Cocomo ii guía

Gerencia de Proyectos Informáticos C.P.Ingeniería de Sistemas e Informática - UTEA 2011
1 Ing. Hesmeralda Rojas Enriquez
COCOMO II
Breve historia
El modelo COCOMO ha evolucionado debido a los constantes avances en
el mercado de desarrollo de software.
En el año 1981 Barry Boehm publica el modelo COCOMO, acorde a las prácticas de desarrollo de
software de aquel momento [Boehm 1981]. Durante la década de los 80, el modelo se continuó
perfeccionando y consolidando, siendo el modelo de estimación de costos más ampliamente
utilizado en el mundo.
En el año 1983 se introduce el lenguaje de programación Ada (American National Standard
Institute) para reducir los costos de desarrollo de grandes sistemas. Algunos aspectos de Ada
provocaron un gran impacto en los costos de desarrollo y mantenimiento, así Barry Boehm y
Walker Royce definieron un modelo revisado, llamado Ada COCOMO [Boehm 1989].
En los 90, las técnicas de desarrollo de software cambiaron dramáticamente, surgieron la necesidad
de reusar software existente, la construcción de sistemas usando
librerías, etc. Estos cambios comenzaron a generar problemas en la
aplicación del modelo COCOMO. La solución fue reinventar el
modelo. Después de algunos años y de un esfuerzo combinado de
USC-CSE (University of Southern California- Center For Software
Engineering), IRUS at UC Irvine y organizaciones privadas, aparece
COCOMO II. Las incorporaciones a este modelo lo reforzaron e
hicieron apto para ser aplicado en proyectos vinculados a
tecnologías como orientación a objetos, desarrollo incremental,
composición de aplicación, y reingeniería. COCOMO II consta de tres
modelos, cada uno de los cuales ofrece una precisión acorde a cada
etapa de desarrollo del proyecto. Enunciados en orden creciente de
fidelidad son, modelo de Composición de Aplicación, Diseño Temprano y Post Arquitectura.
El USC- CSE implementó los dos últimos modelos en una herramienta de software. Esta
herramienta le permite al planificador hacer rápidamente una exploración de las posibilidades de
un proyecto, analizando qué efectos provoca el ajuste de requerimientos, recursos y staff sobre la
estimación de costos y tiempos.
Para evitar confusión el modelo COCOMO original fue redesignado con el nombre COCOMO’ 81. Así
todas las referencias de COCOMO encontradas en la literatura antes de 1995 se refieren a lo que
ahora llamamos COCOMO’81. La mayoría de las referencias publicadas a partir de 1995 se refieren
a COCOMO II.

Cocomo II
Es un modelo de estimación de costes.
COnstrucive COst MOdel (MOdelo COnstructivo de Costo.
Creado por Barry W. Boehm.
Los objetivos principales que se tuvieron en cuenta para construir el modelo COCOMO II fueron:
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 un marco analítico cuantitativo y un conjunto de herramientas y técnicas que
evaluaran el impacto de las mejoras tecnológicas de software sobre los costos y tiempos en
las diferentes etapas del ciclo de vida de desarrollo.
COCOMO II está compuesto por tres modelos denominados: Composición de Aplicación, Diseño
Temprano y Post-Arquitectura.
Éstos surgen en respuesta a la diversidad del mercado actual y futuro de desarrollo de software.
Esta diversidad podría representarse con el siguiente esquema

Aplicaciones desarrolladas por Usuarios Finales:
•En este sector se encuentran las aplicaciones de procesamientode información generadas
directamentepor usuarios finales, mediante la utilizaciónde generadores de aplicaciones
tales como planillas de cálculo, sistemas de consultas,etc. Estas aplicacionessurgen
debido al uso masivo de estas herramientas,conjuntamentecon la presión actual para
obtener solucionesrápidas y flexibles.
Generadores de Aplicaciones:
•En este sector operan firmas como Lotus, Microsoft, Novell, Borland con el objetivo de
crear módulos pre-empaquetados que serán usados por usuarios finales y
programadores.
Aplicaciones con Componentes:
•Sector en el que se encuentran aquellas aplicaciones que son específicaspara ser
resueltaspor soluciones pre-empaquetadas,pero son lo suficientementesimples para ser
construidasa partir de componentesinteroperables.
•Componentestípicas son constructoresde interfases gráficas, administradoresde bases
de datos, buscadores inteligentesde datos, componentes de dominio-específico
(medicina,finanzas, procesos industriales,etc.). Estas aplicacionesson generadas por un
equipo reducido de personas, en pocas semanas o meses.
Sistemas Integrados: Sistemas de gran escala, con un alto grado de integración
entre sus componentes, sin antecedentes en el mercado que se puedan tomar
como base. Porciones de estos sistemas pueden ser desarrolladas a través de la
composiciónde aplicaciones. Entre las empresas que desarrollan software
representativode este sector, se encuentran grandes firmas que desarrollan
software de telecomunicaciones,sistemas de informacióncorporativos, sistemas
de control de fabricación, etc.
Infraestructura: Área que comprende el desarrollo de sistemas operativos,
protocolos de redes, sistemas administradores de bases de datos, etc.
Incrementalmenteeste sector direccionará sus soluciones, hacia problemas
genéricosde procesamiento distribuido y procesamiento de transacciones, a
soluciones middleware. Firmas representativas son Microsoft, Oracle, SyBase,
Novell y NeXT.

1. Modelo I:
Nivel inicial de prototipado - Modelo Composición de Aplicación.
El esfuerzo necesario para concretar un proyecto de desarrollo de software, cualquiera sea el
modelo empleado, se expresa en meses/persona (PM) y representa los meses de trabajo de
una persona fulltime, requeridos para desarrollar el proyecto.
Estimación del Esfuerzo
Estimaciones realizadas con puntos de objeto y una fórmula simple para el cálculo del esfuerzo
Soporta proyectos con prototipado y proyectos que hacen uso intensivo de la
reutilización.
Basado en estimaciones estándar de la productividad del desarrollador en puntos-
objeto/mes.
Tiene en cuenta el uso de herramientas CASE
La fórmula es:
.
Cálculo de Esfuerzo
PM = ( NOP * (1 - %reuse/100 ) ) / PROD
Donde:
NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado
en Puntos Objeto y se calcula de la siguiente manera:
%reuso: Porcentaje de reuso que se espera lograr en el proyecto
PROD: Es la productividad promedio determinada a partir del análisis de datos de
proyectos en [Banker 1994], mostrada en
2. Modelo II:
Modelo para Diseño Temprano (EDM)
Este modelo se usa en las etapas tempranas de un proyecto de software, cuando se conoce
muy poco del tamaño del producto a ser desarrollado, de la naturaleza de la plataforma, del
personal a ser incorporado al proyecto o detalles específicos del proceso a utilizar. Este modelo
podría emplearse tanto en productos desarrollados en sectores de Generadores de Aplicación,
Sistemas Integrados o Infraestructura.
El modelo de Diseño Temprano ajusta el esfuerzo nominal usando siete factores de costo. La
fórmula para el cálculo del esfuerzo es la siguiente:

Donde
PMEstimado: es el esfuerzo nominal ajustado por 7 factores, que reflejan otros aspectos
propios del proyecto que afectan al esfuerzo necesario para la ejecución del mismo.
KSLOC: es el tamaño del software a desarrollar expresado en miles de líneas de código
fuente.
A es una constante que captura los efectos lineales sobre el esfuerzo de acuerdo a la
variación del tamaño, (A=2.94).
B es el factor exponencial de escala, toma en cuenta las características relacionadas con las
economías y deseconomías de escala producidas cuando un proyecto de software
incrementa su tamaño.
EMi corresponde a los factores de costo que tienen un efecto multiplicativo sobre el
esfuerzo, llamados Multiplicadores de Esfuerzo (Effort Multipliers). Cada factor se puede
clasificar en seis niveles diferentes que expresan el impacto del multiplicador sobre el
esfuerzo de desarrollo. Esta escala varía desde un nivel Extra Bajo hasta un nivel Extra Alto.
Cada nivel tiene un peso asociado. El peso promedio o nominal es 1.0.
Si el factor provoca un efecto nocivo en el esfuerzo de un proyecto, el valor del
multiplicador correspondiente será mayor que 1.0, caso contrario el multiplicador será
inferior a 1.0.
Los multiplicadores reflejan la capacidad de los desarrolladores, requerimientos no funcionales,
la familiaridad con la plataforma de desarrollo, etc.
1. Abrev. Descripción Ponderación
2. RCPX Fiabilidad de producto y complejidad 0 a 1
3. RUSE Reutilización requerida 0 a 1
4. PDIF Dificultad de la plataforma 0 a 1
5. PREX Experiencia del personal 0 a 1
6. PERS Capacidad del personal 0 a 1
7. SCED Agenda requerida 0 a 1
8. FCIL Facilidades de soporte de grupo 0 a 1
PM refleja la cantidad de código generada automáticamente

3. Modelo III:
Nivel post-arquitectura.
Es el modelo de estimación más detallado y se aplica cuando la arquitectura del proyecto está
completamente definida. Este modelo se aplica durante el desarrollo y mantenimiento de
productos de software incluidos en las áreas de Sistemas Integrados, Infraestructura y
Generadores de Aplicaciones.
El esfuerzo nominal se ajusta usando 17 factores multiplicadores de esfuerzo. El mayor número
de multiplicadores permite analizar con más exactitud el conocimiento disponible en las
últimas etapas de desarrollo, ajustando el modelo de tal forma que refleje fielmente el
producto de software bajo desarrollo. La fórmula para el cálculo del esfuerzo es la siguiente:
Estimación de Esfuerzo
Personas Mes Nominales.
PM= A * TamañoB
* EMi (A= 2.94)
B < 1. Los esfuerzos de desarrollo mejoran cuando escalan. Si se dobla el tamaño, el
esfuerzo es menor del doble.
B = 1. Los proyectos están balanceados. Los aumentos son proporcionales.
B > 1. Los esfuerzos de desarrollo empeoran cuando escalan. Si se dobla el tamaño, el
esfuerzo es menor del doble.
Factor de Escala
B = 0,91 + 0,01 ×  Wi
Cálculo de Esfuerzo
PM = PMnominal *  EMi

EM : Effort Multipliers W : Factores de Escala (Fi)
Nº Factores de escala Fi Abreviatura
1. Precedentes PREC
2. Flexibilidad de desarrollo FLEX
3. Resolución de arquitectura riesgo RESL
4. Cohesión del equipo de trabajo TEAM
5. Madurez del Proceso PMAT
Tabla de Puntuación:
Modelos de Madurez del software
Nivel Definición Características
Optimizado
0.00
La organización completa está volcada en la mejora
continua de los procesos. Se hace uso intensivo de las
métricas y se gestiona el proceso de innovación.
Mejoramiento
realimentando al proceso
– Productividad y calidad
Gestionado
cuantitativamente
1.56
Se caracteriza porque las organizaciones disponen de
un conjunto de métricas significativas de calidad y
productividad, que se usan de modo sistemático para la
toma de decisiones y la gestión de riesgos. El software
resultante es de alta calidad.
Proceso medido
Definido
3.12
Además de una buena gestión de proyectos, a este
nivel las organizaciones disponen de correctos
procedimientos de coordinación entre grupos,
formación del personal, técnicas de ingeniería más
detalladas y un nivel más avanzado de métricas en los
Proceso definido e
institucionalizado

procesos. Se implementan técnicas de revisión por
pares.
Repetible
4.68
En este nivel las organizaciones disponen de unas
prácticas institucionalizadas de gestión de proyectos,
existen unas métricas básicas y un razonable
seguimiento de la calidad. La relación con
subcontratistas y clientes está gestionada
sistemáticamente.
Proceso dependiente de
individuo
Inicial
Superior 6.24
Inferior 7.80
Las organizaciones en este nivel no disponen de un
ambiente estable para el desarrollo y mantenimiento
de software. Aunque se utilicen técnicas correctas de
ingeniería, los esfuerzos se ven minados por falta de
planificación. El éxito de los proyectos se basa la
mayoría de las veces en el esfuerzo personal, aunque a
menudo se producen fracasos y casi siempre retrasos y
sobrecostes. El resultado de los proyectos es
impredecible.
Caótico - Riesgo

Multiplicadores de esfuerzo (EM)
Son 17:
 Relacionados con el producto:
1. (RELY). Fiabilidad Requerida de Software
Esta es la medida de hasta qué punto el software debe realizar su función esperada
durante un periodo de tiempo.
2. (DATA). Medida del Volumen de Datos
Esta medida intenta capturar lo que afecta en el desarrollo del producto los
requerimientos de datos grandes. La medida se determina calculando D/P.
DATA se valora como Bajo si D/P es menor que 10 y Muy Alto si es mayor que 1000.
3. (CPLX). Complejidad del Producto
Las Medidas de complejidad del módulo versus Tipo de módulo proporciona la escala de
valores CPLX de Cocomo II. La complejidad se decide en 5 áreas: Funcionamiento de
control, Funcionamiento computacional, Funcionamiento de Dispositivos dependientes,
Funcionamiento del sector de datos y Funcionamiento del Gestor de Interfaz de Usuario.
Se seleccionará el área o combinación de áreas que caracterizan al producto o a un
subsistema del producto. La medida de complejidad es la media subjetiva de estas áreas.
3.1.Funcionamiento de control
Muy Bajo: código con unos pocos operadores de programación no anidados.
Bajo: anidamiento sencillo de operadores de programación estructurados.
Nominal: Mayoría de anidamiento simple.
Alto: Operadores de programación estructurados altamente anidados
compuestos de muchos predicados.
Muy Alto: Codificación recursiva. Manejo de interrupciones con prioridades
fijadas. Sincronización de tareas, retorno de llamadas complejas, proceso
distribuido, etc.
Extra Alto: Múltiples recursos de planificación con cambio dinámico de
prioridades. Control a nivel de microcódigo. Control distribuido en tiempo real.
3.2.Funcionamiento computacional
Muy Bajo: Evaluación de expresiones simples, por ejemplo
Bajo: Evaluación de expresiones de nivel moderado: p.ej
Nominal: Uso de rutinas matemáticas y estadísticas estándar.
Alto: Análisis numérico básico: ecuaciones diferenciales ordinarias.
Muy Alto: Análisis numérico difícil pero estructurado: ecuaciones de matrices,
ecuaciones diferenciales parciales.
Extra Alto: Análisis numérico difícil y sin estructurar.

3.3.Funcionamiento dispositivos dependientes
Muy Bajo: Declaraciones simples de lectura-escritura con formatos simples.
Bajo: No necesidad de conocimiento de características del procesador
particular o del dispositivo de I/O.
Nominal: El proceso de I/O incluye selección de dispositivo, estado de
validación y proceso de errores.
Alto: Operación de I/O a nivel físico (traducción de direcciones físicas de
almacenamiento: búsquedas, lecturas, etc.).
Muy Alto: Rutinas para diagnóstico de interrupciones, servicio de
enmascaramiento. Manejo de línea de comunicación.
Extra Alto: Dispositivo dependiente temporalmente de la codificación.
Operaciones microprogramazas.
3.4.Funcionamiento del sector de datos
Muy Bajo: Arrays simples en memoria principal. Actualizaciones, Queries
simples
Bajo: Archivos únicos sin cambio en la estructura de datos, sin ediciones, sin
archivos intermedios. Actualizaciones, Queries moderadamente complejos
Nominal: Entradas de múltiples archivos y salida de un único archivo. Cambios
estructurales simples, ediciones simples. Actualizaciones, Queries complejos.
Alto: Encadenamientos simples activados por contenidos de hileras de datos.
Muy Alto: Coordinación de bases de datos distribuidas. Encadenamientos
complejos. Optimización de la búsqueda
Extra Alto: Acoplamiento fuerte, estructuras de objetos y relacionales
dinámicas.
3.5.Funcionamiento de gestor de Interfaces de usuario
Muy Bajo: Forma de entrada simple, generadores de informes
Bajo: Uso de constructores simples de interfaces gráficos de usuario
Nominal: Uso simple de conjunto Widget
Alto: Extensión y desarrollo de conjunto Widget. Voz simple de I/O multimedia
Muy Alto: Multimedia complejo 2D/3D, gráficos dinámicos multimedia
Extra Alto: Multimedia complejo, realidad virtual.
4. (RUSE). Reutilización Requerida
Explica el esfuerzo adicional necesario para construir componentes pensados para se
reutilizados en otros proyectos.
5. (DOCU). Documentación Asociada a las Necesidades del Ciclo de Vida

 Relacionados con la plataforma de desarrollo:
6. (TIME). Restricción del Tiempo de Ejecución
Esta es una medida de la restricción del tiempo de ejecución
7. (STOR). Restricción de Almacenamiento Principal
Esta medida representa el grado de restricción de almacenamiento principal.
8. (PVOL). Volatilidad de la Plataforma
Plataforma: significa la complejidad del Hardware y Software (OS, DBMS, etc.) que el producto
software necesita para realizar sus tareas.
 Relacionados con personal
9. (ACAP). Habilidad del Analista
Lo que se debe considerar en esta medida son la habilidad de análisis y diseño, la eficiencia y la
habilidad para comunicar y cooperar que posee el Analista, no se debe considerar aquí el nivel de
experiencia ya que se mide con AEXP.
10.(PCAP). Habilidad del Programador
Lo que se debe considerar en esta medida son la habilidad de análisis y diseño, la eficiencia y la
habilidad para comunicar y cooperar que posee el Programador, no se debe considerar aquí el
nivel de experiencia ya que se mide con AEXP.
11.(AEXP). Experiencia en las Aplicaciones
Esto mide el nivel de experiencia en aplicaciones del equipo de proyecto en el desarrollo de
sistemas.
12.(PEXP). Experiencia en la Plataforma
Aquí se reconoce la importancia de entender el uso de plataformas más poderosas, incluyendo
más interfaces gráficas.
13.(LTEX). Experiencia en la Herramienta y en el Lenguaje
Esta es una medida del nivel de experiencia en el lenguaje de programación.

14.(PCON). Continuidad del Personal
La escala de valores mide el movimiento de personal del proyecto anualmente.
 Relacionados con el proyecto
15.(TOOL) Uso de Herramientas Software
Los valores para la herramienta van desde edición y código simple, Muy Bajo, hasta herramientas
integradas de gestión del ciclo de vida, Muy Alto.
16.(SITE). Desarrollo Multilugar
Determinar la medida del driver de costo incluye el cálculo y la medida de 2 factores: Localización
del lugar (desde totalmente localizado hasta distribución internacional) y soporte de
comunicación (desde correo de superficie y algún acceso telefónico hasta multimedia totalmente
interactivo).
17.(SCED). Calendario de Desarrollo Requerido
Este valor mide las restricciones de horario impuestas al equipo de proyecto que desarrolla el
software. Los valores se definen en términos de porcentaje de aceleración o alargamiento sobre
el calendario respecto de un calendario nominal para un proyecto que requiere una cantidad de
esfuerzo dada.

Tabla que refleja los coeficientes necesarios para el cálculo:
Abreviatura Muy bajo Bajo Nominal Alto Muy alto Extra alto
RELY 0.75 0.88 1.00 1.15 1.39 1.00
DATA 1.00 0.93 1.00 1.09 1.19 1.00
CPLX 0.75 0.88 1.00 1.15 1.30 1.66
RUSE 1.00 0.91 1.00 1.14 1.29 1.49
DOCU 0.89 0.95 1.00 1.06 1.13 1.00
TIME 1.00 1.00 1.00 1.11 1.31 1.67
STOR 1.00 1.00 1.00 1.06 1.21 1..57
PVOL 1.00 0.87 1.00 1.15 1.30 1.00
ACAP 1.50 1.22 1.00 0.83 0.67 1.00
PCAP 1.37 1.16 1.00 0.87 0.74 1.00
PCON 1.24 1.10 1.00 0.92 0.84 1.00
AEXP 1.22 1.10 1.00 0.89 0.81 1.00
PEXP 1.25 1.12 1.00 0.88 0.81 1.00
LTEX 1.22 1.10 1.00 0.91 0.84 1.00
TOOL 1.24 1.12 1.00 0.86 0.72 1.00
SITE 1.25 1.10 1.00 0.92 0.84 1.00
SCED 1.29 1.10 1.00 1.00 1.00 1.00
Determinación del Tiempo de Desarrollo y Cantidad de Personal
Determinación del Tiempo de Desarrollo
Tdes= 3.67 * (E)0.28 + 0.002 * ∑SFi
Cantidad de Personal
CH= E/Tdes

EJERCICIOS
Para un software se ha hallado que el total de Puntos de Función Ajustados fue de 349.6
TLDC = Nº medio de LDC de “x” lenguaje de programación x PFA/1000
TLDC= 53 x 349.6 / 1000
TLDC= 18.52
Determinación de los factores de escala
E= A * (Tamaño)B X
EMi
E= Esfuerzo nominal
Tamaño= Puntos de Función Ajustados

Cocomo ii guía

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Cocomo ii guía

Similar a Cocomo ii guía (20)

Último

Último (20)

Cocomo ii guía