CAPITULO 5:

ASEGURAMIENTO DE
LA CALIDAD
5.5 Funciones Generales del SQA
5.6 Análisis de efectos
2 5.5 FUNCIONES GENERALES DEL SQA

Describir los diferentes roles que puede jugar el equipo de SQA en una organización nos dará una visión clara de las
funciones que puede llevar a cabo.
“Como policía del proceso”: el trabajo del equipo de SQA es asegurar que el desarrollo sigue el proceso establecido.
Entre sus funciones en este rol se encuentran:
• Auditar los productos del trabajo para identificar deficiencias.
• Determinar el cumplimiento del plan de desarrollo del proyecto y del proceso de desarrollo de software.
• Juzgar el proceso y no el producto.

“Como abogado del cliente”: el trabajo del equipo de SQA es representar al cliente. Entre sus funciones en este rol se
encuentran:
• Identificar la funcionalidad que al cliente le gustaría encontrar.
• Ayudar a la organización a sensibilizarse con las necesidades del cliente.
• Actuar como un cliente de prueba para obtener una alta satisfacción del cliente.
3 5.5 FUNCIONES GENERALES DEL SQA

“Como analista” el trabajo del equipo de SQA es recabar información. Entre sus funciones en este rol se
encuentran:
• Juntar muchos datos sobre todos los aspectos del producto y del proceso.
• Con esta información ayudar a mejorar los procesos y los productos.

“Como proveedor de información” el trabajo del equipo de SQA es revisar qué es lo que esté hecho y decir
cuáles objetivos técnicos realmente están cumplidos para que la gerencia pueda tomar mejores decisiones
de negocios. Entre sus funciones en este rol se encuentran:
• Proveer información técnica objetiva para que la gerencia pueda usarla para tomar mejores decisiones.
• Proveer información apropiada de las clases de productos y de los riesgos asociados con estos.
• Concentrarse más en la reducción de los riesgos que en el cumplimiento del proceso.
4 5.5 FUNCIONES GENERALES DEL SQA

“Como responsable de la elaboración del proceso” el trabajo del equipo de SQA es

participar en la definición de los planes, procesos, estándares y procedimientos para
asegurar que se ajustan a las necesidades del proyecto y que pueden ser usados para realizar
las evaluaciones de QA y cumplir los requerimientos del proyecto y las políticas de la
organización. Para cumplir este rol el aseguramiento de la calidad debería comenzar en las
fases tempranas del proyecto.
5 5.6 ANÁLISIS DE DEFECTOS

• No es una mera suposición decir que los defectos ocurren a lo largo de todo el ciclo de
vida del software y sin previo aviso, por lo que se hace necesario dedicar tiempo y
esfuerzo en su detección y corrección. No obstante, es también importante la prevención
de defectos, la cual sólo podrá llevarse a cabo una vez que se realice un registro y
seguimiento de todos los defectos que se han presentado, para poder realizar su posterior
análisis, y así corregir las deficiencias actuales en el proceso / producto de desarrollo de
software y evitar situaciones similares en futuros proyectos.
• Como los defectos son detectados y eliminados (caso ideal), se puede acumular una gran
cantidad de datos acerca de ellos. Estos datos son la entrada para el análisis del actual
proceso de desarrollo y sus potenciales debilidades, tarea que debe ser asumida por el
área de aseguramiento de calidad (QA) de la organización.
6 5.6 ANÁLISIS DE DEFECTOS

• Un historial acumulativo de defectos puede indicar dónde será efectivo aplicar modificaciones al proceso
de desarrollo del software, así como la relación causa-efecto de los defectos encontrados en los productos
pueden determinar posibles pautas que guíen la mejora del proceso de desarrollo.
• Defectos
• “Un defecto es cualquier característica involuntaria que deteriora la utilidad o valor de un ítem, o
cualquier tipo de defecto, imperfección o deficiencia”. Entonces se puede definir un defecto de software
como un defecto o imperfección en un producto o proceso de software. Esta es la definición con la cual se
trabajará en el resto de este trabajo.
• Un producto de software es cualquier artefacto creado como parte del proceso de software incluyendo
programas de computación, procedimientos, documentación y datos asociados. Un proceso de software es
un conjunto de actividades, métodos, prácticas y transformaciones que se usa para desarrollar y mantener
productos de software.
7 5.6.1 CONCEPTOS DEL ANÁLISIS

• El análisis de defectos es la disciplina que mide el desarrollo de software y su uso. Las mediciones
pueden provenir de diversas fuentes tales como: encuestas, calendarización, datos del defecto,
registros y planes de presupuesto, características del sistema, entre otros. Depende de cada
organización descubrir y determinar las fuentes de medición que mejor satisfacen sus necesidades,
según la situación en la que se encuentren.
• Las Métricas son una parte esencial de cualquier sistema de calidad de software, y representan la
relación entre los datos medidos que se convierten en información aplicable para la gestión de
calidad. Si n embargo, a menudo las métricas no representan más que un ejercicio de recolectar
números sin entregar información útil. El rol de la unidad de SQA, será entonces, proveer
información que apoye la toma de decisiones, que de capacidad de acción a nivel de gestión, de
forma de beneficiar y mejorar el proceso de desarrollo de software; las métricas pueden hacer esto,
pero son solamente útiles cuando contribuyen a dar información base.
8 5.6.1.1 MEDICIONES (MEASURES)

• "No puedes controlar lo que no puedes medir", DeMarc o, 1982 [FEPF -1997]
• Un número, por ejemplo, no es una métrica. Es sólo un valor que no aporta información
alguna. En cambio, si se le agrega una dimensión a ese número, por ejemplo, líneas de
código, se ha creado una unidad de medida. Ahora bien 6.000 LOC sigue siendo una
medida pues aún no entrega información alguna.
9 5.6.1.2 MÉTRICAS

• Una métrica está definida como la razón de, o la relación entre dos mediciones. Es una
medición propuesta, que sólo cuando realmente caracteriza a un atributo, se le puede llamar
una medición de este, y una vez que se obtiene información de ella, pasa a ser una métrica.
Así, por ejemplo, una densidad de 6 defectos por 1.000 LOC comienza recién a alcanzar un
estado de información.
• Las métricas de defectos son aquellas que están compuestas de mediciones relacionadas con
defectos. Las mediciones pueden incluir el número de fallas del sistema, llamadas de ayuda
hechas en línea, tiempo gastado en grabar después de la falla, y disminución de las ventas
debido a la insatisfacción de muchos clientes. Una típica métrica de defectos es el número
de informes de problemas cerrados versus el número de nuevos informes de problemas
registrados.
10 5.6.1.3 ANÁLISIS DEL PRODUCTO

• El producto es la primera área donde la mayoría de las organizaciones comienzan a medir.

Frecuencia de error, tamaño del producto de software, costo de desarrollo, número de pruebas
ejecutadas exitosamente, y otras similares, son a menudo los aspectos medidos en un comienzo. La
mayoría de estas métricas de producto pueden ser recolectadas directamente del Informe de
Problemas (IP) (Trouble Reports -TR) y de la documentación asociada al proyecto. Las métricas del
producto se basan en los atributos de este, las características de los defectos y cualquier otro dato con
respecto al producto.
• Usando métricas del producto, la unidad de SQA puede localizar áreas propensas de error en código,
debilidades en el diseño, defectos de las pruebas y así sucesivamente. Las métricas del producto
también ayudan a SQA a identificar los esfuerzos que pueden afectar de forma beneficiosa el análisis
de un producto en particular. A largo plazo, al analizar el producto se acumulará una cantidad de
información suficiente, la que podrá ser aplicada también en los análisis orientados al proceso.
11 5.6.1.4 ANÁLISIS DE PROCESOS

• Es deber de SQA mejorar el proceso por el cual se desarrollan los productos de software.
El entendimiento y mejoramiento del proceso depende fuertemente del resultado del
análisis del producto desarrollado su historial de defectos y cambios de los que fue
objeto, por ejemplo: Por sí mismo, el registro y análisis de los datos de los defectos y no
defectos, para un único producto, no es especialmente útil en un proceso básico (process
basic). Es el análisis continuo de los datos en múltiples productos lo que guía hacia la
obtención de información que describe un proceso; es aquí donde la unidad de SQA
puede comenzar a describir el proceso y su comportamiento.
12 5.6.1.4 ANÁLISIS DE PROCESOS

• El análisis de las metodologías de detección de defectos y sus resultados pueden entregar

un conocimiento más certero del valor de esta información. Comparando cuándo y cómo
se detectan los defectos, versus cuándo fueron introducidos, es posible obtener una visión
global del proceso.
• El análisis de los defectos tipos que se detectan provee de la información necesaria para
profundizar en las fortalezas y debilidades del proceso de desarrollo de software. Así, una
vez que se entiende el comportamiento del proceso, las modificaciones intencionales que
se le hagan se convertirán en cambios identificables en los productos de desarrollo. De
esa forma la unidad de SQA será capaz de sugerir cambios beneficiosos al proceso en
análisis, respaldado en datos e información, más que en suposiciones
13 5.6.2 LOCALIZACIÓN DE DATOS

• Una tarea que se hace imprescindible si se quiere generar métricas, es la recolección de

datos en forma de mediciones. Estos datos son obtenidos fácilmente de distintas fuentes,
tal como presupuesto e informes de planificación, informes de problemas, entre otros.
14 5.6.2.1 INFORMANDO LOS DEFECTOS

• Cuando las organizaciones desarrolladoras de software son pequeñas, no existe una metodología
formal que indique los pasos a seguir para reportar un defecto. A medida que las organizaciones
crecen su complejidad aumenta y, por consecuencia, la de los defectos que se detectan. De esta
forma cobra relevancia el método que se utilice para recolectar la información de los defectos,
pues mientras más datos se tengan con respecto a un defecto en particular, más fácil será la tarea
de corregirlo.
• Es importante notar que el IP es un informe que combina los defectos, tanto de los documentos
como del software. Mientras las organizaciones mantengan un mismo sistema para el
procesamiento de defectos, tanto de documentos como de software, se elimina la duplicación de
esfuerzos. "Más aún, al almacenar todos los defectos que se detectan en una misma base de datos,
se hace más fácil el registro, seguimiento, monitoreo y análisis de las tendencias de estos".
15 5.6.2.1 INFORMANDO LOS DEFECTOS

• Como herramienta para informar defectos de software, el IPS incluye datos que deben ser
entregados por el iniciador (debe ser alguien involucrado con el software a través de su
ciclo de vida) y el corrector. También pregunta por información que crea diversos tipos de
clasificación tales como la prioridad de la corrección, criticalidad del defecto y la fuente
original del defecto (error de código, deficiencia de los requerimientos, entre otros). Tal
información puede ser analizada y relacionada posteriormente, y a menudo sirve para
acentuar los aspectos débiles del proceso de desarrollo de software que debe ser objeto de
preocupación por parte de la gestión. Tales relaciones pueden indicar también, al
comienzo de nuevos proyectos, áreas propensas a problemas, las que deberían ser
asignadas a personal con más experiencia, ser objetivo de controles estrictos, o estar bajo
revisiones y pruebas más frecuentes durante el proceso de desarrollo.
16 5.6.3 REPARACIÓN Y CIERRE DE DEFECTOS

• Un aspecto importante del Informe de Problemas (IP), independiente de la forma en que

sea implementado, es que provee un mecanismo para asegurar que cada defecto fue
notificado y encaminado y la solución fue registrada. Para el cierre de un IPS se debe
seguir un procedimiento preestablecido, para evitar que los defectos que son detectados,
pero no resueltos, vuelvan a presentarse y causen daños o costos no esperados. La unidad
de SQA tiene la responsabilidad de monitorear todos los IP abiertos e informar al área de
gestión del estado de éstos. De esta forma, será menos probable que un defecto no sea
notado y se pierda. También debe realizarse un chequeo con los desarrolladores para
asegurar que ellos no están dejando de lado defectos en favor de considerarlos en una
actividad posterior del desarrollo.
17 5.6.3 REPARACIÓN Y CIERRE DE DEFECTOS

• El IP no se considera cerrado hasta que esa sección ha sido completada. Los defectos pueden perderse en el sistema si
no son monitoreados hasta su cierre y reportados como tal. Cada organización debe definir los estándares que regulen
el seguimiento y monitoreo de los defectos. Por ejemplo, uno de esos estándares debería especificar el lapso durante el
cual un defecto puede permanecer sin ser tratado, sin perjuicio de la siguiente actividad.
• Cada informe de problemas, para cada producto y/o proceso en general, debe proporcionar una referencia futura para el
registro formal del problema (que derivó en un defecto) y la decisión que determinó su resolución. En algunas
organizaciones existen informes por separado para lo que es la decisión de una corrección o cambio de un defecto. Un
formulario para registrar los cambios es la Petición de Cambio del Software, el cual puede ser usado por separado al IP
si se requiere implementar un cambio formalmente. De esta forma, al cerrar un defecto, se tiene un rastro completo del
tratamiento del cual fue objeto.
• El cierre de un IP usualmente describe las acciones llevadas a cabo para corregir el defecto que provocó el problema. No
obstante, no todos los informes de problemas están correctos del todo. Pueden ocurrir situaciones en donde lo que se
piensa que es un defecto, en realidad no lo es. Sin embargo, el IP existe, y a pesar de que no se realiza ningún cambio ni
modificación, el informe debe ser formalmente cerrado.
18 5.6.4 SELECCIÓN DE MÉTRICAS
5.6.4.1 MÉTRICAS DISPONIBLES
• No sólo porque una organización utilice ciertas métricas implica que estas mismas servirán en otra
organización. Dependerá del tipo de organización el tipo de métrica que le será de utilidad. Además,
las organizaciones sólo comenzarán a desarrollar métricas cuando sean capaces de monitorear y cerrar
informes de problemas. Probablemente no se usarán métricas para intentar expresar la validez del
algoritmo de estimación de un sistema desarrollado hasta que la organización haya estado usando
métricas durante un cierto tiempo.
• La selección de métricas específicas para desarrollar está en directa relación con los objetivos de
calidad que se han definido, tanto para un producto como para un proceso. Esto no significa que
existen métricas específicas que ciertas organizaciones deberían usar, sino que lo que se pretende en
este documento, es dar algunos ejemplos de métricas que han sido útiles en algunas organizaciones.
Las métricas que se describen a continuación intentan dar ideas a los participantes del análisis de
defectos, acerca de qué métricas se usan y qué preguntas se deben realizar para determinarlas
19 5.6.4.2 MÉTRICAS APLICABLES

La mayoría de las métricas existentes son orientadas al proceso o al producto.

a) Métricas orientadas al producto.- Para SQA es de especial relevancia el conocimiento
adquirido con los defectos encontrados en el producto actual de desarrollo de software,
así como en los proyectos pasados. Para un producto de software dado, con la
experiencia adquirida anteriormente, se puede indicar si el avance del sistema apunta
hacia la preparación de la implementación de este. Algunas métricas pueden dar las
pautas para identificar los módulos o subsistemas propensos a error. Otras métricas
indican la reducción en la detección de defectos como los defectos que son encontrados
y removidos.
20 5.6.4.2 MÉTRICAS APLICABLES

b) Métricas orientadas al proceso

Las métricas de productividad entregan indicadores de la efectividad del proceso, calidad de las
técnicas de estimación, calidad de las técnicas de detección de defectos y similares. Algunas están
basadas en defectos y otras no.
Para determinar cómo un proceso se está comportando se puede realizar un análisis de tendencia a
largo plazo por medio de la comparación de las mediciones y métricas que se obtienen. Procesos de
control estadísticos, razón de la detección de error, salida en cierto plazo, costo de calidad, y uso de
ayuda en línea, son todos ejemplos de m ediciones y métricas que pueden ser estudiadas en un período
de tiempo. El uso de mapas de control de procesos para el software puede ayudar a describir de mejor
forma el comportamiento del proceso de desarrollo y, a su vez, identificar el comportamiento de los
cambios en éste, como respuesta a las variaciones intencionales aplicadas al proceso.
21 5.6.4.2 MÉTRICAS APLICABLES

c) Costo de calidad
El costo de calidad (Cost of Quality, CQ) es usado a menudo para medir el valor de la calidad del sistema en
desarrollo. Combinando el costo de los recursos utilizados para prevenir la ocurrencia de errores, y la evaluación de
la calidad de un producto, se puede definir el costo de alcanzar calidad (COA). Este valor se agrega a los costos de
los recursos utilizados debido a que la calidad no fue lograda, es decir, el costo de falla (Cost of Fail, COF).
Entonces, la suma de COA+COF determina el costo de calidad.
Los costos de prevención consideran aspectos como entrenamiento, adquisición de una metodología y de
herramientas automatizadas, planificación, especificación de estándares, entre otros. Estos son los costos en los que
se debe incurrir para reducir la probabilidad de cometer un error desde el principio del proceso de desarrollo.
Cuando un producto manifiesta un error se incurre en costos de falla. Es importante reconocer que sólo la primera
revisión o prueba de un producto se considera como costo de evaluación. El costo de falla (failure) incluye el costo
de re-trabajo, sanciones, sobretiempo, re-ejecución de las aplicaciones que fallan en producción, pleitos legales, y
varios otros costos.
22 5.6.4.3 MÉTRICAS ORIENTADAS A LAS METAS
EN EL DESARROLLO DE SOFTWARE DE CALIDAD
(SQS)
• Es importante entender tanto los objetivos de la organización, como del sistema de calidad en desarrollo,
antes de escoger y aplicar las métricas. Los tipos de métricas que se plantean son consideradas
razonables para una organización que recién comienza a usar métricas en el desarrollo de SQS. Como
cada organización crece en experiencia a medida que desarrolla software de calidad, las metas, preguntas
y métricas adicionales o más avanzadas pueden llegar a ser útiles en el transcurso del proceso de
desarrollo software de calidad que aplique una organización.
• En la tabla 1.2 se sugieren metas posibles para el desarrollo de software de calidad, y métricas
representativas para alcanzar dichas metas. No obstante, ninguna de estas métricas es para ser
interpretada, usada o requerida por todas las organizaciones. Ningún texto de métricas podría cubrir el
amplio rango de posibles métricas para desarrollar software de calidad, ni el amplio espectro de
organizaciones existentes. Lo que se propone aquí es sólo las métricas típicas, para que cualquier
organización pueda comenzar y encaminarse de forma apropiada en el desarrollo de software de calidad.