Revista Tecnología y Ciencia - Universidad Tecnológica Nacional
ISSN 1666-6933 / Septiembre-Diciembre 2018 / Año 16 - Nº 33

Propuesta de Modelo de Proceso de Ingeniería Distribuida de Requisitos de Software

Gustavo Sevilla

Instituto de Informática, Facultad de Ciencias Exactas Físicas y Naturales, Universidad Nacional de San JuanArgentina
gsevilla@iinfo.unsj.edu.ar

Sergio Zapata

Instituto de Informática, Facultad de Ciencias Exactas Físicas y Naturales, Universidad Nacional de San JuanArgentina

Estela Torres

Instituto de Informática, Facultad de Ciencias Exactas Físicas y Naturales, Universidad Nacional de San JuanArgentina

Fáber Giraldo

Departamento de Ingeniería en Computación, Universidad del Quindío Armenia, Colombia
fdgiraldo@uniquindio.edu.co

Presentación 18/11/2016
Aprobación 20/07/2017

Resumen

Los escenarios de Desarrollo Global de Software, donde los actores del proceso están dispersos geográficamente, crecen a diario en muchas partes del mundo, incluso en Latinoamérica. Este nuevo entorno impacta sobre el desempeño de los métodos y las herramientas usadas en los procesos tradicionales de desarrollo de software. Debido al alto flujo de comunicación humana que requiere, el proceso de ingeniería de requisitos es fuertemente afectado por las características particulares de estos nuevos escenarios globales. Basado en estudios experimentales, este artículo presenta un modelo de proceso de ingeniería de requisitos para desarrollo de software distribuido que contempla tanto técnicas de elicitación como así también herramientas de comunicación.

Palabras clave: Desarrollo Gobal de Software, Ingeniería Distribuida de Requisitos de Software, Proceso de Software

Abstract

Global software development settings, where stakeholders are geographically distributed, grow on all world, including Latin American. These novel work environments impact on performance of traditional methods and tools used in software development. Software requirements process is strongly affected by these global settings because this process involves a lot of human communications which are harmed by geographical distance. Grounded in experimental studies this article presents a software requirements engineering process model to distributed software development. This model includes elicitation techniques and communication tools.

Keywords: Global Software Development, Distributed Software Requirements Engineering, Software Process

Introducción

El proceso de desarrollo de software tiende, cada vez con mayor énfasis, a ser distribuido o global, donde los participantes se encuentran dispersos geográficamente. A esta moderna forma de trabajo se la denomina Desarrollo Global de Software (DGS). Varias razones han impulsado este escenario: reducción de costos, mejor aprovechamiento global de la escasa disponibilidad de recursos humanos, mayor cantidad de horas de trabajo disponibles en función de las distintas zonas horarias, incentivos a la inversión en mercados emergentes y crecimiento significativo de la demanda mundial en software (Herbsleb and Moitra, 2001).

Es aceptable sostener que estos nuevos contextos impactarán en la forma en que se desarrolla software, especialmente en aquellas etapas del proceso de desarrollo de software donde hay exigencias de mayor comunicación y colaboración entre los miembros del equipo de trabajo distribuido. Así, los procesos, técnicas y herramientas de construcción de software aplicadas a tradicionales escenarios colocalizados deben ser revisados para constatar su efectividad en los nuevos ambientes globales. El término colocalizado hace referencia a la cualidad de presencialidad de todos los involucrados en una misma localización.

Hay aún un significativo conocimiento que debe ser alcanzado, métodos y técnicas que deben ser desarrolladas y prácticas que deben evolucionar para que el DGS se transforme en una disciplina madura (Damian and Moitra, 2006).

Se conoce que el éxito de un proyecto de software depende en gran medida de una correcta ejecución del proceso de Ingeniería de Requisitos de Software (IRS). Tener una correcta definición de los requisitos de software es clave para obtener un producto de calidad que satisfaga las necesidades y expectativas del cliente/usuario. La necesidad de contar con un proceso de IRS dentro del proceso ingeniería de software es imprescindible para obtener productos de calidad (Durán, 2000). Así mismo, la calidad de los requisitos mejora en la medida que hay mayor participación de las personas involucradas. Esta participación se dificulta cuando el proceso de IRS se realiza en un entorno distribuido de desarrollo, es decir, cuando los actores están geográficamente dispersos. Por ello la IRS en ambientes distribuidos necesita de un adecuado modelo de proceso que promueva y facilite la colaboración efectiva y eficiente de los involucrados, siendo las técnicas de elicitación y las herramientas de comunicación elementos claves para servir a este propósito.

El presente trabajo focaliza su objetivo en la propuesta de un modelo de proceso para IRS aplicable a contextos distribuidos de desarrollo de software, basado en el uso de herramientas de comunicación y de técnicas de elicitación, específicamente definido para pequeñas empresas productoras de software de gestión. Esta propuesta está fundamentada en trabajos experimentales realizados con dicho propósito.

Ingeniería de Requisitos de Software Distribuida

La Ingeniería de Requisitos de Sistemas de Software (IRS) es el proceso de identificación de los stakeholders y sus necesidades, documentando esto en una forma que sea susceptible de análisis, comunicación y posterior implementación (Nuseibeh and Easterbrook, 2000).

El proceso de IRS es un ciclo repetitivo en forma de espiral, que comprende cuatro etapas: educción (elicitación), análisis y negociación, especificación y validación de requisitos (Kotonya and Sommerville, 1998).

También en (Thayer, 1998) se define la IRS en función de cuatro componentes o fases: Elicitación, Análisis, Especificación y Validación.

En (Pressman, 2010) se describe que la IRS se desarrolla en las etapas de: concepción, indagación, elaboración, negociación, especificación, revisión-validación y administración.

Analizando las anteriores descripciones sobre las etapas o actividades de la IRS dadas por diferentes autores e intentando resumirlas en una sola, definimos las siguientes etapas dentro del proceso de IRS:

• Elicitación: comprende la obtención (captura, descubrimiento y adquisición) de requisitos.
• Análisis y Negociación: busca alcanzar acuerdos y/o entendimientos entre todos los participantes sobre los requisitos.
• Especificación: es la representación detallada de los requisitos.
• Validación: busca que los requisitos documentados se correspondan con las necesidades de los interesados y comprueba que la especificación cumpla criterios de calidad.

La IRS, reconocida como una fase crítica en la Ingeniería de Software, presenta nuevas dificultades en los entornos distribuidos, además de aumentar o potenciar las ya existentes (Damian, 2002). Las deficiencias en la comunicación entre ingenieros de requisitos y usuarios-clientes, las diferencias culturales y organizacionales, las dificultades para generar confianza mutua y resolver conflictos son algunos de los principales problemas identificados (Zowghi and Coulin, 2005). Todo esto apoya la necesidad planteada en (Zowghi, 2002) de un proceso para requisitos que solucione los problemas del desarrollo distribuido.

Experimentos controlados y análisis estadístico de encuesta

El modelo de proceso propuesto surge en función de experimentos controlados, realizados por los autores, que ofrecen evidencias respecto de las más eficientes técnicas de elicitación y mejor uso de las herramientas de comunicación aplicadas en escenarios distribuidos, específicamente donde el cliente/usuario y el ingeniero de requisitos se encuentran dispersos geográficamente.

Es muy importante destacar que las experimentaciones realizadas se hicieron en un contexto universitario y bajo características similares a pequeñas empresas desarrolladoras de software, las cuales constituyen la amplia mayoría de la industria del software en América Latina. De manera que los resultados y propuestas del presente artículo deben ser analizados bajo esa premisa. Si bien en los experimentos participaron estudiantes avanzados la mayoría de ellos tenían moderada experiencia en el desarrollo de software en la industria.

Se expone a continuación un resumen de dos experimentos realizados con las características mencionadas y que dan soporte al modelo de proceso propuesto.

Elicitación Distribuida de Requisitos de Software: un caso experimental entre Argentina y Colombia

En este experimento se pretendió adquirir un conocimiento más acabado de la etapa de elicitación distribuida de requisitos de software (Zapata et al., 2013), a partir de los conocimientos ya existentes del mismo proceso en escenarios de elicitación colocalizados (presenciales), siendo aquel el foco de investigación del trabajo.

En forma conjunta con profesores de la Universidad Nacional de San Juan (UNSJ) de Argentina, de la Universidad del Cauca de Colombia y de la Universidad de Quindío de Colombia, se ejecutó un experimento controlado con dos factores: contexto de elicitación (distribuido/colocalizado) y técnicas de elicitación utilizadas (3 distintas combinaciones de técnicas). Así, se ejecutaron dos fases experimentales similares, la primera aplicada a un contexto distribuido de desarrollo de software; mientras que la segunda se aplicó en un contexto tradicional colocalizado. El diseño experimental finalmente fue un diseño factorial 2x3 como se muestra en la Tabla 1.

Las técnicas de elicitación utilizadas en este experimento son las más usadas en pequeñas empresas de desarrollo de software de Argentina: entrevista, cuestionario y brainstorming (Antonelli and Oliveros, 2002), algo que también se verifica en toda Latinoamérica. Entendiendo que en situaciones reales se usan combinaciones de técnicas en el proceso de elicitación, se definieron tres alternativas (factores) de combinación de técnicas para experimentar: entrevista/cuestionario, entrevista/brainstorming y entrevista exclusivamente.

Alumnos avanzados de las distintas universidades mencionadas jugaron el rol de ingenieros de requisitos, mientras que profesores hacían las veces de clientes/usuarios remotos.

Tabla 1 - Diseño Experimental Con 2 Factores

Los ingenieros de requisitos, conformando equipos de elicitación, debían elaborar un documento de requisitos de software (DRS) como producto final de su trabajo, tal documento sería posteriormente objeto de medición de calidad. Para obtener el DRS los ingenieros de requisitos tuvieron un documento descriptivo inicial que exponía una visión general y preliminar del problema, y a partir del mismo debían aplicar la combinación de técnicas de elicitación, asignadas aleatoriamente a cada equipo de elicitación, hasta obtener el documento DRS definitivo. Para lograr el objetivo debían interactuar con el cliente/usuario del sistema a desarrollar.

Los investigadores que diseñaron el experimento elaboraron, previo a la ejecución del mismo y en conjunto con profesores expertos, un Documento de Requisitos Básicos (DRB) el cual contenía todos los requisitos de software necesarios para satisfacer adecuadamente el desarrollo del sistema solicitado. Este documento, que fue elaborado y validado por profesores expertos, sería utilizado posteriormente como referencia para la evaluación de los DRS producidos por los estudiantes.

Con el objeto de medir la calidad del DRS resultante y que tal medición sea un indicador de la efectividad de la técnica de elicitación aplicada, se eligió la métrica utilizada en (Lloyd et al., 2002), (Lloyd, 2001), ajustándola para este caso experimental particular. De esta manera la métrica usada en el presente experimento involucró 4 sub-indicadores a medir:

• Nivel de adecuación general del documento (NAD): mide aspectos de la organización del documento que surgen como consecuencia de la acción de elicitación. Por ejemplo clasificación de requisitos por orden de importancia, viabilidad y/o esfuerzo de implementación. Este indicador toma valores entre 1 y 100.
• Porcentaje de requisitos evoluciona-dos (RE): mide el porcentaje de requisitos del DRS que se identifican como una evolución de un requisito de software que ya se encontraba en el DRB. Son los requisitos que necesitaron una elicitación más profunda y minuciosa; que evidencian una interacción más rica y efectiva entre ingeniero de requisitos y cliente/usuario.
• Porcentaje de requisitos sin defecto (RSD): mide el porcentaje de requisitos que no tienen defectos de precisión, vaguedad, ambigüedad, etc. Es decir, defectos atribuibles a deficiencias en el proceso de elicitación.
• Porcentaje de requisitos soportados (RS): porcentaje de requisitos que estando en el DRB también se encuentran en el DRS producido por los ingenieros de requisitos. Este sub-indicador está relacionado con la completitud del DRS producido. Este indicador es el que mejor representa un proceso de elicitación exitoso. En caso que este indicador alcance el 100% indica que se descubrieron todos los requisitos necesarios para la aplicación en desarrollo.

Componiendo estos cuatro subindicado-res, cada uno con ponderaciones diferentes como se aprecia en (1), se obtuvo el indicador de calidad del documento (CDRS) que indirectamente refleja la efectividad de las técnicas de elicitación aplicadas.

CDRS=(0.05 NAD+0.3 RE+0.25 RSD+0.4 RS) (1)

Los sub-indicadores RE y RS son los que mejor reflejan la efectividad de un proceso de elicitación, es por ello que tienen mayor ponderación en el indicador CDRS.

Al finalizar el experimento, y en función de los sub-indicadores definidos, un grupo de profesores expertos, externos al experimento, evaluó y calificó los documentos DRS producidos por los distintos grupos de elicitación. Este proceso consistió en evaluar cada documento DRS presentado por los grupos de alumnos tomando como referencia el documento DRB elaborado por los investigadores y la métrica definida en (1). Es importante destacar que previo a comenzar la evaluación se llevó a cabo una reunión con los expertos a fin de aunar criterios para la asignación de valores a cada uno de los sub-indicadores. La evaluación la hizo un grupo de 4 profesores expertos, quienes primero realizaron una revisión individual y luego una revisión grupal en donde acordaron el valor final CDRS de cada documento DRS.

En la fase experimental ejecutada en ambiente distribuido, participaron 22 estudiantes y 6 profesores. Los alumnos fueron distribuidos en forma aleatoria en 11 grupos de dos estudiantes cada uno, conformando cada grupo un equipo de elicitación. A su vez, a cada grupo le fue asignado aleatoriamente un profesor que jugaría el rol de cliente/usuario para tal equipo de elicitación. También, en forma aleatoria, se le asignó a cada grupo una de las tres combinaciones de técnicas seleccionadas para este experimento. De esta forma se conformaron 4 grupos de elicitación que aplicaron la técnica entrevista, 4 grupos que aplicaron la combinación entrevista-cuestionario y finalmente 3 grupos aplicaron Entrevista-Brainstorming.

Con el fin de simular el ambiente distribuido, en todo momento la comunicación entre ingenieros de requisitos y cliente/usuario fue mediante emails, chat o videoconferencia IP, quedando ambas partes en libertad de optar por la aplicación específica de su preferencia. En ningún momento los ingenieros de requisitos y los clientes/usuarios interactuaron cara a cara.

En función de la técnica de elicitación aplicada se utilizaron distintas herramientas de comunicación.

Para entrevista y brainstorming los sujetos prefirieron usar videoconferencia, mientras que para cuestionario principalmente email y en menor medida chat. Se utilizaron aplicaciones de comunicación estándares de propósito general por entender que éstas son las más ampliamente difundidas y las de mayor preferencia para pequeñas empresas de software que por primera vez se enfrentan a la construcción de software distribuido o global.

Esta fase del experimento tomó aproxi-madamente diez días en llevarse a cabo.

En la Tabla 2 se muestra los resultados obtenidos por cada grupo respecto a la calidad de los documentos de requisitos resultantes.

Tabla 2 - Resultados Fase Experimental Distribuida

En la fase experimental ejecutada en ambiente colocalizado, participaron 18 alumnos avanzados conjuntamente con 5 profesores.

De igual manera, que en la fase anteriormente descripta, los alumnos fueron distribuidos en 9 grupos, de tal forma que finalmente quedaron conformados 3 grupos de elicitación que aplicaron la técnica entrevista, 3 grupos aplicaron la combinación entrevista-cuestionario y finalmente 3 grupos aplicaron entrevista-brainstorming.

La comunicación entre ingenieros de requisitos y usuarios-clientes fue en todo momento presencial. Aproximadamente 10 días insumió la ejecución de esta fase. En la Tabla 3 se muestra los resultados obtenidos por cada grupo de estudiantes discriminando los resultados de cada uno de los 4 sub-indicadores (NAD, RE, RSD y RS).

Tabla 3 - Resultados Fase Experimental Colocalizada

En Tabla 4 y Tabla 5 se pueden ver los resultados promedios de los CDRS agrupando los mismos por técnicas de elicitación aplicadas en los dos procesos de elicitación realizados, es decir distribuido y colocalizado respectivamente.

Los datos experimentales obtenidos sugieren que la combinación de técnicas más efectiva en un contexto distribuido sería Entrevista-Cuestionario, la cual alcanza un nivel de efectividad que supera en un 9% a la siguiente combinación de técnicas más efectiva, que fue entrevista-brainstorming. También se advierte que la técnica Entrevista, usada en forma única, es la menos efectiva de las técnicas evaluadas en este contexto distribuido.

Tabla 4 - Resultados Promedios Fase Distribuida

Tabla 5 - Resultados Promedios Fase Colocalizada

Además, según los resultados preliminares obtenidos se puede advertir que en estos nuevos escenarios distribuidos la eficacia promedio de las técnicas tradicionales de elicitación sería un 10% menor que el promedio de esas mismas técnicas aplicadas en ambientes colocalizados.

Uso de Wiki en Ingeniería de Requisitos de Software bajo contextos distribuidos

Esta experiencia (Sevilla et al., 2014) expone un experimento controlado realizado para evaluar el desempeño de una Wiki, específicamente diseñada para el proceso de IRS, en escenarios distribuidos de desarrollo de software. La wiki utilizada fue Softwiki, proyecto financiado por el Ministerio de Educación e Investigación del Gobierno Alemán y apoyado por las universidades de Duisburg-Essen y Leipzig. El estudio evidenció que en un contexto distribuido y mediante el uso de una herramienta wiki se obtiene un Documento de Requisitos de Software con mayor precisión.

Este experimento se realizó en un contexto universitario, en donde los sujetos del experimento fueron estudiantes avanzados y profesores de la carrera de grado en Ciencias de la Computación de la Universidad A. Se conformaron 9 grupos o equipos de IRS integrados por dos estudiantes (cumpliendo el rol de ingenieros de requisitos) cada uno, más un profesor que hacía las veces de cliente/usuario. El escenario de trabajo fue distribuido, los ingenieros de requisitos estaban remotamente ubicados respecto del cliente/usuario. La asignación de alumnos a los grupos fue aleatoria, teniendo en cuenta que los alumnos tenían perfiles de conocimiento y experiencia previa similares. Igualmente aleatoria fue la asignación de profesores.

Con el fin de simular el ambiente distribuido, en todo momento la comunicación entre ingenieros de requisitos y clientes/usuarios se realizó por email, chat, videoconferencia o wiki, en ningún momento hubo interacción cara a cara.

En el marco del experimento ejecutado, los ingenieros de requisitos, rol asignado a alumnos, tuvieron que elicitar información respecto de los requisitos del software a implementar. Para ello interactuaron con el cliente, rol asignado a un profesor. El software a desarrollar, objeto del proceso de IRS, fue un sistema de información de tamaño pequeño/mediano destinado a la gestión de información administrativa. El mismo problema fue planteado a todos los grupos de IRS que participaron en el experimento. La información elicitada fue registrada en la wiki y convertida progresiva y cooperativamente en requisitos de software bien formulados.

Al comenzar el experimento se les proveyó, a los ingenieros de requisitos, de un documento descriptivo inicial que exponía una visión vaga y general del problema, y a partir del mismo debían comenzar con el proceso de ingeniería de requisitos hasta obtener un documento de requisitos de software (DRS) definitivo, usando las herramientas de comunicación mencionadas. Los ingenieros de requisitos especificaron en la herramienta wiki, junto al cliente los requisitos funcionales y no funcionales del DRS, documento que sería posteriormente objeto de medición de calidad.

En cuanto a la única técnica de elicitación de requisitos empleada en este estudio, se escogió una de la más usada en pequeñas empresas de software de Argentina, entrevista (Antonelli and Oliveros, 2002).

Previo a la ejecución del experimento el equipo de investigación elaboró un Documento de Requisitos de Software de Referencia (DRSR), el cual contenía todos los requisitos de software necesarios para satisfacer adecuadamente el desarrollo del sistema solicitado. Este DRSR sería utilizado posteriormente como referencia para las evaluaciones de los DRS producidos por los ingenieros de requisitos de cada grupo.

Para comprobar el aporte del uso de la wiki en obtener un DRS de mayor calidad, se consideraron solamente tres atributos de calidad del DRS, Completitud, No Ambigüedad y Precisión. Para satisfacer estos atributos es necesaria una interacción reflexiva (de respuestas meditadas, no instantáneas) y basada en un soporte textual (para analizar ambigüedad y precisión principalmente) entre los ingenieros de requisitos y los clientes. Estás características hacen pensar que las wikis serían una herramienta válida para ese proceso. Con este fin se procedió a utilizar tres indicadores para estos atributos:

• El Indicador de Completitud del DRS (q1) determina el grado en que los requisitos presentes en el DRSR están soportados en el DRS del grupo, el resultado es una proporción (valores entre 0 y 1). A medida que este valor se acerque a 1 mayor es el grado de completitud.
• El Indicador de No ambigüedad de los Requisitos (q2) determina el grado de no ambigüedad de los requisitos del DRS, el resultado es una proporción entre los requisitos evaluados como no ambiguos y el total de requisitos del DRS. A medida que este valor se acerque a 1, mayor es el grado de no ambigüedad del DRS producido.
• El Indicador de Precisión de los Requisitos (q3) determina el grado de precisión de los requisitos del DRS, el resultado es una proporción entre los requisitos evaluados como precisos y el total de requisitos del DRS. A medida que este valor se acerque a 1 mayor es el grado de precisión del DRS producido.

Un grupo de profesores expertos de la UNSJ, ajenos al experimento, evaluó los DRS producidos por los alumnos a los fines de determinar estos indicadores. Con antelación a la evaluación se reunió a los expertos para acordar y unificar los criterios de ponderación y valoración de cada uno de los indicadores.

En la Tabla 6 se muestran los resultados obtenidos por cada grupo de IRS respecto de tres atributos de calidad del Documento de Requisitos de Software: completitud, ausencia de ambigüedad y precisión.

Otro índice medido es el grado o nivel de uso de la herramienta wiki que hizo cada grupo. Este índice se obtuvo de los registros de logs propios de la herramienta wiki.

Tabla 6 - Resultados Obtenidos

Haciendo un análisis de correlaciones entre el Índice de Uso de Wiki y cada uno de los indicadores q1, q2 y q3 se pueden arribar a diversas conclusiones o indicios. Así resultó que no hay indicios que el mayor uso de wiki promueva documentos de requisitos más completos y con menor ambigüedad en ambientes distribuidos. Sin embargo, hubo un alto nivel de correlación entre el Índice de Uso de Wiki y q3, lo que despierta la sospecha que el mayor uso de wiki mejora la precisión del DRS.

En la Tabla 7 se puede apreciar el uso de las herramientas de comunicación en los distintos días que se realizó el experimento, consolidando los datos de todos los grupos de IRS. En la columna Emails se registra la cantidad de correos electrónicos intercambiados entre ingenieros de requisitos y clientes/usuarios. En la columna Versiones Wiki se contabilizan el total de nuevas versiones de requisitos registradas en la herramienta wiki por cada día del experimento.

En la próxima columna denominada Comentarios Wiki se contabilizan el total de comentarios relacionados a los requisitos que fueron registrados, en la herramienta wiki, por los ingenieros de requisitos y los clientes/usuarios.

Estas dos últimas columnas dan evidencia del uso de la wiki.

Finalmente, la columna VC contabiliza los minutos totales de uso de la herramienta de comunicación videoconferencia.

Se debe tener en cuenta que los primeros 4 días fueron ocupados por actividades de interacción inicial (presentación, aproximación, etc.) entre las partes.

Tabla 7 - Uso de Herramientas de Comunicación por Día

En ese periodo inicial se acordó la realización de la primera entrevista, es por ello que se puede decir que la actividad de elicitación realmente comenzó sobre el quinto día.

Teniendo en cuenta lo anterior se infiere de la observación de la Tabla 7 que las videoconferencias han sido realizadas principalmente en los primeros tramos del proceso de IRS.

Esto apoya la hipótesis que esta herramienta de comunicación se usa principalmente para comenzar el abordaje general del problema, intentando ser una opción para determinar las generalidades del problema, su alcance, sin profundizar en detalles del mismo.

A diferencia de las videoconferencias, se advierte que la actividad en la herramienta wiki se concreta con mayor énfasis en los tramos finales del proceso de IRS.

Esto abona la creencia que la wiki es una herramienta que ayuda en la búsqueda de precisión de los requisitos de software, acción que generalmente se ejecuta justamente al final del proceso de requisitos de software.

La actividad de intercambio de emails es la única que mantiene al menos una actividad moderada durante todo el proceso de IRS. Es probable que lo anterior se deba a que esta herramienta se usa como medio de comunicación de acciones de sincronización de tareas entre los ingenieros de requisitos y clientes/usuarios (contacto inicial, avisos de transferencia de control de tareas, pedidos de validación de tareas, acuerdo final respecto de documento de requisitos, etc.) estando estas acciones presentes durante todo el proceso de IRS.

Análisis Estadístico de la Encuesta

A los fines de medir la Facilidad de Uso y la Eficacia de la herramienta wiki empleada en el último experimento se realizo una encuesta anónima a los Ingenieros de Requisitos de cada Grupo.

La encuesta se definió siguiendo los lineamientos de (Hayes, 2000), con posibilidad de probar estadísticamente la fiabilidad del mismo, teniendo en cuenta el proceso de generación de encuestas como en otros trabajos realizados para medición de la satisfacción (Lund et al., 2000).

Se seleccionó el formato de respuesta tipo Likert (Likert, 1932), que permite que los alumnos contesten en grados variables a cada artículo, de acuerdo a una escala.

Este formato es considerado más adecuado porque es cuantitativo a la hora de valorar las respuestas de los alumnos.

La escala seleccionada en esta oportunidad es la siguiente:

1. Estoy absolutamente en desacuerdo con el enunciado.
2. Estoy en desacuerdo.
3. No estoy en acuerdo ni en desacuerdo.
4. Estoy de acuerdo.
5. Estoy completamente de acuerdo con el enunciado

Tres enunciados de la Encuesta se agruparon para representar la dimensión Facilidad de Uso y otros dos para representar la dimensión Eficacia.

Cada dimensión fue resumida en una variable, que es la mediana de los resultados que integran cada bloque ya que la mediana es una medida de tendencia central más resistente a los valores extremos.

Luego se realizó un análisis estadístico descriptivo para cada dimensión.

Facilidad de Uso este bloque abarcó los enunciados 1 al 3 de la encuesta, los cuales se presentan a continuación:

1. Me resultó fácil de usar la Herramienta Wiki empleada para la ER.

2. Considero que la Herramienta Wiki requiere poco esfuerzo para aprender a utilizarla

3. Me llevó poco tiempo completar los requisitos en la Herramienta Wiki.

Estos ítems se resumieron en una nueva variable denominada Facilidad de Uso, la cual fue encontrada como la mediana entre los enunciados que integran el bloque.

Se presenta la Tabla 8 de frecuencias y en la Figura 1 el gráfico de barras que muestra la distribución de la variable resumen de este bloque (o dimensión).

En general, los resultados obtenidos son altamente satisfactorios ya que el 100% de los valores es mayor o igual a 4.

Tabla 8 - Tabla de frecuencias de Facilidad de Uso

Figura 1- Gráfico de barras de Facilidad de Uso

Eficacia este bloque comprende los enunciados 4 y 5 de la encuesta, los cuales se presentan a continuación:

4. La Herramienta Wiki me ayudó a obtener una Especificación de Requisitos de Software (ERS) que considero correcta.

5. El Glosario de Términos en la Herramienta wiki me dio más entendimiento del dominio del problema.

Se muestra a continuación la Tabla 9 de frecuencias y en la Figura 2 el gráfico de barras que muestra la distribución de la variable.

Tabla 9 - Tabla de frecuencias de Eficacia

Figura 2 - Gráfico de barras de Eficacia

Resultados y discusión

En esta sección se expone un análisis integrado de los resultados de los experimentos realizados y descriptos en la sección anterior, como así también de la encuesta.

En el primer experimento se advierte que las técnicas de entrevista combinada con la técnica de cuestionario son una alternativa efectiva para ambientes de IRS donde el cliente/usuario y el ingeniero de requisitos se encuentran distantes geográficamente. Se advierte que las entrevistas fueron usadas al comienzo del proceso de elicitación de requisitos, cuando una noción más general de las necesidades del cliente/usuario, respecto del sistema a desarrollar, se requería. Mientras que la técnica de cuestionario fue utilizada con el fin de obtener información más específica o focal.

Los hallazgos mencionados del primer experimento son compatibles con los encontrados en el segundo. En este último caso, además de evidenciar que las herramientas wiki ayudan a obtener un documento de requisitos más preciso también se observa que las videoconferencias son usadas en el comienzo del proceso de IRS, que la wiki alcanza su mayor uso hacia el final del proceso y que finalmente los emails se usan durante todo el proceso, principalmente para comunicar actividades de coordinación entre los actores remotamente ubicados.

En lo que respecta al análisis de los datos de la encuesta referentes a la Facilidad de Uso vemos que en general, los resultados obtenidos son altamente satisfactorios ya que el 100% de los valores es mayor o igual a 4. En lo que respecta a Eficacia en general, los resultados obtenidos presentan sesgo desde el valor 3,5 a la derecha y el 56,3% de los valores es mayor o igual a 4.

En función de las evidencias experimentales obtenidas, respecto a técnicas de elicitación y herramientas de comunicación usadas, se propone en este artículo un modelo de proceso para ingeniería de requisitos de software en un escenario donde el cliente/usuario se encuentra remotamente ubicado respecto del ingeniero de requisitos. El modelo de proceso propuesto se puede observar en la Figura 3.

Figura 3 - Modelo de proceso de IRS Distribuida

Se debe destacar que la propuesta está orientada a pequeñas empresas de desarrollo de software dedicadas a la producción de sistemas de gestión, condiciones que se establecieron para la ejecución de los experimentos realizados.

El modelo de proceso propone, basada en las experiencias realizadas, el uso de técnicas de elicitación y herramientas de comunicación en cuatro diferentes fases del proceso de IRS.

En la propuesta se intenta mantener una continua interacción con el cliente/usuario durante todo el proceso, teniendo el mismo distinto grado de protagonismo en las distintas fases.

En este sentido, la wiki, específicamente configurada para el proceso de IRS, es una herramienta de comunicación y repositorio donde se registran los avances del proceso, concretamente los requisitos de software establecidos con sus comentarios asociados. La wiki es accedida tanto por el ingeniero de requisitos como por el cliente/usuario. La información que se genera en cada fase del proceso se almacena en la wiki que da soporte al modelo de proceso.

El modelo de proceso establece que para la primera fase, Elicitación, se use primeramente la técnica entrevista por medio de videoconferencia. Esta primera aproximación entre cliente/usuario e ingeniero de requisitos tiene por objeto obtener una definición general, no precisa, del problema a resolver. Es por ello que, como muestran los experimentos, las entrevistas no estructuradas son adecuadas para esta fase. Para ello la videoconferencia es una herramienta de comunicación de relativa alta riqueza comunicacional que soporta adecuadamente una entrevista remota. A medida que se avanza en el conocimiento del problema se puede hacer uso de cuestionarios para obtener mayor precisión, los mismos pueden gestionarse apropiadamente por medio de una herramienta de comunicación asincrónica como el correo electrónico o herramientas web de uso específico para cuestionario, por ejemplo Google Forms.

La segunda fase del proceso, Análisis y Negociación, tiene por objeto analizar claridad, pertinencia y viabilidad técnica de los requisitos de software. Para ello es necesario interactuar con el cliente/usuario para negociar aspectos relativos a esfuerzo y factibilidad técnica de la implementación de los requisitos. En esta fase pueden utilizarse entrevistas por medio de videoconferencias. Como en todas las fases los avances en cuanto a definición de requisitos de software son registrados en el Repositorio Wiki.

Al final de esta segunda fase es cuando la herramienta wiki como medio de comunicación asincrónico entre cliente/usuario e ingeniero de requisitos comienza a tomar preponderancia.

En la fase de Especificación se tiene como meta establecer un conjunto de requisitos de software bien formulados, es decir con los atributos de calidad suficientes para asegurar el éxito de las etapas posteriores del proceso de desarrollo de software. El modelo de proceso propone el uso de la herramienta wiki en esta fase, con ella el ingeniero de requisitos puede revisar y editar los requisitos para mejorar su calidad, mientras que el cliente/usuario puede verificar, modificar y validar los cambios. En esta fase, comienza un tipo de interacción asincrónica, textual, reflexiva y focal entre las partes, por lo cual las videoconferencias dejan de ser tan útiles, transformándose la wiki en la herramienta adecuada.

Esta fase requiere un trabajo más detallado sobre los requisitos especialmente para otorgarles precisión a los mismos. Es acá donde la herramienta wiki aporta gran beneficio, como lo evidencian los datos experimentales mencionados en este trabajo.

Finalmente, en la fase de Validación ambas partes del proceso, cliente/usuario e ingeniero de requisitos, validan el conjunto de requisitos de software identificados y expuestos claramente en el Repositorio Wiki, nuevamente esta herramienta apoya estas tareas de revisión y validación integral.

A partir de las evidencias experimentales expuestas en este trabajo se propone que la comunicación asincrónica que proveen los emails sea utilizada durante todo el proceso de IRS, en todas las fases. Normalmente los emails soportan intercambio de mensajes de planificación y coordinación entre las partes del proceso, por ejemplo de solicitud de videoconferencia, de aviso de conclusión de actividades, de alarmas de vencimiento de tareas, de difusión de aspectos relacionados con el avance del proyecto, etc. Es por esa razón que el uso de emails aparece durante todo el proceso.

Al final del proceso, en el Repositorio Wiki permanecerá registrado el conjunto de requisitos de software que conformarán el núcleo del DRS del sistema.

Conclusiones

Los escenarios de desarrollo global de software son cada vez más aplicados en la industria internacional. Una de las etapas del desarrollo de software que se ve más afectada por estos nuevos escenarios, debido a su alta interactividad entre stakeholders, es el proceso de ingeniería de requisitos de software.

En este trabajo, y en función de experimentos controlados realizados por los autores, se plantea un modelo de proceso de IRS para escenarios distribuidos, en donde el cliente/usuario y el ingeniero de requisitos se encuentran distantes geográficamente.

El modelo de proceso propuesto establece las técnicas de elicitación y las herramientas de comunicación más apropiadas para estos contextos distribuidos. El modelo involucra especialmente el uso de wiki como una forma de comunicación asincrónica entre los actores del proceso y especialmente como una práctica que mejora la calidad de los requisitos de software encontrados.

Si bien los sujetos que participaron en las experimentaciones fueron estudiantes, los mismos tenían experiencia en la industria de desarrollo de software. Resultados experimentales indican que los estudiantes tienen un buen entendimiento de la forma en que la industria trabaja en el contexto de selección de requisitos de software, de manera que los estudiantes pueden trabajar correctamente como sujetos en estudios empíricos en esta área (Svahnberg et al., 2008). Adicionalmente, estudios exponen que la experiencia influye de modo relativamente reducido en la eficacia del proceso de ingeniería de requisitos (Agarwal and Tanniru, 1990), (Marakas and Elam, 1998).

Se debe destacar que la propuesta está ceñida a pequeñas empresas de software desarrolladoras de sistemas de gestión. No es posible la generalización de este modelo de proceso a otros contextos u otras condiciones, no sería apropiado. Es necesario que la propuesta tenga validaciones adicionales, más allá de las evidencias experimentales obtenidas, lo cual probablemente provocará una mejora de la misma.

Referencias

Herbsleb, J. D. y Moitra, D. (2001). “Global software development” en IEEE Software, 18(2): 16–20.

Damian, D. y Moitra, D. (2006). “Global Software Development: How Far Have We Come?”, IEEE Software, 23(5): 17–19.

Durán, A. (2000). “Un entorno metodológico de Ingeniería de Requisitos para Sistemas de Información” Tesis Doctoral, Universidad de Sevilla.

Nuseibeh, B. y Easterbrook, S. (2000). "Requirements engineering: a roadmap", Proceedings of the Conference on the Future of Software Engineering, ACM.

Kotonya, G. y Sommerville, I. (1998). Requirements engineering: processes and techniques. London: John Wiley & Sons.

Thayer, R. (1998). "Software Engineering Project management" en IEEE Computer Society.

Pressman, R. (2010). Ingeniería del software. Un enfoque práctico. Mc Graw Hill, Séptima edición.

Damian, D. (2002). “The study of requirements engineering in global software development: as challenging as important” en ICSE – International Workshop on Global Software Development, Florida.

Zowghi, D. y Coulin, C. (2005). "Requirements Elicitation: A Survey of Techniques, Approaches, and Tools" en Engineering and Managing Software Requirements. Springer-Verlag: 19-46.

Zowghi, D. (2002). "Does Global Software Development Need a Different Requirements Engineering Process?" en ICSE'2002 - International Workshop on Global Software Development, Orlando, Florida.

Zapata, S., Torres, E., Sevilla, G., Aballay, L. y Reus, M. (2013). "Eficacia de Técnicas Tradicionales de Elicitación de Requisitos de Software Aplicadas en Escenarios Distribuidos de Desarrollo de Software" en Conferencia Latinoamericana de Informática, Simposio de Ingeniería de Software.

Antonelli, L. y Oliveros, A. (2002). “Fuentes Utilizadas por Desarrolladores de Software en Argentina para Elicitar Requerimientos”, 5th Workshop on Requirement Engineering: 106–116.

Lloyd, W. J., Rosson, M. B. y Arthur, J. D. (2002). “Effectiveness of Elicitation Techniques in Distributed Requirements Engineering” en Proceedings of the IEEE Joint International Conference on Requirements Engineering.

Lloyd, W. J. (2001). “Tools and Techniques for Effective Distributed Requirements Engineering: An Empirical Study”, (Masters) Thesis, Virginia Tech.

Sevilla, G., Zapata, S., Torres, E. y Collazos, C. (2014). “Using Wikis as Collaborative Strategy to Support Software Requirements Elicitation” en 9th Colombian Computing Congress.

Hayes, B. E. (2000). Como medir la Satisfacción del Cliente: Diseño de Encuestas, Uso y Métodos de Análisis Estadístico. México: Alfaguara.

Lund M. I., Zapata S., Herrera M. (2000). “Proposal to Measure Software Customers Satisfaction” en Argentine Symposium on Software Engineering ASSE ’2000, 29 JAIIO.

Likert, R.A. (1932). “Technique for the measurement of attitudes” en Archives of Psychology.

Svahnberg, M., Aurum, A. y Wohlin, C. (2008). "Using students as subjects - an empirical evaluation" en Proceedings of the Second ACMIEEE international symposium on Empirical software engineering and measurement: 288–290.

Agarwal, R., Tanniru, M. R. (1990). “Knowledge Acquisition Using Structured Interviewing: An Empirical Investigation”, Journal of Manag. Inf. Systems, 7(1): 123-141.

Marakas, G. M., Elam, J. J. (1998). “Semantic Structuring in Analyst and Representation of Facts in Requirements Analysis” en Information Systems Research, 9: 37-63.

Agradecimientos

Trabajo desarrollado en el proyecto Cohesión Grupal en Ingeniería de Software Global (UNSJ). A estudiantes y profesores de las universidades latinoamericanas que participaron. Al proyecto SoftWiki (Alemania).