UNIVERSIDAD NACIONAL

JOSE FAUSTINO SANCHEZ CARRION

FACULTAD DE INGENIERIA INDUSTRIAL, SISTEMAS
E INFORMATICA

Tema :

FLUJOS DE TRABAJO FUNDAMENTALES

Captura de requisitos como casos de uso

Docente :
Ing. Mario Alberto Osorio Osorio
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

 Qu hacemos en Requisitos ?
Flujos de Trabajo
Fundamentales

Fases
Inicio

Elaboraci
n

Construccin

Transicin

__

Iterac.
# n-1

Requisitos
Anlisis
Diseo
Implementacin
Prueba
Iterac.
#1

Iterac.
#2

__

__

__

__

Iterac.
# n

Iteraciones
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Captura de requisitos

Los desarrolladores no sern los futuros

usuarios del sistema. ( No obtendrn de
si mismos la retroalimentacin de qu tal
funcionan )

Los requisitos y restricciones no estan

profundamente arraigados en sus
medulas a traves de un uso continuo del
producto desde la infancia.

Es pues el acto de descubrimiento por

si mismos lo que se necesita.

Proceso de averiguar normalmente en circustancias

difciles, lo que se debe construir
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Usuarios
Con frecuencia los usuarios
no saben cules son los
requisitos ni tampoco cmo
especificarlos de una forma
precisa

Cada uno conoce la parte de su trabajo

Ninguno tiene una visin global.

Los usuarios no saben como puede hacerse mas eficiente la

operacin en su conjunto.

La mayora de los usuarios no sabe que partes de su trabajo

pueden transformarse en software.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Analistas

Usados
tradicionalmente
como
intermediarios, con la esperanza de
que el analista fuese capaz de tener una
visin en conjunto.

Tipicamente registraban los requisitos

en documentos que llegaban a cientos y
miles de pginas.

Incluso con la ayuda del analista los

usuarios no comprendian del todo lo que
el sistema software debera hacer hasta
que el sistema estaba casi terminado.

Es cierto que los sistemas que construimos deberan dar soporte a los
usuarios, y que podemos aprender de ellos sobre sus interacciones.

Sin embargo es an mas importante que los sistemas den soporte

a la misin sobre la cual se construyen.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Objeto del flujo de trabajo de los requisitos

Guiar el desarrollo hacia el
sistema correcto.

Mediante una descripcin de los

requisitos del sistema ( es decir,
las condiciones o capacidades
que el sistema debe cumplir )

Suficientemente buena como para que pueda llegarse a un

acuerdo entre el cliente (incluyendo a los usuarios) y a los
desarrolladores sobre qu debe y qu no debe hacer el sistema.

Debemos utilizar el lenguaje del cliente.

Sirven de ayuda al jefe de proyecto a planificar las iteraciones y

las versiones del cliente.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Puntos de partida
Tenemos diferentes puntos de partida :
a)

Comenzar haciendo un modelo de negocios

nuevo.

b)

Comenzamos con un modelo de negocio que

ya esta en desarrollo por parte de alguna otra
empresa.

c)

Si el sistema no diera soporte directamente al

negocio, podiamos empezar con un modelo de
objetos sencillo, como un modelo de dominio.

d)

El cliente puede tener ya las especificaciones

de sus requisitos detallada pero no basada en
objetos.

e)

Clientes que solo tiene una vaga nocin

( derivada de un informe de visin general
creado por la alta direccin)
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Flujo de Trabajo de Requisitos

De la Visin a los Requisitos

Captura de requisitos como casos de uso
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

DE LA VISION A LOS REQUISITOS

Flujo de trabajo arquetpico
A parte de las diferencias en los puntos de partida, ciertos
pasos son factibles en la mayora de los casos:

Enumerar los requisitos candidatos

Comprender el contexto del sistema

Capturar requisitos funcionales

Capturar requisitos no funcionales

No
Nose
sellevan
llevanaacabo
caboseparadamente
separadamente
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Enumerar los requisitos candidatos

Lista de ideas de ( clientes , usuarios, analistas, desarrolladores)

Los consideramos como un conjunto de requisitos candidatos

Esta lista crece con nuevos elementos y mengua cuando algunas

caractersticas se convierten en requisitos y se transforman en
otros artefactos como casos de uso.

Cada caracteristica tiene un nombre corto y una breve explicacin

o definicin, acompaado de un conjunto de valores:

Estado( propuesto, aprobado, incluido o validado)

Coste estimado de implementacin

Prioridad ( critico, importante o secundario)

Nivel de riesgo asociado a la implementacion de la

caracterstica ( critico, significativo u ordinario)

Sirven para la planificacin del proyecto y para decidir la secuencia

de iteraciones
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Lista de Caractersticas

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

De la visin a los requisitos

Trabajo a realizar

Artefactos resultantes

Enumerar requisitos candidatos

Lista de caractersticas

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 concretos ( para
requisitos especficos de un
caso de uso )

Definen una
especificacin de
requisitos
tradicional

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Comprender el contexto del sistema

Hay dos aproximaciones para expresar el contexto de un sistema:
modelado del dominio y modelado del negocio.
Modelo del dominio
Describe conceptos importantes del contexto, como objetos del
dominio y enlaza estos objetos unos con otros. ( sirven para definir
clases )
Modelo del negocio
Describe los procesos existentes u observados con el objetivo de
comprenderlos.
Especifica que procesos de negocio soportara el sistema, aparte de
identificar objetos, establece competencias para cada proceso: sus
trabajadores, sus responsabilidades, y las operaciones que llevan a
cabo.

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Modelo del dominio

Captura los tipos ms importantes de objetos en el contexto del
sistema.
Los objetos del dominio representan cosas que existen o los
eventos que suceden en el entorno en el que trabaja el sistema,
aparecen en tres formas tpicas :

Objetos del negocio ( Pedidos, cuentas, contratos, etc. ).

Objetos del mundo real y conceptos ( Condiciones climticas ).

Sucesos que ocurriran o han ocurrido ( La llegada de un avion,

su salida y la hora de la comida ).

Muestran a los clientes, usuarios, revisores y a otros desarrolladores

las clases de dominio y como se relacionan unas con otras mediante
asociaciones.
El modelo de dominio se describe mediante diagramas de UML
( especialmente mediante diagramas de clase)
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Ejemplo de Modelo del dominio

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Ejemplo de Modelo del dominio

Pedido

Artculo

fecha de emisin
direccin de entrega

descripcin
foto
precio

1..*

1..*

pagable

Factura
cantidad
fecha de emisin
fecha lmite de pago

comprador
1
vendedor
1

Cuenta
saldo
titular

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Desarrollo y Usos del Modelo del dominio

Reunidos expertos del dominio y gente con experiencia en

modelado

Comprender y describir las clases mas importantes ( Para

dominios de tamao moderado se obtienen de 10 a 50
clases )

El resto de clases candidatas se guardan en un glosario de

terminos.

El glosario y el modelo sirven para que todos hablen un

lenguaje comn y puedan compartir el conocimiento unos con
otros.

Las
clases
del los
dominio
Al
describir
casos se
de utilizan:
uso y al disear la interfaz de usuario.

Para sugerir clases internas al sistema durante el anlisis.

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Modelo del negocio

Comprender los procesos de negocio de la organizacin
Expresado en terminos de:

Casos de uso del negocio

Actores del negocio

Obreros del negocio

Objetos de negocio

El modelo del negocio est soportado por dos tipos de modelos de

UML: modelos de casos de uso y modelos de objetos.
Modelo de objetos

Es un modelo interno a un negocio.

Describe como cada caso de uso del negocio es llevado a cabo

por parte de un conjunto de trabajadores que utilizan un conjunto
de entidades del negocio y de unidades de trabajo.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Ejemplo : Diagrama de Sub-sistemas

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Desarrollo Modelo del negocio

Se confecciona un modelo de casos

de uso del negocio que identifique
los actores del negocio y los casos
de uso del negocio que utilicen los
actores. Sirve para comprender
mejor que valor proporciona el
negocio a sus actores.
Luego se desarrolla un modelo de
objetos del negocio compuesto por
obreros, entidades del negocio y
unidades de trabajo que juntos
realizan los casos de uso del
negocio.

Caso de Uso del

Negocio

Obrero del
Negocio

Actor del
Negocio

Objeto del
Negocio

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Ejemplo de
Modelo de Casos de Uso del negocio

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Modelo de Objetos para Vender Productos

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Ejemplo de Modelo de Objetos de Negocio

Ventas: del Pedido a la

Entrega

Comprador

Gestor de
pagos

comprador

Hacer Transferencia, y Sacar

e Ingresar Dinero.

vendedor

Cuenta

Vendedor

Importe de la
factura

Factura

Gestin de Prestamo: de la
Solicitud al Desembolso.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Capturar requisitos funcionales

A partir de la Lista de Caractersticas obtenemos requisitos

funcionales:

Identificamos requisitos basados en casos de uso.

Los casos de uso capturan tanto los requisitos funcionales

como los no funcionales que son especificos de cada caso de
uso.

Cada usuario quiere que el sistema haga algo para l o el, es

decir que lleve a cabo ciertos casos de uso.

Aqui tambien se deben especificar cual sera la apariencia de

la interfaz. ( uso de esbozos y prototipos )

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Capturar requisitos no funcionales

Especifican propiedades del sistema, como restricciones del

entorno o de la implementacin, rendimiento, dependencias de
la plataforma, facilidad de mantenimiento, extensibilidad y
fiabilidad.

Ejemplo:
Requisito de rendimiento

Cuando un comprador envia una factura para su pago, el

sistema deberia responder con una verificacionnde la solicitud
en menos de 1.0 segundos en el 90% de los casos. La duracion
de esta verificacion nunca debera exceder los 10.0 segundos a
menos que la conexin de red no funciones ( en cuyo caso se
debe informar al usuario )
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Requisitos no funcionales
Requisitos de plataforma hardware
Servidores
SUN SPARC 20 o PC Pentium.
Clientes
PC (procesador mnimo Intel 486) o Sun Sparc 5.

Restricciones en los formatos de fichero

La Versin 1.2 del Sistema de Facturacin debe soportar nombres largos de fichero.

Restricciones en la plataforma software

Software del Sistema
Sistemas operativos de cliente: Windows NT 4.0, Windows 95, o Solaris 2.6.
Sistemas operativos de servidor: Windows NT 4.0 o Solaris 2.6.
Software para Internet : Netcape Communicator 4.0 o Microsoft Internet Explorer 6.0

Otros requisitos
Seguridad, Disponibilidad, Facilidad de Aprendizaje, etc.

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

DE LA VISION A LOS REQUISITOS

Trabajo a realizar

Artefactos resultantes

Enumerar requisitos candidatos

Lista de caractersticas

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 concretos
( para requisitos especficos
de un caso de uso )

Definen una
especificacin de
requisitos
tradicional

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Flujo de Trabajo de Requisitos

De la Visin a los Requisitos

Captura de requisitos como casos de uso
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Captura de requisitos como casos de uso

Analista
de Sistemas

Arquitecto

Especificador
de Casos de Uso

Diseador de Interfaz
de usuario

Identificar Actores
Y Casos de Uso

Estructurar el Modelo
de Casos de Uso

Priorizar
Casos de Uso

Detallar
Un Caso de Uso

Esbozar
Interfaz de Usuario
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajadores y Artefactos
del Flujo de Trabajo
de Requisitos

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajadores y artefactos en la captura de requisitos

Analista de
sistemas

Especificador de
casos de uso

Diseador de interfaz
de usuario

Arquitecto

responsable de

responsable de

responsable de

responsable de

Modelo
de casos
de uso

Actor

Glosario

Caso de uso

Prototipo
de interfaz
de usuario

Descripcin
de la
arquitectura

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefactos
Cualquier tipo de descripcin o informacin creada, producida,
cambiada o utilizada por los trabajadores durante su trabajo con el
sistema.

Artefactos del flujo de trabajo de los requisitos

Modelo
de casos
de uso

Actor

Glosario

Caso de uso

Prototipo
de interfaz de
usuario

Descripcin
de la
arquitectura

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: modelo de casos de uso

Sirve como acuerdo entre clientes y desarrolladores

Proporciona la entrada fundamental para el anlisis, el diseo y las

pruebas.

Modelo de casos de uso

Sistema de casos de uso

Actor

Caso de uso
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: actor

Comprador

Un actor es un agente, alguien o algo que solicita

un servicio al sistema o acta como catalizador
para que ocurra algo.

Cada tipo de usuario del sistema se representa por uno o mas

actores ( uno por cada rol que desempea )

Persona

Banco

Sub-Sistema

Cada actor debe poseer al menos un caso de uso y cada una de

sus instancias representa a un usuario en concreto.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

El ACTOR no es un Usuario

El actor representa un rol del usuario.

El usuario es alguien que asume un rol

cuando interacta con el sistema.

Cada actor usa el

diferentes maneras.

sistema

de

Cada manera en que el actor usa el

sistema es un caso de uso.

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: caso de uso

Sacar Dinero

Un caso de uso especfica una secuencia de

acciones que el sistema puede llevar a cabo
interactuando con sus actores, incluyendo
alternativas dentro de la secuencia.

Es una especificacin del comportamiento de "cosas" dinmicas,

en este caso, de instancias (realizaciones) de los casos de uso.

Es un clasificador pues su descripcin puede incluir diagramas de

estados, diagramas de actividad, colaboraciones, y diagramas de
secuencia.

Consideramos atmicas las instancias de casos de uso, es decir

cada una de ellas se ejecuta por completo o no se ejecuta nada.
Las interferencias se manejarn a traves de gestores durante el
anlisis y el diseo.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Los casos de uso describen el sistema

Hacer una llamada

Recibir una llamada

Un sistema es descrito por un conjunto finito de casos de uso.

Un sistema potencialmente tiene un nmero infinito de
escenarios.
Cada caso de uso de un sistema debe ser enumerado, de otra
forma el sistema no sera funcionalmente completo.

Uso del Telfono Celular

Visualizar el ltimo nmero discado
Visualiza fecha y hora
Visualizar directorio
Enviar mensaje
Visualizar llamadas prdidas

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: descripcin de la arquitectura

( vista del modelo de casos de uso )

Debe incluir los casos de uso que describan alguna

funcionalidad importante y crtica.

Son los primeros en ser desarrollados durante el anlisis y

diseo

Descripcin
de la arquitectura
vista de la
arquitectura

Modelo de casos
de uso
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: glosario

Util para alcanzar un consenso entre los desarrolladores

relativo a la definicion de los diversos conceptos y
nociones, y para reducir en general el riesgo de
confusiones.

Glosario

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Artefacto: prototipo de interfaz de usuario

Nos ayudan a comprender y especificar las interacciones

entre actores humanos y el sistema durante la captura de
requisitos

Prototipo
de interfaz de
usuario

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajadores

Cada trabajador es responsable de un conjunto de artefactos.

Una misma persona puede estar asignada a diferentes

trabajadores durante un proyecto

Representa el conocimiento y las habilidades que alguien

necesita para hacerse cargo del trabajo como trabajador del
proyecto.

Analista de
sistemas

Especificador de
casos de uso

Diseador de
interfaz de
usuario

Arquitecto

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajador: analista de sistemas

Es responsable del conjunto de

requisitos que estan modelados en
los casos de uso ( funcionales y no
funcionales).

Es reponsable de delimitar el
sistema , encontrando los acrtores y
casos de uso y asegurando que el
modelo de casos de uso es
completo y consistente.

No es responsable de cada caso de

uso en particular.

Analista de
sistemas
responsable de

Modelo de
casos de uso

Actor

Glosario

Debe haber un analista para cada

sistema ( trabajando en equipo )
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajador: especificador de casos de uso

Asisten al analista en la captura

de requisitos.

Especificador
de casos de uso

Tienen como responsabilidad la

descripcin detallada de uno o
mas casos de uso

responsable de

Deben trabajar de manera

estrecha con los usuarios de
sus casos de uso.

Caso de uso

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajador: diseador de interfaz de usuario

Dan forma visual

interfaces de usuario.

Desarrollan
prototipos
interfaces de usuario
algunos casos de uso.

las

de
para

Diseador de
interfaz de usuario

responsable de

Habitualmente un prototipo por

cada actor.
Prototipo
de interfaz
de usuario

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Trabajador: arquitecto

Participa en el flujo de
trabajo de los requisitos
para describir la vista de la
arquitectura del modelo de
casos de uso.
Debe priorizar casos de
uso.
La vista de la arquitectura
del modelo de casos de uso
sirve para planificar las
iteraciones.

Arquitecto

responsable de

vista de la arquitectura
Descripcin
de la arquitectura

Modelo de casos
de uso

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividades
del Flujo de Trabajo
de Requisitos

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Flujo de trabajo

Analista
de Sistemas

Arquitecto

Especificador
de Casos de Uso

Diseador de Interfaz
de usuario

Identificar Actores
Y Casos de Uso

Estructurar el Modelo
de Casos de Uso

Priorizar
Casos de Uso

Detallar
Un Caso de Uso

Esbozar
Interfaz de Usuario
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividad: encontrar actores y casos de uso

Analista
de Sistemas
Modelo del negocio
(o modelo del dominio)

Requisitos
adicionales

Modelo de casos de uso

(esbozado)
Encontrar
actores
y casos de uso
Glosario

Lista de
caractersticas
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividad: encontrar actores y casos de uso

Encontrar los actores, que

representen a roles de personas
que intervienen en la operacin del
sistema. Ejemplo:

Vendedor. Representa a una persona que

vende y distribuye bienes o servicios. El
vendedor utiliza el sistema para conseguir
nuevos pedidos y entregar las confirmaciones
de pedido, facturas y avisos de pago.

Los obreros y actores identificados en el modelo del negocio se

utilizan como punto de partida para derivar un primer conjunto de
actores y casos de uso para el sistema en construccin.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

A la bsqueda de Actores...

Quin est interesado en un requerimiento concreto ?

En qu dominios de la organizacin se usar el sistema ?

Quin ser beneficiario de la nueva funcionalidad ?

Quin proveer, usar y/o retirar, informacin ?

Quin dar soporte y administrar el sistema ?

Usar el sistema un recurso externo ?

Un usuario actuar con diferentes roles ?

Diferentes usuarios actuarn con un mismo rol ?

Interaccionar el nuevo sistema con un sistema antiguo ?

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividad: encontrar actores y casos de uso

Encontrar los casos de uso Es una

funcionalidad proporcionada por el sistema
(deben permitir modificar, revisar , probar y ser
manejados unitariamente). Tenemos que
considerar si es completo o se ejecuta como
continuacion de otro caso de uso. Un caso de
uso debe entregar un resultado que se puede
observar y que aade valor a un actor.

Pagar factura. Lo utiliza un comprador para planificar los pagos de las facturas por
los bienes que el o ella ha solicitado y recibido.
Este caso de uso incluye tanto la planificacin como la ejecucin de un pago. Si
dividimos el caso de uso en dos partes, una para la planificacin y otra para la
ejecucin de pagos. Planificacin de Pagos no aadira valor por s mismo. El valor
se obtiene una vez que la factura ha sido pagada.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Usos del Sistema Operativo

Obtener fecha y hora
Cambiar de directorio

Uso del Sistema de Planillas

Ingresar un nuevo empleado
Ingresar las horas trabajadas

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Casos de Uso
ITEM

CASOS DE USO

ACTOR
Evaluador de
Expediente

Actualizar datos socioeconmicos

Inscribir postulante

Aceptar preinscripcin

Calificar exmenes

Capturar huella digital

Comparar huellas digitales

Digitalizar documentos

Distribuir postulantes por aula

Jefe de Admision

Emitir constancia de ingreso

Jefe de Computo

10

Evaluar ficha social

Jefe de Computo
Evaluador de
Expediente
Jefe de Computo
Asistente de Computo
Auditor
Asistente de Computo

Evaluador de
Expediente
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Categora de Actores

Primarios
Agrupa a todo aquello que utiliza las
funciones principales del sistema para
satisfacer un requerimiento.

Secundarios
Agrupa a todo aquello de lo que el
sistema se vale para atender los
requerimientos de los actores principales.

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actores Primarios en un Diagrama de Caso de

Uso
Sistema de Negociacin
Agente de Negocios
Ejecutar Orden

Inversionista

Los

Verificar Cuota

actores primarios se muestran en la parte izquierda del

diagrama.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actores Secundarios en un Diagrama de Caso de

Uso
Sistema de Negociacin

Agente de Negocios

Vender Acciones
Verificar Cuota

Inversionista
Los

Sistema
Bancario
Transferir Dinero

actores secundarios se muestran en la parte derecha

del diagrama.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Interpretar el Diagrama

Usuario

Sistema
del Banco

Retirar
Depositar
Pedir Saldo

Cliente

Administrador
De Red

Transferir entre cuentas

Reparar Cajeros

Tcnico

Hacer Mantenimiento

Administrador del
Cajero Automtico

Reponer Insumos
Solicitar Reposicin Insumos

Proveedor de
Insumos

Sistema del Cajero

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividad: encontrar actores y casos de uso

Describir brevemente cada caso de uso

Los siguientes
pasos, se agrupan
en el Caso de Uso.

Crear Documento de Venta

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Modelo de casos de uso Servicios de Hotel

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Modelado de grandes sistemas

Primero se especifica el sistema entero con sus casos de uso.

Se disea en trminos de sub-sistemas que colaboran

Los casos de uso en su totalidad se dividen en los subsistemas

Se definen interfaces que interconectan a los subsistemas

Luego cada subsistema por separado puede desarrollarse

independientemente.

Se adopta este enfoque cuando queremos:

Desarrollar un subsistema utilizando una tecnologa diferente ( solo

debe proporcionar los usos y casos de uso adecuados y siempre
que soporte las interfaces)

Gestionar el sistema de forma separada ( ubicaciones geogrficas

distintas)
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Sub-sistemas que colaboran

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Gestin de Almacn

Consultar Pedidos
no Atendidos

Reabastecer taller

Cancelar Pedido Atendido

Jefe de taller
Incidencia de Pedido

Tcnico
de taller
Atender Pedido

Consultar Pedidos a Enviar

Pasar Pedido a Envo

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Gestin de Ventas

Otorgar Incentivos

Usuario Ventas
Gestin Clientes

Jefe de Ventas
Control Estadsticas

Agente
de Ventas

Cliente
Online

Operadora

Incidencia de Pedido
( from Gestin de Almacn )
Elaborar Pedido
<<include>>

Elaborar Pedido Online

Elaborar Pedido

<<include>>
<<include>>

Consultar
Catlogo

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

Actividad: priorizar casos de uso

Arquitecto
Modelo
de casos de uso
(esbozado)

Requisitos
adicionales

Priorizar
casos de uso

Descripcin
de la arquitectura
(vista del modelo
de casos de uso)

Glosario

La vista obtenida se revisa con el jefe del proyecto, a fin de

planificar las iteraciones, ver los aspectos econmicos o del
negocio del sistema que va ha ser desarrollado.
ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

La Casa de la Calidad

Casos de Uso

X
X

El ingreso y modificacin de los datos generales de los postu-lantes

(nombre, apellidos, direccin, familiares directos, etc.).

2 Obtener el nmero de postulantes por cada modalidad de ingreso.

3.7

3 Obtener nmero de postulantes que tengan documentos en trmite.

4.1

4 Obtener cronograma entrevista personal por traslado y tercio superior

4.5

Obtener el Nmero de postulantes por evaluacin progresiva (4 y 5 de

secundaria) por colegio de procedencia.

4.1

Obtener el Nmero de Postulantes por modalidad de traslado

(institutos u otras universidades).

2.5

161.9

118.7

10.3

SUMA PESOS

27.3

Comparar huellas digitales

Capturar huella digital

Calificar exmenes

7.6

Aceptar preinscripcin

Inscribir postulante

REQUERIMIENTOS
DEL CLIENTE

Actualizar datos socioecon.

REQUERIMIENTOS TECNICOS
( Casos de Uso )

IMPORTANCIA PARA
EL CLIENTE

26.9

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO

ING. MARIO
MARIO ALBERTO
ING.
ALBERTOOSORIO
OSORIOOSORIO
OSORIO