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

2.2. Técnicas de la Ingeniería de Requisitos

No description
by

John gallegos

on 10 August 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of 2.2. Técnicas de la Ingeniería de Requisitos

INSTITUTO TECNOLÓGICO SUPERIOR DE JEREZ

MATERIA: Fundamentos de Ingeniería de software

MAESTRO: Hailer de Rene de la Cruz Castañeda .

Alumno: Juan Francisco Gallegos Olivares

Numero de control : 11070008

CARRERA: Ingeniería en sistemas computacionales.

MÓDULO: X

TEMA: TECNICAS DE LA INGENIERIA DE REQUISITOS

JEREZ 10 DE AGOSTO DEL AÑO 2013.
Se documentan los requisitos acordados con el cliente en un nivel apropiado de detalle. En la práctica esta actividad se va realizando conjuntamente con el análisis.

Se pude decir que la especificación es el “pasar en limpio ” el análisis realizado previamente aplicando técnicas o estándares de documentación como UML "EL LENGUAJE UNIFICADO DE MODELADO".


Especificación

Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requerimiento.



Ingeniería de Requisitos

Un requisito es una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo [IEEE]"Instituto de Ingenieros Eléctricos y Electrónicos"

Una condición o capacidad que debe ser atendida por el sistema [RUP]"Proceso Unificado de Racional".

Algo que el sistema debe hacer o una cualidad que el sistema debe poseer [Robertson – Robertson].


¿Qué son los requisitos?

Los requisitos de software
Ingeniería de requisitos
Técnicas de ingeniería de requisitos


La notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML y fue avalada por las principales empresas que desarrollan software en el mundo.
La mejor forma de empezar a entender un sistema es a partir de los servicios o funciones que ofrece a su entorno

Los Casos de Uso y UML

Un ejemplo de caso de uso

Nombre: Orden de pedido

Precondición: un usuario válido está conectado al sistema

Descripción: El caso de uso comienza con un pedido del cliente
El cliente entra su nombre y dirección. Si el cliente entra solo el código postal, el sistema debe agregar la ciudad y la provincia.

El cliente entrará todos los código de los productos deseados y la cantidad solicitada.
El sistema indicará el nombre del producto y el precio unitario del mismo
El sistema totalizará la cantidad de productos pedidos y el total de la venta.
El cliente indicará la forma de pago, si es tarjeta el número de la misma
El cliente apretará la tecla enviar.
El sistema verificará la información, guardará la orden de pedido como pendiente y la forma de pago.

Una vez confirmado el pago, la orden se cambiará a confirmada y se le indica esto al cliente, el caso de uso finaliza
Excepciones: En el paso 9, si hay información incorrecta, el sistema le preguntará al cliente que quiso poner
Post condiciones: La orden fue salvada en el sistema y fue marcada como confirmada

Un ejemplo de caso de uso

Dibujar los límites

Identificar los actores fuera de los límites del sistema que interactúan con él
Para cada actor
Identificar los posibles casos de uso
Establecer escenarios concretos para ilustrar cada caso de uso
Agrupar escenarios similares en casos de uso si son una variación sobre un tema

Usando casos de Uso

Ventajas y desventajas

Caracterización detallada de todas las posibles interacciones con el sistema
Ayuda en el dibujo de los límites del sistema, y con el alcance de los requerimientos
Los casos de uso no captura en dominio del conocimiento
Un caso de uso no es especificación precisa, solo es la representación de un problema puntual



Casos de Uso

Casos de Uso

Los Casos de Uso facilitan la elicitación de requisitos y son fácilmente comprensibles por los clientes y usuarios.
Sirven de base a las pruebas del sistema y a la documentación para los usuarios.
Los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema
Se escriben, generalmente, en lenguaje natural
No hay descripción interna del sistema, solo la interacción con el mismo



Los casos de uso son una técnica para la especificación de requerimientos funcionales propuesta inicialmente en por Jacobson y actualmente forma parte de la propuesta de UML [Booch99].
Una descripción de una secuencia de acciones que el sistema debe llevar a cabo para obtener un resultado observable para un actor particular [Booch]
Un caso de uso es la descripción de una secuencia de interacciones entre el sistema y uno o más actores en la que se considera al sistema como una caja negra.
Los actores son personas u otros sistemas que interactúan con el sistema cuyos requerimientos se están describiendo. Un actor puede participar en varios casos de uso y un caso de uso puede estar relacionado con varios actores

Casos de Uso

Fases del brainstorming

Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos:
Revisar ideas: se revisan para clarificarlas
Descartar ideas.
Priorizar ideas.
Documentación: el jefe produce la documentación oportuna conteniendo las ideas priorizadas y comentarios generados durante la consolidación.


Preparación
Selección de participantes
Preparación logística
Generación
Jefe de proyecto expone un enunciado general del problema , que hace de semilla para que se generen ideas.
Los participantes generan nuevas ideas de forma aleatoria
Reglas
Se prohíbe la critica de ideas
Se fomentan las ideas más avanzadas y se estimula a los participantes a generar nuevas ideas
Se debe generar un gran número de ideas,
Se debe alentar a los participantes a combinar o completar las ideas de otros participantes


Fases del brainstorming

El brainstorming o tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios [Raghavan].
Las sesiones de brainstorming formadas de cuatro a diez participantes, uno de los cuales es el jefe de la sesión.


Brainstorming

Entrevistas


Realización de entrevistas: se distinguen tres etapas [Piattini]:
Apertura
Desarrollo
Terminación
Análisis de las entrevistas
Reorganizar la información, contrastarla con otras entrevistas o fuentes de información.
Validar con el entrevistado para confirmar los contenidos.

Entrevistas


Preparación de entrevistas: Las entrevistas no deben improvisar se, por lo que conviene realizar las siguiente tareas previas:
Estudiar el dominio del problema
Seleccionar a las personas a las que se va a entrevistar (top–down)
Determinar el objetivo y contenido de las entrevistas
Planificar las entrevistas

Las entrevistas son la técnica de e licitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo.
En las entrevistas se pueden identificar claramente tres fases [Piattini]: preparación, realización y análisis

Entrevistas


Técnicas de ingeniería de Requisitos

Con los anteriores problemas, se han desarrollado numerosas técnicas para tratar de superarlos
Cada técnica puede aplicarse en una o más actividades de la ingeniería de requerimientos; en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

Técnicas de ingeniería de Requisitos

Normalmente clientes y analistas se enfrascan en el proyecto de forma unilateral y no en equipo. Cada parte define su propio “territorio”
Este enfoque no es muy efectivo, abundan los malentendidos, se pierde información importante y nunca se establece una relación de trabajo satisfactoria.

Técnicas de ingeniería de Requisitos

Antes de mantener las reuniones con los clientes y usuarios e identificar los requisitos es fundamental conocer el dominio del problema.

Mantener reuniones con clientes y usuarios sin conocer las características de su actividad hará que probablemente no se entiendan sus necesidades.

Para conocer el dominio del problema se puede obtener información de fuentes externas al negocio del cliente

El análisis de requisitos siempre comienza con una comunicación entre dos o más partes.
Un cliente tiene un problema al que puede encontrar una solución basada en computadora.

El desarrollador responde a la petición del cliente. La comunicación ha comenzado. Pero, el camino entre la comunicación y el entendimiento está lleno de baches.

Técnicas de ingeniería de Requisitos

La validación es la actividad que certifica que el modelo de los requisitos es consistente con las intenciones de los clientes y los usuarios.

Se verifica que los requisitos sean consistentes y que estén completos

Validación

Se trabaja sobre la base de la anterior actividad.

Actividad la cual se enfoca a descubrir problemas con los requisitos del sistema identificados hasta el momento.

Por lo general se hace un análisis luego de haber producido un bosquejo inicial del documento de requisitos.

Se conceptúan los requisitos, se investigan, se intercambian ideas con el resto del equipo, se resaltan los problemas, se buscan alternativas y soluciones



Análisis

Permite gestionar las necesidades del proyecto en forma estructurada.

Mejora la capacidad de predecir cronogramas de los proyectos, así como sus resultados.

Disminuye los costos y retrasos del proyecto
Mejora la calidad del software
Mejora la comunicación entre equipos
Evita rechazos de los usuarios finales

Importancia de la ingeniería de Requisitos

Ingeniería de Requisitos ayuda a los ingenieros de software a entender mejor el problema en cuya solución trabajarán.

Incluye el conjunto de tareas que conducen a comprender cuál será el impacto del software sobre el negocio, qué es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software. [Pressman]

Ingeniería de Requisitos

Características de un Requisito

Completo: Un requisito es completo si no necesita ampliar detalles en su redacción, es decir se proporciona la información suficiente para su comprensión

Consistente: Un requisito es consistente si no es contradictorio con otro requisito
No ambiguo: Un requisito no es ambiguo cuando tienen una sola interpretación . El lenguaje usado en su definición no debe causar confusión al lector.


Especificado por escrito: como todo contrato o acuerdo entre dos partes.


Conciso: un requisito es conciso si es fácil de leer y entender. Su redacción debe ser simple para las personas que lo vayan a consultar en el futuro.

Características de un Requisito

Delimitan las condiciones en que el sistema presta servicios a los usuarios
Velocidad de respuesta
Ancho de banda requerido
Espacio en memoria o en disco
....

Requisitos no funcionales

Definen lo que el sistema tiene que hacer, los servicios que debe proporcionar al usuario
Describen la funcionalidad del sistema

Requisitos funcionales

Los usuarios no saben lo que quieren.
Un sistema tiene muchos usuarios y ninguno tiene una visión de conjunto.
No saben cómo hacer más eficiente la operación en su conjunto
No saben qué partes de su trabajo pueden transformarse en software.
No saben detallar lo que saben de forma precisa.

Problemas

Técnicas de la Ingeniería de Requisitos

Usando casos de Uso

Para cada caso de uso

Escribirlo
Especificar reglas para elección del mismo y para interactuar con él
Considerar alternativas
Ver posibles superposiciones de casos de uso

Template de caso de uso:
Nombre:
Resumen:
Actores:
Precondiciones:
Descripciones:
Excepciones:
Postcondiciones:

Elicitación de requisitos
Full transcript