VALIDACIÓN Y USABILIDAD DE SISTEMAS INFORMÁTICOS         (1ª Parte)             Curso de Doctorado    Distinguido con la M...
VALIDACIÓN Y USABILIDAD DE SISTEMAS              INFORMÁTICOSFORMATO DEL CURSO– Primera parte    Aspectos generales de la ...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                       INFORMÁTICOSAlgunas diferencias entre sistemas inteligentes ysis...
VALIDACIÓN Y USABILIDAD DE SISTEMAS               INFORMÁTICOSLas características diferenciales, estructurales yfuncionale...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                INFORMÁTICOSAlgunas técnicas útiles para la adquisición de conocimiento...
VALIDACIÓN Y USABILIDAD DE SISTEMAS               INFORMÁTICOSAprendizaje automático– Técnica automática de adquisición qu...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                INFORMÁTICOSLa subjetividad afecta de manera importante a la validación...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                INFORMÁTICOSEl problema del paradigma de representación del conocimient...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                 INFORMÁTICOSEL PROBLEMA DEL DESPLAZAMIENTO DEL PARADIGMA              ...
VALIDACIÓN Y USABILIDAD DE SISTEMAS               INFORMÁTICOSEL PROBLEMA DEL DESPLAZAMIENTO DELPARADIGMA– Surge cuando en...
VALIDACIÓN Y USABILIDAD DE SISTEMAS               INFORMÁTICOSElección del modelo de razonamiento– Los modelos de razonami...
VALIDACIÓN Y USABILIDAD DE SISTEMAS                INFORMÁTICOSLa inexactitud del conocimiento, implementado oinferido, pu...
VALIDACIÓN Y USABILIDAD DE SISTEMAS              INFORMÁTICOSEn los procesos de validación tendremosque considerar:– Aspec...
METODOLOGÍAS DE DESARROLLOPrincipios generales de desarrollo– Desarrollo del sistema mediante un ciclo de vida dividido en...
METODOLOGÍAS DE DESARROLLO– Algunos ejemplos de metodologías:    Adquiere y codifica    Método de Buchanan    Diseño incre...
ADQUIERE Y CODIFICASimilar al procedimiento de “codifica y corrige”No sigue un esquema precisoEl sistema se desarrolla en ...
METODOLOGÍA DE DESARROLLO DE BUCHANAN  Identificación                Requisitos                   Conceptualización       ...
METODOLOGÍA DE DESARROLLO DE BUCHANANIdentificación – Se reconocen aspectos importantes del problema:       Participantes ...
METODOLOGÍA DE DESARROLLO DE BUCHANANConceptualización– Organización del conocimiento según un  esquema conceptual– Búsque...
METODOLOGÍA DE DESARROLLO DE BUCHANANFormalización– Proceso de traducción de…    Conceptos clave    Subproblemas    Caract...
METODOLOGÍA DE DESARROLLO DE BUCHANANElicitación– Extracción del conocimiento    Soporte físico    Proceso consistente con...
METODOLOGÍA DE DESARROLLO DE BUCHANANImplementación– Formulación de reglas– Formulación de estructuras de control– Obtenci...
METODOLOGÍA DE DESARROLLO DE BUCHANANPrueba– Evaluación del rendimiento del prototipo  construido– Identificación de error...
METODOLOGÍA DE DESARROLLO DE BUCHANANLos lazos de realimentación no tienen por qué seguir estrictamentela secuencia del es...
METODOLOGÍA DE DESARROLLO          INCREMENTALDesarrollo iterativo de sistemasProceso cíclico de desarrolloEn cada ciclo s...
METODOLOGÍA DE DESARROLLO DE                    GONZÁLEZ-DANKELAnálisis                                     Ajuste del dis...
METODOLOGÍA DE DESARROLLO DE          GONZÁLEZ-DANKELModelo de desarrollo que incorpora prototipado rápido y desarrolloinc...
METODOLOGÍA DE DESARROLLO DE             SCOTTSe divide en 4 fases:– Fase de análisis    Se investiga la viabilidad del pr...
METODOLOGÍA DE DESARROLLO DE                  SCOTTANÁLISIS                                        Identificación de la po...
METODOLOGÍA DE DESARROLLO DE           SCOTTPrototipado rápido y desarrollo incrementalLos prototipos construidos son una ...
METODOLOGÍA DE DESARROLLO DE SCOTTLas características de esta metodología son muy parecidas a las dela metodología de Gonz...
METODOLOGÍA DE DESARROLLO DE SCOTTDos fases típicas en el proceso de adquisicióndel conocimiento:– Adquisición inicial    ...
METODOLOGÍA DE DESARROLLO EN ESPIRAL                                                                         Análisis de  ...
METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Análisis de requisitos    ¿Es de utilidad el sistema?   ...
METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Adquisición del conocimiento    El conocimiento extraído...
METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Prototipado     El desarrollo incremental a través de un...
METODOLOGÍA DE DESARROLLO EN ESPIRALProceso dividido en 4 fases:– Implementación y mantenimiento     Una vez desarrollado ...
TIPOS DE PROTOTIPOSPrototipo de demostraciónPrototipo de investigaciónPrototipo de campoModelo de producciónSistema comerc...
VALIDACIÓN Y USABILIDAD DE SISTEMAS           INFORMÁTICOS               Evaluación               Validación              ...
VALIDACIÓN Y USABILIDAD DE SISTEMAS              INFORMÁTICOSVerificación:– Comprobación de que estamos construyendo  el s...
VALIDACIÓN Y USABILIDAD DE SISTEMAS              INFORMÁTICOSValidación:– Comprobación de que estamos construyendo  el sis...
VALIDACIÓN Y USABILIDAD DE SISTEMAS              INFORMÁTICOSEvaluación:– Análisis de aspectos que van más allá de la  cor...
VERIFICACIÓN DE SISTEMASVerificación del cumplimiento de lasespecificacionesVerificación de los mecanismos deinferenciaVer...
VERIFICACIÓN DEL CUMPLIMIENTO DE LAS              ESPECIFICACIONESPersonal potencialmente involucrado:–   Desarrolladores–...
VERIFICACIÓN DE LOS MECANISMOS DE INFERENCIA Pierde importancia con la utilización de entornos de desarrollo comerciales E...
VERIFICACIÓN DE LA BASE DE CONOCIMIENTOSEs responsabilidad del ingeniero del sistemaGeneralmente se basa en el concepto de...
VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE               CONOCIMIENTOS Reglas redundantes  – Redundancias sintácticas  ...
VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE               CONOCIMIENTOS Reglas conflictivas  – Premisas idénticas pero c...
VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE               CONOCIMIENTOS Reglas englobadas en otras      P (x) y Q (x) → ...
VERIFICACIÓN DE LA CONSISTENCIA DE LA BASE DE               CONOCIMIENTOS Reglas circulares      P (x) → Q (x)      Q (x) ...
VERIFICACIÓN DE LA COMPLETITUD DE LA BASE DE               CONOCIMIENTOS Valores no referenciados de atributos  – Parte de...
INFLUENCIA DE LAS MEDIDAS DE INCERTIDUMBRERedundancia – En sistemas sin incertidumbre la redundancia no tiene por qué afec...
ASPECTOS GENERALES DE LA VALIDACIÓN DE               SISTEMASValidar– Comprobar que estamos construyendo el producto  corr...
ASPECTOS GENERALES DE LA VALIDACIÓN DE               SISTEMASLa validación orientada a los resultados esprevia a la valida...
PERSONAL INVOLUCRADO EN LA VALIDACIÓN  Ingeniero del                                         Evaluadores  conocimiento    ...
PARTES DEL SISTEMA QUE DEBEN SER VALIDADASResultados finales – Performance general del sistemaResultados intermedios – Des...
PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS                                         SISTEMA EXPERTO          Resultado     ...
PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS                            IF pCO2 > 50 mmHg THEN Estado_pCO2 = ALTO           ...
PARTES DEL SISTEMA QUE DEBEN SER VALIDADAS                                    SISTEMA EXPERTO                             ...
CASUÍSTICA DE LA VALIDACIÓNDos tipos de datos– Los que incluyan las características de cada caso particular– Un criterio q...
VALIDACIÓN CONTRA EL EXPERTOSe utilizan las opiniones y las interpretacionesde los expertos humanos como criterio devalida...
VALIDACIÓN CONTRA EL EXPERTOHay tres procedimientos diferentes:– Validación contra un único experto      Ventajas        –...
VALIDACIÓN CONTRA EL PROBLEMANuestro sistema: ¿acierta realmente, o resuelveconvenientemente, el problema planteado?Ventaj...
MOMENTO EN QUE SE REALIZA LA             VALIDACIÓNBachant y McDermott– Validar un sistema que no está terminado puede no ...
MÉTODOS DE VALIDACIÓNMétodos cualitativos– Emplean técnicas subjetivas de comparación de rendimientos     Validación super...
MÉTODOS DE VALIDACIÓNMedidas de pares –   Medidas de acuerdo          Índice de acuerdo          Índice de acuerdo en uno ...
OTRAS MEDIDASCoeficientes de exactitudDistancias aritméticasCurvas ROC…                      1                            ...
ERRORES COMETIDOS EN LA VALIDACIÓN  Errores de comisión  Errores por omisión                         Sistema válido       ...
Un ejemplo de validación                           69
Un ejemplo de validación                           70
Un ejemplo de validación                                        Porcentajes de acuerdo totales en                   PATRIC...
Un ejemplo de validación                                  Porcentajes de acuerdo por                                    ca...
Un ejemplo de validación                                                             Sistema                              ...
Un ejemplo de validaciónCriterios con carácter general:– Si el dominio de aplicación es un dominio crítico, en el que no e...
Un ejemplo de validaciónEsquema de la validación formal dePATRICIA– Contexto retrospectivo– Con medidas de pares y técnica...
Un ejemplo de validaciónEtapas:– Labores de interpretación    OXIGENACION    BALANCE ACIDO-BASE    RESPIRACION ENDOGENA   ...
Un ejemplo de validaciónMedidas realizadas:– Indices de concordancia entre expertos  (incluido el sistema)– Indices de con...
Un ejemplo de validación                                                       Balance Ácido-Base                         ...
Un ejemplo de validación                                                 Balance Ácido-Base                               ...
Un ejemplo de validación                                             Balance Ácido-Base                                   ...
USABILIDAD DE SISTEMASMétodos heurísticos– Técnicas heurísticas, desarrolladas por expertos, que analizan  los interfaces ...
MÉTODOS HEURÍSTICOSAnálisis del sistema y detección de problemas deamigabilidad y calidad– Cuestionarios ergonómicos– Insp...
MÉTODOS SUBJETIVOSConocimiento de la opinión de los usuarios sobre la propiausabilidad del sistema – Pensar en alto – Obse...
EJEMPLOS DE CUESTIONARIOS CERRADOS                                                     SI         NO      NS/NC Escala sim...
MÉTODOS EMPÍRICOSSe trata de sacar conclusiones basadas en datosobjetivos obtenidos sobre cómo los usuarios utilizan elsis...
MEDIDAS OBJETIVAS DE USABILIDADNúmero de tareas diversas que pueden realizarse en undeterminado periodo de tiempoProporció...
RESUMENVerificación, validación y análisis de usabilidad sonfundamentales para desarrollar software de calidadEstas fases ...
Upcoming SlideShare
Loading in...5
×

3 tecnicas modernas programacion

1,004

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,004
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

3 tecnicas modernas programacion

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

    Clipping is a handy way to collect important slides you want to go back to later.

×