Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS

“Año de la Promoción de la Industria Responsable y del Compromiso
Climático”
UNIVERSIDAD PERUANA LOS ANDES
FACULTAD DE INGENIERÍA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE SISTEMAS Y
COMPUTACIÓN
II PROGRAMA DE TITULACIÓN DE INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
– FILIAL LIMA
INFORME TÉCNICO
PRESENTADO POR:
Bach. Carmen Elizabeth Vásquez Dextre
PARA OPTAR EL TÍTULO PROFESIONAL DE
INGENIERO DE SISTEMAS Y COMPUTACIÓN
LIMA – PERU
2014
LA APLICACIÓN DE CMMI EN LA GESTIÓN DE
PROYECTOS

___________________________________
DR. RUBEN DARIO TAPIA SILGUERA
PRESIDENTE
___________________________________
………………………………………….
JURADO
___________________________________
………………………………………….
JURADO
___________________________________
………………………………………….
JURADO
______________________________________
MG. MIGUEL ÁNGEL CARLOS CANALES
SECRETARIO DOCENTE

Dedicatoria:
Agradecer a mi esposo por la
comprensión y el apoyo constante,
a mis padres, hermano y hermana,
por recordarme que me extrañan,
todos permanecen siempre dentro
de mis oraciones.
GRACIAS

INDICE
RESUMEN ..................................................................................................... 5
INTRODUCCIÓN ........................................................................................... 6
CAPITULO N°1 .............................................................................................. 7
1. ANTECEDENTES DE LA INVESTIGACIÓN........................................ 7
2. IDENTIFICACIÓN DEL PROBLEMA.................................................. 10
3. OBJETIVOS ....................................................................................... 12
4. JUSTIFICACIÓN ................................................................................ 13
5. METODOLOGÍA................................................................................. 34
CAPÍTULO N°2 - FUNDAMENTOS TEÓRICOS.......................................... 39
1. GESTIÓN DE PROYECTOS.............................................................. 39
2. CMMI®............................................................................................... 51
CAPÍTULO N°3 - APLICACIÓN DE CASO DE ESTUDIO ........................... 67
EQUIPO QUE CONFORMA EL PROYECTO .............................................. 71
PARTICIPACIÓN DEL EQUIPO EN EL CICLO DE VIDA DEL PROYECTO
DE IMPLEMENTACIÓN............................................................................... 71
CAPÍTULO N°4 - RESULTADOS DEL ESTUDIO Y PROPUESTAS DE
MEJORA .................................................................................................... 110
CONCLUSIONES ...................................................................................... 113
RECOMENDACIONES .............................................................................. 115
BIBLIOGRAFÍA .......................................................................................... 117
ANEXOS .................................................................................................... 119
ORGANIZACIÓN DE LA EMPRESA - ORGANIGRAMA..................... 121

5
RESUMEN
En la industria de Información y Tecnología (IT), existen organizaciones que
prestan servicios de consultoría, cuya gestión generalmente se realiza a
través de proyectos, aplicando la Guía del PMBOK® del PMI - Project
Management Institute Inc. En algunos casos, estas organizaciones también
podrían estar utilizando como referencia el modelo CMMI® que se ha
convertido en un estándar de facto en la industria, de tal forma que en
muchas ocasiones se ven enfrentadas a utilizar formatos y procedimientos
que dan respuesta a las prácticas de cada uno de los modelos, y aparecen
discrepancias y dificultades para adaptar la ejecución con ambas
referencias1.
1
Artículo: Vista ampliada para Gerencia de Proyectos usando mejores prácticas del PMBok® cuarta
edición y CMMI®-SVC V.1.2 nivel de capacidad o madurez 2. M.Sc. Ingrid Lucía Muñoz Periñán.
Universidad Icesi (2011). Revista Sistemas y Telemática. Vol.9. No.16, 73-90

6
INTRODUCCIÓN
El presente trabajo trata sobre como introducir los conocimientos del CMMI®
aplicándolos a la Gestión de Proyectos por medio de la Guía de Buenas
Prácticas – PMBOK®.
En el Planteamiento del Problema se describe el problema y se ha
referenciado dos fuentes principales, las mismas que dieron inicio a la
realización de este informe y que sirven de sustento para entender que
aplicar el CMMI® a la Gestión de Proyectos, es algo que se busca desde
hace un buen tiempo, por las posibilidades de mejora para las empresas que
la aplican.
En Fundamentos Teóricos se describe los conceptos básicos del PMBOK®,
el cual es considerado como el estándar para la Gestión de Proyectos.
Asimismo, se describe el alcance del proyecto en la cual se describe
brevemente los 5 Grupos de Procesos Básicos y las 9 Áreas de
Conocimiento. También describimos los conceptos básicos del CMMI® con
la finalidad de comprender sus áreas de procesos e introducirnos en los
niveles de madurez de una organización.
La Justificación plantea el PORQUE de este informe, además de realizar el
cruce de información, identificando las buenas prácticas y los procesos que
pueden ser incluidos en la Gestión de un Proyecto tomando en cuenta las
áreas de conocimiento.

7
CAPITULO N°1
1. ANTECEDENTES DE LA INVESTIGACIÓN
Para el presente informe, se han revisado dos fuentes secundarias, las
mismas que se resumen a continuación.
Planificación de proyectos para mejora de procesos. Enfoque en
pequeñas empresas de desarrollo de Software2, el cuál sostiene que: “A
partir del diagnóstico resultante de la evaluación a las empresas del sur
occidente colombiano, propone un modelo de planificación de proyectos de
mejora de procesos para las áreas de administración de requisitos,
administración de configuración y estimación en planificación de proyectos,
procesos priorizados (contemplados dentro de CMMI® en su nivel 2) y sobre
todo, definidos en el marco de pertinencia y contextualización para empresas
pequeñas de desarrollo. Los procesos propuestos, son una estrategia de
desarrollo de software que promueve prácticas adaptativas en vez de
predictivas; centradas en la gente y en los equipos, orientadas hacia
prestaciones y hacia la entrega y comunicación intensivas lo cual requiere
que la empresa se involucre de forma directa.”
Paulk, Curtis, y Weber definen a CMMI como un modelo que establece los
niveles por medio de los cuales las empresas de software desarrollan
definiciones, implementaciones, mediciones, controles y mejoras de sus
procesos de software, además de CMMI permite la definición del grado de
madurez de una determinada empresa y cuáles son las acciones de mejora
prioritarias para sus procesos de software (Paulk, Curtis y Weber, 1993).
La representación escalonada está orientada a presentar los procesos de
manera conjunta, es decir, deben abordar en su totalidad todos los procesos
de un nivel para poder pasar al siguiente.
2
Planificación de Proyectos para mejora de Procesos. Enfoque en pequeñas empresas de desarrollo
de software. Luis Merchán Paredes, Ph. D. Universidad San Buenaventura Seccional CALI. 2010

8
Ilustración 1 – Representación escalonada de CMMI (Maestría en Ingeniería de Calidad 2006)
Towards new approach of continuous process improvement based on
CMMI® and PMBOK®3 menciona que: “Hoy en día, es muy raro que las
empresas desarrollen solas todos los elementos que componen un producto
o servicio. La mayor parte del tiempo, se crean algunos componentes in-
house, mientras que otros se adquieren. Todos estos componentes son
entonces integrados en el producto final o servicio. Por lo tanto, las
organizaciones deben administrar y controlar su complejo proceso de
desarrollo y mantenimiento.
3
Towards new approach of continuous process improvement based on CMMI and PMBOK. IJCSI
International Journal of Computer Science Issues, Vol. 9, Issue 6, No 1, November 2012. Yassine
Rdiouat, Naima Nakabi, Khadija Kahtani and Alami Semma.

9
Los problemas que enfrentan las organizaciones implican soluciones para
toda la empresa y requieren un enfoque integrado para sus actividades de
desarrollo para alcanzar sus objetivos estratégicos.
Generalmente, hay tres dimensiones críticas en la que se basan todas las
organizaciones para aumentar su eficacia: Habilidades y potenciales
humanos, procedimientos y métodos, Tecnología y conocimientos técnicos.
Pero, ¿cuál es el elemento unificador que mantiene todo junto? Son los
procesos utilizados por la organización que son la base más profunda, la
más sostenible, que apoya todas estas dimensiones. Muchas organizaciones
no están interesadas en adoptar un proceso de enfoque de mejora, ya que
sólo se centran en tener el personal estupendo y la tecnología (Modelo
HERO). Estas organizaciones se encuentran con graves problemas de
calidad desde que la calidad del sistema depende en gran medida de la
calidad de los procesos de la organización.
No pretendemos que la gente y la tecnología no sean importantes. La
tecnología está cambiando constantemente y la gente cambia de trabajo
todo el tiempo. Un enfoque centrado en el proceso proporciona la
infraestructura para hacer frente a estos cambios y maximizar la
productividad de los individuos y el uso de la tecnología para ser más
competitivos.
PMBOK® es una norma que presenta las técnicas y herramientas para la
gestión eficaz de los proyectos, mientras que, CMMI® es un modelo de
proceso de madurez que ofrece los elementos esenciales de los procesos
eficaces; se centra en la organización de madurez y no en los individuos.
Para una organización que adopta el PMBOK® y quiere mejorar
continuamente sus procesos, CMMI® es un buen candidato que ofrece un
plan de trabajo más detallado para el proceso de mejora.”

10
2. IDENTIFICACIÓN DEL PROBLEMA
Actualmente la industria del software representa una actividad económica de
suma importancia en muchos países, entre ellos Perú, que ofrece múltiples
fuentes de negocio y perfila como un semillero apreciable de ingresos y
desarrollo. En los países latinoamericanos la industria de software, aún
incipiente e inmadura, es vista como una actividad económica en constante
desarrollo en la categoría de emprendimiento como pequeñas empresas
desarrolladoras de software.
La Gestión de Proyectos, en especial, los relacionados a desarrollo de
software presentan problemas en tiempo, alcance y costo, por lo que se
requiere que los procesos de las organizaciones incluyan el desarrollo de
niveles de madurez que alimenten el ciclo de vida del Proyecto, y que
sincronicen los procesos de la organización, para alinear el desarrollo y la
gestión de proyectos internos y externos. El principal factor que influye en
esta problemática son los riesgos, en la historia reciente de la ingeniería
causaron muchos incidentes que están relacionados con problemas en el
software. Pero estos problemas rara vez ocupan las páginas de los
periódicos, y solamente llaman nuestra atención cuando se producen en
sistemas críticos, causando pérdida de vidas humanas o arruinando grandes
inversiones. Es el caso de la explosión del cohete Ariane V en 1996 debida a
una reutilización fallida de software, o los fallos de programación en las
primeras versiones de los misiles Patriot que, a pesar de su superioridad en
el aire, resultaban totalmente ineficaces contra los misiles Scud iraquíes, uno
de cuyos ataques costó la vida a 28 personas.
Los estudiosos del tema, como Peter G. Neumann, llevan más de 25 años
observando y cuantificando los riesgos derivados de un mal desarrollo o un
uso indebido de los sistemas informáticos y sus consecuencias. La tabla 1
recoge algunas cifras extraídas del Risk Digest. Debe señalarse que no se
incluyen todas las categorías del trabajo original, y que un mismo riesgo
puede hallarse bajo más de un epígrafe4.
4
Gestión de riesgos en proyectos de desarrollo de software en España: estudio de la situación. Luis
Fernández Sanz*, Pedro Bernad Silva. Departamento de Ciencias de la Computación, Universidad de
Alcalá.

11
Ilustración 2 – Número de riesgos recogidos por Peter G. Neumann
La mejora de procesos es un tema crítico y esencial para que las
organizaciones puedan adecuarse a las cambiantes necesidades como así
también al crecimiento al que están sometidos sin planificación previa. Con
el fin de acompañar y ordenar este crecimiento muchos estándares han sido
desarrollados. Sin embargo, estas normativas en general requieren de un
esfuerzo y una infraestructura muy grande, que hace que las organizaciones
que están en el medio, intentando dejar de ser pequeñas organizaciones
para dar un salto de tamaño y convertirse a medianas o grandes
organizaciones sufran el costo adicional que genera el esfuerzo extra que se
relaciona con la mejora de procesos. En esta mejora de procesos se incluye
lo referente a la Gestión de Proyectos internos y externos de la organización,
siendo crucial para su evolución y sobrevivencia que los proyectos se cierren
en forma exitosa.

12
3. OBJETIVOS
1.1 OBJETIVO GENERAL
Lograr una adecuada planificación para la implementación de fases
del CMMI hasta el nivel 3 en una empresa de software, con la
finalidad de mejorar la gestión de los proyectos y la calidad del
producto software.
1.2 OBJETIVOS ESPECÍFICOS
• Realizar un análisis comparativo entre las áreas de proceso de
CMMI® y las buenas prácticas del PMBOK®.
• Establecer una metodología que permita la Implementación del
CMMI® en toda la organización para alcanzar el nivel 3 de
madurez.
• Elaborar los documentos que dan inicio al proyecto de
implementación y que permitirán conocer el alcance del
proyecto basándose en la Guía del PMBOK®.
• Definir los roles del equipo de trabajo y sus funciones dentro
del equipo que llevara a cabo la implementación del CMMI®
• Establecer el Project Charter y el cronograma de Planificación
del Proyecto, definiendo las tareas y actividades a realizarse en
el proyecto.
• Conocer los paquetes de trabajo o entregables que habrán en
el proyecto definiéndolos en el EDT y en el Diccionario de EDT.

13
4. JUSTIFICACIÓN
El presente informe se realiza con la finalidad de conocer cuáles son las
prácticas genéricas y/o especificas del CMMI® que tienen relación con la
Gestión de Proyectos específicamente el PMBOK®, para luego establecer
una metodología que permita la implementación del CMMI® en el caso de
estudio.
Con el presente informe se pretende difundir la implementación del CMMI®,
para ello, se toma una parte de la implementación, específicamente la parte
de Planificación de Proyectos, estableciendo las actividades que se deberán
desarrollar para alcanzar el nivel 3 de madurez en la organización.
Para la realización de la Planificación del Proyecto de Implementación, y al
Nivel 3 de Madurez propuesto en la implementación del CMMI® en la
empresa de software, se utilizará la representación escalonada debido a que
se desea integrar todas las áreas de la organización.
La implementación del CMMI® DEV es requerida en toda la organización,
debido a que el corazón del negocio es el desarrollo de software, este como
producto interactúa con las áreas de VENTAS, CONTABILIDAD, FINANZAS,
TECNOLOGÍA y, ARTE Y DISEÑO. Siendo una serie de procesos
identificados en las diferentes áreas que definen el producto final que cada
cliente recibirá, para lo cual la calidad y la minimización de riesgos es un
factor clave.
La importancia de este análisis radica en la expansión de la implementación
de niveles de CMMI® en el Perú5.
A continuación podremos observar la relación de empresas peruanas e
internacionales que tienen alguna sede en Perú y que ya implementaron
algún nivel del CMMI®.
5
CMMI INSTITUTE https://sas.cmmiinstitute.com/pars/pars.aspx

14
Tabla 3. En la siguiente tabla, se pueden observar una relación hasta el 2014 de empresas que obtuvieron
algún nivel del CMMI® en el Perú, siendo en varios casos obtenidos por empresas internacionales o
transnacionales.
Organización
Unidad Organizacional
Líder de Equipo
Patrocinador
Fecha final
Modelo
(Representación): Nivel
de Madurez
CosapiSoft S.A.
CosapiSoft
David Arteaga
Gil
EMILIO
FERNANDEZ DE
CORDOVA
01/27/2012
CMMI-DEV
v1.3(Staged):Maturity
Level 3
Trans Solutions Systems S.A.
Trans Solutions Systems
David Arteaga
Gil
Dante Rebagliati
05/17/2012
CMMI-DEV
Level 3
Accenture
LATAM: Argentina DC; Brasil
DC; Colombia & Perú
(Telefónica TGP)
John Voss
Marcio Theme
07/25/2012
CMMI-DEV
Level 3
Banco Central de Reserva del
Perú
Gerencia de Tecnologías de
Información - Subgerencia de
Soluciones de Tecnologías de
Información.
David Arteaga
Gil
FELIPE ERNESTO
ROEL
MONTELANOS
08/29/2012
CMMI-DEV
Level 2
TeamSoft S.A.C.
Software Development Unit
David Arteaga
Gil
ALBERTO
OLAECHEA
10/18/2012
CMMI-DEV
Level 3
IBM
IBM Application Management
Services, Spanish South
America (Argentina, Chile,
Colombia, Peru, Uruguay and
José Luis
Iparraguirre
Alejandro Yvorra
11/09/2012
CMMI-DEV
Level 5

15
Venezuela). Maintenance,
Development and Testing
services.
SOFTWARE ENTERPRISE
SERVICES SAC
SES – Software Factory
David Arteaga
Gil
JUAN HUAPAYA
01/11/2013
CMMI-DEV
Level 3
Novatronic SAC
Gerencia de Operaciones
(Operations Management)
David Arteaga
Gil
Guillermo
Pacheco
02/07/2013
CMMI-DEV
Level 3
everis Perú
everis Perú - Outsourcing
Carmen Cecilia
Rodríguez
Pascual Ruiz
02/08/2013
CMMI-DEV
v1.3(Continuous):Maturity
Level 3
BSF S.A.
Nearshore Software Services
Unit
Ernesto Raúl
Corona
Luis Robbio
03/22/2013
CMMI-SVC+SSD
Level 3
GMD S.A.
Application Outsourcing -
Maintenance, Development
and Testing Services
David Arteaga
Gil
ALDO MARTIN
GALLI ALVAREZ
Luis Mercado
04/19/2013
CMMI-DEV
Level 3
Hildebrando
Hildebrando México, Perú,
Colombia
JuanJo Cukier
Rafael López
Escalera
Rubén Guerrero
JORGE VELEZ
05/31/2013
CMMI-DEV
Level 3
Delaware Consultoría Perú SAC
Delaware Peru - Software
Services
David Arteaga
Gil
Alberto Centeno
06/21/2013
CMMI-DEV
Level 3
Telefónica Gestión de Servicios David Arteaga 07/16/2013 CMMI-DEV

16
Compartidos Perú S.A.C.
Fabricas de Software Interna y
Externa en Gerencia de
Sistemas de Negocio y Servicio
de Testing en Gerencia de TI
Gil
Roger Bernedo
Level 3
Synopsis S.A.
Gerencia de Operaciones
David Arteaga
Gil
Ricardo Palma
09/13/2013
CMMI-DEV
Level 3
UNIVERSIDAD PRIVADA
ANTENOR ORREGO
Software Development
Projects at Office: Systems and
Information's Engineering -
(Oficina de Sistemas e
Ingeniería de Información -
Proyectos de Desarrollo de
Software)
David Arteaga
Gil
MARCELINO
WALDEMAR
CARRETERO
OBANDO
12/09/2013
CMMI-DEV
Level 2
SIVSA, Soluciones Informáticas,
S.A.
Software Development
Projects and HOSIX Software
Maintenance Service.
Ramiro Carballo
José Antonio
Román Jiménez
04/23/2014
CMMI-DEV
Level 2
CMMI-SVC
Level 2
Tata Consultancy Services
Sucursal del Perú
Software Development and
Maintenance Projects in Peru
Miguel Serrano
SANGRAM
SAHOO
06/07/2014
CMMI-DEV
Level 3
Vector Software Factory
Development Unit
José Sancho
Thomas
Enrique Sánchez
06/23/2014
CMMI-DEV
Level 3
Esta relación de empresas que ya implementaron algún nivel del CMMI® en
el Perú, refuerza la importancia de este informe.

17
Debido a la información revisada en artículos, libros, tesis, entre otros. La
implantación del CMMI® siguiendo los estándares propuestos en la Guía del
PMBOK®, se hace necesaria en toda aquella organización que desea
competir a nivel internacional, con altos estándares para sus procesos, que
generen productos (en este caso software) de calidad y con una
minimización de riesgos en su desarrollo.

18
1.3 COMBINANDO CMMI® + PMBOK® PARA POTENCIAR
LA GESTION DE PROYECTOS
Para ello tenemos que tomar los aportes que nos brinda CMMI® con
respecto a la Gestión de Proyectos.
En esta asignación se ha recopilado entre los Grupos de Procesos de
Dirección de Proyectos y Áreas de Gestión de Proyectos del Conocimiento
en los ejes X e Y, respectivamente; y las prácticas de CMMI-Dev, Versión
1.3 entre ellos. Los grupos de procesos y áreas de conocimiento de la matriz
de gestión de proyectos del PMBOK® y las prácticas específicas del
CMMI®. Las actividades técnicas (como el diseño de un proyecto) no
aparecen en esta compilación.6
Tabla 4 COMBINANDO CMMI® + PMBOK® PARA POTENCIAR LA GESTION DE PROYECTOS
Áreas de
conocimiento
Grupos de Procesos de Gestión de Proyectos
Grupo de
Procesos
de Inicio
Grupo de
Procesos de
Planeamient
o
Grupo de
Procesos de
Ejecución
Grupo de
Procesos
de
Monitoreo
y Control
Cierre de
Grupos
de
Procesos
Gestión de la
Integración de
Proyectos
4.1
Desarrollar
el Acta de
Proyecto
4.2 Desarrollar
el Plan de
Gestión de
proyectos
4.3 Ejecutar,
dirigir y
gestionar un
proyecto.
4.4
Monitorear
y Controlar
el Trabajo
del
Proyecto
4.5 Realizar
el Control
Integrado
de Cambios
4.6 Cerrar
el Proyecto
o Fase
IPM/ SG1;
GP 2.1.
PP/ SG2, SP
2.3, 2.7; IPM/SP
1.1, 1.4; REQM/
SP 1.5; CM/ SP
1.1, 1.2; GP 2.1,
2.2, 2.3.
REQM/ SP 1.3,
1.4, 1.5; IPM/ SP
1.1, 1.5; CM/ SP
1.2, 1.3, 2.1, 2.2,
3.1; PP/ SP 1.2;
IPM/ SP 1.2; GP
2.1, 2.6.
PMC/SP 1.1,
1.4, 1.6, 1.7,
2.1, 2.2, 2.3;
MA/ SP 1.1;
GP 2.8, 2.10.
IPM/SP 1.7;
GP 3.2.
Gestión del Alcance
del Proyecto
5.1 Reunir los
requisitos
5.2 Definir el
Alcance, 5.3
Crear el EDT
5.4 Verificar
el Alcance,
5.5 Control
del Alcance
PP/ SP 1.1, 1.3;
RD/ SP 1.1, 1.2,
2.1, 2.2, 2.3,
3.1, 3.2; REQM/
SP 1.3.
RD/ 3.4;
PMC/ SP 1.1;
CM/ SP 1.3,
3.1.
6
Quality Mentors. Ribhu Lavania

19
Gestión del Tiempo
del Proyecto
6.1 Definir
Actividades,
6.2 Secuencia
de
Actividades,
6.3 Estimar los
recurso de las
Actividades,
6.4 Estimar la
duración de
las actividades
6.5 Desarrollar
el cronograma
6.6 Control
del
cronograma
PP/SP 1.1, 1.4,
2.1, 2.4, 3.2;
IPM/ SP 1.2,
1.3; GP 2.3.
PMC/ SP
1.1.
Gestión de Costos
del Proyecto
7.1 Estimar
Costos, 7.2
Determinar
Presupuesto
7.3 control
de costos
PP/SP 1.4, 2.1,
3.3; GP 2.3.
PMC/ SP
1.1.
Gestión de la
Calidad del Proyecto
8.1 Plan de
calidad
8.2 Realizar el
Aseguramiento
de Calidad
8.3 Realizar
el Control
de Calidad
RD/SP 3.2, 3.3,
3.4; PPQA/
SP1.1, 1.2; MA/
SP 1.2, 1.3, 1.4;
QPM/ SP 1.1,
1.2, 1.3, 1.4;
VER/ SP 1.1,
1.3; VAL/SP
1.1, 1.3; OPP/
SP 1.1, 1.2, 1.3.
RD/SP3.2; PPQA/
SP 2.1, 2.2; MA/
SP 2.3, 2.4; QPM/
2.1, 2.2, 2.3; VER/
SP 1.2, 2.1, 2.2,
3.1; VAL/SP 1.2,
2.1; GP 2.6, 2.9.
PMC/ SP
1.1, PPQA/
SP 2.1, 2.2;
PMC/ 2.1,
2.2, 2.3; MA/
SP 2.1, 2.2;
CM/ SP 2.3;
VER/SP 2.3,
3.2; VAL/SP
2.2; OPP/ SP
1.4, 1.5; GP
2.8, 2.9, 2.10.
Gestión de
Recursos Humanos
del Proyecto
9.1 Desarrollo
del Plan de
Recursos
Humanos
9.2 Adquirir el
Equipo del
Proyecto, 9.3
Desarrollar el
Equipo del
Proyecto, 9.4
Gestionar el
Equipo del
Proyecto
PP/ SP 2.4, 2.6,
IPM/ SP 1.3,
1.6; OT/ SPSP
1.1, 1.2; GP 2.3.
IPM/ SP1.6; OT/
SP 2.1, 2.2, 2.3;
GP 2.5, 2.7.
Gestión de
Proyectos de
Comunicaciones
10.1
Identificar
los
Stakeholde
rs
10.2 Plan de
Comunicacion
es
10.3 Distribuir
información,
10.4 Gestionar
las expectativas
de los
Stakeholders
10.5
Informe de
resultados
PP/SP 2.6;
REQM/
SP1.1, 1.2;
GP 2.7; GP
2.4.
IPM/ SP 1.5;
REQM/SP1.1,1.
2, ;
IPM/ SP 1.7, 2.1,
2.2, 2.3; REQM/
SP 1.3, 1.4, GP
2.7.
PMC/SP 1.2,
1.4, 1.5, 1.7,

20
Gestión de Riesgos
del Proyecto
11.1 Gestión
del Plan de
Riesgos 11.2
Identificar
Riesgos 11.3
Realizar el
Análisis
Cuantitativo
de Riesgos
11.4 Realizar
el Análisis
Cuantitativo
de Riesgos,
11.5
Respuestas al
Plan de
Riesgos
11.6
Riesgos de
Monitoreo y
Control
PP/SP 2.2,
RSKM/ SP 1.1,
1.2, 1.3, 2.1,
2.2, 3.1.
RSKM/ SP
3.2; PMC/
1.3,
Gestión de las
Adquisiciones del
Proyecto
12.1 Plan de
Adquisiciones
12.2
Aprovisionamien
to de Conducta
12.3
Administrar
las
Adquisicion
es
12.4 Cerrar
las
Adquisicion
es
SAM/ SP 1.1,
1.2, 1.3; GP 2.3.
SAM/ SP 2.1, 2.2,
2.3.
SAM/ SP 2.1,
2.2, 2.3.
RSKM/ SP
2.3.
© QualityMentors.
Version 1.1/ February 2011.
Podría existir alguna relación entre ciertos procesos del PMBOK® y las
Áreas de Proceso (PAs) de CMMI®; sin embargo, la relación está más a
nivel de prácticas de CMMI® con procesos del PMBOK®.
En un análisis detallado, no todos los procesos del PMBOK® son
referenciados en CMMI®; sin embargo, aplicar todos los procesos del
PMBOK® a una metodología organizacional de proyectos crea fortalezas en
varios de los niveles de madurez de CMMI®.
La siguiente imagen presenta uno de los procesos del PMBOK® que puede
ser relacionado, directamente, con una práctica de Planificación del Proyecto
de CMMI®. El PMBOK® describe, con algún nivel de detalle, cada uno de
los elementos de las entradas, técnicas y salidas. Para algunos de ellos
incluye ejemplos gráficos y explicaciones adicionales.

21
Ilustración 3 – Diagrama de un Proceso de Gerencia de Proyectos con Entradas, Técnicas, y Salidas.
A continuación se presenta la práctica específica del área de proceso de
Planeación del Proyecto que se relaciona de manera directa con el proceso
de arriba, tal cual como se encuentra en el documento de CMMI®7.
Tabla 5 - Área de Proceso de CMMI® con Descripción Completa
Nivel 2
Área de Proceso PLANIFICACIÓN DEL PROYECTO
Meta SG 1 Establecer Estimaciones
Las estimaciones de los parámetros de planificación del
proyecto se establecen y mantienen.
Practica SP 1.1 Estimar el Alcance del Proyecto
Establecer una estructura de desglose de trabajo de nivel
superior (EDT) para estimar el alcance del proyecto.
La EDT evoluciona con el proyecto. Inicialmente una de
nivel superior de la EDT puede servir para estructurar la
estimación inicial. El desarrollo de una EDT divide el
proyecto en general en un conjunto interconectado de
componentes manejables. Por lo general, la EDT es una
estructura orientada producto que proporciona un esquema
para identificar y organizar las unidades lógicas de trabajo
para gestionar, que son llamados "paquetes de trabajo." El
EDT proporciona un mecanismo de organización de
referencia y para la asignación de esfuerzo, la
programación y la responsabilidad y se utiliza como marco
de referencia base para planificar, organizar y controlar el
trabajo realizado en el proyecto. Algunos proyectos utilizan
7
Artículo: Áreas de CMMI relacionadas con la administración de proyectos. Mauricio Morales, PMP®.
Portal Líder de Proyecto.
http://www.liderdeproyecto.com/manual/areas_de_cmmi_relacionadas_con_la_administracion_de
_proyectos.html

22
el término "contrato EDT" para referirse a la parte de la
EDT puesto bajo contrato (posiblemente toda la EDT). No
todos los proyectos tienen un EDT contrato (por ejemplo, el
desarrollo, financiado internamente).
Típicos Productos
de Trabajo
1. Descripciones de Tareas
2. Descripciones de Paquetes de Trabajo
3. EDT
Subpracticas 1. Desarrollar un WBS basado en la arquitectura del
producto.
La EDT proporciona un esquema para organizar el trabajo
del proyecto en torno a los componentes del producto y de
productos compatibles con el trabajo. La WBS debe
permitir la identificación de los siguientes elementos:
▪ Riesgos identificados y sus tareas de mitigación
▪ Tareas para entregables y actividades de apoyo
▪ Tareas para el desarrollo de planes de apoyo
necesarios, tales como gestión de la configuración,
control de calidad y planes de verificación
▪ Tareas para la integración y la gestión de artículos
no desarrollados
2. Identificar los paquetes de trabajo con suficiente
detalle para especificar las estimaciones de las tareas
del proyecto, las responsabilidades y el calendario.
El nivel superior de la EDT se pretende ayudar a calibrar el
esfuerzo de trabajo del proyecto en términos de tareas y
roles organizativos y responsabilidades. La cantidad de
detalle en la EDT en este nivel más detallado ayuda a
desarrollar horarios realistas, lo que minimiza la necesidad
de reserva de gestión.
3. Identificar los componentes del producto o
productos que se adquieren externamente.
Consulte el área de proceso de Gestión de Acuerdos con
Proveedores para obtener más información sobre la
adquisición de productos de fuentes externas al proyecto.
4. Identificar los productos de trabajo que serán
reutilizados.
El detalle presentado en el PMBOK®, para la mayoría de los procesos, es
mayor que el expuesto en CMMI®, sumando a esto, que el PMBOK®
contiene procesos que no pueden ser direccionados a CMMI®. Por otro

23
lado, CMMI® provee una estructura de gestión de procesos y mejores
prácticas para ingeniería.
Combinando ambos modelos se obtiene un excelente y maduro esquema de
gerencia de proyectos de ingeniería.
1.4 CMMI® DESDE PMBOK®
Por su especificidad, no es fácil establecer una visión del PMBOK® desde
CMMI® o mejor, hay mucho más que abarcar desde CMMI® que desde
PMBOK®; sin embargo, al revés, PMBOK® permite implantar una gerencia
de proyectos más amplia que la descrita por CMMI® y soporta algunas
prácticas de otras disciplinas como soporte.
Para enfocar mejor en CMMI® y cómo se puede apoyar en conseguirlo con
PMBOK® revisare las prácticas de CMMI® indicando cómo son apoyadas
por los procesos de aquel.
1.5 COMPARACIÓN DIRECTA DE ÁREAS DE PROCESO
CMMI® A PROCESOS PMBOK®
Desde PMBOK® se apoyan varias áreas de proceso o prácticas específicas
y genéricas de CMMI®. Dado que una valoración oficial busca el
cumplimiento o logro de las metas específicas y genéricas, buscare cuáles
de éstas se encuentran cubiertas por los procesos del PMBOK®. Esta
comparación se realiza en la siguiente tabla, para todas las áreas de
procesos de CMMI®, en todos los niveles de madurez.

24
Tabla 6 - Comparación de Prácticas Específicas de las Áreas de Proceso de CMMi contra Procesos del PMBOK®
Nivel
Área de
Proceso CMMi®
Metas Específicas de
las Áreas de Proceso
de CMMi®
Proceso del PMBOK®
Correspondiente o
Equivalente
2
REQM –
Gestión de
Requerimientos
SG 1 – Administrar
requerimientos
5.2 – Definir alcance
5.5 – Controlar el alcance
PP –
Planeación de
Proyectos
SG 1 – Establecer
estimados
5.3 – Desarrollar WBS
6.3 – Estimar Recursos
de las Actividades
6.4 – Estimar duración de
las actividades
7.1 – Estimar costos
7.2 – Determinar el
presupuesto
SG 2 – Desarrollar un
plan de proyecto
4.2 – Desarrollar plan del
proyecto
8.1 – Planear la calidad
9.1 – Planear recursos
humanos
10.2 – Desarrollar plan
de comunicaciones
11.1 – Planear gestión de
riesgos
12.1 – Planear
adquisiciones
SG 3 – Obtener
compromiso con el
plan
proyecto
PMBOK® define que el
plan se desarrolla con
el equipo del proyecto
para obtener mayor
compromiso.
PMC –
Monitoreo y
Control de
Proyectos
SG 1 – Monitorear el
proyecto contra el plan
4.4 – Monitorear y
controlar el trabajo del
proyecto
5.4 – Verificar el alcance
6.6 – Controlar el
cronograma
7.3 – Controlar costos
8.3 – Realizar control de
calidad
controlar riesgos
12.3 – Administrar
adquisiciones
acciones correctivas

25
hasta el cierre proyecto
calidad
PPQA –
Aseguramiento
de calidad de
proceso y
producto
SG 1 – Objetivamente
evaluar procesos y
productos de trabajo
8.2 – Realizar el
aseguramiento de calidad
calidad
SG 2 – Proveer
conocimiento y
evidencia objetivos
8.2 – Realizar el
10.5 – Reportar el
desempeño
MA – Medición
y Análisis
SG 1 – Alinear
medición y actividades
de análisis
PMBOK® define,
aunque no en un
proceso, la realización
de un Plan de Gestión
de Costos en dónde se
deben establecer las
reglas de medición de
valor ganado
proyecto
SG 2 – Proveer
resultados de las
mediciones
proyecto
desempeño
SAM –
Administración
de Acuerdos
con
Proveedores
SG 1 – Establecer
acuerdos con
proveedores
12.1 – Planear
adquisiciones
12.2 – Ejecutar
adquisiciones
SG 2 – Satisfacer
acuerdos con
proveedores
adquisiciones12.4 –
Cerrar adquisiciones
CM –
Administración
de la
configuración
SG1 – Establecer
líneas base
6.5 – Desarrollar el
cronograma
presupuesto
SG 2 – Rastrear y
controlar cambios
8.2 – Realizar el
calidad
4.5 – Ejecutar el control
integrado de cambios

26
En PMBOK® La
mayoría de los
procesos de planeación
y control tienen, como
salida, solicitudes de
cambios,
actualizaciones a
documentos del
proyecto y/o
actualizaciones al plan
del proyecto.
SG 3 – Establecer
integridad
proyecto
proyecto
4.5 – Ejecutar el control
integrado de cambios
de comunicaciones
3
DAR – Análisis
y resolución de
decisión
SG 1 – Evaluar
alternativas
cronograma
presupuesto
PMBOK® establece
análisis de alternativas
como técnica en estos
procesos, junto con el
análisis “what-if”; sin
embargo, no lo
determina en el nivel de
formalismo que
establece CMMi® pues
se asume que habrá
algún método para
realizarlo.
IPM – Gerencia
integrada de
proyectos
SG 1 – Usar el proceso
definido para el
proyecto
proyecto
4.3 – Dirigir y gestionar la
ejecución del plan del
proyecto
proyecto
8.2 – Realizar el
10.3 – Distribuir
información
SG 2 - Coordinar y 5.1 – Obtener

27
colaborar con los
stakeholders
relevantes
requerimientos
10.1 – Identificar
stakeholders
expectativas de los
stakeholders
humanos
9.2 – Adquirir el equipo
del proyecto
equipo del proyecto
9.4 – Administrar el
equipo
En PMBOK® el
stakeholder es
relevante para todas las
actividades del
proyecto y siempre se
establece que sus
necesidades y
expectativas deben ser
cumplidas.
SG 3 – Aplicar principio
de IPPD
IPPD en CMMi® se
refiere a crear un
ambiente de
integración entre
equipos para cumplir
eficientemente con
los requerimientos
del proyecto y
producir productos
de calidad
SP 3.1 Establecer el
Proyecto Visión
Compartida
SP 3.2 Establecer la
estructura del equipo
integrado
SP 3.3 Asignar
Requisitos para los
equipos integrados
SP 3.4 Establecer
project charter
5.1 – Obtener
requerimientos
5.3 – Desarrollar el WBS
humanos
9.2 – Adquirir el equipo
del proyecto
equipo del proyecto
9.4 – Administrar el
equipo
8.2 – Realizar el
stakeholders
de comunicaciones
10.3 – Distribuir
información
expectativas de los
stakeholders
PMBOK® menciona,

28
equipos integrados
Establecer y mantener
los equipos integrados
en la estructura.
SP 3.5 Asegurar la
colaboración entre la
interconexión Equipos
aunque no lo establece
como proceso ni
técnica, la creación de
la Matriz de Asignación
de responsabilidades
(RAM) donde se
asignan paquetes del
WBS a personas o
equipos del proyecto.
OPD –
Definición del
Proceso
Organizacional
SG 1 – Establecer
activos de procesos
organizacional
10.3 – Distribuir
información
4.6 – Cerrar el proyecto o
fase
PMBOK® no define
cómo establecer los
activos de proceso pero
sí los usa como entrada
para la mayoría de sus
procesos y
explícitamente en estos
dos, los activos de
proceso son
actualizados.
SG 2 – Habilitar la
gestión de IPPD
SP 2.1 Establecer
mecanismos de
empoderamiento
SP 2.2 Establecer
normas y directrices
para los equipos
integrados
SP 2.3 Equilibrar las
responsabilidades del
Equipo y de la
organización
stakeholders
de comunicaciones
humanos
equipo del proyecto
PMBOK® no posee
procesos específicos
pero si define técnicas
de negociación,
creación de reglas
básicas y esquemas de
comunicación que
cubren las prácticas
específicas de esta
meta específica.
OPF – Foco en
el Proceso
Organizacional
SG 1 – Determinar
oportunidades de
mejoramiento del
proceso
8.2 – Realizar el
calidad
desempeño
SG 2 – Planear e 8.1 – Planear la calidad

29
implementar
mejoramientos al
proceso
8.2 – Realizar el
PMBOK® no contiene
procesos para
implementar o hacer
seguimiento, de manera
específica, al
mejoramiento del
proceso; sin embargo,
como salida del 8.1 hay
un Plan de
Mejoramiento del
Proceso y como salida
de 8.2 hay
actualizaciones a
documentos del
proyecto que incluyen
las oportunidades de
mejora.
SG 3 – Implantar
activos de proceso
organizacional e
incorporar lecciones
10.3 – Distribuir
información
En PMBOK®, en la
mayoría de los
procesos de planeación
y control, se cuenta con
los activos de proceso
como entrada o son
alimentados en las
salidas; estos incluyen
las lecciones
aprendidas para que
sean incluidas en el
plan
Aunque no hay un
proceso específico,
como salida del 10.3
están las lecciones
aprendidas
PI – Integración
de producto
SG 1 – Prepararse
para la integración de
producto
No cubierta por
PMBOK®
SG 2 – Asegurar
compatibilidad de
interfaces
5.1 – Obtener
requerimientos
calidad
PMBOK® no establece
directamente nada
relacionado con
interfaces pero si se

30
obtienen como
requerimientos se
asegura su
cumplimiento hasta el
final
SG 3 – Ensamblar
componentes de
producto y entregar el
producto
4.6 – Cerrar el proyecto o
fase
5.4 – Verificar el alcance
PMBOK® no se refiere
a actividades de
ingeniería como el
ensamble pero en estos
dos procesos asegura
la aceptación y entrega
del producto del
proyecto o la fase a
otros.
RD – Desarrollo
de
Requerimientos
SG 1 – Desarrollar
requerimientos del
cliente
5.1 – Obtener
requerimientos
SG 2 – Desarrollar
requerimientos del
producto
5.1 – Obtener
requerimientos
SG 3 – Analizar y
validar requerimientos
5.1 – Obtener
requerimientos
RSKM –
Gestión de
Riesgos
SG 1 – Prepararse
para la gestión de
riesgos
11.1 – Planear Gestión
de Riesgos
SG 2 – Identificar y
analizar riesgos
11.2 – Identificar riesgos
del proyecto
11.3 – Ejecutar análisis
cualitativo de riesgo
11.4 – Ejecutar análisis
cuantitativo de riesgos
SG 3 – Mitigar riesgos
11.5 – Planear
respuestas a riesgos
PMBOK® excede los
requisitos de CMMi en
cuanto a la gestión de
riesgos extendiendo el
alcance hasta el
monitoreo y control y
definiendo acciones
adicionales a la
mitigación como
transferir, evitar, asumir
y contener.
TS – Solución SG 1 – Seleccionar No cubierta por

31
Técnica soluciones para
componentes de
producto
PMBOK®
SG 2 – Desarrollar el
diseño
No cubierta por
PMBOK®
SG 3 – implementar el
diseño del producto
No cubierta por
PMBOK®
VER –
Verificación
SG 1 – Prepararse
para la verificación
SG 2 - Ejecutar
revisiones por pares
No cubierta por
PMBOK® aunque como
técnica en el 8.3 –
Realizar control de
calidad, se incluyen las
inspecciones, no se
menciona que sean por
pares.
SG 3 – Verificar
productos de trabajo
seleccionados
8.2 – Realizar el
calidad
VAL –
Validación
SG 1 – Prepararse
para la validación
SG 2 - Validar el
producto y los
componentes de
producto
calidad
OT –
Entrenamiento
organizacional
SG 1 – Establecer la
capacidad de
entrenamiento
organizacional
No cubierta por
PMBOK®
SG 2 – Proveer el
entrenamiento
necesario
humanos
equipo del proyecto
4
QPM – Gestión
Cuantitativa de
Proyectos
cuantitativamente el
proyecto
8.2 – Realizar el
calidad
estadísticamente el
desempeño de los
subprocesos
calidad
PMBOK® establece
herramientas y técnicas
estadísticas de control
de procesos como las
tablas de control en
este proceso.

32
OPP –
Desempeño del
Proceso
Organizacional
SG 1 – Establecer
líneas base de
desempeño y modelos
presupuesto
En PMBOK®, como
salida de este proceso,
se establece la Línea
Base de Medición de
Desempeño del
proyecto que se
operará a través del
método de Valor
Ganado
5
OID –
Innovación y
Despliegue
Organizacional
SG 1 – Seleccionar
mejoramientos
No cubierta por
PMBOK®
SG 2 – Desplegar
mejoramientos
No cubierta por
PMBOK®
Analizando la tabla se puede observar que se puede lograr un muy amplio
cubrimiento de CMMi® con los procesos, técnicas, entradas y salidas del
PMBOK®; sin embargo, debe llevarse a cabo un proceso de definición
cuidadoso de los métodos y prácticas que se vayan a implementar para
lograr cubrimiento completo.
1.6 COMPARACIÓN DE METAS GENÉRICAS CMMI® A
PROCESOS DE PMBOK®
Si bien es importante que haya apoyo del PMBOK® para las prácticas
específicas o algunas áreas de proceso, también lo es el que las prácticas
genéricas sean apoyadas ya que determinan la institucionalización y
mejoramiento del proceso en la organización.
A continuación presento la relación entre estas prácticas genéricas de
CMMi® y los procesos del PMBOK®.

33
Tabla 7 - Comparación de Metas Genéricas de CMMi® contra Procesos del PMBOK®
Práctica Genérica PMBOK®
GP 2.1 – Establecer una política
organizacional
PMBOK® define como entradas a
muchos de sus procesos los
Activos de Proceso de la
Organización y se refiere, en
Gestión de Calidad, a la inclusión
de la Política de Calidad de la
organización. Asume, entonces,
que las políticas
organizacionales ya se
encuentran en estos activos de
proceso.
GP 2.2 – Planear el proceso 4.2 – Desarrollar el Plan del
Proyecto
GP 2.3 – Proveer recursos 6.3 – Estimar Recursos de las
Actividades
GP 2.4 – Asignar responsabilidades 4.1 – Desarrollar el Project Charter
(Responsabilidad para el gerente
de proyecto)
9.1 – Planear Recursos Humanos
(Responsabilidades del equipo del
proyecto)
GP 2.5 – Entrenar la gente 9.3 – Desarrollar el Equipo del
proyecto
GP 2.6 – Administra configuraciones 4.4 – Monitorear y Controlar el
Trabajo del Proyecto
GP 2.7 – Identificar e involucrar
stakeholders relevantes
10.1 – Identificar Stakeholders
GP 2.8 – Monitorear y controlar el
proceso
4.4 – Monitorear y Controlar el
Trabajo del Proyecto
5.5 – Controlar el Alcance
6.6 – Controlar el Cronograma
7.3 – Controlar Costos
8.3 – Realizar control de calidad
11.6 – Monitorear y Controlar
Riesgos
4.5 – Ejecutar el Control Integrado
de Cambios
GP 2.9 – Objetivamente evaluar
adherencia
8.2 – Realizar el Aseguramiento de
Calidad
GP 2.10 – Revisar estado con
niveles superiores
10.5 – Reportar el Desempeño
GP 3.1 – Institucionalizar un proceso
definido
No cubierta por PMBOK®

34
5. METODOLOGÍA
Existe una alta relación entre el PMBOK® y CMMi® por lo que llevar una
implementación de prácticas de la mano del primero nos deja en una
excelente posición, con fortalezas más allá de niveles 2 y 3.
El proceso de implementación sugerido, a través del PMBOK® se centra en
la implantación de los procesos de gerencia de proyectos y en el cierre de
las brechas que resulten con CMMi®. De esta manera se buscará implantar
una adecuada gerencia de proyectos, llegando a CMMi® como una
ganancia adicional, si se siguen los pasos adecuados.
Los pasos sugeridos para el proceso de implementación de CMMi® desde la
gerencia de proyectos con PMBOK®, se ha conceptualizado así:
1) DETERMINACIÓN DEL OBJETIVO DEL MEJORAMIENTO
Siempre el objetivo debe estar ligado a una meta de negocio, no a mejorar
por mejorar. A través de la definición de la meta de negocio se obtiene el
nivel de madurez deseado, si el mejoramiento se aborda por representación
escalonada, o las áreas de proceso a mejorar, si se aborda la representación
continua.
2) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN
ADMINISTRACIÓN DE PROYECTOS
Podemos apoyarnos en el Organizational Project Management Maturity
Model (OPM3®), otro de los estándares de gerencia de proyectos del PMI®,
que nos permite evaluar el nivel de madurez de la organización en cuanto a
la gerencia de proyectos se refiere, para determinar los aspectos de mejora
o implantación de prácticas específicas, de acuerdo a la idiosincrasia,
situación de la empresa, mercado y clientes objetivo, nivel y cantidad de
personal, estructura organizacional y demás factores determinantes o
limitantes de la formalidad y prácticas.
3) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN INGENIERÍA

35
Al igual que el proceso anterior, pero enfocado en aquellas actividades o
procesos de ingeniería propios de la empresa. En esta área el PMBOK® no
aporta en su totalidad por lo que se deberá referir a las áreas de proceso de
ingeniería y a las mejores prácticas de la industria específica en que se lleve
a cabo el mejoramiento.
4) ESTABLECIMIENTO DE LA SITUACIÓN ACTUAL EN GESTIÓN DE
PROCESOS
Es muy importante tener una adecuada gestión de procesos. En esto nos
apoyan las Áreas de Proceso seleccionadas, Definición de Procesos de la
Organización y Enfoque de Procesos de la Organización de nivel 3 de
CMMi® que, en nuestro concepto y a pesar de que estén en nivel 3, deben
iniciar su desarrollo desde nivel 2, junto con la Gestión de Configuración. El
análisis de la situación en gestión de procesos nos permite establecer los
trabajos previos de definición de estándares, documentación, archivos de
procesos, biblioteca de procesos y demás elementos de soporte a la
definición, documentación y despliegue de procesos y prácticas.
5) SOCIALIZACIÓN DE LA SITUACIÓN ACTUAL DE LA ORGANIZACIÓN
A través de presentaciones a grupos específicos y a alta gerencia, se
presenta la situación actual y el objetivo de mejoramiento establecido,
indicando el nivel de compromiso que se requiere para llegar a la meta y una
estimación del tiempo del esfuerzo a realizar, bajo los supuestos adecuados
de disponibilidad de personal y compromiso de la alta gerencia.
6) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN
ADMINISTRACIÓN DE PROYECTOS
Con base en las necesidades específicas encontradas en el análisis de
situación actual en gerencia de proyectos, se establecen los puntos de
entrenamiento en gerencia de proyectos. Dado que la gerencia de proyectos
debe verse como política medular en la organización, se sugiere siempre
llevar este entrenamiento al público más amplio posible y de la manera más

36
completa, haciendo un enfoque claro en los logros que se ha planteado la
organización.
7) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN INGENIERÍA
Con base en las mejores prácticas que se ha identificado que requieren
mejoramiento o implantación, cubriendo siempre las Áreas de Proceso
seleccionadas de ingeniería del nivel deseado de madurez y apoyándose en
las mejores prácticas de la industria objetivo de la organización.
8) DESARROLLO DEL PLAN DE ENTRENAMIENTO EN GESTIÓN DE
PROCESOS
Si se requiere capacitar a la organización o a un área específica que se
encargará de la administración de los procesos, se lleva a cabo este plan de
entrenamiento. Como mínimo, para toda la organización deberá haber un
entrenamiento de utilización de procesos y acerca de cómo se definen las
solicitudes de mejoramiento y se tramitan, de acuerdo al nivel objetivo.
9) EJECUCIÓN DE PLANES DE ENTRENAMIENTO
Los entrenamientos planteados se llevan a cabo manteniendo un rastreo a
los participantes, seguimiento al desarrollo de cada entrenamiento y una
medición de efectividad y relevancia a lo largo de todo el proyecto,
proveyendo los refuerzos que se requieran a lo largo del mismo.
10) DEFINICIÓN DE LOS EQUIPOS DE TRABAJO DE MEJORAMIENTO
Se puede observar que los entrenamientos no se discriminan a miembros
específicos de la organización; obviamente se involucran en ingeniería los
responsables de las actividades de ingeniería, sin embargo, para procesos y
gerencia de proyectos se sugiere llevarlos al público más amplio posible.
Una vez dictados los entrenamientos, o a la par con los mismos, se definen
los equipos que llevarán a cabo la definición de procesos, prácticas y el
pilotaje y despliegue de los mismos.

37
11) DESARROLLO DEL PLAN DE IMPLEMENTACIÓN DE GESTIÓN DE
PROCESOS
Este plan es específico para el equipo de mejoramiento de procesos y define
la forma de atacar los puntos de mejora encontrados, el orden, la prioridad y
las reglas del equipo.
12) DESARROLLO DEL PLAN DE MEJORAMIENTO DE GERENCIA DE
PROYECTOS
Específicamente para el grupo a cargo del mejoramiento de la gerencia de
proyectos. Es importante que en este grupo participen todos los gerentes,
líderes o coordinadores de proyectos de la organización, quienes conocen la
forma específica de trabajo.
13) DESARROLLO DEL PLAN DE MEJORAMIENTO DE INGENIERÍA
Enfocado en los puntos de mejora de ingeniería, se desarrolla con los
practicantes técnicos de la organización, indicando las prácticas a implantar,
seleccionadas de los entrenamientos y acordes con la compañía.
14) DISEÑO DE PRÁCTICAS
Cada uno de los equipos de mejoramiento diseña, entonces, las prácticas
adecuadas para cubrir las oportunidades de mejora. Las prácticas deben ser
adecuadas a la situación del personal, mercado, tipos de proyectos,
duración, tipos de productos a desarrollar. Debe evitarse la sobre-
formalización, cuando la organización no lo requiere o la utilización de
prácticas demasiado densas si el personal no está acostumbrado a este
nivel de formalidad.
15) VERIFICACIÓN DE PRÁCTICAS DISEÑADAS CONTRA MODELO
CMMI®
Antes de pilotar las prácticas debe verificarse que cubran las brechas
encontradas en la evaluación contra las prácticas de las áreas de proceso de
CMMi®

38
16) PILOTAJE DE PRÁCTICAS
Una vez definidas las prácticas, se pilotan en proyectos específicos o
situaciones que permitan evaluar su corrección, completitud y relevancia
para el objetivo de la organización.
17) AJUSTE DE PRÁCTICAS
Como resultado del pilotaje se obtendrán puntos de mejora o ajuste a las
prácticas definidas. Una vez ajustadas se establecen como línea base del
proceso.
18) DESPLIEGUE DE PRÁCTICAS
El despliegue de prácticas estará a cargo de los equipos de mejoramiento
quienes establecerán, también, la forma en que serán incorporadas al
quehacer de la organización, preferiblemente en nuevos proyectos o en
fases próximas a iniciar en proyectos existentes, si es que la utilización de la
práctica no traumatiza los compromisos adquiridos en el proyecto con los
stakeholders.
19) OBTENCIÓN DE EVIDENCIAS
Durante la utilización de las prácticas debe mantenerse un levantamiento de
evidencias tendiente a generar la Base de Datos de los Indicadores de
Implementación de Proceso (PIIDB - Practice Implementation Indicator Data
Base) sobre la que, posteriormente, se apoyará la evaluación SCAMPI que
valorará oficialmente a la organización en el nivel CMMi® seleccionado8.
8
Integración de CMMi y del PMBOK® para proyectos exitosos. Mauricio Morales, PMP®. Portal Líder
de Proyecto.
http://www.liderdeproyecto.com/manual/integracion_de_cmmi_y_del_pmbok_para_proyectos_exi
tosos.html

39
CAPÍTULO N°2 - FUNDAMENTOS TEÓRICOS
1. GESTIÓN DE PROYECTOS
1.1 ¿QUÉ ES UN PROYECTO?
Según la Guía del PMBOK®:
Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un
producto, servicio o resultado único. La naturaleza temporal de los proyectos
implica que un proyecto tiene un principio y un final definidos.
El final se alcanza cuando se logran los objetivos del proyecto, cuando se
termina el proyecto porque sus objetivos no se cumplirán o no pueden ser
cumplidos, o cuando ya no existe la necesidad que dio origen al proyecto.
Asimismo, se puede poner fin a un proyecto si el cliente (cliente,
patrocinador o líder) desea terminar el proyecto. Que sea temporal no
significa necesariamente que la duración del proyecto haya de ser corta. Se
refiere a los compromisos del proyecto y a su longevidad. En general, esta
cualidad de temporalidad no se aplica al producto, servicio o resultado
creado por el proyecto; la mayor parte de los proyectos se emprenden para
crear un resultado duradero. Por ejemplo, un proyecto para construir un
monumento nacional creará un resultado que se espera perdure durante
siglos. Por otra parte, los proyectos pueden tener impactos sociales,
económicos y ambientales susceptibles de perdurar mucho más que los
propios proyectos.
Cada proyecto genera un producto, servicio o resultado único. El resultado
del proyecto puede ser tangible o intangible. Aunque puede haber elementos
repetitivos en algunos entregables y actividades del proyecto, esta repetición
no altera las características fundamentales y únicas del trabajo del proyecto.
Por ejemplo, los edificios de oficinas se pueden construir con materiales
idénticos o similares, y por el mismo equipo o por equipos diferentes. Sin
embargo, cada proyecto de construcción es único, posee una localización
diferente, un diseño diferente, circunstancias y situaciones diferentes,
diferentes interesados, etc.

40
Según el ISO 21500:
La Norma ISO 21500 define un proyecto como un conjunto único de
procesos que consta de actividades coordinadas y controladas, con fechas
de inicio y fin, que se llevan a cabo para lograr los objetivos del proyecto. El
logro de los objetivos del proyecto requiere la realización de entregables que
satisfagan requisitos específicos. Además un proyecto puede estar sujeto a
múltiples restricciones, tales como: tiempo, costo y recursos.
1.2 PMBOK VS ISO 21500
En el Perú, la Guía del PMBOK® es la más utilizada, según el gráfico a
continuación, año a año va creciendo la cantidad de certificados como PMP.
Ilustración 4 – Informativo Mensual Febrero 2010. PMI PERU LIMA CHAPTER.
El PMI, entendiendo la necesidad de unificar las diferentes metodologías y
marcos de trabajos existentes en la actualidad en Gestión de Proyectos
participa en el grupo de análisis de la ISO 21500, teniendo un papel
relevante ocupando la Secretaria del comité.
El 1ero de Mayo 2014, INDECOPI: Organismo Peruano de Normalización,
emitió la Norma Técnica Peruana NTP ISO 21500:2014, adoptándose
formalmente la ISO 21500 como norma nacional.

41
PÚBLICO OBJETIVO DEL ISO 21500 Y DEL PMBOK
GRUPOS DE PROCESOS
GRUPOS DE MATERIA
COMPARATIVO ISO 21500 vs PMBOK
Ilustración 5 – Presentación del Webinar “Conoce la Norma ISO 21500 y cómo se relaciona con la Guía del
PMBOK®”. Lorenzo Armenta Fonseca. http://sgcampus.com.mx/2014/02/conoce-la-norma-iso-21500-y-
como-se-relaciona-con-la-guia-del-pmbok/

42
Debido a que el PMBOK abarca más procesos y tiene como público objetivo
a Directores, Gerentes y Jefes de Proyecto, así como al equipo que lo
conforman, por ser buenas prácticas reconocidas mundialmente, no sé
ampliará la información del ISO 21500, en cambio, si ampliaremos la
información del PMBOK® con la finalidad de posteriormente revisar como el
CMMI® se aplica en la Gestión de Proyectos.
1.3 CARACTERÍSTICAS DE LOS PROYECTOS
Un proyecto se puede definir generalmente por las siguientes características:
• Incluye un objetivo, producto o resultado único que se puede definir
claramente. Un ejemplo de esto es un proyecto para reparar los daños
causados por un impacto de una aeronave. Una vez reparados los daños
del impacto, concluirá el proyecto.
• Suele tener restricciones u objetivos definidos en términos de
costo, programa (tiempo) y requisitos de alcance de objetivos. Por
ejemplo, un límite de tiempo. La aeronave dañada deberá repararse
dentro de un plazo específico para no perder varias horas del plan de
vuelos. Tendrá que hacerse todo lo posible para concluir la reparación
dentro de este plazo.
• Emplea las habilidades y los talentos de múltiples profesiones y
organizaciones. Con frecuencia, los proyectos están relacionados con
tecnologías avanzadas y dependen de tareas interdependientes que
pueden ocasionar problemas nuevos y únicos. Los requisitos en cuanto a
tareas y habilidades varían de acuerdo con el proyecto. En la reparación
de los daños de una aeronave participan muchas disciplinas como por
ejemplo: ingenieros mecánicos y aeronáuticos, inspectores de seguridad
y representantes del fabricante de la aeronave. Estas personas podrían
trabajar en el proyecto de forma conjunta, como un equipo
multidisciplinario.
• Es único. Por lo general, un proyecto es una actividad única que nunca
se repite en forma exacta. Generalmente, el daño por un impacto será un
caso único. El alcance de los daños dependerá del objeto que causó el

43
impacto, del lugar en donde ocurrió, de la forma en la que se produjo el
impacto, de la velocidad que llevaba y de otros factores.
• No es del todo familiar. Puede incorporar nueva tecnología y en
consecuencia poseer elementos importantes de incertidumbre y riesgo.
El fracaso del proyecto podría comprometer a la propia organización o a
sus objetivos.
• Se trata de una actividad temporal. Se emprende para alcanzar un
objetivo en un determinado período de tiempo y una vez logrado, el
proyecto deja de existir. Esto se aplica tanto al proyecto en sí como a la
estructura organizacional creada para llevarlo a cabo. Una vez reparada
la aeronave, el equipo de reparación regresa a su terminal de base y bien
sigue de guardia, o se marcha a casa. La próxima vez que se necesite a
este equipo, podría estar compuesto de personas distintas, que trabajan
en otra aeronave y en condiciones diferentes.
• Forma parte del proceso que supone trabajar para cumplir un
objetivo. A lo largo del proceso, el proyecto pasa por distintas fases y,
por consiguiente, las tareas, las personas, la estructura organizacional y
los recursos cambian a medida que el proyecto avanza de una fase a
otra. Los proyectos suelen tener puntos de inicio y terminación
claramente definidos. En el caso de la reparación de la aeronave, habrá
una inspección, una evaluación, una solución, una Implementación, una
terminación y pruebas de verificación.
• Todo ello forma parte de un proceso entrelazado. No es frecuente que
los proyectos se lleven a cabo de forma aislada. Suelen existir algunos
enlaces entre los distintos proyectos que está llevando a cabo una
determinada organización.
• Generalmente no es tan importante para la organización. Por lo
general, los proyectos no constituyen el principal objetivo de la
organización. Hay excepciones, como es el caso de las organizaciones
dedicadas exclusivamente a investigación y desarrollo y las compañías
que se establecen con el único propósito de planificar y ejecutar un solo
proyecto. Por lo regular, la organización se interesa por tener objetivos
funcionales definidos, y el proyecto está subordinado a éstos.

44
• Es relativamente complejo. Los proyectos cuentan con la participación
de equipos multidisciplinarios y persiguen metas y objetivos definidos.
Por lo tanto, tienden a ser relativamente complejos desde el punto de
vista organizacional, si se comparan con los procesos funcionales
estándar que se realizan en la organización9.
1.4 DIRECCIÓN DE PROYECTOS ORGANIZACIONAL
(PMO)
Es un marco de referencia para mantener toda la organización enfocada en
la estrategia general. La PMO proporciona indicaciones acerca de cómo se
deben priorizar, gestionar, ejecutar y medir los proyectos, programas,
portafolios y otros trabajos organizacionales a fin de cumplir de la mejor
manera los objetivos estratégicos.
En el siguiente gráfico se muestra como la Dirección de Proyectos
organizacional impulsa a una organización que implementa la dirección de
proyectos, y programas y la gestión de portafolios a cumplir los objetivos
estratégicos10.
9
Gestión de Proyectos. Edinburgh Business School. Heriot – Watt University. Alexander Roberts, Dr.
William Wallace. 2011
10
Preparación para el Examen PMP. Rita Mulcahy. Octava Edición.

45
Ilustración 6 Dirección de Proyectos Organizacional
1.5 ¿QUÉ ES LA GESTIÓN DE PROYECTOS?
La gestión de proyecto se ocupa en gran medida de planificar y controlar las
tres variables clave asociadas con los proyectos. Estas variables son tiempo,
costo y calidad. Están interrelacionadas y muchas veces un cambio en
cualquiera de las variables tiene un impacto importante en las demás.
Debido a que la gestión de proyecto se ocupa de administrar el cambio,
dentro de las restricciones impuestas por las tres variables clave de tiempo,
costo y calidad, cabe esperar que las estructuras organizacionales para la
gestión de proyecto difieran de las estructuras organizacionales
tradicionales, que fueron concebidas para ayudar a los directivos a
administrar en entornos más estables. Las estructuras organizacionales para
la gestión de proyecto son examinadas y contrastadas con las estructuras

46
organizacionales de gestión más tradicionales. Los proyectos tienen un ciclo
de vida finito, es decir, tienen puntos específicos de inicio y terminación, y,
en consecuencia, cualquier equipo de proyecto o estructura organizacional
que se constituya para gestionar un proyecto tendrá un ciclo de vida finito.
La gestión de proyecto es una profesión internacional y multidisciplinaria
realmente única. Esta característica ha llevado a desarrollar estándares
internacionales genéricos y a encomendar la gestión a un nuevo tipo de
profesional que opera de forma diferente a los directivos funcionales
tradicionales.
1.6 ¿QUÉ ES EL PMI?
El PMI (Project Management Institute) es la institución líder en la Industria de
la Gerencia de Proyectos, dedicada al progreso y fomento de su aplicación
efectiva a través de la práctica. Fundada en 1969 en Pensilvania, Estados
Unidos de Norteamérica, actualmente está presente en alrededor de 172
países, con más de 500,000 miembros y profesionales certificados,
organizados en más de 250 Capítulos.
El capítulo PMI Lima Perú agrupa a los profesionales del Perú de distintas
áreas comprometidos con la mejora de las organizaciones a través de la
aplicación de las buenas prácticas de gestión de proyectos establecidas por
el PMI11.
1.7 ¿QUÉ ES EL PMBOK?
La Guía del PMBOK® identifica ese subconjunto de fundamentos para la
gestión de proyectos generalmente reconocido como buenas prácticas.
“Generalmente reconocido” significa que los conocimientos y prácticas
descritos son aplicables a la mayoría de los proyectos, la mayoría de las
veces, y que existe consenso sobre su valor y utilidad. “Buenas prácticas”
significa que se está de acuerdo, en general, en que la aplicación de
conocimientos, habilidades, herramientas y técnicas puede aumentar las
posibilidades de éxito de una amplia variedad de proyectos. "Buenas
prácticas" no significa que el conocimiento descrito deba aplicarse siempre
11
Project Management Institute - Perú.
http://www.pmi.org.pe/portal/index.php?option=com_content&view=article&id=86&Itemid=34

47
de la misma manera en todos los proyectos; la organización y/o el equipo de
dirección del proyecto son los responsables de establecer lo que es
apropiado para cada proyecto concreto.
La Guía del PMBOK® también proporciona y promueve un vocabulario
común para el uso y la aplicación de los conceptos de la dirección de
proyectos dentro de la profesión de la dirección de proyectos. Un vocabulario
común es un elemento esencial en toda disciplina profesional. El Léxico de
Términos de Gestión de Proyectos del PMI proporciona el vocabulario
profesional de base que puede ser utilizado de manera consistente por
directores de proyecto, directores de programa, directores de portafolios y
otros interesados12.
1.8 ALCANCE DE LA GUÍA DEL PMBOK®:
Como se aprecia en la Ilustración 4, los grupos de procesos de la dirección
de proyectos se vinculan entre sí a través de los resultados que producen,
son actividades superpuestas que tienen lugar a lo largo de todo el proyecto.
La salida de un proceso normalmente se convierte en la entrada para otro
proceso o es un entregable del proyecto.
Los grupos de procesos dados por la Guía de Fundamentos en Dirección de
Proyectos PMBOK 4ta edición son los siguientes:
i. Iniciación.- Son procesos realizados para definir un nuevo proyecto o
una nueva fase de un proyecto ya existente, mediante la obtención de
la autorización para comenzar dicho proyecto o fase.
ii. Planificación.- Son procesos requeridos para establecer el alcance
del proyecto, refinar los objetivos y definir el curso de acción
necesario para alcanzar los objetivos para cuyo logro se emprendió el
proyecto.
12
Guía de los Fundamentos para la Dirección de Proyectos (Guía del PMBOK). Quinta Edición. Project
Management Institute. 2013.

48
iii. Ejecución.- Aquellos procesos realizados para completar el trabajo
definido en el plan para la dirección del proyecto a fin de cumplir con
las especificaciones del mismo.
iv. Seguimiento y Control.- Son procesos requeridos para dar
seguimiento, analizar y regular el progreso y el desempeño del
proyecto, para identificar áreas en las que el plan requiera cambios y
para iniciar los cambios correspondientes.
v. Cierre.- Son procesos realizados para finalizar todas las actividades a
través de todos los grupos de procesos, a fin de cerrar formalmente el
proyecto o una fase del mismo.
Ilustración 7 - Grupo de procesos de la Dirección de Proyectos
La Guía de los Fundamentos en Gestión de Proyectos PMBOK 4ta
edición, tiene nueve áreas de conocimiento:
i. Gestión de la Integración.- Incluye los procesos y actividades
necesarios para identificar, definir, combinar, unificar y coordinar los
diversos procesos y actividades de la dirección de proyectos dentro
de los grupos de procesos de gestión de proyectos. La integración
incluye características de unificación, consolidación, articulación, así
como las acciones integradoras que son cruciales para la terminación
del proyecto, la gestión exitosa de las expectativas de los interesados
y el cumplimiento de los requisitos.

49
ii. Gestión del Alcance.- Incluye los procesos necesarios para
garantizar que el proyecto incluya todo el trabajo requerido para
completarlo con éxito. El objetivo principal de la Gestión del Alcance
del Proyecto es definir y controlar qué se incluye y qué no se incluye
en el proyecto.
iii. Gestión del Tiempo.- Incluye los procesos requeridos para
administrar la finalización del proyecto a tiempo. Estos procesos
interactúan entre sí y con procesos de las otras áreas de
conocimiento. Dependiendo de las necesidades del proyecto, cada
proceso puede implicar el esfuerzo de un grupo o persona. Cada
proceso se ejecuta por lo menos una vez en cada proyecto y en una o
más fases del proyecto, en caso de que el mismo esté dividido en
fases.
iv. Gestión del Costo.- Incluye los procesos involucrados en estimar,
presupuestar y controlar los costos de modo que se complete el
proyecto dentro del presupuesto aprobado. En algunos proyectos,
especialmente en aquéllos de alcance más pequeño, la estimación de
costos y la preparación del presupuesto de costos están tan
estrechamente ligadas que se consideran un solo proceso, que puede
realizar una sola persona en un periodo de tiempo relativamente
corto.
v. Gestión de la Calidad.- Incluye los procesos y actividades de la
organización ejecutante que determinan responsabilidades, objetivos
y políticas de calidad a fin que el proyecto satisfaga las necesidades
para las cuales fue emprendido, buscando la mejora continua de los
procesos llevados a cabo durante el proyecto.
vi. Gestión de Recursos Humanos.- Incluye los procesos que
organizan, gestionan y conducen el equipo del proyecto. El equipo del
proyecto está conformado por las personas a las que les ha sido
asignados roles y responsabilidades para completar el proyecto. Es
importante la participación de todos los miembros en la toma de
decisiones y la planificación del proyecto.
vii. Gestión de las Comunicaciones.- Incluye los procesos requeridos
para garantizar la generación, recopilación, distribución,

50
almacenamiento, recuperación y disposición final de la información
del proyecto de tal forma que sean adecuados y oportunos. Una
comunicación eficaz crea un puente entre los diferentes interesados
involucrados en un proyecto, conectando distintos entornos culturales
y organizacionales en la ejecución o resultado del proyecto.
viii. Gestión de Riesgos.- Incluye los procesos relacionados con la
planificación de la gestión, identificación, análisis, planificación de
respuesta ante riesgos así como su monitoreo y control en un
proyecto. Se ocupa primordialmente de los costos de los recursos que
demandan las actividades programadas. Incluye los procesos de
estimación de costos, preparar el presupuesto de costos y el control
de los mismos.
ix. Gestión de Adquisiciones.- Incluye los procesos de compra o
adquisición de los productos, servicios o resultados que son
necesarios obtener fuera del equipo del proyecto. Incluye los aspectos
relacionados con la gestión de los contratos.

51
2. CMMI®
2.1 ¿QUÉ ES CMMI®?
Los modelos CMMI® (Capability Maturity Model Integration) es un
conjunto de mejores prácticas que ayudan a las organizaciones a
mejorar sus procesos. Fue desarrollado por equipos de producto con
miembros de la industria, Gobierno y el Instituto de Ingeniería de
Software (SEI) de la Universidad de Carnegie Mellon.
Un modelo de madurez y de capacidad (Capability Maturity Model,
CMM), incluyendo CMMI®, es un modelo de evaluación de los
procesos de una organización. Los CMMs contienen los elementos
esenciales de los procesos eficaces. Estos elementos se basan en los
conceptos desarrollados por Crosby, Deming, Juran y Humphrey.
Existen modelos de madurez, estándares, metodologías y directrices
que pueden ayudar a las organizaciones a mejorar sus procesos de
negocio y alcanzar sus objetivos propuestos. Sin embargo, la mayoría
de los enfoques de mejoramiento se enfocan sobre una parte
específica del negocio y no tienen un enfoque sistémico a los
problemas que estas enfrentan. El centrarse en la mejora de un área
del negocio, estos modelos han aumentado las barreras que existen
en las organizaciones.
CMMI® provee una oportunidad de evitar o eliminar esas barreras.
Consiste de buenas prácticas que direccionan las actividades de
desarrollo aplicadas a los productos y servicios. Se ocupa de las
prácticas que cubren el ciclo de vida del producto, desde su
concepción, hasta la entrega y mantenimiento.
El Modelo CMMI® se ha convertido en el estándar de facto para
evaluar y mejorar los procesos de desarrollo y mantenimiento de
software ya que provee guías para aplicar las mejores prácticas en
una organización de desarrollo.
2.2 COMPONENTES DEL MODELO
Área de Proceso (PA)

52
Un área de proceso es una agrupación de prácticas relacionadas en
una determinada área que, cuando se ejecutan colectivamente
permiten cumplir con las metas consideradas importantes para
realizar mejoras significativas en esta área.
CMMIDEV 1.3, está conformado por 22 áreas de procesos,
clasificadas de la siguiente forma:
• 16 son áreas de proceso de base
• 1 es un área de proceso compartida
• 5 son áreas de proceso específicas de desarrollo.
Asimismo, se pueden agrupar en cuatro categorías: Gestión de
Procesos (Process Management), Gestión de Proyectos (Project
Management), Ingeniería (Engineering), Soporte (Support), las cuales
se enumeran en la siguiente tabla:
Tabla 1. Procesos y Categorías de CMM DEV 1.3
Nombre del Proceso Categoría
CAR Análisis de causa raíz (Causal Analysis and Resolution) Soporte
CM Gestión de la Configuración (Configuration Management) Soporte
DAR Análisis de las Decisiones y Resolución (Decision Analysis
and Resolution)
Soporte
IPM Gestión Integrada de Proyectos (Integrated Project
Management)
Gestión de Proyectos
MA Medición y Análisis (Measurement and Analysis) Soporte
OPD Definición Procesos Organizacionales (Organizational
Process Definition)
Gestión de Procesos
OPF Definición del proceso de Organización (Organizational
Process Focus)
OPM Gestión del Desempeño Organizacional (Organizational
Performance Management)
OPP Rendimiento Proceso Organizacional (Organizational
Process Performance)
OT Entrenamiento Organizacional (Organizational Training) Gestión de Procesos
PI Integración del Producto (Product Integration) Ingeniería
PMC Control y Monitoreo de Proyectos (Project Monitoring and
Control)
PP Planeación de Proyectos (Project Planning) Gestión de Proyectos
PPQA Aseguramiento calidad Procesos y Productos (Process and
Product Quality Assurance)
Soporte
QPM Gestión Cuantitativa de Proyectos (Quantitative Project
Management)

53
RD Desarrollo de Requerimientos (Requirements Development) Ingeniería
REQM Gestión de Requerimientos (Requirements Management) Gestión de Proyectos
RSKM Gestión de Riesgos (Risk Management) Gestión de Proyectos
SAM Gestión acuerdo Proveedores (Supplier Agreement
Management)
TS Solución Técnica (Technical Solution) Ingeniería
VAL Validación (Validation) Ingeniería
VER Verificación (Verification) Ingeniería
Secciones.- Las secciones son las diferentes partes que conforman
las áreas de proceso son las siguientes:
Declaración del propósito (Purpose Statement).- Una declaración
del propósito describe la finalidad del área de proceso y es un
componente informativo.
Notas Introductorias (Introductory Notes).- Describe los conceptos
principales cubiertos por el área de proceso y es un componente
informativo.
Áreas de Proceso relacionadas (Related Process Areas).-
Referencia a secciones de otras áreas de proceso que podrían
interactuar con otras áreas de interés. La sección de áreas de
proceso relacionadas es un componente informativo.
Metas Específicas (Specific Goals - SG).- Abarcan las
características únicas que describen que debe implementarse para
satisfacer el área de procesos. Son componentes requeridos del
modelo y se usan en las evaluaciones para determinar si el área de
procesos se ha satisfecho o no. Cada una de ellas se identifica de
forma consecutiva dentro de cada área con la sigla SG.
Metas Genéricas (Generic Goals - GG).- Orientadas a apoyar la
planeación e implementación de las actividades de los proyectos o la
organización. Son componentes requeridos (required) y se usan en
las evaluaciones para determinar si el área de proceso se ha
satisfecho o no. Se llaman genéricas porque representan una
característica que debe ser transversal a todo el proceso asociado al
área de procesos.

54
Prácticas específicas (Specific Practice - SP).- Actividades
consideradas necesarias (should be) para el cumplimiento de la meta
específica asociada. Las prácticas son los bloques constructivos
principales sobre los que descansa la madurez de los procesos de la
organización. Normalmente se esperan que estén presentes.
Prácticas genéricas (Generic Practices - GP).- Actividades que
aseguran que los procesos asociados con las áreas de proceso sean
efectivos, repetibles y perdurables. Contribuyen al cumplimento de las
metas genéricas aplicables a una área de proceso determinada. Estos
componentes se esperan que estén presentes (expected).
Sub prácticas (SubPractices).- Descripciones detalladas que
proporcionan la orientación para interpretar y ejecutar una práctica
específica o genérica.
Elaboraciones de prácticas genéricas (Generic Practice
Elaborations).- Las elaboraciones aparecen después de la práctica
genérica para proporcionar una guía sobre cómo puede aplicarse la
práctica genérica en el contexto de un área de proceso. Es un
componente informativo en el modelo.
Componentes.- Los componentes del modelo se agrupan en tres
categorías (requeridos, esperados e informativos) descritas a
continuación:
Requeridos.- Son componentes CMMI® que son esenciales para el
logro de la mejora en una determinada área de proceso. Los
componentes requeridos son las metas genéricas y específicas.
Esperados.- Son componentes CMMI® que describen las actividades
que son importantes en el logro de un componente requerido. Los
componentes esperados son las prácticas genéricas y específicas.
Informativos.- Son componentes que ayudan los usuarios del modelo
CMMI a entender los componentes esperados y requeridos. Pueden
ser ejemplos en un recuadro, explicaciones detalladas u otras
informaciones útiles. Las sub-prácticas, las notas, las referencias, los
títulos de metas, los títulos de prácticas, las fuentes, los ejemplos de
productos de trabajo y las elaboraciones de prácticas genéricas son
componentes informativos del modelo.

55
Las relaciones entre los elementos que conforman el área de proceso
y que forman parte de las secciones y componentes, se muestran en
la figura 10.
Figura 1. Relaciones entre elementos del área de proceso [CMMI, 2010]
2.3 NIVELES DEL MODELO
Los niveles se utilizan en CMMI-DEV® para describir un camino
evolutivo recomendado para una organización que quiera mejorar los
procesos que utiliza para desarrollar productos o servicios. Los
niveles pueden también ser el resultado de la actividad de calificación
en las evaluaciones. Las evaluaciones se pueden aplicar a
organizaciones enteras o a grupos más pequeños, tales como un
grupo de proyectos o una división.
CMMI® da soporte a dos caminos de mejora usando niveles. Un
camino permite a las organizaciones mejorar de forma incremental los
procesos que corresponden a un área de proceso individual (o grupo
de áreas de proceso) seleccionada por la organización. El otro camino
permite a las organizaciones mejorar un conjunto de procesos
relacionados tratando, de forma incremental, conjuntos sucesivos de
áreas de proceso.

56
Estos dos caminos de mejora son asociados con dos tipos de
niveles:
Niveles de Capacidad.- Utiliza los niveles de capacidad para
caracterizar el estado de los procesos de la organización con respecto
a un área de proceso individual, como se aprecia en la figura 11. Para
dar soporte a aquellos que utilizan la representación continua, las
áreas de procesos se organizan en cuatro categorías: Gestión de
Procesos, Gestión de Proyectos, Ingeniería y Soporte.
Figura 2. Representación continua
Niveles de Madurez.- La representación por etapas utiliza los niveles
de madurez para caracterizar el estado global de los procesos de la
organización con respecto al modelo como un todo. Ofrece un camino
predefinido de la mejora desde el nivel de madurez 1 al nivel de
madurez 5, que implica el logro de los objetivos de las áreas de
proceso en cada nivel de madurez. Esto implica que para pasar de un
nivel a otro se deben cumplir todas las áreas desde el nivel inferior,
como se aprecia en la figura 12.

57
Figura 3. Representación por etapas
Los niveles de capacidad se refieren a la consecución de la mejora de
procesos de una organización en áreas de proceso individuales. Estos
niveles son un medio para mejorar de forma incremental los procesos que
corresponden a un área de proceso dada. Los cuatro niveles de capacidad
se numeran del 0 al 3.
Los niveles de madurez se refieren a la consecución de la mejora de
procesos de una organización en múltiples áreas de proceso. Estos niveles
son un medio para mejorar los procesos correspondientes a un conjunto
dado de áreas de proceso (es decir, nivel de madurez). Los cinco niveles de
madurez se numeran del 1 al 5.
La Tabla 2 compara los cuatro niveles de capacidad con los cinco niveles de
madurez. Se puede apreciar que los nombres de dos niveles son los mismos
en ambas representaciones (es decir, Gestionado y Definido). Las
diferencias son que no existe nivel de madurez 0, no hay niveles de
capacidad 4 y 5, y en el nivel 1, los nombres utilizados en el nivel de
capacidad 1 y nivel de madurez 1 son diferentes.

58
Tabla 2. Comparación de los niveles de capacidad y de madurez
Nivel Representación continua
Niveles de capacidad
Representación por etapas Niveles
de madurez
Nivel 0 Incompleto
Nivel 1 Realizado Inicial
Nivel 2 Gestionado Gestionado
Nivel 3 Definido Definido
Nivel 4 Gestionado cuantitativamente
Nivel 5 En optimización
2.4 Áreas del proceso y niveles de madurez
CMMI® posee cinco niveles de madurez, siendo el nivel 1 el nivel inicial en
el cual hay caos en los procesos de desarrollo. Como muestra la figura 13,
por cada nivel de madurez existen áreas de proceso asociadas. Hay cinco
niveles de madurez. Clasificación de los niveles de madurez se conceden
para los niveles 2 a 5. El presente trabajo se centra en las áreas de proceso
que ayudan a alcanzar el nivel 2 del modelo CMM Dev 1.3, en ese sentido
se hace una descripción de las áreas de proceso consideradas en dicho
nivel.
2.5 Gestión de Configuración
El propósito de la Gestión de Configuración (Configuration Management -
CM) es establecer y mantener la integridad de los productos de trabajo
utilizando la identificación de la configuración, el control de la configuración,
el informe del estado de la configuración y las auditorías de la configuración.
El área de proceso de Gestión de Configuración implica las siguientes
actividades:
• Identificar la configuración de los productos de trabajo seleccionados
que componen las líneas base en puntos determinados en el tiempo.
• Controlar los cambios a los elementos de configuración.
• Construir o proporcionar las especificaciones para construir los
productos de trabajo a partir del sistema de gestión de configuración.
• Mantener la integridad de las líneas base.

59
• Proporcionar a los desarrolladores, usuarios finales y clientes datos
precisos del estado y de la configuración actual.
Figura 4 Áreas de proceso y Niveles de madurez
Los productos de trabajo puestos bajo gestión de configuración incluyen los
productos que se entregan al cliente, los productos de trabajo internos
seleccionados, los productos adquiridos, las herramientas y otros elementos
utilizados para crear y describir estos productos de trabajo
Está área de procesos está conformada por las metas específicas y
prácticas específicas siguientes:
• SG 1 Establecer las líneas base.
o SP 1.1 Identificar los elementos de configuración.
o SP 1.2 Establecer un sistema de gestión de configuración.
o SP 1.3 Crear o liberar las líneas base.
• SG 2 Seguir y controlar los cambios.

60
o SP 2.1 Seguir las peticiones de cambio.
o SP 2.2 Controlar los elementos de configuración.
• SG 3 Establecer la integridad.
o SP 3.1 Establecer los registros de gestión de configuración.
o SP 3.2 Realizar auditorías de configuración.
2.6 Medición y Análisis
El propósito de Medición y Análisis (Measurement and Analysis - MA) es
desarrollar y mantener la capacidad de medición utilizada para dar soporte a
las necesidades de información de la gerencia.
El área de proceso Medición y Análisis implica las siguientes actividades:
• Especificar los objetivos de medición y análisis para alinearlos con las
necesidades de información y con los objetivos del proyecto, de la
organización o del negocio.
• Especificar las medidas, las técnicas de análisis y los mecanismos,
para la recogida de datos, almacenamiento de datos, difusión y
realimentación.
• Implementar las técnicas de análisis y los mecanismos para la
recogida de datos, difusión de datos y realimentación.
• Proporcionar resultados objetivos que puedan utilizarse en la toma de
decisiones informadas y en la toma de acciones correctivas
apropiadas.
• SG 1 Alinear las actividades de medición y análisis.
o SP 1.1 Establecer los objetivos de medición.
o SP 1.2 Especificar las medidas.
o SP 1.3 Especificar los procedimientos de recogida y de
almacenamiento de datos.
o SP 1.4 Especificar los procedimientos de análisis.

61
• SG 2 Proporcionar los resultados de la medición.
o SP 2.1 Obtener los datos de la medición.
o SP 2.2 Analizar los datos de la medición.
o SP 2.3 Almacenar los datos y los resultados.
o SP 2.4 Comunicar los resultados.
2.7 Monitoreo y Control de Proyectos (PMC)
El propósito del Monitoreo y Control del Proyecto (Project Monitoring and
Control - PMC) es proporcionar una comprensión del progreso del proyecto
para que se puedan tomar las acciones correctivas apropiadas, cuando el
rendimiento del proyecto se desvíe significativamente del plan.
Un plan de proyecto documentado es la base para el monitoreo de las
actividades, la comunicación del estado y la toma de acciones correctivas. El
progreso se determina principalmente comparando los atributos de los
productos de trabajo y de las tareas, el esfuerzo, el costo y el calendario
reales, con el plan en los hitos o niveles de control establecidos en el
calendario del proyecto o en la estructura de descomposición del trabajo
(WBS). Una visibilidad adecuada del progreso permite llevar a cabo las
acciones correctivas de manera oportuna cuando el rendimiento se desvíe
significativamente del plan. Una desviación es significativa si, cuando se deja
sin resolver, impide al proyecto cumplir con sus objetivos.
• SG 1 Monitorizar el proyecto frente al plan.
o SP 1.1 Monitorizar los parámetros de planificación del
proyecto.
o SP 1.2 Monitorizar los compromisos.
o SP 1.3 Monitorizar los riesgos del proyecto.
o SP 1.4 Monitorizar la gestión de los datos.
o SP 1.5 Monitorizar la involucración de las partes interesadas.
o SP 1.6 Llevar a cabo las revisiones del progreso.

62
o SP 1.7 Llevar a cabo las revisiones de hitos.
• SG 2 Gestionar las acciones correctivas hasta su cierre.
o SP 2.1 Analizar las cuestiones.
o SP 2.2 Llevar a cabo las acciones correctivas.
o SP 2.3 Gestionar las acciones correctivas.
2.8 Planificación del Proyecto (PP)
El propósito de la Planificación del Proyecto (Project Planning - PP) es
establecer y mantener planes que definan las actividades del proyecto.
Una de las claves para gestionar eficazmente un proyecto es la planificación
del proyecto. El área de proceso Planificación del Proyecto implica las
siguientes actividades:
• Desarrollar el plan de proyecto.
• Interactuar de forma apropiada con las partes interesadas relevantes.
• Obtener el compromiso con el plan.
• Mantener el plan.
La planificación incluye la estimación de los atributos de los productos de
trabajo y de las tareas, la determinación de los recursos necesarios, la
negociación de los compromisos, la elaboración de un calendario, y la
identificación y el análisis de los riesgos del proyecto.
Para establecer el plan de proyecto, puede ser necesario realizar iteraciones
de estas actividades. El plan de proyecto proporciona la base para realizar y
controlar las actividades del proyecto que abordan los compromisos con el
cliente del proyecto.
El plan de proyecto se modifica generalmente a medida que el proyecto
progresa, para abordar los cambios en los requisitos y en los compromisos,
las estimaciones inexactas, las acciones correctivas y los cambios a los
procesos. Esta área de proceso contiene las prácticas específicas que
describen tanto la planificación como la re planificación.

63
• SG 1 Establecer las estimaciones.
o SP 1.1 Estimar el alcance del proyecto.
o SP 1.2 Establecer las estimaciones de los atributos de los
productos de trabajo y de las tareas.
o SP 1.3 Definir las fases del ciclo de vida del proyecto.
o SP 1.4 Estimar el esfuerzo y el coste.
• SG 2 Desarrollar un plan de proyecto.
o SP 2.1 Establecer el presupuesto y el calendario.
o SP 2.2 Identificar los riesgos del proyecto.
o SP 2.3 Planificar la gestión de los datos.
o SP 2.4 Planificar los recursos del proyecto.
o SP 2.5 Planificar el conocimiento y las habilidades necesarias.
o SP 2.6 Planificar la involucración de las partes interesadas.
o SP 2.7 Establecer el plan de proyecto.
• SG 3 Obtener el compromiso con el plan.
o SP 3.1 Revisar los planes que afectan al proyecto.
o SP 3.2 Conciliar los niveles de trabajo y de recursos.
o SP 3.3 Obtener el compromiso con el plan.
2.9 Aseguramiento de la Calidad del Proceso y del
Producto
El propósito del Aseguramiento de la Calidad del Proceso y del Producto
(PPQA) es proporcionar al personal y a la gerencia una visión objetiva de los
procesos y de los productos de trabajo asociados.
• El área de proceso de Aseguramiento de la Calidad del Proceso y del
Producto implica las siguientes actividades:
• Evaluar objetivamente los procesos realizados y los productos de
trabajo frente a las descripciones de proceso, los estándares y los
procedimientos aplicables.
• Identificar y documentar las no conformidades.

64
• Proporcionar realimentación al personal del proyecto y a los gerentes
sobre los resultados de las actividades de aseguramiento de la
calidad.
• Asegurar que se tratan las no conformidades.
El área de proceso de Aseguramiento de la Calidad del Proceso y del
Producto da soporte a la entrega de productos de alta calidad,
proporcionando al personal del proyecto y a los gerentes, en todos los
niveles, la visibilidad apropiada y la realimentación sobre los procesos y los
productos de trabajo asociados, durante toda la vida del proyecto.
• SG 1 Evaluar objetivamente los procesos y los productos de trabajo.
o SP 1.1 Evaluar objetivamente los procesos.
o SP 1.2 Evaluar objetivamente los productos de trabajo.
• SG 2 Proporcionar una visión objetiva.
o SP 2.1 Comunicar y resolver las no conformidades.
o SP 2.2 Establecer los registros.
2.10 Gestión de Requisitos
El propósito de la Gestión de Requisitos (Requirements Management -
REQM) es gestionar los requisitos de los productos y los componentes de
producto del proyecto, y asegurar la alineación entre esos requisitos, y los
planes y los productos de trabajo del proyecto.
Los procesos de gestión de requisitos gestionan todos los requisitos
recibidos o generados por el proyecto, incluyendo tanto los requisitos
técnicos como los no técnicos, así como los requisitos impuestos al proyecto
por la organización.
Una parte de la gestión de requisitos es documentar los cambios a los
requisitos y su análisis razonado, y mantener la trazabilidad bidireccional
entre los requisitos fuente, todos los requisitos de producto y de componente

65
de producto, y otros productos de trabajo especificados (véase la definición
de “trazabilidad bidireccional” en el glosario).
• SG 1 Gestionar los requisitos.
o SP 1.1 Comprender los requisitos.
o SP 1.2 Obtener el compromiso sobre los requisitos.
o SP 1.3 Gestionar los cambios a los requisitos.
o SP 1.4 Mantener la trazabilidad bidireccional de los requisitos.
o SP 1.5 Asegurar el alineamiento entre el trabajo del proyecto y
los requisitos.
2.11 Gestión de Acuerdos con Proveedores
El propósito de la Gestión de Acuerdos con Proveedores (Supplier
Agreement Management - SAM) es gestionar la adquisición de productos y
servicios de proveedores.
El alcance de esta área de proceso aborda la adquisición de productos,
servicios y componentes de producto y de servicio que pueden ser
entregados al cliente del proyecto o incluidos en un producto o sistema de
servicios. Estas prácticas del área de proceso también pueden ser utilizadas
para otros propósitos que beneficien al proyecto (Ejemplo: compra de
consumibles).
En las áreas de proceso, donde se utilizan los términos “producto” y
“componente de producto”, sus significados también abarcan servicios,
sistemas de servicio y sus componentes.
El área de proceso Gestión de Acuerdos con proveedores implica las
siguientes actividades:
• Determinar el tipo de adquisición.
• Seleccionar los proveedores.
• Establecer y mantener acuerdos con los proveedores.
• Ejecutar los acuerdos del proveedor.

66
• Aceptar la entrega de los productos adquiridos.
• Asegurar una transición satisfactoria de los productos adquiridos.
• SG 1 Establecer acuerdos con proveedores.
o SP 1.1 Determinar el tipo de adquisición.
o SP 1.2 Seleccionar a los proveedores.
o SP 1.3 Establecer acuerdos con proveedores.
• SG 2 Satisfacer los acuerdos con los proveedores.
o SP 2.1 Ejecutar el acuerdo con el proveedor.
o SP 2.2 Aceptar el producto adquirido.
o SP 2.3 Asegurar la transición de los productos.

67
CAPÍTULO N°3 - APLICACIÓN DE CASO DE ESTUDIO
1.1 PLAN DE IMPLEMENTACIÓN
Como empresa desarrolladora de software OSPARTNERS S.A.C. depende
directamente del proceso de elaboración del producto final, es decir del
SOFTWARE.
Los tres ejes fundamentales que contribuyen para alcanzar el objetivo
primordial de desarrollar productos de software son:
- El proceso
- Los proyectos (incluida la tecnología utilizada)
- Las personas
Adicionalmente se debe tomar en cuenta que los tres ejes nombrados
anteriormente determinan:
- Costos
- Plazos
- Calidad
La situación actual de OSPARTNERS S.A.C. encaja en algunos de los
rasgos que identifican a una empresa de desarrollo de software inmadura
puesto que la evaluación realizada la ubica en Nivel 1 (Inicial).
El requerimiento de implementación proviene de la Gerencia General y es
asignado a la Gerencia de Desarrollo, de acuerdo al Plan Institucional
abarca el Nivel 2 y Nivel 3.
El Nivel 2:
1. Involucra la Gestión de Proyectos, el detalle de las actividades y los
tiempos.
2. Se define qué información maneja la Empresa.
3. Se establece las líneas base de procesos de la información.

68
Los productos o entregables a generarse en este Nivel 2 son:
- Plan de Proyecto
- Plan de Riesgos
- Plan de Comunicaciones
- Definición de métricas
- Plan de configuración
- Cuestionarios de auditoria
- Minutas
- Líneas base
- Registro de problemas
- Solicitud de requerimientos
- Acuerdos con Proveedores
- Sistemas, entre otros.
En el Nivel 3:
- Administración de los procesos
- Fortalecimiento de la Ingeniería
- Integración del Producto
- Validación del Producto
- Verificación del Producto
Una vez culminada la implementación, se someterá a la organización a una
Evaluación SCAMPI con el que se determinará si efectivamente se alcanzó
el Nivel 3 de madurez del CMMI® con la finalidad de obtener la certificación.

69
Ilustración 8 – DOCUMENTO DE SOLICITUD DE INICIO DEL PROYECTO DE IMPLEMENTACIÓN DEL CMMI –
PARTE N°1 – Enviado por la Gerencia General a la Gerencia de Desarrollo

70
Ilustración 9 – DOCUMENTO DE SOLICITUD DE INICIO DEL PROYECTO DE IMPLEMENTACIÓN DEL CMMI –
PARTE N°2 - Enviado por la Gerencia General a la Gerencia de Desarrollo

71
1. EQUIPO DEL PROYECTO
EQUIPO QUE CONFORMA EL PROYECTO
TIPO DE ROL ROLES ASOCIADOS
Líder de Proyecto Lidera y coordina al grupo de trabajo, verifica y revisa los
productos, configura el proceso, decide y verifica el
cumplimiento de las mejores prácticas.
Gestor de Requerimientos Función básicamente de gestión a nivel de proyecto que
involucra al cliente y al patrocinador de proyecto.
Gestor de Planificación Planifica y controla los recursos físicos, humanos,
monetarios e informáticos que se le otorgan para lograr
los resultados esperados de los distintos proyectos de
desarrollo del área.
Gestor de calidad Planifica y actúa en actividades de aseguramiento de
calidad de los procesos y en que los productos no se
desvíen de los estándares.
Gestor de Configuración Planifica y realiza las actividades de administración de la
configuración. Controla y autoriza todos los cambios en
las líneas base. La administración del repositorio de líneas
base es revisada y aprobada por el gestor de
configuración antes de tomar cualquier acción.
Gestor de Proveedores Actividades de gestión de proyectos que según la
estructura de la organización se gestiona por el mismo
proyecto o existe un área de adquisición que ejecuta la
mayoría de las actividades.
Gestor de desarrollo Trabaja en desarrollo y mantención del software, lleva a
cabo actividades como requerimientos, análisis, diseño,
codificación, testing, y documentación e informes
técnicos.
PARTICIPACIÓN DEL EQUIPO EN EL CICLO DE VIDA DEL
PROYECTO DE IMPLEMENTACIÓN
ÁREA DE PROCESO ROLES
INVOLUCRADOS
DESCRIPCIÓN ARTEFACTO
Gestión de
Requerimientos
REQM
Gestor de
Requerimientos
Función
básicamente de
gestión a nivel del
proyecto que
involucra al cliente
y al patrocinador
Se generan actas de
reunión para definir los
requerimientos, así como
se crea una lista de
requerimientos, se
establecen formas de
estimación del esfuerzo
en los cambios de
requerimientos, matriz de
trazabilidad de los

Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS

Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS

Similar a Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS (20)

Más de Carmen Elizabeth Vásquez Dextre

Más de Carmen Elizabeth Vásquez Dextre (6)

Último

Último (20)

Informe tecnico LA APLICACIÓN DE CMMI EN LA GESTIÓN DE PROYECTOS