Implementación de 4 Áreas de Proceso Del Modelo de Calidad CMMI: Gestión y Desarrollo de Requerimientos, Validación, y Verificación

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERÍA
CARRERA DE INGENIERÍA DE SISTEMAS DE INFORMACIÓN
Implementación de 4 Áreas de Proceso del modelo de

calidad CMMI: Gestión y Desarrollo de
Requerimientos, Validación, y Verificación
PROYECTO PROFESIONAL
Para optar el título de:
INGENIERO DE SISTEMAS DE INFORMACIÓN
AUTOR
ERICK DANIEL NAKAMA ARAKAKI
ASESOR: Pedro Cruz Hernández
Lima, Perú
2009
i
DEDICATORIA
El presente proyecto está dedicado a mi familia que gracias a su apoyo incondicional me

permitieron adquirir mayores conocimientos y cumplir mis metas profesionales.
ii
RESUMEN
El presente proyecto se basa en la aplicación del modelo de mejora continua de procesos

en los talleres y proyectos de la carrera de Ingeniería de Software de la Universidad
Peruana de Ciencias Aplicadas UPC que basan el desarrollo de sus proyectos en la
metodología RUP.
El modelo de calidad en referencia es el CMMI (Capability Maturity Model

Integration), cuyo propósito es proveer una guía de las mejores prácticas para mejorar
los procesos de una organización, en cuanto al desarrollo, adquisición y mantenimiento
de productos software y servicios.
Se describe el proceso seguido para obtener un diagnóstico inicial de la situación de los

talleres y proyectos con respecto a los lineamientos establecidos por el modelo CMMI,
el cual se obtuvo haciendo uso de la metodología de evaluación SCAMPI (Standard
CMMI Appraisal Method for Process Improvement).
Como segundo paso se describe el proceso de detallado del desarrollo de las soluciones
para cubrir las brechas de cumplimiento de los lineamientos identificada en la
evaluación SCAMPI.
Posteriormente se detalla el proceso de implementación de las soluciones en proyectos

denominados pilotos, el seguimiento correspondiente en el cumplimiento de las
actividades y utilización de las soluciones
iii
Finalmente, se presenta un análisis de los resultados obtenidos luego del proceso de
implementación describiendo las mejoras alcanzadas en el cumplimiento de los
lineamientos del modelo que, si se mantienen en el tiempo, se conseguiría resultados
visibles de mejora en los productos finales de los proyectos.
iv
ÍNDICE DE CONTENIDOS
RESUMEN ...................................................................................................................... iii

INTRODUCCIÓN ............................................................................................................ 1
CAPÍTULO 1: LA EMPRESA OBJETIVO .................................................................... 4
1.1. Sistemas y Software Consultores ..................................................................... 4
1.2. Justificación del inicio del proyecto ................................................................. 7
CAPÍTULO 2: MARCO TEÓRICO .............................................................................. 11
2.1. ¿Qué es calidad? ............................................................................................. 11
2.2. ¿Qué es el CMMI? .......................................................................................... 12
2.2.1 Introducción ................................................................................................... 12
2.2.2 Estructura ....................................................................................................... 13
2.2.3 Representaciones y niveles ............................................................................ 15
2.2.4 Categorías y Áreas de Procesos ..................................................................... 18
2.3. ¿Qué es el SCAMPI? ...................................................................................... 20
2.3.1 Descripción de la metodología de evaluación ............................................... 20
2.3.2 Clases de SCAMPI ........................................................................................ 21
2.3.3 Caracterización de las prácticas específicas y genéricas ............................... 24
2.3.4 Caracterización de áreas de procesos ............................................................ 25
CAPÍTULO 3: ESTUDIO DEL ESTADO ACTUAL DE LA EMPRESA ................... 27
3.1. Planificación y preparación de la evaluación ................................................. 28
3.1.1. Identificación de requerimientos, objetivos y alcance de la evaluación ..... 28
3.2.2 Identificación de recursos y desarrollo del plan de ejecución ....................... 30
3.2. Ejecución y conducción de la evaluación ....................................................... 35
3.3. Análisis de resultados de la evaluación .......................................................... 36
3.3.1 Gestión de Requerimientos (REQM) ............................................................ 37
3.3.2 Desarrollo de Requerimientos (RD) .............................................................. 38
3.3.3 Verificación (VER)........................................................................................ 40
3.3.4 Validación (VAL) .......................................................................................... 41
CAPÍTULO 4: DESARROLLO DE PROPUESTAS DE SOLUCIÓN ......................... 43
4.1. Metodología .................................................................................................... 43
v
4.2. Propuestas de Solución Aprobadas................................................................. 45
4.3. Recursos Tecnológicos ................................................................................... 46
CAPÍTULO 5: PROCESO DE IMPLEMENTACIÓN .................................................. 49
5.1. Preparación ..................................................................................................... 49
5.1.1. Designación de responsables por Área de Proceso. ................................... 49
5.1.2. Designación de Proyectos Piloto ................................................................ 50
5.1.3. Reuniones con miembros del directorio y responsables de las Áreas de
Proceso ................................................................................................................... 51
5.1.4. Elaboración de materiales de inducción y capacitación. ............................ 52
5.2. Inducción y Capacitación ............................................................................... 53
5.3. Implementación y Seguimiento ...................................................................... 54
CAPÍTULO 6: ANÁLISIS DE RESULTADOS ............................................................ 57
6.1. Gestión de Requerimientos (REQM) ............................................................. 58
6.2. Desarrollo de Requerimientos (RD) ............................................................... 60
6.3. Verificación (VER)......................................................................................... 62
6.4. Validación (VAL) ........................................................................................... 65
CONCLUSIONES .......................................................................................................... 68
RECOMENDACIONES ................................................................................................ 71
BIBLIOGRAFÍA ............................................................................................................ 73
GLOSARIO DE TÉRMINOS ........................................................................................ 75
vi
Implementación de 4 Áreas de Proceso del modelo de calidad CMMI: Gestión y Desarrollo de Requerimientos, Validación, y
Verificación
INTRODUCCIÓN
El Modelo Integrado de Madurez de la Capacidad (CMMI – Capability Maturity Model

Integration) es un modelo de calidad para el desarrollo, mantenimiento de software, y
gestión y desarrollo de proyectos. Su enfoque está basado en procesos y mide el nivel
de capacidad de cada uno de éstos, que tomados en conjunto, determinan el nivel de
madurez de la organización.
El CMMI fue desarrollado por el Instituto de Ingeniería del Software de la Universidad

de Carnegie Mellon (Software Engineering Institute - SEI), promovido y patrocinado
por el Departamento de Defensa de los Estados Unidos.
El CMMI surge a partir de la integración de varios Modelos de Madurez de la

Capacidad (CMM) desarrollados en la década de los 90´s bajo la dirección del
Departamento de Defensa de los Estados Unidos ante la necesidad de solucionar los
problemas de calidad en el desarrollo y gestión de proyectos de software que tenían las
empresas proveedoras que le brindaban sus servicios.
El presente estudio realizado tiene por objetivo emplear la metodología definida en el

modelo de calidad CMMI para llevar a cabo la implementación de cuatro (4) Áreas de
Procesos en proyectos piloto de la empresa virtual “Sistemas y Software Consultores”
conformada por los talleres y proyectos de software y sistemas de información, taller de
desarrollo y pruebas, taller de desarrollo, y el directorio o comité de proyectos de la
carrera de Ingeniería de Software de la Universidad Peruana de Ciencias Aplicadas
(UPC).
1
Las Áreas de Proceso incluidas en el estudio son:
 Gestión de Requerimientos (REQM) – Nivel 2
 Desarrollo de Requerimientos (RD) – Nivel 3
 Verificación (VER) – Nivel 3
 Validación (VAL) – Nivel 3
De esta manera, se busca mejorar y optimizar las actividades de desarrollo de software,

enfocadas en procesos, para lograr productos finales con los lineamientos de calidad
empleadas a nivel mundial.
El capítulo 1 del presente documento proporciona una descripción del negocio en el que
se realizará la implementación de las 4 Áreas de Proceso seleccionadas del modelo de
calidad CMMI; así mismo, proporciona una justificación del inicio del estudio.
El capítulo 2 contiene el marco teórico detallado en la que se incluye el modelo de

calidad CMMI y el método de evaluación SCAMPI, ambos desarrollados por el SEI.
El capítulo 3 contiene el estudio de la situación actual del negocio objetivo, detalla el

proceso de evaluación, su estrategia y obtención de resultados.
En el capítulo 4 se detalla el proceso realizado para desarrollar las soluciones requeridas

luego de realizar un análisis de los resultados obtenidos de la evaluación de la situación
actual.
2
Verificación
En el capítulo 5 se describe la implementación de las soluciones desarrolladas en

proyectos piloto y los resultados finales posteriores a la implementación
3
CAPÍTULO 1: LA EMPRESA OBJETIVO
En el presente capítulo se define la empresa objetivo y la justificación de inicio del

proyecto.
1.1. Sistemas y Software Consultores
La Universidad Peruana de Ciencias Aplicadas UPC, primera universidad global del

Perú creada mediante Ley 26276 el 5 de enero de 1994 y cuya definición de su misión
es la de formar líderes íntegros y realizar propuestas innovadoras para impulsar la
creación de una nueva realidad, cuenta con dos carreras profesionales enmarcadas en el
campo de la computación: Ingeniería de Software e Ingeniería de Sistemas de
Información.
La carrera de Ingeniería de Software es una de las carreras profesionales enmarcadas en

el campo de la computación dentro de la facultad de Ingeniería de la Universidad
Peruana de Ciencias Aplicadas. La carrera cuenta con una acreditación nacional,
otorgada en Enero del 2008, por parte del Instituto de Calidad y Acreditación de
Carreras Profesionales de Ingeniería y Tecnología (ICACIT) según los criterios del
Accreditation Board for Engineering and Technology (ABET).
La carrera de Ingeniería de Software tiene como misión:
"Formar ingenieros de software profesionales y competentes en el

emprendimiento y la gestión de proyectos enmarcados en el ciclo de vida
del software, diseño y construcción de productos software de probada
calidad y basados en estándares requeridos por el negocio y la profesión,
4
Verificación
con una sólida base en principios de ingeniería y en tendencias en

computación".1
El aprendizaje está basado en proyectos y con competencias y perfiles profesionales

recomendados por organizaciones internacionales como ABET, IEEE-Computer
Society y ACM.
En este sentido, el alumno interacciona con cursos de la especialidad desde el primer

ciclo empleando modernas herramientas CASE y posteriormente formando parte de los
talleres y proyectos dentro del marco de la empresa virtual “Sistemas y Software
Consultores” que le permite poner en práctica todos los conocimientos adquiridos en un
proyecto profesional.
La carrera de Ingeniería de Sistemas de Información es la segunda carrera profesional

enmarcada en el campo de la computación dentro de la facultad de Ingeniería.
Tiene como objetivo formar ingenieros capaces de diseñar y gestionar sistemas de

información para cualquier tipo de empresa. Así como seleccionar e integrar las
distintas tecnologías y herramientas de información para lograr los fines estratégicos de
las unidades de negocio en las empresas. El alumno trabaja con herramientas ERP,
CRM, SCM, e-business y business intelligence.2
Los alumnos de las carreras de Ingeniería de Software y Sistemas de Información dan

inicio al desarrollo de un proyecto profesional en Taller de Proyectos (8vo ciclo)
continuando con su desarrollo en Proyecto 1 y Proyecto 2 (9no y 10mo ciclo
1
http://www.upc.edu.pe/0/modulos/JER/JER_Interna.aspx?ARE=0&PFL=13&JER=526
2
http://www.upc.edu.pe/0/modulos/JER/JER_Interna.aspx?ARE=0&PFL=13&JER=551
5
respectivamente), bajo el marco de una empresa virtual denominada “Sistemas y
Software Consultores” (http://sys.computacion.upc.edu.pe/sys).
La empresa virtual “Sistemas y Software Consultores” está estructurada por los alumnos
de los cursos de Taller de Proyectos, Proyecto1, y Proyecto2; un directorio conformado
por los ingenieros Ludvik Medic, Ilver Anache, y Rosario Villalta; un gerente general, y
jefes de línea de productos. A su vez, cuenta con dos áreas de soporte: un área de
pruebas de software, conformado por los alumnos de Taller de Desarrollo y Pruebas,
para asegurar la calidad de los productos intermedios y finales, y un área de desarrollo,
conformado por los alumnos de Taller de Desarrollo, encargada de prestar servicios de
programación a los proyectos de software.
El directorio es un grupo encargada de aprobar la cartera de proyectos de Ingeniería

Software e Ingenierías de Sistemas de Información definidos y propuestos por los
comités de cada línea de negocio; realizar un seguimiento a los proyectos mediante
sustentaciones planificadas a lo largo del ciclo de vida de los proyectos dividido en tres
etapas (Taller de proyectos, Proyecto 1, y Proyecto 2); y determinar la finalización y
cierre de los mismos.
Figura 1.1 – Organigrama de la empresa virtual “Sistemas y Software Consultores
6
Verificación
Fuente: Elaboración propia
1.2. Justificación del inicio del proyecto
El proceso evolutivo del desarrollo de software debe ser gestionado bajo actividades
monitoreadas y medidas que aseguren que los resultados que se esperan lograr sean
alcanzados con el menor costo posible y dentro de los tiempos establecidos y acordados
con el cliente. De esta manera, el desarrollo de software se convierte en una actividad de
ingeniería y no en un conjunto de actividades sin rumbo y poco productivas que, en
gran porcentaje, terminan en un producto incompleto, entregado fuera de tiempo y/o con
defectos sin solucionar.
Todo ello conlleva a implementar la metodología de calidad CMMI, aceptada como uno
de los mejores estándares a seguir para el proceso de desarrollo y mantenimiento de
software, en la empresa virtual “Sistemas y Software Consultores”.
7
Por otro lado, el desarrollo de software bajo el modelo de calidad CMMI permitirá a los
futuros profesionales de ingeniería de software y de ingeniería de sistemas de
información entrar al mercado competitivo, familiarizados con el estándar adoptado por
las más grandes empresas del mundo en el desarrollo de software y con muchas
empresas del mercado peruano y latino que apuestan por producir software de calidad y
así alcanzar ventajas competitivas dentro de sus sectores de negocio.
Como primer paso, se realizaron reuniones con los alumnos y profesores encargados de
supervisar los proyectos de Ingeniería de Software para identificar las dificultades y
problemas que se presentan al inicio, durante y fin del desarrollo de los proyectos.
Luego del análisis de los temas tratados, se identificaron los siguientes problemas, que
dieron inicio al proyecto de implementación de ciertas Áreas de Proceso del modelo
CMMI para optimizar y asegurar un producto final acorde a los requerimientos y
calidad esperada por el cliente:
 Ambigüedad en la definición de proyectos: Los proyectos propuestos a los analistas

para su desarrollo en taller de proyectos no tienen una buena definición de los
requerimientos iniciales. Esto origina incertidumbre en los analistas sobre los
objetivos y el propósito del proyecto a iniciar y muchas veces la insatisfacción del
cliente. Es así, que en ocasiones se ha tenido que replantear el propósito del
proyecto.
 Inconsistencia y trazabilidad entre los requerimientos iniciales y los planes: Los

requerimientos iniciales no guardan relación con los planes elaborados por los
analistas de los diferentes proyectos.
 Poca eficiencia en las actividades de verificación y validación: En ciertas etapas del

desarrollo de software no se les dedica el esfuerzo adecuado para lograr un producto
8
Verificación
desarrollado bajo ciertos estándares de calidad. Es así que en algunos casos, los
productos de software presentan defectos en su funcionamiento que no fueron
detectados en el momento indicado, lo cual genera un retraso en los tiempos de
entrega del producto. En otros casos, el producto no cumple con las exigencias y
necesidades del cliente.
 No existe una definición formal de los procesos.
De acuerdo a la problemática identificada, y luego de una evaluación y priorización de

las Áreas de Proceso definidas en el modelo CMMI, mediante reuniones con miembros
del Directorio de Proyectos, se determinó la implementación de un Área de Proceso del
nivel 2 y tres Áreas de Proceso del nivel 3 en la empresa virtual “Sistemas y Software
Consultores” para dar solución a los problemas iniciales identificados. Las Áreas de
Proceso seleccionadas son las siguientes:
 Gestión de Requerimientos (REQM): Área de Proceso enmarcada dentro del nivel 2

del modelo CMMI, tiene como propósito gestionar los requerimientos del producto
y componentes del producto e identificar inconsistencias entre los requerimientos y
el plan y workproducts del proyecto.
 Desarrollo de Requerimientos (RD): Área de Proceso perteneciente al nivel 3 del

modelo CMMI cuyo propósito es producir y analizar los requerimientos del cliente,
producto y componentes del producto.
 Verificación (VER): Área de Proceso perteneciente al nivel 3 del modelo CMMI,

incluye las fases de preparación, ejecución, e identificación de las acciones
correctivas. Las actividades de verificación se realizan sobre el producto final y
productos intermedios para asegurar que los productos cumplen con los
9
requerimientos solicitados por el cliente e identificar y corregir defectos en el
momento apropiado dentro del ciclo de desarrollo del software.
 Validación (VAL): Área de Proceso perteneciente al nivel 3 del modelo CMMI,

tiene como propósito demostrar que el producto o componente del producto cumple
con su propósito cuando es instalado en el ambiente destinado. Asegura que el
producto desarrollado es el correcto y el requerido por el cliente.
Dentro de los beneficios esperados con la implementación de las Áreas de Proceso

seleccionadas se encuentran:
 Mejorar la gestión y desarrollo de los requerimientos.
 Mejorar el cumplimiento del plan y cronograma de los proyectos.
 Mejorar la calidad y reducción de defectos.
 Mejorar la satisfacción del cliente.
 Incrementar la productividad.
10
Verificación
CAPÍTULO 2: MARCO TEÓRICO
En el presente capítulo se presentan algunas definiciones de calidad y se explica en

forma detallada el modelo CMMI y el método de evaluación SCAMPI.
2.1. ¿Qué es calidad?
Existen muchas definiciones propuestas por diversos especialistas profesionales en el

tema de calidad.
J.M. Juran, figura renombrada en el control de calidad, define calidad como la

“adecuación del producto al uso”. Por su parte, E. Deming, reconocido por su aporte en
el desarrollo y crecimiento de Japón, define calidad como la “conformidad con
requisitos y confiabilidad en el funcionamiento”. Para P. Crosby, la calidad es cero
defectos. P Drucker sostiene que un buen producto no es el que cumple con una
determinada especificación, sino el que es bien recibido por el cliente.
El Organismo Internacional de Normalización (ISO) define calidad en la norma ISO

8402:1994 como “la totalidad de características o propiedades de un producto o servicio
que le confieren la aptitud para satisfacer las necesidades explícitas e implícitas de sus
clientes”.
Por otro lado, acercándonos a definiciones con mayor relación a la ingeniería, la IEEE
(Institute of Electrical and Electronics Engineers) define calidad como “El grado en que
11
un sistema, componente o proceso cumple con los requerimientos especificados, y
necesidades o expectativas del cliente o usuario”.
En el marco de la calidad del software, Pressman autoridad reconocida en la mejora de

procesos de software y en tecnologías de Ingeniería de software define calidad como la
“Concordancia del software producido con los requisitos funcionales y de rendimiento
explícitamente establecidos, con los estándares de desarrollo explícitamente
documentados y con las características implícitas que se espera de todo software
desarrollado profesionalmente”.3
2.2. ¿Qué es el CMMI?
2.2.1 Introducción
El Modelo Integrado de Madurez de la Capacidad (Capability Maturity Model

Integration - CMMI) es un modelo de mejora continua, enfocado en procesos, que
incluye las mejores prácticas para el desarrollo y mantenimiento de software,
actividades relacionadas a la administración de proyectos y mejora de procesos.
El CMMI fue desarrollado por el Instituto de Ingeniería del Software de la Universidad

Carnegie Mellon (Software Engineering Institute - SEI), promovido y patrocinado por
el Departamento de Defensa de los Estados Unidos, con el fin de lograr un modelo
integrado a partir de diversos modelos de Madurez de la Capacidad (CMM)
desarrollados principalmente en la década de los 90’s y que tuvieron un buen
reconocimiento de las organizaciones que las emplearon. Entre estos modelos se
encuentran:
3
http://web.frm.utn.edu.ar/liredat/docs.html
12
Verificación
 CMM-SW (CMM para Software).
 SE-CMM (Modelo de Madurez de la Capacidad para Ingeniería de Sistemas).
 IPD-CMM (Desarrollo de Producto).
Es así, que la primera versión del modelo (CMMI v1.1) fue publicado en enero del
2002 y en el año 2007 se liberó la segunda versión (CMMI v1.2).
2.2.2 Estructura
El modelo CMMI está estructurado por los Niveles de Madurez, los cuales están
conformados por un conjunto de Áreas de Proceso. Éstas a su vez contienen una serie de
Metas Específicas y Metas Genéricas.
El siguiente gráfico muestra los componentes que forman la estructura del modelo
CMMI.
Figura 2.1 – Estructura del CMMI
13
Fuente: CMMI v1.2
A continuación se describe cada uno de los componentes de la estructura del modelo:
 Nivel de madurez: Estado evolutivo definido que indica el nivel de madurez de una
organización.
 Área de proceso: Conjunto de prácticas relacionadas en un área, que implementadas

colectivamente, satisface un conjunto de metas consideradas importantes para lograr
mejoras en dicha área. Todas las áreas de proceso en CMMI son comunes para las
representaciones continua y secuencial.
 Meta genérica: Son llamadas genéricas porque las mismas metas aplican para
múltiples áreas de procesos. Una meta genérica describe las características que se
deben presentar para institucionalizar los procesos que implementan un área de
proceso.
 Meta específica: Una meta específica describe una característica única que debe ser
implementado para satisfacer el área de proceso.
 Prácticas genéricas: Son llamadas genéricas porque la misma práctica aplica para
múltiples áreas de procesos. Una práctica genérica es la descripción de una actividad
que es considerada importante para alcanzar la meta genérica asociada.
 Prácticas específicas: Una práctica específica describe las actividades que se esperan
resulten en el logro de una meta genérica de un área de proceso.
14
Verificación
2.2.3 Representaciones y niveles
CMMI permite alcanzar la mejora de los procesos mediante dos representaciones:

Continua y Secuencial.
Figura 2.2 – Representaciones del modelo CMMI
Fuente: www.sei.cmu.edu
A continuación se detalla cada una de ellas:
 Representación Continua
La representación continua permite a una organización seleccionar una determinada

área o grupo de áreas de procesos y mejorarlos para alcanzar la capacidad deseada. Esta
representación proporciona una mayor flexibilidad al momento de utilizar el modelo
CMMI para la mejora de procesos ya que la organización puede elegir mejorar el o las
áreas de procesos que están más alineadas a los objetivos del negocio o presentan una
deficiencia con respecto a las demás áreas de proceso.
15
Para la representación continua, se definen 6 niveles de capacidad de los procesos (del 0
al 6).
Nivel de Capacidad Característica
5. Optimizado La mejora de procesos está institucionalizada.
4. Gestionado Cuantitativamente Los procesos son controlados con técnicas

cuantitativas.
3. Definido Procesos definidos y alineados a las políticas de la

organización
2. Gestionado El proceso se planifica, se revisa y se evalúa para

comprobar que cumple los requisitos.
1. Ejecutado Se logran los objetivos.
0. Incompleto El proceso no se lleva a cabo o no se obtienen los

resultados requeridos.
Tabla 2.1 – Niveles de Capacidad de la representación continua

 Representación Escalonada
La representación secuencial o escalonada ofrece una manera sistemática y estructurada

para lograr una mejora de procesos por niveles. Esta representación define un orden de
implementación de las áreas de procesos. Para que una organización se encuentre en un
nivel determinado es necesario cumplir con todas actividades de las áreas de procesos
del nivel y de los niveles anteriores.
El modelo CMMI define 5 niveles de madurez para la representación secuencial.
16
Verificación
Figura 2.3 – Niveles de Madurez de la representación escalonada
 Inicial: No existe una planificación en el desarrollo y mantenimiento de software. El

desarrollo de los proyectos se basa en esfuerzo personal lo cual a menudo ocasiona
retrasos en los tiempos de entrega, sobrecostos de las actividades y por consiguiente
el fracaso del proyecto. El resultado de los proyectos es impredecible.
 Gestionado: Este nivel se caracteriza porque los proyectos son gestionados y

controlados durante su desarrollo. Los resultados de éxito de proyectos anteriores se
pueden repetir ya que se realiza un seguimiento de la calidad de los proyectos
utilizando prácticas institucionalizadas y métricas básicas.
 Definido: Este nivel se caracteriza porque los procesos están claramente definidos y
documentados, no solamente para un proyecto sino para toda la organización. Se
cuenta con procedimientos y métricas de un nivel más avanzado.
17
 Gestionado cuantitativamente: Este nivel se caracteriza por poseer objetivos
medibles, cuantificables y pronosticados. La gestión de los proyectos se basa en
modelos estadísticos.
 Optimizado: Este nivel se caracteriza por estar orientado a la mejora continua de los
procesos de la organización. Se hace uso intensivo de las métricas y se gestiona el
proceso de innovación.
2.2.4 Categorías y Áreas de Procesos
El modelo CMMI cuenta con 25 áreas de procesos desplegadas en niveles de madurez

(5 niveles); y a su vez, agrupadas por categorías: Ingeniería, gestión de proyectos,
gestión de procesos, y soporte.
En el siguiente cuadro se muestran las áreas de procesos agrupados por categorías y

niveles de madurez.
GESTIÓN DE GESTIÓN DE
N INGENIERÍA SOPORTE
PROYECTO PROCESO
Análisis causal
Innovación y
5 despliegue Innovación y
organizacional despliegue
organizacional
Gestión cuantitativa Rendimiento de

4
de proyecto progreso
18
Verificación
organizacional
Desarrollo de Administración de Formación
requerimientos riesgos organizativa
Gestión de proyecto Definición de Análisis

Solución técnica de
integrada decisiones y
proceso
3 Integración de soluciones
producto Gestión de organizacional
proveedores Enfoque en el
Verificación integrada proceso
Validación organizacional
Equipos integrados
Gestión de la
Gestión de acuerdos configuración
con proveedores
Aseguramiento de
Gestión de Seguimiento y la calidad del
2
requerimientos control de proyecto proceso y del
producto
Planificación de
proyecto Medición y
análisis
Tabla 2.2 – Áreas de Proceso por Categorías

www.sei.cmu.edu
A continuación se describe brevemente cada categoría:
19
 Ingeniería: Agrupa áreas de procesos relacionadas con el ciclo de vida de desarrollo
de un producto software, desde la captura y desarrollo inicial de los requerimientos
del cliente hasta el uso operacional.
 Gestión de proyecto: Enfocado a la planificación, seguimiento, y control del

proyecto. Cubre temas de gestión de acuerdos con proveedores y administración de
riesgos mediante un monitoreo constante a lo largo del proyecto.
 Gestión de procesos: Contiene prácticas cuyo objetivo es optimizar y mejorar los

procesos de la organización. Proporciona la capacidad de documentar las mejores
prácticas y medir cuantitativamente la calidad del proceso.
 Soporte: Proporciona prácticas que apoyan a las demás áreas de procesos en el

desarrollo del producto software.
2.3. ¿Qué es el SCAMPI?
2.3.1 Descripción de la metodología de evaluación
Ante la necesidad de poder medir el nivel de cumplimiento de una organización con

respecto a los lineamientos establecidos en el modelo CMMI, el SEI desarrolló en
paralelo al modelo una metodología de evaluación formal denominada “Standard
CMMI Appraisal Method for Process Improvement” (SCAMPI).
El método de evaluación SCAMPI se divide en tres fases (Planificación y preparación

para la evaluación, Conducción de la evaluación, y Reporte de resultados) y basa su
20
Verificación
evaluación en el análisis de las evidencias recolectadas sobre la ejecución y

cumplimiento de las prácticas específicas y genéricas del modelo CMMI.
La recolección de evidencias objetivas puede realizarse mediante la recopilación de

documentación como políticas organizacionales, procedimientos, artefactos resultantes
de implementaciones, instrumentos, y materiales de presentación; y entrevistas con las
personas encargadas de implementar o usar los procesos.
Las evidencias o huellas que prueban la implementación de una práctica son llamadas
Indicadores de Implementación de Práctica (PIIs) las cuales se clasifican en tres tipos:
artefactos directos, artefactos indirectos, y afirmaciones.
 Artefactos directos: Son las salidas tangibles resultantes directamente de la

implementación o ejecución de una práctica específica o genérica.
 Artefactos indirectos: Son los artefactos que son consecuencia de la ejecución de

una práctica específica o genérica pero que no son el propósito por el cual se ejecutó
la práctica.
 Afirmaciones: Confirmaciones orales o escritas de la implementación de una

práctica específica o genérica.
2.3.2 Clases de SCAMPI
21
Existen 3 clases de SCAMPI (A, B y C) que pueden ser utilizados dependiendo del
objetivo de la evaluación.
El SCAMPI clase A tiene un foco primario en la institucionalización. Es el método más

riguroso y completo de las tres clases y es usado para evaluaciones en profundidad.
Permite evaluar y brindar una puntuación sobre el nivel de madurez de la organización.
Requiere muchos recursos de tiempo y personas.
El SCAMPI clase B tiene un foco primario en el despliegue (“deployment”). Es un

método que resulta ser útil previo a la implementación masiva de nuevos procesos. Sin
embargo, no proporciona una puntuación sobre el nivel de madurez de la organización.
El SCAMPI clase C tiene un foco en el acercamiento o aproximación (“approach”). Es

el menos riguroso de todos, rápido y el que demanda menos recursos. No proporciona
puntuación sobre el nivel de madurez de la organización.
El siguiente cuadro muestra una comparación entre las tres clases de SCAMPI
22
Verificación
Características Clase A Clase B Clase C
Cantidad de
evidencia objetiva Alta Medio Baja
requerida
Calificación
Sí No No
generada
Recursos
Alto Medio Bajo
requeridos
Tamaño del equipo Grande (Mínimo 4 Mediano (Mínimo Pequeño (Mínimo 1

evaluador personas) 2 personas) personas)
Fuentes de datos
Sólo requiere dos
necesarios Requiere los tres
tipos de fuentes Sólo requiere
(instrumentos, tipos de fuentes de
(una de ellas debe documentación
entrevistas, datos
ser entrevistas)
documentación)
Persona autorizada Persona con

Líder del equipo Persona autorizada
o con formación y formación y
evaluador y acreditada
experiencia experiencia
Tabla 2.3 – Tabla comparativa de las clases de SCAMPI

23
2.3.3 Caracterización de las prácticas específicas y genéricas
En la siguiente tabla se muestra las caracterizaciones o valoraciones de las prácticas

específicas y genéricas de acuerdo a la existencia o no de los artefactos directos,
indirectos, afirmaciones, y debilidades.
Caracterización Requisitos o Condiciones
Uno o más artefactos directos.
Completamente Al menos un artefacto indirecto y/o existencia de afirmaciones

Implementado (CI) que confirmen la implementación.
Ninguna debilidad presentada.
Ampliamente Al menos un artefacto indirecto y/o existencia de afirmaciones

Implementado (AI) que confirmen la implementación.
Una o más debilidades presentadas.
Artefactos directos inadecuados o ningún artefacto directo.
Uno o más artefactos indirectos o afirmaciones que sugieran

que algunos aspectos de la práctica son implementadas.
Parcialmente Una o más debilidades descubiertas.

Implementado (PI)
o
Ningún artefacto indirecto o afirmaciones.
24
Verificación
Artefactos directos inadecuados o ningún artefacto directo.

No Implementado
Ningún artefacto indirecto o afirmaciones.
(NI)
Tabla 2.4 – Caracterización de Prácticas Específicas y Genéricas

2.3.4 Caracterización de áreas de procesos
En la siguiente tabla se muestra las caracterizaciones o valoraciones asignadas a las

áreas de proceso de acuerdo a las caracterizaciones obtenidas de sus prácticas
específicas y genéricas.
Caracterización Requisitos o Condiciones
Completamente Todas las prácticas están caracterizadas como CI

Implementado (CI)
Ampliamente Todas las prácticas están caracterizadas como AI o CI, con al

Implementado (AI) menos un AI
Al menos una práctica caracterizada como AI o CI y al menos

Ampliamente
Implementado (AI) o una práctica caracterizada como PI o NI.
Parcialmente El equipo evaluador puede elegir AI o PI dependiendo del
Implementado (PI) impacto de las debilidades en el logro de los objetivos.
25
Parcialmente Todas las prácticas están caracterizadas como PI o NI, con al
Implementado (PI) menos un PI.
No Implementado Todas las prácticas están caracterizadas como NI.

(NI)
Tabla 2.5 – Caracterización de Áreas de Proceso

26
Verificación
CAPÍTULO 3: ESTUDIO DEL ESTADO ACTUAL

DE LA EMPRESA
En el presente capítulo se detalla el proceso de evaluación SCAMPI inicial y los

resultados obtenidos identificando oportunidades de mejora.
La evaluación del estado de la empresa es necesaria para determinar el nivel de

cumplimiento de cada una de las Áreas de Proceso, mediante la identificación de las
fortalezas, brechas y debilidades que tiene la organización con respecto al cumplimiento
de prácticas específicas y prácticas genéricas definidas en el modelo CMMI.
Es por ello que, en una primera etapa, se realizó una evaluación a una muestra de tres
proyectos de ingeniería de software, los cuales se encontraban en diferentes etapas o
iteraciones de su respectivo ciclo de vida.
Para obtener resultados acordes con los lineamientos propuestos por el modelo CMMI
se realizó la evaluación utilizando la metodología SCAMPI desarrollado por el SEI.
Se realizó una evaluación SCAMPI B para llevar a cabo la evaluación debido al

reducido número de personas, recursos y tiempo. Esto no significó que la calidad de la
evaluación y resultados obtenidos se vea afectada o mermada.
27
3.1. Planificación y preparación de la evaluación
La planificación y preparación de la evaluación garantiza que los resultados obtenidos

sean de calidad y lo más cercano a la realidad. Por esta razón, se realizó un plan de
evaluación previa a la ejecución de la evaluación los cuales se explicarán a
continuación.
3.1.1. Identificación de requerimientos, objetivos y alcance de la

evaluación
Esta etapa de la evaluación es una de las bases iniciales que determina el éxito o fracaso
de la evaluación. Es importante tener conocimiento de la estructura de la empresa, los
roles y funciones de cada una de las personas que laboran en ella. Así mismo, identificar
las Áreas de Proceso a ser incluidas en la evaluación de acuerdo a los objetivos y
necesidades de la empresa.
Se identificaron las Áreas de Proceso críticas y con mayor prioridad a ser evaluadas.
Estas son:
 Gestión de Requerimientos (REQM)
 Desarrollo de Requerimientos (RD)
 Verificación (VER)
 Validación (VAL)
28
Verificación
Para el Área de Proceso de Gestión de Requerimientos (REQM) se tomó como los

resultados de la evaluación realizada por el proyecto CMMI nivel 2 con colaboración
del Ingeniero David Arteaga.
Otras Áreas de Proceso evaluadas fueron: Solución Técnica (TS), Integración de

Producto (PI), y Administración de Riesgos (RSKM). Estas Áreas de Proceso no están
incluidas, en el presente estudio, dentro del proceso de implementación en la empresa
virtual “Sistemas y Software Consultores”; sin embargo, los resultados obtenidos
pueden servir de referencia para un eventual estudio posterior.
Se seleccionaron tres proyectos como muestra con la colaboración del Gerente de

Proyectos. Los proyectos seleccionados son Gestión Curricular, Laboratorio Clínico, y
Registro Institucional del Docente.
A continuación se describe brevemente cada uno de los proyectos:
 Gestión Curricular:
Subsistema permite optimizar las distintas tareas involucradas en el proceso de gestión

curricular en las instituciones educativas; permitirá facilitar y realizar de manera
ordenada el diseño de la estructura curricular.
 Laboratorio Clínico:
Subsistema encargado de recibir las solicitudes de análisis clínicos y enviar los

resultados de los mismos; así como llevar a cabo la administración de los pacientes
externos, de los análisis disponibles, de los insumos y de la asignación de los
29
laboratoristas. Su principal objetivo es brindar la información indispensable para los
usuarios del subsistema y otros subsistemas.
 Registro Institucional del Docente:
Subsistema que ofrece la solución de acceder a la información personal, académica y

laboral pertinente al perfil de los docentes de la entidad educativa. Además, permite
una adecuada gestión de la trayectoria académica y profesional del docente, de esta
manera, se contemplan temas como logros académicos, méritos, deméritos,
participaciones en eventos con la universidad, entre otros.
3.2.2 Identificación de recursos y desarrollo del plan de ejecución
Esta actividad se refiere a la identificación de los recursos requeridos para llevar a cabo
la ejecución de la evaluación. Los recursos incluyen a las personas participantes,
facilidades y disponibilidad de tiempo, herramientas o plantillas de evaluación, y acceso
a la información (documentación y afirmaciones de los entrevistados).
Se identificaron a las personas a entrevistar por cada uno de los proyectos seleccionados
para la evaluación entre ellas los analistas, el gerente de producto, el gerente técnico, el
gerente de proyecto, el gerente de pruebas, y el gerente de desarrollo.
A continuación se muestra la relación de personas que formaron parte de los proyectos

con sus respectivos roles.
30
Verificación
Proyectos Analistas Gerente Gerente Gerente Gerente de Gerente de

Producto Técnico Proyecto Pruebas Desarrollo
Gestión Carlos Raffo Humberto Joel Francia Pedro Cruz Alex

Curricular César Miranda Carranza Vidaurre
Miguel Becerra
Laboratorio Mariana Segura Jorge Cabrera Aarón Ibañez Pedro Cruz Alex
Clínico Giuliana Veli Vidaurre
Registro Gonzalo Mori Carlos Joel Francia Miguel Pedro Cruz Alex
Institucional Roger Cruz Carranza Arrunátegui Vidaurre
del Docente
Tabla 3.1 – Personas entrevistadas por proyecto

Posteriormente, luego de realizar un análisis de los roles desempeñados por las personas
involucradas en los proyectos contra las Áreas de Procesos del modelo CMMI, se
identificaron a las personas a entrevistar para obtener afirmaciones e información
referente a cada una de las actividades de cada Áreas de Proceso evaluadas*.
En la siguiente tabla se marcan con puntos verdes las personas entrevistadas por Área de
Proceso.
Tabla 3.2 – Personas entrevistadas por Área de Proceso
*
Las Áreas de Proceso TS, PI, y RSKM formaron parte de las Áreas de Proceso evaluadas; sin embargo
no fueron consideradas dentro del alcance del presente proyecto para la implementación.
31
Como parte de la planificación de la evaluación, se elaboró un cronograma de

entrevistas con las personas identificadas en la tabla anterior.
Lunes Martes Miércoles Jueves Viernes
16/10/06 17/10/06 18/10/06 19/10/06 20/10/06
•Ilver Anache
(14:00)
•Carlos Carranza
(15:00)
23/10/06 24/10/06 25/10/06 26/10/06 27/10/06
•Ludvik Medic •Humberto •Pedro Cruz •Alex Vidaurre

(15:00) Carranza (17:00) (15:00) (15:00)
•Aarón Ibañez
(16:00)
32
Verificación
30/10/06 31/10/06 1/11/ 2/11/06 3/11/06
FERIADO
•Laboratorio Clínico
(15:00)
•Gestión Curricular
(16:00)
Tabla 3.3 – Cronograma de entrevistas

Un aspecto importante antes de realizar una evaluación es tener conocimiento de las

herramientas, metodología y estándares empleados por la organización en el proceso de
desarrollo de software.
La empresa virtual “Sistemas y Software Consultores” emplea como metodología

principal el RUP (Rational Unified Process), y el paquete de IBM Rational para el
diseño, gestión de requerimientos, herramienta diseño y ejecución de pruebas de
software.
Se realizó un análisis de las actividades y artefactos generados por dicha metodología

con el fin de identificar las relaciones entre el RUP y el modelo CMMI, llegándose a la
conclusión de que muchos aspectos del modelo CMMI son cubiertos por las actividades
y artefactos definidos en la metodología RUP. De esta manera, se realizó la
implementación reutilizando los artefactos del RUP que satisfacen los lineamientos
establecidos en el modelo CMMI con el fin de reducir el impacto del cambio de trabajo
en el desarrollo de los proyectos.
Como material principal para la recolección de evidencias durante las entrevistas fue
necesaria la creación de una Guía de evaluación (ver adjunto 4), en la cual se listan las
prácticas específicas y prácticas genéricas por cada Área de Proceso. Cada práctica
33
específica y práctica genérica tiene asociado una relación actividades y artefactos o
productos típicos esperados a encontrar durante la evaluación.
A continuación se muestra el nivel de sinergia entre el modelo CMMI y la metodología

RUP para cada Área de Proceso a implementar.
Tabla 3.4 – Sinergia de las prácticas de REQM entre el CMMI y RUP
Tabla 3.5 - Sinergia de las prácticas de RD entre el CMMI y RUP
34
Verificación
Tabla 3.6 - Sinergia de las prácticas de VER entre el CMMI y RUP
Tabla 3.7 - Sinergia de las prácticas de VAL entre el CMMI y RUP
Leyenda:
3.2. Ejecución y conducción de la evaluación
35
La ejecución de la evaluación se realizó siguiendo el cronograma de evaluación
establecida en la etapa de preparación y planificación de la evaluación.
Como primer paso, en la ejecución de la evaluación, se solicitó y recopiló la

documentación generada por los proyectos seleccionados y se realizó un estudio de los
mismos para identificar fortalezas y debilidades con respecto a las prácticas del CMMI.
En base a los documentos recopilados, se identificaron los artefactos directos e

indirectos que daban cumplimiento a cada una de las prácticas específicas y genéricas
de cada área de proceso.
Posteriormente, se llevaron a cabo las entrevistas con los miembros de los proyectos,
gerentes y los responsables de las áreas de procesos para obtener mayor información y
entendimiento de los procesos que puedan ser usados como evidencia objetiva. Es así,
que mediante las afirmaciones recogidas en las entrevistas se recolectaron evidencias
adicionales que fueron utilizadas para caracterizar o dar una valoración a las prácticas y
áreas de procesos.
La información recopilada producto de las entrevistas y análisis de artefactos se registró

en el documento Diagnóstico de la Situación Actual.
3.3. Análisis de resultados de la evaluación
Con la información obtenida y registrada en el Diagnóstico de la Situación Actual, se

realizó la caracterización o valoración de las prácticas del modelo asignándole un nivel
36
Verificación
de implementación de acuerdo a las reglas o parámetros definidos en el SCAMPI y

explicados en el marco teórico.
Como segundo paso, partiendo del nivel de implementación de las prácticas específicas
y genéricas, se determinó el nivel de satisfacción, mediante el algoritmo establecido en
la metodología de evaluación SCAMPI, de cada Área de Proceso sujetos a evaluación
obteniendo los resultados por Área de Proceso.
3.3.1 Gestión de Requerimientos (REQM)
A continuación se muestra el nivel de cumplimiento del Área de Proceso Gestión de

Requerimientos. Los datos de los resultados obtenidos en el presente Área de Proceso
fueron extraídos del estudio realizado por el Proyecto CMMI nivel 2.
Tabla 3.8 – Resultados de evaluación de REQM
Fuente: Tesis CMMI nivel 2
37
Oportunidades de mejora identificadas:
 A veces el Comité de Proyectos no cuenta con toda la información para revisar la

presentación. Puede sugerirse usar criterios a usar durante la revisión.
 No se documentan los cambios a los requerimientos, hay un formato, pero no se

viene usando.
 No hay una sistemática documentada para presentar el esquema de trabajo de los

proyectos.
 Eventualmente hay máquinas sin los productos ni la configuración necesaria. Hay

algunos problemas de inicio de configuración y carga de software y datos.
 Hay una herramienta que podría usarse para gestionar requerimientos y los
documentos.
 No hay un sistema de métricas para seguimiento de la ejecución de proyectos. El

Comité de Proyectos no tiene una visibilidad de la ejecución de los proyectos. No se
está informando al Comité por falta de tiempo.
 No hay criterios formalmente descritos para la revisión de la adherencia a los

procesos.
3.3.2 Desarrollo de Requerimientos (RD)
A continuación se muestra el nivel de cumplimiento del Área de Proceso Desarrollo de

Requerimientos.
Tabla 3.9 – Resultados de evaluación de RD
38
Verificación
 No se asignan los requerimientos a cada componente del producto.
 No hay un documento con los estándares de diseño de interfaces.
 No se identifican y asignan riesgos a los requerimientos.
 No se realizan valoraciones de riesgos de los requerimientos.
 No hay una política documentada de desarrollo de requerimientos.
 No hay un documento de adaptación del RUP a la empresa virtual
 No se utiliza ninguna herramienta para la administración de la configuración a nivel

organizacional para el proceso de Desarrollo de Requerimientos.
 No se lleva un monitoreo del avance con respecto al plan.
39
 No se guardan las presentaciones de delegados como parte de información para
mejora del proceso.
 Los miembros del Directorio no llenan el documento de cierre de iteración.
3.3.3 Verificación (VER)
A continuación se muestra el nivel de cumplimiento del Área de Proceso Verificación.
Tabla 3.10 – Resultados de evaluación de VER

tab009.jpg
 No se realizan actividades de peer reviews.
 No se tiene una política organizacional para el Área de Proceso Verificación.
 El proceso de verificación no está documentado. Sólo lo conoce el Gerente de

Pruebas.
40
Verificación
 No se tiene documentado el plan del proceso de verificación.
 No se usa ninguna herramienta para la administración de la configuración a nivel

organizacional.
 No se evalúa objetivamente la adherencia del proceso. Se debería evaluar mediante

revisiones periódicas de los artefactos generados en el Área de Pruebas.
3.3.4 Validación (VAL)
A continuación se muestra el nivel de cumplimiento del Área de Proceso Verificación.
Tabla 3.11 – Resultados de evaluación de VAL
41
 No se tiene documentado los procedimientos de validación para cada componente

del producto o artefacto.
 No se tiene un documento con los defectos encontrados en el proceso de validación.

Todo se reporta a través de correos electrónicos.
 No hay una política organizacional documentada para esta área de proceso.
 No se utiliza ninguna herramienta para la administración de la configuración a nivel

organizacional para el proceso de validación.
 No se lleva un control según el plan establecido por cada grupo de proyecto.
 No se guarda información de mejora con respecto al Área de Proceso de Validación.
 No se evalúa objetivamente la adherencia del proceso.
 Los miembros del Directorio no llenan el documento de cierre de iteración.
42
Implementación de 4 Áreas de Proceso del modelo de calidad CMMI:
Gestión y Desarrollo de Requerimientos, Validación, y Verificación
CAPÍTULO 4: DESARROLLO DE PROPUESTAS

DE SOLUCIÓN
En el presente capítulo, se detalla el proceso de desarrollo de las propuestas de solución

para cubrir las brechas identificadas en el capítulo anterior.
4.1. Metodología
El desarrollo de las propuestas de solución, durante todo el proyecto, requirió de una

constante comunicación con las personas que actualmente tienen a su cargo la ejecución
de actividades de desarrollo y gestión de requerimientos, validación, y verificación de
los productos desarrollados. Estas personas fueron llamadas “Responsables del Área de
Proceso” pues son quienes supervisan dichas actividades en los diferentes grupos de
trabajo.
La siguiente tabla muestra el responsable establecido para cada Área de Proceso

evaluada.
Responsable Área de Proceso
Pedro Cruz Gestión de Requerimientos(REQM)
Pedro Cruz Desarrollo de Requerimientos (RD)
Pedro Cruz Verificación (VER)
43
Capítulo 4: Desarrollo de Propuestas de Solución
Pedro Cruz Validación (VAL)
Tabla 4.1 – Responsables por Área de Proceso (Fase Desarrollo de Propuestas de

Solución)
Por otro lado, se trabajó de manera conjunta con los Jefes de Línea de Productos,
Gerente de Proyecto, y proyectos cuyos trabajos tenían relación con el presente estudio
tales como el proyecto MOPROSOFT, y Comité de Educación.
Como primer paso, se elaboraron y documentaron los procedimientos para cada Área de
Proceso a implementar (Desarrollo de Requerimientos, Verificación, y Validación).
Para cada procedimiento se definió un flujograma de actividades a seguir con su
respectiva caracterización identificando los roles, fases, inputs y outputs para cada tarea.
Así mismo, se proporciona una descripción de cada actividad con los pasos a seguir en
cada una de ellas.
Para el caso del Área de Proceso Gestión de Requerimientos (REQM) se hará uso del
proceso que forma parte del proyecto tesis CMMI nivel 2.
Mediante un mapeo de la metodología RUP y el modelo CMMI, se determinaron los

artefactos generados por el RUP a ser incorporados e implementadas en los talleres y
proyectos para lograr con el cumplimiento de las prácticas específicas que resultaron
con una valoración de Parcialmente Implementado (PI) y No Implementado (NI) en la
evaluación realizada. En algunos casos, se realizaron modificaciones a los artefactos del
RUP que se vienen utilizando para optimizar el número de artefactos adicionales a
implementar.
44
Por otro lado, se definieron formatos o plantillas necesarias para cubrir las brechas que
no se lograban satisfacer con las actividades y artefactos de la metodología RUP.
Se coordinó con los proyectos de Gestión de Reuso para el almacenamiento de los

formatos y procesos en el repositorio de Assets, los cuales pueden ser descargados
desde la web Rational Asset Manager.
4.2. Propuestas de Solución Aprobadas
A continuación se presenta la relación de artefactos a utilizar en el proceso de

implementación. Cada artefacto tiene una traza hacia la práctica específica que
satisface.
45
4.3. Recursos Tecnológicos
Los talleres y proyectos de software en la empresa virtual, siguen la metodología RUP y

utilizan como software la suite de IBM Rational para el desarrollo y gestión de los
mismos.
Aprovechando este contexto, se identificaron los recursos de software necesarios para

llevar a cabo la implementación de la mejora de los procesos y que permitan la
realización de las diferentes actividades definidas en los procesos.
A continuación se detallan los recursos de software:
IBM Rational RequisitePro
IBM Rational RequisitePro mantiene los equipos de proyectos al día gracias a la

creación, análisis y gestión de los requerimientos de aplicaciones y casos de uso.
46
Entre sus características se encuentran:
 Un producto potente y fácil de utilizar para la gestión de requisitos y casos de uso

que propicia una mejor comunicación, mejoras en el trabajo en equipo y reduce el
riesgo de los proyectos.
 Combina la interfaz conocida y fácil de utilizar de los documentos de Microsoft

Word con potentes funciones de base de datos para conseguir la máxima eficacia en
análisis y consulta de requisitos.
 Proporciona a los equipos la posibilidad de comprender el impacto de los cambios.
 Garantiza que todos los componentes del equipo estarán informados de los
requisitos más actuales para asegurar la coherencia.
 Proporciona acceso basado en web para los equipos distribuidos.
IBM Rational ClearQuest
Rational ClearQuest proporciona un seguimiento flexible de defectos y cambios en toda

la empresa.
Entre sus características se encuentran:
 Seguimiento basado en actividad de cambios y defectos.
 Soporte robusto y flexible para flujos de trabajo, que incluye notificaciones por
correo electrónico y opciones de envío.
 Fácil personalización mediante funciones de "apuntar y pulsar".
 Soporte completo para consultas con generación de multitud de informes y gráficos.
 Interfaz web para acceder fácilmente desde cualquier navegador web estándar.
 Integración transparente con Rational ClearCase para conseguir una solución SCM
completa.
47
 Integrado con los IDE líderes en el sector, como WebSphere Studio, Eclipse y
Microsoft .NET
48
CAPÍTULO 5: PROCESO DE
IMPLEMENTACIÓN
En el presente capítulo de detalla el proceso de implementación de las Áreas de Proceso

involucradas en el presente estudio, el cual se dividió en 4 etapas:
 Preparación
 Inducción y Capacitación
 Implementación y Seguimiento
 Análisis de Preparación
5.1. Preparación
El proceso de implementación se inició con la etapa de preparación. En esta etapa se

realizaron las siguientes actividades.
5.1.1. Designación de responsables por Área de Proceso.
Al igual que en la fase de Desarrollo de Propuestas de Solución, para el proceso de

implementación se designaron responsables para cada Área de Proceso quienes tienen
una función primordial para lograr una implementación exitosa. Es responsabilidad de
los responsables de las Áreas de Proceso asegurar la correcta implementación de las
soluciones y la mantener una continuidad en el tiempo de dichas soluciones.
49
Capítulo 6: Análisis de Resultados
Los responsables designados para cada Área de Proceso son los siguientes:
Responsable Área de Proceso
Gestión de Requerimientos (REQM)
Pedro Cruz Desarrollo de Requerimientos (RD)
Validación (VAL)
Alex Vidaurre Verificación (VER)
Tabla 5.1 – Responsables por Área de Proceso (Fase Proceso de Implementación)

Fuente: Elaboración Propia
5.1.2. Designación de Proyectos Piloto
La implementación de las Áreas de Proceso se lleva a cabo sobre un conjunto de

proyectos piloto para determinar la eficacia final de la implementación en base a una
evaluación SCAMPI post implementación. Si el resultado es positivo, es decisión del
directorio de la empresa virtual desplegarlo sobre todos los proyectos de software, que
basan su desarrollo en la metodología RUP, en ciclos posteriores.
La selección de los proyectos piloto se realizó con el Gerente de Proyectos en base a los
siguientes criterios:
 Los proyectos deben encontrarse en las primeras iteraciones del ciclo de desarrollo
(Taller de Proyectos o Proyecto 1).
 Deben ser de la carrera de Ingeniería de Software.
50
 Deben ser proyectos formales desarrollados bajo la metodología RUP.
Los proyectos piloto seleccionados son los siguientes:
Jefe de Línea
Ciclo Proyecto Integrantes Testers
de Producto
Evaluación basada Francisco Elera Hernán

TP en web Rodríguez
Renzo Sánchez
Apoyo a la Francisco Chávez Hernán Miguel

educación continua Rodríguez Talavera
P1 Sofía Garay
Karen Loayza
Reconocimiento de Edson Villar Hernán Rosa Felix

patrones Rodríguez
P1 Miguel Martinez Enrique
vehiculares
Huamán
Tabla 5.2 – Proyectos piloto

5.1.3. Reuniones con miembros del directorio y responsables de las

Áreas de Proceso
Un aspecto importante para llevar a cabo el proceso de implementación de CMMI es

obtener el compromiso de los involucrados y beneficiados por la implementación. Es
por ello, que se llevaron a cabo diversas reuniones con miembros del directorio y
51
responsables de las Áreas de Proceso a implementar; así como también, con otros
stakeholders que puedan dar soporte a la implementación.
Como resultado de las reuniones llevadas a cabo se determinaron algunas tareas a

realizar por proyectos externos.
Item Tarea Responsable
1 Implementación de repositorios de proyectos Centro de Cómputo 2
Implementación del CVS como herramienta de

2 Centro de Cómputo 2
configuración de versiones
Elaboración de manual de creación de

3 Centro de Cómputo 2
repositorios en RequisitePro
Tabla 5.3 – Tareas de Proyectos Externos

5.1.4. Elaboración de materiales de inducción y capacitación.
Para dar inicio al proceso de inducción y capacitación a los integrantes de los proyectos
piloto y responsables de las Áreas de Proceso, se elaboraron los siguientes documentos:
 Presentación de inducción y capacitación.
 Documento de inducción y capacitación.
 Manual de creación de repositorios en RequisitePro.
52
 Manual de captura de requerimientos en RequisitePro.
5.2. Inducción y Capacitación
El proceso de inducción al modelo CMMI es una actividad de vital importancia dentro

del marco de la implementación, el cual asegura que los analistas de los proyectos piloto
tengan conocimiento del modelo CMMI, las actividades que deben realizar y artefactos
que a elaborar para satisfacer los lineamientos establecidos por el modelo.
En la etapa de inducción y Capacitación se planificó y llevó a cabo una reunión de

inducción con los miembros de los proyectos piloto en la cual se cubrieron los
siguientes puntos:
 Descripción de la empresa virtual “Sistemas y Software Consultores”.
 Introducción del modelo CMMI.
 Descripción de las Áreas de Proceso a implementar.
 Explicación de las razones de la implementación.
 Diagnóstico actual de la empresa con respecto a los lineamientos del CMMI.
 Herramientas a utilizar en la implementación.
 Los beneficios a obtener con la implementación.
 Los compromisos por parte de los miembros de los proyectos piloto.
El siguiente cuadro muestra la relación de personas que estuvieron presentes en la

reunión de inducción y capacitación.
53
Proyecto Ciclo Nombre Asistencia
Francisco Elera 
Evaluación basada
TP
en web
Renzo Sánchez 
Francisco Chávez 
Apoyo a la
P1
educación continua
Sofía Garay 
Miguel Martinez 
Reconocimiento de
P1
patrones vehiculares
Edson Villar 
Tabla 5.4 – Asistencia a la reunión de Inducción y Capacitación

En el caso del analista Francisco Chávez, se le brindó una inducción individual

cubriendo los puntos tratados en la reunión de inducción.
La capacitación a los analistas de los proyectos piloto y Jefe de Línea de Producto en la

realización de las actividades definidas y formatos o plantillas fue un proceso continuo
que se extendió hasta la etapa de implementación y seguimiento.
5.3. Implementación y Seguimiento
La etapa de implementación y seguimiento tuvo una duración de 4 semanas.
54
Durante la implementación se capacitó a los analistas y responsables de las Áreas de

Proceso implementadas en el uso de los formatos desarrollados y actividades para
satisfacer las prácticas que propone el modelo CMMI.
El proceso de implementación presentó algunas barreras que significaron un riesgo para

la implementación, la principal barrera se relaciona con la cultura de trabajo de los
analistas. En un inicio los analistas de los proyectos piloto se mostraron incómodos y
reacios con la idea de elaborar artefactos y llenar formatos adicionales a los que
normalmente tenían que desarrollar. Sin embargo, con un seguimiento continuo se logró
cambiar la cultura de trabajo de los analistas a un conjunto de actividades ordenadas que
significaban un beneficio para el desarrollo y seguimiento de sus proyectos.
El seguimiento a los proyectos piloto fue semanal, mediante el uso de un checklist de

artefactos que debían ser desarrollados y por consiguiente las actividades a ser
realizadas.
A continuación se muestra el cumplimiento de los proyectos piloto en la presentación y

entrega de los artefactos solicitados.
Proyectos Testers
Nº Artefactos
AECE
AECE
SRPV
SRPV
EBW
EW
1 Charter de Proyecto  
2 Plan de Desarrollo de Software   
3 Plan de Iteración   
4 Formato de Petición de Cambio  
55
5 Formato Consolidado de Peticiones de Cambio  
6 Especificación de Casos de Uso   
7 Modelo de Casos de Uso   
8 Especificación de Requerimientos de Software   
9 Plan de Administración de Requerimientos   
10 Especificaciones Suplementarias   
11 Documento de Arquitectura de Software  
12 Glosario de Términos   
13 Lista de Riesgos  
14 Visión   
15 Plan de Pruebas  
16 Registro de Revisiones
17 Plan de Aceptación de Producto   
18 Formato Acta de Reunión 
19 Prototipo Visual   
20 Formato Consolidado de Artefactos Verificados  
21 Reporte de Defectos  
Tabla 5.5 – Artefactos Presentados por Proyectos Piloto y Testers

56
CAPÍTULO 6: ANÁLISIS DE RESULTADOS
El presente capítulo se detalla el análisis de resultados mediante una evaluación

SCAMPI post implementación.
La etapa del análisis de resultados tuvo una duración de 3 semanas.
Se realizó una evaluación SCAMPI tipo B post – implementación para determinar el

nivel de cumplimiento de las prácticas de las Áreas de Proceso implementadas.
El proceso de evaluación tuvo inicio con la recopilación de evidencias de los proyectos

piloto, el cual se realizó de forma continua conforme se realizaba el seguimiento a los
proyectos, seguido de breves entrevistas con los involucrados para obtener información
adicional con el fin de asegurar la confiabilidad de los resultados.
Para mayor detalle de la evaluación ver el documento Evaluación SCAMPI Post

Implementación.
En las siguientes secciones se detalla el resultado de la evaluación realizada.
57
6.1. Gestión de Requerimientos (REQM)
A continuación se muestra la tabla resumen de la calificación de cada práctica

específica y genérica del Área de Proceso REQM.
Tabla 6.1 – Resultados de evaluación de REQM Post implementación
0
1 0
Los resultados obtenidos mediante la recopilación de evidencias y artefactos

implementados muestran una mejora en el cumplimiento de las prácticas específicas de
58
REQM por consiguiente la meta genérica SG1 - Gestionar Requerimientos se encuentra

satisfecha.
La práctica genérica GP2.6 – Administrar Configuraciones se encuentra no

implementada debido a que no se llegó a implementar una herramienta de configuración
de versiones, en este caso el CVS. No se contó con las condiciones necesarias en los
servidores del centro de cómputo. Era necesario que se implementen los repositorios de
los proyectos en los servidores del centro de cómputo para dar inicio a la instalación de
la herramienta.
Se implementó el uso de matrices de trazabilidad mediante Rational RequisitePro para

identificar y gestionar el impacto de cambios en los requerimientos sobre otros. Estas
matrices de trazabilidad también fueron incorporados en el documento Plan de
Administración de Requerimientos.
A continuación se muestra una comparación entre los resultados de las evaluaciones

realizadas antes y después de la implementación.
Los resultados de la evaluación SCAMPI post implementación muestran una mejora en

el cumplimiento de las prácticas.
59
Se logró satisfacer la práctica SP1.2 – Obtener Compromiso sobre los Requerimientos,

de PI a CI, mediante la formalización de los requerimientos en el documento de Visión
y Especificación de Requerimientos de Software. Así mismo, se realiza y registra la
evaluación del impacto que genera cambios a los requerimientos.
Se logró satisfacer la práctica SP1.3 – Gestionar Cambios de los Requerimientos, de NI

a CI, mediante la implementación de los formatos de petición de cambios y formato de
consolidado de peticiones de cambio, con los cuales se deja constancia de la aprobación
de las peticiones de cambios y el seguimiento de los mismos.
Todas estas mejoras en el cumplimiento de las prácticas se basaron en los proyectos

pilotos en los cuales se realizó la implementación.
6.2. Desarrollo de Requerimientos (RD)

específica y genérica del Área de Proceso RD.
Tabla 6.2 – Resultados de evaluación de RD Post implementación
60
Los resultados muestran un alto nivel de implementación de las prácticas específicas de

RD por consiguiente las metas genéricas SG1 - Gestionar Requerimientos, SG2 –
Desarrollar Requerimientos del Cliente, y SG3 – Analizar y Validar Requerimientos se
encuentran satisfechas.
Como en el Área de Proceso anterior, la práctica genérica GP2.6 – Administrar

Configuraciones se encuentra no implementada debido a que no se llegó a implementar
una herramienta de configuración de versiones, en este caso el CVS. Era necesario que
se implementen los repositorios de los proyectos en los servidores del centro de
cómputo para dar inicio a la instalación de la herramienta.
61


Se logró satisfacer la práctica SP2.2 – Asignar los Requerimientos a los Componentes

del Producto, de NI a CI, mediante la implementación de matrices de trazabilidad entre
las necesidades de los stakeholders vs las características del SW; características del SW
vs los Casos de Uso. Así mismo, se consolidan los requerimientos en el documento de
Especificación de Requerimientos de Software.
Se logró satisfacer la práctica SP3.4 – Analizar los Requerimientos para lograr el

Equilibrio, de NI a CI, mediante evaluaciones de riesgos de los requerimientos. Para
ello, se implementó la matriz de trazabilidad entre Casos de Uso vs Riesgos y se adaptó
el documento del RUP Lista de Riesgos agregándole el campo de requerimiento
asociado al riesgo.
6.3. Verificación (VER)
62

específica y genérica del Área de Proceso VER.
Tabla 6.3 – Resultados de evaluación de VER Post implementación

tab015.jpg

VER; por consiguiente, las metas genéricas SG1 – Prepararse para la Verificación y
SG3 – Verificar los Productos Seleccionados, se encuentran satisfechas. Esto mediante
la implementación de un ambiente de verificación con el uso del Rational RequisitePro
y Rational Clear Quest, y el establecimiento de un procedimiento de verificación para
realizar las pruebas de los artefactos generados, reportar y dar seguimiento a los
defectos encontrados.
Por otro lado, la meta genérica SG2 – Realizar Peer Reviews se encuentra Parcialmente
Satisfecho.

63

Se logró mejorar parcialmente el cumplimiento de la práctica SP2.1 – Prepararse para

Peer Reviews, de NI a PI; y la práctica SP 2.2 – Conducir Peer Reviews. Debido a la
naturaleza de la empresa virtual, cantidad de recursos humanos y tiempo disponible de
los mismos, no fue posible realizar peer reviews formales con los distintos roles
característicos (moderador, escribano, desarrollador, testers, etc.). Sin embargo, se
realizaron inspecciones informales o revisiones a la documentación en las cuales se
revisó aspectos de gramática, ortografía, incongruencias, claridad de la redacción,
consistencia entre las necesidades de los stakeholders definidos en el documento de
visión contra las características del software definidos en el documento Especificación
de Requerimientos de Software. Para ello, se implementó en los cursos de Pruebas de
Software y Validación y Verificación un formato de Consolidación de Artefactos
Verificados y reportes de Resultados de Pruebas para llevar un mejor control.
Como propuesta de mejora, se elaboró una lista de comprobación de artefactos con la

colaboración de los profesores Alex Vidaurre y Aarón Ibáñez. Es recomendable que se
definan roles de revisores técnicos que se encarguen de realizar inspecciones a los
artefactos a nivel de contenido.
64
6.4. Validación (VAL)

específica y genérica del Área de Proceso VAL.
Tabla 6.4 – Resultados de evaluación de VAL Post implementación

VAL; por consiguiente, las metas genéricas SG1 – Prepararse para la Validación y SG2
– Validar el Producto o Componente del Producto se encuentran satisfechas.

65

Se logró mejorar medianamente el cumplimiento de la práctica SP1.3 – Establecer los

Procedimientos y Criterios para la Validación. Los criterios y procedimientos de
validación se definen en el documento Plan de Aceptación del Producto.
Se logró mejorar medianamente el cumplimiento de la práctica SP 2.2 – Analizar

Resultados de la Validación. Los resultados de la validación no se registran en un
documento exclusivamente diseñado para ese propósito. Se hace uso de las actas de
reunión para registrar las incidencias y el formato de petición de cambios si hubiere
cambios mayores.
66
67
CONCLUSIONES
1. El modelo CMMI proporciona los lineamientos para lograr una mejora en la

capacidad los procesos y en el nivel de madurez de una organización. En la empresa
virtual “Sistemas y Software Consultores” se buscó mejorar la capacidad de los
procesos relacionados a los requerimientos, validación, y verificación.
2. Para lograr una mejora significativa de los procesos, es necesario el compromiso y

colaboración de las diferentes unidades de la organización, principalmente del nivel
más alto de la misma.
3. El modelo CMMI puede coexistir con otros modelos de calidad o metodologías

formales de desarrollo de software.
4. La evaluación SCAMPI realizada en la empresa virtual fue de clase B – C debido al

reducido número de evaluadores y el corto periodo de tiempo con el que se contó
para realizar la evaluación. Esta clase de evaluación no permite determinar el nivel
de madurez de la organización ya que no es una evaluación rigurosa.
5. Los proyectos de software de la empresa virtual utilizan la metodología y artefactos

propuestos en la metodología RUP para el desarrollo de los productos de software.
Por tal motivo, y para no crear un impacto significativo en el trabajo de los analistas
y testers se reutilizó dicha metodología adaptándola a los lineamientos establecidos
por el modelo CMMI.
6. Para las prácticas que no fueron satisfechas por el RUP se crearon plantillas o
formatos para cubrir las brechas y satisfacer dichas prácticas.
7. Se logró obtener el compromiso tanto de los analistas de los proyectos piloto como
de los testers asignados a dichos proyectos en la realización de las actividades y
presentación de los artefactos y formatos adicionales implementados.
68
Verificación
8. Es necesario llevar a cabo una capacitación del modelo CMMI y en el uso de los
artefactos implementados a los nuevos alumnos de Taller de Proyectos. Así como
también, a los alumnos de Taller de Desarrollo y Pruebas.
9. Mediante la incorporación de las propuestas de solución se logró un mayor nivel de

cumplimiento de las prácticas definidas en las Áreas de Proceso implementadas con
respecto al nivel identificado en la evaluación SCAMPI inicial (pre-
implementación).
10. No es recomendable implementar el modelo CMMI en proyectos que utilizan una

metodología de desarrollo ágil.
11. La implementación del modelo CMMI en los talleres y proyectos no garantiza que
todos proyectos produzcan un producto final de calidad. Mucho depende de la
dedicación, responsabilidad, compromiso, y esfuerzo de los analistas para con su
proyecto.
12. Algunas soluciones desarrolladas pueden ser implementadas en proyectos de

Ingeniería de Sistemas de Información.
69
70
Verificación
RECOMENDACIONES
1. Es recomendable que el comité propicie el compromiso de todos los niveles de la

organización para posteriores implementaciones del modelo CMMI.
2. Se recomienda mantener el repositorio común que contiene todos los artefactos de

tal manera, que los artefactos implementados puedan ser reutilizados por los nuevos
proyectos entrantes.
3. Se recomienda adquirir o crear un software de evaluación SCAMPI para facilitar

posteriores implementaciones de Áreas de Proceso del CMMI en la empresa virtual.
4. Es recomendable realizar monitoreos o evaluaciones SCAMPI B periódicas para

identificar desviaciones y asegurar el cumplimiento de las Áreas de Proceso
implementadas.
5. Es necesario ordenar y definir los repositorios en los servidores del centro de

cómputo para realizar un seguimiento óptimo a la evolución de los requerimientos
mediante el RequesitePro.
6. Se recomienda que la estructura organizacional de la empresa virtual no cambie

drásticamente o con mucha frecuencia.
7. Se recomienda la creación de un workflow para la planeación y monitorio de los

proyectos para facilitar y optimizar el proceso de verificación y validación por parte
de los responsables y supervisores de los proyectos.
8. Por la gran cantidad de proyectos, se recomienda mayores recursos humanos que

cumplan los roles de jefes o gerentes de proyectos para llevar un mejor control sobre
los mismos, en temas de verificación de los artefactos generados, en cuanto a
requerimientos y aspectos técnicos.
71
9. Se recomienda la creación de roles de revisores que se encarguen de realizar
inspecciones de contenido de los entregables (requerimientos, arquitectura, etc.)
mediante el uso de la lista de comprobación de artefactos desarrollado en el presente
proyecto.
10. Se recomienda la elaboración y entrega al inicio del ciclo de un charter completo a

los alumnos de taller de proyectos para que tengan una idea clara del propósito de su
proyecto.
72
Verificación
BIBLIOGRAFÍA
AHERN, Dennis (2004) CMMI distilled: A practical introduction to integrated process

improvement. Boston: MA: Addison-Wesley.
ANTÓN CALVAY, Hernán y CARBAJAL VALVERDE, Jorge (2008)

Implementación del Nivel II del CMMI. (Tesis de título profesional en Ingeniería de
Sistemas de Información). Lima: Universidad Peruana de Ciencias Aplicadas.
CMMI BROWSER (2007) (www.wibas.de/cmmibrowser/index_de.php); contiene

información sobre el modelo CMMI v1.2. Cubre las representaciones Continua y
Escalonada. (consulta: 5 marzo).
CONCHA, Nancy (2006) Propuesta para implementar CMMI en una empresa con
múltiples unidades desarrolladoras de software (consulta: 11 de septiembre).
(http://sisbib.unmsm.edu.pe/bibvirtualdata/Tesis/Basic/concha_hn/concha_hn.pdf)
COGNENCEinc (2006)
(htttp://www.cognence.com/pdfs/CMMI_ProcessAndRequirementsManagement_White
Paper%20v1.0.pdf); contiene información acerca como alcanzar el nivel 2 del CMMI
usando soluciones software IBM Rational (consulta: 17 de enero).
IBM (2006) (http://www-

142.ibm.com/software/dre/ecatalog/Browse.wss?locale=es_ES); contiene información
sobre los productos IBM Rational (consulta: 14 de septiembre).
73
PROCESS STRATEGIES (2007) (http://process-strategies.com/appraisals.html);
contiene información sobre el método de evaluación SCAMPI (consulta: 09 de octubre).
SOFTWARE ENGINEERING INSTITUTE (2007) (http://www.sei.cmu.edu/cmmi/);

contiene información detallada sobre el modelo CMMI y el método de evaluación
SCAMPI (consulta: 05 de febrero).
WIKIPEDIA, la enciclopedia libre (2006) (http://es.wikipedia.org/wiki/CMMI);

contiene información sobre el modelo CMMI (consulta: 11 de septiembre).
74
Verificación
GLOSARIO DE TÉRMINOS
Analista: Alumnos de los cursos de Taller de Proyectos, Proyecto 1, y Proyecto 2
AECE: Proyecto de Ingeniería de Software Apoyo a la Educación Continua.
Área de proceso: Conjunto de prácticas relacionadas en un área, que implementadas

colectivamente, satisface un conjunto de metas consideradas importantes para lograr
mejoras en dicha área. Todas las áreas de proceso en CMMI son comunes para las
representaciones continua y secuencial.
Artefacto: Producto tangible resultante del proceso de desarrollo de software.
Capacidad: Cualidad que permite un buen desarrollo y resultado de una actividad.
EW: Proyecto de Ingeniería de Software Evaluación Basada en Web.
Metodología RUP: IBM Rational Unified Process. Proceso de desarrollo de software

típicamente usado para el desarrollo de sistemas orientado a objetos.
75
Nivel de Madurez: Grado de mejora de proceso a través de un grupo predefinido de
áreas de proceso en el cual tiene establecidas un grupo de objetivos.
Proceso: Conjunto de actividades o prácticas relacionadas que se ejecutan para obtener

un resultado de valor.
Integración de Producto (PI): Área de Proceso cuyo propósito es ensamblar, integrar

los componentes del producto, asegura que el producto integrado funciona
adecuadamente.
Gestión de Requerimientos (REQM): Área de Proceso cuyo propósito es gestionar los

requerimientos del producto y componentes del producto del proyecto e identificar
inconsistencias entre los requerimientos y los planes y work products.
Desarrollo de Requerimientos (RD): Área de Proceso cuyo propósito es producir y

analizar los requerimientos del cliente, producto y componentes del producto.
Administración de Riesgos (RSKM): Área de Proceso cuyo propósito es identificar

potenciales problemas antes de que éstos ocurran y planificar actividades a lo largo del
ciclo de vida del proyecto para mitigar los riesgos y su impacto sobre los objetivos
establecidos.
SCAMPI: Standard CMMI Appraisal Method for Process Improvement. Es una

metodología de evaluación para determinar el nivel de implementación del modelo
CMMI en una organización.
76
Verificación
SEI: Software Engineering Institute. Instituto de Ingeniería de Software propietario del

modelo CMMI y el método de evaluación SCAMPI.
SRPV: Proyecto de Ingeniería de Software de Patrones Vehiculares.
Stakeholders: Personas que tienen una fuerte relación con un proyecto.
Solución Técnica (TS): Área de Proceso cuyo propósito es diseñar, desarrollar e

implementar soluciones a los requerimientos.
Tester: Alumno del curso de Taller de Desarrollo y Pruebas.
Verificación (VER): Área de Proceso cuyo propósito es asegurar que el producto

seleccionado cumple con los requerimientos establecidos y funciona correctamente.
Validación (VAL): Área de Proceso cuyo propósito es demostrar que el producto o

componente del producto cumple con su propósito. Y si el producto desarrollado es el
correcto o deseado.
77
78

Implementación de 4 Áreas de Proceso Del Modelo de Calidad CMMI: Gestión y Desarrollo de Requerimientos, Validación, y Verificación

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Implementación de 4 Áreas de Proceso Del Modelo de Calidad CMMI: Gestión y Desarrollo de Requerimientos, Validación, y Verificación

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

CARRERA DE INGENIERÍA DE SISTEMAS DE INFORMACIÓN

Implementación de 4 Áreas de Proceso del modelo de

ASESOR: Pedro Cruz Hernández

El presente proyecto está dedicado a mi familia que gracias a su apoyo incondicional me

El presente proyecto se basa en la aplicación del modelo de mejora continua de procesos

El modelo de calidad en referencia es el CMMI (Capability Maturity Model

Se describe el proceso seguido para obtener un diagnóstico inicial de la situación de los

Posteriormente se detalla el proceso de implementación de las soluciones en proyectos

RESUMEN ...................................................................................................................... iii

El Modelo Integrado de Madurez de la Capacidad (CMMI – Capability Maturity Model

El CMMI fue desarrollado por el Instituto de Ingeniería del Software de la Universidad

El CMMI surge a partir de la integración de varios Modelos de Madurez de la

El presente estudio realizado tiene por objetivo emplear la metodología definida en el

 Gestión de Requerimientos (REQM) – Nivel 2

 Desarrollo de Requerimientos (RD) – Nivel 3

 Verificación (VER) – Nivel 3

 Validación (VAL) – Nivel 3

De esta manera, se busca mejorar y optimizar las actividades de desarrollo de software,

El capítulo 2 contiene el marco teórico detallado en la que se incluye el modelo de

El capítulo 3 contiene el estudio de la situación actual del negocio objetivo, detalla el

En el capítulo 4 se detalla el proceso realizado para desarrollar las soluciones requeridas

En el capítulo 5 se describe la implementación de las soluciones desarrolladas en

En el presente capítulo se define la empresa objetivo y la justificación de inicio del

1.1. Sistemas y Software Consultores

La Universidad Peruana de Ciencias Aplicadas UPC, primera universidad global del

La carrera de Ingeniería de Software es una de las carreras profesionales enmarcadas en

La carrera de Ingeniería de Software tiene como misión:

"Formar ingenieros de software profesionales y competentes en el

con una sólida base en principios de ingeniería y en tendencias en

El aprendizaje está basado en proyectos y con competencias y perfiles profesionales

En este sentido, el alumno interacciona con cursos de la especialidad desde el primer

La carrera de Ingeniería de Sistemas de Información es la segunda carrera profesional

Tiene como objetivo formar ingenieros capaces de diseñar y gestionar sistemas de

Los alumnos de las carreras de Ingeniería de Software y Sistemas de Información dan

El directorio es un grupo encargada de aprobar la cartera de proyectos de Ingeniería

Figura 1.1 – Organigrama de la empresa virtual “Sistemas y Software Consultores

Fuente: Elaboración propia

1.2. Justificación del inicio del proyecto

 Ambigüedad en la definición de proyectos: Los proyectos propuestos a los analistas

 Inconsistencia y trazabilidad entre los requerimientos iniciales y los planes: Los

 Poca eficiencia en las actividades de verificación y validación: En ciertas etapas del

 No existe una definición formal de los procesos.

De acuerdo a la problemática identificada, y luego de una evaluación y priorización de

 Gestión de Requerimientos (REQM): Área de Proceso enmarcada dentro del nivel 2

 Desarrollo de Requerimientos (RD): Área de Proceso perteneciente al nivel 3 del

 Verificación (VER): Área de Proceso perteneciente al nivel 3 del modelo CMMI,

 Validación (VAL): Área de Proceso perteneciente al nivel 3 del modelo CMMI,

Dentro de los beneficios esperados con la implementación de las Áreas de Proceso

 Mejorar la gestión y desarrollo de los requerimientos.

 Mejorar el cumplimiento del plan y cronograma de los proyectos.

 Mejorar la calidad y reducción de defectos.

 Mejorar la satisfacción del cliente.

CAPÍTULO 2: MARCO TEÓRICO

En el presente capítulo se presentan algunas definiciones de calidad y se explica en

2.1. ¿Qué es calidad?

Existen muchas definiciones propuestas por diversos especialistas profesionales en el

J.M. Juran, figura renombrada en el control de calidad, define calidad como la

El Organismo Internacional de Normalización (ISO) define calidad en la norma ISO

En el marco de la calidad del software, Pressman autoridad reconocida en la mejora de

2.2. ¿Qué es el CMMI?

El Modelo Integrado de Madurez de la Capacidad (Capability Maturity Model