Descarga la aplicación para disfrutar aún más
Vista previa del material en texto
Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 1 UNIDAD 4 REQUERIMIENTOS Y VIABILIDAD DEL SISTEMA IDENTIFICACION DE REQUISITOS Introducción Lo más difícil en la construcción de un sistema software es decidir precisamente qué construir, no existe tarea con mayor capacidad de lesionar al sistema cuando se hace mal. Ninguna otra tarea es tan difícil de rectificar a posteriori (F.P. Brooks, 1987) Continuamente se publican nuevos datos acerca de la importancia de los requisitos en Ingeniería del Software, por ejemplo según el “Chaos Report” del Standish Group 1, resulta que: • El gasto anual en proyectos software en EEUU es de unos 250 billones de dólares, invertidos en aproximadamente unos 175000 proyectos • 31.1% serán cancelados • 52.7% costará un 190% más de lo estimado • Un 16.2% será finalizado a tiempo y dentro del presupuesto pero el producto final poseerá (aprox.) la mitad de los requisitos iniciales Estudios anteriores a éste reflejan: • El 45% de los errores tienen su origen en los requisitos y en el diseño preliminar • El 56% de los errores que tienen lugar en un proyecto software se deben a una mala especificación de requisitos Según el “Chaos Report” los factores principales que conducen al fracaso en los proyectos software son: • Falta de comunicación con los usuarios • Requisitos incompletos • Cambios a los requisitos Por otra parte la evidencia demuestra que: • Los requisitos contienen demasiados errores • Muchos de estos errores no se detectan al principio • Muchos de estos errores podrían ser detectados al principio • No detectar errores incrementa los costos (tiempo y dinero) de forma exponencial Y esto trae como consecuencia que: • El sistema resultante no satisface a los usuarios • Se producirán desacuerdos entre usuarios y desarrolladores • Puede ser imposible demostrar si el software cumple o no los requisitos • Se gastará tiempo y dinero en construir el sistema equivocado Ante esta situación qué se puede hacer? En primer lugar, se debe tomar conciencia del problema, quizá no se conozcan todas las soluciones, pero al menos se conocen los problemas. Quizá no sea posible elaborar los requisitos con absoluta perfección, pero se debiera intentar minimizar el impacto de los errores en los requisitos y se podría tratar de organizar mejor las tareas relacionadas con los requisitos. Los requisitos se sitúan en la frontera socio-técnica de los sistemas, y esa frontera es borrosa, e inconsistente. Según M. Jackson los requisitos son: “donde lo formal se encuentra con lo informal”. Los requisitos están vivos, emergen, interactúan, cambian, desaparecen… 1 www.standishgroup.com/chaos.html nicoj Resaltar nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 2 Ingeniería de Requisitos Para remediar en lo posible esta situación, surge la Ingeniería de Requisitos (IR). La IR trata de los principios, métodos, técnicas y herramientas que permiten descubrir, documentar y mantener los requisitos para sistemas basados en computadora, de forma sistemática y repetible. La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software. Se crean modelos de los requisitos de datos, flujo de información y control, y del comportamiento operativo. Se analizan soluciones alternativas y el modelo completo del análisis es creado. Donald Reifer describe el proceso de ingeniería de requisitos del software en el siguiente párrafo: La ingeniería de requisitos es el uso sistemático de procedimientos, técnicas, lenguajes y herramientas para obtener con un coste reducido el análisis, documentación, evolución continua de las necesidades del usuario y la especificación del comportamiento externo de un sistema que satisfaga las necesidades del usuario. Todas las disciplinas de la ingeniería son semejantes, la ingeniería de requisitos no se guía por conductas esporádicas, aleatorias o por modas pasajeras, si no que se debe basar en el uso sistemático de aproximaciones contrastadas. Tanto el desarrollador como el cliente tienen un papel activo en la ingeniería de requisitos del software. El cliente intenta replantear un sistema confuso, a nivel de descripción de datos, funciones y comportamiento, en detalles concretos. El desarrollador actúa como un interrogador, como consultor, como persona que resuelve problemas y como negociador. ¿Qué es? El papel global del software en un gran sistema es identificado durante la ingeniería del sistema. De cualquier manera, es necesario considerar una visión lo más profunda posible del papel del software, para comprender los requisitos específicos que deben ser considerados en la construcción de un software de alta calidad. Este es el trabajo del análisis de requisitos del software. Para realizar el trabajo adecuadamente, se deben seguir un conjunto de conceptos y principios fundamentales. ¿Quién lo hace? Generalmente, el ingeniero del software es quién realiza el análisis de requisitos. En cualquier caso, para aplicaciones de negocio complejas, un «analista de sistemas» —formado en los aspectos del negocio del dominio de la aplicación— puede realizar esta tarea. ¿Por qué es importante? Si no se analiza, es muy probable que se construya una solución software muy elegante que resuelva incorrectamente el problema. El resultado es tiempo y dinero perdido, frustración personal y clientes descontentos. ¿Cuáles son los pasos? Los requisitos de datos, funciones y comportamiento son identificados por la obtención de información facilitada por el cliente. Los requisitos son refinados y analizados para verificar su claridad, completitud y consistencia. La especificación se incorpora al modelo del software y es validada tanto por el ingeniero del software como por los clientes/usuarios. ¿Cuál es el producto obtenido? Una representación efectiva del software debe ser producida como una consecuencia del análisis de requisitos. Tanto los requisitos del sistema como los requisitos del software pueden ser representados utilizando un prototipo, una especificación o un modelo simbólico. ¿Cómo puedo estar seguro de que lo he hecho correctamente? El resultado obtenido del análisis de requisitos del software debe ser revisado para conseguir: claridad, completitud y consistencia. nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 3 Requisitos Se considerará que un problema sw consiste en configurar una máquina M para que ejerza unos efectos R en un dominio D La máquina M es la que realizará los requisitos R gracias a su conexión con D. En la fase de requisitos solo necesitamos describir las conexiones de M con D, es decir el comportamiento externo de M (M-ex), sin detalles internos (M-int). En IR se denominan requisitos a los tres conjuntos M-ex, R y D, la razón es que los requisitos estánconstituidos por toda aquella información que sirva para construir un sistema que satisfaga las metas perseguidas. Ejemplo Este ejemplo está basado en un caso real, y demuestra que los Requisitos (metas, deseos), no son suficientes si no se encuentran basados en un contexto: Se trata de especificar un software para un sistema de avión. En estos sistemas hay un requisito que establece, que la marcha atrás sólo puede ser habilitada sí y solo sí el avión se encuentra en la pista. Es decir: R: marcha_atras-habilitada → avión_en_pista Para detectar si el avión se encuentra o no en pista, existen unos sensores conectados a las ruedas, que generan pulsos eléctricos, cuando las ruedas están girando. Para que este mecanismo funcione, se supone que en el dominio que rodea al software (o sea, en el mundo real) se cumple que “las ruedas rotan cuando se encuentran en pista y que se envían los pulsos cuando las ruedas rotan” D1: pulsos_sensor → ruedas_rotando D2: ruedas_rotando → avión_en_pista Las dos afirmaciones no son requisitos, sino descripciones. Finalmente, la descripción del comportamiento externo de la máquina M (en realidad el comportamiento externo del software, M-ex), establecería que M-ex: marcha_atras_habilitada →pulsos_sensor Puede comprobarse que dado el comportamiento externo de la Máquina M-ex y dadas las descripciones D, se cumple R. La importancia del conocimiento del dominio D, es crucial en la IR. Si se diera el caso (como sucedió en la realidad) que la pista estuviese mojada (aquaplaning) y por lo tanto las ruedas dejaran de rotar, deja de cumplirse D2, las ruedas no rotan a pesar de que el avión está en la pista. Por lo tanto, un pequeño cambio en el Dominio, pese a no hallarse aparentemente conectado con el software, puede conducir a una situación en la que R no se cumple. En IR se denominan “requisitos” a los tres conjuntos R, M-ex y D. La razón es que los requisitos están constituidos por toda la información necesaria para construir un sistema que satisfaga las metas perseguidas. Los requisitos no son análisis top-down, ni son la arquitectura del sistema, ni son el “qué” frente al “cómo”. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 4 Determinación e Identificación de requisitos El análisis y la especificación de los requisitos puede parecer una tarea relativamente sencilla, pero las apariencias engañan. Abundan las ocasiones para las malas interpretaciones o falta de información. Es muy probable que haya ambigüedad. El dilema al que se enfrenta el ingeniero del software puede entenderse muy bien repitiendo la famosa frase de un cliente anónimo: «Sé que cree que entendió lo que piensa que dije, pero no estoy seguro de que se dé cuenta de que lo que escuchó no es lo que yo quise decir.» El análisis de los requisitos es una tarea de ingeniería del software que cubre el hueco entre la definición del software a nivel sistema y el diseño del software El análisis de requisitos permite al ingeniero de sistemas especificar las características operacionales del software (función, datos y rendimientos), indica la interfaz del software con otros elementos del sistema y establece las restricciones que debe cumplir el software. El análisis de requisitos del software puede dividirse en cinco áreas de esfuerzo: (1) reconocimiento del problema (2) evaluación y síntesis (3) modelado (4) especificación (5) revisión. Inicialmente, el analista estudia la Especificación del Sistema (si existe alguna) y el Plan del Proyecto de Software. Es importante entender el software en el contexto de un sistema y revisar el ámbito del software que se empleó para generar las estimaciones de la planificación. A continuación, se debe establecer la comunicación para el análisis de manera que nos garantice un correcto reconocimiento del problema. El objetivo del analista es el reconocimiento de los elementos básicos del problema tal y como los percibe el cliente/usuario. La evaluación del problema y la síntesis de la solución es la siguiente área principal de esfuerzo en el análisis. El analista debe definir todos los objetos de datos observables externamente, evaluar el flujo y contenido de la información, definir y elaborar todas las funciones del software, entender el comportamiento del software en el contexto de acontecimientos que afectan al sistema, establecer las características de la interfaz del sistema y descubrir restricciones adicionales del diseño. Cada una de estas tareas sirve para describir el problema de manera que se pueda sintetizar un enfoque o solución global. Por ejemplo, un mayorista de repuestos de automóviles necesita un sistema de control de inventario. El analista averigua que los problemas del sistema manual que se emplea actualmente son: (1) incapacidad de obtener rápidamente el estado de un componente (2) dos o tres días de media para actualizar un archivo a base de tarjetas; (3) múltiples órdenes repetidas para el mismo vendedor debido a que no hay manera de asociar a los vendedores con los componentes. Una vez que se han identificado los problemas, el analista determina qué información va a producir el nuevo sistema y qué información se le proporcionará al sistema. Por ejemplo, el cliente desea un informe diario que indique qué piezas se han tomado del inventario y cuántas piezas similares quedan. El cliente indica que los encargados del inventario registrarán el número de identificación de cada pieza cuando salga del inventario. nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Máquina de escribir El analista crea modelos para entender el comportamiento del sistema y El modelo servirá de pilar para el diseño del software y como base para la creación de una especificación del software. nicoj Máquina de escribir se especifican los criterios de validación que han de servir para demostrar que se ha llegado a un buen entendimiento de la forma de implementar con éxito el software. nicoj Máquina de escribir Revisión. Se vuelve a evaluar el plan del proyecto del software, para determinar si las primeras estimaciones siguen siendo validas después del conocimiento adicional obtenido durante el análisis. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 5 Una vez evaluados los problemas actuales y la información deseada (entrada y salida), el analista empieza a sintetizar una o más soluciones. Para empezar, se definen en detalle los datos, las funciones de tratamiento y el comportamiento del sistema. Una vez que se ha establecido esta información, se consideran las arquitecturas básicas para la implementación. Un enfoque cliente/servidor parecería apropiada, pero ¿está dentro del ámbito esbozado en el Plan del Software'? Parece que sería necesario un sistema de gestión de bases de datos, pero, ¿está justificada la necesidad de asociación del usuario/cliente? El proceso de evaluación y síntesis continúa hasta que ambos, el analista y el cliente, se sienten seguros de que se puede especificar adecuadamente el software para posteriores fases de desarrollo. A lo largo de la evaluación y síntesis de la solución, el enfoque primario del analista está en el «qué» y no en el «cómo». ¿Qué datos produce y consume el sistema, qué funciones deberealizar el sistema, qué interfaces se definen y qué restricciones son aplicables? Durante la actividad de evaluación y síntesis de la solución, el analista crea modelos del sistema en un esfuerzo de entender mejor el flujo de datos y de control, el tratamiento funcional y el comportamiento operativo y el contenido de la información. El modelo sirve como fundamento para el diseño del software y como base para la creación de una especificación del software. El Proceso de los Requisitos El proceso de Ingeniería de Requisitos es un conjunto estructurado de actividades que sirven para derivar, validar y mantener los requisitos de un sistema (hardware, software o hardware + software). De acuerdo con los estándares definidos por la IEEE la especificación estándar de requerimientos de software debe contener los siguientes elementos: • Descripción de la Funcionalidad de la Aplicación. • Descripción de la relación de la Aplicación con Sistemas e Interfaces Externas. • Descripción de las métricas de Desempeño del Sistema (Velocidad, disponibilidad, tiempos de respuesta y mantenibilidad). • Limitaciones de la implementación (Lenguaje de desarrollo, políticas de Base de Datos, Sistemas Operativos y otros Recursos utilizados). Las tareas que conlleva este proceso, a grandes rasgos, se representan en el siguiente gráfico: nicoj Resaltar nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 6 Los cuadros redondeados son tareas. Los cuadros son productos (inputs o outputs). La separación que se muestra es más conceptual que real ya que las tareas que se ejecutan durante el proceso de requisitos suceden en paralelo y se solapan unas con otras. Por ejemplo durante el proceso de Educción de Requisitos empleando prototipado, es inevitable realizar una pequeña validación de los requisitos que se van obteniendo, o incluso una pequeña negociación, si por ejemplo estamos tratando con varios usuarios a la vez. IDENTIFICACIÓN DE REQUISITOS PARA EL SOFTWARE Antes que los requisitos puedan ser analizados, modelados o especificados, deben ser recogidos a través de un proceso de obtención. La educción de requisitos se refiere a la captura y descubrimiento de los requisitos. Es una actividad más “humana” que técnica, en la que se identifica a los interesados y se establecen las primeras relaciones entre ellos y el equipo de desarrollo: “Un cliente tiene un problema que pretende sea resuelto con una solución basada en computadora. Un desarrollador responde a la solicitud de ayuda del cliente. La comunicación ha empezado. Pero el camino de la comunicación al entendimiento está a menudo lleno de baches.” Principales fuentes de requisitos Los requisitos pueden proceder de: • Metas: factores críticos de éxito • Conocimiento del dominio de la aplicación • Los interesados. Los afectados por el sistema • El entorno físico que rodea al sistema • El entorno organizacional. Los procesos de negocio. Inicio del proceso La técnica de obtención de requisitos (educción) más usada, es la de llevar a cabo una reunión o entrevista preliminar. La primera reunión entre el ingeniero del software (el analista) y el cliente puede compararse con la primera cita entre dos adolescentes. Nadie sabe qué decir o preguntar; los dos están preocupados de que lo que digan sea malentendido; ambos piensan qué pasará (los dos pueden tener expectativas radicalmente diferentes); los dos están deseando que aquello termine, pero, al mismo tiempo, ambos desean que la cita sea un éxito. Sin embargo, hay que empezar la comunicación. Gause y Weinberg [GAU89] sugieren que el analista empiece preguntando cuestiones de contexto libre. Es decir, un conjunto de preguntas que llevarán a un entendimiento básico del problema, qué solución busca, la naturaleza de la solución que se desea y la Educción de Requisitos Análisis y Negociación Documentación de Requisitos Educción de Requisitos Necesidades Información del Dominio Estándares Documento de Requisitos GESTION DE REQUISITOS nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 7 efectividad del primer encuentro. El primer conjunto de cuestiones de contexto libre se enfoca sobre el cliente, los objetivos generales y los beneficios esperados. Por ejemplo, el analista podría preguntar: • ¿Quién está detrás de la solicitud de este trabajo? • ¿Quién utilizará la solución? • ¿Cuál será el beneficio económico del éxito de una solución? • ¿Hay alguna otra alternativa para la solución que necesita? Estas preguntas ayudan a identificar todos los participantes que tienen un interés en el software a construir. Además, las preguntas identifican los beneficios medibles en una implementación correcta de posibles alternativas para un desarrollo normal del software. El siguiente conjunto de preguntas permite al analista obtener un mejor entendimiento del problema y al cliente comentar sus opiniones sobre la solución: • ¿Cómo caracterizaría una «buena» salida (resultado) generada para una buena solución? • ¿A qué tipo de problema(s) va dirigida esta solución? • ¿Puede mostrarme (o describirme) el entorno en que se utilizará la solución? • ¿Hay aspectos o restricciones especiales del rendimiento que afecten a la manera de enfocar la solución? El último conjunto de preguntas se concentra en la eficacia de la reunión. Gauge y Weinberg las denominan «meta-preguntas» y proponen la siguiente lista (abreviada): ¿Es usted la persona adecuada para responder a estas preguntas? ¿Sus respuestas son «oficiales»? ¿Estoy preguntando demasiado? ¿Hay alguien más que pueda proporcionar información adicional? ¿Hay algo más que debería preguntarle? Estas preguntas (y otras) ayudarán a «romper el hielo» e iniciar la comunicación tan esencial para el éxito del análisis. Pero el formato de reunión tipo «pregunta y respuesta» no es un enfoque que haya tenido mucho éxito. De hecho, esta sesión de preguntas y respuestas debería emplearse solamente en el primer encuentro y sustituirse después por una modalidad que combine elementos de resolución del problema, negociación y especificación. En la siguiente sección se presenta un enfoque a reuniones de este tipo. Técnicas para facilitar las especificaciones de una aplicación Entre las técnicas destacadas para la educción de requisitos, hallamos: • Entrevistas: que es el método tradicional • Escenarios: los requisitos se situan en el contexto de uso del sistema • Prototipado: cuando la incertidumbre es total acerca del futuro del sistema. De los cuales hay dos tipos principales, Evolutivo y De Desecho (muchas veces desarrollados con diapositivas) Técnica TFEA Los clientes y los ingenieros del software a menudo tienen una mentalidad inconsciente de «nosotros y ellos». En vez de trabajar como un equipo para identificar y refinar los requisitos, cada uno define por derecho su propio «territorio» y se comunica a través de una serie de memorandos, papeles de posiciones formales, documentos y sesiones de preguntas y respuestas. La historia ha demostrado que este método no funciona muy bien. Abundan los malentendidos, se omite información importante y nunca se establece una buena relación de trabajo. Con estos problemas en mente es por lo que algunos investigadores independientes han desarrollado un enfoque orientado al equipo para la reunión de requisitos que se aplica durante las primeras fases delanálisis y especificación. Denominadas Técnicas para facilitar las especificaciones de la aplicación (TFEA), este enfoque es partidario de la creación de un equipo conjunto de clientes y desarrolladores que trabajan juntos para identificar el problema, proponer soluciones, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución. Hoy en día, las TFEA son empleadas de forma general por los sistemas de información, pero la técnica ofrece un potencial de mejora en aplicaciones de todo tipo. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 8 Se han propuesto muchos enfoques diferentes de TFEA. Cada uno utiliza un escenario ligeramente diferente, pero todos aplican alguna variación en las siguientes directrices básicas: • La reunión se celebra en un lugar neutral y acuden tanto los clientes como los desarrolladores. • se establecen normas de preparación y de participación. • se sugiere una agenda lo suficientemente formal como para cubrir todos los puntos importantes, pero lo suficientemente informal como para animar el libre flujo de ideas. • Un «coordinador» (que puede ser un cliente, un desarrollador o un tercero) que controle la reunión. • Se usa un «mecanismo de definición» (que puede ser hojas de trabajo, gráficos, carteles o pizarras). • El objetivo es identificar el problema, proponer elementos de solución, negociar diferentes enfoques y especificar un conjunto preliminar de requisitos de la solución en una atmósfera que permita alcanzar el objetivo. Para comprender mejor el flujo de acontecimientos tal y como ocurren en una reunión TFEA, presentamos un pequeño escenario que esboza la secuencia de acontecimientos que llevan a la reunión, los que ocurren en la reunión y los que la siguen. En las reuniones iniciales entre el desarrollador y el cliente, se dan preguntas y respuestas básicas que ayudan a establecer el ámbito del problema y la percepción global de una solución. Fuera de estas reuniones iniciales, el cliente y el desarrollador escriben una «solicitud de producto» de una o dos páginas. Se selecciona lugar, fecha y hora de reunión TFEA2 y se elige un coordinador. Se invita a participar a representantes de ambas organizaciones; la del cliente y la de desarrollo. Se distribuye la solicitud de producto a los asistentes antes de la fecha de reunión. Mientras se revisa la solicitud días antes de la reunión, se pide a todos los asistentes que hagan una lista de objetos que formen parte del entorno del sistema, otros objetos que debe producir el sistema y objetos que usa el sistema para desarrollar sus funciones. Además, se pide a todos los asistentes que hagan otra lista de servicios (procesos o funciones) que manipulan o interactúan con los objetos. Finalmente, se desarrollan también listas de restricciones (por ejemplo, costes, tamaño, peso) y criterios de rendimiento (por ejemplo, velocidad, precisión). Se informa a los asistentes que no se espera que las listas sean exhaustivas, pero que sí que reflejen su punto de vista del sistema. Por ejemplo, imagínese que a un equipo de trabajo TFEA de una compañía de productos para el consumidor se le ha dado la siguiente descripción del producto: “Nuestras investigaciones indican que el mercado de sistemas de seguridad para el hogar está creciendo a un ritmo del 40 por 100 anual. Nos gustaría entrar en este mercado construyendo un sistema de seguridad para el hogar basado en un microprocesador que proteja y/o reconozca varias situaciones indeseables tales como irrupciones ilegales, fuego, inundaciones y otras. El producto, provisionalmente llamado Hogar Seguro, utilizará los sensores adecuados para detectar cada situación, puede programarse por el propietario del hogar y llamará automáticamente a una agencia de vigilancia cuando se detecte alguna de estas situaciones.” En realidad, se proporcionaría considerablemente más información en esta fase. Pero incluso con información adicional, habría ambigüedades presentes, existirán omisiones probablemente y podrían ocurrir errores. Por ahora, la «descripción de producto» anterior bastará. El equipo TFEA está compuesto por representantes de marketing, ingeniería del software y del hardware, y de la fabricación también participará un coordinador externo. Todos los componentes del equipo TFEA desarrollan las listas descritas anteriormente. Los objetos descritos para HogarSeguro podrían incluir detectores de humo, sensores de ventanas y puertas, detectores de movimientos, una alarma, un acontecimiento (se ha activado un sensor), un panel de control, una pantalla, números de teléfono, una llamada de teléfono, etc. La lista de servicios podría incluir la instalación de la alarma, vigilancia de los sensores, marcado de teléfono, programación del panel de control y lectura de la pantalla (fíjese que los servicios actúan sobre los objetos). De igual manera, todos los asistentes TFEA desarrollarán una lista de restricciones (por ejemplo, el sistema debe tener un coste de fabricación de menos de $10.000, 2 Dos de los enfoques más populares de TFEA son Desarrollo Conjunto de Aplicaciones/UAD), desarrollado por IBM, y The METHOD, desarrollado por Performance Resources, Irte, Falls Church, VA. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 9 debe tener una «interfaz amigable» con el usuario y debe conectar directamente con una línea telefónica estándar) y de criterios de rendimiento (por ejemplo, un acontecimiento detectado por un sensor debe reconocerse en un segundo; se debería implementar un esquema de prioridad de acontecimientos). Cuando empieza la reunión TFEA, el primer tema de estudio es la necesidad y justificación del nuevo producto, pues todo el mundo debería estar de acuerdo en que el desarrollo (o adquisición) del producto está justificada. Una vez que se ha conseguido el acuerdo, cada participante presenta sus listas para su estudio. Las listas pueden exponerse en las paredes de la habitación usando largas hojas de papel, pinchadas o pegadas, o escritas en una pizarra. Idealmente debería poderse manejar separadamente cada entrada de las listas para poder combinarlas, borrarlas o añadir otras. En esta fase, está estrictamente prohibido, el debate o las críticas. Una vez que se han presentado las listas individuales sobre un tema, el grupo crea una lista combinada. La lista combinada elimina las entradas redundantes y añade las ideas nuevas que se les ocurran durante la presentación, pero no se elimina nada más. Cuando se han creado las listas combinadas de todos los temas, sigue el estudio —moderado por el coordinador—. La lista combinada es ordenada, ampliada o redactada de nuevo para reflejar apropiadamente el producto o sistema que se va a desarrollar. El objetivo es desarrollar una lista de consenso por cada tema (objetos, servicios, restricciones y rendimiento). Después estas listas se ponen aparte para utilizarlas posteriormente. Una vez que se han completado las listas de consenso, el equipo se divide en subequipos; cada uno trabaja para desarrollar una mini-especificación de una o más entradas de cada lista. La mini-especificación es una elaboración de la palabra o frase contenida en una lista. Por ejemplo, la mini-especificación del objeto panel de control de HogarSeguro podría ser: montado en la pared; tamaño aproximado 23 * 13 centímetros; contiene el teclado estándar de 12 teclas y teclas especiales;contiene una pantalla LCD de la forma mostrada en el bosquejo (no presentado aquí); toda la interacción del cliente se hace a través de las teclas usadas para activar o desactivar el sistema; software para proporcionar una directriz de empleo, recordatorios, etc., conectado a todos los sensores. Cada subequipo presenta entonces sus mini-especificaciones a todos los asistentesTFEA para estudiarlas. Se realizan nuevos añadidos, eliminaciones y se sigue elaborando. En algunos casos, el desarrollo de algunas mini-especificaciones descubrirá nuevos objetos, servicios, restricciones o requisitos de rendimiento que se añadirán a las listas originales. Durante todos los estudios, el equipo sacará a relucir aspectos que no podrán resolverse durante la reunión. Se hará una lista de estas ideas para tratarlas más adelante. Una vez que se han completado las mini-especificaciones, cada asistente de la TFEA hace una lista de criterios de validación del producto/sistema y presenta su lista al equipo. Se crea así una lista de consenso de criterios de validación. Finalmente, uno o más participantes (o algún tercero) es asignado para escribir el borrador entero de especificación con todo lo expuesto en la reunión TFEA. TFEA no es la panacea para los problemas que se encuentran en las primeras reuniones de requisitos, pero el enfoque de equipo proporciona las ventajas de muchos puntos de vista, estudio y refinamiento instantáneo y un paso adelante hacia el desarrollo de una especificación. Problemas con la educción Entre los principales problemas que pueden entorpecer la tarea de la educción de requisitos se cuentan los siguientes: • Los usuarios no pueden /saben describir sus tareas • Mucha información importante no llega a verbalizarse • La educción se afronta como un proceso pasivo, cuando debería ser un proceso cooperativo. nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 10 ¿Cómo escribir requisitos? Y se ha mencionado que los requisitos constituyen la base de la comunicación entre todas las partes interesadas en el desarrollo del sistema: usuarios, clientes, desarrolladores y el equipo encargado de realizar las pruebas. Todas estas personas forman un conjunto heterogéneo, lo cual provoca que “la mejor forma” de escribir requisitos no exista. Lo que para unos puede ser un lenguaje muy preciso, para otros puede ser un lenguaje incomprensible. Debido a esto en la práctica, lo más utilizado es el lenguaje natural a pesar de su inherente ambigüedad. Se acostumbra a especificar cada requisito como una frase corta (“el sistema hará X…”, “se facilitará X…”, etc.). También se utiliza el lenguaje natural complementado con diagramas y/o notaciones formales. La notación utilizada depende de quien leerá o quien escribirá los requisitos. Ejemplos: 1. El sistema mantendrá la temperatura de la caldera entre 70 y 80 grados 2. El sistema mantendrá un registro de todos los materiales de la biblioteca, incluyendo libros, periódicos, revistas, videos y CDRoms. 3. El sistema permitirá a los usuarios realizar una búsqueda por título, autor o ISBN. 4. La interface de usuario se implementará sobre un navegador Web. 5. El sistema deberá soportar al menos 20 transacciones por segundo 6. El sistema permitirá que los nuevos usuarios se familiaricen con su uso en menos de 15 minutos Aquí puede verse que los requisitos son de muy distintos tipos: • Requisitos que definen efectos sobre el entorno (1) • Requisitos muy generales • Requisitos funcionales (3) • Requisitos de implementación (4) • Requisitos de rendimiento (5) • Requisitos de usabilidad (6) Debido a que hay tantos tipos distintos de requisitos, no es posible establecer una forma estándar de escribirlos. Tampoco es posible decir cuál es la “mejor forma” de especificarlos. Todo depende de quien los escribe, quién los va a leer, el dominio de la aplicación, etc. Requisitos en negativo Tan importante como decir lo que el sistema debe hacer, es decir lo que el sistema NO debe hacer. Estos requisitos “en negativo” limitan el ámbito del sistema. Las razones son varias: • En primer lugar, dicen donde NO se deben emplear recursos • Por otro lado, especificar lo que el sistema no hará es fundamental para sistemas críticos (es decir, sistemas en los que un fallo puede provocar un accidente). Se trata de especificar cómo el sistema evitará la aparición de situaciones potencialmente peligrosas. Requisitos Funcionales y No Funcionales Los requisitos funcionales describen los servicios (funciones) que se esperan del sistema. Por ejemplo: “El sistema aceptará pagos con VISA” Los requisitos funcionales son restricciones sobre los requisitos funcionales. Por ejemplo:”El Sistema aceptará pagos con VISA de forma segura y con tiempo de respuesta menor a 5 segundos.” Pero el siguiente, muchas veces resulta arbitrario: “”El Sistema aceptará pagos con VISA a través del protocolo SET”. En este caso, lo que aparentemente es un requisito funcional, está determinado, en el nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 11 fondo por una serie de características no funcionales (características que hacen que el protocolo SET sea el más adecuado para los objetivos perseguidos). Modelización de requisitos Ciertos aspectos de los requisitos se expresan mediante modelos de datos, de control, de estados, de interacción, de objetos, etc. La meta es entender mejor el problema, más que iniciar el diseño de la solución (idealmente). El tipo de modelo elegido depende de: • La naturaleza del problema • La experiencia del modelizador • La disponibilidad de herramientas • La imposición del cliente de una notación determinada. Negociación de Requisitos En todo proceso de IR intervienen distintos individuos con distintos, y a veces enfrentados intereses. Estos conflictos entre requisitos se descubren durante el análisis. Todo conflicto descubierto debería disparar un proceso de (re)negociación, es decir, los conflictos nunca se deben resolver “por decreto”. Desde este punto de vista, los conflictos son positivos, pues son fuente de NUEVOS REQUISITOS. Los acuerdos alcanzados deben ser convenientemente anotados, favoreciéndose asi la trazabilidad de los requisitos a sus orígenes (“el requisito 987 surge como resultado de la reunión entre X y Z el día tal…”) Documento de Requisitos El llamado “Documento de Requisitos” es el modo habitual de guardar y comunicar los requisitos. Debe tenerse en cuenta que al decir “documento”, nos referimos a cualquier medio electrónico de almacenamiento y distribución de información como por ejemplo: • Procesador de textos • Bases de datos • Herramientas de Gestión de Requisitos En general, es buena práctica utilizar, al menos dos documentos, a distinto nivel de detalle: 1. DRU: Documento de Requisitos de Usuario 2. ERS: Especificacion de Requisitos de Software La pregunta que surge es: En que se diferencian los requisitos de usuario de los requisitos de software? A grandes rasgos se puede afirmar que: • El DRU se escribe desde el punto de vista del usuario/cliente/interesado. Normalmente los requisitos de usuario, contenidos en el DRU, no poseen demasiado nivelde detalle. Se incluye la descripción del problema actual (razones por las que el sistema de trabajo actual es insatisfactorio) y las metas que se espera lograr con la construcción del nuevo sistema. • La ERS desarrolla mucho más los contenidos de la DRU. Los requisitos del software contenidos en la ERS son más detallados. Contiene la respuesta a la pregunta ¿Qué características debe poseer un sistema que nos permita alcanzar los objetivos y evitar los problemas expuestos en la DRU? Estándares Los documentos estándares más conocidos de especificación de requisitos son: • IEEE 830 nicoj Resaltar Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 12 • PSS-05 de la Agencia Espacial Europea (ESA). Las herramientas de gestión de requisitos permiten generar documentación en los anteriores formatos, a partir de una base de datos de requisitos Características deseables de una ERS Una ERS de calidad debería presentar, dentro de lo posible, las siguientes características: • No ambigua: la ERS es no ambigua si todo requisito posee una sola interpretación. • Completa: Una ERS es completa si todo lo que se supone que el software debe hacer está incluido en la ERS. Por completitud, deberían describirse todas las posibles respuestas a todas las posibles entradas y en todas las situaciones posibles. Además, la ERS no contendrá secciones de tipo “por determinar…” • Correcta: todo requisito de la ERS contribuye a satisfacer una necesidad real • Comprensible: todo tipo de lectores (clientes, usuarios, desarrolladores, equipo de pruebas, gestores, etc) entienden la ERS • Verificable: si para cada requisito expresado en la ERS existe un procedimiento de prueba finito y no costoso para demostrar que el futuro sistema lo satisface • Internamente Consistente: no existen subconjuntos de requisitos contradictorios • Externamente Consistente: ninguno de los requisitos está en contradicción con lo expresado en documentos de nivel superior. Por ejemplo los requisitos del software no pueden contradecir los requisitos del sistema. • Realizable: si dados los actuales recursos la ERS es implementable • Concisa: la ERS debe ser lo más breve posible, sin que esto afecte al resto de atributos de calidad • Independiente del Diseño: existen más de un diseño e implementación que realizan la ERS. Para ello la ERS debiera limitarse a describir el comportamiento externo del sistema. • Trazable: cada requisito se puede referenciar de forma unívoca. Es fundamental para precisar qué requisitos son implementados por que componente del diseño, lo cual es imprescindible a la hora de realizar las pruebas de dicho componente. • Modificable: los cambios son fáciles de introducir • Electrónicamente almacenada: se encuentra en un archivo de texto, en una base de datos o, mejor aún, ha sido creada con una herramienta de Gestión de Requisitos (RequisitePro, Doors, etc) • Ejecutable/Interpretable/Prototipable/Animable: si existe una herramienta software que, recibiendo como entrada la ERS, realice un modelo ejecutable de la misma. Aplicable tan solo a ciertas notaciones como las notaciones formales o los diagramas de transición de estados. • Anotada por importancia relativa: si los requisitos se clasifican según su importancia. Como mínimo un requisito puede ser “Obligatorio, Deseable u Opcional”. Esto sire para no asignar demasiados recursos a la implementación de requisitos no esenciales. • Anotada por estabilidad relativa: los requisitos son, en general, inestables y volátiles. A cada requisito se le asigna una probabilidad de cambio (Alta, Media o Baja). • Anotada por versión: si un lector de la ERS puede determinar qué requisitos serán satisfechos por qué versión del producto. • No redundante: cada requisito se expresa en un solo lugar de la ERS. La redundancia de todas formas, no es del todo mala si aumenta la legibilidad • Nivel de Abstracción: al nivel adecuado, ni demasiado detallada ni demasiado vaga • Precisa: una ERS es precisa si hace uso de valores numéricos para precisar características del sistema. La precisión es aplicable, ante todo, a los requisitos no funcionales. Por ejemplo, no es útil decir: ¡“el tiempo de respuesta será más bien rápido!, sino “El tiempo de Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 13 respuesta será menor a dos segundos” (esto es fuertemente dependiente de la tecnología disponible, que no siempre se conoce al principio del proyecto). • Reutilizable: si ciertas secciones de la ERS se pueden reutilizar • Trazada: sin está claro el origen de cada requisito (quien o que pide) • Con referencias cruzadas: si se utilizan referencias entre requisitos relacionados o entre otras secciones Para lograr los objetivos y resultados anteriormente descritos, será necesario el seguimiento de un proceso estructurado que finalizará con la elaboración y verificación de los artefactos de salida descritos a continuación: • Documento de definición de Actores del Sistema • Documento de Casos de Uso del Sistema • Documento de Especificación Detallada de Casos de Uso • Documento de definición de Requerimientos No Funcionales. 1. Criterios de inicio o criterios de entrada Este proceso se inicia luego de la aprobación del Acta de Inicio del proyecto para el desarrollo del Sistema para el seguimiento de la gestión de proyectos de Software. Adicionalmente se cuenta con el enunciado general de requerimientos del proyecto, a partir del cual se desarrollará el proceso de especificación. También se realiza la definición de las diferentes plantillas para los documentos de actores, casos de uso y especificación detallada, y se definen los ítems incluidos en el documento de requerimientos no funcionales. 2. Objetivo del proceso El objetivo principal del proceso de especificación es lograr definir de forma clara y precisa cada uno de los requerimientos del Sistema para el seguimiento de la gestión de proyectos de desarrollo de Software. El seguimiento adecuado del proceso además nos permitirá: • Disminuir el número de defectos encontrados en la fase de implementación del producto de software. • Realizar la fase de implementación de forma ágil y con la seguridad de estar desarrollando exactamente las necesidades del cliente. • Lograr un dimensionamiento adecuado del tamaño del sistema. Como resultado final del proceso de especificación deben quedar elaborados, validados y verificados los siguientes entregables: • Documento de definición de Actores del Sistema • Documento de Casos de Uso del Sistema • Documento de Especificación Detallada de Casos de Uso • Documento de definición de Requerimientos No Funcionales 3. Responsables del Proceso El proceso de especificación será desarrollado conjuntamente por todo el equipo de trabajo, realizando una distribución equitativa de cargas de trabajo. El proceso estará dirigido por el líder del proyecto y el aseguramiento de la calidad estará a cargo del Líder de Calidad. 4. Entradas Las siguientes son las actividades que se deben ejecutar durante el proceso de Especificación de Requerimientos • Enunciado del trabajo del Proyecto: El enunciado del trabajo es la entrada que describe la oportunidad o necesidad de negocio que la organización ha identificado y por la cual se dio origen al proyecto. Adicionalmente, indica el alcance Universidad Nacional de Jujuy-Facultad de IngenieríaSistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 14 y los requisitos del producto los cuales servirán de apoyo para los procesos posteriores principalmente al proceso de planeación. • Acta de constitución: El acta de constitución, contiene información de los objetivos, alcance, restricciones y demás, que se deben tener en cuenta para la planeación del proyecto. • Formatos establecidos para la especificación: Son las plantillas definidas para construir los documentos involucrados en este proceso. Las plantillas son: o Plantilla de Actores del Sistema: En esta plantilla se realizará la descripción de los actores que interactúan con el sistema. Para esto se utilizará el formato ESPECIFICACION_ACTORES_SISTEMA.doc o Plantilla de especificación de requerimientos funcionales: En esta plantilla se especifica de forma detallada el formato de cada uno de los casos de uso que componen el sistema. Para esto se propone el formato ESPECIFICACION_DETALLADA_CASO_USO.doc o Documento de especificación de requerimientos no funcionales: En este documento se especificarán los requerimientos no funcionales del sistema Este documento contará con las siguientes secciones: REQUERIMIENTOS NO FUNCIONALES MANIFIESTOS. Desempeño Disponibilidad Usabilidad REQUERIMIENTOS NO FUNCIONALES OPERACIONALES Robustez Escalabilidad Seguridad Interoperabilidad REQUERIMIENTOS NO FUNCIONALES DE DESARROLLO Base De Datos Servidor Web De Aplicaciones Navegador Web Máquina Virtual De Java 5. Actividades Las siguientes son las actividades que se deben ejecutar durante el proceso de Especificación de Requerimientos. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 15 6.Identificación de los Requerimientos No Funcionales del Sistema Enunciado del proyecto Formatos Establecidos para Especificación Documento de Especificación de Requerimientos No Funcionales Acta de Constitrución 3.Identificación de módulos del sistema y / o Procesos de Negocio 1.Análisis inicial del mundo del Sistema. Documento de Especificación de Módulos del Sistema 4.Identificación de todos los Actores que componen el Sistema 5.Identificación detallada de Casos de Uso del Sistema Documento de Casos de Uso del Sistema 6.Especificación detallada de Requerimientos Documento de Actores del Sistema Documento de Especificación detallada de Casos de Uso Acta de Aprobación de la Especificación 2.Identificación general de los Requerimientos Funcionales del Sistema Administración de Requerimientos (Controles de Cambios) Figura. 1 Diagrama Actividades Proceso de Especificación de Requerimientos Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 16 • Análisis del mundo del sistema a. Descripción: Realizar un análisis preliminar del mundo del sistema.. b. Resultado: Descripción del mundo del sistema. c. Responsable: Líder del Proyecto d. Participantes: Líder de Soporte. • Identificación de Módulos del Sistema y/o Procesos de Negocio a. Descripción: Identificar los módulos que conforman el sistema y elaborar el documento que los describe. b. Resultado: Documento de Módulos del Sistema c. Responsable: Líder del Proyecto d. Participantes: Líder de Soporte. • Identificación de todos los actores que componen el Sistema a. Descripción: Identificar los actores que intervienen en el sistema y elaborar el correspondiente Documento de Actores del Sistema b. Resultado: Documento de Actores del Sistema c. Responsable: Líder del Proyecto d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto. • Identificación de Casos de Uso del Sistema a. Descripción: Identificar los casos de Uso que componen el Sistema y elaborar el respectivo documento. b. Resultado: Elaboración del documento de Casos de Uso del Sistema. c. Responsable: Líder del Proyecto d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto • Especificación detallada de Requerimientos Funcionales a. Descripción: Elaboración de los documentos de especificación detallada de Casos de Uso. b. Resultado: Documento de Especificación detallada de Casos de Uso. c. Responsable: Líder del Proyecto d. Participantes: Líder de Desarrollo, Líder de Soporte, Líder del Proyecto • Especificación de Requerimientos No Funcionales a. Descripción: Elaboración del Documento de Especificación de Requerimientos No Funcionales del Sistema. b. Resultado: Documento de Especificación de Documentos No Funcionales del Sistema c. Responsable: Líder de Desarrollo • Acta de Aprobación a. Descripción: En este documento se aprueba por parte del Cliente (Profesor y Monitor) y por parte del Equipo de Trabajo el proceso de especificación de requerimientos del Sistema. b. Resultado: Acta de Aprobación de la Especificación del Sistema, firmada por el Cliente y por el equipo de trabajo. c. Responsable: Líder del Proyecto. d. Participantes: Líder del Proyecto, Profesor, Monitor • Administración de Requerimientos a. Descripción: En este documento se hace el seguimiento sobre el control de cambios realizado sobre la especificación de requerimientos. Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 17 e. Resultado: Documento de Administración de Requerimientos.. f. Responsable: Líder del Proyecto. g. Participantes: Líder del Proyecto, Líder de Calidad 6. Salidas Las siguientes son las salidas del proceso de Especificación de Requerimientos. • Documento de Especificación de Módulos del Sistema: En este documento se identifican los módulos que componen el Sistema de Información y se da una descripción de cada uno de ellos, indicando sus características y principales responsabilidades. • Documento de Especificación de Requerimientos Funcionales: En este documento se especifica de forma detallada cada uno de los casos de uso que componen el sistema. • Documento de Requerimientos No Funcionales del Sistema: En este documento se especificarán los requerimientos no funcionales del sistema. 7. Criterios de terminación del proceso El proceso finaliza una vez se hayan ejecutado todas las actividades definidas y como resultado de la revisión del mismo, se firmará la correspondiente Acta de Aprobación de la Especificación del Sistema. Validación de Requisitos El objetivo de la validación de requisitos es descubrir problemas en el Documento de Requisitos antes de comprometer recursos a su implementación. El documento debe revisarse para: • Descubrir omisiones o falta de requisitos • Conflictos • Ambiguedades • Comprobar la calidad del documento y su grado de adhesión a estándares Revisiones Las revisiones del documento de requisitos constituyen la fórmula más empleada en validación. En estas revisiones, un grupo de personas (incluyendo usuarios) se ocupan de revisar el documento de requisitos. Tiene tres fases: • Busqueda de problemas • Reunión • Establecimiento de acuerdos Como guía paraidentificar problemas habituales, se pueden utilizar listas de comprobación, “checklists”. Otros tipos de validación son: • Prototipado: permite descubrir con rapidez si el usuario se encuentra satisfecho o no con los requisitos • Validación de modelos: cuando los requisitos se expresan por medio de modelos (de objetos, DFD, etc) • Validacion de la “testeabilidad”. El equipo de pruebas debe revisar los requisitos. Un ejemplo de cuestiones que debieran figurar en una lista de comprobación podría ser: • ¿Están todos los requisitos convenientemente numerados? • ¿El mismo servicio es solicitado en distintos requisitos? Existen contradicciones entre ellos? • ¿Los requisitos relacionados se encuentran agrupados en el documento? • ¿Los requisitos son fácilmente comprensibles? Por todo tipo de lectores? Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 18 Gestión de Requisitos (Requirements Management, RM) Consiste básicamente, en gestionar los cambios a los requisitos. Asegura la consistencia entre los requisitos y el sistema construido (o en construcción). Esta tarea consume grandes cantidades de tiempo y esfuerzo y abarca todo el ciclo de vida del producto. Es necesario realizar una adecuada gestión de requisitos por una serie de razones, como: • Los requisitos son volátiles • El entorno físico del sistema cambia • Trasladar un sistema de un entrono a otro requiere modificaciones • El entorno organizacional cambia • Las políticas cambian • Cambios en las reglas y en los procesos del negocio provocan cambios en el sistema • La propia existencia del sistema va a generar nuevos requisitos por parte de los usuarios La Gestión de Requisitos implica: • Definir procedimientos de cambios: definen los pasos y los análisis que se realizarán antes de aceptar los cambios propuestos. • Cambiar los atributos de los requisitos afectados • Mantener la trazabilidad hacia atrás, hacia adelante y entre requisitos • Control de versiones del documento de requisitos Existen herramientas que han sido desarrolladas específicamente para utilizarlas en las técnicas de gestión de requisitos y dominar cualquier tarea asociada con los requisitos. El uso de este tipo de herramientas permite mejorar la calidad del desarrollo de un proyecto, automatizar procesos de la Ingeniería de Requisitos, proporcionar un mayor control en el mantenimiento de los requisitos y añadir un beneficio significativo reduciendo posibles errores durante el desarrollo de un proyecto, lo que implica en una reducción de costes. Para facilitarnos la difícil tarea de seleccionar una herramienta de gestión de requisitos adecuada, podemos hacer uso de la norma ISO 24766 (Information Technology – Guide for requirements tool capabilites), la cual proporciona una orientación sobre las capacidades deseables que debería aportar una herramienta de Ingeniería de Requisitos. Herramientas Software para la Gestion de Requisitos, consultar: https://www.appvizer.es/organizacion- planificacion/gestion-requerimientos http://www.overti.es/tecnologia/283-normas-y-estandares-para-gestion-de-requisitos https://www.appvizer.es/organizacion-planificacion/gestion-requerimientos https://www.appvizer.es/organizacion-planificacion/gestion-requerimientos Universidad Nacional de Jujuy-Facultad de Ingeniería Sistemas de Información- Sistemas de Información I Prof. Lic. Analía N. Herrera Cognetta 19 Bibliografía ROGER PRESSMAN “Ingeniería del software” 5ª edición. ANDRES SILVA, “Documentación Master en Ingenieria del Software”. UPM, 2000 KOVITZ B. L., “Practical Software Requirements. A Manual 01 Content and Style”. Manning 1999
Compartir