CMM 01

Mejoramiento del Proceso de Desarrollo: una visión Ejecutiva

Duración: 4 hs
Roles involucrados: Dirección, Gerencia y Lideres de proyectos
Metodología: exposición participante complementada con presentación de casos prácticos de aplicación
Equipamiento: 1 proyector
1 pc
Material Didáctico: cada participante recibirá una copia del material utilizado durante la capacitación
Contenidos Generales:
Razones por las cuales la mejora del proceso de desarrollo es negocio, organización de la estructura para un proceso de mejora,
comparación de modelos, descripción de CMM, ROI esperado, tiempos esperados de implementación.

Historial de Revisiones
FECHA VER. DESCRIPCION AUTOR Ob
s

01-01-2001 1 Confección inicial jmeles@vates.com

15-08-2003 2.030819 Rediseño completo, agregado de contenidos ecorona@innevo.com

12-01-2004 20040112 Modificaciones a la comparación de CMM vs CMMI ecorona@innevo.com

Mejora del Proceso de desarrollo de
software

Una visión ejecutiva

Agenda
• ¿Es negocio mejorar el proceso de desarrollo?
• Estado actual de nuestra organización
• Modelo de mejora de procesos
• Implementando la mejora
• Descripción del modelo
• CMM: Qué es y que no es
Objetivo de la capacitación

Comprender el por qué de la mejora de

procesos en el desarrollo de software,
cómo se relaciona con el negocio y qué rol
tendrá CMM en sus organizaciones
¿Es negocio mejorar el proceso de desarrollo?

Mejorar el proceso de desarrollo de software

es negocio, y tiene un ROI alto comparado
con otros negocios (promedio de 5:1)
según las estadísticas.
¿Es negocio mejorar el proceso de desarrollo?

Mas allá de las estadísticas...

¿Es negocio para nosotros?

 ¿Es negocio mejorar el proceso de desarrollo?

Para saber si es negocio deberíamos poder

medirlo
• ¿Cuáles beneficios nos trae directamente?
• ¿Cuáles beneficios son inherentes a la mejora de proceso, aunque no
generalmente su razón primaria?
 ¿Es negocio mejorar el proceso de desarrollo?

Debemos buscar la propuesta de valor de la

iniciativa de mejora

• Un proyecto en la mayoría de los casos se inicia y justifica por alguno de

estos tres motivos
Incrementa la rentabilidad en algún área en particular y/o del negocio en
general
De igual manera, disminuye costos
Disminuye ciclos de vida de productos y su salida al mercado
 ¿Es negocio mejorar el proceso de desarrollo?

Esta propuesta de valor generalmente tiene

otros valores agregados

• Afianza relaciones con los clientes

• Abre nuevas posibilidades de negocio
• Contribuye a generar estabilidad en la organización
• Eleva el concepto que nuestros clientes tienen de nosotros
¿Es negocio mejorar el proceso de desarrollo?

Establecemos cómo medir la mejora relacionada al

negocio

Directamente Indirectamente
+ Rentabilidad + Prestigio
- Costos + Competitividad
- Ciclo de producto - Rotación de
personal
+ Clientes
Otros....
¿Es negocio mejorar el proceso de desarrollo?

Mi propuesta de valor para la iniciativa de

mejora de la empresa

?
 ¿Es negocio mejorar el proceso de desarrollo?

Framework de propuesta de valor sugerido

La mejora de proceso es para (la organización),

quien (necesita mejorar xx indicadores - recordar métricas anteriores),
y para implementarla adoptaremos el modelo (XXXX),
esperando como resultado principal (la mejora esperada mejor conectada
a los objetivos de negocio organizacionales)
[y nos diferenciaremos de los demás debido a que nuestra mejora se
orientará a (especialización de la mejora)]
 ¿Es negocio mejorar el proceso de desarrollo?

Ejemplo de propuesta de valor

La mejora de proceso es para INNEVO,
quien necesita
equiparar el nivel de calidad exigido por sus clientes,
aumentar la posibilidad de generar nuevos clientes y
mantener indicadores que permitan mejorar continuamente el proceso
de desarrollo,
y para implementarla adoptaremos el modelo CMM v 1.1,en su nivel 2,
esperando como resultado principal volvernos proveedores de servicios
de las principales fábricas de software del mundo,
y nos diferenciaremos de los demás debido a que nuestra mejora se
orientará a integrarnos con otras empresas de nivel similar o mejor,
sólo del rubro de IT
¿Es negocio mejorar el proceso de desarrollo?

Si encontramos la propuesta de valor

descubrimos cómo incide en el negocio
y definimos si es negocio
para nuestra organización
Estado actual de nuestra
organización
 Estado actual

Comencemos por preguntarnos lo difícil

• ¿Cuáles son los objetivos de nuestros proyectos:

calidad, fechas, tecnología, características de los
productos?
• ¿Tenemos información adecuada de quienes inician los
proyectos (normalmente áreas comerciales o de
marketing)?
• ¿Nos llega adecuadamente la información de los
clientes finales?
• ¿Existe retroalimentación de calidad de quienes dan
soporte y tratan comercialmente a los clientes?
 Estado actual

Comencemos por preguntarnos lo difícil

• ¿Podemos describir el proceso de desarrollo en

pequeños procesos que se intercomunican mediante
entregables?
• ¿Existe una alta rotación de personal?
• ¿Cuánto porcentaje de tiempo anual se le dedica a
capacitación?
• ¿Están comunicados nuestros equipos de trabajo
compartiendo experiencia?
 Estado actual

Descubrir el área de dolor es la premisa

• Ciclo de vida de proyectos

• Expectativas de los clientes
• Delimitación y descripción de requerimientos
• Diseño de los productos
• Estimaciones
• Administración, control y cierre de los proyectos
• Calidad de los productos de software
• ¿Otra?
 Estado actual

Realizar el esfuerzo de obtener métricas

actuales

• LOCs por desarrollador / unidad de tiempo /tecnología

• Unidades de partición por desarrollador (puntos de función, casos
de uso, etc.)
• Densidad de defectos por desarrollador / unidad de tiempo
/tecnología
• Costo LOC
• Casos de uso / Casos de prueba diseñados por unidad de tiempo
• Tiempo medio entre defectos
• Costo medio de resolución de defectos
 Estado actual

Un buen punto de partida para las

métricas es
PSM (Practical Software Measurement)

• www.psmsc.com
• La versión 5 ya está coordinada con estándares de
mejora de procesos como CMM, ISO 15504 y otras
• Se puede adecuar según las necesidades de cada
organización
Estado actual

PSM (Práctical Software Measurement)

Areas comunes de medición en proyectos

Avance y schedule
Recursos y costo
Tamaño de producto y estabilidad
Calidad de producto
Desempeño de proceso
Efectividad de la tecnología
Satisfacción del usuario
Estado actual

Ahora podemos identificar cuán cerca

estamos del objetivo

!
Patrón simple para análisis de empresas

Grado de Personal Proceso definido

madurez capacitado
BASICO No / parcial No

MEDIO Si No

No / parcial Parcial / si

AVANZADO Si Parcial / si
Estado actual

Conectar los objetivos estratégicos de la

organización con
los objetivos de la mejora

Ej.: Objetivos fijados a través de Balanced Scorecard pueden

ser asociados a las métricas de los planes de medición
definidos, y de esta manera monitorear el cumplimiento de
sus objetivos por categoría
Estado actual

Revisemos nuestra cultura organizacional

?
Modelos de mejora de
procesos
 Modelos disponibles

Los modelos de mejora de procesos de

software mas utilizados son:
• CMM
SW-CMM v1.1
CMMI
• ISO
ISO 15504 - SPICE
Modelos disponibles

Estos modelos no definen procesos, sino

establecen un marco sobre el cual
podemos diseñar la estrategia de
mejora.

Tanto SPICE como CMM trabajan con los

conceptos de madurez y capacidad.
capacidad
Modelos disponibles

Capacidad
Rango de resultados esperados para un
proceso definido.

Madurez
Areas de conocimiento que cubre un proceso
definido. Alcance del proceso.
Modelos disponibles

Ambos modelos pueden utilizarse

tanto para diseñar estrategias de
mejora como para realizar
evaluaciones de capacidad y
madurez
Modelos disponibles

CMM
Modelo de Capacidad y Madurez
Lo emite el Software Engineering Institute – SEI,
que es una entidad fundada por el DoD de
USA en conjunto con la universidad de
Carnegie Mellon.
Este instituto se funda en 1984.
Modelos disponibles

CMM
Existen actualmente 2 modelos
activos de CMM:
• SW-CMM
• CMMI
Modelos disponibles

SW-CMM
El modelo mas implementado en
todo el mundo es SW-CMM.
No es una norma, y no se
“certifica”, sólo se evalúa a través
de profesionales reconocidos por
el SEI como Lead Assessors
 Modelos disponibles

¿Que modelo elegimos?

Por qué elegir SW-CMM
• Es el modelo mas expandido
• Es el modelo con mayor cantidad de gente
experimentada en el mercado
• Es el modelo seleccionado por el mayor
mercado de software del mundo (USA)
• Es el más económico de implementar, por el
conocimiento disponible y su tamaño
Modelos disponibles

¿Qué diferencias tienen SW-CMM y

CMMI?
¿Por qué uno u otro?
Modelos disponibles: SW-CMM vs. CMMI
Factores SW-CMM CMMI
Tamaño del Modelo Aprox. 500 páginas Aprox. 1000 páginas
18 áreas claves 22 áreas claves
316 prácticas 417 prácticas
52 Objetivos 70 Objetivos
Vigencia del Modelo en el Desde 1993 Desde 2001
Mercado
Reconocimiento del Modelo en Reconocido como un estándar Se calcula que llevará mas de 4 años
el Mercado constituirse en estándar
Cantidad de empresas Nivel 2 = 70 Nivel 2 = 2
certificadas Nivel 3 = 147 Nivel 3 = 10
Nivel 4 = 86 Nivel 4 = 1
Nivel 5 = 116 Nivel 5 = 7
TOTAL = 419 TOTAL = 21
Características de las Aplicable a cualquier tipo de Preferiblemente organizaciones que
empresas que Organización. Ya hayan trabajado en programas de
lo pueden aplicar Mejora.
Costo de definición del Modelo Menores costos debido a: Mayores costos debido a:
•Existencia de consultores en el •Disponibilidad de
Mercado Consultores con experiencia
•Procesos Maestros disponibles •Poca experiencia generada
Tamaño del sistema de calidad a •Tamaño del sistema de
definir Calidad a definir
Modelos disponibles: SW-CMM vs. CMMI

Factores SW-CMM CMMI

Costo de Certificación Para nivel II aprox. entre Mayores (relación 4 a 1) debido a:
u$s 10.000 y 15.000 •Mayor cantidad de días de
capacitación obligatoria
•Mayor cantidad de trabajo
on-site del Lead Asesor
•Fees más altos por parte
del SEI
•Mayores costos de los
Lead Assessors
Adaptación a Posee guía para adaptar el No posee guía de ajuste para
empresas pequeñas modelo a organizaciones adaptar el modelo a organizaciones
pequeñas. pequeñas.
Existencia de Métricas ROI 1:8 (promedio) No existen datos hasta el momento.
Vigencia del Modelo Año 2002: 109 empresas Año 2002: 18 empresas acreditaron
en el Mercado acreditaron con este con este modelo.
modelo.
 Modelos disponibles: SW-CMM vs. CMMI

Conclusiones
• En empresas donde su área de negocio principal es el desarrollo de
software, las diferencias entre los dos modelos son notables a partir desde
del nivel 3, sin que esto signifique que se hayan quitado áreas clave. Todo el
esfuerzo realizado para SW-CMM, es transferible directamente a CMMI,
ningún esfuerzo se pierde.

• La percepción de la industria es que CMMI se adapta más a empresas

grandes que a pequeñas, para las cuales el fuerte es la entrega rápida de
productos.
 Modelos disponibles: SW-CMM vs. CMMI

Conclusiones
• El CMMI es un modelo nuevo, y aún se le realizan modificaciones y
sugerencias de cambio.
• En las empresas que sólo desarrollan software, el modelo CMMI no
representa mayores ventajas en relación a SW-CMM, sino a partir del tercer
nivel.
• Los procesos de preparación y mejora, tanto como la acreditación para
CMMI son más largos y costosos.
• Si bien consideramos que en pocos años el Modelo CMMI puede ser
referenciado como un estándar en la industria, en la actualidad está
buscando (y construyendo) su convalidación en el mercado.
Modelos disponibles: SW-CMM vs. CMMI

" # $
%
Implementando la mejora
Motivación de la mejora

La calidad necesita de mediciones

que nos den visibilidad sobre el
estado actual de los procesos:

No se puede mejorar lo que no se

puede medir
Motivación de la mejora

CMM se basa en la siguiente premisa

de Process Management

“La calidad de un sistema depende

altamente de la calidad del proceso
utilizado para adquirirlo,
desarrollarlo y mantenerlo”
Motivación de la mejora

CMM permite definir una estrategia

de mejora, debido a su estructura
de niveles de madurez, y la
cobertura incremental de nuevas
áreas a medida que se sube el nivel
de madurez

Esto permite enfocarse

Liderazgo de la mejora

Conectando los conceptos vistos hasta el

momento, necesitamos:
Alinear la mejora al negocio
Seguir una estrategia de mejora
Medir claramente la mejora y su impacto

Ayuda mucho el hecho de que la mejora

se encuentre dentro de la visión de la
compañía
Liderazgo de la mejora

Componentes de la visión

Formulada por los líderes y no las masas

Compartida con el equipo
Amplia y detallada
Positiva y alentadora

Visión según Joel Barker

Liderazgo de la mejora

Para poder realizar todo esto

correctamente, el líder de la mejora
de procesos a nivel organizacional
es:

La Dirección General
Patrón de la mejora

Un patrón simple a usar es aquel que

pude ser memorizado por todos

1. Comprender el modelo a usar en la mejora (CMM)

2. Comprender la diferencia entre las prácticas actuales
y las práctica deseadas
3. Definir los procesos necesarios para cumplir las
metas de mejora
4. Asegurar que el proceso es seguido y continuamente
mejorado
Patrón de la mejora

SEPG
Software Engineering Process Group

Su ROL es conducir y facilitar el proceso de mejora

mediante el cual la organización aprende de sí misma

Mediante la asignación de recursos a esta actividad, la

organización responsabiliza a alguien (individual o equipo)
de tomarse el tiempo necesario para mantener la
perspectiva de la mejora
Patrón de la mejora

SEPG
Una de sus principales actividades es documentar, capturar la cultura
organizacional, adecuar los procesos maestros, y continuar
documentando

¿Por qué se documenta?

Capturar intenciones para referencia en casos de que alguien olvide

detalles de lo acordado previamente
Capturar expectativas para usar en estimaciones y planificación de
actividades
Capturar expectativas de comunicación, como planes, reportes,
registros, de manera que la gente entienda cómo interactúa con otra
gente, y poder además comparar resultados reales contra esperados
Patrón de la mejora

SEPG
¿Qué ocurre si no lo tenemos definido?

Problema 1: El desarrollo de la mejora y su planificación se

hacen en tiempos “libres”

Problema 2: Los esfuerzos de mejora no se planifican ni se

monitorean
 Infraestructura para la mejora

&'
(
& ) * &. ) ) * )
)
&+ , - & )
&, * ) "
" " * / /

& ) " " 0 # 1 2 31

# " 1 4
&. ) , - "
"
&+
&,
Infraestructura para la mejora

4
' ''

-- ""

5 56 6 ""

- ) 5 56 6 "" 5 56 6 "" 5 56 6 "" 77

, - 5 56 6 5 56 6 5 56 6

- ) '' '' ''

Organización del proyecto
Iniciación
Propósito
Establecer el marco de procesos y
capacitación necesarios para alcanzar
el nivel de madurez requerido.
Actividades principales
Definir y adecuar procesos, capacitar
equipos, mentoring y evaluaciones
internas.
Adquirir
Establecer visión – Plan de Acción - Ejecución
Transición
Propósito
Asistir a la organización en los ajustes
necesarios para que el modelo sea
operacional de manera de poder
realizar un assessment del tipo CBA-
IPI (mediante un lead asesor).
Actividades principales
Recolectar métricas, recomendar
ajustes necesarios a los procesos,
realizar evaluaciones internas.
Implementar
Institucionalización
Propósito
Operar los procesos y expandirlos a
todas las áreas de la organización que
lo requieran.
Representar y modificar los procesos
de acuerdo a la dinámica de la
organización.
Actividades principales
Operar en el mantenimiento y la
mejora continua mediante los grupos
establecidos de SEPG y QA.
Incorporar paulatinamente proyectos
al modelo.
Operar
Organización del proyecto

Paso a paso
1. Establecer visión (Envisioning)
a. Sabemos que hacemos ahora y que necesitamos
que se haga
2. Establecer plan de acción (Encoding)
a. Decidimos qué hacer y lo documentamos
3. Ejecutar (Enacting)
a. Lo hacemos y mejoramos la performance
Organización del proyecto

Enfocarse
1. Establecer visión (Envisioning)
a. Entender el modelo CMM y los conceptos
relacionados a su implementación y cambio cultural
b. Compartir el conocimiento y la forma en que se
comprende el modelo, discutirlo y asimilar puntos de
vista
Organización del proyecto

Enfocarse
2. Establecer plan de acción (Encoding)
a. Mantener la esencia de QUÉ debe ser capturado. No llenar el
proceso con texto que nunca se leerá. Mantenerlo simple facilita
que se pueda seguir.
b. El proceso debe ser comprensible de manera fácil
c. El proceso debe ser de alto nivel para tareas conocidas y
comunes, y detallado para tareas críticas y de alto riesgo
d. Inicie, y mejore en ciclos subsiguientes. No se paralice.
Organización del proyecto

Enfocarse
3. Ejecutar (Enacting)
a. Soportar la adopción del proceso. Si el proceso
facilita las cosas, será mas fácil adoptarlo.
b. Los gerentes y los colegas deben soportar el uso del
proceso.
c. Ayude a la gente a saber como le está yendo en la
adopción de las nuevas prácticas.
d. Mantenga la mejora de forma continua, repitiendo
estos pasos.
Descripción del modelo
El modelo CMM

Organización
El modelo se organiza en niveles de madurez

1. Procesos Ad hoc: Batallando con las mismas crisis una y otra vez
2. Proceso Repetible: Encontrando un patrón, capturarlo y repetirlo
3. Proceso Definido: Alterando el patrón para que encaje en la
situación actual
4. Proceso Gestionado Cuantitativamente: manteniendo el camino a
la meta
5. Proceso Continuamente optimizado: Creando o usando nuevos
métodos para exceder las metas
 Hechos de la vida real

De Marco dice que en las organizaciones de software es común

que se presenten estas situaciones:
• “...se quejan de nosotros por que saben que si se quejan
trabajaremos mas...”
• “...la mayoría de los reportes muestran que nuestras
estimaciones son terribles, pero nadie estuvo o está en
desacuerdo con nuestro método de estimación...”
• “...un plan correcto no sólo tiene que parecer imposible, sino
que debe ser ridículamente imposible”
DeMarco plantea que nuestra industria está sobrecargada y se
percibe como si la única opción fuera pagar para ser mas
veloces sacrificando calidad.
Organizaciones maduras

Posee capacidad de administrar procesos de

desarrollo de software y de mantenimiento.

El proceso de desarrollo de software está bien

definido, el personal existente en la organización lo
conoce y las actividades del proceso se llevan a
cabo conforme a lo planeado.

Los procesos definidos se actualizan cuando es

necesario y se mejoran a través de pruebas piloto y/o
análisis de costo beneficio.
Organizaciones maduras
Los gerentes monitorean la calidad de los productos
de software y la satisfacción del cliente.

Existe una base cuantitativa para medir la calidad

del producto.

Los calendarios y presupuestos se basan en el

desempeño histórico y son realistas.

Como resultado de todo lo anterior, por lo general se

logran los resultados esperados de costo,
calendarización, funcionalidad y calidad del producto.
 El modelo CMM
Descripción de niveles
Productividad
y Calidad
Nivel
• mejora continua de los procesos
5 Optimizado
• retroalimentación de métricas cuantitativas de los procesos
• aplicación de ideas innovadoras y tecnologías
• recolección de métricas detalladas del proceso y calidad de los productos
4 Nivel
Administrado • control cuantitativo del proceso y los productos
• procesos de software (administración e ingeniería) documentados y
3 Nivel
Definido
estandarizados
• los proyectos usan una versión especializada de los procesos estándares
Nivel • procesos de administración de proyectos establecidos
2 Repetible • se monitorean costo, tiempo y funcionalidad

• proceso de desarrollo “a la medida” y ocasionalmente caótico

1 Nivel • pocos procesos se encuentran definidos
Inicial • el éxito depende de los esfuerzos individuales y heroísmos Riesgo
El modelo CMM – Revisión de niveles
Foco Administración Organizacional Ingeniería

5
Optimizado
Mejora
Continua
Prevención de Defectos Manejo de Cambios a
Procesos
Manejo de Cambios
de Tecnologías

4
Administrado
Calidad del
Proceso y del Manejo Cuantitativo de Procesos
Manejo de la
Calidad del
Software
Producto

Foco Organizacional en los

Foco Ingeniería de

3
Manejo Integrado del Software Procesos
organizacional en Productos de
Coordinación Intergrupal Definición de Procesos Software
los Procesos e
Organizacional
Definido Ingeniería de Revisión entre
Software Programa de Entrenamiento Colegas
Manejo de Requerimientos
Planeación del Proyecto de Software
Seguimiento y supervisión del

2 Administración de
Proyectos
Proyecto de Software
Aseguramiento de la Calidad de
Software
Repetible Manejo de la Configuración del
Software
Manejo del Subcontrato de Software

1
Inicial
Procesos a la medida
El modelo CMM – Revisión de niveles

Nivel 1: Para producir

Solo hazlo. Actividad Resultados
 El modelo CMM – Revisión de niveles

Actividades realizadas Actividades Capacidad resultante

por la Organización realizadas por los
proyecto
La organización carece Durante las crisis, los
de prácticas de proyectos abandonan los
administración sólidas procedimientos
planeados
Las buenas prácticas de
ingeniería de software Aún los procesos fuertes
están minadas por la de ingeniería de software
mala planeación y por las no pueden superar la
reacciones para poder inestabilidad creada por
cumplir con el sistema la ausencia de prácticas
comprometido de administración sólidas
del proceso
Capacidad del Proceso de
Software es impredecible
debido a que el proceso
es cambiado o modificado
constantemente durante el
avance del trabajo
(ejemplo, el proceso es ad
hoc)
Pocos procesos estables
El modelo CMM – Revisión de niveles

Planeación
Nivel 2: Para producir
Piensa antes de
actuar, y piensa Actividad Resultados
después de actuar
Entrada para
para asegurarte de
que lo hiciste bien.
Evaluación Para mejorar
 El modelo CMM – Revisión de niveles
Actividades realizadas
por la Organización
Se establecen las políticas y
procedimientos para la
administración de proyectos de
software
Procesos efectivos de manejo
de proyectos se institucionalizan
lo cual permite a nuevos
proyectos repetir las prácticas
exitosas desarrolladas en
proyectos anteriores a pesar de
que los procesos específicos del
proyecto sean diferentes
Actividades realizadas
por los proyectos
Se hacen compromisos
realistas en el proyecto
basados en resultados de
proyectos anteriores y los
requerimientos actuales del
proyecto
Se da seguimiento al costo,
calendario y funcionalidad del
software para identificar
problemas para alcanzar los
compromisos
Capacidad resultante
del proceso
La Capacidad de Proceso de
Software es disciplinada
debido a que la planeación y
seguimiento del proyecto son
estables y los éxitos
anteriores pueden ser
repetidos
Los procesos del proyecto
están bajo un control efectivo
del sistema de administración
del proyecto, siguiendo
planes realistas
El modelo CMM – Revisión de niveles

Aseguramiento de
Manejo de los
la Calidad del
Requerimientos
Software

Planeación del Manejo de la

Proyecto de Configuración del
Software Software

Seguimiento y Manejo del

supervisión del Subcontrato de
proyecto de Software Software
El modelo CMM – Revisión de niveles

Planeación
Entrada para
Para producir

Estándares Actividad Resultados

Entrada para
Entrada para
Evaluación
Para mejorar

Usa las lecciones que aprendiste

 El modelo CMM – Revisión de niveles

Actividades realizadas Actividades realizadas por Capacidad resultante del

por la Organización los proyectos proceso

Se documenta el Proceso La Capacidad del Proceso

Los proyectos adecuan el
estándar de la organización de Software es estándar y
proceso estándar de software
para el desarrollo y consistente debido a que
de la organización para
mantenimiento de software tanto las actividades de
desarrollar el proceso definido
para su proyecto ingeniería de software y de
Se integran los procesos de administración son
manejo de proyecto y estables y repetibles
Debido a que el proceso de
procesos de ingeniería de
software está bien definido, la
software; se explotan prácticas El costo, calendario y
gerencia tiene buena visibilidad
efectivas de ingeniería de funcionalidad están bajo
dentro del progreso técnico de
software control, se le da
todos los proyectos
seguimiento a la calidad del
Se da soporte al proceso software
(SEPG)
El modelo CMM – Revisión de niveles

Foco de la Definición de
Organización en Procesos
Procesos Organizacional

Programa de Coordinación Revisión

entrenamiento Intergrupal entre
colegas

Manejo integrado del Ingeniería del

Software Producto de
Software
El modelo CMM – Revisión de niveles

Planeación Para predecir

Entrada para
Para producir

Estándares Actividad Resultados

Entrada para
Entrada para
Evaluación
Para mejorar

Predice los resultados que esperas y

necesitas, luego entonces, crea las
oportunidades para obtener esos resultados
 El modelo CMM – Revisión de niveles
Actividades realizadas
por la Organización
Se establecen metas de
calidad cuantitativas para los
productos de software y los
procesos. Se tienen
mediciones de productividad
y calidad para actividades
importantes del proceso de
software a través de todos
los proyectos como parte de
un programa de métricas
organizacional.
Provee los fundamentos
para evaluaciones
cuantitativas
!
Actividades realizadas
por los proyecto
Los proyectos controlan sus
productos y procesos
limitando la variación en el
desempeño de su proceso
para caer dentro de los límites
aceptables establecidos
El riesgo de la curva de
aprendizaje debido a moverse
a un nuevo dominio de
aplicación es conocido y
manejado cuidadosamente
Capacidad resultante del
proceso
La Capacidad del Proceso de
software es predecible
debido a que el proceso es
medido y opera dentro de los
límites establecidos
Permite predecir tendencias
en los procesos y la calidad
dentro de límites
cuantitativos, permite tomar
acciones correctivas cuando
los límites son excedidos
El modelo CMM – Revisión de niveles

Manejo de la Manejo
calidad del cuantitativo de
Software Procesos
El modelo CMM – Revisión de niveles
"

Planeación Para predecir

Entrada para
Para producir

Estándares Actividad Resultados

Entrada para Entrada para

Evaluación
Para mejorar Para mejorar

Genera lecciones aprendidas, usa las lecciones aprendidas para generar más lecciones
aprendidas, y así sucesivamente
 El modelo CMM – Revisión de niveles
Actividades realizadas
por la Organización
Toda la organización está
enfocada a la mejora continua
de procesos con la meta de
prevención de defectos.
La información se utiliza para
hacer el análisis de costo-
beneficio de nuevas
tecnologías y cambios a
nuevos procesos. Innovaciones
a las prácticas de ingeniería de
software se transfieren a toda
la organización
"# ! $
Actividades realizadas
por los Proyectos
Los equipos de proyecto
analizan defectos y
determinan su causa
Los equipos de proyecto
evalúan los procesos para
prevenir que los defectos ya
conocidos ocurran
nuevamente
Capacidad resultante
del Proceso
La Capacidad del Proceso de
Software es mejorada
continuamente debido a que la
organización mejora
continuamente la capacidad y
el desempeño del proceso en
los proyectos
La mejora ocurre por la mejora
incremental a los procesos
existentes así como por la
innovación mediante el uso de
nuevas tecnologías y métodos
El modelo CMM – Revisión de niveles
"

Prevención de Administración de
Defectos cambios a
Tecnologías

Administración
de Cambios a
Procesos
Estado actual

Relacionemos las áreas claves de CMM

con nuestra empresa

?
Lo que SI es CMM y lo que
NO es
Jamie Myer – SEI member
 Lo que NO es
NO es una “solución milagrosa” para el desarrollo de software
No podemos culpar a una herramienta de medición de nuestras fallas

NO es obvio su valor para el común de los ingenieros

Es un valor para el negocio, pero es difícil cuantificar en dinero

NO es un proceso predefinido para hacer que un negocio tenga éxito

Lamentablemente vamos a tener que seguir haciendo negocios y preocuparnos por
hacerlos lo mejor posible

NO es una herramienta para incrementar el control y la burocracia

CMM no sugiere agregar procesos donde no exista valor en agregarlos

NO es una justificación para formar grandes grupos de Ingeniería de Procesos o de

Aseguramiento de Calidad
No es diferente de otros proyectos que la organización inicia, con recursos
asignados y posibilidades de desviarse del plan original en función del
cumplimiento de las metas y la colaboración de los equipos
 Lo que NO es
NO es una manera de retener clientes
La relación con el cliente y los procesos de CRM siguen estando activos y deben
trabajar para lograr la satisfacción y buscar nuevos negocios

NO es un reemplazo para la ingeniería de negocios

Podemos seguir creando un producto de alta calidad, pero de ninguna cabida en el
mercado

NO es una forma efectiva de armar un grupo de “iluminados” o “gurúes”

Los procesos son parte del trabajo diario, y como tal deben estar incorporados al
lenguaje natural que facilite el entendimiento de los mismos

NO es un reemplazo para no necesitar equipos motivados respondiendo a metas claras

Coloquen al mejor capitán, en el mejor barco, y con los mejores marineros, en el
medio del océano y no le digan adónde ir. Todo funciona pero no hay camino.

NO es una guía rápida para TODOS los ciclos de vida de TODOS los proyectos de TODAS
las áreas de negocio de cualquier empresa
 Lo que SI es

1. Es una herramienta para medir la capacidad de ingeniería de

software de las empresas
2. Adaptado al entorno de cada organización puede lograr mejoras
impredecibles en la gente, los procesos y la tecnología utilizadas
como base para la construcción de productos competitivos
3. Es una guía que permite elegir el destino tomando diversas
alternativas para llegar a él, incluyendo en esta decisión la cultura
de la organización
4. Es una forma de enfocarnos en lo importante a mejorar en función
de nuestro estado actual, y no atacar áreas o procesos no claves
para la madurez que la empresa posee
 Condiciones para el éxito

1. La Dirección debe dirigir el cambio, la Dirección debe medir el

cambio
2. Tomar conciencia de que es un cambio de cultura de trabajo, darle
esa importancia
3. Mantener las cosas simples
4. Utilizar el sentido común
5. Entrenar a la gente. Ayudarla a ejecutar su trabajo de acuerdo a los
procesos definidos.
6. Promocionar y publicar los beneficios
7. Tomar conciencia del esfuerzo requerido en tiempo y recursos
Esfuerzo necesario
El último Maturity Profile emitido por el SEI nos da
los siguientes datos:
Consultas

Mejora del Proceso de desarrollo de

software

Una visión ejecutiva

 Referencias
• Sanjiv Ahuja, Telcordia Technologies: “Common Sense – Process” Gráfica
• Dave Zubrow: Process Improvement: Just the Facts, not the Hype – SEI, 1997
• Mark C. Paulk: Investing in Software Process Improvement: An Executive Perspective – SEI, 2002
• 2003 Apraissal - Process Maturity Profile.pdf, SEI, 2003
• Kim Caputo: CMM Implementation Guide, 1998 Addison Wesley