Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

INGENIERÍA DE REQUISITOS

No description
by

Jorge Guadarrama

on 9 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of INGENIERÍA DE REQUISITOS

INGENIERÍA DE REQUISITOS
UNIDAD 2
INGENIERIA DE REQUISITOS

2.1 Tareas de la Ingeníeria
de Requisitos
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISTOS
ENTREVISTAS Y CUESTIONARIOS
SISTEMAS EXISTENTES
LLUVIA DE IDEAS
PROTOTIPOS
CASOS DE USO
2.3 MODELADO DE REQUISITOS
El modelo de requisitos tiene como objetivo delimitar el sistema y capturar la funcionalidad que debe ofrecer desde la perspectiva del usuario. Este modelo puede funcionar como un contrato entre el desarrollador y el cliente o usuario del sistema, y por lo tanto proyecta lo que el cliente desea según la percepción del desarrollador. Por lo tanto, es esencial que los clientes puedan comprender este modelo.
2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS
Hasta hace poco tiempo 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
2.1 TAREAS DE LA INGENIERÍA DE REQUISITOS
2.2 TÉCNICAS DE LA INGENIERÍA DE REQUISTOS
2.3 MODELADO DE REQUISITOS
2.4 HERRAMIENTAS CASE PARA LA INGENIERÍA DE REQUISITOS

Tiene por objetivo identificar el ámbito del proyecto general. Comienza con una serie de conversaciones informales entre los participantes del mismo. Esta fase suele ser acompañada de los documentos de definición de la visión global y la visión del dominio del sistema. Se inicia muchas veces por: se descubre un nuevo mercado y se descubre un nuevo servicio.

INICIO
Se sugiere a los ingenieros recopilar requisitos de manera organizada, preguntando a los usuarios y otros interesados cuales son os objetivos para el sistema o producto, que es lo que se debe lograr, de que forma el producto satisface las necesidades del negocio y como se utilizara el producto día d día. Se identifican una serie de problemas que ayudan a entender porque es difícil la obtención de requisitos:
Problema de ámbito
Problema de comprensión
Problemas de volatilidad

OBTENCIÓN
ESPECIFICACIÓN
Es el producto final de la ingeniería de requisitos, y se convierte en la materia prima para las actividades posteriores en el proceso de desarrollo del sistema. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, una colección de escenarios de uso, un prototipo o cualquier combinación de estos.
NEGOCIACIÓN
En esta etapa el ingeniero de requisitos debe negociar con el cliente los alcances y límites del sistema. De forma iterativa los requisitos se prioriza, modifican, combinan o eliminan buscando acuerdos que beneficien a todas las partes. Se identifican y analizan los riesgos asociados con cada requisito.
ELABORACIÓN
Se crea un modelo de análisis con la información obtenida del cliente en las fases de inicio y obtención. La información conseguida con el cliente durante el inicio y obtención se expande y se refina durante la elaboración. Esta actividad se enfoca en el desarrollo de un modelo técnico refinado de las funciones, características y restricciones del software. La elaboración se conduce mediante la creación y refinamiento de escenarios del usuario que describan la forma en que el usuario final y otros actores interactúan con el sistema.
Se define como un conjunto de actividades en los cuales, utilizando técnicas y herramientas, se analiza un problema y se concluye con la especificación de una solución. La ingeniería de requisitos es el proceso de desarrollar una especificación de software.
VALIDACIÓN
La validación de requisitos examina la especificación para asegurar que todos los requisitos de software se han establecidos de manera precisa; que se han detectado las inconsistencias omisiones y errores y que estos han sido corregidos y que el producto de trabajo cumple con los estándares establecidos para el proceso, proyecto y producto.
GESTIÓN DE REQUISITOS
Ayuda a rastrear los requisitos según las características de los mismos, el código fuente relacionado, dependencia entre requisitos, subsistemas e interfaces internas y externas de forma que pueda identificarse con rapidez para entender como afectara una modificación diferentes aspectos del sistema a construir. Es un conjunto de actividades que ayudan al equipo de proyecto a identificar, controlar y rastrear los requisitos y los cambios a estos en cualquier momento mientras se desarrolla el proyecto.
Extracción, Análisis y Especificación
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.

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.

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

ENTREVISTAS Y CUESTIONARIOS
Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.
Por lo común, 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. El éxito de esta técnica, depende de la habilidad del entrevistador y de su preparación para la misma.

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.
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.
PROTOTIPOS
Los prototipos son Simulaciones del posible producto, que luego son utilizados por el usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema diseñado con base a los requerimientos recolectados le permite al usuario realizar su trabajo de manera eficiente y efectiva.
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.
CASOS DE USO
Los casos de uso son una técnica para especificar el comportamiento de un sistema.
Los casos de uso permiten entonces describir la posible secuencia de interacciones entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de un actor, es una descripción de un conjunto de escenarios, cada uno de ellos comenzado con un evento inicial desde un actor hacia el sistema
Requisitos y Análisis
a) Requisitos:
El modelo de casos de uso sirve para expresar el modelo de requisitos, el cual se desarrolla en cooperación con otros modelos como se verá más adelante.

b) Análisis:
La funcionalidad especificada por el modelo de casos de uso se estructura en el modelo de análisis, que es estable con respecto a cambios, siendo un modelo lógico independiente del ambiente de implementación.

Diseño e Implementación
c) Diseño:
La funcionalidad de los casos de uso ya estructurada por el análisis es realizada por el modelo de diseño, adaptándose al ambiente de implementación real y refinándose aún más.

d) Implementación:
Los casos de uso son implementados mediante el código fuente en el modelo de implementación.

Pruebas y Documentación
e) Pruebas:
Los casos de uso son probados a través de las pruebas de componentes y pruebas de integración.

f) Documentación:
El modelo de casos de uso debe ser documentado a lo largo de las diversas actividades, dando lugar a distintos documentos como los manuales de usuario, manuales de administración, etc.

IRQA
Herramienta CASE de Ingeniería de Requisitos, diseñada para soportar las actividades realizadas en el proceso de especificación de sistemas. Ésta facilita y formaliza la comunicación entre el cliente, el proveedor y los distintos miembros del equipo de desarrollo. 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.
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.
CONTROLA
Ofrece recursos importantes tales como: Administración de requisitos, administración de casos de uso, administración de casos de prueba y error, planeamiento de liberaciones, administración de implementaciones, control de dependencia entre Implementaciones, matriz de rastreabilidad y rastreabilidad de los requisitos.
INTEGRANTES
Solis Cebrero Heilli Sak-nicte Hernandez Simon Marlen
Rodriguez Castillo Guadalupe Alheli
Ortiz Ferrer Yissell Alejandra
Guadarrama Arteaga Jorge Gerardo
Full transcript