validación y usabilidad de sistemas informáticos

8/18/2019 VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOS

1/87

1

VALIDACIÓN Y USABILIDAD DESISTEMAS INFORMÁTICOS

(1ª Parte)

Curso de DoctoradoDistinguido con la Mención de Calidad

Vicente Moret BonilloEduardo Mosqueira ReyElena Hernández Pereira


2/87

2

VALIDACIÓN Y USABILIDAD DE SISTEMAS

INFORMÁTICOS

FORMATO DEL CURSO

– Primera parteAspectos generales de la validación y el análisis deusabilidad 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/87

3


INFORMÁTICOSAlgunas diferencias entre sistemas inteligentes ysistemas convencionales

Información sin incertidumbreInformación con incertidumbre

Información numéricaInformación numérica y simbólica

Tipo de informaciónutilizada

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

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

Naturaleza delconocimiento

empleado

No siempre es necesaria la interactividadSon altamente interactivos

Resuelven problemas a través del manejo de informaciónalmacenada 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 sinambigüedad y que son resueltos por algoritmos

específicos.

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

heurístico.Problemas

apropiados

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

estructuración

Se suelen construir a partir de herramientas (“shells”) comercialesque 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/87

4


INFORMÁTICOS

Las características diferenciales, estructurales y

funcionales de los sistemas inteligentes condicionanenormemente los procesos de validación, pero no tantolos análisis de usabilidad

Los 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


5/87

5


INFORMÁTICOS

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

Expertohumano

Ingeniero delconocimiento

1

Ejemplos y

casos históricos

2

Textos

Expertohumano

3

4

Programainteligentede edición

Textos5

Programa deinducción

Programa decomprensión

de textos

FUENTE DECONOCIMIENTO

MODO DE A DQ UISIC IÓ N

Manuales

Semi-automáticos

Automáticos


6/87

6


INFORMÁTICOS

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 lascosas, suelen encontrarse cómodos cuando de lo que se trata es deinterpretar 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/87

7


INFORMÁTICOS

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 delsistema inteligente es el colectivo de expertos humanos

Pero… ¿quién valida al validador?

Cuestión abierta para el debate


8/87

8


INFORMÁTICOS

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 losmétodos procedimentales, suelen ser más flexibles, más eficaces, ymás eficientes

El 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


9/87

9


INFORMÁTICOS

EL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA

Herramienta 1

Paradigma 1

Esquema1

Desarrolloincremental

Esquema2

Herramienta 2

Paradigma 2

Desarrolloincremental

Paradigmasinapropiados

Cambio deparadigmas

C ontinuar sincambios

Retraso en elproyecto

Dificultades enel diseñ o


10/87

10


INFORMÁTICOS

EL PROBLEMA DEL DESPLAZAMIENTO DELPARADIGMA – Surge cuando en la fase de desarrollo se detecta que alguno de

los esquemas de representación, modelos de razonamiento, oentornos 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 deusabilidad

– ¿Debemos replantear el proyecto?

Retraso del proyecto y pérdidas económicas – Si el desplazamiento del paradigma ocurre en etapastempranas, puede se beneficioso, ya que permite ajustar yoptimizar las técnicas de desarrollo


11/87

11


INFORMÁTICOS

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-Shafer Cuasi-estadísticosInciertos

Bayes, redes de creenciaEstadísticosEstadísticos

CategóricosSimbólicos

EJEMPLOSMODELOSDOMINIOS


12/87

12


INFORMÁTICOS

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/87

13


INFORMÁTICOS

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 coninformación imprecisa

– Aspectos relacionados con los mecanismossegún los cuales podemos inferirconocimiento a partir de datos inciertos


14/87

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 herramientasCASE y análisis estructurados

– Mantener una descripción detallada de la situación del proyectoen cada momento

– Optimizar el personal dedicado al desarrollo: poco pero conexperiencia – Mejorar el proceso adoptando diferentes métodos y técnicas


15/87

15

METODOLOGÍAS DE DESARROLLO

– Algunos ejemplos de metodologías:

Adquiere y codifica

Método de Buchanan

Diseño incrementalMétodo de González-Dankel

Método de Scott

Desarrollo en espiral


16/87

16

ADQUIERE Y CODIFICA

Similar 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 el

experto 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


17/87

17

METODOLOGÍA DE DESARROLLO DE BUCHANAN

Requisitos

Conceptualización

Formalización

Implementación

Prueba

Identificación

Conceptos

Estructuras

Reglas

R e f i n a m i e n

t o s

R e d i s e ñ o s

Reformulaciones


18/87

18


Identificación – Se reconocen aspectos importantes del problema:

Participantes – Expertos del dominio – Ingenieros de conocimiento – Usuarios

Características del problema – Tipo

– Subtareas – TerminologíaRecursos disponibles

– Fuentes de conocimiento – Recursos computacionales – Tiempo de desarrollo

– FinanciaciónMetas – Formalización del conocimiento del experto – Distribución de experiencia – Formación de nuevos expertos


19/87

19


Conceptualización

– Organización del conocimiento según unesquema 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/87

20


Formalización

– Proceso de traducción de…Conceptos clave

Subproblemas

Características del flujo de información

– Construcción de representaciones formalesbasadas en…

Herramientas de desarrolloEsquemas de ingeniería del conocimiento


21/87

21


Elicitación

– Extracción del conocimientoSoporte físico

Proceso consistente con la información obtenida

en fases anteriores: – Identificación

– conceptualización


22/87

22


Implementación

– Formulación de reglas – Formulación de estructuras de control

– Obtención de un prototipoPermite comprobar si hemos conceptualizado bienel conocimiento del dominio

Permite comprobar si hemos formalizado bien el

conocimiento del dominio


23/87

23


Prueba

– Evaluación del rendimiento del prototipoconstruido

– Identificación de errores

– Identificación de anomalías en…Base de conocimientos

Mecanismos de inferencia


24/87

24


Los lazos de realimentación no tienen por qué seguir estrictamentela secuencia del esquema propuesto por Buchanan

Las retroalimentaciones pueden aparecer entre cualquier par defases de la metodología

Conceptualización

FormalizaciónImplementación

Prueba

Identificación


25/87

25

METODOLOGÍA DE DESARROLLO

INCREMENTAL

Desarrollo iterativo de sistemas

Proceso cíclico de desarrolloEn cada ciclo se efectúa un refinamiento – Proceso de depuración de errores en la base de

conocimientos

En cada ciclo se efectúa una extensión delsistema – Ampliación de las capacidades del mismo

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


26/87

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/87

27


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 inicialEsquema 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 – PruebaFase de verificación-validación

– Ajuste de diseño y mantenimientoPueden aparecer desplazamientos del paradigma


28/87

28


SCOTT

Se divide en 4 fases:

– Fase de análisisSe investiga la viabilidad del proyecto

– Fase de especificación

Se inicia el proyecto y de fijan las bases deldesarrollo

– Fase de desarrolloSe realiza el diseño y se implementa el sistema

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


29/87

29


SCOTT

U T IL IZ A C IÓ N

D E S A R R O L L O

E S P E C IF IC A C I Ó N

A N Á L IS IS

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 is 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 l u 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 ic 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 lc o n o c i m i e n t o

D e f in i r lo 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 ic 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 r u 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 i m 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 ir 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 in i od e u s o r u t in 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 iz a r ya u m e n t a r e l s i s t e m a


30/87

30


SCOTTPrototipado rápido y desarrollo incremental

Los prototipos construidos son una ayuda parael 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 puedeevidenciar errores, que hay que corregir, orecoger sugerencias de los usuarios, que hayque implementar


31/87

31

METODOLOGÍA DE DESARROLLO DE SCOTT

Las características de esta metodología son muy parecidas a las dela metodología de González-Dankel

La metodología de Scott pone especial énfasis en la adquisición delconocimientoLa 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 im plem entación

Evaluación

Mantenimiento


32/87

32

METODOLOGÍA DE DESARROLLO DE SCOTT

Dos fases típicas en el proceso de adquisición

del conocimiento: – Adquisición inicialFase preparatoria en la que la información obtenida nospermite tener un conocimiento más amplio de lo que debehacer el sistema, de cómo va a ser usado, y de cómo hayque desarrollarloAparece en el análisis y en la especificación

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


33/87

33

METODOLOGÍA DE DESARROLLO EN ESPIRAL

VR

Verificaciónde Requisi tos

(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/87

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 laorganización?


35/87

35



– Adquisición del conocimiento

El conocimiento extraído de una determinadafuente, y posteriormente transformado en unesquema de representación dado, debe ser

verificado


36/87

36



– PrototipadoEl desarrollo incremental a través de una serie de prototipospermite que en cada ciclo se fijen los requisitos apropiados

Para que un prototipo sea útil hay que validarloLas técnicas de verificación y de validación van a dependerde:

– Las características del sistema

– Las características del dominio de aplicación – La etapa de desarrollo en que nos encontremos


37/87

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


38/87

38

TIPOS DE PROTOTIPOS

Prototipo de demostraciónPrototipo de investigación

Prototipo de campoModelo de producción

Sistema comercial


39/87

39


INFORMÁTICOS

Verificación

Validación

Evaluación


40/87

40


INFORMÁTICOS

Verificación:

– Comprobación de que estamos construyendoel sistema correctamente

– Comprobar que el sistema no contiene

errores de implementación – Comprobar que el sistema cumple con las

especificaciones inicialmente definidas


41/87

41


INFORMÁTICOS

Validación:

– Comprobación de que estamos construyendoel sistema correcto

– Comprobar que el sistema produce la salida

correcta – Comprobar que el sistema cumple con las

necesidades y los requisitos del usuario


42/87

42


INFORMÁTICOS

Evaluación:

– Análisis de aspectos que van más allá de lacorrecció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/87

43

VERIFICACIÓN DE SISTEMAS

Verificación del cumplimiento de las

especificacionesVerificación de los mecanismos deinferencia

Verificación de la base de conocimientos – Verificación de consistencia

– Verificación de la completitud – Influencia de las medidas de incertidumbre


44/87

44

VERIFICACIÓN DEL CUMPLIMIENTO DE LAS

ESPECIFICACIONES

Personal 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


45/87

45

VERIFICACIÓN DE LOS MECANISMOS DE INFERENCIA

Pierde importancia con la utilización de entornosde desarrollo comerciales

El problema se transfiere hacia la elección de laherramienta adecuadaExcepciones:

– Dominios críticos – Desconocimiento sobre el funcionamiento exacto dela herramienta

– Los procedimientos de resolución de conflictos o los

procesos de búsqueda implementados puedendificultar el seguimiento de los mecanismos deinferencia


46/87

46

VERIFICACIÓN DE LA BASE DE CONOCIMIENTOS

Es responsabilidad del ingeniero del sistema

Generalmente se basa en el concepto deanomalías

Una anomalía es un uso extraño del esquema

de 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

Ó


47/87

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óndel sistema se cambie una regla pero no la otra

Ó


48/87

48


CONOCIMIENTOS

Reglas conflictivas

– Premisas idénticas pero conclusionescontradictorias

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 hayparámetros multivaluados

Ó


49/87

49


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 deresolución de conflictos

– Normalmente la eficiencia del sistema se

incrementa con el empleo de reglas másrestrictivas



50/87

50


CONOCIMIENTOS

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 BP (x) y Q (x) → R (x)Not Q (x) → R (x)Solución

– P (x) → R (x) – Not Q (x) → R (x)

VERIFICACIÓN DE LA COMPLETITUD DE LA BASE DE


51/87

51

VERIFICACIÓN DE LA COMPLETITUD DE LA BASE DE

CONOCIMIENTOSValores 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 premisade 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


52/87

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 evidencialCondiciones 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 puedeconvertirse en “sin salida” cuando su conclusión tiene una certidumbre pordebajo del umbral establecido como “conocido” o “significativo”

Reglas inalcanzables – Mismo caso que el anterior

ASPECTOS GENERALES DE LA VALIDACIÓN DE


53/87

53


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 deusuario

Tipos – Validación orientada a los resultados (VOR) – Validación orientada al uso (VOU)

Assessment o Valoración



54/87

54


SISTEMAS

La validación orientada a los resultados esprevia a la validación orientada al uso

La 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


55/87

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 sistemainteligente es un modelo computacional del conocimiento de losexpertos humanos


56/87

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” comolo haría un experto humano… también en la forma


57/87

57


Resultado(Balance ácido-base)

ACIDOSIS METABÓLICA

Valor esperado

ACIDOSIS METABÓLICA YRESPIRATORIA

≠

Paciente

GasometríaspCO2 = 48 mmHgpH = 7.32[HCO3]

−= 17 mg / l

Contexto

No presenta fallorenal

RazonamientoDatos

SISTEMA EXPERTO

Analizando los resultados intermedioscomprobamos que hay un error en la

interpretación del pCO2…


58/87

58


SISTEMA EXPERTO Resultado

(Balance ácido-base)ACIDOSIS METABÓLICA Y

RESPIRATORIA

Valor esperado

ACIDOSIS METABÓLICA Y

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


−= 17 mg / l

Contexto


Corregido el error, las conclusiones son ahora correctasPero… persiste todavía un error que no detectamos sino seguimos el proceso de razonamiento, y si no se nospresenta, durante la validación, el caso de un “fallorenal”

R S S S Q S R S


59/87

59


SISTEMA EXPERTO Resultado(Balance ácido-base)

ACIDOSIS METABÓLICA YRESPIRATORIA

Valor esperado

ACIDOSIS METABÓLICA Y

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


−= 17 mg / l

Contexto


CASUÍSTICA DE LA VALIDACIÓN


60/87

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 estamostratando

La 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ónen el que se analiza el rendimiento del sistema

VALIDACIÓN CONTRA EL EXPERTO


61/87

61


Se utilizan las opiniones y las interpretacionesde los expertos humanos como criterio de

validació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 queestán validando y, por lo tanto, no ser objetivos



62/87

62


Hay tres procedimientos diferentes: – Validación contra un único experto

Ventajas

– Suele haber al menos un experto disponibleInconvenientes

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

VALIDACIÓN CONTRA EL PROBLEMA


63/87

63

VALIDACIÓN CONTRA EL PROBLEMA

Nuestro 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, lacredibilidad del sistema aumenta

Inconvenientes

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

MOMENTO EN QUE SE REALIZA LA


64/87

64

VALIDACIÓNBachant y McDermott – Validar un sistema que no está terminado puede no ser útil

– Las interpretaciones del sistema pueden no ser correctas si noestá implementado todo el conocimiento

Buchanan 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 prospectivaSobre casos reales todavía no resueltos y análisis de lasinterpretaciones propuestas

MÉTODOS DE VALIDACIÓN


65/87

65


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/87

66


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

OTRAS MEDIDAS


67/87

67

OTRAS MEDIDAS

Coeficientes de exactitud

Distancias 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

ERRORES COMETIDOS EN LA VALIDACIÓN


68/87

68

ERRORES COMETIDOS EN LA VALIDACIÓN

Errores de comisiónErrores por omisión

DECISIÓNCORRECTA

ERROR TIPO I

Riesgo para ingeniero

Sistema no aceptadocomo válido

ERROR TIPO II

Riesgo para usuario

DECISIÓN

CORRECTA

Sistema aceptado

como válido

Sistema no válidoSistema válido

Un ejemplo de validación


69/87

69




70/87

70




71/87

71


PATRICIA

Experto Colaborador

Médico que atendió el

caso (clínico)

119 casos

reales

Porcentajes de acuerdo totales entodas las categorías

Clínico vs.Experto Colaborador

Clínico vs.Sistema Experto

Sistema Experto vs.Experto Colaborador

79%

78%

92%



72/87

72


Equipo Médico

147 casos

reales

PATRICIA

Porcentajes de acuerdo porcategoría diagnóstica

Oxigenación 92%

Balance Ácido-Base 74%

Hemodinámica 87%

Terapia Ventilatoria 71%



73/87

73


Característicasde los casos

SistemaExperto

2

Resultados de la

validación

Validación

3

Interpretacionesde los casos

Dominio UCI: – No es fácil establecer

referencias estándar – Nunca podríamos asegurarque las interpretaciones yprescripciones de unexperto sigan siempre los

mismos principios – El estrés y el entorno

contribuyen a desvirtuarcomportamientos

– Pueden aparecersoluciones equivalentesaunque no idénticas

Referenciaestándar

Casos deprueba

1



74/87

74


Criterios con carácter general:

– Si el dominio de aplicación es un dominio crítico, en el que no esposible 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 talreferencia es muy difícil de obtener, la validación debe llevarse acabo 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/87

75


Esquema 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 PATRICIAdentro del grupo de expertos colaboradores.



76/87

76

j p

Etapas:

– Labores de interpretaciónOXIGENACIONBALANCE ACIDO-BASERESPIRACION ENDOGENA

PRESION ARTERIALFRECUENCIA CARDIACA

– Labores de sugerencias terapéuticasMANEJO OXIGENATORIOMANEJO VENTILATORIO



77/87

77

j p

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/87

78

j p

Balance Ácido-BasePorcentajes de acuerdo total vs pares de com paració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

P o r c e n t a j e d e a c u e r d o

Porcentajes de acuerdo "dent ro de uno" vs pares de comparación

0

20

40

60

80

100


Pares de comparación

% " d e n t r o d e u n o "



79/87

79

j p

Balance Ácido-Base

Valores de kappa vs. pares de comparación

0.00

0.20

0.40

0.60

0.80

1.00


Pare s de com paración

K a p p a

Valores de kappa ponderada vs. pares de comparación

0.00

0.20

0.40

0.60

0.80

1.00


Pare s de com paración

K a p p a p o n d e r a d a



80/87

80

Kappa

0.000.200.400.600.801.001.201.401.601.80

2.00

A B C D E F G

Expertos

M e d i d a s d e W i l l i a m s

Kappa pond erada

0.000.200.400.600.801.001.201.401.601.80

2.00

A B C D E F G

Expertos


Porcentajes de acuerdo

0.000.200.400.600.801.001.20

1.401.601.802.00

A B C D E F G

Expertos


Porcentajes "dentro d e uno"

0.000.200.400.600.801.001.20

1.401.601.802.00

A B C D E F G

Expertos


j pBalance Ácido-Base

USABILIDAD DE SISTEMAS


81/87

81

Métodos heurísticos – Técnicas heurísticas, desarrolladas por expertos, que analizan

los interfaces de los módulos, evalúan su arquitectura ydeterminan sus puntos fuertes y débiles desde la perspectiva delusuario

Métodos subjetivos

– Obtienen información de los usuarios sobre prototiposoperativos 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

MÉTODOS HEURÍSTICOS


82/87

82

Aná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

MÉTODOS SUBJETIVOS


83/87

83

Conocimiento 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

EJEMPLOS DE CUESTIONARIOS CERRADOS


84/87

84

¿ P u e d e r e a l iz a r s 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 f e r en c ia l s em á n t i c a

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

P E G A R

N ON O N S /N C

¿ E s t á d e a c u e r d o c o n . . .? C o m p l e t a m e n t ed e a c u e r d o

C o m p l e t a m e n t ee n d e s a c u e rd o E n d e s a c u e rd o

L i g e ra m e n t e e nd e s a c u e r d o N e u t r a l

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

C o m p l e t a m e n t ed e a c u e r d o

C o m p l e t a m e n t ee n d e s a c u e r d o

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

C l a s i fic a e l m ó d u l o . .. d e a c u e r d o a lo s s i g u ie n t e s p a r á m e t ro s

E x t re m a d a -m e n t e 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 t e

F á c i l D i f í c i l

C l a r o C o n f u s o

O r d e n a lo s s i g u ie n t e s c o m a n d o s s e g ú n s u u t ilid a d

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

S I

MÉTODOS EMPÍRICOS


85/87

85

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

sistema – Exactitud

Número de errores provocados durante un determinado lapso detiempo

– VelocidadCeleridad en la interacción con el sistema

– Exactitud y velocidad son magnitudes inversamenteproporcionales

MEDIDAS OBJETIVAS DE USABILIDAD


86/87

86

Número de tareas diversas que pueden realizarse en undeterminado 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

RESUMEN


87/87

87

Verificación, validación y análisis de usabilidad sonfundamentales para desarrollar software de calidad

Estas 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 las

tareas 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

validación y usabilidad de sistemas informáticos

Documents