3 tecnicas modernas programacion

  • 726 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
726
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
10
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOS (1ª Parte) Curso de Doctorado Distinguido con la Mención de Calidad Vicente Moret Bonillo Eduardo Mosqueira Rey Elena Hernández Pereira 1
  • 2. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSFORMATO DEL CURSO– Primera parte Aspectos generales de la validación y el análisis de usabilidad de sistemas informáticos – Vicente Moret Bonillo– Segunda parte Estudio de técnicas de validación de sistemas informáticos – Eduardo Mosqueira Rey– Tercera parte Análisis de técnicas de usabilidad de sistemas informáticos – Elena María Hernández Pereira 2
  • 3. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSAlgunas diferencias entre sistemas inteligentes ysistemas convencionales Sistemas Expertos Software convencional Separación del conocimiento de las estructuras de control Separación de datos y algoritmos que utilizan los datos Suelen incluir estructuras de explicación de las conclusiones No existen estructuras de explicación Estructura Existen gestores de bases de datos que nos permiten centrarnos Se suelen construir a partir de herramientas (“shells”) comerciales exclusivamente en los datos y no en su almacenamiento o que permiten centrarse en el conocimiento estructuración Problemas mal definidos, que no pueden ser especificados con Problemas bien definidos, que pueden ser especificados sin Problemas precisión y que son resueltos utilizando conocimiento ambigüedad y que son resueltos por algoritmos apropiados heurístico. específicos. Generalmente dominios sin experiencia computacional Generalmente dominios con experiencia computacional Métodos declarativos y no determinísticos Métodos procedimentales y determinísticos Intentan seguir líneas de razonamiento similares a las de los Se centran en la solución y no en la forma en que se obtiene. expertos humanos Estrategias de Interpretan datos Manipulan datos resolución Resuelven problemas a través del manejo de información Tienen en cuenta aspectos como la abstracción, la incertidumbre, almacenada en bases de datos y mediante procesos el aprendizaje, etc. predecibles, fiables y exactos. Son altamente interactivos No siempre es necesaria la interactividad Naturaleza del Conocimiento proveniente de la experiencia humana (alta Conocimiento de naturaleza algorítmica (alta interacción con conocimiento interacción con expertos) usuarios) empleadoTipo de información Información numérica y simbólica Información numérica utilizada Información con incertidumbre Información sin incertidumbre 3
  • 4. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSLas características diferenciales, estructurales yfuncionales de los sistemas inteligentes condicionanenormemente los procesos de validación, pero no tantolos análisis de usabilidadLos problemas más importantes que debe resolver uningeniero de conocimiento cuando se plantea el diseño yconstrucción de un sistema inteligente son:– Adquisición del conocimiento– Representación del conocimiento– Elección del modelo de razonamiento adecuado 4
  • 5. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSAlgunas técnicas útiles para la adquisición de conocimiento FUENTE DE MODO DE CONOCIMIENTO ADQUISICIÓN Experto 1 Ingeniero del humano conocimiento Manuales 2 Textos Programa 3 inteligente Experto humano de edición Ejemplos y Semi- casos históricos automáticos 4 Programa de inducción Textos Programa de 5 comprensión Automáticos de textos 5
  • 6. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSAprendizaje automático– Técnica automática de adquisición que implica: Recolección de ejemplos o casos históricos – Suministrados por el colectivo de expertos humanos – Obtenidos directamente a partir de las fuentes bibliográficas Utilización de un programa de inducción – Obtención de heurísticas – Extracción de reglas– Ventaja Los expertos, aunque tienen problemas para explicar cómo hacen las cosas, suelen encontrarse cómodos cuando de lo que se trata es de interpretar ejemplos– Inconveniente La interacción con el experto es siempre imprescindible – Conocimientos de paradigmas de programación clásica – Conocimientos de psicología cognoscitiva – Conocimientos de programación simbólica 6
  • 7. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSLa subjetividad afecta de manera importante a la validación desistemas inteligentesEl árbitro que tiene que decidir sobre el grado de corrección delsistema inteligente es el colectivo de expertos humanosPero… ¿quién valida al validador?Cuestión abierta para el debate 7
  • 8. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSEl problema del paradigma de representación del conocimiento– ¿métodos declarativos?– ¿métodos procedimentales?– ¿ambos tipos de métodos?Norma general– Los sistemas que combinan las capacidades de representación de los métodos declarativos, con las capacidades inferenciales de los métodos procedimentales, suelen ser más flexibles, más eficaces, y más eficientesEl esquema de representación elegido está estrechamenterelacionado con el mecanismo de razonamiento adecuadoLos procesos de razonamiento influyen sobre el paradigma derepresentaciónEl paradigma de representación influye sobre los procesos derazonamiento 8
  • 9. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSEL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA Desarrollo incremental Paradigma 2 Herramienta 2 Cambio de Esquema Retraso en el Desarrollo paradigmas 2 proyecto incremental Paradigma 1 Paradigmas Herramienta 1 Esquema inapropiados 1 Continuar sin Dificultades en cambios el diseño 9
  • 10. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSEL PROBLEMA DEL DESPLAZAMIENTO DELPARADIGMA– Surge cuando en la fase de desarrollo se detecta que alguno de los esquemas de representación, modelos de razonamiento, o entornos de programación elegidos elegidos no son adecuados– ¿Debemos continuar el desarrollo con infraestructuras no adecuadas? …que complicarán el proceso de validación y el análisis de usabilidad– ¿Debemos replantear el proyecto? Retraso del proyecto y pérdidas económicas– Si el desplazamiento del paradigma ocurre en etapas tempranas, puede se beneficioso, ya que permite ajustar y optimizar las técnicas de desarrollo 10
  • 11. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSElección del modelo de razonamiento– Los modelos de razonamiento forman parte de las estructuras de control del conocimiento– Son fundamentales para organizar la búsqueda de soluciones en el espacio de estados– Las características del dominio y las características del problema condicionan la elección del modelo de razonamiento DOMINIOS MODELOS EJEMPLOS Simbólicos Categóricos Estadísticos Estadísticos Bayes, redes de creencia Inciertos Cuasi-estadísticos FCs, Dempster-Shafer Lingüísticos difusos 11
  • 12. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSLa inexactitud del conocimiento, implementado oinferido, puede aparecer por diversas causas:– Falta de información– Datos no disponibles en un momento dado– Datos ambiguos– Errores en las medidas de los datos– Medidas contradictorias– Imprecisión– Inconsistencia– Estimaciones– Condiciones excepcionales no observadas 12
  • 13. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSEn los procesos de validación tendremosque considerar:– Aspectos relacionados con la representación del conocimiento inexacto– Cuestiones relativas a la forma de tratar con información imprecisa– Aspectos relacionados con los mecanismos según los cuales podemos inferir conocimiento a partir de datos inciertos 13
  • 14. METODOLOGÍAS DE DESARROLLOPrincipios generales de desarrollo– Desarrollo del sistema mediante un ciclo de vida dividido en fases– Verificar el sistema y validar los resultados en cada fase– Mantener controlado el desarrollo del producto a través de hitos o puntos de control– Utilizar técnicas modernas de programación como herramientas CASE y análisis estructurados– Mantener una descripción detallada de la situación del proyecto en cada momento– Optimizar el personal dedicado al desarrollo: poco pero con experiencia– Mejorar el proceso adoptando diferentes métodos y técnicas 14
  • 15. METODOLOGÍAS DE DESARROLLO– Algunos ejemplos de metodologías: Adquiere y codifica Método de Buchanan Diseño incremental Método de González-Dankel Método de Scott Desarrollo en espiral 15
  • 16. ADQUIERE Y CODIFICASimilar al procedimiento de “codifica y corrige”No sigue un esquema precisoEl sistema se desarrolla en base a una serie deiteraciones en las que se interactúa con elexperto y se codifica el conocimiento extraídoSólo se cumplen dos de los principios generalesde desarrollo:– Validación continua– Utilización de equipos de trabajo pequeños 16
  • 17. METODOLOGÍA DE DESARROLLO DE BUCHANAN Identificación Requisitos Conceptualización Conceptos Formalización Estructuras Reglas Implementación Reformulaciones Rediseños Refinamientos Prueba 17
  • 18. METODOLOGÍA DE DESARROLLO DE BUCHANANIdentificación – Se reconocen aspectos importantes del problema: Participantes – Expertos del dominio – Ingenieros de conocimiento – Usuarios Características del problema – Tipo – Subtareas – Terminología Recursos disponibles – Fuentes de conocimiento – Recursos computacionales – Tiempo de desarrollo – Financiación Metas – Formalización del conocimiento del experto – Distribución de experiencia – Formación de nuevos expertos 18
  • 19. METODOLOGÍA DE DESARROLLO DE BUCHANANConceptualización– Organización del conocimiento según un esquema conceptual– Búsqueda de conceptos que representen el conocimiento del experto– Identificación del flujo de información durante el proceso de resolución de problemas 19
  • 20. METODOLOGÍA DE DESARROLLO DE BUCHANANFormalización– Proceso de traducción de… Conceptos clave Subproblemas Características del flujo de información– Construcción de representaciones formales basadas en… Herramientas de desarrollo Esquemas de ingeniería del conocimiento 20
  • 21. METODOLOGÍA DE DESARROLLO DE BUCHANANElicitación– Extracción del conocimiento Soporte físico Proceso consistente con la información obtenida en fases anteriores: – Identificación – conceptualización 21
  • 22. METODOLOGÍA DE DESARROLLO DE BUCHANANImplementación– Formulación de reglas– Formulación de estructuras de control– Obtención de un prototipo Permite comprobar si hemos conceptualizado bien el conocimiento del dominio Permite comprobar si hemos formalizado bien el conocimiento del dominio 22
  • 23. METODOLOGÍA DE DESARROLLO DE BUCHANANPrueba– Evaluación del rendimiento del prototipo construido– Identificación de errores– Identificación de anomalías en… Base de conocimientos Mecanismos de inferencia 23
  • 24. METODOLOGÍA DE DESARROLLO DE BUCHANANLos lazos de realimentación no tienen por qué seguir estrictamentela secuencia del esquema propuesto por BuchananLas retroalimentaciones pueden aparecer entre cualquier par defases de la metodología Identificación Prueba Conceptualización Implementación Formalización 24
  • 25. METODOLOGÍA DE DESARROLLO INCREMENTALDesarrollo iterativo de sistemasProceso cíclico de desarrolloEn cada ciclo se efectúa un refinamiento– Proceso de depuración de errores en la base de conocimientosEn cada ciclo se efectúa una extensión delsistema– Ampliación de las capacidades del mismoEl modelo de desarrollo en cascada no estámuerto… pero debería estarlo 25
  • 26. METODOLOGÍA DE DESARROLLO DE GONZÁLEZ-DANKELAnálisis Ajuste del diseño Especificación Implementación Diseño preliminar Prueba (V&V) Prototipo inicial Mantenimiento Evaluación Diseño final 26
  • 27. METODOLOGÍA DE DESARROLLO DE GONZÁLEZ-DANKELModelo de desarrollo que incorpora prototipado rápido y desarrolloincrementalFases: – Análisis del problema Estudios coste-beneficio y análisis de mercados – Especificación de requisitos Definición de objetivos del proyecto y selección de medios – Diseño preliminar Decisiones de alto nivel para el prototipo inicial Esquema de representación, herramienta y expertos – Prototipado inicial y evaluación El prototipo es una versión con funcionalidad limitada del producto final – Diseño final Módulos del sistema, entradas y salidas – Implementación – Prueba Fase de verificación-validación – Ajuste de diseño y mantenimiento Pueden aparecer desplazamientos del paradigma 27
  • 28. METODOLOGÍA DE DESARROLLO DE SCOTTSe divide en 4 fases:– Fase de análisis Se investiga la viabilidad del proyecto– Fase de especificación Se inicia el proyecto y de fijan las bases del desarrollo– Fase de desarrollo Se realiza el diseño y se implementa el sistema– Fase de utilización Se habilita el sistema para su uso rutinario 28
  • 29. METODOLOGÍA DE DESARROLLO DE SCOTTANÁLISIS Identificación de la potencial aplicación Identificación Comprobación de la adecuación de las técnicas de ingeniería del Valoración conocimiento Definir lo que hará el sistema.ESPECIFICACIÓN Trabajar con el experto para Familiarización planificar el desarrollo. Aprender cómo el expertoDESARROLLO Diseño conceptual resuelve el problema y desarrollar un modelo conceptual del sistema Decidir la representación del Diseño de conocimiento y los f ormalismos de implementación control para implementar el modelo conceptualRefinamiento y extensión Seguir el diseño de Implementación implementación para construir la base de conocimientos Evaluación Comprobar si el sistema funciona correctamenteUTILIZACIÓN Instalar el sistema en el dominio Pruebas de campo de uso rutinario Corregir errores, actualizar y aumentar el sistema Mantenimiento 29
  • 30. METODOLOGÍA DE DESARROLLO DE SCOTTPrototipado rápido y desarrollo incrementalLos prototipos construidos son una ayuda parael proceso de adquisición del conocimientoLa fase de utilización empieza cuando elsistema se instala en el entorno en que se usaráde forma rutinariaLa fase de mantenimiento posterior puedeevidenciar errores, que hay que corregir, orecoger sugerencias de los usuarios, que hayque implementar 30
  • 31. METODOLOGÍA DE DESARROLLO DE SCOTTLas características de esta metodología son muy parecidas a las dela metodología de González-DankelLa metodología de Scott pone especial énfasis en la adquisición delconocimientoLa adquisición del conocimiento está presente en todo el proceso Identificación Fam iliarización Diseño de im plem entación Evaluación Mantenim iento 0 10 20 30 40 50 60 70 80 90 100 31
  • 32. METODOLOGÍA DE DESARROLLO DE SCOTTDos fases típicas en el proceso de adquisicióndel conocimiento:– Adquisición inicial Fase preparatoria en la que la información obtenida nos permite tener un conocimiento más amplio de lo que debe hacer el sistema, de cómo va a ser usado, y de cómo hay que desarrollarlo Aparece en el análisis y en la especificación– Adquisición detallada El foco de atención es más estrecho y profundo. El proceso es mucho más detallado. Permite la comprensión del modus operandi de los expertos. Aparece en el desarrollo y en la utilización. 32
  • 33. METODOLOGÍA DE DESARROLLO EN ESPIRAL Análisis de AR Requisitos (AR) AR Verificación AR de Requisitos (VR) VR AR VR VR VR Inicio del ciclo AC Casos de Test Test de Adquisición del Recolección campo Prot. de- NAR AC de datos mostración conocimiento (AC)Validación Verificación Prototipo de NAR AC investigación Grupo de AC control NAR Prototipo de campo Verificación Modelo de NAR Fijar un nivel Prototipado producción aceptable de rendimiento(NAR) 33
  • 34. METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Análisis de requisitos ¿Es de utilidad el sistema? ¿Cuál es el problema que hay que resolver? ¿Quiénes son los usuarios potenciales? ¿Cuál es el impacto previsto del sistema en la organización? 34
  • 35. METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Adquisición del conocimiento El conocimiento extraído de una determinada fuente, y posteriormente transformado en un esquema de representación dado, debe ser verificado 35
  • 36. METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Prototipado El desarrollo incremental a través de una serie de prototipos permite que en cada ciclo se fijen los requisitos apropiados Para que un prototipo sea útil hay que validarlo Las técnicas de verificación y de validación van a depender de: – Las características del sistema – Las características del dominio de aplicación – La etapa de desarrollo en que nos encontremos 36
  • 37. METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Implementación y mantenimiento Una vez desarrollado el prototipo podemos… – Utilizarlo como fuente de especificaciones – Hacer evolucionar el prototipo hasta convertirlo en un sistema de producción operativo Cuando el sistema está operativo… – Tenemos que monitorizarlo – Tenemos que comprobar su concordancia con los requisitos – Tenemos que documentar su utilización en el entorno de trabajo El mantenimiento exige… – Realizar tareas de validación – Detectar inconsistencias – Asegurar la robustez del sistema 37
  • 38. TIPOS DE PROTOTIPOSPrototipo de demostraciónPrototipo de investigaciónPrototipo de campoModelo de producciónSistema comercial 38
  • 39. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOS Evaluación Validación Verificación 39
  • 40. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSVerificación:– Comprobación de que estamos construyendo el sistema correctamente– Comprobar que el sistema no contiene errores de implementación– Comprobar que el sistema cumple con las especificaciones inicialmente definidas 40
  • 41. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSValidación:– Comprobación de que estamos construyendo el sistema correcto– Comprobar que el sistema produce la salida correcta– Comprobar que el sistema cumple con las necesidades y los requisitos del usuario 41
  • 42. VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOSEvaluación:– Análisis de aspectos que van más allá de la corrección de las soluciones finales– Análisis de utilidad– Análisis de robustez– Análisis de velocidad– Análisis de eficiencia– Posibilidades de ampliación– Facilidad de manejo 42
  • 43. VERIFICACIÓN DE SISTEMASVerificación del cumplimiento de lasespecificacionesVerificación de los mecanismos deinferenciaVerificación de la base de conocimientos– Verificación de consistencia– Verificación de la completitud– Influencia de las medidas de incertidumbre 43
  • 44. VERIFICACIÓN DEL CUMPLIMIENTO DE LAS ESPECIFICACIONESPersonal potencialmente involucrado:– Desarrolladores– Usuarios– Expertos– Grupo de evaluadores independientesAspectos a considerar:– Paradigma de representación– Técnica de razonamiento– Diseño modular– Conexión adecuada con software externo– Especificaciones del interfaz de usuario– Capacidades de explicación– Requisito de rendimiento en tiempo real– Facilidad de mantenimiento del sistema– Verificación de las especificaciones de seguridad– Nivel de protección de la base de conocimientos 44
  • 45. VERIFICACIÓN DE LOS MECANISMOS DE INFERENCIA Pierde importancia con la utilización de entornos de desarrollo comerciales El problema se transfiere hacia la elección de la herramienta adecuada Excepciones: – Dominios críticos – Desconocimiento sobre el funcionamiento exacto de la herramienta – Los procedimientos de resolución de conflictos o los procesos de búsqueda implementados pueden dificultar el seguimiento de los mecanismos de inferencia 45
  • 46. VERIFICACIÓN DE LA BASE DE CONOCIMIENTOSEs responsabilidad del ingeniero del sistemaGeneralmente se basa en el concepto deanomalíasUna anomalía es un uso extraño del esquemade representación del conocimientoUna anomalía debe ser considerada como unerror potencial– Hay anomalías que resultan de errores– Hay anomalías que no constituyen errores 46
  • 47. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE CONOCIMIENTOS Reglas redundantes – Redundancias sintácticas P (x) y Q (x) → R (x) Q (x) y P (x) → R (x) – Redundancias semánticas Premisas o conclusiones de una regla no son idénticas en la sintaxis, pero sí lo son en el significado P (x) y Q (x) → R (x) = Tormenta Q (x) y P (x) → R (x) = Actividad eléctrica – Las redundancias no siempre causan problemas lógicos, aunque pueden afectar a la eficiencia del sistema – Pueden aparecer problemas cuando en una eventual revisión del sistema se cambie una regla pero no la otra 47
  • 48. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE CONOCIMIENTOS Reglas conflictivas – Premisas idénticas pero conclusiones contradictorias P (x) y Q (x) → R (x) P (x) y Q (x) → not R (x) – Aparecen peculiaridades cuando utilizamos algunos modelos de tratamiento del conocimiento inexacto, o cuando hay parámetros multivaluados 48
  • 49. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE CONOCIMIENTOS Reglas englobadas en otras P (x) y Q (x) → R (x) P (x) → R (x) – No tiene por qué ser una anomalía – Hay que definir una estrategia adecuada de resolución de conflictos – Normalmente la eficiencia del sistema se incrementa con el empleo de reglas más restrictivas 49
  • 50. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE CONOCIMIENTOS Reglas circulares P (x) → Q (x) Q (x) → R (x) R (x) → P (x) Condiciones IF innecesarias – Caso A P (x) y Q (x) → R (x) P (x) y not Q (x) → R (x) Solución – P (x) → R (x) – Caso B P (x) y Q (x) → R (x) Not Q (x) → R (x) Solución – P (x) → R (x) – Not Q (x) → R (x) 50
  • 51. VERIFICACIÓN DE LA COMPLETITUD DE LA BASE DE CONOCIMIENTOS Valores no referenciados de atributos – Parte del conocimiento declarativo no está representado en el conocimiento procedimental Valores ilegales de atributos Reglas inalcanzables – Situación relacionada con la dirección de la búsqueda SDO: – La conclusión de una regla no aparece como objetivo y no aparece como parte de la premisa de otra regla SDD: – La premisa de una regla no puede ser obtenida del exterior y no aparece como conclusión de ninguna regla Reglas sin salida – Una regla inalcanzable para un SDO es una regla sin salida para un SDD – Una regla inalcanzable para un SDD es una regla sin salida para un SDO 51
  • 52. INFLUENCIA DE LAS MEDIDAS DE INCERTIDUMBRERedundancia – En sistemas sin incertidumbre la redundancia no tiene por qué afectar a la salida del sistema – En sistemas con incertidumbre la redundancia puede causar graves problemas, al modificarse el peso evidencial de las conclusionesReglas englobadas en otras – Puede ser una situación perfectamente admisible. Dos reglas pueden concluir lo mismo con distinta potencia evidencialCondiciones IF innecesarias – Mismo caso que el anteriorReglas circulares – La utilización de medidas de incertidumbre puede romper la circularidad. Por ejemplo, si la confianza de una conclusión cae por debajo de un umbralReglas sin salida – Su detección se complica cuando manejamos incertidumbre. Una regla puede convertirse en “sin salida” cuando su conclusión tiene una certidumbre por debajo del umbral establecido como “conocido” o “significativo”Reglas inalcanzables – Mismo caso que el anterior 52
  • 53. ASPECTOS GENERALES DE LA VALIDACIÓN DE SISTEMASValidar– Comprobar que estamos construyendo el producto correcto– Examinar la validez de los resultados– Constatar el cumplimiento de las necesidades definidas– Constatar el cumplimiento de los requisitos de usuarioTipos– Validación orientada a los resultados (VOR)– Validación orientada al uso (VOU) Assessment o Valoración 53
  • 54. ASPECTOS GENERALES DE LA VALIDACIÓN DE SISTEMASLa validación orientada a los resultados esprevia a la validación orientada al usoLa validación orientada al uso está cercana alos estudios de usabilidadCaracterísticas importantes VOR:– Personal involucrado en el proceso– Partes del sistema que deben ser validadas– Casuística de la validación– Criterios de validación– Momento en que se realiza la validación– Métodos de validación– Errores cometidos en la validación 54
  • 55. PERSONAL INVOLUCRADO EN LA VALIDACIÓN Ingeniero del Evaluadores conocimiento independientes Validación del Experto sistema humano Usuarios finalesLa falacia del superhombre:– Se le suele exigir más al sistema inteligente que al experto humano, sin tener en cuenta que el conocimiento del sistema inteligente es un modelo computacional del conocimiento de los expertos humanos 55
  • 56. PARTES DEL SISTEMA QUE DEBEN SER VALIDADASResultados finales – Performance general del sistemaResultados intermedios – Descripción del funcionamiento interno del sistema – Permite corregir errores cometidosRazonamiento seguido – Un proceso de razonamiento incorrecto puede ser fuente de errores cuando queramos ampliar la base de conocimientos del sistema – Tenemos que diseñar sistemas que “piensen” como lo haría un experto humano… también en la forma 56
  • 57. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS SISTEMA EXPERTO Resultado Gasometrías (Balance ácido-base) pCO2 = 48 mmHg ACIDOSIS METABÓLICA pH = 7.32 Razonamiento ≠ Datos − [HCO3] = 17 mg / l Valor esperado Contexto ACIDOSIS METABÓLICA Y No presenta fallo RESPIRATORIA Paciente renalAnalizando los resultados intermedioscomprobamos que hay un error en lainterpretación del pCO2… 57
  • 58. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO ⇓ IF pCO2 > 46 mmHg THEN Estado_pCO2 = ALTO SISTEMA EXPERTO Resultado (Balance ácido-base) Resultados intermediosGasometrías ACIDOSIS METABÓLICA YpCO2 = 48 mmHg RESPIRATORIA Estado_pCO2 = NormalpH = 7.32 −[HCO3] = 17 mg / l ⇒ Alto = Razonamiento Estado_pH = Bajo RazonamientoContexto Valor esperado previo Estado_HCO3 = Bajo finalNo presenta fallo ACIDOSIS METABÓLICA Yrenal RESPIRATORIA Corregido el error, las conclusiones son ahora correctas Pero… persiste todavía un error que no detectamos si no seguimos el proceso de razonamiento, y si no se nos presenta, durante la validación, el caso de un “fallo renal” 58
  • 59. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS SISTEMA EXPERTO Resultado (Balance ácido-base)Gasometrías Resultados intermedios ACIDOSIS METABÓLICA YpCO2 = 48 mmHg RESPIRATORIApH = 7.32 Estado_pCO2 = Alto[HCO3]− 17 mg / l = = Razonamiento Estado_pH = Bajo RazonamientoContexto previo Estado_HCO3 = Bajo Valor esperado finalNo presenta fallo ACIDOSIS METABÓLICA Yrenal RESPIRATORIA IF [HCO3]− 18 mg / l THEN Estado_HCO3 = BAJO < ⇓ − IF (([HCO3] < 18 mg / l) and (no Fallo Renal)) or (([HCO3]− 16 mg / l) and (Fallo Renal)) < THEN Estado_HCO3 = BAJO 59
  • 60. CASUÍSTICA DE LA VALIDACIÓNDos tipos de datos– Los que incluyan las características de cada caso particular– Un criterio que permita identificar el tipo de caso que estamos tratandoLa muestra debe ser– Suficiente– Suficientemente representativaProceso– Obtención de la casuística de validación– Transferencia de los datos al sistema que ha de interpretarlos– Resultados y criterios son la entrada del proceso de validación en el que se analiza el rendimiento del sistema 60
  • 61. VALIDACIÓN CONTRA EL EXPERTOSe utilizan las opiniones y las interpretacionesde los expertos humanos como criterio devalidaciónPuede haber discrepancias entre expertos osesgos en este tipo de validación– Factores externos: estrés,…– Pueden no ser independientes– Pueden ser ambiguos– Pueden pertenecer a distintas escuelas de pensamiento– Pueden tener sus propias ideas sobre el sistema que están validando y, por lo tanto, no ser objetivos 61
  • 62. VALIDACIÓN CONTRA EL EXPERTOHay tres procedimientos diferentes:– Validación contra un único experto Ventajas – Suele haber al menos un experto disponible Inconvenientes – La validación puede no ser fiable– Validación contra un grupo de expertos Ventajas – No estamos supeditados a una única opinión – Permite comparar el grado de consistencia entre expertos del dominio Inconvenientes – Los expertos no son todos iguales: ¿Cómo medir el rendimiento del sistema?– Validación contra un consenso de expertos Ventajas – En teoría es el método más objetivo y fiable Inconvenientes – Puede haber un experto especialmente influyente – ¿Cómo se mide el consenso? 62
  • 63. VALIDACIÓN CONTRA EL PROBLEMANuestro sistema: ¿acierta realmente, o resuelveconvenientemente, el problema planteado?Ventajas– Método completamente objetivo– La solución real puede verse en el problema– Si nuestro sistema discrepa con el experto humano, pero coincide con la respuesta del problema, la credibilidad del sistema aumentaInconvenientes– Falacia del superhombre– No siempre puede realizarse una validación contra el problema 63
  • 64. MOMENTO EN QUE SE REALIZA LA VALIDACIÓNBachant y McDermott– Validar un sistema que no está terminado puede no ser útil– Las interpretaciones del sistema pueden no ser correctas si no está implementado todo el conocimientoBuchanan y Shortliffe– La validación del sistema debe estar presente a lo largo de todo su ciclo de desarrolloAspectos relacionados– Validación retrospectiva Sobre casos históricos ya resueltos y almacenados– Validación prospectiva Sobre casos reales todavía no resueltos y análisis de las interpretaciones propuestas 64
  • 65. MÉTODOS DE VALIDACIÓNMétodos cualitativos– Emplean técnicas subjetivas de comparación de rendimientos Validación superficial Pruebas de Turing Pruebas de campo Validación de subsistemas Análisis de sensibilidad Grupos de controlMétodos cuantitativos– Emplean técnicas estadísticas de comparación de rendimientos Medidas de pares Medidas de grupo Ratios de acuerdo 65
  • 66. MÉTODOS DE VALIDACIÓNMedidas de pares – Medidas de acuerdo Índice de acuerdo Índice de acuerdo en uno Kappa Kappa ponderada – Medidas de asociación Tau de Kendall Tau B de Kendall Rho de Spearman Gamma de Goodman-KruskalMedidas de grupo – Medidas de Williams – Análisis clúster – Escalamiento multidimensional – Medidas de dispersión y tendenciasRatios de acuerdo – Sensibilidad – Especificidad – Valor predictivo positivo – Valos predictivo negativo – Índice de acuerdo – Medida de Jaccard 66
  • 67. OTRAS MEDIDASCoeficientes de exactitudDistancias aritméticasCurvas ROC… 1 0.05 0.9 0.1 0.8 0.3 0.7 0.6 TP 0.5 0.5 0.4 0.3 0.7 0.2 0.1 0.9 0 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 FP 67
  • 68. ERRORES COMETIDOS EN LA VALIDACIÓN Errores de comisión Errores por omisión Sistema válido Sistema no válido Sistema aceptado DECISIÓN ERROR TIPO II como válido CORRECTA Riesgo para usuarioSistema no aceptado ERROR TIPO I DECISIÓN como válido Riesgo para ingeniero CORRECTA 68
  • 69. Un ejemplo de validación 69
  • 70. Un ejemplo de validación 70
  • 71. Un ejemplo de validación Porcentajes de acuerdo totales en PATRICIA todas las categorías Clínico vs. Experto Colaborador 79% Clínico vs. Sistema Experto 78%119 casos Experto Colaborador Sistema Experto vs. reales Experto Colaborador 92% Médico que atendió el caso (clínico) 71
  • 72. Un ejemplo de validación Porcentajes de acuerdo por categoría diagnóstica PATRICIA Oxigenación 92% Balance Ácido-Base 74% Hemodinámica 87%147 casos Terapia Ventilatoria 71% reales Equipo Médico 72
  • 73. Un ejemplo de validación Sistema Dominio UCI:Casos de prueba Experto – No es fácil establecer 1 referencias estándar Características de los casos – Nunca podríamos asegurar que las interpretaciones y 2 prescripciones de un experto sigan siempre los Interpretaciones de los casos mismos principios Referencia estándar – El estrés y el entorno contribuyen a desvirtuar comportamientos 3 – Pueden aparecer soluciones equivalentes aunque no idénticas Validación Resultados de la validación 73
  • 74. Un ejemplo de validaciónCriterios con carácter general:– Si el dominio de aplicación es un dominio crítico, en el que no es posible reconsiderar decisiones una vez han sido tomadas, entonces los métodos prospectivos no son apropiados.– Evidentemente, si no existe una referencia estándar, o si tal referencia es muy difícil de obtener, la validación debe llevarse a cabo sin tales consideraciones.– Si la salida del sistema es un conjunto de interpretaciones que están lingüísticamente etiquetadas según una escala ordinal, entonces podemos considerar el uso de medidas cuantitativas, como índices de concordancia o medidas Kappa. 74
  • 75. Un ejemplo de validaciónEsquema de la validación formal dePATRICIA– Contexto retrospectivo– Con medidas de pares y técnicas cuantitativas– Efectuar un análisis de grupo tratando de identificar referencias estándar, y posicionando a PATRICIA dentro del grupo de expertos colaboradores. 75
  • 76. Un ejemplo de validaciónEtapas:– Labores de interpretación OXIGENACION BALANCE ACIDO-BASE RESPIRACION ENDOGENA PRESION ARTERIAL FRECUENCIA CARDIACA– Labores de sugerencias terapéuticas MANEJO OXIGENATORIO MANEJO VENTILATORIO 76
  • 77. Un ejemplo de validaciónMedidas realizadas:– Indices de concordancia entre expertos (incluido el sistema)– Indices de concordancia en uno– Indices kappa– Indices kappa ponderada– Medidas de Williams– Análisis Clúster 77
  • 78. Un ejemplo de validación Balance Ácido-Base Porcentajes de acuerdo total vs pares de com paraciónPorcentaje de acuerdo 100 80 60 40 20 0 a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g Pares de com paración Porcentajes de acuerdo "dentro de uno" vs pares de com paración% "dentro de uno" 100 80 60 40 20 0 a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g Pares de com paración 78
  • 79. Un ejemplo de validación Balance Ácido-Base Valores de kappa vs. pares de comparación 1.00 0.80 Kappa 0.60 0.40 0.20 0.00 a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g Pares de com paración Valores de kappa ponderada vs. pares de comparaciónKappa ponderada 1.00 0.80 0.60 0.40 0.20 0.00 a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g Pares de com paración 79
  • 80. Un ejemplo de validación Balance Ácido-Base Kappa Kappa ponderada 2.00 2.00 Medidas de Williams Medidas de Williams 1.80 1.80 1.60 1.60 1.40 1.40 1.20 1.20 1.00 1.00 0.80 0.80 0.60 0.60 0.40 0.40 0.20 0.20 0.00 0.00 A B C D E F G A B C D E F G Expertos Expertos Porcentajes de acuerdo Porcentajes "dentro de uno" 2.00 2.00 Medidas de Williams Medidas de Williams 1.80 1.80 1.60 1.60 1.40 1.40 1.20 1.20 1.00 1.00 0.80 0.80 0.60 0.60 0.40 0.40 0.20 0.20 0.00 0.00 A B C D E F G A B C D E F G Expertos Expertos 80
  • 81. USABILIDAD DE SISTEMASMétodos heurísticos– Técnicas heurísticas, desarrolladas por expertos, que analizan los interfaces de los módulos, evalúan su arquitectura y determinan sus puntos fuertes y débiles desde la perspectiva del usuarioMétodos subjetivos– Obtienen información de los usuarios sobre prototipos operativos del prototipo en desarrollo (observación directa, cuestionarios, entrevistas, grupos de control,…)Métodos empíricos– Obtención de datos objetivos acerca de cómo los usuarios utilizan el sistema 81
  • 82. MÉTODOS HEURÍSTICOSAnálisis del sistema y detección de problemas deamigabilidad y calidad– Cuestionarios ergonómicos– Inspección de interfaces– Evaluación de la navegación– Análisis formales 82
  • 83. MÉTODOS SUBJETIVOSConocimiento de la opinión de los usuarios sobre la propiausabilidad del sistema – Pensar en alto – Observación – Cuestionarios – Entrevistas – Grupos de control – Retroalimentación con el usuario 83
  • 84. EJEMPLOS DE CUESTIONARIOS CERRADOS SI NO NS/NC Escala simple ¿Puede realizarse ...? Escala multipunto ¿Está de acuerdo con ...? Completamente Completamente en desacuerdo de acuerdo Escala de Lickert ¿Está de acuerdo con ...?Completamente Ligeramente en Ligeramente de Completamenteen desacuerdo En desacuerdo desacuerdo Neutral acuerdo De acuerdo de acuerdo Escala diferencial semántica Clasifica el módulo ... de acuerdo a los siguientes parámetros Extremada- Extremada- mente Bastante Ligeramente Neutral Ligeramente Bastante mente Fácil Difícil Claro Confuso Escala de orden Ordena los siguientes comandos según su utilidad PEGAR DUPLICAR AGRUPAR BORRAR 84
  • 85. MÉTODOS EMPÍRICOSSe trata de sacar conclusiones basadas en datosobjetivos obtenidos sobre cómo los usuarios utilizan elsistema– Exactitud Número de errores provocados durante un determinado lapso de tiempo– Velocidad Celeridad en la interacción con el sistema– Exactitud y velocidad son magnitudes inversamente proporcionales 85
  • 86. MEDIDAS OBJETIVAS DE USABILIDADNúmero de tareas diversas que pueden realizarse en undeterminado periodo de tiempoProporción entre interacciones correctas y erroresNúmero de errores cometidos por el usuarioTiempo consumido en la realización de una tarea específicaTiempo consumido en la recuperación de erroresNúmero de características del sistema que son utilizadas por losusuarios 86
  • 87. RESUMENVerificación, validación y análisis de usabilidad sonfundamentales para desarrollar software de calidadEstas fases deben formar parte del ciclo de desarrollodel sistemaLas metodologías de desarrollo y diseño deben incluirexplícita y específicamente la ubicación idónea de lastareas de verificación, validación y usabilidadLa realización de estas tareas requiere el dominio detécnicas específicasLa evaluación de sistemas debe ser contemplada comoun proceso global de análisis de la performance delsistema en cuestión 87