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? • Identificación de fortalezas y debilidades de la organización. • Identificación de contratistas a partir de su nivel CMM. • 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 => 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 • Operar como una organización CMM L5 • Crear pasos incrementales específicos • Adoptar el concepto de separación de elementos • Desplegar procesos a proyectos • Medir la mejora por producto, no por proceso • Alojar los recursos apropiadamente • 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.