03 Modelos y Control de Calidad PDF

MODELOS Y CONTROL DE CALIDAD
SEMANA 3
Aseguramiento de la
calidad del software
(SQA)
Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 3
ninguna clase.
2
ESTE DOCUMENTO CONTIENE LA SEMANA 3
ÍNDICE
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA) .................................................................. 5
OBJETIVOS ESPECÍFICOS ...................................................................................................................... 5
INTRODUCCIÓN ................................................................................................................................... 5
1. MÉTRICA DE LA CALIDAD DE SOFTWARE .................................................................................... 6
1.1. CONCEPTOS BÁSICOS ............................................................................................................. 6
1.1.1. ENTIDAD ................................................................................................................................. 6
1.1.2. ATRIBUTO ............................................................................................................................... 6
1.1.3. MEDIDA .................................................................................................................................. 7
1.1.4. MEDICIÓN ............................................................................................................................... 7
1.1.5. INDICADOR ............................................................................................................................. 7
1.1.6. INTERPRETACIÓN ................................................................................................................... 7
1.1.7. RANGO DE VALORES............................................................................................................... 7
1.1.8. VALOR ..................................................................................................................................... 7
1.2. EJEMPLO DEFINICIÓN DE MÉTRICA ........................................................................................ 8
2. APLICACIÓN DE MÉTRICAS DE SOFTWARE EN SQA................................................................................ 9
2.1. CLASIFICACIÓN DE MÉTRICAS ................................................................................................ 9
2.1.1. MÉTRICAS DEL PRODUCTO ..................................................................................................... 9
2.1.2. MÉTRICAS DEL PROCESO Y RECURSOS ................................................................................. 14
2.2. MÉTODO DE MEDICIÓN OBJETIVO-PREGUNTA-MÉTRICA (GOM) ....................................... 16
2.2.1. OBJETIVOS DE ALCANCE ....................................................................................................... 16
2.2.2. MODO DE APLICACIÓN ......................................................................................................... 17
COMENTARIO FINAL .............................................................................................................................. 22
REFERENCIAS ..................................................................................................................................... 23
ÍNDICE DE FIGURAS
Figura 1: Mirada integrada métricas de software .............................................................................. 9
Figura 2: El proceso GQM ()............................................................................................................... 17
3
ÍNDICE DE TABLAS
Tabla 1: Definición de una métrica ...................................................................................................... 8
Tabla 2: Definición de métricas sistemas orientados a objeto .......................................................... 12
Tabla 3: Las fases de GQM ................................................................................................................ 16
Tabla 4: Plantilla de definición de GQM ............................................................................................ 19
4
ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE (SQA)
OBJETIVOS ESPECÍFICOS
 Conocer los fundamentos básicos de métrica y su aplicación en el aseguramiento de la

calidad del software.
 Comprender las características y utilización de las métricas de calidad del software.
 Utilizar el método de medición GQM para el logro de objetivo de calidad.
INTRODUCCIÓN
El concepto de métrica resulta transversal a todo tipo de análisis de información,

independientemente de la industria en la cual se requiera utilizar. En términos generales,
corresponde a un sistema conformado por criterios, valores y otros elementos, los cuales
permiten evaluar alguna característica de un objeto en estudio. En el desarrollo de esta semana,
se revisará en detalle y en forma precisa la definición de métrica y cómo se aplica en el desarrollo
de productos de software.
5
1. MÉTRICA DE LA CALIDAD DE SOFTWARE
Desde el punto de vista de la calidad del software, evidenciar en forma objetiva el grado de
adherencia de la solución a los estándares, procedimientos y requerimientos es una actividad que
se debe hacer. Dicho de otra forma, es importante plantearse la siguiente pregunta: ¿se puede
cuantificar el grado de calidad de un producto o solución de software? Afortunadamente, la
respuesta es sí, se puede. Sin embargo, se deben hacer las siguientes preguntas: ¿cuándo se hace?
y ¿cómo se hace?
Cuando se habla de calidad del software, se puede decir que corresponde al grado en que un
conjunto de características del producto de software se ajusta a los requerimientos. Lo anterior
debiera reflejarse en la satisfacción del cliente, dada la concordancia del producto de software con
sus requerimientos. Para lograrlo, se debe recorrer un camino en el cual durante el ciclo de
desarrollo del software hay que realizar mediciones. Estas nos irán dando las señales de desviación
o adherencia, respecto a lo que se busca como resultado final.
Formalmente, para el concepto de métrica se puede adoptar la definición estándar dada por IEEE
(Institute of Electric and Electronic Engineers): “Una medida cuantitativa del grado en el que un
sistema, componente o proceso posee un atributo determinado” (Pressman, 2010, pp. 527).
1.1. CONCEPTOS BÁSICOS

Para poder entender y utilizar las métricas, a continuación se va a estudiar cómo se definen (óp.
cit.):
1.1.1. ENTIDAD
El concepto de entidad se puede definir como un objeto que va a ser caracterizado mediante una
medición de sus atributos. Así entonces, en términos más precisos, se puede definir una entidad
como un proceso, servicio, proyecto, o bien, algo para lo cual su medición resulta importante
dentro de un contexto determinado.
1.1.2. ATRIBUTO
Este concepto corresponde a una propiedad que es medible, y que a su vez puede referirse a una
representación física o abstracta de un concepto. Cuando se habla de representación física, se
hace referencia a un objeto en particular. Asimismo, al señalar que puede ser una representación
abstracta, por ejemplo un módulo de un sistema.
6
1.1.3. MEDIDA
Desde una mirada de ingeniería de software, Pressman (óp. cit.) define el concepto de medida
como el que proporciona un indicio cuantitativo de la extensión, cantidad, dimensión, capacidad o
tamaño de algún atributo de un producto o proceso. Sobre esa base, se entiende como el
resultado de una medición y su unidad de medida será determinada por la naturaleza del dato o
información que se esté midiendo.
1.1.4. MEDICIÓN
Corresponde al conjunto de acciones que van a realizarse para obtener una medida de un atributo
perteneciente a una entidad. Para realizarlas, se selecciona la forma que sea coherente con lo
requerido. Por ejemplo, definiendo un método de medición, una función de cálculo más
elaborada, o bien una estrategia de análisis de información.
1.1.5. INDICADOR
Corresponde a una métrica o combinación de estas, cuyo valor proporciona un entendimiento

objetivo respecto del proceso de software, proyecto de software, o bien, del producto de software
en particular. El valor de un indicador nos proporciona comprensión para realizar ajustes en el
ámbito que corresponda para obtener mejores resultados finales.
1.1.6. INTERPRETACIÓN
Corresponde al análisis que se debe realizar en cuanto al dato obtenido a través de la medición. La
que además puede tener consistencia, luego de haber obtenido un número considerable de
mediciones.
1.1.7. RANGO DE VALORES
Corresponde al rango de valores dentro del cual se espera esté el valor obtenido de la medición.
Para efectos de las interpretaciones, al existir mediciones que escapen al rango definido, se debe
revisar nuevamente el modelo y verificar que los rangos sean los adecuados.
1.1.8. VALOR
Corresponde al valor definitivo de la medición de acuerdo al rango donde clasificó.
7
1.2. EJEMPLO DEFINICIÓN DE MÉTRICA
De acuerdo a los conceptos vistos anteriormente, se revisará un ejemplo en el cual se quiere
medir el grado de facilidad que presenta el software para ser analizado ante la presencia de
errores que el usuario ha detectado en el ambiente productivo. En la tabla se detallan cada uno de
los conceptos definidos en el punto anterior.
Entidad: análisis del producto de software
Medida Valo
Atributo Medición Interpretación Rango
r
Facilidad de Se deben analizar las solicitudes Definición: Lo ideal es un valor

0,5 < X <= 1 5
diagnosticar un de mantenimiento efectuadas y de X lo más cercano a
establece
problema en el su evaluación preliminar, por lo 1, lo cual indica que
un
software. cual se requiere contar con existe un buen
porcentaje 0,2 < X <= 0,5 3
documentación del diagnóstico del
de los
mantenimiento. problema.
casos con
un
Forma de calcular: diagnóstico
X = A / B; correcto
A= Número de solicitudes de del
X < 0,3 1
mantenimiento con un problema.
diagnóstico correcto del
problema.
B= Número total de solicitudes
de mantenimiento.
Tabla 1: Definición de una métrica

Fuente: material elaborado para esta asignatura (J. Reyes, 2015).
8
2. APLICACIÓN DE MÉTRICAS DE SOFTWARE EN SQA
La aplicación de métricas en el software requiere una planificación y diseño previo, el cual asegure
que los objetivos de medición sean los adecuados y ayuden en el proceso de generación de
software de calidad. Como ya se ha mencionado, la calidad del software no es una propiedad
absoluta del producto en sí, ya que al analizarlo en forma integral todas las acciones que conlleva
el desarrollo de software inciden finalmente en el producto. Entonces, bajo este análisis, las
métricas ayudan en forma objetiva a establecer desviaciones en el proceso, proyecto y producto
final. Gráficamente podemos resumir lo anterior, en la Figura 1.
Figura 1: Mirada integrada métricas de software

Como se observa, el uso de métricas requiere definiciones previas que establezcan el ámbito a
evaluar (proceso de desarrollo de software, proyecto de desarrollo de software y producto de
software), como también la definición de las métricas que se utilizarán. De acuerdo a lo anterior,
se verá cómo se clasifican y cómo se utilizan.
2.1. CLASIFICACIÓN DE MÉTRICAS
2.1.1. MÉTRICAS DEL PRODUCTO
Las métricas del producto de software se enfocan en la evaluación de la calidad de los entregables
durante el ciclo de desarrollo, siendo estos por ejemplo módulos funcionales, componentes de
software u otro tipo de ítem de programación o documentación que se considera como parte de la
solución.
A diferencia de otras disciplinas, la ingeniería de software plantea muchos modelos a través de los
cuales busca precisar indicadores que den alertas o señalen el grado de adherencia de un
producto de software respecto a las definiciones iniciales que se hayan determinado para su
desarrollo. Se menciona lo anterior porque la ingeniería de software estudia el desarrollo de un
9
producto, el cual no es el resultado de una manufactura, fabricación o construcción, como
tradicionalmente lo hacen otras industrias en sus procesos productivos.
Por lo anterior, la definición de estas métricas en la ingeniería de software siempre tendrá

distintas valoraciones respecto a sus resultados.
2.1.1.1. ESTÁNDARES
Calidad de la especificación
A través de esta métrica se busca valorar la calidad de la especificación de requerimientos, donde

se consideran aspectos de calidad interna del producto, tales como especificidad, completitud,
corrección, comprensibilidad, verificabilidad, modificabilidad y reusabilidad; entre otros (Davis,
1993).
Así por ejemplo, se puede evaluar lo siguiente:
a. Especificidad
Si para una especificación existen requerimientos, donde
Donde:
corresponde al número de requerimientos funcionales
son los requerimientos no funcionales (por ejemplo, portabilidad del código). Para establecer
el nivel de especificidad de los requerimientos (falta de ambigüedad), se tiene:
Donde
es el número de requerimientos donde los revisores concluyeron lo mismo respecto a su

definición (misma interpretación). Así, mientras más cercano esté al valor de 1, menos
ambiguo será el requerimiento.
b. Completitud
Recuerde que un requerimiento es completo si en su definición están consideradas todas las

entradas y salidas que este debe abarcar. Si se habla de un sistema de caja, es claro que además
de recibir dinero debe ser capaz también de entregar vuelto cuando corresponda y calcularlo bien.
Así entonces, la completitud de los requerimientos puede evaluarse de acuerdo a la siguiente

expresión:
10
Los requerimientos funcionales únicos están representados por la expresión , en tanto que las
entradas al sistema son representadas por la expresión y el número de estados definidos en la
especificación corresponde a . Entonces, la relación mide el porcentaje de funciones
necesarias que se definió para un sistema.
2.1.1.2. MÉTRICAS PARA DISEÑO
Orientación a objetos
El paradigma de orientación a objetos para desarrollar software obedece a una visión distinta de
los sistemas tradicionales o secuenciales. Conceptualmente la orientación a objetos es un modelo
desestructurado y las métricas que interpretan este paradigma tienen por objetivo determinar el
tamaño del software, la herencia y características internas de las clases.
Conjunto de métricas propuestas por Chidamber y Kemerer (1994, citados por Piattini, García,
García y Pino, 2012) son las siguientes:
Métrica Descripción Método de evaluación

a. Métodos ponderados por Mide la complejidad de una clase Sea la clase C que tiene
clase (WMC, Weighted los métodos y
Methods per Class). su complejidad
VMC =
b. Profundidad del árbol de Mide el máximo nivel en la Se trata de la cuenta
herencia de una clase (DIT, jerarquía de herencia. directa de los niveles de
Depth of Inheritance Tree). la jerarquía de herencia.
DIT se considera como una métrica Considerando que en el
del número de clases antecesoras nivel cero de la jerarquía
que una clase podría se encuentra la clase raíz.
potencialmente afectar, debido a
que cuanto mayor sea el nivel de
profundidad de herencia de una
clase, mayor es el número de
métodos y atributos que hereda de
otras clases.
c. Número de hijos (NOC, NOC es el número de subclases Cuenta la cantidad
Number of Children). subordinadas a una clase en la directa de subclases de
jerarquía, es decir, la cantidad de una clase.
subclases que pertenecen a una
clase
d. Acoplamiento entre CBO determina para una clase en Cuenta directa de clases
objetos (CBO, Coupling particular el número de clases con acopladas.
Between Objects ). las cuales está acoplada. Se
11
considera acoplamiento cuando por
ejemplo un método de un objeto
usa el método de otro objeto.
e. Respuesta de una clase RFC establece el número potencial Cuenta directa de las
(RFC, Response for a Class) de métodos que se pueden ejecutar ocurrencias de llamados
como respuesta a un mensaje a otras clases de una
recibido de un objeto de esa clase. clase específica.
f. Falta de cohesión en los LCOM establece en qué medida los Se calcula como el
métodos (LCOM, Lack of métodos hacen referencia a los número de pares de
Cohesion in Methods). atributos. funciones sin variables
compartidas de instancia,
LCOM es una métrica de la menos el número de
cohesión de una clase en base al pares de funciones con
número de atributos comunes variables de instancia
usados por diferentes métodos. Un compartidas.
valor alto en LCOM implica falta de
cohesión, es decir, escasa similitud
entre los métodos siendo siempre
deseable un alto grado de cohesión
en los métodos de una clase.
Tabla 2: Definición de métricas sistemas orientados a objeto
Fuente: material elaborado para esta asignatura (J. Reyes, 2015)
2.1.1.3. MÉTRICAS DISEÑO WEBAPPS
En la industria de software no existe un criterio estándar para definir métricas para las
aplicaciones web. Por tanto, aún persiste un conjunto de métricas propuestas, las cuales son
interpretables y su adopción se deja a criterio de los equipos de desarrollo, los que pueden
también adaptarlas a sus propios proyectos (Pressman, 2010).
a. Métricas de interfaz sugeridas
Nombre Descripción
Complejidad de plantilla Número de regiones distintas definidas en una interfaz
Complejidad de región de Número promedio de distintos vínculos en cada región
plantilla
Complejidad de Número promedio de distintos ítems que el usuario
reconocimiento debe buscar para una acción
Complejidad de selección Número promedio de vínculos que pueden
seleccionarse por página
12
b. Métricas de diseño gráfico sugeridas
Nombre Descripción
Tamaño de página Bytes totales para la página (elementos, gráficos, hojas
de estilo)
Conteo de color Cantidad de colores usados
Conteo de vínculos Vínculos totales de una página
Conteo de palabras Cantidad total de palabras que aparecen en una página
Conteo grupo de textos Cantidad de áreas de texto resaltadas con color,
bordes, listas
Porcentaje gráfico Gráficos totales de una página
c. Métricas de contenido sugeridas
Nombre Descripción
Espera de página Tiempo promedio esperado para que una página
descargue el contenido
Complejidad de página Número promedio de tipos diferentes de medios
utilizados en la página. No incluye texto
Complejidad gráfica Número promedio de medios gráficos por página
Complejidad de video Número promedio de medios de video por página
d. Métricas de navegación sugeridas
Nombre Descripción
Complejidad de vinculación de Número de vínculos por página
página
Conectividad Número total de vínculos internos (no incluye los
generados dinámicamente)
Densidad de conectividad Conectividad dividida por conteo de página
2.1.1.4. MÉTRICAS DEL CÓDIGO FUENTE
Líneas de código LOC
Este tipo de métrica, conocida también como LOC (Lines of Code), tiene por objeto contabilizar la
cantidad de líneas de códigos escritas en un programa. Es una de las más clásicas y utilizadas
cuando las generaciones de lenguajes de programación eran estructuras lógicas secuenciales. Al
utilizarla surge cierta ambigüedad en el sentido de definir lo que efectivamente se quiere
contabilizar como línea de código. Por ejemplo, los comentarios. En algunos casos se consideran y
en otros no, queda a criterio de una definición de proyecto, así también ciertas instrucciones
13
declarativas o de forma, las cuales no necesariamente son estructuras “ejecutables como tal, pero
sí necesarias para la ejecución” (óp. cit.).
Longitud total LT
La longitud total LT (Total Long) corresponde a la suma total de las líneas de código que no son
comentarios más la suma total de las líneas de código que sí son comentarios. A partir de esta
definición, podemos obtener información relativa a, por ejemplo, el porcentaje o proporción de
líneas de comentario respecto al total de líneas. Podríamos asumir que estas corresponderán a la
documentación del programa (óp. cit.).
2.1.1.5. MÉTRICAS DE COMPLEJIDAD
Complejidad ciclomática
Métrica propuesta por Thomas McCabe en el año 1976, la cual se funda en principios matemáticos
aplicados al análisis algorítmico de un conjunto de instrucciones de código en programación. Lo
que se busca obtener es la cantidad de flujos independientes dentro de un conjunto de líneas de
código en un programa. Para representarla, se considera la teoría de grafos, y se utiliza un grafo de
control, donde se establece la cantidad de caminos linealmente independientes dentro del
programa. De su análisis se obtiene información importante para el desarrollo de pruebas o
análisis de un problema dado en la ejecución de instrucciones de un programa. Se calcula a través
de la siguiente expresión:
V (G) = A – N + 2
A representa la cantidad de arcos de un grafo y N la cantidad de nodos. A mayor valor de V (G),

mayor será la complejidad del programa. Por la naturaleza de la métrica, se busca que la medición
de V (G) sea la menor posible.
2.1.2. MÉTRICAS DEL PROCESO Y RECURSOS
2.1.2.1. MÉTRICAS DEL PROCESO
Como se ha mencionado anteriormente, la calidad del producto de software reúne una serie de
factores que inciden en el resultado final. Uno de ellos corresponde al proceso utilizado para
producir el software, el cual se basa en las definiciones que realiza la organización y su alcance, y
considera la información recopilada de todos los proyectos que se estén ejecutando, como
también los registros históricos de la actividad.
Desde el punto de vista organizacional, se pueden considerar algunos aspectos importantes en

todo proceso de desarrollo de software (óp. cit.):
 Motivación y habilidades de los miembros del equipo
14
 El nivel tecnológico utilizado en el proceso
 La complejidad del producto
Estos puntos influirán en el mejor desempeño deseado en el resultado. Además, se pueden

también considerar otros factores que en forma indirecta también influyen. Es el caso de las
condiciones de la organización, el cliente y entorno de desarrollo.
Así entonces, se pueden mencionar algunos criterios que permiten medir ciertas variables del
proceso de desarrollo de software, tales como las siguientes (óp. cit.):
 Errores durante el desarrollo

 Errores reportados por los usuarios
 Productividad del equipo
 Esfuerzo empleado en el desarrollo
 Tiempo utilizado en el desarrollo
 Cumplimiento de plazos
También es importante señalar que para definir y utilizar métricas se debe considerar el grado de
adherencia a las políticas organizativas. Esto tiene que ver más con las sensibilidades que se
suceden en algunos casos con las personas, por tanto, el uso de métricas siempre debe enfocarse
en el mejoramiento del proceso en su conjunto y no ser un instrumento que pueda generar
conflictos dentro del mismo equipo de desarrollo.
2.1.2.2. MÉTRICAS DEL PROYECTO
Las métricas de cada proyecto son la base de análisis para todo proceso de desarrollo de software.
Al mantener una medición permanente sobre el proyecto, quien lo administra buscará minimizar
costos, ajustarse a los plazos, generar un producto de acuerdo a su planificación. En la siguiente
lista se pueden resumir los factores que se miden y dan respuesta a los conceptos anteriormente
mencionados (óp. cit.):
 Evaluar y dar visibilidad del estado actual del proyecto

 Identificación y mitigación de riesgos
 Levantar puntos de atención para que no se transformen en problemas
 Evaluar las asignaciones de tareas
 Verificar la calidad del producto de software que se está desarrollando
Estas mediciones —en el ámbito del proyecto— tienen carácter táctico, puesto que los
administradores del proceso de desarrollo de software utilizarán estos datos para realizar ajustes
en los flujos de trabajo (procedimientos) y en las actividades que se espera sean realizadas de la
mejor forma posible en la organización.
15
2.2. MÉTODO DE MEDICIÓN OBJETIVO-PREGUNTA-MÉTRICA (GOM)
El método GQM (Goal Question Metric) fue elaborado por Basili y Weiss (1984), el cual establece
como primicia que la medición siempre debe estar orientada a satisfacer un objetivo, el cual se
depura a través de un conjunto de preguntas, las cuales derivan en las métricas que serán
definidas.
2.2.1. OBJETIVOS DE ALCANCE
Su formulación se lleva a cabo a través de tres fases, las cuales se resumen en la Tabla - 3:
Nombre Descripción
Planificación En esta etapa se selecciona, define y planifica un proyecto
de software; obteniéndose un plan de proyecto
Definición Se define y documenta el plan de medición (objetivos,
preguntas, métricas e hipótesis)
Recopilación de datos Se realiza la recopilan los datos
Interpretación Procesamiento de los datos recopilados utilizando las
métricas definidas. Estas representan respuestas a las
preguntas planteadas previamente y sobre las cuales se
evalúa si se responde o no el objetivo planteado
Tabla 3: Las fases de GQM
El proceso cómo se aplica cada una de estas fases es ilustrado en la Figura 2, donde a partir del
plan de proyecto se definen un conjunto de objetivos con sus respectivas preguntas, las cuales dan
origen a las métricas. Asimismo, hecha la recopilación de datos, se realizan las mediciones y de ese
universo de información se tratan de responder las preguntas antes planteadas. Cuando estas
preguntas encuentran respuesta en la información recopilada, se logra dar respuesta a los
objetivos definidos inicialmente.
16
Figura 2: El proceso GQM ()
Fuente: Piattini et al. (2012, p. 215).
2.2.2. MODO DE APLICACIÓN
A continuación se revisará con más detalle cada una de las fases que considera este método, de
acuerdo a lo señalado en Piattini (2012 et al.).
2.2.2.1. MÉTRICAS DEL PROCESO
Se recopila la mayor cantidad de información necesaria para sacar adelante la medición. El plan de
proyecto es el documento base para tal efecto, dado que en este se han definido procedimientos,
plazos, recursos y los objetivos del plan de medición. A continuación, se nombran las etapas de
esta fase.
Establecer el equipo GQM
El equipo se caracteriza porque sus miembros no forman parte de los equipos de desarrollo,
conocen detalladamente los objetivos de medición y tienen una orientación a la mejora de los
procesos. Se definen los roles de dirección del equipo de medición y las actividades que deben
llevar a cabo. Al mencionar algunas de estas, tenemos: planificar las mediciones que se realizarán
en los proyectos, ejecutar las tareas de medición y generar entregables (informes), comparar los
datos recolectados del proyecto versus los datos históricos del proceso, levantar mejoras e
informarlas a la organización.
Selección de áreas de mejora
Sobre la base de la información recolectada, se seleccionan áreas de mejora, las cuales pueden
estar en el ámbito del producto, proyecto, o bien, del mismo proceso. La evaluación debe
considerar los factores que puedan incidir en la aplicación de estas mejoras, por ejemplo, plazos,
prioridades, costo, disponibilidad en las agendas de los proyectos; por mencionar algunos.
17
Seleccionar el proyecto de aplicación y formar el equipo
Todas las actividades de medición se sustentan plenamente en la motivación y alineación con los
objetivos de mejora. Los integrantes del equipo GQM deberán liderar estos cambios e incidir en el
equipo de proyecto para que estos hagan propias las actividades necesarias para una buena
medición y mejores resultados finales.
Crear el plan de proyecto
Una vez creado el equipo de GQM y definidas las áreas de mejora, se debe trabajar en el plan de
proyecto, el cual debe considerar lo siguiente (Piattini et al., 2012):
a. Resumen de la gestión, la cual presenta en forma bien resumida el plan de medición

b. Una introducción del programa de mejora. En este se presentan los objetivos de mejora y
los objetivos del proyecto de desarrollo de software
c. Calendarización, incluyendo la planificación temporal, entregables, asignaciones de
recursos y análisis costo-beneficio de la mejora
d. Organización, donde se describe la estructura organizacional del proyecto y el equipo
GQM.
e. Procesos de gestión, donde se definen las prioridades, procedimientos de generación
informes de gestión y control de riesgos
f. Formación y promoción, donde se presenta el plan para la formación de los integrantes
del equipo del proyecto y la comunicación de los resultados a la organización
Formación y promoción
El equipo GQM difunde las características y alcance de las actividades con los equipos de proyecto
de desarrollo de software. Se planifican sesiones periódicas en las cuales se difunden los objetivos
de medición propuestos, los beneficios, impacto en el desarrollo del proyecto. El objetivo es
motivar y alinear a los miembros del equipo de proyecto de desarrollo de software en la
consecución de las actividades de medición ya definidas.
2.2.2.2. DEFINICIÓN
En esta etapa se definen formalmente las actividades necesarias para llevar a cabo el programa de
medición y los entregables corresponden a los planes GQM, de medición y análisis. Consta de las
siguientes etapas (óp. cit.).
 Definir los objetivos de medición
Sobre la base de los objetivos de mejora del proyecto definidos previamente, se debe obtener una
definición formal y estructurada. El método cuenta con una plantilla que facilita el orden y claridad
en las definiciones. Se muestra a continuación en la Tabla 3.
18
Concepto Alcance
Analizar El objeto de estudio bajo medición
Con el propósito de
Entender, mejorar o controlar el objeto
Con respecto a El enfoque de calidad del objeto en el que se centra la
medición
Desde el punto de Perspectiva del grupo que mide el objeto
vista de
En el contexto de El entorno en que la medición tiene lugar
Tabla 4: Plantilla de definición de GQM
Fuente: Piattini et al. (2012, p. 218)
 Revisar o producir los modelos de proceso de software
Dado el carácter de un programa de medición, es necesario que existan procedimientos que

determinen cómo se deben hacer las tareas por parte del equipo de desarrollo de software. En
ausencia de estos, el equipo de GQM debe proponerlos, o bien, en el caso que ya existan, verificar
si se ajustan al programa de medición. En el caso que no sea así, deben ser modificados para que
consideren la actividad de medición. Todo cambio o propuesta de ello debe estar también
aprobado por el equipo de proyecto de desarrollo de software.
 Realización de entrevistas GQM
Estas deben ser realizadas a los integrantes del equipo de proyecto de desarrollo de software, con
el objeto de realizar un levantamiento respecto a la información que el equipo de proyecto tiene
respecto a los objetivos de medición, métricas definidas, factores que pudieran alterar o afectar el
proceso de medición.
 Definir preguntas e hipótesis
A partir de la definición de los objetivos de medición. Las preguntas se plantean desde un punto
de vista operativo y las respuestas deberán ser evaluadas para determinar si se cumplen o no los
objetivos definidos. Esto se realiza en la fase de interpretación de datos.
 Revisión de preguntas e hipótesis
Es una verificación que se debe realizar con el objeto de asegurar que las preguntas e hipótesis
hayan sido bien planteadas.
 Definición de métricas
Son el resultado de la depuración de las preguntas pero traducidas en valores cuantificables. Las
métricas, como sabemos, proporcionan datos precisos (indicadores) en función de su formulación.
19
 Revisión de consistencia y completitud de métricas
Es una verificación que busca consistencia entre objetivos, preguntas y definición de las métricas;
respecto al objeto de medición.
 Generación del plan GQM
Consolida el plan de medición (¿cómo se realizará?, ¿quién lo realizará?, ¿cómo se evaluará?,

¿cómo se informará?), en el cual van los objetivos, preguntas, métricas e hipótesis del programa
de medición. Es la guía para la interpretación de datos y para el plan de medición y análisis.
 Elaboración del plan de medición
Corresponde a la definición de las tareas de medición, donde se identifica al responsable de

recolectar la información, el momento de hacerlo, el detalle de las observaciones y mediciones.
Así también la agenda de mediciones que debe ejecutarse con el equipo de proyecto de desarrollo
de software.
 Elaboración del plan de análisis
Documento donde se analiza la información provista respecto a preguntas y objetivos. En este

documento se consolida la información relevante y se procesa de manera que sea fácilmente
entendible por el equipo del proyecto de desarrollo de software. Sobre la base de la información
de este documento, se proponen mejoras en el ámbito en el cual se ha detectado alguna
desviación respecto al plan inicial del proyecto y el proceso de desarrollo de software definido en
la organización.
 Revisión de planes
Busca verificar y validar el desarrollo de los planes anteriores (que corresponden a medición y
análisis) con el equipo de proyecto de desarrollo de software. Es importante que en ambos casos
estén aprobados por ellos.
2.2.2.3. RECOPILACIÓN DE DATOS
Como su nombre lo define, en esta etapa se recopilará la información que se ha definido obtener
en función de los objetivos de medición. Se realiza una vez finalizada la etapa anterior, sus
principales fases son las siguientes (Piattini et al. 2012)
 Preparación e inicio de la obtención de datos
Inicialmente se realizará una inducción o traspaso de conocimiento orientado a asegurar el

entendimiento por parte de los miembros del equipo de los objetivos de la medición. Lo anterior
se apoya con procedimientos y las herramientas definidas para la actividad. Posteriormente, se
20
realiza una formalización que define el inicio de la actividad, para posteriormente realizar la
obtención de datos y su entrega al equipo GQM para su almacenamiento y tratamiento posterior.
 Sistema de soporte a la medición
El alcance de este sistema es brindar todas las herramientas para ingresar, procesar, analizar y
emitir informes de los resultados. Así también, mantener un registro histórico para posteriores
mediciones. Este sistema se compone de herramientas para bases de datos, archivos de carga
(Excel por ejemplo), sistemas visualizadores de datos entre otros. En rigor, esta plataforma la
define la organización, de acuerdo a los recursos de los cuales pueda disponer. Lo importante es la
información y el análisis que de ella se pueda realizar.
2.2.2.4. INTERPRETACIÓN
Es en esta etapa donde, luego de realizar el análisis pertinente a los datos, se concluye si se han
respondido las preguntas planteadas y alcanzado o no los objetivos propuestos (Piattini et al.,
2012).
 Preparación de sesiones de retroalimentación
El equipo de GQM prepara toda la información que deberá revisar con el equipo de proyecto de
desarrollo de software, para informarlo respecto a los resultados obtenidos. Lo anterior tiene por
objeto mostrar los temas de interés para facilitar la toma de decisiones en la mejora del ámbito
que corresponda.
 Sesiones de retroalimentación
El equipo de proyecto, como experto en el tema de análisis, revisa en conjunto con el grupo GQM
toda la información que ha sido preparada. En estas sesiones se deberán tomar las decisiones que
deriven en acciones para la mejora que corresponda realizar. Asimismo, se deben analizar otros
factores (como los ya mencionados costos, prioridad, disponibilidad y riesgos) para evaluar bien
las decisiones que se tomen.
 Generación de informes de interpretación
Dadas las sesiones de retroalimentación, se deben formalizar las conclusiones y recomendaciones

en un documento. El documento es elaborado por el equipo GQM y se distribuye a los miembros
del equipo del proyecto de desarrollo de software.
 Análisis costo-beneficio
Ante la toma de decisiones, siempre será recomendado realizar un análisis de costos y beneficios.
En este caso, también debe realizarse.
21
COMENTARIO FINAL
El aseguramiento de la calidad del software requiere una mirada que abarque no solo el producto
de software, sino también el proceso de desarrollo definido para hacerlo. En este sentido es
relevante que en las organizaciones definan estándares de trabajo que los equipos de desarrollo
utilicen. Esto implica tener una visión integrada del proceso completo. De esta forma, la manera
de realizar las tareas, apoyadas por métodos definidos y metodologías que faciliten su aplicación,
son la clave para desarrollar productos de software de calidad. Para materializar lo anterior, existe
una amplia variedad de estándares que se pueden adaptar a las necesidades de cada organización.
22
REFERENCIAS
Basili, V. y Weiss, D. (1984). A Methodology for Collecting Valid Software Engineering Data. IEE
Transactions on Software Engineerin, vol. SE-10, N° 6, pp. 728-738.
Davis, A.; Overmyer, S. ; Jordan, K.; Caruso, J.; Dandashi, F.; Dinh, A.; Kincaid, G.; Ledeboer, G.;
Reynolds, P.; Sitaram, P.; Ta, A. y Theofanos, M. (1993). Identifying and Measuring Quality
in a Software Requirements Specification. Proceeding First International Software Metrics
Symposium,Baltimore, MD, IEEE, pp. 141-152.
IEEE Computer Society (s. f.). About SWEBOK. Recuperado de:
http://www.computer.org/web/swebok
Piattini, M.; García, F.; García, I. y Pino, F. (2012). Calidad de sistemas de información. México:
Alfaomega Grupo Editor. Madrid: Ra-Ma.
Piattini, M. (2008). Medición y estimación del software. Técnicas y métodos para mejorar la calidad
y la productividad. México: Alfaomega Grupo Editor. Madrid: Ra-Ma.
Pressman, R. (2010). Ingeniería de Software, un enfoque práctico. 7.ª edición. España: Editorial
McGraw-Hill Interamericana S. A.
Sociedad del Aseguramiento de la Calidad. Recuperado de: https://www.sqa.org/
PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:
IACC (2015). Aseguramiento de la calidad del software (SQA). Modelos y Control de Calidad.
Semana 3.
23
24

03 Modelos y Control de Calidad PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

03 Modelos y Control de Calidad PDF

Uploaded by

Copyright:

Available Formats

MODELOS Y CONTROL DE CALIDAD

 Conocer los fundamentos básicos de métrica y su aplicación en el aseguramiento de la

El concepto de métrica resulta transversal a todo tipo de análisis de información,

1.1. CONCEPTOS BÁSICOS

Corresponde a una métrica o combinación de estas, cuyo valor proporciona un entendimiento

1.1.7. RANGO DE VALORES

Corresponde al valor definitivo de la medición de acuerdo al rango donde clasificó.

Entidad: análisis del producto de software

Facilidad de Se deben analizar las solicitudes Definición: Lo ideal es un valor

Tabla 1: Definición de una métrica

Figura 1: Mirada integrada métricas de software

2.1. CLASIFICACIÓN DE MÉTRICAS

2.1.1. MÉTRICAS DEL PRODUCTO

Por lo anterior, la definición de estas métricas en la ingeniería de software siempre tendrá

A través de esta métrica se busca valorar la calidad de la especificación de requerimientos, donde

Así por ejemplo, se puede evaluar lo siguiente:

Si para una especificación existen requerimientos, donde

corresponde al número de requerimientos funcionales

es el número de requerimientos donde los revisores concluyeron lo mismo respecto a su

Recuerde que un requerimiento es completo si en su definición están consideradas todas las

Así entonces, la completitud de los requerimientos puede evaluarse de acuerdo a la siguiente

2.1.1.2. MÉTRICAS PARA DISEÑO

Métrica Descripción Método de evaluación

2.1.1.3. MÉTRICAS DISEÑO WEBAPPS

a. Métricas de interfaz sugeridas

c. Métricas de contenido sugeridas

d. Métricas de navegación sugeridas

2.1.1.4. MÉTRICAS DEL CÓDIGO FUENTE

Líneas de código LOC

2.1.1.5. MÉTRICAS DE COMPLEJIDAD

A representa la cantidad de arcos de un grafo y N la cantidad de nodos. A mayor valor de V (G),

2.1.2. MÉTRICAS DEL PROCESO Y RECURSOS

2.1.2.1. MÉTRICAS DEL PROCESO

Desde el punto de vista organizacional, se pueden considerar algunos aspectos importantes en

 Motivación y habilidades de los miembros del equipo

Estos puntos influirán en el mejor desempeño deseado en el resultado. Además, se pueden

 Errores durante el desarrollo

2.1.2.2. MÉTRICAS DEL PROYECTO

 Evaluar y dar visibilidad del estado actual del proyecto

2.2.1. OBJETIVOS DE ALCANCE

2.2.2. MODO DE APLICACIÓN

2.2.2.1. MÉTRICAS DEL PROCESO

Establecer el equipo GQM

Selección de áreas de mejora

Crear el plan de proyecto

a. Resumen de la gestión, la cual presenta en forma bien resumida el plan de medición

 Definir los objetivos de medición

 Revisar o producir los modelos de proceso de software

Dado el carácter de un programa de medición, es necesario que existan procedimientos que

 Realización de entrevistas GQM

 Definir preguntas e hipótesis

 Revisión de preguntas e hipótesis

 Generación del plan GQM

Consolida el plan de medición (¿cómo se realizará?, ¿quién lo realizará?, ¿cómo se evaluará?,

 Elaboración del plan de medición

Corresponde a la definición de las tareas de medición, donde se identifica al responsable de

 Elaboración del plan de análisis

Documento donde se analiza la información provista respecto a preguntas y objetivos. En este

2.2.2.3. RECOPILACIÓN DE DATOS

 Preparación e inicio de la obtención de datos

Inicialmente se realizará una inducción o traspaso de conocimiento orientado a asegurar el

 Sistema de soporte a la medición

 Preparación de sesiones de retroalimentación