P. 1
Mejora de Procesos - Modelos

Mejora de Procesos - Modelos

|Views: 53|Likes:
Describe modelos en la Mejora de Procesos
Describe modelos en la Mejora de Procesos

More info:

Published by: Juan López Villegas on Nov 28, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

03/03/2013

pdf

text

original

Sections

Modelos de mejora de procesos

León, 19 de Junio de 2008

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

Agenda
• Motivación para la Mejora de Procesos • Modelos de Mejora de Procesos
– CMMI – ITMARK

• Beneficios y Conclusiones

© ESI 2008

2

“Software is everywhere”

Fuente: Paul Nielsen, SEI 2007
© ESI 2008 3

Ejemplo del Crecimiento del Software

1990: 1 millón de líneas de código 2010: 100 millones de líneas de código Windows 2000: 35 M LOC Windows XP: 40 M LOC ITEA: el volumen de embedded Debian 3.1: 230 M LOC software se duplica cada 2 años
Fuente: Paul Nielsen, SEI 2007
© ESI 2008 4

¿Por qué queremos mejorar?

Creencias - I
Todas las organizaciones tienen la necesidad de mejorar continuamente su rendimiento con el fin de satisfacer las necesidades de sus clientes Supervivencia empresarial

© ESI 2008

5

Creencias - II
Sólo es posible hacer 3 cosas:
Trabajar más duro Contratar personal más cualificado Invertir para mejorar los procesos que se siguen para realizar el trabajo
© ESI 2008 6

¿En qué basa su estrategia de mejora?

© ESI 2008

7

Motivación para la mejora de procesos

© ESI 2005

8

CMMI Overview Seminar

¿Por qué debería la Gerencia preocuparse por el proceso de software ?
Resulta muy complicado entregar constantemente productos de calidad a nuestros clientes y a la vez obtener beneficios, partiendo de unos procesos de desarrollo pobremente definidos.
© ESI 2008 9

Situación real …

“Sólo el 35% de los proyectos de software tiene éxito.”
Standish Group, CHAOS Report, 2006

© ESI 2008

10

¿Qué está sucediendo?
Éxitosos 35%

Problemáticos 46%
Definiciones Éxitosos Problemáticos Fallidos

Fallidos (Cancelados) 19%
En tiempo, en presupuesto, en funcionalidad prometida Tarde, sobrepasado el presupuesto, falta funcionalidad Proyectos cancelados

De una inversión en proyectos de $255 billones, se desperdician $55 billones De cada 100 proyectos, 94 se reinician Al 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

Source: Standish Group Chaos Report - 2006 © ESI 2008 11

Estamos mejorando, pero…
1994 Chaos Report Éxitosos 16%

Problemáticos 53%

Fallidos (Cancelados) 31% Éxitosos 35%

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 los defectos Muchas compañías gastan del 30% al 44% de su tiempo y dinero en rehacer el software que ya han escrito

2006 Chaos Report

Problemáticos 46%
© ESI 2008 12

Fallidos (Cancelados) 19%

La calidad tiene coste (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. Categorías de coste

Coste de No Conformidad + Coste de Conformidad = Coste de la Calidad
© ESI 2008 13

Fallos internos + fallos externos Prevención + Evaluación

La calidad tiene coste (CoQ)
Prevención
Costes asociados con la prevención de defectos
Planificación Documentación Formación Herramientas Políticas y procedimientos Proyectos de mejora de la calidad Captura y análisis de datos Análisis de fallos y causas Informes de calidad

Evaluación
Costes asociados con la búsqueda de defectos
Revisiones • Sistema •Requisitos • Diseño • Planes de pruebas • Casos de pruebas Inspecciones de código •Pruebas (primera vez) Auditorías Evaluaciones CMM •Clase A, B, C

Fallo interno
Costes asociados con defectos encontrados antes de la entrega / instalación
Correcciones • Requisitos • Diseño • Código • Documentación Nuevas pruebas Menor eficiencia (nuevas pruebas, cambios en entregables, desviaciones de plazos, presupuestos, etc.)

Fallo externo
Costes asociados con defectos encontrados tras la entrega/instalación
Garantías Gestión de quejas Proyectos perdidos Soporte técnico Parches en versiones

© ESI 2008

14

… pero es muy rentable
1988 - CMM NIvel 1
41 39

1990 - CMM NIvel 2
21

21
20

58

Nuevo desarrollo Coste de conformidad (COC) Coste de no conformidad (CONC)
10 23

1995 - 6 CMM Nivel 4
17

1992 – CMM Nivel 3

77

67

ROI 7.7:1, Productividad
© ESI 2008 15

140%, $4.48M ahorrados en seis proyectos en un año

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

… pero es muy rentable (2)
Performance Category Cost Schedule Productivity Quality Customer Satisfaction Return on Investment Median 20% 37% 62% 50% 14% 4.7 : 1 Number of Data Points 21 19 17 20 6 16 Low 3% 2% 9% 7% -4% 2:1 High 87% 90% 255% 132% 55% 27.7 : 1

Datos publicados el día 15 de diciembre de 2005 por el SEI sobre los resultados obtenidos a través de Procesos de Mejora en un grupo de empresas sobre las que existen datos públicos -- http://www.sei.cmu.edu/cmmi/results.html

© ESI 2008

16

… pero es muy rentable (3)
Metric
ROI Impact on Cycle Time Reduction in Rework Impact on Quality (% defect reduction) Impact on Productivity (Improvement) Impact on Schedule Variance Impact on Quality (% of defects found) Reduction in Project Cost Cost of the Improvement (% of total engineering effort)

Median
3 Ratio -38% -60% - 48.5 % +39% -40% 98% -30% 1.1 %

Total Data Points
9 5 1 20 12 3 1 2 1

Minimum Maximum
2 Ratio -15% -60% -0,5% +5% -35% 98% -20% 1.1 % 13.3 Ratio -50% -60% 95% +250% -50% 98% -40% 1.1 %

Mean
4.6 Ratio - 32.6 % -60% -47,6% +57% -41,7% 98% -30% 1.1 %

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/
© ESI 2008 17

Pero… ¿esto es cierto para una PYME?
La respuesta al acabar la presentación…

© ESI 2008

18

Modelos de Mejora de Procesos Software
© ESI 2008 19

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

Productos

Personas
Principales determinantes del coste, plazo y calidad del producto

SATISFACCIÓN DEL CLIENTE
Tecnología

Proceso

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

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

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
© ESI 2008 21

¿Cuáles son los riesgos de la mejora basada en modelos?
• • • • • 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

© ESI 2008

22

????

¿Los modelos son útiles… o no?
ITIL ISO 20000

© ESI 2008

23

Modelos de Referencia TI

-SPICE

© ESI 2008

24

Mapa Mejora de procesos

© ESI 2008

25

Fuente: Paul Nielsen, SEI 2008

Cobertura de los Modelos
ITIL, CMMI-Dev&Svc – SPICE - ITMARK ISO 27001 & 27002 - Partially

People-CMM ESI BITS

Organización

& Roles Personas Metricas

CobiT CMMI-Dev&Svc SPICE - ITMARK

Control
CobiT ISO 27001 & 27002

Procesos
CMMI-Dev&Svc SPICE - ITMARK ITIL CobiT ISO 27001 & 27002 - partially

Tecnología & Infraestructura
ITIL – partially CMMI-Svc – partially

© ESI 2008

26

Ciclo de vida Desarrollo & Servicio

Calidad debe cubrir todo el Ciclo de Vida
© ESI 2008 27

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

28

Visión general de CMMICMMI-DEV

© ESI 2008

29

Familia de productos CMMI
• La familia de productos CMMI aborda los siguientes materiales: – Modelo – Evaluación – Formación • El modelo del CMMI se compone de lo siguiente: – CMMI Model Foundation – Material compartido – Material específico de la constelación • Adquisición • Desarrollo • Servicios
Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5 © ESI 2008 30

Constelaciones CMMI
CMMI-SVC CMMI-DEV Proporciona guías para medir, controlar y gestionar los procesos de desarrollo Proporciona guías para aquellos que proveen servicios dentro de la organización y a clientes externos 16 áreas de proceso usadas en todos CMMI-ACQ proporciona una guía para habilitar una gestión en adquisiciones informada y decisiva
Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5 © ESI 2008 31

Áreas de Proceso
• 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
© ESI 2008 32

Estructura del Área de Proceso
Área de Proceso(AP)

Propósito

Introducción

AP Relacionadas

Metas Específicas Metas Genéricas Prácticas Específicas Prácticas Genéricas Subprácticas Subprácticas Legend
Requerido
© ESI 2008 33

Resultados típicos

Elaboraciones

Esperado

Informativo

Tipos de metas y prácticas
• 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 institucionalizar cada Área de Proceso – por lo tanto, son aplicables para todas las Áreas de Proceso

© ESI 2008

34

Prácticas genéricas
Meta Genérica 2: Institucionalizar un Proceso Gestionado
– – – – – – – – – – 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 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

Meta Genérica 3: Institucionalizar un Proceso Definido
- GP 3.1 Establecer un proceso definido - GP 3.2 Recoger información para la mejora
© ESI 2008 35

Prácticas genéricas
Meta genérica 4: Institucionalizar un proceso gestionado cuantitativamente
– GP4.1 Establecer objetivos cuantitativos para el proceso – GP4.2 Estabilizar el rendimiento de los subprocesos

Meta genérica 5: Institucionalizar un proceso optimizado
– GP5.1 Asegurar la mejora continua de los procesos – Corregir las causas de los problemas

© ESI 2008

36

Representaciones del modelo
Escalonada
ML5 ML4 ML3 ML2 ML 1 . . . para un conjunto definido de áreas de proceso en la organización
© ESI 2008 37

Continua
Capacidad del Área de Proceso (PA)

PA

PA

PA

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

Ventajas de la representación Escalonada
• 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

© ESI 2008

38

Ventajas de la representación Continua
• 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
© ESI 2008 39

PA

PA

PA

Niveles de Madurez
NIVEL 5 En optimización 4 Gestionado cuantitativamente FOCO Mejora continua del proceso Gestión cuantitativa AREAS DE PROCESO Innovación y despliegue organizativo Análisis causal Rendimiento de procesos organizativos Gestión de proyectos cuantitativa Desarrollo de requerimientos Solución técnica Integración de producto Verificación Validación Foco en proceso organizativo Definición de proceso organizativo + IPPD Entrenamiento organizativo Gestión de proyecto integrada + IPPD Gestión de riesgos Análisis de decisiones y soluciones Gestión de requerimientos Planificación de proyecto Seguimiento y control de proyecto Gestión de acuerdos con proveedores Medición y análisis Aseguramiento de la calidad Gestión de la configuración Calidad Productividad

3 Definido

Estandarización del proceso

2 Gestionado

Gestión de proyectos básica

Riesgo Retrabajo

1 Inicial
© ESI 2008

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

Resumen CMMI-DEV
Escalonada
ML5 ML4 ML3 ML2 ML 1 Organizació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

Áreas de proceso
Capacidad
Innovació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)

Continua

PA

Proceso
Gestión Proceso

PA

PA

OPF, OPD, OT, OPP, OID

Gestión Proyecto
PP, PMC, SAM, IPM, RSKM, QPM

Soporte
CM, PPQA, MA, CAR, DAR

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

Ingeniería
REQM, RD, TS, PI, VER, VAL

© ESI 2008

41

Ejemplo -Uso de la representación continua en una factoría SW
FRONT OFFICE: Desarrollo de Requisitos Gestión del Proyecto Aceptación del Producto BACK OFFICE: Diseño Técnico Construcción Pruebas

• Si las dos áreas son entidades distintas, el uso de la representación escalonada (nivel 2 o 3 de madurez) para abordar un programa de mejora no sería eficiente • La representación continua facilitaría un mejor despliegue de la mejora en cada una de las áreas y su posterior integración
La representación continua ayuda a las organizaciones a dirigir su capacidad de mejora concentrándose en aquellas áreas que son críticas para su negocio
© ESI 2008 42

Uso de la representación continua en una empresa que externaliza el desarrollo
En este ejemplo se está mostrando que la organización está gestionando óptimamente los proyectos, las fases de recogida y gestión de requisitos y la de aceptación del desarrollo externalizado. La organización además hace mucho hincapié en la gestión cuantitativa de los indicadores críticos con el proveedor (SLAs)
Nivel 3 Nivel 2 Nivel 1 OPF OPD PP PMC SAM IPM RSKM RD REQM VAL CM PPQA MA

© ESI 2008

43

Representación Continua en un vistazo
Ventajas • Apropiada para:
– Empresas con recursos limitados para la mejora – Diferentes entidades con diferentes grados de institucionalización

Riesgos
• Necesidad muy alta de conocimiento de cómo el modelo CMMI puede ayudar a la mejora del negocio (selección de áreas no críticas) • Relaciones y dependencias entre las áreas de procesos más difíciles de identificar • Dificultad para establecer prioridades • Grandes logros no claros

• Permite un grado de flexibilidad y adecuación máximo para la mejora del negocio (“máximo retorno de la inversión en mejora”)
© ESI 2008 44

Áreas de proceso de CMMICMMI-DEV

© ESI 2008

45

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 personas Es posible conseguir calidad y resultados excepcionales, siempre que se asignen las mejores personas a las tareas Es difícil predecir los resultados Las prácticas de gestión pueden no ser eficaces

In
© ESI 2008 46

Out

Nivel de Madurez 2: Gestionado

2

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

In

Out

© ESI 2008

47

Áreas de Proceso de ML2
Gestión de Requisitos 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. El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan las actividades 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. El propósito de la Gestión de Acuerdos con Proveedores (SAM) es gestionar la adquisición de productos de proveedores.

Planificación del Proyecto Seguimiento y Control del Proyecto

Gestión de Acuerdos con Proveedores
© ESI 2008

48

Áreas de Proceso de ML2
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. Aseguramiento de la Calidad de Proceso y Producto Gestión de la Configuración 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. El propósito de la Gestión de la Configuración (CM) es establecer y mantener la integridad de los productos de trabajo utilizando la identificación, control, contabilidad de estado y auditorías de la configuración.

© ESI 2008

49

Ejemplo Gestión de Requisitos
G ALS
SG1: Gestionar Requisitos Se gestionan los requisitos y se identifican las inconsistencias con los planes de proyecto y productos de trabajo.

Preguntas clave - ejemplo
1. ¿Cómo se garantiza que los requisitos del cliente están alineados con lo que nosotros entendemos que quiere? 2. ¿Cómo se garantiza la completitud de los requisitos, es decir, que han sido recogidos de forma completa y con el detalle suficiente)? 3. ¿Cómo se garantiza que los requisitos son registrados? 4. Cuando tiene lugar un cambio en un requisito (ej: el cliente solicita modificar un requisito, incluir uno nuevo, etc), ¿cuál es el proceso que se sigue para gestionarlo? Por favor describa el proceso. 5. ¿Cómo se garantiza la trazabilidad entre los requisitos y sus correspondientes cambios? 7. Cuando tiene lugar un cambio en un requisito, ¿cómo actualiza la trazabilidad de requisitos? 8. ¿Cómo se garantiza la correspondencia entre el plan de proyecto y los requisitos? 9 …..
© ESI 2008 50

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

G ALS

SG1: Evaluar Objetivamente Procesos y Productos de trabajo Se 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 Objetiva Las no conformidades son supervisadas y comunicados con objetividad, asegurando su resolución.

© ESI 2008

51

Ejemplo Aseguramiento de la Calidad del Proceso y Producto
Preguntas Clave - Ejemplo
1. Describa brevemente como se ejecuta una auditoría de aseguramiento de la calidad (cómo se planifica, se ejecuta, se reportan los resultados, etc) 2. ¿Cuáles son los procesos y productos de trabajo que se auditan? 3. ¿Cuáles son los criterios para seleccionar los proyectos y productos de trabajo a auditar? 4. ¿Qué tipo de auditorías de aseguramiento de la calidad existen?, ¿cuándo se deben realizar?, ¿se dispone de una checklist para cada tipo de auditoría? 5. ¿Cómo se garantiza que las auditorías de aseguramiento de la calidad se realizan de manera objetiva?, ¿quiénes son los auditores? 6. ¿Existe un plan general de auditorías que recopile todas las actividades del proceso de aseguramiento de la calidad?, ¿podría describir su contenido?, ¿para qué período de tiempo?, ¿se actualiza dicho plan?, ¿incluyen los planes de proyecto actividades de aseguramiento de la calidad? 7. ¿Se genera un informe de resultados de cada auditoría?, ¿qué contiene dicho informe? 8. ¿Dónde se registran las no-conformidades?, ¿qué atributos lleva asociados la noconformidad (ej: responsable de resolución, fecha estimada de resolución, etc)?
© ESI 2008 52

Ejemplo Aseguramiento de la Calidad del Proceso y Producto
Preguntas Clave - Ejemplo
9. ¿Cómo se registran las fechas de cierre de las no-conformidades?, ¿quién es el responsable de cerrar la no-conformidad? 10. ¿Quién es el responsable de garantizar la resolución de las no- conformidades?, ¿cómo revisa las no-conformidades abiertas?, ¿con qué frecuencia? 11. En caso de que una no-conformidad no pueda ser resuelta por el equipo del proyecto, ¿cuál es el mecanismo de escalado? 12. ¿Dónde se almacenan los informes y resultados de las actividades de aseguramiento de la calidad?, ¿a quiénes están accesibles? 13. ¿Qué tipo de métricas existen para el análisis de las no-conformidades (ej: número de no-conformidades identificadas, abiertas, cerradas)?, ¿con qué frecuencia se comunican las tendencias de calidad a los agentes involucrados?

© ESI 2008

53

Nivel de Madurez 3: Definido

3

• 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

In
© ESI 2008 54

Out

Áreas de Proceso de ML3
Desarrollo de Requisitos Solución Técnica El propósito del Desarrollo de Requisitos (RD) es producir y analizar los requisitos del cliente, del producto, y de los componentes del producto. El 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. El 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. El propósito de la Verificación (VER) es asegurar que los productos de trabajo seleccionados cumplen con los requisitos especificados. 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.
55

Integración de Producto Verificación

Validación

© ESI 2008

Áreas de Proceso de ML3
Enfoque al Proceso Organizativo El 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. 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. El 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.
56

Definición del Proceso Organizativo + IPPD Formación Organizativa

© ESI 2008

Áreas de Proceso de ML3
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.

Gestión del El propósito de la Gestión del Riesgo (RSKM) es identificar Riesgo 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. Análisis de El propósito del Análisis de Decisiones y Soluciones (DAR) es Decisiones analizar posibles decisiones utilizando un proceso de evaluación y formal, que evalúa alternativas siguiendo criterios establecidos. Soluciones
© ESI 2008 57

Nivel de Madurez 4: Gestionado Cuantitativamente
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 58

4

Proceso Gestionado Cuantitativamente
In Out

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.

© ESI 2008

59

Áreas de Proceso de ML4
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. 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.

Gestión de Proyectos Cuantitativa

© ESI 2008

60

5

Nivel de Madurez 5: En Optimización
Se identifican, evalúan y despliegan mejoras incrementales e innovadoras que incrementan (de forma medible) las capacidades de los procesos. Se utilizan mediciones para: seleccionar mejoras e innovaciones estimar y medir los costes y beneficios de las mejoras e innovaciones Los análisis se dirigen a conocer y resolver las causas comunes de variación de los procesos
© ESI 2008 61

Procesos en Optimización
In Out

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
© ESI 2008 62

Foco en la Mejora Continua
Diagrama de control de la capacidad

Zona inicial de control de la calidad

Pérdida crónica
Quality Improvement

New zone of quality control Nueva

zona de control

Mejora de la calidad

Pérdida crónica se ha reducido

La mejora continua significa mejorar la capacidad medible de los procesos de manera controlada
© ESI 2008 63

Áreas de Proceso de ML5
Innovació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. 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.

Análisis Causal y Soluciones

© ESI 2008

64

Resumen CMMI-DEV

© ESI 2008

65

Modelo IT Mark

© ESI 2008

66

¿Qué es IT Mark?

• IT Mark = Reconocimiento de Excelencia en Tecnologías de la Información • IT Mark = el primer servicio internacional de certificación que evalúa los procesos técnicos y de negocio, diseñado específicamente para PYMEs del sector TI • IT Mark = un servicio clave diseñado para PYMEs, que las ayuda a posicionarse a través de la Mejora Continua, arrancando una iniciativa de mejora con sostenibilidad.

© ESI 2008

67

Público Objetivo
• Empresas que desarrollan y mantienen soluciones en TI • Un modelo adaptado para una PYME debería ayudar a – Mejorar los procesos software – Mejorar otros procesos importantes – Entrar en el movimiento de Calidad – Reconocer la excelencia • Diseñado para Pequeñas y Micro Empresas (menos de 10 empleados), aunque también es aplicable para grandes Organizaciones
© ESI 2008 68

¿Qué evalúa ITMark?
– Procesos de gestión y desarrollo de software – Procesos de gestión del negocio – Procesos de gestión de la seguridad de información

© ESI 2008

69

¿En qué modelos se basa ITMark?
– Procesos de gestión y desarrollo software • CMMI-DEV v1.2, la representación escalonada, niveles de madurez 2 y 3 – Procesos de gestión de negocio • Ten squared (10²) – Procesos de gestión de la seguridad de la información • ISO/IEC 27002:2005 Information technology – Security techniques – Code of practice for information security management • ISO/IEC 27001:2005 Information technology – Security techniques – Information security management systems – Requirements

© ESI 2008

70

Niveles IT Mark (1)
• I.T. Mark: acredita que la empresa es conciente de los temas relacionados con la gestión Técnica, de la Seguridad y del Negocio y ha realizado pasos para controlarlos. • I.T. Mark Premium: acredita que la empresa ha alcanzado un Buen nivel de la capacidad de los procesos de Negocio, Seguridad y Desarrollo de Software según los modelos reconocidos en el mundo. • I.T. Mark Elite: acredita que la empresa ha alcanzado un Alto nivel de Definición e Institucionalización de sus procesos de Negocio, Seguridad y Desarrollo de Software, así como que la calidad de sus productos es buena debido a su proceso de mejora continua.

© ESI 2008

71

Niveles IT Mark
Nivel Evaluación de los procesos de negocio Evaluación de los procesos de seguridad de la información Evaluación de los proceso de gestión y desarrollo de software Clase de la evaluación Hallazgos Ningún área de proceso en rojo & Nº áreas de proceso en verde >=11 Ningún área de proceso en rojo & Nº áreas de proceso en verde >=3 Clase B: No más de 2 AP en rojo. Estas AP no pueden ser ni PP, ni PMC. Clase C: No más de 2 AP alcanzando menos de 50%. Estas AP no pueden ser ni PP, ni PMC.

No hay categoría en rojo y > 75%

Nivel 3

Clase B, Nivel de madurez 3

No hay categoría en rojo y > 60%

Nivel 2

Clase B, Nivel de madurez 2

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

Nivel 1

Clase C, Nivel de madurez 2

© ESI 2008

72

ITMark: Un camino de mejora de procesos para pymes
2-3 semanas, 2 evaluadores 8 días, 2 evaluadores (L2) Level 3 Class B
Level 2 Class B 102 Doc. Review

Empres a objetivo ME y GE

PYME

4 días, 1evaluador

InfoSec Snapsho t

Level 2 Class C

102 Interview

Micro y pymes

Inf. Security (ISO 27001)

SPI (CMMI)

Business (10 Sq.)
Negocio Clientes

Procesos
© ESI 2008 73

Niveles de IT Mark y CMMI
5. En optimización 4. Gestionado cuantitativamente 3. Definido 2. Gestionado

1. Inicial

CMMI

© ESI 2008

74

Conclusiones

© ESI 2008

75

Las premisas a considerar
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

© ESI 2008

76

CMMI desarrollo de negocio
• Reducir el desarrollo/ coste de mantenimiento
– Mejorar la productividad – Menor re-trabajo

• Aumento de ingresos y beneficios

• Mejorar la satisfacción del cliente
– Reducir defectos post-entrega – Mejoras visibles de la calidad y fiabilidad

• Se repite el negocio • Incremento de ventas del producto

• Reducción de ciclos
– Mejora en la realización del proceso

• Mejora del time to market • Bonus por pronta entrega • Reducción en la rotación de personal y en los gastos de readaptación • Mejora de la ventaja competitiva

• Mejorar el staff profesional
– Mejorar la moral del trabajador – Aumentar la confianza del desarrollador/personal de soporte

Mejores productos – no sólo software – salen antes y con menor coste
© ESI 2008 77

Qué es y qué no es CMMI
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 objetivos El modelo CMMI no es una certificación → Ayuda a encontrar los huecos que existen entre la manera de trabajar y la manera en la que 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.

© ESI 2008

78

Beneficios vs. madurez

© ESI 2008

79

ROI vs. madurez

© ESI 2008

80

Caso de estudio ABB
• Unidad de desarrollo de 30-35 ingenieros SW/HW • Comienza el programa de trabajo Q1-03, sin experiencia previa CMMI. • CMMI programa: Level2 + Req. Dev. + Verification • Objetivo del programa: 25% COPQ ( Cost of Poor Quality: cost of fixing SW/HW errors found before product is shipped to customer) • Resultados: •COPQ reducido en un 30% •ROI: 2:1 en el primer año

© ESI 2008

81

http://www.sei.cmu.edu/pub/documents/06.reports/pdf/06tr004.pdf

Resultados Cuantitativos Nivel 4

© ESI 2008

82

Resultados Cuantitativos Nivel 4

© ESI 2008

83

Todo tipo de organizaciones..

© ESI 2008

84

Todo tipo de organizaciones..
• Basado en datos de SEI (Marzo 2008), empresas que han evaluado (2635 en total) según la cantidad de empleados (tamaño de la organización) – 50.8% son organizaciones de menos de 100
• El 13.6% hasta de 25 empleados • El 15.6% entre 26 y 50 • El 12.8% entre 51 y 75

Datos en España
CMMI NIVEL 1 NIVEL 2 NIVEL 3 NIVEL 4 NIVEL 5 TOTAL ORGANIZACIONES 1 49 21 1 3 75 1% 65% 28% 1% 4%

35 PYME 71% - Nv. 2

EMPRESAS SOLICITUDES PLAN AVANZA 2006 CMMI SPICE 9001 TOTAL 28 17 12 57 2007 101 3 7 111 195% 361%

•Marzo 2007 – 31 •Marzo 2008 – 75 incremento 242%
© ESI 2008 85

Para más información …

José Ramón Lamenca Gerente de Servicios
JoseRamon.Lamenca@esi.es

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

© ESI 2008

86

European Software Institute (ESI)
• 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
Instalaciones de ESI en > Zamudio, Bizkaia (España)

ESI es Miembro de:

ESI esta Acreditado por:

ISO 9001:2000 Certif. DNV 2367

© ESI 2008

87

Patronos de la Fundación

© ESI 2008

88

Nuestra Misión
Contribuir al desarrollo de la

Sociedad

de la Información y al incremento de la competitividad de la industria... ... a través del conocimiento, la innovación, la mejora continua, ... y la promoción y difusión de las Tecnologías de la Información.

© ESI 2008

89

Capacidades en Formación – 8 Instructores oficiales para CMMI, acreditados por el Software Engineering Institute (español, inglés, búlgaro y francés). – SEI Transition Partners para la provisión de cursos oficiales CMMI desde 2003 (para SW CMM desde 1996) – Más de 2.200 personas formadas oficialmente por ESI en todo el mundo en más de 450 organizaciones de 20 países – Cursos y seminarios impartidos bajo catálogo, o según las necesidades de los clientes – Seminarios impartidos por consultores senior con amplia experiencia en la implantación del modelos CMMI

© ESI 2008

90

Capacidades en Consultoría
– 10 SCAMPI Lead Appraisers (CMMI) – SEI Transition Partners para la realización de Evaluaciones Clase A (CMM / CMMI) desde 1996 100 SCAMPIs clase A, en todos los niveles de 2 a 5. – 17 personas dedicadas full-time a proveer servicios CMMI – Prácticamente la totalidad del personal técnico de ESI está oficialmente formado en el modelo CMMI – Implantando CMMI, niveles 2 a 5, en la actualidad en más de 250 organizaciones de España, Portugal, Alemania, Dinamarca, Irlanda, Italia, Hungría, Bulgaria, Lituania, Letonia, México, Argentina, Perú, Brasil, Chile, Venezuela, Uruguay, Corea, China, EE.UU, Australia,… – En diversos sectores: servicios, telecomunicaciones, sector financiero y bancario, automoción, ferroviario, energía y utilities
© ESI 2008 91

Para más información …

José Ramón Lamenca Gerente de Servicios
JoseRamon.Lamenca@esi.es

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

© ESI 2008

92

You're Reading a Free Preview

Descarga
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->