Estimación de costos y esfuerzos. Calidad en el Desarrollo de Software. Estimación de costos para el software. Planificación de proyectos

Transcripción

1 Estimación de costos y esfuerzos Métricas de procesos de software Depto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur COCOMO otros Segundo Cuatrimestre 2007 de proyectos Estimación de costos para el software la primer componente de un proyecto de ingeniería de software es la planificación del proyecto el primer paso de la planificación es documentar suposiciones, metas y restricciones de proyecto a continuación, el administrador debe desarrollar un plan de actividades, para cumplir los requerimientos dentro de las restricciones dadas dentro de este plan, se debe identificar el modelo de proceso a seguir, asi como los recursos requeridos típicos recursos: número y capacidad del personal, equipo, insumos, tiempo requerimientos incompletos o imprecisos esconden costos ocultos pero aún con requerimientos claro, la estimación es difícil la mejor aproximación es desarrollar incrementalmente los requermientos, revisando estimaciones a medida que se dispone de más información (desarrollo en espiral)

2 Estimación de costos para el software Modelos predictivos de costos de software el costo del software depende de una combinación de factores, como complejidad del problema habilidad del personal diseño del software herramientas disponibles la ingeniería del software, a diferencia de otras ingenierías, depende fuertemente del diseño tradicionalmente, el tamaño del código ha sido usado no como una medida de productividad, sino como entrada para los modelos de estimación de costos entonces la mayoría de los métodos comienza con una predicción del tamaño del código a producir la estimación será más simple y acertada si la organización mantiene una base de datos de proyectos pasados Modelos predictivos de costos de software Modelos predictivos de costos de software otras características comunes de casi todos los modelos es que la predicción total del esfuerzo de producción es PM inicial = c KLOC k es decir, la cantidad de meses-programador es una función de la cantidad de líneas de código, siendo las constantes c y k dependientes del modelo otros factores de ajustes pueden ser tenidos en cuenta para escalar esta estimación inicial producto requerimientos extra de confiabilidad o complejidad inherente del problema computación requerimientos extra de tiempo o almacenamiento en el procesamiento personal por ejemplo, si el personal afectado tiene experiencia en el área proyecto por ejemplo, si se usaran herramientas sofisticadas

3 Factores de ajustes usados en diferentes modelos Factores de ajustes usados en diferentes modelos (cont.) tamaño código fuente código objeto número de rutinas número de elementos de datos documentación número de personal programas tipo complejidad lenguaje reuso confiabilidad requerida requerimientos gráficos computación personal restricciones de tiempo restricciones de almacenamiento configuración del hardware desarrollo concurrente capacidad continuidad experiencia en hardware experiencia en el área de la aplicación experiencia en el lenguaje y las herramientas Factores de ajustes usados en diferentes modelos (cont.) Pasos para derivar en una estimación de costos proyecto herramientas y técnicas interface al usuario definición de requerimientos volatilidad de requerimientos cronograma seguridad acceso a computadoras madurez del software de soporte en general, los siguientes son los pasos básicos para realizar una estimación de costos de un sistema de software propuesto: 1 estimar el tamaño eventual del software, usarlo en la fórmula del modelo para llegar a una estimación inicial 2 revisar la estimación usando los factores de costos, u otros factores de escalas determinados por el modelo 3 aplicar las herramientas del modelo al resultado anterior para determinar esfuerzo total, productividad, distribución de actividades, etc

4 COCOMO COCOMO COCOMO (Constructive Cost Model) es uno de los modelos de costos más conocidos desarrollado en los 70 s por Barry Boehm, actualmente ha evolucionado en originalmente, es un conjunto de tres modelos diferentes con complejidades y nivel de detalle en incremento Desarrollado en la década del 70 por Boehm básico: aplicable cuando se conoce muy poco del proyecto intermedio: aplicable luego de la especificación de requerimientos avanzado: aplicable cuando se termina el diseño todos los modelos utilizan la misma fórmula: donde E = as b F E: esfuerzo en personas mes S: tamaño medido en KSDI (K-delivered source instructions) F : factor de ajuste (igual a 1 en el modelo básico) a,b: se obtienen de tablas del modelo en función del tipo de sistema COCOMO - Clasificación de sistemas COCOMO - modelo básico orgánicos: involucra procesamiento de datos, uso de bases de datos y se focaliza en transacciones y recuperación de datos. Ejemplo: sistema de facturación embebido: contiene software de tiempo real que es una parte integral de un sistema mayor basado en hardware. Ejemplo: control de ascensores semi-embebido: entre orgánico y embebido Ű presenta mayor procesamiento de transacciones. Ejemplo: Monitoreo de una red el modelo básico aplica las siguientes fórmulas y valores a b c d orgánico embebido semi-embebido personas mes: PM = a (KDSI b ) tiempo de desarrollo: TD = c (PM d )

5 COCOMO intermedio COCOMO - factores de ajustes cuando se conoce muy poco del proyecto, se utiliza COCOMO básico con F = 1 cuando se conoce un poco más el lenguaje, herramientas a utilizar se puede aplicar COCOMO intermedio se eligen los factores de ajustes de una tabla que presenta 15 tratan de capturar el impacto del entorno del proyecto en el costo de desarrollo de un análisis estadístico de más de 100 factores que influencian el costo, Boehm retuvo 15 de ellos para COCOMO la importancia de cada factor de ajuste es clasificada en una escala ordinal con seis puntos: Muy Baja, Baja, Nominal, Alta, Muy Alta, Extra Alta 1 atributos del producto 2 atributos del personal 3 atributos del hardware 4 atributos del proyecto COCOMO - atributos del producto COCOMO - atributo RELY RELY garantía de funcionamiento requerida por el software DATA tamaño de la base de datos CPLX complejidad del producto indica las posibles consecuencias para el usuario en el caso que todavía existan defectos en el producto muy baja: el efecto de un fallo del software simplemente trae como consecuencia la inconveniencia de corregir el fallo baja: el efecto de un fallo software es una pérdida fácilmente recuperable para los usuarios nominal: el efecto es una moderada pérdida para los usuarios, pero es una situación de la que se puede salir sin excesiva dificultad alta: el efecto es una gran pérdida financiera o una inconveniencia masiva humana muy alta: el efecto es un pérdida en vidas humanas

6 COCOMO - atributo DATA COCOMO - atributo CPLX indica el tamaño de la base de datos a desarrollar en relación con el tamaño del programa existen cuatro segmentos con la razón , que determinan las puntuaciones de bajo a muy alto el valor se define por el cociente D/P, donde D es tamaño de la base de datos en bytes y P el tamaño del programa en DSI indica la complejidad de cada módulo y se utiliza para determinar la complejidad compuesta del sistema la puntuación puede variar de muy baja si el módulo está compuesto de expresiones matemáticas simples a extra alta para módulos que utilizan muchos recursos de planificación COCOMO - atributos del hardware COCOMO - atributo TIME TIME limitaciones en el porcentaje de uso de la CPU STOR limitaciones en el porcentaje de uso de memoria VIRT volatilidad de la máquina virtual TURN frecuencia de cambio en el modelo de explotación se expresa en el porcentaje de tiempo de ejecución disponible se basa en la presunción de que siempre será más exigente para un programador escribir un programa que tiene una restricción en el tiempo de ejecución es nominal cuando el porcentaje es el 50 %, y extra alta cuando la restricción es del 95 %

7 COCOMO - atributo STOR COCOMO - atributo VIRT captura el esfuerzo de programación para que el programa pueda correr en un volumen menor de almacenamiento principal se basa en la presunción de el esfuerzo de programación se incrementa si el programa tiene que correr en un volumen menor del almacenamiento principal el valor es nominal cuando la reducción del almacenamiento principal es del 50 % a extra alta cuando la reducción es del 95 % refleja los cambios que puede sufrir la máquina virtual (hardware mas software) durante el desarrollo del software refleja la probabilidad de que ocurran los cambios desde baja a muy alta COCOMO - atributo TURN COCOMO - atributos del personal cuantifica el tiempo de respuesta del ordenador desde el punto de vista del programador cuanto mayor sea el tiempo de respuesta, más alto será el esfuerzo humano puede variar desde baja para un sistema interactivo; a muy alta cuando el tiempo medio de respuesta es de más de 12 horas ACAP calificación de los analistas AEXP experiencia del personal en aplicaciones similares PCAP calificación de los programadores VEXP experiencia del personal en la máquina virtual LEXP experiencia en el lenguaje de programación a usar.

8 COCOMO - atributo ACAP COCOMO - atributo AEXP mide la capacidad del grupo de analistas, en términos de habilidad de análisis, eficiencia y capacidad para cooperar estas habilidades tienen un impacto significativo en el esfuerzo humano cuanto más capaz sea el grupo, menos esfuerzo será necesario puede variar desde muy baja a muy alta mide la experiencia del grupo en una aplicación similar la experiencia del grupo tiene una gran influencia en el esfuerzo puede ser muy baja: < 4 meses experiencia media baja: 1 año de experiencia media nominal: 3 años de experiencia media alta: 6 años de experiencia media muy alta: > 12 años, o reimplementación de un subsistema COCOMO - atributo PCAP COCOMO - atributo VEXP mide la capacidad del grupo de programadores, en términos de habilidad de programación, eficiencia y capacidad para cooperar similar al atributo que mide la calificación de analistas, pero en este caso, se mide al grupo de programadores cuanto más capaz sea el grupo, menos esfuerzo será necesario se aplica a los programadores como grupo, pero no a los programadores individuales puede variar desde muy baja a muy alta mide la experiencia de los programadores en la máquina virtual puede ser muy baja: < 1 mes experiencia media baja: 4 meses nominal: 1 año alta: > 3 años

9 COCOMO - atributo LEXP COCOMO - atributos del proyecto mide la experiencia de los programadores en el lenguaje de programación un grupo de programadores con amplia experiencia en un lenguaje determinado programará de una manera mucho más segura, generando un menor número de defectos y de requerimientos humanos puede variar desde muy baja a alta para un grupo de un mes a tres años de experiencia, respectivamente muy baja: < 1 mes experiencia media baja: 4 meses experiencia media nominal: 1 año experiencia media alta: > 3 años MODP uso de prácticas modernas de programación TOOL uso de herramientas de desarrollo de software SCED limitaciones en el cumplimiento de la planificación COCOMO - atributo MODP COCOMO - atributo TOOL indica la utilización de modernas prácticas de programación estas prácticas incluyen, por ejemplo, programación estructurada y desarrollo top-down puede ser muy baja: no se utilizan prácticas modernas de programación (PMP) baja: uso experimental de algunas PMP nominal: experiencia razonable en el uso de algunas PMP alta: experiencia razonable en gran parte de PMP indica el uso de herramientas de software el uso adecuado de herramientas de software es un multiplicador de la productividad la puntuación varía desde muy baja cuando sólo se utilizan herramientas básicas, a muy alta cuando se utilizan herramientas específicas

10 COCOMO - atributo SCED COCOMO - peso de los factores indica el esfuerzo necesario para cumplir con la planificación el tiempo nominal de desarrollo, tal como se define en el modo básico, es el plazo que requiere menor esfuerzo humano cualquier apresuramiento (muy baja) o retraso (muy alta) demandarán más esfuerzo muy baja baja nominal alta muy alta nominal RELY DATA CPLX TIME STOR VIRT TURN COCOMO - peso de los factores (cont.) muy baja baja nominal alta muy alta nominal ACAP AEXP PCAP VEXP LEXP MODP TOOL SCED para los proyectos medios, COCOMO intermedio es coincidente con el modelo debe ser calibrado al propio entorno de desarrollo una vez que se han identificado los módulos del sistema, se puede utilizar o detallado : se aplica la versión intermedia a nivel de componentes y luego se construye una estimación para el proyecto completo

11 COCOMO - fases de desarrollo COCOMO - fase de desarrollo permite estimar los tiempos para cada una de las fases de desarrollo considera cuatro fases: 1 requerimientos/planes 2 diseño del producto 3 codificación 4 prueba/integración es la primera fase del ciclo de desarrollo se analiza el requerimiento, se muestra un Plan de Producto y se genera una especificación completa del producto esta fase consume del 6 % al 8 % del esfuerzo nominal PM puede durar del 10 % al 40 % del tiempo nominal de desarrollo TD estos porcentajes dependen del modo y del tamaño (de 2000 LOC a LOC) COCOMO - fase de diseño COCOMO - fase de codificación es la segunda fase del ciclo de desarrollo COCOMO se preocupa de la determinación de la arquitectura del producto y de las especificaciones de los subsistemas esta fase requiere del 16 % al 18 % del esfuerzo nominal PM puede durar del 19 % al 38 % del tiempo nominal de desarrollo TD COCOMO subdivide esta fase en dos subfases: diseño detallado y prueba del código esta fase requiere del 48 % al 68 % del esfuerzo nominal PM puede durar del 24 % al 64 % del tiempo nominal de desarrollo TD

12 esta fase consiste principalmente en unir las diferentes unidades ya probadas se utiliza del 16 % al 34 % del esfuerzo nominal PM puede durar del 18 % al 34 % del tiempo nominal de desarrollo TD es una actualización de COCOMO para que se adapte a las nuevas tecnologías, enfoques de OO, etc la estimación del proceso en está basado en tres etapas principales de cualquier desarrollo: Etapa Basado en Utiliza 1 prototipos puntos objetos 2 decisiones de arquitectura puntos función 4 diseño detallado KDSI Modelo Curvas de Rayleigh surge en 1978 como solución a un requerimiento de la marina de EEUU para proveer un método para estimar esfuerzo y tiempo fue desarrollado por Putnam y lo llamó modelo se utiliza para proyectos con mas de LOC puede ser ajustado para proyectos mas pequeños asume que el esfuerzo para proyectos de desarrollo de software es distribuido en forma similar a una colección de curvas de Rayleigh, una para cada una de las actividades principales del desarrollo la ecuación relaciona S (líneas de código) con varias variables: un factor tecnológico C; esfuerzo total del proyecto en años-persona K ; y tiempo de entrega t d, en años la relación se expresa como S = CK 1/3 t 4/3 d

13 Curvas de Rayleigh resultan las siguientes curvas, para cada etapa en el proyecto Modelo en la práctica C puede tomar hasta 20 valores distintos, y la equación no puede ser usada hasta que se haya estimado el tamaño del resultado también es necesario acordar los valores C, y suponer K o t d constantes para estimar duración, Putnam introduje otra ecuación D 0 = K /t 3 d D 0 es la constante de aceleración de la fuerza de trabajo. Por ejemplo, 12.3 para software nuevo con muchas GUI, 15 para sistemas stand-alone, y 27 para reimplementación se sistemas existentes. Modelo Problema de modelos existentes usando las dos ecuaciones se puede resolver esfuerzo y duración por ejemplo, K = (S/C) 9/7 D 4/7 0 la ecuación relacionando estos valores permite jugar con el efecto de variar el tiempo de entrega y ver como este incide con el total de esfuerzo requerido para completar el proyecto debido a que la ecuación tiene una potencia cuarta, la asignación de recursos tiene una implicancia fuerte en grandes proyectos según la ecuación reducir un 10 % el tiempo resulta en un 52 % de aumento del esfuerzo total del ciclo de vida hay acuerdo en que el tamaño del producto es factor determinante del esfuerzo requerido para construirlo la mayoría de los modelos sugiere que el esfuerzo requerido es aproximadamente proporcional al tamaño incluyen un ajuste (b... > 1) inverso a la economía de escala, proyectos mas grandes son menos productivos que los mas pequeños el modelo de Putnam concluye que disminuyendo la duración aumenta el esfuerzo, pero aumentando la duración disminuye el esfuerzo

14 Modelos existentes Mejoras a la exactitud de las estimaciones los modelos pueden trabajar bien para los entornos en los cuales fueron derivados, no parece razonable que un modelo simple pueda ser válido universalmente el modelo de Putnam es muy sensible al factor tecnológico, que a su vez no es fácil de obtener la mayoría de los modelos trabajan sobre un conjunto de datos de análisis post hoc los parámetros de input necesarios son muy difíciles de obtener en las primeras etapas del proyecto definición de datos locales: usar medidas de tamaño y esfuerzo que son definidas consistentemente a través de todo el entorno proceso de calibración: asegurar que los valores provistos al modelo son consistentes con los requerimientos y expectativas del modelo reajustar los coeficientes del modelo usando datos de proyectos pasados para reflejar la productividad básica encontrada en el nuevo entorno eliminar, agregar o modificar conductores de costos personalizar el modelo Mejoras a la exactitud de las estimaciones (cont.) Grupo de estimación grupo de estimación independiente: propuesta de De Marco, asegura consistencia entre proyectos, mayor experiencia, monitoreo de la base de datos reducir subjetividad al input: los modelos de estimación locales basados en datos más homogéneos son más exactos que modelos más generales y complejos. Estos modelos locales reducen subjetividad estimación preliminar y re-estimación: la estimación temprana requiere el uso de información incompleta. Se mejora relacionando dos pasos: estimación preliminar y re-estimación cuando se dispone de la información 1 el coordinador le entrega a cada estimador la información relevante 2 el coordinador convoca a una reunión donde se hacen preguntas y se discute aspectos de la estimación 3 cada experto provee una estimación (rango) inicial anónima 4 el coordinador circulariza un resumen de las estimaciones individuales y el promedio

15 Grupo de estimación de costos 5 el coordinador convoca a otra reunión para discutir los resultados 6 los expertos proveen nuevas estimaciones anónimas 7 se repiten pasos 2 a 6 hasta que el grupo decide que el promedio es representativo y satisfactorio Putnam propone: est = (cota_inf + 4 valores_similares + cota s up)/4 DBA COCOMO 2004 COINCOMO 2004 COCOTS 2000 COSYSMO 2002 COSoSIMO 2004 Costing Secure System 2004