1. VALIDACIÓN Y USABILIDAD DE
SISTEMAS INFORMÁTICOS
(1ª Parte)
Curso de Doctorado
Distinguido con la Mención de Calidad
Vicente Moret Bonillo
Eduardo Mosqueira Rey
Elena Hernández Pereira
1

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

3. VALIDACIÓN Y USABILIDAD DE SISTEMAS
INFORMÁTICOS
Algunas diferencias entre sistemas inteligentes y
sistemas convencionales
Sistemas Expertos Software convencional
Separación del conocimiento de las estructuras de control Separación de datos y algoritmos que utilizan los datos
Suelen incluir estructuras de explicación de las conclusiones No existen estructuras de explicación
Estructura
Existen gestores de bases de datos que nos permiten centrarnos
Se suelen construir a partir de herramientas (“shells”) comerciales
exclusivamente en los datos y no en su almacenamiento o
que permiten centrarse en el conocimiento
estructuración
Problemas mal definidos, que no pueden ser especificados con Problemas bien definidos, que pueden ser especificados sin
Problemas precisión y que son resueltos utilizando conocimiento ambigüedad y que son resueltos por algoritmos
apropiados heurístico. específicos.
Generalmente dominios sin experiencia computacional Generalmente dominios con experiencia computacional
Métodos declarativos y no determinísticos Métodos procedimentales y determinísticos
Intentan seguir líneas de razonamiento similares a las de los
Se centran en la solución y no en la forma en que se obtiene.
expertos humanos
Estrategias de Interpretan datos Manipulan datos
resolución
Resuelven problemas a través del manejo de información
Tienen en cuenta aspectos como la abstracción, la incertidumbre,
almacenada en bases de datos y mediante procesos
el aprendizaje, etc.
predecibles, fiables y exactos.
Son altamente interactivos No siempre es necesaria la interactividad
Naturaleza del
Conocimiento proveniente de la experiencia humana (alta Conocimiento de naturaleza algorítmica (alta interacción con
conocimiento
interacción con expertos) usuarios)
empleado
Tipo de información Información numérica y simbólica Información numérica
utilizada Información con incertidumbre Información sin incertidumbre
3

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

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

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

7. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
7

8. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
8

9. VALIDACIÓN Y USABILIDAD DE SISTEMAS
INFORMÁTICOS
EL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA
Desarrollo
incremental
Paradigma 2
Herramienta 2
Cambio de Esquema Retraso en el
Desarrollo paradigmas 2 proyecto
incremental
Paradigma 1
Paradigmas
Herramienta 1
Esquema inapropiados
1
Continuar sin Dificultades en
cambios el diseño
9

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

11. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
DOMINIOS MODELOS EJEMPLOS
Simbólicos Categóricos
Estadísticos Estadísticos Bayes, redes de creencia
Inciertos Cuasi-estadísticos FCs, Dempster-Shafer
Lingüísticos difusos
11

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

13. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
13

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
14

15. METODOLOGÍAS DE DESARROLLO
– Algunos ejemplos de metodologías:
Adquiere y codifica
Método de Buchanan
Diseño incremental
Método de González-Dankel
Método de Scott
Desarrollo en espiral
15

16. ADQUIERE Y 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
16

17. METODOLOGÍA DE DESARROLLO DE BUCHANAN
Identificación Requisitos
Conceptualización Conceptos
Formalización Estructuras
Reglas
Implementación
Reformulaciones
Rediseños
Refinamientos
Prueba
17

18. METODOLOGÍA DE DESARROLLO DE BUCHANAN
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
18

19. METODOLOGÍA DE DESARROLLO DE BUCHANAN
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
19

20. METODOLOGÍA DE DESARROLLO DE BUCHANAN
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
20

21. METODOLOGÍA DE DESARROLLO DE BUCHANAN
Elicitación
– Extracción del conocimiento
Soporte físico
Proceso consistente con la información obtenida
en fases anteriores:
– Identificación
– conceptualización
21

22. METODOLOGÍA DE DESARROLLO DE BUCHANAN
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
22

23. METODOLOGÍA DE DESARROLLO DE BUCHANAN
Prueba
– Evaluación del rendimiento del prototipo
construido
– Identificación de errores
– Identificación de anomalías en…
Base de conocimientos
Mecanismos de inferencia
23

24. METODOLOGÍA DE DESARROLLO DE BUCHANAN
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
Identificación
Prueba Conceptualización
Implementación Formalización
24

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
25

26. METODOLOGÍA DE DESARROLLO DE
GONZÁLEZ-DANKEL
Análisis Ajuste del diseño
Especificación
Implementación
Diseño preliminar
Prueba (V&V)
Prototipo inicial
Mantenimiento
Evaluación
Diseño final
26

27. METODOLOGÍA DE DESARROLLO DE
GONZÁLEZ-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
27

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

29. METODOLOGÍA DE DESARROLLO DE
SCOTT
ANÁLISIS
Identificación de la potencial
aplicación
Identificación
Comprobación de la adecuación
de las técnicas de ingeniería del
Valoración conocimiento
Definir lo que hará el sistema.
ESPECIFICACIÓN Trabajar con el experto para
Familiarización planificar el desarrollo.
Aprender cómo el experto
DESARROLLO
Diseño conceptual resuelve el problema y desarrollar
un modelo conceptual del sistema
Decidir la representación del
Diseño de conocimiento y los f ormalismos de
implementación control para implementar el
modelo conceptual
Refinamiento
y extensión Seguir el diseño de
Implementación
implementación para construir la
base de conocimientos
Evaluación Comprobar si el sistema funciona
correctamente
UTILIZACIÓN Instalar el sistema en el dominio
Pruebas de campo de uso rutinario
Corregir errores, actualizar y
aumentar el sistema
Mantenimiento
29

30. METODOLOGÍA DE DESARROLLO DE
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
30

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
Identificación
Fam iliarización
Diseño de im plem entación
Evaluación
Mantenim iento
0 10 20 30 40 50 60 70 80 90 100
31

32. METODOLOGÍA DE DESARROLLO DE 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.
32

33. METODOLOGÍA DE DESARROLLO EN ESPIRAL
Análisis de
AR
Requisitos
(AR)
AR
Verificación
AR de Requisitos
(VR)
VR
AR VR
VR
VR
Inicio del ciclo
AC
Casos de Test
Test de Adquisición del
Recolección campo Prot. de- NAR AC
de datos mostración
conocimiento
(AC)
Validación Verificación Prototipo de NAR AC
investigación
Grupo de AC
control NAR
Prototipo de
campo
Verificación
Modelo de NAR Fijar un nivel
Prototipado producción aceptable de
rendimiento(NAR)
33

34. METODOLOGÍA DE DESARROLLO EN ESPIRAL
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?
34

35. METODOLOGÍA DE DESARROLLO EN ESPIRAL
Proceso dividido en 4 fases:
– Adquisición del conocimiento
El conocimiento extraído de una determinada
fuente, y posteriormente transformado en un
esquema de representación dado, debe ser
verificado
35

36. METODOLOGÍA DE DESARROLLO EN ESPIRAL
Proceso dividido en 4 fases:
– Prototipado
El desarrollo incremental a través de una serie de prototipos
permite que en cada ciclo se fijen los requisitos apropiados
Para que un prototipo sea útil hay que validarlo
Las técnicas de verificación y de validación van a depender
de:
– Las características del sistema
– Las características del dominio de aplicación
– La etapa de desarrollo en que nos encontremos
36

37. METODOLOGÍA DE DESARROLLO EN ESPIRAL
Proceso dividido en 4 fases:
– Implementación y mantenimiento
Una vez desarrollado el prototipo podemos…
– Utilizarlo como fuente de especificaciones
– Hacer evolucionar el prototipo hasta convertirlo en un sistema de
producción operativo
Cuando el sistema está operativo…
– Tenemos que monitorizarlo
– Tenemos que comprobar su concordancia con los requisitos
– Tenemos que documentar su utilización en el entorno de trabajo
El mantenimiento exige…
– Realizar tareas de validación
– Detectar inconsistencias
– Asegurar la robustez del sistema
37

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

39. VALIDACIÓN Y USABILIDAD DE SISTEMAS
INFORMÁTICOS
Evaluación
Validación
Verificación
39

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

41. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
41

42. VALIDACIÓN Y USABILIDAD DE SISTEMAS
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
42

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
43

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
44

45. VERIFICACIÓN DE LOS MECANISMOS DE INFERENCIA
Pierde importancia con la utilización de entornos
de desarrollo comerciales
El problema se transfiere hacia la elección de la
herramienta adecuada
Excepciones:
– Dominios críticos
– Desconocimiento sobre el funcionamiento exacto de
la herramienta
– Los procedimientos de resolución de conflictos o los
procesos de búsqueda implementados pueden
dificultar el seguimiento de los mecanismos de
inferencia
45

46. VERIFICACIÓN DE LA BASE DE 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
46

47. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE
CONOCIMIENTOS
Reglas redundantes
– Redundancias sintácticas
P (x) y Q (x) → R (x)
Q (x) y P (x) → R (x)
– Redundancias semánticas
Premisas o conclusiones de una regla no son idénticas en la
sintaxis, pero sí lo son en el significado
P (x) y Q (x) → R (x) = Tormenta
Q (x) y P (x) → R (x) = Actividad eléctrica
– Las redundancias no siempre causan problemas lógicos,
aunque pueden afectar a la eficiencia del sistema
– Pueden aparecer problemas cuando en una eventual revisión
del sistema se cambie una regla pero no la otra
47

48. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE
CONOCIMIENTOS
Reglas conflictivas
– Premisas idénticas pero conclusiones
contradictorias
P (x) y Q (x) → R (x)
P (x) y Q (x) → not R (x)
– Aparecen peculiaridades cuando utilizamos
algunos modelos de tratamiento del
conocimiento inexacto, o cuando hay
parámetros multivaluados
48

49. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE
CONOCIMIENTOS
Reglas englobadas en otras
P (x) y Q (x) → R (x)
P (x) → R (x)
– No tiene por qué ser una anomalía
– Hay que definir una estrategia adecuada de
resolución de conflictos
– Normalmente la eficiencia del sistema se
incrementa con el empleo de reglas más
restrictivas
49

50. VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE
CONOCIMIENTOS
Reglas circulares
P (x) → Q (x)
Q (x) → R (x)
R (x) → P (x)
Condiciones IF innecesarias
– Caso A
P (x) y Q (x) → R (x)
P (x) y not Q (x) → R (x)
Solución
– P (x) → R (x)
– Caso B
P (x) y Q (x) → R (x)
Not Q (x) → R (x)
Solución
– P (x) → R (x)
– Not Q (x) → R (x)
50

51. VERIFICACIÓN DE LA COMPLETITUD DE LA BASE DE
CONOCIMIENTOS
Valores no referenciados de atributos
– Parte del conocimiento declarativo no está representado en el conocimiento
procedimental
Valores ilegales de atributos
Reglas inalcanzables
– Situación relacionada con la dirección de la búsqueda
SDO:
– La conclusión de una regla no aparece como objetivo y no aparece como parte de la premisa
de otra regla
SDD:
– La premisa de una regla no puede ser obtenida del exterior y no aparece como conclusión de
ninguna regla
Reglas sin salida
– Una regla inalcanzable para un SDO es una regla sin salida para un SDD
– Una regla inalcanzable para un SDD es una regla sin salida para un SDO
51

52. INFLUENCIA DE LAS MEDIDAS DE 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
52

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
53

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
54

55. PERSONAL INVOLUCRADO EN LA VALIDACIÓN
Ingeniero del Evaluadores
conocimiento independientes
Validación del
Experto sistema
humano Usuarios
finales
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
55

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
56

57. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS
SISTEMA EXPERTO Resultado
Gasometrías (Balance ácido-base)
pCO2 = 48 mmHg ACIDOSIS METABÓLICA
pH = 7.32 Razonamiento ≠
Datos −
[HCO3] = 17 mg / l
Valor esperado
Contexto
ACIDOSIS METABÓLICA Y
No presenta fallo RESPIRATORIA
Paciente renal
Analizando los resultados intermedios
comprobamos que hay un error en la
interpretación del pCO2…
57

58. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS
IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO
⇓
IF pCO2 > 46 mmHg THEN Estado_pCO2 = ALTO
SISTEMA EXPERTO Resultado
(Balance ácido-base)
Resultados intermedios
Gasometrías ACIDOSIS METABÓLICA Y
pCO2 = 48 mmHg RESPIRATORIA
Estado_pCO2 = Normal
pH = 7.32
−
[HCO3] = 17 mg / l ⇒ Alto =
Razonamiento Estado_pH = Bajo Razonamiento
Contexto Valor esperado
previo Estado_HCO3 = Bajo final
No presenta fallo ACIDOSIS METABÓLICA Y
renal RESPIRATORIA
Corregido el error, las conclusiones son ahora correctas
Pero… persiste todavía un error que no detectamos si
no seguimos el proceso de razonamiento, y si no se nos
presenta, durante la validación, el caso de un “fallo
renal”
58

59. PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS
SISTEMA EXPERTO Resultado
(Balance ácido-base)
Gasometrías Resultados intermedios ACIDOSIS METABÓLICA Y
pCO2 = 48 mmHg RESPIRATORIA
pH = 7.32 Estado_pCO2 = Alto
[HCO3]− 17 mg / l
= =
Razonamiento Estado_pH = Bajo Razonamiento
Contexto previo Estado_HCO3 = Bajo Valor esperado
final
No presenta fallo ACIDOSIS METABÓLICA Y
renal RESPIRATORIA
IF [HCO3]− 18 mg / l THEN Estado_HCO3 = BAJO
<
⇓
−
IF (([HCO3] < 18 mg / l) and (no Fallo Renal)) or
(([HCO3]− 16 mg / l) and (Fallo Renal))
<
THEN Estado_HCO3 = BAJO
59

60. CASUÍSTICA DE LA VALIDACIÓ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
60

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
61

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

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
63

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
64

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
65

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
66

67. OTRAS MEDIDAS
Coeficientes de exactitud
Distancias aritméticas
Curvas ROC…
1
0.05
0.9 0.1
0.8
0.3
0.7
0.6
TP 0.5 0.5
0.4
0.3 0.7
0.2
0.1
0.9
0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
FP
67

68. ERRORES COMETIDOS EN LA VALIDACIÓN
Errores de comisión
Errores por omisión
Sistema válido Sistema no válido
Sistema aceptado DECISIÓN ERROR TIPO II
como válido CORRECTA Riesgo para usuario
Sistema no aceptado ERROR TIPO I DECISIÓN
como válido Riesgo para ingeniero CORRECTA
68

69. Un ejemplo de validación
69

70. Un ejemplo de validación
70

71. Un ejemplo de validación
Porcentajes de acuerdo totales en
PATRICIA todas las categorías
Clínico vs.
Experto Colaborador 79%
Clínico vs.
Sistema Experto 78%
119 casos
Experto Colaborador Sistema Experto vs.
reales Experto Colaborador 92%
Médico que atendió el
caso (clínico)
71

72. Un ejemplo de validación
Porcentajes de acuerdo por
categoría diagnóstica
PATRICIA
Oxigenación 92%
Balance Ácido-Base 74%
Hemodinámica 87%
147 casos
Terapia Ventilatoria 71%
reales
Equipo Médico
72

73. Un ejemplo de validación
Sistema
Dominio UCI:
Casos de
prueba Experto – No es fácil establecer
1 referencias estándar
Características
de los casos – Nunca podríamos asegurar
que las interpretaciones y
2
prescripciones de un
experto sigan siempre los
Interpretaciones
de los casos mismos principios
Referencia
estándar – El estrés y el entorno
contribuyen a desvirtuar
comportamientos
3 – Pueden aparecer
soluciones equivalentes
aunque no idénticas
Validación
Resultados de la
validación
73

74. Un ejemplo de validación
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.
74

75. Un ejemplo de validación
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.
75

76. Un ejemplo de validación
Etapas:
– Labores de interpretación
OXIGENACION
BALANCE ACIDO-BASE
RESPIRACION ENDOGENA
PRESION ARTERIAL
FRECUENCIA CARDIACA
– Labores de sugerencias terapéuticas
MANEJO OXIGENATORIO
MANEJO VENTILATORIO
76

77. Un ejemplo de validación
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
77

78. Un ejemplo de validación
Balance Ácido-Base
Porcentajes de acuerdo total vs pares de com paración
Porcentaje de acuerdo
100
80
60
40
20
0
a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g
Pares de com paración
Porcentajes de acuerdo "dentro de uno" vs pares de com paración
% "dentro de uno"
100
80
60
40
20
0
a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g
Pares de com paración
78

79. Un ejemplo de validación
Balance Ácido-Base
Valores de kappa vs. pares de comparación
1.00
0.80
Kappa
0.60
0.40
0.20
0.00
a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g
Pares de com paración
Valores de kappa ponderada vs. pares de comparación
Kappa ponderada
1.00
0.80
0.60
0.40
0.20
0.00
a/b a/c a/d a/e a/f a/g b/c b/d b/e b/f b/g c/d c/e c/f c/g d/e d/f d/g e/f e/g f/g
Pares de com paración
79

80. Un ejemplo de validación
Balance Ácido-Base
Kappa Kappa ponderada
2.00 2.00
Medidas de Williams
Medidas de Williams
1.80 1.80
1.60 1.60
1.40 1.40
1.20 1.20
1.00 1.00
0.80 0.80
0.60 0.60
0.40 0.40
0.20 0.20
0.00 0.00
A B C D E F G A B C D E F G
Expertos Expertos
Porcentajes de acuerdo Porcentajes "dentro de uno"
2.00 2.00
Medidas de Williams
Medidas de Williams
1.80 1.80
1.60 1.60
1.40 1.40
1.20 1.20
1.00 1.00
0.80 0.80
0.60 0.60
0.40 0.40
0.20 0.20
0.00 0.00
A B C D E F G A B C D E F G
Expertos Expertos
80

81. USABILIDAD DE 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
81

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
82

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
83

84. EJEMPLOS DE CUESTIONARIOS CERRADOS
SI NO NS/NC
Escala simple ¿Puede realizarse ...?
Escala multipunto ¿Está de acuerdo con ...? Completamente Completamente
en desacuerdo de acuerdo
Escala de Lickert ¿Está de acuerdo con ...?
Completamente Ligeramente en Ligeramente de Completamente
en desacuerdo En desacuerdo desacuerdo Neutral acuerdo De acuerdo de acuerdo
Escala diferencial semántica Clasifica el módulo ... de acuerdo a los siguientes parámetros
Extremada- Extremada-
mente Bastante Ligeramente Neutral Ligeramente Bastante mente
Fácil Difícil
Claro Confuso
Escala de orden Ordena los siguientes comandos según su utilidad
PEGAR DUPLICAR AGRUPAR BORRAR
84

85. MÉTODOS EMPÍ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
85

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
86

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
87