Tipos Métricas de Software

Tipos Métricas de Software

Clasificación

•Las mediciones se pueden englobar en dos categorías:
–Medidas directas
•El coste y el esfuerzo aplicado.
•El número de líneas de código (LDC), velocidad de ejecución, memoria, defectos.
–Medidas indirectas
•Funcionalidad, calidad, complejidad, eficiencia, fiabilidad, mantenimiento.
•Dependiendo de lo que se quiera medir, las métricas se clasifican en:
–Métricas orientadas al proceso
–Métricas orientadas al proyecto
–Métricas orientadas al producto
–Métricas orientadas a la calidad

Métricas de proceso

• Métricas de propósito estratégico. 
• Las métricas aplicadas al proceso establecen un conjunto de indicadores – Mejora de procesos de SW. 
• Se basan en datos históricos o estadísticos. 
• Métricas privadas: Se aplica a individuos – y los resultado o información no se publican. 
• Métricas públicas : Origen privada – Se publican a todo el equipo. 
• Los indicadores del proceso permiten: Al gestor, evaluar lo que funciona y lo que no, A la organización, tener una visión profunda de la eficacia de un proceso ya existente

Métricas privadas:
Sólo es conocido por el equipo del proyecto, pero publicas por todos los miembros del equipo
•Índices de defecto por individuo o módulo
•Líneas de código o puntos de función por modulo y función
•Errores encontrados durante la revisión con técnicas formales

Métricas públicas:
Asimilan información que originalmente era privada de particulares y equipos permitiendo a las organizaciones hacer los cambios estratégicos para mejorar el proceso del software.
•Índice de defectos a nivel de proyecto

Métricas de proceso: Orientadas al tamaño

Productividad = KLDC / persona-mes
Calidad = N° de errores (defectos) / KLDC
Coste medio = USD / KLDC
Documentación = KLDC / persona-mes

•Las métricas del software orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad, considerando el “tamaño” del software que se haya producido.
•Para desarrollar métricas que se puedan comparar entre distintos proyectos, se seleccionan las líneas de código como valor de normalización.

Proceden de la normalización de medidas de calidad y productividad considerando el tamaño del software.

Algunas métricas. Formulas:
(KLDC por persona-mes): Productividad = KLDC / persona-mes
(Errores por KLDC): Calidad = Errores / KLDC
(Coste por KLDC): Coste = Dinero / KLDC
(Pagina de documentación por KLDC): Documentación = Paginas de documentación / KLDC
Todo se basa en la KLDC pero esta medida es un artificio, que depende del lenguaje de programación utilizado.

Ejemplo: Medidas LDC
•n1: número de operadores diferentes que aparecen en el programa.
•n2: número de operandos diferentes que aparecen en el programa.
•N1: número total de veces que aparece el operador.
•N2: número total de veces que aparecen el operando.

De está tabla se desprenden los valores de n1=10 y N1=28.

De esta tabla se desprenden los valores de n2=7 y N2=22.

Calcular la productividad, calidad, coste medio y documentación de acuerdo a la información proporcionada en la tabla que se muestra a continuación:

• Productividad = KLDC / personas-mes 
• Calidad = Nº errores (defectos) / KLDC 
• Coste medio = Dólares / KLDC 
• Documentación = Páginas de documentación / KLDC

Métricas de proceso: Orientadas a la función

Productividad = PF / persona-mes
Calidad = N° de errores (defectos) / PF
Coste medio = USD / PF
Documentación = PF / persona-mes

•La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evaluar para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función:
•Número de entradas del usuario
•Número de salidas del usuario
•Número de consultas del usuario
•Número de archivos
•Número de interfaces externas

Puntos de función:
•Funcionalidad o utilidad de la aplicación
•La unidad básica de medida son los Puntos de Función

Calculo de puntos de función

• Es una métrica que se puede aplicar en las primeras fases de desarrollo.
• Se basa en características fundamental-mente “externas” de la aplicación a desarrollar.
• Son elementos fácilmente identificables en los diagramas de especificación del sistema. (DFD, Entidad-Relación, DD)
• Los usuarios los entienden perfectamente. 
• Observamos la aplicación como una caja negra. 
• Nos centramos en característica visibles del proyecto en estudio. 
• Mide dos tipos de características: Los elementos de función (entradas, salidas, ficheros, etc.). Los factores de Complejidad.
• Elementos de Función: 

1.  Entradas 
2.  Salidas 
3.  Consultas 
4.  Ficheros Lógicos Internos 
5.  Ficheros de Interfaz

1. Entradas:
• Son todos aquellos procesos que hacen llegar datos a la aplicación desde el exte-rior, desde un usuario u otra aplicación.
• El flujo de datos deberá tener una sola dirección, del exterior al interior.
• Como consecuencia de una entrada, siempre deberá actualizarse un fichero lógico interno.
• Ejemplos:
Pantallas de entrada de datos.
Lector de códigos de barras.
Lector de tarjetas magnéticas y electrónicas.
Cáptura de imágenes, voz, etc.

2. Salidas:
• Son todos aquellos procesos que hacen llegar datos desde la aplicación hacia el exterior, a un usuario o a otra aplicación.
• El flujo de datos deberá tener una sola dirección, del interior al exterior.
• Ejemplos:
Pantallas de salida de datos.
Listados.
Grabación de bandas magnéticas.
Transferencia de datos a otras aplicaciones, ya sea mediante ficheros o transmisión de datos.

3. Consultas: 

• Son todos aquellos procesos que están formados por una combinación de entradas y salidas, produciendo una consulta a los datos.
• El flujo de datos deberá tener dos direcciones.
• Como consecuencia de una consulta no se modifican los datos del sistema.
• La complejidad de la consulta viene dada por la mayor entre la entrada y la salida.

4. Ficheros Lógicos Internos:
• Es un grupo de datos relacionados, tal como los percibe el usuario y que son mantenidos por la aplicación.
• Los ficheros se cuentan una sola vez, independientemente del número de procesos que los acceden.
• Ejemplos:
Clientes.
Socios.
Artículos.
Proveedores.

5. Ficheros de Interfaz Externos:
• Es un grupo de datos relacionados, tal como los percibe el usuario, referencia-dos por la aplicación y que son manteni-dos por otra aplicación.
• Son ficheros internos de otra aplicación.

Estimación del esfuerzo requerido

• Partimos de los datos históricos de la Organización. 
• Esfuerzo = PF * Promedio_Organización( Lenguaje)

Ventajas:
•Los PF son independientes del lenguaje de programación
•Se basan en datos que se puedan conocer antes de empezar el proyecto

Inconvenientes:
•Los datos se basan en juicios subjetivos
•Su valor no es físico. No tiene unidades

Métricas de proyecto

Todo proyecto debe medir: 

Entradas:
La dimensión de los recursos (personas, entornos) que se requiere para realizar el trabajo.

Salidas:
Medidas de la entrega o productos creados durante el proceso de ingeniería de software.

Resultados:
Medidas que indican la efectividad de las entregas.

La métrica del proyecto de software se usa por el equipo del software para adaptar el flujo de trabajo del proyecto y las actividades técnicas.
La utilización de métricas para el proyecto tiene dos aspectos fundamentales:
1. Se utilizan para minimizar la aplicación de desarrollo haciendo los ajustes necesarios que eviten retrasos y reduzcan problemas y riesgos potenciales.
2. Se utilizan para evaluar la calidad de los productos en el momento actual y cuando sea necesario.

Los indicadores del proyecto permiten al gestor de proyectos del software:
1. Evaluar el estado del proyecto en curso.
2. Seguir la pista de los riesgos potenciales.
3. Detectar las áreas problemas antes de que se conviertan en criticas.
4. Ajustar el flujo y las tareas del trabajo.
5. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo del software. 

Métricas de propósito táctico.
Doble finalidad
1. Minimizar tiempos de desarrollo – reducción de problemas y riesgos.
2. Valorar calidad del producto – mejor calidad, menos defectos – reducción de reelaboración.

Los indicadores del proyecto permiten al gestor:
1. Evaluar el estado del proyecto en curso
2. Seguir la pista de riesgos potenciales
3. Detectar áreas problemáticas antes de que se conviertan en críticas
4. Ajustar el flujo y las tareas de trabajo
5. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la IS 

•Utilizado por un director de proyecto y equipo de software para adaptar el flujo de trabajo del proyecto y las actividades técnicas.
•Purposito:
-Minimizar el calendario de desarrollo, haciendo los ajustes necesarios para evitar retrasos y mitigar los problemas
-Evaluar la calidad del producto en forma permanente
•Metricas:
-Esfuerzo o tiempo por tarea
-Los errores descubiertos por hora opinión
-Programado vs fechas reales de hitos
-Número de cambios y sus características
-Distribución del esfuerzo en las tareas 

Métricas de producto

•Enfoque en la calidad de los resultados
•Métricas de productos se combinan a través de varios proyectos para producir indicadores de proceso
•Métricas por producto:
-Medidas del Modelo de Análisis
-Complejidad del Modelo de Diseño
1.Complejidad algorítmica Interna
2.complejidad arquitectónica
3.Complejidad del flujo de datos
-Métricas de código 

Métricas de calidad

Miden el número de defectos no descubiertos en la prueba, la facilidad de mantenimiento del sistema y la eficiencia de eliminar los defectos.

Factores que afectan a la calidad:
•Operación del producto (uso)
•Revisión del producto (modificación)
•Transporte (modificación para que funcione en otro entorno)  

Corrección:
Definición: Grado en que el software realiza la función encomendada.
Medida: Defectos por KLDC (medida mas común), Defectos por PF
Defecto: Carencia verificada de conformidad con los requisitos. Los comunica el usuario a lo largo de un periodo de tiempo determinado (un año).

Facilidad de mantenimiento:
Definición: Facilidad con la que se puede corregir un programa si se encuentra un error, adaptarlo a un cambio de entorno, o mejorarlo ante una petición del cliente
Medida: No hay. Son indirectas. TMC (Tiempo Medio de Cambio), es el tiempo que lleva analizar, diseñar, implementar, probar y distribuir un cambio.
Desperdicio: Coste de corregir los defectos encontrados después de haber distribuido el software a los usuarios finales 

Integridad:
Definición: Habilidad de un sistema para resistir ataques (accidentales o intencionados) contra su seguridad tanto a los programas como a los datos y documentos
Amenaza: Probabilidad de que un ataque ocurra en un tiempo determinado
Seguridad: Probabilidad de que se puede repeler el ataque
Integridad = ∑ [(1-amenaza) * (1-seguridad)] para cada tipo de ataque

Facilidad de uso:
Definición: Es una cuantificación de la amigabilidad de uso
Características:
•Habilidad intelectual y/o física para aprender el sistema
•Tiempo necesario para llegar a ser moderadamente eficiente en el uso del sistema
• Aumento neto en productividad cuando se utiliza eficientemente .
•Valoración subjetiva del usuario hacia el sistema  

Medidas de calidad del SW:
Corrección: grado en que el SW lleva a cabo su función.
Facilidad de mantenimiento: representa la facilidad de corregirse y adaptarse a un cambio.
Integridad: Mide la habilidad de un sistema para resistir ataques (tanto accidentales como intencionados) contra su seguridad.
Facilidad de uso: Intento por medir lo amigable que puede ser un programa con el usuario. 

Aunque hay muchas medidas de la calidad de software, la corrección, facilidad de mantenimiento, integridad, y facilidad de uso proporcionan indicadores útiles para el equipo del proyecto.

Corrección
–Un programa debe operar correctamente o proporcionará poco valor a sus usuarios.
–La medida más común de corrección es defectos por KLDC. 

Facilidad de mantenimiento
–Facilidad con la que se puede corregir un programa si se encuentra un error, se puede adaptar si su entorno cambia, o mejorar si el cliente desea un cambio de requisitos.
–Una simple métrica orientada al tiempo 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 adecuada, en implementar el cambio, en probarlo y en distribuir el cambio a todos los usuarios. 

Integridad
Para medir la integridad, se tienen que definir dos atributos adicionales: amenaza y seguridad.

–Amenaza es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado.
–Seguridad es la probabilidad de que se pueda repeler el ataque de un tipo determinado.

La integridad del sistema se puede definir como: ∑ [(1-amenaza) * (1-seguridad)] 

Facilidad de uso
Si un programa no es «amigable con el usuario», frecuentemente está abocado al fracaso, se puede medir en función de cuatro características:

1.Habilidad intelectual y/o física requerida para aprender el sistema;
2.Tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema;
3.Aumento neto en productividad (sobre el enfoque que el sistema reemplaza) medida cuando alguien utiliza el sistema moderadamente y eficientemente;
4.Valoración subjetiva (a veces obtenida mediante un cuestionario) de la disposición de los usuarios hacia el sistema.

Integración de las métricas dentro del proceso de desarrollo de sw
•Muchos diseñadores del software no coleccionan las medidas.
•Sin las medidas es imposible determinar si un proceso está mejorando o no.
•Las líneas base de métricas constan de datos recogidos de proyectos de software desarrollados anteriormente.
•Conseguir estos datos de proyectos históricos es muy difícil, si los diseñadores anteriores no coleccionaron los datos de una manera continua.

Establecimiento de una linea base 

Los datos de la Línea Base deben tener los siguiente atributos:
1.Deben ser razonablemente exactos
2.Deben reunirse del mayor numero de proyectos que sea posible
3.Las medidas deben ser consistentes
4.Las aplicaciones deben ser semejantes para trabajar con la estimación.

Consejos sobre la linea base

•Los datos deben ser razonablemente precisos, han de evitarse la suposición sobre proyectos anteriores.
•Los datos deben obtenerse de tantos proyectos como sea posible.
•Las medidas deben ser consistentes. LDC distintas para cada lenguaje de programación.
•Las aplicaciones deben ser similares a la que va a ser estimada.

Colección de métricas, computo y evaluación

Establecimiento de un programa de metricas

•Identifique los objetivos del negocio
•Identifique lo que se desea saber o aprender
•Identifique los subobjetivos
•Identificar las entidades y atributos relativos a esos subobjetivos
•Formalizar los objetivos de la medición
•Identificar preguntas que puedan cuantificarse y los indicadores que se van a usar para ayudar a conseguir los objetivos de medición.

•Identificar los elementos de datos que se van a recoger para construir los indicadores que ayuden a responder a las preguntas planteadas.
•Definir las medidas a usar y hacer que estas definiciones sean operativas.
•Identificar las acciones que serán tomadas para mejorar las medidas indicadas.
•Preparar un plan para implementar estas medidas.