Métricas de Proyectos

La ingeniería se basa en medidas, en consecuencia, la ingeniería del software no escapa a esta regla. La medida se hace necesaria por varias razones. Se permite obtener a través de las medidas indicadores que resultan útiles para reconocer el proceso de una tarea o análisis, que más tarde, sirve para mejorar las cosas, para organizar o clasificar tipos de procesos, costes, seguimientos, rendimiento, etc.

Las medidas en el mundo de la ingeniería física se clasifican en dos tipos o clases:

• Medidas Directas - Las medidas directas se trata de indicadores cuyos valores hacen mención a dimensiones físicas de un objeto, por ejemplo, un tornillo tiene un determinado tamaño, peso, etc.
• Medidas Indirectas – Las medidas indirectas se trata de indicadores cuyos valores no hacen mención a características dimensionales físicas de un objeto, más bien, se basa en la interpretación de calidad y rendimiento. Por ejemplo, la evaluación del resultado final de fabricación de tornillos incluyendo los artículos defectuosos.

Métricas de Tamaño del Software

Medir el tamaño de un programa puede resultar en una tarea crítica. En el basto universo de la programación y desarrollo del software, se han diseñado un sin fin de procesos de mediciones. Sin embargo, tan solo dos se han hecho notar y son los que aún mantienen arduas discusiones entre expertos de la ingeniería. Estos métodos son los siguientes:

• LDC – Líneas de Códigos – Este modelo de medidas utiliza la cantidad de líneas escritas y las utiliza para cuantificar un indicador que le permite determinar el tamaño, que más tarde, será comparado con las líneas escritas corregidas, agregadas o borradas al programa.
• PF – Puntos de función - Este modelo de medidas se basa en cantidad de funciones y tiene incidencia en la cantidad de procesos del programa, procedimientos o eventos del mismo. Utiliza un factor de 3D (tres dimensiones) como indicadores de interpretación.

El PF o punto de función, responde a la siguiente relación matemática y de ella deriva el PF 3D.

PW = N x W	Donde: PF es el punto de función N es la apariencia o el número total de cuentas de entradas obtenidas W es el factor de ajuste de complejidad que va del 0 al 14
PW = (Nb x Wb) + (Nm x Wm) + (Na x Wa)	PF 3D (tres dimensiones) donde: Nb, Nm y Na son las apariencias (baja, media y alta) Wb, Wm y Wa los factores de complejidad (baja, media y alta)

La variable W estriba de 14 formulaciones que debe hacerse el desarrollador para calificar el ajuste de complejidad que consta de 14 preguntas y que ponderan según los criterios que se enmarcan a continuación:

1. ¿Requiere el sistema copias de seguridad y de recuperación fiables? 2. ¿Se 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 el sistema entrada de datos interactiva? 7. ¿Requiere la entrada de datos interactiva que las transacciones de entradas lleven a cabo sobre múltiples pantallas u operaciones?

8. ¿Se actualización los archivos maestros de forma interactiva? 9. ¿Son complejas los archivos maestros de forma interactiva? 10. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 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?

Nivel	Estado
0…5	No importantemente aplicable
5…14	Absolutamente esencial

Lenguaje de programación	LDC/PF (medio)
Ensamblador	320
C	128
COBOL	106
FORTRAN	106
Pascal	90
C++	64
Ada95	53
Visual Basic	32
Smalltalk	22
Powerbuilder (generador de código)	16
SQL	12

Abra que recordar que este método PF como el método LDC, son descriptivos. Existe toda una relativización al respecto. Sin embargo, puede resulta útil por varias razones. Por ejemplo, si estamos en fase de optimizar el código, estos métodos podrían resultar en muy útiles. La métrica que surge de ello resulta en un indicador que puede ser eje comparativo durante las fases de refinamiento de código.

Puede calcular el coste de desarrollo por fases y, quizá, esto puede darle una idea de la envergadura del proyecto que se pretende confeccionar. De todos modos, el coste debe calcularse bajo otras razones y no bajo un mero concepto de medida lineal como pretende mostrar la tabla. Recuérdese que este se trata de una tabla de orientación y no puede ser representativamente una medida estandarizada. Tan solo, se trata de un número y simplemente eso, un número.

Economía en Base al Sistema COCOMO

El modelo COCOMO (Constructive Cost Model) se trata de uno de los modelos de construcción de software industrial de escala, diseñado por el ingeniero Barry Bohem. Presenta un acertado marco de estimación de costes de desarrollo, estimaciones de personal en función al tiempo, procesos diversos de ingeniería y gestión, etc. Además de ello, posee una jerarquía dividida en tres fases:

• Modelo de composición de aplicación
• Modelo de fase de diseño previo
• Modelo de fase posterior a la arquitectura

El gráfico muestra un modelo de diseño en las alboradas de un diseño de software. Se detalla los costes, la cantidad de líneas, los puntos de función, las desviaciones de esfuerzo estimadas y normales, etc. Mediante este software que puede obtenerse gratuitamente en el sitio del colegio de ingenieros en USA y cuya dirección de Internet es la siguiente: Site Web http://csse.usc.edu/csse/index.html, Ud., podrá construir y estimar costes y otras razones de ingeniería a través de un pequeño pero poderoso programa de ingeniería para el desarrollo de proyectos de sistemas. 

Autor: Wagner, Ariel Alejandro.