Flujo De Trabajo PUDS

Contenido

 Captura de requisitos

 Captura de requisitos como casos de uso

 Análisis

 Diseño

 Implementación

 Pruebas

Captura de requisitos

 La captura de requisitos es complicada

 Creamos código para otros

 Los usuarios no los conocen y les cuesta

especificarlos de forma precisa

 Suelen ser varios usuarios sin una visión global

 Los requisitos cambian

 Las condiciones cambian

Captura de requisitos

 Objetivo: guiar el desarrollo hacia el

sistema correcto

 El cliente debe ser capaz de leer y

comprender el resultado

 El resultado ayuda al jefe de proyecto a

planificar las iteraciones

 Puntos de partida:

 Modelo del negocio

 Modelo del dominio

 Se deben reducir los riesgos

Captura de requisitos

 Pasos a seguir

 Enumerar los requisitos candidatos

 Comprender el contexto del sistema

 Capturar requisitos funcionales

 Capturar requisitos no funcionales

 Se realizan de forma conjunta

Captura de requisitos

Enumerar requisitos candidatos

 Lista de características

 Se utiliza sólo para planificación

 Estructura de las características:

 Nombre y breve descripción

 Estado (propuesto, aprobado, incluido,…)

 Coste estimado implementación

 Prioridad

 Nivel de riesgo (crítico, significativo, …)

Captura de requisitos

Comprender contexto sistema

 Modelo del dominio

 Conceptos importantes del contexto

 Objetos del dominio

 Modelo del negocio

 Qué procesos de negocio soportará el sistema

 Objetos del dominio,

 trabajadores, responsabilidades y operaciones

 El arquitecto y el jefe del proyecto deciden

si se realizan estos modelos

Captura de requisitos

 Capturar requisitos funcionales

 Casos de uso

 Soporte al usuario en procesos de negocio

 Debemos conocer el contexto

 Apariencia de la interfaz de usuario

 Capturar requisitos no funcionales

 Restricciones de entorno, de plataforma,

rendimiento, etc.

 Asociados a casos de uso o generales (lista aparte

de requisitos adicionales)

Captura de requisitos

Trabajo a realizar Artefactos

resultandtes

Enumerar requisitos

candidatos

Lista de características

Comprender el contexto

del sistema

Modelo del dominio o del

negocio

Capturar los requisitos

funcionales

Modelo de casos de uso

Capturar los requisitos

no funcionales

Requisitos adicionales o

casos de uso

Modelo del dominio

 Objetos en el contexto del sistema

 Aparecen en tres formas típicas:

 Objetos del negocio (pedidos, cuentas,

facturas)

 Objetos del mundo real

 Sucesos que ocurrirán o han ocurrido

 Se describe mediante diagramas de clase

 Se suelen requerir pocas clases (10 – 50)

Modelo del dominio

 Clases restantes se almacenan en un

glosario

 Define un vocabulario común

 El modelo del dominio debe contribuir a

comprender el problema

 Las clases se utilizan:

 Al describir casos de uso y diseñar interfaces

 Para sugerir clases internas

Modelo del negocio

 Describe los procesos de negocio de una

empresa

 Soportado por modelos de casos de uso y

modelos de objetos



...