Introducción.
Este capítulo es una revisión de las ideas principales acerca del diseño y desarrollo de sistemas expertos. Existen 6 fases principales:
1) Determinación del problema.
2) Adquisición de conocimiento.
3) Diseño del sistema.
4) Pruebas y evaluación.
5) Documentación.
6) Mantenimiento.
.
Fases en el desarrollo de sistemas expertos.
FASE 4 : PRUEBAS
A medida que se desarrolla el sistema se necesita realizar pruebas para constatar que el rendimiento del SE es adecuado. El proceso de evaluación del SE. Esta relacionado con la validación del sistema y la aceptación del usuario.
VALIDACION DEL SISTEMA
Si el SE. Está diseñado correctamente el sistema deriva los mismos resultados que un experto y razona de manera similar que el experto. La validación tiene dos campos : validar los resultados del sistema y validar el proceso de razonamiento del SE.
VALIDACION DE RESULTADOS
Para validar resultados se usa generalmente problemas pasados que fueron resueltos exitosamente, y se cuenta con información específica del problema, y los resultados correspondientes. Durante las pruebas se administra la información del problema al SE y las recomendaciones del sistema se comparan con los resultados reales del problema. Se deben considerar tres criterios para la evaluación de un SE. La selección del criterio de pruebas, selección de los casos de pruebas, selección de los evaluadores.
Selección del criterio de pruebas: Si el sistema se a diseñado para resolver un problema espec&´fico, entonces el criterio de pruebas es realizar un test completo, el sistema debe demostrar que realiza alguna tarea de valor, tal como reducción de costos, mejoramiento de la productividad, mejoramiento en la calidad del producto, etc.
Un criterio de pruebas distinto es comparar al sistema con lo que hace un experto humano. Esta fue la técnica usada para evaluar el MYCIN, que fue desarrollado para diagnosticar enfermedades infecciosas de la sangre y proporcionar una recomendación terapéutica aceptable.
Selección de los casos de pruebas: La selección de éste material es dependiente de las especificaciones iniciales del proyecto. Por ejemplo muchos sistemas son diseñados para asistir al usuario en problemas rutinarios. En estas aplicaciones el material de pruebas deberían ser pruebas pasadas que son problemas típicos del dominio.
En otras aplicaciones la organización necesita que el sistema resuelva cada posible problema, y no solo aquellos rutinarios o comunes. En este caso se necesita probar con problemas rutinarios y con aquellos que no lo son.
Selección de los evaluadores: Seleccionar quien evalúe el SE. Es también dependiente de las especificaciones del proyecto. Para un sistema diseñado para ayudar a un experto, será suficiente que el sistema sea evaluado por este experto, ya que si el esta satisfecho con los resultados el sistema tendrá éxito.
Si el sistema será usado por otros expertos, entonces el proceso de selección se torna mas difícil, la mejor solución es seguir el ejemplo de MYCIN, donde el equipo para evaluar el sistema estaba compuesto por muchas personas ajenas al proyecto, entre ellas expertos del área.
EVITAR PARCIALIDAD
Un aspecto de la evaluación es que se debe considerar la posible presencia de parcialidad. Los evaluadores de forma consciente o no, pueden ser parciales contra un programa de computación que ha sido diseñado para modelar el razonamiento humano.
El equipo de desarrollo del MYCIN consciente de este problema, ya que lo experimento en las primeras fases de evaluación, no notifico a los evaluadores de pruebas posteriores que los resultados de las pruebas que iban a revisar eran producidas por un programa de computación, de esta manera se evita la parcialidad.
VALIDAR EL RAZONAMIENTO
Los evaluadores necesitan saber si el sistema está obteniendo respuestas correctas usando razonamiento correcto. La principal razón para esto es el número limitado de casos de prueba que pueden ser actualmente usados durante los estudios de evaluación. Se tienen dos formas de validar el razonamiento del sistema, uno el macronivel , donde los evaluadores pueden estudiar el resultado de los hechos que dieron como resultado la recomendación final. Y el otro el micronivel donde el evaluador rastrea y revisa todas las reglas usadas en la obtención de una recomendación.
MINIMIZAR EQUIVOCACIONES
Cuando el sistema tiene una equivocación, se debe permitir al experto revisar los resultados y preguntarle acerca de porque la respuesta dada fue incorrecta, y porque la respuesta correcta no se encontró . Se puede usar esta información para mejorar el SE de dos formas: 1) corregir el conocimiento que llevo a la equivocación y 2) aumentar el conocimiento necesario para llegar a una respuesta correcta.
ACEPTACION DEL USUARIO
Una gran parte de la evaluación de un SE debe dedicarse a las necesidades del usuario, algunos de los aspectos mas importantes que se debe evaluar son: Facilidad de uso, Claridad de preguntas, claridad de explicaciones, presentación de resultados, utilidades del sistema.
Si la interfaz está diseñada adecuadamente el usuario se sentirá cómodo y podrá encontrar ayuda fácilmente. Se debe tomar en cuenta también la velocidad de respuesta, ya que el usuario se sentirá incómodo con mucho retardo en el sistema.
El rendimiento de un sistema depende fuertemente de la información que recibe del usuario. Si esta información es incorrecta, los resultados del sistema serán erróneos. Por ello es importante que las preguntas estén bien diseñadas.
EVOLUCION DE LAS PRUEBAS:
PASO 1: PRUEBAS PRELIMINARES:
Inmediatamente después del desarrollo del prototipo, debe ser realizada una prueba informal del sistema para evaluar la completitud de la base de conocimiento. Este test debería aplicar todas las posibles combinaciones de respuestas posibles a las preguntas del sistema. La solución derivada por el sistema debería entonces ser verificada para cada conjunto de respuestas.
PASO 2: PRUEBAS DE DEMOSTRACION:
Siguiendo al desarrollo del prototipo, una demostración del sistema debería ser hecha con personas de la organización. Esta demostración ilustra lo que puede ser realizado con el sistema. Un importante beneficio de una demostración exitosa es que puede revitalizar el interés en el proyecto.
PASO 3: PRUEBAS PARA
Durante el desarrollo del proyecto se podrá testear el sistema con problemas reales del dominio. Aquí el objetivo es determinar con que efectividad el sistema resuelve los problemas y cubrir las deficiencias del sistema. En este test se puede detectar la falta de conocimiento o conocimiento inadecuado, y se pasa a remediar esta situación.
Con la ayuda del experto este test puede también descubrir problemas con el razonamiento del sistema, los cuales deben ser solucionados.
PASO 4: PRUEBAS DE REFINAMIENTO
Luego que el sistema a probado ser capaz de manejar casos típicos, se debería hacer pruebas con casos mas difíciles, aún si el propósito original del SE. es manejar solo situaciones típicas, este test impulsa al sistema a considerar problemas mas complejos. El resultado es generalmente un refinamiento en el conocimiento del sistema y en el control.
PASO 5: PRUEBAS FORMALES
Aquí el objetivo es determinar que nivel de rendimento a alcanzado el sistema en cuanto a las metas iniciales del proyecto.
PASO 6: PRUEBAS EN EL CAMPO
Todas las anteriores pruebas fueron realizadas en el laboratorio. En las pruebas de laboratorio es posible tener un alto grado de control sobre el proceso de evaluación.
Durante las pruebas de campo el sistema esta en el ambiente de trabajo al que pertenece y expuesto a tipos de problemas para los cuales fue originalmente diseñado. El principal objetivo de éste test es determinar si el sistema cumple con sus metas originales, y si no determinar que cosas adicionales se necesitan. Esto involucra la validación futura del sistema, y lograr la aceptación del usuario.
FASE 5: DOCUMENTACION.
A medida que el sistema avanza, se acumula gran cantidad de información proveniente de la recolección de conocimiento. Se debe buscar la manera mas adecuada de documentar toda esta información.
Esta documentación sirve al personal del proyecto. Debería contener todo el material recolectado durante el proyecto.
QUE NECESITA SER DOCUMENTADO:
Durante el proyecto, la información que se necesita registrar en la documentación sirve para tres principales propósitos:
- Referencia para el desarrollo del SE.
- Referencia para escribir el reporte final.
- Referencia para mantener el SE.
Se debe documentar lo siguiente:
- Conocimiento, incluye reglas, frames y estrategias.
- Diagramas, ilustraciones de las relaciones entre las distintas piezas de conocimiento
- Código fuente
- Pruebas
- Transcripciones, versión escrita de registros hechos durante sesiones de adquisición de conocimiento.
- Glosario de términos
- Reportes y referencias técnicas.
COMO ORGANIZAR
La documentación debería cumplir las siguientes especificaciones:
- Fácil acceso a nuevo conocimiento
- Fácil acceso y modificación a conocimiento pasado
- Fácil acceso a información relacionada
- Fácil acceso a reportes.
Una sección en el cuerpo de la documentación que es único a los SE. es el diccionario de conocimiento, esta sección contiene información de las piezas de conocimiento recolectado durante el proyecto, tales como reglas, objetos y estrategias.
HIPERTEXTO
Un problema básico dentro la documentación es la dificultad de identificar relaciones entre piezas de información almacenada en lugares separados. Esto ocurre en libros, ya que presentan una representación lineal de la información. Para facilitar la búsqueda de información relacionada, esta se almacena en medios electrónicos. Varios diseñadores adoptan la técnica de hipertexto, la idea básica es crear lazos asociativos entre la información relacionada.
GUIA PARA DISEÑAR
El contenido de la documentación del proyecto, debería incluir lo siguiente:
- Tabla de contenidos
- Propuesta del proyecto
- Diccionario de conocimiento
- Código fuente
- Pruebas
- Transcripciones de las sesiones
- Información del personal del proyecto
- Glosario
- Referencias
- Indice.
REPORTE FINAL
Existen variaciones acerca del contenido de este reporte, esto depende de la organización para la que fue diseñado el SE., básicamente el reporte final debería contener lo siguiente:
- Titulo
- Tabla de contenidos
- Introducción del proyecto
- Descripción del programa
- Resultados de las pruebas
- Sumario
- Referencias
- Bibliografía
- Apéndices.
FASE 6 MANTENIMIENTO.-
La última fase del proyecto es el mantenimiento. La organización, institución o persona que use el sistema puede adquirir nuevos productos y equipamiento, o cambiar procedimientos de trabajo con los recursos existentes. Estos cambios requieren modificaciones apropiadas en el sistema.
Cuando se usa un SE se pueden encontrar deficiencias en el rendimiento, o simplemente es muy difícil para el usuario el manejo del sistema. En estos casos también se requerirá mantenimiento del sistema.
El mantenimiento de cualquier tipo de software puede resultar muy costoso. Un estudio realizado por
El ingrediente más importante para el mantenimiento de un programa es la documentación. Si la documentación es completa y organizada facilitara la tarea del mantenimiento.
Estructura modular
Para ayudar el mantenimiento, el conocimiento del sistema debería estar organizado de forma que permita fácil acceso a partes de interés y permita fácil modificación.
Conocimiento separado de la información
Es muy importante separar el conocimiento de la información y una forma de separarlos es colocando la información en una base de datos y el conocimiento usando reglas variables. De esta manera si se necesita cambios solo en la información, se puede hacer los cambios directamente en la base de datos. Y si la forma de tomar decisiones necesita ser cambiada, las reglas apropiadas deben ser modificadas.
Meta-Reglas
Otro aspecto del diseño que impacta en el mantenimiento del sistema es el uso de meta-reglas. Las meta-reglas aumentan la flexibilidad en el control del razonamiento del sistema. Al realizar el mantenimiento, si las meta reglas están mezcladas con las demás reglas, se dificulta el proceso, ya que es de gran importancia revisar primero estas reglas que las demás. Se deben seguir buenas practicas de documentación para resolver este problema, de tal manera que se tenga rápido acceso a las meta reglas.
Por ejemplo, usted podría construir una meta-regla que establezca una nueva meta en base al contexto de las sesiones.
Sin embargo, una meta-regla se entierra dentro de muchas otras reglas y el ingeniero de conocimiento que ni siquiera no puede ser consciente que existe.
Sería injusto recomendar excluir meta-regla del sistema debido a este problema de mantenimiento de potencial. Pero hay un par de puntos para considerar eso puede ayudar.
Primero, usted necesita hacer que el personal de mantenimiento sea consciente que los meta-regla existen y donde ellos se localizan.
Segundo, usted necesita hacer la meta-regla fácilmente accesible. Esto puede ser logrado agrupándoselos en un regla-juego separado.
Problemas del software
La opción de software desarrollaba que el sistema especialista también tendrá un impacto en la tarea de mantenimiento. La preocupación aquí es el talento de la programación necesitado, portabilidad del sistema, utilidades de la modificación, y nuevas versiones. Echemos una mirada a cada uno de éstos cuando ellos afectan el esfuerzo de mantenimiento.
-Habilidades programando. La opción de software de desarrollo puede ir de los lenguajes bajos a las herramientas híbridas grandes. Individuos cobrados con mantener el sistema necesitarían tener como requisito previo habilidades en la programación en el software escogido. En general, exige mucho más entrenamiento aprender un lenguaje bajo que una herramienta de desarrollo de sistema especialista. Sin embargo, en cualquier caso, usted necesitará tener el personal de mantenimiento entrenado en el proyecto del software para llevar a cabo el programa de mantenimiento.
Portabilidad del sistema
La portabilidad permite mover el sistema a otras computadoras existentes en la organización. En general los sistemas desarrollados con un lenguaje son más fáciles de portar, mientras que los desarrollados con un shell pueden ser limitados a cierto tipo de computadoras o sistemas operativos. Si se cree que la portabilidad será un aspecto importante en el futuro del SE, se debe tener cuidado al escoger un software de desarrollo.
Utilidades para la modificación
Modificar el conocimiento en un SE no es tan simple como cambiar reglas individuales, ya que estas reglas pueden estar relacionadas con muchas otras. En este punto una herramienta importante es el verificador de consistencia de reglas incluidos en algunos shells. Esta utilidad verifica que cada nueva regla presente consistencia con las reglas existentes y no tenga contradicciones con ninguna otra.
Quién mantiene sistema?
Decidiendo quién es mantener el sistema es una decisión importante al reunir un programa de mantenimiento de sistema especialista. Los individuos deben tener las capacidades para realizar la tarea y despacho de aduanas por la organización.
El diseñador del sistema es la primera opción obvia. Este individuo tiene ambos conocimiento que diseña habilidades para realizar la tarea y experimentar con el sistema. Sin embargo, este individuo puede ser más valioso en otros nuevos proyectos.
La organización puede elegir para escoger otros que tienen menos o ninguna experiencia con el sistema o desarrollo de sistema de experto. Si este acercamiento se toma, entonces la organización asume la responsabilidad de entrenamiento los individuos. Este acercamiento fue tomado por DIC que sigue el desarrollo de XCON.
El DIC estableció un grupo de las personas para mantener XCON. Puesto que XCON que usó OPS, estos individuos necesitaron entrenar en el lenguaje primero.
Este proceso asumió como promedio aproximadamente tres meses en completar. Un producto de este acercamiento era que en el futuro al especializarlos se agrupan de individuos hábiles en el plan del sistema especialista se estableció dentro de DIC que pudo extender la capacidad de XCON para considerar la configuración de otros tipos de sistemas de la computadora.
Para los propósitos de seguridad, es importante que sólo se designe a los individuos permitidos para mantener el sistema. La razón para esta recomendación se dio cuando usted considera el daño del posible que puede hacerse si un individuos desautorizado se dan acceso al sistema. Cada pedazo de conocimiento en el sistema tiene un posible impacto en el resultado final del sistema. Un menudo puede llevar a un resultado totalmente diferente. Considere el cambio simple siguiente por ejemplo a una regla en un Sistema de la inversión financiero:
OLD RULE NEW RULE
IF Desired return>15% IF Desired return>10%
AND Market is bull AND Market is bull
THEN Advise high-risk stocks THEN Advise high-risk stocks
En este ejemplo, un cambio se hizo al porcentaje de retorno deseado como una condición por recomendar acciones de riesgo altas. Este cambio puede haber sido hecho por una persona desautorizado con intenciones buenas. Sin embargo, cuando el cliente pierde la inocencia del error que usted estará mirando fijamente un traje de la ley probablemente (tuchill 1991)
Documentación de los cambios.-
Es muy importante mantener buenos registros acerca de cualquier cambio hecho al sistema. A continuación se muestra un modelo de un documento de cambios.
FORMA DE MANTENIMIENTO
|
Titulo del proyecto: _______________________ Organización responsable: ___________________ Modificado por: __________________________ Fecha de modificación: ____________ |
|
Que fue modificado |
|
Por que fue modificado |
|
Observaciones |
Cada vez que se realizan cambios en el sistema se debe documentar adecuadamente.
SUMARIO:
- Existen seis principales fases en el desarrollo de un SE. Determinación del problema, Adquisición del conocimiento, Diseño del sistema, Pruebas y evaluación, Documentación y mantenimiento.
- La motivación de la organización para el desarrollo de un SE es importante para definir el proyecto.
- Aspectos importantes con problemas, personal y despliegue son importantes para medir la factibilidad del proyecto.
- Las pruebas en un SE involucran la validación de los resultados del sistema y su proceso de razonamiento.
- Las pruebas del sistema se realizan a lo largo del proyecto, tornándose más formales a medida que el proyecto avanza.
- La documentación del proyecto es importante para el desarrollo y el mantenimiento del SE.
- El diccionario del conocimiento contiene piezas importantes de conocimiento recolectado durante el proyecto tales como reglas, objetos, etc.
- El sistema debería ser diseñado pensando en facilitar las tareas de mantenimiento.
- Todos los cambios hechos al sistema durante el mantenimiento deben ser claramente documentados.
REFERENCES.
-Adrian W.R. M.A Branstad, and J.C Chemiavsky, Validation, Verification and testing of computer Software, ACM Computing Surveys. Vol 14, No 2, pp 159-192 june 1982.
-Sistemas expertos de Durkin.
-Turing. A.M. Computing Machinery and Mind, vol. 59, 1950
´nbsp;nbsp;
Categoría:
- Inicie sesión para comentar