La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Taller de desarrollo de proyectos 2 – Marzo 2009 Gestión de requerimientos.

Presentaciones similares


Presentación del tema: "Taller de desarrollo de proyectos 2 – Marzo 2009 Gestión de requerimientos."— Transcripción de la presentación:

1 Taller de desarrollo de proyectos 2 – Marzo 2009 Gestión de requerimientos

2 Agenda Requerimientos SRS Use Cases User stories UATs Gestión de requerimientos

3 ¿Que es un requerimiento? Una condición o capacidad necesitada por el usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe poseer un sistema o algún componente del mismo para satisfacer un contrato, estándar, especificación u otro documento formalmente impuesto. Documentación.

4 ¿Porque es tan dificil identificarlos? El síndrome del si, pero... El Síndrome de los Requerimientos Ocultos El Síndrome del Usuario y Desarrollador

5 – Entrevistas a usuarios – Cuestionarios – Brainstorming – Observación – Workshops de creación de user stories – Role Playing – Prototipos Técnicas para identificarlos

6 – Con valor para usuarios o clientes – Estimable – Correcto – Sin ambigüedades – Completo – Consistente – Priorizable – Testeable – Modificables (Independientes) – Fácil de seguir (Traceable) Características de los buenos requerimientos

7 – SRS (Software Requirement Specification) – Caso de Uso – User Stories – UATs ¿Cómo podemos especificarlos? Es importante expresar el ¿qué? y no el ¿cómo?

8 – Basado en el standard IEEE Std , – Creado el 1984 y revisado en 1993 y – Incluye: – Prácticas recomendadas – Diferentes alternativas para organizar una especificación de requerimientos. – Descripción detallada de cada sección. – Introducción – Descripción General – Requerimientos Específicos –Funcionales, –De interfaces externas, –De performance, –Restricciones de diseño, –Atributos de calidad –Otros requerimientos. SRS

9 – UC001 – Registro asignación turno – Actores: Recepcionista – Pre-condiciones: El usuario debe de estar registrado y loggeado – Post-condiciones: El turno queda asignado en el sistema – Flujo Principal: 1. El usuario selecciona la opción de reserva de turnos 2. El sistema solicita nombre del médico que asistirá al paciente 3. El usuario ingresa el nombre del médico del cuál se solicita turno 4. El sistema muestra los próximos 5 turnos disponibles del médico 5. El usuario selecciona alguno de los 5 turnos o pasa al flujo alternativo El sistema solicita datos paciente 7. El usuario brinda datos paciente 8. El sistema registra el turno – Flujo Alternativo: Ninguno de los 5 turnos disponibles es apropiado – El usuario informa que ninguno de los 5 turnos puede ser tomado – El sistema muestra otros 5 turnos disponibles con un lapso no menor a una semana entre fecha y fecha de cada turno. Ejemplo de Caso de Uso

10 – Describe la funcionalidad que será de valor para un usuario o comprador de un sistema o software. – Tienen información sobre: – Quien? (rol del usuario) – Que? (Objetivo) – Porqué? (justificación) User Stories

11 User Story Como un [rol] Quiero que [objetivo] para poder [valor de negocio] Ejemplo: Como un médico de la clínica Quiero consultar historias clínicas para poder dar un diagnóstico más acertado a mis pacientes

12 – Son usados para expresar detalles que resultan de una conversación entre clientes y desarrolladores – Documentan supuestos sobre la funcionalidad – Determinan si la funcionalidad está completamente implementada – Deberían ser escritas por el cliente en vez de por el desarrollador (o al menos en conjunto) – Son escritas antes de que el desarrollador codee. – Si es posible los desarrolladores deben automatizar el testing (ej. FIT & FitNesse) User Acceptance Tests (UATs)

13 Gestión tradicional

14 – El involucramiento activo de los usuarios es imperativo – Los requerimientos evolucionan a medida que se desarrolla el software – La cooperación, colaboración y comunicación entre equipos es esencial. – Los requerimientos ágiles son justos y necesarios. Gestión ágil Cada nuevo PBI es priorizado y agregado al backlog Cada iteración se implementa los PBI más prioritarios Las prioridades pueden modificarse en cualquier momento PBI menos detallados PBI más detallados Los PBI pueden ser removidos en cualquier momento Alta Prioridad Baja Prioridad

15 – Los requerimientos pueden ser priorizados por: – Su valor de negocio – Su riesgo – Su impacto en otros requerimientos – El deseo de utilizarlos – La cohesión con otros requerimientos – Permiten confirmar que el sistema o componente cumple su propósito. Priorizando requerimientos

16 Referencias – User Stories Applied Mike Cohn – Managing Software Requirements, A Unified Approach Dean Leffingwell, Don Widrig – –


Descargar ppt "Taller de desarrollo de proyectos 2 – Marzo 2009 Gestión de requerimientos."

Presentaciones similares


Anuncios Google