Formación Cmmi-Dev l2

Interpretando el modelo CMMI-DEV
reas de proceso REQM, PP, PMC, MA, PPQA, CM, SAM
Capability Maturity Model and CMMI are registered

in the U.S. Patent and Trademark Office by
Carnegie Mellon University
ESI
1
ndice de contenidos
Visin general del modelo CMMI-DEV

Gestin de requisitos (REQM)
Planificacin de proyecto (PP)
Seguimiento y control de proyecto (PMC)
Medicin y anlisis (MA)
Aseguramiento de la calidad de proceso y producto (PPQA)
Gestin de configuracin (CM)
ESI
ndice de contenidos

Gestin de acuerdos con proveedores (SAM)
ESI
CMMI
Capability Maturity Model Integration (CMMI) es un modelo para la

mejora de procesos que proporciona a las organizaciones los
elementos esenciales para implantar y mantener procesos eficaces.
Las mejores prcticas CMMI se publican en los documentos llamados

modelos. En la actualidad hay tres reas de inters cubiertas por los
modelos de CMMI: Desarrollo, Adquisicin y Servicios.
La versin actual de CMMI es la versin 1.3. Hay tres constelaciones

de la versin 1.3 disponible:
CMMI para el Desarrollo (CMMI-DEV o CMMI for Development). En l se tratan procesos

de desarrollo de productos y servicios.
CMMI para la Adquisicin (CMMI-ACQ o CMMI for Acquisition). En l se tratan la gestin de
la cadena de suministro, adquisicin y contratacin externa en los procesos del gobierno y
la industria.
CMMI para Servicios (CMMI-SVC o CMMI for Services), est diseada para cubrir todas las
actividades que requieren gestionar, establecer y entregar Servicios.
ESI
Constelaciones CMMI
CMMI-SVC
CMMI-DEV
Proporciona guas
para medir,
controlar y
gestionar los
procesos de
desarrollo de
software
16 reas de
proceso
usadas en
todos
Proporciona guas
para aquellos que
proveen servicios
dentro de la
organizacin y a
clientes externos
CMMI-ACQ
Source: 2006 Carnegie Mellon University; CMMI v1.2 Upgrade Training, Module 5
ESI
5
proporciona una
gua para habilitar
una gestin en
adquisiciones
informada y
decisiva
Los niveles de madurez

5
5. En
optimizacin
Foco en la mejora continua
4. Gestionado
cuantitativamente
El proceso se controla cuantitativamente
3. Definido
3
Proceso definido para la

organizacin y proactivo
2. Gestionado
2
Proceso definido caracterizado

para proyectos y frecuentemente
reactivo
1. Inicial
DESEABLE
Proceso impredecible,
poco controlado
ESI
META
reas de Proceso
Un rea de Proceso (PA) es un grupo de prcticas
relacionadas que colectivamente ayudan a alcanzar un
conjunto de metas
Son los bloques fundamentales que permiten
establecer la capacidad del proceso de una
organizacin
Cada rea de proceso reside en un nivel de madurez
ESI
Tipos de metas y prcticas

Metas y Prcticas Especficas
indican qu debe ser implantado para cada
rea de Proceso
por lo tanto, son especficas de cada rea de Proceso
Metas y Prcticas Genricas
indican qu debe ser implantado para institucionalizar
cada rea de Proceso
por lo tanto, son aplicables para todas las reas de
Proceso
ESI
Estructura modelo
Staged v1.2
Maturity Level
Process
Area 1
ESI
Process
Area 2
Process
Area n
Generic Goals
Specific Goals
Generic
Practice
s
Specific
Practice
s
Nivel de Madurez 2: Gestionado

2
Gestin de proyectos disciplinada

Se establecen y siguen polticas organizativas
Se documentan y siguen planes de proyecto y descripciones de
procesos
Los recursos son los adecuados (humanos, materiales)
Se asignan responsabilidades y autoridades a lo largo de la vida del
proyecto
La disciplina ayuda a mantener las prcticas existentes en tiempos de
estrs
La Direccin tiene visibilidad sobre el estado de las actividades y los
productos en puntos definidos
ESI
10
reas de Proceso en el Nivel de Madurez 2

Gestin de Requisitos
Planificacin de Proyecto
Seguimiento y Control de Proyecto
Gestin de Acuerdos con Proveedores
Medicin y Anlisis
Aseguramiento de la Calidad de
Proceso y Producto
Gestin de la Configuracin
Inicial
ESI
11
En
optimizacin
Gestionado
Cuantitativamente
Definido
Gestionado
Visin general modelo CMMI-DEV v1.2

Representacin escalonada
reas de proceso
Innovacin y Despliegue Organizativo (OID)
Anlisis Causal y Soluciones (CAR)
5
4
Rendimiento de Procesos Organizativos (OPP)

Gestin de Proyectos Cuantitativa (QPM)
Nivel madurez 4 OPP, QPM1
Nivel madurez 3 RD, TS, PI,
VER, VAL, OPF, OPD, OT, IPM,

RSKM, DAR
Nivel madurez 2 REQM, PP,
Organizacin
PMC, MA, PPQA, CM, SAM
Gestin
Gestin
procesos
procesos
OPF,
OPF,OPD,
OPD,OT,
OT,
OPP,
OPP,OID
OID
Gestin de Requisitos (REQM)

Planificacin del Proyecto (PP)
Seguimiento y Control del Proyecto (PMC)
Gestin de Acuerdos con Proveedores (SAM)
Medicin y Anlisis (MA)
Aseguramiento Calidad Proceso Producto (PPQA)
Gestin de la Configuracin (CM)
ESI
12
Gestin
Gestin
proyectos
proyectos
Soporte
Soporte
PP,
PP,PMC,
PMC,SAM,
SAM,
IPM,
IPM,RSKM,
RSKM,QPM
QPM
Ingeniera
Ingeniera
CM,
CM,PPQA,
PPQA,MA,
MA,
CAR,
CAR,DAR
DAR
REQM,
REQM,RD,
RD,TS,
TS,
PI,
PI,VER,
VER,VAL
VAL
0 1 2 3 4 5
Representacin continua
Capacidad
Desarrollo de requisitos (RD)

Solucin tcnica (TS)
Integracin de Producto (PI)
Verificacin (VER)
Validacin (VAL)
Enfoque al Proceso Organizativo (OPF)
Definicin del Proceso Organizativo (OPD+IPPD)
Formacin Organizativa (OT)
Gestin Integrada de Proyecto (IPM+IPPD)
Gestin del Riesgo (RSKM)
Anlisis de Decisiones y Soluciones (DAR)
Nivel madurez 5 OID, CAR
PA PA
PA
Proceso
ndice de contenidos

ESI
13
Gestin de Requisitos
El propsito de la Gestin de Requisitos (REQM) es gestionar los requisitos de
los productos del proyecto y los componentes del producto, e identificar
inconsistencias entre dichos requisitos y los planes de proyecto y productos de
trabajo.
ALS
ESI
SG1: Gestionar Requisitos

Se gestionan los requisitos y se identifican las inconsistencias
con los planes de proyecto y productos de trabajo.
14
SG1 : Gestionar Requisitos
Se gestionan los requisitos y se identifican las inconsistencias con

los planes de proyecto y productos de trabajo
Las siguientes prcticas estn asociadas a esta meta :
SP1.1 : Entender los requisitos

SP1.2 : Obtener el compromiso con los requisitos
SP1.3 : Gestionar los cambios en los requisitos
SP1.4 : Mantener una trazabilidad bidireccional entre los requisitos
SP1.5 : Identificar inconsistencias entre los productos de trabajo y los
requisitos
ESI
15
GG2: Institucionalizar un proceso gestionado

El proceso es institucionalizado como un proceso gestionado
Las siguientes prcticas estn asociadas a esta meta
GP2.1 : Establecer una poltica en la organizacin

GP2.2 : Planificar el proceso
GP2.3 : Proporcionar recursos
GP2.4 : Asignar responsabilidades
GP2.5 : Formar al personal
GP2.6 : Gestionar la configuracin
GP2.7 : Identificar e involucrar a los participantes importantes
GP2.8 : Dar seguimiento y controlar el proceso
GP2.9 : Evaluar objetivamente la adherencia del proceso
GP2.10 : Revisar el estado del proceso con el nivel superior de gestin
ESI
16
Hallazgos Obligatorios REQM
Un conjunto documentado de requisitos
Un conjunto documentado de requisitos analizados (Documento requisitos)
Los requisitos pueden estar formalizados en un documento, una BD, una herramienta
especfica de gestin de requisitos, actas de reunin, correos, etc.
Los requisitos deben ser analizados para asegurar que la comprensin del proveedor y los
deseos del cliente se encuentran alineados. El anlisis de los requisitos puede puede
quedar reflejado en un documento, una herramienta especfica, una base de datos, etc.
Un conjunto documentado de cambios a los requisitos
Un cambio es una modificacin, cambio o eliminacin de un requisito. Todos los cambios

deben quedar documentados y deben existir referencias sobre los requisitos modificados o
eliminados. Tambin sera muy conveniente documentar el anlisis de impacto realizado
para evaluar el impacto del cambio y no slo el resultado de este cambio.
ESI
17
Hallazgos Obligatorios REQM
Evidencias de compromiso con los requisitos
Tanto para el conjunto inicial de requisitos como para los cambios debe existir un
compromiso explcito del equipo del proyecto y del cliente. Este compromiso puede ser una
firma de aprobacin del documento de requisitos por el cliente, un correo, actas de reunin
del equipo del proyecto conjuntamente con aprobaciones del plan de proyecto An
teniendo en cuenta que al principio del proyecto la mayora de los requisitos no son
conocidos, esto no es motivo para que no exista un compromiso con los requisitos.
Trazabilidad entre los requisitos
La trazabilidad ayuda a realizar anlisis de impacto a los cambios a los requisitos, en

consecuencia el nivel mnimo de trazabilidad a mantener depender de la volatilidad de los
requisitos y la criticidad del software. Una buena prctica es establecer al menos
trazabilidad entre los requisitos y los casos de prueba. Las relaciones o dependencias entre
los requisitos deberan quedar documentadas, as como las relaciones entre los requisitos,
las especificaciones funcionales y/o casos de uso.
ESI
18
ndice de contenidos

ESI
19
Planificacin de Proyecto
El propsito de la Planificacin de Proyecto (PP) es establecer y mantener planes
que definan las actividades del proyecto.
ALS
SG1: Realizar estimaciones

Se establecen y mantienen estimaciones de los parmetros
de planificacin del proyecto.
SG2: Desarrollar un plan de proyecto
Se establece y mantiene un plan de proyecto como base para
su gestin.
SG3: Obtener el compromiso con el plan
Se establecen y mantienen los compromisos con el plan de
proyecto.
ESI
20
SG1 : Realizar estimaciones
Se establecen y mantienen estimaciones de los parmetros de

planificacin del proyecto.

SP1.1 : Estimar el alcance del proyecto
SP1.2 : Realizar estimaciones de los atributos de productos de trabajo y
tareas
SP1.3 : Definir el ciclo de vida del proyecto
SP1.4 : Estimar esfuerzo y coste
ESI
21
SG2 : Desarrollar un plan de proyecto
Se establece y mantiene un plan de proyecto como base para su

gestin.
SP2.1 : Establecer el presupuesto y el calendario

SP2.2 : Identificar riesgos del proyecto
SP2.3 : Planificar la gestin de los datos
SP2.4 : Planificar los recursos del proyecto
SP2.5 : Planificar los conocimientos y perfiles necesarios
SP2.6 : Planificar la involucracin de los participantes
SP2.7 : Realizar el plan del proyecto
ESI
22
SG3 : Obtener el compromiso con el plan
Se establecen y mantienen los compromisos con el plan de

proyecto.

SP3.1 : Revisar los planes que afectan al proyecto
SP3.2 : Compaginar las cargas de trabajo y los recursos
SP3.3 : Obtener el compromiso con el plan
ESI
23
Hallazgos Obligatorios PP
WBS documentada del proyecto
Estimaciones documentadas del tamao y la complejidad
Las tareas y los productos de trabajo del proyecto deben ser identificados con suficiente
detalle como para permitir las estimaciones. La descomposicin de las tareas debe incluir
tambin hitos o tareas no relacionadas con la ingeniera, como la gestin de proyecto, el
aseguramiento de la calidad, la gestin de la configuracin, etc. Es posible tener diferentes
WBS dependiendo de los diferentes ciclos de vida que se hayan definido en la organizacin.
Las estimaciones de esfuerzo deben basarse en estimaciones de tamao y complejidad.

Pueden utilizarse diferentes mecanismos para satisfacer este requisito, puntos de funcin,
medidas de complejidad basadas en datos histricos que identifiquen elementos contables
y establezcan una relacin entre la complejidad y el esfuerzo, etc.
Estimaciones documentadas de esfuerzo y coste
Las estimaciones de esfuerzo debern basarse en mtodos sistemticos (datos histricos

de proyectos comparables, modelos aplicados de estimacin del tamao, etc.). Las
estimaciones del esfuerzo debern ser ajustadas de acuerdo a diferentes factores tales
como los riesgos del proyecto, la experiencia de los equipos de trabajo, etc. Las
estimaciones del coste debern derivarse del clculo de los costes de trabajo, coste de
horas extras, gastos de viajes, formacin, materiales, etc.
ESI
24
Calendario documentado del proyecto
Recursos y habilidades
La WBS del proyecto deber evolucionar a un calendario donde se incluyan los hitos,
restricciones, disponibilidad de los recursos, paralelismo y dependencias entre tareas
En el plan de proyecto deber documentarse tanto los recursos (personas, equipos,

materiales, etc.) como la cantidad en la que son necesarios. Para las personas ser
tambin obligatorio planificar la formacin especfica en caso de que esta sea necesaria.
Lista documentada de los riesgos del proyecto
Para cada riesgo deber realizarse una evaluacin del mismo (normalmente basado en la
probabilidad de ocurrencia e impacto sobre el proyecto) y una mitigacin (acciones
preventivas para mantener el riesgo bajo un nivel aceptable de probabilidad o disminuir el
impacto sobre el proyecto) o contingencia (acciones correctivas cuando el riesgo se
materializa o la probabilidad supera el nivel establecido).
ESI
25
Evidencias documentadas de la involucracin de los stakeholders
El plan de proyecto debe representar el plan de todo el conjunto del proyecto, en

consecuencia deber incluir evidencias de que todas las partes (otros equipos de proyecto,
auditores, grupo de pruebas, grupo de configuracin, marketing, mantenimiento, etc)
afectadas por el proyecto de tal modo que el plan de proyecto se convierta en un plan de
proyecto integrado. Dependiendo de la relevancia de las partes externas las evidencias
documentadas de los stakeholders podrn ser implementadas como simples hitos o tareas
en el plan de proyecto o como una tabla de stackeholders en la cual se especifica para
cada una de las fases del ciclo de vida dnde estn involucrados junto con una descripcin
de su rol y responsabilidad para cada fase.
Plan de proyecto documentado
Si todo lo anterior existe, entonces tambin existe un plan de proyecto documentado, un

plan de proyecto puede tener diferentes nombres y puede estar formado por diferente
documentacin, eso no importa, el aspecto obligatorio es que el plan de proyecto debe
incluir todos los aspectos explicados con anterioridad. El plan de proyecto es un documento
vivo, normalmente existirn diferentes versiones alineadas con la planificacin de los
cambios que ocurran durante la ejecucin del proyecto derivados de cambios en los
requisitos o de cualquier otra circunstancia. Adems debe de existir un nivel de compromiso
apropiado (interno y externo) al plan de proyecto; este compromiso puede ser una firma
formal de un gerente y el cliente o simples evidencias de aceptacin tales como e-mails de
los stakeholders implicados.
ESI
26
ndice de contenidos

ESI
27
Seguimiento y Control del Proyecto

El propsito del Seguimiento y Control del Proyecto (PMC) es dar a conocer el
progreso del proyecto, de manera que se puedan tomar las apropiadas acciones
correctivas cuando el rendimiento del proyecto se desva significativamente
respecto del plan.
ALS
SG1: Dar Seguimiento al Proyecto respecto del Plan

Los resultados actuales y el progreso del proyecto son
supervisados respecto del plan de proyecto.
SG2: Gestionar y Cerrar Acciones Correctivas
Se gestionan hasta su cierre las acciones correctivas cuando
los resultados del proyecto se desvan significativamente
respecto del plan.
ESI
28
SG1 : Dar seguimiento del proyecto respecto del plan
Dar seguimiento al rendimiento y progreso actual del proyecto

respecto del plan.
SP1.1 : Dar seguimiento a los parmetros del plan del proyecto

SP1.2 : Dar seguimiento a los compromisos
SP1.3 : Dar seguimiento a los riesgos del proyecto
SP1.4 : Dar seguimiento a la gestin de los datos
SP1.5 : Dar seguimiento a la involucracin de los participantes
SP1.6 : Realizar revisiones peridicas
SP1.7 : Realizar revisiones de hitos
ESI
29
SG2 : Gestionar las acciones correctivas hasta su cierre
Las acciones correctivas se gestionan hasta su cierre cuando el

rendimiento o los resultados del proyecto se desvan
significativamente respecto a lo planificado.

SP2.1 : Analizar problemas
SP2.2 : Tomar acciones correctivas
SP2.3 : Gestionar las acciones correctivas
ESI
30
Hallazgos Obligatorios PMC
Registro del esfuerzo actual y de la estimacin del esfuerzo hasta la finalizacin
Los integrantes de equipo de proyecto debern registrar segn la periodicidad que se establezca
el esfuerzo actual incurrido y la estimacin del esfuerzo necesario para completar las tareas
asignadas
El esfuerzo incurrido real debera registrarse de acuerdo al modo en el que est establecido dentro
de la organizacin (horas, fracciones de das, etc.). La estimacin para la finalizacin puede
expresarse como un % sobre el progreso del trabajo ya realizado o como el esfuerzo necesario
para finalizar el trabajo. Estos dos datos cuantitativos son las bases para una gestin de proyecto
sistemtica, si ellos, el proyecto ser gestionado por impulsos o sensaciones en vez de por
hechos.
Compromisos monitorizados
Deben generarse evidencias de revisiones a los compromisos: estas pueden ser replanificaciones,
problemas a gestionar, riesgos, revisiones de hitos, revisiones a los compromisos (en aquellos
casos en los que este aspecto sea crtico para el proyecto). Los compromisos sern tanto externos
(con el cliente, subcontratista, proveedor externo, equipos de desarrollo externos, etc.) como
internos (equipo de desarrollo interno, equipo de pruebas, gerente de cuento, aseguramiento de
calidad, etc.). La monitorizacin de los compromisos est fuertemente ligada con la monitorizacin
de la involucracin de los stackeholders y con las revisiones de hitos.
ESI
31
Evidencias documentadas de la gestin de los riesgos
Deber existir una tabla de riesgos para el proyecto; esta tabla de riesgos deber de
actualizarse con las decisiones tomadas relativas a las acciones contencin o contingencia,
probabilidad, impacto, estado de los riesgos, nuevos riesgos identificados y problemas
derivados de la gestin de riesgos.
Criterios de salida en las revisiones de hitos
Normalmente, las revisiones de hitos son revisiones planificadas en etapas determinadas

del ciclo de vida que tienen que satisfacer unos criterios predefinidos. Es importante tener
evidencias de que esos se han establecido y que se han (o no se han) satisfecho cuando
se realiza la revisin del hito. Una revisin de hito puede ser simplemente una revisin
realizada por el jefe de proyecto para verificar que los criterios de salida se han satisfecho
(ej.: una lnea base de sw que ha sido entregada para pruebas del sistema, auditoras a la
lnea base ejecutadas, ausencia de errores abiertos, etc.)
ESI
32
Acciones Correctivas
El objetivo principal de la monitorizacin y control de proyectos es implantar las acciones

correctivas (cuanto sean necesarias) para minimizar las desviaciones respecto del plan.
Consecuentemente es obligatorio encontrar evidencias documentadas de que esas
acciones correctivas se llevan a cabo. Si las acciones correctivas modifican el plan de
proyecto y se genera una nueva versin del mismo, entonces la evidencia de esas accionas
correctivas es la nueva versin del plan; si las acciones correctivas generan nuevos riesgos
o modifican las caractersticas o las acciones de mitigacin de un riesgo existente, la
evidencia de esta accin correctiva es la modificacin realizada en la tabla de riesgos; la
seccin de acciones abiertas de las actas de reunin de las revisiones peridicas del
proyecto tambin es una evidencia aceptable. Una muy buena prctica es crear una
herramienta de gestin de problemas para llevar la traza de cada problema relacionado con
PP/PMC.
ESI
33
ndice de contenidos

ESI
34
Medicin y Anlisis
El propsito de la Medicin y Anlisis (MA) es desarrollar y mantener una
capacidad de medicin que sea utilizada para apoyar las necesidades de
informacin de gestin.
ALS
SG1: Alinear las Actividades de Medicin y Anlisis

Los objetivos y actividades de medicin se alinean con los
objetivos y necesidades de informacin identificados.
SG2: Proporcionar los Resultados de Mediciones
Se proporcionan los resultados de las mediciones, reflejo de
los objetivos y necesidades de informacin identificados.
ESI
35
SG1 : Alinear las actividades de medicin y anlisis
Las actividades y objetivos de medicin se alinean con los objetivos

y necesidades de informacin identificados.

SP1.1 : Establecer objetivos de medicin
SP1.2 : Especificar mtricas
SP1.3 : Especificar los procedimientos de recogida de datos y
almacenamiento
SP1.4 : Especificar los procedimientos de anlisis
ESI
36
SG2 : Proporcionar los resultados de medicin
Se proporcionan los resultados de medicin, los cuales reflejan los

objetivos y necesidades de informacin identificados.
SP2.1 : Recoger los datos de medicin

SP2.2 : Analizar los datos de medicin
SP2.3 : Almacenar los datos y los resultados
SP2.4 : Comunicar los resultados
ESI
37
Hallazgos Obligatorios MA
Alineamiento entre las mtricas y las necesidades de la organizacin y/o los

objetivos de negocio de la organizacin
Es necesario una representacin explcita de esta relacin. Generalmente las compaas

aplican alguna metodologa para establecer este alineamiento como el Goal Question
Metric (GQM) o el Balanced Scorecard. Por norma general, los senior managers se
involucran en la definicin de esta relacin. Sera suficiente si la organizacin es capaz de
demostrar que lo que se est midiendo a nivel de proyecto est alineado directamente con
los objetivos de la organizacin.
Catlogo de Mtricas
Cualquier tipo de documento o base de datos que demuestre que las mtricas estn
definidas y son utilizadas en los proyectos. Se espera que todos los implicados en el
contexto de los proyectos y de la organizacin sea capaz de comprender el propsito de
cada una de las mtricas definidas. Se aceptan soluciones como los cuados de mando a
nivel de organizacin o a nivel de proyecto. Hay que recordar que el principal objetivo que
empuja a los proyecto a medir aquello que est bajo su control directo es contribuir a
alcanzar los objetivos de la organizacin, es por ello que se recomienda mantener un
cuadro de mando de proyecto.
ESI
38
Hallazgos Obligatorios MA
Definicin operativa de las mtricas
Para cada mtrica se espera encontrar su definicin operativa, que consiste en una
informacin completa de cmo obtener los datos, analizarlos, almacenarlos e informar de
los resultados, quin es el responsable y con qu frecuencia as como cundo los datos
deberan ser recogidos y analizados.
Resultados de la medida proporcionados por los proyectos
Cualquier tipo de documento u hoja de clculo con los resultados de las mtricas del
proyecto y las mtricas recogidas, analizadas y almacenadas de acuerdo con el
procedimiento definido. Si hay definido un cuadro de mando para el proyecto, este es el
hallazgo que se est buscando.
ESI
39
ndice de contenidos

ESI
40
Aseguramiento de la Calidad de Proceso y Producto

El propsito del Aseguramiento de la Calidad de Proceso y Producto (PPQA) es
proporcionar a la Direccin y al resto del personal una visin objetiva de los
procesos y los productos de trabajo asociados.
ALS
SG1: Evaluar Objetivamente Procesos y Productos de

trabajo
Se evala de forma objetiva que los procesos implantados y
los productos/servicios asociados se adhieren a las
descripciones de proceso, estndares y procedimientos
aplicables.
SG2: Proporcionar Visibilidad Objetiva
Las no conformidades son supervisadas y comunicadas con
objetividad, asegurando su resolucin.
ESI
41
SG1 : Evaluar objetivamente los procesos y productos de

trabajo
Se evala de forma objetiva que los procesos implantados y los

productos/servicios asociados se adhieren a las descripciones de
proceso, estndares y procedimientos aplicables.

SP1.1 : Evaluar objetivamente los procesos
SP1.2 : Evaluar objetivamente los productos de trabajo y los servicios
ESI
42
SG2 : Proporcionar una percepcin objetiva
Se da seguimiento objetivo y se comunican las no-conformidades, y

se asegura su resolucin.

SP2.1 : Comunicar y asegurar la resolucin de las no-conformidades
SP2.2 : Establecer registros
ESI
43
Hallazgos Obligatorios PPQA
Evaluacin objetiva de los procesos
Evaluacin objetiva de los productos de trabajo
Los criterios para la seleccin de los proyectos deben estar claramente definidos, as como
los procesos que debern ser evaluados. Deberan determinarse los tipos de auditoras a
realizar para cada tipo de proyecto y en las diferentes fases del mismo, no slo al final.
Cada auditora debe estar documentada con un informe que contenga los resultados de la
evaluacin y las no-conformidades identificadas.
Debe documentarse la seleccin de los productos de trabajo a ser evaluados. La evaluacin

de los productos de trabajo es una revisin relativa a la adherencia de estos a las
definiciones, procedimientos plantillas y/o estndares (por ej. estndares de programacin).
Los productos de trabajo debern ser evaluados antes de su entrega al cliente.
Gestin de las no-conformidades
La lista de no conformidades deber estar documentada y ser gestionada por el grupo de

aseguramiento de la calidad para asegurar su resolucin. Cada no-conformidad registrada
incluir su descripcin, responsable y fecha de cierre para su resolucin. Debera de haber
evidencia de mecanismos de escalado en aquellos casos en los que la no-conformidad no
pueda ser resuelta dentro del mbito del proyecto.
ESI
44
Hallazgos Obligatorios PPQA
Registros
Institucionalizacin del proceso
Las auditoras, los informes, las no-conformidades, las acciones correctivas y los informes
de tendencia de la calidad deben quedar registrados. Los resultados y el estado de las
actividades de calidad deben ser comunicados regularmente a los stakeholders relevantes.
Al objeto de garantizar el empleo de los mismos criterios por parte de los evaluadores,
deberan definirse check-list para cada proceso producto y fase del proyecto a ser
evaluada. Adems, la independencia de los auditores debe garantizarse seleccionando
evaluadores externos al proyecto, proceso u organizacin de acuerdo con los casos.
Plan de aseguramiento de la calidad
El plan de auditoras deber ser elaborado peridicamente por el grupo de aseguramiento

de la calidad para determinar la cantidad de recursos y las posibles fechas de ejecucin. El
plan deber ser actualizado con los proyectos especficos y las fechas reales de ejecucin.
Por otra parte, todos los proyectos deberan incluir en sus planes evidencias de las
actividades de aseguramiento de la calidad a realizar dentro de los mismos.
ESI
45
ndice de contenidos

ESI
46
Gestin de la Configuracin
El propsito de la Gestin de la Configuracin (CM) es establecer y mantener la
integridad de los productos de trabajo utilizando la identificacin, control,
contabilidad de estado y auditoras de la configuracin.
ALS
SG1: Establecer lneas base

Se establecen lneas base de los productos de trabajo
identificados.
SG2: Dar seguimiento y Controlar Cambios
Se da seguimiento y se controlan los cambios a los productos
de trabajo puestos bajo gestin de la configuracin.
SG3: Establecer Integridad
Se establece y mantiene la integridad de las lneas base.
ESI
47
SG1 : Establecer lneas base
Se establecen lneas base de los productos de trabajo identificados.

SP1.1 : Identificar los elementos de configuracin
SP1.2 : Establecer un sistema de gestin de la configuracin
SP1.3 : Crear o liberar lneas base
ESI
48
SG2 : Dar seguimiento y controlar los cambios
Se da seguimiento y se controlan los cambios a los productos de

trabajo puestos bajo gestin de la configuracin.

SP2.1 : Dar seguimiento a las peticiones de cambio
SP2.2 : Controlar los elementos de configuracin
ESI
49
SG3 : Establecer la integridad
Se establece y mantiene la integridad de las lneas base.

SP3.1 : Establecer registros de la gestin de la configuracin
SP3.2 : Ejecutar auditoras de configuracin
ESI
50
Hallazgos Obligatorios CM
Elementos de configuracin identificados para el proyecto
Sistema de configuracin establecido
Cualquier tipo de documentacin (a nivel de proyecto u organizacional) que presente qu

productos estarn bajo control de configuracin. Estos podrn ser documentos del
proyecto, software, productos de trabajo (cdigo fuente, documentacin de diseo, etc.) y
productos de trabajo de sistemas (componentes hardware).
La estructura fsica y lgica definida para el almacenamiento y recuperacin de los

elementos de configuracin. Tpicamente se refiere a repositorios en herramientas o
entornos de red.
Lneas base de proyecto
Tanto lneas base normales como lneas base para las peticiones de cambio. Se espera
encontrar algn tipo de documentacin para la lnea base, como puede ser: notas de
entrega/liberacin de versin, propsito de la lnea base, tipo de la lnea base, responsable
de generacin, situacin respecto de la auditora, etc.
ESI
51
Hallazgos Obligatorios CM
Control de la evolucin de los elementos de configuracin
Para cada elemento de configuracin, debe encontrarse disponible la historia de su

evolucin, la razn para crear una nueva versin. Tpicamente est relacionada con la tabla
de historia de cambios en la documentacin o con los procedimientos de check-in checkout cuando se estn utilizando herramientas.
Resultados de las auditoras a la configuracin
Cualquier tipo de documentacin que refleje que las lneas base han sido auditadas y el
resultado de cada tema analizado. Para este tipo de auditoras se pueden utilizar reglas
similares que las aplicadas en las auditoras de aseguramiento de la calidad, como los
procedimientos para manejar las no-conformidades. Tambin se espera encontrar check-list
como elemento de partida para realizar la auditora a la configuracin.
ESI
52
ndice de contenidos

ESI
53
Gestin de Acuerdos con Proveedores

El propsito de la Gestin de Acuerdos con Proveedores (SAM) es gestionar la
adquisicin de productos de proveedores.
ALS
SG1: Establecer Acuerdos con Proveedores

Se establecen y mantienen acuerdos con proveedores.
SG2: Satisfacer los Acuerdos con Proveedores
Los acuerdos con proveedores son satisfechos por ambas
partes, el proyecto y el proveedor.
ESI
54
SG1 : Establecer acuerdos con proveedores
Se establecen y actualizan los acuerdos con los proveedores.
Las siguientes prcticas estn asociadas a esta meta:

SP1.1 : Determinar tipo de adquisicin
SP1.2 : Seleccionar proveedor
SP1.3 : Establecer acuerdos con proveedor
ESI
55
SG2 : Satisfacer los acuerdos con proveedores
Los acuerdos con los proveedores se cumplen por ambas partes,

proyecto y proveedor.
SP2.1 : Ejecutar acuerdo con proveedor

SP2.2 : Dar seguimiento al proceso del proveedor
SP2.3 : Evaluar los productos del proveedor
SP2.4 : Aceptacin del producto
SP2.5 : Integracin del producto
ESI
56
Hallazgos Obligatorios SAM
Catlogo de proveedores
Acuerdo formal con el proveedor
Cualquier tipo de documento, base de datos o lista que represente a los proveedores
aprobados de la organizacin. Si la organizacin no dispone de este tipo de catlogo, debe
poder probar que antes de la firma del acuerdo con el proveedor, se ha realizado un
proceso de seleccin
Es el acuerdo legal entre la organizacin y el proveedor. Este acuerdo formal puede ser un
contrato, una licencia (productos COTS), un acuerdo de nivel de servicio, etc. Deber
ponerse especial nfasis en los aspectos relacionados con la transicin del producto para
garantizar la continuidad del soporte al producto en casos extremos.
Informes de monitorizacin de los proveedores
Documentos (informes, actas de reunin, etc.) que muestren que los trabajos a realizar por
los proveedores son controlados y gestionados. Dependiendo del tipo de contrato el tipo de
monitorizacin puede cambiar; no es lo mismo gestionar contratos llave en mano que
bolsas de horas.
ESI
57
Hallazgos Obligatorios SAM
Informes de evaluacin de los productos suministrados
Documentos que reflejen las actividades llevadas a cabo para evaluar el producto
suministrados por el proveedor y si es aplicable el periodo de transicin establecido. Este
informe debera representar la aceptacin formal del producto hecha por la organizacin
que ha subcontratado.
Plan de proyecto documentado
Si SAM es aplicable a un proyecto, el plan de proyecto deber reflejar los hitos importantes
o tareas subcontratadas mostrando que dichas actividades son monitorizadas y controladas
ESI
58
Gracias por vuestra atencin
ESI
59

Formación Cmmi-Dev l2

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Formación Cmmi-Dev l2

Uploaded by

Copyright:

Available Formats

Interpretando el modelo CMMI-DEV

reas de proceso REQM, PP, PMC, MA, PPQA, CM, SAM

Capability Maturity Model and CMMI are registered

Visin general del modelo CMMI-DEV

Visin general del modelo CMMI-DEV

Capability Maturity Model Integration (CMMI) es un modelo para la

Las mejores prcticas CMMI se publican en los documentos llamados

La versin actual de CMMI es la versin 1.3. Hay tres constelaciones

CMMI para el Desarrollo (CMMI-DEV o CMMI for Development). En l se tratan procesos

Los niveles de madurez

Foco en la mejora continua

El proceso se controla cuantitativamente

Proceso definido para la

Proceso definido caracterizado

Tipos de metas y prcticas

Nivel de Madurez 2: Gestionado

Gestin de proyectos disciplinada

reas de Proceso en el Nivel de Madurez 2

Visin general modelo CMMI-DEV v1.2

Rendimiento de Procesos Organizativos (OPP)

Nivel madurez 4 OPP, QPM1

Nivel madurez 3 RD, TS, PI,

VER, VAL, OPF, OPD, OT, IPM,

Nivel madurez 2 REQM, PP,

PMC, MA, PPQA, CM, SAM

Gestin de Requisitos (REQM)

Desarrollo de requisitos (RD)

Nivel madurez 5 OID, CAR

Visin general del modelo CMMI-DEV

SG1: Gestionar Requisitos

SG1 : Gestionar Requisitos

Se gestionan los requisitos y se identifican las inconsistencias con

Las siguientes prcticas estn asociadas a esta meta :

SP1.1 : Entender los requisitos

GG2: Institucionalizar un proceso gestionado

GP2.1 : Establecer una poltica en la organizacin

Hallazgos Obligatorios REQM

Un conjunto documentado de requisitos

Un conjunto documentado de requisitos analizados (Documento requisitos)

Un conjunto documentado de cambios a los requisitos

Un cambio es una modificacin, cambio o eliminacin de un requisito. Todos los cambios

Hallazgos Obligatorios REQM

Evidencias de compromiso con los requisitos

Trazabilidad entre los requisitos

La trazabilidad ayuda a realizar anlisis de impacto a los cambios a los requisitos, en

Visin general del modelo CMMI-DEV

SG1: Realizar estimaciones

SG1 : Realizar estimaciones

Se establecen y mantienen estimaciones de los parmetros de

Las siguientes prcticas estn asociadas a esta meta :

SG2 : Desarrollar un plan de proyecto

Se establece y mantiene un plan de proyecto como base para su

Las siguientes prcticas estn asociadas a esta meta :

SP2.1 : Establecer el presupuesto y el calendario

SG3 : Obtener el compromiso con el plan

Se establecen y mantienen los compromisos con el plan de

Las siguientes prcticas estn asociadas a esta meta :

WBS documentada del proyecto

Estimaciones documentadas del tamao y la complejidad

Las estimaciones de esfuerzo deben basarse en estimaciones de tamao y complejidad.

Estimaciones documentadas de esfuerzo y coste

Las estimaciones de esfuerzo debern basarse en mtodos sistemticos (datos histricos

Calendario documentado del proyecto

En el plan de proyecto deber documentarse tanto los recursos (personas, equipos,