modelo para la medición del progreso del alfa sistema de

Modelo para la medición del progreso del alfa sistema de

software del núcleo de Semat con base en las normas ISO/IEC 2502n e

ISO/IEC 2504n

Wilder Perdomo Charry

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Ciencias de la Computación y la Decisión

Medellín, Colombia

2019

Modelo para la medición del progreso del alfa sistema de

software del núcleo de Semat con base en las normas ISO/IEC 2502n e

ISO/IEC 2504n

Wilder Perdomo Charry

Tesis de investigación presentada como requisito para optar al título de:

PhD en Ingeniería—Sistemas e Informática

Director:

Ph.D. Carlos Mario Zapata Jaramillo

Línea de Investigación:

Ingeniería de Sistemas

Grupo de Investigación:

Lenguajes Computacionales

Universidad Nacional de Colombia

Facultad de Minas, Departamento de Ciencias de la Computación y la Decisión

Medellín, Colombia

2019

Dedicatoria

A Dios que está presente en todo lugar, momento y circunstancia, y quien siempre

me acompaña en el camino de la vida.

A mi madre, mi padre y Maria Alejandra, quienes son prueba de amor, persistencia

y unión familiar. Criterios fundamentales para alcanzar un sueño.

Wilder P.

Agradecimientos Esta tesis no había sido posible desarrollarla sin el soporte de personas e instituciones quienes han contribuido de diferentes maneras. Deseo expresar mi mayor agradecimiento a mi tutor, Carlos Mario Zapata Jaramillo, quien a lo largo de estos años me ha brindado asesoría, soporte y entendimiento en todo el proceso de investigación. Cada palabra y enseñanza son muy valiosas para mi crecimiento personal y profesional y siempre le estaré muy agradecido. Gracias a la Universidad Nacional de Colombia, sede Medellín, especialmente al Departamento de Ciencias de la Computación y la Decisión, quienes apoyaron mis dos primeros años de estudios doctorales con la beca de la Facultad de Minas. Un agradecimiento especial también para la Universidad de San Buenaventura, sede Medellín, quienes permitieron que durante mi horario laboral como profesor e investigador dedicara parte de mi tiempo al desarrollo inicial del proyecto de investigación. Agradezco el apoyo brindado por la empresa ECConnect con sede en Sídney, Australia, quienes aportaron significativamente con la validación del modelo propuesto en esta Tesis Doctoral, en especial a los cinco participantes, quienes gracias a sus conocimientos y experiencia en la industria lograron entender el objetivo del proyecto, validar las medidas propuestas, su relación con el alfa sistema de software del núcleo de Semat y con la ejecución del modelo en un caso práctico. A mis compañeros de Doctorado, Claudia Elena Durango Vanegas, Diana María Torres Ricaurte y Alexander Barón Salazar por sus contribuciones, experiencia y apoyo durante nuestro proceso de formación. Además, a mis amigos cercanos Juan Camilo Giraldo y Mauricio Amariles con quienes compartimos experiencias y conocimientos en ingeniería e investigación. Finalmente, es mi privilegio agradecer a mi esposa y compañera de vida, quien me brindó su apoyo incondicional, su experiencia y conocimiento para encausar esta meta que siempre hemos considerado ‘nuestra’. Gracias, por tanto. Siempre he pensado que trabajar en equipo, con visión y persistencia nos ayuda a avanzar y lograr grandes metas.

Resumen y Abstract IX

Resumen

Semat es una iniciativa desarrollada para refundar la ingeniería de software como una disciplina rigurosa basada en una teoría sólida, principios probados y mejores prácticas. La norma ISO/IEC 25000 (SQuaRE) es un estándar internacional que permite evaluar la calidad del producto de software, sustituyendo a las normas ISO/IEC 9126 e ISO/IEC 14598. En algunos estudios se relacionan implícitamente las características y métricas de la calidad de las normas ISO/IEC 9126 e ISO/IEC 25000 con los estados del alfa sistema de software del núcleo de Semat. En otros proyectos se muestra una relación esquemática entre las características, sub-características y medidas de calidad de las normas ISO/IEC 9126 e ISO/IEC 25000 y los estados de los alfas, pero no existe relación explicita entre las características y medidas con cada uno de los estados del alfa sistema de software del núcleo de la Esencia de Semat. Teniendo como base estos hallazgos, en esta Tesis de Doctorado se plantea la elaboración de un modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n. La propuesta se centra en la selección de las medidas adecuadas de los estados del alfa sistema de software para estructurar las relaciones entre ellos, validando su aplicación usando la metodología de caso de estudio con una empresa desarrolladora de software y desarrollando un modelo para la medición de la calidad del producto. Los resultados son prometedores, ya que se puede usar para establecer un modelo coherente y estructural para evaluar la salud y el progreso del alfa sistema de software en un esfuerzo en ingeniería de software. Palabras clave: Semat, Calidad de software, ISO/IEC 25000, Sistema de software, Medición, Evaluación.

X Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n

Abstract

Semat is an initiative developed for refounding the software engineering by defining a theoretical basis, best practices, and a set of widely-agreed elements. ISO/IEC 25000 (System and Software Quality Requirements and Evaluation-SQuaRE) is an international standard, which allows for evaluating the software product quality. ISO 25000 replaces ISO/IEC 9126 and ISO/IEC 14598 standards. Quality characteristics and measures of ISO/IEC 25000 and ISO/IEC 9126 standards are implicitly related to software system states of the Semat kernel in some studies. In other projects, a schematic relationship between ISO/IEC 9126 and ISO/IEC 25000 quality characteristics, sub-characteristics and measures is shown, but they lack explicit relationship between measures and characteristics with each one of the software system states of the Semat Essence. According to the aforementioned findings, in this PhD thesis we propose the development of a model for measuring software system alpha progress based on the ISO/IEC 2502n and the ISO/IEC 2504n standards. This PhD thesis is focused on the selection of the appropriate measures of the software system states in order to structure the relationships between them, validating them by using a case study methodology related to a software development company, and developing a model for product quality measurement. The results are promising since we can use them to establish a coherent and structural model for evaluating health and progress of the software system alpha of a software engineering endeavour. Keywords: Semat, Software quality, ISO/IEC 25000, Software system, Measurement, Evaluation.

Contenido XI

Contenido

Pág.

Resumen ........................................................................................................................ IX

Abstract........................................................................................................................... X

Lista de figuras ............................................................................................................ XIII

Lista de tablas .............................................................................................................. XV

Lista de Símbolos y abreviaturas .............................................................................. XVII

Introducción .................................................................................................................... 1

1. Marco teórico ............................................................................................................... 3 1.1. Teoría y método de la ingeniería de software–Semat ......................................... 3 1.1.1. Áreas de interés.............................................................................................. 3 1.1.2. Alfas del núcleo de Semat .............................................................................. 4 1.1.3. Elementos del núcleo de Semat ..................................................................... 6 1.2. ISO/IEC 25000 ................................................................................................... 7 1.2.1. Estándar ISO/IEC 2502n ................................................................................ 9 1.2.2. Estándar ISO/IEC 2504n .............................................................................. 10

2. Antecedentes ............................................................................................................. 13 2.1. Modelos de evaluación de la calidad del software basados en la norma ISO/IEC 9126 e ISO/IEC 25000 ................................................................................................ 16 2.2. Relación entre la norma ISO/IEC 9126 y el núcleo Semat ................................ 25

3. Planteamiento del problema ..................................................................................... 30 3.1. Descripción del problema ................................................................................. 30 3.2. Objetivos .......................................................................................................... 31

3.2.1. Objetivo General ............................................................................................ 31 3.2.2. Objetivos específicos ..................................................................................... 31

4. Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat ............................................................................................................................. 33

4.1. Selección de las medidas apropiadas de la norma ISO/IEC 2502n .................. 33 4.2. Relación de las medidas seleccionadas de la ISO/IEC 2502n con los estados del alfa sistema de software ............................................................................................. 39 4.2.1. Medidas de la calidad en uso (ISO/IEC 25022) relacionadas con los estados del alfa ..................................................................................................................... 39

XII Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n

4.2.2. Medidas de la calidad del producto (ISO/IEC 25023) relacionadas con los estados del alfa ........................................................................................................... 44 4.2.3. Medidas de la calidad del dato (ISO/IEC 25024) relacionadas con los estados del alfa ...................................................................................................................... 55 4.3. Representación en el núcleo de Semat del alfa sistema de software y de las medidas identificadas en la ISO/IEC 2502n ................................................................. 65 4.4. Modelo final en esquemas preconceptuales ..................................................... 71

5. Caso de estudio ........................................................................................................ 76 5.1. Evaluación del modelo para la medición del progreso del alfa sistema de software del núcleo de Semat ..................................................................................... 76 5.2. Validación del modelo propuesto ...................................................................... 88 5.2.1. Medidas que aprueban los participantes ....................................................... 90 5.2.2. Amenazas a la validez ................................................................................... 94 5.2.3. Esquema preconceptual ejecutable validado con la medida consistencia operacional .................................................................................................................. 94

6. Conclusiones y trabajo futuro .................................................................................. 97 6.1. Conclusiones .................................................................................................... 97 6.2. Trabajo Futuro .................................................................................................. 98

Referencias ................................................................................................................... 99

Contenido XIII

Lista de figuras

Pág. Figura 1. Arquitectura del núcleo de Semat (OMG, 2014)................................................ 3 Figura 2. Alfas del núcleo de Semat (OMG, 2014). .......................................................... 4 Figura 3. Alfas y sus estados, núcleo de Semat (Jacobson et al., 2013). ........................ 5 Figura 4. Alfa sistema de software y sus estados (Jacobson et al., 2013). ...................... 5 Figura 5. Vista conceptual del lenguaje (OMG, 2014). ..................................................... 6 Figura 6. Organización del estándar internacional—SQuaRE (ISO/IEC, 2014)................ 8 Figura 7. Marco general del proceso de evaluación de la calidad del producto (ISO/IEC, 2011). ............................................................................................................................. 10 Figura 8. Metodología de vigilancia tecnológica e inteligencia competitiva (Palop & Vicente, 1999; ERICA, 2012). ......................................................................................... 13 Figura 9. Relación de atributos contemplados en KEMIS (Marcos et al., 2008). ............ 17 Figura 10. Evaluación de la calidad de productos de software libre disponibles en la web (Marcos et al., 2008)....................................................................................................... 17 Figura 11. Factores de usabilidad del modelo jerárquico (Heo et al., 2009). .................. 18 Figura 12. Proyecto MEDUSAS (Mellado et al., 2010). .................................................. 19 Figura 13. Métricas de reutilización del diseño (Bougroun et al., 2012). ........................ 20 Figura 14. Clasificación agregada por la importancia del aspecto de calidad (Lampasona et al., 2012). ................................................................................................................... 21 Figura 15. Modelo de calidad en uso para la interfaz de usuarios móviles (Alnanih et al., 2013). ............................................................................................................................. 22 Figura 16. Impacto de los requisitos en las características externas (Idri et al., 2015). .. 23 Figura 17. Esquema de evaluación de confiabilidad (Febrero et al., 2016). ................... 24 Figura 18. Herramienta tecnológica para evaluar la calidad (Rodríguez et al., 2016)..... 24 Figura 19. Resultados de las evaluaciones (Rodríguez et al., 2016). ............................. 25 Figura 20. Cartas empleadas en el juego MetriCC (Zapata et al., 2013). ....................... 26 Figura 21. Relación usabilidad, estados del alfa sistema de software (Perdomo & Zapata, 2015). ............................................................................................................................. 26 Figura 22. Relación de métricas de la característica usabilidad con los estados del alfa sistema de software (Perdomo & Zapata, 2015). ............................................................ 27 Figura 23. Pasos para la selección de las medidas apropiadas (Los autores). .............. 33 Figura 24. Representación Semat de (a) medición de la calidad basada en estándares del estado con arquitectura seleccionada (Los autores). ................................................ 66

XIV Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n

Figura 25. Representación Semat de (a) medición de la calidad basada en estándares del estado demostrable (Los autores). ............................................................................ 67 Figura 26. Representación Semat de (a) medición de la calidad basada en estándares del estado usable (Los autores). ..................................................................................... 68 Figura 27. Representación Semat de (a) medición de la calidad basada en estándares del estado listo (Los autores) .......................................................................................... 69 Figura 28. Representación Semat de (a) medición de la calidad basada en estándares del estado operacional (Los autores). ............................................................................. 70 Figura 29. Representación Semat de (a) medición de la calidad basada en estándares del estado retirado (Los autores). ................................................................................... 71 Figura 30. Modelo para la medición del progreso del alfa del núcleo de Semat (Los autores)........................................................................................................................... 72 Figura 31. Relaciones entre conceptos (Los autores). .................................................... 74 Figura 32. Esquema preconceptual ejecutable representando la medida corrección de error de entrada de usuario de la característica usabilidad (Los autores). ....................... 75 Figura 33. Método GQM (Basili et al., 2007). ................................................................. 77 Figura 34. Consentimiento informado (Los autores). ...................................................... 78 Figura 35. Carta de participación (Los autores). ............................................................. 79 Figura 36. Entrevista (Los autores). ............................................................................... 79 Figura 37. Esquema preconceptual ejecutable que los participantes validan (Los autores)........................................................................................................................... 95

Contenido XV

Lista de tablas

Pág.

Tabla 1. Elementos gráficos del núcleo de Semat (OMG, 2014). ..................................... 6 Tabla 2. Características y sub-características de calidad del producto del sistema y software (ISO/IEC, 2016). ................................................................................................ 8 Tabla 3. Estructura de la medida de calidad (ISO/IEC, 2016). ......................................... 9 Tabla 4. Factores Críticos de Vigilancia—FCV (adapatada de Palop & Vicente, 1999). . 14 Tabla 5. Bitácora de búsqueda (adapatada de Palop & Vicente, 1999). ......................... 14 Tabla 6. Priorización de la información (Los autores). .................................................... 15 Tabla 7. Síntesis de estudios analizados en relación con los problemas identificados (Los autores). ......................................................................................................................... 28 Tabla 8. Lista de chequeo de los estados del alfa sistema de software (Jacobson et al., 2013). ............................................................................................................................. 34 Tabla 9. Cantidad de medidas seleccionadas por característica (Elaboración propia con base en ISO/IEC, 2014; ISO/IEC, 2016). ........................................................................ 36 Tabla 10. Medidas de calidad en uso seleccionadas (Los autores; ISO/IEC 2016). ....... 36 Tabla 11. Medidas de calidad del producto de software seleccionadas (Los autores; ISO/IEC 2016). ............................................................................................................... 37 Tabla 12. Medidas de calidad del dato seleccionadas (Los autores; ISO/IEC 2016). ..... 38 Tabla 13. Descripción numérica entre los estados del alfa y las medidas seleccionadas (Elaboración propia con base en Jacobson et al., 2013; ISO/IEC, 2014; ISO/IEC, 2016). ....................................................................................................................................... 39 Tabla 14. Relación de los estados del alfa sistema de software con las medidas de la calidad en uso (Los autores). ......................................................................................... 40 Tabla 15. Función de medición de la calidad en uso para el estado demostrable (Elaboración propia con base en ISO/IEC 2016). ........................................................... 41 Tabla 16. Función de medición de la calidad en uso para el estado usable (Elaboración propia con base en ISO/IEC 2016). ................................................................................ 41 Tabla 17. Función de medición de la calidad en uso para el estado listo (Elaboración propia con base en ISO/IEC 2016). ................................................................................ 42 Tabla 18. Función de medición de la calidad en uso para el estado operacional (Elaboración propia con base en ISO/IEC 2016). ........................................................... 43 Tabla 19. Relación de los estados del alfa sistema de software con las medidas de la calidad del producto (Los autores).................................................................................. 44

XVI Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n

Tabla 20. Función de medición de la calidad del producto para el estado con arquitectura seleccionada (Elaboración propia con base en ISO/IEC 2016). ...................................... 47 Tabla 21. Función de medición de la calidad del producto para el estado demostrable (Elaboración propia con base en ISO/IEC 2016). ............................................................ 48 Tabla 22. Función de medición de la calidad del producto para el estado usable (Elaboración propia con base en ISO/IEC 2016). ............................................................ 49 Tabla 23. Función de medición de la calidad del producto para el estado listo (Elaboración propia con base en ISO/IEC 2016). ............................................................ 51 Tabla 24. Función de medición de la calidad del producto para el estado operacional (Elaboración propia con base en ISO/IEC 2016). ............................................................ 52 Tabla 25. Función de medición de la calidad del producto para el estado retirado (Elaboración propia con base en ISO/IEC 2016). ............................................................ 54 Tabla 26. Relación de los estados del alfa sistema de software con las medidas de la calidad del dato (Los autores). ........................................................................................ 55 Tabla 27. Función de medición de la calidad del dato para el estado con arquitectura seleccionada (Elaboración propia con base en ISO/IEC 2016). ...................................... 57 Tabla 28. Función de medición de la calidad del dato para el estado demostrable (Elaboración propia con base en ISO/IEC 2016). ............................................................ 57 Tabla 29. Función de medición de la calidad del dato para el estado usable (Elaboración propia con base en ISO/IEC 2016). ................................................................................. 59 Tabla 30. Función de medición de la calidad del dato para el estado listo (Elaboración propia con base en ISO/IEC 2016). ................................................................................. 62 Tabla 31. Función de medición de la calidad del dato para el estado operacional (Elaboración propia con base en ISO/IEC 2016). ............................................................ 63 Tabla 32. Función de medición de la calidad del dato para el estado retirado (Elaboración propia con base en ISO/IEC 2016). ................................................................................. 64 Tabla 33. Protocolo del estudio de caso según Maimbo y Pervan (2005) ....................... 78 Tabla 34. Elementos de la entrevista (Los autores) ........................................................ 80 Tabla 35. Cantidad de medidas a validar mediante el caso de estudio (Los autores). .... 87 Tabla 36. Perfil de los participantes en el estudio de caso (Los autores) ........................ 89 Tabla 37. Resultado del análisis de datos (Los autores) ................................................. 90 Tabla 38. Medidas que los participantes aceptan (Los autores) ..................................... 90 Tabla 39. Medidas que los participantes no aceptan (Los autores)................................. 91 Tabla 40. Amenazas a la validez (Los autores) .............................................................. 94

Contenido XVII

Lista de Símbolos y abreviaturas

Abreviaturas Abreviatura Término SEMAT Método y teoría de la ingeniería de software Alpha Abstract-Level Progress Health Attribute Sistema de software

Un sistema de software puede ser parte de un software, hardware, negocio o una solución social más amplia.

QM Medida de calidad QME Elemento de medición de la calidad OMG Object Management Group

ISO/IEC International Organization for Standardization and International Electrotechnical Commission

SQuaRE Requisitos y evaluación de la calidad del producto de software FCV Factores Críticos de Vigilancia GQM Goal, Question, Metric

Introducción

La comunidad de investigación de ingeniería de software viene prestando atención a las teorías en ingeniería de software (Jacobson et al., 2013), evidenciando la necesidad de establecer un marco de trabajo común que permita a los desarrolladores de software el intercambio de información o la toma de decisiones (Muto et al., 2015). Esta necesidad da origen a Semat1 (Software Engineering Method and Theory), una iniciativa desarrollada para refundar la ingeniería de software como una disciplina rigurosa basada en una teoría sólida, principios probados y mejores prácticas (Jacobson et al., 2009). Jacobson et al., (2012) sugieren que un método es una composición de las prácticas que se describen en términos de los elementos esenciales del núcleo, denominados alfas, que son: oportunidad, interesados, requisitos, sistema de software, trabajo, equipo y forma de trabajo. Cada alfa se caracteriza con un simple conjunto de estados que representan su progreso y salud (Kajko-Mattsson et al., 2012; Zapata et al., 2013). La norma ISO/IEC 25000 (SQuaRE—Software Product Quality Requirements and Evaluation) es un estándar internacional que permite evaluar la calidad del producto de software, sustituyendo a las normas ISO/IEC 9126 e ISO/IEC 14598 (Hosni & Kirinic, 2013; Rodríguez et al., 2015). SQuaRE incluye las siguientes divisiones: ISO/IEC 2500n modelo de gestión de la calidad, ISO/IEC 2501n modelo de calidad, ISO/IEC 2502n medida de la calidad, ISO/IEC 2503n requisitos de la calidad e ISO/IEC 2504n evaluación de la calidad (ISO/IEC, 2007; ISO/IEC, 2011a; ISO/IEC, 2014; Schneider & Berenbach, 2014). Existen algunos estudios que se enfocan en evaluar la calidad del producto de software con base en las normas ISO/IEC 9126 (Alnanih et al., 2013; Bougroun et al., 2012; Heo et al., 2009) e ISO/IEC 25000 (Febrero et al., 2016; Idri et al., 2015; Lampasona et al., 2012; Marcos et al., 2008; Mellado et al., 2010; Rodríguez et al., 2016). Sin embargo, en estos estudios se desarrollan modelos y métodos que relacionan implícitamente las características, sub-características y medidas con los estados del alfa sistema de software del núcleo de Semat. Las medidas definidas en la norma ISO/IEC 25000 se pueden relacionar con los estados de los alfas del núcleo de Semat para evaluar y validar la calidad del producto de software por medio de cada estado del alfa y, de esta manera, obtener un producto de software de alta calidad. En otros estudios, como el de Zapata y Montoya

1 En el resto de este documento, usaremos el acrónimo "Semat" en minúscula, como una manera de seguir una tendencia sobre el uso de este término como un nombre propio en lugar de un acrónimo.

2 Introducción

(2016), se plantea la relación de las métricas de la norma ISO/IEC 9126 y los estados de los alfas del núcleo de Semat, centrando la propuesta en la selección de las métricas adecuadas para verificar y validar cada uno de los estados de los alfas, evidenciando la falta de una relación explicita entre las métricas de la norma ISO/IEC 9126 e ISO/IEC 25000 y los estados del alfa sistema de software. Además, en la investigación sobre la identificación de criterios para relacionar la usabilidad con el alfa sistema de software del núcleo de Semat, Perdomo y Zapata (2015) muestran una revisión de literatura sobre los modelos de medición de la calidad en productos de software, con el fin de identificar algunos criterios para definir la relación entre la característica de usabilidad de la métrica externa de la norma ISO/IEC 9126, con el alfa sistema de software y sus estados del núcleo de Semat. Zapata et al. (2013) desarrollan el juego MetriCC, que muestra la relación de algunas métricas de la norma ISO/IEC 9126 con los criterios de terminación de los espacios de actividad correspondientes al alfa sistema de software y que evidencian el progreso del alfa. En los estudios citados anteriormente se muestran esquemáticamente las medidas de la norma ISO/IEC 9126 y algunos estados de los alfas requisitos y sistema de software, pero no existe relación explicita entre las medidas de las normas ISO/IEC 9126 e ISO/IEC 25000 y cada uno de los estados del alfa sistema de software del núcleo de la Esencia Semat. Teniendo como base estos problemas, en esta Tesis de Doctorado se desarrolla un modelo para relacionar cada una de las medidas de la calidad establecidas en la norma ISO/IEC 2502n e ISO/IEC 2504n con el alfa sistema de software del núcleo de Semat. La propuesta se centra en la selección de las medidas adecuadas de los estados del alfa sistema de software, para estructurar las relaciones entre ellos, desarrollando un modelo para la medición y evaluación de la calidad del producto, y validando la aceptación de las medidas seleccionadas y el modelo propuesto en un caso de estudio mediante entrevistas semiestructuradas a una empresa desarrolladora de software en Australia. Los resultados son prometedores, ya que se pueden usar para establecer un modelo coherente y estructural para evaluar la salud y el progreso del alfa sistema de software en un esfuerzo en ingeniería de software. La presente Tesis Doctoral se divide en seis Capítulos: en el Capítulo 1 se presenta el marco teórico, el cual contiene una especificación del método y la teoría de la ingeniería de software, el estándar ISO/IEC 25000 y la medición y evaluación de la calidad del producto de software. En el Capítulo 2 se describen los antecedentes, en los cuales se considera una revisión de la literatura del objeto de estudio. En el Capítulo 3 se plantea el problema, el cual incluye su descripción y los objetivos de la Tesis Doctoral. En el Capítulo 4 se propone el modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n. En el Capítulo 5 se valida el modelo propuesto en un caso de estudio. Finalmente, en el Capítulo 6 se discuten las conclusiones y el trabajo futuro.

1. Marco teórico

1.1. Teoría y método de la ingeniería de software–Semat La iniciativa Semat se creó con el objetivo de refundar la ingeniería de software como una disciplina rigurosa basada en una teoría sólida, principios probados y mejores prácticas. Además, se define el lenguaje ‘Esencia’ y el núcleo (Jacobson et al., 2013), los cuales constituyen un estándar. El núcleo de Semat “ayuda a los profesionales a comparar métodos de desarrollo de software y tomar mejores decisiones sobre sus prácticas”; también “se pueden utilizar para analizar las fortalezas y debilidades de la forma de trabajar de un equipo” (OMG, 2014). En la Figura 1 se muestra la arquitectura del núcleo, donde los métodos se componen de prácticas, las prácticas se describen con el uso de los elementos del núcleo y las prácticas y el núcleo se definen en términos del lenguaje. Figura 1. Arquitectura del núcleo de Semat (OMG, 2014).

1.1.1. Áreas de interés La Esencia del núcleo de Semat tiene tres áreas de interés: cliente, solución y esfuerzo como se muestra en la Figura 2. En el área de interés del cliente (color verde) se comprenden las necesidades de los interesados y se exploran las posibilidades. En el área de interés de la solución (color amarillo), se comprenden los requisitos y se despliega y opera el sistema. En el área de interés del esfuerzo (color azul) se prepara el trabajo, se coordinan las actividades, se apoya al equipo, se hace un seguimiento del progreso y se detiene el trabajo (Jacobson et al., 2013). Los colores facilitan el entendimiento y seguimiento de los elementos del núcleo de Semat (OMG, 2014).

4 Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n

1.1.2. Alfas del núcleo de Semat El núcleo de Semat incluye elementos esenciales para trabajar en cada esfuerzo de desarrollo de software, los llamados alfas (sigla en inglés: Abstract-Level Progress Health Attribute), que permiten evaluar la salud y el progreso de un esfuerzo de ingeniería de software. En Semat se definen siete alfas principales: oportunidad, interesado, requisitos, sistema de software, equipo, trabajo y forma de trabajo. Cada alfa pertenece a un área de interés. En la Figura 2 se muestran los alfas del núcleo de Semat en cada área de interés. Los alfas tienen un conjunto de estados predefinidos y cada estado tiene una lista de verificación predefinida. Los alfas representan “indicadores críticos de las cosas que son más importantes para hacer seguimiento” durante el proceso de desarrollo de software (OMG, 2014). Figura 2. Alfas del núcleo de Semat (OMG, 2014).

En cada alfa se estipulan las tareas que se deben alcanzar (véase la Figura 3), lo cual ayuda a los administradores a comprender el progreso y la salud del desarrollo (Numata et al., 2015). El sistema de software es uno de los alfas del núcleo de Semat y constituye el énfasis de esta Tesis Doctoral. Este alfa consiste en un sistema que incluye software, hardware y datos y que proporciona su valor principal por la ejecución del software. Un sistema de software puede ser parte de un software, hardware, negocio o una solución social más amplia (OMG, 2014). Durante su desarrollo, un sistema de software progresa mediante varios estados: con arquitectura seleccionada, demostrable, usable, listo, operacional y retirado (véase la Figura 4). Estos estados proporcionan puntos de la estabilidad de un sistema de software desde su concepción hasta su eventual retiro (OMG, 2014).

Marco Teórico 5

Figura 3. Alfas y sus estados, núcleo de Semat (Jacobson et al., 2013).

Figura 4. Alfa sistema de software y sus estados (Jacobson et al., 2013).

El núcleo de Semat incluye otros elementos como prácticas, productos de trabajo, espacios de actividad, actividades, competencias y patrones. En la Figura 5 se muestran los elementos del núcleo de Semat y algunas asociaciones. Además, en la Figura 5 se muestra la dinámica semántica del lenguaje del núcleo, por ejemplo, una actividad produce o actualiza un producto de trabajo.


Figura 5. Vista conceptual del lenguaje (OMG, 2014).

1.1.3. Elementos del núcleo de Semat En la Tabla 1 se muestran los elementos del núcleo de Semat y su respectiva descripción. Tabla 1. Elementos gráficos del núcleo de Semat (1 de 2; OMG, 2014).

Nombre Símbolo Descripción

Alfa

Elemento esencial para determinar el progreso y la salud de un esfuerzo de ingeniería de software.

Actividad

Define una o más tipos de productos de trabajo y tareas y guías sobre cómo usarlos en un contexto de práctica.

Espacio de actividad

Actividades siempre realizadas en cualquier esfuerzo de ingeniería de software.

Práctica

Descripción de cómo manejar un aspecto específico de un esfuerzo de desarrollo de software.

Asociación de elementos

Se utiliza para conectar un producto de trabajo con un alfa o un rol. También se utiliza para conectar un espacio de actividad con una actividad o una fase.

Marco Teórico 7

Tabla 1. Elementos gráficos del núcleo de Semat (2 de 2; OMG, 2014).

Nombre Símbolo Descripción

Patrón o Rol

Es un mecanismo “genérico” para nombrar conceptos complejos que se componen de varios elementos de la Esencia.

Producto de trabajo

Dispositivo de valor y relevancia para un esfuerzo de ingeniería de software.

Símbolo de asociación de patrón

name

Una asociación de patrón se visualiza mediante una o más líneas continuas que se originan en un círculo que conecta cada elemento asociado dentro del patrón.

1.2. ISO/IEC 25000 ISO/IEC 25000 (SQuaRE—Requisito y evaluación de la calidad del producto de software) es un estándar internacional para evaluar la calidad del producto de software. Esta norma sustituye a las normas ISO/IEC 9126 e ISO/IEC 14598 (Hosni & Kirinic, 2013; Rodríguez et al., 2015). La norma incluye las siguientes divisiones: ISO/IEC 2500n gestión de la calidad, ISO/IEC 2501n modelo de calidad, ISO/IEC 2502n medición de la calidad, ISO/IEC 2503n requisitos de calidad e ISO/IEC 2504n evaluación de la calidad (ISO/IEC, 2007; ISO/IEC, 2011b; ISO/IEC, 2016; Schneider & Berenbach, 2014). Según Abran et al. (2008), ISO/IEC incluye la serie sobre requisitos y evaluación de la calidad del producto de software (SQuaRE) para mejorar la interpretación y el uso de las medidas. En la Figura 6 se muestra la estructura de la SQuaRE. Esta tesis Doctoral se enfoca principalmente en las divisiones ISO/IEC 2502n medición de la calidad e ISO/IEC 2504n evaluación de la calidad. Las características y sub-características de calidad incluyen medidas, las cuales tienen nombre, identificación, descripción y función de medida. Una función de medida es un algoritmo usado para combinar elementos de medición de calidad. Los resultados obtenidos al aplicar esta función se denominan medidas de calidad. Una medida de calidad representa la cuantificación de características y sub-características de calidad. Se debe utilizar más de una medida de calidad para medir una característica o sub-característica de calidad. De manera similar a ISO/IEC 9126, ISO/IEC 25000 tiene algunas características para medir la calidad del software desde diferentes perspectivas; la calidad en uso (ISO/IEC 25022), la calidad del producto del sistema y software (ISO/IEC 25023) y la calidad del dato (ISO/IEC 25024). En ISO/IEC 25023, las características se reorganizan para dar mayor importancia a la seguridad y la compatibilidad, que anteriormente se consideraban sub-características en los procesos de medición (véase la Tabla 2).


Figura 6. Organización del estándar internacional—SQuaRE (ISO/IEC, 2014).

Finalmente, ISO/IEC 25040 tiene un alto nivel de importancia para llevar a cabo el proceso de evaluación de la calidad, como una forma de reemplazar la serie ISO/IEC 14598. También incluye la medición, evaluación y evaluación total de la calidad del producto (Esaki, 2013). ISO/IEC 25040 incluye estándares para proporcionar requisitos, recomendaciones y pautas para evaluar el proceso del producto de software (ISO/IEC, 2011). Tabla 2. Características y sub-características de calidad del producto del sistema y software (1 de 2; ISO/IEC, 2016).

Característica Sub-característica Adecuación funcional

Integridad funcional, corrección funcional, adecuación funcional

Eficiencia de rendimiento

Comportamiento temporal, utilización de recursos, capacidad

Compatibilidad Coexistencia, interoperabilidad Usabilidad Reconocimiento de adecuación, capacidad de

aprendizaje, operabilidad, protección contra errores del usuario, estética de la interfaz de usuario, accesibilidad

Fiabilidad Madurez, disponibilidad, tolerancia a fallos, recuperabilidad

Seguridad Confidencialidad, integridad, no repudio, responsabilidad, autenticidad

Marco Teórico 9

Tabla 2. Características y sub-características de calidad del producto del sistema y software (2 de 2; ISO/IEC, 2016).

Característica Sub-característica Mantenibilidad Modularidad, reutilización, capacidad de análisis,

modificabilidad, capacidad de prueba. Portabilidad Adaptabilidad, capacidad de instalación,

intercambiabilidad Cada característica tiene asociada una sub-característica y una medida de calidad. Las medidas de calidad se implementan para evaluar cuantitativamente el sistema de software. Las medidas pueden ser internas o externas. Las medidas internas se pueden aplicar a software no ejecutable, como la especificación y el diseño de requisitos. Las medidas externas se pueden implementar al ejecutar el producto de software durante las etapas de prueba (ISO/IEC, 2016). En la Tabla 3 se muestra la estructura de la medida ‘coexistencia con otros productos’, la cual se asocia con la sub-característica ‘coexistencia’ y la característica ‘compatibilidad’. Tabla 3. Estructura de la medida de calidad (ISO/IEC, 2016).

ID Nombre Descripción Función de medida CCo-1-G

Coexistencia con otros productos

¿Qué proporción de productos de software específicos pueden compartir el entorno con este producto de software sin impacto adverso sobre sus características de calidad o funcionalidad?

X = A / B A = número de otros productos de software especificados con el cual este producto puede coexistir B = número de otros productos de software especificados para coexistir con este producto en un entorno de operación.

1.2.1. Estándar ISO/IEC 2502n ISO/IEC 2502n incluye un modelo de referencia de la medición de la calidad del producto, definiciones de medidas de calidad (interna, externa y en uso) y guías prácticas para su aplicación. Actualmente, esta división comprende (ISO/IEC, 2014): • ISO/IEC 25020—Guía y modelo de referencia para la medición: se presenta una

explicación introductoria y un modelo de referencia común a los elementos de medición de la calidad. También, se proporciona una guía para que los usuarios seleccionen o desarrollen y apliquen medidas que proponen las normas ISO.

• ISO/IEC 25021—Elementos de medida de calidad: se define y especifica un conjunto recomendado de métricas base y derivadas que se puedan usar a lo largo de todo el


ciclo de vida del desarrollo de software. Este conjunto de métricas se utiliza como entrada en el proceso de medida de la calidad interna, externa y en uso y, también, se especifica la forma de crear nuevas métricas de calidad en el modelo. Los elementos de medida de la calidad (QME por sus siglas en inglés) incluyen la relación existente entre las propiedades a cuantificar y los QME (ISO/IEC, 2012).

• ISO/IEC 25022—Medición de calidad en uso: se definen, específicamente, las métricas para realizar la medición de la calidad en uso del producto.

• ISO/IEC 25023—Medición de la calidad del producto de software y sistemas: se definen, específicamente, las métricas para realizar la medición de la calidad de productos y sistemas software (ISO/IEC, 2016).

• ISO/IEC 25024—Medición de la calidad de datos: se definen, específicamente, las métricas para realizar la medición de la calidad de datos.

1.2.2. Estándar ISO/IEC 2504n ISO/IEC 2504n se usa para realizar el proceso de evaluación de la calidad del producto, reemplazando completamente a su antecesor, la serie ISO/IEC 14598. Además, contempla la medición, evaluación y valoración total de la calidad del producto (Esaki, 2013). En el modelo de evaluación en la Figura 7 se describe el proceso y se detallan las actividades (entradas, restricciones, recursos y resultados) con sus respectivas tareas, las cuales incluyen propósitos e información complementaria que se utiliza para guiar una evaluación de calidad del producto de software. Figura 7. Marco general del proceso de evaluación de la calidad del producto (ISO/IEC, 2011).

Marco Teórico 11

La división de evaluación contiene un proceso con entradas de evaluación, las cuales incluyen nombre, requisito, medida, criterio y diseño, que finaliza con un plan de actividades. Además, hacen parte del proceso las restricciones, los recursos y resultados del proceso que se presentan en un reporte de hallazgos. Diferentes roles aplican el proceso de evaluación, como adquiriente, desarrollador, evaluador independiente, proveedor y operador. ISO/IEC 2504n incluye normas que proporcionan requisitos, recomendaciones y guías para llevar a cabo el proceso de evaluación del producto de software. Esta norma incluye (ISO/IEC, 2011): • ISO/IEC 25040—Guía y modelo de referencia de la evaluación: se propone un modelo

de referencia general para la evaluación, que incluye las entradas al proceso de evaluación, las restricciones y los recursos necesarios para obtener las correspondientes salidas.

• ISO/IEC 25041—Guía de evaluación para desarrolladores, adquirentes y evaluadores independientes: se describen los requisitos y recomendaciones para la implementación práctica de la evaluación del producto de software desde el punto de vista de los desarrolladores, adquirentes y evaluadores independientes.

• ISO/IEC 25042—Módulos de evaluación: se define lo que la norma considera un

módulo de evaluación y la documentación, estructura y contenido que se debe utilizar a la hora de definir uno de estos módulos.

• ISO/IEC 25045—Módulo de evaluación para recuperabilidad: se define un módulo para

la evaluación de la sub-característica “recuperabilidad”. Con este marco conceptual, se procede a analizar los antecedentes, que se incluyen en el Capítulo siguiente.

2. Antecedentes

El proceso de revisión sistemática de literatura se desarrolla de acuerdo con la metodología de vigilancia tecnológica e inteligencia competitiva descrita en la norma AENOR-UNE 166006:2011 (AENOR, 2011), en la guía metodológica que proponen Palop y Vicente (1999) y adaptada en ERICA (2012; véase la Figura 8). Figura 8. Metodología de vigilancia tecnológica e inteligencia competitiva (Palop & Vicente, 1999; ERICA, 2012).

La metodología se desarrolla combinando dos enfoques: uno relacionado con la búsqueda e investigación de lo que se desconoce con base en la necesidad de tomar una decisión sobre un tema específico en un plazo concreto y otro basado en la atención, búsqueda y seguimiento sistemático de novedades en áreas priorizadas y previamente acotadas para la detección anticipada de señales tempranas de cambios y la identificación de posibles oportunidades o amenazas (Palop & Vicente, 1999). La metodología cuenta con tres funciones básicas: observar, analizar y utilizar. Durante la función “Observar” se desarrollan tres fases: búsqueda, captación y difusión.


En la fase de búsqueda se presenta el formato “Factores Críticos de Vigilancia”, en el que se responde a una serie de preguntas relacionadas con el tema de investigación (véase la Tabla 4). Tabla 4. Factores Críticos de Vigilancia—FCV (adapatada de Palop & Vicente, 1999).

Tema ¿Por qué? ¿Para que? ¿Para quién? Palabras clave Restricciones Preguntas clave

Modelo de la relación entre las métricas de calidad de software incluidas en la norma ISO/IEC:25000 y los diferentes elementos del núcleo de Semat .

La ingeniería de software carece de procesos objetivos de evaluación y validación experimentales y creíbles de la calidad del software.

La ingeniería de software no tiene definidas las medidas para evaluar la calidad del software producido y los métodos que se usan para producirlo.

Desarrollar un modelo para la medición de la calidad del producto de software con base en la norma ISO/IEC:25000, en relación con el alfa sistema de software del núcleo de Semat .

Equipos de desarrollo de software e ingeniería de software.

ISO/IEC25000, característica, sub-característica, medida, función de medida, Semat , alfa, estado, evaluación

Metodologías, Normas/Estándar ISO/IEC.Sólo enfocado en sistemas de software (sistemas de información, software, aplicaciones, aplicación de escritorio o móvil)

1. ¿Qué enfoques se utilizan en las empresas para medir la calidad del software?2. ¿Qué métricas existen para evaluar la calidad del producto de software?3. ¿Existen modelos donde se relacionen las medidas de la norma ISO/IEC25000 con los estados del alfa del núcleo de Semat?

FICHA TECNICAFACTORES CLAVES DE VIGILANCIA TECNOLÓGICA (FCV)

En la fase de captación se desarrolla la “Bitácora de Búsqueda” que incluye una síntesis de las palabras clave, la ecuación de búsqueda utilizada durante el proceso de captación de información en las bases de datos científicas, la fuente de información, la cantidad de artículos y el nivel de prioridad (véase la Tabla 5). Adicionalmente, en el formato se almacenan los resultados de la búsqueda y captación de información facilitando el control de los metadatos identificados durante el proceso de investigación. Tabla 5. Bitácora de búsqueda (adapatada de Palop & Vicente, 1999).

Palabras Clave Ecuación de Búsqueda Fuente de Información Cantidad Prioridad

(1/5) Resultado Búsqueda (Fuente Bibliográfica)

Metrics, software quality model, measurement, progress, state, software project

pub-date > 2009 and (Metrics of software quality model applied to the measurement of progress and status of a software project) AND LIMIT-TO(cids, "271629,271539,271990,271521","Journal of Systems and Software,Information and Software Technology,Computer Networks,Future Generation Computer Systems") AND LIMIT-TO(topics, "system,project,process") AND LIMIT-TO(contenttype, "JL,BS","Journal").

Science Direct 19 3

http://www.sciencedirect.com.ezproxy.unal.edu.co/science?_ob=ArticleListURL&_method=list&_ArticleListID=-

877218379&_st=5&filterType=&searchtype=a&originPage=rslt_list&_origin=&_mlktType=&md5=b6802afff3ea4caad91a989

8ec228bcc

Metrics, quality, ISO 9126, measurement, progress, state, software project, application, information system

pub-date > 2007 and (Quality metrics ISO: 9126, applied to measuring the progress and status of a software project) and (Quality metrics ISO: 9126, applied to measuring the progress and status of a software product) AND LIMIT-TO(yearnav, "2015,2014,2013,2012,2009") AND LIMIT-TO(cids, "271539,271629,271322,271802,272990","Information and Software Technology,Journal of Systems and Software,Computer Methods and Programs in Biomedicine,Computers in Human Behavior,Electronic Notes in Theoretical Computer Scienc...") AND LIMIT-TO(topics, "application,quality,requirement,system,application service") AND LIMIT-TO(contenttype, "JL,BS","Journal").

Science Direct 7 4


877231611&_st=5&filterType=&searchtype=a&originPage=rslt_list&_origin=&_mlktType=&md5=8d5753c2530713263fd3df7

29d5e42f5

Quality metrics, ISO 9126, measurement, evaluation, software products

pub-date > 2007 and (Quality metrics ISO: 9126, applied to the evaluation of software products) or (Quality metrics ISO: 9126, applied to the measurement of software products) AND LIMIT-TO(cids, "271539,271629,271914,311863","Information and Software Technology,Journal of Systems and Software,Computer Standards & Interfaces,Relating System Quality and Software Architectu...") AND LIMIT-TO(topics, "quality,quality model,system,iso,model") AND LIMIT-TO(contenttype, "JL,BS","Journal").

Science Direct 15 3


877247314&_st=5&filterType=&searchtype=a&originPage=rslt_list&_origin=&_mlktType=&md5=f3236db3303dfa286628c22

6b984b83a

Metrics, measure, quality, ISO 9126, measurement, progress, state, software project, application

(Quality metrics ISO: 9126, applied to measuring the progress and status of a software project)

IEEE Explore Digital Library 18 3

http://ieeexplore.ieee.org.ezproxy.unal.edu.co/search/searchresult.jsp?action=search&sortType=&rowsPerPage=&searchField=Search_All&matchBoolean=true&queryText=(Quality%20

metrics%20ISO:%209126,%20applied%20to%20measuring%20the%20progress%20and%20status%20of%20a%20softwar

e%20project)&ranges=2008_2016_Year

Antecedentes 15

En la fase de difusión se socializa con las partes interesadas (red de observadores) los hallazgos preliminares identificados en las fases de búsqueda y captación. Durante la función “Analizar” se desarrollan tres fases: tratamiento, análisis y validación. En las fases de tratamiento y análisis de la información se identifican los artículos relevantes para la investigación, respondiendo a las preguntas clave descritas en los factores críticos de vigilancia. Una vez se identifican los estudios relevantes, se revisan a profundidad y, posteriormente, el equipo de investigadores los prioriza y analiza (véase la Tabla 6). Tabla 6. Priorización de la información (Los autores).

Fuente Total Relevante SeleccionadosIEEE Xplore Digital Library 30 10 4Google Sholar 42 16 4Science Direct 70 21 2Scopus 14 12 0Springer Link 14 8 1Redalyc 38 6 1Total 208 73 12

En la fase de validación se analizan 12 artículos como antecedentes para la investigación, los cuales se revisan haciendo un análisis a profundidad de cada modelo en comparación con la Esencia del núcleo de Semat, los estados del alfa y las medidas para la evaluación de la calidad del producto de software. Los artículos restantes se descartan debido a la falta de modelos de evaluación de la calidad y a la inexistente relación entre las medidas y los estados del alfa sistema de software. De todo el ciclo de vigilancia tecnológica, se aplican en el proceso de revisión de literatura las funciones “Observar” y “Analizar”. La función “Utilizar” se desarrolla en el Capítulo 4, durante el proceso de definición y validación del modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 25000. A continuación, se describen los resultados del análisis de los artículos seleccionados, los cuales se presentan de acuerdo con los modelos de evaluación de la calidad del software implementados y su relación implícita o explícita entre las normas ISO/IEC 9126 e ISO/IEC 25000 y los estados del alfa sistema de software de la Esencia Semat.


2.1. Modelos de evaluación de la calidad del software basados en la norma ISO/IEC 9126 e ISO/IEC 25000

El proyecto KEMIS (Marcos et al., 2008) incluye una infraestructura para la implementación de la mantenibilidad de la norma ISO/IEC 25000 haciendo uso de herramientas de software libre, lo que permite obtener una medida de la calidad del producto de software (véase la Figura 9). Este proyecto se enfoca en indicadores de mantenibilidad que aportan visibilidad durante el desarrollo, la adquisición y el mantenimiento de un producto, proporcionando una infraestructura de medición automática. Primero se relaciona una selección de atributos de calidad correspondientes a las sub-características de la mantenibilidad y luego se establecen las funciones necesarias para obtenerlos a partir de métricas de código. El proyecto KEMIS incluye funciones para normalizar los indicadores de atributos de calidad, de tal forma que se permite su escalado a sub-características y características de calidad. Luego de definir y normalizar los atributos, se asignan pesos a los atributos de acuerdo con el nivel de importancia dado a cada atributo. En este proyecto se genera un modelo de calidad que se almacena en una base de datos, que permite configurar los pesos de las funciones expuestas, los umbrales y las relaciones entre atributos y sub-características. Los autores validan el modelo propuesto con la evaluación de la calidad de varios productos de software libre disponibles en la web (véase la Figura 10) y obtienen tres de los valores que componen la mantenibilidad: estabilidad, capacidad de cambio y capacidad análisis. Este proyecto incluye una combinación de medidas y atributos de la característica y sub-características de mantenibilidad de las normas ISO/IEC 9126 e ISO/IEC 25000. El sistema de software se presenta en la forma de software libre y el proyecto propuesto para obtener la medida de la calidad no permite describir ninguna relación explicita ya que el núcleo de la Esencia Semat no existía en 2008. Sin embargo, en Marcos et al. (2008) se presentan indicadores de mantenibilidad como capacidad de analizarlo, capacidad para cambiarlo, estabilidad, capacidad para probarlo y cumplimiento de la mantenibilidad; los cuales aportan visibilidad durante el desarrollo, adquisición y mantenimiento de un producto para lograr el escalado con herramientas de software libre. Lo más cercano a “escalado” en el alfa sistema de software y de acuerdo con los indicadores de mantenibilidad definidos son los estados “usable”, “operacional” y “listo”, por lo que las métricas de mantenibilidad que los autores definen se relacionan implícitamente con estos estados.

Antecedentes 17

Figura 9. Relación de atributos contemplados en KEMIS (Marcos et al., 2008).

Figura 10. Evaluación de la calidad de productos de software libre disponibles en la web (Marcos et al., 2008).

Heo et al. (2009) proponen un modelo para evaluar las capacidades de usabilidad en teléfonos móviles en niveles que incluyen indicadores, criterios y propiedades. El marco propuesto es un enfoque para cuantificar la usabilidad mediante la validación y medición colectiva de aspectos definidos en listas de chequeo. En el modelo se presenta una jerarquía de factores de usabilidad con cuatro niveles de abstracción para identificar cómo se conectan los factores con niveles superiores y adyacentes (véase la Figura 11). El sistema de software en el artículo se presenta en la forma de aplicativo móvil y el procedimiento propuesto para evaluar la usabilidad no presenta ninguna relación debido a que durante 2009 el núcleo de Semat no existía como estándar. En este modelo se usa una sola característica de la norma ISO/IEC 9126 y algunos indicadores y criterios establecidos para su medición, sin mencionar las medidas definidas en la norma para evaluar la usabilidad.

Stability Changeability Analysabilityjboss-maven-plugin CodeHaus 83,05 371,00 87,26 100,00 72,47Jdepend Clarkware Consulting 75,35 1.808,00 100,00 100,00 50,70castos-maven-plugin CodeHaus 72,10 263,00 98,38 100,00 45,00jlgui javazoom 71,81 8.538,00 85,65 50,00 75,80quilt apache 60,91 4.087,00 95,18 49,58 49,43ivy apache 60,07 24.612,00 100,00 50,00 45,13commons-collections apache 60,00 19.417,00 100,00 50,00 45,00FindBugs University of Mariland 59,85 72.195,00 99,40 50,00 45,00JavaNCSS Klcee 59,42 15.203,00 100,00 50,00 43,84TightVNCviewer TightVNC Software 56,30 3.292,00 3,80 100,00 60,70velocity-tools apache 52,99 4.960,00 21,98 100,00 45,00CheckStyle Oliver Burn 39,46 28.744,00 17,85 50,00 45,00PMD InfoEther 37,65 39.604,00 10,60 50,00 45,00commons-logging apache 34,67 1.774,00 0,00 48,69 45,00

MantainabilitySub-característica

NOMBRE PROVEEDOR NIVEL mantenibilidad DE PRODUCTO NCSS


Los autores proponen un marco de trabajo para evaluar la usabilidad de los teléfonos móviles a partir de cinco indicadores, soporte visual de los objetivos de la tarea, apoyo de la interacción cognitiva, apoyo de la interacción eficiente, soporte funcional de las necesidades del usuario y soporte ergonómico debido a la poca efectividad de los métodos existentes para aplicarlos a un teléfono móvil. De acuerdo con la definición e interpretación descrita de los indicadores, el proyecto presenta relación implícita con el estado “usable” del alfa sistema de software del núcleo de Semat. Figura 11. Factores de usabilidad del modelo jerárquico (Heo et al., 2009).

En el proyecto MEDUSAS (Mellado et al., 2010) se ofrece a las empresas y organismos públicos un conjunto de servicios de evaluación y control de la calidad del software, de forma independiente y basados en la actual familia de normas ISO 25000. Además, este proyecto se enfoca en definir un marco de trabajo que permite determinar los procesos necesarios para llevar a cabo la evaluación de la calidad de los productos software. Este proyecto cuenta con un componente metodológico, un componente tecnológico y un componente de gestión y divulgación. En el componente metodológico se encuentra la metodología de la evaluación de la calidad, los modelos de calidad y las métricas, heurísticas y listas de chequeo necesarias para garantizar la mantenibilidad, seguridad y usabilidad del software. El componente tecnológico hace referencia al soporte metodológico y al entorno de medición y evaluación de la calidad que representan el conjunto de herramientas tecnológicas que permiten llevar a cabo el proceso de medición. Por último, el componente de gestión y divulgación incluye las herramientas necesarias para la planificación y gestión del proyecto, así como para su divulgación en los medios de comunicación (véase la Figura 12). La metodología MEDUSAS se puede aplicar mediante una implementación adaptada a la empresa cliente o mediante una implementación externalizada, más conocida como outsourcing. En el proyecto se evalúan las características de mantenibilidad, seguridad y usabilidad del producto de software describiendo las medidas utilizadas de la norma ISO/IEC 25000. El

Antecedentes 19

sistema de software se presenta en la forma de software y el proyecto propuesto para evaluar y controlar la calidad no presenta ninguna relación explicita con los estados del alfa debido a que durante el año 2010 el núcleo de Semat no se consideraba un estándar. En Mellado et al. (2010) se afirma que “una vez que el producto se implanta en sus instalaciones, se encuentran con graves problemas de calidad y seguridad” lo más cercano a “implantado” en el alfa sistema de software es “operacional”, por lo que las métricas de seguridad que ellos definen se ligan implícitamente con este estado. Figura 12. Proyecto MEDUSAS (Mellado et al., 2010).

Bougroun et al. (2012) analizan una clasificación existente de métricas orientadas a objetos para facilitar la evaluación del software. El modelo de calidad para el diseño orientado a objetos (QMOOD) se usa para relacionar los atributos de calidad y las métricas de diseño (véase la Figura 13). En el modelo propuesto se establece una clasificación de métricas orientadas a objetos basadas en las sub-características de la norma ISO/IEC 9126 y la combinación de los factores, el diseño y las propiedades de calidad de software orientado a objetos. El sistema de software en el artículo se describe en la forma de software orientado a objetos y el modelo propuesto no presenta relación con los estados del alfa sistema de software del núcleo de Semat ya que durante 2012 no era un estándar. Aunque en el modelo se describe la reusabilidad como atributo de calidad de acuerdo con la norma ISO/IEC 9126 y se listan algunas métricas de diseño, no se establece relación entre las métricas definidas y los estados del alfa sistema de software.


En Bougroun et al. (2012) se propone una alternativa para evaluar el software sin descuidar las propiedades de los diseños orientados a objetos como “abstracción”, “herencia” y “encapsulamiento”. Lo más cercano al modelo propuesto y a la combinación de los factores, el diseño y las propiedades de calidad en el alfa sistema de software son “operacional y retirado”, por lo que las métricas de mantenibilidad y confiabilidad que ellos definen se relacionan implícitamente con estos estados. Figura 13. Métricas de reutilización del diseño (Bougroun et al., 2012).

Lampasona et al. (2012) desarrollan un modelo de calidad del software personalizado a Ecopetrol, una empresa colombiana de petróleo y gas. Describen la creación del modelo de calidad ajustado a las necesidades del departamento de tecnologías de información en la empresa, alineando la incorporación, adquisición y desarrollo de soluciones informáticas con los objetivos del negocio. El modelo se desarrolla en dos etapas: una encuesta sobre la relevancia de varias características de calidad y un taller para identificar problemas relacionados con las características de calidad identificadas, definir objetivos de medición y determinar métricas concretas para los objetivos identificados. En la Figura 14 se observan los resultados de la encuesta que incluye las características evaluadas como muy importantes. Se identifican problemas específicos relacionados con la calidad del software que se deberían evitar. Los autores definen un conjunto de objetivos de calidad medibles para el enfoque de calidad de la compañía petrolera. Para cada objetivo se desarrollan métricas concretas que caracterizan la calidad del software en Ecopetrol, las cuales se integran en un modelo de calidad. Adicionalmente, este modelo se desarrolla para reducir los problemas causados por la baja calidad de software, contribuir con la capacidad de desarrollo y ayudar a la compañía a ser más ágil. Aunque en el artículo el sistema de software se presenta en la forma de software y en el modelo se relacionan los objetivos y las métricas de calidad con las características de la norma ISO/IEC 25000, no se presenta una relación entre dichas características, objetivos y métricas, y los estados del alfa sistema de software ya que el núcleo de Semat no existía como estándar durante 2012.

Antecedentes 21

Los autores desarrollan un modelo de calidad que consta de 10 objetivos medibles, 17 preguntas, 36 medidas y 10 factores de variación para mantener software rápido y ser más agiles. Este modelo presenta una relación implícita entre las características de adecuación funcional, eficiencia de rendimiento, usabilidad, seguridad y compatibilidad con los estados demostrable, usable, listo y operacional del alfa sistema de software de la Esencia Semat. Figura 14. Clasificación agregada por la importancia del aspecto de calidad (Lampasona et al., 2012).

Alnanih et al. (2013) proponen un modelo de calidad en uso para medir la calidad en el diseño de la interfaz de usuario basado en el estándar ISO/IEC 9126 para dispositivos móviles. Los factores de calidad en uso tales como efectividad, productividad, eficiencia, seguridad y satisfacción se redefinen para reflejar las formas en que los dispositivos móviles se usan y los contextos en los que se utilizan. En este proyecto se propone un factor de calidad en uso llamado ‘navegación de tareas’. En la Figura 15 se presentan los factores de calidad en uso con su respectiva interpretación y los indicadores de calidad con sus respectivas medidas. La evaluación de diferentes factores de calidad en uso ayuda a incrementar la efectividad, seguridad, productividad, eficiencia y satisfacción en el uso de dispositivos móviles. Los dispositivos móviles en este estudio en particular representan el sistema de software y con el modelo propuesto para medir la calidad en el diseño de la interfaz de usuario se validan teórica y empíricamente los factores de calidad en uso, pero no se hace explicita la relación entre estos factores y los estados del alfa sistema de software de la Esencia de Semat debido a que, durante la fecha de publicación del artículo, el núcleo no era un estándar. Sin embargo, existe una relación implícita entre los factores eficiencia de la tarea y navegación de tareas establecidos en la norma ISO/IEC 9126 y los estados usable y operacional del alfa sistema de software.


Figura 15. Modelo de calidad en uso para la interfaz de usuarios móviles (Alnanih et al., 2013).

Otro modelo en el que se evalúa la calidad del software basado en la norma ISO/IEC 25000, es el que proponen Idri et al. (2015) para evaluar la calidad de los registros de salud personales móviles (mPHRs) para el monitoreo del embarazo. Los autores analizan siete estudios en los que se definen requisitos de mPHR y se evalúan las aplicaciones móviles actuales en el mercado para monitorear el embarazo y lograr identificar los requisitos de evaluación de la calidad de los mPHR. Los requisitos de mPHR para el monitoreo del embarazo se clasifican en siete grupos: accesibilidad de la aplicación, detalles personales de la mujer embarazada, información del cuerpo físico, historial médico personal, información obstétrica y del embarazo, acciones de la usuaria y componentes de la aplicación. Además, los autores calculan el impacto de los requisitos en la calidad del producto de software utilizando la norma ISO/IEC 25000 (véase la Figura 16). El modelo permite a los desarrolladores y evaluadores considerar que el diseño de la lista de verificación es la clave principal para deducir el impacto de los requisitos en calidad del producto de software. El sistema de software se presenta en la forma de registro de salud personal móvil (mPHR). Aunque en el modelo se analiza el impacto de los requisitos en la evaluación de la calidad de los mPHRs usando la norma ISO/IEC 25000, no se describe explícitamente la relación entre las características y sub-características de calidad con los estados del alfa sistema de software. Aparte de la característica de transferibilidad, todas las demás características incluidas en este modelo se relacionan implícitamente con los estados del alfa sistema de software del núcleo de Semat, excepto el estado retirado.

Antecedentes 23

Figura 16. Impacto de los requisitos en las características externas (Idri et al., 2015).

Febrero et al. (2016) presentan una revisión sistemática de literatura sobre confiabilidad del software basado en la norma ISO/IEC 25000 como punto de partida para una propuesta de evaluación de la confiabilidad. El estudio incluye 1820 estudios como resultado de la revisión, de los cuales 800 se seleccionan después del filtrado de datos y 30 se analizan a fondo de acuerdo con la metodología propuesta. Los autores presentan un diseño para modelar la confiabilidad del software, integrando descriptivamente las necesidades de los grupos de interés. Cada nivel del modelo que se muestra en la Figura 17 tiene un nivel de descripción y una necesidad del usuario. En la parte superior se encuentra confiabilidad como la percepción del usuario sobre el comportamiento del sistema; esta vista es característica del usuario final o niveles de gestión superiores. Los primeros niveles de descomposición permiten el análisis funcional de los contribuyentes globales a la percepción del usuario como la madurez y la disponibilidad del software. En el tercer nivel del modelo se encuentran las medidas externas según la norma ISO/IEC 25000: estabilidad, solidez, tolerancia a fallos y capacidad de recuperación. El cuarto nivel comprende factores del software que afectan las características de calidad: complejidad del software, cambio de especificación, entorno operativo o cobertura de prueba. El último nivel permite obtener una descripción completa de los atributos medibles desde la percepción del usuario. Los autores presentan un esquema de diseño y evaluación de las sub-características de confiabilidad y su relación con las necesidades de los usuarios capturando diferentes puntos de vista. El sistema de software en el modelo se presenta en la forma de confiabilidad del software. Sin embargo, en el modelo no se evidencia una relación explicita entre confiabilidad y los estados del alfa sistema de software. No obstante, existe una relación implícita entre la característica de confiabilidad y los estados listo y operacional del alfa sistema de software del núcleo de Semat a pesar de que no se difundió ampliamente durante 2016.


Figura 17. Esquema de evaluación de confiabilidad (Febrero et al., 2016).

Rodríguez et al. (2016) presentan un entorno con un modelo de calidad, un proceso de evaluación en el que se establecen los requisitos de evaluación, la especificación de los detalles de evaluación, el diseño de la evaluación y la conclusión del proceso de evaluación. Además, se presenta un conjunto de herramientas para evaluar la característica idoneidad funcional de la norma ISO/IEC 25000. Los autores adaptan el laboratorio para la evaluación de la calidad de software (AQCLab) que se enfoca en evaluar la mantenibilidad para evaluar la idoneidad funcional (véase la Figura 18). Figura 18. Herramienta tecnológica para evaluar la calidad (Rodríguez et al., 2016).

En esta herramienta se genera un archivo XML que contiene los resultados de las medidas empleadas en la evaluación de la idoneidad funcional del producto. La herramienta permite al evaluador registrar toda la información de los requisitos que se deben implementar para cumplir los requisitos configurados al inicio del ciclo de vida. Además, la herramienta permite la asociación de los requisitos con el objetivo de uso. Los autores presentan la validación del modelo aplicado en una compañía consultora en procesos y proyectos de tecnologías de información (Bitware SL), realizando dos evaluaciones de la idoneidad

Antecedentes 25

funcional de una aplicación web para la gestión de los recursos humanos de una organización (véase la Figura 19). Los resultados de las evaluaciones de idoneidad funcional muestran un nivel constante de cumplimiento con los requisitos del producto. Aunque la relación entre los requisitos del producto y el nivel de idoneidad funcional la ratifica el equipo de trabajo de la compañía, esta relación no se hace explicita en la forma de estados del alfa. No solo la idoneidad funcional se puede relacionar con los requisitos del producto, sino con los estados con arquitectura seleccionada y demostrable del alfa sistema de software del núcleo de Semat. Figura 19. Resultados de las evaluaciones (Rodríguez et al., 2016).

2.2. Relación entre la norma ISO/IEC 9126 y el núcleo Semat

En el tutorial sobre la iniciativa Semat y el juego MetriCC, Zapata et al. (2013) presentan una herramienta que facilita el aprendizaje sobre la iniciativa Semat y la manera en que esta iniciativa empieza a consolidar la ingeniería de software por medio de la profundización en sus conceptos y la representación de los diferentes métodos y prácticas de desarrollo de software. En este juego se permite interactivamente visualizar la importancia y el funcionamiento de las prácticas de ingeniería de software mediante el uso del núcleo de Semat. En el desarrollo del juego, cada jugador trata de recorrer en cada partida las métricas y criterios de terminación que le permiten determinar que un espacio de actividad se completa. En el transcurso del juego, los jugadores deben ir superando las dificultades que generan los demás jugadores y deben ir creando obstáculos para que los demás jugadores no avancen en el juego. En el juego se emplean 129 cartas de cuatro clases: criterio de terminación, métrica, cartas problema y cartas solución (véase la Figura 20). Los autores realizan una breve descripción de la relación entre la métrica cumplimiento de usabilidad de la norma ISO/IEC 9126 con el estado retirado del alfa sistema de software y el criterio de terminación “el sistema ya no es compatible”. Sin embargo, no existe


evidencia explicita de la relación entre las métricas de la norma ISO/IEC 9126 e ISO/IEC 25000 con cada uno de los estados del alfa sistema de software. Figura 20. Cartas empleadas en el juego MetriCC (Zapata et al., 2013).

Perdomo y Zapata (2015) incluyen algunos criterios que permiten definir la relación entre la característica de usabilidad de la métrica externa de la norma ISO/IEC 9126 con el alfa sistema de software del núcleo de Semat (véase la Figura 21). Figura 21. Relación usabilidad, estados del alfa sistema de software (Perdomo & Zapata, 2015).

Los autores presentan las métricas externas que se relacionan con los estados del alfa sistema de software y las sub-características de usabilidad de la norma ISO/IEC 9126 (véase la Figura 22). En este proyecto se identifica la existencia de la relación directa de cuatro de los seis estados del alfa sistema de software con las sub-características de usabilidad. Mediante la relación establecida se evidencia la necesidad de integrar los conceptos y la funcionalidad de los estados del alfa con las métricas identificadas. Por otro lado, no se evidencia una relación explicita entre las sub-características y métricas de la norma ISO/IEC 9126 e ISO/IEC 25000 y los estados arquitectura seleccionada y retirado del alfa sistema de software de la Esencia Semat.

Antecedentes 27

Figura 22. Relación de métricas de la característica usabilidad con los estados del alfa sistema de software (Perdomo & Zapata, 2015).

Zapata y Montoya (2016) plantean la relación de algunas métricas de la norma ISO/IEC 9126 y algunos estados de las alfas del núcleo de Semat, centrando la propuesta en la selección de las métricas adecuadas para verificar y validar los estados de los alfas requisitos y sistema de software para obtener un producto de software de alta calidad. El estado ‘tratado’ del alfa requisitos se relaciona con la métrica ‘integridad funcional de la implementación’. En la métrica se cuenta el número de funciones faltantes detectadas en la evaluación y se compara con el número de funciones descritas en las especificaciones de los requisitos. La ecuación de la métrica se define como:

𝑋𝑋 = 1 − (𝛼𝛼 / 𝛽𝛽)

α = Número de funciones faltantes detectadas en la evaluación. β = Número de funciones descritas en las especificaciones del requisito 0 <= X<= 1, cuanto más cerca de 1, más completo.


El estado ‘operacional’ del alfa sistema de software se relaciona con la métrica ‘consistencia operacional en el uso’. Con la métrica se determina qué tan consistentes son los componentes de la interfaz de usuario. La ecuación de la métrica se define como:

𝑋𝑋 = 1 − (𝛼𝛼 / 𝛽𝛽)

α = Número de mensajes o funciones que el usuario encuentra inaceptablemente inconsistentes con las expectativas del usuario.

β = Número de mensajes o funciones. 0 <= X<= 1, cuanto más cerca de 1, es mejor.

Las métricas seleccionadas son adecuadas para validar los estados dirigido y operacional de los alfas requisitos y sistema de software respectivamente. Las métricas ayudan a obtener requisitos de calidad e identificar la completitud de la especificación que acepta el usuario. Además, se determina qué tan consistentes son los componentes de la interfaz de usuario, que pueden ayudar a obtener un sistema compatible con los niveles de servicio acordados con el usuario. Aunque los autores relacionan algunas métricas de la calidad de la norma ISO/IEC 9126 con los estados dirigido y operacional de los alfas requisitos y sistema de software, no existe relación explicita entre las métricas y cada uno de los estados del alfa sistema de software. Además, los autores proponen el uso de la norma ISO/IEC 25000 en lugar de la norma ISO/IEC 9126. En la Tabla 7 se presenta una síntesis de los diferentes estudios que se relacionan en el Capítulo 1. Allí se resumen los autores de los estudios analizados en relación con los problemas identificados. Tabla 7. Síntesis de estudios analizados en relación con los problemas identificados (1 de 2; Los autores).

Autor Modelo usado Estados deducidos

Tipo de representación

Relación explicita/implícita

Marcos et al., 2008 ISO/IEC 9126 e ISO/IEC 25000

Usable, operacional, listo Tabular Implícita

Heo et al., 2009 ISO/IEC 9126 Usable Jerárquica Implícita Mellado et al., 2010 ISO/IEC 25000 Operacional Jerárquica Implícita

Bougroun et al., 2012 ISO/IEC 9126 Operacional, retirado Jerárquica Implícita

Lampasona et al., 2012 ISO/IEC 25000

Demostrable, usable, listo, operacional

Tabular Implícita

Alnanih et al., 2013 ISO/IEC 9126 Usable, Operacional Jerárquica Implícita

Zapata et al., 2013 ISO/IEC 9126 Retirado Semat Explicita

Idri et al., 2015 ISO/IEC 25000

Con arquitectura seleccionada, demostrable, usable, listo, operacional

Tabular Implícita

Antecedentes 29

Tabla 7. Síntesis de estudios analizados en relación con los problemas identificados (2 de 2; Los autores)

Autor Modelo usado Estados deducidos

Tipo de representación

Relación explicita/implícita

Perdomo y Zapata, 2015 ISO/IEC 9126

Demostrable, usable, listo, operacional

Jerárquica Explicita

Febrero et al., 2016 ISO/IEC 25000 Listo, operacional Jerárquica Implícita

Rodríguez et al., 2016 ISO/IEC 25000

Con arquitectura seleccionada, demostrable

Jerárquica Implícita

Zapata y Montoya, 2016 ISO/IEC 9126 Operacional Semat Explicita

Las representaciones definidas de acuerdo a la revisión de los artículos relacionados con el objeto de la investigación son: i) jerárquica, cuando se realizada la representación de algún modelo con imágenes y figuras, ii) tabular, cuando se define la representación en tabla y iii) Semat, cuando la representación se desarrolla de acuerdo a los elementos de la Esencia Semat: alfa, actividad, espacio de actividad, practica, producto de trabajo, entre otros (OMG, 2014).

Por otra parte, la relación es declarada explicita cuando se expresa un criterio o característica con claridad y determinación, e implícita cuando algo está incluido en otro criterio sin que esta lo exprese o lo manifieste de manera directa.

3. Planteamiento del problema

3.1. Descripción del problema El alfa sistema de software del núcleo de Semat requiere para el cumplimiento de los criterios de calidad, un proceso de medición y evaluación, el cual se define en el estándar internacional ISO/IEC 25000 en sus normas ISO/IEC 2502n para la medición de la calidad del sistema y producto de software e ISO/IEC 2504n para el proceso de evaluación de la calidad. Para establecer una relación entre los estados del alfa sistema de software de la Esencia Semat y las medidas descritas en el estándar, es necesario establecer una conexión explicita con las características de calidad de la norma ISO/IEC 2502n, las cuales contienen sub-características y medidas específicas para relacionar los estados con arquitectura seleccionada, demostrable, usable, listo, operacional y retirado, con criterios tales como identificación, descripción de la medida, función de medida, fórmula, variable y descripción de la variable. De la misma manera, es importante establecer relación con el proceso de evaluación de la calidad, con el que se describen requisitos de entrada, restricciones, recursos y resultados para cada uno de los roles del proceso tales como desarrollador, adquiriente y evaluador independiente. Algunos estudios académicos permiten relacionar explícitamente las características y métricas de la calidad de la norma ISO/IEC 9126 con algunos estados de las alfas requisitos y sistema de software del núcleo de Semat (Zapata et al., 2013; Zapata & Montoya, 2016). Otro estudio muestra la relación esquemática entre las características, sub-características y medidas de la norma ISO/IEC 9126 y los estados de las alfas, pero no existe relación explicita entre las características y medidas con cada uno de los estados del alfa sistema de software (Perdomo & Zapata, 2015). Por otra parte, algunos proyectos se enfocan solo en evaluar la calidad del producto de software con base en las normas ISO/IEC 9126 (Alnanih et al., 2013; Bougroun et al., 2012; Heo et al., 2009; Marcos et al., 2008) e ISO/IEC 25000 (Febrero et al., 2016; Idri et al., 2015; Lampasona et al., 2012; Mellado et al., 2010; Rodríguez et al., 2016) desarrollando modelos y metodologías que relacionan implícitamente las características, sub-características y medidas con los estados del alfa sistema de software del núcleo de Semat.

Planteamiento del problema 31

El método para la evaluación de calidad basado en las normas ISO/IEC 25000 facilita la conformidad del usuario con el sistema de software. Las medidas y el proceso de evaluación definidos en la norma ISO/IEC 2502n e ISO/IEC 2504n respectivamente se pueden relacionar con los estados del alfa sistema software del núcleo de Semat para evaluar y validar la calidad del producto mediante cada estado del alfa y, de esta manera, medir la salud y el progreso de los esfuerzos de ingeniería de software. Teniendo en cuenta lo anterior, se propone la elaboración de un modelo para relacionar cada una de las medidas y la evaluación de la calidad del producto de software establecidas en las normas ISO/IEC 2502n e ISO/IEC 2504n con el alfa sistema de software del núcleo de Semat, para medir la salud y el progreso de los esfuerzos de ingeniería de software, estableciendo de esta manera un modelo de medición y evaluación objetivo de la calidad del producto de software.

3.2. Objetivos

3.2.1. Objetivo General Relacionar mediante un modelo cada una de las medidas y la evaluación de la calidad del producto de software establecidas en el estándar internacional ISO/IEC 2502n e ISO/IEC 2504n, con el alfa sistema de software del núcleo Semat, para medir la salud y el progreso de los esfuerzos de la ingeniería de software.

3.2.2. Objetivos específicos Construir el marco referencial en relación con las medidas de la calidad del producto

de software existentes en la norma ISO/IEC 25000 y los elementos del núcleo de Semat.

Caracterizar las medidas de la calidad del producto de software identificadas en relación con los elementos del núcleo de Semat.

Estructurar las relaciones entre las medidas de la calidad del producto de software y los elementos del núcleo de Semat.

Elaborar el modelo para la medición del progreso del alfa sistema de software a partir de las relaciones identificadas.

Evaluar la aplicación del modelo de calidad del producto de software al alfa sistema de software del núcleo de Semat mediante un caso de estudio.

4. Modelo para la medición del progreso del alfa sistema de software del núcleo de Semat

En esta Tesis de Doctorado se desarrolla un modelo para relacionar y evaluar cada una de las medidas de la calidad establecidas en la norma ISO/IEC 2502n e ISO/IEC 2504n con el alfa sistema de software del núcleo de Semat. La propuesta se centra en la selección de medidas adecuadas para los estados del alfa sistema de software, estableciendo un modelo de medición y evaluación objetivo de la calidad del producto para reflejar la salud y el progreso de un esfuerzo en ingeniería del software.

4.1. Selección de las medidas apropiadas de la norma ISO/IEC 2502n

Para la selección de las medidas apropiadas, se desarrollan los pasos que se muestran en la Figura 23, teniendo en cuenta la descripción de cada medida y su relación con los estados del alfa sistema de software: Figura 23. Pasos para la selección de las medidas apropiadas (Los autores).

Paso 1. Documentar los estados del alfa y las medidas de calidad: Se seleccionan todos los estados del alfa sistema de software para evaluarlos usando las medidas de la norma ISO/IEC 2502n. La selección de los estados se basa principalmente en sus listas de chequeo (véase la Tabla 8). Los estados implican que “se debe demostrar

Documentar los estados del alfa sistema de software y cada medida de la calidad

del producto de software de acuerdo con las normas

ISO/IEC 2502n

Interpretar los significados de las medidas de acuerdo con las normas 2502n y los estados alfa con la lista de

verificación para relacionarlos

Seleccionar las medidas adecuadas para evaluar la

calidad del producto de software en los estados del

alfa sistema de software

Representar las medidas y los estados del alfa sistema de software en el núcleo de

Semat


que el alfa sistema de software tiene suficiente calidad y funcionalidad para que sea útil para los usuarios” (Jacobson et al., 2013). Para documentar los estados y las medidas se crea un documento en Excel para hacer el análisis y seguimiento a cada estado y su relación con las medidas de calidad. Tabla 8. Lista de chequeo de los estados del alfa sistema de software (Jacobson et al., 2013).

Estado Ítem

Con arquitectura seleccionada

i. Se seleccionó la arquitectura que trata los riesgos técnicos clave ii. Se acordaron los criterios para seleccionar la arquitectura iii. Se seleccionaron las plataformas, tecnologías y lenguajes iv. Se tomaron las decisiones de compra, construcción y reúso

Demostrable

i. Se demostraron las características clave de la arquitectura ii. Los interesados relevantes acordaron que la arquitectura es

apropiada iii. Se ejercieron la interfaz crítica y las configuraciones del sistema

Usable

i. El sistema es usable y tiene las características de calidad deseadas

ii. Los usuarios pueden operar el sistema iii. Se aceptaron los niveles de defectos iv. Se conoció el contenido de liberación

Listo

i. Se puso a disposición la documentación de usuario ii. Los representantes de los interesados aceptaron el sistema iii. Los representantes de los interesados quieren que se haga

operacional el sistema

Operacional

i. El sistema se usó en un ambiente operacional ii. El sistema está disponible para los usuarios previstos iii. Al menos un ejemplo del sistema es completamente operacional iv. El sistema es compatible con los niveles de servicio acordados

Retirado i. No se da más soporte al sistema ii. No se producirán más actualizaciones al sistema iii. Se reemplazó o se descontinuó el sistema

Paso 2. Interpretar los significados de las medidas y los estados alfa: Se seleccionan las medidas para los estados, se interpreta el significado de las medidas y se relacionan con los estados del alfa. Sin embargo, cada medida tiene una particularidad y debe ser aplicada de acuerdo al contexto del proyecto de software y a los requisitos de la organización. Se identifican las medidas internas y externas adecuadas para evaluar el estado y el progreso del alfa sistema de software. Una medida interna es una "medida del grado en que un conjunto de atributos estáticos de un producto de software satisface las

Modelo propuesto 35

necesidades declaradas e implícitas del producto de software para utilizarlo en condiciones específicas" (ISO/IEC, 2016). Una medida externa es una "medida del grado en que un sistema o producto de software permite que el comportamiento satisfaga las necesidades declaradas e implícitas de que el sistema, incluido el software, se utilice bajo condiciones específicas" (ISO/IEC, 2016). Existen medidas internas y externas las cuales de acuerdo a su funcionalidad se aplican a nivel interno (verificación y validación de requisitos funcionales) y a nivel externo (verificación y validación de requisitos no funcionales como seguridad, portabilidad, mantenibilidad, usabilidad, funcionalidad, confiabilidad y compatibilidad). Las relaciones establecidas de cada característica, sub-característica y medida de calidad se presentan de acuerdo a la correlación directa entre el significado de cada medida seleccionada con los ítems de la lista de chequeo por estado. Algunas medidas se pueden relacionar con diferentes criterios según la definición de cada estado del alfa y de acuerdo al enfoque de calidad a evaluar, según calidad en uso, calidad del producto y calidad del dato. Durante el ejercicio de relacionamiento no se implementan criterios de valoración para definir la pertinencia de las medidas, esto se hace a juicio de los investigadores, lo que posteriormente será analizado en un estudio de caso con expertos de la industria de software para validar su idoneidad. En el numeral 3.3 se describe a profundidad las medidas seleccionadas y las relaciones establecidas. Paso 3. Seleccionar las medidas adecuadas para evaluar la calidad del software en los estados del alfa sistema de software: En la Tabla 9 se muestra la cantidad de medidas seleccionadas por característica de acuerdo con las normas ISO/IEC 25022 calidad en uso (naranja), ISO/IEC 25023 calidad del producto (morado) e ISO/IC 25024 calidad del dato (rojo). En la Tabla 10 se listan 12 (33%) medidas de calidad en uso seleccionadas de un total de 36 (100%) establecidas en la norma ISO/IEC 25022 de acuerdo con las relaciones identificadas para cada estado del alfa sistema de software. Las “medidas de calidad en uso no sólo dependen de la calidad del producto de software, sino también del contexto de uso particular en el cual el producto se está usando. El contexto de uso incluye, factores de usuario, factores de la tarea y factores de ambiente físico y social que pueden afectar la calidad en uso. Por lo tanto, comparaciones de la calidad en uso de un producto de software son sólo válidas cuando las medidas se realizan en el mismo contexto de uso” (ISO/IEC, 2014). Las medidas de la calidad en uso se categorizan en cinco características de acuerdo con la norma ISO/IEC 25022: efectividad, eficiencia, satisfacción, cobertura de contexto y libertad de riesgo.


Tabla 9. Cantidad de medidas seleccionadas por característica (Elaboración propia con base en ISO/IEC, 2014; ISO/IEC, 2016).

Característica Calidad en

uso

Total medidas ISO/IEC 25022

ISO/IEC 25022 seleccionadas

Característica Calidad del producto



Característica Calidad del dato



Efectividad 5 2 Adecuación funcional 4 4 Exactitud 7 1

Eficiencia 6 2 Eficiencia en el desempeño 12 2 Completitud 8 3

Satisfacción 9 6 Compatibilidad 4 3 Consistencia 6 2

Cobertura de contexto 4 2 Usabilidad 22 10 Credibilidad 4 2

Libertad de riesgo 12 Confiabilidad 11 2 Actualidad 3 1

Seguridad 11 1 Accesibilidad 3 1

Mantenibilidad 13 3 Conformidad 2 2

Portabilidad 9 4 Confidencialidad 2 2

Eficiencia 7 2

Precisión 2 1

Trazabilidad 3 1

Comprensibilidad 7 1

Disponibilidad 3 1

Portabilidad 3 1

Recuperabilidad 3 1

Total 36 12 86 29 63 22

(%) 100% 33% 100% 34% 100% 35%

Tabla 10. Medidas de calidad en uso seleccionadas (Los autores; ISO/IEC 2016).

Característica No ID Medida (ISO/IEC 25022)

Efectividad 1 8.2 - Ef-1-G Tareas completadas

2 8.2 - Ef-2-S Objetivos alcanzados

Eficiencia 3 8.3 - Ey-1-G Tiempo de tarea

4 8.3 - Ey-2-S Eficiencia de tiempo

Satisfacción

5 8.4 - SUs-1-G Satisfacción general

6 8.4 - SUs-2-G Satisfacción con las características

7 8.4 - SUs-3-G Uso discrecional

8 8.4 - SUs-4-G Utilización de características

9 8.4 - SPI-1-G Satisfacción del usuario (experiencia de usuario)

10 8.4 - STr-1-G Confianza del usuario

Cobertura de contexto

11 8.6 - CFl-1-S Contexto de uso flexible

12 8.6 - CFl-2-S Flexibilidad del producto

Libertad de riesgo No se presenta relación con los estados

Modelo propuesto 37

En la Tabla 11 se listan 29 (34%) medidas de calidad del producto de software seleccionadas de un total de 86 (100%) establecidas en la norma ISO/IEC 25023 de acuerdo con las relaciones identificadas para cada estado del alfa sistema de software. Las medidas de la calidad del producto se categorizan en ocho características de acuerdo con la norma ISO/IEC 25023: adecuación funcional, eficiencia de rendimiento, compatibilidad, usabilidad, confiabilidad, seguridad, mantenibilidad y portabilidad. Tabla 11. Medidas de calidad del producto de software seleccionadas (Los autores; ISO/IEC 2016).

Característica No ID Medida (ISO/IEC 25023)

Adecuación funcional

1 8.2 - FCp-1-G Cobertura funcional 2 8.2 - FCr-1-G Corrección funcional 3 8.2 - FAp-1-G Pertinencia funcional del objetivo de uso 4 8.2 - FAp-2-G Adecuación funcional del sistema


5 8.3 - PRu-3-G Significado de la utilización de dispositivos de E/S 6 8.3 - PCa-1-G Capacidad de procesamiento de transacciones

Compatibilidad 7 8.4 - CIn-1-G Intercambio de formato de datos 8 8.4 - CIn-3-S Suficiencia de interfaz externa 9 8.4 - CCo-1-G Coexistencia con otros productos

Usabilidad

10 8.5 - UAp-1-G Descripción completa 11 8.5 - ULe-4-S Interfaz de usuario 12 8.5 - UIn-1-S Aspecto estético de las interfaces de usuario 13 8.5 - UOp-1-G Consistencia operacional 14 8.5 - UEp-2-S Corrección de error de entrada de usuario 15 8.5 - UOp-7-S Categorización comprensible de la información 16 8.5 - ULe-1-G Integridad de la guía del usuario 17 8.5 - UOp-3-S Personalizabilidad funcional 18 8.5 - UOp-4-S Personalización de la interfaz de usuario 19 8.5 - UOp-8-S Aspecto de consistencia

Confiabilidad 20 8.6 - RFt-1-G Evitación de fallos 21 8.6 - RAv-1-G Disponibilidad del sistema

Seguridad 22 8.7 - SIn-1-G Integridad de datos

Mantenibilidad 23 8.8 - MAn-1-G Integridad del registro del sistema 24 8.8 - MMd-1-G Eficiencia de modificación 25 8.8 - MMd-3-S Capacidad de modificación

Portabilidad

26 8.9 - PAd-2-G Adaptación ambiental del software 27 8.9 - PAd-3-S Adaptación ambiental operacional 28 8.9 - PRe-4-S Reutilización de datos/capacidad de importación 29 8.9 - PRe-3-S Integración funcional

En la Tabla 12 se listan 22 (35%) medidas de calidad del dato seleccionadas de un total de 63 (100%) establecidas en la norma ISO/IEC 25024 de acuerdo con las relaciones


identificadas para cada estado del alfa sistema de software. Las “medidas de calidad del dato se evalúan en la aplicación de métodos de medición” (ISO/IEC, 2014). Un método de medición es una secuencia lógica de operaciones usada para cuantificar las propiedades respecto de una escala especificada. La aplicación de un método de medición se denomina elemento de medida de calidad (QME; siglas en inglés: Quality Measure Element; ISO/IEC, 2014). Las medidas de la calidad del dato se categorizan en 15 características de acuerdo con la norma ISO/IEC 25024: QMs para exactitud, completitud, consistencia, credibilidad, actualidad, accesibilidad, conformidad, confidencialidad, eficiencia, precisión, trazabilidad, comprensibilidad, disponibilidad, portabilidad y recuperabilidad. Tabla 12. Medidas de calidad del dato seleccionadas (1 de 2; Los autores; ISO/IEC 2016).

Característica No ID Medida (ISO/IEC 25024) QMs para exactitud 1 8.2 - Acc-I-8 Exactitud del modelo de datos

QMs para completitud

2 8.3 - Com-I-1 Registro completo 3 8.3 - Com-I-6 Modelo conceptual de datos completo 4 8.3 - Com-I-8 Metadatos completos

QMs para consistencia

5 8.4 - Con-I-4 Consistencia de la arquitectura 6 8.4 - Con-I-2 Consistencia del formato de datos

QMs para credibilidad

7 8.5 - Cre-I-1 Credibilidad de los valores 8 8.5 - Cre-I-4 Credibilidad del modelo de datos

QMs para actualidad 9 8.6 - Cur-I-1 Frecuencia de actualización QMs para accesibilidad 10 8.7 - Acs-I-1 Accesibilidad del usuario

QMs para conformidad

11 8.8 - Cmp-I-2 Cumplimiento normativo debido a la tecnología 12 8.8 - Cmp-I-1 Cumplimiento normativo del valor y/o formato

QMs para confidencialidad

13 8.9 - Cnf-I-1 Uso de cifrado 14 8.9 - Cnf-D-1 No vulnerabilidad

QMs para eficiencia 15 8.10 - Eff-I-2 Eficiencia de utilización 16 8.10 - Eff-D-2 Eficiencia de procesamiento de datos

QMs para precisión 17 8.11 - Pre-I-1 Precisión de los valores de los datos QMs para trazabilidad 18 8.12 - Tra-D-2 Trazabilidad del valor de los datos

QMs para comprensibilidad 19 8.13 - Und-I-4 Comprensión de los valores de los datos

QMs para disponibilidad 20 8.14 - Ava-D-1 Proporción de disponibilidad de datos

QMs para portabilidad 21 8.15 - Por-D-1 Proporción de portabilidad de datos

QMs para recuperabilidad 22 8.16 - Rec-D-1 Proporción de recuperabilidad de datos

Modelo propuesto 39

Paso 4. Representación de las medidas y los estados del alfa: La representación de las medidas y los estados del alfa sistema de software en el núcleo de Semat, se desarrolla en el numeral 3.4 de esta tesis.

4.2. Relación de las medidas seleccionadas de la ISO/IEC 2502n con los estados del alfa sistema de software

Para relacionar las medidas de la calidad en uso (ISO/IEC 25022), calidad del producto (ISO/IEC 25023) y calidad del dato (ISO/IEC 25024) con los estados del alfa se realiza la interpretación de la lista de verificación por estado y la descripción de cada medida. En la Tabla 13 se muestra la descripción numérica entre los estados del alfa sistema de software y las medidas seleccionadas. Tabla 13. Descripción numérica entre los estados del alfa y las medidas seleccionadas (Elaboración propia con base en Jacobson et al., 2013; ISO/IEC, 2014; ISO/IEC, 2016).

Estados alfa sistema de software

Medidas por estado del alfa




Con arquitectura seleccionada 6 4 2

Demostrable 7 1 4 2

Usable 24 5 6 13

Listo 12 5 4 3

Operacional 21 6 9 6

Retirado 5 4 1

Total 75 17 31 27

(%) 100% 23% 41% 36%

A continuación, se describen las relaciones entre las medidas seleccionadas de la calidad en uso, calidad del producto y calidad del dato con la lista de verificación de los estados del alfa sistema de software del núcleo de Semat y las respectivas funciones de medición. Cabe destacar que algunas medidas se relacionan con más de un estado del alfa sistema de software.

4.2.1. Medidas de la calidad en uso (ISO/IEC 25022) relacionadas con los estados del alfa

En la Tabla 14 se relacionan los estados del alfa sistema de software con las medidas de la calidad en uso identificadas en la norma ISO/IEC 25022.


Tabla 14. Relación de los estados del alfa sistema de software con las medidas de la calidad en uso (Los autores).

Estado Lista de verificación ID Medida (ISO/IEC 25022)

Demostrable Los interesados relevantes acordaron que la arquitectura es apropiada

8.4 - SUs-1-G Satisfacción general

Usable

El sistema es usable y tiene las características de calidad deseadas

8.4 - SUs-2-G Satisfacción con las características

8.4 - SUs-3-G Uso discrecional 8.4 - SUs-4-G Utilización de características

Los usuarios pueden operar el sistema

8.2 - Ef-1-G Tareas completadas 8.2 - Ef-2-S Objetivos alcanzados

Listo

Los representantes de los interesados aceptaron el sistema

8.4 - SUs-1-G Satisfacción general

8.4 - SPI-1-G Satisfacción del usuario (experiencia de usuario)

Los representantes de los interesados quieren que se haga operacional el sistema

8.4 - STr-1-G Confianza del usuario 8.3 - Ey-1-G Tiempo de tarea 8.3 - Ey-2-S Eficiencia de tiempo

Operacional

Al menos un ejemplo del sistema es completamente operacional

8.2 - Ef-1-G Tareas completadas 8.2 - Ef-2-S Objetivos alcanzados 8.3 - Ey-1-G Tiempo de tarea 8.3 - Ey-2-S Eficiencia de tiempo

El sistema es compatible con los niveles de servicio acordados

8.6 - CFl-1-S Contexto de uso flexible

8.6 - CFl-2-S Flexibilidad del producto

Existe una relación directa de los estados demostrable, usable, listo y operacional con diferentes medidas de la calidad en uso. Sin embargo, con los estados con arquitectura seleccionada y retirado no se logra establecer una correlación directa debido a la complejidad del significado de algunas medidas con las cuales no se logra evaluar el criterio específico de los estados del alfa. Para el estado demostrable, se identifica una relación directa con la característica satisfacción y una de sus medidas. Con las medidas de satisfacción se “evalúa el grado en que se satisfacen las necesidades del usuario cuando un producto o sistema se utiliza en un contexto de uso específico” (ISO/IEC, 2016). En la Tabla 15 se muestra la función de medida y la principal razón de selección de la medida. La función de medida se define en la ISO/IEC 15939 como “una fórmula que muestra cómo los elementos de la medición de la calidad se combinan para producir la medida de la calidad” (ISO/IEC, 2007).

Modelo propuesto 41

Tabla 15. Función de medición de la calidad en uso para el estado demostrable (Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección

Satisfacción

Satisfacción general

𝑋𝑋 = �𝐴𝐴𝐴𝐴

Ai = respuestas a las preguntas realizadas al usuario con respecto a la satisfacción general del sistema

Los interesados relevantes manifiestan satisfacción general con las funcionalidades y la usabilidad del producto o sistema

Al igual que en el estado demostrable, en el estado usable se presentan algunas relaciones con las características satisfacción y efectividad. Con las medidas de efectividad se “evalúa la precisión y la integridad con la que los usuarios logran objetivos específicos” (ISO/IEC, 2016). En la Tabla 16 se describen cinco medidas seleccionadas con su respectiva función de medición y razón de selección. Tabla 16. Función de medición de la calidad en uso para el estado usable (1 de 2; Elaboración propia con base en ISO/IEC 2016).


Satisfacción

Satisfacción con las características


Ai = respuestas a un cuestionario relacionado con características específicas

Los interesados relevantes manifiestan satisfacción del producto respecto de ciertas características específicas identificadas

Uso discrecional

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de usuarios usando una función específica, aplicación o sistema B = número de usuarios potenciales quienes podrían usar la función específica

Proporción de usuarios potenciales seleccionando el uso de algunas funciones del sistema

Utilización de características

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de usuarios usando una característica particular B = número de usuarios en un conjunto de usuarios del sistema identificados

Proporción de un conjunto de usuarios del sistema identificados quienes usan una característica particular


Tabla 16. Función de medición de la calidad en uso para el estado usable (2 de 2; Elaboración propia con base en ISO/IEC 2016).


Efectividad

Tareas completadas

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de tareas únicas completadas B = número total de tareas únicas intentadas

Proporción de las tareas que se completan correctamente sin asistencia

Objetivos alcanzados

� 𝑋𝑋 = 1 − �𝐴𝐴𝐴𝐴 � 𝑋𝑋 ≥ 0 }

Ai = valor proporcional de cada objetivo faltante o incorrecto en el resultado de la tarea (valor máximo = 1)

Proporción de los objetivos de la tarea que se alcanzan correctamente sin asistencia

En el estado listo se presenta una relación cercana con las características satisfacción y eficiencia. Con las medidas de eficiencia se “evalúan los recursos gastados en relación con la precisión y la integridad con que los usuarios logran los objetivos” (ISO/IEC, 2016). Las cinco medidas seleccionadas se muestran en la Tabla 17. Tabla 17. Función de medición de la calidad en uso para el estado listo (1 de 2; Elaboración propia con base en ISO/IEC 2016).


Satisfacción



Ai = respuestas a las preguntas realizadas al usuario respecto de la satisfacción general del sistema

Los interesados relevantes manifiestan satisfacción general con las funcionalidades y la usabilidad del producto o sistema

Satisfacción del usuario (experiencia de usuario)

𝑋𝑋 = 𝐴𝐴 A = valor de la escala psicométrica de un cuestionario de placer.

Proporción de la medida en que el usuario obtiene placer en comparación con el promedio para este tipo de producto/sistema

Confianza del usuario

𝑋𝑋 = 𝐴𝐴 A = valor de la escala psicométrica de un cuestionario de confianza

Proporción de la medida en que el usuario confía en el sistema/producto

Modelo propuesto 43

Tabla 17. Función de medición de la calidad en uso para el estado listo (2 de 2; Elaboración propia con base en ISO/IEC 2016).


Eficiencia

Tiempo de tarea 𝑋𝑋 = 𝑇𝑇 T = tiempo de la tarea

Tiempo tomado para completar una tarea exitosamente

Eficiencia de tiempo

𝑋𝑋 = 𝐴𝐴/𝑇𝑇 A = número de objetivos alcanzados T = tiempo

Eficiencia con la cual los usuarios logran sus objetivos sobre el tiempo cuando utilizan el producto o sistema

Por último, el estado operacional, para su evaluación, comparte las medidas de efectividad (tareas completadas y objetivos alcanzados) y eficiencia (tiempo de tarea y eficiencia de tiempo) descritas en los estados listo y usable. Sin embargo, es necesario la evaluación de las medidas de cobertura de contexto para dar cumplimiento a los criterios del estado (véase la Tabla 18). Con las medidas de cobertura de contexto se “evalúa el grado en que un producto se puede usar con efectividad, eficiencia, satisfacción y libertad de riesgo en contextos de uso específicos y en contextos más allá de los identificados inicialmente de manera explícita” (ISO/IEC, 2016). Tabla 18. Función de medición de la calidad en uso para el estado operacional (1 de 2; Elaboración propia con base en ISO/IEC 2016).


Efectividad

Tareas completadas

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de tareas únicas completadas B = número total de tareas únicas intentadas

Proporción de las tareas que se completan correctamente sin asistencia

Objetivos alcanzados

� 𝑋𝑋 = 1 − �𝐴𝐴𝐴𝐴 � 𝑋𝑋 ≥ 0 }

Ai = valor proporcional de cada objetivo faltante o incorrecto en el resultado de la tarea (valor máximo = 1)

Proporción de los objetivos de la tarea que se alcanzan correctamente sin asistencia

Eficiencia

Tiempo de tarea 𝑋𝑋 = 𝑇𝑇 T = tiempo de la tarea

Tiempo tomado para completar una tarea exitosamente


𝑋𝑋 = 𝐴𝐴/𝑇𝑇 A = número de objetivos alcanzados T = tiempo

Eficiencia con la cual los usuarios logran sus objetivos sobre el tiempo cuando utilizan el producto o sistema


Tabla 18. Función de medición de la calidad en uso para el estado operacional (2 de 2; Elaboración propia con base en ISO/IEC 2016).


Cobertura de contexto

Contexto de uso flexible

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de contextos adicionales en los cuales el producto se puede usar con aceptable calidad en uso B = número total de contextos adicionales en los cuales el producto se puede usar

Grado en el que el producto se puede usar en contextos de uso adicionales (diferentes tipos de usuarios, usos y ambientes) con ninguna modificación o sólo simples modificaciones

Flexibilidad del producto

𝑋𝑋 = 1/𝐵𝐵�𝐴𝐴𝐴𝐴𝐵𝐵

𝑖𝑖=1

A = modificabilidad de los requisitos especificados (i) B = número total de nuevos requisitos desde los usuarios específicos

Facilidad con la cual un producto se puede modificar para reunir requisitos de usuario adicionales

4.2.2. Medidas de la calidad del producto (ISO/IEC 25023) relacionadas con los estados del alfa

En la Tabla 19 se muestra la relación de los estados del alfa sistema de software con las medidas de la calidad del producto identificadas en la norma ISO/IEC 25023. Tabla 19. Relación de los estados del alfa sistema de software con las medidas de la calidad del producto (1 de 3; Los autores).



Se seleccionó la arquitectura que trata los riesgos técnicos clave.

8.2 - FCp-1-G Cobertura funcional

8.2 - FCr-1-G Corrección funcional

Se acordaron los criterios para seleccionar la arquitectura

8.2 - FAp-1-G Pertinencia funcional del objetivo de uso

Se seleccionaron las plataformas, tecnologías y lenguajes

8.3 - PRu-3-G Significado de la utilización de dispositivos de E/S

Modelo propuesto 45

Tabla 19. Relación de los estados del alfa sistema de software con las medidas de la calidad del producto (2 de 3; Los autores).


Demostrable

Se demostraron las características clave de la arquitectura

8.2 - FAp-2-G Adecuación funcional del sistema

8.2 - PCa-1-G Capacidad de procesamiento de transacciones

Se ejercieron la interfaz crítica y las configuraciones del sistema

8.4 - CIn-1-G Intercambialidad de formatos de datos

8.4 - CIn-3-S Suficiencia de interfaz externa

Usable


8.5 - UAp-1-G Descripción completa 8.5 - ULe-4-S Interfaz de usuario

8.5 - UIn-1-S Aspecto estético de las interfaces de usuario

Los usuarios pueden operar el sistema 8.5 - UOp-1-G Consistencia operacional

Se aceptaron los niveles de defectos 8.5 - UEp-2-S Corrección de error de

entrada de usuario

Se conoció el contenido de liberación 8.5 - UOp-7-S

Categorización comprensible de la información

Listo

Se puso a disposición la documentación de usuario 8.5 - ULe-1-G Integridad de la guía del

usuario Los representantes de los interesados aceptaron el sistema

8.6 - RFt-1-G Evitación de fallos


8.5 - UOp-1-G Consistencia operacional

8.7 - SIn-1-G Integridad de datos

Operacional

El sistema se usó en un ambiente operacional

8.5 - UOp-1-G Consistencia operacional 8.5 - UOp-3-S Personalizabilidad funcional

8.5 - UOp-4-S Personalización de la interfaz de usuario

8.5 - UOp-8-S Aspecto de consistencia

8.8 - MAn-1-G Integridad del registro del sistema

8.9 - PAd-2-G Adaptación ambiental del software

El sistema se usó en un ambiente operacional 8.9 - PAd-3-S Adaptación ambiental

operacional El sistema está disponible para los usuario previstos 8.6 - RAv-1-G Disponibilidad del sistema


Tabla 19. Relación de los estados del alfa sistema de software con las medidas de la calidad del producto (3 de 3; Los autores).


Operacional

Al menos un ejemplo del sistema es completamente operacional

8.5 - UOp-1-G Consistencia operacional


8.4 - CCo-1-G Coexistencia con otros productos

Retirado

No se da más soporte al sistema

8.8 - MMd-1-G Eficiencia de la modificación

8.8 - MMd-3-S Capacidad de la modificación

Se reemplazó o se descontinuó el sistema

8.9 - PRe-3-S Integración funcional

8.9 - PRe-4-S Reutilización de datos / Capacidad de importación

Para el estado con arquitectura seleccionada, se encuentra una estrecha relación con las características de idoneidad funcional y eficiencia de rendimiento y sus medidas. Las medidas de idoneidad funcional "se utilizan para evaluar el grado en que un producto o sistema proporciona funciones que satisfacen las necesidades declaradas e implícitas cuando se usan en condiciones específicas" y las medidas de eficiencia de rendimiento "se utilizan para evaluar el rendimiento relativo a la cantidad de recursos utilizados en condiciones". "Los recursos pueden incluir otros productos de software, la configuración de hardware y software del sistema y los materiales (por ejemplo, papel de impresión, medios de almacenamiento)" (ISO/IEC, 2016). Como una medida directa para evaluar el estado, se identifican las características adecuación funcional y eficiencia de rendimiento. Cada característica tiene tres sub-características respectivamente: completitud funcional, corrección funcional y apropiación funcional, y comportamiento en el tiempo, utilización de recursos y capacidad. Estas sub-características contienen cuatro y 12 medidas respectivamente. Sin embargo, se seleccionan cuatro medidas debido a los significados y la directa relación con el estado arquitectura seleccionada. En la Tabla 20 se muestra la función de medida y la principal razón de selección.

Modelo propuesto 47

Tabla 20. Función de medición de la calidad del producto para el estado con arquitectura seleccionada (Elaboración propia con base en ISO/IEC 2016).



Cobertura funcional

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de funciones perdidas B = número de funciones específicas

Proporción de las funciones específicas y los criterios usados que se implementan cuando se selecciona la arquitectura

Corrección funcional

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de funciones que son incorrectas B = número de funciones consideradas

Proporción de las funciones que proveen los resultados correctos cuando se selecciona la arquitectura. Una función incorrecta es aquella que no provee un resultado razonable y aceptable para lograr el objetivo específico esperado

Pertinencia funcional del objetivo de uso

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de funciones perdidas o incorrectas que se requieren para lograr un objetivo de uso específico B = número de funciones requeridas para lograr un objetivo de uso específico

Proporción de funciones que requiere el usuario y que proveen resultados apropiados para lograr un objetivo de uso específico

Significado de la utilización de dispositivos de E/S

𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐴𝐴)/𝑛𝑛𝑖𝑖=1𝑡𝑡𝑡𝑡𝑡𝑡

Ai = Duración de los dispositivos de E/S ocupados para realizar un conjunto específico de tareas para la i-ésima observación Bi = Duración de la operación de E/S para realizar las tareas para la observación i-ésima n = número de observaciones

Proporción de tiempo usado para desarrollar un conjunto específico de tareas comparado con el tiempo de operación

Al igual que en el estado anterior, en el estado demostrable, se presenta una relación directa con las características de adecuación funcional y eficiencia de rendimiento. Además, este estado se relaciona con la característica de compatibilidad, la cual “se usa para evaluar el grado en el cual un producto, sistema o componente puede intercambiar información con otros productos, sistemas o componentes, y/o mantener sus funciones requeridas, mientras comparten el mismo ambiente de hardware o software” (ISO/IEC, 2016). En la Tabla 21 se muestran cuatro medidas seleccionadas para el estado:


Tabla 21. Función de medición de la calidad del producto para el estado demostrable (Elaboración propia con base en ISO/IEC 2016).



Adecuación funcional del sistema

𝑋𝑋 = � (𝐴𝐴𝐴𝐴)/𝑛𝑛𝑖𝑖=1𝑡𝑡𝑡𝑡𝑡𝑡

Ai = puntaje de adecuación para el objetivo de uso i, es decir, el valor medido de la adecuación funcional del objetivo de uso para el i-ésimo objetivo de uso específico n = número de objetivo de uso

Proporción de las funciones y las características de la arquitectura clave que se demostraron y los usuarios las requieren para lograr sus objetivos y proporcionar un resultado apropiado


Capacidad de procesamiento de transacciones

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de transacciones completadas durante el tiempo de observación B = duración de la observación

Grado en que los límites máximos de un producto o parámetro del sistema cumplen los requisitos. Dichos parámetros se asocian con la forma en que se puede ejercer el sistema y se puede medir su desempeño

Compatibilidad

Intercambiabilidad de formato de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de formato de datos intercambiable con otros sistemas o software B = número de formato de datos especifico a ser intercambiable

Grado en que con un producto se pueden realizar sus funciones requeridas de manera eficiente al compartir un entorno y recursos comunes con otros productos, sin un impacto perjudicial en cualquier otro producto. En general, la integración con otros sistemas existentes se demuestra.

Suficiencia de interfaz externa

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de interfaces externas que son funcionales B = número de interfaces externas específicas

Proporción de las interfaces externas especificadas con otro software y sistemas es funcional.

De otra parte, en el estado usable se identifica una relación con la característica de usabilidad y sus medidas. Las medidas de usabilidad "se utilizan para evaluar el grado en que un producto o sistema lo pueden utilizar usuarios específicos para lograr objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso específico" (ISO/IEC, 2016). La usabilidad tiene seis sub-características: reconocimiento apropiado, capacidad de aprendizaje, operabilidad, protección contra errores del usuario, estética de la interfaz del usuario y accesibilidad. Las sub-características contienen veintidós

Modelo propuesto 49

medidas. Sin embargo, se seleccionan seis medidas en total, las cuales se describen en la Tabla 22. Tabla 22. Función de medición de la calidad del producto para el estado usable (1 de 2; Elaboración propia con base en ISO/IEC 2016).


Reconocimiento de adecuación

Descripción completa

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de uso de escenarios descritos en la descripción del producto o en los documentos del usuario B = número de uso de escenarios del producto

Proporción de escenarios de uso que se presentan en la descripción del producto o en los documentos del usuario. La funcionalidad que proporciona el sistema se probó. Además, el sistema se documenta totalmente.

Aprendizaje

Interfaz de usuario auto explicativa

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de información y pasos que se presentan en una forma en que el usuario podría entender B = número de elementos de información y pasos para completar tareas comunes para un usuario por primera vez

Proporción de elementos de información y pasos presentados al usuario que le permite completar tareas comunes sin previo entrenamiento

Interfaz de usuario

Aspecto estético de las interfaces de usuario

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de interfaces de pantalla estéticamente agradables a los usuarios en apariencia B = número de interfaces de pantalla

Grado de satisfacción de la apariencia del diseño de la interfaz de usuario

Operabilidad

Consistencia operacional

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de tareas interactivas específicas que se realizan de manera inconsistente B = número de tareas interactivas específicas que deben ser coherentes

Grado en que un producto o sistema tiene atributos que lo hacen fácil de operar y controlar. Además, el sistema lo pueden operar las partes interesadas que lo utilizan


Tabla 22. Función de medición de la calidad del producto para el estado usable (2 de 2; Elaboración propia con base en ISO/IEC 2016).


Operabilidad

Categorización comprensible de la información

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de estructuras de información que son familiares y convenientes para los usuarios previstos B = número de estructuras de información usadas

Grado en que con el software se organiza la información en categorías convenientes para los usuarios

Protección de error de usuario

Corrección de error de entrada del usuario

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de errores de usuario que se diseñan y se validan B = número de errores de usuario que ocurren durante la operación

Grado en que con el sistema se protege a los usuarios contra errores detectados

En el estado listo se identifican diferentes relaciones con las características de usabilidad, confiabilidad y seguridad. Con las medidas de confiabilidad “se evalúa el grado en el que con el sistema, producto o componente se realizan funciones bajo condiciones específicas durante un período dado”. La confiabilidad tiene cuatro sub-características: madurez, disponibilidad, tolerancia a fallos y capacidad de recuperación. Las medidas de seguridad “se utilizan para evaluar el grado en que con un producto o sistema se protege la información y los datos para que las personas u otros productos o sistemas tengan el grado de acceso apropiado a los datos y a sus niveles de autorización”. La seguridad tiene cinco sub-características: confidencialidad, integridad, no repudio, responsabilidad y autenticidad (ISO/IEC, 2016). Cada una de estas características tiene 11 medidas. Se seleccionan cuatro medidas debido al significado y a su relación directa con el estado listo. En la Tabla 23 se muestra la función de medición y la principal razón de selección.

Modelo propuesto 51

Tabla 23. Función de medición de la calidad del producto para el estado listo (Elaboración propia con base en ISO/IEC 2016).


Aprendizaje

Integridad de la guía del usuario

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de funciones que se describen en la documentación del usuario B = número de funciones implementadas que se requiere documentar

Proporción de funciones que se explican detalladamente en la documentación del usuario. Además, la instalación y la documentación se encuentran disponibles

Operabilidad


𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de tareas interactivas específicas que se realizan de manera inconsistente

B = número de tareas interactivas específicas que deben ser coherentes


Tolerancia a fallos

Evitación de fallos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de incidentes críticos y graves que se evitan (respecto de casos de prueba) B = número de casos de prueba que se ejecutan con un patrón de fallas durante la prueba

Grado en el que el producto funciona a pesar de la presencia de fallas de hardware o software

Integridad

Integridad de los datos

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de elementos de datos que se dañan por un acceso no autorizado B = número de elementos de datos que deben evitar la corrupción o modificación de datos

Grado en el que con el producto se previenen accesos o modificaciones no autorizados a los datos y computadores

En el estado operacional se presenta una relación con las características usabilidad, portabilidad, confiabilidad, compatibilidad y mantenibilidad. Con las medidas de mantenibilidad “se evalúa el grado en el cual un sistema o programa de cómputo se integra con componentes discretos, de modo que un cambio en un componente tiene un impacto


mínimo en otros componentes”. La mantenibilidad tiene cinco sub-características: modularidad, reutilización, analizabilidad, modificabilidad y testabilidad. Las medidas de portabilidad “se utilizan para evaluar el grado de efectividad y eficiencia con que un sistema, producto o componente se puede transferir desde un hardware, software u otro entorno operativo o de uso a otro”. La portabilidad tiene tres sub-características: adaptabilidad, instalación y reemplazabilidad (ISO/IEC, 2016). Cada una de estas características tienen 13 y nueve medidas respectivamente. En la Tabla 24 se muestran las ocho medidas seleccionadas con la función de medición y la principal razón de medición. Tabla 24. Función de medición de la calidad del producto para el estado operacional (1 de 2; Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección Operabilidad


𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de tareas interactivas específicas que se realizan de manera inconsistente

B = número de tareas interactivas específicas que deben ser coherentes


Personalización funcional

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de funciones y procedimientos operacionales que se personalizan a conveniencia del usuario B = número de funciones y procedimientos operacionales que benefician a los usuarios debido a la personalización

Grado en que las funciones y procedimientos operacionales se personalizan a conveniencia del usuario

Personalización de la interfaz de usuario

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de interfaces de usuario que se personalizan B = número de elementos de interfaces de usuario que se benefician de la personalización

Proporción de elementos de interfaz de usuario que se personalizan en apariencia.

Modelo propuesto 53

Tabla 24. Función de medición de la calidad del producto para el estado operacional (2 de 2; Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección Analizabilidad

Integridad del registro del sistema

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de registros que se graban en el sistema B = número de registros para los que se requieren pistas de auditoría durante la operación

Grado en el que con el sistema se graban operaciones en registros. Además, se pueden controlar las operaciones

Disponibilidad

Disponibilidad del sistema

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = tiempo real de operación del sistema B = tiempo programado para la operación del sistema

Proporción del tiempo en que el sistema está realmente disponible versus el tiempo de funcionamiento programado

Adaptabilidad

Adaptabilidad del sistema de software al entorno

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de funciones incompletas o insuficientes que no cumplen los requisitos durante las pruebas B = número de funciones que se prueban en diferentes entornos de software

Grado en que el sistema o producto se adapta a diferentes entornos de software

Adaptabilidad del entorno operacional

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de funciones incompletas o insuficientes que no cumplen los requisitos durante las pruebas operativas B = número de funciones que se prueban en diferentes entornos operativos

Grado en que el sistema o producto se adapta a diferentes entornos operativos

Coexistencia

Coexistencia con otros productos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de otros productos de software con los que el producto coexiste B = número de otros productos que coexisten con este producto en el entorno de operación

Grado en el que el producto comparte el entorno con otro software sin afectar negativamente sus características y funcionalidades de calidad


Para el estado retirado, se seleccionan cuatro medidas de las características mantenibilidad y portabilidad, las cuales tienen relación directa con el estado. Las medidas apropiadas se describen en la Tabla 25. Tabla 25. Función de medición de la calidad del producto para el estado retirado (Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección Modificabilidad

Eficiencia de modificación

𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐴𝐴)/𝑛𝑛𝑖𝑖=1𝑡𝑡𝑡𝑡𝑡𝑡

Ai = tiempo total que se gasta para realizar una modificación específica i; Bi = tiempo esperado para hacer una modificación específica i; n = número de modificaciones medidas

Proporción del tiempo empleado en las modificaciones que se realizan

Capacidad de modificación

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos que se modifican en una duración especifica B = número de elementos que se requieren modificar en una duración específica

Proporción de modificaciones que se realizan en una duración especifica

Reemplazabilidad

Inclusión funcional

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de funciones que producen resultados similares B = número de funciones que se utilizan en el producto de software reemplazado

Proporción de funciones del producto que se usan fácilmente después de reemplazar el producto de software

Capacidad de reutilización o importación de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de datos que se usan continuamente B = número de datos que se usan continuamente en el producto de software reemplazado

Proporción de datos del producto que se usan después de reemplazar el producto de software

Modelo propuesto 55

4.2.3. Medidas de la calidad del dato (ISO/IEC 25024)

relacionadas con los estados del alfa En la Tabla 26 se muestra la relación de los estados del alfa sistema de software con las medidas de la calidad del dato identificadas en la norma ISO/IEC 25024. Tabla 26. Relación de los estados del alfa sistema de software con las medidas de la calidad del dato (1 de 2; Los autores).



Se acordaron los criterios para seleccionar la arquitectura

8.4 - Con-I-4 Consistencia de la arquitectura

8.8 - Cmp-I-2 Cumplimiento normativo debido a la tecnología

Demostrable

Se demostraron las características clave de la arquitectura

8.4 - Com-I-2 Consistencia del formato de datos

Los interesados relevantes acordaron que la arquitectura es apropiada

8.4 - Com-I-4 Consistencia de la arquitectura

Usable


8.2 - Acc-I-8 Exactitud del modelo de datos

8.4 - Con-I-2 Consistencia del formato de datos

8.5 - Cre-I-1 Credibilidad de los valores

8.5 - Cre-I-4 Credibilidad del modelo de datos

8.9 - Cnf-I-1 Uso de cifrado 8.9 - Cnf-D-1 No vulnerabilidad

8.11 - Pre-I-1 Precisión de los valores de los datos

8.13 - Und-I-4 Comprensión de los valores de los datos

8.14 - Ava-D-1 Proporción de disponibilidad de datos

8.15 - Por-D-1 Proporción de portabilidad de datos

8.16 - Rec-D-1 Proporción de recuperabilidad de datos

Los usuarios pueden operar el sistema

8.10 - Eff-I-2 Eficiencia de utilización

8.10 - Eff-D-2 Eficiencia de procesamiento de datos


Tabla 26. Relación de los estados del alfa sistema de software con las medidas de la calidad del dato (2 de 2 Los autores).


Listo Los representantes de los interesados quieren que se haga operacional el sistema

8.3 - Com-I-1 Registro completo

8.3 - Com-I-6 Modelo conceptual de datos completo

8.3 - Com-I-8 Metadatos completos

Operacional

El sistema está disponible para los usuarios previstos 8.7 - Acs-I-1 Accesibilidad del usuario


8.8 - Cmp-I-1 Cumplimiento normativo del valor y/o formato

8.12 - Tra-D-2 Trazabilidad del valor de los datos


8.14 - Ava-D-1 Proporción de disponibilidad de datos

8.15 - Por-D-1 Proporción de portabilidad de datos

8.16 - Rec-D-1 Proporción de recuperabilidad de datos

Retirado No se producirán más actualizaciones al sistema 8.6 - Cur-I-1 Frecuencia de

actualización Las medidas de la calidad del dato presentan una mayor relación con los estados usable y operacional, sin dejar de mantener una relación con algunas medidas de los otros estados del alfa. En el estado con arquitectura seleccionada se identifica una relación directa con las características consistencia y conformidad y sus respectivas medidas. Las medidas de calidad (QMs) para consistencia “se relacionan con el grado en el cual el dato tiene atributos que son libres de contradicción y son coherentes con otros datos en un contexto de uso específico” y las QMs para conformidad “representan el grado en que el dato tiene atributos que se adhieren a los estándares, convenciones o regulaciones vigentes y reglas similares relacionadas con la calidad del dato en un contexto de uso específico” (ISO/IEC, 2016). Las características contienen seis y dos medidas respectivamente. Sin embargo, se seleccionan dos medidas debido a su relación con el estado con arquitectura seleccionada. En la Tabla 27 se muestran la función de medida y la principal razón de selección.

Modelo propuesto 57

Tabla 27. Función de medición de la calidad del dato para el estado con arquitectura seleccionada (Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección QMs de consistencia

Consistencia de la arquitectura

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de una arquitectura que tienen un elemento referenciado correspondiente en la arquitectura instalada B = número de elementos de la arquitectura referenciada

Grado en el que los elementos de la arquitectura tienen una correspondencia con algún elemento de la arquitectura referenciada

QMs de conformidad

Cumplimiento normativo debido a la tecnología

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato que se ajustan a los estándares o regulaciones debido a la tecnología B = número de elementos del dato que se deben ajustar a los estándares o regulaciones debido a la tecnología

Grado en el que los elementos del dato cumplen con estándares o regulaciones específicas

De otra parte, en la Tabla 28 se muestran dos medidas seleccionadas de la característica consistencia, las cuales tiene relación directa con el estado demostrable. Tabla 28. Función de medición de la calidad del dato para el estado demostrable (1 de 2; Elaboración propia con base en ISO/IEC 2016).


QMs de consistencia

Consistencia del formato de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato donde el formato de todas las propiedades es consistente en diferentes archivos de datos B = número de elementos para los cuales se define la consistencia del dato

Grado en el que la consistencia del formato de datos se mantiene con los mismos elementos del dato


Tabla 28. Función de medición de la calidad del dato para el estado demostrable (2 de 2; Elaboración propia con base en ISO/IEC 2016).


QMs de consistencia

Consistencia de la arquitectura

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de una arquitectura que tienen un elemento referenciado correspondiente con la arquitectura instalada B = número de elementos de la arquitectura referenciada

Grado en el que los elementos de la arquitectura tienen una correspondencia con algún elemento de la arquitectura referenciada

En el estado usable se identifica una relación con la mayoría de las características de la calidad del dato: exactitud, consistencia, credibilidad, confidencialidad, eficiencia, precisión, comprensibilidad, disponibilidad, portabilidad y recuperabilidad. Las medidas de exactitud “proveen el grado en el cual el dato tiene atributos que representan correctamente el valor real de los atributos previstos de un concepto o evento en un contexto de uso específico”. En las medidas de credibilidad “se garantiza que los atributos del dato son verdaderos y creíbles para los usuarios”. Con las medidas de confiabilidad “se asegura que los atributos del dato son sólo accesibles e interpretables para usuarios autorizados”. En las medidas de eficiencia “se proveen los niveles de rendimiento esperados para el uso de cantidades y tipos de recursos apropiados”. Con las medidas de precisión “se garantiza que el dato tiene atributos que son exactos o proporcionan discriminación”. Las medidas de entendimiento “permiten que los usuarios lean e interpreten los atributos del dato y los expresen en lenguajes, símbolos y unidades apropiadas”. Las medidas de disponibilidad “permiten que los atributos del dato se recuperen para usuarios autorizados o aplicaciones en un contexto de uso específico”. En las medidas de portabilidad “se preserva la calidad de los atributos del dato instalados o movidos desde un sistema a otro”. Las medidas de recuperabilidad se definen como “el grado en el que el dato tiene atributos que mantienen y preservan un específico nivel de operaciones y calidad, aún en el evento de fallos, en un contexto de uso específico” (ISO/IEC, 2016). En la Tabla 29 se muestran las medidas con sus respectivas funciones de medición y razones de selección.

Modelo propuesto 59

Tabla 29. Función de medición de la calidad del dato para el estado usable (1 de 3; Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección QMs de exactitud

Exactitud del modelo de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del modelo de datos con los que se describe la exactitud del sistema B = número de elementos del modelo de datos con los que se describe la exactitud requerida dentro de la especificación de requisitos del sistema

Grado en el que con el modelo de datos se describe el sistema con la exactitud requerida

QMs de consistencia

Consistencia del formato de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato donde el formato de todas las propiedades es consistente en diferentes archivos de datos B = número de elementos para los cuales se define la consistencia del dato

Grado en el que la consistencia del formato de datos se mantiene con los mismos elementos del dato

QMs de credibilidad

Credibilidad de los valores

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de información donde se validan y se certifican los valores para un proceso específico B = número de elementos de información que se necesita validar y certificar

Grado en el que los elementos de información se consideran verdaderos, reales y creíbles

Credibilidad del modelo de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de un modelo de datos con definiciones apropiadas que se validan y certifican en un proceso específico B = número de elementos de un modelo de datos

Grado en el que con el modelo de datos se provee información creíble



Medida Función de medición Principal razón de selección QMs de confidencialidad

Uso de cifrado

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de valores del dato que se codifican y decodifican correctamente B = número de valores del dato con requisitos para codificación o decodificación

Grado en el que los valores del dato cumplen los requisitos de cifrado o codificación

No vulnerabilidad

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = número de accesos que usuarios no autorizados realizan con éxito durante intentos formales de penetración para alcanzar el elemento del dato objetivo en un período específico B = número de accesos que los usuarios no autorizados realizan al dato objetivo en un período específico

Grado en el que el elemento del dato confidencial lo pueden acceder solamente usuarios autorizados

QMs de eficiencia

Eficiencia utilizable

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de valores del dato que los usuarios evalúan como ‘fácilmente usados’ B = número de valores del dato que evalúan los usuarios

Proporción de los valores del dato que permiten un fácil uso a los futuros usuarios

Eficiencia del procesamiento de datos

𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 A = tiempo perdido debido a la representación de los elementos del dato durante un trabajo B = tiempo de procesamiento

Proporción del tiempo que se pierde debido a la representación del elemento del dato

QMs de precisión

Precisión de los valores del dato

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de los valores del dato con la precisión requerida B = número de valores del dato con el requisito de precisión definido

Grado de precisión de los valores del dato de acuerdo con la especificación definida en el requisito

Modelo propuesto 61


Medida Función de medición Principal razón de selección QMs de entendimiento

Entendimiento de los valores del dato

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de los valores del dato que los usuarios entienden fácilmente B = número de los valores del dato que los usuarios intentan entender durante un período de observación

Proporción de los valores del dato que los usuarios entienden en un contexto específico de uso

QMs de disponibilidad

Relación de disponibilidad de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato disponibles en un período específico B = número de elementos del dato que se requieren en el mismo periodo

Proporción de los elementos del dato disponibles cuando se requieren (ej. copias de seguridad o procedimientos de restauración)

QMs de portabilidad

Relación de portabilidad de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato con los que se preserva la calidad existente después de la migración B = número de elementos del dato migrados

Proporción de la calidad del dato que no disminuye después del proceso de migración

QMs de recuperabilidad

Relación de recuperabilidad del dato

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato que se recuperan exitosamente B = número de elementos del dato que se deben recuperar

Grado en el que los datos almacenados en un dispositivo se recuperan exitosamente

Por otra parte, en el estado listo se presenta una relación consecuente con la característica completitud. Las medidas de completitud “proveen el grado en el que los datos asociados con una entidad objetivo esperan valores para todas las propiedades relacionadas en un contexto de uso específico” (ISO/IEC, 2016). Las medidas seleccionadas se muestran en la Tabla 30.


Tabla 30. Función de medición de la calidad del dato para el estado listo (Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección QMs de completitud

Completitud del registro

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato con valores no nulos en un registro B = número de elementos del dato del registro para el cual la completitud se mide

Grado de completitud de los elementos del dato de un registro en un archivo de datos

Completitud del modelo conceptual de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de entidades del modelo de datos conceptual B = número de entidades del modelo de datos conceptual con los que se describe completamente el esquema contextual

Proporción de las entidades que se describen completamente en el modelo conceptual de datos y en el esquema contextual

Completitud de los metadatos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de atributos con metadatos completos dentro del diccionario de datos B = número de atributos para el cual los metadatos se esperan dentro del diccionario de datos

Grado de completitud de atributos para los metadatos

En el estado operacional se presentan relaciones directas con seis características de la calidad del dato: accesibilidad, conformidad, trazabilidad, portabilidad, disponibilidad y recuperabilidad y algunas de sus medidas, las cuales se describen en la Tabla 31. Las medidas de accesibilidad “proveen el grado en el que el dato lo pueden acceder en un contexto de uso específico, particularmente personas que necesitan tecnología de apoyo o configuración especial debido a alguna discapacidad”. Las medidas de trazabilidad “proporcionan un camino de auditoria o acceso a los datos y a cualquier cambio que se realiza en un contexto de uso específico” (ISO/IEC, 2016).

Modelo propuesto 63

Tabla 31. Función de medición de la calidad del dato para el estado operacional (1 de 2; Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección QMs de accesibilidad

Accesibilidad del usuario

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato relevantes para las tareas del usuario dentro de un contexto de uso específico que tienen valores accesibles B = número de elementos del dato que son relevantes para las tareas del usuario dentro de un contexto de uso específico que tienen valores que se requiere acceder de conformidad con la especificación

Grado en el que los valores del dato son accesibles para los usuarios

QMs de conformidad

Cumplimiento normativo debido a la tecnología

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato que se ajustan a los estándares o regulaciones debido a la tecnología B = número de elementos del dato que se deben ajustar a los estándares o regulaciones debido a la tecnología

Grado en el que los elementos del dato cumplen con estándares o regulaciones específicas

QMs de trazabilidad

Trazabilidad del valor del dato

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato que se pueden rastrear usando las capacidades del sistema B = número de elementos del dato que se espera rastrear utilizando las capacidades del sistema

Grado de rastreabilidad de la historia de los elementos del valor del dato usando las capacidades del sistema

QMs de disponibilidad

Relación de disponibilidad de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato disponibles en un período específico B = número de elementos del dato que se requieren en el mismo periodo

Proporción de los elementos del dato disponibles cuando se requieren (ej. copias de seguridad o procedimientos de restauración)


Tabla 31. Función de medición de la calidad del dato para el estado operacional (2 de 2; Elaboración propia con base en ISO/IEC 2016).

Medida Función de medición Principal razón de selección QMs de portabilidad

Relación de portabilidad de datos

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato con los que se preserva la calidad existente después de la migración B = número de elementos del dato migrados

Proporción de la calidad del dato que no disminuye después del proceso de migración

QMs de recuperabilidad

Relación de recuperabilidad del dato

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos del dato que se recuperan exitosamente B = número de elementos del dato que se deben recuperar

Grado en el que los datos almacenados en un dispositivo se recuperan exitosamente

En cuanto al estado retirado se identifica una relación con la característica actualidad y una de sus medidas (véase la Tabla 32). Las medidas de actualidad “ayudan a identificar que los atributos del dato son de la edad correcta en un contexto de uso específico” (ISO/IEC, 2016). Tabla 32. Función de medición de la calidad del dato para el estado retirado (Elaboración propia con base en ISO/IEC 2016).


QMs de actualidad

Frecuencia de actualización

𝑋𝑋 = 𝐴𝐴/𝐵𝐵 A = número de elementos de datos actualizados con la frecuencia requerida B = número de elementos de datos que tienen un requisito de frecuencia de actualización

Grado en el que los elementos del dato se actualizan con la frecuencia requerida

Modelo propuesto 65

4.3. Representación en el núcleo de Semat del alfa sistema de software y de las medidas identificadas en la ISO/IEC 2502n

La relación de las medidas identificadas en la ISO/IEC 25023 y los estados del alfa sistema de software se muestran en diferentes representaciones en el núcleo de Semat usando los elementos de la Tabla 1. En la Figura 24 se muestra una relación completa entre el estado con arquitectura seleccionada con su respectiva lista de chequeo y las relaciones establecidas con la ISO/IEC 25000, que para este caso en particular se realiza con las medidas seleccionadas de las divisiones de la calidad en uso (ISO/IEC 25022), calidad del producto (ISO/IEC 25023) y la calidad del dato (ISO/IEC 25024). En la parte (a) de la representación, el estándar se asocia con un espacio de actividad denominado ‘probar el sistema’, el cual se conecta mediante una asociación con cada uno de los ítems de la lista de chequeo del estado con arquitectura seleccionada: i) se selecciona la arquitectura que trata los riesgos técnicos clave; ii) se acuerdan los criterios para seleccionar la arquitectura; iii) se seleccionan las plataformas, tecnologías y lenguajes; y iv) se toman las decisiones de compra, construcción y reuso (véase la Tabla 5). Todas estas actividades se ejecutan en la fase de desarrollo. Adicionalmente, en la parte (b), se muestra la practica asociada con el alfa sistema de software y los productos de trabajo definidos: registro de defectos, lista de verificación de desarrollo y resultados de aceptación. Cada ítem de la lista de chequeo descrito en la parte (a) se conecta con el producto de trabajo identificado durante la investigación, se vincula al rol de desarrollador mediante el uso de la relación ‘trabajar en’. Por otra parte, en el primer elemento de este estado, el desarrollador puede seleccionar del estándar ISO/IEC 25000 las medidas que necesite aplicar durante la evaluación de la calidad del producto de software.


Figura 24. Representación Semat de (a) medición de la calidad basada en estándares del estado con arquitectura seleccionada del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores).

En la Figura 25 se muestra la representación en el núcleo de Semat del estado demostrable. El alfa sistema de software se asocia con los productos de trabajo: registro de defectos, lista de verificación de desarrollo y resultados de aceptación; y la lista de chequeo del estado demostrable: i) se demuestran las características clave de la arquitectura; ii) las partes interesadas acuerdan que la arquitectura es apropiada; y se ejerce la interfaz crítica y las configuraciones del sistema. Las medidas se pueden seleccionar de la norma ISO/IEC 25000 durante la primera actividad.

Modelo propuesto 67

Figura 25. Representación Semat de (a) medición de la calidad basada en estándares del estado demostrable del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores).

En la Figura 26 se muestra la representación en el núcleo de Semat del estado usable. El alfa sistema de software se asocia con los productos de trabajo: registro de defectos, lista de verificación de desarrollo y resultados de aceptación; y la lista de chequeo del estado usable: i) el sistema es usable y tiene las características de calidad deseadas; ii) los usuarios pueden operar el sistema; iii) se acepta la funcionalidad y el rendimiento; iv) se aceptan los niveles de defectos; y v) se conoce el contenido de liberación. Las medidas se pueden seleccionar de la norma ISO/IEC 25000 durante la primera actividad.


Figura 26. Representación Semat de (a) medición de la calidad basada en estándares del estado usable del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores).

En la Figura 27 se muestra la representación en el núcleo de Semat del estado listo. El alfa sistema de software se asocia con los productos de trabajo: registro de defectos, lista de verificación de desarrollo y resultados de aceptación; y la lista de chequeo del estado listo: i) se pone a disposición la documentación del usuario; ii) los representantes de los interesados aceptan el sistema; y iii) los representantes de los interesados quieren que se haga operacional el sistema. Las medidas se pueden seleccionar de la norma ISO/IEC 25000 durante la primera actividad.

Modelo propuesto 69

Figura 27. Representación Semat de (a) medición de la calidad basada en estándares del estado listo del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores)

En la Figura 28 se muestran la relación entre el estado operacional y las medidas en la representación del núcleo de Semat. El alfa sistema de software se asocia con un producto de trabajo extra: reporte de niveles de servicio y la lista de chequeo del estado operacional: i) el sistema se usa en un ambiente operacional; ii) el sistema está disponible para los usuarios previstos; iii) al menos un ejemplo del sistema es completamente operacional; y iv) el sistema es compatible con los niveles de servicio acordados. Las medidas se pueden seleccionar de la norma ISO/IEC 25000 durante la primera actividad.


Figura 28. Representación Semat de (a) medición de la calidad basada en estándares del estado operacional del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores).

En la Figura 29 se muestra la representación en el núcleo de Semat del estado retirado. El alfa sistema de software se asocia con los productos de trabajo: registro de defectos, lista de verificación de desarrollo, reporte de niveles de servicio y resultados de aceptación; y la lista de chequeo del estado retirado: i) no se da más soporte al sistema; ii) no se producen más actualizaciones al sistema; y iii) se reemplaza o se descontinua el sistema. Las medidas se pueden seleccionar de la norma ISO/IEC 25000 durante la primera actividad.

Modelo propuesto 71

Figura 29. Representación Semat de (a) medición de la calidad basada en estándares del estado retirado del alfa del sistema de software; (b) norma ISO/IEC 25000 y productos de trabajo para evaluar los estados alfa (Los autores).

La representación en el núcleo de Semat de las medidas seleccionadas de las normas ISO/IEC 25022 (calidad en uso) e ISO/IEC 25024 (calidad del dato) mantienen la misma estructura, listas de chequeo y productos de trabajo que se describen en las representaciones de los estados del alfa sistema de software y las medidas de la norma ISO/IEC 25023. Sin embargo, lo único que cambia es la selección de medidas desde el primer ítem de la lista de chequeo, las cuales se describen desde la Tabla 15 a la Tabla 18 para calidad en uso y desde la Tabla 27 a la Tabla 32 para calidad del dato.

4.4. Modelo final en esquemas preconceptuales En la Figura 30 se presenta el modelo para la medición del progreso del alfa sistema de software del núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n. Se usan esquemas preconceptuales para representar la funcionalidad del modelo. La implementación de esquemas preconceptuales ayuda a garantizar un modelo integral, ya que se conciben como herramienta para representar un problema de dominio que cualquiera puede usar y comprender (Zapata et al., 2011). El modelo se asocia con el estándar ISO/IEC 2502n e ISO/IEC 2504n. El modelo propuesto en esta Tesis Doctoral se diseña para utilizarlo desde el inicio del ciclo de vida de desarrollo y garantizar la salud y el progreso del alfa sistema de software. El público objetivo que se puede beneficiar al aplicar el modelo es la industria de software, las empresas jóvenes de desarrollo de software, los equipo de desarrollo integrados por gestores de proyectos,


analista de pruebas, desarrolladores, arquitectos y gestores de calidad; y todas las demás empresas que deseen medir y evaluar la calidad de sus productos desde los enfoques de la calidad en uso, del producto y del dato. Figura 30. Modelo para la medición del progreso del alfa del núcleo de Semat (Los autores).

El diseño del esquema preconceptual comprende los siguientes pasos. Se identifican 18 conceptos principales del núcleo de Semat y las normas ISO/IEC

2502n e ISO/IEC 2504n, los cuales son seleccionados de acuerdo a su importancia en el flujo de desarrollo del modelo y a su representación, como un atributo/componente que interactúan entre sí para la ejecución del proceso de medición y evaluación del alfa sistema de software. A continuación, se describe los conceptos y sus significados:

1. Estándar: documento que proporciona para uso común y repetido, reglas, guías o características para actividades o sus resultados, con el objetivo de lograr el grado óptimo de orden en un contexto dato (ISO/IEC 2010).

2. División: la división forma una familia de estándares que sirven para propósitos complementarios (ISO/IEC 2010).

3. Tipo: Son las categorías definidas para el desarrollo de un estándar.

Modelo propuesto 73

4. Alfa: Son representaciones de las cosas esenciales para trabajar. Los alfa

proporcionan descripciones del tipo de cosas que un equipo administrará, producirá y utilizará en el proceso de desarrollo, mantenimiento y soporte de software (Jacobson et al., 2013).

5. Estado: Son utilizados para evaluar el progreso y la salud de un alfa (Jacobson et al., 2013).

6. Característica: Una propiedad distintiva que es importante para identificar el dominio funcional al que pertenece un conjunto especifico de requisitos. (ISO/IEC, 2010).

7. Sub-característica: Atributo o propiedad de calidad del software que es refinada a partir de una característica de calidad (ISO/IEC, 2010).

8. Medida: Variable para el cual un valor es asignado como el resultado de una medición (ISO/IEC, 2016).

9. Identificación: Código o identificador de un tipo de medida. 10. Descripción: Elementos y detalles explícitos de una medida. 11. Función de medición: Una función de medición es un algoritmo utilizado para

combinar elementos de medición de calidad. El resultado de aplicar una función de medición se denomina medición de calidad de software. De esta forma, las medidas de calidad del software se convierten en cuantificaciones de las características y subcaracterísticas de calidad (ISO/IEC, 2010).

12. Evaluación: Proceso o guía detallada para el desarrollo de actividades de verificación y validación de un producto, sistema o aplicación.

13. Rol: Actividad/tarea que desarrolla un actor interno o externo al sistema. Un actor puede ser una persona, un dispositivo, otro sistema o subsistema o tiempo. Los actores representan los diferentes roles que algo externo tiene en su relación con el sistema cuyos requisitos funcionales se están especificando (ISO/IEC, 2010).

14. Proceso: Sistema de actividades, que utiliza recursos para transformar entradas en salidas (ISO/IEC, 2011).

15. Entradas: Son especificaciones o requisitos específicos como insumo para el proceso de evaluación de la calidad del software (ISO/IEC, 2011).

16. Restricciones: incluye los recursos, el tiempo, costo, contexto, herramientas, metodología y necesidades específicas de los usuarios (ISO/IEC, 2011).

17. Recursos: Se representan en tiempo, costo y recursos humanos destinados para el desarrollo de una actividad específica.

18. Resultados: Hallazgos identificados durante el proceso de medición y evaluación.

Se identifican posibles relaciones entre los conceptos como se muestra en la Figura

31.


Figura 31. Relaciones entre conceptos (Los autores).

Se identifican conceptos complementarios para relacionar diferentes partes del modelo como nombre, fórmula, variable, descripción variable, requisito, medida, criterio, diseño, reporte y plan de actividades.

Se construye el modelo para la medición del progreso del alfa sistema de software del

núcleo de Semat con base en las normas ISO/IEC 2502n e ISO/IEC 2504n. Cada concepto del esquema preconceptual se requiere para direccionar el problema principal que se identifica en los antecedentes de esta Tesis Doctoral, el cual se enfoca en relacionar el núcleo Semat con las normas ISO/IEC 2502n e ISO/IEC 2504n para medir la salud y el progreso de un esfuerzo de ingeniería de software y mejorar la calidad del producto desarrollado. La estructura del esquema preconceptual y la representación en Semat ayudan a garantizar un modelo de medición y evaluación internacional para el estado sistema de software el cual los desarrolladores de software, probadores y líderes de proyecto puedan entender y usar. Se seleccionan algunas medidas identificadas de la norma ISO/IEC 2502n y un ejemplo del proceso de evaluación (ISO/IEC 2504n) para representar la funcionalidad del modelo, En la Figura 32 se propone un esquema preconceptual ejecutable para representar la medida consistencia operacional. Los esquemas preconceptuales ejecutables se adecúan para ilustrar los conceptos principales de un esquema preconceptual con el fin de validar su significado (Zapata et al., 2011).

Modelo propuesto 75

Figura 32. Esquema preconceptual ejecutable representando la medida corrección de error de entrada de usuario de la característica usabilidad (Los autores).

El esquema de la Figura 32, permite ejecutar el flujo de desarrollo del modelo para la medición de la salud y el progreso de los estados del alfa sistema de software en un caso práctico. El esquema será utilizado para verificar y validar las medidas y la implementación del modelo en un proyecto real en la industria del software.


5. Caso de estudio

5.1. Evaluación del modelo para la medición del progreso del alfa sistema de software del núcleo de Semat

El caso de estudio se utiliza para evaluar los métodos de desarrollo y para observar, explicitar y explorar otros fenómenos en situaciones de la vida real (Yin, 1994). Por lo tanto, se obtiene una mayor comprensión acerca de por qué algo sucedió, cómo sucedió y qué otro criterio es importante para una mayor investigación. Los casos de estudio implican un examen a profundidad de un solo caso o un pequeño número de casos. Este método proporciona una forma sistemática de observar eventos, recopilar datos, analizar información y reportar resultados. Comúnmente, se investigan una o más preguntas de investigación (Verner & Abdullah, 2012). El método incluye seis fases: planificación previa, planificación del estudio de caso, diseño, recopilación de datos, análisis de datos e informes. Planificación previa Se utiliza el método GQM (Goal Question Metric; Basili et al., 2007), con el cual se define el objetivo de investigación, la pregunta de investigación (RQ; Research Question) y la métrica para el caso de estudio (véase la Figura 33). Planificación del caso de estudio Se necesita establecer la pregunta de investigación (RQ) y definir la hipótesis de investigación (H).

RQ. ¿Cuáles son los puntos de vista del equipo de desarrollo de software sobre las relaciones entre las medidas y los estados del alfa sistema de software del núcleo de Semat para evaluar la salud y el progreso de un esfuerzo en ingeniería de software?

Modelo propuesto 77

H. SI el equipo de desarrollo de software identifica más del 65% de las relaciones entre las medidas y los estados del alfa, ENTONCES el modelo para evaluar la salud y el progreso del sistema de software se acepta. La hipótesis se establece de acuerdo con la naturaleza de las características (atributos) inspeccionadas, que para este caso de estudio se representan con las medidas y los estados del alfa sistema de software. Además, las características se expresan en términos de aceptación o rechazo. Figura 33. Método GQM (Basili et al., 2007).

Diseño

Se define un protocolo de caso de estudio formal. Por ello, se sigue la guía y recomendaciones de Maimbo y Pervan (2005) que citan Runesson y Höst (2008). Se diseña una entrevista y se implementa el protocolo del estudio original (véase la Tabla 33). Uno de los elementos del protocolo es un formulario de consentimiento informado que firman las partes involucradas (investigador y participante) al protocolo de la entrevista. En el formulario de consentimiento, el investigador se compromete a mantener uso confidencial de la información que suministra la empresa y los productos relacionados con el estudio.

Los principales criterios para seleccionar a los desarrolladores de software son: i) estar empleado en una compañía de desarrollo de software en Sídney, Australia; ii) tener mínimo dos años de experiencia; iii) ser desarrollador de software junior/senior.

Caso de estudio


Tabla 33. Protocolo del estudio de caso según Maimbo y Pervan (2005)

Sección Contenido

Preámbulo Contiene información sobre el propósito del protocolo y guías para el almacenamiento de datos y documentos

General Proporciona una breve descripción del proyecto de investigación y el método de investigación de caso

Procedimientos Descripción detallada de los procedimientos para llevar a cabo cada caso, incluidos detalles prácticos sobre los contactos y el calendario

Instrumentos Guías de entrevista, cuestionarios, etc., que se utilizan para garantizar una recopilación de datos coherente

Guía análisis de datos

Descripción detallada de los procedimientos de análisis de datos, incluidos esquemas de datos, códigos a priori, etc.

Esquema preconceptual ejecutable

Validación del modelo para evaluar la salud y el progreso del alfa sistema de software en un esfuerzo en ingeniería de software con una medida que los participantes seleccionan.

Los formatos que se utilizan en el caso de estudio, se presentan en las Figuras 34, 35 y 36 y la Tabla 34 en inglés y la validación del modelo en un esquema preconceptual ejecutable. Figura 34. Consentimiento informado (Los autores).

Modelo propuesto 79

Figura 35. Carta de participación (Los autores).

Figura 36. Entrevista (Los autores).

Caso de estudio


Tabla 34. Elementos de la entrevista (1 de 6; Los autores)

4. Is there any relationship between the architecture selected state and the following related measures? Do you have any comments?

State Checklist Measure formula Rationale Accept / Reject Comments

Architecture

selected

Architecture selected that addresses key technical risks

Functional coverage: 𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵

A = number of functions missing B = number of functions specified

The proportion of the specified functions and criteria be used when selecting the architecture have been agree on. The proportion of functions and criteria provides the correct results. An incorrect function is one that does not provide a reasonable and acceptable outcome to achieve the specific intended objective.

Functional correction: 𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵

A = number of functions that are incorrect B = number of functions considered

Criteria for selecting architecture agree on

Architecture consistency: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of elements of an architecture that have a corresponding referenced elements in the installed architecture B = number of elements of the referenced architecture

The proportion of the elements or functions for selecting architecture agreed on by the user provides appropriate outcome to achieve a specific usage objective.

Platforms, technologies, and language selected

Mean I/O devices utilization: 𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐴𝐴)

𝑖𝑖=1 𝑡𝑡𝑡𝑡 𝑡𝑡

/𝑛𝑛

Ai = duration of I/O device(s) busy time to perform a given set of tasks for i-th observation Bi = duration of I/O operations to perform the tasks for i-th observation n = number of observations

The degree to which the amounts and types of resources used by a product or system when performing its functions meet the requirements. Such requirements are platforms, technologies, and language to be used.

Modelo propuesto 81


5. Is there any relationship between the demonstrable state and the following related measures? Do you have any comments?


Demonstrable

Key architecture characteristics demonstrated

Functional appropriateness of system: 𝑋𝑋 = �𝐴𝐴𝐴𝐴/𝑛𝑛

Ai = Appropriateness score for usage objective i, that is, the measured value of specific usage objective n = number of usage objectives

The proportion of the functions and key architecture characteristics were demonstrated and required by the users to achieve their objectives and provide an appropriate outcome. The degree to which data has attributes that are free from contradiction and are coherent with other data in a specific context of use.

Data format consistency: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data items where the format of all properties is consistent in different data files B = number of data items for which format consistency can be defined

Relevant stakeholders agree architecture is appropriate

Overall satisfaction: 𝑋𝑋 = �𝐴𝐴𝐴𝐴

Ai = response to a question

The degree to which user needs are satisfied when a product or system is used in a specified context of use.

Critical interface and system configurations exercised

Data formats interchangeability: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data formats exchangeable with other software or system B = number of data formats specified to be exchangeable

The degree to which a product can perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product. In general, the integration with other existing systems has been demonstrated.

Caso de estudio



6. Is there any relationship between the usable state and the following related measures? Do you have any comments?


Usable

System is usable and has desired characteristics

Satisfaction with features: 𝑋𝑋 = �𝐴𝐴𝐴𝐴

Ai = response to a question related to a specific feature

The proportion of functions is explained in enough detail in user documentation and/or help facility to enable the user to apply the functions or features. The degree to which data item defined as confidential can be accessed by authorized users only.

Self-explanatory user interface: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of information elements and steps that are presented in a way that the user could understand B = number of information elements and steps needed to complete common tasks fir first time user

Non-vulnerability: 𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵

A = number of accesses successfully performed during formal penetration attempts by unauthorized users to reach target data item in a specific period of time B = number of accesses attempted by unauthorized users to target data item in a specific period of time

System can be operated by users

Operational consistency: 𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵

A = number of specific interactive tasks that are performed inconsistently B = number of specific interactive tasks that need to be consistent

The degree to which a product or system has attributes that make it easy to operate and control. Also, the system can be operated by stakeholders who use it.

Defect levels acceptable Functionality and performance have been tested and accepted

User entry correction: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of user errors that are designed and tested to recovered by the system B = number of user errors which can occur during operation

The degree to which the system protects users against making errors. Also, the performance of the system is acceptable for the final users.

Release content known

Understandable categorization of information: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of information structures that are familiar and convenient for the intended users B = number of information structures used

The software organizes the information in categories that are familiar to the intended users and convenient for their tasks. Also, the release content is known.

Modelo propuesto 83


7. Is there any relationship between the ready state and the following related measures? Do you have any comments?


Ready

User documentation available

User guidance completeness: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of functions described in user documentation and/or help facility as required B = number of functions implemented that are required to be documented

The proportion of functions is explained in enough detail in user documentation and/or help facility to enable the user to apply the functions. In addition, installation and another user documentation are available.

Stakeholders representatives accept system

Failure avoidance: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of avoided critical and serious failure occurrences (based on test cases) B = number of executed test cases of fault pattern (almost causing failure) during testing

The degree to which a system or product operates as intended despite the presence of hardware or software faults.

Stakeholders representatives want to make system operational

User trust: 𝑋𝑋 = 𝐴𝐴

A = Psychometric scale value from a trust questionnaire The degree to which a user or other

stakeholder has confidence that a product/system will behave as intended. The degree to which a system or product prevents unauthorized access to, or modification of, computer programs or data. Completeness of data items of a record within a data file.

Data integrity: 𝑋𝑋 = 1− 𝐴𝐴/𝐵𝐵

A = number of data items which are actually corrupted by unauthorized access B = number of data items for which data corruption or modification have to be prevented

Record completeness: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data items with associated value not null in a record B = number of data items for which completeness can be measured

Caso de estudio



8. Is there any relationship between the operational state and the following related measures? Do you have any comments?


Operational

System in use in operational environment

System log completeness: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of logs that are actually recorded in the system B = number of logs for which audit trail required during operation

The degree of effectiveness and efficiency with which it is possible to assess the impact on a product of an intended change to one or more of its parts, or to diagnose a product for deficiencies or causes of failure, or to identify parts to be modified.

System available to intended users

User accessibility: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data items relevant to the user’s task within specific context of use having values accessible by intended users B = number of data items that are relevant to the user’s task within the context of use having values that are required to be accessible in conformance to specification

The system is available in the system operational time schedule. That is means that the product or system can be extended to special days, such a holidays and weekend, in addition to regular operational days.

At least one example of system is fully operational

Time efficiency: 𝑋𝑋 = 𝐴𝐴/𝑇𝑇

A = number of objectives achieved T = Time

The efficiency with which users achieve their objectives over time when using the system.

System supported to agreed-on service levels

System software environmental adaptability: 𝑋𝑋 = 1− 𝐴𝐴/𝐵𝐵

A = number of functions which were not completed or results which were insufficient to meet requirement during testing B = number of functions which were tested in different system software environment

The degree to which a product can effectively and efficiently be adapted for different or evolving hardware, software or other operational or usage environments. The product can share the environment with other software without adverse impact on their quality characteristics or functionalities. Also, the system is fully supported to the agreed service levels.

Co-existence with other products: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of other specified software products with which this product can co-exist B = number of other software products specified to co-exist with this product in the operation environment

Modelo propuesto 85


9. Is there any relationship between the retired state and the following related measures? Do you have any comments?


Retired

System no longer supported

Modification efficiency: 𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐴𝐴)

𝑖𝑖=1 𝑡𝑡𝑡𝑡 𝑡𝑡

/𝑛𝑛

Ai = total work time spent for making a specific type of modification i Bi = expected time for making the specific type of modifications i n = number of modifications measured

The product can be effectively and efficiently modified without defects or degrading existing product quality. In addition, we can identify if the system has been replaced or discontinued. The proportion of items or modifications made within a specified duration. Also, we can find through updates if the system will no longer be produced and in fact, it is not needing any more modification.

Modification capacity: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of items actually modified within a specified duration B = number of items required to be modified within specified duration

Updates to system will no longer be produced

Update frequently: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data items updated with the required frequency B = number of data items having an update frequency requirement

The degree to which data has attributes that are of the right age in a specific context of use. In addition, when data items are updated with the frequency required.

System has been replaced or discontinued

Data reuse/import capability: 𝑋𝑋 = 𝐴𝐴/𝐵𝐵

A = number of data which can be used continuously as before B = number of data which are to be used continuously in the replaced software product

The same data of the product can be used after replacing previous software product by the own. That means that the developers can reuse or reproduce parts of the coding in another project or the same in another implementation.

Caso de estudio

Modelo propuesto 87

Las medidas por estado del alfa se seleccionan de acuerdo con los siguientes criterios y con el objetivo de aplicar una entrevista corta y comprensible para el participante: • Selección de mínimo una y máximo seis medidas de las normas ISO/IEC 25022,

ISO/IEC 25023 e ISO/IEC 25024 por estado del alfa.

• Relación explícita de las medidas con la lista de chequeo de los estados del alfa sistema de software.

• Se priorizan las medidas de la norma ISO/IEC 25023 que presentan mayor relación

con las listas de chequeo de los estados del alfa. Los estados agrupan el 37% del total de las medidas que se seleccionan para validar el modelo, lo cual representa 28 medidas sobre un total de 75 que se describen en el modelo. Para los estados con arquitectura seleccionada y retirado no se presenta relación con ninguna medida de calidad en uso de la norma ISO/IEC 25022 (véase la Tabla 35). Tabla 35. Cantidad de medidas a validar mediante el caso de estudio (Los autores).

Recopilación de datos El método principal para la recolección de datos es la entrevista semiestructurada, que se considera factible para este tipo de estudio descriptivo y explicativo (Lethbridge, Sim, & Singer, 2005; Yin, 1994). La entrevista tiene una duración de 30 minutos con cada participante e incluye una introducción y preguntas abiertas y cerradas. El instrumento consta de las siguientes secciones:

• Introducción • Antecedentes personales, grupales y de la empresa • Experiencias generales de calidad de productos de software y metodologías de

ingeniería de software • Validación del modelo para evaluar el estado y el progreso del alfa sistema de

software del núcleo de Semat

Estado Total medidas

ISO/IEC 25022Calidad en uso

ISO/IEC 25023Calidad del producto

ISO/IEC 25024Calidad del dato

Con arquitectura seleccionada 4 3 1

Demostrable 4 1 2 1Usable 6 1 4 1Listo 5 1 3 1Operacional 5 1 3 1Retirado 4 3 1Total seleccionadas para validar 28 4 18 6

(%) 37% 5% 13% 5%Total seleccionadas por estado 75 17 31 27

(%) 100% 23% 41% 36%

Caso de estudio


Se aplican 16 entrevistas semiestructuradas, que se realizan con los empleados de ocho empresas de desarrollo de software en Sídney, Australia. Las razones de la elección de las empresas en Australia y no en Colombia, se debe a la cercanía del investigador con las empresas y su residencia en Australia, debido al desarrollo de un proyecto de investigación en el país oceánico. Estas entrevistas se graban y se transcriben. Análisis de datos Las entrevistas se transcriben literal e integralmente. Antes de comenzar el análisis de datos, se estructuran las transcripciones en estados, características y tipos de medición según los diferentes criterios que se utilizan durante las entrevistas. Además, se implementan etiquetas y conceptos que se asignan en categorías y subcategorías teóricas y sus relaciones. Informes Runesson y Höst (2008) proporcionan ejemplos de informes de casos de estudio adecuados para que los informes académicos se adapten a este estudio. Además, el caso de estudio se informa de diferentes maneras a diversas audiencias como académicos y profesionales, es decir, documento de conferencia, periódico, póster, tesis, disertación, etc.

5.2. Validación del modelo propuesto En el proceso de validación se establece contacto directo con ocho empresas de desarrollo de software con oficinas en Sídney, Australia y dos empleados de cada compañía asignados en roles relacionados con desarrollo (desarrollador), pruebas de software (analista de pruebas) y gestión de proyectos (Líder de proyectos). Seguidamente, se establecen ocho reuniones con los participantes incluido el representante designado por la compañía y se contextualiza sobre el objetivo y el alcance del caso de estudio. El objetivo es validar desde el punto de vista de los equipos de desarrollo de software las relaciones entre las medidas de calidad en uso, del producto de software y del dato que se seleccionan en la investigación y los estados del alfa sistema de software del núcleo de Semat, los cuales se describen en el formato de la entrevista. Se revisa la documentación de soporte del caso de estudio (consentimiento informado y carta de participación) y la empresa acepta participar en la investigación al igual que los equipos de desarrollo. Luego, se procede a listar las personas que participan en el estudio (véase la Tabla 36). Por criterios de confidencialidad y ética en el proceso de investigación no se divulgan detalles personales de los participantes.

Caso de estudio 89

Tabla 36. Perfil de los participantes en el estudio de caso (Los autores)

Nombre Perfil Participante 1 Director de proyectos Participante 2 Desarrollador de software Senior Participante 3 Desarrollador de software Senior Participante 4 Desarrollador de software Junior Participante 5 Analista de calidad Participante 6 Director de proyectos Participante 7 Desarrollador de software Junior Participante 8 Analista de calidad Participante 9 Desarrollador de software Senior Participante 10 Desarrollador de software Senior Participante 11 Desarrollador de software Junior Participante 12 Analista de calidad Participante 13 Desarrollador de software Senior Participante 14 Director de proyectos Participante 15 Desarrollador de software Junior Participante 16 Analista de calidad

Antes del proceso formal de aplicación de las entrevistas, cada empleado acepta su participación en el proyecto y firma el consentimiento informado. Luego, se establece la agenda de entrevistas con los participantes de acuerdo con su disponibilidad. Se entrevistan nueve desarrolladores de software, cuatro analistas de calidad y tres directores de proyecto. Durante la realización de las entrevistas, los participantes prestan especial atención a los estados demostrable, listo y retirado, debido a la falta de conocimiento sobre la conceptualización de la Esencia Semat y sus estados. Sin embargo, el investigador aclara las inquietudes y explica a los participantes la dinámica de la entrevista y se dan a conocer los pasos para relacionar cada una de las medidas con los seis estados del alfa. Estos pasos, se describen a continuación: Cada participante comprende desde su experiencia y conocimiento el significado de

cada medida y la descripción de la lista de chequeo de cada estado.

De acuerdo con la fórmula de medida y la razón de selección que se describen en el instrumento, se relaciona cada medida con los estados del alfa.

Luego, el participante señala con una equis (x) en el formato de la entrevista si acepta

alguna relación identificada o la rechaza con sus respectivos comentarios El análisis realizado por los participantes se hizo teniendo en cuenta un proyecto de desarrollo de software en ejecución y de acuerdo a cada rol desempeñado, se analizan las


preguntas y se dan respuestas. En dos ocasiones particulares, los participantes solicitan aclaración frente a conceptos y medidas que no son conocidas y que son poco aplicadas en su entorno. El investigador da respuesta a sus inquietudes y plantea ejemplos prácticos para que los participantes comprendan el contexto de las medidas y los estados del alfa. El análisis de los datos recolectados muestra que, de un total de 28 (100%) medidas que se validan con los participantes, se aceptan 19 (68%) y 9 (32%) no son aceptadas (véase la Tabla 37). Los criterios de aceptación de las medidas y su relación con los estados del alfa sistema de software se justifican a partir de la experiencia en calidad y desarrollo de software de los participantes. Tabla 37. Resultado del análisis de datos (Los autores)

Estados # Medidas Aceptadas No aceptadas Con arquitectura seleccionada 4 2 2 Demostrable 4 3 1 Usable 6 4 2 Listo 5 4 1 Operacional 5 4 1 Retirado 4 2 2

Total (%)

28 19 9 100% 68% 32%

5.2.1. Medidas que aprueban los participantes Las medidas que los participantes validan y aceptan de acuerdo con los ítems de la lista de chequeo por estado se muestran en la Tabla 38. En la Tabla 39 se listan las medidas que los participantes no aceptan y sus respectivos comentarios. Tabla 38. Medidas que los participantes aceptan (1 de 2; Los autores)

Estado Ítem lista de chequeo Medida

Arquitectura seleccionada

Se acordaron los criterios para seleccionar la arquitectura Consistencia de la arquitectura

Se seleccionaron las plataformas, tecnologías y lenguajes

Significado de la utilización de dispositivos de E/S

Demostrable Se demostraron las características clave de la arquitectura

Adecuación funcional del sistema Consistencia del formato de datos

Se ejercieron la interfaz crítica y las configuraciones del sistema

Intercambialidad de formatos de datos

Caso de estudio 91

Tabla 38. Medidas que los participantes aceptan (2 de 2; Los autores)

Estado Ítem lista de chequeo Medida

Usable


Interfaz de usuario auto explicativa

Los usuarios pueden operar el sistema Consistencia operacional Se aceptaron los niveles de defectos Se han probado y aceptado la funcionalidad y el rendimiento

Corrección de error de entrada de usuario

Se conoció el contenido de liberación Categorización comprensible de la información

Listo

Se puso a disposición la documentación de usuario Integridad de la guía del usuario

Los representantes de los interesados aceptaron el sistema Evitación de fallos


Integridad de datos

Registro completo

Operacional

El sistema se usó en un ambiente operacional Integridad del registro del sistema

El sistema está disponible para los usuario previstos Accesibilidad del usuario


Adaptación ambiental del software Coexistencia con otros productos

Retirado No se producirán más actualizaciones al sistema Frecuencia de actualización

Se reemplazó o se descontinuó el sistema

Reutilización de datos/Capacidad de importación

Tabla 39. Medidas que los participantes no aceptan (1 de 3; Los autores)

Estado Ítem lista de chequeo Medida Comentarios

Arquitectura seleccionada

Arquitectura seleccionada que aborda riesgos técnicos clave

Cobertura funcional

- Integrar estos dos significados en una fórmula de medida (evaluar la cobertura funcional y la corrección)

- Corrección funcional es una definición adecuada para este estado de la lista de verificación

- Con esta medida es imposible hacer alguna prueba

- ¿Cuál es la diferencia para evaluar la cobertura y la corrección? ¿Podemos integrar ambos?

Corrección funcional

- ¿Podríamos integrar las dos medidas en una sola?

- No puedo medir la corrección funcional en mi rol de pruebas, solo la cobertura funcional.

- No sé cómo podría medirse ¿Alguna corrección o criterio funcional?




Demostrable

Los interesados relevantes acordaron que la arquitectura es apropiada


- Es una medida muy general, falta especificación

- Revisar su idoneidad Esta medida es muy general. Sin embargo, ¿tiene alguna medida adicional?

- La medida debe ser específica. Sugiero eliminar esta medida. No parece relevante aquí

- No es una medida clara y coherente - No muestra ninguna relación con el

significado y el estado - Puedo probarlo, pero ¿cuál es el

significado? - ¿En general significa todo? No está

claro

Usable El sistema es usable y tiene las características de calidad deseadas

Satisfacción con características

- Es una medida básica. ¿Qué sucede si tengo algunas respuestas? Puedo encontrar el resultado correcto con esta fórmula. Por favor, sugiera algo más útil y claro.

- La fórmula no es suficiente para medir la satisfacción.

- La fórmula es demasiado general. Además, puedo relacionar cada elemento con el significado de la lista de verificación

- ¿Qué tipos de características?

No vulnerabilidad

- Esta medida se puede relacionar con algunos ítems de seguridad y no de usabilidad

- Esta medida no es coherente con el estado usable. Revisar y verificar su idoneidad

- Es un atributo que se relaciona con los criterios de seguridad y no se relaciona directamente con el estado usable (específicamente con la interfaz de usuario)

- No se enfoca en criterios de usabilidad ¿Estado usable o seguridad?

- Vulnerabilidad significa seguridad y no puedo ver el estado de seguridad o algo así

Caso de estudio 93



Listo

Los representantes de las partes interesadas quieren que el sistema sea operativo

Confianza del usuario

- ¿Cómo se obtiene la escala psicométrica?

- Estas medidas no son suficientes y claras para que el sistema sea operativo

- En las pruebas, es difícil de medir. ¿Quién define la escala psicométrica?

- No lo necesito aquí. Te sugiero que elimines esta medida

- Para mi punto de vista es complicado medir

- En mi experiencia, no puedo medir la confianza. ¿Explícame cómo?

Operacional

Al menos un ejemplo de sistema es completamente operativo


- No es una medida suficiente para cubrir la lista de verificación y el estado operativo

- Estaba trabajando en un equipo de prueba y ahora soy desarrollador, pero estoy realmente preocupado por esta medida. No parece conveniente, ni convincente

Retirado No se da más soporte al sistema

Eficiencia de la modificación

- Estas medidas se relacionan con la mantenibilidad. Sin embargo, la eficiencia de modificación no presenta ninguna relación directa con el estado y el ítem de la lista de chequeo.

- Las medidas están relacionadas con la capacidad de mantenimiento. Sin embargo, la eficiencia de la modificación no tiene relación directa con el estado y el elemento.

- Esta medida se centra más en las modificaciones y la lista de verificación de estado significa que ya no es compatible. Entonces, no coincide. Revisar nuevamente.

- Esta medida está en el lugar equivocado ¿Qué pasa si lo incluimos en estado demostrable?

Capacidad de modificación

- Esta medida se centra más en las modificaciones y la lista de verificación de estado significa que ya no es compatible. Luego, no coincide. Verificar nuevamente

- No evaluamos la capacidad. Se centra más en la eficiencia


5.2.2. Amenazas a la validez En el desarrollo del caso de estudio se pueden presentar amenazas relacionadas con el proceso de selección, difusión de información, poco conocimiento del objeto de estudio, inestabilidad del instrumento de validación e idioma del diseño del instrumento y aplicación de la entrevista (véase la Tabla 40). Tabla 40. Amenazas a la validez (Los autores)

Amenaza Descripción Estrategia de mitigación

Selección inadecuada de participantes

Que no se seleccione la cantidad requerida de participantes y que no cumplan con los requisitos mínimos de participación

Contactar diferentes empresas de desarrollo de software para lograr al menos la participación de cinco expertos en el caso de estudio

Difusión de información

Que los participantes se comuniquen entre sí y esto afecte los resultados del caso de estudio

Aplicar las entrevistas a cada participante por separado

Poco conocimiento del objeto de estudio

Que los participantes no conozcan la conceptualización del núcleo de Semat, los alfas y sus estados

Durante el proceso de contextualización del caso de estudio, dar a conocer a los participantes información general de la Esencia Semat

Inestabilidad del instrumento de validación

Poca o nula confiabilidad del instrumento

Elaborar un instrumento estable y confiable. Realizar prueba piloto con al menos un experto de la academia y la industria.

Idioma del diseño del instrumento y aplicación de la entrevista

Diseño y aplicación del instrumento en un lenguaje y cultura diferente a Colombia

Manejo avanzado del inglés para el diseño y aplicación del instrumento Reconocimiento cultural y similitud en el desarrollo de proyectos de software (Australia-Colombia)

5.2.3. Esquema preconceptual ejecutable validado con la medida consistencia operacional

Después de conocer las medidas que los participantes aceptan, se presenta el esquema preconceptual vacío para que seis de los nueve desarrolladores de software participantes apliquen el modelo desarrollado en un proyecto de software en ejecución. Cuatro desarrolladores coincidieron en aplicar la medida de calidad del producto “consistencia operacional” (véase la Figura 37), de acuerdo a la característica “usabilidad” y la sub-característica “operabilidad” y los dos restantes aplicaron el modelo con la medida “corrección de error de entrada de usuario” de la característica “usabilidad” y sub-característica “protección de error de usuario”. Los seis participantes manifiestan que existe una secuencia lógica y una relación coherente para evaluar la salud y el progreso de los estados operacional y usable del alfa sistema de software en un esfuerzo en ingeniería de software.

Caso de estudio 95

Figura 37. Esquema preconceptual ejecutable que los participantes validan (Los autores).

Se usa el esquema preconceptual ejecutable para representar la funcionalidad del modelo para evaluar la salud y el progreso del alfa sistema de software. Los participantes seleccionan la medida ‘consistencia operacional’ de la característica ‘usabilidad’, para evidenciar la relación establecida con los estados ‘usable’ y ‘operacional’ e identificar la secuencia lógica y coherente de ejecución del modelo. Por otra parte, el esquema se presenta a los participantes, quienes identifican las relaciones entre el proceso de medición y evaluación y cómo pueden usar y comprender los elementos y atributos que lo componen para representar un problema específico. En el ejemplo particular de la medida que se selecciona, se valida que los usuarios puedan operar el sistema y de esta manera se identifica cual es la función de medición, qué rol evalúa el estado del alfa y qué atributos se ejecutan para desarrollar el proceso de evaluación mediante la norma ISO/IEC 2504n. La representación en esquemas preconceptuales ejecutables contribuye en la comprensión global del modelo que se propone en esta Tesis de Doctorado para evaluar la salud y el progreso de los estados del alfa sistema de software en un esfuerzo en ingeniería de software que incluye los criterios establecidos en las normas ISO/IEC 2502n e ISO/IEC 2504n para medir y evaluar la calidad del producto.

Modelo propuesto 97

6. Conclusiones y trabajo futuro

6.1. Conclusiones En esta Tesis Doctoral, se propuso un análisis de las medidas de la norma ISO/IEC 2502n para seleccionar las medidas apropiadas del alfa sistema de software para estructurar las relaciones entre ellas. Se propusieron seis representaciones en el núcleo de Semat para mostrar las relaciones identificadas de cada uno de los estados con las medidas respectivas y diferentes productos de trabajo. Además, se presentó un esquema preconceptual ejecutable con la medida ‘corrección de error de entrada del usuario’ para verificar la secuencia lógica y coherente entre la medida y los estados del alfa, y validar la funcionalidad del modelo. Se seleccionaron 75 medidas de un total de 185 establecidas en el estándar internacional ISO/IEC 25000. Del total de medidas caracterizadas, 17 hacen parte de las medidas de calidad en uso (ISO/IEC 25022), 31 medidas de la calidad del producto de software (ISO/IEC 25023) y 27 medidas de la calidad del dato (ISO/IEC 25024). Se propuso el proceso de evaluación bajo la norma ISO/IEC 25040, relacionado con entradas, restricciones, recursos y roles, para medir la calidad del software desde las perspectivas de uso, producto y dato. Con la revisión sistemática de literatura se evidenció que en varios estudios se relacionan implícitamente las medidas con los estados del alfa sistema de software del núcleo Semat. Se identificó una falta de especificación de la relación entre la norma ISO/IEC 9126 y la nueva propuesta de medidas basadas en la norma ISO/IEC 25000. Los estados alfa del sistema de software se pueden evaluar utilizando las medidas ISO/EC 25000. Por último, es importante mencionar que la validación de la hipótesis y el modelo propuesto se realizó utilizando un método de caso de estudio y se evidenció que: - La hipótesis planteada la aceptaron los participantes del estudio (director de proyectos,

desarrollador de software y analista de pruebas), identificando más del 65% de las relaciones entre las medidas y los estados alfa. Los participantes aceptaron el 68% de


las medidas incluidas en el caso de estudio (19 sobre un total de 28) y no aceptaron el 32% restante (9 sobre un total de 28).

- La no aceptación del 32% de las medidas, se debe a la inadecuada relación de la lista de chequeo de todos los estados con las medidas ‘cobertura funcional’, ‘corrección funcional’, ‘satisfacción general’, ‘satisfacción con características’, ‘no vulnerabilidad’, ‘confianza del usuario’, ‘eficiencia de tiempo’, ‘eficiencia de la modificación’ y ‘capacidad de modificación’.

- Las estrategias de mitigación a las amenazas a la validez del caso de estudio son

fundamentales para prevenir errores durante el proceso de ejecución del método.

- Los esquemas preconceptuales ejecutables ayudan a garantizar un modelo integral y a interpretar cómo se pueden usar y comprender los elementos y atributos que lo componen para representar un problema específico (medidas y las relaciones con los estados del alfa sistema de software).

6.2. Trabajo Futuro Al finalizar esta Tesis de Doctorado se identificaron las siguientes propuestas de trabajo futuro en las áreas de ingeniería de software, ingeniería de requisitos y calidad de software: - Identificar la relación entre los estados del alfa requisitos y las medidas de calidad en

uso, calidad del producto de software y calidad del dato.

- Creación de una herramienta automática de selección de medidas para jóvenes empresas de acuerdo al contexto y a la flexibilidad en el desarrollo de proyectos de software.

- Continuar con la validación del caso de estudio en otras empresas de acuerdo con los criterios definidos, para identificar qué medidas implementan usualmente y cómo los desarrolladores de software evalúan la calidad de sus productos.

- Realizar la validación completa de las 75 medidas de calidad en uso, calidad del producto y calidad del dato seleccionadas para cada estado, para identificar la comprensión y aplicabilidad del modelo en las empresas de desarrollo de software.

- Validar el esquema preconceptual ejecutable con diferentes medidas y monitorear su funcionalidad en algunas compañías de software.

- Identificar como las empresas jóvenes de desarrollo de software evalúan la calidad de sus productos y que medidas implementan para hacerlo.

Referencias 99

Referencias

Abran, A., Al-Qutaish, R., Desharnais, J., & Habra, N. (2008). ISO-Based models to measure software product quality. In R.K., Jain (Ed.), Software Quality Measurement–Concepts and approaches, pp. 61-96. Hyderabad, India: The ICFAI University Press.

AENOR-UNE 166006:2011. Gestión de la I+D+i—Sistema de vigilancia tecnológica e inteligencia competitiva, Madrid: AENOR.

Alnanih, R., Ormandjieva, O., y Radhakrishnan, T. (October, 2013). A New Quality-in-Use Model for Mobile User Interfaces. In 23nd International Workshop on Software Measurement and 8th International Conference on Software Process and Product Measurement, pp. 165-170. Ankara, Turkey.

Basili, V., Heidrich, J., Lindvall, M., Munch, J., Regardie, M., & Trendowicz, A. (2007). GQM+Strategies—Aligning Business Strategies with Software Measurement. In First International Symposium on Empirical Software Engineering and Measurement, ESEM, Madrid.

Bougroun, Z., Zeaaraoui, A., Belkasmi, M. G., & Bouchentouf, T. (September, 2012). Classification of the metric in ISO model by oriented object properties. In Second International Conference on the Innovative Computing Technology, pp. 128-132. Casablanca, Morocco.

Dwolatzky, B. (2012, May). Re-founding software engineering practice—The SEMAT initiative. In 4th Software Engineering Colloquium, pp. 12-14. Cape Town, South Africa.

Esaki, K. (2013). System quality requirement and evaluation, importance of application of the ISO/IEC25000 series. Global Perspective on Engineering Management, 2 (2), pp. 52-59.

Febrero, F., Calero, C., & Moraga, M. A. (2016). Software reliability modeling based on ISO/IEC SQuaRE. Information and Software Technology, 70, pp. 18-29. doi:10.1016/j.infsof.2015.09.006

Heo, J., Ham, D. H., Park, S., Song, C., & Yoon, W. C. (2009). A framework for evaluating the usability of mobile phones based on multi-level, hierarchical model of usability factors. Interacting with Computers, 21 (4), pp. 263-275.

Hosni, M., & Kirinic, V. (September, 2013). Application of software product quality international standards through software development life cycle. In Central


European Conference on Information and Intelligent Systems, pp. 284-296. Varaždin, Croatia.

Idri, A., Bachiri, M., & Fernandez, J. L. (2015). A Framework for Evaluating the Software Product Quality of Pregnancy Monitoring Mobile Personal Health Records. Journal of Medical Systems, 40 (3), pp. 1-17.

ISO/IEC 15939:2007, Systems and software engineering—Measurement process, Canada: ISO/IEC.

ISO/IEC 24765:2010, Systems and software engineering—Vocabulary, Switzerland: ISO/IEC.

ISO/IEC 25040:2011a, Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—Evaluation process, Canada: ISO/IEC.

ISO/IEC 25010:2011b, Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—System and software quality model, Canada: ISO/IEC.

ISO/IEC 25021:2012. Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—Quality measure elements, Canada: ISO/IEC.

ISO/IEC 25000:2014, Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—Guide to SQuaRE 25000, Canada: ISO/IEC.

ISO/IEC 25023:2016, Systems and software engineering—Systems and software Quality Requirements and Evaluation (SQuaRE)—Measurement of systems and software product quality, Switzerland: ISO/IEC.

Jacobson, I., Meyer, B., & Soley, R. (2009). The SEMAT initiative: A call for action. Dr. Dobb's Journal, 10.

Jacobson, I., Ng, P.-W., McMahon, P., Spence, I., & Lidman, S. (2012). The essence of software engineering: the SEMAT kernel. Communication of the ACM, 55 (12), pp. 42-49.

Jacobson, I., Ng, P.-W., McMahon, P. E., Spence, I., y Lidman, S. (2013). The essence of software Engineering: applying the SEMAT kernel. New Jersey: Addison-Wesley.

Kajko-Mattsson, M., Striewe, M., Goedicke, M., Jacobson, I., Spence, I., Huang, S., McMahon, P., MacIssac, B., Elvesæter, B., y Berre, A. (June, 2012). Refounding software engineering: The Semat initiative (Invited presentation). In 34th International Conference on Software Engineering, pp. 1649-1650. Surich, Switzerland.

Lampasona, C., Heidrich, J., Basili, V. R., & Ocampo, A. (September, 2012). Software quality modeling experiences at an oil company. In ACM-IEEE International Symposium on Empirical software engineering and measurement, pp. 243- 246. Lund, Sweden.

Lethbridge, T. C., Sim, S. E., & Singer, J. (2005). Studying software engineers: Data collection techniques for software field studies. Empirical Software Engineering, 10(3), 311-341.

Referencias 101

Maimbo, H., & Pervan, G. (December, 2005). Designing a case study protocol for application in IS research. In Pacific Asia Conference on Information Systems—PACIS, pp. 1281-1292.

Marcos, J., Arroyo, A., Garzas, J., & Piattini, M. (2008). La norma ISO/IEC 25000 y el proyecto KEMIS para su automatización con software libre. Revista Española de Innovación, Calidad e Ingeniería del Software, 4 (2), pp. 133-144.

Marin, H. A., & Bedoya, A. E. (Octubre, 2015). Una adopción de PMBOK al ciclo de vida de desarrollo de proyectos software en pequeñas empresas. En VI Congreso Iberoamericano de Ingenieria de Proyectos, pp. 1-19. Medellin, Colombia.

Mellado, D., Rodriguez, M., Verdugo, J., Piattini, M., & Fernandez, E. (2010). Evaluacion de la calidad y seguridad en productos software. Gobernacion España, Administracion Electronica.

Muto, K., Kimita, K., & Shimomura, Y. (2015). A Guideline for Product-Service-Systems Design Process. Procedia CIRP, 30, pp. 60-65. Tokyo, Japan.

Numata, E., Hosono, S., Sakaki, H., Izukura, S., Kimita, K., & Shimomura, Y. (2015). Disciplines for Designing PSS Actor Network. Procedia CIRP, 30, pp. 408-414.

OMG. (2014). Kernel and Language for Software Engineering Methods (Essence). Needham, USA, Retrived from: http://www.omg.org/spec/Essence/1.0/

Palop, F., & Vicente, J. M. (Febrero, 1999). Vigilancia tecnológica e inteligencia competitiva: su potencial para la empresa española. Fundación COTEC para la innovación, pp. 1-116. Madrid, España.

Perdomo, W., & Zapata, C. M. (2015). Identificación de criterios para relacionar la usabilidad con el alfa sistema de software del núcleo de SEMAT. En Latin American Software Engineering Symposium—LASES, pp. 17-22. Bogota, Colombia.

Piattini, M., & Garzas, J. (2007). Fábricas de software: experiencias, tecnologías y organización. Mexico DF: Alfaomega Grupo Editor.

Piattini, M., Garcia, F., Garzas, J., & Genero, M. (Enero, 2008). Medición y estimación del software: técnicas y métodos para mejorar la calidad y productividad del software. En RA-MA (Ed.), pp. 121-127. Madria, España.

Rodríguez, M., Oviedo, J. R., & Piattini, M. (2016). Evaluation of software product functional suitability: a case study. Software Quality Management, 18 (3), pp. 18-29.

Rodríguez, M., Pedreira, O., & Fernández, C. M. (2015). Certificación de la mantenibilidad del producto software: un caso practico. Revista Latinoamericana de Ingenieria de Software, 3 (3), pp. 127-134.

Runeson, P., & Höst, M. (2008). Guidelines for conducting and reporting case study research in software engineering. Empirical Software Engineering, 14 (2), 131-164.

Schneider, F., & Berenbach, B. (2014). A Literature Survey on International Standards for System Requirements Engineering. INSIGHT, 17 (1), pp. 32-35.

Simmonette, M., Magalhães, M. & Spina, E. (2017). Associating quality measures to the alpha states of the SEMAT kernel. (1a ed.). En Zapata, C., Durango, C. y Perdomo, W. Software engineering: methods, modeling and teaching Volume 4 (pp. 41-54). Medellin, Colombia: Editorial Bonaventuriana.

http://www.omg.org/spec/Essence/1.0/


Verner, J. M., & Abdullah, L. M. (2012). Exploratory case study research: Outsourced project failure. Information and Software Technology, 54(8), 866-886.

Yin, R. K. (1994). Case study research: design and methods. SAGE Publications—International Education and Professional Publisher, New Delphi, 5 (2), pp. 1-53.

Zapata, C. M., Maturana, G. V., & Castro, L. F. (Agosto, 2013). Tutorial sobre la iniciativa Semat y el juego MetriCC. En Congreso Colombiano de Computación, pp. 1-3. Bogota, Colombia.

Zapata, C. M., & Montoya, Y. (April, 2016). On the Relationship of ISO/IEC 9126 Metrics and the Alpha States of the SEMAT Kernel. In 4th International Conference in Software Engineering Research and Innovation—CONISOFT, pp. 59-64. Puebla, Mexico.

modelo para la medición del progreso del alfa sistema de

Documents