Ingeniería de Software Avanzada

Universidad Técnica Federico Santa María Departamento de Informática Ingeniería de Software Avanzada Dr. Marcello Visconti Z. Productividad y estimación de esfuerzo Productividad de software Estimación de esfuerzo - importancia y categorías de modelos Estimación de esfuerzo - modelo de Putnam Estimación de esfuerzo - modelo COCOMO Page 1

Productividad de software Cita clásica si se incorpora más gente a un proyecto que ya está atrasado, éste se atrasará aun más (Brooks, 1975) Productividad de software En general, Output/Input Output? LOC? tokens? FP? OO? Input? esfuerzo? $? Productividad? LOC/$, LOC/MM, PF/MM, PF/$? Page 2

Rangos de productividad en PF/MM Tamaños Seleccionados Tasas de Productividad PF/MM 100 PF 1000 PF 10000 PF > 100 1.0% 0.01% 0.0% 75 a 100 3.0% 0.1% 0.0% 50 a 75 7.0% 1.0% 0.0% 25 a 50 15.0% 5.0% 0.1% 15 a 25 40.0% 10.0% 1.4% 5 a 15 25.0% 50.0% 13.5% 1 a 5 10.0% 30.0% 70.0% <1 4.0% 4.0% 15.0% Productividad de software No es fácil de definir Pero es relativamente fácil mejorarla > disminución de esfuerzo - mayores competencias, mejores herramientas, métodos, estructuras de organización, planificación y control mejorar proceso Page 3

Productividad de software Factores que afectan la productividad humanos proceso producto otros (hardware?) Productividad de software Modelos de productividad - criterios para incluir factores > objetividad > generalidad > significancia > independencia Page 4

Productividad de software Estudios de productividad > Walston- Félix > Brooks > ITT > Boehm -- Modelo COCOMO Estudio de Walston-Félix Primer estudio, comienzos de los 70 s Sesenta (60) proyectos, múltiples datos recolectados Varios lenguajes, tamaños, productividades Modelo de estimación: 68 factores, luego 29 Page 5

Estudio de Walston-Felix Response Group Mean Productivity Productivity Productivity (DSL/PM) Change Range Question or Variable (1) (2) (3) (4) (5) 1 Customer interface complexity <Normal Normal >Normal 500 295 124 376 4,03* 2 User participation in the None Some Much definitions of requirements 491 267 205 286 2,40* 3 Customer originated Few Many program design changes 297 196 101 2,94* 4 Customer experience with None Some Much the application area of the project 318 340 206 112 1,65 5 Overall personnel Low Average High experience and qualifications 132 257 410 278 3,11* 6 Percentaje of programmers <25% 25-50% >50% doing development who 153 242 391 238 2,56* participated in design of funcional specifications 7 Previous experience with Minimal Average Extensive operational computer 146 270 312 166 2,14 8 Previous experience with Minimal Average Extensive programming languages 122 225 385 263 3,16* 9 Previous experience with Minimal Average Extensive application of similar or 146 221 410 264 2,81* greater size and complexity Estudio de Walston-Felix Response Group Mean Productivity Productivity Productivity 10 Ratio of average staff size to <0.5 0.5-0.9 >0.9 duration (people/month) 305 310 173 132 1,76 11 Hardware under No Yes concurrent development 297 177 120 1,68 12 Development computer 0% 1-25% >25% access, open under special request 226 274 357 131 1,58 13 Development computer 0-10% 11-85% >85% access, closed 303 251 170 133 1,78 14 Classified security environment No Yes for computer and 25% of programs 289 156 133 1,85 and data 15 Structured programming 0-33% 34-66% >66% 169-310 141 1,83 16 Design and code inspections 0-33% 34-66% >66% 220 300 339 119 1,54 17 Top-Down development 0-33% 34-66% >66% 196 237 321 125 1,64 18 Chief programmer team usage 0-33% 34-66% >66% 219-408 189 1,86 19 Overall complexity of code <Average >Average developed 314 185 129 1,7 20 Complexity of application <Average Average >Average (DSL/PM) Change Range Question or Variable (1) (2) (3) (4) (5) processing 349 345 168 181 2,08 Page 6

Estudio de Walston-Felix Response Group Mean Productivity Productivity Productivity (DSL/PM) Change Range Question or Variable (1) (2) (3) (4) (5) 21 Complexity of program flow <Average Average >Average 289 299 209 80 1,43 22 Overall constraints on program Minimal Average Severe design 293 286 166 127 1,77 23 Program design constraints on Minimal Average Severe main storage 391 277 192 198 2,04 24 Program design constraints Minimal Average Severe on timing 303 317 171 132 1,85 25 Code for real-time or interactive <10% 10-40% >40% operation or executing under 279 337 203 76 1,66 severe time constraint 26 Percentage of code for 0-90% 91-99% 100% delivery 159 327 265 106 2,06 27 Code classified as 0-33% 34-66% 67-100% nonmathematical application 188 311 267 79 1,65 and I/O formatting programs 28 Number of classes of ítems in the 0-15 16-80 >80 data base per 1000 lines of code 334 243 193 141 1,73 29 Number of pages delivered 0-32 33-88 >88 documentation per 1000 lines 320 252 195 125 2,56* of delivered code Estimación de esfuerzo Importancia de estimar correctamente > subestimación de esfuerzo: pérdida económica > sobrestimación de esfuerzo: pérdida de competitividad Combinación de modelos, datos históricos, experiencia y sentido común Page 7

Estimación de esfuerzo Enfoques de estimación opinión experta analogías descomposición modelos matemáticos Estimación de esfuerzo Criterios de bondad de los modelos > validez > objetividad > facilidad de uso > robustez > transportabilidad Page 8

Estimación de esfuerzo Categorías de modelos > históricos > estadísticos > teóricos > compuestos Estimación de esfuerzo Modelos históricos o experimentales > mayoría de los modelos utilizados, expertos elaboran juicios basados en experiencia, intuición, información histórica Page 9

Estimación de esfuerzo Modelos estadísticos > se basa en análisis estadísticos para determinar parámetros y relaciones entre parámetros, i.e. producir ecuaciones matemáticas Estimación de esfuerzo Modelos teóricos > se basan en teorías del funcionamiento de la mente humana durante el desarrollo de software y de supuestas leyes matemáticas que sigue el proceso de desarrollo de software > ejemplo: Putnam Page 10

Estimación de esfuerzo Modelos compuestos > incorporan una combinación de ecuaciones analíticas, ajustes estadísticos, y juicios expertos > ejemplo: COCOMO Modelo de Putnam Supuesto básico: utilización de personal durante el desarrollo sigue una curva similar a la distribución Rayleigh Page 11

Modelo de Putnam Curva Global Diseño y Codificación Personas y y1 Tiempo Modelo de Putnam Parámetros y ecuaciones Ecuación básica K = S 3 / (C 3 T 4 ) C : factor tecnológico Problemas: determinación de C, amplificación de efectos, distribución Rayleigh Page 12

Modelo de Putnam Ecuación principal del modelo muestra la no linealidad existente entre el tiempo y esfuerzo Modelo cuestionado y poco utilizado Modelo COCOMO Barry Boehm, 1981 Estima esfuerzos y tiempos, por fases y actividades Importancia: modelo compuesto más famoso y mejor documentado Tres (3) niveles, 3 modos de desarrollo determinan conjunto de ecuaciones básicas Modelo básico: basado en KLOC Modelo intermedio: basado en KLOC + 15 factores de ajuste de esfuerzo - RELY, DATA, CPLX, TIME, STOR, VIRT, TURN, ACAP, AEXP, PCAP, VEXP, LEXP, MODP, TOOL, SCED Modelo detallado: similar al intermedio pero diferenciado por fase Problemas de validación (63 proyectos, 1964-1979), variabilidad, parámetros a estimar y necesidad de calibración Versión 2.0, liberada Septiembre 1997 (83 proyectos) Page 13

Causas de inexactitud de estimación - top 5 Cambios frecuentes en los requerimientos Tareas omitidas Usuarios no comprenden cabalmente sus requerimientos Mala comunicación usuario - analista Pobre o imprecisa definición del problema Una metodología de estimación Entrada: definición del problema Paso 1: estimar tamaño (FP) Paso 2: transformar tamaño (FP a KLOC) Paso 3: estimar tiempo y esfuerzo (COCOMO) Paso 4: distribuir tiempo y esfuerzo (COCOMO) Paso 5: normalizar a tiempo calendario (ESTERLING) Salida: calendario, costos Page 14

Modelo COCOMO KDSI: kilo delivered source instructions Rango básico de estimación: desde Diseño del producto hasta Pruebas e integración Sólo actividades y cargos directos Persona-mes: 19 días, 152 horas Buena administración Requerimientos no cambian Modelo de desarrollo clásico o en cascada Modelo COCOMO básico Ecuaciones básicas modo orgánico esfuerzo: MM = 2.4 (KDSI) 1.05 tiempo: TDEV = 2.5 (MM) 0.38 dotación promedio: FSP = MM / TDEV productividad: DSI/MM Perfiles de Proyectos Globales Tamaño de Producto Pequeño: 2 KDSI Intermedio: 8 KDSI Medio: 32 KDSI Grande: 128 KDSI Esfuerzo [MM] Productividad [DSI/MM] Calendarización [meses] Personal Promedio [FSP] 5,0 400 4,6 1,1 21,3 376 8,0 2,7 91,0 352 14,0 6,5 392,0 327 24,0 16,0 Page 15

Modelo COCOMO básico Fase de Distribución de Esfuerzo y Calendarización: Modo Orgánico FASE Esfuerzo Planes y Requerimientos Pequeño (2 KDSI) Tamaño del Producto Intermedio Medio (8 KDSI) (32 KDSI) Grande (128 KDSI) 6 % 6 % 6 % 6 % Diseño del Producto 16 16 16 16 Programación 68 65 62 59 Diseño Detallado 26 25 24 23 Codificación y Test 42 40 38 36 Unitario Integración y Test 16 19 22 25 TOTAL 100 % 100 % 100 % 100 % Calendarización Planificación y Requerimientos 10 % 11 % 12 % 13 % Diseño del Producto 19 19 19 19 Programación 63 59 55 51 Integración y Test 18 22 26 30 TOTAL 100 % 100 % 100 % 100 % Modelo COCOMO básico Esfuerzo de mantención anual ACT: annual change traffic (%) MM AM = ACT * MM, FSP AM = MM AM /12 Otros modos de desarrollo modo semidesconectado» MM = 3.0 (KDSI) 1.12» TDEV = 2.5 (MM) 0.35 modo embebido» MM = 3.6 (KDSI) 1.20» TDEV = 2.5 (MM) 0.32 Page 16

Modelo COCOMO básico Características Distinguibles de Modos de Desarrollo de Software Modo Característica Orgánico Semi-Desconectado Integrado Entendimiento organizacional de Completo Considerable General objetivos 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 Algunos Moderado Extensivo hardware asociado y procedimientos operacionales Necesidad de arquitecturas y algoritmos Mínimo Algunos Considerable de 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 Modelo COCOMO básico Ocho actividades en cada fase análisis de requerimientos diseño del producto programación planificación del testing verificación y validación administración (project office) CM & QA documentación (manuals) Page 17

Modelo COCOMO básico Distribución por actividad (modo embebido) Plans and Integration Phase Requirements Product Design Programming and Test Development Maintenance Product Size S I M L VL S I M L VL S I M L VL S I M L VL S I M L VL S I M L VL Overall Phase % 8 8 8 8 8 18 18 18 18 18 60 57 54 51 48 22 25 28 31 34 Activity Percentage Req. Analysis 50 48 46 44 42 10 10 10 10 10 3 3 3 3 3 2 2 2 2 2 4 4 4 4 4 6 6 6 5 5 Product design 12 13 14 15 16 42 42 42 42 42 6 6 6 6 6 4 4 4 4 4 12 12 12 12 12 11 11 11 11 11 Programming 2 4 6 8 10 10 11 12 13 14 55 55 55 55 55 32 36 40 44 48 42 43 43 44 45 38 39 39 40 41 Test planning 2 3 4 5 6 4 5 6 7 8 4 5 6 7 8 3 3 4 4 5 4 4 5 6 7 3 3 4 5 6 V&V 6 7 8 9 10 6 7 8 9 10 8 9 10 11 12 30 28 25 23 20 12 13 14 14 14 12 13 14 14 14 Project office 16 14 12 10 8 15 13 11 9 7 9 8 7 6 5 10 9 8 7 6 10 9 8 7 6 10 9 8 7 6 CM/QA 5 4 4 4 3 4 3 3 3 2 8 7 7 7 6 10 9 9 9 8 8 7 7 7 6 8 7 7 7 6 Manuals 7 7 6 5 5 9 9 8 7 7 7 7 6 5 5 9 9 8 7 7 8 8 7 6 6 12 12 11 11 11 Modelo COCOMO intermedio Mejores (o menos malos) resultados que el modelo básico Quince factores de costo: producto, proceso (proyecto), recursos (computador, personal) Esfuerzo nominal modo orgánico MM NOM = 3.2 (KDSI) 1.05 TDEV = 2.5 (MM) 0.38 modo semidesconectado MM NOM = 3.0 (KDSI) 1.12 TDEV = 2.5 (MM) 0.35 modo embebido MM NOM = 2.8 (KDSI) 1.20 TDEV = 2.5 (MM) 0.32 Page 18

Modelo COCOMO intermedio Múltiples Esfuerzos de Desarrollo de Software Controladores de Costos Rating Muy Bajo Bajo Nominal Alto Muy Alto 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 1,00 1,06 1,21 1,56 Pr incipal 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 pr ogramación 1,14 1,07 1,00,95 Atributos del Proyecto MODP Uso de prácticas modernas de 1,24 1,10 1,00,91,82 programación T OOL Uso de herramientas de software 1,24 1,10 1,00,91,83 S CED Calendarización requerida del desarrollo 1,23 1,08 1,00 1,04 1,10 Extra Alto Modelo COCOMO intermedio Cost Driver Very Low Low Nominal High Very High Extra High Product Attributes RELY Effect: slight Low, easily Moderate, High Financial Risk to human inconvenience recoverable losses recoverablre losses loss life DATA (DB bytes / Prog. DSI) < 10 10 <= (D/P) < 100 100 <= (D/P) < 1000 (D/P) >=1000 CPLX Computer Attributes TIME <=50% use of 70% 85% 95% available execution time STOR <=50% use of 70% 85% 95% available storage VIRT Major change every 12 Major: 6 months Major: 2 months Major: 2 weeks months Minor: 2 weeks Minor: 1 week Minor: 2 days Minor: 1 Month TURN Interactive Average turnaround 4-12 hours >12 hours < 4 hours Personnel attributes ACAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile AEXP <= 4 months 1 year 3 years 6 years 12 years experience PCAP 15th percentile 35th percentile 55th percentile 75th percentile 90th percentile VEXP <= 1 month 4 months 1 year 3 years experience LEXP <= 1 month 4 months 1 year 3 years experience Project attributes MODP No use Beginning use Some use General use Routine use TOOL Basic Basic mini tools Basic midi/maxi Strong maxi Add requirements, microprocessor tools programming, test design, management, tools tools documentation tools SCED 75% of nominal 85% 100% 130% 160% Page 19

Modelo COCOMO intermedio Pasos determinación de esfuerzo nominal determinación de ratings y factores multiplicadores para los 15 cost drivers determinación de factor de ajuste de esfuerzo (effort adjustment factor, eaf), esfuerzo y tiempo» factor: eaf = cd 1 * cd 2 * cd 3 **** cd 15» esfuerzo: MM = MM NOM * eaf» tiempo: TDEV correspondiente Modelo COCOMO intermedio Esfuerzo de mantención anual ACT: annual change traffic (%) eaf AM : solo 14 cost drivers, con tablas propias para RELY y MODP, no se considera SCED MM NOM-AM = ACT * MM NOM MM AM = eaf AM * MM NOM-AM FSP AM = MM AM /12 Otros adaptación de software (EDSI) desarrollo por componentes Page 20

Ideas finales modelo COCOMO Modelo detallado: mayor esfuerzo, resultados similares (no muy buenos..) Muchos factores no incluídos Importancia de calibración Desarrollo de COCOMO 2.0 Modelo COCOMO 2.0 Nuevo escenario cambios en tecnología de software nuevos modelos de ciclo de vida nuevas herramientas reingeniería generadores de aplicaciones enfoques orientados a objetos etc Page 21

Modelo COCOMO 2.0 Características principales mayor variedad de técnicas y tecnologías uso de diferentes modelos de tamaño según se avanza en el desarrollo y se conoce más del sistema se basa en tres etapas principales de un proceso de desarrollo, reconociendo que es imposible conocer tamaño en LOC en forma temprana en el ciclo de vida dado que es nuevo, no hay datos publicados acerca de su precisión Modelo COCOMO 2.0 Etapa 1 normalmente se conoce poco del tamaño probable del producto final, se trabaja con prototipos para resolver aspectos de alto riesgo, por lo que el tamaño se estima en puntos de objeto ( u object points, que capturan el tamaño en términos de generadores de esfuerzo de alto nivel: número de tablas de datos de clientes y de servidores, % de pantallas e informes reusados desde proyectos anteriores) Page 22

Modelo COCOMO 2.0 Etapa 2 se ha decidido continuar con el desarrollo, pero deben explorarse arquitecturas y conceptos de operación alternativos... se conoce más que en la etapa anterior, pero no suficiente como para estimar con precisión... se utilizan puntos de función como estimador de tamaño pues ofrecen una descripción mejor que los puntos de objeto para estimar la funcionalidad capturada en los requerimientos Modelo COCOMO 2.0 Etapa 3 ha comenzado el desarrollo y se cuenta con mucha más información, se estima el tamaño en términos de LOC y se utilizan los cost drivers de una manera similar al modelo original, incorporando modelos de reuso, nuevos cost drivers, nuevos valores de parámetros, tomando en cuenta además la mantención y la degradación del producto (breakage o cambios en los requerimientos en el tiempo) Page 23