Ing. Francisco Rodríguez Novoa

1. UNT. INGENIERIA INDUSTRIAL Ingeniería de Software Tema 2 ESTIMACION DE PROYECTOS SOFTWARE Ing. Francisco Rodríguez Novoa

2. Métricas de Software • La medición es fundamental en el desarrollo de cualquier producto. • La medición del software proporciona un mecanismo para la evaluación objetiva. • Las mediciones pueden aplicarse sobre: • Proceso (permitiendo mejorarlo) • Proyecto (ayuda en la estimación, control de calidad y evaluación) • Producto (análisis de calidad de resultados)

3. Métricas de Software • Las mediciones permiten: • caracterizar fijar líneas base para comparar con evaluaciones futuras • evaluar controlar avance, desviaciones, impacto tecnológico, mejoras • predecir planificar y estimar en base a datos históricos, • mejorar la calidad del producto

4. Métricas de Software Medida: proporciona indicación cuantitativa de extensión, cantidad, capacidad o tamaño de los atributos de un proceso, proyecto o producto. Medición: es el acto que determina una medida. Métrica: una medida cuantitativa del grado en que un sistema, componente, o proceso posee un atributo dado. Indicador: métrica o combinación de métricas que proporciona una visión profunda del proceso, del proyecto o del producto.

5. Métricas de Software El ingeniero de software recopila medidas y desarrolla métricas para obtener indicadores Ejemplo: Medida # errores encontrados en la revisión de un módulo Posibles Métricas en base a dicha medida # medio de errores encontrados por cada revisión # medio de errores encontrados por persona-hora en revisiones Un Indicador podría obtenerse del siguiente análisis: Los equipos que aplicaron una determinada metodología de trabajo obtuvieron un 30% menos de errores que aquellos que no la aplicaron. Esto puede ser un indicador que permita al Gerente del Proyecto decidir que todos los equipos utilicen dicha metodología.

6. Métricas del Proceso e Indicadores Los Indicadores del Proceso permiten obtener información sobre la eficacia de un proceso existente. El gestor puede evaluar lo que funciona y lo que no del proceso. Métricas del Proceso • Se recopilan de proyectos anteriores, durante un largo período de tiempo. Permiten lograr indicadores para mejorar los procesos del software. • Son indirectas. Se extraen según resultados provenientes del proceso. • Ejemplos: errores detectados antes de la entrega, defectos detectados e informados por los usuarios finales, productos de trabajo entregados, esfuerzo humano y horas consumidas para obtener un producto de trabajo, ajustes con la planificación

7. Métricas del Proyecto e Indicadores • Los Indicadores de Proyecto permiten: • evaluar el estado del proyecto en curso • seguir la pista de los riesgos potenciales • detectar áreas de problemas antes de que sean críticas • ajustar el flujo de trabajo y las tareas realizadas • evaluar habilidad del equipo p/ controlar la calidad de lo producido

8. Métricas del Proyecto e Indicadores Métricas del Proyecto • Se recopilan de proyectos anteriores. • Permiten estimar esfuerzo, costo y tiempo para el actual proyecto. • Sirven para supervisar y controlar el avance del proyecto. • Gobiernan los ajustes necesarios para evitar riesgos, retrasos y atenuar problemas.

9. Categorías de Mediciones del Software • Medidas Directas Costo y esfuerzo requerido para desarrollar el software, número de líneas de código (LDC) producidas, velocidad de ejecución, tamaño de memoria, defectos informados durante un período. • Medidas Indirectas Funcionalidad, calidad, complejidad, eficiencia, fiabilidad, facilidad de mantenimiento, facilidad de uso. Es necesario normalizar las medidas para crear métricas de software que permitan comparar diferentes proyectos

10. Métricas Orientadas al Tamaño Provienen de normalizar medidas de calidad y/o productividad, considerando el tamaño del software producido. Se definen métricas que permiten comparar diferentes proyectos. Ventajas: Se calculan fácilmente, existen modelos de estimación que usan LDC como entrada y hay mucha documentación. Detractores: el #LDC dependen del lenguaje de programación, perjudican a programas cortos pero bien diseñados, dificulta la planificación porque se deben estimar las LDC mucho antes de que se complete el análisis y diseño

11. Métricas Orientadas a la Función • Albretch, 1979, sugirió los Puntos de Función como una medida de funcionalidad del software. • • La funcionalidad es una medida indirecta, entonces deben usarse medidas directas para conseguirla. • • Para computar métricas c/PF se definen cinco características: • # Entradas de usuario: contar cada entrada de usuario que • proporciona datos a la aplicación. • # Salidas de usuario: contar cada salida que la aplicación proporciona al usuario. (informes, pantallas, mensajes). • # Peticiones de usuario. petición entrada interactiva que produce alguna respuesta del software inmediata como salida interactiva. • # Archivos: contar cada archivo lógico maestro (agrupación lógica de datos). • # Interfaces externas: contar todas las interfaces que se utilizan para transmitir información a otro sistema

12. Puntos de Función Factor de Ponderación: simple, medio o complejo. Valor de complejidad determinado de manera subjetiva por c/ organización.

13. Puntos de Función: Valores de ajuste de complejidad

14. Planificación de Proyectos: Estimación La gestión de proyectos de software comienza con un conjunto de actividades que globalmente se denominan Planificación de Proyectos de Software. Su principal objetivo es proporcionar un marco de trabajo que permita al gestor hacer estimaciones razonables de recursos, costo y tiempos.

15. Planificación de Proyectos Software • Definir el Ambito del software. • Evaluar la funcionalidad, el rendimiento y las restricciones requeridas. • Se realizan entrevistas entre el Ingeniero de SW y el Cliente y se aplican técnicas para facilitar las especificaciones de la aplicación. • Ejemplo: FAST: FacilitatedApplicationSpecificationTechniques, se crean equipos de clientes y desarrolladores para identificar el problema, proponer soluciones, negociar enfoques y especificar un conjunto preliminar de requisitos. • La viabilidad del proyecto se define de acuerdo al ámbito especificado. • ¿Es factible contruir el Sw a partir de éste ámbito? • • Estimar los Recursos requeridos.

16. Estimación de Proyectos Software Opciones p/ realizar estimaciones seguras de costos y esfuerzos: • Dejar la estimación para más adelante (será 100% fiable al terminar el proyecto). No puede ser, son necesarias a priori. • Basarse en proyectos similares ya terminados. Solo si el proyecto actual es muy similar a esfuerzos pasados. • Utilizar técnicas de descomposición. Método viable para la estimación de proyectos de software que utiliza un enfoque “divide y vencerás”. • Desarrollar un modelo empírico de estimación. Pueden usarse como complemento a las técnicas de descomposición. Cada modelo se basa en datos históricos. COCOMO y COCOMO II.

17. Técnicas de Descomposición • Estimación basada en el problema: se usan LDC y PF como medidas básicas para calcular métricas de productividad. Estimación basada en LDC y en Puntos de Función. Se descompone el problema en funciones, se basa en los datos históricos, y estima un valor de tamaño optimista, más probable, y pesimista para cada función. Se calcula el valor esperado (VE) de la variable de estimación como la media ponderada de las estimaciones optimistas, más probables y pesimistas. VE = (Sopt+ 4Sm+ Spes)/6 • Estimación basada en el proceso: Se descompone el proceso en tareas y se estima el esfuerzo (por ej.: persona-mes) que requerirá llevar a cabo cada una de las tareas del proceso en cada función.

18. Modelos Empíricos de Estimación COCOMO (COnstructive COst MOdel) Boehm (81) introduce una jerarquía de modelos: Modelo 1: COCOMO básico, calcula esfuerzo y costo del desarrollo en función del tamaño del programa, expresados en LDC. Modelo 2: COCOMO intermedio, calcula esfuerzo y costo en función del tamaño del programa y de un conjunto de conductores de costo con atributos del producto, del HW, del personal y del proyecto. Modelo 3: COCOMO avanzado, incorpora las características del intermedio + evaluación de los conductores de costo en c/fase del proceso. COCOMO está definido para tres tipos de proyectos: •modo orgánico: proyectos de software pequeños y sencillos. •modo semiacoplado: proyectos de software intermedio en cuanto a tamaño y nivel de complejidad. •modo empotrado: proyectos muy restringidos

19. COCOMO Básico

20. COCOMO Básico Ej. Con modelo orgánico y suponiendo KLDC=33,2. • Calcula la cantidad de personas por mes. E = 2,4 (KLDC)1,05 = 2,4 (33,2) 1,05 = 95 p-m • Calcula la duración del proyecto. D = 2,5 E0,38 = 2,5 (95) 0,38 = 14,10 meses • Calcula número de personas para el proyecto. N = E / D = 95 / 14,10 ~ 7 personas

21. FIN