Metrica  Orientada al Tamaño 

(COCOMO: Modelo contructivo de costes)

• El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés COnstructive COst MOdel) es un modelo matemático de base empírica utilizado para estimación de costes[1] 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 en modos que representan el tipo de proyecto, y puede ser:

1. 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).
2. 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.
3. 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.

Modelo básico

Se utiliza para obtener una primera aproximación rápida del esfuerzo, y hace uso de la siguiente tabla de constantes para calcular distintos aspectos de costes:

MODO	a	b	c	d
Orgánico	2.40	1.05	2.50	0.38
Semilibre	3.00	1.12	2.50	0.35
Rígido	3.60	1.20	2.50	0.32

Estos valores son para las fórmulas:

• Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb)
• Tiempo de desarrollo del proyecto (TDEV) = c*(MMd)
• Personas necesarias para realizar el proyecto (CosteH) = MM/TDEV
• Costo total del proyecto (CosteM) = CosteH * Salario medio entre los programadores y analistas.

Se puede observar que a medida que aumenta la complejidad del proyecto (modo), las constantes aumentan de 2.4 a 3.6, que corresponde a un incremento del esfuerzo del personal. Hay que utilizar con mucho cuidado el modelo básico puesto que se obvian muchas características del entorno
Modelo intermedio
Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.
Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar.
Los valores de las constantes a reemplazar en la fórmula son:

MODO	a	b
Orgánico	3.20	1.05
Semilibre	3.00	1.12
Rígido	2.80	1.20

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

Atributos

Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo - bajo - nominal - alto - muy alto - extremadamente alto. Dependiendo de la calificación de cada atributo, se asigna un valor para usar de multiplicador en la fórmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la fórmula debe ser multiplicado por 1000).

El significado de los atributos es el siguiente, según su tipo:

1. De software

• RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad).
• DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la relación: D / K, donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código.
• CPLX: representa la complejidad del producto.

    2.     De hardware

• TIME: limitaciones en el porcentaje del uso de la CPU.
• STOR: limitaciones en el porcentaje del uso de la memoria.
• VIRT: volatilidad de la máquina virtual.
• TURN: tiempo de respuesta requerido.

   3.  De personal

• ACAP: calificación de los analistas.
• AEXP: experiencia del personal en aplicaciones similares.
• PCAP: calificación de los programadores.
• VEXP: experiencia del personal en la máquina virtual.
• LEXP: experiencia en el lenguaje de programación a usar.

  4. De proyecto

• MODP: uso de prácticas modernas de programación.
• TOOL: uso de herramientas de desarrollo de software.
• SCED: limitaciones en el cumplimiento de la planificación.

El valor de cada atributo, de acuerdo a su calificación, se muestra en la siguiente tabla:

Atributos	Valor
	Muy bajo	Bajo	Nominal	Alto	Muy alto	Extra alto
Atributos de software
Fiabilidad	0,75	0,88	1,00	1,15	1,40
Tamaño de Base de datos		0,94	1,00	1,08	1,16
Complejidad	0,70	0,85	1,00	1,15	1,30	1,65
Atributos de hardware
Restricciones de tiempo de ejecución			1,00	1,11	1,30	1,66
Restricciones de memoria virtual			1,00	1,06	1,21	1,56
Volatilidad de la máquina virtual		0,87	1,00	1,15	1,30
Tiempo de respuesta		0,87	1,00	1,07	1,15
Atributos de personal
Capacidad de análisis	1,46	1,19	1,00	0,86	0,71
Experiencia en la aplicación	1,29	1,13	1,00	0,91	0,82
Calidad de los programadores	1,42	1,17	1,00	0,86	0,70
Experiencia en la máquina virtual	1,21	1,10	1,00	0,90
Experiencia en el lenguaje	1,14	1,07	1,00	0,95
Atributos del proyecto
Técnicas actualizadas de programación	1,24	1,10	1,00	0,91	0,82
Utilización de herramientas de software	1,24	1,10	1,00	0,91	0,83
Restricciones de tiempo de desarrollo	1,23	1,08	1,00	1,04	1,10

Modelo Detallado

  Este modelo puede procesar todas las características del proyecto para construir una estimación. Introduce dos características principales

  (1) Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase del proyecto.(2) Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al que es más susceptible la variación.

 Estimación del esfuerzo.

A. Fases de desarrollo

 El desarrollo del software se lleva a cabo a través de cuatro fases consecutivas: requerimientos/planes, diseño del producto, programación y prueba/integración.

Requerimientos/planes. Esta es la primera fase del ciclo de desarrollo. Se analiza el requerimiento, se muestra un Plan de Producto y se general una especificación completa del producto. Esta fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al 40% del tiempo nominal de desarrollo td. Estos porcentajes dependen del modo y del tamaño (de 2000 LOC a 512000 LOC).

Diseño del producto. La segunda fase del ciclo de desarrollo COCOMO se preocupa de la determinación de la arquitectura del producto y de las especificaciones de los subsistemas. Esta fase requiere del 16% al 18% del esfuerzo nominal Kn, y puede durar del 19% al 38% del tiempo nominal de desarrollo td.

Programación. La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos subfases: diseño detallado y prueba del código. Esta fase requiere del 48% al 68% del esfuerzo nominal Kn, y dura del 24% Al 64% del tiempo nominal de desarrollo.

Prueba/Integración. Esta última fase consiste principalmente en unir las diferentes unidades ya probadas. Se utiliza del 16% al 34% del coste nominal Kn y dura del 18% al 34% del td.

B. Principio de estimación del esfuerzo.

   B.1. Tamaño equivalente. Como parte del software puede haber sido ya desarrollado, no se requiere entonces un desarrollo completo. En tales casos se estiman las partes de diseño (D%), código (C%) e integración (I%) a ser modificadas. Se calcula un factor de ajuste A

            A = 0.4 D + 0.3 C + 0.3 I

            El tamaño equivalente, Sequ es            Sequ = (S • A) / 100.

  B.2. Cálculo del esfuerzo. El tamaño equivalente se calcula para cada módulo. El esfuerzo asignado al desarrollo de cada módulo se obtiene entonces a través de:

     (1) seleccionar los valores apropiados de los atributos de coste para cada fase

     (2) multiplicar los atributos de coste para cada módulo y fase, obteniendo un conjunto de 4 multiplicadores globales

     (3) multiplicar los atributos globales por el esfuerzo nominal en cada fase y sumarlos para obtener el esfuerzo total estimado.

Métricas orientadas a la función.

La medida de punto de función se propuso en 1979 y trata de medir la funcionalidad o utilidad del software. 1.    Hay que completar la siguiente tabla de valores del dominio de la información:

Parámetro	Cuenta	Factor de ponderación			Subtotal
		Simple	Medio	Complejo
Número de entradas de usuario		3	4	6
Número de salidas de usuario		4	5	7
Número de peticiones de usuario		3	4	6
Número de archivos		7	10	15
Número de interfaces externas		5	7	10
Total

2.    donde:

•     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

 Indicaciones:

•     Contar cada medida por separado. 
•    Asociar, de alguna manera, un valor de complejidad a cada medida. La siguiente tabla muestra una heurística para decidir la complejidad de todo el sistema. 

Tipos de archivos referenciados	Tipos de datos elementales
	1-5	6-19	20+
0-1	bajo	bajo	medio
2-3	bajo	medio	alto
4+	medio	alto	alto

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

4.    El punto de función FP se calcula con la siguiente ecuación:

PF = T * (0.65 + 0.01 * F).

Métricas

o    Errores por PF.

o    Defectos por PF.

o    Costo por PF.

o    Página de documentación por PF.

o    PF por hombre-mes.

Métricas ampliadas de punto de función.

Los puntos de función fueron diseñados originalmente para sistemas de información y por eso le da más importancia a los datos y menos a los aspectos de control y funcionales. Para subsanar esto, se han propuesto los puntos de característica y los puntos de función 3D.

Puntos de característica.

Se calcula igual que el punto de función y solo agrega la cuenta de algoritmos. En este contexto se define un algoritmo como un problema de cálculo limitado que se incluye dentro de un programa de computadora específico. Invertir una matriz, decodificar un string o manejar una interrupción son ejemplos de algoritmos.

Puntos de función 3D.

Los puntos de función 3D se calculan llenando la siguiente tabla:

Elemento de medición	Pesos de complejidad												Subtotal
	Bajo				Medio				Alto
Estructuras internas de datos		*	7	+		*	10	+		*	15	=
Datos externos		*	5	+		*	7	+		*	10	=
Número de entradas de usuario		*	3	+		*	4	+		*	6	=
Número de salidas de usuario		*	4	+		*	5	+		*	7	=
Número de peticiones de usuario		*	3	+		*	4	+		*	6	=
Transformaciones		*	7	+		*	10	+		*	15	=
Transiciones				+				+				=
Punto de función 3D

Punto de función 3D     

donde:

•     Estructuras internas de datos. Son arreglos, listas ligadas, pilas, colas, etc.
•     Datos externos. Equivale a la suma de los archivos y las interfaces externas tal y como están definidos para el punto de función.
•     Entradas de usuario. Definidas igual que para el punto de función.
•     Salidas de usuario. Definidas igual que para el punto de función.
•     Peticiones de usuario. Definidas igual que para el punto de función.
•     Transformaciones. Son las operaciones internas requeridas para transformar datos de entrada en datos de salida. Multiplicar dos matrices cuenta como una transformación. Leer datos de un archivo y guardarlos en memoria no.
•     Transiciones. Ocurre cuando el software pasa de un estado a otro como resultado de algún suceso. En un sistema de altas, bajas y cambios, al tomar la opción de altas, pasa del estado "menú principal" al estado "procesa altas" y puede ser que en ese momento pida datos para dar la alta.

Indicaciones:

•     Para cada medida, contar por separado, de acuerdo a algún criterio de asignación de complejidad, las veces que aparezca con complejidad baja, media y alta.
•     Para cada medida, multiplicar cada cuenta por el factor de complejidad correspondiente, sumar las tres cantidades y escribir el total en la columna de la extrema derecha.
•     Sumar la columna de la extrema derecha y obtener el punto de función 3D.

Funcionalidad de los lenguajes de programación

La tabla siguiente proporcional estimaciones informales del número de líneas de código que se necesitan para construir un punto de función en varios lenguajes de programación:

Lenguaje	LOC/PF
Ensamblador	320
C	128
Cobol	105
Fortran	105
Pascal	90
Ada	70
OOL	30
4GL	20
Generadores de código	15
Hojas de cálculo	6
Lenguajes de íconos	4

Metricas de Calidad

• Corrección: medir la funcionalidad del software(para lo que fue hecho).
• Facilidad de Mantenimiento: facilidad para corregir errores y adaptarse a los cambios.
• Integridad: medir la capacidad del sistema para resistir ataques accidentales o intencionales en su seguridad.

Integridad= 1-(amenaza*(1-seguridad)

Amenaza =probabilidad que un ataque suceda en un tiempo determinado.

Seguridad = probabilidad de que se repela la amenaza.

• Facilidad de uso: se mide en términos de interfaz de usuario.

Eficacia en la eliminación de defectos

Cuando se considera un proyecto como un todo se define:

EED=  E/ (E+D)

E: numero de errores encontrados antes de entregar el software al usuario final

D: numero de defectos encontrados después de la entrega.

Nota: El valor ideal de EDD es 1

Al aplicarla antes de que ocurra una  actividad  se define como:

EEDi= Ei/(Ei+Ei+1)

Ei: numero de errores encontrados durante la actividad

Ei+1: numero de errores encontrados durante la actividad i+1 de ingeniería del software.

Métricas para las Pequeñas Organizaciones

• Tiempo transcurrido desde el momento en que se hizo la solicitud hasta que la evaluación esta completa
• Esfuerzo para realizar la evaluación.
• Tiempo transcurrido desde que se completa la evaluación hasta la asignación del pedido de cambio de personal.
• Esfuerzo requerido para hacer el cambio.
• Tiempo requerido para hacer el cambio.
• Errores descubiertos durante el trabajo para hacer el cambio.
• Defectos descubiertos después de que el cambio es liberado a la base de cliente.

Establecimiento de un programa de métricas de software.

Esta dirigido por metas según  el instituto de ingenieros de software(SEI) y define los siguientes pasos:

• Identificar los objetivos de la empresa.
• Identificar lo que se requiere conocer o aprender.
• Identificar los sub-objetivos.
• Identificar las entidades y atributos relacionados con los objetivos secundarios.
• Formalizar los objetivos de la medición.
• Identificar preguntas cuantificables y los indicadores relacionados que se emplearan como apoyo para lograr los objetivos de sus mediciones.
• Identificar los elementos de datos que se recopilaran para  construir los indicadores que ayudaran a responder las preguntas.
•  definir las medidas que se emplearan y hacer que estas definiciones sean operativas.
• Identificar acciones que se tomaran para implementar las medidas.

El personal de software desarrolla una serie de preguntas relacionadas con características cuantitativas por ejemplo, tamaño, costo, tiempo de desarrollo, estas preguntas se derivan de sub-objetivos relacionadas con la s entidades y actividades realizadas como parte del proceso de software.

Para esto se puede derivar la siguiente lista de preguntas:

¿la solicitud del cambio del cliente contiene la información requerida para evaluar adecuadamente el cambio y luego implementarlo en una forma oportuna?

¿Cuan grande es el registro de petición de cambio?

Bibliografia Utilizada:

Roger S Pressman, Ingenieria del Software Un enfoque Practico, Quinta Edicion, Editorial MacGrawHill.

Casos de estudio Aplicando el programa de Metricas

Caso de Estudio #1: Fundacion FES

Programa de Métricas

1.    Objetivos del Negocio.

Automatizar sus actividades a fin de mejorar la Gestión de Fondos asignados a los diversos programas.

2.    Nuevos saberes/Aprendizajes.

La Fundación Friedrich Ebert (FES) fue creada en 1925 como legado político de Friedrich Ebert, el primer presidente alemán elegido democráticamente. La Fundación es una institución político-cultural privada, sin fines de lucro, comprometida con los principios y los valores fundamentales de la democracia social.

El trabajo de la Fundación tiene como objetivo fomentar la participación, el pluralismo y la justicia social así como fortalecer el estado de derecho y promover la búsqueda de soluciones pacíficas de conflictos en la esfera estatal y en la sociedad civil. La FES trabaja con partidos políticos, sindicatos, instituciones de investigación y enseñanza, movimientos cívicos y organizaciones de la sociedad civil; igualmente, con entidades estatales y organismos internacionales.

En sus prioridades de trabajo, las oficinas de la FES se orientan por sus cometidos principales, los grandes retos políticos globales y por las necesidades de sus respectivas contrapartes. La asesoría política, la formación socio-política y el intercambio internacional de experiencias se realizan mediante consultorías, conferencias, seminarios y talleres.

El trabajo internacional de la FES es financiado, en su mayor parte, con fondos proporcionados por el Ministerio Federal de Cooperación Económica y Desarrollo y el Ministerio Federal de Relaciones Exteriores. Con recursos de otros organismos, entre ellos de la Unión Europea, se financian numerosos proyectos específicos.

3.    Subojetivos.

Mejorar la  Gestión de Fondos asignados a los programas Nicas y control de:

• Agenda de Eventos:
• Lugar.
• Fecha
• Participantes
• Invitaciones.
• Confirmación.
• Llenado de datos.
• Exponencias
• Temas.
• Documentos.
• Materiales de Apoyo.
• Informes.
• Publicación.
• Refrigerios y Alimentos.

4.    Entidades y atributos de los Subojetivos.

 

5. Objetivos de Medición.



Nuestros objetivos con respecto a la medición del Software es tratar de que el mismo trabaje con gran funcionalidad y eficiencia del cual tratamos de que se realice con gran calidad para que no haya problemas en el momento de la implementación. Así como que tenga la facilidad de darle mantenimiento o control de errores para que no haya ningún tipo de problema. Todo esto con el fin de crear un software que se ha muy fiable y de gran particularidad y que se ha de agrado a la Fundación.

6. Preguntas Cuantitativas e Indicadores relacionados.

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ía 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 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 conversi6n y la instalaci6n?
13. ¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?
14. ¿Se ha diseñado la aplicaci6n para facilitar los cambios y para ser fácilmente utilizada por el usuario?


Cada una de las preguntas anteriores es respondida usando una escala con rangos desde 0 (no importante o aplicable) hasta 5 (absolutamente esencial).Los valores constantes de la ecuación (1) y los factores de peso que se aplican a las cuentas de los dominios de información se determinan empíricamente. Una vez que se han calculado los puntos de función, se utilizan de forma análoga a las líneas de código como forma de normalizar las medidas de productividad, calidad y otros atributos del software.


Una vez calculado los puntos de función se usan de forma analógica a las líneas de código como medida de la productividad, calidad y otros productos del software.

7. Recolecta de datos y cálculos de indicadores.
Según el modo y el modelo, mis constantes tienen los valores siguientes:

A	B	C	D
3.00	1.12	2.50	0.35

PF= CUT * (0.65 + 0.01 * )

Para calcular el CUT se hace lo siguiente:

Parámetro	#	Simple	Medio	Complejo	Subtotal
#Entradas	40	3	4	6	=160
#Salidas	16	4	5	7	=80
#Peticiones	16	3	4	6	=64
#Archivos	15	7	10	15	=150
#Interfaz	26	5	7	10	=260
				CUT	= 714

Esto es para determinar los Factores ∑ F

#	Rango(0-5)
1	5
2	3
3	3
4	5
5	5
6	5
7	5
8	5
9	3
10	3
11	5
12	1
13	1
14	5