Sistema experto basado en reglas para la documentación de requerimientos de Software
Enviado por nelohp
- 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 documentación de requerimientos de software | Z: Desarrollador de software |
DEFINICIÓN CONCEPTUAL | Sistema basado en la computadora que es capaz de resolver problemas complejos en dominios específicos, mostrando un nivel de desempeño comparado con el de los expertos humanos | Identificación detallada de la información que se necesita para realizar determinadas tareas o funciones | Encargado del desarrollo de un producto de software a bajo costo y alto rendimiento. |
DEFINICIÓN OPERACIONAL | Es el elemento contenedor de toda la información útil en pos de la solución a la problemática. Se empleará las normas ISO 12119-1998: EVALUACION Y TEST DE PRODUCCION DE SOFTWARE, 9146-1991: CARACTERISTICAS DE CALIDAD DE UN PRODUCTO SOFTWARE. | Producto resultante del sistema experto. Contiene la descripción del dominio del problema y de los requerimientos. Se utilizará la norma de la IEEE-STD- 830-1998: ESPECIFICACIONES DE LOS REQUERIMINETOS DE SOFTWARE, y como métrica la METRICA 2.1: INGENIERIA DE REQUERIMIENTOS. | La Adquisición de conocimientos se comenzará con una serie de reuniones con los expertos, y posibles usuarios del Sistema Experto, se usará las técnicas citadas en el punto 10.2 |
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 problema | Control |
Mapeos | Mapeos sobre datos de entrada y de salida del software | Transformación |
Operaciones sobre dominios creados | Operaciones que realizan los usuarios sobre objetos que existen solo dentro del software | Workpieces |
Correspondencias entre dominios | Mantenimiento de dominios que no poseen fenómenos compartidos en sus estados 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 |