Guía práctica para COCOMO 2.0 Ingeniería de Software Avanzada

Transcripción

1 Universidad Técnica Federico Santa María Departamento de Informática Guía práctica para COCOMO 2.0 Ingeniería de Software Avanzada 1 INTRODUCCIÓN COCOMO 2.0 (Constructive Cost Model, COCOMO) surge como respuesta a las falencias de COCOMO original (COCOMO 81) y a la necesidades planteadas por un nuevo escenario para el desarrollo de software (cambios tecnológicos, nuevos modelos del ciclo de vida, nuevas herramientas, reingeniería, generadores de aplicaciones, enfoque orientado a objetos, etc.) proponiendo principalmente el uso de diferentes modelos de tamaño según el avance del proyecto y el nivel de conocimiento del sistema en desarrollo. En concreto COCOMO 2.0 provee tres modelos de estimación secuenciales que corresponden a las siguientes etapas: Etapa 1 o Application Composition Model orientada a apoyar la estimación en las etapas tempranas del desarrollo de software, donde básicamente se cuenta con escasa información sobre los requerimientos del sistema. Este modelo además apoya la estimación para el desarrollo de prototipos rápidos en cualquier etapa del ciclo de vida del software. Etapa 2 o Early Design Model enfocada a apoyar la estimación tras la definición de los requerimientos y así respaldar la toma de decisiones sobre la evaluación de arquitecturas y conceptos de operación alternativos para el desarrollo de software. Etapa 3 o Post-Architecture Model orientada a apoyar la estimación durante el desarrollo del sistema. 1

2 2 ETAPA 1: THE APPLICATION COMPOSITION MODEL 2.1 Descripción general La etapa 1 esta enfocada a apoyar la estimación de esfuerzo durante las fase de planificación de un proyecto de desarrollo de software. Esto implica que la estimación deba realizarse sobre la base de información exigua y en muchos casos insuficiente. Dadas estas circunstancias, COCOMO 2.0 propone que es posible identificar elementos de alto nivel que permitan estimar el tamaño del producto final, base fundamental para el cálculo del esfuerzo. Luego, se sugiere estimar el tamaño del producto como puntos objeto (Object Points, OP) que capturan el tamaño en términos de generadores de esfuerzo de alto nivel: informes, ventanas, componentes de tercera generación, vistas y tablas de datos. 2.2 Estimación del esfuerzo En la etapa 1 de COCOMO 2.0 el esfuerzo se define como: E=NOP/PROD Donde E: esfuerzo en personas-mes NOP (New Object Points): nuevos puntos objeto PROD: razón de productividad A. Estimación de tamaño a través de NOP Paso 1: Identificación de los tipos de objeto. Lista de las ventanas, informes y componentes de tercera generación (objetos, clases, herencia, etc.) que abarcará la aplicación. Paso 2: Clasificación de cada tipo de objeto según su complejidad. Identificados los objetos, es necesario para cada uno de ellos (informes y ventanas) determinar el número de vistas que contiene, el número de tablas de datos que referencia y el tipo de fuente de dichas tablas (servidores o clientes). Con estos datos y según las tablas 1 y 2 se obtiene el nivel de complejidad (simple, medio, o difícil) de cada objeto. Observación: Los componentes de tercera generación son clasificados como difíciles. Número de vistas contenidas Total < 4 (<2 srvr, <3 clnt) Ventanas Número y fuentes de tablas de datos Total < 8 (2/3 srvr, 3-5 clnt) Total >8 (>3 srvr, >5 clnt) <3 Simple Simple Media 3-7 Simple Media Difícil >8 Media Difícil Difícil Tabla 1 2

3 Número de vistas Contenidas Total < 4 (<2 srvr, <3 clnt) Informes Número y fuentes de tablas de datos Total < 8 (2/3 srvr, 3-5 clnt) Total >8 (>3 srvr, >5 clnt) 0-1 Simple Simple Media 2-3 Simple Media Difícil >4 Media Difícil Difícil Tabla 2 Paso 3: Cálculo de los puntos objeto (Object Points, OP). Para calcular los OP se ingresa el número de objetos identificados dentro de cada categoría de complejidad de acuerdo a la siguiente tabla. Luego se realiza un cálculo simple cuyo resultado son los OP. Tipo de objeto Complejidad Peso Simple Media Difícil Subtotal Ventana x 1 + x 2 + x 3 = Informe x 2 + x 5 + x 8 = Componente de 3GL x 10 = Total OP (+) = Tabla 3. Cálculo de OP. Observación: El factor multiplicador de cada celda refleja el esfuerzo relativo requerido para implementar un tipo de objeto con un nivel de complejidad dado. Paso 4: Cálculo de los Nuevos Puntos Objeto (New Object Points, NOP). El cálculo de los NOP corresponde a la consideración del reuso como un factor importante dentro de la estimación del tamaño del producto final. NOP= (OP)/(100-%r)/100 Donde %r corresponde a los objetos (informes, ventanas y componentes de 3GL) de proyectos previos que serán reutilizados en el proyecto actual. B. Estimación de PROD Paso 1: Determinación de la razón de productividad PROD. Para el cálculo de la productividad, en la etapa 1 de COCOMO 2.0 se consideran dos aspectos clave: la experiencia y la capacidad de los desarrolladores, y la madurez y la capacidad de ICASE. Cada uno de estos factores debe ser clasificado como muy bajo, bajo, nominal, alto o muy alto, para luego y según la siguiente tabla establecer el valor de la razón de productividad, PROD. Experiencia y capacidad de los desarrolladores Madurez y capacidad de ICASE Muy Baja Muy Baja Baja Nominal Alta Muy Alta Baja Nominal Alta Muy Alta PROD Tabla 4. Estimación de la razón de productividad (PROD). Dado que el valor que tomen los factores involucrados puede ser substancialmente diferente (Por ejemplo: Experiencia y capacidad de los desarrolladores= Alta, y Madurez y capacidad de ICASE= Muy Baja) los autores recomiendan privilegiar el valor más cercano al nominal. 3

4 3 ETAPAS 2 Y 3: THE EARLY DESIGN MODEL & THE POST- ARCHITECTURE MODEL 3.1 Descripción general Una vez que la etapa de planificación ha sido aprobada, es necesario tomar decisiones sobre las arquitecturas y los conceptos de operación alternativos. Luego, COCOMO 2.0 establece una segunda etapa orientada precisamente a apoyar esta tarea. La etapa 2 cuenta con mayor información sobre los requerimientos del proyecto, mas ésta aún es insuficiente para una estimación precisa. Ante ello COCOMO 2.0 propone utilizar los puntos de función (Function Points, FP) como estimador de tamaño, pues ofrecen una descripción mejor que los OP para estimar la funcionalidad capturada en los requerimientos. COCOMO 2.0 define, además, una tercera etapa orientada a entregar información (estimaciones) sobre el estado del proyecto para facilitar el control de posibles desviaciones en relación a la planificación inicial (tiempo y esfuerzo) durante el desarrollo del sistema. Esto implica que se cuenta con mayor información sobre el sistema, por lo que COCOMO 2.0 sugiere la contabilización de las líneas de código (LOC) y el uso de cost drivers de una manera similar a COCOMO original, incorporando modelos de reuso, modelos reingeniería, y nuevos cost drivers. 3.2 Estimación de esfuerzo A. Estimación del esfuerzo nominal Para ambas etapas el esfuerzo nominal es definido como: PM nominal = A* (Tamaño) B Donde A: constante B: factor de economía des-economía de escala Tamaño: KSLOC Paso 1: Determinación de la constante A. El propósito de la constante es capturar el efecto multiplicador del aumento del tamaño de un proyecto. Hasta el momento ha sido establecida temporalmente como: A= 2.45, para la etapa 2 A= 2.55, para la etapa 3. Paso 2: Cálculo del factor de economía de escala B. El factor de B captura la economía de escala en un proyecto. Se habla de economía de escala (B<1) cuando al aumentar el tamaño del producto al doble, el esfuerzo aumenta en una cifra menor que el doble, por lo tanto un aumento en el tamaño del producto produce un aumento de la productividad. Si el esfuerzo aumenta en el mismo factor que el tamaño se habla de equilibrio (B=1), y en el caso que aumentara más que el doble se habla de des-economía (B>1). En COCOMO original este factor correspondía a una constante que variaba según el tipo o modo de desarrollo de software (orgánico, semi-desconectado, o embebido). Sin embargo durante el desarrollo de COCOMO 2.0 se establece que es más adecuado determinar B según los elementos que influyen sobre la 4

5 productividad del desarrollo, es decir los factores de escala que determinan una economía o des-economía de escala. Estos son: Precedentes (Precedentedness,PREC): experiencia de los desarrolladores en el desarrollo de proyectos similares. Flexibilidad (Development Flexibility, FLEX): flexibilidad del proceso de desarrollo en relación con los requerimientos establecidos. Arquitctura y resolución de los riesgos (Architecture/ Risk Resolution, RESL): gestión de los riesgos medido como porcentaje de respuesta que es capaz de lograr la organización ante la ocurrencia de algún riesgo. Cohesión del equipo (Team Cohesion, TEAM): tipo de interacción de los miembros de la organización desarrolladora. Madurez del proceso (Process Maturity, PMAT): nivel de madurez de la organización en relación con las áreas de prácticas clave (Key Practices Areas, KPA) del CMM (Capability Maturity Model). Cada uno de estos factores de escala es ponderado con un peso w i, que varía entre 0 y 5, según los criterios de la siguiente tabla: Scale Very Low Nominal High Very Extra Fators Low High High w i PREC FLEX RESL TEAM PMAT thoroughly unpreceden ted largely unpreceden ted rigorous occasional relaxation little some (20%) (40%) very some difficult difficult interactions interactions somewhat unpreceden ted some relaxation often (60%) basically cooperative interactions generally familiar general conformity Generally (75%) largely cooperative largely familiar Throughly familiar some general conformity goals mostly full (90%) (100%) highly cooperative Weighted average of Yes answers to CMM Maturity Questionnaire Tabla 5. Ponderación de los factores de escala. seamless interaction Para calcular el PMAT se evalúa el porcentaje de cumplimiento de las 18 áreas de prácticas clave definidas en el CMM del Software Engineering Institute, SEI (Ver tabla 6). Luego el PMAT se calcula como: PMAT= 5 - S (((KPA%*i)/100)*5/18),i=1,..,18 KPA Almost always Often About half Occassion_ ally Rarely if ever Does not apply Don t know KPA% >90% 60-90% 40-60% 10-40% <10% Requeriments Management Software Project Management Software Project Tracking and Oversight Software Subcontract Management Software Configuration Management Software Quality Assurance Organization Process Focus Organization Process Definition Trainning Program Integrated Software Management Software Product Engineering Intergoup Coordination Peer Reviews 5

6 KPA Almost always Often About half Occassion_ ally Rarely if ever Does not apply KPA% >90% 60-90% 40-60% 10-40% <10% Quantitative Process Management Software Quality Management Defect Prevention Tecnology Change Mangement Process Change Management Tabla 6. Cuestionario de madurez del CMM (continuación). Una vez ponderados los factores de escala es posible calcular el factor de economía de escala, B, como: B= 0,91 + 0,01* S w i, i=1,..,5 Donde w i corresponde al peso asignado a cada factor de escala. Paso 3: Estimación de tamaño. Don t know El método para estimar el tamaño en COCOMO 2.0 está fuertemente determinado por la información disponible. Como se vio anteriormente en la etapa 1, dada la escasa información, el tamaño se calcula en términos de OP. En la etapa 2, la situación es diferente, la especificación de requerimientos ya es más sólida por lo que una estimación por medio de puntos de función (Function Points, FP) y su traducción a miles de líneas de código (KSLOC) parece más adecuada. En la etapa 3 en cambio, ya se está en el desarrollo propiamente tal. Luego, dependiendo del estado de avance del desarrollo se podrían contabilizar las líneas de código directamente, en caso contrario se mantiene el cálculo por PF. El cálculo de FP se realiza según el procedimiento establecido por IFPUG. Sin embargo, para COCOMO 2.0 lo relevante es establecer los puntos de función no ajustados (Unadjusted Function Points, UFP). Es más, el tamaño en KSLOC es calculado por tabla a través del valor de UFP y no PF. En relación a las LOC la dificultad se encuentra en la definición de qué es o no una LOC. Para establcer consistencia al momento de contabilizar las LOC directamente se sugiere utilizar la Checklist de definición de LOC del SEI. Mostrado a continuación. 6

7 7

8 Paso 4: Ajuste del tamaño por reuso. Al igual que en la etapa 1, en las presentes etapas el reuso es considerado un factor importante dentro de la estimación. Para ambos casos, se calculan las líneas de código equivalentes (ESLOC) producto del reuso. Este cálculo requiere de la estimación de los siguientes elementos de entrada : ASLOC: tamaño del software (en LOC) que debe ser adaptado. DM: porcentaje de diseño que debe modificarse en el software para adaptarlo a los nuevos objetivos y al nuevo ambiente. CM: porcentaje de código que debe modificarse en el software para adaptarlo a los nuevos objetivos y al nuevo ambiente. IM: porcentaje del esfuerzo de integración original que debe ser modificado para integrar el software reusado. Además, en la estimación de las ESLOC se consideran la influencia de los siguientes elementos: La comprensión del software (Software Understanding, SU) que será reutilizado en términos de su estructura, su correspondencia con la aplicación en desarrollo y la documentación disponible. El nivel de evaluación y asimilación (Assessment & Assimilation, AA) requerido para determinar cuándo un modulo es apropiado o no para la aplicación y para integrar su descripción a la descripción del producto. La familiaridad del programador con el software que será reutilizado. (Programmer`s Unfamiliarity, UNFM) Cada uno de estos factores es calculado por medio de las tablas 8, 9 y 10 respectivamente. Very Low Nominal High Very High Low SU (%) Structure Application Clarity Self Descriptive ness AA Increment Very low cohesion, high coupling, spaghetti code No match between program and application world views Obscure code; documentatio n missing, obscure or obsolete 0 None Moderately low cohesion, high coupling Some correlation between program and application Some code commentary and headers; some useful documentation Reassonably well structured, some weak areas Moderate correlation between program and application Moderate levels of code commentary, headers, documentations Tabla 8. Estimación del SU. High cohesion, low coupling Good correlation between program and application Good code commentary and headers, useful documentation; some weak areas Level of AA Effort 2 Basic module search and documentation Strong modularity, information hiding in data/control structures Clear match between program and application world views Self descriptive code, documentation up to date, well organized with design rationale 4 Some module Test and Evaluation, documentation 6 Considerable module Test and Evaluation, documentation 8 Extensive module Test and Evaluation, documentation Tabla 9. Estimación del AA. 8

9 UNFM Increment 0,0 Completely familiar 0,2 Mostly familiar 0,4 Somewhat familiar 0,6 Considerably familiar 0,8 Mostly unfamiliar Level of Unfamiliarity 1,0 Completely unfamiliar Tabla 10. Estimación del UNFM. Una vez determinados los ASLOC, DM, CM, IM, SU, AA y UNFM es posible calcular las ESLOC como: ESLOC=[ASLOC(AA+AAF(1+0,02(SU)(UNFM)))]/100, AAF<=0,5 ESLOC=[ASLOC(AA+AAF+(SU)(UNFM))]/100, AAF>0,5 Donde AAF= 0,4(DM) + 0,3(CM) + 0,3(IM) Paso 5: Ajuste por reingeniería. Otro de los aspectos considerados importantes en el momento de estimar el esfuerzo nominal es la reingeniería, la cual se entiende como la capacidad de migrar automáticamente de la aplicación A a B. La reingeniería es considerada mediante el siguiente ajuste: Donde PM nominal = A* (Tamaño) B + [ASLOC (AT/100)/ATPROD] ASLOC: tamaño del software (LOC) que debe ser adaptado (estimado subjetivamente). AT: % del código que será reingenierado mediante traducción automática (Ver tabla 11). ATPROD: razón de productividad de la traducción automática. (temporalmente, 2400[LOC/Personmonth] ) Re-engineering target AT Batch processing 96% Batch with SORT 90% Batch with DBMS 88% Batch, SORT, DBMS 82% Interactive 50% Tabla 11. Estimación del AT. B. Estimación del esfuerzo ajustado En forma análoga a COCOMO 81, COCOMO 2.0 considera en sus etapas 2 y 3 el ajuste del esfuerzo nominal al considerar un conjunto de cost drivers, cuyo efecto es ponderado obteniéndose un mutliplicador de esfuerzo (Effort multipliers, EM i ) asociado a cada cost driver. PM ajustado = PM nominal * P EM i Los cost drivers considerados varían según la etapa del modelo de COCOMO 2.0 que se utilice. 9

10 Multiplicadores de esfuerzo de Etapa 2. La etapa 2 considera 7 cost drivers apreciables en la tabla 12. En términos globales, cada uno de los cost drivers pertenecientes a la etapa 2 corresponde la agrupación de uno o más cost drivers de la etapa 3: Cost Driver Description Counterpart Combined Post-Architecture (Stage 3) Cost Driver PERS Personnel capability ACAP, PCAP, PCON RCPX Product reliability and RELY, DATA, CPLX, complexity DOCU RUSE Required reuse RUSE PDIF Platform difficulty TIME, STOR, PVOL PREX Personnel experience AEXP, PEXP,LTEX FCIL Facilities TOOL, SITE SCED Schedule SCED Tabla 12. Cost Drivers de la Etapa 2. En el caso de RUSE y de SCED sus respectivos EM son calculados directamente a partir de las tablas 13 y 14. En el caso de los cost drivers restantes se calcula el EM para los cost drivers de la etapa 3 que lo componen y luego se calcula el EM como el promedio de los EM de sus componentes. Por ejemplo, EM PDIF =[EM PDIF + EM PDIF + EM PDIF ]/ 3. Multiplicadores de esfuerzo de Etapa 3. La etapa 3 se compone de 17 cost drivers, cada uno de los cuales es clasificado como Very Low hasta Extra High según la tabla 13. Una vez clasificado el cost driver se obtiene el EM respectivo por medio de la tabla

11 Tabla 13. Clasificación de los cost drivers para la etapa 3. 11

12 12

13 Very Low Low Nominal High Very High Extra High Factores de producto RELY DATA CPLX RUSE DOCU Factores de plataforma TIME STOR PVOL Factores de personal ACAP PCAP AEXP PEXP LTEX PCON Factores del proyecto TOOL SITE SCED Tabla Estimación de tiempo de desarrollo Una vez calculado el esfuerzo ajustado es posible, estimar el tiempo de desarrollo: TDEV= [3,67*(PM x ) (0,28+0,2*(B-1.01)) ]*SCED%/100 Donde TDEV: tiempo de desarrollo desde el establecimiento de la baselinek de requerimientos hasta la aceptación del producto final. PM x : estimación del esfuerzo ajustado sin considerar el cost driver SCED. 3.4 Mantención La aplicación de COCOMO 2.0 a la etapa de mantención asume el término del desarrollo del software y la contabilización de las líneas de código de éste (Tamaño del Código Base). Luego: (Tamaño) M = [(Tamaño del Código Base)*MCF]*MAF Donde (Tamaño) M : estimación del tamaño en KSLOC asociado a la mantención MCF (Maintenance Change Factor): porcentaje de cambios en el código base. Este factor es el equivalente al ACT de mantención en COCOMO 81, salvo por que el MCF puede estar asociado a cualquier período (ACT impone un período de 12 meses). 13

14 MCF= (Tamaño agregado + Tamaño modificado)/tamaño del Código Base MAF (Maintenance Adjustment Factor): factor de ajuste de mantención. MAF= 1+((SU/100)*UNFM) Luego, el esfuerzo asociado a mantención se calcula como: PM M =A*(Tamaño M ) B * P EM i,i=1,..,17 Además, si se conoce el tiempo o el personal de mantención es posible calcular el personal o el tiempo respectivo mediante: PM M= T M* FSP M 14