Descargar la presentación
La descarga está en progreso. Por favor, espere
1
REQUIREMENTS MANAGEMENT
INICIO
2
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
3
Metas y prácticas específicas
Inicio
4
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
5
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
6
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
7
Specific Practices 2/2 1.5 Identificar inconsistencias entre los work products del proyecto y los requerimientos
8
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
9
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)
10
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
11
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
12
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
13
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
14
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
15
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
16
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
17
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
18
SP 1.4 Work products Matriz de Requerimientos fuentes y derivados
Matriz de Requerimientos derivados y otros work products del proyecto
19
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
20
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
21
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
22
SP1.5 Work Products Documentación de las Inconsistencias
Plan para corregirlas
23
Metas y prácticas específicas
Terminación
24
REQUIREMENTS MANAGEMENT
Terminación
Presentaciones similares
