CAPITULO 5:

ASEGURAMIENTO DE
LA CALIDAD
5.6.5 RECOLECCIÓN DE MEDICIONES

5.6.5.1 DATOS DEL DEFECTO

5.6.5.2 CLASIFICACIÓN DEL DEFECTO

5.6.5.3 MEDICIONES DE NO-DEFECTOS

5.6.6 DEFINIR HERRAMIENTAS DE APOYO

5.6.7 IMPLEMENTAR EL ANÁLISIS DE DEFECTOS

5.6.8 EVALUACIÓN DE RESULTADOS

5.7 ASEGURAMIENTO DE CALIDAD EN EL DESARROLLO DEL SOFTWARE

2 5.6.5 RECOLECCIÓN DE MEDICIONES

• Una vez que se decidió qué métricas se usarán, el siguiente paso se centra en la
recolección de las mediciones necesarias, las cuales están asociadas a los datos del
defecto.
• Para esto, es necesario tener claro ciertos aspectos para realizar una completa y adecuada
recolección de mediciones
3 5.6.5.1 DATOS DEL DEFECTO

• Datos del defecto es otro tipo de información en "bruto", que es de importancia considerable en un
proyecto de desarrollo de software [JALT -2000]. Debido a que los defectos tienen directa relación
con la calidad del software, en cierto sentido se vuelve más importante este tipo de información que
los datos asociados al esfuerzo de desarrollo. Se define un defecto, como algo que es encontrado en
algún producto de trabajo del proyecto de desarrollo de software, y cuya presencia puede significar
efectos adversos al logro del objetivo del proyecto.
• La información de los defectos es necesaria, en primera instancia, para el nivel de gestión. Un
proyecto de software de gran escala puede incluir miles de defectos que son encontrados por diferentes
personas en diferentes etapas del proyecto. A menudo los procesos son tales, que la persona que repara
un defecto es distinta de aquella que lo descubrió o informó. Generalmente, en un proyecto de
desarrollo se quiere remover la mayoría o todos los defectos encontrados antes de que la entrega final
del software se realice.
4 5.6.5.1 DATOS DEL DEFECTO

• Una vez que el defecto ha sido registrado (y posteriormente cerrado), el análisis se puede enfocar
en tópicos tales como la cantidad de defectos que se han encontrado hasta el momento, el
porcentaje de defectos que aún sigue "abierto", y otros aspectos del proyecto. El monitoreo de
defectos es considerado una de las mejores prácticas para la gestión de un proyecto.
• No basta sólo con registrar los defectos para realizar un buen análisis. Para entender la capacidad
de calidad del proceso en uso, por ejemplo, defectos encontrados durante la fase de aceptación y
post entrega, necesitan ser separados de otro tipo de defectos. Para crear una línea base que
especifique qué porcentaje de los defectos son recogidos en una cierta etapa, y para comparar los
defectos encontrados versus los que se estimaron, es necesario registrar información de la fase u
etapa de desarrollo en la cual se encontró el defecto. En otras palabras, para cada defecto que se
registra, se debe entregar información relacionada a la fase en la cual se introdujo el defecto en el
sistema.
 • Toda la información de defectos asociada a un proyecto en particular debe ser debidamente
identificada y registrada.
5 • Para esto, y para realizar una clasificación a posteriori de los defectos, las características básicas
que se requieren para registrar un defecto son los que a continuación se especifican:
Dato Descripción
Código del proyecto Código o identificador del proyecto para el cual el defecto fue capturado.
Descripción Descripción del defecto
Ubicación Dónde el defecto fue encontrado (opcional)
Etapa del proceso de desarrollo del proyecto de software en la cual se detectó el
Etapa de detección defecto; típicamente es la etapa de revisión o de pruebas
Etapa en la cual se insertó/originó el defecto. Para esto se requiere análisis del defecto
Etapa de inserción
Tipo Clasificación del tipo de defecto (ver tabla 1.4)
Severidad Severidad del defecto
Forma en la cual la revisión está siendo realizada, esto es: por una persona o por un grupo
Tipo de revisión de revisión (opcional)
Estado Estado del defecto en algún punto del tiempo (abierto, cerrado, reparado)
Nombre de la persona que notificó el defecto, después de realizar la revisión o las
Reportado por (submitter) pruebas

Dato Descripción
Nombre de la persona que tendrá la responsabilidad de corregir el defecto (típicamente el
Asignado a (owner) autor del producto de trabajo en el cual el defecto fue encontrad o)
Fecha de envío Fecha en la cual el defecto fue enviado para corregirse
Fecha de cierre Fecha en la cual el defecto enviado se resolvió
6 5.6.5.2 CLASIFICACIÓN DE DEFECTOS

• Al contar con una clasificación de defectos se puede usar el dato asociado al defecto para guiar la
resolución de éste, identificar las debilidades del proceso de desarrollo de software o predecir a
futuro áreas problemas. Este es el enlace entre control de calidad (Quality Control, QC) -
encontrar y reparar defectos - y aseguramiento de calidad (Quality Assurance, QA) del software -
analizar el proceso de desarrollo de software.
• En ocasiones, es necesario entender la naturaleza de los defectos sin hacer referencia a la etapa en
la cual se detectaron, sino más bien, a una categoría de defectos. Tal clasificación puede ayudar a
entender la distribución de los defectos a través de diferentes categorías. Por esta razón, también es
necesario saber los tipos de defectos posibles. En la tabla 1.4 se dan algunos ejemplos de tipos de
defectos. Esta clasificación no es rígida, lo que significa que en cada proyecto se puede definir una
clasificación propia de defectos dependiendo del tipo de proyecto y análisis de defectos que se esté
llevando a cabo.
7 5.6.5.2 CLASIFICACIÓN DE DEFECTOS
Tipo de defecto Ejemplo de los defectos
Insuficiente / incorrectos errores en los algoritmos usados; condiciones erradas, casos de
Lógico prueba, o documentos de diseño.
Problemas con estándares de codificación / documentación, tales como: indentación,
alineación, disposición, modularidad, comentarios, codificación en sí, falta de ortografía
Estándares

Código redundante Un mismo pedazo de código que es usado en muchos, o en el mismo programa

Interfaz usuaria Funciones específicas de teclado que no funcionan; menú de navegación inadecuado
Pobre velocidad de procesamiento; falla del sistema provocada por el tamaño del archivo;
Performance problemas de memoria
Reusabilidad Incapacidad de reutilizar el código
Aspecto del diseño Aspectos relacionados específicamente al diseño del sistema
Defectos tales como: vaciado de memoria, desbordamiento de arreglos, funciones ilegales
Defectos en el manejo de la de llamadas al sistema, estancamiento del sistema, o desbordamiento de la memoria
memoria
Defectos encontrados mientras se revisaban documentos tales como: plan de proyecto,
Defectos en los plan de gestión de configuración, o especificación de requerimientos.
documentos
Actualización o eliminación de registros en un mismo orden, a través de todo el sistema
Consistencia
Trazabilidad Trazabilidad del programa fuente con la especificación de requerimientos
Portabilidad Que el código no sea independiente de la plataforma
 • Por último, la severidad del defecto es registrada. Este dato es importante para la gestión
del proyecto. Por ejemplo, si un defecto es muy severo, el jefe de proyecto podría
8 programarlo para ser corregido lo más luego posible. Un ejemplo de la clasificación de
los defectos según su severidad se muestra en la tabla 1.5.

Severidad Explicación para la categorización

El defecto puede ser muy crítico en términos de afectar a la programación, o ser un
Crítico obstáculo, es decir, dificulta que el usuario use el sistema posteriormente.

El mismo tipo de defecto ha ocurrido en muchos programas o módulos. Se necesita

corregir todo. Por ejemplo, estándares de codificación no son seguidos en ningún
Mayor programa. Alternativamente, el defecto impide que el usuario proceda de forma normal
en su trabajo.

Menor Este defecto está aislado o no impide que el usuario trabaje correctamente, pero causa
inconvenientes.
El defecto no afecta de ninguna forma el desempeño del producto de software. Por
ejemplo, aspectos estéticos y errores gramaticales en los mensajes.
Cosmético
9 5.6.5.3 MEDICIONES DE NO-DEFECTOS

• El análisis de defectos se basa en los datos que se obtienen a partir de un defecto; no obstante, esto
no es suficiente para la mayoría de las métricas. Los datos de los no defectos son usualmente la
base para las métricas de proceso y producto y, en algunos casos, forman la métrica.
• Algunas mediciones de no-defectos están definidas, y sus valores están en "bruto"; por ejemplo,
tamaño del proyecto, presupuesto y planificación, y el número de personas involucradas en una
actividad. Estas mediciones pueden ser obtenidas de forma directa, sin la necesidad de
interpretarlas.
• Para SQA, algunas mediciones no están disponibles en valores en "bruto", pero se basan en la
cuantificación de los datos subjetivos. Esas mediciones "suaves" pueden incluir aspectos como:
apreciaciones del cliente, calidad observada en una escala subjetiva y estimaciones de calidad.
Este tipo de mediciones deberían ser usadas con cuidado sobre todo porque no hay una forma
precisa de cuantificarlas o validarlas.
10 5.6.6 DEFINIR HERRAMIENTAS DE APOYO

• La representación de mediciones y métricas puede tomar muchas formas. Es necesario

definir y seleccionar qué herramientas de apoyo se utilizarán para el análisis de los datos.
A menudo estas se utilizan para la recolección de mediciones, métricas y medidas.
11 5.6.7 IMPLEMENTAR EL ANÁLISIS DE DEFECTOS

• La creación de un programa de métricas / mediciones se inicia con la determinación de

los requerimientos, es decir, conocer qué información se quiere. Después de esto, se
puede comenzar a definir las mediciones orientadas a conseguir el objetivo del proceso de
análisis de defectos.
• Debido a que no existe un consenso ni estandarización en lo que al uso e interpretación
de las métricas se refiere, ni una definición común ya aceptada de cada “error”, “línea de
código" - por nombrar algunos, ya que cada organización que mide o contabiliza algo lo
hace a su manera, es que lo más aconsejable es que cada organización diseñe su propio
programa de métricas / mediciones de acuerdo con su situación particular.
12 5.6.7 IMPLEMENTAR EL ANÁLISIS DE DEFECTOS

• Cuando la organización tiene un conjunto de métricas con información acerca del

proceso de software, puede ofrecer aquellas mediciones como guías a la industria
productora de software. En algún punto, otras organizaciones podrían adoptar y adaptar
las métricas propuestas, y así, la estandarización puede surgir. La IEEE ha publicado un
estándar que cubre el establecimiento de un programa de métricas (IEEE Standard 1061-
1992) lo que constituye un punto de partida para aquellas compañías que recién
comienzan a desarrollar su propio programa de métricas / mediciones.
13 5.6.7.1 REGLAS

Existen unas simples, pero importantes, reglas que deben seguirse en el diseño e
implementación del análisis de defectos y un programa de métricas / mediciones. Estas son:
• El programa debe ser promovido y apoyado desde los altos a los bajos niveles al interior
de la organización.
• Las métricas deben apoyar la calidad desde la perspectiva del cliente.
• Las mediciones no deben interferir con el correcto desempeño del trabajo asignado.
• La gente que es medida debe jugar un rol en la definición de las mediciones y métodos.
14 5.6.7.1 REGLAS

• Las métricas desarrolladas deben basarse en los defectos y otros datos que guíen a lograr una mejor
satisfacción del cliente. Si el programa de métricas planteado no provoca el aumento en la
satisfacción del cliente, los costos que esto implica se darán por desperdiciados. No obstante, no se
deben dejar de lado aquellas métricas y mediciones que promuevan el mejoramiento de la metodología
de trabajo utilizada al interior de la organización.
• Puede presentarse el caso de que, incluso si la alta gerencia de la organización apoya el análisis de
defectos o el programa de métricas / mediciones, si estas se obtienen durante el desempeño del trabajo
los funcionarios podrían no cooperar con esta actividad. Por consiguiente, las personas que conducen
la recolección de datos deben recordar que el resto de la gente está ocupada realizando su trabajo
diario. A ellos les pagan por su trabajo, no por las mediciones que se recolectarán. Por lo tanto, es
importante informar y hacer partícipe a cada miembro de la organización de las actividades de
medición que se llevarán a cabo, a fin de lograr que todos apoyen esta tarea.
15 5.6.7.2 DISEÑO DEL PLAN

El análisis de defectos o un plan de métricas deben ser tratado igual que el desarrollo de software. Es un
proyecto, tiene requerimientos, debe ser diseñado, "codificado", probado, implementado y mantenido. Un
enfoque simple de cinco pasos puede ser usado para definir y comenzar el plan:
• Definir los objetivos del plan: Esto es equivalente a establecer la misión y visón para la organización.
• Realizar preguntas acerca del uso del plan y métricas: Los objetivos del plan conducen a las preguntas
acerca de la actitud del cliente, calidad del producto, experiencia en los defectos, oportunidades de
mejoramiento del proceso, y similares.
• Identificar las métricas que serán desarrolladas y usadas: Las respuestas anteriores dan claridad y
conocimiento acerca del tipo de métricas que deben ser evaluadas. Como se está interesado en el análisis
de defectos, un conjunto particular de métricas surgirá para este efecto. Dependiendo del caso, la
organización deberá desarrollar estos pasos, dentro del contexto de su propia madurez, ámbito y
capacidades.
16 5.6.7.2 DISEÑO DEL PLAN

• Identificar las mediciones que deben realizarse, a modo de reunir los datos para las
métricas: La organización será la responsable de determinar los métodos de
cuantificación en el caso de que sean datos no cuantificables directamente ("suaves",
subjetivos o de apreciación personal).
• Planificar la recolección de datos, desarrollo y aplicación de las métricas
A través de todo el proceso es necesario involucrar a las personas cuyo trabajo y productos
serán objeto de medición. Ellas son las más cercanas a todas las cosas que están siendo
medidas, su esfuerzo, productos, procesos, defectos, entre otros, por lo que a menudo
pueden sugerir métricas y mediciones de mayor utilidad que las propuestas por la unidad de
SQA.
17 5.6.8 EVALUACIÓN DE RESULTADOS

• Después de la ejecución de cualquier plan de métricas o análisis de defectos es de vital

importancia evaluar los resultados obtenidos, de forma tal de apoyar la toma de
decisiones.
• Para esto, es de vital importancia contar con la información y herramientas necesarias. A
partir de los resultados generados en esta etapa, se determina si será necesario introducir
una mejora en el proceso / producto analizado.