MODELO COCOMO

Modelo Constructivo de Costos

(COnstructive COst Model)
Ingeniería de Software
 Andrea Vecino
 Yadith Miranda
 Verónica Obregón
 Andrés Barrios
 David Pava

Tecnología en Sistemas
(VI Semestre)
 ¿Qué es el Modelo COCOMO?
 Cocomo es un modelo diseñado por Barry
W. Boehm para dar una estimación de el
número de meses hombre que tomará
para desarrollar un producto software.

 Es un modelo matemático de base empírica

utilizado para estimación de
costos 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: Básico, Intermedio y Detallado.

3
 Simple: proyectos pequeños de < 50KLDC,
en los cuales se tiene experiencia de
proyectos similares

 Moderado: proyectos de complejidad

media(< 300 KLDC) donde la experiencia es
variable.

 Incrustado: proyectos bastante complejos

donde la experiencia es nula y se utiliza
tecnología realmente de frontera.
 Estimación LDC y PF

Las estimaciones de LDC y PF son técnicas de

estimación distintas:

LDC (Orientadas al tamaño)

PF (Orientadas a la función)

Los datos de LDC y PF se utilizan de dos formas

durante la estimación del proyecto de software.
Técnicas de Estimación

El valor esperado para la variable de

estimación, E, puede
obtenerse como una media ponderada de las
estimaciones
LDC o PF optimista (a), más probable (m), y
pesimista (b) de
las estimaciones LDC o PF por ejemplo:

E = (a + 4m + b)/6

EJEMPLO: LDC
Modelos de Punto de Función
Este modelo se crea como una alternativa a la
estimación del tamaño de un producto software
mediante LDC (Líneas de Código Fuente).

El método de estimación de puntos de función se

utiliza para determinar el tamaño del software.

Están orientadas a la función es decir se centran en

la funcionalidad o utilidad del programa.

PF= ConteoTotal * [0,65 + 0,01 *

∑ (Fi )] EJEMPLO
Trabaja en Función de 3
Submodelos:
 Modelo Básico
 Modelo Intermedio
 Modelo Detallado
MODELOS DE ESTIMACION
 Las ecuaciones que se utilizan en los tres modelos son:
 , en persona-mes
 , en meses
 , en personas
 donde:
 E es el esfuerzo requerido por el proyecto, en persona-
mes
 Tdev es el tiempo requerido por el proyecto, en meses
 P es el número de personas requerido por el proyecto
 a, b, c y d son constantes con valores definidos en una
tabla, según cada submodelo
 Kl es la cantidad de líneas de código, en miles.
 m(X) Es un multiplicador que depende de 15 atributos.
El modelo COCOMO básico

E= a (KLOC) b

E= esfuerzo (hombre/mes)
KLOC= número (miles)
estimado de líneas de código
del proyecto.
Tiempo de desarrollo:

D= c (E) d
La Variable “a” es un factor constante
que depende de las practicas
organizacionales locales y del tipo de
software que se desarrolla.

La variable b por lo general se

encuentra entre (1;1.5), refleja el
esfuerzo requerido en la mayoria de
proyectos
 Coeficientes a usar:

PROYECTO a b c d Descripción
SOFTWARE

Simple 3,2 1,05 2,5 0,38 Aplicaciones bien comprendidas

desarrolladas por equipos pequeños

Moderada 3,0 1,12 2,5 0,35 Proyectos más complejos donde los
miembros del equipo tienen experiencia
limitada en sistemas relacionados
Incrustada 2,8 1,20 2,5 0,32 Proyectos complejos donde el software es
parte de un complejo fuertemente acoplado
de hardware, software, reglas y
procedimientos operacionales.
 Ejemplo:
Supongamos que una empresa cualquiera
desea diseñar un proyecto que gestione sus
inventarios y decide desarrollarlo mediante su
propio equipo de analista y programadores que
anteriormente y durante muchos años, vienen
desarrollando aplicaciones similares en la
misma empresa.

Si un estudio inicial determina que el tamaño

del producto en alrededor de 32 000 líneas de
programa fuente (32 KLOC). Cuales serán las
características del proyecto?.
 •Esfuerzo:

E = 2.4 (32)1.05 E = 91 hombres-mes

•Tiempo de desarrollo:

D= c (E)d D = 2.5 (91)0.38 = 14 meses

b
•Número de personas trabajando en el proyecto:

N = 91/14 = 6.5 hombres

 Ejemplo: LDC
Considerar un paquete de software a desarrollar para una aplicación de diseño
asistido por computador (CAD). Revisando la especificación del sistema
encontramos que el software va ejecutarse en una estación de trabajo de
microcomputadora y se conectará con varios periféricos gráficos incluyendo
ratón, digitalizador, pantalla en color de alta resolución, y una impresora de alta
resolución.

La evaluación del alcance indica que se requieren las siguientes

funciones principales para el software de CAD:
* Interfaz de usuario y facilidades de control (IUCF)
* Análisis geométrico bidimensional (AG2D)
* Análisis geométrico tridimensional (A3GD)
* Gestión de estructuras de datos (GED)
* Facilidades de visualización de gráficos de computadora (FVGC)
* Control de periféricos (CP)
* Módulos de análisis de diseño (MAD)
 SOLUCION
Función Optimista Más Pesimista Esperado
probable

Control de interfaz de 1800 2400 2650 2340

usuario
Análisis geométrico en 4100 5200 7400 5380
2-D
Análisis geométrico en 4600 6900 8600 6800
3-D
Gestión de la estructura 2950 3400 3600 3350
de datos
Visualización de 4050 4900 6200 4950
gráficos en la
computadora
Control periféricos 2000 2100 2450 2140
Análisis de diseño 6600 8500 9800 8400

33360
REGRESAR LDC estimadas
 Sensores
Contraseña

Consulta de zona
Función E
Usuario Consulta de sensor
Interacción De
Usuario En
Hogar Seguro
Botón de pánico Usuario

Activar/Desactivar

Subsistema
Datos De Configuracion Del Sistema De Monitoreo
Y Respuesta
 SOLUCION
 Se muestra 3 entradas externas (contraseña, botón de pánico y
activar/desactivar) junto con 2 consultas externas(consulta de zona y
consulta de sensor). Se muestra ALI (archivo de configuración del sistema).
También están presentes 2 salidas de usuarios( mensajes y estatus del
sensor) y 4 AIE (sensor de prueba, configuración de zona, activar
/desactivar y alerta de alarma)
 PREGUNTAS para determinar los factores de ajustes de valor Fi en PF:
1) ¿El sistema requiere respaldo y recuperación confiables?
2) ¿Se requieren comunicaciones de datos especializados para transferir
información a la aplicación, u obtenerla de ella?
3) ¿Hay funciones distribuidas de procesamiento?
4)¿El desempeño es crítico?
5)¿El sistema se ejecutará en un entorno existente que tiene un uso pesado
de operaciones?
6)¿El sistema requiere entrada de datos en línea?
7)¿La entrada de datos en línea requiere que la transacción de entrada se
construya en varias pantallas u operaciones?
8)¿Los ALI se actualizan en línea?
9)¿Las entradas, las salidas, los archivos o las consultas
son complejos?
10)¿Es complejo el procesamiento interno?
11)¿El código diseñado será reutilizable?
12)¿Se incluyen la conversión e instalación en el diseño?
13)¿Esta diseñado el sistema para instalaciones múltiples
en diferentes organizaciones?
14) ¿La aplicación está diseñada para facilitar el cambio y
para que el usuario use fácilmente?
 Ejemplo PF

NIVEL DE COMPLEJIDAD
TIPO DE FUNCION TOTAL
SIMPLE MEDIO COMPLEJO

Entradas de 3* 3 3*4 3* 6 9
Usuario
Salidas de Usuario 2* 4 2*5 2* 7 8

Archivos Internos 1*7 1*10 1* 15 7

Archivos Externos 4* 5 4* 7 4* 10 20

Consultas de 2* 3 2* 4 2* 6 6
Usuario
TOTAL PF SIN AJUSTAR PF = 50

PF= 50*(0,65+(0,01*46)) REGRESAR

PF=56
Modelo 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
◦ Apremios de funcionamiento Run-time
◦ Apremios de la memoria
◦ Volatilidad del ambiente virtual de la máquina
◦ Tiempo de turnabout requerido
 Cualidades del personal
◦ Capacidad del analista
◦ Capacidad de la tecnología de dotación lógica
◦ Experiencia de los usos
◦ Experiencia virtual de la máquina
◦ Experiencia del lenguaje de programación
 Cualidades del proyecto
◦ Uso de las herramientas del software
◦ Uso de los métodos de la tecnología de dotación lógica
 Horario requerido del desarrollo
 Cada uno de las 15 cualidades recibe un
grado en una escala del seis-punto que
se extienda de “muy bajo” a “superior”
(en importancia o valor). Un multiplicador
del esfuerzo de la tabla abajo se aplica
al grado. El producto de todos los
multiplicadores del esfuerzo da lugar
a coeficiente de adaptación del esfuerzo
(EAF). Los valores típicos para EAF se
extienden a partir de la 0.9 a 1.4.
Conductores del coste Grados
Muy Bajo Nominal Alto Muy arriba Superior
bajo
Cualidades de producto

Confiabilidad requerida 0.75 0.88 1.00 1.15 1.40

del software

Tamaño de la base de 0.94 1.00 1.08 1.16

datos del uso

Complejidad del 0.70 0.85 1.00 1.15 1.30 1.65

producto
Cualidades del hardware

Apremios de 1.00 1.11 1.30 1.66

funcionamiento Run-time

Apremios de la memoria 1.00 1.06 1.21 1.56

Volatilidad del ambiente 0.87 1.00 1.15 1.30

virtual de la máquina

Tiempo de turnabout 0.87 1.00 1.07 1.15

requerido
Cualidades del personal

Capacidad del analista 1.46 1.19 1.00 0.86 0.71

Experiencia de los usos 1.29 1.13 1.00 0.91 0.82

Capacidad de la Software 1.42 1.17 1.00 0.86 0.70

Engineer

Experiencia virtual de la 1.21 1.10 1.00 0.90

máquina

Experiencia del lenguaje 1.14 1.07 1.00 0.95

de programación

Cualidades del proyecto

Uso de las herramientas 1.24 1.10 1.00 0.91 0.82

del software

Uso de los métodos de la 1.24 1.10 1.00 0.91 0.83

tecnología de dotación
lógica

Horario requerido del 1.23 1.08 1.00 1.04 1.10

desarrollo
FORMULA DEL MODELO
COCOMO INTERMEDIO

 E=ai(KLoC)(bi).EAF
 Donde está el esfuerzo E aplicado en
persona-meses, KLoC es el número
estimado de millares de líneas entregadas de
código para el proyecto, yEAF es el factor
calculado arriba. El coeficiente ai y el
exponente bi se dan en la tabla siguiente.
Proyecto del software ai bi
Orgánico 3.2 1.05
Semi-separado 3.0 1.12
Encajado 2.8 1.20

 El tiempo de desarrollo D aplicaciones del

cálculo E de la misma forma que en el
COCOMO básico.
Modelo COCOMO Detallado
 COCOMO detallado - incorpora todas
las características de la versión
intermedia 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.
CONCLUSION DE FASES
 COCOMO BASICO: Calcula esfuerzo y
costo del desarrollo en función del
programa, expresados en LDC.
 COCOMO INTERMEDIO: Calcula
esfuerzo y costo en función de costo con
atributos del producto del HW, del
personal y del proyecto.
 COCOMO DETALLADO: Incorpora las
características del intermedio +
evaluación de las condiciones de costo
en cada fase del proyecto.
 INCONVENIENTES DEL
MODELO COCOMO
 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).
 A la vez, cada submodelo también se divide
en modos que representan el tipo de proyecto, y
puede ser:
 Modo Organico
 Modo Semilibre o Semiencajado
 Modo Rigido o Empotrado
 MODO ORGANICO
 un pequeño grupo de programadores
experimentados desarrollan software en
un entorno familiar. El tamaño del
software varía desde unos pocos miles
de líneas (tamaño pequeño) a unas
decenas de miles (medio).
 proyectos relativamente sencillos,
menores de 50 KDLC líneas de código,
en los cuales se tiene experiencia de
proyectos similares y se encuentran en
entornos estables.
 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.
 proyectos intermedios en complejidad
y tamaño (menores de 300 KDLC),
donde la experiencia en este tipo de
proyectos es variable, y las
restricciones intermedias.
MODO RIGIDO O EMPOTRADO

 el proyecto tiene fuertes restricciones,

que pueden estar relacionadas con la
funcionalidad y/o pueden ser técnicas. El
problema a resolver es único y es difícil
basarse en la experiencia, puesto que
puede no haberla.
 proyectos bastante complejos, en los
que apenas se tiene experiencia y se
engloban en un entorno de gran
innovación técnica. Además se trabaja
con unos requisitos muy restrictivos y de
gran volatilidad.