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