metricas del proyecto de software - introduccion

Métricasde un proyecto de Software

Métricas del Proyecto

•Cuando pueda medir lo que está diciendo yexpresarlo con números, ya conoce algo sobre ello;cuando no pueda medir, cuando no pueda expresarlo que dice con números, su conocimiento esprecario y deficiente; puede ser el comienzo delconocimiento, pero en tus pensamientos apenasestás avanzando hacia el escenario de la ciencia.

• Lord Kelvin


• Medida:

• Proporciona una indicación cuantitativa de extensión,cantidad, dimensiones, capacidad y tamaño de algunosatributos de un proceso o producto. Pueden ser directas,p.e. número de líneas de código, número de erroresencontrados, etc., o pueden ser indirectas, p.e.funcionalidad, calidad, complejidad, etc.

• Medición:

• Acto de determinar una medida.


• Métrica:

• Es una medida cuantitativa del grado en que un sistema oproceso posee un atributo dado. Por lo general relacionauna o más medidas, p.e. número de errores encontradospor cada mil líneas de código.

• Indicador:

• Es una métrica o combinación de métricas queproporcionan una visión del proceso, del proyecto o delsoftware en sí, y poder hacer ajustes para que las cosasmejoren.


• 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.


• 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


• 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.


•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.


•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


• Se computa el coste global de errores y defectos de cadacategoría.

• Los datos resultantes se analizan para detectar lascategorías que producen el coste más alto para laorganización.

• Se desarrollan planes para modificar el proceso con elintento de eliminar (o reducir la frecuencia de aparicionesde) 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• 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.


•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.


•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.


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.


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

[email protected]

https://www.youtube.com/user/fabiandiazs

Msc.Ing.Jose Fabián Diaz Silva

Consultas

mailto:[email protected]

https://www.youtube.com/user/fabiandiazs