1 Pasos a realizar en un estudio de evaluación Dos pasos clave en cualquier proyecto de evaluación son: – Seleccionar la técnica de evaluación. – Seleccionar las métricas.

2 Cuando Evaluar Proceso de Desarrollo Aplicaciones puesta en producción Adquisición de Aplicaciones

3 La evaluación estática (conocida con el nombre genérico de Revisiones) se realiza en paralelo al proceso de construcción, constando de una actividad de evaluación emparejada con cada actividad de desarrollo. Es decir, la actividad de Definición de Requisitos de Usuario va acompañada de una actividad de Revisión de Requisitos de Usuario, la actividad de Definición de Requisitos Software va emparejada con su correspondiente actividad de revisión y así, sucesivamente. Proceso en Desarrollo - EVALUACI Ó N EST Á TICA

4 Las actividades de revisión marcan el punto de decisión para el paso a la siguiente actividad de desarrollo. Es decir, la actividad de requisitos interactúa con la actividad de revisión de requisitos en un bucle de mejora iterativa hasta el momento en que la calidad de los requisitos permite abordar la subsiguiente fase de desarrollo. Lo mismo ocurre con el diseño arquitectónico: sufrirá una mejora iterativa hasta que su nivel de calidad permita pasar al diseño detallado y así, sucesivamente. Nótese que esto también ocurre en la fase de codificación. T É CNICAS DE EVALUACI Ó N EST Á TICA

5

6 BENEFICIOS DE LAS REVISIONES La raz ó n para buscar defectos en software temprano es porque é stos se traducen en defectos en el software final. Defectos en los requisitos se traducir á n en defectos en el sistema final.

7 T É CNICAS DE EVALUACI Ó N EST Á TICA BENEFICIOS DE LAS REVISIONES Si un dise ñ o contiene defectos, seguramente estos defectos se trasmitir á n al c ó digo cuando los programadores usen ese dise ñ o como gu í a para su trabajo. La detecci ó n temprana de errores acarrea grandes beneficios. Si las revisiones ú nicamente se aplican al c ó digo mejoran la calidad y producen ahorros en los costos del proyecto.

8 T É CNICAS DE EVALUACI Ó N EST Á TICA BENEFICIOS DE LAS REVISIONES Los resultados publicados sobre ahorros con las revisiones afirman que la utilizaci ó n de inspecciones de c ó digo produce un ahorro del 39% sobre el coste de detectar y corregir defectos, frente a ú nicamente utilizar la evaluaci ó n din á mica. La experiencia demuestra que entre el 30% y el 70% de los defectos, de dise ñ o y c ó digo son detectados por las t é cnicas est á ticas.

9 T É CNICAS DE EVALUACI Ó N EST Á TICA BENEFICIOS DE LAS REVISIONES Esto crea un gran ahorro, pues la correcci ó n es m á s f á cil y menos costosa durante la evaluaci ó n est á tica que durante la din á mica. Cuando durante la evaluaci ó n din á mica del sistema se detecta un fallo en un programa, lo que se detecta es el fallo, no la falta que lo provoca. Es decir, tras la detecci ó n del fallo, se requiere una labor de localizaci ó n en el programa de la falta que provoc ó el fallo.

10 T É CNICAS DE EVALUACI Ó N EST Á TICA BENEFICIOS DE LAS REVISIONES Con las t é cnicas est á ticas, lo que se detecta son directamente faltas. Por tanto, una vez detectada, se puede pasar a la fase de correcci ó n. Es decir, desaparece la tarea de localizaci ó n de la falta. Esto significa, que las t é cnicas est á ticas son m á s baratas por falta que las din á micas.

11 T É CNICAS DE EVALUACI Ó N EST Á TICA BENEFICIOS DE LAS REVISIONES Las revisiones tambi é n proporcionan beneficios m á s Generales tales como: oEvaluaci ó n del progreso del proyecto oPotencia las capacidades de los participantes oMejoran la comunicaci ó n entre el equipo de desarrollo, aumentando su motivaci ó n, pues los software pasan a ser documentos p ú blicos. oProporciona aprendizaje, retroalimentaci ó n y prevenci ó n.

12 T É CNICAS DE EVALUACI Ó N EST Á TICA OBJETIVOS La evaluaci ó n est á tica de los distintos software que se generan en el desarrollo de software (especificaci ó n de requisitos, modelos conceptuales, dise ñ o, c ó digo, etc.) pretende comprobar su calidad.

13 T É CNICAS DE EVALUACI Ó N EST Á TICA OBJETIVOS Los defectos que se buscan al evaluar estáticamente los software son: Para los Requisitos Para el Diseño Para el Código Fuente

14 OBJETIVOS: Para los requisitos Correcci ó n: Los requisitos especifican correctamente lo que el sistema debe hacer. Es decir, un requisito incorrecto es un requisito que no cumple bien su funci ó n, un requisito incorrecto ser á aquel que indica incorrectamente lo que debe hacer el sistema. Compleci ó n: Especificaci ó n completamente el problema. Est á especificado todo lo que tiene que hacer el sistema y no incluye nada que el sistema no deba hacer. En dos palabras: no falta nada; no sobra nada.

15 OBJETIVOS: Para los requisitos Consistencia. No hay requisitos contradictorios. Ambig ü edad. Los requisitos no pueden estar sujetos a interpretaci ó n. Si fuese as í, un mismo requisito puede ser interpretado de modo distinto por dos personas diferentes y, por tanto, crear dos sistemas distintos. Si esto es as í, los requisitos pierden su valor pues dejan de cumplir su funci ó n (indicar qu é debe hacer el sistema). Claridad. Se entiende claramente lo que está especificado.

16 OBJETIVOS: Para el Dise ñ o Correcci ó n: El dise ñ o no debe contener errores. Los errores de correcci ó n se pueden referir a dos aspectos. Defectos de “ escritura ”, es decir, defectos en el uso de la notaci ó n de dise ñ o empleada (el dise ñ o contiene detalles prohibidos por la notaci ó n). Defectos con respecto a los requisitos: el dise ñ o no realiza lo que el requisito establece.

17 Compleci ó n: El dise ñ o debe estar completo. Ya sea que dise ñ a todo el sistema marcado por los requisitos; ya sea no dise ñ ando ninguna parte no indicada en los requisitos. De nuevo, nada falta, nada sobra. Consistencia: Al igual que en los requisitos, el dise ñ o debe ser consistente entre todas sus partes. No puede indicarse algo en una parte del dise ñ o, y lo contrario en otra. OBJETIVOS: Para el Diseño

18 Factibilidad: El dise ñ o debe ser realizable. Debe poderse implementar. Trazabilidad: Se debe poder navegar desde un requisito hasta el fragmento de dise ñ o donde é ste se encuentra representado. OBJETIVOS: Para el Diseño

19 OBJETIVOS: Para el C ó digo Fuente Correcci ó n: El código no debe contener errores. Defectos de escritura: es decir, lo que habitualmente se conoce por “programa que no funciona”. Por ejemplo, bucles infinitos, variable definida de un tipo pero utilizada de otro, contador que se sale de las dimensiones de un array, etc. Defectos con respecto al diseño: el código no realiza lo que el diseño establece.

20 Compleci ó n: El código debe estar completo. Una vez más, nada falta ni nada sobra (con respecto, en este caso, al código). Consistencia: Al igual que en los requisitos y diseño, el código debe ser consistente entre todas sus partes. No puede hacerse algo en una parte del código, y lo contrario en otra. Trazabilidad: Se debe poder navegar desde un requisito hasta el fragmento de código donde éste se ejecute, pasando por el fragmento de diseño. OBJETIVOS: Para el C ó digo Fuente

21 Tipos de Revisiones: Revisiones informales Tambi é n llamadas inadecuadamente s ó lo Revisiones (lo cual genera confusi ó n con el nombre gen é rico de todas estas t é cnicas). Las Revisiones Informales no dejan de ser un intercambio de opiniones entre los participantes.

22 Tipos de Revisiones: Revisiones formales o Inspecciones. En las Revisiones Formales, los participantes son responsables de la fiabilidad de la evaluaci ó n, y generan un informe que refleja el acto de la revisi ó n. Por tanto, s ó lo consideramos aqu í como t é cnica de evaluaci ó n las revisiones formales, puesto que las informales podemos considerarlas un antepasado poco evolucionado de esta misma t é cnica.

23 Tipos de Revisiones: Walkthrough (Recorrido): Es una revisi ó n que consiste en simular la ejecuci ó n de casos de prueba para el programa que se est á evaluando. De hecho, con los walkthrough se recorre el programa imitando lo que har í a la computadora.

24 Tipos de Revisiones: Auditorias: Las auditorias contrastan los software generados durante el desarrollo con est á ndares, generales o de la organizaci ó n. T í picamente pretenden comprobar formatos de documentos, inclusi ó n de toda la informaci ó n necesaria, etc. Es decir, no se tratan de comprobaciones t é cnicas, sino de gesti ó n o administraci ó n del proyecto.

25 Inspecciones Las inspecciones de software son un m é todo de an á lisis est á tico para verificar y validar un software manualmente. Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas analiza un software usando una t é cnica de lectura con el prop ó sito de detectar defectos. El objetivo principal de una inspecci ó n es detectar faltas antes de que la fase de prueba comience.

26 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecci ó n: Las Inspecciones constan de dos partes: la comprensi ó n del software que se inspecciona y la b ú squeda de faltas en dicho software. M á s concretamente, una inspecci ó n tiene cuatro fases principales: 1. Inicio 2. Detecci ó n de defectos 3. Colecci ó n de defectos 4. Correcci ó n y seguimiento

27 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones: Inicio – El objetivo es preparar la inspecci ó n y proporcionar la informaci ó n que se necesita sobre el software para realizar la inspecci ó n. Detecci ó n de defectos – Cada miembro del equipo realiza individualmente la lectura del material, compresi ó n del software a revisar y la detecci ó n de faltas. Bas á ndose en las faltas detectadas cada miembro debe realizar una estimaci ó n subjetiva del n ú mero de faltas remanentes en el software.

28 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones. Etapa de Inicio: Subfase Planificaci ó n. Se deben seleccionar los participantes, asignarles roles, preparar un calendario para la reuni ó n y distribuir el material a inspeccionar. Los papeles que existen en una inspección son: Organizador. Planifica las actividades de inspección en un proyecto, o incluso en varios proyectos. Moderador. El moderador debe garantizar que se sigan los procedimientos de la inspección así como que los miembros del equipo cumplan sus responsabilidades.

29 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones. Etapa de Inicio: Subfase Planificaci ó n. Inspector. Los inspectores son los responsables de detectar defectos en el producto software bajo inspección. Lector/Presentador. Durante la reunión para la inspección en grupo, el lector dirigirá al equipo a través del material de modo completo y lógico, lo que significa que debe explicar e interpretar el producto.

30 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones. Etapa de Inicio: Subfase Planificaci ó n. Autor. El autor es la persona que ha desarrollado el producto que se esta inspeccionando y es el responsable de la corrección de los defectos durante la fase de corrección. Escriba. El secretario o escriba es responsable de incorporar todos los defectos en una lista de defectos durante la reunión. Recolector. El recolector recoge los defectos encontrados por los inspectores en caso de no haber una reunión de inspección.

31 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones. Etapa de Inicio: Subfase Planificaci ó n. Un equipo de inspección nunca debería contar con más de cinco miembros. El número mínimo de participantes son dos Los candidatos principales para actuar como inspectores es el personal involucrado en el desarrollo del producto. Los inspectores deben tener un alto grado de experiencia y conocimiento.

32 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones. Etapa de Inicio: Subfase Lanzamiento. Consiste en una primera reunión donde el autor explica el producto a inspeccionar a los otros participantes. El objetivo principal de esta reunión de lanzamiento, es facilitar la comprensión e inspección a los participantes. Es recomendable realizar esta reunión: 1.) Cuando el producto a inspeccionar es complejo y difícil de comprender. 2.) Cuando el producto a inspeccionar pertenece a un sistema software de gran tamaño.

33 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones: Colecci ó n de defectos – El registro de las faltas encontrada por cada miembro del equipo es compilado en un solo documento que servir á de base a la discusi ó n sobre faltas que se realizar á en grupo. Utilizando como base las faltas comunes encontradas por los distintos inspectores se puede realizar una estimaci ó n objetiva del n ú mero de faltas remanentes.

34 T É CNICAS DE EVALUACI Ó N EST Á TICA Proceso de Inspecciones: Correcci ó n y seguimiento – El autor del software inspeccionado debe corregir las faltas encontradas e informar de las correcciones realizadas a modo de seguimiento.

35 T É CNICAS DE EVALUACI Ó N EST Á TICA Estimaci ó n de los Defectos Remanentes: A pesar de que el propósito principal de las Inspecciones es detectar y reducir el número de defectos, un efecto colateral pero importante es que permiten realizar desde momentos muy iniciales del desarrollo predicciones de la calidad del producto.

36 T É CNICAS DE EVALUACI Ó N EST Á TICA Estimaci ó n de los Defectos Remanentes: Concretamente, las estimaciones de las faltas remanentes tras una inspección deben utilizarse como control de la calidad del proceso de desarrollo. Hay varios momentos de estimación de faltas remanentes en una inspección.

37 T É CNICAS DE EVALUACI Ó N EST Á TICA Estimaci ó n de los Defectos Remanentes: Al realizar la b ú squeda individual de faltas, el inspector puede tener una idea de las faltas remanentes en base a las siguientes dos situaciones: Encontrar muchas faltas es sospechoso ya que muchas faltas detectadas hacen pensar que debe haber muchas más. Encontrar muy pocas faltas tambi é n resulta sospechoso, especialmente si es la primera vez que se inspecciona este producto.

38 T É CNICAS DE EVALUACI Ó N EST Á TICA Estimaci ó n de los Defectos Remanentes: La estimaci ó n m á s fiable sobre el n ú mero de faltas remanentes que se puede obtener en una Inspecci ó n es la coincidencia de faltas entre los distintos inspectores. Los m é todos que explotan coincidencias para estimar se llaman Estimaciones Captura-Recaptura y no son originarias de la Ingenier í a del Software. En el caso de las Inspecciones, el nivel de coincidencia de las faltas detectadas por los distintos revisores es usado como estimador

39 T É CNICAS DE EVALUACI Ó N EST Á TICA T é cnicas de Lectura: Las t é cnicas de lectura son gu í as que ayudan a detectar defectos en los productos software. T í picamente, una t é cnica de lectura consiste en una serie de pasos o procedimientos cuyo prop ó sito es que el inspector adquiere un conocimiento profundo del producto software que inspecciona. Las t é cnicas de lectura m á s populares son la lectura Ad-hoc y la Lectura basada en listas de comprobaci ó n.

40 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA SIN CHECKLISTS En esta t é cnica el producto software se entrega a los inspectores sin ninguna indicaci ó n o gu í a sobre c ó mo proceder con el producto ni qu é buscar. Por eso la denominamos tambi é n c ó mo Lectura sin Checklists. El t é rmino "ad-hoc" s ó lo se refiere al hecho de no proporcionar apoyo a los inspectores.

41 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA SIN CHECKLISTS La detecci ó n de los defectos depende completamente de las habilidades, conocimientos y experiencia del inspector. El inspector deber á buscar secuencialmente los defectos t í picos del producto que est é leyendo (y que hemos indicado m á s arriba). Si se est á inspeccionando unos requisitos, el inspector, buscar á sistem á tica y secuencialmente defectos de correcci ó n, de completud, de ambig ü edad, etc.

42 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA SIN CHECKLISTS TALLER: Revisar y Buscar los requisitos con defecto del caso a continuación sin guía alguna acorde a la lista de criterios de calidad que debe cumplir los requisitos tales como: Corrección: Compleción: Consistencia Ambigüedad Claridad.

43 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Proporciona un apoyo mayor mediante preguntas que los inspectores deben de responder mientras leen el artefacto. Es decir, esta técnica proporciona listas que ayudan al inspector a saber qué tipo de faltas buscar. Aunque una lista supone más ayuda que nada, esta técnica presenta la debilidad de que las preguntas proporcionan poco apoyo para ayudar a un inspector a entender el producto inspeccionado.

44 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Las preguntas son a menudo generales y no suficientemente adaptadas a un entorno de desarrollo particular. Finalmente, las preguntas en una lista de comprobaci ó n est á n limitadas a la detecci ó n de defectos de un tipo determinado, t í picamente de correcci ó n, puesto que las listas establecen errores universales

45 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para Requisitos: ¿ Existen contradicciones en la especificaci ó n de los requisitos? ¿ Resulta comprensible la especificaci ó n? ¿ Est á especificado el rendimiento? ¿ Puede ser eliminado alg ú n requisito? ¿ Pueden juntarse dos requisitos? ¿ Son redundantes o contradictorios? ¿ Se han especificado todos los recursos hardware necesarios? ¿ Se han especificado las interfaces externas necesarias? ¿ Se han definido los criterios de aceptaci ó n para cada una de las funciones especificadas?

46 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para Requisitos: Los requisitos necesitan ser evaluados de forma cr í tica para prevenir errores. En esta fase radica la calidad del producto software desde la perspectiva del usuario. Si la evaluaci ó n en general es dif í cil, la de los requisitos en particular lo es m á s, debido a que lo que se eval ú a es la definici ó n del problema.

47 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Diseño: ¿ Cubre el dise ñ o todos los requisitos funcionales? ¿ Resulta ambigua la documentaci ó n del dise ñ o? ¿ Se ha aplicado la notaci ó n de dise ñ o correctamente? ¿ Se han definido correctamente las interfaces entre elementos del dise ñ o? ¿ Es el dise ñ o suficientemente detallado como para que sea posible implementarlo en el lenguaje de programaci ó n elegido?

48 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: L ó gica del Programa ¿ Es correcta la l ó gica del programa? ¿ Est á completa la l ó gica del programa?, es decir, ¿ est á todo correctamente especificado sin faltar ninguna funci ó n?

49 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: Interfaces Internas ¿ Es igual el n ú mero de par á metros recibidos por el m ó dulo a probar al n ú mero de argumentos enviados?, adem á s, ¿ el orden es correcto? ¿ Los atributos (por ejemplo, tipo y tama ñ o) de cada par á metro recibido por el m ó dulo a probar coinciden con los atributos del a argumento correspondiente?

50 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: Interfaces Internas ¿ Coinciden las unidades en las que se expresan par á metros y argumentos? ¿ Altera el m ó dulo un par á metro de s ó lo lectura? ¿ Son consistentes las definiciones de variables globales entre los m ó dulos?

51 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: Interfaces Externas ¿ Se declaran los ficheros con todos sus atributos de forma correcta? ¿ Se abren todos los ficheros antes de usarlos? ¿ Coincide el formato del fichero con el formato especificado en la lectura? ¿ Se manejan correctamente las condiciones de fin de fichero? ¿ Se los libera de memoria? ¿ Se manejan correctamente los errores de entrada/salida?

52 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: Datos: oSe refieren a los accesos que se realizan a los mismos. oUtilizar variables no inicializadas oSalirse del l í mite de las matrices y vectores oSuperar el l í mite de tama ñ o de una cadena

53 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el Código Fuente: Declaraci ó n de Datos: oEl prop ó sito es comprobar que todas las definiciones de los datos locales son correctas. Por ejemplo: oComprobar que no hay dos variables con el mismo nombre oComprobar que todas las variables est é n declaradas oComprobar que las longitudes y tipos de las variables sean correctos.

54 T É CNICAS DE EVALUACI Ó N EST Á TICA LECTURA BASADA EN LISTA DE COMPROBACI Ó N Checklists para el C ó digo Fuente: C á lculo: oIntenta localizar errores derivados del uso de las variables. oComprobar que no se producen overflow o underflow Comparaci ó n: oIntenta localizar errores en las comparaciones realizadas en instrucciones tipo If-Then-Else, While, etc. oComprobar que no existen comparaciones entre variables con diferentes tipos de datos o si las variables tienen diferente longitud. oComprobar si los operadores utilizados en la comparaci ó n son correctos.

55 Técnicas de la evaluación de rendimiento Medición. Modelo analítico. Simulación.

56 Medición Tomar medidas directamente sobre el sistema o sistemas implicados en la evaluación, Controlando la carga de trabajo del sistema, o bien, Generando una carga de trabajo expresamente para la evaluación (carga sintética).

57 Modelado Construir un modelo analítico del sistema a evaluar. Un modelo analítico utiliza fórmulas y ecuaciones diferenciales, Para tratar de hallar, a partir de los valores conocidos o estimados de ciertos parámetros, los valores de los que interesan del sistema para la evaluación.

58 Simulación Simular el sistema utilizando algún lenguaje de programación especializado en simulaciones o genérico.

59 Criterios para seleccionar técnicas evaluación

60 Estado del desarrollo del sistema Sólo es posible emplear técnicas de medición si el sistema ya existe, o al menos, disponemos de algo similar al sistema que debemos estudiar. Por ejemplo, es aplicable cuando se diseña una versión mejorada del producto (optimización). Si estamos ante un concepto nuevo debemos emplear técnicas de modelado o simulación. Un modelo o simulación se puede emplear cuando no es posible realizar medidas; pero es más convincente si están basados en medidas previas.

61 Tiempo necesario para la evaluación Muchas veces es necesario tener los resultados para ayer. Entonces la mejor elección es el modelado. La simulación lleva mucho tiempo. Las técnicas de medición llevan, normalmente, más tiempo que los modelos y menos que las simulaciones. Las medidas se ven afectadas más veces que las demás técnicas por por las leyes de Murphy, por tanto el tiempo puede aumentar.

62 Disponibilidad de herramientas Herramientas: – Modelado  No es necesaria ninguna herramienta especial. – Simulación  Lenguajes de simulación. – Medición  Instrumentos de medida. La carencia de alguna de estas herramientas condiciona la no utilización de una técnica.

63 Nivel de precisión deseado (I) El modelado requiere simplificaciones y que se asuman supuestos previos, lo cual limita mucho su precisión. Las simulaciones pueden incorporar más detalles y por tanto acercarse más a la realidad. Normalmente las mediciones sobre el propio sistema es lo más preciso.

64 Nivel de precisión deseado (II) Las mediciones pueden proporcionar resultados poco precisos debido a la gran cantidad de parámetros ambientales: Configuración del sistema. Tipo de carga de trabajo. Tiempo de medida. La buena o mala elección de los parámetros condiciona la precisión de las técnicas de medida.

65 Nivel de precisión deseado (y III) El nivel de precisión y la corrección de las conclusiones pueden no estar relacionados. Cuando realizamos un estudio de evaluación para optimizar un sistema muchas veces produce mejores conclusiones la utilización de técnicas de modelado.

66 Evaluación de modificaciones (I) Muchas veces el objetivo de una evaluación es: – Comparar varios sistemas o, – Encontrar el valor óptimo para un parámetro. Es importante comprender como influye el cambio de valores de un parámetro en el rendimiento general.

67 Evaluación de modificaciones (y II) Los modelos nos dan la mejor información sobre los efectos de varios parámetros y sus interacciones. Las simulaciones es posible buscar en un espacio de valores la combinación óptima; pero no siempre está clara la relación entre los distintos parámetros. Las mediciones son la peor técnica a este respecto, no es fácil justificar que una mejora de rendimiento es consecuencia del cambio en un parámetro o de un cambio aleatorio en el entorno.

68 Coste dedicado al proyecto de evaluación Las técnicas de medición son las más costosas: – Requieren hardware o software real para realizar las medidas. – Para sistemas caros se utilizan simulaciones para reducir coste. Los modelos analíticos requieren lápiz y papel (y tiempo del analista) por lo que son los menos caros

69 Credibilidad de los resultados Es más fácil convencer a otras personas si disponemos de medidas directas sobre el sistema. Mucha gente es escéptica con los resultados un modelado, porque no comprende las técnicas empleadas. A veces se utilizan simulaciones o mediciones para validar los resultados obtenidos a través de técnicas modelado.

70 Criterios para seleccionar técnicas evaluación

71 Combinación de técnicas En ocasiones es útil utilizar varias técnicas de forma simultanea. Muchas veces se usa la máxima: “hasta que no sean validados, los resultados de una evaluación están bajo sospecha”.