TODO LO RELACIONADO CON EL MODELO COCOMO

1. MODELO COCOMO
Modelo Constructivo de Costos
(COnstructive COst Model)

2. Ingeniería de Software
 Andrea Vecino
 Yadith Miranda
 Verónica Obregón
 Andrés Barrios
 David Pava
Tecnología en Sistemas
(VI Semestre)

3.  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
¿Qué es el Modelo COCOMO?

5.  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.

6. 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.
Estimación LDC y PF

7. 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
Técnicas de Estimación

8. 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.
EJEMPLO
PF= ConteoTotal * [0,65 + 0,01 *
∑ (Fi )]
Modelos de Punto de Función

9. Trabaja en Función de 3
Submodelos:
 Modelo Básico
 Modelo Intermedio
 Modelo Detallado

10. 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.

11. E= esfuerzo (hombre/mes)
KLOC= número (miles)
estimado de líneas de código
del proyecto.
E= a (KLOC)b
D= c (E) d
Tiempo de desarrollo:
El modelo COCOMO básico

12. 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

13. Coeficientes a usar:
PROYECTO
SOFTWARE
a b c d Descripción
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.

14. 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?.
Ejemplo:

15. E = 2.4 (32)1.05 E = 91 hombres-mes
D = 2.5 (91)0.38D= c (E)
b
d
•Esfuerzo:
•Tiempo de desarrollo:
= 14 meses
N = 91/14
•Número de personas trabajando en el proyecto:
= 6.5 hombres

16. 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)
Ejemplo: LDC

17. SOLUCION
Función Optimista Más
probable
Pesimista Esperado
Control de interfaz de
usuario
1800 2400 2650 2340
Análisis geométrico en
2-D
4100 5200 7400 5380
Análisis geométrico en
3-D
4600 6900 8600 6800
Gestión de la estructura
de datos
2950 3400 3600 3350
Visualización de
gráficos en la
computadora
4050 4900 6200 4950
Control periféricos 2000 2100 2450 2140
Análisis de diseño 6600 8500 9800 8400
33360
LDC estimadasREGRESAR

18. Contraseña
Consulta de zona
Consulta de sensor
Botón de pánico
Activar/Desactivar
Usuario
Sensores
Usuario
Subsistema
De Monitoreo
Y Respuesta
Datos De Configuracion Del Sistema
Función E
Interacción De
Usuario En
Hogar Seguro

19. 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?

20. 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?

21. TIPO DE FUNCION
NIVEL DE COMPLEJIDAD
TOTAL
SIMPLE MEDIO COMPLEJO
Entradas de
Usuario
3* 3 3*4 3* 6 9
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
Usuario
2* 3 2* 4 2* 6 6
TOTAL PF SIN AJUSTAR PF = 50
REGRESARPF= 50*(0,65+(0,01*46))
PF=56
Ejemplo PF

22. 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.

23. 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

24.  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.

25. Conductores del coste Grados
Muy
bajo
Bajo Nominal Alto Muy arriba Superior
Cualidades de producto
Confiabilidad requerida
del software
0.75 0.88 1.00 1.15 1.40
Tamaño de la base de
datos del uso
0.94 1.00 1.08 1.16
Complejidad del
producto
0.70 0.85 1.00 1.15 1.30 1.65
Cualidades del hardware
Apremios de
funcionamiento Run-time
1.00 1.11 1.30 1.66
Apremios de la memoria 1.00 1.06 1.21 1.56
Volatilidad del ambiente
virtual de la máquina
0.87 1.00 1.15 1.30
Tiempo de turnabout
requerido
0.87 1.00 1.07 1.15

26. 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
Engineer
1.42 1.17 1.00 0.86 0.70
Experiencia virtual de la
máquina
1.21 1.10 1.00 0.90
Experiencia del lenguaje
de programación
1.14 1.07 1.00 0.95
Cualidades del proyecto
Uso de las herramientas
del software
1.24 1.10 1.00 0.91 0.82
Uso de los métodos de la
tecnología de dotación
lógica
1.24 1.10 1.00 0.91 0.83
Horario requerido del
desarrollo
1.23 1.08 1.00 1.04 1.10

27. FORMULA DEL MODELO
COCOMO INTERMEDIO
 E=ai(KLoC)(b
i
).EAF

28.  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.
 El tiempo de desarrollo D aplicaciones del
cálculo E de la misma forma que en el
COCOMO básico.
Proyecto del software ai bi
Orgánico 3.2 1.05
Semi-separado 3.0 1.12
Encajado 2.8 1.20

29. 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.

30. 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.

31. 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).

32. 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

33. 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.

34. 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.

35. 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.