Embed Size (px)
Citation preview
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
Figura 20 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, las cuales 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 al grupo 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
gura
1 C
orre
spon
denc
ia e
ntre
gru
pos d
e pr
oces
os y
áre
as d
e co
noci
mie
nto
en P
MB
OK
(Pro
ject
Man
agem
ent I
nstit
ute
2013
).
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 Criterios de 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
Tipo
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 conjuntos de 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 Aseguramiento 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 la calidad.
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 identificados.
En (Pizzi 2013), se propone una estrategia de predicción de calidad mediante una clasificación difusa de métricas del proceso, obteniendo aquellas con mayor impacto en la calidad, de las cuales se analiza un conjunto de métricas que son automáticamente computadas y un conjunto de reglas de selección que deben ser definidos por un experto en el área.
En (Khoshgoftaar, Xiao, and Gao 2014), se presenta un modelo para la clasificación de módulos propensos a fallos mediante la implementación de 2 modelos; 1) el modelo basado en reglas (RB) y 2) el modelo de aprendizaje basado en casos (CBL), esto mediante un algoritmo optimizado de análisis se genera un árbol de decisiones para identificar módulos propensos a errores.
En (Almakadmeh, Abu-Zitoon, and Student 2015), se propone una metodología para reducir el número de defectos mediante la integración de herramientas ad hoc y el conocimiento de expertos para la gestión de métricas de calidad, de esta manera se pretende
41
reducir la cantidad de defectos. La metodología contiene 7 pasos para la selección de las herramientas y procedimientos a aplicar en las pruebas del producto.
En (McIntosh et al. 2016), se presenta la expansión de un estudio anterior de su auditoría, en el cual, se demuestra que prácticas formales de revisión de código ayudan a en el incremento de la calidad, en el estudio actual se incluye un conjunto de proyectos en donde se evalúa el impacto de las métricas de: cobertura de revisión de código, porción de cambios en el código, participación en las revisiones de código y experiencia del revisor. Por medio de la relación entre defectos identificados y las métricas propuestas se concluye que la calidad incrementa al realizar prácticas formales de revisión de código en comparación a los métodos ligeros de revisión de código.
En (Janicijevic et al. 2016), se propone una metodología de trabajo para la selección de métricas óptimas en la gestión de la calidad utilizando cadenas de Markov. Los resultados obtenidos muestran que la selección de métricas adecuadas pueden ayudar en la optimización de los procesos y recursos.
En (Paschalidou, Stiakakis, and Chatzigeorgiou 2013), se propone una metodología para la aplicación de análisis de envoltorio de datos o Data Envelopment Analysis (DEA), mediante la cual se analiza la calidad a través de las versiones lanzadas, estableciendo límites de eficiencia, la calidad de cada versión del software es evaluada mediante unidades de toma de decisiones (DMUs) que son las entidades mínimas para procesar información, de esta manera la eficiencia de cada DMU es evaluada mediante el análisis de las salidas de cada unidad y los recursos utilizados para producirla. La metodología pretende identificar las versiones del código que se encuentran fuera del límite de calidad e identificar las unidades que deben ser mejoradas.
En (Seth et al. 2015), se propone un análisis de factores que impactan la calidad, el análisis se realiza mediante la metodología de teoría fundamentada Straussiana o Grounded Theory (GT). Esta metodología establece 3 fases de análisis de datos: 1) codificación abierta, que consiste en la identificación y etiquetado de conceptos similares en los datos, 2) codificación axial, que es la categorización de conceptos similares e identificación de relaciones y 3) codificación selectiva, que consiste en la examinación del desarrollo de las categorías para definir una categoría principal que describa las categorías identificadas y establezca una hipótesis o teoría.
En (Catelani et al. 2011), se propone un enfoque para la ejecución de pruebas automáticas de software, la metodología propuesta consiste en la generación de casos de prueba de caja negra, en las cuales se tiene un conjunto de entradas y salidas claramente identificadas, los casos de prueba son elaborados bajo estas restricciones. El estudio demostró que mediante la
42
implementación del enfoque se disminuye considerablemente el número de errores en el software.
En (Janus et al. 2012), se propone un enfoque que integra prácticas ágiles de medición, integración y mejora continua (3C), mediante la selección y aplicación de herramientas de soporte y métricas de gestión. Cómo resultados al realizar seguimiento continuo de la calidad se obtuvo una mejora en la calidad final y se redujo el esfuerzo y recursos en la gestión de la calidad.
En (Brady and Menzies 2010), se propone una optimización en el proceso de desarrollo mediante la comparación entre los modelos de Razonamiento Basado en Casos (CBR) y la herramienta de modelado paramétrico SEESAW, seleccionando las prácticas que optimicen el proceso respecto a recursos y actividades a realizar. CBR demostró requerir menos esfuerzo y recursos obteniendo una mejor calidad, excepto en el caso en que no se cuente con datos históricos en donde SEESAW es más adecuada ya que no requiere datos históricos para su implementación.
A continuación, en la Tabla 10, se identifica la problemática atendida y una clasificación en los estudios primarios correspondientes a prácticas para el aseguramiento de la calidad.
Tabla 10 Análisis de problemática y solución en los estudios primarios
ID Problemática Solución Categoría
EP7 Dificultades para implementar entornos multimodelo.
Integrar modelos más populares para mejorar la calidad de software.
Optimización del proceso
EP8 Dificultad de llevar a la práctica atributos de calidad establecidas en los modelos de calidad.
Elaborar un meta modelo mediante prácticas de modelos de calidad y herramientas de análisis.
Análisis estático
EP9 Gestión de la calidad en los sistemas de software para servicios.
Proponer un meta modelo adecuado para la gestión de la calidad en sistemas de servicios.
Análisis estático
EP10 Gestión de la calidad interna.
Implementación de un método para la integración de actividades de gestión de calidad de software mediante análisis estático de código.
Análisis estático
EP11 Reducción del tiempo en el aseguramiento de la calidad.
Implementación de un método ligero para la ejecución de actividades enfocadas en el control de la calidad por medio de la identificación temprana de
Priorización de elementos
43
la calidad.
EP12 Restricciones en entorno de móviles para el desarrollo de software.
Estrategia para el aseguramiento de la calidad considerando restricciones de entorno, hardware y estándares de calidad.
Análisis estático
EP13 Poco conocimiento cuantitativo del estado de la calidad.
Integración de métricas en el desarrollo de software mediante herramientas CASE.
Análisis estático
EP14 Optimización de actividades para aseguramiento de calidad en PyMES.
Evaluación de técnicas para análisis automático de código.
Análisis estático
EP15 Optimización de métricas para el aseguramiento de la calidad.
Enfoques de calidad ajustados al contexto de la empresa mediante conocimiento de expertos.
Análisis estático
EP16 Integración de dos modelos complementarios para clasificación de módulos.
Modelo para clasificar módulos propensos a errores.
Identificación de defectos
EP17 Selección de técnicas de prueba de código adecuadas.
Metodología para ayudar en la selección de técnicas y herramientas de prueba de código.
Análisis dinámico
EP18 Mejora en la eficiencia de prácticas de revisión de código.
Análisis de métricas en revisiones formales de código en comparación a herramientas modernas de revisión de código.
Análisis estático
EP19 Optimización en el aseguramiento de la calidad.
Metodología para la selección de métricas óptimas para el aseguramiento de la calidad usando cadenas de Járkov.
Priorización de elementos
EP20 Fluctuación de la calidad a través de las versiones del software.
Metodología para evaluación de la calidad usado DEA.
Análisis estático
EP21 Identificación de factores que impactan la calidad de software.
Análisis de evidencia usando metodología de teoría fundamentada de Straussian.
Experiencia/habilidad
EP22 Correcta implementación de técnicas de verificación de software para el
Elaboración de una metodología para la creación de pruebas automáticas.
Análisis dinámico
44
aseguramiento de la calidad.
EP23 Mejora en el control y aseguramiento de la calidad interna del software.
Implementación de prácticas ágiles de medición, integración y mejora continua del software.
Análisis estático
EP24 Optimización de técnicas para el aseguramiento de calidad.
Evaluación entre modelos para la optimización de la calidad.
optimización del proceso
Como podemos observar en (Rahmani, Sami, and Khalili 2016) y (Khoshgoftaar, Xiao, and Gao 2014), propone entorno multimodelo, integrando dos o más modelos que son complementarios mutuamente, mientras que los meta-modelos propuestos en los EP cubren de manera abstracta atributos de calidad como se propone en (Goeb and Lochmann 2011), las metodologías identificadas están enfocadas en actividades para la selección de pruebas y métricas adecuadas para la calidad.
En la Tabla 11, se muestran las prácticas propuestas para el aseguramiento de la calidad en los EPS.
Tabla 11 Prácticas propuestas en estudios primarios
ID Prácticas de aseguramiento de calidad
EP7 Integrar actividades del modelo CMMI-DEV del área de proceso medición y análisis, práctica específica 2: proporcionar resultados de medición. Integrar objetivo específico 1 de CMMI-DEV proceso de medición y análisis.
EP8 Identificar elementos críticos para la calidad. Identificar y asignar métricas de calidad como atributos de los elementos de software identificados.
EP9 Establecer métricas de calidad para la gestión de la calidad.
EP10
Definir objetivos de calidad y modelo de calidad de acuerdo a los requisitos de proyecto. Analizar los resultados de la medición y realizar acciones correctivas. Establecer actividades para auditar el monitoreo de la calidad. Clasificar métricas o indicadores de calidad.
EP11
Producir un plan de evaluación que ayude al entendimiento del proceso de aseguramiento de la calidad. Establecer criterios para aseguramiento de calidad. Configurar herramientas de análisis automático de código.
45
EP12 Integrar atributos de calidad en los elementos clave de software.
EP13 Incorporar métricas para cubrir requisitos de calidad.
EP14 Ejecutar pruebas automáticas. Implementar análisis estático de código.
EP15 Seleccionar métricas mediante parámetros de configuración. Delimitar rango de valores aceptables para resultados de calidad.
EP16 Identificar errores probables en módulos de software.
EP17
Analizar naturaleza del software e iniciar proceso de prueba. Revisar el dominio de entradas y salidas del software para ajustar las herramientas. Analizar el flujo de control del software. Establecer el enfoque y criterios o métricas de calidad a evaluar.
EP18
Establecer responsables de revisión de código y scripts para la ejecución de pruebas automáticas. Incluir revisores responsables de criticar los cambios y proporcionar retroalimentación. Analizar defectos y cambios en el código por medio de variables.
EP19
Establecer de actividades de verificación. Priorizar requisitos respecto al cliente. Identificar los factores que impactan en el cumplimiento de los requisitos. Identificar conjunto de características del software relevantes para el cliente.
EP20 Establecer límites de calidad para cumplir niveles aceptables de calidad. Analizar cada versión liberada con respecto a los límites establecidos. Medir la eficiencia de calidad mediante métricas en la entrada y salida de datos.
EP21
Realizar revisiones internas del producto. Validar calidad entre responsables del proyecto. Incluir herramientas de outsourcing para evaluar atributos de calidad mediante métricas.
EP22 Establecer actividades para la generación automática de casos de prueba. Evaluar entradas y salidas respecto a las esperadas. Utilizar parámetros para establecer límites de calidad.
EP23 Seleccionar y configurar herramientas de integración y medición continua. Evaluar de manera continua la calidad de código mediante integración continua.
46
Medir de manera continua mediante métricas de prácticas ágiles como: defectos, cobertura, etc.
EP24
Establecer límites de calidad y métricas a evaluar durante el proceso. Realizar verificación de producto con respecto a funcionalidad requerida o defectos encontrados. Establecer atributos de calidad para conocer el grado de cumplimiento de la calidad.
Podemos observar que existe una tendencia a integrar prácticas de verificación de los estándares y modelos de calidad, ya que un gran porcentaje de las prácticas encontradas se basan en los procesos de los modelos o estándares de calidad identificados en la Tabla 2, así como la evaluación continua del estado de la calidad mediante el seguimiento y control de métricas de calidad.
Como resultado de las prácticas analizadas, se proponen 3 actividades principales a tener en cuenta para un adecuado entorno de aseguramiento de calidad; (1) identificar elementos relevantes para la calidad, (2) identificar y asignar métricas que tengan mayor impacto en la calidad de la organización y (3) identificar y asignar criterios para la aceptación del producto. Además, se añadieron 2 actividades que se consideran importantes para el aseguramiento de la calidad las cuales son: 4) realizar seguimiento y control de la calidad y 5) verificar la configuración del aseguramiento de la calidad.
2.1.3.3. Pregunta de investigación 3 (RQ3) RQ3. ¿Cuáles son los defectos más comunes en los productos de software? A continuación, en la Tabla 12, se muestra un análisis respecto a la problemática
abordada en los EP obtenidos para la segunda cadena de búsqueda.
Tabla 12 Problemática abordada en los estudios primarios
ID Problemática Solución
EP25 Identificación de defectos en fases tempranas de desarrollo de software.
Identificar las métricas asociadas a tipos de defectos.
EP26 Reducción del impacto de los defectos en el desarrollo del software.
Metodología para identificar los defectos de mayor impacto en el software.
EP27 Detección de defectos en el desarrollo de software.
Análisis de eficiencia de detección de defectos en los métodos UBT-i y UBR.
EP28 Reducción de defectos de software. Caracterizar los defectos en el ciclo de vida del software y los factores que afectan su ocurrencia.
47
EP29 Reducción de defectos en la producción del software.
Tipificación de los defectos inyectados en el desarrollo de software.
A partir del análisis realizado, se puede decir que la integración de métricas asociadas a
tipos de software como se propone en (N. Gupta, Singh, & Sharma, 2015), ayuda a detectar la inyección de defectos, la cual puede ser reforzada mediante la identificación de los tipos de defectos como se propone en (Deshpande, Rao, & Suma, 2015). La identificación de defectos en el ciclo de vida como se establece en (Anand, David, & Sagayaraj, 2015) y (Hale, Hale, & Smith, 2011), pretende identificar densidad de defectos en las fases del proceso de producción de software.
A continuación, se presenta un resumen de los estudios primarios seleccionados a partir de la segunda cadena de búsqueda.
En (N. Gupta et al., 2015) se realizó una propuesta para identificar las relaciones entre métricas y defectos de software, para ello se realizó una clasificación dentro de 4 categorías de defectos una selección de un total de 18 defectos, los defectos seleccionados fueron:
• Profundidad de árbol de herencia (DIT) • Acoplamiento entre objetos (CBO) • Respuesta para una clase (RFC) • Frecuencia de reúso (RR) • Baja cohesión en métodos (LCOM) • Paquetes importados (PACK) • Número de sentencias (NOS) • Errores de Halstead (HBUG) • Tamaño de clases no ponderadas (UWCS) • Variables de instancia declaradas (INST) • Índice de mantenibilidad (MI) • Complejidad ciclomática (AVCC) • Acoplamiento de paso de mensajes (MPC) • Líneas de comentario por clase (CCML) • Líneas de código (NOLC) • Anchura de métodos por clase (WMC) • Esfuerzo Halsted (HEFF)
Las 4 categorías de defectos asignadas fueron: 1) Doggy code, 2) Mala práctica, 3) Correcto y 4) Optimizado. Para identificar las relaciones se realizó un análisis de correlación linear por pares de variables. Los resultados demostraron que para la categoría de optimizado se tienen 5 métricas relacionados que son: LCOM, WMC, LCOM2, NLOC y HEFF, para la
48
categoría de doggy code se tienen 2 métricas relacionadas que son: MPC y RR, para la categoría de mala práctica se tienen las siguientes 3 métricas: LCOM, RR, AVCC y finalmente para la categoría de correcto se tienen las métricas de RR y LCOM.
Por otra parte en (Anand et al., 2015), se muestra el impacto de 12 defectos seleccionados, los cuales son:
• Desviación del estándar de código (DEC) • Defectos de flujo o secuencia (DFS) • Mala cobertura de requerimientos (MCR) • Defectos de interfaz de usuario (DIU) • Incorrecto mapeo de funciones (IMP) • Error de documentación (ED) • Mala ejecución de pruebas (MEP) • Mal uso de técnicas (MT) • Pruebas o error de interface (PEI) • Baja cobertura de pruebas (BCP) • Alcance de variable (AV) • Diseño inadecuado (DI)
El análisis se realizó a 21 proyectos de desarrollo de software, en el cual se utilizó la técnica ANOVA para detectar la varianza entre la densidad de los tipos de defectos seleccionados, posteriormente se realizó un agrupamiento de los resultados usando el método Fisher. Los resultados mostraron que existe un incremento en la incidencia de cierto tipo de errores cuando otros son introducidos, por lo que le es más fácil controlar la calidad y costos del software al líder de proyecto al centrar su atención en la ocurrencia de los defectos que detonan defectos más críticos.
En (Winkler, Biffl, & Faderl, 2010), se describe un análisis comparativo para evaluar dos técnicas para la detección de defectos; 1) UBR y 2) UBT-i, en el que se realizó un experimento controlado en un entorno académico, en donde un grupo de estudiantes llevan a cabo un proyecto de desarrollo utilizando las dos técnicas para la detección de defectos, obteniendo una categorización de defectos para analizar su frecuencia, las 3 categorías propuestas fueron creadas de manera empírica. Las categorías son:
• Clase A: defectos cruciales • Clase B: defectos de alta importancia • Clase C: defectos de menor importancia.
El estudio se realizó en un entorno académico a un proyecto de gestión de taxis. Los resultados fueron los siguientes:
49
• Clase A obtuvo 29 ocurrencias (48.33%) • Clase B obtuvo 24 ocurrencias (40%) • Clase C obtuvo 7 ocurrencias (11.66%)
Los resultados obtenidos arrojan que existen una variación mínima en la eficiencia y efectividad entre ambas técnicas, sin embargo UBT-i requiere un mayor esfuerzo en la creación de sus pruebas.
En (Hale et al., 2011), se realizó una evaluación de técnicas de revisión de código a lo largo del ciclo de vida del software, las técnicas son clasificadas de acuerdo al nivel de formalidad, que varían desde inspecciones formales, revisiones de equipo, revisiones por pares, walkthrough review y revisiones ad-hoc. De la misma manera, se proponen dos clasificaciones generales para los defectos, las cuales son:
• Defectos mayores: son cambios en componentes principales y defectos que afectan la funcionalidad o requisitos.
• Defectos menores: son fallas en el estándar de documentación, errores de diseño, errores en topografía en comentarios o requisitos incompletos.
El estudio se realizó a 991 productos de software en una empresa con una certificación CMMI-DEV V1.1 nivel 3, los resultados obtenidos respecto a la incidencia de defectos fueron los siguientes:
• Defectos mayores 22.28% • Defectos menores 77.71%
En este estudio, se concluyó que el aumento en los defectos en productos de trabajo está directamente relacionado a la complejidad del análisis de problemas en la etapa de análisis.
Finalmente en (Deshpande et al., 2015), se realiza un análisis a la distribución de los defectos inyectados en el ciclo de desarrollo de software, los defectos se clasificaron en 5 categorías de defectos que son:
• Defecto trivial • Defecto menor • Defecto mayor • Defecto crítico • Defecto bloqueante
El análisis se realizó a 5 proyectos en lenguaje java dentro de una empresa de desarrollo de software con una certificación CMMI-DEV nivel 5, los resultados de los proyectos fueron analizados empíricamente y se recolectó evidencia de los defectos ocurridos. Los resultados del análisis fueron los siguientes:
50
• Defectos triviales hasta 10% • Defectos menores hasta 40% • Defectos mayores hasta 32% • Defectos críticos hasta 40% • Defectos bloqueantes hasta 10%
A continuación, en la Tabla 13, se presenta un resumen de la clasificación propuesta en los EPS y su incidencia.
Tabla 13 Análisis de clasificación de defectos e incidencia
A partir de los estudios primarios, se establecieron 3 categorías de defectos para
identificar el tipo de defecto más recurrente en el desarrollo de software:
ID Clasificación Incidencia
EP25
Doggy code Mala práctica Correcto Optimizado
Sin datos
EP26
Desviación del estándar de código (DEC) Defectos de flujo o secuencia (DFS) Mala cobertura de requisitos (MCR) Defectos de interfaz de usuario (DIU) Incorrecto mapeo de funciones (IMP) Error de documentación (ED) Mala ejecución de pruebas (MEP) Mal uso de técnicas (MT) Pruebas o error de interface (PEI) Baja cobertura de pruebas (BCP) Alcance de variable (AV) Diseño inadecuado (DI)
DEC 187 ocurrencias DFS 110 ocurrencias MCR 100 ocurrencias DIU 80 ocurrencias IMP 78 ocurrencias ED 50 ocurrencias MEP 82 ocurrencias MT 60 ocurrencias PEI 40 ocurrencias BCP 45 ocurrencias AV 47 ocurrencias DI 32 ocurrencias
EP27 Case A Clase B Clase C
Case A: 29 (48.33%) Clase B: 24 (40%) Clase C: 7 (11.66%)
EP28 Defectos mayores Defectos menores
Defectos mayores 22.28% Defectos menores 77.71%
EP29
Defecto trivial Defecto menor Defecto mayor Defecto crítico Defecto bloqueante
Defecto trivial hasta 10% Defecto menor hasta 40% Defecto mayor hasta 32% Defecto crítico hasta 40% Defecto bloqueante hasta 10%
51
• Defecto menor: defectos que no interfieren con la funcionalidad del sistema como pueden ser errores en el estándar de código, documentación incompleta, errores en diseño de interfaz.
• Defecto mayor: defectos relacionados con omisiones que no detienen el funcionamiento del sistema pero pueden convertirse en defectos mayores, como pueden ser validación de entradas, tipificación de variables.
• Defecto crítico: defectos relacionados con fallas que ocasionan la caída del sistema, como pueden ser fallas de seguridad, fallas en diseño de alto nivel, comunicación entre componentes.
A continuación, en la Tabla 14, se muestra una media estadística de la clasificación propuesta en la que se tomaron los valores indicados en cada EP y se obtuvo la media estadística para cada clasificación de defectos.
Tabla 14 Distribución de errores en los estudios primarios
Clasificación EP26 EP27 EP28 EP29 Media Defecto menor 49,84 11,66 77,71 37,87 44,27 Defecto mayor 36,87 40,00 22,28 54,54 38,42 Defecto crítico 13,28 48,33 7,57 17,30
Como se puede observar, la categoría de defecto menor obtuvo un mayor índice de
ocurrencia, esto contrasta a los resultados particulares de defectos en artículos en los que se muestra que algunos de los tipos de defectos críticos obtienen mayor valor, esto se debe a que existe una mayor cantidad de clasificaciones para defectos menores que independientemente no representan algún defecto con mayor índice pero que unidos en una clasificación general representan una mayoría.
2.2. Análisis de herramientas comerciales, estándares y modelos orientados a la calidad del producto
En esta sección se presentan análisis de herramientas, modelos y estándares realizado. En la tabla 15 se muestra un análisis realizado a los principales estándares y modelos de calidad para identificar la cobertura de las actividades para el aseguramiento de la calidad propuestas en el estándar IEEE 730.
52
Tabla 15 Análisis de modelos y estándares de calidad de software
Actividades IEEE 730
CMMI-DEV V1.3
ISO 15504 (SPICE) PMBOK MoProSoft
Cobertura en modelos o estándares
Proceso de aseguramiento de la calidad del producto.
PPQA, VER, VAL, MA
- Área-Gestión de la Calidad del Proyecto Grupo de Procesos de Monitoreo y Control
Desarrollo y Mantenimiento de Software, Administración de Proyectos Específicos.
3
Definir aseguramiento de producto
Establece que productos de trabajo puede generar en cada práctica específica de cada proceso.
- Indica que entradas y salidas son requeridas para iniciar y evaluar el cumplimiento de un proceso.
-
2
Evaluar conformidad con el plan
PPQA- Establecer conformidad de proceso y producto.
Proceso de aseguramiento de la calidad del software.
- Desarrollo y Mantenimiento de Software- objetivo 3: Llevar a cabo las actividades de las fases de un ciclo mediante el cumplimiento del plan de desarrollo.
3
Evaluar conformidad del producto
PPQA- Establecer conformidad de proceso y producto VAL- Producto cumple con uso previsto.
Proceso de verificación del software.
Gestión de la Calidad del Proyecto: Realizar el Aseguramiento de Calidad: consiste en auditar los requisitos de calidad y los resultados de las mediciones.
Desarrollo y Mantenimiento de Software- objetivo 1: que los productos de salida sean consistentes con los productos de entrada de cada fase.
4
Evaluar aceptabilidad de producto
VAL- El producto cumple con requisitos especificados.
Proceso de validación del software.
Gestión de la Calidad del Proyecto: Entrada: listas de verificación de calidad.
Administración de Proyectos Específicos: objetivo 2 Mantener informado al cliente.
4
53
Actividades IEEE 730
CMMI-DEV V1.3
ISO 15504 (SPICE) PMBOK MoProSoft
Cobertura en modelos o estándares
Evaluar el soporte al ciclo de vida del producto
TS- SP3.2- Productos de trabajo- Manuales.
- - -
1
Mediciones de producto
MA- mantener capacidad de medición para soporte a la gerencia.
- Gestión de la Calidad del Proyecto: Entrada: métricas de calidad.
Desarrollo y Mantenimiento de Software: indicadores de cumplimiento en cada fase. Administración de Proyectos Específicos: el producto contiene indicadores de tiempo y costo.
3
Como se puede observar en la Tabla 15, las tareas mayormente consideradas dentro de los
modelos y estándares analizados son:
• Evaluar conformidad del producto • Evaluar aceptabilidad de producto • Mediciones de producto.
Por otro lado la actividad menos cubierta fue:
• Evaluar el soporte al ciclo de vida del producto. A continuación, en la Tabla 16, se muestra el análisis realizado a las principales
herramientas enfocadas en la calidad de software, identificando la cobertura de las 3 principales tareas que se identificaron en la Tabla 15.
Tabla 16 Análisis de herramientas orientadas a la calidad del software
Herramienta Tipo Modelo o estándar
soportado
Evaluar conformidad del
producto
Evaluar aceptabilidad de producto
Mediciones de producto
Microsoft project
Gestión de proyectos
PMBOK Permite la asignación y revisión de tareas.
- -
Kaizen / ArgoUML
Elaboración de diagrama de procesos
MoProSoft - - -
54
Trello
Gestión de tareas
- Permite asignar checklist a las actividades para determinar su cumplimiento.
Permite a usuarios visualizar y manipular el estado de las actividades.
-
Jira Gestión de proyectos
ISO 9126, CMMI DEV V1.3
Maneja gestión de errores, prioriza el trabajo en equipo.
- -
The Software Process
Dashboard
Herramienta de soporte de metodología
TSP/PSP Permite evaluar el cumplimiento de estándares de código.
- Integra una suite de métricas de software.
Selenium Automatización de pruebas
- Evalúa funcionalidad de producto.
- Solo evalúa métrica de defectos.
Jenkins
Integración continua / Entrega continua
- Evalúa cumplimiento de las pruebas, gestiona los defectos del producto.
- Se integran métricas con herramientas de terceros y se visualizan resultados en la herramienta.
Analizando los datos anteriores, se concluye que la tarea “evaluación de la conformidad
del producto” es la actividad mayormente cubierta por aproximadamente el 86%, por otra parte, la actividad “evaluación de la aceptabilidad del producto” es la menos cubierta, por un 14% de las herramientas. Finalmente, el porcentaje de cobertura de la actividad “realizar mediciones al producto” es de 43%. Por lo que se concluye que las tendencia en las herramientas existentes se inclina a verificar la cobertura de los requisitos.
2.3. Selección de tecnología En esta sección se analiza y selecciona la tecnología disponible, para la implementación
de la propuesta en el desarrollo de una herramienta de software, esta es una etapa importante ya que la integración de la tecnología seleccionada impactará directamente en el desempeño y percepción de calidad que tengan los usuarios de la herramienta.
2.3.1. Lenguaje de programación La selección de lenguajes de desarrollo, forma parte importante en el desarrollo de la
solución, esta se debe analizar desde varios enfoques para encontrar un equilibrio entre
55
simplicidad, robustez, rendimiento y soporte al lenguaje. A continuación, se presenta un análisis realizado para seleccionar el lenguaje de desarrollo a utilizar.
2.3.1.1. Comparativa entre lenguajes La siguiente información se obtuvo de la página oficial del TIOBE index (TIOBE Index |
TIOBE - The Software Quality Company n.d.), que presenta un indicador de popularidad de lenguajes de programación dentro de la comunidad de desarrolladores.
A continuación, en la Figura 4, se muestra el puntaje obtenido en la página oficial del TIOBE.
Figura 4 Índice de puntuación TIOBE de lenguajes de programación
Nota: Recuperada de “TIOBE Índex” en https://www.tiobe.com/tiobe-index/
Como se puede observar, los lenguajes de programación que obtuvieron los mejores puntuaciones son: Python, JavaScript, R, PHP, Ruby y Swift. Los lenguajes R y Swift son
56
para análisis estadístico (R) y para desarrollo de software bajo el sistema operativo iOS (Swift) por lo que quedaron fuera de las opciones.
En la Tabla 17 se presenta un análisis de las ventajas y desventajas de los lenguajes de programación principales de acuerdo a los resultados del TIOBE index.
Tabla 17 Comparativa entre lenguajes de programación
Lenguaje Ventajas Desventajas
JavaScript
Grande comunidad de usuarios Facilidad para validar formularios
Popularidad en deceso. Es fácil de manipular por sitios externos. Requiere de otro lenguaje de programación para funciones complejas.
Python Sintaxis muy descriptiva. Robusto y potente Extensa documentación
Se requiere servidor que soporte Python
PHP Popularidad en ascenso Lenguaje muy sencillo
Se requiere servidor que soporte PHP
En concusión, se seleccionó el lenguaje de Python, ya es un lenguaje para desarrollo web multiplataforma de última generación, robusto y cuenta con extensa documentación. Además, de acuerdo a los resultados del TIOBE index, ha obtenido buenos resultados en los últimos años incrementando su comunidad de usuarios, y por lo tanto el soporte al lenguaje.
2.3.2. Frameworks de desarrollo Web En esta sección se analizan los frameworks de desarrollo existentes para el lenguaje de
programación seleccionado, el factor que se considera en la selección es la flexibilidad para implementar componentes externos, la comunidad de usuarios y documentación disponible; estos tres factores son importantes en la fase de desarrollo debido a que facilitan la reutilización de componentes de terceros y esto hará más eficiente la etapa de desarrollo.
2.3.2.1. Comparativa de Frameworks A continuación, en la Tabla 18, se muestra una comparación entre los 3 frameworks
principales para desarrollo web para Python.
57
Tabla 18 Comparativa entre frameworks
Framework Descripción Comunidad Material de apoyo
Django
El framework open source, debido a su potencia es el más utilizado en proyectos con Python, trabaja bajo la arquitectura Modelo-Vista-Plantilla (MVT), cuenta con su propio servidor y por ellos es multiplataforma, cuenta con un módulo robusto de administración y otro para el manejo de plantillas. Existen una amplia cantidad de componentes open source disponibles.
Comunidad extensa y activa, existen blog en la página oficial del framework.
Contiene una extensa documentación online y ejemplos de uso de componentes, además de manuales PDF disponibles.
Pyramid
Muy flexible, recomendado cuando se trabaja con prototipado.
Amplia comunidad, menor que Django pero en ascenso 2,800 según datos de su página oficial.
Tiene disponible tutoriales en la página oficial.
Web2py
Creado en el 2007 Web2py es open source trabaja bajo una arquitectura Modelo-Vista-Controlador (MVC), no tiene soporte para Python 3.0.
Cuenta con un foro en diversos países para una ayuda especializada en su idioma.
Tiene una gran cantidad de documentación oficial en su página incluyendo un PDF de 600 páginas que incluyen una introducción a Python.
Analizando las ventajas y desventajas de cada framework, se seleccionó el framework Django, ya que además de contar con una mejor calidad en la documentación y componentes disponibles para reutilización, ofrece otras ventajas como: 1) módulo para el manejo de plantillas, 2) contiene diversos componentes disponibles en la comunidad de desarrolladores, 3) contiene un módulo que permite una migración fácil entre lenguajes de consulta estructurada (SQL) a partir de los modelos establecidos.
2.4. Metodología de desarrollo En esta sección se analizan algunas de las metodologías para desarrollo de software
identificando ventajas y desventajas, para posteriormente, seleccionar la que mejor se adapte a las necesidades del proyecto.
58
2.4.1. Comparación de metodologías A continuación, en la Tabla 19, se identifican las ventajas y desventajas de las
metodologías de desarrollo más populares.
Tabla 19 Comparativa de metodologías
Metodología Ventajas Desventajas
Cascada tradicional
Los participantes tienen responsabilidades definidas. Es fácilmente identificable el avance del proyecto en general.
Las fases de la metodología son dependientes. Debe ser un entorno controlado con requisitos bien definidos y estables.
Espiral
Se realizan incrementos funcionales en cada ciclo. Permite un mejor manejo de riesgos.
Se refinan los requisitos en cada ciclo, por lo que cambian continuamente.
Prototipado
Se puede obtener una idea general del producto deseado en fases tempranas de desarrollo. Permiten visualizar la funcionalidad principal
Se puede crear falsa expectativa de avance.
Debido a la naturaleza del proyecto, ya que se tiene un tiempo establecido y un conjunto de requisitos definidos a partir del diseño de la propuesta, se seleccionó la metodología cascada.
59
Capítulo 3. Metodología para el desarrollo de la tesis
En este capítulo se describe la metodología utilizada para el desarrollo de la tesis. La Figura 5 muestra las tareas llevadas a cabo durante el desarrollo de la tesis y el orden en que se implementaron.
Figura 5 Metodología para el desarrollo de la tesis
3.1. Ejecución de la metodología para el desarrollo de Tesis En esta sección, se describen los pasos que se realizaron para el desarrollo de la
metodología.
1. Definir el estado del arte en el área de calidad de productos de software y tipificación e incidencia de defectos. Con el objetivo de obtener un panorama actual sobre la calidad de productos de software se realiza una revisión sistemática de la literatura enfocada en tres elementos principales: 1) herramientas de gestión de calidad de software, 2) prácticas para el aseguramiento de calidad de software y 3) defectos en productos de software. En el Capítulo 2, sección 2.1 se encuentra detallado el protocolo de la revisión sistemática desarrollado y los resultados obtenidos.
60
2. Establecer una clasificación e incidencia de defectos. A partir de los resultados de la revisión sistemática de la literatura se realizó una clasificación de defectos, en la que se establecieron tres categorías: defecto menor, defecto mayor y defecto crítico. Para cada una de las clasificaciones se identificó el índice de incidencia por medio del cálculo de media aritmética a partir de los datos obtenidos en los estudios primarios. El análisis completo se encuentra en el Capítulo 2, sección 2.1.3.3.
3. Realizar un análisis de herramientas, estándares y modelos orientados a la calidad de productos de software así como sus elementos propuestos. Se analizaron los modelos y estándares de calidad principales identificando la cobertura de las actividades de aseguramiento de la calidad del estándar IEEE 730. De igual manera, se realizó un análisis de las principales herramientas de calidad de software comerciales existentes. El desarrollo de esta actividad se encuentra en el capítulo 2, sección 2.2.
4. Elaborar una propuesta de la herramienta de soporte para el aseguramiento de la calidad de software. La descripción de la propuesta se encuentra detallada en el Capítulo 4, secciones 4.1 y 4.2.
5. Diseñar la herramienta que integre la solución propuesta. A partir de la propuesta para el aseguramiento de la calidad, se desarrolló una herramienta implementando la propuesta, la tecnología utilizada se describe en la sección 2.3, mientras que la metodología de desarrollo se encuentran en la sección 2.4, ambas secciones se encuentran dentro del Capítulo 2.
6. Desarrollar la herramienta. El desarrollo de la herramienta se encuentra en el Capítulo 4, sección 4.4.
7. Realizar un caso de estudio implementando la herramienta desarrollada. Los detalles del caso de estudio realizado se encuentran en el Capítulo 5, sección 5.2. De igual manera, el análisis de los datos recogidos y el reporte de resultados se encuentran en el Capítulo 5 en las secciones 5.2.4 y 5.2.5 respectivamente.
61
Capítulo 4. Herramienta de soporte para el aseguramiento de la calidad del software
Este capítulo contiene los resultados del proceso de desarrollo de la herramienta siguiendo la metodología seleccionada, como son: elementos de diseño, requisitos de software, diagramas de sistema e interfaces de la herramienta. Se comienza con el diseño de la propuesta a partir de la problemática identificada en la revisión sistemática, posteriormente, se elaboran los diagramas del sistema a partir del diseño elaborado. Finalmente se muestra el desarrollo de la herramienta.
4.1. Desarrollo de la propuesta A partir del análisis de los resultados de la revisión sistemática, se identificaron 3
actividades principales a tener en cuenta para un adecuado entorno de aseguramiento de calidad:
1) Selección de elementos relevantes para el aseguramiento de la calidad.
2) Asignación de criterios de aceptación a cada elemento.
3) Selección de métricas de calidad relevantes, conforme a estándares de calidad de la organización.
Además se añadieron 2 actividades que se consideran importantes para el aseguramiento de la calidad:
4) Seguimiento y control del proyecto.
5) Verificación de la configuración.
4.1.1. Diseño de la propuesta La herramienta está diseñada en fases, cada fase está compuesta por actividades, y éstas
están compuestas por una o más tareas enfocadas en realizar las prácticas para el aseguramiento de la calidad. En la Tabla 20, se describen los elementos utilizados para el diseño de la herramienta.
62
Tabla 20 Elementos de diseño de la propuesta
Nombre Descripción Icono
Producto de
trabajo
Es un elemento generado durante el ciclo de vida del desarrollo del proyecto, este puede ser: documentos, diagramas, código ejecutable, script, etc.
Rol Define un conjunto de responsabilidades y habilidades específicas dentro del proyecto de desarrollo de software.
Fase Representa una etapa en el ciclo de vida del aseguramiento de la calidad, está delimitado por una fecha, actividades y productos generados.
Actividad Está conformada por una serie de tareas a realizar y salidas a generar, con el fin de integrar productos que servirán de apoyo para dar por concluida la fase.
Tarea Es una acción específica que el equipo de trabajo deberá realizar para producir las salidas requeridas por la actividad.
Salida
Es un elemento temporal que ayuda en el aseguramiento de la calidad de un producto o bien, proporciona información del estado actual de la calidad del producto de trabajo.
4.1.2. Descripción de la fases A partir de los elementos propuestos y de las 5 actividades para el aseguramiento de la
calidad identificadas en la sección 4.1 del documento. Se diseñaron un total de 8 fases, las cuales se detallan a continuación.
63
4.1.2.1. Fase de inicio El objetivo de esta fase, es configurar la herramienta acorde al plan de proyecto y/o al
plan de calidad, asignando las fases necesarias y los productos de trabajo a evaluar, así como de las métricas y criterios de aceptación aplicables a cada producto de trabajo agregado o que sea requerido por estándares de calidad de la organización.
Esta fase integra 4 actividades para el aseguramiento de la calidad que son: 1) selección de elementos relevantes para el aseguramiento de la calidad; 2) asignación de métricas de calidad relevantes; 3) asignación de criterios de aceptación a cada elemento y 4) verificación de la configuración. Esta fase está diseñada para que el líder de proyecto configure la herramienta, seleccionado las fases, productos, criterios y métricas considerados para el control de la calidad.
4.1.2.1.1. Elementos de entrada Los elementos requeridos para esta fase son: el plan de proyecto, se utiliza como
referencia para realizar la configuración de la herramienta de acuerdo a sus fases de desarrollo, roles y productos de trabajo necesarios; y/o el plan de calidad, del cual deben ser considerados los productos de trabajo, criterios de aceptación y métricas de calidad que en él se requieran. En caso de no contar con éstos, también se pueden considerar herramientas de gestión de desarrollo del proyecto, en donde se toman las actividades o tareas establecidas para instanciar las fases de acuerdo a ellas.
4.1.2.1.2. Roles involucrados A continuación, se describen los roles involucrados en esta fase.
• Líder de proyecto: Es el responsable de realizar las configuraciones en la herramienta respecto al plan de calidad, plan de proyecto o herramienta de gestión de proyecto, agregando las fases necesarias para el aseguramiento de la calidad, los productos de trabajo en cada fase, las métricas de calidad asociadas y los criterios de aceptación para cada producto.
• Gerente de calidad: Es el responsable de evaluar la conformidad de la configuración de la herramienta con respecto al plan de proyecto, así como las métricas de la calidad y los criterios de aceptación para cada producto de trabajo, verificando la configuración de la herramienta.
4.1.2.1.3. Actividades Las actividades que definen esta fase están orientadas a configurar la herramienta con
respecto al plan de calidad y/o plan de proyecto, para posteriormente ser implementada durante el desarrollo del proyecto.
64
1. Configuración respecto al plan de calidad, plan de proyecto y/o herramientas de gestión de proyecto
En esta actividad se agregan las fases para el desarrollo del proyecto, así como los productos de trabajo que se evaluarán en cada fase. La actividad contiene 2 tareas orientadas a establecer fases, productos de trabajo, asignación de criterios y métricas de calidad respecto al plan de proyecto, plan de calidad y/o herramienta de gestión de proyecto. A continuación, se describen las dos tareas contenidas en esta actividad.
• Identificar y agregar fases del ciclo de aseguramiento. En esta tarea se agregan las fases y eventos importantes acorde al plan de proyecto, plan de calidad o herramienta de gestión del proyecto, la salida de esta fase es la configuración de la herramienta alineada al plan de proyecto, plan de calidad y/o herramienta de gestión de proyecto.
• Agregar los productos de trabajo requeridos. En esta tarea se identifican los productos de trabajo que deben ser evaluados o son requeridos por el plan de calidad, plan de proyecto y/o herramienta de gestión de proyecto. Una vez identificados, se agregan a la configuración en la fase correspondiente acorde a la metodología de desarrollo, algunos ejemplos de productos de trabajo son: documento de requisitos, diseño de sistema, formato de revisiones, código fuente, plan de pruebas, etc. En esta tarea se obtiene como salida la configuración de la herramienta con los productos de trabajo asignados a cada fase.
2. Asignar métricas de calidad y criterios de aceptación a los productos de trabajo agregados
En esta actividad, se identifican las métricas que son requeridas por el plan de proyecto, plan de calidad y/o herramienta de gestión de proyecto, de igual manera se asignan los criterios de aceptación a los productos de trabajo registrados conforme al plan de calidad o estándares de la organización. Esta actividad contiene 3 tareas orientadas a identificar, asignar y evaluar las métricas y criterios de aceptación para el aseguramiento de la calidad de cada producto de trabajo. A continuación, se describen las tareas contenidas en esta actividad.
• Identificar y asignar criterios de aceptación a los productos de trabajo. En esta tarea son identificados y asignados los criterios de aceptación acorde al plan de calidad o en su defecto a estándares de la organización. La salida de esta actividad es la selección y asignación de los criterios de aceptación para cada producto de trabajo agregado en la configuración de la herramienta.
65
• Identificar y asignar métricas aplicables al control de la calidad. En esta tarea son identificadas y asignadas las métricas requeridas por el plan de proyecto, plan de calidad y/o herramienta de gestión de proyecto, las cuales tengan impacto en los productos de trabajo agregados a la configuración. Las salidas esperadas de esta actividad es la selección y asignación de las métricas para cada producto de trabajo agregado en la configuración de la herramienta.
• Determinar si las métricas seleccionadas son representativas de la calidad según el plan de proyecto, plan de calidad y/o herramienta de gestión de proyecto. En esta tarea se evalúa si las métricas asignadas a los productos de trabajo son representativas de acuerdo al plan de calidad o estándares de la organización establecidos. La salida esperada de esta tarea es la verificación de las métricas seleccionadas para cada producto de trabajo.
3. Evaluar la aceptabilidad de la configuración de la herramienta
En esta actividad se verifica la aceptación de la configuración de la herramienta. En esta actividad contiene una tarea enfocada en determinar cuando la configuración de la herramienta se completó. A continuación, se describe la tarea contenida en esta actividad.
• Evaluar conformidad de la configuración de la herramienta. Esta tarea, tiene como objetivo validar que la configuración de la herramienta se completó, es decir, que la herramienta contenga las fases, productos, métricas y criterios de aceptación y que no existe algún elemento incompleto. La salida de esta tarea es obtener la aprobación de la configuración por el gerente de calidad.
A continuación, en la Figura 6, se muestra el diagrama de diseño correspondiente a la fase de Inicio.
66
Figura 6 Fase de inicio
4.1.2.2. Fase de análisis El objetivo de esta fase es: verificar y validar requisitos, evaluando el contenido del
documento de requisitos, así como los resultados de medición realizados.
Esta fase integra la actividad de seguimiento y control. Esta fase está diseñada para que el analista realice las verificaciones correspondientes y el gerente de calidad evalué los resultados de medición obtenidos.
4.1.2.2.1. Elementos de entrada El producto de trabajo requerido para esta fase es el documento de requisitos (SRS). Si
existen requisitos licitados mediante outsourcing estos deberán ser incluidos para su evaluación.
67
4.1.2.2.2. Roles involucrados A continuación se describen los roles involucrados en esta fase.
• Analista. Este rol es el responsable de evaluar la conformidad del documento de requisitos contra los criterios de aceptación establecidos y registrar los resultados de medición.
• Gerente de calidad. Es el rol responsable de evaluar y analizar los resultados de las mediciones al documento de requisitos y registrar acciones correctivas en caso de ser necesario.
4.1.2.2.3. Actividades Las actividades contenidas en la fase de análisis están orientadas a evaluar el documento
de requisitos para determinar el grado de cumplimiento de los criterios de aceptación, así como analizar los resultados de medición.
1. Evaluar aceptabilidad de documento de requisitos.
En esta actividad se realiza la verificación y validación al documento de requisitos para identificar el cumplimiento con los criterios de aceptación agregados en la fase de inicio. Esta actividad contiene 2 tareas enfocadas a verificar y validar el documento de requisitos. A continuación se describen las dos tareas contenidas en esta actividad.
• Determinar conformidad entre documento de requisitos y criterios de aceptación. Consiste en evaluar (validar, verificar o revisar) el cumplimiento de los criterios de aceptación establecidos usando técnicas de: revisión, auditoría, pruebas o evaluaciones. La salida requerida de esta tarea es el documento de requisitos verificado con respecto a los criterios de aceptación registrados para este producto.
• Validación del documento de requisitos. En esta tarea el cliente valida el cumplimiento de los criterios de aceptación en el documento de requisitos. La salida de esta tarea es el documento de requisitos validado con respecto a los criterios de aceptación.
2. Mediciones al documento de requisitos
Esta actividad, está enfocada a evaluar los resultados de medición del documento de requisitos, contiene una tarea enfocada a identificar no conformidades en los resultados de medición en el documento de requisitos. A continuación, se describe la tarea correspondiente a esta actividad.
68
• Analizar resultados de medición de calidad. En esta tarea se analizan los resultados de calidad obtenidos en el documento de requisitos contra los resultados esperados para identificar mejoras o no conformidades. La salida esperada es retroalimentación del equipo o no conformidades en los resultados de medición en caso de existir.
A continuación, en la Figura 7, se muestra el diseño correspondiente a la fase de Análisis.
Figura 7 Fase de análisis
4.1.2.3. Fase de evaluación de riesgos El objetivo de esta fase, es evaluar el documento de gestión de riesgos, el cual es
verificado contra los criterios de aceptación establecidos y son evaluados los resultados de medición obtenidos.
69
Esta fase integra la actividad para el aseguramiento de la calidad de seguimiento y control. Esta fase está diseñada para que el líder de proyecto verifique el cumplimiento de los criterios de aceptación y el gerente de calidad evalúe los resultados de medición.
4.1.2.3.1. Elementos de entrada El producto de trabajo requerido para esta fase es el documento de gestión de riesgos.
4.1.2.3.2. Roles involucrados Los roles que intervienen en esta fase son los siguientes.
• Líder de proyecto. Este rol es en encargado de realizar la verificación del cumplimiento de los criterios de aceptación establecidos en la fase de inicio para el documento de gestión de riesgos.
• Gerente de calidad. Este rol es el encargado de evaluar los resultados de medición obtenidos de las métricas asignadas el documento de gestión de riesgos en la fase de inicio.
4.1.2.3.3. Actividades La fase de evaluación contiene dos actividades orientadas a verificar y validar el
documento de requisitos contra los criterios de aceptación agregados en la fase de inicio y a evaluar los resultados de medición. A continuación se describen las actividades correspondientes.
1. Evaluar aceptabilidad del documento de gestión de riesgos
En esta actividad, se confirma el cumplimiento de los criterios de aceptación. Esta actividad está compuesta por una tarea, la cual se describe a continuación.
• Conformidad del documento de riesgos. En esta tarea se evalúa el cumplimiento de los criterios de aceptación aplicables al documento de gestión de riesgos. Esta tarea genera como salida el documento de riesgos verificado por el líder de proyecto.
2. Mediciones al documento de gestión de riesgos
Esta actividad está compuesta por una tarea, la cual está orientada a evaluar los resultados de medición. A continuación se describe la tarea contenida.
• Analizar resultados de medición. En esta tarea se evalúan los resultados de medición del documento de riesgos contra los resultados de medición esperados.
70
La salida de esta tarea es la identificación de las no conformidades en los resultados esperados.
La Figura 8 muestra el diseño correspondiente a la fase de evaluación de riesgos.
Figura 8 Fase de evaluación de riesgos
4.1.2.4. Fase de diseño El objetivo de esta fase, es verificar y validar el diseño del sistema, así como evaluar los
resultados de medición.
Esta fase cubre con la actividad de seguimiento y control. Está diseñada para que el arquitecto evalué el cumplimiento de los criterios de aceptación registrados para el diseño del sistema.
4.1.2.4.1. Elementos de entrada Los productos de software requeridos para esta fase son: el diseño detallado y arquitectura
del sistema, los cuales muestran el funcionamiento y estructura del sistema, algunos ejemplos
71
de diagramas son: diagrama de clases, diagrama de componentes, diagrama entidad-relación, diagrama de procesos, diagrama de componentes, etc.
4.1.2.4.2. Roles involucrados A continuación se presenta una descripción de los roles requeridos para la fase de diseño
y las actividades a su cargo.
• Arquitecto de software: Este rol es el responsable de la ejecución de las actividades de evaluar el cumplimiento de los criterios de aceptación del diseño de software agregados en la fase de inicio.
• Gerente de calidad: Es el responsable de evaluar los resultados de medición en los diagramas de diseño y tomar acciones correctivas a los resultados en caso de ser necesarias.
4.1.2.4.3. Actividades La fase de diseño, está compuesta por 3 actividades enfocadas a identificar el
cumplimiento de los criterios de aceptación en el diseño detallado y la arquitectura del sistema, así como a evaluar los resultados de medición obtenidos.
1. Evaluar la conformidad del diseño
Esta actividad está orientada a determinar cuándo el diseño de software está conforme a los requisitos documentados. Está compuesta por una tarea enfocada en verificar el cumplimiento de requisitos establecidos en el documento de requisitos. A continuación se describe la tarea correspondiente a esta actividad.
• Evaluar (validar, verificar o revisar) conformidad del diseño de sistema contra los requisitos de software establecidos. En esta tarea se verifica que el diseño del sistema esté alineado o cumpla con los requisitos de software establecidos en el documento de requisitos. La salida de esta tarea es el diseño de sistema verificado contra los requisitos del cliente.
2. Evaluar la aceptabilidad del diseño de sistema
El objetivo de esta actividad es evaluar el cumplimiento de los criterios de aceptación establecidos para el diseño de sistema en la fase de inicio. Está actividad está conformada por dos tareas, las cuales se describen a continuación.
• Determinar conformidad del diseño del sistema y criterios de aceptación. En esta tarea se realizan verificaciones a los diagramas del sistema con respecto a los criterios de aceptación agregados a los diagramas de diseño en la fase de inicio,
72
utilizando técnicas de: revisión, auditoría, pruebas o evaluaciones. La salida requerida de esta tarea es el diseño de sistema verificado contra los criterios de aceptación.
• Validación del diseño de sistema. En esta tarea el cliente valida el cumplimiento de los criterios de aceptación en el diseño del sistema. La salida de esta tarea es el diseño de sistema validado con respecto a los criterios de aceptación.
3. Mediciones de calidad en el diseño de sistema
Esta actividad se enfoca en evaluar los resultados de medición de la calidad realizados al diseño del sistema. Esta actividad está conformada por una tarea enfocada en evaluar los resultados de medición, la cual se describe a continuación.
• Analizar resultados de medición. En esta tarea son evaluados los resultados de medición obtenidos en el diseño de sistema para detectar no conformidades con respecto a los resultados de medición esperados. Esta tarea genera como salida las no conformidades identificadas con respecto a los resultados de medición actual y los resultados de medición esperados.
En la Figura 9, se muestra el diseño correspondiente a la fase de diseño.
73
Figura 9 Fase de diseño
4.1.2.5. Fase de desarrollo El objetivo de esta fase es evaluar que el código fuente cumpla con los criterios de
aceptación establecidos y evaluar los resultados de medición.
Esta fase cubre la actividad de aseguramiento de la calidad correspondiente al seguimiento y control. Está diseñada para que el desarrollador verifique el cumplimiento de los criterios de aceptación establecidos para el código fuente y el gerente de calidad evalúe los resultados de medición obtenidos.
4.1.2.5.1. Elementos de entrada El producto de trabajo requerido para esta fase es el código fuente o módulos del sistema
que implementan la funcionalidad requerida en la fase de análisis.
74
4.1.2.5.2. Roles involucrados Los roles relacionados a esta fase son aquellos que intervienen en la generación y
evaluación del código fuente, los cuales se describen a continuación.
• Desarrollador. Es el responsable de realizar la verificación del código fuente desarrollado con respecto a los criterios de aceptación establecidos en la fase de inicio.
• Gerente de calidad. Este rol es el responsable de evaluar los resultados de medición de código fuente para identificar mejoras o no conformidades en la medición de calidad.
4.1.2.5.3. Actividades Esta fase está conformada por tres actividades de aseguramiento de la calidad enfocadas
en la verificación y validación del código fuente. A continuación se describen las 3 actividades.
1. Evaluar la conformidad del código fuente
En esta actividad se determina si el código fuente cumple con los requisitos del software identificados en el documento de requisitos, de igual manera, se verifica que el código fuente implementa el diseño de software establecido. A continuación, se describen las dos tareas que componen esta actividad.
• Evaluar (validar, verificar o revisar) conformidad del código fuente contra los requisitos de software establecidos. En esta tarea que verifica que la funcionalidad indicada en los requisitos de software sea implementada en el código fuente. La salida de esta tarea es el código fuente verificado contra los requisitos de software establecidos en el documento de requisitos.
• Evaluar (validar, verificar o revisar) conformidad en código fuente contra el diseño de software establecido. En esta tarea se verifica que el código fuente implemente el diseño de software propuesto en los diagramas de diseño. La salida de esta tarea es el código fuente verificado contra el diseño de software establecido.
2. Evaluar aceptabilidad del código fuente
Esta actividad está compuesta por una tarea enfocada a evaluar el cumplimiento de los criterios de aceptación en el código fuente. A continuación se describe la tarea contenida en esta actividad.
75
• Determinar conformidad de código fuente y criterios de aceptación. En esta tarea, se realizan revisiones al código fuente usando técnicas de: revisión, auditoría, pruebas o evaluaciones, para determinar el cumplimiento de los criterios de aceptación establecidos en la fase de inicio. La salida de esta tarea es el código fuente verificado y validado contra los criterios de aceptabilidad establecidos.
3. Mediciones de calidad en el código fuente
Esta actividad está compuesta por una tarea, la cual está enfocada en evaluar los resultados de medición en el código fuente. A continuación, se describe la tarea contenida en esta actividad.
• Analizar resultados de medición. En esta tarea, se analizan los resultados de medición obtenidos del código fuente, para identificar inconformidad en los resultados de medición obtenidos contra los resultados de medición esperados. La salida de ésta tarea son las no conformidades identificadas en los resultados de medición.
A continuación, en la Figura 10, se muestra el diseño correspondiente a la fase de desarrollo.
76
Figura 10 Fase de desarrollo
4.1.2.6. Fase de pruebas El objetivo de esta fase es evaluar el plan de pruebas y/o los reportes de pruebas para
evaluar el cumplimiento con los requisitos de calidad y criterios de aceptación establecidos en la fase de inicio.
Esta fase cubre con la actividad de aseguramiento de la calidad de seguimiento y control. Está diseñada para que el tester verifique el cumplimiento de los criterios de aceptación, de igual manera que el gerente de calidad evalúe los resultados de medición obtenidos.
4.1.2.6.1. Elementos de entrada Los elementos de entrada requeridos en esta fase son el plan de pruebas o procedimientos
de pruebas, y/o los resultados de pruebas.
77
4.1.2.6.2 Roles involucrados Los roles involucrados en esta fase son los que intervienen en la elaboración y ejecución
de las pruebas de software, los cuales se describen a continuación.
• Tester. Este rol es el encargado de determinar cuando el plan de pruebas y/o los resultados de pruebas cumplen con los criterios de aceptación establecidos en la fase de inicio.
• Gerente de calidad. Este rol es el responsable de evaluar los resultados de medición correspondientes a la ejecución de pruebas, así como establecer las acciones correctivas a las no conformidades identificadas entre los resultados de medición obtenidos contra los resultados de medición esperados.
4.1.2.6.3. Actividades Las actividades en esta fase están orientadas a verificar la aceptabilidad del plan de
pruebas y resultados de pruebas, así como identificar no conformidades en los resultados de medición. Las actividades 3 actividades contenidas en la fase de pruebas son descritas a continuación.
1. Evaluar conformidad del plan de pruebas o procedimiento de pruebas
En esta actividad se realiza la revisión al plan de pruebas o procedimientos de pruebas para verificar que los requisitos establecidos son debidamente probados o considerados en el plan de pruebas o procedimiento de pruebas. Esta actividad, contiene una tarea la cual se describe a continuación.
• Evaluar conformidad de plan de pruebas o procedimiento de pruebas contra los requisitos de software establecidos. En esta tarea se valida, verifica o revisa que los requisitos de software son probados de manera correcta por las pruebas realizadas. La salida de esta tarea es el plan de pruebas o procedimientos de prueba verificado contra requisitos de software establecidos en el documento de requisitos.
2. Evaluar aceptabilidad del plan de pruebas y los resultados de pruebas
Esta actividad contiene dos tareas orientadas a evaluar el cumplimiento de los criterios de aceptación aplicables al plan de pruebas y a los resultados de pruebas. A continuación, se describen las tareas correspondientes a esta actividad.
• Determinar conformidad entre resultados de pruebas y plan de pruebas contra criterios de aceptación. En esta tarea se determina si el plan de pruebas y los
78
resultados de pruebas cumplen con los criterios de aceptación asignados en la fase de inicio, utilizando técnicas de: revisión, auditoría o evaluaciones. La salida de esta tarea es el plan de pruebas y resultados de pruebas verificados contra los criterios de aceptación establecidos.
• Validación de los resultados de pruebas. En esta tarea el cliente confirma que los resultados de pruebas cumplen con los criterios de aceptación asignados. La salida de esta tarea son los resultados de pruebas validados con respecto a los criterios de aceptación establecidos.
3. Mediciones de calidad al plan de pruebas y resultados de pruebas
Esta actividad está orientada a evaluar los resultados de medición realizados al plan de pruebas y resultados de pruebas. Esta actividad está conformada por una tarea que se describe a continuación.
• Analizar resultados de medición. En esta tarea se evalúan los resultados de medición del plan de pruebas y resultados de pruebas. La salida de esta tarea son las no conformidades en los resultados de medición obtenidos con respecto a los resultados de medición esperados.
A continuación, en la Figura 11, se muestra el diseño correspondiente a la fase de pruebas.
79
Figura 11 Fase de pruebas
4.1.2.7. Fase de liberación En esta fase es evaluado el procedimiento de entrega del software, para verificar que
cumpla con los estándares de calidad y criterios de aceptación establecidos en la fase de inicio.
Esta fase cumple con la actividad de aseguramiento de la calidad de seguimiento y control. Está orientada a que el líder de proyecto verifique el cumplimiento de los criterios de aceptación y el gerente de calidad evalúe los resultados de medición obtenidos del procedimiento de entrega.
4.1.2.7.1. Elementos de entrada En esta fase se requiere la evidencia de entrega del software tal como: procedimientos de
entrega o scripts de entrega continua si se realizarán prácticas ágiles.
80
4.1.2.7.2. Roles involucrados Los roles requeridos para esta fase son los encargados de la ejecución del procedimiento
de entrega, los cuales se describen a continuación.
• Gerente de calidad. Es el encargado de analizar los resultados de medición del procedimiento de entrega.
• Líder de proyecto. Es el encargado de verificar que el procedimiento de entrega cumpla con los criterios de aceptación establecidos.
4.1.2.7.3. Actividades Las actividades de esta fase están orientadas al aseguramiento de la calidad del
procedimiento de entrega del software, así como la documentación relacionada tal como formatos o scripts. Esta fase está conformada por dos actividades las cuales son:
1. Evaluar aceptabilidad del procedimiento de entrega
En esta actividad se revisa que el procedimiento de entrega cumpla con los criterios de aceptación establecidos y estos sean confirmados por el cliente. Esta actividad está compuesta por dos tareas, las cuales se describen a continuación.
• Determinar la conformidad entre el procedimiento de entrega y los criterios de aceptación. En esta tarea se verifica que el procedimiento de entrega cumpla con los criterios de aceptación establecidos en la fase de inicio utilizando técnicas de: revisión, auditoría, pruebas o evaluaciones. Esta tarea genera como salida el procedimiento de entrega verificado contra los criterios de aceptación establecidos.
• Validación del procedimiento de entrega. En esta tarea el cliente confirma el cumplimiento de los criterios de aceptación que fueron asignados al procedimiento de entrega en la fase de inicio. La salida de esta tarea es el procedimiento de entrega validado con respecto a los criterios de aceptación establecidos.
2. Mediciones de calidad al procedimiento de entrega
En esta actividad se evalúan los resultados en las mediciones de calidad del procedimiento de entrega para identificar no conformidades en los resultados obtenidos. Esta actividad está conformada por una tarea, la cual se describe a continuación.
• Analizar resultados de medición del procedimiento de entrega. Para esta tarea se analizan los resultados de calidad obtenidos contra los resultados de calidad
81
esperados para determinar no conformidades. La salida de esta tarea son las no conformidades identificadas con respecto a los resultados de medición obtenidos.
La Figura 12 muestra el diseño correspondiente a la fase de liberación.
Figura 12 Fase de liberación
4.1.2.8. Fase de cierre El objetivo de esta fase es evaluar el contenido del documento de cierre del proyecto y su
documentación relacionada, para verificar que se cumplan con los criterios de aceptación establecidos en la fase de inicio.
Esta actividad cubre con la actividad de aseguramiento de la calidad de seguimiento y control. Por lo que está orientada a que el líder de proyecto confirme el cumplimiento de los criterios de aceptación y de igual manera el gerente de calidad evalúe los resultados de medición obtenidos.
82
4.1.2.8.1. Elementos de entrada Para esta fase se requiere el documento de cierre de proyecto que contiene las condiciones
en las cuales el proyecto será finalizado.
4.1.2.8.2. Roles involucrados El rol que se requiere para esta fase es el encargado de realizar el cierre del proyecto, el
cual debe supervisar la buena comunicación con el cliente, y determinar el cumplimiento de los criterios de aceptación al momento del cierre. A continuación se describe brevemente las responsabilidades del rol involucrado.
• Líder de proyecto. Este rol es el encargado de determinar el cumplimiento de los criterios de aceptación aplicables al documento de cierre de proyecto.
4.1.2.8.3. Actividades La fase está conformada por una actividad, que está orientada en la verificación de los
criterios de aceptación en el documento de cierre del proyecto.
1. Evaluar aceptabilidad del documento de cierre de proyecto
Esta actividad verifica que los criterios de aceptación agregados en la fase de inicio sean correctamente cubiertos. Esta actividad está compuesta por una tarea que se detalla a continuación.
• Determinar conformidad entre documento de cierre del proyecto y criterios de aceptación. En esta tarea se realiza la verificación al documento de cierre de proyecto para evaluar el cumplimiento de los criterios de aceptación utilizando técnicas de: revisión, auditoría, pruebas o evaluaciones. La salida de esta tarea es el documento de cierre de proyecto verificado contra criterios de aceptación establecidos.
En la Figura 13, se muestra el diseño correspondiente a la fase de cierre.
83
Figura 13 Fase de cierre
4.2. Desarrollo de la herramienta Para facilitar a las empresas la incorporación de las actividades de aseguramiento de la
calidad, se desarrolló una herramienta de acuerdo a las tecnologías seleccionadas en la sección 2.3 y al diseño propuesto en la sección 4.1. A continuación, se describen algunos de los modelos principales para comprender el funcionamiento de la herramienta.
4.2.1. Modelo de Requisitos El modelo de requisitos permite identificar los roles que participan y las funciones a las
cuales tiene acceso en el sistema, en este caso, se realizó un diagrama de casos de uso, el cual se muestra en la Figura 14.
84
Figura 14 Diagrama de casos de uso
4.2.2. Modelo de Contenido El modelo de contenido, es un diagrama que describe la estructura estática del sistema, en
este caso se realizó a partir del documento de requisitos se elaboró un diagrama Entidad-Relación. El cual se puede observar en la Figura 15.
85
Figu
ra 1
5 D
iagr
ama
entid
ad-r
elac
ión
86
4.2.3. Modelo de Navegación El modelo de navegación describe las relaciones de las funciones de todo el sistema. La
Figura 16 muestra el modelo de navegación del módulo de administración de proyectos, mientras que la Figura 17, muestra el modelo de navegación del módulo de evaluación de proyectos.
Figura 16 Diagrama de navegación de módulo de configuración
87
Figura 17 Diagrama de navegación de módulo de seguimiento y control
4.2.4. Elementos de metodología analizados para configuración de herramienta
4.2.4.1. Fases de aseguramiento de la calidad de software A continuación se muestran las fases definidas para la configuración de los proyectos en
la herramienta, estas fases se obtuvieron a partir de un análisis de las fases comunes en las principales metodologías de desarrollo de software. Las fases son las siguientes:
88
• Análisis: el objetivo de esta fase es verificar y validar requisitos, así como verificar el contenido de documento de requisitos y evaluar los resultados de medición realizadas.
• Diseño: el objetivo de esta fase es verificar y validar el diseño del sistema, así como el evaluar resultados de medición en el diseño de sistema.
• Evaluación de riesgos: el objetivo de esta fase es evaluar los documentos de gestión de riesgos, lo cual es verificado contra los criterios de aceptación establecidos, además de evaluar los resultados de medición en los documentos de gestión de riesgos.
• Desarrollo: el objetivo de esta fase es evaluar el cumplimiento de los requisitos y diseño del sistema contra el código fuente y el cumplimiento de los criterios de aceptación y resultados de medición en el código fuente.
• Pruebas: el objetivo de esta fase es evaluar los resultados de las pruebas y el contenido de reportes de pruebas, así como verificar el cumplimiento de los criterios de aceptación y resultados de medición asociados a las pruebas.
• Liberación: el objetivo de esta fase es evaluar el procedimiento de entrega y la evidencia generada del procedimiento de entrega.
• Cierre: el objetivo de esta fase es evaluar el contenido en el documento de cierre de proyecto.
4.2.4.2. Productos de trabajo A continuación se muestran los productos de trabajo disponibles en la herramienta. Estos
productos de trabajo fueron el resultado de un análisis realizado a los principales productos de trabajo relacionados a cada una de las fases identificadas en la sección 4.2.4.1. A partir del análisis realizado se obtuvieron los siguientes productos de trabajo para cada fase.
Análisis - Documento de especificación de requisitos
Diseño - Diagrama de diseño (Componentes, actividades, estados, E-R, clases, procesos,)
Evaluación - Documento de gestión de riesgos
Desarrollo - Código fuente
Pruebas - Plan de pruebas / Resultados de pruebas
Liberación - Procedimiento de entrega
Cierre - Documento de cierre de proyecto
89
4.2.4.3. Métricas de calidad En esta sección se analiza la trazabilidad de un conjunto de métricas de calidad
disponibles en la herramienta; obtenidas a partir de la extension de un estudio previo realizado en (), a partir de este, se agregaron un conjunto de métricas de la calidad, y atributos de calidad propuestos en el estándar ISO/IEC 9126 (ISO 2000), el objetivo de ese trabajo es permitir alinear la selección de métricas de calidad en la configuración del proyecto con respecto a los objetivos de calidad dentro de la organización, por medio de los atributos de calidad relacionadoas a cada métrica.
A continuación se muestran las métricas seleccionadas y su definición.
• Anchura de métodos por clase (WMC): se relaciona directamente con la definición de complejidad de un objeto, desde que los métodos son propiedades de objetos y complejidad de un objeto es determinada por la cardinalidad de su conjunto de propiedades.
• Profundidad de árbol de herencia (DIT): indica el máximo número de niveles de herencia heredados desde una clase particular hacia su clase padre. Esta es una medición de cuantas clases padre puede potencialmente afectar esta clase.
• Número de hijos (NOC): es una medida que indica la cantidad de sub clases que heredadas de la clase padre.
• Respuesta para una clase (RFC): indica el número de métodos que son llamados en respuesta a un mensaje recibido por un objeto de una clase. Esta métrica muestra cuanto una clase se comunica con otras clases.
• Acoplamiento entre objetos (CBO): nivel de dependencia entre funciones de diferentes módulos.
• Cohesión entre métodos (LCOM): distancia en líneas de código entre módulos que tienen relación.
• Líneas de código (LOC): total de líneas de código existentes en un archivo de código.
• Inyección de defectos (DI): cantidad de defectos inyectados en el componente.
• Eliminación de defectos (DR): total de defectos eliminados en el componente.
• Complejidad ciclomática (CC): medición de partes independientes lineales máximas en la parte de control de programas.
90
A continuación, se listan el conjunto de atributos de calidad y su definición.
• Understability: capacidad del producto de software de permitir a los usuarios entender el entorno en el que el software es adecuado.
• Stability: capacidad del producto de software de evitar efectos inesperados a partir de modificaciones al software.
• Testeability: capacidad del software de permitir ser validado contra los requisitos aplicables.
• Recoverability: capacidad del software de re establecer un nivel específico de funcionalidad y recuperar los datos afectados en caso de un fallo.
• Modifiability: capacidad del software para permitir la implementación de una modificación al sistema.
• Usability: capacidad del software de ser entendido, aprendido, usado y atractivo para un usuario, cuando se utiliza bajo condiciones específicas.
• Efficiency: capacidad del software para proveer rendimiento adecuado, en función a la cantidad de recursos utilizados bajo condiciones establecidas.
• Analyzability: capacidad del software de ser diagnosticado para deficiencias o causas de fallos, e identificar las partes que deben ser modificadas.
• Adaptability: capacidad del software de ser modificado para operar en diferentes ambientes específicos sin aplicar acciones que no fueran provistas para el propósito del software.
• Learnability: capacidad del software de permitir a un usuario aprender sobre la aplicación, su funcionamiento y uso.
• Functionality: capacidad del software de proveer funcionalidad que satisfaga las necesidades implícitas y explícitas cuando el software se utiliza bajo condiciones específicas.
• Maintainability: capacidad del software de ser modificado. Las modificaciones pueden incluir correcciones, mejoras o adaptaciones a cambios en el entorno, y en requisitos y especificaciones funcionales.
• Reusability: capacidad del software o componente para ser utilizado en diferentes dominios.
91
• Traceability: capacidad del software para conectar una larga proporción de código con revisiones de código o elementos del diseño del sistema.
• Change proness: nivel en el que un componente de sistema o módulo de código es propenso a ser actualizado.
A partir de las definiciones anteriores, en la Tabla 21, se muestra la trazabilidad deacuerdo a su definición entre el conjunto de métricas analizado y los atributos de calidad.
92
Tab
la 2
1 T
raza
bilid
ad e
ntre
mét
rica
s y a
trib
utos
de
calid
ad
93
Capítulo 5. Resultados En este capítulo se presentan los resultados de la implementación de la herramienta
desarrollada. Este capítulo incluye tanto la descripción de algunas de las principales pantallas de la herramienta, así como el estudio de caso diseñado y realizado para validar la propuesta.
5.1. Herramienta para implementación de la propuesta A continuación, se muestran las interfaces principales de la herramienta elaborada
indicando la actividad del aseguramiento de la calidad a la que están orientadas.
5.1.1. Interfaz de gestión de elementos En la Figura 18, se muestra un ejemplo de la interfaz para la gestión de productos de
trabajo, elementos tales como: proyectos, fases de proyecto, roles de proyecto, eventos de proyecto y productos de trabajo de fase, los cuales se gestionan en una interfaz similar. Esta pantalla implementa la actividad de Evaluar conformidad de la configuración respecto al plan de calidad y/o plan de proyecto contenida en la la fase de inicio de la propuesta.
Figura 18 Interfaz de gestión de productos de trabajo
5.1.2. Interfaz de gestión de métricas y criterios de producto de trabajo
En la Figura 19, se muestra un ejemplo de la interfaz en la cual se gestionan los criterios de aceptación y métricas asignadas a un producto de trabajo registrado. Este elemento cubre
94
la actividad de asignar métricas de calidad y criterios de aceptación a los productos de trabajo agregados contenida en la fase de inicio.
Figura 19 Interfaz de gestión de métricas y criterios de aceptación de producto
5.1.3. Interfaz de evaluación de la configuración del proyecto En la Figura 20 y Figura 21, se muestran las interfaces para dos casos de verificación de
la configuración del proyecto, en la Figura 20, la configuración está incompleta y no se permite autorizar la configuración, mientras que en la Figura 21, se muestra la verificación de la configuración sin ningún conflicto. Este elemento cubre con la actividad de evaluar la aceptabilidad de la configuración de la herramienta contenida en la fase de inicio.
Figura 20 Interfaz de aprobación de la configuración incorrecta
95
Figura 21 Interfaz de aprobación de la configuración correcta
5.1.4. Interfaz de evaluación de criterios de producto En Figura 22, se muestra un ejemplo de la interfaz en la cual se evalúa el cumplimiento de
los criterios de aceptación registrados a un producto de trabajo. Esta tarea es común para cada producto de trabajo registrado. Cabe señalar que la herramienta está diseñada de tal manera que para cada producto de trabajo disponible en las fases de proyecto registradas. Este elemento cubre con la actividad de evaluar aceptabilidad del producto de trabajo contenida en las fases de análisis, evaluación, diseño, desarrollo, pruebas, liberación y cierre.
Figura 22 Interfaz de evaluación de criterios de aceptación de producto
5.1.5. Interfaz de validación de criterios de aceptación En la Figura 23, se muestra la interfaz en la cual el cliente valida el cumplimiento de los
criterios de aceptación asignados. Cabe resaltar que no todos los productos de trabajo requieren de validación, sólo aquellos que de acuerdo a las reglas de operación de la
96
herramienta lo indique. Este elemento cubre con la tarea de validación del producto de trabajo contenida en la actividad de evaluar aceptabilidad del producto de trabajo contenida en las fases de análisis, diseño, pruebas y liberación.
Figura 23 Interfaz de validación de criterios de aceptación
5.1.6. Interfaz de revisión de resultados de medición En Figura 24, se muestra la interfaz que permite observar la evolución del histórico de los
resultados de medición para cada métrica asignada a un producto de trabajo. Este elemento cubre con la actividad de mediciones al producto de trabajo, contenida en las fases de análisis, evaluación, diseño, desarrollo, pruebas y liberación.
97
Figura 24 Interfaz de revisión de resultados de medición
5.1.7. Interfaz de acciones correctivas en resultados de medición En Figura 25, se observa la interfaz que muestra el histórico de las acciones correctivas
registradas para los resultados de medición obtenidos en un producto. Este elemento cubre con la actividad de mediciones al producto de trabajo, contenida en las fases de análisis, evaluación, diseño, desarrollo, pruebas y liberación.
98
Figura 25 Interfaz de acciones correctivas en resultados de medición
5.2. Estudio de caso Un estudio de caso es un método empírico que investiga un fenómeno contemporáneo
dentro de su contexto real, especialmente cuando los límites entre el fenómeno y el contexto no son claramente evidentes (Yin, 2002).
El estudio de caso es adecuado para muchos tipos de investigación en Ingeniería de Software, debido a que los objetos de estudio son fenómenos contemporáneos que son difíciles de estudiar de forma aislada. Los estudios de caso proporcionan una comprensión más profunda de los fenómenos que se estudian en comparación a los experimentos controlados (Runeson & Höst, 2009).
La implementación de un estudio de caso consta de 5 pasos principales, los cuales se muestran a continuación (Runeson & Höst, 2009):
Figura 26 Pasos para implementar un estudio de caso
1.Diseñarelestudiodecaso 2.Prepararlarecogidadedatos
3.Recogerdatos 4.Analizarlosdatosrecogidos
5.Reportarlosresultados
99
En las siguientes secciones se muestran las actividades desarrolladas para cada paso para la implementación de los estudios de caso.
5.2.1. Diseño y planificación de los estudios de caso La planificación de un estudio de caso es crucial para que éste tenga éxito; por lo tanto, el
diseño y planificación de un estudio de caso debe contener los siguientes elementos:
• Objetivo - ¿Qué se quiere lograr?
• El objeto de estudio - ¿Qué es lo que se estudia?
• Teoría - Marco de referencia
• Preguntas de investigación - ¿Qué se quiere conocer?
• Métodos – ¿Cómo recoger los datos?
A continuación se muestra el diseño y planificación para un estudio de caso.
5.2.1.1. Objetivo del estudio de caso Evaluar el nivel en que las practicas de aseguramiento de la calidad contenidas en la
herramienta propuesta se integran a los entornos y prácticas de aseguramiento de la calidad en el desarrollo de software.
5.2.1.2. Objeto de estudio El estudio de caso se centra en el uso de la herramienta en 6 empresas de desarrollo de
software para la implementación de las actividades de aseguramiento de la calidad:
Tabla 22 Empresas para estudio de caso
NombreNúmero deencuestados Rol de encuestados Característica
Empresa B
4 Desarrolladore, tester, diseñadore y manager.
Centro académico para desarrollo de
software(UTEZ)
Empresa C
1 Manager. Centro académico de
desarrollo de software (Río Grande)
Empresa F
1 Desarrollador, tester, diseñador y análista.
Empresa dedicada al desarrollo de software
embebido, certificada en el estándar ISO/IEC 29110
(NOMADA)
100
Empresa E
4 Desarrolladores, análistas,
testers, arquitectos, gerentes de calidad.
Centro de investigación.
5.2.1.3. Marco de referencia En el entorno actual, el software juega un papel importante, ya que con este las empresas
dirigen sus esfuerzos. De acuerdo a un análisis realizado a los principales modelos de calidad, el cual se muestra en la sección 2.2, las actividades de verificación y validación juegan un papel crucial en el aseguramiento de la calidad del software. Es por ello, que se propone una herramienta que proporcione soporte para realizar 5 actividades principales para el aseguramiento de la calidad, las cuales son: (1) selección de elementos relevantes para el aseguramiento de la calidad; (2) asignación de criterios de aceptación a cada elemento; (3) selección de métricas de calidad relevantes, conforme a estándares de calidad de la organización; (4) seguimiento y control del proyecto y (5) verificación de la configuración.
5.2.1.4. Preguntas de investigación A continuación, se retoman las preguntas de investigación definidas en el Capitulo 2
sección 2.1.1.2, esto para identificar la trazabilidad entre las preguntas definidas en el caso de estudio y estas, de esta manera, se identifica si la propuesta realizada cubre la problemática inicial del presente estudio.
RQ1. ¿La herramienta facilita la gestión de la calidad en el desarrollo de software?
RQ2. ¿Las prácticas contenidas en la herramienta permiten implementar el aseguramiento de la calidad del producto?
RQ3. ¿Se mejora la identificación de defectos en los productos de software obtenidos?
5.2.1.5. Métodos para la recogida de datos El método elegido para la recogida de datos es el cuestionario, debido a que los
cuestionarios son formularios que los encuestados rellenan de manera individual, sin necesidad de entrevistarlos, y que además, se pueden analizar fácilmente. Para la creación de los cuestionarios se utiliza el software de encuestas Google Forms, ya que este software permite crear formularios y analizar los resultados de una forma rápida y gratuita.
5.2.2. Preparación de la recogida de datos La recogida de datos se realiza mediante la aplicación de una encuesta en la que se valida
la viabilidad de los elementos propuestos para el aseguramiento de la calidad y la interfaz de la herramienta.
101
A continuación la Tabla 23 muestra las preguntas de la encuesta, de las cuales las primeras 5 se enfocan en validar cada uno de los pasos del método para aligerar procesos, para cada pregunta de la encuesta se muestra su relación con las preguntas de investigación. La recolección de respuestas para las preguntas utiliza la escala Likert con los siguientes niveles de respuesta:
a) Totalmente en desacuerdo b) En desacuerdo c) Ni de acuerdo ni en desacuerdo d) De acuerdo e) Totalmente de acuerdo
Tabla 23 Preguntas de encuesta para estudio de caso
Preguntas respecto a elementos de aseguramiento de la calidad Preguntas de investigación
¿Considera que las fases disponibles son las adecuadas para una cobertura total de la metodología de desarrollo que realiza en su equipo de trabajo?
P2
¿Considera que los tipos de producto de trabajo disponibles son los suficientes para un aseguramiento de la calidad mínimo?
P2
¿Considera que las actividades de aseguramiento de la calidad que realiza se pudieron ajustar a la configuración de la herramienta?
P2
¿Considera que con las actividades realizadas se obtendrá una mejora en la prevención de defectos?
P3
Preguntas sobre la herramientaFacilidad de entendimiento: · Se reduce el esfuerzo para realizar acciones en pocos pasos. · El estado de la calidad se transmite forma clara y concisa. · La herramienta permite fácilmente al usuario identificar qué acciones debe llevar a cabo.
P1
Facilidad de uso: · Los usuarios realizan sus tareas correctamente en el menor tiempo posible. · Las tareas están diseñadas para realizarse de la forma más rápida e intuitiva posible.
P1
Satisfacción en uso: · Los resultados que obtendrías tras la interacción con la aplicación Web son los deseados. · La interfaz es amigable al usuario.
P1
5.2.3. Recogida de datos Para la recogida de datos en los casos de estudio se sigue el siguiente proceso:
1. Se realiza una reunión con una muestra de empleados de la empresa en la cual se les explica brevemente el funcionamiento de la herramienta y sus bases conceptuales mediante una presentación electrónica y un video demostrativo.
102
2. Se proporciona acceso a la herramienta al equipo de desarrollo.3. El equipo de desarrollo interactúa con la herramienta.4. EL equipo de desarrollo contesta la encuesta de validación diseñada en la sección
anterior.5. A partir de las respuestas de la encuesta obtenidas se realiza el análisis de datos, el cual se
describe en la siguiente sección.
5.2.4. Análisis de los datos recogidos En esta sección se realiza un análisis de los datos recogidos en las empresas que
participaron en los casos de estudio.
5.2.5. Reporte de resultados A continuación, se muestran y analizan los resultados para cada pregunta de la encuesta
de validación, se pidió a los encuestados indicar la experiencia laboral, los datos obtenidos se muestran en la Figura 27.
Figura 27 Experiencia de los encuestados
1) ¿Considera que las fases disponibles son las adecuadas para una cobertura total de la metodología de desarrollo que realiza en su equipo de trabajo?
A continuación, en la Figura 28 , se muestran los resultados para la pregunta 1 del estudio de caso.
103
Figura 28 Respuestas de la pregunta 1 del estudio de caso
En la figura anterior vemos que el 80% está de acuerdo que las fases disponibles son las adecuadas, mientras que un 20% está totalmente de acuerdo, por lo que se concluye que de manera general los participantes opinan que las fases se adecuan a su forma de trabajo.
2) ¿Considera que los tipos de producto de trabajo disponibles son los suficientes para un aseguramiento de la calidad mínimo?
A continuación, en la Figura 29 , se muestran los resultados para la pregunta 2 del estudio de caso.
104
Figura 28 Respuestas de la pregunta 2 del estudio de caso
En la figura anterior podemos observar que el 20% de los encuestados está totalmente deacuerdo que los productos de trabajo son suficientes para un mínimo aseguramiento de la calidad, mientras que el 70% está de acuerdo y el 10% no está seguro que los productos de trabajo propuestos no cubren todos los productos de trabajo criticos para el aseguramiento de la calidad, por lo que se concluye que de manera general la opinión es que los productos disponibles en la herramienta son suficientes en un entorno de aseguramiento de la calidad básico.
3) ¿Considera que las actividades de aseguramiento de la calidad que realiza se pudieron ajustar a la configuración de la herramienta?
A continuación, en la Figura 30, se muestran los resultados para la pregunta 3 del estudio de caso.
Figura 30 Respuestas de la pregunta 3 del estudio de caso
En la figura anterior podemos observar que el 10% está totalmente de acuerdo que las actividades que realiza para el aseguramiento de la calidad se pueden implementar utilizando la herramienta, mientras que el 50% está de acuerdo y el 40% opina que no todas las prácticas de asegurameinto de la calidad que realiza se pueden integrar en la herramienta, por lo que se concluye que de manera general los encuestados opinan que las prácticas que implementan se pueden incorporar en la herramienta.
4) ¿Considera que con las actividades realizadas se obtendrá una mejora en la prevención de defectos?
105
A continuación, en la Figura 31 , se muestran los resultados para la pregunta 4 del estudio de caso.
Figura 29 Respuestas de la pregunta 4 del estudio de caso
En la figura anterior podemos ver que el 80% de los encuestados opinó de manera positiva, mientras que el 20% no está seguro que con el uso de la herramienta se mejoren los resultados de calidad del producto, por lo que se concluye que la herramienta si ayudará en la reducción de los defectos.
5) ¿Se reduce el esfuerzo para realizar acciones en pocos pasos?
A continuación, en la Figura 32 , se muestran los resultados para la pregunta 5 del estudio de caso.
106
Figura 30 Respuestas de la pregunta 5 del estudio de caso
En la figura anterior podemos observar que el 60% de los encuestados está de acuerdo o totalmente de acuerdo respecto a si la herramienta reduce el esfuerzo para realizar las acciones de aseguramiento de la calidad en pocos pasos, mientras que el 40% opina que la implementación de la herramienta no implica una reducción en el esfuerzo del equipo para implementar actividades de aseguramiento de la calidad, por lo que podemos concluir que la interfaz de la herramienta es adecuada aunque aún puede realizarse mejoras para reducir tiempo y esfuerzo en la configuración de la herramienta.
6) ¿El estado de la calidad se transmite forma clara y concisa?
A continuación, en la Figura 33 , se muestran los resultados para la pregunta 6 del estudio de caso.
107
Figura 33 Respuestas de la pregunta 6 del estudio de caso
En la figura anterior podemos observar que el 70% opina de manera positiva que la herramienta transmite el estado de la calidad, mientras que el 30% no están seguros que la herramienta ayude en la visualización del estado de la calidad, por lo que se concluye que la herramienta ayuda en la difusión del estado de la calidad.
7) ¿La herramienta permite fácilmente al usuario identificar qué acciones debe llevar a cabo?
A continuación, en la Figura 34 , se muestran los resultados para la pregunta 7 del estudio de caso.
108
Figura 31 Respuestas de la pregunta 7 del estudio de caso
En la figura anterior observamos que el 20% de los encuestados está totalmente de acuerdo que la herramienta permite al usuario saber qué acciones debe realizar, mientras que el 50% está de acuerdo y el 30% no está seguro que la herramienta ayude a identificar que acciones debe de realizar para el aseguramiento de la calidad, por lo que se concluye que la herramienta ayuda a asignar actividades de aseguramiento de la calidad a los integrantes del equipo de desarrollo.
8) ¿Los usuarios realizan sus tareas correctamente en el menor tiempo posible?
A continuación, en la Figura 35 , se muestran los resultados para la pregunta 8 del estudio de caso.
Figura 32 Respuestas de la pregunta 8 del estudio de caso
En la figura anterior podemos observar que el 60% de los encuestados está de acuerdo que la herramienta permite a los usuarios realizar sus tareas rápido y correctamente, mientras que el 40% opina que con el uso de la herramienta no se reduce el tiempo en el que se realizan actividades de aseguramiento de la calidad, por lo que se concluye que la herramienta no representa una mejora significativa en la reducción del tiempo que se dedica al aseguramiento de la calidad.
9) ¿Las tareas están diseñadas para realizarse de la forma más rápida e intuitiva posible?
A continuación, en la Figura 36 , se muestran los resultados para la pregunta 9 del estudio de caso.
109
Figura 36 Respuestas de la pregunta 9 del estudio de caso
En la figura anterior podemos observar que el 90% de los encuestados está de acuerdo que las tareas para el aseguramiento de la calidad implementadas en la herramienta se realizan de la manera rápida e intuitiva, mientras que el 10% opina que la herramienta no permite identificar fácilmente las actividades a realizar, por lo que se concluye que con el uso de la herramienta los integrantes del equipo de desarrollo podrán saber que acciones deben de ejecutar con respecto al aseguramiento de la calidad.
10) ¿Los resultados que obtendrías tras la interacción con la aplicación Web son los deseados?
A continuación, en la Figura 37 , se muestran los resultados para la pregunta 10 del estudio de caso.
110
Figura 33 Respuestas de la pregunta 10 del estudio de caso
En la figura anterior podemos observar que el 80% de los encuestados está de acuerdo que los resultados de utilizar la herramienta son los deseados, mientras que el 20% opina que los resultados no fueron los esperados, por lo que se concluye que la implementación de la herramienta se obtendrá una mejora en el estado de la calidad de los productos de trabajo generados.
11) ¿La interfaz es amigable al usuario?
A continuación, en la Figura 38 , se muestran los resultados para la pregunta 11 del estudio de caso.
111
Figura 34 Respuestas de la pregunta 11 del estudio de caso
En la figura anterior podemos ver que el 80% de los encuestados opina que la interfaz de la herramienta es amigable al usuario, mientras que el 20% opinó que la interfaz se no es amigable al usuario, por lo que se concluye que de manera general opinan que la interfaz de la herramienta es amigable.
112
Capítulo 6. Conclusiones En este capítulo se presentan las conclusiones obtenidas. Además, se presenta el trabajo
futuro derivado de este tema de investigación, y por último, se abordan los productos académicos de esta investigación.
6.1. Conclusiones Como se observa en los resultados de la revisión sistemática de la literatura, las prácticas
de aseguramiento de la calidad más comunes están orientadas a la ejecución de análisis estático y dinámico de código. Respecto a las herramientas para el aseguramiento de la calidad encontradas, se pudo observar que están enfocadas en la integración de código fuente y a la optimización de pruebas de software.
Por otra parte, a partir de problemas identificados, se realizó una propuesta de clasificación de los mismos, los resultados de la clasificación mostraron que los defectos más recurrentes son los defectos menores, entre los que se encuentran: errores en documentación, desviación del estándar de código, defectos de interfaz de usuario, etc. Aunque ese tipo de defectos de manera individual obtienen bajos índices, en la clasificación propuesta representan el 44.37%, lo que indica que este tipo de defectos son poco atendidos, y esto puede ser grave a largo plazo para un sistema de software, ya que este tipo de defectos tiende a convertirse un defecto mayor u ocasionar un defecto crítico.
A partir del estudio de caso se concluye que la herramienta se adapta a la metodología de trabajo y contiene los productos de trabajo para un entorno mínimo de aseguramiento de la calidad, además de ayudar a transmitir el estado actual de la calidad y en la prevención de defectos, impactando en la calidad final de los productos de software, sin embargo se encontró que no se adapta a todas las prácticas de aseguramiento de la calidad que implementan los desarrolladores de software encuestados.
6.2. Trabajo futuro Como trabajo futuro, se planea incrementar la funcionalidad de la herramienta, mediante
el análisis de cobertura de atributos de calidad mediante las métricas de calidad seleccionadas por el usuario. Esta funcionalidad permitirá apoyar al gerente de calidad a seleccionar métricas de calidad alineadas a sus objetivos de negocio.
Otra mejora para la herramienta propuesta, es incrementar la interoperabilidad de la herramienta propuesta con herramientas externas, esta funcionalidad permitirá la automatización de tareas de aseguramiento de la calidad, por ejemplo, la integración de herramientas para la recolección automática de métricas de calidad como Jenkins, GitHub o
113
GitLab. Además de la integración de herramientas de gestión de proyectos para unificar los entornos de desarrollo como Jira o Trello.
6.3. Logros académicos A continuación se muestran los logros académicos obtenidos a partir de la presente
investigación.
6.3.1. Productos académicos Cómo resultados académicos realizamos la publicación de dos artículos, los cuales son:
1. Munoz M, Mejia J, Ibarra S. Tools and practices to software quality assurance: A systematic literature review. In: 2018 13th Iberian Conference on Information Systems and Technologies (CISTI). IEEE; 2018:1-6. doi:10.23919/CISTI.2018.8399334
2. Ibarra S, Muñoz M. software Software quality assurance on software development. 2018, in press.
114
Referencias Almakadmeh, K., Abu-Zitoon, F., & Student, M. (2015). A Generic Model-Based Methodology of Testing Techniques to Obtain High Quality Software. https://doi.org/10.1145/2816839.2816903
Anand, R., David, K., & Sagayaraj, S. S. (2015). Identifying the impact of defects among the defect types in Software development projects. In 2015 International Conference on Smart Technologies and Management for Computing, Communication, Controls, Energy and Materials (ICSTM) (pp. 146–152). IEEE. https://doi.org/10.1109/ICSTM.2015.7225404
Beltr, N. O., & Le, G. C. (2011). Gestión de calidad en desarrollo de software, 8(1), 65–69.
Brady, A., & Menzies, T. (2010). Case-based reasoning vs parametric models for software quality optimization. In Proceedings of the 6th International Conference on Predictive Models in Software Engineering - PROMISE ’10 (p. 1). New York, New York, USA: ACM Press. https://doi.org/10.1145/1868328.1868333
Budgen, D., & Pearl Brereton, durhamacuk. (2006). Performing Systematic Literature Reviews in Software Engineering. Retrieved from http://delivery.acm.org.svproxy01.cimat.mx/10.1145/1140000/1134500/p1051-budgen.pdf?ip=148.235.65.253&id=1134500&acc=ACTIVE SERVICE&key=6F4CCF05E2930152.3A406A232738A87B.4D4702B0C3E38B35.4D4702B0C3E38B35&__acm__=1527395053_1b5d1e858999dc5c754ea107
Catelani, M., Ciani, L., Scarano, V. L., & Bacioccola, A. (2011). Software automated testing: A solution to maximize the test plan coverage and to increase software reliability and quality in use. Computer Standards & Interfaces, 33(2), 152–158. https://doi.org/10.1016/j.csi.2010.06.006
Corral, L., & Luis. (2012). Using software quality standards to assure the quality of the mobile software product. In Proceedings of the 3rd annual conference on Systems, programming, and applications: software for humanity - SPLASH ’12 (p. 37). New York, New York, USA: ACM Press. https://doi.org/10.1145/2384716.2384734
Deshpande, B., Rao, J. J., & Suma, V. (2015). Comprehension of Defect Pattern at Code Construction Phase during Software Development Process (pp. 659–666). https://doi.org/10.1007/978-3-319-12012-6_73
Friginal, Jesus,de Andrés, David, Ruiz, J.-C. (2011). Using Dependability Benchmarks to Support ISO/IEC SQuaRE. https://doi.org/10.1109/PRDC.2011.13
115
Gleirscher, M., Golubitskiy, D., Irlbeck, M., & Wagner, S. (2014). Introduction of static quality analysis in small- and medium-sized software enterprises: experiences from technology transfer. Software Quality Journal, 22(3), 499–542. https://doi.org/10.1007/s11219-013-9217-z
Goeb, A., & Lochmann, K. (2011). A software quality model for SOA. In Proceedings of the 8th international workshop on Software quality - WoSQ ’11 (p. 18). New York, New York, USA: ACM Press. https://doi.org/10.1145/2024587.2024593
Gupta, N., Singh, D., & Sharma, A. (2015). Identifying Effective Software Metrics for Categorical Defect Prediction Using Structural Equation Modeling. In Proceedings of the Third International Symposium on Women in Computing and Informatics - WCI ’15 (pp. 59–65). New York, New York, USA: ACM Press. https://doi.org/10.1145/2791405.2791484
Gupta, S., Singh, H. K., Venkatasubramanyam, R. D., & Uppili, U. (2014). SCQAM: a scalable structured code quality assessment method for industrial software. In Proceedings of the 22nd International Conference on Program Comprehension - ICPC 2014 (pp. 244–252). New York, New York, USA: ACM Press. https://doi.org/10.1145/2597008.2597806
Hale, D. P., Hale, J. E., & Smith, R. K. (2011). Evaluation of work product defects during corrective & enhancive software evolution. ACM SIGMIS Database, 42(1), 59. https://doi.org/10.1145/1952712.1952716
Heinemann, L., Hummel, B., & Steidl, D. (2014). Teamscale: software quality control in real-time. In Companion Proceedings of the 36th International Conference on Software Engineering - ICSE Companion 2014 (pp. 592–595). New York, New York, USA: ACM Press. https://doi.org/10.1145/2591062.2591068
Hernández, R., Fernández, C., & Baptista, P. (2014). Metodología de la investigación. (M.-H. / I. EDITORES, Ed.), Journal of Chemical Information and Modeling (6th ed., Vol. 53). México. https://doi.org/10.1017/CBO9781107415324.004
Holl, K., & Elberzhager, F. (2017). Guiding Quality Assurance for Mobile Applications with FIT4Apps — A Two-Step Evaluation. In 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA) (pp. 435–439). IEEE. https://doi.org/10.1109/SEAA.2017.12
Ibarra, S., & Muñoz, M. (2018). software Software quality assurance on software development.
116
IEEE/IEC. (2016). ISO/IEC TR 29110 (Vol. 2016). Switzeland. Retrieved from http://standards.iso.org/ittf/PubliclyAvailableStandards/c060389_ISO_IEC_TR_29110-5-1-1_2012(E).zip
ISO. (2006). International Standard ISO / IEC 15504, 2006, 1–170.
ISO 9000:2005(es), Sistemas de gestión de la calidad — Fundamentos y vocabulario. (2005). Retrieved July 4, 2018, from https://www.iso.org/obp/ui/#iso:std:iso:9000:ed-3:v1:es
Jain, R. S., & Gupta, A. (2011). Refinement of the Test Bed Using Various Prioritization Techniques for Assuring Software-Quality (pp. 657–661). Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-25734-6_113
Janicijevic, I., Krsmanovic, M., Zivkovic, N., & Lazarevic, S. (2016). Software quality improvement: a model based on managing factors impacting software quality. Software Quality Journal, 24(2), 247–270. https://doi.org/10.1007/s11219-014-9257-z
Janus, A., Dumke, R., Schmietendorf, A., & Jäger, J. (2012). The 3C Approach for Agile Quality Assurance. Retrieved from http://delivery.acm.org.svproxy01.cimat.mx/10.1145/2670000/2669382/p9-janus.pdf?ip=148.235.65.253&id=2669382&acc=ACTIVE SERVICE&key=6F4CCF05E2930152.3A406A232738A87B.4D4702B0C3E38B35.4D4702B0C3E38B35&CFID=777674939&CFTOKEN=49488839&__acm__=1499990755_ecb3c5e1af2857bbb3e74dc1c925c2b1
Juran, J. M., Godfrey, a B., Hoogstoel, R. E., & Schilling, E. G. (1999). Juran ’ S Quality Handbook. (J. M. Juran, Ed.), Training for Quality (Sixth, Vol. 1). Mc Graw Hill. https://doi.org/10.1007/s00268-011-1084-9
Kan, S. H., & H., S. (2003). Metrics and models in software quality engineering. Addison-Wesley. Retrieved from https://dl.acm.org/citation.cfm?id=559784#
Khoshgoftaar, T. M., Xiao, Y., & Gao, K. (2014). Software quality assessment using a multi-strategy classifier. Information Sciences, 259, 555–570. https://doi.org/10.1016/j.ins.2010.11.028
Kothapalli, C., Ganesh, S., Singh, H. K., Ravikanth, K., Gupta, S., & Rao, K. (2011). Continual Monitoring of Code Quality. Retrieved from http://delivery.acm.org.svproxy01.cimat.mx/10.1145/1960000/1953379/p175-kothapalli.pdf?ip=148.235.65.253&id=1953379&acc=ACTIVE SERVICE&key=6F4CCF05E2930152.3A406A232738A87B.4D4702B0C3E38B35.4D4702B0C3E38B35&CFID=777674939&CFTOKEN=49488839&__acm__=
117
Lin, L., He, J., Zhang, Y., & Song, F. (2015). Quality Assurance through Rigorous Software Specification and Testing: A Case Study. Procedia Computer Science, 62, 257–265. https://doi.org/10.1016/j.procs.2015.08.448
Lochmann, K., & Heinemann, L. (2011). Integrating quality models and static analysis for comprehensive quality assessment. In Proceeding of the 2nd international workshop on Emerging trends in software metrics - WETSoM ’11 (p. 5). New York, New York, USA: ACM Press. https://doi.org/10.1145/1985374.1985378
Mathrani, A. (2014). Quality assurance strategy for distributed software development using managed test lab model. In 2014 IEEE International Technology Management Conference (pp. 1–4). IEEE. https://doi.org/10.1109/ITMC.2014.6918609
McGrath, S., Walz, J., Rakitin, S., Blaine, D., & Frank, B. (2014). IEEE Standard for Software Quality Assurance Processes. IEEE, 1–138. https://doi.org/10.1109/IEEESTD.2014.6835311
McIntosh, S., Kamei, Y., Adams, B., & Hassan, A. E. (2016). An empirical study of the impact of modern code review practices on software quality. Empirical Software Engineering, 21(5), 2146–2189. https://doi.org/10.1007/s10664-015-9381-9
Munoz, M., Mejia, J., & Ibarra, S. (2018). Tools and practices to software quality assurance: A systematic literature review. In 2018 13th Iberian Conference on Information Systems and Technologies (CISTI) (pp. 1–6). IEEE. https://doi.org/10.23919/CISTI.2018.8399334
Oktaba, H., Alquicira, C., Ramos, A., Martínez, A., Quintanilla, G., Ruvalcaba, M., … Flores, M. (1994). Modelo de Procesos para la Industria del Software, 1, 121. Retrieved from https://www.uv.mx/rrojano/MIS/desarrollo1/material/moprosoft-v1.1.pdf
Öztürk, M. M., CİL, İ., & Zengin, A. (2015). Development of a Multi-Agent Framework for Software Quality. ACM SIGSOFT Software Engineering Notes, 40(1), 1–10. https://doi.org/10.1145/2693208.2693234
Paschalidou, G., Stiakakis, E., & Chatzigeorgiou, A. (2013). An application of data envelopment analysis to software quality assessment. In Proceedings of the 6th Balkan Conference in Informatics on - BCI ’13 (p. 228). New York, New York, USA: ACM Press. https://doi.org/10.1145/2490257.2490264
Pizzi, N. J. (2013). A fuzzy classifier approach to estimating software quality. Information Sciences, 241, 1–11. https://doi.org/10.1016/j.ins.2013.04.027
Project Management Institute. (2013). GUÍA DE LOS FUNDAMENTOS PARA LA DIRECCIÓN DE PROYECTOS (GUÍA DEL PMBOK®). (Project Management Institute,
118
Ed.) (Quinta). Pensilvania, EE.UU.: Project Management Institute. Retrieved from https://www.pmi.org/pmbok-guide-standards/foundational/pmbok
R. Rebolledo. (2017). Las 20 mejores empresas del mundo en el 2017 | El Economista. Retrieved February 9, 2018, from https://www.eleconomista.com.mx/empresas/Las-20-mejores-empresas-del-mundo-en-el-2017-20170628-0113.html
Rahmani, H., Sami, A., & Khalili, A. (2016). CIP-UQIM: A unified model for quality improvement in software SME’s based on CMMI level 2 and 3. Information and Software Technology, 71, 27–57. https://doi.org/10.1016/j.infsof.2015.10.009
Runeson, P., & Höst, M. (2009). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14(2), 131–164. https://doi.org/10.1007/s10664-008-9102-8
Sandric, B., & Jurcevic, M. (2018). Metrology and quality assurance in internet of things. In 2018 First International Colloquium on Smart Grid Metrology (SmaGriMet) (pp. 1–6). IEEE. https://doi.org/10.23919/SMAGRIMET.2018.8369849
Selleri Silva, F., Soares, F. S. F., Peres, A. L., Azevedo, I. M. de, Vasconcelos, A. P. L. F., Kamei, F. K., & Meira, S. R. de L. (2015). Using CMMI together with agile software development: A systematic review. Information and Software Technology, 58, 20–43. https://doi.org/10.1016/j.infsof.2014.09.012
Seth, F. P., Mustonen-Ollila, E., Taipale, O., & Smolander, K. (2015). Software quality construction in 11 companies: an empirical study using the grounded theory. Software Quality Journal, 23(4), 627–660. https://doi.org/10.1007/s11219-014-9246-2
Software Engineering Institute. (2010). CMMI ® DEV V. 1.3. Retrieved from http://www.sei.cmu.edu
Suali, A. J., Fauzi, S. S. M., Sobri, W. A. W. M., & Nasir, M. H. N. M. (2017). Developers’ coordination issues and its impact on software quality: A systematic review. In 2017 3rd International Conference on Science in Information Technology (ICSITech) (pp. 659–663). IEEE. https://doi.org/10.1109/ICSITech.2017.8257195
The Standish Group International. (2016). CHAOS REPORT 2016 THE WINNING HAND.
TIOBE Index | TIOBE - The Software Quality Company. (n.d.). Retrieved November 27, 2017, from https://www.tiobe.com/tiobe-index/
119
Winkler, D., Biffl, S., & Faderl, K. (2010). Investigating the Temporal Behavior of Defect Detection in Software Inspection and Inspection-Based Testing (pp. 17–31). Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-13792-1_4
Yazbek, H., & Hashem. (2010). A concept of quality assurance for metrics in CASE-tools. ACM SIGSOFT Software Engineering Notes, 35(5), 1. https://doi.org/10.1145/1838687.1838711
Yin, R. (2009). Case Study Research. ETHNOGRAPHY (4th ed., Vol. 5). SAGE. Retrieved from http://cemusstudent.se/wp-content/uploads/2012/02/YIN_K_ROBERT-1.pdf
Zaytsev, Y. V., & Morrison, A. (2013). Increasing quality and managing complexity in neuroinformatics software development with continuous integration. Frontiers in Neuroinformatics, 6, 31. https://doi.org/10.3389/fninf.2012.00031
Zhang, P., Zhou, X., Li, W., & Gao, J. (2017). A Survey on Quality Assurance Techniques for Big Data Applications. In 2017 IEEE Third International Conference on Big Data Computing Service and Applications (BigDataService) (pp. 313–319). IEEE. https://doi.org/10.1109/BigDataService.2017.42
