Modelo híbrido para la elicitación de requisitos de software basado en una Sintaxis Controlada
77
0
0
Texto completo
(2) MODELO HÍBRIDO PARA LA ELICITACIÓN DE REQUISITOS DE SOFTWARE BASADO EN UNA SINTAXIS CONTROLADA. Renán Darı́o Gonzales Apaza.
(3) Dedicatoria. mi madre Antonia, porque creyó en mi y porque me sacó adelante, dándome ejemplo digno de superación y entrega, porque en gran parte gracias a ella, hoy puedo ver alanzado parte de mi meta, ya que siempre estuvo impulsándome en los momentos mas difı́ciles de mi carrera, y porque el orgullo que siente por mi, fue lo que me hizo ir hasta el final. A mi padre Renán por haber fomentado en mı́ el deseo de superación y el anhelo de triunfo en la vida. Va por ustedes, por lo que valen, porque admiro su fortaleza y por lo que han hecho de mı́.. A. i.
(4) Agradecimiento. L. a investigación realizada, no hubiera sido posible sin el apoyo del Consejo Nacional de Ciencia y Tecnologı́a (CONCYTEC) en convenio con la Universidad Nacional de San Agustı́n (UNSA), el Fondo Nacional de Desarrollo Cientı́fico, Tecnológico y de Innovación Tecnológica (CIENCIACTIVA) y, la Escuela de Postgrado de la UNSA. Además, quiero agradecer, a mi asesor el profesor: Dr. José Alfredo Herrera Quispe, por su apoyo, paciencia, sabidurı́a, confianza y por toda la ayuda dedicada a mi trabajo. Igualmente, deseo expresar un agradecimiento especial al Mgr. Jhon Edilberto Monroy Barrios, por la dedicación brindada para que la investigación se haga una realidad, gracias también a todos docentes de la maestrı́a en informática que contribuyeron en mi formación como investigador y profesional.. ii.
(5) Resumen. L. a naturaleza de los requisitos de software es subjetiva y de varias formas. El nivel de complejidad aumenta junto con el volumen, especialmente cuando los requisitos están en un lenguaje natural. Obtener requisitos de software de calidad que sean comprensibles y sin ambigüedad en el idioma español, constituyen una necesidad latente. El trabajo de investigación tuvo como propósito proponer un modelo hı́brido para la elicitación de requisitos de software basado en una sintaxis controlada, tomando en cuenta el comportamiento estático y dinámico entre los diferentes actores del sistema. Las expresiones fueron elaboradas en base a la notación de Backus Naur Form. La propuesta tomó como punto de partida a dos propuestas, siendo como base para definir las reglas de escritura. El modelo consta de dos principales pasos: la realización de un análisis léxico donde se estudió la naturaleza del idioma español y un análisis sintáctico donde creamos reglas para escribir oraciones de requisitos de software utilizando la notación Backus Naur Form. Adicionalmente, se desarrolló una herramienta que guı́a el proceso de escritura en la elicitación de requisitos de software. Los resultados mostraron una alta precisión en comprensibilidad y se redujo la ambigüedad de elicitación de requisitos. Permitiendo mejorar el desarrollo de actividades de ingenierı́a de software ya que no hay herramientas disponibles para la elicitación de requerimientos de software con estructuras propias del idioma español.. Keywords: Ingenierı́a de requisitos, análisis de requisitos, sintaxis controlada, ambigüedad de requisitos, herramienta CASE.. iii.
(6) Abstract. he nature of the software requirements is subjective and in several ways. The level of complexity increases along with the volume, especially when the requirements are in a natural language. Obtaining quality software requirements that are understandable and unambiguous in the Spanish language is a latent need. The purpose of the research work was to propose a hybrid model for the elicitation of software requirements based on a controlled syntax, taking into account the static and dynamic behavior among the different actors of the system. The expressions were elaborated based on the Backus Naur notation. The proposal took as a starting point two proposals, being as a basis to define the rules of writing. The model consists of two main steps: the realization of a lexical analysis where the nature of the Spanish language was studied and a syntactic analysis where we create rules to write sentences of software requirements using the Backus Naur Form notation. Additionally, a tool that guides the writing process in the elicitation of software requirements was developed. The results showed a high accuracy in understandability and the ambiguity of requirements elicitation was reduced. Allowing to improve the development of software engineering activities since there are no tools available for the elicitation of software requirements with structures typical of the Spanish language.. T. Keywords: Requirements engineering, requirements analysis, controlled syntax, ambiguity of requirements, CASE tool.. iv.
(7) Índice general. Dedicatoria . . . . . . Agradecimiento . . . Resumen . . . . . . . Abstract . . . . . . . . Lista de acrónimos . . Índice de figuras . . . Índice de tablas . . . Índice de ecuaciones .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . . . . . . . .. . i . ii . iii . iv . vi . viii . ix . ix. 1. Introducción 1.1. Problema de investigación . 1.2. Justificación . . . . . . . . . 1.3. Objetivos de la investigación 1.3.1. Objetivo general . . . 1.3.2. Objetivos especı́ficos 1.4. Estructura del documento .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. . . . . . .. 1 2 2 3 3 3 3. 2. Estado del arte 2.1. Elicitación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Conclusiones del capı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4 4 13. 3. Fundamentos teóricos 3.1. Ingenierı́a de software . . . . . . . . . . . . . . . 3.2. Requisitos e ingenierı́a de requisitos . . . . . . . 3.3. Requisitos . . . . . . . . . . . . . . . . . . . . . . 3.4. Ingenierı́a de requisitos . . . . . . . . . . . . . . . 3.5. Clasificación de los requisitos . . . . . . . . . . . 3.6. Procesos en ingenierı́a de requisitos . . . . . . . . 3.6.1. Elicitación de requisitos . . . . . . . . . . 3.6.2. Análisis de requisitos . . . . . . . . . . . . 3.6.3. Especificación de requisitos . . . . . . . . 3.6.4. Validación de requisitos . . . . . . . . . . 3.6.5. Administración de requisitos . . . . . . . 3.7. Proceso en la elicitación de requisitos . . . . . . . 3.8. Técnicas de elicitación de requisitos de software . 3.9. Metodologı́a de elicitación de requisitos . . . . . 3.9.1. La metodologı́a de Zawahreh . . . . . . .. 14 14 14 15 15 16 17 17 17 17 18 18 18 19 21 21. v. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . ..
(8) 3.9.2. El modelo de Medeiros . . . . . . . . . 3.9.3. Metodologı́a de Tiwari . . . . . . . . . 3.10. Caracterı́sticas de los requisitos . . . . . . . . 3.11. Herramientas para la elicitación de requisitos 3.12. Conclusiones del capı́tulo . . . . . . . . . . . 4. Propuesta 4.1. Propuesta . . . . . . . . . . . . 4.1.1. Análisis léxico . . . . . 4.1.2. Análisis sintáctico . . . 4.2. Elementos complementarios . 4.2.1. Frase del sujeto: . . . . 4.2.2. Frase del objeto: . . . . 4.2.3. Frase de la preposición 4.2.4. Instancia del objeto . . 4.2.5. Elemento vacı́o . . . . 4.3. Procedimiento . . . . . . . . . 4.4. Metodologı́a de validación . . 4.5. Conclusiones del capı́tulo . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. . . . . . . . . . . . .. . . . . .. 21 22 22 23 24. . . . . . . . . . . . .. 25 25 26 30 33 33 33 34 34 34 34 37 38. 5. Procedimientos y pruebas 5.1. Caso de estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1. Caso 1: Sistema de biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.2. Caso 2: Descripción dinámica de requisitos para el sistema de gestión de indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.3. Caso 3: Sistema de control de combustible . . . . . . . . . . . . . . . . . . 5.2. Conclusiones del capı́tulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 40 40 41 44 46 50. 6. Conclusiones y recomendaciones 6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2. Recomendaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3. Trabajos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 51 51 52 53. ANEXOS. 54. REFERENCIAS BIBLIOGRÁFICAS. 59.
(9) Lista de acrónimos. ISO. International Organization for Standardization (Organización Internacional de. Normalización).. IEEE. Institute of Electrical and Electronics Engineers (Instituto de Ingenierı́a Eléctrica. y Electrónica).. IEC. International Electrotechnical Commissio (Comisión Electrotécnica Internacional).. CMM. Capability Maturity Model (Modelo de Madurez de Capacidades).. RUP. Rational Unified Process (Proceso Racional Unificado).. SBVR. Semantic of Business Vocabulary and Rules (Semántica para Vocabulario de. Negocios y Regla de Negocios).. LN. Lenguaje natural.. POS. Part of speech (Etiquetado gramatical).. UML. Unified Modeling Language (Lenguaje unificado de modelado).. INI. Initial (archivos de configuración inicial).. XP. Extreme Programming (Programación Extrema).. BNF. Backus Naur Form.. HTML. HyperText Markup Language (lenguaje de marcas de hipertexto).. MySQL. My Structured Query Language (Lenguaje de Consulta Estructurado).. MVC. Modelo Vista Controlador.. PHP. Hypertext Preprocessor (Procesador de hipertexto).. ERS. Elicitación de requisitos de software.. AD. Almacén de datos.. vii.
(10) Índice de figuras. 2.1. Patrón de especificaciones de requisitos de software tailandés (Thongglin et al., 2013). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. El proceso general de detección de requisitos defectuosos (Femmer et al., 2014). 2.3. Proceso para mapear los requisitos en lenguaje natural a una representación SBVR (Umber and Bajwa, 2012). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4. Modelo de transformación de lenguaje natural a SBVR (Ramzan et al., 2014). . . 2.5. Propuesta de metamodelo (Ramzan et al., 2014). . . . . . . . . . . . . . . . . . . 2.6. Enfoque propuesto para la clasificación de requisitos (Minhas et al., 2011). . . . 2.7. Ejemplo de especificación de escenario para identificar un elector (Fatwanto, 2013b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.8. Arquitectura de la propuesta (Geetha and Anandha Mala, 2014b). . . . . . . . . 2.9. Patrón de descripción de atributos (Thongglin et al., 2012). . . . . . . . . . . . . 2.10. Reglas de uso de verbos auxiliares (Thongglin et al., 2012). . . . . . . . . . . . . 2.11. Arquitectura para el diagrama de actividad (Gulia and Choudhury, 2016). . . . 2.12. Arquitectura para el diagrama de secuencia (Gulia and Choudhury, 2016). . . . 2.13. Proceso para la extracción de glosario de términos (Dwarakanath et al., 2013). .. 9 10 11 11 12 12 13. 3.1. La elicitación de requisitos y el proceso de análisis (Sommerville, 2015). . . . . 3.2. Técnica de elicitación de requisitos (Tiwari and Rathore, 2017). . . . . . . . . . 3.3. Caracterı́sticas de los requisitos (Wiegers and Beatty, 2013). . . . . . . . . . . . .. 19 22 23. 4.1. Modelo hı́brido propuesto para la elicitación de requisitos de software en una sintaxis controlada. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2. Arquitectura del sistema ERS propuesto (Elaboración propia) . . . . . . 4.3. Método ágil de programación extrema (Sommerville, 2015). . . . . . . . 4.4. Interfaz de la herramienta ERS-TOOL (Elaboración propia). . . . . . . . 4.5. Metodologı́a de validación (Monroy Barrios, 2016). . . . . . . . . . . . .. 26 35 36 37 38. viii. basado . . . . . . . . . . . . . . . . . . . . . . . . .. 5 5 6 7 7 8.
(11) Índice de tablas. 5.1. Descripción casos de estudio (Elaboración propia) . . . . . . . . . . . . . . . . . 5.2. Descripción estática de requisitos para el sistema de biblioteca (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3. Descripción dinámica de requisitos para el sistema de biblioteca (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4. Descripción estática de requisitos para el sistema de gestión de indicadores (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.5. Descripción dinámica de requisitos para el sistema de gestión de indicadores (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6. Descripción estática de requisitos para el sistema de control de combustible (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7. Descripción dinámica de requisitos para el sistema de control de combustible (Elaboración propia) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8. Resultados de la encuesta aplicada (Elaboración propia) . . . . . . . . . . . . . . 5.9. Resultado de comprensión y promedio de precisión (Elaboración propia) . . . .. ix. 41 42 43 44 45 47 48 49 49.
(12) Índice de ecuaciones. 2.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12 4.13 4.14 4.15 4.16 4.17 4.18 4.19 4.20 4.21 4.22 4.23 4.24 4.25. Formato para especificar requisitos . . . . . . . . . . . . . . . . . . . . . . . . . Uso del verbo auxiliar: debe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uso de palabras de cuantificación universal . . . . . . . . . . . . . . . . . . . . . Uso de palabras de cuantificación numérica . . . . . . . . . . . . . . . . . . . . . Uso de la palabra de preposición: de y desde . . . . . . . . . . . . . . . . . . . . Uso de la palabra de preposición : dentro de y bajo . . . . . . . . . . . . . . . . . Uso de la palabra de preposición: con . . . . . . . . . . . . . . . . . . . . . . . . Uso de la palabra de preposición: en . . . . . . . . . . . . . . . . . . . . . . . . . Uso de la palabra de preposición: por y mediante . . . . . . . . . . . . . . . . . . Conjunto de reglas de escritura ERS . . . . . . . . . . . . . . . . . . . . . . . . . Forma normal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma debe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma modal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma tiene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma de subsunción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma condicional simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma condicional simple negación . . . . . . . . . . . . . . . . . . . . . . . . . Forma condicional alternativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma secuencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forma actividad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frase del sujeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frase del objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frase preposición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instancia del objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Elemento vacio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. x. 9 27 28 28 28 29 29 29 29 30 31 31 31 31 31 32 32 32 32 33 33 33 34 34 34.
(13) Capı́tulo 1. Introducción. La ingenierı́a de software es más que solo programar. Consiste en toda la documentación asociada, principios de diseño o filosofı́as requeridas para hacer que estos programas funcionen como se espera (Achimugu et al., 2014a). Como una de las disciplinas centrales de cualquier proceso de ingenierı́a para sistemas técnicos, la ingenierı́a de requisitos tiene como objetivo especificar de forma sistemática los requisitos para los sistemas que se desarrollarán (Braun et al., 2014). En muchas aplicaciones, la información disponible está en forma de texto en lenguaje natural en lugar de la base de datos estructurada. Para hacer un uso productivo del texto en lenguaje natural aplicamos la extracción de texto, que comprende el proceso de estructurar la entrada, extraer patrones e interpretar el resultado (Geetha and Anandha Mala, 2013). Los requisitos se definen inicialmente con el cliente y se enumeran en un formato de lista de deseos del cliente (Inayat et al., 2015). Comprender los requisitos del software durante los proyectos de desarrollo de software es una tarea ardua (Fernández et al., 2017). Es común para los requisitos, que normalmente se especifican utilizando un lenguaje natural particular, adornado con ambigüedad e incompletitud Femmer et al. (2014). Formar una vista compartida entre las partes interesadas o los posibles usuarios y desarrolladores requiere, por lo tanto, trabajos significativos. Ambas partes tienen que compartir su punto de vista interno con respecto al sistema bajo consideración para lograr un entendimiento común (Fatwanto, 2013a). La literatura revisada sobre ingenierı́a de software no contempla el comportamiento estático y dinámico de las caracterı́sticas especificas de las necesidades del usuario por tal motivo nuestra propuesta plantea la solución de dichas limitaciones en las reglas de escrituras propias del lenguaje que generan errores en la compresión de información entre los actores que participan en el desarrollo de sistemas.. 1.
(14) 1.1.. Problema de investigación. En el proceso de la elicitación de requisitos de software el cliente suele expresar el dominio de su problema en un lenguaje natural, y el analista obtiene y registra información sobre estas necesidades. El problema en la elicitación de requisitos de software es la ambigüedad en la descripción de las caracterı́sticas del sistema a desarrollar, porque comúnmente se especifican utilizando un lenguaje natural particular (Achimugu et al., 2014a; Fatwanto, 2013a; Femmer et al., 2014; Misra, 2016; Ramzan et al., 2014), provocando de esta forma el fracaso o la demora en la entrega de los proyectos de software debido a requisitos deficientes (Alshazly et al., 2014; Bjarnason et al., 2016). Adicionalmente, éste problema se deriva en una baja comprensibilidad entre analistas, usuarios y/o clientes debido a que los deseos y necesidades no son de entendimiento común (Zapata et al., 2014). Ambas partes tienen que compartir su punto de vista interno con respecto al sistema bajo consideración para lograr una comprensión común (Fatwanto, 2013a). Comprender los requisitos de software durante los proyectos de desarrollo de software es una tarea ardua (Fernández et al., 2017). La literatura revisada para tratar este problema se enfoca en describir aspectos de la estructura del software y aspectos dinámicos del software de manera separada. Por lo que, se deberı́an de abordar de manera complementaria para tener un entendimiento global del sistema. Por otro lado, se observa y es evidente que es necesario sistematizar y ahondar hacia una más activa, participativa, práctica y efectiva, a favor del mejoramiento de la calidad de requisitos de software. Por lo tanto, podemos concluir que el problema central es la ambigüedad de requisitos en la comprensión de la información de forma precisa entre los actores que participan en el desarrollo de sistemas, en el dominio de la elicitación de requisitos de software.. 1.2.. Justificación. La utilidad de la investigación, radica en la adquisición de conocimiento rápido y preciso (Karpicke y Blunt, 2011). Nuestra propuesta se basa en un modelo que permita plantear reglas de escritura para describir requisitos de software sin ambigüedad, ya que es una de las principales fallas en el desarrollo de proyectos de software (Kaur y Sengupta, 2013). Y su impacto se ve relacionado el éxito del proyecto de software y las expectativas del cliente con el International (2013a,b); Vedia (2017), como también con factores humanos (Gallego, 2015). Suaza (2014) señala que “se asume a la Ingenierı́a de requisitos como la fase más importante del ciclo de vida de la Ingenierı́a de Software, y que se brinda especial atención a la elicitación, preocupa el hecho de que se trabaja, propone y difunde muy poco acerca de cómo documentar esta etapa”. El resultado de nuestro modelo desemboca en una aplicación que constituye una herramienta de gran utilidad en el campo de la ingenierı́a de requisitos, permitiendo establecer información relevante superando la ambigüedad del lenguaje natural, la dificultad y los efectos negativos que conlleva al entendimiento de las partes involucradas, para lograr este objetivo 2.
(15) empleamos un conjunto de reglas de de escritura basadas en una sintaxis controlada.. 1.3.. Objetivos de la investigación. 1.3.1.. Objetivo general. Proponer un modelo hı́brido para la elicitación de requisitos de software basado en una sintaxis controlada.. 1.3.2.. Objetivos especı́ficos. Analizar el escenario para establecer la cobertura, vacı́os existentes y las tecnologı́as que se emplean para tratar la ambigüedad en requisitos de software. Diseñar un método de reglas de escritura basado en una sintaxis controlada. Proponer un proceso que permita derivar la aplicabilidad de las reglas de escritura en usuarios para su uso en casos reales. Validar la viabilidad de la propuesta.. 1.4.. Estructura del documento. El presente trabajo se encuentra organizado de la siguiente manera: En el capı́tulo 2, se describe una contextualización de los estudios existentes en la literatura acerca de la ambigüedad cuando se describen requisitos de software, el cual ayudará a entender qué aspectos de este trabajo están vinculados a nuestra investigación, sin embargo, servirá como soporte para una de las aportaciones de esta tesis, lo cual puede contribuir en la mejora de los enfoques existentes. En el capı́tulo 3, se definen los procesos y el marco teórico relacionados con la elicitación de requisitos de software. Esta contextualización proporciona un argumento necesario para la contribución de esta tesis. En el capı́tulo 4, se presenta la propuesta de solución que incluye: un análisis léxico, un análisis sintáctico, los criterios para desenvolver una herramienta que implementa la propuesta y la forma como serán abordados los problemas detectados. En el capı́tulo 5, se muestran los procedimientos y pruebas realizadas con el modelo a través de casos de estudio con nuestro modelo propuesto. En el capı́tulo 6, las conclusiones y recomendaciones finales de este proyecto de investigación, para esto se verifica que los objetivos derivados han sido alcanzados a lo largo de la investigación.. 3.
(16) Capı́tulo 2. Estado del arte. En el presente capı́tulo, identificamos las principales propuestas para resolver el efecto de la ambigüedad cuando se describen requisitos de software, y proponen soluciones para evitar su efecto. Empezaremos con una contextualización actual para tratar la ambigüedad y terminaremos con las últimas propuestas en el área.. 2.1.. Elicitación de requisitos. En el contexto de la elicitación de requisitos de software, seleccionamos las siguientes investigaciones que servirán de partida para la formulación de nuestro proyecto de investigación: Thongglin et al. (2013), en su trabajo denominado “Thai Software Requirements Specification Pattern”, presenta patrones de especificación de requisitos de software para el idioma Tailandés haciendo uso de una sintaxis controlada, con el objetivo de ayudar a los ingenieros de software a como comenzara escribir especificación de requisitos de software y que información deberı́a ser recopilada. Todo ello expresado en un patrón de especificación de requisitos (similar a una tarjeta “Clase-Responsabilidades-Colaboradores” propuestas por Ward Cunningham y Kent Beck). La propuesta consiste en un conjunto de reglas de escritura denominada sintaxis controlada y patrones de especificación de requisitos de software. La estructura de cada componente esta diseñada de acuerdo a la sintaxis controlada. El patrón consiste en dos partes: la definición de requisitos de software y la especificación de requisito de software como se observa en la Figura 2.1.. 4.
(17) ĞĨŝŶŝĐŝſŶĚĞƌĞƋƵŝƐŝƚŽƐ ĚĞƐŽĨƚǁĂƌĞ ZYϭ. EŽŵďƌĞĚĞĚĞĨŝŶŝĐŝſŶ ĚĞƌĞƋƵŝƐŝƚŽƐ фZ^х. ZYϮ ͘. ͘͘ ͘͘. ZYͲŶ. ͘͘. /ZĞƋƵŝƐŝƚŽ. ĞĨŝŶŝĐŝſŶĚĞZĞƋƵŝƐŝƚŽƐ ĚĞ^ŽĨƚǁĂƌĞ /ZĞƋƵŝƐŝƚŽ. dĞdžƚŽůŝďƌĞ. sĞƌƐŝſŶ. dĞdžƚŽůŝďƌĞ. &ƵĞŶƚĞ. dĞdžƚŽůŝďƌĞ dĞdžƚŽůŝďƌĞ. WƌŽƉſƐŝƚŽ. фWZKWM^/dKх. ƵƚŽƌ. фWZ KE//MEх фD/EKͺ^/Kх. WƌĞĐŽŶĚŝĐŝſŶ ĂŵŝŶŽ ďĄƐŝĐŽ. фD/EKͺ>d ZEKх фWK^dKE//MEх. ĂŵŝŶŽ ĂůƚĞƌŶŽ WŽƐƚ ĐŽŶĚŝĐŝſŶ. Figura 2.1: Patrón de especificaciones de requisitos de software tailandés (Thongglin et al., 2013).. Los resultados muestran un buen nivel de control de especificación de requisitos de software en el idioma tailandés, del mismo modo se evitan ambigüedades léxicas y sintácticas en cada oración. Femmer et al. (2014), en su trabajo denominado “Rapid Requirements Checks with Requirements Smells: Two Case Studies”, proponen detectar problemas en los requisitos aplicando un análisis de requisitos estático de peso ligero. Esta técnica permite realizar verificaciones instantáneas en cuanto son escritas. Se basan en los criterios de lenguaje natural del estándar ISO/IEC/IEEE 29148 que sirven para detectar requisitos que violan estos principios.. ϭ͘Śƚŵů ϭ͘ĚŽĐ. ϭ. Ϯ. ϯ. ϰ. ŶĄůŝƐŝƐ. ŶŽƚĂĐŝŽŶĞƐ. ZĞƋƵŝƐŝƚŽƐĚĞĨĞĐƚƵŽƐŽƐ. WƌĞƐĞŶƚĂĐŝŽŶĞƐ. ƐƉ ϭ ^ĞĐϭ. ZĞƋϭ ZĞƋϮ ZĞƋϯ ^ĞĐϮ ZĞƋϭ ZĞƋϮ ƐƉ ϭ ^ĞĐϭ ZĞƋϭ ZĞƋϮ ZĞƋϯ. ƚŝƋƵĞƚĂĚŽWK^ ŶĄůŝƐŝƐŵŽƌĨŽůſŐŝĐŽ >ĞŵĂƚŝnjĂĐŝſŶ. ZĞŶĚĞƌŝnjĂŶĚŽ ĞƐƉĞĐŝĨŝĐĂĐŝŽŶĞƐ ĐŽŶĂŶŽƚĂĐŝŽŶĞƐ. ϭ͘Śƚŵů ϭ͘Śƚŵů ƐƚĂĚŝƐƚŝĐĂƐ͘ Śƚŵů. WĂŶĞů ĚĞĂŶĄůŝƐŝƐ. Figura 2.2: El proceso general de detección de requisitos defectuosos (Femmer et al., 2014).. En la Figura 2.2, se observa el proceso que consta de cuatro pasos: el análisis de especificaciones en requisitos únicos, anotación de requisitos con meta-información como el lematizado, detección requisitos defectuosos donde se incluyen técnicas como la detección 5.
(18) de pronombres vagos, lenguaje subjetivo, frases comparativas vagas, superlativos, verbos y adjetivos ambiguos; y finalmente se muestra un reporte donde se evidencia las palabras que indican imprecisión seguido de una sugerencia. Los resultados muestran que el enfoque es adecuado para detectar defectos relevantes en requisitos de software. Pero no pueden encontrar todos los defectos posibles. Umber and Bajwa (2012), en su trabajo denominado “A Step Towards Ambiguity Less Natural Language Software Requirements Specifications”, para tratar la ambigüedad presentan un enfoque basado en una representación del lenguaje natural controlada semánticamente para los requisitos de software. Para representar una semántica de lenguaje natural usan el estándar de “Semantic of Business Vocabulary and Rules (SBVR)”. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ͻ00 00 ƐƉĞĐŝĨŝĐĂĐŝſŶĚĞƚĞdžƚŽ>E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ͻ WƌĞƉƌŽĐĞƐĂŶĚŽ 0 0 0 0 0 0000000000000000000000000000000000000000000000000000000000000000000000000000 ͻ ŶĄůŝƐŝƐƐŝŶƚĄĐƚŝĐŽ WƌŽĐĞƐĂŵŝĞŶƚŽ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ĚĞƚĞdžƚŽ>E 0 0 0ͻ0 0/ŶƚĞƌƉƌĞƚĂĐŝſŶƐĞŵĄŶƚŝĐĂ 00 00 00 00 00 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 00 00 00ͻ00 00 džƚƌĂLJĞŶĚŽƚŝƉŽƐĚĞŽďũĞƚŽƐ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ͻͻ00 00 džƚƌĂLJĞŶĚŽĐŽŶĐĞƉƚŽƐǀĞƌďĂůĞƐ 0000000000000000000000000000000000000000000000000000000000000000000000000000 džƚƌĂLJĞŶĚŽĐŽŶĐĞƉƚŽƐŝŶĚŝǀŝĚƵĂůĞƐ 'ĞŶĞƌĂĐŝſŶĚĞ 0 0 0 0 0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00. ǀŽĐĂďƵůĂƌŝŽ^sZ ͻ džƚƌĂLJĞŶĚŽĐĂƌĂĐƚĞƌşƐƚŝĐĂƐ. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00ͻ00 00'ĞŶĞƌĂŶĚŽƚŝƉŽƐĚĞĚĂƚŽ^sZ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0 0 0ͻ0 0ƉůŝĐĂƌůĂĨŽƌŵƵůĂĐŝſŶƐĞŵĄŶƚŝĐĂ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 'ĞŶĞƌĂĐŝſŶĚĞ 0 0 0ͻ0 0ƉůŝĐĂŶĚŽŶŽƚĂĐŝſŶŝŶŐůĞƐĂĞƐƚƌƵĐƚƵƌĂĚĂ ƌĞŐůĂƐ^sZ 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0. Figura 2.3: Proceso para mapear los requisitos en lenguaje natural a una representación SBVR (Umber and Bajwa, 2012).. La Figura 2.3, muestra el proceso: en la primera fase se realiza un análisis del texto de requisitos de software en LN (lenguaje natural) donde se identifica las palabras clave del archivo de texto con especificaciones en el idioma ingles. En la segunda fase una extracción del vocabulario SBVR: En esta fase, los elementos SBVR por ejemplo tipos de objetos, verbos, caracterı́sticas, palabras de cuantificación, etc. son identificados a partir de la fase previa. Finalmente se generan las reglas SBVR; en esta fase se representa las reglas SBVR a partir del vocabulario anterior que da como resultado una lista de requisitos en formulación modal; que indican restricción sobre lo que se debe y no debe realizar el sistema a desarrollar. Los resultados muestran que el enfoque puede ser útil generando modelos de software precisos y consistentes desde los requisitos de software en lenguaje natural. Ramzan et al. (2014), presentan “A Model Transformation from NL to SBVR”, un enfoque de un modelo de transformacion para generar requisitos de softaware basado en SBVR(Semantics of Busines Vocabulary and Business Rules). La información es ingresada en un meta-modelo fuente (lenguaje natural) que es automáticamente convertido en un meta modelo de destino 6.
(19) SBVR. Los componentes necesarios para la el modelo de transformación desde un meta-modelo LN a un meta-modelo SBVR son meta-modelo fuente LN, motor de transformación, regla de transformación, descripción de transformación. El boceto completo de la transformación del modelo se observa en la Figura 2.4.. Figura 2.4: Modelo de transformación de lenguaje natural a SBVR (Ramzan et al., 2014).. Por otro lado, el metamodelo de lenguaje natural está basado en el metamodelo ProjectITRSL donde se complementa nuevos elementos sobre los existentes. En la Figura 2.5 se observa los nuevos elementos agregados en color naranja.. ZĞƋƵŝƐŝƚŽ KƚƌŽƌĞƋƵŝƐŝƚŽ. ZĞƋƵŝƐŝƚŽ ĨƵŶĐŝŽŶĂů. ZĞƋƵŝƐŝƚŽ ƐŝŵƉůĞ. ZĞƋƵŝƐŝƚŽ ĐŽŶĚŝĐŝŽŶĂů. ĐƚŽƌ. KƉĞƌĂĐŝſŶ sĞƌďŽĂƵdžŝůŝĂƌ. ŐĞŶƚĞ WŽƐĞĞĚŽƌ ĂƵƐĂŶƚĞŝŶǀŽůƵŶƚĂƌŝŽ. sĞƌďŽĚĞ ĂĐĐŝſŶ. ZĞĐŝďŝĚŽƌ. ZĞƋƵŝƐŝƚŽŶŽ ĨƵŶĐŝŽŶĂů. ŽŶĚŝĐŝſŶ ^ƵũĞƚŽ ŶƚŝĚĂĚ ĞŶĞĨĂĐƚŽ. WĂƐŝǀŽ >ŽĐĂůŝnjĂĐŝſŶ /ŶƐƚƌƵŵĞŶƚŽ. Figura 2.5: Propuesta de metamodelo (Ramzan et al., 2014).. 7.
(20) Los resultados muestran un buen promedio de precisión que hace posible especificar requisitos con mı́nima ambigüedad mediante requisitos basados en SBVR usando el enfoque del modelo de transformación. Minhas et al. (2011), en su trabajo denominado “Controlled Vocabulary based Software Requirements Classification”, plantean que organizar los requisitos en grupos pueden apoyar a que los requisitos de software sean mas comprensibles. Para ellos presentan un clasificador que transforma requisitos escritos en lenguaje natural en los grupos correspondientes. La organización de estos grupos depende de la asociación entre palabras claves, por ejemplo de jerarquı́a. La clasificación de las palabras clave funcionan mejor cuando están escritas en un vocabulario controlado. La estructura de ésta técnica comprende tres principales componentes: un repositorio de palabras clave y sus relaciones como fuente de datos, un mapeo que encuentra palabras en los requisitos del documento con las palabras del repositorio, y presentación que muestra los requisitos ya clasificados.. WƌŽĐĞƐŽĚĞĐŽŝŶĐŝĚĞŶĐŝĂĚĞ ƉĂůĂďƌĂƐĐůĂǀĞĚĞƌĞƋƵŝƐŝƚŽƐ. ZĞĚĚĞ ƉĂůĂďƌĂƐĐůĂǀĞ. ŶƚƌĂĚĂ. ůĂƐŝĨŝĐĂĚŽƌ ZĞƋƵĞƌŝŵŝĞŶƚŽƐĚĞƵƐƵĂƌŝŽ ůĂƐŝĨŝĐĂĚŽƌ. DĂƉĞĂŶĚŽƌĞƋƵŝƐŝƚŽƐĞŶ ZĐŽŶƉĂůĂďƌĂƐĐůĂǀĞ. ŶĄůŝƐŝƐ ĚĞƌĞƋƵŝƐŝƚŽƐ. ZĞƋƵŝƐŝƚŽƐĐůĂƐŝĨŝĐĂĚŽƐ. Figura 2.6: Enfoque propuesto para la clasificación de requisitos (Minhas et al., 2011).. La Figura 2.6, muestra una abstracción del enfoque propuesto. Comienza con los requisitos de diferentes usuarios. Estos requisitos son mapeados iterativamente con el repositorio de palabras. Finalmente se presentan en forma de grupos, cada uno contiene un conjunto de requisitos que pueden usarse para un análisis adicional. Los resultados muestran una alta precisión al usar las palabras clave, por lo que tienen un gran impacto en sus resultados. Sin embargo, deben elaborarse con cuidado ya que inciden significativamente en los resultados. La desventaja de este enfoque es que debe existir una alta coherencia con respecto a los requisitos dados; ası́ entonces el resultado sera de alta calidad. El desafı́o de esta técnica es la selección de palabras clave adecuadas y crear su repositorio para la clasificación. 8.
(21) Keet and Khumalo (2017), presentan “Toward a Knowledge-to-text Controlled Natural Language of IsiZulu”, cuya propuesta consiste en describir reglas de negocio y especificar conocimiento de texto estructurado en requisitos, con el objetivo de formar oraciones correctas. Los patrones de verbalización que expone son: cuantificaciones universales, cuantificadores de existencia, axiomas con propiedades simples, y casos básicos de negación. Basado en la evaluación preliminar se seleccionan en un algoritmo de verbalización para generar oraciones correctas en el idioma IsiZulu, que han sido evaluadas. Los resultados muestran un resultado aceptable para formas de subvención, las construcciones existenciales fueron generalmente aceptables con algunas frases que condujeron a ambigüedad. En la investigación de Fatwanto (2013a,b), para mantener la flexibilidad y simplicidad, trabaja con un método para especificar requisitos de software en un lenguaje natural. El método propuesto consiste en dos aspectos: el uso de un lenguaje natural restringido y la estructura para especificar los requisitos de software para poder ser traducibles a un aspecto dinámico del sistema. En la Ecuación 2.1, se observa el formato utilizado para la especificación de requisitos:. Requisito = Sujeto + V erbo + Destino + [Manera]. (2.1). El sujeto representa el agente que ejecuta el comportamiento, el verbo describe la actividad realizada por el sujeto, el destino puede ser una entidad fı́sica o conceptual (objeto), el objeto contiene un número de propiedades que pueden ser afectados por la actividad y la manera define el camino o los instrumentos usados para describir la acción. En la Figura 2.7, se observa un escenario de descripción de eventos bajo el formato propuesto.. ǀĞŶƚŽ. ƐƚĂĚŽ. ^/^d D ů ǀŽƚĂŶƚĞ ŵƵĞƐƚƌĂ ŝŶŐƌĞƐĂƐƵ ͮƉĂŶƚĂůůĂ ĚĞ ŶŽŵďƌĞ ŝŶŝĐŝŽͮ ^/^d D ^/^d D ŶĐƵĞŶƚƌĂĂů ƵƐĐĂĂů ĞůĞĐƚŽƌ ĞůĞĐƚŽƌ ůǀŽƚĂŶƚĞ ŚĂĐĞ^/^d D ĐůŝĐ DƵĞƐƚƌĂĂů ͮŽƚſŶŝŶŝĐŝŽͮ ĞůĞĐƚŽƌ. ĐĐŝſŶ. ŐĞŶƚĞ. ĐƚŝǀŝĚĂĚ. KďũĞƚŽ. ^/^d D. ďƵƐĐĂ. ĞůĞĐƚŽƌ. ^/^d D. ŵƵĞƐƚƌĂ. ĞůĞĐƚŽƌ. ^/^d D. ŵƵĞƐƚƌĂ. ͮWĂŶƚĂůůĂĚĞ ŝŶŝĐŝŽͮ. Figura 2.7: Ejemplo de especificación de escenario para identificar un elector (Fatwanto, 2013b).. 9.
(22) Geetha and Anandha Mala (2013, 2014a,b), presentan una forma de identificar el esquema de la tablas en base de datos y la relación correspondiente de las tablas extraı́das de la especificación de requisitos en lenguaje natural. El proceso comienza con la identificación del esquema y propiedades de la tabla, luego se identifica el atributo de clave principal a partir de adjetivos, priorizando los atributos. Seguidamente se identifica la relación entre tablas. Como resultado se tiene la relación entre las tablas, además que se valida en tiempo real. La Figura 2.8, muestra el proceso de la propuesta.. ŶƚƌĂĚĂ Z^. ŽŵŝŶŝŽĚĞůĐŽŶŽĐŝŵŝĞŶƚŽ ĚĞ ůŝĐŝƚŽƌ. /ĚĞŶƚŝĨŝĐĂĚŽƌ ĐůĂǀĞ. &ƌĂĐĐŝŽŶĂŵŝĞŶƚŽĚĞĨƌĂƐĞƐ. džƚƌĂĐĐŝſŶĚĞĂƚƌŝďƵƚŽƐĚĞů ĚŝĂŐƌĂŵĂĚĞĐůĂƐĞƐ. ŽŶĚŝĐŝſŶ ƚŝƋƵĞƚĂĚŽLJĨƌĂŐŵĞŶƚĂĐŝſŶĚĞĨƌĂƐĞƐ. /ĚĞŶƚŝĨŝĐĂĐŝſŶĚĞůĂĐůĂǀĞ ŽŶĚŝĐŝſŶ ƉƌŝŵĂƌŝĂ. ZĞƐŽůƵĐŝſŶĚĞƌĞĨĞƌĞŶĐŝĂLJŵĂƉĞŽ. /ĚĞŶƚŝĨŝĐĂĐŝſŶĚĞĐůĂǀĞ ĨŽƌĄŶĞĂ. 'ĞŶĞƌĂĐŝſŶĚĞůĚŝĂŐƌĂŵĂĚĞĐůĂƐĞƐ;EŽŵďƌĞĚĞ ĐůĂƐĞƐ͕ƚƌŝďƵƚŽƐ͕DĠƚŽĚŽƐLJƌĞůĂĐŝŽŶĞƐͿ. Figura 2.8: Arquitectura de la propuesta (Geetha and Anandha Mala, 2014b).. La idea central es identificar la dependencia de los atributos entre las tablas basadas en el enfoque basado en reglas de la forma Sujeto - Verbo - Objeto (S-V-O). El proceso de encontrar la relación entre los atributos comienza con el extractor de requisitos que interpreta los requisitos en S-V-O para mapear la palabra en elementos orientados a objetos. Los patrones S-V-O identificados se utilizan para clasificar elementos orientados a objetos como clases, atributos, métodos y relaciones. Thongglin et al. (2012), describen el problema y ambigüedad encontrados en especificación de requisitos de software en el idioma Tailandés, y proponen un enfoque para escribir requisitos de software en el idioma Tailandés mediante el uso de una sintaxis controlada con el objetivo de reducir la ambigüedad y mejorar la comprensibilidad. Las reglas de escritura establecidas son para expresar atributos, verbos auxiliares, palabras de clasificación, cuantificación y preposición. En la Figura 2.9, se observa el patrón de escritura para describir atributos de un sustantivo en el idioma Tailandés, donde muestra diferentes formas de expresar la pertenencia de un atributo a un sustantivo.. 10.
(23) Figura 2.9: Patrón de descripción de atributos (Thongglin et al., 2012).. En la Figura 2.10, se observa el uso de verbos auxiliares, que pueden ser usados junto con el verbo transitivo o intransitivo.. Figura 2.10: Reglas de uso de verbos auxiliares (Thongglin et al., 2012).. Los experimentos muestran una buena precisión con sentencias para descripción de requisitos de software. Glavaš et al. (2012), presentan un método para automatizar el análisis de requisitos basado en una sintaxis especı́fica. El enfoque se basa en reglas para la extracción de entidades, atributos, relaciones del modelo de negocio expresado por el usuario, existencia de un objeto directo, posesiones y relaciones entre objetos. Gulia and Choudhury (2016), para minimizar los errores que surgen en la especificación de requisitos proponen una técnica que mejora la generación de modelos UML a través de requisitos en lenguaje natural. La investigación se centra en la producción del diagrama de actividades y el diagrama de secuencia a través de las especificaciones del lenguaje natural. El estándar de etiquetado POS (Part of speech) y el analizador sintáctico analizan los requisitos dados en el idioma ingles por el usuarios y extraen frases, actividades, etc. del texto especificado. 11.
(24) ZĞƋƵŝƐŝƚŽƐĞƐƉĞĐŝĨŝĐĂĚŽƐ. ^ĞƉĂƌĂĚŽƌĚĞ ĨƌĂƐĞƐ. ƚŝƋƵĞƚĂĚŽ WK^. džƚƌĂĐĐŝſŶĚĞŽďũĞƚŽLJǀĞƌďŽ ĐŽŵŽƵŶĂĂĐƚŝǀŝĚĂĚ. ĚŝĐŝſŶĚĞŶƵŵĞƌĂĐŝſŶĚĞ ĂĐƚŝǀŝĚĂĚĞƐƐĞŐƷŶĞůƌĞƋƵŝƐŝƚŽ ĚĞůƵƐƵĂƌŝŽ. ŝďƵũĂƌĞůĚŝĂŐƌĂŵĂĚĞĂĐƚŝǀŝĚĂĚ. Figura 2.11: Arquitectura para el diagrama de actividad (Gulia and Choudhury, 2016).. En la Figura 2.11, se observa el proceso para la generación del diagrama de actividad. El texto ingresado por el usuario es segmentado en sentencias para encontrar estructuras de la forma “Sujeto - Predicado” o “Sujeto - Predicado - Objeto”. Una sentencia será anulada si no tiene un verbo. Luego se realiza la extracción de Verbos y objetos para finalmente mostrar en forma gráfica el diagrama de actividad correspondiente.. ZĞƋƵŝƐŝƚŽƐ ĞƐƉĞĐŝĨŝĐĂĚŽƐ. WƌĞƉƌŽĐĞƐĂŵŝĞŶƚŽ. ,ĞƌƌĂŵŝĞŶƚĂ. ^ƚĂŶĨŽƌĚ ƉĂƌƐĞƌ. ŝďƵũĂƌĞůĚŝĂŐƌĂŵĂĚĞƐĞĐƵĞŶĐŝĂ. /ĚĞŶƚŝĨŝĐĂĐŝſŶĚĞ ŝŶĨŽƌŵĂĐŝſŶ ƌĞƋƵĞƌŝĚĂ. ŐƌĞŐĂƌĐŽŶĚŝĐŝŽŶĞƐƐĞŐƷŶĞůƚŝƉŽ ĚĞŽƌĂĐŝſŶĞŶŝŶŐůĠƐ. Figura 2.12: Arquitectura para el diagrama de secuencia (Gulia and Choudhury, 2016).. En la Figura 2.12, se observa el proceso para generar diagramas de secuencia. Como entrada se tiene un texto plano, que entra a una etapa de pre-procesamiento de análisis y segmentación de sentencias. Se usa la herramienta “Stanford Parser” para obtener la estructura de jerarquı́a del documento usando un analizador. Como paso final se muestra en forma gráfica el diagrama de secuencia. Los resultados muestran que se reduce la brecha entre el lenguaje informal y el lenguaje de modelado formal. Dwarakanath et al. (2013), presentan un método para la extracción automática de glosario de términos desde requisitos en lenguaje natural sin restricciones. Introducen también una técnica lingüı́stica para identificar sustantivos de proceso, sustantivos abstractos y verbos auxiliares. Sigue un proceso con una lista de requisitos de software para entrar en una etapa de pre-procesamiento donde se identifica las oraciones de requisitos como aquellos que comienzan con una etiqueta explı́cita. La extracción es realizada en dos componentes 12.
(25) principales la “unithood determination” y el “termhood determination” como se observa en la Figura 2.13. La primera determina todas aquellas unidades lingüı́sticas que son terminaos candidatos para el glosario de términos. La segunda selecciona o rechaza una unidad como un término. También resuelve la ambigüedad para elegir la unidad correcta como un término. Los términos identificados se colocan en la lista de entidades o lista de acciones del archivo de glosario.. ŽĐƵŵĞŶƚŽ ĚĞƌĞƋƵŝƐŝƚŽƐ. . WƌĞͲƉƌŽĐĞƐŽ ĞƚĞƌŵŝŶĂĐŝſŶĚĞ ƉĂůĂďƌĂƐĐŽŶ ƐŝŐŶŝĨŝĐĂĚŽ ĞƚĞƌŵŝŶĂĐŝſŶĚĞ ƉĞƌŵĂŶĞŶĐŝĂ. . dĠĐŶŝĐĂƐ ůŝŶŐƺşƐƚŝĐĂƐ. . dĠĐŶŝĐĂƐ ůŝŶŐƺşƐƚŝĐĂƐ dĠĐŶŝĐĂƐ ĞƐƚĂĚŝƐƚŝĐĂƐ. . ZĞĚƵĐĐŝſŶĚĞƉĂůĂďƌĂƐƋƵĞƐŽŶ ƐƵƐƚĂŶƚŝǀŽƐĂďƐƚƌĂĐƚŽƐ͕ĂĐĐŝŽŶĞƐ ĂƵdžŝůŝĂƌĞƐŽƚŝĞŶĞŶĂŶĄĨŽƌĂ͘. . >ĂƐƉĂůĂďƌĂƐƋƵĞŶŽƐŽŶ ĂŵďŝŐƵĂƐƐĞŚĂĐĞŶƚĠƌŵŝŶŽƐ͘ ZĞƐŽůǀĞƌƉĂůĂďƌĂƐĂŵďŝŐƵĂƐĚĞ ƉĂůĂďƌĂƐĐŽƌƌĞĐƚĂƐ͘. . 'ůŽƐĂƌŝŽ. /ĚĞŶƚŝĨŝĐĂĚŽƌĚĞĐŝƌĐƵŶƐĐƌŝƉĐŝſŶ DĂŶĞũŽĚĞĐŽŶũƵŶĐŝŽŶĞƐ͕ ŵŽĚŝĨŝĐĂĚŽƌĞƐĂĚũĞƚŝǀĂů͘ EŽŵŝŶĂůŝnjĂĐŝŽŶĞƐĚĞŝĚĞŶƚŝĚĂĚ ZĞĚƵĐĐŝſŶĚĞĚĂƚŽƐĚĞ ĞůĞŵĞŶƚŽƐ͘ ^ĂůŝĚĂ͗hŶĂůŝƐƚĂĚĞƚŽĚĂƐůĂƐ ƉĂůĂďƌĂƐ͘. Figura 2.13: Proceso para la extracción de glosario de términos (Dwarakanath et al., 2013).. 2.2.. Conclusiones del capı́tulo. Este capı́tulo, presentó el análisis de diversos artı́culos, sobre el tema de investigación que abarcamos, el que está orientado a la elicitación de requisitos de software, donde se sintetizan las principales caracterı́sticas de las técnicas, modelos y arquitecturas propuestas, en las cuales se observa que la literatura revisada sobre ingenierı́a de software no contempla el comportamiento estático y dinámico de las caracterı́sticas especificas de las necesidades del usuario por tal motivo nuestra propuesta plantea la solución de dichas limitaciones en las reglas de escrituras propias del lenguaje que generan errores en la compresión de información entre los actores que participan en el desarrollo de sistemas.. 13.
(26) Capı́tulo 3. Fundamentos teóricos. En este capı́tulo, presentamos los fundamentos teóricos de la investigación bibliográfica, los cuales serán conceptualizados para permitir el entendimiento del problema seleccionado.. 3.1.. Ingenierı́a de software. La ingenierı́a de software es más que solo programar. Consiste en toda la documentación asociada, principios de diseño o filosofı́as requeridas para hacer que estos programas funcionen como se espera (Achimugu et al., 2014b). Una definición de corte práctico es la aplicación de un enfoque sistemático, disciplinado y cuantificable al diseño, desarrollo, operación y mantenimiento del software (for computing Machinery, 2013; IEEE, 2014). Ası́ mismo, incluye el estudio de estos enfoques; esto es, la aplicación de la ingenierı́a a la creación de software (Juárez-ramı́rez et al., 2013).. 3.2.. Requisitos e ingenierı́a de requisitos. La ingenierı́a de requisitos cumple un papel principal en el proceso de desarrollo de software (S. and L., 2013). Su principio ha sido adoptado por diversas áreas, tales como los juegos serios (Spinelli and Massa, 2017), software educativo (Ruiz Piedra and Gómez Martı́nez, 2013), juegos de computadora (Cooper and Scacchi, 2015; Viana et al., 2014), desarrollo web (Oliveros et al., 2014; Rafael Pedraza-Jiménez, 2013), sistemas de información, entre otros. Para definir la ingenierı́a de requisitos, se debe entender que son los requisitos. Existen varias definiciones, entra las que podemos citar:. 14.
(27) 3.3.. Requisitos. Algunas definiciones de requisitos encontrados en la literatura se enumeran a continuación: Un requisito es simplemente una declaración abstracta de alto nivel de un servicio que debe proporcionar el sistema o una restricción de éste (Sommerville, 2015). Un requisito de software es una caracterı́stica que debe exhibir para solucionar cierto problema del mundo real. Por lo tanto, un requisito del software es una caracterı́stica que se debe exhibir por el software desarrollado o adaptado para solucionar un problema particular (IEEE, 2014). Los requisitos son capturado en forma escrita para facilitar la comunicación entre los interesados, los analistas, y los desarrolladores. Al escribir el requisitos cuidadosamente, el equipo se asegura de que el producto correcto es construido (Robertson and Robertson, 2013). Un requisito es un atributo necesario en un sistema, una declaración que identifica una capacidad, caracterı́stica o factor de calidad de un sistema para que tenga valor y utilidad para un cliente o usuario (Young, 2004). Los requisitos bien entendidos son la base para determinar el éxito del software implementado, lo cual permite satisfacer las necesidades de los usuarios; dichas necesidades son las que se definen en los requisitos. (Cueva and Sucunuta, 2014). Los requisitos pueden ser categorizados en varios niveles de abstracción, alcance y detalle. Por ejemplo (Vedia, 2017): Requisitos muy generales que expresan con términos amplios qué es lo que el sistema deberı́a hacer. Requisitos funcionales que definen partes de la funcionalidad del sistema. Requisitos no funcionales que agregan restricciones al desarrollo del sistema. Requisitos de implementación que declaran cómo el sistema debe ser implementado. Requisitos de rendimiento que especifican un desempeño mı́nimo aceptable para el sistema. Requisitos de usabilidad que especifican el tiempo máximo aceptable para demostrar el uso del sistema.. 3.4.. Ingenierı́a de requisitos. La ingenierı́a de requisitos define procesos sistemáticos, que introducen una estrategia sólida para derivar una definición de productos de software, es por ello que su objetivo es establecer los requisitos del sistema a desarrollar y su gestión posterior (Vedia, 2017). Algunos autores definen a la ingenierı́a de requisitos como sigue: 15.
(28) Cravero y otros, señalan que el objetivo primordial de la ingenierı́a de requisitos para un AD (almacén de datos) es representar a los usuarios, sus objetivos y las relaciones entre los mismos, con el fin de alcanzar los objetivos del negocio (Cravero et al., 2013). GWEBOK define que la ingenierı́a de requisitos es ampliamente utilizada para indicar el tratamiento sistemático de los requisitos (IEEE, 2014). El objetivo de Ingenierı́a de requisitos es crear proyectos exitosos que cumplan con los requisitos de los clientes (Yozgyur, 2014). La ingenierı́a de requisitos es el proceso de desarrollar una especificación de software. Las especificaciones pretender comunicar las necesidades del sistema del cliente a los desarrolladores del sistema (Sommerville, 2015).. 3.5.. Clasificación de los requisitos. Los requisitos del sistema de software a menudo se clasifican como requisitos funcionales o requisitos no funcionales (Garcı́a, 2015; Sommerville, 2015): Requisitos funcionales: son enunciados acerca de servicios que el sistema debe proveer, de cómo deberı́a reaccionar el sistema a entradas particulares y de cómo deberı́a comportarse el sistema en situaciones especı́ficas. En algunos casos, los requisitos funcionales también explican lo que no debe hacer el sistema (Sommerville, 2015). El requisito funcional se refiere a un comportamiento funcional que los usuarios / clientes quieren que el sistema haga (Laplante, 2017). Adicionalmente, estos requisitos tienen la particularidad que son visibles a los usuarios (Medeiros et al., 2017). Requisitos no funcionales: son restricciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones de tiempo, restricciones en el proceso de desarrollo, como restricciones impuestas por estándares. Los requisitos no funcionales se suelen aplicar al sistema como un todo, más que a una caracterı́stica o servicio individual del sistema (Sommerville, 2015). Dicho de otra manera, los requisitos no funcionales expresan qué tan bien debe funcionar un sistema (Dabbagh and Lee, 2014). Algunos requisitos no funcionales son de seguridad, integridad de datos y usabilidad (Garg and Singhal, 2017). Los requisitos no funcionales expresan qué tan bien o mal es el funcionamiento del sistema en términos de atributos de calidad como fiabilidad, seguridad, rendimiento o usabilidad (Fazlullah Khan, 2016; Laplante, 2017). Es por eso que los requisitos no funcionales a veces se conocen como atributos de calidad o requisitos de calidad (Misaghian and Motameni, 2016). Los requisitos no funcionales junto con los requisitos funcionales comprenden el sistema de software completo. Los requisitos funcionales son exigidos por el cliente y destinados a los usuarios previstos, ya que satisfacen las necesidades o expectativas de 16.
(29) los usuarios (Varun Gupta and jin Kim, 2017). Los usuarios generalmente no solicitan directamente requisitos no funcionales, sin embargo, estos requisitos determinan el nivel de aceptabilidad del sistema de software (Chopra et al., 2016; Varun Gupta and jin Kim, 2017). También, se ha reconocido que el logro de requisitos no funcionales junto con los requisitos funcionales es fundamental para el éxito de un sistema de software (Dabbagh and Lee, 2013; Dabbagh et al., 2016; Dabbagh and Peck Lee, 2015).. 3.6.. Procesos en ingenierı́a de requisitos. La ingenierı́a de requisitos se ha convertido en una disciplina bien establecida donde una amplia gama de enfoques, técnicas y herramientas se han propuesto (Daneva et al., 2014). Hay 5 sub procesos en la ingenierı́a de requisitos, denominados: elicitación de requisitos, análisis de requisitos, especificación, verificación y administración de requisitos (Cueva and Sucunuta, 2014; Sommerville, 2015; Sánchez, 2015; Vedia, 2017):. 3.6.1.. Elicitación de requisitos. La elicitación de requisitos es el proceso de reunir los requisitos correctos de diferentes fuentes (por ejemplo, usuarios, partes interesadas) utilizando las técnicas adecuadas para alcanzar las necesidades de los usuarios y el sistema (Bani-Salameh and Al jawabreh, 2015). Los objetivos del proceso de la elicitación de requisitos son comprender el trabajo que hacen los interesados y cómo pueden usar un nuevo sistema para ayudar a respaldar ese trabajo. Durante la obtención de requisitos, los ingenieros de software trabajan con las partes interesadas para conocer el dominio de la aplicación, las actividades laborales, los servicios y las caracterı́sticas del sistema que desean los interesados, el rendimiento requerido del sistema, las limitaciones de hardware, etc. (Sommerville, 2015). La obtención de requisitos tiene que ver con el origen de los requisitos de software y la forma en que el ingeniero de software puede recopilarlos (Ahmed and Kanwal, 2014). La elicitación de requisitos es el primer subproceso de ingenierı́a de requisitos (RE) y nos obliga a utilizar enfoques de toma de decisiones grupales para seleccionar y priorizar requisitos (Sadiq and Jain, 2013). Este subproceso afecta en cascada sobre otros subprocesos de RE, por lo que juega un papel importante. Identifica los requisitos de un producto al considerar la necesidad de los usuarios y clientes (Misaghian and Motameni, 2016).. 3.6.2.. Análisis de requisitos. En el análisis de requisitos, el interesado se comunica y negocia entre sı́ para comprender el requisito, mientras que esta negociación, de que se eleve el conflicto (Al-Zawahreh and Almakadmeh, 2015; Sharma and Pandey, 2013).. 3.6.3.. Especificación de requisitos. La especificación de requisitos es el proceso de anotar los requisitos del usuario y del sistema en un documento de requisitos. Idealmente, los requisitos del usuario y del sistema 17.
(30) deberı́an ser claros, inequı́vocos, fáciles de entender, completos y consistentes (Sommerville, 2015). Para sistemas complejos en esta fase (Lazo and Botero, 2017) señalan que se elaboran tres tipos de documentos: definición del sistema, requisitos del sistema, y requisitos del software.. 3.6.4.. Validación de requisitos. La validación de requisitos es el proceso de verificar que los requisitos definen el sistema que el cliente realmente quiere. Se superpone con la elicitación y el análisis, ya que se trata de encontrar problemas con los requisitos. La validación de requisitos es crı́ticamente importante porque los errores en un documento de requisitos pueden conducir a grandes costos por tener que rehacer, cuando estos problemas se descubren durante el desarrollo o después de que el sistema está en servicio (Sommerville, 2015).. 3.6.5.. Administración de requisitos. Durante el proceso de desarrollo de software, la comprensión de los interesados sobre el problema cambia constantemente (Sommerville, 2015). La administración de requisitos es una actividad clave en el proceso de ingenierı́a de requisitos y tiene como objetivo principal supervisar la evolución de las necesidades, ya sea mediante la búsqueda de nuevas necesidades, o mediante la observación de las deficiencias en las necesidades registradas en los productos en desarrollo (Soares et al., 2013). Por lo tanto, la administración de requisitos es una relación de actividades, que colaboran para el equipo involucrado en el proyecto, identificar, controlar y rastrear los requisitos en cualquier momento (Matuda and Begosso, 2013).. 3.7.. Proceso en la elicitación de requisitos. El primer paso durante el desarrollo del software, la ingenierı́a de requisitos, es muy crı́tico debido al alto esfuerzo (en tiempo y costos) que debe hacerse para corregir los errores detectados posteriormente que se han realizado en esta fase inicial del ciclo de vida del software (Fehrenbach, 2013). Sommerville (2015), considera un modelo de elicitación y proceso de análisis dividido en cuatro fases. En la Figura 3.1 se observa las actividades del proceso. 1. Descubrimiento y comprensión de los requisitos: este es el proceso de interactuar con las partes interesadas del sistema para descubrir sus requisitos. Los requisitos de dominio de los interesados y la documentación también se descubren durante esta actividad. 2. Clasificación y organización de los requisitos: esta actividad toma la colección no estructurada de requisitos, agrupa los requisitos relacionados y los organiza en grupos coherentes. 3. Priorizar requisitos y negociación: cuando se involucran múltiples partes interesadas, los requisitos entrarán en conflicto. Esta actividad se relaciona con priorizar requisitos 18.
(31) y la búsqueda y resolución de conflictos de requisitos a través de la negociación. Por lo general, las partes interesadas deben reunirse para resolver las diferencias y comprometerse los requisitos aceptados. 4. Documentación de requisitos: los requisitos se documentan y se ingresan en la próxima ronda de la espiral. En esta etapa, es posible que se produzca un borrador inicial de los documentos de requisitos de software, o los requisitos pueden simplemente mantenerse informalmente en pizarras, sitios web colaborativos u otros espacios compartidos.. ϭ͘ĞƐĐƵďƌŝŵŝĞŶƚŽLJ ĐŽŵƉƌĞŶƐŝſŶĚĞ ƌĞƋƵŝƐŝƚŽƐ. Ϯ͘ůĂƐŝĨŝĐĂĐŝſŶLJ ŽƌŐĂŶŝnjĂĐŝſŶĚĞůŽƐ ƌĞƋƵŝƐŝƚŽƐ. ϰ͘ŽĐƵŵĞŶƚĂĐŝſŶĚĞ ƌĞƋƵŝƐŝƚŽƐ. ϯ͘WƌŝŽƌŝnjĂĐŝſŶLJ ŶĞŐŽĐŝĂĐŝſŶĚĞ ƌĞƋƵŝƐŝƚŽƐ. Figura 3.1: La elicitación de requisitos y el proceso de análisis (Sommerville, 2015).. 3.8.. Técnicas de elicitación de requisitos de software. La elicitación de requisitos es la fase más crı́tica en la ingenierı́a de requisitos. Es la fase en la que los analistas obtienen, entienden y validan los requisitos de un sistema de las partes interesadas (Anwar and Razali, 2014). Su objetivo es identificar la información que determina qué caracterı́sticas debe tener el sistema de software (Carrizo et al., 2014). Hay muchas técnicas y metodologı́as para direccionar los problemas de la elicitación de requisitos de software (Meth et al., 2013; Sharma and Pandey, 2013, 2014; Sutcliffe and Sawyer, 2013). Al-Zawahreh and Almakadmeh (2015); Yousuf and Asger (2015) divide las técnicas de elicitación de requisitos en cuatro categorı́as: Técnicas tradicionales: comunicación verbal entre partes interesadas y expertos. Manera natural simple para definir el requisito necesario tales como una entrevista. Técnicas de colaboración: proporciona una forma diferente de conectar a los interesados con los analistas para determinar los requisitos deseados, como Focus Group (Grupo focalizado). Técnicas cognitivas: trata los documentos para extraer conocimiento y define el requisito con el Análisis de documentos. 19.
(32) Técnicas de observación: una sólida comprensión del problema del dominio a través de la observación de las acciones humanas, tales como: La observación. Según Sommerville (2015), la elicitación de requisitos implica la reunión con las partes interesadas de diferentes tipos para descubrir información sobre el sistema propuesto. Hay dos enfoques fundamentales para la elicitación de requisitos: Entrevistas: donde se habla con las personas acerca de lo quieren hacer Observación: donde el analista mira a las personas haciendo su trabajo para ver que artefactos usan y como lo usan. Matuda and Begosso (2013), menciona la técnica del prototipo, dado de que permite al analista de sistemas determinar las primeras reacciones del usuario con relación al sistema. Las reacciones pueden ser adquiridas por medio de entrevistas, observación, reportes, y cuestionarios, que muestran la opinión de cada persona respecto al prototipo. Dichas informaciones son importantes para que se pueda medir y establecer las prioridades, como también dar rumbo al sistema. Prototipo de remiendo: este prototipo sólo tiene la capa de interfaz programada, no contiene caracterı́sticas reales. Tiene todas las caracterı́sticas necesarias del sistema, pero es ineficiente. Se vuelve útil para la interacción del usuario con el sistema, para que se familiaricen con las pantallas, y los tipos de entradas y salidas de datos. Prototipo no operativo: este prototipo tiene por objetivo probar algunos aspectos del sistema en desarrollo. Presume como debe ser la rutina del software, y se implementa todas las capas. Los usuarios del sistema también podrán tomar decisiones, a partir de las entradas y salidas obtenidas del prototipo. Primero de una serie: este prototipo consiste en la creación de un primer modelo, un piloto. Primero se realizan pruebas en este modelo piloto, luego se desarrollan los demás con caracterı́sticas uniformes al primero. Prototipo de Caracterı́sticas Seleccionadas: este tipo de prototipo establece la construcción de un modelo operacional que abarca algunas das caracterı́sticas que el sistema deberá tener. Por ejemplo, si el usuario solicita seis funcionalidades distintas, tres de ellas serán implementadas en el prototipo, y a medida que el cliente manipula el prototipo, comunica al analista o que considera funcional o lo que no es pertinente. Según Garg et al. (2015), existen diferentes maneras de lograr la información requerida en la obtención de requisitos que incluyen enfoques directos y enfoques indirectos. En el enfoque directo se interactúa con el experto del dominio y en el enfoque indirecto se clasifica en función de qué tipo de información es obtenida.. 20.
(33) Enfoque directo: el objetivo es mejorar la comprensión de los problemas del sistema que se utiliza actualmente. Las técnicas más comunes utilizadas son: entrevistas, estudio de casos, creación de prototipos. Es ideal para obtener más conocimiento sobre el sistema y los datos genuinos. Para que estos métodos sean exitosos, el experto en el dominio debe ser razonablemente coherente y estar dispuesto a compartir información. Enfoque indirecto: en este enfoque, recopilar información no es una tarea fácil porque la información está disponible en forma distribuida. Cuestionarios, análisis de documentos son sus ejemplos. Tiene una gran cantidad de datos que se pueden obtener del análisis de los documentos. Los resultados obtenidos de este tipo de investigación son fáciles de medir y una prueba aplicable puede sugerir ser derivada de ellos.. 3.9.. Metodologı́a de elicitación de requisitos. En la literatura consultada se encontraron diferentes métodos para recabar información de requisitos de software.. 3.9.1.. La metodologı́a de Zawahreh. El procedimiento propuesto tiene como fin lograr una alta calidad de requisitos para el diseño de software. El proceso de obtención de requisitos comienza con el análisis del analista del dominio del problema para determinar los requisitos a través de diversas actividades (AlZawahreh and Almakadmeh, 2015). Luego, se analiza y estudia la fuente del dominio tales como: objetivo del software, dominio de conocimiento, reglas de negocio y el entorno de la organización. Para seleccionar la técnica apropiada se siguen cinco pasos: Usar los requisitos que fueron extraı́dos del usuario. Determinar las caracterı́sticas del proyecto. Determinar las caracterı́sticas situacionales. Determinación de las técnicas disponibles con caracterı́sticas especı́ficas. Uso de pautas.. 3.9.2.. El modelo de Medeiros. Juliana Medeiros and Silva (2016); Medeiros et al. (2017), plantean un enfoque para especificar requisitos basados en prácticas de diseño dirigidas al desarrollador. En la estructura, las necesidades del cliente y los requisitos del sistema se representan utilizando una vista única que integra tres perspectivas: Modelar los conceptos de negocios (entidades, atributos y relaciones).. 21.
(34) Describir los criterios de aceptación que pueden representar las reglas del negocio, pero también los requisitos técnicos, requisitos no funcionales o cualquier otra restricción. Describir los elementos de interfaz visual entre el sistema y el usuario (maquetas). Esto proporciona una cobertura de requisitos más amplia, comparado como cuando solo se cubren los requisitos del usuario.. 3.9.3.. Metodologı́a de Tiwari. Primero, se identifica varios atributos en tres dimensiones importantes denominadas proyecto, personas y el proceso de desarrollo de software que puede influir en el resultado de un proceso de obtención. Luego, se construye tres matrices por separado para cada dimensión, que muestra una relación entre las técnicas de elicitación y las tres dimensiones de un software. Finalmente, se proporciona un criterio de mapeo y los usamos en la selección de un subconjunto de técnicas de obtención (Tiwari and Rathore, 2017). En la Figura 3.2 se observa las actividades del proceso.. WZKz dK ^K&dtZ DWZ E/K. ϭ͘/ĚĞŶƚŝĨŝĐĂƌůŽƐĂƚƌŝďƵƚŽƐĚĞů Ϯ͘/ĚĞŶƚŝĨŝĐĂƌĐĂƌĂĐƚĞƌşƐƚŝĐĂƐĚĞ ƉƌŽLJĞĐƚŽ ůĂƐƉĞƌƐŽŶĂƐ. ϯ͘/ĚĞŶƚŝĨŝĐĂƌĂƚƌŝďƵƚŽƐĚĞů ƉƌŽĐĞƐŽ. ϯWD;ƚŚƌĞĞ ƉŵĂƚƌŝdžͿͼ dĠĐŶŝĐĂĚĞĞůŝĐŝƚĂĐŝſŶ;d Ϳ d džWƌŽLJĞĐƚŽ͕d džƉĞƌƐŽŶĂ͕d džWƌŽĐĞƐŽ. &ƵŶĐŝſŶĚĞŵĂƉĞŽ &;ƉͿ. dĠĐŶŝĐĂĚĞĞůŝĐŝƚĂĐŝſŶ ĚĞƌĞƋƵŝƐŝƚŽƐ. Figura 3.2: Técnica de elicitación de requisitos (Tiwari and Rathore, 2017).. 3.10.. Caracterı́sticas de los requisitos. Según Gálvez (2016); Wiegers and Beatty (2013), las caracterı́sticas deseables de los requisitos de software está conformado por siete caracterı́sticas, como se observa en la Figura 3.3 y se detallan a continuación: Completo: un requisito está completo si no necesita ampliar detalles en su redacción, es decir, proporciona la información suficiente para su comprensión.. 22.
(35) Correcto: cada requisito debe describir con exactitud la funcionalidad para ser construida (Wiegers and Beatty, 2013). Realizable: debe ser posible poner en práctica cada requisito dentro de las capacidades conocidas y las limitaciones del sistema en su entorno de operaciones (Wiegers and Beatty, 2013). Necesario: un requisito es necesario, si cuando se prescinde del mismo provoca una deficiencia en el sistema a construir; además cuando sus caracterı́sticas fı́sicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto. Importante: dentro del conjunto de requisitos, alguno de ellos debe ser más importante que los otros; en este proceso deben intervenir los interesados en el desarrollo del software. No ambiguo: un requisito no tiene ambigüedades cuando se lo puede interpretar de una sola forma, y por lo tanto el lenguaje usado en su definición no causa confusiones al lector. Verificable: un requisito es verificable cuando puede ser cuantificado de manera que se pueden utilizar los métodos de verificación de inspección, análisis, demostración o pruebas.. ŽŵƉůĞƚŽ. ŽƌƌĞĐƚŽ. ZĞĂůŝnjĂďůĞ. EĞĐĞƐĂƌŝŽ. WƌŝŽƌŝnjĂďůĞ. EŽĂŵďŝŐƵŽ. sĞƌŝĨŝĐĂďůĞ. ĂƌĂĐƚĞƌşƐƚŝĐĂƐĚĞůŽƐƌĞƋƵŝƐŝƚŽƐ. Figura 3.3: Caracterı́sticas de los requisitos (Wiegers and Beatty, 2013).. 3.11.. Herramientas para la elicitación de requisitos. Existen varias herramientas para el proceso de la elicitación de requisitos. Las herramientas de elicitación difieren entre sı́ de acuerdo con el tipo de sistemas y las técnicas de obtención a las que atienden (Ahmed and Kanwal, 2014). Detallamos algunas herramientas a continuación: RequisitePro: una herramienta para la gestión de los requisitos comercializada por IBM (Garcia and Pacheco, 2016). Permite que los requisitos se encuentren documentados bajo estándares recomendados por IEEE, ISO, CMM y RUP, entre otros (Vedia, 2017). Rational DOORS: esta herramienta permite capturar, analizar y administrar un rango de información para asegurar el cumplimiento del proyecto en cuanto a requisitos creada por Quality Systems and Software (Vedia, 2017). 23.
(36) IRQA: soporta los procesos de recolección, análisis y construcción de especificación de requisitos (Vedia, 2017). TOOL RAT: es un asistente que ayuda a los analistas a redactar los requisitos recopilados. Usa un conjunto de patrones, y va guiando paso a paso el proceso de escritura, sugiriendo el siguiente término (Company, 2017). TOOL TESSI: en la herramienta se ofrece un refinamiento textual de la especificación de requisitos que se puede llamar descripción de requisitos. Al trabajar con él, el analista es forzado por la herramienta para completar y explicar los requisitos y para especificar los roles de las palabras en el texto en el sentido del análisis orientado a objetos. Durante este proceso, TESSI construirá automáticamente un modelo UML(lenguaje de modelado unificado).. 3.12.. Conclusiones del capı́tulo. Este capı́tulo, presentó los requisitos conceptuales, necesarios para comprender la investigación y la propuesta planteada en el capı́tulo 4, las cuales se clasificaron como necesarias, después de una recolección y análisis de información sobre sobre la elicitación de requisitos de software.. 24.
(37) Capı́tulo 4. Propuesta. En este capı́tulo, presentamos los detalles del trabajo realizado, el cual tiene como objetivo proponer un modelo hı́brido para la elicitación de requisitos de software basado en una sintaxis controlada.. 4.1.. Propuesta. Se propuso un modelo hı́brido para la elicitación de requisitos de software basado en una sintaxis controlada. Por tal motivo, nuestra propuesta planteó reglas de escritura para describir requisitos de software sin ambigüedad propias del lenguaje que generan errores en la compresión de información entre los actores que participan en el desarrollo de sistemas. La propuesta se basó en la investigación de Thongglin et al. (2012) y Umber and Bajwa (2012) debido a que reportaron un buen avance para tratar la ambigüedad de requisitos de software. En base a las dos investigaciones se propuso plantear la descripción estática y dinámica adaptada al idioma Español con las principales caracterı́sticas de las investigaciones propuestas por los autores anteriormente citados. Nuestro modelo hı́brido se clasifica en dos categorı́as: Descripción estática: define las caracterı́sticas del sistema tales como atributos, propiedades, restricciones, jerarquı́a, entidades y relaciones entre entidades del sistema deseado. Descripción dinámica: define el comportamiento y la interacción entre los componentes, actores y entidades del sistema.. 25.
Figure
+7
Documento similar
Products Management Services (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in
This section provides guidance with examples on encoding medicinal product packaging information, together with the relationship between Pack Size, Package Item (container)
Cedulario se inicia a mediados del siglo XVIL, por sus propias cédulas puede advertirse que no estaba totalmente conquistada la Nueva Gali- cia, ya que a fines del siglo xvn y en
No había pasado un día desde mi solemne entrada cuando, para que el recuerdo me sirviera de advertencia, alguien se encargó de decirme que sobre aquellas losas habían rodado
Habiendo organizado un movimiento revolucionario en Valencia a principios de 1929 y persistido en las reuniones conspirativo-constitucionalistas desde entonces —cierto que a aquellas
The part I assessment is coordinated involving all MSCs and led by the RMS who prepares a draft assessment report, sends the request for information (RFI) with considerations,
De hecho, este sometimiento periódico al voto, esta decisión periódica de los electores sobre la gestión ha sido uno de los componentes teóricos más interesantes de la
Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de
