El Modelo COCOMO

COCOMO. El Modelo Constructivo de Costos (COnstructive COst Model) es una jerarqua de modelos de estimacin para el software. Esta jerarqua est constituida por los siguientes modelos:

El modelo COCOMO bsico es un modelo univariable esttico que calcula el esfuerzo (y el costo) del desarrollo de software en funcin del tamao del programa expresando en lneas de cdigo (LDC) estimadas. El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en funcin del tamao del programa y de un conjunto de conductores de costo, que incluyen la evaluacin subjetiva del producto, del hardware, del personal y de los atributos del proyecto. El modelo COCOMO avanzado incorpora todas las caractersticas de la versin intermedia y lleva a cabo una evaluacin de impacto de los conductores de costo en cada fase (anlisis, diseo, etc.) del proceso de ingeniera de software. Los modelos COCOMO estn definidos para tres tipos de proyecto de software. Modelo Orgnico. Proyectos de software relativamente pequeos y sencillos en los que trabajan pequeos equipos, con buena experiencia en la aplicacin, sobre el conjunto de requisitos poco rgidos (por ejemplo, un programa de anlisis termal desarrollado para un grupo calrico). Modelo Semiacoplado. Proyectos de software intermedios (en tamao y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rgidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestin de base de datos). Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegacin para un avin). Las ecuaciones del modelo COCOMO bsico tienen la siguiente forma: E = ab (KLDC) exp (bb) D = cb (E) exp (db) donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de desarrollo en meses cronolgicos y KLDC es el nmero estimado de Lneas de Cdigo distribudas (en miles) para el proyecto. Las ecuaciones del modelo COCOMO intermedio toma la forma:

E = ai (KLDC) exp (bi) x FAE donde E es el esfuerzo aplicado en personas-mes, KLDC es el nmero estimado de Lneas de Cdigo distribudas para el proyecto.

1. Introduccin El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponindolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarqua de modelos de estimacin de costes software que incluye submodelos bsico, intermedio y detallado. Las ecuaciones de estimacin del esfuerzo de desarrollo tienen la forma b E aiS i m(X) con S el nmero de miles de lneas de cdigo fuente m(X) es un multiplicador que depende de 15 atributos en la siguiente tabla se muestran los coeficientes para los diferentes modos Bsico ai 2.4 3.0 3.6 Intermedio ai 3.2 3.0 2.8

Modo Orgnico Semiencajado Empotrado

bi 1.05 1.12 1.2

bi 1.05 1.12 1.2

2. Modelo Bsico Este modelo trata de estimar, de una manera rpida y ms o menos burda, la mayora de proyectos pequeos y medianos. Se consideran tres modos de desarrollo en este modelo: orgnico, semiencajado y empotrado. 2.1. Modo orgnico. En este modo, un pequeo grupo de programadores experimentados desarrollan software en un entorno familiar. El tamao del software vara de unos pocos miles de lneas (tamao pequeo) a unas decenas de miles de lneas (medio), mientras que en los otros dos modos el tamao vara de pequeo a muy grandes (varios cientos de miles de lneas). En este modo, al igual que en los otros, el coste se incrementa a medida que el tamao 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 tamao expresado en miles de lneas de cdigo fuente. El tiempo de desarrollo se da por td = 2.5 Km0.38 donde Km se obtiene de la ecuacin 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.

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 difcil 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 orgnico, 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 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. Las ecuaciones son Km = 3.0 Sk1.12 y el tiempo de desarrollo por td = 2.5 Km0.35. 2.4. Notas al Modelo Bsico 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 bsico puesto que se obvian muchas caractersticas del entorno. 3. Modelo Intermedio En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisin de la estimacin. 3.1. Ecuaciones nominales de coste. Para cada modo de desarrollo, los 15 atributos del coste intervienen como multiplicadores en el coste nominal, Kn, para producir el coste ajustado. Las ecuaciones nominales de coste para el modelo intermedio son modo orgnico Kn = 3.2 Sk1.05 modo semiencajado Kn = 3.0 Sk1.12 modo empotrado Kn = 2.8 Sk1.20 Notemos que: los exponentes son los mismos que los del modelo bsico, confirmando el papel que representa el tamao; los coeficientes de los modos orgnico y empotrado han cambiado, para mantener el equilibrio alrededor del semiencajado con respecto al efecto multiplicador de los atributos de coste. 3.2. Atributos de coste.

Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo. De un anlisis estadstico de ms de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO. Estos atributos se agrupan en cuatro categoras: atributos del producto, atributos del ordenador, atributos del personal y atributos del proyecto. (1) Atributos del producto RELY: garanta de funcionamiento requerida al software DATA: tamao de la base de datos CPLX: complejidad del producto (2) Atributos del ordenador TIME: restriccin de tiempo de ejecucin STOR: restriccin del almacenamiento principal VIRT: volatilidad de la mquina virtual TURN: tiempo de respuesta del ordenador (3) Atributos del personal ACAP: capacidad del analista AEXP: experiencia en la aplicacin PCAP: capacidad del programador VEXP: experiencia en mquina virtual LEXP: experiencia en lenguaje de programacin (4) Atributos del proyecto MODP: prcticas de programacin modernas TOOL: utilizacin de herramientas software SCED: plan de desarrollo requerido. Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo -- bajo -- nominal -- alto -- muy alto -- extremadamente alto. En la tabla se muestran los valores del multiplicador para cada uno de los 15 atributos. Estos 15 valores se multiplican al Kn, y nos proporciona el esfuerzo ajustado al entorno. 3.3. Significado de los atributos. A. RELY Indica las posibles consecuencias para el usuario en el caso que todava existan defectos en el producto. Una puntuacin 'muy baja' indica que solamente hace falta eliminar los defectos sin ninguna otra consecuencia. "very low": el efecto de un fallo del software simplemente trae como consecuencia la inconveniencia de corregir el fallo "low": el efecto de un fallo software es una prdida fcilmente recuperable para los usuarios "nominal": el efecto es una moderada prdida para los usuarios, pero es una situacin de la que se puede salir sin excesiva dificultad "high": el efecto es una gran prdida financiera o una inconveniencia masiva humana "very high": el efecto es una prdida de vidas humanas. B. DATA

Indica el tamao de la base de datos a desarrollar en relacin con el tamao del programa. Tenemos cuatro segmentos con la razn 10-100-1000, que determinan las puntuaciones de 'bajo' a 'muy alto'. Se define por el cociente D tamao de la base de datos en bytes P tamao del programa en DSI donde D es la cantidad de datos a ser articulada y almacenada en memoria secundaria (cintas, discos, etc.) hasta el tiempo de entrega del producto software. C. CPLX Indica la complejidad de cada mdulo y se utiliza para determinar la complejidad compuesta del sistema. Entonces la puntuacin puede variar de 'muy bajo' si el mdulo est compuesto de expresiones matemticas simples a 'extremadamente alto' para mdulos que utilizan muchos recursos de planificacin. D. TIME Siempre ser ms exigente para un programador escribir un programa que tiene una restriccin en el tiempo de ejecucin. Esta puntuacin se expresa en el porcentaje de tiempo de ejecucin disponible. Es 'nominal' cuando el porcentaje es el 50%, y 'extremadamente alto' cuando la restriccin es del 95%. E. STOR Se espera que un cierto porcentaje del almacenamiento principal sea utilizado por el programa. El esfuerzo de programacin se incremente si el programa tiene que correr en un volumen menor del almacenamiento principal. STOR captura este esfuerzo extra de 'nominal' cuando la reduccin del almacenamiento principal es del 50% a 'extremadamente alto' cuando la reduccin es del 95%. F. VIRT Durante el desarrollo del software la mquina (hard y soft) en la que el programa se va a desarrollar puede sufrir algunos cambios. VIRT lo refleja desde 'bajo' a 'muy alto'. G. TURN Cuantifica el tiempo de respuesta del ordenador desde el punto de vista del programador. Cuanto mayor sea el tiempo de respuesta, ms alto ser el esfuerzo humano. TURN puede variar desde 'bajo' para un sistema interactivo a 'muy alto', cuando el tiempo medio de respuesta es de ms de 12 horas. H. ACAP La capacidad del grupo de analistas, en trminos de habilidad de anlisis, eficiencia y capacidad para cooperar tiene un impacto significativo en el esfuerzo humano. Cuanto ms capaz sea el grupo, menos esfuerzo ser necesario. ACAP puede variar desde 'muy bajo' a 'muy alto'. I. AEXP La experiencia del grupo en una aplicacin similar tiene una gran influencia en el esfuerzo. Puede variar desde 'muy bajo' (menos de cuatro meses de experiencia) a 'muy alto' (mayor de 12 aos de experiencia). "very low": < 4 meses experiencia media "low": 1 ao de experiencia media "nominal": 3 aos de experiencia media "high": 6 aos de experiencia media "very high": > 12 aos, o reimplementacin de un subsistema

J. PCAP La cuantificacin es similar a la de ACAP, pero en este caso relacionado con los programadores. Se aplica a los programadores como grupo, pero no a los programadores individuales. K. VEXP Cuanto mayor sea la experiencia del grupo de programacin con el procesador, menor ser el esfuerzo necesario. VEXP puede variar desde 'muy bajo', cuando la experiencia es menor de un mes, a 'alto' cuando esta experiencia es mayor de 3 aos. "very low": < 1 mes experiencia media "low": 4 meses "nominal": 1 ao "high": > 3 aos L. LEXP Un grupo de programadores con amplia experiencia en un lenguaje determinado programar de una manera mucho ms segura, generando un menor nmero de defectos y de requerimientos humanos. Puede variar desde 'muy bajo' a 'alto' para un grupo de un mes a tres aos de experiencia, respectivamente. "very low": < 1 mes experiencia media "low": 4 meses de experiencia media "nominal": 1 ao de experiencia media "high": > 3 aos M. MODP Utilizacin de modernas prcticas de programacin. Vara de 'muy bajo' a 'muy alto'. Estas prcticas incluyen, por ejemplo, programacin estructurada y desarrollo 'topdown'. "very low": no se utilizan prcticas modernas de programacin -PMP-. "low": uso experimental de algunas PMP "nominal": experiencia razonable en el uso de algunas PMP "high": experiencia razonable en gran parte de PMP "very high": uso habitual de PMP N. TOOL El uso adecuado de herramientas software es un multiplicador de la productividad. La puntuacin de TOOL vara desde 'muy bajo' cuando slo se utilizan herramientas bsicas, a 'muy alto' cuando se utilizan herramientas especficas. O. SCED El tiempo nominal de desarrollo, tal como se define en el modo bsico, es el plazo que requiere menor esfuerzo humano. Cualquier apresuramiento ('muy bajo') o retraso ('muy alto') demandarn ms esfuerzo. 3.4. Notas al modelo Intermedio. Este modelo proporciona una manera potente de capturar la influencia del entorno en el proyecto. 4. Modelo Detallado Este modelo puede procesar todas las caractersticas del proyecto para construir una estimacin. Introduce dos caractersticas principales

(1) Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven ms afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignacin del personal para cada fase del proyecto. (2) Jerarqua del producto a tres niveles. Se definen tres niveles de producto. Estos son mdulo, subsistema y sistema. La cuantificacin se realiza al nivel apropiado, esto es, al nivel al que es ms susceptible la variacin. 4.1. Estimacin del esfuerzo. A. Fases de desarrollo El desarrollo del software se lleva a cabo a travs de cuatro fases consecutivas: requerimientos/planes, diseo del producto, programacin y prueba/integracin. 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 especificacin 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 tamao (de 2000 LOC a 512000 LOC). Diseo del producto. La segunda fase del ciclo de desarrollo COCOMO se preocupa de la determinacin 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. Programacin. La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos subfases: diseo detallado y prueba del cdigo. Esta fase requiere del 48% al 68% del esfuerzo nominal Kn, y dura del 24% Al 64% del tiempo nominal de desarrollo. Prueba/Integracin. 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 estimacin del esfuerzo. B.1. Tamao 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 diseo (D%), cdigo (C%) e integracin (I%) a ser modificadas. Se calcula un factor de ajuste A A = 0.4 D + 0.3 C + 0.3 I El tamao equivalente, Sequ es Sequ = (S A) / 100. B.2. Clculo del esfuerzo. El tamao equivalente se calcula para cada mdulo. El esfuerzo asignado al desarrollo de cada mdulo se obtiene entonces a travs de: (1) seleccionar los valores apropiados de los atributos de coste para cada fase (2) multiplicar los atributos de coste para cada mdulo 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.

Parte II (Unidad 5) La Identificacin de Riesgos en proyectos de software consiste en la determinacin de elementos de riesgos potenciales mediante la utilizacin de algn mtodo consistente y estructurado; este es, probablemente, el paso ms importante entre todos aquellos que componen las actividades de Administracin de Riesgos, ya que sin la correcta determinacin de los mismos, no es posible desarrollar e implementar anticipadamente respuestas apropiadas a los problemas que puedan surgir en el proyecto [Futrell, et al., 2002]. El resultado de la identificacin de riesgos es una lista conteniendo los riesgos que se han identificados y su categora correspondiente

Seguimiento y control de riesgos: Una vez identificados los riesgos del proyecto, es necesario realizar un seguimiento a stos, adems de supervisar los riesgos residuales, identificar nuevos riesgos, ejecutar planes de respuesta a los riesgos y evaluar su efectividad a lo largo del ciclo de vida del proyecto. Aqu revisaremos la gua del PMBOK para la gestin del riesgo la cul consta de seis etapas: Planificacin de la gestin de riesgos. Identificacin de riesgos. Anlisis cualitativo de riesgos. Anlisis cuantitativo de riesgos. Planificacin de la respuesta a los riesgos. Seguimiento y control de riesgos. 1. Planificacin de la gerencia de riesgos Para hacerla efectivamente en proyectos, los integrantes del equipo de proyecto debern centrar sus esfuerzos en planificar concienzudamente la cantidad de riesgo existente. Cuando se planifica el proyecto el tiempo deber estar en consonancia especficamente con el plan de la gerencia del riesgo, el cul indicar al equipo como abordar el riesgo. Por ejemplo, se debera especificar el tipo de factores potenciales de riesgo que se enfrentarn en las reuniones semanales. En organizaciones que han desarrollado consecuencia de los procesos de manipulacin del riesgo, el plan se enfocar en la adopcin de estos procesos dentro de un contexto especfico del proyecto dado. 2. Identificacin de riesgos Es un proceso para descubrir los eventos potenciales de riesgo, para evitar incidentes inesperados, el cul debera realizarse sistemticamente. Se deben enfocar tanto los riesgos internos como externos, los predecibles versus los no predecibles, sobre los que tenemos una medida de control versus los incontrolables, y aquellos tcnicos versus los no tcnicos.

A medida que una organizacin gana experiencia identificando riesgos, se deberan documentar los hallazgos, como mnimo debern hacer checklists"(listas de revisin) de los factores de riesgos que se observaran en los proyectos tpicos. Si fuera posible, los diferentes factores de riesgos se deben sopesar de acuerdo a su importancia. 3. Anlisis cualitativo de riesgos Los modelos de escenarios de riesgo desde el punto de vista cualitativo pueden llevarnos a predecir los eventos que pueden ocurrir en nuestros proyectos, as como su impacto en el coste o en el inventario o en los recursos que se necesitan asociar a la incidencia de un evento de riesgo particular. 4. Anlisis cuantitativo de riesgos Ciertamente, un anlisis cualitativo de riesgo bien hecho proveer al analista de riesgo un buen sentido de lo que encontrar en sus proyectos, ellos tendrn una mejor percepcin si pueden conducir un anlisis cuantitativo de riesgo por el modelo de escenarios de riesgo, haciendo una serie de anlisis de que si, que lo ayudaran a predecir cosas como el impacto en el coste y la programacin de los recursos que necesitan si ocurre un evento particular de riesgo. 5. Planificacin de la respuesta a los riesgos Los analistas de riesgos poseen una idea de que riesgos pueden encontrarse (a travs de la identificacin) y de sus consecuencias (a travs del anlisis cualitativo y cuantitativo de riesgo). Ahora la cuestin es qu hacer con respecto a ellos. Se deben desarrollar estrategias para cambiar esas situaciones de riesgo. La identificacin y el anlisis de los riesgos nos proporciona un conocimiento de cmo ocurren en el proyecto, el planificador del riesgo nos construye acciones que se deben tomar para evitarlos o para frenar sus impactos. Estas estrategias incluyen: transferencia de riesgo (tambin llamado riesgo desviado), disminuir el riesgo, evitarlo y la aceptacin del riesgo. Con la transferencia: planeamos transferir las consecuencias de la situacin de riesgo a otro lugar, comnmente hacemos esto cuando tomamos un seguro. Ejemplo, cuando nuestro coche asegurado se incendia, la compaa asume la obligacin de pagar la reparacin. Otro estndar de riesgo transfiere tcnicas que incluyen garantas y contratos. En el caso de las garantas, un vendedor no ofrecera respuesta a la poltica de reemplazo de los equipos elctricos comprados en un perodo de 90 das. La disminucin del riesgo: se enfoca en reducir el riesgo ajustando problemas que puedan elevar los niveles de riesgo. Por ejemplo: en la inspeccin de una mquina de pulir se encuentra que una de las correas perdi una pieza, lo que llevara a una produccin de partes defectuosas, apretando la correa disminuimos la probabilidad de tener defectos. La evasin del riesgo se reconoce como la forma de navegar libre de incmodos sucesos por lo que hay que evitar hacer cosas que nos puedan molestar. Finalmente, aceptar el riesgo, es reconocer que el mundo est lleno de l y que necesitamos aprender como vivir con el riesgo. As, cuando aplicamos iniciativas riesgosas, estableceremos contingencias para detallar sus consecuencias. Por ejemplo: la investigacin

y el desarrollo de proyectos es notoriamente riesgosa debido a que tenemos poco conocimiento de lo que suceder; por otra parte, para las posibilidades desafortunadas tales como sobrecostes y tropiezos en el inventario se tomaran contingencias para cubrir su posible ocurrencia. 6. Seguimiento y control de riesgos Hasta ahora, hemos visto que la gerencia del riesgo es una gran va pasiva. Tratamos de anticiparnos antes de que ocurran eventos incmodos de riesgo. Esta es la naturaleza fundamental de asumir el riesgo, un gran ejercicio intelectual. Pero, una vez mas un proyecto est en el camino y nosotros encontraremos la frecuencia de los eventos de riesgo, los cules debemos manejar agresivamente. El riesgo siempre existe, pero puede ser controlado o asumido!. Con la monitorizacin y control, tomamos conductas para delinear el riesgo y as intentar resolver los problemas que se presenten, y ver si las acciones tomadas producen los efectos deseados.