validacion de usabilidad de sistema informatico

1

VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOS

(1ª Parte)

Curso de DoctoradoDistinguido con la Mención de Calidad

Vicente Moret BonilloEduardo Mosqueira ReyElena Hernández Pereira

2


FORMATO DEL CURSO– Primera parte

Aspectos generales de la validación y el análisis de usabilidad de sistemas informáticos

– Vicente Moret Bonillo

– Segunda parteEstudio de técnicas de validación de sistemas informáticos

– Eduardo Mosqueira Rey

– Tercera parteAnálisis de técnicas de usabilidad de sistemas informáticos

– Elena María Hernández Pereira

3


Algunas diferencias entre sistemas inteligentes y sistemas convencionales

Información sin incertidumbreInformación con incertidumbre

Información numéricaInformación numérica y simbólicaTipo de información utilizada

Conocimiento de naturaleza algorítmica (alta interacción con usuarios)

Conocimiento proveniente de la experiencia humana (alta interacción con expertos)

Naturaleza del conocimiento

empleado

No siempre es necesaria la interactividadSon altamente interactivos

Resuelven problemas a través del manejo de información almacenada en bases de datos y mediante procesos

predecibles, fiables y exactos.

Tienen en cuenta aspectos como la abstracción, la incertidumbre, el aprendizaje, etc.

Manipulan datosInterpretan datos

Se centran en la solución y no en la forma en que se obtiene.Intentan seguir líneas de razonamiento similares a las de los expertos humanos

Métodos procedimentales y determinísticosMétodos declarativos y no determinísticos

Estrategias de resolución

Generalmente dominios con experiencia computacionalGeneralmente dominios sin experiencia computacional

Problemas bien definidos, que pueden ser especificados sin ambigüedad y que son resueltos por algoritmos

específicos.

Problemas mal definidos, que no pueden ser especificados con precisión y que son resueltos utilizando conocimiento

heurístico.Problemas

apropiados

Existen gestores de bases de datos que nos permiten centrarnos exclusivamente en los datos y no en su almacenamiento o

estructuración

Se suelen construir a partir de herramientas (“shells”) comerciales que permiten centrarse en el conocimiento

No existen estructuras de explicaciónSuelen incluir estructuras de explicación de las conclusiones

Separación de datos y algoritmos que utilizan los datosSeparación del conocimiento de las estructuras de control

Estructura

Software convencionalSistemas Expertos

4


Las características diferenciales, estructurales y funcionales de los sistemas inteligentes condicionan enormemente los procesos de validación, pero no tanto los análisis de usabilidad

Los problemas más importantes que debe resolver un ingeniero de conocimiento cuando se plantea el diseño y construcción de un sistema inteligente son:– Adquisición del conocimiento– Representación del conocimiento– Elección del modelo de razonamiento adecuado

5


Algunas técnicas útiles para la adquisición de conocimiento

Expertohumano

Ingeniero delconocimiento

1

Ejemplos ycasos históricos

2

Textos

Expertohumano

3

4

Programainteligentede edición

Textos5

Programa deinducción

Programa decomprensión

de textos

FUENTE DECONOCIMIENTO

M ODO DEADQUISICIÓN

Manuales

Semi-automáticos

Automáticos

6


Aprendizaje 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

– VentajaLos 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

– InconvenienteLa 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

7


La subjetividad afecta de manera importante a la validación de sistemas inteligentes

El árbitro que tiene que decidir sobre el grado de corrección del sistema inteligente es el colectivo de expertos humanos

Pero… ¿quién valida al validador?

Cuestión abierta para el debate

8


El 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 eficientes

El esquema de representación elegido está estrechamente relacionado con el mecanismo de razonamiento adecuadoLos procesos de razonamiento influyen sobre el paradigma de representaciónEl paradigma de representación influye sobre los procesos de razonamiento

9


EL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA

Herram ienta 1

Paradigm a 1

Esquem a1

D esarrolloincrem ental

Esquem a2

Herram ienta 2

Paradigm a 2

D esarrolloincrem ental

P aradigm asinaprop iados

C am bio deparad igm as

C ontinuar sincambios

R etraso en elproyecto

D ificultades enel diseño

10


EL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA– 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

11


Elecció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

difusosLingüísticos

FCs, Dempster-ShaferCuasi-estadísticosInciertos

Bayes, redes de creenciaEstadísticosEstadísticos

CategóricosSimbólicos

EJEMPLOSMODELOSDOMINIOS

12


La inexactitud del conocimiento, implementado o inferido, 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

13


En los procesos de validación tendremos que 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

14

METODOLOGÍAS DE DESARROLLO

Principios 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

15

METODOLOGÍAS DE DESARROLLO

– Algunos ejemplos de metodologías:

Adquiere y codificaMétodo de BuchananDiseño incrementalMétodo de González-DankelMétodo de ScottDesarrollo en espiral

16

ADQUIERE Y CODIFICA

Similar al procedimiento de “codifica y corrige”No sigue un esquema precisoEl sistema se desarrolla en base a una serie de iteraciones en las que se interactúa con el experto y se codifica el conocimiento extraídoSólo se cumplen dos de los principios generales de desarrollo:– Validación continua– Utilización de equipos de trabajo pequeños

17

METODOLOGÍA DE DESARROLLO DE BUCHANAN

Requisitos

Conceptualización

Formalización

Implementación

Prueba

Identificación

Conceptos

Estructuras

Reglas

Ref

inam

ient

os

Red

iseñ

osReformulaciones

18


Identificació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

19


Conceptualizació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

20


Formalización– Proceso de traducción de…

Conceptos claveSubproblemasCaracterísticas del flujo de información

– Construcción de representaciones formales basadas en…

Herramientas de desarrolloEsquemas de ingeniería del conocimiento

21


Elicitación– Extracción del conocimiento

Soporte físicoProceso consistente con la información obtenida en fases anteriores:

– Identificación– conceptualización

22


Implementació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 dominioPermite comprobar si hemos formalizado bien el conocimiento del dominio

23


Prueba– Evaluación del rendimiento del prototipo

construido– Identificación de errores– Identificación de anomalías en…

Base de conocimientosMecanismos de inferencia

24


Los lazos de realimentación no tienen por qué seguir estrictamente la secuencia del esquema propuesto por BuchananLas retroalimentaciones pueden aparecer entre cualquier par de fases de la metodología

Conceptualización

FormalizaciónImplementación

Prueba

Identificación

25

METODOLOGÍA DE DESARROLLO INCREMENTAL

Desarrollo 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 del sistema– Ampliación de las capacidades del mismo

El modelo de desarrollo en cascada no está muerto… pero debería estarlo

26

METODOLOGÍA DE DESARROLLO DE GONZÁLEZ-DANKEL

Diseño preliminar

Prototipo inicial

Evaluación

Diseño final

Análisis

Especificación

Ajuste del diseño

Implementación

Prueba (V&V)

Mantenimiento

27

METODOLOGÍA DE DESARROLLO DE GONZÁLEZ-DANKEL

Modelo de desarrollo que incorpora prototipado rápido y desarrollo incrementalFases:

– Análisis del problemaEstudios coste-beneficio y análisis de mercados

– Especificación de requisitosDefinición de objetivos del proyecto y selección de medios

– Diseño preliminarDecisiones de alto nivel para el prototipo inicialEsquema de representación, herramienta y expertos

– Prototipado inicial y evaluaciónEl prototipo es una versión con funcionalidad limitada del producto final

– Diseño finalMó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

28

METODOLOGÍA DE DESARROLLO DE SCOTT

Se 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 desarrolloSe realiza el diseño y se implementa el sistema

– Fase de utilizaciónSe habilita el sistema para su uso rutinario

29


U T I L I Z A C I Ó N

D E S A R R O L L O

E S P E C I F I C A C I Ó N

A N Á L I S I S

I d e n t i f i c a c i ó n

V a l o r a c i ó n

F a m i l i a r i z a c i ó n

D is e ñ o c o n c e p t u a l

D i s e ñ o d eim p l e m e n t a c i ó n

I m p l e m e n t a c i ó n

E v a lu a c i ó n

P r u e b a s d e c a m p o

M a n t e n im i e n t o

R e f i n a m i e n t oy e x t e n s i ó n

I d e n t i f i c a c i ó n d e l a p o t e n c i a la p l i c a c i ó n

C o m p r o b a c i ó n d e l a a d e c u a c i ó nd e l a s t é c n i c a s d e i n g e n i e r í a d e l

c o n o c i m i e n t o

D e f i n i r l o q u e h a r á e l s i s t e m a .T r a b a j a r c o n e l e x p e r t o p a r a

p l a n i f i c a r e l d e s a r r o l l o .

A p r e n d e r c ó m o e l e x p e r t or e s u e l v e e l p r o b l e m a y d e s a r r o l l a ru n m o d e l o c o n c e p t u a l d e l s i s t e m a

D e c id i r l a r e p r e s e n t a c i ó n d e lc o n o c i m i e n t o y l o s f o r m a l i s m o s d e

c o n t r o l p a r a im p l e m e n t a r e lm o d e l o c o n c e p t u a l

S e g u i r e l d i s e ñ o d eim p l e m e n t a c i ó n p a r a c o n s t r u i r l a

b a s e d e c o n o c i m i e n t o s

C o m p r o b a r s i e l s i s t e m a f u n c i o n ac o r r e c t a m e n t e

I n s t a l a r e l s i s t e m a e n e l d o m i n i od e u s o r u t i n a r i o

C o r r e g i r e r r o r e s , a c t u a l i z a r ya u m e n t a r e l s i s t e m a

30


Prototipado rápido y desarrollo incrementalLos prototipos construidos son una ayuda para el proceso de adquisición del conocimientoLa fase de utilización empieza cuando el sistema se instala en el entorno en que se usará de forma rutinariaLa fase de mantenimiento posterior puede evidenciar errores, que hay que corregir, o recoger sugerencias de los usuarios, que hay que implementar

31


Las características de esta metodología son muy parecidas a las de la metodología de González-DankelLa metodología de Scott pone especial énfasis en la adquisición del conocimientoLa adquisición del conocimiento está presente en todo el proceso

0 10 20 30 40 50 60 70 80 90 100

Identificación

Familiarización

Diseño de implementación

Evaluación

Mantenimiento

32


Dos fases típicas en el proceso de adquisición del 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 desarrollarloAparece en el análisis y en la especificación

– Adquisición detalladaEl foco de atención es más estrecho y profundo. El proceso es mucho más detallado. Permite la comprensión del modusoperandi de los expertos.Aparece en el desarrollo y en la utilización.

33

METODOLOGÍA DE DESARROLLO EN ESPIRAL

VR

Verificaciónde Requisitos

(VR)

Adquisición delconocimiento

(AC)

VRVR

VR

AC

AC

AC

AC

Análisis deRequisitos

(AR)

AR

AR

AR

AR

Prototipo deinvestigación

Prototipo decampo

Modelo deproducción

Prot. de-mostración

Grupo decontrol

Verificación

Test decampo

Casos de TestRecolección

de datos

Prototipado

Verificación

Validación

Fijar un nivelaceptable de

rendimiento(NAR)

NAR

NAR

NAR

NAR

Inicio del ciclo

34


Proceso 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?

35



– 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

36



– PrototipadoEl desarrollo incremental a través de una serie de prototipos permite que en cada ciclo se fijen los requisitos apropiadosPara que un prototipo sea útil hay que validarloLas 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

37



– Implementación y mantenimientoUna vez desarrollado el prototipo podemos…

– Utilizarlo como fuente de especificaciones– Hacer evolucionar el prototipo hasta convertirlo en un sistema de

producción operativoCuando 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

38

TIPOS DE PROTOTIPOS

Prototipo de demostraciónPrototipo de investigaciónPrototipo de campoModelo de producciónSistema comercial

39


Verificación

Validación

Evaluación

40


Verificació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

41


Validació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

42


Evaluació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

43

VERIFICACIÓN DE SISTEMAS

Verificación del cumplimiento de las especificacionesVerificación de los mecanismos de inferenciaVerificación de la base de conocimientos– Verificación de consistencia– Verificación de la completitud– Influencia de las medidas de incertidumbre

44

VERIFICACIÓN DEL CUMPLIMIENTO DE LAS ESPECIFICACIONES

Personal potencialmente involucrado:– Desarrolladores– Usuarios– Expertos– Grupo de evaluadores independientes

Aspectos 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

45

VERIFICACIÓN DE LOS MECANISMOS DE INFERENCIA

Pierde importancia con la utilización de entornos de desarrollo comercialesEl problema se transfiere hacia la elección de la herramienta adecuadaExcepciones:– 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

46

VERIFICACIÓN DE LA BASE DE CONOCIMIENTOS

Es responsabilidad del ingeniero del sistemaGeneralmente se basa en el concepto de anomalíasUna anomalía es un uso extraño del esquema de representación del conocimientoUna anomalía debe ser considerada como un error potencial– Hay anomalías que resultan de errores– Hay anomalías que no constituyen errores

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ánticasPremisas o conclusiones de una regla no son idénticas en la sintaxis, pero sí lo son en el significadoP (x) y Q (x) → R (x) = TormentaQ (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

48


Reglas conflictivas– Premisas idénticas pero conclusiones

contradictoriasP (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

49


Reglas englobadas en otrasP (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

50


Reglas circularesP (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)

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 reglaSDD:

– 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

52

INFLUENCIA DE LAS MEDIDAS DE INCERTIDUMBRE

Redundancia– 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 evidencial

Condiciones IF innecesarias– Mismo caso que el anterior

Reglas 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

53

ASPECTOS GENERALES DE LA VALIDACIÓN DE SISTEMAS

Validar– 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

54

ASPECTOS GENERALES DE LA VALIDACIÓN DE SISTEMAS

La validación orientada a los resultados es previa a la validación orientada al usoLa validación orientada al uso está cercana a los 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

55

PERSONAL INVOLUCRADO EN LA VALIDACIÓN

Ingeniero delconocimiento

Expertohumano Usuarios

finales

Evaluadoresindependientes

Validación delsistema

La 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

56

PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS

Resultados finales– Performance general del sistema

Resultados intermedios– Descripción del funcionamiento interno del sistema– Permite corregir errores cometidos

Razonamiento 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

57


Resultado(Balance ácido-base)

ACIDOSIS METABÓLICA

Valor esperadoACIDOSIS METABÓLICA Y

RESPIRATORIA

≠

Paciente

GasometríaspCO2 = 48 mmHgpH = 7.32[HCO3]−= 17 mg / l

ContextoNo presenta fallorenal

RazonamientoDatos

SISTEMA EXPERTO

Analizando los resultados intermedios comprobamos que hay un error en la interpretación del pCO2…

58


SISTEMA EXPERTO Resultado(Balance ácido-base)

ACIDOSIS METABÓLICA YRESPIRATORIA


RESPIRATORIA

=Razonamiento

previo

Resultados intermedios

Estado_pCO2 = Normal ⇒ AltoEstado_pH = BajoEstado_HCO3 = Bajo

IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO ⇓IF pCO2 > 46 mmHg THEN Estado_pCO2 = ALTO

Razonamientofinal



Corregido el error, las conclusiones son ahora correctasPero… 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”

59


SISTEMA EXPERTO Resultado(Balance ácido-base)

ACIDOSIS METABÓLICA YRESPIRATORIA


RESPIRATORIA

=Razonamiento

previo

Resultados intermedios

Estado_pCO2 = AltoEstado_pH = BajoEstado_HCO3 = Bajo

Razonamientofinal

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



60

CASUÍSTICA DE LA VALIDACIÓN

Dos 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 representativa

Proceso– 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

61

VALIDACIÓN CONTRA EL EXPERTO

Se utilizan las opiniones y las interpretaciones de los expertos humanos como criterio de validaciónPuede haber discrepancias entre expertos o sesgos 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

62

VALIDACIÓN CONTRA EL EXPERTO

Hay 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 expertosVentajas

– 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 expertosVentajas

– En teoría es el método más objetivo y fiableInconvenientes

– Puede haber un experto especialmente influyente– ¿Cómo se mide el consenso?

63

VALIDACIÓN CONTRA EL PROBLEMA

Nuestro sistema: ¿acierta realmente, o resuelve convenientemente, 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 aumenta

Inconvenientes– Falacia del superhombre– No siempre puede realizarse una validación contra el

problema

64

MOMENTO EN QUE SE REALIZA LA VALIDACIÓN

Bachant 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

65

MÉTODOS DE VALIDACIÓN

Métodos cualitativos– Emplean técnicas subjetivas de comparación de rendimientos

Validación superficialPruebas de TuringPruebas de campoValidación de subsistemasAnálisis de sensibilidadGrupos de control

Métodos cuantitativos– Emplean técnicas estadísticas de comparación de rendimientos

Medidas de paresMedidas de grupoRatios de acuerdo

66

MÉTODOS DE VALIDACIÓN

Medidas de pares– Medidas de acuerdo

Índice de acuerdoÍndice de acuerdo en unoKappaKappa ponderada

– Medidas de asociaciónTau de KendallTau B de KendallRho de SpearmanGamma de Goodman-Kruskal

Medidas de grupo– Medidas de Williams– Análisis clúster– Escalamiento multidimensional– Medidas de dispersión y tendencias

Ratios de acuerdo– Sensibilidad– Especificidad– Valor predictivo positivo– Valos predictivo negativo– Índice de acuerdo– Medida de Jaccard

67

OTRAS MEDIDAS

Coeficientes de exactitudDistancias aritméticasCurvas ROC…

0.9

1

0.8

0.7

0.6

0.5

0.4

0.3

0.2

0.1

00 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

TP

FP

0.9

0.7

0.5

0.3

0.1

0.05

68

ERRORES COMETIDOS EN LA VALIDACIÓN

Errores de comisiónErrores por omisión

DECISIÓN CORRECTA

ERROR TIPO IRiesgo para ingeniero

Sistema no aceptado como válido

ERROR TIPO IIRiesgo para usuario

DECISIÓN CORRECTA

Sistema aceptado como válido

Sistema no válidoSistema válido

69

Un ejemplo de validación

70


71


PATRICIA

Experto Colaborador

Médico que atendió el caso (clínico)

119 casos reales

Porcentajes de acuerdo totales en todas las categorías

Clínico vs.Experto Colaborador

Clínico vs.Sistema Experto

Sistema Experto vs.Experto Colaborador

79%

78%

92%

72


Equipo Médico

147 casos reales

PATRICIA

Porcentajes de acuerdo por categoría diagnóstica

Oxigenación 92%

Balance Ácido-Base 74%

Hemodinámica 87%

Terapia Ventilatoria 71%

73


Característicasde los casos

SistemaExperto

2

Resultados de lavalidación

Validación

3

Interpretacionesde los casos

Dominio UCI:– No es fácil establecer

referencias estándar– Nunca podríamos asegurar

que las interpretaciones y prescripciones de un experto sigan siempre los mismos principios

– El estrés y el entorno contribuyen a desvirtuar comportamientos

– Pueden aparecer soluciones equivalentes aunque no idénticas

Referenciaestándar

Casos deprueba

1

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.

75


Esquema de la validación formal de PATRICIA

– 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.

76

Un ejemplo de validaciónEtapas:– Labores de interpretación

OXIGENACIONBALANCE ACIDO-BASERESPIRACION ENDOGENAPRESION ARTERIALFRECUENCIA CARDIACA

– Labores de sugerencias terapéuticasMANEJO OXIGENATORIOMANEJO VENTILATORIO

77


Medidas 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

78

Un ejemplo de validaciónBalance Ácido-Base

Porcentajes de acuerdo total vs pares de comparación

0

20

40

60

80

100

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 comparación

Porc

enta

je d

e ac

uerd

o

Porcentajes de acuerdo "dentro de uno" vs pares de comparación

0

20

40

60

80

100



% "

dent

ro d

e un

o"

79


Valores de kappa vs. pares de comparación

0.00

0.20

0.40

0.60

0.80

1.00



Kapp

a

Valores de kappa ponderada vs. pares de comparación

0.00

0.20

0.40

0.60

0.80

1.00



Kapp

a po

nder

ada

80

Kappa

0.000.200.400.600.801.001.201.401.601.802.00

A B C D E F G

Expertos

Med

idas

de

Will

iam

s

Kappa ponderada

0.000.200.400.600.801.001.201.401.601.802.00

A B C D E F G

Expertos

Med

idas

de

Will

iam

s

Porcentajes de acuerdo

0.000.200.400.600.801.001.201.401.601.802.00

A B C D E F G

Expertos

Med

idas

de

Will

iam

s

Porcentajes "dentro de uno"

0.000.200.400.600.801.001.201.401.601.802.00

A B C D E F G

Expertos

Med

idas

de

Will

iam

s


81

USABILIDAD DE SISTEMAS

Mé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 delusuario

Mé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

82

MÉTODOS HEURÍSTICOS

Análisis del sistema y detección de problemas de amigabilidad y calidad

– Cuestionarios ergonómicos

– Inspección de interfaces

– Evaluación de la navegación

– Análisis formales

83

MÉTODOS SUBJETIVOS

Conocimiento de la opinión de los usuarios sobre la propia usabilidad del sistema

– Pensar en alto

– Observación

– Cuestionarios

– Entrevistas

– Grupos de control

– Retroalimentación con el usuario

84

EJEMPLOS DE CUESTIONARIOS CERRADOS

¿ P u e d e re a liz a rs e . . .? E s c a la s im p le

E s c a la m u lt ip u n to

E s c a la d e L ic k e r t

E s c a la d i fe r e n c ia l s e m á n t ic a

E s c a la d e o r d e n

P E G A R

N O N O N S /N C

¿ E s tá d e a c u e rd o c o n . . .? C o m p le ta m e n te d e a c u e rd o

C o m p le ta m e n te e n d e s a c u e rd o E n d e s a c u e rd o

L ig e ra m e n te e n d e s a c u e rd o N e u t ra l

L ig e ra m e n te d e a c u e rd o D e a c u e rd o

C o m p le ta m e n te d e a c u e rd o

C o m p le ta m e n te e n d e s a c u e rd o

¿ E s tá d e a c u e rd o c o n . . .?

C la s if ic a e l m ó d u lo . . . d e a c u e rd o a lo s s ig u ie n te s p a rá m e t ro s

E x t re m a d a -m e n te B a s ta n te L ig e ra m e n te N e u tra l L ig e ra m e n te B a s ta n te

E x t re m a d a -m e n te

F á c il D if íc i l

C la ro C o n fu s o

O rd e n a lo s s ig u ie n te s c o m a n d o s s e g ú n s u u t i l id a d

A G R U P A RD U P L IC A R B O R R A R

S I

85

MÉTODOS EMPÍRICOS

Se trata de sacar conclusiones basadas en datos objetivos obtenidos sobre cómo los usuarios utilizan el sistema

– ExactitudNúmero de errores provocados durante un determinado lapso de tiempo

– VelocidadCeleridad en la interacción con el sistema

– Exactitud y velocidad son magnitudes inversamente proporcionales

86

MEDIDAS OBJETIVAS DE USABILIDAD

Número de tareas diversas que pueden realizarse en un determinado periodo de tiempo

Proporción entre interacciones correctas y errores

Número de errores cometidos por el usuario

Tiempo consumido en la realización de una tarea específica

Tiempo consumido en la recuperación de errores

Número de características del sistema que son utilizadas por losusuarios

87

RESUMEN

Verificación, validación y análisis de usabilidad son fundamentales para desarrollar software de calidadEstas fases deben formar parte del ciclo de desarrollo del sistemaLas metodologías de desarrollo y diseño deben incluir explícita y específicamente la ubicación idónea de las tareas de verificación, validación y usabilidadLa realización de estas tareas requiere el dominio de técnicas específicasLa evaluación de sistemas debe ser contemplada como un proceso global de análisis de la performance del sistema en cuestión

validacion de usabilidad de sistema informatico

Education