Sistema experto basado en reglas para la documentación de requerimientos de Software (página 2)

9.2.2 DIMENSIONES DE LA INGENIERÍA DE REQUERIMIENTOS

Una posible visión de la ingeniería de requerimientos es considerarla como un proceso de construcción de una especificación de requerimientos en el que se avanza desde especificaciones iniciales, que no poseen las propiedades oportunas, hasta especificaciones finales completas, formales y acordadas entre todos los participantes, (ver figura 5) [POH 1994].

Figura 5. Dimensiones de la Ingeniería de Requerimientos

Fuente: Informática Gestión – Sistemas

Por un lado están los factores psicológicos y cognitivos que afectan al grado de constitución del conocimiento sobre el sistema que se desea desarrollar, es decir, el llegar a conocer la totalidad de los requerimientos que debe satisfacer el sistema.

Por otro lado, está el grado de formalismo de la representación del conocimiento sobre dichos requerimientos, teniendo en cuenta que un mayor grado de formalismo no implica necesariamente un mayor conocimiento [POH, 1997].

Por último, como ya se comentó anteriormente, están los aspectos sociales, ya que al ser un proceso en el que participan personas con diferentes puntos de vista, es necesario llegar a un punto de acuerdo, normalmente mediante algún tipo de negociación [BOE, 1994].

Estos factores pueden representarse como tres dimensiones [POH, 1994], de forma que durante el proceso de ingeniería de requerimientos se avanza desde especificaciones incompletas, informales e individuales hacia la especificación ideal que sería completa, formal y acordada entre todos los participantes.

Como complemento a este modelo, se afirma que las actividades del proceso de ingeniería de requerimientos serían los vectores que hacen avanzar las especificaciones hacia su situación ideal.

Así, las actividades de elicitación harían avanzar el proceso en las dimensiones de constitución y acuerdo, las actividades de análisis lo harían en constitución y formalidad y las actividades de validación.

9.2.3 CONCEPTO DE REQUERIMIENTO

Una de las características de la IR es la falta de uniformidad en la terminología empleada, tanto para los conceptos básicos como para los procesos y los productos [DAV, 1993], [BRA, 1990], [POH, 1997]. Uno de los conceptos afectados por dicha falta de uniformidad es el de requerimiento.

La definición que aparece en [IEEE, 1990] es la siguiente:

Requerimiento (1):

(a) una condición o capacidad que un usuario necesita para resolver un problema o lograr un objetivo.

(b) una condición o capacidad que debe tener un sistema o un componente de un sistema para satisfacer un contrato, una norma, una especificación u otro documento formal.

(c) una representación en forma de documento de una condición o capacidad como las expresadas en (a) o en (b).

Mientras que la que aparece en [DOD, 1994] es más concisa:

Requerimiento (2): característica del sistema que es una condición para su aceptación.

Otra posible definición es la siguiente [GOG, 1994]:

Requerimiento (3): propiedad que un sistema debería tener para tener éxito en el entorno en el que se usará.

Sin embargo, a pesar de esta aparente simplicidad del concepto, es frecuente encontrar el término requerimiento calificado con adjetivos que pueden resultar confusos en un primer momento: de sistema, hardware, software, de usuario, de cliente, funcional, no funcional, etc.

9.2.4 DIMENSIONES DE LOS REQUERIMIENTOS

La gran cantidad de calificativos que se aplican al término requerimiento muestran distintos aspectos ortogonales que ha menudo se consideran aisladamente.

Para intentar clarificar la situación, se puede identificar tres dimensiones en las que se pueden clasificar los requerimientos, (ver figura 6). Estas tres dimensiones son:

• Ámbito: esta dimensión indica en qué ámbito se debe entender el requerimiento. En general, y siguiendo entre otras las propuestas de [IEEE, 1997], [DOD, 1994] y [DAV, 1993], un ámbito de sistema indica que el requerimiento debe cumplirse a nivel de sistema, entendiendo por sistema un conjunto de hardware y software.

Figura 6. Dimensiones de los Requerimientos

Fuente: Informática Gestión – Sistemas

Si el ámbito es de software quiere decir que el requerimiento sólo afecta a la parte software de un sistema, mientras que si es el ámbito es de hardware sólo afecta a la parte hardware.

Para entender esta clasificación conviene recordar que [DOD, 1994] es una norma militar y que las normas [IEEE, 1997] están fuertemente influidas por dichas normas militares. En el contexto de los desarrollos para fines militares es frecuente tener que desarrollar sistemas en los que el hardware juega un papel tan importante como el software.

La concepción de sistema como conjunto, hardware y software, no es la única. Por ejemplo, en Métrica V2.1 [MAP, 1995] se denominan requerimientos del sistema a los requerimientos que ha de cumplir el sistema a desarrollar, entendiendo por sistema el conjunto de procesos tanto automáticos como manuales. En esta situación se pueden encontrar matices que indiquen si un requerimiento se refiere al sistema en su conjunto o sólo al software, aunque en general dichas diferencias se obvian y no se diferencia entre los distintos ámbitos.

Las dimensiones se describen a continuación:

– Característica que define: esta dimensión clasifica los requerimientos en función de la naturaleza de la característica del sistema deseada que se especifica. La clasificación más habitual suele ser la de requerimientos funcionales (qué funciones debe realizar el sistema) y no funcionales (otras características del sistema).

En [POH,1997] aparece una completa clasificación denominada RSM (Requirements Specification Model, Modelo de Especificación de Requerimientos), cuyas principales clases son: requerimientos funcionales, requerimientos de datos y requerimientos no funcionales.

Siguiendo la clasificación RSM, es conveniente separar de los requerimientos funcionales a los requerimientos de datos o de almacenamiento de información, que establecen qué información debe almacenar el sistema por ser relevante para las necesidades y objetivos de clientes y usuarios.

Es conveniente destacar que al grupo de requerimientos no funcionales no se le ha prestado la atención suficiente y que ya hay opiniones que lo consideran como heterogéneo donde se han clasificado aquellos requerimientos que resultan incómodos [BAS, 1998]. Un ejemplo de esta situación es la escasa importancia que se les ha dado en las técnicas de modelado de sistemas, tanto estructuradas como orientadas a objetos o formales.

– Audiencia: Esta dimensión fundamental, indica la audiencia a la que está dirigido el requerimiento, es decir, las personas que deben ser capaces de entenderlo. En general, se pueden distinguir dos tipos de audiencia, los clientes y usuarios, que no tienen porqué tener formación en ingeniería del software, y los desarrolladores de software.

Cuando la audiencia está formada por clientes y usuarios, la forma más habitual de definir los requerimientos es mediante lenguaje natural.

En el caso de que la audiencia prevista esté formada por desarrolladores de software, los requerimientos suelen expresarse mediante un modelo, normalmente utilizando técnicas estructuradas, orientadas a objetos o formales.

Se usará como referencia la nomenclatura propuesta en [ROM, 1990] y en [BRA, 1990] en la que se denominan requerimientos orientados al cliente, abreviadamente requerimientos–C, a los requerimientos desde el punto de vista de los clientes y usuarios, y requerimientos orientados al desarrollador, abreviadamente requerimientos–D, a los requerimientos desde el punto de vista de los desarrolladores.

No obstante, es relativamente frecuente encontrar el término requerimiento de usuario o requerimiento de cliente para designar requerimientos–C de sistema o de software, y el término requerimiento software para designar requerimientos–D de software, se usará los dos tipos de requerimientos ya que están relacionados.

Un ejemplo de este uso puede verse en las normas de desarrollo de software de la Agencia Espacial Europea [MAZ, 1994].

9.3 SISTEMAS EXPERTOS

9.3.1 DEFINICIÓN DE SISTEMA EXPERTO

La más poderosa contribución de los sistemas expertos es poner al servicio de los analistas noveles la experiencia adquirida por aquellas personas consideradas verdaderos especialistas en el área. [DAV, 1993]

Un SE, es un software que imita el comportamiento de un experto humano en la solución de un problema. Pueden almacenar conocimientos de expertos para un campo determinado y solucionar un problema mediante deducción lógica de conclusiones. [MED, 2004]

Programas que contienen tanto conocimiento declarativo (hechos a cerca de objetos, eventos y/o situaciones) como conocimiento de control (información a cerca de los cursos de una acción), para emular el proceso de razonamiento de los expertos humanos en un dominio en particular y/o área de experiencia. [CAT, 1999]

Para el presente trabajo se utilizará la siguiente definición: Software que incorpora conocimiento de experto sobre un dominio de aplicación dado, de manera que es capaz de resolver problemas de relativa dificultad y apoyar la toma de decisiones inteligentes en base a un proceso de razonamiento simbólico. [CAS, 2002]

9.3.2 COMPONENTES DE UN SISTEMA EXPERTO

Una característica decisiva de los Sistemas Expertos es la separación entre conocimiento (reglas, hechos) por un lado y su procesamiento por el otro. A ello se añade una interfaz de usuario y un componente explicativo, (ver figura 7).

A continuación se muestra una breve descripción de cada uno de los componentes:

1. La Base de Conocimientos de un Sistema Experto contiene el conocimiento de los hechos y de las experiencias de los expertos en un dominio determinado.
2. El Mecanismo de Inferencia de un Sistema Experto puede simular la estrategia de solución de un experto.
3. El Componente Explicativo explica al usuario la estrategia de solución encontrada y el porqué de las decisiones tomadas.
4. La Interfaz de Usuario sirve para que éste pueda realizar una consulta en un lenguaje lo más natural posible.
5. El Componente de Adquisición ofrece ayuda a la estructuración e implementación del conocimiento en la base de conocimientos.

Figura 7. Componentes de un Sistema Experto

Fuente: Sistemas Expertos: Aspectos Técnicos http://ciberconta.es/selecciones/sistexpatll00.htm

9.3.3 TIPOS DE CONOCIMIENTO

Existen dos tipos:

• Conocimiento abstracto, es de validez general y se almacena permanentemente.
• Conocimiento concreto, es de validez particular y se almacena temporalmente. Son los datos o hechos de un problema especifico que es resuelto por el Sistema Experto.

Para el presente trabajo se usará los dos tipos de conocimiento. El primero, como se usará marcos de problema elementales, serán de validez general los cuales se almacenaran permanentemente y el tipo de conocimiento concreto será empleado cuando se resuelva un problema en especifico partiendo de lo general a lo particular.

9.3.4 FUENTES DE CONOCIMIENTO

Existen dos tipos:

• Fuentes Primarias, acceso directo al conocimiento (Experto Humano, libros, textos, Internet).
• Fuentes Secundarias, acceso indirecto a la información (Referencias, Publicaciones). [MED, 2004]

Los cuales se emplearan en el desarrollo del presente trabajo.

9.3.5 CLASIFICACION DE LOS SISTEMAS EXPERTOS

Los sistemas expertos se clasifican de acuerdo al tipo de conocimiento que se utiliza:

• Sistemas Expertos basado en reglas, la construcción de la base de conocimiento es en base a reglas, lo cual, en algunos casos se elabora sencillamente, la explicación de las conclusiones es simple. El motor de inferencia se realiza con algoritmos complejos, lo cual es relativamente lento, además que el aprendizaje estructural es complejo.
• Sistemas Expertos basado en probabilidades, la construcción de la base de conocimiento es en base a frecuencias lo cual requiere de mucha información, la explicación de las conclusiones resulta mas compleja. El motor de inferencia se realiza con algoritmos simples, el aprendizaje parametrico es sencillo. [MED, 2004]

Se empleará el conocimiento basado en reglas porque la información con que se cuenta es de tipo determinístico, ya que se recabará datos históricos, de proyectos que fracasaron así como de los que lograron superar los obstáculos en las etapas iniciales del desarrollo de software, de las consultoras de software.

9.3.6 SISTEMAS EXPERTOS BASADOS EN REGLAS

Los sistemas basados en reglas son los más comúnmente utilizados. Su simplicidad y similitud con el razonamiento humano, han contribuido para su popularidad en diferentes dominios. Las reglas son un importante paradigma de representación del conocimiento. [CAT, 1999]

Las reglas representan el conocimiento utilizando un formato SI-ENTONCES (IF-THEN), es decir tienen 2 partes:

• La parte SI (IF), es el antecedente, premisa, condición o situación.
• La parte ENTONCES (THEN), es el consecuente, conclusión, acción o respuesta.

Las reglas pueden ser utilizadas para expresar un amplio rango de asociaciones,

Una declaración de que algo es verdadero o es un hecho conocido, es una afirmación. El conjunto de afirmaciones se conoce frecuentemente con el nombre de base de afirmaciones. De igual forma, al conjunto de reglas se lo denomina base de reglas.

Un sistema basado en reglas utiliza el modus ponens para manipular las afirmaciones y las reglas durante el proceso de inferencia. Mediante técnicas de búsqueda y procesos de unificación, los sistemas basados en reglas automatizan sus métodos de razonamiento y proporcionan una progresión lógica desde los datos iniciales, hasta las conclusiones deseadas. Esta progresión hace que se vayan conociendo nuevos hechos o descubriendo nuevas afirmaciones, a medida que va guiando hacia la solución del problema.

En consecuencia, el proceso de solución de un problema en los sistemas basados en reglas va realizando una serie de inferencias que crean un sendero entre la definición del problema y su solución, es por estas razones que utilizaremos el conocimiento basado en reglas para nuestro objeto bajo estudio. Las inferencias están concatenadas y se las realiza en forma progresiva, por lo que se lo que se dice que el proceso de solución origina una cadena de inferencias.[CAT, 1999]

9.4 METODOLOGIA DE WEISS Y KULIKOWSKI

Para el desarrollo de un sistema experto Weiss y Kulikowski [WEI, 1984] sugieren las siguientes etapas para el diseño e implementación de un sistema experto, ver la figura 8.

1. Planteamiento del problema. La primera etapa en cualquier proyecto es normalmente la definición del problema a resolver. Puesto que el objetivo principal de un sistema experto es responder a preguntas y resolver problemas, esta etapa es quizás la más importante en el desarrollo de un sistema experto. Si el sistema está mal definido, se espera que el sistema suministre respuestas erróneas.
2. Encontrar expertos humanos que puedan resolver el problema. En algunos casos, sin embargo, las bases de datos pueden jugar el papel del experto humano.
3. Diseño de un sistema experto. Esta etapa incluye el diseño de estructuras para almacenar el conocimiento, el motor de inferencia, el subsistema de explicación, la interfaz de usuario, etc.
4. Elección de la herramienta de desarrollo. Debe decidirse si realizar un sistema experto a medida utilizando lenguaje de programación.
5. Desarrollo y prueba de un prototipo. Si el prototipo no pasa las pruebas requeridas, las etapas anteriores (con las modificaciones apropiadas) deban ser repetidas hasta que se obtenga un prototipo satisfactorio.
6. Refinamiento y generalización. En esta etapa se corrigen los fallos y se incluyen nuevas posibilidades no incorporadas en el diseño inicial. Mantenimiento y puesta al día. En esta etapa el usuario plantea problemas o defectos del prototipo, corrige errores, actualiza el producto con nuevos avances, etc.

Todas estas etapas influyen en la calidad del sistema experto resultante, que siempre debe ser evaluado en función de las aportaciones de los usuarios.

Figura 8. Etapas en el Desarrollo de un Sistema Experto

Fuente: Sistemas Expertos y Modelos de Redes Probabilísticas Enrique Castillo, José Manuel Gutiérrez, y Ah S. Hadi. [CAT, 1999]

9.5 LENGUAJE DE MODELADO UNIFICADO UML

El presente proyecto tomará en cuentan los componente de un sistema experto desde el punto de vista de UML.

9.5.1 REQUERIMIENTOS

Son una descripción de las necesidades o deseos de un producto. Su objetivo es identificar y documentar lo que en realidad se necesita, en forma que claramente se comunique al cliente, estos deben ser definidos de manera inequívoca de modo que se detecten los riesgos y no se presenten sorpresas al momento de entregar el producto.

Se recomienda los siguientes puntos:

• Panorama General: Se limita el campo de acción.
• Clientes: Se realiza una lista de los involucrados.
• Metas: Se lista los objetivos, estos deben limitarse al panorama general.
• Funciones del sistema: Hay que identificarlas y listarías en grupos cohesivos y lógicos.
• Atributos del Sistema: Es el listado de características o dimensiones, cabe mencionar que no son funciones, pero pueden abarcar todas las funciones o ser específicos de un función o grupo de funciones.

9.5.2 CASOS DE USO

El caso de uso es una estructura para describir la forma en que un sistema lucirá para los usuarios potenciales, su elaboración se la realiza con la colección de escenarios iniciadas por una entidad llamada actor7, el resultado del caso de uso deberá tener algún valor, ya sea para el actor que lo inició o para otro, también es posible volver a utilizar un caso de uso para ello existen dos maneras. [LAR-99]

La primera es por "inclusión", la cual consiste en utilizar los pasos de un caso de uso como parte de la secuencia de pasos de otro caso de uso.

La segunda forma es por "extensión" el cual consiste en crear un nuevo caso de uso mediante la adición de pasos a un caso de uso existente.

Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema, ellos están contenidos en un documento narrativo que describe a secuencia de eventos del actor (agente externo) que utiliza un sistema para completar un proceso. UML incluye formalmente el concepto de casos de uso y sus diagramas de uso, a continuación su descripción:

(1) NOMBRE DEL CASO DE USO: Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen tácitamente los requerimientos en las historias que narran, su representación grafica se ubica en la Figura 9 (a).

(2) LOS ACTORES: Están representados por el papel que desempeñan en el caso: una persona, un componente de hardware u otro sistema. Conviene escribir su nombre con mayúscula en la narrativa del caso para facilitar la identificación, su representación gráfica se ubica en la Figura 9 (b)

(3) LÍNEAS DE INTERCONEXIÓN: Una línea asociativa conecta a un actor con el caso de uso y representa la comunicación entre el actor y el caso de uso. La línea asociativa es sólida, corno a que conecta a las clases asociadas, su representación grafica se ubica en la Figura 9 (d).

(4) LOS SISTEMAS Y SUS FRONTERAS: Un caso de uso describe la interacción con un "sistema". Las fronteras ordinarias del sistema son: la frontera hardware / software de un dispositivo o sistema de computo, el departamento de una organización, la organización entera. Es importante definir la frontera del sistema para identificar lo que es interno o externo, así como las responsabilidades del sistema. El ambiente externo está representado únicamente por actores, y el interno por casos de uso, su representación grafica se ubica en la Figura 9 (c). [SCH-2000]

Ya elaborados los casos de uso no es necesario, pero sirve de ayuda realizar un modelo conceptual, el cual se lo representa por medio de diagramas de clases, este muestra gráficamente (ver figura 10) un grupo de diagramas que describen los conceptos, objetos, los atributos, acciones y las asociaciones del dominio que se juzgan importantes.

Ya identificadas las clases de realiza la descripción diagramas de secuencias, estos describen el curso particular de los eventos de un caso de uso, los actores internos que interactúan directamente con el sistema (como caja negra), y con los eventos del sistema generados por los actores. [LAR-99]

Con la información hasta ahora recolectada se puede elaborar la base de conocimiento y la base de hechos, esto gracias a la información que recabo los diagramas de clases.

Ya expuesto los requerimientos y los casos de uso, se ampliara como UML realiza el modelado de un sistema experto.

Figura 9. Iconos Del Lenguaje UML Para La Descripción De Procesos

Fuente: UML Y Patrones Introduccion Al Analisis Y Diseño Orientado A Objetos De Craig Larman

Figura 10. Representación De Los Diagramas De Clase

Fuente: Fuente: UML Y Patrones Introduccion Al Analisis Y Diseño Orientado A Objetos De Craig Larman

9.5.3 BASE DE CONOCIMIENTO

No es el único componente de un sistema experto. Si lo fuera un sistema experto podría ser tan solo una lista de reglas condicionales if – then. Lo que se necesita es un mecanismo para operar a lo largo de la base de conocimiento para resolver un problema.

A tal mecanismo se le conoce como motor de inferencia, otra pieza necesaria es el área de trabajo que contenga las condiciones del problema, esta captura puede realizarse mediante una lista de verificación, preguntas y respuestas de opción múltiple o un sistema extremadamente sofisticado sentado en el idioma natural. Para interactuar con el sistema experto el usuario captura las condiciones de un problema en la interfaz del usuario, mismas que las almacena en el área de trabajo. El motor de inferencia se vale de tales condiciones para buscar una solución en la base de conocimiento, la Figura 11, muestra un diagrama de secuencias de este proceso.

Figura 11. Interacción De Un Sistema Experto

Fuente: APRENDIENDO UML EN 24 HORAS

1e Joseph Schmuller-2000

9.5.4 MODELADO DE LA BASE DE CONOCIMIENTO

La representación de UML para las reglas son como objetos. Contar con uno de los atributos para que sea la parte if, otra la parte then, agregar otros atributos conforme sea necesario.

Figura 12. Diseño de la regla mediante UML

Fuente: APRENDIENDO UML EN 24 HORAS

De Joseph Schrnuller-2000

Para balancear la proliferación respecto a la necesidad de la simplicidad, primero se crea un sencillo icono que representa a la regla en la Figura 12, se llena la parte de if y la parte de then, seguidamente se debe de incorporar cierta información de identificación para cada regla, se agrega su nombre en la parte superior: esto logra un par de cosas:

(1) Convierte a cada regla en única

(2) Muestra a donde ir en el catalogo de reglas para obtener una descripción y explicación completa de la regla.

Si una regla es parte de un subgrupo de reglas, se puede tratar al subconjunto como un paquete. Luego agregar el paquete de información al identificador de la forma usual propia del UML, hacer que el nombre del paquete anteceda a un par de dos puntos (::), que antecedan al identificador. Concluido el paso de análisis de requisitos, se pasa al siguiente paso el "Diseño del Sistema Experto".

10. METODOS Y TECNICAS

Las investigaciones que se emplearán en el desarrollo del trabajo de grado son:

INVESTIGACIÓN DESCRIPTIVA

La investigación descriptiva busca especificar propiedades, características y rasgos importantes de cualquier fenómeno que se analice. [HERNÁNDEZ, 2002]

Se tendrá una investigación descriptiva debido a que se busca especificar los requerimientos de software, recolectando información que ayude a esta investigación, para poder elaborar la documentación de requerimientos de software acorde a los problemas que presenten en la actualidad los desarrolladores de software.

10.1 MÉTODOS

"El método es una especie de brújula en la que no se produce automáticamente el saber, pero que evita perdernos en el caos aparente de los fenómenos, aunque solo sea porque indica como no plantear los problemas y como no sucumbir en el embrujo de prejuicios predilectos". [SAM, 1996]

El método es el camino para llegar a un fin. En consecuencia, los métodos de investigación serán los procedimientos que se apliquen para lograr los objetivos que los investigadores se proponen.

Los distintos métodos que se utilizarán en el desarrollo del trabajo de grado son:

10.1.1 MÉTODO CIENTÍFICO

John Dewey (1910) en su obra "How We Think" establece cinco pasos en el pensamiento reflexivo (que ahora se asocia y describe como Metodología de la investigación, Roberto Hernández Sampieri, Carlos Fernández Collado, Pilar Baptista Lucio, 63 pp., Mc Graw Hill, Colombia 1996, ): [LAB, 2001]

1. Percepción de una dificultad
2. Identificación y definición de la dificultad
3. Soluciones propuestas para el problema: la hipótesis.
4. Deducción de las consecuencias de las soluciones propuestas.
5. Verificación de las hipótesis mediante la acción

A pesar de que el método científico se lo dividió en cinco pasos se tiene un modelo del mismo, (ver figura 13) en el cual se puede observar más detalladamente todos los pasos.

El problema: Los problemas no se inventan, entonces ¿Cómo surgen? Se requiere un observador perspicaz que detecte una incongruencia entre lo observado con las teorías y modelos vigentes. [LAB, 2001]

En el presente trabajo de grado se ha detectó el problema general como también los problemas secundarios, los cuales se los ha expuesto en el Planteamiento del problema.

La hipótesis: "Es una tentativa de explicación o conjetura verosímil, que debe ser sometida a prueba por los hechos que pretende explicar".

Figura 13. Modelo Geométrico del Método Científico

Fuente: http://www.umce.cl/biblioteca/mie_modulo4.pdf

Las hipótesis pueden ser contrarias al sentido común, o bien estar de acuerdo con él, así como darse el caso de que sea correcta o incorrecta. De todos modos siempre debe conducir a pruebas empíricas. [LAB, 2001]

En el trabajo de grado se ha llegado a determinar la hipótesis que se pretende demostrar.

Las predicciones: Corresponden a hechos particulares que se deducen como consecuencias de cierta hipótesis. [LAB, 2001]

Las predicciones, estará referido a en que medida el sistema experto contribuirá al desarrollador de software en la documentación de los requerimientos de software reduciendo el tiempo y costos innecesarios, cooperará a la confirmación o negación de la hipótesis planteada.

El test o prueba: Es el procedimiento de observación o experimento necesario para comprobar la predicción respectiva. [LAB, 2001]

Las pruebas que se realizarán para comprobar las predicciones se las hará en el desarrollo de prototipos que serán probados por los desarrolladores de software disponibles, como también de los estudiantes de la Escuela Militar de Ingeniería.

Las evidencias: Corresponden a los resultados tangibles que quedan del test o prueba. [LAB, 2001]

Al realizar las pruebas se podrá tener información que evidencien las fortalezas y debilidades, la cual será utilizada para poder mejorar el sistema experto.

La nueva teoría: Cuando finalmente se acepta la validez de una hipótesis, ésta constituye la base de una nueva teoría que puede considerar nuevos modelos. [LAB, 2001]

En el caso de que la hipótesis sea válida se podrá desarrollar una nueva teoría respecto a como realizar la documentación de requerimientos de software, lo cual apoyará en el surgimiento de diversas aplicaciones, como sistemas expertos que ayuden al desarrollador de software en las diversas etapas de la construcción de software.

Nuevas observaciones: La aplicación de la nueva teoría a la realidad permite dar interpretaciones más ajustadas a los hechos que se van observando. Si algún observador agudo encuentra que ciertos hechos ya no encajan con la teoría o el modelo explicatorio y su interpretación no funciona para ellos, entonces tenemos una nueva situación problemática que habría que resolver. [LAB, 2001]

Al contar con trabajos de grado realizados anteriormente afines al objeto bajo estudio será de gran aporte para poder obtener información, la cual se filtrará obteniendo partes de estos trabajos que podrán ser relevantes para el presente trabajo.

Las aplicaciones prácticas: Invariablemente después de algún tiempo, van surgiendo productos y procesos tecnológicos a partir de los nuevos descubrimientos científicos. [LAB, 2001]

Al concluir este trabajo servirá como base para la investigación de nuevas aplicaciones como sistemas expertos que ayuden al desarrollador de software en las diversas etapas de la construcción de software.

10.1.2 MÉTODO INDUCTIVO

Es el razonamiento que, partiendo de casos particulares, se eleva a conocimientos generales. Este método permite la formación de hipótesis, investigación de leyes científicas, y las demostraciones. [LOP, 1984]

Este método se lo utilizó para la formación de la hipótesis.

10.1.3 MÉTODO HIPOTÉTICO

Un investigador propone una hipótesis como consecuencia del conjunto de datos empíricos, lo cual arriba a la hipótesis mediante procedimientos inductivos, y posteriormente realiza experimentos para poder rechazar o aceptar la hipótesis. [LOP, 1984] 

Se usará para poder llevar a cabo las pruebas del sistema experto que colaborará a rechazar o aceptar la hipótesis.

10.1.3 MÉTODO DE LA ABSTRACCIÓN

Es un proceso importantísimo para la comprensión del objeto, mediante ella se destaca la propiedad y relación de  las cosas y fenómenos. No se limita a destacar  y aislar alguna propiedad y relación del objeto asequible a los sentidos, sino que trata de descubrir el nexo esencial oculto e inasequible al conocimiento empírico. [OCH, 2002]

Mediante este método se pretende analizar y comprender el objeto bajo estudio para poder establecer los componentes y sus relaciones de esté.

10.2 TÉCNICAS

"La técnica es una forma particular para realizar o aplicar un método, normalmente una técnica está referida a los procedimientos que son empleados para la acumulación y manipulación de los datos". [YAÑ, 2001]

"Podría definirse como el conjunto de procedimientos y recursos de que se vale la ciencia para conseguir su fin. Sin embargo, el nivel del método o de los métodos no tienen nada en común con el de las técnicas, entendiéndose, las técnicas como procedimientos operativos rigurosos. Bien definidos, transmisibles y susceptibles de ser aplicados repetidas veces en las mismas condiciones". [GRA, 1996]

10.2.1 ENTREVISTAS Y CUESTIONARIOS

Las entrevistas y cuestionarios se emplearán para reunir información proveniente de los desarrolladores de software, información que se obtendrá conversando con el encuestado.

Para la realización de las entrevistas se debe coordinar previamente la fecha y hora, y realizar un plan de agenda, en el cual se hace un punteo del objetivo de la entrevista. Por ejemplo, en la primer entrevista estableceremos un plan de comunicación, en el cual se intercambiarán los teléfonos, celulares, direcciones de e-mail y horarios de contacto.

Para realizar las entrevistas, se llevará preparado un cuestionario. En términos generales, un cuestionario consiste en un conjunto de preguntas presentadas a una persona para su respuesta. La forma de la pregunta puede influir en las respuestas, por lo que hay que planearlas cuidadosamente. [KOM, 1993]

Las preguntas suelen distinguirse en dos categorías: abiertas y cerradas. Las preguntas abiertas permiten que los encuestados respondan con su propia terminología. Generalmente estas son más reveladoras, ya que los interrogados no están limitados en sus respuestas. [KOM, 1993]

10.2.2 ENCUESTAS

Son las que están basadas en muestrarios bien elaborados con el objeto de permitirnos llegar a conclusiones y sus fundamentaciones. [YAÑ, 2001]

Se utilizó la encuesta para poder recopilar datos específicos de los desarrolladores de software, que ayudó a identificar los problemas existentes que estan descritos en la sección del planteamiento del problema.

10.2.3 BRAINSTORMING (TORMENTA DE IDEAS)

Este es un modelo que se usará, en el desarrollo del sistema experto, para generar ideas. La intención de su aplicación es la de generar la máxima cantidad posible de ideas para el software.

No hay que detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas. Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro", "impracticable", "imposible", etc. [KOM, 1993]

Las reglas básicas a seguir son:

• Los participantes deben pertenecer a distintas disciplinas y, preferentemente, deben tener mucha experiencia. Esto trae aparejado la obtención de una cantidad mayor de ideas creativas.
• Conviene suspender el juicio crítico y se debe permitir la evolución de cada una de las ideas, porque sino se crea un ambiente hostil que no alienta la generación de ideas.
• Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar, porque luego de maduradas probablemente se tornen sumamente útil.
• A veces ocurre que una idea resulta en otra idea, y otras veces podemos relacionar varias ideas para generar una nueva.
• Escribir las ideas sin censura. [KOM, 1993]

11. TEMARIO TENTATIVO (ÍNDICE)

CARATULA

DEDICATORIA

AGRADECIMIENTOS

INDICE

RESUMEN

CAPITULO 1: GENERALIDADES

1. INTRODUCCION
2. ANTECEDENTES
3. PLANTEAMIENTO DEL PROBLEMA
4. OBJETIVOS
5. HIPOTESIS
6. JUSTIFICACION
7. ALCANCES Y APORTES

CAPITULO 2: MARCO TEÓRICO Y METODOLOGICO

2.1 MARCOS DE PROBLEMA

2.2 INGENIERÍA DE REQUERIMIENTOS

2.3 SISTEMAS EXPERTOS

2.4 METODOLOGIA DE WEISS Y KULIKOWSKI

2.5 LENGUAJE DE MODELADO UNIFICADO UML

CAPITULO 3: MARCO PRÁCTICO

3.1 RECOLECCION DE DATOS PARA EL DESARROLLO DEL PROYECTO

3.2 DISEÑO DEL SISTEMA EXPERTO

3.3 CONSTRUCCION DEL PROTOTIPO

3.4 VALIDACION Y PRUEBA

3.5 PRUEBA DE HIPOTESIS

CAPITULO 4: ESTUDIO DE COSTO – BENEFICIO

4.1. DETERMINACIÓN DE COSTOS

4.2. ESTIMACIÓN DE BENEFICIOS

4.3. ANÁLISIS COSTO BENEFICIO

CAPITULO 5: CONCLUSIONES Y RECOMENDACIONES

5.1 CONCLUSIONES

5.2 RECOMENDACIONES

BIBLIOGRAFIA

GLOSARIO

ANEXOS

12. COSTO DE REALIZACION DEL TRABAJO DE GRADO

Para llevar el Trabajo de Grado se estiman los siguientes costos:

Tabla 3. Costos del Trabajo de Grado

Fuente: Elaboración Propia

13. CRONOGRAMA DE ACTIVIDADES

Tabla 4. Cronograma de Actividades.

Fuente: Elaboración Propia.

GLOSARIO

REQUERIMIENTO: característica del sistema que es una condición para su aceptación.

INGENIERÍA DE SISTEMAS: Es la disciplina a la que se refiere a la planeación, diseño, evolución y construcción científica de sistemas hombre maquina y cuya característica son de ser complejos y conflictivos.

ANALISIS DE SISTEMAS: El análisis de sistemas esta orientado al estudio de o de los sistemas de una organización identificando aspectos de conflicto, a todo ello lo denominamos análisis, posteriormente realizaremos

INGENIERÍA DE SOFTWARE: Es la disciplina encargada del estudio del producto del software, tal estudio estas referido a la proporción de nuevos paradigmas técnicas y herramientas inmersas en la elaboración. Debemos mencionar que la ingeniería del software hace uso de otras disciplinas como la administración, estadística y probabilidad, las matemáticas, la psicología, etc

INGENIERÍA DE REQUERIMIENTOS: conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución

SISTEMA EXPERTO: Es un software que imita el comportamiento de un experto humano en la solución de un problema. Pueden almacenar conocimientos de expertos para un campo determinado y solucionar un problema mediante deducción lógica de conclusiones

PROTOTIPO: Es un modelo a escala, pero no tan funcional para que equivalga a un producto final, ya que no lleva a cabo la totalidad de las funciones necesarias del sistema final. Proporcionando una retroalimentación temprana por parte de los usuarios acerca del Sistema

MARCO DE PROBLEMA: Los marcos de problema caracterizan clases de problema que comúnmente ocurren como subproblemas de otros problemas más grandes y reales

BIBLIOGRAFÍA

[JAC, 1995] Jackson, Michael, Requerimientos de Software y Su Especificacion, Addison- Wesley, ACM Press, 1995.

[BRO, 1995] Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1995.

[CRI y KANG, 1992] M. G. Christel y K. C. Kang. Los Problemas en los Requerimientos y Elicitación. El Informe técnico CMU/SEI-92-TR-12, Software que Diseña el Instituto, Carnegie Mellon University, 1992. Disponible en http://www.sei.cmu.edu.

[HSI, 1993] P. Hsia, A. Davis, y D. Kung. Los estados Informan: La Ingeniería de requerimientos. El Software de IEEE, 10(6), Noviembre 1993.

[IEEE, 1993] [IEEE 1993] IEEE. IEEE La Práctica recomendada para las Especificaciones de Requerimientos de Software. IEEE/ANSI Standard 830–1993, El instituto de Eléctrico e Ingenieros de la Electrónica, 1993.

[POH, 1997] K. Pohl. La Ingeniería de requerimientos: Una Apreciación global. La enciclopedia de Informática y Tecnología, 36, 1997. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS/reports96.htm .

[POH 1994] K. Pohl. Las Tres Dimensiones de Ingeniería de Requerimientos: Un Armazón y su Aplicación. Los Sistemas de información, 3(19), Junio 1994.

[BOE, 1994] B. W. Boehm, P. Bose, E. Horowitz, y M.-J. Lee. Software Requirements as Negotiated Win Conditions. En Los procedimientos de la Primera Conferencia Internacional en la Ingeniería de Requerimientos, 1994. Disponible en http://sunset.usc.edu/TechRpts/Papers/NGPMRequirements93.

[DAV, 1993] A. M. Davis. Remontando: Una Necesidad Simple Descuidó. IEEE Software, 12(5), Septiembre 1995.

[BRA, 1990] J. W. Brackett. Los Requerimientos del software. El Módulo del plan de estudios SEI-CENTÍMETRO-19-1.2, Software que Diseña el Instituto, Carnegie Mellon University, 1990. Disponible en http://www.sei.cmu.edu.

[DOD, 1994] DOD. La Norma Militar 498: El Desarrollo del Software y Documentación. Departamento de Defensa de los Estados Unidos de América, 1994. Disponible en http://www-library.itsi.disa/mil/mil std/498 win3.exe.

[CAT, 1999] Sistemas Expertos y Modelos de Redes Probabilísticas Enrique Castillo, José Manuel Gutiérrez, y Ah S. Hadi.

[GOG, 1994] J. A. Goguen y C. Linde. Las técnicas para los Requerimientos Elicitación. Los Procedimientos del Primer Simposio Internacional en el Diseño de Requerimientos 1993. También aparece en [Thayer y Dorfman 1997]. Disponible en http://www.cse.ucsd.edu/˜goguen.

[MAP, 1995] MAP. Metodología de Planificación y Desarrollo de Sistemas de Información. MÉTRICA Versión 2.1. Tecnos/Ministerio para las Administraciones Públicas, 1995.

[BAS, 1998] L. Bass, P. Clements, y R. Kazman. Nonfunctional Requirements Is a Dysfunctional Term. En Software Architecture in Practice, Addison–Wesley, 1998.

[ROM, 1990] H. D. Rombach. Software Specifications: A Framework. Curriculum Module SEI–CM–11–2.1, Software Engineering Institute, Carnegie Mellon University, 1990. No está disponible en http://www.sei.cmu.edu, aunque aparece en [Dorfman y Thayer 1990].

[MAZ, 1994] C. Mazza, J. Fairclough, B. Melton, D. de Pablo, A. Scheffer, y R. Stevens. "Standards de Ingeniería de Software". Prentice–Hall, 1994. Disponible en http://dxsting.cern.ch/sting/ESA.txt.

[LAB, 2001] Labarca. "METODOLOGÍA DE LA INVESTIGACIÓN". 2001

[YAÑ, 2001] Yañez Romero Fernando, "APUNTES DE METODOLOGÍA DE LA INVESTIGACIÓN", 2001

[SAM, 1996] Roberto Hernández Sampieri, Carlos Fernández Collado , "METODOLOGÍA DE LA INVESTIGACIÓN", Mc Graw Hill, Colombia 1996.

[GRAW, 1996] Grawitz, Madeleine. "METODOS Y TECNICA DE LAS CIENCIAS SOCIELES" Ed. Edita Mexicana S.A., México, 1996. www.entrebits.com

[MED, 2004] Medina Miranda Freddy, "SISTEMAS EXPERTOS Y REDES NEURONALES" Apuntes de clases, 2004

[CAS, 2002] Castro Marcel (2002). "SISTEMAS EXPERTOS". Consultado en http://strix.ciens.ucv.ve/~iartific/Material/PP_Sistemas_Expertos.pdf

[LOP, 1984] López Cano José Luis, "MÉTODOS E HIPÓTESIS CIENTÍFICAS", México, 1984

[KOM, 1993] Komer, P., "DIRECCION DE LA MERCADOTENIA". Séptima Edición. España. Prentice Hall.

[WEI, 1984] Weiss y Kulikowski, "SISTEMAS EXPERTOS", Prentice–Hall, 1984.

[GAO, 1979] Oficina de Cuentas del Gobierno Norteamericano (Government Account Office), "ESTUDIO GAO", 1979.

[TSG, 1995] Grupo Standish, "ESTUDIO CHAOS", 1995.

[ESP, 1996] European Software Process Improvement Training Initiative, "ESTUDIO ESPITI", 1996.

[BOOCH, 1996] Benjamin Cummings. "Análisis y Diseño Orientado a Objetos", 1996.

[RUM, 1996] Rumbaugh James, "Modelado y Diseño Orientado a Objetos", 1996

ANEXO A

ARBOL DE PROBLEMAS

Figura 14. Árbol de Problemas.

Fuente: Elaboración Propia.

ANEXO B

ARBOL DE OBJETIVOS

Figura 15. Árbol de Objetivos.

Fuente: Elaboración Propia.

Autor

Nelson Huanca Pinto

La Paz Bolivia