UN MODELO DE DIÁLOGO PARA LA EDUCCIÓN DE REQUISITOS DE SOFTWARE

A DIALOG MODEL FOR SOFTWARE REQUIREMENTS ELICITATION

 

CARLOS M. ZAPATA
Escuela de Sistemas. Facultad de Minas,Universidad Nacional de Colombia, sede Medellín, cmzapata@unal.edu.co

NICOLÁS CARMONA
Escuela de Sistemas. Facultad de Minas,Universidad Nacional de Colombia, sede Medellín

 

Recibido para revisar Enero 22 de 2008, aceptado Noviembre 3 de 2008, versión final Enero 8 de 2009

 

---

RESUMEN: La educción de requisitos es importante en el desarrollo de software pues, dependiendo de la calidad de este proceso, se pueden desarrollar mejores aplicaciones de software. En la educción de requisitos, las entrevistas suelen ser el método más utilizado y se consideran diálogos entre analistas e interesados. Los trabajos realizados al respecto, presentan limitaciones como la carencia de una estructura definida para las entrevistas analista-interesado, obligando al analista a realizar de manera subjetiva el proceso de educción. En este artículo, se presenta una propuesta de estructura para un modelo de diálogo encaminado a la educción de requisitos de software. Además, se presenta la manera de realizar las preguntas durante una entrevista del proceso de educción, por medio de un caso de estudio.

PALABRAS CLAVE: Modelo de diálogo, Actos de diálogo, Métodos para la educción de requisitos.

ABSTRACT: Software requirements elicitation is an important process in software development, due to the fact that better software applications depend on the quality of this process. Interviews—dialogue between analysts and stakeholders—are the most used methods in software requirements elicitation. Previous work on interviews for requirements elicitation has still constraints: there is no well-established structure for conducting analyst-stakeholder interviews, and the analyst must subjectively conduct the elicitation process. We present, in this paper, a proposal for the structure of a dialog model related to the software elicitation process. We also show, by means of a case study, the way of asking questions throughout an interview of the elicitation process.

KEY WORDS: Dialog model, dialog acts, requirements elicitation methods.

---

 

1. INTRODUCCIÓN

La educción de requisitos, es una técnica para la recolección, procesamiento y especificación de los requisitos de los interesados en el desarrollo de una aplicación de software [1]. La especificación de los requisitos, se realiza con diferentes diagramas, tales como: casos de uso, diagramas de procesos, clases, máquinas de estado, etc. De esta manera, se busca información relevante que se adapte a las necesidades y expectativas de los interesados.

El proceso de educción de requisitos puede resultar complejo, principalmente si el entorno de trabajo es desconocido para el analista, pues en este caso el resultado depende mucho de las personas que participen en el proceso. Debido a lo anterior, la ingeniería de requisitos trabaja desde hace años en el desarrollo de técnicas que permitan hacer este proceso de una forma más eficiente y precisa. Algunas de estás técnicas son: entrevistas individuales, JAD (Joint Application Development), tormenta de ideas, Concept Mapping, Sketches y Storyboards, Cuestionarios y Check List, etc. [2] y [3].

En la educción de requisitos, las entrevistas constituyen una de las técnicas de recopilación de información más utilizadas y, de hecho, sirven de base para las diferentes técnicas mencionadas, pues representan una forma de comunicación natural entre las personas [2].

Aunque las entrevistas se han consolidado como uno de los procesos más utilizados para la educción de requisitos, se encuentran en ellas varias deficiencias, como la falta de procesos estándar para estructurar la información recolectada, la carencia de herramientas de apoyo a este proceso, la alta incidencia del analista y las diferencias de lenguaje entre el analista y el interesado [4].

En este artículo, se propone un modelo de diálogo para la educción de requisitos, como una forma de suministrar una estructura que apoye el proceso de las entrevistas, la temática general de la educción de requisitos y el manejo de los turnos en esta forma de diálogo particular.

Este artículo está organizado de la siguiente manera: en la sección 2 se realiza un análisis crítico de los problemas de las entrevistas como medio de educción de requisitos; los modelos de diálogo se describen en la sección 3 y una propuesta de modelo de diálogo enfocado a la captura de requisitos se presenta en la sección 4. Finalmente, en las secciones 5 y 6 se muestran las conclusiones y el trabajo futuro respectivamente.

 

2. ANÁLISIS DE LOS PROBLEMAS DE LAS ENTREVISTAS COMO MEDIO DE EDUCCIÓN DE REQUISITOS

Las entrevistas, representan la principal técnica utilizada para la educción de requisitos, pues permiten al analista tomar conocimiento del problema y comprender los objetivos de la solución buscada. A través de esta técnica, el equipo de trabajo se acerca al problema de una forma natural. Existen muchos tipos de entrevistas y son muchos los autores que han trabajado en definir su estructura y dar guías para su correcta realización [2]. Entre los tipos más conocidos están la entrevista individual, el JAD (Joint Application Development) y el Brainstorming.

2.1 Entrevista individual
En las entrevistas convencionales, por lo general, se dan ciertos pasos, como los siguientes:

• Estudio del dominio del problema, para comprender las necesidades y expectativas de los interesados [5].
• Identificación de candidatos, con el fin de evitar problemas de la entrevista por una inadecuada selección de los entrevistados.
• Preparación, donde se definen cronogramas, lugares, recursos, etc.
• Desarrollo, que es la ejecución de la entrevista propiamente dicha.
• Continuación, que consiste en elaborar un resumen de la entrevista realizada para solicitar su validación por parte del interesado [6].

A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y, con su aplicación, el equipo de desarrollo puede obtener una amplia visión del trabajo y las necesidades del usuario, es necesario destacar que no es una técnica sencilla de aplicar y que tiene varias deficiencias. Requiere que el entrevistador sea experimentado y tenga capacidad para elegir bien a los entrevistados y obtener de ellos toda la información posible en un período de tiempo siempre limitado. Además, el manejo de información se hace subjetivo y puede llevar a una mala educción de requisitos. Aquí desempeña un papel fundamental la preparación de la entrevista [2]. Otras deficiencias de las entrevistas como medio para la educción de requisitos son: la redundancia de información, la existencia de información irrelevante o la falta de claridad en lo que requiere el interesado para el desarrollo del software y la carencia de herramientas de apoyo a su realización. Una de las causas de estas deficiencias, es la falta de estructura de las entrevistas, que se manifiesta en la forma en que las preguntas se formulan al interesado: pueden ser muy amplias y obligar al interesado a no ser breve ni conciso en su respuesta.

2.2 JAD (Desarrollo conjunto de aplicaciones)
Se basa en cuatro principios fundamentales: dinámica de grupo, uso de ayudas visuales para mejorar la comunicación, conservación de un proceso organizado y racional y empleo de una filosofía de documentación WYSIWYG (What You See Is What You Get, lo que ve es lo que obtiene). Tras una fase de preparación del JAD al caso concreto, el equipo de trabajo se reúne en varias sesiones [3]. En cada una de ellas, se establecen los requisitos de alto nivel a trabajar, el ámbito del problema y la documentación. Durante la sesión, se discute en grupo sobre los diferentes temas, obteniendo una serie de conclusiones que se documentan. En cada sesión, se van concretando más las necesidades del sistema.

En comparación con las entrevistas individuales, presenta las siguientes ventajas:

• Ahorra tiempo, al evitar que las opiniones de los interesados se contrasten por separado.
• La totalidad del grupo, que incluye a todos los interesados, revisa la documentación generada, por lo cual, esta técnica involucra más a los interesados en el desarrollo del software.

En comparación con las entrevistas individuales, presenta las siguientes desventajas:

• JAD es más costoso y puede ser incómodo si el grupo es demasiado grande en relación con el tamaño del proyecto.
• Requiere varias sesiones para clarificar información, lo que implica que la inversión en tiempo es mayor que cuando se realizan entrevistas individuales.

A nivel general, los riesgos son los mismos que en el caso de las entrevistas individuales, pues es difícil precisar la estructura de las sesiones, no se conocen herramientas especializadas de apoyo a esta técnica y la generación de los resultados se basa en la percepción subjetiva de los analistas.

2.3 Brainstorming (tormenta de ideas)
Es una técnica de reuniones en grupo, cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones de brainstorming se suelen conformar con grupos de cuatro a diez participantes, que libremente, con el apoyo del analista, sugieren ideas concernientes al dominio del problema [3].

Como técnica de educción de requisitos, el brainstorming puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de educción, cuando los requisitos son todavía muy imprecisos.

Frente al JAD y las entrevistas individuales, el brainstorming tiene la ventaja de que es muy fácil de aprender y requiere poca organización. De hecho, hay propuestas de realización de brainstorming por vídeoconferencia a través de Internet. Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras técnicas [3]. Así, se encuentra en este tipo de entrevistas los mismos problemas generales que se identificaron para la entrevista individual y para JAD.

2.4. Problemas remanentes
Christel y Kang [4], sugieren varios problemas aún sin solución en las entrevistas y las demás técnicas que se basan en ellas. Uno de ellos, es la carga que se endilga al analista en el proceso, ya que el analista recopila subjetivamente la información relevante para una buena educción de requisitos. Un segundo problema, se refiere a la carencia de procesos estándar para definir una correcta estructura en las entrevistas, de tal forma que se definan turnos y tiempos, tanto para el analista como para el interesado, además de formular correctamente las preguntas; las respuestas suministradas por el interesado no suelen ser, por ello, concisas, coherentes y cortas, como para permitirle al analista extraer toda la información necesaria para la construcción del software o sistema que requiere el interesado. Los otros dos problemas sugeridos, se refieren a la carencia de herramientas que apoyen el proceso de educción de requisitos y las diferencias de lenguaje que poseen los analistas y los interesados (los analistas se suelen expresar en lenguaje técnico del desarrollo de software y los interesados se interesan más por el lenguaje natural, propio de su dominio de conocimiento).

 

3. MARCO TEÓRICO

3.1 Modelos de diálogo
El habla, es el vehículo natural de comunicación que utiliza el hombre y se constituye como el medio de intercambio de información humano-humano más importante. Es, mediante el habla, que el hombre transmite mensajes que contienen información. Las tecnologías del habla, se integran en un ámbito más general, el de las tecnologías lingüísticas, cuyo principal objetivo es facilitar la interacción oral entre personas y sistemas informáticos. De esta manera, las tecnologías del habla engloban a aquellas que permiten, por ejemplo, que un ordenador ofrezca información oral (síntesis), procese información oral emitida por un locutor (reconocimiento) y desarrolle una comunicación bidireccional humano-computador y viceversa (sistemas de diálogo), entre otras cosas [7].

Dentro del ámbito de la Lingüística Computacional y la Ingeniería del Lenguaje, una línea de investigación relacionada con el área del diálogo y las tecnologías del habla, se centra en el modelado del diálogo, asumiendo, entre otros objetivos, el desarrollo de algoritmos, estrategias y formalismos que permitan la participación de un sistema computacional en un diálogo cooperativo [8].

Un análisis exhaustivo del diálogo, requiere tener en cuenta tanto los aspectos relacionados con la representación semántica del contenido de las intervenciones de los diferentes participantes como la información pragmática asociada. Esta información pragmática, incluye los actos de habla, la información disponible para cada participante, los objetivos de la propia preferencia, etc. [8].

El diseño de sistemas computacionales para la gestión del diálogo, o interfaces computacionales, debe, por tanto, cubrir ambos aspectos. Es decir, debe incorporar tanto un formalismo para la representación semántica del lenguaje natural como un modelo para la manipulación de la información pragmática. Asimismo, este último componente debe permitir una gestión adecuada del carácter dinámico del propio discurso [9].

El desarrollo de sistemas de diálogo hablado, es uno de los objetivos que más interés suscitó en los últimos años dentro de la investigación en tecnologías del habla, puesto que constituye una de las aplicaciones que podría tener mayor utilidad en el mundo real.

Los sistemas de diálogo, surgieron para facilitar la interacción mediante el habla entre una persona y un sistema informático, sea para recabar información (cómo es el caso del proceso de educción de requisitos), para llevar a cabo transacciones o para realizar otras funciones. El diálogo entre personas, se basa en una gran diversidad de conocimiento, que permite realizar suposiciones y simplificar el lenguaje que se utiliza. Esto dificulta, en gran medida, que tales sistemas puedan dialogar con las personas de la misma forma en que éstas dialogan entre sí. De ahí, que la tendencia actual de esta tecnología esté orientada a desarrollar sistemas para dominios de aplicación restringidos, los cuales permiten utilizar información acerca de las posibles palabras, tipos de frases e intenciones de los usuarios.

Los sistemas de diálogo actuales se aplican principalmente a tareas como: información y reserva de viajes en avión o tren, compra de productos, información metereológica, control de terminales telefónicas, ayuda a la comunicación entre personas que hablan distintos idiomas, acceso al correo electrónico o mensajes telefónicos, etc. [10]. Específicamente, la estructura del modelo de diálogo es lo que lleva a que la educción de requisitos se pueda llevar a cabo exitosamente.

3.2 Análisis estructural de un diálogo
Bangalore et al. [11] proponen la estructura del diálogo que se muestra en la Figura 1, que representa un árbol con secuencias de diálogos (dialog), una estructura de tareas (tasks) y subtareas (topic/subtask) y estructuras lingüísticas de las expresiones, que son actos de diálogo (dialog act), expresiones (utterance) y cláusulas (clause).

Figura 1. Análisis Estructural del diálogo
Figure 1. Dialog Structural Analysis

Los elementos principales de esta estructura, se detallan a continuación.

3.2.1 Turnos y Expresiones
Un diálogo de cualquier índole (humano-humano o humano-sistema informático), se desenvuelve por medio de turnos, es decir, pregunta tras respuesta, donde la pregunta representa un turno con un determinado tiempo de duración y la respuesta otro turno, con otro tiempo, y así sucesivamente hasta terminar el diálogo [10].

La definición del tiempo apropiado, en el que cada turno debe tomar acción, es de gran importancia, al igual que una buena estructuración de la pregunta que se hace. Estos factores, condicionan una información clara y breve para una correcta educción de requisitos.

Generalmente, en un diálogo humano-humano, los participantes saben quién tiene la palabra y en qué momento hablar. Esto se conoce como comportamiento para tomar el turno (turn taking behavior) y se estudia en el análisis de conversación [10]. Además, existen ciertas reglas que gobiernan dicho comportamiento, por ejemplo:

• Si durante este turno el orador actual seleccionó a A como el siguiente orador, entonces A debe hablar.
• Si el orador actual no selecciona el siguiente orador, cualquier otro orador puede tomar el turno.
• Si nadie toma el siguiente turno, el orador actual puede tomar el siguiente turno.

Es importante tener en cuenta la segmentación a la hora de hablar de turnos y expresiones (utterances), puesto que muchos modelos de diálogo computacionales extraen una expresión como una unidad básica (primitiva). El problema, es complejo porque una sola expresión puede estar diseminada en varios turnos y viceversa.

La relación que se observa entre turnos y expresiones, parece ser uno a una en diálogos humano-sistema informático. Esto se debe, probablemente, a la simplicidad de los sistemas actuales, puesto que las personas tienden a usar expresiones y turnos simples en su diálogo con máquinas, lo cual no ocurre en diálogos humano-humano, en los que los turnos suelen ser muy largos y repletos de expresiones diferentes.

3.2.2 Actos de diálogo
En las conversaciones, a menudo, las expresiones son una especie de acción que el orador lleva a cabo. Estas acciones, se denominan verbos de acción y, más formalmente, actos de discurso (speech acts), que son de tres tipos [8]:

• Locutionary act: una expresión con significado.
• Illocutionary act: una pregunta, respuesta, etc.
• Perlocutionary act: efectos en los sentimientos, etc.

Los actos del discurso, son más comunes en conversaciones y diálogos sostenidos entre personas. Una unidad más general del discurso, que modela funciones conversacionales, se denomina acto de diálogo (dialogue act). Jurafsky [10], sugiere que cualquier acto de diálogo se agrupa en alguna de estas cinco clases:

• Asertividad: Compromiso del orador a algo (sugestionar, jurar, concluir, etc.).
• Dirección: Intento del orador para poner a otros a hacer algo (preguntar, ordenar, solicitar, invitar, aconsejar, etc.).
• Composición: Intento del orador a un curso de acción futuro (prometer, planear, apostar, oponerse, etc.).
• Expresión: Opinión del estado psicológico del orador sobre algún estado (agradecer, disculparse, dar la bienvenida, deplorar, etc.).
• Declaración: Uso de las expresiones como vía para mostrar un estado diferente del mundo (renuncia, despedida, etc.).

Los actos de diálogo más comunes son: Statment (Declaración), Yes-No Questions (Preguntas Si-No), Declarative Questions (Preguntas declarativas), WH-Questions (Preguntas aclarativas).

3.2.3 Etiquetado de los modelos de diálogo
En los diálogos humano-máquina, es necesario aclararle a la máquina la estructura del diálogo que está teniendo lugar. Para ello, se emplean etiquetas que describen el tipo de interacción que se está realizando por medio del diálogo. Mediante el etiquetado, es posible establecer los tipos y subtipos de los elementos que hacen parte de un diálogo en particular.

Entre varias técnicas para el etiquetado de los actos de diálogo, cabe resaltar el uso de DAMSL (Dialogue Act Markup in Several Layers) [12], que codifica varios niveles de expresión. Dos de estos niveles, forward looking function y backward looking function, son extensiones de la estructura del diálogo. El etiquetado se ubica principalmente en estas etiquetas: question, statment, suggest y acknowledgement. Es importante destacar que el acento, la pronunciación y la manera de entonación cuando se termina una frase o expresión, sirven para identificar los actos del diálogo.

 

4. DEFINICIÓN DE UN MODELO DE DIÁLOGO ENFOCADO A LA CAPTURA DE REQUISITOS.

El modelo de diálogo que se propone en este artículo, incluye la definición de unos temas generales que son transversales a cualquier proceso de educción de requisitos, independientemente del dominio al cual se dirija, un conjunto de etiquetas de diálogo, que permiten establecer cuáles deben ser los actos de diálogo que harán parte del proceso de educción y una estructura general de las preguntas, en la cual se combinan los elementos anteriormente descritos para establecer la manera como se puede realizar la entrevista que conducirá a la educción de requisitos.

4.1 Temas transversales al proceso de educción
En la Figura 2, mediante un esquema preconceptual, que es un gráfico que permite la representación del conocimiento [13], se propone un modelo de diálogo que permite hacer una educción de requisitos entre un sistema informático y un interesado.

Figura 2. Estructura propuesta para el Modelo de Diálogo
Figure 2. Proposed Dialog Model Structure

En la Figura 2, Los rectángulos en línea continua representan los conceptos relativos a la educción de requisitos y al modelo del diálogo; los rectángulos en línea discontinua son posibles valores del concepto al que están ligados (por ejemplo, "primero" es un posible valor de "nivel"); los óvalos se denominan "relaciones" y son verbos (cabe anotar que los verbos en óvalos con línea continua son únicamente "es" y "tiene", que se conocen como "relaciones estructurales" y los verbos en óvalos con línea discontinua son verbos de acción, denominados "relaciones dinámicas"; la flecha gruesa que une verbos como "inicia" y "responde", expresa una relación causa-efecto, que se lee "si el analista inicia el acto de diálogo, entonces el interesado responde el acto de diálogo"; las flechas delgadas son elementos de unión de conceptos a relaciones y viceversa; finalmente, las líneas discontinuas unen los conceptos con sus posibles valores.

Con este modelo, se busca una forma de encontrar o extraer la información precisa del interesado, para poder hacer un proceso eficiente de educción de requisitos. Se pretende, también, definir las bases para implementar el modelo en un sistema informático que asista el proceso de educción de requisitos.

4.2 Etiquetas del diálogo
La etiquetación del diálogo, es un aspecto importante a la hora de definir el modelo, y las preguntas a realizar al interesado. Es por ello que se definen, a continuación, las etiquetas que se utilizan en el modelo, distribuidas en tres niveles: un primer nivel de preguntas y respuestas(véase la Tabla 1) y un segundo y tercer nivel, correspondientes a los conceptos especiales de la educción de requisitos (véase la Tabla 2).

Tabla 1. Primer nivel de etiquetación
Table 1. First-level tagging

Tabla 2. Segundo y tercer nivel de etiquetación
Table 2. Second- and third-level tagging

La etiquetación de las frases se realiza de la siguiente manera: al final de cada frase, se coloca entre llaves el tipo de acto de diálogo, discriminando primero las etiquetas de primer nivel y, separadas por coma, se colocan luego las de segundo nivel y, así sucesivamente, a medida que se profundice en el nivel de etiquetación. La propuesta correspondiente a este artículo sólo trata la etiquetación hasta el tercer nivel. Los siguientes, son ejemplos de actos de diálogo etiquetados:

INTERESADO: De acuerdo. Comencemos. {Apertura}.
ANALISTA: ¿En qué área se ubica el problema? {Pregunta Declarativa}.
INTERESADO: intervienen en el proceso el profesor y el auxiliar de docencia. {Respuesta Declarativa, Actor}.
INTERESADO: Para que un alumno reingrese a la carrera, debe esperar al menos un semestre académico. {Respuesta Declarativa, Problema, Restricción}

4.3 Estructuración de las entrevistas
Las entrevistas, se estructuran de la siguiente manera: una etapa de preparación, en la que se definen las preguntas a realizar y se establece un tiempo promedio para las preguntas y las respuestas, y una etapa de desarrollo en donde se explica el objetivo y las metas de la entrevista.

Las preguntas se deben realizar tratando de que la conversación no se salga de curso y teniendo en cuenta el siguiente orden de temas:

Información sobre la entrevista.
Nombre de la Organización.
Área del problema.
Síntomas y Causas del problema.
Actores.
Funciones de los actores.
Restricciones del problema.

A medida que se vaya desarrollando la entrevista, se realiza la etiquetación de las preguntas y respuestas.

4.4 Caso de estudio
A continuación, se presenta, a modo de caso de estudio, una entrevista que se lleva a cabo entre un ANALISTA y un INTERESADO. Se aplican los principios definidos para el modelo de diálogo en los numerales 4.1 a 4.3.

Analista: Bienvenido, el objetivo de esta entrevista es aclarar la información concerniente al dominio del problema que vamos a trabajar. Por favor, responda de la forma más concreta posible {Apertura}.
Interesado: De acuerdo. Comencemos {Afirmación}.
Analista: ¿Cuál es el nombre de la organización? {Pregunta Declarativa}.
Interesado: Dimex S.A. {Respuesta Declarativa, Organización, Nombre}
Analista: ¿Es un problema o un proceso a optimizar? {Pregunta Declarativa}.
Interesado: Existen problemas en el pago de la nomina {Respuesta Declarativa, Problema}.
Analista: ¿Cuál es el área en la que se ubica el problema? {Pregunta Declarativa}.
Interesado: Tenemos problemas en el área administrativa {Respuesta Declarativa, Área}.
Analista: ¿Cuál es el síntoma del problema? {Pregunta Declarativa}.
Interesado: Retrasos en los pagos a los empleados, se está pagando generalmente cinco días después de lo debido. {Respuesta Declarativa, Problema, Síntoma}.
Analista: Elabore una lista de las posibles causas del problema. {Sentencia}.
Interesado: Retrasos en la entrega de recibos y consignaciones, mal manejo de la información, no existe un programa que organice la información y no hay interacción entre los departamentos. {Respuesta declarativa, Problema, Causa}
Analista: ¿Manejan algún programa con el que se realice el cálculo de la nómina? {Pregunta Si/No}
Interesado: No. {Respuesta Sí/No}.
Analista: Elabore una lista de las personas que intervienen en el proceso de nómina. {Sentencia}.
Interesado: En el proceso intervienen la secretaria, el gerente general y el contador. {Respuesta Declarativa, Actor}.
Analista: ¿Cuáles son las funciones de la secretaria? {Pregunta Declarativa}.
Interesado: La secretaria se encarga de organizar la información de los empleados para hacer las consignaciones y los respectivos recibos. {Respuesta Declarativa, Actor, Función}.
Analista: ¿Son sólo estás funciones? {Pregunta Aclarativa}.
Interesado: Sí. {Respuesta Sí/No}.
Analista: ¿Cuáles son las funciones del gerente general? {Pregunta Declarativa}.
Interesado: El gerente general se encarga de revisar la información recopilada por la secretaria y permite el pago a los empleados; en otras palabras, da su visto bueno. {Respuesta Declarativa, Actor, Función}.
Analista: ¿Son sólo estas funciones? {Pregunta Aclarativa}.
Interesado: Sí. {Respuesta Sí/No}.
Analista: ¿Cuáles son las funciones del contador? {Pregunta Declarativa}.
Interesado: El contador revisa y almacena los recibos entregados por la secretaria para la contabilidad de cada mes. {Respuesta Declarativa, Actor, Función}.
Analista: ¿Son sólo estas funciones? {Pregunta Aclarativa}.
Interesado: Sí. {Respuesta Sí/No}.
Analista: ¿Qué condiciona la ejecución del proceso? {Pregunta Declarativa}.
Interesado: Sólo la secretaria se encarga de hacer los pagos y recibos, nadie más interfiere en el proceso. {Respuesta Declarativa, Problema, Restricción}.
Analista: Esto da por terminada la entrevista, muchas gracias por su colaboración. {Cierre}.
Interesado: Gracias a usted. {Cierre}.

El caso de estudio anterior, suministra una visión global de cómo se podrían desarrollar las entrevistas con el uso de etiquetas para, de esta forma, llegar a sistematizar las entrevistas y darles una estructura más concreta que permita, en el futuro, elaborar un sistema informático que asista el proceso de educción de requisitos.

 

5. CONCLUSIONES

En este trabajo, se propuso un modelo de diálogo que contribuye a mejorar algunas de las falencias que se presentan en el proceso de educción de requisitos, dentro del desarrollo de aplicaciones de software. Particularmente, se suministra en el artículo un conjunto de temas transversales a cualquier proceso de educción de requisitos, un conjunto de etiquetas características de los modelos de diálogo aplicados a este proceso y una estructura de la forma de conducir una entrevista con los elementos anotados. De esta forma, se puede eliminar la subjetividad en el proceso de educción de requisitos, puesto que el analista puede seguir el plan de temas definido, estableciendo, en cada caso, los turnos del diálogo de manera adecuada y estructurada. Igualmente, se suministra claridad e intención a las respuestas de los interesados.

 

6. TRABAJO FUTURO

Una de las principales dificultades del trabajo que se propone en este artículo, es el hecho de que es un tema relativamente nuevo en el área de educción de requisitos. Por ello, una línea de investigación futura es la realización proyectos de investigación para desarrollar una herramienta usando los modelos de diálogo como fuente primaria y tener una aproximación al resultado final: una entrevista estructurada entre un analista y un interesado, apoyada por un sistema que conozca la estructura del diálogo genérico de educción de requisitos.

Un paso posterior, consistiría en entablar una relación directa entre los diálogos naturales y los discursos en lenguaje controlado, del tipo UN-Lencep, con el fin de involucrar trabajos como el de Zapata et al. [13], que se vinculan con fases posteriores de la educción de requisitos de manera automática.

Otra línea de trabajo, consiste en ampliar los niveles de etiquetación y crear sistemas inteligentes, de tal forma que abarque a cabalidad el proceso de educción de requisitos (Actores, funciones, características, restricciones, etc.).

Es necesario profundizar más en el uso de los modelos de diálogos, entenderlos y sistematizarlos, con el fin de que no sean sólo útiles en la educción de requisitos, sino en diversas áreas, usándolos como medio de información y comunicación con las máquinas.

 

AGRADECIMIENTO

Este artículo se realizó en el marco del proyecto de Investigación "Un modelo de diálogo para la generación automática de especificaciones en UN-LENCEP" financiado por la DIME.

 

REFERENCIAS

[1] LEITE, J. C. A survey on requirements analysis, Advanced Software Engineering Project. Technical Report RTP-071, Department of Information and Computer Science, University of California at Irvine, 1987.         [ Links ]
[2] PRESSMAN, R. Software Engineering: a practitioner's approach, 6th ed. McGraw Hill, New York, 2005.         [ Links ]
[3] RAGHAVAN, S., ZELESNIK, G. Y FORD, G. Lecture notes on requirements elicitation. Educational Materials, CMU/SEI-94-EM-10, Software Engineering Institute, Carnegie Mellon University, 1994.         [ Links ]
[4] CHRISTEL, M. Y KANG, K. Issues in Requirements Elicitation. CMU/SEI-92-TR-012, Software Engineering Institute, Carnegie Mellon University, 1992.         [ Links ]
[5] GOGUEN, J. Y LINDE, CH. Techniques for Requirements Elicitation. Proceedings of IEEE International Symposium on Requirements Engineering, Oxford, 1993, pp. 152-164.         [ Links ]
[6] ADRIANO, N. Comparación del Proceso de Elicitación de Requerimientos en el desarrollo de Software a Medida y Empaquetado. Propuesta de métricas para la Elicitación. Tesis de M.Sc. Universidad Nacional de la Plata, 2006.         [ Links ]
[7] SPROAT, R. A Computational Theory of Writing Systems. Cambridge University Press, Cambridge, 2000.         [ Links ]
[8] LEECH G. Y WEISSER M. Pragmatics and Dialogue. R. Mitkov (Ed.), "The Oxford handbook of computational linguistics", Oxford University Press, New York, 2003. pp. 136-156.         [ Links ]
[9] BARWISE, J. Y PERRY, J. Situations and Attitudes. MIT Press, Cambridge, 1983.         [ Links ]
[10] JURAFSKY, D. Y MARTIN, J. Speech and Language Processing: An Introduction to Natural Language Processing, Computational Linguistics, and Speech Recognition. Prentice-Hall, New Jersery, 2000.         [ Links ]
[11] BANGALORE, S., DI FABBRIZIO, G. Y STENT, A. Learning the Structure of Task-driven Human-Human Dialogs. Proceedings of the 21st International Conference on Computational Linguistics and the 44th annual meeting of the ACL, Sydney, 2006. pp. 201-208.         [ Links ]
[12] CORE, M. Y ALLEN, J. Coding Dialogs with the DAMSL Annotation Scheme. Proceedings of AAAI Fall Symposium on Communicative Action in Humans and Machines, Boston, 1997.         [ Links ]
[13] ZAPATA, C. M., GELBUKH, A. Y ARANGO, F. Pre-conceptual Schemas: a Conceptual-Graph-like knowledge representation for Requirements elicitation. Lecture Notes in Computer Sciences, 4293, 20006. pp. 27-37.         [ Links ]