flujos_trabajorequisitos

7/24/2019 flujos_trabajoRequisitos

http://slidepdf.com/reader/full/flujostrabajorequisitos 1/89



Contenido

Captura de requisitos

Captura de requisitos como casos de uso

Análisis

Diseño

Implementación

Pruebas




Objetivo: guiar el desarrollo hacia elsistema 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




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 requisitosEnumerar 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 requisitosComprender 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 decidensi se realizan estos modelos




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 apartede requisitos adicionales)




Trabajo a realizar Artefactosresultandtes

Enumerar requisitos

candidatos

Lista de características

Comprender el contextodel sistema

Modelo del dominio o delnegocio

Capturar los requisitos

funcionales

Modelo de casos de uso

Capturar los requisitosno funcionales

Requisitos adicionales ocasos 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 unglosario

Define un vocabulario común

El modelo del dominio debe contribuir acomprender 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 unaempresa

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 compuestopor trabajadores, entidades y unidades detrabajo

El modelo del dominio es unasimplificació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 detrabajadores

Participación de los trabajadores en las

realizaciones de los casos de uso delnegocio (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 acasos 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 puedenasociarse a ningún caso de uso enconcreto

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)




Artefactos y trabajadores

GlosarioActor

Analista de

sistemas

Modelo casos

de uso

Especificador

de casos de uso

Caso de uso Descripción de

la arquitectura

ArquitectoDiseñador de

interfaz de usuario

Prototipo

de interfaz

de usuario




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

Sistema de

casos de uso

1

* *




Artefactos

Actor Cualquier entidad externa al sistema

Cada usuario se representa como uno o más

actores Suelen corresponderse con trabajadores y

actores de negocio

Actor




Artefactos

Caso de uso Es un clasificador: tiene operaciones y

atributos

Las instancias de casos de uso interaccionancon instancias de actores

Se especifican con diagramas de estado o deactividad

Se consideran atómicos Flujos de sucesos y Requisitos especiales

Caso de uso




Artefactos

Descripción de la arquitectura Casos de uso significativos

Funcionalidad importante y crítica

Glosario Definición de conceptos y nociones

Prototipo de la interfaz de usuario

Modelo casos

de uso

Descripción de

la arquitectura

GlosarioPrototipo de interfaz

de usuario




Trabajadores

Analista de sistemas

Especificador de casos de uso

Diseñador de interfaz de usuario

Arquitecto




Actividades

Analista

Arquitecto

Especificador

Diseñador

Encontrar actores y

casos de uso

Priorizar los casos de

uso

Detallar un caso de

uso

Estructurar el modelo

de casos de uso

Prototipar la interfazde usuario

d




Actividades

Encontrar actores y casos de uso

Analista

Encontrar actores ycasos de uso

Glosario

Modelo del

negocioModelo de

casos de uso

(esbozado)

Requisitosadicionales

Lista de

característ.

C d i i




Actividades

Priorizar casos de uso

Arquitecto

Priorizar casos deuso Descripción de laarquitectura (vista del

modelo de casos de uso)

Modelo de

casos de uso

Requisitosadicionales

Glosario

C d i i




Actividades

Detallar un caso de uso

Especificador de

casos de uso

Detallar un caso de

uso

Modelo decasos de uso

Requisitos

adicionales

Glosario

Caso de uso(detallado)

C d i i




Actividades

Técnicas para detallar un caso de uso Precondición + Camino básico + Caminos

alternativos + Poscondición

Diagramas de estado Diagramas de actividades

Diagramas de interacción

C d i i




Actividades

Prototipar la interfaz de usuario

Diseñador de

interfaz de usuario

Prototipar la interfaz

de usuario


Requisitos

adicionales

Glosario

Prototipo

de interfaz

de usuarioCaso de uso

(descrito)

-Lógico

-Físico

C d i i




Actividades

Estructurar el modelo de casos de uso

Analista de

sistemas

Estructurar el

modelo de casos

de uso


Requisitos

adicionales

Glosario

Caso de uso

(descrito)

Modelo de

casos de uso

(estructurado)

C d i i




Actividades

Estructurar el modelo de casos de uso Identificar descripciones de funcionalidad

compartida (herencia) Casos de uso reales

Casos de uso abstractos

Identificar descripciones de funcionalidadadicional y opcional (extensión)

Otras relaciones (inclusión)



Análisis

Se trabaja con conceptos

Especificación más precisa de losrequisitos

Se utiliza el lenguaje de desarrolladores Facilita comprensión, preparación,

modificación y mantenimiento de

requisitos Primera aproximación al modelo de diseño



Análisis

Facilita la identificación y planificación deincrementos

Proporciona una visión general del sistema

Algunas partes del sistema tienen diseñosy/o implementaciones alternativas

Se utiliza un sistema heredado complejo



Análisis

Descripción de la

arquitectura

Realización caso

de uso -Análisis

Clase del

análisis

Arquitecto

Modelo de

análisisPaquete del

análisis

Ingeniero de

componentesIngeniero decasos de uso



Análisis - Artefactos

Modelo de análisis

Modelo de análisis Sistema de

análisis

1

*

*

Realización caso

de uso -Análisis

Clase del

análisis

Paquete del

análisis

* * *

*




Clase de análisis Se centra en requisitos funcionales

Se definen responsabilidades

Atributos conceptuales Relaciones conceptuales

3 estereotipos de clases Clase del

análisis

Clase de

control

Clase de

entidad

Clase de

interfaz




Realización de caso de uso-análisis Descripción textual del flujo de sucesos

Diagramas de clases

Diagramas de interacción (colaboración) Se pueden posponer requisitos no funcionales

(aparecen más)

Realización caso

de uso -Análisis

Caso de uso

«trace»




Paquete de análisis Alta cohesión y bajo

acoplamiento

Dividen el trabajo

Basados en requisitosfuncionales (reconocibles porpersonas del dominio)

Generan subsistemas dediseño

Realización caso

de uso -Análisis

Clase del

análisis

Paquete delanálisis

* *

*




Paquete de análisis: Paquetes de servicio Sevicio: conjunto coherente de acciones

relacionadas funcionalmente que se utiliza envarios casos de uso. Son para los clientes.

Es indivisible

Relevante para uno o pocos actores

Generan subsistemas de servicio en diseño

Generan componentes ejecutables y binarios Objetivo: obtener componentes reutilizables




Descripción de la arquitectura Descomposición del modelo en paquetes

Clases fundamentales:

De entidad, importante en dominio De interfaz, comunicación importante

De control, con amplia cobertura

Generales, centrales y con muchas relaciones

Realizaciones de casos de uso

Modelo de

análisis

Descripción de

la arquitectura



Análisis - Trabajadores

Arquitecto Responsable de la integridad del modelo de

análisis y de la arquitectura del modelo

Ingeniero de casos de uso Garantiza que las realizaciones de casos de

uso cumplen con sus requisitos

Ingeniero de componentes Define y mantiene responsabilidades, atributos

y relaciones de varias clases



Análisis - Actividades

Analizar un caso de

uso

Arquitecto

Ingeniero de

componentes

Ingeniero de

casos de uso

Análisis de la

arquitectura

Analizar una clase Analizar un paquete




Análisis de la arquitectura

Arquitecto

Análisis de la

arquitectura


Requisitos

adicionales

Descripción de la

arquitectura (vista delmodelo de casos de uso)

Paquete del

análisis (esbozo)

Modelo del

negocio

Clase del

análisis (esbozo)

Descripción de la

arquitectura (vista del

modelo de análisis)




Analizar un caso de uso

Ingeniero de casos

de uso

Analizar un

caso de uso


Requisitos

adicionales

Descripción de la

arquitectura (vista delmodelo de análisis)

Modelo del

negocioClase del

análisis (esbozo)

Realización caso

de uso - análisis




Analizar una clase

Ingeniero de

componentes

Analizar una

clase

Clase del

análisis (esbozo)

Realización caso

de uso - análisis

Clase del análisis

(terminada)




Analizar un paquete

Ingeniero de

componentes

Analizar un

paquete

Descripción de la



Paquete del

análisis(esbozo)

Paquete del

análisis

(terminado)



Diseño

Descripción de laarquitectura

Realización caso

de uso - diseño

Interfaz

Arquitecto

Modelo dediseño Subsistema dediseño

Ingeniero de

componentesIngeniero de

casos de uso

Modelo dedespliegue Clases deldiseño



Diseño - Artefactos

Modelo de diseño

Modelo de diseño Sistema de

diseño

1

*

Realización caso

de uso - diseño

* **

*

Clases del

diseño

Interfaz

*

Subsistema de

diseño

*

*




Clase de diseño Sintaxis del lenguaje de programación

Visibilidad de atributos y operaciones

Traducción de las relaciones Métodos por pseudocódigo

Estereotipos que se correspondan conconstrucciones del lenguaje de programación

Clases del

diseño

Interfaz

► realiza




Realización de caso de uso-diseño Diagramas de clase

Diagramas de interacción (clases, subsistemas,

interfaces) Flujo de sucesos-diseño

Requisitos de implementación

Realización caso

de uso - diseño

Realización caso

de uso - análisis

«trace»




Subsistema de diseño Traza con paquetes análisis

Subsistema de servicio

► realiza

*

Realización caso

de uso - diseño

* *

Clases del

diseño

Interfaz

*

Subsistema de

diseño

*




Interfaz

Clases del

diseño

Interfaz

► realiza

Subsistema de

diseño

► realiza

*

*




Descripción de la arquitectura (vistamodelo de diseño) Descomposición en subsistemas

Traza con clases de análisis Clases abstractas

Clases generales y centrales

Realizaciones de caso de uso

Modelo de

diseño

Descripción de

la arquitectura




Modelo de despliegue Distribución física del sistema

Nodos y relaciones

Componentes por nodo Correspondencia entre

arquitectura software yarquitectura del sistema

Modelo de

despliegue

Nodo

*




Descripción de la arquitectura(vista modelo despliegue) Artefactos relevantes para la

arquitectura

Modelo de

despliegue

Descripción de

la arquitectura



Diseño - Trabajadores

Arquitecto Responsable de la integridad de los modelos

de diseño y despliegue

Ingeniero de casos de uso Responsable de la integridad de una o más

realizaciones de casos de uso-diseño

Ingeniero de componentes Define y mantiene operaciones, atributos y

relaciones de una o más clases de diseño



Diseño - Actividades

Diseñar un caso de

uso

Arquitecto

Ingeniero de

componentes

Ingeniero de

casos de uso

Diseño de la

arquitectura

Diseñar una clase Diseñar un

subsistema




Diseño de la arquitectura

Arquitecto

Diseño de la

arquitectura


Requisitos

adicionales

Descripción de la



Modelo de

análisis

Subsistema

Interfaz

Modelo de

despliegue

Clase de

diseño

Descripción arquitectura

(vista de modelo de

diseño y despliegue)




Diseño de un caso de uso

Diseñar un caso de

uso

Ingeniero de

casos de uso


Requisitos

adicionales

Modelo de

despliegue

Subsistema

Interfaz

Clase de

diseño

Modelo de

análisis

Modelo de

diseño

Realización caso

de uso - diseño




Diseño de una clase

Ingeniero de

componentes

Diseñar una clase

Interfaz

Clase de

diseño

Realización casode uso - diseño

Clase de diseño

(completa)

Clase del análisis

(completa)




Diseño de un subsistema

Ingeniero de

componentes

Diseñar un

subsistema

Interfaz

(terminada)

Subsistema

(terminado)


(vista modelo de diseño)

Interfaz

(esbozada)

Subsistema(esbozado)



Implementación

Descripción de la

arquitectura

Interfaz

Arquitecto

Modelo de

implementac.

Implementac.

subsistema

Ingeniero de

componentesIntegrador de

sistemas

Modelo de

despliegue

Componente

Integración de

sistema



Implementación - Artefactos

Modelo de implementación

Modelo de

implementación

Sistema de

implementac.

1

**

*

Interfaz

*

Subsistema de

implementac.

**

Componente




Componente «executable»

«file»

«table» «library»

«document»Componente

«trace»

Clase de

diseño

InterfazInterfaz




Subsistema de implementación Paquete (Java)

Directorio (C++)

Proyecto (VB)

► realiza

*

*

Interfaz

*

Subsistema de

implementac.

* *

Componente




interfaz

Interfaz

► realiza

Subsistema de

implementac.

► realiza

*

*

Componente




Descripción de la arquitectura Subsistemas de implementación

Interfaces y dependencias

Componentes clave

Modelo de

implementac.

Descripción de

la arquitectura




Plan de integración de construcciones Construir el software incrementalmente

Control de versiones

Integración incremental El plan describe la secuencia de construcciones

necesarias en una iteración Funcionalidad de la construcción

Partes del modelo de implementación afectados porla construcción



Implementación -Trabajadores

Arquitecto

Ingeniero de componentes

Integrador de sistemas



Implementación - Actividades

Integrar sistemas

Arquitecto

Ingeniero de

componentes

Integrador de

sistemas

Implementación de la

arquitectura

Implementar una

clase

Implementar un

subsistemaRealizar prueba de

unidad




Implementación de la arquitectura

Arquitecto

Implementación de la

arquitectura

Modelo de

casos de uso

Modelo de

análisis


(vista de modelo de

diseño y despliegue)

Componente

(esbozado y asignado

a un nodo)


(vista de modelo de

implement. y despliegue)




Integrar el sistema

Integrar sistemas

Integrador de

sistemasModelo de

casos de uso

Requisitos

adicionales

Modelo de

implementac.Modelo de

implementac.

Modelo de

diseño

Plan de integración

de construcciones




Implementar un subsistema

Ingeniero de

componentes

Implementar un

subsistema


(vista de modelo de

implementación)

Plan de integración

de construcciones

Subsistema de

diseño

Interfaz

Subsistema de

implementac.

Interfaz




Implementar una clase

Ingeniero de

componentes

Implementar una

clase Componente

(implementado)

Interfaz

Clase de diseño

(diseñada)




Realizar prueba de unidad

Ingeniero de

componentes

Realizar prueba de

unidad Componente

(unidades probadas)

Interfaz

Clase de diseño

(implementada)



Pruebas

Evaluación de

pruebas

Ingeniero

de pruebas

Modelo de

pruebas

Ingeniero de

componentes

Ingeniero de

pruebas integración

Componente

de pruebas

Plan de pruebas

Ingeniero de

pruebas sistema

Procedimiento de pruebas

X

Caso de

prueba

X X

Defecto



Pruebas - Artefactos

Modelo de pruebas

Modelo de

pruebas

Componente

de pruebas

Procedimiento de

pruebas

X

Caso de

prueba

X

Sistema de

pruebas

*

1

**




Caso de prueba Entrada, Resultado y Condiciones

Otras pruebas: Instalación

Configuración

Negativas

De tensión

«trace»

Caso de prueba

(caja negra)

X

Realización caso

de uso - diseño

«trace»

Caso de prueba

(caja blanca)

X

Caso de uso




Procedimiento de prueba Cómo realizar uno o varios casos de prueba

Instrucciones para un individuo

Especificación de interacción manual

Procedimiento de

pruebas

X

Caso de

prueba

X1..* 1..*




Componente de prueba Automatiza uno o varios procedimientos de

prueba

Puede utilizarse un “modelo de diseño depruebas”

1..* 1..*

Componente

de pruebasProcedimiento de

pruebas

X




Plan de prueba Estrategias, recursos y planificación de la

prueba

Defecto Anomalía del sistema Problema descubierto durante la revisión

Evaluación de prueba Evaluación de los resultados de los esfuerzos

de prueba



Pruebas - Trabajadores

Diseñador de pruebas

Ingeniero de componentes

Ingeniero de pruebas de integración

Ingeniero de pruebas del sistema



Pruebas - Actividades

Diseñar pruebaPlanificar

prueba

Implementar pruebas

Realizar prueba de

integración

Realizar prueba de

sistema

Ingeniero de

pruebas

Ingeniero de pruebas de sistema

Ingeniero de pruebas

de integración

Ingeniero de

componentes

Evaluar prueba




Planificar prueba


Planificar pruebas


Modelos c.uso -

implementación


Plan de pruebas




Diseñar prueba


Planificar pruebas


Modelos c.uso -implementación


Plan de pruebas

Procedimiento de

pruebas

X

Caso de

prueba

X

Integración

Sistema

Regresión




Realizar pruebas

Ingeniero decomponentes

Implementar prueba

Modelo

implementación

Procedimiento de

pruebas

X

Caso de prueba

X

Componentede pruebas




Implementar prueba de integración

Ingeniero de pruebas de

integración

Realizar pruebas deintegración

Modelo

implementación

Procedimiento de

pruebas

X

Caso de

prueba

X

Componente

de pruebas

X

Defecto




Realizar pruebas de sistema

Ingeniero de pruebas de

sistema

Realizar pruebas deintegración

Modelo

implementación

Procedimiento de

pruebas

X

Caso de

prueba

X

Componente

de pruebas

X

Defecto




Evaluar prueba


Evaluar prueba

Modelo de

prueba

X

Defecto

Plan de pruebas

Evaluación de prueba



Referencias

Ivar Jacobson, Grady Booch, JamesRumbaugh, “El Proceso Unificado de

Desarrollo Software”, Addison Wesley,1999

flujos_trabajorequisitos

Documents