Estimación para Proyectos Software

Transcripción

1 Nilda M. Pérez Otero Sistemas de Información II Cursada 2011 Facultad de Ingeniería - UNJu Fuentes: Ingeniería del Software. Un Enfoque Práctico 6ta. Ed. - Roger S. Pressmann - Capítulo 23

2 Visión general La planificación de un proyecto software implica estimar cuánto tiempo, esfuerzo, dinero y recursos serán necesarios para contruir un sistema de sw específico. Una vez que se definió el ámbito del proyecto y se dividió el problema en subproblemas, los gestores de proyecto usan datos históricos (como también experiencia personal e intuición) para realizar la estimación. Las estimaciones finales se ajustan teniendo en cuenta los riesgos y la complejidad del proyecto.

3 Objetivos Objetivos Factores de confiabilidad de la estimación Tareas Proveer un marco de trabajo que permita al gestor de proyecto hacer una estimación razonable de recursos, costos y plan de trabajo. Se deben usar escenarios de mejor caso y peor caso para limitar los resultados del proyecto Las estimaciones se deben actualizar a medida que el proyecto progresa.

4 Factores de confiabilidad de la estimación Objetivos Factores de confiabilidad de la estimación Tareas Complejidad del proyecto. Tamaño del proyecto. Grado de incertidumbre estructural. Disponibilidad de información histórica.

5 Tareas Objetivos Factores de confiabilidad de la estimación Tareas 1 Establecer el ámbito del proyecto. 2 Determinar la factibilidad. 3 Analizar los riesgos. 4 Determinar los recursos necesarios: Determinar los recursos humanos necesarios. Definir los recursos sw reusables. Identificar recursos del entorno.

6 Tareas (Cont.) Objetivos Factores de confiabilidad de la estimación Tareas 5 Estimar costo y esfuerzo: Descomponer el problema. Desarrollar dos o más estimaciones. Conciliar las estimaciones. 6 Desarrollar el plan de proyecto: Establecer un conjunto significativo de tareas. Definir una red de tareas. Usar herramientas de planificación para desarrollar un cronograma. Definir mecanismos de seguimiento de la planificación.

7 Ámbito del software Ámbito del software Ámbito y comunicación con el cliente Factibilidad Describe: los datos que se procesan y producen, los parámetros de control, las funciones, el rendimiento, las restricciones, las interfaces externas y la confiabilidad. A menudo las funciones descriptas en el ámbito se refinan con el fin de permitir una mejor estimación.

8 Ámbito y comunicación con el cliente Ámbito del software Ámbito y comunicación con el cliente Factibilidad Determinar los objetivos globales del cliente para el sistema propuesto y algunos beneficios esperados. Determinar las percepciones del cliente con respecto a la naturaleza de una buena solución al problema. Evaluar la eficacia de la reunión con el cliente.

9 Factibilidad Ámbito del software Ámbito y comunicación con el cliente Factibilidad La factibilidad técnica no es una razón suficiente para construir un producto. El producto debe cumplir las necesidades del cliente y no estar disponible como un producto de propósito general.

10 Estimación de recursos Visión General Estimación de recursos humanos: cantidad de personas y capacidades necesarias para completar el proyecto. sw reusables: componentes ya desarrollados, componenentes experimentados, componentes de experiencia parcial, componentes nuevos. de entorno: hw y sw que debe estar disponible para el equipo de sw durante el proceso de desarrollo.

11 Estimación de recursos Visión General Estimación de recursos

12 Opciones Opciones Técnicas de descomposición Conciliación de estimaciones Demorar la estimación hasta avanzado el proyecto. Basar la estimación en proyectos similares ya concluidos. Usar técnicas simples de descomposición para estimar el costo y esfuerzo del proyecto. Usar modelos empíricos para la estimación de costo y esfuerzo. Las herramientas automatizadas pueden ayudar con la descomposición y estimación del proyecto.

13 Técnicas de descomposición Opciones Técnicas de descomposición Conciliación de estimaciones Tamaño del software: de lógica fuzzy, de puntos de función, de componentes estándar, de cambio. Estimación basada en el problema: la estimación basada en LDC se centra en las funciones del sw, mientras que el uso de PF hace énfasis en las características del dominio de información. Estimación basada en el proceso: descomposición basada en las tareas requeridas para completar el marco de proceso sw. Estimación de casos de uso: técnica promisoria pero aun controversial debido a la falta de estandarización de los casos de uso.

14 Conciliación de estimaciones Opciones Técnicas de descomposición Conciliación de estimaciones Causas de los problemas de conciliación: El planificador no entendió adecuadamente o interpretó mal el ámbito del proyecto. El conjunto de datos usados en las técnicas basadas en el problema eran obsoletos o inadecuados para la aplicación.

15 COCOMO II Se derivan de análisis de regresión de datos de proyectos sw pasados con persona-mes estimados como variable dependiente y KLDC o PF como variables independientes. COCOMO (MOdelo COnstructivo de COstos) es un ejemplo de un modelo estático de estimación. La Ecuación del Software es un ejemplo de un modelo dinámico de estimación.

16 COCOMO II COCOMO II Es una jerarquía de modelos de estimación que abarca: Modelo de composición de la aplicación. Modelo de etapa de diseño temprano. Modelo de etapa posterior a la arquitectura.

17 1 Cada escenario de usuario se considera por separado. 2 El escenario se descompone en un conjunto de tareas de ingeniería. 3 Cada tarea se estima por separado: Se puede usar datos históricos, modelos empíricos o experiencia. Se puede estimar el volumen del escenario (LDC, PF, cantidad de casos de uso, etc.)

18 4 Calcular la estimación del escenario completo: Sumar las estimaciones de cada tarea Traducir el volumen estimado en esfuerzo usando datos históricos 5 Se suman los esfuerzos estimados para cada escenario de un incremento para obtener la estimación del incremento.

19 Puede ser más rentable comprar un producto sw determinado que construirlo. El análisis de un árbol de decisión brinda una manera sistemática de tomar una decisión desarrollar-comprar. Como regla, la subcontratación requiere más habilidad en la gestión que el desarrollo interno del mismo producto.