3.8 METRICAS DE PROCESO Y PROYECTO

Transcripción

1 MODULO III Ingeniería de Software INF METRICAS DE PROCESO Y PROYECTO 18/06/2012 Resumen preparado por Miguel Cotaña 1

2 La medición permite obtener una visión del proceso y el proyecto pues proporciona un mecanismo para lograr una evaluación objetiva. La medición se aplica al proceso de software con la finalidad de mejorarlo de manera continua. La medición se utiliza a lo largo de un proyecto de software como apoyo en la estimación, el control de calidad, la valoración de la productividad y el control del proyecto. 2

3 Medición es una operación de asignar un valor a algo que es una medida. Métrica es una interpretación de la medida. Grado en que un sistema, componente posee un atributo dado Indicador provee una visión en cuanto al logro de objetivos. 3

4 Qué control de calidad aplicarías, por ejemplo, para comprar un par de zapatos deportivos (tennis)? 4

5 Cuando se puede medir y cuantificar aquello sobre lo que uno habla y expresarlo en números, se sabe algo acerca de eso; cuando no puede ser expresado en números el conocimiento es escaso e insatisfactorio... Lord Kelvin 5

6 Clasificación Clasificación 1: Métricas de producto. Métricas de proceso. Clasificación 2: Métricas basadas en atributos internos del producto: Medidas de estructuración de un programa. Métricas de complejidad. Métricas de cobertura de pruebas. Métricas de calidad del diseño. Métricas basadas en atributos externos del producto: Métricas de portabilidad. Métricas de defectos. Métricas de usabilidad. Métricas de mantenibilidad. Métricas de fiabilidad. 6

7 Métricas basadas en código fuente: Nº de líneas de código. Nº de líneas de comentario. Nº de instrucciones. Densidad de documentación. Métricas basadas en estructura de diseño: Relacionadas con el control intramodular. Relacionadas con el acoplamiento entre clases. Métricas para sistemas orientados a objetos: Acoplamiento. Herencia. Cohesión. 7

8 Se aplica las métricas para valorar la calidad de los productos. Proporcionan una manera sistemática de valorar la calidad basándose en un conjunto de reglas. Se aplican a todo el ciclo de vida permitiendo descubrir y corregir problemas potenciales. 8

9 Medición de los requisitos Los requisitos del Software son la base de las medidas de calidad. La falta de concordancia con los requisitos es una falta de calidad. Los productos de los requerimientos, pueden ser evaluados por el número de requerimientos. De manera similar, se puede medir la cantidad de cambios introducidos a los requerimientos. 9

10 Es conveniente registrar las medidas del tamaño de los requerimientos por tipo de requerimientos. De esta manera tenemos una idea si el cambio o la incertidumbre de los requerimientos se extiende a todo el producto o reside sólo en ciertos tipos de requerimiento. 10

11 Se pueden utilizar medidas que reflejen cuando los requerimientos están preparados para ser derivados a los ingenieros de diseño: 1. Significa que comprende por completo; 2. Existen algunos elementos nuevos, pero no son diferentes significativamente; 3. Hay elementos nuevos, pero los comprende y piensa que a partir de ellos puede realizar el diseño; 4. Existe partes que no entiende y no está seguro de hacer un buen diseño; 5. No comprende y no está en condiciones de desarrollar un buen diseño. 11

12 Factores de calidad de McCall Los factores que afectan la calidad se pueden categorizar en: Factores que se pueden medir directamente, como por ejemplo los defectos por punto de función. Factores que se pueden medir sólo indirectamente, como por ejemplo la facilidad de uso o mantenimiento. En todos los casos debe aparecer la medición. Debe ser posible comparar el software (documentos, programas, datos) con una referencia y llegar a una conclusión sobre la calidad. 12

13 Facilidad de mantenimiento Flexibilidad Facilidad de prueba Revisión del Producto Transición del producto Portabilidad Reusabilidad Interoperatividad Operación del producto Corrección Fiabilidad Usabilidad Integridad Eficiencia 13

14 Corrección HACE LO QUE QUIERO? Hasta donde satisface un programa una especificación y logra los objetivos del cliente. Fiabilidad Lo hace de forma fiable todo el tiempo? Hasta donde se puede esperar que un programa lleve a cabo su función pretendida con la exactitud requerida 14

15 Eficiencia Se ejecutará en mi HW lo mejor que se pueda? La cantidad de recursos informáticos y código necesario para que un programa realice su función. Seguridad Es seguro? Hasta donde se puede controlar el acceso al software o a los datos por personas no autorizadas. 15

16 Usabilidad Es fácil de manejar? El esfuerzo necesario para aprender, operar, preparar datos de entrada e interpretar salidas (resultados) de un programa. Facilidad de mantenimiento Puedo corregirlo? El esfuerzo necesario para localizar y arreglar un error en un programa. 16

17 Flexibilidad Puedo cambiarlo? El esfuerzo necesario para modificar un programa operativo. Facilidad de prueba Puedo probarlo? El esfuerzo necesario para probar un programa y asegurarse de que realiza la función pretendida. 17

18 Portabilidad Podré usarlo en otra máquina? El esfuerzo necesario para transferir el programa de un entorno de sistema de HW y/o SW a otro; Reusabilidad Podré reutilizar alguna parte del SW? Hasta donde se puede volver a emplear un programa (o partes de un programa) en otras aplicaciones; Interoperabilidad Podré hacerlo interactuar con otro sistema? El esfuerzo necesario para acoplar un sistema con otro. 18

19 19

20 Ejemplo: el factor de calidad Corrección tiene asociadas las métricas: Compleción (Completitud); Trazabilidad; Consistencia. Para evaluar la compleción es necesario dar respuesta a la siguiente lista de comprobación: 20

21 1. No hay referencias ambiguas [R,D,I] 2. Todas las referencias a datos definidas son calculadas u obtenidas de una fuente externa [R,D,I] 3. Todas las funciones definidas son utilizadas [R,D,I] 4. Todas las referencias a funciones están definidas [R,D,I] 5. Se han definido todas las condiciones y procesamientos para cada punto de decisión [R,D,I] 6. Concuerdan todos los parámetros de llamada a funciones definidos y referenciados [D,I] 7. Todos los informes de problemas se han resuelto [R,D,I] 8. El diseño concuerda con los requisitos [D] 9. El código concuerda con el diseño [I] 21

22 Se contesta con un SI o NO, y luego se aplica la que da como resultado el grado o nivel de calidad: C= (# SI para R/6)+(# SI para D/8)+(# SI para I/8) 3 De esta forma, la medida para la compleción es un número entre 0 y 1. La medida para la corrección, por ejemplo, se calculará (x+y+z)/3 Donde: x es la medida para la compleción, y para la trazabilidad y z para la consistencia. 22

23 Algunas métricas Facilidad de mantenimiento = (número medio de días-hombre por corrección) Portabilidad = 1 - (esfuerzo para portar / esfuerzo para implementar) Flexibilidad = (número medio de días-hombre por cambio) Fiabilidad = 1 - (número de errores/ número de líneas de código) 23

24 La fiabilidad emplea varias medidas, la primera de ellas es la probabilidad F de que aparezca un error en un tiempo determinado t, donde t > 0. La fiabilidad R es la probabilidad de que no ocurra un error en ese intervalo de tiempo: R(t) = 1 - F(t) esto supone que se estudia la fiabilidad a lo largo de un espacio continuo de tiempo 24

25 Pero, es más realista ajustarse al número de veces n que se ejecuta el programa: R(n) = 1 - dn /n donde dn es el número de fallo hallados en n ejecuciones. Si f(t) es la función de densidad de probabilidad: f(t) = df(t) / dt y f(tt) es la probabilidad de que el software falle en el intervalo (t, t + d t). 25

26 La tasa de riesgo h(t) es la probabilidad de que el software falle en (t, t + d t) si no ha fallado antes: h(t) = f(t) / ( 1 - F(t) ) de donde podemos obtener una nueva expresión para la fiabilidad del software: h(t) = f(t) / ( 1 - F(t) )= - d( ln (1 - F(t) ) ) / dt = - d ln R(t) / dt 26

27 La fiabilidad R(t) de un componente en un determinado medio durante un periodo t se define como la probabilidad de que su tiempo para fallar excede a t: R(t) = - λ*t donde: R(t)=funcionalidad de un componente; λ = tasa constante de fallo t = intervalo de tiempo R T (t)=1-[1-r1(t)][1-r2(t)]...[1-rn(t)] 27

28 Es difícil desarrollar medidas directas de los factores de calidad señalados anteriormente, se definen un conjunto de métricas para desarrollar expresiones que utilicen los factores: Fq = c1 x m1 + c2 x m2 +.+cn x mn Fq es factor de calidad cn son coeficientes de regresión mn son las métricas que afectan al factor calidad. 28

29 Lamentablemente muchas de las métricas definidas por McCall solamente pueden medirse de manera subjetiva. Las métricas se acomodan en una lista de comprobación que se emplea para puntuar atributos específicos del software. El esquema de puntuación que se propone es una escala del 0 (bajo) al 10 (alto) 29

30 Modelo de calidad ISO 9126 calidad externa e interna funcionalidad fiabilidad usabilidad eficiencia mantenibilidad portabilidad adecuación exactitud interoperabilidad seguridad de acceso cumplimiento de la funcionalidad madurez tolerancia a fallos capacidad de recuperación cumplimiento de la fiabilidad capacidad para ser entendido capacidad para ser aprendido capacidad para ser operado capacidad de atracción cumplimiento de la usabilidad comportamiento temporal utilización de recursos cumplimiento de la eficiencia capacidad para ser analizado capacidad para ser cambiado estabilidad capacidad para ser probado cumplimiento de la mantenibilidad adaptabilidad instalabilidad coexistencia capacidad para ser reemplazado cumplimiento de la portabilidad 30

31 ISO 9126 Funcionalidad Eficiencia Transportabilidad CALIDAD Fiabilidad Mantenibilidad Usabilidad 31

32 Factores de calidad de Boehm 32

33 Métricas en los dominios del proceso y el proyecto Las métricas del proceso se recopilan en el curso de todos los proyectos y durante largos periodos. Su objetivo es proporcionar un conjunto de indicadores de proceso que conduzcan a la mejora de los procesos de software a largo plazo 33

34 Las métricas del proyecto permiten que un gestor de proyecto de software: 1) Valore el estado de un proyecto en curso; 2) Rastree los riesgos potenciales; 3) Descubra las áreas problema antes de que se vuelvan críticas ; 4) Ajuste el flujo de trabajo o las tareas; 5) Evalué la habilidad del equipo. 34

35 Métricas del proceso y mejora del proceso Sw La única forma racional de mejorar cualquier proceso es medir sus atributos específicos, desarrollar un conjunto de métricas significativas con base en dichos atributos y luego emplear las métricas para ofrecer indicadores que conducirán a una estrategia de mejora. 35

36 Producto Características del cliente Condiciones del negocio proceso Personal Entorno de desarrollo Tecnología 36

37 Algunas métricas de proceso son privadas para el equipo del proyecto de software, pero públicas para todos los miembros del equipo. Las métricas públicas por lo general asimilan información que originalmente era privada para los individuos y equipo 37

38 La métricas de proceso de software ofrecen beneficios significativos conforme una organización trabaja en mejor grado global de madurez del proceso. Sin embargo, como todas las métricas, éstas pueden emplearse mal y crear más problemas de los que solucionan 38

39 Grady, sugiere las siguientes reglas: Aplique sentido común y sensibilidad organizativa cuando interprete datos métricos; Ofrezca retroalimentación regular a los individuos y equipos que recopilan medidas y métricas; No utilice las métricas para evaluar a los individuos; 39

40 Trabaje con los profesionales y equipos para establecer metas claras y las métricas que se emplearán para conseguirlas; Nunca use métricas para amenazar a los individuos o equipos; Los datos métricos que indican un área problema no deben considerarse negativos; No obsesionarse con una sola métrica. 40

41 Métricas del proyecto A diferencia de las métricas del proceso de software que se utilizan con propósitos estratégicos, las métricas del proyecto de software son tácticas. Es decir, un gerente de proyecto y un equipo de software emplean las métricas del proyecto y los indicadores que se deducen de ellas para adaptar el flujo de trabajo del proyecto y las actividades técnicas 41

42 La primera aplicación de las métricas del proyecto ocurre durante la estimación. Las métricas recopiladas de los proyectos previos se aprovechan como base desde la cual se realizan estimaciones de esfuerzo y tiempo. Conforme el proyecto avanza, las medidas de esfuerzo y tiempo utilizados se comparan con originales 42

43 Mientras comienza el trabajo técnico, las otras métricas comienzan a tener significado. Se miden los índices de producción representados en términos de modelos creados, hora de revisión, puntos de función y líneas fuente entregadas. Además, se les da seguimiento a los errores descubiertos durante cada tarea de IS. 43

44 Conforme el software evoluciona desde los requisitos hasta el diseño, se recopilan métricas técnicas para valorar la calidad del diseño y mejorar los indicadores que influirán en el enfoque que se adopte para la generación y prueba del código. 44

45 Medición del software Se clasifican en 2 categorías: 1. Medidas indirectas del producto que influyen funcionalidad, calidad, complejidad, eficiencia, confiabilidad, facilidad de mantenimiento, etc. 2. Medidas directas del proceso de software (costo, esfuerzo aplicados) y del producto (líneas de código, rapidez de ejecución y defectos reportados); 45

46 Ejemplo Supongamos una empresa de software que lleva a cabo un proyecto de desarrollo de un sistema X. En un determinado momento el líder del proyecto necesita conocer el nivel de productividad de los programadores del proyecto en comparación con lo habitual en otros proyectos: 46

47 Las métricas a utilizar podrían ser: Directas: LCF (líneas de código fuente escritas). El método de medición es contar las líneas utilizando una herramienta CASE. HPD (horas-programador diarias). El método de medición es que el líder del proyecto anota cada día las horas dedicadas por los programadores al proyecto. CHP (coste por hora-programador, en unidades monetarias). El método de medición es consultar el plan del proyecto, donde se tuvo que indicar este valor, previa consulta a un responsable de personal. 47

48 Indirectas: HPT (horas-programador totales). La función de cálculo es un sumatorio de las HPD de cada día: [métrica indirecta definida en base a sólo 1 métrica directa]. LCFH (líneas de código fuente por hora de programador). La función de cálculo es una simple división: LCFH = LCF / HPT [métrica indirecta definida en base a 2 métricas directas]. CTP (coste total actual del proyecto, en unidades monetarias). La función de cálculo establece que el CTP es el producto del coste unitario de cada hora por el total de horas empleadas: CTP = CHP * HPT [métrica indirecta definida en base a 2 métricas, una directa y otra indirecta]. CLCF (coste por línea de código fuente). CLCF = LCF/CTP. 48

49 Indicadores: PROD (productividad de los programadores). El modelo de análisis utiliza los valores de las métricas LCF, HPT, LCFH y CTP para establecer un valor cualitativo de la productividad de los programadores en este proyecto. El modelo se basa en extraer de una base histórica de proyectos de la organización los valores medios de LCF, HPT, LCFH (LCFHvm) y CTP del subconjunto de proyectos similares (aquellos que tienen LCF entre el 80% y el 120% ). Los criterios de decisión establecidos son: LCFH/LCFHvm < 70% => PROD= muy baja. 70% LCFH/LCFHvm < 90% => PROD= baja. 90% LCFH/LCFHvm < 110% => PROD= normal. 110% LCFH/LCFHvm < 130% => PROD= alta. 130% LCFH/LCFHvm => PROD= muy alta. 49

50 Métricas orientadas al tamaño Las métricas del software orientadas al tamaño preceden de la normalización de las medidas de calidad o productividad considerando el tamaño de software que se ha producido. Si una organización de software mantiene registros simples es factible crear una tabla de medidas orientadas al tamaño. 50

51 Proyecto LDC esfuerzo $ Pag.doc errores defectos personal Beta Alfa Gamma El desarrollo de métricas que se asimilen con métricas similares procedentes de otros proyectos requiere elegir líneas de código con valor de normalización

52 A partir de los datos rudimentarios de la tabla se desarrolla un conjunto de métricas simples orientadas al tamaño para cada proyecto. La métricas orientadas al tamaño no se aceptan universalmente como la forma de medir el proceso del software 52

53 Métricas orientadas a la función Las métricas del software orientadas a la función emplean como un valor de normalización una medida de la funcionalidad que entrega la aplicación. La métrica orientada a la función utilizada con mayor amplitud es el punto de función (PF). El cálculo del PF se basa en características del dominio de información y la complejidad del software 53

54 La métrica del punto de función (PF) se puede utilizar como medio para predecir el tamaño de un sistema obtenido a partir de un modelo de análisis. Para visualizar esta métrica se utiliza un diagrama de flujo de datos, el cual se evalua para determinar las siguientes medidas clave que son necesarias para el cálculo de la métrica de punto de función: 54

55 Número de entradas del usuario; Número de salidas del usuario; Número de consultas del usuario; Número de archivos; Número de interfaces externas. 55

56 Entradas: Pantallas o formularios a través de los cuales usuarios humanos de una aplicación u otros programas agregan nuevos datos o actualizan datos existentes. Si una pantalla de entrada es muy grande para ser desplegada de una vez (asumiendo 80 columnas y 25 líneas) y requiere de una segunda pantalla, el conjunto cuenta como una (1) sola entrada. Se deben considerar entradas que requieren procesamiento único. 56

57 Salidas: Pantallas o informes que la aplicación produce para uso humano o para otros programas. Las salidas que requieren procesamiento separado deben ser contabilizadas: en una aplicación de remuneraciones una función de salida que genere 100 cheques contaría como una sola salida. Ej: pantallas, informes impresos, archivos en disco, sets de cheques, facturas impresas. 57

58 Las consultas se dividen en dos partes: la porción de entrada y la porción de salida. Ejemplos de consultas: consulta de un usuario sin actualizar un archivo, mensajes de ayuda, mensajes de selección. Una consulta típica sería una relacionada con una reservación aérea. Pantallas que le permiten a los usuarios interrogar una aplicación y solicitar asistencia o información, tal como pantallas de ayuda (HELP). 58

59 Archivos internos lógicos: Colección lógica de registro que la aplicación modifica o actualiza una tabla de una base de datos. Archivos externos de interfaz: bases de datos compartidas, archivos lógicos direccionables desde o hacia otra aplicación. Es un conjunto de datos definidos por el usuario, que están relacionados lógicamente y que sólo son usados para propósitos de referencia. 59

60 CGS Factores de influencia FI.1 comunicación de datos FI.2 funciones distribuidas FI.3 objetivos de performance FI.4 configuración usada fuertemente FI.5 tasa de transacciones FI.6 entrada de datos en línea FI.7 eficiencia del usuario final FI.8 actualización en línea FI.9 procesamiento complejo FI.10 reusabilidad FI.11 facilidad de instalación FI.12 facilidad operacional FI.13 sitios múltiples FI.14 facilitamiento del cambio 60

61 Escala de evaluación 0 factor no presente o sin influencia 1 influencia insignificante 2 influencia moderada 3 influencia promedio 4 influencia significativa 5 influencia fuerte 61

62 Comunicación de datos: implica que datos y/o información de control son enviadas o recibidas. La evaluación es un 0 para aplicaciones batch, y un 5 para aplicaciones en que predomina el teleproceso; Funciones distribuidas: analiza si una aplicación es monolítica y opera en un solo procesador o si es distribuida. 0 para aplicaciones monolíticas y un 5 para aplicaciones que se ejecutan dinámicamente en varios procesadores; 62

63 Objetivos de performance: la evaluación sería un 0 si no hay establecido ningún criterio especial de performance, y un 5 si los usuarios insisten en objetivos de performance muy rigurosos que requieren un esfuerzo; Configuración usada fuertemente: la evaluación sería un 0 si la aplicación no tiene restricciones especiales de uso, y un 5 si el uso anticipado requiere especial esfuerzo para ser logrado; 63

64 Tasa de transacciones: la evaluación sería un 0 si el volumen de transacciones no es significativo, y un 5 si el volumen es lo suficientemente significativo como para producir stress en la aplicación y requerir un esfuerzo especial para alcanzar throughputs deseados; Entrada de datos en línea: la evaluación sería un 0 si menos del 15% de las transacciones son interactivas, y un 5 si más del 50% de las transacciones son interactivas 64

65 Eficiencia del usuario final: la evaluación sería un 0 si no hay usuarios finales o no hay requerimientos especiales para los usuarios finales, y un 5 si los requerimientos de eficiencia de usuarios finales son lo suficientemente rígidos como para requerir un esfuerzo; Actualización en línea: la evaluación sería 0 si no hay, y un 5 si las actualizaciones son obligatorias y especialmente difíciles; 65

66 Procesamiento complejo: la evaluación sería 0 si no hay, y un 5 en casos que requieren decisiones lógicas extensas, matemática compleja, procesamiento de excepciones; Reusabilidad: la evaluación sería un 0 si la funcionalidad se planifica, y un 5 si mucha de la funcionalidad y los artefactos del proyecto se pretende que sean usados ampliamente por otras aplicaciones; 66

67 Facilidad de instalación: la evaluación sería un 0 si este factor es insignificante, y un 5 si la instalación es importante y tan restrictiva que requiere un esfuerzo especial para cumplirla satisfactoriamente; Facilidad operacional: la evaluación sería un 0 si este factor es insignificante, y un 5 si la facilidad operacional es tan restrictiva que requiere un esfuerzo especial para alcanzarla; 67

68 Sitios múltiples: la evaluación sería un 0 si hay solo un sitio planificado de uso, y un 5 si el proyecto y sus artefactos se pretenden sean usados en muchos lugares; Facilitamiento del cambio: la evaluación sería un 0 si el cambio no ocurre, y un 5 si la aplicación se desarrolla específicamente para permitir a los usuarios finales el hacer cambios rápidos para controlar datos o tablas que ellos mantienen con la ayuda de la aplicación. 68

69 La cuenta total debe ajustarse utilizando la siguiente ecuación: PF = c-total x (0,65 + 0,01 x Fi) Donde c-total es la suma de todas las entradas PF obtenidas y Fi (i=1 a 14) son los "valores de ajuste de complejidad". 69

70 Se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente: PF = 50 x (0,65 + 0,01 x 46) = 56 Factor de ponderación Parámetro de medición Cuenta Simple Media Compl. Número de entradas del usuario 3 X = 9 Número de salidas del usuario 2 X = 8 Número de consultas del usuario 2 X = 6 Número de archivos 1 X = 7 Número de interfaces externas 4 X = 20 Cuenta total 50 Cálculo de puntos de función 70

71 Métricas orientadas a objetos Las métricas de proyectos de software convencionales (LDC o PF) se aplican en la estimación de proyectos de software OO. Sin embargo, estas métricas no proporcionan suficiente granularidad para la planificación y los ajustes de esfuerzo que se requieren conforme se itera a lo largo de un proceso evolutivo o incremental. 71

72 Lorenz y Kidd, sugieren el siguiente conjunto de métricas OO: Número de guiones de escenario. Es una secuencia detallada de pasos que describen la interacción entre el usuario y la aplicación; Número de clases clave. Son los componentes enormemente independientes definidos con antelación en análisis OO; 72

73 Número de clases de apoyo. Es un indicio de la cantidad de esfuerzo indispensable para desarrollar el software, así como un indicio de la cantidad de reutilización; Número promedio de clases de apoyo por clase clave. Las clases clave se conocen en etapas iníciales. Las clases de apoyo se definen a lo largo del curso de éste; Número de subsistemas. 73

74 Métricas orientadas a casos de uso Los casos de uso se define en etapas tempranas del proceso de software, lo que permite emplearlo en la estimación antes de iniciar las actividades significativas de modelado y construcción. Los casos de uso describen (al menos indirectamente) funciones y características visibles al usuario que son requisitos básicos para un sistema 74

75 El caso de uso es independiente del lenguaje de programación. Además, el número de casos de uso es directamente proporcional al tamaño de la aplicación en LDC, así como al número de casos de prueba que tendrán que diseñarse para ejercitar completamente la aplicación. 75

76 Métricas de proyectos de IWeb Entre las medidas que se pueden recopilar son: Número de páginas web estáticas; Número de páginas web dinámicas; Número de vínculos internos de página; Número de objetos de datos persistentes; 76

77 Número de sistemas externos en interfaz; Número de objetos de contenido estático; Número de objetos de contenido dinámico; Número de funciones ejecutables. 77

78 Métricas para calidad del software La meta primordial de la IS es producir un sistema, aplicación o producto de alta calidad dentro de un marco temporal que satisfaga una necesidad del mercado. El logro de esta meta requiere que los IS apliquen métodos eficaces acoplados con herramientas modernas. Además se debe medir si se logrará la alta calidad. 78

79 Se pueden utilizar muchas medidas de calidad, el impulso primario, es medir los errores y defectos. Las métricas derivadas de estas medidas proporcionan un indicio de la efectividad de la garantía de la calidad del software y de las actividades de control tanto de los individuos como del grupo. 79

80 Las métricas como los errores en el producto de trabajo por punto de función, errores descubiertos por hora de revisión de la eficacia de cada una de las actividades implicadas en la métrica. Los datos de error también se pueden emplear en el cálculo de la eficacia en la eliminación de defectos (EED) 80

81 Medición de la calidad Los indicadores útiles para el equipo de proyecto son: Corrección. La medida más común para la corrección es defectos por KLDC, donde un defecto se define como una falta comprobada de concordancia con los requisitos. Cuando se considera la calidad global de un producto, los defectos son los problemas que reporta el usuario después que se liberó. 81

82 Facilidad de mantenimiento. Es la sencillez con la que un programa puede corregirse si se encuentra un error, adaptarse si su entorno cambia, o mejorar si el cliente desea un cambio en los requisitos. No existe forma de medir directamente, por lo que se emplean medidas indirectas. Una simple medida orientada al tiempo es el tiempo medio de cambio (TMC) 82

83 Integridad. Mide la habilidad de un sistema para resistir ataques a su seguridad. La medición de la integridad requiere definir: amenaza y seguridad. La integridad de un sistema se define: Integridad = 1- (amenaza x (1-seguridad)) Si la probabilidad de amenaza es 0.50 y la posibilidad de repeler un ataque es sólo 0.25, la integridad es 0.63 (inaceptablemente baja). 83

84 Facilidad de uso. Con frecuencia, un programa que no es fácil de usar está condenado al fracaso, incluso si las funciones que realiza son valiosas. Es un intento por cuantificar la sencillez de la aplicación al utilizarla y se puede medir en términos de características 84

85 Eficacia en la eliminación de defectos Una métrica de calidad que ofrece beneficios tanto en ámbito del proyecto como en el proceso es la eficacia en la eliminación de defectos (EED). En esencia, la EED es la medida de la habilidad de filtrar las actividades de la garantía de cualidad y de control conforme se aplica a través de las actividades del marco de trabajo. 85

86 Cuando se considera un proyecto como un todo, la EED se define: EED = E/(E+D) E es el número de errores encontrados antes de entregar el software. D es el número de defectos encontrados después de la carga. El valor ideal de la EED es 1 86

87 La EED también se puede aplicar en el proyecto para valorar la habilidad de un equipo de encontrar errores antes de que pasen a la siguiente actividad. Por ejemplo, la tarea de análisis de requisitos produce un modelo de análisis que se revisa para encontrar y corregir errores. Si no se encuentran errores pasan al diseño. 87

88 Cuando se aplica en este contexto la EED se redefine como: EED i = Ei/(E i +D i+1 ) E i es el número de errores encontrados durante la actividad i de la IS. E i+1 es el número de errores encontrados durante la actividad i+1 de IS que se puede seguir para llegar a errores que no fueron descubiertos en la actividad i de IS 88

89 Integración de las métricas dentro del proceso de Sw La mayoría de los desarrolladores de software todavía no miden y, lamentablemente, muchos tienen poco deseo de comenzar. El problema es cultural!!! 89

90 Argumentos para las métricas del software Si no se mide, no existe una forma real de determinar si se está mejorando. Y si no se mejora, se está perdido. Si se emplea la medición para establecer una línea base del proyecto, cada uno de los temas: desarrollar estimaciones de proyecto significativas, producir sistemas de calidad, tener el producto a tiempo, se vuelven más manejables. 90

91 Establecimiento de una línea base Los datos de la línea base deben tener los siguientes atributos: Los datos deben ser razonablemente precisos; Los datos deben recopilarse para tantos proyectos como sea posible; Las medidas deben ser consistentes; Las aplicaciones deben ser similares al trabajo que se estimará. 91

92 Recopilación, cálculo y evaluación de métricas La recopilación de datos requiere una investigación histórica de los proyectos previos para reconstruir los datos requeridos Proceso de IS Proyecto Recopilacion medidas de SW de datos Cálculo de métricas Producto métricas Evaluación de SW Métricas indicadores 92