cocomo

1. INSTITUTO SUPERIOR JUAN MEJIA BACA
NOMBRES:NOMBRES:
TEMA:
CURSO:
PROFESOR:
AÑO:
Año de la Consolidación del Mar de Grau
Densy de la cruz lucero
Yuliana arrieta flores
Cocomo
Marco Aurelio Porro Chulli

2. COCOMO
COnstructive COst MESel del (COCOMO) es un algorítmico Modelo de la
valoración del coste del software convertido cerca Barry Boehm. El modelo utiliza
una básica regresión fórmula, con los parámetros que se derivan de datos
históricos del proyecto y de características actuales del proyecto.
COCOMO primero fue publicado en 1981 Barry J. Boehm Libro Economía de la
tecnología de dotación lógica como modelo para estimar esfuerzo, coste, y el horario
para los proyectos del software. Dibujó en un estudio de 63 proyectos
en TRW Espacio aéreo donde Barry Boehm era el director de la investigación y de
la tecnología del software en 1981. El estudio examinó los proyectos que se
extendían de tamaño a partir de 2000 a 100.000 líneas del código, y lenguajes de
programación que se extienden de asamblea a PL/I. Estos proyectos fueron
basados en modelo de la cascada del desarrollo del software que era el proceso
frecuente del desarrollo del software en 1981.
Referencias a esta del modelo llamada típicamente él COCOMO 81. En
1997COCOMO II fue convertido y finalmente publicado en 2001 en el
libroValoración del coste del software con COCOMO II. COCOMO II es el sucesor
de COCOMO 81 y se satisface mejor para estimar proyectos modernos del
desarrollo del software. Proporciona más ayuda para moderno procesos del
desarrollo del software y una base de datos actualizada del proyecto. La necesidad
del nuevo modelo vino mientras que la tecnología del desarrollo del software se
movió desde el chasis y el procesamiento por lotes de noche al desarrollo de
escritorio, a la reutilidad del código y al uso de los componentes de software
disponibles. Este artículo se refiere COCOMO 81.
COCOMO consiste en una jerarquía de tres cada vez más detallados y de formas
exactas. El primer nivel, COCOMO básico es buena para aprisa, la orden temprana,
áspera de las estimaciones de la magnitud de los costes del software, pero su
exactitud debe limitado a su carencia de factores explicar diferencia en cualidades
del proyecto (Conductores del coste). COCOMO intermedio toma estos conductores
del coste en consideración y COCOMO detallado explica además la influencia de
las fases del proyecto individual.

3. COCOMO BASICO
COCOMO básico son los parásitos atmosféricos, el modelo solo-valorado que
computa esfuerzo del desarrollo del software (y coste) en función del tamaño del
programa expresado en líneas estimadas del código. COCOMO se aplica a tres
clases de los proyectos del software:
• Los proyectos orgánicos - son los proyectos relativamente pequeños, simples del
software en los cuales los equipos pequeños con el buen trabajo de la experiencia
del uso a un sistema de requisitos menos que rígidos.
• los proyectos - (de tamaño y complejidad) Semi-se separan los proyectos
intermedios del software en los cuales los equipos con los niveles mezclados de la
experiencia deben resolver una mezcla de requisitos rígidos y menos que rígidos.
• Los proyectos - se encajan los proyectos del software que se deben desarrollar
dentro de un sistema de hardware apretado, de software, y de apremios
operacionales.
Las ecuaciones básicas de COCOMO toman la forma
E=ab(KLOC)b
b
D=cb(e)d
b
P=E/D
Donde está el esfuerzo E aplicado en persona-meses, D es el tiempo de desarrollo
en meses cronológicos, KLOC es el número estimado de líneas entregadas del
código para el proyecto (expresado en millares), y P es el número de la gente
requerida. Los coeficientes ab, bb, cb y db se dan en la tabla siguiente.
Proyecto del
software
ab bb cb db
Orgánico 2.4 1.05 2.5 0.38
Semi-
separado
3.0 1.12 2.5 0.35
Encajado 3.6 1.20 2.5 0.32
COCOMO básico es bueno para aprisa, temprano, la orden áspera de las
estimaciones de la magnitud del software cuesta, pero no explica diferencias en
apremios del hardware, calidad y experiencia del personal, uso de herramientas

4. 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
Bajo Nominal Alto Muy
arriba
Superior

5. 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
La fórmula intermedio de Cocomo ahora toma la forma:
E=ai(KLoC)(b
i
).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 EAFes 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.

6. COCOMO DETALLADO
COCOMO detallado - incorpora todas las características de la versión intermedia
conungravamendelimpactodelconductordelcosteencadapaso(análisis,diseño,
etc.) del proceso de la tecnología de dotación lógica.

7. Ejemplo Estimación con el método de
Cocomo
Entre los distintos métodos de estimación de costes de desarrollo de software, el modelo
COCOMO (COnstructive COst MOdel) desarrollado por Barry M. Boehm, se engloba en el grupo
de los modelos algorítmicos que tratan de establecer una relación matemática la cual permite
estimar el esfuerzo y tiempo requerido para desarrollar un producto.
Por un lado COCOMO define tres modos de desarrollo o tipos de proyectos:
Orgánico: 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.
Semi-acoplado: 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.
Empotrado: 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.
Y por otro lado existen diferentes modelos que define COCOMO:
Modelo básico: Se basa exclusivamente en el tamaño expresado en LDC.
Modelo intermedio: Además del tamaño del programa incluye un conjunto de medidas
subjetivas llamadas conductores de costes.
Modelo avanzado: Incluye todo lo del modelo intermedio además del impacto de cada
conductor de coste en las distintas fases de desarrollo.
Para nuestro caso el modelo intermedio será el que usaremos, dado que realiza las
estimaciones con bastante precisión.
Así pues las fórmulas serán las siguientes:
E = Esfuerzo = a KLDC e * FAE (persona x mes)
T = Tiempo de duración del desarrollo = c Esfuerzo d (meses)
P= Personal = E/T (personas)
Para calcular el Esfuerzo, necesitaremos hallar la variable KDLC (Kilo-líneas de código),
donde los PF son 261,36 (dato conocido) y las líneas por cada PF equivalen a 32 según vemos en
la tabla que se ilustra a continuación:
LENGUAJE LDC/PF
Ensamblador 320

8. Resumen
El objetivo de este trabajo es ofrecer una metodología de estimación de costos basada en la
metodología COCOMO II (Boehm B., 2000) que sea aplicable a proyectos de desarrollo de
software que utilizan métodos ágiles de desarrollo (Kamaruddin, 2012). Este trabajo permitirá
aportar mejoras en la estimación de costos de proyectos ágiles considerando la productividad del
equipo y ofreciendo técnicas flexibles en el desarrollo de un producto de software. COCOMO II
(Milicic, 2004) es un modelo de estimación de costos referente en el mercado, pero la aplicación
del mismo es poco efectiva en ambientes de desarrollo caóticos (Ahmed E. Hassan, 2003)
compuestos por equipos de desarrollo inmaduros así como en proyectos que siguen una
metodología ágil de desarrollo. En este trabajo se espera establecer un modelo práctico de
estimación de costos que incorpore las características consideradas en los proyectos ágiles
(Pressman R., 2005). En la actualidad se observa la importancia de la estimación de costos de
proyectos ágiles debido al auge que estas metodologías están teniendo en el mercado nacional e
internacional
.
Summary
The aim of this paper is to provide a cost estimate methodology based on COCOMO II
methodology (B. Boehm, 2000) that is applicable to software development projects using
agile development methods (Kamaruddin, 2012). This work will provide improvements in
cost estimation considering agile project team productivity and offering flexible techniques
in the development of a software product. COCOMO II (Milicic, 2004) is a model of cost
estimation benchmark in the market, but its application is ineffective in environments chaotic
development (Ahmed E. Hassan, 2003) composed of teams of immature development as well
as projects They are following an agile development methodology. This work is expected to
establish a practical cost estimation model to incorporate the features seen in agile projects
(R. Pressman, 2005). Today the importance of estimating costs due to the rise agile projects
that these methodologies are having on the domestic and international markets is observed.

9. CONCLUSIONES.
¿Son los modelos de estimación de costo del software realmente generalizables para ambientes
diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables
para el ambiente típico de procesamiento de datos para los negocios?
Los modelos desarrollados en ambientes diferentes no trabajan muy bien, cuando se desea
acoplarlos. Los porcentajes de error calculados usando la formula de error relativo están en el
rango de 85 a 775%. Esta variación se debe la diferencia de ambientes.
¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así,
¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?
En términos de los resultados de error relativo los modelos que no usan líneas de código como
entrada fueron mejores. Pero en términos de los resultados de regresión están altamente
correlacionados.
En conclusión: 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.
LINKOGRAFIA
https://acevedodelacru.wordpress.com/conclusiones/
https://es.wikipedia.org/wiki/COCOMO
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm

10. CONCLUSIONES.
¿Son los modelos de estimación de costo del software realmente generalizables para ambientes
diferentes, para los cuales fueron desarrollados?. Si no, ¿pueden ser fácilmente moldeables
para el ambiente típico de procesamiento de datos para los negocios?
Los modelos desarrollados en ambientes diferentes no trabajan muy bien, cuando se desea
acoplarlos. Los porcentajes de error calculados usando la formula de error relativo están en el
rango de 85 a 775%. Esta variación se debe la diferencia de ambientes.
¿Los modelos que no usan líneas de código(SLOC) son tan exactos como las que si? Si es así,
¿Se podría eliminar las necesidad de estimar las líneas de código del proyecto?
En términos de los resultados de error relativo los modelos que no usan líneas de código como
entrada fueron mejores. Pero en términos de los resultados de regresión están altamente
correlacionados.
En conclusión: 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.
LINKOGRAFIA
https://acevedodelacru.wordpress.com/conclusiones/
https://es.wikipedia.org/wiki/COCOMO
http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm