MÉTRICAS DE SOFTWARE
Una métrica es una medida efectuada sobre los programas, documentación, su
desarrollo y
mantenimiento, o sobre algún aspecto del sistema en desarrollo o del proceso
empleado que permite, previa comparación con unos valores (medidas) de
referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar
las decisiones necesarias.
VENTAJAS DEL USO DE MÉTRICAS:
·
Determinar
la calidad del producto.
·
Evaluar
la productividad de los desarrolladores.
·
Conocimiento
cuantitativo de las características del proceso y del producto.
·
Se
podrán realizar comparaciones con otros proyectos.
·
Se
podrá mejorar el producto ya que las métricas sirven para detectar defectos.
CARACTERÍSTICAS:
·
Exactas
·
Precisas: No se debe perder información en los redondeos ya
que la información se desvirtúa.
·
Consistentes: Una medición de un atributo debe dar el mismo
valor independientemente de la medición.
·
Comparables: Para ello, debe estar normalizada.
TIPOS DE MÉTRICAS DE SOFTWARE:
— Métricas de tamaño: Los programas se escriben en lenguajes muy distintos y con propósitos
muy diferentes, usando técnicas y métodos dispares, pero con una característica
común: tienen un tamaño.
Este tamaño se determina
habitualmente tomando como referencia el programa en código fuente. El tamaño
es una medida empleada fundamentalmente por tres razones: es fácil de obtener
una vez que el programa ha sido completado, es uno de los factores más
importantes en los métodos de desarrollo, y la productividad se expresa
tradicionalmente con el tamaño del código. La medida de tamaño más usada es la
cantidad de líneas de código que se representa como Ss, y se mide en LOC (Lines
Of Code, líneas de código). Para
programas grandes es más adecuado el uso de KLOC (miles de líneas de código)
representadas como S.
— Métricas de estructuras de control:
La estructura lógica de un programa
es el mecanismo que le permite realizar las distintas funciones para las que
fue construido. La estructura lógica del programa representa los algoritmos
empleados en su diseño y procesa los datos. La estructura de un algoritmo se
representa perfectamente con las gráficas denominadas diagramas de flujo. Son
muchos los métodos de medición del software que se basan en estos diagramas.
El flujo de control en un programa
es habitualmente secuencial, aunque puede ser interrumpido en ciertas
ocasiones:
— En una decisión, se divide en dos
nuevas líneas de flujo que responden a la evaluación de una condición
determinada.
— Un salto hacia atrás devuelve el
flujo de control a una instrucción que ya ha sido ejecutada. Normalmente son la
base de los bucles.
— Una transferencia de control a una
rutina o procedimiento externo, hace que el flujo discurra por un camino
externo al programa.
La métrica denominada cuenta de
decisión (DE) mide la cantidad de veces que ocurren situaciones como las
mencionadas en primer y segundo lugar. Esto es, cuenta el número de
instrucciones de decisión y bucles condicionales. A la hora de contar
decisiones debe tenerse en cuenta los casos en que estas son compuestas, en
esta situaciones DE cuenta predicados más que instrucciones en sí, por lo que
las situaciones en las que se usan los operadores AND y OR incrementan en más
de uno el valor de DE (algo similar ocurre con instrucciones del tipo CASE).
— Métricas compuestas:
Las medidas descritas hasta ahora
miden una única magnitud para darle sentido como una característica del
software. Sin embargo, ocurre con frecuencia que para describir una determinada
cualidad del software es preciso componer (construir un par) de medidas
simples.
— Métricas de esfuerzo:
El número real de horas y minutos
que invierte un programador, es enorme, sin embargo hay una medida que destaca
por su universalidad: la personames o meses -hombre. Por otra parte, aunque el
esfuerzo es muy importante, en realidad la más importante métrica del esfuerzo
es el coste.
La importancia de la medida del
esfuerzo y coste responde más a necesidades de tipo administrativo y de gestión
que estrictamente técnicas.
Otro elemento importante al trabajar
a escala reducida es el tiempo de comprensión y aprendizaje que el programador
requiere para comprender los requerimientos, el diseño, o cualquier documento
previo a la codificación. Aprender a manejar las herramientas y lenguajes,
conocer los interfaces, la metodología empleada, etc. Supone retrasos
importantes en proyectos unipersonales.
— Métricas de calidad y fiabilidad:
El estudio de la calidad y
fiabilidad tiene una importancia cada vez mayor en el mundo de la Ingeniería
del Software. No sólo se trata de obtener sistemas desarrollados correctamente,
de acuerdo a los requerimientos y a los estándares establecidos, sino que se
pretenda conseguir programas fáciles de mantener y, lo que es más importante,
sistemas fiables en tareas críticas.
La prueba del software se encarga de
someter un programa a una revisión de todos los estados posible por los que
puede atravesar en algún momento de su vida útil. Los tres objetivos que dirigen
la prueba del software son:
— La prueba es un proceso de ejecución
de un programa con la intención de
descubrir un error.
— Un buen caso de prueba es aquel que
tiene una alta probabilidad de mostrar un error no descubierto hasta entonces.
— Una prueba tiene éxito si descubre
un error no detectado hasta entonces. Sin embargo, la característica más
destacable de la prueba del software es que la prueba no puede asegurar la
ausencia de defectos: sólo puede demostrar que existen defectos en el software.
— Métricas de diseño:
Eficiencia:
el esfuerzo de implementación puede reducirse.
Reducción de errores: los planes de prueba se simplifican notablemente.
Reducción del esfuerzo de mantenimiento: la división en módulos favorece que las
distintas funciones las lleven a cabo módulos diferenciados.
Ana Catalina Rodríguez Jaramillo
