Estimación de Proyectos

Transcripción

1 Estimación de Proyectos Actualidad Informática Universidad Nacional de Misiones

2 Estimación para proyectos SW Las fallas al planificar es uno de los mayores errores que se pueden cometer. Se necesita para resolver los problemas tempranamente en los proyectos a menores costos. El proyecto promedio gasta el 80% de su tiempo en re elaboración: corrigiendo errores que se cometieron en etapas tempranas del proyecto. Steve McConnell. Sobrevivir el proyecto de software

3

4 Proceso de Estimación Descripción del ambito del producto Descomponer el problema en sub problemas Estimar empleando datos históricos (métricas de otros proyectos) y la experiencia como guía. La complejidad y el riesgo se consideran antes de realizar una estimación final. Pressman Roger. Ingeniería del Software. Un enfoque práctico.

5 Información Histórica y Requerimientos La característica de una mente instruida es descansar satisfecha con el grado de precisión que la naturaleza del asunto admite, y no buscar la exactitud cuando sólo es posible una aproximación de la verdad. Aristóteles El planificador y, en forma más importante, el cliente deben reconocer que la variabilidad en los requisitos del software significa inestabilidad en costo y programa de trabajo. Pressman R.

6 Tareas para la estimación 1. Establecer el ámbito del proyecto. 2. Determinar la factibilidad. 3. Analizar los riesgos. 4. Definir los recursos requeridos: a) Humanos, b) de Software c) y de Entorno. 5. Estimar costo y esfuerzo: a) descomponer el problema, b) desarrollar dos o más estimaciones empleando tamaño, c) puntos de función, d) tareas de proceso o casos de uso. 6. Desarrollar un plan de proyecto: a) establecer tareas significativas, b) definir una red de tareas, c) realizar cronograma, d) definir mecanismos de seguimiento del programa de trabajo.

7 Estimaciones de tamaño del producto Estimación basada en el problema Estimación basada en el problema LDC: líneas de código PF: propuesta por Albretch, puntos de función, para medir la funcionalidad que entrega un sistema. Estimación basada en proceso Estimación con casos de uso El modelo COCOMO II

8 Lineas de Código LDC o LOC El estimador comienza con un enfoque acotado del El estimador comienza con un enfoque acotado del ámbito del software y partir de ahí empieza descomponer el sw en funciones que puedan estimarse individualmente. Entonces se estiman las LDC o PF (las variables de estimación) para cada función. Entonces se aplican las métricas de la línea base de productividad (LDC/pm) a la variable de estimación apropiada y se deriva el costo de esfuerzo de la función. La estimaciones de función se combinan para producir una estimación global del proyecto completo

9 Estudio de Caso de LDC o LOC Se describe el ámbito del software Expandir las oraciones para ofrecer detalles concretos. Identificar las grandes funciones del SW. Elaborar tabla de estimación. Regla: S=(S opt +4S m +S pes )/6 Función Facilidad de interfaz del usuario Análisis geométrico 2D Análisis geométrico 3D Gestión de BD Presentación gráfica Control de periféricos Módulo de análisis y diseño LDC estimadas Líneas de código estimadas 33200

10 Estudio de Caso de LDC o LOC Por ejemplo para el análisis geométrico 3D se obtiene un optimista de 4600 LDC, más probable 6900 LDC y pesimista 8600 LDC, quedando según la ecuación 6800 LDC. Históricamente el promedio organizacional para este tipo de proyecto es de 620 LDC/pm con una tarifa de 4000 $ por mes. El costo será de 6 $ por LDC. Dando un costo total del proyecto de 199 mil $ con 53 personas mes. ldc ldc/pm 620 cant personas 53,55 tarifa por mes $ 4.000,00 cost de LDC - pm $ 6,00 costo por mes $ 3.720,00 costo total $ ,00

11 Puntos de Función Puntos función (FP): miden la cantidad de funcionalidad de un sistema descripto en una especificación (se pueden computar sin forzar que la especificación siga un modelo o técnica en particular) Primero computamos la cantidad de Puntos Función No Ajustados (UFC) Luego se obtienen los FP multiplicando los UFC por un Factor de Complejidad Técnica (TCF)

12 Ejemplo basado en PF TABLA I - Tabla de total de función sin ajustar (TUFP)

13 Ejemplo basado en PF Inputs externos. Items provistos por el usuario que describen distintos datos orientados a la aplicación (ej nombre de archivos, menús de selección) Outputs externos. Items provistos al usuario que generan datos orientados a la aplicación (ej informes y mensajes) Consultas externas. Inputs interactivos que requieren una respuesta Archivos externos. Interfaces de otros sistemas y leíbles por máquina Archivos internos. Archivos maestros lógicos del sistema

14 Ejemplo basado en PF Diagrama de Contexto de ejemplo

15 Ejemplo basado en PF Calculo PF

16 Ejemplo basado en PF 1. Respaldo y recuperación: El sistema requiere respaldo y recuperación confiable? 2. Comunicaciones de datos: Se requiere comunicación de datos especializada para transferir información a la aplicación u obtenerla de ella? 3. Procesamiento distribuido: Hay funciones distribuidas de procesamiento? 4. Desempeño crítico: el desempeño crítico? 5. Entorno operativo existente: el sistema se ejecutará en un entorno existente que tiene un uso pesado de operaciones? 6. Entrada de datos en línea: el sistema requiere entrada de datos en línea? 7. Transacción de entrada sobre pantallas múltiples: la entrada de datos en línea requiere que la transacción de entrada se construya en varias pantallas u operaciones? 8. ILF actualizado en línea: Los ALI se actualizan en línea? 9. Complejo de valores de dominio de información: las entradas, las salidas, los archivos o las consultas son complejos? 10. Complejo de procesamiento interno: es complejo el procesamiento interno? 11. Código diseñado para reutilización: el código diseñado será reutilizable? 12. Conversión/instalación en diseño: se incluyen la conversión e instalación en el diseño? 13. Instalaciones múltiples: esta diséñado el sistema para instalaciones múltiples en diferentes organizaciones? 14. Aplicación diseñada para cambio: la aplicación esta diseñada para facilitar el cambio y para que el usuario lo utilice facilmente? Factor de Ajuste de Valor Donde Fi = 0 a 5 según el peso del factor: 0 = irrelevante 3 = medio 5 = esencial

17 Ejemplo basado en PF LOC por PF por lenguaje

18 Ejemplo basado en PF PF = conteo total x ( x (F i )) Para el ejemplo PF= 50 x (0.65+(0.01 x 46)) Supóngase que los datos históricos dicen que un PF equivale a 60 LOC y que se producen 12 PF por cada persona-mes. Supóngase también que en proyectos anteriores se han encontrado en promedio tres errores por punto de función durante la revisión de análisis y diseño. Los PF también pueden calcularse a partir de diagramas UML de clases y secuencias. Factor de Ajuste de Valor

19 Ejemplo de Estimación con Casos de Uso Observaciones Se escriben con diferentes grados de abstracción LDC estimadas=nxldc prom +((Sa/Sh-1)+Pa/Ph-1))xLDCajuste Donde N= nro. de CU. LDC prom= promedio historico de LDC por caso de uso para este tipo de subsitema LDC ajuste=representa un ajuste con base en n por ciento de LDC prom donde n se define localmente y representa la diferencia entre este proyecto y los proyectos promedio Sa = escenarios reales por cada caso de uso Sh = escenarios promedios por caso de uso para este tipo de subsitema Pa = páginas reales por caso de uso. Ph = páginas promedio por caso de uso para este tipo de subsistema

20 Ejemplo de Estimación con Casos de Uso Para el SW CAD 1 Subsitema de intrefaz de usuario: 6 CU, no mas de 10 escenarios y long promedio de 6 paginas 2 Subsistema de Ingenieria: (mayor nivel de estructura) 10 CU, no mas de 20 escenarios, 8 pag longitud promedio 3 subsistema de infraestructura: 5 CU, 6 escenarios, 5 pag. Con n = 30 por ciento. CU Esc Pg EscH Pg H LDC H LDC Estimadas ,4 Total LDC estimadas 42610

21 Ejemplo de Estimación con Casos de Uso Si se considera que 620 LDC/pm como productividad promedio en los sistemas de este tipo y una escala salarial de 4000 $ por mes, el costo por línea de código es de aprox. 6 $. En base a los datos históricos el costo total estimado del proyecto es de $ y esfuerzo estimado de 6 personas mes.

22 Modelo COCOMO II Aborda tres áreas: Aborda tres áreas: 1. Modelo de composición de la aplicación: primeras etapas, se utilizan prototipos, interacción software sistema, desempeño y madurez de la tecnología. 2. Modelo de etapa de diseño temprano: se estabilizaron los requisitos y se tiene la arquitectura básica del software. 3. Modelo de etapa posterior a la arquitectura: se emplea durante la construcción del SW>

23 Modelo COCOMO II Las principales capacidades de COCOMO 2.0 son los ajustes a medida dependiendo del software a desarrollar, involucrando en la estimación del coste a los puntos objeto (object points), puntos función (function points) y líneas de código fuente; utilizando modelizaciones no lineales para atender a la reingeniería y reusabilidad del software, En el primer nivel (composición de la aplicación) se utilizan puntos objeto. Para ello se cuentan: pantallas, reportes y componentes. Cada instancia (pantalla o reporte) se clasifica según su complejidad (simple, medio o difícil) Los puntos objetos se determinan al multiplicar el nro de instancias por el factor de ponderación y se suman para tener una cuenta total. Teniendo en cuenta la reutilización este valor se puede ajustar porcentualmente. Tipo de objeto Peso de complejidad Simple Medio Dificil Pantalla Reporte Componente 3GL 10

24 Modelo COCOMO II Para estimar el esfuerzo se calcula la tasa de productividad PROD = NPO/persona-mes Luego se determina la estimación del esfuerzo del proyecto. NOP (Nuevos Puntos Objeto): Tamaño del nuevo software a desarrollar expresado en Puntos Objeto y se calcula de la siguiente manera: NOP = OP x (100 - %reuso)/100 OP (Puntos Objeto): Tamaño del software a desarrollar expresado en Puntos Objeto %reuso: Porcentaje de reuso que se espera lograr en el proyecto PROD: Es la productividad promedio determinada a partir del análisis de datos de proyectos en [Banker 1994]

25 Modelo COCOMO II Esfuerzo estimado = NPO/PROD Experiencia / capacidad del desarrollador Madurez / capacidad el entorno TASA DE PRODUCTIVIDAD (PROD) Muy Baja Muy Baja Baja Nominal Alta Muy alta Baja Nominal Alta Muy alta

26 Modelo COCOMO II Si se considera el nivel de arquitectura Esta ecuación calcula el esfuerzo nominal para un proyecto expresado en Meses-persona (PM). El factor de escala B explica el ahorro o gasto relativo de escala. La constante A se le ha asignado un valor de 2,45.

27 Modelo COCOMO II El tamaño de una aplicación se mide en unidades de líneas de código fuente (KSLOC). En Cocomo II puede estimarse también a partir de Puntos de Función sin ajustar convirtiendo a SLOC y luego dividiendo por Si se opta por utilizar directamente el valor del número de líneas de código, el objetivo es medir la cantidad de trabajo intelectual que se emplea en el desarrollo del programa. Si se opta por utilizar los Puntos de Función sin Ajustar (PFSA) para determinar el tamaño del proyecto, éstos deben convertirse en líneas de código fuente en el lenguaje de programación

28 Modelo COCOMO II El exponente B se obtiene mediante los denominados drivers de escala. Cada driver de escala tiene un rango de niveles de valores desde Muy Bajo hasta Extra Alto. Cada nivel de valores tiene un peso FE cuyo valor específico se llama factor de escala. Un factor de escala de un proyecto, FEJ se calcula sumando todos los factores y se usa para determinar el exponente B de escala.

29 Modelo COCOMO II

30

31

32 PRACTICA 1. Suponga que es el gestor de una compañía que construye 1. Suponga que es el gestor de una compañía que construye el sw para un robot casero destinado a cortar el pasto. Describir el ámbito del sw de manera acotada. Establezca sus suposiciones acerca del hw que se requerirá, como alternativa puede sustituir por otro problema robótico que le interese. 2. Haga una descomposición funcional, estime el tamaño de cada función. Determine las LDC. 3. Suponga que su organización produce 450 LDC/pm con una escala salarial de 3000 $ por persona-mes. 4. Estime el esfuerzo y costo para construir el sw, empleando alguna de las técnicas vistas en esta presentación.

33 Bibliografía Pressman R. Ingeniería del Software. Un enfoque práctico. Sexta Pressman R. Ingeniería del Software. Un enfoque práctico. Sexta edición. Norma TTN Ministerio de Planificiación Federal. Inversión Pública y Servicios. Tribunal de Tasación de la Nación. McConnell, S., Software estimation, caps 4 y 5 McConnell, S. Rapid Development [PMBOK] PMI, A Guide to the Project Management Body of Knowledge. (PMBOK Guide), Third Edition, Project Management Institute 2004 Wysocki, R., McGary, R., Effective Project Management, Third Edition, John Wiley & Sons 2003