requirements management inicio. propósito gestionar los requerimientos de el o los productos del...
TRANSCRIPT
REQUIREMENTS MANAGEMENT
INICIO
Propósito
• Gestionar los requerimientos de el o los productos del proyecto y de los componentes de dichos productos
• Identificar las inconsistencias entre estos requerimientos y el plan y work products del proyecto
Metas y prácticas específicas
Inicio
Meta específica 1/2
• Los requerimientos son gestionados y las inconsistencias con el plan y los productos del proyecto son identificadas
• El proyecto mantiene un conjunto de vigentes y aprobados requerimientos durante todo el ciclo de vida del proyecto
Meta específica 2/2
• Para la disciplina de Software Engineering los requerimientos de software pueden ser un subconjunto de todos los requerimientos del producto o bien ser el total de los requerimientos
• En el primer caso se habla de requerimientos alocados al software
Specific Practices 1/2
• 1.1Obtener una entendimiento compartido de los requerimientos
• 1.2 Obtener commitments para los requerimientos
• 1.3 Gestionar cambios en los requerimientos
• 1.4 Mantener trazabilidad bidireccional de los requerimientos
Specific Practices 2/2
• 1.5 Identificar inconsistencias entre los work products del proyecto y los requerimientos
SP 1.1: Obtener un entendimiento compartido de los requerimientos
• Durante el desarrollo del proyectos todas las tareas reciben requerimientos
• Se establecen criterios o canales oficiales para recibir requerimientos (Key Users)
• Los Ingenieros de Requerimientos analizan los pedidos con los Key Users para asegurar que se alcanza una correcta y compartida especificación de requerimientos
SP1.1 Work products
• Key Users seleccionados utilizando criterios establecidos
• Requerimientos evaluados y aceptados o rechazados utilizando criterios objetivos– Por ejemplo utilizar IEEE-std 830
• Alcanzar con los Key Users una comprensión de los requerimientos que permita obtener commitments para la realización de los mismos
• Expresar esta comprensión utilizando documentos estandar (Modelo de Requerimientos)
SP1.2 Obtener compromisos para los requerimientos aceptados
• Dirigida a que el equipo que implementará los requerimientos acordados con los Key Users los acepte y se comprometan para su realización
• Estos compromisos se describen en el plan y work products del proyecto
• Los requerimientos evolucionan y es necesario lograr que el equipo acepte estos cambios y su impacto en el plan y work products del proyecto
SP1.2 Work Products
• Evaluar el impacto de los requerimientos sobre los compromisos existentes
• Modelo de Requerimientos actualizado
• Plan y Work Products del proyecto actualizados
• Aprobación del Modelo y del Plan por quienes tienen autoridad para hacerlo
SP 1.3 Gestionar cambios en los requerimientos
• Utilizar un workflow aprobado para gestionar los cambios a los requerimientos– Recibido– Revisado– Acordado con Key User– Evaluado el impacto sobre el proyecto– Aceptado por el equipo del proyecto– Autorizado
SP 1.3 Gestionar cambios en los requerimientos
– Modelo de Requerimientos actualizado– Plan del proyecto actualizado– Requerimiento implementado
• Conocer el status de cada cambio propuesto a los requerimientos
• Mantener la historia de los cambios en los requerimientos– Ayuda a medir la volatilidad
SP 1.3 Work Products
• Base de datos con la historia de los cambios a los Requerimientos
• Mantener esta base es una las tareas del workflow
SP1.4 Mantener trazabilidad bidireccional de los requerimientos
• A medida que se avanza en el desarrollo de los requerimientos o de la solución técnica del producto y se identifican componentes, se generan requerimientos derivados para los componentes
• Se denominan requerimientos fuentes (sources) los acordados con los Key Users
SP1.4 Mantener trazabilidad bidireccional de los requerimientos
• Dos tipos de trazabilidad– De los requerimientos fuentes a los
requerimientos derivados, hasta el último nivel de ellos
– De los requerimientos derivados a otros work products del proyecto
SP1.4 Mantener trazabilidad bidireccional de los requerimientos
• Otros Work Products del proyecto– Modelos de Análisis– Modelos de Diseño– Modelos de Despliegue– Modelos de Componentes de Software– Códigos fuente y ejecutable– Planes y resultados de Verificación– Planes y resultados de Validación
SP 1.4 Work products
• Matriz de Requerimientos fuentes y derivados
• Matriz de Requerimientos derivados y otros work products del proyecto
SP1.5 Especificar inconsistencias entre Requerimientos y Plan
• Buscar y encontrar las inconsistencias entre requerimientos y el plan y work products del proyecto
• Identificar e iniciar las acciones correctivas necesarias
SP1.5 Especificar inconsistencias entre Requerimientos y Plan
• Revisar plan, tareas y work products del proyecto para identificar inconsistencias con los requerimientos y los cambios realizados a los mismos
• Identificar las fuentes de las inconsistencias y su explicación
SP1.5 Especificar inconsistencias entre Requerimientos y Plan
• Identificar los cambios que deben ser realizados en el plan y los work products como consecuencia al cambio en la linea de base de los requerimientos
• Iniciar las acciones correctivas
SP1.5 Work Products
• Documentación de las Inconsistencias
• Plan para corregirlas
Metas y prácticas específicas
Terminación
REQUIREMENTS MANAGEMENT
Terminación