mejora de procesos general v3.ppt [modo de … · • capability maturity model integration (cmmi)...

Por qué la mejora Por qué la mejora de procesos de de procesos de

© ESI 2010 1

de procesos de de procesos de softwaresoftware

Valencia, 21 de Abril de 2009

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

AgendaAgenda

1. Motivación para la Mejora de Procesos

2. Modelos de Mejora de Procesos

– CMMI®

© ESI 2010 2

– CMMI®

– ISO/IEC-15504 (SPICE)

– ITMark®

– ISO/IEC-20000

3. Beneficios y Conclusiones

1. Motivación

© ESI 2010 3

1. Motivación para la mejora

de procesos

Software is everywhere

© ESI 2010 4

Fuente: Paul Nielsen, SEI 2007

Ejemplo del Crecimiento del Software

© ESI 2010 5

1990: 1 millón de líneas de código

2010: 100 millones de líneas de código

Fuente: Paul Nielsen, SEI 2007

ITEA: el volumen de embeddedsoftware se duplica cada 2 años

Windows 2000: 35 M LOCWindows XP: 40 M LOCDebian 3.1: 230 M LOC

Impacto del Software

• Se achaca a las TIC el 45% del aumento de la productividad, y el 25% del aumento del PIB en Europa

• Fundación BBVA “Impacto de las TIC en el crecimiento económico español” (03/2007): relaciona productividad y

© ESI 2010 6

gasto en TIC

• Plan Avanza: Objetivo TIC el 7% PIB en 2010

¿Qué está sucediendo?¿Qué está sucediendo?

Éxitosos35%Problemáticos

46%

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%

© ESI 2010 7

Source: Standish Group Chaos Report - 2006

Fallidos(Cancelados)

19%

Definiciones

ÉxitososEn tiempo, en presupuesto, en funcionalidad prometida

ProblemáticosTarde, sobrepasado el presupuesto, falta funcionalidad

Fallidos Proyectos cancelados

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

Estamos mejorando, pero…Estamos mejorando, pero…

Éxitosos 16%


31%

Problemáticos53%

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

© ESI 2010 8

31%

Éxitosos 35%


19%

Problemáticos46%

2006 Chaos Report

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

CALIDAD CALIDAD –– Bill Gates en COMDEXBill Gates en COMDEX

� Si la General Motors pudiese tener un desarrollo tecnológico comparable al de la industria TIC, hoy conduciríamos todos autos

© ESI 2010 9

industria TIC, hoy conduciríamos todos autos de $25 que recorrerían 1.000 millas con un galón de combustible

CALIDAD CALIDAD –– Respuesta de Rick Wagoner (1/2)Respuesta de Rick Wagoner (1/2)

� Su coche tendría 2 accidentes al día sin causa explicable

� Cada vez que se pintasen las líneas de la carretera deberíacomprar un coche nuevo

Si GM se hubiese desarrollado como Microsoft, hoy:

© ESI 2010 10

� De vez en cuando su coche se saldría de la carretera sin causaexplicable; usted lo aceptaría, arrancaría de nuevo y seguiríaconduciendo

� Si al hacer una determinada maniobra su coche se detuviese y senegase a arrancar de nuevo, se vería obligado a instalar un nuevomotor en el coche

� Sólo se podría sentar usted en su coche, aunque podría adquirirCar95 o Car2000 y pagar por los asientos adicionales

� El indicador de aceite, el de exceso de temperatura y el de bateríase reemplazarían por una lámpara general de fallo del vehículo

� El sistema Airbag le preguntaría “¿Está usted seguro?” antes de

Si GM se hubiese desarrollado como Microsoft, hoy:

CALIDAD CALIDAD –– Respuesta de Rick Wagoner (2/2)Respuesta de Rick Wagoner (2/2)

© ESI 2010 11

� El sistema Airbag le preguntaría “¿Está usted seguro?” antes deactivarse

� Ocasionalmente se le bloquearían todas las puertas del vehículo.Podría usted desbloquearlas tirando del tirador al tiempo que girala llave con una mano y con la otra agarra la antena de radio

� Cada vez que GM lanzase un nuevo vehículo debería ustedaprender a conducir de nuevo, porque ninguno de los mandos delcoche funcionaría igual que en el anterior modelo

aa menor coste menor coste

ObjetivoObjetivo

en tiempoen tiempo y formay forma

concon menos defectosmenos defectos

© ESI 2010 12

Qué hacer•• Modelos de Mejora de Modelos de Mejora de Procesos (Calidad)Procesos (Calidad)

PRODUCIR PRODUCIR MEJORMEJOR SOFTWARESOFTWARE

Cómo hacerlo•• MétodosMétodos•• TécnicasTécnicas•• MetodologíasMetodologías

La premisaLa premisa

El desarrollo de software debe ser contemplado como un

proceso de negocio que tiene que ser gestionado, ser eficiente

© ESI 2010 13

que ser gestionado, ser eficiente y ser predecible

Artesanía / Ingeniería

La Calidad tiene coste…

PrevenciónCostes asociados con la prevención de defectos

Planificación

Documentación

Entrenamiento

Fallos internosCostes asociados con defectos detectados antes de la entrega/ instalación de un producto

Fallos externosCostes asociados con defectos detectados tras la entrega/instalación de un producto

Garantías

EvaluaciónCostes asociados con la “búsqueda” de defectos

Revisiones

• Requisitos

• Diseño

© ESI 2010 14

Entrenamiento

Herramienta

Políticas y procedimientos

Proyectos de mejora de la calidad

Toma y análisis de datos

Análisis de fallos y de causas

Rehacer

• Requisitos

• Diseño

• Codificación

• Documentatión

Re-testing

Menor eficiencia (trabajo repetido, desviaciones de plazos, presupuestos, etc.)

Garantías

Gestión de quejas

Proyectos perdidos

Soporte técnico

Nuevas releases, parches, “Services Packs” (terminología MS)

• Diseño

• Planes de pruebas

• Casos de pruebas

Revisiones e inspecciones de código

Testing (Primera vez)

Auditorías

Evaluaciones de Certificación

• Clase A, B, C

5821

21

39

20

41

1988 - CMM Nivel 1 1990 – CMM Nivel 2

Nuevo desarrollo

… pero es muy rentable

© ESI 2010 15

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

67

23

10

77

176

1992 - CMM Nivel 3 1995 – CMM Nivel 4

Nuevo desarrolloCoste de Calidad

Coste de No-Calidad

ROI 7.7:1, Productividad ��140%, $4.48M ahorrados en 6 proyectos durante 1 año

¿Qué he mejorado?

LA PRODUCTIVIDAD !!!!!

© ESI 2010 16

LA PRODUCTIVIDAD !!!!!

En pequeñas empresas - PyME

En pequeñas organizaciones

En pequeños proyectos

¿Dónde se desarrolla?

© ESI 2010 17

En pequeños proyectos

PYME TIC:• 99,2% del total empresas TIC• 67% de los puestos de trabajo• 58% valor añadido

EUROSTAT – Key Figures in Europe 2007-08

Situación PYME TIC

Un alto porcentaje de empresas TIC son PYME.

� El número medio de trabajadores es bajo.� Los recursos económicos son limitados.� Su enfoque es a corto plazo: desean soluciones a

© ESI 2010 18

� Su enfoque es a corto plazo: desean soluciones a problemas conocidos con la mínima inversión, mínima interrupción y resultados rápidamente demostrables.

� Su principal fortaleza en el mercado es la cercanía con el cliente.

Situación PYME TIC

Dificultad para comercializar gran escala sus actuales productos y servicios.

Dificultad para gestionar el crecimiento de la estructura productiva.

Dificultad para adaptarse a un nuevo mercado:

© ESI 2010 19

Dificultad para adaptarse a un nuevo mercado:• Globalización• Factorías de Software near/off shoring• Tecnología emergentes (OSS,..)

En la mayoría conscientes de la problemática..

Incrementar ventas

Reducir costes

Reducir defectos

Reducir quejas del cliente

Situación PYME TIC

© ESI 2010 20

0,00% 10,00% 20,00% 30,00% 40,00% 50,00% 60,00% 70,00% 80,00% 90,00% 100,00%

Mejora de calidad de producto

Mejora de proceso

Mejora de productividad

Mejora del acceso al mercado

Incrementar satisfacción del cliente

Incrementar ventas

*Motivación para comenzar un programa de mejoraSoftAragón 2006

Objetivo con las empresas del Sector TIC

• Mejora de la Competitividad de la PYME.

• Industrializar y madurar el sector TIC.• Generar confianza y visibilidad de un

sector TIC maduro.

© ESI 2010 21

sector TIC maduro.

Medida para potenciar la Calidad del Software de la industria TIC

2. Modelos 2. Modelos de Mejora de de Mejora de

© ESI 2010 22

de Mejora de de Mejora de Procesos Procesos SoftwareSoftware

¿Qué es un proceso de software?¿Qué es un proceso de software?

Conjunto de actividades para desarrollar y mantener el software y los productos asociados (documentos de diseño, casos de pruebas, manuales de usuario…) y para gestionar su producción

Procedimiento y métodos

© ESI 2010 23

Procedimiento y métodos que definen las relaciones

entre las tareas

Herramientas y equipos

Gente con conocimiento, motivación y

formación

Proceso

“La calidad de un producto está determinada en gran

medida por la calidad

Situaciónesperada

No debieraocurrir

PROCESO

PR

OD

UC

TO

Malo Bueno

Premisa básica de la mejora de procesosPremisa básica de la mejora de procesos

© ESI 2010 24

medida por la calidad de los procesos de desarrollo y mantenimiento del producto”

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

Esfuerzoheroico

Negociomaduro

esperada ocurrir

PR

OD

UC

TO

Bueno

• Un modelo de procesos es una colección estructurada de prácticas que describen las características de los procesos efectivos.

• Las prácticas incluidas son aquéllas que han demostrado ser eficaces en la industria.

¿Qué es y por qué es importante usar un modelo de procesos?¿Qué es y por qué es importante usar un modelo de procesos?

© ESI 2010 25

• Un modelo indica QUÉ se debe hacer, NO CÓMO hacerlo

Un modelo proporciona

• un punto de inicio• el beneficio de experiencias previas de la comunidad• un lenguaje común y visión compartida• un marco para priorizar mejoras

Entonces … ¿Qué modelo utilizo?Entonces … ¿Qué modelo utilizo?

ITILISO

20000

© ESI 2010 26

????

Uso del sentido común

“All models are wrong, but some are useful.”

George Box

© ESI 2010 27

Aproximaciones simplificadas de la realidad que aportan entendimiento.

Ciclo de vida Desarrollo & ServicioCiclo de vida Desarrollo & Servicio

© ESI 2010 28

Calidad debe cubrir todo el Ciclo de Vida

Mapa Mejora de procesosMapa Mejora de procesos

© ESI 2010 29Fuente: Paul Nielsen, SEI 2008


Mét

odos

de

Eva

luac

ión

de P

roce

sos

ISO

/IEC

155

04 S

PIC

E

(Fut

uro

ISO

33.

000)

MODELOS METODOLOGÍAS(QUÉ hacer) (CÓMO hacerlo)

CMMI-DEV y CMMI-ACQ RUPSpice-for-Space SCRUM, XP, AgileAutomotive SPICE Métodos EstructuradosITMark-DEV PMI

DESARROLLO SW

© ESI 2010 30


Mét

odos

de

Eva

luac

ión

de P

roce

sos

ISO

/IEC

155

04 S

PIC

E

(Fut

uro

ISO

33.

000)

ITMark-DEV PMIISO 15504 / 12207 (?) PSP-TSP

Otros muchos

CMMI-SVC ITILISO-20.000 etcITMark-SVC

SERVICIOS DE EXPLOTACIÓN SW

Modelo de Modelo de

© ESI 2010 31

Modelo de Modelo de Excelencia Excelencia

EFQMEFQM

EFQM Excellence model for SIOs version 2.2

SupportEngineeringProject Management

Process Management

Process Areas

Sw and SE Processes

© ESI 2010 32

Support

RESULTSRESULTS

KEY PERFORMANCE

RESULTS

PEOPLE RESULTS

CUSTOMERRESULTS

SOCIETY RESULTS

LEADERSHIP PROCESSES

PEOPLE

POLICY ANDSTRATEGY

PARTNERSHIPS AND RESOURCES

ENABLERSENABLERS

SIO: Sw. Intensive Organisations

Visión Visión general de general de

© ESI 2010 33

general de general de CMMICMMI

¿Qué es CMMI?¿Qué es CMMI?

• Capability Maturity Model Integration (CMMI) es un modelo para la mejora de procesos que proporciona a las organizaciones los elementos esenciales para tener procesos eficaces

• La familia de productos CMMI aborda los siguientes materiales:• Modelo

© ESI 2010 34

• Modelo• Evaluación• Formación

• CMMI se organiza en “constelaciones”:• Desarrollo (CMMI – DEV)• Adquisición (CMMI – ACQ)• Servicios (CMMI - SVC)

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

Constelaciones CMMIConstelaciones CMMI

CMMI-DEV

Proporciona guías para medir, controlar y

gestionar los procesos de

CMMI-SVC

Proporciona guías para aquellos que proveen servicios

dentro de la organización y a clientes externos16 áreas de

© ESI 2010 35

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

procesos de desarrollo

CMMI-ACQ

proporciona una guía para habilitar

una gestión en adquisiciones

informada y decisiva

clientes externos16 áreas de proceso

usadas en todos

El proceso se controla cuantitativamente

Foco en la mejora continua

5. En

optimización

4. Gestionado cuantitativamente

3. Definido

4

5

Niveles de Madurez –CMMI EscalonadoNiveles de Madurez –CMMI Escalonado

© ESI 2010 36

Proceso impredecible, poco controlado

Proceso definido caracterizado para proyectos y frecuentemente reactivo

Proceso definido para la organización y proactivo

3. Definido

1. Inicial

2. Gestionado

1

2

3

NIVEL FOCO AREAS DE PROCESO Calidad

5 En optimizaciónMejora continua del proceso

Innovación y despliegue organizativoAnálisis causal

Productividad

4Gestionado cuantitativamente

Gestión cuantitativa

Rendimiento de procesos organizativosGestión de proyectos cuantitativa

3 DefinidoEstandarización del proceso

Desarrollo de requerimientosSolución técnicaIntegración de productoVerificaciónValidaciónFoco en proceso organizativo

Niveles de MadurezNiveles de Madurez

© ESI 2010 37

3 Definidodel proceso

Foco en proceso organizativoDefinición de proceso organizativo + IPPDEntrenamiento organizativo Gestión de proyecto integrada + IPPDGestión de riesgosAnálisis de decisiones y soluciones

2 GestionadoGestió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 Riesgo

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

Resumen CMMI-DEVResumen CMMI-DEV

Escalonada Continua

PA PA

N. C

apac

idad

Áreas ProcesoPAML 1

ML2

ML3

ML4

ML5

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

ML5

ML4

ML3

N. M

adu

rez

© ESI 2010 38

Áreas ProcesoML 1Organización

Nivel Madurez 5 OID, CAR

Nivel Madurez 4 OPP, QPM

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

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

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)

SoporteSoporteCM, PPQA, MA,

CAR, DAR

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

Gestión Gestión ProyectoProyecto

PP, PMC, SAM, IPM, RSKM, QPM

Gestión Gestión ProcesoProceso

OPF, OPD, OT, OPP, OID

ML3

ML2

P & P

Proyectos

Buenas

Organización

Políticas yProcedimientos

P & PP & P

P & P

Análisis de Procesos

Del nivel de madurez 2 al nivel de madurez 3Del nivel de madurez 2 al nivel de madurez 3

© ESI 2010 39

P & PNivel 2 Nivel 3

Buenas Prácticas

P & P

P & P

Implantación Organizativa

Política yProcedimientos

Implantación en la organización

Nivel 3 Nivel 4

Moviéndose a niveles de madurez superioresMoviéndose a niveles de madurez superiores

© ESI 2010 40

Objetivos de Negocio

estratégicosCambios según se requieran

Conocimiento cuantitativo de la capacidad de los procesos y productos

Nivel 5

Cambios por prevención, tecnología o mejora

Estructura del Área de ProcesoEstructura del Área de Proceso

AP Relacionadas

Introducción

Metas EspecíficasMetas Genéricas

Propósito

Área de Proceso(AP)

© ESI 2010 41

Resultados típicos

Subprácticas

Esperado InformativoRequerido

Prácticas Específicas Prácticas

Genéricas

ElaboracionesSubprácticas

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

Ejemplo: Gestión de Requisitos 1/5Ejemplo: Gestión de Requisitos 1/5

Maturity Level

Process Area 1

ProcessArea 2

Process Area n

Staged v1.2

Maturity Level

Process Area 1

ProcessArea 2

Process Area n

Staged v1.2

© ESI 2010 42

ALSGSG1: Gestionar Requisitos Se gestionan los requisitos y se identifican las inconsistencias con los planes de proyecto y productos de trabajo.

GG 2: Institucionalizar un Proceso Gestionado: El proceso es institucionalizado como un proceso gestionado.

Generic Goals Specific Goals

Note: no common features

Generic Practices

Specific Practices

Generic Goals Specific Goals

Note: no common features

Generic Practices

Specific Practices


Analyze andValidate

Requirements

Develop Customer

Requirements

DevelopProduct

Requirements

Requirements Development (RD)

© ESI 2010 43

RequirementsRequirements Requirements

Stakeholders

Requirements

ManageRequirements

Requirements Management (REQM)

SP1.1 Obtener Conocimiento de los Requisitos

• Identificar quienes son los actores• Criterios de Aceptación de Requisitos• Documentación de los Requisitos• Registro de los Requisitos

SP1.2 Obtener Compromiso a los Requisitos • Registros de Compromisos

• Aceptación de Requisitos


SP1.3 Gestionar los Cambios • Proceso de Gestión del cambio• Análisis de Impacto

© ESI 2010 44

SP1.3 Gestionar los Cambios a los Requisitos • Análisis de Impacto

• Seguimiento del cambio• Registros de cambio

SP1.4 Mantener Trazabilidad Bidireccional entre los Requisitos

• Matriz de trazabilidad– Entre Requisitos– Reqs- Casos de prueba, Reqs- plan de

proyecto

SP1.5 Identificar Inconsistencias entre los requisitos y productos de trabajo

• Registro de inconsistencias y de acciones correctivas.

• Identificación de cambios a realizar en otros productos y planes


– GP 2.1 Establecer una política organizativa– GP 2.2 Planificar el proceso– GP 2.3 Proporcionar recursos– GP 2.4 Asignar responsabilidades– GP 2.5 Entrenar al personal

Meta Genérica 2: Institucionalizar un Proceso Gestionado

© ESI 2010 45

– GP 2.5 Entrenar al personal– GP 2.6 Gestionar configuraciones– GP 2.7 Identificar e involucrar agentes relevantes– GP 2.8 Supervisar y controlar el proceso– GP 2.9 Evaluar objetivamente la adherencia– GP 2.10 Revisar el estado con un nivel superior de Gerencia

GG2: Institucionalizar un proceso gestionado El proceso es institucionalizado como un proceso gestionado.

GP 2.1 Establecer una política en la organización

• Política• Roles• Canales de comunicación• Criterios de aceptación

GP 2.2 Planificar el proceso • Existe tarea en el plan de proyecto• La tarea está asignada a un responsable


© ESI 2010 46

• La tarea está asignada a un responsable

GP 2.3 Proporcionar recursos • Herramientas, Plantillas,..• Tiempo (plan SP2.2)• Personal

GP 2.4 Asignar responsabilidades

• Definición de roles y sus responsabilidades

GP 2.5 Formar al personal • Planes de formación (especialmente referida al área de proceso)

• ¿Saben realizar los responsables su trabajo?

Y además … GP 2.6, 2.7, 2.8, 2.9, 2.10

Modelo CMMI-DEV 1.2 http://www.sei.cmu.edu/publications/documents/06.reports/06tr008.html

Informes General CMMI http://www.sei.cmu.edu/cmmi/index.cfm

Referencias Oficiales CMMIReferencias Oficiales CMMI

© ESI 2010 47

Informes General CMMI http://www.sei.cmu.edu/cmmi/index.cfm

• Informes de evaluaciones, método de evaluación y requisitos.

• Información para la adopción de CMMI, comparación y equivalencias entre modelos.

• Resultados de rendimientos, ROI, casos de éxito

• Programa de formación y eventos,

• …

CMMI, CMM, and Capability Maturity Model are registered in the U.S. Patent and Trademark Office.CMM Integration, SCAMPI, and IDEAL are service marks of Carnegie Mellon University.

Visión general de Visión general de ISO/IEC 15504 ISO/IEC 15504

© ESI 2010 48

ISO/IEC 15504 ISO/IEC 15504 SPICESPICE

ISO/IEC 15504-2 SPICE• ISO/IEC 15504 es un estándar internacional que es

aplicable a cualquier organización/empresa que quiera conocer y mejorar la capacidad de sus procesos.

• Es independiente del tipo de organización, del modelo del ciclo de vida, de la metodología de desarrollo y de la

© ESI 2010 49

del ciclo de vida, de la metodología de desarrollo y de la tecnología utilizada.

• No pretende fijar la manera de realizar los procesos dentro de una organización, sino que valora su capacidad y ayuda a proponer mejoras que aumenten esta capacidad.

• La descripción de los procesos de Desarrollo está en ISO-12207 (los de Servicios en ISO-20000)

PRIMARY Life Cycle Processe

Acquisition Process Group (ACQ)ACQ.1 Acquisition preparationACQ.2 Supplier selectionACQ.3 Contract agreementACQ.4 Supplier monitoringACQ.5 Customer acceptance

Supply Process Group (SPL)SPL.1 Supplier tenderingSPL.2 Product releaseSPL.3 Product acceptance support

Engineering Process Group (ENG)

ORGANIZATIONAL Life Cycle Processes

Management Process Group (MAN)MAN.1 Organizational alignmentMAN.2 Organizational managementMAN.3 Project managementMAN.4 Quality managementMAN.5 Risk managementMAN.6 Measurement

Process Improvement Process Group (PIM)PIM.1 Process establishmentPIM.2 Process assessmentPIM.3 Process improvement

Dimensión de procesos

© ESI 2010 50

Engineering Process Group (ENG)ENG.1 Requirements elicitation ENG.7 Software integrationENG.2 System requirements analysis ENG.8 Software testingENG.3 System arquitecture design ENG.9 System integrationENG.4 Software requirements analysis ENG.10 System testingENG.5 Software design ENG.11 Software installationENG.6 Software construction ENG.12 Software and system maintenance

Operation Process Group (OPE)OPE.1 Operational useOPE.2 Customer support

PIM.3 Process improvement

Resource and Infraestructure Process Group (RIN)

RIN.1 Human resource managementRIN.2 TrainingRIN.3 Knowledge managementRIN.4 Infraestructure

Reuse Process Group (REU)REU.1 Asset managementREU.2 Reuse program managementREU.3 Domain engineering

Support Process Group (SUP)SUP.1 Quality assurance SUP.6 Product evaluationSUP.2 Verification SUP.7 DocumentationSUP.3 Validation SUP.8 Configuration managementSUP.4 Joint review SUP.9 Problem resolution managementSUP.5 Audit SUP.10 Change request management

SUPPORTING Life Cycle Processes

Niveles de Capacidad

5

4

Optimizando

Predecible

5.1 Innovación procesos

5.2 Optimización procesos

Atributos

4.1 Medición de los procesos

4.2 Control de procesos

© ESI 2010 51

3

2

1

0

Establecido

Gestionado

Realizado

Incompleto

1.1 Ejecución del proceso

2.1 Gestión del proceso

2.2 Gestión de los productos

3.1 Definición de procesos

3.2 Despliegue de los procesos

4.2 Control de procesos

Ejemplo de Perfil de Madurez –Representación Continua (CMMI ó SPICE)

No existen Niveles de Madurez definidosNivel de

Capacidad 0-5

3

© ESI 2010 52

2

1

MAN3 SUP1 SUP8 MAN6 ENG1

Project

Management

Quality

Assurance

Configuration

Management

Measurement

Requirements

Elicitation

Áreas de Proceso individuales

ISO 15504-2 SPICE

• 15504 es un Modelo con Representación Continua sólo – 5 Niveles de Capacidad para cada Proceso (como CMMI)

– Algunas variantes tienen Niveles de Madurez (Spice-for-Space, Automotive SPICE, TR 15504-7)

– Técnicamente similar a CMMI

© ESI 2010 53

• En proceso de migración / integración a ISO/IEC-33000 con ISO20000 y más

• Realmente 15504 Parte 2 es sólo Norma de Evaluación de Procesos (no dice qué procesos)

• La descripción de los procesos de Desarrollo está en ISO-12207 (los de Servicios en ISO-20000)

Ventajas e inconvenientes SPICE / CMMI

• ISO/IEC-15504-2 es una Norma ISO, evolucionada a partir de CMM y otros modelos. CMMI no es ISO.

• No existe un mecanismo de Acreditación de Organismos de Certificación 15504 (similar a ENAC), por tanto no hay certificaciones reconocidas.

• No existe un mecanismo de acreditación de Auditores 15504, Formadores, etc.

• Demasiadas variantes SPICE sin reconocimiento mutuo

© ESI 2010 54

• En vías de migración y modificación

• CMMI compatible 15504 (realmente su método de evaluación SCAMPI con 15504-2, que es la única parte normativa de la familia 15504)

• Escasa implantación y reconocimiento de 15504 salvo en mercados específicos (relativamente pequeños)

• Al no haber Niveles de Madurez 15504 comparables dificulta mucho el benchmarking entre empresas – pedir que mis suministradores sean SPICE nivel 2 es algo que no tiene sentido

ModeloModelo

© ESI 2010 55

ModeloModelo

• Certificación que evalúa los procesos técnicos y de negocio, diseñado específicamente para PYME del sector TI

– Procesos de desarrollo de software• CMMI-DEV v1.2, representación escalonada, niveles de madurez 2 y 3

– Procesos de gestión del negocio• Ten squared (10²) del estilo del Modelo EFQM, simplificado

¿Qué es IT Mark?¿Qué es IT Mark?

© ESI 2010 56

• Ten squared (10²) del estilo del Modelo EFQM, simplificado

– Procesos de gestión de la seguridad de la información• Basado en ISO/IEC 27000:2005 Information Technology – Security

techniques

• Diseñado para PYME, a quienes ayuda a posicionarse a través de la Mejora Continua, arrancando una iniciativa de mejora con sostenibilidad.

Niveles de IT Mark y CMMINiveles de IT Mark y CMMI

5. En

optimización

4. Gestionado cuantitativamente

© ESI 2010 57

3. Definido

1. Inicial

2. Gestionado

CMMI

Niveles IT MarkNiveles IT Mark

NivelProcesos de

negocio(10squared)

Procesos de seguridad

de la información(ISO27000)

Proceso de software (CMMI)

Clase de la evaluación

Hallazgos

Ninguna categoría en rojo y > 75%

Nivel 3Clase B, Nivel de madurez 3

Ningún área de proceso en rojo &

Nº áreas de proceso en

© ESI 2010 58

rojo y > 75%verde >=11

Ninguna categoría en rojo y > 60%

Nivel 2Clase B, Nivel de madurez 2

Ningún área de proceso en rojo &

Nº áreas de proceso en verde >=3

No más de una categoría en rojo y > 50%

Nivel 1Clase C, Nivel de madurez 2

No más de 2 AP alcanzando menos de 50%. Estas AP no pueden ser ni PP, ni PMC.

Más información http://www.esi.es

Compatibilidad ITMark e ISO/IEC 15504 – SPICE

Nivel de

Capacidad 0-5

3

2

Perfil Objetivo del proyecto:

© ESI 2010 59

2

1

MAN3 SUP1 SUP8 MAN6 ENG1

Project

Management

Quality

Assurance

Configuration

Management

Measurement

Requirements

Elicitation

Perfil de empresa participante

Desarrollo Software

Provisión de Servicio

ImplantaciónSWAtención

Procesos ISO20000CMMI, ISO15504, ITMark

© ESI 2010 62

SW

Soporte yMantenimiento

Atencióny soportePreventa

Los procesos que abarca la ISO20000 están especialmente orientados a actividades relacionadas con la provisión del servicio una vez que el producto se ofrece en el mercado y posteriormente se implanta y se provee de soporte y mantenimiento al cliente.

InstalaciónInfraestructura

física

Procesos ISO/IEC 20.000

Procesos de Entrega de Servicios

Gestión deCapacidad Gestión de Niveles

Gestión deSeguridad de

Planificando e implementando Servicios nuevos o cambiados

Planificando e implementando Gestión de Servicios

Requisitos para el sistema de Gestión

© ESI 2010 63

Capacidad Gestión de Nivelesde Servicio

Seguridad de la Información

Informes de Servicio

Procesos de Control

Gestión de ConfiguracionesGestión de CambiosProcesos

de Versiones

Gestión de Versiones

Procesos de Resolución

Gestión de Problemas

Gestión de Incidentes

Procesosde Relaciones

Gestión de Relacionesde Negocio

Gestión de Proveedores

Gestión deContinuidad y Disponibilidadde Servicio

Presupuestacióny Contabilizaciónde Servicios de TI

CMMI for ServicesCategory Process Area

Process Management Organizational Innovation and Deployment (OID)Organizational Process Definition (OPD)Organizational Process Focus (OPF)Organizational Process Performance (OPP)Organizational Service Management (OSM)*Organizational Training (OT)

Project Management Capacity and Availability Management (CAM)Integrated Project Management (IPM)Project Monitoring and Control (PMC)Project Planning (PP)Requirements Management (REQM)Risk Management (RSKM)

© ESI 2010 64

Risk Management (RSKM)Quantitative Project Management (QPM)Service Continuity (SCON)*Supplier Agreement Management (SAM)

Service Establishment and Delivery

Incident and Request Management (IRM)Service Delivery (SD)Service System Development (SSD)*Service Transition (ST)

Support Causal Analysis and Resolution (CAR)Configuration Management (CM)Decision Analysis and Resolution (DAR)Measurement and Analysis (MA)Problem Management (PRM)Process and Product Quality Assurance (PPQA)

Engineering none

Diferencias CMMI-SVC frente a CMMI-DEV

5 Razones clave para la adopción

• La Mejora de Procesos Software ayuda a las organizaciones:– Mejoras en la entrega de los productos en funcionalidad, coste y

plazos.– Coordinación eficaz con proveedores y clientes.– Proveer productos y servicios con reconocimiento de calidad

© ESI 2010 66

– Proveer productos y servicios con reconocimiento de calidad “world class” (CMMI, ITMark, SPICE,..)

– Definición e implementación de una perspectiva integrada de negocio e ingeniería.

– Procesos comunes, integrados y basados en la mejora para el desarrollo de sistemas y software.

Beneficios CMMI PredicciónBeneficios CMMI Predicción

Level

5544Managed

Optimizing

Probability

Time/$/...

Target N-Y

Probability

Time/$/...

Target N-Z

Results

Quali

Produc

Predicted Performance

Performance improves based on quantitative understanding ofprocess and product.

Results

Performance continu-ously improves.

© ESI 2010 68

11Initial

4433

22Repeatable

Defined

Time/$/...

Probability

Time/$/...

Target N-X

Probability

Time/$/...

Target N-a

Probability

Time/$/...Target N

RISK

ity

ctivity

Targets not achieved.Commitments not kept.

Plans based on pastperformance aremore realistic.

With well-defined processes perfor-mance improves.

process and product.

Resultado de mejoraResultado de mejora

Metric Median Total Data Points

Minimum Maximum Mean

ROI 3 Ratio 9 2 Ratio 13.3 Ratio 4.6 Ratio

Impact on Cycle Time -38% 5 -15% -50% - 32.6 %

Reduction in Rework -60% 1 -60% -60% -60%

Impact on Quality (% defect reduction)

- 48.5 % 20 -0,5% 95% -47,6%

Impact on Productivity

CMMI Process Improvement

© ESI 2010 69

Datos publicados referidos a 2007.

DACS is a Department of Defense (DoD) Information Analysis Center (IAC). DACS

technical area of focus is Software Technology and Software Engineering, in its

broadest sense. https://www.thedacs.com/databases/roi/

Impact on Productivity (Improvement)

+39% 12 +5% +250% +57%

Impact on Schedule Variance -40% 3 -35% -50% -41,7%

Impact on Quality (% of defects found)

98% 1 98% 98% 98%

Reduction in Project Cost -30% 2 -20% -40% -30%

Cost of the Improvement (% of total engineering effort)

1.1 % 1 1.1 % 1.1 % 1.1 %

Caso de estudio CMMI Nivel 4 Caso de estudio CMMI Nivel 4

© ESI 2010 71

6,7 hh/pf * 5,7inc./100pf = 5,7 incidencias por cada 670 horas de desarrollo!!

Datos de programa de mejora CMMIDatos de programa de mejora CMMI

Esfuerzo Interno

Dedicación de recursos internos a la definición de procesos y soluciones, incluido el desarrollo de herramientas

Consultoría externa

Contratación de consultoría externa como soporte a la iniciativa de mejora 28.80 %

63.50 %

© ESI 2010 72

FormaciónContratación de formación externa y dedicación interna a actividades de formación

Varios Viajes, compra de material, 1.80 %

5.90 %

Beneficios para las pymes I

• Capacidad gestión del proceso productivo con datos objetivos: incidencias, cambios en requisitos, fechas, etc.

• Organización menos dependiente de las personas. Fundamental en una PYME.

• Mejora en los métodos de estimación del trabajo a realizar y de planificación.

© ESI 2010 73

planificación.• Incremento de la satisfacción del cliente externo e interno.• Mayor confianza ante el sector y ante los clientes.• Mejor posicionamiento en la oferta de contratos públicos y

grandes cuentas.

*Datos Competic/SofAragón 2006

Mejora de la calidad de producto (numero de defectos)

Mejora de la satisfacción del cliente

Mejora de la moral de los trabajadores

Reducción del coste de la calidad

Beneficios para las pymes II

© ESI 2010 74

0,00 1,00 2,00 3,00 4,00 5,00 6,00 7,00 8,00 9,00 10,00

Calendario y presupuestos mas predecibles

Mejora del tiempo de desarrollo

Mejora de la productividad

*Datos SoftAragón 2006

¿Y cuánto tiempo cuesta un proyecto de mejora?¿Y cuánto tiempo cuesta un proyecto de mejora?

© ESI 2010 75

Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Updatehttp://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm

Soy pyme… ¿esto es para mí?Soy pyme… ¿esto es para mí?

© ESI 2010 76

Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Updatehttp://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm

Perfil de madurez mundialPerfil de madurez mundial

© ESI 2010 77

Source: SEI, Process Maturity Profiles for CMMI, 2009 End-Year Update, http://www.sei.cmu.edu/cmmi/casestudies/profiles/cmmi.cfm

• 1º país en evaluaciones CMMI de Europa con algún nivel alcanzado.

• Gran crecimiento relativo, junto con el de China y Argentina

Datos en España

Madurez en EspañaMadurez en España

CMMINº de

ORGANIZACIONES

71% - PYME

EMPRESAS SOLICITUDES PLAN

© ESI 2010 78

CMMI ORGANIZACIONES

NIVEL 1 1 1%

NIVEL 2 108 60%

NIVEL 3 54 30%

NIVEL 4 3 2%

NIVEL 5 4 2%

TOTAL 180

SOLICITUDES PLAN AVANZA

2006 2007

CMMI 28 101 361%

SPICE 17 3

9001 12 7

TOTAL 57 111 195%

• Diciembre 2006 – 31 • Diciembre 2007 – 75 • Diciembre 2008 – 105• Diciembre 2009 – 180

Parque Tecnológico, # 204E-48170 Zamudio

Félix NanclaresGerente de Proyectos Asociativos

[email protected]

Para más información …

Mikel EmaldiDirector Relaciones

Institucionales

© ESI 2010 79

Sexta edición de la conferencia SEPG LA 2010, del 10 al 12 de noviembre en Medellín, Colombia.

La SEPG LA es la edición de las conferencias SEPG para Latinoamérica, el lugar de encuentro de la Comunidad de Mejora de Procesos Latinoamericana para aprender, compartir experiencias y desarrollar habilidades para alcanzar los mejores resultados de negocio. La SEPG LA 2010 combinará un programa de máxima calidad con el networking esperado.

Organizada por SEI y ESI

E-48170 ZamudioBizkaia (Spain)Tel.: +34 94 420 95 19Fax: +34 94 420 94 20www.esi.es

Parque Tecnológico, # 204E-48170 ZamudioBizkaia (Spain)Tel.: +34 94 420 95 19Fax: +34 94 420 94 20www.esi.es

[email protected]

http://www.esi.es/SEPGLA/

mejora de procesos general v3.ppt [modo de … · • capability maturity model integration (cmmi)...

Documents