Ejemplo Trabajo Tesis CMMI

Propuesta de implantación de CMMI-
DEV 1.3 nivel de madurez 2 en una

empresa consultora de software en el Perú
Item Type info:eu-repo/semantics/masterThesis
Authors Carranza Liza, María Isabel; Rodríguez Solórzano, Rubén Moisés;

Valverde Mejía, Eduardo Miguel
Citation Carranza Liza, M. I., Rodríguez Solórzano, R. M., & Valverde

Mejía, E. M. (2018, August 3). Propuesta de implantación de
CMMI-DEV 1.3 nivel de madurez 2 en una empresa consultora de
software en el Perú. Universidad Peruana de Ciencias Aplicadas
(UPC). Universidad Peruana de Ciencias Aplicadas (UPC), Lima,
Perú. Retrieved from http://hdl.handle.net/10757/624261
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights info:eu-repo/semantics/openAccess; Attribution-

NonCommercial-ShareAlike 3.0 United States
Download date 07/06/2021 17:18:44
Item License http://creativecommons.org/licenses/by-nc-sa/3.0/us/
Link to Item http://hdl.handle.net/10757/624261

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
ESCUELA DE POSGRADO
PROGRAMA ACADÉMICO DE MAESTRÍA EN DIRECCIÓN DE SISTEMAS

Y TECNOLOGÍAS DE LA INFORMACIÓN
Propuesta de implantación de CMMI-DEV 1.3 nivel de

madurez 2 en una empresa consultora de software en el Perú
TRABAJO DE INVESTIGACIÓN
Para optar el grado académico de Maestro en Dirección de Sistemas y Tecnologías
de la Información
AUTORES
Carranza Liza, María Isabel (0000-0003-0042-3284)
Rodríguez Solórzano, Rubén Moisés (0000-0003-0901-6714)
Valverde Mejía, Eduardo Miguel (0000-0002-3428-5695)
ASESOR DE TRABAJO DE INVESTIGACION

Gerónimo Vásquez, Alfonso Herminio (0000-0002-3734-9244)
Lima, 03 de agosto del 2018

Dedicatoria
“Agradezco a Dios por darme salud para continuar con mis sueños y a mis
padres y seres queridos por motivarme a seguir siempre superándome dando lo
mejor de mí en cada nuevo reto que me propongo.” (María Isabel Carranza)
“Agradecimientos especiales a mis queridos padres: Alejandrina y Alberto por
su apoyo incondicional desde siempre, a mi esposa Jessika por su paciencia
especial en esta etapa de estudios y a mis queridos hijos Benniluz y Moisés, mis
motivos de superación constante.” (Rubén Rodríguez) “Doy gracias a Dios por
permitirme avanzar en mi formación como persona y como profesional y por
ponerme en el camino a personas tan especiales como mis padres, Teresa
Ricaldoni, y amigos que con su ejemplo y consejos me motivan para lograr los
objetivos en mi vida.” (Eduardo Valverde)
2
RESUMEN EJECUTIVO
El objeto de estudio de la presente tesis es el Departamento de Sistemas de una empresa consultora

peruana que produce software y que requiere resolver una problemática en sus procesos que genera
grandes pérdidas económicas.
En el análisis cuantitativo se identificó que existe una inadecuada gestión de proyectos, lo cual ha
generado, en los últimos años, pérdidas en la facturación. Ante esta situación se recomienda tomar
acciones correctivas ya que se evidencia que dichas pérdidas se están incrementando anualmente,
además, está impactando en el objetivo estratégico de alcanzar la eficiencia en sus procesos;
establecido para apoyar a la consecución del objetivo organizacional de aumentar el EBITDA. En
el análisis cualitativo se identificó que las principales causas del problema están relacionas a la
inadecuada gestión de requisitos, deficientes estimaciones de costo y tiempo e inadecuada
planificación.
Es por ello, que luego del análisis de la problemática, se propone la implantación de los procesos
de gestión de proyectos de acuerdo al modelo de CMMI-DEV, ya que se adapta a los procesos
desarrollados por la empresa y ayuda a las organizaciones que lo implementan en la reducción de
costos y tiempo, así como en el incremento de la calidad y la satisfacción del cliente.
Como conclusiones, se recomienda la ejecución de la propuesta presentada para apoyar en los

objetivos estratégicos del Departamento de Sistemas y de la organización, evitando pérdidas
económicas que permitirán a la organización ser más rentable, además se busca incrementar la
capacidad para ejecutar nuevos proyectos generando mayores ingresos.

Palabras clave: CMMI‐Dev, Procesos, Software, Proyectos
3
ABSTRACT
The object of study of this thesis is the Systems Department of a Peruvian consulting company
that produces software and that requires solving a problem in their processes that generates large
economic losses.
In the quantitative analysis, it was identified that there is inadequate project management, which
has generated, in recent years, losses in billing. Faced with this situation, it is recommended to
take corrective actions since it is evident that said losses are increasing annually, besides, it is
impacting on the strategic objective of achieving efficiency in its processes; established to support
the achievement of the organizational objective of increasing EBITDA. In the qualitative analysis
it was identified that the main causes of the problem are related to the inadequate management of
requirements, poor estimates of cost and time and inadequate planning.
That is why, after the analysis of the problem, the implementation of the project management
processes is proposed according to the CMMI-DEV model, since it adapts to the processes
developed by the company and helps the organizations that they implement in the reduction of
costs and time, as well as in the increase of the quality and the satisfaction of the client.
As conclusions, it is recommended the execution of the proposal submitted to support the strategic
objectives of the Department of Systems and the organization, avoiding economic losses that will
allow the organization to be more profitable and increase the capacity to execute new projects
generating higher revenues.
Keywords: CMMI-Dev, Processes, Software, Projects
4
TABLA DE CONTENIDO
TABLA DE CONTENIDO............................................................................................................. 5
ÍNDICE DE TABLAS .................................................................................................................... 7
INDICE DE FIGURAS................................................................................................................... 9
INTRODUCCIÓN ........................................................................................................................ 10
CAPÍTULO 1: MARCO TEÓRICO............................................................................................. 13
1.1 Situación actual de la industria del software en el Perú...................................................... 13
1.2 Modelos de mejora de los procesos de desarrollo de software ........................................... 18
1.2.1 ISO 9001 ...................................................................................................................... 18
1.2.2 ISO 12207 .................................................................................................................... 20
1.2.3 ISO 15504 .................................................................................................................... 22
1.2.4 IDEAL.......................................................................................................................... 26
1.2.5 CMMI (Capability Maturity Model Integration) ......................................................... 28
1.3 Modelo CMMI-DEV .......................................................................................................... 31
1.3.1 CMMI continuo y escalonado ...................................................................................... 33
1.3.2 Nivel de Madurez 2 en CMMI-DEV ........................................................................... 36
1.3.3 Áreas de proceso del Nivel de Madurez 2 de CMMI-DEV ......................................... 36
1.3.4 Metas genéricas y prácticas genéricas del nivel de madurez 2 de CMMI-DEV ......... 39
1.3.5 Metas específicas y prácticas específicas del nivel de madurez 2 de CMMI-DEV..... 40
1.3.6 Método estándar para la evaluación de procesos del modelo CMMI – SCAMPI ....... 45
CAPÍTULO 2: SITUACIÓN PROBLEMÁTICA ........................................................................ 49
2.1 Objeto de estudio ................................................................................................................ 49
2.1.1 Presentación de la empresa .......................................................................................... 49
2.1.2 Análisis FODA del Departamento de Sistemas ........................................................... 53
2.1.3 Objetivos estratégicos .................................................................................................. 57
2.1.4 Procesos de gestión de proyectos ................................................................................. 59
2.2 Problemática ....................................................................................................................... 64
2.2.1 Análisis cuantitativo..................................................................................................... 66
5
2.2.2 Análisis cualitativo....................................................................................................... 69
2.2.3 Conclusiones del análisis de la problemática............................................................... 72
CAPÍTULO 3: PROPUESTA ....................................................................................................... 74
3.1 Implantación de CMMI basada en el marco IDEAL .......................................................... 74
3.1.1 Iniciar ........................................................................................................................... 75
3.1.2 Diagnosticar ................................................................................................................. 77
3.1.3 Establecer ..................................................................................................................... 88
3.2 Evaluación económica de la propuesta ............................................................................. 104
3.2.1 Costos del proyecto .................................................................................................... 104
3.2.2 Beneficios del proyecto.............................................................................................. 106
3.2.3 Flujo de caja del proyecto .......................................................................................... 107
3.2.4 Simulación del proyecto ............................................................................................ 108
CAPÍTULO 4: CONCLUSIONES Y RECOMENDACIONES................................................. 110
Conclusiones ........................................................................................................................... 110
Recomendaciones ................................................................................................................... 112
Referencias bibliográficas........................................................................................................... 114
Anexos ........................................................................................................................................ 121
6
ÍNDICE DE TABLAS
Tabla 1: Entidades asociadas a la ALETI ..................................................................................... 14

Tabla 2: Principales problemas para exportar software ................................................................ 16
Tabla 3: Niveles de capacidad y atributos de proceso .................................................................. 24
Tabla 4: Reglas de derivación para los niveles de madurez ......................................................... 25
Tabla 5: Rangos de evaluación de los atributos de procesos ISO 15504...................................... 25
Tabla 6: Comparación de los niveles de capacidad y de madurez. ............................................... 33
Tabla 7: Procesos de CMMI-DEV................................................................................................ 35
Tabla 8: Áreas de proceso del nivel de madurez 2 de CMMI-DEV ............................................. 37
Tabla 9: Propósito de las áreas de proceso ................................................................................... 37
Tabla 10: Metas y prácticas genéricas del nivel de madurez 2 ..................................................... 39
Tabla 11: Metas y prácticas específicas de gestión de requisitos ................................................. 40
Tabla 12: Metas y prácticas específicas de planificación del proyecto ........................................ 41
Tabla 13: Metas y prácticas específicas de monitorización y control de proyectos ..................... 42
Tabla 14: Metas y prácticas específicas de gestión de acuerdos con proveedores ....................... 43
Tabla 15: Metas y prácticas específicas de gestión de configuración .......................................... 44
Tabla 16: Metas y prácticas específicas de medición y análisis ................................................... 45
Tabla 17: Clases de SCAMPI ....................................................................................................... 46
Tabla 18: Certificaciones CMMI-DEV v.1.3 ............................................................................... 47
Tabla 19: Certificaciones CMMI-DEV v.1.3, en China ............................................................... 47
Tabla 20: Certificaciones CMMI-DEV v.1.3 en México ............................................................. 47
Tabla 21: Número de certificaciones CMMI-DEV v.1.3 en el Perú ............................................ 48
Tabla 22: Colaboradores en el Departamento de Sistemas ........................................................... 52
Tabla 23: Objetivos estratégicos de la unidad de negocio de TI. ................................................. 58
Tabla 24: Caracterización del proceso de Iniciación .................................................................... 59
Tabla 25: Caracterización del proceso de Planificación del Proyecto .......................................... 60
Tabla 26: Caracterización del proceso de Ejecución del Proyecto ............................................... 61
Tabla 27: Caracterización del proceso de Seguimiento y Control................................................ 62
7
Tabla 28: Caracterización del proceso de Cierre .......................................................................... 63
Tabla 29: Matriz de selección de la problemática ........................................................................ 65
Tabla 30: Indicadores de la gestión de proyectos por fase. .......................................................... 66
Tabla 31: Resumen de pérdidas en facturación ............................................................................ 69
Tabla 32: Impacto de la problemática en los objetivos estratégicos ............................................. 73
Tabla 33: Mapeo de los procesos de CMMI-DEV con los procesos de la empresa ..................... 75
Tabla 34: Estructura del equipo de mejora ................................................................................... 76
Tabla 35: Proyectos considerados en la evaluación ...................................................................... 79
Tabla 36: Rango de evaluación de las prácticas usando la ISO15504 .......................................... 80
Tabla 37: Rango de evaluación de las metas ................................................................................ 80
Tabla 38: Resultado de la evaluación del proceso REQM ........................................................... 81
Tabla 39: Resultado de la evaluación del proceso PP................................................................... 83
Tabla 40: Resultado de la evaluación del proceso PMC............................................................... 84
Tabla 41: Resultado de la evaluación del proceso SAM .............................................................. 86
Tabla 42: Resumen de cumplimiento de metas ............................................................................ 88
Tabla 43: Propuesta de definición de prácticas genéricas ............................................................ 89
Tabla 44: Caracterización del proceso gestión de requisitos ........................................................ 90
Tabla 45: Caracterización del proceso planificación del proyecto ............................................... 93
Tabla 46: Caracterización del seguimiento y control del proyecto............................................... 99
Tabla 47: Entregables del proyecto propuesto ............................................................................ 102
Tabla 48: Recursos humanos requeridos .................................................................................... 104
Tabla 49: Costos del proyecto..................................................................................................... 104
Tabla 50: Beneficios del proyecto .............................................................................................. 106
Tabla 51: Flujo de caja del proyecto ........................................................................................... 107
Tabla 52: Variables de simulación .............................................................................................. 108
8
INDICE DE FIGURAS
Figura 1: Estructura de la norma ISO 15504. ............................................................................... 23

Figura 2: Fases del modelo IDEAL .............................................................................................. 28
Figura 3: Constelaciones de CMMI. ............................................................................................. 29
Figura 4: Componentes del modelo CMMI. ................................................................................. 32
Figura 5: Servicios brindados por la empresa objeto de estudio. ................................................. 50
Figura 6: Organigrama de la empresa consultora. ........................................................................ 52
Figura 7: Brechas a cubrir en gestión de proyectos. ..................................................................... 67
Figura 8: Facturación Vs. Costo Real (Años: 2015, 2016 y 2017) ............................................... 68
Figura 9: Diagrama causa-efecto de inadecuada gestión de proyectos......................................... 71
Figura 10: Análisis de Pareto para identificar las causas más relevantes ..................................... 72
Figura 11: Fases de la elaboración de la propuesta de mejora...................................................... 74
Figura 12: Organigrama propuesto para la mejora de procesos ................................................... 77
Figura 13: Cálculo del tamaño de la muestra................................................................................ 78
Figura 14: Caracterización de las prácticas de REQM ................................................................. 82
Figura 15: Nivel de implementación e institucionalización de REQM ........................................ 82
Figura 16: Caracterización de las prácticas de PP ........................................................................ 83
Figura 17: Nivel de implementación e institucionalización de PP ............................................... 84
Figura 18: Caracterización de las prácticas de PMC .................................................................... 85
Figura 19: Nivel de implementación e institucionalización de PMC ........................................... 85
Figura 20: Caracterización de las prácticas de SAM .................................................................... 86
Figura 21: Nivel de implementación e institucionalización de SAM ........................................... 87
Figura 22: Proceso propuesto de gestión de requisitos ................................................................. 93
Figura 23: Proceso propuesto de planificación de proyectos ....................................................... 98
Figura 24: Proceso propuesto de seguimiento y control de proyectos........................................ 101
Figura 25: Simulación VAN del proyecto. ................................................................................. 109
Figura 26: Simulación TIR del proyecto. ................................................................................... 109
9
INTRODUCCIÓN
El presente documento desarrolla la propuesta de implantación de CMMI-DEV 1.3 nivel de

madurez 2 en una empresa consultora de software en el Perú. El tema elegido busca brindar una
solución a una problemática de una empresa mediante un modelo calidad, desde las perspectivas
de tecnologías de información y negocios. El documento se realiza en cuatro capítulos los cuales
se detallan a continuación:
En el primer capítulo se revisa el marco teórico donde se analiza la situación actual de la industria
de desarrollo de software en el Perú, la cual viene creciendo a un ritmo constante en los últimos
cuatros años, principalmente gracias a la presencia de pequeñas y medianas empresas (PyMEs).
Sin embargo, una de las principales barreras que enfrenta la industria para continuar su crecimiento
y presencia en mercados extranjeros, son los estándares de calidad exigidos. Es por ello que se
revisan los modelos de calidad más utilizadas por las empresas del sector de desarrollo de software,
los cuales son: ISO9001, ISO 12207, ISO15504, IDEAL y CMMI-DEV.
En el segundo capítulo se presenta la problemática. La empresa seleccionada para el trabajo es una

empresa dedicada al desarrollo de software, cuyo nombre no se menciona por motivos de
confidencialidad. Esta empresa tiene presencia a nivel nacional e internacional en los países de
Ecuador, Estados Unidos y Chile, pero a pesar de su crecimiento, los indicadores de gestión de
proyectos de desarrollo de software reflejan una inadecuada ejecución en los procesos de gestión
de proyectos, lo cual ha traído como consecuencia que la empresa venga generando pérdidas en su
facturación por US$168,681, en promedio, en los últimos tres años. Esta situación es relevante,
porque impacta en los objetivos estratégicos de la organización asociados al incremento del
EBITDA y de satisfacción de los clientes, motivo por el cual se plantea la implantación de un
modelo de calidad de procesos ampliamente reconocido en la industria de desarrollo de software
como es CMMI-DEV, para mejorar los procesos de gestión de proyectos en la empresa.
En el tercer capítulo se desarrolla la propuesta de solución basada en el modelo CMMI-DEV, para

lo cual se plantea que la implantación de la mejora se realice bajo el marco IDEAL por ser un
marco aprobado para la implantación de procesos de mejora. El modelo propone cinco fases:
10
Iniciar, diagnosticar, establecer, accionar y aprender, en el presente documento sólo se revisan las
tres primeras fases por ser las necesarias para realizar la propuesta:
 En la primera fase se justifica la necesidad del cambio por estar impactando en los objetivos
estratégicos de la organización. Se estable como alcance la propuesta de mejora de los procesos
del área de Desarrollo de Software del Departamento de Sistemas que están asociados a los
procesos del nivel de madurez 2 del modelo de CMMI-DEV. Asimismo, se estable como
objetivo general el ahorro en costos, reduciendo en un 20% las pérdidas en facturación (US$
168,68) desde el primer año, con mejoras anuales hasta alcanzar una eficiencia sostenible. Para
lo cual se establecen los siguientes objetivos específicos:
- Establecer una estructura que permita gestionar el proceso de mejora y asegurar la correcta
ejecución de los nuevos procesos, así como promover próximas iniciativas de mejora.
- Propuesta de implantación de manera iterativa los procesos de mejora, mediante la

ejecución de proyectos pilotos para asegurar la correcta ejecución y beneficio de los nuevos
procesos.
- Elaborar el manual de procesos basados en el modelo de CMMI-DEV para aquellos

procesos que requieran de mejoras.
 En la segunda fase se evalúan los procesos de la empresa que están asociados a los procesos
del nivel de madurez 2 de CMMI-DEV, esta evaluación se realizó basándose en el método
estándar para la evaluación de procesos del modelo CMMI (SCAMPI).
 En la tercera fase se determina como prioridad de la implantación los procesos de Gestión de

requisitos, Planificación de proyectos y de Monitorización y control del proyecto por ser los
más críticos, según la evaluación realizada en la fase anterior. Es por ese motivo que serán los
procesos a abordar en la propuesta presentada. Para dichos procesos se propone el rediseño y
se desarrolla el plan de implantación.
Asimismo, en el tercer capítulo se realiza la evaluación económica de la propuesta, en la cual se

determinan los costos y los beneficios económicos de la solución para luego realizar el flujo de
caja proyectado a cinco años donde se obtiene los siguientes indicadores financieros: VAN =
US$128,821.48 y TIR =31%. Por lo tanto, al tener una VAN positiva y una TIR superior al costo
11
oportunidad de la inversión (12%), se considera que el proyecto debe ejecutarse por ser rentable
para la empresa. Luego se realiza la simulación del proyecto obteniéndose una VAN promedio
positiva y una TIR promedio superior al costo oportunidad de la inversión, por lo que se garantiza
la rentabilidad del proyecto.
Finalmente, en el cuarto capítulo se presenta las conclusiones a las que se han llegado luego de la
realización del trabajo presentado y, además, se presentan recomendaciones para la empresa para
que pueda implementar con éxito la propuesta desarrollada.
12
CAPÍTULO 1: MARCO TEÓRICO
En el presente capítulo se desarrolla el marco teórico, en el cual se detalla la situación actual de la

industria del software en el Perú, con el objetivo de entender su potencial a nivel nacional e
internacional. Asimismo, se presentan las normas y modelos de calidad más utilizadas en la
industria del software, las cuales son: ISO 9001, ISO 12207, ISO 15504, IDEAL y CMMI, con el
objetivo de analizar la tendencia en la adopción de estándares de calidad y mejora de procesos de
desarrollo de software en las empresas. Finalmente, se profundiza en el modelo CMMI-DEV 1.3
y se identifican los procesos del nivel de madurez 2.
1.1 Situación actual de la industria del software en el Perú

“Se llama sector de software aquel conformado por unidades económicas cuya actividad principal
es la producción, desarrollo y comercialización de programas informáticos.” (PROMPEX &
APESOFT, 2004, p.7), teniendo en consideración esta definición del sector de software en el
presente documento de tesis nos centraremos en las empresas del sector de software cuyo rubro
principal sea el desarrollo de software.
La industria de software en Latinoamérica, según Hernández (2006), está marcada por numerosos
convenios para el desarrollo de las nuevas tecnologías, además cuenta con asociaciones de
cooperación que tienen el objetivo de propiciar políticas, mejorar los mercados y las cadenas de
distribución, para ayudar a los asociados a mejorar su competitividad y buscar alternativas de
desarrollo de programas conjunto, como por ejemplo la Federación de Asociaciones de
Latinoamérica, el Caribe y España de Entidades de Tecnología de la Información, la cual es
integrada por empresas de Latinoamérica y del país ibérico (ALETI). En la Tabla 1 podemos
apreciar algunos de los países de la región con la empresa asociada a la ALETI, en el caso del Perú
la empresa vinculada es la Asociación Peruana de Productores de Software (APESOFT).
13
Tabla 1: Entidades asociadas a la ALETI
País Empresa
Argentina CESSI - Cámara de Empresas de Tecnología de Información de Argentina
Bolivia CBTI - Cámara Boliviana de Tecnologías de la Información
Brasil ASSESPRO
Associação das Empresas Brasileiras de Tecnología da Informação.
Chile ACTI
Asociación Chilena de Empresas de Tecnología de Información. GECHS
Colombia FEDESOFT
Federación Colombiana de la Industria del Software y Tecnologías

Informáticas Relacionadas
Costa Rica CAMTIC
Cámara de Empresas de Tecnología de Información y Comunicaciones
Cuba INCUSOFT
Industria Cubana del Software
Ecuador AESOFT
Asociación Ecuatoriana de Software
México AMITI
Asociación Mexicana de la Industria de Tecnologías de la Información
Panamá APS
14
Asociación Panameña de Software
Paraguay APUDI
Cámara Paraguaya de la Informática y las Telecomunicaciones
Perú APESOFT
La Asociación Peruana de Productores de Software
Uruguay CUTI
Cámara Uruguaya de Tecnologías de la Información
Venezuela CAVEDATOS
Cámara Venezolana de Empresas de Tecnologías de la Información
España AETIC
Asociación Española de Tecnologías de Información y Comunicaciones
Nota. Tomado “La industria del software. Estudio a nivel global y América
Latina" en Observatorio de la Economía Latinoamericana, Nº 116, 2009. Por Santos H.: Autor.
Miranda M. (2017), presidente de APESOFT, presentó en el último foro de inteligencia y

sostenibilidad urbana realizado en la ciudad de Málaga – España, los siguientes indicadores acerca
de la industria de desarrollo de software en el Perú:
El sector de la industria de desarrollo de software ha crecido sostenidamente a un ritmo de 15%

durante los últimos cuatro años.
Existen en Perú un estimado de 450 empresas formales que desarrollan software en Perú, de las
cuales el 85% son pequeñas y medianas empresas (PyMEs).
Estos indicadores nos permiten afirmar que el impulso a la industria de software nacional está
dando buenos resultados con un crecimiento constante generado principalmente por las PyMEs.
15
Además, la industria de software en el Perú tiene proyecciones interesantes y beneficiosas para el
país, tal como lo señala el Instituto Nacional de Estadística e Informática (INEI) (2017) en su
reporte al cierre del tercer trimestre del año 2017 donde se indica que el sector de
telecomunicaciones y otros servicios de información contribuyeron en un 8.5% al crecimiento en
2.5% del producto bruto interno (PBI).
Asimismo, el diario Gestión (2017) informó que el sector de desarrollo de software cerró el año
2016 con una facturación de US$240 millones, además, Andina – Agencias peruanas de noticias
(2017) publicó que según información de la Comisión de Promoción del Perú para la Exportación
y el Turismo (PROMPERÚ), las exportaciones peruanas de software alcanzaron los US$50
millones en el mismo año, teniendo como destino los sectores de telecomunicaciones, eléctrico y
financiero. Estas cifras nos indican que sólo el 21% de la facturación de la industria de software
proviene de exportaciones, lo cual se puede explicar por las barreras competitivas en los mercados
extranjeros. Al respecto, en la Tabla 2 se presentan los principales problemas a los que se enfrentan
las empresas de desarrollo de software a la hora de aventurarse a ingresar a mercados extranjeros,
según un estudio conjunto realizado por la Comisión de Promoción de las Exportaciones
(PROMEX) y APESOFT en el año 2004, donde se identifica que los tres principales
inconvenientes son: i) Falta de información y canales de comercialización, ii) Estándares de
calidad y certificaciones, y iii) Financiamiento.
Las cifras revelan que una de las principales limitantes para la exportación de software son los
estándares de calidad y certificaciones, lo cual se justifica por el costo que demandan, ya que como
se mencionó anteriormente, la industria de software en el Perú está conformado mayoritariamente
por PyMEs y la obtención de certificados requiere una inversión bastante elevada. Al respecto,
PROMPEX & APESOFT (2004) afirman que el 52% de 149 empresas encuestadas, consideran
que las certificaciones de calidad son muy caras, sin embargo, el 87% estaría dispuesto a invertir
en la implementación de programas de mejoramiento de procesos de software.
Tabla 2: Principales problemas para exportar software

Problema Porcentaje (%)
Información de mercados y canales de comercialización 58.4
16
Estándares internacionales de calidad y certificaciones 41.7
Financiamiento 33.3
Infraestructura y equipamiento 20.9
Desconocimiento de mecanismos de exportación 20.8
Restricciones a la inversión extranjera 12.5
Disponibilidad de RRHH capacitados 12.5
Conectividad 4.3
Otros 13.0
Nota. Información recuperada de PROMPEX & APESOFT (2004). Situación de la industria

nacional de software en el Perú. Recuperado de: http://cendoc.esan.edu.pe/fulltext/e-
documents/diagnosticosoftware2004_v3.pdf
Asimismo, “los principales mercados de exportación de las empresas de software son: Estados
Unidos (46%), Chile (16%), España (10%), Colombia (6%), Uruguay (4%), Bolivia (2%) y Suiza
(2%), según cifras de PROMPERÚ.” (El Comercio, 2017) lo cual nos indica que no se realizan
muchas exportaciones de software a nivel regional, ya que los desarrollos de software nacional son
principalmente exportados al mercado estadounidense, líder en el mercado del software con más
de 100 mil empresas en el sector según Guillen M. (2016). Esta situación nos muestra que existe
un mercado prometedor en los Estados Unidos, pero también altamente competitivo, por eso las
empresas peruanas deben asegurarse de brindar productos de calidad y contar con certificaciones
que las respalden.
En la página oficial del evento Perú Service Summit (2017), organizado por PROMPERÚ se indica
que del universo de empresas formales del sector de software que tienen estándares de calidad, el
75% de ellas cuentan con certificación ISO 9001 y un 40% de empresas con certificación CMMI.
Lo cual refleja que la mayoría de empresas que cuentan con certificación de calidad optan por
certificarse en ISO9001 e incluso hay algunas que tienen doble certificación. La poca acogida de
17
la certificación CMMI probablemente se debe a que está certificación es más costosa, por ser más
especializada y además demora más tiempo en conseguirse, características que la hacen menos
atractivas para las empresas del sector.
Otro indicador importarte es el costo de la hora hombre de los desarrolladores de software peruanos
en comparación con otros países de la región, tal como lo afirma Mendoza M. (2015) en una
entrevista realizada a Huapaya J. Gerente General de Software Enterprise Services, donde se
menciona que, en Brasil la hora hombre está valorada en US$ 80, mientras que en el Perú tiene
una valoración de US$20, esta diferencia nos haría más atractivos para los fabricantes de software
extranjeros.
Del análisis actual de las empresas de desarrollo de software se destaca que en el Perú la industria
de desarrollo de software tiene potencial para seguir creciendo e incrementando sus exportaciones.
Sin embargo, existen brechas que cubrir para poder ingresar a los mercados extranjeros, en ese
sentido, es importante que las empresas se preocupen por brindar servicios y productos con
estándares de calidad ampliamente reconocidos a nivel mundial para poder ser más competitivas
y aumentar su presencia a nivel internacional, ya que podríamos ofrecer software de buena calidad
a un precio bastante competitivo.
1.2 Modelos de mejora de los procesos de desarrollo de software

Luego de identificar la importancia de los estándares de calidad en un sector con proyecciones de
crecimiento y oportunidades de exportación como es la industria de software nacional, se
presentarán las normas y modelos más reconocidos por la industria a nivel mundial y se evaluarán
sus ventajas y desventajas de implementación.
1.2.1 ISO 9001

International Organization for Standardization (ISO) (2015) establece en su norma ISO 9001:2015
los requisitos para establecer un sistema de gestión de calidad , además, la ISO (2015) define en
la norma ISO 9000:2015 el concepto de calidad como un grado en el que un conjunto de
características inherentes cumple con los requisitos; y un sistema de gestión como conjunto de
elementos de una organización interrelacionados o que interactúan para establecer políticas,
objetivos y procesos para lograr estos objetivos; por lo tanto, podemos inferir que el objetivo de la
18
ISO 9001:2015 es brindar a las organizaciones las pautas para orientar sus lineamientos y procesos
hacia a la satisfacción de sus clientes, en la medida en que se satisfacen sus requisitos.
Ijaz,Asghar y Ahsan (2016) afirman que la esencia de un software de calidad es una cualidad del
proceso de software. Por lo que no es posible obtener un producto de calidad sin tener un proceso
de calidad. Es por ello, que si una empresa utiliza una norma de calidad como la ISO 9001:2015
para mejorar sus procesos del desarrollo de software, es muy probable que en dicha empresa se
logre producir software de calidad lo cual aumentará la satisfacción del cliente.
Para lograr la mejora de procesos la norma ISO 9001:2015 incorpora en su enfoque a procesos, el
ciclo Planificar-Hacer-Verificar-Actuar (PHVA) y el pensamiento basado en riesgos, lo cual
significa que la ISO 9001:2015 busca ayudar a las organizaciones a planificar, gestionar e
identificar oportunidades de mejora en sus procesos para poder ejecutarlos de manera óptima,
además, incorpora el elemento riesgo para poder identificar amenazas a los procesos y poder
definir controles preventivos para minimizar o mitigar dichos riesgos.
Con respecto a la estructura de la norma ISO 9001:2015 esta consta de diez capítulos, los primeros
tres capítulos de la norma no contienen requisitos, ya que están orientados a identificar el objeto y
campo de aplicación de la norma, las referencias normativas y los términos/definiciones para la
norma. Los capítulos del 4 al 10 contienen los requisitos de la norma: i. Contexto de la
organización, ii. Liderazgo, iii. Planificación, iv. Apoyo, v. Operación, vi. Evaluación del
desempeño y vii. Mejora.
Asimismo, en la norma ISO 9001:2015 se afirma que implantar un sistema de gestión de la calidad
es una decisión estratégica y si una organización la implementa puede tener los siguientes
beneficios:
 La capacidad para proporcionar regularmente productos y servicios que satisfagan los

requisitos del cliente, así como los legales y reglamentarios aplicables.
 Facilitar oportunidades de aumentar la satisfacción del cliente.
 Abordar los riesgos y oportunidades asociadas con su contexto y objetivos.
19
 La capacidad de demostrar la conformidad con requisitos del sistema de gestión de la calidad
especificados.
Asimismo, Torres (2007) identifica otras ventajas no mencionadas anteriormente:
 Es aplicable para cualquier industria y entorno.
 La norma ISO 9001 contempla la mayoría de áreas funcionales que puede tener una
organización las cuales son: gestión, recursos humanos, producción, ingeniería y calidad.
 Las empresas que adoptan o se certifican en la norma ISO 9001 logran tener reconocimiento
internacionalmente lo cual abre oportunidades a las empresas para entrar a nuevos mercados.
 Existe libertad para su implementación y para la interpretación de los requisitos.
Los beneficios descritos han sido muy atractivos a nivel mundial, ya que una encuesta realizada
por la Asociación Internacional de Normalización (ISO) (2016) revela que al 2016 se han emitido
1’106,356 certificados de ISO 9001 (80,596 en la versión 2005) a nivel mundial. A nivel regional
(Centroamérica y Sudamérica), asimismo, se identifica que el país con mayor número de
certificaciones es Brasil con 20,908, por su parte Perú cuenta con 1,320 certificaciones cifra que
se ha venido incrementando anualmente.
Sin embargo, la adopción de la ISO 9001 tiene inconvenientes sobre todo cuando se desea adoptar
en la industria del software. Las desventajas identificadas por Torres (2007) son:
 Por ser una norma aplicable a cualquier industria, es genérica por lo tanto no está dirigida
exclusivamente para empresas de software. Asimismo, no proporciona información de cómo
aplicarlo a empresas de menor tamaño.
 Debido a la naturaleza genérica de la norma ISO 9001, hay pocas directrices para su
implementación en industrias o campos específicos.
 La norma no provee las actividades para lograr la mejora de procesos.
1.2.2 ISO 12207

La International Organization for Standardization (ISO) (2008) afirma que la norma ISO 12207 es
el primer estándar internacional orientado a proporcionar un conjunto completo de procesos,
20
actividades y tareas de ciclo de vida para software que es parte de un sistema más grande y para
productos y servicios de software independientes. En la ISO 12207 se establece que puede
utilizarse en uno de los siguientes modos:
 Por la organización: para evaluar la conformidad de un conjunto de procesos de ciclo de vida

declarados con sus disposiciones (métodos, procedimientos, técnicas, herramientas y personal
capacitado)
 Por un proyecto: para evaluar la conformidad del proyecto con el entorno declarado y
establecido de procesos de ciclo de vida para proporcionar productos y servicios.
 Por un adquiriente y un proveedor: se utiliza como guía para desarrollar un acuerdo sobre los
procesos y actividades.
 Por organizaciones y evaluadores: para realizar evaluaciones que respalden la mejora del
proceso organizacional.
En el Perú, mediante Resolución Directoral N°013.2016-INACAL/DN se aprueba la Norma

Técnica Peruana NTP- ISO/IEC 12207:2016 Ingeniería de software y sistemas. Procesos del ciclo
de vida del software. 3ª Edición. Dicha norma explicada en la Resolución Administrativa N° 019-
2017-MTC/33.6 en donde se menciona que la NTP-ISO/IEC 12207:2016 es un marco de
referencia que cubre el ciclo de vida del software y considera los procesos para adquirir,
suministrar (productos y servicios de software), controlar y mejorar procesos. Por lo tanto, se
puede afirmar que la norma técnica mencionada es un equivalente o adaptación de la norma ISO
12207.
Asimismo, en dicha Resolución Administrativa se menciona que en la NTP-ISO/IEC 12207:2016

las actividades a ejecutar a lo largo del ciclo de software están divididas en cinco procesos
principales (adquisición, suministro, desarrollo, operación y mantenimiento), ocho procesos de
apoyo (documentación, gestión de la configuración, aseguramiento de la calidad, verificación,
validación, revisión conjunta, auditoría y solución de problemas) y cuatro procesos organizativos
(gestión, infraestructura, mejora de proceso y recursos humanos).
Finalmente, es importante mencionar que mediante Resolución Ministerial N Nº 041-2017-PCM

se aprobó el uso obligatorio de la Norma Técnica Peruana NTP-ISO/IEC 12207:2016- Ingeniería
21
de Software y Sistemas. Procesos del ciclo de vida del software. 3ª Edición, en todas las entidades
integrantes del Sistema Nacional de Informática. Lo cual significa que esta norma es obligatoria
para toda empresa de software que desee trabajar en proyectos de desarrollo o servicio de software
para entidades del Estado Peruano.
1.2.3 ISO 15504

La norma ISO 15504 también conocida como SPICE (Software Process Improvement and
Capability Determination) “es un estándar internacional para la evaluación y mejora de procesos.
Puede ser utilizado por cualquier organización para determinar la capacidad actual y potencial de
sus propios procesos, y también definir áreas y prioridades para la mejora de procesos” (Mesquida,
Mas, Amengual, & Calvo-Manzano, 201, p.240).
Por su parte la Asociación Española para la Calidad - AEC (2017) afirma que la ISO 15504 es un
marco de referencia para:
 Determinar las fortalezas y debilidades de los procesos.
 Mejorar los procesos de software y medir sus mejoras.
 Aquellos que adquieren un sistema para evaluar la capacidad de los proveedores de sistemas.
 Determinar los riesgos de negocio para una empresa que considera desarrollar un nuevo
producto de software o servicio.
La ISO 15504 comprende siete partes, siendo las dos primeras normativas. La séptima la
concerniente a la evaluación con niveles de madurez, tal como se muestra en la Figura 1, la parte
7, está relacionada con la parte normativa número 2 de realización de la evaluación.
Garzás, Fernández & Piattini (2009) identifica en el sistema de evaluación de la ISO 15504
componentes específicos (outcomes y actividades) y componentes comunes para todos los
procesos (atributos de proceso y prácticas de atributo). Los componentes específicos se encuentran
definidos en el modelo de referencia ISO 12207 mientras que los componentes comunes se
encuentran definidos en la ISO 15504: los atributos de proceso en la parte 2 y las prácticas de
atributo en la parte 5.
22
Figura 1: Estructura de la norma ISO 15504.
Los cuadros en color naranja representan las partes que son normativas y en azul las que no son
normativas. Adaptado de “Bautista M., Pérez A. Lara M. (2012). Determinación de la Capacidad
de Mejora del Proceso de Software. Universidad Veracruzana. Recuperado de:
https://www.uv.mx/personal/jfernandez/files/2012/11/ISO15504.pdf”
La definición de los componentes definidos para la ISO 15504 es la siguiente:
 Outcome: componente requerido que aplica a un proceso y describe las características que
deben cumplirse para satisfacer dicho proceso.
 Actividades: es un componente de información y brinda las descripciones detalladas para la

interpretación e implementación de los outcomes.
 Atributo de proceso: componente requerido que describe las características que deben estar
presentes para institucionalizar un proceso.
 Práctica de atributo: componente requerido que define qué se debe realizar para alcanzar el
propósito de un atributo de proceso.
23
Para medir el nivel de capacidad de un proceso se utilizan los atributos de procesos (AP), cuya
relación se muestra en la Tabla 3, donde se identifica los AP que deben cumplirse para lograr un
nivel de capacidad del proceso.
Tabla 3: Niveles de capacidad y atributos de proceso

Nivel de capacidad Atributo de proceso (AP)
1: Proceso realizado AP 1.1 Realización del proceso
2: Proceso gestionado AP 2.1 Gestión de la realización
AP 2.2 Gestión del producto de trabajo
3: Proceso establecido AP 3.1 Definición del proceso
AP 3.2 Despliegue del proceso
4: Proceso predecible AP 4.1 Medición del proceso
AP 4.1 Control del proceso
5: Proceso de optimización AP 5.1 Innovación del proceso
Nota. Tomado de Garzás, J., Fernández, C. M., & Piattini, M. (2009). Una aplicación de la Norma
ISO/IEC 15504 para la Evaluación por Niveles de Madurez de Pymes y Pequeños Equipos de
Desarrollo. REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, 5(2).
El sistema de evaluación que propone la ISO 15504 está basado en niveles de madurez, como
podemos ver en la Tabla 3 existen reglas de derivación para los niveles de madurez, los cuales son
evolutivos, lo que implica que, alcanzar un nivel de madurez superior requiere del cumplimiento
del nivel inmediato inferior, siendo el nivel de madurez más bajo el nivel 0 y el más alto el nivel
5. Asimismo, se puede identificar que los niveles de madurez guardan relación con los niveles de
capacidad, por lo tanto, existen atributos de proceso que deben cumplirse para lograr un
determinado nivel de madurez.
24
Tabla 4: Reglas de derivación para los niveles de madurez
Nivel de madurez Descripción
0 La organización no tiene una implementación efectiva de los procesos.
1 Los procesos objeto de evaluación alcanzan el nivel de capacidad 1, es decir
existen productos resultantes par los mismos y el proceso se puede
identificar.
2 Los procesos de los niveles de madurez 2 tienen nivel de capacidad 2 o
superior.
3 Los procesos de los niveles de madurez 2 y 3 tienen nivel de capacidad 3 o
superior.
4 Uno o más procesos tienen nivel de capacidad 4 o superior.
5 Uno o más procesos tienen nivel de capacidad 5.
Nota. Tomado de Garzás, J., Fernández, C. M., & Piattini, M. (2009). Una aplicación de la Norma
ISO/IEC 15504 para la Evaluación por Niveles de Madurez de Pymes y Pequeños Equipos de
Desarrollo. REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software, 5(2).
Para que una empresa pueda medir sus procesos utilizando la ISO 15504, se han establecido rangos
de medición, al respecto Garzás et al. (2009) presenta los rangos considerados para la evaluación
de los atributos de proceso, en donde el rango obtenido, dependerá de la calificación obtenida en
las prácticas de atributo asociadas. En la Tabla 5 se muestran los rangos considerados, siendo el
nivel más bajo el No logrado y el más alto el Totalmente Logrado.
Asimismo, es importante mencionar que este rango de medición es utilizado en los procesos de
evaluación que no son necesariamente evaluaciones de cumplimiento de normas ISO, por ejemplo,
Garzás et al. (2009) aplica los rangos de medición de la norma ISO 15504 para medir el nivel de
madurez de un modelo propuesto para PyMEs.
Tabla 5: Rangos de evaluación de los atributos de procesos ISO 15504

Nivel Rango según ISO 15504
No logrado (N) El grado de alcance de los componentes asociados al atributo de
proceso es del 0% al 15%.
25
Parcialmente logrado (P) El grado de alcance de los componentes asociados al atributo de
Ampliamente logrado (L) El grado de alcance de los componentes asociados al atributo de
Totalmente logrado (F) El grado de alcance de los componentes asociados al atributo de
proceso es del 86% al 100%
Nota. Elaborado a partir de “Una aplicación de la Norma ISO/IEC 15504 para la Evaluación por
Niveles de Madurez de Pymes y Pequeños Equipos de Desarrollo”. (2009). REICIS. Revista
Española de Innovación, Calidad e Ingeniería del Software, 5(2). Garzás, J., Fernández, C. M., &
Piattini, M.: Autor.
Para Alarcón (2011) existen muchas ventajas en la adopción de la ISO 15504 en especial para las
PyMEs por ser una certificación más económica y adaptable a las necesidades y a la estructura de
trabajo para el ciclo de vida de desarrollo de software facilitando la mejora de los procesos de la
organización, lo cual se ve reflejado en mayor productividad y satisfacción por parte de los clientes
en el producto final, lo cual ayudaría a la organización a ser más competitiva y tener más acogida
en la región. Sin embargo, también se recomienda que no se implante en organizaciones con menos
de 20 personas, ya que obtener la certificación podría convertirse en un trabajo complejo por temas
de costos y disponibilidad de recursos.
Sin embargo, para Torres (2007) la evaluación de la ISO 15504 es difícil y confusa ya que esta
norma permite que el dominio de procesos sea tan amplio para abarcar todos los posibles ciclos de
vida, además esta complejidad la convierten significativamente más costosa que otros modelos.
En conclusión, se destaca que la implementación de la ISO 15504 podría ser costosa ya que su
alcance podría llegar a ser muy amplio y confuso, lo que involucraría mayor cantidad de recursos
y por lo tanto su adopción podría no ser la adecuada para pequeñas empresas.
1.2.4 IDEAL
Gremba J. & Myers C. (1997) afirman que el modelo IDEAL fue originalmente concebido como
un modelo de ciclo de vida para la mejora de procesos basado en el Modelo de Capacidad de
Madurez (CMM) para software, sin embargo, debido al potencial de modelo fuera del ámbito de
26
procesos, el el Sofware Engineering Institute (SEI) generó una primera versión del modelo para
enfatizar que era el primer paso hacia el objetivo de una aplicabilidad más amplia. Es por ello, que
según Garcia-Miller, S., Graettinger, C., & Kost, K. (2006), el SEI define el modelo IDEAL como
un modelo de mejora organizacional, no sólo de procesos, que sirve como hoja de ruta para iniciar,
planificar e implementar acciones de mejora.
El nombre del modelo deriva de las cinco fases que define: initiating (iniciar), diagnosing
(diagnosticar), establiching (establecer), acting (actuar) y learnig (aprender). En la Figura 2, se
describen las acciones a realizar en cada una de las fases, las cuales Gremba J. & Myers C. (1997)
definen de la siguiente manera:
Iniciar: en esta fase se identifican las razones comerciales para emprender el esfuerzo y se le
relaciona con los objetivos y metas organizacionales. En esta fase el apoyo de la alta dirección es
crítica, además se asignan los recursos y se establece una estructura que administre y soporte la
implementación.
Diagnosticar: durante esta fase se identifica el estado actual de la organización y se plantea el

estado deseado de la organización. Estos estados organizacionales se usan para desarrollar un
enfoque para mejorar la práctica comercial.
Establecer: esta fase tiene como objetivo desarrollar el plan de trabajo detallado, con las acciones
específicas, los hitos, entregables y las responsabilidades. Además, se establecen las prioridades
de acuerdo a los resultados obtenidos en la fase anterior.
Accionar: en esta fase se realiza el trabajo que se tenía conceptualizado y planificado en las fases
anteriores. En esta fase generalmente se consume más tiempo de calendario y más recursos que en
todas las fases combinadas.
Aprender: esta fase completa el ciclo de mejora ya que uno de los objetivos del modelo IDEAL es
la mejora continua. En esta fase se revisa toda la experiencia IDEAL para determinar qué se logró,
si el esfuerzo logró los objetivos previstos y cómo la organización puede implementar cambios de
manera más efectiva y/o eficiente en el futuro.
27
Figura 2: Fases del modelo IDEAL
Elaborado con información de “The IDEAL(SM) model. Software Engineering Institute
publication. (1997). Gremba J. & Myers C: Autor.
Finalmente, es importante mencionar que, en lo referente a recursos, Garcia M., S., Graettinger,
C., & Kost, K. (2006) afirman que, para el modelo IDEAL, el SEI recomienda al menos un
empleado de tiempo completo como líder de proyecto (PL). El PL debería llevar a cabo actividades
del Grupo Directivo de Gestión, el Grupo de Procesos de Ingeniería y el Grupo de Trabajo Técnico.
1.2.5 CMMI (Capability Maturity Model Integration)

El Equipo de Producto CMMI (2010), equipo especializado en CMMI del Software Engineering
Institute, define los modelos CMMI (Capability Maturity Model Integration) como colecciones de
buenas prácticas que ayudan a la mejora de los procesos en las organizaciones. Además, Goksen,
Cevik & Avunduk (2015) afirman que los modelos de CMMI son los más completos para la mejora
de los procesos de desarrollo y mantenimiento de productos y servicios. “La última versión de
CMMI, publicado por el Software Engineering Institute, es CMMI v.1.3, la cual se creó con el fin
28
de definir constelaciones para que se pueda aplicar en distintas áreas de interés” (Mesquida et al.,
2012, p.240). Estas constelaciones son, según el Equipo de Producto CMMI (2010) un conjunto
de componentes que se usan para construir modelos, materiales de formación y documentos para
la evaluación de un área de interés. Las áreas de interés o constelaciones definidas en CMMI v.1.3
se muestran en la Figura 3, donde se identifican 3 constelaciones: Constelación para el desarrollo
(CMMI-DEV), constelación para la adquisición (CMMI-ACQ) y constelación para los servicios
(CMMI-SVC). En este documento nos centraremos en CMMI-DEV por estar relacionado a la
industria de desarrollo de software y usaremos los términos de CMMI y CMMI-DEV
indistintamente.
Figura 3: Constelaciones de CMMI.

CMMI ha definido tres constelaciones: para el desarrollo (CCMI-DEV), para servicios (CMMI-
SVC) y para las adquisiciones (CMMI-ACQ), las cuales comparten componentes comunes, es por
ello que se representan con una intersección de conjuntos.
En lo que respecta a los beneficios de adoptar CMMI-DEV, Torres (2007) identifica las siguientes
ventajas:
 Las mejores prácticas de este modelo, están dirigidas exclusivamente para la industria de
software.
29
 Incluye las prácticas de institucionalización, las cuales permiten asegurar que los procesos
asociados con cada área de proceso sean efectivos, repetibles y duraderos en la organización.
 Explica paso a paso como lograr la mejora de los procesos, a través de niveles de madurez y
capacidad.
 Considera la transición del aprendizaje individual al aprendizaje de la organización haciendo

uso de mejora continua, lecciones aprendidas y uso de bibliotecas y bases de datos de proyectos
mejorados.
En relación a las desventajas de la adopción de CMMI, Torres (2007) considera las siguientes:
 Al ser una guía detallada, CMMI-DEV puede llegar a ser excesivamente extenso para algunas
organizaciones y por lo tanto el tiempo de implementación es mayor que otros modelos.
 Su total implementación requiere mayor inversión económica si se la compara con la ISO/IEC

15504 e ISO 9000.
 Debido a que sólo se pueden mejorar áreas de proceso del actual nivel de madurez; se centra
más en alcanzar el siguiente nivel de madurez, más que la mejora medible de los objetivos de
la organización.
 Presta excesiva atención a aspectos de gestión, dejando a un lado aspectos técnicos, o que
podamos mejorar áreas de proceso según nuestro interés obviando las relaciones y
dependencias entre ellas.
Finalmente, es importante mencionar que, empresas que han implementado CMMI-DEV en

alguno de sus niveles han manifestados mejoras en términos de costo, tiempo, calidad, satisfacción
del cliente y retorno de la inversión. Una evaluación realizada por Goldenson, D., & Gibson, D.
L. (2003), refleja que de 12 doce casos de estudio: 8 casos evidenciaron beneficios relacionados
con el cronograma, ya que disminuyó el tiempo de ejecución de tareas; 6 casos presentaron
beneficios con respecto al costo, ya que se disminuyeron los gastos en encontrar y solucionar
defectos; 3 casos evidenciaron mejoras en la satisfacción del cliente; 5 tuvieron mejoras
considerables en calidad lo cual se vio reflejado en la reducción de defectos a lo largo del ciclo de
vida del producto; y también se identificaron 3 casos en los que se logró un retorno positivo de la
inversión en proyectos de mejora de procesos basada en el modelo de CMMI-DEV.
30
1.3 Modelo CMMI-DEV
CMMI-DEV es una constelación del modelo CMMI que puede ser utilizado por las organizaciones
dedicadas a producir software y que desean mejorar sus procesos para asegurar productos de
calidad.
Para el caso de CMMI-DEV v.1.3 se han mapeado 22 áreas de proceso, Von, Silva, Buglione,
Scheidt & Prikladnicki (2010) identifican que un área de proceso es un conjunto de prácticas
relacionadas que cuando son implementadas satisfacen un conjunto de metas importantes para
realizar mejoras en dicha área de proceso.
Además, cada área de proceso tiene componentes agrupados en tres categorías: requeridos,
esperados e informativos. El Equipo de Producto CMMI (2010) define que los componentes
requeridos son esenciales para lograr la mejora del proceso mientras que los componentes
esperados describen las actividades que son importantes para lograr un componente CMMI
requerido y finalmente establecen un conjunto de componentes informativos los cuales tienen la
finalidad de ayudar a los usuarios del modelo a comprender los componentes requeridos y
esperados. Tal como se puede identificar en la Figura 4. Los componentes requeridos son las metas
genéricas y específicas, los componentes esperados son las prácticas genéricas y las específicas y
los componentes informativos son las sub prácticas, los ejemplos, declaración del propósito, notas
introductorias y áreas de proceso relacionadas.
A continuación, se explicarán cada uno de los componentes requeridos y esperados:
 Metas genéricas: el Equipo de Producto CMMI (2010) denomina a las metas genéricas como
“genéricas” porque la misma declaración de la meta se aplica a múltiples áreas de proceso.
Una meta genérica describe las características que deben estar presentes para institucionalizar
los procesos que implementan un área de proceso. Se dice que un proceso está
institucionalizado si se ejecuta consistentemente y existe compromiso. Además, una meta
genérica es un componente requerido del modelo y se utiliza en las evaluaciones para
determinar si se satisface un área de proceso.
 Prácticas genéricas: el Equipo de Producto CMMI (2010) denomina a las prácticas genéricas
como “genéricas” porque la misma práctica se aplica a múltiples áreas de proceso. Las
31
prácticas genéricas describen las actividades que se consideran importantes para lograr la meta
genérica.
 Meta específica: según el Equipo de Producto CMMI (2010) una meta específica está asociada
a una única área de proceso, es decir es específica para dicha área. Von et al. (2010) menciona
que en el marco de CMMI, cada área de proceso incluye un conjunto de prácticas relacionadas
que se requieren colectivamente para objetivos específicos, dichos objetivos a los que hacen
mención son las metas específicas.
 Prácticas específicas: según el Equipo de Producto CMMI (2010), las prácticas específicas se
asignan a las metas específicas, por lo tanto, una práctica específica describe las actividades
que se esperan en el logro de una meta específica de un área de proceso.
Figura 4: Componentes del modelo CMMI.

Tomado de CMMI Institute (2010). Spanish Technical Report CMMI V1.3.
32
1.3.1 CMMI continuo y escalonado
Según el Equipo de Producto CMMI (2010) la representación continua es una estructura donde los
niveles de capacidad proporcionan un orden recomendado para abordar la mejora de procesos
dentro de cada área de proceso especificada, mientras que la representación por etapas es una
estructura en la que el alcance de las metas de un conjunto de áreas de proceso establece un nivel
de madurez; cada nivel construye una base para los niveles siguientes.
Para poder detallar las diferencias entre los niveles de capacidad y madurez se ha desarrollado la
Tabla 6, en la que se presenta la comparación entre ambos niveles: el nivel de capacidad más
básico es el nivel 0 (Incompleto) y el más alto el nivel el nivel 3 (Definido), mientras que el nivel
de madurez más básico es el nivel 1 (Realizado) y el más alto el nivel 5 (En optimización)
Tabla 6: Comparación de los niveles de capacidad y de madurez.

Nivel Capacidad Madurez
0 Incompleto Proceso que, o bien no
se realiza, o se realiza
parcialmente.
1 Realizado Proceso que lleva a cabo Inicial Los procesos son generalmente
el trabajo necesario para ad hoc y caóticos.
producir productos de
trabajo. Se satisfacen las
metas específicas del
área de proceso.
2 Gestionado Es un proceso realizado Gestionado Los procesos se planifican y
que se planifica y ejecutan de acuerdo con las
ejecuta de acuerdo con políticas. Se monitorizan,
la política. controlan y revisan
3 Definido Es un proceso Definido Los procesos están bien
gestionado que se caracterizados y
adapta a partir del comprendidos, y se describen
conjunto de procesos en estándares, procedimientos,
estándar de la herramientas y métodos.
organización de acuerdo
33
a las guías de adaptación
de la organización.
4 Gestionado La organización y los
cuantitativamente proyectos establecen objetivos
cuantitativos para la calidad y
el rendimiento del proceso.
5 En optimización La organización mejora
continuamente sus procesos
basándose en una comprensión
cuantitativa de sus objetivos de
negocio y necesidades de
rendimiento.
Nota. Elaborado con información de “Spanish Technical Report CMMI V1.3”. CMMI Institute
(2010). Equipo de Producto CMMI: Autor.
Asimismo, el Team, C. P (2002) indica que existen muchas razones válidas para seleccionar una
representación o la otra, la elección dependerá de lo que la organización desee lograr. A
continuación, se detalla las características de cada una de las representaciones y que acciones
debería realizar una empresa dependiendo de la representación elegida:
Representación continua: se permite seleccionar el orden de mejoramiento que mejor cumpla

los objetivos de negocio y mitigue las áreas de riesgo de la organización. Además, habilita las
comparaciones entre las organizaciones en un área de proceso.
Por lo tanto, si una empresa opta por una representación continua deberá, en primer lugar,
elegir las áreas de proceso que desea evaluar, la elección dependerá de la necesidad,
oportunidad o estrategia de la empresa.
 Representación por etapas: se proporciona una secuencia probada de mejoras, comenzando con
las prácticas básicas de gestión y progresando a través de un camino predefinido y probado de
los niveles sucesivos, cada uno sirviendo de base para el siguiente. Además, permite las
comparaciones entre las organizaciones mediante el uso de niveles de madurez.
Por lo tanto, si una empresa opta por una representación por etapas, deberá iniciar
obligatoriamente con los procesos considerados en el nivel de madurez 2 (Gestionado), para
34
que luego de alcanzar dicho nivel de madurez pueda proceder con el siguiente nivel, que sería
el nivel de madurez 3, y así continuar hasta lograr el nivel deseado por la organización, siendo
el máximo nivel de madurez, el nivel 5 (Optimizado).
En la Tabla 7 se han identificado los procesos por categorías (Gestión de procesos, gestión de
proyectos, ingeniería y soporte) mapeados según los niveles de madurez establecidos por
CMMI-DEV, como se puede apreciar, a diferencia de los niveles de capacidad no se considera
el nivel uno por considerarse el nivel en el que los procesos se realizan de manera ad-hoc y por
lo tanto sería el estado inicial de toda empresa.
Tabla 7: Procesos de CMMI-DEV

Nivel de Categorías
madurez Gestión de procesos Gestión de Ingeniería Soporte
proyectos
5 Innovación y Análisis causal y
Optimizado distribución resolución (CAR)
organizacional (OID)
4 Rendimiento del Gestión
Gestionado proceso cuantitativa de
cuantitativamente organizacional (OPP) proyectos (QPM)
3 Enfoque proceso Gestión integrada Desarrollo de Análisis de decisión u
Definido organizacional (OPF) de proyectos requisitos (RD) resolución (DAR)
Definición del (IPM) Solución técnica
proceso Gestión de riesgos (TS)
organizacional (OPD) (RSKM) Verificación (VER)
Formación de la Validación (VAL)
organización (OT) Integración del
producto (PI)
2 Planificación del Gestión de Gestión de la
Gestionado proyecto (PP) requisitos (REQM) configuración (CM)
Monitorización y Aseguramiento de la
control del calidad del proceso y
proyecto (PMC) producto (PPQA)
Gestión del Medición y análisis
acuerdo con el (M&A)
35
suministrador
(SAM)
1
Inicial
1.3.2 Nivel de Madurez 2 en CMMI-DEV

El nivel de madurez 2 (ML2) indica que los procesos son gestionados ya que el Equipo de Producto
CMMI (2010) manifiesta que en dicho nivel se garantiza que, en los proyectos, los procesos se
planifican y ejecutan de acuerdo con las políticas; los proyectos emplean personal calificado que
dispone de recursos adecuados para producir resultados controlados; se involucra a las partes
interesadas relevantes; se monitorizan, controlan y revisan; y se evalúan en cuanto a la adherencia
a sus descripciones de proceso. Con lo cual se puede afirmar que en una empresa con nivel de
madurez 2 sus procesos se ejecutan normalmente incluso en periodos bajo presión. Además, para
que una empresa pueda alcanzar el ML2, Monteiro, P., Machado, R. J., & Kazman, R. (2009)
afirman que la organización se debe asegura de que, en sus proyectos de desarrollo de software,
los requisitos se gestionan y que sus procesos se planifican, realizan, miden y controlan.
1.3.3 Áreas de proceso del Nivel de Madurez 2 de CMMI-DEV

El Equipo de Producto CMMI (2010), define un área de proceso como un grupo de prácticas
relacionadas. El mapeo de las áreas de procesos del nivel de madurez 2 asociadas a su
correspondiente categoría se encuentran mapeadas en la Tabla 8, donde identificamos que en el
nivel de madurez 2 se consideran las áreas de proceso básicas de gestión de proyectos las cuales
contienen las actividades relacionadas con el establecimiento y mantenimiento del plan del
proyecto, el establecimiento y mantenimiento de los compromisos, la monitorización del progreso
frente al plan, la toma de acciones correctivas y la gestión de acuerdos con proveedores. Además,
se consideran los procesos de soporte que permiten gestionar la configuración, medir y analizar
los procesos y asegurar la calidad tanto de los procesos como de los productos.
36
Tabla 8: Áreas de proceso del nivel de madurez 2 de CMMI-DEV
Áreas de proceso Acrónimo Categoría
Monitorización y control del proyecto PMC Gestión de proyectos
Planificación del proyecto PP Gestión de proyectos
Gestión de requisitos REQM Gestión de proyectos
Gestión de acuerdos con proveedores SAM Gestión de proyectos
Gestión de la configuración CM Soporte
Medición y análisis MA Soporte
Aseguramiento de la calidad del proceso y del producto PPQA Soporte
Asimismo, cada área de proceso tiene la declaración de su propósito, la declaración de los

propósitos de las áreas de proceso del nivel de madurez 2 se encuentran detalladas en la Tabla 9.
Tabla 9: Propósito de las áreas de proceso

Área de proceso Propósito
Gestión de requisitos El propósito de REQM es gestionar los requisitos de los productos
(REQM) 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.
Planificación del El propósito de PP es establecer y mantener planes que definan las
proyecto (PP) actividades del proyecto.
Monitorización y control El propósito de PMC es proporcionar una comprensión del progreso
del proyecto (PMC) del proyecto para que se puedan tomar las acciones correctivas
apropiadas, cuando el rendimiento del proyecto se desvíe
significativamente del plan.
Gestión de acuerdos con El propósito de SAM es gestionar la adquisición de productos y
proveedores (SAM) servicios de proveedores.
Gestión de la El propósito de CM es establecer y mantener la integridad de los
configuración (CM) productos de trabajo utilizando la identificación de la configuración,
37
el control de la configuración, el informe del estado de la
configuración y las auditorías de la configuración.
Medición y análisis (MA) El propósito de MA es desarrollar y mantener la capacidad de
medición utilizada para dar soporte a las necesidades de
información de la gerencia.
Aseguramiento de la El propósito PPQA es proporcionar al personal y a la gerencia una
calidad del proceso y del visión objetiva de los procesos y de los productos de trabajo
producto (PPQA) asociados.
Entendiendo el propósito de cada una de las áreas de proceso del nivel de madurez 2 de CMMI-
DEV y conociendo que en dicho nivel lo que se busca es asegurar que los procesos estén
gestionados, se puede asegurar que, encuna organización que desee alcanzar el nivel de madurez
2, debe existir un compromiso organizacional para comenzar a realizar las actividades de sus
procesos de gestión de proyectos y de soporte, de manera realista, planificada y controlada para
asegurar la calidad de los procesos y de los productos resultantes. Por lo tanto, los desafíos para
alcanzar el nivel de madurez 2 de CMMI-DEV se puede resumir en:
El reto del nivel 2 está en que las personas y la organización aprendan a comprometerse
en forma realista, entendiendo cual es el trabajo a realizar, estimándolo (tamaño, esfuerzo,
costos, recursos, presupuesto, y cronograma) formalmente, planeándolo, controlando su
progreso y sus riesgos y gestionando labores de soporte y apoyo tanto al proyecto como al
futuro de la organización, en lo relacionado con el control de versiones y líneas de base, la
gestión de proveedores, la definición y análisis de mediciones, el aseguramiento de la
calidad de los procesos utilizados y los productos de software creados. (Palacios, H.,
Porcell, N., 2012, p.115)
Aunque, el reto parece complicado, realmente no debería obstaculizar ningún proyecto de

implantación o mejora de procesos basado en CMMI-DEV, ya que dicho modelo brinda los
lineamientos necesarios para alcanzar cada uno de los niveles de madurez mediante la consecución
de metas genéricas y metas específicas, además, el modelo de CMMI-DEV detalla cómo logras
38
dichas metas mediante prácticas tanto, específicas como genéricas. Por lo tanto, podemos afirmar
que, si una organización desea lograr el nivel de madurez 2 o algún otro, deberá enfocar sus
esfuerzos a asegurar que se logran cada una de las metas y prácticas genéricas y específicas
propuestas por el modelo. Mayor detalle de las metas genéricas y específicas, así como de sus
respectivas prácticas se dará en la siguiente sección.
1.3.4 Metas genéricas y prácticas genéricas del nivel de madurez 2 de CMMI-

DEV
En la Tabla 10 se visualizan las metas y prácticas genéricas de cada uno de los procesos del nivel
de madurez 2.
Tabla 10: Metas y prácticas genéricas del nivel de madurez 2

Metas genéricas Prácticas genéricas
GG 1 Lograr las metas específicas GP 1.1 Realizar las prácticas específicas
GG 2 Institucionalizar un proceso GP 2.1 Establecer una política de la organización
gestionado GP 2.2 Planificar el proceso
GP 2.3 Proporcionar recursos
GP 2.4 Asignar responsabilidad
GP 2.5 Formar al personal
GP 2.6 Controlar los productos de trabajo
GP 2.7 Identificar e involucrar a las partes
interesadas relevantes
GP 2.8 Monitorizar y controlar el proceso
GP 2.9 Evaluar objetivamente la adherencia
GP 2.10 Revisar el estado con el nivel directivo
(2010). Equipo de Producto CMMI.
39
1.3.5 Metas específicas y prácticas específicas del nivel de madurez 2 de CMMI-
DEV
A continuación, se mostrará el detalle de las metas específicas con sus respectivas prácticas para
cada uno de los procesos del nivel de madurez 2.
1.3.5.1 Gestión de requisitos (REQM)

Las metas y prácticas específicas asociadas al proceso de gestión de requisitos se encuentran
detalladas en la Tabla 11.
Tabla 11: Metas y prácticas específicas de gestión de requisitos

Meta específica Práctica específica
SG1. Gestionar los requisitos SP1.1. Comprender los requisitos.
SP1.2. Obtener el compromiso sobre los requisitos.
SP1.3. Gestionar los cambios a los requisitos.
SP1.4. Mantener la trazabilidad bidireccional de los

requisitos.
SP1.5. Asegurar el alineamiento entre el trabajo del

proyecto y los requisitos.
Nota. Elaborado a partir de información del “Spanish Technical Report CMMI V1.3.” 201). CMMI
Institute (2010). Equipo de Producto CMMI.
1.3.5.2 Planificación del proyecto (PP)

Las metas y prácticas específicas asociadas al proceso de planificación del proyecto se encuentran
detalladas en la Tabla 12
40
Tabla 12: Metas y prácticas específicas de planificación del proyecto
SG1. Establecer las estimaciones SP1.1. Estimar el alcance del proyecto.
SP1.2. Establecer las estimaciones de los atributos de los

productos de trabajo y de las tareas.
SP1.3. Definir las fases del ciclo de vida del proyecto.
SP1.4. Estimar el esfuerzo y el coste.
SG2. Desarrollar un plan de SP2.1. Establecer el presupuesto y el calendario.

proyecto
SP2.2. Identificar los riesgos del proyecto.
SP2.3. Planificar la gestión de los datos.
SP2.4. Planificar los recursos del proyecto.
SP2.5. Planificar el conocimiento y las habilidades

necesarias.
SP2.6. Planificar la involucración de las partes interesadas.
SP2.7. Establecer el plan de proyecto.
SG3. Obtener el compromiso con SP3.1. Revisar los planes que afectan al proyecto.
el plan
SP3.2. Conciliar los niveles de trabajo y de recursos.
SP3.3. Obtener el compromiso con el plan.
41
1.3.5.3 Monitorización y control de proyectos (PMC)
Las metas y prácticas específicas asociadas al proceso de monitorización y control de proyectos se
encuentran detalladas en la Tabla 13.
Tabla 13: Metas y prácticas específicas de monitorización y control de proyectos

SG1. Monitorear el proyecto SP1.1. Monitorear los parámetros de planificación del

frente al plan proyecto.
SP1.2. Monitorear los compromisos.
SP1.3. Monitorear los riesgos del proyecto.
SP1.4. Monitorear la gestión de los datos.
SP1.5. Monitorear la involucración de las partes

interesadas.
SP1.6. Llevar a cabo las revisiones de progreso.
SP1.7. Llevar a cabo las revisiones de hitos.
SG2. Gestionar las acciones SP2.1. Analizar los asuntos de discusión.

correctivas hasta su cierre
SP2.2. Llevar a cabo las acciones correctivas.
SP2.3. Gestionar las acciones correctivas.
1.3.5.4 Gestión de acuerdos con proveedores (SAM)

Las metas y prácticas específicas asociadas al proceso de gestión de acuerdos con proveedores se
encuentran detalladas en la Tabla 14.
42
Tabla 14: Metas y prácticas específicas de gestión de acuerdos con proveedores
SG1. Establecer acuerdos con SP1.1. Determinar el tipo de adquisición para cada producto
proveedores o componente de producto a adquirir.
SP1.2. Seleccionar a los proveedores en base a una

evaluación de su capacidad para cumplir los requisitos
especificados y los criterios establecidos.
SP1.3. Establecer y mantener los acuerdos con proveedores.
SG2. Satisfacer los acuerdos con SP2.1. Realizar las actividades con el proveedor tal y como
los proveedores se especifica en el acuerdo con el proveedor.
SP2.2. Asegurar que el acuerdo con el proveedor se cumple

antes de aceptar el producto adquirido.
SP2.3. Asegurar la transición de los productos adquiridos

del proveedor.
Institute - Equipo de Producto CMMI.
1.3.5.5 Gestión de configuración (CM)

Las metas y prácticas específicas asociadas al proceso de gestión de configuración se encuentran
43
Tabla 15: Metas y prácticas específicas de gestión de configuración
SG1. Establecer las líneas base SP1.1. Identificar los elementos de configuración, los
componentes, y los productos de trabajo relacionados que
serán puestos bajo gestión de configuración.
SP1.2. Establecer y mantener un sistema de gestión de

configuración y de gestión de cambios para controlar los
productos de trabajo.
SP1.3. Crear o liberar las líneas base para uso interno y para
la entrega al cliente.
SG2. Seguir y controlar los SP2.1. Seguir las peticiones de cambio a los elementos de
cambios configuración.
SP2.2. Controlar los cambios a los elementos de

configuración.
SG3. Establecer la integridad SP3.1. Establecer y mantener los registros que describen los
elementos de configuración.
SP3.2. Realizar auditorías de configuración para mantener

la integridad de las líneas base de configuración.
1.3.5.6 Medición y análisis (MA)

Las metas y prácticas específicas asociadas al proceso de medición y análisis se encuentran
44
Tabla 16: Metas y prácticas específicas de medición y análisis
SG1. Alinear las actividades de SP1.1. Establecer los objetos de medición.

medición y análisis
SP1.2. Especificar las medidas.
SP1.3. Especificar los procedimientos de recogida y de

almacenamiento de datos.
SP1.4. Especificar los procedimientos de análisis.
SG2. Proporcionar los resultados de SP2.1. Obtener los datos de la medición.

la medición
SP2.2. Analizar e interpretar los datos de la medición.
SP2.3. Almacenar los datos y los resultados.
SP2.4. Comunicar los resultados.
1.3.6 Método estándar para la evaluación de procesos del modelo CMMI –

SCAMPI
Valle, Santos & Loures (2017) afirman que el Método de Evaluación CMMI Estándar para la
mejora de procesos (SCAMPI) es el método más conocido y utilizado para identificar fortalezas,
debilidades y calificaciones relacionadas con los modelos de referencia de Capability Maturity
Model Integration (CMMI). Existen tres clases de evaluación de SCAMPI las cuales se diferencian
entre si principalmente por el tamaño del equipo evaluador y la rigurosidad de la evaluación, tal
como se muestra en la Tabla 17, donde se presenta el nivel exigido de las características (evidencia
objetiva, calificación, recursos, equipo) para cada clase de evaluación SCAMPI.
45
Tabla 17: Clases de SCAMPI
Característica Clase C Clase B Clase A
Cantidad de evidencias objetivas Bajo Medio Alto
Calificaciones generadas No No Sí
Necesidad de recursos Baja Media Alta
Tamaño del equipo Pequeño Mediano Grande
Nota. Realizado con información de “A family of SCAMPI Appraisal Methods.”. Software
Engineering Institute (2003). Hayes W., Miluk G., Kitson D.: Autores. Recuperado de:
https://resources.sei.cmu.edu/asset_files/Presentation/2003_017_001_23182.pdf
En el Annual Report to Partners (2016) de CMMI se afirma, que las evaluaciones de CMMI son
reconocidas en todo el mundo como una medida confiable de la capacidad de una organización y
la madurez del proceso, asimismo, en el informe se afirma que a febrero del 2016 se han reportado
2.266 evaluaciones de SCAMPI a nivel mundial. Con lo que podemos afirmar que las empresas
que buscan un reconocimiento a nivel mundial, optan por evaluaciones SCAMPI para poder
obtener una certificación de CMMI en algún nivel.
Con respecto a la facilidad para obtener la certificación CMMI, Jezreel, Marcos & Mirna (2017)
manifiestan que algunas empresas no logran pasar la evaluación en el nivel de madurez deseado,
porque a pesar de ser una evaluación formal su implementación es realizada de manera empírica
en las organizaciones. Además, carece de un fundamento matemático y sólo se toma en cuenta la
experiencia del Lider Appraisal y el equipo auditor en la implementación y mejora de procesos de
software. Sin embargo, a pesar del esfuerzo que demanda obtener una certificación de CMMI en
la industria de software varias empresas a nivel mundial han optado por esta certificación en la
constelación CMMI-DEV. Además, como podemos observar en el Tabla 18, en los últimos tres
años existe una tendencia creciente de certificaciones CMMI-DEV v. 1.3 en sus diferentes niveles,
el crecimiento es mayor al 15% anual, desde 1649 en el año 2015 hasta 2298 al finalizar el año
2017. También se puede observar que el mayor número de certificaciones corresponden al Nivel
3 y el menor número de certificaciones corresponde al Nivel 4, por lo que se puede sugerir, que el
Nivel adecuado para una empezar una certificación en CMMI–DEV es el Nivel 2.
46
Tabla 18: Certificaciones CMMI-DEV v.1.3
Año Nivel 2 Nivel 3 Nivel 4 Nivel 5 Total
2015 158 1291 46 154 1649
2016 141 1592 64 187 1984
2017 144 1861 48 245 2298
Nota: Elaborado con datos oficiales recuperados de: https://sas.cmmiinstitute.com/pars/pars.aspx
Otro dato importante es que China es el país líder en el mundo, en cuanto a mayor cantidad de
certificaciones CMMI-DEV v.1.3, en la Tabla 19 podemos observar que en el año 2017 se
obtuvieron 1504 certificaciones en ese país, lo que representa más del 65% del número total de
certificaciones de ese año a nivel mundial.
Tabla 19: Certificaciones CMMI-DEV v.1.3, en China

Año Nivel 2 Nivel 3 Nivel 4 Nivel 5 Total
2015 3 762 36 78 879
2016 6 1062 46 101 1215
2017 4 1304 33 163 1504
A nivel Latinoamericano, México es el país con mayor número de certificaciones, la distribución

de certificaciones se observa en la Tabla 20 donde identificamos que, a diferencia de China, los
niveles con mayor número de certificaciones son los Niveles 2 y 3. Asimismo, las cifras revelan
que en general el número de Certificaciones de CMMI-DEV en México es mucho menor a el
número de certificaciones que tiene China.
Tabla 20: Certificaciones CMMI-DEV v.1.3 en México

Año Nivel2 Nivel3 Nivel4 Nivel5 Total
2015 23 22 2 1 48
2016 32 21 1 5 59
2017 36 41 0 11 88
47
Finalmente, en la Tabla 21 se muestran el número de certificaciones de CMMI-DEV por niveles
en el Perú. Con cifras muy por debajo de países como China (el líder mundial) y México (el líder
de la región), lo cual revela que existe una importante brecha por cubrir en cuanto a la relevancia
que le dan las empresas de la industria del software de tener una certificación de calidad
especializada en procesos de dicha industria. Reducir esta brecha es relevante porque al no contar
con certificaciones que garanticen la calidad de los procesos de la industria de Desarrollo de
Software deja al Perú como un país menos atractivo en el mercado mundial.
Tabla 21: Número de certificaciones CMMI-DEV v.1.3 en el Perú

Año Nivel2 Nivel3 Nivel4 Nivel5 Total
2015 0 5 0 2 7
2016 2 6 0 2 10
2017 0 6 0 1 7
48
CAPÍTULO 2: SITUACIÓN PROBLEMÁTICA
El propósito del siguiente capítulo es presentar a la organización que será objeto de estudio y
realizar un análisis cuantitativo y cualitativo de la situación actual de la empresa que permita
identificar la problemática a abordar en el presente documento de tesis.
2.1 Objeto de estudio
2.1.1 Presentación de la empresa

La empresa objeto de estudio de la presente propuesta de tesis es una consultora peruana con más
de 50 años de experiencia en proyectos de ingeniería para la industria del cemento y que forma
parte de un Grupo Concreto importante del país. No se mencionarán en el presente documento el
nombre ni la razón social de la empresa por motivo de confidencialidad.
Actualmente, la empresa tiene presencia tanto a nivel a nacional como en el extranjero, ya que en
el año 2014 empezó operaciones en Ecuador, en el año 2015 en los Estados Unidos y se tiene
pronosticado su próximo ingreso al mercado de Chile a fines del año 2018. Los servicios que
brinda la empresa tanto a clientes externos como a otras empresas del grupo, se muestra en la
Figura 5 los cuales se describen a continuación:
 Asesoría y asistencia técnica: servicio brindado a clientes externos para apoyarlos en el

monitoreo de la eficiencia en la productividad de las plantas, reportes de calidad e
investigaciones requeridas por el cliente como identificación de materia primas y determinar
su calidad.
 Desarrollo y gestión de proyectos de construcción: servicio por el cual se gestionan y

desarrollan proyectos de ingeniería civil bajo una metodología de gestión de proyectos basadas
en el estándar del Project Management Institute (PMI). Los proyectos que se gestionan son
tanto para el estado peruano como para el sector privado nacional e internacional.
 Análisis y ensayos físico-químicos: servicio brindado a empresas del Grupo como a clientes
externos. En los laboratorios se realizan análisis de materiales: cemento, calizas, yesos arenas,
49
minerales y carbón. Esta unidad cuenta con un sistema de gestión de calidad y cuenta con la
acreditación de la NTP-ISP/IEC 17025.
 Servicios informáticos: servicio de outsourcing brindado exclusivamente a empresas del Grupo

Concretero a nivel nacional e internacional (sólo en Ecuador), en el cual se ofrecen servicios
de integración, así como proyectos de desarrollo, implementación y mantenimiento de
herramientas de gestión. Es importante mencionar que, desde el año 2013, este servicio no es
brindado a una empresa del grupo debido a que dicha empresa decidió subcontratar este
servicio a una empresa externa.
Figura 5: Servicios brindados por la empresa objeto de estudio.

Se identifica las unidades de negocio con los servicios que brindan tanto a clientes externos como
a clientes del mismo grupo. Los nombres de Empresa 1, Empresa 2 y Empresa 3 representan otras
empresas del Grupo y son utilizados por motivos de confidencialidad.
La información de la misión, visión y valores de la empresa consultora ha sido obtenida de la

página institucional de la organización y se presenta a continuación:
50
2.1.1.1 Misión
 Identificar oportunidades en el mercado aplicando las mejores tecnologías, anticipándonos a

las necesidades de nuestros clientes.
 Proveer servicios de ingeniería incluyendo gerencia y supervisión de proyectos satisfaciendo

los objetivos de costo, tiempo, alcance y calidad previamente definidos en los proyectos.
 Brindar asesoría técnica para el cumplimiento de la productividad en las instalaciones

industriales, así como con la calidad en sus operaciones y productos.
 Formar equipos multidisciplinarios, altamente competitivos y comprometidos con los clientes,

respaldados por una cultura de dedicación al trabajo y mejora continua.
2.1.1.2 Visión
Ser una empresa consultora peruana con experiencia a nivel mundial que busca permanentemente
la creación de valor para sus clientes, aplicando tecnología de punta con soluciones innovadoras
en la industria cementera, construcción, minería, energía, agricultura y otros sectores relacionados,
nuestra orientación está enfocada hacia la productividad y desarrollo sostenible como factores
prioritarios para fomentar la industria y el desarrollo del país.
2.1.1.3 Valores
La organización trabaja bajo los valores de honestidad, calidad en el servicio, orientación al cliente,
trabajo en equipo y adaptabilidad al cambio, contando con un calificado y multidisciplinario staff
de profesionales, contribuyendo de manera decisiva en el sector empresarial peruano de manera
sustentable con acceso a tecnologías eficientes y de menor impacto ambiental.
2.1.1.4 Estructura organizativa

El mapa organizacional de la empresa se encuentra diagramado en la Figura 6, donde se puede
apreciar que la organización tiene una estructura jerárquica, la cual está liderada por un Directorio
seguido del Presidente y del Gerente General, cuyas funciones están soportadas por las Áreas de
legal, Asesoría de inmobiliaria y de Asesoría de estudios económicos. Asimismo, se identifican
tres gerencias: Gerencia de Desarrollo Técnico, Gerencia de Operaciones Técnicas y la Gerencia
de Administración y finanzas, siendo esta última gerencia la que tiene a su cargo el Departamento
de Sistemas.
51
Figura 6: Organigrama de la empresa consultora.
El organigrama de la empresa tiene una estructura jerárquica. El Departamento de Sistema reporta
directamente a la Gerencia de Administración y Finanzas. Tomado del Plan Organizacional 2017.
Actualmente, el Departamento de Sistemas cuenta con una oficina de proyectos o PMO que es la
que brinda soporte directo a la gerencia del Departamento y tres áreas operativas: i. Redes,
Infraestructura y Soporte. ii. Operaciones y iii. Desarrollo de proyectos. Además, cuenta con un
total de 30 trabajadores en planilla distribuidos en las diferentes áreas del Departamento, tal como
se muestra en la Tabla 22.
Tabla 22: Colaboradores en el Departamento de Sistemas

Área organizativa Cantidad de colaboradores
Gerencia 1
PMO 2
Redes, Infraestructura y Soporte 9
52
Operaciones 6
Desarrollo de Proyectos de TI 12
TOTAL 30
2.1.2 Análisis FODA del Departamento de Sistemas
Fortalezas
 Competencias del equipo de trabajo
Las competencias laborales tienen que ver con la capacidad, habilidades, conocimientos y
aptitudes en el profesional que le permiten asumir los retos y contingencias que pueda tener su
puesto de trabajo de una mejor manera. Consultando con la sub gerencia de TI y las jefaturas de
operaciones, desarrollo y calidad se identificaron las siguientes competencias en el personal:
- Trabajo en equipo
El desarrollo de los proyectos casi nunca es atendido por sola persona, involucra (por lo menos)
un jefe de proyecto, un analista programador, un analista de calidad y recurso para el despliegue
de cambios; los cuales se organizan para terminar el trabajo asignado.
- Organización
El trabajo en proyecto se basa en una planificación en donde se definen las actividades a realizar,
así como sus tiempos de ejecución lo cual ayuda a los recursos asignados a organizarse y poder
priorizar sus actividades. Para el caso de la mesa de ayuda, se ayudan de la herramienta KACE
para conocer su carga de trabajo en el día y en la semana inclusive priorizada la atención de tickets.
- Análisis
Parte importante dentro de la ejecución de proyectos es el análisis de datos, la cual es necesaria en

todas las fases del ciclo de desarrollo de un proyecto de software por ejemplo al inicio con el
análisis de las solicitudes de los clientes para convertirlos en requerimientos; y al presentarse un
53
incidente a atenderse por la mesa de ayuda, dentro de esta atención –por procedimiento- siempre
se indica el diagnóstico (resultado del análisis) y la solución inmediata y/o definitiva.
- Toma de decisiones
Asociado a la competencia del numeral 5, producto del análisis de los datos o de una situación se
toma decisión para actuar. Dentro de los equipos de trabajo en el área, muchas situaciones
(conflictos, ambigüedades, controversias) son resueltas sin requerir la intervención de la jefatura
correspondiente o de la sub gerencia de TI.
Orientación al cliente
En el área se busca la empatía, que quiere decir “ponerse en los zapatos del otro”, bajo esta premisa
se busca ser empático con el cliente para quien y con quien se ejecutan los proyectos; se le hace
partícipe al cliente (usuario) en las fases del ciclo de vida del proyecto de desarrollo de software;
mantener una comunicación constante ayuda a conseguir la empatía.
- Creatividad e innovación
Actualmente se vienen trabajan en dos proyectos de innovación, los cuales requieren que los
recursos en las que se puedan proponer nuevas ideas, cuestionar lo que ya vienen funcionando y
ser capaces de ejecutarlas.
 Ganas de crecer
Durante las entrevistas al personal al momento de su reclutamiento siempre manifestaron su deseo

de crecer y de hacer carrera dentro de la empresa. En el caso del área de desarrollo de proyectos
un analista programador puede llegar a ser con el tiempo y de forma escalonada analista técnico,
analista funcional y jefe de proyecto; luego pensar en llegar a niveles de jefatura del área.
 Buen clima laboral
Entre los miembros del área se practica el respeto mutuo y la tolerancia; la buena escucha para la
toma de decisiones y lograr consensos; facilitar la información que se pueda solicitar; manejo de
crisis; confianza en la persona y en su trabajo. Adicionalmente, se cuenta con un espacio adecuado
para el óptimo desenvolvimiento de la persona (equipos, muebles, iluminación, etc.).
54
 Capacitación continua
En la elaboración del presupuesto anual del área de sistema uno de los principales rubros es la
capacitación de los recursos, estos pueden ser grupales o personales, estos últimos a menudo son
a solicitud del mismo colaborador.
Debilidades
 Poca comunicación con los usuarios finales
Las coordinaciones con los usuarios finales no es la adecuada tanto para esclarecer dudas durante
el desarrollo del proyecto como para el informe de avance de los mismos. En la sección de
fortalezas se indicó que se trabaja la empatía con el cliente, pero este punto en una tarea pendiente
por mejorar.
 Poca comunicación entre áreas
Durante el ciclo de vida de proyecto de desarrollo de software no sólo el área de desarrollo de

proyecto es la participante sino otras áreas como la PMO, el área de calidad y el área de soporte;
las cuales tienes tareas asignadas en el proyecto, pero en ocasiones no existe la debida
comunicación generando retrasos y asignaciones a los recursos en otras tareas.
 No se cumplen con los procesos
Existen puntos en el proceso de desarrollo de software que son omitidos o postergados con el fin
de hacer más fluido el proceso o por la necesidad de no dejar sin carga de trabajo a los otros
recursos asignados; estos puntos “omitidos o postergados” corresponden principalmente, a las
revisiones de comité, las cuales depende de la disponibilidad de alguna de las jefaturas para
realizarlas. Además, debido a que es necesaria la aprobación en comité de los avances para poder
continuar con las actividades pendientes, puede generar cuellos de botella que impiden el avance
programado de un proyecto.
 Rotación de personal
Se presentan casos en los que colaboradores asignados a un proyecto dejan la empresa en plena
ejecución del proyecto por lo que conseguir y darle la inducción a otro recurso queda fuera de lo
planificado y se traduce en un mayor tiempo y costo para el proyecto. Esta situación se refleja aún
55
más cuando el recurso que deja la empresa corresponde al jefe de proyecto. Anualmente se tenía
un promedio 5 colaboradores que se retiran de la empresa ya sea por una mejor oportunidad de
trabajo o por desacuerdo con la forma de trabajar en el área.
 Problemas con la infraestructura de la red para la comunicación con usuarios
Se ha adoptado una política de reducir las reuniones presenciales y hacerlas de forma virtual
haciendo uso de la herramienta de Google, HangOut. Sin embargo, este tipo de comunicación
experimenta lentitud y problemas de conectividad por no contar con una red capaz de soportar el
ancho de banda necesario para voz y video.
Oportunidades
 Brindar servicios a empresas fuera del grupo
Actualmente el Departamento de Sistemas sólo brinda sus servicios (soporte, mantenimiento y

desarrollo de soluciones) a las empresas del grupo. Existe la posibilidad de contar con una cartera
de clientes fuera del grupo (rubro de consultora de sistemas) si se logra mejorar los procesos del
área de desarrollo de software de la empresa consultora.
 Automatización de pruebas
Actualmente, las pruebas de control de calidad son manuales, se arman casos de prueba y los
analistas de control de calidad son los responsables de ejecutar cada caso de prueba; de ser varios
casos de prueba se toma una muestra de ellos para garantizar el funcionamiento de estos.
 Certificación de calidad de procesos de software
Al mejorar el proceso de desarrollo de software y mantenerlo en el tiempo, se puede optar por una
certificación en CMMI-DEV, lo que podría permitir: i) Acompañar a la estrategia de expansión de
la empresa y ii) Ampliar la cartera de clientes en un futuro.
Amenazas
 Percepción de demora en la atención de los requerimientos de los usuarios
Ante la falta de una adecuada comunicación con el cliente y la demora en la entrega de los
productos, el cliente queda insatisfecho con el trabajo a pesar de que el producto cumple con sus
56
requerimientos; lo que provoca que el cliente no esté tan convencido de trabajar con el
Departamento de Sistemas y por lo tanto podría llegar a prescindir de los servicios de tecnología
de información ofrecidos por la empresa.
 Existencia de otras consultoras con tarifas más económicas
En el mercado existen otras empresas que brindan servicio de soporte, mantenimiento y desarrollo
de soluciones (GMD, COSAPI, ROYAL SYSTEM, etc.) las cuales por ganarse al cliente pueden
ofrecer tarifas más bajas a las tarifas con las que cuentan los recursos de la empresa; lo cual puede
provocar –en conjunto con la amenaza anterior- a optar por un servicio externo. Situación que ya
tiene precedentes, como se mencionó en la sección de Presentación de la empresa, una de las
empresas del grupo ha externalizado los servicios de tecnología de información.
2.1.3 Objetivos estratégicos

En esta sección se presentarán los objetivos estratégicos de la empresa consultora, para luego
realizar el despliegue hacia los objetivos estratégicos del Departamento de Sistemas con el objetivo
de identificar cómo esta área apoya a los objetivos organizacionales de la empresa.
La empresa objeto de estudio, en su Plan Estratégico para los años 2014 al 2018, presenta los
siguientes objetivos estratégicos:
 Aumentar el EBITDA en un 12.5% anual para los años del 2014 al 2018.
 Agregar valor asegurando la sostenibilidad, seguridad y productividad en los servicios

ofrecidos al cliente.
 Asegurar la satisfacción del cliente no menor al 95%.
 Diferenciarnos poniendo valor a la innovación en productos, servicios y procesos.
Para lograr los objetivos de la organización el Departamento de Sistemas ha establecido los

siguientes objetivos estratégicos:
 Lograr la excelencia operativa.
 Mantener la vigilancia tecnológica y la demanda del mercado.
 Monitorear la satisfacción del cliente.
57
 Asegurar la adopción de las herramientas de TI.
En la Tabla 23 se muestra el despliegue de los objetivos estratégicos organizacionales hacia los

objetivos estratégicos del Departamento de Sistemas, asimismo, se indican los atributos claves de
servicio de TI y los indicadores para asegurar la consecución de los objetivos.
Tabla 23: Objetivos estratégicos de la unidad de negocio de TI.

Objetivo Objetivo Atributo clave del Indicadores de TI
estratégico estratégico servicio de TI
organizacional Departamento
Sistemas
Aumentar el Alcanzar la Proveer servicios de Acuerdo de nivel de servicio
EBITDA en un eficiencia en los acuerdo a un estándar (SLA) de atención al 95%.
12.5% anual procesos. Disponibilidad de todos los
servicios de sistemas al 99%
Planificar y Acuerdo de nivel de servicio
suministrar el de incidentes al 95% dentro
despliegue del cambio del SLA.
Disminuir en 40% los
incidentes por
procedimientos.
Proveer marcos de Indicadores de tiempo y costo
trabajo técnicos y de de proyectos no menores al
gestión. 95%
Agregar valor en Asegurar la Asegurar que los Promover la capacitación y
los servicios adopción de las clientes obtengan el difusión en el uso de las
ofrecidos al herramientas de TI. mejor valor de su herramientas de TI de los
cliente inversión en clientes.
tecnología.
Asegurar la Monitorear la Desarrolla y mantiene Medir la satisfacción del
satisfacción del satisfacción del relaciones con sus cliente por ticket de atención,
cliente. clientes
58
cliente no menor lograr una satisfacción no
al 95%. menor al 85%.
Diferenciarnos Mantener la Desarrolla y mantiene Monitorear el mercado sobre

poniendo valor a vigilancia relaciones con los el desarrollo de las tecnologías
la innovación en tecnológica y la proveedores y clientes. de información y las
productos, demanda del necesidades de nuestros
servicios y mercado. clientes.
procesos
2.1.4 Procesos de gestión de proyectos

Los procesos de gestión de proyectos que se realizan en la empresa se pueden agrupar en cinco
fases o macro procesos: Iniciación, planificación, ejecución, seguimiento y control, y cierre. La
caracterización de los procesos mencionados se encuentra desde la Tabla 24 hasta la Tabla 28,
donde se puede identificar el objetivo del proceso, las actividades, los insumos para que se lleve a
cabo el proceso y las salidas o productos finales del proceso. Para ver el diagrama de los procesos
revisar el Anexo 1.
Tabla 24: Caracterización del proceso de Iniciación

Iniciación
Descripción Proceso que a partir de una necesidad del cliente, realiza las estimaciones
de capacidad y presupuesto para poder elaborar el Acta de Constitución
del Proyecto o Project Charter.
Objetivo Aprobar el Project Charter del proyecto
Entradas Necesidad y requerimiento del cliente.
Actividades 1. Cliente envía necesidad y requerimiento.

2. Elaborar formato de requerimiento.
3. Revisar análisis de capacidad para asignar un Jefe de Proyecto o
Analista de Sistemas.
59
4. Realizar estimación de horas y del presupuesto.
5. Elaborar Project Charter.
6. Revisar estimaciones del Project Charter.
7. Ajustar estimaciones del Project Charter.
8. Revisar y aprobar el Project Charter con Jefe de Desarrollo y Jefe de
Proyecto o Analista de Sistemas.
Salidas Project Charter aprobado
Indicadores Porcentaje de proyectos que termina la fase con Project Charter aprobado.
Tabla 25: Caracterización del proceso de Planificación del Proyecto

Planificación del proyecto
Descripción Contempla las actividades necesarias para establecer el plan de proyectos.
Objetivo Generar el plan de proyecto con su respectiva línea base (Alcance, tiempo,
cronograma, presupuesto y calidad)
Entradas Project Charter aprobado.
Actividades 1. Asignar Jefe de Proyectos o Analista de Sistemas según cartera.

2. Elaborar planes de gestión: Requisitos, alcance, tiempo, costo,
comunicaciones, calidad. Además, de pedido de recursos y de
adquisiciones, en caso aplique.
3. Revisar y ajustar documentación del proyecto: Alcance,
requerimientos y calidad).
4. Elaborar la estructura de descomposición de trabajo (EDT).
5. Elaborar el cronograma.
6. Revisar y aprobar documentación: Requerimientos, EDT, presupuesto
y cronograma.
7. Comunicar el cronograma final al usuario líder y áreas implicadas.
8. Generar la línea base del proyecto.
Salidas Plan de proyecto con la línea base del proyecto aprobada.
Indicadores  Porcentaje de proyectos que cuenta con alcance definido.
60
 Porcentaje de proyectos que cuenta con un plan de proyectos.
 Porcentaje de proyectos que cuenta con cronograma aprobado antes de

la ejecución.
 Porcentaje de proyectos que tiene presupuesto aprobado antes de la

ejecución.
Tabla 26: Caracterización del proceso de Ejecución del Proyecto

Ejecución del proyecto
Descripción El proceso contempla las actividades para ejecutar el plan de proyecto

dentro de lo definido en el alcance, el cronograma y dentro de los costos
planificados.,
Objetivo Ejecutar el proyecto según lo planificado y realizar los controles de cambio

necesarios.
Entradas Plan de proyecto aprobado.
Actividades 1. Revisar plan de proyecto y actualizar informe de avance del

cronograma.
2. Revisar programación de recursos y generar hoja de programación
semanal de actividades.
3. Verificar asignación de los recursos según prioridades.
4. Revisar lista de actividades.
5. Realizar registro de horas y reportar avance en el sistema de gestión.
6. Generar reporte de horas y avance del proyecto.
7. Aprobar horas reportadas.
8. Realizar seguimiento al avance.
9. Actualizar cronograma, presupuesto y avance.
10. Actualizar plan y documentación del proyecto.
Salidas Documentación del proyecto actualizada.
61
Indicadores  Porcentaje de proyectos que siguen las actividades según lo
planificado.
 Porcentaje de proyectos que presenta el reporte diario de horas

invertidas.
Tabla 27: Caracterización del proceso de Seguimiento y Control

Seguimiento y control
Descripción Proceso por el cual se realiza el monitoreo del avance del proyecto,
asimismo, se identifican las desviaciones al plan de proyectos.
Objetivo Supervisar al seguimiento de los proyectos mediante la generación de

informes de estado y de horas invertidas para aprobación de la gerencia.
Entradas No tiene.
Actividades 1. Realizar informe semanal de avances del proyecto.

2. Revisar informe semanal de avance del proyecto.
3. Verificar estado del proyecto (alcance, tiempo, costo)
4. Realizar control de cambios.
5. Realizar re planificación de recursos.
6. Revisar retrasos y tomar acciones correctivas.
7. Generar informe de avances para la gerencia.
Salidas Informe mensual del estado del proyecto y horas para aprobación de la
gerencia.
Indicadores Porcentaje de proyectos que termina dentro de lo planificado.
Porcentaje de proyectos que realiza control de cambio.
62
Tabla 28: Caracterización del proceso de Cierre
Cierre
Descripción
Objetivo El proceso tiene objetivo validar la conformidad del usuario, además, de

liberar los recursos asignados al proyecto.
Entradas Documento de pase a producción.
Actividades 1. Informar conformidad del cierre.

2. Coordinar cierre del registro de horas del proyecto.
3. Confirmar conformidad del usuario.
4. Calcula métricas del proyecto y actualiza documento de lecciones
aprendidas.
5. Verificar que la documentación del proyecto se encuentra completa.
6. Realizar la publicación de documentación del usuario y actualiza
información para los stakeholders.
7. Elaborar informe final del proyecto.
8. Realizar seguimiento durante el período de estabilización.
9. Solicitar cierre de carpeta del proyecto.
10. Enviar al gestor de aplicaciones la documentación final del proyecto.
11. Realizar actualizaciones a la carpeta de cliente en caso aplique.
Salidas Carpeta actualiza del proyecto y del cliente.
Indicadores Porcentaje de proyectos cerrados formalmente.
Herramientas tecnológicas para la gestión de proyectos

Actualmente, el Departamento de Sistemas cuenta con tres herramientas tecnológicas para la
gestión de proyectos, siendo dos de ellas de uso gratuito y uno con licencia pagada. Lo cual indica
que dicho Departamento no ha realizado importantes inversiones en tecnología para la gestión de
proyectos.
63
Para las tareas relacionadas a la planificación del cronograma y del presupuesto, así como para
realizar el seguimiento y control del proyecto se utiliza el MSProject 2016. El Departamento de
Sistemas cuenta con 15 licencias pagadas que son utilizadas principalmente por la Oficina de
Gestión de Proyectos, Equipo del proyecto y Gerente del Departamento.
Para la gestión de los documentos del proyecto como, por ejemplo, el Project Charter y plan del
proyecto y planes de seguimiento se utiliza el Google Drive, dicha herramienta es gratuita y es
accedida con usuario genérico del Departamento de Sistemas, lo cual representa problemas de
seguridad e integridad de la información. Asimismo, para la administración de tareas del proyecto
y seguimiento de incidencias se utiliza la herramienta de software libre denominada Jira.
2.2 Problemática
El área de mejora seleccionada es el Departamento de Sistemas, porque dicha área no está
ejecutando sus procesos de manera eficiente, lo que se evidencia en pérdidas económicas. Para
identificar las principales problemáticas del Departamento, se recopiló la opinión de la Gerente
del Departamento de Sistemas, la Jefe de Desarrollo, el responsable de la Oficina de Proyectos y
un Jefe de Proyectos, quienes identificaron las siguientes problemáticas del área:
 Inadecuada gestión de proyectos con pérdidas en la facturación por aproximadamente 18% en

promedio en los últimos tres años.
 Alta rotación del personal, con un incremento del 5% en el último año.
 Inadecuada capacitación de los jefes de proyectos en gestión de proyectos. Sólo el 1% de los

jefes de proyecto cuenta con una certificación PMP.
Para seleccionar la problemática para la presente propuesta de tesis, se optó por identificar el
problema más relevante de los tres presentados, para lo cual se ha realizado una matriz de selección
de problemas, que se muestra en la Tabla 29. El nivel de relevancia de un problema se ha
ponderado en la matriz de evaluación con los siguientes criterios: i) Impacto sobre el cliente, ii)
Relación con los objetivos, iii) Necesidad de la mejora y iv) Disponibilidad de los recursos
necesarios. De la matriz presentada podemos concluir que la problemática más relevante es la
inadecuada gestión de proyectos por lo que será la oportunidad de mejora de la presente propuesta.
64
Tabla 29: Matriz de selección de la problemática
Problemas bajo evaluación Criterios de evaluación Total
Impacto Relación Necesidad Recursos
sobre el con los de la necesarios
cliente objetivos mejora
Inadecuada gestión de 5 5 5 1 16
proyectos con pérdidas en la
facturación por
aproximadamente 18% en
los últimos tres años.
Alta rotación del personal, 2 1 2 2 7

con un incremento del 5% en
el último año.
Inadecuada capacitación de 1 2 2 5 10
los jefes de proyectos en
gestión de proyectos. Sólo el
1% de los jefes de proyecto
cuenta con una certificación
PMP.
Nota. Se ha considerado la siguiente ponderación para los criterios de evaluación: Escala: 0 =

Nada, 1 = Poco, 2 = Regular, 5 = Mucho.
Con la problemática seleccionada se realizará el análisis cuantitativo, que implica una evaluación
en términos monetarios del problema, para poder entender su impacto económico en la
organización. Finalmente, se realizará el análisis cualitativo del problema en la cual se
identificarán las posibles causas y se seleccionará las más significativas con un diagrama de Pareto.
65
2.2.1 Análisis cuantitativo
En el informe ejecutivo se reportaron los indicadores para cada etapa del proceso de gestión de
proyectos. En la Tabla 30 se muestran los resultados obtenidos con su respectivo semáforo, de
color verde se encuentran los indicadores con un valor mayor o igual al 70% y en rojo en caso
contrario.
Tabla 30: Indicadores de la gestión de proyectos por fase.

Proceso Indicadores Semáforo
Iniciación El 91% de los proyectos cuenta con un acta oficial de

inicio del proyecto, denominado Acta de Constitución o
Project Charter.
Planificación El 91% de los proyectos tiene alcance definido. El 9%

faltante, estaban asociados a proyectos de baja
envergadura.
El 55% de los proyectos inicia con un plan de proyecto

aprobado.
El 89% de los proyectos cuenta con un cronograma

aprobado antes del inicio de la ejecución del proyecto.
El 89% de los proyectos se ejecuta con presupuesto

aprobado antes del inicio de la ejecución del proyecto.
Sólo el 11% de los proyectos identifica riesgos pero no

existe planificación para su gestión.
Ejecución El 65% de los proyectos ejecuta las tareas según lo

planificado.
El 62% de los proyectos presenta el reporte diario de horas

invertidas.
Seguimiento y Ninguno de los proyectos realiza control de riesgos.

control
Ninguno de los proyectos realiza gestión de cambios.
66
El 55% de los proyectos termina según lo planificado en
el presupuesto y el cronograma.
Cierre Ninguno de los proyectos realiza el cierre formal de los

proyectos.
Por lo tanto, de los indicadores se identifican brechas a cubrir en los procesos de gestión de
proyectos que se encuentran ilustrados en la Figura 7, donde se puede apreciar los retos asociados
a los procesos de gestión de proyectos de la empresa.
Figura 7: Brechas a cubrir en gestión de proyectos.
Superar estas brechas en gestión de proyectos es importante porque están generando pérdidas
económicas a la empresa, esto se explica porque el monto de facturación por el concepto de
desarrollo de proyectos se calcula utilizando la técnica del Valor Ganado, el cual “representa la
cantidad del presupuesto total del proyecto que ha sido ganado basado en el porcentaje del trabajo
que ha sido realizado” (Gallegos, 2018, p.47), es decir la facturación se realiza considerando el
avance del presupuesto en un momento dado y no con el costo real del esfuerzo invertido en el
proyecto.
Por lo tanto, al no tener una adecuada gestión de proyectos los costos incurridos al finalizar el
proyecto superan ampliamente lo presupuestado inicialmente. En la Figura 7, se muestra las
67
diferencias, de los últimos tres años, entre la facturación (valor ganado) y el costo real de los
proyectos; donde el monto de facturación fue calculado automáticamente por la herramienta usada
para la gestión de proyectos: MS Project, mientras que el costo real fue obtenido por un sistema
interno de la empresa, en el cual se registran las horas reales invertidas en las tareas de los
proyectos.
Figura 8: Facturación Vs. Costo Real (Años: 2015, 2016 y 2017)

Las barras azules corresponden al monto facturado anual a los clientes por concepto de proyectos
de desarrollo de software mientras que las barras celestes corresponden a los costos reales anuales
incurridos en los proyectos de desarrollo de software.
En conclusión, al hacer una comparación entre el monto facturado y los costos reales se revela una
varianza negativa, esta diferencia “significa que el proyecto está fallando en cumplir con su costo
objetivo y está superando su presupuesto base.” (Gallegos, 2018, p.48). Esta varianza se muestra
en la Tabla 31 donde se evidencia que las pérdidas en facturación en los últimos tres años
ascienden a US$ 506,044 que en promedio representa un total de US$ 168,681. Además, se
identifica que el porcentaje de pérdida viene creciendo en un promedio del 18% y a un ritmo del
2%, lo que implica que de no tomar acciones correctivas para mejorar los procesos de gestión de
68
proyectos probablemente para el año 2018 la empresa tendrá que afrontar pérdidas por un 22% en
la facturación por proyectos de desarrollo de software.
Tabla 31: Resumen de pérdidas en facturación

Diferencia entre la
Año % de pérdida
facturación y el costo real
2015 US$ 148, 626 16%
2016 US$ 142, 172 18%
2017 US$ 215, 246 20%
Total tres años US$ 506,044 -
Promedio tres años US$ 168,681 18%
2.2.2 Análisis cualitativo

Para poder identificar las posibles causas a la problemática de una inadecuada gestión de proyectos
en la empresa consultora, se realizaron reuniones de lluvia de ideas con participación del equipo
de proyectos del Departamento de Sistemas, las cuales están mapeadas en la Figura 9 en un
diagrama de Ishikawa o Espina de Pescado. Las causas identificadas son:
 Personas:
- Incapacidad del Jefe de Proyecto (JP): consideran que existe inexperiencia de los jefes de
proyecto que tienen perfil de desarrolladores y que no cuentan con las habilidades
necesarias para la gestión de proyectos.
- Falta de capacitación: en relación al punto anterior, consideran que se requiere

capacitaciones en habilidades blandas, en fundamentos de gestión de proyectos y en
herramientas para mejorar la gestión de proyectos.
69
- Disponibilidad de recursos: al no contar con los recursos necesarios muchas veces un jefe
de proyectos tiene que realizar las actividades de un analista y/o desarrollador, lo cual
genera sobrecarga de los recursos disponibles que impacta en los tiempos de cronograma.
- Alta rotación: debido a la alta rotación de personal en la empresa, principalmente de jefes

de proyectos, se generan retrasos cuando ingresa un nuevo recurso por el tiempo que
demanda capacitarlo en los proyectos, muchas veces es auto aprendizaje porque no se tiene
toda la documentación de los proyectos.
 Tiempo:
- Mala estimación: se considera que los tiempos considerados al momento de realizar la

planificación del proyecto no son realistas pues no consideran variables que pueden
impactar el proyecto, como los tiempos de los usuarios o las asignaciones de los recursos
a otros proyectos.
 Procesos:
- Mala definición de requisitos: el levantamiento de información de las necesidades de los

usuarios no se realiza correctamente y se realizan asunciones de los requerimientos del
usuario, lo cual genera que cuando se está en la fase de pruebas el producto es regresado a
la fase de desarrollo porque no cumple con los requerimientos del usuario.
- Inadecuada planificación: en el proceso de planificación los jefes de proyectos realizan los

planes según su experiencia y no utilizan ninguna herramienta, método o documentación
de proyectos anteriores para el análisis de los costos y tiempo. Además, no se realiza la
planificación de riesgos de los proyectos y cuando se presenta una situación no
contemplada se generan retrasos por no tener un plan de respuesta.
- Falta de seguimiento y control: los informes de seguimiento muchas veces son realizados
sin la debida rigurosidad, lo cual no permite identificar a tiempo desviaciones a lo
planificado y por lo tanto las acciones correctivas muchas veces terminan en solicitudes de
cambio cuyo costo no está contemplado.
70
 Herramientas
- Herramientas de gestión inadecuadas: como se mencionó anteriormente la empresa sólo

utiliza el MSProject para la gestión de proyectos y JIRA para la gestión de incidencias del
proyecto, herramientas que no permiten realizar seguimiento ni contar con documentación
asociada a los proyectos, lo cual se requiere para agilizar las actividades de gestión de
proyectos.
Figura 9: Diagrama causa-efecto de inadecuada gestión de proyectos
Luego, para poder determinar las causas principales que nos permitirán solucionar la problemática
planteada, se realizaron encuestas en el área para poder identificar las causas más relevantes
mediante un análisis de Pareto, tal como se muestra en la Figura 10.
71
Figura 10: Análisis de Pareto para identificar las causas más relevantes
2.2.3 Conclusiones del análisis de la problemática

Se evidencia que el Departamento de Sistemas está teniendo pérdidas económicas por diferencias
entre los montos que factura a sus clientes y los montos reales incurridos en la ejecución de sus
proyectos, lo cual revela que existe una inadecuada gestión de proyectos por tener procesos que
no están cumpliendo los indicadores metas del área.
Asimismo, es importante mencionar que la problemática planteada es relevante no sólo para el

Departamento de Sistemas sino para la empresa en general debido a que está impactando a los
objetivos estratégicos, tal como se muestra en la Tabla 32, donde se muestra el impacto del
problema en la organización.
72
Tabla 32: Impacto de la problemática en los objetivos estratégicos
Problema Indicador del Objetivo Estratégico del Objetivo Estratégico
Departamento de Departamento de Sistemas de la Organización
Sistemas
Inadecuada Indicadores de tiempo Alcanzar la eficiencia en los Aumentar el EBITDA

gestión de y costo de proyectos procesos. en un 12.5% anual
proyectos no menores al 95% para los años del 2014
al 2018.
Ante esta situación problemática se propone realizar la mejora de los procesos de gestión de
proyectos bajo el modelo de madurez propuesto por CMMI-DEV v1.3, el cual es elegido frente a
las ISO y otros modelos por los siguientes motivos:
 Según la investigación realizada de las normas y modelos de calidad de procesos de desarrollo

de software, CMMI-DEV brinda un modelo que se adapta a los procesos desarrollados para la
gestión de proyectos en el Departamento de Sistemas por ser un modelo especializado en la
industria de software, además brinda las pautas para alcanzar niveles incrementales de madurez
en los procesos.
 Se tiene evidencia de que este modelo ayuda a las organizaciones que lo implementan en la
reducción de costos y tiempo, así como en el incremento de la calidad y la satisfacción del
cliente; beneficios que figuran como brechas a cubrir en los procesos de gestión de proyectos.
 El modelo CMMI-DEV es el que mejor acompaña los planes de crecimiento de la empresa, ya

que es ampliamente reconocido en los Estados Unidos. Además, teniendo en consideración las
intenciones de la empresa de incursionar en nuevos mercados, será indispensable contar con
un modelo de clase mundial que garantice la calidad de procesos de desarrollo de software.
73
CAPÍTULO 3: PROPUESTA
En este capítulo se presentan las acciones necesarias para poner en marcha la implantación de la
mejora de procesos basados en el modelo de CMMI-DEV, desde su concepción hasta la
elaboración del plan de proyecto, para lo cual se utilizará el marco para proyectos de mejora de
procesos denominado IDEAL. Finalmente, se realiza la evaluación económica de la propuesta.
3.1 Implantación de CMMI basada en el marco IDEAL

Se propone que la implantación de modelo CMMI se realice considerando las fases propuestas por
el modelo IDEAL por ser un marco propicio para el desarrollo de proyectos de mejora de procesos,
según se detalla en la Figura 11:
Figura 11: Fases de la elaboración de la propuesta de mejora.
74
3.1.1 Iniciar
3.1.1.1 Necesidad del cambio

Se reconoce la necesidad de realizar cambios en los procesos del Departamento de Sistemas debido
a que se ha identificado que la problemática de inadecuada gestión de proyectos ha venido
impactando con pérdidas en la facturación por US$168,681, en promedio en los últimos tres años.
Esta situación, tiene repercusiones directas al objetivo estratégico del Departamento de Sistemas
de alcanzar la eficiencia operativa, el cual, también impacta en el objetivo organizacional de
incrementar el EBITDA en un 12.5% anual.
3.1.1.2 Alcance
El alcance contempla los procesos del área de Desarrollo de Software del Departamento de
Sistemas que están asociados a los procesos del nivel de madurez 2 del modelo CMMI-DEV, los
cuales han sido identificados en la Tabla 33 donde se muestra el mapeo de los procesos del área
de Desarrollo de Software con los considerados por el modelo CMMI-DEV.
Tabla 33: Mapeo de los procesos de CMMI-DEV con los procesos de la empresa
Proceso Área de Desarrollo de Software Proceso CMMI-DEV nivel 2
Seguimiento y control de proyectos Monitorización y control del proyecto (PMC)
Planificación de proyectos Planificación del proyecto (PP)
Gestión de requerimientos Gestión de requisitos (REQM)
Gestión de proveedores Gestión de acuerdos con proveedores (SAM)
Control de cambios Gestión de la configuración (CM)
Medición de proyectos Medición y análisis (MA)
Proceso de control de calidad del producto Aseguramiento de la calidad del proceso y del
producto (PPQA)
75
3.1.1.3 Objetivo general
La presente propuesta de mejora tiene como objetivo general ahorro en costos reduciendo en un
20% las pérdidas en facturación (US$ 168,68) desde el primer año, con mejoras anuales hasta
alcanzar una eficiencia sostenible.
3.1.1.4 Objetivos específicos
 Establecer una estructura que permita gestionar el proceso de mejora y asegurar la correcta
ejecución de los nuevos procesos, así como promover próximas iniciativas de mejora.
 Implementar de manera iterativa los procesos de mejora, mediante la ejecución de proyectos

pilotos para asegurar la correcta ejecución y beneficio de los nuevos procesos.
 Elaborar el manual de procesos basados en el modelo de CMMI-DEV para aquellos procesos

que requieran de mejoras.
3.1.1.5 Estructura del equipo de mejora continua

Se propone que la estructura del proyecto de mejora esté conformada por tres equipos: i) el equipo
directivo de gestión, ii) el equipo de procesos de ingeniería y iii) el equipo técnico. Las
responsabilidades para cada equipo se muestran en la Tabla 34.
Tabla 34: Estructura del equipo de mejora

Equipo Responsabilidades
Directivo de Gestión Alinear los objetivos del proyecto de mejora con las necesidades del negocio,
demostrar patrocinio al proyecto de mejora de procesos, asignar recursos y
proporcionar orientación durante el monitoreo y proponiendo acciones
correctivas.
Procesos de Asegurar la coordinación del esfuerzo del proyecto de mejora en toda la

Ingeniería organización, brindar capacitación y realizar evaluaciones del proyecto de
mejora.
Técnico (equipo de Acompañar y ejecutar las acciones de mejora de los procesos.
proyectos)
76
Asimismo, para asegurar la mejora continua en los procesos de la organización se propone la
creación de un área especialista en calidad y mejora de procesos de software cuya función principal
será asegurar que los proyectos que se ejecuten para la Unidad de Tecnologías de Información
cumplan con lo especificado en los manuales de procesos. Esta área deberá realizar seguimiento
constante para detectar desviaciones que afecten el logro de los objetivos de los procesos, además,
debido a la importancia que tiene para asegurar la consecución de los objetivos estratégicos se ha
considerado que deberá ser un área de apoyo a la Gerencia General, tal como se muestra en la
Figura 12.
Figura 12: Organigrama propuesto para la mejora de procesos
3.1.2 Diagnosticar
3.1.2.1 Objetivo del diagnóstico inicial

El objetivo del diagnóstico inicial es reflejar el nivel de adherencia de los procesos de la empresa
a las prácticas y metas de las áreas de proceso del nivel de madurez 2 del modelo CMMI- DEV.
Como resultado del diagnóstico se identifican las fortalezas y oportunidades de mejora de los
77
procesos considerados en el alcance. Las oportunidades de mejora serán las brechas a cubrir por
los procesos ejecutados por la empresa.
3.1.2.2 Proceso de evaluación basado en SCAMPI

La evaluación realizada no es una evaluación SCAMPI propiamente, sin embargo, se considera
que está basada en SCAMPI porque tiene aspectos muy asociados a una evaluación SCAMPI de
clase C, ya que ha sido realizada por un equipo pequeño con conocimientos del modelo de CMMI-
DEV, pero no certificado; otro aspecto es que sólo se ha considerado como evidencia objetiva las
afirmaciones recolectadas de encuestas realizadas al personal involucrado en los procesos
evaluados. El formato de las encuestas realizadas se encuentra en el Anexo 2.
El proceso de evaluación inició con la definición de los siguientes parámetros de número de

personas y proyectos seleccionados para realizar las encuestas:
 Número de personas: las encuestas fueron tomadas a un número significativo de trabajadores

con participación en proyectos de desarrollo de software. Para poder determinar la muestra
significativa se utilizó la fórmula de la Figura 13 para el cálculo del tamaño de la muestra
conociendo el tamaño de la población.
Figura 13: Cálculo del tamaño de la muestra.

Realizado con información de: http://normasapa.net/formula-muestra-población/
Donde:
- N: 26, es el tamaño de la población. Del total de colaboradores del Departamento de

Sistemas se han retirado a los cuatro administradores de red.
- Z: 1.65, es el nivel de confianza utilizado al 90%
78
- p: 0.5, probabilidad de éxito.
- q: 1-0.5, probabilidad de fracaso.
- e: 0.05, error muestral.
Por lo tanto, el tamaño de la muestra (n) o número de personas a las que se les realizó la encuesta
fue de 23.
 Proyectos evaluados: en el diagnóstico inicial se ha considerado como muestra a cuatros

proyectos de la empresa con diferentes características los cuales se encuentran descritas en la
Tabla 35.
Tabla 35: Proyectos considerados en la evaluación

Proyecto Descripción
UN-508- Creación de portal Proyecto para cliente.
VENDEMAX Estado: en curso. Iniciado en julio del año 2017.
Duración: 10 meses
BA-430 - Seguridad de Proyecto para cliente.
información de producción Estado: en curso. Iniciado en febrero del año 2018.
Duración: 3 meses
UN408 - Facturación electrónica Proyecto para cliente.
– Paperless Estado: terminado. Iniciado en mayo del año 2017
Duración: 11 meses.
AR108 - Rediseño integración Proyecto interno
GLAB SPRING Estado: en curso. Iniciado en octubre del año 2017.
Duración: 7 meses.
Luego, de la definición de los parámetros mencionados, se tomaron las encuestas para

posteriormente realizar la consolidación y cálculo de los porcentajes de adherencia de los procesos
de la empresa a las prácticas específicas y genéricas del modelo CMMI-DEV. El detalle de los
resultados obtenidos se encuentra en el Anexo 3 y finalmente, se realizó la evaluación de los
procesos, en la cual se identificaron fortalezas y oportunidades de mejora.
79
Los criterios considerados para la evaluación fueron:
 Rangos para evaluar el nivel de adherencia de las prácticas específicas y genéricas: se utilizó
los rangos definidos por la ISO 15504, según se muestra en la Tabla 36.
Tabla 36: Rango de evaluación de las prácticas usando la ISO15504

Nivel Indicador Rango según ISO 15504
No logrado (N) 0% al 15%
Parcialmente logrado (P) 16% al 50%
Largamente logrado (L) 51% al 85%
Totalmente logrado (F) 86% al 100%
 Nivel de cumplimiento de las metas específicas y genéricas: se considera los criterios de la

Tabla 37 donde se indica que una meta se cumple si tiene todas sus prácticas están en un nivel
de largamente logrado y/o totalmente logrado; en contraste, si una práctica o varias están
parcialmente logradas o no logradas la meta no se cumple.
Tabla 37: Rango de evaluación de las metas

Nivel Indicador Criterio
Cumple Todas sus prácticas están ampliamente logradas o

totalmente logradas.
No se cumple Una o más prácticas están parcialmente logradas o no

logradas.
Asimismo, para el proceso de evaluación se utilizó como herramienta de apoyo el software

Appraisal Assistant Beta, desarrollado por Software Quality Institute de la universidad de Griffith
80
de Australia, esta herramienta fue utilizada principalmente para tener vistas generales gráficas de
los resultados obtenidos.
3.1.2.3 Situación actual

En esta sección se presentan los resultados del nivel de adherencia únicamente de los procesos del
área de gestión de proyectos a las prácticas establecidas por CMMI-DEV, por estar asociadas a la
problemática identificada de inadecuada gestión de proyectos. Sin embargo, se puede consultar el
Anexo 3, si se desea revisar el detalle de los resultados obtenidos, indicando fortalezas y
oportunidades de mejora, de todos los procesos del nivel de madurez 2 así como el resumen de
evaluación de dichos procesos.
3.1.2.3.1 Gestión de requisitos (REQM)

De la evaluación realizada a las prácticas específicas y genéricas del proceso de gestión de
requisitos se concluye que no se satisface las metas del proceso, debido a que existen prácticas, en
su mayoría específicas, que sólo se cumplen parcialmente. Lo mencionado anteriormente se refleja
en la Tabla 38 donde se muestra el nivel de cumplimiento de las metas y prácticas específicas, así
como el cumplimiento de las metas genéricas, además en la Figura 14 se muestra el nivel de
adherencia general del proceso y en la Figura 15 el nivel de implementación asociadas a las
prácticas específicas y el nivel de institucionalización asociada a la práctica genérica.
Tabla 38: Resultado de la evaluación del proceso REQM

PA METAS PRACTICAS
SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 1.5
SG1
23,69 36,32 31,58 29,47 31,58
REQM
GP 2.1 GP 2.2 GP 2.3 GP 2.4 GP 2.5 GP 2.6 GP 2.7 GP 2.8 GP 2.9 GP 2.10
GG2
60 60 60 60 60 60 60 60 47,37 47,37
Nota. SG: Metas específicas, GG: Metas genéricas, SP: prácticas específicas y GP : prácticas
genéricas.
81
Figura 14: Caracterización de las prácticas de REQM
Figura 15: Nivel de implementación e institucionalización de REQM
3.1.2.3.2 Planificación del proyecto (PP)

De la evaluación realizada a las prácticas específicas y genéricas del proceso de planificación de
proyectos se concluye que no se satisface las metas del proceso, aunque la mayoría de prácticas se
cumplen largamente, un porcentaje bastante amplio solo se cumple parcialmente. Lo mencionado
anteriormente se refleja en la Tabla 39 donde se muestra el nivel de cumplimiento de las metas y
82
prácticas específicas, así como el cumplimiento de las metas genéricas, además en la Figura 16 se
muestra el nivel de adherencia general del proceso y en la Figura 17 el nivel de implementación
asociadas a las prácticas específicas y el nivel de institucionalización asociada a la práctica
genérica.
Tabla 39: Resultado de la evaluación del proceso PP

PA METAS PRACTICAS
SP 1.1 SP 1.2 SP 1.3 SP 1.4
SG1
40,26 56,84 56,84 13,68
SP 2.1 SP 2.2 SP 2.3 SP 2.4 SP 2.5 SP 2.6 SP 2.7
SG2
15,27 52,90 34,73 45,47 48,95 37,89 60,00
PP
SP 3.1 SP 3.2 SP 3.3
SG3
44,21 12,63 13,26
GG2
31,58 56,84 56,84 56,84 53,68 53,68 56,84 37,89 56,84 37,89
genéricas.
Figura 16: Caracterización de las prácticas de PP
83
Figura 17: Nivel de implementación e institucionalización de PP
3.1.2.3.3 Monitorización y control del proyecto (PMC)

De la evaluación realizada a las prácticas específicas y genéricas del proceso de seguimiento y
control de proyectos se concluye que no se satisface las metas del proceso debido a la que la
mayoría de prácticas sólo se cumplen parcialmente. Lo mencionado anteriormente se refleja en la
Tabla 40 donde se muestra el nivel de cumplimiento de las metas y prácticas específicas, así como
el cumplimiento de las metas genéricas, además en la Figura 18 se muestra el nivel de adherencia
general del proceso y en la Figura 19 el nivel de implementación asociadas a las prácticas
específicas y el nivel de institucionalización asociada a la práctica genérica.
Tabla 40: Resultado de la evaluación del proceso PMC

PA METAS PRACTICAS
SP 1.1 SP 1.2 SP 1.3 SP 1.4 SP 1.5 SP 1.6 SP 1.7
SG1
34,73 25,26 6,32 2,11 17,89 26,84 14,53
SP 2.1 SP 2.2 SP 2.3
PMC SG2
23,69 25,26 23,16
GG2
44,21 44,21 44,21 44,21 44,21 44,21 44,21 41,05 44,21 53,68
genéricas.
84
Figura 18: Caracterización de las prácticas de PMC
Figura 19: Nivel de implementación e institucionalización de PMC
85
3.1.2.3.4 Gestión de acuerdos con proveedores (SAM)
De la evaluación realizada a las prácticas específicas y genéricas del proceso de gestión de
acuerdos con proveedores se concluye que se satisface las metas específicas del proceso, sin
embargo, existen oportunidades de mejora necesarias en la institucionalización del proceso. Lo
mencionado anteriormente se refleja en la Tabla 41 donde se muestra el nivel de cumplimiento de
las metas y prácticas específicas, así como el cumplimiento de las metas genéricas, además en la
Figura 20 se muestra el nivel de adherencia general del proceso y en la Figura 21 el nivel de
implementación asociadas a las prácticas específicas y el nivel de institucionalización asociada a
la práctica genérica.
Tabla 41: Resultado de la evaluación del proceso SAM

METAS PRACTICAS
SP 1.1 SP 1.2 SP 1.3
SG1
58,40 62,31 59,89
SP 2.1 SP 2.2 SP 2.3
SG2
62,31 61,43 62,05
GG2
34,62 34,62 34,62 34,62 34,62 34,62 46,15 46,15 36,92 36,92
genéricas.
Figura 20: Caracterización de las prácticas de SAM
86
Figura 21: Nivel de implementación e institucionalización de SAM
3.1.2.4 Situación optimada

En la Tabla 42 se muestra el resumen de la evaluación realizada a los procesos de gestión de
proyectos, como se puede apreciar existen varias metas de los procesos que no se llegan a cumplir,
por lo tanto, se proponen las siguientes mejoras en los procesos de gestión de proyectos:
 Mejorar el proceso de gestión de requisitos para asegurar que sus prácticas se cumplen
largamente.
 En el proceso de planificación de proyectos eliminar el 15.38% de prácticas no logradas e

incrementar el número de prácticas logradas largamente.
 En el proceso de monitorización y control de proyectos eliminar el 15% de prácticas no

logradas e incrementar el número de prácticas logradas largamente.
 En el proceso de gestión de acuerdos con proveedores incrementar el número de prácticas que

se cumplen largamente.
 Asegurar la institucionalización de los procesos de gestión de proyectos.
87
Tabla 42: Resumen de cumplimiento de metas
Proceso Meta Cumplimiento
Gestión de SG1. Gestionar los requisitos No cumple

requisitos
GG 2 Institucionalizar un proceso gestionado No cumple
Planificación de SG1. Establecer las estimaciones No cumple

proyectos
SG2. Desarrollar un plan de proyecto No cumple
SG3. Obtener el compromiso con el plan No cumple
Seguimiento y SG1. Monitorear el proyecto frente al plan No cumple

control de
SG2. Gestionar las acciones correctivas hasta su No cumple
proyectos
cierre
Gestión de SG1. Establecer acuerdos con proveedores Cumple

acuerdos con
SG2. Satisfacer los acuerdos con los proveedores Cumple
proveedores
3.1.3 Establecer
3.1.3.1 Prioridades de la implantación

En el diagnóstico inicial se identificaron brechas a cubrir en varios de los procesos de gestión de
proyectos. Sin embargo, se establece como prioritarios por su impacto en el problema los
siguientes:
88
 Gestión de requisitos
 Planificación de proyectos
 Seguimiento y control de proyectos
3.1.3.2 Diseño de nuevos procesos

Para asegurar el cumplimiento de las prácticas genéricas, se propone incluir en el manual de
procesos, secciones que sirvan como evidencia objetiva, según se detalla en la Tabla 43.
Tabla 43: Propuesta de definición de prácticas genéricas

Práctica genérica Manual de procesos
GP2.1 Establecer una política de la Sección Políticas del Manual de Procesos (Ver
organización Anexo 7)
GP2.2 Planificar el proceso Sección Caracterización del Manual de

Procesos – Actividades de planificación (Ver
Anexo 7)
GP2.3 Proporcionar recursos Sección Recursos del proyecto del Manual de

Procesos (Ver Anexo 7)
GP2.4 Asignar responsabilidad Sección Caracterización del Manual de

Procesos – Responsable (Ver Anexo 7)
GP2.5 Formar al personal Recursos del proyecto
GP2.6 Controlar los productos de trabajo Sección Gestión de la configuración del

Manual de Procesos (Ver Anexo 7)
GP2.7 Identificar e involucrar a las partes Sección Interesados del Manual de Procesos
interesadas (Ver Anexo 7)
89
GP2.8 Monitorizar y controlar el proceso Sección Caracterización del Manual de
Procesos – Indicadores del proceso (Ver
Anexo 7)
GP2.9 Evaluar objetivamente la adherencia Sección Auditorías del Manual de Procesos

(Ver Anexo 7)
GP2.10 Revisar el estado con el nivel directivo Sección Auditorías del Manual de Procesos
(Ver Anexo 7)
Para asegurar el cumplimiento de las prácticas específicas se ha realizado el rediseño de los

procesos. El diseño contempla la caracterización del proceso identificando actividades, métricas,
indicadores, plantillas de ser necesario, así como el diagrama del nuevo proceso propuesto.
3.1.3.2.1 Gestión de requisitos

Tabla 44: Caracterización del proceso gestión de requisitos
Objetivo del Revisar los requerimientos solicitados por el usuario (cliente), indicando
proceso su factibilidad y proporcionar las correspondientes observaciones técnicas
y su impacto en el negocio. Incrementar la eficiencia en la gestión de
proyectos al proporcionar los lineamientos correspondientes que
asegurará reducir en forma considerable los re-trabajos y su consecuencia
en los costos asociados.
Actividades de  Se debe garantizar la disponibilidad de los usuarios claves y de los
planificación recursos necesarios para realizar el levantamiento de requisitos.
 Se debe garantizar el respaldo de la Gerencia del usuario solicitante.
 Los responsables de las actividades del proceso deberán leer y
comprender el manual de proceso y las plantillas requeridas
Actividad Tareas Responsable Plantilla Práctica
CMMI-
DEV
90
Analizar lista de Recibir lista de Jefe de - SP 1.1
requerimientos requerimientos por parte Proyecto
de los usuarios.
Realizar revisión
preliminar de los
requerimientos.
Identificar Identificar los Jefe de - SP 1.1
problemas, problemas que se Proyecto SP 1.5
necesidades y desprenden a partir de
características los requerimientos de
usuario.
Identificar las
necesidades de los
usuarios a partir de los
problemas
identificados.
Identificar las
características de la
solución a partir de las
necesidades de los
usuarios identificadas.
Describir los
requerimientos
funcionales y no
funcionales para abordar
las características de la
solución.
Elaborar Matriz de Identificar dependencias Jefe de Matriz de SP 1.4
Trazabilidad entre los requerimientos Proyecto trazabilidad de
analizados. requisitos (ver
Anexo 4.1)
91
Elaborar Documento Consolidar el listado de Jefe de Plantilla – SP 1.5
de Especificación de problemas, de las proyecto Especificación
Requerimientos necesidades, los de
problemas y los Requerimientos
requerimientos (ver Anexo 4.2)
funcionales y no
funcionales.
Detallar a alto nivel los
requerimientos
funcionales
Realizar inducción Presentar al analista de Jefe de - SP 1.2
de requerimientos calidad los proyecto SP 1.3
requerimientos
analizados
Revisar documento Presentar al usuario Analista de - SP 1.2
de requisitos líder el resultado del Calidad SP 1.3
análisis de los Usuario
requerimientos. Líder
Indicadores del proceso
Indicadores de seguimiento de requisitos y Indicadores de gestión de cambios.
su trazabilidad.
92
Figura 22: Proceso propuesto de gestión de requisitos
3.1.3.2.2 Planificación del proyecto

Tabla 45: Caracterización del proceso planificación del proyecto
Objetivo del Elaborar el plan de proyecto con la finalidad de asegurar la calidad e
proceso integridad de las aplicaciones nuevas o actualizadas que son desarrolladas
por el área de Desarrollo.
93
Actividades de  El Administrador del Proyecto debe designar al Jefe de Proyectos.
planificación  Se debe asegurar los accesos a la carpeta del proyecto al Jefe de
Proyecto.
comprender el manual de proceso y las plantillas requeridas.
CMMI-
DEV
Crear repositorio de Crear repositorio para el Administrador Estructura SP 2.3
proyecto almacenamiento de los de Proyectos base para la
artefactos del proyecto creación de
repositorios
de
proyectos
Elaborar el Plan de Definir el proceso para la Jefe de Plantilla SP 2.7
Gestión del elaboración del enunciado Proyecto para el plan
Alcance del proyecto. de gestión
Definir el proceso para la de alcance
creación y aprobación del (ver Anexo
EDT. 5.1)
Definir el proceso para la
obtención de la aceptación
de los entregables
terminados.
Definir el proceso para
controlar las solicitudes de
cambio.
Elaborar el Plan de Definir la planificación, la Jefe de Plantilla SP 2.7
Gestión de monitorización y el Proyecto para el plan
Requisitos reporte de las actividades de gestión
asociadas a los requisitos.
94
Definir los procesos para de
ejecutar las solicitudes de requisitos
cambio en los requisitos. (ver Anexo
Definir los criterios para la 5.2)
priorización de requisitos.
Definir las métricas con
las que se medirá el
producto.
Elaborar el Describir el alcance del Jefe de Plantilla - SP 1.1
Enunciado del producto. Proyecto Enunciado
Proyecto / Alcance Indicar los criterios de del alcance
aceptación de los (ver Anexo
entregables. 5.3)
Indicar los entregables del
proyecto.
Indicar las exclusiones,
restricciones y los
supuestos a considerar en
el proyecto.
Elaborar EDT Identificar y agrupar los Jefe de Formato de SP 1.1
entregables para el Proyecto EDT (ver SP 1.3
proyecto Anexo 5.4)
Generar estimación Estimar las horas para el Jefe de Formato de SP 1.2
de horas (gestión y desarrollo del producto. Proyecto Estimación SP 1.4
producto) Estimar las horas de de Horas
gestión del proyecto. (PERT) (ver
Anexo 5.5)
Generar estimación Estimar las horas para la Analista de Formato de SP 1.2
de horas de pruebas ejecución de las pruebas Calidad Estimación
de control de calidad. de Horas
95
(PERT) (ver
Anexo 5.5)
Analizar Revisar cuadro de Administrador - SP 1.2
disponibilidad de disponibilidad de recursos de Proyectos SP 1.4
recursos para identificar fechas de
liberación o disminución
de carga
Asignar personal al Asignar al equipo de Administrador - SP 2.4
proyecto proyecto según las de Proyectos SP 2.5
funciones requeridas en el SP 3.1
plan y en función al SP 3.2
cuadro de disponibilidad.
Elaborar Generar listado de Jefe de Plantilla de SP 1.2
cronograma actividades a partir del Proyecto Cronograma SP 1.4
EDT (ver Anexo
Secuenciar las 5.6)
actividades.
Asignar recursos a las
actividades.
Asignar el esfuerzo a cada
actividad por recurso.
Revisar Verificar si los Analista de - SP 3.3
Cronograma entregables y fechas de Calidad
entrega corresponden a lo Usuario Líder
acordado
Elaborar planes de Elaborar el plan de gestión Jefe de Plantilla - SP 1.1
gestión de tiempo. Proyecto Plan de SP 1.2
Elaborar el plan de gestión proyecto SP 1.3
de costos. (ver Anexo SP 1.4
Elaborar el plan de gestión 5.7) SP 2.1
de calidad SP 2.2
96
Elaborar el plan de gestión SP 2.3
de comunicaciones SP 2.4
de riesgos. SP 2.6
SP 2.7
SP 3.3
Generar el KICK- Presentar al usuario líder Jefe de Plantilla – SP 3.3
OFF del proyecto el plan de gestión de Proyecto Aceptación
alcance. de Proyecto
(KICK
OFF) (ver
Anexo 5.8)
Cantidad de ajuste a los cronogramas Cantidad de proyecto que tuvieron KICK-OFF
posterior a revisiones.
Cantidad de rechazos del Project Charter por
tema de costos.
97
Figura 23: Proceso propuesto de planificación de proyectos
98
3.1.3.2.3 Seguimiento y control del proyecto
Tabla 46: Caracterización del seguimiento y control del proyecto
Objetivo del Realizar el monitoreo y control de los parámetros del proyecto (atributos
proceso de los productos de trabajo y tareas; costes y esfuerzo; y tiempo), riesgos
y otros parámetros del proyecto (datos, compromisos e hitos) para
identificar problemas en el progreso del proyecto y poder tomar acciones
correctivas inmediatas.
Actividades de  El Jefe de proyecto deberá tener los accesos a los documentos
planificación necesarios para realizar el proceso.
CMMI-DEV
Monitorizar el plan Revisar los atributos de los Jefe de Avance del SP 1.1
de proyecto productos de trabajo y proyecto proyecto SP 1.6
tareas. (ver Anexo SP 1.7
Revisar el coste y esfuerzo. 6.1) SP 2.1
Revisar el progreso frente
al calendario e identificar
el avance de los hitos.
Mensualmente realizar el
reporte de avance del
proyecto.
Identificar y analizar los
problemas en los
parámetros de
planificación de proyectos.
Monitorizar los Revisar estado de los Jefe de Gestión de SP 1.3
riesgos riesgos. proyecto riesgos (ver SP 2.1
Anexo 6.2)
99
Actualizar documento de
riesgos.
Monitorizar Realizar la gestión de Jefe de Gestión de SP 1.4
documentos y datos. proyecto datos (ver SP 1.5
compromisos del Realizar el seguimiento a Anexo 6.3) SP 1.2
proyecto los compromisos y la Matriz de SP 2.1
involucración de los interesados
interesados. (ver Anexo
6.4)
Evaluar control de Documentar y gestionar Jefe de Plantilla de SP 2.1
cambio controles de cambios de proyecto control de
ser necesario. cambios
(ver Anexo
6.5)
Realizar acciones Identificar y realizar Jefe de Lista de SP 2.2
correctivas acciones correctivas a los proyecto problemas SP 2.3
problemas identificados. (ver Anexo
6.6)
Generar informes y Generar reporte de Jefe de Avance del SP 1.6
actualizar progreso y rendimiento. proyecto proyecto SP 2.3
indicadores Actualizar cuadro (ver Anexo
integrado de control de 6.1)
proyectos. Indicadores
Actualizar documento de del
lecciones aprendidas. proyecto
Rendimiento del proyecto. Indicador de desviación de horas programadas.
Rendimiento del cronograma (SPI) Indicador de desviación del presupuesto.
Rendimiento de costos (CPI) Desviaciones a los hitos del proyecto.
Porcentaje de avance por etapa del proyecto. Indicador de seguimiento de problemas.
100
Figura 24: Proceso propuesto de seguimiento y control de proyectos
101
3.1.3.3 Plan de implantación
El plan de implantación permitirá brindar visibilidad del avance del proyecto a las partes
interesadas, es por ello que es importante considerar hitos para medir el avance del proyecto. El
plan de proyecto se encuentra detallado en el Anexo 8, sin embargo, en esta sección se presentarán
los puntos más resaltantes relacionados al alcance del proyecto, la gestión de cronograma y la
gestión de recursos.
3.1.3.3.1 Alcance del proyecto

El alcance del proyecto incluye los procesos de i) Gestión de requisitos, ii) Planificación de
proyectos, y iii) Seguimiento y control del proyecto, para dichos procesos se realiza la adecuación
y difusión de nuevos procesos basados en el modelo de CMMI-DEV, la ejecución de proyectos
pilotos y la puesta en marcha de un equipo para asegurar la mejora de los procesos.
Los entregables considerados para el proyecto son:
Tabla 47: Entregables del proyecto propuesto

Entregables del Descripción Criterio de Fecha de entrega
producto aceptación estimada
Documentos de Documentos con las Documentos en Al tercer mes
procesos . descripciones de los procesos formato definido
a mejorar. por el Manual de
procesos utilizado
por la organización.
Capacitaciones Control de asistencias de las Lista revisada y Durante el
capacitaciones realizadas. validad por la segundo mes.
gerencia del
Departamento de
Sistemas.
Informe de Documento con indicadores Los informes deben Durante el
seguimiento de presentado al final de cada cumplir el formato segundo mes
procesos iteración de los procesos en los desarrollado para la
proyecto piloto.
102
monitorización y
control de proyectos.
Informe del Documento de cierre del Documentos del A fines del
proyecto proyecto. proyecto aprobados segundo mes
en el repositorio de
proyectos.
3.1.3.3.2 Gestión del cronograma

El cronograma tiene tres grandes fases: Inicio del proyecto, ejecución de proyectos pilotos e
instauración de procesos de mejora. En la fase de inicio se selecciona al equipo de proyectos y los
proyectos que serán utilizados como pilotos en la siguiente fase.
En la fase de ejecución de proyectos pilotos se ha considerado dos ciclos de mejora por proceso.
Los ciclos de mejora sirven para mejorar la definición de los procesos, por lo tanto, al finalizar el
primer ciclo de mejora se realizan los ajustes necesarios a los procesos y a su respectiva
documentación, estos cambios serán considerados en el siguiente ciclo de mejora, asimismo, se
deberá capacitar al equipo de proyectos con los ajustes realizados. Al final, de los ciclos de mejora,
se consideran hitos de seguimiento de las mejoras realizadas.
En la última fase, se realiza la instauración de los procesos con las mejoras propuestas y que luego
de los pilotos han sido mejoradas, dentro de las actividades se consideran aquellas que son
necesarias para la difusión de los nuevos procesos e instauración del área de mejora.
Los hitos considerados en el cronograma son:
 Kickoff del proyecto
 Mejora 10% indicadores del proyecto (Por cada proceso en el primer ciclo de mejora)
 Mejora 20% indicadores del proyecto (Por cada proceso en el segundo ciclo de mejora)
 Inicio de operaciones con los nuevos procesos.
3.1.3.3.3 Gestión de recursos humanos

Para la ejecución del proyecto se requerirá tres recursos con los perfiles profesionales y
asignaciones especificados en la Tabla 48.
103
Tabla 48: Recursos humanos requeridos
Puesto Cantidad Perfil Tipo de
asignación
requerida
Gerente de 1 Experiencia comprobada en la gestión de Completo

aseguramiento proyectos en mejora de procesos. Mínimo 5 años
de calidad de participando en proyectos de implantación de
procesos procesos.
Conocimientos comprobados en modelos de

calidad, de preferencia CMMI-DEV.
Analista de 2 Experiencia comprobada, mínimo 2 años, en la Completo

aseguramiento gestión de calidad de procesos.
de calidad de
Experiencia en proyectos de desarrollo de
procesos
software.
3.2 Evaluación económica de la propuesta

Para cuantificar los costos y beneficios del proyecto de mejora de procesos mediante el modelo
CMMI-DEV se han considerado los criterios para cuantificar los costos y beneficios en proyectos
de mejora de calidad identificados por Torres-Navarro, C., & Callegari-Malta, N. (2016), los
cuales se detallan en el Anexo 9, y han sido adoptados en la Tabla 49 para el proyecto propuesto.
3.2.1 Costos del proyecto

Tabla 49: Costos del proyecto
Concepto de costo Período Detalle Total
Costos directos
104
Inversión por Año 0 Incluye: capacitación, implementación y US$ 55,040
actividades del planeación.
proyecto
Hardware y Año 0 3 equipos: Lenovo Thinkpad E570 Intel US$ 7,500
comunicaciones Core I7 - Mi 8gb - A 1tb por US$ 2,500
(c/u).
Software Año 0 3 S.O Windows 10 Pro – US$ 276 (c/u) US$ 6,330
3 MS Office Professional 2016 US$ 554
(c/u)
3 MS Project Professional US$ 1,280 (c/u)
Pago al equipo del Desde año 1 1 Jefe de área - sueldo mensual US$ 1,846 US$ 43,077
proyecto 2 Analista de procesos de calidad - sueldo
mensual de US$ 615 (c/u).
Otros costos Desde año 1 Infraestructura, servicios US$ 300
Costos indirectos
Incentivos equipo Año 0 Para el equipo de proyectos que participe US$ 8,500
mejora en los pilotos de mejora de procesos
Gestión del cambio Año 0 Actividades para gestionar el cambio US$ 34,000
cultural de la organización
Infraestructura nueva Año 0 Acondicionamiento de un área para que US$ 28,000
área de mejora de ejecute sus actividades el equipo de
procesos proyecto de mejora.
Auditorías Desde año 1 A un costo de US$67 por hora por 60 US$ 4,024
horas
Mantenimiento Desde año 1 3 mantenimientos a US$ 200 (c/u) US$ 600
equipos
Otros costos Desde el Costos administrativos por nueva área de US$ 450 y
indirectos año 1 mejora de proceso con un incremento en US$ 518
el quinto año por expansión de la empresa. (Desde el
año 4)
105
3.2.2 Beneficios del proyecto
Los beneficios identificados en el Anexo 9, se pueden cuantificar a partir del estudio realizado por
Goldenson, D., & Gibson, D. L. (2003) donde se afirma que las empresas que implementan CMMI-
DEV obtienen beneficios entre un 20% a 60% de reducción de costos no planificados, además, de
disminución en tiempos de ejecución de proyectos con mejoras del 10% por reducciones de re
trabajos y 15% en los tiempos de espera, asimismo, se presentan incrementos en la mejora en la
satisfacción del cliente entre el 55% y 98%.
Por lo tanto, para el proyecto propuesto se espera tener un ahorro por productividad, así como
incremento de la capacidad del equipo para atender nuevos proyectos, debido a la reducción de los
tiempos de ejecución y además gracias al incremento de la satisfacción del cliente se podrá ingresar
a proyectos en nuevos mercados, producto de la internacionalización de la empresa. Estos
beneficios descritos se detallan en la Tabla 50.
Tabla 50: Beneficios del proyecto

Beneficios del proyecto
Ahorro por productividad
1er año Ahorro del 20% de las pérdidas equivalente a 1125 horas a un precio US$ 33,736
de US$ 30 por hora.
2do año Ahorro del 40% de las pérdidas equivalente a 2249 horas a un precio US$ 69,789
de US$ 30 31.03 por hora
3er año Ahorro del 50% de las pérdidas equivalente a 2811 horas a un precio US$ 89,853
de US$ 31.96
4to año Ahorro del 60% de las pérdidas equivalente a 2811 horas a un precio US$ 111,059
de US$ 32.92
5to año Ahorro del 60% de las pérdidas equivalente a 2811 horas a un precio US$ 114,390
de US$ 33.91
Ingresos por nuevos proyectos y mercados
3er año Proyecto de un año (1920 horas) a un precio de US$ 31.96 por hora US$ 61,365
4to año Proyecto de un año (1920 horas) a un precio de US$ 32.92 por hora US$ 63,206
5to año Proyecto de dos años (3840 horas) a un precio de US$ 33.91 por hora US$ 130,204
106
Nota. Las pérdidas promedio de la empresa son US$ 168,681 equivalentes a 5,623 horas
aproximadamente. Además, se considera incrementos del precio por hora en un 3% anual.
3.2.3 Flujo de caja del proyecto

El flujo de caja del proyecto se encuentra en la Tabla 51, del cual se han obtenido los siguientes
indicadores financieros:
 Valor presente neto (VAN) igual a US$128,821.48
 Tasa Interna de Retorno (TIR) se calcula en 31%
Por lo tanto, al tener una VAN positiva y una TIR superior al costo oportunidad de la inversión
(12%), se considera que el proyecto debe ejecutarse por ser rentable para la empresa.
Tabla 51: Flujo de caja del proyecto

0 1 2 3 4 5
Beneficios
Porcentaje de 0,20 0,40 0,50 0,60 0,60
productividad
Cantidad de horas 1125 2249 2811 3374 3374
por proyecto
Precio por hora 30,00 31,03 31,96 32,92 33,91
Ingreso por US$ 33736,2 US$ 69.789 US$ 89.853 US$ 111.059 US$ 114.390
productividad
Nuevos proyectos US$ 61.365 US$ 63.206 US$ 130.204
Total beneficios US$ 33.736 US$ 69.789 US$ 151.218 US$ 174.265 US$ 244.595
Costos totales del proyecto
Hrs. Proyecto de (US$ 55.040)
mejora
Compra equipos (US$ 7.500)
Licencia (US$ 6.330)
Incentivo equipo de (US$ 8.500)
mejora
Gestión del cambio (US$ 34.000)
Infraestructura para (US$ 28.000)
nueva área
Pago equipo mejora (US$ 43.077) (US$ 43.077) (US$ 43.077) (US$ 43.077) (US$ 43.077)
Mantenimiento (US$ 600) (US$ 600) (US$ 600) (US$ 600) (US$ 600)
equipos
Auditorías (US$ 4.024) (US$ 4.024) (US$ 4.024) (US$ 4.024) (US$ 4.024)
Costos (US$ 450) (US$ 450) (US$ 450) (US$ 518) (US$ 518)
administrativos
Otros costos (US$ 300) (US$ 300) (US$ 300) (US$ 300) (US$ 300)
107
Total costos (US$ 139.370) (US$ 48.451) (US$ 48.451) (US$ 48.451) (US$ 48.519) (US$ 48.519)
Flujo de Caja Neto (US$ 139.370) (US$ 14.715) US$ 21.338 US$ 102.767 US$ 125.746 US$ 196.076
Factor de 1,0000 0,8929 0,7972 0,7118 0,6355 0,5674
descuento:
Flujo de Caja Neto (US$ 139.370) (US$ 13.138) US$ 17.010 US$ 73.147 US$ 79.914 US$ 111.259
Descontado
Sin embargo, debido a que se han realizado asunciones con respecto a los beneficios del proyecto
se considera necesario realizar una simulación del proyecto considerando las variables del
porcentaje de productividad esperada, cantidad de horas por proyecto, precio por hora y el
porcentaje de productividad esperada luego de la implantación del proyecto.
3.2.4 Simulación del proyecto

Para la simulación se han considerado las variables de la Tabla 52.
Tabla 52: Variables de simulación

Variable Consideración para la evaluación
Porcentaje de productividad Distribución uniforme del 0.2 al 0.3 de % de productividad, con
incremento en los siguientes dos años en 0.1% y 0.3%. Se simula
un posible incremento de hasta un 0,1 límite en el cuarto año, con
el cual se espera tener capacidad para proyectos de otros países,
lo cual se simula con una distribución uniforme.
Precio por hora Distribución uniforme de US$30 a US$33 con un posible
incremento del 3% cada año. La posibilidad del incremento
también se simula con una distribución uniforme.
Nuevos proyectos A partir del 3er año se simula la posibilidad de no tener nuevos
proyectos o de tener proyectos de hasta dos años con una
distribución uniforme de 0 a 3840 horas.
Costos variables Distribución uniforme entre US$300 y US$450 con incrementos
del 0,05% anual.
108
Los resultados de la simulación revelan que con los variables definidas se obtiene que la VAN
promedio es de US$91,991.97 la cual es positiva, con un riesgo del 2% de que el proyecto no
genere rentabilidad, tal como se muestra en la Figura 25.
Figura 25: Simulación VAN del proyecto.

Además, la TIR tiene un valor promedio de 26,88% el cual sigue siendo superior al 12% de la tasa
de descuento, tal como se muestra en la Figura 26.
Figura 26: Simulación TIR del proyecto.
109
CAPÍTULO 4: CONCLUSIONES Y
RECOMENDACIONES
Conclusiones
 La industria de desarrollo de software en el Perú tiene proyecciones de crecimiento, sin
embargo, una de las principales barreras para su incursión en el mercado internacional son la
necesidad de adopción de estándares de calidad y certificaciones que garanticen que el proceso
de producción de productos de software es de calidad. Para superar esta barrera, existen normas
internacionales y modelos que pueden implantarse en las empresas dependiendo de sus
necesidades, como son la IS0 9001, ISO 12207, IS0 15504 y CMMI-DEV.
 Con el análisis cuantitativo y cualitativo de la situación de la empresa se identifica que la

problemática más relevante del Departamento de Sistemas es la ineficiencia en la gestión de
proyectos, situación que se ve reflejada en pérdidas económicas por US$168,681, en promedio,
en los últimos tres años. Asimismo, se identifica que esta problemática está afectando
directamente al objetivo del Departamento de Sistemas de alcanzar eficiencia en los procesos,
que apoya al objetivo estratégico de la empresa de incrementar el EBITDA en un 12.5% anual,
además de impactar con la satisfacción del cliente porque se incumple con las fechas y costos
establecidos en los proyectos.
 Ante la problemática planteada se propone implantar mejoras en los procesos de gestión de

proyectos basadas en el modelo de madurez CMMI-DEV, el cual es elegido por los siguientes
motivos: i) está especializado en la industria de software y brinda las pautas para alcanzar
niveles incrementales de madurez en los procesos, ii) su implementación permite la reducción
de costos y tiempo, así como en el incremento de la calidad y la satisfacción del cliente. y iii)
es un modelo ampliamente reconocido internacionalmente lo cual acompaña los planes
estratégicos de la empresa de crecimiento en el extranjero principalmente en los Estados
Unidos y Chile.
110
 Para implantar la mejora de procesos basada en el modelo de CMMI se utiliza el marco IDEAL
por ser un marco de referencia que brinda la hoja de ruta para la implantación de acciones para
la mejora continua de procesos. Además, es el marco propuesto por el Software Engineering
Institute (SEI) de la Carnegie Mellon University, creadores del modelo de madurez CMMI. El
marco Ideal ha permitido estructurar el proyecto de mejora en las etapas de iniciar, diagnosticar
y establecer. En la etapa de iniciar se justifica la necesidad del cambio y se establecen los
objetivos del proyecto, en la etapa de diagnóstico se identifica la situación actual de la empresa
y en la etapa de establecer se presenta el diseño de los nuevos procesos y el plan de
implantación. En el presente documento no se realizan las etapas de ejecutar y aprendizaje
debido a que no se contemplan en el alcance de la propuesta.
 Del diagnóstico inicial realizado se concluye que los procesos de gestión de proyectos
ejecutados por el Departamento de Sistemas no son lo suficientemente maduros, ya que se
identifican brechas importantes a cubrir. Sin embargo, se establecen como procesos prioritarios
en la implantación de la propuesta de mejora, los procesos de gestión de requisitos,
planificación de proyectos y, control y seguimiento de proyectos; debido a su impacto en la
problemática de inadecuada gestión de proyectos. Para estos procesos, se desarrolla el manual
de procesos basado en el modelo CMMI-DEV que permite asegurar los objetivos específicos
y generales que el modelo establece.
 Debido a que el diagnóstico inicial fue basado en el modelo de evaluación SCAMPI, la empresa
ya cuenta con los conocimientos y experiencia acerca de este tipo de evaluación. Por lo tanto,
luego de estabilizados los procesos de mejora propuestos en el presente documento, la empresa
podría solicitar una evaluación oficial de SCAMPI, para la cual se encontrará mejor preparada
para afrontarla con éxito. Conseguir este tipo de certificación permitirá a la unidad de
tecnología de información mejorar su imagen con sus clientes actuales y le abrirá la
oportunidad de ampliar su cartera de clientes.
 El plan de implantación propuesto considera la ejecución de proyectos pilotos con hasta dos
ciclos de mejora, que permitirán asegurar beneficios incrementales con los nuevos procesos.
Asimismo, se establecen hitos que permitirán monitorear la mejora esperada, que permitirá al
Departamento de Sistemas obtener una reducción de las pérdidas en la facturación
(US$168,681) a un 20% el primer año, 40% en el segundo año y 50% a partir del tercer año.
111
 Se identifica como factores críticos de éxito: i) apoyo de la alta gerencia ii) alta capacitación a
todo el personal del área en los nuevos procesos iii) empoderamiento de la nueva área como
clave para el cumplimiento y monitoreo de todos los procesos del área. Gestionar estos factores
permitirán a la empresa ser más rentable, ya que i) será más eficiente y disminuirá sobrecostos,
ii) tendrá mayor capacidad para atender las necesidades del negocio, iii) mejorará la
experiencia del cliente iv) creará una cultura de calidad y de rendimiento y v) mejorará su
imagen con socios estratégicos del mismo grupo.
 Con la evaluación económica de la propuesta se demuestra que el proyecto presentado es

rentable para la empresa pues los indicadores financieros lo respaldan. El valor presente neto
(US$128,821.48) es positivo y la tasa interna de retorno (31%) es superior a la tasa de
descuento del 12%. Además, con la simulación del proyecto se identifica que los supuestos
realizados en los beneficios por productividad y nuevos proyectos, al ser iterados siguen
retornando indicadores financieros positivos para el proyecto, con una VAN promedio positiva
y una TIR promedio superior al 12%.
Recomendaciones
 Se recomienda implantar una mejora de procesos, principalmente en los relacionados a la
gestión de proyectos, debido a su impacto en los objetivos estratégicos organizacionales. Esta
mejora de procesos debe estar basada en un modelo específico para la industria del software
como CMMI-DEV con la finalidad que los procesos se adecuen más fácilmente. Asimismo,
para poder evidenciar mejoras importantes en la organización se recomienda que la
implantación comience con aquellos procesos que han sido identificados como críticos en los
análisis realizados y fueron corroborados con la evaluación inicial, dichos procesos son la
gestión de requisitos, planificación de proyectos y, seguimiento y control de proyectos.
 Se recomienda que luego de la implantación de los procesos abordados en la presente

propuesta, se realice una nueva evaluación basada en SCAMPI para asegurar el impacto
positivo de la implantación. Luego, de estabilizados los procesos, es aconsejable continuar con
otros procesos identificados en el diagnóstico inicial con oportunidad de mejora, hasta lograr
el nivel de madurez deseado para la organización. Asimismo, se aconseja que luego de la
puesta en producción de la mejora se realicen auditorías internas para poder asegurar la mejora
112
progresiva de los procesos, asimismo, se aconseja una auditoría externa luego de la
estabilización de los procesos.
 Se recomienda analizar la posibilidad de solicitar una evaluación SCAMPI clase A como una
necesidad estratégica, ya que la empresa actualmente tiene presencia en el mercado extranjero,
con posibilidad de mayor expansión, por lo tanto, una certificación en calidad de procesos
como la de CMMI en alguno de sus niveles de madurez podría abrir mayores oportunidades
para continuar expandiendo la Unidad de Tecnologías de Información y generar mayores
ingresos a la empresa.
 Se recomienda formar a un equipo especializado en mejora de procesos con el fin de asegurar

la correcta ejecución de los procesos propuestos, brindar capacitación al equipo de proyectos,
acompañar la ejecución de los proyectos pilotos y fomentar nuevas iniciativas de mejora de
procesos en el Departamento de Sistemas. Este equipo deberá contar no sólo con el apoyo de
la Gerencia del Departamento de Sistemas sino también del equipo directivo de la empresa.
 Para asegurar el apoyo de la alta gerencia, se recomienda presentar la propuesta como un

proyecto estratégico mostrando el impacto que tiene en los objetivos estratégicos de la
organización. Asimismo, será necesario acompañar la propuesta con la evaluación económica
realizada para asegurar que la propuesta es rentable para la organización. Asimismo, se
aconseja realizar el seguimiento del proyecto según lo propuesto en el proceso de Seguimiento
y Control del presente documento para poder asegurar la consecución de los hitos que son
críticos para asegurar el ahorro en la productividad esperada del proyecto y la eficiencia
requerida que permita incrementar la capacidad de la empresa para atender la demanda de
nuevos proyectos.
113
Referencias bibliográficas
Annual-Report-to-Partners. (2016). Recuperado de: http://partners.cmmiinstitute.com/wp-

content/uploads/2017/01/Annual-Report-to-Partners-2016.pdf.
Alarcón Aldana, A. C., González Sanabria, J. S., & Rodríguez Torres, S. L. (2011). Guía para
pymes desarrolladoras de software, basada en la norma ISO/IEC 15504. Revista Virtual
Universidad Católica del Norte, (34).
APESOFT: con entidad dedicada a las TIC se duplicaría el crecimiento del sector software. (2017,
abril). Gestión. Recuperado de: https://gestion.pe/tecnologia/apesoft-entidad-dedicada-tic-
duplicaria-crecimiento-sector-software-132697
Ariza, P., Pineres, M., Santiago, L., Mercado, N., & De la Hoz, A. (2014, November).
Implementation of moprosoft level I and II in software development companies in the colombian
caribbean, a commitment to the software product quality region. In Central America and Panama
Convention (CONCAPAN XXXIV), 2014 IEEE (pp. 1-5). IEEE.
Asociación Española para la Calidad (2017). https://www.aec.es/web/guest/centro-

conocimiento/spice
Asociación Internacional de Normalización - ISO (2016). https://www.iso.org/the-iso-survey.html
114
Bautista M., Pérez A. Lara M. (2012). Determinación de la Capacidad de Mejora del Proceso de
Software. Universidad Veracruzana. Recuperado de:
https://www.uv.mx/personal/jfernandez/files/2012/11/ISO15504.pdf”
CMMI Institute (2016). Published Appraisal Results. Recuperado de:

https://sas.cmmiinstitute.com/pars/pars.aspx
Equipo de Producto CMMI (2010). Spanish Technical Report CMMI V1.3. CMMI Institute.
Exportaciones peruanas de software sumaron US$50 millones el año pasado. (5 de mayo del 2016).
Andina – Agencia Peruana de Noticias. Recuperado de:
http://www.andina.com.pe/agencia/noticia-exportaciones-peruanas-software-sumaron-50-
millones-ano-pasado-665767.aspx
Gallegos, J. F. D. C. (2008). Administración del valor ganado aplicado a proyectos de tecnología

de información. Industrial Data, 11(1), 47-52.
Garcia-Miller, S., Graettinger, C., & Kost, K. (2006). Proceedings of the First International
Research Workshop for Process Improvement in Small Settings, 2005.
Garzás, J., Fernández, C. M., & Piattini, M. (2009). Una aplicación de la Norma ISO/IEC 15504
para la Evaluación por Niveles de Madurez de Pymes y Pequeños Equipos de Desarrollo. REICIS.
Revista Española de Innovación, Calidad e Ingeniería del Software, 5(2).
115
Goksen, Y., Cevik, E., & Avunduk, H. (2015). A Case Analysis on the Focus on the Maturity
Models and Information Technologies. Procedia Economics and Finance, 19, 208-216.
Goldenson, D., & Gibson, D. L. (2003). Demonstrating the impact and benefits of CMMI: an
update and preliminary results.
Gremba J. & Myers C. (1997). The IDEAL(SM) model. Software Engineering Institute
publication. Recuperado de: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=20208
Guillen M. (2016, noviembre). El mercado de software en los Estados Unidos. Documento de

trabajo presentado para Estudios de Mercados de la Red de Oficina Económicas y Comerciales de
España en el Exterior. Resumen ejecutivo recuperado de: https://www.icex.es/icex/es/navegacion-
principal/todos-nuestros-servicios/informacion-de-mercados/paises/navegacion-principal/el-
mercado/estudios-informes/DOC2017692504.html?idPais=US
Hayes W., Miluk G., Kitson D. (2003). A family of SCAMPI Appraisal Methods. Software
Engineering Institute. Recuperado de:
https://resources.sei.cmu.edu/asset_files/Presentation/2003_017_001_23182.pdf
Hernández, V. S. (2006). La Industria Del Software. Estudio A Nivel Global Y América

Latina. Observatorio de la Economía Latinoamericana.
Ijaz, Q., Asghar, H., & Ahsan, A. (2016, August). Exploratory study to investigate the correlation
and contrast between ISO 9001 and CMMI framework: Context of software quality management.
116
In Innovative Computing Technology (INTECH), 2016 Sixth International Conference on (pp.
388-391). IEEE.
Industria Nacional de Software. (2017, 29 de agosto). El Comercio. Recuperado de:

https://elcomercio.pe/suplementos/comercial/comercio-exterior/industria-nacional-software-
1002992
Instituto Nacional de Estadística e Informática (INEI). (noviembre del 2017). Comportamiento de

la Economía Peruana en el Tercer Trimestre del 2017 (Informe técnico N°4). Recuperado de:
https://www.inei.gob.pe/media/MenuRecursivo/boletines/04-informe-tecnico-n04_producto-
bruto-interno-trimestral-2017iii.PDF
International Organization for Standarization (ISO). (2015). ISO 9000:2015. Sistema de gestión
de la calidad – Fundamentos y vocabulario. Recuperado de:
https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-4:v1:es
International Organization for Standarization (ISO). (2015). ISO 9001:2015. Sistema de gestión
de la calidad – Requisitos. Recuperado de: https://www.iso.org/obp/ui/#iso:std:iso:9001:ed-
5:v1:es
International Organization for Standarization (ISO). (2008). ISO 12207: 2008. Systems and
software engineering – Software life cycle processes. Recuperado de:
https://www.iso.org/obp/ui/es/#iso:std:iso-iec:12207:ed-2:v1:en
117
Jezreel, M., Marcos, G., & Mirna, M. (2017, June). Organization of the process areas of CMMI-
Dev v1. 3 level 2 through of its dependencies. In Information Systems and Technologies (CISTI),
2017 12th Iberian Conference on (pp. 1-7). IEEE.
Mendoza M. (2015, 20 de octubre). Desarrolladores de software peruanos facturan US$500

millones. El Comercio. Recuperado de: https://elcomercio.pe/economia/negocios/desarrolladores-
software-peruanos-facturan-us-500-millones-233085
Mesquida, A. L., Mas, A., Amengual, E., & Calvo-Manzano, J. A. (2012). IT Service Management
Process Improvement based on ISO/IEC 15504: A systematic review. Information and Software
Technology, 54(3), 239-247.
Miranda, M. (7 de junio de 2017). Perú – Oportunidades para la ciudad sostenible. Documento

de trabajo presentado en el Noveno Foro Inteligencia & Sostenibilidad Urbana, Málaga, España.
Recuperado de: http://greencities.malaga.eu/es/foros/programa-foro-tic-
sostenibilidad./presentaciones-foro-tic-sostenibilidad/index.html#.WjsgzzdG2t8
Norma NMX-I-059-2-NYCE-2016, Tecnologías de la Información – Software – Modelos de

Procesos y Evaluación para Desarrollo y Mantenimiento de Software Parte2: Requisitos de
Procesos (MoProsoft)
NYCE (2016). MoProSoft. Recuperado de: https://www.nyce.org.mx/moprosoft-nyce/
118
Oktaba, H., Esquivel, C. A., Ramos, A. S., Martínez, A. M., Osorio, G. Q., López, M. R., ... &
Lemus, M. Á. F. (2005). Modelo de Procesos para la Industria de Software MoProSoft. Versión
1.3.
Oktaba, H., García, F., Piattini, M., Ruiz, F., Pino, F. J., & Alquicira, C. (2007). Software process
improvement: The competisoft project. Computer, 40(10).
Palacios, H., & Porcell, N. (2012). Diffculties when implementing the CMMI organizational
model. Revista EAN, (72), 110-127.
Perú Service Summit (2017). Recuperado de: http://www.peruservicesummit.com/sectores
Pino, F. J., García, F., Ruiz, F., & Piattini, M. (2005). Adaptación de las normas ISO/IEC 12207:
2002 e ISO/IEC 15504: 2003 para la evaluación de la madurez de procesos software en países en
desarrollo. In JISBD (pp. 187-194).
PROMPEX & APESOFT (2004). Situación de la industria nacional de software en el Perú.

Recuperado de: http://cendoc.esan.edu.pe/fulltext/e-documents/diagnosticosoftware2004_v3.pdf
Resolución Administrativa N° 019-2017 – MTC /33.6. Recuperado de:

https://www.aate.gob.pe/intraate1/upload/institucionales/1503496820-
RA_019_2017_MetodologiaDesarrolloyMantenimiento.pdf
119
Resolución Directoral N° 013-2016-INACAL/DN. Recuperado de:
http://busquedas.elperuano.pe/normaslegales/aprueban-normas-tecnicas-peruanas-sobre-
alimentos-cocidos-de-resolucion-directoral-no-013-2016-inacaldn-1404994-1/
Resolución Ministerial Nº 041-2017-PCM. Recuperado de:

http://busquedas.elperuano.pe/download/url/aprueban-uso-obligatorio-de-la-norma-tecnica-
peruana-ntp-is-resolucion-ministerial-n-041-2017-pcm-1491441-1
Team, C. P. (2002). Capability Maturity Model® Integration (CMMI), Version 1.1- Continuous
Representation.
Torres, M. (2003). Estudio comparativo entre estándares ISO/IEC TR 15540 y CMMI (Tesis de
Grado, Escuela Politécnica Nacional, Quito, Ecuador) Recuperado de:
http://bibdigital.epn.edu.ec/bitstream/15000/240/1/CD-0637.pdf
Torres-Navarro, C., & Callegari-Malta, N. (2016). Criterios para cuantificar costos y beneficios
en proyectos de mejora de calidad. Ingeniería Industrial, 37(2), 151-163.
Valle, A. M., Santos, E. A., & Loures, E. R. (2017). Applying process mining techniques in
software process appraisals. Information and Software Technology, 87, 19-31.
Von Wangenheim, C. G., da Silva, D. A., Buglione, L., Scheidt, R., & Prikladnicki, R. (2010).
Best practice fusion of CMMI-DEV v1. 2 (PP, PMC, SAM) and PMBOK 2008. Information and
software technology, 52(7), 749-757.
120
Anexos
Anexo 1: Diagramas actuales de gestión de proyectos.
Anexo 1.1: Diagrama de iniciación de proyectos
121
Anexo 1.2: Diagrama de planificación de proyectos
Anexo 1.3: Diagrama de ejecución de proyectos
122
Anexo 1.4: Diagrama de seguimiento y control de proyectos
Anexo 1.5: Diagrama de cierre de proyectos
123
Anexo 2: Formatos de encuestas.
Anexo 2.1: Encuesta de gestión de requisitos
Tabla 2.1.A: Encuesta de metas y prácticas específicas de gestión de requisitos
Sub Nunca A veces Siempre

Resumen de metas y prácticas especifica Preguntas
Práctica 0 3 5
SG 1 Gestionar los requisitos
SP 1.1 Comprender los requisitos SP 1.1.1 ¿Se establecen criterios para distinguir a los proveedores apropiados de requisitos?
SP 1.1.2 ¿Se establecen criterios objetivos para la evaluación y aceptación de los requisitos ?
SP 1.1.3 ¿Se analizan los requisitos para asegurar que se cumplen los criterios establecidos ?
¿Alcanzar una comprensión de los requisitos con los proveedores de requisitos para que los
SP 1.1.4
participantes del proyecto puedan comprometerse con ellos ?
SP 1.2 Obtener el compromiso sobre los SP 1.2.1 ¿Se evalúa el impacto de los requisitos sobre los compromisos existentes ?
requisitos SP 1.2.2 ¿Se negocian y registran los compromisos ?
SP 1.3 Gestionar los cambios a los requisitos ¿Se documentan todos los requisitos y los cambios a los requisitos que se reciben o generan por
SP 1.3.1
el proyecto ?
¿Se mantiene una historia de cambios de los requisitos, incluyendo el análisis razonado de los
SP 1.3.2
cambios ?
¿Se evalúa el impacto de los cambios de requisitos desde el punto de vista de las partes
SP 1.3.3
interesadas relevantes ?
SP 1.3.4 ¿Se pone a disposición del proyecto los requisitos y los datos de los cambios ?
SP 1.4 Mantener la trazabilidad bidireccional ¿Se mantiene la trazabilidad de los requisitos para asegurar que la fuente de los requisitos de
SP 1.4.1
de los requisitos nivel más bajo (es decir, inferidos) está documentada ?
¿Se mantiene la trazabilidad de los requisitos desde un requisito a sus requisitos inferidos y a la
SP 1.4.2
asignación a los productos de trabajo ?
SP 1.4.3 ¿Se genera una matriz de trazabilidad de requisitos ?
SP 1.5 Asegurar el alineamiento entre el ¿Se revisan los planes del proyecto, las actividades y los productos de trabajo en cuanto a la
SP 1.5.1
trabajo del proyecto y los requisitos consistencia con los requisitos y los cambios realizados sobre ellos ?
SP 1.5.2 ¿Se identifica la fuente de la inconsistencia (si existe) ?
¿Se identifica cualquier cambio que se debería realizar a los planes y a los productos de trabajo
SP 1.5.3
resultantes de los cambios a la línea base de requisitos ?
SP 1.5.4 ¿Se inicia cualquier acción correctiva necesaria ?
Tabla 2.1.B: Encuesta de metas y prácticas genéricas de gestión de requisitos
Nunca A veces Siempre

Resumen de metas y prácticas genéricas Preguntas
0 3 5
GG2 Institucionalizar un proceso gestionado
GP 2.1 Establecer una política de la organización ¿Se tiene una política en la organización para la gestion de requerimientos?
GP 2.2 Planificar el proceso ¿Se establece y mantiene el plan para realizar el proceso de la gestion de requerimientos?
GP 2.3 Proporcionar recursos ¿Se proporciona recursos para realizar el proceso de la gestion de requerimientos?
¿Se asigna responsabilidad y la autoridad para realizar el proceso de la gestion de
requerimientos?
GP 2.5 Formar al personal ¿Se forma a las personas para realizar o dar soporte al proceso de la gestion de requerimientos?
¿Se pone los productos de trabajo seleccionados del proceso de gestion de requerimientos bajo
los niveles de control apropiados?
Identificar e involucrar a las partes interesadas ¿Se identifica e involucra a las partes interesadas relevantes del proceso de la gestion de
GP 2.7
relevantes requerimientos?
¿Se monitorea y controla el proceso de gestión de requerimientos para tomar las acciones
GP 2.8 Monitorizar y controlar el proceso
correctivas apropiadas?
¿Se evalua objetivamente la adherencia del proceso de gestión de requerimientos y de los
GP 2.9 Evaluar objetivamente la adherencia productos del trabajo seleccionados frente a la descripción del proceso, estandares, manuales y
procedimientos y tratar las no conformidades?
¿El nivel directivo revisa las actividades del proceso de gestión de requerimientos, el estado y los
resultados del proceso y ayuda a resolver los asuntos en discución?
124
Anexo 2.2: Encuesta de planificación de proyectos
Tabla 2.2.A: Encuesta de metas y prácticas específicas de planificación del proyecto

Práctica 0 3 5
SG 1 Establecer las estimaciones
SP 1.1 Estimar el alcance del proyecto SP 1.1.1 ¿Se desarrolla una WBS?
Se defini los paquetes de trabajo con el detalle suficiente para que se
SP 1.1.2 puedan especificar las estimaciones de las tareas, las responsabilidades
y el calendario del proyecto?
¿Se identifica los productos y los componentes del producto a adquirir
SP 1.1.3
externamente.
SP 1.1.4 ¿Se identifica los productos de trabajo a reutilizar?
SP 1.2 Establecer las estimaciones de los SP 1.2.1 ¿Se determinar la aproximación técnica para el proyecto?
atributos de los productos de trabajo ¿Se usa métodos apropiados para determinar los atributos de los productos
y de las tareas. SP 1.2.2
de trabajo y de las tareas a utilizar para estimar los requisitos de recursos?
SP 1.2.3 ¿Se estima los atributos de los productos de trabajo y de las tareas?
SP 1.3 Definir las fases del ciclo de vida del ¿Se define las fases del ciclo de vida del proyecto sobre las que encuadrar el esfuerzo
SP 1.3.1
proyecto a planificar?
SP 1.4 Estimar el esfuerzo y el coste ¿Se recopila los modelos o los datos históricos a utilizar para transformar
SP 1.4.1 los atributos de los productos de trabajo y de las tareas en estimaciones
de horas de trabajo y de coste?
¿Se incluye las necesidades de la infraestructura de soporte al estimar el
SP 1.4.2
esfuerzo y el coste?
¿Se estima el esfuerzo y el coste usando modelos, datos históricos, o una
SP 1.4.3
combinación de ambos?
SG2 Desarrollar un plan de proyecto
SP 2.1 Establecer el presupuesto y el SP 2.1.1 ¿Se identificar los principales hitos?
calendario SP 2.1.2 ¿Se identifica los supuestos del calendario?
SP 2.1.3 ¿Se identifica las restricciones?
SP 2.1.4 ¿Se identifica las dependencias entre las tareas?
SP 2.1.5 ¿Se establece y mantiene el presupuesto y el calendario?
SP 2.1.6 ¿Se establece los criterios de las acciones correctivas?
SP 2.2 Identificar los riesgos del proyecto SP 2.2.1 ¿Se identifica los riesgos?
SP 2.2.2 ¿Se documenta riesgos?
¿Se revisa y obtiene el acuerdo con las partes interesadas relevantes sobre
SP 2.2.3
la completitud y exactitud de los riesgos documentados?
SP 2.2.4 ¿Se modifica los riesgos según sea apropiado?
SP 2.3 Planificar la gestión de los datos ¿Se establece los requisitos y los procedimientos para asegurar la privacidad
SP 2.3.1
y la seguridad de los datos?
¿Se establece un mecanismo para almacenar los datos y acceder a los
SP 2.3.2
datos almacenados?
¿Se documentan las acciones correctivas para corregir las desviaciones Determinar los datos del proyecto que
SP 2.3.3
serán identificados, recogidos y distribuidos?
¿Se determina los requisitos para proporcionar el acceso a los datos y su
SP 2.3.4
distribución a las partes interesadas relevantes?
¿Se decide qué datos y planes del proyecto requieren control de versión u otros niveles de control de
SP 2.3.5
configuración y establecer mecanismos para asegurar que los datos del proyecto se controlan?
SP 2.4 Planificar los recursos del proyecto SP 2.4.1 ¿Se determina los requisitos del proceso?
SP 2.4.2 ¿Se determina los requisitos de comunicación?
SP 2.4.3 ¿Se determina los requisitos de personal?
SP 2.4.4 ¿Se determina los requisitos de instalaciones, equipamiento y componentes?
SP 2.4.5 ¿Se determina otros requisitos de recursos continuos?
SP 2.5 Planificar el conocimiento y las SP 2.5.1 ¿Se identifica el conocimiento y las habilidades necesarios para realizar el proyecto?
habilidades necesarias SP 2.5.2 ¿Se evalua el conocimiento y las habilidades disponibles?
SP 2.5.3 ¿Se selecciona los mecanismos para proporcionar el conocimiento y las habilidades necesarias?
SP 2.5.4 ¿Se incorpora los mecanismos seleccionados en el plan de proyecto?
SP 2.6 Planificar la involucración de las
SP 2.6.1 ¿Se planifica la involucración de las partes interesadas identificadas?
partes interesadas
SP 2.7 Establecer el plan de proyecto SP 2.7.1 ¿Se establece y mantiene el plan global del proyecto?
SG3 Obtener el compromiso con el plan

SP 3.1 Revisar los planes que afectan al
SP 3.1.1 ¿Se revisa todos los planes que afectan al proyecto para comprender los compromisos del proyecto?
proyecto
SP 3.2 Conciliar los niveles de trabajo y de ¿Se ajusta el plan de proyecto para conciliar los recursos disponibles y los estimados.Se revisa los compromisos
SP 3.2.1
recursos internos con la alta dirección según sea apropiado?
SP 3.3 Obtener el compromiso con el plan SP 3.3.1 ¿Se identifica el soporte necesario y negocia los compromisos con las partes interesadas relevantes?
¿Se documenta todos los compromisos de la organización, tanto definitivos como provisionales, asegurando el
SP 3.3.2
nivel apropiado de firmantes?
SP 3.3.3 ¿Se revisa los compromisos internos con la alta dirección según sea apropiado?
SP 3.3.4 ¿Se revisa los compromisos externos con la alta dirección según sea apropiado?
¿Se identifica los compromisos relacionados con las interfaces entre los elementos del proyecto y otros proyectos
SP 3.3.5
y unidades de la organización, de tal forma que estos compromisos puedan ser monitorizados?
125
Tabla 2.2.B: Encuesta de metas y prácticas genéricas de planificación del proyecto

0 3 5
Institucionalizar un proceso gestionado
GG2
GP 2.1 Establecer una política de la organización
¿Se tiene una política de establecimiento de las expectativas de la organización para estimar los parámetros de la
planificación, para definir compromisos internos y externos, y para desarrollar un plan para gestionar el proyecto?
GP 2.2 Planificar el proceso ¿Se establece y mantiene el plan para realizar el proceso?: Ejemplo: planificación de actividades de planificación
del proyecto.
GP 2.3 Proporcionar recursos Se proporciona recursos en caso se necesite experiencia, equipamiento e instalaciones especiales. Ejemplos:
Expertos técnicos en áreas aplicables, paquetes de planificación y de calendario del proyecto, modelos de
estimaciones
GP 2.4 Asignar responsabilidad ¿Se asigna responsabilidad y la autoridad para realizar el proceso, desarrollar los productos de trabajo y
proporcionar los servicios del proceso?
GP 2.5 Formar al personal ¿Se forma a las personas para realizar o dar soporte al proceso según sea necesario?
GP 2.6 Controlar los productos de trabajo ¿Se pone los productos de trabajo seleccionados del proceso bajo los niveles de control apropiados? Ejemplos:
Estructura de descomposición del trabajo, Plan de proyecto
GP 2.7 Identificar e involucrar a las partes interesadas
¿Se identifica e involucra a las partes interesadas relevantes del proceso, según lo planificado?
relevantes
GP 2.8 Monitorizar y controlar el proceso ¿Se monitoriza y controla el proceso frente al plan para realizar el proceso y tomar las acciones correctivas
apropiadas? Ejemplos: Número de revisiones al plan, Variación de coste, calendario y esfuerzo por cada
modificación del plan.
GP 2.9 Evaluar objetivamente la adherencia ¿Se evalua objetivamente la adherencia del proceso y de los productos de trabajo seleccionados frente a la
descripción del proceso, estándares y procedimientos, y tratar las no conformidades?
¿Se revisa con el nivel directivo las actividades, el estado y los resultados del proceso y resolver las cuestiones?
126
Anexo 2.3: Encuesta de monitorización y control de proyectos
Tabla 2.3.A: Encuesta de metas y prácticas específicas de monitorización y control de proyectos

Práctica 0 3 5
SG 1 Monitorear el proyecto frente al plan
SP 1.1 Monitorear los parámetros de SP 1.1.1 ¿Se monitorean el tiempo y esfuerzo asociados de cada proyecto?
planificación del proyecto SP 1.1.2 ¿Se monitorean los costes asociados de cada proyecto?
SP 1.1.3 ¿Se monitorean los atributos de los productos de trabajo y las taeas?
SP 1.1.4 ¿Se moniteren los recursos proporcionados y recursos utilizados ?
SP 1.1.5 ¿Se monitorean el conocimientos y las habilidades del personal de proyecto?
SP 1.1.6 ¿Se documentan las desviaciónes significativas en los parametros de planificación?
SP 1.2 Monitorear los compromisos SP 1.2.1 ¿Se revisan regularmente los compromisos?
SP 1.2.2 ¿Se identifican los compromisos que no se han cumplido o que estan en riesgo?
SP 1.2.3 ¿Se documentan los resultados de las revisiones de los compromisos?
SP 1.3 Monitorear los riesgos del proyecto SP 1.3.1 ¿Se revisan periodicamente la documentación de riesgos?
SP 1.3.2 ¿Se modifica la documentación de riesgo a medida que avanzan los proyectos?
SP 1.3.3 ¿Se comunican el estado de los riegos a las partes interesadas del proyecto?
SP 1.4 Monitorear la gestión de los datos SP 1.4.1 ¿Se revisan periodicamente las actividades de gestión de datos?
SP 1.4.2 ¿Se identifican y documentan las cuestiones significativas y sus impactos?
SP 1.4.3 ¿Se documentan los resultados de las revisiones de la gestión de datos?
SP 1.5 Monitorear la involucración de las SP 1.5.1 ¿Se revisan periodicamente el estado de la involucación de las partes intersadas?
partes interesadas SP 1.5.2 ¿Se identifican y documentan los asuntos significativos y sus impactos?
SP 1.5.3 ¿Se documentan los resultados de las revisiones de las partes interesadas?
SP 1.6 Llevar a cabo las revisiones de SP 1.6.1 ¿Se comunica con regularidad a la partes interesadas el estado de las actividades?
progreso SP 1.6.2 ¿Se revisan los resultados de la recogida y el analisis de las medidas?
SP 1.6.3 ¿Se identifican y documentan las cuestiones y desviaciones frente al plan?
SP 1.6.4 ¿Se documentan las peticiones de cambio y problemas identificados del WBS?
SP 1.6.5 ¿Se documentan los resultados de revisiones?
SP 1.6.6 ¿Se siguen las peticiones de cambio y los informes de problemas hasta su cierre?
SP 1.7 Llevar a cabo las revisiones de hitos SP 1.7.1 ¿Se llevan a cabo las revisiones de hitos con las partes interesadas?
SP 1.7.2 ¿Se revisan los compromisos, plan, estado y riesgo del proyecto?
SP 1.7.3 ¿Se identifican y documentan las cuestiones significativas y sus impactos?
SP 1.7.4 ¿Se documentan los resultados de revisión?
SP 1.7.5 ¿Se siguen los elementos de acción hasta su cierre?
SG2 Gestionar las acciones correctivas hasta su cierre
SP 2.1 Analizar los asuntos de discución SP 2.1.1 ¿Se recopilan los asuntos de discución para su análisis?
SP 2.1.2 ¿Se analizan los asuntos de discución para determinar las acciones correctivas?
SP 2.2 Llevar a cabo las acciones correctivas SP 2.2.1 ¿se determinan y documentan las acciones apropiadas para tratar los asuntos de discución?
SP 2.3 Gestionar las acciones correctivas SP 2.3.1 ¿Se monitorean las acciones correctivas hasta su finalización?
SP 2.3.2 ¿Se analizan los resultados de las acciones correctivas para medir su eficacia?
SP 2.3.3 ¿Se documentan las acciones correctivas para corregir las desviaciones
Tabla 2.3.B: Encuesta de metas y prácticas genéricas de monitorización y control de proyectos

0 3 5
GG2 Institucionalizar un proceso gestionado
GP 2.1 Establecer una política de la organización ¿Se tiene una política en la organización para la monitorización y control de los proyectos?
GP 2.2 Planificar el proceso ¿Se establece y mantiene el plan para la monitorización y control de proyectos?
GP 2.3 Proporcionar recursos Se proporciona recursos para la monitorización y control de proyectos?
¿Se asigna responsabilidad y la autoridad para realizar el proceso para la monitorización y
control de los proyectos?
¿Se forma a las personas para realizar o dar soporte al proceso de monitorización y control
GP 2.5 Formar al personal
del proyecto?
¿Se pone los productos de trabajo del proceso de monitorización y control de los proyectos
seleccionados del proceso bajo los niveles de control apropiados ?
Identificar e involucrar a las partes interesadas ¿Se identifica e involucra a las partes interesadas relevantes del proceso para la monitorización
GP 2.7
relevantes y control de los proyectos?
GP 2.8 Monitorizar y controlar el proceso ¿Se monitorea el proceso de monitorización y control del proyecto?
¿Se evalua objetivamente la adherencia del proceso de monitorización y control del proyecto
GP 2.9 Evaluar objetivamente la adherencia frente a los productos del trabajo seleccionados tales como estandares, manuales y
procedimientos?
¿El nivel directivo revisa las actividades del proceso de monitorización y gestión de proyectos,
el estado y los resultados del proceso y ayuda a resolver los asuntos en discución?
127
Anexo 3: Reporte de la evaluación inicial
Nota: Documento resumido.
EVALUACIÓN DE PROCESOS DEL NIVEL DE

MADUREZ 2 DE CMMI-DEV
El presente documento presenta el diagnóstico de los procesos del
nivel e madurez 2. No tiene validez como evaluación SCAMPI
128
1. Alcance
El alcance organizacional de la evaluación inicial involucra al área de Desarrollo de Software del

Departamento de Sistemas de la consultora de software. Asimismo, en el diagnóstico inicial sólo
se contemplará en la evaluación, los procesos del área que estén asociados a los procesos del nivel
de madurez 2 del modelo CMMI-DEV.
Los procesos considerados en la evaluación son:
 Gestión de requisitos
 Monitorización y control de proyectos
 Gestión de acuerdos con proveedores
 Gestión de configuración
 Medición y análisis
 Aseguramiento de la calidad del proceso y del producto
2. Evaluación
a. Gestión de Requisitos
El propósito de la Gestión de Requisitos (REQM) es gestionar los requisitos de los productos y los
componentes de producto del proyecto, y asegurar la alineación entre esos requisitos, y los planes
y los productos de trabajo del proyecto.
A. Metas específicas:
 SG1: Gestionar los Requisitos: Se establece la gestión de requisitos, así como se identifican
las inconsistencias de los planes y productos de trabajo del proyecto. El proyecto mantiene
un conjunto actual y aprobado de requisitos durante la vida del mismo.
B. Metas genéricas:
129
 GG2: Institucionalizar un proceso gestionado.
C. Fortalezas:
 Se tiene una política en la organización para la gestión de requerimientos.
 Se planifica el proceso, ya que se establece y mantiene un plan para realizar el proceso de

la gestión de requerimientos.
 Se proporciona recursos para realizar el proceso de la gestión de requerimientos.
 Se asigna responsabilidad y la autoridad para realizar el proceso de la gestión de

requerimientos.
 Se forma a las personas para realizar o dar soporte al proceso de la gestión de

requerimientos.
 Se pone los productos de trabajo seleccionados del proceso de gestión de requerimientos

bajo los niveles de control apropiados.
 Se identifica e involucra a las partes interesadas relevantes del proceso de la gestión de

requerimientos.
 Se monitorea y controla el proceso de gestión de requerimientos para tomar las acciones

correctivas apropiadas.
D. Oportunidades de mejora:
 No siempre se comprenden los requisitos, ya que no siempre: se establecen criterios para

distinguir a los proveedores apropiados de requisitos; se establecen criterios objetivos para
la evaluación y aceptación de los requisitos ni se analizan para asegurar que se cumplen
los criterios establecidos; se alcanza una comprensión de los requisitos con los proveedores
de requisitos para que los participantes del proyecto puedan comprometerse con ellos.
 No siempre se obtiene el compromiso con los requisitos; ya que nos son prácticas
frecuentes que se evalúe el impacto de los requisitos sobre los compromisos existentes ni
que se negocien y registren los compromisos.
130
 No siempre se gestionan los requisitos, ya que no siempre se: documentan todos los
requisitos y los cambios a los requisitos que se reciben o generan por el proyecto; se
mantiene una historia de cambios de los requisitos, incluyendo el análisis razonado de los
cambios; se evalúa el impacto de los cambios de requisitos desde el punto de vista de las
partes interesadas relevantes; ni se pone a disposición del proyecto los requisitos y los datos
de los cambios.
 No siempre se mantiene la trazabilidad bidireccional de los requisitos, ya que no son

prácticas frecuentes que: se asegure que la fuente de los requisitos de nivel más bajo está
documentada; se mantenga trazabilidad de los requisitos desde un requisito a sus requisitos
inferidos y a la asignación a los productos de trabajo; además, no siempre se genera una
matriz de trazabilidad de requisitos.
 No siempre se asegura el alineamiento entre el trabajo del proyecto y los requisitos ya que
no siempre: se revisan los planes del proyecto, las actividades y los productos de trabajo
en cuanto a la consistencia con los requisitos y los cambios realizados sobre ellos; se
identifica la fuente de la inconsistencia (si existe); se identifica cualquier cambio que se
debería realizar a los planes y a los productos de trabajo resultantes de los cambios a la
línea base de requisitos; ni se inicia cualquier acción correctiva necesaria.
 No siempre se evalúa objetivamente la adherencia del proceso de gestión de requerimientos

y de los productos del trabajo seleccionados frente a la descripción del proceso, estándares,
manuales y procedimientos y tratar las no conformidades.
 El nivel directivo no siempre revisa las actividades del proceso de gestión de

requerimientos, el estado y los resultados del proceso y ayuda a resolver los asuntos en
discusión.
 No siempre se establece y mantiene constantemente la descripción del proceso de gestión

de requerimientos.
 No siempre se recoge experiencias de la gestión de requerimientos para dar soporte al uso

futuro y a la mejora de procesos.
E. Resultados de la evaluación:
131
b. Planificación del Proyecto
El propósito de la Planificación del Proyecto (PP) es establecer y mantener planes que definan las
actividades del proyecto.
 SG1: Establecer Estimaciones: Se establecen y mantienen las estimaciones de los

parámetros de planificación del proyecto.
 SG2: Desarrollar un plan de proyecto: Se establece y mantiene un plan de proyecto como

base para gestionar el proyecto.
132
 SG3: Obtener compromiso con el plan: Se establecen y mantienen los compromisos con el
plan de proyecto.
C. Fortalezas:
 Se determina la aproximación técnica para el proyecto.
 Se usa métodos apropiados para determinar los atributos de los productos de trabajo y de
las tareas a utilizar para estimar los requisitos de recurso.
 Se estima los atributos de los productos de trabajo y de las tareas.
 Se define las fases del ciclo de vida del proyecto sobre las que encuadrar el esfuerzo a
planificar.
 Se establece y mantiene el plan global del proyecto, además, se establece y mantiene el

plan para realizar la planificación de proyectos.
 Se proporciona recursos en caso se necesite experiencia, equipamiento e instalaciones

especiales. Ejemplos: Expertos técnicos en áreas aplicables, paquetes de planificación y de
calendario del proyecto, modelos de estimaciones.
 Se asigna responsabilidad y la autoridad para realizar el proceso, desarrollar los productos

de trabajo y proporcionar los servicios del proceso.
 Se forma a las personas para realizar o dar soporte al proceso según sea necesario.
 Se pone los productos de trabajo seleccionados del proceso bajo los niveles de control
apropiados. Ejemplos: Estructura de descomposición del trabajo, Plan de proyecto.
 Se identifica e involucra a las partes interesadas relevantes del proceso, según lo

planificado.
133
 Se identifica e involucra a las partes interesadas relevantes del proceso, según lo
planificado.
 Se evalúa objetivamente la adherencia del proceso y de los productos de trabajo

seleccionados frente a la descripción del proceso, estándares y procedimientos, y tratar las
no conformidades.
 No siempre se desarrollar una WBS (Estructura de descomposición de trabajo) y se define

los paquetes de trabajo con el detalle suficiente para que se puedan especificar las
estimaciones de las tareas, las responsabilidades y el calendario del proyecto.
 No siempre se identifica los productos y los componentes del producto a adquirir

externamente ni se identifica los productos de trabajo a reutilizar.
 No se recopila los modelos o los datos históricos a utilizar para transformar los atributos
de los productos de trabajo y de las tareas en estimaciones de horas de trabajo y de coste.
Esto indica que no se estima el esfuerzo y el coste usando modelos, datos históricos, o una
combinación de ambos.
 No se incluye las necesidades de la infraestructura de soporte al estimar el esfuerzo y el

coste.
 No se identifica los principales hitos ni supuestos del calendario. Asimismo, tampoco se

identifica restricciones y dependencias entre las tareas.
 No se establece ni mantiene el presupuesto y el calendario, así como tampoco se establecen

los criterios de las acciones correctivas.
 No siempre se identifica ni se documenta los riesgos, por lo que no es posible revisar y

obtener el acuerdo con las partes interesadas relevantes sobre la completitud y exactitud de
los riesgos.
 No siempre se establece los requisitos y los procedimientos para asegurar la privacidad y

la seguridad de los datos. Ni se determina los requisitos para proporcionar el acceso a los
datos y su distribución a las partes interesadas relevantes.
134
 No siempre se establece un mecanismo para almacenar los datos y acceder a los datos
almacenados.
 No siempre se documentan las acciones correctivas para corregir las desviaciones Ni se

determina los datos del proyecto que serán identificados, recogidos y distribuidos.
 No siempre se decide qué datos y planes del proyecto requieren control de versión u otros
niveles de control de configuración ni se establece mecanismos para asegurar que los datos
del proyecto se controlan.
 No siempre se determina los requisitos del proyecto como por ejemplo los requisitos de
comunicación, de personal, de instalaciones, de equipamiento, de componentes u otros
recursos continuos.
 No siempre se planifica el conocimiento y las habilidades necesarias para la ejecución de

los proyectos, así como tampoco se evalúan las habilidades disponibles.
 No siempre se planifica la involucración en el proyecto de las partes interesadas

identificadas, además, frecuentemente no se revisa todos los planes que afectan al proyecto
para comprender los compromisos del proyecto.
 No se ajusta el plan de proyecto para conciliar los recursos disponibles y los estimados. Ni
se revisa los compromisos internos con la alta dirección según sea apropiado para conciliar
los niveles de trabajo y de recursos.
 En general no se negocia ni se evalúan los compromisos con las partes interesadas ni los
compromisos externos ni internos con la alta dirección, por lo que no se logra obtener un
compromiso de todos los involucrados e interesados en el proyecto.
 No siempre se sigue una política de establecimiento de las expectativas de la organización

para estimar los parámetros de la planificación, para definir compromisos internos y
externos, y para desarrollar un plan para gestionar el proyecto.
 No siempre se monitoriza y controla el proceso frente al plan para realizar el proceso y

tomar las acciones correctivas apropiadas. Asimismo, no es frecuente las revisiones con el
nivel directivo las actividades, el estado y los resultados del proceso y resolver las
cuestiones.
135
 No se establece ni mantiene la descripción de un proceso definido. Ni tampoco se recoge
experiencias relativas al proceso procedentes de la planificación y realización del proceso
para dar soporte al uso futuro y a la mejora de los procesos y de los activos de proceso de
la organización.
136
c. Monitorización y Control del Proyecto
El propósito Seguimiento y Control del Proyecto (PMC) es proporcionar una comprensión del
progreso del proyecto para que se puedan tomar las acciones correctivas apropiadas, cuando el
rendimiento del proyecto se desvíe significativamente del plan.
 SG1: Dar Seguimiento al Proyecto respecto del Plan: Se realiza seguimiento al rendimiento
y el progreso real del proyecto respecto al plan del proyecto.
 SG2: Gestionar y Cerrar Acciones Correctivas: Se gestionan las acciones correctivas hasta
su cierre cuando el rendimiento o los resultados del proyecto se desvían significativamente
del plan.
C. Fortalezas:
 El nivel directivo revisa las actividades del proceso de monitorización y gestión de

proyectos, el estado y los resultados del proceso y ayuda a resolver los asuntos en discusión.
137
 No siempre se monitorean los parámetros de planificación del proyecto como tiempo,
esfuerzo, costos, atributos de los productos de trabajo, recursos, habilidades ni
conocimientos del personal. Asimismo, tampoco se documentan las desviaciones
significativas en los parámetros de planificación.
 No siempre se revisan regularmente los compromisos para poder identificar los

compromisos que no se han cumplido o que están en riesgo. Asimismo, en los casos en los
que se realiza la revisión de compromisos no siempre se documentan los resultados de las
revisiones.
 No se monitorea los riesgos del proyecto ya que se evidencia que no se modifica la

documentación de riesgo a medida que avanzan los proyectos ni existen revisiones
periódicas de la documentación de riesgo. Asimismo, tampoco se comunica el estado de
los riegos a las partes interesadas del proyecto.
 No se monitorea la gestión de datos, ya que se evidencia que no se revisan periódicamente

las actividades de gestión de datos ni se identifican o documentan las cuestiones
significativas y sus impactos. Tampoco se documentan los resultados de las revisiones de
la gestión de datos.
 No siempre se monitorear la involucración de las partes interesadas. Se evidencia que no

siempre se revisan periódicamente el estado de la involucración de las partes interesadas
ni se identifican o documentan los asuntos significativos y sus impactos. Algunas veces se
documentan los resultados de las revisiones de las partes interesadas.
 No siempre se lleva a cabo las revisiones de progreso, ya que se cumple con: comunicar
con regularidad a las partes interesadas el estado de las actividades, revisar los resultados
de la recogida y el análisis de las medidas, identificar y documentar las cuestiones y
desviaciones frente al plan, documentar las peticiones de cambio y problemas identificados
del WBS, documentar los resultados de revisiones, y, sigue las peticiones de cambio y los
informes de problemas hasta su cierre.
 No se llevan a cabo las revisiones de hitos con las partes interesadas, ni se revisan los
compromisos, plan, estado y riesgo del proyecto. Además, no se documentan los resultados
de revisión ni se siguen los elementos de acción hasta su cierre.
138
 No siempre se recopilan los asuntos de discusión para su análisis ni se analizan para
determinar las acciones correctivas.
 No siempre se determinan o documentan las acciones apropiadas para tratar los asuntos de
discusión.
 No siempre se monitorean las acciones correctivas hasta su finalización, o se monitorean

las acciones correctivas hasta su finalización. Tampoco es frecuente que se documenten las
acciones correctivas para corregir las desviaciones.
 No siempre se sigue una política o plan en la organización para la monitorización y control

de los proyectos.
 No siempre se proporciona recursos, se asignan responsabilidades y la autoridad para

realizar la monitorización y control de proyectos. Algunas veces, se forma a las personas
para realizar o dar soporte al proceso de monitorización y control del proyecto.
 No se pone los productos de trabajo del proceso de monitorización y control de los

proyectos seleccionados del proceso bajo los niveles de control apropiados.
 Algunas veces se identifica e involucra a las partes interesadas relevantes del proceso para
la monitorización y control de los proyectos.
 No siempre se monitorea el proceso de monitorización y control del proyecto.
 No siempre se evalúa objetivamente la adherencia del proceso de monitorización y control

del proyecto frente a los productos del trabajo seleccionados tales como estándares,
manuales y procedimientos.
 No siempre se establece y mantiene constantemente la descripción del proceso de

monitorización y control del proyecto. Además, sólo algunas veces se recoge experiencias
del proceso para dar soporte al uso futuro y a la mejora del proceso.
139
d. Gestión de Acuerdos con Proveedores
El propósito de la Gestión de Acuerdos con Proveedores (SAM) es gestionar la adquisición de

productos y servicios de proveedores.
140
 SG1: Establecer acuerdos con proveedores. Los acuerdos con los proveedores se establecen
y mantienen.
 SG2: Satisfacer los acuerdos con los proveedores. Los acuerdos con los proveedores se
satisfacen tanto por el proyecto como por el proveedor.
C. Fortalezas:
 Casi siempre se determina el tipo de adquisición para cada producto o componente de

producto a adquirir.
 Casi siempre se selecciona a los proveedores en base a una evaluación de su capacidad para
cumplir los requisitos especificados y los criterios establecidos, casi siempre se cumple con
establecer y documentar los criterios para la evaluación de proveedores potenciales,
identificar proveedores potenciales y se envía el material y los requisitos, evaluar
propuestas conforme a los criterios de evaluación, evaluar los riesgos asociados con cada
proveedor propuesto y con evaluar las capacidades de los proveedores propuestos para
realizar.
 Casi siempre se establece y mantiene los acuerdos con proveedores, ya que se cumple
frecuentemente con: revisar periódicamente al acuerdo con el proveedor para asegurar que
refleja exactamente la relación del proyecto con el proveedor, y los riesgos y las
condiciones de mercado actuales; asegurar que todas las partes del acuerdo con el
proveedor comprenden y aceptan todos los requisitos antes de implementar el acuerdo o
cualquier cambio; modificar el acuerdo con el proveedor, según sea necesario; y con
modificar los planes y compromisos del proyecto, para reflejar el acuerdo con el proveedor.
 Casi siempre se satisfacen los acuerdos con el proveedor ya que frecuentemente: se realiza
las actividades con el proveedor tal y como se especifica en el acuerdo con el proveedor;
se asegura que el acuerdo con el proveedor se cumple antes de aceptar el producto; y se
segura la transición de los productos adquiridos del proveedor.
141
 No se tiene institucionalizado un proceso definido, lo cual se refleja en la falta de

recopilación de experiencias relativas al proceso de Acuerdo de proveedores procedentes
de la planificación y realización del proceso para dar soporte al uso futuro y a la mejora de
los procesos y de los activos de proceso de la organización.
 No se tiene institucionalizado un proceso gestionado, lo cual se refleja por ejemplo en la

falta de un plan para realizar el proceso de Acuerdo de proveedores o para proveer de los
recursos necesarios para realizarlo; asimismo, no se controla los productos de trabajo ni se
identificar o involucrar a las partes interesadas relevantes.
142
e. Gestión de Configuración
El propósito de la Gestión de Configuración (CM) es establecer y mantener la integridad de los

productos de trabajo utilizando la identificación de la configuración, el control de la configuración,
el informe del estado de la configuración y las auditorías de la configuración.
 SG1: Establecer las líneas base. Se establecen las líneas base de los productos de trabajo
identificados.
 SG2: Establecer un sistema de gestión de configuración. Establecer y mantener un sistema

de gestión de configuración y de gestión de cambios para controlar los productos de trabajo.
 SG3: Crear o liberar las líneas base. Crear o liberar las líneas base para uso interno y para
la entrega al cliente.
C. Oportunidades de mejora:
 No siempre se identifican los elementos de configuración, los componentes, y los

productos de trabajo relacionados que serán puestos bajo gestión de configuración, lo cual
se refleja en que no son prácticas constantes: seleccionar los elementos de configuración y
los productos de trabajo que los componen, basándose en criterios documentados;
especificar las características importantes de cada elemento de configuración, así como su
propietario y su relación con otros elementos.
 No siempre se utiliza o mantiene el sistema de gestión de configuración y de gestión de

cambios para controlar los productos de trabajo, ya que no siempre: se almacena y recupera
los elementos de configuración en un sistema de gestión de configuración; se almacena y
recupera versiones archivadas de elementos de configuración, así como tampoco se crean
informes de gestión de configuración a partir del sistema de gestión de configuración.
143
 No siempre se crea o libera las líneas base para uso interno y para la entrega al cliente, ya
que existen casos en los que no se obtiene la autorización del Comité de Control de
Configuración (CCB) antes de crear o liberar las líneas base de elementos de configuración,
así como tampoco es frecuente que se documente el conjunto de elementos de
configuración que están contenidos en una línea base.
 No siempre se sigue las peticiones de cambio a los elementos de configuración, ya que no

siempre se inicia y registra las peticiones de cambio en la base de datos de peticiones de
cambio, ni se analiza el impacto de los cambios y correcciones propuestas, así como
tampoco se clasifica, prioriza y sigue el estado de las peticiones.
 No siempre se controla los cambios a los elementos de configuración ni se obtiene la

autorización apropiada antes que los elementos de configuración modificados sean
introducidos en el sistema de gestión de configuración. Así como también es poco
frecuente que se realice revisiones para asegurar que los cambios no hayan causado efectos
no deseados en las líneas base.
 No siempre se registra las acciones de gestión de configuración con suficiente detalle para
que se conozca el contenido y el estado de cada elemento de configuración, y para que se
puedan recuperar versiones anteriores.
 No siempre se asegura que las partes interesadas relevantes tengan acceso y conocimiento
del estado de configuración de los elementos de configuración.
 No siempre se identifica la versión de los elementos de configuración que constituyen una

línea base particular, ni se describe las diferencias entre líneas bases sucesivas.
 No siempre se realiza auditorías de configuración para mantener la integridad de las líneas

base, ya que no es frecuente que: se revise la estructura y la integridad de los elementos en
el sistema de gestión de configuración; se confirme que los elementos en el sistema de
gestión de configuración son completos, correctos y consistentes; así como tampoco se
confirma el cumplimiento con los estándares y procedimientos aplicables de gestión de
configuración.
 No siempre se garantiza la institucionalización de un proceso gestionado, lo cual se refleja

por ejemplo en la falta de un plan para realizar el proceso de Gestión de configuración o
144
para proveer de los recursos necesarios para realizarlo; asimismo, no se controla los
productos de trabajo ni se identificar o involucrar a las partes interesadas relevantes.
 No se tiene institucionalizado un proceso gestionado, lo cual se refleja por ejemplo en la

falta de un plan para realizar el proceso de Gestión de configuración o para proveer de los
recursos necesarios para realizarlo; asimismo, no se controla los productos de trabajo ni se
identificar o involucrar a las partes interesadas relevantes.
D. Resultados de la evaluación:
145
f. Medición y Análisis
El propósito de Medición y Análisis (MA) es desarrollar y mantener la capacidad de medición

utilizada para dar soporte a las necesidades de información de la gerencia.
 SG1: Alinear las actividades de medición ya análisis. Los objetivos y las actividades de
medición están alineados con las necesidades de información y los objetivos identificados.
 SG2: Proporcionar los resultados de la medición. Se proporcionan los resultados de la

medición que tratan las necesidades de información y los objetivos identificados.
C. Fortalezas:
 Casi siempre se documenta, prioriza o revisa las necesidades de información y los

objetivos. Es frecuente la trazabilidad y realimentación para refinar y clarificar las
necesidades de información y los objetivos.
 Casi siempre se identifican las medidas candidatas en base a los objetivos de medición
documentados. Además, casi siempre se especifican las definiciones operativas para las
medidas, se priorizan, revisan y actualizan las medidas.
146
 Casi siempre se especifican los procedimientos de recogida y de almacenamiento de datos,
ya que se: identifica las fuentes de datos existentes que se generan a partir de los productos
de trabajo, los procesos o las transacciones actuales; identifica las medidas para las que se
necesitan datos que no se encuentren disponibles en la actualidad; priorizan, revisar y
actualizar los procedimientos de recogida y de almacenamiento de datos.
 Casi siempre se especifican los procedimientos de análisis; ya que casi siempre se cumple
con: especificar y priorizar los análisis a realizar y los informes a preparar; seleccionar los
métodos y las herramientas apropiados de análisis de datos; especificar los procedimientos
administrativos para el análisis de los datos y comunicar los resultados; revisar y actualizar
el contenido y el formato propuesto de los análisis e informes especificados; y especificar
los criterios para evaluar la utilidad de los resultados de análisis y para evaluar el
comportamiento de las actividades de medición y análisis.
 Casi siempre se obtienen los datos para las medidas base y las medidas generadas.
Asimismo, es frecuente que se realicen las comprobaciones de integridad de datos lo más
cerca posible a la fuente de los mismos.
 Casi siempre se llevan a cabo los análisis iniciales, interpretación de los resultados y
perfilar las conclusiones preliminares. Lo cual se evidencia porque se revisa los resultados
iniciales con las partes interesadas relevantes y se refinan los criterios para análisis futuros.
 Casi siempre se revisan los datos para asegurar que sean completos, íntegros, precisos y
actuales; así mismo es una actividad constante dejar disponibles los contenidos
almacenados para uso exclusivo de grupos y miembros del personal apropiados; ni se
previene que la información almacenada sea utilizada inapropiadamente.
 Casi siempre se mantiene informados oportunamente a las partes interesadas relevantes de

los resultados de la medición y se les ayuda a entender los resultados.
 Casi siempre se cumple la institución de un proceso definido, lo cual se refleja en la

recopilación de experiencias relativas al proceso de Medición y análisis procedentes de la
planificación y realización del proceso para dar soporte al uso futuro y a la mejora de los
procesos y de los activos de proceso de la organización.
147
 Casi siempre se cumple la institución de un proceso gestionado, lo cual se refleja por
ejemplo en la falta de un plan para realizar el proceso de Medición y análisis o para proveer
de los recursos necesarios para realizarlo; asimismo, se controla los productos de trabajo y
se identificar e involucrar a las partes interesadas relevantes.
g. 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.
148
 SG1: Evaluar objetivamente los procesos de producto y de trabajo. Se evalúa objetivamente

la adherencia de los procesos realizados y de los productos de trabajo asociados a las
descripciones de proceso, estándares y procedimientos aplicables.
 SG2: Proporcionar una visión objetiva. Las no conformidades se siguen y comunican de

forma objetiva, y se asegura su resolución.
C. Fortalezas:
 Casi siempre se evalúa objetivamente los procesos realizados seleccionados frente a las
descripciones de proceso, estándares y procedimientos aplicables. Se define una
descripción de la cadena informativa de aseguramiento de la calidad y cómo ello asegura
la objetividad. Ejemplos de esta falencia se evidencia en que no siempre: se promueve un
entorno que incentive la participación del personal en la identificación y comunicación de
las cuestiones de calidad; se establece y mantiene criterios claramente indicados para las
evaluaciones; se Utilizar los criterios indicados para evaluar la adherencia de los procesos
realizados y seleccionados frente a las descripciones de proceso, estándares y
procedimientos.
 Casi siempre se evalúa objetivamente los productos de trabajo seleccionados frente a las
descripciones de proceso, estándares y procedimientos aplicables.
 Casi siempre se comunica y resuelve las no conformidades, lo cual se refleja en que se

evidencia que: se documenta las no conformidades cuando no se puedan resolverse en el
proyecto; e revisa periódicamente las no conformidades abiertas y las tendencias con el
gerente designado para recibir las no conformidades y actuar sobre ellas.
 Casi siempre se registran las actividades de aseguramiento de la calidad del proceso y del
producto con suficiente detalle, de forma que sean conocidos el estado y los resultados.
149
 Casi siempre se cumple la institución de un proceso definido, lo cual se refleja en la
recopilación de experiencias relativas al proceso de Aseguramiento de la calidad y del
producto procedentes de la planificación y realización del proceso para dar soporte al uso
futuro y a la mejora de los procesos y de los activos de proceso de la organización.
 Casi siempre se cumple la institución de un proceso gestionado, se refleja en el plan para

realizar el proceso de Aseguramiento de calidad y del producto o para proveer de los
recursos necesarios para realizarlo; asimismo, se controla los productos de trabajo y se
identifica o involucra a las partes interesadas relevantes.
3. Resumen de resultados
A continuación, se presenta los reportes finales de la evaluación de todas las prácticas de los
procesos de nivel de madurez 2 de CMMI-DEV.
150
Metas Genéricas
Metas Específicas
151
ID Requerimiento
ID´s Necesarios
Asociados
Suposiciones Técnicas y/o

Necesidades del cliente
Matriz de Trazabilidad de Requerimientos
Descripción del
Requerimiento
Estado
Componentes del Sistema

Asociados
Módulos de Software
Anexo 4: Plantillas de gestión de requisitos
Asociados
Implementado
Implementado En
Números de Casos de
Anexo 4.1: Plantillas de matriz de trazabilidad de requisitos
Pruebas Relacionadas
152
Comentarios
Anexo 4.2: Plantillas de especificación de requisitos
Especificación de Requerimientos
[Nombre del proyecto]
[Versión]
153
Historia del documento
Fecha Versión Descripción Elaborado por Aprobado por
154
Especificación de Requerimientos
Introducción
El presente documento muestra las necesidades identificadas durante el levantamiento de

información de la revisión de las solicitudes realizadas por [persona o área solicitante] para la
implementación del [nombre del proyecto].
Problemas
Ítem Descripción
Necesidades Identificadas
Ítem Descripción Problema
Características
Ítem Descripción Necesidad
Requerimientos Funcionales
Ítem Descripción Característica
Requerimientos No Funcionales
155
Ítem Descripción
Especificación por Requerimiento
[Código de Requerimiento]: [Descripción breve del requerimiento]
Casos de uso identificados
Paquete Caso de Uso
Distribución de Requerimiento por Casos de Uso Identificado
Paquete Caso de Uso Requerimiento
156
Anexo 5: Plantillas de planificación del proyecto
Anexo 5.1: Plantilla de plan de gestión de alcance
NOMBRE DEL PROYECTO:
CÓDIGO DEL PROYECTO:
DIRECTOR DEL PROYECTO:
FECHA DE ELABORACIÓN:
HISTORIAL DE VERSIONES
FECHA Y HORA N° DE DESCRIPCIÓN ELABORADO POR
VERSIÓN
PROPÓSITO DEL PLAN DE GESTIÓN DEL ALCANCE DEL PROYECTO
¿Cuál es el objetivo de este documento?
DESARROLLO DEL ENUNCIADO DEL ALCANCE DEL PROYECTO
157
ESTRUCTURA DE LA EDT / WBS
DICCIONARIO DE LA EDT / WBS
MANTENIMIENTO DE LA LÍNEA BASE DEL ALCANCE
158
CAMBIOS AL ALCANCE DEL PROYECTO
ACEPTACIÓN DE LOS ENTREGABLES
INTEGRACIÓN DE LOS REQUISITOS Y EL ALCANCE
159
CONTROL DEL ALCANCE
APROBACIÓN
Nombre Cargo Firma Fecha
Iniciador/Patrocinador del
Proyecto
Director del Proyecto
160
Anexo 5.2: Plantilla de plan de gestión de requisitos

FECHA Y HORA N° DE VERSIÓN DESCRIPCIÓN ELABORADO POR
PROPÓSITO DEL PLAN DE GESTIÓN DE REQUISITOS DEL PROYECTO
ACOPIO DE LOS REQUISITOS
ANÁLISIS DE LOS REQUISITOS
161
CLASIFICACIÓN DE LOS REQUISITOS
DOCUMENTACIÓN DE LOS REQUISITOS
PRIORIZACIÓN DE LOS REQUISITOS
MÉTRICAS DE LOS REQUISITOS
VALIDACIÓN DE LOS REQUISITOS
162
TRAZABILIDAD DE LOS REQUISITOS
INFORME DE LOS REQUISITOS
GESTIÓN DE LA CONFIGURACIÓN
APROBACIÓN
163
Iniciador/Patrocinador del
Proyecto
164
Anexo 5.3: Plantilla de enunciado del alcance del proyecto

ELABORADO POR:
PROPÓSITO DEL ENUNCIADO DEL ALCANCE DEL PROYECTO
DESCRIPCIÓN DEL ALCANCE DEL PROYECTO
165
LISTA DE ENTREGABLES DEL PROYECTO
CRITERIOS DE ACEPTACIÓN
EXCLUSIONES DEL PROYECTO
166
RESTRICCIONES DEL PROYECTO
SUPUESTOS DEL PROYECTO
167
APROBACIÓN
Firma del Director del Proyecto Firma del Iniciador/Patrocinador
Nombre del Director del Proyecto Nombre del Iniciador/Patrocinador
Fecha Fecha
168
Anexo 5.4: Plantilla de EDT
Anexo 5.5: Plantilla de estimación de horas - PERT
Anexo 5.6: Plantilla de cronograma
169
Anexo 5.7: Plantilla de gestión de proyecto
PLAN DE GESTIÓN DEL PROYECTO
[NOMBRE PROYECTO]
[Notas adicionales]
[Versión X.Y]
170
Versión Resumen Elaborado por Fecha (dd/mm/yyyy)
171
1. INTRODUCCION
[Breve descripción de la necesidad que origina el proyecto]
2. METAS Y OBJETIVOS
META
Ideal que se quiere lograr a través del proyecto.
Se escribe en términos subjetivos, no tiene que ser medible ni debe tener una especificación de tiempo.
OBJETIVO OBJETIVO ESPERADO FECHA ESPERADA
Lista de objetivos definidos para el proyecto Valor (medición) que se espera obtener del objetivo. Debe Fecha en que se espera alcanzar
ser verificado su cumplimiento de acuerdo con los criterios la medición esperada del
objetivo.
y metodología de medición.
3. ALCANCE DEL PROYECTO

a. Descripción del producto o servicio
b. Lista de entregables
172
c. Supuestos del proyecto
SUPUESTOS DESCRIPCION
Lista de aspectos (variables) que afectan el proyecto. Valores, situaciones o circunstancias determinadas para las
Algunos ejemplos de variables son: tiempo disponible,
variables como base de la planeación. (ejemplo:la disponibilidad
nivel de participación, disponibilidad de información o
documentos, etc. de los miembros del equipo es del 100%, recibiremos cada semana
un reporte de producción,...etc.)
1.
2.
3.
4.
4. GESTIÓN DEL CRONOGRAMA

Se emplearán las siguientes vistas de MS Project:
 Diagrama de Gantt, Hitos
 Diagrama de Gantt, Entrada
 Diagrama de Gantt, Resumen
 Diagrama de Gantt, Trabajo
 Uso de tareas
 Uso de recursos
Diagrama de Gantt
173
Id EDT Nombre de tarea Pred Recursos Trabajo Duración Comienzo
may '06 28 may
L MX J V S D L MX
0 0 PROYECTO 24 horas 3 días mar 23/05/06
1 1 ENTREGABLE 24 horas 3 días mar 23/05/06
2 Actividad 1 Recurso A 8 horas 1 día mar 23/05/06 Recurso A
3 Actividad 2 2 Recurso B 8 horas 1 día mié 24/05/06 Recurso B
4 Actividad 3 3 Recurso C 8 horas 1 día jue 25/05/06 Recurso C
5. GESTIÓN DEL RECURSOS HUMANOS
6. GESTIÓN DE COSTOS
7. GESTIÓN DE LAS INTERESADOS
Interesado Nivel de influencia Nivel de interés esperado
8. GESTIÓN DEL RIESGOS

ESTIMACIÓN ESTIMACIÓN DEL PROB X TIPO DE
COD. RIESGO DISPARADOR DEL EVENTO / TRIGGER RESPUESTA PLANIFICADA RESPONSABLE
PROBABILIDAD IMPACTO IMPACTO RESPUESTA
Leyenda:
PROBABILIDAD VALOR IMPACTO VALOR

Muy improbable 0,1 Muy bajo 0,05
Relativamente probable 0,3 Bajo 0,1
Probable 0,5 Moderado 0,2
Muy probable 0,7 Alto 0,4
Casi certeza 0,9 Muy alto 0,8
174
Anexo 5.7: Plantilla de aceptación de proyecto (kick off)

[Declaración de aceptación proyecto]
APROBACIÓN

Iniciador/Patrocinador del Proyecto
175
Anexo 6: Plantillas de monitorización y control del proyecto
Anexo 6.1: Plantillas avance del proyecto
DOCUMENTO PARA MONITORIZACIÓN
Y CONTROL DE PROYECTOS
[Nombre del proyecto]

El presente documento contiene las plantillas para realizar la
Monitorización y control de proyectos
[Versión]
<<La plantilla de avance del proyecto tiene como objetivo reportar semanalmente el estado real
del proyecto y evaluarlo con lo planificado para detectar desviaciones significativas>>
176
1.0 Versión inicial
177
A. Estado general del proyecto:
<<En esta sección se muestra una vista general del avance del proyecto y en semáforo el estado>>
Proyecto: <<Código ‐ Nombre del proyecto>>
Cliente: <<Nombre del cliente>> Rendimiento del proyecto (SPI – CPI)
Jefe de proyecto: <<Nombre del JP>> Fecha reporte: <<DD/MM/YYYY>>
Horas planificadas Horas consumidas Desviación Presupuestado Ejecutado Desviación

0 0 S/. ‐ S/. ‐ S/. ‐
Fecha fin
Fecha inicio Fecha inicio Fecha fin Fecha fin Actividades en curso Desviación
Etapa Desviación estimada
estimada real estimada real
0.00%
0.00% 0.00%
0.00% 0.00%
0.00% 0.00%
0.00% 0.00%
0.00% 0.00%
(*) Etapas: Análisis/ diseño / construcción / pruebas / producción
Fecha fin Fecha inicio
Actividades cerradas Próximas actividades
real estimada
Leyenda: >95% > 85% < 95% <= 85%
B. Estado de actividades:
<<Para conocer el detalle del avance de las actividades culminadas: en esta sección se detallan las
desviaciones en tiempo y costo por actividad>>
Planificado Real Desviaciones

N° Actividades
Fecha inicio Fecha fin Horas Costo Fecha inicio Fecha fin Horas Costo Horas Costo
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
0 0
No considerar los hitos Totales 0 0
178
C. Estado de hitos – Línea Base 1
<<Sección para detectar desviaciones en los hitos del proyecto por fase>>
Fecha
Hitos Establecidos Fecha Objetivo Fecha Real
Reprogramada
Fase I
Fase II
Fase III
Fecha Fin
D. Estado de esfuerzo:
<<Para conocer el detalle del esfuerzo de los recursos asignados al proyecto: en esta sección se
detalla el esfuerzo de los recursos>>
Semana actual
Acumulado Total horas
Rol Nombre recurso
semana anterior % Horas Horas Total acumuladas
Asignación regulares extras semana
0
0
0
0
0
Total de esfuerzo: 0 0
Roles: (JP) jefe de proyecto / (AP) analista programador / (ARQ) arquitecto / (QA) Calidad
E. Solicitudes de cambio presentadas

<<Debe estar asociado al formato de Plantilla de control de cambios>>
N° del cambio Alcance y Objetivo Status Fecha
179
F. Riesgos de nivel de severidad Alta o Crítica
<<Debe estar asociado al formato de Plantilla de gestión de riesgos>>
Nº Descripción del Riesgo Acciones Realizadas y Pendientes Status
R01
R02
Anexo 6.2: Plantilla de gestión de riesgos

Lista de Riesgos del proyecto <<Nombre del proyecto>>
Obj. Score Tipo

Fecha Categoria Propietario del Riesgo o Riesgo
Item Riesgos Impactado Prob Imp (Prob x Trigger Respuesta al Riesgo Resp Riesgos Secundarios
identificación Riesgo (**) Responsable(s) Residual
(*) Imp) (***)
(*) Tiempo; Alcance, Costo, Calidad
(**) Técnico, Externo; Organización, Dirección de proyectos
(***) Evitar; Mitigar; Transferir; Aceptar
Nota: score mayor a 50 es de color rojo.
Anexo 6.3: Plantilla de gestión de datos

Proyecto: <<Nombre del proyecto>>
Protección Roles de acceso
Fecha Fecha última Tiempo de Medio y lugar (Ej. Responsable de (L: Lectura / E: Escritura)
Proceso NombreRegistro Recuperación
creación Modificación conservación de archivo Contraseña, conservación
firewall)
GP LP ED ET EC
Roles de acceso: GP: gerente de proyecto, LP: lider de proyecto, ED: equipo de desarrollo, ET: equipo técnico, EC: equipo de calidad
180
Anexo 6.4: Plantilla de matriz de interesados
Proyecto: <<Nombre del proyecto>>
Organización Nombres y apellidos Cargo Teléfono 1 Teléfono 2 email
Nivel de interés Nivel de interés Seguimiento

Riesgo
deseado actual Fecha Observación Acción Responsable Estado
Organización Nombres y apellidos Cargo Teléfono 1 Teléfono 2 email
Nivel de interés Nivel de interés Seguimiento

Riesgo
deseado actual Fecha Observación Acción Responsable Estado
Nivel de interés: I: indiferente; R: resistente; N: neutral ; A: de apoyo; L: líder
Anexo 6.5: Plantilla de control de cambios

Cambio No: Unidad de negocio:
Solicitante: Nombre de proyecto:
Fecha de solicitud de cambio: Gerente de Proyecto:
Urgencia del cambio: (en la semana, durante el mes, Administrador del cambio: (puede ser una persona a
etc) la que se le delega su administración)
Descripción del cambio:
Justificación del cambio:
Beneficios del cambio:
Impacto en el Proyecto: Costos del cambio: (estimado de los costos de recursos

Tiempo humanos y otros que se incurriría por el cambio)
Alcance
Calidad
181
Requiere aprobación adicional de fondos
Impacto en los procesos de negocio: Costos de no hacerlo: (impacto económico Ej. Multa,
pérdida de negocios, que se tendría por no hacer el
cambio)
Documentación de sustento: (documentos, gráficos y otros que servirían para detallar el requerimiento adicional)
Sección de aprobación
Rol Firma
Solicitante
Gerente de proyecto
Patrocinador
Anexo 6.6: Plantilla de gestión de problemas

Listado de problemas del proyecto: <<Nombre del proyecto>>
Fecha
Descripción del problema (colocar Fase del Criticidad Fecha Fecha
N° Estado (*) Impacto en el proyecto Identificado por Asigando a estim.
links a documentos de ser necesario) proceso (**) apertura cierre
cierre
(*) Abierto / Asignado / En revisión / Cerrado
(**) Rojo: Alta / Amarillo: Media / Verde: Baja
182
Anexo 7: Manual de procesos
MANUAL DE PROCESOS
Implantación de mejora de procesos
Los nuevos procesos propuestos están basados en el modelo de madurez CMMI
Gestión de requisitos - Planificación del proyecto - Seguimiento y control
Versión 1.0
183
1.0 Versión inicial María Carranza 10/05/21018
184
1. POLÍTICAS
Gestión de requisitos:
 Todo documento de requisitos deberá identificar claramente los responsables de los
requerimientos en el equipo del cliente.
 En el documento de requisitos se debe indicar el alcance de cada requerimiento y lo que no
será considerado. Asimismo, se debe identificar claramente los canales de comunicación
para la recepción, levantamiento y aprobación de los requerimientos.
 Se mantiene, registra y evalúa los cambios que se realizan a los requisitos.
 El documento de requisitos y los controles de cambio a los requisitos deberán ser
almacenados en el repositorio institucional.
Planificación del proyecto:

 El Gerente de Proyecto es el responsable de gestionar la planificación de proyectos.
 La persona autorizada para realizar actualizaciones a los documentos generados durante la
planificación es el Gerente de Proyecto.
 La documentación y plantillas de la planificación del proyecto deberá guardarse en el
repositorio institucional y deberá ser compartida a los integrantes del equipo de proyecto.
Seguimiento y control de proyectos:

 El Gerente de Proyecto es el responsable de gestionar la monitorización y seguimiento de
los proyectos.
 La documentación y plantillas generadas durante el proceso de monitorización y
seguimiento de proyectos será almacenada en el repositorio institucional.
 Los indicadores generados durante el proceso deberán ser revisados y comunicados en un
comité a los todos los interesados del proyecto.
 Los riesgos del proyecto serán monitoreados en las reuniones de seguimiento del plan,
basándose en la matriz de riesgos del plan de proyecto.
185
2. CARACTERIZACIÓN DE PROCESOS
Gestión de requisitos
Objetivo del Revisar los requerimientos solicitados por el usuario (cliente), indicando
proceso su factibilidad y proporcionar las correspondientes observaciones técnicas
y su impacto en el negocio. Incrementar la eficiencia en la gestión de
proyectos al proporcionar los lineamientos correspondientes que
asegurará reducir en forma considerable los re-trabajos y su consecuencia
en los costos asociados.
Actividades de  Se debe garantizar la disponibilidad de los usuarios claves para

planificación realizar el levantamiento de requisitos.
 Se debe garantizar el respaldo de la Gerencia del usuario solicitante.
 Se debe verificar la disponibilidad de los recursos asignados para el

proceso.


CMMI-
DEV
Analizar lista de Recibir lista de Jefe de - SP 1.1

requerimientos requerimientos por parte Proyecto
de los usuarios.
Realizar revisión
preliminar de los
requerimientos.
Identificar Identificar los Jefe de - SP 1.1

problemas, problemas que se Proyecto SP 1.5
necesidades y desprenden a partir de
características
186
los requerimientos de
usuario.
Identificar las
necesidades de los
usuarios a partir de los
problemas
identificados.
Identificar las
características de la
solución a partir de las
necesidades de los
usuarios identificadas.
Describir los
requerimientos
funcionales y no
funcionales para abordar
las características de la
solución.
Elaborar Matriz de Identificar dependencias Jefe de Matriz de SP 1.4

Trazabilidad entre los requerimientos Proyecto trazabilidad de
analizados. requisitos (ver
Anexo 4.1)
Elaborar Documento Consolidar el listado de Jefe de Plantilla – SP 1.5

de Especificación de problemas, de las proyecto Especificación
Requerimientos necesidades, los de
problemas y los Requerimientos
requerimientos (ver Anexo 4.2)
funcionales y no
funcionales.
187
Detallar a alto nivel los
requerimientos
funcionales
Realizar inducción Presentar al analista de Jefe de - SP 1.2

de requerimientos calidad los proyecto SP 1.3
requerimientos
analizados
Revisar documento Presentar al usuario Analista de - SP 1.2

de requisitos líder el resultado del Calidad SP 1.3
análisis de los
Usuario
requerimientos. Líder
Responsable del seguimiento del proceso
Gerente del proyecto – Jefe de proyecto
Indicadores de seguimiento de requisitos y Indicadores de gestión de cambios.

su trazabilidad.

Objetivo del Elaborar el plan de proyecto con la finalidad de asegurar la calidad e
proceso integridad de las aplicaciones nuevas o actualizadas que son desarrolladas
por el área de Desarrollo.
Actividades de  El Administrador del Proyecto debe designar al Jefe de Proyectos.

planificación
 Se debe asegurar los accesos a la carpeta del proyecto al Jefe de
Proyecto.

comprender el manual de proceso y las plantillas requeridas.
188
CMMI-
DEV
Crear repositorio de Crear repositorio para el Administrador Estructura SP 2.3

proyecto almacenamiento de los de Proyectos base para la
artefactos del proyecto creación de
repositorios
de
proyectos
Elaborar el Plan de Definir el proceso para la Jefe de Plantilla SP 2.7

Gestión del elaboración del enunciado Proyecto para el plan
Alcance del proyecto. de gestión
Definir el proceso para la de alcance

(ver Anexo
creación y aprobación del
EDT. 5.1)
Definir el proceso para la

obtención de la aceptación
de los entregables
terminados.
Definir el proceso para

controlar las solicitudes de
cambio.
Elaborar el Plan de Definir la planificación, la Jefe de Plantilla SP 2.7

Gestión de monitorización y el Proyecto para el plan
Requisitos reporte de las actividades de gestión
asociadas a los requisitos. de
requisitos
189
Definir los procesos para (ver Anexo
ejecutar las solicitudes de 5.2)
cambio en los requisitos.
Definir los criterios para la

priorización de requisitos.
Definir las métricas con

las que se medirá el
producto.
Elaborar el Describir el alcance del Jefe de Plantilla - SP 1.1

Enunciado del producto. Proyecto Enunciado
Proyecto / Alcance del alcance
Indicar los criterios de
aceptación de los (ver Anexo
5.3)
entregables.
Indicar los entregables del

proyecto.
Indicar las exclusiones,

restricciones y los
supuestos a considerar en
el proyecto.
Elaborar EDT Identificar y agrupar los Jefe de Formato de SP 1.1

entregables para el Proyecto EDT (ver
SP 1.3
proyecto Anexo 5.4)
Generar estimación Estimar las horas para el Jefe de Formato de SP 1.2

de horas (gestión y desarrollo del producto. Proyecto Estimación SP 1.4
producto) de Horas
Estimar las horas de
gestión del proyecto. (PERT) (ver
Anexo 5.5)
190
Generar estimación Estimar las horas para la Analista de Formato de SP 1.2
de horas de pruebas ejecución de las pruebas Calidad Estimación
de control de calidad. de Horas
(PERT) (ver
Anexo 5.5)
Analizar Revisar cuadro de Administrador - SP 1.2

disponibilidad de disponibilidad de recursos de Proyectos SP 1.4
recursos para identificar fechas de
liberación o disminución
de carga
Asignar personal al Asignar al equipo de Administrador - SP 2.4

proyecto proyecto según las de Proyectos
SP 2.5
funciones requeridas en el
SP 3.1
plan y en función al
cuadro de disponibilidad. SP 3.2
Elaborar Generar listado de Jefe de Plantilla de SP 1.2

cronograma actividades a partir del Proyecto Cronograma SP 1.4
EDT (ver Anexo
Secuenciar las 5.6)
actividades.
Asignar recursos a las

actividades.
Asignar el esfuerzo a cada

actividad por recurso.
Revisar Verificar si los Analista de - SP 3.3

Cronograma entregables y fechas de Calidad
entrega corresponden a lo Usuario Líder
acordado
191
Elaborar planes de Elaborar el plan de gestión Jefe de Plantilla - SP 1.1
gestión de tiempo. Proyecto Plan de
SP 1.2
Elaborar el plan de gestión proyecto
SP 1.3
(ver Anexo
de costos.
5.7) SP 1.4
Elaborar el plan de gestión
SP 2.1
de calidad
SP 2.2
Elaborar el plan de gestión
de comunicaciones SP 2.3

de riesgos. SP 2.5
SP 2.6
SP 2.7
SP 3.3
Generar el KICK- Presentar al usuario líder Jefe de Plantilla – SP 3.3

OFF del proyecto el plan de gestión de Proyecto Aceptación
alcance. de Proyecto
(KICK
OFF) (ver
Anexo 5.8)
Gerente del proyecto – Jefe de proyecto
Cantidad de ajuste a los cronogramas Cantidad de proyecto que tuvieron KICK-OFF

posterior a revisiones.
Cantidad de rechazos del Project Charter por

tema de costos.
192
Objetivo del Realizar el monitoreo y control de los parámetros del proyecto (atributos
proceso de los productos de trabajo y tareas; costes y esfuerzo; y tiempo), riesgos
y otros parámetros del proyecto (datos, compromisos e hitos) para
identificar problemas en el progreso del proyecto y poder tomar acciones
correctivas inmediatas.
Actividades de  El Jefe de proyecto deberá tener los accesos a los documentos

planificación necesarios para realizar el proceso.


CMMI-DEV
Monitorizar el plan Revisar los atributos de los Jefe de Avance del SP 1.1
de proyecto productos de trabajo y proyecto proyecto SP 1.6
tareas. (ver Anexo
SP 1.7
Revisar el coste y esfuerzo. 6.1)
SP 2.1
Revisar el progreso frente
al calendario e identificar
el avance de los hitos.
Mensualmente realizar el
reporte de avance del
proyecto.
Identificar y analizar los

problemas en los
parámetros de
planificación de proyectos.
193
Monitorizar los Revisar estado de los Jefe de Gestión de SP 1.3
riesgos riesgos. proyecto riesgos (ver
SP 2.1
Actualizar documento de Anexo 6.2)
riesgos.
Monitorizar Realizar la gestión de Jefe de Gestión de SP 1.4

documentos y datos. proyecto datos (ver SP 1.5
compromisos del Realizar el seguimiento a Anexo 6.3)
SP 1.2
proyecto los compromisos y la Matriz de
SP 2.1
involucración de los interesados
interesados. (ver Anexo
6.4)
Evaluar control de Documentar y gestionar Jefe de Plantilla de SP 2.1

cambio controles de cambios de proyecto control de
ser necesario. cambios
(ver Anexo
6.5)
Realizar acciones Identificar y realizar Jefe de Lista de SP 2.2

correctivas acciones correctivas a los proyecto problemas
SP 2.3
problemas identificados. (ver Anexo
6.6)
Generar informes y Generar reporte de Jefe de Avance del SP 1.6

actualizar progreso y rendimiento. proyecto proyecto SP 2.3
indicadores Actualizar cuadro (ver Anexo
integrado de control de 6.1)
proyectos. Indicadores
Actualizar documento de del

proyecto
lecciones aprendidas.
194
Jefe de proyecto
Rendimiento del proyecto. Indicador de desviación de horas programadas.
Rendimiento del cronograma (SPI) Indicador de desviación del presupuesto.
Rendimiento de costos (CPI) Desviaciones a los hitos del proyecto.
Porcentaje de avance por etapa del proyecto. Indicador de seguimiento de problemas.
195
3. DIAGRAMAS DE PROCESOS
Gestión de requisitos
196
197
4. GESTIÓN DE LA CONFIGURACIÓN
Todos los documentos generados durante los procesos de gestión de requisitos, planificación
del proyecto y seguimiento y control de proyectos deberá tener una sección de control de
versiones según el siguiente formato:
Además, el nombre de los documentos tendrá el siguiente formato:

<Área propietaria>- <Código del proyecto>-<Nombre corto del documento>-<Versión>.
Donde:
 Área propietaria: SIS
 Código del proyecto: PROY#### (#número en formato 0000)
 Nombre corto del proyecto: por ejemplo: ACTA, PLAN, CTRC, LPRO (según
plantillas)
 Versión: por ejemplo: v1.0
198
5. INTERESADOS
Proceso Interesados
Gestión de requisitos Cliente solicitante
Planificación del proyecto Gerente el proyecto y Jefe de proyecto
Seguimiento y control de proyectos Gerente el proyecto y Jefe de proyecto
6. RECURSOS
Los procesos de gestión de requisitos, planificación de proyectos y seguimiento y control de
proyectos tienen como principal recurso al Jefe de Proyecto. Por lo tanto, se tiene que asegurar
que el personal que cumpla dicha función tenga experiencia comprobada en gestión de proyectos.
De ser necesario se deberá capacitar al personal en las siguientes habilidades técnicas:
 Seguimiento y control de proyectos
 Gestión de riesgos del proyecto
 Gestión y elaboración de cronogramas
 Gestión y elaboración de presupuestos
Asimismo, se requiere capacitación en habilidades de blandas como:
 Negociación
 Gestión de conflictos
 Habilidades de comunicación
 Liderazgo
7. AUDITORÍAS
Las auditorías tienen el objetivo de evaluar el nivel de madurez de los procesos, según lo propuesto
por el modelo CMMI. Se consideran dos tipos de auditorías:
Tipo auditoría Características
Interna Serán desarrolladas por personal de la organización con experiencia en
auditoría y mejora de procesos, además deberán tener conocimientos de
gestión de proyectos de software.
199
El equipo seleccionado no podrá evaluar proyectos en los cuales haya
participado directa o indirectamente.
Los resultados de la auditoría son confidenciales y deberán ser
comunicadas al Gerente del Departamento de Sistemas.
La selección de los proyectos estará a cargo del Gerente de Sistemas.
Externa Serán desarrollas por un equipo externo a la organización especializado
en auditoría de procesos, con certificaciones que respalden sus
habilidades y conocimientos.
No necesariamente será realizado por un certificador SCAMPI.
200
Anexo 8: Plan de gestión del proyecto de mejora
PLAN DE GESTIÓN DE PROYECTO
MEJORA DE PROCESOS
El presente documento presenta el plan de gestión del proyecto de
Mejora de procesos basada en CMMI-DEV 1.3
Versión 1.0
201
1.0 Versión inicial María Carranza 04/05/2018
202
1. INTRODUCCION
El proyecto surge de la necesidad de reducir las brechas identificadas en la evaluación de procesos

basados en CMMI-DEV, ya que dichas deficiencias están generando pérdidas económicas a la
organización e impactando en sus objetivos estratégicos.
2. METAS Y OBJETIVOS
META
La meta del proyecto es realizar las acciones necesarias para mejorar los procesos de gestión de
proyectos que tienen oportunidades de mejora según lo identificado en la evaluación inicial. Dichos
procesos incluyen: la gestión de requisitos, planificación de proyecto, así como, monitorización y
OBJETIVO OBJETIVO ESPERADO FECHA ESPERADA
Contar con documentación de Documentación inicial y final al 100% Al tercer mese luego
procesos relacionados a la gestión de planificación de proyectos, gestión de iniciado el
de proyectos que requieran de proyecto.
de requisitos y de monitorización y
mejoras. Los nuevos procesos
estarán basados en el modelo de control.
CMMI-DEV.
Implementar dos proyectos pilotos Desarrollar al 100% dos ciclos de Al segundo mes.
para asegurar la correcta ejecución prueba.
y beneficio de los nuevos
procesos.
La empresa debe contar con un Incluir en el organigrama del Al tercer mes.
equipo capacitado en la mejora de Departamento de Sistemas al equipo de
proceso para realizar seguimiento mejora de procesos.
y controlar los nuevos procesos
implementados.
203
3. ALCANCE DEL PROYECTO
a. Descripción del producto
El alcance del proyecto incluye los procesos de gestión de requisitos, planificación de
proyectos, así como para la monitorización y control del proyecto, para dichos procesos
se realiza la adecuación y difusión de nuevos procesos basados en el modelo de CMMI-
DEV, la ejecución de proyectos pilotos y la puesta en marcha de un equipo para
asegurar la mejora de los procesos.
b. Lista de entregables
Documentos de Documentos con las Documentos en Al tercer mes
procesos . descripciones de los procesos formato definido
a mejorar. por el Manual de
procesos utilizado
por la organización.
Capacitaciones Control de asistencias de las Lista revisada y Durante el
capacitaciones realizadas. validad por la segundo mes.
gerencia del
Departamento de
Sistemas.
Informe de Documento con indicadores Los informes deben Durante el
seguimiento de presentado al final de cada cumplir el formato segundo mes
procesos iteración de los procesos en los desarrollado para la
proyecto piloto. monitorización y
Informe del Documento de cierre del Documentos del A fines del
proyecto proyecto. proyecto aprobados segundo mes
en el repositorio de
proyectos.
204
c. Supuestos del proyecto
SUPUESTOS DESCRIPCION
1. Tiempo disponible Disponibilidad del equipo de proyectos es al 100%.
2. Nivel de participación Los interesados serán notificados activamente del
progreso del proyecto y tendrán participación activa
en la toma de decisiones.
3. Disponibilidad de la información y Se contará con un repositorio para el proyecto en la
documentos
cual se manejarán niveles de acceso.
4. Recursos Se cuenta con un equipo con conocimientos y
experiencia en mejora de procesos.
4. GESTIÓN DEL CRONOGRAMA

El cronograma tiene tres grandes fases: Inicio del proyecto, ejecución de proyectos pilotos e
instauración de procesos de mejora. En la fase de inicio se selecciona al equipo de proyectos y los
proyectos que serán utilizados como pilotos en la siguiente fase.
En la fase de ejecución de proyectos pilotos se ha considerado dos ciclos de mejora por proceso.
Los ciclos de mejora sirven para mejorar la definición de los procesos, por lo tanto, al finalizar el
primer ciclo de mejora se realizan los ajustes necesarios a los procesos y a su respectiva
documentación, estos cambios serán considerados en el siguiente ciclo de mejora, asimismo, se
deberá capacitar al equipo de proyectos con los ajustes realizados. Al final, de los ciclos de mejora,
se consideran hitos de seguimiento de las mejoras realizadas.
En la última fase, se realiza la instauración de los procesos con las mejoras propuestas y que luego
de los pilotos han sido mejoradas, dentro de las actividades se consideran aquellas que son
necesarias para la difusión de los nuevos procesos e instauración del área de mejora.
205
206
207
4.1 Los hitos considerados son:
 Kick off del proyecto
 Mejora 10% indicadores del proyecto (Por cada proceso en el primer ciclo de mejora)
 Mejora 20% indicadores del proyecto (Por cada proceso en el segundo ciclo de mejora)
 Inicio de operaciones con los nuevos procesos
5. GESTIÓN DEL RECURSOS HUMANOS

Para la ejecución del proyecto se requerirá tres recursos con los perfiles profesionales y
asignaciones especificados en la siguiente tabla:
Puesto Cantidad Perfil Tipo de
requerida asignación
Gerente de 1 Experiencia comprobada en la gestión de Completo
aseguramiento proyectos en mejora de procesos. Mínimo 5 años
de calidad de participando en proyectos de implantación de
procesos procesos.
Conocimientos comprobada en modelos de
calidad, de preferencia CMMI-DEV.
Analista de 2 Experiencia comprobada, mínimo 2 años, en la Completo
aseguramiento gestión de calidad de procesos.
de calidad de Experiencia en proyectos de desarrollo de
procesos software.
6. GESTIÓN DE COSTOS
Para el proyecto propuesto será necesario asignar colaboradores a tiempo completo (8 horas) que
realicen el seguimiento de los proyectos pilotos y apoyen al equipo de proyectos en la ejecución
de los nuevos procesos, el equipo deberá estar compuesto un Gerente de aseguramiento de calidad
de procesos y dos Analistas de aseguramiento de calidad de procesos. El costo por hora
considerado para cada recurso es: para el perfil de Directivo de Gestión se ha considerado un costo
de US$45 y para el perfil de Analista de procesos un costo de US$17, además del equipo técnico
conformado por el personal de proyectos que tienen un costo de US$70.
208
Nombre del recurso Capacidad máx. Tasa estándar
Directivo de gestión 100% $45.00/hora
Analista de procesos de ingeniería 1 100% $17.00/hora
Analista de procesos de ingeniería 2 100% $17.00/hora
Equipo de proyectos piloto 1 100% $70.00/hora
Equipo de proyectos piloto 2 100% $70.00/hora
7. GESTIÓN DE LAS INTERESADOS
Interesado Nivel de influencia Nivel de interés esperado

Gerente General Alta Alta
Gerente de Desarrollo de Sistemas Alta Alta
Jefe de Proyecto Media Alta
Gerente de Aseguramiento de Calidad Alta Alta
Analista de Aseguramiento de Calidad Baja Baja
209
8. GESTIÓN DEL RIESGOS
ESTIMACIÓN ESTIMACIÓN DEL PROB X TIPO DE
COD. RIESGO DISPARADOR DEL EVENTO / TRIGGER RESPUESTA PLANIFICADA RESPONSABLE
PROBABILIDAD IMPACTO IMPACTO RESPUESTA
Mantener informada a la Gerencia del
Gerente de
Resistencia a apoyar el proyecto y/o ausencias avance del proyecto.
R_001 No tener el apoyo de la Gerencia General. 0,1 0,8 0,08 Mitigar Desarrollo de
en las reuniones. Establecer fechas de reuniones
Sistemas
estratégicas.
Inasistencias a las capacitaciones y/o Gestión de incentivos para el personal Gerente de
Resistencia al cambio por parte del equipo
R_002 0,5 0,4 0,2 resistencia a gestionar proyectos según nuevas asignado al ptoyecto de mejora de Mitigar Aseguramiento de
de proyectos
plantillas propuestas en los procesos procesos. Calidad
Demoras en los tiempos de contratación Demora en la entrega de fichas de candidatos Asignar personas contratadas en la Gerente de
R_003 de las personas requeridas para el 0,3 0,8 0,24 para entrevistas (fase II del manual de empresa que cumplan con el perfiel Transferir Desarrollo de
proyecto. contrataciones) establecido. Sistemas
Cambio solicitado o renuncia de alguno de los
Cambios en los equipos de proyecto de Realizar transferencia de conocimiento a
R_004 0,5 0,2 0,1 miembros del equipo de proyecto de desarrollo Aceptar Jefe de Proyecto
desarrollo piloto nuevos integrantes del proyecto.
piloto
Leyenda:
PROBABILIDAD VALOR IMPACTO VALOR
Muy improbable 0,1 Muy bajo 0,05
Relativamente probable 0,3 Bajo 0,1
Probable 0,5 Moderado 0,2
Muy probable 0,7 Alto 0,4
Casi certeza 0,9 Muy alto 0,8
210
Anexo 9: Resumen de ítems de costos y beneficios
9.1: Ítems de costos
Ítem de costo Propósito Tipo Citas
Auditoría Realización de inspecciones internas y externas con el fin e 5

de evaluar la conformidad de productos y procesos.
Calibración Disposición de equipos de medida confiables para realizar e 1

medición
Capacitación Preparación y organización de capacitaciones y p 4

entrenamientos para el personal involucrado.
Consultoría Desarrollo de actividades de apoyo para diseñar e e 2

implementar proyectos de mejora.
Diagnóstico Evaluación del grado de cumplimiento con los requisitos de e 3

la calidad.
Implementación Desarrollo de actividades, rectificación y mantenimiento de p 6

la operatividad de los procesos.
Planeación Planificación y despliegue de actividades para el desarrollo p 13

de un sistema de calidad, incluyendo diseño documental,
reorganización de procesos y disposición de otros recursos
para la puesta en marcha de un proyecto de calidad.
Nota. Ítems de costos que aplican al proyecto, donde p: costo de prevención; e: costo de
evaluación. Elaborado con información de: Torres-Navarro, C., & Callegari-Malta, N. (2016).
Criterios para cuantificar costos y beneficios en proyectos de mejora de calidad. Ingeniería
Industrial, 37(2), 151-163.
211
9.1: Ítems de beneficios
Ítem de Propósito Tipo Frecuencia
beneficio de citas
Cliente y Atracción de nuevos clientes y/o acceso a nuevos e 5

mercado mercados
Imagen de la Mejoramiento de la calidad percibida de los clientes, e 11

Empresa mejor prestigio, mayor predisposición de los clientes
Productividad Disminución del uso de recursos para realizar las i 43

mismas actividades
Reducción de Disminución de recursos económicos involucrados en e 1

reclamos el tratamiento de los reclamos, en toda la cadena
recepción- solución.
Rentabilidad Aumento de la utilidad de una organización i 7
Ventas Incremento de los ingresos por venta e 5
Nota. Ítems de beneficios que aplican al proyecto, donde i: beneficios internos; e: beneficios
externos. Elaborado con información de: Torres-Navarro, C., & Callegari-Malta, N. (2016).
Criterios para cuantificar costos y beneficios en proyectos de mejora de calidad. Ingeniería
Industrial, 37(2), 151-163.
212

Ejemplo Trabajo Tesis CMMI

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ejemplo Trabajo Tesis CMMI

Cargado por

Copyright:

Formatos disponibles

Propuesta de implantación de CMMI-

DEV 1.3 nivel de madurez 2 en una

Item Type info:eu-repo/semantics/masterThesis

Authors Carranza Liza, María Isabel; Rodríguez Solórzano, Rubén Moisés;

Citation Carranza Liza, M. I., Rodríguez Solórzano, R. M., & Valverde

Publisher Universidad Peruana de Ciencias Aplicadas (UPC)

Rights info:eu-repo/semantics/openAccess; Attribution-

Download date 07/06/2021 17:18:44

Item License http://creativecommons.org/licenses/by-nc-sa/3.0/us/

Link to Item http://hdl.handle.net/10757/624261

PROGRAMA ACADÉMICO DE MAESTRÍA EN DIRECCIÓN DE SISTEMAS

Propuesta de implantación de CMMI-DEV 1.3 nivel de

ASESOR DE TRABAJO DE INVESTIGACION

Lima, 03 de agosto del 2018

El objeto de estudio de la presente tesis es el Departamento de Sistemas de una empresa consultora

Como conclusiones, se recomienda la ejecución de la propuesta presentada para apoyar en los

Keywords: CMMI-Dev, Processes, Software, Projects

Tabla 1: Entidades asociadas a la ALETI ..................................................................................... 14

Figura 1: Estructura de la norma ISO 15504. ............................................................................... 23

El presente documento desarrolla la propuesta de implantación de CMMI-DEV 1.3 nivel de

En el segundo capítulo se presenta la problemática. La empresa seleccionada para el trabajo es una

En el tercer capítulo se desarrolla la propuesta de solución basada en el modelo CMMI-DEV, para

- Propuesta de implantación de manera iterativa los procesos de mejora, mediante la

- Elaborar el manual de procesos basados en el modelo de CMMI-DEV para aquellos

 En la tercera fase se determina como prioridad de la implantación los procesos de Gestión de

Asimismo, en el tercer capítulo se realiza la evaluación económica de la propuesta, en la cual se

En el presente capítulo se desarrolla el marco teórico, en el cual se detalla la situación actual de la

1.1 Situación actual de la industria del software en el Perú

Argentina CESSI - Cámara de Empresas de Tecnología de Información de Argentina

Bolivia CBTI - Cámara Boliviana de Tecnologías de la Información

Associação das Empresas Brasileiras de Tecnología da Informação.

Asociación Chilena de Empresas de Tecnología de Información. GECHS

Federación Colombiana de la Industria del Software y Tecnologías

Costa Rica CAMTIC

Cámara de Empresas de Tecnología de Información y Comunicaciones

Industria Cubana del Software

Asociación Ecuatoriana de Software

Asociación Mexicana de la Industria de Tecnologías de la Información

Cámara Paraguaya de la Informática y las Telecomunicaciones

La Asociación Peruana de Productores de Software

Cámara Uruguaya de Tecnologías de la Información

Cámara Venezolana de Empresas de Tecnologías de la Información

Asociación Española de Tecnologías de Información y Comunicaciones

Miranda M. (2017), presidente de APESOFT, presentó en el último foro de inteligencia y

El sector de la industria de desarrollo de software ha crecido sostenidamente a un ritmo de 15%

Tabla 2: Principales problemas para exportar software

Información de mercados y canales de comercialización 58.4

Infraestructura y equipamiento 20.9

Desconocimiento de mecanismos de exportación 20.8

Restricciones a la inversión extranjera 12.5

Disponibilidad de RRHH capacitados 12.5

Nota. Información recuperada de PROMPEX & APESOFT (2004). Situación de la industria

1.2 Modelos de mejora de los procesos de desarrollo de software

1.2.1 ISO 9001

 La capacidad para proporcionar regularmente productos y servicios que satisfagan los

 Facilitar oportunidades de aumentar la satisfacción del cliente.

 Abordar los riesgos y oportunidades asociadas con su contexto y objetivos.

Asimismo, Torres (2007) identifica otras ventajas no mencionadas anteriormente:

 Es aplicable para cualquier industria y entorno.

 Existe libertad para su implementación y para la interpretación de los requisitos.

 La norma no provee las actividades para lograr la mejora de procesos.

1.2.2 ISO 12207

 Por la organización: para evaluar la conformidad de un conjunto de procesos de ciclo de vida

En el Perú, mediante Resolución Directoral N°013.2016-INACAL/DN se aprueba la Norma