Monografias.com > Computación > General
Descargar Imprimir Comentar Ver trabajos relacionados

Sistema experto basado en reglas para la documentación de requerimientos de Software




Enviado por nelohp



Partes: 1, 2

    1. Trabajos
      realizados
    2. Descripción del objeto
      bajo estudio
    3. Planteamiento del
      problema
    4. Objetivos
    5. Hipótesis
    6. Justificación
    7. Alcances y
      aportes
    8. Marco teórico y
      metodológico
    9. Métodos
      y técnicas
    10. Temario
      tentativo (índice)
    11. Costo
      de realización del trabajo de grado
    12. Cronograma de
      actividades
    13. Glosario
    14. Bibliografía
    15. Anexos

    1.
    INTRODUCCIÓN

    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

    2.1 TRABAJOS
    REALIZADOS

    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:

    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:

    1. Implicación de los usuarios
    2. Apoyo de los directivos
    3. Enunciado claro de los requerimientos

    Mientras que los tres principales factores de fracaso
    eran:

    1. Falta de información por parte de los
      usuarios
    2. Especificaciones y requerimientos
      incompletos
    3. 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.

    4. PLANTEAMIENTO DEL
    PROBLEMA

    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.

    5.
    OBJETIVOS

    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.

    6.
    HIPOTESIS

    "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.
    JUSTIFICACION

    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. ALCANCES Y
    APORTES

    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.

    Partes: 1, 2

    Página siguiente 

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter