Estimación Al principio, el coste del software constituía un pequeño porcentaje del coste total de los sistemas informáticos. Hoy el software es el elemento.

Presentación del tema: "Estimación Al principio, el coste del software constituía un pequeño porcentaje del coste total de los sistemas informáticos. Hoy el software es el elemento."— Transcripción de la presentación:

1 Estimación Al principio, el coste del software constituía un pequeño porcentaje del coste total de los sistemas informáticos. Hoy el software es el elemento más caro de la mayoría de los sistemas. Un error en la estimación puede marcar la diferencia entre beneficios y pérdidas. En un proyecto se estiman fundamentalmente tres elementos: Costes Recursos Agendas Estimar no es una ciencia exacta y por tanto implica un asumir riesgos. Los factores que aumentan el riesgo son: La complejidad del proyecto El tamaño del proyecto Estructuración del proyecto Los factores que permiten reducir el riesgo son: Una buena base histórica Experiencia Uso de medidas cuantitativas Es necesario realizar estimaciones con un grado de riesgo aceptable.

2 Diferentes opciones de estimación
Existen varias posibilidades para estimar: Dejar la estimación para más adelante. Utilizar técnicas de descomposición. Desarrollar métodos empíricos. Adquirir una o varias herramientas automáticas de estimación. Desde un punto de vista ideal se deberían aplicar las tres últimas opciones conjuntamente. La técnica de descomposición utiliza un enfoque divide y vencerás, descomponiendo el proyecto en sus funciones y estimando estas. Todos los modelos empíricos se basan en la experiencia (datos históricos) y toman como base: d = f(vi) Donde d es el valor estimado y vi son parámetros independientes. Las herramientas automáticas implementan una o varias técnicas de descomposición o modelo empíricos. Cada una de las opciones viables para la estimación sólo será buena si los datos históricos que se utilizan son buenos.

3 Técnicas de descomposición
Consiste en dividir el problema en subproblemas más pequeños y abordables. Tanto las líneas de código (LDC) como los puntos de función (PF) son datos básicos a partir de los cuales se pueden obtener métricas de productividad. Los datos de LDC y PF se emplean de dos formas en la estimación: Como variables de estimación. Como métricas de base recogidas de anteriores proyectos. 1. A partir de una declaración restringida del ámbito del software, descomponer el software en funciones, que puedan ser estimadas individualmente. 2. Estimar LDC o PF para cada una de las funciones. 3. Aplicar métricas de productividad a la variable de estimación apropiada y derivar el coste y el esfuerzo. 4. Proporcionar tres valores para cada valor a estimar: optimista, más probable y pesimista usando datos históricos. 5. Calcular el valor esperado de LDC o PF como E = ( pesimista + 4 probable + pesimista ) / 6

4 Técnicas de descomposición
6. Calcular los valores estimados a partir del valor esperado de LDC o PF Multiplicar el valor total de la variable de estimación para todas las funciones por la métrica de productividad media correspondiente a la variable de estimación. Si en total se han estimado 310 PF y la productividad media de PF de acuerdo con anteriores proyectos es 5,5 PF/personas-mes, entonces el esfuerzo total del proyecto es 56 personas-mes. Multiplicar el valor de la variable de estimación obtenida para cada función por el valor de productividad compensado, que se basa en el nivel de complejidad percibido par la función. Para funciones de complejidad media se utiliza una métrica de productividad media. Sin embargo, para funciones de complejidad alta o baja se compensa la métrica de productividad hacia abajo o hacia arriba. Si la productividad media fuera 490 LDC/persona-mes, se podría estimar la productividad para una función más compleja que la media en 300 LDC/persona-mes y para la funciones simple en 650 LDC/persona-mes. ¿Serán correctas las estimaciones? No se puede asegurar. Cualquier técnica de estimación tiene que ser comprobada utilizando otro método. Incluso entonces, deberá prevalecer la experiencia y el sentido común.

5 Ejemplo Desarrollo de un paquete de software para una aplicación de diseño asistido por computadora (CAD). Revisando la especificación del sistema, vemos que el software va a ejecutarse en una estación de trabajo a la que estarán conectados varios periféricos gráficos: un ratón, un digitalizador, una pantalla en color de alta resolución y una impresora láser. Con la especificación del sistema, se puede desarrollar una declaración preliminar el ámbito del software: El software de CAD aceptará del ingeniero datos de geometría bi- y tri-dimensional. El ingeniero controlará e interactuará con el sistema CAD a través de una interfaz hombre-máquina. Todos los datos geométricos y cualquier información adicional se mantendrán en una base de datos de CAD. Los módulos de análisis de diseño se desarrollarán de forma que produzcan la salida requerida en una forma que pueda ser mostrada en una gran variedad de dispositivos gráficos. El software estará diseñado para poder controlar e interactuar con dispositivos periféricos tales como un ratón, un digitalizador, una impresora láser y un trazador. Se identifican las siguientes funciones: Interfaz de usuario y facilidades de control (IUFC) Análisis geométrico bidimensional (AG2D) Análisis geométrico tridimensional (AG3D) Gestión de la base de datos (GBD) Facilidad de visualización de gráficos (FVG) Control de periféricos (CP) Módulo de análisis de diseño (MAD)

6 Ejemplo Utilizaremos LDC como variable de estimación.
Siguiendo la técnica de descomposición, se desarrolla la tabla de estimación que se muestra:

7 Estimación del esfuerzo
La estimación del esfuerzo es la técnica más utilizada para calcular el coste de un proyecto de ingeniería del software. En la resolución de cada tarea del proyecto se aplica un número determinado de personas/día, /mes o /año. Se asocia un coste a cada unidad de esfuerzo y se deriva el coste total estimado. Al igual que las técnicas LDC y PF, la estimación de esfuerzo comienza con una delimitación de las funciones del software, obtenidas del ámbito del proyecto. Para cada función debe realizarse una serie de tareas de ingeniería del software (análisis de requisitos, diseño, implementación y pruebas). Se pueden representar las funciones con sus tareas de ingeniería del software asociadas en la tabla:

8 Estimación del esfuerzo
El planificador estima el esfuerzo (p. ej.: en personas(mes) de acometer cada tarea de ingeniería del software de cada función del software. Estos datos constituyen la matriz central de la tabla. Se aplican las tarifas laborales (a cada una de las tareas de ingeniería del software. Lo más normal es que la tarifa laboral sea distinta para cada tarea. El personal senior: análisis de requisitos y en las primeras etapas del diseño. El personal junior: etapas del diseño, implementación y pruebas iniciales. En un último paso, se calculan los costes y el esfuerzo para cada función y cada tarea de ingeniería del software. Si se ha hecho la estimación del esfuerzo independientemente de la estimación LDC o PF ahora tendremos dos estimaciones de coste y de esfuerzo que se pueden compara y unificar. Si ambos conjuntos de estimaciones muestran concordancias razonables, existirá una buena razón para creer que las estimaciones son fiables. Si, por otro lado, los resultados de ambas técnicas de descomposición no tienen mucho en común, deberá realizarse otra investigación y otro análisis.

9 Ejemplo de estimación del esfuerzo
Retomando el software de CAD, con la misma definición de ámbito y de funciones. En la tabla de estimaciones de esfuerzo aparecen las estimaciones de esfuerzo para cada tarea de ingeniería del software de cada función de software CAD. Análisis de requisitos y diseño utilizan 75 personas-mes El coste total estimado es de $ El esfuerzo total estimado es de 153 personas-mes Comparando estos resultados con los obtenidos mediante la técnica de líneas de código, se encuentra una variación en: El coste del 7 por 100 El esfuerzo del 5 por 100

10 No concordancia entre estimaciones
¿Que ocurre cuando la concordancia entre las estimaciones es pobre? Debemos reevaluar la información utilizada para hacer las estimaciones. Muchas divergencias entre estimaciones se deben a esta dos causas: No se entiende adecuadamente el ámbito del proyecto o ha sido malinterpretado por el planificador. Los datos de productividad utilizados en las técnicas LDC o PF son inadecuados, obsoletos o se han aplicado mal.

11 Modelos empíricos de estimación
Utilizan formulas derivadas empíricamente para predecir los datos que se requieren en el paso de planificación del proyecto. Los datos empíricos que soportan la mayoría de modelos se obtienen de una muestra de proyectos limitada. Por esto un mismo modelo de estimación no es adecuado para todas las clases de proyectos de software ni para todos los entornos de desarrollo. Los modelos de recursos consisten en una o varias ecuaciones obtenidas empíricamente que predicen el esfuerzo, la duración del proyecto y otros datos. Basili describe cuatro clases de modelos de recursos: Modelos univariable estáticos Modelos multivariable estáticos Modelos multivariable dinámicos Modelos teóricos

12 Clasificación de los modelos empíricos
Modelos univariable estáticos. Toma la forma: Variable a calcular = C1 ( característica estimada)C2 Variable a calcular: recursos, esfuerzo, duración del proyecto, cantidad de personal, líneas de documentación, etc. Característica estimada: LDC, esfuerzo, etc. C1 y C2: constantes empíricas. Modelos multivariable estáticos. Variable a calcular = C11 E1C12 + C21 E2C Ei es la característica i-ésima del software. Ci1, Ci2 son ctes. empíricas para la característica i-ésima. Modelos multivariable dinámicos. Proyecta los requisitos de recursos como una función del tiempo. Si se obtiene empíricamente el modelo, los recursos se definen en una serie de pasos consecutivos en el tiempo que asignan cierto porcentaje de esfuerzo a cada etapa del proceso de ingeniería del software. Cada paso puede ser subdividido en tareas. El enfoque teórico de la modelización multivariable dinámica incluye una “curva continua de utilización del recurso” como hipótesis y, a partir de ella, obtiene ecuaciones que modelizan el comportamiento del recurso (modelo de estimación de Putnam). Modelos teóricos. Al contrario que los anteriores examina el software desde el punto de vista microscópico, es decir, las características del código fuente (p.e. número de operadores y de operandos).

13 COCOMO. COnstructive COst MOdel
El modelo constructivo de coste (COCOMO) es una jerarquía de modelos de estimación. Modelo 1. El modelo básico es univariable estático que calcula el esfuerzo del desarrollo del software en función del tamaño del programa, expresado en LDC estimadas. Modelo 2. El modelo intermedio calcula el esfuerzo de desarrollo en función del tamaño del programa y de un conjunto de “conductores de coste”, que incluye la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto. Modelo 3. El modelo avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación del impacto de los “conductores de coste” en cada fase (análisis, diseño, etc.) del proceso de ingeniería del software. El modelo COCOMO se debe a Barry Boehm [BOE81, que lo presento en su libro sobre economía del software.

14 COCOMO. Tipo de proyectos
Los modelos anteriores están definidos para tres tipos de proyectos, definidos por Boehm: Modo orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en las aplicaciones, sobre un conjunto de requisitos poco rígidos. Modo semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia deben satisfacer los requisitos poco o medio-rígidos (p.e. Un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos). Modo empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringido (p.e. software de control de navegación para un avión).

15 COCOMO. Modelo básico. Las ecuaciones del modelo básico son las siguientes: E = a (KLDC)b D = c (E)d E es el esfuerzo aplicado en persona-mes. D es el tiempo de desarrollo en meses. KLDC es el número estimado de líneas de código. a, b, c y d se muestran en la siguiente tabla:

16 COCOMO. Modelo Intermedio
El modelo básico se amplia para considerar un conjunto de atributos conductores de coste: 1. Atributos del producto a. Fiabilidad del software requerida. b. Tamaño de la base de datos de la aplicación. c. Complejidad del proyecto. 2. Atributos del hardware a. Restricciones de rendimiento en tiempo de ejecución. b. Restricciones de memoria. c. Volatilidad del entorno de la máquina virtual. d. Tiempo de espera requerido. 3. Atributo del personal a. Capacidad de análisis. b. Capacidad del ingeniero de software. c. Experiencia en aplicaciones. d. Experiencia con la máquina virtual. e. Experiencia con el lenguaje de programación. 4. Atributos del proyecto a. Utilización de herramientas de software. b. Aplicaciones de métodos de ingeniería del software. c. Planificación temporal del desarrollo requerida.

17 COCOMO. Modelo Intermedio
Cada uno de los atributos es valorado de 0 a 6 puntos. De acuerdo con la evaluación se determina un multiplicador de esfuerzo a partir de las tablas calculadas por Boehm. Con el producto de todos los multiplicadores de esfuerzo se obtiene un factor de ajuste del esfuerzo (FAE), que toma valores típicos entre 0,9 y 1,4. La ecuación del modelo COCOMO intermedio es: E = a (KLDC)b FAE E es el esfuerzo en personas-mes. LDC es el número estimado de líneas de código. a y b se obtienen de la tabla: COCOMO es el modelo empírico más completo para la estimación del software publicado hasta la fecha. Deben tenerse en cuenta los propios comentarios de Boehm sobre COCOMO y sobre todos los modelos: Un modelo de estimación de costes del software está bien construido si puede estimar los costes del desarrollo de software en torno al 20 por 100 de los costes reales, y el 70 por 100 del tiempo y ello en su propio terreno.

18 COCOMO. Ejemplo del modelo básico
Aplicando el modelo COCOMO al ejemplo de software CAD. Las LDC estimadas son Coeficientes de la tabla COCOMO básico para el modelo semiacoplado E = 3,0 (33,33)1,12 = 1523 personas-mes D = 2,5 (152)0,35 = 14,5 meses El valor de la duración del proyecto permite al planificador recomendar un número de N personas para el proyecto: N = E / D = 11 personas

19 Putnam Modelo multivariable dinámico que asume una distribución específica del esfuerzo a lo largo de la vida de un proyecto de desarrollo del software. El modelo se ha obtenido a partir de distribuciones de mano de obra en grandes proyectos (30 personas-año o más). Sin embargo, se puede extrapolar a proyectos más pequeños. La distribución del esfuerzo en grandes proyectos de software puede ser caracterizada como se muestra:

20 Putnam Se puede utilizar la curva de Rayleigh-Nordem para obtener una ecuación del software que relaciona el número de líneas de código esperadas con el esfuerzo y el tiempo de desarrollo: L = Ck K1/3 td4/3 Ck es una constante del estado de la tecnología: Ck= 2000 para un entorno de desarrollo pobre. Ck= 8000 para un buen entorno de desarrollo (buena tecnología, adecuada documentación, modo de ejecución interactivo) Ck= para un entorno excelente con herramientas y técnicas automáticas. td = Tiempo de desarrollo en años. Reorganizando la ecuación anterior podemos obtener el esfuerzo K Dadas las potencias de alto orden que aparecen en la ecuación del software, se puede demostrar que, postergando ligeramente la fecha de entrega, se puede obtener un sustancial ahorro en el esfuerzo humano aplicado al proyecto.

21