CMM y CMMI.

Presentación del tema: "CMM y CMMI."— Transcripción de la presentación:

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 Objetivo:
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 Capacidad 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 Medidas y análisis
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 ( )

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

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

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