Validacion de usabilidad de sistema informatico

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

2
VALIDACIÓN Y USABILIDAD DE SISTEMAS
INFORMÁTICOS
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 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

3
INFORMÁTICOS
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
INFORMÁTICOS
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
INFORMÁTICOS
Algunas técnicas útiles para la adquisición de conocimiento
Experto
humano
Ingeniero del
conocimiento
1
Ejemplos y
casos históricos
2
Textos
Experto
humano
3
4
Programa
inteligente
de edición
Textos
5
Programa de
inducción
Programa de
comprensión
de textos
FUENTE DE
CONOCIMIENTO
MODO DE
ADQUISICIÓN
Manuales
Semi-
automáticos
Automáticos

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

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 del
sistema inteligente es el colectivo de expertos humanos
Pero… ¿quién valida al validador?
Cuestión abierta para el debate

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 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 adecuado
Los procesos de razonamiento influyen sobre el paradigma de
representación
El paradigma de representación influye sobre los procesos de
razonamiento

9
INFORMÁTICOS
EL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA
Herram ienta 1
Paradigm a 1
Esquem a
1
D esarrollo
increm ental
Esquem a
2
Herram ienta 2
Paradigm a 2
D esarrollo
incremental
Paradigm as
inapropiados
C am bio de
paradigm as
C ontinuar sin
cambios
R etraso en el
proyecto
Dificultades en
el diseño

10
INFORMÁTICOS
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
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-ShaferCuasi-estadísticosInciertos
Bayes, redes de creenciaEstadísticosEstadísticos
CategóricosSimbólicos
EJEMPLOSMODELOSDOMINIOS

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
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 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 codifica
Método de Buchanan
Diseño incremental
Método de González-Dankel
Método de Scott
Desarrollo en espiral

16
ADQUIERE Y CODIFICA
Similar al procedimiento de “codifica y corrige”
No sigue un esquema preciso
El 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ído
Só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
Refinamientos
Rediseños
Reformulaciones

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

21
Elicitación
– Extracción del conocimiento
Soporte físico
Proceso 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 dominio
Permite 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 conocimientos
Mecanismos de inferencia

24
Los lazos de realimentación no tienen por qué seguir estrictamente
la secuencia del esquema propuesto por Buchanan
Las 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 sistemas
Proceso cíclico de desarrollo
En 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 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
GONZÁLEZ-DANKEL
Modelo de desarrollo que incorpora prototipado rápido y desarrollo
incremental
Fases:
– 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

28
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 desarrollo
Se realiza el diseño y se implementa el sistema
– Fase de utilización
Se habilita el sistema para su uso rutinario

29
SCOTT
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 if ic a c i ó n
V a l o r a c i ó n
F a m il 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 e
im 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 in a m i e n t o
y e x t e n s i ó n
I d e n t if ic a c i ó n d e l a p o t e n c i a l
a p l ic 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 ó n
d e l a s t é c n ic 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 in ir l o q u e h a r á e l s is 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 if 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 o
r 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 ll a r
u n m o d e l o c o n c e p t u a l d e l s is t e m a
D e c id ir l a r e p r e s e n t a c i ó n d e l
c o n o c i m i e n t o y l o s f o r m a lis 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 l
m o d e l o c o n c e p t u a l
S e g u ir e l d is e ñ o d e
im 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 is t e m a f u n c i o n a
c o r r e c t a m e n t e
I n s t a l a r e l s is t e m a e n e l d o m in i o
d e u s o r u t in a r i o
C o r r e g ir e r r o r e s , a c t u a li z a r y
a u m e n t a r e l s is t e m a

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

31
METODOLOGÍA DE DESARROLLO DE SCOTT
Las características de esta metodología son muy parecidas a las de
la metodología de González-Dankel
La metodología de Scott pone especial énfasis en la adquisición del
conocimiento
La 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
METODOLOGÍA DE DESARROLLO DE SCOTT
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 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.

33
METODOLOGÍA DE DESARROLLO EN ESPIRAL
VR
Verificación
de Requisitos
(VR)
Adquisición del
conocimiento
(AC)
VR
VR
VR
AC
AC
AC
AC
Análisis de
Requisitos
(AR)
AR
AR
AR
AR
Prototipo de
investigación
Prototipo de
campo
Modelo de
producción
Prot. de-
mostración
Grupo de
control
Verificación
Test de
campo
Casos de Test
Recolección
de datos
Prototipado
Verificación
Validación
Fijar un nivel
aceptable 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
– 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

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

38
TIPOS DE PROTOTIPOS
Prototipo de demostración
Prototipo de investigación
Prototipo de campo
Modelo de producción
Sistema comercial

39
INFORMÁTICOS
Verificación
Validación
Evaluación

40
INFORMÁTICOS
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
INFORMÁTICOS
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
INFORMÁTICOS
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
especificaciones
Verificación de los mecanismos de
inferencia
Verificació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 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

46
VERIFICACIÓN DE LA BASE DE CONOCIMIENTOS
Es responsabilidad del ingeniero del sistema
Generalmente se basa en el concepto de
anomalías
Una anomalía es un uso extraño del esquema
de representación del conocimiento
Una 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á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

48
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

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 de
resolución de conflictos
– Normalmente la eficiencia del sistema se
incrementa con el empleo de reglas más
restrictivas

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

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

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 conclusiones
Reglas 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 umbral
Reglas 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
usuario
Tipos
– 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 uso
La validación orientada al uso está cercana a
los estudios de usabilidad
Caracterí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 del
conocimiento
Experto
humano Usuarios
finales
Evaluadores
independientes
Validación del
sistema
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 esperado
ACIDOSIS METABÓLICA Y
RESPIRATORIA
≠
Paciente
Gasometrías
pCO2 = 48 mmHg
pH = 7.32
[HCO3]−
= 17 mg / l
Contexto
No presenta fallo
renal
RazonamientoDatos
SISTEMA EXPERTO
Analizando los resultados intermedios
comprobamos que hay un error en la
interpretación del pCO2…

58
SISTEMA EXPERTO Resultado
RESPIRATORIA
Valor esperado
RESPIRATORIA
=
Razonamiento
previo
Estado_pCO2 = Normal
⇒ Alto
Estado_pH = Bajo
Estado_HCO3 = Bajo
IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO
⇓
IF pCO2 > 46 mmHg THEN Estado_pCO2 = ALTO
Razonamiento
final
Gasometrías
pCO2 = 48 mmHg
pH = 7.32
[HCO3]−
= 17 mg / l
Contexto
No presenta fallo
renal
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”

59
SISTEMA EXPERTO Resultado
RESPIRATORIA
Valor esperado
RESPIRATORIA
=
Razonamiento
previo
Estado_pCO2 = Alto
Estado_pH = Bajo
Estado_HCO3 = Bajo
Razonamiento
final
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
Gasometrías
pCO2 = 48 mmHg
pH = 7.32
[HCO3]−
= 17 mg / l
Contexto
No presenta fallo
renal

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
tratando
La 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ón
Puede 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 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?

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 conocimiento
Buchanan y Shortliffe
– La validación del sistema debe estar presente a lo largo de todo
su ciclo de desarrollo
Aspectos 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 superficial
Pruebas de Turing
Pruebas de campo
Validación de subsistemas
Análisis de sensibilidad
Grupos de control
Métodos cuantitativos
– Emplean técnicas estadísticas de comparación de rendimientos
Medidas de pares
Medidas de grupo
Ratios de acuerdo

66
MÉTODOS DE VALIDACIÓN
Medidas 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-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 exactitud
Distancias aritméticas
Curvas ROC… 0.9
1
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
0 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ón
Errores por omisión
DECISIÓN
CORRECTA
ERROR TIPO I
Riesgo para ingeniero
Sistema no aceptado
como válido
ERROR TIPO II
Riesgo para usuario
DECISIÓN
CORRECTA
Sistema aceptado
como válido
Sistema no válidoSistema válido

71
Un ejemplo de validación
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ísticas
de los casos
Sistema
Experto
2
Resultados de la
validación
Validación
3
Interpretaciones
de 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
Referencia
estándar
Casos de
prueba
1

74
Criterios 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
Etapas:
– Labores de interpretación
OXIGENACION
BALANCE ACIDO-BASE
RESPIRACION ENDOGENA
PRESION ARTERIAL
FRECUENCIA CARDIACA
– Labores de sugerencias terapéuticas
MANEJO OXIGENATORIO
MANEJO 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
Balance Á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
Porcentajedeacuerdo
Porcentajes de acuerdo "dentro de uno" vs pares de comparación
0
20
40
60
80
100
%"dentrodeuno"

79
Balance Ácido-Base
Valores de kappa vs. pares de comparación
0.00
0.20
0.40
0.60
0.80
1.00
Kappa
Valores de kappa ponderada vs. pares de comparación
0.00
0.20
0.40
0.60
0.80
1.00
Kappaponderada

80
Kappa
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
A B C D E F G
Expertos
MedidasdeWilliams
Kappa ponderada
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
A B C D E F G
Expertos
MedidasdeWilliams
Porcentajes de acuerdo
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
A B C D E F G
Expertos
MedidasdeWilliams
Porcentajes "dentro de uno"
0.00
0.20
0.40
0.60
0.80
1.00
1.20
1.40
1.60
1.80
2.00
A B C D E F G
Expertos
MedidasdeWilliams
Balance Ácido-Base

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 del
usuario
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 ltip u n to
E s c a la d e L ic k e r t
E s c a la d ife re n c ia l s e m á n tic a
E s c a la d e o rd e n
P E G A R
N ON 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 tra 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
d e a c u e rd o
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 ific 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 tro s
E x tre 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 tre m a d a -
m e n te
F á c il D ifíc il
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 tilid 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
– 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

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

87
RESUMEN
Verificación, validación y análisis de usabilidad son
fundamentales para desarrollar software de calidad
Estas fases deben formar parte del ciclo de desarrollo
del sistema
Las 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 usabilidad
La realización de estas tareas requiere el dominio de
técnicas específicas
La 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

Más contenido relacionado

La actualidad más candente (20)

Destacado (8)

Similar a Validacion de usabilidad de sistema informatico (20)

Último (20)

Validacion de usabilidad de sistema informatico