Transcripción de Metricas para el proceso de pruebas de Software

Introducción
Para obtener un software de calidad es necesario medir el proceso de software (Avances, tamaño,
costos, etc,).
Métricas
Las métricas determinan, mediante estadísticas en la experiencia, el avance del software y el
cumplimiento de parámetros requeridos.
Métricas para Pruebas

¿Qué se utiliza en las pruebas?

Durante la etapa de pruebas se utilizarán la métrica de cobertura, madurez y profundidad de las
pruebas, el porcentaje de defectos por tipo, la densidad de defectos, la métrica para el control de
pruebas de unidad, la tasa de propagación de defectos, la métrica para pruebas de camino básico y
el índice de madurez del software.
Métricas para el proceso de Pruebas de Software
Estas mediciones se realizan mediante las
métricas
que le dan un valor a los diferentes aspectos del desarrollo de software.
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.
Las pruebas al software se realizan con el objetivo de encontrar y documentar los defectos en la
calidad del software, aconsejar en base a la calidad determinada, validar y probar las hipótesis
hechas en el diseño y la especificación de requerimientos mediante una demostración concreta
Medida de amplitud o cobertura de las pruebas
Proporciona un indicador de cuantos requisitos se han probado del número total de ellos. Indica la
complexión del plan de pruebas
La cobertura de las pruebas indica cómo se van cumpliendo los casos de prueba especificados, por
tanto una mayor cobertura de las pruebas indica un buen desarrollo de las pruebas
La cobertura de las pruebas se calcula como:

Donde:
• CP: valor de la cobertura de las pruebas.
• CPE: número de casos de prueba que han sido ejecutados.
• CPR: número de casos de prueba a ejecutar requeridos para cubrir todos los requerimientos.

Profundidad de las pruebas

Porcentaje de los caminos básicos independientes probados en relación al total de ellos sumando la
complejidad ciclomática de todos los módulos del programa.
La métrica para pruebas del camino básico se calcula como:
Donde:
• PCB: porcentaje de caminos básicos.
• P: número de pruebas diseñadas.
• v(G): complejidad ciclomática calculada anteriormente.

Madurez de las pruebas

Indicador del buen desempeño del flujo de trabajo de pruebas, no sólo se enfoca en la completitud
de los casos de prueba según los definidos para cubrir los requerimientos, sino que también
comprende los casos de pruebas que han obtenido resultados satisfactorios.
La madurez de las pruebas se calcula como:
Donde:
• MP: valor de la madurez de las pruebas.
• CPS: número de casos de prueba que han dado resultados satisfactorios.
• CPR: número de casos de prueba diseñados para cubrir todos los requerimientos.

Perfiles de fallos
Se emplean para categorizar y priorizar los errores. La prioridad indica la severidad del problema.
Las categorías de fallos proporcionan una descripción del error para realizar análisis estadísticos de
errores.

El porcentaje de defectos por tipo permite categorizar los fallos porque identifica los tipos de
defectos más comunes que puedan presentarse en cualquier etapa del desarrollo del software.
El porcentaje de defectos por tipo se calcula como:
Donde:
• %DT: porcentaje de defectos por tipo.
• NDT: es el número de defectos por tipo.
• TDI: número total de defectos identificados en una etapa del proyecto.

La densidad de defectos ofrece una medida sobre la proporción de defectos con respecto a la
cantidad de elementos de especificación.
Densidad de defectos
Esta métrica permite realizar análisis estadísticos al finalizar las pruebas para valorar la integridad y
madurez del software analizado.
La densidad de defectos se calcula como:
Donde:
• DD: densidad de defectos.
• TD: número total de defectos encontrados durante las pruebas.
• CER: número de elementos de especificación revisados.

Es recomendable para una alta calidad del software que la densidad de defectos tenga un valor
mínimo.

• La mayoría de las métricas se concentran en el proceso y no en el producto.

• Debe apoyarse en las métricas del análisis y del diseño.
• Las métricas basadas en la función pueden utilizarse para predecir el esfuerzo global de las
pruebas.
• La métrica Bang puede proporcionar una indicación del numero de los casos de prueba necesarios
para examinar una media primitiva(burbuja del DFD).
• A medida que avanzan las pruebas, hay métricas que indican la completitud de las mismas:
- Amplitud de las pruebas(cuantos requisitos se han probado).
- Profundidad de las pruebas(% de los caminos básicos probados).
- Perfiles de fallo(para dar prioridad y categorizar los errores encontrados).
• Ayudan a diseñar casos de prueba efectivos y evaluar la eficacia de las pruebas.
 • Métricas de cobertura de instrucciones y ramas
• Métricas relacionadas con los defectos
• Efectividad de la prueba
• Métricas en el proceso
• En muchos modelos las métricas de un modelo pueden aplicarse en actividades posteriores a la
ingeniería del software.
Métricas para las pruebas
Se emplea para desarrollar una indicación del tamaño del software a implementar como
consecuencia del diseño del modelo de análisis. Desarrollada por el marco es una indicación
independiente de la implementación del tamaño del sistema. El desarrollador del software debe
evaluar un conjunto de primitivas.

Métricas de calidad de software

La generación de conocimiento necesita un poso de calidad que se extiende desde el dato
mismo hasta el programa desarrollado para interactuar con la información. Las métricas
de calidad de software permiten monitorizar un producto para determinar su nivel de calidad,
aunque, el seguimiento que este tipo de medidas permiten llevar a cabo brinda
la oportunidad de conocer muchas más cosas de una solución.

Beneficios y ejemplos del uso de métricas de calidad de

software
La mala calidad de la información y de software impacta negativamente en el negocio a
diferentes niveles:

 Disminuye ingresos y aumenta el gasto.

 Incrementa el riesgo.

 Provoca una reducción de la confianza, tanto dentro como fuera de la organización.

Un enfoque proactivo tanto del gobierno de la información como de la data quality

permite la identificación temprana de errores o defectos que pueden ser corregidos a
tiempo, eliminando de raíz problemas mayores. Los efectos positivos empiezan a notarse
y sus beneficios aumentan en un ciclo de mejora continua propiciado por el control de
las métricas de calidad de software.

Esta monitorización facilita el evaluar:

 La calidad del producto.

 El rendimiento del equipo de desarrollo.

 La justificación del uso de nuevas herramientas o soluciones.

 Los resultados obtenidos a partir de la incorporación del software a los procesos y
operaciones.

Para conseguir llegar al nivel de evaluación, es preciso contar con datos relevantes, precisos y
actualizados sobre diferentes áreas, que faciliten una perspectiva global de la solución. Así,
las métricas de calidad de software pueden aplicarse a diferentes contextos, como:

1. El proyecto: son las que facilitan la gestión del riesgo permitiendo tomar el pulso a la
iniciativa de desarrollo desde su inicio.
2. El producto: están enfocadas a medir las características del software y todos los
entregables que lo acompañan, fruto del proyecto de desarrollo, como modelos,
componentes adicionales y documentación.
3. El proceso: tienen por objeto identificar mejores prácticas para su exportación a futuros
proyectos y, para conseguirlo, recopilan datos de distintas iniciativas a lo largo de un
periodo de tiempo determinado.

Sin embargo, a la hora de centrarse en la solución en sí, existen algunas métricas de calidad
de software imprescindibles, como las que tienen que ver con los cinco siguientes criterios:

A/ Métricas de exactitud: intentan aportar información sobre la validez y precisión del

software y su estructura, incluyendo la etapa de despliegue, pero también la de pruebas y la
función de mantenimiento.

B/ Métricas de rendimiento: a través de ellas se consigue medir el desempeño del software,

tanto de cada uno de sus módulos, como del sistema al completo.

C/ Métricas de usabilidad: hay que descartar la complejidad y buscar una solución intuitiva y
user-friendly. este tipo de métricas de calidad de software ayudan a determinar si la solución
cumple con dichos requisitos.

D/ Métricas de configuración: las limitaciones, el estilo de código y todos los datos relativos
al desarrollo y cualidades del producto se verán evaluados en base a estas métricas.

E/ Métricas de eficiencia: minimización de latencias, velocidad de respuesta, capacidad, es

un enfoque similar al de la productividad, pero con un matiz un poco distinto, que, añadido a
aquél, aporta una visión mucho más completa de la solución.

De esta forma, evaluando el software a través de diferentes ópticas y en base a

continuas mediciones, se puede ganar en alineación con el objetivo de calidad que,
poco a poco, se irá sofisticando y para lograr alcanzar cotas superiores.
Métricas para el modelo de diseño.

Estas métricas cuantifican los atributos del diseño de manera tal que le permiten al ingeniero de
software evaluar la calidad del diseño, la métrica incluye:

 Métricas arquitectónicas. Proporcionan un indicio de la calidad del diseño arquitectónico.

 Métricas al nivel de componente. Mide la complejidad de los componentes del software y
otras características que impactan la calidad.
 Métricas de diseño de la interfaz. Se concentran principalmente en la facilidad de uso.
 Métricas especializadas en diseño orientado a objetos. Miden características de clases,
además de las correspondientes a comunicación y colaboración.

Métricas arquitectónicas.

Consideradas métricas de caja negra ya que no requieren ningún conocimiento del

funcionamiento interno de un componente de software en particular.

Card y Glass dan tres medidas de la complejidad del diseño del software:

 Complejidad Estructural en el caso de arquitecturas jerárquicas

 Complejidad de datos indica complejidad de la interfaz interna de un módulo
 Complejidad del sistema es la suma de las complejidades estructural y de datos.

Métricas al nivel de componente.

Métricas de diseño de la interfaz.

Métricas especializadas en diseño orientado a objetos.

Whitmire describe nueve características distintivas y mensurables de un Diseño OO:

 Tamaño
 Complejidad
  Acoplamiento
 Su ciencia
 Grado de avance
 Cohesión
 Primitivismo
 Similitud
 Volatilidad

El paradigma objetivo/pregunta/métrica (OPM) desarrollado por Basili y Weiss es considerado

una técnica para identificar significativa métricas las cuales son aplicables en cualquier parte
del proceso de software; destaca la necesidad de:

1. Establecer un objetivo de medición que sea específico para la actividad del proceso o las
características del producto que se está evaluando.
2. Definir un conjunto de preguntas que deben responderse con el n de alcanzar el objeto.
3. Identificar métricas bien formadas que ayuden a responder esas preguntas.

Calidad General
Calidad del Software es el cumplimiento de los requisitos de funcionalidad y desempeño
explícitamente establecidos, de los estándares de desarrollo explícitamente documentados y
de las características implícitas que se esperan de todo software desarrollado
profesionalmente.
Con esta definición se destacan tres puntos importantes:
1. Los requisitos del software son la base de las medidas de calidad. La falta de concordancia
con estos requisitos es una falta de calidad.

2. Los estándares especificados definen un conjunto de criterios de desarrollo que guían la

ingeniería del software. Si no se siguen los criterios, el resultado será, casi seguramente, la
falta de calidad.
3. A menudo se soslaya un conjunto de requisitos implícitos. Si el software cumple con sus
requisitos explícitos pero no con los implícitos, la calidad del software estará en duda.

Factores de Calidad de McCall

Estos factores se dividen en dos grupos muy importantes:
1. Los que se miden directamente.
2. Los que solo se miden indirectamente. McCall, Richards y Walters propusieron unos
factores los cuales se concentran en tres aspectos importantes de un producto de software:
sus características operativas, su capacidad para experimentar cambios y su capacidad para
adaptarse a nuevos entornos.

Corrección: Grado en que cumple el programa con su especificación y satisface los objetivos
que propuso el cliente.
Contabilidad: Grado en que se esperaría que un programa desempeñe su función con la
precisión requerida.
Eficiencia: Cantidad de código y de RR. De cómputo necesarios para que un programa
realice su función.

Integridad: Grado de control sobre el acceso al S/W o los datos por parte de personas no
autorizadas.

Facilidad de uso: Esfuerzo necesario para prender, operar y preparar los datos de entrada de
un programa e interpretar la salida.

Facilidad de mantenimiento: Esfuerzo necesario para localizar y corregir un error en un

programa.

Flexibilidad: Esfuerzo necesario para modificar un programa en operación.

Facilidad de prueba: Esfuerzo que demanda probar un programa con el fin de asegurar que
realiza su función.

Portabilidad: Esfuerzo necesario para transferir el programa de un entrono de hardware o

software a otro.

Facilidad de reutilización: grado en que un programa puede reutilizarse en otras

aplicaciones.

Interoperabilidad: Esfuerzo necesario para acoplar un sistema con otro.

Muchas de estas métricas solo se miden subjetivamente.

Factores de calidad del estándar ISO 9126

Se desarrolló como un intento por identificar los atributos de calidad para el software de
computadora. El estándar identifica 6 puntos:
-Funcionalidad.
-Confiabilidad.
-Facilidad de uso.
-Eficiencia.
-Facilidad de mantenimiento.
-Portabilidad.
Un marco conceptual para las métricas del producto
Medidas, métricas e indicadores Aunque estos tres términos suelen utilizarse
de manera intercambiable, es necesario
especificar las diferencias entre éstos.
Medida Proporciona indicación cuantitativa de la
extensión, la cantidad, la dimensión, la
capacidad o el tamaño de algún atributo de un
producto o proceso.

Medición Acto de determinar una medida.

Métrica Medida cuantitativa del grado en que un
sistema, componente o proceso posee un
atributo determinado.
Un ingeniero de software recopila medidas y
desarrolla métricas para obtener los
indicadores.
Indicador Métrica o combinación de métricas que
proporcionan conocimientos. Estos
conocimientos le permiten al jefe de proyecto
o a los ingenieros de software ajustar el
proceso, el proyecto o el producto para que
las cosas mejores.
Principios de medición
Roche sugiere un proceso de medición al que caracterizan cinco actividades:

 Formulación. Derivación de medidas y métricas apropiadas para la representación del

software que se considera.
 Recolección. Mecanismo con que se acumulan los datos necesarios para derivar las
métricas formuladas.
 Análisis. Cálculo de las métricas y la aplicación de herramientas matemáticas.
 Interpretación. Evaluación de las métricas en un esfuerzo por conocer mejor la calidad
de la representación.
 Retroalimentación. Recomendaciones derivadas de la interpretación de las métricas del
producto transmitidas al equipo del software.
Existen principios que son representativos de muchos otros que podrían proponerse para
caracterizar y validar las métricas:
 Una métrica debe tener propiedades matemáticas deseables.
  Cuando una métrica representa una característica de software que aumenta cuando se
presentan rasgos positivos o que disminuye al encontrar rasgos indeseables, el valor de
la métrica debe aumentar o disminuir en el mismo sentido.
 Cada métrica debe validarse empíricamente en una amplia variedad de contextos antes
de publicarse o aplicarse a la toma de decisiones.

MÉTRICAS PARA EL CÓDIGO FUENTE

Estás métricas asignadas como cuantitativas por Halstead, se derivan después de que se ha
generado el código o se estima una vez que el diseño esté completo.

Un programa está compuesto de “tokens”, las instrucciones del lenguaje, los identificadores,
constantes, operadores delimitadores de comentario y signos especiales del mismo. De esta forma
se obtiene una medida más realista de la cantidad de información contenida en el código fuente.

Las medidas son:

● 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 ocurrencias de operadores

● N2: el número total de ocurrencias de operandos

Aclaración:

● Los operadores son las palabras reservadas del lenguaje, tales como IF-THEN, READ, FOR,...; los
operadores aritméticos +, -, *,..... los de asignación y los operadores lógicos AND, EQUAL TO,....

● Los operandos son las variables, literales y las constantes del programa.

Longitud (N):

● Se calcula como, N = N1 + N2

● Es una simple medida del tamaño de un programa.

● Cuanto más grande sea el tamaño de N, mayor será la dificultad para comprender el programa y
mayor el esfuerzo para mantenerlo.

Volumen (V):
● Da un peso extra al número de operadores y operandos únicos. Por ejemplo, si dos programas
tienen la misma longitud N pero uno tiene mayor número de operadores y operandos únicos, que
naturalmente lo hacen más difícil de entender y mantener, este tendrá un mayor volumen.

● Se calcula como V = N x log2(n) donde n = n1 + n2

Dificultad (D):

● Para definir la dificultad D del programa, se usa la fórmula siguiente:

D = (n1 * N2) / (n2 *2).

Esfuerzo (E):

● El esfuerzo es otra medida estudiada por Halstead que ofrece una medida del trabajo requerido
para desarrollar un programa.

● Desde el punto de vista del mantenimiento, el esfuerzo se puede interpretar como una medida
del trabajo requerido para comprender un software ya desarrollado.

● La fórmula es la siguiente: E = D * V ó V/L

● Volumen mínimo (L): L = 2/n1 * n2/N2

Por ejemplo, consideremos el siguiente trozo de programa:

if (N < 2)

A = B * N;

System.out.println("El resultado es : " + A);

A partir de aquí se deduce:

● Operadores Únicos n1 = 6 (if, {}, system.out.println, =, *, <)

● Ocurrencias de Operadores N1 = 6 (if, {}, system.out.println, =, *, <)

● Operandos Únicos n2 = 4 (N, A, B, 2)

● Ocurrencias de Operandos N2 = 6 (N, 2, A, B, N, A)

● Longitud (N) = 6 + 6 = 12

● Volumen (V) = 27.509 * log2(6+4) = 91.382

● Dificultad (D) = (6 * 6)/(4 * 2) = 4.5

● Esfuerzo (E) = 91.382 * 4.5 = 411.219

las métricas [de complejidad del software] son simplemente medidas cuantitativas de
ciertas características de un proyecto de desarrollo. Pueden medir alguno de los
siguientes objetos:
a. Productos (como el código o la documentación).
b. El proceso de desarrollo como tal (aspectos de las actividades del desarrollo).
c. El dominio del problema (como las telecomunicaciones, los sistemas de tratamiento de
información, y el control de procesos).
d. Las características ambientales (como las personas, las organizaciones y las
herramientas)."

Complejidad ciclomática de McCabe

La complejidad ciclomática se basa en el recuento del número de caminos lógicos individuales

contenidos en un programa. Para calcular la complejidad del software, Thomas McCabe utilizó la
teoría y flujo de grafos. Para hallar la complejidad ciclomática, el programa se representa como un
grafo, y cada instrucción que contiene, un nodo del grafo. Las posibles vías de ejecución a partir de
una instrucción (nodo) se repesentan en el grafo como aristas. Por ejemplo, el código que se
muestra a continuación con 2 sentencias selectivas anidadas genera el siguiente grafo:

1 if (condicion){ 2 if (condicion){ 3 A; B; } else { 4 C; D; 5 } 6 }

Si se realizase el grafo, se observaría que se encuentran 3 caminos posibles para llegar de la

sentencia 1 a la sentencia 6:

Camino 1 (si ambos IF’s son verdad): Sentencias 1, 2, 3, 6

Camino 2 (si el primer IF es verdad y el segundo es falso): Sentencias 1, 4,6

Camino 3 (si el primer IF es falso): Sentencias 1, 6

Este programa tiene una complejidad ciclomática de 3.

La complejidad ciclomática se puede calcular de otras maneras. Se puede utilizar la fórmula:

v(G) = e - n + 2 v(G) = e - n + 2

donde e representa el número de aristas y n el número de nodos.

Otra forma de calcular la complejidad ciclomática consiste en aplicar la siguiente fórmula:

v(G) = número de regiones cerradas en el grafo + 1

 Tablas de Métricas
Organizadas por característica y subcaracterística, cada métrica contiene:

1. Nombre 6. Tipo de escala

2. Propósito 7. Tipo de medida
3. Método de aplicación 8. Fuente de medición
4. Medidad, fórmula y cómputo de datos
9. Referencia a ISO/IEC 12207 SLCP
5. Interpretación del valor medido 10. Audiencia

1. Métricas de Funcionalidad
1. Adecuidad
2. Exactidud
3. Interoperabilidad
4. Seguridad
5. Conformidad de la funcionalidad

1.1. Ejemplo de Métrica de Adecuidad

Nombre: Completitud de implementación funcional
Propósito: Qué tan completa está la implementación funcional.
Método de Contar las funciones faltantes detectadas en la evaluación y comparar con el número de funciones
aplicación: descritas en la especificación de requisitos.
Medición, fórmula: X = 1 - A/B
A = número de funciones faltantes
B = número de funciones descritas en la especificación de requisitos
Interpretación: 0 <= X <= 1
Entre más cercano a 1, más completa.
Tipo de escala: absoluta
Tipo de medida: X = count/count
A = count
B = count
Fuente de medición: Especificación de requisitos
Diseño
Código fuente
Informe de revisión
ISO/IEC 12207 6.6 Validación
SLCP: 6.6 Revisión conjunta
Audiencia: Requeridores
Desarrolladores

2. Métricas de Fiabilidad
1. Madurez
2. Tolerancia a fallos
3. Recuperabilidad
4. Conformidad de la fiabilidad

2.1. Ejemplo de Métrica de Madurez

Nombre: Suficiencia de las pruebas
Propósito: Cuántas de los casos de prueba necesarios están cubiertos por el plan de pruebas.
Método de Contar las pruebas planeadas y comparar con el número de pruebas requeridas para obtener una
aplicación: cobertura adecuada.
Medición, fórmula: X = A/B
A = número de casos de prueba en el plan
B = número de casos de prueba requeridos
Interpretación: 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 medición: A proviene del plan de pruebas
B proviene de la especificación de requisitos
ISO/IEC 12207 Aseguramiento de Calidad
SLCP: Resolución de problemas
Verificación
Audiencia: Desarrolladores
Mantenedores

3. Métricas de Usabilidad
1. Entendibilidad
2. Aprendibilidad
3. Operatibilidad
4. Atractivo
5. Conformidad de la usabilidad

3.1. Ejemplo de Métrica de Entendibilidad

Nombre: Funciones evidentes
Propósito: Qué proporción de las funciones del sistemas son evidentes al usuario.
Método de aplicación: Contar las funciones evidentes al usuario y comparar con el número total de funciones.
Medición, fórmula: X = A/B
A = número de funciones (o tipos de funciones) evidentes al usuario
B = total de funciones (o tipos de funciones)
Interpretación: 0 <= X <= 1
Entre más cercano a 1, mejor.
Tipo de escala: absoluta
Tipo de medida: X = count/count
A = count
B = count
 Fuente de medición: Especificación de requisitos
Diseño
Informe de revisión
ISO/IEC 12207 SLCP: Verificación
Revisión conjunta
Audiencia: Requeridores
Desarrolladores

4. Métricas de Eficiencia
1. Comportamiento en el tiempo
2. Utilización de recursos
3. Conformidad de la eficiencia

4.1. Ejemplo de Métrica de Comportamiento

en el Tiempo
Nombre: Tiempo de respuesta
Propósito: Cuál es el tiempo estimado para completar una tarea.
Método de aplicación: Evaluar la eficiencia de las llamadas al SO y a la aplicación.
Estimar el tiempo de respuesta basado en ello. Puede medirse:
 Todo o partes de las especificaciones de diseño.
 Probar la ruta completa de una transacción.
 Probar módulos o partes completas del producto.
 Producto completo durante la fase de pruebas.
Medición, fórmula: X = tiempo (calculado o simulado)
Interpretación: Entre más corto, mejor.
Tipo de escala: proporción
Tipo de medida: X = time
Fuente de medición: Sistema operativo conocido
Tiempo estimado en llamadas al sistema
ISO/IEC 12207 SLCP: Verificación
Revisión conjunta
Audiencia: Desarrolladores
Requeridores

5. Métricas de Mantenibilidad
1. Analizabilidad
2. Cambiabilidad
3. Estabilidad
4. Examinabilidad
5. Conformidad de la mantenibilidad

5.2. Ejemplo de Métrica de Cambiabilidad

Nombre: Registrabilidad de cambios
 Propósito: ¿Se registran adecuadamente los cambios a la especificación y a los módulos con comentarios en el
código?
Método de
Registrar la proporción de información sobre cambios a los módulos
aplicación:
Medición, fórmula: X = A/B
A = número de cambios a funciones o módulos que tienen comentarios confirmados
B = total de funciones o módulos modificados
Interpretación: 0 <= X <= 1
Entre más cercano a 1, más 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 medición: Sistema de control de configuraciones
Bitácora de versiones
Especificaciones
ISO/IEC 12207 Verificación
SLCP: Revisión conjunta
Audiencia: Desarrolladores
Mantenedores
Requeridores

6. Métricas de Transportabilidad
1. Adaptabilidad
2. Instalabilidad
3. Coexistencia
4. Remplazabilidad
5. Conformidad de la transportabilidad

6.5. Ejemplo de Conformidad de la

Transportabilidad
Nombre: Conformidad de transportabilidad
Propósito: Qué tan conforme es la transportabilidad del producto con regulaciones, estándares y convenciones
aplicables.
Método de Contar los artículos encontrados que requieren conformidad y comparar con el número de artículos en
aplicación: la especificación que requieren conformidad.
Medición, fórmula: X = A/B
A = número de artículos implementados de conformidad
B = total de artículos que requieren conformidad
Interpretación: 0 <= X <= 1
Entre más cercano a 1, más completa.
Tipo de escala: absoluta
Tipo de medida: X = count/count
A = count
B = count
 Fuente de Especificación de conformidad y estándares, convenciones y regulaciones relacionados.
medición: Diseño
Código fuente
Informe de revisión
ISO/IEC 12207 Verificación
SLCP: Revisión conjunta
Audiencia: Requeridores
Desarrolladores

Consideraciones al Utilizar las Métricas

1. Interpretación de las mediciones
 Diferencia entre conextos de pruebas y de uso.
 Validez de resultados: procedimientos, fuentes de evaluación, validación de datos.
 Equilibrio de recursos de medición.
 Especificación correcta.
2. Validación de las métricas
 Propiedades deseables: confiable, repetible, reproducible, disponible, indicable, correcta, con significado.
 Demostración de validez: correlación, rastreo, consistencia, predictibilidad, discriminación.
 7 propiedades deseables en las métricas
 7 propiedades deseables en las métricas
3. Uso de métricas para estimación y predicción
4. Detección de desviaciones y anomalías
5. Presentación de resultados de medición
 Gráficas de barras, matriz de desempeño, gráficas de Pareto, gráficas de correlación, etc.

Modelo de Medición de la Calidad

Actividad 1 Actividad 2 Actividad 3 Actividad 4 Actividad 5 Actividad 6 Actividad 7 Actividad 8

Fase Análisis de requisitos Diseño de Diseño Codificación y Integración y Integración y Instalación Aceptación y
arquitectura detallado de pruebas de pruebas de pruebas de apoyo
software software software sistema

Referencia Calidad requerida por Calidad en Calidad en Calidad en uso Calidad en Calidad en uso Calidad en Calidad en uso
modelo 9126 el usuario uso predicha uso predicha predicha uso predicha predicha uso predicha medida
Calidad interna Calidad Calidad Calidad externa Calidad Calidad Calidad Calidad
requerida externa externa medida externa externa medida externa externa
Calidad externa predicha predicha Calidad externa medida Calidad interna medida medida
requerida Calidad Calidad predicha Calidad medida Calidad Calidad
interna interna Calidad interna externa interna interna
medida medida medida predicha medida medida
Calidad
interna
medida

Entregables Requisitos de calidad Diseño de Diseño Código y Producto y Sistema Sistema Producto
clave del usuario arquitectura detallado de resultados de resultados de intgrado y instalado entregado
Requisitos de calidad software pruebas pruebas resultados de
externa pruebas
Requisitos de calidad
interna

Métricas Internas (externas Internas Internas Internas y Internas y Internas y Internas y Calidad en el
utilizadas pueden validar externas externas externas externas uso, internas y
especificaciones) externas

Pasos Sugeridos
1. Identificación de requisitos de calidad
2. Especificación de la evaluación
3. Diseño de la evaluación
4. Ejecución de la evaluación
5. Retroalimentación a la organización

Identificación de requisitos de calidad

Característica Subcaracterística Peso
Funcionalidad Adecuidad A
Exactidud A
Interoperabilidad B
Seguridad B
Conformidad M
Fiabilidad Madurez B
Tolerancia a fallos M
Recuperabilidad A
Tolerancia a fallos M
... ... ...

Especificación de la evaluación
Característica Subcaracterística Métrica Nivel Requerido Nivel Obtenido
Funcionalidad Adecuidad
Exactidud
Interoperabilidad
Seguridad
Conformidad
Fiabilidad Madurez
Tolerancia a fallos
Recuperabilidad
Tolerancia a fallos
... ...

Diseño de la evaluación
 Característica Subcaracterística Entregables Métricas Métricas Métricas
a Evaluar Internas a Externas a de Calidad
Aplicar Aplicar en el Uso
Funcionalidad Adecuidad 1. 1. 1. (no aplica)
2. 2. 2.
3. 3. 3.
Exactidud 1. 1. (no aplica) (no aplica)
2. 2.
3. 3.
Interoperabilidad ... ... ... ...

Métricas Internas Puras

 Referencia unificada de datos
 Trazabilidad
 Adecuidad de nombre de variables
 Número ciclomático
 Proporción de acomplamiento entre módulos por
 Complejidad del flujo de
datos
información
 Enunciados del programa
 Modularidad
 Tamaño promedio de módulo
 Tamaño del programa
 Proporción de acomplamiento entre módulos por
 Enunciados condicionales
funciones