Capitulo 6

Diseo de sistemas Expertos

6.1 Introduccin
En los captulos anteriores, hemos hablado de los conceptos generales y la teora de los sistemas
expertos. Este captulo presenta las pautas generales para la construccin de sistemas expertos
prcticos diseados para aplicaciones del mundo real, no prototipos de investigacin. Una
metodologa de ingeniera de software se describe de modo que un sistema experto puede ser un
producto de calidad desarrollado de una manera costo-efectiva y oportuna.

6.2 Seleccin del problema apropiado

Antes de poder construir un sistema experto se debe seleccionar un problema de forma apropiada,
como se discuti en la Seccin 1.6. Como con cualquier proyecto de software hay una serie de
consideraciones generales que deben realizarse antes de un gran compromiso con la gente, los
recursos y el tiempo estn comprometidos con un sistema experto propuesto. Estas consideraciones
generales son tpicas de las preocupaciones de la gestin de proyectos en los programas
convencionales, pero deben ser personalizadas para los requerimientos especiales de los sistemas
expertos. Un punto de vista general de gestin de desarrollo de sistemas expertos se muestra en la
Figura 6.1. Las tres etapas generales tienen consideraciones ms especficas, que se muestra
debajo de ellos. Estas consideraciones ms especficas sern discutidas en forma de preguntas y
respuestas que sirvan de gua para los proyectos de sistemas expertos.

Seleccin del paradigma apropiado.

Por qu estamos construyendo un sistema experto?
Esta es probablemente la pregunta ms importante a preguntarse en cualquier proyecto. Mientras
que el Captulo 1, Seccin 2 se describen las ventajas generales de los sistemas expertos, slo se
autoriza a la gestin el sistema y personal tcnico necesarios para aplicar en la necesidad. En
particular, la respuesta a esta pregunta con el tiempo se debe dar a los propietarios o accionistas de
la financiacin del desarrollo. Antes de comenzar, debe haber una clara identificacin del problema,
expertos y usuarios.

Rentabilidad
Cul es la recompensa?
Esta pregunta est relacionada con la primera pregunta. Sin embargo, sta es ms pragmtica en
que est pidiendo el retorno especfico de la inversin de las personas, recursos, tiempo y dinero. El
pago puede ser en dinero, aumentar la eficiencia, o de cualquiera de las otras ventajas de los
sistemas expertos descrito en el captulo 1. Tambin es importante recordar que si no se usa el
sistema, no habr recompensa. Debido a que los sistemas expertos es una nueva tecnologa, es
ms difcil y riesgoso responder a esta pregunta en relacin a la programacin convencional.
Figura 6.1 Tareas de Gestin de Proyectos

Herramientas
Qu herramientas se encuentran disponibles para construir el sistema?
Hay muchas herramientas de sistemas expertos disponibles en la actualidad con ventajas y
desventajas. El Apndice D resume las caractersticas de algunas herramientas. Sin embargo, esto
slo debe ser tomado como una gua, ya que las herramientas de software se desarrollan tan
rpidamente. Por lo general, usted puede contar con una mejora importante cada ao en cada
herramienta y una revisin en profundidad cada dos o tres aos.
Estas mejoras no se limitan a las herramientas de software. Muchas de los estados de herramientas
avanzadas se ejecut con $ 50.000 en mquinas LISP a mediados la dcada de 1980 fueron
reescritas ms tarde para correr en microcomputadores o microprocesadores personalizados. Esto
reduce considerablemente el costo de hardware para ejecutar las herramientas. La mejor gua es
examinar las publicaciones actuales y hablar con personas que han construido sistemas expertos.

Costo
Cunto va a costar?
El costo de la construccin de un sistema experto depende de las personas, los recursos y el tiempo
destinado a su construccin. Adems del hardware y software necesario para ejecutar una
herramienta de sistema experto, tambin puede haber un costo considerable en la capacitacin. Si el
personal tiene poca o ninguna experiencia con una herramienta, puede ser costoso capacitarlos. Por
ejemplo, la capacitacin en estados de herramientas avanzadas de sistemas expertos puede costar
$ 2500/semana por persona.

6.3 ETAPAS EN EL DESARROLLO DE UN SISTEMA EXPERTO.

De qu manera el sistema se desarrollar?
En gran medida, el desarrollo de un sistema experto depende de los recursos aportados, sin
embargo, como cualquier otro proyecto, el desarrollo tambin depender de la forma en que el
proceso est organizado y dirigido.

Gestin de Proyectos
La gestin de proyectos se espera que proporcione el siguiente-hecho, la gestin de proyectos ha
sido objeto de un enfoque de sistema experto (Sathi 86):
Gestin de actividades
Planificacin Definir las actividades
Especificar la prioridad de las actividades
Requerimientos de los recursos
Hitos
Duracin
Responsabilidades
Programacin Asignacin de tiempos de inicio y finalizacin.
Resolver los conflictos en la programacin de tareas con la misma
prioridad.
Crnica Monitorear desempeo del proyecto.
Anlisis Analizar planes, programas y actividades de la
crnica.

Gestin de Configuraciones del Producto

Gestin de Productos Gestionar las diferentes versiones del
producto.
Gestin de Cambios Gestionar las propuestas de cambio y las
evaluaciones de impacto.
Asignar personal para realizar cambios
Instalar nuevas versiones del producto.

Gestin de Recursos
Previsin de las necesidades de recursos
Adquirir los recursos
Asignar responsabilidades para el uso ptimo de los recursos
Proporcionar los recursos crticos para minimizar los cuellos de botella

Para el desarrollo de un sistema experto, las actividades son las tareas necesarias para construir el
sistema. La Figura 6.2 muestra una vista general de las actividades necesarias para producir un
sistema en trminos de las etapas que atraviesa un sistema.
Figura 6.2 Etapas generales en el desarrollo de un sistema experto

El problema de la entrega.
Cmo se entregar el sistema?
Si bien es conveniente y puede reducir al mnimo el tiempo de desarrollo utilizar una estacin de
trabajo de punta, a menudo es demasiado costoso para entregar el sistema en estas estaciones de
trabajo.
Por ejemplo, una estacin de trabajo que tiene US $ 100.000 en hardware y software es bastante
cara para su uso en las oficinas una empresa. Adems, las tasas anuales de mantenimiento pueden
aumentar an ms el costo considerablemente.
Dependiendo del nmero de sistemas expertos para su implementacin, el problema de entrega de
los sistemas desarrollados puede ser un factor importante en el desarrollo. El problema de la entrega
debe ser considerado en las primeras etapas de desarrollo (Freedman 86).
Idealmente, los sistemas expertos entregados debern ser capaces de funcionar con hardware
estndar. Sin embargo, algunas herramientas de sistema experto requieren una placa especial para
un microprocesador LISP, lo que aumentar sustancialmente el costo.
En muchos casos, el sistema experto debe estar integrado con otros programas existentes. Se debe
considerar la comunicacin y la coordinacin de entrada/salida del sistema experto con estos
programas. Tambin puede ser necesario llamar a los sistemas expertos como un procedimiento de
un lenguaje de programacin convencional, y el sistema debe apoyar esto.
Mantenimiento y Evolucin.
De qu manera el sistema ser mantenido y evolucionar?
El mantenimiento y la evolucin de un sistema experto es ms de una actividad abierta que con los
programas convencionales. Debido a que los sistemas expertos no se basan en algoritmos, su
rendimiento depende del conocimiento. Como se adquieren nuevos conocimientos y el viejo
conocimiento es modificado, el rendimiento del sistema mejora.
En un producto de calidad comercial debe haber una manera sistemtica y eficaz de recopilar
informes de errores de los usuarios. Mientras que la recopilacin y reparacin de los informes de
error no es de alta prioridad en los sistemas de investigacin de calidad, es una alta prioridad en los
sistemas de calidad comercial. Un buen mantenimiento se puede hacer slo si los informes de
errores se adquieren.
La mejora de un sistema experto despus de la entrega es tambin ms de una preocupacin en un
sistema de calidad comercial. Los desarrolladores de un sistema comercial queremos que sea un
xito financiero. Esto significa escuchar lo que los usuarios quieren y estn dispuestos a pagar por
mejoras. En un sentido muy real, un sistema experto comercial nunca puede ser acabado, slo sigue
mejorando.

6.4 ERRORES EN LAS ETAPAS DE DESARROLLO

Los errores de mayor potencial del desarrollo de sistemas expertos se pueden clasificar por las
etapas ms probables en que se producen, como se ilustra en la Figura 6.3. Estos errores son los
siguientes:
Errores de expertos en el conocimiento. El experto es la fuente de conocimiento del
sistema experto. Si el conocimiento del experto es errneo, los resultados pueden ser
propagados a travs del proceso de desarrollo. Como se mencion en el captulo 1, un
beneficio secundario de la construccin de un sistema experto es la deteccin potencial de
conocimiento errneo cuando el conocimiento del experto, se hace explcito.
Para los proyectos de misin crtica en la que la vida humana y la propiedad estn en
riesgo, puede ser necesario establecer procedimientos formales para certificar los
conocimientos de un experto. Uno de los enfoques que la NASA ha utilizado con xito para los
vuelos espaciales son los paneles de tcnicas de vuelo, que revisan regularmente soluciones
a los problemas y las tcnicas de anlisis utilizadas para desarrollar las soluciones (Culbert
87). Los paneles consisten en usuarios del sistema, independientemente del dominio de los
expertos, desarrolladores de sistemas y administradores para asegurar la cobertura de todas
las reas que afectan el desarrollo.
La ventaja de un panel de enfoque es que el conocimiento del experto se encuentra
bajo estrecha vigilancia en el comienzo del proceso de desarrollo, cuando el conocimiento es
errneo es ms fcil de corregir. Cuanto ms tiempo el conocimiento errneo pasa
desapercibido, ms caro que es corregirlo. Si el conocimiento del experto no es inicialmente
verificado, la prueba definitiva es la validacin del sistema experto. La validacin final del
sistema experto demuestra que el sistema satisface los requisitos, especialmente la exactitud
e integridad de las soluciones.
La desventaja de un panel de enfoque es sobre todo el costo involucrado. Sin embargo,
este costo puede ser compensado por una mayor eficiencia del proceso de desarrollo.
 Errores semnticos. Un error de semntica se produce cuando el significado del
conocimiento no est bien comunicado. Como un ejemplo muy sencillo, supongamos que un
experto dice que "usted puede apagar un fuego con el agua" y el ingeniero del conocimiento
interpreta esto como "Todos los fuegos puede ser extinguido por el agua." Los errores
semnticos ocurren si el ingeniero del conocimiento malinterpreta las respuestas de los
expertos, o el experto interpreta mal la pregunta del ingeniero del conocimiento, o ambos.
Los errores de sintaxis. Estos son simples errores que ocurren cuando se introduce de
forma incorrecta una regla o un hecho. Las herramientas de sistemas expertos deben marcar
estos errores y emitir el mensaje apropiado. Otros errores que se producen en la fase de
construccin de la base de conocimiento se deben a errores de la fuente del conocimiento que
no se han detectado en las etapas anteriores.

Figura 6.3 Errores importantes en los sistemas de expertos alguna de las causas

Errores del motor de inferencia. Al igual que con cualquier otra pieza de software, el
motor de inferencia puede tener fallos. En el momento en que una herramienta de sistema
experto es liberado para su uso general, todos los errores comunes deberan ser encontrados.
Sin embargo, puede haber errores que slo aparecen en raras circunstancias tales como
tener 159 reglas en la agenda. Algunos errores pueden ser muy sutiles y slo aparecen en
ciertas operaciones de reconocimiento de patrones.
En general, los errores del motor de inferencia pueden aparecer en reconocimiento de
patrones, resolucin de conflictos, y la ejecucin de las acciones. Estos errores pueden ser
difciles de detectar si no son consistentes. Si la herramienta de sistema experto se utiliza
para aplicaciones de misin crtica, se debe determinar cmo la herramienta fue validada.
 El mtodo ms simple de comprobar si hay errores de herramienta es el clsico de
preguntar a otros usuarios y al proveedor de la herramienta. El proveedor de la herramienta
debe estar dispuesto a proporcionar una lista de clientes, informes de errores y correcciones,
y cunto tiempo la herramienta ha estado en uso. Un grupo de usuarios es una excelente
fuente de informacin.
Los errores de la cadena de inferencia. Estos errores pueden ser causados por el
conocimiento errneo, errores semnticos, errores de motor de inferencia, la especificacin
incorrecta de la prioridad de las reglas, y las interacciones no planificadas entre las reglas. Los
errores de la cadena de inferencia ms complejos se deben a la incertidumbre de las reglas y
las pruebas, la propagacin de la incertidumbre en la cadena de inferencia, y no
monotonicidad.
La eleccin de un mtodo para tratar la incertidumbre no se resuelve automticamente
todos los temas relacionados con la incertidumbre. Por ejemplo, antes de elegir la inferencia
bayesiana simple, usted debe comprobar para ver si el supuesto de independencia
condicional est garantizado.
Lmites de los errores de la ignorancia. Un problema que es comn a todas las etapas
de desarrollo es especificando los lmites de la ignorancia del sistema. Como se mencion en
el captulo 1, los expertos humanos conocen el alcance de sus conocimientos y sus
actuaciones se degradan correctamente (esperamos) en los lmites de su ignorancia. Los
expertos humanos debe ser lo suficientemente honesto como para admitir una mayor
incertidumbre en sus conclusiones cerca de las fronteras. Sin embargo, a menos que un
sistema experto est especficamente programado para admitir la incertidumbre, es posible
que siga proporcionando respuestas, incluso si la cadena de inferencia y las pruebas son
dbiles.

6.5 INGENIERA DE SOFTWARE Y SISTEMAS EXPERTOS

En las secciones anteriores hemos hablado de las consideraciones generales en el uso del
paradigma de los sistemas expertos. Ahora vamos a examinar las etapas de desarrollo de sistemas
expertos desde la perspectiva ms tcnica del ingeniero del conocimiento que de hecho construye el
sistema.
Dado que los sistemas expertos se han trasladado fuera de la fase de investigacin existe una
necesidad real para entregar software de calidad a los estndares del software convencional. La
metodologa aceptada para el desarrollo de software de calidad para los estndares comerciales,
industriales, y el gobierno es la ingeniera de software.
Es importante seguir los buenos estndares en el desarrollo de un producto o el producto
probablemente no ser de buena calidad. Los sistemas expertos ahora deben considerarse un
producto como cualquier otro producto de software, tales como un procesador de textos, programa
de nminas, juego de ordenador, y as sucesivamente. Sin embargo, existe una diferencia
significativa de la misin entre los sistemas expertos y los productos tpicos de consumo, tales como
procesadores de texto y video juegos. La misin se refiere a la finalidad general de un proyecto o
una tecnologa. La tecnologa de sistemas expertos en general, tiene una misin seria de ser fuente
de conocimientos tcnicos en situaciones de alto rendimiento y posiblemente peligrosa en donde la
vida humana y la propiedad estn en juego. Estas son las aplicaciones de misin crtica que se
mencion en la seccin anterior.
Aplicaciones de misin crtica son diferentes de la ms relajada misin de los procesadores de texto
y videojuegos, que es aumentar la eficiencia y las actividades recreativas. La vida humana no puede
depender de un error en un procesador de textos o un videojuego (o al menos no debera).
Los sistemas expertos son sistemas de alto rendimiento que deben ser de alta calidad o sern
propensos a errores. La ingeniera de software ofrece metodologas para la construccin de software
de calidad, como se ilustra en la Figura 6.4.

Figura 6.4 Metodologa de la Ingeniera de Software

La calidad es un trmino difcil de describir en un sentido general, porque significa cosas diferentes
para personas diferentes. Una manera de definir la calidad es como los atributos necesarios o
deseables de un objeto determinado en alguna escala. El trmino objeto se utiliza aqu para referirse
a cualquier software o hardware. Los atributos y sus valores se llaman indicadores, ya que se
utilizan como medidas de un objeto. Por ejemplo, la fiabilidad de la medida de una unidad de disco
es un indicador de su calidad. Una medida de este atributo es el tiempo medio entre fallos (TMEF) de
la unidad. Una unidad confiable podra tener un TMEF de 1000 horas de uso entre los fallos,
mientras que una unidad poco confiable podra tener un TMEF de 100 horas.
La tabla 6.1 da una lista de algunos indicadores que pueden ser utilizados en la evaluacin de la
calidad de un sistema experto. Estas cifras slo se deben tomar como gua ya que un sistema
especfico de expertos puede tener ms o menos de estos. Sin embargo, el concepto importante es
tener una lista de indicadores necesarios que pueden ser utilizados en la descripcin de la calidad.
Una lista de indicadores le permitir con mayor facilidad un orden de prioridades dado que muchos
pueden entrar en conflicto con los dems. Por ejemplo, el aumento de las pruebas de un sistema
experto para asegurar su exactitud aumentar el costo. Decidir cundo finalizan las pruebas es
generalmente una decisin compleja que involucra los factores de horarios, costos y requisitos.
Idealmente, tres de estos requisitos deben ser satisfechos. En la prctica, algunos pueden ser
juzgados ms importantes que otros y las limitaciones de satisfacer todos los factores se debilitarn.

Salidas correctas dado una entrada correcta.

Salida completa dado una entrada correcta.
Salida consistente, dada la misma entrada de nuevo.
Confiable para que no falle (a menudo) debido a los errores.
til para las personas y, preferiblemente, de fcil uso.
Mantenible.
Mejorable.
Validado para demostrar que satisface necesidades y peticiones del usuario.
Prueba para demostrar exactitud e integridad.
Rentable.
Cdigo reutilizable para otras aplicaciones.
Portable a otros hardwares / software de entorno.
Compatible con otros programas.
Cdigo comprensible.
Preciso.
Degradacin elegante en los lmites del conocimiento.
Capacidad incorporada con otros idiomas.
Base de conocimiento verificado.
Explicacin de instalacin.

Tabla 6.1 Algunos Indicadores de Calidad de Software para Sistemas Expertos

6.6 CICLO DE VIDA DEL SISTEMA EXPERTO

Uno de los principales mtodos de ingeniera de software es el ciclo de vida. El ciclo de vida del
software es el perodo de tiempo que comienza con el concepto inicial del software y termina con su
retiro del uso. En lugar de pensar en el desarrollo y el mantenimiento por separado, el concepto de
ciclo de vida proporciona una continuidad que une todas las etapas. Planificacin para el
mantenimiento y la evolucin temprana del ciclo de vida reduce el coste de estas ltimas etapas.

Costos de mantenimiento.
Para el software convencional, el mantenimiento normalmente representa alrededor de 60 a 80 por
ciento de todos los costos de software y es generalmente de dos a cuatro veces el costo de
desarrollo original. Aunque hay poca informacin sobre el mantenimiento de los sistemas expertos,
porque son tan nuevas, las cifras probablemente sern peor para los sistemas expertos. Si los
programas convencionales con algoritmos conocidos requieren un mantenimiento tanto, entonces los
sistemas expertos es probable que requieran un mayor mantenimiento ya que se basan en el
conocimiento tanto que es heurstico y experimental. Sistemas expertos que hacen un montn de
inferencia bajo incertidumbre debe ser an ms susceptibles a los altos costos de mantenimiento y
su evolucin.
Modelo de Cascada
Una cantidad de diferentes modelos de ciclo de vida se han desarrollado para el software
convencional. El modelo en cascada clsico, familiar para los programadores de software
convencional, fue el original modelo de ciclo de vida y se ilustra en la Figura 6.5 (Boehm 84).

Figura 6.5 El modelo de cascada del ciclo de vida del software

En el modelo de cascada cada etapa termina con la verificacin y validacin (V & V) la actividad para
minimizar los problemas en esa etapa. Tambin, observe que las flechas van y vienen una sola
etapa a la vez. Esto representa el desarrollo iterativo de dos etapas adyacentes con el fin de
minimizar el costo en comparacin con el ms alto costo de la iteracin de desarrollo en varias
etapas.
Otro trmino para el ciclo de vida es el modelo de proceso, debido a que se refiere a dos aspectos
fundamentales del desarrollo de software:
(1) Qu se debe hacer a continuacin?
(2) Cunto tiempo debe la siguiente etapa en llevarse a cabo?
El modelo de proceso es en realidad un meta-metodologa, ya que determina el orden y la duracin
en el que los mtodos comunes de software son aplicados. Los mtodos comunes de software de
desarrollo (o metodologas) muestran los mtodos especficos para llevar a cabo una etapa como

Planificacin.
Requerimientos.
Adquisicin de conocimientos.
Pruebas.
Representacin de las etapas de los productos.
Documentacin.
Cdigo.
Diagramas.

Modelo Cdigo y corregir

Una serie de modelos de procesos se han utilizado para el desarrollo de software. El primer "modelo''
es el famoso modelo cdigo y corregir, en el que parte del cdigo est escrito y luego se corrige
cuando no funciona bien (Boehm 88). Este suele ser el mtodo de eleccin para los nuevos
estudiantes de programacin tanto en la programacin convencional y sistemas expertos.
En 1970 las deficiencias en el enfoque de cdigo y corregir eran tan evidentes que el modelo de
cascada fue desarrollado para proporcionar una metodologa sistemtica que fue especialmente til
para grandes proyectos. Sin embargo, hubo dificultades con el modelo de cascada, ya que asume
que toda la informacin necesaria para una etapa era conocida. En la prctica, a menudo no era
posible escribir los requisitos completos hasta que el prototipo haba sido construido. Esto llev al
concepto "hacerlo dos veces", en el cual se construy un prototipo, los requisitos determinados, y
entonces el sistema final fue construido.

Modelo Incremental
El modelo de cascada incremental es un refinamiento de la cascada y de la norma de arriba hacia
abajo. La idea bsica del desarrollo incremental es el desarrollo de software en incrementos de
capacidad funcional. El modelo incremental se ha utilizado con xito en grandes proyectos de
software convencional. El modelo incremental es til tambin para desarrollo de sistemas expertos,
en el que la adicin de reglas aumenta las capacidades del sistema de asistente a colega y por
ltimo a nivel de expertos. As, en un sistema experto los incrementos ms importantes son de
asistente, a algn conocido, y de colega a experto. Los incrementos menores corresponden a
incrementos de especializacin dentro de cada nivel que ofrecen algn aumento significativo. Un
micro incremento es el cambio en la experiencia mediante la adicin o mejoramiento de un estado
individual.
La principal ventaja del modelo incremental es que los incrementos en capacidad funcional son ms
fciles de probar, verificar y validar que los productos de las distintas fases en el modelo de cascada.
Cada incremento funcional puede ser probado, verificado y validado inmediatamente con el experto
en lugar de tratar de hacer la validacin de todo al final. Esto disminuye el costo de la incorporacin
de las correcciones en el sistema. En esencia, el modelo incremental es similar al de un prototipo
rpido continuo que se extiende sobre todo el desarrollo. Y no slo un prototipo rpido de las etapas
iniciales para determinar los requisitos en el enfoque "hacer dos veces", el prototipo en evolucin es
el sistema.

Modelo Espiral
Una forma de visualizar el modelo incremental es una adaptacin del modelo espiral convencional,
como se muestra en la Figura 6.6. Cada circuito de la espiral aade algunas capacidades
funcionales al sistema. La etiqueta de punto final "sistema Entregado" no es realmente el final de la
espiral. En cambio, una nueva espiral comienza con el mantenimiento y la evolucin del sistema. La
espiral puede ser refinada para especificar con mayor precisin las etapas generales de adquisicin
de conocimientos, de codificacin, evaluacin y planificacin.

Figura 6.6 Un Modelo Espiral de Desarrollo del Sistema Experto.

6.7 UN MODELO DE CICLO DE VIDA DETALLADO

Una modelo de ciclo de vida que ha sido utilizado con xito en una serie de proyectos de sistema
experto es el modelo lineal, que se ilustra en la Figura 6.7, una adaptacin de Bochsler (Bochsler
88). Este ciclo de vida se compone de una serie de etapas desde la planificacin hasta la evaluacin
del sistema y describe el desarrollo del sistema a un punto en el que sus capacidades funcionales
sern evaluadas. Despus de esto, el ciclo de vida repite esta misma secuencia, desde la
planificacin hasta la evaluacin del sistema hasta que el sistema se entrega para su uso rutinario. El
ciclo de vida se utiliza para el posterior mantenimiento y evolucin del sistema. Aunque no se
muestra explcitamente, la verificacin y validacin de proceden en paralelo con las etapas. En
lugar de simplemente arreglar algunos errores, es importante seguir adelante con la misma
secuencia de las etapas para mantener la calidad del sistema experto. Saltarse etapas, incluso para
arreglar un pequeo error, perjudica la calidad de todo el sistema.
El ciclo de vida muestra que puede ser considerado un circuito del modelo espiral. Cada etapa
consta de tareas. No todas las tareas pueden ser necesarias para una etapa, especialmente cuando
el sistema entra en mantenimiento y evolucin. En cambio, las tareas pretenden servir como una
combinacin de todas las tareas para el ciclo de vida completo, desde el concepto inicial hasta la
jubilacin del software. Las tareas tambin dependern del tipo exacto de aplicacin en construccin
y por lo que slo deben considerarse como una gua, en lugar de requisitos indispensables que se
deben realizar para cada etapa que se complete.
Este modelo de ciclo de vida se discutir en detalle para ilustrar los muchos factores que deben ser
considerados para un sistema experto de gran calidad. Para los pequeos prototipos de tipo
investigacin que no estn destinados al uso general, no todas las tareas o etapas son necesarias.
Sin embargo, es increble la cantidad de software que se desarrolla para uso personal o de
investigacin se liberan y son asociados al uso general.

Figura 6.7 El modelo lineal de desarrollo del ciclo de vida del sistema experto

Planificacin
El propsito de la etapa de planificacin es la de producir un plan de trabajo formal para el desarrollo
de sistemas expertos. El plan de trabajo es un conjunto de documentos que se utilizarn para
orientar y evaluar el desarrollo. En la Tabla 6.2 se muestran las tareas en esta etapa.

Tarea
Evaluacin de Viabilidad
Manejo de los Recursos
Organizar las Tareas
Horarios
Diseo Funcional Preliminar
Requerimientos de Alto Nivel
Tabla 6.2 Tareas de la Etapa de Planeamiento
Objetivos
Determinar si vale la pena construir el sistema y,
de ser as, si la tecnologa del sistema experto
debe ser utilizada.
Evaluar los recursos de las personas, tiempo,
dinero, software y hardware necesario. Cmo
adquirir y gestionar los recursos necesarios?
Especificar las tareas y su orden en las etapas.
Especificar las fechas de inicio y entrega de
tareas en las etapas.
Definir lo que el sistema debe lograr mediante la
especificacin de las funciones de alto nivel del
sistema. Esta tarea especifica el objetivo del
sistema.
Describir en trminos de alto nivel cmo el
funcionamiento del sistema se llevar a cabo.

El estudio de viabilidad es la tarea ms importante en el ciclo de vida. La evaluacin debe responder

a la pregunta de si el proyecto vale la pena y la pregunta relacionada de si un sistema experto es el
paradigma adecuado. Las respuestas a estas dos preguntas determinan si el proyecto debe
proceder utilizando un enfoque de sistemas expertos. Muchos factores estn involucrados en el
estudio de viabilidad. Como se discuti en la Seccin 6.1 estos factores incluyen la seleccin de un
dominio apropiado de los sistemas expertos, el costo, rentabilidad, entre otros.
Definicin del conocimiento
El objeto de la etapa de definicin del conocimiento es definir los requisitos de conocimiento del
sistema experto. La etapa de definicin de conocimiento consiste en dos tareas principales, a saber:
Identificacin de la fuente del conocimiento y seleccin.
La adquisicin de conocimientos, anlisis y extraccin.

Cada una de estas tareas principales se compone de otras tareas. La Tabla 6.3 describe las tareas
de Identificacin de la fuente y la seleccin.

Tarea
Identificacin de la Fuente
Fuente Importante
Fuente Disponible
Seleccin de la Fuente
Tabla 6.3 Identificacin de la fuente del conocimiento y las tareas de seleccin
Objetivo
Quin y qu son las fuentes de conocimiento, sin
tener en cuenta la disponibilidad.
Lista prioritaria de fuentes de conocimiento en orden
de importancia para el desarrollo.
Listado de fuentes de conocimiento en orden de
disponibilidad. Libros y otros documentos son
generalmente mucho ms accesibles que los
expertos humanos.
Seleccionar las fuentes de conocimiento basadas en
la importancia y disponibilidad.

Tareas de adquisicin, anlisis y extraccin se describen en la Tabla 6.4

Tarea Objetivo
Estrategia de Adquisicin Especificar cmo el conocimiento se adquiere
mediante mtodos de entrevistar a los expertos, la
lectura de documentos, la induccin de reglas, las
redes de repertorio, y as sucesivamente.
Identificacin de los Seleccionar los conocimientos especficos de las
Elementos del fuentes que sern de utilidad en esta iteracin del
Conocimiento ciclo de vida.
Sistema de Clasificacin del Clasificar y organizar el conocimiento para ayudar
Conocimiento en la verificacin del conocimiento y comprensin
por parte de los desarrolladores. Utilice grupos
jerrquicos siempre que sea posible.
Diseo Funcional Detallado Especificar las capacidades funcionales del sistema
en detalle. Esto est en un nivel ms tcnico,
mientras que el diseo funcional preliminar es a
nivel gerencial.
Control de Flujo Preliminar Describir las fases generales que el sistema
experto ejecutar. Las fases corresponden a las
reglas lgicas que se activan / desactivan en
grupos para controlar el flujo de ejecucin.
Manual de Usuario Describe el sistema desde el punto de vista del
Preliminar usuario. Una parte a menudo ignorado, pero
esencial del sistema. Es absolutamente importante
involucrar a los usuarios tan pronto como sea
posible para la retroalimentacin. Si ellos no utilizan
el sistema, es intil.
Especificaciones de los Definir exactamente lo que el sistema tiene que
Requerimientos hacer.
El sistema experto ser validado utilizando estos
requisitos.
Conocimientos Bsicos Base de conocimiento para el sistema. Cualquier
cambio, ahora debe ser realizado por una solicitud
de cambio formal. El conocimiento de alto nivel es
ahora adecuado para la siguiente etapa de diseo
del conocimiento.
Tabla 6.4 Adquisicin de conocimientos, anlisis y extraccin de las tareas

El principal objetivo de la tarea de adquisicin de conocimientos, la tarea de anlisis del

conocimiento, y la tarea de extraccin del conocimiento es para producir y verificar los conocimientos
requeridos por el sistema. En el momento en que el conocimiento es lnea de referencia, este debe
ser correcto y adecuado para la siguiente etapa de diseo del conocimiento. Adems de la forma
tradicional de entrevistas a expertos, otras tcnicas tales como el repertorio de redes o teora de
constructos personales podrn ser utilizados para llevar a cabo la adquisicin de conocimientos
automatizados (Boose 84).

Diseo del Conocimiento

El objetivo de la etapa de diseo para producir el conocimiento es el diseo detallado de un sistema
experto. Hay dos tareas principales que componen esta etapa:
Definicin del conocimiento.
Diseo detallado
La Tabla 6.5 se describen las tareas asociadas con la definicin del conocimiento.
Tarea Objetivo
Representacin del Representacin del conocimiento. Especificar cmo
Conocimiento el conocimiento se representa, como reglas,
marcos, o lgica. Depende de lo que la herramienta
de sistema experto de apoyo.
Control de Estructura Especificar tres estructuras de control general: (1)
Detallada Si el sistema est incrustado en el cdigo de
procedimiento, cmo ser llamado. (2) El control de
los grupos relacionados de reglas dentro de un
sistema de ejecucin. (3) meta nivel de estructuras
de control de las normas.
Estructura Interna de Especificar la estructura interna de los hechos de
Hechos una manera consistente para ayudar en la
 comprensin y el buen estilo.
Interfaz de Usuario Especifique una interfaz de usuario preliminar.
Preliminar Obtener retroalimentacin de los usuarios acerca
de la interfaz.
Plan de Prueba Inicial Especificar cmo el cdigo se pondr a prueba.
Definir los datos de prueba, los pilotos de pruebas,
y como los resultados de las pruebas sern
analizados.
Tabla 6.5 Tareas de Definicin del Conocimiento

Las estructuras internas de hechos descritos en la Tabla 6.5 se discuten con ms detalle en los
captulos de CLIPS. La idea bsica de especificar las estructuras de hechos es la adaptacin de un
buen estilo. Por ejemplo, un hecho como el "10" no es muy significativo por s mismo. Qu
representa el "10"? Si se incluye informacin adicional con el hecho como "precio es 10" o, mejor
an, "el precio del oro es 10", entonces el precio del oro es significativo. Tenga en cuenta que esta
forma de la realidad es convencional de la forma objeto-atributo-valor, lo que es conveniente a las
personas para leer y entender. CLIPS apoya esto a travs de la construccin deftemplate de las
normas, y tambin a travs de objetos.
En algunos lenguajes de sistemas expertos los campos pueden tener tipos fuertes para que slo se
permita ciertos valores, si una norma trata de especificar un valor que no est permitido, el motor de
inferencia indicar esto como un error, los detalles de la etapa de diseo del conocimiento se
muestra en la tabla 6.6.
El producto de la etapa de diseo detallada es la lnea de referencia del documento de diseo desde
el que se puede proceder la codificacin. La lnea de referencia del documento de diseo se somete
a un sistema de conocimientos de revisin del diseo como una revisin final antes de que comience
la codificacin.

Tarea Objetivo
Diseo de la Estructura Especificar cmo el conocimiento est organizado
lgicamente en la base de conocimientos y lo que
hay en la base de conocimientos.
Estrategia de la Especificar cmo el sistema se ejecutar.
Implementacin
Interfaz de Usuario Especificar la interfaz de usuario detallada despus
Detallada de recibir comentarios de los usuarios desde el
diseo preliminar de la interfaz de usuario.
Especificaciones de Diseo Documentar el diseo.
e Informe
Plan de Pruebas Detallado Especificar exactamente cmo el cdigo ser
probado y verificado.
Tabla 6.6 Tareas detalladas del diseo del conocimiento.

Cdigo y comprobacin
La tabla 6.7 describe el cdigo y la etapa de comprobacin, el cual comienza la implementacin del
cdigo actual.
Tarea Objetivo
Codificacin Implementar la codificacin.
Prueba Cdigo de ensayo a partir de datos de prueba,
pilotos de pruebas, y procedimientos de anlisis de
pruebas.
Listado de Origen Producir comentarios, cdigo fuente documentado.
Manual de Usuario Producir manual de usuario de trabajo de lo que los
expertos y los usuarios pueden proporcionar
informacin sobre el sistema.
Gua de Instalacin / Uso Documento de instalacin / funcionamiento del
sistema para los usuarios.
Documento de Descripcin Documento general del funcionamiento del sistema
del Sistema experto, las limitaciones y problemas.
Tabla 6.7 Tareas de Codificacin y Prueba

Esta etapa termina con la de prueba de revisin de Disponibilidad, que determina si el sistema
experto est listo para la siguiente etapa de la verificacin del conocimiento.

Verificacin de Conocimientos
El objetivo de la fase de verificacin del conocimiento es determinar la exactitud, integridad y
coherencia del sistema. Esta etapa se divide en dos tareas principales:
Pruebas formales.
Prueba de anlisis.

La tabla 6.8 describe las tareas de prueba formal de la etapa de verificacin del conocimiento.

Tarea Objetivo
Procedimientos de Prueba Implementar Procedimientos formales de prueba
Informes de Ensayo Documentar los Resultados de la Prueba.
Tabla 6.8 Tareas de de prueba formal de la etapa de verificacin de conocimientos

Las tareas de la prueba de anlisis se muestran en la Tabla 6.9. La prueba de anlisis busca los
siguientes problemas principales:
Respuestas incorrectas.
Respuestas incompletas.
Respuestas inconsistentes.
y determina si el problema radica en las reglas, las cadenas de inferencia, la incertidumbre, o alguna
combinacin de estos tres factores. Si el problema no puede ser precisado en el sistema experto, es
necesario analizar el sistema experto con herramientas de software para los errores.
Tarea Objetivo
Resultado de las Analizar los resultados de las pruebas
Evaluaciones
Recomendaciones Documentar recomendaciones y conclusiones de
las pruebas
Tabla 6.9 Tareas de pruebas de anlisis

Evaluacin del Sistema

Como se describe en la Tabla 6.10, la ltima etapa del ciclo de vida de desarrollo es la etapa de
evaluacin del sistema. El propsito de esta etapa es resumir lo que se ha aprendido con las
recomendaciones de mejoras y correcciones.

Tareas Objetivos
Evaluacin de Resultados Resumir el resultado de pruebas y verificacin
Recomendaciones Recomendar modificaciones en el sistema
Evaluaciones Validar que el sistema es correcto con respecto a
las necesidades del usuario y los requisitos
Informe Previsional o Final Si el sistema est completo, emitir un informe final.
Si no es as, un informe provisional.
Tabla 6.10 Tareas de las Etapas de Evaluacin del sistema.

Dado que un sistema experto es generalmente construido en iteraciones, el informe de la etapa de

evaluacin del sistema por lo general ser un informe intermedio sobre el aumento de la
funcionalidad del sistema con los nuevos conocimientos aadidos. Sin embargo, la capacidad del
nuevo sistema debe ser verificado por s mismo y tambin como parte de los conocimientos previos
en el sistema. Es decir, el sistema de verificacin debe realizarse en conjunto con todo el
conocimiento del sistema, no slo los nuevos conocimientos. El sistema experto tambin debe
validarse cada vez en esta etapa en vez de esperar la iteracin final. Sistemas automatizados para la
validacin de las bases de conocimiento tambin se estn investigando (Stachowitz 87).