CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad Robin Alberto Castro Gil
[email protected] Liliana Franco Marulanda
[email protected] Administración de los requerimientos [REQM]
http://www.icesi.edu.co/servicios_apoyo Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
CMMI
Capability Maturity Model Integration CMMI es un modelo para la mejora de procesos que proporciona a las organiz organizac acion iones es los elementos esen esenci cial ales es para para proc proces esos os efic eficie ient ntes es.. La ultima versión del modelo cuenta con tres constelaciones: C MMI-DEV • Desarrollo (CMMI-DEV y CMMI-DEV + IPPD) • Adquisición (CMMI-ACQ) • Servicios (CMMI-SVC) En nuestro caso, el modelo/constelación que será implementado es CMMI para el desarrollo (CMMI-DEV o CMMI for Development)
Fuente: http://es.wikipedia.org/wiki/CMMI
CMMI DEV- Niveles de madurez vs categorías
Requirements Management [REQM] Administración de los requerimientos CMMI Universidad Icesi – Cali, Colombia
Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
CATEGORÍA:
INGENIERÍA CONCEPTOS GENERALES
- Categoría: Ingeniería Área de proceso básica de la categoría Ingeniería
Categoría de ingeniería Las áreas de proceso que pertenecen a la categoría Ingeniería cubren las actividades para la desarrollo y mantenimiento que parten de la disciplina de la ingeniería. Las áreas de proceso de Ingeniería pueden utilizarse para la mejora de procesos. Las áreas de proceso contenidas en esta categoría son: • • • • • •
Requirements Development [RD] Requirements Management [REQM] Technical Solution [TS] Product Integration [PI] Verification [VER] Validation [VAL]
Ingeniería Áreas de proceso básicas Requirements
REQM
Product and product component requirements
Alternative solutions
TS
RD
Product components
Product
PI
Requirements Product components, work products, verification and validation reports
PI = Produ ct Integration RD = Requirements Development REQM = Requirements Management TS = T echnical Solution VAL = Validation VER = Verification
VER
Customer needs
Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
VA L
Customer
REQUIREMENTS MANAGEMENT A ENGINEERING PROCESS AREA AT MATURITY LEVEL 2
- Propósito y descripción - Metas y practicas específicas
Administración de los requerimientos [REQM]
Propósito: •
El propósito de REQM es administrar los requerimientos del proyecto e identificar inconsistencias entre estos y el plan del proyecto, y los entregables.
El área de proceso REQM involucra: –
Administrar todos los requerimientos recibidos o generados por el proyecto, incluyendo los requerimientos funcionales o no funcionales.
–
Documentar los cambios a los requerimientos y mantener una trazabilidad bidireccional entre los requerimientos y todos los productos.
REQM es un área de proceso de la categoría “Ingeniería” para nivel de madurez 2
Administrar los requerimientos (Metas y practicas específicas)
•
SG1 Administrar los requerimientos SP 1.1 Obtener un entendimiento de los requerimientos. SP 1.2 Obtener un compromiso hacia los requerimientos. SP 1.3 Administrar los cambios a los requerimientos. SP 1.4 Mantener la trazabilidad bidireccional a los requerimientos. SP 1.5 Identificar inconsistencias entre el proyecto y los requerimientos.
Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
SG1 Administrar los requerimientos Los requerimientos son administrados y sus inconsistencias con los planes de proyectos y productos de trabajo son identificados •
Los requerimientos son administrados, documentando los cambios generados, manteniendo trazabilidad de estos contra todos los entregables del proyecto, identificando inconsistencias entre los requerimientos y el plan del proyecto y los entregables, tomando acciones correctivas.
•
El proyecto mantiene un curso y es aprobado según el conjunto de requerimientos basados en el ciclo de vida del proyecto siguiendo: – – – –
Administrar todos los cambios a los requisitos Mantener las relaciones entre los requisitos, los planes de proyecto, y la labor de productos Identificar las incoherencias entre los requisitos, los planes de proyecto, y la labor de productos Tomar medidas correctivas
mayor información en: Solución técnica Ver mayor información en: Desarrollo de los requerimientos Ver mayor información en: Monitorio y control de proyectos Ver
SP 1.1 Obtener un entendimient o de los requerimient os
SG1 Administrar los requerimientos
SP 1.1 Obtener un entendimiento de los requerimientos
Desarrollar un entendimiento con los requisitos proveídos sobre el significado de los requisitos.
Productos típicos de trabajo • Lista de criterios para identificar los
proveedores apropiados de requerimientos. • Criterios que permitirán evaluar y aceptar los requerimientos. • Resultados del análisis contra los criterios definidos. • Un acuerdo del conjunto de requerimientos.
SP 1.1 Obtener un entendimient o de los requerimient os
SG1 Administrar los requerimientos
Sub-prácticas •
Establecer criterios para la identificación de los proveedores de los requerimientos apropiados.
•
Establecer criterios objetivos con los cuales serán aceptados los requerimientos.
•
Analizar los requerimientos contra los criterios establecidos para verificar su cumplimiento.
•
Lograr el entendimiento de los requerimientos con el proveedor para que los participantes puedan comprometerse con ellos
SP 1.2 Obtener un compromiso hacia los requerimient os
SG1 Administrar los requerimientos
SP 1.2 Obtener un compromiso hacia los requerimientos
Obtener compromisos de los participantes del proyecto hacia los requerimientos
Productos típicos de trabajo • Valoración del impacto de los
requerimientos. • Documentación de compromisos en: – Los requerimientos – Los cambios de los requerimientos
SP 1.2 Obtener un compromiso hacia los requerimient os
SG1 Administrar los requerimientos
Sub-prácticas •
Valorar el impacto que tendrían los requerimientos de un nuevo proyecto, contra los compromisos ya adquiridos.
•
Negociar y registrar los compromisos.
SP 1.3 Administrar los cambios a los requerimient os
SG1 Administrar los requerimientos
SP 1.3 Administrar los cambios a los requerimientos
Administrar los cambios de los requerimientos según como ellos evolucionen durante el proyecto
Productos típicos de trabajo • Estados de los requerimientos. • Base de datos de los requerimientos • Base de datos de las decisiones sobre
los requerimientos
SP 1.3 Administrar los cambios a los requerimient os
SG1 Administrar los requerimientos
Sub-prácticas •
Documentar todos los requerimientos y sus cambios sus cambios que son dados o generados.
•
Mantener el historial de los cambios a los requerimientos y la razón de los cambios.
•
Evaluar los impactos de los cambios en los requerimientos desde el punto de vista de los interesados.
•
Asegurar la disponibilidad de la información de los requerimientos y de sus cambios hacia el proyecto.
SP 1.4 Mantener una trazabilidad bidireccional a los requerimient os.
SG1 Administrar los requerimientos
SP 1.4 Mantener una trazabilidad bidireccional a los requerimientos
Mantener una trazabilidad bidireccional entre los requerimientos y los productos de trabajo
Productos típicos de trabajo • •
Matriz de trazabilidad de los requerimientos Sistema de monitoreo para los requerimientos
SP 1.4 Mantener una trazabilidad bidireccional a los requerimient os.
SG1 Administrar los requerimientos
Sub-prácticas •
Mantener trazabilidad de los requerimientos para asegurar que la fuente de los requerimientos derivados estén documentados.
•
Mantener trazabilidad de los requerimientos sus requerimientos derivados y con sus elementos relacionados con funciones, interfaces, objetos, personas y procesos.
•
Generar la matriz de trazabilidad de requerimientos.
SP 1.5 Identificar inconsistenci as entre el proyecto y los requerimient os
SG1 Administrar los requerimientos
SP 1.5 Identificar inconsistencias entre el trabajo del proyecto y los requerimientos
Identificar inconsistencias entre el plan del proyecto, los productos de trabajo y los requerimientos (Ver mayor información en: Control y monitoreo de proyectos)
Productos típicos de trabajo • Documentación de inconsistencias • Acciones Correctivas
SP 1.5 Identificar inconsistenci as entre el proyecto y los requerimient os
SG1 Administrar los requerimientos
Sub-prácticas •
Revisión de todo el proyecto para evaluar la consistencia con los requerimientos y sus cambios.
•
Identificar la causa de la inconsistencia y su lógica.
•
Identificar los cambios que son requeridos en los planes y en los productos de trabajo resultantes de los cambios a la línea base de los requerimientos.
•
Iniciar acciones correctivas
METAS Y PRÁCTICAS GENÉRICAS
- Metas y prácticas genéricas - Relaciones entre áreas de proceso y prácticas genéricas
Metas y prácticas genéricas GG1. Cumplir con las metas específicas GP 1.1
- Ejecutar las prácticas específicas
a u n i t n o C
GG2. Institucionalizar un proceso administrado GP 2.1
- Establecer una política organizacional
GP 2.2
- Planificar el proceso
GP 2.3
- Proveer los recursos
GP 2.4
- Asignar las responsabilidades
GP 2.5
- Entrenar a las personas
GP 2.6
- Administrar las configuraciones
GP 2.7
- Identificar e involucrar a los stakeholders relevantes
GP 2.8
- Monitorear y controla el proceso
GP 2.9
- Evaluar objetivamente la adherencia
GP 2.10
- Revisar el estado con la administración superior
a d a n o l a c s E / a u n i t n o C
Metas y prácticas genéricas *GG3. Institucionalizar un proceso definido GP 3.1
- Establecer un proceso definido
GP 3.2
- Recolectar la información de mejora
, a d a n o 5 l a – c s 3 E / a M u N n i t n o C
*Starget Only: GG3 y sus practicas no son aplicables al nivel de madurez dos (2), pero son aplicables a un nivel de madurez tres (3) y las anteriores
GG4. Institucionalizar un proceso cuantitativamente administrado GP 4.1
- Establecer objetivos cuantificables para el proceso
GP 4.2
-Establecer rendimiento de subprocesos
a u n i t n o C
GG5. Institucionalizar un proceso en optimización GP 5.1
- Asegurar un mejoramiento continuo del proceso
GP 5.2
-Corregir desde la raíz las causas de los problemas.
a u n i t n o C
Relaciones entre áreas de procesos y prácticas genéricas GP 1.1
GP 3.1
SP 1.1 OT IPM
GP 2.4 GP 2.3
CM
GP 2.5
SP 1.6
OPF
SP 2.1
SP 2.5
GP 2.2
SP 1.3
SP 2.6
GP 3.2
SP 3.4
GP 2.6
SP 2.4 SP 2.4
OPD
GP 4.1
GP 2.7 OPP
PP
SP 1.1
QPM
SP 1.5 GP 2.8
GP 2.1
MA
GP 4.2
SG 2
PMC
GP 2.9
SP 1.6 SP 1.7
Fuente: CMMI-DEV-v1.2 Tabla 7.2 Generic Practice and Process Area Relationships
PPQA
GP 2.10
Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
GP 5.1
OID
GP 5.2
CAR
CMMI
Referencias •
CMMI, guidelines for process integration and product improvement/ Chrissis, Mary Beth; Konrad, Mike; Shrum, Sandy. - 2. ed. - Upper Saddle River, New Jersey : Addison Wesley, c2007. (SEI Series in Software Engineering).
•
CMMI® for Development, Version 1.2 - CMU/SEI-2006
•
Website http://www.sei.cmu.edu/cmmi/
•
Website http://www.wikipedia/CMMI /
•
Introduction to CMMI DEV Version 1.2 – [Training material]
•
Intermediate Concepts of CMMI DEV Version 1.2 – [Training material]
•
CMMI survival guide, just enough process improvement/ Garcia, Suzanne; Turner, Richard. - Upper Saddle River, New Jersey : Addison Wesley, c2007. (SEI Series in Software Engineering).
CMMI Capability Maturity Model Integration Modelo integrado de madurez de la capacidad Robin Alberto Castro Gil
[email protected] Liliana Franco Marulanda
[email protected] Administración de los requerimientos [REQM]
http://www.icesi.edu.co/servicios_apoyo Fuente CMMI-DEV-v1.2 SEI http://www.sei.cmu.edu/
