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.