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
http://www.slideshare.net/mireya2022/modelo-cocomo-59266650
Video de Referencia
Link de la Diapositiva
http://www.slideshare.net/mireya2022/modelo-cocomo-59266650
Video de Referencia
No hay comentarios:
Publicar un comentario