Artículo original

ANÁLISIS DE VARIANTES DE UN PROCESO DE REQUISITOS

VARIANTS ANALYSIS OF A REQUIREMENTS PROCESS

Graciela HADAD⁽¹⁾, Viviana LEDESMA⁽²⁾, Jorge DOORN⁽³⁾

⁽¹⁾Universidad Nacional del Oeste

Universidad Nacional de La Matanza

ghadad@uno.edu.ar

⁽²⁾ Universidad Nacional de La Matanza

vledesma@unlam.edu.ar

⁽³⁾ Universidad Nacional del Oeste

Universidad Nacional de La Matanza

jdoorn@uno.edu.ar

Resumen:

La literatura muestra que las técnicas empleadas en un proceso de Ingeniería de Requisitos frecuentemente son elegidas en función a características particulares de cada proyecto, usualmente denominadas factores situacionales. Con lo anterior presente, se ha trabajado en la adaptación dinámica de un proceso de Ingeniería de Requisitos, que ha estado en aplicación por más de dos décadas. Dicha adaptación consiste en ir ajustando el mismo, según diferentes combinaciones de factores situacionales en puntos de variación específicos, gestionando un reservorio de bloques de proceso que son incorporados o descartados como parte de la adaptación. Este artículo, presenta un estudio de las tres variantes del proceso que se consideran más significativas, mediante estudios de casos controlados. Este trabajo permitió analizar la calidad de los requisitos obtenidos con cada variante, cuando se trataba de un dominio de aplicación relativamente conocido por los ingenieros de requisitos, así como considerar también el esfuerzo insumido. Esto posibilitó detectar algunos aspectos en los que el mecanismo de adaptación aún debe fortalecerse.

Abstract:

The literature shows that the techniques used in a Requirements Engineering process are frequently chosen based on the particular characteristics of each project; these are called situational factors. Taking the above into account, work has been done on the dynamic adaptation of a Requirements Engineering process, which has been in use for more than two decades. This adaptation consists of adjusting the requirements process according to different combinations of situational factors at specific variation points, managing a repository of process blocks that are incorporated or discarded as part of the adaptation. This article presents a study of the three variants of the process that are considered of most significance, through controlled case studies. This work has made possible to analyze the quality of the requirements obtained and the effort required in each variant, when dealing with an application domain relatively known to requirements engineers. This led to identify some aspects in which it is still necessary to strengthen the adaptation mechanism.

Palabras Clave: Ingeniería de Requisitos, Factores Situacionales, Variabilidad de Procesos, Ingeniería de Métodos Situacional

Keywords: Requirements Engineering, Situational Factors, Process Variability, Situational Method Engineering

I. INTRODUCCIÓN

Dado que el conocimiento del dominio del problema se expresa sobre todo en lenguaje natural, el uso de un enfoque basado en representaciones de requisitos en lenguaje natural favorece la comunicación con los clientes y usuarios, lo que incrementa el compromiso de los mismos, creciendo de esta manera la probabilidad de éxito del proyecto [1].

Sin embargo, por sí sólo, el uso del lenguaje natural no garantiza una buena comunicación. Es más, en situaciones desfavorables puede entorpecerla significativamente. Esto último ocurre cuando los interlocutores pertenecen a diferentes culturas o dominios de conocimientos disímiles. Para atemperar este tipo de dificultades, especialmente las relacionadas con la falsa sensación haber establecido una comunicación eficaz sin efectivamente haberlo logrado y poder aprovechar las ventajas del uso del lenguaje natural es muy recomendable procurar unificar el lenguaje que se utiliza. En el proceso [2] que sustenta el estudio que se reporta en el presente artículo, se exige que los ingenieros de requisitos comprendan y utilicen el vocabulario que emplean los clientes y usuarios del universo de discurso (UdeD) [2]. Definitivamente, esta no es una práctica aislada ya que el uso de glosarios está muy difundido en la Ingeniería de Requisitos (IR) [3]-[6].

La experiencia adquirida en el desarrollo profesional de software, principalmente en el uso del proceso mencionado [2], indica que cada proyecto tiene características particulares, por las que se hace necesario efectuar cambios en actividades definidas. Esta práctica es común en muchos dominios, especialmente en el desarrollo de software [7], [8]. Es entonces que se diseñó un método de adaptación del proceso de requisitos utilizado en base a 26 factores relacionados con el contexto de aplicación y con las características propias del proyecto de software [9]. Este método, que permite tomar decisiones guiadas acerca de cómo ajustar el proceso y los modelos a construir según la situación imperante, se basa en principios de la Ingeniería de Métodos Situacional [10]-[12] y de la Variabilidad de Procesos [13].

El propósito del presente trabajo es estudiar la adaptación de un proceso de requisitos basado en modelos escritos en lenguaje natural cuando es puesta en práctica por ingenieros de requisitos que tienen un cierto conocimiento del contexto de aplicación, y que, por ende, pueden no requerir una fase de aprendizaje previa ni del lenguaje de los clientes y usuarios ni de los procesos del negocio, antes de proceder a establecer los requisitos del software. Para ello se ha optado por planificar y llevar a cabo un estudio de dos casos controlando algunos aspectos.

II. PROCESO DE REQUISITOS UTILIZADO

El proceso de requisitos utilizado desarrolla dos modelos iniciales [2] como una instancia de aprendizaje sobre el UdeD: un glosario, denominado Léxico Extendido del Lenguaje (LEL), con definiciones de los términos utilizados en el UdeD, y un modelo del proceso del negocio, denominado Escenarios Actuales (EA), el que provee descripciones de las actividades que tienen lugar en el UdeD. El proceso sigue una secuencia base que puede tener reciclos por evolución del UdeD y por corrección de defectos, que está compuesto por los siguientes subprocesos (ver Figura 1 – en la misma se omitieron los reciclos):

1. Identificar preliminarmente el objetivo general y alcance del sistema de software.

2. Crear el Léxico Extendido del Lenguaje, [14].

3. Construir Escenarios Actuales. Estos EA se describen usando los términos definidos en el LEL del UdeD.

4. Construir Escenarios Futuros (EF), con el fin de definir el contexto del software y cómo el software interactuará en ese contexto [15].

Fig. 1. Proceso de Requisitos basada en Modelos en Lenguaje Natural

5. Crear el Léxico Extendido del Lenguaje del Sistema, que describe los términos introducidos o modificados utilizados para describir los EF [16].

6. Refinar el objetivo general del sistema y descomponerlo en objetivos específicos.

7. Especificar requisitos, produciendo el documento de ERS, extrayendo los requisitos del conjunto de EF [17].

En este proceso la fase de aprendizaje se concentra en los subprocesos Crear el Léxico Extendido del Lenguaje y Construir Escenarios Actuales, mientras que los siguientes subprocesos corresponden a una fase de definición de los requisitos. Claramente la actividad inicial de identificación del objetivo general del sistema da un marco de referencia para las fases de aprendizaje y de definición.

En resumen, el proceso se enfoca en alcanzar la máxima comprensión del UdeD, con el objetivo de lograr que los ingenieros de requisitos, junto con los clientes, puedan definir soluciones a través de un sistema de software, permitiendo a la vez planificar cambios al macrosistema fácilmente insertables en la cultura de la organización y compatibles con los recursos disponibles.

A continuación, se describe brevemente el modelo de Escenario, dado que en el estudio realizado se usaron los Escenarios Futuros como base de comparación.

Fig. 2. Ejemplo de Escenario

Cada escenario permite describir una situación actual o futura del UdeD, acotada en un contexto dado donde participan actores y se utilizan recursos, por lo que el modelo de Escenario [4] es una estructura compuesta por las siguientes entidades: título, objetivo, contexto, recursos, actores, episodios y excepciones, y el atributo restricción. Un escenario debe satisfacer un objetivo que se alcanza realizando sus episodios donde intervienen los actores. Estos describen el curso principal de acción como también los cursos alternativos, mientras que los caminos excepcionales se muestran en un componente diferente. Además, la situación que se describe en el escenario ocurre en un contexto dado por la ubicación geográfica, la ubicación temporal y la precondición o estado inicial de dicha situación. Un ejemplo de escenario se presenta en la Figura 2, extraído del caso Sistema de Gestión de Biblioteca, donde las frases subrayadas indican que son términos definidos en el LEL.

III. ADAPTABILIDAD DE PROCESOS

Adaptar sistemáticamente un proceso comprende identificar adecuadamente, por un lado, las posibles alternativas de variación del proceso y, por otro, los aspectos que rodearán su desarrollo para determinar apropiadamente la selección de estas variaciones.

Para definir adaptaciones al proceso de requisitos presentada en la sección anterior, tal como se mencionó antes, se utilizaron conceptos y principios provenientes de la Ingeniería de Métodos Situacional [12] y de la Variabilidad de Procesos [13].

El objetivo de la Ingeniería de Métodos Situacional es la construcción de métodos específicos para llevar a cabo un proyecto, que se ajuste a las situaciones particulares de su contexto, de modo flexible, adaptable, ágil y repetible [10], [18]. Siguiendo los principios de esta disciplina, la adaptación de un proceso de desarrollo de software se basa en indicadores que en su conjunto definen una situación [19]. Se entiende como situación a la combinación de circunstancias en un momento dado y en un contexto específico, que afecta la forma de trabajo y los productos a generar [20]. Entonces, la situación queda caracterizada por un conjunto de factores del contexto de aplicación y del proyecto de software.

Según Brinkkemper en [18], un proceso se compone de fragmentos o bloques más pequeños, que se caracterizan por tener un objetivo, el que puede ser alcanzado por una o más actividades que se realizan aplicando una o más técnicas incluidas en ese bloque y que pueden generar uno o más artefactos. Algunos de los bloques son comunes a todas las situaciones mientras que otros son variantes de acuerdo a distintos factores de situación. Por lo tanto, el proceso se conforma con la unión de ciertos bloques para una situación particular [11].

Por otro lado, la Variabilidad de Proceso se enfoca en extender, personalizar o configurar un proceso para ser reutilizado bajo un determinado contexto, cuya detección involucra identificar qué puede variar, porqué y cuáles son las variantes posibles [13], [21]. La gestión de variabilidad incluye la definición de:

· los puntos de variación a detectar en el proceso, que corresponden a dónde los elementos del proceso pueden cambiar;

· las posibles resoluciones o flujos variantes, que son las partes del proceso que representan la variabilidad e implementan los puntos de variación; y

· el mecanismo de variabilidad a usar, que puede ser: parametrización, adición, omisión, reemplazo de un elemento simple y variabilidad de tipo de dato.

Han surgido propuestas para atenuar los problemas detectados en la creación y mejora de procesos de IR, adaptándolos a las características particulares de un proyecto, aplicando en mayor o menor medida principios de la Ingeniería de Métodos Situacional.

En algunos de estos trabajos se pone a disposición una base de conocimiento sobre actividades y técnicas de IR, que sirve de guía para crear un proceso de IR acorde a las necesidades del proyecto [22], [23]. Estas propuestas se fundamentan en la reutilización, y el proceso se define tomando elementos de métodos ya existentes. A pesar del uso de algunos atributos relacionados con el proyecto, estos autores no dan criterios claros de aplicación de los mismos, o solo presentan pautas de selección muy generales.

Ciertos trabajos [24]-[26] aportan guías para la selección de las técnicas de elicitación, considerando determinadas características contextuales, como el número de fuentes de información, la distribución geográfica del usuario, la disponibilidad de tiempo del usuario, y su experiencia en el dominio, entre otras.

Existen otras propuestas para la adaptación situacional de actividades de IR para proyectos de determinada naturaleza o alcance, por ejemplo, desarrollo global de software o métodos ágiles [27]-[29].

Otros trabajos se han centrado en mecanismos para la creación de un proceso de IR ajustado a las características situacionales del entorno, aplicable a proyectos de diferente naturaleza, utilizando algunos principios de la Ingeniería de Métodos Situacional mediante el uso de componentes modulares existentes, combinando con conceptos de variabilidad de procesos [30], [31].

La propuesta de adaptación que se presenta aquí se enmarca en los últimos trabajos mencionados, pues tiene por finalidad establecer mecanismos claros para adaptar un proceso de IR de acuerdo con las características particulares del contexto en el que ésta deba ser aplicada.

IV. ADAPTACIONES AL PROCESO DE REQUISITOS

En el proceso de IR utilizado en este trabajo, se propusieron en su momento, adaptaciones al proceso base descripto en la sección 2, según las características específicas del contexto de aplicación y del proyecto de software en particular [32], [9]. Para ello se utilizó una combinación de principios de la Ingeniería de Métodos Situacional y de la Variabilidad de Proceso. Se definieron 5 puntos de variación (ver Figura 3) se identificaron 10 factores relacionados con el contexto de aplicación y 16 factores relativos al proyecto. Cada subproceso se compone de actividades, algunas de ellas se descomponen en subactividades, siendo el nivel más bajo de descomposición un bloque de proceso. Algunos bloques de proceso pueden ser compartidos por algunos subprocesos. Se definieron reglas de adaptación en cada punto de variación en función de los factores situacionales que afectan al subproceso en su conjunto o a partes de dicho subproceso. Mediante estas reglas se establecen los mecanismos de adaptación partiendo del proceso base: reemplazar un bloque de proceso por otro, adicionar un bloque, eliminarlo o parametrizarlo. La parametrización implica asignarle al bloque valores de factores situacionales que producen solo variaciones internas leves a la actividad, tal como usar determinada técnica.

Fig. 3. Variantes de Alto Nivel en el Proceso Base

La Figura 3 presenta el proceso base con las variantes de mayor nivel, donde algunos subprocesos de primer nivel podrían ser omitidos (reemplazo por el Bloque Nulo). Las condiciones (reglas de adaptación) que rigen estas variantes de nivel superior se describen a continuación. Cabe aclarar que los factores situacionales se utilizan en distintos niveles del proceso, no solo en el nivel superior donde se decide solo omitir o no un subproceso, sino a nivel de actividades de los subprocesos, omitiéndolas, reemplazándolas, agregando nuevas actividades o como parámetros de las actividades, siguiendo los principios de la Ingeniería de Métodos Situacional. Como se muestra en la Figura 3, si las condiciones 1 a 4 son verdaderas, se recomienda la omisión de los respectivos subprocesos.

En esta adaptación no se ha considerado posible omitir la construcción de los EF, por considerárselos vitales para una adecuada definición de los requisitos en un marco tal que permita gestar propuestas y soluciones alternativas en cuanto a las características y comportamientos del futuro sistema de software interactuando con el macrosistema y que permita incluso promover mejoras al propio macrosistema. A continuación, se describen estas 4 condiciones, poniendo énfasis en las primeras dos condiciones, que son las que se han utilizado en el estudio de caso.

· Condición 1: se refiere a la omisión o no del subproceso Crear Léxico Extendido del Lenguaje:

Se va a prescindir de crear el léxico en el caso que el equipo de requisitos haya participado en proyectos referidos al mismo dominio del software a desarrollar, lo cual implica que tiene una amplia experiencia en el UdeD. Lo anterior aplica siempre que no existan diferencias idiomáticas ni temporales entre los involucrados o que los usuarios se encuentren distribuidos geográficamente. A pesar de ello, hay otros factores que se deberán considerar para evaluar la posibilidad de omitir este bloque: que no haya exigencia de construir un LEL del UdeD para reuso, o la necesidad de cumplir con una pre-rastreabilidad a todos los artefactos del proceso. Lo anterior se define a partir de la siguiente condición 1, donde si es verdadera no se construye el LEL del UdeD.

· Condición 2: se refiere a la omisión o no del subproceso Construir Escenarios Actuales:

Este subproceso modela las situaciones del contexto presente, a través de los EA. En determinadas situaciones, esta actividad carecería de sentido, por ejemplo, si se va a desarrollar un software para un mercado potencial, o si se trata de un contexto nuevo. Por otra parte, sería improductivo crear los EA cuando el nivel de cambios en el contexto de aplicación sea extremadamente alto. Además de los casos mencionados, hay dos situaciones en las que se podría prescindir de los EA. Una es cuando el equipo de requisitos además de contar con una sólida experiencia en el dominio conoce en profundidad las actividades del contexto de aplicación, cómo se desenvuelven y cuáles son las responsabilidades de los actores en dicho contexto particular. Si tal fuera el caso, se debe considerar que no deben existir diferencias idiomáticas, culturales ni temporales significativas entre los involucrados, y que los usuarios estén en un mismo lugar. De modo similar, podría omitirse la construcción de los EA si el equipo tiene sólida experiencia en el proceso de IR, el tamaño del proyecto no es grande, para un contexto muy simple, de baja complejidad, con mínimas inconsistencias, y hay poca rotación de los usuarios y también del equipo de desarrollo. Ambos contextos mencionados admiten la omisión de este bloque siempre que no haya la exigencia de construir EA para reuso o de cumplir con una pre-rastreabilidad a todos los artefactos. Esto queda formulado en la siguiente condición 2, donde si es verdadera entonces no se construyen los EA.

· Condición 3: se refiere a la omisión o no del subproceso Construir el Léxico Extendido del Sistema:

Este subproceso se realiza paralelamente a la construcción de los EF. Puede omitirse si no hay exigencia de construir este LEL para reuso ni para cumplir con una pre-rastreabilidad que involucre a todos los artefactos. Tampoco es necesario cuando el equipo de requisitos tiene una amplia experiencia en el UdeD, no existen diferencias idiomáticas ni temporales entre los involucrados, los usuarios no están distribuidos geográficamente y no se realizará una alta reingeniería en los procesos del negocio. En el caso de cambios sustanciales en los procesos del negocio, ello puede impactar notablemente en las descripciones de los EF, requiriéndose desambiguar el nuevo vocabulario introducido en dichas descripciones.

· Condición 4: se refiere a la omisión o no del subproceso Especificar Requisitos:

Este subproceso explicita los requisitos del software extrayéndolos de los EF y luego construye el documento ERS. En algunos proyectos, este subproceso debe realizarse debido a la exigencia de un documento con todos los requisitos del software, ya sea por razones contractuales, certificaciones de software u otras. Sin embargo, en otros contextos podría omitirse, por ejemplo, para proyectos de pequeña envergadura, o sin una exigencia de producir requisitos para reuso, ni es necesario individualizar los requisitos por no desarrollarse actividades de rastreabilidad.

V. DESCRIPCIÓN DEL ESTUDIO DE CASO

Concentrando nuevamente la atención en el núcleo central del presente artículo que reporta los resultados de estudiar, en forma descriptiva y parcialmente explicativa, la efectividad de las tres adaptaciones más importantes es que, a tal efecto, el estudio de caso se elaboró para comparar las siguientes variantes:

· producir los requisitos generando cada uno de los modelos propuestos en el proceso de requisitos, denominado proceso base;

· producir los requisitos omitiendo la construcción del LEL del UdeD; y

· producir los requisitos omitiendo la construcción de los EA.

Se reitera que el objetivo de este estudio ha sido poder establecer qué variante logra una mejor calidad de los requisitos y el esfuerzo que dicho trabajo demanda, cuando se trata de un dominio de aplicación relativamente conocido por los ingenieros de requisitos. Es por ello que las variantes se focalizan en la fase de aprendizaje contemplada en el proceso de requisitos. En resumen, los modelos que se generan en cada variante bajo estudio son:

Variante V1: LEL del UdeD – EA – EF – LEL del Sistema – ERS

Variante V2: LEL del UdeD – EF – LEL del Sistema – ERS

Variante V3: EA – EF – LEL del Sistema – ERS

Es decir, las variantes a estudiar dependen de la construcción o no de los modelos LEL del UdeD y EA, siendo la variante V1 el proceso base de referencia.

El estudio se desarrolló en un contexto académico, en el marco de una asignatura de 4to. año en una carrera informática de la Universidad Nacional de La Matanza. Todos los sujetos fueron estudiantes que realizaban la experiencia como parte de un proyecto integrador de la asignatura, lo cual implicaba que estuvieran involucrados y comprometidos con la realización de sus tareas. Se conformaron en forma aleatoria 12 grupos, de 4 a 6 alumnos. Debe mencionarse que ninguno de los sujetos (estudiantes) tenía experiencia en IR, y todos recibieron la misma capacitación acerca del proceso de requisitos a lo largo de la cursada. Sin embargo, la naturaleza de los casos estudiados y su involucramiento en el mismo garantizaba un importante conocimiento del mismo.

Se seleccionaron dos casos referidos a sistemas en funcionamiento en la Universidad, cuyo dominio es relativamente conocido por los sujetos:

Caso CA: Sistema de Autogestión de Alumnos

Caso CB: Sistema de Gestión de Biblioteca

Cada grupo desarrolló su proyecto integrador utilizando una variante asignada del proceso de requisitos (V1, V2 o V3) que debían aplicar sobre uno de los dos contextos de aplicación señalados (CA o CB), durante un cuatrimestre (16 semanas).

Los estudiantes dispusieron del documento de objetivo y alcance del sistema, y tenían la posibilidad de acceso al uso del sistema existente para cada caso.

La Tabla 1 detalla el caso y la variante del proceso con la que trabajó cada grupo.

TABLA 1.

Asignación de casos y variantes del proceso por grupo

VI. DESCRIPCIÓN DE LA SITUACIÓN DE CADA CONTEXTO DE APLICACIÓN

Cabe mencionar que los alumnos usan habitualmente el Sistema de Autogestión de Alumnos para toda su actividad administrativa en la Universidad por lo que se establece que el nivel de conocimiento previo del dominio es Muy Alto, mientras que el uso del Sistema de Gestión de Biblioteca suele ser menos frecuente, conociendo algunas actividades con cierto nivel de detalle y desconociendo algunas otras, principalmente las vinculadas a otros tipos de lectores no alumnos, por lo que se establece que el nivel de conocimiento previo del dominio es Medio. Esto es lo que marca la diferencia en la situación entre el caso CA y el caso CB: el nivel de conocimiento previo del dominio.

En la Tabla 2 se indican los factores situacionales relevantes para decidir la construcción o no del LEL del UdeD y de los EA, según lo descripto en la sección 3.

En base a los valores de estos factores, la recomendación propuesta de adaptación del proceso de requisitos para el caso Sistema de Autogestión de Alumnos (CA) es no construir el LEL del UdeD (condición 1 = V) y construir los EA (condición 2 = F), según las condiciones descriptas en la sección 3. Mientras que para el caso Sistema de Gestión de Biblioteca (CB) la recomendación propuesta es construir el LEL del UdeD (condición 1 = F) y construir los EA (condición 2 = F). Luego, en ambos casos se sugiere la construcción de EA. Estas decisiones están básicamente relacionadas con el conocimiento previo del UdeD y la experiencia en el proceso de requisitos de los ingenieros de requisitos.

TABLA 2.

Detalle de la situación para los casos bajo estudio

En base a lo recomendado para cada caso, esto indica que el caso CA se desarrollaría siguiendo la variante V3, mientras que el caso CB estaría bajo la variante V1.

VI. MÉTRICAS UTILIZADAS EN EL ESTUDIO DE CASO

Un buen indicador que sirve de base para comparar los resultados al aplicar las distintas variantes del proceso son los EF obtenidos por cada grupo. Esto es así debido a que, por un lado, son elaborados en cualquier variante y, por otro lado, dichos escenarios concentran tanto los requisitos funcionales y no funcionales en sus descripciones.

No obstante, comparar únicamente los valores de las mediciones tomadas de cada modelo de EF obtenido no permite visualizar el resultado real alcanzado, dado que dichos valores dependen de cómo los grupos organizaron los escenarios y con qué nivel de detalle los describieron. Por ejemplo, para el Sistema de Autogestión de Alumnos el grupo G8 definió un EF para la funcionalidad Consultar historial académico, mientras que para cubrir la misma funcionalidad el grupo G9 definió 4 EF y el grupo G11 definió 3 EF. Por lo tanto, se hizo necesario establecer las funcionalidades esperadas para cada sistema, para lo cual se consolidaron los objetivos de los EF generados por cada grupo, teniendo como base el objetivo y alcance inicial establecido. Así es que para el Sistema de Autogestión de Alumnos se identificaron 26 funcionalidades según el alcance del sistema (ver Tabla 3), y para el Sistema de Gestión de Biblioteca 17 funcionalidades (ver Tabla 4).

TABLA 3.

Funcionalidades cubiertas para el Sistema de Autogestión de Alumnos

Cabe mencionar que no debe interpretarse que estas dos listas de funcionalidades abarcan la totalidad de servicios que cada sistema debería efectivamente cubrir, sino que es un mero parámetro de comparación a utilizar respecto al grado relativo de cobertura alcanzado por cada grupo, debiéndose tener presente la imposibilidad de establecer con certeza el nivel de completitud alcanzado. Este aspecto de la falacia de la completitud ha sido ampliamente tratado en la literatura [33].

TABLA 4.

Funcionalidades cubiertas para el Sistema de Gestión de Biblioteca

Teniendo presente lo anterior, se definió un conjunto de métricas, enfocadas en los EF, para luego permitir comparar los resultados conseguidos con la aplicación de cada variante bajo estudio en cada caso. La Tabla 5 detalla cada una de las métricas definidas.

TABLA 5.

Métricas para comparar la aplicación de las variantes del proceso

VII. ANÁLISIS DE LOS RESULTADOS

Una vez concluidos los proyectos, se tomaron las mediciones según las métricas definidas en la Tabla 5. Cada proyecto implicó la realización de una variante del proceso de IR para un caso dado y por un grupo dado. En las Tablas 6 y 7 se presenta un resumen de las mediciones obtenidas para el análisis de cada caso.

TABLA 6.

Mediciones obtenidas para el Sistema de Autogestión de Alumnos

TABLA 7.

Mediciones obtenidas para el Sistema de Gestión de Biblioteca

Tanto en el caso del Sistema de Autogestión de Alumnos como en el Sistema de Gestión de Biblioteca, se observa en las Tablas 6 y 7 que la cobertura de funcionalidades entre la V1 y la V2 son bastante similares (ver métricas 2 y 3) con un nivel de confianza superior al 95%. Sin embargo, esto no ocurre en el nivel de detalle de la descripción de dichas funcionalidades (ver métricas 5, 6 y 7), donde se observa una diferencia pronunciada en el promedio de episodios por EF entre ambas variantes para el caso CB (también con un nivel de confianza superior al 95%), siendo menos notoria para el caso CA. En ambos casos, el mayor nivel de detalle con que se describen las funcionalidades se alcanza con la V1 (que construye los EA) respecto de la V2. No es posible realizar estas comparaciones con la V3 dado la única muestra disponible en cada caso. Lo que puede mencionarse es que dichos valores (métrica 7) de la V3 son más cercanos a la V2 en ambos casos.

Debe aclararse que para los cálculos de nivel de confianza se ha utilizado la distribución t de Student [34], considerando que las curvas para las variantes V1 y V2 son aproximadamente gaussianas y se tienen muestras pequeñas en ambos casos. Ver tablas anexas A.1 y A.2 con el detalle de resultados estadísticos con un nivel de significancia α= 0,05.

Al estudiar la tasa de excepciones por EF (ver métrica 9) surge que no hay diferencias significativas entre la V1 y la V2 para ambos casos, con un nivel de confianza superior al 95%.

En el caso CB se observa una cantidad similar de actores identificados entre las variantes V1 y V2 con una probabilidad superior al 95%, lo que no ocurre en el caso CA (ver métrica 10 en Tablas 4 y 5). Al no observarse causas aparentes provenientes de ambos dominios, se puede decir que estas observaciones están dando un indicio de falencias en las heurísticas referidas a la identificación de actores.

En lo que sigue se analizan las recomendaciones de adaptación del proceso de IR para la situación de cada caso, en cuanto a la construcción o no del LEL del UdeD y de los EA, estudiando los resultados obtenidos en el promedio de episodios por EF para cada variante aplicada, pudiendo o no sobrar el LEL del UdeD, pudiendo o no sobrar los EA, e incluso pudiendo faltar los EA para cada caso según la variante utilizada (ver Tabla 6).

Comparando la variante V1 con la variante V2, surge con una probabilidad superior al 95% que hacer los EA es más beneficioso cuando se trata de un contexto menos conocido (Caso CB); en este caso la V1 estaría acompañando esta observación (aunque sin valor estadístico).

En la variante V1 comparando el caso CA con el caso CB, no se detectan diferencias si se recomienda hacer el LEL o no, con un nivel de confianza superior al 95%. En otras palabras, surge que, si bien las reglas que deciden sobre la necesidad de hacer o no el LEL están correctamente enfocadas, son demasiado laxas, recomendando hacer esa actividad en situaciones en las que podría no ser necesaria.

Comparando el caso CA con el caso CB en la variante V2, se detecta con una probabilidad superior al 90% que es más perjudicial no hacer los EA cuando se recomienda construir ambos modelos LEL y los EA.

Sin evidencia estadística, debido a la escasa cantidad de casos de la variante V3, es posible observar que no construir el LEL del UdeD cuando se recomienda hacerlo aparentemente sería más perjudicial.

TABLA 8.

Análisis de la recomendación de adaptación del proceso de IR por caso

Dadas las diferencias en la cantidad promedio de episodios para cada variante, se realizó un análisis más profundo sobre dos de las funcionalidades más relevantes de cada caso, realizando un estudio estadístico y un estudio semántico de cada uno de los EF que representan dichas funcionalidades. En la Tabla 7 se muestra la cantidad de episodios y excepciones de los EF Inscribir a materias e Inscribir a exámenes finales del Sistema de Autogestión de Alumnos (CA). Por su parte, en la Tabla 8 se presenta el mismo detalle para los EF Realizar un préstamo y Devolver un préstamo, del Sistema de Gestión de Biblioteca (CB).

TABLA 9.

Resultados del análisis de dos EF del Sistema de Autogestión de Alumnos

TABLA 10.

Resultados del análisis de dos EF del Sistema de Gestión de Biblioteca

En base al estudio estadístico, surge para ambos casos, con una probabilidad superior al 80%, que construir los EA (V1) frente a no construirlos (V2) ha sido más beneficioso en cuanto a lograr una mayor cantidad de episodios por EF, lo que está en concordancia con lo estudiado previamente para el conjunto total de EF. Ver tablas anexas A.3 y A.4 con el detalle de resultados estadísticos con un nivel de significancia α= 0,20.

En cuanto a las excepciones, se observan valores similares en cada EF entre la V1 y la V2 en ambos casos, excepto para el primer escenario del caso CA, con una probabilidad superior al 80%. Obviamente, no es posible realizar ninguna observación estadística relativa a la V3.

Para ambos casos, se analizó semánticamente los dos EF seleccionados, observándose que los episodios de quienes siguieron las variantes V1 y V3 son más completos y bien detallados. En tanto que los grupos que aplicaron la variante V2, tienen episodios muy generales de alto nivel, sin mucho detalle sobre cómo efectivamente deberían realizarse las actividades a través del nuevo sistema de software, ni qué información específica debería manejarse, ya sea para control, presentación, carga o consulta. Esto podría indicar que la heurística de construcción de EF cuando se parte de un LEL del UdeD sin EA no es lo suficientemente precisa (V2), mientras que los EA facilitarían proponer soluciones a través de los EF al haber identificado problemas en los EA. Considerando que se trataban de contextos relativamente conocidos, la falta de experiencia en IR podría estar jugando un papel más importante que el considerado por las reglas de adaptación utilizadas.

En cuanto a los tiempos promedios insumidos al aplicar el proceso en cada una de sus variantes, se ha tomado como punto de referencia el tiempo insumido para realizar el proceso completo (variante V1). En el caso del Sistema de Gestión de Biblioteca, los equipos que aplicaron la variante V2 tardaron un 41% menos respecto a la variante V1, y los que aplicaron la variante V3 un 18% menos, lo cual es lógico debido al tiempo requerido para producir todos los modelos del proceso de IR en la variante V1. Por otro lado, la diferencia entre las variantes V2 y V3 significa que llevó más tiempo construir los EA que el LEL del UdeD, lo cual también es razonable debido a que los EA exigen elicitar y elaborar más información y de distinto nivel de granularidad. Sin embargo, los grupos que construyeron los EA tuvieron mejores resultados en cuanto a la cobertura de funcionalidades con los EF y el nivel de detalle alcanzado en sus descripciones (en base al estudio estadístico de cantidad promedio de episodios por EF y al análisis semántico realizado sobre los dos EF más relevantes de cada caso). En cuanto al Sistema de Autogestión de Alumnos, se observa que aquellos que aplicaron la variante V2 tardaron un 44% menos con relación a la variante V1, siendo bastante similar al caso CB. En cambio, los que aplicaron la variante V3 tardaron un 15% más de tiempo respecto a la variante V1, lo cual podría tener relación con que quienes aplicaron la variante V3 tuvieron una cobertura de las funcionalidades muy superior a la obtenida por los que aplicaron las variantes V1 y V2.

En otras palabras, en el caso del Sistema de Autogestión de Alumnos surge, con una probabilidad superior al 80%, que existen notorias diferencias de tiempo entre la V1 y la V2; esto también se refleja en la única muestra de la V3 respecto de las otras dos variantes. Sin embargo, en el caso del Sistema de Gestión de Biblioteca no se observan las mismas notorias diferencias, con la misma probabilidad.

A fin de realizar una correcta interpretación de los resultados, considerando sus limitaciones, se han analizado las amenazas a la validez a las que podría estar sujeto este estudio. A continuación, se listan las principales amenazas identificadas y la forma en que han sido tratadas:

· Capacidad de los sujetos: la diferencia de capacidad y experiencia de los sujetos puede sesgar los resultados. Para mitigar esta amenaza los grupos fueron formados al azar lo cual atenúa el problema de que no todos los sujetos tenían las mismas capacidades.

· Seguimiento del proceso: es posible que los sujetos no cumplan con el proceso establecido, o incluso que lo apliquen de distinta forma. Para evitar esta amenaza los alumnos fueron supervisados semanalmente por los docentes con los mismos lineamientos. De este modo esta amenaza se reduce, pero no se neutraliza.

· Sujetos sin experiencia: el estudio se ha realizado en un contexto académico. Los sujetos no tienen o tienen poca práctica en la industria. Además, no cuentan con experiencia en el proceso de IR. Los grupos recibieron instrucciones generales del proceso de IR a llevar a cabo. Para contener esta amenaza, a medida que avanzaban en el proceso se fueron dando explicaciones detalladas de cada etapa del mismo. A pesar de ello, los resultados no son generalizables de forma directa a profesionales u otro tipo de sujetos.

Debido a limitaciones en la cantidad de grupos utilizada para el estudio, cada variante del proceso no ha sido aplicada por la misma cantidad de grupos, lo que se considera que es una amenaza de segundo orden.

VIII. CONCLUSIONES

Se ha realizado un estudio para comparar las principales variantes del proceso de IR referidas a omitir la construcción de algunos de los modelos de la fase de aprendizaje. En el mismo se utilizaron dos dominios de aplicación, disponiendo de un total de 13 muestras. Los sujetos que participaron contaban con similar conocimiento del dominio de aplicación, pero no poseían experiencia en el proceso de requisitos.

El estudio arrojó indicios preliminares que advierten que la calidad de los requisitos no sería independiente del modo en que se aplica proceso de IR. Se observa que al partir de sujetos con la misma experiencia en el dominio de aplicación, los EF generados tuvieron mayor calidad cuando estos se construyeron con una fase de aprendizaje basada en la construcción de los EA, en comparación con aquellos EF construidos con una fase de aprendizaje basada únicamente en la creación del modelo LEL del UdeD. Aunque, para esta última variante, también es posible que se trate de la carencia de una heurística apropiada para construir EF sin disponer de EA.

En otros términos, los resultados apoyan la recomendación dada por las reglas de adaptación de crear los EA para ambos casos, al menos en el contexto de las heurísticas actuales.

Sin embargo, estos son indicios preliminares que deben ser ratificados con otras réplicas del estudio, en otros dominios, e incluyendo otras variantes. En cuanto a la construcción de EF como una actividad obligatoria en este proceso de IR, se considera que la estrategia presentada en [6] que promueve la extracción directa de requisitos a partir del LEL es un salto muy largo para lograr requisitos de buena calidad con un nivel de completitud aceptable, aunque sería apropiado ponderar la importancia de esa presunta debilidad en el marco del proceso de adaptación expuesto.

Las mediciones obtenidas aún son escasas para obtener conclusiones generalizables. No obstante, los resultados alcanzados son válidos para reforzar las reglas planteadas y promover futuros trabajos.

Asimismo, se ha observado que algunos factores situacionales tendrían distinto grado de impacto en el desarrollo del proceso de requisitos, con lo cual podría ser necesario ponderar este impacto en las reglas de adaptación asignando pesos a los factores.

IX. REFERENCIAS Y BIBLIOGRAFÍA

A. Referencias bibliográficas:

[1] L. Macaulay, “Requirements Capture as a Cooperative Activity”. Proceedings of IEEE International Symposium on Requirements Engineering, San Diego, EEUU. IEEE: 174-181, 1993.

[2] J. Leite, J. Doorn, G. Kaplan, G. Hadad, & M. Ridao, “Defining System Context Using Scenarios”. Perspectives on Software Requirements, Kluwer Academic Publishers, chapter 8: 69-199, 2004.

[3] A. Cockburn, “Writing Effective Use Cases”. Addison-Wesley Professional, 2000.

[4] J. Leite, G. Hadad, J. Doorn, & G. Kaplan, “A Scenario Construction Process”. Requirements Engineering Journal, 5(1): 38-61, 2000.

[5] D. Leffingwell, & D. Widrig, “Managing Software Requirements - A Unified Approach”. Second edition. Addison-Wesley Object Technology Series, .2003.

[6] L. Antonelli, G. Rossi, J. Leite, & A. Oliveros, “Deriving Requirements Specifications from the Application Domain Language Captured by Language Extended Lexicon”. Proceedings of XV Workshop on Requirements Engineering. Buenos Aires, Argentina, 2012.

[7] P. Haumer, “IBM Rational Method Composer: Part 1: Key concepts”, 2005. Recuperado el 1/10/2020, https://www.ibm.com/developerworks/rational/library/dec05/haumer/

[8] D. Firesmith, & B. Henderson-Sellers, “The OPEN Process Framework: An Introduction”. Harlow, Herts, UK: Addison-Wesley, 2002.

[9] G. Hadad, J. Doorn, & V. Ledesma, “Dynamic Situational Adaptation of a Requirements Engineering Process”. En M. Khosrow-Pour (ed), Encyclopedia of Information Science and Technology, Fourth Edition. Hershey, PA: IGI Global, Information Science Reference, ISBN: 9781522522553, pp.7422 – 7434, 2018.

[10] K. Kumar & R. Welke, “Methodology Engineering: a Proposal for Situation-Specific Methodology Construction”. W.W. Cotterman & J.A. Senn (Eds.), Challenges and strategies for research in systems development, John Wiley & Sons, pp. 257-269, 1992.

[11] B. Henderson-Sellers & J. Ralyté, “Situational Method Engineering: State-of-the-Art Review”. Journal of Universal Computer Science, 16(3): 424-478, 2010.

[12] B. Henderson-Sellers, J. Ralyté, P. Ågerfalk & M. Rossi, “Situational Method Engineering”. Springer-Verlag Berlin Heidelberg, 2014.

[13] A. Hallerbach, T. Bauer & M. Reichert, “Managing Process Variants in the Process Lifecycle”. Proceedings of 10th International Conference on Enterprise Information Systems, pp. 154-161. Barcelona, España, 2008.

[14] G. Hadad, J. Doorn & G. Kaplan, “Creating Software System Context Glossaries”. Encyclopedia of Information Science and Technology, Second Edition, Hershey. IGI Global, pp.789-794, 2009.

[15] G. Hadad, “Uso de Escenarios en la Derivación de Software”. Tesis Doctoral, Facultad de Ciencias Exactas, Universidad Nacional de La Plata, Argentina, 2008.

[16] G. Kaplan, J. Doorn & N. Gigante, “Evolución Semántica de Glosarios en los Procesos de Requisitos”. Memorias del XVIII Congreso Argentino de Ciencias de la Computación. Mar del Plata, Argentina, 2013.

[17] G. Hadad, J. Doorn & G. Kaplan, “Explicitar Requisitos del Software Usando Escenarios”. Proceedings of 12th Workshop on Requirements Engineering, Universidad Técnica Federico Santa María, pp. 63-74. Valparaíso, Chile, 2009 (b).

[18] S. Brinkkemper, “Method Engineering: Engineering of Information Systems Development Methods and Tools”. Information & Software Technology, 38(4): 275-280, 1996.

[19] H. Khan, M. bin Mahrin, & S. bt Chuprat, “Factors for Tailoring Requirement Engineering Process: A Review”. International Journal of Software Engineering and Technology, 1(1): 7-18, 2014.

[20] T. Bucher, M. Klesse, S. Kurpjuweit & R. Winter, “Situational Method Engineering. Situational method engineering: fundamentals and experiences”, Springer US, pp. 33-48, 2007.

[21] Ø. Haugen, B. Møller-Pedersen, J. Oldevik, G. Olsen, A. Svendsen, “Adding Standardized Variability to Domain Specific Languages”. Proceedings of the12th International Software Product Line Conference (SPLC 2008), vol. 1, pp. 139–148. IEEE Computer Society, Limerick, 2008.

[22] L. Jiang & A. Eberlein, “A Framework for Requirements Engineering Process Development” (FRERE). Proceedings of 19th Australian Conference on Software Engineering (ASWEC 2008), Perth, Australia, pp. 507-516, 2008.

[23] D. Zowghi, D. Firesmith & B. Henderson-Sellers, “Using the OPEN Process Framework to Produce a Situation-Specific Requirements Engineering Method”. Proceedings of 1st International Workshop on Situational Requirements Engineering Processes (SREP'05), Paris, Francia, pp.59-74, 2005.

[24] A. Hickey & A. Davis, “A Unified Model of Requirements Elicitation. Journal of Management Information Systems”. Information Systems Design- Theory and Methodology, 20(4): 65-84, 2004.

[25] C. Coulin, “A Situational Approach and Intelligent Tool for Collaborative Requirements Elicitation”. Tesis Doctoral, University of Technology. Sydney, Australia, 2007.

[26] D. Carrizo, O. Dieste & N. Juristo, “Study of Elicitation Techniques Adequacy”. Proceedings of 11th Workshop on Requeriments Engineering, Barcelona, España, pp. 104-114, 2008.

[27] A. Abdullah & H. Khan, “FreGsd: A Framework for Global Software Requirement Engineering”. Journal of Software, 10(10): 1189-1198, 2015.

[28] K. Bakhat, A. Sarwar, Y. Motla & M. Akhta, “A Situational Requirement Engineering Model for an Agile Process”. Bahria University, Journal of Information & Communication Technology, 8(1): 21-26, 2015.

[29] H. Khan, M. bin Mahrin & M. Mali, “Situational Requirement Engineering Framework for Global Software Development: Formulation and Design”. Bahria University Journal of Information & Communication Technologies, 9(1): 74-84, 2016.

[30] C. Coulin, D. Zowghi & A. Sahraoui, “A Situational Method Engineering Approach to Requirements Elicitation”. Workshops in the Software Development Process. Software Process: Improvement and Practice, 11(5): 451–464, 2006.

[31] O. Jafarinezhad & R. Ramsin, “Development of Situational Requirements Engineering Processes: A Process Factory Approach”. Proceedings of 36th IEEE International Conference on Computer Software and Applications, pp. 279-288, 2012.

[32] V. Ledesma, G. Hadad & J. Doorn, “Adaptación Dinámica de un Proceso de Requisitos Orientado al Cliente”. Proceedings of CONAIISI 2016, 4to Congreso Nacional de Ingeniería Informática / Sistemas de Información, ISSN: 2347-0372. Salta, Argentina, 2016.

[33] D. Rochowiak, “Extensibility and Completeness: An Essay on Scientific Reasoning”. The Journal of Speculative Philosophy, 2(4): 241-266, 1988.

[34] G. Cavanos, “Probabilidades y Estadística. Aplicaciones y métodos”, 1º edición. Mc. Graw Hill. ISBN: 968-451-856-0, 1988.

B. Bibliografía:

C. Rolland, “Method Engineering: Towards Methods as Services. Making Globally Distributed Software Development a Success Story”. Proceedings of International Conference on Software Process (ICSP 2008), pp.10–11, 2008.

J. Ralyté, “Situational Method Engineering in Practice: A Case Study in a Small Enterprise”. Proceedings of 25th International Conference on Advanced Information Systems Engineering, pp. 17-24, 2013.

L. Chen & M. Babar, Variability Management in Software Product Lines: An Investigation of Contemporary Industrial Challenges. Proceedings of the 14th International Conference on Software Product Lines: going beyond (SPLC 2010), pp. 166-180, 2010.

M. Galster, D. Weyns, D. Tofan, B. Michalik & P. Avgeriou, “Variability in Software Systems - A Systematic Literature Review”. IEEE Transactions on Software Engineering, 40(3): 282-306, 2014.

Ø. Haugen & O. Øgård, “BVR – Better Variability Results”. Proceedings of International Conference on System Analysis and Modeling: Models and Reusability (SAM 2014), Lecture Notes in Computer Science, vol. 8769, pp. 1-15, 2014.

T. Martínez-Ruiz, F., García, M. Piattini & J. Munch, “Modelling Software Process Variability: An Empirical Study”. IET Software, 5(2): 172-187, 2011.

E. Santos, J. Castro, J. Sánchez & O. Pastor, “A Goal-Oriented Approach for Variability in BPMN”. Proceedings of 13th Workshop on Requirements Engineering (WER’10), pp. 17-28, 2010.

A. Schnieders & F. Puhlmann, “Variability Mechanisms in E-Business Process Families”. Proceedings of 9th International Conference on Business Information Systems (BIS 2006), pp. 583-601, 2006.