Métricas del software

COCOMO

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COstMOdel) es un modelo matemático de base empírica utilizado para estimación de costes de software. Incluye tres submodelos, cada uno ofrece un nivel de detalle y aproximación, cada vez mayor, a medida que avanza el proceso de desarrollo del software: básico, intermedio y detallado.

Este modelo fue desarrollado por Barry W. Boehm a finales de los años 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981).

CARACTERÍSTICAS

Pertenece a la categoría de modelos de subestimaciones basados en estimaciones matemáticas. Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en líneas de código principalmente.

INCONVENIENTES

• Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizarlas.
• Se puede desviar de la realidad si se indica mal el porcentaje de líneas de comentarios en el código fuente.
• Es un tanto subjetivo, puesto que está basado en estimaciones y parámetros que pueden ser "vistos" de distinta manera por distintos analistas que usen el método.
• Se miden los costes del producto, de acuerdo a su tamaño y otras características, pero no la productividad.
• La medición por líneas de código no es válida para orientación a objetos.
• Utilizar este modelo puede resultar un poco complicado, en comparación con otros métodos (que también sólo estiman).

MODELOS DE ESTIMACIÓN

La función básica que utilizan los tres modelos es: E = a(Kl)^b * m(X) donde:

a y b son constantes con valores definidos en cada submodelo

Kl es la cantidad de líneas de código, en miles.

m(X) Es un multiplicador que depende de 15 atributos.

El resultado se da en unidades salario/mes y horas-hombre.

A la vez, cada submodelo también se divide enmodos que representan el tipo de proyecto, y puede ser:

• modo orgánico: un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía desde unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles (medio). mientras que en los otros dos modos el tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga. Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo.

• modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgánico y el rígido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas.

• modo rígido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes.



 Métricas Orientadas al Tamaño
 
Las métricas del software orientadas al tamaño provienen de la normalización de las medidas de calidad y/o productividad considerando el «tamaño» del software que se haya producido. Si una organización de software mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño, como la que muestra la   La tabla lista cada proyecto de desarrollo de software de los últimos años y las medidas correspondientes de cada proyecto. Refiriéndonos a la entrada de la tabla  del proyecto alfa: se desarrollaron 12.100 líneas de código (LDC) con 24 personas-mes y con un coste de E168.000. Debe tenerse en cuenta que el esfuerzo y el coste registrados en la tabla incluyen todas las actividades de ingeniería del software (análisis, diseño, codificación y prueba) y no sólo la codificación. Otra información sobre el proyecto alfa indica que se desarrollaron 365 páginas de documentación, se  registraron 134 errores antes de que el software se entregara y se encontraron 29 errores después de entregárselo al cliente dentro del primer año de utilización.

También sabemos que trabajaron tres personas en el desarrollo del proyecto alfa.

 ¿Qué datos deberíamos reunir para derivar métricas orientadas al tamaño?  

Para desarrollar métricas que se puedan comparar entre distintos proyectos, se seleccionan las líneas de
código como valor de normalización. Con los rudimentarios datos contenidos en la tabla se pueden desarrollar para cada proyecto un conjunto de métricas simples orientadas al tamaño:
errores por KLDC (miles de líneas de código)
defectos4 por KLDC
E por LDC
páginas de documentación por KLDC
Plontillo de colección de métricos
Además, se pueden calcular otras métricas interesantes:
errores por persona-mes
LDC por persona-mes
E por página de documentación

  Métricas Orientadas a la Función
Las métricas del software orientadas a la función utilizan una medida de la funcionalidad entregada por la
aplicación como un valor de normalización. Ya que la «funcionalidad>>n o se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas. Las métricas orientadas a la función fueron propuestas por primera vez por Albretch [ALB79], quien sugirió una medida llamada punto defunción. Los puntos de función se derivan con una relación empírica  según las medidas contables (directas) del dominio de información del software y las evaluaciones de la complejidad del software.
Referencia 3 Web Se puede obtener información completo sobre los puntos de funcibn en: www.ifpug.org

Los puntos de función se calculan [IFP94] completando la tabla de la  Se determinan cinco características de dominios de información y se proporcionan las cuentas en la posición apropiada de la tabla. Los valores de los dominios de información se definen de la forma siguiente? Número de entradas de usuario. Se cuenta cada entrada de usuario que proporciona diferentes datos orientados a la aplicación. Las entradas se deberían diferenciar de las peticiones, las cuales se cuentan de forma separada. los puntos de función se derivan de medidas directas del dominio de la información. Número de salidas de usuario. Se cuenta cada salida que proporciona al usuario información orientada a la aplicación. En este contexto la salida se refiere a informes, pantallas, mensajes de error, etc. Los elementos de datos particulares dentro de un informe no se cuentan de forma separada.

Número de pcticiones de usuario. Una petición se define como una entrada interactiva que produce la generación de alguna respuesta del software inmediata en forma de salida inleractiva. Se cuenta cada petición por separado. Número de archivos. Se cuenta cada archivo maestro lógico (esto es, un grupo lógico de datos que puede ser una parte de una gran base de datos o un archivo
independiente). Número de interfaces externas. Se cuentan todas las interfaces legibles por la máquina (por ejemplo: archivos de datos de cinta o disco) que se utilizan para transmitir información a otro sistema. 

Una vez que se han recopilado los datos anteriores, a la cuenta se asocia un valor de complejidad.
Las organizaciones que utilizan métodos de puntos de función desarrollan criterios para determinar si
una entrada en particular es simple, media o compleja. No obstante la determinación de la complejidad
es algo subjetiva.

Parámetros de medición Cuenta Número de entradas de usuario Número de salidas de usuario

Número de peticiones de usuario ccll Número de archivos Número de interfaces externas Factor de ponderación

 Simple Medio Complejo 

x 3 4 6 =a

x 4 5 7 =a
x 3 4 6 =a
X l 10 15 = a
x 5 7 10 = a
Cuenta total
  Cálculo de puntos de función.
Para calcular puntos de función (PF), se utiliza la
(4.1)
relación siguiente:
PF = cuenta-total x [0,65 + 0,Ol x 6(Fi )]
en donde cuenta-total es la suma de todas las entradas
PF obtenidas de la figura 4.5.
Fi (i = 1 a 14) son «valores de ajuste de la compkjidad
» según las respuestas a las siguientes preguntas
.
¿Requiere el sistema copias de seguridad y de recuperación
fiables?
¿Se requiere comunicación de datos?
¿Existen funciones de procesamiento distribuido?
¿Es crítico el rendimiento?
¿Se ejecutarh el sistema en un entorno operativo
existente y fuertemente utilizado?
i,Requiere el sistema entrada de datos interactiva?
¿Requiere la entrada de datos interactiva que las
transacciones de entrada se lleven a cabo sobre múltiples
pantallas u operaciones?
¿Se actualizan los archivos maestros de forma
interactiva?
¿Son complejas las entradas, las salidas, los archivos
o las peticiones?
¿Es complejo el procesamiento interno?
¿Se ha diseñado el código para ser reutilizable?
¿Están incluidas en el diseño la conversión y la instalación'?
¿Se ha diseñado el sistema para soportar múltiples
instalaciones en diferentes organizaciones?
¿Se ha diseñado la aplicación para facilitar los cambios
y para ser fácilmente utilizada por el usuario?


   Métricas ampliadas de punto de función
La medida de punto de función se diseñó originalmente para aplicarse a aplicaciones de sistemas de información de gestión. Para acomodar estas aplicaciones, se enfatizó la dimensión de datos (los valores de dominios de información tratados anteriormente) para la exclusión de dimensiones (control) funcionales y de comportamiento. Por esta razón, la medida del punto de función era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control). Para remediar esta situación se ha propuesto un número de extensiones a la métrica del punto de función básica.

CLAVE
la extensión de los puntos de función se utiliza en la ingeniería, en las aplicaciones de tiempo real
y en las aplicaciones orientadas al control. Una extensión del punto de función es la llamada
puntos de características [JON9 11; es una ampliación de la medida del punto de función que se puede aplicar a sistemas y aplicaciones de ingeniería del software. La medida de punto de característica acomoda a aplicaciones en donde la complejidad del algoritmo es alta. Las aplicaciones de software de tiempo real, de control de procesos, y empotradas tienden a tener alta complejidad de algoritmos y por lo tanto son adecuadas para el punto de característica. Para calcular el punto de característica, los valores
de dominio de información se cuentan otra vez y se pesan de la forma que se describe en la Sección 4.3.2. Además, la métrica del punto de característica cuenta una característica nueva del software -los algoritmos-. Un algoritmo se define como <<unp roblema de cálculo limitado que se incluye dentro de un programa de computadora específico» [JON9 11. Invertir una matriz, decodificar una cadena de bits o manejar una interrupción son ejemplos de algoritmos. 

Boeing ha desarrollado otra extensión de punto de función para sistemas en tiempo real y productos de
ingeniería. El enfoque de Boeing integra la dimensión de datos del software con las dimensiones funcionales y de control para proporcionar una medida orientada a la función que es adecuada a aplicaciones que enfatizan las capacidades de control y función. Las características de las tres dimensiones del software se «cuentan, cuantifican y transforman» en una medida que proporciona una indicación de la funcionalidad entregada por el software6, llamada Punto de Función 30 [WHI95]
La dimensión de datos se evalúa exactamente iguala como se describe en la Sección 4.3.2. Las cuentas de
datos retenidos (la estructura interna de datos de programas, p. ej.: archivos) y los datos externos  entradas, salidas, peticiones y referencias externas) se utilizan a lo largo de las medidas de la complejidad para derivar una cuenta de dimensión de datos. 

La dimensión funcional se mide considerando «el número de operaciones internas requeridas para transformardatos de entrada en datos de salida» [WHI95].

Para calcular puntos de función 3D, se utiliza la rela-
(4.2)
en donde 1, O, Q, F, E, T y R representan valores con
peso de complejidad en los elementos tratados anteriormente:
entradas, salidas, peticiones, estructuras de
datos internas, archivos externos, transformaciones y
transiciones, respectivamente. Cada valor con peso de
complejidad se calcula con la relación siguiente:
valor con peso de complejidad =
ción siguiente:
índice=I + O + Q + F + E + T+ R

en donde Nil , Ni, y Nih representan el número de apariciones
del elemento i (p. ej.: salidas) para cada nivel
de complejidad (bajo, medio, alto), y Wi, , Wia y W,
son los pesos correspondientes. El cálculo global de los
puntos de función 3D se muestran en la Figura 4.6.
Se debería señalar que los puntos de función, los puntos
de característica y los puntos de función 3D representan
lo mismo -«funcionalidad» o «utilidad»
entregada por el software-. En realidad, cada una de
estas medidas producen el mismo valor si sólo se considera
la dimensión de datos de una aplicación. Para sistemas
de tiempo real más complejos, la cuenta de puntos
de característica a menudo se encuentra entre el 20 y el
35 por 100 más que la cuenta determinada sólo con los
puntos de función.
El punto de función (y sus extensiones), como la
medida LDC, es controvertido. Los partidarios afirman
que PF es independiente del lenguaje de programación,
lo cual es ideal para aplicaciones que utilizan lenguajes
convencionales y no procedimentales; esto se basa en
los datos que probablemente se conocen al principio de
la evolución de un proyecto, y así el PF es más atractivo
como enfoque de estimación.
Sentencias
1-5 6-10 11+
1-10 Bajo Bajo Medio
1 1-20 Bajo Medio Alto
Cálculo de los índices de los puntos
de función 30.
Los detractores afirman que el método requiere algún
«juego de manos» en el que el cálculo se base en datos
subjetivos y no objetivos; y afirman que las cuentas del
dominio de información (y otras dimensiones) pueden
ser difíciles de recopilar después de realizado, y por último
que el PF no tiene un significado físico directo -es
simplemente un número-.
Métricas para la calidad de software


El objetivo primordial de la ingeniería del software es producir
un sistema, aplicación o producto de alta calidad.
Para lograr este objetivo, los ingenieros del software deben
aplicar métodos efectivos junto con herramientas modernas
dentro del contexto de un proceso maduro de desarrollo
de software. Además, un buen ingeniero del software
(y buenos gestores de la ingeniería del software) deben
medir si la alta calidad se va a llevar a cabo.
La calidad de un sistema, aplicación o producto es
tan bueno como los requisitos que describen el problema,
el diseño quc modcla la solución, el código que conduce
a un programa ejecutable, y las pruebas que
ejercitan el software para detectar errores. Un buen ingeniero
del software utiliza mediciones que evalúan la
calidad del análisis y los modelos de diseño, el código
fuente, y los casos de prueba que se han creado al aplicar
la ingeniería del software. Para lograr esta evaluación
de la calidad en tiempo real, el ingeniero debe
utilizar medidas técnicas (Capítulos 19 y 24) que evalúan
la calidad con objetividad, no con subjetividad.
Referencia Web/ ’
Se puede encontrar una excelente fuente de informoción
sobre la calidad del software y ternos relacionados
(incluyendo métricas) en: www.quol¡tyworld.com
El gestor de proyectos también debe evaluar la calidad
objetivamente, y no subjetivamente. A medida que
el proyecto progresa el gestor del proyecto también debe
evaluar la calidad. Las métricas privadas recopiladas por
ingenieros del software particulares se asimilan para proporcionar
resultados en los proyectos. Aunque se pueden
recopilar muchas medidas de calidad, el primer objetivo
en el proyecto es medir errores y defectos. Las métricas
que provienen de estas medidas proporcionan una indicación
de la efectividad de las actividades de control y
de la garantía de calidad en grupos o en particulares.
En el capitulo 8 se presento un estudio detallada sobre
las actividades de garantía de calidad del software.
4.5.1. Visión general de los factores que afectan
Hace 25 años, McCall y Cavano [MCC78] definieron un
juego de factores de calidad como los primeros pasos hacia
el desarrollo de métricas de la calidad del software. Estos
factores evalúan el software desde tres puntos de vista distintos:
(1) operación del producto (utilizándolo), (2) revisión
del producto (cambiándolo), y (3) transición del
producto (modificándolo para que funcione en un entorno
diferente, por ejemplo, «portándolo»). Los autores, en
su trabajo, describen la relación entre estos factores de
calidad (lo que llaman un «marco de trabajo») y otros
aspectos del proceso de ingeniería del software:
En primer lugar, el marco de trabajo proporciona un mecanismo
para que el gestor del proyecto identifique lo que considera
importante. Estas cualidades son atributos del software,
además de su corrección y rendimiento funcional, que tiene
implicaciones en el ciclo de vida. En otros factores, como son
facilidad de mantenimiento y portabilidad, se ha demostrado
que tienen un impacto significativo en el coste del ciclo de vida.. .
En segundo lugar, el marco de trabajo proporciona un medio
de evaluar cuantitativamente lo bien que va progresando el desarrollo
en relación con los objetivos de calidad establecidos.. .
En tercer lugar, el marco de trabajo proporciona más interacción
del personal de QA (garantía de calidad) en el esfuerzo
de desarrollo.. .
Por Último,. . . el personal de garantía de calidad puede utilizar
indicaciones de calidad pobre para ayudar a identificar
estándares [mejores] a enfrentar en el futuro.
Un estudio detallado del marco de trabajo de McCall
y Cavano, así como otros factores de calidad, se presentan
en el Capítulo 19. Es interesante destacar que
casi todos los aspectos del cálculo han sufrido cambios
radicales con el paso de los años desde que McCall y

Cavano hicieron su trabajo, con gran influencia, en 1978.
Pero los atributos que proporcionan una indicación de
la calidad del software siguen siendo los mismos.
a sus usuarios finales-. Cuando la proporción de
desperdicios en el coste global del proyecto (para
muchos proyectos) se representa como una función
del tiempo, el gestor puede determinar si la facilidad
total del software producido por una organización de
desarrollo está mejorando. Se pueden emprender
acciones a partir de las conclusiones obtenidas de
esa información.
Integridad. En esta época de «hackers» y direwalls
», la integridad del software ha llegado a tener
mucha importancia. Este atributo mide la capacidad
%&"E
Sorprendentemente, los factores que definían la calidad
del software en el año 1970 san los mismos factores
que continúan definiendo la calidad del software
en la primera década de este siglo.
¿Qué significa esto? Si una organización de software
adopta un juego de factores de calidad como una «lista
de comprobación» para evaluar la calidad del software,
es probable que el software construido hoy siga exhibiendo
la calidad dentro de las primeras décadas de este
siglo. Incluso, cuando las arquitecturas de cálculo sufren
cambios radicales (como seguramente ocurrirá), el software
que exhibe alta calidad en operación, transición y
revisión continuará sirviendo también a sus usuarios.