Métricas para mantener el Presupuesto. Administración y Gestión de Proyectos de Software. Métricas para mantener el Presupuesto

Transcripción

1 Métricas para mantener el Presupuesto Administración y Gestión de Proyectos de Software Objetivo: Maximizar la cantidad de funciones entregables por dólar del costo total (todo el tiempo de vida) del sistema. 2do. Cuatrimestre 2005 Costo total del sistema= costo de desarrollo + costo de producción + costo de mantenimiento. Depto. Cs. e Ingeniería de la Computación Universidad Nacional del Sur Prof. Sergio Martig Clase 5-2 Métricas para mantener el Presupuesto 1. Formular un sólo indicador de medida de éxito vs el objetivo. (Bang per Buk BPB). Este indicador es una medida de la funcionalidad entregada por el proyecto por cada dólar invertido. 2. Coleccionar datos en una muestra de proyectos para establecer estándares de performance de BPB. 3. Buscar y evaluar predictores para aquellas partes de medida del BPB que influyen a futuro. 4. Motivar al personal para mejorar el BPB. El personal debe estar informado de cómo se calcula el BPB. 5. Publicar el BPB proyectado durante el proyecto, y el actual luego de 6 meses de la implementación. Métricas para mantener el Presupuesto La principal justificación para la colección y análisis de datos métricos no es obtención del objetivo sino alineación al objetivo Maximizar la funcionalidad entregada por cada peso invertido es un objetivo indiscutible. Cómo pesamos funcionalidad? Prof. Sergio Martig Clase 5-3 Prof. Sergio Martig Clase 5-4 1

2 Modelización del Problema Modelización del Problema Un modelo consiste de una partición, junto con un registro de las interfaces entre las piezas de la partición. Se necesitan tres perspectivas para especificar la mayoría de los sistemas: 1. Modelo Funcional: visión particionada de lo que hace el sistema. 2. Modelo de Datos Retenido: visión particionada de lo que el sistema recuerda. 3. Modelo de Comportamiento: visión de los diferentes estados de comportamiento que caracterizan al sistema. Prof. Sergio Martig Clase 5-5 Prof. Sergio Martig Clase 5-6 Modelo Funcional Modelo de Datos Describe todo el sistema. Muestra cómo los inputs se transforman en outputs Particiona en las funciones constituyentes y en las interfaces entre las mismas. Particiona hasta el nivel elemental. Particiona de manera que las interconexiones se minimicen. Define cada ítem de dato en la red, llegando al nivel de elemento de dato. Lo podemos considerar como una proyección sobre el espacio de las funciones. Una representación concisa de los requerimientos del sistema desde el punto de vista de los datos dentro del sistema. Todos los datos retenidos por el sistema son datos que describen cosas simuladas por el mismo. (descripción de atributos) La mayoría de los datos retenidos son descriptores de un y sólo un objeto simulado. Lo podemos pensar como una proyección en el espacio de información Prof. Sergio Martig Clase 5-7 Prof. Sergio Martig Clase 5-8 2

3 Modelo de Comportamiento Componentes Primitivas de un Modelo Un sistema típicamente va pasando por distintos estados, cada uno de los cuales está caracterizado por su respuesta única a un conjunto de estímulos dados. Está compuesto por los estados y los eventos que causan que el sistema cambie de un estado a otro, junto con una descripción de su comportamiento Podemos pensar al modelo de transición de estados como una proyección sobre el espacio de los estados Prof. Sergio Martig Clase 5-9 Prof. Sergio Martig Clase 5-10 Modelo de Especificación Modelo de Especificación. Métricas La confección de un modelo formal provee tres beneficios: 1. El modelo de especificación es público. Puede ser corregido y refinado por miembros del proyecto o usuario. 2. El modelo de especificación tiene características medibles que pueden ser relacionadas con performance observada. 3. El modelo de especificación es terminado en forma temprana durante el proyecto, provee oportunidad para corregir las estimaciones. El modelo de especificación describe los requerimientos en sí mismo, no la forma de satisfacerlos. Un análisis cuantitativo del modelo provee una medida de la funcionalidad a ser entregadas. Esto es lo que llamamos Bang. Bang: Métrica de funcionalidad. Una indicación del tamaño del sistema independiente de la implementación. El tamaño del modelo de especificación es una medida directa de la funcionalidad a ser entregada. Prof. Sergio Martig Clase 5-11 Prof. Sergio Martig Clase

4 Componentes Primitivas del Modelo de Especificación Componentes Primitivas del Modelo de Especificación Contar las primitivas (P- counts) provee métricas básicas para medir el Bang: 1. PF: número de primitivas funcionales automáticas 2. PFM: número de primitivas funcionales manuales modificables 3. DE: número de datos elementales dentro del sist. automático 4. DEI: número de datos elementales de input 5. DEO: número de datos elementales de output 6. DER: número de datos elementales retenido Prof. Sergio Martig Clase 5-13 Prof. Sergio Martig Clase OB: número de objetos retenidos Componentes Primitivas del Modelo de Especificación 8. RE: número de relaciones en el modelo de datos retenido 9. ST: número de estados en el modelo de comportamiento 10.TR: número de transiciones en el modelo de comportamiento 11.TCi: número de data tokens en la primitiva i 12.REi: número de relaciones que involucran al objeto i Formulación de una Teoría de Costos Bang Tentativo = PF * (Factor de Peso para PF) + DE * (Factor de Peso para DE) +... Para caracterizar el Bang se elige uno de los indicadores como el principal y se usan los otros para modificarlo. En la mayoría de los sistemas administrativos PF es el principal indicador. Hay sistemas altamente orientados a funciones (function- strong) y otros a datos (data- strong), dependiendo de esto es el indicador que se deberá considerar como principal. Prof. Sergio Martig Clase 5-15 Prof. Sergio Martig Clase

5 Formulación de una Teoría de Costos Dominios de Sistemas en Función de Ratios Se pueden analizar dos ratios en función de PF (primitivas funcionales) y RE (relaciones entre objetos). RE/PF < 0.7 =. Sistema orientado a funciones. RE/PF > 1.5 =. Sistema orientado a datos. El ratio DEO/PF es una medida de cuánto el sistema está dedicado a cálculos o a administración de datos. Prof. Sergio Martig Clase 5-17 Prof. Sergio Martig Clase 5-18 Bang para sistemas orientados a Funciones Indicadores para Partición Uniforme La componente principal del Bang para estos sitemas es el PF Es el PF una medida satisfactoria? Todas las primitivas funcionales demandan el mismo esfuerzo? Diferencia en tamaño Diferencia en complejidad Puedo encontrar distintos tamaños por la manera en que se particiona. Se puede calcular: TCavg = TCi/PF Regla de Partición Uniforme: Dejar una componente como primitiva sólo si no es posible una partición o si la nueva partición no reduce el TCavg. Ejemplo: De Marco (pag. 86) Puede ser que ésta partición no sea buena para los analistas. La deberán realizar los integrantes del grupo de Métricas. Prof. Sergio Martig Clase 5-19 Prof. Sergio Martig Clase

6 Correcciones en el tamaño El tamaño relativo de una función puede ser aproximado como una función de los TC i. El problema de cómo varía el tamaño en función de los TC i fue estudiado por Halstead. Tamaño(primitivai) es proporcional a TC i * LOG 2(TC i) Existen tablas para corregir el tamaño de las PF en función de los TC i Ahora tenemos PFC = PFC i Prof. Sergio Martig Clase 5-21 Correcciones en complejidad Las primitivas pueden tener distinta complejidad. Podemos considerar esa variación clasificando la primitiva y asignándole el valor de corrección correspondiente. Las correcciones dependen del contexto. Según De Marco las podemos clasificar en: 1. Separación: dividen los datos de input 2. Merge: combinan los datos de input (Amalgamation) 3. Dirección de Datos: dirigen datos de acuerdo a una variable de control 4. Actualización simple: actualiza uno o mas datos en almacenamientos 5. Administración de almacenamientos: analiza datos almacenados y actúa basado en el estado de los datos. Prof. Sergio Martig Clase 5-22 Correcciones en complejidad 6. Edición: evalúa nuevos datos en frontera hombremáquina 7. Verificación: chequea e informa inconsistencias. 8. Manipulación de textos: administra textos. 9. Sincronización: decide cuando actuar o decide por otras. 10.Generación de output: formatea nuevos flujos de datos (no tabulares). 11.Display: construye outputs tabulares (2 dimensiones). 12.Aritméticas: realiza cálculos. 13.Inicialización: setea valores para datos almacenados. 14.Computación: cálculos matemáticos complejos. 15.Administración de dispositivos: controla dispositivos. Prof. Sergio Martig Clase 5-23 Bang para sistemas orientados a Datos La componente principal del Bang para este tipo de sistemas es el OB. Nuevamente nos enfrentamos al hecho de que no todos los objetos tienen un mismo costo de implementación. Se aplica un factor de corrección en función de su grado de relación con los otros objetos. (REi) Prof. Sergio Martig Clase

7 Bang para sistemas Híbridos Cálculo del Bang: Funcional En sistemas híbridos se aconseja manejar dos Bangs, el funcional y el de datos. No se puede generalizar una fórmula que los relacione. El Bang es un indicador cuantitativo de las funciones útiles netas desde el punto de vista del usuario. Independiente de la implementacion. Objetivos de Calcular el Bang: 1. Se usa como un predictor fuerte y anticipado del esfuerzo. 2. Se usa para calcular eficiencia productiva: BPB Se deben usar otras métricas para otras actividades(conversion, BD,...) 1. Inicializar Bang = 0 2. Para cada primitiva funcional en el modelo: a) TC i = suma de los data token b) PFC i = Tabla de corrección (TC i) c) Clasificar la primitiva en la clase que corresponda. d) PesoCorregido i = Tabla de corrección peso (tipo de primitiva) e) Bang = Bang + PFC i * PesoCorregido i Prof. Sergio Martig Clase 5-25 Prof. Sergio Martig Clase 5-26 Cálculo del Bang: Orientado a Datos 1. Inicializar Bang = 0 2. Para cada objeto del modelo de objetos: a) Calcular RE i b) OBC i = Tabla de corrección (RE i ) c) Bang = Bang + OBC i Modelo de Diseño Diseño es determinar qué módulos y con qué interfaces deberán implementarse para satisfacer los requerimientos especificados. La descomposición del producto en módulos es el modelo de diseño. El diseño esta completo ssi 1. Existe relación 1-1 entre: módulos- modelo y módulosimplementados. 2. Existe relación 1-1entre: relaciones entre módulos del modelo y las relaciones entre módulos implementadas. 3. Existe relación 1-1entre: interfaces de datos entre módulos del modelo y los datos compartidos entre los módulos implementados. Prof. Sergio Martig Clase 5-27 Prof. Sergio Martig Clase

8 Modelo de Diseño. Notación Modelo de Diseño. Versiones Una técnica común para modelizar diseños sincrónicos es la representación mediante una jerarquía de módulos: carta estructurada. Si esperamos métricas comparables de proyecto en proyecto, se necesita establecer un acuerdo sobre la granularidad del diseño. Problema de Particiones Uniformes: la partición de diseño está completa cuando los módulos son suficientemente pequeños para ser implementados sin nuevas particiones. Test simple de partición: el módulo no necesita etiquetas internas. Prof. Sergio Martig Clase 5-29 Prof. Sergio Martig Clase 5-30 Modelo de Diseño. Versiones Métricas de Diseño En ciclos evolutivos, muchas veces se utilizan técnicas de implementación top-down o implementación por versiones. Los módulos que una versión no contiene son reemplazados por módulos dummy o stubs. Esta técnica presenta varias ventajas: testeo incremental, disponibilidad anticipada de productos parciales, etc. Es relevante la información cuantitativa que puede ser extractada del plan de versiones, y el uso que se le puede dar a esta información. Se puede deducir en base a los resultados de una versión, la completitud y grado de aceptación de la implementación total. Prof. Sergio Martig Clase 5-31 El Peso del Diseño puede ser usado para mejorar los predictores basados en el Bang Prof. Sergio Martig Clase

9 Métricas de Diseño Primitivas 1. MO = cantidad de módulos 2. CO = cantidad de conexiones entre módulos 3. DA i = data tokens en conexiones normales del módulo i 4. SW i = control tokens en conexiones normales del módulo i 5. EN = cantidad de datos encapsulados 6. AE i = (amplitud del encapsulamiento) número de módulos que acceden al grupo de datos i 7. PE i = (profundidad del encapsulamiento) número de datos elementales contenidos en el grupo i 8. PA = cantidad de conexiones patológicas 9. DP i = cantidad de data tokens patológicos compartidos por el módulo i 10.SP i = cantidad de control tokens patológicos compartidos por el módulo i Métricas de Diseño Primitivas Ejemplo: Ver fotocopia entregada. Figura 11-2, Pág 105. Libro de De Marco. Prof. Sergio Martig Clase 5-33 Prof. Sergio Martig Clase 5-34 Peso del Diseño Peso del Diseño El procedimiento requiere: 1. Observación de las Métricas Primitivas derivadas del Modelo de Diseño 2. Cálculo del predictor Peso de Diseño 3. Colección de los valores del predictor y los correspondientes costos y tiempos de implementación para un conjunto de proyectos 4. Correlación de los valores del predictor con las cantidades a ser proyectadas 5. Proyección de los costos y tiempos del nuevo proyecto en función del valor observado para el predictor. Una vez que las Métricas primitivas del diseño son obtenidas, necesitamos alguna manera de poder integrarlas para obtener un único valor del Peso del diseño de un Módulo. El peso del diseño servirá entonces como un predictor del esfuerzo restante, es decir: Esfuerzo de Implementación Esfuerzo de Testing Prof. Sergio Martig Clase 5-35 Prof. Sergio Martig Clase

10 Peso del Diseño Dos módulos con similar longitud: Requieren el mismo esfuerzo de implementación y testing? Imposibilidad de usar las métricas de diseño en forma directa. Regla: El tiempo de implementación para módulos de similar longitud varía con el número de decisiones en el módulo. (Complejidad de la estructura interna). Una forma de determinar el número de decisiones, sería realizar un pseudocódigo. Consume tiempo y esfuerzo. Idea de Warnier: la estructura interna de un módulo es isomórfica con la estructura de datos de su contexto. Prof. Sergio Martig Clase 5-37 Peso del Diseño. Número de decisiones Paralelismo entre la Estructura de los Datos y su Proceso: La idea de Warnier es que todas las decisiones presentes en el código están basadas en los datos procesados por ese código. La estructura de los datos del entorno de un módulo nos da una pista de cómo el código del mismo debería ser escrito. Estimación del número de decisiones a partir del diseño. Si existe una sub estructura repetitiva en los datos de entrada, debería haber un bucle que lo procese. Si hay un dato opcional, un campo que puede o no estar, debería haber un condicional en el código. Si las alternativas que presenta un dato son varias deberá contarse con un mecanismo de selección que lo trate de manera adecuada. Prof. Sergio Martig Clase 5-38 Peso del Diseño. Número de decisiones Peso del Diseño. Número de decisiones Notación: Por cada iteración {A}, existe una estructura de repetición que la trata. Por cada alternativa [A/B], existe una selección que la trata. Por cada cada opcional, (D), existe una selección que lo trata. Cálculo del Número de Decisiones en un Módulo: 1. Setear contador de decisiones = 0 2. Describir la estructura de datos del entorno del módulo. Analizar a nivel de data token (ver DD) 3. Realizar a) Por cada iteración, sumar 1 al contador b) Por cada selección de dos casos, sumar 1 al contador c) Por cada selección de n casos, sumar n - 1 al contador d) Por cada alternativa, sumar 1 al contador Prof. Sergio Martig Clase 5-39 Prof. Sergio Martig Clase

11 Peso del Diseño = Peso del Módulo i Peso del Diseño Peso del Módulo i = f (Tokens, ContadorDecisionesPronosticado) Un refinamiento podría ser agrupar los módulos en clases y aplicar un factor de corrección a cada clase. Por ejemplo: módulos de librerías) Los valores de la tabla deben ser personalizados para cada lenguage. Problemas con las Métricas de Diseño En muchos proyectos se abandona la etapa de diseño y se comienza con la implementación. Los malos diseños reflejan un problema de gerenciamiento. Regla: Ninguna desviación al diseño puede ser construida unilateralmente por el implememtador. Toda desviación debe ser aprobada por el diseñador Métrica de Acatamiento del Diseño = Cantidad de Decisiones Pronosticadas Cantidad de Decisiones Implementadas Prof. Sergio Martig Clase 5-41 Prof. Sergio Martig Clase 5-42 Qué más podemos medir? Métricas de Implementación Regla de Migración de Costos de De Marco: Los costos migrarán afuera de cualquier actividad que es medida más cuidadosamente que sus actividades vecinas. Peor Caso: migración de costos de desarrollo a mantenimiento. Se requiere del código una indicacion cuantitativa del trabajo faltante: testing, ensamble de versiones, documentación. Prof. Sergio Martig Clase 5-43 Prof. Sergio Martig Clase

12 Métricas de Implementación Implementación. Métricas de Volumen El código es un mensaje al computador, Lawrence Putnam. Hipótesis de Volumen: Los esfuerzos requeridos para escribir, testear y documentar un trozo de código son funciones monotónicas crecientes del volumen del trozo de código. El contenido de información de un mensaje es una función del número de piezas del mensaje y del espacio de información. Halstead describió el contenido de información de un módulo o programa en términos de su Longitud y Vocabulario. Volumen = Longitud * log 2(Vocabulario) Longitud = cantidad de los operadores usados + cantidad de los operandos usados Vocabulario = cantidad de operadores únicos usados + cantidad de los operandos únicos usados Longitud: cantidad total de palabras Vocabulario: cantidad total de palabras únicas Volumen(A + B) V olumen(a) + V olumen(b) Prof. Sergio Martig Clase 5-45 Prof. Sergio Martig Clase 5-46 Implementación. Métricas de Volumen Ejemplo: function unique (newword: shortstring; wordlist: list): boolean; var index: integer; begin unique := TRUE; for index := 1 to wordlist.count do if newword = wordlist.word[index] then unique := FALSE; end; Volumen = 30 * log 2(24) = 138 Prof. Sergio Martig Clase 5-47 Implementación. Métricas de Complejidad A) IF indicador1 THEN IF indicador2 THEN IF indicador3 THEN indicador4 := TRUE; ELSE indicador4 := FALSE; B) indicador1:= TRUE; indicador1:= TRUE; indicador1:= TRUE; MOVE(x, y); CLEARSECREEN; indicador4 := indicador3; Prof. Sergio Martig Clase

13 Implementación. Métricas de Complejidad Implementación. Métricas de Complejidad Qué es complejidad? Cómo afecta el desarrollo de SW? Puede ser prácticamente imposible brindar una solución simple a un problema complejo. Un estimador de la complejidad simplemente tiene que darnos una estimación de cuánto costará completar su estimación McCabe y Chen: representar el código como un grafo de segmentos conectados Nodos: secciones de código que se ejecutan secuencialmente. Arcos: caminos de control que unen las secciones. Prof. Sergio Martig Clase 5-49 Prof. Sergio Martig Clase 5-50 Implementación. Métricas de Complejidad Implementación. Métricas de Complejidad Chen define complejidad: Número sin unidad que representa la cantidad de intersecciones entre el grafo y una línea que conecta el exterior del mismo con todos los dominios definidos por éste. Módulos de diferente complejidad Prof. Sergio Martig Clase 5-51 Prof. Sergio Martig Clase

14 Implementación. Métricas de Complejidad Peso de la Implementación McCabe Medida Ciclomática = Cantidad de Conexiones - Cantidad de Nodos + 2, MC = = 5 Otra manera de expresarlo (número de decisiones + 1) MC = Idea: tomar medidas separadas del volumen y complejidad del código obtener un predictor llamado Peso de Implementación. Se debe corregir el Volumen con un factor que dependa de la complejidad El factor podría depender únicamente del número de decisiones. Comenzar con algo básico y mejorarlo con la experiencia. Los módulos usados y/o adaptados de librerías deberían ajustarse con un factor de corrección. Ej: Lab. De Ing. De SW de Maryland se descuenta un 22% al valor calculado. Prof. Sergio Martig Clase 5-53 Prof. Sergio Martig Clase 5-54 Cálculo del peso de la Implementación 1. Setear Peso = 0 2. Repetir para cada módulo a) Calcular Volumen b) Calcular puntos de decisión y ajustarlo con factor de complejidad c) Calcular Volumen Corregido = Volumen * Factor Complejidad a) Si el módulo es usado/adaptado de librería Ajustar Volumen Corregido con factor de corrección de descuento b) Peso = Peso + Volumen Corregido Prof. Sergio Martig Clase 5-55 Medición de Atributos Internos. Tamaño Las mediciones de tamaño generalmente se rechazan debido a: 1. Esfuerzo: no tienen en cuenta redundancia y complejidad 2. Productividad: no consideran funcionalidad y esfuerzo 3. Costo: no contabilizan complejidad y reuso El tamaño del software puede ser descripto con tres atributos: 1. Longitud: mide tamaño físico del producto. 2. Funcionalidad: mide las funciones provistas por el producto. 3. Complejidad: puede ser interpretada de distintas maneras. Prof. Sergio Martig Clase

15 Medición de Atributos Internos. Tamaño Complejidad: 1. Complejidad del Problema: del problema a resolver. 2. Complejidad del Algoritmo: del algoritmo utilizado. Eficiencia del SW. 3. Complejidad Estructural: mide la estructura del SW implementado. 4. Complejidad Cognitiva: esfuerzo requerido para entender el SW. Consenso en medir longitud de programas, pero no de especificaciones. Existen trabajos para medir funcionalidad de especificaciones. Pocos avances en medición de complejidad. Medición de Atributos Internos. Tamaño Los tres productos mas importantes cuyo tamaño sería importante medir: Especificaciones Diseño Código La medida mas comunmente usada son las líneas de código: LOC Se debe tener en cuenta: líneas en blanco, líneas de comentarios, declaración de datos y líneas que contienen varias instrucciones. Prof. Sergio Martig Clase 5-57 Prof. Sergio Martig Clase 5-58 Longitud: Líneas de Código Longitud: Líneas de Código Conte, Dunsmore & Shen: cualquier línea de texto de programa que no es comentario o línea en blanco, independientemente del número de sentencias o fragmentos de sentencias en la línea. Hewlett- Packard: una sentencia de código fuente no comentada: cualquier sentencia excepto comentarios o líneas en blanco. NCLOC - CLOC: non commented line of code - commented line of code ELOC: effective line of code longitud total LOC = NCLOC + CLOC Sería posible distinguir entre la cantidad de código entregado ( DSI: delivered source instructions) y la cantidad de código desarrollado. Formulas de Halstead: Volumen = Longitud * log2(v ocabulario) Otro enfoque es medir longitud de acuerdo a: 1. Número de bytes de almacenamiento requerido para el texto del programa. 2. Número de caracteres (CHAR) en el texto del programa. Prof. Sergio Martig Clase 5-59 Prof. Sergio Martig Clase

16 Longitud: Líneas de Código y Tamaño En programación visual, entornos de ventanas, orientación a objetos lenguages de cuarta generación cambian las nociones de tamaño. Surgen dos nuevos objetivos de medición: 1. Cómo se tienen en cuenta objetos no textuales? 2. Cómo medimos componentes construidas externamente? Pfleeger: contar objetos y métodos conduce a estimaciones más precisas. Prof. Sergio Martig Clase