Adaptabilidad y Completitud en Procesos de Requisitos.

Adaptabilidad y Completitud en Procesos de Requisitos
Jorge H. Doorn, Graciela D.S. Hadad
[email protected], [email protected]
Claudia S. Litvak, Viviana Ledesma, Andrea F. Vera
{clitvak,cledesma,avera}@ing.unlam.edu.ar
Descriptores: Ingeniería de Requisitos, Variabilidad de Procesos, Completitud.
Resumen:
El proceso de Ingeniería de Requisitos basado en modelos en lenguaje natural, que ha
sido elaborado y refinado a lo largo de varios proyectos de investigación precedentes, se
ha difundido a través de cursos de grado y posgrado, y puesto en práctica en varios
proyectos de software en la industria. Aún cuando el proceso puede considerarse
suficientemente maduro, requiere mejoras en algunos aspectos relevantes. Dos de ellas
están relacionadas con: i) la adaptación del proceso de requisitos a la naturaleza del
proyecto, y ii) el control del grado de completitud alcanzado en sus diferentes actividades.
La primera mejora involucra considerar la envergadura del proyecto y la complejidad del
dominio, entre otros factores. En base a factores del contexto y del proyecto, es que se
deben tomar decisiones referidas a qué artefactos de requisitos deben construirse, qué
actividades del proceso son necesarias realizar y qué técnicas específicas son más
convenientes aplicar. Es decir, se trata de adaptar el proceso de requisitos a cada proyecto
de software específico, en base a los factores situacionales imperantes en él.
Por otro lado, la completitud es una incógnita en muchas áreas del conocimiento humano.
Específicamente en la Ingeniería de Software se presenta una seria dificultad: conocer con
certeza cuan completamente se han realizado tareas como las inspecciones de un
documento, las pruebas de unidades o de integración. Lo mismo ocurre en la Ingeniería de
Requisitos. Pese a ello, la completitud puede estimarse en forma aproximada. Diferentes
técnicas de estimación han sido propuestas, pero la calidad de las mismas y su integración
efectiva al proceso de requisitos es un problema abierto. Todas estas tareas de
investigación tienden a lograr una mayor integración de las distintas actividades del
proceso de requisitos y a una mejor evaluación de su calidad, eficacia y eficiencia.
Contexto:
Frecuentemente en la literatura, se propone el uso de un método específico para definir los
requisitos del software [1-4]. Sin embargo, existen muchos factores que deberían ser
considerados en el momento de definir los mismos, tales como el grado de reingeniería
esperado en los procesos del negocio, el conocimiento previo del dominio de la aplicación,
la complejidad de dicho dominio, el tipo de producto software y la envergadura del
proyecto, entre otros. En la práctica, estos factores generalmente no son identificados al
inicio del proyecto, sino que son considerados durante el transcurso del mismo sin ser
aprovechados durante la fase de planificación. Rolland [5] ha señalado que el desarrollo
de un sistema comienza con una fase de definición del método a utilizar. Existen métodos
en la Ingeniería de Requisitos muy difundidos, tanto en la literatura como en la práctica,
que se basan en la construcción de escenarios y casos de uso, presentando usualmente
un único enfoque para construir sus modelos [1,2]. Enfoques top-down [3] y bottom-up [4]
son los más ampliamente difundidos para construir casos de uso y escenarios; mientras
que enfoques middle-out [6,7] son menos frecuentemente utilizados. Es altamente
probable que sean más fáciles de obtener buenas soluciones, si se sigue un proceso de
construcción de escenarios o casos de uso que atienda factores particulares del proyecto
en cuestión, aún cuando la literatura ofrezca generalmente un único camino para construir
dichos modelos. Esto se basa en los principios de la Ingeniería de Métodos Situacional [8],
la cual se avoca a la construcción de métodos ajustados a situaciones específicas para el
desarrollo de software. Se debe tener en cuenta que cada situación es una combinación
del contexto y del tipo de proyecto [9].
Respecto a la completitud, el uso de técnicas apropiadas de elicitación, modelado,
verificación y validación de requisitos permite reducir la incompletitud natural en proyectos
complejos. Sin embargo, ellas no permiten eliminar el problema ni estimar el grado de
completitud alcanzado. Una adaptación del método de captura-recaptura propuesto por
[10] fue aplicado en la Ingeniería de Requisitos [11,12], obteniéndose en varios
experimentos resultados que muestran un nivel de completitud en los modelos de apenas
el 51%. Estos resultados alarmantes desencadenaron en nuevos estudios, que incluyeron
ajustes semánticos [13,14], confirmando los resultados anteriores.
El proceso de ingeniería de requisitos de software basado en modelos en lenguaje natural
[15], ampliado en [16] y que es la base del presente proyecto de investigación, consiste en
crear un glosario denominado Léxico Extendido del Lenguaje (LEL); construir un conjunto
de Escenarios Actuales que representan situaciones observables en el contexto de
aplicación; refinar los objetivos del sistema de software en base al conocimiento adquirido,
para luego construir escenarios que representen situaciones proyectadas con el nuevo
sistema del software, denominados Escenarios Futuros; crear un LEL según los términos
utilizados en los Escenarios Futuros (denominado LEL de Requisitos); y finalmente, definir
las especificaciones de requisitos del software en base al conocimiento adquirido y
modelado en las etapas previas. El proyecto de investigación tiene por objetivo fortalecer
este proceso de requisitos con mecanismos de adaptabilidad y completitud referidos a la
evolución del contexto de aplicación.
Desarrollo del Trabajo:
El proceso de ingeniería de requisitos desarrollado presenta dos grandes etapas bien
distinguibles: una de aprendizaje y la otra de definición (ver Fig.1). Cuando hay un
conocimiento previo del dominio de la aplicación, la primera fase se convierte en un
proceso confirmatorio, o podría incluso llegar a eliminarse parcial o totalmente.
Basados en la propuesta de la Ingeniería de Métodos Situacional [8], se han estudiado
diversos factores que son tenidos en cuenta en la literatura en distintas actividades del
proceso de requisitos [17-19]. Analizados muchos de estos factores, se ha detectado que
algunos de ellos no afectan el proceso de requisitos en sí (en general, se utilizan para
seleccionar técnicas de elicitación [19,20]), mientras que algunos deben aún estudiarse
para determinar su posible inicidencia en el
Variante A
proceso [21].
Variante B
Creación del Léxico
Extendido Lenguaje
Estado16
Construcción de
Escenarios Actuales
Estado29
Variante C
Refinamiento
Estado10
de Objetivos
Variante D
Construcción de
Escenarios Futuros
Variante E
Creación del Léxico
de Requisitos
Estado29
Las variantes en los sub-procesos, presentados
Fase de
Aprendizaje
en la Fig.1, pueden indicar: (i) el sub-proceso se
realiza o no; (ii) el sub-proceso se realiza
parcialmente;
o
(iii)
las
actividades
que
componen el sub-proceso pueden desarrollarse
aplicando distintos métodos. Debe observarse
Fase de
Definición
Estado41
que, a pesar de la secuencialidad expresada en
la Fig.1, existen continuos re-ciclos dadas las
actividades de verificación y validación de cada
Especificación
de Requisitos
Estado11
modelo, y la mejora continua en la comprensión
del
Figura 1. Proceso de Ingeniería de
Requisitos
problema.
La
variante
A
depende
principalmente de la novedad del negocio, el
tipo de cliente (específico o mercado potencial)
y la familiaridad con el dominio. La variante B depende fuertemente del conocimiento
previo que los ingenieros de requisitos tengan del dominio de la aplicación, aunque
también este proceso se ve afectado por la complejidad del problema, la envergadura del
proyecto y la volatilidad del dominio, entre otros factores. La variante C está influenciada
principalmente por el grado de reingeniería de los procesos del negocio y secundariamente
por los factores considerados en las variantes A y B que afectan a la construcción o no de
algunos de los modelos predecesores a los Escenarios Futuros. La variante D depende
básicamente del grado de cambios introducidos en la terminología utilizada en los
Escenarios Futuros respecto de la utilizada en el contexto actual de la aplicación,
representada en el LEL de Requisitos. La variante E está subordinada a un pedido
contractual de crear el documento de especificación de requisitos, la envergadura del
proyecto y la demanda de gestionar la rastreabilidad individual de cada requisito.
Tomando como ejemplo la variante C, se pueden presentar cinco enfoques para manejar la
construcción de Escenarios Futuros (ver Fig.2):
(i)
Crear los Escenarios Futuros derivándolos directamente de los Escenarios Actuales
existentes: enfoque orientado a los procedimientos.
(ii) Crear los Escenarios Futuros dirigido por los objetivos establecidos para el software,
apoyándose en los Escenarios Actuales de alto nivel.
(iii) Crear los Escenarios Futuros mediante una combinación de las dos estrategias
precedentes: enfoque híbrido.
(iv) Crear los Escenarios Futuros utilizando la técnica de derivación del LEL [7].
(v) Crear los Escenarios Futuros siguiendo un enfoque top-down dirigido por los objetivos
del sistema, comenzando por construir escenarios de alto nivel.
Construcción de Escenarios Futuros
Con Escenarios Actuales
Sin Escenarios Actuales
Sin Léxico
Innovación
= Baja
Con Léxico
Innovación
= Alta
Innovación
= Media
Innovación = Alta
Enfoque orientado
a lo Procedural
Estado3
Enfoque
Estado1
Híbrido
Enfoque dirigido
por Objetivos
Estado2
Enfoque Top-Down
Tradicional
Estado4
Innovación =
Baja o Media
Enfoque basado
Estado5
en el Léxico
Figura 2. Enfoques para construir Escenarios Futuros
Cabe aclarar que otros factores podrían ser relevantes en casos específicos que afectarían
decisiones sobre cómo configurar el método. Acá se han tenido en cuenta los factores
arquetípicos de un proyecto de software.
Conclusiones:
El proceso de ingeniería requisitos básico sin variantes se construyó sobre la base de la
experiencia adquirida tras años de su implementación en la práctica académica y
profesional. Esta experiencia nos ha enseñado que los problemas complejos tienen
características distintivas que se deben tener en cuenta para llevar a cabo un proceso de
requisitos con éxito. Por lo tanto, es aconsejable adaptar el proceso de requisitos
seleccionando las técnicas y modelos que son más adecuados para la situación específica.
La lista de factores de situación es bastante exhaustiva, aunque es probable que se
extienda. Se están evaluando algunos factores que no se mencionan aquí. Varios caminos
alternativos del proceso de requisitos se han aplicado en casos reales, a pesar de que no
se han definido formalmente antes de su aplicación. Pruebas adicionales de las diferentes
variantes del proceso se llevarán a cabo para comprobar la eficacia de los caminos
propuestos a partir de la estrategia básica. La presencia de muchos factores hace casi
imposible validar cada combinación de ellos, teniendo en cuenta los diferentes valores
posibles asociados a cada factor. Esto no impide la investigación exploratoria de las
combinaciones más probables.
Los estudios relacionados con completitud han tenido un avance interesante, que se
manifiesta en nuestras publicaciones [13,14], aunque es un problema complejo que
requiere aún mayores estudios.
Referencias:
[1] Leffingwell D, Widrig D, Managing Software Requirements - A unified approach. Addison-Wesley
Object Technology Series, 2º ed, 2003.
[2] Seyff N, Maiden N, Karlsen K, Lockerbie J, Grünbacher P, Graf F, Ncube C, Exploring how to
use scenarios to discover requirements, Requirements Engineering Journal, 14(2):91-111,
2009.
[3] Sutcliffe A, A Technique Combination Approach to Requirements Engineering, 3rd IEEE
International Symposium on Requirements Engineering, IEEE Computer Society Press,
pp.65-74, 1997.
[4] Potts C, Using Schematic Scenarios to Understand User Needs, Symposium on Designing
Interactive Systems: Processes, Practices and Techniques, ACM Press, pp.247-256, 1995.
[5] Rolland C, Method Engineering: Towards Methods as Services, ICSE 2008, Springer-Verlag,
Alemania, pp.10–11, 2008.
[6] Gough PA, Fodemski FT, Higgins SA, Ray SJ, Scenarios - An Industrial Case Study and
Hypermedia Enhancements, IEEE International Symposium on Requirements Engineering,
IEEE Computer Society Press, pp.10-17, 1995.
[7] Leite JCSP, Hadad GDS, Doorn JH, Kaplan GN, A Scenario Construction Process,
Requirements Engineering Journal, 5(1):38-61, 2000.
[8] Welke RJ, Kumar K, Method Engineering: a proposal for situation-specific methodology
construction. En: Cotterman, Senn (eds.) Systems Analysis and Design: A Research Agenda,
Wiley, Chichester, pp.257-268, 1992.
[9] Bucher T, Klesse M, Kurpjuweit S, Winter R, Situational Method Engineering. On the
Differentiation of “Context” and “Project Type”, IFIP International Federation for Information
Processing, Vol. 244/2007, 33-48, 2007.
[10] Wohlin C, Runeson P, Defect content estimations from Review Data, 20th Intl Conference on
Software Engineering, Japón, pp.400-409, 1982.
[11] Doorn JH, Ridao M, Completitud de Glosarios: Un Estudio Experimental, VI Workshop on
Requirements Engineering, Brasil, pp.317-328, 2003.
[12] Litvak CS, Hadad GDS, Doorn JH, Un abordaje al problema de completitud en requisitos de
software, XVIII Congreso Argentino de Ciencias de la Computación, Bahía Blanca, pp.827836, 2012.
[13] Litvak, C.S., Hadad, G.D.S., Doorn, J.H.: Correcciones semánticas en métodos de estimación
de completitud de modelos en lenguaje natural, XVI Workshop on Requirements Engineering,
Uruguay, pp.105-117, 2013.
[14] Litvak CS, Hadad GDS, Doorn JH, Mejoras semánticas para estimar la Completitud de
Modelos en Lenguaje Natural, Primer Congreso Nacional de Ingeniería Informática / Sistemas
de Información, Córdoba, 2013.
[15] Leite JCSP, Doorn JH, Kaplan GN, Hadad GDS, Ridao MN, Defining System Context using
Scenarios. En: Perspectives on Software Requirements, Kluwer Academic Publishers, EEUU,
ISBN: 1-4020-7625-8, capítulo 8, 2004, pp.169-199.
[16] Hadad GDS, Uso de Escenarios en la Derivación de Software, Tesis Doctoral, Facultad de
Ciencias Exactas, UNLP, 2008.
[17] Dhaliwal JS, Benbasat I, A Framework for the Comparative Evaluation of Knowledge
Acquisition Techniques, Knowledge Acquisition, 2(2):145-166, 1990.
[18] Jafarinezhad O, Ramsin R, Development of Situational Requirements Engineering Processes:
A Process Factory Approach, 36th IEEE Intl Conference on Computer Software and
Applications, pp.279-288, 2012.
[19] Carrizo D, Dieste O, Juristo N, Study of elicitation techniques adequacy, 11th Workshop on
Requeriments Engineering, 2005.
[20] Maiden N, Rug G, ACRE: Selecting methods for requirements acquisition. Software
Engineering Journal, 11(3):183-192, 1996.
[21] Hadad GDS, Doorn JH, Introducing Variability in a Client-Oriented Requirements Engineering
Process”, ER@BR2013: Requirements Engineering @ Brazil, Río de Janeiro, pp.8-13, 2013.