El Modelo COCOMO
Introducción
El Modelo Constructivo de
Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de
los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro
"Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una
jerarquía de modelos de estimación de costes software que incluye submodelos
básico, intermedio y detallado.
Las ecuaciones de estimación
del esfuerzo de desarrollo tienen la forma:
con
• S el número de miles de líneas de
código fuente
• m(X) es un multiplicador que
depende de 15 atributos
• en la siguiente tabla se muestran
los coeficientes para los diferentes modos
1. MODELO BÁSICO
Este
modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría
de proyectos pequeños y medianos. Se consideran tres modos de desarrollo en
este modelo: orgánico, semiencajado y empotrado.
1.1. Modo orgánico.
En este modo, un pequeño grupo de
programadores experimentados desarrollan software en un entorno familiar. El
tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas
decenas de miles de líneas (medio), mientras que en los otros dos modos el
tamaño varía de pequeño a muy grandes (varios cientos de miles de líneas). En
este modo, al igual que en los otros, el coste se incrementa a medida que el
tamaño lo hace, y el tiempo de desarrollo se alarga.
Se utilizan dos ecuaciones
para determinar el esfuerzo de personal y el tiempo de desarrollo. El coste es
Km = 2.4 Sk1.05
Donde Km se expresa en
personas-mes y Sk es el tamaño expresado en miles de líneas de código fuente.
El tiempo de desarrollo se da por
td = 2.5 Km0.38
Donde Km se obtiene de la
ecuación anterior y td es el tiempo de desarrollo en meses. Estas ecuaciones se
han obtenido por medio de ajustes de curvas realizado por Boehm en TRW sobre 63
proyectos.
1.2. Modo Empotrado.
En este modo, el proyecto tiene
unas fuertes restricciones, que pueden estar relacionadas con el procesador y
el interface hardware. El problema a resolver es único y es difícil basarse en
la experiencia, puesto que puede no haberla.
Las estimaciones de tiempo y
coste se basan en las mismas ecuaciones que en el modo orgánico, pero con
diferentes constantes. Así, el coste se da por
Km = 3.6 Sk1.20
Y el tiempo de desarrollo por
td = 2.5 Km0.32
1.3. Modo Semiencajado.
Es un modo intermedio entre los dos
anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de
personas experimentadas y no experimentadas.
Las ecuaciones son
Km = 3.0 Sk1.12
Y el tiempo de desarrollo por
td = 2.5 Km0.35.
1.4. Notas al Modelo Básico
Se puede observar que a medida que
aumenta la complejidad del proyecto, 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 básico puesto que se obvian muchas características del
entorno.
2. MODELO 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.
La fórmula intermedio de
Cocomo ahora toma la forma:
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, y EAF 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.
3. MODELO
DETALLADO
Este modelo puede procesar todas
las características del proyecto para construir una estimación. Introduce dos
características principales
(1) Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases
se ven más afectadas que otras por los atributos. El modelo detallado
proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto
ayuda a determinar la asignación del personal para cada fase del proyecto.
(2) Jerarquía del producto a tres niveles. Se definen tres niveles
de producto. Estos son módulo, subsistema y sistema. La cuantificación se
realiza al nivel apropiado, esto es, al nivel al que es más susceptible la
variación.
3.1. ESTIMACIÓN DEL ESFUERZO.
Ø Fases de desarrollo
El desarrollo del software se lleva a cabo a
través de cuatro fases consecutivas: requerimientos/planes, diseño del
producto, programación y prueba/integración.
Requerimientos/planes. Esta es la
primera fase del ciclo de desarrollo. Se analiza el requerimiento, se muestra
un Plan de Producto y se general una especificación completa del producto. Esta
fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al 40% del
tiempo nominal de desarrollo td. Estos porcentajes dependen del modo y del
tamaño (de 2000 LOC a 512000 LOC).
Diseño del producto. La segunda
fase del ciclo de desarrollo COCOMO se preocupa de la determinación de la
arquitectura del producto y de las especificaciones de los subsistemas. Esta
fase requiere del 16% al 18% del esfuerzo nominal Kn, y puede durar del 19% al
38% del tiempo nominal de desarrollo td.
Programación. La tercera fase del
ciclo de desarrollo COCOMO se subdivide en dos subfases: diseño detallado y
prueba del código. Esta fase requiere del 48% al 68% del esfuerzo nominal Kn, y
dura del 24% Al 64% del tiempo nominal de desarrollo.
Prueba/Integración. Esta última
fase consiste principalmente en unir las diferentes unidades ya probadas. Se
utiliza del 16% al 34% del coste nominal Kn y dura del 18% al 34% del td.
Ø Principio de estimación del esfuerzo.
1. Tamaño equivalente. Como parte del software puede haber sido ya
desarrollado, no se requiere entonces un desarrollo completo. En tales casos se
estiman las partes de diseño (D%), código (C%) e integración (I%) a ser
modificadas. Se calcula un factor de ajuste A
A = 0.4 D + 0.3 C + 0.3 I
El tamaño equivalente, Sequ es
Sequ = (S · A) / 100.
2. Cálculo del esfuerzo. El tamaño equivalente se calcula para cada
módulo. El esfuerzo asignado al desarrollo de cada módulo se obtiene entonces a
través de:
(1) seleccionar los valores apropiados
de los atributos de coste para cada fase
(2) multiplicar los atributos de coste
para cada módulo y fase, obteniendo un conjunto de 4 multiplicadores globales
(3)
multiplicar los atributos globales por el esfuerzo nominal en cada fase y
sumarlos para obtener el esfuerzo total estimado.
Ejemplo Practico:
RESUMEN
El Modelo COCOMO
El Modelo Constructivo de
Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de
los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro
"Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una
jerarquía de modelos de estimación de costes software que incluye submodelos
básico, intermedio y detallado.
2. MODELO BÁSICO
Este modelo trata de estimar, de
una manera rápida y más o menos burda, la mayoría de proyectos pequeños y
medianos. Se consideran tres modos de desarrollo en este modelo: orgánico,
semiencajado y empotrado.
2.1. Modo orgánico.
En este modo, un pequeño grupo de
programadores experimentados desarrollan software en un entorno familiar.
2.2. Modo Empotrado.
En este modo, el proyecto tiene
unas fuertes restricciones, que pueden estar relacionadas con el procesador y
el interface hardware. El problema a resolver es único y es difícil basarse en
la experiencia, puesto que puede no haberla.
2.3. Modo Semiencajado.
Es un modo intermedio entre los dos
anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de
personas experimentadas y no experimentadas.
3. MODELO 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”.
4. MODELO DETALLADO
Este modelo puede procesar
todas las características del proyecto para construir una estimación. Introduce
dos características principales
Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se
ven más afectadas que otras por los atributos. El modelo detallado proporciona
un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a
determinar la asignación del personal para cada fase del proyecto.
Jerarquía del producto a tres niveles. Se definen tres niveles de
producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza
al nivel apropiado, esto es, al nivel al que es más susceptible la variación.
SUMARY
THE COCOMO MODEL
Constructive Cost Model
(Constructive Cost Model) was developed by B. W. Boehm in the late 70s and
early 80s, exposing in detail in his book "Software Engineering
Economics" (Prentice-Hall, 1981). COCOMO is a hierarchy of models of software
cost estimation including detailed submodels basic, intermediate and.
2. BASIC MODEL
This
model tries to estimate quickly and more or less crudely, most small and medium
projects. organic, semiencajado and built: three modes of development in this
model are considered.
twenty-one. organically.
In
this mode, a small group of experienced programmers develop software in a
familiar environment.
2.2. Flush mode.
In
this way, the project has strong restrictions, which may be related to the
processor and the hardware interface. The problem to solve is unique and is
difficult to rely on experience, since it can not be.
2. 3. Semiencajado mode.
It
is an intermediate mode between the two. Depending on the problem, the group
may include a mixture of experienced and not experienced.
3. INTERMEDIATE MODEL
Intermediate COCOMO software
development effort calculations as a function of program size and a system of
"cost drivers" that include subjective assessment of the product,
hardware, personnel and project qualities. This extension considers a set of four
"drivers side".
4. DETAILED MODEL
This model can process all the
features of the project to build an estimate. Introduces two main features
Multipliers sensitive to phase effort. Some stages are more
affected than others by the attributes. The detailed model provides a set of
multipliers effort for each attribute. This helps determine the allocation of
personnel for each project phase.
Product hierarchy at three levels. three levels of product are
defined. These are module, subsystem and system. The quantization is performed
at the appropriate level, ie the level at which the variation is more
susceptible.
RECOMENDACIONES
1. Las medidas de protección
ambiental deben orientar la actividad humana, con el propósito de hacer
compatibles las estrategias de desarrollo económico y social, con las de
preservación ambiental.
2. El Plan General de
Ordenamiento de la Cuenca de El Cajón, debe estar inserto en una estructura
legal e institucional de carácter nacional, y constituir una marco de
referencia para una segunda fase del proyecto de Manejo de los Recursos
Naturales de la Cuenca de El Cajón, y a otros proyectos de manejo de cuencas en
Honduras.
4. Debido a la escasez de
recursos y los numerosos problemas ambientales, es necesario hacer una
priorización de los esfuerzos de solución hacia los problemas de deterioro
ambiental de mayor gravedad, como lo hecho en la Cuenca.
5. Debe haber una
incorporación gradual y sostenida de la población y los gobiernos locales en
las acciones de ordenamiento y manejo de los recursos naturales, como también
en otras actividades tendientes a la preservación de los recursos.
CONCLUSIONES
Los modelos, a pesar de su
perfeccionamiento sobre diferentes entradas para la estimación de esfuerzo, no
modelan de manera adecuada los factores que afectan la productividad. Es
necesario hacer mas investigaciones acerca de cómo medir todos los factores que
afectan los sistemas de productividad profesional, si la profesión es
encontrarse con los cambios del futuro.
APRECIACIÓN DEL EQUIPO
Es uno de los modelos más documentados en la actualidad y es muy fácil de utilizar. Es correcto con referencia a los 63 proyectos utilizados, aunque de ello no se debe desprender que deba ser válido siempre. Una preocupación es la adaptación de las ecuaciones exponenciales a organizaciones específicas, cosa que no parece inmediatamente fácil.
GLOSARIO DE TÉRMINOS
Es la amplitud de aplicación potencial de los
componentes del programa
Es la propiedad que permite que una subclase herede
los atributos y los mensajes de una superclase. Es el mecanismo por el cual
elementos más específicos incorporan la estructura y el comportamiento de
elementos más generales
Interacción
Es una especificación de comportamiento cuyo fin es
lograr un propósito específico. Abarca un conjunto de intercambios de mensajes
entre un conjunto de objetos dentro de un contexto particular. Una interacción
puede ilustrarse mediante uno o más escenarios.
Completitud
Es el grado en que se ha conseguido la total
implementación de las funciones requeridas.
Es la parte del proceso de desarrollo de software cuyo
propósito principal es decidir cómo se construirá el sistema. Durante el diseño
se toman decisiones estratégicas y tácticas para alcanzar los requerimientos
funcionales y la calidad esperada.
Evento
En el contexto de un diagrama de estado, un evento es
un acontecimiento que puede disparar una transición de estados.
LINKOGRAFÍA
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm
http://ingenieraupoliana.blogspot.pe/2010/10/cocomo.html
https://sites.google.com/site/stigestionydesarrollo/recuperacion/recuperacion-gestion/tema-9/10---explicar-modelo-cocomo
Link de la Diapositiva
Video de Referencia
