COCOMO

El Modelo Constructivo de Costes (o COCOMO, por su acrónimo del inglés Constructive Cost Model) es un modelo de estimación de costes de software que incluye tres submodelos, donde 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.

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

[editar] 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.

[editar] Inconvenientes

• Los resultados no son proporcionales a las tareas de gestión ya que no tiene en cuenta los recursos necesarios para realizar las tareas.
• Se puede desviar de la realidad si indica mal el porcentaje de comentarios en las líneas de código.
• 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 en la orientación a objetos.
• Utilizar esta herramienta puede resultar un poco complicada, en comparación con otros métodos (que también sólo estiman).

[editar] 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 son las líneas de código (en miles)

el resultado es en salarios/mes y horas-hombre.

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

A la vez, cada submodelo también se divide en modos 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 de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio).
• 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 unas fuertes restricciones, que pueden estar relacionadas con la funcionalidad o técnicas. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla.

[editar] 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:

Estos valores son para las fórmulas:

• Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Kl^b)
• Tiempo de desarrollo del proyecto (TDEV) = c*(MM^d)
• 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

[editar] Modelo intermedio

Este añade al modelo básico quince modificadores opcionales para tener en cuenta el entorno de trabajo, incrementando la precisión de la estimación. Como resultado de este ajuste, al resultado de la fórmula general se lo multiplica por los atributos que se deciden utilizar.

Los valores de las constantes a reemplazar en la fórmula son:

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.

[editar] 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:

• 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)
  • DATA: tamaño de la base de datos 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 líneas de código.
  • CPLX: complejidad del producto

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

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

• 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 dependiendo de su calificación es:

[editar] Modelo Detallado

Presenta principalmente dos mejoras respecto al anterior:

• Los factores correspondientes a los atributos son sensibles a la fase sobre la que se realizan las estimaciones, puesto que aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además porque van variando de una etapa a otra.
• Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.

[editar] Enlaces externos

• El modelo COCOMO (Español)
• Ejemplo COCOMO