INGENIERÍA DE REQUISITOS Unidad 2 Integrantes equipo Morales Balderas josefina Reyes Larios María Fernanda Heredia palma Andrea Valencia Carrión Alina.

Presentación del tema: "INGENIERÍA DE REQUISITOS Unidad 2 Integrantes equipo Morales Balderas josefina Reyes Larios María Fernanda Heredia palma Andrea Valencia Carrión Alina."— Transcripción de la presentación:

1 INGENIERÍA DE REQUISITOS Unidad 2 Integrantes equipo Morales Balderas josefina Reyes Larios María Fernanda Heredia palma Andrea Valencia Carrión Alina Acevedo Hernández Pedro Iván

2 2.1. TAREAS DE LA INGENIERÍA DE REQUISITOS La Ingeniería de Requisitos (IR) cumple un papel primordial en el proceso de producción de software, ya que se enfoca un área fundamental: la definición de lo que se desea producir.

3 Su principal tarea consiste en la generación de especificaciones correctas que describan con claridad, sin ambigüedades, en forma consistente y compacta, las necesidades de los usuarios o clientes; de esta manera, se pretende minimizar los problemas relacionados por la mala gestión de los requisitos en el desarrollo de sistemas.

4 DEFINICION DE ING. DE REQUISITOS se define, como un conjunto de actividades en las cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución (a veces más de una).

5 ACTIVIDADES DE LA INGENIERÍA DE REQUISITOS:  Extracción: Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente dado a las actividades involucradas en el descubrimiento de los requisitos del sistema.

6  Análisis: Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se enfoca en descubrir problemas con los requisitos del sistema identificados hasta el momento.

7  Especificación: En esta fase se documentan los requisitos acordados con el cliente, en un nivel apropiado de detalle.

8  Validación: La validación es la etapa final de la IR. Su objetivo es, ratificar los requisitos, es decir, verificar todos los requisitos que aparecen en el documento especificado para asegurarse que representan una descripción

9 2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISTOS Entrevistas y Cuestionarios  Las entrevistas y cuestionarios se emplean para reunir información  Durante la entrevista, el analista conversa con el ENCUESTADO; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

10  los ENCUESTADOS son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o empleados que proporcionan datos para el sistema propuesto o que serán afectados por él.

11 SISTEMAS EXISTENTES  Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén relacionados con el sistema a ser construido. Por un lado, podemos analizar las interfaces de usuario, observando el tipo de  Información que se maneja y cómo es manejada, por otro lado también es útil analizar las distintas  Salidas que los sistemas producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre la base de estas.

12 LLUVIA DE IDEAS  Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar la máxima cantidad posible de requerimientos para el sistema. No hay que detenerse en pensar si la idea eso no del todo utilizable. La intención de este ejercicio es generar, en una primera instancia, muchas ideas.

13 PROTOTIPOS  El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores y clientes se reúnen y definen los objetivos globales del software, identifican todos los requerimientos que son conocidos, y señalan áreas en las que será necesaria la profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El diseño rápido se centra en una representación de aquellos aspectos del software que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño rápido lleva a la construcción de un prototipo.

14 2.3 MODELADO DE REQUISITOS  Descripción del Problema La descripción del problema es una descripción muy preliminar de necesidades que sirve únicamente como punto de inicio para comprender los requisitos del sistema. Se trata aquí de simular una descripción preparada por un cliente la cual debe evolucionar por medio del modelo de requisitos para lograr la especificación final del sistema a desarrollarse

15 Modelo de Casos de Uso El modelo de casos de uso describe un sistema en término de sus distintas formas de utilización, cada uno de estas formas es conocida como un caso de uso. Cada caso de uso o flujo se compone de una secuencia de eventos iniciada por el usuario. Dado que los casos de uso describen el sistema a desarrollarse, cambios en los requisitos significarán cambios en los casos de uso.

16 Modelo de Interfaces El modelo de interfaces describe la presentación de información entre los actores y el sistema. Se especifica en detalle cómo se verán las interfaces de usuario al ejecutar cada uno de los casos de uso. Si se trata de InterfazHumano Computadora (“HCI - Human Computer Interface”) se puede usar esquemas de cómo vería el usuario las pantallas cuando se ejecuta cada caso de uso.

17  También se puede generar una simulación más sofisticada usando unSistema Manejador de Interfaces de Usuario (“UIMS - User Interface Management System”). Normalmente, un prototipo funcional de requisitos mostrando las interfaces de usuario es una estrategia importante. Esto ayuda al usuario a visualizar los casos de uso según serán mostrados por el sistema a ser construido. Tal enfoque elimina muchas posibilidades de malos entendimientos.

18 2.4. HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS Las herramientas para la gestión de requisitos de software se limitaban a editores de texto, los cuales hacían de esta tarea una labor tediosa y confusa. Actualmente, se cuenta con múltiples opciones, como las que se mencionan a continuación :

19 IRQA 43 Facilita la captura, organización y análisis de las condiciones, así como la especificación de la solución mediante el apoyo metodológico adaptable a cada cliente.

20 CONTROLA Herramienta de apoyo al proceso de ingeniería de software en pequeñas empresas. Se creó gracias a la expansión que tuvo el mercado y a la generación de grandes y pequeñas empresas, las cuales requieren un instrumento para el desarrollo de sus proyectos.

21 OSRMT (Open Source Requirements Management Tool) Herramienta libre para la gestión de requisitos, cuyas principales características son: trabaja en arquitectura cliente/servidor, desarrollada bajo Java; la versión 1.3 trae un módulo para manejar la trazabilidad y lo introduce para el control de cambios; así mismo, genera la documentación de los requisitos tratados.

22  JEREMIA Se trata exclusivamente de una aplicación cliente, lo cual no permite la posibilidad de trabajar en equipo. Ésta, ayuda durante el desarrollo del sistema, especialmente en el seguimiento de cambios de los requisitos a lo largo del ciclo de vida.

23 RAMBUTAN Esta herramienta está basada en XML, realmente consta de un conjunto de aplicaciones para el usuario final, ayudando a los analistas de sistemas en la recopilación y categorización de hechos en un documento de especificación de requisitos. Lo curioso es que tiene un cliente para palm (PDA), el cual se utiliza para recopilar los hechos en el lugar donde está ubicado el cliente mientras que la aplicación de escritorio recibe la información, edita y perfecciona.