Estimación del esfuerzo y costos necesarios para el desarrollo de un proyecto de software

Transcripción

1 Carlos Eduardo Vázquez Estimación del esfuerzo y costos necesarios para el desarrollo de un proyecto de software Objetivos 1. Despertar en el público la conciencia sobre la problemática en la elaboración de estimaciones en el desarrollo de software 2. Presentar el concepto de unidad de producto y de cómo aplicarlo en la medición de software para la planeación y monitoreo de la productividad en su desarrollo 3. Introducir el método de COSMIC para la medición del tamaño funcional y su papel en la generación de unidades de producto a partir de los requerimientos funcionales 1

2 1. La problemática de la estimación Estimar pequeños elementos es fácil Programar una Transacción Probar una Transacción Dificuldad Estimar la realización de una actividad de 12 horas Pequeño! Impacto Cuando se solicita una medición a un desarrollador para entregar un programa probado y brinda una estimación de 12 horas, lo más probable es que esté en lo cierto Esto porque se trata de un programa cuya dificultad de estimación es menor o su impacto de error es pequeño. Un gran elemento como la suma de pequeñas partes Dificultad 1. La problemática de la estimación Impacto La solución para todos los problemas de estimación es descomponer un proyecto en sus partes y hacer las estimaciones en estos mismos modelos Fase 01 Fase 02 Fase 03 Fase 04 Estimar la entrega de un producto final a lo largo de dos años Grande! Los escenarios en los que la estimación del todo es difícil y que el impacto de los errores es demasiado grande no serían un problema y todo el mundo estaría feliz 2

3 1. La problemática de la estimación Alcance preliminar Necesidades de negocio El fallo en esta lógica Proceso de la Ingeniería de Requierimientos No se pueden identificar cuáles son esas actividades de 12 horas durante las fases iniciales del desarrollo Evolución del desarrollo Decisiones y acuerdos sobre la solución????? Al inicio no sé sabe cuáles son todos los programas Hay trabajo que no es una función de esa cantidad de programas El nivel de información disponible no permite usar la lógica de la estimación de abajo hacia arriba como solución para los desafíos de la estimación 1. La problemática de la estimación #NoEstimates De igual forma, no se puede decidir sobre los cambios que deben ser priorizados dentro del 20% de las demandas que consumen el 80% de los recursos Por qué estimar si al final del trabajo ya estoy seguro de la información de interés? Al final, son apenas entre 15 o 30 días en un ambiente donde se hace uso de enfoques ágiles de desarrollo Se puede esperar por ese momento para saber en lugar de simplemente creer. 3

4 1. La problemática de la estimación CANTIDAD (#) ESFUERZO (HH) < HH 82% > HH 18% < HH 39% > HH 61% Las decisiones ejecutivas de inversión deben ser justificadas a quien mantiene el gobierno de aquella organización Cómo hacer esto con #NoEstimates? La unidad de producto en la construcción civil Presupuesto disponible Casa en el estilo Santa Fé de Cadu 1 m 1 m Costo unitario medio de construcción por m 2 A partir de esto, tuve la oportunidad de tomar varias decisiones: Es más caro (proporcionalmente) construir un baño que un cuarto Cuando tuve que estimar el costo únicamente del baño, ya tenía elementos para realizar estimaciones de abajo para arriba Los desembolsos ocurridos no excedieron la estimación inicial basada en la cantidad de metros cuadrados y en la productividad media 4

5 Arquitectos Ingenieros Maestro de obras Albañiles Ayudantes Impuestos y tasas Aprobaciones y registros Diversos materiales Apropiación indirecta de costos Apropiación directa de costos 1 m US$ 500,00/ m2 Productividad 1 m Casa construída 300 m2 Producto Desembolso con las inversiones US$ ,00 Costo?? Cuál sería la métrica que cumple el papel de unidad de producto para la planificación y seguimiento del desempeño para el desarrollo de software? Unidad de Producto Permite aproximar o medir el tamaño del software a partir de sus requerimientos Apoya en la estimación del esfuerzo del proyecto o en la cuantificación del desempeño a partir de la perspectiva del usuario o dueño para fines del análisis de productividad Es independiente del desarrollo técnico y decisiones de implementación Permite comparar la productividad entre las diferentes técnicas y tecnologías disponibles 5

6 La implementación Al ambiente La organización La calidad 25/09/2015 Otras métricas permiten cuantificar el desempeño técnico de productos y servicios a partir de su implementación Análisis de eficiencia del diseño Mejora en el rendimiento del diseño Apoyo a la Ingeniería de Requerimientos Dimensión del diseño y calidad Apoyo a la verificación y validación Tipos de Requerimientos No son Requerimientos Funcionales Cualquier otro tipo de requerimientos o de restricción de orden general para el producto la interoperabilidad, privacidad y la protección contra daños incidentales o accidentales las tecnologías de desarrollo, mantenimiento, soporte y ejecución como: herramientas de programación y pruebas, sistemas operativos, sistemas de gestión de bases de datos, sistemas de gestión de la interfaz gráfica con el usuario, etc. equipos de destino, la adhesión a las normas y los lugares para la operación desempeño, compatibilidad, usabilidad, confiabilidad, seguridad, mantenibilidad y portabilidad Requerimientos Funcionales Requerimientos que están específicamente asociados a una tarea o servicio del usuario y que describen lo que el software debe hacer independientemente de cómo lo haga Manipulación y movimiento de datos Transferencia Transformación Almacenamiento Recuperación 6

7 Dónde están los requerimientos funcionales? artefatos con definición de requerimientos programas físicos artefatos con decomposición funcional de los requerimientos Requerimientos Funcionales del Usuário ( RFU ) en los artefatos del software a ser medido Procedimentos y manuales operacionales del software artefatos del modelo /análisis de datos préimplementación pósimplementación artefatos de almacenamiento físico de datos La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo Primera versión de los Requerimientos Versión posterior de los Requerimientos Requerimientos Funcionales del Usuario Requerimientos Funcionales del Usuario Puede ser medido por COSMIC Artefactos de Software Requerimientos no Funcionales Verdaderos RFN Debería ser registrado, puede ser cuantificable Evolución de la Línea del Tiempo del Proyecto 7

8 La relación entre los requerimientos funcionales y no funcionales a lo largo del desarrollo Inicialmente, RNF El tiempo de respueta medio en horarios pico no debe exceder X segundos La disponibilidad debe aumentar Y% en relación a la media anual pasada RFU a ser desenvolvido ou adquirido Proveer datos externos en tiempo real Monitorar y reportar tiempo medio de respuesta Habilitar el cambio rápido de procesamiento para un procesador alternativo sin interrupción del servico RNF após requisitos iniciais evoluírem em RFU Equipo apropriado Parte del software escrito en lenguaje de bajo nivel Procesador alternativo operando en hot stand by Derivación de unidad de producto de los requerimientos funcionales ISO/IEC define los principios de la medición del tamaño funcional Implementados en métodos de medición del tamaño funcional por: COSMIC (ISO/IEC 19761:2011) IFPUG APF (ISO/IEC 20926:2009) UKSMA Mk II (ISO/IEC 20968:2002) NESMA APF (ISO/IEC 24570:2005) FISMA (ISO/IEC 29881:2010) 8

9 2 a generación de métodos de medición del tamaño funcional Nivel de confiabilidad compatible con todos los tipos de software Accesible al público y su documentación no tiene costo Tiene reconocimiento total de la ISO/IEC Proyecto es simple y posee una base conceptual compatible con la Ingeniería de Software moderna: Los métodos anteriores no siempre tienen una aplicación amplia suficiente para atender las necesidades del mercado, o funcionan apenas con acceso restringido Planificación y medición del desempeño tiene mayor exactitud Tiene la habilidad de capturar el tamaño a partir de múltiples perspectivas Visión general del método de medición COSMIC Es un valor de una magnitud de acuerdo con el método de COSMIC Independiente de implementación relacionada con los artefactos del software a ser medido Expresado en unidades: Puntos de Función COSMIC o PFC 1 objetivos Conjunto de: Modelos Principios Reglas Procesos 4 3 tamaño funcional de la parte del software 2 Requerimientos funcionales del usuario en los artefactos del software a ser medido Describe lo que el software debe hacer para los usuarios, quienes son los destinatarios y remitentes de los datos Excluye requerimientos técnicos o de calidad que expresan cómo el software funciona La función es relativa al proceso de información que el software debe ejecutar para sus usuarios 9

10 Las fases en la medición COSMIC 1 Objetivos 6 Estrategia de medición Definición de cada parte del software a ser medido de la medición exigida Requerimientos funcionales del Usuario en artefatos del software a ser medido 5 Modelo de contexto de software Fase de mapeo 9 Modelo general de software 8 Requerimientos 10 Funcionales del Usuario en la forma del modelo general de software Fase de medición 11 4 Tamaño funcional del software en unidades de PFC Usuario funcional aplicación siendo medida Aplicación para Usuario funcional humano usuario funcional de la aplicación siendo medida Usuarios funcionales de una parte del software a ser medido identificados a partir de sus RFU, como fuentes y/o destinos pretendidos para datos En la visión lógica para una parte del software de aplicaciones de negocio, los RFU acostumbran a describir sólo la funcionalidad requerida desde el punto de vista de usuarios humanos y, tal vez, otras aplicaciones pares que envíen o reciban datos Cualquier camada de software y dispositivos de hardware que soporten la interación de los usuarios funcionales con la aplicación son facilitadores de las transferencias de datos y no remitentes o destinatarios 10

11 camada de aplicación 25/09/2015 Frontera frontera aplicación siendo medida Aplicación par frontera Frontera definida como interfaz conceptual entre software y usuario funcional Frontera no debe ser confundida con qualquier línea diseñada en un diagrama para delimitar o alcance de una parte del software o camada Frontera permite hacer distinción clara entre cualquier parte del software medido (dentro) y cualquier parte del ambiente de los usuarios funcionales (fuera) Movimientos de datos entradas salidas grabaciones armazenamento persistente aplicación siendo medida exits entries lecturas entries exits aplicación par Movimientos de datos Usuarios funcionales interactuan con el software a través de la frontera via dos tipos de movimientos de datos (entries y exits) Software también intercambia datos con el dispositivo de almacenamiento persistente via dos tipos de movimientos de datos (reads y writes) El dispositivo de almacenamiento no es considerado como un usuario del software y, por tanto, está dentro de la frontera del software 11

12 Ejemplo de Movimientos de datos usuario funcional processo funcional objetos de interés cliente producto pedido items de pedido pedido item del pedido confirmación del pedido cliente producto pedido item del pedido Medición Vs Aproximación del tamaño 1 PFC G1 = 1,5 PFC G2 ± 25% 1 PFC G2 = 1,33 PFC G3 ± 15% Editar y gerenciar pedidos de vacaciones 100 PFC G1 incluir, alterar, excluir, apreciar PFC G2 especificación completa 200 PFC G3 Estimar/Aproximar Medir propuesta requerimientos proyecto construcción implementación 1. Evaluar el desempeño por la relación entre la cantidad de horas invertidas y la cantidad de puntos función COSMIC medidos 2. Re-evaluar los indicadores de productividad para que pasen a incluir el desempeño de los proyectos que terminan 3. Re-evaluar la cantidad de puntos función COSMIC que corresponden en promedio a los procesos y a los conceptos de negocio 12

13 Benchmarking Esfuerzo estimado por otros métodos: 1000 HH 07 HH/CFP o menos de 8% de probabilidad Aproximación del Tamaño: 150 CFP Conócete a ti mismo 13

14 Conclusión De algo que estoy seguro es sobre la diferencia de las respuestas para la siguiente pregunta: " Por qué me pides HH para el proyecto y no HH? Porque yo lo sé Porque sólo hay un 2% de probabilidad de entregar el proyecto de este tamaño con HH de acuerdo a nuestros datos históricos. No hay un proyecto de la base de datos internacional de evaluación comparativa que indique esto como algo posible 14