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

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
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

del estado demostrable (Los autores). ............................................................................ 67
del estado usable (Los autores). ..................................................................................... 68
del estado listo (Los autores) .......................................................................................... 69
del estado operacional (Los autores). ............................................................................. 70
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
calidad del producto (Los autores).................................................................................. 44
XVI Modelo para la medición del progreso del alfa sistema de software del núcleo de
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
Tabla 23. Función de medición de la calidad del producto para el estado listo
Tabla 24. Función de medición de la calidad del producto para el estado operacional
Tabla 25. Función de medición de la calidad del producto para el estado retirado
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
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
Tabla 31. Función de medición de la calidad del dato para el estado operacional
Tabla 32. Función de medición de la calidad del dato para el estado retirado (Elaboración
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 Un sistema de software puede ser parte de un software,
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
International Organization for Standardization and International
ISO/IEC
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 Semat 1 (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

Elemento esencial para determinar el
Alfa progreso y la salud de un esfuerzo de
ingeniería de software.
Define una o más tipos de productos de
Actividad trabajo y tareas y guías sobre cómo usarlos
en un contexto de práctica.
Espacio de Actividades siempre realizadas en cualquier

actividad esfuerzo de ingeniería de software.
Descripción de cómo manejar un aspecto

Práctica específico de un esfuerzo de desarrollo de
software.
Se utiliza para conectar un producto de
Asociación de trabajo con un alfa o un rol. También se utiliza
elementos 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
Es un mecanismo “genérico” para nombrar

Patrón o Rol conceptos complejos que se componen de
varios elementos de la Esencia.
Producto de Dispositivo de valor y relevancia para un

trabajo esfuerzo de ingeniería de software.
Una asociación de patrón se visualiza

Símbolo de
mediante una o más líneas continuas que se
asociación de name
originan en un círculo que conecta cada

patrón
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).

software (1 de 2; ISO/IEC, 2016).
Característica Sub-característica
Adecuación Integridad funcional, corrección funcional,
funcional adecuación funcional
Eficiencia de Comportamiento temporal, utilización de recursos,
rendimiento 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

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- Coexistencia ¿Qué proporción de X=A/B
1-G con otros productos de software A = número de otros productos de
productos específicos pueden software especificados con el cual
compartir el entorno con este producto puede coexistir
este producto de software B = número de otros productos de
sin impacto adverso sobre software especificados para
sus características de coexistir con este producto en un
calidad o funcionalidad? 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.
14 Modelo para la medición del progreso del alfa sistema de software del núcleo de
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).
FICHA TECNICA
FACTORES CLAVES DE VIGILANCIA TECNOLÓGICA (FCV)
Tema ¿Por qué? ¿Para que? ¿Para quién? Palabras clave Restricciones Preguntas clave
La ingeniería de software
carece de procesos
objetivos de evaluación y Metodologías, 1. ¿Qué enfoques se utilizan en las
Desarrollar un modelo
validación experimentales Normas/Estándar empresas para medir la calidad del
Modelo de la relación para la medición de la
y creíbles de la calidad del ISO/IEC25000, ISO/IEC. software?
entre las métricas de calidad del producto Equipos de
software. característica, sub- Sólo enfocado en 2. ¿Qué métricas existen para
calidad de software de software con base desarrollo de
característica, medida, sistemas de software evaluar la calidad del producto de
incluidas en la norma en la norma software e
La ingeniería de software función de medida, (sistemas de software?
ISO/IEC:25000 y los ISO/IEC:25000, en ingeniería de
no tiene definidas las Semat , alfa, estado, información, software, 3. ¿Existen modelos donde se
diferentes elementos relación con el alfa software.
medidas para evaluar la evaluación aplicaciones, relacionen las medidas de la norma
del núcleo de Semat . sistema de software
calidad del software aplicación de escritorio ISO/IEC25000 con los estados del
del núcleo de Semat .
producido y los métodos o móvil) alfa del núcleo de Semat ?
que se usan para
producirlo.
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).
Fuente de Prioridad
Palabras Clave Ecuación de Búsqueda Cantidad Resultado Búsqueda (Fuente Bibliográfica)
Información (1/5)
pub-date > 2009 and (Metrics of software quality model applied to the
http://www.sciencedirect.com.ezproxy.unal.edu.co/science?_o
Metrics, software quality measurement of progress and status of a software project) AND LIMIT-
b=ArticleListURL&_method=list&_ArticleListID=-
model, measurement, TO(cids, "271629,271539,271990,271521","Journal of Systems and
Science Direct 19 3 877218379&_st=5&filterType=&searchtype=a&originPage=rsl
progress, state, software Software,Information and Software Technology,Computer Networks,Future
t_list&_origin=&_mlktType=&md5=b6802afff3ea4caad91a989
project Generation Computer Systems") AND LIMIT-TO(topics,
8ec228bcc
"system,project,process") AND LIMIT-TO(contenttype, "JL,BS","Journal").
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
Metrics, quality, ISO 9126, http://www.sciencedirect.com.ezproxy.unal.edu.co/science?_o
LIMIT-TO(yearnav, "2015,2014,2013,2012,2009") AND LIMIT-TO(cids,
measurement, progress, b=ArticleListURL&_method=list&_ArticleListID=-
"271539,271629,271322,271802,272990","Information and Software
state, software project, Science Direct 7 4 877231611&_st=5&filterType=&searchtype=a&originPage=rsl
Technology,Journal of Systems and Software,Computer Methods and
application, information t_list&_origin=&_mlktType=&md5=8d5753c2530713263fd3df7
Programs in Biomedicine,Computers in Human Behavior,Electronic Notes
system 29d5e42f5
in Theoretical Computer Scienc...") AND LIMIT-TO(topics,
"application,quality,requirement,system,application service") AND LIMIT-
TO(contenttype, "JL,BS","Journal").
pub-date > 2007 and (Quality metrics ISO: 9126, applied to the evaluation
of software products) or (Quality metrics ISO: 9126, applied to the
http://www.sciencedirect.com.ezproxy.unal.edu.co/science?_o
measurement of software products) AND LIMIT-TO(cids,
Quality metrics, ISO 9126, b=ArticleListURL&_method=list&_ArticleListID=-
"271539,271629,271914,311863","Information and Software
measurement, evaluation, Science Direct 15 3 877247314&_st=5&filterType=&searchtype=a&originPage=rsl
Technology,Journal of Systems and Software,Computer Standards &
software products t_list&_origin=&_mlktType=&md5=f3236db3303dfa286628c22
Interfaces,Relating System Quality and Software Architectu...") AND LIMIT-
6b984b83a
TO(topics, "quality,quality model,system,iso,model") AND LIMIT-
TO(contenttype, "JL,BS","Journal").
http://ieeexplore.ieee.org.ezproxy.unal.edu.co/search/searchr
Metrics, measure, quality, esult.jsp?action=search&sortType=&rowsPerPage=&searchFi
ISO 9126, measurement, (Quality metrics ISO: 9126, applied to measuring the progress and status of IEEE Explore eld=Search_All&matchBoolean=true&queryText=(Quality%20
18 3
progress, state, software a software project) Digital Library metrics%20ISO:%209126,%20applied%20to%20measuring%
project, application 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 Seleccionados

IEEE Xplore Digital Library 30 10 4
Google Sholar 42 16 4
Science Direct 70 21 2
Scopus 14 12 0
Springer Link 14 8 1
Redalyc 38 6 1
Total 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).
Sub-característica
NIVEL mantenibilidad
NOMBRE PROVEEDOR NCSS Mantainability
DE PRODUCTO
Stability Changeability Analysability
jboss-maven-plugin CodeHaus 83,05 371,00 87,26 100,00 72,47
Jdepend Clarkware Consulting 75,35 1.808,00 100,00 100,00 50,70
castos-maven-plugin CodeHaus 72,10 263,00 98,38 100,00 45,00
jlgui javazoom 71,81 8.538,00 85,65 50,00 75,80
quilt apache 60,91 4.087,00 95,18 49,58 49,43
ivy apache 60,07 24.612,00 100,00 50,00 45,13
commons-collections apache 60,00 19.417,00 100,00 50,00 45,00
FindBugs University of Mariland 59,85 72.195,00 99,40 50,00 45,00
JavaNCSS Klcee 59,42 15.203,00 100,00 50,00 43,84
TightVNCviewer TightVNC Software 56,30 3.292,00 3,80 100,00 60,70
velocity-tools apache 52,99 4.960,00 21,98 100,00 45,00
CheckStyle Oliver Burn 39,46 28.744,00 17,85 50,00 45,00
PMD InfoEther 37,65 39.604,00 10,60 50,00 45,00
commons-logging apache 34,67 1.774,00 0,00 48,69 45,00
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.
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).
Estados Tipo de Relación

Autor Modelo usado
deducidos representación explicita/implícita
ISO/IEC 9126 e Usable,
Marcos et al., 2008 ISO/IEC 25000 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
Operacional,
Bougroun et al., 2012 ISO/IEC 9126
retirado
Jerárquica Implícita
Demostrable,
Lampasona et al.,
ISO/IEC 25000 usable, listo, Tabular Implícita
2012 operacional
Usable,
Alnanih et al., 2013 ISO/IEC 9126
Operacional
Zapata et al., 2013 ISO/IEC 9126 Retirado Semat Explicita

Con arquitectura
seleccionada,
Idri et al., 2015 ISO/IEC 25000 demostrable, Tabular Implícita
usable, listo,
operacional
Antecedentes 29
Tabla 7. Síntesis de estudios analizados en relación con los problemas identificados (2 de

2; Los autores)
Estados Tipo de Relación

Autor Modelo usado
deducidos representación explicita/implícita
Demostrable,
Perdomo y Zapata, ISO/IEC 9126 usable, listo, Jerárquica Explicita
2015 operacional
Listo,
Febrero et al., 2016 ISO/IEC 25000
operacional
Con arquitectura
Rodríguez et al.,
ISO/IEC 25000 seleccionada, Jerárquica Implícita
2016 demostrable
Zapata y Montoya,
ISO/IEC 9126 Operacional Semat Explicita
2016
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).
Documentar los estados del Interpretar los significados

Seleccionar las medidas
alfa sistema de software y de las medidas de acuerdo Representar las medidas y
adecuadas para evaluar la
cada medida de la calidad con las normas 2502n y los los estados del alfa sistema
calidad del producto de
del producto de software de estados alfa con la lista de de software en el núcleo de
software en los estados del
acuerdo con las normas verificación para Semat
alfa sistema de software
ISO/IEC 2502n relacionarlos
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
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
i. Se seleccionó la arquitectura que trata los riesgos técnicos clave
Con
ii. Se acordaron los criterios para seleccionar la arquitectura
arquitectura
iii. Se seleccionaron las plataformas, tecnologías y lenguajes
seleccionada
iv. Se tomaron las decisiones de compra, construcción y reúso
i. Se demostraron las características clave de la arquitectura
ii. Los interesados relevantes acordaron que la arquitectura es
Demostrable
apropiada
iii. Se ejercieron la interfaz crítica y las configuraciones del sistema
i. El sistema es usable y tiene las características de calidad
deseadas
Usable ii. Los usuarios pueden operar el sistema
iii. Se aceptaron los niveles de defectos
iv. Se conoció el contenido de liberación
i. Se puso a disposición la documentación de usuario
ii. Los representantes de los interesados aceptaron el sistema
Listo
iii. Los representantes de los interesados quieren que se haga
operacional el sistema
i. El sistema se usó en un ambiente operacional
ii. El sistema está disponible para los usuarios previstos
Operacional
iii. Al menos un ejemplo del sistema es completamente operacional
iv. El sistema es compatible con los niveles de servicio acordados
i. No se da más soporte al sistema
Retirado 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).
Total Total Total

Característica Característica
medidas ISO/IEC 25022 medidas ISO/IEC 25023 Característica medidas ISO/IEC 25024
Calidad en Calidad del
ISO/IEC seleccionadas ISO/IEC seleccionadas Calidad del dato ISO/IEC seleccionadas
uso producto
25022 25023 25024
Adecuación
Efectividad 5 2 4 4 Exactitud 7 1
funcional
Eficiencia en el
Eficiencia 6 2 12 2 Completitud 8 3
desempeño
Satisfacción 9 6 Compatibilidad 4 3 Consistencia 6 2

Cobertura de
4 2 Usabilidad 22 10 Credibilidad 4 2
contexto
Libertad de
12 Confiabilidad 11 2 Actualidad 3 1
riesgo
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)

1 8.2 - Ef-1-G Tareas completadas
Efectividad
2 8.2 - Ef-2-S Objetivos alcanzados
3 8.3 - Ey-1-G Tiempo de tarea
Eficiencia
4 8.3 - Ey-2-S Eficiencia de tiempo
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
Satisfacción
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 11 8.6 - CFl-1-S Contexto de uso flexible

contexto 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).

1 8.2 - FCp-1-G Cobertura funcional
Adecuación 2 8.2 - FCr-1-G Corrección funcional
funcional 3 8.2 - FAp-1-G Pertinencia funcional del objetivo de uso
4 8.2 - FAp-2-G Adecuación funcional del sistema
Eficiencia de 5 8.3 - PRu-3-G Significado de la utilización de dispositivos de E/S
rendimiento 6 8.3 - PCa-1-G Capacidad de procesamiento de transacciones
7 8.4 - CIn-1-G Intercambio de formato de datos
Compatibilidad 8 8.4 - CIn-3-S Suficiencia de interfaz externa
9 8.4 - CCo-1-G Coexistencia con otros productos
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
Usabilidad
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
20 8.6 - RFt-1-G Evitación de fallos
Confiabilidad
21 8.6 - RAv-1-G Disponibilidad del sistema
Seguridad 22 8.7 - SIn-1-G Integridad de datos
23 8.8 - MAn-1-G Integridad del registro del sistema
Mantenibilidad 24 8.8 - MMd-1-G Eficiencia de modificación
25 8.8 - MMd-3-S Capacidad de modificación
26 8.9 - PAd-2-G Adaptación ambiental del software
27 8.9 - PAd-3-S Adaptación ambiental operacional
Portabilidad
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).

QMs para exactitud 1 8.2 - Acc-I-8 Exactitud del modelo de datos
2 8.3 - Com-I-1 Registro completo
QMs para
3 8.3 - Com-I-6 Modelo conceptual de datos completo
completitud
4 8.3 - Com-I-8 Metadatos completos
QMs para 5 8.4 - Con-I-4 Consistencia de la arquitectura
consistencia 6 8.4 - Con-I-2 Consistencia del formato de datos
QMs para 7 8.5 - Cre-I-1 Credibilidad de los valores
credibilidad 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
10 8.7 - Acs-I-1 Accesibilidad del usuario
accesibilidad
QMs para 11 8.8 - Cmp-I-2 Cumplimiento normativo debido a la tecnología
conformidad 12 8.8 - Cmp-I-1 Cumplimiento normativo del valor y/o formato
QMs para 13 8.9 - Cnf-I-1 Uso de cifrado
confidencialidad 14 8.9 - Cnf-D-1 No vulnerabilidad
15 8.10 - Eff-I-2 Eficiencia de utilización
QMs para eficiencia
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
18 8.12 - Tra-D-2 Trazabilidad del valor de los datos
trazabilidad
QMs para
19 8.13 - Und-I-4 Comprensión de los valores de los datos
comprensibilidad
QMs para
20 8.14 - Ava-D-1 Proporción de disponibilidad de datos
disponibilidad
QMs para
21 8.15 - Por-D-1 Proporción de portabilidad de datos
portabilidad
QMs para
22 8.16 - Rec-D-1 Proporción de recuperabilidad de datos
recuperabilidad
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 Medidas por ISO/IEC 25022 ISO/IEC 25023 ISO/IEC 25024
software estado del alfa seleccionadas seleccionadas seleccionadas
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.
calidad en uso (Los autores).
Estado Lista de verificación ID Medida (ISO/IEC 25022)

Los interesados relevantes
Demostrable acordaron que la arquitectura 8.4 - SUs-1-G Satisfacción general
es apropiada
Satisfacción con las
El sistema es usable y tiene 8.4 - SUs-2-G
características
las características de calidad
8.4 - SUs-3-G Uso discrecional
Usable deseadas
8.4 - SUs-4-G Utilización de características
Los usuarios pueden operar 8.2 - Ef-1-G Tareas completadas
el sistema 8.2 - Ef-2-S Objetivos alcanzados
Los representantes de los 8.4 - SUs-1-G Satisfacción general
interesados aceptaron el Satisfacción del usuario
8.4 - SPI-1-G
sistema (experiencia de usuario)
Listo
Los representantes de los 8.4 - STr-1-G Confianza del usuario
interesados quieren que se 8.3 - Ey-1-G Tiempo de tarea
haga operacional el sistema 8.3 - Ey-2-S Eficiencia de tiempo
8.2 - Ef-1-G Tareas completadas
Al menos un ejemplo del
8.2 - Ef-2-S Objetivos alcanzados
sistema es completamente
8.3 - Ey-1-G Tiempo de tarea
operacional
Operacional 8.3 - Ey-2-S Eficiencia de tiempo
El sistema es compatible con 8.6 - CFl-1-S Contexto de uso flexible
los niveles de servicio
8.6 - CFl-2-S Flexibilidad del producto
acordados
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
𝑋𝑋 = � 𝐴𝐴𝐴𝐴
Los interesados relevantes manifiestan
Satisfacción Ai = respuestas a las preguntas satisfacción general con las
general realizadas al usuario con respecto funcionalidades y la usabilidad del
a la satisfacción general del producto o sistema
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
𝑋𝑋 = � 𝐴𝐴𝐴𝐴 Los interesados relevantes manifiestan

Satisfacción con
Ai = respuestas a un cuestionario satisfacción del producto respecto de
las
relacionado con características ciertas características específicas
características
específicas identificadas
𝑋𝑋 = 𝐴𝐴/𝐵𝐵
A = número de usuarios usando
una función específica, aplicación Proporción de usuarios potenciales
Uso
o sistema seleccionando el uso de algunas
discrecional
B = número de usuarios funciones del sistema
potenciales quienes podrían usar
la función específica
A = número de usuarios usando
Proporción de un conjunto de usuarios
Utilización de una característica particular
del sistema identificados quienes usan
características B = número de usuarios en un
una característica particular
conjunto de usuarios del sistema
identificados
Tabla 16. Función de medición de la calidad en uso para el estado usable (2 de 2;


Efectividad
A = número de tareas únicas
Tareas Proporción de las tareas que se
completadas
completadas completan correctamente sin asistencia
B = número total de tareas únicas
intentadas
� 𝑋𝑋 = 1 − � 𝐴𝐴𝐴𝐴 � 𝑋𝑋 ≥ 0 }
Ai = valor proporcional de cada Proporción de los objetivos de la tarea
Objetivos
objetivo faltante o incorrecto en el que se alcanzan correctamente sin
alcanzados
resultado de la tarea (valor asistencia
máximo = 1)
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;


Satisfacción
𝑋𝑋 = � 𝐴𝐴𝐴𝐴 Los interesados relevantes manifiestan

Satisfacción Ai = respuestas a las preguntas satisfacción general con las
general realizadas al usuario respecto de funcionalidades y la usabilidad del
la satisfacción general del sistema producto o sistema
Satisfacción del 𝑋𝑋 = 𝐴𝐴 Proporción de la medida en que el
usuario A = valor de la escala usuario obtiene placer en comparación
(experiencia de psicométrica de un cuestionario con el promedio para este tipo de
usuario) de placer. producto/sistema
𝑋𝑋 = 𝐴𝐴
Confianza del A = valor de la escala Proporción de la medida en que el
usuario psicométrica de un cuestionario usuario confía en el sistema/producto
de confianza
Modelo propuesto 43
Tabla 17. Función de medición de la calidad en uso para el estado listo (2 de 2;


Eficiencia
𝑋𝑋 = 𝑇𝑇 Tiempo tomado para completar una
Tiempo de tarea
T = tiempo de la tarea tarea exitosamente
𝑋𝑋 = 𝐴𝐴/𝑇𝑇
Eficiencia con la cual los usuarios
Eficiencia de A = número de objetivos
logran sus objetivos sobre el tiempo
tiempo alcanzados
cuando utilizan el producto o sistema
T = tiempo
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;


Efectividad
A = número de tareas únicas
Tareas Proporción de las tareas que se
completadas
completadas completan correctamente sin asistencia
B = número total de tareas únicas
intentadas
� 𝑋𝑋 = 1 − � 𝐴𝐴𝐴𝐴 � 𝑋𝑋 ≥ 0 }
Ai = valor proporcional de cada Proporción de los objetivos de la tarea
Objetivos
objetivo faltante o incorrecto en el que se alcanzan correctamente sin
alcanzados
resultado de la tarea (valor asistencia
máximo = 1)
Eficiencia
𝑋𝑋 = 𝑇𝑇 Tiempo tomado para completar una
Tiempo de tarea
T = tiempo de la tarea tarea exitosamente
Eficiencia con la cual los usuarios
Eficiencia de A = número de objetivos
logran sus objetivos sobre el tiempo
tiempo alcanzados
cuando utilizan el producto o sistema
T = tiempo
Tabla 18. Función de medición de la calidad en uso para el estado operacional (2 de 2;


Cobertura de contexto
A = número de contextos
Grado en el que el producto se puede
adicionales en los cuales el
Contexto de uso usar en contextos de uso adicionales
producto se puede usar con
flexible (diferentes tipos de usuarios, usos y
aceptable calidad en uso
ambientes) con ninguna modificación o
B = número total de contextos
sólo simples modificaciones
adicionales en los cuales el
producto se puede usar
𝐵𝐵
𝑋𝑋 = 1/𝐵𝐵 � 𝐴𝐴𝐴𝐴
𝑖𝑖=1
A = modificabilidad de los Facilidad con la cual un producto se
Flexibilidad del
requisitos especificados (i) puede modificar para reunir requisitos
producto
B = número total de nuevos de usuario adicionales
requisitos desde los usuarios
específicos
4.2.2. Medidas de la calidad del producto (ISO/IEC 25023)

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.
calidad del producto (1 de 3; Los autores).

Se seleccionó la arquitectura 8.2 - FCp-1-G Cobertura funcional
que trata los riesgos técnicos
8.2 - FCr-1-G Corrección funcional
clave.
Con Se acordaron los criterios
Pertinencia funcional del
arquitectura para seleccionar la 8.2 - FAp-1-G
objetivo de uso
seleccionada arquitectura
Se seleccionaron las
Significado de la utilización
plataformas, tecnologías y 8.3 - PRu-3-G
de dispositivos de E/S
lenguajes
Modelo propuesto 45

Adecuación funcional del
8.2 - FAp-2-G
Se demostraron las sistema
características clave de la Capacidad de
arquitectura 8.2 - PCa-1-G procesamiento de
Demostrable transacciones
Intercambialidad de
Se ejercieron la interfaz 8.4 - CIn-1-G
formatos de datos
crítica y las configuraciones
Suficiencia de interfaz
del sistema 8.4 - CIn-3-S
externa
8.5 - UAp-1-G Descripción completa
El sistema es usable y tiene
8.5 - ULe-4-S Interfaz de usuario
las características de calidad
Aspecto estético de las
deseadas 8.5 - UIn-1-S
interfaces de usuario
Los usuarios pueden operar
8.5 - UOp-1-G Consistencia operacional
Usable el sistema
Se aceptaron los niveles de Corrección de error de
8.5 - UEp-2-S
defectos entrada de usuario
Categorización
Se conoció el contenido de
8.5 - UOp-7-S comprensible de la
liberación
información
Se puso a disposición la Integridad de la guía del
8.5 - ULe-1-G
documentación de usuario usuario
Los representantes de los
interesados aceptaron el 8.6 - RFt-1-G Evitación de fallos
Listo
sistema
Los representantes de los 8.5 - UOp-1-G Consistencia operacional
interesados quieren que se
8.7 - SIn-1-G Integridad de datos
haga operacional el sistema
8.5 - UOp-1-G Consistencia operacional
8.5 - UOp-3-S Personalizabilidad funcional
Personalización de la
8.5 - UOp-4-S
interfaz de usuario
El sistema se usó en un
8.5 - UOp-8-S Aspecto de consistencia
ambiente operacional
Integridad del registro del
8.8 - MAn-1-G
Operacional sistema
Adaptación ambiental del
8.9 - PAd-2-G
software
El sistema se usó en un Adaptación ambiental
8.9 - PAd-3-S
ambiente operacional operacional
El sistema está disponible
8.6 - RAv-1-G Disponibilidad del sistema
para los usuario previstos

Al menos un ejemplo del
sistema es completamente 8.5 - UOp-1-G Consistencia operacional
operacional
Operacional
El sistema es compatible con
Coexistencia con otros
los niveles de servicio 8.4 - CCo-1-G
productos
acordados
8.8 - MMd-1-G Eficiencia de la modificación
No se da más soporte al
Capacidad de la
sistema 8.8 - MMd-3-S
modificación
Retirado
8.9 - PRe-3-S Integración funcional
Se reemplazó o se
Reutilización de datos /
descontinuó el sistema 8.9 - PRe-4-S
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).

Adecuación funcional
𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 Proporción de las funciones específicas
Cobertura A = número de funciones perdidas y los criterios usados que se
funcional B = número de funciones implementan cuando se selecciona la
específicas arquitectura
Proporción de las funciones que
𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 proveen los resultados correctos
A = número de funciones que son cuando se selecciona la arquitectura.
Corrección
incorrectas Una función incorrecta es aquella que
funcional
B = número de funciones no provee un resultado razonable y
consideradas aceptable para lograr el objetivo
específico esperado
𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵
A = número de funciones perdidas
o incorrectas que se requieren Proporción de funciones que requiere
Pertinencia
para lograr un objetivo de uso el usuario y que proveen resultados
funcional del
específico apropiados para lograr un objetivo de
objetivo de uso
B = número de funciones uso específico
requeridas para lograr un objetivo
de uso específico
𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐵𝐵)/𝑛𝑛
𝑖𝑖=1𝑡𝑡𝑡𝑡𝑡𝑡
Ai = Duración de los dispositivos
Significado de de E/S ocupados para realizar un Proporción de tiempo usado para
la utilización de conjunto específico de tareas para desarrollar un conjunto específico de
dispositivos de la i-ésima observación tareas comparado con el tiempo de
E/S Bi = Duración de la operación de operación
E/S para realizar las tareas para la
observación i-ésima
n = número de observaciones
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

Adecuación funcional
𝑋𝑋 = � (𝐴𝐴𝐴𝐴)/𝑛𝑛
Proporción de las funciones y las
Ai = puntaje de adecuación
características de la arquitectura
para el objetivo de uso i, es
Adecuación funcional clave que se demostraron y los
decir, el valor medido de la
del sistema usuarios las requieren para lograr
adecuación funcional del
sus objetivos y proporcionar un
objetivo de uso para el i-ésimo
resultado apropiado
objetivo de uso específico
n = número de objetivo de uso
Eficiencia de rendimiento
Grado en que los límites máximos de
un producto o parámetro del sistema
Capacidad de A = número de transacciones
cumplen los requisitos. Dichos
procesamiento de completadas durante el tiempo
parámetros se asocian con la forma
transacciones de observación
en que se puede ejercer el sistema y
B = duración de la observación
se puede medir su desempeño
Compatibilidad
Grado en que con un producto se
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 pueden realizar sus funciones
A = número de formato de requeridas de manera eficiente al
datos intercambiable con otros compartir un entorno y recursos
Intercambiabilidad de
sistemas o software comunes con otros productos, sin un
formato de datos
B = número de formato de impacto perjudicial en cualquier otro
datos especifico a ser producto. En general, la integración
intercambiable con otros sistemas existentes se
demuestra.
A = número de interfaces Proporción de las interfaces externas
Suficiencia de
externas que son funcionales especificadas con otro software y
interfaz externa
B = número de interfaces sistemas es funcional.
externas específicas
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;

Reconocimiento de adecuación
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 Proporción de escenarios de uso
A = número de uso de que se presentan en la descripción
escenarios descritos en la del producto o en los documentos
Descripción
descripción del producto o en del usuario. La funcionalidad que
completa
los documentos del usuario proporciona el sistema se probó.
B = número de uso de Además, el sistema se documenta
escenarios del producto totalmente.
Aprendizaje
A = número de elementos de
información y pasos que se
presentan en una forma en Proporción de elementos de
que el usuario podría información y pasos presentados al
Interfaz de usuario
entender usuario que le permite completar
auto explicativa
B = número de elementos de tareas comunes sin previo
información y pasos para entrenamiento
completar tareas comunes
para un usuario por primera
vez
Interfaz de usuario
A = número de interfaces de
Aspecto estético de pantalla estéticamente Grado de satisfacción de la
las interfaces de agradables a los usuarios en apariencia del diseño de la interfaz
usuario apariencia de usuario
B = número de interfaces de
pantalla
Operabilidad
A = número de tareas
Grado en que un producto o
interactivas específicas que
sistema tiene atributos que lo hacen
Consistencia se realizan de manera
fácil de operar y controlar. Además,
operacional inconsistente
el sistema lo pueden operar las
B = número de tareas
partes interesadas que lo utilizan
deben ser coherentes
Tabla 22. Función de medición de la calidad del producto para el estado usable (2 de 2;

Operabilidad
A = número de estructuras de
Grado en que con el software se
Categorización información que son
organiza la información en
comprensible de la familiares y convenientes
categorías convenientes para los
información para los usuarios previstos
usuarios
B = número de estructuras de
información usadas
Protección de error de usuario
A = número de errores de
Corrección de error usuario que se diseñan y se Grado en que con el sistema se
de entrada del validan protege a los usuarios contra
usuario B = número de errores de errores detectados
usuario que ocurren durante
la operación
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
A = número de funciones que Proporción de funciones que se
se describen en la explican detalladamente en la
Integridad de la guía
documentación del usuario documentación del usuario. Además,
del usuario
B = número de funciones la instalación y la documentación se
implementadas que se encuentran disponibles
requiere documentar
Operabilidad
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
Tolerancia a fallos
A = número de incidentes
críticos y graves que se evitan
Grado en el que el producto funciona
(respecto de casos de prueba)
Evitación de fallos a pesar de la presencia de fallas de
B = número de casos de
hardware o software
prueba que se ejecutan con un
patrón de fallas durante la
prueba
Integridad
datos que se dañan por un Grado en el que con el producto se
Integridad de los acceso no autorizado previenen accesos o modificaciones
datos B = número de elementos de no autorizados a los datos y
datos que deben evitar la computadores
corrupción o modificación de
datos
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).

Operabilidad
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
A = número de funciones y
procedimientos operacionales
Grado en que las funciones y
que se personalizan a
Personalización procedimientos operacionales se
conveniencia del usuario
funcional personalizan a conveniencia del
B = número de funciones y
usuario
procedimientos operacionales
que benefician a los usuarios
debido a la personalización
interfaces de usuario que se
Proporción de elementos de interfaz
Personalización de la personalizan
de usuario que se personalizan en
interfaz de usuario B = número de elementos de
apariencia.
interfaces de usuario que se
benefician de la
personalización
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).

Analizabilidad
A = número de registros que Grado en el que con el sistema se
Integridad del registro se graban en el sistema graban operaciones en registros.
del sistema B = número de registros para Además, se pueden controlar las
los que se requieren pistas de operaciones
auditoría durante la operación
Disponibilidad
Proporción del tiempo en que el
A = tiempo real de operación
Disponibilidad del sistema está realmente disponible
del sistema
sistema versus el tiempo de funcionamiento
B = tiempo programado para
programado
la operación del sistema
Adaptabilidad
A = número de funciones
incompletas o insuficientes que
Adaptabilidad del Grado en que el sistema o producto
no cumplen los requisitos
sistema de software se adapta a diferentes entornos de
durante las pruebas
al entorno software
B = número de funciones que
se prueban en diferentes
entornos de software
A = número de funciones
incompletas o insuficientes que
Grado en que el sistema o producto
Adaptabilidad del no cumplen los requisitos
se adapta a diferentes entornos
entorno operacional durante las pruebas operativas
operativos
se prueban en diferentes
entornos operativos
Coexistencia
A = número de otros productos
Grado en el que el producto
de software con los que el
comparte el entorno con otro
Coexistencia con producto coexiste
software sin afectar negativamente
otros productos B = número de otros productos
sus características y funcionalidades
que coexisten con este
de calidad
producto en el entorno de
operación
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

Modificabilidad
𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐵𝐵)/𝑛𝑛
Ai = tiempo total que se gasta
para realizar una modificación
Eficiencia de específica i; Proporción del tiempo empleado en
modificación Bi = tiempo esperado para las modificaciones que se realizan
hacer una modificación
específica i;
n = número de modificaciones
medidas
A = número de elementos que
se modifican en una duración
Capacidad de Proporción de modificaciones que se
especifica
modificación realizan en una duración especifica
B = número de elementos que
se requieren modificar en una
duración específica
Reemplazabilidad
A = número de funciones que
Proporción de funciones del producto
producen resultados similares
Inclusión funcional que se usan fácilmente después de
reemplazar el producto de software
se utilizan en el producto de
software reemplazado
A = número de datos que se
Capacidad de usan continuamente Proporción de datos del producto
reutilización o B = número de datos que se que se usan después de reemplazar
importación de datos usan continuamente en el el producto de software
producto de software
reemplazado
Modelo propuesto 55
4.2.3. Medidas de la calidad del dato (ISO/IEC 25024)

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.
calidad del dato (1 de 2; Los autores).
Medida
Estado Lista de verificación ID
(ISO/IEC 25024)
Consistencia de la
Con Se acordaron los criterios 8.4 - Con-I-4
arquitectura
arquitectura para seleccionar la
Cumplimiento normativo
seleccionada arquitectura 8.8 - Cmp-I-2
debido a la tecnología
Se demostraron las
Consistencia del formato
características clave de la 8.4 - Com-I-2
de datos
arquitectura
Demostrable
Los interesados relevantes
Consistencia de la
acordaron que la 8.4 - Com-I-4
arquitectura
arquitectura es apropiada
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
El sistema es usable y
tiene las características de 8.9 - Cnf-D-1 No vulnerabilidad
calidad deseadas 8.11 - Pre-I-1 Precisión de los valores
Usable 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
8.10 - Eff-I-2 Eficiencia de utilización
Los usuarios pueden
operar el sistema 8.10 - Eff-D-2 Eficiencia de
procesamiento de datos
calidad del dato (2 de 2 Los autores).
Medida
Estado Lista de verificación ID
(ISO/IEC 25024)
8.3 - Com-I-1 Registro completo

Los representantes de los
Listo interesados quieren que se 8.3 - Com-I-6 Modelo conceptual de
haga operacional el datos completo
sistema
8.3 - Com-I-8 Metadatos completos
El sistema está disponible
8.7 - Acs-I-1 Accesibilidad del usuario
para los usuarios previstos
Cumplimiento normativo
El sistema es compatible 8.8 - Cmp-I-1
del valor y/o formato
con los niveles de servicio
Trazabilidad del valor de
acordados 8.12 - Tra-D-2
los datos
Operacional
8.14 - Ava-D-1 Proporción de
disponibilidad de datos
El sistema es compatible
con los niveles de servicio 8.15 - Por-D-1 Proporción de portabilidad
de datos
acordados
8.16 - Rec-D-1 Proporción de
recuperabilidad de datos
No se producirán más Frecuencia de
Retirado 8.6 - Cur-I-1
actualizaciones al sistema 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).

QMs de consistencia
A = número de elementos de una
arquitectura que tienen un Grado en el que los elementos de la
Consistencia de elemento referenciado arquitectura tienen una
la arquitectura correspondiente en la arquitectura correspondencia con algún elemento
instalada de la arquitectura referenciada
B = número de elementos de la
arquitectura referenciada
QMs de conformidad
A = número de elementos del
dato que se ajustan a los
Cumplimiento
estándares o regulaciones debido Grado en el que los elementos del dato
normativo
a la tecnología cumplen con estándares o
debido a la
B = número de elementos del regulaciones específicas
tecnología
dato que se deben ajustar a los
estándares o regulaciones debido
a la tecnología
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;

QMs de consistencia
dato donde el formato de todas
Consistencia Grado en el que la consistencia del
las propiedades es consistente en
del formato de formato de datos se mantiene con los
diferentes archivos de datos
datos mismos elementos del dato
B = número de elementos para
los cuales se define la
consistencia del dato
Tabla 28. Función de medición de la calidad del dato para el estado demostrable (2 de 2;

QMs de consistencia
A = número de elementos de una
arquitectura que tienen un Grado en el que los elementos de la
Consistencia de elemento referenciado arquitectura tienen una
la arquitectura correspondiente con la correspondencia con algún elemento
arquitectura instalada de la arquitectura referenciada
B = número de elementos 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;

QMs de exactitud
modelo de datos con los que se
describe la exactitud del sistema Grado en el que con el modelo de
Exactitud del
B = número de elementos del datos se describe el sistema con la
modelo de datos
modelo de datos con los que se exactitud requerida
describe la exactitud requerida
dentro de la especificación de
requisitos del sistema
QMs de consistencia
dato donde el formato de todas
Grado en el que la consistencia del
Consistencia del las propiedades es consistente
formato de datos se mantiene con los
formato de datos en diferentes archivos de datos
mismos elementos del dato
B = número de elementos para
los cuales se define la
consistencia del dato
QMs de credibilidad
información donde se validan y
Grado en el que los elementos de
Credibilidad de los se certifican los valores para un
información se consideran
valores proceso específico
verdaderos, reales y creíbles
B = número de elementos de
información que se necesita
validar y certificar
A = número de elementos de un
modelo de datos con
Credibilidad del definiciones apropiadas que se Grado en el que con el modelo de
modelo de datos validan y certifican en un datos se provee información creíble
proceso específico
B = número de elementos de un
modelo de datos

QMs de confidencialidad
A = número de valores del dato
que se codifican y decodifican Grado en el que los valores del dato
Uso de cifrado correctamente cumplen los requisitos de cifrado o
B = número de valores del dato codificación
con requisitos para codificación o
decodificación
A = número de accesos que
usuarios no autorizados realizan
con éxito durante intentos
formales de penetración para Grado en el que el elemento del dato
No vulnerabilidad alcanzar el elemento del dato confidencial lo pueden acceder
objetivo en un período específico solamente usuarios autorizados
B = número de accesos que los
usuarios no autorizados realizan
al dato objetivo en un período
específico
QMs de eficiencia
A = número de valores del dato
Proporción de los valores del dato que
Eficiencia que los usuarios evalúan como
permiten un fácil uso a los futuros
utilizable ‘fácilmente usados’
usuarios
B = número de valores del dato
que evalúan los usuarios
Eficiencia del A = tiempo perdido debido a la Proporción del tiempo que se pierde
procesamiento de representación de los elementos debido a la representación del
datos del dato durante un trabajo elemento del dato
B = tiempo de procesamiento
QMs de precisión
A = número de los valores del
Grado de precisión de los valores del
Precisión de los dato con la precisión requerida
dato de acuerdo con la especificación
valores del dato B = número de valores del dato
definida en el requisito
con el requisito de precisión
definido
Modelo propuesto 61

QMs de entendimiento
A = número de los valores del
dato que los usuarios entienden
Entendimiento de Proporción de los valores del dato que
fácilmente
los valores del los usuarios entienden en un contexto
B = número de los valores del
dato específico de uso
dato que los usuarios intentan
entender durante un período de
observación
QMs de disponibilidad
Proporción de los elementos del dato
Relación de dato disponibles en un período
disponibles cuando se requieren (ej.
disponibilidad de específico
copias de seguridad o procedimientos
datos B = número de elementos del
de restauración)
dato que se requieren en el
mismo periodo
QMs de portabilidad
Relación de dato con los que se preserva la Proporción de la calidad del dato que
portabilidad de calidad existente después de la no disminuye después del proceso de
datos migración migración
B = número de elementos del
dato migrados
QMs de recuperabilidad
Relación de Grado en el que los datos
dato que se recuperan
recuperabilidad almacenados en un dispositivo se
exitosamente
del dato recuperan exitosamente
dato que se deben recuperar
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

QMs de completitud
dato con valores no nulos en un Grado de completitud de los
Completitud del
registro elementos del dato de un registro en
registro
B = número de elementos del un archivo de datos
dato del registro para el cual la
completitud se mide
A = número de entidades del
Completitud del modelo de datos conceptual Proporción de las entidades que se
modelo B = número de entidades del describen completamente en el
conceptual de modelo de datos conceptual con modelo conceptual de datos y en el
datos los que se describe esquema contextual
completamente el esquema
contextual
A = número de atributos con
metadatos completos dentro del
Completitud de los Grado de completitud de atributos
diccionario de datos
metadatos para los metadatos
B = número de atributos para el
cual los metadatos se esperan
dentro del diccionario de datos
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;

QMs de accesibilidad
dato relevantes para las tareas
del usuario dentro de un
contexto de uso específico que
tienen valores accesibles
Accesibilidad del Grado en el que los valores del dato
usuario son accesibles para los usuarios
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
QMs de conformidad
dato que se ajustan a los
Cumplimiento estándares o regulaciones Grado en el que los elementos del
normativo debido debido a la tecnología dato cumplen con estándares o
a la tecnología B = número de elementos del regulaciones específicas
dato que se deben ajustar a los
estándares o regulaciones
debido a la tecnología
QMs de trazabilidad
dato que se pueden rastrear
usando las capacidades del Grado de rastreabilidad de la historia
Trazabilidad del
sistema de los elementos del valor del dato
valor del dato
B = número de elementos del usando las capacidades del sistema
dato que se espera rastrear
utilizando las capacidades del
sistema
QMs de disponibilidad
Proporción de los elementos del dato
Relación de dato disponibles en un período
disponibles cuando se requieren (ej.
disponibilidad de específico
copias de seguridad o procedimientos
datos B = número de elementos del
de restauración)
dato que se requieren en el
mismo periodo
Tabla 31. Función de medición de la calidad del dato para el estado operacional (2 de 2;

QMs de portabilidad
Relación de dato con los que se preserva la Proporción de la calidad del dato que
portabilidad de calidad existente después de la no disminuye después del proceso de
datos migración migración
dato migrados
QMs de recuperabilidad
Relación de Grado en el que los datos
dato que se recuperan
recuperabilidad almacenados en un dispositivo se
exitosamente
del dato recuperan exitosamente
dato que se deben recuperar
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

QMs de actualidad
datos actualizados con la Grado en el que los elementos del
Frecuencia de
frecuencia requerida dato se actualizan con la frecuencia
actualización
B = número de elementos de requerida
datos que tienen un requisito de
frecuencia de actualización
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
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.
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
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.
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
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
Caso depropuesto
estudio 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.
Tabla 33. Protocolo del estudio de caso según Maimbo y Pervan (2005)
Sección Contenido
Contiene información sobre el propósito del protocolo y guías
Preámbulo
para el almacenamiento de datos y documentos
Proporciona una breve descripción del proyecto de
General
investigación y el método de investigación de caso
Descripción detallada de los procedimientos para llevar a
Procedimientos cabo cada caso, incluidos detalles prácticos sobre los
contactos y el calendario
Guías de entrevista, cuestionarios, etc., que se utilizan para
Instrumentos
garantizar una recopilación de datos coherente
Guía análisis Descripción detallada de los procedimientos de análisis de
de datos datos, incluidos esquemas de datos, códigos a priori, etc.
Esquema Validación del modelo para evaluar la salud y el progreso del
preconceptual alfa sistema de software en un esfuerzo en ingeniería de
ejecutable 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).

Caso depropuesto
Modelo estudio 79
Figura 35. Carta de participación (Los autores).
Figura 36. Entrevista (Los autores).

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?
Accept /
State Checklist Measure formula Rationale Comments
Reject
Functional coverage: The proportion of the specified functions
𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 and criteria be used when selecting the
A = number of functions missing architecture have been agree on.
B = number of functions specified
Architecture selected that
The proportion of functions and criteria
addresses key technical risks Functional correction:
provides the correct results. An incorrect
function is one that does not provide a
A = number of functions that are incorrect
reasonable and acceptable outcome to
B = number of functions considered
achieve the specific intended objective.
Architecture consistency:
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 The proportion of the elements or
A = number of elements of an architecture that functions for selecting architecture
Architecture Criteria for selecting
have a corresponding referenced elements in agreed on by the user provides
selected architecture agree on
the installed architecture appropriate outcome to achieve a
B = number of elements of the referenced specific usage objective.
architecture
Mean I/O devices utilization:
𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐵𝐵) /𝑛𝑛 The degree to which the amounts and
𝑖𝑖=1 𝑡𝑡𝑡𝑡 𝑛𝑛
types of resources used by a product or
Platforms, technologies, and Ai = duration of I/O device(s) busy time to system when performing its functions
language selected perform a given set of tasks for i-th observation meet the requirements. Such
Bi = duration of I/O operations to perform the requirements are platforms,
tasks for i-th observation technologies, and language to be used.
n = number of observations
Caso depropuesto
Modelo estudio 81
5. Is there any relationship between the demonstrable state and the following related measures? Do you have any comments?
Accept /
Reject
Functional appropriateness of system:
𝑋𝑋 = � 𝐴𝐴𝐴𝐴/𝑛𝑛 The proportion of the functions and key
Ai = Appropriateness score for usage objective architecture characteristics were
i, that is, the measured value of specific usage demonstrated and required by the
objective users to achieve their objectives and
Key architecture characteristics n = number of usage objectives provide an appropriate outcome.
demonstrated Data format consistency:
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 The degree to which data has attributes
A = number of data items where the format of that are free from contradiction and are
all properties is consistent in different data files coherent with other data in a specific
B = number of data items for which format context of use.
Demonstrable consistency can be defined
Overall satisfaction: The degree to which user needs are
Relevant stakeholders agree
𝑋𝑋 = � 𝐴𝐴𝐴𝐴 satisfied when a product or system is
architecture is appropriate
Ai = response to a question used in a specified context of use.
The degree to which a product can
Data formats interchangeability: perform its required functions efficiently
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 while sharing a common environment
Critical interface and system A = number of data formats exchangeable with and resources with other products,
configurations exercised other software or system without detrimental impact on any other
B = number of data formats specified to be product. In general, the integration with
exchangeable other existing systems has been
demonstrated.
6. Is there any relationship between the usable state and the following related measures? Do you have any comments?
Accept /
Reject
Satisfaction with features:
𝑋𝑋 = � 𝐴𝐴𝐴𝐴
Ai = response to a question related to a specific feature
Self-explanatory user interface:
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 The proportion of functions is explained
A = number of information elements and steps that are in enough detail in user documentation
presented in a way that the user could understand and/or help facility to enable the user to
System is usable and has B = number of information elements and steps needed to apply the functions or features.
desired characteristics complete common tasks fir first time user
Non-vulnerability: The degree to which data item defined
as confidential can be accessed by
authorized users only.
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
Usable Operational consistency:
The degree to which a product or system
has attributes that make it easy to
System can be operated A = number of specific interactive tasks that are performed
operate and control. Also, the system
by users inconsistently
can be operated by stakeholders who
B = number of specific interactive tasks that need to be
use it.
consistent
Defect levels acceptable User entry correction:
The degree to which the system protects
users against making errors. Also, the
Functionality and A = number of user errors that are designed and tested to
performance of the system is acceptable
performance have been recovered by the system
for the final users.
tested and accepted B = number of user errors which can occur during operation
Understandable categorization of information: The software organizes the information
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 in categories that are familiar to the
Release content known A = number of information structures that are familiar and intended users and convenient for their
convenient for the intended users tasks. Also, the release content is
B = number of information structures used known.
Caso depropuesto
Modelo estudio 83
7. Is there any relationship between the ready state and the following related measures? Do you have any comments?
Accept /
Reject
User guidance completeness: The proportion of functions is explained
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 in enough detail in user documentation
A = number of functions described in user and/or help facility to enable the user to
User documentation available
documentation and/or help facility as required apply the functions. In addition,
B = number of functions implemented that are installation and another user
required to be documented documentation are available.
Failure avoidance:
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 The degree to which a system or
Stakeholders representatives A = number of avoided critical and serious product operates as intended despite
accept system failure occurrences (based on test cases) the presence of hardware or software
B = number of executed test cases of fault faults.
pattern (almost causing failure) during testing
User trust:
𝑋𝑋 = 𝐴𝐴
Ready A = Psychometric scale value from a trust
The degree to which a user or other
questionnaire
stakeholder has confidence that a
Data integrity:
product/system will behave as intended.
A = number of data items which are actually
Stakeholders representatives The degree to which a system or
corrupted by unauthorized access
want to make system product prevents unauthorized access
B = number of data items for which data
operational to, or modification of, computer
corruption or modification have to be prevented
programs or data.
Record completeness:
Completeness of data items of a record
A = number of data items with associated value
within a data file.
not null in a record
B = number of data items for which
completeness can be measured
8. Is there any relationship between the operational state and the following related measures? Do you have any comments?
Accept /
Reject
The degree of effectiveness and
System log completeness:
efficiency with which it is possible to
System in use in assess the impact on a product of an
A = number of logs that are actually recorded in the
operational intended change to one or more of its
system
environment parts, or to diagnose a product for
B = number of logs for which audit trail required during
deficiencies or causes of failure, or to
operation
identify parts to be modified.
User accessibility:
The system is available in the system
A = number of data items relevant to the user’s task
operational time schedule. That is
within specific context of use having values accessible
System available to means that the product or system can
by intended users
intended users be extended to special days, such a
B = number of data items that are relevant to the user’s
holidays and weekend, in addition to
task within the context of use having values that are
regular operational days.
required to be accessible in conformance to
specification
Operational At least one example of
Time efficiency:
The efficiency with which users achieve
system is fully their objectives over time when using
A = number of objectives achieved
operational the system.
T = Time
System software environmental adaptability:
𝑋𝑋 = 1 − 𝐴𝐴/𝐵𝐵 The degree to which a product can
A = number of functions which were not completed or effectively and efficiently be adapted for
results which were insufficient to meet requirement different or evolving hardware, software
during testing or other operational or usage
System supported to B = number of functions which were tested in different environments.
agreed-on service system software environment
levels Co-existence with other products: The product can share the environment
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 with other software without adverse
A = number of other specified software products with impact on their quality characteristics or
which this product can co-exist functionalities. Also, the system is fully
B = number of other software products specified to co- supported to the agreed service levels.
exist with this product in the operation environment
Caso depropuesto
Modelo estudio 85
9. Is there any relationship between the retired state and the following related measures? Do you have any comments?
Accept /
Reject
Modification efficiency:
𝑋𝑋 = � (𝐴𝐴𝐴𝐴/𝐵𝐵𝐵𝐵) /𝑛𝑛 The product can be effectively and
𝑖𝑖=1 𝑡𝑡𝑡𝑡 𝑛𝑛 efficiently modified without defects or
Ai = total work time spent for making a specific degrading existing product quality. In
type of modification i addition, we can identify if the system
Bi = expected time for making the specific type has been replaced or discontinued.
of modifications i
System no longer supported
n = number of modifications measured The proportion of items or modifications
Modification capacity: made within a specified duration. Also,
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 we can find through updates if the
A = number of items actually modified within a system will no longer be produced and
specified duration in fact, it is not needing any more
B = number of items required to be modified modification.
Retired
within specified duration
Update frequently:
The degree to which data has attributes
that are of the right age in a specific
Updates to system will no A = number of data items updated with the
context of use. In addition, when data
longer be produced required frequency
items are updated with the frequency
B = number of data items having an update
required.
frequency requirement
Data reuse/import capability: The same data of the product can be
𝑋𝑋 = 𝐴𝐴/𝐵𝐵 used after replacing previous software
System has been replaced or A = number of data which can be used product by the own. That means that
discontinued continuously as before the developers can reuse or reproduce
B = number of data which are to be used parts of the coding in another project or
continuously in the replaced software product the same in another implementation.
Caso depropuesto
Modelo estudio 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).
Total ISO/IEC 25022 ISO/IEC 25023 ISO/IEC 25024

Estado
medidas Calidad en uso Calidad del producto Calidad del dato
Con arquitectura
4 3 1
seleccionada
Demostrable 4 1 2 1
Usable 6 1 4 1
Listo 5 1 3 1
Operacional 5 1 3 1
Retirado 4 3 1
Total seleccionadas para
28 4 18 6
validar
(%) 37% 5% 13% 5%
Total seleccionadas por
75 17 31 27
estado
(%) 100% 23% 41% 36%
 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
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 4 Desarrollador de software Junior
Participante 5 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

Se acordaron los criterios para
Consistencia de la arquitectura
Arquitectura seleccionar la arquitectura
seleccionada Se seleccionaron las plataformas, Significado de la utilización de
tecnologías y lenguajes dispositivos de E/S
Se demostraron las características clave Adecuación funcional del sistema
de la arquitectura Consistencia del formato de datos
Demostrable
Se ejercieron la interfaz crítica y las Intercambialidad de formatos de
configuraciones del sistema datos
Caso de estudio 91
Tabla 38. Medidas que los participantes aceptan (2 de 2; Los autores)
Estado Ítem lista de chequeo Medida

El sistema es usable y tiene las Interfaz de usuario auto
características de calidad deseadas explicativa
Los usuarios pueden operar el sistema Consistencia operacional
Se aceptaron los niveles de defectos
Usable Corrección de error de entrada de
Se han probado y aceptado la
usuario
funcionalidad y el rendimiento
Categorización comprensible de
Se conoció el contenido de liberación
la información
Se puso a disposición la documentación
Integridad de la guía del usuario
de usuario
Los representantes de los interesados
Evitación de fallos
Listo aceptaron el sistema
Los representantes de los interesados Integridad de datos
quieren que se haga operacional el
Registro completo
sistema
El sistema se usó en un ambiente
Integridad del registro del sistema
operacional
El sistema está disponible para los
Operacional Accesibilidad del usuario
usuario previstos
El sistema es compatible con los niveles Adaptación ambiental del software
de servicio acordados Coexistencia con otros productos
No se producirán más actualizaciones al
Frecuencia de actualización
sistema
Retirado
Se reemplazó o se descontinuó el Reutilización de datos/Capacidad
sistema de importación
Tabla 39. Medidas que los participantes no aceptan (1 de 3; Los autores)
Ítem lista de
Estado Medida Comentarios
chequeo
- 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
Cobertura
estado de la lista de verificación
funcional
- Con esta medida es imposible hacer
Arquitectura alguna prueba
Arquitectura seleccionada que - ¿Cuál es la diferencia para evaluar
seleccionada aborda riesgos la cobertura y la corrección?
técnicos clave ¿Podemos integrar ambos?
- ¿Podríamos integrar las dos
medidas en una sola?
- No puedo medir la corrección
Corrección
funcional en mi rol de pruebas, solo
funcional
la cobertura funcional.
- No sé cómo podría medirse ¿Alguna
corrección o criterio funcional?
Ítem lista de
chequeo
- Es una medida muy general, falta
especificación
- Revisar su idoneidad
Esta medida es muy general. Sin
embargo, ¿tiene alguna medida
adicional?
Los interesados
- La medida debe ser específica.
relevantes
Satisfacción Sugiero eliminar esta medida. No
Demostrable acordaron que la
general parece relevante aquí
arquitectura es
- No es una medida clara y coherente
apropiada
- 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
- 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.
Satisfacción
- La fórmula no es suficiente para
con
medir la satisfacción.
características
- 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?
- Esta medida se puede relacionar
El sistema es
con algunos ítems de seguridad y
usable y tiene las
Usable no de usabilidad
características de
- Esta medida no es coherente con el
calidad deseadas
estado usable. Revisar y verificar su
idoneidad
- Es un atributo que se relaciona con
los criterios de seguridad y no se
No
relaciona directamente con el
vulnerabilidad
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
Ítem lista de
chequeo
- ¿Cómo se obtiene la escala
psicométrica?
- Estas medidas no son suficientes y
claras para que el sistema sea
Los
operativo
representantes de
- En las pruebas, es difícil de medir.
las partes
Confianza del ¿Quién define la escala
Listo interesadas
usuario psicométrica?
quieren que el
- No lo necesito aquí. Te sugiero que
sistema sea
elimines esta medida
operativo
- Para mi punto de vista es
complicado medir
- En mi experiencia, no puedo medir
la confianza. ¿Explícame cómo?
- No es una medida suficiente para
cubrir la lista de verificación y el
Al menos un
estado operativo
ejemplo de
Eficiencia de - Estaba trabajando en un equipo de
Operacional sistema es
tiempo prueba y ahora soy desarrollador,
completamente
pero estoy realmente preocupado
operativo
por esta medida. No parece
conveniente, ni convincente
- 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
Eficiencia de
modificación no tiene relación
la modificación
directa con el estado y el elemento.
- Esta medida se centra más en las
No se da más modificaciones y la lista de
Retirado
soporte al sistema 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?
- Esta medida se centra más en las
modificaciones y la lista de
verificación de estado significa que
Capacidad de
ya no es compatible. Luego, no
modificación
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

Que no se seleccione la cantidad Contactar diferentes empresas de
Selección
requerida de participantes y que no desarrollo de software para lograr al
inadecuada de
cumplan con los requisitos mínimos menos la participación de cinco
participantes
de participación expertos en el caso de estudio
Que los participantes se
Difusión de Aplicar las entrevistas a cada
comuniquen entre sí y esto afecte
información participante por separado
los resultados del caso de estudio
Durante el proceso de
Poco Que los participantes no conozcan contextualización del caso de
conocimiento del la conceptualización del núcleo de estudio, dar a conocer a los
objeto de estudio Semat, los alfas y sus estados participantes información general
de la Esencia Semat
Elaborar un instrumento estable y
Inestabilidad del confiable.
Poca o nula confiabilidad del
instrumento de Realizar prueba piloto con al menos
instrumento
validación un experto de la academia y la
industria.
Manejo avanzado del inglés para el
Idioma del diseño
Diseño y aplicación del instrumento diseño y aplicación del instrumento
del instrumento y
en un lenguaje y cultura diferente a Reconocimiento cultural y similitud
aplicación de la
Colombia en el desarrollo de proyectos de
entrevista
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
98 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
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.
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 Software Del Núcleo de Semat Con Base en Las Normas ISO/IEC 2502n e ISO/IEC 2504n

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

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

Cargado por

Copyright:

Formatos disponibles

Modelo para la medición del

progreso del alfa sistema de

Wilder Perdomo Charry

Universidad Nacional de Colombia

Wilder Perdomo Charry

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

Universidad Nacional de Colombia

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

Gracias a la Universidad Nacional de Colombia, sede Medellín, especialmente al

Finalmente, es mi privilegio agradecer a mi esposa y compañera de vida, quien me brindó

Palabras clave: Semat, Calidad de software, ISO/IEC 25000, Sistema de software,

Keywords: Semat, Software quality, ISO/IEC 25000, Software system, Measurement,

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

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

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

1. Marco teórico ...............................................................................................................3

3. Planteamiento del problema .....................................................................................30

5. Caso de estudio ........................................................................................................ 76

6. Conclusiones y trabajo futuro.................................................................................. 97

Figura 1. Arquitectura del núcleo de Semat (OMG, 2014)................................................ 3

Figura 25. Representación Semat de (a) medición de la calidad basada en estándares

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

Lista de Símbolos y abreviaturas

La norma ISO/IEC 25000 (SQuaRE—Software Product Quality Requirements and

En los estudios citados anteriormente se muestran esquemáticamente las medidas de la

La presente Tesis Doctoral se divide en seis Capítulos: en el Capítulo 1 se presenta el

1.1. Teoría y método de la ingeniería de software–Semat

Figura 1. Arquitectura del núcleo de Semat (OMG, 2014).

1.1.1. Áreas de interés

1.1.2. Alfas del núcleo de Semat

Figura 2. Alfas del núcleo de Semat (OMG, 2014).

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).

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

1.1.3. Elementos del núcleo de Semat

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

Nombre Símbolo Descripción

Espacio de Actividades siempre realizadas en cualquier

Descripción de cómo manejar un aspecto

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

Nombre Símbolo Descripción

Es un mecanismo “genérico” para nombrar

Producto de Dispositivo de valor y relevancia para un

Una asociación de patrón se visualiza

originan en un círculo que conecta cada

1.2. ISO/IEC 25000

Las características y sub-características de calidad incluyen medidas, las cuales tienen

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

Tabla 2. Características y sub-características de calidad del producto del sistema y

Tabla 2. Características y sub-características de calidad del producto del sistema y

Tabla 3. Estructura de la medida de calidad (ISO/IEC, 2016).

ID Nombre Descripción Función de medida

1.2.1. Estándar ISO/IEC 2502n

• ISO/IEC 25020—Guía y modelo de referencia para la medición: se presenta una

• ISO/IEC 25021—Elementos de medida de calidad: se define y especifica un conjunto

• ISO/IEC 25022—Medición de calidad en uso: se definen, específicamente, las métricas

• ISO/IEC 25023—Medición de la calidad del producto de software y sistemas: se

• ISO/IEC 25024—Medición de la calidad de datos: se definen, específicamente, las

1.2.2. Estándar ISO/IEC 2504n

La división de evaluación contiene un proceso con entradas de evaluación, las cuales

ISO/IEC 2504n incluye normas que proporcionan requisitos, recomendaciones y guías

• ISO/IEC 25040—Guía y modelo de referencia de la evaluación: se propone un modelo