Modelo de Madurez

Modelos de Madurez
Itinerario
 Introducción
The Process Maturity Framework
CMM 1.1
 Conceptos de CMM 1.1
Process
Capability / Maturity / Performance
Niveles de Madurez / Capacidad
 Métodos de Evaluación
IDEAL approach
Experiencias / Datos
 ¿Como cambia CMMi?
 Conclusiones
Ingeniería de Software II
Modelo de madurez
2
Process Maturity Framework
Financiado por el DoD, en 10 meses se construye la
p
r
i
m
e
r
v
e
r
s
i
ó
n
[
H
u
m
p
h
r
e
y
’
8
7
]
.
Tiene como objetivo asistir a las organizaciones para
mejorar su capacidad para producir software de
calidad.
Ingeniería de Software II
Modelo de madurez
3
Process Maturity Framework
Creación de ...
“
S
o
f
t
w
a
r
eP
r
o
c
e
s
s
A
s
s
e
s
me
n
t
”
“
S
o
f
t
w
a
r
eP
r
o
c
e
s
s
E
v
a
l
u
a
t
i
o
n
”
“
P
r
o
c
e
s
s
Ma
t
u
r
i
t
y
Q
u
e
s
t
i
o
n
n
a
i
r
e
”
Ingeniería de Software II
Modelo de madurez
4
CMM 1.1
Durante 3 años se recolecta información de la
implementación del Process Maturity Framework
S
e
c
r
e
ae
n’
9
0
l
ap
r
i
me
r
v
e
r
s
i
o
nC
MMv
1
.
0
S
ea
j
u
s
t
aa
c
o
r
d
e
a
l
ae
x
p
e
r
i
e
n
c
i
ay
e
n’
9
2s
e
c
r
e
a
CMM v1.1
Ingeniería de Software II
Modelo de madurez
5
¿Qué es un proceso?
Un proceso es una secuencia de pasos efectuados
para un propósito determinado.
Un proceso integra personas, métodos y
herramientas.
E
s
“
l
oq
u
e
h
a
c
e
mo
s
”
p
a
r
a
c
u
m
p
l
i
r
c
o
nu
n
o
b
j
e
t
i
v
o
=
>
Una descripción de proceso, no es un proceso.
Ingeniería de Software II
Modelo de madurez
6
Proceso
Definición según CMM
“
AS
o
f
t
w
a
r
e
P
r
o
c
e
s
s
c
a
n
b
e
d
e
f
i
n
e
d
a
s
a
s
e
t
o
f
a
c
t
i
v
i
t
i
e
s
,
m
e
t
h
o
d
s
,
practices and transformations that people employ to develop and
m
a
i
n
t
a
i
n
s
o
f
t
w
a
r
e
a
n
d
t
h
e
a
s
s
o
c
i
a
t
e
d
p
r
o
d
u
c
t
s
”
CMM enfoca su esfuerzo en los procesos como una forma de
potenciar a las personas que hacen efectivamente el trabajo.
La calidad del producto se encuentra determinada por la calidad
de los procesos que la construyen.
Ingeniería de Software II
Modelo de madurez
7
Proceso
Procedimientos y
Métodos
Personas con
habilidades,
entrenamiento y
motivación
Ingeniería de Software II
Equipamiento y
Herramientas
Modelo de madurez
8
Capability / Maturity / Performance
 Software Process Capability describe el rango esperado de resultado
a partir de seguir un proceso determinado.
Define una forma de predecir la calidad de la salida del siguiente proyecto de
software.
 Software Project Performance es el resultado real de aplicar los
procesos.
La variación con respecto al esperado se conoce como ruido y debería tambien estar
controlado.
 Software Process Maturity define el poder de una organización para
mejorar la calidad de sus procesos y la consistencia en la cual los
mismos son aplicados a lo largo de diferentes proyectos de la
organización.
Ingeniería de Software II
Modelo de madurez
9
Capability / Maturity / Performance
Predicción de Performance
Capability
Ingeniería de Software II
Performance
Modelo de madurez
10
Capability / Maturity / Performance
Process Improvement
Capability
Improvement
Maturity
Ingeniería de Software II
Modelo de madurez
11
Maturity Level / Capability
Cada nivel se caracteriza por la práctica de
actividades que garanticen que cierto tipo de
problemas serán evitados.
Ingeniería de Software II
Modelo de madurez
12
Maturity Level / Capability:
–
Initial
Level 1
S
ec
a
r
a
c
t
e
r
i
z
a
p
o
r
l
ap
r
e
s
e
n
c
i
ad
e
“
h
é
r
o
e
s
”
g
r
a
c
i
a
s
a
los cuales los proyectos alcanzan el éxito.
La administración de los proyectos es ad-hoc.
Dependiente de cada manager en particular.
La integridad de los entregables no esta garantizada.
La performance de la organización es impredecible.
Ingeniería de Software II
Modelo de madurez
13
Héroes
“
Successfull software projects are a sequence of
problems encountered and effectively solved.”
[James Bach –Enough About Process: WHAT We Need
are Heroes]
La performance de la organización es dependiente
de las personas.
Ingeniería de Software II
Modelo de madurez
14
Level 2 –
Repeatable
Ingeniería de Software II
Modelo de madurez
15
2–
Repeatable
Control la variación entre fecha esperada y fecha real de los
entregables.
Software Project Planning (SPP)
Software Project Tracking and Oversight (SPTO)
Integridad de producto instalado y en desarrollo.
Software Configuration Management (SCM)
Predicción de Performance.
Software Quality Assurance (SQA)
Consistencia con el Cliente
Requirement Management
Ingeniería de Software II
Modelo de madurez
16
Level 2 –
Repeatable
L
ao
r
g
a
n
i
z
a
c
i
ó
n
p
o
s
e
eu
n
a
c
a
p
a
c
i
d
a
d
“
R
e
p
e
a
t
a
b
l
e
”
en el sentido que a nivel organización se puede
garantizar que la performance alcanzada podrá ser
repetida en futuros proyectos.
La calidad de entrada de los procesos permite
predecir la calidad de salida con un nivel de
verosimilitud controlado.
Ingeniería de Software II
Modelo de madurez
17
2–
Repeatable
Limitaciones
No reutilizo experiencias inter-proyecto.
Problemas por la falta de coordinación entre
proyectos
Ingeniería de Software II
Modelo de madurez
18
Level 3 –
Defined
Ingeniería de Software II
Modelo de madurez
19
Level 3 –
Defined
Integración de Experiencias
Peer Reviews
Training Program
Integroup Coordination
Administración Inter-Proyecto.
Integrated Software Management
Nivel Organizacional
Organization Process Focus
Organization Process Definition
Ingeniería de Software II
Modelo de madurez
20
3–
Defined
El nivel Definido indica que se opera a partir de procesos
establecidos a partir de estándares.
No existen conflictos de realocación por falta de
coordinación.
Prioridad Organizacional
Ingeniería de Software II
Modelo de madurez
21
Level 3 –
Defined
Limitaciones
No se realiza predicción de calidad
No existe administración cuantificable de los procesos
Ingeniería de Software II
Modelo de madurez
22
4–
Managed
Administración Cuantitativa de Procesos
Quantitative Process Management
Predicción de Calidad
Software Quality Management
Ingeniería de Software II
Modelo de madurez
23
4–
Managed
Limitaciones
No existe posibilidad de reaccionar modificando procesos.
No existe garantía que no ocurran errores recurrentes.
Los cambios tecnológicos producen resultados no
cuantificables / controlables.
Ingeniería de Software II
Modelo de madurez
24
5–
Optimized
Reutilización de Defect-CR
Defect Prevention
Control de Cambios Tecnológicos
Technology Change Management
Procesos dinámicos pero controlados
Process Change Management
Ingeniería de Software II
Modelo de madurez
25
5–
Optimized
Limitaciones...
¿ Existen ?
Ingeniería de Software II
Modelo de madurez
26
S
E
I
’
s
I
D
E
A
L
A
p
p
r
o
a
c
h
Initiating
Diagnosing
Evaluating
Acting
Learning
Ingeniería de Software II
Modelo de madurez
27
S
E
I
’
s
I
D
E
A
LA
p
p
r
o
a
c
h
Learning
Revisión de
Objetivo
Organizacional
Documentar y
Analizar Lecciones
Definir
Procesos
y Métricas
Estímulo para
el cambio
Establecer
Contexto
y patrocinio
Initiating
Planear y
Ejecutar Pilots
Establecer
Infraestructura
de mejora
Planear /
Ejecutar y
seguir
Instalación
Evaluar y
caracteriza
practicas
actuales
Desarrollar
Recomendaciones
y documentar
Establecer
resultados
Estrategia y
Prioridades
Diagnosing
Ingeniería de Software II
Acting
Modelo de madurez
Establecer
Teams
Planear
Acciones
Establishing
28
S
E
I
’
s
I
D
E
A
L
A
p
p
r
o
a
c
h
Software Process Assesment
Identificar debilidades y construir un plan de mejora
El cliente es la organización evaluada
Software Capability Evaluation
Identificar proveedores capaces de realizar un trabajo
determinado
El cliente es otra organización contratante.
Ingeniería de Software II
Modelo de madurez
29
S
E
I
’
s
I
D
E
A
L
A
p
p
r
o
a
c
h
1.
Selección de Equipo de Auditoría.
2.
Maturity Questionnaire / samples CMM
3.
Análisis de Respuesta
4.
Visita On-Site / Entrevistas y Documentación de
Revisiones
5.
D
e
t
e
r
mi
n
a
c
i
ó
nd
e“
F
i
n
d
i
n
g
s
”
b
a
s
a
d
o
e
nK
P
A
’
s
g
o
a
l
s
6.
KPA Profile
Ingeniería de Software II
Modelo de madurez
30
Experiencias / Datos
48 compañias
efectuando
1 o 2 evaluaciones
Ingeniería de Software II
Modelo de madurez
31
Experiencias / Datos
37% de las organizaciones calificó en nivel 2 entre
18 y 30 meses.
El más rápido en calificar nivel 2 fue 11 meses.
50% de las organizaciones calificó en nivel 3 entre
18 y 30 meses.
El más rápido en calificar nivel 3 fue 12 meses.
Ingeniería de Software II
Modelo de madurez
32
Experiencias / Datos
El reporte del DoD estaba en lo cierto: Todas las organizaciones encontraron
dificultades en el área de Management.
Ingeniería de Software II
Modelo de madurez
33
¿Cómo cambia CMMi?
Confío vs NO Confío.
Non Technical vs Quality Attributes
Staged vs Contnuos.
Ingeniería de Software II
Modelo de madurez
34
Conclusiones
El modelo cumple con el objetivo de garantizar
performance
Es un modelo muy rígido. De alguna manera induce
a la reducción de cambios sobre los subproductos.
Es difícil aplicar ciclos de vida evolutivos
manteniendo el concepto de calidad de CMM.
Ingeniería de Software II
Modelo de madurez
35
Muchas Gracias!
Ingeniería de Software II
Modelo de madurez
36