Medición de Productividad de Software

Transcripción

1 Medición de Productividad de Software Una definición tradicional de productividad de software corresponde al número de líneas de código fuente producidas por persona-mes de esfuerzo. Existen muchos problemas con esta definición, partiendo por una definición precisa de lo que es una línea de código: debe incluir comentarios? líneas en blanco? líneas de declaración de datos? cómo tratar múltiples instrucciones por línea, o código reusado? Después debe definirse claramente qué se determina como esfuerzo: esfuerzo de codificación? de análisis? administrativo? Aún cuando estas cantidades pudieran ser definidas con claridad persiste la paradoja que indica que existe mayor productividad cuando se utiliza un lenguaje de bajo nivel, comparado con la utilización de lenguajes de alto nivel. Esta paradoja se explica en parte por la existencia de costos fijos muy importantes que no están relacionados directamente con el esfuerzo de codificación (por ejemplo análisis, diseño, documentación); otra explicación está en que la codificación en lenguajes de alto nivel requiere un número menor de líneas de código que la codificación en lenguajes de bajo nivel. El siguiente ejemplo demuestra la paradoja. Versión Assembler Versión PL/I Actividad Persona-Mes Costo Persona-Mes Costo Diseño Codificación 1 5 $ 5,000 $ 25, $ 5,000 $ 5,000 Testing 2 $ 10,000 1 $ 5,000 1 $ 5,000 1 $ 5,000 Documentación 1 $ 5,000 1 $ 5,000 Administración/Soporte Total 10 $ 50,000 5 $ 25,000 LOC/PM $/LOC 100 $ $ 100 Un ejemplo hipotético concerniente a la productividad Ha habido diversos intentos para evitar los problemas descritos. Algunos han sido convertir el número de líneas de código de alto nivel en un número equivalente de líneas de código de bajo nivel, utilizar número de tokens por persona-mes, o puntos de función por persona-mes. Más allá de los problemas en la definición de productividad, los caminos para mejorarla están asociados a la existencia de mejores herramientas, mejores procesos de desarrollo y mantención, y mejor planificación y control. Dr. Marcello Visconti Z. 1

2 Factores que Afectan la Productividad Los factores principales que afectan la productividad en el desarrollo de software pueden clasificarse en cuatro categorías: factores humanos, factores del proceso, factores del producto y factores computacionales. Algunos de los factores humanos: capacidad individual, años de experiencia, experiencia en el lenguaje, experiencia con problemas similares, experiencia previa con el sistema en uso, tamaño del equipo de trabajo, organización del equipo de trabajo, experiencia del equipo de trabajo en el trabajo conjunto, motivación individual y calidad de la administración, entre otros. Algunos de los factores del proceso: lenguaje de programación, ambiente de trabajo, lenguaje de especificación y/o diseño, estrategia de diseño, estrategia de programación, revisiones de diseño y código, herramientas de testing, herramientas CASE y tiempo disponible, entre otros. Algunos de los factores del producto: tamaño del producto, tamaño de la base de datos, requerimientos de tiempo real, confiabilidad, portabilidad, estructuras de control, estructuras de datos, número de módulos, acoplamiento, requerimientos de memoria, complejidad, cantidad de código reusado, estado de la definición del problema, cantidad de documentación, restricciones de seguridad y tipo de software, entre otros. Algunos de los factores computacionales: tiempos de respuesta, tiempos de turnaround, hardware bajo desarrollo concurrente, volatilidad del software básico del sistema de desarrollo, restricciones de almacenamiento y restricciones de tiempo, entre otros. Criterios para Incluir Factores en un Modelo de Productividad Cuatro son los criterios principales que se identifican como los principales para determinar qué factores incluir en un modelo de productividad: capacidad de ser medido y objetividad, generalidad, significancia e independencia. La capacidad de ser medido y objetividad se refiere a que el factor debe ser cuantificable o rankeable, en forma relativamente independiente de quién es el observador: la medición debe ser algorítmica y objetiva, entregando valores razonablemente próximos para situaciones similares, más allá del momento, el lugar y el observador. Dr. Marcello Visconti Z. 2

3 La generalidad de propósito se refiere al grado de aplicabilidad a la masa de productos de software. En general, un factor no debe ser sólo aplicable a un tipo específico de aplicaciones de software. La significancia implica que un factor sólo debe ser incluido si se ha establecido (mediante métodos estadísticos apropiados) que el mismo tiene un efecto significativo; si el factor sólo tiene un efecto menor, entonces debe ser descartado. La independencia busca definir factores que no estén correlacionados. Por ejemplo, si 4 factores están altamente correlacionados sólo uno de ellos debería incluirse como representante de ellos. Para encontrar estos representantes (o para descartar factores redundantes ) existen técnicas estadísticas específicas. Existen pocos estudios que puedan establecer en forma definitiva los efectos que presentan los factores mencionados anteriormente en la productividad de software. Sin embargo, algunos estudios entregan indicaciones de las magnitudes posibles de estos efectos. Por ejemplo, varios experimentos han mostrado que el efecto de la capacidad individual en la productividad puede ser muy grande, hasta del orden de 26:1 en proyectos pequeños, de una persona. Para proyectos más grandes, que involucran equipos de trabajo, este efecto es menos pronunciado aunque significativo, y puede ser del orden de 2:1 a 4:1. Estudio de Productividad de Walston-Felix Este estudio es probablemente el primer intento sistemático para coleccionar datos de proyectos de software bajo condiciones semi-controladas, y se desarrolló a comienzos de los años setenta, en IBM. Informes detallados de 60 proyectos diferentes fueron recogidos en diversos momentos del desarrollo. Los datos recolectados incluyeron esfuerzos de desarrollo, recursos computacionales, datos de completación de las fases, errores, número de módulos, grado de uso de prácticas modernas de programación, páginas de documentación y lenguajes usados, entre otros. Los programas representaban aplicaciones de distinto tipo, escritas en 28 lenguajes, con tamaños variables entre 4000 LOC y LOC, productividades entre 27 LOC/persona-mes y 1000 LOC/persona-mes, con un promedio de productividad de 300 LOC/persona-mes. Un objetivo de este estudio fue producir un modelo de estimación de esfuerzo basado sólo en tamaño. Dado que los resultados no fueron satisfactorios, Dr. Marcello Visconti Z. 3

4 se estudió el efecto de otros factores. Para ello se identificaron 68 factores y su incidencia en la variación de productividad. Mediante regresión multilineal se redujo el número de factores a las 29 variables que estaban significativamente correlacionadas con la productividad. La siguiente tabla muestra cada una de las 29 variables, escala de ratings usada en cada caso, la productividad media por cada rating, y la variación de productividad. Los 8 factores que manifiestan el mayor impacto en la productividad están identificados mediante un asterisco (*). Es importante recalcar que estos resultados sólo reflejan la situación particular del ambiente bajo estudio. Pregunta o Variable 1 Complejidad de interfaz del cliente 2 Participación del usuario en la definición de requerimientos 3 Cambios del diseño del programa originados por el cliente 4 Experiencia del cliente con el área de aplicación del proyecto 5 Experiencia del personal global y calificaciones 6 Porcentaje de programadores haciendo desarrollo y que participaron en el diseño de especificaciones funcionales 7 Experiencia previa con computadores operacionales 8 Experiencia previa con lenguajes de programación 9 Experiencia previa con aplicaciones de tamaño y complejidad similar o mayor 10 Tasa de tamaño promedio de staff para duración (persona/mes) 11 Hardware bajo desarrollo concurrente 12 Acceso a computador de desarrollo, abierto bajo requerimientos especiales 13 Acceso a computador de desarrollo, cerrado bajo requerimientos especiales Productividad Promedio del Grupo de Respuesta (DSL/PM) (1) (2) (3) < Normal 500 Ninguno 491 Pocos 297 Ninguno 318 Bajo 132 < 25 % 153 Mínimo 146 Mínimo 122 Mínimo 146 < 0,5 305 No % % 303 Normal 295 Algunos 267 Algunos 340 Promedio % 242 Promedio 270 Promedio 225 Promedio 221 0,5-0, % % 251 > Normal 124 Muchos 205 Muchos 196 Muchos 206 Alto 410 > 50 % 391 Extensivo 312 Extensivo 385 Extensivo 410 > 0,9 173 Sí 177 > 25 % 357 > 85 % 170 Cambio de Productivida d ( L) (4) Rango de Productivida d (L max /L min ) (5) 376 4,03* 286 2,40* 101 2,94* 112 1, ,11* 238 2,56* 166 2, ,16* 264 2,81* 132 1, , , ,78 Dr. Marcello Visconti Z. 4

5 14 Entorno de seguridad clasificado para computadores y 25% de programas y datos No Programación estructurada 0-33 % Inspecciones de diseño y 0-33 % código Desarrollo Top-down 0-33 % Uso del equipo de 0-33 % programador jefe Complejidad global de < Promedio desarrollo de código Complejidad de < Promedio procesamiento de la 349 aplicación 21 Complejidad del flujo del < Promedio programa Restricciones globales en Mínimas diseño del programa Restricciones de diseño del programa en almacenamiento principal 24 Restricciones de diseño del programa en el tiempo 25 Código para operaciones de tiempo real o interactivas o ejecutándose bajo fuertes restricciones de tiempo 26 Porcentaje de código para entrega 27 Clasificación del código como aplicación nomatemática y programas formateando I/O 28 Número de clases de ítemes en la base de datos por 1000 LOC 29 Número de páginas de documentación entregada por 1000 LOC entregadas Mínimas 391 Mínimas 303 < 10 % % % % % % % - Promedio 345 Promedio 299 Promedio 286 Promedio 277 Promedio % % % Sí 156 > 66 % 310 > 66 % 339 > 66 % 321 > 66 % 408 > Promedio 185 > Promedio 168 > Promedio 209 Fuertes 166 Fuertes 192 Fuertes 171 > 40 % % % 267 > > , , , , , , , , , , , , , , , ,56* En un intento por utilizar estos resultados con objetivos predictivos se definió un índice de productividad para cada proyecto, I: 29 I = Σ W i X i i=1 donde W i es una ponderación variable definida así: W i = ½ log 10 ΛL i Dr. Marcello Visconti Z. 5

6 y X i se define de la siguiente manera: X i = 1, si el rating indica productividad en aumento 0, si el rating indica productividad nominal -1, si el rating indica productividad en disminución El rango de valores de W i es , y el valor de I puede ser menor que, igual a, o mayor que cero. El modelo de productividad derivado tiene la siguiente forma: log L = a + bi con L = productividad (LOC/persona-mes), a y b coeficientes determinados empíricamente de la base de proyectos, e I es el índice de productividad. Para aplicar este modelo en la estimación de productividad para nuevos proyectos deben seguirse los siguientes pasos: utilizar los valores de W i, a y b determinados en el estudio rankear los 29 factores de productividad para el nuevo proyecto determinar los valores X i s para el nuevo proyecto calcular el índice I para el nuevo proyecto obtener la productividad L para el nuevo proyecto Otros Estudios de Productividad en Desarrollo de Software En 1980 F. Brooks realizó un estudio utilizando los datos del estudio Walston-Felix para determinar el efecto de la estructuración del desarrollo sobre la productividad. Para esto mantuvo fijo el tamaño y varió la complejidad ambiente y la experiencia de los profesionales. Las principales conclusiones arrojaron lo siguiente: cuando el proyecto de desarrollo es no estructurado, la baja productividad se correlaciona con otros factores (como el tamaño, la complejidad, las restricciones, etc.), pero cuando el proyecto de desarrollo es estructurado se superan los efectos negativos de aquellos factores, y la productividad siempre aumenta. Este aumento es mayor para proyectos grandes y/o complejos, lo que es indicativo de la importancia de la estructuración del desarrollo para enfrentar la complejidad. Dr. Marcello Visconti Z. 6

7 En 1984 se desarrolló un estudio en la ITT, para lo cual se analizaron 44 proyectos con tamaños variables entre y LOC, con diversas aplicaciones desarrolladas en distintos lenguajes. Este estudio determinó que los principales factores explicativos de las variaciones de productividad eran los siguientes: las restricciones de recursos y la complejidad explicaban un 16% de la variación de productividad, la participación y experiencia del cliente explicaban un 12%, el tamaño del computador de desarrollo y las prácticas modernas de programación explicaban un 24%, la experiencia del personal un 4%, y la estabilidad de las especificaciones y el desarrollo concurrente de hardware un 9%. En 1981 se dan a conocer los resultados de un estudio desarrollado por Barry Boehm que cristalizó en el ampliamente conocido modelo de estimación de esfuerzo COCOMO. El estudio se desarrolló durante la década del setenta, se basó en 63 proyectos del ámbito militar, con tamaños en el rango a LOC, y 7 lenguajes diferentes. Este estudio determinó 15 factores como los principales determinantes de las variaciones de productividad. Como los tres principales factores se determinaron los siguientes: complejidad del producto, capacidad de los analistas, y capacidad de los programadores. Dr. Marcello Visconti Z. 7

8 Estimación de Esfuerzo de Desarrollo de Software Un problema crítico que enfrentan los administradores de proyectos de software es el de la estimación de esfuerzos y costos. Tanto la sobreestimación como la subestimación de costos es dañina, por lo que la precisión en esta tarea es fundamental. Cuatro categorías de modelos de estimación de esfuerzo y costos se identifican: ### modelos históricos o basados en la experiencia ### modelos estadísticos ### modelos teóricos ### modelos compuestos Para definir la bondad de los modelos es importante considerar los siguientes criterios: validez: produce el modelo estimaciones lo suficientemente próximas al menos en la base de datos de validación? es el modelo aplicable al proyecto en consideración? objetividad: se basan las estimaciones en mediciones y datos obtenidos algorítmicamente? dependen ellas de factores subjetivos que pueden variar significativamente con diferentes personas? facilidad de uso: es fácil obtener los datos necesitados por el modelo? hay mucho costo de overhead para obtenerlos? se encuentra la información requerida disponible tempranamente en el ciclo de vida? robustez: produce un efecto desproporcionado una alteración pequeña en uno o más parámetros de entrada? transportabilidad: es el modelo muy dependiente de datos locales lo que lo hace imposible de ser usado en otros ambientes? Modelos Históricos o Experimentales La mayoría de los modelos que existen hoy día caen en esta categoría. En términos simples, expertos elaboran juicios acerca de esfuerzos de desarrollo requeridos, para lo cual se basan en su propia experiencia con proyectos Dr. Marcello Visconti Z. 8

9 similares, en su intuición, y posiblemente en la información histórica mantenida acerca de proyectos completados. Modelos Estadísticos Este tipo de modelos se basa en análisis estadísticos para determinar parámetros y relaciones entre parámetros que conforman los modelos. Se reconocen modelos lineales y no lineales; algunos de los modelos más importantes descritos en la literatura se muestran a continuación: Ê = 5,2 S 0,91 (Walston-Felix) Ê = 3,5 + 0,73 S 1,16 (Bailey-Basili) Ê = 3,2 S 1,05 (Modo 1 de Boehm) Ê = 3,0 S 1,12 (Modo 2 de Boehm) Ê = 2,8 S 1,20 (Modo 3 de Boehm) Ê = 5,288 S 1,047 (para S 10) (Doty) Modelos Teóricos Estos modelos se basan en teorías de cómo funciona la mente humana durante el proceso de desarrollo de software, y en leyes matemáticas que se asume sigue el proceso de desarrollo de software. Algunos de los modelos más famosos que caen en esta categoría son el modelo de asignación de recursos de Putnam, el modelo de Jensen, el modelo de esfuerzo de Software Science de Halstead. Modelos Compuestos Estos modelos incorporan una combinación de ecuaciones analíticas, ajustes estadísticos de datos, y juicios expertos. Algunos de estos modelos son RCA PRICE S, SOFTCOST, COPMO, pero el más famoso de todos es el modelo COCOMO. A continuación se describen brevemente algunos de los modelos más importantes de los mencionados anteriormente. Estos son el modelo de Putnam, y el modelo COCOMO. Modelo de Putnam Este modelo teórico propuesto en 1978 parte del supuesto básico que la utilización de personal durante el desarrollo y mantención de software sigue una Dr. Marcello Visconti Z. 9

10 curva similar a la distribución probabilística Rayleigh. La siguiente figura muestra dicha distribución. Curva Global Diseño y Codificación Personas y y 1 Tiempo La ecuación siguiente indica la utilización de personal como función del tiempo, donde a es un parámetro que afecta la forma de la curva, y K es el esfuerzo total dedicado durante el ciclo de vida: 2 y(t) = K (1-e -at ) Si T es el momento en que la utilización de personal llega al máximo, y el parámetro a se establece igual a 1/(2T 2 ), T corresponde al tiempo total del proyecto. Haciendo las sustituciones pertinentes se determina que el esfuerzo de desarrollo es aproximadamente un 40% del esfuerzo total, i.e. E = K. Putnam definió la métrica de dificultad D de la siguiente manera: D = K / T 2 y asumió la siguiente relación entre productividad L y dificultad D: Dr. Marcello Visconti Z. 10

11 L = c 1 D β definiendo productividad como tamaño en LOC dividida por esfuerzo de desarrollo: L = S / E Usando regresión lineal determinó que β era igual a -2/3, con lo que encontró las siguientes relaciones: S = L E = c 1 D -2/3 E = c 1 D -2/ K reemplazando D con K/T 2, se obtiene la ecuación principal del modelo: S = C K 1/3 T 4/3 ó K = S 3 / (C 3 T 4 ) donde C es asumida como un factor tecnológico, que refleja el efecto de numerosos otros factores. Putnam propone determinar este valor a partir de datos históricos. El modelo en general ha sido ampliamente debatido y poco aceptado, entre otras cosas por el efecto amplificado que tienen cambios pequeños de algunos parámetros sobre los demás, dada la relación exponencial entre ellos. A modo de ejemplo, basta considerar que una reducción de tiempo de desarrollo T de 5 a 4 años aumenta el esfuerzo 2.4 veces, y una disminución de 5 a 3 años lo aumenta 7.7 veces. El modelo en general es interesante desde una perspectiva histórica y académica, pero la carencia de validación aceptable más allá de la base de datos de validación, la ambigüedad en la determinación de C, el uso de la distribución Rayleigh, entre otras razones lo transforman en muy cuestionado y poco usado. Dr. Marcello Visconti Z. 11

12 Modelo COCOMO El modelo COCOMO (COnstructive COst MOdel) fue propuesto por Barry Boehm en 1981 y es el modelo compuesto más famoso, completo y acuciosamente documentado de todos los modelos para estimación de esfuerzo de desarrollo y mantención de software. El modelo permite estimar tiempo de desarrollo, esfuerzo de desarrollo, con descomposición por fases y actividades, y esfuerzo de mantención anual. El modelo en realidad no es uno solo sino tres, pues se reconocen tres niveles: los modelos Básico, Intermedio, y Detallado. Además el modelo presenta relaciones matemáticas diferentes de acuerdo al modo de desarrollo, según se trate de proyectos simples, medianamente complejos, y complejos (en la terminología de COCOMO: orgánicos, semi-desconectados, e integrados). Las ecuaciones básicas son de la siguiente forma: esfuerzo : E = a i S bi m(x) tiempo : T = c i E di Los valores de a, b, c, y d dependen del nivel y modo de desarrollo, y fueron determinados empíricamente. El valor de m(x) es un multiplicador de ajuste de complejidad no relevante para el nivel Básico del modelo, y dependiente de 15 factores para los niveles intermedio y detallado. Es importante señalar que el modelo COCOMO fue validado utilizando 63 proyectos desarrollados durante los años , todos ellos desarrollados en diversos lenguajes, con tamaños variables entre 2K a 1M LOC, aplicaciones diversas, con tasas de productividad también muy diversas. La determinación de los ratings para los 15 factores de costo que determinan el multiplicador de ajuste de complejidad fue hecha mediante juicio experto. La base de datos utilizada se describe en la siguiente página. En términos generales y considerando la base de datos de validación, el método Básico funciona mal y el método Intermedio bien, pero falta aun la validación fuera de ella. Otros problemas tienen que ver con la gran variabilidad posible del multiplicador de ajuste de complejidad ( hasta 800:1!), el elevado número de parámetros que estimar, y la necesidad de calibración de los parámetros determinados empíricamente. Dr. Marcello Visconti Z. 12

13 A continuación se entregan algunas definiciones, antes de describir de manera más detallada este método. La Base de Datos COCOMO Base de Datos Completa Modos : Tipos : Año de Desarrollo Tipo de Computador Lenguajes de Programación Nº de puntos de datos Rango de Productividad (DSI/MM) Orgánico Semi-desconectado Integrado Negocios Control Máquina-Humano Científico Soporte Sistemas Maxi Midi Mini Micro FORTRAN COBOL Jovial PL/ Pascal Otros HOL Assembler Definiciones y Supuestos de COCOMO KDSI: kilo delivered source instruction, o mil instrucciones fuente entregadas. Excluye explícitamente código no entregado (como test drivers), además de no Dr. Marcello Visconti Z. 13

14 contabilizar los comentarios ni el código reusado sin modificaciones. Incluye las declaraciones de datos, instrucciones JCL, formateos, etc las ecuaciones de esfuerzo y tiempo abarcan desde diseño a test de integración las estimaciones sólo cubren las actividades directamente relacionadas con el desarrollo del proyecto; excluye entrenamiento de los usuarios, instalación, conversión, etc. las estimaciones cubren los cargos directos del proyecto, excluyendo operadores de centros de procesamiento, secretarias, etc una persona-mes es equivalente a 19 días o 152 horas de trabajo el proyecto será bien administrado la especificación de requerimientos no va a cambiar sustancialmente los factores de costo considerados son independientes de la fase, i.e., son comunes para todo el desarrollo (con la excepción de COCOMO detallado) los costos incluyen todos los costos de la fase el proceso de desarrollo sigue el paradigma clásico (modelo en cascada) Modelo COCOMO Básico Las siguientes son las ecuaciones para la estimación del esfuerzo y tiempo de desarrollo correspondientes al modo orgánico, es decir, la forma típica de desarrollo: proyecto de tamaño pequeño o medio, desarrollado en un ambiente familiar y local. esfuerzo : MM = 2.4 (KDSI) 1.05 tiempo : TDEV = 2.5 (MM) 0.38 Ejemplo: Imagine un proyecto cuyo tamaño en LOC se estima en 32000, que será desarrollado por un equipo local de profesionales con bastante experiencia en desarrollos similares; por lo tanto puede ser asumido como proyecto del modo orgánico. Estimaciones: Dr. Marcello Visconti Z. 14

15 esfuerzo: MM = 2.4 (32) 1.05 = 91 personas-mes tiempo: TDEV = 2.5 (91) 0.38 = 14 meses productividad: DSI / 91 MM = 352 DSI/MM dotación promedio: 91 MM/ 14 meses = 6.5 FSP (full-time equivalent software personnel) La siguiente tabla presenta un perfil de estimaciones asociadas al modo orgánico de desarrollo con tamaños variables de los proyectos. Perfiles de Proyectos Globales Tamaño de Producto Esfuerzo [MM] Productividad [DSI/MM] Calendarización [meses] Personal Promedio [FSP] Pequeño: 2 KDSI 5, ,6 1,1 Intermedio: 8 21, ,0 2,7 KDSI Medio: 32 KDSI 91, ,0 6,5 Grande: 128 KDSI 392, ,0 16,0 La tabla siguiente muestra las distribuciones porcentuales de esfuerzo y tiempo de desarrollo por fase del ciclo de vida asociadas a los tamaños de proyectos descritos en la tabla anterior. Fase de Distribución de Esfuerzo y Calendarización: Modo Orgánico FASE Pequeño (2 KDSI) Tamaño del Producto Intermedio Medio (8 KDSI) (32 KDSI) Grande (128 KDSI) Esfuerzo Planes y Requerimientos 6 % 6 % 6 % 6 % Diseño del Producto Programación Diseño Detallado Codificación y Test Unitario Integración y Test TOTAL 100 % 100 % 100 % 100 % Calendarización Planificación y Requerimientos 10 % 11 % 12 % 13 % Diseño del Producto Programación Integración y Test Dr. Marcello Visconti Z. 15

16 TOTAL 100 % 100 % 100 % 100 % Esta tabla puede ser usada para determinar el esfuerzo, tiempo de desarrollo y dotación promedio asociada a una fase en particular. Por ejemplo, imagine en el ejemplo anterior de 32 KDSI se desea estimar los parámetros asociados a la fase de programación. Las estimaciones serían las siguientes: esfuerzo : (0.62) (91 MM) = 56 MM tiempo : (0.55) (14 meses) = 7.7 meses dotación promedio : 56 MM / 7.7 meses = 7.3 FSP La tabla siguiente muestra un perfil de las distribuciones de esfuerzo, tiempo, dotación promedio y productividad, por fase del desarrollo y según tamaño del proyecto. Perfiles de Proyectos Básicos: Modo Orgánico CANTIDAD Pequeño (2 KDSI) Tamaño del Producto Intermedio Medio (8 KDSI) (32 KDSI) Grande (128 KDSI) Total Esfuerzo (MM) 5,0 21, Planes y Requerimientos 0,3 1, Diseño del Producto 0,8 3, Programación 3,4 13, Diseño Detallado 1,3 5, Codificación y Test 2,1 8, Unitario Integración y Test 0,8 4, Calendarización (meses) 4, Planificación y Requerimientos 0,5 0,9 1,7 3,1 Diseño del Producto 0,9 1,5 2,7 4,6 Programación 2,9 4,7 7,7 12,2 Integración y Test 0,8 1,8 3,6 7,2 Personal Promedio (FSP) Planificación y Requerimientos 0,6 1,4 2,9 8 Diseño del Producto 0,9 2,3 5,6 14 Programación 1,2 2,9 7,3 19 Integración y Test 1,0 2,3 5,6 14 Dr. Marcello Visconti Z. 16

17 Promedio de Proyectos (FSP) 1,1 2,7 6,5 16 % de Promedio de Proyectos Planificación y Requerimientos 60 % 55 % 50 % 46 % Diseño del Producto Programación Integración y Test Productividad (DSI/MM) Estimación de Esfuerzo de Mantención La estimación del esfuerzo básico de mantención se hace en términos de una cantidad denominada Tráfico de Cambio Anual o ACT (Annual Change Traffic), que es la fracción de instrucciones fuente del producto que son sometidas a cambios durante un año típico, sea por modificación o adición. La estimación del esfuerzo de mantención anual se hace utilizando la siguiente relación: MM AM = (ACT) MM D FSP M = MM AM / 12 Suponga que en el ejemplo de las DSI se determina que en un año se agregarán 4000 DSI y se modificarán 2400 DSI. Esto determina un ACT = ( ) / = 0.20, lo que significa un esfuerzo de mantención anual MM AM de 0.20 (91 MM) = 18 MM, y una dotación promedio de 18 MM / 12 = 1.5 FSP. Otros Modos de Desarrollo La siguiente tabla muestra las ecuaciones para estimar esfuerzo y tiempo de desarrollo para los tres modos de desarrollo: orgánico, semi-desconectado e integrado. Dr. Marcello Visconti Z. 17

18 Ecuaciones de Esfuerzo y Calendarización de COCOMO Básico Modo Esfuerzo Duración Orgánico MM = 2,4 (KDSI) 1,05 TDEV = 2,5 (MM) 0,38 Semi-Desconectado MM = 3,0 (KDSI) 1,12 TDEV = 2,5 (MM) 0,35 Integrado MM = 3,6 (KDSI) 1,20 TDEV = 2,5 (MM) 0,32 La siguiente tabla muestra un perfil de estimaciones de esfuerzo, tiempo, dotación promedio y productividad para los distintos tamaños standard y según el modo de desarrollo. Estimaciones de COCOMO Básico para Productos de Tamaño Standard Esfuerzo (MM) Pequeño 2 KDSI Intermedio 8 KDSI Medio 32 KDSI Grande 128 KDSI Muy Grande 512 KDSI Orgánico 5,0 21, Semi-Desconectado 6, Integrado 8, Productividad (DSI/MM) Pequeño 2 KDSI Intermedio 8 KDSI Medio 32 KDSI Grande 128 KDSI Muy Grande 512 KDSI Orgánico Semi-Desconectado Integrado Calendarización (Meses) Pequeño 2 KDSI Intermedio 8 KDSI Medio 32 KDSI Grande 128 KDSI Muy Grande 512 KDSI Orgánico 4, Semi-Desconectado 4,8 8, Integrado 4,9 8, Personal Promedio (FSP) Pequeño 2 KDSI Intermedio 8 KDSI Medio 32 KDSI Grande 128 KDSI Muy Grande 512 KDSI Orgánico 1,1 2,7 6,5 16 Semi-Desconectado 1,4 3, Integrado 1,7 5, Una definición precisa de cada modo de desarrollo es bastante difícil. En breve, el modo orgánico se distingue por desarrollos acotados en ambientes altamente familiares y locales. El modo integrado se distingue por una necesidad de operar bajo restricciones muy específicas. El modo semi-desconectado representa un estado intermedio entre los modos orgánico e integrado. Dr. Marcello Visconti Z. 18

19 Características Distinguibles de Modos de Desarrollo de Software Modo Característica Orgánico Semi-Desconectado Integrado Entendimiento organizacional de objetivos Completo Considerable General del producto Experiencia en trabajos con sistemas de Extensivo Considerable Moderado software relacionados Necesidad de conformar software con Básico Considerable Total requerimientos pre-establecidos Necesidad de conformar software con Básico Considerable Total especificaciones externas de interface Desarrollo concurrente de nuevo hardware Algunos Moderado Extensivo asociado y procedimientos operacionales Necesidad de arquitecturas y algoritmos de Mínimo Algunos Considerable procesamiento de datos innovativo Premio a completación temprana Bajo Medio Alto Rango de tamaño de producto < 50 KDSI < 300 KDSI Todos los tamaños Ejemplos Reducción de datos lotes, Modelos científicos, Modelos de Negocios, Compiladores y Sistemas Operativos pequeños, Inventario simple y control de producción La mayoría de los sistemas de procesamiento de transacciones, Nuevos Sistemas Operativos y DBMS, Control de producción de inventarios ambiciosos, Controladores de comandos simples Grandes sistemas de procesamiento de transacciones complejas, Muy Grandes y ambiciosos Sistemas Operativos, Ambiciosos controladores de comandos de aviones La tabla siguiente muestra las principales diferencias en los proyectos asociadas al modo de desarrollo. Dr. Marcello Visconti Z. 19

20 Dr. Marcello Visconti Z. 20

21 Diferencias de Actividad de Proyectos Debido a Modos de Desarrollo de Software Modo INTEGRADO SEMI- DESCONECTADO ORGÁNICO Requerimientos y Diseño del Producto Re-elaboración extensiva para acomodar cambios de especificación Especificación completa, validación de requerimientos e interfaces Nivel intermedio de defectos anteriores Re-elaboración relativamente pequeña para acomodar cambios de especificación Especificación bastante general, validación de requerimientos e interfaces Análisis ocasional, prototipación de elementos de gran trabajo Fase Diseño Detallado Administración de configuración muy formal, control de interfaces Administración de configuración bastante informal, control de interfaces Codificación y Testing de Unidad Re-elaboración extensiva para acomodar cambios de código Re-elaboración moderada para acomodar cambios de código Integración y Test Requerimientos extensivos, testing de interfaces Requerimientos moderados, testing de interfaces La tabla siguiente muestra la distribución porcentual de esfuerzo y tiempo por tamaño del proyecto y por modo de desarrollo. Dr. Marcello Visconti Z. 21

22 Fase de Distribución de Esfuerzo y Calendarización: Todos los Modos Distribución de Esfuerzo Tamaño Modo Fase Pequeño 2 KDSI Intermedio 8 KDSI Medio 32 KDSI Grande 128 KDSI ORGÁNICO Planes y Requerimientos (%) Diseño del Producto Muy Grande 512 KDSI Programación Diseño Detallado Codificación y Test Unitario Integración y Test SEMI-DESCONECTADO Planes y Requerimientos (%) Diseño del Producto Programación Diseño Detallado Codificación y Test Unitario Integración y Test INTEGRADO Planes y Requerimientos (%) Diseño del Producto Programación Diseño Detallado Codificación y Test Unitario Integración y Test Distribución de Calendarización ORGÁNICO Planes y Requerimientos (%) Diseño del Producto Programación Integración y Test Dr. Marcello Visconti Z. 22

23 SEMI-DESCONECTADO Planes y Requerimientos (%) Diseño del Producto Programación Integración y Test INTEGRADO Planes y Requerimientos (%) Diseño del Producto Programación Integración y Test La siguiente tabla muestra un perfil de estimaciones de los parámetros para proyectos de tamaño medio, i.e DSI. Perfil de Proyectos Básicos: Proyectos de Tamaño Medio Modo Orgánico Demi-Desconectado Integrado Cantidad Total de Esfuerzo (MM) Planes y Requerimientos Diseño del Producto Programación Diseño Detallado Código y test unitario Integración y test Total de Calendarización (MM) Planes y Requerimientos 1,7 2,8 4,5 Diseño del Producto 2,7 3,6 4,8 Programación 7,7 6,8 5,6 Integración y test 3,6 3,6 3,6 Personal Promedio (FSP) 6,5 10,4 16,4 Planes y Requerimientos 2,9 3,6 4,0 Diseño del Producto 5,6 6,9 8,8 Programación 7,3 12,5 22,1 Integración y test 5,6 10,0 17,8 Porcentaje de Personal Promedio Planes y Requerimientos Diseño del Producto Programación Integración y test Productividad (DSI/MM) Dr. Marcello Visconti Z. 23

24 Sólo código y test de unidad (DSI/MM) Distribución de Esfuerzo por Actividades El modelo COCOMO asume que en todas las fases se desarrollan las siguientes 8 actvidades: análisis de requerimientos diseño del producto programación planificación del testing verificación y validación Funciones de oficina del proyecto (administración) CM & QA (administración de la configuración y aseguramiento de calidad) Manuales Las tablas (7-1, 7-2, 7-3) muestran la distribución de esfuerzo por actividades para cada modo de desarrollo, variando el tamaño del proyecto. Los tamaños standard utilizados son: S I M L VL : pequeño (2 KDSI) : intermedio (8 KDSI) : medio (32 KDSI) : grande (128 KDSI) : muy grande (512 KDSI) Ejemplo: Asuma que un proyecto es muy grande (very large o de tamaño 512 KDSI) y es desarrollado bajo el modo integrado. Lo que se desea obtener es la dotación promedio por actividad para la fase de diseño del producto. Utilizando las ecuaciones apropiadas u observando la tabla de estimaciones según modo y tamaño, se determina un esfuerzo estimado de 6420 MM y 41 meses de tiempo de desarrollo. Dr. Marcello Visconti Z. 24

25 Utilizando la tabla de distribución porcentual de esfuerzo y tiempo por fases para el modo integrado se determinan las siguientes estimaciones para el esfuerzo, el tiempo de desarrollo y la dotación promedio: esfuerzo de la fase de diseño del producto: (0.18) 6420 = 1156 MM tiempo de desarrollo de la fase de diseño del producto: (0.38) 41 meses = 15.6 meses dotación promedio para la fase de diseño del producto: 1156 MM / 15.6 meses = 74 FSP Utilizando la tabla de distribución por actividad para el modo integrado se determina la siguiente distribución de dotación: Análisis de requerimientos (10 %) : 7 FSP Diseño del producto (42 %) : 31 FSP Programación (14 %) : 10 FSP Planificación del testing (8 %) : 6 FSP Verificación y validación (10 %) : 7 FSP Funciones de oficina del proyecto (administración) (7 %) : 5 FSP Administración de la configuración y aseguramiento de calidad (2 %) : 2 FSP Manuales (7 %) : 5 FSP Limitaciones de COCOMO Básico La mayor limitación de COCOMO básico está en la no consideración de otros factores además del tamaño en líneas de código. Factores asociados al producto, al proyecto, al personal y al ambiente computacional son incorporados en el siguiente nivel del modelo: COCOMO intermedio. Modelo COCOMO Intermedio El modelo COCOMO intermedio ha manifestado un mejor comportamiento respecto de la base de datos de validación que el modelo COCOMO básico. Mientras el modelo básico presenta estimaciones con un error menor al 30% el 29% de las veces, dichas estimaciones presentan un error menor al 100% solo el 60% de las veces. El modelo intermedio por su parte presenta estimaciones con un error menor al 20% el 68% por ciento de las veces. Dr. Marcello Visconti Z. 25

26 Además de las líneas de código, el modelo intermedio considera 15 factores de costo (cost drivers) que son los siguientes: Atributos del producto: û ### RELY : confiabilidad requerida û ### DATA : tamaño de la base de datos û ### CPLX : complejidad del producto Atributos del computador: û ### TIME : restricciones de tiempo de ejecución û ### STOR : restricciones del almacenamiento principal û ### VIRT : volatilidad de la máquina virtual û ### TURN : tiempo de turnaround Atributos del personal: û ### ACAP : capacidad de los analistas û ### AEXP : experiencia en la aplicación û ### PCAP : capacidad de los programadores û ### VEXP : experiencia en la máquina virtual û ### LEXP : experiencia en el lenguaje de programación Atributos del proyecto: û ### MODP : prácticas modernas de programación û ### TOOL : uso de herramientas de software û ### SCED : tiempo de desarrollo requerido Las siguientes son las ecuaciones del modelo COCOMO intermedio para determinar esfuerzos nominales de desarrollo (es decir, antes de ajustar la estimación considerando los 15 factores de costo): Ecuaciones de Estimación de Esfuerzo Nominal de COCOMO Intermedio Modo de Desarrollo Ecuación de Esfuerzo Nominal Orgánico (MM) NOM = 3,2 (KDSI) 1,05 Semi-Desconectado (MM) NOM = 3,0 (KDSI) 1,12 Dr. Marcello Visconti Z. 26

27 Integrado (MM) NOM = 2,8 (KDSI) 1,20 La siguiente tabla muestra los factores de multiplicación asociados a los diversos ratings de cada una de los 15 factores de costo. Controladores de Costos Múltiples Esfuerzos de Desarrollo de Software Muy Bajo Bajo Rating Nomi nal Atributos del Producto RELY Requerimientos de confiabilidad del Sw,75,88 1,00 1,15 1,40 DATA Tamaño de base de datos,94 1,00 1,08 1,16 CPLX Complejidad del Producto,70,85 1,00 1,15 1,30 1,65 Atributos del Computador TIME Restricciones del tiempo de ejecución 1,00 1,11 1,30 1,66 STOR Restricciones de Almacenamiento Principal 1,00 1,06 1,21 1,56 VIRT Volatilidad de la máquina virtual,87 1,00 1,15 1,30 TURN Tiempo de turnaround del computador,87 1,00 1,07 1,15 Atributos del Personal ACAP Capacidad del analista 1,46 1,19 1,00,86,71 AEXP Experiencia en aplicaciones 1,29 1,13 1,00,91,82 PCAP Capacidad de programadores 1,42 1,17 1,00,86,70 VEXP Experiencia en máquinas virtuales 1,21 1,10 1,00,90 LEXP Experiencia en el lenguaje de programación 1,14 1,07 1,00,95 Alto Muy Alto Atributos del Proyecto MODP Uso de prácticas modernas de programación 1,24 1,10 1,00,91,82 TOOL Uso de herramientas de software 1,24 1,10 1,00,91,83 SCED Calendarización requerida del desarrollo 1,23 1,08 1,00 1,04 1,10 Extra Alto La tabla 8-3, 8-4 entregan guías para determinar el rating apropiado para cada factor de costo en una situación específica. Ejemplo: Considere un proyecto de 10 KDSI, modo integrado. Utilizando las ecuación apropiada se determina el esfuerzo nominal: esfuerzo nominal: 2,8 (10) 1,20 = 44 MM La siguiente tabla especifica la situación, rating y factor multiplicador para cada uno de los 15 factores de costo. Dr. Marcello Visconti Z. 27

28 Rating de Controladores de Costos: Sofware de Comunicaciones de Microprocesador Controlador de Costos Situación Rating Multiplicador de Esfuerzo RELY Uso local de sistema. Nominal 1,00 Poblemas de recuperación poco serios DATA 20,000 bytes Bajo 0,94 CPLX Procesamiento de Muy Alto 1,30 comunicaciones TIME Puede usarse 70% del Alto 1,11 tiempo disponible STOR 45K de 64K de Alto 1,06 almacenamiento (70%) VIRT Basado en Hw de Nominal 1,00 microprocesadores comerciales TURN Tiempo turnaround Nominal 1,00 promedio de 2 horas ACAP Buen analista senior Alto 0,86 AEXP Tres años Nominal 1,00 PCAP Buen programador senior Alto 0,86 VEXP Seis meses Bajo 1,10 LEXP Doce meses Nominal 1,00 MODP Mejores técnicas en uso Alto 0,91 después de un año TOOL En nivel de herramientas Bajo 1,10 de minicomputadores básicos SCED Nueve meses Nominal 1,00 Factor de Ajuste de Esfuerzo 1,17 (producto de multiplicadores de esfuerzo) Utilizando el factor de ajuste EAF (effort adjustment factor), que es 1.17, se obtiene la estimación del esfuerzo: esfuerzo : (44 MM) 1,17 = 51 MM Asumiendo un costo promedio de US$6000 por persona-mes, se obtiene un costo total de US$ Esto es indicativo de que los costos podrían alterarse contratando a personal menos preparado y más barato, o modificando el hardware usado. Este modelo permite analizar si la alteración es positiva o negativa. Alteración 1: Dr. Marcello Visconti Z. 28

29 Se contrata personal menos capacitado y a un costo de US$5000 por mes. De esta manera el rating asociado a los factores de costo ACAP y PCAP baja de alto (high) a nominal. Este cambio en los ratings determina un nuevo factor de ajuste EAF de 1,58 (en lugar de 1,17). Por lo tanto, el esfuerzo ahora es (44 MM) 1,58 = 70 MM, en lugar de 51 MM. Los nuevos costos son ahora: 70 MM (US$5000) = US$ Por lo tanto, el supuesto ahorro se transforma en pérdida. Alteración 2: Se compra más memoria principal, pasando de 64K a 96K. El costo de la memoria adicional es US$ Esto cambia la restricción asociada al factor STOR desde 70% a 47%, lo que modifica el rating desde alto (high) a nominal. El nuevo factor de ajuste EAF es ahora 1,10, por lo que el esfuerzo se estima ahora en (44 MM) 1,10 = 48 MM, con un costo modificado de 48 MM (US$6000) = US$ más US$ del valor de la memoria agregada, lo que da un total de US$ y un ahorro neto de US$8000. Alteración 3: Ahora aparece un nuevo microprocesador que entrega la misma performance del procesador actual, pero que cuesta US$ menos que el actualmente en uso. Sin embargo, este nuevo microprocesador tiene solo un mínimo de soporte de herramientas, ya que sus compiladores, assemblers, etc. son primitivos y no confiables, además de no contar con las ayudas de diagnóstico y mantención que tiene el procesador actualmente en uso. Como resultado de esto, el rating asociado a TOOL es ahora muy bajo (very low) y no bajo (low). El factor de ajuste es ahora 1,32; el esfuerzo se estima ahora en (44 MM) 1,32 = 58 MM, con un costo de 58 MM (US$6000) = US$ menos US$ del ahorro por el nuevo microprocesador, lo que da un total de US$ con una pérdida neta de US$ El modelo COCOMO intermedio permite también estimar el esfuerzo anual de mantención utilizando un procedimiento similar al que utiliza el modelo COCOMO básico para determinar el esfuerzo de mantención nominal. La ecuación es la siguiente: MM NAM = (ACT) MM D Posteriormente se determina el factor de ajuste de esfuerzo de mantención EAF M, para lo cual no se considera el factor SCED (tiempo de desarrollo es irrelevante en la mantención), y los factores RELY y MODP utilizan multiplicadores distintos asociados a los ratings. Ver tablas 8-7, 8-8. Dr. Marcello Visconti Z. 29

30 Finalmente, se determina el esfuerzo de mantención tal como se hace en el modelo COCOMO básico. Las ecuaciones son: MM AM = (EAF) MM NAM FSP M = MM AM / 12 Consideraciones Finales sobre COCOMO El modelo COCOMO detallado es similar al modelo intermedio, pero con una determinación de ratings de los factores de costo y factores de ajuste para cada fase del desarrollo en lugar de un solo rating y factor de ajuste. En general, el esfuerzo extra requerido en la versión detallada no se justifica dada la similitud de los resultados entre ambos. El modelo COCOMO en sus versiones intermedia y detallada incluye 16 factores: líneas de código y los 15 factores de costo. Algunos factores no incluidos son: tipo de aplicación, nivel del lenguaje, volatilidad de los requerimientos, continuidad del personal, calidad de la administración, calidad de la interfaz con el usuario/cliente, calidad de la documentación, seguridad, privacidad, entre otros. Previo a la utilización del modelo COCOMO es importante calibrar sus parámetros, es decir ajustarlos a la nueva situación. Esta calibración puede incluir el ajuste de valores de sus parámetros, la inclusión nuevos factores de costo, o la exclusión de otros. Dr. Marcello Visconti Z. 30