LABORATORIO N° 14

Escuela Profesional: Ingeniería de Sistemas. Asignatura: Ingeniería Software.

Ciclo y Turno: Septimo -Noche Semestre Académico: 2021
Docente: Ing. Frank Huamanchumo C. Fecha: Diciembre 2021

Sesión 14: Métricas medidas e indicadores

INTRODUCCION
El desarrollo de sistemas hoy en día ha tomado gran importancia en el mundo. Aunque esta importancia tienda a aumentar, no todo
tiene una buena perspectiva, existen inconvenientes en el desarrollo de los sistemas grandes retrasos en la programación,
inconsistencia en su funcionamiento, etc.; pero lo más importante es la falta de calidad, punto de gran interés e importancia para el
logro de eficiencia y productividad de los sistemas.

Es claro que si un sistema presenta errores al momento de ser utilizado, ese producto pierde confiabilidad a los ojos del usuario hasta
el nivel que podría ser desechado como un producto defectuoso. Por esta razón los proyectos de sistemas presentan fallas que impiden
que el sistema funcione como era de esperarse o que sea utilizado en su totalidad. Por ello, es necesario definir e impulsar líneas de
acción tendientes a mejorar el sistema producido. Dentro de estas líneas de acción está la relacionada con el proceso mismo del
desarrollo del sistema, y como necesidad primordial, la de realizar una investigación que permita conocer de primera mano el estado
en que se encuentra su proceso de desarrollo.
.
I. OBJETIVOS
Conocer las metricas e indicadores en el software

II. EQUIPOS Y MATERIALES

 Computadora personal.
 Programa Racional Rose correctamente instalado
 Cuaderno de clases, donde están los modelos resueltos en clase

III. METODOLOGIA Y ACTIVIDADES

a) Diseño de los ejercicios desarrollados en el aula.

b) Presentar avances y ejecución de cada uno de los ejercicios al docente o jefe de práctica encargado para la
calificación correspondiente.
c) Guardar la carpeta de sus archivos a sus memorias.
d) Apagar el computador y dejarla en buen estado al retirarse del laboratorio dejar todo en orden.

IV. IMPORTANTE

Importancia de las metricas e indicadores de software.

V. MANEJO DEL SOFTWARE

Métricas en el Desarrollo de Software

TEMA

Las Métricas y la Calidad de Software

OBJETIVOS ESPECÍFICOS
 Definir la importancia de contar con métricas de software para el aseguramiento
 de la calidad del producto software
 Presentar modelos de calidad de software con mediciones de métricas de
atributos internos y externos del producto software

CONTENIDOS
 Introducción
 Visión General de los Factores que Afectan la Calidad
 Medida de la Calidad
 Factores de Calidad de McCall
 FURPS
 Métricas del Modelo de Análisis
 Métricas del Modelo de Diseño
 Métricas del Diseño de Interfaz
 Métricas del Código Fuente
 Métricas para Pruebas
 Métricas para Mantenimiento

ACTIVIDADES
 Aplicar las métricas de McCall, identificando los factores de calidad, al poryecto
de su curso de Diseño de Aplicaciones Web
1. INTRODUCCION
El objetivo primordial de la ingeniería del software es producir un
sistema, aplicación o producto de alta calidad. Para lograr este
objetivo, los ingenieros de software deben emplear métodos
efectivos junto con herramientas modernas dentro del contexto de
un proceso maduro de desarrollo del software. Al mismo tiempo,
un buen ingeniero del software y buenos administradores de la
ingeniería del software deben medir si la alta calidad se va a llevar
a cabo. A continuación se verá un conjunto de métricas del
software que pueden emplearse a la valoración cuantitativa de la
calidad de software.

El punto de vista de ¿Qué es calidad? Es diverso, y por lo tanto

existen distintas respuestas, tales como se muestra a
continuación:

El American Heritage Dictionary [Pressman ´98] define la calidad

como “Una característica o atributo de algo.”

La definición estándar de calidad en ISO-8402 es “La totalidad de

rasgos y características de un producto, proceso o servicio que
sostiene la habilidad de satisfacer estados o necesidades
implícitas” [Mcdermid ’91].

“Concordar explícitamente al estado funcional y a los

requerimientos del funcionamiento, explícitamente a los
estándares de documentación de desarrollo, e implícitamente
características que son expectativas de todos los desarrolladores
profesionales de software” [Pressman ’93].

La calidad de un sistema, aplicación o producto es tan buena

como los requisitos que detallan el problema, el diseño que
modela la solución, el código que transfiere a un programa
ejecutable y las pruebas que ejercita el software para detectar
errores. Un buen ingeniero del software emplea mediciones que
evalúan la calidad del análisis y los modelos de diseño, así como
el código fuente y los casos de prueba que se han establecido al
aplicar la ingeniería del software. Para obtener esta evaluación de
calidad, el ingeniero debe utilizar medidas técnicas, que evalúan la
calidad con objetividad, no con subjetividad. Asimismo, un buen
administrador de proyectos debe evaluar la calidad objetivamente
y no subjetivamente. A medida que el proyecto progresa el
administrador del proyecto siempre debe valorar la calidad.
 Aunque se pueden recopilar muchas medidas de calidad, el primer
objetivo en el proyecto es medir errores y defectos. Las métricas
que provienen de estas medidas proporcionan una indicación de la
efectividad de las actividades de control y de la garantía de calidad
en grupos o en particulares.

Por ejemplo los errores detectados por hora de revisión y los

errores detectados por hora de prueba suministran una visión
profunda de la eficacia de cada una de las actividades envueltas
en la métrica. Así los datos de errores se pueden utilizar también
para calcular la eficiencia de eliminación de defectos en cada una
de las actividades del marco de trabajo del proceso.

2. VISION GENERAL DE LOS FACTORES QUE AFECTAN LA CALIDAD

McCall y Cavano [John A. McDermid ‘91] definieron un juego de
factores de calidad como los primeros pasos hacia el desarrollo de
métricas de la calidad del software. Estos factores evalúan el
software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión del producto (cambiándolo)
y (3) transición del producto (modificándolo para que funcione en un entorno
diferente, por ejemplo: “portándolo”) Los autores describen la relación entre
estos
 factores de calidad (lo que llaman un ‘marco de trabajo’) y otros
aspectos del proceso de ingeniería del software:

En primer lugar el marco de trabajo proporciona al administrador

identificar en el proyecto lo que considera importante, como:
facilidad de mantenimiento y transportabilidad, atributos del
software, además de su corrección y rendimiento funcional
teniendo un impacto significativo en el costo del ciclo de vida. En
segundo lugar, proporciona un medio de evaluar cuantitativamente
el progreso en el desarrollo de software teniendo relación con los
objetivos de calidad establecidos. En tercer lugar, proporciona
más interacción del personal de calidad, en el esfuerzo de
desarrollo. Por último, el personal de calidad puede utilizar
indicaciones de calidad que se establecieron como ”pobres” para
ayudar a identificar estándares “mejores” para verificar en el
futuro.

Es importante destacar que casi todos los aspectos del cálculo

han sufrido cambios radicales con el paso de los años desde que
McCall y Cavano hicieron su trabajo, teniendo gran influencia, en
1978. Pero los atributos que proporcionan una indicación de la
calidad del software siguen siendo los mismos. Si una
organización de software adopta un juego de factores de calidad
como una “lista de comprobación” para evaluar la calidad del
software, es probable que el software construido hoy siga
exhibiendo la buena calidad dentro de las primeras décadas del
siglo XXI. Incluso, cuando las arquitecturas del cálculo sufran
cambios radicales (como seguramente ocurrirá), el software que
exhibe alta calidad en operación, transición y revisión continuará
sirviendo a sus usuarios.

3. MEDIDA DE LA CALIDAD
Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de
mantenimiento, integridad y facilidad de uso suministran indicadores útiles para el
equipo del proyecto. Gilb [Len O. Ejiogo ‘90] sugiere definiciones y medidas para cada
uno de ellos, tales como:

Corrección: A un programa le corresponde operar correctamente

o suministrará poco valor a sus usuarios. La corrección es el grado
en el que el software lleva a cabo una función requerida. La
medida más común de corrección son los defectos por KLDC, en
donde un defecto se define como una falla verificada de
conformidad con los requisitos.

Facilidad de mantenimiento. El mantenimiento del software

cuenta con más esfuerzo que cualquier otra actividad de ingeniería
del software. La facilidad de mantenimiento es la habilidad con la
que se puede corregir un programa si se encuentra un error, se
puede adaptar si su entorno cambia o optimizar si el cliente desea
un cambio de requisitos. No hay forma de medir directamente la
facilidad de mantenimiento; por consiguiente, se deben utilizar
medidas indirectas. Una métrica orientada al tiempo simple es el
tiempo medio de cambio (TMC), es decir, el tiempo que se tarda
en analizar la petición de cambio, en diseñar una modificación
apropiada, en efectuar el cambio, en probarlo y en distribuir el
cambio a todos los usuarios. En promedio, los programas que son
más fáciles de mantener tendrán un TMC más bajo (para tipos
equivalentes de cambios) que los programas que son más difíciles
de mantener.
Hitachi ha empleado una métrica orientada al costo (precio) para
la capacidad de mantenimiento, llamada “desperdicios”. El costo
estará en corregir defectos hallados después de haber distribuido
el software a sus usuarios finales.

Cuando la proporción de desperdicios en el costo global del

proyecto se simboliza como una función del tiempo, es aquí donde
el administrador logra
determinar si la facilidad de mantenimiento del software producido
por una organización de desarrollo está mejorando y asimismo se
pueden emprender acciones a partir de las conclusiones obtenidas
de esa información.

Integridad. En esta época de intrusos informáticos y de virus, la

integridad del software ha llegado a tener mucha importancia. Este
atributo mide la habilidad de un sistema para soportar ataques
(tanto accidentales como intencionados) contra su seguridad. El
ataque se puede ejecutar en cualquiera de los tres componentes
del software, ya sea en los programas, datos o documentos.

Para medir la integridad, se tienen que definir dos atributos

adicionales: amenaza y seguridad. La amenaza es la probabilidad
(que se logra evaluar o concluir de la videncia empírica) de que un
ataque de un tipo establecido ocurra en un tiempo establecido. La
seguridad es la probabilidad (que se puede estimar o deducir de la
evidencia empírica) de que se pueda repeler el ataque de un tipo
establecido, en donde la integridad del sistema se puede
especificar como:

integridad = [1- amenaza x (1- seguridad)] (4.1)

donde se suman la amenaza y la seguridad para cada tipo de ataque.

Facilidad de uso. El calificativo “amigable con el usuario” se ha

transformado universalmente en disputas sobre productos de
software. Si un programa no es “amigable con el usuario”,
prácticamente está próximo al fracaso, incluso aunque las
funciones que realice sean valiosas. La facilidad de uso es un
intento de cuantificar “lo amigable que pude ser con el usuario” y
se consigue medir en función de cuatro características: (1)
destreza intelectual y/o física solicitada para aprender el sistema;
(2) el tiempo requerido para alcanzar a ser moderadamente
eficiente en el uso del sistema; (3) aumento neto en productividad
(sobre el enfoque que el sistema reemplaza) medida cuando
alguien emplea el sistema moderadamente y eficientemente, y (4)
valoración subjetiva (a veces obtenida mediante un cuestionario)
de la disposición de los usuarios hacia el sistema. Los cuatro
factores anteriores son sólo un ejemplo de todos los que se han
propuesto como medidas de la calidad del software.
Medidas de Fiabilidad y de Disponibilidad
Los trabajos iniciales sobre fiabilidad buscaron extrapolar las
matemáticas de la teoría de fiabilidad del hardware a la
predicción de la fiabilidad del software.

La mayoría de los modelos de fiabilidad relativos al

hardware van más orientados a los fallos debidos al
desajuste, que a los fallos debidos a defectos de diseño, ya
que son más probables debido al desgaste físico (p.ej.: el
efecto de la temperatura, del deterioro, y los golpes) que los
fallos relativos al diseño.
Desgraciadamente, para el software lo que ocurre es lo
contrario. De hecho, todos los fallos del software, se
producen por problemas de diseño o de implementación.
Considerando un sistema basado en computadora, una
medida sencilla de la fiabilidad es el tiempo medio entre
fallos (TMEF) [Mayrhauser´91], donde:

TMEF = TMDF+TMDR (4.2)

(TMDF (tiempo medio de fallo) y TMDR (tiempo medio de reparación)).

 Muchos investigadores argumentan que el TMDF es con
mucho, una medida más útil que los defectos/KLDC,
simplemente porque el usuario final se enfrenta a los fallos,
no al número total de errores. Como cada error de un
programa no tiene la misma tasa de fallo, la cuenta total de
errores no es una buena indicación de la fiabilidad de un
sistema. Por ejemplo, consideremos un programa que ha
estado funcionando durante
14 meses. Muchos de los errores del programa pueden
pasar desapercibidos durante décadas antes de que se
detecten. El TMEF de esos errores puede ser de 50 e
incluso de 100 años. Otros errores, aunque no se hayan
descubierto aún, pueden tener una tasa de fallo de
18 ó 24 meses, incluso aunque se eliminen todos los errores
de la primera categoría (los que tienen un gran TMEF), el
impacto sobre la fiabilidad del software será muy escaso.

Además de una medida de la fiabilidad debemos obtener

una medida de la
disponibilidad. La disponibilidad del software es la
probabilidad de que un programa funcione de acuerdo con
los requisitos en un momento dado, y se define como:

Disponibilidad = TMDF/(TMDF + TMDR) x 100 % (4.3)

La medida de fiabilidad TMEF es igualmente sensible al

TMDF que al TMDR. La medida de disponibilidad es algo
más sensible al TMDR ya que es una medida indirecta de la
facilidad de mantenimiento del software.

Eficacia de la Eliminació n de Defectos

Una métrica de la calidad que proporciona beneficios tanto a
nivel del proyecto como del proceso, es la eficacia de la
eliminación de defectos (EED) En particular el EED es una
medida de la habilidad de filtrar las actividades de la
garantía de calidad y de control al aplicarse a todas las
actividades del marco de trabajo del proceso.

Cuando se toma en consideración globalmente para un

proyecto, EED se define de la forma siguiente:

EED = E / (E + D) (4.4)
donde E= es el número de errores encontrados antes de la
entrega del software al usuario final y D= es el número de
defectos encontrados después de la entrega.

El valor ideal de EED es 1, donde simbolizando que no se

han encontrado defectos en el software. De forma realista, D
será mayor que cero, pero el valor de EED todavía se puede
aproximar a 1 cuando E aumenta. En consecuencia cuando
E aumenta es probable que el valor final de D disminuya (los
errores se filtran antes de que se conviertan en defectos) Si
se utiliza como una métrica que suministra un indicador de
la destreza de filtrar las actividades de la garantía de la
calidad y el control, el EED alienta a que el equipo del
proyecto de software instituya técnicas para encontrar los
errores posibles antes de su entrega.

Del mismo modo el EED se puede manipular dentro del

proyecto, para evaluar la habilidad de un equipo en
encontrar errores antes de que
 pasen a la siguiente actividad, estructura o tarea de
ingeniería del software. Por ejemplo, la tarea de análisis de
requerimientos produce un modelo de análisis qué se puede
inspeccionar para encontrar y corregir errores. Esos errores
que no se encuentren durante la revisión del modelo de
análisis se pasan a las tareas de diseño (en donde se puede
encontrar o no) Cuando se utilizan en este contexto, el EED
se vuelve a definir como:

EED = Ei / ( Ei + Ei+1) (4.5)

Donde Ei = es el número de errores encontrados durante la
actividad iesima de: ingeniería del software i, el Ei + 1 = es
el número de errores encontrado durante la actividad de
ingeniería del software (i + 1) que se puede seguir para
llegar a errores que no se detectaron en la actividad i.

Un objetivo de calidad de un equipo de ingeniería de

software es alcanzar un EED que se aproxime a 1, esto es,
los errores se deberían filtrar antes de pasarse a la actividad
siguiente. Esto también puede ser utilizado dentro del
proyecto para evaluar la habilidad de un equipo, esto con el
objetivo de encontrar deficiencias que harán que se atrase el
proyecto.

Existen varias métricas de calidad, pero las más importantes

y que engloban a las demás, son sólo cuatro: corrección,
facilidad de mantenimiento, integridad y facilidad de uso, se
explican en la siguiente sección.

4. FACTORES DE CALIDAD DE McCALL

Los factores que perturban la calidad del software se pueden
categorizar en dos grandes grupos: (1) factores que se pueden
medir directamente (por ejemplo: defectos por puntos de función)
y (2) factores que se pueden medir sólo indirectamente (por
ejemplo: facilidad de uso o de mantenimiento).
McCall y sus colegas plantearon una categorización de factores
que afectan a la calidad de software, que se muestran en la figura
4.1 en donde se centralizan con tres aspectos importantes de un
producto de software: sus características operativas, su capacidad
de cambio y su adaptabilidad a nuevos entornos.

Refiriéndose a los factores, McCall proporciona las siguientes

descripciones: [Pressman ’98].

1. Corrección:
Hasta dónde satisface un programa su especificación y
consigue los objetivos de la misión del cliente.

2. Fiabilidad:
 Hasta dónde puede quedarse un programa que lleve a cabo su
función pretendida con la exactitud solicitada. Cabe hacer notar
que se han propuesto otras definiciones de fiabilidad más
completas.

3. Eficiencia:
El conjunto de recursos informáticos y de código necesarios
para que un programa realice su función.

4. Integridad:
Hasta dónde se puede controlar el acceso al software o a los
datos por individuos no autorizados.

5. Usabilidad (facilidad de manejo):

El esfuerzo necesario para aprender, operar, y preparar datos
de entrada e interpretar las salida (resultados) de un programa.

6. Facilidad de mantenimiento:
El esfuerzo necesario para localizar y arreglar un error en un programa.

7. Flexibilidad:
El esfuerzo necesario para modificar un programa operativo.

8. Facilidad de prueba:
El esfuerzo necesario para aprobar un programa para
asegurarse de que realiza su función pretendida.

9. Portabilidad:
El esfuerzo necesario para trasladar el programa de un entorno
de sistema hardware y/o software a otro.

10. Reusabilidad: (capacidad de reutilización):

Hasta dónde se puede volver a utilizar un programa (o partes)
en otras aplicaciones con relación al empaquetamiento y
alcance de las funciones que ejecuta el programa.

11. Interoperatividad:
El esfuerzo necesario para acoplar un sistema con otro.

Es difícil y en algunos casos improbable, desarrollar medidas

directas de los factores de calidad anteriores. Es por eso, que se
definen y emplean un conjunto de métricas para desarrollar
expresiones para todos los factores de acuerdo con la siguiente
relación:
 Fq = c1 * m1 + c2 * m2 + …+ cn * mn

Donde Fq es un factor de calidad del software, cn son coeficientes

de regresión y mn son las métricas que afectan al factor de
calidad. Lo malo es que las métricas definidas por McCall sólo
pueden medirse de manera subjetiva.

Las métricas van en lista de comprobación que se emplean para

‘apuntar’ atributos específicos del software. El esquema de
puntuación presentado por McCall es una escala del 0 (bajo) al 10
(alto) En donde se emplean las siguientes métricas en el esquema
de puntuación:
 Facilidad de auditoria: La facilidad con la que se puede justificar el
cumplimiento de los estándares.
 Exactitud: La exactitud de los cálculos y del control.
 Estandarización de comunicaciones: El nivel de empleo de estándares de
interfaces, protocolos y anchos de banda.
 Complexión: El grado con que sé a logrado la implementación total de una
función.
 Concisión: Lo compacto que resulta ser el programa en términos de líneas
de código.
 Consistencia: El uso de un diseño uniforme y de técnicas de documentación
a través del proyecto de desarrollo del software.
 Estandarización de datos: El empleo de estructuras y tipos de datos
estándares a lo largo del programa.
 Tolerancia al error: El deterioro causado cuando un programa descubre un
error.
 Eficiencia de ejecución: El rendimiento del funcionamiento de un programa.
 Capacidad de expansión. El grado con que se pueden aumentar el diseño
arquitectónico, de datos o procedimental.
 Generalidad: La extensión de aplicación potencial de los componentes del
programa.
 Independencia del hardware: El grado con que se desacopla el software del
hardware donde opera.
 Instrumentación: El grado con que el programa vigila su propio
funcionamiento e identifica los errores que suceden.
 Modularidad: La independencia funcional de componentes de programa.
 Operatividad: La facilidad de operación de un programa.
 Trazabilidad: La capacidad de alcanzar una representación del diseño o un
componente real del programa hasta los requisitos.
 Formación: El grado en que el software ayuda a los nuevos usuarios a
manejar el sistema.

La relación entre los factores de calidad del software y las

métricas de la lista anterior se muestra en la figura siguiente.
Convendría decirse que el peso que se asigna a cada métrica
depende de los productos y negocios locales.
5. FURPS (Funcionality, Usability, Reliability, Performance, Supportability)
Hewlett-Packard ha desarrollado un conjunto de factores de calidad de software
al que se le ha dado el acrónimo de FURPS: [Pressman ’98]

1. Funcionalidad. Se aprecia evaluando el conjunto de características y

capacidades del programa, la generalidad de las funciones entregadas y la
seguridad del sistema global.
2. Usabilidad (facilidad de empleo o uso) Se valora considerando factores
humanos, la estética, consistencia y documentación general.
3. Fiabilidad. Se evalúa midiendo la frecuencia y gravedad de los fallos, la
exactitud de las salidas (resultados), el tiempo medio entre fallos (TMEF), la
capacidad de recuperación de un fallo y la capacidad de predicción del
programa.
4. Rendimiento. Se mide por la velocidad de procesamiento, el tiempo de
respuesta, consumo de recursos, rendimiento efectivo total y eficacia.
5. Capacidad de soporte. Combina la capacidad de ampliar el programa
(extensibilidad), adaptabilidad y servicios (los tres representan
mantenimiento), así como capacidad de hacer pruebas, compatibilidad,
capacidad de configuración, la facilidad de instalación de un sistema y la
facilidad con que se pueden localizar los problemas.
6. METRICAS DEL MODELO DE ANÁ LISIS
En esta fase se obtendrán los requisitos y se establecerá el
fundamento para el diseño. Y es por eso que se desea una visión
interna a la calidad del modelo de análisis. Sin embargo hay pocas
métricas de análisis y especificación, se sabe que es posible
adaptar métricas obtenidas para la aplicación de un proyecto, en
donde las métricas examinan el modelo de análisis con el fin de
predecir el tamaño del sistema resultante, en donde resulte
probable que el tamaño y la complejidad del diseño estén
directamente relacionadas. Es por eso que se
CALIDAD DE SOFTWARE
14

verán en las siguientes secciones las métricas orientadas a la

función, la métrica bang y las métricas de la calidad de
especificación.

Métricas Basadas en la Funció n

La métrica de punto de función (PF) se puede usar como
medio para predecir el tamaño de un sistema que se va a
obtener de un modelo de análisis. Para instruir el empleo de
la métrica PF, se considerará una sencilla representación
del modelo de análisis mostrada por Pressman [‘98] en
donde se representa un diagrama de flujo de datos, de una
función de una aplicación de software llamada Hogar
Seguro. La función administra la interacción con el usurario,
aceptando una contraseña de usuario para activar/
desactivar el sistema y permitiendo consultas sobre el
estado de las zonas de seguridad y varios censores de
seguridad. La función muestra una serie de mensajes de
petición y envía señales apropiadas de control a varios
componentes del sistema de seguridad.

El diagrama de flujo de datos se evalúa para determinar las

medidas clave necesarias para el cálculo de al métrica de
PF.:
 número de entradas de usuario
 número de salidas de usuario
 número de consultas del usuario
 número de archivos
 número de interfaces externas

Hay tres entradas del usuario: contraseña, interruptor de emergencias y

activar/desactivar aparecen en la figura con dos consultas: consulta de zona y
consulta de sensor. Se muestra un archivo (archivo de configuración del
sistema) También están presentes dos salidas de usuarios (mensajes y estado de
del sensor) y cuatro interfaces externas (sensor de prueba, configuración de
zona, activar/desactivar y alerta de alarma).
CALIDAD DE SOFTWARE
14
 La cuenta total mostrada en al figura debe ajustarse usando la ecuación:

PF = cuenta-total * (0.65 + 0.01 * Fi)

Donde cuenta-total es la suma de todas las entradas PF

obtenidas de la figura y Fi( i=1 a 14) son “valores de ajuste
de complejidad”. Para el propósito de este ejemplo,
asumimos que Fi es 46 (un producto moderadamente
complejo) Por lo tanto:

PF = 50* [0.65+(0.01*46)]=56

Basándose en el valor previsto de PF obtenido del modelo

de análisis, el equipo del proyecto puede estimar el tamaño
global de implementación de las funciones de Hogar Seguro.
Asuma que los datos de los que se disponen indican que un
PF supone 60 líneas de código (si se usa un lenguaje
orientado a objetos) y que en un esfuerzo de un mes-
persona se producen 12 PF. Estos datos históricos
proporciona al administrador del proyecto una importante
información de planificación basada en el modelo de análisis
en lugar de en estimaciones preliminares.

Métricas de la Calidad de la Especificació n

Existe una lista de características para poder valorar la
calidad del modelo de análisis y la correspondiente
especificación de requisitos: Especificidad, corrección,
compleción, comprensión, capacidad de verificación,
consistencia externa e interna, capacidad de logro,
concisión, traza habilidad, capacidad de modificación,
exactitud y capacidad de reutilización. Aunque muchas de
las características anteriores pueden ser de naturaleza
cuantitativa, Davis [Presuman ‘98] sugiere que todas puedan
representarse usando una o más métricas. Por ejemplo
asumimos que hay ni requisitos en una especificación, tal
como

ni = nf + nnf

Donde nf es el número de requisitos funcionales y nnf es el

número de requisitos no funcionales ( por ejemplo,
rendimiento).
Para determinar la especificidad de los requisitos, Davis
[Pressman ‘98] sugiere una métrica basada en la
consistencia de la interpretación de los revisores para cada
requisito:

Q1 = nui / nr

Donde nui es el número de requisitos para los que todos los

revisores tuvieron interpretaciones idénticas. Cuanto más
cerca de uno este el valor de Q1 menor será la ambigüedad
de la especificación.

La compleción de los requisitos funcionales pueden

terminarse calculando la relación

Q2 = nu / (ni * ns)

donde nu es el número de requisitos de función únicos, ni es

el número de entradas (estímulos) definidos o implicados
por la especificación y ns es el número de estados
especificados. La relación Q2 mide porcentaje
 de funciones necesarias que se han especificado para un
sistema, sin embargo, no trata los requisitos no funciónales.
Para incorporarlos a una métrica global completa, debemos
considerar el grado de validación de los requisitos:

Q3 = nc / (nc + nnv)

donde nc es el número de requisitos que se han validados

como correctos y nnv el número de requisitos que no se han
validado todavía.

7. METRICAS DEL MODELO DE DISEÑ O

Las métricas para software, como otras métricas, no son
perfectas; muchos expertos argumentan que se necesita más
experimentación hasta que se puedan emplear bien las métricas
de diseño. Sin embargo el diseño sin medición es una alternativa
inaceptable. A continuación se mostraran algunas de las métricas
de diseño más comunes. Aunque ninguna es perfecta, pueden
proporcionarle al diseñador una mejor visión interna y así el diseño
evolucionara a un mejor nivel de calidad.

7.1. Mé tricas de Diseñ o de Alto Nivel

Éstas se concentran en las características de la estructura
del programa dándole énfasis a la estructura arquitectónica
y en la eficiencia de los módulos.

Estas métricas son de caja negra, en el sentido de que no

se requiere ningún conocimiento del trabajo interno de
ningún modo en particular del sistema.

Card y Glass [Pressman ’98] proponen tres medidas de complejidad del

software: complejidad estructural, complejidad de datos y complejidad del
sistema.

La complejidad estructural. S(i), de un módulo i se define de

la siguientes manera.

S(i) = fout (i)

donde f out (i) es la expansión del módulo i.

La complejidad de datos. D(i) proporciona una indicación de

la complejidad en la interfaz interna de un módulo i y se
define como :
 D(i) = v(i) / [fout (i) + 1]

donde v(i) es el número de variables de entrada y salida del módulo i.

Finalmente. la complejidad del sistema. C(i), se define como

la suma de las
complejidades estructural y de datos, y se define como.

C(i)=S(i)+D(i)

A medida que crecen los valores de complejidad, la

complejidad arquitectónica o global del sistema también
aumenta. Esto lleva a una
 mayor probabilidad de que aumente el esfuerzo necesario
para la integración y las pruebas.

Una métrica de diseño arquitectónico propuesta por Henry y

Kafura [Hamdi ‘99] también emplea la expansión y la
concentración. Los autores definen una métrica de
complejidad de la forma:.

MHK = longitud (i) x [f¡n(i) + fout(i)]2

donde la longitud (i) es el número de sentencias en lenguaje

de programación en el módulo (i) y fin (i) es la concentración
del módulo i. Henry y Kafura amplían la definición de
concentración y expansión no sólo el número de conexiones
de control del módulo (llamadas al módulo), sino también el
número de estructuras de datos del que el módulo i recoge
(concentración) o actualiza (expansión) datos.

Para calcular el MHK durante el diseño, puede emplearse el

diseño procedimental para estimar el número de sentencias
del lenguaje de programación del módulo i. Como en las
métricas de Card y Glass mencionadas anteriormente, un
aumento en la métrica de Henry-Kafura conduce a una
mayor probabilidad de que también aumente el esfuerzo de
integración y pruebas del módulo.

Fenton [‘91] sugiere varias métricas de morfología simples

(por ejemplo, forma) que permiten comparar diferentes
arquitecturas de programa mediante un conjunto de
dimensiones directas. En la Figura se muestra un ejemplo
de una arquitectura de software donde puede visualizarse
las siguientes métricas:

Tamañ o = n +a
Donde n es número de nodos (módulos) y a es el número de
arcos (líneas de control) Para la arquitectura mostrada en la
Figura 4.4, [Fenton’91] tamaño = 17 + 18 = 35

profundidad = el camino má s largo desde el nodo raíz (parte má s alta) a un

nodo hoja.

Para la arquitectura mostrada en la Figura profundidad =4.

anchura = máximo número de nodos de cualquier nivel de la
arquitectura.

Para la arquitectura mostrada en la

Figura anchura = 6.
 Relació n arco-a-nodo, r = a/n
que mide la densidad de conectividad de la arquitectura y
puede proporcionar una medida sencilla del acoplamiento
de la arquitectura.

Para la arquitectura mostrada en la Figura

angterior r = 18/17 = 1,06.

El Mando de sistemas de la Fuerza Aérea Americana

[Pressman’98] ha desarrollado varios indicadores de calidad
del software basados en características medibles del diseño
de un programa de computadora. Empleando conceptos
similares a los propuestos en IEEE Std en 1988, la Fuerza
Aérea utiliza información obtenida del diseño de datos y
arquitectónico para obtener un índice de calidad de la
estructura del diseño (ICED) que va desde 0 a 1.

Se deben comprobar los siguientes valores para calcular el

ICED [Pressman’98]:

SI = el número total de módulos definidos en la arquitectura del

programa

S2 = el número de módulos que para funcionar

correctamente dependen de la fuente de datos de entrada o
producen datos que se van a emplear en algún otro lado en
general, los módulos de control (entre otros) no formarían
parte de S2.

S3 = el número de módulos que para que funcionen

correctamente dependen de procesos previos

S4 = el número de elementos de base de datos (incluye

todos los objetos de datos y todos los atributos que definen
los objetos)

S5 = el número total de elementos únicos de base de datos

S6 = el número de segmentos de base de datos (registros

diferentes u objetos individuales)
S7 = el número de módulos con una salida y una entrada (el
proceso de excepciones no se considera de salida múltiple)

Una vez que se han determinado los valores SI a S7 para

un programa de computadora, se pueden calcular los
siguientes valores intermedios:

Estructura del programa: D1, donde D1 se define como

sigue: si el diseño arquitectónico se desarrolló usando un
método determinado (por ejemplo, diseño orientado a flujo de
datos o diseño orientado a objetos), entonces D1=1, de otra
manera D1=0.

Independencia del módulo:

D2=1 – (S2/S1)

Módulos no dependientes de procesos previos:

D3=1 – (S3/S1) (4.21)

Tamaño de la base de datos:

 D4=1 – (S5/S4)

Compartido de la base de datos:

D5=1-(S6/S4)

Caracterísitcas de entrada/salida del módulo:

D6=1 – (S7/S1)

Con estos valores intermedios calculados, el ICED se

obtiene de la siguiente manera:
ICED=_ Wi Di

donde i = 1 a 6, Wi es el peso relativo de la importancia de

cada uno de los valores intermedios y _W i =1 (si todos los
Di tiene el mismo peso, entonces Wi=0.167).

Se puede determinar y compartir el valor de ICED de

diseños anteriores con un diseño actualmente en desarrollo.
Si el ICED es significativamente inferior a la medida, se
aconseja seguir trabajando en el diseño y revisión.
Igualmente, si hay que hacer grandes cambios a un diseño
ya existente, se puede calcular el efecto de estos cambios
en el ICED.

7.2. Mé tricas de Diseñ o en los Componentes

Las métricas de diseño a nivel de componentes se
concentran en las características internas de los
componentes del software e incluyen medidas de la
cohesión, acoplamiento y complejidad del módulo. Estas
tres medidas pueden ayudar al desarrollador de software a
juzgar la calidad de un diseño a nivel de componentes.

Las métricas presentadas son de “caja blanca” en el sentido

de que requieren conocimiento del trabajo interno del
módulo en cuestión. Las métricas de diseño en los
componentes se pueden aplicar una vez que se ha
desarrollado un diseño procedimental. También se pueden
retrasar hasta tener disponible el código fuente

7.3. Mé tricas de Cohesió n

Bieman y Ott [Hamdi ‘99] definen una colección de métricas
que proporcionan una indicación de la cohesión de un
módulo. Las métricas se definen con cinco conceptos y
medidas:
1. Porción de datos. Dicho simplemente, una porción de datos es una
marcha atrás a través de un módulo que busca valores de datos que
afectan a la localización del módulo en el que empezó la marcha
atrás. Debería resaltarse que se pueden definir tanto porciones de
programas (que se centran en enunciados y condiciones) como
porciones de datos.

2. Símbolos léxicos (tokens) de datos. Las variables definidas para un

módulo pueden definirse como señales de datos para el módulo.

3. Señales de unión. El conjunto de señales de datos que se

encuentran en uno o más porciones de datos.

4. Señales de super-unión. Las señales de datos comunes a todas las

porciones de datos de un módulo.
 5. Cohesión. La cohesión relativa de una señal de unión es
directamente proporcional al número de porciones de datos que liga.
Bieman y Ott desarrollaron métricas para cohesiones funcionales
fuertes (CFF), cohesiones funcionales débiles (CFD), y pegajosidad
(el grado relativo con el que las señales de unión ligan juntas
porciones de datos) Estas métricas se pueden interpretar de la
siguiente manera [Hamdi’99] .

Todas estas métricas de cohesión tienen valores que van desde 0 a 1.

Tienen un valor de 0 cuando un procedimiento tiene más de

una salida y no muestra ningún atributo de cohesión
indicado por una métrica particular.

Un procedimiento sin señales de super-unión, sin señales

comunes a todas las porciones de datos, no tiene una
cohesión funcional fuerte (no hay señales de datos que
contribuyan a todas las salidas) Un procedimiento sin
señales de unión, es decir, sin señales comunes a más de
una porción de datos (en procedimientos con más de una
porción de datos), no muestra una cohesión funcional débil y
ninguna adhesividad (no hay señales de datos que
contribuyan a más de una salida) La cohesión funcional
fuerte y la pegajosidad se obtienen cuando las métricas de
Bieman y Ott toman un valor máximo de 1.

Esto es una breve descripción de las métricas de Bieman y

Ott. Sin embargo, para ilustrar el carácter de estas métricas,
se debe la métrica para la cohesión funcional fuerte:

CFF(i) = SU(SA(i))/señ ales (i)

donde SU(SA(i)) denota señales de super-unión (el conjunto

de señales de datos que se encuentran en todas las
porciones de datos de un módulo i) Como la relación de
señales de super-unión con respecto al número total de
señales en un módulo i aumenta hasta un valor máximo de
1, la cohesión funcional del módulo también aumenta 1.

8. METRICAS DEL DISEÑ O DE INTERFAZ

Aunque existe una significativa cantidad de literatura sobre el
diseño de interfaces hombre-máquina, se ha publicado
relativamente poca información sobre métricas que proporcionen
una visión interna de la calidad y facilidad de empleo de la interfaz.
Sears [Pressman ´98] sugiere la conveniencia de la
representación (CR) como una valiosa métrica de diseño para
interfaces hombre-máquina. Una IGU (Interfaz Gráfica de Usuario)
típica usa entidades de representación, iconos gráficos, texto,
menús, ventanas y otras para ayudar al usuario a completar
tareas. Para realizar una tarea dada usando una IGU, el usuario
debe moverse de una entidad de representación a otra. Las
posiciones absolutas y relativas de cada entidad de
representación, la frecuencia con que se utilizan y el “costo” de la
transición de una entidad de representación a la siguiente
contribuirá a la conveniencia de la interfaz.

Para una representación específica (p. ej.: un diseño de una IGU

específica), se pueden asignar costos a cada secuencia de
acciones de acuerdo con la siguiente relación:
 Costos = [frecuencia de transició n (ki) x costos de transició n (ki)]

donde k es la transición i específica de una entidad de

representación a la siguiente cuando se realiza una tarea
específica. Esta suma se da con todas las transiciones de una
tarea en particular o conjunto de tareas requeridas para conseguir
alguna función de la aplicación. El costo puede estar caracterizado
en términos de tiempo, retraso del proceso o cualquier otro valor
razonable, tal como la distancia que debe moverse el ratón entre
entidades de la representación.

La conveniencia de la representación se define como:

CR = 100 x [(costo de la representació n ó ptima CR)/

(costo de la representació n propuesta)] .

donde CR = para una representación óptima. Para calcular la

representación óptima de una IGU, la superficie de la interfaz (el
área de la pantalla) se divide en una cuadrícula. Cada cuadro de
la cuadrícula representa una posible posición de una entidad de la
representación. Para una cuadrícula con N posibles posiciones y
K diferentes entidades de representación para colocar, el número
posible de distribuciones se representa de la siguiente manera
[Pressman ‘98]:

Nú mero posible de distribuciones = [N !/ (K! * (N - K)!] * K!

La CR se emplea para valorar diferentes distribuciones propuestas

de IGU y la sensibilidad de una representación en particular a los
cambios en las descripciones de tareas (por ejemplo, cambios en
la secuencia y/o frecuencia de transiciones) Es importante apuntar
que la selección de un diseño de IGU puede guiarse con métricas
tales como CR, pero el árbitro final debería ser la respuesta del
usuario basada en prototipos de IGU. Nielsen Levy [Pressman ‘98]
informa; que puede haber una posibilidad de éxito si se prefiere la
interfaz basándose exclusivamente en la opinión del usuario ya
que el rendimiento medio de tareas de usuario y su satisfacción
con la IGU están altamente relacionadas.

9. MÉ TRICAS DEL CÓ DIGO FUENTE

La teoría de Halstead de la ciencia del software es ‘probablemente
la mejor conocida y más minuciosamente estudiada... medidas
compuestas de la complejidad (software)’ [Ejiogo ‘91]. La ciencia
software propuso las primeras ‘leyes’ analíticas para el software
de computadora.

La ciencia del software asigna leyes cuantitativas al desarrollo del

software de computadora. La teoría de Halstead se obtiene de un
supuesto fundamental [Pressman ‘98]: ‘el cerebro humano sigue
un conjunto de reglas más rígido (en el desarrollo de algoritmos)
de lo que se imagina...’. La ciencia del software usa un conjunto
de medidas primitivas que pueden obtenerse una vez que se ha
generado o estimado el código después de completar el diseño.
Estas medidas se
listan a continuación.

n1: el número de operadores diferentes que aparecen en

el programa n2: el número de operandos diferentes que
aparecen en el programa N1: el número total de veces
que aparece el operador
N2: el número total de veces que aparece el operando
Halstead usa las medidas primitivas para desarrollar expresiones
para la longitud global del programa; volumen mínimo potencial
para un algoritmo; el volumen real (número de bits requeridos para
especificar un programa); el nivel del programa (una medida de la
complejidad del software); nivel del lenguaje (una constante para
un lenguaje dado); y otras características tales como esfuerzo de
desarrollo, iempo de desarrollo e incluso el número esperado de
fallos en el software.

Halstead expone que la longitud N se puede estimar como:

N = n1 log2 n1 + n2 log2 n2

y el volumen de programa se puede

definir como: V = N log2 (n1 + n2) (4.34)
Se debería tener en cuenta que V variará con el lenguaje de
programación y representa el volumen de información

Teóricamente debe existir un volumen mínimo para un algoritmo.

Halstead define una relación de volumen L como la relación
volumen de la forma más compacta de un programa respecto al
volumen real del programa. Por tanto L, debe ser siempre menor
de uno. En términos de medidas primitivas, la relación de volumen
se puede expresar como:

L = 2/n1*n2/N2

Halstead propuso que todos los lenguajes pueden categorizarse

por nivel de lenguaje, I, que variará según los lenguajes. Halslead
creó una teoría que suponía que el nivel de lenguaje es constante
para un lenguaje dado, pero otro trabajo [Pressman ‘98] indica que
el nivel de lenguaje es función tanto del lenguaje como del
programador. Los siguientes valores de nivel de lenguaje se
muestran en la tabla siguiente:
 Parece que el nivel de lenguaje implica un nivel de abstracción en
la especificación procedimental. Los lenguajes de alto nivel
permiten la especificación del código a un nivel más alto de
abstracción que el lenguaje ensamblador (orientado a máquina).

10. MÉ TRICAS PARA PRUEBAS

Aunque se ha escrito mucho sobre métricas del software para
pruebas, la mayoría de las métricas propuestas se concentran en
el proceso de pruebas, no en las características técnicas de las
pruebas mismas. En general, los responsables de las pruebas
deben fiarse del análisis, diseño y código para que les guíen en el
diseño y ejecución los casos de prueba Las métricas basadas en
la función pueden emplearse para predecir el esfuerzo global de
las pruebas Se
pueden juntar y correlacionar varias características a nivel de
proyecto (p ej.: esfuerzo y tiempo las pruebas, errores
descubiertos, número de casos de prueba producidos) de
proyectos anteriores con el número de Pf producidos por un
equipo del proyecto. El equipo puede después predecir los valores
‘esperados’ de estas características del proyecto actual. La
métrica bang puede proporcionar una indicación del número de
casos de prueba necesarios para examinar las medidas primitivas.
El número de primitivas funcionales (Pfu), elementos de datos,
(ED), objetos (0B), relaciones (RE), estados (ES) y transiciones
(TR) pueden emplearse para predecir el número y tipos de
pruebas de la caja negra y blanca del software Por ejemplo, el
número de pruebas asociadas con la interfaz hombre-máquina se
puede estimar examinando (1) el número de transiciones (TR)
contenidas en la representación estadotransición del IHM y
evaluando las pruebas requeridas para ejecutar cada transición,
(2) el número de objetos de datos (0B) que se mueven a través de
la interfaz y (3) el número de elementos de datos que se
introducen o salen.

Las métricas de diseño de alto nivel proporcionan información

sobre facilidad o dificultad asociada con la prueba de integración y
la necesidad de software especializado de prueba (p. ej.: matrices
y controladores) La complejidad ciclomática (una métrica de
diseño de componentes) se encuentra en el núcleo de las pruebas
de caminos básicos, un método de diseño de casos de prueba.

Además, la complejidad ciclomática puede usarse para elegir

módulos como candidatos para pruebas más profundas. Los
módulos con gran complejidad ciclomática tienen más probabilidad
de tendencia a errores que los módulos con menor complejidad
ciclomática. Por esta razón, el analista debería invertir un esfuerzo
extra para descubrir errores en el módulo antes de integrarlo en un
sistema. El esfuerzo de las pruebas también se puede estimar
usando métricas obtenidas de medidas de Halstead.

Usando la definición del volumen de un programa V, y nivel de

programa, NP, el esfuerzo de la ciencia del software, puede
calcularse como;

NP=1 / [(n1 / 2) * (N2 / n2)]

e = V / NP

El porcentaje del esfuerzo global de pruebas a asignar un módulo

k para estimar usando la siguiente relación:
 porcentaje de esfuerzo de pruebas (k) = e(k)/e(i)

donde e(k) se calcula para el módulo k usando las ecuaciones y

suma en el denominador de la ecuación es la suma del esfuerzo
de la ciencia del software a lo largo de todos los módulos del
sistema.

A medida que se van haciendo las pruebas tres medidas

diferentes proporcionan una indicación de la complexión de las
pruebas. Una medida de la amplitud de las pruebas proporciona
una indicación de cuantos (del número total de ellos) se han
probado. Esto proporciona una indicación de la complexión del
plan de pruebas. La profundidad de las prueba es una medida del
porcentaje de los caminos básicos independientes probados en
relación al número total de estos caminos en el programa. Se
puede calcular una estimación razonablemente exacta del número
de caminos básicos sumando la complejidad ciclomática de todos
los módulos del programa. Finalmente, a medida que se van
haciendo las
 pruebas y se recogen los datos de los errores, se pueden emplear
los perfiles de fallos para dar prioridad y categorizar los errores
descubiertos. La prioridad indica la severidad del problema. Las
categorías de los fallos proporcionan una descripción de un error,
de manera que se puedan llevar a cabo análisis estadísticos de
errores.

11. MÉ TRICAS DE MANTENIMIENTO

Se han propuesto métricas diseñadas explícitamente para
actividades de mantenimiento. El estándar IEEE 982.1-1988
[Pressman ‘98] sugiere un índice de madurez del software (IMS)
que proporciona una indicación de la estabilidad de un producto
de software (basada en los cambios que ocurren con cada versión
del producto) Se determina la siguiente información:

Mr = número de módulos en la versión actual

Fc = número de módulos en la versión actual que se han cambiado

Fa = número de módulos en la versión actual que se han añadido

Fd = número de módulos de la versión anterior que se han borrado

en la versión actual

El índice de madurez del software se calcula de la siguiente manera:

IMS = [Mr – (Fa + Fc + Fd)]/ Mr

A medida que el IMS se aproxima a 1.0 el producto se empieza a

estabilizar. El IMS puede emplearse también como métrica para la
planificación de las actividades de mantenimiento del software. El
tiempo medio para producir una versión de un producto software
puede correlacionarse con el IMS desarrollándose
modelos empíricos para el mantenimiento.

Autoevaluación
 Mencione y explique brevemente cuáles son las medidas que normalmente se
consideran en el software
 Desarrolle el Factor de Calidad “Fiabilidad” del modelo de McCall teniendo
como referencia la Especificación de Requerimientos de su curso de Diseño
de Aplicaciones Web
Aseguramiento de la Calidad de Software - SQA

TEMA

Garantía de Calidad de Software

OBJETIVOS ESPECÍFICOS
 Definir la importancia de las actividades de SQA para los proyectos de TI
 Identificar las principales actividades del equipo de SQA
 Definir la estrategia de pruebas de RTF

CONTENIDOS
 Aseguramiento de la Calidad de Software
 Administración de la Calidad
 Revisiones Técnicas Formales (RTF)
 Garantía de Calidad Estadística
 Fiabilidad de Software

ACTIVIDADES
 Aplicar una RTF a un proyecto desarrollado en el curso de Diseño de
Aplicaciones Web
1. ASEGURAMIENTO DE LA CALIDAD DE SOFTWARE (SQA)
La calidad del software no es algo en lo que se empieza a pensar
una vez que se ha generado el código. Según R. Presuman, el
aseguramiento de la calidad del software (SQA) es una “actividad
de protección” que se aplica a lo largo de todo el proceso de
ingeniería software y engloba:
1. Un enfoque de gestión de la calidad
2. Tecnología de ingeniería del software o del conocimiento efectiva
(métodos y herramientas)
3. Revisiones técnicas formales que se aplican durante cada paso de la
ingeniería del software o del conocimiento
4. Una estrategia de prueba en múltiples niveles
5. El control de la documentación del software y de los cambios realizados
6. Un procedimiento que asegure un ajuste a los estándares de desarrollo
del software (cuando sea posible)
7. Mecanismos de medición y de información

Las anteriores involucran tanto a los ingenieros de software como

al equipo de SQA. Los ingenieros de software deben aplicar
métodos técnicos y mediciones sólidas, conducir revisiones
técnicas formales y ejecutar pruebas de software bien
planificadas. Por otro lado, de acuerdo al Software Engineering
Institute (SEI), el equipo de SQA tiene como propósito proveer a
la gerencia la visibilidad apropiada del proceso que está siendo
usado y de los productos siendo desarrollados. El propósito
involucra:
 Revisar y auditar los productos de software y actividades para asegurar
que obedecen a los procedimientos y estándares aplicables
 Proveer al gerente del proyecto de software y a otras gerencias, según
corresponda, los resultados de las revisiones y auditorias. Las
discrepancias son primero planteadas dentro del proyecto de software y
resueltas allí, si es posible. Si no se pueden resolver, se debe escalar a
niveles superiores para su resolución.

1.1. Actividades del Equipo de SQA

Las actividades del equipo de SQA, acorde al SEI, comprenden:
1. Preparar un plan de SQA para el proyecto: El plan es desarrollado
durante la planificación del proyecto y es revisado por todas las
partes interesadas. Las actividades de aseguramiento de la calidad
a desempeñar por el equipo de ingenieros de software y el equipo
de SQA son regidas por este plan. El plan identifica:
 Evaluaciones a realizar
 Auditorías y revisiones a realizar
 Estándares aplicables al proyecto
 Procedimientos para reporte y seguimiento de errores
 Documentos a ser producidos por el equipo de SQA
 Retro-alimentación a proveer al equipo del proyecto de software.
2. Participar en el desarrollo de la descripción del proceso de
software del proyecto: El equipo de software selecciona un proceso
de software para el proyecto, el equipo de SQA revisa la
descripción del proceso, verificando que cumpla con las políticas
de la organización, estándares de software internos y estándares
 impuestos externamente, entre otros.
3. Revisar las actividades de ingeniería del software o de
conocimiento para verificar que cumplan con el proceso de
software definido: El equipo de SQA identifica, documenta y hace
el seguimiento de
 cualquier desviación del proceso y verifica las
correcciones realizadas
4. Auditar productos de trabajo de software designados, para verificar
que cumplan con aquellos definidos como parte del proceso de
software: El equipo de SQA revisa productos seleccionados;
identifica, documenta y hace el seguimiento de las desviaciones;
verifica las correcciones realizadas y periódicamente informa los
resultados de su trabajo al gerente del proyecto
5. Asegurar que las desviaciones detectadas sean documentadas y
manejadas de acuerdo a procedimientos documentados: Las
desviaciones pueden encontrase en el plan de proyecto,
descripciones del proceso, estándares aplicables o productos de
trabajo técnico
6. Registrar cualquier incumplimiento y reportarlo a la alta gerencia: A
los incumplimientos se les debe hacer seguimiento hasta que sean
resueltos.

El equipo de SQA participa también en la tarea recolectar y

analizar métricas de software como así también en establecer y
revisar procedimientos, planes y estándares.

2. ADMINISTRACIÓ N DE LA CALIDAD
La Administración de la Calidad cuenta con dos niveles de trabajo:

El nivel de entidad u organización. Donde se trata de crear y

gestionar una infraestructura que fomente la calidad de los
productos software mediante la adecuación y mejora de las
actividades y procesos involucrados en su producción e, incluso,
en su comercialización y en la interacción con los clientes.

El nivel del proyecto. Donde las guías que la infraestructura

organizativa prevé para las distintas actividades y mantenimiento
del software deben ser adaptadas a las características concretas
del proyecto y de su entorno para ser aplicadas a la práctica.

Dentro del primer nivel de acción, la gestión de la calidad en

organizaciones de software ha seguido dos líneas que pueden
ser complementarias entre sí:

Por una parte, se ha seguido la línea marcada por las entidades

internacionales de estandarización para todas las organizaciones
de producción o servicios. Principalmente se han impuesto en la
práctica las directrices marcadas por ISO (Organization for
Internacional Standarization) a través de unas normas ISO 9000
para la gestión de calidad. En el caso del software es
principalmente aplicable la norma ISO 9001. El sector de
software difiere por la naturaleza del producto tanto del resto de
sectores productivos que ha sido necesario crear una guía
específica para su aplicación a este sector: ISO 9000-3.

El mundo del software ha creado sus propias líneas de trabajo en

la gestión de la calidad, trabaja sobre los procesos de producción
como medio para asegurar la calidad del producto software. Por
ejemplo, el SEI (Software Engineering Institute), proponiendo un
modelo de clasificación y mejora de los procesos empleados por
las organizaciones de software denominado CMM y su evolución
al CMMI.
 La Calidad del Software se diseña conjuntamente con el sistema,
nunca al final. En los sistemas de garantía de calidad, se observa
una relación entre los precios y costos que generan las fallas al
producir software, costos al volver a trabajar sobre un software ya
desarrollado para reparar defectos, la reducción de precios al
obtener una calidad más pobre, los costos del proceso de
inspección del software, el costo del sistema de garantía de
calidad y los beneficios obtenidos. A mayor calidad, mayores son
los costos, pero mayores también los beneficios obtenidos en la
fase del mantenimiento del software. Este costo hay que
considerarlo dentro de todo el ciclo de vida del proyecto.

El aseguramiento de la Calidad de Software engloba un enfoque

de gestión de calidad, tecnología de ingeniería de software
efectiva (métricas y herramientas), revisiones técnicas formales
(RTF) que se aplican durante el proceso del software, una
estrategia de prueba multiescalada, el control de la
documentación del software y de los cambios realizados, un
procedimiento que asegure un ajuste a los estándares de
desarrollo del software (cuando sea posible) y mecanismos de
medición y de generación de informes.

La idea de la necesidad de realizar pruebas en fases tempranas,

conduce a realizar un mecanismo básico que permite las
Revisiones Técnica Formales.

3. REVISIONES TÉ CNICA FORMALES (RTF)

Una revisión técnica formal (RTF) es una actividad que garantiza
la Calidad del Software y que es llevada a cabo por los
profesionales de la ingeniería de software. Los objetivos de la
RTF son:
1. Descubrir errores en la función, la lógica o la implementación de cualquier
representación del software
2. Verificar que el software bajo revisión alcance sus requisitos
3. Garantizar que el software haya sido representado de acuerdo con ciertos
estándares predefinidos
4. Conseguir un software desarrollado de forma uniforme y
5. Hacer que los proyectos sean más manejables.

La RTF es una actividad colectiva que permite ampliar la visión

sobre lo que se revisa, situación que se profundiza al ser aplicada
por distintos niveles y especialidades de profesionales a distintos
elementos que componen el software, lo cual permite; por una
parte que los profesionales que recién se incorporan al equipo de
trabajo puedan observar los diferentes enfoques del análisis,
diseño e implementación del software, además que sirve para
promover la seguridad y la continuidad, ya que varias personas
se familiarizan con partes del software que de otro modo no
hubiesen visto nunca.

Las revisiones técnicas formales permiten establecer un marco

común para la definición de distintas etapas de revisión en el
ciclo de vida del software, este mecanismo no sólo está pensado
para las etapas tempranas del ciclo de vida, sino que también
puede - y debe – ser utilizado en etapas como la de prueba de
software y el mantenimiento. El mecanismo más común para su
implementación es la reunión de revisión, la cual deberá regirse,
para asegurar su éxito, por una buena planificación, control y,
sobre todo, por la participación dedicada de todos y cada uno de
los involucrados. Condiciones sumamente restrictivas para la
forma en que estas revisiones se realicen, lo que lleva a que su
orientación sea muy específica, en el sentido que cada RTF debe
centrarse en una parte muy bien delimitada del software total.
Se pueden realizar inspecciones para cada módulo o pequeño
grupo de módulos que conformen un sistema. Al limitar el centro
de atención de la RTF la probabilidad de descubrir errores es
mayor. En la figura 2 se puede apreciar lo que sería el flujo de
información necesario para realizar correcta y completamente
una prueba de software, la cual puede ser aplicada tanto a los
módulos individuales como al software en su totalidad.

Figura 2 - Flujo de Información para realizar una prueba

3.1. La Reunió n de Revisió n

Independientemente del formato que se elija para la RTF,
cualquier reunión de revisión debe acogerse a las
siguientes restricciones:
 Deben convocarse para la revisión (normalmente) entre tres y cinco
personas
 Se deben preparar por adelantado, pero sin que requiera más de
dos horas de trabajo a cada persona, y
 La duración de la reunión de revisión debe ser menor de dos horas

Con las anteriores limitaciones, debe resultar obvio que

cada RTF se centra en una parte específica (y pequeña)
del software total. Por ejemplo, en lugar de intentar revisar
un diseño completo, se hacen inspecciones para cada
módulo (componente) o pequeño grupo de módulos. Al
limitar el centro de atención de la RTF, la probabilidad de
descubrir errores es mayor.

El centro de atención de la RTF es un producto de trabajo

(por ejemplo, una porción de requisitos, un diseño detallado
del módulo, enlistado del código fuente de un módulo). El
individuo que ha desarrollado el producto informa al Jefe de
Proyecto de que el producto está terminado y que se
requiere una revisión. El Jefe de Proyecto contacta con un
Jefe de Revisión, que evalúa la disponibilidad del producto,
genera copias del material del producto y las distribuye a
dos o tres revisores para que se preparen por adelantado.
Cada revisor estará una y dos horas revisando el producto,
tomando notas y también familiarizándose con el trabajo.
De
CALIDAD DE SOFTWARE
8

forma concurrente, también el Jefe de Revisión revisa el

producto y establece una agenda para la reunión de
revisión que, normalmente, queda convocada para el día
siguiente.

La reunión de revisión es llevada a cabo por el Jefe de

Revisión, los revisores y el productor. Uno de los revisores
toma el papel d registrador, o sea, de persona que registra
(de forma escrita) todos los sucesos importantes que se
produzcan durante la revisión. La RTF comienza con una
explicación de la agenda y una breve introducción a cargo
del productor. Entonces el productor procede con el
recorrido de inspección del producto, explicando el
material, mientras que los revisores exponen sus
consideraciones basándose en su preparación previa.
Cuando se descubren problemas o errores válidos, el
registrador los va anotando.

Al final de la revisión, todos los participantes en la RTF deben decidir si

(1) aceptan el producto sin posteriores modificaciones; (2)
rechazan el producto debido a los errores encontrados (una
vez corregidos, ha de hacerse otra revisión) o (3) aceptan
el producto provisionalmente (se ha encontrado errores
menores que deben ser corregidos, pero sin necesidad de
otra posterior revisión). Una vez tomada la decisión, todos
los participantes terminan firmando, indicando así que han
participado en la revisión y que están de acuerdo con las
conclusiones del equipo de revisión.

3.2. Registro e Informe de la Revisió n

Durante la RTF, uno de los revisores (el registrador)
procede a registrar todas las ocurrencias que vayan
surgiendo. Al final de la reunión de revisión, resume todas
las ocurrencias y genera una lista de sucesos de revisión.
Además, prepara un informe sumario de la revisión técnica
formal. El informe sumario de la revisión responde a tres
preguntas:
1. ¿Qué fue revisado?
2. ¿Quién lo revisó?
3. ¿Qué se descubrió y cuáles son las conclusiones?

Dicho informe es una página simple (con posibles anexos)

que se adjunta al registro histórico del proyecto.

La lista de sucesos de revisión sirve para:

 Identificar las áreas problemáticas dentro de un producto
CALIDAD DE SOFTWARE
8
 Servir como lista de comprobación de puntos de acción que guíe al
productor para hacer las correcciones

La lista de sucesos puede adjuntarse al informe resumen.

Cuando el producto es aceptado con cambios, alguien debe

encargarse del
seguimiento de los cambios identificados en la lista de
sucesos de revisión. El revisor jefe o el equipo SQA pueden
ser los encargados de dicho seguimiento.

3.3. Directrices para la Revisió n

Las directrices de revisión deben establecerse de
antemano para evitar Problemas y para
conducirlas revisiones técnicas
formales, distribuyéndolas después entre los
revisores, para ser consensuadas y,
finalmente, seguidas. A menudo una revisión incontrolada
puede ser peor que no hacer ningún tipo de revisión. A
continuación se muestra un conjunto mínimo de directrices
para las RTF:
1. Revisar el producto, no al productor
Una RTF involucra gente y egos. Conducida
adecuadamente, la RTF debe llevar a todos los
participantes a un sentimiento agradable de estar
cumpliendo su deber. Si se lleva incorrectamente, la
RTF puede tomar el aura de inquisición. Se deben
señalar los errores educadamente; el tono de la reunión
debe ser distendido y constructivo; no debe intentarse
dificultar o batallar. El Jefe de Revisión debe moderar la
reunión para garantizar que se mantiene un tono y una
actitud adecuados y debe inmediatamente cortar
cualquier revisión que haya escapado al control.
2. Fijar una agenda y mantenerla
Un mal de las reuniones de todo tipo es la deriva. La
RTF debe seguir un plan de trabajo concreto. El jefe de
revisión es el que carga la responsabilidad de mantener
el plan de la reunión y no debe tener miedo de cortar a
la gente cuando se empiece a divagar.
3. Limitar el debate y las impugnaciones
Cuando un revisor ponga de manifiesto una
observación, podrá no haber unanimidad sobre su
impacto. En lugar de perder el tiempo debatiendo la
cuestión, debe registrarse el hecho y dejar que la
cuestión se lleve a cabo en otro momento.
4. Enunciar áreas de problemas, pero no intentar resolver cualquier
problema que se ponga de manifiesto
Una revisión no es una sesión d resolución de
problemas. A menudo, la resolución de los problemas
puede ser encargada al productor por sí solo o con la
ayuda de otra persona. La resolución de los problemas
debe ser propuesta para después de la reunión de
revisión.
5. Tomar notas escritas
A veces es buena idea que el registrador tome las notas
en una pizarra, de forma que las declaraciones o la
asignación de prioridades pueda ser comprobada por el
resto de los revisores, a medida que se va registrando
la información.
6. Limitar el número de participantes e insistir en la preparación
anticipada
Dos personas son mejores que una, pero catorce no
son necesariamente mejores que cuatro. Se ha de
mantener el número de participantes en el mínimo
necesario. Además, todos los miembros del equipo de
revisión deben prepararse por anticipado. El Jefe de
 Revisión debe solicitar comentarios (que muestren que
cada revisor ha revisado el material).
7. Desarrollar una lista de comprobación para cada producto que
vaya a ser revisado
Una lista de comprobaciones ayuda al Jefe de Revisión
a estructurar la reunión d RTF y ayuda a cada revisor a
centrarse en los asuntos importantes. Se deben
desarrollar listas de comprobaciones para los
documentos de análisis, de diseño, de codificaciones e
incluso de prueba.
8. Disponer de recursos y una agenda para la RTF
Para que las revisiones sean efectivas, se debe
planificar como una tarea del proceso de ingeniería de
software. Además se debe trazar un plan de acción
para las modificaciones inevitables que aparecen como
resultado de una RTF.
 9. Llevar a cabo un buen entrenamiento de todos los revisores
Por razones de efectividad, todos los participantes en la
revisión deben recibir algún entrenamiento formal. El
entrenamiento se debe basar en los aspectos
relacionados con el proceso, así como las
consideraciones de psicología humana que atañen a la
revisión.
10. Repasar las reuniones anteriores
Las sesiones de información pueden ser beneficiosas
para descubrir problemas en el propio proceso de
revisión. El primer producto que se haya revisado
puede establecer las propias directivas de revisión.

4. GARANTIA DE CALIDAD ESTADISTICA

La garantía de calidad estadística refleja una tendencia creciente
en toda la industria de establecer más cuantitativa la calidad. La
garantía de calidad estadística implica los siguientes pasos :
1. Se agrupa y se clasifica la información sobre los defectos existentes
2. Se intenta encontrar la causa subyacente de cada defecto (por ejemplo,
no concordancia con la especificación, error de diseño incumplimiento de
los estándares, pobre comunicación con el cliente).
3. Mediante el principio de Pareto (el 80% de los defectos se pueden
encontrar en el 20% de todas las posibles causas), se aísla el 20 % (los
pocos pero vitales)
4. Una vez que se han identificado los defectos vitales, se actúa para
corregir los problemas que han producido los defectos.

Es importante tener en cuenta que la acción correctora se centra

básicamente en los defectos vitales. A medida que se corrigen
las causas vitales, aparecen nuevas candidatas en lo alto de la
pila. Proceso limpio. La verificación formal de programas
(pruebas de corrección) y la SQA estadística se han combinado
en una técnica que mejora la calidad del producto de software.
Denominado proceso limpio o ingeniería del software limpia,
se puede resumir de la siguiente manera : Con el proceso limpio,
se puede llevar un control de calidad estadístico, igual que con el
desarrollo de hardware limpio, la mayor prioridad del proceso es
la prevención de los defectos, más que la eliminación de
defectos. Esta primera prioridad se consigue mediante la
verificación matemática (pruebas de corrección) en lugar de la
depuración de programas que se prepara para la prueba del
sistema. La siguiente prioridad es proporcionar una certificación
estadística válida de la calidad de los sistemas. La medida de la
calidad viene dada por el tiempo medio hasta que se produce el
fallo

4.1. Posibles Causas de Errores en el Software

 Especificación incompleta o errónea (EIE)
 Mala interpretación de la comunicación del cliente (MCC)
 Desviación deliberada de la especificación (DDE)
 Incumplimiento de los estándares de programación (IEP)
 Error en la representación de los datos (ERD)
 Interfaz de módulo inconsistente (IMI)
 Error en la lógica de diseño (ELD)
 Prueba incompleta o errónea (PIE)
 Documentación imprecisa o incompleta (DII)
 Error en la traducción del diseño al lenguaje de programación (TLP)
 Interfaz hombre-máquina ambigua o inconsistente (IHM)
 Varios (VAR)
4.2. Aplicació n del SQA Estadística
Para aplicar el SQA estadística se construye la Tabla 1. La
tabla indica que EIE, MCC y ERD son las causas vitales
que contabilizan el 53% de todos los errores. Sin embargo,
debe observarse que si sólo se consideran errores serios,
se seleccionarían las siguientes causas vitales: EIE, ERD,
TLP y ELD. Una vez determinadas las causas vitales, la
organización de desarrollo de software puede comenzar la
acción correctiva. Por ejemplo, para corregir la MCC, el
equipo de desarrollo de software podría implementar
técnicas que facilitaran la especificación de la aplicación
para mejorar la calidad de la especificación y la
comunicación con el cliente. Para mejorar el ERD, el
equipo de desarrollo del software podría adquirir
herramientas CASE para el modelamiento de datos y
realizar revisiones del diseño de datos más rigurosas.

Es importante destacar que la acción correctiva se centra

principalmente en las causas vitales. Cuando éstas son
corregidas, nuevas candidatas saltan al principio de la lista.

Junto con la recopilación de información sobre defectos, los

equipos de desarrollo del software pueden calcular el índice
de errores (IE) para cada etapa principal del proceso de
ingeniería de software. Después del análisis, del diseño, la
codificación, la prueba y la entrega, se recopilan los
siguiente datos:

Ei=número total de defectos descubiertos durante la etapa

i-ésima del proceso de ingeniería de software
Si=número de defectos
graves Mi=número de
defectos moderados
Ti=número de defectos leves
PS=tamaño del producto (LDC, sentencias de diseño,
páginas de documentación) en la etapa i-esima
Ws, Wm, Wt=factores de peso de errores graves,
moderados, y leves, en donde los valores recomendados
son Ws=10, Wm= 3, Wt=1. Los factores de peso de cada
fase deberían agrandarse a medida que el desarrollo
evoluciona. Eso favorece a la organización que encuentra
los errores al principio.
 En cada etapa del proceso de ingeniería de software se
calcula un índice de fase, IFi:

IFi = Ws (Si / Ei ) + Wm (Mi Ei ) + Wt (Ti / Ei)

El índice de errores (IE) se obtiene mediante el cálculo del

defecto acumulativo de cada IF i asignando más peso a los
errores encontrados más tarde en el proceso de ingeniería
del software, que a los que se encuentran en las primeras
etapas.

IE = ∑ (i x IFi) / PS
= (IF1 + 2 IF2 + 3 IF3 + … + i IFi) / PS

Tot Gra Moderado Le

al ve ve
Error No. % No. % No. % No. %
EIE 2 22 3 27 6 18 1 24
0 % 4 % 8 % 0 %
5 3
 MCC 156 17% 12 9% 68 18% 76 17%
DDE 48 5% 1 1% 24 6% 23 5%
IEP 25 3% 0 0% 15 4% 10 2%
ERD 130 14% 26 20% 68 18% 36 8%
IMI 58 6% 9 7% 18 5% 31 7%
ELD 45 5% 14 11% 12 3% 19 4%
PIE 95 10% 12 9% 35 9% 48 11%
DII 36 4% 2 2% 20 5% 14 3%
TLP 60 6% 15 12% 19 5% 26 6%
IHM 28 3% 3 2% 17 4% 8 2%
VAR 56 6% 0 0% 15 4% 41 9%
Totale 942 100% 128 100% 379 100% 435 100%
s

Tabla 1 – Recolección de datos para la SQA estadística

5. FIABILIDAD DEL SOFTWARE

No hay duda que la fiabilidad de un programa de computadora es
un elemento importante de su calidad general. Si un programa
falla frecuentemente en su funcionamiento, no importa si el resto
de los factores de calidad son aceptables.

La fiabilidad del software, a diferencia de otros factores de

calidad, puede ser medida o estimada mediante datos históricos
o de desarrollo. La fiabilidad del software se define en términos
estadísticos como la probabilidad de operación libre de fallos de
un programa de computadora es un entorno determinado y
durante un tiempo específico. Por ejemplo, un programa X puede
tener una fiabilidad estimada de 0.96 durante un intervalo de
proceso de ocho horas. En otras palabras, si se fuera a ejecutar
el programa X 100 veces, necesitando de ocho horas de tiempo
de proceso (tiempo de ejecución), lo probable es que funcione
correctamente (sin fallos) 96 de cada 100 veces.

Siempre que se habla de fiabilidad, surge una pregunta

fundamental ¿qué se entiende por el término fallo? En el contexto
de cualquier disquisición sobre calidad y fiabilidad del software, el
fallo es cualquier falla de concordancia con los requisitos del
software. Incluso en esta definición existen grados. Los fallos
pueden ser simplemente desconcertantes o ser catastróficos.
Puede que un fallo sea corregido en segundos mientras que otro
lleve semanas o incluso meses. Para complicar más las cosas, la
corrección de un fallo puede llevar a la introducción de otros
errores que, finalmente, lleven a más fallos. Medidas de fiabilidad
y de disponibilidad. Los primeros trabajos sobre fiabilidad
intentaron explotar las matemáticas de la teoría de fiabilidad del
hardware a la predicción de la fiabilidad del software. La mayoría
de los modelos de fiabilidad relativos al hardware van más
orientados a los fallos debidos al desajuste que a los fallos
debidos a defectos del diseño. En el hardware, son más
probables los fallos debidos al desgaste físico que los fallos
relativos al diseño. Desgraciadamente para el software lo que
ocurre es lo contrario. De hecho todos los fallos del software, se
producen por problemas de diseño o de implementación; el
desajuste no entra en este panorama.

5.1. Modelos de Fiabilidad de Software

Para modelar la fiabilidad del software, se deben considerar
primero los principales factores que le afecten: Introducción
de fallos, eliminación de fallos y entorno. La introducción de
fallos depende principalmente de las características del
código desarrollado y de las características del proceso de
desarrollo. La característica del código más significativa es
el tamaño. Entre las características del proceso del
desarrollo se
encuentran las tecnologías y las herramientas de ingeniería
del software usadas, y el nivel de experiencia del personal.
Se puede desarrollar código para añadir posibilidades o
para eliminar fallos. La eliminación de fallos depende del
tiempo, del perfil operativo. Como algunos los anteriores
factores son de naturaleza probabilística y se dan en el
tiempo, los modelos de fiabilidad del software generalmente
se formulan en términos de
procesos aleatorios.

Los modelos de fiabilidad del software entran en dos

grandes categorías:

1. Modelos que predicen la fiabilidad como una función cronológica

del tiempo (calendario)
2. Modelos que predicen la fiabilidad como una función del tiempo de
procesamiento transcurrido (tiempo de ejecución de CPU)

Se han propuesto modelo estocásticos mucho más

sofisticados para la fiabilidad del software:
1. Validez predictiva.
La posibilidad de que el modelo prediga el
comportamiento de fallo futuro basándose en los datos
obtenidos de las fases de prueba y de operación.
2. Capacidad.
La posibilidad de que el modelo genere datos que
puedan ser fácilmente aplicados a los esfuerzos de
desarrollo de software industriales.
3. Calidad de suposiciones.
La plausibilidad de las suposiciones en las que se
basan los fundamentos matemáticos del modelo
cuando se llega a los límites de esas suposiciones
4. Aplicabilidad.
El grado en que se puede aplicar un modelo de
fiabilidad en diferentes terrenos y tipos de aplicación del
software
5. Simplicidad.
El grado en que el conjunto de datos que soportan el
modelo el directo; el grado en que el enfoque y las
matemáticas son intuitivos; el grado en que se puede
automatizar el enfoque general
6. Seguridad del software.
La seguridad del software es una actividad de garantía
de calidad del software que se centra en la
identificación y evaluación de los riesgos potenciales
que pueden producir un impacto negativo en el software
y hacer que falle el sistema completo.
Autoevaluación

 ¿Cuáles son las actividades que abarca el SQA?

 ¿Cuáles son las principales actividades del equipo de SQA?
 Desarrolle una lista de ocurrencias aplicando el método de RTF