Cap. 3 Metricas y Estimaci¢n de Software.pdf

13005-Ingeniería de Software 2 Métricas y Estimación de Software Ing. Carlos Medina MBA,, PMP®,COBIT®, ITIL ® ISO , 27001 [email protected] Definición y clasificación de Métricas...

13005-Ingeniería de Software 2 Métricas y Estimación de Software Ing. Carlos Medina MBA,, PMP®,COBIT®, ITIL ® ISO , 27001 [email protected] Definición y clasificación de Métricas Ing. Carlos Medina MBA,, PMP®,COBIT®, ITIL ® ISO , 27001 [email protected] Definiciones Medida: o Suministra una indicación cuantitativa de extensión, cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto. o Medida Directa: número de líneas de código, número de errores. o Medida Indirecta: Funcionalidad, calidad, complejidad, etc. Medición: o Acto de determinar una medida. Definiciones Métrica: o Medida cuantitativa del grado en que un sistema o proceso posee un atributo dato. o Relaciona una o más medidas. Ejemplo: número de errores encontrados por cada mil líneas de código. Indicador: o Métrica, o combinación de métricas que suministran una visión del proceso, del proyecto o del software en sí, y poder hacer ajustes para que las cosas mejoren. Tipos de Métricas Métricas del Producto: Le permiten a la organización de ingeniería del software o tener una visión mas profunda de la eficacia de un proceso existente. o Permiten determinar lo que esta funcionando o no. Métricas del Proceso: Le permiten a la organización de ingeniería del software: o Métricas del proceso de Desarrollo o tener una visión mas profunda de la eficacia de un proceso existente. o Permiten determinar lo que esta funcionando o no. o Permiten tomar decisiones. o Las métricas se recolectan para brindar indicadores. o Métricas del Proyecto: Le permiten al director del Proyecto o Evaluar el estado del Proyecto en curso. o Seguir la pista de los riesgos potenciales. o Detectar las áreas problemáticas antes de que sean criticas. o Ajustar el flujo y las tareas del trabajo. o Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo. Interpretar las Métricas de calidad Es necesario abalizar y evaluar los datos obtenidos de las métricas. Estas deben ser: Simples Fáciles de calcular Empíricas Intuitivamente persuasivas Consistentes y Objetivas Deben Cubrir: La cobertura de las Pruebas El numero de defectos descubiertos El tiempo de respuesta Velocidad de ejecución. Interpretar las Métricas de calidad Por ejemplo. Si la cobertura de pruebas es baja, se pueden agregar más casos de prueba para mejorar la calidad del software Si el número de defectos descubiertos es alto, se pueden revisar los procesos de desarrollo y prueba para identificar y corregir los errores En resumen, la interpretación de los resultados de las métricas de calidad del software es fundamental para identificar problemas en el ciclo de vida del software y tomar medidas para mejorar la calidad del software.  Métricas relevantes de Calidad de Software Cobertura de pruebas: Esta métrica indica la cantidad de código que ha sido probado, lo que puede ayudar a identificar áreas del software con poca cobertura de pruebas y, por lo tanto, más propensas a contener errores. Número de defectos: Permite medir la cantidad y gravedad de los defectos encontrados en el software, lo que puede indicar problemas de calidad y áreas que requieren mayor atención. Rendimiento: Incluye métricas como el tiempo de respuesta y la velocidad de ejecución, que son fundamentales para evaluar la eficiencia y el rendimiento del software, y pueden revelar posibles cuellos de botella o problemas de escalabilidad Cómo se pueden aplicar las métricas de calidad del software en diferentes etapas del ciclo de vida del software Planificación: Medir la cantidad de requisitos especificados, la complejidad del sistema y la estimación de tiempo y recursos necesarios para su implementación. Análisis: Evaluar la calidad del modelo de análisis, la complejidad del diseño y la coherencia entre los componentes del sistema. Diseño: Medir la calidad del diseño arquitectónico, la cohesión y la coupling entre los componentes del sistema. Implementación: Medir la cantidad de líneas de código agregadas, modificadas o eliminadas, así como la densidad de comentarios y la cobertura de pruebas unitarias. Pruebas: Medir la cobertura de pruebas, la cantidad de defectos descubiertos, el tiempo de respuesta y la velocidad de ejecución. Integración: Medir la integración continua, la automatización de pruebas y la estabilidad del software después de cada integración. Entrega: Medir la calidad del producto final, la satisfacción del cliente y la adherencia a los estándares de calidad establecidos. Mantenimiento: Medir la cantidad de cambios realizados, la cobertura de pruebas de mantenimiento y la estabilidad del software después de cada actualización.  Métricas aplicadas al Ciclo de Vida del Software Métricas Orientadas al Análisis Métricas Orientadas al Diseño Métricas del Código Fuente Métricas del Mantenimiento  Métricas aplicadas al Ciclo de Vida del Software Métricas Orientadas al Análisis Métricas basadas en Puntos de Función (PF) Métricas de la calidad de la especificación [Davis] Métricas Basadas en Puntos de Función (PF) Los métodos de análisis de puntos de función (APF) son técnicas de medición de la funcionalidad de software, independientemente de cómo fue construido. Busca determinar la cantidad de trabajo necesaria para desarrollar el software, sin prestar atención a factores como la tecnología empleada o la experiencia del equipo. Los puntos de función (FP) son unidades de medida que representan una cantidad independiente de la tecnología utilizada para construir el software Adoptada ampliamente debido a su capacidad para proporcionar una medida abarcadora de la complejidad del software, lo que permite estimar el esfuerzo, el tiempo y el costo de proyectos de software. Métricas Basadas en Puntos de Función (PF) Miden la funcionalidad del producto de software No se puede medir directamente. Evalúa la complejidad del software: o Entradas Externas (EE). Entradas que suministran datos a la aplicación. o Salidas Externas (SE). pantallas o mensajes Reportes, que dan información. o Consultas Externas (CE). Entrada interactiva que produce una respuesta del software en forma de salida interactiva. o Archivos Lógicos Internos (ALI). Archivos que pueden ser parte de una base de datos o de tipo independiente. o Archivos de Interfaz Externas (AIE). Archivos que se usan para transmitir información a otro sistema.  Métricas Basadas en Puntos de Función (PF) Para cada medida, se multiplica la cuenta por el factor de complejidad elegido y escribirlo en la columna de la extrema derecha. Se suma la columna de la extrema derecha y obtener un total (Conteo Total) que indica el valor del dominio de la información.  Factores de Ajuste de Valor (FAV) Se responde a cada una de las siguientes catorce preguntas y asignarles un valor entre 0 y 5, donde: 0: no influencia, 1: incidental, 2: moderado, 3: medio, 4: significativo y 5: esencial. 1. ¿Requiere el sistema copias de seguridad y 8. ¿Se actualizan los archivos maestros de forma de recuperación fiables? interactiva? 2. ¿Requiere comunicación de datos? 9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones? 3. ¿Existen funciones de procesamiento distribuido? 10. ¿Es complejo el procesamiento interno? 11. ¿Se ha diseñado el código para ser reutilizable? 4. ¿Es crítico el rendimiento? 12. ¿Están incluidas en el diseño la conversión y la 5. ¿Se ejecutará el sistema en un entorno instalación? operativo existente y fuertemente utilizado? 13. ¿Se ha diseñado el sistema para soportar 6. ¿Requiere entrada de datos interactiva? múltiples instalaciones en diferentes 7. ¿Requiere la entrada de datos interactiva que organizaciones? las transacciones de entrada se lleven a cabo 14. ¿Se ha diseñado la aplicación para facilitar los sobre múltiples pantallas u operaciones? cambios y para ser fácilmente utilizada por el usuario? Se suman los puntos asignados a cada respuesta y obtener un total F que indica un valor de ajuste de complejidad. Métricas Basadas en Puntos de Función (PF) El punto de función FP se calcula con la siguiente ecuación: PF = conteo total * [0.65 + 0.01 *∑ (Fi)] Donde: Conteo total: suma de todas las entradas. (Fi -> i= 1..14): factores de ajuste de valor (FAV) Métricas Basadas en Puntos de Función (PF) Ejemplo: (Pressman) Métricas Basadas en Puntos de Función (PF) Paso 1: Identificar Entradas Externas (EE) -> 3 Métricas Basadas en Puntos de Función (PF) Paso 2: Identificar Consultas Externas (CE) -> 2 Métricas Basadas en Puntos de Función (PF) Paso 3: Identificar Archivo Lógico Interno (ALI) -> 1 Métricas Basadas en Puntos de Función (PF) Paso 4: Identificar Salidas Externas (SE) -> 1 Métricas Basadas en Puntos de Función (PF) Paso 5: Establecer Ponderación y realizar conteo Suponiendo un (Fi) es 46 (moderadamente complejo). Se puede asumir un N° de líneas de PF = 50 x [0.65 + (0.01 x 46)] = 56 código por PF para determinar esfuerzo. Ej: 60 líneas x PF Métricas de la Calidad de Especificación [Alan Davis 1983] Hace referencia a la evaluación de la calidad de los requisitos y especificaciones de un software. Davis define la calidad como "la aplicación inteligente de principios probados, técnicas, lenguajes y herramientas para la creación y mantenimiento, dentro de un coste razonable, de software que satisfaga las necesidades de los usuarios” Estas métricas incluyen características como especificidad, completitud, corrección, comprensión, verificación, consistencia, logro, concisión, trazabilidad, modificación, exactitud y reutilización. Estas características ayudan a valorar la calidad del modelo de análisis y la correspondiente especificación de requisitos, permitiendo identificar posibles problemas en los requisitos del software y contribuyendo a la entrega de un producto final de mayor calidad Métricas de la Calidad de Especificación [Alan Davis 1983] Formulación: Nr = Nf + Nnf, donde: Nr = Número de requerimientos Nf = Número de requerimientos funcionales Nnf = Número de Requerimientos No funcionales. Se determina la especificidad como: Q1 = Nui / Nr, donde: Nui = Numero de requerimientos donde todos los revisores interpretaron los requerimientos de forma igual.  Métricas aplicadas al Ciclo de Vida del Software Métricas Orientadas al Diseño Métricas de Complejidad (Card, Glass) Métricas de Morfología (Fenton)  Métricas de Complejidad (Card, Glass 1990) Abarcan tres medidas principales: complejidad estructural, complejidad de datos y complejidad del sistema. Estas métricas permiten evaluar la calidad del diseño a nivel de los componentes, brindando una visión interna que ayuda a los desarrolladores a juzgar la eficiencia y la arquitectura del programa La complejidad estructural, representada por S(i), se define como la expansión del módulo i, es decir, el número de módulos directamente subordinados a él. Por otro lado, la complejidad de datos, D(i), se refiere al número de variables de entrada y salida que entran y salen del módulo i. Finalmente, la complejidad del sistema, C(i), es la suma de las complejidades estructural y de datos.  Métricas de Complejidad (Card, Glass 1990) Complejidad estructural: donde: Expansión del módulo (i). – número de módulos subordinados al módulo i. Complejidad de Datos. Sobre la interfaz interna del módulo: D(i) = v(i) / [ +1], donde: v(i) = número de variables que entran o salen del módulo Complejidad Total del Sistema: SI crecen los valores de complejidad, crece la CS = ∑(S(i)+D(i)) complejidad arquitectónica del sistema. Complejidad Relativa del Sistema: CRS > 26.5 à Malo. CRS = Promedio (S(i) +D(i)) Métricas de Complejidad Métricas de Complejidad – Tabla Cálculo de complejidad para el ejemplo: Módulo Expansión del Complejidad Complejidad de Módulo Estructural Datos Módulo Ejecutivo ATM 4 16 1.6 Complejidad total Introducir Tarjetas 0 0 6 Del Sistema: 40.1 Identificar NIP 0 0 3 Solicitar Saldo 1 1 2 Complejidad Relativa: Retirar Efectivo 2 4 3 6.65. Calcular Entrega 1 1 2.5 TOTALES 22 18.1 Métricas de Complejidad – Tabla Cálculo de complejidad para el ejemplo: D(i) CS CRS Expansión del Complejidad Variables Complejidad Complejidad Complejidad Módulo Módulo Estructural IN/OUT de Datos Total Relativa Módulo Ejecutivo 4 16 8 1,6 17,6 19,2 ATM Introducir Tarjetas 0 0 6 6 6 12 Identificar NIP 0 0 3 3 3 6 Solicitar Saldo 1 1 4 2 3 5 Retirar Efectivo 2 4 9 3 7 10 Calcular Entrega 1 1 5 2,5 3,5 6 TOTALES 22 18,1 40,1 9,7 Métricas de Morfología (Fenton) Se utilizan para comparar diferentes arquitecturas de software a través de dimensiones directas. Estas métricas simples permiten evaluar la forma general de la estructura del sistema y pueden incluir medidas como el tamaño, la profundidad y la anchura de la arquitectura. Por ejemplo, una de las métricas propuestas es el tamaño, que se calcula como la suma del número de nodos y arcos en la arquitectura Métricas de Morfología (Fenton) Se propone medidas basadas en la forma (morfos) según la estructura jerárquica de módulos del sistema. Tamaño = n + a (número de nodos + numero de aristas) Profundidad Anchura Relación arco nodo à R = a/n Métricas de Morfología (Fenton) tamaño= n + a tamaño= 17+18=35. Profundidad= 4 amplitud= 6 Relación arco/nodo R=18/17= 1.06  Métricas aplicadas al Ciclo de Vida del Software Métricas Orientadas al Código Fuente Líneas de código Métricas de complejidad de Halstead Métricas Orientadas al Código Fuente (Halstead, 1977) Se definen las siguientes métricas: Longitud del programa (N): Se estima como N = n1 log2 n1 + n2 log2 n2, donde n1 es el número de operadores diferentes en el programa y n2 es el número de operandos distintos en el programa. Volumen del programa (V): Se define como V = N log2(n1 + n2), donde N es la longitud del programa. Volumen compacto (L): Se calcula como L = 2 / n1 x n2 / N2, donde N es la longitud del programa. Estas métricas proporcionan información sobre la complejidad y el esfuerzo necesario para desarrollar y probar el software, lo que puede ser útil para evaluar la calidad y el rendimiento del código fuente. Métricas Orientadas al Código Fuente (Halstead, 1977) Se definen las siguientes variables: Las métricas de Halstead son: n1 = número de operadores diferentes en el programa Longitud global del programa n2 = número de operandos N = n1 log2 n1 + n2 log2 n2 diferentes en el programa N1 = número total de veces que aparecen los operadores Volumen del programa N2 = número total de veces que V = N log2 (n1 + n2) aparecen los operandos. Métricas Orientadas al Código Fuente (Halstead, 1977) n1 = número de operadores diferentes en el programa n2 = número de operandos diferentes en el programa N1 = número total de veces que aparecen los operadores N2 = número total de veces que aparecen los operandos. N Operador Cuenta N Operando Cuenta 1 for 2 1 I 4 2 = 6 2 J 5 3 < 2 3 N 2 4 ++ 2 4 Temp 3 5 - 1 5 X 4 Total 13 Total 18 n1 = 5 n2 = 5 N1 = 13 N2 = 18  Métricas aplicadas al Ciclo de Vida del Software Son herramientas utilizadas para medir y evaluar diferentes aspectos del desarrollo de software a lo largo de su ciclo de vida. Productividad del desarrollador: Mide la eficiencia y el rendimiento de los desarrolladores en la creación de software. Rendimiento del software: Evalúa cuantitativamente cómo se comporta un sistema de software. Defectos y seguridad: Se centra en la detección y gestión de defectos en el software para garantizar su calidad. Experiencia de usuario (UX): Analiza aspectos cualitativos relacionados con la interacción y satisfacción del usuario con el software.  Métricas aplicadas al Ciclo de Vida del Software Métricas Orientadas al Mantenimiento Estándar IEEE 982.1-1998, define el Índice de Madurez de Software (IMS), que define la estabilidad de un producto de software. Donde: Mt = número de módulos de la versión actual Fc = número de módulos que modificaron de la versión actual Fa = número de módulos que se agregaron de la versión actual Fd = número de módulos que se eliminaron de la versión actual. Estimación de Software Estimación del Costo del Software La estimación y calendarización (scheduling) del proyecto se llevan a cabo de forma conjunta. Sin embargo se debe contar con estimaciones previas para ver los efectos sobre la calendarización y éstas se actualizan de forma regular. Permite la utilización efectiva de los recursos y una adecuada planeación. Parámetros de Costos (Además del personal de ingenieros, arquitectos de software, etc.): Arrendamiento de oficinas Servicios públicos. Personal de apoyo como contadores, secretarias, limpiadores y técnicos. Redes y comunicaciones e infraestructura. Seguridad social y de beneficio de empleados como las pensiones y seguros de salud. Costos de viajes y capacitación Costos de hardware y software, incluyendo mantenimiento Factores que afectan la asignación de precios al software Oportunidad de mercado: penetración de mercado con cotización de bajos costos al inicio. Incertidumbre: Incremento del precio de venta, para cubrir costos por riesgos emergentes. Términos contractuales: Aumentar el precio de venta, por asumir condiciones específicas, ej: entrega del código fuente en el desarrollo. Factores que afectan la asignación de precios al software Volatilidad de los requerimientos: Precio de venta reducido para el proyecto inicial para ganar el contrato. Después del contrato tener precios altos por solicitudes de cambios de requerimientos. Salud Financiera: Cuando las fábricas de software tienen dificultades financieras podrían bajar sus costos para ganar contratos. Esto es mejor que quedar fuera del negocio o quebrar Algunas Técnicas de Estimación Estimación Algorítmica Modelo de costo basado en una métrica de software (tamaño). Se hace una estimación con ésa métrica y arroja el costo según esfuerzo. Juicio Experto Consulta de expertos en desarrollo de software y la aplicación. Cada uno de ellos estima el costo del proyecto. Comparación y discusión hasta haya consenso. Estimación Analógica Se estima el costo de un nuevo proyecto por similaridades con otros proyectos completados. Algunas Técnicas de Estimación Ley de Parkinson El trabajo se extiende para llenar el tiempo disponible. El costo se determina por los recursos disponibles más que por los objetivos logrados. Ejemplo: Si un software se hace en 6 meses, pero si se acuerda la entrega con el cliente en 12 meses, se realizará entonces en los 12 meses. Asignar precios para Ganar El esfuerzo estimado depende del presupuesto del cliente y no de la funcionalidad del software. Estimación Algorítmica de Costos Esfuerzo = A x TamañoB x M Donde: A: es un factor constante que depende de las prácticas organizacionales locales y del tipo de software que se desarrolla. Tamaño es una valoración del t amaño del código del software o una estimación de la funcionalidad expresada en Puntos de Función (PF), o cada mil líneas de código. B: Exponente (valores entre 1 y 1.5). Refleja el esfuerzo requerido para proyectos según su tamaño. M: es un multiplicador generado al combinar diferentes procesos, atributos del producto y del desarrollo. Modelo COCOMO - (Constructive Costo Model) § Es un modelo matemático empírico utilizado para estimar el esfuerzo, el tiempo y el costo requeridos para desarrollar un proyecto de software § Se obtuvo recolectando datos de varios proyectos de software grandes, se analizar los mismos para inferir fórmulas que se ajustarán mejor a las observaciones. § Esta bien documentado, es de dominio público y lo apoyan herramientas comerciales. § Se ha utilizado y evaluado ampliamente. § Ha evolucionado del COCOMO 81( 1981) al COCOMO 2 (1995) Modelo COCOMO - (Constructive Costo Model) Es Fue desarrollado por Barry Boehm a finales de los años 70 y comienzos de los 80. COCOMO incluye tres submodelos: básico, intermedio y detallado..El modelo básico se utiliza para estimar proyectos pequeños y medianos de manera rápida. Se divide en tres modos de desarrollo: orgánico, semi-acoplado y empotrado. El modelo intermedio se emplea para estimaciones más complejas e incluye 15 atributos que abarcan aspectos del producto, del ordenador usado, del personal y del proyecto. El modelo detallado incorpora las características del modelo intermedio y evalúa el impacto de los factores de coste en cada fase del proceso de ingeniería del software. COCOMO Básico Complejidad del proyecto Fórmula Descripción Aplicaciones bien comprendidas Simple PM = 2.4 (KLDC)1.05 x M desarrolladas por equipos pequeños Proyectos más complejos donde los Moderada PM = 3.0 (KLDC)1.12 x M miembros del equipo tienen experiencia limitada en sistemas relacionados Proyectos complejos donde el software es parte de un complejo fuertemente Incrustada PM = 3.6 (KLDC)1.20 x M acoplado de hardware, software, reglas y procedimientos operacionales. KLDC: Mil líneas de código COCOMO Básico: Factor M M= PERS x RCPX x RUSE x PDIF x FCIL x SCED. Donde M representa 7 conductores de procesos PERS: capacidad del personal RCPX: fiabilidad y complejidad del producto RUSE: reutilización requerida PDIF: dificultad de la plataforma PREX: experiencia del personal FCIL: recursos de apoyo. SCED: calendarización Estos pueden estimarse en una escala de 1 a 6 -> 1: corresponde a un valor muy bajo y 6 a valores muy altos. COCOMO Básico: Factor M M= PERS x RCPX x RUSE x PDIF x FCIL x SCED. Donde M representa 7 conductores de procesos PERS: capacidad del personal RCPX: fiabilidad y complejidad del producto RUSE: reutilización requerida PDIF: dificultad de la plataforma PREX: experiencia del personal FCIL: recursos de apoyo. SCED: calendarización Estos pueden estimarse en una escala de 1 a 6 -> 1: corresponde a un valor muy bajo y 6 a valores muy altos. COCOMO Básico: Factor M COCOMO Básico: Factor M ¡Gracias!