UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

Transcripción

1 UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA La Universidad Católica de Loja ESCUELA DE SISTEMAS INFORMÁTICOS Y COMPUTACIÓN TEMA: Análisis comparativo entre las técnicas utilizadas en la Ingeniería de Requisitos, permitiendo evaluar dichas técnicas frente a las características de los proyectos Memoria de Tesis previa a la obtención del Título de Ingeniero en Sistemas Informáticos y Computación. AUTOR: DIRECTOR: COODIRECTOR: Daniel Estiven Valdivieso Narváez Ing. Danilo Jaramillo Ing. Patricio Abad Loja Ecuador

2 CERTIFICACIÓN Ing. Danilo Jaramillo DIRECTOR DE TESIS C E R T I F I C A: Que el presente trabajo de investigación, previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, ha sido dirigido, supervisado y revisado en todas sus partes, por lo mismo, cumple con los requisitos legales exigidos por la, quedando autorizada su presentación. Loja, 12 de noviembre de 2008 Ing. Danilo Jaramillo 2

3 AUTORÍA El presente proyecto de tesis previa a la obtención del Título de Ingeniero en Sistemas Informáticos y Computación; sus conceptos, análisis, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor. Se indicar además que la información de otros autores empleada en este trabajo está debidamente especificada en fuentes de referencia y apartados bibliográficos. Daniel Estiven Valdivieso Narváez 3

4 CESIÓN DE DERECHOS El autor, declara estar de acuerdo con la disposición del Estatuto Orgánico de la en su Art. 67, en el cual se enuncia lo siguiente: Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través o con el apoyo financiero académico o institucional (operativo) de la Universidad. Daniel Estiven Valdivieso Narváez 4

5 AGRADECIMIENTOS El presente trabajo representa el esfuerzo de cinco años de estudio y la culminación de una etapa más en mi vida estudiantil y profesional. En esta etapa existen muchas personas que directa o indirectamente han contribuido a mi desarrollo profesional y personal. En primer lugar, agradezco a mis padres por darme su apoyo constante e incondicional, con el único objetivo de cumplir mi sueño, ser Profesional de Ingeniería en Sistemas Informáticos y Computación. A mis familiares, tíos, primos, que de una u otra forma ayudaron a mi formación personal y entender que en la vida debemos luchar por lo que amamos y deseamos alcanzar. A mi director de tesis, Ing. Danilo Jaramillo, que con su guía, esfuerzo, dedicación, paciencia y conocimiento, contribuyó de manera fundamental la culminación del presente trabajo. A mis amigos, Luis, Manuel, Diego, Galo, con los cuales compartí momentos de alegría y malas noches de estudio, pero con resultados positivos. Gracias por su apoyo. Y de manera muy especial, a Diana, que en toda esta etapa de mi vida supo darme su apoyo y cariño de manera desinteresada. Gracias por ser parte importante de mi vida. EL AUTOR 5

6 DEDICATORIA El presente trabajo se lo dedico principalmente a mis padres, por sus consejos, esfuerzo y apoyo constante. Sin ellos no podría haber llegado hasta esta etapa de mi vida. Ellos son un ejemplo de vida y superación para mi vida. A mis familiares y amigos, que gracias a su apoyo ayudaron a la formación de mi vida personal, profesional y a la culminación del presente trabajo. A Diana, por ser una de las principales personas en apoyarme en toda eta etapa de mi vida profesional, por su comprensión, paciencia y cariño en los momentos difíciles de mi vida. Y la y manera especial a la Escuela de Ciencias de la Computación, por permitirme formarme y ser parte importante del desarrollo productivo de mi país. Daniel Estiven Valdivieso Narváez 6

7 ÍNDICE DE CONTENIDOS CONTENIDO ÍNDICE DE CONTENIDOS... 1 ÍNDICE DE ILUSTRACIONES OBJETIVOS INTRODUCCIÓN INGENIERÍA DE REQUISITOS (IR) HISTORIAEIMPORTANCIA QUÉ ES INGENIERÍA DE REQUISITOS? PROCESO DE LA INGENIERÍA DE REQUISITOS Proceso de la Ingeniería de Software Proceso de la Ingeniería Web CAPITULO II MODELOS DEL PROCESO DE INGENIERÍA DE REQUISITOS MODELOS DE PROCESO MODELO DE POHL MODELO ESPIRAL MODELO SWEEBOK (Software Engineering Body of Knowledge Model) MODELO DE MADUREZ DEL PROCESO REAIMS MODELO DE VOLERE COMPARACIÓN ENTRE LOS MODELOS TÉCNICA UTILIZADAS EN LA INGENIERÍA DE REQUISITOS ENTREVISTA CUESTIONARIOS Y CHECKLIST TORMENTA DE IDEAS (BRAINSTORMING) JAD (JOINT APPLICATION DEVELOPMENT) CASOS DE USO WALKTHROUGHS PROTOTIPADO OPORTUNIDADES 57 7

8 4. HERRAMIENTAS SOFTWARE DE INGENIERÍA DE REQUISITOS UTILIZADAS EN EL MEDIO CARACTERÍSTICAS DEL PROCESO DE ADMINISTRACIÓN DE REQUISITOS VENTAJAS Y DESVENTAJAS DEL USO DE HERRAMIENTAS SOFTWARE EN LA INGENIERÍA DE REQUISITOS CONTRASTACIÓN DE HERRAMIENTAS FRENTE A CARACTERÍSTICAS DE ADMINISTRACIÓN DE REQUISITOS OPORTUNIDADES.62 CAPÍTULO V CONTRASTACIÓN DE HERRAMIENTAS Y ACTIVIDADES FRENTE A TIPOS DE PROYECTOS PROYECTOS Y TIPOS DE PROYECTOS PROCESOS DE INGENIERÍA DE REQUISITOS EN ORGANIZACIONES Proceso de requisitos en la COOPMEGO Proceso de requisitos en el Banco de Loja Proceso de requisitos del SRI Proceso de Requisitos en el TPE-L Proceso de requisitos en empresas de desarrollo de software Resumen del proceso de requisitos ejecutado en organizaciones COMPARACIÓN ENTRE PLANTILLAS DE HERRAMIENTAS EVALUACIÓN DE LAS ACTIVIDADES, TÉCNICAS Y HERRAMIENTAS, FRENTE A TIPOS DE PROYECTOS Nivel de importancia de los requisitos en el desarrollo de proyectos Técnicas utilizadas en la captura de requisitos Técnicas utilizadas en el análisis de requisitos Técnicas utilizadas en la especificación de requisitos Técnicas utilizadas en la validación y verificación de requisitos Modelos de Ingeniería de Requisitos utilizados en el desarrollo de proyectos Herramientas utilizadas en el manejo o gestión de requisitos de los proyectos desarrollados CONTRASTACIÓN ENTRE ACTIVIDADES, TÉCNICAS Y HERRAMIENTAS, Y TIPOS DE PROYECTOS.88 CAPÍTULO VI APLICACIÓN DEL MODELO POHL EN EL GDS DE LA UPSI - SYLLABUS

9 6.1. ANTECEDENTES DEL GDS Quiénes utilizan SYLLABUS? La metodología PROCESO ACTUAL DE INGENIERÍA DE REQUISITOS EN EL GDS APLICACIÓN DEL MODELO DE POHL Y MSF EN EL GDS (SYLLABUS) MODELO DE POHL Y SUS FASES MODELO DE POHL VS. MSF APLICACIÓN CONCLUSIONES RECOMENDACIONES BIBLIOGRAFÍA ANEXOS IRqA (ANALIZADOR INTEGRAL DE REQUISITOS) 125 GENERALIDADES FUNCIONALIDADES PROCESOS DE IRqA IBM RATIONAL REQUISITE PRO 130 LEAP SE 134 VISUAL REQUISITE

10 ÍNDICE DE ILUSTRACIONES Ilustración 1. Proceso de IR de la Ingeniería de Software Ilustración 2. Fases del proceso de IR de la Ingeniería de Software Ilustración 3. Proceso de IR de la Ingeniería Web Ilustración 4. Modelo de Pohl de IR Ilustración 5. Fases de RUP Ilustración 6. Modelo Espiral de IR Ilustración 7. Modelo SWEEBOK de IR Ilustración 8. Niveles de madurez del Modelo REAIMS Ilustración 9. Modelo de Volere Ilustración 10. Contrastación de las actividades del Modelo de Volere frente al Modelo de Pohl Ilustración 11. Diagrama de Casos de Uso Ilustración 12. Proceso de requisitos de la COOPMEGO Ilustración 13. Proceso de requisitos del Banco de Loja Ilustración 14. Proceso de requisitos del SRI-Loja Ilustración 15. Resumen del proceso de requisitos ejecutado en organizaciones Ilustración 16. Creación de requisitos en IRqA Ilustración 17. Selección del tipo de requisitos en IRqA Ilustración 18. Selección del proyecto al cual corresponde el requisito creado Ilustración 19. Lista de requisitos creados para un proyecto Ilustración 20. Plantilla de creación de requisitos de LEAP SE Ilustración 21. Creación de requisitos en Visual Requisite Ilustración 22. Importancia de los requisitos en Proyectos de Bajo Nivel Ilustración 23. Importancia de los requisitos en Proyectos de Nivel Medio Ilustración 24. Importancia de los requisitos en Proyectos de Nivel Alto Ilustración 25. Técnicas utilizadas en la captura de requisitos en Proyectos de Bajo Nivel Ilustración 26. Técnicas utilizadas en la captura de requisitos en Proyectos de Nivel Medio Ilustración 27. Técnicas utilizadas en la captura de requisitos en Proyectos de Nivel Alto Ilustración 28. Técnicas utilizadas en el análisis de requisitos en Proyectos de Bajo Nivel Ilustración 29. Técnicas utilizadas en el análisis de requisitos en Proyectos de Nivel Medio Ilustración 30. Técnicas utilizadas en el análisis de requisitos en Proyectos de Nivel Alto Ilustración 31. Técnicas utilizadas en la especificación de requisitos en Proyectos de Bajo Nivel Ilustración 32. Técnicas utilizadas en la especificación de requisitos en Proyectos de Nivel Medio Ilustración 33. Técnicas utilizadas en la especificación de requisitos en Proyectos de Nivel Alto Ilustración 34. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Bajo Nivel Ilustración 35. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Nivel Medio.. 86 Ilustración 36. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Nivel Alto Ilustración 37. Modelos de Ingeniería de Requisitos utilizados en Proyectos de Nivel Medio Ilustración 38. Modelos de Ingeniería de Requisitos utilizados en Proyectos de Nivel Alto Ilustración 39. Herramientas utilizadas para gestión de requisitos en el desarrollo de proyectos Ilustración 40. Roles de MSF Ilustración 41. Proceso General de Obtención de Requisitos del Proyecto Syllabus Ilustración 42. Diagrama de Gestión de requisitos de cambio de Syllabus

11 Ilustración 43. Proceso de Requisitos de cambio desde una visión general Ilustración 44. Modelo de Pohl de IR Ilustración 45. Diagrama de Gestión de requisitos de cambio de Syllabus - Propuesto Ilustración 46. Proceso General de Requisitos recomendado para el GDS (SYLLABUS) Ilustración 47. Logotipo de IRqA Ilustración 48. Empresas que han aplicado IRqA Ilustración 49. Administración y gestión de requisitos Ilustración 50. Atributos de Requisitos Ilustración 51. Código de modelos de objetos Ilustración 52. Casos de Uso en Visual Requisite

12 Objetivo General OBJETIVOS Realizar un análisis comparativo entre las técnicas utilizadas en la Ingeniería de Requisitos, permitiendo evaluar dichas técnicas frente a las características de los proyectos Objetivos Específicos Estudiar y analizar los distintos modelos, técnicas y herramientas utilizadas en la Ingeniería de Requisitos. Realizar un análisis y evaluación de las diferentes técnicas, modelos y herramientas de la Ingeniería de Requisitos utilizadas en el desarrollo de proyectos Recomendar un proceso de Ingeniería de Requisitos para el GDS (SYLLABUS), basado en la fundamentación realizada. Resultados Esperados Al finalizar este proyecto se pretende dejar en claro cuáles son las herramientas que se deben utilizar para la recolección de información frente a los diferentes tipos de proyectos que se pueden desarrollar. Estrategias La metodología que se utilizará es una Investigación documental que se realiza, apoyándose en documentos que se basa en la consulta de libros, artículos o ensayos de revistas y periódicos. 12

13 Además se apoyará en una Investigación de campo: la misma que presenta informaciones que provienen entre otras, de entrevistas, cuestionarios, encuestas y observaciones. Ya que se necesitará realizar una análisis comparativo de las herramientas utilizadas en la Ingeniería de Requisitos. Actividades Entrevistas con los administradores de los sistemas que poseen algunas entidades financieras de la localidad y empresas constructoras de software de los diferentes sitios del país. Entrevista con miembros del GDS para la aplicación del Modelo de Pohl de Ingeniería de Requisitos basado en MSF, en el sistema SYLLABUS. 13

14 INTRODUCCIÓN Al momento de la culminación de un proyecto siempre se realiza la evaluación de los recursos utilizados en el desarrollo del mismo, de esta forma se observa que dichos recursos han sido utilizados de forma excesiva o no, la estimación de tiempos de terminación de las tareas y los recursos a utilizar no son exactamente los adecuados para un proyecto, esto debido a una defectuosa lista de requisitos del sistema que obligan al incremento de tareas. Dichas tareas no solo se refieren a las actividades del desarrollo de los proyectos, sean estas basadas en un metodologías de desarrollo o no, sino también a aquellas actividades de los subprocesos que se manejan durante el ciclo de vida de cada uno de los proyectos que se desarrollan, como: Ingeniería de Requisitos, fases de desarrollo, control y aseguramiento de calidad, y otros subprocesos del desarrollo de proyectos software. En lo referente a la Ingeniería de Requisitos, se conoce que los requisitos son parte fundamental del desarrollo de un proyecto, pero, para llegar a obtener un proyecto o producto software de calidad, es necesario que se utilicen ciertas técnicas, modelo de proceso o herramientas, que permitan a los constructores de software administrar o gestionar de manera adecuada cada uno de los requisitos durante el ciclo de vida de dichos proyectos. Del mismo modo que se utiliza o aplica metodologías de desarrollo de software en los proyectos, se puede realizar lo mismo con los subprocesos de desarrollo, en este caso la Ingeniería de Requisitos a través de los diferentes modelos de procesos de requisitos existentes. De esta manera con el presente proyecto se pretende hacer un estudio comparativo de las diferentes técnicas que existen en la obtención de los requisitos, involucradas en la Ingeniería de Requisitos, además de realizar una contrastación del uso de estas técnicas frente a las características de desarrollo de los proyectos, para poder dar una orientación del uso estas técnicas al momento de iniciar un proyecto. 14

15 CAPÍTULO I 1. INGENIERÍA DE REQUISITOS (IR) Los grandes sistemas software constituyen actualmente un elemento común en nuestra sociedad, convirtiéndose día a día en imprescindibles para la industria, el comercio y las personas. Siempre que vamos a desarrollar una determinada aplicación o un sistema para nuestros clientes, ponemos en marcha principios, métodos, técnicas y herramientas que permiten mantener y documentar las necesidades o requisitos generales para el desarrollo de estas aplicaciones, a estos importantes aspectos se le llama Ingeniería de Requisitos. Por tanto, es importante describir y detallar en qué consiste esta área de la Ingeniería de Software para la consolidación de cualquiera de los proyectos que se realicen HISTORIA E IMPORTANCIA Antiguamente los requisitos o necesidades no eran tomados en cuenta por los profesionales y las empresas constructoras de software de forma adecuada y, no llegaban a cumplir los objetivos de los proyectos. Estas empresas tenían de cierta manera, fuertes bases estructuradas de lo que podían hacer y los cliente en lugar de contratar a un profesional que desarrolle una solución que se ajuste a sus necesidades, buscaba en el mercado la herramienta necesaria que se ajustaría a sus requisitos y sobre todo que le de la confianza para implementarla y que no termine sufriendo pérdidas de tiempo, económicas y buscando otro solución a sus problemas o necesidades, pues el desarrollo personalizado era extremadamente costoso. 15

16 Se reconoce a la Ingeniería de Requisitos dentro de la Ingeniería de Software como la parte borrosa del proceso de desarrollo de sistemas, la misma que comprende la formalización de ideas que en primera instancia son netamente informales. Desde mediados de los años 70 la Ingeniería de Requisitos adquirió una vital relevancia pues los costos de desarrollo disminuyeron en gran cantidad y las empresas finalmente entendieron la necesidad de desarrollar sistemas a medida de las necesidades o requisitos. Solo entre un 9% y un 12 % de la duración de un proyecto se utiliza en la Ingeniería de Requisitos, esto resulta a lo menos extraño pues es en esta fase donde ocurre la mayor cantidad de errores, los más costosos de reparar y que más tiempo consumen. Se afirma que el 10% de los errores ocurren en esta fase, recientes estudios confirman que entre un 44% y un 80% ocurren durante la especificación de requisitos, estas cifras son realmente alarmantes en el sentido del poco tiempo que se le dedica a esta fase durante la creación y desarrollo de los proyectos 1. Por experiencia, algunos desarrolladores, analistas de sistemas e ingenieros de software aseguran que reparar un error en la fase de codificación cuesta entre 5 y 10 veces más que si se hiciera durante la fase de requisitos, esta cantidad aumenta mucho más si el error ocurre durante la fase de codificación o mantenimiento del proyecto, hasta llegar entre 200 y 400 veces más caro, y así en el resto de fases del proyecto. Un dato muy alarmante es que cerca del 53% de los proyectos fracasan por no realizar un análisis de requisitos. Y no solamente hay fracasos de proyectos por el no análisis de los requisitos, sino también porque no existe una importante participación de los usuarios o clientes y, por la obtención incompleta de los requisitos. Estos datos nos dan a entender que, si mejoraríamos esta fase de toma de requisitos, nos proporcionaría grandes 1 BOHEM, Barry. (2007). Blog Competencias del ICI en la toma de requisitos. Disponible en: 16

17 beneficios y sobre todo facilidad para representar y desarrollar una solución eficiente y eficaz de acuerdo a las necesidades planteadas por los clientes QUÉ ES INGENIERÍA DE REQUISITOS? Existen varios conceptos o significados acerca de la Ingeniería de Requisitos que nos proporcionan varios autores según su nivel de experiencia, sentido común o simplemente por su forma de ver los requisitos respecto al desarrollo de un determinado proyecto. En la Ingeniería de Requisitos principalmente se identifican dos aspectos muy importantes: el primero que es el propósito del sistema que se va a desarrollar y el segundo, el contexto en el que será usado. En base a estas características, se definen algunos conceptos como: (i). La Ingeniería de Requisitos o los requisitos en sí, constituyen el enlace entre las necesidades reales de los clientes, usuarios y otros participantes vinculados al sistema. La Ingeniería de Requisitos consiste en un conjunto de actividades y transformaciones que pretenden comprender las necesidades de un sistema software y convertir la declaración de estas necesidades en una descripción completa, precisa y documentada de los requisitos del sistema siguiendo un determinado estándar. 2 (ii). La Ingeniería de Requisitos trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para los sistemas basados en computadora, de forma sistemática y repetible.. 3 (iii). Es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro 2 MÁRQUEZ, José Manuel. (2005). Ingeniería del Software. Departamento de Informática. Universidad de Valladolid. Disponible en: 3 GÁLVEZ, Jorge Alberto. (2006). Ingeniería de Requerimientos. Universidad Tecnológica de Pereira. Ensayo sobre Ingeniería de Requerimientos. 17

18 documento formal. Una representación documentada de una condición o capacidad de un sistema. 4 La Ingeniería de Requisitos en si cumple un papel primordial en el proceso de construcción y producción de un software, es decir que, estará basado en función de las necesidades planteadas por los clientes en un nivel muy general, donde se descubre, documenta, analiza y se define los servicios o componentes de lo que se desea producir, además de las restricciones que tendrá el producto o software. Su principal tarea consiste en proporcionar requisitos fiables para la construcción de un software, además de facilitar la comprensión por parte de los desarrolladores, de lo que el cliente requiere. La obtención correcta de los requisitos puede llegar a describir con claridad, sin ambigüedades, en forma consistente y compacta, el comportamiento de un sistema. La Ingeniería de Requisitos, lo único que pretende en la construcción de sistemas software es minimizar los problemas relacionados al desarrollo de sistemas, claro está en proporción a la realidad de cada proyecto, no solo de grandes sistemas software empresariales, de ciencia, nanotecnología, etc., sino también en los pequeños, como simples aplicaciones de escritorio, tareas estudiantiles, etc. Con esto se logra reducción de tiempo en la construcción del software o proyecto, reducción de errores y, lo más importante no solo para el cliente sino también para el ingeniero de requisitos y el equipo de desarrollado, se evita gastar dinero más de lo planeado y determinado para el proyecto. A continuación se detalla algunas de las características más importantes de Ingeniería de Requisitos: Permitir gestionar o administrar las necesidades reales del proyecto en forma estructurada, esto quiere decir que, cada actividad de la Ingeniería de Requisitos que 4 IEEE. (2007). Introducción a la Ingeniería de Requisitos. Ingeniería de Software (3 I.T.I.S., I.T.I.G.). Documento digital. 18

19 se desarrolla, consiste de una serie de pasos bien definidos y lo más importante bien organizados. Mejorar la capacidad de predecir cronogramas de los proyectos, así como también sus resultados. La Ingeniería de Requisitos proporciona al desarrollador o su equipo de desarrollo un punto de partida para controles y actividades de mantenimiento del software, como estimación y planeación de costos, tiempo y recursos que se van a utilizar en la obtención del producto. Disminuir costos y retrasos de un proyecto. Al realizar un proceso de Ingeniería de Requisitos adecuado, los tiempos de desarrollo disminuyen, al igual que el costo por corrección de los errores encontrados en cada una de las fases de construcción, que se han originado del conjunto de requisitos. Mejorar la calidad del software, está dada en función del cumplimiento de un conjunto de requisitos como: funcionalidad, facilidad de uso, confiabilidad, desempeño, seguridad, etc. Mejorar la comunicación entre equipos, permitiendo que la obtención y definición de requisitos representa una forma de consenso entre los clientes y desarrolladores. Si este consenso no tiene aceptación, el proyecto estará destinado al fracaso. Quizá la característica más importante, es de que evita rechazos de los usuarios finales. La Ingeniería de Requisitos tiende a obligar a los clientes a considerar sus requisitos o necesidades cuidadosamente y a revisarlos dentro del contexto del problema, por este motivo se lo involucra durante todo el desarrollo del proyecto PROCESO DE LA INGENIERÍA DE REQUISITOS Es muy importante definir cuál es el proceso de Ingeniería de Requisitos ya que esto nos va a servir para la obtención correcta de los requisitos. Se han definido diversos procesos a nivel de toda la Ingeniería de Software, así tenemos procesos para el desarrollo de aplicaciones web o para de escritorio. Se ha definido un estándar, pero en general, la mayor parte de estos procesos tienen un parecido y lo único que buscan es recopilar la mayor cantidad de requisitos correctos para así conformar una buena estructura que servirá de base para el desarrollo de un proyecto. 19

20 Proceso de la Ingeniería de Software Necesidades del usuario Estudio de Viabilidad Captura y Análisis Informe de Viabilidad Modelos del Sistema Especificación Requisitos de Usuario y Sistema Validación Documento de requisitos Ilustración 1. Proceso de IR de la Ingeniería de Software. Ilustración 2. Fases del proceso de IR de la Ingeniería de Software. En la ilustración 1 y 2, se muestra un esquema del proceso de la Ingeniería de Requisitos basado en la Ingeniería de Software. El proceso de cumple en cinco fases, viabilidad, captura y análisis, especificación, validación y gestión de requisitos Estudio de viabilidad Esta fase es de gran importancia para el cumplimiento de los objetivos de una organización o un determinado cliente que desea poner en marcha el desarrollo de un proyecto. Este estudio permitirá obtener un informe tanto para el equipo de desarrollo del proyecto como para el cliente, donde se verificará si el proyecto vale la pena desarrollarlo, si es factible utilizar la tecnología actual ya sea en costo o tiempo, si permitirá comunicarse con otros sistemas, etc. Si no se realiza un análisis correcto y no se informa 20

21 de la verdadera viabilidad de desarrollo que tiene un proyecto, en esta etapa, es posible que el proyecto fracase desde sus inicios Captura y Análisis En esta fase el ingeniero de requisitos o algún miembro del equipo de desarrollo entran en contacto con el usuario final o con el cliente para determinar el alcance del proyecto que se desea construir, además, se debe identificar cuáles son los servicios que prestará el sistema, su rendimiento, sus necesidades y restricciones, y cuáles son los objetivos esperados. Todos estos aspectos son los requisitos que son identificados, analizados y clasificados (funcionales, no funcionales ) por el ingeniero de requisitos al momento que interactúa con el usuario para determinar la mejor solución a su problema. En la captura y análisis de requisitos entran los llamados stakeholders, que son aquellas personas a los que afecta directa o indirectamente el sistema, determinando la aparición de nuevos requisitos. Por ejemplo en la implementación de un cajero automático de un banco, se reconoce los siguientes stakeholders: clientes del banco, directores de una sucursal, supervisores de la superintendencia de bancos, etc. La captura y análisis se resume en cinco pasos fundamentales: i. Identificar las fuentes de información y planificar las actividades de investigación ii. Realizar las preguntas apropiadas (comprender las necesidades del cliente) iii. Analizar la información (detectar puntos no claros) iv. Confirmar con los usuarios (lo que parece haberse comprendido) v. Sintetizar los requisitos (especificación de requisitos) En esta fase o etapa, entra un aspecto muy importante, tal es el caso, de las técnicas o herramientas que se utilizan para la obtención y el respectivo análisis de los requisitos, así están en este grupo: entrevistas, observación, cuestionarios, prototipado, Requisite Pro, IRqA, etc. 21

22 Especificación El objetivo principal de la especificación de requisitos es obtener un documento de especificación de requisitos, en el cual se llega a definir de una forma completa, precisa y verificable cada uno de los requisitos que debe satisfacer el sistema a desarrollar, además de sus respectivas restricciones (software, hardware). En la especificación de requisitos se debe redactar y describir solamente aquella información veraz que ha sido tomado por el ingeniero de requisitos o su equipo en el momento de la entrevista con el usuario final, cliente o los stakeholders que hayan entrado en el proceso, y ser comunicada de forma eficaz para reconocer cada componente del sistema. No es necesario detallar ningún tipo de diseño del software, ya que esto influiría directamente en los requisitos. Consideraciones en la especificación de requisitos. Lo que caracteriza a una buena especificación de requisitos es que no existan ambigüedades en la información transmitida, esto puede originar varias interpretaciones por parte del desarrollador. Debe ser completa, es decir, se debe señalar los requisitos funcionales y no funcionales, así como también aquellas restricciones que tendrán el sistema o proyecto, además de los estándares en los que se basan o los determinados por el equipo desarrollador. Su verificación debe ser fácil y cumplir con las expectativas del cliente y quien lo construye, no se debe incluir aquellos requisitos que no sean verificables, posteriormente se los debe incluir luego de haber hecho un respectivo análisis y comprobado que es verificables. También tiene mucho que ver la facilidad de uso con el fin de facilitar a aquellas personas que realicen el mantenimiento y explotación de los requisitos, además de su fácil modificación tanto en su estructura como en su estilo o tipo, no se debe permitir redundancia, cada uno de los requisitos se debe utilizar en un solo lugar. 22

23 La trazabilidad también tiene mucha importancia, esto determina el ciclo de vida de los requisitos, además de que cada uno de estos posee su propia identificación, diferenciándolos de los demás Validación Consiste en mostrar o comprobar que cada uno de los requisitos obtenidos define la funcionalidad del proyecto que se va a construir y lo que desea el cliente. En esta etapa solamente entran aquellos requisitos que se mencionaron en la especificación. Comprende dos partes: verificación y validación. En la verificación se comprueba que los requisitos han sido construidos de acuerdo a estándares y criterios establecidos por el equipo de desarrollo, aquí interactúan los clientes, usuarios finales, analistas y otras personas que influyen en el proceso. La validación comprueba que los requisitos se ajustan a las necesidades del usuario final o clientes, en base a técnicas de revisión ya sean formales o informales Gestión En esta etapa se realiza la comprensión y control de los cambios de cada uno de los requisitos, sean estos requisitos estables o volátiles. Se realizan varias tareas importantes: una de ellas es la planificación de la gestión de requisitos, que tiene que ver con la identificación de requisitos, proceso de gestión de cambios, políticas de trazabilidad y herramientas de soporte. Otra tarea es la de gestión de cambios en los requisitos, que comprende el análisis del problema y especificación del cambio, análisis y estimación del cambio, implementación del cambio. 23

24 Proceso de la Ingeniería Web. Clientes Usuarios Analistas Desarrolladores Diseñadores Información Captura de requisitos Definición de requisitos Validación de requisitos Catálogo de requisitos Correcciones Ilustración 3. Proceso de IR de la Ingeniería Web. La ilustración 3 muestra el esquema del proceso de Ingeniería de Requisitos que se usa en el desarrollo de proyectos web, tiene mucha relación con el proceso anterior en tres fases muy importantes, captura y definición de requisitos a cargo de los ingenieros de requisitos, analistas, desarrolladores, diseñadores del sistema; y la validación de requisitos, donde actúan los usuarios finales o clientes. A esto se suman algunos componentes que no dejan de ser importantes a la hora de hablar de obtención de requisitos para el desarrollo e implementación de un proyecto. El proceso de definiciónvalidación es iterativo, con el fin de realizar correcciones a errores existentes, en aplicaciones o proyectos grandes este proceso será necesario ejecutarlo varias veces. 24

25 Captura de requisitos El proceso de captura de requisito para los ingenieros de requisitos puede resultar complejo si no se conoce el entorno de trabajo, es muy importante poner atención a la información proveniente de los clientes, documentos o aplicaciones existentes, ya que estos son los que definen cuáles son los componentes y servicios que va a prestar el sistema web. Se utilizan varias técnicas, entre las más utilizadas están: entrevista, desarrollo conjunto de aplicaciones (JAD), casos de uso, mapa de conceptos, etc Definición de requisitos Se construye a partir de la captura de requisitos, dentro de esta etapa se definen aquellos requisitos funcionales y no funcionales, incluso las restricciones que tendrán el sistema o proyecto, se identificarán y cumplirán con cada una de las necesidades del usuario final o cliente. Se obtiene un catálogo de requisitos que corresponden a un conjunto de resultados de requisitos que serán validados. Podemos anotar además otras técnicas que son utilizadas con frecuencia en la captura de requisitos: Reviews o Walk-throughs. Auditorías. Matrices de trazabilidad. Prototipos Validación de requisitos Los requisitos una vez definidos necesitan ser validados para comprobar que cada uno de ellos cumple con las necesidades que el cliente requiere. Es necesario asegurar que el análisis realizado y los resultados que se han obtenido en la fase de definición de requisitos son correctos. En la actualidad existen propuestas para la validación y la 25

26 mayoría de estas consisten o comprender la revisión de todos los requisitos obtenidos en la primera fase de este proceso junto con el usuario final o cliente, para detectar errores o inconsistencias. 26

27 CAPITULO II 2. MODELOS DEL PROCESO DE INGENIERÍA DE REQUISITOS 2.1. MODELOS DE PROCESO El modelo de procesos de la Ingeniería de Requisitos se ha convertido en un estándar para los ingenieros de requisitos y los desarrolladores de proyectos, se tomarán aquellos aspectos que se han estandarizado y que son tres: Captura, Análisis y Validación. Estas fases, si se las puede llamar así, realizan un proceso iterativo con el fin de redefinir ciertos requisitos, obtener nuevos o simplemente corregir errores, a estos procesos iterativos se los llama ciclos, que se forman por la interacción entre estas fases, además de la inclusión de un ciclo de desarrollo e ingeniería de requisitos. El éxito de una buena toma de requisitos depende del modelo de procesos que se utilice, además, de la capacidad y experiencia de quién interactúa con el cliente o con los stakeholders necesarios con el único fin de aplicar o acoplar sus necesidades al sistema o proyecto que se va a desarrollar. Captura-Análisis-Validación: Este primer proceso iterativo representa un ciclo interno que indica que durante el proceso de validación de los requisitos que realizan los clientes o usuarios pueden aparecer nuevos requisitos que hasta ese momento no se los había tomado en cuenta o no se los identificó. Es necesario ponerse de acuerdo con los clientes o usuarios y determinar si es indispensable incluir estos requisitos. Captura-Análisis: En este ciclo se determina la posibilidad de que se encuentre conflictos o deficiencias en los requisitos durante la fase de análisis, provocando que se llegue a una nueva etapa de captura/negociación de los requisitos con el cliente, y finalmente se realice un análisis exhaustivo de los mismos, a fin de eliminar dichos conflictos o deficiencias. 27

28 Ingeniería de Requisitos-Desarrollo: Es sumamente importante porque durante la fase de desarrollo existe la posibilidad de encontrar nuevos requisitos que no se los puede implementar por su complejidad o ambigüedad, dando la posibilidad de volver a realizar las actividades necesarias para reconsiderar ciertos requisitos o incluir nuevos. Además del modelo estándar de procesos que se utiliza existen otros modelos muy interesantes que son utilizados en la Ingeniería de requisitos por parte de los ingenieros de requisitos, estos, dependiendo de la experiencia de quién los utilice, ayudan a disminuir el número de errores o el posible fracaso de un sistema o proyecto en el que se ha realizado mal la Ingeniería de Requisitos MODELO DE POHL Ingeniero de requisitos Expertos en el dominio Captura Negociación Clientes Usuarios Validación y Verificación Especificación y Documentación Programadores Grupo de calidad Director del proyecto Ilustración 4. Modelo de Pohl de IR. Este es un modelo iterativo en el que entran en juego cuatro actividades: Captura, Negociación, Especificación-Documentación y Validación-Verificación. El orden en que se 28

29 ejecutan y realizan estas actividades puede ser cualquiera, pero siempre es aconsejable seguir una secuencia. 5 Todos los que conforman el grupo de desarrollo, ingeniero de requisitos, grupo de calidad, director del proyecto, programadores, expertos en el dominio, además del cliente y los usuarios que intervengan son parte del modelo y de sus actividades. La Captura cumple el papel de recolección de los requisitos o necesidades del cliente y determinar el alcance del sistema o proyecto. En la Negociación, todos los participantes del proyecto tienen la tarea de discutir y dar sus opiniones respecto a los requisitos que se han obtenido, con el fin de determinar las funciones y las restricciones que tendrá el sistema o proyecto, si estos no cumplen las expectativas del cliente y lo que se quiere alcanzar, se deberá volver a hacer una nueva captura de requisitos. Aquellos requisitos que han sido negociados, deben ser especificados e incorporados en un documento de especificación de requisitos, aquí se deben definir solamente aquellos requisitos completos y que son verificables. Esto determinará el cumplimiento de los objetivos del sistema y la satisfacción de las necesidades del cliente. Es importante destacar que en este documento se deberá incluir información real, sin ambigüedades que se ha obtenido en el momento de hablar con el cliente o los stakeholders. Los requisitos deben ser validados-verificados. Se debe confirmar los requisitos asegurándose que realmente cumplen con los objetivos y las necesidades del cliente. Si se detectan errores, el cliente junto con el encargado de realizar esta actividad deberán 5 Información recopilada de: - GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: - BERNÁRDEZ, Beatriz. (2001). Modelo aplicado a la calidad de la ingeniería de requisitos. Universidad de Sevilla. Documento digital. 29

30 redefinir los requisitos erróneos, buscando una posible solución, en caso de no encontrarla se volverá a negociar estos requisitos. Al tratarse de un modelo de requisitos en el cual intervienen o participan varias personas relacionadas en la fase de requisitos de un proyecto, se puede aplicar o relacionar con algunas metodologías del desarrollo de software como: MSF (Microsoft Solution Framework) y RUP (Rational Unified Process) Modelo de Pohl aplicado a MSF El modelo MSF se basa en la organización de equipos para el desarrollo y consecución de los proyectos. En cada uno de estos, toma mucha importancia los roles y responsabilidades que cada integrante del grupo tiene, su finalidad es la de tener éxito en los proyectos y productividad en el equipo de trabajo creado. De esta manera, los roles y responsabilidades pueden tomarse en cuenta en el desarrollo de la fase de requisitos de un proyecto, con la misma finalidad, desarrollar una fase de requisitos exitosa mediante el apoyo del equipo de desarrollo, y guiados por el ingeniero de requisitos. Los roles que MSF tiene son: Gerente de proyecto Gerente de producto Arquitecto Desarrollador Aseguramiento de la Calidad Gerente de lanzamiento Encargado de la experiencia del usuario A continuación, se muestra una tabla en la cual los roles o participantes de la metodología MSF pueden ser parte de las actividades del Modelo de Pohl. Cabe destacar en cada una de las actividades debe participar el ingeniero de requisitos. 30

31 ACTIVIDADES Captura Negociación Especificación-Documentación Validación-Verificación Tabla 1. Roles de MSF frente a actividades del Modelo de Pohl. ROLES MSF Gerente de producto Gerente de producto Gerente de proyecto Analista-Desarrollador Aseguramiento de calidad Gerente de producto El Release Management se encarga de validar la infraestructura de la solución que se vaya a construir, no entran a participar del modelo. Este, junto con el ingeniero de requisitos se encargaría de evaluar si lo que el cliente desea es posible construirlo, en base a los requisitos y la existencia de la infraestructura necesaria para el desarrollo de la solución Modelo de Pohl aplicado a RUP La metodología de desarrollo de software de RUP también se base en el trabajo de equipo, en la distribución de roles y responsabilidades, pero enfatiza en el tipo de personalidad de los miembros para delegar dichas funciones de trabajo. Un aspecto importante en esta metodología de desarrollo de software es la aplicación de buenas prácticas, dadas y establecidas por RUP, estas son: Desarrollo iterativo, Gestión de los requisitos, aplicación de arquitecturas basadas en componentes, modelado visual del software (UML), verificación de la calidad del producto y control de cambios del software. Las fases de las cuales se constituye esta metodología de desarrollo de software son: Incepción (Requisitos) Elaboración (Análisis y diseño) Construcción (Implementación) Transición (Pruebas) 31

32 Ilustración 5. Fases de RUP. Fuente: Los role de RUP están distribuidos de la siguiente manera: Analista Arquitecto de software Desarrolladores Gestores (desarrollo y proyecto) Tester Apoyo (documentación) Especialistas en pruebas Gestor de control del cambio Esta metodología puede ser la que mejor se ajuste al modelo de requisitos de Pohl, tanto para MSF, RUP y Pohl, el proceso es iterativo. De tal manera que en cada iteración se puede obtener o refinar algunos requisitos, además de ir desarrollando una solución eficaz, eficiente y de alta calidad. Cada iteración constituye un demo de la solución, así mismo puede establecerse borradores de requisitos, irlos mejorando, hasta poder 32

33 alcanzar la satisfacción o el objetivo planteado por el cliente y/o con el ingeniero de requisitos, y este a su vez, con el equipo de desarrollo. En la tabla 2, se especifica cuáles de los participantes de la metodología RUP pueden intervenir en la actividades del Modelo de Pohl. Captura Negociación Tabla 2. Roles de RUP frente a actividades del Modelo de Pohl. ACTIVIDADES Especificación y documentación Validación y verificación ROLES RUP Analista Arquitecto del software Analista Desarrolladores Gestor de proyecto Apoyo Gestor de control del cambio Tester Analista 33

34 MODELO ESPIRAL Borrador de requisitos Captura de requisitos Análisis y Validación de requisitos Documento de requisitos Negociación de requisitos Conflictos de los requisitos Ilustración 6. Modelo Espiral de IR. Este modelo plantea tres ejes: Borrador de Requisitos, Conflictos de Requisitos, Documento de Requisitos; que se cumplen o complementan en base a tres actividades: Captura, Análisis-Validación y Negociación de requisitos. El modelo es iterativo, no es posible determinar un punto de finalización del proceso de Ingeniería de Requisitos por cuanto nunca se podrá obtener requisitos perfectos. El modelo asume que existe la actividad de gestión de requisitos, que se realiza durante todo el proceso y que se encarga de gestionar la obtención incremental de los requisitos y los inevitables cambios a los que está sujetos 6. 6 GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: 34

35 Al tratarse de una gestión de requisitos, el cliente y el grupo de desarrollo deben estar preparados para los cambios en los requisitos y en el sistema o proyecto, estos cambios pueden originarse a raíz del análisis y validación de los requisitos, luego de realizar el borrador de requisitos, que no es más que un documento en el que se encuentra todos los requisitos capturados en una grado menor de detalle. Al analizar y validar los requisitos se pueden encontrar errores o conflictos que necesitan ser corregidos y reinsertados en el proceso. Aquellos requisitos que son analizados son los que darán la forma y el alcance del sistema o proyecto. A través de la negociación se logra determinar las funciones que el grupo de desarrollo tendrá que tomar en cuenta para desarrollar e implementar una solución. En la negociación, tanto el ingeniero de requisitos, el grupo de desarrollo como el cliente exponen sus criterios respecto a los requisitos capturados, al mismo tiempo que establecen los requisitos válidos también pueden encontrar inconsistencias en los mismos y determinar si es necesario realizar un nuevo análisis de los requisitos o volver a recolectar información. Los requisitos deben ser plasmados en un documento de requisitos, estos deberán ser los que realmente servirán para la construcción de la solución, además, deben cumplir con las expectativas y objetivos planteados por el cliente y quien desarrolla la solución. 35

36 MODELO SWEEBOK (Software Engineering Body of Knowledge Model) Captura de requisitos Análisis y Negociación de requisitos Documentación de requisitos Validación de requisitos Necesidades del cliente o usuarios Requisitos acordados Documento de requisitos Ilustración 7. Modelo SWEEBOK de IR. Nació como un proyecto desarrollado por la IEEE para producir un cuerpo de conocimiento sobre Ingeniería de Software que siente las bases sobre dicha ingeniería como una profesión 7. Dentro de este proyecto existen diez áreas de conocimiento, diseño del software, construcción del software, testeo del software, mantenimiento, entre otras. Una de ellas son los Requisitos del Software, es aquí donde nace el modelo SWEEBOK como una visión consistente y consensuada de la Ingeniería del Software. El modelo consiste en cuatro actividades: Captura, Análisis y Negociación, Documentación y, Validación de los requisitos. En la captura de requisitos se realiza la recolección de la información por parte del grupo de desarrollo o de la persona encargada de hacer esta actividad. La información es relevante e importante ya que determina los requisitos y las necesidades del cliente para con el sistema o proyecto, además del dominio del problema. Es necesario que en esta actividad intervenga el cliente y los stakeholders necesarios, ya que en ocasiones los clientes no son los que manejan la solución que se construya, sino los stakeholders. 7 GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: 36

37 En el análisis-negociación se estudia, analiza y clasifica las necesidades del cliente con el fin de encontrar conflictos y darles solución. Así mismo, se determina el alcance o límite de la solución y como deberá interactuar con el entorno. Cuando se encuentra problemas o inconsistencias en los requisitos, deben ser sometidos a un análisis entre el ingeniero de requisitos, el grupo de desarrollo y el cliente, aquí se deberá dar criterios y alcanzar un acuerdo para realizar cambios o no en los requisitos. Se puede llegar a desarrollar un modelo conceptual (diagrama entidad/relación, de entidades o clases) para un mejor análisis y negociación de requisitos. Seguidamente se debe generar un documento de requisitos el cual servirá como base para futuras revisiones. Los requisitos que aquí se detallen deben ser reales y válidos. Cuando existen sistemas o proyectos grandes y que tienen componentes que no están incluidos como software, se debe desarrollar tres tipos de documentos 8 : 1. Documento de definición del sistema. Este, es un documento de requisitos de los usuarios que define en un alto nivel las necesidades o requisitos desde la perspectiva del negocio. 2. Especificación de los requisitos del sistema. Este documento se lo desarrolla cuando existen ciertos componentes claves en el desarrollo de la solución, componentes no software (ejemplo: hardware necesario para el funcionamiento del sistema). 3. Especificación de los requisitos del software. Describe las funciones y restricciones de la solución, así como también lo que no debe hacer. Este documento puede ser complementado con los modelos o descripciones desarrollados en la actividad anterior. 8 Documentos recomendados en: Departamento de Lenguajes y Sistemas Informáticos. Introducción a la Ingeniería de Software. Universidad de Sevilla. Disponible en: 37

38 Los requisitos deben ser validados. Se confirma que los requisitos cumplen con los objetivos planteados y describen verdaderamente la solución que el cliente desea. Se debe revisar los documentos desarrollados para encontrar o detectar errores o conflictos no detectados anteriormente. Es necesario que los documentos cumplan con criterios y estándares de calidad establecidos por el ingeniero de requisitos y el grupo de desarrollo MODELO DE MADUREZ DEL PROCESO REAIMS Nivel 2: Repetible - Estándares definidos para los documentos de requisitos y para las actividades del proceso. - Pocos problemas con los requisitos, especialmente para sistemas conocidos. Nivel 1: Definido - Proceso de ingeniería de requisitos definido explícitamente y basado en las mejores prácticas. - Programa de mejora de procesos en marcha. Nivel 1: Inicial - Ingeniería de requisitos. - Son comunes los problemas con los requisitos. Ilustración 8. Niveles de madurez del Modelo REAIMS. REAIMS (Requirements Engineering Adaptation and Improvement for safety and dependability). Su traducción al español es Ingeniería de Requisitos adaptado y mejorado para la seguridad y dependencia. Es el resultado de un proyecto europeo que lleva su nombre y que va orientado a los procesos de Ingeniería de Requisitos que deben manejar las organizaciones. Para este modelo se definen tres niveles de madurez: 38

39 Nivel 1: Inicial Este nivel va orientado a aquellas organizaciones que desarrollan proyectos y que no tienen definido un proceso de Ingeniería de Requisitos. Por lo general, se encuentran con problemas e inconsistencias en la construcción de soluciones o proyectos, y no se dan cuenta que es por la falta de un proceso que les permita por lo menos minimizar los errores y disminuir el riesgo de fracaso de sus proyecto. Además, no produce un documento de requisitos en los plazos que se han solicitado, sólo dependen de las habilidades y experiencia de los ingenieros de requisitos para cumplir con las responsabilidades de recolección de información. Nivel 2: Repetible A este nivel pertenecen todas aquellas organizaciones que han definido ciertas normas, estándares para sus documentos de requisitos, así como también para su descripción. El manejo de políticas y procedimientos que les permita gestionar los requisitos es muy importante en este nivel, por cuanto les permite a las organizaciones utilizar herramientas para automatizar el manejo de los requisitos, mejorando el proceso de construcción de un proyecto. Los documentos de requisitos son más consistentes, cumpliéndose dentro de los plazos previstos por el ingeniero de requisitos. Nivel 3: Definido Aquí las organizaciones ya tienen un proceso de Ingeniería de Requisitos definido. Además, la organización cuenta con un modelo de mejora de procesos, lo que le permite adaptarse a nuevos métodos y técnicas según sus necesidades. En este nivel cuenta la experiencia de la organización y del ingeniero de requisitos en aplicar sus conocimientos y buenas prácticas del proceso de requisitos. 39

40 Para clasificar a la organización en estos niveles, el modelo propone buenas prácticas clasificadas en tres grupos: básicas, intermedias y avanzadas. El ingeniero de requisitos junto con el director o gestor del proyecto que se esté realizando debe constatar si se están aplicando estas buenas prácticas, de esta manera se puede clasificar a la organización en uno de los niveles de madurez. Durante la realización del proyecto REAIMS se constató que la mayor parte de las empresas europeas se ubicaban en un nivel de madurez inicial. Para las organizaciones que no poseen ningún proceso de requisitos, se proponen 10 buenas prácticas: 1. Definir una estructura normalizada del documento de requisitos. 2. Hacer el documento fácil de cambiar. 3. Identificar de manera única cada requisito. 4. Definir políticas para la gestión de requisitos. 5. Definir plantillas normalizadas para la descripción de requisitos. 6. Usar el lenguaje de forma simple, consistente y concisa. 7. Organizar revisiones formales de los requisitos. 8. Definir listas de comprobación para la validación. 9. Usar listas de comprobación para el análisis de los requisitos. 10. Planificar los conflictos y su resolución. 9 Tabla 3. Porcentaje de mejores prácticas aplicadas a los niveles de madurez. NIVEL Inicial Repetible Definido MEJORES PRÁCTICAS/GRUPOS Menos del 55% de mejores prácticas básicas. Alrededor del 55% básicas y menos del 40% avanzadas. Más del 85% de las básicas, 40% más de las intermedias y avanzadas. 9 BERNÁRDEZ, Beatriz. (2001). Modelo aplicado a la calidad de la ingeniería de requisitos. Universidad de Sevilla. Documento digital. 40

41 Las buenas prácticas son aplicadas a actividades definidas por el mismo modelo, estas son: documentación de requisitos, captura de requisitos, análisis-negociación, descripción de requisitos, modelización de requisitos, validación de requisitos, gestión y validación de sistemas críticos. Las mejores prácticas se aplican a todas las actividades a excepción de la documentación, descripción y modelización de requisitos en las que no se aplica las mejores prácticas avanzadas MODELO DE VOLERE Este quizá es el modelo que ha servido de base para la construcción de los demás modelos, posee un conjunto de actividades que se relacionan e interactúan de manera iterativa, lo que hace que el proceso de Ingeniería de Requisitos se vuelva eficaz y eficiente. Este es un modelo de procesos genérico, útil para definir, analizar, especificar y validar los requisitos. Estudio de viabilidad Uso del producto y evolución Análisis y definición de requisitos Reutilización de requisitos Prototipado de los requisitos Revisión de la especificación Borrador de requisitos Calidad de requisitos Ilustración 9. Modelo de Volere. Dentro de las principales actividades de este modelo están 10 : 10 Información tomada de: ROBERTSON, Z., ROBERTSON, J. (2006). Mastering the Requirements Process. Editorial Addison-Wesley. Sexta Edición. 41

42 1. Estudio de viabilidad: Aquí se obtiene la información necesaria que permita al ingeniero de requisitos determinar si es viable la construcción o desarrollo del proyecto, en base a los requisitos planteados por el cliente. Así mismo, se determina una estimación de los riesgos, costos del proyecto, stakeholders y restricciones. Esta actividad puede ser ejecutada en pocas horas o en algunos días, dependiendo de la experiencia del ingeniero de requisitos, y de la complejidad-tamaño del proyecto. 2. Análisis y definición de requisitos: Una vez completado el estudios de viabilidad, los requisitos deben ser analizados y definidos aplicando técnicas específicas utilizadas en la Ingeniería de Requisitos. Por ejemplo, se describe y representa los requisitos en casos de uso y se plantea escenarios para lograr identificar aquellos requisitos que deberán cumplir con la funcionalidad de la solución, además, se podrá identificar los potenciales requisitos que pueden ser usados en el desarrollo del proceso de construcción del proyecto. 3. Prototipado de los requisitos: Los requisitos son representados mediante un prototipo en el cual, el ingeniero de requisitos transforma estos en funcionalidades, estas funcionalidades son representadas mediante esquemas o interfaces de usuarios. El objetivo de esta actividad es mostrar al cliente una aproximación visual de cómo quedaría la solución y, de ser necesario, este planteará nuevos requisitos y/o restricciones que deberán ser descritos en el borrador de requisitos. 4. Borrador de requisitos: El ingeniero de requisitos debe describir los requisitos seleccionados para cumplir las expectativas y los objetivos del proyecto en un borrador de requisitos, este no es más que una plantilla donde se proporciona información sobre cada requisito obtenido del cliente y los stakeholders, los cuales se convertirán en requisitos formales, es decir, los verdaderos requisitos que representarán una determinada funcionalidad del proyecto previo el paso por pruebas de calidad de los mismos. 42

43 5. Calidad de los requisitos: En esta actividad se determina si los requisitos son correctos, antes de ser entregados a los desarrolladores. Se aplica un conjunto de pruebas para determinar la calidad individual de cada requisito. La persona encargada de hacer el testeo o prueba de los requisitos deberá autorizar el paso de los mismos si cumple con las expectativas del proyecto y no poseen inconsistencias. La calidad de los requisitos se refiere a la obtención de requisitos válidos, precisos y completos, que puedan ser utilizados en cualquier momento del proceso de desarrollo del software, logrando de esta manera aumentar el nivel de calidad del mismo. Se generará un documento de especificación de requisitos, donde se describirá cada uno de los requisitos aceptados y que cumplen con las necesidades del proyecto. En la especificación, el ingeniero de requisitos puede obtener un panorama de las funcionalidades que tendrá la solución, su arquitectura y además, será de mucha utilidad para los gestores del proyecto en la estimación de costos y esfuerzo necesario para el desarrollo del proyecto. 6. Revisión de la especificación: Luego de haber desarrollado el documento de especificación, es necesario hacer una revisión final, esto con el fin de identificar o encontrar posibles errores o conflictos en los requisitos que luego puedan afectar directa o indirectamente la solución a construir y que deben ser resueltos. La revisión permite confirman que la especificación realmente está completa y que se puede pasar a la siguiente actividad. 7. Diseño y construcción: Esta actividad se refiere a la implementación de los requisitos, es decir, al desarrollo del proyecto o de la solución que será entregado al cliente, en el cual deberán estar representadas todas las necesidades propuestas por el mismo. 8. Reutilización de requisitos: Muchas de las veces los proyectos que se construyen no son completamente eficientes, esto se debe a la mala aplicación de un proceso de desarrollo de software y al mal manejo de los requisitos. Por tal motivo, se genera un 43

44 conjunto de requisitos que pueden ser reutilizados en una nueva versión, del mismo proyecto para el que fueron obtenidos u otro similar. La reutilización no quiere decir que aquellos requisitos que se reutilicen deben ser directamente utilizados por los desarrolladores, estos deben pasar por el mismo proceso de análisis, definición, prototipado, calidad, etc. 9. Uso del producto y evolución: Esta actividad tiene que ver netamente con el uso del producto o solución desarrollado para el cliente. Con el uso posiblemente se planteen nuevas necesidades o requisitos por parte del cliente y que deberán ser consideradas para el desarrollo de una nueva versión del producto. Al ser este el modelo base para el desarrollo de los diferentes modelos de la Ingeniería de Requisitos, es necesario hacer una comparación entre las etapas, fases o actividades de cada modelo de requisitos frente al modelo de Volere. A continuación se muestra una contrastación del modelo de Volere frente al resto de modelos de requisitos: Tabla 4. Contrastación de actividades del Modelo de Volere frente a otros modelos de requisitos. MODELO DE VOLERE GENÉRICO POHL ESPIRAL SWEEBOK REAIMS Estudio de viabilidad X Análisis y Definición de requisitos X X X X X Prototipado de los requisitos X Borrador de requisitos X X X X Calidad de los requisitos X X Especificación de requisitos X X X Revisión de la especificación X X x X El Modelo de requisitos de Volere ha marcado la diferencia respecto al resto de modelos, cada uno de estos ha tomado ciertas etapas o actividades para la construcción y ejecución de su proceso de requisitos, si bien no tienen la misma identificación respecto al nombre de etapa o actividad, en el contexto son lo mismo, algunas de las etapas de 44

45 Volere son una combinación de un conjunto de actividades y tareas referentes a la Ingeniería de Requisitos. Es así que, por ejemplo para el desarrollo del Modelo de Pohl se han tomado las siguientes actividades del Modelo de Volere: Modelo de Volere Modelo de Pohl Estudio de viabilidad Uso del producto y evolución Negociación Análisis y definición de requisitos Reutilización de requisitos Captura Especificación y documentación Prototipado de los requisitos Revisión de la especificación Borrador de requisitos Calidad de requisitos Validación y verificación Ilustración 10. Contrastación de las actividades del Modelo de Volere frente al Modelo de Pohl. En el Modelo de Pohl, la actividad de negociación de requisitos está basada en el análisis y definición de requisitos del modelo de Volere, en dicha actividad se aplicará técnicas específicas de Ingeniería de Requisitos con el fin de obtener requisitos que cumplan con las funcionalidades de la solución y con los objetivos planteados por el equipo de desarrollo, además de identificar requisitos potenciales que pueden ser usados durante el proceso de desarrollo de un proyecto. El borrador de requisitos y revisión de la especificación son dos de las actividades del Modelo de Volere que Pohl integra en su proceso de requisitos en la actividad de especificación y documentación. En esta actividad del Modelo de Pohl se deberá describir cada uno de los requisitos negociados, al ser un modelo iterativo, en cada iteración se 45

46 realizará una revisión de la especificación de los requisitos, se documentará los nuevos y potenciales requisitos capturados y usados durante el desarrollo de un proyecto. La validación de requisitos del Modelo de Pohl se basa en la actividad de calidad de requisitos de Volere. En esta actividad se revisa si cada uno de los requisitos que pasaron por la especificación es correcto y no poseen inconsistencias. Al final se deberá obtener requisitos con un alto nivel de calidad. Del mismo modo, algunas de las actividades del Modelo de Volere se pueden contrastar con las etapas de los demás modelos de requisitos, al realizar un análisis exhaustivo se podrá verificar que dichos modelos están basados o que tienen una relación directa con el proceso de requisitos desarrollado en el Modelo de Volere COMPARACIÓN ENTRE LOS MODELOS Tabla 5. Comparación entre Modelos de Proceso de IR. ACTIVIDADES MODELOS GENÉRICO POHL ESPIRAL SWEEBOK REAIMS VOLERE Captura X X X X X X Análisis X X X X X X Borrador de X X X requisitos Negociación X X X X X Descripción de requisitos X X Modelado de requisitos X X Especificación de requisitos X X X X Validación X X X X Gestión X X Todos los modelos son similares en cuanto a las actividades que realizan, pero tiene sus diferencias, las que radican en la aplicación de un número determinado de actividades y en la forma de hacerlo, sea esto iterativo o secuencial. La elección del modelo no depende del número de actividades, sino de la eficacia y eficiencia con que se lo aplique. Los ingenieros de requisitos deben conocer cada uno de 46

47 estos modelos, debe seleccionar y aplicar alguno en base a la complejidad del problema o las necesidades del sistema o proyecto que se desea construir. Si es un proyecto simple y sin muchos requisitos por parte del usuario, donde el tiempo y los recursos para construir una solución son cortos, se puede seleccionar el modelo estándar o genérico de procesos. Si se tiene un proyecto sumamente complejo, en el cual se encuentra invertido mucho tiempo y una gran cantidad de recursos, es probable aplicar el modelo de Pohl o el espiral, con los cuales se puede obtener de forma iterativa resultados en cada actividad que se realice. El modelo que mejor se puede aplicar y acoplarse a cualquier empresa constructora de software es el modelo de madurez de REAIMS, que mediante las actividades y las buenas prácticas propone un mejor tratamiento de los requisitos y sobre todo trata de disminuir los errores o conflictos de los mismos con el fin de lograr desarrollar una solución con un alto nivel de calidad. Además que, permitirá a dichas empresas o al ingeniero de requisitos aplicar otros modelos de proceso de requisitos para sus proyectos, según el nivel de madurez que hayan adquirido. 47

48 CAPÍTULO III 3. TÉCNICA UTILIZADAS EN LA INGENIERÍA DE REQUISITOS Existen algunas técnicas que se utilizan en la Ingeniería de Requisitos ya sea a nivel general o en cada una de las etapas del proceso. Dichas técnicas pueden ser de mucha ayuda para los ingenieros de requisitos, tanto para facilitar la obtención de los requisitos como para lograr definir las funciones que tendrán el sistema o proyecto en función de las necesidades de cada cliente. Hay algunas técnicas muy conocidas que no sólo se las utiliza en Ingeniería de Requisitos, sino que también en otras áreas simples o complejas como: talleres, estudios de mercadeo, estudios estadísticos, etc. A continuación se detalla las técnicas más utilizadas en la Ingeniería de Requisitos ENTREVISTA Es la más conocida y la más utilizada por parte de los ingenieros de requisitos. Con la utilización de esta técnica se intenta recoger información de los stakeholders, a través de una comunicación personal que se lleva a cabo por medio de una conversación. Aunque es inevitable hacerla a los clientes, necesita ser desarrollada, analizada y aplicada cuidadosamente y sobre todo que con ella se trate de obtener la mayor información posible para poder definir o redefinir un sistema o proyecto. Aquí entran dos elementos: el entrevistador, cuya función puede ser tomada por el Ingeniero de Requisitos; y el entrevistado. El entrevistador debe tener ciertas cualidades que le permitan establecer una comunicación adecuada y estable, además, debe mantener siempre una actitud acorde al momento, y sobre todo tener conocimiento de la técnica que está aplicando. Es importante destacar que el entrevistado muchas de las veces puede presentar algún tipo de rechazo, no aceptación o agresividad ante la actuación del entrevistador. Aquí entra en juego la experiencia del entrevistador para ser 48

49 paciente ante esta actitud y, tratar de manejar la situación haciendo entender al entrevistado de la importancia de tratar el tema. El entrevistador debe limitarse a comprender, escuchar, observar y respetar las opiniones del entrevistado. El entrevistado es el que decidirá si se pone en marcha o no el desarrollo del sistema o proyecto. Algunas de las cualidades que debe tener el entrevistador son: Saber observar y escuchar Poseer madurez Ser objetivo e imparcial No ser autoritario Comprensión Ser cordial y accesible Ser sincero, paciente y sereno Ser prudente Tener actitud para afrontar la situación Tener conocimiento de la técnica La entrevista posee tres fases: 1. Preparación 2. Realización y conducción 3. Análisis de la entrevista Preparación: El entrevistador debe realizar una investigación previa de la situación que va a afrontar, es decir, conocer el problema que va a tratar. Además, debe tener identificado y preparar a las personas que va a entrevistar y que le podrían proporcionar la mayor cantidad de información. Debe definir o planificar lugar, hora y fecha de la entrevista. 49

50 Realización y Conducción: Se debe establecer una un ambiente confortable que le permita al entrevistado sentirse cómodo ante la situación. Las preguntas que se hagan tienen que ser abiertas y claras, acordes al tema que se esté tratando. El entrevistado debe hacer lo posible por mantener el control de la entrevista obteniendo el máximo de información. Cuando haya terminado la entrevista se debe establecer nuevas citas de ser necesario. Análisis de la entrevista: Esta fase no debe pasar por alto, las notas obtenidas en la entrevista deben ser pasadas a limpio y de forma organizada. El entrevistador debe analizar y contrastar la información tomada de las distintas fuentes, evaluar cómo le ha ido en las entrevistas y proponer aspectos que crea conveniente ser mejorados CUESTIONARIOS Y CHECKLIST El objetivo principal es hacer que el ingeniero de requisitos y el grupo de desarrollo conozcan el entorno del problema en el que deben desenvolverse. Consta de una serie de preguntas precisas y fáciles de entender, en las que el cliente o stakeholders pueda realizar respuestas cortas. Cada pregunta puede tener una o varias opciones, esto depende del nivel de detalle o de la estructura del cuestionario que realice el ingeniero de requisitos para obtener información. Esta técnica va de la mano con la entrevista, con el fin de recoger la mayor cantidad de información del problema. Puede ser utilizada también antes de la entrevista como preparación a esta, con el fin de tener conocimiento sobre el tema que debe tratar con los entrevistados. La formulación de las preguntas, el número de opciones por pregunta, ó, el total de personas que sean encuestadas, dará al ingeniero de requisitos la posibilidad de obtener a detalle las necesidades o los requisitos necesarios para el desarrollo de una solución. 50

51 3.3. TORMENTA DE IDEAS (BRAINSTORMING) Es una técnica de grupo, en la que se lanzan o generan ideas que son criticadas y analizadas libremente. Puede ayudar a los ingenieros de requisitos a obtener diferentes vistas o enfoques del problema o de las necesidades de los clientes y plantear del mismo modo soluciones de diversas formas. Al no tener una organización clara no produce el mismo resultado que otras técnicas utilizadas en la Ingeniería de Requisitos. Podría ser de mucha utilidad cuando aún no se ha obtenido o identificado con claridad los requisitos. Una recomendación es que el número de participantes no debe sobrepasar de diez, una de estas debe tomar el rol de moderador o director del grupo. Este no tiene la necesidad de controlar el grupo. Es muy sencilla de usar a la hora de aplicarlo a la captura de requisitos. Permite obtener una visión general y clara de las necesidades del sistema o proyecto, pero no se puede obtener suficiente detalle sobre los mismos JAD (JOINT APPLICATION DEVELOPMENT) Significa Desarrollo Conjunto de Aplicaciones y supone una alternativa a las entrevistas individuales, y se desarrolla a lo largo de un conjunto de reuniones de grupo en un período de 2 a 4 días 11. Cada una de las reuniones que se realiza ayuda al usuario o cliente a establecer los requisitos, el verdadero problema y cuáles van a ser sus posibles soluciones, esto con el fin de integrarlo en el proceso de desarrollo de la solución. En cada reunión, el grupo puede determinar algunas conclusiones que deben ser documentadas, por lo que conforme avanzan estas, se obtiene una visión clara de las necesidades del sistema. Esta es aplicada a las actividades de captura y especificación de requisitos. 11 GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: 51

52 Además, se puede obtener una idea clara del diseño de la solución a la que se quiere llegar, lo que comúnmente se dice: Lo que ves es lo que obtienes 12. Esta técnica en comparación con la entrevista posee algunas ventajas, lo que la hace más aplicable al proceso de Ingeniería de Requisitos. Las ventajas son: Ahorra tiempo, evitando que las opiniones de los clientes o stakeholders tengan de contrastarse por separado. Todo el grupo, esto incluye: clientes, stakeholders, ingeniero de requisitos, revisan toda la documentación e información desarrollada. Va orientado más a los clientes o stakeholders inmersos en el desarrollo de la solución. Pero también tiene sus desventajas, a continuación se menciona algunas de ellas: Tiempo de para preparación de las reuniones no definido. La obtención de muchas ideas puede llegar a confundir al ingeniero de requisitos. Al incluir a los clientes, stakeholders, y su no preparación técnica en la revisión de la documentación, puede ocasionar conflictos, malestar e insatisfacción por lo elaborado CASOS DE USO Es una de las técnicas mayormente utilizada en el desarrollo de proyectos o sistemas. Estos describen las interacciones que se producen entre el sistema y los actores para ejecutar una determinada función. Facilitan la captura de requisitos, ayuda en la especificación de los mismos y pueden ser de mucha utilidad en la validación y verificación de requisitos. Son fácilmente entendidos por los clientes o usuarios. Los actores pueden interactuar o participar con varios casos de uso dependiendo del contexto del problema, así mismo, un caso de uso puede interactuar con varios actores. 12 GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: 52

53 Un caso de uso especifica el comportamiento de un sistema o una parte del mismo, y es una descripción de un conjunto de secuencias de acciones, donde cada secuencia representa la interacción de los elementos externos del sistema (sus actores) con el propio sistema. Un caso de uso representa un requerimiento funcional del sistema. 13 Un Caso de Uso describe un servicio provisto por un sistema, es decir un modo específico de usarlo. El conjunto completo de Casos de Uso especifica todas las posibles maneras en las que el sistema puede ser usado, sin revelar cómo esto es implementado por el sistema. 14 Cada caso de uso que se defina debe tener su respectiva documentación, con detalle de nombre de caso de uso, descripción, flujo normal y alternativo, etc. El detalle dependerá de las necesidades del problema. Para esto se utiliza plantillas, en las que se numera y describe las interacciones usando lenguaje natural. La plantilla puede modificarse según el ingeniero de requisitos que la aplique y el nivel de detalle que requiere. Nombre Caso de Uso: Autor: Fecha Descripción: Actores: Precondiciones: Flujo Normal: Flujo Alternativo: Poscondiciones: Tabla 6. Ejemplo de plantilla de Casos de Uso. 13 GUTIÉRREZ, Claudio. Departamento de Sistemas de Información. Universidad de Chile. Artículo sobre UML. Disponible en: 14 GIANDIN, R., PONS, C. Relación entre casos de uso y UML. Universidad Nacional de la Plata. Disponible en: 53

54 En la plantilla se debe poner el nombre del caso de uso que se vaya a detallar. El autor, la persona que va llenar la plantilla. Una fecha, una pequeña descripción y los actores que interactúan con el caso de uso. Las precondiciones son los hechos que deben cumplirse para que el flujo del evento se pueda llevar a cabo. El flujo normal se refiere a la ejecución normal del caso de uso. El flujo alternativo indica las opciones o acciones inesperadas que puede hacer el sistema ante un error o cambio de información en el flujo normal. Las Poscondiciones son hechos que deben cumplirse en caso de que el flujo normal se haya ejecutado correctamente. Cuando se tiene varios casos de uso, además, que han sido detallados completamente, es difícil relacionarlos. Es necesario utilizar un diagrama de casos de uso que permita tener una visión general del problema. En el diagrama de casos de uso se representa actores (quienes hacen uso o interactuarán con el sistema), funcionalidades (casos de uso) y las interacciones o asociaciones entre estas. Dichas interacciones son representadas por una línea, es aconsejable utilizar una línea con flecha para entender de mejor manera el comportamiento del sistema y obtener mejores resultados a la hora de analizar el diagrama de casos de uso. Además, los límites del sistema o proyecto son representados por un cuadro que abarca todos los casos de uso que pertenezcan a él. Sistema CasoUso1 CasoUso2 Actor 1 CasoUso3 Actor 2 Ilustración 11. Diagrama de Casos de Uso. 54

55 3.6. WALKTHROUGHS Se define esta técnica como técnica de análisis estático en la que un programador o un diseñador dirige a miembros del equipo de desarrollo u otras personas interesadas a través de un segmento de documentación o código y los participantes realizan comentarios sobre posibles errores, violaciones de estándares de desarrollo y otros problemas 15. El objetivo primordial de esta técnica es identificar errores o conflictos en la documentación o definición de requisitos, esto se lo puede hacer a nivel de casos de uso ya que aquí se pone a conocimiento el funcionamiento del sistema o proyecto y se puede revisar minuciosamente cada aspecto y plantear opiniones al respecto. El ingeniero de requisitos que realiza y ejecuta esta técnica a detalle, puede dar a conocer los resultados a los participantes con el fin de conocer sus criterios, para luego reducir al máximo los errores o conflictos encontrados PROTOTIPADO Permite capturar información y validar la solución o producto que se ha desarrollado mediante prototipos. Es una representación gráfica clara de lo que el usuario quiere o va a recibir. A través del prototipado se logra reducir costos en desarrollar o reconstruir un sistema o proyecto. Son muy necesarios para comunicarse con el usuario o cliente, permitiendo determinar el nivel de usabilidad e interacción del mismo, e identificar o redefinir ciertos aspectos de la solución. Según el estándar ISO 13407, el prototipo se define como: una representación de todo o parte de un producto o sistema que, aunque limitado de algún modo, puede utilizarse con fines de evaluación GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: 16 FERRÉ, Xavier. Marco de Integración de la Usabilidad en el Proceso de Desarrollo de Software. Facultad de Informática. Universidad Politécnica de Madrid. Resultados de Tesis Doctoral. Disponible en: 55

56 Existen tres tipos de prototipos: 1. Prototipo de la interfaz del usuario: Es un modelo evolutivo de cómo va quedando la interfaz del usuario en base a los requisitos o necesidades planteados. Puede ser desarrollado en papel, ejecutable del sistema o proyecto en desarrollo o software específicos que se las encuentra libremente en el mercado. 2. Prototipos de rendimiento: Estos no incluyen la interfaz del usuario. Va orientado a los desarrolladores, con el fin de comprobar la funcionalidad de los componentes de la solución que se está desarrollando. No se aplica a la Ingeniería de Requisitos. 3. Prototipo funcional: Es una versión limitada de la solución desarrollada. No se aplica a la Ingeniería de Requisitos. El uso de prototipos puede tener ventajas, así como también desventajas al aplicarlo en la Ingeniería de Requisitos. Dentro de las principales ventajas y desventajas de esta técnica están: Tabla 7. Ventajas y desventajas del Prototipado. VENTAJAS Viabilidad y utilidad del sistema o proyecto. Permite desarrollar interfaces de usuario en base a los requisitos. Permite encontrar requisitos incorrectos o inconsistentes. DESVENTAJAS Elevados costos en capacitación de prototipado. Costos en el desarrollo de prototipos. Se alarga el tiempo de entrega de la solución. Al no ser reales ni considerar el rendimiento de la solución, los clientes o stakeholders pueden tener una mala impresión de lo que realmente se desea desarrollar. 56

57 Los prototipos pueden llegar a ser muy útiles si se lo sabe aplicar correctamente y en el momento oportuno. En la captura y validación de requisitos puede llegar determinar realmente lo que el usuario desea y lo que quiere ver. Deben ser fiables y describir exactamente los componentes o funcionalidades tomados en cuenta en el prototipado OPORTUNIDADES La aplicación de cualquiera de las técnicas mencionadas de la Ingeniería de Requisitos como parte de cualquier metodología o proceso de desarrollo de software es fundamental para lograr un proyecto o producto de calidad, es así que, las oportunidades de mejora de procesos de requisitos de software a través de la aplicación de este tipo de técnicas salen a relucir. Se pueden identificar las siguientes oportunidades: Mejora el proceso de captura de requisitos o necesidades y recolección de información para el desarrollo de los diferentes tipos de proyecto. Identificación de funcionalidades o módulos de un producto. Identificación de errores o inconsistencias en los requisitos capturados, negociados y especificados. A través de la documentación obtenida de la aplicación de estas técnicas, se puede dar a conocer tanto al equipo de desarrollo como a los stakeholders, cada uno de los requisitos capturados, negociados y validados. Representación gráfica de la posible solución de un proyecto a través de módulos funcionales o no. Identificación de los potenciales usuarios de un sistema o proyecto. Obtención de requisitos precisos, completos, fiables y sin inconsistencias. Capacitación del personal sobre las diferentes técnicas utilizadas en la Ingeniería de Requisitos para el desarrollo de los diferentes tipos de proyectos. 57

58 CAPÍTULO IV 4. HERRAMIENTAS SOFTWARE DE INGENIERÍA DE REQUISITOS UTILIZADAS EN EL MEDIO Conforme a avanzado el desarrollo de proyectos y la necesidad de automatizar algunos procesos para agilizarlos y dar mejores prestaciones a los usuarios a través del software, se ha creado herramientas software que permiten administrar y gestionar los requisitos que se necesita para el desarrollo de un proyecto o sistema, algunas de estas son herramientas libres y otras pagadas. La utilización de estas, permite un mejor manejo, detección de los errores y conflictos encontrados en los requisitos del cliente o stakeholders, reduciendo tiempo y costos en la fase de requisitos de proyectos con un alto nivel de complejidad. Dentro de las herramientas utilizadas en la Ingeniería de Requisitos están 17 : Rational Requisite Pro IRqA (Analizador integral de requisitos) LEAP SE Visual Requisite La elección de alguna de las técnicas y herramientas software, depende de la metodología de desarrollo de software que se vaya a aplicar y del tipo de proyecto a construir, es así que, en un proyecto de gestión académica universitario en el que se esté aplicando RUP como metodología de desarrollo, es posible que el ingeniero de requisitos aplique Rational Requisite Pro, ya que es una herramienta propia de esta metodología y, le permite manejar y administrar de forma adecuada la gran cantidad de requisitos que se generan del proyecto. 17 Para mayor información sobre el funcionamiento y características de las herramientas utilizadas en la Ingeniería de Requisitos, revisar el Anexo 3. 58

59 4.1. CARACTERÍSTICAS DEL PROCESO DE ADMINISTRACIÓN DE REQUISITOS Luego de haber realizado un estudio sobre el proceso, modelos, actividades, técnicas y herramientas que deben desarrollar en la Ingeniería de Requisitos como parte de todo desarrollo de proyectos o software, es necesario identificar algunas de las principales características que se deben tomar en cuenta a la hora de aplicar una Ingeniería de Requisitos exitosa y seleccionar una herramienta que ayude a lograr dicho propósito. Dentro de las principales características están: Captura de requisitos, comprende la obtención de los requisitos o necesidades planteados por el cliente. Análisis, se realiza la identificación de los requisitos y la clasificación por tipo: funcional, no funcional, de software, de usuario, de interfaz, de negocio. Negociación, implica contrastar y dar opiniones respecto a los requisitos que se han obtenido, con el fin de determinar las funciones y las restricciones que tendrá el sistema o proyecto. Especificación, consiste en la definición, descripción detallada y completa de cada uno de los requisitos que serán sometidos a validación. Validación y verificación, comprobar que los requisitos obtenidos cumplen con los objetivos del cliente y si fueron construidos en base a estándares o criterios desarrollados por el equipo de desarrollo. Gestión de requisitos, se realiza la comprensión y control de los cambios de cada uno de los requisitos. Trazabilidad, consiste en determinar el ciclo de vida de los requisitos, además de que cada uno de estos posee su propia identificación, diferenciándolos de los demás. Facilidad de uso, quiere decir facilidad en el manejo de herramientas para la administración de requisitos por parte de aquellas personas que realicen el mantenimiento y explotación de los mismos, además de su fácil modificación tanto en su estructura como en su estilo o tipo. 59

60 Redundancia, no se debe permitir redundancia, cada uno de los requisitos se debe utilizar en un solo lugar y ser identificados de manera diferente. Generación de modelos, algunas de las herramientas utilizadas en la Ingeniería de Requisitos deben permitir generar modelos como: casos de uso, conceptuales, de estado entre otros; de tal manera que ayude a validar y verificar cada uno de los requisitos y a la identificación de potenciales errores. Comunicación de requisitos, los más importante en el desarrollo de todo proyecto es la comunicación que exista en el equipo de desarrollo, toda la información debe ser comunicada de manera oportuna, en el caso de los requisitos, a través de las herramientas se puede lograr esto con la generación de usuarios, estos tendrán acceso a cada uno de los requisitos con el fin de analizarlos, refinarlos de ser necesario y sobre todo obtener coherencia en los requisitos. Generar informes, la generación de informes es importante para el respectivo análisis de los requisitos y de un proyecto VENTAJAS Y DESVENTAJAS DEL USO DE HERRAMIENTAS SOFTWARE EN LA INGENIERÍA DE REQUISITOS VENTAJAS Algunas de las herramientas permite generar grandes repositorios de requisitos que pueden ser utilizados no solo en uno, sino en varios proyectos dependiendo del contexto en el que se maneje. Permite tener una visibilidad clara de cada uno de los requisitos, es decir, la identificación de funcionalidades y restricciones que tendrá un proyecto o sistema. Permite dar seguimientos a los requisitos durante todo el desarrollo de un proyecto, el seguimiento implica trazabilidad, es decir, que los requisitos tendrán vida durante todo el proyecto. Algunas de las herramientas permite el manejo de versiones de los requisitos, es una característica importante a la hora de analizar los requisitos y verificar la evolución de cambios que se ha desarrollado. 60

61 Permiten generar modelos como casos de uso, de estado, diagramas de flujo entre otros, lo que facilita el análisis de los requisitos, su especificación y validación. Manejo de un grupo de usuarios, cada usuario registrado en el proyecto tendrá acceso a todos los requisitos capturados, podrá modificarlos, analizarlos, validarlos y notificar los cambios realizados. Controlar, administrar los requisitos y sus cambios para luego reutilizarlos en cualquier actividad del proceso de software que se necesite. Reducción de costos y tiempo en el proceso de requisitos de los proyectos. DESVENTAJAS Una de las principales desventajas es la cultura de uso de las herramientas de Ingeniería de Requisitos, dichas herramientas no son muy utilizadas en la administración y gestión de requisitos en el desarrollo de proyectos, en la mayoría de casos este proceso es manual, y en otros casos se usa plantillas elaboradas en Microsoft Word solo para captura de requisitos. La infraestructura necesaria para el uso de estas herramientas es otro impedimento, se necesita comunicar los equipos en red, en algunos casos, la utilización de bases de datos potentes para la obtención de grandes repositorios de requisitos es muy necesario. Los costos por licenciamiento de las herramientas que ofrecen grandes beneficios como por ejemplo Rational Requisite Pro e IRqA, son altos. Adicional a esto, se suma los costos de las herramientas que se incorporen o interactúen con las de requisitos. No permiten incorporar procesos ni modelos de Ingeniería de Requisitos CONTRASTACIÓN DE HERRAMIENTAS FRENTE A CARACTERÍSTICAS DE ADMINISTRACIÓN DE REQUISITOS En base a las características obtenidas del estudio de los procesos, modelos, actividades y herramientas utilizadas en la Ingeniería de Requisitos, es conveniente identificar cuáles de las herramientas mencionadas abarcan dichas características, con el fin de analizar y obtener aquella que mejor convenga utilizar a la hora de desarrollar un proyecto. 61

62 Tabla 8. Contrastación de herramientas frente a características de administración de requisitos. Requisite LEAP Visual Características IRqA Pro SE Requisite Captura X X X X Análisis X X Negociación Especificación X X Validación y verificación Gestión de requisitos X X X X Trazabilidad X X Facilidad de uso X X No Redundancia Generación de modelos X X X Comunicación de requisitos X X Generación de informes X X X X 4.4. OPORTUNIDADES Las herramientas software utilizadas en la Ingeniería de Requisitos cumplen con un aspecto importante sobre todo en el desarrollo de proyectos de alto nivel. A través de su uso se pueden identificar algunas oportunidades que deben ser tomadas en cuenta por parte del ingeniero de requisitos y del equipo de desarrollo. Podemos anotar: Gestión y administración de todos los requisitos capturados. Análisis y validación de requisitos. Análisis y validación entre versiones de requisitos. Identificación del tipo de requisitos: funcionales, no funcionales, de usuario, de interfaz, de negocio o Generación de modelos de casos de uso, modelos conceptuales. Generación de diagramas de base de datos. 62

63 Generación de código basado en clases, que se podría utilizar como capa de negocios de un proyecto. Generación de interfaces de usuario no funcionales. Construcción de casos de uso a partir de los requisitos capturados e ingresados en las herramientas. Mejorar la comunicación entre los miembros del equipo de desarrollo de software, lo que permitirá obtener una coherencia en los requisitos. Mantener al tanto a todos los miembros del equipo de desarrollo de cada uno de los nuevos requisitos ingresados para un proyecto o de los cambios efectuados en estos. Reutilización de requisitos para nuevos proyectos que impliquen características similares. Generación de reportes e informes detallados para el análisis de cada uno de los proyectos que se desarrollen. Control y gestión de los requisitos de cambio de los diferentes proyectos. 63

64 CAPÍTULO V 5. CONTRASTACIÓN DE HERRAMIENTAS Y ACTIVIDADES FRENTE A TIPOS DE PROYECTOS. Si bien es cierto, la mayor parte de los proyectos que realizan la empresas constructoras de software visitadas no tienen o no aplican una Ingeniería de Requisitos adecuada en el desarrollo de los mismos, lo que implica un conjunto de riesgos y posibilidades de fracaso. Necesariamente el no aplicar metodologías, procesos, técnicas o herramientas software en la obtención, análisis, validación, gestión de requisitos y otras actividades, no significa que esta área de la Ingeniería de Software lleva la mayor parte de responsabilidad en el fracaso de los proyecto, una parte sí, porque aquí se define prácticamente las funcionalidades del sistema y las verdaderas necesidades de los clientes. La otra parte es responsabilidad de las actividades del desarrollo del software y que es manejada por programadores, control de calidad, gestores del cambio, etc., en los cuales la participación del ingeniero de requisitos y el proceso de Ingeniería de Requisitos sólo se justifica con el cambio en los requisitos del proyecto o sistema en construcción, sea esto por nuevos requisitos pedidos por el cliente o por inconsistencias encontradas en el desarrollo de la solución PROYECTOS Y TIPOS DE PROYECTOS Más que definir los proyectos y sus tipos es preciso hacer una diferenciación o un análisis de lo que conlleva realizarlos con criterios basados en su amplitud, complejidad o nivel de usuarios. Para un mejor análisis se los ha separado en tres niveles de proyectos, de alto nivel, proyectos en los cuales su tiempo de desarrollo es extenso y tienen un grado alto de complejidad; los de nivel medio, que son aquellos en los cuales los recursos, la información, el alcance y la complejidad de desarrollo es intermedia a los de alto y bajo 64

65 nivel; y los de bajo nivel que no se utiliza mucho tiempo en su construcción, son simples y la información necesaria es obtenida con facilidad. Los proyectos de alto nivel involucran un extenso tiempo de desarrollo y nivel muy alto de complejidad y ambigüedades, por lo que el ingeniero de requisitos junto con el equipo de desarrollo y los analistas que interviene deben estar preparados para seleccionar y determinar los requisitos o necesidades de los clientes. La mayoría de estos proyectos son destinados a un conjunto de usuarios (proyectos multiusuario), por este motivo es que se torna extenso su desarrollo, se debe recoger información no sólo de los clientes, sino también de cada una de las personas que están directamente relacionadas con el uso del sistema o proyecto, por ejemplo: un sistema de gestión académica universitario, se recoge datos y requisitos de las secretarias, directores departamentales, personal financiero, estudiantes, etc. Es sumamente costoso y cualquier error durante sus fases de desarrollo incrementaría su costo y tiempo. En este tipo de proyecto están: proyectos industriales, académicos, empresariales, inteligencia artificial, biotecnología, bancarios, etc. Se considerarían proyectos de nivel medio, aquellos en los que los recursos, la cantidad de participantes, equipo de desarrollo, complejidad, alcance, cantidad de información y requisitos son promediados, es decir, un nivel intermedio entre los proyectos de alto y bajo nivel. El desarrollo de este tipo de proyectos no involucra grandes recursos económicos y tampoco un extenso tiempo de desarrollo. El número de usurarios para estos proyectos es medio. Los proyectos de bajo nivel no involucran a muchas personas y están destinados a un mínimo de usuario, es mucho más fácil la tarea de obtención de requisitos y posterior desarrollo porque sólo se toma en cuenta las necesidades de los clientes y se debe procurar satisfacerlas al máximo, cualquier error o falta de requisitos en el proceso puede ser solucionado rápidamente sin que esto implique un coste económico y de tiempo. El tiempo de desarrollo es corto, así mismo la extensión del proyecto. Por ejemplo: un sistema de facturación para un supermercado, la información se obtiene directamente del 65

66 cliente o posiblemente de un cajero, porque estos son los que manejarán el sistema, los componentes del sistema son pocos y limitados. Aquí están proyectos como: generador de reportes, inventario, ventas, etc. Las herramientas software son esenciales en el desarrollo de proyectos de alto nivel, pues de esta forma les permite a los ingenieros de requisitos o al equipo de desarrollo de software administrar o gestionar los requisitos proporcionados por sus clientes. Además, facilitan la comunicación entre los miembros del equipo, la fuga o pérdida de información de cada uno de los requisitos capturados y, lo más importante, se tiene trazabilidad de dichos requisitos, es decir, el tiempo de vida de cada uno de los requisitos durante el desarrollo de cualquier proyecto. Además de la diferenciación entre proyectos, es preciso hacer una categorización que diferencie o identifique claramente el tipo de proyecto que se desea construir, de tal forma que, para establecer esta categorización se ha tomado en cuenta ciertos aspectos que propone Pressman 18 para la estimación del tamaño de un proyecto o software (tamaño de componentes estándar): número de usuarios, módulos, transacciones, interfaces, requisitos de cambio diarios, relación o conexión con otros sistemas, entre otros. Tabla 9. Categorización para Proyectos. Aspectos a evaluar Alto Nivel Nivel Medio Bajo Nivel Usuarios Módulos Transacciones/día Interfaces Requisitos de cambio Relación otros sistemas 2 o más Al menos 1 - Cada uno de los valores propuestos, son valores que si bien no son reales, se aproximan a la realidad del desarrollo de proyectos en sus diferentes tipos. 18 PRESSMAN, Roger. (2005). Ingeniería del Software, un enfoque práctico. Editorial McGraw-Hill. Sexta Edición. 66

67 5.2. PROCESOS DE INGENIERÍA DE REQUISITOS EN ORGANIZACIONES En organizaciones en las cuales el manejo de requisitos en sus sistemas es una realidad, sean entidades financieras, desarrollo de software, recaudación de impuestos, etc., no existe un manejo o administración de los requisitos de dichos sistemas. Algunos desconocen de la importancia de realizar prácticas adecuadas que les permita de forma ordenada, eficiente, eficaz y con un alto grado de calidad, gestionar los requisitos que en sus sistemas o en la construcción de soluciones para sus clientes. Algunos de los casos son deficientes, no se manejan al menos un acta de reuniones, en la cual se describan o mencionen de manera breve cuáles son las necesidades que sus clientes tienen Proceso de requisitos en la COOPMEGO Departamentos de la COOPMEGO participar Entrevista plasmar Requisitos-Acta de reuniones solicitan_sistema realizar elaborar Departamento de Informática pertenece Programador Prototipado del sistema desarrolla Sistema realiza encagar si Estudio de viabilidad decide Desarrollar sistema? no Comprar Sistema Ilustración 12. Proceso de requisitos de la COOPMEGO. La Cooperativa de Ahorro y Crédito Manuel Esteban Godoy Ortega (COOPMEGO), en el desarrollo de sus proyectos y sistemas no utilizan específicamente una metodología ni un proceso de Ingeniería de Requisitos, algunas actividades son cumplidas y otras no, pero si utilizan algunas técnicas de Ingeniería de Requisitos como entrevista y JAD. Cualquier 67

68 persona de la institución que desee un sistema acorde a las tareas que realice, hace el pedido al departamento de tecnología. Un equipo de este departamento realiza una entrevista con la persona interesada para obtener los requisitos. Luego, los miembros del departamento de tecnología realizan un estudio de viabilidad, en el cual se define o determina si el sistema pedido, se encarga a un programador del departamento o si resulta mejor la compra de un sistema o solución similar. Si el sistema es desarrollado por un programador del departamento, los requisitos son plasmados en un acta realizada en Microsoft Word y definida por esta área de la entidad. En estas plantillas se menciona el nombre del departamento para el cual se construirá o comprará el software, lugar y fecha de obtención de los requisitos, el responsable de redactar al acta, antecedentes, los objetivos que se quiere lograr con la construcción del sistema, el detalle o descripción de los requisitos y el nombre de los participantes de la reunión. Además, en esta acta se hará constar el nombre de la persona que ha pedido cambios en los requisitos del sistema y su equivalente impreso con su firma, esta persona siempre será una con mayor rango de responsabilidad o en orden jerárquico de autoridad. Esto se realiza con el fin de evitar problemas en el supuesto caso que, la persona que pidió el sistema no esté de acuerdo con el sistema obtenido. Luego de la reunión y redacción del acta, se realiza un prototipado de los requisitos, con el fin de dar a la persona interesada una idea clara de los que realmente desea, además de obtener nuevos requerimientos. Cabe destacar que los prototipos únicamente son utilizados en la obtención y definición de requisitos iniciales. Para los demás casos, los requisitos son gestionados en plantillas. Los cambios en los requisitos, sea esto en la etapa inicial, cuando los estos están definidos, o cuando ya se ha construido el sistema, son manejados en versiones, para lo cual manejan el software MS Visual SourceSafe como herramienta de control de dichas versiones Información obtenida de la entrevista con el Ing. Julio Guarderas. Miembro del Depto. De Informática de la COOPMEGO. 68

69 Proceso de requisitos en el Banco de Loja participar Departamentos Banco de Loja Reuniones periódica para definir requisitos solicitan_sistema realizar Área de Informática decide Desarrollar sistema? si Autorización del Gerente si Comprar Sistema no desarrolla no Sistema desarrollar Ilustración 13. Proceso de requisitos del Banco de Loja. En el Banco de Loja, en la mayoría de sus sistemas construidos y por construir, los requisitos son manejados en plantillas de Microsoft Word. Los sistemas son construidos o comprados según las necesidades de la entidad o por pedido del personal para cubrir una tarea o responsabilidad, previo la autorización de su Gerente General. En caso de construir dichos sistemas, los miembros encargados de desarrollar estas soluciones en el área de informática, realizan reuniones periódicas con el o los interesados a fin de obtener los requisitos y posteriormente definirlos. Los requisitos definidos son detallados en plantillas determinadas por el área de informática. Aquí, consta el nombre de la persona que pide la solución, un nombre del requerimiento, fecha de obtención y una descripción. A partir de estos requisitos se empieza la construcción del sistema o solución pedida. En el caso que exista algún cambio en los requisitos, estos son plasmados en otra versión del mismo documento o plantilla. 69

70 Es evidente la no utilización de una metodología o un proceso de Ingeniería de Requisitos, por tal motivo, la mayor parte de los sistemas que posee el Banco de Loja son comprados Proceso de requisitos del SRI Departamentos del SRI requisitos_en Sistema Nacional de Recaudación de Impuestos solicita_req Departamento de Soporte Informático comunica elaborar Sistema Contable Plantilla de requerimientos solicitar Centro de Soporte Tecnológico del SRI (Quito) Proveedores Sistema de Inventario de Activos Sistema de RRHH Ilustración 14. Proceso de requisitos del SRI-Loja. En lo que respecta al Servicio de Rentas Internas (SRI), el único sistema propio es el de recaudación de impuestos manejado a nivel nacional. Poseen un sistema de contabilidad, de personal y de inventario de activos comprados. Si alguna persona de la entidad solicita un cambio de dichos sistemas, el departamento de Soporte Informático tiene que acudir al proveedor de estos y solicitar que se considere dichas necesidades del personal y se haga los cambios. El departamento de Soporte Informático maneja dos tipos de requisitos: Requerimientos de usuario y, requerimientos de aplicación. En lo que se refiere a requerimientos de usuario, tienen que ver con los que son las necesidades técnicas y tecnológicas de los empleados o personal de la entidad, sean estos suministros técnicos como: aplicaciones, 20 Información obtenida de la entrevista con el Ing. Boris Armijos. Miembro del Área de Informática del Banco de Loja. 70

71 reparación de equipos, impresoras, etc., suministros de oficina, etc. Para esto, el personal debe solicitar este requerimiento a través de una lista de distribución o también llamada mesa de apoyo, que no es más que la solicitud a través de un correo electrónico, a partir del cual se delega a una persona del departamento para que dé solución a este requerimiento. Los requerimientos de aplicación tienen que ver exclusivamente con el sistema de recaudación del SRI. Si alguna persona necesita tener una funcionalidad adicional o hacer algún cambio en algún componente, este debe solicitar directamente al Centro de Soporte Tecnológico del SRI en Quito a través de una plantilla. En esta plantilla deberá poner su nombre, cargo que desempeña, que requerimiento es el que desea, los objetivos que quiere lograr con el cambio en la funcionalidad o un nuevo requerimiento, que antecedentes existen y por último, cuáles son las características de la funcionalidad que está manejando, en caso de que se desee hacerlo sobre una existente. Por el motivo de no contar un software que les permita manejar o administrar adecuadamente los requisitos o necesidades de la entidad, han decidido hacer uso de MANTIS, un software que les permitirá hacer un seguimiento de las necesidades, depurar errores y todo lo que necesite revisión y mejora continuos Proceso de Requisitos en el TPE-L En el Tribunal Provincial Electoral de Loja (TPE-L) la situación en el manejo y administración de requisitos es crítica. En el sistema de escrutinios que se maneja a nivel nacional lo único que hacen es dar recomendaciones sobre mejoras o cambios en el sistema. Pero en lo que se refiere a los sistemas de inventario y de contabilidad de la institución, no se maneja un adecuado proceso de manejo o administración de requisitos. 21 Información obtenida de la entrevista con el Ing. José Luis Ponce. Director del Depto. Soporte Informático del SRI. 71

72 Si algún miembro de TPE-L que esté directamente relacionado con estos sistemas necesita un cambio en el sistema, el director del Centro de Cómputo realiza una única reunión con la persona interesada y escucha sus requisitos, no se maneja ninguna plantilla para determinar, analizar o definir realmente un requisito, todo se maneja verbalmente. Luego de la reunión el Director delega a una persona para que realice el cambio, en caso de no satisfacer las necesidades de la persona que solicitó, se tiene otra reunión, y así hasta lograr aparentemente, una solución eficiente Proceso de requisitos en empresas de desarrollo de software Muchas de las empresas de desarrollo de software, no toman en cuenta, o no entienden la importancia de aplicar una Ingeniería de Requisitos adecuada en la construcción de sus proyectos, productos o sistemas. Tal es el caso de la empresa de desarrollo de sitios y portales web de Joomla-Ecuador. Si bien ellos utilizan las metodologías, procesos de integración o desarrollo de módulos y componentes, para entregar soluciones eficientes y de acuerdo a las necesidades de sus clientes, y basados en estándares y marcos conceptuales de la Ingeniería de Software y lineamientos del desarrollo web; no realizan una adecuada Ingeniería de Requisitos, por ende no ponen atención ni a los proceso, ni a los modelos y sus actividades o herramientas para la gestión de requisitos. 23 Otro caso muy similar es el de i-solutions Group S.R.L. de Avellaneda-Argentina, empresa encaminada en el desarrollo web y software. Para ambos casos se utiliza los lineamientos y estándares de la web y de Ingeniería de Software respectivamente, en la construcción se atiende a un proceso de desarrollo, por lo general: Inicio, Diseño, Construcción, Pruebas e Implementación; pero en lo que se refiere a los requisitos el aporte es nulo Información obtenida de la entrevista con el Ing. Freddy Reyes. Director del Centro de Cómputo del TPE-L. 23 Información obtenida por colaboración del Ing. Boris Valencia. Gremio: Joomla-Ecuador. Contacto Ejecutivo. Quito. 24 Información obtenida por colaboración de la Srta. Eugenia Bahit. I-Solutions Group S.R.L. Avellaneda- Argentina. Contacto Ejecutivo. 72

73 Para los casos de las dos últimas empresas antes mencionadas, la entrevista es la única técnica y actividad de captura de requisitos que se utiliza, de ahí se obtiene la información necesaria para identificar las funcionalidades o componentes de los sistemas o productos que desarrollan. En algunos casos, según la complejidad de la solución, se tienen reuniones constantes entre el encargado de los requisitos y el cliente con el fin de refinar o comprender verdaderamente sus necesidades, en este caso, se podría considerar que existe una negociación o validación de los requisitos planteados Resumen del proceso de requisitos ejecutado en organizaciones A continuación se muestra un resumen de cómo se maneja el proceso de requisitos en las diferentes organizaciones visitadas: ORGANIZACIÓN PROCESO - HERRAMIENTAS PLANTILLAS MODELO COOPMEGO Manual No MS Visual SourceSafe, Microsoft Word Anexo 2 Banco de Loja Manual No Microsoft Word Si SRI Manual No MANTIS No TPE-L Manual No No No Joomla Ecuador Manual No No No i-solutions Group S.R.L. Manual No No No Ilustración 15. Resumen del proceso de requisitos ejecutado en organizaciones Oportunidades Al conocer el proceso de requisitos que se maneja en ciertas organizaciones del medio y, sobre todo de la no aplicación de herramientas software que faciliten el proceso de Ingeniería de Requisitos y el desarrollo de los diferentes proyectos, se presentan las siguientes oportunidades: 73

74 Capacitación al personal sobre las diferentes técnicas y herramientas software que se utilizan en la Ingeniería de Requisitos para el desarrollo de los diferentes tipos de proyectos. Auditoría sobre el proceso de requisitos y de desarrollo de proyectos realizados por el personal de dichas organizaciones. Aplicación de un modelo de requisitos en el desarrollo de proyectos o en el control y ejecución de requisitos de cambio de proyectos ya desarrollados. Evaluación de conocimientos del personal sobre Ingeniería de Requisitos, sus modelos y procesos COMPARACIÓN ENTRE PLANTILLAS DE HERRAMIENTAS El desarrollo o aplicación de plantillas para los requisitos es muy importante, de aquí se puede hacer un análisis, crear modelos, casos de uso e incluso identificar las funcionalidades o componentes de un proyectos o sistemas a desarrollar. Quizá la debilidad o desventaja más fuerte de las herramientas software que se utiliza sea la utilización de una plantilla de requisitos que sea completa y consistente. En el caso de IRqA los requisitos creados tienen los campos mínimos de creación de requisitos, esto es: nombre, descripción, tipo de requisitos y su asociación con el proyecto para el cual fue creado. Las versiones o los cambios en estos se maneja independientemente, esto permite comparar y analizar el estado y el porqué de los cambios realizados en los requisitos de cualquier proyecto. 74

75 Ilustración 16. Creación de requisitos en IRqA. Ilustración 17. Selección del tipo de requisitos en IRqA. Ilustración 18. Selección del proyecto al cual corresponde el requisito creado. Ilustración 19. Lista de requisitos creados para un proyecto. A partir de la lista de requisitos se realiza otro conjunto de acciones que tienen que ver con el análisis y especificación de los requisitos y la creación de diagramas. 75

76 LEAP SE utiliza una plantilla no muy específica o centrada en la creación de requisitos, pues utiliza o adjunta ciertos atributos que en lo posterior permiten realizar otras acciones como obtención del código fuente de un modelo de objetos, o generar un modelo de datos SQL. Lo más importante de esta plantilla es la elección de la categoría o del tipo de requisitos que se va a crear, y la prioridad. Dicha prioridad permite a los ingenieros de requisitos prestar más atención en su análisis, pues esto puede indicar que dicho requisito se puede convertir en un componente o funcionalidad de un sistema o proyectos, o su vez en lo que todo desarrollo o construcción de software tiene, un riesgo. Ilustración 20. Plantilla de creación de requisitos de LEAP SE. Para el caso de Visual Requisite, no posee una plantilla para la creación o fácil especificación de los requisitos, solamente se registra un nombre y una breve descripción de dichos requisitos. Lo más importante de esta herramienta es las acciones que se puede hacer en base a los requisitos, sea esto la creación de modelos, casos de uso u otros. 76

77 Cada uno de los requisitos creados puede irse relacionando con otros, se va conformando o identificando los componentes de la solución, se incorpora actores y se construye diagramas de casos o de uso o modelos mencionados anteriormente, se puede implementar varios componentes o características y relacionarlos con cada requisito creado. Ilustración 21. Creación de requisitos en Visual Requisite. La completitud y consistencia de las plantillas no significa crear un sin número de campos solamente para abultar dicha plantilla, sino significa considerar aspectos relevantes que luego le permitan al ingeniero de requisitos manejar y administrar de forma adecuada las necesidades o requisitos planteados por los clientes para el desarrollo de un proyecto o sistema, y para identificar los componentes verdaderamente útiles y funcionales de la solución que se vaya a construir. Las herramientas software debe contener algunos de estos aspectos relevantes, quizá no todos, pero si los más principales y necesarios en la Ingeniería de Requisitos. No existe una plantilla estándar para el manejo de los requisitos, ni una guía de creación de estas, pero se puede tomar ciertos aspectos que se podría considerar en una plantilla de requisitos, estos pueden ser: 77

78 Fecha de creación Responsable Un nombre que identifique realmente al requisito Una breve descripción Tipos de requisitos, funcional, no funcional, de sistema, interfaz, etc. Prioridad Manejo de versiones Responsable de cambios o de autorización de cambios Estado, es decir, si el requisito se encuentra activo, fue modificado o en proceso de eliminar Código, relacionado con el nombre del requisito Relación con otros requisitos o componentes de la solución 5.4. EVALUACIÓN DE LAS ACTIVIDADES, TÉCNICAS Y HERRAMIENTAS, FRENTE A TIPOS DE PROYECTOS De una muestra de 20 encuestas, realizadas a profesionales de la Ingeniería de Software, los mismos que han desarrollado proyectos en sus distintos niveles y que están directamente relacionados con la Ingeniería de Requisitos, sus actividades, modelos y herramientas, se ha obtenido los siguientes resultados Nivel de importancia de los requisitos en el desarrollo de proyectos Se toma como base la ubicación o escala de importancia que se le asigna a los requisitos por cada tipo de proyecto descrito a continuación: 78

79 Ilustración 22. Importancia de los requisitos en Proyectos de Bajo Nivel. Ilustración 23. Importancia de los requisitos en Proyectos de Nivel Medio. Ilustración 24. Importancia de los requisitos en Proyectos de Nivel Alto. 79

80 De lo que se puede observar de los datos recopilados, se determina que la importancia de los requisitos se incrementa conforme el alcance o complejidad de los proyectos, es decir, mientras cada uno de los proyectos incorpore mayor cantidad de usuarios, módulos, transacciones o requisitos de cambio, los proyectos alcanzarán un rango de importancia mayor Técnicas utilizadas en la captura de requisitos. Lo que se describe en las siguientes ilustraciones es la relación entre las técnicas de captura de requisitos y el porcentaje de personas que comúnmente las utiliza según el tipo de proyecto que ejecute. Ilustración 25. Técnicas utilizadas en la captura de requisitos en Proyectos de Bajo Nivel. 80

81 Ilustración 26. Técnicas utilizadas en la captura de requisitos en Proyectos de Nivel Medio. Ilustración 27. Técnicas utilizadas en la captura de requisitos en Proyectos de Nivel Alto. La utilización de una u otra es necesaria según el nivel de abstracción o cantidad de requisitos y detalle que se quiera obtener al momento de capturar los requisitos. Para los proyectos de Bajo y Medio Nivel la técnica más utilizada es la tormenta de ideas, por cuanto es una técnica básica y ocupa poco tiempo al momento de aplicarse. Para proyectos de Nivel Medio y Alto la entrevista es la técnica a la que más recurren los ingenieros de requisitos, debido al nivel de detalle de los requisitos y la cantidad de usuarios que están relacionados con el proyecto a desarrollarse. 81

82 Técnicas utilizadas en el análisis de requisitos. Esta relación describe las técnicas de análisis de requisitos adoptadas por los ingenieros de requisitos en el desarrollo de cada uno de sus proyectos. Ilustración 28. Técnicas utilizadas en el análisis de requisitos en Proyectos de Bajo Nivel. Ilustración 29. Técnicas utilizadas en el análisis de requisitos en Proyectos de Nivel Medio. 82

83 Ilustración 30. Técnicas utilizadas en el análisis de requisitos en Proyectos de Nivel Alto. Se puede observar que para los proyectos de bajo nivel la técnica más utilizada es Walkthroughs, debido a su fácil y rápida aplicación, con la que se identifican errores o conflictos en la documentación o código y en la definición de requisitos, mientras que para proyectos de nivel medio y alto la situación es muy diferente, en donde los casos de uso se considera la técnica más adecuada porque permite identificar de manera sencilla el comportamiento de un sistema y los usuarios relacionados con el mismo Técnicas utilizadas en la especificación de requisitos. Estas ilustraciones relacionan las técnicas de especificación de requisitos en cada nivel de proyectos y el porcentaje de las personas encuestadas que hacen uso de algunas de ellas. 83

84 Ilustración 31. Técnicas utilizadas en la especificación de requisitos en Proyectos de Bajo Nivel. Ilustración 32. Técnicas utilizadas en la especificación de requisitos en Proyectos de Nivel Medio. Ilustración 33. Técnicas utilizadas en la especificación de requisitos en Proyectos de Nivel Alto. 84

85 En los proyectos de bajo nivel, las técnicas de especificación de requisitos más aplicadas son Walkthroughs y casos de uso, por su sencillez al aplicarlas y fácil identificación de conflictos en los proyectos. Para los proyectos de nivel medio y alto la relación se mantiene para casos de uso y aparece otra técnica, el prototipado también relevante según el alcance del proyecto, permitiendo capturar información y validar la solución o producto que se ha desarrollado mediante prototipos, vale recalcar que con esta técnica se reduce significativamente los costos de desarrollo de los proyectos Técnicas utilizadas en la validación y verificación de requisitos. En las siguientes ilustraciones se analiza la frecuencia de uso de las técnicas para la validación y verificación de requisitos para los distintos niveles de proyectos. Ilustración 34. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Bajo Nivel. 85

86 Ilustración 35. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Nivel Medio. Ilustración 36. Técnicas utilizadas en la validación y verificación de requisitos en Proyectos de Nivel Alto. Para los proyectos de nivel medio y bajo la relación en cuanto a técnicas utilizadas es similar, por ejemplo, en ambos casos se aplica Walkthroughs, casos de uso y prototipado, que como se mencionó anteriormente son de fácil aplicación se consideran básicas en el desarrollo de los proyectos. Para proyectos de mayor alcance o nivel, las técnicas más frecuentadas son: el prototipado y casos de uso. 86

87 Modelos de Ingeniería de Requisitos utilizados en el desarrollo de proyectos. De la muestra, se estimó que en el desarrollo de proyectos de bajo nivel, el modelo que es utilizado frecuentemente, es el Modelo Estándar: Captura, Análisis y Validación. Ilustración 37. Modelos de Ingeniería de Requisitos utilizados en Proyectos de Nivel Medio. Ilustración 38. Modelos de Ingeniería de Requisitos utilizados en Proyectos de Nivel Alto. Los modelos Estándar y Espiral de Ingeniería de Requisitos son los más utilizados en los proyectos de Nivel Medio y Alto, pues se considera que los requisitos no llegarán a ser 87

88 perfectos, lo que implica aplicar modelos o procesos iterativos, en el caso del espiral, para obtener requisitos consistentes Herramientas utilizadas en el manejo o gestión de requisitos de los proyectos desarrollados. Ilustración 39. Herramientas utilizadas para gestión de requisitos en el desarrollo de proyectos. Para proyectos de nivel medio y alto, las herramientas más utilizadas por las personas encuestadas son IRqA y Requisite Pro, esto se atribuye a la cantidad de actividades de requisitos que dichas herramientas contienen, por ejemplo: captura, análisis, especificación, validación, gestión de los requisitos de los clientes, pruebas, trazabilidad de los requisitos. Para el caso de proyectos de nivel bajo, si bien existe un porcentaje de utilización de dichas herramientas, no es común su uso debido a la cantidad de requisitos que se maneja en este tipo de proyectos, su utilización implicaría un coste y tiempo mayores de los planificado CONTRASTACIÓN ENTRE ACTIVIDADES, TÉCNICAS Y HERRAMIENTAS, Y TIPOS DE PROYECTOS En el desarrollo de los proyectos, productos o sistemas relacionados a la Ingeniería de Software, además de basarse en sus estándares, metodologías y procesos para obtener 88

89 soluciones de calidad, eficaces y eficientemente funcionales, es necesario aplicar una Ingeniería de Requisitos adecuada, esta también es necesaria en la elaboración y consecución de dichas soluciones. No todo proyecto necesita que le apliquen al cien por ciento un procesos de Ingeniería de Requisitos. Es decir, el aplicar actividades, técnicas, procesos, metodologías, depende exclusivamente del alcance que tenga el proyecto. No se pueden considerar todas las actividades en un proyecto cuyo tiempo de desarrollo es mínimo, por ejemplo 30 días, o aplicar técnicas como prototipado para la validación de cada uno de los requisitos de los clientes, e incluso construir modelos o diagramas de casos de uso para especificar funcionalidades o el comportamiento de un proyecto o sistema pequeño. No es el mismo caso para un proyecto extenso, aplicar un proceso de Ingeniería de Requisitos eficientemente puede implicarle al desarrollador o al equipo de desarrollo, disminuir los riesgos y maximizar sus beneficios, pues al obtener requisitos de calidad, el proceso de construcción de la solución se torna menos complejo y los costos por reestructuración o cambios en el software son bajos. Además, la documentación generada permitirá ver a detalle, verificar y validar que cada uno de los requisitos cumpla con las especificaciones dadas por el cliente. Aquí también entran las herramientas software, en proyectos muy grandes la gestión de los requisitos no se puede dejar de lado, es necesario automatizar ciertas tareas que permitan manejar los tiempos de desarrollo y sobre todo que permitan la comunicación entre los miembros del equipo desarrollador de la solución, hablando por comunicación, la administración o gestión eficiente de los requisitos. En la tabla 10, se ha desarrollado una clasificación o categorización de cada una de las actividades, técnicas y herramientas que se debe o podrían ser utilizadas en el desarrollo de proyectos, tanto de alto como de bajo nivel. Si bien no es una clasificación basada en estándares o lineamientos propios de la Ingeniería de Software, se ha tratado de plasmar 89

90 las mejores vías o aspectos que tienen que ver con la Ingeniería de Requisitos en la construcción de soluciones eficientes y calidad. Tabla 10. Contrastación de actividades, técnicas y herramientas frente a tipos de proyectos. ACTIVIDADES TÉCNICAS HERRAMIENTAS Viabilidad Captura Análisis Entrevista, JAD, cuestionarios, Brainstorming, casos de uso, prototipado JAD, casos de uso IRqA, Rational Requisite Pro, LEAP SE, Visual Requisite IRqA, Rational Requisite Pro PROYECTOS (NIVEL) BAJO MEDIO ALTO X X X X X X X Borrador de requisitos JAD X X X Negociación X X Descripción de requisitos Rational Requisite X Modelado de requisitos Especificación de requisitos Validación Gestión Validación de sistemas críticos JAD, casos de uso Prototipado, walkthroughs, casos de uso IRqA, Rational Requisite Pro, Visual Requisite IRqA X X IRqA, Rational Requisite Pro IRqA, Rational Requisite Pro, LEAP SE, Visual Requisite X X X X X 90

91 CAPÍTULO VI 6. APLICACIÓN DEL MODELO POHL EN EL GDS DE LA UPSI - SYLLABUS 6.1. ANTECEDENTES DEL GDS El GDS es un área de la Unidad de Proyectos y Sistemas Informáticos, en la cual se desarrolla, administra y mantienen los diferentes sistemas informáticos con los que cuentan la. Su intervención ha permitido solucionar problemas y satisfacer las necesidades de los diferentes departamentos en donde se han implementado dichos sistemas. El GDS administra y mantiene algunas aplicaciones de la UTPL. Dentro de las más importantes están: Syllabus - UTPL: Gestión Académica de la UTPL. Calificación Automática: Proceso de calificación automática de evaluaciones para las dos modalidades, tanto Clásica como A distancia. Sistema de Digitalización: Archivo digital de documentos de la UTPL. DEIAP: Gestión, distribución y control de los docentes que forman parte del proceso de evaluación de la Modalidad A Distancia. Syllabus - Ibarra: Gestión Académica de la Universidad Católica de Ibarra. Gestión de Archivo físico: Nómina - Gestión de nomina de RRHH: Gestión de la nómina de Recursos Humanos de la UTPL. Dentro del grupo, la aplicación a la cual se ha designado una mayor prioridad es el SYLLABUS. El mismo que soporta la Gestión Académica de la UTPL, en el que se incluyen funciones de oferta académica, matriculas, pagos, consultas, notas y otros módulos asociados al sistema. 91

92 Por ser este el proyecto al cual más tiempo y personal dedica el GDS, se lo ha tomado en cuenta para aplicar el Modelo de Pohl de Ingeniería de Requisitos, utilizando la metodología de desarrollo de software Microsoft Solution Framework (MSF), con la cual trabajan en el grupo Quiénes utilizan SYLLABUS? En Syllabus se encuentran tres niveles de usuarios, cada uno de estos con sus respectivas restricciones o niveles de acceso al sistema: Administrativos, secretarias de escuela, recaudadores, coordinadores y secretarias de los centros universitarios, además se incluye personal que trabaja en la administración del sistema y que son miembros del GDS Docentes, que pertenecen a las diferentes escuelas y áreas de la Universidad. Profesionales en formación en las dos modalidades tanto Clásica como A Distancia La metodología La metodología de desarrollo de software implementada en el GDS es Microsoft Solution Framework (MSF) V3. Los roles definidos para esta metodología son: Gerente de Proyecto Gerente de Producto Arquitecto Desarrollador Aseguramiento de Calidad Encargado de la experiencia del Gerente de lanzamiento Experiencia del usuario Gerente de Proyecto Gerente de Producto Arquitecto usuario Gerente de lanzamiento Aseguramiento de calidad Desarrollador Ilustración 40. Roles de MSF. 92

93 Es importante recalcar que para el rol de desarrollador se desglosan tres funciones o responsabilidades: Desarrolladores que realizan tareas de apoyo, como documentación; Desarrolladores encargados del desarrollo de módulos para el sistema; y Desarrolladores que realizan tareas de análisis del sistema. A pesar de que se ha implementado la metodología y distribuido cada uno de los roles con el objetivo de aumentar la productividad y sobre todo mejorar la comunicación en el equipo de desarrollo, el cumplimiento de esta metodología es parcial, puesto que los roles y responsabilidades del equipo de desarrollo se ha desvirtuado. Los proyectos encargados al GDS, las tareas y responsabilidades asignadas a cada uno de los miembros del equipo, fueron creciendo, no así con la infraestructura y recurso humano necesario para cubrir dichas tareas, responsabilidades y proyectos. Esto ocasionó que cada miembro del equipo asumiera más de un rol y, de cierta forma se perdiera el control de una adecuada gestión de requisitos. Los requisitos cuando son comunicados no llegan al responsable, y no sigue su proceso normal. En un principio, los requisitos para SYLLABUS eran gestionados mediante la herramienta Requisite Pro. Como es una herramienta que necesita licenciamiento, con el tiempo se dejó de utilizar por el hecho de no adquirir dicha licencia para su funcionamiento. Por la necesidad de tener un adecuado control y gestión de los requisitos, se volvió a utilizar Requisite Pro, con el objetivo no solo de tener dicho controlar y gestionar de forma adecuado los requisitos, sino tener trazabilidad de los requisitos en el sistema Syllabus. De igual manera para los proyectos que se van a desarrollar o se encuentran ya en construcción PROCESO ACTUAL DE INGENIERÍA DE REQUISITOS EN EL GDS El proceso de requisitos que maneja el GDS para SYLLABUS no cumple con algunas de las tareas recomendadas para la Ingeniería de Requisitos. Si bien se ha establecido puntos de control para el manejo de los requisitos, estos no son administrados por las personas que realmente deberían intervenir. Sin embargo de la información que se puedo 93

94 recabar se conoció que gran parte de los requisitos no pasan por el proceso establecido, sino que son comunicados directamente a cualquiera de los miembros del equipo de desarrollo. Ilustración 41. Proceso General de Obtención de Requisitos del Proyecto Syllabus. Declaración del Proyecto Modalidad Clásica Visión Requisitos Académicos Modalidad Abierta Prototipado del módulos del proyecto Revisión - Sistema financiero: Clásica, Abierta - Sistemas legales: Secretaría General - CEDIB: Entrega material bibliográfico - Vicecanciller - Rector Stakeholders responsables Validación Análisis y Diseño En la ilustración 41 se describe a manera muy general, como es el proceso de requisitos de cambio que se maneja para SYLLABUS. Posteriormente se planteará un proceso similar pero estableciendo roles y responsabilidades de los miembros del equipo de desarrollo basado en MSF Esta información se la obtuvo en conversación con de uno de los miembros del equipo de desarrollo de software del GDS, Ing. Patricio Abad. 94

95 Correcto Análisis comparativo entre las técnicas utilizadas en la Ingeniería de Requisitos frente a tipos de los proyectos GESTIÓN DE REQUISITOS DE CAMBIO STAKEHOL DER Inicio Petición de requerimiento Revisar especificación Aprobado GERENTE PRODUCTO Notificar estado Existe requerimiento? si no Ingresado Ingresar/ Actualizar requerimiento en SAR Autorizar Requerimiento Autorizado SQA incorrecto Registrar observaciones Validar requerimiento no Es correcto? si Estabilizar Cerrado Fin GRENTE DE PROYECTO Asignar Arquitecto Asignado Planificar desarrollo Planificado DESARROLLO ARQUITECTO Analizar Impacto y tiempos Analizado En desarrollo Especificar solución Implementar Estabilizandose Ilustración 42. Diagrama de Gestión de requisitos de cambio de Syllabus. Fuente: Grupo de Desarrollo de Software. 95

96 En la ilustración 42 se muestra como es el proceso de requisitos de cambio del Proyecto Syllabus desde una visión más general. MODALIDAD CLÁSICA Arquitectura Arte y Diseño Electrónica y Telecomunicaciones Geología y Minas Ingeniería Civil Sistemas Informáticos solicita Secretaría del Área Técnica comunica SYLLABUS Comunicación Social Derecho Psicología Inglés Admin. Empresas Admin. En Banca y Finanza Admin. En Hotelería y Turismo Contabilidad y Auditoría Economía Asistencia Gerencial y Relaciones Públicas Secretaría del Área Socio-Humanística Secretaría del Área Administrativa DIRECCIÓN GENERAL ACADÉMICA inf_req Equipo de Desarrollo del GDS cambios_según_requisitos Gerente del Proyecto Gerente del Producto Analista Desarrollador Aseguramiento de la calidad Experiencia del Usuario Gerente de Lanzamiento * Cualquiera de los miembros del equipo puede recibir el requisito. Bioquímica y Farmacia Gestión Ambiental Industrias Agropecuarias Ingeniería Agropecuaria Ingeniería Química Medicina Biología Secretaría del Área Biológica Informa_req Informan_req Todo los departamentos relacionados a la Modalidad Abierta solicitan GESTIÓN DE PROCESOS MODALIDAD A DISTANCIA CEDIB ENTORNO VIRTUAL DE APRENDIZAJE CONTABILIDAD SISTEMA DE DIGITALIZACIÓN OTROS SISTEMAS Ilustración 43. Proceso de Requisitos de cambio desde una visión general Modelo obtenido a partir en conversación con de uno de los miembros del equipo de desarrollo de software del GDS, Ing. Diana Cuenca. 96

97 6.3. APLICACIÓN DEL MODELO DE POHL Y MSF EN EL GDS (SYLLABUS) MODELO DE POHL Y SUS FASES Este modelo de Ingeniería de Requisitos es un modelo iterativo, en el cual el ingeniero de requisitos no es el único participante y responsable del proceso de Ingeniería de Requisitos de un proyecto, sin o también, todos aquellos los que conforman el equipo de desarrollo en sus diferentes roles, definidos según la metodología de desarrollo de software. El modelo consta de cuatro actividades o etapas: Captura: Recolección de los requisitos o necesidades del cliente y determinar el alcance del sistema o proyecto. Negociación: Discutir y dar criterios respecto a los requisitos obtenidos, con el fin de determinar las funciones y las restricciones que tendrá el sistema, sino se cumple con las expectativas, se volverá a la etapa de captura. Especificación y documentación: Documento de especificación de requisitos, se deben incluir y definir solamente aquellos requisitos completos y que son verificables. Validación y verificación: Confirmar los requisitos y asegurarse de que realmente cumplen con los objetivos y las necesidades del cliente. Con la aplicación de este modelo se trata de obtener borradores de requisitos o demos en cada iteración, esto con el fin de que en cualquiera de los proyectos que se esté desarrollando, los requisitos se vayan refinando o a su vez obteniendo nuevos requisitos o necesidades. Los nuevos requisitos pueden aparecer, ya sea por pedido de los clientes o por la necesidad de integrar nuevas funcionalidades al sistema, según lo estime el ingeniero de requisitos o el equipo de desarrollo del software. 97

98 MODELO DE POHL VS. MSF Por qué aplicar MSF al Modelo de Pohl? Por lo general cuando se va a desarrollar un proyecto de alto nivel se hace uso de las metodologías de desarrollo de software para lograr obtener el máximo nivel de satisfacción tanto para el equipo de desarrollo como para el cliente. En las metodologías de desarrollo una de las principales etapas de la construcción del software es la fase de requisitos, si bien se realiza algunas tareas referentes a los requisitos, algunas se dejan de lado, como lo es el análisis, especificación, validación y verificación de requisitos, entre otras actividades dependiendo del modelo de requisitos empleado para el proyecto. El Modelo de Pohl permite integrar la metodología de desarrollo de software MSF al proceso de Ingeniería de Requisitos. No en sus etapas de desarrollo, sino en la participación de los miembros del equipo de desarrollo, en sus distintos roles y responsabilidades, formando parte del proceso de Ingeniería de Requisitos de los proyectos. En el caso de MSF, los roles: Gerente de Proyecto, Gerente de Producto, Analista- Desarrollador, Desarrollador, Aseguramiento de calidad, Encargado de la experiencia del usuario, Gerente de lanzamiento; pueden ser partícipes de la fase de requisitos. Lo que se logra es, obtener requisitos fiables, sin ambigüedades, acordes a las necesidades de los clientes y del proyecto, ayudándose de una buena organización del equipo de desarrollo y su productividad. Las distintas perspectivas y opiniones de los miembros del equipo de desarrollo, ayudará a mejorar el nivel de satisfacción de los usuarios finales y la calidad del producto MSF posee 4 fases: Planeación, Construcción, Implementación y Operación. En la fase de planeación se realiza el proceso de Ingeniería de Requisitos. A través del Modelo de Pohl, al ser un modelo iterativo al igual que MSF, se puede llegar a obtener o identificar nuevos requisitos en el resto de fases de desarrollo, o redefinir aquellos ya establecidos. 98

99 En cada etapa de MSF se obtiene demos funcionales de un producto, lo mismo ocurre con el Modelo de Pohl. Si bien no la obtención de demos, sino borradores de requisitos que pueden ser utilizados en cada fase del proceso de requisitos o de construcción del software. Al final, se logrará obtener un producto de calidad y la satisfacción de los usuarios finales. Gerente de Producto Captura Negociación Gerente de Producto Gerente de Proyecto Gerente de Producto Validación y Verificación Especificación y Documentación Desarrollador Aseguramiento de calidad Analista Ilustración 44. Modelo de Pohl aplicando roles de MSF. De esta forma, los participantes que deberían intervenir en cada una de las etapas del Modelo de Pohl y, basados en la metodología de desarrollo de software MSF son: Ventajas - Disciplina y organización del trabajo. - Mejora la comunicación del ingeniero de requisitos con el equipo de desarrollo. - Requisitos fiables, sin ambigüedades y de alta calidad. - Mejora la calidad del producto. - Manejo de plantillas para documentación de requisitos. - Planificación de cada una de las etapas del proceso de requisitos. 99

100 Desventajas - El avance del proyecto se podría ver afectado por cuanto se tiene la intervención de los miembros del equipo de desarrollo de software basado en MSF. - En las fases del proceso de desarrollo de software de MSF se solicita mucha documentación, puede ocurrir lo mismo con las etapas del modelo de Pohl APLICACIÓN La metodología de desarrollo de software utiliza en el proyecto SYLLABUS es Microsoft Solution Framework (MSF) V3. De esta metodología de desarrollo se tomará en cuenta los roles y responsabilidades establecidos para aplicarlos al modelo de requisitos de Pohl. Con esto se pretende establecer recomendaciones y dar ciertas pautas, que le permita al equipo de desarrollo de software realizar un proceso de requisitos adecuado o realizar algunas de las tareas que el modelo sugiere. Además, les permitirá conocer el origen de los requisitos y cuáles deberían ser los responsables o participantes del proceso. Los roles definidos para la metodología de desarrollo de software MSF: Gerente de Proyecto, Gerente de Producto, Arquitecto, Desarrollador, Aseguramiento de Calidad, Encargado de la experiencia del usuario, Gerente de Lanzamiento; formarán parte del modelo de Pohl en sus distintas etapas. A continuación se muestra la distribución de los roles de la metodología de desarrollo MSF para cada una de las etapas del Modelo de Pohl, para el proceso de requisitos del GDS: 100

101 ACTIVIDADES Captura Negociación Especificación-Documentación Validación-Verificación Tabla 11. Roles de MSF frente a actividades del Modelo de Pohl. ROLES MSF Gerente de producto Gerente de producto Gerente de proyecto Analista-Desarrollador Aseguramiento de calidad Gerente de producto La documentación de MSF que se recomienda en cada una de las etapas del proceso de requisitos recomendado, son una base para la elaboración de documentos acordes al proceso de requisitos. Cada uno de estos documentos debe ser modificado, solamente se debe tomar en cuenta ciertos aspectos referentes a los requisitos o aquellos que el ingeniero de requisitos junto con los miembros del equipo de desarrollo estimen necesarios. Antes de iniciar con el proceso de requisitos, como primer paso, se debe utilizar Acta de constitución recomendada por MSF, en este documento se deberá dejar sentado cada uno de los roles de los miembros del equipo, en base a la metodología MSF y al Modelo de Pohl Captura Quién lo debe realizar? La captura de los requisitos es muy importante para el desarrollo y/o administración de los requisitos de un sistema ya elaborado, en este caso Syllabus. Quienes deben realizar esta actividad o etapa de ingeniería de requisitos y basada en MSF deberían ser: - Gerente de Producto Ellos, además del ingeniero de requisitos, deben ser los encargados de capturar o de receptar cada uno de los requisitos. En base a su función y responsabilidad dentro del 101

102 equipo de desarrollo y, por su relación directa con el cliente, que pueden identificar verdaderamente cuál es el requisito o a su vez establecer una prioridad para aquellos redefinidos, y de esta manera satisfacer las necesidades de los usuarios. Qué documentos se deben utilizar? Para esta etapa se debe utiliza el siguiente documento MSF. - Documento de visión. En el documento de visión se describirá cada uno de los requisitos obtenidos según su tipo: Funcional, de Negocio, Operacionales, de Usuario o de Sistema. Se puede elaborar un documento en el cual consten todos los requisitos capturados por el Product Management, de tal forma que tanto este, como el equipo de desarrollo tengan un respaldo de la información capturada. Es necesario que dicha información o los requisitos que sean plasmados en este tipo de documento sean descritos claramente, con sus características o atributos bien definidos, sin ambigüedades, errores o inconsistencias. Es importante que los documentos generados sean compartidos con todos los miembros del equipo de desarrollo, estén o no incluidos en esta etapa. Una de las características por las que se aplica MSF al Modelo de Pohl, es la de mejorar la comunicación entre el equipo Negociación Quién lo debe realizar? La negociación permite al equipo de desarrollo o aquellos miembros que intervienen en esta etapa establecer las funciones y restricciones que puede tener SYLLABUS, en base 102

103 a los criterios de quienes intervienen. De no llegar a satisfacer las necesidades del sistema y en especial del usuario, se debe volver hacer la etapa de captura. Los miembros del equipo de desarrollo que debería participar, además del ingeniero de requisitos son: - Gerente de Producto - Gerente de Proyecto Estos miembros del equipo de desarrollo, deben dar sus criterios sustentándose en el proyecto, con el único fin de establecer requisitos verdaderamente útiles para el sistema. Requisitos que deberán ser especificados y documentados, para luego ser validados. Además, deben fijar parámetros de negociación como: negociación de requisitos por tipo, establecer un nivel de prioridad para cada requisito; con el fin desarrollar una etapa de negociación satisfactoria para el equipo de desarrollo, el proyecto SYLLABUS y sus usurarios. Qué documentos se deben utilizar? No es necesaria la utilización de documentación MSF en esta etapa. Se puede elaborar un documento o una plantilla en los cuales consten los aportes, criterios o resultados de la negociación de cada requisito. 103

104 Tabla 12. Plantilla de negociación de requisitos recomendada. NOMBRE_PROYECTO> RESPONSABLES DE LA ETAPA DE NEGOCIACIÓN: ACTA DE NEGOCIACIÓN DE REQUISITOS <NOMBRE>,<ROLES_MSF> - <NOMBRE>, Gerente de Proyecto - <NOMBRE>, Gerente de Producto - <NOMBRE>, Stakeholders <NÚMERO_ACTA> <CÓDIGO> REQUISITOS DESCRIPCIÓN APORTES Y CRITERIOS PARA LOS REQUISITOS RESULTADO DE NEGOCIACIÓN FECHA DE NEGOCIACIÓN FECHA TENTATIVA PARA APLICAR EL REQUISITO Código de Requisitos < REQ1_ NOM> <DESCRIPCIÓN_REQ1> <APORTES_CRITERIOS> Aportes y criterios recogidos de los miembros MSF. <ESTADO_REQ> <Activo> <En cola de requisitos> <Eliminado> <Modificado> <REDEFINIR_REQ> <VIABILIDAD> <FECHA_NEG> <FECHA_T> PRIORIDAD <RANGO DE 1-10> FIRMA Gerente de Proyecto FIRMA Gerente de Producto FIRMA Stakeholders En la presente plantilla de ejemplo se quiere rescatar las opiniones o criterios de cada uno de los miembros del equipo de desarrollo MSF, que forman parte de la etapa de negociación. Se establece para ello el código de cada uno de los requisitos <REQ1_NOM>, una pequeña descripción de dicho requisitos, se deberá mencionar los módulos que afecta el requisitos. Además, se recoge los criterios dados por los participantes de la negociación, con el fin de conocer cuáles fueron las pautas que permitieron establecer u obtener los resultados de la negociación. 104

105 En el resultado de la negociación se especificará el estado del requisito tratado <ESTADO_REQ>, y de ser necesario, en base a los criterios dados por los participantes de la etapa de negociación, se desarrollará una descripción de aquellos requisitos que necesitan o se ha creído conveniente redefinirlos. Dicha descripción deberá definir si el requisito es una funcionalidad del sistema o una restricción. Se debe marcar la fecha en la que se realiza la negociación <FECHA_NEG>. Además, determinar una fecha estimada <FECHA_T>, para la cual el requisito debe ser ejecutado, esta fecha será establecida por los responsables de la etapa de captura. El requisito debe pasar el resto de etapas del modelo de requisitos, al ser este un modelo iterativo, si el requisito no cumple con los objetivos planteados para el sistema o tiene errores o inconsistencias, la fecha se modificará conforme sea analizado en las demás etapas del modelo e iteraciones realizadas. Se deberá establecer una prioridad para el requisito tratado <PRIORIDAD>, de tal forma que se pueda prestar atención a aquellos requisitos que tiene mayor relevancia en el proyecto. El objetivo de este proceso de negociación es que se logre obtener requisitos claros y que permitan establecer a través de las tres negociaciones las funcionalidades y restricciones del sistema, o a su vez, redefinir aquellos requisitos que tengan inconsistencias o errores. Cada requisito debe llegar al final del proceso, es decir, al Development. Este es quién debe negociar y junto con el Analyst determinar si el requisito es viable o no Especificación Quién lo debe realizar? Esta etapa es esencial en la Ingeniería de Requisitos y en la aplicación del Modelo de Pohl según MSF, pues de esta manera se puede tener a manera de respaldo, en un documento de especificación de requisitos, aquellos requisitos que fueron tomados por los miembros del equipo de desarrollo y que implicaron cambios en SYLLABUS. Quienes deberían participar en esta etapa son: 105

106 - Analyst Qué documentos se deben utilizar? Los documentos que deben utilizar los miembros del equipo de desarrollo que participan en esta etapa están basados en el tipo de requisito, estos son: - Especificación de requisitos funcionales - Especificación de requisitos del negocio - Especificación de requisitos operacionales - Especificación de requisitos del sistema - Especificación de requisitos de usuario Cada uno de los documentos debe ser compartido con el resto de miembro del equipo de desarrollo, con el objetivo de que conozcan cada uno de los requisitos tratados y los cambios efectuados en SYLLABUS. De tal manera que no se hagan cambios inesperadamente y redundantes sobre el sistema Validación y verificación Quién lo debe realizar? Es importante que los requisitos sean validados y verificados por un equipo eficiente. En esta etapa se aceptan aquellos requisitos que satisfacen las necesidades del equipo como desarrolladores y administradores del sistema, de los usuarios finales, y de las necesidades del sistema en cuanto a su funcionalidad. Quien debería validar y verificar los requisitos es: - Aseguramiento de calidad - Analista 106

107 Qué documentos se deben utilizar? No existe un documento de validación de requisitos. Lo que se puede utilizar en esta etapa son los mismos documentos de la especificación de requisitos, pues en estos documentos se hará constar los requisitos ya validados y verificados, en sus distintos tipos. Los documentos que se deben utilizar son: - Especificación de requisitos funcionales - Especificación de requisitos del negocio - Especificación de requisitos operacionales - Especificación de requisitos del sistema - Especificación de requisitos de usuario PROCESO DE REQUISITOS PARA EL GDS (SYLLABUS) APLICANDO MSF Y EL MODELO DE REQUISITOS DE POHL A continuación se muestra una aplicabilidad de un proceso de requisitos de cambio para el GDS (SYLLABUS). El proceso desarrollado está basado en El Modelo de Pohl de requisitos y en la metodología de desarrollo de software MSF que se aplica en el GDS. 107

108 QUALITY ANSURANCE GRENTE DE PROYECTO GERENTE PRODUCTO STAKEH OLDER Análisis comparativo entre las técnicas utilizadas en la Ingeniería de Requisitos frente a tipos de los proyectos GESTIÓN DE REQUISITOS DE CAMBIO - PROPUESTO Inicio Petición de requerimiento Notificar estado Existe requerimient o? no si Ingresado Ingresar/Actualizar requerimiento en SAR si Establecer funciones y restricciones Autorizar Requerimiento Autorizado DESARROLLO ANALISTA Revisión requerimiento Existe inconsistencias en req.? no Analizar Impacto y tiempos Analizado En desarrollo Especificar solución Implementar Estabilizandose Planificado Planificar desarrollo Aprobado Revisar especificación incorrecto Registrar observaciones no Validar requerimiento Es correcto? Correcto si Estabilizar Cerrado Fin Ilustración 45. Diagrama de Gestión de requisitos de cambio de Syllabus - Propuesto. 108

109 MODALIDAD CLÁSICA Arquitectura Arte y Diseño Electrónica y Telecomunicaciones Geología y Minas Ingeniería Civil Sistemas Informáticos Comunicación Social Derecho Psicología Inglés Admin. Empresas Admin. En Banca y Finanza Admin. En Hotelería y Turismo Contabilidad y Auditoría Economía Asistencia Gerencial y Relaciones Públicas Bioquímica y Farmacia Gestión Ambiental Industrias Agropecuarias Ingeniería Agropecuaria Ingeniería Química Medicina Biología solicita Secretaría del Área Técnica Secretaría del Área Socio-Humanística Secretaría del Área Administrativa Secretaría del Área Biológica comunica CAPTURA DIRECCIÓN GENERAL ACADÉMICA Product Management GESTIÓN DE PROCESOS Informan_req solicitan_req pasa_req pasa_req pasa_req NEGOCIACIÓN Product Management, Project Management, Analyst, Development Project Management, Analyst Quality Ansurance cambios_según_requisitos_validados SYLLABUS ESPECIFICACIÓN Y DOCUMENTACIÓN VALIDACIÓN Y VERIFICACIÓN * Los cambios en el sistemas pueden ser realizados por el Release Management. Todo los departamentos relacionados a la Modalidad Abierta MODALIDAD A DISTANCIA solicitan_req CEDIB ENTORNO VIRTUAL DE APRENDIZAJE CONTABILIDAD SISTEMA DE DIGITALIZACIÓN OTROS SISTEMAS Ilustración 46. Proceso General de Requisitos recomendado para el GDS (SYLLABUS). En el presente proceso se sigue manteniendo algunos PUNTOS DE CONTROL del proceso actual de requisitos que maneja el GDS. Cabe destacar que dicho proceso recomendado es iterativo, por lo tanto, cada uno de los requisitos que entre al proceso debe pasar por todas las etapas hasta ser aceptado o validado. 109

110 En la modalidad clásica, para cada una de las áreas: Técnica, Administrativa, Socio- Humanística y Biológica; se cuenta con una secretaría de área, este punto de control es el encargado de receptar todos los requisitos de las diferentes secretarias o departamentos relacionados a dicha área. Cada secretaría de área debe efectuar un proceso de filtración de requisitos, esto con el fin de evitar que haya requisitos redundantes, para agilizar el proceso de requisitos y obtener una solución en tiempos relativamente mínimos. Esta información debe ser pasada a Dirección General Académica (DGA). Para la modalidad a distancia, el proceso de requisitos se efectúa de manera similar a la Clásica. El punto de control Gestión de Procesos (GP) será el encargado de receptar todos los requisitos solicitados por los departamentos que conforman esta modalidad. De igual manera, deben filtrar los requisitos y evitar redundancias en la información obtenida. Para las modalidades de estudio tanto clásica como a distancia, Dirección General Académica y Gestión de Proceso respectivamente, son los encargados de la etapa de Captura de requisitos, pues ellos cumplen la función de Product Management, y como tales deben participar en la etapa de negociación de requisitos según lo planteado en el modelo. Para los sistemas relacionados o que forman parte del Sistema de Gestión Académica (SYLLABUS): CEDIB, EVA, CONTABILIDAD, DIGITALIZACIÓN; no existen puntos de control, los requisitos obtenidos serán comunicados o pasados a la etapa de Captura directamente por el responsable de dichos sistemas o sus usuarios. En la fase de captura, el Product Management debe volver a revisar los requisitos o información que se les trasmitió, con el objetivo de lograr obtener requisitos limpios, sin redundancias. El proceso de filtración de los requisitos en los puntos de control podría tener errores o inconsistencias. En esta fase se puede utilizar la plantilla de captura de requisitos recomendada (Tabla 12) para describir o especificar cada uno de los requisitos capturados. O en su defecto se puede utilizar el Documento de Visión de MSF como documento base, en este se describirá los distintos tipos de requisitos obtenidos: funcionales, del negocio, 110

111 operacionales, del sistema o de usuario. Además se debe elaborar o modificar el Acta de Constitución del proyecto, en la cual se determinarán los roles y responsabilidades de quiénes conformarán los equipos para las diferentes etapas del proceso de requisitos. El Acta debe ser desarrollada antes de la fase de Captura. Tabla 13. Plantilla de captura de requisitos recomendada. NOMBRE_PROYECTO> RESPONSABLES DE LA ETAPA DE NEGOCIACIÓN: PLANTILLA DE CAPTURA DE REQUISITOS <NOMBRE>,<ROLES_MSF> <NOMBRE, Gerente de Producto <NÚMERO_PLANTILLA> <CÓDIGO> REQUISITOS DEFINICIÓN DESCRIPCIÓN ORIGEN FECHA CAPTURA FECHA REQUERIDA Código de requisitos < REQ1_ NOM> <DEFINICIÓN_REQ1_NOM> <DESCRIPCIÓN> <MODULOS QUE AFECTA> <SECRETARÍA_TÉCNICA> <SECRETARÍA_ADMIN> <FECHA_CAP> <FECHA_REQ> PRIORIDAD <RANGO DE 1-10> FIRMA Product Management El Gerente de Producto deberá elaborar una plantilla por cada uno de los requisitos capturados. Al final de esta etapa, se podrá obtener un descripción o especificación clara de cada uno de los requisitos obtenidos. Es importante que todos los documentos desarrollados en cada fase sean transmitidos o comunicados al resto del equipo de desarrollo, en las diferentes fases del proceso de requisitos. Con el objetivo de los participantes de las fases del proceso de requisitos 111

112 conozcan el tipo de requisitos o la información obtenida en cada fase, de tal manera que tengan una idea de lo que al final del proceso se quiere obtener. Luego de la revisión y la elaboración de la documentación requerida por MSF, los documentos deben ser pasados a la siguiente fase de requisitos, la Negociación. En la fase de negociación, los miembros del equipo de desarrollo: Product Management, Project Management, Analyst y Development; deberán revisar la documentación proporcionada por el equipo que realizó la captura de requisitos y, establecer las funcionalidades del sistema y sus restricciones. Los criterios dados por cada uno de los participantes en esta fase son esenciales, pues de ellos se puede llegar a obtener o redefinir algunos de los requisitos tratados, dando como resultado requisitos fiables, sin inconsistencia, sin ambigüedades, al mismo tiempo que les permitan establecer si, dichos requisitos son una funcionalidad del sistema o una restricción. Si en esta etapa se encuentra algún tipo de error o inconsistencia en los requisitos capturados, se deberá volver a la etapa de Captura, es responsabilidad del Product Management transmitir requisitos bien definidos y en lo posible viables. No existe documentación de MSF que se pueda utilizar en la fase de negociación del proceso de requisitos aplicado. Pero, se puede utilizar como ejemplo base la plantilla propuesta (tabla 13) para la negociación de los requisitos. 112

113 Tabla 14. Plantilla de negociación de requisitos recomendada. NOMBRE_PROYECTO> RESPONSABLES DE LA ETAPA DE NEGOCIACIÓN: ACTA DE NEGOCIACIÓN DE REQUISITOS <NOMBRE>,<ROLES_MSF> - <NOMBRE>, Gerente de Proyecto - <NOMBRE>, Gerente de Producto - <NOMBRE>, Stakeholders <NÚMERO_ACTA> <CÓDIGO> REQUISITOS DESCRIPCIÓN APORTES Y CRITERIOS PARA LOS REQUISITOS RESULTADO DE NEGOCIACIÓN FECHA DE NEGOCIACIÓN FECHA TENTATIVA PARA APLICAR EL REQUISITO Código de Requisitos < REQ1_ NOM> <DESCRIPCIÓN_REQ1> <APORTES_CRITERIOS> Aportes y criterios recogidos de los miembros MSF. <ESTADO_REQ> <Activo> <En cola de requisitos> <Eliminado> <Modificado> <REDEFINIR_REQ> <VIABILIDAD> <FECHA_NEG> <FECHA_T> PRIORIDAD <RANGO DE 1-10> FIRMA Gerente de Proyecto FIRMA Gerente de Producto FIRMA Stakeholders Al final de la negociación se debe transmitir todos aquellos requisitos viables que serán especificados y documentados de manera clara y completa. De esto dependerá que cada uno de los requisitos pueda ser validado y verificado de manera correcta. Cada uno de los requisitos negociados debe pasar a la fase de Especificación y documentación. En esta fase cada uno de los requisitos negociados debe ser definido de manera completa, precisa y verificable. Se puede utilizar una plantilla de especificación como la recomendada (tabla 14) o documentación basada en MSF. 113

114 NOMBRE_PROYECTO> RESPONSABLES DE LA ETAPA DE NEGOCIACIÓN: Tabla 15. Plantilla de especificación de requisitos recomendada. <NÚMERO_PLANTILLA> <CÓDIGO> PLANTILLA DE ESPECIFICACIÓN DE REQUISITOS <NOMBRE>, <ROLES_MSF> - <NOMBRE>, Gerente de Proyecto - <NOMBRE>, Analista-Desarrollador REQUISITOS DEFINICIÓN ATRIBUTOS ORIGEN FECHA DE ESPECIFICACIÓN Código de Requisitos < REQ1_ NOM> <DEF_REQ1> <ATRIB1> <ATRIB2> <SECRE_TÉCN> <SECRE_ADMIN> <FECHA_ESP> FECHA TENTATIVA PARA APLICAR EL REQUISITO TIPO DE REQUISITO <FECHA_T> <FUNCIONAL> <INTERFAZ> <NEGOCIO> <USUARIO> <SISTEMA> PRIORIDAD <RANGO DE 1-10> FIRMA Gerente de Proyecto FIRMA Analista-Desarrollador El Gerente de Proyecto y Analista-Desarrollador, deberán especificar únicamente aquellos requisitos que pasaron por la fase de negociación y que serán motivo de validación y verificación en la siguiente fase del proceso de requisitos. En la fase de Validación y Verificación se toman en cuenta solamente aquellos requisitos que fueron especificados en la fase anterior del proceso de requisitos. Quality Ansurance debe comprobar que los requisitos fueron definidos en base a estándares establecidos por el ingeniero de requisitos, el grupo de desarrollo de software o los miembros que participan del proceso de requisitos. Además, deberá comprobar que cada 114

115 uno de los requisitos se ajusta a las necesidades de los usuarios finales, esta comprobación la pueden realizar utilizando técnicas de validación y verificación formales o informales. Los requisitos que sean validados y verificados deben volver a ser especificados y documentados según los diferentes tipos de requisitos. Si existen requisitos que no pasen la fase de validación y verificación por haber encontrado inconsistencias o errores, estos deberán volver a la fase de especificación y documentación, o en su defecto, a la negociación de requisitos. Tabla 16. Plantilla para la validación y verificación de requisitos recomendada. NOMBRE_PROYECTO> RESPONSABLES DE LA ETAPA DE NEGOCIACIÓN: <NÚMERO_PLANTILLA> <CÓDIGO> PLANTILLA DE VALIDACIÓN y VERIFICACIÓN DE REQUISITOS <NOMBRE>,<ROLES_MSF> - <NOMBRE>, Aseguramiento de calidad - <NOMBRE>, Gerente de Producto REQUISITOS DEFINICIÓN FECHA DE VALIDACIÓN VALIDACIÓN FECHA PARA EJECUTAR EL REQUISITO <NOM_REQ1> <DEF_REQ1> <FECHA_VAL> <COMENTARIOS ACERCA DE LA VALIDACIÓN> Se acepta o niega el requisito? <FECHA DE EJECUCIÓN EN CASO DE PASAR LA VALIDACIÓN> PRIORIDAD <RANGO DE 1-10> FIRMA Quality Ansurance Posteriormente al proceso de requisitos, luego de la validación y verificación de cada uno de los requisitos, estos pueden ser comunicados al Gerente de lanzamiento para que efectúe los cambios necesarios en el Sistema de Gestión Académica (SYLLABUS). 115

116 7. CONCLUSIONES Al realizar un estudio sobre el manejo de los requisitos en las diferentes empresas encuestadas que desarrollan software tanto local como nacional, se constató que no tienen un proceso formal de requisitos para el desarrollo de sus productos o proyectos. Se maneja en algunos casos de forma manual mediante el uso de actas de reuniones en las cuales se plasman los requisitos, en otros casos, los requisitos únicamente son tratados en reuniones y no se tiene un respaldo de esto documentado. La importancia de los requisitos es gradual, es decir, a medida que al alcance y el número de recursos de los proyectos crece, los requisitos van tomando un nivel de importancia mucho mayor. Para la etapa de captura de requisitos, independientemente de si se utilice o no un proceso de Ingeniería de Requisitos, la Entrevistas, Checklist, Tormenta de ideas y Casos de Uso son las técnicas más utilizadas en la captura de requisitos por parte de los profesionales del software, recalcando que en proyectos de nivel bajo y medio, hay mayor énfasis en utilizar la tormenta de ideas. La entrevista tiene mayor relevancia ante proyectos de alto nivel. Las técnicas Walkthroughs, Prototipado y Casos de Uso son las más utilizadas en el análisis, especificación y validación de requisitos. Para los proyectos de nivel bajo y medio Walkthroughs, Casos de Uso y Prototipado son las más utilizadas por los profesionales constructores Para proyectos de nivel alto los casos de uso se han convertido en una técnica fundamental para el análisis, especificación y validación de cada uno de los requisitos de un proyecto, dicha técnica es la más utilizada en este tipo de proyectos. Utilizar herramientas software para la gestión o administración de requisitos en el desarrollo de los proyectos, especialmente en los de mediano y alto nivel, se logra: trazabilidad, coherencia en los requisitos, comunicación del equipo de desarrollo, no 116

117 se pierde información, se da seguimiento a los requisitos y se obtiene un alto nivel de calidad tanto en los requisitos capturados como en el proyecto. Realizar un proceso de requisitos no adecuado, implica obtener un mayor número de errores, mayor costo y tiempo en el desarrollo de las siguientes etapas de construcción de un proyecto. 117

118 8. RECOMENDACIONES Que los ingenieros de requisitos, un desarrollador o cualquier equipo que construya de software, utilice de un proceso de requisitos para el desarrollo de los proyectos, esto ayudará a dichos participantes, a obtener requisitos limpios, sin ambigüedades, completos y sobre todo viables. Al final obtendrán un producto o proyecto de calidad con requisitos de calidad. Utilizar herramientas software de gestión de requisitos, ayudarán al ingeniero de requisitos o al equipo de desarrollo a no perder la información y lo más importante obtener trazabilidad de los requisitos a lo largo del ciclo de vida del software, dando la posibilidad de que el equipo de desarrollo se mantenga al tanto de los cambios realizados en los requisitos. Mejorando de esta manera la comunicación entre los miembros del equipo de desarrollo, agilidad en los procesos que involucren requisitos, disminución de errores o inconsistencias en los requisitos y la calidad del producto o del software. Que se desarrolle o utilice algún tipo de documentación de requisitos como plantillas, actas de reuniones, etc., de esta manera el ingeniero de requisitos o el equipo de desarrollo tendrán una forma de respaldo ante los cambios realizados en los sistemas que administran y ante cualquier reclamo que se pueda originar de parte de los clientes o de los mismos miembros del equipo de desarrollo. El proceso no debe terminar en la captura, negociación o especificación. El proceso terminará cuando cada uno de los requisitos sea validado y verificado por el responsable de esta etapa, en el caso específico del Modelo de Pohl basado en MSF, lo deberá realizar Quality Ansurance (QA). En el desarrollo de todo proyecto de software es necesario dar mayor énfasis en el proceso de requisitos, de tal forma que se pueda reducir tanto costos, como tiempo de desarrollo de dichos proyectos. Realizar un proceso adecuado de requisitos, implicará tener una cantidad baja de errores en las siguientes de etapas de desarrollo de un proyecto. 118

119 9. BIBLIOGRAFÍA PRESSMAN, Roger. (2005). Ingeniería del Software, un enfoque práctico. Editorial McGraw-Hill. Sexta Edición. ROBERTSON, Z., ROBERTSON, J. (2006). Mastering the Requirements Process. Editorial Addison-Wesley. Sexta Edición. MÁRQUEZ, José Manuel. (2005). Ingeniería del Software. Departamento de Informática. Universidad de Valladolid. Disponible en: GÁLVEZ, Jorge Alberto. (2006). Ingeniería de Requerimientos. Universidad Tecnológica de Pereira. Ensayo sobre Ingeniería de Requerimientos. OLIVEROS, Alejandro. (2007). Gestión de Requerimientos. Facultad de Informática, Universidad Nacional de La Plata. Maestría en Ingeniería de Software. Documento digital. IEEE. (2007). Introducción a la Ingeniería de Requisitos. Ingeniería de Software (3 I.T.I.S., I.T.I.G.). Documento digital. BOHEM, Barry. (2007). Blog Competencias del ICI en la toma de requisitos. Disponible en: GARCÍA, Jesús. Introducción a la Ingeniería de requisitos. Ingeniería de Software. Escuela Superior Politécnica de Albacete. España. Disponible en: BERNÁRDEZ, Beatriz. (2001). Modelo aplicado a la calidad de la ingeniería de requisitos. Universidad de Sevilla. Documento digital. GUTIÉRREZ, Claudio. Departamento de Sistemas de Información. Universidad de Chile. Artículo sobre UML. Disponible en: ESCALONA, M.J., GONZÁLEZ, J. Metodología y técnicas en Proyectos software para la web. Metodologías para la Ingeniería Web. Programa de Doctorado Tecnología e Ingeniería del Software. Universidad de Sevilla. Documento digital. ESCALONA, M.J., KOCH, N. (2002). Ingeniería de Requisitos en aplicaciones para la web. Universidad de Sevilla (ESCALONA) - España, Universidad de Munich (KOCH) - Alemania. Documento Digital. 119

120 GUTIÉRREZ, Claudio. Departamento de Sistemas de Información. Universidad de Chile. Artículo sobre UML. GIANDIN, R., PONS, C. Relación entre casos de uso y UML. Universidad Nacional de la Plata. Disponible en: LETELIER, Patricio. (2007). Introducción a la Ingeniería de Requisitos. Departamento de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia. Documento digital. BERNÁRDEZ, B., DURÁN, A. (2000). Metodología para la Elicitación de Requisitos en Sistemas Software. Departamento de Lenguas y Sistemas Informáticos. Universidad de Sevilla. Informe Técnico LSI GIANDIN, R., PONS, C. (2008). Relación entre casos de uso y UML. Universidad Nacional de la Plata. Revista Colombiana de Computación. Volumen FERRÉ, Xavier. Marco de Integración de la Usabilidad en el Proceso de Desarrollo de Software. Facultad de Informática. Universidad Politécnica de Madrid. Resultados de Tesis Doctoral. Disponible en: FERNÁNDEZ, Caro. (2008). Introducción a la Ingeniería de Requisitos con IRqA. TCP Sistemas e Ingeniería. España. Documento digital. MELLADO, Daniel. (2006). Introducción a la Ingeniería de Requisitos. Instituto Nacional de la Seguridad Nacional. Profesor Asociado a la Universidad de Castilla La Mancha. España. Documento digital. SOLARTE, Mario. (2007). Aproximación metodológica para la ingeniería de requisitos de sistemas telemáticos. Grupo de Ingeniería Telemática. Universidad del Cauca. Documento digital. DEL ÁGUILA CANO, Isabel María. (2005). Marco Metodológico de la Ingeniería de Requisitos. Ingeniería de datos, del conocimiento y del software. Universidad de Almería. Documento digital. 120

121 GARCÍA, L., FERNÁNDEZ, L. Procedimiento para el desarrollo del proceso de ingeniería de requisitos en un proyecto software. Departamento de Sistemas y Computación Instituto Tecnológico de Morelia. México. Documento digital. Departamento de Lenguajes y Sistemas Informáticos. Introducción a la Ingeniería de Software. Universidad de Sevilla. Disponible en: 121

122 10. ANEXOS Anexo 1. Encuesta sobre Ingeniería de Requisitos, sus técnicas, modelos y herramientas software para gestión o administración de los requisitos. UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA ESCUELA DE CIENCIAS DE LA COMPUTACIÓN TEMA: "Análisis comparativo entre las técnicas utilizadas en la Ingeniería de Requerimientos, permitiendo evaluar dichas técnicas frente a las características de los proyectos " NOTA: Por motivo del desarrollo de un proyecto de investigación de la Universidad Técnica Particular de Loja, previo a la obtención del Título de Ingeniero en Sistemas Informáticos y Computación, solicito muy comedidamente de respuesta a las siguientes preguntas, con las cuáles se realizará un estudio y evaluación sobre el tema mencionado. Por favor lea detenidamente las preguntas, marque con una X o sombree con algún color la casilla que usted estime correcta. 1. En qué tipos de proyectos ha participado usted? Especifique un nivel. * El tipo de proyecto se refiere al alcance de este. Ej. Tiempo corto, pocos requisitos, mínimo de recursos, podría considerarse un proyecto de nivel bajo. * Termina la a. Bajo b. Medio 3. Alto 4. Ninguno encuesta. 2. Cuál es el nivel de importancia que han tenido los requerimientos en el desarrollo de sus proyectos? a. 0% - 20% b. 21% - 40% c. 41% - 60% d. 61% - 80% e. 81% - 100% 122

123 3. Cuáles de las siguientes técnicas son utilizadas por usted en la captura de requisitos? a. Entrevista b. Cuestionarios c. Checklist d. Tormenta de ideas e. Desarrollo Conjunto de Aplicaciones (JAD) * Supone una alternativa a las entrevistas individuales, y se desarrolla a lo largo de un conjunto de reuniones en grupo en un período de 2 a 4 días. Se integra al cliente en el desarrollo del proyecto. f. Casos de Uso g. Prototipado h. Ninguna 4. Cuáles de las siguientes técnicas son utilizadas por usted en el análisis de requisitos? a. Casos de Uso b. Prototipado c. Walkthroughs * El objetivo primordial de esta técnica es identificar errores o conflictos en la documentación o definición de requisitos. d. Ninguna 5. Cuáles de las siguientes técnicas son utilizadas por usted en la especificación de requisitos? a. Casos de Uso b. Prototipado c. Walkthroughs * El objetivo primordial de esta técnica es identificar errores o conflictos en la documentación o definición de requisitos. d. Desarrollo Conjunto de Aplicaciones (JAD) e. Ninguna 123

124 6. Cuáles de las siguientes técnicas son utilizadas por usted en la validación y verificación de requisitos? a. Casos de Uso b. Prototipado c. Walkthroughs * El objetivo primordial de esta técnica es identificar errores o conflictos en la documentación o definición de requisitos. d. Ninguna 7. De los modelos de Ingeniería de Requisitos mencionados a continuación, cuáles son utilizados por usted en el desarrollo de sus proyectos? a. Modelo Estándar * Captura, Análisis, Validación. b. Modelo de Pohl c. Modelo Espiral d. Modelo Sweebok e. Modelos de Madurez del Proceso Reaims f. Modelo de Procesos Volere g. Otro (Especifique) 8. Cuál de las siguientes herramientas son utilizadas por usted la el manejo o gestión de los requisitos en el desarrollo de sus proyectos. a. IRqA (Integral Requisite Analyzer) b. Requisite Pro c. LEAP SE d. Visual Requisite GRACIAS POR SU COLABORACIÓN 124

125 Anexo 2. A continuación se detalla algunas características principales de las herramientas utilizadas en la Ingeniería de Requisitos. IRqA (ANALIZADOR INTEGRAL DE REQUISITOS) GENERALIDADES Es una herramienta que fue desarrollada por TCP Sistemas e Ingeniería de España, es completa, puesto que no es necesario utilizar algún otro tipo de herramienta para ejecutar o desarrollar todas las actividades de la Ingeniería de Requisitos. IRqA cubre la captura, análisis, especificación, validación, gestión de los requisitos de los clientes, incluyendo en esta última actividad la gestión de calidad, de pruebas y, trazabilidad de los requisitos. Ilustración 47. Logotipo de IRqA. Fuente: Sitio Oficial de IRqA - Además, es muy útil en la construcción de un proyecto, puesto permite gestionar los requisitos en todas las fases de desarrollo del software y organizar dicho proyecto. Por lo tanto, con IRqA se logra reducir costos tanto en la especificación de los requisitos, como en el desarrollo de una solución. Por estos motivos, IRqA se ha convertido en una herramienta indispensable para las empresas en el desarrollo de grandes proyectos a nivel mundial, ente las que destacan IBM, Audi, Bosch. Tecnologías de la información, aeroespacial, microelectrónica, automotriz, telecomunicaciones y redes, y por supuesto desarrollo de software son las áreas de mayor aplicación de esta herramienta; no sólo por la facilidad de uso y reducción de costos, sino también por la aplicación de estándares que mejoran el rendimiento y funcionalidad de los proyectos. Es así qué, permite realizar conexiones ODBC o bases de 125

126 datos, es accesible a lenguajes de programación como Java, C++ y Visual Basic. La utilización de IRqA en proyectos realizados por parte del Gabinete de Investigación Militar Operativa de España e Yphise, una compañía de analistas mundialmente reconocida, le ha permitido comprobar y, reconocer la funcionalidad y rendimiento de esta herramienta en dichos proyectos. Ilustración 48. Empresas que han aplicado IRqA. Fuente: Sitio Oficial de IRqA - FUNCIONALIDADES Dentro de las funcionalidades de esta herramienta, en cuanto al manejo de los requisitos están: Captura y clasificación de requisitos Análisis de requisitos Especificación de la solución Validación de la especificación 126

127 Organización del proyecto Medidas de calidad de de la especificación de requisitos Generación de reportes En relación a las fases de desarrollo de un proyecto, las funcionalidades de esta herramienta cubren las siguientes actividades: Pruebas de validación y aceptación Gestión de la configuración Estimación de proyectos Integración con herramientas de diseño El objetivo principal de IRqA, además de la reducción de costos, es desarrollar una especificación de requisitos correcta, completa y sin inconsistencias. Como logra esto, a través de una buena recolección de información, en esta herramienta los requisitos son tomados como elementos de información 27. Estos elementos de información son sometidos a las actividades del la Ingeniería de Requisitos utilizando un modelo iterativo, es decir, en cada actividad se obtiene una resultado, este resultado viene a ser la especificación de requisitos que el ingeniero de requisitos de ir analizando y refinando en cada iteración. PROCESOS DE IRqA Las actividades que se encuentran definidas en IRqA se las clasifica en dos procesos, las que componen el proceso básico de especificación de requisitos y, las del proceso de soporte: 27 CARO, Fernández. Introducción a la Ingeniería de Requisitos con IRqA. TCP Sistemas e Ingeniería. España. Documento digital. 127

128 Proceso básico: Captura de requisitos: Recolección de la información proporcionada por el cliente o los stakeholders que intervengan en el proceso. Se realiza una captura automática de requisitos a través de MS Word, Excel. Aquí se puede integrar herramientas de gestión de la configuración como: MS Visual SourceSafe, CVS y otras. Análisis de requisitos: Comprender el problema planteado por el usuario y determinación de las funcionalidades y restricciones del proyecto. Se puede construir modelos o diagramas de clases, de entidad-relación. Especificación de la solución: Descripción de los requisitos y de las funcionalidades del proyecto y del entorno en que se va a desenvolver a través de modelos o diagramas: - Diagramas de casos de uso (UML) - Diagramas de estado (UML) - Diagramas de contexto - Diagramas de flujo de datos - Escenarios 128

129 Descripción funcional (Especificación de la solución). Validación de la especificación: Comprobar que cada uno de los requisitos obtenidos y descritos en la especificación definen el sistema o proyecto que se va a construir y que desea el cliente. Esto se hace de forma automática, IRqA detecta automáticamente inconsistencias en la especificación de la solución. Proceso de soporte: Gestión de requisitos: Controlar y administrar los requisitos y sus cambios para luego reutilizarlos en cualquier actividad del proceso de software que se necesite. Trazabilidad de requisitos: Identificación de los requisitos que afectan directa o indirectamente en cada una de las fases del ciclo de vida del proceso de desarrollo del software. IRqA tiene predeterminada una metodología o proceso flexible, lo que permite ajustarlo a cualquier tipo de proyecto que se desee construir. Esto puede ser una ventaja en algunas ocasiones, pero puede convertirse en una desventaja ya que no permite que se adapte o 129

130 incorpore otras diferentes metodologías según la conveniencia del ingeniero de requisitos y del tipo de proyecto. IBM RATIONAL REQUISITE PRO Es una herramienta desarrollada y utilizada por IBM en la construcción de sus proyectos y el de sus clientes y parte del Proceso Racional Unificado (RUP). IBM tiene una política que va de la mano con la aplicación de esta herramienta, cuánto mejor se comunique y administre los requisitos, mejor será la oportunidad que tendrán sus proyectos para brindar la solución correcta a tiempo y dentro del presupuesto 28. Esta herramienta es muy potente, permite una adecuada captura, análisis y gestión de los requisitos así como los casos de uso. Es fácil de usar, además, como característica principal, permite que no solo el ingeniero de requisitos sino también todos los miembros del equipo de desarrollo de software, colaboren en la creación y compartición de los requisitos de la solución que se vaya a construir. Permite almacenar los requisitos en una base de datos como Oracle 8, 9i o 10G, SQL Server 7 o 2000 Microsoft Access 2000, lo que ayuda a dar soporte a una gran cantidad de requisitos. Permite generar reportes para los clientes, además de un seguimiento de los requisitos en todas las fases de desarrollo de una solución. Dentro de los beneficios que posee Requisite Pro están: Es potente y fácil de usar para la gestión de requisitos y casos de uso. Proporciona una mejor comunicación y mejora el trabajo en equipo. Disminuye el riesgo de fracaso de un proyecto. Permite manejar bases de datos, se logra la máxima eficacia y consulta de los requisitos. 28 IBM. Documentación de IBM Rational Requisite Pro. 130

131 Da la posibilidad a los miembros del equipo de desarrollo de conocer e identificar los cambios en los requisitos. Garantiza la comunicación entre el equipo y la coherencia de los requisitos. Permite que el usuario defina los tipos de requisitos que desee. Permite generar informes para los clientes. Su principal desventaja es que, sólo se maneja en el sistema operativo Windows (2000, NT y XP) y su costo es muy alto (más de $ ). Requisite Pro utiliza MS Word y bases de datos no propietarias para organizar la información, dicha información es almacenada en paquetes o baselines, aquí se encuentra definidos documentos o plantillas que se conectan a una base de datos, de tal manera que, si un miembro del equipo desee ver el contenido o las características que engloba un requisito o la forma y contexto como introdujo la información, simplemente lo puede hacer con un doble clic sobre este. Lo que permite una administración y gestión efectiva de los requisitos que se están manejando en ese momento para el desarrollo de una solución. 29 SOLARTE, Mario. Aproximación metodológica para la ingeniería de requisitos de sistemas telemáticos. Documento digital. 131

132 Almacenamiento de requisitos en paquetes. Los requisitos evolucionan conforme transcurre el desarrollo de un proyecto, en muchas ocasiones, especialmente en proyectos grandes, no es fácil determinar y analizar los cambios y el impacto que tienen sobre otros requisitos relacionados. Con esta herramienta se puede ver dicho impacto en tiempo real, lo que le permite al ingeniero de requisitos o los miembros del equipo tomar decisiones rápidamente para una mejor administración de los requisitos. Los desarrolladores tienen acceso total a los requisitos, lo que les permite obtener un diseño óptimo de la solución y disminuir costos en revisiones, revisiones de los requisitos que son permanentes durante el ciclo de vida del software. Como es una complemento de RUP, el acceso a los requisitos se logra a través de IBM Rational Software Arquitect, IBM Rational Software Modeler y IBM Rational Rose Technical Developer, sin necesidad de que el desarrollador tenga que ir donde el ingeniero de requisitos a pedir la información. De tal manera que el desarrollador también pueda acceder al modelo de casos de uso, su 132

133 especificación y su diagrama, desarrollados en esta misma herramienta, con el fin de asegurar que el proyecto o la solución que se esté construyendo refleje realmente la necesidades de los clientes. La contribución de toda la suite de IBM RUP hace que se cumpla correctamente la administración de los requisitos, pero no dejando de lado las mejores prácticas que caracteriza a esta metodología: Desarrollo iterativo del software Gestión de los requisitos Arquitectura basada en componentes Modelado (UML) Verificación y validación de la calidad del software Control y gestión de los cambios del software Dentro de las características o funcionalidades que posee esta poderosa herramienta están: Integración de Word y bases de datos Potente motor de requerimientos Trazabilidad Análisis y notificación de cambios Creación y comparación de baselines Acceso vía web mediante RequisiteWeb Reporte detallado de estándares y compatibilidad Soporte de bases de datos comerciales Integración con herramientas de Rational Soporte a la comunidad de usuario y a su información GRUPO SOLUCIONES INNOVA. Herramientas y soluciones IBM. Disponible en: 133

134 LEAP SE Ilustración 49. Administración y gestión de requisitos. Es una herramienta que permite crear y administrar requisitos, además, cada requisito puede ser clasificado según el tipo de requisitos: funcional, estructural y técnico, clasificación según LEAP SE; y según la categoría, además, permite determinar un nivel de prioridad para cada uno de los requisitos creados. Posee 22 plantillas para crear rápidamente los requisitos necesarios para el proyecto. Los requisitos que se definan, tienen un conjunto de atributos, estos pueden ser relacionados con entidades que se han encontrado en la información que se recolecta del cliente o los stakeholders, se los clasifica según el tipo de requisitos que el ingeniero de requisitos considere, además, los dichos requisitos son modificados, se puede manejar versiones, lo que ayuda a no perder los datos históricos de cada uno de ellos. 134

135 Ilustración 50. Atributos de Requisitos. A través de una integración con Microsoft Access DB, permite gestionar y administrar de mejor manera los requisitos. Los campos de la base de datos se crean automáticamente cuando se genera un diagrama con los posibles campos para una base de datos SQL en LEAP SE, estos campos son los que constan en cada plantilla, sean atributos, entidades, prioridad, categorías, etc. Además del diagrama de la base de datos SQL, también se puede obtener un modelo de objetos, del cual se puede generar el código y ser utilizado por el equipo de desarrollo en la construcción de la solución. 135

136 Ilustración 51. Código de modelos de objetos. Es una herramienta muy práctica y fácil de usar. Los ingenieros de requisitos, cuando incursionan en nuevos proyectos, pueden ser relacionados o no, con esta herramienta pueden obtener datos importantes que les puedan servir de base para el desarrollo de una solución exitosa y satisfactoria para el cliente, es decir, la reutilización de la información. VISUAL REQUISITE Visual Requisite, es una solución innovador para ser utilizada en base a las necesidades de desarrollo, es de bajo costo y no implica riesgos que dificulten la obtención de una solución que satisfaga al cliente. Visual Requisite es útil cuando implica desarrollar un proyecto de cualquier tipo en que el ingeniero de requisitos sea capaz de describir el problema de manera rápida, eficiente, con claridad, y sobre todo que no implique muchos gastos, esto en función de los que se va a construir. Permite generar y administrar los requisitos de manera eficaz. Además, permite crear escenarios y casos de uso que pueden ser relacionados con los requisitos previamente 136

137 establecidos. Algo muy importante de esta herramienta es el desarrollo de interfaces de usuario, lo que permite presentar a los clientes un prototipo inicial de la solución en base a los requisitos obtenidos. El requisito principal de esta herramienta es tener una plataforma Windows, además, el equipo en el que se instale Visual Requisite deberá contar con una capacidad de memoria RAM de 512MB. Ilustración 52. Casos de Uso en Visual Requisite. Dentro de las funcionalidades principales de Visual Requisite están: Construir requisitos como un conjunto de esquemas vinculados que son fáciles de leer y navegar. Presentar un producto en múltiples puntos de vista: caso de uso, interfaz de usuario, flujo de trabajo, definir casos de uso visualmente. 137