visión general de cmmi for development

© ESI 2008 1

Visión general deCMMI® for Development

® Capability Maturity Model and CMMI are registered in the U.S. Patent and Trademark Office by Carnegie Mellon University

© ESI 2008 2

Objetivos del seminario

• Introducir la mejora de procesos basada en CMMI

• Comprender los modelos CMMI, sus prácticas de gestión, de ingeniería y sus aspectos organizativos

• Estar seguros de que se entiende:– Cuál es nuestro rol en la mejora de procesos– Qué es y qué no es CMMI-DEV

• Entender la importancia de la mejora de procesos dentro del contexto de negocio de la organización

© ESI 2008 3

Reglas

• Le animamos a formular preguntas

• Sus aportaciones serán bienvenidas

• Se espera una comunicación abierta, sincera e imparcial entre todos los participantes

© ESI 2008 4

Agenda

• Motivación para la mejora de procesos

• Conceptos de gestión de procesos

• Visión general de CMMI-DEV

• Áreas de proceso de CMMI-DEV

• El camino hacia la mejora

• Conclusiones

© ESI 2008 5

• Centro Tecnológico de la Red Vasca de Tecnología. • Fundación sin ánimo de lucro.• Centro Tecnológico de la Red Vasca de Tecnología. • Fundación sin ánimo de lucro.

• Fundada en 1993 por la Comisión Europea y Gobierno Vasco. Con sede social en Zamudio.

• Fundada en 1993 por la Comisión Europea y Gobierno Vasco. Con sede social en Zamudio.

European Software Institute

© ESI 2008 6

ESI es parte de TECNALIA, una de las mayores Corporaciones Tecnológicas privadas de Europa

– Una Corporación Tecnológica privada, creada en 2001

– Con el objetivo de contribuir al desarrollo económico y social a través de la promoción de la innovación tecnológica

– Integra las actividades de un grupo de Centros Tecnológicos

– El Objetivo de la estructura financiera

• 50% ingresos por actividades comerciales bajo contrato,

• 50% subvenciones de proyectos I + D

– Miembro de EARTO: Asociación Europea de Investigación y Organizaciones Tecnológicas

© ESI 2008 7

Cifras Tecnalia

Más de 1.300 empleados

24 sedes (140.000 m2)

> 3.600 Clientes/año

115 millones de Euros (Ingresos 2007)

6 FP: 26 Proyectos (45 M€de ingresos )

Certificación ISO 9001

CENTROS TECNOLÓGICOS INTEGRADOSCENTROS TECNOLÓGICOS INTEGRADOS

http://www.tecnalia.net/tecnalia/castellano/azti.jsp

http://www.tecnalia.net/tecnalia/castellano/esi.jsp

http://www.tecnalia.net/tecnalia/castellano/inasmet.jsp

http://www.tecnalia.net/tecnalia/castellano/labein.jsp

http://www.tecnalia.net/tecnalia/castellano/robotiker.jsp

http://www.tecnalia.net/tecnalia/castellano/neiker.jsp

© ESI 2008 8

COLABORADORES DE LA FUNDACIÓNCOLABORADORES DE LA FUNDACIÓN

http://www.ericsson.com/

http://www.vodafone.es/

http://www.iberdrola.es/

http://www.gedas.com/index.htm

http://www.lucent.com/

http://www.bbk.es/

http://www.nokia.es/

http://www.itesm.mx/

© ESI 2008 9

¿En qué basa su estrategia de

mejora?

CMMI Overview Seminar© ESI 2005 10

MotivaciMotivacióón n para la mejora para la mejora

de procesosde procesos

© ESI 2008 11

¿Por qué debería la Gerencia preocuparse por el proceso de software ?

Resulta muy complicado entregar constantementeconstantemente

productosproductos de calidad a nuestros clientes y a la vez

obtener beneficios, partiendo de unos

procesosprocesos de desarrollo pobremente definidos.

© ESI 2008 12

Situación real …

“Sólo el 34% de los proyectos de software

tiene éxito.”Standish Group, CHAOS Report, 2003

© ESI 2008 13Source: Standish Group Chaos Report - 2003

¿Qué está sucediendo?Exitosos

34%

Fallidos(Cancelados)

15%

Problemáticos51%

Definiciones

Exitosos En tiempo, en presupuesto, en funcionalidad prometida

Problemáticos Tarde, sobrepasado el presupuesto, falta funcionalidad

Fallidos Proyectos cancelados

De una inversión en proyectos de $255 billones, se desperdician $55 billonesDe cada 100 proyectos, 94 se reinicianAl liberar un producto, tan sólo están incluidas el 52% de las funciones y propiedades requeridas.De media los costes de los proyectos suponen el 143% de lo estimado, y el 82% se pasa de plazos

© ESI 2008 14

Estamos mejorando, pero …Exitosos 16%


31%

Problemáticos53%

Exitosos 34%


15%

Problemáticos51%

1994 Chaos Report

2003 Chaos Report

El dinero perdido en gastos del proyecto ha descendido del 32% al 21.5%Los sobrecostes han descendido del 180% al 43%

Las compañías liberan los productos a sus clientes con un 15% de defectosMuchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito

Las compañías liberan los productos a sus clientes con un 15% de defectosMuchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito

© ESI 2008 15

Las cosas “pintan” mejorLas cosas “pintan” mejor

Reducir el número de defectos entregados al cliente en un 95%

Reducir los plazos de desarrollo de software en un 71%

Incrementar la productividad (medida en líneas de código o puntos función por día) en un 222%

Obtener de media un ROI de 5:1Obtener de media un ROI de 5:1

Los programas de mejora de procesos software exitosos permiten:

Sources: Capers Jones and Software Engineering Institute

© ESI 2008 16

Sin embargo...Sin embargo...

Dos tercios de los proyectos de mejora no concluyen con éxito tras una evaluación formal, debido a:

estrategias incorrectasfalta de compromiso falta de seguimientoincapacidad de medir las mejorasobjetivos de mejora no alineados con los objetivos del negocio

Hay algunos problemas en cómo se ejecuta una iniciativa SPI

Source: Herb Krasner

© ESI 2008 17

Largo plaz

oCorto

plazo Directo

Indirecto

Recursos gastados:DineroTiempo

Personas

Objetivo de negociono alcanzado

Sufrimiento moral

Seguridad del trabajo amenazada

Estrategiasno alcanzadas

Menorconfianza en

los líderes

Incremento dela resistencia al cambio

Mayor probabilidadde fallo en futuros cambios

SUPERVIVENCIA

La calidad NO es gratis …• Coste de conformidad

...pero la calidad es más económica que las alternativas• Coste de no-conformidad

Coste de la calidad VS Coste de la no calidadCoste de la calidad VS Coste de la no calidad

© ESI 2008 18

Coste de la Calidad (CoQ)

Crosby describe el Coste de la no-conformidad como aquel coste en el que se incurre porque el producto o servicio no se desarrolló de forma apropiada la primera vez.

Coste de No ConformidadCoste de Conformidad+

= Coste de la CalidadCoste de la Calidad

Fallos internos+ fallos externos

Prevención+ Evaluación

Categorías de coste

© ESI 2008 19

39

20

41New DevelopmentCOCCONC

Fuente: Ratheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017, November 1995

Una experiencia de CoQ ¿A qué dedican su tiempo los ingenieros de SW?

OO¿A qué dedicamos nuestro presupuesto de ingeniería de SW?

© ESI 2008 20

Evolución del CoQ Raytheon

L1 L2 L3

Source: Ratheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017, November 1995

L1 L2 L3

NIVEL CMM

L4

© ESI 2008 21

Mejoras alcanzadas

5821

21

67

23

10

77

176

39

20

41

1988 - CMM Nivel 1 1990 - CMM Nivel 2

1995 - CMM Nivel 4 1992 – CMM Nivel 3

Nuevo desarrolloCoste de conformidad (COC)

Coste de no conformidad (CONC)

Source: Ratheon Electronic Systems Experience in Software Process Improvement, CMU/SEI-95-TR-017, November 1995

ROI 7.7:1, Productividad 140%, $4.48M ahorrados en seis proyectos en un año

© ESI 2008 22

Conceptos Conceptos de gestide gestióón de n de

procesosprocesos

© ESI 2008 23

¿Qué es un Proceso?

¿Cómo define usted un proceso?

© ESI 2008 24

• Un proceso es un conjunto de prácticas que se realizan con un propósito; puede incluir herramientas, métodos, materiales y/o personal.

• Habitualmente se presenta como uno de los componentes de la triada proceso-personas-tecnología, pero también puede considerarse como el “pegamento” que une los demás aspectos.

Definición básica de proceso

© ESI 2008 25

Puntos de apoyo de la calidadPuntos de apoyo de la calidad

SATISFACCISATISFACCIÓÓN DEL N DEL CLIENTECLIENTE

ProductosProductos

PersonasPersonas

TecnologíaTecnologíaProcesoProceso

Todo el mundo entiende la importancia de tener una plantilla de calidad y motivada, pero …

...incluso nuestros mejores empleados no pueden rendir de manera óptima si los procesos no se entienden o no operan de manera óptima.

Principales determinantes del

coste, plazo y calidad del producto

© ESI 2008 26

• Un proceso proporciona un marco disciplinado– … en oposición al foco en personas

• El personal de trabajo es, por término medio, lo “bueno” que la formación recibida le permite ser

• Trabajar más duro no es la respuesta• La respuesta es trabajar de forma más inteligente a través de

procesos

– … en oposición al foco en las tecnologías• Aplicar la tecnología sin objetivos claros no proporciona tantos

beneficios• La tecnología proporciona máximo beneficio cuando se aplica con

un marco de referencia estructurado

¿Por qué centrarnos en los procesos?

© ESI 2008 27

“The quality of a product is largely determined by the quality of the process that is used to develop and maintain it.”

Traducción: La calidad del producto está altamente determinada por la calidad de los procesos usados para su desarrollo y mantenimiento.

Basado en los principios de TQM de Shewhart, Juran, Deming y Humphrey.

Premisa básica de la mejora de procesos

Esfuerzoheroico

Negocio softwaremaduro

¡TÍPICO! Sistema no predecible

PROCESO

PR

OD

UC

TO

Malo Bueno

Bueno

© ESI 2008 28

• Un modelo es una colección estructurada de elementos que describen las características de procesos efectivos

• Los procesos incluidos en un modelo son aquellos que por experiencia demuestran ser efectivos

¿Qué es un modelo de procesos?

© ESI 2008 29

Un modelo proporciona• un punto de partida • los beneficios de experiencias pasadas de la

comunidad• un lenguaje común y una visión compartida• un marco para priorizar mejoras

¿Cuáles son los beneficiosde la mejora basada en modelos?

© ESI 2008 30

• Los modelos son simplificaciones del mundo real

• Los modelos no tienen por qué ser completos

• La interpretación y adaptación debe hacerse en función de los objetivos del negocio

• Se necesita aplicar un juicio profesional para su correcto uso

• Olvidar que:– Un modelo no es un proceso– Un modelo muestra qué hacer, pero NO cómo hacerlo ni

quién ha de hacerlo

¿Cuáles son los riesgos de lamejora basada en modelos?

© ESI 2008 31

Uso del sentido común

“All models are wrong, but some are useful.”Traducción: “Todos los modelos están equivocados, pero algunos son útiles”

– George Box

Aproximaciones simplificadas de la realidad que aportan visión

© ESI 2008 32

VisiVisióón n general de general de CMMICMMI--DEVDEV

© ESI 2008 33Source: 2006 Carnegie Mellon University; CMMI v1.2

CMMI – Historia

© ESI 2008 34

Constelaciones CMMI

Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5

CMMI-DEVProporciona guías

para medir, controlar y

gestionar los procesos de desarrollo

CMMI-ACQproporciona una

guía para habilitar una gestión en adquisiciones informada y

decisiva

CMMI-SVCProporciona guías para aquellos que proveen servicios

dentro de la organización y a clientes externos

16 áreas de proceso

usadas en todos

© ESI 2008 35

Escalonada

ML 1

ML2

ML3

ML4

ML5

. . . para un conjunto definido deáreas de proceso en laorganización

PA PA0

1

2

3

4

5PA

Continua

. . . para una o un conjunto de áreas de proceso

Representaciones del modeloRepresentaciones del modeloRepresentaciones del modelo

Cap

acid

ad d

elÁ

rea

de P

roce

so (P

A)

© ESI 2008 36

• Herencia de modelos anteriores– Software CMM– SECMM– IPD CMM

• Por compatibilidad con el nuevo estándar internacional para evaluación de procesos ISO/IEC 15504 (SPICE)

• En el desarrollo de CMMI participaron equipos procedentes de los modelos anteriores

• Resultaba “muy duro” elegir un único modo de representación

• Desde el comienzo se llegó a un compromiso para apoyar por igual a ambas representaciones

¿Por qué dos representaciones?

© ESI 2008 37

• Proporciona una hoja de ruta para la implementación:– grupos de áreas de proceso– secuencia de implementación

• Resulta familiar a aquellos que migren desde el SW-CMM

Ventajas de la representación Escalonada

© ESI 2008 38

• Proporciona flexibilidad para poder centrarse en áreas de proceso específicas, en línea con objetivos y metas de negocio

• Resulta familiar a aquellos que migren desde la comunidad de ingeniería de sistemas

• Compatible con el modelo de referencia SPICE

Ventajas de la representación Continua

PA PA

0

1 2

3

4

5

PA

© ESI 2008 39

Proceso impredecible, poco controlado

Proceso definido caracterizado para proyectos y frecuentemente reactivo

Proceso definido para la organización y proactivo

El proceso se controla cuantitativamente

Foco en la mejora continua

5. En optimización

4. Gestionado cuantitativamente

3. Definido

1. Inicial

2. Gestionado

1

2

3

4

5

Los niveles de madurez

© ESI 2008 40

NIVEL FOCO AREAS DE PROCESO Calidad

5 En optimización Mejora continua del proceso

Innovación y despliegue organizativoAnálisis causal

Productividad

Riesgo

4

Retrabajo

Gestión cuantitativa

Rendimiento de procesos organizativosGestión de proyectos cuantitativa

3

Gestionado cuantitativamente

Definido

Gestionado

Estandarización del proceso

Desarrollo de requerimientosSolución técnicaIntegración de productoVerificaciónValidaciónFoco en proceso organizativoDefinición de proceso organizativo + IPPDEntrenamiento organizativo Gestión de proyecto integrada + IPPDGestión de riesgosAnálisis de decisiones y soluciones

2 Gestión de proyectos básica

Gestión de requerimientos Planificación de proyectoSeguimiento y control de proyectoGestión de acuerdos con proveedoresMedición y análisisAseguramiento de la calidadGestión de la configuración

1 Sin áreas de proceso – ¡el trabajo se realiza de alguna manera!Inicial

© ESI 2008 41

Esperado

Obligatorio

Nivel de Madurez

Área de Proceso Área de Proceso Área de Proceso

Metas Genéricas

MetasEspecíficas

PrácticasGenéricas

PrácticasEspecíficas

Estructura del modelo CMMI

© ESI 2008 42

• Un Área de Proceso (PA) es un grupo de prácticas relacionadas que colectivamente ayudan a alcanzar un conjunto de metas

• Son los bloques fundamentales que permiten establecer la capacidad del proceso de una organización

• Cada área de proceso reside en un nivel de madurez

Áreas de Proceso

© ESI 2008 43

• Metas y Prácticas Específicas

– indican qué debe ser implantado para cadaÁrea de Proceso

– por lo tanto, son específicas de cada Área de Proceso

• Metas y Prácticas Genéricas

– indican qué debe ser implantado para institucionalizarcada Área de Proceso

– por lo tanto, son aplicables para todas las Áreas deProceso

Tipos de metas y prácticas

© ESI 2008 44

• Meta Genérica (del Nivel de Madurez 2)– Institucionalizar un Proceso Gestionado

• 10 prácticas genéricas para las Áreas de Proceso del nivel 2

• Meta Genérica (del Nivel de Madurez 3)– Institucionalizar un Proceso Definido

• 2 prácticas genéricas adicionales que se aplican a todas las Áreas de Proceso de los niveles 2 y 3

Metas Genéricas

Los Niveles de Madurez 4 y 5 heredan las Metas y Prácticas Genéricas de los niveles de madurez 2 y 3

Los Niveles de Madurez 4 y 5 heredan las Metas y Prácticas Genéricas de los niveles de madurez 2 y 3

© ESI 2008 45

Resumen CMMI-DEVEscalonada Continua

PA PA

Cap

acid

ad0

1

2

3

4

5

ProcesoPA

ML 1

ML2

ML3

ML4

ML5

Organización

Nivel Madurez 5 OID, CARNivel Madurez 5 OID, CAR

Nivel Madurez 4 OPP, QPMNivel Madurez 4 OPP, QPM

Nivel Madurez 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR

Nivel Madurez 3 RD, TS, PI, VER, VAL, OPF, OPD, OT, IPM, RSKM, DAR

Nivel Madurez 2 REQM, PP, PMC, MA, PPQA, CM, SAMNivel Madurez 2 REQM, PP, PMC, MA, PPQA, CM, SAM

Áreas de procesoInnovación y Despliegue Organizativo (OID)Análisis Causal (CAR)

Rendimiento de Procesos Organizativos (OPP)Gestión de Proyectos Cuantitativa (QPM)

Desarrollo de Requisitos (RD)Solución Técnica (TS)Integración de Producto (PI)Verificación (VER)Validación (VAL)Foco en Proceso Organizativo (OPF)Definición de Proceso Organizativo + IPPD (OPD)Formación Organizativa (OT)Gestión de Proyecto Integrada + IPPD (IPM)Gestión del Riesgo (RSKM)Análisis de Decisiones y Soluciones (DAR)

Gestión de Requisitos (REQM)Planificación de Proyecto (PP)Seguimiento y Control de Proyecto (PMC)Gestión de Acuerdos con Proveedores (SAM)Medición y Análisis (MA)Aseguramiento Calidad Proceso Producto (PPQA)Gestión Configuración (CM)

SoporteCM, PPQA, MA,

CAR, DAR

SoporteSoporteCM, PPQA, MA,

CAR, DAR

IngenieríaREQM, RD, TS, PI, VER, VAL

IngenierIngenierííaaREQM, RD, TS, PI, VER, VAL

Gestión Proyecto

PP, PMC, SAM, IPM, RSKM, QPM

GestiGestióón n ProyectoProyecto

PP, PMC, SAM, IPM, RSKM, QPM

Gestión Proceso

OPF, OPD, OT, OPP, OID

GestiGestióón n ProcesoProceso

OPF, OPD, OT, OPP, OID

© ESI 2008 46

ÁÁreas de reas de proceso de proceso de CMMICMMI--DEVDEV

© ESI 2008 47

Nivel de Madurez 1: Inicial

Se ejecutan procesos pero sin formalismo y en ocasiones de manera caótica.Los resultados dependen de esfuerzos heroicos y de lo competente de las personasEs posible conseguir calidad y resultados excepcionales, siempre que se asignen las mejores personas a las tareasEs difícil predecir los resultadosLas prácticas de gestión pueden no ser eficaces

© ESI 2008 48

Resultados impredecibles

Entran los requisitosEl producto se desarrolla siguiendo algún tipo de proceso “amorfo”Salen los productos (quizás no todos) y se espera que funcionen

In Out

© ESI 2008 49

• Gestión de proyectos disciplinada• Se establecen y siguen políticas organizativas• Se documentan y siguen planes de proyecto y descripciones

de procesos• Los recursos son los adecuados (humanos, materiales)• Se asignan responsabilidades y autoridades a lo largo de la

vida del proyecto• Éxitos pasados se espera puedan repetirse en nuevos

proyectos similares• La disciplina ayuda a mantener las prácticas existentes en

tiempos de estrés• La Dirección tiene visibilidad sobre el estado de las

actividades y los productos en puntos definidos

Nivel de Madurez 2: Gestionado2

© ESI 2008 50

In Out

Entran los requisitosSe desarrollan planes de acuerdo a las políticasLas actividades se llevan a cabo de acuerdo a los planesSe realizan mediciones y revisiones en puntos definidosSalen los productos y (normalmente) funcionan

El proceso es “Gestionado”

© ESI 2008 51

Gestión de RequisitosPlanificación de ProyectoSeguimiento y Control de ProyectoGestión de Acuerdos con ProveedoresMedición y AnálisisAseguramiento de la Calidad de Proceso y ProductoGestión de la Configuración

En optimización

Definido

Inicial

Gestionado

GestionadoCuantitativamente

Áreas de Proceso en el Nivel de Madurez 2

© ESI 2008 52

El propósito de la Gestión de Requisitos (REQM) es gestionar los requisitos de los productos del proyecto y los componentes del producto, e identificar inconsistencias entre dichos requisitos y los planes de proyecto y productos de trabajo.

ALSG SG1: Gestionar Requisitos Se gestionan los requisitos y se identifican las inconsistenciascon los planes de proyecto y productos de trabajo.

Gestión de Requisitos

© ESI 2008 53

Planificación del Proyecto

El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan las actividades del proyecto.

ALSG SG1: Establecer EstimacionesSe establecen y mantienen estimaciones de los parámetros de planificación del proyecto.

SG2: Desarrollar un Plan de ProyectoSe establece y mantiene un plan de proyecto que se usarácomo base para su gestión.

SG3: Obtener Compromisos con el PlanSe establecen y mantienen compromisos con el plan de proyecto.

© ESI 2008 54

Seguimiento y Control del Proyecto

El propósito del Seguimiento y Control del Proyecto (PMC) es dar a conocer el progreso del proyecto, de manera que se puedan tomar las apropiadas acciones correctivas cuando el rendimiento del proyecto se desvía significativamente respecto del plan.

ALSG SG1: Dar Seguimiento al Proyecto respecto del PlanLos resultados actuales y el progreso del proyecto son supervisados respecto del plan de proyecto.

SG2: Gestionar y Cerrar Acciones CorrectivasSe gestionan hasta su cierre las acciones correctivas cuando los resultados del proyecto se desvían significativamente respecto del plan.

© ESI 2008 55

Gestión de Acuerdos con Proveedores

El propósito de la Gestión de Acuerdos con Proveedores (SAM) es gestionar la adquisición de productos de proveedores.

ALSG SG1: Establecer Acuerdos con ProveedoresSe establecen y mantienen acuerdos con proveedores.

SG2: Satisfacer los Acuerdos con ProveedoresLos acuerdos con proveedores son satisfechos por ambas partes, el proyecto y el proveedor.

© ESI 2008 56

Medición y Análisis

El propósito de la Medición y Análisis (MA) es desarrollar y mantener una capacidad de medición que sea utilizada para apoyar las necesidades de información de gestión.

ALSG SG1: Alinear las Actividades de Medición y AnálisisLos objetivos y actividades de medición se alinean con los objetivos y necesidades de información identificados.

SG2: Proporcionar los Resultados de MedicionesSe proporcionan los resultados de las mediciones, reflejo de los objetivos y necesidades de información identificados.

© ESI 2008 57

Aseguramiento de la Calidad de Proceso y Producto

El propósito del Aseguramiento de la Calidad de Proceso y Producto(PPQA) es proporcionar a la Dirección y al resto del personal una visión objetiva de los procesos y los productos de trabajo asociados.

ALSG SG1: Evaluar Objetivamente Procesos y Productos de trabajoSe evalúa de forma objetiva que los procesos implantados y los productos/servicios asociados se adhieren a las descripciones de proceso, estándares y procedimientos aplicables.

SG2: Proporcionar Visibilidad ObjetivaLas no conformidades son supervisadas y comunicados con objetividad, asegurando su resolución.

© ESI 2008 58

Gestión de la Configuración

El propósito de la Gestión de la Configuración (CM) es establecer y mantener la integridad de los productos de trabajo utilizando laidentificación, control, contabilidad de estado y auditorías de la configuración.

ALSG SG1: Establecer líneas base Se establecen líneas base de los productos de trabajo identificados.

SG2: Dar seguimiento y Controlar CambiosSe da seguimiento y se controlan los cambios a los productos de trabajo puestos bajo gestión de la configuración.

SG3: Establecer IntegridadSe establece y mantiene la integridad de las líneas base.

© ESI 2008 59

• Este nivel se construye sobre los cimientos de la gestión de proyectos establecida en el nivel 2– Los procesos de ingeniería se implantan con

mayor efectividad– La organización es más proactiva– Se identifican y resuelven las necesidades de

formación• La organización dispone de un conjunto de procesos

estándares, que cada proyecto particular puede adaptar en función de sus necesidades

Nivel de Madurez 3: Definido 3

© ESI 2008 60

La similitud entre proyectos permite estimar de manera más uniforme el rendimiento del proyecto y los resultados esperados.

In Out

Gestionado siguiendo un Proceso Definido

© ESI 2008 61

Desarrollo de RequisitosSolución TécnicaIntegración de ProductoVerificaciónValidaciónFoco en Proceso OrganizativoDefinición de Proceso Organizativo + IPPDFormación OrganizativaGestión de Proyecto Integrada + IPPDGestión del RiesgoAnálisis de Decisiones y Soluciones

Definido

En Optimización

Inicial

Gestionado



© ESI 2008 62

Desarrollo de RequisitosEl propósito del Desarrollo de Requisitos (RD) es producir y analizar los requisitos del cliente, del producto, y de los componentes del producto.

ALSG SG1: Desarrollar Requisitos del Cliente Se recogen las necesidades, expectativas, restricciones e interfaces de los agentes afectados, y se transforman en requisitos del cliente.

SG2: Desarrollar Requisitos del ProductoSe refinan y elaboran los requisitos del cliente, para desarrollar los requisitos del producto y de sus componentes.

SG3: Analizar y Validar RequisitosSe analizan y validan los requisitos, y se desarrolla una definición de la funcionalidad requerida.

© ESI 2008 63

Solución TécnicaEl propósito de la Solución Técnica (TS) es diseñar, desarrollar e implementar soluciones a los requisitos. Las soluciones, diseños e implementaciones incluyen productos, componentes y procesos relacionados con el ciclo de vida del producto.

ALSG SG1: Seleccionar Soluciones para componentes Se seleccionan soluciones para el producto o sus componentes, entre diferentes soluciones alternativas.

SG2: Desarrollar el DiseñoSe desarrolla el diseño del producto o de sus componentes.

SG3: Implementar el Diseño del ProductoSe implementan, a partir de los diseños, los componentes del producto y la documentación de apoyo asociada.

© ESI 2008 64

Integración de ProductoEl propósito de la Integración de Producto (PI) es ensamblar el producto a partir de sus componentes, asegurar que el producto funciona adecuadamente, y entregar el producto.

ALSG SG1: Preparar la Integración del ProductoSe lleva a cabo la preparación de la integración del producto.

SG2: Asegurar la Compatibilidad de InterfacesSe asegura que las interfaces entre componentes del producto, tanto internas como externas, son compatibles.

SG3: Ensamblar los Componentes y Entregar el ProductoLos componentes, una vez verificados, son ensamblados; y el producto, una vez integrado, verificado y validado, es entregado.

© ESI 2008 65

VerificaciónEl propósito de la Verificación (VER) es asegurar que los productos de trabajo seleccionados cumplen con los requisitos especificados.

ALSG SG1: Preparar la VerificaciónSe lleva a cabo la preparación de la verificación.

SG2: Realizar Peer Reviews Se realizan Peer Reviews para los productos de trabajo seleccionados.

SG3: Verificar Productos de Trabajo seleccionadosSe verifican los productos de trabajo seleccionados frente a los requisitos especificados.

© ESI 2008 66

Validación

ALSG SG1: Preparar la ValidaciónSe lleva a cabo la preparación de la validación.

SG2: Validar el Producto o los ComponentesEl producto o sus componentes son validados para asegurar que pueden ser utilizados adecuadamente en el entorno de producción previsto.

El propósito de la Validación (VAL) es demostrar que un producto o un componente funciona adecuadamente cuando se instala en el entorno previsto.

© ESI 2008 67

Verificación vs. Validación

VERIFICACIÓN ¿Hemos construido el softwarecorrectamente?

Ingeniería SQA (Aseguramiento de la Calidad de Software)

Planes de prueba

Documentosde diseño

Software

Requisitossoftware

VALIDACIÓN ¿Hemos construido el softwarecorrecto?

Requisitosde Usuario

Pruebas de aceptación

UsuarioCliente

Manual de Usuario

Sistema Software

© ESI 2008 68

Enfoque al Proceso OrganizativoEl propósito del Enfoque al Proceso Organizativo (OPF) es planificar, implementar y desplegar la mejora de procesos organizativa a través de un estudio profundo de las fortalezas y debilidades actuales de los procesos y activos de procesos de la organización.

ALSG SG1: Determinar Oportunidades de Mejora de ProcesosSe identifican periódicamente y cuando es necesario, las fortalezas, debilidades y oportunidades de mejora para los procesos de la organización.

SG2: Planificar e Implantar las Mejoras de ProcesosSe planifican e implementan las acciones que abordan la mejora de los procesos y activos de procesos de la organización.

SG3: Desplegar Activos de Proceso Organizativos e Incorporar Lecciones AprendidasSe despliegan los activos de proceso organizativos a lo largo de la organización, y las experiencias de uso de los procesos son incorporadas a los activos organizativos.

© ESI 2008 69

Definición del Proceso Organizativo + IPPD

El propósito de la Definición del Proceso Organizativo (OPD) es establecer y mantener un conjunto útil de activos de proceso organizativo y de estándares de entorno de trabajo.

ALSG SG1: Establecer Activos de Proceso OrganizativosSe establece y mantiene un conjunto de activos de proceso organizativos.

Adicional para IPPD:SG2: Preparar la Gestión IPPDSe proporcionan reglas y directivas organizativas, las cuales gobiernan la operativa de los equipos integrados.

© ESI 2008 70

Formación OrganizativaEl propósito de la Formación Organizativa (OT) es desarrollar las habilidades y el conocimiento del personal, para que puedan desempeñar sus roles de manera efectiva y eficiente.

ALSG SG1: Establecer una Capacidad de Formación OrganizativaSe establece y mantiene una capacidad de formación que apoya los roles técnicos y gerenciales de la organización.

SG2: Proporcionar la Formación NecesariaSe proporciona la formación necesaria para que los individuos lleven a cabo sus roles con efectividad.

© ESI 2008 71

Gestión Integrada de Proyecto + IPPD

El propósito de la Gestión Integrada de Proyecto (IPM) es establecer y gestionar el proyecto y la involucración de los agentes relevantes de acuerdo a un proceso definido e integrado que está adaptado a partir del conjunto de procesos estándares de la organización.

ALSG SG1: Usar el Proceso Definido del ProyectoEl proyecto es conducido utilizando un proceso definido que ha sido adaptado a partir del conjunto de procesos estándares de la organización.

SG2: Coordinar y Colaborar con los Agentes RelevantesEl proyecto se coordina y colabora con los agentes relevantes.

Adicional para IPPD:SG3: Aplicar los Principios IPPDEl proyecto se gestiona utilizando los principios para IPPD.

© ESI 2008 72

Evolución de la gestión de proyectos

Plan de desarrollo de software

Requisitos del cliente

Conjunto de procesos estándar de la organización

Proceso definido del proyecto

Lecciones Aprendidas

Guías de adaptación

Proporciona la base para

Requisitos de la organización

Gestión de proyectos de nivel 2

© ESI 2008 73

Gestión del RiesgoEl propósito de la Gestión del Riesgo (RSKM) es identificar problemas potenciales antes de que ocurran, de manera que las actividades de gestión del riesgo puedan ser planificadas y activadas a tiempo a lo largo de la vida del producto o proyecto, para mitigar impactos adversos sobre los objetivos a alcanzar.

ALSG SG1: Preparar la Gestión del RiesgoSe lleva a cabo la preparación de la gestión del riesgo.

SG2: Identificar y Analizar RiesgosSe identifican y analizan riesgos, para determinar su importancia.

SG3: Mitigar RiesgosCuando resulta necesario, se gestionan y mitigan los riesgos para reducir impactos adversos sobre los objetivos a alcanzar.

© ESI 2008 74

Análisis de Decisiones y SolucionesEl propósito del Análisis de Decisiones y Soluciones (DAR) es analizar posibles decisiones utilizando un proceso de evaluación formal, que evalúa alternativas siguiendo criterios establecidos.

ALSG SG1: Evaluar AlternativasLas decisiones se basan en la evaluación de alternativas, utilizando criterios establecidos.

© ESI 2008 75

Nivel de Madurez 4: Gestionado Cuantitativamente

4

Los proyectos utilizan objetivos medibles para cumplir las necesidades de los clientes, de los usuarios finales y de la organización.

Directivos e ingenieros utilizan datos estadísticos y otras técnicas cuantitativas para gestionar los procesos y sus resultados.

Se utilizan dichas técnicas a nivel organizativo y de proyectos para:– comprender anteriores: rendimientos de proceso,

calidad de producto y calidad de servicio– predecir futuros: rendimientos de proceso, calidad de

producto y calidad de servicio

© ESI 2008 76

Los niveles de madurez 2 y 3 establecen los cimientos necesarios para la gestión cuantitativa, a través de:– procesos definidos que:

aseguran consistencia en la organizaciónproporcionan una comprensión cualitativa de los sub-procesos y sus relaciones

– mediciones comunes que permiten acumular datos significativos de toda la organización

En el nivel de madurez 3, se recogen y analizan mediciones para entender y gestionar las actividades y sus resultados:– Se establecen umbrales, pero sin usar métodos estadísticos

o cuantitativos– Cuando los umbrales se superan, se activan acciones

El Camino al Nivel de Madurez 4 4

© ESI 2008 77

El comportamiento y rendimiento del proceso es predecible y comprendido cuantitativamente.

Existe una base cuantitativa para la toma de decisiones que permite alcanzar los objetivos establecidos para los procesos, la calidad del producto y la calidad del servicio.

In Out

Proceso Gestionado Cuantitativamente

© ESI 2008 78

Rendimiento de Procesos Organizativos

Gestión de Proyectos Cuantitativa


Definido

En Optimización

Inicial

Gestionado


© ESI 2008 79

Rendimiento de Procesos Organizativos Rendimiento de Procesos Organizativos

El propósito del Rendimiento de Procesos Organizativos (OPP) es establecer y mantener un entendimiento cuantitativo del rendimiento del conjunto de procesos estándar de la organización como soporte a los objetivos de calidad y de rendimiento de procesos, y para proporcionar datos del rendimiento de los procesos, líneas base, y modelos para gestionar cuantitativamente los proyectos de la organización.

ALSG SG 1: Establecer Líneas base y Modelos de RendimientoSe establecen y mantienen líneas base y modelos que caracterizan el rendimiento esperado del conjunto de procesos estándar de la organización.

© ESI 2008 80

Gestión de Proyectos Cuantitativa Gestión de Proyectos Cuantitativa

El propósito de la Gestión de Proyectos Cuantitativa (QPM) es gestionar cuantitativamente los procesos definidos en el proyecto para alcanzar los objetivos de calidad y de rendimiento de procesos establecidos para el proyecto.

ALSG SG 1: Gestionar el Proyecto CuantitativamenteEl proyecto se gestiona cuantitativamente utilizando objetivos de calidad y de rendimiento de procesos.

SG 2: Gestionar Estadísticamente el Rendimiento de los SubprocesosSe gestiona estadísticamente el rendimiento de los subprocesos seleccionados dentro del proceso definido para el proyecto.

© ESI 2008 81

Nivel de Madurez 5: En Optimización

5

Se identifican, evalúan y despliegan mejoras incrementales e innovadoras que incrementan (de forma medible) las capacidades de los procesos.

Tanto los procesos empleados por los proyectos como los procesos estándares de la organización son objetivo de las actividades de mejora.

Se establecen objetivos de mejora cuantitativos para la organización, y se revisan continuamente para reflejar los cambios que se puedan producir en los objetivos de negocio.

© ESI 2008 82

En el nivel de madurez 4los análisis se dirigen a conocer y resolver las causas especiales de variación de los procesos

las mediciones se analizan para fijar objetivos y requisitos de calidad de producto/servicio y para los procesos

En el nivel de madurez 5los análisis se dirigen a conocer y resolver las causas comunes de variación de los procesos

se utilizan mediciones para:

seleccionar mejoras e innovaciones

estimar los costes y beneficios de las mejoras e innovaciones

medir los costes y beneficios actuales de las mejoras e innovaciones

El Camino al Nivel de Madurez 5 5

© ESI 2008 83

La mejora de procesos continua y medible (en tanto que se gestiona la estabilidad de los procesos) forma parte del día a día

In Out

Procesos en Optimización

© ESI 2008 84

New zone ofquality control

QualityImprovement

Zona inicial decontrol de la calidad

Pérdida crónica

Diagrama de control de la capacidad

Mejora dela calidad

Nueva zona decontrol

Pérdida crónicase ha reducido

La mejora continua significa mejorar la capacidad medible de los procesos de manera controlada

Foco en la Mejora Continua

© ESI 2008 86

Innovación y Despliegue OrganizativoInnovación y Despliegue Organizativo

El propósito de la Innovación y Despliegue Organizativo (OID) es seleccionar y desplegar mejoras incrementales e innovadoras que de forma medible mejoren las tecnologías y procesos de la organización.Las mejoras apoyan los objetivos de calidad y de rendimiento de procesos derivados de los objetivos de negocio de la organización.

ALSG SG 1: Seleccionar MejorasSe seleccionan mejoras de proceso y mejoras tecnológicas que contribuyen a cubrir los objetivos de calidad y de rendimiento de procesos.

SG 2: Desplegar MejorasSe despliegan de forma continua y sistemática mejoras medibles en los procesos y tecnologías de la organización.

© ESI 2008 87

Análisis Causal y SolucionesAnálisis Causal y Soluciones

El propósito del Análisis Causal y Soluciones (CAR) es identificar las causas de los fallos y de otros problemas y tomar acciones para prevenir que sucedan en el futuro.

ALSG SG 1: Determinar Causas de FallosSe determinan sistemáticamente las causas raíz de los fallos y de otros problemas.

SG 2: Abordar Causas de FallosSe abordan sistemáticamente las causas raíz de los fallos y otros problemas para evitar que sucedan en el futuro.

© ESI 2008 90

• Establecer los objetivos de negocio• Identificar principales problemas a resolver• Obtener compromiso y patrocinio de la Dirección• Entrenarse/Informarse sobre métodos de mejora • Comunicar la iniciativa a la organización

InicioInicio

• Desarrollar planes– Plan estratégico de mejora de procesos

• Establecer metas de mejora• Desarrollar planes tácticos para abordar las

recomendaciones

EstablecerEstablecer

• Establecer la línea base de madurez de la organización– Identificar fortalezas– Identificar áreas de mejora

• Definir recomendaciones de mejora

DiagnósticoDiagnóstico

IDEAL – Establecer metas

© ESI 2008 91

• Definir procesos de software• Definir mediciones• Pilotar nuevos procesos y mediciones• Institucionalizar procesos y mediciones

ActuarActuar

• Identificar lecciones aprendidas• Analizar lecciones aprendidas• Medir esfuerzo dedicado respecto a los

objetivos de negocio• Reforzar compromiso y patrocinio• Planificar siguiente ciclo de mejora

AprenderAprender

IDEAL – Alcanzar las metas

© ESI 2008 92

• Appraisal Requirements for CMMI (ARC v1.1) = Requisitos de Evaluación para CMMI– Guía establecida para desarrolladores de métodos de

evaluación – Especifica los requisitos para las distintas clases de

métodos de evaluación• Clase A: método de evaluación completo e intensivo• Clase B: auto-evaluaciones, iniciales e incrementales • Clase C: vista rápida

Evaluaciones CMMI

© ESI 2008 93

Quién es quién en la mejora

GrupoDirectivo

SEPGGrupo de Procesos

de Ingeniería de Software

Grupo detrabajo

Equipo DirectivoGerencia mediaRepresentante del SEPG

Responsables de proyectosResponsables de tareas

Personal seniorRepresentante de SEPG

© ESI 2008 94

Responsabilidades delGrupo Directivo

• Alinea el esfuerzo de la mejora con la visión y misión organizativos

• Proporciona recursos y asegura la redistribución del trabajo

• Da seguimiento a los resultados de la implementación y ejecuta acciones correctivas

© ESI 2008 95

Responsabilidades del SEPG

• Facilita la mejora de procesos a través de los diversos niveles de la organización

• Da seguimiento e informa sobre los progresos

• Es el punto de referencia del aprendizaje organizativo

• Da formación, consultoría y apoyo

© ESI 2008 96

Responsabilidades de los Grupos de Trabajo

• Se centran en la mejora de un proceso, de acuerdo a las asignaciones efectuadas por el Grupo Directivo

• Describen y documentan el proceso actual• Identifican los cambios a realizar al proceso actual• Testean los procesos mejorados en proyectos piloto• Documentan el proceso mejorado• Desarrollan planes de despliegue e institucionalización• Entregan los procesos mejorados al Grupo Directivo

para el desarrollo de políticas

© ESI 2008 97

C

Clase C: Acercamiento• Puede adoptar una amplia variedad

de formas • Puede limitar la investigación a un

“acercamiento” al realizar el examen de los procesos

Clase B: Despliegue• Es más riguroso respecto al tipo y

número de evidencias examinadas• Puede limitar la investigación al

“despliegue” al examinar los procesos que estén implementados

Clase A: Institucionalización

breadth of tailoring

Clases de métodos de evaluación - I

B

A

depth of investigation

• es el método de evaluación más riguroso• se centra en cómo se ha realizado la implementación y se examina el nivel de institucionalización de las prácticas desplegadas

© ESI 2008 98

Clases de métodos de evaluación - IICaracterísticas Clase A Clase B Clase CNº de evidencias objetivas recopiladas

Alto(3 fuentes)

Medio(2 fuentes)

Bajo(1 fuente)

Puntuaciones generadas

Sí No No

Tiempo de actividades on-site (ML2)

Alto(~2 semanas)

Medio(~1 semana)

Bajo(~1-2 semanas)

Tamaño del equipo Grande(> 4 personas)

Medio(2 personas)

Bajo(1 persona)

Requisitos del Líder del Equipo de Evaluación

Lead appraiser Lead appraiser o persona formada y con experiencia

Persona formada y con experiencia

Extracted from Appraisal Requirements for CMMI, Version 1.1 (ARC) (CMU/SEI-2001-TR-034)

© ESI 2008 100

• Un modelo CMMI proporciona un enfoque disciplinado para mejorar los procesos de una organización

• CMMI puede ayudar a– establecer objetivos de mejora y

prioridades– proporcionar guías para implantar

procesos de calidad– proporcionar un marco de referencia para

evaluar las prácticas actuales

Motivación para CMMI-DEV

© ESI 2008 101

• La mejora de procesos debería llevarse a cabo para mejorar el negocio, y no como un objetivo en sí mismo

• Mejorar tiene diferentes connotaciones para cada organización– ¿cuáles son sus objetivos de negocio?– ¿cómo mide su progreso/consecución?

• La mejora es un esfuerzo estratégico a largo plazo– ¿cuál es el impacto esperado en la

organización?– ¿cómo se medirá el impacto?

“In God we trust, all others bring data.”

- W. Edwards Deming

Las premisas a considerar

© ESI 2008 102

• Los beneficios de la mejora de procesos pueden clasificarse en las siguientes categorías:– tener calendarios y presupuestos más predecibles– mejorar tiempos de desarrollo– mejorar la productividad– mejorar la calidad (medida en número de defectos)– mejorar la satisfacción del cliente– mejorar la moral de los empleados– reducir el coste de la calidad– incrementar el retorno de la inversión

Beneficios de la mejora de procesos

© ESI 2008 103

¿Dónde aplica CMMI-DEV?

• CMMI-DEV ha sido desarrollado para proporcionar buenas prácticas de gestión y de ingeniería para cualquier proyecto de desarrollo y cualquier entorno.– modelo descrito jerárquicamente – los componentes del CMMI-DEV son niveles de madurez,

niveles de capacidad, áreas de proceso y metas

• Las metas son “requeridas”• ¡Las prácticas de CMMI-DEV son “esperadas”, pero

prácticas alternativas son perfectamente aceptables!

© ESI 2008 104

“Qué” Versus “Cómo”

• El propósito de CMMI-DEV es:– descriptivo de las prácticas de ingeniería del

software y de gestión– prescriptivo en cuanto a las prioridades para la

mejora de procesos

• Las áreas de proceso describen el “qué” no el “cómo”

© ESI 2008 105

Usando CMMI-DEV correctamenteUsando CMMI-DEV correctamente• El uso correcto de CMMI-DEV implica:

– reflejar la realidad de su entorno de negocio• ajustar (interpretar) el CMMI-DEV para adaptarlo

al contexto y necesidades de la organización• Teniendo en cuenta un juicio profesional

– identificar problemas de forma objetiva– pensar y analizar cómo aplica CMMI-DEV

• ejecutando y no sólo pensando!• no tomando decisiones imprudentes!

– apoyar la participación de los trabajadores

© ESI 2008 106

Obligar a seguir procesos definidos sin la contribución de sus verdaderos propietarios – sus usuarios

Verificar la conformidad de la organización contra las prácticas y subprácticas

No escuchar los problemas de la organización

No interpretar el contexto y la realidad de la organización

No ser capaces, o lo que es peor, no querer interpretar, adaptar o aplicar un juicio profesional en la organización

Uso inadecuado del CMMI

© ESI 2008 107

El modelo CMMI es una herramienta para mejorar → Pero, de la misma manera que un mapa no sirve sin un destino, el modelo CMMI necesita construirse alrededor de su negocio y de sus objetivosEl modelo CMMI no es una certificación → Ayuda a encontrar los huecos que existen entre la manera de trabajar y la manera en laque se debería trabajar. El modelo CMMI no describe procesos! Define el qué pero no el cómo!→ Falla si no se refuerza y usa apropiadamente. Tiene éxito si es propiedad de los grupos que lo utilizan.Junto con el modelo SW-CMM, está probado en la industria que mejora la madurez y el rendimiento de las organizaciones → Pero no compensa una mala gestión o decisiones estratégicas equivocadas.

Qué es y qué no es CMMI

© ESI 2008 108

Mejora de los Procesos Software (SPI)

actividad continuaesfuerzo de equipo

modelo de referencia

medición cuantitativa

compromiso de la dirección

dirigidos por las necesidades de negocio

requiere una inversión de tiempo

© ESI 2008 109

Estrategia de despliegue

Resistencia al cambio

Estrategia para la mejora – ¿Algún eslabón perdido?

informationtargets action plan abilities resources incentives+ + + + + =

informationtargets action plan abilities resources incentives+ + + + + = Éxito

Source: Motorola University

informationtargets abilities resources incentives+ + + + + =informationtargets action plan resources incentives+ + + + + = Miedo

informationtargets action plan abilities incentives+ + + + + = Frustración

informationtargets action plan abilities resources+ + + + + =targets action plan abilities resources incentives+ + + + + = Caos

informationabilities resources incentives+ + + + + = Indecisiónaction plan

Ejecucióndificultosa

© ESI 2008 110

Burocracia sin sentido Caos total

Calidad Caos Creativo

Proceso documentadoSe

ntid

o C

omún

NoSiSi

No

… sin perder nunca de vista nuestro objetivo

Hagamos prevalecer el sentido común..

© ESI 2008 111

¿La cuestión es cómo?En términos sencillos – los 3 aspectos clave para el éxito son:

Entender las expectativas de los clientes y el mercado

Posicionarse adecuadamente frente a los competidores

Conocer y mejorar nuestra propia capacidad

El objetivo es ser más competitivo

visión general de cmmi for development

Documents