Reconciliación de las métricas LDC y PF23

Reconciliación de las métricas LDC y PF

La relación entre líneas de código y puntos de función depende del lenguaje de programación en que se implementan el SW y la calidad del diseño.
La métrica de punto de función (PF) puede usarse de manera efectiva como medio para medir la funcionalidad que entra a un sistema. Al usar datos históricos, la métrica PF puede entonces usarse para:
1) estimarel costo o esfuerzo requerido para diseñar, codificar y probar el software;
2) predecir el número de errores que se encontrarán durante las pruebas,
3) prever el número de componentes y/o de líneas fuente proyectadas en el sistema implementado.
los puntos de función y las métricas basadas en LOC son predictores relativamente precisos del esfuerzo y del costo en el desarrollo del software. Sinembargo, si se van a usar LOC y PF para estimación debe establecerse una línea de referencia de información.

Métricas orientadas a objeto
es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación. Cada guión se organiza en tripletas de la forma {iniciador, acción, participante} donde iniciador es el objeto que solicita cierto servicio (que inicia un mensaje),acción es el resultado de la solicitud y participante es el objeto servidor que satisface la solicitud. El número de guiones de escenario se relaciona directamente con el tamaño de la aplicación y con el nú- mero de casos de prueba que deben desarrollarse para ejercitar el sistema una vez construido.

Número de clases clave. Las clases clave son los “componentes enormemente independientes”[Lor94] que se definen tempranamente en el análisis orientado a objeto (capítulo 6).5 Puesto que las clases clave son centrales en el dominio del problema, el número de tales clases es un indicio de la cantidad de esfuerzo requerido para desarrollar el software y también de la cantidad potencial de reuso por aplicar durante el desarrollo del sistema

Número de clases de apoyo. Las clases de apoyo serequieren para implementar el sistema, pero no se relacionan de inmediato con el dominio del problema. Los ejemplos pueden ser clases de interfaz de usuario (GUI), clases de acceso y manipulación de base de datos y clases de cálcu lo. Además, es posible desarrollar clases de apoyo para cada una de las clases clave. Las clases de apoyo se definen de manera iterativa a lo largo de un proceso evolutivo.El número de clases de apoyo es un indicio de la cantidad de esfuerzo requerido para desarrollar el software y también de la potencial cantidad de reuso que se va a aplicar durante el desarrollo del sistema





Número de subsistemas. Un subsistema es un agregado de clases que apoyan una función que es visible para el usuario final de un sistema. Una vez identificados los subsistemas, es másfácil plantear un calendario razonable en el cual el trabajo sobre los subsistemas se divide entre el personal del proyecto. Para usarse de manera efectiva en un entorno de ingeniería del software orientado a objeto, es necesario recopilar métricas similares a las anotadas anteriormente, junto con medidas del proyecto, tales como esfuerzo empleado, errores y defectos descubiertos, y modelos o páginasde documentación producidos. Conforme crece la base de datos (después de haber completado algunos proyectos), las relaciones entre las medidas orientadas a objeto y las medidas del proyecto proporcionarán métricas que pueden auxiliar en la estimación del proyecto.

Métricas orientadas a caso de uso Los casos de uso6 se utilizan ampliamente como un método para describir los requerimientos en eldominio en el nivel del cliente o empresarial, que implican características y funciones del software. Parecería razonable usar el caso de uso como una medida de normalización similar a LOC o PF. Como los PF, el caso de uso se define al principio del proceso del software, lo que permite emplearlo para estimación antes de iniciar actividades significativas de modelado y construcción. Los casos de uso...