Ingeniería de Requisitos Temario


Tormenta de Ideas (Brainstorming)



Descargar 1,13 Mb.
Página4/14
Fecha de conversión12.01.2017
Tamaño1,13 Mb.
1   2   3   4   5   6   7   8   9   ...   14

Tormenta de Ideas (Brainstorming)

  • Objetivo: Lograr consenso sobre los requisitos
  • Ayuda a la participación de todos los involucrados
  • Permite pensar en otras ideas
  • Un secretario saca notas de todo lo discutido
  • Reglas
    • No se permite criticar ni debatir
    • Dejar volar la imaginación
    • Generar tantas ideas como sea posible
    • Mutar y combinar ideas

Tormenta de Ideas – Fase de Generación

  • Los principales stakeholders se juntan en un cuarto.
  • Se explican las reglas.
  • Se establece el objetivo:
    • ¿Qué características esperan en el producto?
    • ¿Qué servicios esperan que provea?
    • Los objetivos permiten decidir cuando terminar.
  • Se pide que cada participante escriba sus ideas, luego las ideas son leídas para que otros piensen en ideas relacionadas y de esa forma las ideas mutan y se combinan.

Tormenta de Ideas – Fase de Reducción

  • El secretario lee cada idea y pregunta si es válida
    • Si hay cualquier desacuerdo, la idea se queda
  • Agrupamiento de ideas
    • Nombrar los grupos
  • Definición
    • Se escribe una breve descripción de lo que la idea significa para la persona que la escribió
    • Ayuda a tener un entendimiento común del requerimiento
    • Lleva unos minutos por idea
  • Priorización (opcional)
    • Test de los $100: Cada persona tiene dinero para comprar ideas, se ordena según ideas más compradas
      • Solo se puede hacer una vez
      • Se debe limitar la cantidad a gastar en 1 sola idea

Sesiones de Trabajo (Workshop)

  • Ámbito para las tormentas de ideas
  • Preparación
    • Venderlo a los posibles miembros de la reunión
    • Asegurarse que asisten los stakeholders correctos
    • Estructurar la invitación, el lugar, etc.
    • Enviar material previo a la reunión
      • Doc de requisitos
      • Entrevistas, defectos de los sistemas existentes, etc.
      • Asegurarse de enviar lo necesario, sin exagerar
    • Organizar la Agenda
      • Introducción
      • Tormenta de ideas – generación
      • Tormenta de ideas – reducción
      • Priorización
      • Resumen

Casos de Uso

  • Formato simple y estructurado donde los usuarios y desarrolladores pueden trabajar juntos
  • No son de gran ayuda para identificar aspectos no funcionales
  • Mientras se definen los casos de uso, puede ser un buen momento para definir pantallas u otros objetos con los que el usuario interactúa
  • Pueden ser usados en el diseño y en el testing del sistema
  • Usarlo
    • Cuando el sistema está orientado a la funcionalidad, con varios tipos de usuarios
    • Cuando la implementación se va a hacer OO y con UML
  • No son la mejor elección:
    • Sistemas sin usuarios y con pocas interfaces
    • Sistemas dominados primariamente por requisitos no funcionales y restricciones de diseño

Prototipado

  • Implementación parcial, permite a los desarrolladores y usuarios:
  • Prototipo desechable: El propósito es solo establecer que algo se puede hacer, luego se parte de cero en la construcción, quedando el conocimiento aprendido
  • Prototipo evolutivo: Es implementado sobre la arquitectura del producto final, el sistema final se obtiene de evolucionar el prototipo
  • Aspectos para los que es frecuente construir prototipos:
    • Apariencia y percepción de la interfaz de usuario
    • Arquitectura (riesgos tecnológicos, tiempos de respuesta)
    • Otros aspectos riesgosos

Mismos datos, pero…

  • Ingrese
  • año: ____
  • mes: ____
  • día: ____
  • Julio 1998
  • 1998
  • 2025
  • 1
  • 31
  • Ene
  • Dic
  • Martes 16 Oct. 2002

Análisis de Requisitos

Proceso de Requisitos

  • Artefactos
  • Análisis
  • Especificación
  • Validación
  • Actividades
  • Especificación de Requisitos
  • Documento
  • de
  • Requisitos
  • Planificación
  • Obtención
  • Verificación
  • Documento
  • de
  • Visión

Análisis de Requisitos

  • Analizar stakeholders / clientes / usuarios
  • Crear vistas
  • Detallar
  • Negociar prioridades
  • Buscar reqs que faltan
  • Evaluar factibilidad técnica - Prototipos
  • Evaluar riesgos de requerimientos – En el Plan

Stakeholders / Clientes / Usuarios

  • Clientes:
    • Definir responsable de:
      • resolución de conflictos
      • validación
    • Planificar reuniones de revisión de avance con el responsable.
    • Definir proceso de resolución de conflictos pe. en alcance.
  •  Usuarios:
    • dividirlos en clases
    • definir representantes
    • definir prototipos
    • acordar responsabilidades y estrategias de colaboración con representantes
  • Stakeholders
  • Clientes
  • Usuarios

Proceso de Requisitos

  • Artefactos
  • Análisis
  • Especificación
  • Validación
  • Actividades
  • Especificación de Requisitos
  • Documento
  • de
  • Requisitos
  • Modelo del Sistema
  • Planificación
  • Obtención
  • Verificación
  • Documento
  • de
  • Visión



Compartir con tus amigos:
1   2   3   4   5   6   7   8   9   ...   14


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal