INSTITUTO SUPERIOR JUAN MEJIA BACA

NOMBRES:

TEMA:

CURSO:

PROFESOR:

AÑO:

Año de la Consolidación del Mar de Grau

Densy de la cruz luceroYuliana arrieta flores

Cocomo

Marco Aurelio Porro Chulli

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.

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)bb D=cb(e)db 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

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

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

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.

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

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.

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