Está en la página 1de 85

INCEPTION

Ing. Cristian Buitrago Ortega

Preliminares
Objetivos de la fase, Listado de artefactosy algo ms!!!

Establecer alguna visin inicial comn


para los objetivos del proyecto
Determinar factibilidad, y decidir si lo mejor es
investigar seriamente en la etapa de Elaboracin.
La fase puede incluir el primer trabajo de
requerimientos, y planning para la primera
Iteracin.

Objetivos

Grado de Avance:
Los artefactos son slo parcialmente completados en esta
fase.
se refinan en iteraciones posteriores

Valor Para el proyecto:


No deberan ni siquiera ser creado si no se considera
probable que se agregue valor prctico real al proyecto.

Complejidad:
puesto que son de creacin, el contenido de la
investigacin y los contenidos de los artefactos deben ser
ligeros.

Acerca de sus artefactos.

Que

se puede producir algn trabajo de


programacin de inicio con el fin de crear
una "prueba de concepto, prototipos,
para aclarar una serie de requisitos a
travs de (normalmente) prototipos Ul, y
para hacer experimentos de programacin
para cuestiones tcnicas.

Por favor, tenga en cuenta.

Ahora si..los entregables.

Ms entregables.

Recuerde que los artefactos debe ser considerados


opcionales. Elija crear slo aquellos que realmente aadan
Valor para el proyecto, y elimine aquellos si su Valor no es
probado.

El valor de un artefacto no es el documento o el diagrama


en s mismo, pero s lo es el pensamiento analtico, y la
lectura proactiva (y entonces se trata de registrar, para
evitar la reinvencin, o tener que repetir cosas
verbalmente).

Recuerden registrar los artefactos digitalmente y en lnea,


ms que en papel.

Note tambin que los artefactos UP de anteriores proyectos


pueden ser reutilizados en siguientes proyectos.

A tener en cuenta..

Requerimientos

Requerimientos son
capacidades y
condiciones los
cuales el sistema
debe cumplir.
Un primer desafo del
trabajo de
requerimientos es
encontrar, comunicar,
y recordar que es lo
que realmente se
necesita, de un modo
limpiamente
entendible para el
cliente y el equipo
de desarrolladores.

Definicin

UP promueve un conjunto de mejores


prcticas, una de las cuales es la gestin de
requerimientos.

Esto se refiere, en el contexto del cambio


inevitable de requerimientos en etapas
posteriores del desarrollo, como un enfoque
sistemtico de hallar, documentar, organizar,
y registrar y rastrear el cambios de
requerimientos de un sistema, con habilidad
y cuidado.

Requerimientos en UP

Es ms

Un estudio de factores en proyectos rechazados revel que


el 37% de los factores se relacionaban con
requerimientos, hacindolos el ms grande contribuyente
a los problemas

Funcionales: caractersticas, capacidades, seguridad.

Usabilidad: factores humanos, ayudas, documentacin.

Confiabilidad: frecuencia de fallo, recuperacin,


prediccin.

Performance: tiempos de respuesta, rendimiento,


precisin, disponibilidad, utilizacin de recursos.

Soporte: capacidad de adaptacin, mantenibilidad,


internacionalizacin, configurabilidad.

Tipos de Requerimientos:

Los

requerimientos funcionales son


explorados y registrados en el modelo de
casos de uso, y las caractersticas del
sistema en el artefacto visin.
Otros requerimientos puede ser
registrados en casos de usos relacionados,
o en el artefacto de especificaciones
suplementarias.

Artefactos para requerimientos

Requerimientos y UP
Modelo de Casos de Uso.

Donde define UP el modelo de


Casos de USO?

clientes y usuarios finales tienen metas (tambin


conocidas como necesidades).

quieren sistemas informticos que les ayuden a


alcanzarlas

Hay muchas vas para capturar estas metas y


requerimientos del sistema.

las mejores son las que son simples y familiares


porque ayudan, sobre todo a clientes y usuarios
finales, a contribuir a su definicin y evaluacin.

Para recordar

Los Casos de Uso son


informalmente

Proceso de ventas:
Un cliente arriba a la registradora con tems a
comprar. El cajero usa el sistema POS para registrar
cada producto comprado.

El sistema presenta un total de compra y detalles de


cada tem.
El cliente ingresa la informacin de pago, la cual el
sistema valida y registra.
El sistema actualiza el inventario.
El cliente recibe una factura desde el sistema y
entonces se retira con los productos.

Ejemplo Caso de uso(1):Breve

Un caso de uso es una coleccin de


sucesos relacionados y escenarios de falla
que describen a los actores usando un
sistema para ayudar a alcanzar una
meta.

Definicion Formal 1: Caso de Uso.

Es

alguien que exhibe un


comportamiento determinado, como una
persona (identificada por rol), sistema de
cmputo, u organizacin.
por ejemplo un cajero.

Definiciones Informales: Actor

1
2
3

Es una secuencia especfica de acciones e


interacciones entre actores y el sistema que se
est tratando.

Es una particular historia de uso de un sistema

O un camino a travs del caso de uso.

Definiciones Informales:
Escenario(Instancia de caso de
uso)

El

escenario de comprar exitosamente


tems con dinero.

El

escenario de fallar la compra debido a


una denegacin de transaccin con tarjeta
de crdito.

Ejemplos de Escenario:

Escenario de xito principal


Un cliente arriba a la caja con tems. El cajero utilizar el
sistema pos para registrar cada producto.

Escenarios alternativos:
Si la autorizacin de crditos rechazada, informar al
cliente y preguntar por un mtodo alternativo de pago.
S el tem no fue identificado en el sistema(p.ej. cdigo de
Barras), notificar al cajero y sugerir entrada manual del
cdigo identificador.
El sistema detecta falla para comunicar con el sistema
externo calculador de impuestos

Ejemplo de Caso de Uso 2:Casual

Un

conjunto de instancias de caso de


uso, donde cada instancia es una
secuencia de acciones que un sistema
ejecuta, que producen un resultado
observable de valor a un actor en
particular.

Definicin Formal 2: Caso de Uso


segn UP

Una actitud clave en el trabajo


con casos de uso es enfocarse
en la pregunta: como se
podra usar el sistema para
proveer Valor observable al
usuario, o cumplir sus metas?.
Meramente pensar en los
requerimientos del sistema en
trminos de una lista de
mercado, que presenta
caractersticas o funciones del
sistema a cumplir.

Concienticmonos..

Casos

de uso = requerimientos (aunque


no todos los requerimientos).

Casos de Uso y requerimientos

Los

casos de uso son documentos de


texto.
No son diagramas.
El modelado de casos de uso es
principalmente una acto de escribir texto,
no dibujar.
Sin embargo, UML define un diagrama de
caso de uso para ilustrar los nombres de
los casos de uso y actores, y sus
relaciones.

Cual es la naturaleza de los casos


de uso???

Tipos de Casos de Uso

Definicin

Responsabilidades

Son el ms comn y recomendado


tipo.
No describen los trabajos internos del
sistema, sus componentes, o diseo.
Describen el sistemas en funcin de
sus responsabilidades.

Es posible especificar el sistema qu


debe hacer (requerimientos
funcionales) sin decidir cmo lo har
(el diseo).
El qu vs. El cmo

Casos de uso de caja


negra(Definicin)

Ejemplo Caso de Uso 3: Caja


Negra:

Breve
conciso resumen de un prrafo, por lo general
del escenario principal o flujo Bsico.

Casual
Formato o informal de prrafo. Mltiples prrafos
que cubren varios escenarios

Completamente formal(fully dressed)


el ms elaborado. Todos los pasos y variaciones
son escritos en detalle, con secciones de apoyo,
tales como precondiciones y Poscondiciones.

Tipos formales

Ejemplo caso de uso 4: Fully


Dressed(1)

Ejemplo caso de uso 4: Fully


Dressed(2)

Ejemplo caso de uso 4: Fully


Dressed(3)

Ejemplo caso de uso 4: Fully


Dressed(4)

Ejemplo caso de uso 4: Fully


Dressed(5)

Ejemplo caso de uso 4: Fully


Dressed(6)

Ejemplo caso de uso 4: Fully


Dressed(7)

Ejemplo caso de uso 4: Fully


Dressed(8)

Hace

nfasis en el hecho de que hay una


interaccin continua entre los actores y el
sistema.

Variacin de dos columnas.

Ejemplo Caso de uso 5: Variacin


de dos columnas

Secciones habituales
en un caso de uso

Lista de Stakeholders e interesados:

Precondiciones

expresan lo que siempre debe ser


verdadero antes de comenzar un escenario
en el caso de uso.
No son verificadas al interior del caso de
uso
Implica un escenario de otro caso de uso
que fue exitosamente completado

Post
Condiciones

Expresan lo que debe ser verdadero al


completar exitosamente el caso de uso.
. La garanta debe cumplir las necesidades
del Stakeholder.

Precondiciones y Post - Condiciones

Precondiciones y Post - condiciones


Ejemplo

Tambin es llamado el escenario de camino feliz


Describe el camino tpico de sucesos que satisface
los intereses de los Stakeholders.
No debe incluir condiciones o ramificaciones
Los pasos pueden ser de diferentes tipos:
Interacciones entre actores.
Una validacin (usualmente por el sistema).
Un cambio estado por el sistema (por ejemplo, registrando o
modificando algo).

Escenario Principal de xito


Flujo Normal, Flujo Bsico , Flujo Principal

Ejemplo: Flujo Principal

Extensiones

Ellas indican todos los otros escenarios por ramas, ya sean


de falla o xito.

Es comn, y de hecho se espera, que la seccin de


extensiones ser considerablemente ms grande y ms
compleja que la seccin de escenario principal.

Tambin se le conoce como seccin de flujo se alternativos.

Los escenarios de extensin son ramas de el escenario


principal, y debe ser notados con respecto a este punto.

Una extensin tiene dos partes: la condicin y el manejo.

Extensiones

Escriba

la condicin como algo que puede


ser detectado por el sistema o un actor.

El

manejo de la extensin puede ser


resumida en un solo paso, o incluir una
secuencia, para indicar que la condicin
puede lanzarse dentro del rango de pasos.

Guideline para extensiones

Algunas

veces las Extensiones pueden


ser bastante complejas, y esto puede ser
motivacin para expresar la extensin
como un caso de uso separado:

Guideline para extensiones(cont)

Si

es deseable describir una condicin de


extensin como posible durante
cualquiera (o al menos la mayora) de
pasos, las etiquetas * a, * b, puede ser
usadas

Guideline para extensiones(cont)

Si

un requerimiento no funcional, atributo


de calidad, o restriccin, se relaciona
especficamente a un caso de uso,
regstrelo junto con el caso de uso:

Requerimientos Especiales

Metas de Negocio y
Casos de Uso
Gua EBP

Cmo descubrir casos de uso?


Cmo saber si algo es un caso de uso?
A que nivel puedo expresar un UC?

Respecto a los UC..

Para Anlisis de requerimientos


para un software.
Enfoquese en los casos de uso
a nivel de
PROCESOS ELEMENTALES
DE NEGOCIO(EBP).

Se debe tener en cuenta

Proviene de la Ingeniera de Procesos


de Negocio

Una tarea ejecutada por una persona,


en un lugar y en un momento, en
respuesta a un elemento de negocios.

cual aade Valor medible de


negocios y deja los datos en un
estado consistente.

Qu es EBP?

Negociar un contrato con


un proveedor
Un cajero utiliza un SI para
registrar una compra
Un Logeo de aplicacin.
Ejemplo: Cual de estos es un caso
de uso EBP?

Pueden intervenir uno o dos actores


No es una accin computacional(p.ej. eliminar un registro, imprimir un
documento)
El escenario principal de xito es de entre 5 a 10 pasos.
No se realiza en das o en varias sesiones, de hecho se realizar en una sola
sesin. Su duracin es unos pocos minutos a una hora de duracin
Tiene Valor aadido para el negocio.
Los datos que quedan en un estado consistente.

Caracteristicas de un UC(Guia
EBP)

Paso pequeo,
como "eliminar un
elemento de lnea"
o "imprimir el
documento

hace falta das y


varias sesiones, al
igual que "negociar
un contrato de
abastecimiento,"

No tiene valor
aadido para el
negocio

Un UC no es

Utilizando EBP---->
Para hallar UC Vlidos

Los actores tienen metas..........

Usan software para satisfacerlas

Un UC sirve (o debera servir)


para cumplir una meta de un
usuario en el sistema.

Recuerde que..

Hallar las
metas de
Usuario

Definir un
UC para c/
u

Por lo tantoPara hallar UC!

Ms que preguntar.

Pregunte

Donde estn los


UC?

Donde estn las


metas?

Es decir.

Capturar o
procesar
una venta

UC
Procesar
Venta.

Meta
El nombre de un UC debe reflejar
su meta.Por ejemplo

Prevenir robo de informacin


Es de ms alta jerarqua que un EBP:
Puede se llamado un objetivo
empresarial(no EBP).

Identificarme como Usuario


Parece cercano al nivel de Usuario
(EBP), pero no lo es, debido a que no
tiene valor agregado al negocio.

Busqueda de Jerarqua de Metas


Ejemplos

Los objetivos son usualmente


compuestos, del nivel
empresarial(lucro/valor) a metas
intermedias de soporte, para soportar
metas de subfuncin al interior de las
aplicaciones(entradas validas).

Similarmente, los casos de uso de


deben ser escritos a diferentes
niveles para satisfacer esas
metas, y pueden estar compuestas
de casos de uso de nivel bajo.

Procesos de soporte..

Hallando Actores,
Metas y UC

1.

2.

3.

Identificar Actores primarios: aquellos


que deben cumplir metas de usuario a
travs del uso de servicios del sistema.
Para cada uno, identificar sus metas de
usuario: concentrarse al nivel de metas
de usuario que satisfagan EBP.
Definir los casos de uso que satisfagan
metas de usuario: nmbrelos acorde a
sus metas.

PROCEDIMIENTO PARA ESCRIBIR


UC!!!!!!!!

Quien
Quien

comienza y para el sistema?


hace la administracin de usuarios
de seguridad?
Quien hace la administracin del sistema?
Es el tiempo un actor porque el sistema
hace algo en respuesta a un evento
temporal?
Tiene evala la actividad del sistema o
performance?
Quien Ejecuta Procesos EBP?

ActoresPreguntese

Registre

los actores primarios y sus metas


en una lista:

Actores.Sugerencia

En

General, se deben definir un caso de


uso de nivelEBP para cada meta de
usuario:

Meta
de
Usuario

UC EBP

UC.Definirlos.

Nombre el caso
de uso similar a
una meta de
usuario.
nombre un caso
de uso
comenzando con
un verbo.

UCsugerencias al Definirlos

La Excepcin es CRUD
Rena Objetivos de
CRUD en un solo UC
nombrndolo:
administrar<x>

UCExcepcin

Estilos de Casos de Uso

Mantenga la interfaz de usuario fuera


Enfquese en los pasos EBP
Se enfoca en los intentos que hace el usuario
Y en las responsabilidades del Sistema
Evitar los detalles de UI

Estilo de escritura esencial..

Estilo EsencialEjemplo blackbox

Estilo Esencial..Ejemplo Fully


Dressed

las decisiones de UI
figuran en el texto del
caso de uso

El texto incluso pueden


mostrar prototipos de
ventanas de interfaz.

Estilo concreto (evitarlo durante el


trabajo de requerimientos):

Estilo concreto.Ejemplos

Diagramas de casos de uso

Los diagramas de casos de uso y las


relaciones de los casos de uso son
secundarias en el trabajo con casos de uso

Los casos de uso son documentos de texto.

Hacer casos de uso significa escribir


texto(y ocasionalmente Prototipos de UI).

Osea

Gracias..