Este documento describe el modelo COCOMO (Constructive Cost Model), el cual permite estimar el costo, el esfuerzo y el tiempo de planificación de proyectos de desarrollo de software. El modelo considera factores como el tamaño del proyecto, las características del producto, el hardware utilizado, y el personal involucrado. Existen tres modos de desarrollo y tres versiones del modelo (básico, intermedio y detallado) que proveen estimaciones con diferentes niveles de detalle.
3. DEFINICION
Es un modelo que permite estimar el costo, el esfuerzo, y programar la hora de
planificar una nueva actividad de desarrollo de software.
4. OBJETIVOS:
Desarrollar un modelo de estimación de costo y cronograma de proyectos de
software que se adaptara tanto a las prácticas de desarrollo de la década del 90
como a las futuras
Construir una base de datos de proyectos de software que permitiera la calibración
continua del modelo, y así incrementar la precisión en la estimación.
Implementar una herramienta de software que soportara el modelo
Proveer una marco analítico cuantitativo y un conjunto de herramientas y tecnicas
que evaluaran el impacto de las mejores tecnológicas de software sobre los costos y
tiempos en las etapas del ciclo de vida de desarrollo.
5. MODOS DE DESARROLLO
En el modelo COCOMO I uno de los factores más importantes que influye en la duración y el costo de
un proyecto de software es el Modo de Desarrollo. Todo proyecto corresponde a uno de los siguientes
tres modos:
Modo Orgánico: En esta clasificación se encuentran proyectos desarrollados en un ambiente familiar y
familiar y estable. El producto a elaborar es relativamente pequeño y requiere pocas innovaciones
innovaciones tecnológicas en lo que refiere a algoritmos, estructuras de datos e integración de
hardware. Pocos proyectos de modo orgánico han desarrollado productos con más de 50 KSLOC1 de
KSLOC1 de nuevo software.
Ejemplos de software que se encuentran bajo esta clasificación son:
Modelos de negocios
Modelos científicos
Sistemas operativos de pequeña escala
6. Modo Semiacoplado: Es un modelo para productos de software de tamaño y complejidad
media. Las características de los proyectos se consideran intermedias a las de los modos
Orgánico y Empotrado. Esto implica:
Que el equipo de desarrollo:
Tiene un nivel intermedio de experiencia y conocimiento del sistema en desarrollo.
Está conformado por algunas personas con vasta experiencia y otras inexpertas en el
campo de aplicación.
Está constituido por personas con amplios conocimientos sólo en algunos aspectos.
7. Modo Empotrado: En esta clasificación están incluidos proyectos de gran envergadura que
operan en un ambiente complejo con altas restricciones de hardware, software y procedimientos
operacionales, tales como los sistemas de tráfico aéreo.
Ejemplos de software que se encuentran en esta clasificación son:
Sistemas complejos de procesamiento de transacciones
Sistemas operativos de gran escala
8. MODELOS DE ESTIMACIÓN
Cocomo básico
Son los parásitos atmosféricos, el modelo solo-valorado que computa esfuerzo del desarrollo del
software (y coste) en función del tamaño del programa expresado en líneas estimadas del código.
COCOMO se aplica a tres clases de los proyectos del software:
• Los proyectos orgánicos
• los proyectos medios
• Los proyectos empotrados
9. Cocomo intermedio
COCOMO intermedio esfuerzo del desarrollo del software de los cálculos como función del
tamaño del programa y de un sistema de los “conductores del coste” que incluyen el gravamen
subjetivo del producto, del hardware, del personal y de las cualidades del proyecto. Esta
extensión considera un sistema de cuatro “los conductores costados”, cada uno con un número
de cualidades del subsidiario:
Cualidades de producto
Confiabilidad requerida del software
Tamaño de la base de datos del uso
Complejidad del producto
Cualidades del hardware
Entre otros.
10. Cocomo detallado
COCOMO detallado - incorpora todas las características de la versión
con un gravamen del impacto del conductor del coste en cada paso (análisis,
diseño, etc.) del proceso de la tecnología de dotación lógica.
El Modelo Detallado provee los medios para generar estimaciones con mayor
grado de |precisión y detalle. Difiere del Modelo Intermedio en dos aspectos
principales
• Jerarquía de niveles del producto
• Multiplicadores de Esfuerzo (EM Effort Multipliers) sensitivos a las
fases
11. CARACTERISTICAS
Pertenece a la categoría de modelos estimadores basados en estimaciones matemáticas.
Está orientado a la magnitud del producto final, midiendo el "tamaño" del proyecto, en
función de la cantidad de líneas de código, principalmente.
Se presentan tres niveles: básico, intermedio y detallado.
12. 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).
13. CASO PRÁCTICO
Así pues tras saber que son 32 LDC por cada PF por el hecho de ser Visual Basic que es el
resultado de los KLDC será el siguiente:
KLDC=(PDF*Líneas de código por cada PF)/1000=(261,36*32) /1000=8,363 KLDC
Así pues, en nuestro caso el tipo orgánico será el más apropiado ya que el número de líneas de
código no supera los 50 KLDC, y además el proyecto no es muy complejo, por consiguiendo, los
coeficientes que usaremos serán los siguientes:
PROYECTO
SOFTWARE
a e c d
Orgánico 3,2 1,05 2,5 0,38
Semi-acoplado 3,0 1,12 2,5 0,35
Empotrado 2,8 1,20 2,5 0,32
14. RESUMEN
Como se conoce, una de las tareas de mayor importancia en la planificación de
proyectos de software es la estimación, la cual consiste en determinar, con cierto
grado de certeza, los recursos de hardware y software, costo, tiempo y esfuerzo
necesarios para el desarrollo de los mismos. Este modelo permite realizar
estimaciones en función del tamaño del software, y de un conjunto de factores
de costo y de escala. Los factores de costo describen aspectos relacionados con
la naturaleza del producto, hardware utilizado, personal involucrado, y
características propias del proyecto. El conjunto de factores de escala explica las
economías y des economías de escala producidas a medida que un proyecto de
software incrementa su tamaño.
15. SUMMARY
As is known, one of the most important tasks in the project planning software is the
estimate, which is to determine with any degree of certainty, resources, hardware
and software, cost, time and effort needed for development thereof. This model
allows estimates based on the size of the software, and a set of cost factors and
scale. Cost factors describe aspects related to the nature of the product, used
hardware, personnel involved, and characteristics of the project. The set of scale
factors des explains economies and economies of scale produced as a software
project increases its size.
16. RECOMENDACIONES
Se miden los costes del producto, de acuerdo a su tamaño y otras características
pero no la productividad.
Loa 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 solo estiman).
17. CONCLUSIÓN
En conclusión; este Cocomo I es uno de los modelos más documentados
en la actualidad por su facilidad de utilizar. Es correcto con referencia a
los 63 proyectos utilizados, aunque de ello no se debe desprender que
deba ser valido siempre. Una preocupación es la adaptación de las
ecuaciones exponenciales a organizaciones específicas, cosa que no
parece inmediatamente fácil.
18. APRECIACIÓN DEL EQUIPO
El hecho que el modelo ayuda a un estimador a comprender mejor la complejidad
del software; este método es un ejemplo de variable simple inmóvil y es usado por
miles de administradores de proyecto de software
19. GLOSARIO
Impacto: Choque violento de una cosa en movimiento contra otra; especialmente de un
proyectil contra un blanco.
Empotrado:
Que está completamente metido dentro de una cosa, generalmente a causa de un choque
Envergadura: Importancia, amplitud, alcance
Delegar: Proviene del verbo delegaré cuyo significado es remitir, transferir, imputar, atribuir.
Transacción: interacción con una estructura de datos compleja, donde los procesos deben
aplicarse uno después del otro de manera similar a una interacción atómica.
Acarrear: Ocasionar o provocar algún daño:
Gravamen: es una carga (una obligación, impuesto o tributo que se aplica a un inmueble
