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).
Contenido
|
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 realizar las tareas.
- Se puede desviar de la realidad debido a la existencia de comentarios en las líneas de código.
- No es objetivo puesto que se realizan estimaciones sobre estimaciones del número de líneas de código que tendrá nuestro proyecto.
- Se mide el producto, o su tamaño, cosa totalmente diferente a medir la productividad.
- La medición por líneas de código no tienen sentido en la orientación a objetos.
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.
- 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.
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 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:
| 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:
- 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:
| 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,15 | 1,30 | ||
| 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 lenguage | 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 | |
4. 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.
4.1. 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.
No hay comentarios:
Publicar un comentario