Uso de Escenarios. en la Derivación de Software

Transcripción

1 Uso de Escenarios en la Derivación de Software Tesis Doctoral Graciela Dora Susana Hadad Director de tesis: Asesor Científico: Prof. Dr. Julio Cesar Sampaio do Prado Leite Pontificia Universidade Catolica do Rio de Janeiro Prof. Ing. Jorge Horacio Doorn Universidad Nacional de La Plata Facultad de Ciencias Exactas Universidad Nacional de La Plata Argentina

2 Resumen Esta tesis presenta una estrategia en la Ingeniería de Requisitos, denominada SDRES, que intenta abordar temas poco tratados en la práctica real, tales como los cambios constantes en los requisitos, defectos del software originados en los requisitos, el contexto organizacional que rodea al sistema de software y la consideración de requisitos de calidad. Esta estrategia está dirigida por modelos (Léxico Extendido del Lenguaje, Escenarios y Documento de Requisitos) y orientada al cliente, por ello utiliza sus modelos escritos en lenguaje natural como medio de comunicación y elicitación. SDRES tiene en cuenta la calidad de los modelos que produce mediante procesos de verificación y validación. Para cada actividad de la estrategia se presenta un conjunto de heurísticas y recomendaciones. Se encara el tema de evolución y versionado de los modelos, así como distintas modalidades de utilizar la estrategia según la complejidad del problema, el conocimiento sobre el mismo y otras características. Abstract The present thesis shows a Requirements Engineering strategy, called SDRES, which proposes to face topics rarely treated in real practice, such as continuous changes in requirements, software defects brought in requirements, the organisational context surrounding the software system and the quality treatment of requirements. This strategy is driven by models (Language Extended Lexicon, Scenarios and Software Requirements Specification) and oriented to the client. Therefore it uses models written in natural language as means of communication and elicitation. SDRES keeps in mind the quality of the produced models by means of verification and validation processes. For each activity of the strategy a set of heuristic and recommendations is presented. The evolution topic and model versioning is treated, as well as different modalities to use the strategy according to the complexity of the problem, the knowledge on the problem and other characteristics. «Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.» Antoine de Saint Exupery i

3 Índice Descripción Página Lista de Figuras vi Lista de Tablas viii Lista de Acrónimos Utilizados ix 1. Introducción Motivación La importancia de los requisitos Errores en el proceso de desarrollo de software La Ingeniería de Requisitos y la Ingeniería de Software Evolución de los requisitos Reflexiones Objetivos y Trabajo realizado Estructura de la tesis Ingeniería de Requisitos Consideraciones iniciales El Proceso de la Ingeniería de Requisitos Contexto del proceso de la IR Aspectos ético contractuales de la IR Características y Actividades del proceso de la IR Elicitación Modelado Análisis Gestión de Requisitos Rastreo de los Requisitos Comparación de taxonomías de actividades en la IR La Ingeniería de Requisitos en los Modelos de Proceso de Software Modelos de Proceso de Software Observaciones sobre los Modelos de Proceso de 49 Software 2.4. Métodos de la Ingeniería de Requisitos Introducción Técnicas tradicionales de Análisis de Sistemas Métodos Orientados a Objetos Comparando técnicas estructuradas vs orientadas a 55 objetos desde la IR Otros métodos en la IR La IR en el Proceso Unificado Métodos Ágiles Características generales Relación con los métodos clásicos y la IR La Programación extrema 69 ii

4 Descripción Página 2.6. Los Requisitos Requerimientos, Requisitos y Especificaciones Qué versus Cómo Propiedades y Atributos de los requisitos Taxonomía de requisitos Documento de Definición de Requisitos Uso de Glosarios en el desarrollo de software Introducción a diccionarios y glosarios Estrategias en la IR que usan glosarios Escenarios y Casos de Uso Definición de Escenario y Caso de Uso Estrategias basadas en escenarios en la IR Técnica de Inspección de Requisitos El framework: Client-Oriented Requirements Baseline SDRES, una Estrategia en la Ingeniería de Requisitos Introducción Etapas de la estrategia La evolución de los modelos Tipos de evolución en SDRES Gestión de evolución de los modelos Cómo aplicar y adaptar SDRES Ámbito de aplicación de la estrategia Versionado de los modelos Resumen Léxico Extendido del Lenguaje Introducción El modelo del LEL El proceso de creación del LEL Generalidades del proceso Actividades del proceso Otros tópicos en el proceso Observaciones La técnica del LEL frente a la práctica de glosarios Uso del LEL en otras estrategias Ficha de Información Anticipada Resumen Escenarios Introducción Escenarios Actuales y Escenarios Futuros El modelo de Escenario Observaciones Resumen Escenarios Actuales El proceso de construcción de escenarios actuales Generalidades del proceso Actividades del proceso Observaciones Inspección de escenarios 211 iii

5 Descripción Página Características de la inspección Taxonomía de Defectos El proceso de inspección Intra e Inter inspección de escenarios Administrando el Proceso de Inspección Observaciones Resumen Escenarios Futuros Introducción El proceso de construcción de escenarios futuros Características del proceso Generalidades del proceso Actividades del proceso Enfoques en el modelado de EF Observaciones Resumen Explicitar Requisitos del Software Introducción El proceso de explicitar los requisitos Gestión de requisitos Observaciones Resumen Conclusiones Corolario Consideraciones finales Futuros trabajos 278 Apéndices 280 A. Principales iniciativas en la Ingeniería de Requisitos 280 A.1. Introducción 280 A.2. Fijación de estándares para especificar requisitos 280 A.3. Estándares de calidad para procesos de software que han Incluido estándares para el proceso de IR 281 A.4. Congresos dedicados exclusivamente a esta disciplina 282 A.5. Revistas y libros dedicados exclusivamente al tema 282 A.6. Herramientas comerciales que soportan actividades de 283 la IR A.7. Comunidades informáticas 284 A.7.1. Internacionales 284 A.7.2. Nacionales 284 B. Publicaciones contenidas en la tesis 285 B.1. Publicaciones en Capítulo de Libro 285 B.2. Publicaciones Internacionales con Referato 285 B.3. Publicaciones en Anales de Congresos 285 B.4. Publicaciones Internas con referato 286 B.5. Publicaciones sin referato 286 B.6. Artículos enviados para publicación 287 B.7. Artículos en etapa final de redacción 287 C. Trabajos derivados de esta tesis 288 iv

6 Descripción Página C.1. Tesis relacionadas 288 D. Aplicaciones de la estrategia 290 D.1. Introducción 290 D.2. Ejemplo de Léxico Extendido del Lenguaje 291 D.3. Ejemplo de Escenarios Actuales 303 D.4. Ejemplo de Escenarios Futuros 318 D.5. Ejemplo de Lista de Requisitos 351 E. Modelo de Trazas 356 E.1. Introducción 356 E.2. Ejemplos 360 E.3. Codificación de Entidades EJEMPLO E.4. Tipos de Operaciones EJEMPLO E.5. Codificación de Entidades EJEMPLO E.6. Tipos de Operaciones EJEMPLO F. Aplicación de Inspecciones en Escenarios 374 F.1. Introducción 374 F.2. Intra Inspección 374 F.2.1. Guías de Instrucción Intra Inspección 374 F.2.2. Formularios de Intra Inspección 382 F3. Inter Inspección 393 F.3.1. Guías de Instrucción Inter Inspección 393 F.3.2. Formularios de Inter Inspección 403 F.4. Gestión de Inspección 416 F.4.1. Guías de Instrucción de Gestión de Inspección 416 F.4.2. Formularios de Gestión de Inspección 420 G. Relación entre Escenario y Caso de Uso 425 G.1. Relación entre los tipos de escenarios y de casos de uso 425 G.2. Relación entre los componentes de escenarios y de casos 427 de uso Referencias 430 Agradecimientos 454 v

7 Lista de Figuras Figura Nº Descripción Página 1-1 Catarata de Errores según el Modelo Mizuno Catarata de Errores extendiendo el Modelo Mizuno Evolución de los Errores + Evolución de los Requisitos Gráfico Belady-Lehman Proceso de la Ingeniería de Requisitos Evolución del UdeD frente a las Actividades de la IR Verificación y Validación Sub-actividades de la Negociación Sub-actividades de la Gestión de Requisitos Tipos de Rastreabilidad Modelos de Proceso de Software versus Necesidades de Usuarios Fases y Flujos de Trabajo de RUP Requerimientos versus Requisitos Estructura de SRS según [IEEE Std ] Taxonomía de inspecciones basadas en enfoques de lectura SDRES, una Estrategia en la IR SADT de la Estrategia Evolución por cambios genuinos en el UdeD Evolución por cambios en las expectativas de los usuarios Evolución por mejora en la comprensión de las expectativas Evolución por puesta en servicio parcial del software Evolución por puesta en servicio total del software Nexos en el CORB Registro de Trazas para Versionado Ejemplo de la vista hipertexto entre el LEL, Escenarios y SRS El Modelo del Léxico Extendido del Lenguaje Diagrama de Entidad-Relación del Modelo del LEL SADT del proceso de creación del LEL SADT de la actividad Planear en el proceso del LEL SADT de la actividad Recolectar en el proceso del LEL SADT de la actividad Clasificar en el proceso del LEL Ejemplos de jerarquías de símbolos Ejemplo de homónimos Ejemplo de homónimos con sinónimos Ficha de Información Anticipada Relación entre actividades de la IR y actividades del LEL Diagrama de Entidad-Relación del Modelo de Escenario Diagrama de Entidad-Relación Extendido del Componente Episodios Modelo de Escenario SADT del proceso de construcción de Escenarios Actuales SADT de la actividad Derivar en el proceso de EA 179 vi

8 Figura Nº Descripción Página 6-3 Ejemplo de derivación de un escenario actual Versión final de un escenario actual SADT de la actividad Organizar en el proceso de EA Ejemplo de operación Factorizar Ejemplo de operación Consolidar Ejemplos de Escenarios Integradores Ejemplos de Construcción de Secuencias SADT del proceso de Inspección de Escenarios SADT de la actividad Verificar Forma III: Control Sintáctico del Escenario Forma VI: Cumplimiento del Léxico Forma VII: Control de Ocurrencia de Actores de Escenarios Instrucciones para la Intra forma VI: Cumplimiento del Léxico Forma VI: Control de Precondiciones de Sub-Escenarios Forma VII: Control de Solapamiento de Escenarios Forma XI: Control de Cubrimiento de Impactos del LEL Instrucciones para la Intra forma VI: Control de Precondiciones de Sub-Escenarios 6-20 Forma IV: DEOs por Componente Relación entre actividades de IR y actividades de construcción de EA Ejemplo de evolución de un escenario actual a un escenario futuro Evolución proyectada de Escenarios Actuales a Futuros en el marco de los Objetivos SADT del proceso de construcción de Escenarios Futuros SADT de la actividad Organizar en el proceso de EF Selección de Enfoque para construir EF Recorrido del árbol en modalidad post-order Recorrido del árbol en modalidad pre-order Recorrido del árbol en modalidad híbrida Relación entre actividades de IR y actividades de construcción de EF SADT del proceso de explicitar Requisitos del Software Ejemplo de lista de requisitos de un escenario futuro Trazas semánticas Intra CORB y Extra CORB Relación entre actividades de IR y actividades de explicitar requisitos 274 D-1 Resultados del proceso de derivación y organización para el Sistema de Agenda de Reuniones 303 E-1 Modelo de Trazas para Versionado 358 E-2 Vista de una Traza 359 G-1 Modelo de Caso de Uso 425 G-2 Relaciones entre tipos de escenarios y tipos de casos de uso 426 vii

9 Lista de Tablas Tabla Nº Descripción Página 1-1 Costo relativo de corrección de errores Uso de técnicas en el proceso de la Ingeniería de Requisitos Técnicas V&V en la Ingeniería de Requisitos Comparativo de Actividades de la IR Foco de Valores en los Métodos Ágiles Visiones del Qué y del Cómo Ejemplificando las visiones del Qué y del Cómo Comparación de eficiencia de Lectura basada en Escenarios contra Ad Hoc y Checklist Aplicación de SDRES en los Modelos de Proceso Tipos de Nexos entre Modelos Ejemplos del género en símbolos Datos de casos de estudio utilizando el LEL Tipos de operaciones en la reorganización de escenarios Cuadro comparativo de construcción de escenarios Enfoques para construir escenarios Descripción de los formularios de inspección de Intra escenarios Descripción de los formularios de inspección de Inter escenarios Descripción de los formularios de gestión de inspecciones Datos de casos de estudio sobre Escenarios Actuales Datos de inspecciones controladas sobre Escenarios Actuales Datos de casos de estudio sobre Escenarios Futuros Tipos de requisitos extraídos de escenarios futuros Tipos de relación entre componente y requisito Datos de casos de estudio sobre Requisitos derivados de EF Énfasis de diversas estrategias en las actividades de la IR 277 D-1 Evolución de escenarios actuales para el Sistema de Agenda de Reuniones D-2 Evolución de EA a EF según enfoques para el Sistema de Agenda de Reuniones G-1 Relación entre componentes de Escenario y de Caso de Uso 428 viii

10 Lista de Acrónimos utilizados ACM Association for Computer Machinery CMM Capability Maturity Model CMMI Capability Maturity Model Integration CORB Client-Oriented Requirements Baseline COTS Commercial Off The Shelf CREWS Cooperative Requirements Engineering With Scenarios DEO Discrepancias, Errores y Omisiones DER Diagrama de Entidad-Relación DFD Diagrama de Flujo de Datos EA Escenarios Actuales EF Escenarios Futuros EG Escenarios Generales EI Escenarios Integradores ESPRIT European Strategic Program on Information Technology IEC International Electrotechnical Commission IEEE Institute for Electrical and Electronics Engineers IID Iterative and Incremental Development IR Ingeniería de Requisitos ISO International Standardisation Organisation JAD Joint Application Design LEL Language Extended Lexicon / Léxico Extendido del Lenguaje LN Lenguaje Natural MD Modelo de Diseño NATO North Atlantic Treaty Organisation OMG Object Management Group OMT Object Modeling Technique RAD Rapid Application Development RE Requirements Engineering RF Requisitos Funcionales RNF Requisitos No Funcionales RUP Rational Unified Process SADT Structured Analysis and Design Technique SDRES Scenario Driven Requirements Engineering Strategy SEI Software Engineering Institute SPICE Software Process Improvement and Capability Evaluation SRS Software Requirements Specification TSE Transactions on Software Engineering UB Universidad de Belgrano - Argentina UdeD Universo de Discurso UML Unified Modelling Language UNCPBA Universidad Nacional del Centro de la Provincia de Buenos Aires ix

11 UNLaM UTN V&V XP Universidad Nacional de La Matanza Universidad Tecnológica Nacional Verificación y Validación extreme Programming / Programación extrema x

12 Capítulo 1 Introducción «The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.» F. Brooks, "No Silver Bullet", IEEE Computer, Motivación La importancia de los requisitos La clave del éxito o fracaso de un proyecto de software depende fuertemente de resolver el problema correcto [Rumbaugh 94], es decir, encontrar el conjunto de soluciones adecuadas al problema en el universo de discurso (UdeD) 1. Para lo cual, se debe primero adquirir conocimiento sobre el UdeD, capturando las demandas, necesidades y problemas presentes en él y, luego, determinar que los requisitos especificados para el sistema de software sean los correctos. Los errores en los requisitos incrementan altamente los costos de desarrollo y mantenimiento de los sistemas de software, dado que la corrección de los mismos puede involucrar desde simples adaptaciones al código, el rediseño de algún componente o hasta reformular total o parcialmente la solución propuesta. Es sabido que los costos por corrección de errores en los requisitos se incrementan en cada fase de desarrollo del software. La incidencia del costo de corrección de requisitos erróneos ha sido ampliamente estudiada por autores como Michael Fagan [Fagan 74], Barry Boehm [Boehm 76], Bell y Thayer [Bell 76], Edmund Daly [Daly 77], Victor Basili [Basili 81] y Alan Davis [Davis 93] entre otros. Barry Boehm [Boehm 81] estudió varios proyectos de desarrollo de software de gran envergadura para determinar el costo de corrección de errores en requisitos (ver Tabla 1-1), errores que eran descubiertos tardíamente en el proceso de desarrollo. Como se puede observar en la Tabla 1-1, en el caso de un requisito erróneo que permanece sin ser detectado ni corregido hasta la etapa de operación, su reparación puede costar hasta 100 veces más que si fuera 1 Universo de discurso [Leite 94]: todo el contexto en el cual el software se desarrolla e incluye todas las fuentes de información y toda la gente relacionada con el software. Es la realidad acotada por el conjunto de objetivos establecidos por quienes demandan una solución de software. Las personas involucradas en el proceso de desarrollo son principalmente: usuarios, clientes, ingenieros de software, expertos del dominio, las cuales son denominadas en la literatura con la palabra stakeholders. Capítulo 1 Introducción 1

13 detectado y corregido en la fase de establecimiento de los requisitos. Fase donde se detectó el error Costo promedio Definición de Requisitos 1 Diseño 3-6 Codificación 10 Pruebas de desarrollo Prueba de aceptación Operación Tabla 1-1. Costo relativo de corrección de errores [Boehm 81] Se puntualizan a continuación aquellos aspectos a considerar en los errores en los requisitos [Davis 93]: i) Cuanto más tarde en el ciclo de vida se detecta un error, más costoso es repararlo. El crecimiento de los costos de reparación es producto de la catarata de errores que se producen: errores originados en una etapa se arrastran en fases sucesivas más nuevos errores que se originan en cada una de ellas (ver Figura 1-1). [Mizuno 83] Se debe acotar que el costo de reparación tiene ligado naturalmente un costo de desarrollo previo de los artefactos que se desecharán o rehacerán en la cadena de errores. ii) Muchos errores permanecen latentes y no son detectados hasta bastante después de la etapa en que se cometieron. El 54% de los errores se detectan después de la fase de codificación y prueba. Estos errores provienen en un 45% de la fase de requisitos y en un 9% de la fase de codificación. [Boehm 75] iii) Se están cometiendo demasiados errores. El 56% de los errores tienen su origen en la etapa de requisitos. Informado por Tom DeMarco, citado en [Tavolato 84] Capítulo 1 Introducción 2

14 iv) Los errores de requisitos responden a una clasificación típica. hechos incorrectos 49% omisiones 31% inconsistencias 13% ambigüedades 5% otros (requisitos mal ubicados) 2% [Basili 81] v) Los errores en los requisitos pueden detectarse. La detección puede realizarse a través de distintas técnicas: ad hoc, inspecciones, pruebas unitarias, pruebas de integración, evaluación (pruebas de aceptación), otros. Las inspecciones detectan el 65% de errores, las pruebas unitarias: 10%, pruebas de integración: 6%, evaluación: 10%, otros: 10%. [Davis 93] Los puntos recién mencionados se pueden resumir en las siguientes conclusiones [Davis 93]: Se cometen muchos errores de requisitos. Muchos de esos errores se detectan tardíamente. Sin embargo, muchos de esos errores pueden detectarse tempranamente. No detectar los errores contribuye al incremento de costos en el software. Diversas estadísticas realizadas a lo largo de las últimas décadas referidas a fracasos en proyectos de software [Alford 79] [Boehm 81] [GAO 92] [Faulk 92] [Lutz 93] [CHAOS 95] concluyen que los requisitos son la fuente principal de problemas en la mayoría de dichos proyectos: requisitos inadecuados, cambios en los requisitos durante el ciclo de vida, requisitos no bien comprendidos y requisitos incompletos. En 1987, el Departamento de Defensa de los Estados Unidos generó un informe [Brooks 87b] sobre los problemas de calidad y productividad en el desarrollo de software militar, que abrió las puertas para la investigación de la llamada crisis del software, ya reconocida desde fines de la década del 60 [Naur 68]. Paralelamente, acaecieron en la práctica industrial fracasos paradigmáticos en proyectos de gran envergadura, tales como el Sistema de Control del Tráfico Aéreo de la Administración Federal de Aviación [Gibbs 94] [Stix 94], el Sistema de Administración de Equipaje del Nuevo Aeropuerto Internacional de Denver [GAO 94], el Sistema de Ambulancias de Londres [Finkelstein 96], el Sistema de tiempo real de Paramax System Corporation [Lindstrom 93] y otros. Algunos de los casos más recientes que se pueden mencionar son: el Sistema de Reservas del Ferrocarril Nacional francés (dos días fuera de uso por defectos en la actualización de un programa, 2004), el Sistema de Gestión de Energía de General Electric (causó un apagón en el noreste de Estados Unidos y parte de Canadá, debido a un error de Capítulo 1 Introducción 3

15 programación en el sistema de gestión y monitoreo de energía de un proveedor que provocó la caída del resto de sistemas que no preveían esta falla, 2003), el software de la Estación Espacial Internacional (varios problemas tales como la operación de un brazo del robot de la estación, 2001), el programa de simulación del puente Millenium en Londres (falló debido a una incorrecta estimación de la cantidad de peatones, 2000), entre otros muchos. En respuesta a la baja calidad de los productos de software con altos costos de corrección y mantenimiento, muchos desarrolladores de software e investigadores se han planteado la necesidad de profundizar en el proceso previo al diseño del software. Sus investigaciones y prácticas profesionales han apuntado a garantizar la producción de software de alta calidad y bajo costo basándose en el establecimiento de un punto de partida de alta confiabilidad, mediante la detección de errores lo más tempranamente posible. Es necesario entonces contar con procesos de producción de requisitos confiables. En esta sub-sección, se ha dado cuenta de las consecuencias que producen los defectos en los requisitos, cabe mencionar a continuación las fuentes de dichos defectos. El reconocimiento de los defectos en los requisitos mediante el estudio de sus causas y efectos ha permitido, en los últimos años, el establecimiento de procesos de definición de requisitos atentos a esta grave circunstancia Errores en el proceso de desarrollo de software Habitualmente cuando se hace referencia a errores en los requisitos de los sistemas se desliza en forma tácita la idea de que el profesional de software o el proceso de captura han sido el origen de los mismos. Esta suposición, si bien muy difundida, probablemente sea parcialmente falsa ya que muchos de los errores, discrepancias y omisiones que aparecen en los requisitos y naturalmente se propagan al sistema final, ya existían en la fuente de información. En realidad existe una responsabilidad compartida, ya que en los casos en que el defecto está empotrado en la fuente de información, el ingeniero de requisitos tiene algún grado de responsabilidad al no ponerlo en evidencia, especialmente en relación con las discrepancias y omisiones. Mizuno en [Mizuno 83] propuso un modelo para la catarata de errores que se presenta en la Figura 1-1. Si bien este gráfico es notoriamente ilustrativo para comprender el problema de la propagación y la ampliación de los errores a lo largo del proceso de desarrollo de software, contiene varias simplificaciones excesivas que enmascaran algunos aspectos relevantes de la problemática de la Ingeniería de Requisitos. El punto más importante parece ser la visión del problema real como una entidad fuente de todo saber y verdad. No existe un problema real perfecto que constituya la esencia químicamente pura de las necesidades del UdeD y que determine unívocamente los requisitos del sistema de software. Por el contrario, la dificultad realmente reside en que la visión que las organizaciones tienen de ellas mismas es incompleta o incoherente [Godel 62]. Peor aún las Capítulo 1 Introducción 4

16 fuentes de información introducen sus propias contradicciones, sesgos, errores y extemporalidades que obscurecen un poco más la percepción de las necesidades del negocio 2. Problema Real Definición de Requisitos Especificación correcta Especificación errónea Diseño Diseño correcto Diseño erróneo Diseño basado en especificación errónea Implementación Programas correctos Programas con errores Programas basados en diseño erróneo Programas basados en especificación errónea Prueba Funciones correctas Errores corregibles Errores incorregibles Errores escondidos Producto con programas imperfectos Figura 1-1. Catarata de Errores según el Modelo Mizuno [Mizuno 83] El meta-modelo conceptual, que supone un problema real perfecto, asigna además todas las dificultades a: i) la inhabilidad de las fuentes de información para revelar el conocimiento profundo, y ii) la inhabilidad del ingeniero de requisitos para capturar la información relevante y libre de omisiones. Esta visión ha entronizado el concepto de la captura de requisitos, ya que lo único que habría que hacer es descubrir la verdad. De esta manera los requisitos se han reducido a un conjunto de pepitas de oro y por lo tanto la tarea a emprender es tamizar la grava para encontrarlos. El problema real es un agregado de certezas, contradicciones, dudas y 2 En [Jacobson 99] se pone de manifiesto que una complicación en la captura de requisitos son los usuarios por ser éstos una fuente imperfecta de información. Capítulo 1 Introducción 5

17 aspectos no planteados. En otras palabras, sí hay información directamente transformable en requisitos del sistema de software, pero hay mucho más que eso. La tarea del ingeniero de requisitos es mucho más compleja que meramente sonsacar los requisitos, también debe colaborar con el esclarecimiento de las dudas, debe detectar las contradicciones y visualizar las circunstancias no consideradas, entre otras. Adicionalmente, el ingeniero de requisitos contribuye con propuestas de servicios del sistema que en algunos casos complementan la información adquirida y en algunos otros ofrece algún antagonismo con la misma. Los requerimientos, pedidos y demandas de los usuarios son idealmente realizados en el contexto del objetivo de obtener una mejora en los procesos del negocio. Se dice idealmente porque pueden insertarse objetivos personales no claramente explicitados o eventualmente cuidadosamente ocultos. Por el otro lado, las propuestas del ingeniero de requisitos están guiadas por la aspiración de facilitar el desarrollo del artefacto de software, ya sea simplificando el sistema o dotándolo de propiedades que lo acerquen a modelos conceptuales preconcebidos. En la Figura 1-2, se presenta un esquema que extiende el modelo de Mizuno, visualizando el problema real como un agregado de certezas, contradicciones, dudas y aspectos no considerados. En este esquema además se representa el hecho de que las fuentes de información aportan su propia distorsión dificultando, en alguna medida, aún más el proceso de definición de los requisitos del sistema de software, proceso que por otro lado, como se visualiza en la figura, se descompone en tres sub-etapas: elicitación, modelado y especificación 3. Por razones de espacio, no se ha graficado en la Figura 1-2 la cascada de errores que se arrastran en las siguientes etapas de diseño, implementación y prueba. La Figura 1-2 fue confeccionada siguiendo el estilo de la figura original de Mizuno, por lo que conserva las mismas simplificaciones que la original, excepto las ya indicadas modificaciones en la visión del problema real. En ese sentido, el esquema no refleja que sobre los requisitos erróneos se puedan además acumular errores de diseño (sólo se cometen errores de diseño sobre los requisitos correctos) y que los errores de programación se concentran en los fragmentos del sistema correctamente diseñados. Por otra parte, en ambas figuras también se ignora que una actividad de validación forzaría, con un alto costo, la corrección de los errores incorregibles ; así como descubriría en mayor o menor grado los errores escondidos, también con altos costos de corrección. Como se ha mencionado arriba, la tarea del ingeniero de requisitos no es simple, debe tamizar la grava en el UdeD para encontrar información relevante, certera y lo más completa posible, para lo cual debe contar con técnicas y herramientas adecuadas, saber lidiar con personas a distintos niveles de la organización, y seguir los pasos necesarios que le permitan asegurar el mejor resultado. Es decir, el ingeniero de requisitos debe adquirir 3 La especificación puede ser vista como parte del modelado, pero se ha presentado por separado para mostrar más en detalle la cascada de errores. Capítulo 1 Introducción 6

18 habilidades y conocimientos que trascienden el campo tecnológico para entrar en contacto con otras ciencias que le den soporte integral a su actividad. Problema Real Certezas Inconsistencia s Dudas Aspectos no considerados Elicitación Demandas correctas Demandas erróneas Demandas inconsistentes Demandas omitidas Modelado Requisitos candidatos correctos Propuestas correctas Requisitos candidatos erróneos Propuestas erróneas Requisitos basados en demandas erróneas Requisitos basados en demandas inconsistentes Requisitos omitidos Especificación Especificación correcta Especificación errónea Especificación basada en requisitos erróneos Especific. basada en propuestas erróneas Especific. basada en demandas erróneas Especific. basada en demandas inconsistentes Especificación omitida Producto con programas imperfectos Figura 1-2. Catarata de Errores extendiendo el Modelo Mizuno La Ingeniería de Requisitos y la Ingeniería de Software La Ingeniería de Software (término acuñado por primera vez por un grupo de estudio de la NATO en 1968 [Naur 68]) provee un enfoque sistematizado para el desarrollo, operación, mantenimiento y retiro (desmantelamiento) del software [IEEE Std ]. Por lo tanto, como toda disciplina de la ingeniería, debe contar con las siguientes características: tecnologías bien comprendidas, procesos bien definidos, resultado predecible de las etapas del proceso y pasos del proceso repetibles. Se trata de una aspiración a la que tanto la Ingeniería de Software como la Ingeniería de Requisitos se están aproximando día a día, aún cuando Fred Brooks [Brooks 87] haya anunciado que nunca se encontrará la bala de plata: «Ninguna mejora importante en el área de la ingeniería de software aparecerá nunca». Dan Berry coincide con Brooks, pues luego de mostrar la frustración que causa el Capítulo 1 Introducción 7

19 desarrollo de software ya sea desde la aplicación de IR hasta XP, sugiere que tal vez el desarrollo de software sea un arte, independientemente de la cantidad de sistematización lograda en los procesos y métodos elaborados [Berry 02]. Pese a esto, la corriente principal de la Ingeniería de Software procura avanzar y hay mucho terreno para ello, y esto se evidencia en la cantidad y calidad de los trabajos de investigación que se están realizando en esta área. Existe una gran diferencia entre el producto a construir por la ingeniería de software respecto a otras ingenierías. En casi todas las ramas de la ingeniería se genera habitualmente un bosquejo / maqueta / plano / diagrama u otro elemento que representa el artefacto a construir y, a través de él, se planifica la tarea de construcción y se asegura que responda a las expectativas de los clientes. Sin embargo, una dificultad especial que se le presenta a la ingeniería de software es justamente la representación del producto a construir, pues dicho producto (el software) es en sí mismo una representación del mundo real, entonces los documentos y/o modelos que describen el software a construir son una representación de una representación a ser creada [Kovitz 02]. Esto implica la necesidad de prestar especial atención a la generación de esos documentos y/o modelos que representarán a ese artefacto, lo que indudablemente requiere un considerable esfuerzo y tiempo de elaboración, para que sean precisos, correctos y lo más completos posibles. Esta es la tarea básica de la Ingeniería de Requisitos como pilar del desarrollo de software y, como tal, debe considerarse en el contexto de la Ingeniería de Software y de la Ingeniería de Sistemas [Kaindl 02]. Por tanto, se debe observar que la Ingeniería de Software se basa en dos conceptos fundamentales: producto [Gunther 78] y sistema. Es decir, tiene simultáneamente tanto un enfoque ingenieril como un enfoque sistémico. La función de la ingeniería es procurar productos de mejor calidad dentro de un costo compatible con esa calidad, optimizando costos. Pero además, dado que el producto es un sistema debe tener en consideración las características que presenta todo sistema: propósito, globalidad, entropía y homeostasis, de acuerdo a la Teoría General de Sistemas [von Bertalanffy 68]. La Ingeniería de Software tiene dos vertientes, una mejorar el proceso de producción de software con técnicas de desarrollo, y otra mejorar la gestión del proceso, y es en esta segunda parte donde fundamentalmente cabe la Ingeniería de Requisitos pues tiene más que ver con lo humano que con lo tecnológico. Se debe enfatizar que el proceso de desarrollo de software no es solamente una actividad técnica pues se lleva a cabo en un contexto social donde todos los involucrados participan [Leite 94] [Maté 05]. La Ingeniería de Requisitos es una disciplina que procura sistematizar el proceso de definición de requisitos. Es decir, apunta a mejorar la forma en que se comprenden y definen los servicios que deberán prestar los sistemas de software. La complejidad de los problemas a resolver exige que se preste más atención a su correcto entendimiento antes de comprometer una solución. La IR cubre todas las actividades involucradas en descubrir, modelar, analizar y mantener un conjunto de requisitos para un sistema de software. Capítulo 1 Introducción 8

20 Aunque el problema de cómo establecer sistemas no es nuevo, sólo recientemente la comunidad científica de computación, principalmente la comunidad de ingeniería de software, comenzó a prestar especial atención a la tarea de definición de los servicios que deben prestar los sistemas. El término Ingeniería de Requisitos surgió (formalmente publicado) recién en Enero de 1977 en IEEE Transactions on Software Engineering, donde figuran los siguientes artículos acuñando el término: A Requirements Engineering Methodology for Real-Time Processing Requirements, Alford, M., IEEE-TSE, January An Extendable Approach to Computer-Aided Software Requirements Engineering, Bell, T., Bixler, D., Dyer, M., IEEE-TSE, January La primera conferencia internacional sobre este tema fue en 1993 (RE 93) y en 1995 se realizó la primera reunión del grupo de trabajo IFIP 2.9 (Ingeniería de Requisitos de Software). La Ingeniería de Software ha estado prestando más atención al modelado e implementación (codificación) de productos, proveyendo métodos, herramientas y procedimientos para tal fin, mientras que la Ingeniería de Requisitos comenzó examinando los aspectos del establecimiento de requisitos y su intrínseca dependencia de los aspectos sociales que rodean la construcción del software y que rodearán su operación. La IR tiene una interacción muy fuerte con aquellos que demandan un producto de software. Por lo tanto, el proceso de la IR es un esfuerzo cooperativo que involucra a usuarios, clientes, ingenieros de software, consultores, expertos, denominados en la literatura stakeholders, siendo el término que se emplea en castellano involucrados 4. La IR debe entonces achicar la brecha entre el usuario que tiene necesidades y requiere soluciones a sus problemas, pero que no tiene los conocimientos para especificar los requisitos, y el ingeniero de software que sí tiene dichos conocimientos técnicos pero desconoce el mundo del usuario con sus problemas y necesidades. De lo dicho, surgen dos aspectos ineludibles en un proceso de IR exitoso: i) establecer una buena comunicación entre ambas partes, y ii) comprender cabalmente el mundo del usuario. Lo primero sólo es posible lograrlo cuando el ingeniero de software comprende el vocabulario que maneja el usuario. La postura inversa es casi 4 Se entiende por clientes a los involucrados en el UdeD que de alguna manera se constituyen en dueños del sistema, es decir aquellos que demandan el sistema de software y usuarios a aquellos que efectivamente deban interactuar con el mismo. Naturalmente que un cliente puede ser simultáneamente un usuario y frecuentemente lo es; inclusive éstos no son roles estáticos, por el contrario pueden interactuar con el ingeniero de requisitos cambiando su punto de vista de cliente a usuario y viceversa en forma notoriamente dinámica. Se puede decir que el punto de vista del cliente tiene un sesgo más fuerte hacia los objetivos del sistema a ser desarrollado, y que el del usuario está más dirigido a los detalles concretos de su trabajo diario. Capítulo 1 Introducción 9