universidad nacional mayor de san...

UNIVERSIDAD NACIONAL MAYOR DE SAN MARCOS Fundada en 1551

FACULTAD DE CIENCIAS MATEMATICAS

E.A.P. DECOMPUTACION

“PROPUESTA PARA IMPLANTAR CMMI EN UNA EMPRESA CON MULTIPLES UNIDADES DESARROLLADORAS DE SOFTWARE”

MONOGRAFÍA

Para optar el Título Profesional de :

LICENCIADO EN COMPUTACION

AUTOR

NANCY ELIZABETH CONCHA HUACOTO

LIMA – PERÚ 2005

INDICE

I.INTRODUCCIÓN

II.FUNDAMENTACIÓN TEÓRICA 2.1 Fundamentación genérica

2.1.1 Conceptos de calidad 2.1.2 Qué es un Proceso? 2.1.3 Qué es un modelo de Procesos? 2.1.4 Qué es CMM? 2.1.5 Madurez vs. Inmadurez 2.1.6 Qué es CMMI? 2.1.7 Evolución de madurez de los procesos CMMI 2.1.8 Antecedentes del CMMI 2.1.9 Necesita su Organización CMMI? 2.1.10 Componentes del modelo CMMI

2.2 Fundamentación específica 2.2.1 CMM vs. CMMI – Diferencias y Semejanzas 2.2.2 Por qué se aplica CMMI? 2.2.3 Procesos 2.2.4 Objetivos del presente estudio

III.PLANTEAMIENTO DEL PROBLEMA 3.1 Situación actual 3.2 Antecedentes del estudio 3.3 Determinación del problema 3.4 Justificación

IV. METODOLOGÍA DE IDENTIFICACIÓN, TRANSFORMACIÓN E IMPLANTACIÓN – ITI

4.1 Descripción general de la metodología 4.2 Descripción detallada 4.3 Esquema de la metodología 4.4 Objetivos de la metodología

V.PROCESO DE IMPLANTACIÓN

5.1 Descripción general 5.1.1 Alcances del estudio

5.2 Descripción detallada 5.2.1 Levantamiento de requerimientos 5.2.2 Transformación 5.2.3 Implantación 5.2.4 Barreras para una implantación exitosa 5.2.5 Factores críticos de éxito

VI. CONCLUSIONES

VII. RECOMENDACIONES REFERENCIAS

ANEXOS

Anexo I – Glosario de términos Anexo II – Acrónimos Anexo III – Descripción detallada de PAs y evidencias de cumplimiento Anexo IV – Formatos

Propuesta para Implantar CMMI en una Empresa con Múltiples Unidades Desarrolladores de Softwre. Concha Huaroto, Nancy Elizabet.

Derechos reservados conforme a Ley

Elaboración y diseño en formato PDF por la Oficina General del Sistema de Bibliotecas y Biblioteca Central de la UNMSM

RESUMEN

El Modelo Integrado de Madurez de la Capacidad - CMMI se usa para mejorar la

calidad del desarrollo y mantenimiento de software, basado en las mejoras de los

procesos de la Organización.

En el presente estudio se evaluará y aplicará la metodología de Identificación,

Transformación e Implantación – ITI para transformar una Empresa con múltiples

Unidades Desarrolladoras de Software – UDSs a los procesos CMMI para que puedan

operar bajo un concepto de calidad estándar e integrado que originará que la

Organización produzca mejores productos. Así mismo implementar los estándares

CMMI en las Unidades Desarrolladoras previa customización de la Unidad sujeto de

estudio.

Se realiza una fundamentación teórica del modelo CMMI, se describe la metodología

de Identificación, Transformación e Implantación – ITI y se describe de una manera

práctica cómo una Unidad Desarrolladora de Software se transformó al modelo CMMI

utilizando la metodología ITI.

PALABRAS CLAVES: CMMI

MODELO INTEGRADO DE MADUREZ DE LA

CAPACIDAD

METODOLOGÍA DE TRANSFORMACIÓN




ABSTRACT Capability Maturity Model Integrated - CMMI is used to improve quality in

development and maintenance of software, based in improvement the Organization’s

Process.

In this study it will be evaluate and aplicate “ Identification, Transformation and

Implementation – ITI” methodology to transform an Enterprise with many Units

Developers of de Software – UDSs to the CMMI process to operate in a quality

standard an integrated concept in order to Organization make better products. In the

same way to customize and implement CMMI standars on a Developer Unit.

A theoric fundamentation of CMMI model will be make, describing “ Identification,

Transformation and Implementationt” methodology – ITI; and it will be also described

on a practical way how an Unit Developer of de Software – UDS became a CMMI

model using ITI methodology.

KEY WORDS: CMMI

CAPABILITY MATURITY MODEL INTEGRATED

TRANSFORMATION METODOLOGY




CAPÍTULO I

Introducción El modelo CMMI – Modelo Integrado de Madurez de la Capacidad surge a partir del

reconocimiento de las organizaciones, tanto del Departamento de Defensa de los EEUU

como de la industria en general, de que los componentes de los sis temas son con

frecuencia, una causa significativa de demoras, mayores costos e insatisfacción de

clientes.

El modelo CMMI define 5 niveles, mediante los cuales se describen los distintos grados

de madurez de una organización. Los requerimientos para satis facer cada nivel se

encuentran detallados en un conjunto de actividades que se agrupan en Áreas de

Procesos definidos para cada nivel. Para que una organización se encuentre en un nivel

determinado es necesario cumplir con todas las actividades definidas para ese nivel y

para los niveles anteriores.

EL CMMI se basa en el concepto de la evolución de la madurez de los procesos. Esto

implica un orden, por lo tanto el enfoque de CMMI apunta a desarrollar la madurez de

las Organizaciones de Desarrollo de Software en forma progresiva nivel a nivel.

Nivel 1 – Inicial: Procesos no predecibles y pobremente controlado

Nivel 2 – Repetible: Las tareas anteriormente exitosas pueden repetirse

Nivel 3 – Definido: Procesos bien definidos y entendidos

Nivel 4 – Administrado: Procesos medidos y controlados

Nivel 5 – Optimizado: Foco continuo en la mejora de procesos

El modelo CMMI aplica conceptos de gerencia de procesos y mejora de calidad al

desarrollo y mantenimiento de software, y describe los estados a través de los cuales las

organizaciones de software evolucionan a medida en que definen, implementan, miden,

controlan y mejoran sus procesos de software.




En el presente estudio se evaluará y aplicará la metodología de Identificación,

Transformación e Implantación – ITI para transformar una Empresa con múltiples

Unidades Desarrolladoras de Software – UDSs a los procesos CMMI para que puedan

operar bajo un concepto de calidad estándar e integrado que originará que la

Organización produzca mejores productos basados en las mejoras de sus procesos. Así

mismo implementar los estándares CMMI en las Unidades Desarrolladoras previa

customización de la Unidad sujeto de estudio.

En el capítulo I se realiza una fundamentación teórica definiendo conceptos del modelo

CMMI y otros conceptos relacionados, en el capítulo II se detalla el problema que tiene

la Empresa con relación al cumplimiento de sus objetivos de calidad en el desarrollo y

mantenimiento de los productos de software, en el capítulo III se describe la

metodología de Identificación, Transformación e Implantación – ITI que se usará para

transformar una Unidad Desarrolladora de Software a los estándares de calidad del

modelo CMMI, y en el capítulo IV se describirá de una manera práctica cómo una UDS

se transformó a los estándares de calidad CMMI utilizando la metodología ITI así como

las barreras que se encontró durante la transformación. En los anexos del presente

documento puede encontrarse en mayor detalle las prácticas requeridas para cumplir

con el modelo CMMI y ejemplos de formatos a utilizar.

La metodología ITI que aquí se describe está basada en la experiencia de haber

participado en la transformación de una Unidad Desarrolladora de Software - UDS, la

misma que en el presente estudio se nombra como UDS “1”. El mismo proceso puede

ser utilizado para transformar cualquier otras UDS.

No es objetivo del presente estudio la construcción de los procedimientos, guías,

formatos y herramientas, etc. que respondan al modelo definido.




CAPÍTULO II

Fundamentación teórica 2.1 Fundamentación genérica 2.1.1 Conceptos de calidad Conceptos de calidad según algunos pioneros de la calidad: Calidad es cero defectos haciendo las cosas correctamente desde el principio. Philip B.

Crosby

Calidad es aptitud para el uso. J.M. Jurán

Calidad es total liderazgo de la marca en sus resultados al satisfacer los requisitos del

cliente haciendo la primera vez bien lo que haya que hacer. Westhingouse

La calidad se refiere a la cantidad de atributo no apreciado contenida en cada unidad del

atributo no apreciado. Keith B. Leffler

Un software es de calidad si satisface un propósito específico y si sus partes también

son de alta calidad; sin embargo a pesar que la mayoría usamos el término “calidad” de

una forma que pensamos que tiene sentido, que es entendible para todos, descubriremos

que una definición útil de calidad no es fácil de desarrollar.

La calidad puede entenderse en dos niveles: El primer nivel de calidad, es producir

bienes o servicios cuyas características medibles satisfacen un conjunto de

especificaciones que están definidas numéricamente, y el segundo nivel de calidad de

productos y servicios es aquél que satisface las necesidades de los clientes para su uso o

consumo. En resumen el primer nive l significa trabajar con las especificaciones,

mientras que el segundo nivel significa satisfacer al cliente.

2.1.2 ¿Qué es un Proceso? Un proceso es un conjunto de prácticas que se ejecutan con un propósito determinado,

las cuales transforman entradas en salidas que son de valor para el cliente. El proceso

puede incluir herramientas, métodos, materiales y/o personas.




Proceso es uno de los 3 puntos de apalancamiento de la mejora del desempeño de una

Organización. Para mejorar el desempeño, se pueden cambiar los procesos, las

personas, la tecnología o una combinación de ellos.

2.1.3 ¿Qué es un modelo de procesos? Un modelo de procesos es un conjunto estructurado de elementos que describen

características de procesos efectivos y de calidad. Un modelo indica “Qué hacer”, no

“Cómo hacer”, ni “Quién lo hace”. Un modelo proporciona:

o Un punto donde comenzar

o El beneficio de las experiencias pasadas de la comunidad participante

o Un lenguaje común y una visión compartida

o Un marco para priorizar acciones

o Una forma de definir lo que significa “mejora” para la organización

Los procesos incluidos en el “modelo de procesos” son aquellos que la experiencia ha

demostrado que son efectivos.

2.1.4 ¿Qué es CMM?

CMM – Modelo de Madurez de la Capacidad es un MODELO desarrollado por el

Instituto de Ingeniería de Software – SEI de la Universidad Carnegie Mellon, basado en

las mejores prácticas actuales de desarrollo de software. CMM es un marco para la

mejora de procesos de software y para la evaluación de la madurez de las capacidades.

El modelo CMM aplica conceptos de gerencia de procesos, mejora de calidad al

desarrollo y mantenimiento de software, y describe los estados a través de los cuales las

organizaciones de software evolucionan a medida en que definen, implementan, miden,

controlan y mejoran sus procesos de software.




Dentro de la representación por estados, el modelo CMM aplica a la Organización

niveles de madurez mediante los cuales se mide el avance de los procesos de la

organización

Nivel de madurez Estados

1 Inicial

2 Administrado

3 Definido

4 Administrado cuantitativamente

5 Optimizado

Cuadro Nro II,1. Nivel de madurez según la representación por estados

2.1.5 Madurez vs Inmadurez

Organizaciones con procesos

inmaduros

Organizaciones con procesos maduros

Procesos improvisados por los gerentes y

desarrolladores

Procesos documentados

Cada uno posee sus propios procesos Procesos seguidos consistentemente

Procesos comprometidos en orden a

cumplir los costos y las fechas acordadas

El rendimiento de los procesos es medido,

seguido y entendido

Calidad difícil de predecir La calidad es predecible porque los

procesos están bajo control

Los procesos “viven” mientras viven los

desarrolladores

Los procesos “viven” por sí solos y son

mejorados continuamente

Las nuevas tecnologías corren riesgos de caer en desuso.

Las nuevas tecnologías son incorporadas

de una manera disciplinada.

Cuadro Nro. II,2. Comparación entre Madurez e Inmadurez




Gráfico Nro II,1. Efectos de mejora en madurez de los procesos 2.1.6 ¿Qué es CMMI? El Modelo Integrado de Madurez de la Capacidad - CMMI es un conjunto de

herramientas que ayudan a la Organización a mejorar sus procesos de desarrollo de

productos y servicios, adquisiciones y mantenimiento. El modelo CMMI ha

evolucionado el concepto del Modelo CMM establecido para la maduración de la

capacidad de Software, a un nivel que permite el crecimiento continuado y expansión

del concepto CMM para múltiples disciplinas, tales como SW-CMM, EIA/IS 731, IPD-

CMM y otros modelos de mejora de procesos.

Madurez de Procesos es un indicador del potencial de crecimiento en capacidad de los

procesos, Capacidad es el rango esperado a ser alcanzado por los procesos, y el

Rendimiento es el resultado actual alcanzado por el proceso.

“El Rendimiento de procesos pasados es un indicador de la Capacidad de los Procesos.

La Capacidad de Procesos es una predicción del rendimiento futuro de los procesos”.




De la misma manera que el modelo CMM, el modelo CMMI tiene una representación

por estados, que enfoca o mide la mejora de los procesos usando niveles de madurez.

2.1.7 Evolución de madurez de los procesos CMMI

Las Organizaciones en el camino hacia lograr la madurez de los procesos pasan por 5

niveles de maduración:

Nivel 1: Inicial Procesos impredecibles, pobremente controlados y reactivos.

El proceso de software se caracteriza como ad hoc y ocasionalmente caótico. Pocas

actividades están definidas y el éxito de los proyectos depende del esfuerzo individual.

Hay carencia de procedimientos formales, estimaciones de costos, planes del proyecto,

mecanismos de administración para asegurar que los procedimientos se siguen.

Nivel 2: Administrado. Procesos caracterizados en proyectos y acciones reactivas con

frecuencia.

Son establecidas las actividades básicas para la administración de proyectos de

software para el seguimiento de costos, programación y funcionalidad. El éxito está en

repetir prácticas que hicieron posible el éxito de proyectos anteriores, por lo tanto hay

fortalezas cuando se desarrollan procesos similares, y gran riesgo cuando se enfrentan

nuevos desafíos.

Las áreas de proceso de nivel 2 son:

o Administración de Requerimientos (RM)

o Planeamiento de Proyectos (PP)

o Monitoreo y Control de Proyectos (PMC)

o Administración de acuerdos con Proveedores (SAM)

o Aseguramiento de la Calidad de Productos y Procesos (PPQA)

o Administración de la Configuración (CM)

o Mediciones y Análisis (MA)




Nivel 3: Definido. Procesos caracterizados en la Organización, y con acciones

proactivas.

Las actividades del proceso de software para la administración e ingeniería están

documentadas, estandarizadas e integradas en un proceso de software estándar para la

Organización


o Foco en los Procesos Organizacionales (OPF)

o Definición de Procesos Organizacionales (OPD)

o Entrenamiento Organizacional (OT)

o Desarrollo de Requerimientos (RD)

o Solución Técnica (TS)

o Integración de Productos (PI)

o Verificación (VER)

o Validación (VAL)

o Administración del Proyecto Integrado (IPM)

o Administración de Riesgos (RiskM)

o Equipo Integrado (IT)

o Ambiente Organizacional (OE)

o Análisis de Decisión y Resolución (DAR)

Nivel 4: Administrado cuantitativamente. Los procesos son medidos y controlados.

Se registran medidas detalladas de las actividades del Proceso y calidad del Producto. El

proceso de software y el producto son entendidos cuantitativamente y controlados.


o Administración Cuantitativa de Proyectos (QPM)

o Performance de los Procesos Organizacionales (OPP)




Nivel 5: Optimizado. Enfoque continuo en la mejora de procesos.

Existe una mejora continua de las actividades, las que se logran a través de un feedback

con estas áreas de procesos y también a partir de ideas innovadoras y tecnología. La

recolección de datos es automatizada y usada para identificar elementos más débiles del

proceso. Se hace un análisis riguroso de causas y prevención de defectos.


o Análisis de Causas y Resolución (CAR)

o Innovación Organizacional (OI)

La descripción de las áreas de Proceso se encuentra en el anexo III.

Gráfico Nro II,2. Evolución del proceso de madurez 2.1.8 Antecedentes del CMMI (CMM, ISO ) El CMMI fue creado para resolver el problema de tener múltiples CMMs. La misión del

CMMI fue combinar los modelos CMM para Software SW-CMM v2.0 draft C,

Electronic Industries Alliance Interim Standar (EIA/IS 731), y CMM para Desarrollo de

productos Integrados IPD-CMM v0.98

Nivel 3 Definido

Nivel 2

Administrado

Nivel 4 Administrado

cuantitativamente

Nivel 5 Optimizado

Proceso disciplinado

Proceso consistente

Proceso predecible

Proceso continuamente mejorado

Nivel 1 Inicial




2.1.9 Necesita su Organización CMMI?

A continuación algunos síntomas para identificar si su organización necesita CMMI.

Estos síntomas fueron tomadas de la presentación “ CMMI Overview for Executives”

de la Universidad Carnegie Mello.

o Los planes se hacen, pero no necesariamente se siguen.

o No se hace el seguimiento al trabajo real vs el plan. Los planes no son revisados.

o Los requerimientos no son consistentes, los cambios no son manejados.

o Los estimados son muy irreales, su incumplimiento es común.

o Cuando no se puede cumplir con los plazos, surge una atmósfera de crisis.

o Los defectos se encuentran en la fase de pruebas, o peor aún los encuentra el

cliente.

o El éxito depende de acciones heroicas de individuos competentes.

o La consistencia en la ejecución es cuestionable.

2.1.10 Componentes del Modelo CMMI

Se denomina Componente a cualquiera de los elementos principales de la arquitectura

que componen un modelo CMMI.

Los componentes del modelo CMMI son: áreas de procesos, metas genéricas, metas

específicas, prácticas genéricas, prácticas específicas y sub prácticas.

Las prácticas genéricas se agrupan según las siguientes características comunes:

o Compromiso para ejecutar

o Habilidad para ejecutar

o Dirección de Implementación

o Verificación de la Implementación

A continuación se define cada uno de los elementos del CMMI




Gráfico Nro. II,2 Componentes del modelo CMMI

Áreas de Proceso (PA)

Un área de proceso es un “Conjunto” de prácticas relacionadas, que ejecutadas

colectivamente satisface un conjunto de metas consideradas importantes para hacer

mejoras significativas en esa área.

Niveles de Madurez

Area de Proceso 1 Area de Proceso 2 Area de Proceso n

Metas específicas

Metas genéricas

Prácticas específicas

Compromiso Habilidad Dirección Verificación

Características comunes

Prácticas genéricas




Metas Genéricas (GG)

Son llamadas “genéricas” porque la misma descripción aparece en múltiples áreas de

procesos.

Metas Específicas (SG)

Las metas específicas aplican a áreas de procesos y direccionan a características únicas

que describen lo que debe ser implementado para satisfacer el área de proceso.

Características Comunes (KF)

Organizan las prácticas genéricas de cada área de proceso. Están agrupadas para

proveer una manera de presentar las prácticas genéricas:



o Dirección para implementación

o Verificación de implementación

Prácticas Genéricas (GP)

Las prácticas genéricas proveen institucionalización para asegurar que el proceso

asociado con el área de proceso debe ser repetible y duradero. Son categorizadas por

metas genéricas y características comunes.

Prácticas Específicas (SP)

Una práctica específica es una actividad que es considerada importante en la meta

específica asociada. Describe las actividades esperadas para conseguir las metas

específicas de un área de proceso.

Sub prácticas

Son descripciones detalladas que proveen guías para interpretar prácticas específicas o

genéricas.




2.2 Fundamentación específica 2.2.1 CMM vs CMMI – Diferencias y Semejanzas

CMM CMMI

5 niveles de madurez 5 niveles de madurez

18 Áreas Claves de procesos 24 Áreas de Procesos

Orientado al Software Integrado: SW, EIA/IS, IPD

Nivel de Madurez 2

CMM CMMI

RM - Administración de Requerimientos. RM - Administración de Requerimientos

SPP - Planeamiento de Proyectos de

Software

PP - Planeamiento de Proyectos

SPTO – Seguimiento del Proyecto de

Software.

PMC - Monitoreo y Control de Proyectos

SSM – Administración de Subcontratos de

Software

SAM - Administración de Acuerdos con

Proveedores

SQA - Aseguramiento de la Calidad del

Software

PPQA - Aseguramiento de la Calidad de

Productos y Procesos

SCM – Administración de la

Configuración del Software

CM - Administración de la Configuración

MA - Métricas y Análisis




Nivel de Madurez 3

CMM CMMI

OPF - Foco en los Procesos

Organizacionales

OPF - Foco en los Procesos

Organizacionales

OPD – Definición de Procesos

Organizacionales

OPD – Definición de Procesos

Organizacionales

PT – Programa de Entrenamiento OT – Entrenamiento Organizacional

RD- Desarrollo de Requerimientos

TS – Solución Técnica

SPE – Software Product Engineering

PI – Integración de Productos

VER - Verificación PR – Revisión por Pares

VAL - Validación

ISM – Administración del Software

Integrado

IC – Coordinación Entre Grupos

IPM – Administración de Proyecto

Integrado

RiskM - Administración de Riesgos

IT - Equipo Integrado

OE – Ambiente Organizacional

DAR – Análisis de Decisión y Resolución

Nivel de Madurez 4

CMM CMMI

QPM- Administración Cuantitativa de

Procesos

QPM – Administración Cuantitativa de

Proyectos

SQM – Administración de la calidad del

Software.

OPP – Performance de los Procesos

Organizacionales




Nivel de Madurez 5

CMM CMMI

DP - Prevención de Defectos CAR – Análisis de Causas y Resolución

TCM – Administración de Cambios

Tecnológicos

PCM – Administración de Cambio de

Procesos

OID – Innovación Organizacional y

Entrega

Cuadro Nro. II,3 Diferencias y semejanzas entre los modelos CMM y CMMI

2.2.2 ¿Por qué se aplica CMMI?

Se aplica CMMI porque:

o Es un modelo que aplica estándares de calidad

o Provee un enfoque más efectivo e integrado a Ingeniería de Sistemas y de

Software.

o Construye procesos desde un inicio, o sobre inversión previa usada con SW

CMM.

o Provee un enlace o relación mas explicita entre la Gestión y la Ingeniería con los

objetivos del negocio.

o Provee mayor visibilidad del ciclo de vida del producto; y las actividades de

ingeniería ayudan a asegurar que los productos y servicios satisfacen las

expectativas de los clientes.

o Incorpora lecciones aprendidas de otras áreas, de mejores prácticas e implanta

prácticas de alta madurez más robustas.

o Incluye funciones organizacionales que son críticas para los productos y

servicios

o Soporta integración futura con otros modelos CMMI de disciplinas específicas.

o Muestra el camino a seguir en la gestión de proyectos, integrando de una manera

ordenada los procesos y los productos.




2.2.3 Procesos

Categoría de Procesos

Niveles

Administración Organización Ingeniería

o CAR: Análisis de Causas y Resolución

o Administración de Cambios Tecnológicos 5. Optimizado

?? Administración de Cambios a los Procesos

4. Controlado o QPM: Administración Cuantitativa del Proyecto

o OPP: Performance de los Procesos Organizacionales

3. Definido o IPM: Administración Integrada del Proyecto

o RiskM: Administración de Riesgos

o DAR: Análisis de Decisión y Resolución

o OPF: Foco en procesos Organizacionales

o OPD: Definición de Procesos Organizacionales

o AE: Ambiente Organizacional

o IT: Equipo Integrado

o RD: Desarrollo de Requerimientos

o TS: Solución Técnica

o VER: Verificación

o VAL: Validación

o PI: Integración de Productos

2. Repetible o RM: Administración de Requerimientos

o PP: Planeamiento de Proyectos

o PMC: Monitoreo y Control de Procesos

o SAM: Administración de Acuerdos con Proveedores

o PPQA: Aseguramiento de Calidad de Productos y Procesos

o CM: Administración de la Configuración

o MA: Medición y Análisis

Ninguno

Los Procesos de Administración deben estar operando antes de iniciar los Procesos

Organizacionales y de Ingeniería

1. Inicial Procesos Ad Hoc

Cuadro Nro. II,4 Cuadro de procesos según nivel y categoría de procesos




2.2.4 Objetivos del presente estudio Para aplicar el modelo CMMI dentro de una empresa es requerido que se revise a

detalle el marco teórico del modelo según lo establecido por el Instituto de Ingeniería de

Software de la Universidad Carnegie y Mellon, defina un modelo integrado de procesos

y construya procedimientos, guías, formatos, herramientas, etc. que respondan al

modelo definido. Posteriormente implementar este modelo definido en base a una

metodología.

El objetivo del presente estudio es mostrar el enfoque del modelo CMMI y la manera

cómo una Organización que cuenta con múltiples Unidades Desarrolladoras de Software

(UDS) pueden operar bajo un modelo definido de calidad estándar e integrado que

originará que la Organización produzca mejores productos basados en las mejoras de

sus procesos.

Se mostrará la aplicación de una metodología para transformar una Empresa con

múltiples Unidades Desarrolladoras de Software a los procesos CMMI. Así mismo

implementar los estándares CMMI en las Unidades Desarrolladoras previa

customización de la Unidad sujeto de estudio.

No es objetivo del presente estudio la construcción de los procedimientos, guías,

formatos, herramientas, etc. que soporten el modelo definido.




CAPÍTULO III

Planteamiento del Problema 3.1 Situación actual La Empresa sujeto de estudio tiene 5 Unidades de Negocio, cada una de ellas cuenta

con una Unidad Desarrolladora de Software – UDS asociada. Una UDS desarrolla

aplicativos corporativos y brinda soporte al 60% de los usuarios de la empresa,

mientras que las otras 4 Unidades tienen sede en Provincias, desarrollan aplicativos

locales y brindan servicio en conjunto al 40% de los usuarios.

Cada UDS opera independientemente utilizando sus propios estándares, metodologías,

procedimientos, prácticas y herramientas. En algunos casos hay procesos que no se

realizan o que se realizan de diversas manera aún dentro de cada UDS. La diversidad de

procesos duplica esfuerzos y dificulta o imposibilita la realización de tareas comunes

dentro de la propia UDS y con mayor razón dentro de la empresa.

Cada Unidad de Negocio solicita sus requerimientos locales de software a la UDS de su

localidad. Algunas veces más de una UDS ha construido el mismo producto bajo

enfoques diferentes y/o plataformas diferentes, lo cual origina serios problemas de

integración.

No se puede predecir de antemano el tiempo que demandará la construcción de un

producto porque no existe la cultura de re-uso de activos (procesos, programas,

procedimientos, etc) ni el registro de datos que permitan un planeamiento en base a

información histórica.

La demanda de actividades de mantenimiento de los aplicativos incluyendo corrección

de errores es muy grande, y toma demasiado tiempo de los programadores, lo que hace

que no se atienda requerimientos visibles de mejora por dedicación del personal a

tareas de mantenimiento.




La documentación sobre las actividades de desarrollo y mantenimiento es muy pobre lo

que origina que el personal desarrollador consuma mucho tiempo entendiendo los

programas y los procesos.

3.2 Antecedentes del estudio

La UDS que brinda los servicios de aplicativos corporativos a la empresa ha elaborado y

aplicado un conjunto de prácticas estándares de desarrollo de software que están

asociadas al modelo CMMI, y construido los procedimientos, guías, formatos y

herramientas para soportar el modelo. Estas prácticas han venido dando resultados a la

UDS. La metodología utilizada para su transformación fue la Metodología

Identificación, Transformación e Implantación – ITI, la misma que generó el modelo

inicial y se denominó “Primera etapa”.

La empresa requiere que estas prácticas sean llevadas a nivel organización, por lo cual

se hace necesario replicar el modelo en cada UDS utilizando la misma metodología ITI

para transformar la otras UDSs a partir del modelo inicial en una implantación por

etapas. La transformación de la UDS “1” a partir del modelo inicial será la

implantación Piloto y se denominará la ITI -“Segunda etapa”.

3.3 Determinación del problema

La diversidad de procesos duplica esfuerzos y dificulta o imposibilita la realización de

tareas comunes dentro de la propia Unidad desarrolladora y con mayor razón dentro de

la empresa. Algunos problemas son:

o Cada UDS tiene su propia política con relación a los procesos de desarrollo de

software.

o El procedimiento de atención de requerimientos no contribuye a una gestión

adecuada de los requerimientos.




o Demasiado esfuerzo en la elaboración de un producto. Cada vez que se desarrolla un

nuevo producto se tienen que realizar todas las actividades. No hay cultura de re-

uso, ni uso de experiencias exitosas.

o Los tiempos para la construcción de software frecuentemente son mayores que los

planeados.

o Los productos elaborados por una UDS no pueden ser utilizados por otra UDS por

cuanto los estándares, procedimientos, procesos, hardware y software son diferentes.

o Las Unidades de Negocio no tienen una visión compartida sobre el desarrollo de

software.

3.4 Justificación

Es necesaria la implantación del modelo CMMI para dar solución a los problemas

planteados y como herramienta que permite disminuir costos a las Unidades de

Negocio y a la organización en general por economías de escala, uniformidad de

procesos, facilitar la comunicación y entendimiento entre el personal de las UDS,

reducción del tiempo de desarrollo, reducción de riesgos, ayuda en la estimación del

software y sobre todo para aumentar la calidad del software.

Es importante que la solución a los problemas se realice utilizando un modelo, porque

un modelo proporciona:

o Un punto donde comenzar

o El beneficio de las experiencias pasadas de la comunidad participante

o Un lenguaje común y una visión compartida

o Un marco para priorizar acciones

o Una forma de definir lo que significa “mejora” para la organización




Se usará el modelo CMMI para:

o Ayudar a establecer objetivos y prioridades en mejoras de procesos

o Ayudar a asegurar procesos estables y maduros y con la capacidad requerida

o Como guía para la mejora de procesos a nivel proyecto y a nivel organización

o Como una metodología de evaluación para diagnosticar el estado de los esfuerzos de

mejora.

Se usará la metodología Identificación, Transformación e Implantación – ITI para

transformar la UDS “1” a los estándares requeridos por el modelo CMMI de una manera

simple y sencilla.




CAPÍTULO IV

Metodología de Identificación, Transformación e Implantación - ITI 4.1 Descripción general de la metodología

Para que una empresa con múltiples UDS adopte el modelo CMMI es recomendable

que exista una transformación que considere la ejecución de dos etapas, la primera

denominada “Primera etapa” para adecuar lo procesos de la empresa a los procesos de

CMMI definiendo un Proceso modelo para la empresa, y la segunda denominada

“Segunda etapa” para adecuar y estandarizar los procesos de cada UDS al modelo

definido para la empresa.

La estrategia que puede usar la empresa puede ser pasar de un nivel de CMMI al

inmediato superior o avanzar más de un nivel. En cualquier caso la metodología que se

usará para pasar del modelo actual al modelo CMMI será la metodología de

Identificación, Transformación e implantación - ITI, la cual se realiza en 3 fases:

o Levantamiento de requerimientos: Determinación del gap (brecha) de procesos

o Transformación: Implementación de los procesos

o Implantación: Institucionalización de las prácticas.

4.2 Descripción detallada

A continuación se describe las fases de la metodología de Identificación,

Transformación e Implantación - ITI.

o Fase Levantamiento de requerimientos

Esta fase comprende el análisis de la situación actual, identificando los procesos y

metodologías utilizadas en la empresa, los procedimientos, estándares, formatos, y

en general los productos de trabajo, y los entregables al cliente relacionados con sus




PAs, determinando el gap (brecha) entre lo que tiene la UDS y lo que se requiere

para cumplir con CMMI, generando el Plan de Transformación.

Las actividades a realizarse durante esta fase son:

1. Identificar el material para entrenamiento.

2. Establecer el repositorio donde se almacenará la documentación.

3. Identificar los procesos, procedimientos, metodologías y formatos utilizados por el

cliente.

4. Analizar la documentación y las prácticas del cliente con relación al desarrollo de

Software.

5. Verificar el nivel de cumplimiento con relación a los estándares de CMMI (uso de

listas de chequeo relacionadas al cumplimiento de las prácticas de cada PA)

6. Consolidar el análisis.

7. Identificar los gaps (brechas).

8. Definir objetivos medibles.

9. Diseñar el Plan de transformación.

10. Revisar el Plan de Transformación.

11. Aprobar el Plan de Transformación.

Los entregables de la fase del Levantamiento de Requerimientos son:

1. Reporte de Aseguramiento de calidad con la identificación del estado de

cumplimiento de cada una de las prácticas genéricas y específicas definidas para las

Áreas de Proceso.

2. Reporte Resumen con el nivel de cumplimiento de cada PA.

3. Gap en relación con el modelo CMMI.

4. Plan del Proyecto.




o Fase Transformación: Adecuación e Implementación de los procesos

Esta fase comprende el análisis del gap, la definición / customización de los

procedimientos a implementar por cada PA, y la elaboración de un Proceso de

Definición del Proyecto – PDP con el cuadro de estándares, procedimientos, guías, y

formatos a utilizarse en cada UDS.


1. Instalar herramientas de soporte.

2. Definir nuevas Bases de datos.

3. Instalar nuevas Bases de datos y autorizar accesos a las mismas.

4. Desarrollar el PDP - Proceso de Definición de Proyecto (por cada PA).

5. Desarrollar y / o adecuar los procedimientos (por cada PA).

6. Documentar las políticas.

7. Habilitar formatos (por cada PA).

8. Verificar desvíos respecto del modelo CMMI.

9. Consolidar el PDP integrado de todas las PAs.

10. Revisar el PDP.

11. Justificar y aprobar desvíos (por personal experto en CMMI).

12. Aprobar el PDP (por personal experto en CMMI).

Los entregables de esta segunda fase son:

1. PDP definido.

2. Procesos estandarizados.

3. Políticas de la UDS “1” orientadas al cumplimiento de CMMI.

4. Procedimientos que cumplen con CMMI.

5. Formatos que cumplen con CMMI.

6. Herramientas que soportan los procesos.




7. Bases de datos que soportan los procesos.

8. Medidas y Mediciones

o Fase Implantación.

Comprende la institucionalización de las prácticas e implementación de las PAs

en las UDS de las Unidades de Negocio.


1. Implantar las PAs.

2. Preparar material de entrenamiento identificado ( por cada PA ).

3. Realizar el entrenamiento.

4. Justificar documentado en una Base de datos las razones por las cuales los formatos,

procedimientos, políticas y prácticas cumplen con CMMI.

5. Revisar las justificaciones.

6. Obtener acuerdos con el cliente en caso de cambios a los procesos, procedimientos

y/o formatos que le impacten.

7. Documentar oportunidades de mejora.

8. Iniciar la ejecución bajo estándares del modelo CMMI.

9. Recoger mediciones

10. Verificar el cumplimiento de los estándares.

Los entregables de esta tercera fase son:

1. Personal capacitado.

2. Acuerdos con los Usuarios.

3. Reportes de mediciones planeados vs reales

4. Reporte de verificación de cumplimiento.




Para la aplicación de la presente metodología se requiere contar con personal experto en

las prácticas de CMMI.

4.3 Esquema de la metodología ITI

Gráfico Nro. IV,1 Esquematización de la metodología ITI.

Estándares del modelo CMMI

Identificación Fase I

Aseguramiento Gap

Plan de transformación

Estándares actuales

Bases de datosactuales

Transformación Fase II

Institucionalización Fase III

Nuevos Estándares

-PDP

Acuerdos con usuarios

Verificación de cumplimiento

Nuevas Bases De datos

•Entrenamiento •Acuerdos •Aplicación estándares CMMI •Actualización DB •Verificación de cumplimiento




4.4 Objetivos de la metodología

Como objetivo general de la metodología es ayudar a la empresa / unidad de negocio a

alinear sus procesos a los procesos del modelo CMMI de tal manera de hacerlos que

cumplan con los estándares del modelo CMMI.

Los objetivos específicos son:

o Diagnosticar el estado de la Organización en relación al CMMI

o Ayudar a la Organización a conseguir una implantación rápida por re-uso de

activos de procesos

o Identificar las brechas para lograr el cumplimiento

o Tomar acciones para reducir las brechas.

o Ayudar a establecer objetivos y prioridades en mejoras de procesos.

o Ayudar a asegurar procesos estables y maduros y con la capacidad requerida.

o Como guía para la mejora de procesos a nivel Proyecto y a nivel Organización.

o Para elaborar productos de calidad utilizando procesos de calidad.




CAPÍTULO V

Proceso de Implantación El proceso de implantación que aquí se describe, está basado en la experiencia de haber

participado en la transformación de una Unidad Desarrolladora de Software, la misma

que en el presente estudio se nombra como UDS “1”. El mismo proceso puede ser

utilizado para transformar otras UDS.

5.1 Descripción general

Se definió el proyecto “CMMI” el cual tuvo como misión implantar el CMMI en la

organización y en la UDS “1” en el más breve plazo. El equipo del proyecto estuvo

conformado por personal experto en procesos de CMMI y personal de la UDS “1”, con

roles y responsabilidades claramente definidos.

o 1 Ejecutivo de Proyecto

o 1 Administrador del proyecto

o 1 líder del proyecto por el lado de la UDS “1”

o Equipo Implementador (*)

o Equipo Implementador por el lado de la UDS “1” (*)

(*) El número de personas que participan en el Proyecto así como el tiempo de

duración del Proyecto dependerá de la definición del alcance del Proyecto, es decir si se

va a realizar una implementación por niveles o una implantación total.

Se definió una estrategia de implementación rápida, para lo cual se tomó en cuenta lo

siguiente:

o Identificar la metodología de transformación a utilizar.

o Incluir dentro del Equipo de implementación a personal experto en CMMI.

o Capacitar al Equipo de implementación en la metodología de Identificación,

Transformación e Implantación - ITI.




o Capacitar al Equipo de implementación de la UDS “1” en CMMI.

o Obtener el compromiso del personal de la UDS “1” para apoyar en las

actividades de CMMI.

o Explicar a todo el personal de la UDS “1” las razones de la implementación

y cómo ayudará en los objetivos de calidad.

o Involucrar a un grupo de la UDS “1” en el Proyecto de Implementación.

o Usar como base los procedimientos, fo rmatos y herramientas que están

siendo utilizados por la UDS “1” y que cumplen con los requerimientos del

CMMI y solicitar aprobaciones a los expertos.

o Para proceso inexistentes y/o procesos que no cumplen con el CMMI usar

procedimientos definidos para la organización.

o Uso de herramientas que permitan desarrollar rápidamente el trabajo y que

ayuden a generar métricas.

o No duplicar esfuerzos registrando bases de datos adicionales. Se usa las

bases de datos existentes, para lo cual es posible que se requiera

modificaciones al SW para generar métricas

o Reducir el impacto en la atención a usuarios.

o La implantación de los procesos organizacionales se debería hacer a nivel

Empresa.

5.1.1 Alcances del estudio

La Implantación del CMMI en una Empresa con varias Unidades de Negocio en las

cuales cada una tiene su propia Unidad de Desarrollo de Software - UDS se realiza en

dos etapas:

La primera etapa consiste en revisar los procesos de CMMI tal como lo define el

Instituto de Ingeniería de Software – SEI de la Universidad Carnegie Mellon, analizar

los procesos, políticas, estándares y procedimientos actuales de la empresa y alinear los

procesos a los procesos de CMMI y elaborar los procedimientos, estándares, políticas de

la empresa para ayudar en la consecución de los objetivos. La segunda etapa consiste en




aplicar los estándares definidos a nivel empresa a las diferentes UDS de las unidades de

negocio manteniendo en lo posible los estándares definidos en la primera etapa.

Es sobre esta segunda etapa que trata el estudio. La Unidad Desarrolladora de Software

sujeto de estudio será la UDS “1”.

5.2 Descripción detallada Al inicio del Proyecto se identificaron un conjunto de actividades y se asignaron

responsables, los cuales tuvieron como responsabilidad de elaborar el plan de

implementación.

Actividades Responsable

1. Mapeo de Matriz de CMMI Equipo de Implantación

2. Identificar cobertura de prácticas CMMI Equipo de Implantación

3. Revisión de aseguramiento de calidad con

Checklist de CMMI

Equipo de Implantación

4. Análisis de Matriz y Checklist para

identificar Gap (brecha) Estado Actual-

CMMI


5. Estimación de Recursos y tiempos para

Implementación en función del gap


6. Elaboración del Plan de Implementación Equipo de Implantación

Cuadro Nro. V,2 Responsables por actividades 5.2.1 Identificación: Levantamiento de Requerimientos La UDS “1” tiene un conjunto de estándares, procesos, procedimientos y formatos

definidos con los cuales ha venido operando. Algunos de los documentos son

compartidos con los Usuarios.




Primera etapa : Nivel Empresa

Segunda etapa : Nivel UDS Cuadro Nro. V,1 Etapas para transformar la empresa a un modelo de CMMI

Interpretación del modelo CMMI y adecuación a la

Empresa

Adecuación y alineación de la UDS “1” con la Empresa

Actuales o Políticas o Procesos o Estándares o Procedimientos

Modelo CMMI del Instituto SEI

Nuevos o Políticas o Procesos o Estándares o Procedimientos (Modelo Empresa)

Unidad de Negocio 1 o Políticas o Estándares o Procedimie

ntos

Unidad de Negocio “n” o Políticas o Estándar

es o Procedim

ientos

Adecuación y alineación de la UDS “n”

con la Empresa

Modelo de la Empresa Prácticas organizacionales

Modelo UDS “1” Modelo UDS “n”




El Equipo de Implantación entrevistó al personal de la USD “1” y revisó los

siguientes documentos que deben ser generados por la UDS “1”:

o Contratos, Acuerdos de niveles de servicio.

o Plan de trabajo de la UDS y de los proyectos.

o Productos de trabajo con actividades de Administración de la calidad

o Registro (Log) de Problemas

o Registro (Log) de Dependencias

o Registro (Log) de requerimientos de cambio

o Registro (Log) de riesgos

o Minutas de reunión con clientes y miembros del equipo.

o Documentos firmados por clientes

o Plan de pruebas

o Resultado de revisiones previas de Aseguramiento de la calidad

o Resultado de cualquier otra revisión previa

o Procesos, procedimientos, metodologías, estándares, guías, formatos.

Se asignó las áreas de proceso a los miembros del equipo. Cada uno de ellos tuvo el

encargo de identificar las brechas (gaps) de una o más áreas de proceso. A continuación,

a modo de ejemplo se muestra un cuadro con algunas prácticas de la PA Planeamiento

del proyecto en la que se muestra los distintos grados de cumplimiento.

Se corroboró la brecha total mediante la revisión de Aseguramiento de Calidad

(PPQA), para conocer el grado de cumplimiento de la USD “1” respecto del modelo

CMMI definido para la Empresa, usando un formato para aseguramiento de procesos

(checklist) que tiene una lista de chequeo de todos los puntos relacionados con el

cumplimiento de las prácticas genéricas y específicas del CMMI de todas las áreas de

procesos.




PP: Planeamiento del Proyecto

Práctica Observación Brecha Grado de

cumplimiento

SP 1.1 Estimar el

alcance de

proyecto

Esta práctica se cubre mejorando

y consolidando el alcance que

actualmente tiene el plan del

proyecto de la UDS1.

El WBS que servirá como

sustento para definir el alcance.

Falta

consolidar y

mejorar el

alcance del

proyecto

Cumple

parcialmente

70%

SP 1.2 Establecer

estimados de

productos de

trabajo y atributos

de las tareas

Esta práctica se cubre usando la

metodología para estimación que

tiene la UDS1. Para los costos,

se usará la tabla de costos por

persona para el presente año.

Para el planeamiento de

actividades, se usará un diagrama

de Gantt.

No se ha

identificado

brechas.

Cumple

100%

SP 2.3 Plan para

administrar los

datos

La UDS1 no tiene un plan para el

manejo de la data.

Generar el Plan

de

Administración

de datos

No cumple

Cuadro V,4 Identificación de brechas por PA

A continuación se muestra un cuadro resumen por área de proceso del número de

prácticas revisados y el porcentaje de cumplimiento de las prácticas.




Área de

Proceso

Nro de items

revisados

(prácticas)

Adherencia

%

Comentarios Esfuerzo

esperado

(días)

RM 8 50 10

PP 39 48 65

PMC 30 38 29

MA 8 0 29

PPQA 7 71 10

CM 22 61 15

CMMI2: 45%

Area de Proceso

Nro de items revisados (prácticas)

Adherencia %

Comentarios Esfuerzo esperado

(días) RD 14 35 32

TS 12 22 25

PI 16 6 36

VER 12 16 18

VAL 11 37 9

OPF 5 80 Nivel empresa 8

OPD 3 66 Nivel empresa 8

OT 2 50 Nivel empresa 8

IPM 15 26 26

Risk

Management

8 12 14

DAR 6 0 22

CMMI3: 26%




Area de Proceso


Adherencia %


(días) OPP 2 0 Nivel empresa 10

QPM 4 0 18

CMMI4: 0%

Area de Proceso


Adherencia %


(días) CAR 2 0 20

OID 5 0 Nivel empresa 8

CMMI5: 0%

TOTAL 231 30% 420

Cuadro V,4 Reporte Resumen del nivel de cumplimiento de las PAs

Se analizó el Reporte de Aseguramiento de calidad. El resultado del análisis arrojó

como resultado que la USD “1” tuvo 30 % de adherencia al CMMI. Con este resultado

se determinó el alcance, el esfuerzo y el costo del Proyecto y se elaboró el Plan del

Proyecto.

La estimación del alcance fue dada por las tareas a realizarse en cada una de las PAs

para completar en conjunto el 70% de cumplimiento faltante.

El esfuerzo estimado para la Transformación e Implantación fue de 24 meses -

persona, en base a la situación actual, complejidad y número de pendientes por

implementar en cada PA. Se asignó 3 personas a tiempo completo para lograr el

objetivo de implantarlo en 10 meses.

El costo del Proyecto fue calculado en base de los recursos requeridos (personal,

infraestructura, HW, SW) y al tiempo de dedicación del personal.




Se determinó que todas las PAs de carácter general como por ejemplo las

Organizacionales fueran ejecutadas por el Equipo de Procesos de la Empresa. La

ejecución de todas las otras PAs fueron de responsabilidad de la UDS “1”.

Los entregables de la fase “Levantamiento de Requerimientos” fueron: Un Reporte de

Aseguramiento de calidad con la identificación de estado de cumplimiento de cada una

de las prácticas genéricas y específicas definidas para las Áreas de Proceso, un Reporte

Resumen con el nivel de cumplimiento de cada PA, y el Plan del Proyecto.

5.2.2 Transformación: Implementación de los procesos

Se usó una clasificación del proyecto dependiendo del % de cumplimiento de las

prácticas de la Unidad de Negocio con relación a las prácticas definidas en el modelo

de la empresa según la siguiente tabla:

% de cumplimiento Categoría

Más de 81% A

Entre 61% y 80% B

Entre 41% y 60% C

Entre 21% y 40% D

Menos de 20 % E

Cuadro V,5 Clasificación del proyecto

Según esta tabla, la clasificación de la UDS “1” fue “D” con un porcentaje de

cumplimiento con el modelo de la empresa fue de 30%.

Luego de establecido el gap (brecha) entre los procedimientos existentes identificados

en el “Levantamiento de Requerimientos” y lo que requiere CMMI, se trabajó en la

definición y adecuación de los procedimientos, formatos, herramientas a implementar

por cada PA para hacerlos que cumplan con el CMMI. El detalle de lo que requiere




cada PA y las evidencias de cumplimiento con el CMMI puede encontrarse en el anexo

III del presente documento.

Se elaboró el Proceso de Definición del Proyecto – PDP con los productos de trabajo

que cumplen con el CMMI a ser utilizado por la UDS “1”, y que será el marco para

todas las actividades de desarrollo de software de la UDS “1”. La descripción del PDP

con la información mínima requerida, así como modelos de formatos utilizados puede

encontrarse en el anexo IV.

Los entregables de esta segunda fase fueron:

o PDP definido.

o Políticas de la UDS “1” orientadas al cumplimiento de CMMI.

o Procesos definidos.

o Procedimientos que cumplen con CMMI.

o Guías.

o Formatos que cumplen con CMMI.

o Herramientas que soportan los procesos.

o Estándares.

o Bases de datos que soportan los procesos.

5.2.3 Implantación: Institucionalización de las practicas

Comprende la implementación de las prácticas genéricas y específicas de cada PAs para

ser utilizado por todo el personal de la UDS “1”.

o Se dió acceso al personal de la UDS “1” a las Bases de datos definidas.

o Se capacitó a todo el personal de la UDS “1” en los nuevos procesos,

procedimientos, guías, formatos así como en el manejo de las nuevas Bases

de datos.




o Se apoyó al personal para manejar el cambio cultural dentro de la

organización.

o Se verificó el cumplimiento de los procedimientos por el personal de la

UDS “1” y se reforzó la capacitación en las áreas de menor cumplimiento.

o Se realizó acuerdos con los Usuarios para manejar el cambio de los

procedimientos, procesos y formatos que les afectan.

o Se estableció un Equipo de procesos permanente en la UDS “1” cuya

responsabilidad fue la verificación continua del cumplimiento de los

procedimientos a través de la revisión de evidencias.

o Se incluyó en el kit de inducción al personal nuevo la capacitación en las

políticas, procesos, procedimientos, formatos, guías y herramientas con las

que se cumple el CMMI.

Los entregables de esta tercera fase fueron:

o Capacitación al personal

o Acuerdos con los Usuarios

o Reporte de verificación de cumplimiento

5.2.4 Barreras para una implantación exitosa

Durante la implementación se encontró barreras que originaron riesgos en el proyecto.

A continuación se detalla las más relevantes, y las acciones tomadas para superarlas.

5.2.4.1 Cultura del Usuario: Los Usuarios requieren que sus requerimientos sean

atendidos de inmediato, lo cual origina conflicto en los desarrolladores entre la atención

al usuario y el cumplimiento de las evidencias del CMMI, eligiendo la atención al

cliente.




Para superar esta barrera se realizaron las siguientes acciones:

o Se divulgó el modelo a los niveles más altos de la organización.

o Se incluyó a los Usuarios en este proceso, y se les explicó la importancia

que la atención del requerimiento sea en forma completa, y las implicancias

de no hacerlo. Este punto hizo que baje la presión de los usuarios sobre los

Desarrolladores.

o Se revisó el proceso de atención de requerimientos para incluir un

procedimiento para manejar las urgencias.

5.2.4.2 A los Desarrolladores no les gusta documentar ni alimentar las bases de datos,

por lo cual generalmente inician la atención de un siguiente requerimiento antes de

haber culminado la documentación del anterior.

Para superar esta barrera se realizaron las siguientes acciones:

o Se incluyó específicamente en la descripción de puestos las actividades de

documentación y actualización de las bases de datos.

o Se dividió la documentación y la actualización de las bases de datos según

roles, de esta manera no toda la documentación recayó sobre una persona.

o Se desarrollaron formatos (templates) que faciliten el llenado de la

documentación.

o Se utilizó herramientas para la documentación.

o Se reforzó la capacitación a los Desarrolladores en los procedimientos

asociados a las áreas de proceso.

5.2.5 Factores críticos de éxito

A continuación se describe los factores que se consideran críticos para alcanzar la

transformación.




o Es necesario que el Sponsor del Proyecto sea de un cargo muy alto dentro

de la organización.

o Es importante involucrar a todos los stakeholders definiendo y divulgando

sus roles y responsabilidades, manteniendo una comunicación permanente

simple y muy estrecha.

o Es determinante seguir una metodología que marque la ruta a seguir

durante el proceso de transformación.

o Es necesario tener objetivos claros y medibles al inicio del proyecto, y

efectuar mediciones que indiquen si se logró el objetivo.

o Para la aplicación de la presente metodología se requiere contar con

personal experto en las prácticas de CMMI, compromiso del personal que

implanta y del personal que ejecuta.




CAPÍTULO VI

Conclusiones “Madurez de Procesos es un indicador del potencial de crecimiento en capacidad de

procesos de una Organización, Rendimiento es el resultado actual alcanzado por el

proceso, y Capacidad es el rango esperado a ser alcanzado por los procesos”, es decir

si conocemos el rendimiento de nuestra Organización, podremos predecir su capacidad

de proceso.

El modelo CMMI ayuda a desarrollar la madurez de las Organizaciones de Desarrollo

de Software en forma progresiva nivel a nivel. Cuando una Organización pasa de un

nivel al inmediato superior debe implementar un conjunto de prácticas claves que

aumentan su capacidad de dar respuesta a los desafíos cada vez más exigentes del

negocio de Desarrollo y Mantenimiento de aplicaciones. La opción por el CMMI

significa reconocer que el único camino para la supervivencia en una economía de largo

plazo es ejecutar “mejor”, “más rápido” y “más barato”. Esta elección está alineada con

la tendencia de las empresas de servicio insertadas en un mercado globalizado, de

implementar un método internacional reconocido por la Industria del Software, para

certificar la calidad que brindan a sus clientes.

EL modelo CMMI se basa en el concepto de la evolución de la madurez de los

procesos, esto implica un orden, es decir que algunas acciones deben realizarse antes en

una organización para que pueda avanzar hacia niveles de madurez superiores. Por

ejemplo, se debe alcanzar un control básico en los proyectos antes que el proceso de

software sea uniformizado en toda la organización. El CMMI por tanto, provee un

estándar de gran valor para juzgar el progreso del proceso de mejora, y el darse cuenta

que operar bajo un modelo CMMI implica “Mejorar los procesos para tener mejores

productos”.




El uso de un modelo estándar e integrado con un enfoque de calidad según el modelo

CMMI en una organización que cuenta con múltiples Unidades Desarrolladoras de

Software (UDS) originará que la organización produzca “mejores productos basados

en las mejoras de sus procesos”.

El uso de una metodología para llevar a una Organización de Desarrollo de Software

como la metodología de Identificación, Transformación e Implantación – ITI es factor

determinante en la transformación de una Empresa hacia estándares de calidad como el

CMMI porque indica el mapa a seguir durante la transformación.

La metodología de Identificación, Transformación e Implantación – ITI permite a la

Empresa una transformación rápida y gradual hacia el modelo CMMI con resultados

objetivos y de calidad. Los activos que genera pueden ser re-usados por otra Unidad

Desarrolladora de Software.

Propuesta para Implantar CMMI en una Empresa con Múltiples Unidades Desarrolladores de Softwre. Concha Huaroto, Nancy Elizabet .



CAPÍTULO VII

Recomendaciones 1. Es necesario que el uso de modelos CMMI sea política de empresa. De esta forma se

asegura que los procedimientos y estándares se mantengan vivos y no caigan en desuso.

2. Es necesario definir una metodología para transformar una Empresa hacia modelos

CMMI. La metodología de Identificación, Transformación e Implantación – ITI

contribuye fuertemente hacia el logro de la transformación.

3. Es recomendable que la implantación de CMMI sea por etapas dentro de un proceso

escalonado subiendo de nivel en nivel.

4. Es necesario que la empresa mantenga un área que monitoree permanentemente los

procesos CMMI y que vigile su cumplimiento.

5. Es necesario involucrar a los usuarios “Stakeholders” en los procesos CMMI.

6. Es necesario que al inicio del proyecto se defina un repositorio flexible y organizado

(base de datos) que permita almacenar todas las evidencias de cumplimiento con las

prácticas de CMMI.

7. Es necesario que el personal del Proyecto así como el personal de toda el área esté

informado del avance del proyecto.

8. Tomar acciones rápidas que permitan superar las barreras y riesgos encontrados y que

afectan el éxito de la implementación:

o Establecer y definir claramente los roles y responsabilidades del personal

implementador.

o Capacitar previamente a todo el personal en CMMI, obteniendo el compromiso

del personal para apoyar en las actividades de CMMI.

o Usar como base los procedimientos y formatos que están siendo utilizados y

que cumplen con los requerimientos del CMMI y solicitar aprobaciones a los

expertos.

Propuesta para Implantar CMMI en una Empresa con Múltiples Unidades Desarrolladores de Softwre. Concha Huaroto, Nancy Elizabet .



o Para procesos inexistentes y/o procesos que no cumplen con el CMMI usar

procedimientos de la instalación.

o No se debe afectar los niveles de servicio, para lo cual es necesario que se

asigne recursos adicionales, tanto de personal como de herramientas.

o Uso de herramientas que permitan desarrollar rápidamente el trabajo y que

ayuden a generar métricas (ejemplo: rational rose, visio, ms project, rational

clear case, etc)

o No duplicar esfuerzos registrando bases de datos adicionales. Evaluar las bases

de datos existentes, para verificar si requiere modificaciones al SW para

generar métricas.

o Involucrar a los clientes en el cambio.

Durante la implantación se recomienda:

1. Capacitar al personal desarrollador en los nuevos procesos, procedimientos y

formatos así como en las nuevas Bases de datos y hacer extensiva esta capacitación

a todo personal nuevo.

2. Explicar al personal desarrollador la importancia de seguir las prácticas de CMMI y

la generación de las evidencias de cumplimiento.

3. Verificar continuamente el cumplimiento de los procesos por todo el personal,

hasta que se haya generado la práctica.

Recomendación final

Utilizar la presente propuesta como base inicial para la construcción de una transformació n

hacia estándares de calidad como las que usa el modelo CMMI y completarlas con

investigación del modelo CMMI y la aplicación de acuerdo a la realidad de cada empresa.




Referencias

o Capability Maturity Model Integration (CMMI) Versión 1.1

o CMMI for Systems Engineering and Software Engineering (CMMI-

SE/SW,V1.1) Staged Representation

o Presentación “CMMI Overview for Executives” de la Universidad Carnegie

Mello.

o La Calidad es libre de Philip B. Crosby

Propuesta para Implantar CMMI en una Empresa con Múltiples Unidades Desarrolladores de Softwre. Concha Huaroto, Nancy Elizabet..



ANEXOS

ANEXO I

Glosario de términos:

Áreas de Proceso (PA)

Un área de proceso es un conjunto de prácticas relacionadas en un área que ejecutadas

colectivamente satisface un conjunto de metas consideradas importantes para hacer

mejoras significativas en esa área.

Metas Genéricas (GG)

Son llamadas “genéricas” porque la misma descripción aparece en múltiples áreas de

procesos.

Metas Específicas (SG)

Las metas específicas aplican a áreas de procesos y direccionan a características únicas

que describen que debe ser implementadas para satisfacer el área de proceso.

Características Comunes (KF)

Organizan las prácticas genéricas de cada área de proceso. Están agrupadas para

proveer una manera de presentar las prácticas genéricas:



o Dirección para implementación

o Verificación de implementación

Prácticas Genéricas (GP)

Las prácticas genéricas proveen institucionalización para asegurar que el proceso

asociado con el área de proceso debe ser repetible y duradera. Son categorizadas por

metas genéricas y características comunes.




Prácticas Específicas (SP)

Una práctica específica es una actividad que es considerada importante en la meta

específica asociada. Describe las actividades esperadas para resultar un acercamiento de

las metas específicas de un área de proceso.

Sub prácticas

Son descripciones detalladas que proveen guías para interpretar prácticas específicas o

genéricas.

Stakeholders : Personas que tienen un fuerte relacionamiento con el proyecto, ya sea

porque proporcionan datos al proyecto o porque reciben datos del mismo,

ANEXO II

Acrónimos

CM Administración de la Configuración

CMM Modelo de Maduración de Capacidad

CMMI Modelo Integrado de Maduración de la Capacidad

DAR Análisis de Decisión y Resolución

EIA/IS 731 Electronic Industries Alliance Interim Standar

GG Metas Genéricas

GP Prácticas Genéricas

IPD-CMM CMM para Desarrollo de productos Integrados

IPM Administración del Proyecto Integrado

MA Mediciones y Análisis

PA Áreas de Proceso

PDP Proceso Definido para el Proyecto

PMC Monitoreo y Control de Proyectos

PP Planeamiento de Proyectos

PPQA Aseguramiento de Calidad de Productos y Procesos

QPM Administración Cuantitativa del Proyecto




RD Desarrollo de Requerimientos

RM Administración de Requerimientos

RiskM Administración de Riesgos

SP Prácticas Específicas

SW-CMM CMM para Software

WBS Work Breakdown Structured

ANEXO III

Descripción detallada de PAs y evidencias de cumplimiento Prácticas Generales

Todas las Áreas de Procesos (PAs) deben cumplir un conjunto de prácticas generales,

cuyas evidencias de cumplimiento deben almacenarse en un repositorio del Proyecto. A

continuación se describen las prácticas generales:

o Políticas

Se cumple con esta práctica si existe una política definida que describe los objetivos,

visión, misión y los estándares de la empresa, y que el personal involucrado haya leído

la política y confirmado su adherencia a la política notificado su lectura de la política.

Esta notificación debe almacenarse en la base de datos del proyecto.

Ejemplos de cumplimiento: Políticas y notas de confirmación de lecturas almacenadas

en un repositorio.

o Planes

Se cumple con esta práctica si se tiene planes de trabajo tanto para los proyectos como

para atender la operativa, considerando todas las tareas relacionadas con todas las PAs,

y si éstos planes están dentro de un gantt general . Existe un responsable para su

creación, revisión y mantenimiento.




Ejemplos de cumplimiento: Plan del Proyecto, Plan de Administración de la

Configuración, Gantt General, Plan Operativo, Plan de administración de riesgos, plan

de aseguramiento de la calidad, etc.

o Recursos

Se cumple con esta práctica si todo proyecto define los recursos necesarios

(herramientas, infraestructura, personas) para la ejecución de lo planeado, y existe un

responsable para su definición y su asignación.

Ejemplos de cumplimiento: Recursos asignados (de HW, de SW, de infraestructura y de

personal) estén identificados en el Plan del Proyecto, en el Plan de Administración de la

Configuración, etc.

o Responsabilidad

Se cumple con esta práctica si cada tarea definida en el proyecto tiene asignada una

persona responsable.

Ejemplos de cumplimiento: Responsables de ejecutar las tareas, identificadas en el Plan

del Proyecto, en el Plan de Administración de la Configuración, etc.

o Entrenamiento

Se cumple con esta práctica si todo proyecto identifica las necesidades de entrenamiento

para la ejecución del mismo. Existe un responsable para la definición y la ejecución.

Ejemplo de cumplimiento: Requerimientos de entrenamiento definidos en el Plan del

Proyecto, y Desarrollo de un control para monitoreo de cumplimiento de entrenamiento.

o Administración de la configuración

Se cumple con esta práctica si todo proyecto define en un plan los componentes que

estarán bajo el control de versiones.




Ejemplo de cumplimiento: Documento “Plan de Administración de la Configuración”

que tenga todos los componentes que van a estar bajo control de la configuración como

versiones de manuales, versiones de procedimientos, versiones de programas, etc.

o Stakeholders

Se cumple con esta práctica si todo proyecto identifica a los stakeholders (del proyecto,

del cliente y/o externos) a los cuales se involucra conforme a lo planeado. , los mismos

que son involucrados conforme lo planeado.

Ejemplo de cumplimiento: Plan de involucramiento de los stakeholders, minutas de

reuniones con los stakeholders y copia de mails. ?

o Monitoreo y Análisis de métricas

Se cumple con esta práctica si todo proyecto hace seguimiento periódico a lo planeado,

toma las acciones correctivas a los desvíos y se analiza tendencias.

Ejemplo de cumplimiento: Definición de las métricas del Proyecto en un Plan de

calidad, procedimiento para colectar las métricas, colección de las métricas y Análisis

de las métricas.

o Aseguramiento de la Calidad.

Se cumple con esta práctica si todo proyecto realiza revisiones periódicas para asegurar

la calidad, el mismo que cubre todas las ¨PAs.

Ejemplo de cumplimiento: Reporte de Aseguración de calidad, Lista de verificación de

Aseguramiento de Calidad.

o Revisión de alto nivel.

Se cumple con esta práctica si todo proyecto reporta a la gerencia superior

periódicamente el estado del proyecto, el mismo que debe considerar mediciones para

cada una de las PAs.




Ejemplos de cumplimiento: Preparación de un resumen “Reporte de Estado” que se

presenta periódicamente al nivel superior, para revisar nivel cumplimiento y analizar y

tomar acciones sobre problemas y riesgos. Las mediciones en este reporte pueden ser

Número de horas dedicadas a cada PA, Nro de productos de trabajo atendidos, % de

avance en el cumplimiento, etc.

o Definición de Procesos para el Proyecto (PDP).

Todo proyecto define un Proceso General “Proceso de Definición de Proyecto” – PDP

los cuales rigen el proyecto. En este mismo PDP se deben detallar las razones para su

construcción. Existe un responsable para la definición, aprobación y mantenimiento del

PDP.

Ejemplo: Construcción de un proceso que contenga las políticas, procedimientos,

procesos, herramientas y formatos utilizados en el proyecto.

o Mejoras.

Todo proyecto identifica activos y oportunidades de mejora para ser reutilizadas por la

organización. Los activos y las oportunidades de mejora deben almacenarse en archivos

o bases de datos, de tal manera de explotar la información que ahí se almacena.

Ejemplo de cumplimiento: Bases de datos de “Mejoras”, Bases de datos de “Lecciones

aprendidas”

Prácticas Específicas

Todas las Áreas de Procesos (PAs) deben cumplir un conjunto de prácticas que son

específicas de cada una de ellas. A continuación se describe las prácticas específicas de

las PAs, las cuales se han agrupado por tipo de PA.




o NIVEL 2

Administración de Requerimientos (RM)

El propósito de “Administración de Requerimientos” es administrar los requerimientos

del proyecto e identificar inconsistencias entre esos requerimientos y los planes del

proyecto y productos de trabajo.

Se cumple con las prácticas específicas de “Administración de Requerimientos”, si se

cumple las siguientes metas específicas:

o Administrar Requerimientos

Los requerimientos se administran y se identifican las inconsistencias con los planes del

proyecto y productos de trabajo.

1. Se entiende los requerimientos (comunicación con el cliente para entender los

requerimientos)

2. Se obtiene compromiso del personal involucrado en la atención del

requerimiento.

3. Se administra los cambios a los requerimientos (procedimiento de control de

cambios)

4. Se obtiene la trazabilidad bidireccional de los requerimientos (Desde el

requerimiento se identifica a todos los componentes involucrados en el cambio,

y desde cualquier componente se identifica al requerimiento original).

5. Se identifica inconsistencias entre los trabajos del proyecto y los requerimientos

(Ejemplo: Diseño no está de acuerdo con el requerimiento, etc)

Ejemplos de cumplimiento: Plan Operativo, Documento de Alcance, Minuta de

Comunicación del Plan, Procedimiento de control de cambios, Revisión de Diseño por

los pares, Aplicativos para gestionar los Requerimientos.




PA Planeamiento de Proyecto (PP)

El propósito de “Planeamiento de Proyecto” es establecer y mantener planes que

definan el alcance y el ciclo de vida del proyecto; y establezcan el presupuesto y los

cronogramas con las actividades del proyecto.

Se cumple con las prácticas específicas de Planeamiento de Proyecto, si se cumple las

siguientes metas específicas:

o Establecer estimaciones

Las estimaciones de los parámetros se establecen y se mantienen según el plan del

proyecto.

1. Se estima el alcance del proyecto (WBS, relación de tareas)

2. Se establece los atributos de estimación de los productos de trabajo y tareas

(tamaño en puntos de función, líneas de código, etc.)

3. Se define el ciclo de vida del proyecto (fases del proyecto, ejm propuesta y

ejecución)

4. Se determina los estimados de esfuerzo (horas)

Ejemplo de cumplimiento: Work Breakdown Structured (WBS), Gantt general, Plan

General del proyecto, Plan Operativo, Ciclo de vida Proyectos.

o Desarrollar el Plan del proyecto

Se establece un Plan del proyecto en el que se identifican los riesgos, se desarrollan los

planes de administración de datos, de manejo de recursos, de involucramiento de los

stakeholders y de administración de habilidades; y se mantiene como base para la

administración del proyecto.




1. Se establece el Presupuesto y Schedule.

2. Se identifican los riesgos.

3. Se define un Plan para administrar los datos.

4. Se define un Plan para administrar los recursos.

5. Se define un Plan para administrar el conocimiento y habilidades.

6. Se define un Plan para involucrar a los stakeholders.

7. Se establece el Plan general del Proyecto (Debe integrar a todos los planes).

Ejemplo de cumplimiento: Plan del Proyecto, Gantt General, Plan Operativo,

Evaluación de Riesgos, Plan de Administración de datos, Plan de Involucramiento de

Stakeholders, plan de Administración de habilidades.

o Obtener compromiso para el Plan

Se establecen y mantienen compromisos con los involucrados en el Proyecto con las

actividades definidas en el plan del proyecto.

1. Se revisan los planes que afectan al proyecto (con los involucrados)

2. Se reconcilia los trabajos con la disponibilidad de recursos

3. Se obtiene el compromiso de los involucrados con el plan (minuta, mail, firmas,

etc)

Ejemplos de cumplimiento: Minutas de reunión de revisión de los planes con los

involucrados internos y externos.

PA Control y Monitoreo del Proyecto (PMC)

El propósito de “del Proyecto” es proveer un entendimiento del progreso del proyecto

para que se puedan tomar acciones correctivas apropiadas cuando el desempeño del

proyecto se desvía significativamente del plan.




Se cumple con las prácticas específicas de “Control y Monitoreo del Proyecto”, si se


o Monitorear el proyecto a partir del plan

Se hace seguimiento del desempeño y el progreso actual del proyecto a partir del plan

del proyecto.

1. Se monitorea los parámetros de planeamiento del proyecto (% de avance, fechas

reales vs fechas estimadas, nro. de requerimientos atendidos vs el planeado, etc.)

2. Se monitorea los compromisos.

3. Se monitorea los riesgos.

4. Se monitorea el plan de administración de datos (Que los datos existan y estén

almacenados en el lugar correcto).

5. Se monitorea el involucramiento de los stakeholders.

6. Se conduce revisiones del progreso del proyecto (Avance del proyecto).

7. Se conduce revisiones de los hitos del proyecto.

Ejemplos de cumplimiento: Reporte de estado del proyecto, Plan operativo, Reporte de

Seguimiento al Plan del Proyecto, Seguimiento al Plan de Administración de riesgos,

Seguimiento al Plan de administración de datos, Seguimiento al Plan de

Involucramiento de los stakeholders.

o Administrar acciones correctivas a tomar

Se administran las acciones correctivas a tomar cuando el desempeño del proyecto, o los

resultados se desvían significativamente del plan.

1. Se analizan los problemas.

2. Se toman las acciones correctivas.

3. Se administran las acciones correctivas.

Ejemplo de cumplimiento: Registro de Problemas y acciones correctivas(Log)




PA Mediciones y Análisis (MA)

El propósito de “Mediciones y Análisis” es desarrollar y mantener la capacidad de

tomar mediciones para responder a las necesidades de información requeridas para el

gerenciamiento del proceso de software, tanto a nivel de proyecto como a nivel de

organización.

Se cumple con las prácticas específicas de “Mediciones y Análisis”, si se cumple las


o Alinear actividades de medición y análisis con los objetivos y las necesidades de

información.

1. Se establecer objetivos de medición.

2. Se especifican medidas (métricas básicas: nro. de requerimientos a atenderse,

esfuerzo esperado de corrección de errores, etc.).

3. Se establecen procedimientos de colección de datos y almacenamiento.

4. Se establece el procedimiento de análisis.

Ejemplos de cumplimiento: Métricas básicas y calculadas, Plan de calidad, Niveles de

Servicio, Procedimiento para recolección y análisis de métricas

o Proveer resultados de las mediciones

Se proveen resultados de las mediciones asociadas con los objetivos y las necesidades

de información identificadas.

1. Se colecciona las mediciones.

2. Se analiza las mediciones (para ver si los datos obtenidos son los correctos).

3. Se almacena los datos y resultados (métricas básicas y calculadas).

4. Se comunica los resultados del proceso a los involucrados.




Ejemplos de cumplimiento: Reporte de Estado del Proyecto, Análisis de Congruencia

de Métricas, Reporte de métricas calculadas, Análisis de Causas de Desvíos.

PA Administración de la Configuración (CM)

El propósito de “Administración de la Configuración” es establecer y mantener la

integridad de los productos de trabajo usando identificación de configuración, control de

configuración, cuentas de estados de configuración, y auditorías de configuración.

Se cumple con las prácticas específicas de “Administración de la Configuración”, si se


o Establecer líneas base

Se establecen las líneas base de los productos de trabajo identificados.

1. Se identifica los items de la configuración

2. Se establece y mantiene un sistema de administración de la configuración.

3. Se crea o libera baselines (para uso interno o para entregar al cliente)

Ejemplos de cumplimiento: Plan de Administración de la Configuración, Baselines del

proyecto

o Seguir y controlar cambios

Se siguen y controlan los cambios de los productos de trabajos que están bajo control de

configuración.

1. Se monitorea los requerimientos de cambio.

2. Se controla los cambios a los items de la configuración.

Ejemplos de cumplimiento: Baselines, Registro de Pases a Producción, Revisión

mensual, Comparación de Cambios

o Establecer integridad




Se establece y mantiene la integridad de las líneas base.

1. Se establece y mantiene registros describiendo los items de configuración.

2. Se ejecuta auditorias a la configuración, para mantener la integridad.

Ejemplos de cumplimiento: Registro de pases a producción, Historia de Versiones en

Producción, Auditorias de Administración de la Configuración

PA Aseguramiento de la Calidad de Productos y Procesos (PPQA)

El propósito de Aseguramiento de Calidad de Procesos y Productos es proveer un staff y

administración con el objetivo de aseguramiento que se hayan cumplidos con los

procedimientos que soportan los procesos que aseguran la calidad.

Se cumple con las prácticas específicas de “Aseguramiento de la calidad de productos y

Procesos”, si se cumple las siguientes metas específicas:

o Evaluar objetivamente procesos y productos de trabajo

1. Se evalúa objetivamente los procesos. (contra listas predefinidas)

2. Se evalúa objetivamente los productos de trabajo y servicios (contra listas

predefinidas)

o Proveer comunicación interna objetiva

1. Se comunica las no conformidades y se asegura su resolución.

2. Se establece y mantiene registros de actividades de aseguramiento




o NIVEL 3 PA Desarrollo de Requerimientos (RD) El propósito de “Desarrollo de Requerimientos” es producir y analizar requerimientos

del cliente, del producto y de componentes del producto. Se cumple con las prácticas

específicas de “Desarrollo de Requerimientos”, si se cumple las siguientes metas

específicas:

o Desarrollo de requerimientos del Cliente

Se recolectan las necesidades de los stakeholder, expectativas, limitaciones e interfaces,

y se trasladan a los requerimientos del cliente.

1. Se obtienen las necesidades de los stakeholders.

2. Se desarrollan los requerimientos del cliente.

Ejemplos de cumplimiento: Memorándum de usuario, Reporte de Definición del

Proyecto, Documento de Alcance (de Requerimientos).

o Desarrollar requerimientos del Producto

Se elaboran y refinan los requerimientos del cliente para desarrollar los requerimientos

del producto y los componentes del producto.

1. Se establecen los requerimientos de productos y de componentes de productos.

2. Se asigna los requerimientos a cada componente de los productos.

3. Se identifica los requerimientos de interfases.

Ejemplos de cumplimiento: Reporte de Definición del Proyecto, Documento de

Alcance.

o Analizar y validar requerimientos

Se analizan y validan los requerimientos, y se desarrolla la definición de la

funcionalidad requerida.




1. Se establece y mantiene los conceptos operacionales y escenarios asociados.

2. Se establece y mantiene una definición de la funcionalidad requerida.

3. Se analizan los requerimientos para asegurar que son necesarios y suficientes.

4. Se analizan los requerimientos para balancear las necesidades de los

stakeholders y las restricciones. (usando modelos, prototipos, simulaciones, etc)

Ejemplos de cumplimiento: Documento de Alcance, Reporte de definición del Proyecto

Revisión por pares de Requerimientos, Evaluación de riesgos técnicos, Diseño Externo,

Revisión de Diseño Externo por los pares.

PA Solución Técnica (TS)

El propósito de “Solución Técnica” es diseñar, desarrollar e implementar soluciones a

los requerimientos. Las soluciones, diseños e implementaciones abarcan productos,

componentes del producto, y ciclos de vida asociados al producto.

Se cumple con las prácticas específicas de “Solución Técnica”, si se cumple las


o Seleccionar las soluciones de los componentes del producto

Se seleccionan las soluciones del producto o componente de producto desde soluciones

alternativas.

1. Se desarrollan alternativas de solución y criterios de selección (costos,

rendimiento técnico, complejidad, limitaciones tecnológicas, riesgos, facilidad

de uso, etc).

2. Se evoluciona conceptos operacionales escenarios y ambientes para describir las

condiciones (modo de operación, estado de operación para cada componente)

3. Se selecciona las soluciones de componente de producto que mejor satisface los

criterios establecidos.




Ejemplos de cumplimiento: Registros de Análisis de Decisiones, Diseño Externo.

o Desarrollar el Diseño

Se desarrollan los diseños del producto y componente del producto.

1. Se desarrolla un diseño por cada producto o componente de producto

(arquitectura del producto, diseño detallado).

2. Se establece un paquete de datos técnicos.

3. Se diseña las interfases en términos de criterios establecidos y mantenidos.

4. Se evalúa si los componentes de los productos deben ser desarrollados,

comprados o re-usados en base a criterios establecidos.

Ejemplos de cumplimiento: Diseño Externo, Documento de Alcance, Diseño Interno.

o Implementar el Diseño del Producto

Los componentes del producto y la documentación asociada, se implementan de

acuerdo a lo diseñado.

1. Se implementa el diseño (codificación, re-uso de código, prueba unitaria)

2. Se desarrolla y mantiene la documentación de usuario final.

Ejemplos de cumplimiento: Código Fuente, Pruebas Unitarias, Manuales de Usuario,

Guías de Usuario.

PA Integración de Productos (PI)

El propósito de “Integración de Productos” es integrar el producto a partir de sus

componentes, asegurar que el producto (como parte de la integración) funciona

correctamente, y entregar el producto.




Se cumple con las prácticas específicas de “Integración de Productos”, si se cumple las


o Preparar la Integración del Producto

Se lleva a cabo la preparación para la integración del producto.

Ejemplos de cumplimiento:

Reporte de Definición del Proyecto, Plan del Proyecto, Pruebas de Integración, Registro

de Pase a Producción

o Asegurar la Compatibilidad de Interfaces

Se verifica que las interfaces de los componentes del producto, tanto internas como

externas, son compatibles.

Ejemplos de cumplimiento: Revisión de Diseño Externo por los pares, Diseño Interno.

o Integrar los componentes del producto y entregar el producto

Se integran los componentes del producto verificados y se entrega el producto

integrado, verificado y validado.

Ejemplos de cumplimiento: Pruebas Unitarias, Ensamblaje de componentes de

productos, Pruebas Integración, Registros de pases a Producción.

PA Verificación (VER)

El propósito de “Verificación” es asegurar que los productos de trabajo seleccionados

responden a los requerimientos especificados.




Se cumple con las prácticas específicas de “Verificación”, si se cumple las siguientes

metas específicas:

o Seleccionar los productos a verificar

Se selecciona los productos que se van a verificar, los cuales deben estar definidos en

los planes.

Ejemplos de cumplimiento: Plan del Proyecto, Plan maestro de pruebas, Casos de

Prueba

o Preparar la Verificación, Realizar revisiones entre colegas (Peer reviews)

Se prepara la verificación de acuerdo a lo establecido en el PDP.

Ejemplos de cumplimiento: PDP, Revisión de Diseño Externo entre colegas, Revisión

de Requerimientos, Revisión de Documentación, Revisión de Código.

o Preparar la Verificación, Verificar los entregables.

Se verifica los entregables.

Ejemplos de cumplimiento: Pruebas Unitarias, Pruebas de Integración

PA Validación (VAL)

El propósito de “Validación” es demostrar que un producto o componente satisface su

uso pretendido, en el ambiente operativo planeado.




Se cumple con las prácticas específicas de “Validación”, si se cumple las siguientes

metas específicas:

o Definir los productos a validar, Preparar el ambiente de validación y criterios.

Ejemplos de cumplimiento: Estrategia de validación, Procedimiento de prueba de

software.

o Validar productos o componentes del producto.

Se validan los productos o componentes para asegurar que están listos para ser usados

en su ambiente productivo.

Ejemplos de cumplimiento: Pruebas de Aceptación.

PA Administración de Proyecto Integrado (IPM)

El propósito de “Administración del Proyecto Integrado” es establecer y administrar el

proyecto y la participación de los principales grupos involucrados de acuerdo a un

proceso definido e integrado que es adaptado a partir de los procesos estándar de la

organización.

Se cumple con las prácticas específicas de “Administración de Proyecto Integrado”, si

se cumple las siguientes metas específicas:

o Usar el PDP (Procesos Definidos para el Proyecto)

El proyecto se conduce usando un “Proceso Definido” que es adaptado a partir del

conjunto de procesos estándar de la organización según los criterios de parametrización

para el proyecto. (ver anexo IV)

1. Se establece un “Proceso Definido” para el proyecto según los criterios de

parametrización (ejemplos de parametrización pueden ser tamaño de proyecto,

costo del proyecto, etc)




2. Se usan los activos de la organización para planear las actividades de proyecto

(ejemplo: tiempo promedio estimado de revisión de documentación)

3. Se integran los planes (El plan general debe invocar a los otros planes)

4. Se maneja el proyecto usando los planes integrados (El gantt general invoca los

gantt de los otros planes)

5. Se contribuye con los activos de la organización (mejoras a procesos, rutinas

generales, etc)

Ejemplos de cumplimiento: Repositorio para almacenar los Proyectos, Plan del

Proyecto, Gantt general, Lecciones aprendidas, Mejoras de procesos.

o Coordinar y colaborar con los principales grupos involucrados

Se lleva a cabo la coordinación y colaboración con los principales grupos involucrados.

1. Se administra el involucramiento de los stakeholders (tareas de los stakeholders

en el proyecto y fechas de cumplimiento)

2. Se administra las dependencias (tareas cuya ejecución depende de la ejecución

de una tarea del stakeholder, e impacto en el proyecto)

3. Se resuelve los problemas de coordinación

Ejemplos de cumplimiento: Plan y seguimiento de Stakeholders, Seguimiento de las

dependencias, Registro de problemas (Log), Reporte de Seguimiento de Proyectos.

PA Administración de Riesgos (RiskM)

El propósito de “Administración de Riesgos” es identificar potenciales problemas antes

de que ocurran, de manera que las actividades de manejo de riesgos podrían ser

planeadas cuando sea necesario a lo largo del ciclo de vida del proyecto para alivianar

impactos adversos en los objetivos a alcanzar.

Se cumple con las prácticas específicas de “Administración de Riesgos”, si se cumple

las siguientes metas específicas:




o Preparar para el manejo de Riesgos

Se lleva a cabo la preparación del manejo de riesgos.

1. Se determina las fuentes de riesgos y sus categorías (lista de posibles riesgos)

2. Se define los parámetros de riesgos (impacto)

3. Se establece la estrategias de administrar un riesgo (Revisión periódica hasta que

se mitigue o desaparezca)

Ejemplo de cumplimiento: Evaluación de riesgos, Plan del proyecto que direcciona a la

ejecución de evaluación de riesgos.

o Identificar y analizar Riesgos

Los riesgos son identificados y analizados para determinar su importancia relativa.

1. Se identifica riesgos (de la lista de posibles riesgos)

2. Se evalúa, categoriza y prioriza riesgos

Ejemplo de cumplimiento: Evaluación de riesgos

o Disminuir riesgos

Los riesgos se manejan y disminuyen para reducir impactos adversos en los objetivos a

alcanzar.

1. Se desarrolla planes de mitigación de riesgos

2. Se implementa planes de mitigación de riesgos

Ejemplo de cumplimiento: Plan de Administración de riesgos que incluyen plan de

mitigación de riesgos.




PA Análisis de Decisión y Resolución (DAR)

El propósito de “Análisis de Decisión y Resolución” es analizar decisiones usando un

proceso de evaluación formal, que evalúa las alternativas identificadas contra los

criterios establecidos.

Se cumple con las prácticas específicas de “Análisis de Decisión y Resolución”, si se


o Evaluar alternativas

Las decisiones se basan en la evaluación de alternativas usando criterios establecidos.

1. Se establecen guías para Análisis de decisiones

2. Se establecen criterios de evaluación

3. Se identifican alternativas de solución

4. Se seleccionan métodos de evaluación

5. Se evalúan alternativas

6. Se selecciona la solución

Ejemplos de cumplimiento: Guía de Registro y Análisis de decisiones, Registro de

Análisis de Decisiones.

o NIVEL 4

PA Administración Cuantitativa del proyecto (QPM)

El propósito de “Administración Cuantitativa del proyecto” es administrar

cuantitativamente el conjunto de procesos definidos para el proyecto, a fin de alcanzar

la calidad establecida para el proyecto y los objetivos de rendimiento del proceso.

Se cumple con las prácticas específicas de “Administración Cuantitativa del proyecto”,

si se cumple las siguientes metas específicas:




o Administrar cuantitativamente el proyecto.

El proyecto es cuantitativamente administrado teniendo en cuenta los objetivos de

calidad y rendimiento del proceso.

1. Se establecen los objetivos del proyecto (cumplir con los niveles de servicio,

satisfacción del cliente, calidad de productos, etc).

2. Se define el criterio para establecer el “Proceso definido” (menor impacto en el

cliente, elevar nivel de satisfacción, etc).

3. Se seleccionan los sub procesos que serán administrados cuantitativamente

(estimaciones, planificaciones, pruebas, etc).

4. Se administra el rendimiento del proyecto.

Ejemplos de cumplimiento: Plan de Calidad, PDP, Métricas básicas, Reporte de

métricas calculadas (predicciones).

o Administrar estadísticamente el rendimiento de los subprocesos

El rendimiento de los subprocesos seleccionados desde el PDP es administrado

estadísticamente.

1. Se seleccionan mediciones y técnicas analíticas (ejemplo: tasa de desvío en

estimaciones menor que 8%, etc).

2. Se aplican métodos estadísticos para obtene r las variaciones.

3. Se monitorea el rendimiento de los sub procesos seleccionados (ejm: tasa de

desvío en estimaciones del mes fue mayor que el esperado. 10% obtenido vs el

8% esperado).

4. Se almacena la data manejada estadísticamente.

Ejemplos de cumplimiento: Métricas básicas, Métricas Calculadas, Reporte Estadístico,

Reporte de Causas de Desvíos, Repositorio de datos históricos.




o NIVEL 5

PA: Análisis de Causas y Resolución (CAR)

El propósito de la PA CAR: Análisis de Causas y Resolución es identificar las causas de

defectos y otros problemas y tomar acción para prevenirlos de ocurrencias futuras.

Se cumple con las prácticas específicas de “Análisis de Causas y Resolución”, si se


o Determinar las causas de los defectos

1. Se selecciona la data defectuosa para análisis (ejemplos: defectos encontrados en

las pruebas, en las revisiones entre pares, problemas de capacidad de procesos,

problemas de telecomunicaciones, etc.)

2. Se analiza las causas raíces y se propone acciones

o Administrar las causas raíces de defectos para prevenir su ocurrencia futura.

1. Se implementa las acciones propuestas

2. Se evalúa el efecto de los cambios

3. Se almacena un registro con el análisis de causas y resolución

PA: Innovación Organizacional y Entrega (OID)

El propósito de la PA OID: Innovación Organizacional y Entrega es seleccionar e

implementar las mejoras innovadoras en forma incremental para optimizar las

mediciones derivadas de las tecnologías y de los procesos de la Organización. Las

mejoras se basan en los objetivos de calidad y de rendimiento (performance) de

procesos, los cuales son derivados de los objetivos de la Organización.




Se cumple con las prácticas específicas de “Innovación Organizacional y Entrega” si se


o Seleccionar mejoras.

Se seleccionan las mejoras de procesos y de tecnología que contribuyen a alcanzar los

objetivos de calidad y performance de los procesos.

1. Se recolectan y analizan propuestas de mejoras.

2. Se identifican y analizan las mejoras innovadoras.

3. Se realizan pilotos de las mejoras.

4. Se seleccionan las mejoras a implementar.

o Implementar mejoras

Se implementan y se miden en forma sistemática y continua, las mejoras a las

tecnologías y a los procesos de la Organización.

1. Se planifica la implementación.

2. Se administra la implementación.

3. Se mide los efectos de las mejoras.

ANEXO IV

FORMATOS A continuación se muestran algunos ejemplos de formatos que se pueden utilizar

durante el desarrollo de Software. Cada Proyecto puede definir sus propios formatos, sin

embargo debido a que los procesos deben estar estandarizados, es necesario que todos

los proyectos de la organización utilicen los mismos formatos.

Relación de formatos:




1. Proceso de Definición del Proyecto – PDP.

2. Plan de Administración de Datos.

3. Plan de Administración de Riesgos.

4. Cambio de Requerimientos.

5. Registros DAR.

6. Verificación de Código.

7. Casos de Prueba.

8. Reporte de Mediciones.

9. Reporte de Estado del Proyecto.

10. Plan de Involucramiento de los Stakeholders y Monitoreo.

El proceso de Definición del Proyecto es el gran proceso que reúne y relaciona en un

solo proceso, las herramientas, modelos, formatos, procedimientos, con las que se

cumple el CMMI. Puede aplicarse a toda una organización como a un proyecto

específico. A continuación se describe los campos mínimos que debe tener un PDP:

o Procedimiento Original : Nombre del procedimiento que soporta la PA tal como

ha sido definido para la empresa.

FORMATO: Proceso de Definición del Proyecto - PDP

Este formato pertenece a la PA Administración Integrada del Proyecto: IPM

PROCESO DE DEFINICIÓN DEL PROYECTO - PDP

PROYECTO: nombre del proyecto FECHA: dd/mm/aaaa

Proc. original Requiere desvío SI/NO

Atributo de parametri-zación

Alcance de implementación

Identificación del desvío

Proc. adoptado

Evidencia de cumplimiento de la PA

RM y RD




Procedimiento de Administración y Desarrollo de requerimientos

SI Todo el documento

Modificar el procedimiento para que cumpla con las prácticas de RM y RD de CMMI

Hay desvío porque este procedimiento ha venido siendo usado con los Usuarios

Procedimiento para la Gestión y Desarrollo de Requerimientos

1.-Requerimiento de Usuario. 2.-Informe de atención del requerimiento

VAL Procedimiento de validación

NO 1.-Documento de alcance 2.-Diseño externo 3.-Formato de casos de prueba

o Requiere desvío (SI/No): Identificador de desvío respecto al uso del

procedimiento original o de alguno de sus componentes. Se coloca NO, si no se

va a utilizar estrictamente el procedimiento original .

o Atributo de parametrización: Parte del documento que será modificado.

o Alcance de implementación: Cómo se implantará la parte modificada, la misma

que también debe cumplir con CMMI

o Razón para el desvío: Causa por la que no se implementará el procedimiento

original.

o Procedimiento adoptado: Nombre del nuevo procedimiento.

o Evidencias de cumplimiento: Formatos, metodologías, herramientas. Procesos y

procedimientos que contienen las evidencias de cumplimiento con cada una de

las prácticas generales y específicas de las PAs.

El PDP así como los procedimientos o sus componentes que tienen desvío deben ser

aprobados por el Grupo de Procesos para verificar que los mismos cumplan con CMMI.

Todos los documentos deben estar anexos al PDP.

FORMATO: Plan de Administración de datos




Este formato pertenece a la PA: Monitoreo y Control – PMC. Se utiliza para controlar

que los documentos se hayan construído según los estándares y que hayan sido

almacenado en el lugar adecuado.

PLAN DE ADMINISTRACIÓN DE DATOS


Nombre del documento

Descripción Responsable

Ubicación Nivel de seguridad

Tipo de documento

Es entrega

ble

Está bajo el control

de la configuración

Registro DAR

Documento de Análisis de decisión y Resolución para riesgos que se presenten

Analista funcional

Base de datos del proyecto

Medio: Modo “actualización” para coordinadores y “lectura” para todo el equipo

Electrónico SI NO

Diseño externo

Diseño externo

Analista


Bajo: Modo “actualización” para todo el equipo

Electrónico SI SI

Estrategia de pruebas

Estrategia de pruebas

Jefe de proyecto


Alto: Modo “actualización” Para el jefe de proyecto y “lectura” para todo el equipo

Electrónico NO SI




FORMATO: Plan de Administración de riesgos

Este plan pertenece a la PA Administración de riesgos. Muestra los riesgos ordenados

según el impacto en el proyecto. Para todos los riesgos excepcionales, altos y medios

preparar un plan para mitigar los riesgos, y para los riesgos excepcionales y altos hacer

también un plan de contingencia. A continuación el formato llenado con un ejemplo.

PLAN DE ADMINISTRACIÓN DE RIESGOS


Riesgos /Plan de

mitigación/

Plan de contingencia

Esfuerzo

Costo

Responsable Fecha

objetivo

Estado

EXCEPCIONALES

Riesgo: El número de

requerimientos pendientes es

mayor que el número

esperado

30,000

nuevos

soles

Jefe de

proyecto

31/07/05 En proceso

Plan de mitigación: Acordar con el cliente elevar el valor del indicador “número de

requerimientos pendientes” a un número más real.

Plan de contingencia: Contratar 2 personas por 5 meses para reducir el número de

requerimientos

MEDIO

Riesgo: El reporte “nombre

del reporte” no se acabará a

tiempo

Sin costo Analista 30/06/05 Cerrado

Plan de mitigación: Revisar la ruta crítica y actualizar el plan




FORMATO : Cambio de Requerimientos

Este formato pertenece a la PA Administración de Requerimientos. Se usa cuando se

produce un cambio durante la ejecución del proyecto que altera el alcance, el schedule o

el costo.

FORMATO DE CAMBIO DE REQUERIMIENTOS


SECCIÓN I . Descripción del cambio

Requerimiento impactado:

Descripción del cambio

Requerido por: Nombre: Firma:

SECCIÓN II . Evaluación del cambio

Costo estimado Tiempo estimado: Evaluado por:

Solución propuesta:

Sección del contrato que modifica:

SECCIÓN III . APROBADO ( ) RECHAZADO ( )

Nombre: Firma: Fecha:



FORMATO: Registro Dar

Este formato pertenece a la PA: Análisis de Decisión y Resolución. Se utiliza cuando

hay necesidad de tomar decisiones para elegir entre más de una alternativa por algún

problema que puede impactar en los costos, schedule o alcance.




REGISTRO DAR


Información general

Problema N°: xxxx

Breve descripción del problema que requiere un análisis de decisión:

Objetivos, alcance y requerimientos del proceso de evaluación formal:

Criterios de evaluación

Lista de todos los criterios

potenciales identificados,

disponibles para utilizar

en la evaluación de

soluciones alternativas

Escala de ranking Criterio seleccionado o

rechazado para usar en la

evaluación

Fundamento para la

selección o el rechazo de

cada criterio

Soluciones alternativa y resultados de evaluación

Alcance de las soluciones alternativas propuestas que

pueden conducir el problema

Resultados de la evaluación, incluyendo el fundamento

para la selección o el rechazo de cada solución

Métodos de evaluación

Descripción del método / métodos de evaluación

seleccionados

Descripción de las medidas usadas para el método de

evaluación (costo, schedule, desempeño, riesgos, etc)

Solución recomendada

Solución recomendada seleccionada para el alcance de

las alternativas y el fundamento para la selección de las

mismas como la “mejor” de todas las soluciones

Riesgos potenciales asociados con la implementación de

la solución recomendada

Mediciones

Medición Estimado Actual

Esfuerzo del proceso (horas / persona)

Duración del proceso (días)

Costo para ejecutar la evaluación (Soles)

Participantes en la evaluación

Nombre del participante Rol Tiempo dedicado (%)




FORMATO: Verificación de código.

Este formato pertenece a la PA de Verificación. Se utiliza para asegurarse que el código

ha sido construido en base al Diseño y si cumple con los estándares definidos. En forma

similar se pueden construir formatos para verificaciones de Requerimientos, Diseño,

Documentación, etc.

FORMATO DE VERIFICACIÓN DE CODIGO


Autor: Tiempo de preparación (horas):

Nombre del Inspector: Tiempo utilizado en la inspección(horas):

Otros participantes: Nro. de defectos encontrados:

Tiempo de corrección(horas):

Nombre del programa: Nro.lineas de código del programa revisado:

DEFECTOS ENCONTRADOS DURANTE LA REVISIÓN

Resúmen de los defectos encontrados. Están identificados como Aceptado = NO

Descripción del defecto Descripción de la corrección

Fase del ciclo de vida en la que se ingresó el defecto

Tipo de severidad

Fecha de resolución

Criterio de revisión del código (ejemplos para programación

estructurada)

Aceptado

(SI/NO)

Comentarios

Se siguen los estándares de codificación?

El código está de acuerdo con el diseño?

Se inicializaron las variables?

Se ha evitado la asignación de valores a las variables?

Cada rutina utiliza una tarea bien definida?

Es el código re-usable

Contiene manejo de errores?

Se usa los estándares gráficos definidos? (color de pantalla,

botones, niveles de navegación)




FORMATO: Casos de Prueba.

Este formato puede utilizarse para las pruebas unitarias, pruebas de integración, pruebas

del sistema, pruebas de aceptación. Para el caso de pruebas de aceptación pertenece a la

PA de Validación, en todos los otros casos pertenece a la PA de Verificación.

CASOS DE PRUEBA


Requerimiento N° Nombre del Proceso: Prueba N°

Propietario del Proceso: Responsable de prueba:

Equipo de Pruebas:

Tiempo invertido ( * = horas / persona)

Preparación (*)

Prueba (*)

Corrección(*)

Describir aquí en una o más líneas los casos de prueba desde la perspectiva del usuario para que los

lectores entiendan el propósito de este documento

Caso N°

Descripción del caso

Condiciones de prueba

Resultados esperados

Resultados obtenidos

Acciones (1)

Firma ejecutor de prueba

1

2

3

4

5

6

Notas:

(1) Describe la acción luego de detectarse un resultado no esperado




FORMATO: Reporte de Mediciones

Este formato pertenece a la PA: Mediciones y Análisis. Por cada PA se deben reportar

las métricas básicas.

REPORTE DE MEDICIONES

PROYECTO: nombre del proyecto FECHA:

dd/mm/aaaa

Relación de parámetros Unidad de reporte Valor esperado Valor obtenido PA: Verificación

Productos verificados cantidad 4 5

Esfuerzo consumido Horas 10 15

Defectos encontrados cantidad 1 2

Esfuerzo en corrección

de defectos

Horas 4 6

PA Planeamiento del Proyecto Requerimientos

cumplidos en fecha

cantidad 25 30

Nro. total de

requerimientos

atendidos en el mes

cantidad 32 34




FORMATO: Reporte de Estado del Proyecto

Este formato se utiliza para reportar el avance del proyecto. Pertenece a la PA

Monitoreo y Control. Se usa una lámina para reportar el avance de cada PA

REPORTE DE ESTADO DEL PROYECTO


PA: Control de la Configuración

Actividad Fechas planeadas Fechas ejecutadas

Crear el plan SCM 12/01/05 15/01/05

Definir el baseline 19/01/05 21/01/05

Generar reporte de estado 30/05/05 29/05/05

Ejecutar auditoría al baseline 25/07/05

Actividad Horas planeadas Horas ejecutadas

Esfuerzo en tareas de

administración de la

configuración

29 24.5




FORMATO: Plan de Involucramiento de Stakeholders y Monitoreo

Este formato se utiliza para definir las actividades de los stakeholders con relación a

cada una de las PAs, y monitorear los avances.

PLAN DE INVOLUCRAMIENTO DE STAKEHOLDERS Y MONITOREO


PA: Planeamiento de Proyecto

Stakeholder 1 Stakeholder 2 Stakeholder 3

Stakeholder 4

Stakeholder 5

Revisar el documento de entendimiento

Aprobar el documento de entendimiento

Fecha: 15/06/05

Se revisó el documento de entendimiento

Fecha: 20/06/05

Se aprobó el documento de entendimiento

PA: Métricas y Análisis

Stakeholder 1 Stakeholder 2 Stakeholder 3

Stakeholder 4

Stakeholder 5

Recibe el “Reporte de Estado Mensual” con el resultado del período

Recibe los reportes de niveles de servicio alcanzados en el mes

Fecha 1 Se envió el “Reporte de Estado mensual”

Se envió los reportes de niveles de servicio

Fecha 2 Se envió el “Reporte de Estado mensual”

Se envió los reportes de niveles de servicio

universidad nacional mayor de san...

Documents