Guia de Evaluación Para El Nivel de Madurez 2 de Cmmi

GUIA DE EVALUACIÓN PARA EL NIVEL DE MADUREZ 2 DE CMMI Fecha: 02/12/2014

GUIA DE EVALUACIÓN PARA EL NIVEL DE MADUREZ 2 DE CMMI Página 1 de 35

GUIA DE EVALUACIÓN PARA EL NIVEL DE

MADUREZ 2 DE CMMI

Kelly Ramírez Lara

Diego Obando

Javier Jaramillo

Carlos cuero



TABLA DE CONTENIDO

INTRODUCCIÓN .......................................................................................................................... 4

OBJETIVOS .................................................................................................................................. 5

Generales .................................................................................................................................. 5

Específicos ................................................................................................................................ 5

ESTRUCTURA DE UN ÁREA DE PROCESO SEGÚN CMMI ...................................................... 6

ÁREA DE PROCESO ................................................................................................................ 6

Componentes requeridos ....................................................................................................... 7

Componentes esperados ....................................................................................................... 7

Componentes informativos .................................................................................................... 7

ESTRUCTURA DE ÁREA DE PROCESO ................................................................................. 8

Declaración del propósito ....................................................................................................... 8

Notas introductorias ............................................................................................................... 8

Áreas de proceso relacionadas .............................................................................................. 8

Metas específicas .................................................................................................................. 8

Metas genéricas ..................................................................................................................... 8

Resúmenes de metas y prácticas específicas ....................................................................... 9

Prácticas específicas ............................................................................................................. 9

Ejemplo de productos de trabajo ............................................................................................ 9

Sub prácticas ......................................................................................................................... 9

Prácticas genéricas .............................................................................................................. 10

Elaboraciones de la práctica genérica ................................................................................. 10

ÁREAS DE PROCESO QUE SE INVOLUCRAN EN EL NIVEL 2 DE CMMI .............................. 11

GESTIÓN DE CONFIGURACIÓN (CM) .................................................................................. 11

MEDICIÓN Y ANÁLISIS (MA).................................................................................................. 12

MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC) ................................................... 12



PLANIFICACIÓN DEL PROYECTO (PP) ................................................................................ 13

ASEGURAMIENTO DE LA CALIDAD DEL PROCESO Y DEL PRODUCTO (PPQA) ............. 14

GESTIÓN DE REQUISITOS (REQM) ..................................................................................... 15

GESTIÓN DE ACUERDOS CON PROVEEDORES (SAM) ..................................................... 16

MATRIZ PIIBD............................................................................................................................. 18

INSTITUCIONALIZAR UN PROCESO GESTIONADO ........................................................... 20

GESTIÓN DE CONFIGURACIÓN (CM) .................................................................................. 22

MEDICIÓN Y ANÁLISIS (MA).................................................................................................. 24

MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC) ................................................... 26

PLANIFICACIÓN DEL PROYECTO (PP) ................................................................................ 28

ASEGURAMIENTO DE LA CALIDAD DEL PROCESO Y DEL PRODUCTO (PPQA) ............. 30

GESTIÓN DE REQUISITOS (REQM) ..................................................................................... 31

GESTIÓN DE ACUERDOS CON PROVEEDORES (SAM) ..................................................... 32

CONSTRUIR UNA PROPUESTA A LA LUZ DEL MODELO CMMI, PARA CALIFICAR LAS

ÁREAS DE PROCESO TENIENDO EN CUENTA EL ESTADO DE LOS PII .............................. 33

FASES DE LA EVALUACIÓN.................................................................................................. 34

Preparación y planificación .................................................................................................. 34

Readiness-review ................................................................................................................. 34

Ejecución de la auditoría y comunicación de resultados ...................................................... 34



INTRODUCCIÓN

El modelo CMMI se usa para evaluar el nivel de madurez de una compañía en términos

de desarrollo de software. Es una versión más amplia que se basa en CMM, adoptando

la mayoría de sus conceptos y ofreciendo índices de referencia de las mejores

prácticas para el desarrollo de software.

Dependiendo la implementación de los procesos de calidad de las organizaciones,

CMMI determina cinco niveles de madurez: Inmadura, básica, gestionada, establecida,

predecible y optimizada. En el nivel 2 (gestionada) los procesos se llevan a cabo, se

planifican, revisan y se evalúan para comprobar que cumplen los requisitos, es decir, el

proyecto es gestionado y controlado durante el desarrollo del mismo; se puede saber el

estado del proyecto en todo momento.

Que una organización haya alcanzado nivel 2 de CMMI implica, en síntesis, que aplica

procesos básicos de gestión de los proyectos (costo, calendario, funcionalidad). Estos

procesos hacen que se pueda repetir con éxito proyectos futuros de características

similares.



OBJETIVOS

GENERALES

Construir una base para ayudar a certificar la madurez de las empresas desarrolladoras

de software en los procesos que requiere CMMI nivel 2, donde la generación de

evidencia para el control de procesos a través del seguimiento de las auditorías y del

registro y tratamiento de las no conformidades son requerimientos esenciales para el

área de aseguramiento de la calidad de los procesos y productos (PPQA).

.

ESPECÍFICOS

Entender y usar el modelo CMMI.

Conocer la estructura de un área de proceso en 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.

Evidenciar los beneficios que conlleva la aplicación de los modelos de calidad en las

empresas de desarrollo de software.

Comprender que con el nivel 2 de CMMI se garantiza una gestión de los requisitos y que

los procesos deber estar planeados, ejecutados, medidos y controlados.



ESTRUCTURA DE UN ÁREA DE PROCESO SEGÚN CMMI

ÁREA DE PROCESO

` Un área de proceso es un grupo de prácticas relacionadas dentro de un área que,

cuando se implementan simultáneamente, satisface un conjunto de metas

consideradas importantes para mejorar esa área.

Un área de proceso comparte metas, propósitos y prácticas las cuales satisfacen los

objetivos requeridos.

Figura 1: Componente modelo CMMI



Antes de empezar a describir cada ítem de la estructura de un área de proceso

debemos tener en cuenta que existen 3 categorías de componentes requeridos,

esperados e informativos, según CMMI se definen como:

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.

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.

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.



ESTRUCTURA DE ÁREA DE PROCESO

Declaración del propósito

Una declaración del propósito describe la finalidad del área de proceso y es un

componente informativo.

Notas introductorias

Describe los conceptos principales cubiertos por el área de proceso y es un

componente informativo.

Á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.

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.

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.

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.

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.

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.

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.



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.

Una práctica genérica es un componente esperado del modelo.

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. Una elaboración de práctica genérica es un

componente informativo del modelo.



ÁREAS DE PROCESO QUE SE INVOLUCRAN EN EL NIVEL 2 DE CMMI

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.

Algunos ejemplos de recursos son:

Herramientas de gestión de configuración.

Herramientas de gestión de datos.

Herramientas de archivo y reproducción.

Sistemas de gestión de bases de datos.



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


Paquetes estadísticos.

Paquetes que dan soporte a la recogida de datos a través de la red.

MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC)

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.

Un plan de proyecto documentado es la base para la monitorización de las actividades,

la comunicación del estado y la toma de acciones correctivas. El progreso se determina

principalmente comparando los atributos de los productos de trabajo y de las tareas, el



esfuerzo, el coste y el calendario reales, con el plan en los hitos o niveles de control

establecidos en el calendario del proyecto o en la estructura de descomposición del

trabajo (WBS). Una visibilidad adecuada del progreso permite llevar a cabo las

acciones correctivas de manera oportuna cuando el rendimiento se desvíe

significativamente del plan. Una desviación es significativa si, cuando se deja sin

resolver, impide al proyecto cumplir con sus objetivos.

El término “plan de proyecto”, se utiliza a lo largo de esta área de proceso para referirse

al plan global para controlar el proyecto.

Cuando el estado real se desvíe significativamente de los valores esperados, se

llevarán a cabo acciones correctivas según proceda. Estas acciones pueden requerir

una re planificación, que puede incluir la modificación del plan original, el

establecimiento de nuevos acuerdos o la inclusión de actividades adicionales de

mitigación en el plan actual.


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.

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.

Una de las claves para gestionar eficazmente un proyecto es la planificación 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.

La planificación incluye la estimación de los atributos de los productos de trabajo y de

las tareas, la determinación de los recursos necesarios, la negociación de los

compromisos, la elaboración de un calendario, y la identificación y el análisis de los

riesgos del proyecto. Para establecer el plan de proyecto, puede ser necesario realizar

iteraciones de estas actividades. El plan de proyecto proporciona la base para realizar y

controlar las actividades del proyecto que abordan los compromisos con el cliente del

proyecto (véase la definición de “proyecto” en el glosario).

La experiencia particular en planificación de proyectos puede incluir:

Estimadores experimentados.

Planificadores.

Expertos técnicos en áreas aplicables (p. ej., dominio del producto, tecnología).

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.



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.

En particular, si se implementa el área de proceso Desarrollo de

Requisitos, sus procesos generarán requisitos de producto y de componente de

producto que también serán gestionados por los procesos de gestión de requisitos.

En todas las áreas de proceso, cuando se utilizan los términos “producto” y

“componente de producto”, sus significados previstos también incluyen los servicios, los

sistemas de servicio y sus componentes.

Cuando las áreas de proceso Gestión de Requisitos, Desarrollo de Requisitos y

Solución Técnica están implementadas, sus procesos asociados pueden estar

estrechamente relacionados y realizarse de manera concurrente.


Herramientas para el seguimiento de los requisitos.

Herramientas de trazabilidad.



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.

En las áreas de proceso, donde se utilizan los términos “producto” y “componente de

producto”, sus significados también abarcan servicios, sistemas de servicio y sus

componentes.

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.




Herramientas de seguimiento de requisitos.

Programas para gestión de proyectos y calendarios.



MATRIZ PIIBD

Para comprender qué son los indicadores de implementación de la práctica es

necesario conocer primero la estructura de un área de proceso.

Las áreas de proceso están compuestas de unas metas, que deben ser alcanzadas

para cumplir con el área de proceso.

Se distinguen dos tipos de metas, las metas genéricas (GG), que son comunes a todas

las áreas de proceso, y las metas específicas (SG), que son definidas por cada área de

proceso. Estas metas se dividen a su vez en prácticas, que son actividades que se

consideran importantes para alcanzar el objetivo del área de proceso.

Se distinguen también dos tipos de prácticas, las prácticas genéricas (GP), que son

comunes a todas las áreas de proceso, y las prácticas específicas (SP), que son

propias de cada área de proceso.



Figura 2: Metas de áreas de proceso

Cuando se está realizando una auditoría CMMI, es necesario comprobar que todas las

metas de cada área de proceso definida en el nivel de madurez a evaluar han sido

alcanzadas. Para ello, se comprueba que todas las prácticas definidas de cada meta

han sido satisfechas. Si esto es así, la realización de cada práctica dejará algún tipo de

“rastro” (por ejemplo un documento, un acta de reunión, un email, etc.). A estos

“rastros” se les conoce como indicadores de implementación de la práctica (Practice

Implementation Indicators o PII), que son, por lo tanto, el resultado de la

implementación de una práctica y que sirven para comprobar que esta implementación

se ha realizado correctamente. Estos indicadores de implementación es lo que busca el

auditor durante la auditoría para comprobar que se está realizando cada una de las

prácticas y que se alcanzan, por lo tanto, cada una de las metas del área de proceso

correspondiente.



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

responsabilidades respecto al

proceso.

Actas donde se asignan los

integrantes del proyecto y se

explican sus

responsabilidades.

Listas de asistencia

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.

Estándares, procedimientos y

métodos para la capacitación de

todo el personal asignado a los

proyectos.

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.

Archivos de Logs



Control sobre la integración

de las partes del software en

un solo producto de

software.

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

controlar los

procesos

Evaluaciones objetivas del proceso

planificadas y ejecutadas.

Evaluaciones objetivas de producto

de trabajo planificadas y

ejecutadas.

Calendario de las evaluaciones

objetivas.

Acciones correctivas,

Acciones preventivas y

Acciones de mejora

asociadas al desempeño de

los procesos y proyectos.

Se comunican los resultados

a todos los involucrados.

Registro de las

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 auditoria

Listas de chequeo de

auditoria

Informes de auditoria

Listas de asistencia a la

auditoria

Actas de auditorias

Informes de auditoria

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.



GESTIÓN DE CONFIGURACIÓN (CM)


SG 1. Establecer líneas base.

SP 1.1.

Identificar cada

componente

susceptible de

ser versionado.

Documento o tool Donde sí

identifican los Elementos de

Configuración de las 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

Tiempo dedicado a la elaboración, horas,

actas, etc Registro de Horas

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.

SG 2. Seguimiento y control de cambios.

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, identificando errores

o conflictos. No conformidades

identificadas durante las

auditorías internas y externas.

Logs de ejecuciones del

servidor de integración continua.

Registros de auditoría interna o externa

Registros de Ejecuciones del Servidor de

Integración Continua.

SG 3. Establecer la integridad



SP 3.1.

Establecer y

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

realización de la auditoría.



MEDICIÓN Y ANÁLISIS (MA)


SG 1. Alinear actividades de medición y análisis con los objetivos y las necesidades de información

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 de 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

SG 2. Proporcionar resultados de las mediciones

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



MONITORIZACIÓN Y CONTROL DEL PROYECTO (PMC)


SG 1. Monitorizar el proyecto de acuerdo con el Plan

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.).

Identificación de desviaciones en

el proyecto.

Registro de la revisión de las

horas imputadas al proyecto.

Registro de

horas


compromisos

Actas de reunión de seguimiento,

informes de avance, de

cumplimiento de hitos, etc.

Horas programadas al

seguimiento del proyecto


riesgos.

Histórico de cambios en 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 almacenados en el

lugar correcto).

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.

SP 1.5. Monitorizar de

la involucración de

los interesados.

Actas de reunión de entrega de

hitos intermedios.

Correos o notificaciones entre los

implicados.

SP 1.6. Realizar revisiones

del progreso del

proyecto (avance del

mismo).

Informes de avance del

seguimiento.

Actas de reunión de 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.

Actas de reunión de entrega

intermedia, reuniones intermedias

de chequeo con el cliente.

Acta de reunión de final de un

Sprint

Histórico de entregables.

Histórico de incidencias.

Riesgos del proyecto revisados

durante la realización del hito.



SG 2. Administrar acciones correctivas a tomar

SP 2.1. Analizar los

problemas.

Incidencias registradas y

analizadas

Peticiones de cambio

asociadas.

Planificación modificada

incluyendo las incidencia y su

estimación

Peticiones

de cambio

SP 2.2. Tomar acciones

correctivas.

Documento o registro de

acciones correctivas.

Incidencias resueltas.

Histórico de cambios de estado

de las incidencias

Acciones

correctivas

SP 2.3. Administrar las

acciones correctivas

Histórico de acciones

correctivas, participantes,

planes derivados, etc.

Acta de reunión al final del hito en

la que se incluye la revisión de las

incidencias y las acciones

correctivas asociadas.

Planes de

mejora

asociados



PLANIFICACIÓN DEL PROYECTO (PP)


SG 1. Establecer estimaciones

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 el método usado. Hoja de costes para el proyecto y el procedimiento de cálculo. Definición de recursos necesarios (memoria, capacidad de red, etc.) para la realización del proyecto..

Horas dedicadas a la tarea de estimación. Herramienta de cálculo de esfuerzo y coste completada

SG 2. Desarrollar el plan de proyecto

SP 2.1. Establecer el presupuesto y calendario del proyecto

Sección de presupuesto del documento del plan de Proyecto. Diagrama de PERT en el que se identifican las distintas tareas y sus dependencias.

Horas asignadas a la tarea de elaboración del presupuesto y calendario. 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, entendiendo por datos cualquier documentación requerida para soportar un programa en cualquiera de sus

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.



facetas (administración, control de cambios, logística, etc)

SP 2.4. Definir un plan para administrar los recursos, entendiendo por recurso una máquina, materiales, métodos, etc.

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

SP 2.5. Definir un plan para administrar los 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.

SP 2.6. Definir un plan para involucrar a los interesados.

Listado de los participantes del proyecto y rol que juegan en el mismo. Comunicación formal a las personas que participarán en el proyecto (cliente, desarrolladores, equipo de pruebas, etc.). Plan de comunicación y relaciones entre los participantes.

Acta de inicio del proyecto en la que participan tanto el cliente como los principales involucrados en el proyecto y se explica el plan de comunicación.

SP 2.7. Establecer el Plan General del proyecto.

Plan de proyecto Horas dedicadas a la tarea de planificación. Plantilla de plan de proyecto.

SG 3. Obtener un compromiso para realizar el plan

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 (correo, acta, etc.).

SP 3.2. Reconciliar el trabajo y el nivel de los recursos.

Presupuestos renegociados. Control de la asignación y capacidad de los recursos. Reestimación de las tareas de los implicados que tengan una dedicación que no sea aceptable.

Revisión en herramienta de gestión de personal y control de horas, así como el ajuste de recursos y tareas

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.



ASEGURAMIENTO DE LA CALIDAD DEL PROCESO Y DEL PRODUCTO (PPQA)


SG 1. Evaluar objetivamente procesos y productos de trabajo

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. Informe de auditoría interna o externa. No conformidades

detectadas durante la auditoría. .

Actas de reunión de evaluación de los procesos.

Horas registradas a las actividades de las auditorías.

Registro de auditoría

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.

SG 2. Proporcionar comunicación interna objetiva

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

Acciones correctivas asociadas a las no conformidades

Registro de acciones correctivas

SP 2.2. Establecer y 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 auditoria



GESTIÓN DE REQUISITOS (REQM)


SG 1 Gestionar los requerimientos

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

Peticiones de cambio asociadas con requisitos.

Requerimientos versionados. Tareas para cada petición de

cambio: trazabilidad de la petición de cambio con las tareas

Histórico de requisitos cuyo estado haya pasado a “abierto”

tras haber sido “cerrado” Estimación de las tareas

asociadas al cambio en un requisito.

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

Acciones correctivas asociadas a las inconsistencias encontradas entre el proyecto y los requisitos.

Acciones correctivas



GESTIÓN DE ACUERDOS CON PROVEEDORES (SAM)


SG1: Establecer los acuerdos con Proveedores

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. 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

SG 2. Satisfacer los acuerdos del 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 la 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 productos

Planes de transición y despliegue, gestión del cambio, paso a producción, a

pre-producción, etc. Informes de formación sobre los nuevos productos.

Registro de horas de cada empleado que se involucró en

actividades de formación relacionadas con el producto.

Informe de incidencias durante el despliegue



CONSTRUIR UNA PROPUESTA A LA LUZ DEL MODELO CMMI, PARA

CALIFICAR LAS ÁREAS DE PROCESO TENIENDO EN CUENTA EL ESTADO

DE LOS PII

La evaluación que se pretende realizar estará enfocada en la verificación de cada uno

de los aspectos anteriormente mencionados. 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, revisa 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.

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. Para comprobar si se cumplen, se

utilizará la escala que determina si se han implementado completamente, parcialmente

o no se han implementado. La escala puede verse en la siguiente tabla:

Calificación Descripción

Fully Implemented (FI) Artefactos directos presentes y adecuados Artefactos indirectos y/o Afirmaciones No se han notado debilidades

En gran parte Implementado (LI)

Artefactos directos presentes y adecuados Artefactos indirectos y/o Afirmaciones Se han notado una o más debilidades

Parcialmente Implementado (PI)

Artefactos directos no encontrados o inadecuados Artefactos indirectos y/o afirmaciones indican que parte de la practica ha sido implementada Se han notado una o más debilidades ó Artefactos directos presentes y adecuados No se encuentra otra evidencia que soporte la práctica Se han encontrado una o más debilidades

No Implementado (NI) Artefactos directos no encontrados yo inadecuados No se encuentra otra evidencia que soporte la práctica Se han notado una o más debilidades



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.

Readiness-review

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 auditoria, el quipo 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.

Todo lo anteriormente definido para hacer la evaluación a la empresa permitirá hacer

seguimiento periódico a cada uno de los procesos que deben ser llevados a cabo,

enfocados a la calidad del software permitiendo así una mejora continua.

Guia de Evaluación Para El Nivel de Madurez 2 de Cmmi

Documents

Transcript of Guia de Evaluación Para El Nivel de Madurez 2 de Cmmi