Sistema experto basado en reglas para la documentación de requerimientos de Software
- Trabajos
realizados - Descripción del objeto
bajo estudio - Planteamiento del
problema - Objetivos
- Hipótesis
- Justificación
- Alcances y
aportes - Marco teórico y
metodológico - Métodos
y técnicas - Temario
tentativo (índice) - Costo
de realización del trabajo de grado - Cronograma de
actividades - Glosario
- Bibliografía
- Anexos
Desarrollar un software significa
construirlo simplemente mediante su descripción. Está es una muy buena
razón para considerar la actividad de desarrollo de
software como una ingeniería. En un nivel más general,
la relación existente entre un software y su entorno es
clara ya que el software es introducido en el mundo de modo de
provocar ciertos efectos en el mismo.
Aquellas partes del mundo que afectarán al
software y que serán afectadas por él será
el Dominio de
Aplicación. Es allí donde los usuarios y/o clientes
observarán si el desarrollo del software ha cumplido su
propósito. [BRO, 1995]
Una de las mayores deficiencias en la práctica de
construcción de software es la poca
atención que se presta a la
discusión del problema. En general los desarrolladores se
centran en la solución dejando el problema inexplorado. El
problema a resolver debe ser deducido a partir de su
solución.
Esta aproximación orientada a la solución
puede funcionar en campos donde todos los problemas son
bien conocidos, clasificados e investigados, donde la innovación se ve en la detección de
nuevas soluciones a
viejos problemas.
Pero el desarrollo de software no es un campo con tales
características. La versatilidad de las computadoras y
su rápida evolución hace que exista un repertorio de
problemas en constante cambio y cuya
solución software sea de enorme importancia.
Para poder
clasificar los problemas y relacionarlos surge una idea crucial
llamada Marcos de Problema. Un marco de problema define una
clase de
problema, mediante la provisión de una estructura
definida de partes principales en la cuales todos los problemas
de dicha clase deben coincidir.
Los marcos de problema caracterizan clases de problema
que comúnmente ocurren como subproblemas de problemas
reales. [JAC, 1995]
Que un problema particular encaje en un marco particular
depende de la estructura y características del dominio de
la aplicación y la estructura y características de
los requerimientos.
De acuerdo a estudios realizados1 se
observó que los proyectos2 han fallado porque
sus requerimientos no tuvieron una correcta3
descripción y fueron inadecuadamente4
explorados lo cual derivó al incremento de tiempos y
costos iniciales
del proyecto. Los
requerimientos se ubican en el dominio de la
aplicación donde está el problema. Se debe
definir el problema mediante una precisa y explícita
descripción.
El propósito del presente trabajo es
desarrollar un sistema experto
para la documentación de los requerimientos de software
contribuyendo así al desarrollador de software
disminuyendo el tiempo y
costos.
Y su importancia radica en el apoyo a la toma de
decisiones que brindará al desarrollador de software,
en un problema particular, en la etapa de documentación de
los requerimientos de software.
software tanto nacionales como internacionales,
además del porque de la selección
del tema, interés de
la carrera, interés de la universidad,
interés de la sociedad e
interés de la región.
2. ANTECEDENTES
La sección de antecedentes incluye información sobre trabajos afines de los
requerimientos de
De acuerdo a la investigación bibliografíca, en la
carrera de Informática, de la UMSA, Juan Carlos
Miranda Aranibar, elaboró la tesis
"Modelo de
Estimación de Costos para Desarrollo de
Software".
El objetivo de la
tesis era derivar un modelo de costeo a partir del COCOMO
(COnstructive COst MOdel), extrapolando los datos obtenidos
de empresas,
considerando el ambiente
actual de trabajo en los centros de
cómputo, el cual solamente está referido a los
costos y deja de lado a los requerimientos de
software.
Otra tesis de la carrera de Informática de la
UMSA es la de "Interfaz para la especificación de
requerimientos del usuario", presentada por Lidia Callata Villca,
en 1999.
El propósito de esta tesis era proporcionar una
herramienta que permita la especificación de
requerimientos del usuario. La propuesta solo se refiere a una
interfaz para especificar algunos requerimientos
específicos del usuario y no es general para los
requerimientos del sistema software.
En la misma carrera de la UMSA, Miriam Rojas
Siñani, en el año 1997, presentó la tesis
"Especificación formal de la documentación de
software".
El objetivo de esta tesis era formalizar la
documentación de software. Sin embargo, se refiere a la
documentación del desarrollo y construcción, pero
no de los requerimientos.
En la carrera de Ingeniería
de Sistemas de la Escuela Militar
de Ingeniería se desarrollo el trabajo de
Mery Ana Nevenka Monje Ascarrunz con el nombre de "Mesa de Ayuda
para Requerimientos de Hardware y Software Caso:
Instituto Nacional de Estadística".
El objetivo era proporcionar una mesa de ayuda para
requerimientos de hardware y software para el Instituto Nacional
de Estadística que contribuye a mejorar y controlar la
atención a usuarios de equipos de computación. El trabajo se refiere a una
institución en particular, y no es genérico para
las distintas organizaciones e
instituciones
existentes en la sociedad.
A nivel internacional, en Internet, se encontró
una referencia muy importante, la de Amador Durán Toro que
lleva el nombre de "Un Entorno Metodológico de
Ingeniería de Requerimientos para Sistemas de
Software".
Este trabajo tiene como objetivo el de proporcionar una
metodología de requerimientos para los
sistemas de
información.
También se encontró el trabajo de
Nicolás Davyt Dávila con el nombre de
"Ingeniería de Requerimientos: Una Guía Para
Extraer, Analizar, Especificar y Validar los Requerimientos de un
Proyecto".
El objetivo de este artículo, es que pueda ser
utilizado como guía para determinar, analizar y
especificar los requerimientos de un proyecto en el cual el
dominio de aplicación es totalmente desconocido y no es
estructurado.
La diferencia que tiene el presente trabajo con los
citados anteriormente es que ninguno ofrece una herramienta que
aporte al desarrollador de software en la disminución de
tiempo y costos empleado para la documentación de los
requerimientos de software, mediante la ingeniería de
conocimientos para el desarrollo de un sistema
experto.
2.2 SELECCIÓN DEL TEMA
Al estudiar la materia de
Ingeniería
de Software se observó que en la actualidad, los
requerimientos de software tienen insuficiente importancia
contando con pocas herramientas
de soporte tecnológico, lo cual causa un efecto en la
institución u organización provocando demora de tiempo y
costos que podrían haberse evitado elaborando una correcta
documentación de los requerimientos de software, es de
ahí que nace de la inquietud de poder ofrecer un sistema
experto que apoye a realizar una correcta documentación de
requerimientos de software.
2.3 INTERÉS DE LA CARRERA
Se considera que el tema es de interés debido a
que la carrera de Ingeniería de Sistemas, de la EMI,
cuenta con escasas herramientas de soporte tecnológico que
puedan apoyar el aprendizaje de
los estudiantes de cursos inferiores en las materias relacionadas
con el presente trabajo, como los de:
- Análisis y Programación de Sistemas.
- Ingeniería de Software.
- Ingeniería del Conocimiento.
- Sistemas Expertos y Redes
Neuronales.
2.4 INTERES DE LA UNIVERSIDAD
El interés de la Escuela Militar de
Ingeniería, es poder disponer de una herramienta de
soporte tecnológico que pueda ayudar al departamento de
informática en la documentación de requerimientos
de software.
2.5 INTERÉS DE LA SOCIEDAD
Los desarrolladores de software podrán utilizar
el sistema experto como un apoyo para la documentación de
requerimientos de software para brindar mejores productos para
las organizaciones e instituciones.
2.6 INTERÉS DE LA REGION
Las consultoras de software, existentes en nuestro
medio, tendrán la posibilidad de obtener la herramienta
para que sus desarrolladores puedan realizar la
documentación de requerimientos de software, lo que
coadyuvará a mejores servicios en
las diversas instituciones y organizaciones de la región
al contar con un software que evite la demora de tiempo y costos
innecesarios contribuyendo así al desarrollo del la
Nación.
3. DESCRIPCIÓN
DEL OBJETO BAJO ESTUDIO
A principios de los
años 50 en algún organismo del gobierno de los
Estados Unidos
se podía encontrar una sala de un centro de cálculo.
La estancia estaba ocupada por un enorme ordenador cuyo
desarrollo había costado varios millones de dólares
y cuyo mantenimiento
tenia ocupadas a varias personas las 24 horas del
día.
La siguiente media hora era el turno semanal de uno de
los muchos científicos que trabajaba para el Departamento
de Defensa. Su trabajo consistía en calcular tablas
numéricas para trayectorias balísticas usando
ecuaciones
relativamente complejas. Llevaba toda la semana repasando su
programa en su
despacho para asegurarse que no contenga errores
sintácticos ni semánticos, ya que un fallo en la
compilación podría hacerle perder su preciosa media
hora semanal.
Cuando comienza su tiempo, el ordenador comienza a leer
las tarjetas
perforadas que previamente había entregado al operador,
compila el programa sin errores y comienza su ejecución.
El científico se dispone a esperar a que la impresora
comience a imprimir las tablas. Cuando faltan sólo pocas
líneas para completarlas, el hardware falla y los
encargados de mantenimiento deben parar la máquina para
repararla. Quizás la semana que viene tenga más
suerte.
Si se compara esta situación con la actual, pocos
son los aspectos comunes que se encuentran. Sin embargo, se
podría hacer un ejercicio de análisis e identificar algunas de las
características del desarrollo de software en los
comienzos de la informática.
- El hardware era mucho más caro que el
software. La máquina y su mantenimiento costaban
millones de dólares. Comparado con este costo, el
sueldo del científico que escribe el programa era
ridículo, así que ¿por qué
preocuparse por el costo del desarrollo de
software? - El desarrollo del hardware era más
complejo que el del software. La tecnología hacia que el hardware sea
complejo de construir y mantener. El software habitual
solía ser programas no
muy grandes (debido, entre otras limitaciones, a la escasa
capacidad de memoria) y
estaban escritos por una única persona,
normalmente empleada en la
organización que utiliza el hardware. Los
requerimientos que tenia que cumplir el software eran simples.
Por lo tanto, ¿por qué preocuparse por la
complejidad del software? - El hardware era poco fiable. Debido a
la tecnología que se utilizaba para su
implementación, en cualquier momento la máquina
podía sufrir una avería, así que
¿para qué preocuparse por la calidad del
software?
Esta despreocupada situación respecto al software
cambia cuando, gracias a los avances en la tecnología,
aumenta la capacidad de memoria y se reducen los costos de
desarrollo y mantenimiento del hardware.
Se empiezan a comercializar los primeros ordenadores y
la demanda de
software más complejo crece rápidamente, generando
la crisis del software, término utilizado por
primera vez en la conferencia
organizada por la Comisión de Ciencia de la
OTAN en Garmisch, Alemania, en
octubre de 1968, para designar la gran cantidad de problemas que
presentaba, y aún presenta, el desarrollo de software y el
alto índice de fracasos en los proyectos de
desarrollo.
¿Qué podía hacerse ante una
situación en la que los proyectos software tenían
un alto riesgo de
fracasar? La respuesta parecía obvia: construir software
de forma similar a como se construye hardware, aviones, barcos,
puentes o edificios, es decir, aplicar los métodos de
la ingeniería a la construcción de
software.
Desde 1968 se ha invertido un gran esfuerzo en
determinar las causas y proponer soluciones para la crisis del
software.
En 1979, la Oficina de
Cuentas del
Gobierno Norteamericano (Government Account Office, GAO)
realizó un estudio [GAO, 1979] seleccionando nueve
proyectos de desarrollo de software para el gobierno
norteamericano cuyos contratos sumaban
una cantidad total de 6.800.000 dólares.
De esta cantidad, sólo 119.000 dólares
correspondían a un proyecto que se había utilizado
tal como se había entregado. Dicho proyecto se trataba de
un preprocesador de COBOL, por lo
que era un problema relativamente simple cuyos requerimientos
eran comprendidos por clientes y desarrolladores y que
además no cambiaron durante el desarrollo.
El resto de los 6.8 millones de dólares se
distribuyeron como puede verse en la figura 1, en la que puede
destacarse el enorme porcentaje de dinero
invertido en proyectos cancelados o no satisfactorios.
En 1995, el Grupo Standish
realizó un estudio, el informe CHAOS,
mucho más amplio y significativo que el del GAO cuyos
resultados, a pesar de haber pasado más de 25 años,
no reflejaban una mejoría sustancial [TSG,
1995].
Los resultados generales, que pueden verse en la figura
2, si se compara con los de [GAO, 1979] presentan una mejora en
los proyectos que se entregan cumpliendo todos sus
requerimientos, 2% frente al 16.2%, sólo el 9% en grandes
compañías, pero empeoran ligeramente respecto a los
que se abandonan durante el desarrollo, 28.7% frente a
31.1%.
Figura 1. Resultados del Informe de
GAO.
Fuente: Government Account Office, GAO [GAO,
1979].
Sin incluir al 16.2% de los proyectos terminados
correctamente, la media del gasto final fue del 189% del
presupuesto
original, el tiempo necesario para su realización del 222%
del plazo original y se cumplieron una media del 61% de los
requerimientos iniciales, cifras que también
empeoraban en el caso de grandes
compañías.
Las encuestas
realizadas a los directores de los proyectos que participaron en
el estudio indicaron que, en su opinión, los tres
principales factores de éxito
eran:
- Implicación de los usuarios
- Apoyo de los directivos
- Enunciado claro de los requerimientos
Mientras que los tres principales factores de fracaso
eran:
- Falta de información por parte de los
usuarios - Especificaciones y requerimientos
incompletos - Especificaciones y requerimientos
cambiantes
Figura 2. Resultados del informe
CHAOS.
Fuente: Grupo Standish [TSG
1995].
En 1996, el proyecto ESPITI (European Software
Process Improvement Training Initiative) [ESP, 1996]
realizó una investigación sobre los principales
problemas en el desarrollo de software a nivel europeo. Los
resultados, muy similares a los obtenidos en el informe CHAOS,
indicaron que los mayores problemas estaban también
relacionados con la especificación, la gestión
y la documentación de los requerimientos de
software.
Estos informes ponen
de manifiesto el hecho de que, a pesar de que las herramientas
para construir software han evolucionado enormemente, se sigue
produciendo software que no es satisfactorio para los clientes y
usuarios. Esto indica que los principales problemas que han dado
origen a la crisis del software residen en las primeras etapas
del desarrollo, cuando hay que decidir las características
del producto
software a desarrollar.
Otros hechos comprobados es la demora de tiempo y el
costo de un cambio en los requerimientos, una vez entregado el
producto, es entre 60 y 100 veces superior al que hubiera
representado el mismo cambio durante las fases iniciales de
desarrollo [DAV, 1993], por lo que no es de extrañar que
aquellos proyectos en los que no se determinan correctamente los
requerimientos y cambian frecuentemente durante el desarrollo,
superen con creces el tiempo y presupuesto inicial.
Todas estas circunstancias han convencido a la gran
parte de la comunidad de la
ingeniería del software de la necesidad, cada vez mayor,
de una ingeniería de requerimientos.
"La parte más difícil en la
construcción de sistemas software es decidir precisamente
¿qué construir? Ninguna otra parte del trabajo
conceptual es tan dificultosa como establecer los requerimientos
técnicos, incluyendo todas las interfaces con humanos,
máquinas y otros sistemas software. Ninguna
otra parte del trabajo puede perjudicar tanto el resultado final
si es realizada en forma errónea. Ninguna otra parte es
tan dificultosa de rectificar posteriormente". [BRO,
1995]
La documentación de requerimientos es una de las
más importantes partes del proceso de
desarrollo de software, pero es, a la vez, una de las que
cuenta con pocas herramientas de soporte tecnológico en
la actualidad, aumentando el tiempo y costos del proyecto. A
su vez es una etapa donde inevitablemente existe
contradicciones y ambigüedad que atentan contra el correcto
comienzo de la vida del software. [BRO, 1995]
Las causas primarias de realizar una incorrecta
conceptualización del problema es cuando el desarrollador
de software tiene situaciones en que es escaso el
conocimiento acerca del dominio de aplicación y el
dominio de aplicación, donde se implantará el
software, puede ser complejo.
Analizando las diferentes causas que dan lugar a un
software desarrollado insatisfactoriamente, se observó los
siguientes aspectos negativos:
- Pocas herramientas de soporte tecnológico,
para realizar la documentación de requerimientos de
software aumentando el tiempo y costos iniciales del
proyecto. - En la etapa de adquisición de requerimientos
frecuentemente existe contradicciones y ambigüedad que
atentan contra el correcto comienzo de la vida del
software. - Existe situaciones en que es escaso el conocimiento
sobre el dominio de aplicación. - El dominio de aplicación, donde se
desarrollará el software, puede ser
complejo.
En base a la problemática descrita anteriormente,
mediante un análisis causal de los requerimientos de
software y con la construcción del árbol de
problemas (ver anexo A) se concretó el problema general y
los problemas secundarios, a ser tratados por el
presente proyecto.
4.1 PROBLEMA GENERAL
El desarrollador de software, cuenta con pocas
herramientas de soporte tecnológico, lo que da lugar a
demora en tiempo e incremento de costos al elaborar la
documentación de requerimientos de software.
4.2 PROBLEMAS SECUNDARIOS
Los problemas secundarios identificados, se detallan a
continuación:
- En la etapa de la documentación de
requerimientos de software, frecuentemente existe
contradicciones y ambigüedad, que atentan contra el
correcto comienzo de la vida del software. - Existe situaciones en que es escaso el conocimiento
sobre el dominio de aplicación. - El dominio de aplicación, donde se
desarrollará el software, en algunos casos, puede
llegar a ser complejo.
En base a los problemas planteados anteriormente se
elaboró un listado de objetivos y se
realizó un análisis de medios y
fines, concluyendo con el árbol de objetivos, a partir del
cual se plantearon los siguientes objetivos (ver anexo B), a ser
tratados por el presente proyecto.
5.1 OBJETIVO GENERAL
Se pretende cumplir con el siguiente objetivo
general:
Desarrollar un sistema experto, basado en reglas,
que coadyuve al desarrollador de software reduciendo el tiempo y
costos en la documentación de requerimientos de
software5.
5.2 OBJETIVOS SECUNDARIOS
Los objetivos secundarios identificados se detallan a
continuación:
- Adquirir los conocimientos de los expertos en
desarrollo de software para tener una concordancia y clara
obtención de los requerimientos de software que
coadyuven al correcto comienzo de la vida del
software. - Contribuir a incrementar el conocimiento sobre el
dominio de aplicación en el que actúa un
software1. - Descomponer un dominio de aplicación
complejo, para permitir solucionarlos por
módulos.
"El sistema experto propuesto coadyuva al
desarrollador de software reduciendo el tiempo y costos en la
documentación de los requerimientos de
software".
6.1 OPERACIONALIZACIÓN DE
VARIABLES
6.1.1 VARIABLES
6.1.1.1 VARIABLE INDEPENDIENTE
X: Sistema experto propuesto.
6.1.1.2 VARIABLE DEPENDIENTE
Y: Reducción de tiempo y costos en la
documentación de los requerimientos de
software.
6.1.1.3 VARIABLE INTERVINIENTE
Z: Desarrollador de software
6.1.2 ESQUEMA DE RELACION CAUSAL DE LAS
VARIABLES
Figura 3. Esquema de Relación
Causal de las Variables
Fuente: Elaboración
Propia
6.1.3 DEFINICIÓN CONCEPTUAL Y OPERACIONAL DE
VARIABLES
Tabla 1: Definición Conceptual y
Operacional de Variables.
VARIABLE | X: Sistema Experto | Y: Reducción de tiempo y costo en la | Z: Desarrollador de software |
DEFINICIÓN CONCEPTUAL | Sistema basado en la | Identificación detallada de la realizar determinadas tareas o | Encargado del desarrollo de un producto de |
DEFINICIÓN OPERACIONAL | Es el elemento contenedor de toda la Se empleará las normas | Producto resultante del sistema experto. | La Adquisición de conocimientos se |
Fuente: Elaboración
Propia
7.1 JUSTIFICACION TÉCNICA
El presente proyecto se justifica técnicamente
porque proporciona una herramienta de apoyo al documentar los
requerimientos de software constituyéndose en una
importante ayuda para los desarrolladores de software. Esta
herramienta tendrá la posibilidad de almacenar gran
cantidad de información (antecedentes de los proyectos de
las consultoras de software) y realizar un gran numero de
operaciones
(es decir, tomar dediciones para la documentación de
requerimientos de software) en poco tiempo de manera que se
obtenga conclusiones rápidamente.
7.2 JUSTIFICACION ECONÓMICA
El presente proyecto se justifica económicamente
porque coadyuvará al desarrollador de software a reducir
el tiempo al elaborar la documentación de requerimientos
de software evitando realizar, en algunos casos, volver a
especificar los requerimientos de software, todo esto
influirá en una reducción de costos del desarrollo
del software.
7.3 JUSTIFICACION SOCIAL
El presente proyecto se justifica socialmente porque
ayudará a la comunidad informática (desarrolladores
de software) a elaborar una documentación de
requerimientos de software oportuna y confiable. A la vez el
proyecto propuesto beneficiará indirectamente a los
clientes y/o usuarios del software, que se desarrollará
con apoyo del sistema experto.
8.1 ALCANCES
El trabajo se encuentra restringido a software de
aplicación desarrollado por consultores, para
aplicaciones específicas (mayormente empresariales) en
organizaciones del medio ya que generalmente se desarrolla este
tipo de software frecuentemente en las consultoras que se cuenta
como apoyo para el desarrollo del presente trabajo.
8.1.1 ÁMBITO TEMPORAL
El desarrollo del software se realizará en un
tiempo de siete meses, aproximadamente, realizando en este tiempo
los prototipos y pruebas en las
consultoras como también en los laboratorios de la Escuela
Militar de Ingeniería.
8.1.2 AMBITO GEOGRAFICO
Abarcará la ciudad de La Paz, al contar con datos
estadísticos de proyectos desarrollados por las
consultoras de software y al mismo tiempo trabajar con expertos
en desarrollo de software de estas consultoras, la mayoría
residentes de la ciudad de La Paz. Pero solo es una limitante por
los datos con los cuales se trabajará lo cual no significa
que no sirva para otra región en especifico.
8.1.3 AMBITO TEMÁTICO
8.1.3.1 INTELIGENCIA
ARTIFICIAL
La Inteligencia
Artificial incluye varios campos de desarrollo6,
pero el presente trabajo se restringe al campo de desarrollo de
sistemas
expertos.
8.1.3.2 SISTEMAS EXPERTOS
En el campo de desarrollo de sistemas expertos se puede
clasificar según el tipo de conocimiento los cuales son
basados en probabilidades y basado en reglas.
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.
8.1.3.3 MARCOS DE PROBLEMA
El sistema abordará el análisis del
problema mediante el uso de marcos de problema para poder guiar
al usuario en la información que necesita obtener para
poder describir el dominio de aplicación.
8.1.3.4 AREA GENERAL: INGENIERIA DE
SOFTWARE
La Ingeniería de Software es la disciplina
encargada del desarrollo de un producto de software a bajo costo
y alto rendimiento. Resulta indispensable tomar en cuenta de que
la piedra fundamental para el desarrollo de software es la
identificación de requerimientos la cual se constituye
como una disciplina la que es ingeniería de
requerimientos, por lo tanto la parte de la Ingeniería de
Software a utilizar alcanza a la parte de Ingeniería de
Requerimientos.
8.1.3.5 AREA ESPECÍFICA: INGENIERIA DE
REQUERIMIENTOS
La Ingeniería de Requerimientos se divide en tres
etapas: elicitación, análisis y validación
de requerimientos. Las cuales se emplearán para el
desarrollo del sistema experto.
8.2 APORTES
8.2.1 APORTE PROFESIONAL
No es frecuente encontrar expertos en requerimientos de
software en el medio. Se requieren personas que hayan trabajado
en una gran cantidad de proyectos software.
Por este motivo, se opto por desarrollar un sistema
experto que podrá reflejar los conocimientos de los
expertos en este campo y así aportar a los desarrolladores
de software despejando las dudas y dificultades en la
elaboración del documento de requerimientos de software
sin escatimar tiempo y costos.
8.2.2 APORTE ACADEMICO
Se podrá aportar una herramienta de soporte
tecnológico a los estudiantes, de la Escuela Militar de
Ingeniería, que desarrollen software, apoyándolos
en la documentación de requerimientos de
software.
9. MARCO TEORICO Y
METODOLOGICO
9.1 MARCOS DE PROBLEMA
Los marcos de problema caracterizan clases de problema
que comúnmente ocurren como subproblemas de otros
problemas más grandes. La idea es analizar los problemas
reales descomponiéndolos en subproblemas que correspondan
a marcos de problemas conocidos.
Cada marco es una elaboración de la forma general
del problema software, y puede ser elemental o compuesto. [JAC,
1995]
Un problema perteneciente a una clase caracterizada por
un marco elemental será capturado mediante la
construcción de descripciones apropiadas al marco. Un
problema de una clase compuesta será primero descompuesto
en subproblemas caracterizados por marcos elementales. [JAC,
1995]
Si se restringe el repertorio de marcos de problema a
los del tipo elemental, sería necesario descomponer cada
problema real en una estructura de subproblemas, cada uno lo
suficientemente pequeño y simple de modo que se ajuste a
los marcos elementales. Se estaría desaprovechando la
oportunidad de construir un repositorio de experiencia sobre los
problemas y su solución. Es por esto que el sistema
experto también proveerá los mecanismos para
administrar un repositorio de marcos compuestos correspondientes
a problemas resueltos.
El uso de marcos de problema otorga dos ventajas
importantes. La primera es que si se posee un nutrido repertorio
de clases de subproblemas conocidos en los cuales se puedan
descomponer los problemas realistas, se obtendrá un
proceso de descomposición guiado por una
clasificación de problemas muy sistemática, esto
redunda en excelentes resultados. [JAC, 1995]
La segunda ventaja es que un marco de problema es
asociado siempre con uno o más métodos para
capturar el problema en detalle y desarrollar su solución.
[JAC, 1995]
Los marcos de problema se emplearán, en el
sistema experto, para guiar la descomposición, dará
consejo y alertará sobre las dificultades que pueden
ocurrir y proveerá el contexto en el que la experiencia
previa capturada en el mismo pueda ser explotada efectivamente.
Una vez analizado el problema dará guías para
describir tanto el dominio de la aplicación como los
requerimientos según la descomposición realizada
con sus marcos de problema asociados.
9.1.1 DIAGRAMAS DE
MARCOS
Se introduce aquí una simple notación
gráfica para describir las partes principales de un
problema software, como puede observarse en la figura
4.
En un marco, cada dominio es representado por un
rectángulo, y los fenómenos compartidos por dos
dominios se representan por una línea que conecta los dos
rectángulos. La máquina a ser programada se
representa por un rectángulo sombreado. La palabra
utilizada dentro de dicho rectángulo representa el tipo de
máquina en la que se convierte la computadora
como resultado de la programación.
Los requerimientos se simbolizan mediante un
óvalo, con una o mas líneas conectándolos a
dominios a los cuales ellos pertenecen.
La manera de leer un diagrama de
marcos involucra dos pasos. Primero se debe leer el óvalo
y detectar con cuáles dominios está relacionado.
Estos son los principales dominios de interés. El segundo
paso es encontrar el dominio de la máquina y ver
cómo, directa o indirectamente, se conecta a los dominios
de interés. Es decir, se traza un camino entre la
máquina y los dominios de interés.
Debe notarse que el diagrama no intenta mostrar en gran
profundidad todos los aspectos del problema. Solo provee una
rápida y gráfica manera de mostrar los principales
elementos del problema para ayudar a planificar una forma
sistemática de documentarlo.
Figura 4. Elementos de Diagramas de
Marcos de Problema.
Fuente: Jackson, Michael, Software
Requirement & Specification, Addison- Wesley, ACM Press,
1995. [JAC, 1995]
9.1.2 MARCOS DE PROBLEMA ELEMENTALES
Se presentan aquí cinco marcos de problema que
corresponde a cinco tipos de requerimientos:
Tabla 2. Tipo de Marcos de
Problema.
Tipo de Requerimiento | Descripción | Marcos de Problema |
Consultas | Requerimiento de información sobre alguna parte del dominio del problema | Información |
Reglas de comportamiento | Reglas que debe seguir el comportamiento del dominio del | Control |
Mapeos | Mapeos sobre datos de entrada y de salida del | Transformación |
Operaciones sobre dominios creados | Operaciones que realizan los usuarios sobre | Workpieces |
Correspondencias entre dominios | Mantenimiento de dominios que no poseen correspondientes. | Conexión |
Fuente: Jackson, Michael, Software
Requirement & Specification, Addison- Wesley, ACM Press,
1995. [JAC, 1995]
Para cada tipo de requerimiento existe un conjunto de
información del dominio del problema necesario para
describir una especificación que implemente el
requerimiento.
Estos marcos no constituyen una lista exhaustiva, solo
describen una clase específica de problema. Cuando se
detecta un problema que se ajusta a uno de los marcos, se conoce
cómo debe documentarse sistemáticamente el problema
de una manera que sea útil para el resto del
desarrollo.
Los problemas reales involucran distintos tipos de
requerimientos a la vez. Es el caso de los marcos
compuestos.
El propósito de enmarcar un problema no es
forzarlo a que se ajuste a alguna categoría existente, por
el contrario, es reconocer un problema familiar y a partir de
allí, comenzar el análisis de un problema no
familiar. [BRO, 1995]
9.2 INGENIERÍA DE
REQUERIMIENTOS
9.2.1 DEFINICION DE INGENIERÍA DE
REQUERIMIENTOS
En [CRI, 1992] y [KANG, 1992] la Ingeniería de
Requerimientos se define como:
Ingeniería de requerimientos (1):
Aplicación disciplinada de principios
científicos
y técnicas para desarrollar, comunicar y
gestionar requerimientos.
Ingeniería de requerimientos (2): El
proceso sistemático de desarrollar requerimientos mediante
un proceso iterativo y cooperativo de analizar el problema,
documentar las observaciones resultantes en varios formatos de
representación y comprobar la precisión del
conocimiento obtenido.
En [HSI, 1993] aparece la siguiente:
Ingeniería de requerimientos (3): Todas
las actividades relacionadas con:
(a) identificación y
documentación de las necesidades de clientes y
usuarios.
(b) creación de un documento que
describe la conducta externa
y las restricciones
asociadas (de un sistema) que satisfará dichas
necesidades.
(c) análisis y validación del
documento de requerimientos para asegurar consistencia,
compleción y viabilidad.
(d) evolución de las
necesidades.
En [IEEE, 1990] aparece la siguiente definición
de análisis de requerimientos que, tal como se
propone en [POH, 1997], puede interpretarse como otra
definición de ingeniería de
requerimientos:
Ingeniería de requerimientos
(4):
(a) el proceso de estudiar las
necesidades del usuario para llegar a una definición de
requerimientos de sistema, hardware o software.
(b) el proceso de estudiar y refinar los
requerimientos de sistema, hardware o software.
Por lo tanto, la Ingeniería de Requerimientos
puede considerarse como un proceso de descubrimiento y
comunicación de las necesidades de clientes y
usuarios y la gestión de los cambios en dichas
necesidades.
Página siguiente |