Modelo Cocomo
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.
Barry Boehm en su libro “economía de la ingeniería de software” detalla un modelo amplio de estimación de costos llamado COCOMO (Constructive Cost Model). La palabra “constructive” se refiere a el hecho que el modelo ayuda a un estimador a comprender mejor la complejidad del software; este modelo es un ejemplo de variable simple estático y es usado por miles de administradores de proyecto de software .
COCOMO ayuda a estimar el esfuerzo, tiempo, gente y costos (ya sea estos de desarrollo, equipamiento y mantenimiento).
El modelo provee tres “niveles” de aplicación: básico, intermedio y avanzado, basados en los factores considerados por el modelo.
- Básico, es un modelo estático simplemente evaluado que calcula el esfuerzo (y costo) del desarrollo del software como función del programa expresado en líneas de código (LDC estimados).
- Intermedio, calcula el esfuerzo del desarrollo del software como función del tamaño del programa y un conjunto de “guías de costo” que incluye una evaluación subjetiva del producto, hardware, personal y de los atributos del proyecto.
- Avanzado, incorpora todas las características de la versión intermedia con una evaluación del impacto de las vías de costo en cada fase (análisis, diseño, etc) del proceso de la ingeniería de software.
El modelo básico se extiende para considerar un conjunto de atributos de guías de costo que pueden agruparse en cuatro categorías principales:
- Producto ( por ej. Requerimientos de software, confiabilidad, tamaño de la base de datos, y complejidad del producto).
- Computadora (por ej. Restricciones en el tiempo de ejecución y almacenamiento).
- Personal (por ej. Capacidad de análisis, experiencia en aplicaciones tanto en lenguajes de programación y capacidad del programador)
- Proyecto (por ej. Uso de practicas modernas de programación, uso de herramientas de software y requerimiento de un plan de desarrollo).
En cada nivel de aplicación están definidos para tres tipos de proyectos de software:
- Modo orgánico, proyectos de software relativamente pequeños y sencillos en los que pequeños equipos con buena experiencia en la aplicación trabajan en un conjunto de requerimiento poco rígidos.
- Modo semi-acoplado(semi-detached), un proyecto de software intermedio en tamaño y complejidad en el cual equipos con distintos niveles de experiencia debe satisfacer requerimientos poco y medio rígidos
- Modo acoplado(detached), un proyecto de software que debe ser desarrollado dentro un conjunto estricto de hardware, software y de restricciones operativas.
Modos que están basados en la complejidad de la aplicación y el desarrollo del ambiente. El modelo de esfuerzo general aplicable a todos los niveles de aplicación y modos está dado por :
Donde:E = es el esfuerzo estimado expresado en hombres-mes
EDSI es el número estimado de líneas de código distribuidas en miles para el proyecto
a, h son constantes determinadas por el modo del desarrollo, ambos incrementados por la complejidad de la aplicación.
EAF es el factor de ajuste de esfuerzo, es igual a 1 para la modelo básica e igual al producto de 15 factores de costo para la modelo intermedia y avanzada. Cada factor de costo multiplicativo es reflexivo de un incremento proporcional (> 1) o decremento (<1) en costo.
A continuación veremos los coeficientes para el modelo intermedio que depende de modo de desarrollo:
| MODO DE DESARROLLO |
A
|
b
|
c
|
d
|
| Organic | 3.2 | 1.05 | 2.5 | 0.38 |
| Semi-detached | 3.0 | 1.12 | 2.5 | 0.35 |
| Embedded | 2.8 | 1.20 | 2.5 | 0.32 |
Modo básico utiliza el tamaño y el modo intermedio 15 manejadores de costo que son los siguientes:
| Manejadores de Costo | Very Low | Low | Nominal | High | Very High | Extra High |
| ACAP Analyst Capability | 1.46 | 1.19 | 1.00 | 0.86 | 0.71 | - |
| AEXP Applications Experience | 1.29 | 1.13 | 1.00 | 0.91 | 0.82 | - |
| CPLX Product Complexity | 0.70 | 0.85 | 1.00 | 1.15 | 1.30 | 1.65 |
| DATA Database Size | - | 0.94 | 1.00 | 1.08 | 1.16 | - |
| LEXP Language Experience | 1.14 | 1.07 | 1.00 | 0.95 | - | - |
| MODP Modern Programming Practices | 1.24 | 1.10 | 1.00 | 0.91 | 0.82 | - |
| PCAP Programmer Capability | 1.42 | 1.17 | 1.00 | 0.86 | 0.70 | - |
| RELY Required Software Reliability | 0.75 | 0.88 | 1.00 | 1.15 | 1.40 | - |
| SCED Required Development Schedule | 1.23 | 1.08 | 1.00 | 1.04 | 1.10 | - |
| STOR Main Storage Constraint | - | - | 1.00 | 1.06 | 1.21 | 1.56 |
| TIME Execution Time Constraint | - | - | 1.00 | 1.11 | 1.30 | 1.66 |
| TOOL Use of Software Tools | 1.24 | 1.10 | 1.00 | 0.91 | 0.83 | - |
| TURN Computer Turnaround Time | - | 0.87 | 1.00 | 1.07 | 1.15 | - |
| VEXP Virtual Machine Experience | 1.21 | 1.10 | 1.00 | 0.90 | - | - |
| VIRT Virtual Machine Volatility | - | 0.87 | 1.00 | 1.15 | 1.30 | - |
El tiempo de desarrollo es igual a :
Donde:
E, es el esfuerzo
c,d son coeficiente, cuyos valores se indicaron anteriormente en una tabla.
El número de programadores es igual a:
Representando un enfoque monolítico para la estimación de costos, a
Razones para elejir COCOMO
- Se a utilizado y evaluado ampliamente
- Esta bien documentado, es del dominio publico y lo apoyan el dominio publico y las herramientas comerciales.
COCOMO II
Considera diferentes enfoques para el desarrollo de software, engloba varios niveles que producen estimaciones detalladas de forma incremental . Ademas soporta el modelo de desarrollo en espiral.
BIBLIOGRAFIA
http://acevedodelacru.wordpress.com/modelo-cocomo-2/
Libro “economía de la ingeniería de software” de Barry Boehm
http://acevedodelacru.wordpress.com/modelo-cocomo-2/
Libro “economía de la ingeniería de software” de Barry Boehm
http://es.wikipedia.org/wiki/COCOMO
http://acevedodelacru.wordpress.com/ejemplo-1/

No hay comentarios:
Publicar un comentario