Transcript Document 7247744

CMM y CMMI
Contenidos
• Introducción
• Madurez vs. Inmadurez
• Niveles de madurez CMM
• Ejemplos de CMM Nivel 5
• CMMI
2
Introducción
• 1986: SEI y MITRE desarrollan un
– FRAMEWORK DE MADUREZ DE PROCESOS
• Objetivo:
– Mejorar los procesos software de las
organizaciones
• 1987: descripción breve y cuestionario de
madurez
3
Madurez vs. Inmadurez
• Una organización inmadura:
– Es reaccionaria
– Está centrada en resolución de crisis
– Planifica mal de manera rutinaria
– Compromete la calidad
– … aunque a veces hacen buen sw!!!
4
Madurez del Proceso SW
• Medida de definición, gestión, control y
efectividad del proceso sw en una
empresa.
• Para que el proceso SW sea maduro, la
organización completa ha de serlo.
• CMM busca esa madurez.
5
CMM: introducción
• Capability Maturity Model
• Guía para ganar control de los procesos de
una empresa en cuanto a desarrollo y
mantenimiento de sw.
• Inspirado por Crosby [Quality is free,
1979]
6
¿Para qué se utiliza CMM?
1. Identificación de fortalezas y debilidades
de la organización.
2. Identificación de contratistas a partir de
su nivel CMM.
3. Comprensión de las actividades
necesarias para mejora de procesos.
7
Niveles de Madurez (I)
• Mejora continua de procesos, en lugar de
innovaciones revolucionarias.
• Un nivel de madurez es un paso evolutivo
bien definido que permite alcanzar un
proceso maduro.
8
Niveles de Madurez (II)
9
Niveles de Madurez (III): Inicial
• Proceso caracterizado ad-hoc, casi
siempre de manera caótica.
• Pocos procesos están definidos.
• El éxito depende del esfuerzo individual.
10
Niveles de Madurez (IV): Inicial
• No hay un entorno apropiado de desarrollo y
•
•
•
mantenimiento sw.
La aplicación de procesos sw no funciona, pues
se sustenta en planificación poco efectiva y
reacción instintiva.
Cuando hay crisis, las planificaciones se olvidan
=> codificación y pruebas.
ÉXITO = gerente excepcional + gran equipo… ¿y
si alguien se va?
11
Niveles de Madurez (V): Repetible
• Procesos básicos de gestión de proyectos:
– Coste
– Planificación
– Funcionalidad
• Disciplina de procesos existe para repetir
éxitos anteriores en proyectos similares.
12
Niveles de Madurez (VI): Repetible
• Las políticas de gestión de proyectos están
establecidas.
• Los procedimientos de implementación de
estas políticas también están establecidas.
• La organización se basa en la experiencia
de anteriores proyectos.
13
Niveles de Madurez (VII): Repetible
• Los compromisos se basan en proyectos
anteriores.
• Los jefes de proyecto aplican conceptos de
gestión de proyecto.
• Los problemas se solucionan según van
apareciendo.
14
Niveles de Madurez (VIII): Repetible
• Se han instalado herramientas básicas de
gestión de software.
– Se utilizan líneas base
• Estándares definidos
– La organización “espera” que se cumplan.
• Equipos disciplinados.
15
Niveles de Madurez (IX): Definido
• Procesos sw de gestión e ingeniería están:
– Documentados
– Estandarizados
– Integrados a partir de un proceso estándar
• Todos los proyectos utilizan “vistas” de
estos procesos.
16
Niveles de Madurez (X): Definido
• El proceso sw está perfectamente
documentado y gestionado.
• Existe un grupo responsable de las
actividades sw de la organización.
• Existen programas de entrenamiento.
• Resumen: estándar y consistente
– Todas las actividades son estables y
repetibles.
17
Niveles de Madurez (XI): Definido
• La diferencia entre el nivel 2 y 3 es:
– Nivel 2: existen políticas y procedimientos.
– Nivel 3: definición, integración y
documentación de todo el proceso.
• Desafío: construir procesos que habiliten el trabajo
de la gente, sin ser demasiado rígidos.
18
Niveles de Madurez (XII): Juran
19
Niveles de Madurez (XIII): Gestionado
• Métricas detalladas del proyecto y
producto sw son recolectadas.
• Tanto el proceso como el producto sw se
entienden y controlan perfectamente.
20
Niveles de Madurez (XIV): Gestionado
• Se establecen metas de calidad de manera
•
•
•
cuantitativa tanto para el producto como para el
proceso software.
Cada actividad se mide por productividad y
calidad, utilizando técnicas de repositorios de
datos.
En estas medidas, variaciones aleatorias se
diferencian de las que tienen sentido.
Resumen: organizaciones predecibles.
21
Niveles de Madurez (XV): Optimizado
• Mejora continua de
•
procesos mediante
retroalimentación.
Aceptación controlada
de ideas y tecnologías
innovadoras.
22
Niveles de Madurez (XVI): Optimizado
• Foco absoluto en la mejora continua de
procesos.
– La organización es capaz de identificar
debilidades y fortalezas proactivamente.
• Análisis de defectos para determinar
causas.
23
Niveles de Madurez (y XVII): Optimizado
• Los niveles 4 y 5 son casi desconocidos
para la industria del software:
24
Visibilidad
de cada
Nivel
25
Porcentaje
de éxito
26
Estructura de
cada nivel
27
Key Process
Areas (I)
28
Key Process Areas (II): nivel 2
• Gestión de Requisitos (RM)
• Planificación de Proyectos SW (PP)
• Project Tracking (PT)
• Gestión de Subcontrata (SM)
• SQA
• Gestión de Configuración (CM)
29
Key Process Areas (III): nivel 3
• Organization Process Focus (PF)
• Process Definition (PD)
• Training Program (TP)
• Integrated Software Management (IM)
• SW Product Engineering (PE)
• Intergroup Coordination (IC)
• Peer Reviews (PR)
30
Key Process Areas (IV): nivel 4
• Quantitative Process Management (QP)
• SW Quality Management (QM)
31
Key Process Areas (V): nivel 5
• Defect Prevention (DP)
• Technology Change Management (TM)
• Process Change Management (PC)
32
Common Features (I)
• Compromiso de Realización
– Políticas organizacionales
– Esponsorización de la gerencia
• Capacidad de Realización
– Recursos
– Estructuras organizacionales
– Entrenamiento
33
Common Features (y II)
• Actividades Realizadas
– Establecimiento de planes y procedimientos
– Acciones de trabajo, control y corrección
• Medidas y análisis
• Verificación de la Implementación
– Revisiones
– Auditorías
– SQA
34
Key Practices:
ejemplo
35
Utilización del CMM (I)
• Criterios y métodos desarrollados por el SEI para
valorar la madurez de una organización:
– Valoración del Proceso Software (Software Process
Assessments)
• Estado del proceso
– Evaluaciones de Capacidad del Software (Software
Capability Evaluations)
• Identificación de contratistas
• Monitorización del estado de un proceso software
36
Utilización
del CMM
(y II):
Pasos
37
Ejemplos
38
Boeing (I)
• SEI dice que el tiempo medio de paso de Nivel 3
•
a 4 es de 33 meses, y 18 más para llegar al
Nivel 5.
Boeing Military Aircraft and Missiles Seattle Site
(AMSS)
– Alcanzó el Nivel 5 en Diciembre de 2001.
– Alcanzó el Nivel 3 en Diciembre de 2000.
• Boeing Space Transportation Systems
– De Nivel 3 a Nivel 5 en seis meses (1995-96)
39
Boeing (II). Factores esenciales
• Composición de un
•
•
Grupo de Proceso de
Ingeniería del
Software (SEPG)
Relación vital con el
caso de negocio
Institucionalización de
una aproximación
“data-driven” a la
gestión.
40
Boeing (III). SEPG
• Concepto de “champion” o espónsor.
• Sus actividades son ejecutivas.
• La gente que tomaba las decisiones eran
responsables de los productos que
utilizaban el proceso.
41
Boeing (IV). Relación vital con el caso
de negocio
• Entender claramente qué areas son
críticas para producir productos exitosos y
de alta calidad.
– Metas de negocio
– Criterios de éxito
42
Boeing (y V). Aproximación “datadriven”
• Información histórica
• Conjunto consistente de indicadores
– De 8 a 12 métricas de calidad
43
CSC SEAS (I)
• Systems, Engineering and Analysis Support
•
Center del Computer Sciences Corporation
CSC: integrador sw con más de 65.000
empleados en todo el mundo.
– SEAS: 850 empleados trabajando para NASA Goddard
Space Flight Center
• 1998: 6ª compañía mundial en obtener el nivel 5
CMM.
44
CSC SEAS (II)
• CSC SEAS da soporte al NASA GSFC en:
– Program Management (PM Office)
– Quality Assurance (QA)
– Process Engineering (PEO)
– Project Control (PCO)
• Debido a la importancia de estas
actividades, se inicia un programa de
mejora de procesos en 1995.
45
CSC SEAS (III): Plan de Mejora
• 5 metas:
1.
2.
3.
4.
5.
Productividad
Calidad
Predictabilidad
Tiempo de ciclo
Cumplimiento de benchmarks estándar.
• Se incluye como objetivos: CMM e ISO9001.
46
CSC SEAS (IV): lecciones
1. Operar como una organización CMM L5
2. Crear pasos incrementales específicos
3. Adoptar el concepto de separación de
4.
5.
6.
7.
elementos
Desplegar procesos a proyectos
Medir la mejora por producto, no por proceso
Alojar los recursos apropiadamente
Producir tres documentos al principio
47
CSC SEAS (V): operar como CMM 5
• No tomar CMM como un conjunto secuencial
•
•
de KPAs
Cultura de mejora continua
Elementos clave desde el principio:
1. Mejorar el producto, más que el proceso
2. Líneas base del producto y sus métricas, de los
procesos, …
3. Establecer un programa de medidas
4. La mejora es técnica y gerencial
48
CSC SEAS (VI): pasos incrementales
• Aunque la mejora es continua, ha de estar
dispuesta en pasos discretos
– Auditorías internas cada cierto tiempo
– Revisiones externas independientes también
• SEAS: 14 entre 1994 y 2001.
49
CSC SEAS (VII): separación de elementos
• ¡ORGANIZACIÓN!
• Un ente que se ocupe de la mejora de
procesos
• Los proyectos se ocupan de producir
sistemas y software.
50
CSC SEAS (VIII): desplegar procesos a proyectos
• A veces, los ingenieros de proceso deben
colaborar en los proyectos para que todo
se aplique correctamente.
• Los procedimientos, checklists, … son
adecuados, pero a veces la participación
de un experto resuelve problemas más
rápidamente.
51
CSC SEAS (IX): medir la mejora por producto
• Es cierto que los procesos que generan un
producto afectan a la calidad del producto.
• Pero también hay que medir la tendencia
del propio producto: metas, métricas, etc.
52
CSC SEAS (X): alojar recursos
• La organización debe
identificar qué
recursos son
necesarios para el
plan de
aseguramiento y
mejora.
– Quiénes
– Cantidad
– Coste
Tamaño de
organización
Recursos para
proceso
70-150
2.0
150-400
2.5-4.0
400-900
3.5-4.5
900-1700
4.0-6.0
53
CSC SEAS (XI): tres documentos
1.
2.
3.
•
•
•
•
•
•
•
Manual de “Quality Management System”
Orientación para nuevos empleados
Describe organización, roles, responsabilidades, …
Qué procesos y cómo se definen.
Plan de Mejora de Procesos
Metas organizativas
Responsabilidades
Estructura de cada actividad
“Profile”
Estado general del proceso
•
•
•
•
•
Cantidad de sw en desarrollo y mantenimiento
Información sobre defectos
Costes de mantenimiento
Tiempos de ciclo de vida sw
…
54
CMM Integration
55
Introducción
• Muchas organizaciones utilizan ya diferentes
CMMs para
–
–
–
–
Ingeniería de sistemas
Ingeniería del software
Adquisición de software
…
• Muchos modelos• Además, estas organizaciones se compran entre
•
sí, se fusionan, …
¿Cómo se integran tantos modelos?
56
CMMI: qué es
• CMMI existe para combinar tres modelos:
– CMM para Software (SW-CMM) v2.0 draft
– Electronic Industries Alliance Interim Standard
(EIA/IS) 731
– Integrated Product Development CMM (IPD-CMM)
v0.98
• Desarrollo de un framework común
• Todos los productos desarrollados son
compatibles con ISO/IEC 15504 (Technical
Report for SW Process Assessment)
57
Elección del modelo CMMI
• Al ser un framework, hay múltiples modelos a
seleccionar:
– ¿Representación?
• Continuo
• Por estapas
– ¿Qué modelo integrado elegir?
• Ingeniería de Sistemas
• Ingeniería del Software
• Desarrollo Integrado de Proceso y Producto
• Subcontrata
58
Tipos de Representación (I): Continua
• Permite seleccionar el orden de mejora
para la organización
• Permite comparativas a través y entre
organizaciones, área a área.
• Migración fácil de EIA/IS a CMMI
59
Tipos de Representación (y II): Por Etapas
• Secuencia probada de mejoras, a partir de
prácticas de gestión básicas.
• Permite comparativas a través y entre
organizaciones, área a área.
• Migración fácil de SW-CMM a CMMI
60
Relación entre ISO/IEC 9001 y
SW/CMM
61
Preguntas
• Una empresa certificada ISO-9001, ¿qué
nivel CMM debería de tener?
• Una organización de nivel 2 ó 3, es “ISO9001 compliant”?
• La gestión de calidad y mejora de
procesos, ¿han de basarse en ISO-9001 ó
en CMM?
62
Relaciones entre CMM e ISO
• Nivel de detalle diferente
– ISO 9001: ¿50 páginas?
– CMM: ¿500 páginas?
• ISO, pero no CMM:
– Productos provistos por comprador (4.7)
– Logística (manejo y entrega) (4.15)
• ISO y CMM, pero no iguales:
– Servicing (4.19)
• ISO y CMM, en debate:
– Acciones correctivas (4.14)
– Técnicas estadísticas (4.20)
63
Diferencia principal
• CMM se centra en
– el concepto de “mejora continua”.
– Software.
• ISO se centra en
– conseguir los criterios mínimos para un
sistema de calidad aceptable.
– Hw, sw, materiales procesados, servicios.
64
KPAs en
ISO
65
Referencias
• CMU/SEI-93-TR-024: Capability Maturity Model for
•
•
•
Software, v. 1.1. Paulk, M.C., Curtis, B., Chrissis, M.B.,
Weber, C. V.
CMMI-SE/SW/IPPD/SS, v.1.1: Capability Maturity Model
Integration (CMMI), Version 1.1. CMMI Product Team.
CMU/SEI-94-TR-12: A Comparison of ISO 9001 and the
Capability Maturity Model for Software. Paulk, M.C.
Attaining Level 5 in CMM Process Maturity. McFarry, F.,
Decker, B. IEEE Software, November/December 2002.
66