Universidad de la integracin de las amricas.

Material de investigacin: COCOMO (Modelo Constructivo de Costos)

Bernardo Javier Blanco Segovia

-Auditoria Informtica

COCOMO (Modelo Constructivo de Costos) El modelo constructivo de costes (Constructive Cost Model) que fue desarrollado por Barry W. Boehm a finales de los aos 70, en 1981 en la publicacin de su libro "Software Engineering Economics" fue puesto en detalle. COCOMO es un modelo matemtico de base emprica utilizado para estimacin de costos de software Como caractersticas principales cuenta con las siguentes : - Est basado en modelos de estimaciones matemticas. - Est orientado al producto final, no a fases intermedias. - Se basa en la cantidad de lneas de codigo del proyecto. Razones para elegir COCOMO: - Se ha utilizado y evaluado ampliamente - Est bien documentado, es del dominio pblico y lo apoyan el dominio pblico y las herramientas comerciales

COCOMO 81: Primera versin de COCOMO en 1981, fue un modelo de 3 niveles donde estos reflejaban el detalle del anlisis de la estimacin del coste. Este supone que el software se desarrolla segn un proceso en cascada, sin embargo ha habido cambios radicales en el desarrollo de software desde que se propuso esta versin. COCOMO II: Considera diferentes enfoques para el desarrollo de software, engloba vario niveles que producen estimaciones detalladas de forma incremental. Adems soporta el modelo de desarrollo en espiral Modelos de estimacin La ecuaciones que se utilizan en los tres modelos son:2

, en persona-mes , en meses , en personas E: es el esfuerzo requerido por el proyecto, en persona-mes Tdey: es el tiempo requerido por el proyecto, en meses P: es el nmero de personas requerido por el proyecto a, b, c y d: son constantes con valores definidos en una tabla, segn cada submodelo Kl_ es la cantidad de lneas de cdigo, en miles. m(X): Es un multiplicador que depende de 15 atributos.

Otra ecuacin de estimacin del esfuerzo de desarrollo tienen una forma:

Dnde: -S: es el nmero de miles de lneas de cdigo fuente -m(X): es un multiplicador que depende de 15 atributos. -En la siguiente tabla se muestra el resto de los atributos. Bsico Intermedio Modo ai bi ai bi Orgnico 2.4 1.05 3.2 1.05 Semiencajado Empotrado 3.0 3.6 1.12 1.2 3.0 2.8 1.12 1.2

A la vez, cada submodelo tambin se divide en modos que representan el tipo de proyecto, y puede ser: modo orgnico: un pequeo grupo de programadores experimentados desarrollan software en un entorno familiar. El tamao del software vara desde unos pocos miles de lneas (tamao pequeo) a unas decenas de miles (medio). modo semilibre o semiencajado: corresponde a un esquema intermedio entre el orgnico y el rgido; el grupo de desarrollo puede incluir una mezcla de personas experimentadas y no experimentadas. modo rgido o empotrado: el proyecto tiene fuertes restricciones, que pueden estar relacionadas con la funcionalidad y/o pueden ser tcnicas. El problema a resolver es nico y es difcil basarse en la experiencia, puesto que puede no haberla. Modelo Bsico El modelo bsico se usa para obtener una aproximacin rpida del esfuerzo, usa las variables a, b, c y d, que varan en funcin de los modos. conforme se aumenta la complejidad del modo, aumentan los valores de las variables (esfuerzo). MODO Orgnico a b c d

2.40 1.05 2.50 0.38

Semilibre 3.00 1.12 2.50 0.35 Rgido 3.60 1.20 2.50 0.32

Estos valores son para las frmulas:

Personas necesarias por mes para llevar adelante el proyecto (MM) = a*(Klb) d Tiempo de desarrollo del proyecto (TDEV) = c*(MM ) 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 bsico puesto que se obvian muchas caractersticas del entorno Modelo intermedio Aade al modelo bsico 15 factores de ajuste o guas de coste. logramos mayor precisin en la estimacin gracias a los nuevos factores, la frmula es la misma que la del modelo bsico pero con el aadido del factor (multiplicando).

Los valores de las constantes a reemplazar en la frmula son: MODO Orgnico a b

3.20 1.05

Semilibre 3.00 1.12 Rgido 2.80 1.20

Se puede observar que los exponentes son los mismos que los del modelo bsico, confirmando el papel que representa el tamao; mientras que los coeficientes de los modos orgnico y rgido 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 calificacin de cada atributo, se asigna un valor para usar de multiplicador en la frmula (por ejemplo, si para un proyecto el atributo DATA es calificado como muy alto, el resultado de la frmula debe ser multiplicado por 1000). El significado de los atributos es el siguiente, segn su tipo: De software

RELY: garanta 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 prdida de vidas humanas (extremadamente alto, software de alta criticidad).

DATA: tamao de la base de datos en relacin con el tamao del

programa. El valor del modificador se define por la relacin: D/K donde D corresponde al tamao de la base de datos en bytes y K es el tamao del programa en cantidad de lneas de cdigo. CPLX: representa la 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 mquina virtual. TURN: tiempo de respuesta requerido. De personal

ACAP: calificacin de los analistas.

AEXP: experiencia del personal en aplicaciones similares. PCAP: calificacin de los programadores. VEXP: experiencia del personal en la mquina virtual. LEXP: experiencia en el lenguaje de programacin a usar. De proyecto

MODP: uso de prcticas modernas de programacin. TOOL: uso de herramientas de desarrollo de software. SCED: limitaciones en el cumplimiento de la planificacin.

Modelo Detallado Presenta principalmente dos mejoras respecto al anterior: Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicacin, utilizacin de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y adems van variando de una etapa a otra. Establece una jerarqua de tres niveles de productos, de forma que los aspectos que representan gran variacin a bajo nivel, se consideran a nivel mdulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema.