ZAC TE 66

Vista previa del material en texto

T E S I S 
Que para obtener el grado de 
Maestro en Ingeniería de 
Software 
 
Presenta 
Saúl Alonso Ibarra Luevano 
 
D irector de Tesis: 
Dr. Mirna Ariadna Muñoz Mata 
Guanajuato, Gto., 25 de Noviembre de 2018 
DESARROLLO DE UNA 
HERRAMIENTA DE SOPORTE 
PARA EL ASEGURAMIENTO DE 
LA CALIDAD EN PRODUCTOS 
DE SOFTWARE 
 
 
 
 
 
Guanajuato, Gto., 25 de Noviembre del 2018 
DESARROLLO DE UNA 
HERRAMIENTA DE SOPORTE 
PARA EL ASEGURAMIENTO DE 
LA CALIDAD EN PRODUCTOS 
DE SOFTWARE 
 
T E S I S 
Que para obtener el grado de 
Maestro en Ingeniería de 
Software 
 
Presenta 
Saúl Alonso Ibarra Luevano 
 
D irector de Tesis: 
Dr. Mirna Ariadna Muñoz Mata 
Autorización de la versión 
final 
	
	
1	
	
	
	
	
	
	
	
Desarrollo de una herramienta de soporte 
para el aseguramiento de la calidad en 
productos de software	
Centro de Investigación en Matemáticas A.C.	
T E S I S	
Que para obtener el grado de 	
Maestro en Ingeniería de Software	
	
Presenta	
Saúl Alonso Ibarra Luevano	
	
Director de Tesis:	
Dra. Mirna Ariadna Muñoz Mata 	
	
Codirector:	
Dr. Jezreel Mejía Miranda 	
	
Zacatecas, Zac. Octubre de 2018	
 
	
	
3	
Agradecimientos 
A mi familia, mis padres; Arcelia y Saúl, mis hermanas; Carolina, Araceli, Isabel y Alejandra 
y a mi hermano Omar, por todo su amor, sus consejos y su apoyo incondicional a lo largo de 
mi vida. 
A mis tutores, la Dra. Mirna Ariadna Muñoz Mata y al Dr. Jezreel Mejia Miranda, por su 
tiempo, sus conocimientos y su guía a lo largo de la maestría. 
A mis compañeros del CIMAT Unidad Zacatecas, por su amistad y compañerismo. 
A los Doctores y Maestros de CIMAT Unidad Zacatecas que me dieron clases y me 
compartieron un poco de su conocimiento. 
Al Consejo Nacional de Ciencia y Tecnología (CONACYT), por el apoyo económico por el 
cual fue realizado el presente trabajo de tesis. 
Y finalmente al Centro de Investigación en Matemáticas (CIMAT), por sus apoyos y 
facilidades otorgadas durante la maestría. 
 
	
	
4	
Abstract 
In recent years the software industry has been growing in their relevance, so that 4 of 5 most 
capitalized companies in the stock market are dedicated to Information Technology area. In 
the same way, the resources that companies dedicate to their product quality have increased, 
this fact is demonstrated in the large number of models and quality standards such as: CMMI, 
ISO/IEC standards, among others. These models and standards contain practices that help 
organizations to achieve better levels in the quality of their processes and products generated. 
Moreover, with the new trends such as the Internet of Things (IoT), applications for mobile 
devices, technologies for Big Data, etc., quality assurance activities have become more 
complex, so that they require knowledge from experts to achieve their implementation. 
However, reports such as the Chaos Report indicate that only 37% of the projects are 
successful, 45% of the projects are changed and the 18% of the projects fail and/or are 
completely canceled. 
In this thesis, a tool, which covers 5 essential software quality assurance activities, was 
developed, so that it allows the promotion of the activities and facilitates their 
implementation. 
The results of a case study demonstrate that the tool is flexible and it can be taylored to 
different development environments, so that it helps to communicate to the development 
teams, the status of the performances of activities related to quality and the results regarding 
the products validation and verification so that, the prevention of defects can be improved. 
Keywords: quality assurance, product quality, quality assurance activities, software 
product, quality tool. 
	 
	
	
5	
Resumen 
En los últimos años la industria de software ha cobrado relevancia, al punto que, 4 de las 
principales 5 empresas más capitalizadas en el mercado bursátil se dedican al área de las 
Tecnologías de la Información. De igual manera, se han incrementado los recursos que las 
empresas dedican a la calidad de sus productos, esto se ve reflejado en la gran cantidad de 
modelos y estándares de calidad como: CMMI, estándares ISO/IEC, entre otros, que 
contienen prácticas que ayudan a las organizaciones a alcanzar mejores niveles en la calidad 
de su organización referente a sus procesos y productos generados. 
Lo que es más, con el auge de nuevas tendencias como el internet de las cosas (IoT), 
aplicaciones para dispositivos móviles, tecnologías para Big Data, etc., las actividades para el 
aseguramiento de la calidad se ha convertido en tareas complejas que requieren de 
conocimiento de expertos en el área para lograr su implementación. Sin embargo, reportes 
como el Chaos Report, indican que sólo el 37% de los proyectos son exitosos, del resto el 
45% de los proyectos son cambiados y el 18% de los proyectos fallan y/o son cancelados 
completamente. 
En esta tesis se realizó una herramienta que cubre con 5 actividades esenciales para el 
aseguramiento de la calidad, tal que mediante el uso de la herramienta se promueven las 
actividades de calidad y se facilita implementación. 
Los resultados demuestran que la herramienta es flexible y se adapta a los entornos de 
desarrollo, ayudando a transmitir el estado de la ejecución de actividades relacionadas con la 
calidad y el resultado respecto a las verificaciones y validaciones del producto, de tal manera 
que puede mejorarse la prevención de defectos. 
Palabras clave: aseguramiento de la calidad, calidad del producto, actividades de 
aseguramiento de la calidad, producto de software, herramienta de calidad. 
	 
	
	
6	
Índice 
Introducción ........................................................................................................................................... 11 
Capítulo 1. Antecedentes .................................................................................................................... 13 
1.1. Marco teórico .............................................................................................................................. 13 
1.1.1. Calidad de software .............................................................................................................. 13 
1.1.2. Aseguramiento de la calidad ................................................................................................ 14 
1.1.3. Modelos y estándares de calidad de software ...................................................................... 14 
1.2 Planteamiento del problema ......................................................................................................... 23 
1.3. Objetivos ..................................................................................................................................... 24 
1.3.1. Objetivo General .................................................................................................................. 24 
1.3.2. Objetivos específicos ........................................................................................................... 24 
1.4. Hipótesis ..................................................................................................................................... 24 
1.5. Justificación ................................................................................................................................ 24 
Capítulo 2. Estado del arte .................................................................................................................. 26 
2.1. Revisión sistemática .................................................................................................................... 26 
2.1.1. Planificación de la revisión sistemática ............................................................................... 26 
2.1.2. Ejecución de la revisión sistemática .................................................................................... 27 
2.1.3.Reporte de resultados ........................................................................................................... 30 
2.2. Análisis de herramientas comerciales, estándares y modelos orientados a la calidad del 
producto ............................................................................................................................................. 51 
2.3. Selección de tecnología ............................................................................................................... 54 
2.3.1. Lenguaje de programación ................................................................................................... 54 
2.3.2. Frameworks de desarrollo Web ........................................................................................... 56 
2.4. Metodología de desarrollo .......................................................................................................... 57 
2.4.1. Comparación de metodologías ............................................................................................. 58 
Capítulo 3. Metodología para el desarrollo de la tesis ........................................................................ 59 
	
	
7	
3.1. Ejecución de la metodología para el desarrollo de Tesis ............................................................ 59 
Capítulo 4. Herramienta de soporte para el aseguramiento de la calidad del software ...................... 61 
4.1. Desarrollo de la propuesta .......................................................................................................... 61 
4.1.1. Diseño de la propuesta ......................................................................................................... 61 
4.1.2. Descripción de la fases ......................................................................................................... 62 
4.2. Desarrollo de la herramienta ....................................................................................................... 83 
4.2.1. Modelo de Requisitos .......................................................................................................... 83 
4.2.2. Modelo de Contenido ........................................................................................................... 84 
4.2.3. Modelo de Navegación ........................................................................................................ 86 
4.2.4. Elementos de metodología analizados para configuración de herramienta ......................... 87 
Capítulo 5. Resultados ........................................................................................................................ 93 
5.1. Herramienta para implementación de la propuesta ..................................................................... 93 
5.1.1. Interfaz de gestión de elementos .......................................................................................... 93 
5.1.2. Interfaz de gestión de métricas y criterios de producto de trabajo ....................................... 93 
5.1.3. Interfaz de evaluación de la configuración del proyecto ..................................................... 94 
5.1.4. Interfaz de evaluación de criterios de producto ................................................................... 95 
5.1.5. Interfaz de validación de criterios de aceptación ................................................................. 95 
5.1.6. Interfaz de revisión de resultados de medición .................................................................... 96 
5.1.7. Interfaz de acciones correctivas en resultados de medición ................................................ 97 
5.2. Estudio de caso ........................................................................................................................... 98 
5.2.1. Diseño y planificación de los estudios de caso .................................................................... 99 
5.2.2. Preparación de la recogida de datos ................................................................................... 100 
5.2.3. Recogida de datos .............................................................................................................. 101 
5.2.4. Análisis de los datos recogidos .......................................................................................... 102 
5.2.5. Reporte de resultados ......................................................................................................... 102 
Capítulo 6. Conclusiones .................................................................................................................. 112 
6.1. Conclusiones ............................................................................................................................. 112 
	
	
8	
6.2. Trabajo futuro ........................................................................................................................... 112 
6.3. Logros académicos .................................................................................................................... 113 
6.3.1. Productos académicos ........................................................................................................ 113 
Referencias ........................................................................................................................................... 114 
	
Índice de Figuras 
Figura 1 Correspondencia entre grupos de procesos y áreas de conocimiento en PMBOK (Project 
Management Institute 2013) .......................................................................................................... 20 
Figura 2 Gráfica de herramientas y frameworks identificados en la RSL ............................................. 32 
Figura 3 Modelos, Meta modelos, Metodologías y Enfoques identificados en la RSL ......................... 35 
Figura 4 Índice de puntuación TIOBE de lenguajes de programación .................................................. 55 
Figura 5 Metodología para el desarrollo de la tesis ............................................................................... 59 
Figura 6 Fase de inicio ........................................................................................................................... 66 
Figura 7 Fase de análisis ........................................................................................................................ 68 
Figura 8 Fase de evaluación de riesgos .................................................................................................. 70 
Figura 9 Fase de diseño .......................................................................................................................... 73 
Figura 10 Fase de desarrollo .................................................................................................................. 76 
Figura 11 Fase de pruebas ...................................................................................................................... 79 
Figura 12 Fase de liberación .................................................................................................................. 81 
Figura 13 Fase de cierre ......................................................................................................................... 83 
Figura 14 Diagrama de casos de uso ...................................................................................................... 84 
Figura 16 Diagrama de navegación de módulo de configuración ......................................................... 86 
Figura 17 Diagrama de navegación de módulo de seguimiento y control ............................................. 87 
Figura 18 Interfaz de gestión de productos de trabajo ........................................................................... 93 
Figura 19 Interfaz de gestión de métricas y criterios de aceptación de producto .................................. 94 
	
	
9	
Figura20 Interfaz de aprobación de la configuración incorrecta .......................................................... 94 
Figura 21 Interfaz de aprobación de la configuración correcta ............................................................. 95 
Figura 22 Interfaz de evaluación de criterios de aceptación de producto .............................................. 95 
Figura 23 Interfaz de validación de criterios de aceptación ................................................................... 96 
Figura 24 Interfaz de revisión de resultados de medición ..................................................................... 97 
Figura 25 Interfaz de acciones correctivas en resultados de medición .................................................. 98 
Figura 26 Pasos para implementar un estudio de caso .......................................................................... 98 
Figura 27 Experiencia de los encuestados ........................................................................................... 102 
Figura 28 Respuestas de la pregunta 1 del estudio de caso ................................................................ 103 
Figura 29 Respuestas de la pregunta 2 del estudio de caso ................................................................. 104 
Figura 30 Respuestas de la pregunta 3 del estudio de caso ................................................................. 104 
Figura 31 Respuestas de la pregunta 4 del estudio de caso ................................................................. 105 
Figura 32 Respuestas de la pregunta 5 del estudio de caso ................................................................. 106 
Figura 33 Respuestas de la pregunta 6 del estudio de caso ................................................................. 107 
Figura 34 Respuestas de la pregunta 7 del estudio de caso ................................................................. 108 
Figura 35 Respuestas de la pregunta 8 del estudio de caso ................................................................. 108 
Figura 36 Respuestas de la pregunta 9 del estudio de caso ................................................................. 109 
Figura 37 Respuestas de la pregunta 10 del estudio de caso ............................................................... 110 
Figura 38 Respuestas de la pregunta 11 del estudio de caso ............................................................... 111 
 
 
 
	
Índice de Tablas 
Tabla 1 Criterios de inclusión de RSL ................................................................................................... 27 
	
	
10	
Tabla 2 Criterios de exclusión de RSL .................................................................................................. 28 
Tabla 3 Resultados de selección de EP para S1 ..................................................................................... 29 
Tabla 4 Resultados de selección de EP para S2 ..................................................................................... 29 
Tabla 5 Estudios primarios seleccionados en la revisión sistemática de literatura ................................ 30 
Tabla 6 Análisis de Herramientas (H) y Frame works (F) identificados en RSL .................................. 32 
Tabla 7 Análisis de elementos de gestión de calidad en estudios primarios ......................................... 34 
Tabla 8 Análisis de estándares base para el aseguramiento de la calidad de software en los EPS ........ 35 
Tabla 9 Análisis de elementos propuestos: Modelo (M), Meta modelo (MM), Metodología (M) o 
Enfoque (E) en los EPS .................................................................................................................. 37 
Tabla 10 Análisis de problemática y solución en los estudios primarios .............................................. 42 
Tabla 11 Prácticas propuestas en estudios primarios ............................................................................. 44 
Tabla 12 Problemática abordada en los estudios primarios ................................................................... 46 
Tabla 13 Análisis de clasificación de defectos e incidencia .................................................................. 50 
Tabla 14 Distribución de errores en los estudios primarios ................................................................... 51 
Tabla 15 Análisis de modelos y estándares de calidad de software ...................................................... 52 
Tabla 16 Análisis de herramientas orientadas a la calidad del software ................................................ 53 
Tabla 17 Comparativa entre lenguajes de programación ....................................................................... 56 
Tabla 18 Comparativa entre frameworks ............................................................................................... 57 
Tabla 19 Comparativa de metodologías ................................................................................................ 58 
Tabla 20 Elementos de diseño de la propuesta ...................................................................................... 62 
Tabla 22 Empresas para estudio de caso ................................................................................................ 99 
Tabla 23 Preguntas de encuesta para estudio de caso .......................................................................... 101 
 
	
	
11	
Introducción 
El desarrollo de software juega un papel importante en la industria, al día de hoy, 4 de las 
5 empresas más capitalizadas en el entorno bursátil se dedican al desarrollo de software (R. 
Rebolledo, 2017). Al igual que el software ha incursionado en la industria, su desarrollo se ha 
vuelto cada vez más complejo e involucra la coordinación de diversos profesionales del 
software como: gerentes de calidad, líderes de proyecto, desarrolladores, arquitectos de 
software, analistas de software, etc., con ello, surgen retos y/o limitantes que deben ser 
gestionados durante el desarrollo del proyecto (Suali, Fauzi, Sobri, & Nasir, 2017). 
Con el auge de nuevas tendencias como el internet de las cosas (IoT) (Sandric & Jurcevic, 
2018), aplicaciones para móviles (Holl & Elberzhager, 2017), y las tecnologías para Big Data 
(Zhang, Zhou, Li, & Gao, 2017), las actividades para el aseguramiento de la calidad se ha 
convertido en una tarea compleja que requiere de conocimiento de expertos para lograr su 
implementación. Por lo que tareas como la verificación, la validación y el seguimiento y 
control de la calidad del software (Holl & Elberzhager, 2017; Zhang et al., 2017) se vuelven 
cada vez más comunes y vitales para el éxito en los proyectos de software. 
Sin embargo, reportes como el Chaos Report (The Standish Group International, 2016), 
indica que tomando en cuenta tiempo, presupuesto y objetivo, sólo el 37% de los proyectos 
son exitosos, mientras que en promedio 45% de los proyectos son cambiados en alguno o en 
varios de los tres aspectos, mientras que el 18% los proyectos fallan y/o son cancelados 
completamente. 
Debido a la importancia de las actividades relacionadas con la calidad en el éxito de los 
proyectos, este estudio presenta el desarrollo de una herramienta diseñada a partir de los 
resultados de una Revisión Sistemática de la Literatura (RSL), descrita en el Capítulo 2 
Estado del arte, el objetivo de la herramienta es dar soporte en el proceso de aseguramiento de 
la calidad del software, con el fin de guiar y facilitar la implementación de actividades para el 
aseguramiento de la calidad en las empresas. Esta herramienta pretende mejorar tanto la 
comunicación, como el seguimiento y control en actividades relacionadas con la gestión de la 
calidad en proyectos de desarrollo de software, involucrando a los gestores de proyectos y los 
miembros del equipo. 
La estructura de la tesis está compuesta por 6 capítulos, los cuales se detallan a 
continuación: 
Capítulo 1. Antecedentes,en este, se presenta el marco teórico que ayuda como línea base 
para una mejor comprensión de los términos utilizados a lo largo del estudio. 
	
	
12	
Capítulo 2. Estado del arte, en este, se describe la ejecución de una Revisión Sistemática 
de Literatura (RSL), que ayuda a analizar e interpretar estudios relevantes sobre el 
aseguramiento de la calidad de software, de igual manera en esta sección se presenta la 
selección de la tecnología para la implementación de la propuesta. 
Capítulo 3. Metodología para el desarrollo de la tesis, en este, se describen las tareas 
llevadas a cabo para el desarrollo de la tesis. 
Capítulo 4. Herramienta de soporte para aseguramiento de la calidad de software, en este, 
se presentan los elementos de diseño de la herramienta, así como las interfaces de la 
herramienta desarrollada. 
Capítulo 5. Resultados, en este, se presentan los resultados obtenidos de la herramienta a 
partir de la ejecución de un estudio de caso. 
Capítulo 6. Conclusiones, en este, se presentan las conclusiones generadas a partir del 
presente estudio. 
	
Capítulo 1. Antecedentes 
En este capítulo se presentan los antecedentes, comenzando con el marco teórico que 
contiene la definición de los conceptos fundamentales a partir de los cuales se desarrolla la 
presente investigación, posteriormente se presenta: el planteamiento del problema, los 
objetivos generales y específicos y la justificación.	
1.1. Marco teórico 
El objetivo del marco teórico es brindar un marco de referencia conceptual necesario 
para comprender la investigación, el marco teórico se integra a partir de teorías, enfoques 
teóricos, estudios y antecedentes en general, que se consideren válidos para la adecuada 
fundamentación del estudio (Hernández, Fernández, and Baptista 2014). A continuación se 
presentan los conceptos fundamentales directamente involucrados con el desarrollo de la 
presente investigación. 
1.1.1. Calidad de software 
Para un común entendimiento del concepto de calidad de software, en este apartado se 
proporcionan algunas definiciones. 
• La calidad es la idoneidad de uso. Es decir, las características del producto que 
satisfacen las necesidades del cliente y por lo tanto producen satisfacción de 
producto (Juran and Godfrey 1998). 
• La capacidad de un conjunto de características inherentes de un producto, o 
componente del producto, o proceso, de satisfacer por completo los requisitos del 
cliente (Software Engineering Institute 2010). 
• Nivel al que una serie de características inherentes satisfacen los requisitos (ISO 
9000:2005(es), Sistemas de gestión de la calidad — Fundamentos y vocabulario 
2005). 
• De acuerdo a Kan, la calidad puede definirse desde el punto de vista popular, 
como las propiedades intangibles que pueden ser discutidas, percibidas y 
juzgadas, pero no medidas o ponderada (Kan & H., 2003). 
• De igual manera, Crosby la define como “cumplimiento de los requisitos”, lo que 
implica que se debe tener conocimiento de los requisitos sin ambigüedades para 
que puedan ser completamente satisfechos (Kan & H., 2003). 
Con base en las definiciones anteriores, para esta tesis, calidad es el nivel en el que un 
producto de software cumple o no con los requisitos especificados y éste a su vez satisface las 
expectativas del cliente. 
	
	
14	
1.1.2. Aseguramiento de la calidad 
A continuación se proporcionan definiciones de aseguramiento de la calidad del 
software. 
• McGrath define el aseguramiento de la calidad del software como “conjunto de 
actividades que definen y evalúan la idoneidad de los procesos de software para 
proveer evidencia que establece confianza que el proceso de software es 
adecuado y produce software de calidad acorde a los fines y usos previstos” 
(McGrath et al., 2014). 
• En el modelo CMMI, se define el aseguramiento de la calidad de software como: 
“medio planificado y sistemático de asegurar a la gerencia que se aplican los 
estándares, prácticas, procedimientos y métodos definidos en el proceso” 
(Software Engineering Institute, 2010). 
Con base en las definiciones anteriores, para esta tesis, aseguramiento de calidad del 
software es el conjunto de prácticas que generan evidencia que permite evaluar que los 
procesos y productos de software cumplen con los estándares aplicables, y estos a su vez, son 
adecuados al tipo de producto de software que se desea obtener. 
1.1.3. Modelos y estándares de calidad de software 
Los modelos y estándares de calidad son una herramienta de apoyo para las empresas de 
desarrollo de software los cuales ayudan a mejorar la producción, competitividad y calidad de 
sus productos y procesos a nivel mundial. Estos modelos y estándares contienen un conjunto 
de buenas prácticas, las cuales son propuestas en conjuntos de procesos relacionados o en 
etapas específicas del ciclo de desarrollo de software para lograr la calidad desde un enfoque 
integral. Algunos de los principales modelos enfocados a la calidad del software son: CMMI-
DEV V 1.3 (Software Engineering Institute 2010) y MoProSoft (Oktaba et al. 1994). Por otra 
parte, algunos de los estándares enfocados a la calidad del software más importantes son: 
ISO/IEC 15504 (ISO 2006), ISO/IEC 29110 (IEEE/IEC 2016) e IEEE 730 (McGrath et al. 
2014). 
1.1.3.1. IEEE 730 
El estándar IEEE 730 (McGrath et al., 2014), es un estándar para el aseguramiento de 
calidad del software, en él se establecen los requisitos para iniciar, planificar, controlar y 
ejecutar el aseguramiento de la calidad dentro de un proyecto de desarrollo de software, este 
proceso está armonizado con el ciclo de vida del proceso propuesto en el estándar 
12207:2008 (McGrath et al., 2014). 
	
	
15	
1.1.3.1.1. Objetivo 
El objetivo de las actividades de este estándar, es permitir que un proyecto de software 
utilice un proceso de aseguramiento de calidad de software para generar y recolectar la 
evidencia que forme la línea base para proporcionar la confianza de que el software 
producido cumple con los requisitos establecidos. 
1.1.3.1.2. Estructura 
Este estándar contiene tres actividades principales, las cuales son: 
• Actividades de implementación de proceso, esta actividad está compuesta por 34 
tareas, su objetivo es establecer y definir un proceso de aseguramiento de la 
calidad documentado e independiente al proceso de desarrollo de los proyectos. 
• Actividades de aseguramiento de producto, esta actividad contiene 24 tareas, su 
objetivo es generar seguridad en la calidad de los productos de software 
generados y en la documentación asociada. 
• Actividades de aseguramiento de proceso, esta actividad contiene 24 tareas, tiene 
como objetivo especificar las actividades y tareas que ayudan a producir y validar 
que el producto es elaborado siguiendo un proceso establecido, gestionado, 
mantenido y aplicado. 
1.1.3.2. CMMI-DEV V1.3 
El CMMI-DEV V1.3 (Software Engineering Institute, 2010), es uno de los tres modelos 
contenidos en la familia de modelos conocido como CMMI, el cual está compuesto por tres 
modelos, el modelo CMMI para adquisición (CMMI-ACQ), el modelo CMMI para desarrollo 
(CMMI-DEV) y el modelo CMMI para servicios (CMMI-SVC), esta investigación se enfoca 
en CMMI-DEV, ya que está enfocado al desarrollo de productos de software. 
1.1.3.2.1. Objetivo 
El modelo CMMI-DEV V1.3, tiene como objetivo proveer una guía para la 
implementación de buenas prácticas en una organización de desarrollo de software. Estas 
buenas prácticas están orientadas a desarrollar productos y servicios que cumplan con las 
necesidades del cliente y los usuarios finales. El modelo CMMI-DEV V1.3 contiene prácticas 
que cubren: la gestión de proyectos, la gestión de procesos, la ingeniería de sistemas, la 
ingeniería de hardware, la ingeniería de software y otros procesos de soporte utilizados en el 
desarrollo y mantenimiento de software (Software Engineering Institute 2010). 
1.1.3.2.2. Estructura 
El modelo CMMI-DEV V1.3, está compuesto 22 áreas de proceso, lascuales se agrupan 
en 4 categorías que son: Gestión de procesos, Gestión de proyectos, Ingeniería y de Soporte. 
	
	
16	
Así mismo, CMMI-DEV V1.3 (Software Engineering Institute 2010) propone 4 niveles de 
capacidad de proceso los cuales son: 
• 0 incompleto: Un proceso incompleto es aquel que es implementado de manera 
parcial o no implementado, es decir cuando uno o más objetivos específicos no 
son cubiertos y no existen objetivos genéricos. 
• 1 realizado: Un proceso realizado es aquel que los objetivos específicos son 
satisfechos en su totalidad, sin embargo existen mejoras a realizar. 
• 2 gestionado: Un proceso gestionado es aquel que el proceso es planificado y 
ejecutado conforme a las políticas del modelo, utiliza las herramientas adecuadas 
para producir los productos de trabajo solicitados, intervienen los roles adecuados 
y su gestión es monitoreada. 
• 3 definido: Un proceso definido es aquel que un proceso gestionado y ajustado a 
los requisitos de la organización contribuye con experiencia para lograr los 
objetivos del proceso de la organización. 
 
Complementariamente el modelo propone 5 niveles de madurez, los cuales se describen a 
continuación. 
• 1 inicial: En este nivel, los procesos que usualmente son caóticos y no han sido 
estandarizados. El éxito del proyecto depende de las capacidades del personal y 
actos heroicos. 
• 2 gestionado: En este nivel, los proyectos son planificados y ejecutados de 
acuerdo a un plan establecido. 
• 3 definido: En este nivel, los procesos están bien identificados y entendidos, y 
estos son descritos con estándares, procedimientos, herramientas y métodos, por 
lo que los procesos son realizados siempre de la misma manera. 
• 4 gestionado cuantitativamente: En este nivel, los procesos tienen metas 
cuantitativas y estas son el indicador de éxito del proyecto. Los metas 
cuantitativas, son establecidas con base en los objetivos de la empresa. 
• 5 optimizado: En este nivel, la organización está en mejora continua basada en 
metas cuantitativas, y objetivos del negocio. 
 
1.1.3.2.3. Áreas de proceso relacionadas al aseguramiento 
de la calidad 
El modelo CMMI-DEV V1.3 (Software Engineering Institute 2010), contiene 4 áreas de 
proceso enfocadas al aseguramiento de la calidad del producto, las cuales son: Aseguramiento 
	
	
17	
de la calidad del proceso y del producto (PPQA), medición y análisis(MA), verificación 
(VER) y validación (VAL). Las cuales se describen a continuación. 
• Aseguramiento de la calidad del producto y proceso: esta área de proceso 
pertenece al nivel de madurez 2, su objetivo es proveer al personal y gerencia de 
una visión objetiva de los proceso y productos de trabajo asociados. Está 
conformada por 2 metas específicas, las cuales son: 
o Evaluar objetivamente los proceso y productos de trabajo. 
o Proporcionar una visión objetiva. 
• Verificación: esta área de proceso pertenece al nivel de madurez 3, su objetivo es 
asegurar que los productos de trabajo seleccionados cumplen con los requisitos 
especificados. Está conformada por 3 metas específicas las cuales son: 
o Preparar la verificación establecer el entorno de verificación. 
o Establecer los procedimientos. 
o Verificar los productos de trabajo seleccionados. 
• Validación: Esta área de proceso pertenece al nivel de madurez 3, su objetivo es 
demostrar que un producto o componente cumple con su uso previsto cuando se 
utiliza en el entorno adecuado. Está compuesta por 2 metas específicas las cuales 
son: 
o Preparar la validación. 
o Validar el producto o los componentes de producto. 
• Medición y análisis: Esta área de proceso pertenece al nivel de madurez 3, su 
objetivo es desarrollar y mantener la capacidad de medición utilizada para dar 
soporte a las necesidades de información de la gerencia. Está compuesta por 2 
metas específicas las cuales son: 
o Alinear las actividades de medición y análisis 
o Proporcionar los resultados de medición. 
1.1.3.3. ISO/IEC 15504 
El estándar ISO/IEC 15504 (ISO, 2006), también llamado Software Process Improvement 
Capability Determination (SPICE), es un estándar para la evaluación y mejora de procesos de 
software, el cual establece un marco de trabajo y un conjunto de requisitos para cualquier fase 
de evaluación de procesos. 
1.1.3.3.1. Objetivo 
El objetivo del estándar ISO/IEC 15504, es proveer un modelo de aseguramiento de 
proceso que ayude en la evaluación de la capacidad de procesos de software, la mejora de los 
procesos de software, el mantenimiento de sistemas informáticos y la elaboración de 
productos de software (ISO 2006). 
	
	
18	
1.1.3.3.2. Estructura 
El estándar ISO/IEC 15504 define 48 procesos en tres niveles organizacionales (ISO 
2006), los niveles organizacionales son: 
• Procesos de ciclo de vida primario.- Son el conjunto de procesos centrales para 
desarrollo de productos técnicos. 
• Procesos de ciclo de vida organizacional.- Son el conjunto de procesos a nivel 
organización para el soporte de proyectos. 
• Procesos de ciclo de vida de soporte.- Son el conjunto de procesos individuales 
para soporte a proyectos. 
 
De igual manera, el estándar ISO/IEC 15504 establece 6 niveles de madurez de la 
organización (ISO 2006), los cuales se detallan a continuación. 
• Nivel 0 proceso incompleto. En este nivel, los procesos no tienen entradas y 
salidas establecidas, y comúnmente, los objetivos del proceso no son alcanzados. 
• Nivel 1 proceso realizado. En este nivel, los objetivos del proceso generalmente 
son alcanzados, sin embargo, el proceso no es planificado y gestionado, tiene 
productos de entrada y salida claros y establecidos, y estos son evaluados para el 
logro del objetivo del proceso. 
• Nivel 2 proceso gestionado. En este nivel, se generan productos de trabajo 
conforme a las especificaciones del proceso, estos cumplen con una serie de 
requisitos y su elaboración está estandarizada, el proceso utilizado para su 
producción es planificado y gestionado. 
• Nivel 3 proceso establecido. En este nivel, se tiene un proceso establecido y 
gestionado mediante un proceso base que contiene buenas prácticas de ingeniería 
de software. El proceso es repetible, implementando estándares de proceso y 
documentos para lograr las salidas esperadas. 
• Nivel 4 proceso predecible. En este nivel, los procesos son llevados a cabo 
consistentemente con el proceso base utilizando límites para controlar y lograr los 
objetivos del proceso. 
• Nivel 5 proceso optimizado. En este nivel, el proceso es ajustado al entorno y 
necesidades de la empresa, el proceso es repetible, alcanzando los objetivos del 
negocio. 
1.1.3.3.3. Áreas de proceso relacionadas al aseguramiento 
de la calidad 
A continuación, se describen los procesos establecidos en el estándar ISO/IEC 15504 que 
están enfocados al aseguramiento de la calidad, los cuales son: 
	
	
19	
• Proceso de gestión de la calidad: este proceso pertenece al grupo de procesos 
organizacionales. Su objetivo es lograr la satisfacción del cliente monitoreando la 
calidad de los procesos y servicios de la organización por medio del 
conocimiento de los requisitos del cliente. 
• Proceso de medición: este proceso pertenece al grupo de procesos 
organizacionales. Su objetivo es recolectar y analizar datos respecto a la 
ejecución del proceso y el producto elaborado en la organización, para ayudar a 
una correcta gestión de los proyectos y demostrar objetivamente la calidad de los 
productos. 
• Proceso de aseguramiento de la calidad del software: este proceso pertenece al 
grupo de procesos de soporte. Su objetivo es asegurar que los productos de 
trabajo y procesos cumplen con los planes definidos. 
• Proceso de verificación del software: este proceso pertenece al grupo de procesos 
de soporte. Su objetivo es confirmar que cada producto de software o servicio de 
un proceso o proyecto refleja adecuadamente los requisitos especificados. 
• Proceso de validación del software: este proceso pertenece algrupo de proceso de 
soporte. Su objetivo es confirmar que los requisitos para un producto se cumplen 
completamente acorde a su uso. 
1.1.3.4. PMBOK 
La guía par la gestión de proyectos (PMBOK) (Project Management Institute, 2013), es 
un compendio de conocimiento que reúne métodos, procesos y buenas prácticas establecidas 
para una correcta gestión de proyectos, aplicables a la mayoría de los proyectos en la mayoría 
de las situaciones. 
1.1.3.4.1. Objetivo 
El objetivo del PMBOK es establecer un conjunto de buenas prácticas, así como un 
vocabulario común para el uso de conceptos relacionados a la dirección de proyectos de 
software (Project Management Institute 2013). 
1.1.3.4.2. Estructura 
El PMBOK establece 47 procesos agrupados en 5 grupos de procesos y 10 áreas de 
conocimiento. Un área de conocimiento, representa un conjunto completo de conceptos, 
términos y actividades que conforman un dominio profesional. En la Figura 1, se muestra la 
relación entre los procesos, áreas de conocimiento y grupos de proceso del PMBOK (Project 
Management Institute 2013). 
 
	
	
20	 
	
Fi
gu
ra
 1
 C
or
re
sp
on
de
nc
ia
 e
nt
re
 g
ru
po
s d
e 
pr
oc
es
os
 y
 á
re
as
 d
e 
co
no
ci
m
ie
nt
o 
en
 P
M
B
O
K
 (P
ro
je
ct
 M
an
ag
em
en
t I
ns
tit
ut
e 
20
13
). 
	
	
21	
1.1.3.4.3. Procesos relacionados al aseguramiento de la 
calidad 
El PMBOK contiene 4 áreas de conocimiento enfocadas en el aseguramiento de la calidad 
(Project Management Institute 2013), las cuales se describen a continuación. 
• Gestión de la calidad del proyecto: esta área de conocimiento tiene como objetivo 
asegurar que se alcancen y validen los requisitos del proyecto y producto. 
• Planificación de la gestión de la calidad: esta área de conocimiento tiene como 
objetivo identificar los requisitos de calidad y/o estándares aplicables al proyecto 
y a productos de trabajo, así como generar la documentación del proyecto para 
demostrar el cumplimiento con los requisitos de calidad relevantes. 
• Ejecución del aseguramiento de la calidad: esta área de conocimiento tiene por 
objetivo auditar la calidad de los requisitos y los resultados de las mediciones al 
control de la calidad, para asegurar que son correctamente seguidos los proceso 
definidos y los estándares aplicables. 
• Control de la calidad: esta área de conocimiento tiene por objetivo evaluar el 
desempeño y recomendar los cambios necesarios para mejorar los resultados 
obtenidos. 
1.1.3.5. MoProSoft 
MoProSoft es un modelo para la gestión de procesos de desarrollo de software, está 
dirigido al desarrollo y mantenimiento del software, y es aplicable a nivel de unidades 
operativas o toda la organización (Oktaba et al., 1994). 
1.1.3.5.1. Objetivo 
Está enfocado en apoyar a las organizaciones para definir procesos de acuerdo a sus 
necesidades, en el caso que ya se tengan establecidos, ayuda a identificar elementos faltantes 
o pobremente cubiertos y es necesario reforzar (Oktaba et al. 1994). 
1.1.3.5.2. Estructura 
El modelo MoProSoft establece 6 procesos principales, contenidos en 3 categorías de 
procesos (Oktaba et al. 1994), las cuales son: 
 
• Alta dirección (DIR). la cual contiene el siguiente proceso: 
o Proceso de gestión de negocio, su objetivo es establecer el motivo, los 
objetivos y los recursos de la organización. 
 
• Categoría de gestión (GES). la cual contiene los procesos de: 
	
	
22	
o Proceso de gestión de recursos, su objetivo es administrar y generar los 
recursos humanos y materiales dentro de la organización así como su 
ambiente de trabajo. 
o Proceso de gestión de procesos, su objetivo es establecer los procesos de 
la organización adecuados para esta. 
o Proceso de gestión de proyectos, su objetivo es evaluar que los proyectos 
contribuyen a los objetivos de la organización y estos están alineados a las 
estrategias establecidas. 
 
• Categoría de operación (OPE). la cual contiene los procesos de: 
o Proceso de administración de proyectos específicos, su objetivo es 
realizar las acciones necesarias para alcanzar los objetivos de tiempo y 
costo en los proyectos. 
o Proceso de desarrollo y mantenimiento de software, su objetivo es 
ejecutar actividades de análisis, diseño, construcción, integración y 
pruebas de productos de software nuevos o existentes. 
 
El modelo MoProSoft establece 5 niveles de capacidad (Oktaba et al. 1994), que ayudan a 
identificar el nivel de capacidad de implementación de los procesos establecidos, estos 
niveles se describen a continuación. 
• Realizado: En este nivel el proceso se implementa y alcanza su propósito. 
• Gestionado: En este nivel el proceso realizado, se administra y sus productos de 
trabajo están establecidos, controlados y mantenidos. 
• Establecido: En este nivel el proceso realizado y gestionado, se implementa por 
medio de un proceso definido. 
• Predecible: En este nivel el proceso establecido, opera bajo límites definidos y 
conocidos. 
• Optimizado: En este nivel el proceso predecible, es mejorado continuamente. 
1.1.3.5.3. Procesos relacionados al aseguramiento de la 
calidad 
A continuación, se presentan los procesos dentro del modelo MoProSoft que son 
enfocadas al aseguramiento de la calidad de producto de software. 
• Desarrollo y Mantenimiento de Software. Este proceso pertenece a la categoría 
de procesos de operación, su objetivo es la realización sistemática de actividades 
de análisis, diseño, construcción, pruebas e integración de productos de software, 
cumpliendo con los requisitos de software especificados. El proceso de desarrollo 
	
	
23	
y mantenimiento de software se compone de uno o más ciclos, en donde cada 
ciclo se compone de las siguientes fases: Inicio, Requerimientos, Análisis y 
diseño, Construcción, Integración y pruebas, y cierre. 
• Administración de proyectos específicos. Este proceso pertenece a la categoría de 
procesos operativos, su objetivo es administrar los proyectos internos y externos 
con base en los planes que se definieron para cada uno de ellos, y permitan 
cumplir con los objetivos de un proyecto en tiempo y costos esperados, o genera 
acciones correctivas si fuesen necesarias. El proceso de administración de 
proyectos específicos está compuesto de actividades de: 1) planificación; su 
objetivo es obtener es mantener el plan del proyecto y el plan de desarrollo que 
regirán al proyecto específico, 2) realización; su objetivo es llevar a cabo las 
actividades del plan del proyecto, 3) evaluación y control; su objetivo es asegurar 
que se cumplan los objetivos del proyecto, y 4) cierre; su objetivo es entregar los 
productos de acuerdo a un protocolo de entrega y dar por concluido el proyecto. 
 1.2 Planteamiento del problema 
El desarrollo de software juega un papel importante en la industria, tanto es así que, al día 
de hoy, 4 de las 5 empresas más capitalizadas en el entorno bursátil se dedican al desarrollo 
de software (R. Rebolledo, 2017). Al igual que el software ha incursionado en la industria, su 
desarrollo se ha vuelto cada vez más complejo e involucra la coordinación de diversos 
profesionales del software como: gerentes de calidad, líderes de proyecto, desarrolladores, 
arquitectos de software, analistas de software, etc., con ello, surgen retos y/o limitantes que 
deben ser gestionados durante el desarrollo del proyecto(Suali et al., 2017). 
Además, con el auge de nuevas tendencias como el internet de las cosas (IoT) (Sandric & 
Jurcevic, 2018), aplicaciones para móviles (Holl & Elberzhager, 2017), y las tecnologías para 
Big Data (Zhang et al., 2017), las actividades para el aseguramiento de la calidad se ha 
convertido en una tarea compleja que requiere de conocimiento de expertos para lograr su 
implementación. 
Sin embargo, reportes como The Chaos Report (The Standish Group International, 2016), 
indican que, tomando en cuenta aspectos clave del proyecto como: tiempo, presupuesto y 
objetivo, sólo el 37% de los proyectos son exitosos,mientras que en promedio el 45% de los 
proyectos son cambiados en uno o más de estos tres aspectos, y el 18% los proyectos fallan 
y/o son cancelados completamente. 
En este contexto, tareas como verificación, validación y seguimiento y control de las 
actividades relacionadas con la calidad del software (Holl & Elberzhager, 2017; Zhang et al., 
2017) se vuelven cada vez más críticas para el éxito en los proyectos de software, sin 
	
	
24	
embargo estas no son realizadas por falta de soporte para su implementación, que es el 
objetivo de esta tesis. 
1.3. Objetivos 
1.3.1. Objetivo General 
Diseñar y desarrollar una herramienta que dé soporte a los responsables de desarrollo y 
de calidad del software en la realización de actividades para el aseguramiento de la calidad. 
1.3.2. Objetivos específicos 
I. Definir el estado del arte en el área de calidad de software. 
II. Establecer una clasificación e incidencia de defectos. 
III. Realizar un análisis de herramientas, estándares y modelos orientados a la calidad de 
productos de software así como sus elementos propuestos. 
IV. Elaborar una propuesta de la herramienta de soporte para el aseguramiento de la 
calidad de software. 
V. Diseñar la herramienta que integre la solución propuesta. 
VI. Desarrollar la herramienta. 
VII. Realizar un estudio de caso implementando la herramienta desarrollada. 
1.4. Hipótesis 
La implementación de una herramienta de soporte al proceso de aseguramiento de la 
calidad en los productos de software incrementará la realización de actividades para el 
aseguramiento de la calidad a llevar a cabo por los equipos de desarrollo de software. 
1.5. Justificación 
Actualmente existen diversos estándares, modelos y herramientas enfocadas a la calidad 
del software, los cuales contienen prácticas y elementos para el aseguramiento de la calidad, 
como se puede ver en la sección 1.1.3. Sin embargo, un factor que impacta la integración de 
dichos modelos, estándares y herramientas es la cultura organizacional y personal, ya que 
para llevar a la implementación estos elementos se requiere de disposición a los tres niveles 
de la organización (operativo, mandos intermedios y gerencia), comúnmente, las personas no 
realizan prácticas que les cuesta trabajo entender o les consume mucho tiempo implementar, 
de igual manera las organizaciones no implementan prácticas cuyo retorno de inversión (ROI) 
no sea visible o cuantificable a corto o mediano plazo. De acuerdo a los resultados arrojados 
	
	
25	
por The Chaos Report 2016 (The Standish Group International, 2016), no se ha presentado 
una mejora en los resultados de los proyectos de los últimos 5 años, como se mencionó 
anteriormente, en promedio el 18% de los proyectos fallan y 45% son cambiados. 
	 
	
	
26	
Capítulo 2. Estado del arte 
En este capítulo se presentan los resultados de la ejecución de la Revisión Sistemática de 
la Literatura (RSL), cuyo objetivo es obtener el estado del arte respecto al aseguramiento de 
la calidad de software, enfocado en identificar tres elementos principales: 1) herramientas 
para la gestión de la calidad, 2) prácticas para el aseguramiento de la calidad y 3) defectos 
más comunes en en el desarrollo del software. Este capítulo incluye también un análisis a los 
principales modelos de calidad y herramientas comerciales para el aseguramiento de la 
calidad, la selección de tecnología y la selección de la metodología para el desarrollo de la 
herramienta. 
2.1. Revisión sistemática 
La revisión sistemática de la literatura (Systematic Literature Review, por sus siglas en 
inglés SLR) es un método que permite identificar, evaluar e interpretar toda la evidencia 
disponible relevante a un tema o pregunta de investigación (Budgen and Pearl Brereton 
2006). La SLR reduce la posibilidad de sesgo en las búsquedas de estudios, ya que es 
necesario definir un protocolo que especifica los métodos utilizados para guiar la revisión 
sistemática (Selleri Silva et al., 2015). 
La revisión sistemática se constituye de tres fases principales: planificación de la 
revisión, ejecución de la revisión, y reporte de resultados. A continuación se detallan las 
actividades realizadas en cada fase. 
2.1.1. Planificación de la revisión sistemática 
La planificación es la primera fase de la revisión sistemática, comprende las siguientes 
actividades: confirmar la necesidad de la revisión, especificar las preguntas de investigación, 
enumerar las fuentes de datos para realizar las búsquedas y, formular las cadenas de 
búsqueda. 
2.1.1.1. Identificación de la necesidad de la revisión 
Para una mayor calidad en la propuesta, se requiere identificar y estructurar el 
conocimiento generado a la fecha con respecto a la calidad del producto de software, con el 
fin de generar un panorama general que ayude a la identificación de herramientas, prácticas y 
defectos desarrollados en esta área. 
2.1.1.2. Preguntas de investigación 
Para conocer el estado del arte se establecieron tres preguntas de investigación, las cuales 
son: 
	
	
27	
RQ1. ¿Qué herramientas se utilizan para la gestión de la calidad en el desarrollo de 
software? 
RQ2. ¿Qué prácticas se implementan para el aseguramiento de la calidad del producto? 
RQ3. ¿Cuáles son los defectos más comunes en los productos de software? 
2.1.1.3. Cadenas de búsqueda 
A partir de las preguntas de investigación, se establecieron las siguientes palabras clave 
que se generaron en el idioma inglés para efecto de obtener un conjunto de artículos más 
amplio: software, quality, product, model, quality assurance, quality management, 
development, defects. Cabe destacar que los modelos (MoProSoft, CMMI-DEV V1.3) y 
estándares (IEEE 730, ISO/IEC 15502), se omitieron de las cadenas de búsqueda dado que se 
tomaron como línea base los estándares y modelos investigados en el Capítulo 1. A partir de 
esas palabras clave, se construyeron las siguientes cadenas de búsqueda: 
S1. Software AND (quality AND (assurance OR management)) AND (development AND 
(tools OR practices)) 
S2. Software product AND development AND defects 
2.1.1.4. Fuentes de datos 
Para la presente investigación se seleccionaron cuatro de las fuentes de datos más 
importantes en el área, siendo las siguientes: ACM, Elsevier, Springer y Web of science. 
2.1.2. Ejecución de la revisión sistemática 
La segunda fase de la revisión sistemática es la ejecución de la revisión, en la cual se 
definen los criterios de inclusión y exclusión para seleccionar los estudios primarios, se 
muestra el proceso de selección de estudios primarios y el número de estudios obtenidos en 
cada paso del proceso, y por último, se muestra la plantilla para extracción de datos de los 
estudios primarios. 
2.1.2.1. Criterios de inclusión y exclusión 
A continuación, en la Tabla 1, se listan los criterios de inclusión utilizados para el 
filtrado de los resultados, de igual manera en la Tabla 2, se listan los criterios de exclusión. 
Tabla 1 Criterios de inclusión de RSL 
ID Criterios de Inclusión 
CI1 Todos aquellos artículos que su fecha de publicación sea igual o mayor al año 2010 y menor 
o igual al 2016. 
	
	
28	
CI2 Todos los artículos que estén escritos en el idioma inglés o español. 
CI3 Todos los artículos que pertenezcan al área de ciencias computacionales, o disciplina de 
ingeniería de software o desarrollo de software 
CI4 Todos aquellos artículos que en su título contenga alguna de las palabras clave “quality” ó 
“software”. 
CI5 Todos los artículos que por el título sea enfocado a la implementación o análisis de un 
herramienta, o práctica para la mejora de la calidad del producto de software 
CI6 Todos aquellos artículos que aporten información respecto al estado actual de prácticas o 
actividades para la mejora de la calidad del software. 
CI7 Se incluirán los artículos que contengan información sobre alguna clasificación, tipificación 
o índice de defectos. 
	
	
Tabla 2 Criterios de exclusión de RSL 
ID Criteriosde exclusión 
CE1 Todos aquellos artículos que en su título o abstract no contengan al menos dos de las 
palabras clave identificadas para la búsqueda. 
CE2 Todos aquellos artículos que su fecha de publicación sea menor al año 2010. 
CE3 Todos aquellos artículos que están en algún idioma diferente al inglés y español. 
CE4 Todos los artículos que no pertenezcan al área de ciencias computacionales o ingeniería de 
software. 
CE5 Se excluirán los artículos que se encuentren duplicados o por su contenido sea similar a 
algún otro artículo seleccionado. 
CE6 Se excluirán los artículos que por alguna cuestión económica, legal o de cualquier índole 
estén fuera del límite de acceso de la institución o estudiante. 
	
	
29	
2.1.2.2. Selección de estudios primarios 
La selección de estudios primarios se realizó en ocho pasos, los cuales se describen a 
continuación:		
Paso 1. Se introduce la cadena de búsqueda y se realiza la consulta en las respectivas 
bases de datos. 
Paso 2. Se aplica el criterio de inclusión CI1. 
Paso 3. Se aplica el criterio CI2. 
Paso 4. Se aplica criterio de inclusión CI3. 
Paso 5. Se aplica criterio de inclusión CI4. 
Paso 6. Se aplican los criterios de inclusión C5. 
Paso 7. Se verifica que cumplan con al menos uno de los criterios de inclusión CI7, 
CI8 o CI9. 
Paso 8. Se aplican los criterios de exclusión. 
Los resultados obtenidos en cada paso para la S1 se muestran en la Tabla 3.		 	
Tabla 3 Resultados de selección de EP para S1 
ACM Springer Web of science Elsevier science Pasos 
6,790 234,004 1,782 163,852 Paso 1 
2,959 113,888 913 74,463 Paso 2 (CI1) 
2,959 113,229 913 74,463 Paso 3(CI2) 
2,959 10,113 229 937 Paso 4(CI3) 
271 3 55 112 Paso 5(CI4) 
13 3 4 5 Paso 6(CI5 ó CI6 ‘o CI7) 
12 3 4 5 Paso 7(CE) 
	
Los resultados obtenidos en cada paso para la S2 se muestran en la Tabla 4. 
Tabla 4 Resultados de selección de EP para S2 
ACM Springer Web of science 
Elsevier 
science Pasos 
501 48,455 432 57,657 Paso 1 
	
	
30	
240 23,768 204 26,054 Paso 2 (CI1) 
240 23,704 204 26,054 Paso 3(CI2) 
240 1,323 105 191 Paso 4(CI3) 
16 0 84 45 Paso 5(CI4) 
1 0 4 0 Paso 6(CI5 ó CI6 ‘o CI7) 
1 0 4 0 Paso 7(CE) 
 
Como resultado, se obtuvieron un total de 29 Estudios Primarios (EPS) para la Revisión 
Sistemática de la Literatura (RSL). 
2.1.2.3. Extracción de datos 
Antes de realizar la extracción de la información, los 29 EPS fueron organizados por 
medio de la herramienta de gestión de archivos PDF Mendeley®. Además, se realizó la 
lectura e identificación de la problemática y la solución propuesta en el estudio. 
Posteriormente con el apoyo de la herramienta Google Spreadsheets® se diseñó un formato 
para la extracción de la información con las siguientes columnas: problemática, solución, 
biblioteca digital, título, autores, año, entorno, clasificación, objetivo, tipo de elemento 
propuesto (si aplica), categoría de defectos (si aplica) e índice de defectos (si aplica). 
2.1.3. Reporte de resultados 
La Tabla 5 muestra el listado de los EP seleccionados para la RSL. 
Tabla 5 Estudios primarios seleccionados en la revisión sistemática de literatura 
ID Nombre 
EP1 Teamscale: Software Quality Control in Real-Time 
EP2 Refinement of the Test Bed Using Various Prioritization Techniques for Assuring 
Software-Quality 
EP3 Quality Assurance through Rigorous Software Specification and Testing: A Case Study 
EP4 Quality Assurance Strategy for Distributed Software Development using Managed Test Lab 
Model 
EP5 Development of a Multi-Agent Framework for Software Quality 
EP6 Increasing quality and managing complexity in neuroinformatics software development 
with continuous integration 
EP7 CIP-UQIM: A unified model for quality improvement in software SME’s based on CMMI 
level 2 and 3 
	
	
31	
EP8 Integrating Quality Models and Static Analysis for Comprehensive Quality Assessment 
EP9 A Software Quality Model for SOA 
EP10 Continual Monitoring of Code Quality 
EP11 SCQAM: A Scalable Structured Method for Industrial Code Quality Assessment Software 
EP12 Using Software Quality Standards to Assure the Quality of the Mobile Software Product 
EP13 A Concept of Quality Assurance for Metrics in CASE-Tools 
EP14 Introduction of static quality analysis in small- and medium-sized software enterprises: 
experiences from technology transfer 
EP15 A fuzzy classifier approach to estimating software quality 
EP16 Software quality assessment using a multi-strategy classifier 
EP17 A Generic Model-Based Methodology of Testing Techniques to Obtain High Quality 
Software 
EP18 An empirical study of the impact of modern code review practices on software quality 
EP19 Software quality improvement: a model based on managing factors impacting software 
quality 
EP20 An Application of Data Envelopment Analysis to Software Quality Assessment 
EP21 Software quality construction in 11 companies: an empirical study using the grounded 
theory 
EP22 Software automated testing: A solution to maximize the test plan coverage and to increase 
software reliability and quality in use 
EP23 The 3C Approach for Agile Quality Assurance 
EP24 Case-Based Reasoning vs Parametric Models for Software Quality Optimization 
EP25 Identifying Effective Software Metrics for Categorical Defect Prediction Using Structural 
Equation Modeling 
EP26 Identifying the Impact of Defects among the Defect Types in Software Development 
Projects 
EP27 Investigating the Temporal Behavior of Defect Detection in Software Inspection and 
Inspection-Based Testing 
EP28 Evaluation of Work Product Defects during Corrective & Enhancive Software Evolution: A 
Field Study Comparison 
	
	
32	
EP29 Comprehension of Defect Pattern at Code Construction Phase during Software 
Development Process 
 
2.1.3.1. Pregunta de investigación 1 (RQ1) 
RQ1. ¿Qué herramientas se utilizan para la gestión de la calidad en el desarrollo de 
software? 
En la Figura 2, se muestra el total de resultados obtenidos respecto a herramientas de 
software y frameworks identificados en los EP. 
	
Figura 2 Gráfica de herramientas y frameworks identificados en la RSL 
Como se puede observar en la gráfica anterior, se encontraron en una razón 2:1 
frameworks, con base en estos datos se puede identificar un área de oportunidad en la 
elaboración de herramientas para dar soporte a las prácticas propuestas en los frameworks. A 
continuación, en la Tabla 6, se muestra el tipo de elemento y nombre o descripción de la 
propuesta en los EP enfocado en la gestión de la calidad. 
Tabla 6 Análisis de Herramientas (H) y Frameworks (F) identificados en RSL 
Tip
o 
Nombre Descripción 
H Teamscale Herramienta para integración continua. 
H Herramienta de detección de fallos 
Herramienta para la optimización de pruebas, enfocada en 
incrementar la cobertura de pruebas y reducir el costo. 
F 
Sincronización de método de 
pruebas y especificación de 
software 
Sincronización de herramientas para la optimización de 
pruebas estáticas basadas en el uso de cadenas de Markov y 
especificación de software basada en secuencias. 
F Framework MTLM Herramienta para facilitar prácticas de prueba en el ciclo de vida del software, asignación de responsabilidades y 
	
	
33	
formalización de procesos de validación. 
F 
Framework multi-agente para 
selección de herramientas de 
prueba 
Integración de herramientas de pruebas unitarias y 
funcionales automatizadas. 
F Framework para integración continua 
Framework basado en prácticas de integración continua 
 
A continuación, se presenta un resumen de los estudios primarios seleccionados en la 
RSL correspondientes a la RQ1. 
En (Heinemann, Hummel, & Steidl, 2014), se propone una herramienta para realizar 
análisis de calidad por medio de pruebas dinámicas de integración de código utilizando un 
control de versiones, mediante la ejecución automática de una serie de pruebas por cada 
commit ejecutado. 
En (Jain & Gupta, 2011), se propone una herramienta para generar conjuntosde pruebas 
que satisfagan criterios de salida particulares, a partir del conjunto de pruebas se identifican 
debilidades y fortalezas de los conjuntos de pruebas. 
En (Lin, He, Zhang, & Song, 2015), se propone un framework enfocado en la creación 
de un entorno que contenga un conjunto de herramientas por medio de un plan en el que se 
detalla las métricas y requisitos relevantes. 
En (Mathrani, 2014), se propone un framework enfocado al análisis dinámico de 
sistemas distribuidos, en donde los equipos de desarrollo realizan pruebas dinámicas al 
código para identificar y resolver errores de código, facilitando la trazabilidad entre piezas de 
software y cambios realizados. 
En (Öztürk, CİL, & Zengin, 2015), se propone un framework para facilitar el proceso de 
selección de herramientas para pruebas de código mediante una ontología de errores y 
herramientas ad-hoc para resolver determinados errores, proporcionado un conjunto base de 
herramientas para análisis dinámico de código. 
En (Zaytsev & Morrison, 2013), se propone un framework para la integración continua 
del código mediante el control de versiones y un software para pruebas de integración 
automática de código. 
Como se puede observar, la categoría más atendida es la ejecución de pruebas dinámicas 
abordada en: (Heinemann et al., 2014), (Jain & Gupta, 2011), (Lin et al., 2015) y (Mathrani, 
2014). Mientras que en (Öztürk et al., 2015) se presenta un análisis en la selección de 
herramientas ad-hoc para la gestión de la calidad, por otra parte en (Zaytsev & Morrison, 
2013) se aborda la integración continua de los componentes de software. 
 
Para evaluar el nivel de gestión cubierto por cada herramienta o framework, se toma 
como base una serie de elementos básicos para la gestión de la calidad propuestos en (Beltr & 
Le, 2011), los elementos son: 
	
	
34	
 • Garantía de calidad, grado de relación que tiene el producto para satisfacer las 
necesidades del usuario, es decir, que se cubran los requisitos y procesos del cliente 
correctamente. 
• Planificación de la calidad, que es satisfecha cuando un elemento permite elaborar en 
las fases iniciales del proyecto un plan de calidad, que detalle cómo se va a evaluar, valorar y 
establecer metas de calidad del software. 
• Control de la calidad, supervisión del estado de la calidad y la toma de acciones 
correctivas para mantener los índices de calidad deseados y la conformidad con el proceso sea 
de manera correcta. 
A continuación, en la Tabla 7, se realiza un análisis para identificar la cobertura de los 
elementos para la gestión de la calidad en los EPS. 
Tabla 7 Análisis de elementos de gestión de calidad en estudios primarios 
ID Garantía Planificación Control 
EP1 Permite ver el historial de 
las modificaciones y evaluar 
el cumplimiento de los 
componentes. 
- Permite supervisar y controlar 
métricas cómo: detección de 
código, tamaño de archivo, 
longitud de métodos, 
complejidad ciclomática, etc. 
EP2 - - Permite detección de errores 
por medio de la ejecución de 
pruebas dinámicas. 
EP3 El método de especificación 
y pruebas estadísticas del 
software, permite la gestión 
de los requisitos de usuario 
y su estado actual. 
Establece límites y elementos 
que deben ser desarrollados 
dentro del proyecto, así como 
responsables de actividades, de 
igual manera, permite la 
especificación de pruebas e 
inclusión de métricas. 
Permite la asignación y 
seguimiento de métricas de 
código como indicadores de 
calidad. 
EP4 - Permite la generación de una 
matriz de responsabilidades 
para identificar recursos como 
técnicas, responsables, 
herramientas, etc. 
Integra herramientas externas 
(como Jira, Seapine y 
AdventNet) para la 
identificación del índice de 
defectos. 
EP5 - Permite la generación de un 
script de pruebas, que será 
ejecutado en las diferentes 
herramientas integradas 
(Selenium IDE, Vega 
Subgraph y SqlQueryStress). 
Identifica métricas como: 
índice de defectos, cobertura 
de pruebas, mediante la 
integración de herramientas 
como Selenium IDE 
	
	
35	
 
 
Como podemos observar, la mayoría de las propuestas controlan la calidad del software 
mediante la integración de métricas, y el seguimiento de los requisitos del software es 
abordado en el 33% de las propuestas y de ellas solo una (EP3) realiza identificación y 
seguimiento completo de los requisitos, mientras que una propuesta solo permite establecer el 
requisito que fue abordado en el código modificado. 
 2.1.3.2. Pregunta de investigación 2 (RQ2) 
RQ2. ¿Qué prácticas se implementan para el aseguramiento de la calidad del 
producto? 
A partir del análisis realizado a los estudios primarios (EPS), se encontraron un conjunto 
de modelos, meta-modelos, metodologías y enfoques orientados a proporcionar prácticas para 
el aseguramiento de la calidad. Como se observa en la Figura 3, en los EPS se identificaron 3 
modelos, 1 meta modelo, 7 metodologías y 7 enfoques. 
	
Figura 3 Modelos, Meta modelos, Metodologías y Enfoques identificados en la RSL 
En la Tabla 8, se muestra una síntesis de los estándares que son implementados directa o 
indirectamente en las propuestas de EPS. 
Tabla 8 Análisis de estándares base para el aseguramiento de la calidad de software en los 
EPS 
EP6 - Realiza integración continua y 
pruebas automáticas mediante 
un script de pruebas. 
Integra métricas en la fase de 
integración de código para 
conocer la salud del proyecto. 
ID Nombre Tipo Modelo o Cómo es implementado (actividades, estrategias) 
	
	
36	
Estándar 
base 
EP7 SPI CIP-
UQIM 
M ISO/IEC 
9001, 
PMBOK 
y CMMI-
DEV 
Se integran actividades de los procesos CMMI-DEV, 
PMBOK e ISO/IEC 9001 para ser armonizados en un 
entorno multimodelo. 
⁠EP8 Modelo de 
reglas para 
análisis 
estático de 
código 
M ISO/IEC 
25010 
Se toman los atributos de calidad propuestos en el 
estándar. 
Se adoptan las estrategias propuestas en el modelo 
para identificar entidades, relaciones y atributos. 
EP9 Arquitectura 
Orientada a 
Servicios 
(SOA) 
MM ISO/IEC 
25010 
Integra prácticas o actividades del estándar para 
identificar elementos y relaciones dentro del sistema. 
⁠EP10 Método de 
monitoreo 
continuo de 
calidad 
(CQMM) 
MT ISO/IEC 
9126 
Utiliza actividades enfocadas a la identificación de 
entidades y atributos para la gestión de la calidad. 
Implementa prácticas para la gestión de atributos de 
calidad. 
EP11 Método de 
evaluación de 
calidad de 
código 
estructurado 
(SCQAM) 
MT ISO/IEC 
14598 
Toma pasos definidos por el estándar para establecer 
y ejecutar la evaluación y estos son optimizados para 
reducir el tiempo que consume. 
EP12 Aseguramient
o de la calidad 
en productos 
de software 
para móviles 
MT ISO/IEC 
9126 
Se toman prácticas para identificar características y 
métricas de calidad externas, internas y centradas en 
el usuario. 
 
EP13 Métricas en 
herramientas 
CASE 
E ISO/IEC 
9000 
Se implementan prácticas para priorizar y métricas 
propuestas por el estándar. 
EP14 Análisis 
estático 
automático 
(ASA) en 
PyMES 
E ISO/IEC 
25010 
Implementa prácticas para categorizar la calidad del 
producto dentro de características y definir entidades 
y sus relaciones. 
	
	
37	
Como podemos observar en la tabla anterior, los estándares identificados son 
principalmente 4, los cuales, se implementan de la manera siguiente: el estándar ISO/IEC 
9001 se utiliza para identificar atributos de calidad relevantes en el control de la calidad, el 
estándar ISO/IEC 9126 se utiliza para identificar subcaracterísticas de calidad y sus métricas 
asociadas, mientras que el estándar ISO/IEC 25010 se utiliza para establecer elementos con 
alto impacto en la calidad y finalmente el estándar ISO/IEC 14598 se utiliza para sustraer una 
línea base de actividades para la revisión de la calidad. 
En la Tabla 9, se muestra el nombre y descripción del elemento para el aseguramiento de 
la calidad propuesto en los EPS relacionados a las prácticas para el aseguramiento de lacalidad. 
Tabla 9 Análisis de elementos propuestos: Modelo (M), Meta modelo (MM), Metodología 
(M) o Enfoque (E) en los EPS 
ID Tipo Nombre Descripción 
Modelo 
EP7 M CIP-UQIM Se propone un modelo que integra a nivel de actividades 
los modelos de calidad más populares. 
EP8 M Modelo de reglas para 
análisis estático de 
código 
Se propone un modelo de calidad que permite definir 
cómo integrar métricas obtenidas mediante herramientas 
de análisis automático y evaluación de expertos. 
EP16 M RB2CBL Se propone un modelo de clasificación que integra un 
modelo basado en reglas y dos modelos de aprendizaje 
basado en casos, y un algoritmo optimizador para la 
evaluación de la calidad. 
Meta-modelo 
EP9 MM SOA Se propone un metamodelo para la clasificación de 
calidad que integra dos modelos de aprendizaje basado 
en casos y un modelo basado en reglas, para 
complementarse de manera mutua. 
Metodología 
EP10 MT CQMM Se propone una metodología que integra herramientas 
de análisis estático de código y el monitoreo utilizando 
modelos de calidad. 
EP11 MT SCQAM Se propone un método de análisis en el que se realiza 
aseguramiento de calidad realizado por expertos y 
dirigido por la aplicación sistemática de herramientas de 
	
	
38	
análisis de código. 
EP12 MT Aseguramiento de la 
calidad en productos 
de software para 
móviles. 
Se propone la implementación de una estrategia para 
extender los estándares de calidad de software y proveer 
mecanismos para la medición de la calidad del software 
para móviles desde el punto de vista de los 
desarrolladores y usuarios. 
EP17 MT Técnicas de pruebas de 
código. 
Se propone una metodología con las categorías de 
pruebas mayormente aceptadas para evaluar aspectos 
como funcionalidad, estructura, confiabilidad, 
requerimientos de usabilidad y consistencia. 
EP18 MT Prácticas de revisión 
de código para 
aseguramiento de la 
calidad. 
Se propone una metodología para evaluar la relación 
entre los defectos posteriores a la liberación y prácticas 
de revisión, como: cobertura de revisiones de código, 
participación en revisiones de código y experiencia en 
revisiones de código. 
EP19 MT Gestión de elementos 
relevantes o de alto 
impacto para la 
calidad. 
Se propone una metodología que utiliza cadenas de 
Markov y un framework sistemático para modelar 
procesos de gestión de la calidad estocásticos y la 
selección de elementos que impactan en la calidad del 
software. 
EP20 MT Data Envelope 
Analysis (DEA) para 
aseguramiento de la 
calidad. 
Se propone la implementación de DEA para asegurar la 
evolución de proyectos de software en términos de los 
valores de métricas seleccionadas en sucesivas versiones 
del proyecto. 
Enfoque 
EP13 E Métricas en 
herramientas CASE. 
Se presenta la inclusión de requisitos en herramientas 
CASE para definir modelos de calidad del producto 
flexibles. 
EP14 E Análisis estático 
automatizado en 
PyMES. 
Se presenta una evaluación de los resultados de análisis 
estático para proveer información sobre los problemas 
que surgen cuando se introducen y usan prácticas de 
análisis estático en PyMES. 
EP15 E Enfoque de 
clasificación difusa. 
Se presenta la implementación de una estrategia para 
determinar un conjunto de métricas de software 
utilizando enfoque de clasificación difusa. 
EP21 E Análisis de factores 
humanos en la calidad 
del software mediante 
teoría fundamentada. 
Se presenta una investigación en la construcción de la 
calidad de software en 11 compañías utilizando el 
método de investigación de teoría fundamentada. 
	
	
39	
EP22 E Implementación de 
pruebas automáticas 
de software. 
Se propone la integración de pruebas automáticas para 
incrementar la cobertura del plan de pruebas dentro del 
tiempo disponible para incrementar la confiabilidad y 
calidad en uso. 
EP23 E Implementación de 
prácticas para la 
integración, medición 
y mejora continua. 
Se propone un enfoque de integración de la práctica ágil 
de integración continua, junto a prácticas de medición 
continua y mejora continua para un aseguramiento ágil 
de la calidad. 
EP24 E Optimización basada 
en razonamiento 
basado en casos vs 
herramienta 
CEESAW. 
Se propone la integración de dos modelos mutuamente 
complementarios para la clasificación de elementos de 
calidad, utilizando una ontología con atributos de 
COCOMO. 
A continuación, se presenta una descripción de las propuestas de los estudios primarios 
mostrados en la Tabla 9. 
En (Rahmani, Sami, and Khalili 2016), se propone un modelo para la mejora de los 
procesos, este modelo es generado mediante técnicas de armonización de actividades de los 
modelos de calidad más populares como: CMMI-DEV V1.2, PMBOK 3 e ISO/IEC 
9001:2000. Estas actividades son integradas dentro del modelo CIP-UQIM, el cual demostró 
ofrecer ventajas en la resolución de problemas de implementación en entornos multi modelo. 
En (Lochmann and Heinemann 2011), se propone un modelo de reglas para realizar 
análisis estático de código, utilizando como línea base los atributos de calidad establecidos en 
el estándar ISO/IEC 25010, los cuales son asociados a entidades por medio de propiedades, 
de esta manera, se gestiona cuantitativamente promoviendo o inhibiendo atributos. 
En (Goeb and Lochmann 2011), se presenta un meta-modelo para gestionar la calidad en 
sistemas distribuidos realizando análisis estático de código, este meta-modelo está orientado a 
la arquitectura de software orientado a la arquitectura (SOA), contiene requisitos específicos 
que son de mayor demanda en los software como servicio (SaaS) de arquitectura distribuida. 
En este modelo se utilizan elementos como: entidad, atributo, factor, impacto entre otros, para 
el aseguramiento de la calidad. 
En (Kothapalli et al. 2011), se propone un método para el monitoreo de la calidad del 
código, mediante la revisión constante en la fase de desarrollo realizando análisis estático de 
código. Este método está basado en el Método de Evaluación para la Calidad Interna del 
Software (EMISQ) e ISO/IEC 9126, por lo que integra atributos y sub-atributos de calidad 
que son gestionados mediante un conjunto de entidades y atributos. El método CQMM 
propone una serie de 11 pasos divididos en 3 etapas. 
	
	
40	
En (Gupta et al. 2014), se propone una metodología para evaluar el impacto de elementos 
de código dentro del producto en general, de esta forma, se realiza una priorización de 
elementos, la metodología contiene atributos de calidad propuestos en EMISQ y está 
conformada por 11 pasos divididos en 3 fases: 1) la entrada, en la cual se realiza la 
integración de los elementos, 2) el proceso, en este se realiza el análisis de los elementos de 
código y 3) la salida, que es en la que se obtienen los resultados del análisis de impacto. 
En (Corral and Luis 2012), se propone una metodología para el aseguramiento de la 
calidad en el desarrollo de software para móviles. Se identificaron requisitos de calidad 
específicos dentro del dominio obtenidos como base a partir del estándar ISO/IEC 9126, 
asignando métricas de calidad y siguiendo regulaciones existentes como: regulaciones de 
mercado, restricciones en el hardware, requisitos de uso y dependencias internas y externas al 
producto. 
En (Yazbek and Hashem 2010), se propone un enfoque de integración de métricas en 
herramientas de Ingeniería de Software Asistida por Computadora (CASE) para el análisis de 
código, integrando análisis estático en las prácticas diarias del desarrollador y en el ciclo de 
desarrollo del software con el objetivo de mantener un control cuantitativo constante del 
software durante el proceso de producción. 
En (Gleirscher et al. 2014), se propone un análisis de actividades para el aseguramiento de 
la calidad mediante la integración de un análisis estático automático, con el objetivo de 
evaluar el esfuerzo requerido para su implementación contra los beneficios obtenidos respecto 
a la utilidad percibida, defectos encontrados y problemas técnicos