Pu fase de inicio-casos uso

1

Método de Desarrollo de Software

Proceso Unificado

Fase de Inicio

A. Soriano – N. Zambrano (Universidad Central de Venezuela)

Inicio Elaboración Construcción Transición

FasesActividades

Análisis requerimientos

Análisis

Diseño

Implementación

Prueba

ConstrucciónInterfaz Usuario

iter 1 | iter 2 | | | | | | | iter n


FasesActividades


Análisis

Diseño

Implementación

Prueba

ConstrucciónInterfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

Modelo de Casos de Uso

2

Proceso Unificado:

Referencias Complementarias

“Applying UML and Patterns: An Introduction to Object Oriented Analysis and

Design and the Unified Process” Craig Larman- Prentice-Hall, Inc. ISBN 0-

13-092569. (Descripción del Problema: Cap. 3 ; Fase de Inicio Cap. 4 -5 - 6

y 7 , Modelo de Casos de Uso: Cap. 6 - 25)

“El Proceso unificado de desarrollo de Software”

I. Jacobson, G. Booch y J.Rumbaugh- Addison Wesley - Pearson Education

“The Rational Unified Process” Ph. Kruchten - Addison Wesley

“El Lenguaje Unificado de Modelado: Manual de Referencia”

J.Rumbaugh, I. Jacobson y G. Booch - Addison Wesley - Pearson

Education.

3


Fases Actividades


Análisis

Diseño

Implementación

Prueba

Construcción

Interfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

Proceso Unificado

Debe quedar claro el

alcance y la factibilidad del

proyecto

4

Esencia del proceso:

desarrollo iterativo

• El desarrollo es planificado en lapsos fijos y

cortos: las iteraciones

• El ciclo de vida es un proceso con feedback y

adaptación

• El sistema crece incrementalmente

• El resultado de cada iteración es un

subconjunto del sistema final

• Una iteración puede significar elegir un conjunto

de requerimientos y diseñar, implementar y

testear o centrarse en mejorar una cualidad

5

Fase de Inicio:

¿objetivos?

• Formular el alcance del proyecto

Capturar los requerimientos y restricciones

mas importantes, a partir de los cuales

pueda depender la finalización del producto

• Preparar el negocio, identificar riesgos y

evaluar alternativas para su manejo,

personal, tiempos, estimar costos y

beneficios

6


Glosario

Visión, Requerimientos

y Caso del Negocio

Fase de Inicio:

¿Qué Artefactos producir?

Describe la terminología clave

Describe los requerimientos

funcionales

Visión general (problema,

usuarios, producto,

restricciones)

Requerimientos principales

7

Plan de Iteración

Lista de Riesgos

y

Plan de Manejo


Glosario

Fase de Inicio:


Describe y prioriza los

riesgos. Analiza cómo

mitigar los riesgos

Describe qué hacer en la

primera iteración de la Fase

de Elaboración

Visión, Requerimientos

y Caso del Negocio

8

Modelo del Dominio

Plan de Iteración

Lista de Riesgos

y

Plan de Manejo


Glosario

Visión y

Caso del Negocio

Fase de Inicio:


Prototipo prototipo de interfaz

u otro tipo de

prototipo

Objetos básicos del dominio

y relaciones entre ellos

9

¿Demasiada Documentación?

SI!

sólo debe construir los

artefactos que considere necesarios

para alcanzar

el objetivo de la fase

10

Fase de Inicio

Artefactos principales

Artefactos a producir

Un documento que de una visión del problema

mostrando los requerimientos centrales del

proyecto y las restricciones principales

Un modelo de casos de uso preliminar que

muestre las funcionalidades (casos de uso) y los

actores identificados en las etapas iniciales

Un modelo del dominio que muestre los

objetos y conceptos más importantes del

contexto del dominio.

11

Fase de Inicio

Artefactos principales

Artefactos a producir

Un modelo del negocio que muestre el

contexto del negocio, los criterios para

determinar el éxito del proyecto y la previsión

financiera

Una estimación inicial de los riesgos

Una planificación del proyecto que muestre

fases e iteraciones

12

Fase de Inicio:

¿En qué disciplina debe producirse un artefacto?


Fases Actividades


Análisis

Diseño

Implementación

Prueba

Construcción

Interfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

- Modelo del Negocio

13

Artefactos de la Fase de Inicio:

¿En qué disciplina?


Fases Actividades


Análisis

Diseño

Implementación

Prueba

Construcción

Interfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

- Modelo de Casos de Uso

- Glosario

14




Fases Actividades


Análisis

Diseño

Implementación

Prueba

Construcción

Interfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

- Análisis y Diseño

de Interfaces

- Modelo del

dominio

15




Fases Actividades


Análisis

Diseño

Implementación

Prueba

Construcción

Interfaz Usuario

iter 1 | iter 2 | | | | | | | iter n

Codificación del Prototipo

16

Los Requerimientos

¿Qué son?

¿Para qué sirven?

¿Cómo se clasifican?

¿A través de qué artefactos pueden

describirse?

17

Los Requerimientos:

¿Qué deberá hacer el sistema?

¿En qué condiciones deberá hacerlo?

¿Qué cualidades o atributos deberá poseer el

sistema?

18

Los Requerimientos:

¿Para qué sirven?

Requerimientos

19

Los Requerimientos:

No

Fu

nci

on

ales

20

Los Requerimientos:

Artefactos

Los Requerimientos Funcionales

historias de utilización del sistema por

parte del usuario para alcanzar las

metas que provee

=

21

¿ Casos de Uso ?

¿Qué hace el actor?

¡Usa el sistema !

El actor interactúa

con el sistema.

Se realiza una

secuencia específica

de acciones

Escenario

22

¿ Caso de Uso ?

• Representa un escenario que realiza el

actor usando el sistema para un próposito

específico

• Define una funcionalidad del sistema

Enlace a UML-Casos de Uso

Unified Modeling

Language

23

Computador

Lector de código de barra

Software del Sistema

registrar ventas

y manejar los pagos

Caso de Estudio:

Sistema de Puntos de Venta

Puntos de Venta para ventas al detal en una

tienda: (PV)

Uso principal:

Compuesto por: Ilustración extraída de:

Appliyng UML and patterns. 2° edición- C. Larman. Prentice Hall. 2002

Caso de Estudio :

Puntos de Venta (PV)

24

Cajero

Sistema PV

Requerimientos Funcionales

4. Casos de Uso

Meta:

Procesar ventas

Caso de Estudio :


25

Requerimientos Funcionales

4. Casos de Uso

Meta del Cajero:

Procesar Venta

Procesar Venta Manejar Devoluciones

Pago

Alquilar

Caso de Estudio :


26

Requerimientos Funcionales : casos de Uso

Procesar Venta

PuntoVenta

Cajero Pago

Caso de Estudio :


27

Casos de Uso: Descripción

Breve

Casual

Completo

Un párrafo resume el escenario principal

Formato informal, los escenarios se

presentan en múltiples párrafos

Todos los pasos y variaciones se describen en

detalle; incluye secciones de soporte tales como

post-condiciones ...

Caso de Estudio :


28

Ejemplo: Casos de Uso Procesar venta

Escenario Principal

1. Un cliente llega a la caja con los

productos que va a comprar. El cajero inicia

la venta para un nuevo cliente. Registra en

la caja cada producto y el sistema genera

una linea por cada producto y muestra el

total por producto y el total acumulado. Al

finalizar se calcula el impuesto y se le

muestra al cliente el total a pagar …

Caso de Estudio :


Formato breve

29

Ejemplo: Casos de Uso Procesar venta

Escenario Principal

1. Un cliente llega a la caja con los productos

que va a comprar. El cajero inicia la venta.

Registra en la caja cada producto.....

Escenarios Alternativos

1.1 Un código de producto no es reconocido....

1.2 El precio de un producto está

equivocado.....

.....

Caso de Estudio :


Formato casual

30

Caso de uso en formato completo

Actor Principal

Expertos e Interesados

Precondiciones

Éxito Garantizado (Postcondiciones)

Escenario Principal de Éxito ( Curso Básico)

Extensiones (Cursos Alternos)

Requerimientos Especiales

Tecnología y Lista de Variaciones de Datos

Frecuencia de Ocurrencia

Preguntas abiertas

Actor que invoca

al sistema

solicitando un

servicio

con un propósito

particular

Actor Principal:

Cajero

Actor principal

Caso de Estudio :


www.usecases.org

31

Actor Principal

Participantes e Intereses

Precondiciones


Escenario Principal de Éxito (Curso Básico)





Preguntas abiertas

participantes en el

Caso de Uso y

sus intereses


Participantes e Intereses:

•Cajero: Desea garantizar

registro rápido y sin errores en

los pagos

•SENIAT: Desea que el

impuestro se registre

adecuadamente

...

Participantes e intereses

Caso de Estudio :


32

Actor Principal


Precondiciones







Preguntas abiertas

Aquellas premisas

que deben ser

ciertas antes de la

ejecución

del caso de uso


Caso de uso Procesar

Venta

Precondición: El Cajero

está identificado y

autorizado

Precondiciones

Caso de Estudio :


33

Actor Principal


Precondiciones







Preguntas abiertas

Establece lo

que debe cumplirse

en caso de haber sido

completado con éxito

el caso de uso.

(escenario principal

o algún curso alterno)


Postcondiciones:

Caso de uso Procesar Venta

- La venta fue registrada.

- El impuesto fue calculado.

- Se calcula el total a pagar

Postcondiciones

Caso de Estudio :


34

Actor Principal


Precondiciones







Preguntas abiertas

Describe el curso

normal

de una secuencia de

transacciones


Curso básico

35

1) El Cajero inicia una nueva venta

2) El Cajero introduce la identificación de un producto y la

cantidad

2.1 El sistema registra cada línea de venta y presenta el total

por producto, la descripción y el total acum. de la venta

El Cajero repite el paso 2 hasta que finalicen los productos

4) El sistema calcula el impuesto y se muestra al cliente el total

a pagar


Ejemplo: Procesar Venta

Escenario Principal de Éxito (Flujo Básico):

FORMATO DE UNA COLUMNA

Caso de Estudio :


36


Ejemplo: Procesar Venta Escenario Principal de Éxito (Flujo Básico): Actor Sistema

Caso de Estudio :


1) El Cajero inicia una

nueva venta

2) El Cajero introduce la

identificación del

producto y la cantidad

3) Registra cada línea de venta y presenta la descripción, el total por linea y el total acumulado

El Cajero repite el paso

2 hasta finalizar de

introducir los productos

Calcula el impuesto y se

muestra el total a pagar

FORMATO DE DOS COLUMNAS

37

Actor Principal


Precondiciones


Escenario Principal de Éxito ( Curso Básico)





Preguntas abiertas

Indican otros

escenarios

no usuales, tanto de

éxito como de falla.



Extensiones (Cursos Alternos):

3. Identificación de producto inválida:

El Sistema señala el error, rechaza

la entrada y solicita la id

Cursos alternos

Caso de Estudio :


38

Actor Principal


Precondiciones







Preguntas abiertas

Requerimientos

no funcionales

asociados con

el caso de uso


Requerimientos no funcionales


Requerimientos Especiales:

- Pantalla Táctil en un gran monitor

plano que permita texto visible a 1 metro.

...

Caso de Estudio :


39

Actor Principal


Precondiciones





Aspectos Técnicos y Tecnologías


Preguntas abiertas

Detalles técnicos que

deben ser considerados

en el caso de uso



- La identificación del

producto se introduce por

una lectora láser y

opcionalmente por el

teclado.

Tecnologías

Caso de Estudio :


40

Actor Principal


Precondiciones







Preguntas abiertas

Indica la frecuencia

de ocurrencia

del caso de uso


Frecuencia de

Ocurrencia:

continua

Ocurrencias

41

Actor Principal


Precondiciones







Preguntas abiertas

Aspectos

no considerados

que se mantienen

como preguntas

abiertas


Preguntas Abiertas:

-¿Puede el cliente

directamente usar el lector de

tarjetas de crédito, o es

indispensable que lo haga el

cajero?

...

Preguntas abiertas

Caso de Estudio :


42

Caso de uso: Descripción

¿Qué formato usar?

Breve

Casual

Completo Procesar Venta

Alquilar

Manejar Devoluciones

43

Casos de Uso en el Proceso

Unificado

Modelado del Negocio

Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas

Enlazan las disciplinas

44


Unificado


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas

Describen los procesos de negocio

45


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas


Unificado

Lenguaje de comunicación común entre los clientes o usuarios y desarrolladores del sistema.

Requerido para la definición de prototipos de interfaces.

46


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas


Unificado

Creación y validación de la

arquitectura del sistema.

47


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas


Unificado

El Modelo de Diseño es la especificación de la implementación

Las realizaciones de los Casos de Uso en el modelo de Diseño se usan para entender el dinamismo del sistema y determinar donde optimizar el rendimiento.

48


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas


Unificado

Constituyen la base para identificar los casos de prueba

Se ejecuta cada Caso de Uso para verificar el sistema.

49


Requerimientos

Análisis y Diseño

Implementación

Prueba

Entrega

Disciplinas


Unificado

Sirven para planificar

la entrega de una fase

o definir variantes del

sistema

Proveen gran parte de

la estructura y

contenido de los

manuales de usuario.

50

URL de interes

(asociadas al libro de Craig Larman):

• www.craiglarman.com

• www.phptr.com/larman

• Acerca de UML:

• www.omg.org

• www.celigent.com/uml

Requerimientos:

• www.swebok.org

• www.sei.cmu.edu

http://www.craiglarman.com/

http://www.phptr.com/larman

http://www.omg.org/

http://www.celigent.com/uml

http://www.swebok.org/

Pu fase de inicio-casos uso

Internet