Proyecto Tesis en Gestion de Calidad de Software

FACULTAD DE INGENIERIA, ARQUITECTURA Y
URBANISMO
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA

DE SISTEMAS
INFORME DE INVESTIGACIÓN
MODELO DE GESTIÓN DE PROYECTOS Y

CONTROL DE CALIDAD EN SOFTWARE PARA
PYMEs PERUANAS DESARROLLADORAS DE
SOFTWARE
PARA LA APROBACIÓN DE LA ASIGNATURA DE

INVESTIGACIÓN II
Autor:
Jimmy André Arroyo Caballero
Línea de Investigación:
Infraestructura, tecnología y medio Ambiente

Ingeniería de Software
Pimentel - Perú
2019
1
2
DEDICATORIA
A Dios.
Por haberme permitido llegar hasta este punto y darme salud para lograr
mis metas, además de su infinito amor.
A Mis padres.
Por ser los pilares fundamentales en todo lo que he llegado a ser, en mi educación,
tanto académica, como de la vida, por su absoluto apoyo perfectamente mantenido
en todos estos años
A Mis abuelos.
Por ser mis mayores fuentes de inspiración y alegría en el trayecto de mi vida,

agradecer infinitamente por darme la alegría de tenerte aún conmigo mamita Naty
y, desde el cielo me bendigan mi mamita Virginia y mis papitos Manuel y Carlos.
A Mis amistades
Por soportar mis locuras y ocurrencias, porque siempre estuvieron ahí para mí en
los buenos y malos momentos apoyándome a lo largo de mi estancia en la
Universidad, en especial Monsalve G.
3
AGRADECIMIENTO
Le agradezco a Dios por haberme acompañado y guiado a lo largo de mi carrera, por ser mi
apoyo en los momentos de debilidad y por otorgarme una vida llena de aprendizajes,
experiencias.
Le doy gracias a mis padres Soledad y Washington por apoyarme en todo momento, por los
valores que me han brindado, y por haberme dado la oportunidad de tener una buena educación
en el transcurso de mi vida.
Agradezco a todos aquellos que han hecho posible esta tesis que con su infinito apoyo lograron
motivarme y apoyarme en mis momentos de flaqueza, Ing. Mejía, Ing. Tuesta.
André.
4
RESUMEN
La industria peruana del software ha crecido considerablemente en los últimos años,

requiriendo cada vez, productos de alta calidad. La mayoría de los expertos expresan que
la calidad se alcanza cumpliendo con todas las características solicitadas optimizando los
recursos actuales, evaluándose de forma integral. En el mercado existen muchos modelos
para guiarse con el fin de obtener productos de calidad, pero relativamente pocos son los
relacionados al producto de software haciendo hincapié en su calidad estando enfocadas
usualmente, a organizaciones de gran tamaño, por lo que la propuesta de un modelo de
gestión en el desarrollo con calidad para PYME’s resulta necesaria.
Para el desarrollo del modelo de gestión propuesto se determinó analizar los modelos
relacionados a la calidad del software como producto, así como el sector peruano de
software respecto a pequeñas y medianas empresas para poder identificar de forma efectiva
las mejores prácticas y esquematizar un modelo que cumpla con el sector, las métricas de
evaluación de producto y el aprendizaje para toda organización respecto a cada proyecto,
obteniendo un marco de trabajo adaptable a las metodologías de desarrollo que presente
cada una de ellas. El resultado, un nuevo modelo de trabajo adaptable validado por
expertos, que se adapta a las necesidades de cada organización. Por último, se propone
emplear el modelo desarrollado en una empresa desarrolladora de software y medir los
resultados cuantitativamente.
Palabras clave: calidad, software, modelo, gestión, desarrollo
5
ABSTRACT
The Peruvian software industry has grown considerably in recent years, each time
requiring high-quality products. Most experts express that quality is achieved by
complying with all the requested characteristics, optimizing current resources and
integrally evaluating them. In the market, there are many models to guide to obtain quality
products, but relatively few are related to the software product emphasizing its quality
being focused usually, large organizations, so the proposal of model management in quality
development for SMEs is necessary.
For the development of the proposed management model it was determined to analyze the
models related to software quality as a product, as well as the Peruvian software sector in
relation to small and medium-sized companies in order to effectively identify the best
practices and outline a model that complies with the sector, product evaluation metrics and
learning for every organization with respect to each project, obtaining a work framework
adaptable to the development methodologies that each of them presents. The result is a
new model of adaptive work validated by experts that adapts to the needs of each
organization. Finally, it is proposed to use the model developed in a software development
company and measure the results quantitatively.
Keywords: quality, software, model, management, development
6
INDICE GENERAL
DEDICATORIA....................................................................................................................... 3
AGRADECIMIENTO ............................................................................................................. 4
RESUMEN................................................................................................................................ 5
ABSTRACT .............................................................................................................................. 6
INDICE DE TABLAS............................................................................................................ 10
INDICE DE FIGURAS.......................................................................................................... 11
CAPITULO I: INTRODUCCIÓN ....................................................................................... 14
1.1. Planteamiento del problema. ................................................................................................................ 14
1.2. Antecedentes de estudio ........................................................................................................................ 18
1.3. Abordaje Teórico ................................................................................................................................... 22

1.3.1. Calidad ............................................................................................................................................ 22
1.3.2. Software .......................................................................................................................................... 24
1.3.3. Calidad de software ........................................................................................................................ 26
1.3.4. Modelo ............................................................................................................................................ 27
1.3.5. Modelos de Calidad de Software .................................................................................................... 57
1.3.6. Evaluación de Calidad de proyectos ............................................................................................... 87
1.4. Formulación del problema .................................................................................................................... 97
1.5. Justificación e importancia del estudio ................................................................................................ 97
1.6. Hipótesis ................................................................................................................................................. 98
1.7. Objetivos................................................................................................................................................. 98
1.7.1. Objetivo General ............................................................................................................................. 98
1.7.2. Objetivos Específicos ..................................................................................................................... 98
CAPITULO II: MATERIAL Y MÉTODO ....................................................................... 100
2.1. Tipo de estudio y diseño de la investigación ...................................................................................... 100
2.2. Escenario de estudio ............................................................................................................................ 100
2.3. Caracterización de sujetos .................................................................................................................. 101
2.4. Técnicas e instrumentos de recolección de datos .............................................................................. 101
2.5. Procedimientos para la recolección de datos ..................................................................................... 102
7
2.6. Procedimiento de análisis de datos..................................................................................................... 103
2.7. Criterios éticos ..................................................................................................................................... 103
2.8. Criterios de rigor científico ................................................................................................................. 103
2.9. Modelo de trabajo................................................................................................................................ 104

2.9.1. Análisis del sector de desarrollo de software en Perú ................................................................... 109
2.9.2. Selección de normas y guías de buenas prácticas ......................................................................... 115
2.9.3. Establecer métricas de evaluación ................................................................................................ 116
2.9.4. Modelo de Gestión para aseguramiento de Calidad ...................................................................... 130
CAPITULO III: REPORTE DE RESULTADOS ............................................................ 157
1.8. Análisis y discusión de resultados ...................................................................................................... 157

1.8.1. Análisis de resultados ................................................................................................................... 157
1.8.2. Discusiones ................................................................................................................................... 159
1.9. Consideraciones finales ....................................................................................................................... 161
1.10. Conclusiones......................................................................................................................................... 161

REFERENCIAS ................................................................................................................... 165
ANEXOS GENERALES ..................................................................................................... 170
ANEXO 1: Documento de reunión inicial del proyecto (DRI) ...................................................................... 170
ANEXO 2: Documento de Políticas empresariales (DPE)............................................................................. 171
ANEXO 3: Documento de Objetivos Empresariales (DOE) ......................................................................... 172
ANEXO 4: Documento de aspectos legales (DAL) ......................................................................................... 173
ANEXO 5: Documento de presupuesto para el proyecto (DPP)................................................................... 174
ANEXO 6: Documento de tiempo total para el proyecto (DTTP) ................................................................ 175
ANEXO 7: Documento de plan de mejora continua (DPMC) ...................................................................... 178
ANEXO 8: Documento de perfiles de equipo de trabajo (DPET) ................................................................ 179
ANEXO 9: Documento de plan de trabajo (DPT) ......................................................................................... 180
ANEXO 10: Documento de formato y estilo de programación (DFP) ......................................................... 181
ANEXO 11: Documento de formato y estilo de base de datos ...................................................................... 182
ANEXO 12: Documento de caso de revisión interna (DCRI) ....................................................................... 183
ANEXO 13: Documento de casos de revisión del usuario (DCRU) .............................................................. 184
ANEXO 14: Documento de formato de medición del proyecto (DFMP) ..................................................... 185
8
ANEXO 15: Documento de estándares del producto (DECPR) ................................................................... 186
ANEXO 16: Documento de formato de entrega de versiones (DFEV)......................................................... 187
ANEXO 17: Documento de formato de control de cambios y correcciones (DFCCK)............................... 188
ANEXO 18: Documento de estándares del proyecto (DECPY) .................................................................... 189
ANEXO 19: Documento de plan de proyecto (DPY) ..................................................................................... 190
ANEXO 20: Documento de hallazgos de verificación.................................................................................... 192
ANEXO 21: Documento de hallazgos de validación ...................................................................................... 193
ANEXO 22: Documento de evaluación de métricas de evaluación (DEMC) ............................................... 194
ANEXO 23: Documento de resultados finales del proyecto .......................................................................... 195
ANEXO 24: Documento de análisis de resultados del proyecto (DARPY) .................................................. 197
ANEXO 25: Hoja de vida de Experto 1 .......................................................................................................... 198
9
INDICE DE TABLAS
Tabla 1. Evolución del estado de proyectos ..................................................................................................... 15

Tabla 2. Tamaño de proyecto por evolución ................................................................................................... 16
Tabla 3. Administrar Requerimiento - CMMI, Nivel 2 ................................................................................... 32
Tabla 4. Planificación de proyecto - CMMI nivel 2 ......................................................................................... 33
Tabla 5. Seguimiento y control de proyectos - CMMI Nivel 2 ........................................................................ 34
Tabla 6. Administración de acuerdo con proveedores- CMMI Nivel 2 .......................................................... 35
Tabla 7. Medición y análisis - CMMI Nivel 2 ................................................................................................... 36
Tabla 8. Aseguramiento de la calidad de procesos y productos - CMMI Nivel 2 .............................................. 37
Tabla 9. Administración de la configuración - CMMI Nivel 2 .......................................................................... 38
Tabla 10. Desarrollo de Requerimientos - CMMI Nivel 3 ............................................................................... 39
Tabla 11. Solución técnica - CMMI Nivel 3 ...................................................................................................... 40
Tabla 12. Integración del producto - CMMI Nivel 3 ......................................................................................... 41
Tabla 13. Verificar - CMMI Nivel 3 .................................................................................................................. 42
Tabla 14. Atención a los procesos organizacionales - CMMI Nivel 3 ............................................................... 43
Tabla 15. Definición de procesos organizacionales - CCMI Nivel 3 ................................................................. 44
Tabla 16. Formación de la organización - CMMI Nivel 3 ................................................................................ 44
Tabla 17. Administración de la integración del producto - CMMI Nivel 3 ....................................................... 45
Tabla 18. Administración de Riesgos - CCMI Nivel 3 ....................................................................................... 46
Tabla 19. Equipo Integrado ................................................................................................................................ 47
Tabla 20. Análisis y toma de decisiones ............................................................................................................. 48
Tabla 21. Administración de procesos cuantitativos - CMMI Nivel 4 ............................................................... 49
Tabla 22. Desempeño del proceso de la organización - CMMI Nivel 4 ............................................................ 50
Tabla 23. Capacidades y factores de calidad expuesta por McCall ............................................................... 63
Tabla 24. Tipos de requerimientos FURPS+ .................................................................................................... 65
Tabla 25. Niveles de medición del modelo GQM ............................................................................................. 70
Tabla 26. Metas, atributos y métricas según SATC......................................................................................... 70
Tabla 27. Agrupamiento de las características de calidad según Dromey ..................................................... 72
Tabla 28. Capas de estructura del Modelo de C-QM ...................................................................................... 73
Tabla 29. Mapeo de áreas y factores de calidad de la metodología SQAE .................................................... 75
Tabla 30. Técnicas e instrumentos de recolección de datos ........................................................................... 102
Tabla 31. Ventas anuales por producto - servicio .......................................................................................... 113
Tabla 32. Selección de normas y guías de buenas prácticas para el desarrollo del modelo MGCQ ......... 115
Tabla 33. Características de calidad de los modelos y estándares de calidad ............................................. 116
Tabla 34. Sub-características de calidad cubiertas por los modelos y estándares a nivel del producto .... 117
Tabla 35. Características y sub-características de calidad............................................................................ 121
Tabla 36. Discusiones generales....................................................................................................................... 159
10
INDICE DE FIGURAS
Figura 1. Curva de falla de software. Copyright 2010 por Pressman, R. ......................................................... 25

Figura 2. Expectativas para la calidad de software. Puntos de referencia que establece la ISO/IEC 9126 para
determinar la calidad de software mediante el uso de categorías y subcategorías. .................................. 26
Figura 3. Development Stage of SP Method for SME's. Propuesto por [7] ...................................................... 28
Figura 4. Estándar del modelo CMMI.............................................................................................................. 51
Figura 5. Beneficios del uso de PMI................................................................................................................... 52
Figura 6. Modelo de gestión de proyectos de PMBOK -PMI ............................................................................. 54
Figura 7. Procesos de gestión de integración de PMBOK ................................................................................. 55
Figura 8. Ciclo PDCA de Deming ..................................................................................................................... 58
Figura 9. Atributos de la calidad McCall ........................................................................................................... 64
Figura 10. Modelo de calidad Gilb .................................................................................................................... 67
Figura 11. Modelo Boehm................................................................................................................................... 67
Figura 12. Criterios y factores de calidad según Boehm ................................................................................... 68
Figura 13. Métricas derivadas de los objetivos y preguntas GQM ..................................................................... 69
Figura 14. Jerarquía de la metodología SQAE .................................................................................................. 74
Figura 15. Ciclo de ITIL .................................................................................................................................... 76
Figura 16. Modelo ISO/IEC 15504 – Certificación SPICE ............................................................................. 77
Figura 17. Modelo de procesos Bootstrap ........................................................................................................ 79
Figura 18. Historia de CMMI. Evolución desde la versión 1.1. que establece Capability Maturity Model
Integration desde 1993 hasta 2010. Extraído de [50] ................................................................................ 81
Figura 19. Niveles de Madurez de CMMI. Representa los escalones que establece CMMI Institute para poder
alcanzar una optimización en los procesos dentro de una organización. ................................................. 83
Figura 20. División del estándar ISO/IEC 2500n. La norma SQuaRE plantea 4 divisiones para el control de
la calidad e software y su evaluación ......................................................................................................... 88
Figura 21. Calidad de producto de software. Niveles de categoría y subcategoría que debe de cumplir un
producto de software para determinar el nivel de calidad de acuerdo al ISO/IEC 25010. Extraído de [38]
..................................................................................................................................................................... 90
Figura 22. Adecuación Funcional. De acuerdo con la ISO 25010 estos son las características que debe
cumplir para aprobar con esta categoría. .................................................................................................. 91
Figura 23. Eficiencia de desempeño. Evalúa el nivel de uso de los recursos y de acuerdo con la ISO/IEC
cumplen con las siguientes categorías........................................................................................................ 92
Figura 24. Compatibilidad. De acuerdo con la ISO/IEC es el nivel de intercambio de información entre
componentes y se subdividen con las subcategorías descritas ................................................................... 92
Figura 25. Usabilidad. De acuerdo con la ISO/IEC se deben de cumplir con las siguientes subcategorías .... 93
Figura 26. Fiabilidad, La ISO/IEC 25010 determina que estás son las subcategorías de debe de cumplirse
para obtener Fiabilidad en el producto de software .................................................................................. 94
Figura 27. Seguridad. De acuerdo con la ISO/IEC, determina que las siguientes subcategorías se deben
cumplir para aprobar la categoría de seguridad por la normal SQuaRE ................................................. 94
Figura 28. Mantenibilidad. De acuerdo con la norma SQuaRE, la categoría de mantenibilidad se cumplirá si
se integran las siguientes subcategorías ..................................................................................................... 95
Figura 29. Etapa 1: Análisis del sector de desarrollo de software peruano - Entregable IASP ..................... 104
Figura 30. Etapa 2: Selección de normas y guías de buenas prácticas - Entregable MSI ............................. 105
Figura 31. Etapa 3: Establecer métricas para evaluación - Entregable PM ................................................... 106
Figura 32. Etapa 4: Propuesta de modelo de gestión y control de calidad - Entregable MGC ...................... 106
Figura 33. Paso 5: Validación de modelo - Entregable IEE............................................................................ 107
Figura 34. Ventas totales por productos o servicios, entre los años 2006 y 2007 con una base de 300
empresas ................................................................................................................................................... 112
Figura 35. Ventas activas en el año 2007 ........................................................................................................ 112
Figura 36. Ciclo PDCA ..................................................................................................................................... 130
Figura 37. Etapa de planificación .................................................................................................................... 131
Figura 38. Etapa de Planificación, Subproceso Generación de plan de trabajo ........................................... 132
11
Figura 39. Reunión inicial del proyecto. ......................................................................................................... 136
Figura 40. Generar plan de trabajo. Flujo de proceso de para generar un plan de trabajo. ..................... 137
Figura 41. Etapa de Planificación, Subproceso Estándares de calidad ......................................................... 138
Figura 42. Etapa de Planificación, Subproceso Selección de comité de control de calidad.......................... 141
Figura 43. Flujo de proceso de selección de personal de comité de control de calidad............................... 142
Figura 44. Organigrama de comité de control de calidad ............................................................................. 142
Figura 45. Flujo de proceso de plan de proyecto. .......................................................................................... 143
Figura 46. Etapa de Hacer ............................................................................................................................... 145
Figura 47. Flujo de proceso para brindar el calendario de actividades y tareas y requerimientos ........... 146
Figura 48. Etapa de Hacer, Subproceso Desarrollo de tarea ........................................................................ 147
Figura 49. Etapa de Hacer, Subproceso Desarrollo de validación de actividad .......................................... 150
Figura 50. Etapa de Verificación ..................................................................................................................... 153
Figura 51. Fase de generación de pruebas de software por usuarios ........................................................... 153
Figura 52. Juicio de experto 1, último resultado de análisis ......................................................................... 162
12
CAPITULO I
13
CAPITULO I: INTRODUCCIÓN
1.1.Planteamiento del problema.
Según [1] el aseguramiento de la calidad de software no es sólo una moda actual, es una
necesidad que va de la mano con el uso de buenas prácticas y procesos que nos ayuden a
verificar, medir y controlar, que dichos principios de calidad se cumplan y se desarrollen
correctamente. Según [2], la mejora de la calidad en el software es reconocida cada vez
más como un problema fundamental de la ingeniería del software
[1] afirman que la calidad de software es tan importante como la calidad de la productividad
con la cual es generada, esto es y será la llave del éxito junto con el servicio de los usuarios.
La calidad requiere de control y a su vez, se hace necesario un método aceptado que permita
diagnosticar en forma ordenada aquello que se desea resolver o mejorar.
Por otra parte, con respecto a la calidad de software, el [3], define la calidad de software
como el grado en que un sistema, componente o procesos cumple con los requisitos o
expectativas del cliente o usuario; en contra parte, el [4] determina que, la calidad de
software es la totalidad de la funcionalidad y las características de un producto de software
que se relacionan con su capacidad para satisfacer las necesidades declaradas o implícitas.
Estos conceptos han ido evolucionando, y han sido absorbidas por las empresas a nivel
mundial por ello, la adquisición y uso de un software en las industrias se ha convertido en
una necesidad acorde al uso tecnológico de los últimos años. Las empresas demandan cada
vez más el uso de soluciones informáticas de calidad, que cumplan con sus objetivos
institucionales e ir aumentando su desarrollo en el mercado laboral, de acuerdo con la
época, adaptándose a los cambios.
Sin embargo, esta creciente demanda por obtener un software de calidad ha obligado a los
equipos de trabajo de desarrollo, atravesar por problemas que van desde su planeamiento
hasta su posible entrega, esto no solo registrado en nuestro país, sino alrededor del mundo,
la industria de software anualmente presenta inconvenientes que se ven reflejados en “The
14
Chaos Report”, reporte de estatus del desarrollo de software que se elabora anualmente
desde 1985 evaluando el desempeño de proyectos de Software.
De acuerdo con [5] en su informe The Chaos Report, publicado en el 2018, se observa que
en visiones generales solo el solo el 29% de los proyectos estudiados termina
satisfactoriamente con los estándares establecidos por la empresa contratante, mientras que
un 52% de estos son regresados por no cumplir con lo establecido, solicitando que se
realicen los cambios en la brevedad posible, y un 19% es rechazado completamente debido
a las carencias de las que son objetos.
Tabla 1. Evolución del estado de proyectos
2011 2012 2013 2014 2015

Exitoso 29% 27% 31% 28% 29%
Por
Cambios 49% 56% 50% 55% 52%
Fallido 22% 17% 19% 17% 19%
Nota: Evolución de los estados de proyectos a nivel mundial y de los casos de éxito y falla de proyectos de
software de distinto tamaño. Recuperado de [5]
Para calificar la efectividad de un proyecto es necesario, de acuerdo con los estudios

realizado en el reporte de caos del 2018, contar con diez factores de referencia, entre ellos
los más importantes son contar con un patrocinador ejecutivo calificado que pueda cumplir
con los objetivos planteados, y un nivel de madurez emocional para el desarrollo.
Solo en América del norte el éxito de sus proyectos subió a un 31% frente a un 16.2% en
promedio registrado en el año 2014, debido a múltiples factores de los que han aprendido
para mejorar y concluir con un proyecto de software consistente con los requerimientos y
buenas prácticas de calidad.
El tamaño del software es también un punto importante para calificar la investigación de

Chaos Report 2018, The Standish Group determina 5 grupos para catalogar los tamaños
del software entre ellas tenemos: proyectos muy grandes, grandes, medianos,
moderadamente pequeños y pequeños, si unimos la data anterior fundamentada en la base
15
de datos de CHAOS, determinamos que de este 29% de aprobación de proyectos, se
comparte en 6%, 11%, 12%, 24% y 61% respectivamente a los tamaños de software
anteriormente descritos.
Tabla 2. Tamaño de proyecto por evolución
Por
Exitoso Fallidos TOTAL
Cambios
Muy Grandes 6% 51% 43% 100%
Grandes 11% 59% 30% 100%
Mediano 12% 62% 26% 100%
Moderadamente
24% 64% 12% 100%
pequeño
pequeño 61% 32% 7% 100%
Nota: Tamaño de los proyectos de software divididos por Standish Group en su base de datos CHAOS2015.
Recuperado de [5]
Chaos Report informa el caso que, a principios del año 1994, American Airlines resolvió
su demanda con Budget Rent-A-Car, Marriott Corp. y Hilton Hotels, luego de que el
proyecto de sistemas de reservación de hoteles y autos colapsara y ocasione un caos,
desencadenando la pérdida de $165 millones de dólares, debido a una declaración
incompleta de requisitos, falta de participación del usuario y cambios constantes de
requisitos y especificaciones.
En 1991, el aeropuerto internación de Denver, conocido como DIA por sus siglas en inglés,
realizó un intento por remodelar su lento sistema de facturación y traslado de equipaje. La
idea consistía en colocar etiquetas de códigos de barras en cada maleta para que fuera
transferidas en trasportadores con carretillas automática. BAE Systems fue el encargado
del desarrollo del sistema automatizado de manipulación de equipajes, basado en un
calendario irrealista y poca medición de riesgos desencadenaron en una pérdida de 2.000
millones de dólares por un periodo de 16 meses de cierre de operación. En su conjunto el
proyecto fue descartado en el 2005.
El servicio nacional de salud, el sistema de sanidad público de Inglaterra, el mayor y más

antiguo del mundo, requería un proyecto que pretendía revolucionar el modo en que se
utiliza la tecnología en el sector sanitario allanando el camino para los historiales
16
electrónicos, el escaneado digital y los sistemas informáticos integrados en hospitales y
centros de atención comunitaria. El proyecto ha sido calificado como el mayor fracaso
informático jamás visto y, una escandalosa pérdida de dinero de los contribuyentes. Los
cálculos del daño infligido a los británicos fluctúan, si bien se puede decir que rondan
precariamente en torno a los 10.000 millones de libras.
Hubo discusiones contractuales desde el principio, con constantes cambios de

especificaciones, disputas con proveedores y problemas técnicos omnipresentes durante
toda la condenada existencia del proyecto.
A las irrealistas previsiones, tanto de tiempo como de costes, se sumaron un inadecuado

estudio preliminar, la inexistencia de revisiones de progreso y una clara falta de liderazgo.
[6] expone que el motivo del fracaso de los proyectos de TI en el estado peruano expone
que el proceso de cada proyecto incluye la gestión, el ciclo de vida, la metodología, los
estándares, la ingeniería, la arquitectura, el componente técnico – administrativo, entre
otros. Por lo tanto, el proceso falla cuando la ingeniería está mal diseña o la gestión es
pobre.
Así mismo [6] también expone que las cuatro razones principales por las cuales los
proyectos de TI fracasan en el estado son la mala definición del alcance del proyecto; la no
aplicación de metodologías tanto de desarrollo de software como de gestión de proyectos;
la selección de tecnologías en proceso de maduración; y la inadecuada selección de los
profesionales
Un software de mala calidad representa riesgos, y las causas que afectan la calidad de
software son resultado de malas prácticas que aparecen desde la concepción del proyecto,
el principal causante de software de mala calidad son los costos.
Sin embargo, otras causas que conllevan a software de mala calidad y en consecuencia en
el fracaso del software son, la falta de dominio de negocio que puede causar un considerable
número de defectos introducidos al sistema por requerimientos funcionales mal entendidos;
por otro lado, los defectos no funcionales que causan interrupciones dañinas, corrupción de
datos o fallas durante la operación son causadas en gran medida por el desconocimiento de
la tecnología.
17
Un calendario poco realista conlleva a un estrés laboral que finalmente se concreta en que
el desarrollador cometa mayor número de errores en el sistema y un tiempo más prolongado
para encontrarlos y solucionarlos, así mismo, un código complejo genera dificultades en
la modificación y por ende conduce a numerosos errores y efectos secundarios como
retrabajos costosos y entregables con retraso, éstos son causados por no implementar
conceptos de ingeniería de software; por ultimo las aplicaciones multinivel que en su
mayoría son mantenidas por equipos distribuidos que tienen poca visibilidad o control
sobre la calidad del software son causados por malas prácticas de desarrollo de software.
Con el presente trabajo de investigación se pretende, desarrollar un modelo para la gestión

de proyectos de software en PYME’s peruanas, añadiendo el control de calidad, basados
en el conjunto de normas de buenas prácticas para lograr reducir el nivel de riesgo de un
proyecto de desarrollo de software.
1.2.Antecedentes de estudio
[7] detectaron en su investigación que existe un gran problema en la confianza, la

legibilidad, satisfacción del cliente y producto de software o servicio en el tiempo y en las
limitaciones presupuestarias definidas; todas estas relacionadas en los recursos, esfuerzos,
dinero y procesos de software, es por ello que se plantearon ayudar a la PYME’s mejorando
su calidad de procesos y productos de software de acuerdo con la adopción de SPI
(Software Process Improvement – Mejora de los procesos de software). Durante su estudio
determinaron que existen varios factores que influyen en la implementación de SPI para la
PYME’s como, los candidatos insuficientes de los proyectos de evaluación formal, el
compromiso del patrocinador para asignar los recursos adecuados, falta de formación de
los profesionales, herramientas inadecuadas, tamaño de los objetivos de la empresa,
sobreestimación de la capacidad de las gestiones y control de procesos del equipo. Su
solución fue desarrollar un método simple, eficiente y de bajo costo con el fin de ayudar a
la PYME’s a mejorar su calidad y procesos de productos de software de acuerdo con un
conjunto de herramientas, actividades y planes. Su método propuesto se compone mediante
la fusión de la norma ISO/IEC 25010 y el nivel 2 de CMMI. Concluyeron finalmente que
tras su estudio y sus pruebas realizadas cumplieron con las necesidades y características,
ayudando a mejorar la calidad de los proyectos y su gestión.
18
[8] observaron que durante el desarrollo del software se detectaron errores y defectos en
los productos finales entregables, segmentando los errores en las principales fallas como:
comprensión de los requisitos inadecuados que incluyen la posibilidad de cambios
frecuentes, un plan de diseño incompleto e incorrecto, errores de codificación, falta de
conocimiento o experiencia en software. Por lo que propusieron un método de
administración para mejorar la calidad de software desde la perspectiva de calidad de
software, por último, diseñaron un modelo de gestión de calidad.
Para el modelo de calidad determinaron 7 pasos a seguir como metodología de trabajo:
Establecer el Equipo de Aseguramiento de Calidad de Software (SQA), Formular el plan
de SQA, desarrollar la lista de tareas de SQA, realizar la inspección del sitio de trabajo
SQA, formulación y notificación de información de inspecciones de SQA, evaluación y
seguimiento de no conformidades y análisis estadístico regular del desempeño de SQA.
Después de las múltiples pruebas que ha realizado, han concluido que el modelo controla
efectivamente los defectos del software, el modelo controla efectivamente los defectos del
software en las etapas de análisis de requisitos, diseño de software e implementación de
código, ha desempeñado un buen beneficio en nuestro trabajo y se ha incluido en la
documentación del sistema de gestión de la calidad.
[9] observaron que a medida que se desarrolla la tecnología de la información, el software

es mucho más popular en nuestra vida diaria, por lo que la calidad del software es un factor
vital relacionado con el éxito comercial y la seguridad humana, describiendo el grado de
conformidad con los requisitos y expectativa explícitos o implícitos. Su estudio determina
que existen dos enfoques que se deben seguir para garantizar la calidad de software. Uno
se centra en una especificación y evaluación directas de la calidad del producto de software,
mientras que el segundo se centra en garantizar la calidad del proceso cuando el producto
esta subdesarrollado. Tras su análisis lograron proporcionar un marco de evaluación de la
calidad del software basado en los estándares de ISO 25000:2014 SQuaRE, y las relaciones
entre el modelo de calidad, su medición, los requisitos para calidad y el proceso de
evaluación. Así mismo proporcionan un análisis de la comparación de técnicas típicas sobre
la cuantificación de calidad, concluyendo que el adecuado uso de los estándares de la serie
SQuaRE mejoraría la calidad del software como medio eficaz de gestión de la calidad.
Finalmente concluyeron que la aplicación adecuada de los estándares de la serie SQuaRE
mejoraría la calidad de los sistemas y su acción como medio eficaz de gestión de la calidad.
19
[10] analizan que cada vez más las empresas pequeñas toman importancia a la calidad del
proyecto de software, y determinan que el problema es mejorar los proyectos de software
de estas pequeñas empresas; por lo tanto, gestionan mejorar el control de calidad y gestión
de pruebas de un proyecto, como el plan de garantía de calidad y el plan de prueba. Estudian
el método de gestión de la calidad en proyectos de software de pequeño tamaño, así mismo
analizan las características y sus desventajas que incurren en la gestión de proyectos de
software. La calidad de software está directamente relacionada con la competitividad del
mercado, considerando que dicho software no puede ser pasado por alto puesto que se
considera como una forma importante de evaluar un proyecto o producto, ya sea conforme
a la norma. Este documento propone una planificación de calidad liviana, ejecución de
calidad y actividades de seguimiento de la calidad en la gestión de proyectos, en tal sentido
este estudio proporciona prácticas y pruebas para asegurar un método efectivo.
[11] estudian que, en muchas empresas, la calidad se trata de la manera antigua,

considerando el control de calidad principal, y en ocasiones el único y cuidadoso, así mismo
determinan que el control no siempre es efectivo. Los problemas con la calidad pueden
surgir por culpa de los proveedores, un cambio desfavorable en los parámetros tecnológicos
de los procesos. En tal sentido determinan que el desarrollo de la ciencia y la tecnología
requiere el desarrollo de nuevos métodos de gestión de la calidad junto con los métodos ya
existentes y los sistemas de gestión de la calidad basados en nuevos enfoques. El artículo
muestra algunas áreas para la mejora de la existencia y la creación de nuevas herramientas,
técnicas y sistemas de gestión de validad del desarrollo de tecnologías digitales. Analiza
los métodos como Lean Production y tecnologías como CALS, ERP, PDM, MES, LIMS,
EAM permitiendo crear un sistema de calidad moderno. Concluyen que la integración de
los métodos anteriores, basados en la tecnología de la información, permiten crear un nuevo
sistema de gestión y control de calidad, así mismo es posible reducir los procedimientos de
rutina que requieren mucho tiempo y recursos.
[12], observan que las empresas se ven obligadas a prestar mucha atención a la creación de
un recurso de información moderno, la introducción de tecnologías de información
avanzadas, así mismo determinan que para resolver problemas con características
innovadoras, la empresa necesita información y, por lo tanto, es necesaria la
comercialización dentro de la empresa. Para ello proponen un enfoque para la descripción,
20
control y la gestión de indicadores de calidad del proyecto de desarrollo de software. Los
investigadores determinan que en su entorno de estudio un problema clave son las nuevas
condiciones de negocio, en este sentido, existe el problema de elegir una herramienta para
evaluar el potenciar económico que permita determinar rápidamente la capacidad interna.
Dicho estudio se basa en la exposición de indicadores de calidad empleando ecuaciones de
situaciones difusas. Proponen a su vez la composición y estructura de un sistema situacional
automatizado con lógica difusa para la implementación de un proyecto de desarrollo de
software con calidad.
[13] analizan que el mercado actual está creciendo y que para aumentar su competitividad
en el mercado de software se necesita mejorar la calidad de los productos de software
entregados, por ende su planteamiento de problema determina cómo se debe evaluar
objetivamente la calidad de los productos de software entregados, así mismo determinan
que, la industria del software aún enfrenta muchos problemas para controlar y evaluar la
calidad de los productos de software; una de las razones principales para esto es que, a
excepción de la falta de un modelo objetivo de evaluación de la calidad de producto de
software, las organizaciones de software no cuentan con un mecanismo bien definido para
medir los atributos de calidad y evaluar el nivel de calidad del producto de software. Esta
investigación propone un modelo de proceso para evaluar el nivel de calidad basándose en
la norma internacional ISO/IEC 14598. El modelo que propone puede generar un modelo
de evaluación de la calidad del producto de software a medida basado en los tipos de
sistemas de información, en consecuencia, las medidas de software necesarias se recopilan
y se analizan para proporcionar información para mejorar del producto de software.
Concluyen indicando que el modelo propuesto ayuda a las organizaciones de desarrollo de
software no solo a fortalecer el mecanismo de medición y análisis de la calidad del producto
de software, sino también a mejorar la motivación y la disposición de la garantía de calidad
del software
[14] estudian que en particular en la industria del software peruano la constitución de las
mismas está determinada por pequeñas empresas que desarrollan software, analizan que
para muchas universidad y empresas aparentan ser disímiles, hecho que se puede apreciar
con cierta facilidad en frases que se escuchan en la industria comúnmente, esto contribuye
a que las relaciones entre empresas sean más complicadas. Para lo cual propusieron el
desarrollo de modelos de procesos que contribuyan a incrementar su competitividad, dicho
21
modelo sido empleado en la realidad de nuestro país, a través de pruebas controladas. Por
lo que proponen el uso de algunos aspectos relevantes del proyecto COMPETISOFT-
Componente-Perú, dicho proyecto permitió obtener un conjunto de beneficios y resultados
tanto para empresas, como para los profesionales académicos.
1.3. Abordaje Teórico
1.3.1. Calidad
Según [15] define la calidad, como: “Propiedad o conjunto de propiedades inherentes a

algo, que permiten juzgar su valor”. Esta definición está orientada al mercado.
La calidad es la “Totalidad de propiedades y características de un producto, proceso o

servicio que le confiere su aptitud para satisfacer unas necesidades expresadas o
implícitas” [16]; además describe los conceptos y principios fundamentales de la
gestión de la calidad que son universalmente aplicables a lo siguiente:
a. Organizaciones que buscan un éxito continuo a través de la implementación de un

sistema de gestión de la calidad;
b. Los clientes que buscan confianza en la capacidad de una organización para
proporcionar productos y servicios de manera consistente de acuerdo con sus
requisitos;
c. las organizaciones que buscan la confianza en su cadena de suministro de que se
cumplirán los requisitos de sus productos y servicios;
d. organizaciones y partes interesadas que buscan mejorar la comunicación a través
de un entendimiento común del vocabulario utilizado en la gestión de la calidad;
e. organizaciones que realizan evaluaciones de conformidad contra los requisitos de
ISO 9001;
f. Proveedores de formación, asesoramiento o asesoramiento en gestión de la
calidad;
g. Desarrolladores de estándares relacionados.
Según [17] “El control de calidad no significa alcanzar la perfección. Significa

conseguir una eficiente producción con la calidad que espera obtener en el mercado”.
22
Es así como la calidad está más relacionada con los procesos internos de las empresas,
orientada hacia la producción.
[18] escribió La trilogía de Juran, según esta debe de comprender:
a. Planificación de la Calidad: rendimiento del producto que da como resultado la

satisfacción del cliente; libertad de deficiencias en el producto, que evita la falta de
satisfacción del cliente.
b. Control de Calidad: como un proceso que debe seguir toda empresa para
asegurarse que sus productos o servicios mantengan un nivel mínimo de Calidad,
el cual es definido por la propia empresa, de acuerdo con las características de lo
que genera, de las características de sus clientes y de los objetivos de eficiencia que
se hayan planteado y que deban alcanzar con regularidad.
c. Mejora de la Calidad. proceso de elevarse a niveles de rendimiento sin precedente.
Un programa de este tipo incluye demostrar las necesidades de las mejoras, identificar
proyectos específicos para la mejora, organizar el apoyo para los proyectos,
diagnosticar las causas, dar remedios para las causas, demostrar que los remedios son
efectivos bajo las condiciones de operación y proporcionar el control para mantener las
mejoras.
Con todos los conceptos anteriores se puede decir que todas las definiciones incluyen
la participación del cliente y que, en el contexto actual, la calidad persigue, a grosso
modo, los siguientes objetivos: satisfacción de los consumidores, eficiencia en la
utilización de los recursos humanos y la reducción en el costo de las operaciones.
1.3.1.1.Evolución de Calidad
La calidad en las empresas ha evolucionado, si lo analizamos desde los inicios de

los procesos de industrialización a mediados del siglo XIX hasta cerca de 1940, la
calidad se relacionaba con la inspección en los productos con el propósito de
detectar errores, de ésta fecha hasta los años 80’s el control de calidad se convirtió
en un ejercicio de control estadístico cuyo propósito era impedir que el producto
defectuoso llegase al cliente iniciando procesos de gestión de calidad total, que
23
buscaban garantizar la calidad por medio de la planificación y la creación de
modelos de calidad de forma permanente.
En la industria del software se pueden evidenciar necesidades de satisfacción del

cliente de productos o servicios. Según [19] afirma que la calidad es la
“Concordancia del software producido con los requerimientos explícitamente
establecidos, con los estándares de desarrollo prefijados y con los requerimientos
implícitos no establecidos formalmente, que desea el usuario”.
Por otro lado [20], afirma que las definiciones de calidad están orientadas a las
facilidades que ofrece el software una vez esté terminado, éste debe contener las
siguientes capacidades:
a. Fiabilidad: Capacidad de operar sin errores.

b. Modificable: Capacidad de hacer los cambios necesarios de una forma
sencilla.
c. Comprensible: Capacidad de comprender el software operativo, de cara a
un cambio o arreglo.
d. Rendimiento: Velocidad y compacidad del software.
e. Utilizable: Capacidad de uso sencillo del software.
f. Probable: Capacidad de construir y ejecutar fácilmente casos de prueba.
g. Portable: Capacidad de mover el software fácilmente de un entorno de
trabajo a otro.
1.3.2. Software
Según [15] define al software como un conjunto de programas, instrucciones y reglas

informáticas que permiten ejecutar distintas tareas en una computadora.
Existen muchos conceptos sobre el termino software como unas instrucciones de un

programa de cómputo que se ejecutan y proporcionan las características, funciones que
requiera el usuario o quizá, estructuras de datos que permiten manejar correctamente la
24
información, sin embargo, muchos de estos profesionales no están lejos de la definición
general de Software.
De acuerdo con [19], el software es el elemento de un sistema lógico y no físico. Por

tanto, tiene características que difieren considerablemente de las de hardware:
a. El Software se desarrolla o modifica con intelecto; no se manufactura en el sentido
clásico.
Aunque existen similitudes entre el desarrollo de software y la fabricación de

hardware, las dos actividades son diferentes en lo fundamental. En ambas, la alta
calidad se logra a través de un buen diseño, pero la fase de manufactura del
hardware introduce problemas de calidad que no existen en el software. Los costos
del software se concentran en la ingeniería. Esto significa que los proyectos de
software no pueden administrarse como si fueran proyectos de manufactura.
b. El software no se “desgasta” pero si se “deteriora”

El software no es susceptible a los problemas ambientales que hacen que el
hardware se desgaste, por lo tanto, en teoría, la curva de la tasa de fallas adopta la
forma de la “curva idealizada”.
Durante su vida el software sufrirá cambios y, es probable que cuando éstos se
realicen, se introduzcan errores que ocasionen que la curva de tasa de fallas tenga
aumentos súbitos. Antes de que la curva vuelva a su tasa de fallas original de estado
estable, surge la solicitud de otro cambio que hace que la curva se dispare
nuevamente, este proceso continuo hace que el software empiece a deteriorarse.
Figura 1. Curva de falla de software. Copyright 2010 por Pressman, R.
25
1.3.3. Calidad de software
Dentro de la Ingeniería de Software, se toma la definición de calidad en el software

propuesta por [16] que la define como “la totalidad de características de un producto de
software que tienen como habilidad, satisfacer necesidades explícitas o implícitas”.
Otra definición muy completa de calidad en el software es la que se presenta más
adelante en la misma definición, se puede decir que el software tiene calidad si cumple
o excede las expectativas del usuario en cuanto a:
a. Funcionalidad
b. Fiabilidad
c. Usabilidad
d. Eficiencia
e. Portabilidad
f. Mantenibilidad
En ese sentido podemos concluir, que la calidad de software se refiere a: “Los factores
de un producto de software que favorecen a la satisfacción completa y total de las
necesidades de un usuario u organización”.
Figura 2. Expectativas para la calidad de software. Puntos de referencia que

establece la ISO/IEC 9126 para determinar la calidad de software mediante el uso
de categorías y subcategorías.
26
1.3.4. Modelo
[21] define modelo como ejemplar o forma que uno propone y sigue en la ejecución
de una obra artística o en otra cosa, ejemplar para ser imitado, representación en
pequeño de una cosa, copia o réplica de un original, construcción o creación que sirve
para medir, explicar e interpretar los rasgos y significados de las actividades agrupadas
en las diversas disciplinas.
El modelo es una representación parcial de la realidad; esto se refiere a que no es

posible explicar una totalidad, ni incluir todas las variables que esta pueda tener, por
lo que se refiere más bien a la explicación de un fenómeno o proceso específico, visto
siempre desde el punto de vista de su autor [22].
Otra acepción define al modelo como un patrón a seguir o muestra para conocer algo,
existe también la idea de que un modelo debe ser utilizado para probar una hipótesis o
una teoría, o tan sólo para poder explicar un proceso o una abstracción [22].
Como conclusión, el término modelo puede ser descrito como la representación de un

hecho o fenómeno propuesta como excelente a seguir, mostrando las características
generales de la estructura de dicho fenómeno, explicar sus elementos, mecanismos y
procesos, cómo se interrelacionan y los aspectos teóricos que le dan sustento, para
facilitar su comprensión.
1.3.4.1.Modelo proceso de software para SME.
El estudio de [7] determina un modelo en el que plantea la intervención del cliente

y del proveedor, hasta completar obtener el total del proyecto.
27
Figura 3. Development Stage of SP Method for SME's. Propuesto por [7]
En dicho sentido el plantea que la responsabilidad del cliente debe estar

comprendido en las siguientes etapas:
Etapa 1: Acuerdos Iniciales

a. Reunión inicial del proyecto: Se reúnen el cliente y su proveedor de
software (la empresa desarrolladora) e inicia el proceso de solicitudes y
requerimientos necesarios para el cliente, en esta etapa se discuten los
principales acuerdos.
b. Propuesta: En esta fase el proveedor de software se encargará de brinda
una propuesta a la necesidad del cliente con las soluciones tecnológicas que
puede ofrecerle cubriendo los puntos de requerimientos mencionados en la
reunión inicial del proyecto.
c. Aprobación: esta fase comprende una reunión con el proveedor de
software y el cliente donde se evaluará la propuesta emitida en contraparte
con los requerimientos necesarios para la empresa contratante.
28
d. Alcance del proyecto: se delimitará y afinará los requerimientos
funcionales y no funcionales del software que requiere el cliente, de acuerdo
a las limitaciones del cliente y del proveedor.
e. Propuesta final: en esta etapa el proveedor de software afinará las
propuestas iniciales en base a los nuevos requerimientos del cliente, así
como también en base a las limitaciones que pueda presentar la empresa
contratante.
f. Aprobación: Se reunirá el cliente y el proveedor y se realizará la
aprobación del proyecto en base a los acuerdos iniciales quedando
documentado el trayecto hasta el momento hasta su aprobación, así como
también el pago inicial del proyecto.
g. Pago inicial de 50%: La empresa contratante pagará el 50% del monto
total de costo de proyecto al proveedor para inicial con el proyecto, esto
debe de constar en las actas, así como también en el contrato que se realiza.
Etapa 2: Desarrollo y pruebas

a. Creación de diseño: La empresa contratante del desarrollo del software,
diseñara el prototipo inicial del software de acuerdo a los acuerdos iniciales
con el cliente.
b. Aceptación de diseño: Se reunirá el cliente y el proveedor para evaluar el
diseño de software que se ha prototipado, y evaluará el cliente si cumple
con sus necesidades.
c. Suministrar contenido: El cliente deberá suministrar la información y
contenido que desea sea trabajado en el sistema con la finalidad de inicial
la implementación del proyecto.
d. Implementación: El proveedor empezará el proceso de desarrollo de la
plataforma tecnológica que se acordó con el cliente, respetando los
requerimientos funciones y no funcionales, así como también el prototipo
de diseño aceptado.
e. Escribir código: El proveedor iniciará el proceso de codificación del
producto, respetando las normas de desarrollo y estándares establecidos.
f. Pruebas de proyecto: El proveedor evaluará el desempeño del software
que ha venido trabajando en un entorno de pruebas controlado.
29
g. Presentación beta: El proveedor presentará e instalará una versión beta de
la aplicación para ser revisada por el cliente.
Etapa 3: Revisión y Aceptación
a. Revisión de tareas: el cliente revisará el proyecto en estado beta, tomará

notas del avance y solicitará una reunión con el proveedor.
b. Reunión de discusiones: el cliente y el proveedor evaluarán el desempeño
de la versión beta de la aplicación. El cliente emitirá sus dudas tomadas en
la revisión que realizó anteriormente.
c. Tomar notas de requerimientos no concluidos: El proveedor tomará nota
de los requerimientos no concluidos o errados para proceder con la
subsanación de las mismas.
d. Revisión de requerimientos no concluidos: El cliente revisará que los
requerimientos no concluidos o errados que se observaron se hayan
subsanado.
e. Final de proyecto: el cliente determina el proyecto como concluido y
aprobado.
f. Pago de 50% final: el cliente pagará el 50% final del costo total del
proyecto que se acordó en la reunión inicial
g. Puesta en marcha: concluido el pago el proveedor publicará o entregará el
producto de software terminado.
30
1.3.4.2.Modelo control CMMI
Capability Maturity Model Integration conocido por sus siglas CMMI, es un

modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento
y operación de sistemas de software.
Dentro de los procesos tenemos:
Nivel 1: Administrado
[23] determina que en este proceso se ejecuta y se logra su objetivo. Sin embargo,
los proyectos no están bien documentados, con respecto a la planificación no se
cumplen los tiempos, no hay control sobre el cambio de especificaciones, entre
otros.
Nivel 2: Administrado
Las áreas de proceso del nivel 2 son siete en total, las cuales describimos
rápidamente en las próximas secciones de acuerdo con el alcance de [23].
1. Administración de Requerimientos (REQM)
[23] explica que esta área de proceso tiene como propósito mantener bajo
control los requerimientos que el producto a desarrollar deberá satisfacer.
Un punto primordial que se plantea en esta área de proceso es que cualquier

cambio realizado a los requerimientos se efectúe de manera controlada y que el
resto de los artefactos del proyecto se mantengan consistentes.
Otro de los puntos incluidos en esta área es la trazabilidad bidireccional,

capacidad para relacionar cuál ha sido el origen de los requerimientos de bajo y
alto nivel, cuáles son los artefactos relacionados con los requerimientos, y
cuáles son los componentes del producto que implementan cada requerimiento.
Dentro de esta área hay solamente un objetivo específico que es Administrar los
requerimientos y dentro de ella cinco prácticas que se describen a continuación.
31
Tabla 3. Administrar Requerimiento - CMMI, Nivel 2
Objetivo específico Prácticas específicas

Administrar Requerimientos. 1. Comprender el significado de los
Los requerimientos son requerimientos
administrados, y se identifican 2. Obtener compromiso de los
las inconsistencias entre los participantes/interesados acerca de los
requerimientos y los planes y requerimientos
otros artefactos del proyecto 3. Administrar cambios a los
requerimientos
4. Mantener la trazabilidad bidireccional
de los requerimientos
5. Identificar inconsistencias entre los
requerimientos y otros productos del
proyecto
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Administración de la Requerimientos”, de

Arévalo, M., 05 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/
cmmi/page/3/
2. Planificación de proyectos (PP)
Según [23] determina que esta área de proceso tiene como propósito establecer
y mantener el plan que será empleado para ejecutar y monitorear el proyecto .
Dentro de esta área se incluyen las actividades necesarias para establecer el

alcance del proyecto, estimar esfuerzos y costos, establecer un cronograma,
identificar los riesgos, además de obtener el compromiso de todos los
involucrados respecto al plan del proyecto.
32
Tabla 4. Planificación de proyecto - CMMI nivel 2

Establecer 1. Estimar el alcance del proyecto
estimaciones. Se 2. Estimar atributos de las tareas y de los
realizan y mantienen productos del proyecto
estimaciones de las 3. Definir el ciclo de vida del proyecto
magnitudes del proyecto. 4. Estimar esfuerzo y costo del proyecto
Desarrollar el plan de 1. Establecer el cronograma y el presupuesto del
proyecto. Se establece y proyecto
mantiene un plan de 2. Identificar los riesgos del proyecto
proyecto que es 3. Planificar la administración de datos del
empleado para proyecto
administrar el proyecto. 4. Planificar recursos necesarios para el proyecto
5. Planifica la adquisición de conocimientos y
habilidades
6. Planificar la participación de los interesados en
el proyecto
7. Establecer el plan de proyecto
Obtener el compromiso 1. Revisar todos los planes que puedan afectar al
de los interesados proyecto
acerca del plan de 2. Ajustar el plan del proyecto para reflejar
proyecto. Los recursos estimados versus los disponibles
compromisos con el plan 3. Obtener compromisos respecto al plan
están formalmente
establecidos y son
mantenidos a lo largo del
proyecto.
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Planificación del Proyecto”, de Arévalo,

M., 05 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/
cmmi/page/3/
33
3. Seguimiento y control de proyectos (PMC)
De acuerdo con [23], esta área de procesos es complementaria y una

consecuencia de la planificación del proyecto (PP), su propósito es monitorear
la ejecución del proyecto. Para ello se suministran los siguientes objetivos.
Tabla 5. Seguimiento y control de proyectos - CMMI Nivel 2

Monitorear el Proyecto 1. Monitorear los parámetros de planificación del
El avance y la proyecto
performance del proyecto 2. Monitorear los riesgos del proyecto
se monitorean respecto a 3. Monitorear los riesgos del proyecto
lo establecido en el plan 4. Monitorear la administración de datos del
de proyecto. proyecto
5. Monitorear la participación de los interesados
6. Conducir revisiones de avance
7. Conducir revisiones de cumplimiento de hitos
Gestionar Acciones 1. Analizar temas pendientes
Correctivas 2. Ejecutar acciones correctivas
Cuando los resultados o 3. Administrar acciones correctivas
la performance del
proyecto se desvían
significativamente del
plan se gestionan
acciones correctivas.
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Monitoreo y Control del Proyecto”, de

Arévalo, M., 05 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/
cmmi/page/3/
34
4. Administración de acuerdos con proveedores (SAM)
[23] afirma que esta área de proceso apunta a resolver la tercerización. Las
practicas incluidas aquí sirven para todo aquello que sea necesario comprar pero
que no será finalmente entregado al cliente, como herramientas de desarrollo.
Los objetivos y prácticas de área son las que se indican:
Tabla 6. Administración de acuerdo con proveedores- CMMI Nivel 2

Establecer acuerdos con 1. Determinar el tipo de adquisición
proveedores. Se 2. Seleccionar proveedores
establecen y mantienen 3. Establecer acuerdos con proveedores
acuerdos con proveedores.
Satisfacer acuerdos con 1. Revisar productos adquiridos

proveedores. Los 2. Ejecutar acuerdos con proveedores
acuerdos con los 3. Aceptar el producto adquirido
proveedores son 4. Transicionar productos
satisfechos por el
proyecto y por los
proveedores
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Administración de Acuerdos con

Proveedores”, de Arévalo, M., 05 de julio, 2011. Recuperado de
https://arevalomaria.wordpress.com/category/ cmmi/page/2/
5. Medición y análisis (MA)
Esta área de proceso apunta, justamente, a desarrollar y mantener capacidades

de medición que permitan satisfacer las necesidades de información de la
organización [23]. Los objetivos en esta área son las siguientes
35
Tabla 7. Medición y análisis - CMMI Nivel 2

Alinear actividades de 1. Establecer objetivos de las mediciones
medición y análisis. Las 2. Especificar métricas
actividades de medición y 3. Especificar procedimientos de recolección y
análisis están alineadas almacenamiento de datos
con los objetivos y 4. Especificar procedimientos de análisis
necesidades de
información.
Proveer los resultados 1. Recolectar datos
de la medición Se 2. Analizar datos
proveen mediciones que 3. Almacenar datos y resultados
satisfacen necesidades y 4. Comunicar resultados
objetivos de información
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Medición y Análisis”, de Arévalo, M., 05

de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/ cmmi/page/3/
6. Aseguramiento de la calidad de procesos y productos (PPQA)
Según [23], establecidos los procesos y estándares será necesario evaluar su

aplicación. El objetivo de esta área es justamente proveer una evaluación
objetiva de los procesos y de los artefactos producidos. Es importante aclarar
que las prácticas de ésta área implican:
a. Evaluar los procesos ejecutados

b. Identificar inconformidades
c. Informar a interesados.
Los objetivos y prácticas específicas del área son los siguientes:
36
Tabla 8. Aseguramiento de la calidad de procesos y productos - CMMI Nivel 2

Evaluar objetivamente 1. Evaluar procesos objetivamente.
procesos y artefactos 2. Evaluar productos y servicios objetivamente.
Se evalúa objetivamente
la adhesión de los
procesos y artefactos a
los estándares y
descripciones de proceso
vigentes.
Proveer realimentación 1. Comunicar y asegurar la resolución de
objetivamente cuestiones de calidad.
El no cumplimiento de 2. Establecer y mantener registros de las
los estándares y actividades de aseguramiento de la calidad.
descripciones de proceso
es objetivamente
comunicado y su
resolución asegurada.
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Aseguramiento de la Calidad de Productos

y Procesos”, de Arévalo, M., 05 de julio, 2011. Recuperado de
https://arevalomaria.wordpress.com/ category/cmmi/page/3/
7. Administración de la configuración (CM)
Por ultimo [23] determina que esta área tiene como propósito mantener la
integridad de todos los artefactos producidos por el proyecto, lo cual implica
identificar los ítems de configuración, realizar sobre ellos cambios de manera
controlada, generar y mantener líneas base y proveer información precisa acerca
del estado de la configuración a todos los interesados.
37
Los objetivos incluidos son:
Tabla 9. Administración de la configuración - CMMI Nivel 2

Establecer líneas base 1. Identificar ítems de configuración
Se establecen líneas base 2. Establecer un sistema de administración de la
de los artefactos puestos configuración
bajo administración de la 3. Crear o liberar líneas base.
configuración.
Monitorear y controlar 1. Monitorear pedidos de cambio

cambios 2. Controlar ítems de configuración.
Los cambios a los
artefactos son
monitoreados y
controlados.
Nota: Recuperado de “CMMI. Nivel 2 Gestionado: Administración de la Configuración”, de
Arévalo, M., 05 de julio, 2011. Recuperado de
https://arevalomaria.wordpress.com/category/cmmi/page/2/
Nivel 3: Definido:
1. Desarrollo de Requerimientos: para alcanzar este nivel explica [23] deben ser
formalizadas las actividades de diseño, desarrollo, verificación, etc., del
producto y ser adoptadas prácticas de gestión de proyectos más avanzadas. Así
mismo deben definirse procesos, procedimientos y estándares más detallados de
alcance organizacional.
Esta área incluye tres objetivos específicos y diez prácticas.
38
Tabla 10. Desarrollo de Requerimientos - CMMI Nivel 3

Desarrollar 1. Revelar necesidades
requerimientos del 2. Desarrollar los requerimientos del cliente.
cliente.
Se revelan las
necesidades,
expectativas,
restricciones e interfaces
y se traducen en
requerimientos del
cliente.
Desarrollar los 1. Establecer requerimientos del producto y sus
requerimientos del componentes
producto. 2. Asignar requerimientos a los componentes del
Los requerimientos del producto
cliente son refinados y 3. Identificar requerimientos de interfaz
elaborados para obtener
los requerimientos del
producto y sus
componentes.
Analizar y validar 1. Desarrollar concepto de operación y escenarios
requerimientos. 2. Desarrollar una definición de la funcionalidad
Los requerimientos son requerida
analizados y validados, y 3. Analizar requerimientos
se desarrolla una 4. Analizar requerimientos para balancear
definición de la necesidades y restricciones
funcionalidad requerida. 5. Validar requerimientos.
Nota: Recuperado de “CMMI Nivel 3: Área Desarrollo de Requerimientos”, de Arévalo, M.,

05 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/cmmi/page/2/
39
2. Solución Técnica: [23] explica que su propósito es formalizar el diseño y la
construcción del producto, mismo que en el nivel 2 no era tan importante. Esta
área de proceso incluye todas las actividades necesarias para:
a. Identificar y seleccionar una solución a los requerimientos
b. Desarrollar el diseño del producto
c. Implementar el diseño y obtener el producto.
Los objetivos y prácticas del área son las siguientes:
Tabla 11. Solución técnica - CMMI Nivel 3

Seleccionar Soluciones 1. Desarrollar soluciones alternativas y criterios de
Soluciones para el selección
producto o para sus 2. Evolucionar conceptos operacionales y
componentes son escenarios
seleccionadas. 3. Seleccionar soluciones
Desarrollar el diseño. 1. Diseñar el producto y los componentes
Se diseña el producto y 2. Desarrollar un paquete técnico de datos
sus componentes 3. Diseñar interfaces
4. Realizar análisis de construir, reusar y comprar
Implementar el Diseño 1. Implementar el diseño

del producto. 2. Desarrollar la documentación de soporte
Los componentes del
producto y la
documentación de soporte
son desarrollados a partir
del diseño
Nota: Recuperado de “CMMI Nivel 3: Área Solución Técnica”, de Arévalo, M., 05 de julio,
2011. Recuperado de https://arevalomaria.wordpress.com/category/cmmi/page/2/
40
3. Integración del producto: La función principal de esta área de proceso es
ensamblar el producto a partir de sus componentes, garantizando que su
funcionamiento sea el provisto, de acuerdo con [23]
Presenta tres objetivos y ocho practicas
Tabla 12. Integración del producto - CMMI Nivel 3

Preparar la integración 1. Desarrollar soluciones alternativas y criterios
del producto de selección
Se prepara la integración 2. Evolucionar conceptos operacionales y
del producto a partir de escenarios
sus componentes 3. Seleccionar soluciones
Desarrollar el diseño. 1. Diseñar el producto y los componentes
Se diseña el producto y 2. Desarrollar un paquete técnico de datos
sus componentes 3. Diseñar interfaces
4. Realizar análisis de construir, reusar y comprar
Implementar el Diseño 1. Implementar el diseño

del producto. 2. Desarrollar la documentación de soporte
Los componentes del
producto y la
documentación de
soporte son desarrollados
a partir del diseño
Nota: Recuperado de “CMMI Nivel 3: Área Integración de Producto”, de Arévalo, M., 05 de

julio, 2011. Recuperado de https://arevalomaria.wordpress.com/category/cmmi/page/2/
41
4. Validación: [23] explica que la función principal de ésta fase es garantizar que
los artefactos seleccionados cumplan con los requerimientos asignados.
Sus objetivos y prácticas son los siguientes.
Tabla 13. Verificar - CMMI Nivel 3

Preparar la verificación 1. Seleccionar artefactos para su verificación
Se preparará la 2. Establecer el ambiente de verificación
verificación de los 3. Establecer procedimientos y criterios de
artefactos verificación
Realizar revisiones 1. Preparar la revisión de pares
Se realizan revisión de 2. Conducir la revisión de pares
pares sobre artefactos 3. Analizar datos de la revisión de pares
seleccionados.
Verificar artefactos 1. Realizar la verificación

Seleccionar artefactos 2. Analizar los resultados de la verificación e
seleccionados son identificar acciones correctivas.
verificados versus los
requerimientos
especificados
Nota: Recuperado de “CMMI Nivel 3: Área Verificación”, de Arévalo, M., 06 de julio, 2011.
Recuperado de https://arevalomaria.wordpress.com/category/cmmi/page/2/
5. Atención a los procesos organizacionales: su principal propósito es , de

acuerdo con [23], planificar e implementar las mejoras a los procesos de la
organización.
Los objetivos y prácticas específicas del área son:
42
Tabla 14. Atención a los procesos organizacionales - CMMI Nivel 3

Determinar 1. Determinar necesidades de los procesos de la
oportunidades de organización
mejora de procesos 2. Evaluar los procesos de la organización
Periódica o 3. Identificar mejoras a los procesos de la
eventualmente se organización.
identifican fortalezas,
debilidades y
oportunidades de mejora
a los procesos de la
organización
Planificar e 1. Establecer planes de acción
implementar actividades 2. Implementar planes de acción
de mejora 3. Desplegar activos de procesos
Las mejoras son 4. Incorporar experiencias reales en los activos de
planeadas e implantadas, proceso.
los activos de proceso son
distribuidos, y se
incorpora la experiencia
adquirida en los activos
de proceso.
Nota: Recuperado de “CMMI Nivel 3: Área Enfoque Organizacional en el Proceso (OPF)”, de

Arévalo, M., 06 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/
category/cmmi/page/2/
6. Definición de procesos organizacionales: [23] determina que su función

principal es establecer y mantener un conjunto de activos de proceso. Debe
entenderse como activo, un cualquier elemento que forme parte de los procesos
de la organización.
El objetivo y las prácticas de ésta área son:
43
Tabla 15. Definición de procesos organizacionales - CCMI Nivel 3

Establecer activos de 1. Definir procesos estándar
procesos 2. Definir modelos de ciclo de vida
Se establece y mantiene un 3. Definir criterios y guías para adaptar procesos
conjunto de activos de 4. Establecer reposito organizacional de métricas
proceso. 5. Establecer la biblioteca de activos
organizacionales de proceso.
Nota: Recuperado de “CMMI Nivel 3: Área Definición Organizacional del Proceso”, de Arévalo,
M., 06 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/ category/cmmi/page/2/
7. Formación de la organización: de acuerdo con [23] su principal función es

proveer los conocimientos y habilidades necesarios para que el personal pueda
desempeñar sus roles eficaz y eficientemente, facilitando el cumplimiento de los
objetivos estratégicos de la organización.
Comprende dos objetivos y siete prácticas.
Tabla 16. Formación de la organización - CMMI Nivel 3

Establecer capacidad de 1. Determinar necesidades de los procesos de
entrenamiento la organización
organizacional 2. Determinar cuáles necesidades de
Se establece y mantiene una entrenamiento son responsabilidad de la
capacidad de entrenamiento organización
que permite desarrollar los 3. Establecer un plan táctico de
conocimiento y habilidades entrenamiento organizacional.
necesarias para las 4. Establecer capacidades de entrenamiento
actividades de la
organización
44
Proveer el entrenamiento 1. Proveer entrenamiento
necesario 2. Establecer registros del entrenamiento
Se provee el entrenamiento 3. Evaluar la efectividad del entrenamiento
necesario para que las
personas desempeñan
efectivamente sus roles.
8. Administración de la Integración del Producto: su principal función es

administrar el proyecto y el involucramiento de todos los interesados mediante
un proceso que ha sido aceptado a las necesidades particulares del proyecto [23].
Presenta cuatro objetivos y trece prácticas.
Tabla 17. Administración de la integración del producto - CMMI Nivel 3

Usar el proceso definido 1. Establecer el proceso definido para el proyecto
para el proyecto 2. Usar los activos de proceso de la organización
El proyecto es dirigido para planificar las actividades del proyecto
Nota: Recuperado de “CMMI Nivel 3: Área Entrenamiento Organizacional”, de Arévalo,
M., 08 de julio,
usando 2011. Recuperado3.
un proceso deIntegrar
https://arevalomaria.wordpress.com/
planes
definido, adaptado del 4. Gerenciar el proyecto usando planes integrados
conjunto de estándares de 5. Contribuir a los activos de proceso de la
proceso de la organización
organización
Coordinar y colaborar 1. Administrar el involucramiento de los
con los interesados. interesados
La coordinación y la 2. Administrar dependencias.
colaboración del 3. Resolver problemas de coordinación.
proyecto y de los
interesados es manejada
adecuadamente.
45
Usar la visión 1. Definir el contexto de la visión compartida del
compartida del proyecto.
proyecto 2. Establecer la visión compartida del proyecto.
El proyecto es dirigido
empleando la visión
compartida del proyecto
Organizar equipos 1. Determinar la estructura del equipo integrado

integrados de proyecto
Los equipos integrados 2. Desarrollar una distribución preliminar de los
necesarios para ejecutar requerimientos a los equipos integrados
el proyecto son 3. Establecer equipos integrados
identificados, definidos,
estructurados y
asignados.
Nota: Recuperado de “CMMI Nivel 3: Área Administración Integrada del Proyecto”, de

9. Administración de riesgos: su función principal de acuerdo con [23] explica se

debe plantear un enfoque sistemático para planear, anticipar y mitigar riesgo
para, proactivamente minimizar su impacto en el proyecto.
Presenta tres objetivos y siete prácticas.
Tabla 18. Administración de Riesgos - CCMI Nivel 3

Preparar la gestión del 1. Determinar fuentes y categorías de riesgo
riesgo 2. Definir parámetros de riesgo
Se establece y mantiene 3. Establecer una estrategia para la gestión del
una estrategia para riesgo
identificar, analizar y
mitigar riesgos
46
Mitigar Riesgos 1. Desarrollar planes de mitigación de riesgo
Los riesgos son 2. Implementar planes de mitigación de riesgo.
manejados y mitigados
para reducir su impacto
negativo en los objetivos.
Nota: Recuperado de “CMMI Nivel 3: Área Administración Integrada del Proyecto”, de

10. Equipo Integrado: [23] su función principal es establecer y mantener equipos

integrados para el desarrollo de productos. Dicho equipo puede estar integrado
por representantes de distintas áreas.
Presenta dos objetivos y ocho prácticas.
Tabla 19. Equipo Integrado

Establecer composición 1. Identificar las tareas del equipo
del equipo 2. Identificar necesidades de conocimientos y
Se establece y mantiene habilidades
una estructura de equipo 3. Asignar miembros de equipos apropiados
que provee los
conocimientos y
habilidades necesarias
para proveer el producto
del equipo
Gobernar la operación 1. Establecer una visión compartida
del equipo 2. Establecer el acuerdo del equipo
La operación del equipo 3. Definir roles y responsabilidades
integrado es gobernada 4. Establecer procedimientos operativos
de acuerdo con principios 5. Colaborar entre los equipos participantes
establecidos
Nota: Recuperado de “CMMI Nivel 3: Área Equipo Integrado”, de Arévalo, M., 02 de

septiembre, 2011. Recuperado de https://arevalomaria.wordpress.com/
47
11. Análisis y toma de decisiones: [23] su propósito que determina es que las
decisiones sean tomadas de acuerdo con un proceso formal, refiriéndose a un
enfoque estructurado para evaluar alternativas y recomendar una solución a un
problema determinado.
Esto implica:
a. Establecer criterios
b. Identificar soluciones alternativas
c. Determinar métodos para evaluarlas
d. Evaluar las soluciones alternativas y recomendar una de ellas.
Presenta un objetivo y seis practicas especificas
Tabla 20. Análisis y toma de decisiones

Se establece y mantiene 3. Definir criterios y guías para adaptar procesos
un conjunto de activos de 4. Establecer reposito organizacional de métricas
Nota: Recuperado de “CMMI Nivel 3: Área Análisis y Toma de Decisiones”, de Arévalo, M.,
08 de julio, 2011. Recuperado de https://arevalomaria.wordpress.com/ category/cmmi/page/2/
Nivel 4: Definido:
1. Administración de procesos cuantitativos: [23] explica que su principal

función es administrar el proyecto de manera tal de cumplir con sus objetivos
de calidad y desempeño. Esto implica:
a. Establecer y mantener los objetivos de calidad y desempeño del proyecto
b. Configurar el proceso que empleará el proyecto seleccionando aquellos
subprocesos sobre la base de su estabilidad y/o capacidad
c. Seleccionar los subprocesos del proceso del proyecto que serán
estadísticamente administrados
48
d. Monitorear el comportamiento del proyecto para determinar si se cumplen
o no los objetivos de calidad y desempeño
e. Monitorear el desempeño de los subprocesos seleccionados para determinar
si pueden cumplir sus objetivos de calidad y desempeño
f. Alimentar el repositorio de métricas de la organización con los datos del
desempeño y calidad real.
Los objetivos y prácticas son las siguientes:
Tabla 21. Administración de procesos cuantitativos - CMMI Nivel 4

Administrar el proyecto 1. Establecer los objetivos del proyecto
cuantitativamente 2. Ensamblar el proceso definido para el proyecto
El proyecto es 3. Seleccionar subprocesos a ser administrados
cuantitativamente estadísticamente
administrado usando 4. Administrar el desempeño del proyecto
objetivos de calidad y
desempeño
Administrar 1. Establecer métricas y técnicas de análisis
estadísticamente el 2. Aplicar métodos estadísticos para entender la
desempeño de los variación
subprocesos 3. Monitorear el desempeño de los subprocesos
El desempeño de los administrados
subprocesos 4. Registrar datos de la gestión estadística
seleccionados,
pertenecientes al proceso
definido del proyecto, es
administrado
estadísticamente
Nota: Recuperado de “CMMI Nivel 4: Administración Cuantitativa de Proyectos”, de

Arévalo, M., 15 de diciembre, 2011. Recuperado de https://arevalomaria.wordpress.com/
category/cmmi/
49
2. Desempeño del proceso de la organización: [23] explica que su principal
función es comprender cuál es la performance de los procesos de la organización
y emplear dicha información para administrar cuantitativamente los proyectos.
Esta área tiene un objetivo y cinco prácticas.
Tabla 22. Desempeño del proceso de la organización - CMMI Nivel 4

Se establece y mantiene 3. Definir criterios y guías para adaptar procesos
un conjunto de activos de 4. Establecer reposito organizacional de métricas
Nota: Recuperado de “CMMI Nivel 4: Desempeño del Proceso de la Organización”, de

Arévalo, M., 2 de septiembre, 2011. Recuperado de https://arevalomaria.wordpress.com/
category/cmmi/
50
INICIAL ADMINISTRADO DEFINIDO ADMINISTRACIÓN OPTIMIZADO
CUANTITATIVA
Esfuerzos Administración básica de Mejora continua del

Proceso de Estandarización Administración Cuantitativa
Heroicos proyecto proceso
1. Administración de 1. Administración de procesos 1. Innovación
1. Diseño 1. Requerimientos de desarrollo
Requerimiento cuantitativos Organizacional y despliegue
2. Desempeño de los procesos 2. Análisis Causal y
2. Desarrollo 2. Planificación del proyecto 2. Solución Técnica
de la organización Resolución
3. Monitoreo y control del
3. Integración 3. Integración del producto
proyecto
4. Administración de
4. Pruebas 4. Validación
acuerdos
5. Atención a los procesos
5. Medición y Análisis
organizacionales
6. Garantía de productos y 6. Definición de los procesos
proceso de calidad organizacionales
7. Formación de la organización
8. Administración de la
integración del producto
9. Administración de riesgos
10. Formar equipo de integración
11. Entorno organizacional para
la integración
Figura 4. Estándar del modelo CMMI
51
1.3.4.3.Modelo de PMI
[24] explica que El Project Management Institute® (PMI) ha definido un modelo de

realización de beneficios para que lo utilice un administrador de programas para ayudar a
la compañía a capturar las expectativas de una inversión. El concepto del modelo es
proporcionar una estructura desde la planificación inicial hasta la realización real (o
reserva) de los beneficios en un nuevo cambio de Business As Usual. Los cinco pasos son
estructuras poco estructuradas para ser jerárquicas en el flujo, pero permiten un enfoque
de elaboración progresiva a medida que más información esté disponible durante la
implementación del programa.
Figura 5. Beneficios del uso de PMI.
a. Identificación de Beneficios: Este paso es análogo a una sesión de lluvia de ideas y

dará como resultado una lista ajustada de los beneficios potenciales. Existen múltiples
formas para extraer esta información, incluidos documentos comerciales, sesiones de
lluvia de ideas, extracción de un plan de negocios, análisis de factores externos,
objetivos estratégicos de loa organización y conocimiento experto.
52
b. Análisis y planificación de beneficios: Este es el medio para estimar y medir los
beneficios. Si el paso de Identificación de beneficios produce una lista de beneficios,
entonces cada beneficio debe pasar un testing para ver si realmente califica como un
beneficio, o para ayudar a priorizar dichos beneficios. El resultado final de este paso
es el Plan de Realización de Beneficios (BRP), que evidencia formalmente las
actividades necesarias para lograr el objetivo planificado del programa.
c. Entrega de beneficios: Este es el medio para colocar realmente los cambios en la

organización y comenzar a ver los beneficios esperados en los fundamentos de
informes de negocios. Dado que los programas incluirán múltiples componentes, la
entrega será un proceso reiterado y comprenderá desde la finalización del primer
proyecto hasta el cierre del programa.
d. Transición de beneficios: Este es el medio para reconocer que los programas tienen
fines definidos y que los beneficios pueden realizarse mucho más allá del cierre del
programa. El Propietario de Beneficios eventualmente asignará la realización de
beneficios a una función de operaciones en la que mide los beneficios como parte de
un proceso de negocio como de costumbre. Esto implica que el monitoreo y control y
la acción prescriptiva asociada ya no son responsabilidad del Gerente del Programa,
sino del gerente de operaciones.
e. Mantenimiento de beneficios: Finalmente, los beneficios deben mantenerse durante

el ciclo de vida de la iniciativa de cambio. Muchas veces, los beneficios serán
pronósticos a lo largo del tiempo, como se define en la hoja de ruta de beneficios, y los
plazos se expandirán más allá de la vida útil del programa. Después de que los
beneficios son transiciones, necesitan ser sostenidos.
53
1.3.4.4.Modelo PMBOK
Según [25] define a PMBOK basado en la literatura de [26], indica que es una norma
norteamericana muy reconocida en el campo de la gestión de proyectos al punto que es
adoptada en muchos países. Así mismo continúa indicando que la guía del PMBOK
contiene el cuerpo de conocimiento o body of knowledge aplicable para desarrollar
profesionalmente la gerencia de proyectos o project management. Ese body of
knowledge incluye conocimiento probado y prácticas aplicadas ampliamente por
profesionales dedicados a esta actividad, además de las innovaciones de prácticas
avanzadas con un uso más limitado.
De acuerdo con ello tenemos que el modelo planteado de PMBOK es el siguiente
Figura 6. Modelo de gestión de proyectos de PMBOK -PMI
a. Gestión de Integración
Según plantea la [27] en su apartado de PMBOK, la Gestión de la Integración del

Proyecto engloba los procesos y actividades necesarios para identificar, definir,
combinar, unificar y coordinar todos los procesos de la gestión de proyectos.
54
Figura 7. Procesos de gestión de integración de PMBOK
[28] explica cada fase de la siguiente manera:
1. Acta de constitución: Consiste en desarrollar un documento que autoriza

formalmente un proyecto, así mismo documentar los requerimientos iniciales.
2. Plan de proyecto: consiste en documentar las acciones necesarias para definir,
preparar, integrar y coordinar los planes subsidiarios.
3. Monitorear y controlar el trabajo: su principal trabajo es monitorear, revisar
y regular el avance del proyecto, teniendo como objetivo, cumplir las metas
definidas en el acta de constitución.
4. Realizar el control integrado de cambios: su principal objetivo de esta fase es
revisar todas las solicitudes de cambios. También se centra en aprobar y
gestionar los cambios en cada entregable, en los activos de los procesos,
documentos del proyecto y en el plan de dirección del proyecto.
5. Cerrar el proyecto: su objetivo principal es finalizar las actividades en todos
los grupos de procesos de la dirección de proyectos.
55
b. Gestión del Alcance
Según [27], la gestión de alcance del proyecto incluye los procesos necesarios para
completarlos con éxito. Es decir que trabajo se va a realizar.
De acuerdo con [28] debemos definir alcance en dos divisiones siendo estas:
1. Alcance del producto: características y funciones que definen un producto,
servicio o resultado.
2. Alcance del proyecto: Trabajo que debe realizarse para entregar un producto,
servicio o resultado con características y funciones específicas.
Así entonces [28] refiere que el alcance del proyecto es más amplio que el alcance
del producto. La gestión del alcance del proyecto debe definir todos los procesos y
trabajos necesarios, de manera que el producto o servicio tenga las características y
funciones previstas.
[28] basada en la normal PMBOK de [27] explica que existen 6 procesos dentro de
la gestión del proyecto siendo estas:
1. Planificar la gestión de alcance: determina la creación de un plan de gestión

de alcance del proyecto, debiendo documentar como será definido, calidad y
controlado.
2. Recopilar requisitos: su función consiste en definir y documentar las
necesidades de los interesados, cumpliendo con los objetivos del proyecto.
3. Definir el alcance: implica una descripción detallada del proyecto del producto.
4. Crear la EDT/WBS: permite subdividir los entregables y el trabajo del
proyecto en componentes más pequeños y de fácil manejo.
5. Validar el alcance: su función es formalizar la aceptación de los entregables
del proyecto que se completaron.
6. Controlar el alcance: su función principal es monitorear el estado del alcance
del proyecto y el producto, así como los cambios a la línea principal del alcance
del proyecto.
56
1.3.5. Modelos de Calidad de Software
De acuerdo con [29] explican que, aunque modelo y metodología distan en su

definición, se rescata la cita dada por Moszkowitz (2010) en la que presenta una
metodología que permite a cualquier organización realizar una autoevaluación o
autodiagnóstico, por medio de una revisión sistemática de sus estrategias y prácticas
de gestión.
Por otro lado [30] menciona que los modelos de calidad son aquellos documentos que
integran la mayor parte de las mejores prácticas, proponen temas de administración en
los que cada organización debe hacer énfasis, integran diferentes prácticas dirigidas a
los procesos clave y permiten medir los avances en calidad.
Así mismo explican [29] que, en el ámbito de la construcción del software, el modelo
de calidad debe permitir evaluar el sistema, bien sea cualitativa o cuantitativamente y,
de acuerdo con esta evaluación la organización podrá propones e implementar
estrategias que permitan la mejora del proceso dentro de las etapas de análisis, diseño,
desarrollo y pruebas del software.
1.3.5.1.Modelos de Calidad a Nivel de Producto
1.3.5.1.1. Modelo Deming
El primer modelo, se desarrollar en Japón en 1951 por la JUSE (Unión Japonesa

de Científicos e Ingenieros). Este modelo recoge la aplicación práctica de las
teorías japonesas de Control Total de la Calidad (TQC) o control de calidad en
toda la empresa (CWQC).
El ciclo Deming, también conocido como círculo PDCA (de Edwards Deming),
corresponde a una estrategia de mejora continua de la calidad en cuatro etapas,
basado en un concepto de Walter A. Sewhart, denominado espiral de mejora
continua.
57
Las siglas PDCA son el acrónimo de Plan, Do, Check, Act (Planificar, Hacer,
Verificar, Actuar).
Figura 8. Ciclo PDCA de Deming
El modelo recoge diez criterios de evaluación de la gestión de la calidad de la

organización:
a. Políticas y objetivos: Se analiza cómo se establecen las políticas de

dirección, calidad y control de calidad, Y cómo se transmiten a todos los
sectores de la empresa. También se evalúa si los contenidos de esta política
son adecuados y se presentan con claridad.
Subcriterios:
i. Políticas de calidad y de control de calidad, y su lugar en la gestión

global del negocio.
ii. Claridad de las políticas (objetivos y mediciones).
iii. Métodos y procesos para el establecimiento de políticas.
iv. Relación de las políticas con los planes a corto y largo plazo.
v. Comunicación de las políticas, comprensión y gestión para
alcanzarlas.
vi. Liderazgo de los ejecutivos.
58
b. Organización: Se evalúa sí los campos de responsabilidad y autoridad
están bien definidos, además examina cómo está organizada la empresa
para llevar a cabo el control de la calidad.
Subcriterios
i. Idoneidad de la estructura organizativa.
ii. Claridad de la autoridad y responsabilidad.
iii. Situación de la coordinación interdepartamental.
iv. Situación de las actividades de comités y equipos de proyectos.
v. Situación de las actividades del personal.
vi. Relaciones con compañías asociadas.
c. Flujo de información y su utilización: se evalúa cómo se obtiene y

transmite la información, procedente del interior y exterior de la compañía,
En todos sus niveles y jerarquías. Se evalúa cuáles son los sistemas
empleados y la velocidad con la que la información es obtenida,
transmitida, evaluada y tratada.
Subcriterios
i. Idoneidad de la recepción y comunicación de información externa.
ii. Idoneidad de la recepción y comunicación de información interna.
iii. Situación de la aplicación de técnicas estadísticas para el tratamiento
de datos.
iv. Idoneidad de la conservación de la información.
v. Situación del uso de la información.
vi. Situación del uso de los ordenadores para el tratamiento de los datos.
d. Estandarización: Se evalúan los procedimientos para el establecimiento,

revisión y derogación de estándares y la forma en la que se controlan y
sistematizan, además del uso que se hace de los estándares para la mejora
de la tecnología de la empresa.
59
Subcriterios
i. Idoneidad del sistema de estándares.
ii. Procedimientos para establecer, revisar y eliminar estándares.
iii. Rendimiento actual en el establecimiento, revisión y eliminación de
estándares.
iv. Contenidos de los estándares.
v. Situación del uso y adherencia en los estándares.
e. Educación y su diseminación: se evalúa cómo se enseña lo que es el

control de calidad y cómo reciben los empleados el entrenamiento en
calidad, mediante cursos de formación o del trabajo diario. En esta métrica
se analiza el grado en el que el concepto de control de calidad y las técnicas
estadísticas han sido comprendidas y empleadas.
Subcriterios
i. Planes de formación y entrenamiento con sus resultados.
ii. Situación de la concientización en calidad y concientización en
gestión de trabajos del control de la calidad.
iii. Situación del soporte y motivación para el auto desarrollo y
autorrealización.
iv. Situación del entendimiento y uso de los conceptos y métodos
estadísticos.
v. Situación del desarrollo de los círculos de control de calidad y de las
sugerencias de mejora.
vi. Situación del soporte de desarrollo de los recursos humanos.
f. Aseguramiento de la calidad: Se evalúa el sistema de dirección para la

garantía de la calidad y se analizan con detalle todas las actividades
esenciales para garantizar la calidad y fiabilidad de los productos y
servicios, incluyendo fiabilidad. dichas actividades representan el
desarrollo de nuevos productos, análisis de la calidad, diseño, producción,
inspección, etc.
60
Subcriterios
i. Situación de la gestión del sistema de aseguramiento de la calidad.
ii. Situación del diagnóstico de control de la calidad.
iii. Situación del desarrollo de nuevos productos y tecnologías.
iv. Situación del control del proceso.
v. Situación del análisis de los procesos y de su mejora.
vi. Situación de la inspección, evaluación de la calidad y auditoría de
esta.
vii. Situación de la gestión de los equipos de producción, instrumentos
de medida y proveedores.
g. Gestión y control: Se evalúa cómo se realizan las revisiones periódicas de

los procedimientos empleados para el mantenimiento y mejora de la
calidad. También se evalúa como están definidas las autoridades y las
responsabilidades sobre las materias, y se evalúa el uso de gráficos y de
otras técnicas estadísticas.
Subcriterios
i. Rotación del ciclo de gestión (PDCA).
ii. Métodos para determinar los puntos de control.
iii. Situaciones de control interno.
iv. Situación de la toma de medidas temporales y permanentes.
v. Situación de sistemas de gestión operativos para costes, cantidades,
entregas, etc.
vi. Relación entre el sistema de aseguramiento de la calidad y otros
sistemas de gestión operativos.
h. Mejora: Se evalúa cómo se seleccionan y analizan los problemas críticos o

no relativos a la calidad y cuál es el uso que se hace de estos análisis.
Subcriterios
i. Método de selección de temas (problemas importantes y asignación
de prioridades).
ii. Enlace entre los métodos analíticos y la tecnología intrínseca.
61
iii. Situación del uso de métodos estadísticos para el análisis.
iv. Uso de los resultados de los análisis.
v. Situación de la confirmación de resultados de mejoras y su
transferencia actividades de mantenimiento y control.
vi. Contribución de las actividades de los círculos de control de calidad.
i. Resultados: Se evalúa los resultados producidos en la calidad de productos

y servicios gracias a la implantación del control de calidad, y si se están
produciendo y vendiendo bienes o servicios de suficiente calidad. Se
comprueba también si ha existido mejora en los productos y servicios
suministrados desde el punto de vista de la calidad coma del coste y de la
cantidad coma y también si la empresa en su conjunto ha mejorado.
Subcriterios
i. Resultados tangibles (como calidad, entrega, costos, beneficio,
seguridad y medio ambiente).
ii. Resultados intangibles.
iii. Métodos para medir y mantener resultados.
iv. Satisfacción de los clientes y de los empleados.
v. Influencia en compañías asociadas.
vi. Influencia en las comunidades locales e internacionales.
j. Planes para el futuro: Se evalúa si los puntos fuertes y débiles en la

situación actual son adecuadamente reconocidos, y en qué modo se realiza
la planificación para la mejora de la calidad.
Subcriterios
i. Situación del aseguramiento de las situaciones actuales.
ii. Planes futuros para mejorar problemas.
iii. Proyección de cambios en el entorno social y en los requisitos de los
clientes, y planes futuros basados en estos cambios proyectados.
iv. Relaciones entre la filosofía de la gestión, la visión y los planes a
largo plazo.
v. Continuidad de las actividades de control de calidad.
vi. Concreción de los planes futuros.
62
1.3.5.1.2. Modelo McCall
El modelo de Jim McCall, desarrollado inicialmente para la Fuerza Aérea de los Estados
Unidos en 1977 que tenía la misión de proporcionar las normas y orientación de técnicas
para la adquisición del software, es uno de los más renombrados actualmente. Este
modelo busca reducir la brecha entre usuarios y desarrolladores enfocándose en un
número de factores de calidad que reflejen las prioridades de ambos. El modelo
establece una jerarquía de Perspectivas (3), Factores (11), Criterios de Calidad (23) y
Métricas (41).
En ese sentido las perspectivas y sus respectivos factores de acuerdo con los planteado
por McCall son las siguientes.
Tabla 23. Capacidades y factores de calidad expuesta por McCall
CAPACIDAD FACTOR METRICA
Corrección: Grado de cumplimiento Compleción

de las especificaciones y objetivos del Consistencia
usuario
Trazabilidad
Complejidad
Consistencia
Confiabilidad: Grado en el sistema Exactitud
está disponible para usarse. Modularidad
Simplicidad
Operación del Tolerancia a errores
producto
Usabilidad: Grado de esfuerzo Facilidad de formación
necesario que se requiere para
aprender a utilizarlo. Operatividad
Integridad o Seguridad: Grado en el Facilidad de auditoria

que se controla el acceso al programa o Instrumentación
los datos por usuarios no autorizados. Seguridad
Eficiencia o Performance: Cantidad Concisión

de recursos y código requeridos por un Eficiencia de ejecución.
programa para realizar una función. Operatividad
Portabilidad: Grado que mide el Auto documentación
esfuerzo para migrar un programa de Generalidad
Transición del un entorno de operación a otro. Modularidad
producto Auto documentación
Reusabilidad: Grado de esfuerzo
Generalidad
requerido para que el programa o una
Independencia hardware
63
de sus partes pueda ser utilizado en Independencia del sistema
otro proyecto. Modularidad
Interoperabilidad: Grado de esfuerzo
dedicado para que un sistema o Comunicaciones
programa pueda operar juntamente con Estandarización de datos
otro.
Auto documentación
Facilidad Mantenimiento: Esfuerzo Concisión
requerido para localizar y corregir un Consistencia
error en un programa en Instrumentación
funcionamiento. Modularidad
Simplicidad
Auto documentación
Capacidad de expansión
Complejidad
Flexibilidad: Esfuerzo requerido para Concisión
Revisión del
modificar un software en
producto Consistencia
funcionamiento.
Generalidad
Modularidad
Simplicidad
Auto documentación
Facilidad de Prueba: Grado de Complejidad
esfuerzo requerido para probar un Facilidad de auditoria
programa verificando que realice Instrumentación
adecuadamente sus funciones. Modularidad
Simplicidad
En ese sentido exponemos la calidad de McCall de acuerdo a la Figura 9Figura 9
Figura 9. Atributos de la calidad McCall
64
1.3.5.1.3. Modelo FURPS
[31] explica que este modelo de calidad propuesto por Robert Grady y Hewlett Packard
Co (HP) en 1987. Sustenta por un lado 5 características de las cuales se deriva su
nombre (Funcionalidad, Facilidad de Uso, Confiabilidad, Performance y Facilidad de
Soporte), y por otro, que los requisitos se clasifiquen en dos categorías: requisitos
funcionales (F), que son los que especifican funciones que el sistema debe ser capaz de
realizar sin tener en cuenta las restricciones físicas; y requerimientos no funcionales
(URPS), que puntualizan atributos del sistema o del medio ambiente del sistema.
Este modelo incluye de una serie de pruebas para las distintas etapas del producto, los
usuarios pueden prueban el producto antes de colocarlo en producción y obtener un
“leed-back”. Asimismo, existe un plan de soporte definido que contiene una base de
datos con todos los errores registrados para poder subsanarlos.
[31] expone que el modelo FURPS incluye, además de los factores de calidad y los
atributos, restricciones de diseño y requerimientos de implementación, físicos y de
interfaz. Una limitación de este modelo de calidad explica [31] es que no tiene en cuenta
la portabilidad de los productos software que se estén considerando, factor muy
importante en función de las exigencias actuales que recaen sobre el proceso de
desarrollo del software.
Tabla 24. Tipos de requerimientos FURPS+
SIGLA TIPO DE REQUERIMIENTO DESCRIPCIÓN
Características, capacidades y
F Funtional Funcional
algunos aspectos de seguridad
Factores Humano (interacción),
U Usability Facilidad de uso
ayuda, documentación
Frecuencia de fallos, capacidad de
R Reliability Fiabilidad recuperación de un fallo y grado de
previsión
Tiempos de respuesta,
P Performance Rendimiento productividad, precisión,
disponibilidad, uso de los recursos
Adaptabilidad, facilidad de
mantenimiento,
S Supportability Soporte
internacionalizaciones, facilidad de
configuración
65
Limitación de recursos, lenguajes y
Implementación
herramientas hardware
Restricciones impuestas para la

Interfaz interacción con sistemas externos
(no es GUI)
+ Plus
Gestión del sistema, pautas
Operaciones
administrativas, puesta en marcha
Empaquetamiento Forma de distribución
Legales Licencia, derechos de autor, etc.
1.3.5.1.4. Modelo Gilb
[32] explican que el modelo de Gilb aparece alrededor de los años 1986 - 1988. Este
modelo utiliza el termino de ‘atributos’ los cuales hacen referencia a la medida de
calidad que determinado sistema (producto) a evaluar posee. El modelo muestra
especial interés en aquellos atributos de calidad que son de interés para el usuario
con miras a satisfacer los requerimientos o necesidades de éste. Los atributos que
GILB definió para establecer la calidad de un sistema son los siguientes:
a. Capacidad de trabajo: se busca medir la capacidad del sistema para ejecutar

tareas. Presenta como sub-atributos la capacidad de almacenamiento, capacidad
de proceso y capacidad de respuesta.
b. Disponibilidad: Mide la capacidad del sistema para ejecutar un trabajo de
forma útil
c. Adaptabilidad: Mide la capacidad que tiene el sistema para adaptarse a las
modificaciones.
d. Utilizabilidad: Mide que el nivel de facilidad con las que las personas serán
capaces y estarán motivadas para emplear el sistema.
66
Figura 10. Modelo de calidad Gilb
1.3.5.1.5. Modelo Boehm
Como lo explica [33], el modelo Boehm expuesto en 1978 agrega algunas

características a las existentes en el modelo McCall y representa una estructura
jerárquica de características, cada una de las cuales contribuye a la calidad total.
Este modelo consiste en un modelo de descomposición de características de calidad

de software en tres niveles, explica [33] se da en tres niveles: usos principales,
componentes intermedios y componentes primitivos, previos a la aplicación de
métricas. Este modelo plantea factores de calidad formados por criterios de calidad
y métricas respectivas.
Quality factor
Quality criteria
Quality metrics
Figura 11. Modelo Boehm
67
El modelo Boehm tiene como finalidad que, el software realice lo que requiere el
usuario, emplee los recursos informáticos de forma eficiente, sea de fácil uso y
aprendizaje y, sea bien diseñado, codificado, probado y mantenido.
Su modelo es similar al de McCall presentando una jerarquía de características, está

basado en un amplio rango de características e incorpora 19 criterios que incluyen
características de performance de hardware.
Las métricas directas e indirectas son usadas para determinar el nivel de acuerdo con
un criterio en particular que afecta a los principales factores de calidad, como
portabilidad, confiabilidad, facilidad de mantenimiento, facilidad de modificación.
Cada factor es descompuesto en varios criterios separados.
Por ejemplo, la facilidad de prueba y la eficiencia dependen directamente del

comportamiento de las interpretaciones específicas y constituyen propiedades
dinámicas.
Figura 12. Criterios y factores de calidad según Boehm
68
1.3.5.1.6. Modelo GQM (GOAL – QUESTION – METRIC)
El modelo GQM (objetivo-pregunta-métrica) de Basili y Romach (1998) explica

[33] que es una propuesta de objetivos y metas que están orientados a la definición
de modelos de calidad. Propone el paradigma GQM para evaluar el nivel de calidad
en cada proyecto, empleando una propuesta para definir un modelo de calidad hasta
alcanzar las métricas concordantes con el análisis e interpretación de los datos y
mediciones respectivas.
Expone [33] que, el enfoque GQM basa la mejora en la definición clara de procesos
y productos, proporcionando una estructura para alcanzar los objetivos cruciales del
proyecto. Consta de 3 etapa siendo estas:
a. Listar objetivos principales de desarrollo y mantenimiento del proyecto.

b. Cada objetivo debe contar con las preguntas que deben contestarse para saber si
los objetivos se están cumpliendo.
c. Decidir que medir para poder contestar las preguntas de manera adecuada, es
decir, desarrollar un conjunto de métricas que ayuden a responder la pregunta.
Figura 13. Métricas derivadas de los objetivos y preguntas GQM
[33] expone que la idea fundamental de GQM es la medición orientada a objetivos

y metas, la cual está basada en el contexto; de acuerdo con ello, el modelo tiene 3
niveles.
69
a. Nivel Conceptual (Goal): El objetivo o meta es definido para un propósito en
específico en base a las necesidades de la organización, teniendo en cuenta una
variedad de razones desde múltiples puntos de vista relacionados a un
ambiente en particular.
b. Nivel Operacional (Question): Representa un conjunto de preguntar que son
empleadas para caracterizar la forma de realización de una meta especifica.
c. Nivel Cuantitativo (Metric): Representa un conjunto de datos que están
asociados a toda pregunta de manera cuantitativa. Para realizar la
cuantificación se emplea un conjunto de métricas.
Tabla 25. Niveles de medición del modelo GQM
Quality Characteristic Subcharacteristic Metric

Question 11, Metric 1, Metric 2,
Goal1, Goal2, …, Goal n
Question 12 Metric 3, …, Metric n
1.3.5.1.7. Modelo SATC
[33] explica que, SATC desarrollo un modelo dinámico que permite la producción
de varios proyectos en desarrollo. Los datos del proyecto son usados para realizar
proyecciones acerca de los riegos y puntos de control del proyecto. Este modelo
utiliza un amplio rango de medidas métricas y; tiene objetivos, atributos y métricas
asociadas a los procesos de desarrollo y al software propiamente dicho. Este modelo
define un conjunto de metas u objetivos relacionados al producto de software y
atributos del proceso que permiten realizar indicadores de la probabilidad de éxito
de los objetivos.
Tabla 26. Metas, atributos y métricas según SATC
Meta Atributos Métricas

Nro. de frases claras
Ambigüedad
Nro. de frases opcionales
Calidad de los Integridad Nro. de TBDs/TBAs
requerimientos Facilidad de entender Estructura de documento
Volatilidad del Cantidad de cambios/cantidad de
requerimiento requerimientos
70
Etapa de clico de vida cuando se
realiza un cambio
Nro. de requerimientos del
software que no se ajustan a los
Trazabilidad requerimientos del sistema
Nro. de requerimientos del
software que no se ajustan al
código y a las pruebas
Estructura / Complejidad lógica. Uso de
Arquitectura GOTO tamaño
Facilidad de Correlación de complejidad /
Calidad del mantenimiento tamaño
producto Correlación de complejidad /
Reusabilidad
tamaño
Documentación interna Porcentaje de comentarios
Documentación externa Índice legible
Horas staff dedicadas a las
Uso de los recursos
Efectividad de la actividades del ciclo de vida
implementación Porcentaje de Tareas terminadas / tareas
terminación terminadas planificadas
Errores y criticidad
Efectividad de la Tiempo de encuentro de errores
Corrección
prueba Tiempo de errores fijos
Ubicación del código de falla
1.3.5.1.8. Modelo Dromey
Explica [33] que el modelo Dromey tiene el propósito de trabajar con una estructura
que permite construir y utilizar un modelo de calidad práctico para evaluar las etapas
de determinación de los requerimientos, diseño e implementación. La información
puede ser usada para elaborar, comparar y evaluar la calidad de los productos de
software. El modelo Dromey plantea la calidad del producto por medio de la
definición de sub-características que pueden ser medidas y evaluadas como
características. También, permite aumentar el entendimiento respecto de la relación
entre los atributos (características) y los sub-atributos de calidad.
Según [33] , Dromey propone 3 modelos para cada etapa del proceso de desarrollo:
un modelo de requerimientos, modelo de diseño y un modelo de calidad de la
71
implementación. Las características de calidad planteadas en este modelo son
eficiencia, confiabilidad, facilidad de mantenimiento, portabilidad, facilidad de uso
y funcionalidad.
Las características pueden ser agrupadas de acuerdo con diversos aspectos a tener en
cuenta en la implementación: corrección, aspectos internos, aspectos del contexto y
aspectos descriptivos.
Tabla 27. Agrupamiento de las características de calidad según Dromey
Correcciones Funcionalidad, Confiabilidad

Mantenibilidad, Eficiencia,
Interno
Confiabilidad
Implementación Mantenibilidad, Confiabilidad,
Contextual
Portabilidad
Mantenibilidad, Reusabilidad,
Descripción
Portabilidad, Usabilidad
Así mismo explica [33] que, Dromey propone una matriz que relaciona las
características de calidad respecto de la Norma ISO 9126-1. Dicha matriz presenta
un mapeo entre las características del producto y los atributos de alto nivel, el cual
es empleado en las evaluaciones del producto de software
1.3.5.1.9. Modelo C-QM
C-QM provee un modelo de calidad comprensivo que puede ser aplicado

efectivamente para evaluar diversos aspectos de la calidad del software, como
explica [33]. Este modelo consiste en factores de calidad, criterios y métricas. La
estructura de C-QM tiene 3 capas: factor, criterio y métrica
72
Tabla 28. Capas de estructura del Modelo de C-QM
Factor Criterio Métrica

Comunalidad Metric for commonality
Funcionalidad Adaptabidad Metric for suitability
Integridad
Metric for completeness
Modularidad Metric for commonality
Construido según Metric for modularity
Reusabilidad especificada
Comprensión Metric for customizability
Metric for comprehensiveness
Modularidad Metric for modularity
Facilidad de Abstrabilidad
Metric for interface
Mantenimiento Facilidad de cambio
abstractness
Metric for changeability
Conformidad standard Metric for standard
Conformidad respecto del conformance
Conformidad modelo de referencia
Metric for reference model
conformance
Este modelo de calidad de software, se definen 4 factores de calidad con sus

respectivos criterios y métricas.
1.3.5.1.10. Modelo SQAE (Sofware Quality Assessment Exercise)
Según explica [33], esta metodología fue desarrollada por MITRE Corporation y se
basa en el concepto de establecer una jerarquía en la cual los conceptos relacionados
al riesgo del ciclo de vida están compuestos de factores tangibles y medibles. Es una
metodología que permite cuantificar los riesgos asociados al software. SQAE provee
un conjunto de herramientas y métodos de evaluación que dan una medida
consistente de la calidad el software y sus riesgos asociados.
Así mismo explica [33] que el modelo SQAE está basado en el modelo de Boehm,
McCall y Dromey. Los factores se establecen en un contexto en el cual las métricas,
la documentación y la codificación pueden ser usadas para generar un perfil de las
fortalezas y debilidades del diseño y de la implementación del sistema
73
Por otro lado, explica [33] que, el objetivo de esta metodología es producir un
sistema de evaluación que satisfaga el objetivo de producir resultados confiables en
todas las etapas del ciclo de vida del software.
Quality area
Quality factor
Quality atributes
Metrics & measures
Figura 14. Jerarquía de la metodología SQAE
Está metodología plantea “factores de calidad” que sirven como base medible para
la definición de las 4 áreas de calidad (maintainability, evoluability, portability,
descriptiveness). Los factores de calidad (consistency, Independence, modularity,
documentation, self descriptiveness, anomaly control, design simplicity) son menos
abstractos que las áreas de calidad y proveen una estructura para medir la calidad de
un sistema.
[33] explica que las áreas de calidad se usan para definir los conceptos de riesgos del
ciclo de vida y se expresan como la suma de varios factores que abarcan aspectos
del concepto a medir.
El uso de porcentajes de factores de calidad deriva de las áreas de calidad. Por cada
factor de calidad se tiene definido un mapeo entre el factor de calidad y una o más
áreas de calidad de acuerdo con lo que explica en su análisis [33]
74
Tabla 29. Mapeo de áreas y factores de calidad de la metodología SQAE
Design Simplicity
Anomaly Control
Descriptiveness
Documentation
Independence
Consistency
Modularity
Self
Maintainability 20% 20% 15% 15% 15% 15%
Evoluability 20% 25% 25% 20% 10%
Portability 20% 25% 15% 40%
Descriptiveness 50% 50%
1.3.5.2.Modelos de Calidad a Nivel de Proceso
De acuerdo con [34] que explica que el producto de software de calidad surge de lo
eficaz y eficiente que puede ser el proceso de desarrollo, Se tiene la necesidad de
extender el concepto de calidad tanto procesos como productos y servicios de una
organización o una combinación de ellos.
Fue un proceso de calidad implica la definición correcta y el hecho que el producto

sirva para lo que sea específico cumpliendo con los objetivos por los cuales fueron
concebidos el proyecto.
La definición de un proceso de software implica determinar los objetivos, las personas

que estarán involucradas en el proceso, las entradas y salidas para el proyecto, los
criterios de entrada y salida las actividades, Los métodos, las herramientas , y el modelo
que se empleará como base para el desarrollo del proyecto, así como sus mediciones
para verificar finalmente los resultados y obtener un producto de calidad.
1.3.5.2.1. ITIL
[29] explica que este modelo fue desarrollado en el Reino Unido, tiene el fin de
fortalecer la gestión gubernamental, a partir de cinco elementos dentro de los que
se destacan: la perspectiva del negocio, entrega de servicio, soporte al servicio,
manejo de la infraestructura y manejo de aplicaciones, con el propósito de ofrecer
una estructura integral para presentar a la organización un servicio completo,
75
cubriendo necesidades de apoyo de instalación, adecuación de redes,
comunicaciones, hardware, servidores, sistema operativo y software necesarios.
Figura 15. Ciclo de ITIL
1.3.5.2.2. ISO/IEC 15504
Permite adicionar la evaluación para procesos en pequeñas y medianas empresas y

en grupos pequeños de desarrollo mediante el uso de seis niveles de madurez dentro
de los que se destacan.
a. Nivel 0: Organización inmadura

b. Nivel 1: Organización básica
c. Nivel 2: Organización gestionada.
d. Nivel 3: Organización establecida.
e. Nivel 4: Organización predecible
f. Nivel 5: Organización Optimizado
[35] describe que la norma ha sido denominada Determinación de la capacidad

de mejora de los procesos de software proponiendo un modelo para la evaluación
de la capacidad en los procesos de desarrollo del producto de software.
La norma ISO/IEC 15504 establecer los requisitos necesarios para una evaluación
de procesos, así como también de los modelos de evaluación, permitiendo que los
requisitos que establece sean adaptados en cualquier modelo de evaluación de una
empresa. Estos requisitos comprenden:
76
a. Evaluación de procesos
b. Mejora de los procesos
c. Evaluar la capacidad y madurez de los procesos
Figura 16. Modelo ISO/IEC 15504 – Certificación SPICE
1.3.5.2.3. Bootstrap
[36] La metodología BOOTSTRAP es el resultado de un proyecto europeo basado

en el modelo CMM e ISO 9000. Este proyecto proporciona una alternativa para las
organizaciones que requieren mejorar su proceso de desarrollo de software,
alcanzando la certificación ISO.
Esta metodología engloba la evaluación para establecer el diagnóstico de un

proceso para e desarrollo de software (incluye la planeación, los métodos y la
capacidad de ingeniería, las herramientas y su tecnología), además de la creación
de un plan de acción que define los pasos, los detalles de la implantación y de
marcos temporales para que la organización aumente su capacidad de entrega de
productos y servicios con atributos de calidad.
De acuerdo con [37], los objetivos de la metodología BOOTSTRAP son:
a. Brindar soporte para la evaluación de la capacidad de los procesos empleando

un conjunto de prácticas de ingeniería de software.
77
b. Incluir estándares reconocidos internacionalmente como fuentes para la
identificación de las prácticas a considerar.
c. Dar soporte a la evaluación indicando cómo el estándar de referencia ha sido
empleado en la organización.
d. Asegurar la fiabilidad y la capacidad de repetición de la evaluación.
e. Identificar las fortalezas y debilidades de los procesos de la organización.
f. Brindar soporte a la creación y aplicación de un plan de mejora que genere
resultados aceptables de forma que permita alcanzar los objetivos de la
organización.
Bootstrap se enfoca [37] en evaluar una organización y sus proyectos

proporcionando perfiles analíticos para cada uno de ellos de forma tal que permita
establecer madurez en los procesos identificando los puntos fuertes y débiles,
realizar un plan de alto nivel de las acciones recomendadas para conseguir la
mejora a partir de los perfiles analíticos y transformar el plan en una serie de mini
proyectos para implementar las mejoras planteadas anteriormente.
Bootstrap emplea de 5 niveles de madurez para indicar el nivel en el que se

encuentra la organización por lo que se emplean diferentes escalas para medir las
fortalezas y debilidades y marcar las pautas de mejora este proceso se divide en 3
categorías dentro de los que se destacan la organización, metodología y tecnología.
Asimismo, cada categoría comprende un conjunto de áreas de procesos orientadas

a obtener el mismo objetivo general, por último, cada proceso se divide en
actividades y estás en prácticas base.
78
Figura 17. Modelo de procesos Bootstrap
1.3.5.2.4. Personal Software Process (PSP)
De acuerdo con [29] explica que este modelo se enfoca al desarrollo profesional de
ingeniero desarrollando una adecuada administración de calidad de los proyectos
de desarrollo minimizando los efectos del producto estimación mi planificación del
trabajo.
Este modelo está diseñado para eh ser utilizado en organizaciones que emplean
modelos como CMMI o ISO 15504.
PSP tiene una restricción considerada como deficiencia en la toma de datos y

elaboración de tablas.
79
1.3.5.2.5. Team Software Process (TSP)
[29] explica que el TSP, es la siguiente etapa al PSP, está diseñado para el trabajo
de equipos de desarrollo de software, que se orientan al desarrollo de productos
minimizando los defectos en tiempo y costos estimados.
Cuenta con planes detallados y procesos como revisiones personales, índices de

desempeño de calidad y la integración del equipo.
1.3.5.2.6. CMMI (Capability Maturity Model Integration)
CMMI que significa Integración de modelos de madurez de capacidades o por sus

siglas en inglés Capability Maturity Model Integration es un modelo de madurez
de mejora de los procesos para el desarrollo de productos y de servicios. Consiste
en las mejores prácticas que cubren el ciclo de vida del producto, desde la
concepción a la entrega y el mantenimiento. Todas las prácticas del modelo CMI
se centran en las actividades de la organización desarrolladora. Cinco de estas áreas
se centran específicamente en prácticas del desarrollo: tratando desarrollo de
requisitos, solución técnica, integración del producto, verificación y validación.
Los modelos CMMI no son procesos ni descripciones de éstos, sino que son
utilizados en organizaciones las cuales dependen de diversos factores, incluyendo
dominios de aplicación y estructura, así como del tamaño de la organización, lo
que permitió que éstas últimas experimentaran un crecimiento en productividad y
calidad, mejorando la duración del ciclo de vida logrando planificaciones y
presupuestos más precisos y previsibles.
A. Evolución de CMMI
Al inicio CMMI era un modelo que combinaba tres modelos fuente: Capability
Maturity Model for Software(SW-CMM) V2.0, el System Engineering
Capality Model (SECM), y el Integrated Product Development Capability
Maturity Model (IPD-CMM); los cuales fueron seleccionados debido al éxito
80
en su adopción o por su prometedor enfoque para mejorar los procesos en una
organización.
En principio el modelo CMM era aplicado en programas de defensa, pero
debido a la gran aceptación se llevó a cabo el desarrollo de modelos CMM para
para diversos ámbitos más allá del software.
El problema con esto es que debido a la gran proliferación de modelos de

desarrollo de software comenzaron a surgir confusiones, motivo por el que el
gobierno terminó financiando un proyecto de dos años en que el participaron
más de 200 expertos del mundo industrial y académico, con el fin de crear un
solo marco extensible para la ingeniería de sistemas, la ingeniería de software
y el desarrollo de productos ¿el resultado? El modelo más conocido
actualmente: CMMI.
El primer modelo CMMI (V1.02) diseñado para usarse por organizaciones de

desarrollo en su búsqueda de la mejora de procesos para toda la empresa, el
cual fue publicado en el 2000, para dos años después emitió la versión 1.1 y
luego de cuatro años se publicó la versión 1.2
Figura 18. Historia de CMMI. Evolución desde la versión 1.1. que

establece Capability Maturity Model Integration desde 1993 hasta
2010. Extraído de [50]
81
En el 2007 se publicó el modelo CMMI para adquisición; Como fue elaborado
a partir de la versión 1.2 del modelo CMMI para Desarrollo, también se
denominó versión 1.2. Dos años más tarde se publicó el modelo CMMI para
Servicios. Como fue construido sobre los otros dos modelos, también fue
denominado versión 1.2. En 2008 se realizaron planes para comenzar a
desarrollar la versión 1.3, que aseguraría la consistencia entre los tres modelos
y mejoraría el material de alta madurez en todos los modelos.
B. Alcance de CMMI para el desarrollo

El CMMI para el desarrollo es un modelo de referencia que cubre las actividades
del desarrollo y del mantenimiento aplicadas tanto a los productos como a los
servicios. Las organizaciones de numerosos rubros como son bancos,
supermercados, empresas dedicadas al desarrollo de software, la defensa, la
fabricación del automóvil y las telecomunicaciones, utilizan el CMMI para
desarrollo, las cuales contienen prácticas que cubren la gestión de proyectos, la
gestión de procesos, la ingeniería de sistemas, la ingeniería del hardware, la
ingeniería de software y otros procesos de soporte utilizados en el desarrollo y
el mantenimiento. El modelo CMMI para desarrollo + IPPD cubre también la
utilización de equipos integrados que están implicados en las actividades de
desarrollo y mantenimiento (IPPD).
La importancia del uso de un modelo radica principalmente en el hecho de que

es precisamente lo que permite comprender cuáles son los elementos específicos
de una organización, a la vez que ayuda a formular y hablar de qué es lo que se
debe mejorar dentro de la misma y de cómo se pueden lograr dichas mejoras.
Por lo que tiene las siguientes ventajas que se deben destacar:
a. Proporciona un marco y un lenguaje común, lo que se traduce en la ruptura

de las barreras de la comunicación en el interior de las organizaciones.
b. Permite que los usuarios puedan enfocarse específicamente en la mejora, ya
que ayudan a que no pierdan la idea global.
c. Aporta años de experiencia.
d. Ayudan a mejorar la satisfacción del cliente.
82
e. Permiten producir productos y servicios de alta calidad.
a. Niveles de Madurez
Es representado por un camino consecutivo de pasos en la capacidad de los
procesos, los que permiten medirlos contra un grupo predefinidos en niveles los
que a su vez sirven como base para alcanzar el siguiente escalón superior y éste
en otro de más alto nivel y así sucesivamente. Esta clasificación se realiza
satisfaciendo los objetivos genéricos y específicos de las áreas de procesos
agrupadas en el nivel correspondiente. Así para llegar al nivel 3 deberán cumplir
todos los objetivos específicos de los niveles 1,2 y 3.
i. Nivel 1: Inicial o No Gestionado

El éxito va a depender del rendimiento de los individuos involucrados en el
proyecto, los procesos son informarles e impredecibles. Las organizaciones
con un nivel de madurez 1 a menudo se producen los productos y servicios
que funcionan; sin embargo, frecuentemente exceden el presupuesto y el
calendario de sus proyectos y se caracterizan por una tendencia a cometer,
abandonar los procesos en el momento de la crisis, y no ser capaz de repetir
sus éxitos pasados.
Figura 19. Niveles de Madurez de CMMI. Representa los escalones que establece CMMI
Institute para poder alcanzar una optimización en los procesos dentro de una organización.
83
ii. Nivel 2: Gestionado
Se realizan tareas básicas de gestión de proyectos y actividades para

realizar un seguimiento y control básico del proyecto, así se puede
implementar aquellos elementos exitosos de la gestión en otros
proyectos similares.
En otras palabras, los proyectos de la organización han asegurado que
los requisitos son gestionados y de que los procesos se planifican,
realizan, medido y controlado.
La disciplina de los procesos reflejados por nivel de madurez 2 ayuda a
garantizar que se conserven las prácticas existentes en los momentos de
estrés. Cuando estas prácticas están en su lugar, los proyectos se realizan
y administran conforme a sus planes documentados correspondientes.
En el nivel de madurez 2, los requisitos, los procesos, los productos de
trabajo, y los servicios son administrados. El estado de los productos de
trabajo y la prestación de servicios son visibles a la gestión en puntos
definidos.
Los compromisos establecidos entre las partes interesadas y son
revisados en la medida necesaria. Productos de Trabajo son objeto de
examen con las partes interesadas y están controlados. Los productos de
trabajo y servicios satisfacen sus requisitos especificados, las normas y
objetivos.
iii. Nivel 3: Definido
Se centra en la estandarización y despliegue a nivel organizacional de

los procesos. Cada proyecto tiene un proceso de gestión que se adaptaría
a los requisitos del mismo partiendo de un conjunto de procesos
organizativos. Una diferencia fundamental entre el nivel de madurez 2 y
el nivel de madurez 3 es el ámbito de los estándares, las descripciones
de los procesos y procedimientos. En el nivel de madurez 2, los
estándares, las descripciones de los procesos y los procedimientos
pueden ser bastante diferentes en cada una de las instancias específicas
del proceso (por ejemplo, en un proyecto en particular).
84
En el nivel de madurez 3, los estándares, las descripciones de los
procesos y procedimientos de un proyecto se diseñan a partir del
conjunto de procesos estándar de la organización para adaptarse a un
determinado proyecto o unidad organizativa. El conjunto de procesos
estándar de la organización incluye los procesos abordados en el nivel
de madurez 2 y el nivel de madurez 3. Como resultado de ello, los
procesos que se llevan a cabo en toda la organización son compatibles
excepto por las diferencias de la sastrería.
Otra diferencia fundamental es que en el nivel de madurez 3, los
procesos son normalmente se describe con más detalle y más rigurosa
que en el nivel de madurez 2. En el nivel de madurez 3, los procesos son
gestionados de manera más proactiva, usando la comprensión de las
relaciones de las actividades del proceso y las medidas detalladas del
proceso, sus productos de trabajo y sus servicios.
iv. Nivel 4: Administrado cuantitativamente
Existe una metodología cuantitativa para controlar los subprocesos, que

son las medidas de procesos recopiladas deben ser utilizadas en la
gestión de procesos.
En el nivel de madurez 4, se seleccionan los que contribuyen de forma
significativa al rendimiento del proceso en general. Estos subprocesos
están controlados mediante técnicas estadísticas y otras técnicas
cuantitativas.
Objetivos cuantitativos de calidad y rendimiento de los procesos se
establecen y se utilizan como criterios para la gestión de procesos. Los
objetivos cuantitativos se basan en las necesidades del cliente, los
usuarios finales, la organización, y los responsables de la
implementación de los procesos. Calidad y rendimiento de los procesos
se entienden en términos estadísticos y se administran a lo largo de la
vida de los procesos.
Para estos procesos, las medidas detalladas del rendimiento de los
procesos son recogidos y analizados estadísticamente. Causas Especiales
85
de variación de procesos se identifican y, en su caso, las fuentes de
causas especiales están corregidos para evitar que se repita en el futuro.
Calidad y rendimiento de los procesos se hayan incorporado las medidas
en la organización del repositorio a medida soporte de toma de
decisiones basadas en el futuro.
Una diferencia fundamental entre el nivel de madurez 3 y el nivel de
madurez 4 es el grado de previsibilidad del rendimiento de los procesos.
En el nivel de madurez 4, el rendimiento de los procesos se controla
mediante técnicas estadísticas y otras técnicas cuantitativas, por lo que
es previsible cuantitativamente hablando. En el nivel de madurez 3, los
procesos son sólo cualitativamente predecibles.
v. Nivel 5: Optimizado
La organización utiliza medidas de los procesos para dirigir su mejora

de procesos. Las tendencias se analizan y los procesos modificados y
adaptados a las necesidades de negocio. Este nivel se centra en mejora
continua del rendimiento de los procesos a través de los aumentos y
mejoras tecnológicas innovadoras.
Los objetivos cuantitativos de mejora de procesos para la organización
se establecen y se revisan de forma continua a fin de reflejar los cambios
objetivos de negocio, y se utilizan como criterios para la administración
de la mejora de procesos.
Los efectos de las mejoras implementadas en los procesos se miden y
evalúan en relación con los objetivos cuantitativos de mejora de
procesos. Tanto los procesos definidos como el conjunto de procesos
estándar de la organización son objetivos para las actividades de mejora
considerables.
Optimización de los procesos ágiles e innovadores, depende de la
participación de un personal capacitado y alineado con los valores y
objetivos empresariales de la organización. La capacidad de la
organización para responder con rapidez a los cambios y oportunidades
se mejora mediante la búsqueda de formas para compartir y fomentar el
86
aprendizaje. Mejora de los procesos es, inherentemente, un papel que
todo el mundo tiene que jugar, lo que se traduce en un ciclo de mejora
continua.
Una diferencia fundamental entre el nivel de madurez 4 y el nivel de
madurez 5 es el tipo de variación de procesos. En el nivel de madurez 4,
los procesos se encargan de causas especiales de variación de procesos
y proporcionan estadísticas para prever los resultados. A pesar de que
los procesos pueden producir resultados previsibles, los resultados
pueden no ser suficientes para alcanzar los objetivos establecidos. En el
nivel de madurez 5, los procesos se encargan de causas comunes de la
variación de procesos y el cambio de los procesos (es decir, el cambio
del medio de rendimiento del proceso) para mejorar el rendimiento (al
mismo tiempo que mantiene estadísticas para prever) para alcanzar los
objetivos cuantitativos de mejora de procesos.
1.3.6. Evaluación de Calidad de proyectos
1.3.6.1.ISO/IEC 25000:2014
ISO/IEC 25000, conocida como SQuaRE (System and Software Quality

Requirements and Evaluation), es una familia de normas que tiene por objetivo la
creación de un marco de trabajo común para evaluar la calidad del producto
software.
[38] La familia ISO/IEC 25000 es el resultado de la evolución de otras normas

anteriores, especialmente de las normas ISO/IEC 9126, que describe las
particularidades de un modelo de calidad del producto software, e ISO/IEC 14598,
que abordaba el proceso de evaluación de productos software. Esta familia de
normas ISO/IEC 25000 se encuentra compuesta por cinco divisiones.
87
Figura 20. División del estándar ISO/IEC 2500n. La norma SQuaRE
plantea 4 divisiones para el control de la calidad e software y su
evaluación
1.3.6.2.ISO/IEC 2500n- División de gestión de calidad
Las normas que conforman este apartado definen todos los modelos, términos y
definiciones comunes referenciados por todas las otras normas de la familia 25000.
Actualmente esta división se encuentra formada por:
a. ISO/IEC 25000 - Guide to SQuaRE: contiene el modelo de la arquitectura de

SQuaRE, la terminología de la familia, un resumen de las partes, los usuarios
previstos y las partes asociadas, así como los modelos de referencia.
b. ISO/IEC 25001 – Planning and Management: establece los requisitos y
orientaciones para gestionar la evaluación y especificación de los requisitos del
producto software.
1.3.6.3.ISO/IEC 2501n – División de Modelo de Calidad
Las normas de este apartado presentan modelos de calidad detallados incluyendo

características para calidad interna, externa y en uso del producto software.
Actualmente esta división se encuentra formada por:
88
a. ISO/IEC 25010 – System and Software Quality models: describe el modelo de
calidad para el producto software y para la calidad en uso. Esta norma presenta
las características y sub-características de calidad frente a las cuales evaluar el
producto Software.
b. ISO/IEC 25012 – Data Quality model: define un modelo general para la calidad
de los datos, aplicable a aquellos datos que se encuentran almacenados de
manera estructurada y forman parte de un sistema de información.
89
Figura 21. Calidad de producto de software. Niveles de categoría y subcategoría que debe de cumplir un producto de software para determinar el nivel de calidad de acuerdo al ISO/IEC
25010. Extraído de [38]
90
De acuerdo con ello podríamos indicar que cada punto de ello tiene un
fin que permite medir correctamente el proceso de calidad así tenemos:
a. Adecuación Funcional: [38] Representa la capacidad del software

para proporcionar funciones que satisfacen las necesidades
declaradas e implícitas. Esta característica se subdivide en
completitud funcional, corrección y pertinencia funcionales.
Figura 22. Adecuación Funcional. De acuerdo con la ISO 25010 estos son las características que debe cumplir
para aprobar con esta categoría.
b. Eficiencia de desempeño: [38] Esta característica representa el

desempeño referente a la cantidad de recursos empleados bajo
ciertas condiciones. Esta característica se subdivide en
comportamiento temporal, utilización de recursos y capacidad.
c. Compatibilidad: [38] Capacidad de dos o más sistemas o

componentes para intercambiar información y llevar a cabo
funciones requeridas cuando se comparte el mismo entorno. Esta
característica se subdivide en coexistencia e interoperabilidad.
91
Figura 23. Eficiencia de desempeño. Evalúa el nivel de uso de los recursos y de acuerdo con la ISO/IEC
cumplen con las siguientes categorías
Figura 24. Compatibilidad. De acuerdo con la ISO/IEC es el nivel de intercambio de información entre
componentes y se subdividen con las subcategorías descritas
92
d. Usabilidad: [38] Capacidad del producto de software para ser
atendido, aprendido, empleado y, además de ser atractivo para el
usuario. Esta característica se subdivide en Capacidad para
reconocer su adecuación, capacidad de aprendizaje, capacidad para
ser usado, protección contra errores de usuario, estética de la
interfaz de usuario y accesibilidad.
Figura 25. Usabilidad. De acuerdo con la ISO/IEC se deben de cumplir con las siguientes subcategorías
e. Fiabilidad: [38] Capacidad de un sistema o componente para

desempeñar las funciones determinadas, cuando se usa bajo unas
condiciones y periodo de tiempo establecidos. Esta característica se
subdivide en Madurez, disponibilidad, tolerancia a fallos y
capacidad de recuperación.
93
Figura 26. Fiabilidad, La ISO/IEC 25010 determina que estás son las subcategorías de debe de cumplirse para
obtener Fiabilidad en el producto de software
f. Seguridad: [38] Capacidad de protección de la información y los

datos de manera que cualquier persona o sistema no autorizado no
puedan leerlos o modificarlos. Cuando se emplea se subdivide en
Confidencialidad, integridad, no repudio, responsabilidad,
autenticidad
Figura 27. Seguridad. De acuerdo con la ISO/IEC, determina que las siguientes subcategorías se deben cumplir
para aprobar la categoría de seguridad por la normal SQuaRE
94
g. Mantenibilidad: [38] Representa la capacidad del producto de
software para ser modificado efectiva y eficientemente, debido a
necesidades evolutivas, correctivas o perfectivas. Cuando se
emplea se subdivide en: Modularidad, reusabilidad, analizabilidad,
capacidad para ser modificar y capacidad para ser aprobado
Figura 28. Mantenibilidad. De acuerdo con la norma SQuaRE, la categoría de mantenibilidad se cumplirá si se
integran las siguientes subcategorías
1.3.6.4.ISO/IEC 2502n – División de medición de calidad
[38] explica que estas normas incluyen un modelo de referencia de la medición

de la calidad del producto, definiciones de medidas de calidad (interna, externa
y en uso) y guías prácticas para su aplicación. Actualmente esta división se
encuentra formada por:
a. ISO/IEC 25020 - Measurement reference model and guide: presenta una

explicación introductoria y un modelo de referencia común a los elementos
de medición de la calidad. También proporciona una guía para que los
95
usuarios seleccionen o desarrollen y apliquen medidas propuestas por
normas ISO.
b. ISO/IEC 25021 - Quality measure elements: define y especifica un
conjunto recomendado de métricas base y derivadas que puedan ser usadas
a lo largo de todo el ciclo de vida del desarrollo software.
c. ISO/IEC 25022 - Measurement of quality in use: define específicamente
las métricas para realizar la medición de la calidad en uso del producto.
d. ISO/IEC 25023 - Measurement of system and software product quality:
define específicamente las métricas para realizar la medición de la calidad
de productos y sistemas software.
e. ISO/IEC 25024 - Measurement of data quality: define específicamente las
métricas para realizar la medición de la calidad de datos.
1.3.6.5.ISO/IEC 2503n – División de requisitos de calidad
Las normas que forman este apartado, explica [38], ayudan a especificar
requisitos de calidad que pueden ser utilizados en el proceso de licitación de
requisitos de calidad del producto software a desarrollar o como entrada del
proceso de evaluación. Para ello, este apartado compone de:
a. ISO/IEC 25030 – Quality requirements: provee de un conjunto de

recomendaciones para realizar la especificación de los requisitos de
calidad del producto software.
1.3.6.6.ISO/IEC 2504n – División de evaluación de calidad
Este apartado incluye normas que proporcionan requisitos, recomendaciones

y guías para llevar a cabo el proceso de evaluación del producto software tal
como explica [38]. Esta división se encuentra formada por:
a. ISO/IEC 25040 - Evaluation reference model and guide: propone un

modelo de referencia general para la evaluación, que considera las
96
entradas al proceso de evaluación, las restricciones y los recursos
necesarios para obtener las correspondientes salidas.
b. ISO/IEC 25041 - Evaluation guide for developers, acquirers and
independent evaluators: describe los requisitos y recomendaciones para la
implementación práctica de la evaluación del producto software desde el
punto de vista de los desarrolladores, de los adquirentes y de los
evaluadores independientes.
c. ISO/IEC 25042 - Evaluation modules: define lo que la Norma considera
un módulo de evaluación y la documentación, estructura y contenido que
se debe utilizar a la hora de definir uno de estos módulos.
d. ISO/IEC 25045 - Evaluation module for recoverability: define un módulo
para la evaluación de la sub característica recuperabilidad
(Recoverability).
1.4.Formulación del problema
¿En qué medida un modelo de gestión de los proyectos de desarrollo de software y

el control de calidad, reducirán el riesgo de fracaso de un proyecto de Software para
PYME’S peruanas?
1.5. Justificación e importancia del estudio
Hoy día en las organizaciones es un problema el no cuantificar la cantidad de

mantenimiento, trabajo adicionales (reprogramaciones) que se realizan producto del
desarrollo de mala calidad, o no se mide el impacto de estos malos proyectos, muchas
veces por querer dar una respuesta rápida a los usuarios nos enfrentamos más
adelante a situaciones críticas como aspectos financieros (errores de facturación,
etc.), costos (hora/hombre invertidas en reparar lo hecho, etc.) o de seguridad, sólo
por mencionar algunos. Es por ello que el presente proyecto aporta un modelo de
gestión y control de calidad que brinda un marco de trabajo para futuros proyectos
en el área de Ingeniería de software como área de estudio, así como también a las
industrias peruanas pequeñas y medianas del sector de desarrollo de software,
97
permitiendo la entrega de productos con el menor riesgo posible y con atributos
mayores de calidad.
1.6. Hipótesis
Un Modelo de gestión de los proyectos de desarrollo para el control de la calidad

reducirá el riesgo de fracaso de un proyecto de Software para PYME'S peruanas.
1.7. Objetivos
1.7.1. Objetivo General
Desarrollar un modelo de gestión de proyecto de desarrollo de software y control

de calidad para PYME’s peruanas de desarrollo de software
1.7.2. Objetivos Específicos
a. Analizar el sector de desarrollo de software peruano.

b. Seleccionar las normas y guías de buenas prácticas para la gestión y el
control en el desarrollo de software.
c. Establecer métricas para la evaluación de la gestión del proyecto y el
control de la calidad.
d. Proponer un modelo de gestión de proyectos de desarrollo de software y
control de calidad para PYME’s peruanas.
e. Validar el modelo de gestión de proyectos de desarrollo de software y
control de calidad para PYME’s peruanas planteado mediante juicio de
expertos
98
CAPITULO II
99
CAPITULO II: MATERIAL Y MÉTODO
2.1.Tipo de estudio y diseño de la investigación
La presente investigación es de tipo Cualitativa, de diseño no Experimental, según

[39] refieren que la investigación de tipo cualitativa se enfoca en comprender los
fenómenos, explorándolos desde la perspectiva de los participantes en un
ambiente natural y en relación con su contexto. Así mismo contemplan, en base a
otros autores, que este enfoque de investigación se selecciona cuando el propósito
es examinar la forman en la que los individuos perciben y experimentan los
fenómenos que los rodea, profundizando en sus puntos de vista, interpretaciones
y significados.
Es por ello por lo que en éste trabajo de investigación busca comprender la

particularidad de los caracteres específicos que comprenden el objeto de estudio,
las PYME’s peruanas de desarrollo de software.
Por otro lado, el concepto de diseño de tipo no experimental según [39] basados
en la recolección de diferentes autores, concluye indicando que este tipo de diseño
de investigación se centra en analizar cuál es el nivel o modalidad de una o
diversas variables en un momento dado, evaluar su situación, comunidad, evento,
fenómeno o contexto, así como también determinar cuál es la relación entre un
conjunto de variables.
2.2. Escenario de estudio
Para esta investigación el escenario de estudio son las PYME’s peruanas que
cumplan con la característica de estar orientadas al rubro tecnológico, por el
ámbito de desarrollo de software.
100
2.3. Caracterización de sujetos
El sujeto de estudio corresponde a las PYME’s peruanas, para la investigación de los

estándares generales y específicos, se contó con el apoyo de dos PYME’s dedicadas
al desarrollo tecnológico y de software en la industria peruana.
Dichas PYME’s solicitaron total discreción con respecto a su nombre y entidad por
lo que las nombraremos como Pyme1 y Pyme 2; se consideró para esta investigación
tomar ciertos criterios que conllevan a realizar el estudio de Gestión de proyectos y
control de calidad en productos de software en esta organización.
Pyme1 es una empresa de creatividad tecnológica que ofrece productos de software

para el manejo de salas de juego, soluciones tecnológicas en general. Su ubicación
es en la ciudad de Lima.
Pyme2 es una empresa dedicada al desarrollo de productos de software, brindando

soluciones rápidas y accesibles para el manejo de gestiones empresariales. Su
ubicación es en la ciudad de Tacna
Para ambas PYME’s se contó con:
a. Acceso a la organización: Se cuenta con el apoyo de las organizaciones para

poder observar y evaluar el nivel de calidad actual del área de desarrollo, así como
los proceso, productos, y mediciones internas.
b. Evolución de avance: Se podrá medir el avance paulatino del uso constante del
modelo planteado.
c. Trato directo con personal: Se podrá obtener la información de primera mano,
pues se podrá conversar con el jefe de proyectos y su personal desarrollador.
d. Accesos a proyecto de desarrollo: la organización ha permitido participar en el
uso del modelo para un entregable de software.
2.4. Técnicas e instrumentos de recolección de datos
Para la siguiente investigación se consideraron los siguientes técnicas e instrumentos

de recolección de datos:
101
Tabla 30. Técnicas e instrumentos de recolección de datos
TECNICA DESCRIPCION INSTRUMENTO

Se entrevistó los jefes de proyectos de
ambas pymes con el fin de recabar la
Entrevista Encuestas
información del manejo de sus
procesos internos de gestión y control
Se realizó el proceso de observación
de los procesos que emplea el área
para desarrollar el trabajo en cuestión,
así como también las características
que contempla un proyecto: costo,
alcance, tiempo. Ficha de
Observación
Observación
Por otro lado, también se observará el

proceso durante el uso del modelo de
gestión y control de calidad (MGC)
hasta el culminar el proyecto.
2.5. Procedimientos para la recolección de datos
Para la siguiente investigación el proceso mediante el cual se obtendrá la información

se realizó por:
a. Proceso de Observación: se tomó nota de los procesos que llevan iniciando la

investigación, así como también su evolución en la implementación del nuevo
modelo de gestión de proyectos y control de calidad.
b. Entrevista: mediante representaciones físicas se cumplió con la entrevista al jefe

de proyectos, así como también a los encargados durante el proceso de desarrollo
del proyecto de software.
102
2.6. Procedimiento de análisis de datos
El análisis de los datos se ejecutará en base a lo siguiente:
Descripción y clasificación de la situación actual del proceso de gestión de un

proyecto de software.
Uso de una matriz de evaluación de los procesos y objetivos planteados.
2.7. Criterios éticos
Privacidad: Se respetará la política de confidencialidad de los datos que se

estableció en la entrevista inicial con el jefe de proyectos y el Gerente general,
manteniendo la información para la organización y los miembros que les compete.
Originalidad: La presente investigación, así como el modelo de gestión planteado

son producto de la propia investigación por lo que se encuentran libre de existencia
intelectual, plagio en cualquier otra investigación.
Veracidad: Cada información que se presenta en esta investigación es verídica y

representa la realidad actual de la empresa en objeto de análisis.
2.8.Criterios de rigor científico
Confidencialidad: Se asegurará la protección de la identidad de las personas que

participan como medio para obtener la información necesaria.
Objetividad: La investigación se basará en criterios técnicos e imparciales.
Veracidad: La información que se muestra será verídica cuidando la

confidencialidad de esta.
103
2.9. Modelo de trabajo
Para el presente trabajo se realizó los siguientes pasos
A. Paso 1: Análisis del sector de desarrollo de software en Perú
En este paso se empleará el uso de estudios ya realizados del sector de software

en el Perú de los último 4 años, mostrado en los reportes:
i. Estudio del Sector peruano de desarrollo de software Competisoft

ii. Análisis PROMOX (sector peruano), desarrollo del sector de software en
Perú
iii. Estudio de análisis peruano PROM PERÚ – Crea Software Perú, cambios
de economía mundial hacia adaptabilidad y crecimiento en Software.
iv. Análisis APESOFT, realidad nacional en el Perú
A partir del análisis de estos estudios se generará un informe del análisis actual
del sector de desarrollo de software en Perú (IASP) que incluirá la descripción de
los estudios y tablas y gráficas evolutivas de las mismas, mostrando la realidad
actual del sector desarrollo en el Perú
Figura 29. Etapa 1: Análisis del sector de desarrollo de software peruano - Entregable
IASP
104
B. Paso 2: Selección de normas y guías de buenas prácticas
En esta etapa se analizará las normas y guías de buenas prácticas para la gestión
de proyectos de software y calidad dentro de las cuales tenemos.
Normas y Guías
i. ISO/IEC 25000: Guía para la evaluación de calidad de software
ii. ISO/IEC 21500: Guía de gestión de proyectos
iii. CMMI: Mejora y evaluación de procesos para el desarrollo
iv. Competisoft: Mejora de procesos para fomentar la competitividad en
PYME’s
v. Moprosoft: Modelo de procesos de la industria del software
vi. NTP/ISO 12207: procesos de ciclo de vida de software
Modelos de Gestión de proyectos y control de calidad
i. Modelo SPM en SME’s

ii. Modelo Ágil
iii. Modelo PMI/PMBOK
iv. Modelo CMMI – Niveles de madurez
v. Modelos tradicionales de desarrollo cascada
A partir de ahí se realizará una matriz de consolidación de indicadores que emplea
cada norma y guía, para determinar la forma de trabajo propuesta por cada una
de ellas, posterior a ello se seleccionará los mejores indicares para poder generar
un matriz de selección de indicadores (MSI) que permitirá incluirse dentro de la
generación del modelo a desarrollar.
Figura 30. Etapa 2: Selección de normas y guías de buenas prácticas - Entregable MSI
105
C. Paso 3: Establecer métricas para evaluación
En esta etapa se evaluará las métricas que explican cada norma y se consolidará
una priorización de estas métricas (PM) para que cualquier proyecto de software
pueda medir su calidad de entregable y gestión al emplear el modelo de gestión
y control de calidad planteado en este estudio
Figura 31. Etapa 3: Establecer métricas para evaluación -

Entregable PM
D. Paso 4: Propuesta de modelo de gestión y control de calidad

En esta etapa se planteará el modelo de gestión de proyectos de software y control
de calidad (MGC) que se está analizando en las anteriores etapas, empleado
indicadores seleccionados, las métricas de evaluación y el estado del sector actual
del desarrollo de software en el Perú
Figura 32. Etapa 4: Propuesta de modelo de gestión y control de

calidad - Entregable MGC
106
E. Paso 5: Validación de modelo
En esta etapa, se apoyará del conocimiento de expertos en el ámbito de gestión de

proyectos de software para evaluar el modelo que se está planteando como propuesta
de investigación. Para ello se entrega un informe de evaluación detallado de expertos
(IEE)
Figura 33. Paso 5: Validación de modelo - Entregable IEE
107
Paso Final 5
Paso 1
Paso 2
Paso 3
Paso 4
108
2.9.1. Análisis del sector de desarrollo de software en Perú
En esta etapa analizaremos paso a paso cada estudio realizado por del sector de
desarrollo de software en el Perú, dentro de las cuales abordaremos:
A. Artículo: Industria peruana de software, perspectivas
Este artículo ha sido generado en base a Apesoft, el Banco Interamericano de

desarrollo y la Cámara de comercio de Lima
[40] explica en base a [41] que, la industria del software tiene un expectante
potencial de crecimiento, determinaba que en el mercado
i. Da empleo directo e indirecto altamente calificado a más de 6000
peruanos
ii. Hay cerca de 300 empresas de software en el Perú
iii. Facturan más de $100 millones con una tasa de crecimiento de 10%
anual
iv. Exportaciones de software crecieron de $6 a $20 millones del 2001 al
2005
Por ello expresa [40] que, bajo ese escenario, es esencial impulsar un trabajo
integral para convertir al sector de desarrollo de software en una fuente de
ingresos para el país.
[40] explica también las razones del porque se debe promover la industria
del software son:
i. Es uno de los motores de la nueva economía

ii. No existen brechas tecnológicas
iii. Productos de calidad y creatividad
iv. Precios competitivos
v. Generador de empleo
vi. Impacto directo en la sociedad: Salud y Educación
[40] explica que la propuesta que determina [41] es una acción viable, efectiva
e integral, con 6 pilares básicos de trabajo entre los que se destacan.
i. Establecer un marco regulatorio.
109
ii. Formar y capacitar nuestro recurso humano.
iii. Impulsar el desarrollo del mercado interno.
iv. Fortalecer la base empresarial.
v. La edificación de una infraestructura tecnológica.
vi. La promoción del desarrollo del mercado externo, a través de la oferta
exportable de software.
B. Aporte Microsoft, situación actual del software en Perú
[42] explica que en base a los que expone [43], el mercado de la informática
en Perú, que incluye el hardware, software y servicios informáticos
profesionales, tuvo un incremento en su tasa de crecimiento anual compuesto
de 14,1% en los últimos diete años.
Para [43], la expectativa es que este año el crecimiento sea de 9,7% con un
movimiento de $2,289 millones de dólares.
[43] basado en el informe de [44], explica que entre el 2010 y el 2017, la

industria del software registró un incremento de 10,8% por encima del
crecimiento mundial especifico del software. Así mismo se proyecta que,
hacia fines del año 2020, la industria del software en Perú se multiplique 2.5
veces en comparación con el año 2010.
[42] indica que, de acuerdo con Robert Ivanschitz, director de asuntos legales
de Microsoft América Latina, expreso que, en el mercado peruano, la industria
comercial solo del software recaudo $396.8 millones de dólares en el 2017,
según cifras oficiales de Sunat
110
C. Análisis América Sistemas basado en IDC
[45] explica basado en el [44] que la incertidumbre política, los escándalos de

corrupción y los problemas asociados a desastres naturales contribuyeron a
que en el 2017 la inversión en la industria de TI no tuviera los crecimientos
pronosticados a inicio de ese año, generando incluso decrecimiento en
distintos rubros.
Así mismo expresa que [44] presentó cifras sobre el crecimiento que tuvo el
sector TIC del país el año pasado donde se declara que el negocio del hardware
y software ronda los $2,000 millones de dólares, mientras que si se habla de
servicios esta cifra se hacer a los $1000 millones cifras prometedoras pero que
están muy por debajo de lo esperado.
Para el 2018, explica [45] que se espera mayor actividad de servicio TI
alineada con las últimas tendencias como Cloud, Big Data/Analytics,
Mobility, IoT, Robotics, Cognitive Computing y Machine Learning. Un
analista de [44] explica que algunas empresas peruanas claramente comienzan
a anticiparse a los efectos de los cambios esperados en sus industrias,
apalancándose en la adquisición de nuevas competencias digitales, donde los
sistemas cognitivos y machine learning se tornan esenciales.
[44] adiciona que en cuanto a facturación de servicio de cloud publica, Perú
registra un crecimiento de año contra año de 44,2% en el 2017 estimado en el
último estudio “IDC Public Cloud Services”. Mientras que lo correspondiente
a los servicios de cloud privada hosteada (sumando los servicios dedicados y
los on demand), muestra un crecimiento de 15,2%. Por otro lado, lo que
corresponde a la inversión de cloud privada empresarial ha tenido también una
subida en 17,3%
D. Estudio de análisis peruano PROM PERÚ – Crea software Perú

[46], indicaba que la industria del software estaba compuesta hacia 16 años, y
que existían 300 empresas formales de dicho rubro, con un total de 30000
programadores de sistemas. Indicaba que para el año 1007, la estructura de
empresas seguía siendo la misma que en el 2006, en cuanto a ventas netas.
111
Figura 34. Ventas totales por productos o servicios, entre los años 2006 y 2007
con una base de 300 empresas
Figura 35. Ventas activas en el año 2007
[46] indica que el 46% de las ventas del año 2007 fueron por las empresas
grande y se estimaba que las empresas grandes representan el 4% del mercado,
por lo que se considera que existe una amplia brecha de ventas con respecto a
las demás empresas.
112
Tabla 31. Ventas anuales por producto - servicio
Año Producto Servicio TOTAL
2003 34.098 51.205 85.303

2004 39.677 61.681 101.358
2005 35.606 96.889 132.495
2006 61.944 78.915 140.859
2007 63.933 87.040 150.973
2008 68.637 91.961 160.598
% Var 06/07 3.1% 10.1% 7.1%
Nota: monto es expresado en miles de dólares, (Base: ventas extrapoladas a 300
empresas).
E. Estudio Apesoft, realidad nacional de Perú
[47] basado en el informe de [48] indica que la industria tecnológica en Perú

cerro el 2016 en $3,887 millones de dólares, además de no prever ningún
cambio a finales de este año, sin embargo, el sector del software crecerá
constantemente.
Así mismo declare Carlos Jacobsen, gerente general de Apesoft para el diario
[47] que el sector cerró en el año 2015 con $240 millones de dólares y se
proyecta para el 2017 un incremento del 5,3%.
Así mismo, este ejecutivo calcula que en los próximos cinco años la ratio
podría subir a 12%, siempre y cuando se implemente un Ministerio de
Tecnologías de Información y Comunicación.
Así mismo [48] informa que, de las 500 empresas peruanas de software, solo
95 pertenecen a Apesoft, pero estas representan el 80% de la facturación
nacional del mercado.
113
INFORME DE ANÁLISIS ACTUAL DEL SECTOR DE DESARROLLO DE
SOFTWARE EN PERÚ – IASP
De acuerdo con los estudios realizados por APESOFT, PROM Perú, así como las
acotaciones de empresas relacionadas al rubro de desarrollo de software, como Microsoft,
o entidades como la cámara de comercio, etc., se determina que la industria del software
ha tenido un crecimiento de los últimos años, expresado en cifras de ventas (millones de
dólares), por ejemplo para los años 2003 las ventas de productos y servicios se contabilizó
un total de $83,303 miles de dólares contra un $240 millones de dólares para el año 2015,
de acuerdo con [48], como en incremento de empresas dedicadas a este rubro por ejemplo
para los años 2003, existían únicamente 300 empresas dedicadas al rubro de desarrollo
de software, contra un total de 500 empresas para el año 2017, de acuerdo con [48].
En tal sentido vemos que la industria del Software ha sufrido cambios y crecimiento
acelerados en la última década pues creció un 66,7% respecto a su primer registro en el
año 2003 versus el 2016.
114
2.9.2. Selección de normas y guías de buenas prácticas
En esta etapa vamos a analizar las principales características y métricas de evaluación de las principales normas y estándares de calidad en
el desarrollo de software, así como de los modelos de gestión.
Tabla 32. Selección de normas y guías de buenas prácticas para el desarrollo del modelo MGCQ
115
2.9.3. Establecer métricas de evaluación
Tabla 33. Características de calidad de los modelos y estándares de calidad
ISO/IEC 25010
ISO/IEC 9126
Modelos o Estándar de calidad
WebQEM
Dromey
FURPS
McCall
Boehm
C-QM
SQAE
SATC
Características de calidad
Funcionalidad o Adecuación
1 x x x x x x x
funcional
2 Usabilidad o Facilidad de uso x x x x x x x
3 Integridad o Seguridad x x
4 Corrección, precisión o Exactitud x
5 Confiabilidad o fiabilidad x x x x x x x
6 Eficiencia o Rendimiento x x x x x x x x
7 Facilidad de mantenimiento x x x x x x x
8 Facilidad de prueba x x x
Flexibilidad, mutabilidad, facilidad
9 de modificación, facilidad de x x
cambio
10 Facilidad de reutilización x x x x
11 Interoperabilidad x
Portabilidad o facilidad de
12 x x x x x
transportación x
13 Ingeniería humana x
Comprensibilidad, facilidad de
14 entendimiento, descripción o x
pertinencia del reconocimiento
15 Soporte o facilidad de soporte x
16 Compatibilidad x
17 Conformidad x
18 Capacidad de evolución x
Total 7 7 11 5 5 4 4 6 8 4
Nota: Características de calidad de Software en base a cada norma y estándar de calidad de software como
producto. Recuperado de “Análisis comparativo de modelos y estándares para evaluar la calidad del
producto de software”, de [54].
116
Tabla 34. Sub-características de calidad cubiertas por los modelos y estándares a nivel del producto
ISO/IEC 25010
ISO/IEC 9126
Modelos o Estándar de calidad
WebQEM
Dromey
FURPS
McCall
Boehm
C-QM
SQAE
SATC
Sub-características de calidad
1 Idoneidad o Pertinencia funcional 6,7 1 1 1
2 Precisión, Exactitud o Corrección 5 1,5 3 5 8 1 1
3 Interoperabilidad 1 16
4 Seguridad o Integridad 1 1 1 1 3
5 Facilidad de recuperación 5 1 5 5
6 Consistencia 5,14 1,2,5,7,10,12 4,7 2 7
7 Adaptabilidad 15 1 12 12
8 Generalidad o Comunalidad 7,10,12 9,10 1
9 Completitud funcional 5,12 1,2,5,7 1 1 1
Comprensibilidad, Facilidad de
10 entendimiento, descripción o 1 10 1,2 2 2
pertinencia del reconocimiento
7,10,12,
11 Documentación interna 2,7,10,12 2 2,7 1
18
7,10,12,
12 Documentación externa 2,7,10,12 2 2,7 2
18
13 Cohesión 7,10,12 2
14 Facilidad de Operación 7 2 2 2
15 Soporte o Facilidad de Soporte 2
117
Atracción o Estética de la interfaz de
16 2 2 2 2
usuario
17 Familiarización 2 2
18 Comunicatividad 8,13 2 2
19 Volumen y tasa de entrada/salida 2
20 Accesibilidad 6,8,13 6,7 6 2
21 Protección contra errores del usuario 2
22 facilidad de aprendizaje 2 2
Estabilidad o Estabilidad de las
23 1 2 7 7
modificaciones
24 Control y auditoria de acceso 3
25 Integridad de los datos 3
26 No repudio 3
27 Responsabilidad 3
28 Autenticidad 1,5,7 3
29 Compleción 1,5 4
30 Trazabilidad 4 1
31 Madurez 5 5 5 5 5
32 Tolerancia ante fallos 5 5 5 5 7,18
33 Encapsulamiento 5,7,10,12
Especificación o construido según
34 1,2,5,7,10,12 1 10
las especificaciones
35 Poco acoplamiento 5,7,10,12
36 simplicidad 6,7 5,7,8 7,18
37 Disponibilidad 6 1 5
118
Rendimiento o Comportamiento
38 6 6 6 6 6 6
temporal
39 Utilización de recursos 6 6 6 6 6
Flexibilidad, mutabilidad, facilidad
40 de modificación, facilidad de cambio 1,5,7 7 7 7
o facilidad de cambio
41 Abstracción 7,10 7
42 Ajustable 7,10,12
43 Parametrización 7,10,12
44 Modularidad 6,7 7,8,9 7,10 7 7,12,18
Reusabilidad o facilidad de
45 7 7
reutilización
Facilidad de diagnóstico o facilidad
46 5 1 7 7
de análisis
7,8,9,10, 7,10,12,
47 Auto descripción 8,14
12 18
48 Instrumentación 2,6,7 8 15
49 Facilidad de prueba 15 7 7
50 Estructura 8,9,14 1,5,7 7
Capacidad de ampliación o
51 9 7 9 15
capacidad de evolución
52 Independencia de la máquina 12 10,12 12
53 confidencialidad 3
Independencia del software de
54 7,10 10,12 12
sistema
55 Datos comunes o estandarización 2,11
119
Comunicaciones comunes o
56 Estandarización de las 1,5 11
comunicaciones
57 Facilidad de reemplazo 12 12
58 Coexistencia 12 16
59 Concisión 14 5,7
60 Legibilidad 14 1
61 Facilidad de instalación 15 12 12
62 Facilidad de configuración 15
63 Compatibilidad 15
64 Conformidad respecto al modelo 17
Conformidad respecto al modelo de
65 17
referencia
Total 12 26 24 24 12 10 15 21 31 9
Nota: Recuperado de “Análisis comparativo de modelos y estándares para evaluar la calidad del producto de software”, de [54].
120
En base a ello seleccionaremos las principales características (Indicadores de
calidad para el producto de software) del consolidado inicial Características de
calidad de los modelos y estándares de calidad. Tabla 33
Tabla 35. Características y sub-características de calidad
CARACTERÍSTICA SUB-CATEGORÍA
1. Pertinencia Funcional
2. Precisión
Funcionalidad 3. Interoperabilidad
4. Seguridad
1. Facilidad de Entendimiento
2. Facilidad de Operación
3. Protección contra errores de usuario
Usabilidad
4. Facilidad de aprendizaje
5. estabilidad
1. Control de Acceso
2. Integridad de los datos
Seguridad 3. Autenticidad
4. Confidencialidad
1. Uso de recursos
Eficacia 2. Rendimiento
3. Disponibilidad
1. Documentación Interna/Externa
2. estabilidad de las modificaciones
Mantenimiento 3. Tolerancia a fallos
4. Flexibilidad
1. Adaptabilidad
2. Facilidad de Instalación
Portabilidad 3. Coexistencia
4. Modularidad
121
Detalle de
Met. Dim. Evaluador Detalle de Evaluador Fórmula Mejor esperado Campos
indicador
Mide el número de
A: Número de funciones
funciones con capacidad
donde se han detectado
Suficiencia de llevar a cabo las tareas 𝒙 = 𝟏 − 𝐀/𝐁 más cercano a 1 problemas en la evaluación.
funcional especificadas comparadas
B: Número de funciones
con el número de
evaluadas.
funciones evaluadas.
Mide la relación entre el A: Número de funciones
número de funciones perdidas detectadas en la
Integridad de la perdidas detectadas y evaluación.
Adecuación
implementación comparar con el número 𝒙 = 𝟏 − 𝐀/𝐁 más cercano a 1 B: Número de funciones

Funcionalidad
funcional de funciones descritas en descritas en la

la especificación de especificación de
requisitos. requisitos.
Mide la relación entre el A: Número de funciones
número de funciones perdidas o incorrectamente
perdidas o implementadas implementadas detectadas
Alcance de la 𝒙 = 𝟏 − 𝐀/𝐁
incorrectamente y en la evaluación.
implementación más cercano a 1
comparar con el número B: Número de funciones
funcional
de funciones descritas en descritas en la
la especificación de especificación de
requisitos. requisitos.
Exactitud
Mide el número de A: Número de cálculos

Exactitud cálculos imprecisos 𝒙 = 𝑨/𝑻 inexactos encontrados por
más cercano a 0
computacional basados en las los usuarios
especificaciones. T: Tiempo de operación.
122
A: Número de resultados
encontrados por los
Mide el número de
𝒙 = 𝑨/𝑻 usuarios con un nivel de
Precisión resultados con precisión más cercano a 0
precisión diferente al
inadecuada.
requerido.
T: Tiempo de operación.
Mide el número de fallos
A1: Números de fallos
que no se repiten durante
Resolución de 𝒙 = 𝑨𝟏 − 𝑨𝟐 resueltos.
el periodo definido de más cercano a 1
fallos A2: Número total de fallos
ensayo bajo condiciones
detectados.
similares.
Fiabilidad
Madurez
T1: Tiempo de operación.

Mide el número de fallos 𝒙 = 𝑻𝟏 /𝑨 A: Número total de fallos
ocurridos durante un detectados.
Tiempo medio periodo definido de El valor más grande T2: Suma de los intervalos
entre fallos operación y contar el mejor de tiempo entre fallos
intervalo promedio entre 𝒚 = 𝑻𝟐 /𝑨 consecutivos.
fallos. A: Número total de fallos
detectados.
Mide el número de A: Número de funciones
Apropiabilidad
funciones accesibles desde accesibles desde la interfaz

Usabilidad
la interfaz del usuario del usuario descritas

Comprensibilidad 𝒙 = 𝐀/𝐁
entendidas fácilmente y más cercano a 1 correctamente por el
de la función
compararlas con el usuario.
número total de funciones B: Número de funciones
disponibles para el usuario accesibles desde la interfaz.
123
A: Número de elementos
Mide el número de
de datos de entradas y
elementos de datos de
salida que el usuario
Entradas y entradas y salida
𝒙 = 𝐀/𝐁 entiende correctamente.
salidas comprendidos por el más cercano a 1
B: Número de elementos
comprensibles usuario y compararlos con
de datos de entrada y salida
el número total de datos
disponibles desde la
disponibles por el usuario.
interfaz.
Mide el comportamiento T: Suma del tiempo de
Facilidad de
Facilidad de Aprendizaje
del usuario desde que se operaciones hasta que el

aprender a
empieza a aprender hasta T más cercano a 0 usuario consigue realizar la
realizar una tarea
que comienza a operar con tarea específica en poco
en uso
eficiencia. tiempo.
Mide el número de A: Número de funciones
funciones utilizadas que pueden emplearse
Eficiencia de la
correctamente tras utilizar correctamente tras uso de
ayuda del sistema 𝒙 = 𝐀/𝐁 más cercano a 1
el sistema de ayuda y ayudas.
en uso
compararlo con el número B: Número total de
total de funciones. funciones disponibles.
A: Número de veces que el
Operabilidad
usuario falla al establecer

Mide contar cuantas veces
Disponibilidad valores de parámetros en
que el usuario selecciona
del valor 𝒙 = 𝟏 − 𝐀/𝐁 más cercano a 1 un periodo corto.
o establece valores de
prefijado en uso B: Número de veces que el
parámetros y fallas.
usuario intenta establecer
valores de parámetros.
124
A: Número de fracasos en
la recuperación del error en
Facilidad de
Mide el comportamiento las que el usuario no haya
recuperación de 𝒙 = 𝟏 − 𝐀/𝐁
del usuario que opera el más cercano a 1 sido informado del riesgo
error operacional
software. por el sistema.
en uso
B: Número de errores del
usuario o cambios.
Prueba de usuario y A: Número de funciones
observación del personalizadas
Uso de la 𝒙 = 𝐀/𝐁
comportamiento del más cercano a 1 satisfactoriamente.
personalización
usuario que opera el B: Número de intentos de
software personalización.
Mide el tiempo que tarda TR: Tiempo en obtener el
Tiempo de en la muestra para 𝒙 = 𝑻𝑹 − 𝑻𝑪 resultado.
Comportamiento en el tiempo
más cercano a 0
respuesta completar su operación y TC: Tiempo en introducir
registro de cada intento el comando.
Establecer cada tarea de

Eficiencia
acuerdo con las premisas

iniciales.
A: Número de tareas
Iniciar diferentes tareas de 𝒙 = 𝑨/𝑻
Rendimiento de completadas.
trabajo. mejor cuanto mayor
procesamiento T: Periodo de tiempo de
Medir el tiempo que tarda
observación.
en la tarea medida para
completar la operación.
Registro de cada intento
125
Ejecutar un número de
escenarios de tareas
concurrentes.
Medir el tiempo que tarda 𝒙 = 𝑻𝒂 − 𝑻𝒃 Ta: Tiempo total de espera.
Tiempo de espera en completar la operación más cercano a 0
Tb: Tiempo de tarea.
seleccionada.
Registro de cada intento y
contar el tiempo medio
para cada escenario.
Miden atributos Mide la relación entre la

1-10: Poco riesgo
relacionados con complejidad ciclomática E: Representa el número de
11-20: Moderado
el esfuerzo del de un producto y su caminos en el flujo de la
Complejidad 𝒙=𝑬 −𝑵+𝟐 riesgo
Mantenibilidad
Analizabilidad
mantenimiento o ciclomática tamaño. Se basa en el lógica o Aristas

21-50: Alto riesgo
el usuario o los cálculo del número de N: Representa las acciones
>=50: Muy alto
recursos gastados caminos independientes a seguir o Nodos
riesgo
para diagnosticar que tiene nuestro código.
deficiencias a Mide la relación entre la LCD: Líneas de código
causa de fallos, o cantidad de código 𝑳𝑪𝑫 duplicadas
Código repetido 𝒙= ∗ 𝟏𝟎𝟎 menor cantidad
para identificar repetido de un producto y 𝑳𝑪𝑻 LCT: Líneas totales de
las partes que su tamaño. código - Líneas comentadas
126
deben ser Mide la relación entre la
modificadas. cantidad de comentarios
de un producto y su
LC: Líneas de código
tamaño (incluye 𝑳𝑪
Densidad 𝒙= ∗ 𝟏𝟎𝟎 comentadas
comentarios). Su objetivo mayor cantidad
comentarios 𝑳𝑻 LT: Líneas de código
es evaluar los comentarios
totales
en el código para conocer
su capacidad para ser
analizado y modificado
Mide la relación entre el Ausencia de comentarios
número de defectos de (10)
Densidad de 01-25: Muy buena Elevada complejidad
analizabilidad y el tamaño
defectos de la 26-50: Buena ciclomática (40)
del proyecto. Se calcula la menor cantidad
capacidad para 51-75: Mala
densidad de violaciones al Incoherencias en el código
ser analizado 76-100: Muy Mala
realizar un análisis (30)
estático del código fuente Código repetido (20)
Miden atributos
Mide la relación entre el
relacionados con
número de dependencias
el esfuerzo del
Modificabilidad
cíclicas que representa el

mantenedor o el
producto y la cantidad de CEM = Ciclos entre
usuario para ∑ 𝑪𝑬𝑴
Densidad de módulos existentes. 𝒙= ∗ 𝟏𝟎𝟎 módulos
medir la 𝑴𝒐𝒅𝒖𝒍𝒐𝒔 menor cantidad
ciclos Su finalidad es evaluar la Módulos = Módulos
conducta del
existencia para conocer las existentes
mantenedor, el
dependencias que pueden
usuario o el
traer problemas entre
sistema software
dichos módulos
cuando se intenta
127
llevar a cabo una 95%-100% : Muy
modificación buena
Representa la capacidad 𝑴𝒕𝒐𝒕 − 𝑴𝒏𝒐𝒅𝒐𝒄 Mtot = Módulos totales
determinada 70%-95% : Buena
Documentación de documentación en el 𝒙= ∗ 𝟏𝟎𝟎 Mnodoc = Módulos no
𝑴𝒕𝒐𝒕 40%-70% : Mala
proyecto documentales
0%-40% : Muy
Mala
Representa la capacidad NVcs = Número de
de nombrar variables 𝑵𝑽𝒄𝒔 variables con nombre con
Nombres de 𝒙= ∗ 𝟏𝟎𝟎
acordes a la función o 𝑵𝑽𝒕𝒐𝒕 mayor cantidad sentido
variables
contexto en el que se Nvtot = Número de
emplea variables totales
Capacidad de ser Acoplamiento entre clases
cambiado un producto se (30)
mide como la relación 01-25: Muy buena Incoherencias en el código
Densidad de
entre el número de 26-50: Buena (30)
defectos de menor cantidad
defectos de 51-75: Mala Código repetido (25)
modificabilidad
modificabilidad que 76-100: Muy Mala
representa el producto y Ausencia de comentarios
su tamaño. (15)
Miden atributos
relacionados con
la conducta
inesperada del A = Número de fallos
Estabilidad
sistema software Densidad de debidos a efectos laterales

cuando dicho fallos por 𝒙 = 𝟏 − 𝑨/𝑩 menor cantidad detectados y corregidos.
software es modificación B = Número total de fallos
probado u corregidos.
operado después
de una
modificación
128
Mide la relación entre el
número de pruebas
unitarias y la complejidad
UN: Número de pruebas
ciclomática, es decir, el
Densidad de unitarias
número de pruebas ∑ 𝑼𝑵 mayor cantidad
pruebas unitarias 𝒙= CC: Complejidad
unitarias codificadas en ∑ 𝑪𝑪 ciclomática
Miden atributos relación con el número de
relacionados con pruebas unitarias
el esfuerzo del deseables
Facilidad de prueba
mantenedor o el Descriptores de acceso:

usuario para número de funciones get y
medir la set empleados
conducta del
Clases: número de clases
mantenedor, el
Mide el tamaño de cada Directorios: número de
usuario o el
parte de nuestro programa, directorios
sistema software
como pueden ser el
cuando se intenta Tamaño del Archivos: número de
número total de líneas, Sin detalle Sin detalle
probar el programa archivos
número de clases, número
software Líneas: número de líneas
de directorios, número de
físicas que contienen al
archivos.
menos un espacio en
blanco o una tabulación o
parte de un comentario
Métodos: número de
funciones
129
2.9.4. Modelo de Gestión para aseguramiento de Calidad
El modelo que plantea la siguiente investigación sobre la gestión para el

aseguramiento de la calidad en proyectos de software en la realidad peruana se basó
en el modelo Deming, ciclo PDCA (Plan, Do, Check, Act).
Figura 36. Ciclo PDCA
2.9.4.1.Planificación
La planificación define un grupo de procesos que van a establecer el alcance total

de los esfuerzos, definir y refinar los objetivos y, finalmente desarrollar una línea
de acción requerida para alcanzar dichos objetivos constituidos en un plan de
trabajo del proyecto.
Durante el proceso de desarrollo del proyecto es posible que los objetivos

planteados sean modificados, refinados, corregidos, aumentados o eliminados por
lo que se debe ir refinando durante todo el proceso en un ciclo continuo y recursivo
a esta etapa la denominaremos desarrollo evolutivo de objetivos.
130
Figura 37. Etapa de planificación
131
Figura 38. Etapa de Planificación, Subproceso Generación de plan de trabajo
132
A. Documentos organizacionales previos (DOP)
Dentro de los documentos organizaciones previos a la reunión inicial y que

tomaran su punto inicial y de uso en el proceso de generación de un plan de
trabajo se contemplan los siguientes:
1. Políticas empresariales (DPE)

Este documento es de tipo interno a la organización y constituye una
directriz restrictiva para genera un marco reglamentario que se debe
conocer y cumplir estrictamente, con el fin de garantizar el orden,
formalidad, credibilidad y control en la organización y en la gestión de
los procesos que conlleven a la mejora de la entidad. Puede guiarse en
base al modelo que se muestra en ANEXO 2: Documento de Políticas
empresariales (DPE)
2. Objetivos empresariales (DOE)

Este documento es de tipo interno a la organización y establece las
situaciones deseadas que toda empresa desea alcanzar en sus distintas
áreas que la conforman o que resultan de su interés, y que reflejan el
deseo contenido en su misión y visión a través de metas alcanzables.
Puede guiarse en base al modelo que se muestra en ANEXO 3:
Documento de Objetivos Empresariales (DOE)
3. Aspectos Legales (DAL)

Este documento es de tipo interno a la organización y determina las
variables legales críticas de éxito, considerando inicialmente las
exigencias del entorno, las oportunidades y amenazas (normas, leyes,
reglamentos, obligaciones y derechos) y, posteriormente considerandos
los recursos y fortalezas a obtener, si se trata de un nuevo proyecto y las
debilidades a superar, si es un proyecto ya existente, respondiendo a las
exigencias legales del entorno; y estimar los costos de inversión y de
operación para dar cumplimiento a las exigencias legales, permisos y
certificaciones.
133
Para registrar los aspectos legales del proyecto se puede guiar del
ANEXO 4: Documento de aspectos legales (DAL)
4. Costos y tiempo (DPP)

Este documento es de tipo externo a la organización y compone los
aspectos económicos y el tiempo que conllevará el término del proyecto.
Este documento se descompone en cada aspecto de análisis, así tenemos.
4.1.Costos
Establecer la aproximación de los recursos monetarios necesarios

para completar las actividades totales del proyecto. La exactitud de
la estimación del costo de un proyecto aumenta según el proyecto
avanza, dicho de otro modo, es un proceso iterativo. Puede visualizar
el modelo en el ANEXO 5: Documento de presupuesto para el
proyecto (DPP).
4.2.Tiempo (DTTP)
Establece los procesos requeridos para administrar el término del

proyecto a tiempo. Estos procesos deben interactuar entre sí y con
procesos de otras áreas de conocimiento. Tras llegar a obtener las
actividades, se procederá con la priorización y por último el
calendario de trabajo para el proyecto. Puede visualizar el modelo
en el ANEXO 6: Documento de tiempo total para el proyecto
(DTTP).
5. Requisitos (REQ)
Este documento sirve como medio de comunicación entre clientes y
usuarios, en este proceso deben de recogerse tanto las necesidades de
clientes y usuarios, así como también los requisitos que deben cumplir
el producto y/o servicio resultante del proyecto para satisfacer dichas
necesidades.
134
Para llevar a cabo la toma de requisitos del sistema puede emplearse el
modelo que se visualiza en el ANEXO 7: Documento de requerimiento
del proyecto (DRPY)
Este debe ser un documento consensuado entre todas las partes y tener
un carácter contractual, de forma que cualquier cambio que se desee
realizar en él una vez acordada la primera línea base, debe aplicarse
siguiendo el procedimiento y formato de control de cambios que se
establece para el proyecto.
El consolidado de los requisitos se puede completar usando el modelo
mostrado en el ANEXO 8: Documento de listado requerimientos del
proyecto (DLRPY).
6. Plan de Mejora continua (DPMC)

Este documento contempla un conjunto de acciones orientadas a
optimizar los resultados de un proceso interno, cuyo único propósito es
la mejora.
Existen varias herramientas de mejora continua, sin embargo, se debe
contemplar que la intervención no significa que los procesos acaben, por
el contrario, es el punto de partida para retomar al primer paso del plan
de mejora, sacando provecho de la experiencia y saber aplicarla en
posteriores casos. Puede emplear el modelo de plan de mejora continua
mostrado en el modelo visto en el ANEXO 9: Documento de plan de
mejora continua (DPMC).
B. Reunión inicial del proyecto (DRI)
El propósito de la reunión inicial del proyecto es comunicar los objetivos

del proyecto, las políticas organizacionales, establecer los aspectos legales
que convergen en el proyecto, los costos, el tiempo, así como el alcance
general del proyecto y obtener el compromiso del equipo, además de
explicar los roles y las responsabilidades de los interesados que van a
intervenir en el inicio, durante el desarrollo y en el aprendizaje del plan de
mejora.
135
El hecho de realizar esta reunión inicial de lanzamiento del proyecto no
excluye que posteriormente se formalice la aceptación del plan de proyecto
en reuniones posteriores, sino que van estrechamente ligados entre sí para
concluir en un sólido plan de proyecto que determine las directrices del
actuar del proyecto.
En esta reunión debe de estar incluido por lo menos, la alta dirección de la
empresa con sus representantes y el jefe de proyecto.
Para un modelo de la reunión inicial del proyecto puede usarse el modelo
visto en el ANEXO 1: Documento de reunión inicial del proyecto (DRI).
Salida
Entradas
Establecer el marco
Reunión inicial del
para generar el plan de
proyecto
trabajo
Figura 39. Reunión inicial del proyecto.
C. Generar plan de trabajo

Corresponde a un esquema en el que se describe un conjunto de metas y
procesos con los cuales un equipo o una persona pueden logran sus
objetivos. Asimismo, le brinda al lector una mejor comprensión del alcance
del proyecto.
Este subproceso incluye cuatro hitos dentro de los que incluye.
1. Obtener documentos de la organización
Para poder llevar a cabo exitosamente un plan de proyecto debe de

contarse con los documentos organizacionales previos (DOP) que se
establecen de acuerdo con el modelo MGCQ en su etapa de planificación
136
2. Establecer perfiles de equipo de trabajo
Dentro de este hito se deberán establecer los perfiles del empleado que
trabajará en el desarrollo del proyecto, deben especificarse, el perfil del
cargo, las funciones a desempeñar, la jerarquía de puestos.
Para completar este hito se puede guiar del DPET (Documento de
perfiles de equipo de trabajo), que se encuentra en el ANEXO 10:
Documento de perfiles de equipo de trabajo (DPET).
3. Selección de personal del equipo de trabajo
Posterior a determinar los perfiles de equipo de trabajo, se procederá a

seleccionar a los profesionales cuyo perfil concuerdan con lo
determinado en el Documento de perfiles de equipo de trabajo (DPET)
4. Generar documento de plan de trabajo
Para poder llevar a cabo exitosamente un plan de proyecto debe de

contarse con los documentos organizacionales previos (DOP) que se
establecen de acuerdo con el modelo MGC en su etapa de planificación
Entradas
1. Políticas empresariales
2.Objetivos de la
organización Salida
3.Aspectos legales
4.Costos y tiempos Plan de trabajo
5.Requisitos
6.Plan de mejora
continua
Figura 40. Generar plan de trabajo. Flujo de proceso de para generar un plan de trabajo.
137
Para asegurar un correcto plan de trabajo se debe incluir todos los
documentos necesarios, los documentos que se mencionan en este modelo,
así como los que se emplean en la metodología de gestión de proyectos que
se ha elegido y se debe concluir con un documento claro y preciso. En él se
detalla el formato de plan de trabajo que se incluirá en su gestión de
proyectos general.
Para generar el documento del plan de trabajo, puede guiarse en el ANEXO

11: Documento de plan de trabajo (DPT).
D. Estándares de calidad
El proceso de establecer estándares proporciona un marco para definir, en

un escenario particular, la calidad; dicho proceso ofrece un conjunto de las
mejores prácticas evitando repetir errores anteriores y capturando el
conocimiento de valor para la organización ofreciendo un marco de trabajo
alrededor del que se implementa el proceso de asegurar y establecer los
estándares de calidad ayudando a la continuidad del trabajo de los
involucrados en el proyecto.
Para llevar a cabo la tarea de Estándares de calidad se debe seguir las

siguientes tareas.
Figura 41. Etapa de Planificación, Subproceso Estándares de calidad
138
1. Establecer estándares del producto
En esta etapa deberá de obtener los documentos necesarios para poder
evaluar métricamente el producto/servicio de software. Dentro de ellas
se requieren los siguientes documentos necesarios.
Documento de formato y estilo de programación (DFP)
Corresponde a los estilos de programación que empleará el equipo de

desarrollo y que debe constar como limitaciones y guía para el desarrollo
del producto final. Puede guiarse del ANEXO 12: Documento de
formato y estilo de programación (DFP)
Documento de formato y estilo de base de datos (DEBD)
Corresponde a todos los datos que comprenden el formato y estilo que se

llevará a cabo para el proyecto respecto a la base de datos, el gestor de
base de datos que se empleará, las limitaciones y usos.
Puede guiarse del ANEXO 13: Documento de formato y estilo de base

de datos
Documento de caso de revisión interna (DCRI)
En este documento se especifican los casos de revisión que empleará el

comité de control de calidad para evaluar el entregable de cada
actividad/tarea que entregue el equipo de desarrollo.
Puede guiarse del ANEXO 14: Documento de caso de revisión interna

(DCRI)
Documento de casos de revisión del usuario (DCRU)
En este documente debe constar los casos de revisión por lo que se

someterá cada actividad por el usuario final.
Puede guiarse del ANEXO 15: Documento de casos de revisión del

usuario (DCRU).
Documento de formato de medición del proyecto (DFMP)
139
En este documento debe constar la evaluación de la actividad
desarrollada y medida por el usuario final, por parte del comité de control
de calidad.
Puede guiarse del ANEXO 16: Documento de formato de medición del

proyecto (DFMP)
2. Generar documento de estándares del producto

En este hito, el líder del proyecto deberá de concretar de acuerdo con los
estándares de medición del producto anteriormente nombrados, un
cuadro de medición del producto en base a las necesidades del cliente.
Para cumplir con el Documento de estándares del producto (DECPR)

puede guiarse del ANEXO 17: Documento de estándares del producto
(DECPR)
3. Establecer estándares por Proyecto

Este tipo de estándares se centran en aplicar sus métricas y conceptos al
proceso para el desarrollo del proyecto aprobado.
En el estándar del proyecto se debe incluir los siguientes conceptos:
Documento de formato de entrega de versiones (DFEV)
En este documento debe constar el propósito de entrega de la versión (sus

mejoras, correcciones y cambios), el número de versión de entregable, el
responsable de la entrega del producto, y el evaluador de calidad del
entregable, así como sus observaciones sobre el mismo.
Puede guiarse del ANEXO 18: Documento de formato de entrega de

versiones (DFEV).
Documento de formato de control de cambios y correcciones

(DFCCK)
En este documento debe constar el propósito de los cambios y

correcciones (motivo, en qué medida es necesario el cambio o corrección,
140
importancia del cambio/corrección, etc.), la versión del proyecto que se
evaluó, y las implicaciones que tomará este cambio/corrección, en el
desarrollo del proyecto y el tiempo que implicará dicho proceso.
Puede guiarse del ANEXO 19: Documento de formato de control de

cambios y correcciones (DFCCK)
4. Generar documento de estándares del proyecto

En este hito, el líder del proyecto deberá de concretar, de acuerdo con los
documentos obtenidos y trabajados en el anterior punto, un documento
de estándares del proyecto (DECPY).
Para cumplir con el documento de estándares del proyecto (DECPY)

puede guiarse del ANEXO 20: Documento de estándares del proyecto
(DECPY)
E. Selección de comité de control de calidad
En esta etapa se selecciona el comité de control de calidad que estará a cargo

de la función de seguimiento y del cumplimiento de lo que se concrete en el
plan del proyecto aprobado.
Para establecer el control de calidad y su equipo deberá de seguirse los

siguientes pasos.
141
Figura 42. Etapa de Planificación, Subproceso Selección de comité de control de calidad
1. Establecer perfiles para personal
El principal objetivo de este documento es establecer los lineamientos

que la organización debe seguir para la elaboración, aprobación,
implementación y actualización del Manual de perfiles de puestos
adoptando el esquema propuesto y una metodología para su
formulación.
La importancia de obtener perfiles para el reclutamiento de personal

radica en que existe un parámetro al cual acudir para corroborar lo que
se espera de alguien y, para darle un mejor cumplimiento a las funciones
que se va a desempeñar en el puesto de trabajo.
2. Seleccionar personal de acuerdo con el perfil

Tras las recepciones de los perfiles profesionales que optar por recibir
el cargo para el comité de control de calidad, se deberá seleccionar a los
mejores candidatos en base a la proximidad del perfil profesional que
ha implementado la organización para su contratación.
Entradas
Salida
1.Manual de perfil de
puesto. Selección de personal
2.Perfiles profesionales de comité de control de
enviado. calidad.
Figura 43. Flujo de proceso 142

de selección de personal de comité de control de calidad.
3. Gestionar jerarquía de personal
La organización debe generar una estructura jerárquica bien establecida
para determinar las vías de comunicación más adecuada para su comité
de control de calidad. La estructura del comité debe ser establecida en
dos escalones de jerarquía comprendidas entre jefatura del comité de
control de calidad y personal de seguimiento de la calidad.
Jefatura de comité
de control de calidad
Personal de
seguimiento de la
calidad
Figura 44. Organigrama de comité de control de calidad
4. Determinar funciones de acuerdo con el rol
Concluido con el proceso de selección del personal y del orden

jerárquico del comité de control de calidad se procederá a brindar las
funciones que debe desempeñar que se encuentran en el manual del
perfil del puesto.
F. Generar plan de proyecto
Un plan de proyecto determina un conjunto de acciones estimadas para

alcanzar un objetivo determinado, para ello se debe de desarrollar en base a
los documentos organizacionales previos como las políticas, los objetivos,
143
además de los documentos ya trabajados hasta el momento como el plan de
trabajo, los estándares de calidad del producto y del proceso y la
conformación del equipo de control de calidad.
Entradas
1.Manual de plan de trabajo.

2.Documentos de estándares de
calidad del producto. Salida
3.Documentos de estándares de
calidad del proyecto. Plan de proyecto
4. Conformación del comité de
control de calidad
5. Documentos Organizacionales.
6. Documento de plan de Trabajo
Figura 45. Flujo de proceso de plan de proyecto.
Para la generación del plan de proyecto se puede guiar del modelo previsto
en el ANEXO 21: Documento de plan de proyecto (DPY)
G. Evaluar propuesta de trabajo
En esta etapa se evalúa todos los conceptos que se han incluido en el plan
de trabajo desarrollados hasta el momento para que la Dirección de la
organización evalúe si los conceptos concuerdan con lo esperado para el
proyecto y para sus lineamientos como organización o debe realizarse algún
ajuste necesario.
En caso se aprueba el proyecto continuará en una reunión final del proyecto

para comunicar el plan de proyecto aprobado por la Dirección y empezar
con la nueva etapa.
De no existir una conformidad con el plan de proyecto enviado por el jefe

de proyecto, se le remitirá a proceder con los cambios y volver a generar el
plan de trabajo bajo las observaciones emitidas.
H. Reunión final del proyecto
144
La reunión final del proyecto es el último paso que se lleva a cabo en la
planificación del proyecto y en él se reúnen el director de la organización y
el jefe de proyecto para dar la conformidad del plan de proyecto, así como
su inicio formal del desarrollo, presentar al comité de control de calidad al
jefe de proyecto y establecer las funciones que se llevarán durante el plazo
del desarrollo del proyecto.
2.9.4.2.Hacer
Consiste en la implementación de los cambios o acciones necesarias para lograr

las mejoras planteadas.
Esta es por lo general la etapa más demandante, requiere de toda la energía del
equipo. Es fundamental estar muy bien organizados, que cada uno sepa que tarea
debe realizar, cómo hacerla y cuándo.
145
Figura 46. Etapa de Hacer
146
A. Otorgar el calendario y requerimientos
El proceso inicia con la entrega del plan del calendario y requerimientos

que se encuentran en el plan del proyecto aprobado, al personal de
desarrollo. Este documento describe las estrategias que han ideado los
directivos para cumplir con los objetivos y que suponen las directrices para
el trabajo a desarrollar.
Este documento incluye el plan de proyecto aprobado y se debe entregar

las tareas a ejecutar para empezar a desarrollar el proyecto.
Entradas Salida
Calendario de
Plan de proyecto aprobado
actividades y tareas y
requerimientos
Figura 47. Flujo de proceso para brindar el calendario de actividades y tareas y

requerimientos
B. Obtener y actualizar calendario de actividades
En esta etapa se obtiene el calendario de las actividades priorizadas al

equipo del proyecto, que se encargará de obtener cada actividad y sus
respectivas tareas para su ejecución.
De existir alguna actividad a corregir, ejecutar o modificar se procederá a

seguir con el siguiente hito, de lo contrario se deberá saltar al proceso de
Generación de entregables y reporte final del proyecto.
147
C. Seleccionar actividad a trabajar
Posterior a verificar que existen actividades a desarrollar se deberá

seleccionar la próxima tarea a trabajar de acuerdo con la priorización que
ha otorgado el líder del proyecto, de no contar con la priorización de
algunas actividades se deberá solicitar al líder del proyecto sea facilitado.
D. Obtener y actualizar tareas de la actividad
Seleccionada la actividad se deberán obtener el conjunto de tareas que

comprende dicha actividad. Así mismo deberá de ser actualizada tras la
verificación del comité de control de calidad, al ser aprobada o rechazada
(por cambios, correcciones, limitaciones, excepciones a los objetivos o
políticas de la empresa, etc.).
Esta actualización se realiza en base al Documento de hallazgos de

verificación (DHVE), que será escrita por el comité de control de calidad.
Si después de obtener y actualizar las tareas de la actividad se concluye

que se han completado todas las descritas, se procederá a la etapa de
Validación de la actividad, de lo contrario deberá continuar con el
Desarrollo de tarea.
E. Desarrollo de tarea
Figura 48. Etapa de Hacer, Subproceso Desarrollo de tarea
148
1. Ejecutar tarea
Comprende la ejecución de cada tarea designada en el calendario de
procesos a desarrollar teniendo en cuenta la hoja detallada de cada
requerimiento que aún falta por completar o modificar.
2. Ejecutar pruebas de verificación

Comprende el proceso de pruebas internas para concluir en el correcto
funcionamiento de la tarea, las limitaciones que se plantean en el plan
de proyecto aprobado, y cuyo desarrollo debe salvaguardar los
lineamientos empresariales y las políticas a las que están sujetas.
La ejecución de pruebas debe iniciar con la creación de los datos de
prueba necesarios para ejecutar los casos de prueba diseñados. La
ejecución de estos casos puede realizarse de manera manual o
automatizada; en cualquiera de los casos, cuando se detecte un fallo en
el sistema se deberá notificar y proceder con la corrección de la tarea y
posterior a ellos una nueva prueba para asegurar el correcto
funcionamiento de este. El comité de control de calidad deberá guiarse
del Documento de casos de revisión interna (DCRI).
Al concluir esta etapa se debe entregar el documento de la revisión
DCRI.
3. Registrar hallazgos de verificación

Posterior a realizar los casos de revisión interna para la tarea entregada,
se procederá a registrar los hallazgos encontrados mediante el caso de
revisión, mismos que servirá para actualizar la tarea como concluida o
rechazada ( por políticas empresariales, incumplimiento de objetivos,
no cumple lo esperado, etc.).
Puede guiarse del ANEXO 22: Documento de hallazgos de verificación
149
F. Validación de actividad
Concluidas la totalidad de tareas comprendidas en la actividad

seleccionada se procederá a la validación de esta, por parte del usuario
final del sistema.
1. Solicitar reunión de usuarios para proceso de validación de

actividad
En este hito el líder del proyecto solicitará la reunión de los usuarios
que realizarán las pruebas sobre la actividad concluida.
2. Realizar pruebas de validación

En esta etapa el usuario final realizará las pruebas de validación en base
al Documento de casos de revisión del usuario DCRU
3. Registrar Hallazgos de validación

El líder del proyecto deberá registrar los hallazgos encontrados en el
hito de validación con el usuario bajo su perspectiva de experto.
Esta tarea debe de ejecutarse al mismo tiempo que el usuario está

realizando sus pruebas.
Este hito debe concluir con el Documento de hallazgos de validación

(DHVA). Puede guiarse del ANEXO 23: Documento de hallazgos de
validación
4. Evaluar la actividad actual en base a métricas de calidad

El comité de control de calidad deberá evaluar la actividad en base a
métricas de calidad estipuladas en el Documento Evaluación de
métricas de calidad (DEMC). Puede guiarse del ANEXO 24:
Documento de evaluación de métricas de evaluación (DEMC)
150
Figura 49. Etapa de Hacer, Subproceso Desarrollo de validación de actividad
151
5. Registrar resultado final de proceso de validación
Concluida el hito de validación del usuario mediante los casos de
revisión, el líder del proyecto deberá registrar el resultado final del
proceso, en el Documento de resultados de prueba de validación,
puede guiarse del ANEXO 23: Documento de hallazgos de validación.
De existir cambios o correcciones encontradas por el usuario final en la

actividad evaluada se procederá a solicitar registren estos, en el
Documento de formato de cambios y correcciones (DFCCK), de lo
contrario el hito de validación de actividad concluye.
6. Registrar cambios o correcciones

El líder del proyecto brindará al usuario final del documento DFCCK,
en el que deberá registrar los cambios y correcciones necesarias para
aprobar la actividad validada.
Puede guiarse del ANEXO 19: Documento de formato de control de

cambios y correcciones (DFCCK)
7. Analizar, priorizar y registrar en calendario

Posterior al llenado los cambios y correcciones del usuario, el líder del
proyecto deberá registrar en el calendario de actividades, lo solicitado
con su respectiva priorización de la actividad, las tareas asignadas de
ésta actividad y el tiempo para el desarrollo.
152
G. Generar entregable y reporte final del proyecto
El entregable representa un producto, un servicio, o un resultado, hacia el

que están orientadas todas las tareas descritas en el plan del proyecto y
definidas en el propio alcance del proyecto (de acuerdo con el modelo de
gestión de proyectos con el que se esté trabajando).
Así mismo deberá de registrarse en el Documento de resultados finales

del proyecto (DRFP), los alcances definidos por el líder del proyecto,
puede guiarse del ANEXO 25: Documento de resultados finales del
proyecto.
H. Generar documentación de calidad del producto
El proceso de documentación de calidad del producto lo realiza el comité

de control de calidad basado en las pruebas unitarias y los resultados de
cada tarea y así lograr un seguimiento del control de calidad interno del
producto basado en el plan del proyecto.
Obtenido el Documento de resultados finales del proyecto DRFP deberá

registrar sus observaciones como evaluador.
153
2.9.4.3.Verificar
Pasado un periodo previsto de antemano, los datos de control son recopilados y

analizados, comparándolos con los requisitos especificados inicialmente, para
saber si se han cumplido y, en su caso, evaluar si se han producido los objetivos
planteados para ello se debe monitorear la implementación y evaluar el plan de
ejecución documentando las conclusiones del proyecto sobre resultados y calidad
del producto.
Figura 50. Etapa de Verificación
A. Obtener documentos finales del proyecto

En este hito el líder del proyecto recolectara los documentos resultantes de la
etapa de Hacer para proceder con el análisis de los resultados.
B. Analizar y comprar resultados

En este hito el líder del proyecto contrastará los resultados del proyecto, contra
los esperados y estimados en la etapa de planificación, plasmados en el plan
del proyecto aprobado, en base a tiempo, costos, limitaciones, etc.
C. Generar documento de análisis de resultados

El proceso de documentación de análisis de los resultados por parte del líder
del proyecto corresponde al análisis ejecutado en el hito anterior y deberá
plasmarse en el Documento de análisis de resultados del proyecto, puede
guiarse en el ANEXO 26: Documento de análisis de resultados del proyecto
(DARPY).
154
2.9.4.4.Actuar
Por último, una vez finalizado el periodo de prueba se deben estudiar los
resultados y compararlos con el funcionamiento de las actividades antes de haber
sido implantada la mejora. Si los resultados son satisfactorios se implantará la
mejora de forma definitiva, y si no lo son habrá que decidir si realizar cambios
para ajustar los resultados o si desecharla. Una vez terminado el paso 4, se debe
volver al primer paso periódicamente para estudiar nuevas mejoras a implantar en
otros proyectos.
Para esta etapa se deberá seguir los siguientes procesos.
Figura 51. Etapa de Actuar
A. Convocar reunión final del proyecto
En esta etapa el jefe de proyecto establece la conclusión del proyecto y

solicita la reunión final al Directorio para entregar el producto y los
documentos de conclusión del proyecto.
155
B. Solicitar documentos del proyecto
En esta etapa el directorio solicita al jefe de proyecto los documentos
del proyecto dentro de los que se destaca.
1. Plan del proyecto aprobado: mismo que se obtuvo en la etapa

de planificación del proyecto
2. Documentos de resultado del proyecto: formato redactado por
el comité de control de calidad y el jefe de proyecto que da
termino al desarrollo y pruebas del producto.
En base a ello se generar el siguiente proceso.
C. Analizar el proyecto
En este proceso, el directorio realiza un análisis de los documentos
entregados que prescriben el inicio y el fin del proyecto, basándose en
dos puntos de vista:
1. La parte externa, el soporte de los documentos, su contenido,

los hallazgos encontrados y concordantes con las limitaciones
escritas en un principio
2. El apoyo del equipo del proyecto para determinar bajo un
estándar organizacional los futuros trabajos a desarrollar.
D. Establecer plan de mejora

Posterior al proceso de análisis de los documentos y del producto
resultante, el jefe de proyecto deberá establecer el proceso de plan de
mejora continua, con el fin de alcanzar la calidad total mejorando la
excelencia corporativa.
En este proceso de mejora, se demuestra el énfasis sobre la capacidad

que tiene la organización para evolucionar, progresar y desarrollarse de
manera sostenible, obteniendo resultados eficientes y de calidad en base
a su mercado laboral.
Para la elaboración del plan de mejora continua puede guiarse en el

ANEXO 9: Documento de plan de mejora continua (DPMC)
156
CAPITULO III
157
CAPITULO III: REPORTE DE RESULTADOS
3.1. Análisis y discusión de resultados
3.1.1. Análisis de resultados
En los últimos años la industria de software ha sufrido una creciente demanda

de productos o servicios que cumplan con todos los requisitos necesarios, en el
tiempo estimado, cumpliendo con los objetivos que se han propuesto para el
desarrollo de este.
Para calificar la efectividad de un proyecto es necesario, contar con diez factores

de referencia, entre ellos los más importantes son contar con un patrocinador
ejecutivo calificado que pueda cumplir con los objetivos planteados, y un nivel
de madurez emocional para el desarrollo. Para el desarrollo de esta investigación
se planteó un modelo de gestión para el aseguramiento de calidad en el producto
de software, que podrá ser aplicado junto a cualquier modelo de gestión de
desarrollo de proyectos o metodologías de desarrollo que existen en el mercado,
añadiendo el atributo de calidad en el producto final y un aprendizaje dentro de
la organización para futuros proyectos.
Para el desarrollo del modelo se empleó como base el modelo Deming de mejora
continua y dentro de ella el uso de modelos, metodologías y buenas prácticas
para describir cada etapa del modelo de gestión y control de calidad.
Deming plantea la metodología en 4 etapas continuas siendo estas: Plan, Do,

Check y Act (PDCA)
1. PLANEAR: en este proceso de desarrollo de proyecto se determinan como

principal objetivo el control y el rumbo que llevará a cabo el proyecto desde
su inicio, su actuar, su verificación y concluyendo por su aprendizaje de
proyecto. Para esta etapa se plantea un proceso que se llevará a cabo entre el
jefe del proyecto y el director o gerente de la PYME. Su entregable final es
el Plan de proyecto aprobado. Esta etapa inicia con una reunión inicial del
proyecto entre los directivos y el jefe del proyecto para establecer el plan de
158
trabajo, así como los estándares de calidad interna que llevaran a cabo, con
el fin de elaborar el plan de proyecto preliminar que posteriormente será
evaluado por el Director, de cumplir con lo requerido para el desarrollo del
mismo, y de estar acorde con sus políticas y objetivos se procederá a aprobar
el plan de proyecto y hacerlo participe al jefe del proyecto en una reunión
final, hito que inicia la etapa de Hacer.
2. HACER: en este proceso se lleva a cabo la implementación de las tareas y

las acciones necesarias para lograr las mejoras planteadas. Su entregable
final es Entregable del proyecto y Documento de resultados finales del
proyecto. En esta etapa el jefe del proyecto brinda al equipo que se encargará
del desarrollo del proyecto el plan de proyecto operativo con el fin de iniciar
con la ejecución de la secuencia de tareas establecidas en el calendario del
proyecto; concluido la etapa de desarrollo de tareas se genera el/los
entregable(s) y el Comité de control de calidad generará el apartado de
calidad del producto consolidado posterior a haber evaluado cada tarea,
además de efectuarse la actividad de validación de los usuarios.
3. VERIFICAR: este proceso se ejecuta posterior de haber terminado la etapa

de hacer y habiendo generado el entregable del proyecto, los datos de control
son recopilados y analizados, comparándolos con los requisitos
especificados inicialmente en la etapa de planear, y llevando a cabo una etapa
de verificación por parte de los usuarios. Su entregable final es el Documento
de análisis de resultado del proyecto.
4. ACTUAR: en esta última etapa se realiza una última reunión con el jefe de
proyecto y el director o gerente de la organización con el fin de verificar lo
acordado en la etapa de planificación contra lo resultante en la etapa de hacer
y verificar, y a partir de ello generar un plan de mejora continua para futuros
proyectos de desarrollo basados en buenas prácticas.
159
3.1.2. Discusiones
En el objetivo principal que se planteó en la presente investigación se estableció

el desarrollo de un modelo de gestión de proyectos de desarrollo de software
para el aseguramiento de la calidad del producto en PYME’s peruanas.
Tabla 36. Discusiones generales
Modelo Discusión
A diferencia del modelo planteado el modelo de PMBOK se
centra en la gestión del desarrollo del proyecto como tal y,
aunque presenta dentro de su planificación un apartado de
gestión de la calidad, el proceso es muy extenso debido a que
PMBOK se centra en el desarrollo de proyectos a gran escala y
PMBOK
no está concebido para organizaciones pequeñas con proyectos
de desarrollo acordes con su realidad.
Es por ello que el modelo planteado representa un control
mucho más corto pero efectivo para el aseguramiento de la
calidad en los productos finales a entregar.
El proceso PSP y TSP se centran en la entrega de un producto
de calidad basado en una serie de normas y procesos que deben
de ajustarse desde el inicio de cada proyecto para asegurar que
el entregable final cumple con los estándares requeridos, siendo
ellos mismos los gestores, evaluadores y actores del proceso
del aseguramiento de la calidad.
PSP Y TSP En el modelo que se planteó, existe un equipo de control de
calidad que dispone realizar las validaciones que se tomaron en
consideración el iniciar el proyecto y, siendo este un ente que
participa externamente al desarrollo del proyecto pero que a su
vez se encuentra estrechamente ligado a cada actividad, no
genera vínculos entre el personal que desvirtúen las discusiones
finales en cada control.
160
El modelo de excelencia EFQM representa una buena práctica
para el control de la calidad y su aseguramiento en cualquier
organización, sin embargo a diferencia con el modelo
planteado, el modelo EFQM presenta conceptos muy abstractos
que complican la implementación en una organización sin
contar con un consultor especialista acreditado, lo que se
EFQM concluye en un desembolso de dinero para la organización, sin
embargo el uso del modelo planteado representa una adición
al modelo o metodología que emplea la organización para el
desarrollo de proyectos, mejorando y aprendiendo a gestionar
su calidad del producto sin aumentar el tiempo necesario para
su desarrollo, mejorando la gestión de los costos y aprendiendo
de ellos para nuevos proyectos.
Moprosoft corresponde a un marco de trabajo para el desarrollo
de software que permite facilitar el cumplimiento de normas
de buenas prácticas como la ISO 9000:2000 y CMMI, se
orienta a mejorar los procesos para contribuir a los objetivos de
la organización.
A diferencia del Moprosoft, el modelo planteado no requiere
MOPROSOFT
contar con algún norma o guía de buena práctica previa, sino
que se adquiere durante el proceso, es decir si durante el
proceso, la organización decide emplear e interiorizar CMMI,
o alguna guía o norma ISO el modelo no se verá afectado, más
por el contrario se enriquecerá aún más de las acciones tomadas
por la organización.
161
3.2.Consideraciones finales
a. El modelo presentado en este proyecto de investigación correspondió a una
adaptación de los modelos de buenas prácticas y modelos de calidad que están
establecidos hasta el momento de desarrollo de la investigación.
b. Se propone emplear el modelo planteado en una PYME peruana de desarrollo y
realizar la medición cuantitativa del proceso y sus resultados.
c. Se propone desarrollar el modelo planteado en esta investigación en un framework
de computadora empleable en un sistema de control de proyectos.
3.3. Conclusiones
a. En la industria peruana de software, específicamente en las organizaciones de
pequeño y mediano tamaño (PYME’s) ha sufrido un incremento considerable
que se concluye en la necesidad cada vez mayor de software de calidad.
b. Las buenas prácticas representan un marco de trabajo y una dirección a seguir
para toda organización que desea brindar calidad en productos o servicios o
dentro de su organización, por ello para la constitución de este modelo y su
evaluación se ha establecido seleccionar las mejores normas que se adecuan
al desarrollo de software.
c. Una correcta evaluación de la calidad del software permite a la organización
conocer cuáles son los aspectos que deben mejorar en futuros proyectos,
asegurando satisfacer sus necesidades como organización. Es por ello que
dentro del marco de evaluación la presente investigación centraliza las
principales métricas de evaluación.
d. El correcto uso del modelo de gestión y calidad en el desarrollo en proyectos
de software mejorará el producto final y logrará generar un proceso de
aprendizaje para la organización.
3.4. Resultados
Tras la validación y juicio de expertos, concluyeron que el modelo MGCQ
presentado representa un modelo consistente con el sector de desarrollo actual, en un
paradigma de desarrollo ágil de proyectos de software, para PYME’s
162
Sin embargo, determinan que sería consistente incluir mejoras para el modelo MGCQ
que añaden su fusión con la norma ISO/IEC 29110, ciclos de vida del software,
además de mejorar el aspecto de gestión de riesgos e incluir el plan de mejora
continua de forma transversal sobre cada etapa, concluyendo en un consolidado final.
Figura 52. Juicio de experto 1, último resultado de análisis
163
164
165
REFERENCIAS
[1] C. L. Vega, L. S. P. River y A. S. Garcia, Mejores prácticas para el

establecimiento y aseguramiento de calidad de software, Medellín, Colombia,
2008.
[2] W. Perry, Quality assurance for information systems, Wellesley, USA: QED
technical publishing group, 1991.
[3] Institute of Electrical and Electronics Engineers, «IEEE,» [En línea]. Available:
https://www.ieee.org/.
[4] International Software Testing Qualifications Board, «ISTQB,» 2018. [En línea].
Available: https://www.istqb.org.
[5] The Standish Group, «The Standish Group,» 2018. [En línea]. Available:
https://ww.standishgroup.com.
[6] O. Camacho Carrillo, Interviewee, ¿Por qué fracasan los proyectos de TI en el

estado Peruano?. [Entrevista]. 7 10 2015.
[7] A. M. Solyman, O. A. Ibrahim y A. A. Mohammed Elhag, «Project management

and software quality control method for small and medium enterprise,» de
International Conference on Computing, Control, Networking, Electronics and
Emvedded Systems Engineering, Khartoum, Sudan, 2015.
[8] Y. Chen, J. Chen, Y. Gao, D. Chen y Y. Tang, «Research on Software Failure

Analysis and Quality Management Model,» de IEEE International Conference on
Software Quality, Reliability and Security Companion, Beijing, China, 2018.
[9] Y. Zhao, J. Gong, Y. Hu, Z. Liu y L. Cai, «Analysis of quality evaluation based on
ISO/IEC SQuaRE series standards and IT's considerations,» IEEE Computer
society, pp. 245-250, 2017.
[10] Y. Lin, Z. Liu y L. Cai, «Application an method of quality management for small-
size software project,» de IET International Conference on Information Science
and Control Engineering 2012, Shenzhen, China, 2012.
[11] S. V. Aleksandrova, V. Vasiliev y G. M. Letuchev, «Digital Technology and

Quality Management,» de International Conference "Quality Management,
Transport and Information Security, Information Technologies" (IT&QM&IS), St.
Petersburg, Russia, 2018.
[12] E. N. Desyatirikova, V. E. Belousov, V. N. Zolotarev y O. Y. Lavlinskaia,

«Design process of software quality management,» de International Conference
166
"Quality Management,Transport and Information Security, Information
Technologies" (IT&QM&IS), St. Petersburg, Russia, 2017.
[13] S.-J. Huang, W.-C. Chen y P.-Y. Chiu, «Evaluation Process Model of the
Software Product Quality Levels,» de International Conference on Industrial
Informatics - Computing Technology, Intelligent Technology, Industrial
Information Integration, Wuhan, China, 2015.
[14] A. Dávila, C. Basurto, L. Flores, R. Manrique, R. Arisaca, J. Sánchez y M.

Schneck de Paula Pessôa, «The peruvian component of Competisoft project:
Lesson learned from academic perspective,» de XXXVIII Conferencia
Latinoamericana En Informatica (CLEI), Medellin, Colombia, 2012.
[15] Real Academia Española, «Diccionario de la lengua española,» 2019. [En línea].
Available: https://dle.rae.es/?w=diccionario.
[16] International Organization for Standardization, «ISO 9001:2015,» 2015. [En

línea]. Available: https://www.iso.org.
[17] E. Deming, Out of the Crisis, Massachussets: Massachussets Institute of

Technology, 1982.
[18] J. Juran, Juran y la planificacion de la calidad, Madrid: Diaz de santos S.A., 1990.
[19] R. Pressman, Ingeniería del Software. Un enfoque prático, Septima ed., P. R.

Vázquez, Ed., Mc Graw Hill, 2010.
[20] V. A. Secades, «Gestion de la calidad, su impacto en la sociedad,» Sociedad y

utopía: Revista de ciencias sociales, pp. 239-252, 2004.
[21] A. H. Gago, Modelos de sistematización del proceso de enseñanza-aprendizaje,

Mexico: Trillas, 1999.
[22] J. R. Aguileta, « Modelo Querétaro: CIIDET, Maestría en Ciencias en Enseñanza

de las Ciencias.,» 2000.
[23] M. E. Arevalo Lizardo, «Arevalo Maria,» 25 6 2011. [En línea]. Available:

https://arevalomaria.wordpress.com.
[24] D. Davis, «Project Management,» 29 9 2014. [En línea]. Available:

https://www.projectmanagement.com/blog-post/10732/Benefits-Realization-PMI-
Model.
[25] Esan, «Conexion Esan,» 12 9 2016. [En línea]. Available:

https://www.esan.edu.pe/apuntes-empresariales/2016/09.
[26] A. Colmenares, «formulaproyectosurbanospmipe,» 18 3 2012. [En línea].

Available: https://formulaproyectosurbanospmipe.wordpress.com/2012/03/18.
167
[27] Project Management Institute, Guia de funamentos para la dirección de proyectos
PMBOK, Pensilvania, EEUU: Project Management Institute, Inc., 2013.
[28] G. Gbegneji, «Gladys Gbegnedji,» 2017. [En línea]. Available:

https://www.gladysgbegnedji.com/project-manager/.
[29] M. Callejas Cuervo, A. C. Alarcón Aldana y A. M. Álvarez Crreño, «Modelos de

calidad del software, un estado del arte,» Ingeniería y Tecnología, pp. 236-250,
2017.
[30] F. Scalone, «Estudio comparativo de los modelos y estándares de caidad del

software,» Tesis Ingeniería de Calidad, Buenos Aires - Argentina, 2006.
[31] Ingenieria Software, «Modelo de Calidad de FURPS,» 2006. [En línea].

Available: http://clases3gingsof.wikifoundry.com/page/FURPS.
[32] L. Bautista Quispe, A. Chaico Lebano, L. Gavilar Pecho, M. Guillen Martinez, A.

Mandujano Bendezú y M. Marca Juarez, «Modelos de Calidad de Software,»
2012. [En línea]. Available: https://es.scribd.com/doc/138528080/Modelos-de-
Calidad-de-Software.
[33] F. Scalone, «Estudio comparativo de los modelos y estándares de calidad de

software,» Buenos Aires, 2006.
[34] A. J. Espejo Chavarría, «Modelo de aseguramento de calidad en el proceso de

desarrollo de software basado en los modelos de madurez de capacidades
(CMMI), proceso de software para equipos (TSP) y personas (PSP),» Universidad
Mayor de San Marcos, Lima, 2016.
[35] ISO Tools Excellence, «SGSI,» 18 1 2018. [En línea]. Available:

https://www.pmg-ssi.com/2018/01/estandar-internacional-iso-iec-15504/.
[36] Anónimo, «Blogspot,» 18 10 2012. [En línea]. Available:

http://procesosoftwareai.blogspot.com/2012/10/bootstrap.html.
[37] F. Scalone, «Tesis: "Estudio Comparativo de los modelos y estandares de calidad

del software",» Buenos Aires, 2016.
[38] ISO 25000, «ISO 25000,» [En línea]. Available: http://www.iso25000.com.
[39] R. Hernandez Sampieri, C. Fernandez Collado y P. Baptista Lucio, Metodología

de la investigacion, Mexico D.F.: McGraw Hill, 2014.
[40] A. Taboada Escajadillo, «INDUSTRIA PERUANA DE SOFTWARE:

PERSPECTIVAS,» Lima, 2008.
[41] Apesoft, «Apesoft,» 2008. [En línea]. Available: https://apesoft.org/.
[42] Gestion, «Mercado de la informática en Perú crecerá 9.7% este año,» Gestion, 6 3
2019.
168
[43] Microsoft, «Microsoft,» 2019. [En línea]. Available: https://news.microsoft.com/.
[44] International Data Corporation, «IDC,» 2018. [En línea]. Available:

http://pe.idclatin.com/default.aspx.
[45] América Sistemas, «Cifras al desnudo: Industria TIC,» América Sistemas, 23 5

2018.
[46] D. Edery Muñoz, «Programa crea software Perú,» Lima, 2007.
[47] Gestión, «Apesoft: Con entidad dedicada a las TIC se duplicaría el crecimiento del
sector software,» Gestión, 9 4 2017.
[48] Apesoft, «Apesoft,» 2017. [En línea]. Available: https://apesoft.org/.
[49] The Standish Group, «The Chaos Report,» Boston, USA, 2015.
[50] CMMI Institute, «CMMI Institute LLC.,» 2019. [En línea]. Available:
https://cmmiinstitute.com/.
[51] C. Cano, A. Melgar, A. Dávila y M. Pessoa, «Comparison of software process

models. A systematic literature review,» de Latin American Computing
Conference (CLEI), Arequipa, Perú, 2015.
[52] E. Gonzalez, «Acerca del estado de la cuestión o sobre un pasado reciente en la

investigacion cualitativa con enfoque hermenéutico,» Unipluriversidad, pp. 60-63,
2013.
[53] P. Ricaute, «¿Cómo ha cambiado el avance tecnológico de los últimos años

nuestro modo de vida?,» 17 4 2010. [En línea]. Available:
https://mediosfera.wordpress.com.
[54] A. González Reyes, M. André Ampuero y A. Hernández González, «Análisis

comparativo de modelosy estándares para evaluar la calidaddel producto de
software,» pp. 43-52, 2015.
[55] Y. Jarvio Hernández, P. Velasco Elizondo y E. Benítez Guerrero, «Evaluando

Adecuación Funcional y Usabilidad en Herramientas de Composición desde la
Perspectiva del Usuario Final,» Revista lbérica de Sistemas y Tecnologías de
Información, pp. 96-114, 2016.
[56] A. Cornejo, «Normas y estandares de proyecto TI,» 29 1 2015. [En línea].

Available: https://normasyestandaresproyectosti.wordpress.com/2015/01/29/iso-
12207/.
169
ANEXOS
170
ANEXOS GENERALES
ANEXO 1: Documento de reunión inicial del proyecto (DRI)
<Empresa> DRI
<Logo> Fecha:
Documento de reunión inicial del Versión:
proyecto
Página:
Unidad Administrativa
Área Responsable
Responsable
CONSIDERACIONES INICIALES
Propósito
ASISTENTES A LA REUNIÓN
Area asistente a
Nombres y apellidos Abreviatura Correo
reunión
DISCULPAN SU INASISTENCIA
Área asistente a reunión Nombres y apellidos Correo
AGENDA DE TRABAJO
TEMA BENEFICIARIO HORA INICIO DETALLE
Gerente General Líder de proyecto
171
ANEXO 2: Documento de Políticas empresariales (DPE)
<Empresa> DPE
<Logo> Fecha:
Documento de políticas empresariales Versión:
Página:
Área Responsable
Responsable
Propósito
Alcance
DETALLE DE POLÍTICA: descripción detalladas de las políticas que regirán el actuar de la

empresa
ÁREA CATEGORÍA POLÍTICA
Área en el que se regirá la Tipo de política que se Detalle da la política y su alcance en el área y
política en cuestión implementará categoría establecida
Responsable 1 Gerente General
172
ANEXO 3: Documento de Objetivos Empresariales (DOE)
<Empresa> DOE
<Logo> Fecha:
Documento de objetivos empresariales Versión:
Página:
Área Responsable
Responsable
Alcance de objetivos
Objetivos primarios: detalle de objetivos principales y secundarios, así como su peso de medición
para su alcance
Objetivo Principal Objetivo Secundario Medición
Objetivo basado en expresiones generales Objetivos basados en cantidad y tiempo Nivel de Medición del
objetivo
Objetivos empresariales: detalle de objetivos estratégicos y tácticos y su respectiva medición

Objetivo Estratégico Objetivo Táctico Medición
Considera a la empresa como un todo, define Dirigido en base a áreas y departamentos en Nivel de Medición del
el rumbo de la empresa específico objetivo
Responsable 1 Gerente General
173
ANEXO 4: Documento de aspectos legales (DAL)
<Empresa> DAL
<Logo> Fecha:
Documento de aspectos legales Versión:
Página:
Área Responsable
Responsable
Alcance legal
Justificación
Aspectos legales: detalle de los aspectos generales que determinan el actuar legal de la empresa.
Política organizacional
Categoría legal Artículo legal Detalle de artículo legal
asociada
Área Legal Gerente General
174
ANEXO 5: Documento de presupuesto para el proyecto (DPP)
<Empresa> DPP
<Logo> Fecha:
Documento de presupuesto para el Versión:
proyecto
Página:
Área Responsable
Responsable
Propósito
Alcance
DETALLE DE COSTOS: comprende los costos generales, de infraestructura, hardware y

software
CATEGORIA DETALLE PRESUPUESTO EXCESO
monto en efectivo con la
Tipo de caterogía en el alcance de lo que comprende Porcentaje de exceso
divisa q maneja la
presupuesto la categoria para el caso
organización
Contabilidad y Finanzas Gerente General
175
ANEXO 6: Documento de tiempo total para el proyecto (DTTP)
<Empresa> DTTP
<Logo> Fecha:
Documento de tiempo total para el Versión:
proyecto
Página:
Área Responsable
Responsable
Propósito
DETALLE DE TIEMPO: estimación del tiempo total para desarrollo, pruebas, aprendizaje y el
general que demanda el desarrollo del proyecto
CATEGORÍA DETALLE TIEMPO EXCESO
detalle de las actividades que Tiempo que tomará la
Tipo de categoría de Porcentaje de tiempo
puedan comprender la categoría para ser concluida
estimación de tiempo que podrá excederse
categoría totalmente
Gerente General
176
ANEXO 7: Documento de requerimiento del proyecto (DRPY)
<Empresa> DRPY
<Logo>
Fecha:
Documento de requerimiento del Versión:
proyecto
Página:
Área Responsable
Responsable
Alcance
Proyecto
Nro de requerimiento Dependecia
Usuario
Cargo de usuario
Analista responsable
Requerimiento
Detalle de Requerimiento
Tipo Requerimiento Funcional No funcional

Restricciones del requerimiento
Usuario
177
ANEXO 8: Documento de listado requerimientos del proyecto (DLRPY)
<Empresa> DLRPY
<Logo> Fecha:
Documento de listado de requerimientos Versión:
del proyecto
Página:
Área Responsable
Responsable
Alcance
Proyecto
Líder del proyecto
Comité de control de calidad
Requerimientos
Totalidad de requerimientos
Nro Requisito Tipo Imp Estado Objetivo Validación
Líder de proyecto
178
ANEXO 9: Documento de plan de mejora continua (DPMC)
<Empresa> DPMC
<Logo> Fecha:
Documento de plan de mejora continua Versión:
Página:
Área Responsable
Responsable
Propósito
DETALLE DE FUNCIONALIDADES: Listado de funcionalidades a mejorar

Funcionalidad Detalle
Proyecto
Requerimiento asociado
Descripcion de Hallazgo
Causa que provoca el

problema
Objetivo a conseguir
1.
Acciones de mejora 2.
3.
Beneficios esperados
Plazo Priorización
Dificultad Impacto
Gerente General Líder del proyecto
179
ANEXO 10: Documento de perfiles de equipo de trabajo (DPET)
<Empresa> DPET
<Logo> Fecha:
Documento de perfiles de equipo de Versión:
trabajo
Página:
Área Responsable
Responsable
Propósito
Proyecto
PERFIL PROFESIONAL
Área
Puesto
PERFIL FUNCIONES JEFE INMEDIATO
Perfil profesional del puesto Funciones a desempeñar del perfil Puesto del jefe inmediato
Gerente Responsable 1 Líder de proyecto
180
ANEXO 11: Documento de plan de trabajo (DPT)
<Empresa> DPT
<Logo>
Fecha:
Documento de plan de trabajo Versión:
Página:
Área Responsable
Responsable
Justificación
Proyecto
CUADRO RESUMEN INICIAL
ACTIVIDAD META CRONOGRAMA RESPONSABLE
RECURSOS DEL PROYECTO

RECURSO DESCRIPCIÓN
DATOS FINALES DEL PROYECTO

Evaluación del proyecto
Presupuesto y financimiento
181
ANEXO 12: Documento de formato y estilo de programación (DFP)
<Empresa> DFP
<Logo> Fecha:
Documento de formato y estilo de Versión:
programación
Página:
Área Responsable
Responsable
Propósito
Proyecto
Lenguaje Programación
Base de datos
Tipo Producto
DETALLE ESPECÍFICO: respecto a comentarios, variables, limitaciones, tamaño de líneas de

código por clase, herencias, funciones, métodos, constructores, documentación, declaraciones, uso de
framework, declaraciones, constantes y referencias
CATEGORIA EJEMPLO DETALLE

Categoría específica para el
Ejemplo de la categoría Detalle específico y su comprensión de la categoría
formato de programación
Control de fuentes
Iteración de
versionamiento
182
ANEXO 13: Documento de formato y estilo de base de datos
<Empresa> DEBD
<Logo> Fecha:
Documento de formato y estilo de base Versión:
de datos
Página:
Área Responsable
Responsable
Propósito
Proyecto
Motor de base de datos
Versión de base datos
Nombre base de datos
Tipo base de datos
DETALLE ESPECÍFICO: respecto a tamaño de nombres, nomenclatura, procedimientos

almacenados, disparadores, planes de mantenimiento, tablas, campos, comentarios, scripts
CATEGORIA EJEMPLO DETALLE

Categoría específica para el
Ejemplo de la categoría Detalle específico y su comprensión de la categoría
formato de base de datos
Iteración de
versionamiento
183
ANEXO 14: Documento de caso de revisión interna (DCRI)
<Empresa> DCRI
<Logo> Fecha:
Documento de caso de revisión interna Versión:
Página:
Área Responsable
Responsable
Propósito
Proyecto
Tarea de revisión
Porcentaje de aceptación
ANÁLISIS: formato de revisión de acuerdo a la tarea a revisar
TAREA ACEPTACIÓN OBSERVACIÓN
Tarea de desarrollo a Porcentaje de aceptación de la
Consideraciones para tomar sobre la tarea
verificar tarea
Consideración final de la
tarea
Comité de control de calidad Líder de proyecto
184
ANEXO 15: Documento de casos de revisión del usuario (DCRU)
<Empresa> DCRU
<Logo>
Fecha:
Documento de casos de revisión del Versión:
usuario
Página:
Área Responsable
Responsable
Propósito
Proyecto
Actividad validada
Usuario que valida
ANÁLISIS: rformato de revisión de acuerdo a la tarea a revisar
ACTIVIDAD ACEPTACIÓN OBSERVACIÓN
Tarea de desarrollo a Porcentaje de aceptacion de
Consideraciones para tomar sobre la tarea
verificar la tarea
Resultados finales
185
ANEXO 16: Documento de formato de medición del proyecto (DFMP)
<Empresa> DFMP
<Logo> Fecha:
Documento de formato de medición del Versión:
proyecto
Página:
Área Responsable
Responsable
Propósito
Proyecto
Versión de proyecto
Responsable
ANÁLISIS Y MEDICIÓN: formato de revisión de acuerdo a la tarea a revisar
MÉTRICA INDICADOR DETALLE VALOR
Indicador de métrica a Indicador de metrica Valor de calculo
¿Qué evaluará?
evaluar seleccionada aceptable
186
ANEXO 17: Documento de estándares del producto (DECPR)
<Empresa> DECPR
<Logo> Fecha:
Documento de estándares del producto Versión:
Página:
Área Responsable
Responsable
Propósito e Importancia
Proyecto
Responsable
EVALUACIÓN DE CALIDAD
Evaluador
MÉTRICA INDICADOR REQUISITO FORMULA RESULTADO
Indicador de métrica Fórmula para
Métrica a evaluar Requisito de revisión Valor obtenido
a evaluar análisis
187
ANEXO 18: Documento de formato de entrega de versiones (DFEV)
<Empresa> DFEV
<Logo> Fecha:
Documento de formato de entrega de Versión:
versiones
Página:
Área Responsable
Responsable
Proyecto
Responsable
Evaluador
Observaciones de la versión entregada
Cliente Líder de proyecto
188
ANEXO 19: Documento de formato de control de cambios y correcciones
(DFCCK)
<Empresa> DFCCK
<Logo> Fecha:
Documento de formato de control de Versión:
cambios y correcciones
Página:
Área Responsable
Responsable
Proyecto
IMPLICACIONES
Tipo de análisis Categoría Causa Descripción
Alcance, cronograma, costos, ¿Qué provoca el cambio o Detalle de la causa del
Cambio o corrección
calidad, recursos corrección? cambio o corrección
189
ANEXO 20: Documento de estándares del proyecto (DECPY)
<Empresa> DECPY
<Logo> Fecha:
Documento de estándares del proyecto Versión:
Página:
Área Responsable
Responsable
Proyecto
Responsable
Evaluador
Área de evaluación
EVALUACION INDICADOR RESPONSABLE EVLUACIÓN RESULTADO
concepto de Indicador de Responsable de área o Forma de
Valor obtenido
evaluación evaluación proceso evaluación
Comité de control de
Líder de proyecto
calidad
190
ANEXO 21: Documento de plan de proyecto (DPY)
<Empresa> DPY
<Logo> Fecha:
Documento de plan de proyecto Versión:
Página:
Área Responsable
Responsable
Alcance del proyecto
Proyecto
ENTREGABLES
Nro. Descripción Lugar y fecha de entrega Condiciones de entrega
EVOLUCION DEL PLAN

Responsable de Código de documento de Código de documento de
Frecuencia de monitoreo
monitoreo monitoreo cambio de plan
ORGANIZACIÓN DEL PROYECTO

Organización del proyecto: calendarios y tiempo
Estructura jerárquica de la organización
191
Responsables
Actividad para Descripción de la
Responsable Involucrado
realizar actividad
GESTIÓN DEL PROYECTO

Objetivos y prioridades administrativas
Proceso Nro. Documento Detalle de documento
Restricciones del proyecto
Gestión de riesgos
Nro. Riesgo Categoría Detalle Seguimiento
Recursos
PROCESO TÉCNICO
Procedimientos técnicos, herramientas y tecnologías
Nro. Herramienta Herramienta Detalle de Herramienta
Documentación
Nro. Documento Entregable Detalle documento Responsable
192
ANEXO 22: Documento de hallazgos de verificación
<Empresa> DHVE
<Logo> Fecha:
Documento de hallazgos de verificación Versión:
Página:
Área Responsable
Responsable
Proyecto
Responsable
HALLAZGOS
Evaluador
Tarea Hallazgos Detalle de hallazgos Estado
nombre tarea concepto de hallazgo detalle de lo encontrado por cada tarea Cumple o no cumple
193
ANEXO 23: Documento de hallazgos de validación
<Empresa> DHVA
<Logo> Fecha:
Documento de hallazgos de validación Versión:
Página:
Área Responsable
Responsable
Proyecto
Responsable validación
HALLAZGOS
Evaluador de validación
Actividad Hallazgos Detalle de hallazgos Estado
nombre actividad concepto de hallazgo detalle de lo encontrado por cada tarea Cumple o no cumple
Líder de proyecto
194
ANEXO 24: Documento de evaluación de métricas de evaluación (DEMC)
<Empresa> DEMC
<Logo>
Fecha:
Documentos de evaluación de métricas Versión:
de control
Página:
Área Responsable
Responsable
Justificación e Importancia
Proyecto
Responsable evaluación
Nivel de calidad interna del
producto
Porcentaje concluido
MÉTRICAS DE EVALUACIÓN
Módulo Entregable Variable Valor Variable Resultado Valor
Módulo de Sub entregable de Variable para Valor de variable de Resultado de Valor que se
evaluación evaluación evaluación análisis calculo espera
Comité de control de
calidad
195
ANEXO 25: Documento de resultados finales del proyecto
<Empresa> DRFP
<Logo> Fecha:
Documento de resultados finales del Versión:
proyecto
Página:
Área Responsable
Responsable
Alcance
Proyecto
Líder del proyecto
Entregable
PROYECTO
Nivel de alcance concluido del proyecto
Porcentaje de termino de Nivel de calidad interna
Actividad
actividad estimada
Actividad del calendario de
actividades estipulado en el Nivel de completitud de actividad por Totalidad de observaciones que considera el
plan de proyecto y los parte del líder del proyecto usuario que valida
cambios requeridos
196
Tiempo y costos empleados
Actividad Tiempo estimado Tiempo Real Costo estimado Costo Real
Actividad del calendario

de actividades Tiempo que se estimó en Tiempo que realmente Costo que se estimó en Costo que realmente
estipulado en el plan de el plan de proyecto empleo para concluir la el plan de proyecto empleo para concluir la
proyecto y los cambios aprobado actividad aprobado actividad
requeridos
Recursos empleados
Actividad Recursos estimados Recursos empleados
Actividad del calendario de
Recursos que se estimaron en el plan Recursos que se emplearon en el plan de
actividades estipulado en el
de proyecto (infraestructura, software, proyecto (infraestructura, software,
plan de proyecto y los
hardware, licencias, etc.) hardware, licencias, etc.)
cambios requeridos
197
ANEXO 26: Documento de análisis de resultados del proyecto (DARPY)
<Empresa> DARPY
<Logo> Fecha:
Documento de análisis de resultados del Versión:
proyecto
Página:
Área Responsable
Responsable
Alcance
Proyecto
Líder del proyecto
PROYECTO
Nivel de alcance concluido del proyecto
Categoría de Valor
Valor Estimado Observaciones
medición Empleado
valores de categoría de
Cálculo establecido en Cálculo establecido
medición del proyecto Motivos y observaciones de la
el plan de proyecto durante el desarrollo
(tiempo, costos, alcance, medición
aprobado del proyecto
objetivo, etc.)
Líder de proyecto
198
ANEXO 27: Hoja de vida de Experto 1
199
200
201
202
203
204
205
206
207
208
209
210

Proyecto Tesis en Gestion de Calidad de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Proyecto Tesis en Gestion de Calidad de Software

Hochgeladen von

Copyright:

Verfügbare Formate

FACULTAD DE INGENIERIA, ARQUITECTURA Y

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA

MODELO DE GESTIÓN DE PROYECTOS Y

PARA LA APROBACIÓN DE LA ASIGNATURA DE

Jimmy André Arroyo Caballero

Infraestructura, tecnología y medio Ambiente

Por ser mis mayores fuentes de inspiración y alegría en el trayecto de mi vida,

La industria peruana del software ha crecido considerablemente en los últimos años,

Palabras clave: calidad, software, modelo, gestión, desarrollo

Keywords: quality, software, model, management, development

1.1. Planteamiento del problema. ................................................................................................................ 14

1.2. Antecedentes de estudio ........................................................................................................................ 18

1.3. Abordaje Teórico ................................................................................................................................... 22

1.4. Formulación del problema .................................................................................................................... 97

1.5. Justificación e importancia del estudio ................................................................................................ 97

1.6. Hipótesis ................................................................................................................................................. 98

2.1. Tipo de estudio y diseño de la investigación ...................................................................................... 100

2.2. Escenario de estudio ............................................................................................................................ 100

2.3. Caracterización de sujetos .................................................................................................................. 101

2.4. Técnicas e instrumentos de recolección de datos .............................................................................. 101

2.5. Procedimientos para la recolección de datos ..................................................................................... 102

2.7. Criterios éticos ..................................................................................................................................... 103

2.8. Criterios de rigor científico ................................................................................................................. 103

2.9. Modelo de trabajo................................................................................................................................ 104

1.8. Análisis y discusión de resultados ...................................................................................................... 157

1.9. Consideraciones finales ....................................................................................................................... 161

1.10. Conclusiones......................................................................................................................................... 161

ANEXO 1: Documento de reunión inicial del proyecto (DRI) ...................................................................... 170

ANEXO 2: Documento de Políticas empresariales (DPE)............................................................................. 171

ANEXO 3: Documento de Objetivos Empresariales (DOE) ......................................................................... 172

ANEXO 4: Documento de aspectos legales (DAL) ......................................................................................... 173

ANEXO 5: Documento de presupuesto para el proyecto (DPP)................................................................... 174

ANEXO 6: Documento de tiempo total para el proyecto (DTTP) ................................................................ 175

ANEXO 7: Documento de plan de mejora continua (DPMC) ...................................................................... 178

ANEXO 8: Documento de perfiles de equipo de trabajo (DPET) ................................................................ 179

ANEXO 9: Documento de plan de trabajo (DPT) ......................................................................................... 180

ANEXO 10: Documento de formato y estilo de programación (DFP) ......................................................... 181

ANEXO 11: Documento de formato y estilo de base de datos ...................................................................... 182

ANEXO 12: Documento de caso de revisión interna (DCRI) ....................................................................... 183

ANEXO 16: Documento de formato de entrega de versiones (DFEV)......................................................... 187

ANEXO 17: Documento de formato de control de cambios y correcciones (DFCCK)............................... 188

ANEXO 18: Documento de estándares del proyecto (DECPY) .................................................................... 189

ANEXO 19: Documento de plan de proyecto (DPY) ..................................................................................... 190

ANEXO 20: Documento de hallazgos de verificación.................................................................................... 192

ANEXO 21: Documento de hallazgos de validación ...................................................................................... 193

ANEXO 22: Documento de evaluación de métricas de evaluación (DEMC) ............................................... 194

ANEXO 23: Documento de resultados finales del proyecto .......................................................................... 195

ANEXO 25: Hoja de vida de Experto 1 .......................................................................................................... 198

ANEXO 26: Hoja de vida de Experto 2 .......................................................................................................... 200

ANEXO 27: Hoja de vida de Experto 3 .......................................................................................................... 206

Tabla 1. Evolución del estado de proyectos ..................................................................................................... 15

Figura 1. Curva de falla de software. Copyright 2010 por Pressman, R. ......................................................... 25

1.1.Planteamiento del problema.

Tabla 1. Evolución del estado de proyectos

2011 2012 2013 2014 2015

Para calificar la efectividad de un proyecto es necesario, de acuerdo con los estudios

El tamaño del software es también un punto importante para calificar la investigación de

Tabla 2. Tamaño de proyecto por evolución

El servicio nacional de salud, el sistema de sanidad público de Inglaterra, el mayor y más

Hubo discusiones contractuales desde el principio, con constantes cambios de

A las irrealistas previsiones, tanto de tiempo como de costes, se sumaron un inadecuado

Con el presente trabajo de investigación se pretende, desarrollar un modelo para la gestión

[7] detectaron en su investigación que existe un gran problema en la confianza, la