Componentes de la ingeniería de requisitos.
Cristhian CuevasApuntes11 de Mayo de 2016
4.874 Palabras (20 Páginas)245 Visitas
Ingenieria de Requerimientos
REQM - Requirements Management - CMMI v1.2
RD - Requirements Development - CMMI v1.2
Cubika Development Process (CDP)
2007
Historia de cambios
Fecha | Versión | Descripción | Autor |
08/02/2006 | 1.0 | Versión inicial del documento | Ernesto del Puerto |
09/02/2006 | 1.1 | Revisión y mínimas modificaciones | Germán Boccoleri |
10/02/2006 | 1.2 | Revisión y mínimas modificaciones | Ernesto del Puerto, Germán Boccoleri |
11/04/2006 | 1.3 | Simplificación en descripciones de procedimiento. Cambios en el formato | Germán Boccoleri |
03/05/2006 | 1.4 | Modificación del flujo principal. Revisión de Matías Wepfer y Matías Gorostegui, para customizar a los proyectos de CBK. | Laura Delfini |
05/05/2006 | 1.5 | Redefinición y escritura de todo el documento. | Laura Delfini |
17/05/2006 | 1.6 | Ajustes en la descripción de las actividades y en el formato del documento. | Laura Delfini |
18/05/2006 | 1.7 | Ajuste final en la definición de las actividades | Laura Delfini |
19/05/2006 | 1.8 | Incorporación de actividades según modelo CMMI nivel 2 v1.1 | Laura Delfini |
17/07/2006 | 1.9 | Correcciones de acuerdo a revisión. | Marcelo Schenone |
20/02/2007 | 2.0 | Cambios menores en referencia a un documento de Control de Cambios. | Marcelo Schenone |
07/05/2007 | 2.1 | Ajustes en actividades de acuerdo al Workflow de Actividades. | Marcelo Schenone |
11/05/2007 | 2.2 | Se mejoró el workflow de procedimiento para una mejor comprensión. | Marcelo Schenone |
Historia de Revisiones, Aprobaciones, y Publicaciones
Fecha | Versión | Descripción | Autor |
22/05/2006 | 1.8 | Se publicó, con un curso de presentación y se habilitó la casilla SPI@cubika.com para las observaciones. | Laura Delfini |
10/07/2006 | 1.9 | Se revisó completamente el documento. | Marcelo Schenone |
Tabla de Contenidos
- Ingenieria de Requerimientos
- Historia de cambios
- Tabla de Contenidos
- Información sobre este documento
- Responsables
- Información de referencia y sugerencias
- Audiencia sugerida
- Referencias
- Objetivo
- Alcance
- Controles
- Roles definidos y responsabilidades
- Diagramma de Actividades del Proceso
- Actividades para levantar Requerimientos
- Objetivo
- Frecuencia
- Entradas
- Salidas
- Paso a Paso
- Actividades para refinar la definición del sistema
- Definir la Visión y el SRS
- Objetivo:
- Frecuencia:
- Entradas:
- Salidas:
- Paso a Paso
- Definir el Modelo de Casos de Uso
- Objetivo
- Frecuencia
- Entradas
- Salidas
- Paso a Paso
- Actividades para revisar requerimientos
- Objetivo
- Frecuencia
- Responsable
- Entradas:
- Salidas:
- Paso a Paso
- Actividades para generar una Línea Base
- Objetivo
- Frecuencia
- Responsable
- Entradas:
- Salidas:
- Actividades para Desarrollar Requerimientos
- Objetivo
- Frecuencia
- Entradas:
- Salidas:
- Paso a Paso
- Actividades para Revisar Especificaciones de Requerimientos
- Objetivo
- Frecuencia
- Entradas:
- Salidas:
- Actividades para refinar los requerimientos suplementarios
- Objetivo
- Frecuencia
- Entradas
- Salidas:
- Paso a Paso
- Actividades para Administrar los Requerimientos de Cambio
- Objetivos
- Frecuencia
- Entradas
- Salidas
- Paso a Paso
- Actividades para especificar Gap de requerimientos
- Objetivos
- Frecuencia
- Entradas:
- Salidas
- Paso a Paso
Información sobre este documento
Responsables
- Sponsor del Proyecto de Mejora: Juan Cabrera
- Responsables del Proceso: PMO
- Miembros del sector Software Process Improvement (SPI)
Información de referencia y sugerencias
http://confluence.cub2k.com/display/CDP/Cubika+Development+Process
spi@cubika.com
Audiencia sugerida
- Analistas Funcionales
Referencias
IBM-RUP 2005
SEI-CMMi DEV v1.2
CM.Nomenclatura de Artefactos.doc
EN.Glosario Organizacional Proceso Cubika.doc
Objetivo
Especificar el procedimiento de Administración de Requerimientos, artefactos, entregables internos y públicos, criterios y lineamientos aplicables a los procesos de análisis en proyectos de desarrollo de software manejados por Cubika.
Alcance
- Este procedimiento se aplica en todos los proyectos de desarrollo de software "manejados" de Cubika.
Controles
Controles serán llevados a cabo por lo procedimientos definidos dentro de la disciplina PPQA.
Roles definidos y responsabilidades
- Analista (Funcional)
El analista funcional es el rol que releva y especifica los requerimientos, modelando y especificando los casos de uso, delineando la funcionalidad del sistema y delimitando su alcance.
Es el responsable de:
- Obtener y analizar en detalle los requerimientos de los stakeholders.
- Elaborar y administrar el Plan de Administración de Requerimientos junto con el PM del proyecto.
- Definir en detalle el alcance del sistema.
- Analizar el impacto de los requerimientos de cambio, realizados sobre la funcionalidad ya definida.
- Armar y mantener actualizado el glosario de términos comunes en el sistema.
- Identificar actores y casos de uso de negocio y de implementación.
- Especificar casos de uso, modelo de caso de uso, especificaciones suplementarias, y demás artefactos que se utilicen para comenzar con el desarrollo del producto.
- Desarrollar y mantener actualizado el Documento de Visión.
- Administrar y mantener las dependencias entre casos de uso y actores, así como también la trazabilidad funcional.
- Líder de Proyecto:
El líder de proyecto es el rol que gestiona el proyecto y es el responsable final por el éxito del mismo. En relación a requerimientos, debe validar y gestionar el alcance del producto durante el ciclo de vida del proyecto.
Es el responsable de:
- Validar la línea base de requerimientos, el Documento de Visión y el SRS
- Armar la planificación en función de los requerimientos definidos
- Gestionar el alcance a lo largo del ciclo de vida
- Participar como miembro del CCB en la resolución de los pedidos de cambio
- QA-Quality Assurance:
El QA es el rol que verifica la calidad en los artefactos de requerimientos.
Es el responsable de:
- Verificar consistencia y coherencia de artefactos de requerimientos.
- Asegurar la calidad del proceso de requerimientos.
- Verificar que los cambios hayan sido correctamente impactados en los requerimientos.
- Arquitecto de software:
El arquitecto tiene la responsabilidad de conducir las principales decisiones técnicas, denominadas "arquitectura del software". Esto incluye identificar y documentar los aspectos más significativos de la arquitectura, incluyendo requerimientos no funcionales, diseño, implementación y deployments del sistema.
Es el responsable de:
- Análisis de la arquitectura.
- Asegurar la viabilidad de la arquitectura requerida.
- Identifica mecanismos de diseño.
- Estructura el modelo de implementación.
- Describe la arquitectura en tiempo de ejecución.
- Describe la distribución del sistema en las distintas etapas.
Diagrama de Actividades del Proceso
[pic 1]
Actividades para levantar Requerimientos
Objetivo
- El objetivo principal de este workflow es mejorar los conocimientos acerca del problema a ser resuelto, identificar a los stakeholders, definir el entorno, las funcionalidades clave y las restricciones de la solución propuesta.
Frecuencia
- Las tareas de este workflow se deberán realizar en reiteradas oportunidades durante la fase de Incepción. Luego, a lo largo del ciclo de vida del proyecto será necesario repetirlo para poder atender a los inevitables requerimientos de cambios que se presenten.
- Esta tarea se realiza normalmente al principio de cada iteración.
Entradas
- Modelo de Casos de Uso de Negocio
- Modelo de Entidades de Dominio
- Realizaciones de Casos de Uso de Negocio
- RFP
- Project Charter
- Propuesta Económica
Salidas
- Documento de Visión Inicial
Paso a Paso
Actividad | Descripción | Responsable |
Conocer en totalidad el problema a ser resuelto | Analizar la información relevada del negocio (Modelo de Casos de Uso de Negocio, RFP) para comprender la totalidad del problema a ser resuelto. | Analista Funcional |
Identificar las restricciones impuestas sobre el sistema | Identificar las restricciones que se hayan detectado durante el relevamiento impuestas al nuevo sistema. | Analista Funcional |
Definir las características del sistema | Tomar como input si existieran las características ofrecidas en la Propuesta Económica o en el RFP (Request For Proposal) entregado por el cliente.
| Analista Funcional |
Actividades para refinar la definición del sistema
...