Cmmi

Proyecto #2
Docente
Juan Villegas
Área
Gestión y Calidad de Software
Alumno
Diego Alejandro Echeverri Jaramillo
Politécnico Colombiano Jaime Isaza Cadavid
Medellin
2015

Contenido
1. Introducción.............................................................................................................................3
2. Objetivos.................................................................................................................................4
2.1. General............................................................................................................................4
2.2. Específicos.......................................................................................................................4
3. Estructura de un área de proceso según CMMI.......................................................................5
3.1 Área de proceso................................................................................................................5
3.2. Componentes requeridos.................................................................................................6
3.3. Componentes esperados.................................................................................................6
3.4. Componentes informativos..............................................................................................6
3.5. Declaración del propósito................................................................................................6
3.6. Notas introductorias........................................................................................................6
3.7. Áreas de proceso relacionadas.........................................................................................7
3.8. Metas específicas.............................................................................................................7
3.9. Metas genéricas...............................................................................................................7
3.10. Resúmenes de metas y prácticas específicas.................................................................7
3.11. Prácticas específicas.......................................................................................................7
3.12. Ejemplo de productos de trabajo...................................................................................7
3.13. Sub prácticas.................................................................................................................8
3.14. Prácticas genéricas........................................................................................................8
3.15. Elaboraciones de la práctica genérica............................................................................8
4. Áreas de proceso que se involucran en el nivel 2 de CMMI....................................................9
4.1. Gestión de configuración (CM)........................................................................................9
4.2. Medición y análisis (MA)..................................................................................................9
4.3. Monitorización y control del proyecto (PCM)................................................................10
4.4. Planificación del proyecto (PP)......................................................................................10
4.5. Aseguramiento de la calidad del proceso y del producto (PPQA).................................10
4.6. Gestión de requisitos (REQM).......................................................................................11
4.7. Gestión de acuerdos con proveedores (SAM)................................................................11
5. Cuadro PIIDB (Practice Implementation Indicators DataBase)..............................................12
5.1. Institucionalizar un proceso gestionado.........................................................................12
5.2. Gestión de configuración (CM)......................................................................................14
5.3. Medición y análisis (MA)................................................................................................16
5.4. Monitorización y control del proyecto (PMC)................................................................18
5.5. Planificación del proyecto (PP)......................................................................................20
5.6. Aseguramiento de la calidad del proceso y del producto (PPQA).................................23
5.7. Gestión de requisitos (REQM).......................................................................................24
5.8 Gestión de acuerdos con proveedores (SAM)................................................................25
6. Propuesta para calificar las áreas de proceso.......................................................................27
7. Bibliografía............................................................................................................................29

1. Introducción
El Capability Maturity Model Integration es un marco de referencia que las organizaciones
pueden emplear para mejorar sus procesos de desarrollo, adquisición, y mantenimiento de
productos y servicios. Nacido en el Software Engineering Institute perteneciente a la Carnegie
Mellon University, CMMI es la nueva generación de una línea de modelos de madurez que se
inició a principios de los noventa con el famoso CMM-SW (Capability Maturity Model for
Software Engineering).
Basados en los principios de la calidad total (TQM) popularizados por autores como Crosby,
Deming y Juran, estos modelos proponen un conjunto de prácticas que las organizaciones
pueden adoptar para implantar procesos productivos más efectivos. Son llamados modelos de
madurez porque proponen adoptar dichas prácticas en forma gradual: primero deben ponerse
en práctica áreas de proceso pertenecientes a un nivel determinado, para luego, sobre esta
base, introducir las correspondientes al nivel siguiente.

2. Objetivos
2.1. General
Construir una guía para llevar a cabo la correcta evaluación según el modelo CMMI-DEV V1.3,
a una compañía de desarrollo de software, específicamente para el nivel de madurez 2
(MANAGED).
2.2. Específicos
● Conocer la estructura de un área de proceso en CMMI.
● Entender y usar el modelo CMMI.
● Elaborar una guía de evaluación para garantizar que los procesos de una organización
cumplan con los estamentos establecidos en el nivel 2 de CMMI.

3. Estructura de un área de proceso según CMMI
3.1 Área de proceso
Área de Proceso
Practicas Especificas “SP”
Metas Especificas “SG” Metas Genericas “GG”
Practicas Genericas “SG”
Ejemplos de Productos
De Trabajo
Elaboracion de Practicas
Genericas

3.2. Componentes requeridos
Los componentes requeridos son componentes CMMI que son esenciales para lograr la mejora
de procesos en un área de proceso dada. Este logro se debe implementar visiblemente en los
procesos de la organización. Los componentes requeridos en CMMI son las metas específicas
y genéricas. La satisfacción de las metas se utiliza en las evaluaciones como base para
determinar si un área de proceso ha sido satisfecha.
3.3. Componentes esperados
Los componentes esperados son componentes CMMI que describen las actividades que son
importantes para lograr un componente CMMI requerido. Los componentes esperados
orientan a quienes implementan mejoras o realizan evaluaciones. Los componentes esperados
en CMMI son las prácticas específicas y genéricas. Antes de que las metas puedan
considerarse satisfechas, sus prácticas tal y como se describen, o prácticas alternativas
aceptables, deben estar presentes en los procesos planificados e implementados de la
organización.
3.4. Componentes informativos
Los componentes informativos son componentes CMMI que ayudan a los usuarios del modelo
a comprender los componentes CMMI requeridos y esperados. Estos componentes pueden ser
ejemplos en un recuadro, explicaciones detalladas u otras informaciones útiles. Las sub
prácticas, las notas, las referencias, los títulos de metas, los títulos de prácticas, las fuentes,
los ejemplos de productos de trabajo y las elaboraciones de prácticas genéricas son
componentes informativos del modelo.
3.5. Declaración del propósito
Una declaración del propósito describe la finalidad del área de proceso y es un componente
informativo.
3.6. Notas introductorias
Describe los conceptos principales cubiertos por el área de proceso y es un componente
informativo.

3.7. Áreas de proceso relacionadas
La sección de áreas de proceso relacionadas enumera las referencias a áreas de proceso
relacionadas y refleja las relaciones de alto nivel entre las áreas de proceso. La sección de
áreas de proceso relacionadas es un componente informativo.
3.8. Metas específicas
Una meta específica describe las características únicas que deben estar presentes para
satisfacer el área de proceso. Una meta específica es un componente requerido del modelo y
se utiliza en las evaluaciones para ayudar a determinar si se satisface un área de proceso.
3.9. Metas genéricas
Las metas genéricas se denominan “genéricas” porque la misma declaración de la meta se
aplica a múltiples áreas de proceso. Una meta genérica describe las características que deben
estar presentes para institucionalizar los procesos que implementan un área de proceso. Una
meta genérica es un componente requerido del modelo y se utiliza en las evaluaciones para
determinar si se satisface un área de proceso.
3.10. Resúmenes de metas y prácticas específicas
El resumen de metas y prácticas específicas proporciona un resumen de alto nivel de las metas
específicas y de las prácticas específicas. El resumen de las metas y prácticas específicas es un
componente informativo.
3.11. Prácticas específicas
Una práctica específica es la descripción de una actividad que se considera importante para
lograr la meta específica asociada. Las prácticas específicas describen las actividades que se
espera que produzcan el logro de las metas específicas de un área de proceso. Una práctica
específica es un componente esperado del modelo.
3.12. Ejemplo de productos de trabajo
La sección de ejemplo de productos de trabajo enumera resultados de muestra de una práctica

específica. Un ejemplo de producto de trabajo es un componente informativo del modelo.
3.13. Sub prácticas
Una sub práctica es una descripción detallada que proporciona orientación para interpretar e
implementar una práctica específica o genérica. Las sub prácticas pueden estar redactadas
como si fueran preceptivas, pero realmente son un componente informativo indicado sólo para
proporcionar ideas que puedan ser útiles para la mejora de procesos.
3.14. Prácticas genéricas
Las prácticas genéricas se denominan “genéricas” porque la misma práctica se aplica a
múltiples áreas de proceso. Las prácticas genéricas asociadas con una meta genérica describen
las actividades que se consideran importantes para lograr la meta genérica y contribuir a la
institucionalización de los procesos asociados con un área de proceso.
3.15. Elaboraciones de la práctica genérica
Las elaboraciones de la práctica genérica aparecen después de las prácticas genéricas para
orientar en la forma en que pueden aplicarse, de forma única, las prácticas genéricas a las
áreas de proceso.

4. Áreas de proceso que se involucran en el nivel 2 de CMMI
4.1. Gestión de configuración (CM)
El propósito de la Gestión de Configuración (CM) es establecer y mantener la integridad de los
productos de trabajo utilizando la identificación de la configuración, el control de la
configuración, el informe del estado de la configuración y las auditorías de la configuración.
El área de proceso de Gestión de Configuración implica las siguientes actividades:
● Identificar la configuración de los productos de trabajo seleccionados que componen las
líneas base en puntos determinados en el tiempo.
● Controlar los cambios a los elementos de configuración.
● Construir o proporcionar las especificaciones para construir los productos de trabajo a
partir del sistema de gestión de configuración.
● Mantener la integridad de las líneas base.
● Proporcionar a los desarrolladores, usuarios finales y clientes datos precisos del estado
y de la configuración actual.
4.2. Medición y análisis (MA)
El propósito de Medición y Análisis (MA) es desarrollar y mantener la capacidad de medición
utilizada para dar soporte a las necesidades de información de la gerencia.
El área de proceso Medición y Análisis implica las siguientes actividades:
● Especificar los objetivos de medición y análisis para alinearlos con las necesidades de
información y con los objetivos del proyecto, de la organización o del negocio.
● Especificar las medidas, las técnicas de análisis y los mecanismos, para la recogida de
datos, almacenamiento de datos, difusión y realimentación.
● Implementar las técnicas de análisis y los mecanismos para la recogida de datos,
difusión de datos y realimentación.
● Proporcionar resultados objetivos que puedan utilizarse en la toma de decisiones.

4.3. Monitorización y control del proyecto (PCM)
El propósito de la Monitorización y Control del Proyecto (PMC) es proporcionar una
comprensión del progreso del proyecto para que se puedan tomar las acciones correctivas
apropiadas, cuando el rendimiento del proyecto se desvíe significativamente
del plan.
Algunos ejemplos de recursos son:
● Sistemas de seguimiento de costes.
● Sistemas de seguimiento de esfuerzo.
● Sistemas de seguimiento de elementos de acción.
● Programas de gestión del proyecto y del calendario.
4.4. Planificación del proyecto (PP)
El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan
las actividades del proyecto.
El área de proceso Planificación del Proyecto implica las siguientes actividades:
● Desarrollar el plan de proyecto.
● Interactuar de forma apropiada con las partes interesadas relevantes.
● Obtener el compromiso con el plan.
● Mantener el plan.
4.5. Aseguramiento de la calidad del proceso y del producto (PPQA)
● Paquetes de análisis estadístico.
● Paquetes de control de calidad y de control estadístico de procesos.
● Scripts y herramientas que ayudan a los equipos a analizar su propio rendimiento de
proceso con necesidad mínima de asistencia adicional de expertos.

4.6. Gestión de requisitos (REQM)
El propósito de la Gestión de Requisitos (REQM) es gestionar los requisitos de los productos y
los componentes de producto del proyecto, y asegurar la alineación entre esos requisitos, y
los planes y los productos de trabajo del proyecto.
Los procesos de gestión de requisitos gestionan todos los requisitos recibidos o generados por
el proyecto, incluyendo tanto los requisitos técnicos como los no técnicos, así como los
requisitos impuestos al proyecto por la organización.
● Herramientas para el seguimiento de los requisitos.
● Herramientas de trazabilidad.
4.7. Gestión de acuerdos con proveedores (SAM)
El propósito de la Gestión de Acuerdos con Proveedores (SAM) es gestionar la adquisición de
productos y servicios de proveedores.
El alcance de esta área de proceso aborda la adquisición de productos, servicios y
componentes de producto y de servicio que pueden ser entregados al cliente del proyecto o
incluidos en un producto o sistema de servicios. Estas prácticas del área de proceso también
pueden ser utilizadas para otros propósitos que beneficien al proyecto (p.ej., compra de
consumibles). Esta área de proceso no se aplica en todos los contextos en los que se
adquieren los componentes comerciales (COTS), sino que se aplica en los casos donde hay
modificaciones a los componentes (COTS), en componentes comerciales de gobierno, o en
software libre, que son un valor importante para el proyecto o que representan un riesgo
importante para el proyecto.
El área de proceso Gestión de Acuerdos con proveedores implica las siguientes actividades:
Determinar el tipo de adquisición.
● Seleccionar los proveedores.
● Establecer y mantener acuerdos con los proveedores.
● Ejecutar los acuerdos del proveedor.
● Aceptar la entrega de los productos adquiridos.
● Asegurar una transición satisfactoria de los productos adquiridos.

5. Cuadro PIIDB (Practice Implementation Indicators DataBase)
5.1. Institucionalizar un proceso gestionado.
Artefacto Directo Artefacto Indirecto Afirmación
GP 2.1. Establecer
las políticas de la
organización
La Gerencia Define y
formaliza las
expectativas de la
organización en
relación con los
procesos de nivel 2 y
proyectos.
Se comunican las
directrices
organizacionales por
diferentes medios:
Intranet. Carteleras,
cartillas de difusión,
página web)
Se realizaran cartillas
de divulgación
GP 2.2. Planificar los
procesos
Elaboración de planes
de procesos y
proyectos en los
cuales se definen:
responsables,
indicadores, áreas a
las que aplica y
descripciones
generales.
Se identifica el
número de horas
asignadas a los
proyectos y de las
cuales se tendrá
control a través de
herramientas como:
Cronogramas, Gantt,
Reporte de horas
trabajadas por el
personal.
Registro de horas
GP 2.3. Proporcionar
los recursos
adecuados
Herramientas de
ejecución: equipos de
cómputo (con hojas de
vida). Herramientas de
seguimiento para
monitorear el estado
de cada uno de los
equipos de cómputo.
Facturas de compra de
los equipos y
maquinaria.
Facturación
GP 2.4. Asignar las
responsabilidades
Identificación,
definición y
formalización de cada
uno de los roles junto
con sus
Actas donde se
asignan los
integrantes del
proyecto y se explican
sus responsabilidades.
Listas de asistencia

responsabilidades
respecto al proceso.
GP 2.5. Formar al
personal
Descripciones de los
procesos de
capacitación, material
que se utilizará en
cada capacitación,
evaluaciones que se
aplicaran una vez
finalizadas las
capacitaciones e
indicadores que
permitan medir el
nivel de satisfacción
con las
capacitaciones.
Listas de asistencias a
los cursos de
formación
programados.
Listas de asistencia
GP 2.6. Gestionar
la configuración
Implementar el gestor
de la configuración
(Tortoise, SVN, CVS,
Subversion,
SourceSafe,
ClearCase, Darcs,
Plastic SCM)
Logs donde se
muestre el control al
código fuente.
Seguimiento del
estado de las
versiones y sus
cambios. Control
sobre la integración
de las partes del
software en un solo
producto de software.
Archivos de Logs
GP 2.7. Identificar los
actores importantes
Establecimiento de
criterios para la
evaluación objetiva de
los procesos de
comunicación
empresarial, en los
cuales se identifican
los actores
(principales
y secundarios)
Actas de las reuniones
programadas y no
programadas del
proyecto.
Actas de reuniones
GP 2.8. Monitorizar y Evaluaciones objetivas Acciones correctivas, Registro de las

controlar los procesos del proceso
planificadas y
ejecutadas.
Evaluaciones objetivas
de producto de
trabajo planificadas y
ejecutadas.
Acciones preventivas y
Acciones de mejora
asociadas al
desempeño de los
procesos y proyectos.
objetivas. Se
comunican los
resultados a todos los
involucrados.
acciones correctivas,
preventivas y de
mejora
GP 2.9. Evaluar
objetivamente el
cumplimiento
Auditorías internas y
externas:
1. Evaluar
objetivamente los
procesos y los
productos de trabajo.
2. Seguir y comunicar
las no conformidades.
3. Informes de no
conformidad.
4. Registros e
informes de
evaluación.
Programación de la
auditoría Listas de
chequeo de auditoría
Informes de auditoría
Listas de asistencia a
la auditoría Actas de
auditorías
Informes de auditoría
GP 2.10. Revisar el
proyecto con los
responsables de
mayor nivel
Reunión Gerencial
donde se revisan y
evalúan los estados
de los procesos de la
empresa.
Actas de las reuniones
gerenciales.
Actas de reunión.
5.2. Gestión de configuración (CM)
SP 1.1. Identificar
cada componente
susceptible de ser
versionado.
Documento o tool
Donde sí identifican
los Elementos de
Configuración de las
Tiempo dedicado a la
elaboración, horas,
actas, etc
Registro de Horas

Líneas de base.
Pueden servicio
Productos Que se
entregan al Cliente,
Herramientas,
Diseños, planos de
Pruebas, Prototipos,
Resultados de
Pruebas, en
documentos, etc
SP 1.2. Establecer y
mantener un sistema
de administración
de la
configuración.
Herramienta de
Gestión de la
configuración
(Tortoise, SVN, CVS,
Subversion,
SourceSafe,
ClearCase, Darcs,
Plastic SCM)
Histórico de
revisiones y roles de
acceso al sistema de
gestión de la
configuración.
Logs de herramientas
de gestión de
configuración
Logs de
configuración
SP 1.3. Crear líneas
base (para uso interno
o para entregar al
cliente).
Descripción de las
entregas formales a
realizar durante el
proyecto, tanto de
productos software
como de
documentación,
describiendo los
elementos que
contiene.
Histórico de entregas
formales realizadas.
SP 2.1. Monitorizar
los requisitos de
cambio.
Peticiones de cambio
realizadas durante el
proyecto.
Registro con la
aprobación o
denegación de un
cambio en el sistema.
SP 2.2. Controlar los
componentes que han
cambiado.
Servidor de
integración continua
que integra
periódicamente el
código realizado hasta
ese momento,
Registros de auditoría
interna o externa
Registros de
Ejecuciones del
Servidor de
Integración Continua.

identificando errores
o conflictos. No
conformidades
identificadas durante
las auditorías internas
y externas. Logs de
ejecuciones del
servidor de
integración continua.
mantener registros
describiendo cada
iteración de la
configuración
Historia revisiones de
las Tareas de Gestión
de configuración.
Historia revisiones de
los Cambios
implementados Entre
dos versiones de la
línea base.
Incidencias en la
Gestión de
configuración (ej.
Establecimiento de
ramas, "fusiona" que
no funcionan).
Histórico de Cambios
en la Herramienta de
Gestión de la
configuración
SP 3.2. Ejecutar
auditorías a la
configuración para
mantener la
integridad.
Informe de auditoría
interna o externa.
No conformidades
extraídas de la
5.3. Medición y análisis (MA)
SP 1.1. Definir cuáles
van a ser los objetivos
de la medición.
Documento con los
objetivos de medición,
donde se indican los
objetivos de negocio y
su relación con los
indicadores de
medición.
Correos de
sugerencias de
indicadores. Histórico
de indicadores.

SP 1.2. Especificar
medidas (métricas
básicas, número de
requerimientos,
esfuerzo esperado en
la corrección de
errores).
Descripción de los
indicadores de
medición: Unidades de
Medida, mecanismo de
Recogida, periodicidad
de la recolección,
Objetivo de la
medición, etc
Reunión para la
definición de los
indicadores. Histórico
de resultados de las
mediciones. Catálogo
genérico de métricas.
Listado de indicadores
de medición.
SP 1.3. Establecer
procedimientos de
recolección de datos y
almacenamiento de
los mismos.
Descripción de los
indicadores de
medición Unidades de
Medida, Mecanismo e
Recogida, etc Sección
en la documentación
de donde se indica
Cómo se almacenan
los Datos
Procedimiento de
medición y análisis
desarrollado. Logs de
las herramientas de
recolección
automática de datos.
SP 1.4. Establecer el
procedimiento de
análisis.
Descripción de los
indicadores de
medición, umbrales y
análisis a realizar.
Plantilla de los
Informes de
Indicadores
SP 2.1. Guardar las
mediciones.
Informe que contenga
los datos extraídos de
la medición
Horas dedicadas a
realizar el Informe.
Registros de las
Herramientas de
recolección
automática de Datos.
Informe de mediciones
SP 2.2. Analizar las
mediciones (para ver
si los datos obtenidos
son Correctos).
Informe de Análisis de
los datos obtenidos.
Reuniones para el
análisis de los datos
Acciones correctivas
asociadas al análisis y
almacenamiento de
los datos
SP 2.3. Almacenar los
datos y resultados
obtenidos (métricas
básicas y calculadas).
BBDD de Indicadores,
Con Los Resultados
de las Mediciones
Anteriores y Actuales
Horas asignadas para
el análisis y
almacenamiento de
los resultados

SP 2.4. Comunicar los
resultados del
proceso a los
involucrados.
Correo electrónico
Actas, donde se
evidencie la
comunicación de los
resultados
comunicaciones de los
resultados
Respuestas sobre los
resultados
comunicados
Actas de reuniones
5.4. Monitorización y control del proyecto (PMC)
SP 1.1. Monitorizar
los parámetros del
Plan de proyecto (%
de avance, fechas
reales vs fechas
estimadas, número de
requerimientos
atendidos vs los
planeados, etc).
Actas de seguimiento
llevadas a cabo.
Herramienta de
seguimiento (por
ejemplo Gantt de
seguimiento, Trac,
etc.).
Registro de la revisión
de las horas
imputadas al
proyecto.
Registro de horas
SP 1.2. Monitorizar
los compromisos
Actas de reunión de
seguimiento, informes
de avance, de
cumplimiento de hitos,
etc.
Horas programadas al
seguimiento del
proyecto
SP 1.3. Monitorizar
los riesgos.
Identificación de
nuevos riesgos a lo
largo del proyecto
Acta de reunión de
seguimiento en la que
se tratan
explícitamente los
riesgos del proyecto.
Actas de reunión
SP 1.4. Monitorizar
Plan de
administración de
datos (que los datos
existan y estén
Servidor de
integración continua.
Registro de tareas de
gestión de datos.
Logs del sistema de
copias de seguridad.
Histórico de
revisiones en gestor
de configuración.

almacenados en el
lugar correcto).
SP 1.5. Monitorizar de
la involucración de los
interesados.
entrega de hitos
intermedios.
Correos o
notificaciones entre
los implicados.
SP 1.6. Realizar
revisiones del
progreso del proyecto
(avance del mismo).
seguimiento
Horas asignadas
atribuidas por parte
del equipo a tareas
del proyecto.
Impedimentos
detectados durante
las reuniones de
seguimiento
SP 1.7. Realizar
revisiones de los hitos
del proyecto.
entrega intermedia,
reuniones intermedias
de chequeo con el
cliente. Acta de
reunión de final de un
Sprint
Riesgos del proyecto
revisados durante la
realización del hito.
SP 2.1. Analizar los
problemas.
Incidencias registradas
y analizadas
Planificación
modificada incluyendo
las incidencia y su
estimación
SP 2.2. Tomar
acciones correctivas.
Documento o registro
de acciones
correctivas.
Histórico de cambios
de estado de las
incidencias
SP 2.3. Administrar
las acciones
correctivas
Histórico de acciones
correctivas,
participantes, planes
derivados, etc.
Acta de reunión al
final.
Planes de mejora
asociados

5.5. Planificación del proyecto (PP)
SP 1.1. Estimar el
alcance del proyecto
(relación de tareas).
Plan de proyecto
donde se indican el
alcance del sistema.
Descripción de las
tareas a realizar
durante el proyecto.
Horas dedicadas a la
tarea de estimación
del alcance, oferta
inicial, estudio de
viabilidad, etc
Plan de proyecto
SP 1.2. Realizar
estimaciones de los
productos de trabajo
y atributos de las
tareas (tamaño en
puntos función, líneas
de código, etc).
Diagrama de Gantt en
el que se describe la
duración de las tareas,
con base en una
estimación por
analogía. Planificación
del sprint backlog.
Informe con los
resultados de la
estimación
Horas planeadas para
la realización de la
estimación por
analogía, punto
función, puntos póker,
etc
Estimaciones
SP 1.3. Definir el ciclo
de vida del proyecto
(diferentes fases del
proyecto).
Una sección,
usualmente
incorporada al plan de
proyecto donde se
describen las fases
que contendrá el
proyecto (análisis,
diseño, despliegue,
iteraciones, etc.), la
relación entre estas
fases y su ordenación
temporal (cascada,
iterativo, incremental,
etc.
Hitos definidos en el
diagrama de Gantt.
SP 1.4. Realizar
estimaciones de
esfuerzo y coste.
Informe en el que se
representan los
resultados de la
estimación del
esfuerzo necesario y
Horas dedicadas a la
tarea de estimación

el método usado.
presupuesto y
calendario del
proyecto
Presupuesto del
documento del plan
de proyecto.
Herramienta de
cálculo de esfuerzo y
coste completada
Registro de horas
SP 2.2. Identificar los
riesgos del proyecto.
Matriz de riesgos
identificados para el
proyecto. Checklist
que evalúa los riesgos
para el proyecto.
Catálogo genérico de
riesgos. Horas
asignadas a la tarea
de identificación de
riesgos
Riesgos iniciales
identificados
SP 2.3. Definir un plan
para administrar los
datos.
Listado de los datos
gestionados en el
proyecto, con la
descripción del
formato, requisitos de
privacidad y
seguridad. Descripción
del sistema de
Backup.
Datos que requieren
confidencialidad.
Estructura de carpetas
y permisos para
controlar datos
confidenciales. Logs
de backups realizados
para el proyecto.
recursos.
Listado de
equipamiento,
instalaciones y
software asociado con
el proyecto. Listado
de recursos humanos
necesarios
Orden de compra de
equipamiento. Acta de
reunión interna de
inicio de proyecto
conocimientos y
habilidades.
Listado de habilidades
necesarias por parte
de los miembros del
equipo. Plan de
personal y de nuevas
contrataciones.
Actividades de
formación para los
perfiles del proyecto.
Material de formación.
para involucrar a los
interesados.
Listado de los
participantes del
proyecto y rol que
Acta de inicio del
proyecto en la que
participan tanto el

juegan en el mismo.
Comunicación formal
a las personas que
participarán en el
proyecto (cliente,
desarrolladores,
equipo de pruebas,
etc.).
cliente como los
principales
involucrados en el
proyecto y se explica
el plan de
comunicación.
Plan General del
proyecto.
Plan del proyecto Horas dedicadas a la
tarea de planificación.
Plantilla de plan de
proyecto.
SP 3.1. Revisar los
planes que afectan al
proyecto (con los
involucrados).
Matriz de relaciones
entre proyectos,
planificación de
proyectos y recursos
asignados en la
unidad organizacional.
Documento con la
ocupación de recursos
de la organización.
Registro de resolución
de conflictos
SP 3.2. Reconciliar el
trabajo y el nivel de
los recursos.
Presupuestos
renegociados. Control
de la asignación y
capacidad de los
recursos.
Revisión en
herramienta de
gestión personal y de
control de horas.
SP 3.3. Conseguir el
compromiso de los
involucrados con el
Plan de proyecto
Aceptación por los
afectados del plan de
proyecto.
Acta de reunión de
inicio del proyecto con
la participación del
equipo.

5.6. Aseguramiento de la calidad del proceso y del producto (PPQA)
SP 1.1. Evaluar
objetivamente los
procesos.
Plan de calidad donde
se han registrado las
diferentes auditorías
independientes que se
realizarán a los
proyectos.
evaluación de los
procesos.
Plan de calidad
Registro de horas
SP 1.2. Evaluar
objetivamente los
productos de trabajo y
servicios.
Informes de pruebas
de los productos y
servicios. Informes de
auditoría interna o
externa realizada al
proyecto
Histórico de casos de
prueba. Horas
dedicadas a las
auditorías.
SP 2.1. Comunicar las
no conformidades y
asegurar su
resolución.
No conformidades
detectadas Durante la
Auditoría comunicadas
a los Proyectos y
asignadas al
responsable de la
solución
asociadas a las no
conformidades
Registro de acciones
correctivas
mantener registro de
actividades.
Plan de calidad e
informes de auditoría.
Almacenamiento de
las no conformidades
identificadas en las
auditorías
Horas dedicadas a las
auditoría
Plan de auditoría

5.7. Gestión de requisitos (REQM)
SP 1.1 Obtener una
comprensión de los
requerimientos
Aplicación de un
listado de criterios
definidos para la
evaluación y la
aceptación de los
requisitos. Resultados
del análisis de los
requisitos frente a los
criterios de
aceptación.
Correos electrónicos o
actas de reunión en
los cuales se evidencia
el entendimiento,
negociación o cambio
de requisitos.
Actas de reunión
SP 1.2 Obtener el
compromiso sobre los
requerimientos
Documento de
requisitos aceptado.
Acta de reunión donde
se aceptan los
requisitos.
Histórico de requisitos
cuyo estado pasa a
ser aceptado.
Documento de
requisitos
SP 1.3 Gestionar los
cambios en los
requerimientos
asociadas con
requisitos.
Requerimientos
versionados.
Histórico de requisitos
cuyo estado haya
pasado a “abierto”
tras haber sido
“cerrado”
SP 1.4 Mantener una
trazabilidad
bidireccional de los
requerimientos
Matriz de trazabilidad
entre requisitos y los
demás elementos que
componen el producto
software (ej. diseño,
casos de prueba,
código fuente, etc.)
Análisis de cambio
donde se ha utilizado
la matriz de
trazabilidad para
valorar el impacto
Documento de control
de cambios
SP 1.5 Identificar las
inconsistencias entre
el trabajo del proyecto
y los requerimientos
Informe de pruebas.
Listado de
inconsistencias
asociadas a las
inconsistencias
encontradas entre el
proyecto y los
requisitos.

5.8 Gestión de acuerdos con proveedores (SAM)
SP 1.1 Determinar el
tipo de compra
Política de acuerdos
con proveedores,
definiendo los tipos de
compras posibles
(productos off-the-
shelf, productos a
medida, etc.)
Requisito del proyecto
donde se describe el
módulo a contratar.
Requisito del proyecto
donde se describe el
módulo un Contratar.
Contrato con el
proveedor
SP 1.2 Seleccionar los
proveedores
Plantilla de
homologación de
proveedores. Listado
de proveedores.
Informe de
homologación
SP 1.3 Establecer los
acuerdos con el
proveedor
Contrato Con El
Proveedor Actas
Acuerdo Realizado Acta de acuerdo con el
proveedor
SP 2.1 Realizar el
acuerdo del Proveedor
Informes de Cierre de
Acuerdos y de
progreso del
Proveedor.
Registro de
incidencias Reuniones
de seguimiento
Actas de reunión
SP 2.2 Monitorizar los
procesos de selección
del proveedor.
Informes de
Seguimiento del
Proveedor. Informes
De discrepancias.
Registro de horas de
a monitorización de
Actividades del
Proveedor.
Registro de Horas
SP 2.3. Evaluar los
productos
seleccionados del
proveedor
Listado de productos
seleccionados Evaluar
al proveedor Informes
de selección de
proveedores
Registro de horas a la
evaluación de
productos de terceros.
SP 2.4. Aceptar los
productos adquiridos
Resultados de las
pruebas de aceptación
Histórico de las
incidencias y sus
resoluciones
SP 2.5. Transferir los Planes de transición y Registro de horas de

productos despliegue, gestión
del cambio, paso a
producción, a pre-
producción, etc.
Informes de formación
sobre los nuevos
productos.
cada empleado que se
involucró en
actividades de
formación
relacionadas con el
producto. Informe de
incidencias durante
el despliegue

6. Propuesta para calificar las áreas de proceso
Basado en el modelo CMMI, se propone una forma de calificación de las áreas del proceso
teniendo en cuenta el estado del PII, los auditores comprobaran los procesos, y el nivel de
implementación que tienen, para ello se usara una escala de 4 items, para evidenciar el estado
en que se encuentran Se ha de comprobar si se cumplen las prácticas definidas para cada una
de las áreas de proceso definidas en el nivel de madurez.
Los items son los siguientes:
Excelente
● Artefactos directos presentes y adecuados
● Artefactos indirectos y/o Afirmaciones
● No se han notado debilidades
Sobresaliente
● Artefactos directos presentes y adecuados
● Artefactos indirectos y/o Afirmaciones
● Se han notado una o más debilidades
Aceptable
● Artefactos directos no encontrados o inadecuados
● Artefactos indirectos y/o afirmaciones indican que parte de la practica ha sido
implementada
● Artefactos directos presentes y adecuados pero no se encuentra otra evidencia que
soporte la práctica
● Se han encontrado una o más debilidades

Insuficiente
● Artefactos directos no encontrados yo inadecuados
● No se encuentra otra evidencia que soporte la práctica
Fases de la evaluación
Preparación y planificación
En esta fase se seleccionaran los objetivos de la mejora, se definirá el método de captura de
evidencias, etc. Esta fase será realizada conjuntamente el auditor principal y el auditor.
Preparación de Revisión
En esta fase se estudia si los proyectos que van a ser evaluados y la organización está
preparada para la auditoría. Es necesario que esta fase se realice al menos una vez.
Ejecución de la auditoría y comunicación de resultados
El equipo de auditoría irá comprobando las prácticas de las áreas de proceso, comprobando el
estado de implementación en el que se encuentran. Para ello, revisará los indicadores de
implementación de la práctica (PII). A cada una de las prácticas se le dará una calificación en
función de las evidencias encontradas.
Una vez se dé por finalizada la auditoría, el equipo preparará un informe en el que detalla el
nivel de cumplimiento de cada una de las metas (genéricas y específicas), prácticas y el
conjunto de debilidades detectadas que terminaran por establecer el nivel de cumplimiento de
cada área de proceso.
Partiendo de lo anteriormente descrito podemos afirmar que contamos con evidencia objetiva y
se cuenta con artefacto directo (documento de diseño), un artefacto indirecto (documento de
aprobación) y también una afirmación (teleconferencia con el cliente) que da como resultado
una evidencia objetiva en esta etapa del ciclo de vida de desarrollo de software.
Si se pretende evaluar otras etapas debemos definir los artefactos directos e indirectos y las
afirmaciones para cada una de ellas. De esta forma tendremos la propuesta de evaluación para
la empresa.

7. Bibliografía
● Guía práctica de supervivencia en una auditoría CMMI, Javier Garzás Parra.
● Spanish Technical Report CMMI v1.3
● Technical Report CMMI v1.3

Cmmi

Más contenido relacionado

La actualidad más candente (20)

Similar a Cmmi (20)

Último (10)

Cmmi