ARTÍCULO ORIGINAL

Dinámica contextual de la educción de requisitos software

Contextual dynamic of the software requirements elicitation

Dante Carrizo^*

Departamento Ingeniería Informática y Cs. de la Computación, Facultad de Informática, Universidad de Atacama. Avda. Copayapu 485. Copiapó, Chile.

^*Autor de correspondencia: teléfono: + 56 + 52 + 206806, fax: + 56 + 52 + 206504, correo electrónico: dante.carrizo@uda.cl (D. Carrizo)

(Recibido el 20 de marzo de 2012. Aceptado el 11 de septiembre de 2013)

Resumen

La educción de requisitos software desde los stakeholders ha sido declarada como una actividad clave que influye poderosamente sobre la calidad de los requisitos especificados y, por lo tanto, del producto final del desarrollo. Por esta razón, es incuestionable la necesidad de contar con guías claras para conducir la interacción con los propietarios de la información del dominio y de las necesidades a las que se pretende dar solución. Este trabajo se centra en la modelación de la educción considerando la influencia de los agentes contextuales del proceso tales como: eductor, quien conduce la actividad; informante, quien posee la información relevante; dominio del problema, características de la problemática a atacar; y proceso, características y restricciones de la actividad misma. El artículo analiza la dinámica que relaciona y condiciona estos factores para seleccionar la técnica a aplicar en cada sesión de educción. Finalmente, el trabajo contribuye con un modelo temporal del proceso y con la representación de la casuística principal del proceso de educción.

Palabras clave: Ingeniería de software, ingeniería de requisitos, modelo de requisitos software, modelo educción de requisitos, atributos del proceso de educción

Abstract

The software requirements elicitation from stakeholders has been stated as a key activity influencing strongly on quality of specified requirements and, therefore, of the final development product. For this raison, is undoubtly the necessity to dispose clear guidelines to drive the interrelationship with the owners of the domain information and the needs that require solutions.This work focuses on the model of the elicitation considering the influence of the contextual agents of the process, such as: elicitor, who drive the activity; informant, who possess the relevant information; problem domain, characteristics of the problematic to tackle; and process, characteristics and restrictions of the activity itself. The article analyses the dynamic that relates these factors to select the technique to use in each elicitation session. Finally, the work contributes with a time model of the process and with the representation of the main casuistic of elicitation process.

Keywords: Software engineering, requirements engineering, software requirements model, requirements elicitation model, elicitation process attributes

Introducción

El proceso sistemático para determinar los requisitos software a través de un proceso iterativo y cooperativo de adquisición de información acerca del dominio del problema, documentando las observaciones resultantes en una variedad de formatos de representación, y chequeando la precisión del entendimiento ganado [1] es actualmente denominada Ingeniería de Requisitos (IR). Es aceptado por la comunidad de la ingeniería de software que la correcta realización de la etapa de requisitos es vital para la calidad del desarrollo de productos software [2, 3]. No obstante, una somera revisión de las investigaciones en Ingeniería de Requisitos permite entrever que la mayoría de los trabajos realizados hacen referencia a métodos o técnicas de modelado y especificación de requisitos [4], descuidando en consecuencia todo lo referido al modo en que se deben obtener esos requisitos desde los interesados en el desarrollo.

Todo esto supone una carencia importantísima para la actividad de requisitos, ya que la efectividad de la educción (elicitation) es un factor que influye poderosamente sobre la calidad de los requisitos y, por lo tanto, del producto final. Por esto, es indudable la necesidad de contar con guías claras para conducir el proceso de interacción con los propietarios de la información de requisitos del producto y, en particular, para la selección de la(s) técnica(s) que mejor funcione(n) en un contexto particular, tal como han sugerido algunos investigadores del área [5, 6].

Esta investigación pretende apoyar al equipo de desarrollo en la realización de la educción de requisitos, es decir, la interacción entre el equipo de desarrollo y los que poseen la información relacionadas con el problema-producto. Para esto, este artículo modela la dinámica de la educción y la relación entre los atributos de los agentes o factores que influyen en la efectividad de este proceso. El análisis de este proceso se realiza a través de diagramas que muestra la evolución en el tiempo de las sesiones de educción. La modelización propuesta es aplicada a una casuística representativa de la educción de requisitos.

Antecedentes

Tal como ocurre con el proceso de Ingeniería de Requisitos, hay bastante ambigüedad y diferencias de enfoques sobre la actividad de educción. Este proceso tiene como objetivo la identificación de información que ayude a determinar las características deseadas del sistema software. Para ello, es necesario considerar información del dominio del problema proveniente de los interesados en el desarrollo del producto. El conocimiento del dominio del problema ayuda al ingeniero de requisitos a obtener un grado común de entendimiento del mundo del usuario y facilita el proceso de captura y especificación de requisitos. Además, este conocimiento puede ser reutilizado en futuras especificaciones significando ahorros de tiempo y costos.

La forma como el equipo de desarrollo establece los requisitos que representan las necesidades de los usuarios/clientes es a través de un proceso que no ha llegado aún a formalizarse sistemáticamente. Esto, probablemente, se debe a las siguientes razones:

No hay normas o estándares que orienten sobre la actividad de interacción con las fuentes de requisitos.

No hay claridad de cómo enfrentar el problema de sonsacar de las fuentes su conocimiento acerca dominio del problema debido a la falta de guías prácticas y poco entendimiento del proceso.

Existen muchos parámetros contextuales (como características del proyecto y de los participantes) que son difíciles de manejar para decidir el camino correcto a seguir en la educción.

Se ha ejecutado la educción como un proceso monótono de interacción sin fin, soslayando la necesidad de instancias en el proceso que permitan analizar dónde estamos y cómo podemos proseguir la captura de información de requisitos.

En la práctica, la actividad de educción es conducida intuitivamente, dejando la dinámica del proceso al sentido común del ingeniero de requisitos. Se captura información de requisitos de todas las fuentes disponibles, a veces redundando excesivamente, hasta que se tiene la idea de que todo lo que se ha obtenido debe comprender la totalidad de la necesidad de los stakeholders. En general, el proceso de educción involucra a un conjunto de personas que mediante interacciones, presenciales y no, entregan información al equipo de desarrollo que la utiliza como materia prima para producir los requisitos del sistema software a construir.

Existen algunos modelos que consideran todo el proceso de Requisitos, que por razones de espacio no se incluyen, pero no existen muchos modelos que describan la educción modelando su ejecución. De estos modelos destacan dos vistas diferentes del proceso. La primera, de Christel y Kang, describe el proceso de educción en cinco pasos en forma de cascada, con posibilidad de volver a etapas anteriores [7]. El modelo que se presenta en la figura 1 y tiene cinco etapas.

El segundo modelo presentado por Chatzoglou y Macaulay denomina el proceso como Captura y Análisis de Requisitos (CAR) y lo dividen en tres fases: Obtener información, Examinar y Asimilar la información (para determinar requisitos) y Verificar si se ha obtenido suficiente información y requisitos identificados. Una iteración de CAR puede ser considerada como una ejecución de estas fases [8]. El modelo del proceso, mostrado en la figura 2, sigue un enfoque de espiral que relaciona las variables de tiempo y costo para obtener requisitos. Muestra que los valores pueden ser diferentes en cada iteración, o mejor dicho, ''el costo y tiempo marginal gastados en obtener información extra no son el mismo en diferente iteraciones''.

Las propuestas anteriores coinciden en el carácter iterativo de la educción. En el modelo de Christel y Kang la cantidad de iteraciones es más abierta y puede asociarse a la ejecución de una sesión de educción. En el caso de Chatzoglou y Macaulay se limita la cantidad de iteraciones estableciéndose alrededor de cuatro como máximo. Si las iteraciones coinciden con las sesiones, que es lo que parece indicar el modelo, es un número muy inferior a lo que pueda darse en muchos desarrollos. Si una iteración implica varias sesiones, no se indica en qué momento se toma esa decisión y si se refiere a un mismo usuario/cliente. Esa instancia de decidir sobre las sesiones de educción siguientes no aparece en los modelos dejando una brecha entre el modelo conceptual y la práctica. Además, los modelos no sólo estudian la actividad de educción sino que la unen a otras actividades de requisitos con lo que no permite una comprensión singular del proceso.

Modelo del proceso de educción

Con lo anterior, esta investigación propone un nuevo modelo que intenta reflejar el carácter práctico y sistemático del proceso. La modelización de la educción contiene dos vistas: una longitudinal, mostrada en la figura 3, y una transversal, mostrada en la figura 4.

La vista longitudinal muestra el proceso de educción en el tiempo como una actividad iterativa compuesta de un conjunto finito de sesiones de educción representadas por un ciclo de la espiral. Cada sesión de educción comprende la interacción del eductor (Ingeniero de Requisitos o integrante del equipo de desarrollo que captura requisitos) con uno o más informantes o stakeholders (sujetos poseedores de la información de requisitos) por un tiempo mostrado en la amplitud del ciclo de la espiral. Nótese que las amplitudes de las sesiones son diferentes indicando que pueden tomar distinta cantidad de tiempo. Una nueva sesión puede realizarse con los mismos sujetos o con unos nuevos, utilizando la misma técnica de educción o una nueva.

En este modelo se establece una relación uno a uno entre las iteraciones y las sesiones, considerando esta última como la ''célula'' básica del proceso. Todas las decisiones en el proceso recaen, por lo tanto, sobre la planificación de una o más sesiones futuras, que dependerán de lo acontecido en sesiones anteriores y de situaciones emergentes.

En la vista se establecen tres periodos principales en el proceso de educción que se corresponden con el atributo de Momento del Proceso: Inicial, donde se establece información global de requisitos que sirve para la gestión del proyecto global como para el resto del proceso de educción; Intermedio, donde se captura la mayor cantidad de los requisitos; y Final, donde se establecen los últimos y se refinan los requisitos. Tanto la fase inicial como la final son menos extensas e involucran menos sesiones que la intermedia.

La vista transversal del modelo (que no es un corte transversal) nos da otra perspectiva de la educción. En ella aparecen en círculos concéntricos los límites de los momentos definidos en la vista longitudinal. Las sesiones aparecen encadenadas en una espiral que por la perspectiva presenta las externas o posteriores más grandes, pero que no implica que éstas tengan connotaciones superiores en algún factor respecto de las internas o iniciales.

Por otro lado, la encadenación de las sesiones no implica necesariamente consecución. El modelo realiza una abstracción y encapsulación del proceso de educción sin mostrar su relación con otras actividades de requisitos como análisis, especificación, verificación y gestión. En la práctica, al terminar una sesión es posible que se continúe con alguna de estas otras actividades de requisitos volviendo posteriormente a una nueva sesión de educción.

Cada sesión de educción se divide en tres tareas:

Preparación de Sesión: Aunque esta actividad se menciona en varias técnicas, en este modelo no se refiere únicamente a lo que concierne a la técnica de educción. Es una tarea que toma más relevancia en esta propuesta de investigación ya que tiene mayor alcance y termina con la logística de la sesión. Cuando estamos en el momento inicial, la preparación permite establecer información general del proyecto que puede utilizarse para gestionar el resto del proceso de educción. En sesiones posteriores, se debe considerar la información obtenida en sesiones anteriores y ocurrencia de circunstancias o problemas emergentes del proyecto que pueden afectar las sesiones siguientes.

Sesión de Educción: Es la tarea productiva que recupera información de los interesados en el proyecto para conformar los requisitos del sistema software. Para ello, se aplica una técnica seleccionada y preparada durante un tiempo estimado prudente, y acorde con la naturaleza y prescripción de la técnica.

Evaluación de Sesión: Esta fase, posterior a la realización de la sesión de educción, no sólo se limita al análisis de la información obtenida sino a reflejar otros aspectos de la sesión ejecutada que pueden influir en las decisiones sobre las sesiones siguientes. Estas variaciones en el contexto de la educción conforman información de entrada a la preparación de la sesión siguiente.

Dinámica del proceso de educción

El proceso de educción de requisitos es iterativo y su unidad elemental es la sesión de educción. Varias sesiones pueden relacionarse si se realizan al mismo informante o están orientadas a un mismo propósito de información objetivo, por ejemplo.

Pese a la simpleza del proceso en términos generales, es una actividad con varias instancias en que el ingeniero de requisitos debe tomar decisiones. Junto a las tareas logísticas de preparación y a las intelectuales del análisis de la información, debe decidir sobre: el cambio de fuentes o informantes, el cambio de técnica de educción, cambio de objetivos de las sesiones siguientes, etc.

Estas decisiones en el proceso están influenciadas por los atributos contextuales del mismo [9]. Es decir, los atributos que pueden variar su valor debido a acciones provocadas con alguna finalidad o a la variación normal del proceso producto de los resultados que se van obteniendo. Estos cambios de valores en los atributos condicionan la toma de decisiones del eductor y por lo tanto la dinámica del proceso de educción.

La dificultad del proceso radica justamente en estos cambios emergentes frente a los cuales el eductor no cuenta con guías prácticas, procedimientos y herramientas que faciliten la conducción de la actividad de educción. La solución propuesta en esta investigación pretende ayudar en esta dirección apoyando al eductor en su tarea. Para lograr esto, se debe conocer con detalle el proceso de educción.

El proceso comienza casi conjuntamente con el comienzo del proyecto. Más aún, el proceso de educción puede comenzar antes que el proyecto obtenga un comienzo formal. Esto se debe a que, en algunos casos, se requiere de educciones iniciales para obtener información relevante para la evaluación y aprobación del proyecto.

En esta etapa, la preparación de las sesiones tiene objetivos más claros de definir pues son más globales aunque no menos complicados de conseguir. Las características del eductor son conocidas en este momento aunque algunas de ellas podrían ser mejoradas de cara al resto del proceso. También en este momento puede conocerse los potenciales informantes y sus características. Esta información permite auscultar si algunos valores de los atributos de estos informantes pueden mejorarse para propiciar una óptima sesión de educción. Con la información anterior, y la información del dominio y del proyecto, se podría orientar la decisión sobre la técnica a utilizar en la próxima sesión. Para terminar la preparación, se realizan las acciones logísticas necesarias para llevar a cabo la sesión, tales como: conseguir los recursos y locaciones necesarias, concertar las citas con los informantes, y preparar, si es necesario, el contenido y material técnico y de apoyo a utilizar en la sesión.

Al finalizar la sesión, el eductor debe analizar la información recopilada desde el o los informantes. Pero además, recoge información que modifica los atributos contextuales y, por lo tanto, que puede influir sobre las decisiones a tomar para las próximas sesiones. Al interactuar con los informantes puede conocer si tienen interés en el proceso, si hay consenso en sus puntos de vista, etc.

La evaluación al término de la sesión no sólo se refiere a la sesión ejecutada sino a la trayectoria del proceso de educción hasta entonces. Este recuento retrospectivo orienta al eductor en la preparación de la próxima sesión y le ayudar a decidir si continúa con el mismo informante, si se actúa sobre el mismo para lograr algún cambio en su conducta, si se cambia por otro, si se cambia de técnica, etc.

Instanciación de atributos de influencia

En la evolución temporal del proceso de educción existen varias instancias en que el eductor debe decidir sobre los atributos del contexto [9]. En estos hitos, puede dar valores o decidir mejorar las condiciones de algunos atributos. Los atributos de diferentes factores que influyen en el proceso de educción [10] se clasifican según su volatilidad, es decir, el grado en que propenden a cambiar, clasificándolos en estáticos o dinámicos, como muestran las tablas 1 y 2. Otra categoría tiene que ver con la posibilidad de mejorar el estado actual de los atributos, realizando alguna acción que cambie su valor original, clasificándolos en mejorables y no mejorables.

Como el proceso se basa en la iteración de sesiones, la definición de las condiciones de los atributos recae en alguna de sus instancias. Estas instancias están relacionadas principalmente con los momentos de las sesiones como se explica a continuación y muestra la figure 5.

Inicio proceso de educción

Al iniciar el proyecto, el eductor es asignado por lo que los valores particulares de sus atributos son conocidos. Específicamente, los atributos valorados son Formación en Técnicas de Educción, Experiencia en Educción, Experiencia en la Técnica de Educción y Familiaridad con el Dominio y, dependiendo de los valores, se pueden recomendar acciones de mejora para Formación en Técnicas de Educción y Familiaridad con el Dominio.

Preparación sesión

En esta actividad es posible que se prepare el inicio de un grupo de sesiones ligadas a objetivos de educción definidos por eductor, o aplicadas a un mismo informante. En este caso, se establecen los valores de Nivel de Pericia y, con eventuales recomendaciones, los relacionados a su Localización y Disponibilidad de Tiempo. Es posible que la primera vez algunos atributos del informante sean omitidos por falta de información como Consenso entre Informantes, Interés del Informante o Capacidad de Articulación. Junto a esto, se pueden establecer los valores de Individuos por Sesión, los atributos de la información del dominio, Tipo de Información a Educir, Nivel Información Disponible y Grado de Definición del Problema, y los atributos del proceso de educción Restricciones de Tiempo y el Momento del Proceso.

En sesiones posteriores, la preparación puede actualizar valores de los atributos. Es posible que se cambie un eductor o los informantes, que se haya mejorado algunos atributos de ellos, debiendo modificar sus valores. En estas instancias se pueden actualizar los valores del Proceso de Educción si han cambiado de valor o Individuos por Sesión si cambia la cantidad de informantes.

Evaluación de sesión

Al finalizar una sesión, luego de analizar la información educida, la evaluación de la sesión permite recopilar información que ayuda a establecer el valor de atributos como Consenso entre Informantes, Interés del Informante o Capacidad de Articulación.

Entre la evaluación de la sesión y la preparación de la siguiente, se actualizan valores de Tipo de Información Disponible, Nivel de Información a Educir y Grado de Definición del Problema. Además, se actualizan si se han mejorado los valores de Localización y Disponibilidad de Tiempo del informante.

La evaluación de la sesión debe permitir obtener información conciliada acerca del resultado de la sesión y del avance del proceso de educción. Esta información estadística y sintomática permite tomar decisiones sobre las sesiones próximas respecto de redirección de los objetivos, cambio de informantes o incluso, cambio de eductor.

Casuística con respecto a participantes

Para facilitar la comprensión del tratamiento del proceso de educción anterior, se presentan algunos casos de ejemplos representativos de la dinámica del proceso de educción de requisitos. Estos casos están relacionados a las posibles variaciones de los participantes en el proceso de educción, es decir, eductores e informantes.

Tipo simple: eductor No mejorable, informantes individual-grupal No mejorables

Este caso es representado en la figura 6. El ingeniero de requisitos del equipo de desarrollo de este caso tiene formación formal y práctica en técnicas de educción, ha participado en 3 proyectos anteriores en tareas de educción aunque no ha aplicado más de dos veces algunas de las técnicas de educción. Uno de esos proyectos anteriores trataba el mismo dominio del actual, aunque es éste el único acercamiento experimentado. Esta información es suficiente para establecer los valores relativos al eductor tales como: Alta Formación en Técnicas de Educción, Experiencia Media en Educción, Baja Experiencia en las Técnicas de Educción y Baja Familiaridad con el Dominio.

Al inicio del proyecto, el eductor debe tomar conocimiento global del problema y del alcance del mismo. Para ello debe recabar información teniendo algún contacto con el directivo principal de la organización. Esta persona es la propietaria y gerente de la misma por más de 10 años y ha decidido realizar el proyecto dedicándole suficiente tiempo y liberando su agenda de viajes y compromisos. Esta información general del directivo permite al eductor preparar la sesión definiendo algunos valores iniciales del informante tales como: Nivel de Pericia de valor Experto, Localización/Accesibilidad Cercano, Alta Disponibilidad de Tiempo e Individual para Individuos por Sesión. Los restantes atributos relacionados al informante quedan pendientes o son omitidos (Interés del Informante, Capacidad de Articulación, Consenso entre Informantes). Además, se establecen los valores relacionados con la información del dominio del problema: Tipo de Información a Educir de valor Estratégico, Nivel de Información Disponible Nulo, y un Alto Grado de Definición del Problema ya que el problema es bien entendido por el equipo de desarrollo, una vez que le fue enviada documentación escrita acerca del producto pretendido. Finalmente, se activan atributos del proceso tales como: Restricción de Tiempo Media ya que se dispone de un plazo determinado para el desarrollo, y Momento del Proceso con valor Inicial.

Se decide utilizar la técnica de entrevista abierta con el gerente de la organización y al evaluar la información obtenida y el cometido de la sesión se actualizan los valores pendientes del informante tales como: Alto Interés del Informante y Alta Capacidad de Articulación. Además, se actualiza el valor de Nivel de Información Disponible a Superior y se emite un informe estadístico de la sesión y del avance del proceso de educción.

El eductor decide realizar una segunda sesión con el mismo informante para profundizar en algunos aspectos del problema por lo que se mantienen los valores tanto para el eductor como para el informante. Se prepara y realiza una entrevista estructurada con el directivo, al cabo de la cual se emite un nuevo informe de sesión y de avance del proceso.

El eductor entiende que el paso siguiente es recabar información general de los involucrados en las operaciones de la organización por lo que actualiza el valor de Tipo de Información a Educir a Táctico y actualiza los valores de los atributos por cambio del informante. Al pretender realizar una sesión con todos los interesados el valor de Individuos por Sesión se cambia a Grupal y se consideran valores promedios para los atributos del informante. Así, los nuevos valores son: Entendido para Nivel de Pericia ya que todos llevan entre 4 y 5 años en su función, Cercano para Localización/accesibilidad ya que todos trabajan en la misma edificación, Alta Disponibilidad de Tiempo ya que se ha liberado un mismo horario a todos para dedicarlo al proyecto.

Se realiza una sesión con la técnica Tormenta de Ideas con los informantes al cabo de la cual se emite un informe de la sesión y del avance del proceso y se actualizan valores como: Interés Alto de los Informantes, Bajo Consenso entre los informantes y Capacidad de Articulación Media para el grupo. De lo anterior, se deduce que ha terminado el momento inicial por lo que se cambia el valor del Momento del Proceso a Intermedio.

Tipo simple-variable: eductor mejorable, informantes individual no mejorables

Este caso es representado en la figura 7. En este caso el ingeniero de requisitos del equipo de desarrollo tiene conocimiento teórico somero de las técnicas, ha participado en 4 proyectos anteriores en tareas de educción en los que ha aplicado algunas técnicas por primera vez. De todas formas, ninguno de esos proyectos anteriores trataba el mismo dominio del actual, el cual es desconocido para él. Esta información define los valores relativos al eductor tales como: Baja Formación en Técnicas de Educción, Experiencia Media en Educción, Baja Experiencia en las Técnicas de Educción y Nula Familiaridad con el Dominio. Es posible que, al ser un sistema basado en conocimientos, el ingeniero de requisitos requiera mejorar su Formación en Técnicas de Educción tomando algún curso formal si el tiempo lo permite o realizando un curso práctico para ejercitar las técnicas. También es recomendable que tome un conocimiento básico del dominio leyendo literatura relacionada.

Al inicio del proyecto, el ingeniero de requisitos debe tomar conocimiento global del problema y del alcance del producto a desarrollar. Para ello debe recabar información del experto en el dominio y a la vez cliente del proyecto. Esta persona tiene una experiencia de 12 años en el dominio y aunque realiza su ocupación en la ciudad su disponibilidad de tiempo es limitada. Esta información general del experto permite al eductor preparar la primera sesión definiendo algunos valores iniciales del informante tales como: nivel de pericia de valor Experto, localización/accesibilidad Cercano, Baja disponibilidad de tiempo e Individual para individuos por sesión. Los restantes atributos relacionados al informante quedan pendientes o son omitidos (Interés del Informante, Capacidad de Articulación, Consenso entre Informantes).

Además, se establecen los valores relacionados con la información del dominio del problema: tipo de información a educir de valor Estratégico, nivel de información disponible Nulo, y un Alto Grado de definición del problema ya que el problema es bien entendido por el equipo de desarrollo una vez que le fue enviada documentación escrita acerca del producto pretendido. Finalmente, se activan atributos del proceso tales como: Restricción de Tiempo Media ya que se dispone de un plazo determinado para el desarrollo, y Momento del Proceso con valor Inicial.

Se decide utilizar la técnica de entrevista abierta con el experto para la primera sesión. Al evaluar la información obtenida y el cometido de la sesión se actualizan los valores pendientes del informante tales como: Alto Interés del Informante y Baja Capacidad de Articulación.

Además, se actualiza el valor de Nivel de Información Disponible a Básico ya que del estudio de mejora del dominio se ha adquirido un conocimiento básico de conceptos y se emite un informe estadístico de la sesión y del avance del proceso de educción. Por lo anterior, se cambia el valor del Tipo de Información a Educir a Táctico. El ingeniero de requisitos en este tiempo ha mejorado su Formación en Técnicas de Educción variando su valor a Alta y su Familiaridad con el Dominio variando su valor a Baja. Se decide realizar una segunda sesión con el mismo experto para profundizar en algunos aspectos del problema por lo que se mantienen los valores tanto para el eductor como para el informante. Con esto, se pasa a un Momento del Proceso Intermedio. Se prepara y realiza una sesión con la técnica de Emparrillado (repertory grid) con el experto, al cabo de la cual se emite un nuevo informe de sesión y de avance del proceso. Producto de esta evaluación se decide cambiar de informante por un segundo interesado en el desarrollo del producto que contiene información de otros aspectos funcionales del dominio.

El cambio de informante actualiza los valores como: Nivel de Pericia Entendido pues tiene 5 años en la realización de funciones en el dominio,

Localización Cercana pues trabaja en el mismo sitio que el anterior informante, y Disponibilidad de Tiempo Alta al reservar horarios para el proyecto. Se realiza una sesión con la técnica de Análisis de Protocolo con el informante al cabo de la cual se emite un informe de la sesión y del avance del proceso y se actualizan valores como: Interés Alto de los Informantes y Capacidad de Articulación Alta para el grupo.

Tipo variable-complejo: eductor no mejorable, informantes grupal- individual mejorable

Este caso es representado en la figura 8. El ingeniero de requisitos del equipo de desarrollo de este caso tiene formación formal y práctica en técnicas de educción, ha participado en 3 proyectos anteriores en tareas de educción aunque no ha aplicado más de dos veces algunas de las técnicas empleadas. Uno de esos proyectos anteriores trataba el mismo dominio del actual, aunque es éste el único acercamiento experimentado. Esta información permite establecer los valores relativos al eductor tales como: Alta Formación en Técnicas de Educción, Experiencia Media en Educción, Baja Experiencia en las Técnicas de Educción y Baja Familiaridad con el Dominio.

Al inicio del proyecto, el ingeniero de requisitos establece que el problema no está claro por lo que decide realizar una sesión con todos los interesados representativos de la organización. El grupo de informantes tiene un Nivel de Pericia de valor promedio Entendido, Localización Cercana ya que todos trabajan en la misma ciudad y algunos pueden trasladarse para la sesión, y Disponibilidad Alta de Tiempo por disposición organizacional.

Además, se activan los valores relacionados con la información del dominio del problema: Tipo de Información a Educir de valor Estratégico, Nivel de Información Disponible Nulo, y un Bajo Grado de Definición del Problema. Finalmente, se definen valores de atributos del proceso tales como: Restricción de Tiempo Baja ya que se dispone de tiempo holgado para el desarrollo, y Momento del Proceso con valor Inicial.

Se decide utilizar la técnica de JAD para clarificar el problema y conocer los puntos de vista de los interesados. Al evaluar la información obtenida y el cometido de la sesión se actualizan los valores promedios pendientes del informante tales como: Medio Interés del Informante, Media Capacidad de Articulación y Bajo Consenso entre Informantes. Además, se emite un informe estadístico de la sesión y del avance del proceso de educción.

El ingeniero de requisitos decide realizar una segunda sesión con el mismo grupo ya que los diferentes puntos de vista no permiten aclarar la definición del problema. Esta vez, se selecciona la Técnica de Grupo Nominal para propiciar un consenso. Al cabo de la interacción, se emite un nuevo informe de sesión y de avance del proceso. Como resultado de la sesión, se logra un Alto Consenso entre los Informantes y un Alto Grado de Definición del Problema. Además, se cambian los valores de Nivel de Información Disponible a Estratégico, el Momento del Proceso a Intermedio, y próximo Tipo de Información a Educir a Táctico.

El eductor entiende que el paso siguiente es recabar información más específica de algunos de los interesados participantes en las sesiones grupales.

Así comienza con sesiones uno a uno por lo que el valor de Individuos por Sesión cambia a Individual. El primer informante seleccionado tiene 4 años en sus funciones por lo que su Nivel de Pericia es Entendido. De su actuación en las sesiones se desprende que tiene Interés Medio y Media Capacidad de Articulación. Su lugar de trabajo está ubicado en otra ciudad y se había trasladado especialmente para las sesiones grupales. De igual forma, dispone de poco tiempo para el proyecto por lo que se recomienda hablar con su superior para liberarle de tareas y propiciar que se pueda trasladar para posibles futuras sesiones.

Mientras se realizan las gestiones se le envía un cuestionario para recabar información particular de su función. Al cabo de la evaluación de la información se emite un informe de avance. Las gestiones realizadas permiten, entonces, cambiar su Localización a Cercano y su Disponibilidad de Tiempo Alta para la selección de una nueva técnica en la siguiente sesión.

Tipo complejo: cambio eductor mejorable, informantes individual mejorables

Este caso es representado en la figura 9. En este ejemplo, el ingeniero de requisitos del equipo de desarrollo no tiene conocimiento alguno de las diversas técnicas de educción, y ha participado en sólo un proyecto anterior en tareas de educción en los que aplicó sólo entrevistas. Además, el dominio es totalmente desconocido para él. Esta información activa los valores relativos al eductor tales como: Nula Formación en Técnicas de Educción, Experiencia Baja en Educción, Nula Experiencia en las Técnicas de Educción y Nula Familiaridad con el Dominio. Es posible que, por la complejidad del desarrollo, el ingeniero de requisitos requiera mejorar su Formación en Técnicas de Educción tomando algún curso formal si el tiempo lo permite o realizando un curso práctico para ejercitar las técnicas. También es recomendable que tome un conocimiento básico del dominio leyendo literatura relacionada.

Al inicio del proyecto, el ingeniero de requisitos debe tomar conocimiento global del problema y del alcance del producto a desarrollar. Para ello, debe recabar información del cliente que es dueño de la empresa con una experiencia de 12 años en su función y, aunque realiza su ocupación en la ciudad, su disponibilidad de tiempo es limitada. Esta información general del experto permite al eductor preparar una primera sesión definiendo algunos valores iniciales del informante tales como: Nivel de Pericia de valor Experto, Localización/Accesibilidad Cercano, Baja Disponibilidad de Tiempo e Individual para Individuos por Sesión. Los restantes atributos relacionados al informante quedan pendientes o son omitidos (Interés del Informante, Capacidad de Articulación, Consenso entre Informantes).

Además, se establecen los valores relacionados con la información del dominio del problema:Tipo de Información a Educir de valor Estratégico, Nivel de Información Disponible Nulo, y un Bajo Grado de Definición del Problema ya que el problema aún no es bien entendido por el equipo de desarrollo. Finalmente, se activan atributos del proceso tales como: Restricción de Tiempo Media ya que se dispone de un plazo determinado para el desarrollo, y Momento del Proceso con valor Inicial.

Se decide utilizar la técnica de Entrevista Abierta con el experto para la primera sesión. Al evaluar la información obtenida y el cometido de la sesión se actualizan los valores pendientes del informante tales como: Alto Interés del Informante y Baja Capacidad de Articulación. El informe de la sesión establece que aún no se ha aclarado el problema en cuestión. Además, el ingeniero de requisitos no ha podido tomar formación acerca de las técnicas ni tomar conocimiento del dominio como le fue recomendado. Por estos motivos, se decide cambiar al eductor.

El nuevo eductor contratado tiene formación formal y práctica en técnicas de educción, ha participado en 3 proyectos anteriores en tareas de educción aunque no ha aplicado más de dos veces algunas de las técnicas empleadas. Uno de esos proyectos anteriores trataba el mismo dominio del actual, aunque es éste el único acercamiento experimentado. Esta información permite activar los nuevos valores relativos al eductor tales como: Alta Formación en Técnicas de Educción, Experiencia Media en Educción, Baja Experiencia en las Técnicas de Educción y Baja Familiaridad con el Dominio.

El nuevo eductor decide proseguir educiendo información del encargado de las operaciones. Un jefe que lleva 5 años en el cargo y que trabaja en la misma edificación aunque no tiene tiempo para el proyecto. El eductor decide enviarle un cuestionario, pero es recomendado que gestione con el dueño un tiempo de dedicación al proyecto para el informante de cara a las siguientes sesiones. El cuestionario contenía, junto las preguntas técnicas del dominio, algunas de tests que permitieron activar valores de Medio para el Interés del Informante y Baja para la Capacidad de Articulación.

La información obtenida fue de tipo Estratégico por lo que decide que la siguiente sesión debiera permitir recopilar información de más bajo Nivel. Así, el Tipo de Información a Educir será Táctico. Debido a que aún no está bien definido el problema y que el informante tiene poca capacidad para articular, el IR decide desarrollar un Prototipo para sesionar con él, más ahora que ha conseguido que disponga de tiempo para la sesión presencial (Disponibilidad de Tiempo Alta). La evaluación de la sesión permite obtener informes de avance del proceso de educción y principalmente lograr un entendimiento cabal del problema. Así, el Grado de Definición del Problema cambia a Alto y el Momento del Proceso a Intermedio.

Conclusiones

El presente artículo es parte de una investigación que intenta apoyar al equipo de desarrollo en la actividad de educción de requisitos de un producto software. Particularmente, presenta una propuesta de modelo de educción que describe como el ingeniero de requisito gestiona el proceso y como trata los atributos que lo condicionan. A diferencia de los modelos existentes, donde si bien es cierto se destaca el hecho de que el proceso involucra varias sesiones de educción, el modelo propuesto se focaliza sobre en entendimiento pragmático de las condicionantes que conducen cada sesión de captura de información relevante para conformar los requisitos. El conocimiento de la influencia de estos atributos contextuales permitirá tomar decisiones sobre la continuación de la educción de requisitos basadas en las condiciones circunstanciales del proceso. Para esto, se representaron los casos de ejemplo representativos que dieron más luz al proceso permitiendo conocer los atributos que influyen en la selección de una técnica adecuada para la próxima sesión. El trabajo presenta una visión en profundidad de la actividad y modela la interacción entre los agentes participantes. Esta información contribuirá con el diseño de una herramienta software que implemente el seguimiento del proceso de educción asistiendo al ingeniero de requisitos en la toma de decisión acerca del devenir de la captura de requisitos. Además, se espera llevar a cabo un estudio empírico de los casos propuestos con el fin de complementar el trabajo presentado.

Agradecimeintos

El presente artículo es parte de una investigación apoyada y financiada por el fondo de concursos internos DIUDA 2010 de Dirección de Investigación de la Universidad de Atacama.

References

1. P. Loucopoulos, V. Karakostas. Systems Requirements Engineering. Ed. McGraw-Hill, Inc. New York, NY, USA. 1995. pp.19-23.         [ Links ]

2. B. Boehm, R. McClean, D. Urfrig. ''Some experience with automated aids to the design of large-scale reliable software''. IEEE Transactions on Software Engineering. Vol. SE-1. 1975. pp.125-133.         [ Links ]

3. Standish Standish Group. The CHAOS Report. Disponible en: http://www.projectsmart.co.uk/docs/chaos-report.pdf. Consultado en: octubre 2005.         [ Links ]

4. B. Kovitz. Practical Software Requirements: A Manual of Content and Style. E.d. Manning Publications Co. Greenwich, CT, USA. 1998. pp. 28-29.         [ Links ]

5. A. Davis, A. Hickey. ''An Ontological Approach to Requirements Elicitation Technique Selection.'' Ontologies in the Context of Information Systems. R. Sharman, R. Kishore, R. Ramesh, (eds). Ed. Kluwer Academic Publishers. Dordrecht, The Netherlands. 2007. pp. 403-431.         [ Links ]

6. J. Dhaliwal, I. Benbazat. ''A framework for the comparative evaluation of knowledge acquisition tools and techniques''. Knowledge-Acquisition. Vol. 2. 1990. pp. 145-166.         [ Links ]

7. M. Christel, K. Kang. Issues in Requirements Elicitation. Technical report. Carnegie Mellon Software Engineering Institute. Pittsburgh, PA, US. 1992. pp. 27-30.         [ Links ]

8. P. Chatzoglou, L. Macaulay. ''Requirements capture and analysis: a planning model''. Information-&- Systems-Engineering. Vol. 1. 1995. pp. 271-87.         [ Links ]

9. D. Carrizo. Revisión de los Atributos Contextuales que influyen en la Selección de Técnicas de Educción de Requisitos. Jornadas Iberoamericanas de Ingeniería de Software y de Ingeniería del Conocimiento. Veracruz, México. 2006. pp. 253-260.         [ Links ]

10. D. Carrizo, O. Dieste. Atributos Contextuales Relevantes para la Selección de Técnicas de Educción Requisitos. Jornadas Iberoamericanas de Ingeniería de Software y de Ingeniería del Conocimiento. Lima, Perú. 2007. pp. 143-149.         [ Links ]