UNIDAD 5

METRICAS PARA SOFTWARE

5.1 Introduccin
Medir:
1. Determinar el valor de una
magnitud.
2. Determinar la cantidad [de
una cosa] por
comparacin con otra
cantidad de la misma
especie tomada como
unidad.


Medicin
Acto de determinar una
medida.
Medida
Proporciona una indicacin
cuantitativa de la cantidad,
dimensiones o tamao de
algunos
atributos de un producto.
Es lo mismo medir,
medicin y medida?
5.1 Introduccin
Mtrica
Es una medida del grado en que un sistema, componente o proceso posee un
atributo dado.

Es una medida efectuada sobre algn aspecto del sistema en desarrollo o del
proceso empleado que permite, previa comparacin con unos valores (medidas)
de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar
las decisiones necesarias.

5.1 Introduccin
de complejidad Mtricas que definen la medicin de la
complejidad: volumen, tamao,
anidaciones, y configuracin.

de calidad Mtricas que definen la calidad del
software: exactitud, estructuracin o
modularidad, pruebas, mantenimiento.

de competencia

Mtricas que intentan valorar o medir
las actividades de productividad
de los programadores con respecto a su
certeza, rapidez, eficiencia y
competencia
de desempeo

Mtricas que miden la conducta de
mdulos y sistemas de un software,
bajo la supervisin del SO o hardware.
estilizadas

Mtricas de experimentacin y de
preferencia: estilo de cdigo,
convenciones, limitaciones, etc.
Clasificacin de las Mtricas
5.1 Introduccion
El objetivo primordial de la
ingeniera del software es
producir un sistema, aplicacin
o producto de alta calidad. Para
lograr este objetivo, los
ingenieros de software deben
emplear mtodos 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
ingeniera del software deben
medir si la alta calidad se va a
llevar a cabo.
Mediciones
basadas en
tcnicas
Procesos,
productos y
servicios
Ingeniera y
administracin
de informacin
Aplicar
Proveer
Mejorar
5.1 Introduccin
Modelo de MCCALL
(1977)

Mtricas de Calidad - Modelos
conocidos
Describe la calidad como
un concepto elaborado
mediante relaciones
jerrquicas entre factores
de calidad, en base a
criterios
Identifica una serie de
criterios, tales como
rastreabilidad, simplicidad,
capacidad de expansin, etc.
Los factores de calidad se
concentran en tres aspectos
importantes de un producto de
software: caractersticas
operativas, capacidad
de cambios y adaptabilidad a
nuevos entornos.
Las mtricas desarrolladas
estn relacionadas con los
factores de calidad y la relacin
que se establece se mide en
funcin del grado de
cumplimiento de los criterios.
5.1 Introduccin
Modelo de MCCALL
(1977)

Mtricas de Calidad - Modelos
conocidos
5.1 Introduccin
Modelo de MCCALL
(1977)

Mtricas de Calidad - Modelos
conocidos
Es difcil 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 mtricas para desarrollar
expresiones para todos los factores de acuerdo con la siguiente relacin:


Fq = c1 * m1 + c2 * m2 + + cn * mn


Donde Fq es un factor de calidad del software, cn son coeficientes de regresin y mn son las
mtricas que afectan al factor de calidad. Lo malo es que las mtricas definidas por McCall slo
pueden medirse de manera subjetiva. Las mtricas van en lista de comprobacin que se
emplean para apuntar atributos especficos del software. El esquema de puntuacin presentado
por McCall es una escala del 0 (bajo) al 10 (alto)
Coeficiente de relacin:
(c1 + c2 + + cn = 1 )
5.1 Introduccin
Modelo de FURPS (1987) Mtricas de Calidad - Modelos
conocidos
Modelo desarrollado por Hewlett-
Packard (HP)en 1987,
desarrollando un conjunto de
factores de calidad de software y
sus respectivos atributos.
Basado en el modelo de MCCALL.
Funcionalidad (Functionality),
usabilidad (Usability),
confiabilidad (Reliability),
desempeo (Performance) y
capacidad de soporte
(Supportability).
Se utilizan para establecer mtricas
de la calidad para todas las
actividades del proceso de
desarrollo de un software, inclusive
de un sistema de informacin.
5.1 Introduccin
Modelo de FURPS (1987) Mtricas de Calidad - Modelos
conocidos
5.1 Introduccin
Modelo de DROMEY (1996) Mtricas de Calidad - Modelos
conocidos
Resalta el hecho de que la calidad
del producto es altamente
determinada por los componentes
del mismo (incluyendo documentos
de requerimientos, guas de
usuarios, diseos, y cdigo),
Sugiere el uso de cuatro categoras
que implican propiedades de calidad,
que son: correctitud, internas,
contextuales y descriptivas.
5.1 Introduccin
Normas ISO 9000
ISO/IEC 9126
Mtricas de Calidad - Modelos
conocidos
5.1 Introduccin
Mtricas para pruebas:

Mtricas de cobertura de instrucciones y
ramas:
lleva al diseo de casos de prueba que
proporciona cobertura del programa

Mtricas relacionadas con los defectos:
se concentran en encontrar los defectos
Mtricas de efectividad de
prueba:
proporcionan un indicio en
tiempo real de la efectividad de
las pruebas aplicadas

Mtricas en el proceso:
mtricas relacionadas con el
proceso que se determinan a
medida que se aplican las
pruebas
5.2 Mtricas en el proceso de pruebas
Nombre:
Suficiencia de las pruebas
Propsito: Cuntas de los casos de prueba necesarios estn
cubiertos por el plan de pruebas.
Mtodo de aplicacin:
Contar las pruebas planeadas y comparar con el
nmero de pruebas requeridas para obtener una
cobertura adecuada.
Medicin, frmula:
X = A/B
A = nmero de casos de prueba en el plan
B = nmero de casos de prueba requeridos
Interpretacin: 0 <= X
Entre X se mayor, mejor la suficiencia.
Tipo de escala:
absoluta
Tipo de medida:
X = count/count
A = count
B = count
Fuente de medicin: A proviene del plan de pruebas
B proviene de la especificacin de requisitos
ISO/IEC 12207 SLCP:
Aseguramiento de Calidad
Resolucin de problemas
Verificacin
Audiencia: Desarrolladores
Mantenedores
Mtricas de
Fiabilidad
Madurez
Tolerancia a fallos
Recuperabilidad
Conformidad de
la fiabilidad

5.2 Mtricas durante el proceso de Pruebas
Nombre:
Completitud de implementacin funcional
Propsito:
Qu tan completa est la implementacin funcional.
Mtodo de aplicacin: Contar las funciones faltantes detectadas en la evaluacin y
comparar con el nmero de funciones descritas en la
especificacin de requisitos.
Medicin, frmula: X = 1 - A/B
A = nmero de funciones faltantes
B = nmero de funciones descritas en la especificacin de
requisitos
Interpretacin: 0 <= X <= 1
Entre ms cercano a 1, ms completa.
Tipo de escala:
absoluta
Tipo de medida: X = count/count
A = count
B = count
Fuente de medicin: Especificacin de requisitos
Diseo
Cdigo fuente
Informe de revisin
ISO/IEC 12207 SLCP: 6.6 Validacin
6.6 Revisin conjunta
Audiencia: Requeridores
Desarrolladores
Mtricas de
Funcionalidad
Adapatabilidad
Exactitud
Interoperabilidad
Seguridad
Conformidad de la
funcionalidad

5.2 Mtricas durante el proceso de pruebas
Nombre:
Funciones evidentes
Propsito: Qu proporcin de las funciones del sistemas son
evidentes al usuario.
Mtodo de aplicacin: Contar las funciones evidentes al usuario y comparar con
el nmero total de funciones.
Medicin, frmula: X = A/B
A = nmero de funciones (o tipos de funciones) evidentes
al usuario
B = total de funciones (o tipos de funciones)
Interpretacin: 0 <= X <= 1
Entre ms cercano a 1, mejor.
Tipo de escala:
absoluta
Tipo de medida: X = count/count
A = count
B = count
Fuente de medicin: Especificacin de requisitos
Diseo
Informe de revisin
ISO/IEC 12207 SLCP: Verificacin
Revisin conjunta
Audiencia: Requeridores
Desarrolladores
Mtricas de
Usabilidad
Entendibilidad
Aprendibilidad
Operatibilidad
Atractivo
Conformidad de la
usabilidad

5.2 Mtricas durante el proceso de Pruebas
Nombre:
Tiempo de respuesta
Propsito:
Cul es el tiempo estimado para completar una tarea.
Mtodo de aplicacin:
Evaluar la eficiencia de las llamadas al SO y a la aplicacin.
Estimar el tiempo de respuesta basado en ello. Puede medirse:
Todo o partes de las especificaciones de diseo.
Probar la ruta completa de una transaccin.
Probar mdulos o partes completas del producto.
Producto completo durante la fase de pruebas.
Medicin, frmula:
X = tiempo (calculado o simulado)
Interpretacin:
Entre ms corto, mejor.
Tipo de escala:
proporcin
Tipo de medida:
X = time
Fuente de medicin: Sistema operativo conocido
Tiempo estimado en llamadas al sistema
ISO/IEC 12207 SLCP: Verificacin
Revisin conjunta
Audiencia: Desarrolladores
Requeridores
Mtricas de Eficiencia
Comportamiento en el tiempo
Utilizacin de recursos
Conformidad de la eficiencia

5.2 Mtricas durante el proceso de Pruebas
Nombre:
Registrabilidad de cambios
Propsito: Se registran adecuadamente los cambios a la
especificacin y a los mdulos con comentarios en el
cdigo?
Mtodo de aplicacin: Registrar la proporcin de informacin sobre cambios a los
mdulos
Medicin, frmula: X = A/B
A = nmero de cambios a funciones o mdulos que tienen
comentarios confirmados
B = total de funciones o mdulos modificados
Interpretacin: 0 <= X <= 1
Entre ms cercano a 1, ms registrable.
0 indica un control de cambios deficiente o pocos cambios y
alta estabilidad.
Tipo de escala:
absoluta
Tipo de medida: X = count/count
A = count
B = count
Fuente de medicin: Sistema de control de configuraciones
Bitcora de versiones
Especificaciones
ISO/IEC 12207 SLCP: Verificacin
Revisin conjunta
Audiencia: Desarrolladores
Mantenedores
Requeridores
Mtricas de
Mantenibilidad
Analizabilidad
Cambiabilidad
Estabilidad
Examinabilidad
Conformidad de la
mantenibilidad

5.2 Mtricas durante el proceso de Pruebas
Nombre: Conformidad de transportabilidad
Propsito:
Qu tan conforme es la transportabilidad del producto con
regulaciones, estndares y convenciones aplicables.
Mtodo de aplicacin: Contar los artculos encontrados que requieren conformidad y
comparar con el nmero de artculos en la especificacin que
requieren conformidad.
Medicin, frmula:
X = A/B
A = nmero de artculos implementados de conformidad
B = total de artculos que requieren conformidad
Interpretacin: 0 <= X <= 1
Entre ms cercano a 1, ms completa.
Tipo de escala: absoluta
Tipo de medida: X = count/count
A = count
B = count
Fuente de medicin: Especificacin de conformidad y estndares, convenciones y
regulaciones relacionados.
Diseo
Cdigo fuente
Informe de revisin
ISO/IEC 12207 SLCP: Verificacin
Revisin conjunta
Audiencia: Requeridores
Desarrolladores
Mtricas de
Transportabilidad
Adaptabilidad
Instalabilidad
Coexistencia
Remplazabilidad
Conformidad de la
transportabilidad

El Reto de Medir el Software
La medicin asigna nmeros o smbolos a atributos de entidades del mundo
real
Para conseguirlo se necesita un modelo de medicin que comprenda un
conjunto consistente de reglas.
Durante dcadas, investigadores han intentado desarrollar una sola mtrica
que proporcione una medida completa de la complejidad del software.
Fenton le bautiz a esta investigacin como la bsqueda de lo imposible.
5.3 Mtricas Para Pruebas
La mayora de las mtricas propuestas se concentran en el
proceso de prueba
No en las caractersticas tcnicas de las pruebas mismas.
Los responsables de las pruebas deben fiarse de las
mtricas de anlisis, diseo y de cdigo para que le guen
en el diseo y ejecucin de los casos de pruebas.



Tipos de Mtricas para Pruebas
Mtrica que ayuda a determinar el nmero de
pruebas requeridas en los distintos niveles de la
prueba
Mtricas para cubrir la prueba de un componente
dado.

La mtrica bang puede proporcionar una indicacin del nmero de
casos de prueba necesarios para examinar las medidas
primitivas.
El nmero de primitivas funcionales (Pfu), elementos de datos
(DE), objetos (OB), relaciones (RE), estados (ES) y transiciones
(TR) pueden emplearse para predecir el nmero y tipos de
pruebas de software de caja negra y blanca.

Las mtricas del diseo arquitectnico proporcionan informacin
sobre la facilidad o dificultad asociada con la prueba de
integracin
La complejidad ciclomtica se encuentra en el ncleo de las
pruebas de caminos bsicos, un mtodo de diseo de casos de
pruebas, adems esta mtrica tambin puede usarse para elegir
mdulos como candidatos para pruebas ms profundas.
Los mdulos con gran complejidad ciclomtica tienen ms
probabilidad de tendencia a errores que los mdulos con menor
complejidad


El esfuerzo de las pruebas tambin se puede
estimar usando mtricas obtenidas de medidas de
Halstead.
Usando la definicin del volumen de un programa
V y el nivel del programa NP, el esfuerzo de la
ciencia del software, e puede calcularse como:
E=V/NP (19.13b)

A medida que se van haciendo las pruebas,
tres medidas diferentes proporcionan una
indicacin de la completacin de las
pruebas.
Amplitud de las pruebas.- representa
cuantos requisitos se han probado y
proporciona una indicacin de la
completacin del plan de pruebas.
Profundidad de las pruebas.- es una
medida del porcentaje de los caminos
bsicos independientes probados en
relacin al nmero total de estos.
Finalmente una vez que se van haciendo las
pruebas, se pueden emplear los perfiles de fallos
para dar prioridad y categorizar los errores
descubiertos
La prioridad indica la severidad del problema
Las categoras de fallos proporcionan una
descripcin para pode llevar anlisis estadsticos.

5.3.1 Mtricas del Mantenimiento
El estndar IEEE 982.1-1998 sugiere un ndice de
madurez.
Este proporciona una indicacin de la estabilidad
de un producto software (basado en los cambios
que ocurren con cada versin del producto):
M
T
=nmero total de mdulos de la versin actual
F
C
= nmero de mdulos en la versin actual que se
han cambiado.

F
a
=nmero de mdulos en la versin actual que se han aadido
F
d
= nmero de mdulos de la versin anterior que se han borrado
en la versin actual.
IMS=[M
T
-(F
a
+ F
c
+ F
d
)]/M
T
(19.15)
A medida que se aproxima a 1.0 el producto empieza a
estabilizarse

Cmo se mide la
calidad en el software?



Qu es la calidad en el software?Se puede medir?Cmo?
Cuando decimos que para nosotros la calidad es muy importante, a
que nos referimos?


Directivos y personal de Mrketin dan ms importancia al nmero de caractersticas que tiene un software que a la calidad,
porque la calidad no se puede poner en un anuncio o en una oferta.
Algunos directivos al mando de empresas que construyen software caen en el error de pensar en la produccin de
software desde los parmetros habituales en otras industrias. La produccin de software es muy diferente, es un proceso
creativo no un proceso manufacturero. La principal diferencia cuando 'fabricamos' software es que la calidad no es
opcional, no puedes elegir fabricar software de baja calidad y rebajar el precio. Puedes restarle funcionalidad, pero no
calidad.
Nadie recuerda a quien hizo un buen software (de calidad), pero nadie olvida el que fallaba constantemente (Te acuerdas
de los pantallazos azules del w95?)
Paradjicamente, y esto es un hecho, es que aadir calidad a nuestro software, al contrario de lo que puede parecer a
primera vista, reduce los costes de desarrollo y acorta los plazos.










Vamos a intentar medir la calidad del
software!!


Primero vamos a intentar identificar los factores que desde
un punto de vista externo definen la calidad del software,
esto no se refiere a los procesos internos de desarrollo,
como pruebas unitarias, gestin de cambios, calidad del
cdigo, no. Se refieren a lo que se percibe, una vez el
software est terminado, implantado y en produccin, lo que
nota un usuario. Pensemos (como ejemplo para evaluar la
calidad) en un producto software..., uno de los primeros que
desarrollamos o probamos, as veremos mejor su evolucin
y evaluaremos la calidad teniendo en cuenta factores
temporales.

Satisfaccin del cliente (se suelen hacer encuestas para
obtener este dato)
Interfaz de usuario (usabilidad, accesibilidad, facilidad de manejo,
curva de aprendizaje, diseo...)
Rendimiento de la aplicacin, Seguridad, Despliegue,
Actualizaciones, Integracin con sistemas...

Nmero de bugs en produccin (bugs encontrados y la
importancia de los mismos, se podra incluir en
satisfaccin del cliente)

Rentabilidad econmica (%, precio de venta - coste de
desarrollo)
Este factor no es relevante para el usuario, pero tiene mucha
informacin subliminal y por eso se debe incluir. Esta muy ligada
la rentabilidad a la calidad, por muchas cosas como (la buena
estimacin, buena planificacin, gestin, previsin, pruebas,
buena arquitectura, buen cdigo, pocos bugs, aplicacin modular
y bien preparada para el cambio...) por ello se incluye como factor
a tener en cuenta, aunque no le afecte al cliente directamente, si
indirectamente, ya que si el software es rentable, el cliente
obtendr un mejor servicio, soporte, mantenimiento... en definitiva
un buen producto...
Tiempo de vida por cliente (aos que el software
est funcionando)
El usuario quiere algo que le satisfaga y si por ejemplo en el
banco de Cuenca tienen una aplicacin Cobol, desarrollada
hace 15 aos, que les satisface las necesidades actuales,
desde luego que es un aplicativo con calidad. Al igual que un
coche, de hecho es muy tpico ver mercedes de hace 20
aos rodando a diario por las carreteras.

Nmero de clientes (clientes que tiene el
software implantado y en produccin)
Otro factor importante es el nmero de clientes que tiene un
software, por ejemplo existen productos software que estn
muy estandarizados (SAP, Subversion, PhotoShop, Office...)
es software muy popular, muy testeado, en diferentes
entornos y condiciones, eso es un sntoma de calidad.

Una ves que conocemos los Factores
vamos a medir la calidad pero Cmo
Medimos la calidad en Software?

El concepto de calidad encuentra muchas definiciones posibles. La ms tradicional se
refiere al conjunto de cualidades de una persona o cosa. Sin embargo, las definiciones
vinculadas a las actividades industriales hablan de la medida en que un producto o
servicio satisface los requerimientos de una funcin dada. De todas formas, el concepto
es subjetivo. Por ejemplo, un producto que cumple con las expectativas de un usuario
puede haber sido elaborado sin conformidad con ciertas normas de fabricacin. Por eso,
la calidad siempre depende del punto de vista, pero, en general, involucra el
cumplimiento de un conjunto de exigencias. Otros aspectos a tener cuenta pueden ser
la adecuacin al uso y la ausencia de deficiencias.

Entonces, qu es la calidad de un producto software?
Existen dos enfoques posibles:

Calidad funcional. Refleja en qu medida el software cumple
con o se ajusta a un determinado diseo, basado en
requerimientos funcionales. stos abarcan las actividades del
software que involucran procesamiento de datos de entrada.
Calidad estructural. Refleja en qu medida el software
cumple con los requerimientos no funcionales, como
rendimiento, capacidad de mantenimiento o escalabilidad.

El estndar ISO/IEC 9126 presenta la calidad del software como un conjunto de seis
caractersticas globales:

- Funcionalidad. Las funciones del software son aquellas que buscan satisfacer las
necesidades del usuario.
- Confiabilidad. La capacidad del software de mantener su rendimiento bajo ciertas
condiciones durante cierto perodo de tiempo.
- Usabilidad. Basada en el esfuerzo necesario para utilizar el software por parte de un
grupo de usuarios.
- Eficiencia. Basada en la relacin entre el nivel de rendimiento del software y el
volumen de recursos utilizado, bajo ciertas condiciones.
- Capacidad de mantenimiento. Basada en el esfuerzo necesario para realizar
modificaciones especficas.
- Portabilidad. Basada en la capacidad del software para ser transferido de un entorno
a otro.