CMM y CMMI

1
CMM y CMMI
2
Contenidos

• Introducción
• Madurez vs. Inmadurez
• Niveles de madurez CMM
• Ejemplos de CMM Nivel 5
• CMMI

3
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

4
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!!!

5
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.

6
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

7
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.

8
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.

9
Niveles de Madurez (II)
10
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.

11
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
  gt codificación y pruebas.
• ÉXITO gerente excepcional gran equipo y si
  alguien se va?

12
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.

13
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.

14
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.

15
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.

16
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.

17
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.

18
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.

19
Niveles de Madurez (XII) Juran
20
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.

21
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.

22
Niveles de Madurez (XV) Optimizado

• Mejora continua de procesos mediante
  retroalimentación.
• Aceptación controlada de ideas y tecnologías
  innovadoras.

23
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.

24
Niveles de Madurez (y XVII) Optimizado

• Los niveles 4 y 5 son casi desconocidos para la
  industria del software

25
Visibilidad de cada Nivel
26
Porcentaje de éxito
27
Estructura de cada nivel
28
Key Process Areas (I)
29
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)

30
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)

31
Key Process Areas (IV) nivel 4

• Quantitative Process Management (QP)
• SW Quality Management (QM)

32
Key Process Areas (V) nivel 5

• Defect Prevention (DP)
• Technology Change Management (TM)
• Process Change Management (PC)

33
Common Features (I)

• Compromiso de Realización
• Políticas organizacionales
• Esponsorización de la gerencia
• Capacidad de Realización
• Recursos
• Estructuras organizacionales
• Entrenamiento

34
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

35
Key Practices ejemplo
36
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

37
Utilización del CMM (y II) Pasos
38
Ejemplos
39
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)

40
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.

41
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.

42
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

43
Boeing (y V). Aproximación data-driven

• Información histórica
• Conjunto consistente de indicadores
• De 8 a 12 métricas de calidad

44
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.

45
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.

46
CSC SEAS (III) Plan de Mejora

• 5 metas
• Productividad
• Calidad
• Predictabilidad
• Tiempo de ciclo
• Cumplimiento de benchmarks estándar.
• Se incluye como objetivos CMM e ISO-9001.

47
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 elementos
4. Desplegar procesos a proyectos
5. Medir la mejora por producto, no por proceso
6. Alojar los recursos apropiadamente
7. Producir tres documentos al principio

48
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
• Mejorar el producto, más que el proceso
• Líneas base del producto y sus métricas, de los
  procesos,
• Establecer un programa de medidas
• La mejora es técnica y gerencial

49
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.

50
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.

51
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.

52
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.

53
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
54
CSC SEAS (XI) tres documentos

• 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

55
CMM Integration
56
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?

57
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)

58
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

59
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

60
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

61
Relación entre ISO/IEC 9001 y SW/CMM
62
Preguntas

• Una empresa certificada ISO-9001, qué nivel CMM
  debería de tener?
• Una organización de nivel 2 ó 3, es ISO-9001
  compliant?
• La gestión de calidad y mejora de procesos, han
  de basarse en ISO-9001 ó en CMM?

63
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)

64
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.

65
KPAs en ISO
66
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.