Está en la página 1de 29

CENTRO INFORMÁTICO DEL I.N.S.S.

SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Informe Técnico
Mejora del Proceso Software
El modelo CMMISM

SPI-INSS

Versión 01.00

29 de enero de 2004

Servicio de Desarrollo Informático Página 1 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

CONTROL DE VERSIONES

Versión Apartado Descripción del Fecha Elaborado Revisado


Cambio
01.00 Creación del Documento 29/01/2004 Proyectos Especiales

Servicio de Desarrollo Informático Página 2 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

ÍNDICE

1. OBJETIVO DEL DOCUMENTO...................................................................................................................................5

2. MEJORA DEL PROCESO SOFTWARE...................................................................................................................5

3. EL MODELO CMMI...................................................................................................................................................9

3.1. INTRODUCCIÓN.....................................................................................................................................................9

3.2. REPRESENTACIONES...........................................................................................................................................9

3.2.1. CONTINUA...........................................................................................................................................................9

3.2.2. POR ETAPAS (STAGED)...................................................................................................................................10

3.3. NIVELES DE MADUREZ.....................................................................................................................................11

3.3.1. NIVEL 1. INICIAL..............................................................................................................................................11

3.3.2. NIVEL 2. GESTIONADO..................................................................................................................................11

3.3.3. NIVEL 3. DEFINIDO.........................................................................................................................................12

3.3.4. NIVEL 4. GESTIONADO CUANTITATIVAMENTE....................................................................................13

3.3.5. NIVEL 5. OPTIMIZADO...................................................................................................................................13

3.4. ÁREAS DE PROCESO..........................................................................................................................................15

3.4.1. GESTIÓN DEL PROCESO...............................................................................................................................15

3.4.2. GESTIÓN DE PROYECTOS............................................................................................................................16

3.4.3. INGENIERÍA......................................................................................................................................................17

3.4.4. SOPORTE............................................................................................................................................................18

3.5. METAS GENÉRICAS. PRÁCTICAS GENÉRICAS. INSTITUCIONALIZACIÓN.....................................20

3.5.1. COMPROMISO DE REALIZACIÓN.............................................................................................................20

3.5.2. HABILIDAD DE REALIZACIÓN...................................................................................................................21

3.5.3. IMPLEMENTACIÓN DIRIGIDA....................................................................................................................23

3.5.4. Implementación Verificada...................................................................................................................................26

Servicio de Desarrollo Informático Página 3 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

1. OBJETIVO DEL DOCUMENTO


El objetivo de este informe es dar una aproximación a la Mejora del Proceso de Software en una
organización de desarrollo. Se presentarán las motivaciones para iniciar un programa de mejora
y su repercusión en aspectos relacionados con Coste, Rendimiento, Calidad, Satisfacción del
usuario, etc.
Posteriormente se presentará el Modelo Integrado de Madurez de Capacidad (CMMI),
desarrollado por el Software Engeneering Institute de la Carnegie Mellon University. Este
modelo surge como integración de los diferentes modelos de de Madurez existentes
previamente, (CMM-SW, P-CMM, IPD-CMM), enfocando los procesos de negocio de la empresa de
un modo integral. Este modelo pretende aportar una guía unificada para la mejora de las
diferentes disciplinas implicadas en una organización de IT.

2. MEJORA DEL PROCESO SOFTWARE

“La calidad de un producto está determinada en gran medida por la calidad del
proceso usado para desarrollarlo y mantenerlo” -Principios de TQM-

El Proceso Software
Podemos definir un proceso como un método para hacer o producir algo. Si extendemos esta
definición al caso del software, podemos decir que el proceso software es un método para
producir o desarrollar software. Esto parece una obviedad, después de todo el software siempre
ha sido desarrollado usando algún método. Por ejemplo, “Prueba y error” es un proceso
perfectamente válido.
Este tipo de procesos, independientemente de la profesionalidad con que se hayan ejecutado,
dependían fuertemente del desarrollador individual. Esto puede derivar en tres problemas:
Primero, ese software es difícil de mantener. Supongamos que el desarrollador abandona la
empresa por la causa que sea, y alguien tiene que retomar su trabajo inconcluso. Puede ocurrir
que exista una documentación exhaustiva del estado actual del trabajo. Puede que incluso
haya un plan, con las tareas individuales completadas marcadas, o puede que el plan exista
únicamente en la cabeza del desarrollador. En cualquier caso el sustituto probablemente
acabará empezando de nuevo, porque no tiene ninguna pista de por donde empezar. El
proceso puede ser excelente, pero es un proceso ad-hoc, no un proceso definido.
Segundo, es difícil medir con precisión la calidad del producto terminado con una evaluación
independiente. Si tenemos dos desarrolladores, siguiendo cada uno su propio proceso,
definiendo sus propias pruebas sobre la marcha, no tenemos un método objetivo de comparar
el trabajo de uno con el del otro, o con un criterio de calidad del cliente.
Tercero, hay un gran esfuerzo duplicado debido a que cada individuo elabora su propia manera
de hacer las cosas aisladamente. Para evitar esto, debemos encontrar algún modo de aprender
de la experiencia de otros, no volver a inventar la rueda.
Por esto es importante que cada organización defina el proceso para un proyecto. En su forma
más simple, esto significa simplemente ponerlo por escrito. Esto especifica los diversos ítems
que deben ser producidos, y el orden en que deben ser producidos: De los planes a los
requisitos, a la documentación y hasta el código fuente final. Debe decir dónde se deben
almacenar, cómo se deben comprobar, y qué se debe hacer con ellos cuando el proyecto
finalice. Una vez puesto por escrito es un proceso definido.

Servicio de Desarrollo Informático Página 4 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Objetivos del Proceso


¿Qué queremos conseguir con el proceso? Hay diversas características que nos interesan de un
proceso:
- Efectivo. Un proceso efectivo debe ayudarnos a conseguir el producto que quiere el
cliente. El proceso debe ayudarnos a determinar las necesidades del cliente, y a verificar
que lo que hemos producido es lo que el cliente necesita.
- Mantenible. Inevitablemente, el software tiene fallos, o bien los requisitos cambian, o
queremos reutilizar partes del software. Puede que en cualquiera de esos casos el
desarrollador original no esté disponible. Uno de los objetivos de un buen proceso es
exponer los procesos mentales del diseñador y el programador de forma que estén
claras sus intenciones. Entonces podremos encontrar fácilmente los fallos o descubrir
dónde hacer los cambios.
- Predecible. Es necesario planificar el desarrollo de cualquier producto, esto es la base
para asignar recursos, tanto tiempo como personal. Es importante predecir cuánto
tiempo llevará el desarrollo del producto. Esto significa estimar con precisión cuánto
llevará producir cada parte de él –incluido el software-. Un buen proceso puede ayudar a
conseguirlo
- Repetible. Si tenemos un proceso que funciona, puede ser replicado en futuros
proyectos. Los procesos ad-hoc raras veces se pueden repetir a no ser que el equipo del
proyecto sea el mismo. Incluso con el mismo equipo, es difícil mantener las cosas
exactamente iguales. Un tema relacionado es la reutilización de procesos. Es una
sobrecarga para cada proyecto el producir un proceso desde cero. Es mucho más rápido
y fácil adaptar un proceso existente.
- De Calidad. En este caso definimos calidad como el grado en que el producto cumple
con su propósito. Uno de los objetivos de un proceso definido es permitir que los
ingenieros de software aseguren un producto de alta calidad. El proceso debe
proporcionar un enlace claro entre los deseos del cliente y el producto desarrollado.
- Mejorable. Nadie puede pretender que su proceso alcance la perfección y no necesite
mejoras posteriores. Incluso si somos todo lo buenos posible ahora, tanto los entornos
de desarrollo como los productos solicitados cambian tan rápidamente que los procesos
deben siempre cambiar para adecuarse a estos cambios. Un objetivo de nuestro proceso
definido debe ser identificar las posibilidades para mejorar el propio proceso
- Seguimiento. Un proceso definido debe permitir a la dirección, a los desarrolladores y a
los clientes seguir el estatus de un proyecto. El seguimiento es el complemento de la
predictibilidad. Nos permite medir la bondad de nuestras predicciones, y por tanto como
mejorarlas.
Todas estas características serían demasiadas para un único proyecto. Es esencial que la
organización proporcione a los proyectos un conjunto de guías para los proyectos, para
permitirles desarrollar sus procesos fácil y rápidamente con una sobrecarga mínima. Estas
guías, en forma de meta-procesos, consisten en un conjunto de instrucciones detalladas de qué
actividades se deben realizar y qué documentos debe producir cada proyecto. Estas
instrucciones se conocen generalmente como el Sistema de Calidad.

La Mejora del Proceso Software


Como estamos viendo, uno los pilares para obtener productos de alta calidad, en el plazo
establecido y con el presupuesto fijado es el proceso utilizado para el desarrollo del producto.
Todo el mundo es consciente de la importancia de tener personal motivado y cualificado, y de

Servicio de Desarrollo Informático Página 5 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

emplear la mejor tecnología posible, pero incluso las personas más capacitadas no producen lo
mejor sin un proceso de alto nivel. Por esto han surgido iniciativas tendentes a la mejora de la
capacidad de los procesos software.
Los programas exitosos de mejora del proceso software han conseguido:
 Reducir en un 95% el número de defectos entregados.
 Reducir los tiempos de desarrollo de software en 71%.
 Incrementar la productividad (medida en LOC o Puntos Función por día ) en un 222%.
 Se ha obtenido un ROI medio de 5:1.
Un proceso se define como un conjunto de prácticas realizadas para obtener un propósito.
Pueden incluir herramientas, métodos, materiales y/o personas. Mientras que el proceso se
describe como uno de los lados del triángulo proceso-personas-tecnología, se puede considerar
como el “pegamento” que unifica los otros aspectos.
Un Modelo de Proceso es una colección estructurada de elementos que describen
características de procesos efectivos. Proporciona una referencia para fijar objetivos y
prioridades de mejora de procesos, y una guía para asegurar procesos estables, capaces y
maduros.
Hay que distinguir entre Capacidad del Proceso y Rendimiento del Proceso. El primer concepto
apunta al rango de resultados esperados por seguir un proceso, establecido inicialmente al
nivel organizativo. Puede predecir el futuro resultado del proceso. El Rendimiento del proceso
es una medida de los resultados actuales conseguidos por la ejecución de un proceso. Se
refiere a un proyecto particular en la organización.
Un modelo de proceso proporciona:
 Un punto de partida
 El beneficio de experiencias anteriores de la comunidad
 Un lenguaje y una visión común
 Un marco para priorizar acciones.

Servicio de Desarrollo Informático Página 6 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Fig. 1. Los diferentes marcos de calidad y mejora de procesos, y las relaciones entre ellos.
Como vemos en la Fig. 1, existe un número considerable de marcos estándar relacionados con
la calidad y los procesos de software:
 Los modelos de madurez de capacidad de la familia CMM.
 Las series de normas ISO
 Modelos de procesos relacionados con el DOD.
 Etc.

Ciclo de mejora del proceso software


Existen una serie de problemas potenciales que se pueden plantear en una organización de
desarrollo de software. Imaginemos que la dirección hiciera estas preguntas:
- ¿Cómo está evolucionando el tamaño del producto?
- ¿Cómo evoluciona la productividad de los desarrolladores?
- ¿Qué calidad tiene nuestro producto? ¿Aumenta?
- ¿Cuántos proyectos terminan a tiempo y dentro del presupuesto?
La dirección tiene como responsabilidad marcar los objetivos para el programa de mejora. Estos
objetivos, en la medida de lo posible deberían expresarse en términos medibles objetivamente.
Por ejemplo, estos objetivos podrían ser:

Servicio de Desarrollo Informático Página 7 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

- Aumentar la predicibilidad de la planificación, disminuir el sobrepaso del presupuesto.


- Disminuir el tiempo de entrega.
- Aumentar la calidad
- Incrementar la productividad…
Deberian definir también el enfoque del programa, y establecer un ciclo de mejora. Este ciclo
constaría de las siguientes etapas:
Evaluacíón:
- La manera actual de trabajar
- Las fortalezas y debilidades de esta manera de trabajar
- Los riesgos relacionados con esas debilidades
- Las áreas en que el modo actual de trabajo necesita ser mejorado.
Definición del Plan de Mejora
A continuación se desarrollaría un plan de mejora en base a la identificación de las áreas que
necesitan mejorar. Este plan es un plan de gestión de proyectos para el proyecto de la mejora:
- Identificación de los entregables del Plan de Mejora de Procesos
- Actividades para producir esos entregables
- Asignación de recursos y programación de las actividades.
- Acuerdo y compromiso con el plan.
Cuando se finaliza el plan, están claras las repercusiones del proyecto de mejora: Coste,
demanda de recursos (propios o consultores), calendario. Es imperativo que la dirección
apruebe la ejecución del plan, asumiendo las inversiones a corto plazo para lograr
beneficios a largo plazo.
- Ejecución de las actividades planificadas.
Una vez que se ha establecido compromiso con el plan, puede empezar su ejecución.

3. EL MODELO CMMI

3.1. Introducción
El modelo CMMI constituye un marco de referencia de la capacidad de las organizaciones de
software en el desempeño de sus diferentes procesos, proporcionando una base para la
evaluación de la madurez de las mismas y una guía para implementar una estrategia para la
mejora continua de los mismos. Proporciona una vista estructurada de la mejora de procesos en
una organización. Puede ayudar a:
 Fijar metas y prioridades de mejora
 Proporcionar orientación en los procesos de calidad
 Proporcionar criterios para evaluar las prácticas
Servicio de Desarrollo Informático Página 8 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Existen una serie de conceptos que constituyen la estructura del marco de referencia:
 Niveles de madurez.
 Áreas de proceso.
 Metas genéricas.
 Metas específicas.
 Prácticas genéricas.
 Practicas específicas.

3.2. Representaciones
Existen dos representaciones del modelo CMMI atendiendo a las diferentes necesidades de las
organizaciones que quieren realizar la mejora de sus procesos. La representación por etapas
hace especial énfasis en el grado de madurez de los procesos, mientras que la representación
continua hace hincapié en la capacidad de ciertas áreas para realizar adecuadamente sus
actividades.

3.2.1. Continua
En la representación continua los niveles de madurez no existen como tales. En cambio los
niveles de capacidad se designan para cada área de proceso, proporcionando un orden
recomendando para acercarse a la mejora dentro de cada área de proceso. Esta representación
favorece la flexibilidad en el orden en que se introducen las mejoras. Aquellas organizaciones
que escojan la representación continua podrán:
 Seleccionar adecuadamente las mejoras que hay que realizar para conseguir los
objetivos del negocio definidos por la organización.
 Permitir un análisis comparativo dentro de la organización y entre diferentes
organizaciones al tener por punto de referencia las diferentes áreas de proceso.
 Facilita la realización de evaluaciones con el modelo SPICE (ISO/IEC TR 15504), ya que la
organización de sus áreas de proceso es similar.

3.2.2. Por Etapas (Staged)


En la representación por Etapas cada área de proceso se asocia con uno de los 5 niveles de
madurez. Los diferentes niveles de madurez sirven como punto de referencia para conocer el
grado de madurez total que tiene una organización en conjunto. Una organización alcanza un
nivel de madurez determinado cuando ha puesto en práctica todas las áreas de proceso
pertenecientes a ese nivel y todos los inferiores. Así pues, proporciona un camino progresivo
para la mejora de los procesos de la organización a nivel global, pues cada nivel de madurez
establece la base para el siguiente. Esta representación proporciona una secuencia contrastada
de mejoras, que comienza con prácticas básicas de gestión de proyectos e irán progresando
por un camino predefinido y probado de sucesivos niveles de madurez.
Por esto, aunque es posible implementar algunas áreas de proceso pertenecientes a niveles
superiores, no es recomendable pues carecerían del sustrato proporcionado por la
institucionalización de las áreas de proceso de los niveles anteriores.
Cada nivel de madurez enfoca en un aspecto del proceso. Así con el nivel 2 se asegura que
están implantadas las áreas de proceso a nivel de proyecto, en el nivel 3 estas prácticas están

Servicio de Desarrollo Informático Página 9 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

definidas para toda la organización a nivel global, de modo que cada proyecto puede adaptar
sus procesos a partir del proceso definido para la organización. Para esto es conveniente
disponer de una Biblioteca de Activos de Proceso (PAL) donde residan las descripciones de los
procesos, plantillas y otros materiales para su utilización en cada proyecto individual. El nivel 4
enfoca en la gestión cuantitativa de los proyectos con los cual incorpora prácticas para
recopilar datos cuantitativos y métricas para ayudar a una toma de decisiones informada. El
nivel 5 tiene como objetivo la mejora continua estudiando las fortalezas y debilidades de los
procesos y la implementación de innovaciones tecnológicas.

Nivel de Madurez

Area de Proceso Area de Proceso Area de Proceso

Metas Genericas Metas Especificas

Caracteristicas Comunes

Compromiso de Habilidad de Implementacion Verificación de la


realizacion realizacion Dirigida implementación

Prácticas Prácticas
Genericas Especificas

Fig 2. Estructura de CMMI. Representación por etapas (staged).

3.3. Niveles de Madurez


Existen 5 niveles de madurez. Cada uno de ellos representa un escalón bien definido de
evolución en el camino para conseguir una organización madura. Cada nivel es una capa en la
base de la mejora continua de los procesos:

Servicio de Desarrollo Informático Página 10 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Niveles de Madurez
Optimizado
5 Enfoque en la mejora del
proceso

Gestionado
4 El proceso es controlado Cuantitativamente
cuantitativamente

3 Proceso caracterizado Definido


por la organización y
proactivo
Gestionado
2 Proceso caracterizado por
proyectos y
frecuentemente reactivo
Inicial
1 Proceso impredecible,
poco controlado y reactivo

Fig 3. Niveles de Madurez CMMI Op

Defined 3.3.1. Nivel 1. Inicial

En el nivel de madurez 1, los procesos normalmente son ad hoc y caóticos. La organización no


provee un entorno estable. El éxito en tales organizaciones depende de la competencia y
heroicidad de las personas de la organización y no del uso de procesos probados. A pesar de
este entorno ad hoc y caótico, las organizaciones de nivel 1 con frecuencia producen productos
y servicios que funcionan; sin embargo, con frecuencia exceden el presupuesto y la
planificación de sus proyectos.

Las organizaciones de nivel 1 se caracterizan por su tendencia al exceso de compromiso,


abandono de los procesos en tiempos de crisis, y no ser capaces de repetir éxitos anteriores.

3.3.2. Nivel 2. Gestionado


En el nivel 2 de madurez, una organización ha conseguido todas las metas específicas y
genéricas de las áreas de proceso del nivel 2. En otras palabras, los proyectos de la
organización han asegurado que los requisitos se gestionan y que los procesos se planifican,
realizan, miden y controlan.

Servicio de Desarrollo Informático Página 11 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

La disciplina de proceso reflejada por el nivel de madurez 2 ayuda a asegurar que las prácticas
existentes se retienen en tiempos de stress. Cuando esas prácticas están presentes, los
proyectos se realizan y gestionan conforme a sus planes documentados.
En el nivel de madurez 2, los requisitos, procesos, productos y servicios se gestionan. El status
de los productos y la prestación de servicios son visibles para la gestión en puntos definidos
(por ejemplo en hitos mayores y al completar tareas mayores)
Se establecen compromisos entre los participantes relevantes, y se revisan según sea
necesario. Loa productos de trabajo se revisan con los participantes, y se controlan. Los
productos y servicios satisfacen sus propios requisitos, estándares y objetivos.

Las áreas de proceso de nivel 2 de CMMI son:


 Gestión de Requisitos
 Planificación del Proyecto
 Monitorización y Control del Proyecto
 Gestión de Acuerdos con Proveedores
 Medidas y Análisis
 Aseguramiento de Calidad del Proceso y del Producto
 Gestión de Configuración

3.3.3. Nivel 3. Definido


En el nivel de madurez 3, una organización ha alcanzado todos los objetivos específicos y
genéricos de los niveles de madurez 2 y 3. En el nivel 3, los procesos están bien caracterizados
y comprendidos, y están descritos en estándares, procedimientos, herramientas y métodos.
El conjunto organizativo de procesos estándar, que es la base para el nivel 3, se establece y
mejora a lo largo del tiempo. Esos procesos estándar se usan para establecer consistencia en la
organización. Los proyectos establecen sus procesos definidos adaptando el conjunto de
procesos estándar de la organización de acuerdo a las directrices de adaptación.
La Gestión de la organización establece objetivos del proceso en base al conjunto de procesos
estándar y se asegura que los objetivos estén alineados apropiadamente.
Una distinción crítica entre el nivel 2 y el nivel 3 es el ámbito de los estándares, descripciones
de proceso y procedimientos. En el nivel 2, los estándares, descripciones de proceso y
procedimientos pueden ser diferentes en cada instancia específica del proceso (por ejemplo, en
un proyecto particular). En el nivel 3, los estándares, descripciones de proceso, y
procedimientos son adaptados desde el conjunto estándar de la organización para encajar en
un proyecto particular o una unidad organizativa. El conjunto organizativo de procesos estándar
incluye los procesos abordados en el nivel 2 y en el nivel 3. Como resultado, los procesos
realizados por la organización son consistentes, excepto por las diferencias permitidas por las
directrices de adaptación.
Otra distinción crítica es que en el nivel 3, los procesos típicamente se describen en mayor
detalle y más rigurosamente que en el nivel 2. En el nivel 3, los procesos se gestionan más
proactivamente, usando una comprensión de las interrelaciones de las actividades del proceso
y medidas detalladas del proceso, sus productos de trabajo, y sus servicios.
Las áreas de proceso del nivel de madurez 3 son:
 Desarrollo de Requisitos
 Solución Técnica
 Integración de Producto
 Verificación
 Validación

Servicio de Desarrollo Informático Página 12 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

 Enfoque del Proceso Organizativo


 Definición del Proceso Organizativo
 Formación organizativa
 Gestión Integrada de Proyectos
 Gestión de Riesgos
 Análisis y Resolución de Decisiones

3.3.4. Nivel 4. Gestionado Cuantitativamente


En el nivel 4, una organización ha alcanzado los objetivos específicos de las áreas de proceso
asignadas a los niveles de madurez 2,3 y 4 y las metas genéricas de los niveles 2 y 3. Se han
seleccionado subprocesos que contribuyen significativamente al rendimiento global del
proceso. Esos subprocesos seleccionados se controlan usando técnicas estadísticas y otras
técnicas cuantitativas.
Los objetivos cuantitativos para la calidad y el rendimiento del proceso se establecen y se usan
como criterio en la gestión de los procesos. Los objetivos cuantitativos se basan en las
necesidades del cliente, usuarios finales, organización e implementadores del proceso. La
calidad y el rendimiento del proceso se entiende en términos estadísiticos, y se gestiona a lo
largo de la vida de los procesos.
Para esos procesos, las medidas detalladas de rendimiento del proceso se recopilan y analizan
estadísticamente. Se identifican causas especiales de variación, y cuando es apropiado, la
fuente de causas especiales se corrige para prevenir ocurrencias futuras.
Las medidas de calidad y de rendimiento del proceso se incorporan en el repositorio de
medidas de la organización para soporte de futuras decisiones basadas en hechos.
Una distinción crítica entre el nivel 3 y el 4 es la predictibilidadd del rendimiento del proceso.
En el nivel 4, el rendimiento del proceso se controla usando técnicas estadísticas y otras
técnicas cuantitativas, y es predecible cuantitativamente. En el nivel 3, los procesos son
predecibles sólo cualitativamente.

Las áreas de proceso del nivel 4 de CMMI son


 Rendimiento del Proceso Organizativo
 Gestión de Proyectos Cuantitativa

3.3.5. Nivel 5. Optimizado


En el nivel 5, una organización ha alcanzado todos los objetivos específicos de las áreas de
proceso asignadas a los niveles 2,3,4 y 5 y las metas genéricas de los niveles 2 y 3. Los
procesos se mejoran continuamente en base a la comprensión cuantitativa de las causas
comunes de variación inherentes al proceso.
El nivel 5 enfoca en mejorar continuamente el rendimiento del proceso por medio de mejoras
tecnológicas incrementales e innovadoras. Se establecen objetivos cuantitativos de mejora del
proceso para la organización, revisados continuamente para reflejar los cambios en los
objetivos del negocio, y se usan como criterio para gestionar la mejora del proceso. Los efectos
de las mejoras del proceso se miden y evalúan contra los objetivos cuantitativos de mejora del
proceso. Tanto los procesos definidos y el conjunto de procesos estándar de la organización son
metas para actividades de mejora medible.
Las mejoras del proceso para abordar las causas comunes de variaciones de proceso y mejorar
mediblemente los proceses organizativos se identifican, evalúan y despliegan. Las mejoras se

Servicio de Desarrollo Informático Página 13 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

seleccionan en base a una comprensión cuantitativa de su contribución esperada para


conseguir los objetivos de mejora de procesos de la organización contra el coste y el impacto
en la organización. El rendimiento de los procesos se mejora continuamente.
Los procesos optimizados, ágiles e innovadores dependen de la participación de una plantilla
alineada con los valores del negocio y los objetivos de la organización. La habilidad de la
organización para responder rápidamente a cambios y oportunidades mejora encontrando
formas de acelerar y compartir el aprendizaje. La mejora del proceso es una parte inherente del
papel de todos, lo que resulta en un ciclo de mejora continua.
Una distinción crítica entre el nivel 4 y el nivel 5 es el tipo de variación del proceso abordada.
En el nivel 4, los procesos intentan abordar las causas especiales de variación del proceso y
proporcionar predicibilidad estadística de los resultados. Dado que los procesos producen
resultados predecibles, éstos pueden ser insuficientes para conseguir los objetivos
establecidos. En el nivel 5 los procesos tienden a abordar las causas comunes de variación del
proceso y cambiar el proceso (esto es, desplazar el significado de rendimiento del proceso)
para mejorar el rendimiento del proceso (mientras se mantiene la predicibilidad estadística)
para conseguir los objetivos establecidos de mejora del proceso cuantitativa.
Las áreas de proceso del nivel 5 son:
 Innovación y Despliegue Organizativo
 Análisis y Resolución Causal

NIVEL AREAS DE PROCESO


1 Inicial Basado en la competencia y acciones individuales de las personas
2 Gestionado  Gestión de los requisitos del Producto y del proyecto
 Planificación de los proyectos
 Seguimiento y control de los proyectos
 Gestión de Acuerdos con los proveedores
 Selección y supervisión de proveedores
 Medición y Análisis
 Aseguramiento de la Calidad del producto y Proceso
 Gestión de la Configuración
3 Definido  Desarrollo de los requisitos
 Diseño, desarrollo y puesta en práctica de soluciones técnicas
 Asegurar la Integración del Producto
 Verificación
 Validación
 Enfoque de la organización hacia la gestión de los procesos
 Correcta definición de los procesos de la organización
 Educación y Entrenamiento para mejorar la eficacia y la eficiencia
 Gestión integrada de los proyectos (producto+ proceso)
 Gestión de riesgos
 Análisis sistemático y puesta en práctica de las decisiones acordadas
 Entorno organizativo adecuado para desarrollo integrado del producto y el
proceso (IPPD*)
 Formar y mantener un equipo para el desarrollo integrado (IPPD)
 Gestión integrada de proveedores (SS)
4 Gestionado  Evaluación de los procesos de la organización (datos de rendimiento de
cuantitativamente los procesos)
 Gestión cuantitativa de los proyectos
 Gestión cuantitativa de los proveedores
5 Optimizado  Innovación y despliegue a lo argo de toda la organización (mejoras
incrementales y su posterior generalización)
 Gestión de cambios tecnológicos
Servicio de Desarrollo Informático Página 14 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

 Análisis y resolución de las causas que generan los diferentes problemas


y errores
Tabla 1: Áreas de proceso asociadas a cada nivel de madurez.

3.4. Áreas de Proceso


Las áreas de proceso son conjuntos de actividades relacionadas en un área, que cuando se
realizan conjuntamente, satisfacen un conjunto de metas que se consideran importantes para
lograr mejoras significativas en esa área.
Las áreas de proceso se catalogan en cuatro diferentes categorías:
 Gestión del Proceso
 Gestión de Proyectos
 Ingeniería.
 Soporte

3.4.1. Gestión del Proceso


Las áreas de proceso de Gestión del Proceso contienen las actividades de cada proyecto
relativas a definir, planificar, dotar de recursos, desplegar, implementar, monitorizar, controlar,
evaluar, medir y mejorar los procesos.
Las áreas de proceso de Gestión del Proceso de CMMI son las siguientes:
 Enfoque Organizativo en el Proceso
 Definición del Proceso Organizativo
 Formación Organizativa
 Innovación y Despliegue Organizativo
El área de proceso Enfoque Organizativo en el Proceso ayuda a la organización a planear e
implementar la mejora de procesos en base a la comprensión de las fortalezas y debilidades de
los procesos y activos de proceso de la organización. Las mejoras candidatas a los procesos de
la organización se obtienen por varios medios. Estos incluyen propuestas de mejora de
procesos, medición de los procesos, lecciones aprendidas en la implementación de los
procesos, y resultados de la evaluación del proceso y de los productos.
El área de proceso Definición Organizativa del Proceso establece y mantiene el conjunto de
procesos estándar de la organización, y otros activos basados en las necesidades de los
procesos y los objetivos de la organización. Esos otros activos comprenden descripciones de
proceso y elementos de proceso, descripciones de modelos de ciclo de vida, guías de
adaptación de procesos, documentación relacionada con los procesos, y datos. Los proyectos
adaptan los procesos estándar para crear sus propios procesos definidos. Los otros activos
soportan la adaptación tanto como la implementación de los procesos definidos. Experiencias y
productos de trabajo, incluyendo datos de mediciones, descripciones de procesos, artefactos de
procesos, y lecciones aprendidas, se incorporan si es apropiado al conjunto de procesos
estándar de la organización y otros activos.
El área de proceso Formación Organizativa identifica tanto las necesidades de formación de la
organización tanto estratégicas como tácticas comunes entre proyectos y grupos de soporte. En
particular es preciso desarrollar u obtener formación sobre las habilidades necesarias para
realizar el conjunto de procesos estándar de la organización. Los componentes principales de la

Servicio de Desarrollo Informático Página 15 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

formación incluyen un programa gestionado de desarrollo de formativo, planes de


documentación, personal con los conocimientos apropiados, y mecanismos para medir la
efectividad del programa de formación.
El área de proceso Rendimiento del Proceso Organizativo deriva objetivos cuantitativos para la
calidad y rendimiento del proceso a partir de los objetivos de negocio de la organización. La
organización proporciona a los proyectos y grupos de soporte medidas comunes, líneas base de
rendimiento, y modelos de rendimiento del proceso. Esos activos de soporte organizativos
adicionales soportan gestión de proyectos cuantitativa, y gestión estadística de subprocesos
críticos, tanto para los proyectos como para los grupos de soporte. La organización analiza los
datos de rendimiento del proceso recopilados de los procesos definidos para desarrollar una
comprensión cuantitativa de la calidad del producto, la calidad servicio, y el rendimiento del
proceso del conjunto de procesos estándar de la organización.
El área de proceso de Innovación y Despliegue Organizacional selecciona y despliega las
mejoras incrementales e innovadoras propuestas que mejoran la habilidad de la organización
para conseguir sus objetivos de calidad y rendimiento. la identificación de mejoras
incrementales e innovadoras debería implicar la participación de una fuerza de trabajo
autorizada alineada con los valores de negocio y objetivos de la organización. La selección de
las mejoras a desplegar se basa en la comprensión cuantitativa de los beneficios potenciales y
costos para desplegar las mejoras candidatas, y la financiación disponible para tal despliegue.

3.4.2. Gestión de Proyectos


Las áreas de proceso de Gestión de Proyectos cubren las actividades relacionadas con la
planificación, monitorización y control del proyecto.
Las áreas de proceso de Gestión de Proyectos de CMMI son las siguientes:
 Planificación de proyectos
 Monitorización y Control del proyecto
 Gestión de Acuerdos con Proveedores
 Gestión Integrada del Proyecto
 Gestión de Riesgos
 Desarrollo de Equipos
 Gestión cuantitativa del Proyecto

El área de proceso de Planificación de Proyectos incluye el desarrollo del Plan de Proyecto,


implicar a los participantes adecuadamente, obtener compromiso para el plan, y mantener el
plan. Cuando se usa un enfoque IPPD, los participantes representan no solo los expertos
técnicos para el desarrollo del producto y el proceso, sino también las implicaciones del
negocio del desarrollo del producto y el proceso.
La planificación comienza con los requisitos que definen el producto y el proyecto - Qué
construir-. El plan de proyecto cubre varias actividades de gestión de proyecto e ingeniería que
serán realizadas por el proyecto. El proyecto revisará otros planes que afectan al proyecto de
diversos participantes relevantes, y establecerá compromisos con estos para su contribución al
proyecto. Por ejemplo, esos planes cubren valoraciones del proceso, evaluaciones del producto,
gestión de configuración, y medición y análisis.
El área de proceso de Seguimiento y Control de Proyectos incluye actividades de seguimiento y
toma de acciones correctivas. El plan de proyecto especifica el nivel apropiado de seguimiento
del proyecto, la frecuencia de revisiones de progreso, y las medidas usadas para monitorizar el
Servicio de Desarrollo Informático Página 16 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

progreso. El progreso se determina principalmente comparando con el plan. Cuando el estatus


actual se desvía significativamente de los valores esperados, se toman acciones correctivas
según sea apropiado. Esas acciones incluirán re-planificación si fuera necesario.
El área de proceso de Gestión de Acuerdos con Proveedores aborda la necesidad del proyecto
de adquirir efectivamente esas porciones del trabajo producidas por suministradores. Una vez
que un componente del producto esta identificado y que el proveedor esta seleccionado, se
establece y mantiene un acuerdo con el proveedor. Se monitorizara el progreso y rendimiento
del proveedor. Se efectúan revisiones y tests de aceptación para los componentes de producto
producidos por suministradores.

El área de proceso de Gestión Integrada del Proyecto, establece y mantiene el proceso definido
del proyecto, adaptado desde el conjunto de procesos estándar de la organización. El proceso
se gestiona usando el proceso definido del proyecto. El proyecto usa y contribuye a los activos
de proceso de la organización.
El proyecto se asegura que los participantes relevantes asociados con el proyecto coordinan
sus esfuerzos oportunamente. Para esto proporciona para la gestión de la implicación de
participantes; la identificación, negociación y seguimiento de dependencias críticas; y la
resolución de incidencias de coordinación con los participantes.
La Gestión del Riesgo toma una aproximación más continua y por anticipado para gestionar
riesgos con actividades que incluyen identificación de los parámetros del riesgo, evaluaciones
de riesgos y manejo de riesgos.
La Gestión Cuantitativa de Proyectos aplica técnicas cuantitativas y estadísticas para gestionar
el rendimiento del proceso y la calidad del producto. Los objetivos de calidad y de rendimiento
del proceso para el proyecto se basan en los establecidos para la organización. El proceso
definido del proyecto comprende, en parte, elementos de proceso y subprocesos cuyo
rendimiento se puede predecir. Como mínimo, se comprende la variación de proceso
experimentada por los subprocesos crítica para alcanzar los objetivos de calidad y rendimiento.
Se toman acciones correctivas cuando se detectan causas especiales de variación.

3.4.3. Ingeniería

Las áreas de proceso de ingeniería cubren las actividades de desarrollo y mantenimiento


compartidas entre las disciplinas de ingeniería. Las seis áreas de proceso en esta categoría
tienen interrelaciones inherentes. Estas interrelaciones son consecuencia de un proceso de
desarrollo de producto más que de procesos específicos de la disciplina como ingeniería de
software o ingeniería de sistemas.

Las áreas de proceso de Ingeniería de CMMI son las siguientes:


 Desarrollo de Requisitos
 Gestión de Requisitos
 Solución técnica
 Integración del Producto
 Verificación
 Validación

El área de proceso Desarrollo de Requisitos identifica las necesidades del cliente y las traduce
en requisitos del producto. El conjunto de requisitos del producto se analiza para producir una

Servicio de Desarrollo Informático Página 17 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

solución conceptual de alto nivel. Este conjunto de requisitos se asigna a un conjunto de


requisitos de los componentes del producto. Otros requisitos que ayudan a definir el producto
se derivan y asignan a componentes del producto. Este conjunto de requisitos del producto y
de los componentes describe con claridad el rendimiento del producto, las características del
diseño, los requisitos de verificación, etc. en los términos que el desarrollador comprende y usa.
Este área de proceso proporciona requisitos al área de proceso Solución Técnica, donde los
requisitos se convierten en la arquitectura, diseño de componentes del producto, y el
componente del producto en si mismo (- codificación, fabricación) Los requisitos también se
proporcionan al área de proceso de integración del Producto, donde los componentes del
producto se combinan y los interfaces entre ellos cubren los requisitos de interfaz descritos en
el Desarrollo de Requisitos.

El área de proceso de Gestión de Requisitos mantiene los requisitos. describe actividades para
obtener y controlar los cambios de requisitos, y asegurar que otros planes relevantes y datos se
mantienen actualizados. Esto proporciona trazabilidad de los requisitos del cliente al producto,
y a los componentes del producto.
La Gestión de Requisitos asegura que los cambios de requisitos se reflejan en los planes de
proyecto, actividades y productos de trabajo. El ciclo de cambios puede impactar en otras áreas
de proceso de ingeniería; por tanto, la gestión de requisitos es una secuencia de eventos
dinámica y con frecuencia recursiva. El establecimiento y mantenimiento de la Gestión de
Requisitos es fundamental para un proceso de diseño de ingeniería controlado y disciplinado.

El área de proceso Solución Técnica desarrolla paquetes de trabajo técnico para los
componentes del producto que serán usados por el área de proceso Integración de Producto. Se
espera el examen de soluciones alternativas, con el intento de seleccionar el diseño óptimo en
base a criterios establecidos. Esos criterios pueden ser diferentes entre productos, dependiendo
del tipo de producto, entorno operativo, requisitos de rendimiento, y coste y planificación de
entregas. la tarea de seleccionar la solución final hace uso de prácticas específicas del área de
proceso Análisis y Resolución de decisiones.
La Solución Técnica recae en prácticas específicas en el Área de proceso Verificación para
realizar verificaciones del diseño y revisiones entre iguales durante el diseño y antes de la
construcción final.

El área de proceso Integración del Producto establece las prácticas específicas asociadas con la
generación de la mejor secuencia de integración posible, integrando los componentes del
producto y entregando el producto al cliente.

Integración del Producto usa prácticas específicas de Verificación y de Validación para


implementar el proceso de integración del producto. Verificación verifica los interfaces y los
requisitos de interfaz entre los componentes del producto antes de la integración del producto.
Es un evento esencial del proceso de integración. Durante la integración del producto en el
entorno operativo, se usan las prácticas específicas del área de proceso Validación.

El área de proceso Verificación asegura que los productos de trabajo seleccionado cubren los
requisitos especificados. El área proceso Verificación selecciona productos de trabajo y métodos
de verificación que serán usados para verificar los productos de trabajo contra los requisitos
especificados. Verificación es generalmente un proceso incremental, comenzando con la
verificación de componentes de producto y normalmente concluye con la verificación de
productos completamente ensamblados.

Servicio de Desarrollo Informático Página 18 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Verificación también aborda revisiones entre iguales. Las revisiones entre iguales son un
método probado para eliminación temprana de defectos y proporciona una valiosa perspectiva
de los productos de trabajo y componentes que se están desarrollando y manteniendo.
El área de proceso Validación valida incrementalmente los productos contra las necesidades del
cliente. La validación se puede realizar en el entorno operativo o en un entorno operativo
simulado. La coordinación con el cliente en los requisitos de validación es uno de los elementos
más esenciales en este área de proceso.

3.4.4. Soporte

Las áreas de proceso de soporte cubren las actividades que soportan el desarrollo y
mantenimiento del producto. . Las áreas de proceso de Soporte comprenden procesos usados
en el contexto de realización de otros procesos. En general abordan procesos que siguen el
curso a lo largo del proyecto, y pueden abordar procesos que aplican más generalmente a la
organización. Por ejemplo, el Aseguramiento de calidad del Producto y el Proceso se puede usar
en todas las áreas de proceso para proporcionar una evaluación objetiva de los procesos y
productos de trabajo descritos en todas las áreas de proceso.

Las áreas de proceso de soporte son las siguientes:


 Gestión de Configuración
 Aseguramiento de Calidad del Proceso y el Producto
 Medición y Análisis
 Entorno Organizativo Para la Integración
 Análisis y Resolución de Decisiones
 Análisis y Resolución de Causas

El área de proceso Gestión de la Configuración da soporte a todas las áreas de proceso


estableciendo y manteniendo la integridad de los productos de trabajo usando identificación de
la configuración, control de configuración, contabilidad del estado de la configuración, y
auditorias de configuración. Los productos de trabajo situados bajo gestión de configuración
incluyen los productos entregados al cliente, productos de trabajo internos designados,
productos adquiridos, herramientas y otros items usados para crear y describir esos productos.
Como ejemplos de productos de trabajo que se pueden poner bajo gestión de configuración
podemos incluir planes, descripciones de proceso, requisitos, diseños de datos, diagramas,
especificaciones de producto, código, compiladores, ficheros de datos de producto, y
publicaciones técnicas de producto.

El área de proceso Aseguramiento de Calidad del Producto y el Proceso da soporte a todas las
áreas de proceso proporcionando prácticas específicas para evaluar objetivamente los procesos
realizados, los productos de trabajo, y los servicios contra las descripciones de proceso
aplicables, estándares, y procedimientos, y asegura que se abordará cualquier incidencia
detectada en esas revisiones. El Aseguramiento de Calidad del Producto y el Proceso da soporte
a la entrega de productos y servicios de alta calidad proporcionando al personal del proyecto y
todos los niveles de dirección la visibilidad y el feedback apropiados, en los procesos y los
productos de trabajo asociados a lo largo de la vida del proyecto.

El área de proceso Medición y Análisis da soporte a todas las áreas de proceso proporcionando
prácticas específicas que guían a los proyectos y organizaciones para alinear las necesidades y
objetivos de medición con un enfoque de medición que proveerá resultados objetivos. Esos

Servicio de Desarrollo Informático Página 19 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

resultados pueden usarse para tomar decisiones informadas y aplicar las acciones correctivas
apropiadas.

El área de proceso Análisis y Resolución de Decisiones da soporte a todas las áreas de proceso
proporcionando un proceso formal de evaluación que asegura que las alternativas se
comparan y que se elige la mejor para cumplir con las metas del área de proceso.

El área de proceso Análisis y Resolución Causal, hace que el proyecto que la usa comprenda las
causas comunes de variación inherentes en los procesos y las elimina de los procesos del
proyecto, así como usar este conocimiento para mejorar continuamente los procesos de la
organización. Tanto los procesos definidos como el conjunto de procesos estándar de la
organización son los objetivos de esas actividades de mejora.

Servicio de Desarrollo Informático Página 20 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

3.5. Metas Genéricas. Prácticas Genéricas. Institucionalización


Las metas genéricas y prácticas genéricas permiten que la organización institucionalice las
mejores prácticas. La organización irá alcanzando mejoras progresivas primero a nivel de
proyecto, y posteriormente continuará a un nivel más avanzado, obteniendo mejoras de
proceso de nivel organizativo usando datos cuantitativos y cualitativos para tomar decisiones.
Las Prácticas Genéricas proporcionan institucionalización para asegurar que los procesos
asociados con cada área de proceso serán efectivos, repetibles y duraderos. Las prácticas
genéricas están categorizadas por las metas genéricas y las características comunes.
Cada área de proceso de nivel 2 contiene la siguiente meta genérica:

GG2
Institucionalizar un proceso Gestionado

El proceso se institucionaliza como un proceso gestionado

Cada área de proceso en el nivel 3 o superior contiene la siguiente meta genérica:

GG3
Institucionalizar un proceso Definido

El proceso se institucionaliza como un proceso definido

Las características comunes son un modo de organizar las prácticas genéricas de cada área de
proceso. En la representación por etapas, existen 4 características comunes:
 Compromiso para la Realización (CO)
 Habilidad para la Realización (AB)
 Implementación Dirigida (DI)
 Implementación Verificada (VE)

3.5.1. Compromiso de realización


Compromiso de Realización agrupa las prácticas genéricas relacionadas con la creación de
políticas y asegurar esponsorización.
GP 2.1 Establecer una Política Organizativa

Establecer y mantener una política organizativa para planificar y realizar


el proceso
El propósito de esta práctica genérica es definir las expectativas organizativas
del proceso y hacer que estas expectativas sean visibles para todos los afectados

Servicio de Desarrollo Informático Página 21 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

en la organización. En general, la alta dirección es responsable de establecer y


comunicar los principios guía, dirección y expectativas para la organización.
No toda la dirección de la alta dirección lleva la etiqueta de política. la existencia
de la apropiada dirección organizativa es la expectativa de esta práctica
genérica, sin tener en cuenta como se denomina o cómo se imparte.

3.5.2. Habilidad de realización


Habilidad de realización agrupa las prácticas genéricas relacionadas con asegurar que el
proyecto o la organización tienen los recursos que necesitan
GP 2.2 Planificar el Proceso

Establecer y mantener el plan para realizar el proceso.


El propósito se esta práctica genérica es determinar qué se necesita para realizar
el proceso, y conseguir los objetivos establecidos, para preparar un plan para
realizar el proceso, preparar una descripción del proceso, y conseguir el acuerdo
para el plan de los participantes relevantes.
Los requisitos para los productos de trabajo específicos del proceso, y para
realizar el trabajo, puede derivar de otros requisitos. En el caso de los procesos
de un proyecto, pueden venir del proceso de gestión de requisitos del proyecto;
en el caso de un proceso organizativo, pueden venir de fuentes organizativas.
Los objetivos para el proceso pueden derivar de otros planes (p.e. los planes del
proyecto). Se incluyen objetivos para la situación específica, incluyendo objetivos
de calidad, coste y planificación. Por ejemplo, un objetivo podría ser reducir el
coste de realizar un proceso para esta implementación sobre la implementación
previa.
Aunque una práctica genérica, por definición, aplica a todas las áreas de proceso,
las implicaciones prácticas de aplicar una práctica genérica varían para cada
área de proceso. Consideremos dos ejemplos que ilustran las diferencias en lo
que se refiere a planificar el proceso. Primero, la planificación descrita por esta
práctica genérica según se aplica al área de proceso de Monitorización y Control
de Proyectos puede ser llevada a cabo completamente por los procesos
asociados con el área de proceso de Planificación de Proyectos. En tal situación,
la práctica genérica no impone expectativas adicionales para la Planificación.
Segundo, la planificación descrita por esta práctica genérica aplicada al área de
proceso de Planificación de Proyectos no debería ser abordada por los procesos
asociados con otras áreas de proceso del modelo. Por tanto, la práctica genérica
fija una expectativa para que el proceso de planificación de proyectos sea
planificado. Es importante tener en cuenta la extensión en que esta práctica
genérica puede reforzar expectativas fijadas en algún otro lugar del modelo, o
fijar nuevas expectativas abordar.
El establecimiento de un plan incluye documentar el mismo y proporcionar una
descripción del proceso. Mantener el plan incluye cambiarlo cuando sea
necesario, en respuesta a acciones correctivas o a cambios en los requisitos y
objetivos del proceso.
El plan para realizar el proceso típicamente incluye lo siguiente:
 Descripción del proceso
Servicio de Desarrollo Informático Página 22 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

 Estándares para los productos o servicios del proceso


 Requisitos para los productos o servicios del proceso
 Objetivos específicos de rendimiento del proceso (e.g. calidad, escala
de tiempo, tiempo de ciclo y uso de recursos)
 Dependencias entre actividades, productos y servicios del proceso
 Recursos (intuido fondos, personal y herramientas) necesarias para
realizar el proceso
 Asignación de responsabilidad y autoridad
 Formación necesaria para realizar y soportar el proceso
 Productos de trabajo a ser situados bajo gestión de la configuración y
nivel de gestión de configuración para cada ítem
 Requisitos de medición para visualizar el rendimiento del proceso, los
productos o el servicio
 Participantes involucrados o identificados
 Actividades para monitorizar y controlar el proceso
 Actividades de revisión por la dirección para el proceso y los productos
Subprácticas
Obtener esponsorización de la dirección para realizar el proceso
Definir y documentar la descripción del proceso
Definir y documentar el plan para realizar el proceso
Revisar el plan con los participantes relevantes y obtener su acuerdo
Revisar el plan según sea necesario.
GP 2.3 Proveer Recursos
Proporcionar recursos adecuados para realizar el proceso, desarrollar
los productos de trabajo, y proporcionar los servicios del proceso
El propósito de esta práctica genérica es asegurar se de que los recursos
necesarios para realizar el proceso según están definidos en el plan están
disponibles cuando sea necesario.
La interpretación del término "adecuado" depende de muchos factores y puede
variar a lo largo del tiempo. Recursos inadecuados se pueden abordar
aumentando recursos o eliminando requisitos, restricciones y compromisos.
GP 2.4. Asignar Responsabilidad

Asignar responsabilidad y autoridad para realizar el proceso, desarrollar


los productos de trabajo, y proveer los servicios del proceso
El propósito de esta práctica genérica es asegurar que hay una contabilidad a lo
largo de la vida del proceso para realizar el proceso y obtener los resultados
especificados. El personal asignado debe tener la autoridad apropiada para
realizar las responsabilidades asignadas.
La responsabilidad se puede asignar usando descripciones detalladas del trabajo
o en documentos vivos, como el plan para realizar el proceso. La asignación
Servicio de Desarrollo Informático Página 23 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

dinámica de la responsabilidad es otra forma legítima de realizar esta práctica


genérica, tanto como la asignación y aceptación de la responsabilidad está
asegurada a través de la vida del proyecto.
Subprácticas
 Asignar responsabilidad en conjunto y responsabilidad para realizar el
proceso
 Asignar responsabilidad para realizar las tareas específicas del proceso
 Confirmar que el personal asignado a las responsabilidades y
autoridades las comprende y acepta
GP 2.5. Formar al Personal

Formar al personal que realiza o da soporte al proceso


El propósito de esta práctica genérica es asegurar que el personal tiene las
habilidades y experiencia necesaria para realizar o dar soporte al proceso.
Se proveerá formación apropiada al personal que realizará el proceso. Se dará
formación introductoria para orientar al personal que interactúa con los que
realizan el trabajo.
Ejemplos de métodos para impartir formación incluyen: auto-estudio, auto-
formación guiada; instrucción programada auto-impartida; formación formal en el
trabajo; mentoring; y formación formal en aula.
La formación soporta el rendimiento exitoso del proceso proveyendo un
entendimiento común del proceso e impartiendo los conocimientos y habilidades
necesarios para realizar el proceso.
GP 3.1 Establecer un Proceso Definido
Establecer y mantener la descripción de un proceso definido
El propósito de esta práctica genérica es establecer y mantener una descripción
del proceso adaptada del conjunto organizativo de procesos estándar para
resolver las necesidades de una instancia específica. La organización debería
tener procesos estándar que cubran el área de proceso, así como directrices para
la adaptación esos procesos estándar para cubrir las necesidades de un proyecto
u función organizativa. Con un proceso definido, la variabilidad en cómo se
realizan los procesos en la organización se reduce, y los activos de proceso, datos
y aprendizaje pueden ser compartidos efectivamente.
Consulte el área de proceso de Definición Organizativa del proceso para más
información acerca del conjunto organizativo de procesos estándar y directrices
de adaptación.
Las descripciones de los procesos definidos proporcionan las bases para
planificar, realizar, y gestionar las actividades, productos de trabajo, y servicios
asociados con el proceso.
Subprácticas
 Seleccionar del conjunto organizativo de procesos estándar los
procesos que cubren el área de proceso y cubren mejor las
necesidades del proyecto o función organizativa.
 Establecer el proceso definido adaptando los procesos seleccionados
de acuerdo a las directrices de adaptación de la organización.
Servicio de Desarrollo Informático Página 24 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

 Asegurar que los objetivos del proceso organizativo están cubiertos


convenientemente por el proceso definido.
 Documentar el proceso definido y los registros de la adaptación.
 Revisar la descripción del proceso definido si es necesario.

3.5.3. Implementación Dirigida


Implementación dirigida agrupa las prácticas genéricas relacionadas con gestionar el
rendimiento del proceso, la integridad de los productos de trabajo, e implicar a los participantes
relevantes
GP 2.6. Gestionar la Configuración
Situar los productos de trabajo del proceso bajo los niveles apropiados
de gestión de la configuración.
El propósito de esta práctica genérica es establecer y mantener la integridad de
los productos de trabajo designados del proceso (o sus descripciones) a lo largo
de su vida útil.
Consulte el área de proceso de Gestión de la Configuración para más información
acerca de situar los productos de trabajo bajo Gestión de la configuración.
Los productos de trabajo designados están identificados específicamente en el
plan de realización del proceso, conjuntamente con una especificación del nivel
de gestión de la configuración.
Los diferentes niveles de gestión de la configuración son apropiados para
diferentes productos y para diferentes puntos del tiempo. Para algunos productos
puede ser suficiente mantener control de versiones (i.e. la versión del producto
en uso en un momento dado, pasado o presente es conocida, y los cambios se
incorporan de manera controlada). El Control de Versiones es normalmente bajo
el control único del dueño del producto (que puede ser una persona, grupo o
equipo).
A veces, puede ser crítico que algunos productos se fijen bajo gestión de
configuración formal o "línea base". Este tipo de gestión de configuración incluye
definir y establecer líneas base en puntos predeterminados. Estas líneas base
están revisadas formalmente y acordadas, y sirven como base para el desarrollo
posterior de determinados productos.
Son posibles niveles adicionales d gestión de configuración entre control de
versiones y gestión de configuración formal. Un producto de trabajo identificado
puede estar bajo diferentes niveles de gestión de configuración en diferentes
momentos del tiempo.
GP 2.7. Identificar e Implicar a los Participantes Relevantes

Identificar e implicar a los participantes relevantes según lo planificado.


El propósito de esta práctica genérica es establecer y mantener la implicación
esperada de los participantes durante la ejecución del proceso.
Implicar a los participantes relevantes como se describe en un plan apropiado de
implicación de participantes. Implicarlos adecuadamente en actividades como las
siguientes:
Servicio de Desarrollo Informático Página 25 de 29
CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

 Planificación
 Toma de decisiones
 Comunicaciones
 Coordinación
 Revisiones
 Evaluaciones
 Definición de requisitos
 Resolución de problemas/incidencias
Consultar el Área de Proceso Planificación de Proyectos para información en la
planificación de proyectos para implicación de los participantes.
El objetivo de planificar la implicación de los participantes es asegurar que se
consigan las interacciones necesarias, mientras que no se permite que un
excesivo número de grupos e individuos afectados impidan la ejecución del
proceso.
Subprácticas
 Identificar participantes relevantes para el proceso y decidir que tipo de
implicación se debería practicar.
 Compartir dichas identificaciones con planificadores de proyectos u otros
planificadores según sea apropiado.
 Implicar a los participantes relevantes según lo planeado.
GP 2.8. Monitorizar y Controlar el Proceso

Monitorizar y controlar el proceso contra el plan para realizar el proceso


y tomar acciones correctivas apropiadas.
El propósito de esta práctica genérica es realizar la monitorización y control diario
del proceso. La visibilidad apropiada del proceso se mantiene, de modo que se
pueda tomar las acciones correctivas oportunas cuando sea necesario. La
monitorización y el control del proceso implican medir los atributos apropiados
del proceso o de los productos de trabajo del proceso.
Consulte el área de proceso de Monitorización y Control del Proyecto para más
información acerca de la Monitorización y Control del proyecto y la toma de
acciones correctivas.
Consulte el área de proceso de Medición y Análisis para más información sobre
medición.
Subprácticas
 Comparar el rendimiento actual con el planificado para realizar el
proceso
 Revisar realizaciones y resultados del proceso contra el plan de
ejecución del proceso.
 Revisar actividades, estatus, y resultados del proceso con el nivel
inmediato de gestión responsable del proceso e identificar
incidencias. Las revisiones se entienden para proporcionar al nivel

Servicio de Desarrollo Informático Página 26 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

inmediato de gestión con visibilidad apropiada en el proceso. las


revisiones pueden ser periódicas o eventuales.
 Identificar y evaluar los efectos de desviaciones significativas del plan.
 Identificar problemas en el plan y en la ejecución del proceso.
 Tomar acciones correctivas cuando no se satisfagan los requisitos y
objetivos, cuando se detecten incidencias, o cuando el progreso difiera
significativamente de lo planificado.
 Seguir la acción correctiva hasta su cierre.
GP 3.2. Recopilar Información de Mejora

Recopilar productos de trabajo, mediciones, resultados de mediciones, e


información de mejora derivada de la planificación y realización del
proceso para soportar el uso y mejora futuro de los procesos
organizativos y los activos de proceso.
El propósito de esta práctica genérica es recopilar información y artefactos
derivados de planificar y realizar el proceso. Esta práctica genérica se realiza
para que la información y los artefactos se puedan incluir en los activos de
proceso de la organización y estén disponibles para todos los que estén (o vayan
a estar) planificando y realizando el mismo o similar proceso. La información y
artefactos se almacenarán en el repositorio de medidas de la organización y la
biblioteca de activos de proceso de la organización.
Ejemplos de información relevante incluyen el esfuerzo invertido en las diferentes actividades, los
defectos incluídos o eliminados en una actividad particular, y lecciones aprendidas.

Subprácticas
 Almacenar medidas del proceso y de producto en el repositorio de la
organización.
 Submitir información para incluir en la biblioteca de activos de proceso.
 Documentar las lecciones aprendidas
 Proponer mejoras a los activos de proceso de la organización.

3.5.4. Implementación Verificada


Implementación verificada agrupa las prácticas genéricas relacionadas con revisiones por la
dirección y evaluación objetiva de la conformidad con las descripciones de proceso,
procedimientos y estándares.

GP 2.9. Evaluar la Adherencia objetivamente

Evaluar objetivamente la adherencia del proceso contra la descripción


del proceso, los estándares, procedimientos e identificar no
conformidades.
El propósito de esta práctica genérica es proporcionar aseguramiento creíble de
que el proceso se ha implementado de acuerdo a lo planificado y se adhiere a la
descripción, estándares y procedimientos.

Servicio de Desarrollo Informático Página 27 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Típicamente, la adherencia es evaluada por personal que no es responsable


directo de gestionar o realizar las actividades del proceso. En muchos casos, la
adherencia es evaluada por personal interno de la organización, pero externo al
proceso o proyecto, o por personal externo a la organización. Como resultado, se
puede proporcionar aseguramiento creíble de que la adherencia incluso cuando
el proceso está sometido a estrés (e.g. el esfuerzo está por encima de lo
planificado o sobre el prosupuesto).
GP 2.10. Revisar Status con los Gestores de Alto Nivel

Revisar las actividades, estatus y resultados del proceso con la gestión


de alto nivel y resolver incidencias.
El propósito de esta práctica genérica es proporcionar a la gestión de alto nivel
visibilidad apropiada del proceso.
La gestión de alto nivel incluye aquellos niveles de gestión en la organización por
encima del nivel inmediato de gestión responsable del proceso. En particular,
incluye gestión senior. Esas revisiones son para gestores que proporcionan la
política y guía general del proceso, no los que realizan la monitorización y control
diario del proceso.
Diferentes gestores tienen diferentes necesidades de información acerca del
proceso. Esas revisiones ayudan a que puedan tomarse decisiones informadas
sobre la planificación y realización del proceso. Estas revisiones, por tanto,
pueden ser periódicas o eventuales.

Servicio de Desarrollo Informático Página 28 de 29


CENTRO INFORMÁTICO DEL I.N.S.S. SPIINSS
Referencia:
01.00 29/01/2004 Proyectos Especiales
PEIT-SPICMMI_01.00.doc
Documento: Informe Técnico. Mejora de Proceso Software. El modelo CMMISM

Servicio de Desarrollo Informático Página 29 de 29

También podría gustarte