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

 Trabajador

 Entidad del negocio: elemento que

manipulan los trabajadores (facturas)

 Unidad de trabajo: conjunto de entidades

Modelo del negocio

 Cómo desarrollarlo:

 Se confecciona un modelo de casos de uso del

negocio

 Se desarrolla un modelo de objetos compuesto

por trabajadores, entidades y unidades de

trabajo

 El modelo del dominio es una

simplificación del modelo de negocio

 Relaciones de traza en todo el sistema

Modelo del negocio

Comprador Vendedor

Cuenta

Gestor de pagos

Factura

Modelo de casos de uso a partir del

Modelo del negocio

 Se identifican actores a partir de

trabajadores

 Participación de los trabajadores en las

realizaciones de los casos de uso del

negocio (roles del trabajador)

 Cada rol de trabajador es un caso de uso

 Definir qué tareas deberían automatizarse

Captura de requisitos como casos de

uso

 Requisitos funcionales

 Requisitos no funcionales (asociados a

casos de uso)

 Pensamos en lo que necesita el usuario

 Papel clave en el proceso

 Artefactos, trabajadores y actividades

Requisitos adicionales

 Requisitos no funcionales que no pueden

asociarse a ningún caso de uso en

concreto

 Requisito de interfaz (con elem. externo)

 Requisito físico (hardware)

 Requisito de diseño (reutilización)

 Requisito de implementación (estándares)

 Otros requisitos (legales, normativas)

Captura de requisitos

Artefactos y trabajadores

Actor Glosario

Analista de

sistemas

Modelo casos

de uso

Especificador

de casos de uso

Caso de uso Descripción de

la arquitectura

Diseñador de Arquitecto

interfaz de usuario

Prototipo

de interfaz

de usuario

Captura de requisitos

Artefactos

 Modelo de casos de uso

 Uso de diferentes diagramas para representar

distintas vistas

 Uso de paquetes

Actor

Modelo de

casos de uso

Caso de uso

...