Modelo COCOMO ensayo PDF

Preview

Summary

Download Modelo COCOMO ensayo PDF

Description

Modelo COCOMO

Gestión de Proyectos de Software.

I.S.C. Francisco Rivera López

Alumnos: Aguilera Morfín Ángel Clemente González Jesús Eduardo Gil Apastillar Eduardo José Hernández Santoyo Ricardo

Índice. Resumen .........................................................................................................................................................2 Introducción ..................................................................................................................................................3 Modelo COCOMO ....................................................................................................................................... 4 Conclusión .................................................................................................................................................... 9 Bibliografía. .................................................................................................................................................. 10

Resumen El modelo de costos de construcción (o COCOMO para abreviar, COnstructive COst MOdel para abreviar) es un modelo matemático basado en la experiencia que se utiliza para estimar los costos de software1. Incluye tres submodelos, cada uno de los cuales proporciona niveles cada vez más altos de detalle y aproximación a medida que avanza el proceso de desarrollo de software: básico, intermedio y detallado. El término "constructivo" significa que el modelo puede ayudar a los estimadores a comprender mejor la complejidad del software. Este modelo es un ejemplo de variables simples estáticas y lo utilizan miles de directores de proyectos de software. COCOMO ayuda a estimar la carga de trabajo, el tiempo, el personal y los costos (incluido el desarrollo, el equipo y el mantenimiento). El modelo fue desarrollado por Barry W. Boehm a fines de la década de 1970 y principios de la de 1980 y se presentó en detalle en su libro "Economía de la ingeniería del software" (Prentice-Hall, 1981). 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

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. El modelo COCOMO original fue publicado por primera vez por Barry Boehm en 1981, reflejando las prácticas actuales de desarrollo de software. El término "constructivo" se refiere al hecho de que el modelo permite al estimador comprender mejor la complejidad del desarrollo de software. En los siguientes quince años, las técnicas de desarrollo de software han experimentado enormes cambios. Estos cambios incluyen el esfuerzo invertido en diseñar y administrar el proceso de desarrollo de software y crear productos de software. Desde mainframes para procesamiento nocturno por lotes hasta sistemas en tiempo real, se pone cada vez más énfasis en la reutilización del software existente y la construcción de nuevos sistemas utilizando componentes de software personalizados. El modelo proporciona tres "niveles de aplicación" basados en los factores considerados por el modelo: básico, intermedio y avanzado. Basic es un modelo estático de evaluación simple, que calcula la carga de trabajo (y el costo) del desarrollo de software basándose en el programa representado por la línea de código (LDC estimado). En el nivel intermedio, la carga de trabajo de desarrollo de software se calcula en función del tamaño del programa y un conjunto de "pautas de costos", que incluyen la evaluación subjetiva del producto, el hardware, el personal y los atributos del proyecto. Cuenta con funciones avanzadas, combina todas las funciones de la versión intermedia y evalúa el impacto de la ruta de costos en cada etapa del proceso de ingeniería de software (análisis, diseño, etc.).

Modelo COCOMO 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 Este añade al modelo básico quince modificadores opcionales para tener en cuenta en el entorno de trabajo, incrementando así la precisión de la estimación.2 Para este ajuste, al resultado de la fórmula general se lo multiplica por el coeficiente surgido de aplicar los atributos que se decidan utilizar. Los valores de las constantes a reemplazar en la fórmula son:

Se puede observar que los exponentes son los mismos que los del modelo básico, confirmando el papel que representa el tamaño; mientras que los coeficientes de los modos orgánico y rígido han cambiado, para mantener el equilibrio alrededor del semilibre con respecto al efecto multiplicador de los atributos de coste.

2.1 ATRIBUTOS Atributos del producto: garantía de funcionamiento requerida para creación del software, tamaño de la BBDD, etc. Atributos del ordenador usado: capacidad de almacenamiento, rapidez del ordenador, etc. Atributos del personal: experiencia en el tipo de software a desarrollar, en el lenguaje usado, etc. Atributos del proyecto: software usado para el desarrollo, lenguaje necesario para crear el software, etc. Todos estos atributos son ponderados matemáticamente en atendiendo de su relevancia. De esta manera se intenta aproximar el coste estimado al real, lo máximo posible. El significado de los atributos es el siguiente, según su tipo: •

De software o RELY: garantía de funcionamiento requerida al software. Indica las posibles consecuencias para el usuario en el caso que existan defectos en el producto. Va desde la sola inconveniencia de corregir un fallo (muy bajo) hasta la posible pérdida de vidas humanas (extremadamente alto, software de alta criticidad). o DATA: tamaño de la base de datos en relación con el tamaño del programa. El valor del modificador se define por la

o

relación: , donde D corresponde al tamaño de la base de datos en bytes y K es el tamaño del programa en cantidad de líneas de código. CPLX: representa la complejidad del producto.

•

De hardware o TIME: limitaciones en el porcentaje del uso de la CPU. o STOR: limitaciones en el porcentaje del uso de la memoria. o VIRT: volatilidad de la máquina virtual. o TURN: tiempo de respuesta requerido.

•

De personal o ACAP: calificación de los analistas. o AEXP: experiencia del personal en aplicaciones similares. o PCAP: calificación de los programadores.

o o •

VEXP: experiencia del personal en la máquina virtual. LEXP: experiencia en el lenguaje de programación a usar.

De proyecto o MODP: uso de prácticas modernas de programación. o TOOL: uso de herramientas de desarrollo de software. o SCED: limitaciones en el cumplimiento de la planificación.

3. MODELO

DETALLADO

Presenta principalmente dos mejoras respecto al anterior: •

Los factores correspondientes a los atributos son sensibles o dependientes de la fase sobre la que se realizan las estimaciones. Aspectos tales como la experiencia en la aplicación, utilización de herramientas de software, etc., tienen mayor influencia en unas fases que en otras, y además van variando de una etapa a otra.

Establece una jerarquía de tres niveles de productos, de forma que los aspectos que representan gran variación a bajo nivel, se consideran a nivel módulo, los que representan pocas variaciones, a nivel de subsistema; y los restantes son considerados a nivel sistema. 3.1. ESTIMACIÓN DEL ESFUERZO. •

A. 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 genera 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. B. Principio de estimación del esfuerzo. B.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,

es

= (S · A) / 100. B.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.

Conclusión Es uno de los modelos más documentados en la actualidad y es muy fácil de usar. Respecto a los 63 ítems utilizados, es correcto, aunque no se debe inferir que debe ser siempre válido. Un tema que necesita atención es cómo adaptar la ecuación exponencial a una organización específica, lo que no parece fácil. La estimación es más precisa a medida que se toman en cuenta mayor cantidad de factores que influyen en el desarrollo de un producto de software. Aunque estos modelos mejoran en diferentes entradas para estimar la carga de trabajo, no modelan adecuadamente los factores que afectan la productividad. Si la industria va a enfrentar cambios futuros, se necesita más investigación para estudiar cómo medir todos los factores que afectan el sistema de productividad profesional.} Cuando desea acoplarlos, los modelos desarrollados en diferentes entornos no funcionan bien. El porcentaje de error calculado usando la fórmula de error relativo está en el rango de 85 a 775%. Este cambio es causado por diferencias ambientales. En términos de resultados de error relativo, es mejor un modelo que no utilice líneas de código como entrada. Pero en términos de resultados de regresión, están altamente correlacionados.

Bibliografía. -

https://es.wikipedia.org/wiki/COCOMO http://www.sc.ehu.es/jiwdocoj/mmis/cocomo.htm https://www.eoi.es/blogs/cesaraparicio/2012/05/06/el-modelo-cocomo-para-estimarcostes-en-un-proyecto-de-software/ https://acevedodelacru.wordpress.com/modelo-cocomo-2/ https://ipmoguide.com/cocomo-el-modelo-constructivo-de-costos/...