Métricasde un proyecto de Software

Métricas del Proyecto
•Cuando pueda medir lo que está diciendo y
expresarlo con números, ya conoce algo sobre ello;
cuando no pueda medir, cuando no pueda expresar
lo que dice con números, su conocimiento es
precario y deficiente; puede ser el comienzo del
conocimiento, pero en tus pensamientos apenas
estás avanzando hacia el escenario de la ciencia.
•Lord Kelvin

Métricas del Proyecto
• Medida:
• Proporciona una indicación cuantitativa de extensión,
cantidad, dimensiones, capacidad y tamaño de algunos
atributos de un proceso o producto. Pueden ser directas,
p.e. número de líneas de código, número de errores
encontrados, etc., o pueden ser indirectas, p.e.
funcionalidad, calidad, complejidad, etc.
• Medición:
• Acto de determinar una medida.

Métricas del Proyecto
• Métrica:
• Es una medida cuantitativa del grado en que un sistema o
proceso posee un atributo dado. Por lo general relaciona
una o más medidas, p.e. número de errores encontrados
por cada mil líneas de código.
• Indicador:
• Es una métrica o combinación de métricas que
proporcionan una visión del proceso, del proyecto o del
software en sí, y poder hacer ajustes para que las cosas
mejoren.

Métricas del Proyecto
• Métricas del Software:
• Amplio numero de medidas para el software.
• Indicadores del Proceso:
• Le permiten a la organización de ingeniería del software
tener una visión mas profunda de la eficacia de un proceso
existente.
• Permiten determinar lo que esta funcionando o no.
• Permiten tomar decisiones.
• Las métricas se recolectan para brindar indicadores.

Métricas del Proyecto
• Indicadores del Proyecto:
• Le permiten al director del Proyecto:
• Evaluar el estado del Proyecto en curso.
• Seguir la pista de los riesgos potenciales.
• Detectar las áreas problemáticas antes de que sean criticas.
• Ajustar el flujo y las tareas del trabajo.
• Evaluar la habilidad del equipo del proyecto en controlar la
calidad de los productos de trabajo.

Métricas del proceso y mejoras en el
proceso del software.
•Métricas Privadas:
• Índice de defectos.
• Índice de defectos (por modulo).
• Errores encontrados durante el desarrollo.
•Métricas Publicas:
• Errores durante revisiones técnicas formales.
• Errores de desarrollo.
• PD - LDC

Métricas del proceso y mejoras en el
proceso del software.
• Las métricas del proceso pueden ser muy útiles, pero hay
que saber interpretarlas:
• Unas normas básicas de interpretación son:
• Utilizar el sentido común al interpretar los datos.
• Proporcionar una realimentación regular a particulares y equipos.
• No utilizar métricas para evaluar a particulares.
• Establecer métricas claras y objetivos para alcanzarlas.

Métricas del proceso y mejoras en el
proceso del software.
•No utilizar métricas para amenazar a particulares
o equipos.
•Si una métrica identifica un área problemática no
se debería considerar como negativa.
•Hay que interpretar todas las métricas en su
conjunto, y no primar una en particular.

Métricas del proceso y mejoras en el
proceso del software
•La utilización de métricas e indicadores fiables da
lugar a una mejora estadística del proceso del
software
•Esta mejora se basa en un análisis de fallos que
identifica la causa y origen de errores y defectos
para varios proyectos de software.
•Error:
• Fallo en un producto generado durante el proceso de IS que
es detectado antes de la entrega al cliente.

Métricas del proceso y mejoras en el
proceso del software
•Defecto: fallo detectado después de la entrega al cliente.
El análisis de fallos :
• Se categorizar por origen todos los errores y defectos de varios proyectos.
• Se registra el coste de corregir cada error o defecto.
• El número de errores y de defectos de cada categoría se cuentan y se
ordenan decrecientemente

Métricas del proceso y mejoras en el
proceso del software
• Se computa el coste global de errores y defectos de cada
categoría.
• Los datos resultantes se analizan para detectar las
categorías que producen el coste más alto para la
organización.
• Se desarrollan planes para modificar el proceso con el
intento de eliminar (o reducir la frecuencia de apariciones
de) la clase de errores y defectos que sean más costosos.

Métricas Orientadas al Tamaño
• Medidas
• Líneas de código (LOC).
• Esfuerzo en hombre-mes.
• Costo en pesos o dólares.
• Número de páginas de documentación.
• Número de errores. Fallas detectadas antes de entregar el software al
cliente.
• Número de defectos. Fallas detectadas después de entregar el
software al cliente.
• Número de personas en el proyecto.

Métricas Orientadas al Tamaño
• Métricas
• Errores por KLOC (mil líneas de código).
• Defectos por KLOC.
• Costo por KLOC.
• Páginas de documentación por KLOC.
• Errores por hombre-mes.
• LOC por hombre-mes.
• Costo por página de documentación.

Métricas Orientadas al Tamaño
•Ventajas
• Son fáciles de calcular.
• Muchos modelos de estimación de software usan LOC o
KLOC como datos de entrada.
• Existen un amplio conjunto de datos y literatura basados en
LOC.
•Desventajas
• Son dependientes del lenguaje de programación.
• Perjudica a los programas cortos pero bien diseñados.
• Su uso en estimación es difícil porque hay que estimar las
LOC a producirse mucho antes de que se complete el
análisis y el diseño.

Métricas Orientadas a la Función
• Miden la funcionalidad
• No se puede medir directamente.
• Evalúa la complejidad del software.
• Entradas de usuario. Son entradas que proporcionan diferentes datos a la
aplicación. No confundirlos con las peticiones de usuario.
• Salidas de usuario. Son reportes, pantallas o mensajes de error que
proporcionan información. Los elementos de un reporte, no se cuentan de
forma separada.
• Peticiones de usuario. Es una entrada interactiva que produce la generación
de alguna respuesta del software en forma de salida interactiva.
• Archivos. Son los archivos que pueden ser parte de una base de datos o
independientes.
• Interfaces externas. Son los archivos que se usan para transmitir información
a otro sistema.

Métricas Orientadas a la Función
•Para cada medida, multiplicar su cuenta por el factor de
complejidad elegido y escribirlo en la columna de la
extrema derecha.
•Sumar la columna de la extrema derecha y obtener un
total T que indica el valor del dominio de la información.

Métricas Orientadas a la Función
Responder a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde 0 es no
influencia, 1 es incidental, 2 es moderado, 3 es medio, 4 es significativo y 5 es esencial.
• 1-¿Requiere el sistema copias de seguridad y de recuperación fiables?
• 2-¿Requiere comunicación de datos?
• 3-¿Existen funciones de procesamiento distribuido?
• 4-¿Es crítico el rendimiento?
• 5-¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?
• 6-¿Requiere entrada de datos interactiva?
• 7-¿Requiere la entrada de datos interactiva que las transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones?
• 8-¿Se actualizan los archivos maestros de forma interactiva?
• 9-¿Son complejas las entradas, las salidas, los archivos o las peticiones?
• 10-¿Es complejo el procesamiento interno?
• 11-¿Se ha diseñado el código para ser reutilizable?
• 12-¿Están incluidas en el diseño la conversión y la instalación?
• 13-¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
• 14-¿Se ha diseñado la aplicación para facilitar los cambios y para ser fácilmente utilizada por el usuario?
Sumar los puntos asignados a cada respuesta y obtener un
total F que indica un valor de ajuste de complejidad.

Métricas Orientadas a la Función
El punto de función FP se calcula con la siguiente ecuación:
PF = T * (0.65 + 0.01 * F).
Donde:
T indica el valor del dominio de la información.
F indica un valor de ajuste de complejidad.

@josefabiandiaz
josefabiandiazs@Gmail.com
https://www.youtube.com/user/fabiandiazs
Msc.Ing.Jose Fabián Diaz Silva
Consultas