3ero Manual IngenieSistemasI

INGENIERA DE
SISTEMAS - I
Presentacin
Ingeniera de Sistemas I Grupo IDAT

Desarrollo y Edicin a cargo del Programa de Computacin e Informtica.
Director Ejecutivo : Ing. Rolando Rojas Gallo
Coordinador Acadmico : Ing. Jos Garca La Riva
Coordinador Administrativo : Sr. Julio Cabrera Calle.

Diseo y Diagramacin : Srta. Katy Lzaro Nez

Elaborado por : Prof. Jorge Gonzales Marav
Prof. Ponce Becerra, Carol Fanny
Prof. Cuya Camara, Jos

Produccin : Departamento de Impresiones del Grupo IDAT
Los derechos de edicin, distribucin y contenidos de este texto son de exclusividad del
GRUPO IDAT.

Presentacin

Ingeniera de Sistemas I pertenece a la lnea formativa que imparte conocimientos
relacionados con el proceso de ingeniera de software, metodologa RUP y UML
(Lenguaje de Moldeamiento Unifcado) para desarrollar un software de calidad.
El presente manual se ha diseado por captulos que se desarrollan en las semanas
acadmicas, en cada captulo se desarrollan los contenidos tericos con ejemplos
resueltos y propuestos.
El curso es terico-prctico, cuenta con laboratorio para desarrollar casos de
proyectos de software utilizando la herramienta de modelado de Rational Roose,
bsicamente se desarrolla la disciplinas de Modelado de Negocio y Modelo de
Requerimientos.

ndice

Presentacin 5
Captulo 1: Ingeniera Software, RUP y UML 9
1. Ingeniera de Software 11
2. Metodologa RUP 18
3. Tcnicas de Recoleccin de Informacin 32
4. UML 39
Capitulo 2: Modelo de Negocio 45
1. Modelo de Caso de Uso del Negocio 50
2. Modelo de Anlisis del Negocio 51
Capitulo 3: Modelo de Requerimientos 77
Bibliografa 106

CAPTULO
1
Ingeniera Software, RUP y UML

Ingeniera de Software

Metodologa RUP

Tcnicas de Recoleccin de Informacin

UML
11
INGENIERA DE SOFTWARE
Ingeniera de Sistemas I
PROGRAMA DE COMPUTACIN E INFORMTICA- IDAT
1. QU ES INGENIERA DE SOFTWARE
Es la disciplina o rea de la informtica que ofrece mtodos y tcnicas para
desarrollar y mantener software de calidad.
Esta ingeniera trata con reas muy diversas de la informtica y de las ciencias de
la computacin, tales como construccin de compiladores, sistemas operativos,
o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del
desarrollo de cualquier tipo de sistemas de informacin y aplicables a infnidad de
reas: negocios, investigacin cientfca, medicina, produccin, logstica, banca,
control de trfco, meteorologa, derecho, Internet, Intranet, etc.
2. MODELOS DE PROCESOS DE INGENIERA DE SOFTWARE
La ingeniera de software tiene varios modelos, paradigmas o flosofas de
desarrollo en los cuales se puede apoyar para la realizacin de software, de los
cuales podemos destacar a stos por ser los ms utilizados y los ms completos:
Modelo en cascada o Clsico (modelo tradicional)
Modelo en espiral (modelo evolutivo)
Modelo de prototipos
Desarrollo por etapas
Desarrollo iterativo y creciente o Iterativo e Incremental
RAD (Rapid Application Development)
3. METODOLOGAS DE DESARROLLO DE SOFTWARE
Qu metodologa debo usar para el desarrollo de un Software?
Todos en algn momento nos hemos hecho esta pregunta, cuando hemos tenido
que desarrollar un sistema o aplicacin de software. Y de hecho esta pregunta se
torna muy importante, pues como arquitectos de Software, debemos tener un plano
en que apoyarnos.
Todo desarrollo de software es riesgoso y difcil de controlar, pero si no llevamos
una metodologa de por medio, lo que obtenemos es clientes insatisfechos con el
resultado y desarrolladores an ms insatisfechos.
Sin embargo, muchas veces no se toma en cuenta el utilizar una metodologa
adecuada, sobre todo cuando se trata de proyectos pequeos de dos o tres meses.
Lo que se hace con este tipo de proyectos es separar rpidamente el aplicativo en
procesos, cada proceso en funciones, y por cada funcin determinar un tiempo
aproximado de desarrollo.
Cuando los proyectos que se van a desarrollar son de mayor envergadura, ah
si toma sentido el basarnos en una metodologa de desarrollo, y empezamos a
buscar cual sera la ms apropiada para nuestro caso. Lo cierto es que muchas
veces no encontramos la ms adecuada y terminamos por hacer o disear nuestra
12
propia metodologa, algo que por supuesto no esta mal, siempre y cuando cumpla
con el objetivo.
Muchas veces realizamos el diseo de nuestro software de manera rgida, con los
requerimientos que el cliente nos solicit, de tal manera que cuando el cliente en la
etapa fnal (etapa de prueba), solicita un cambio se nos hace muy difcil realizarlo,
pues si lo hacemos, altera muchas cosas que no habamos previsto, y es justo ste,
uno de los factores que ocasiona un atraso en el proyecto y por tanto la incomodidad
del desarrollador por no cumplir con el cambio solicitado y el malestar por parte del
cliente por no tomar en cuenta su pedido. Obviamente para evitar estos incidentes
debemos haber llegado a un acuerdo formal con el cliente, al inicio del proyecto, de
tal manera que cada cambio o modifcacin no perjudique al desarrollo del mismo.
Por experiencia, muchas veces los usuarios fnales, se dan cuenta de las cosas
que dejaron de mencionar, recin en la etapa fnal del proyecto, pese a que se les
mostr un prototipo del software en la etapa inicial del proyecto.
Los proyectos fracasan cuando exceden el tiempo y presupuesto, o simplemente
no cumplen con las expectativas del cliente.
Para dar una idea de qu metodologa podemos utilizar y cual se adapta ms
a nuestro medio, mencionar tres de ellas de las que se consideran las ms
importantes, tal como: RUP, XP y MSF.
Rational Unifed Process (RUP)
La metodologa RUP, llamada as por sus siglas en ingls Rational Unifed Process,
es un proceso de desarrollo de software. Un Proceso de desarrollo de software es
el conjunto de actividades necesarias para transformar los requisitos de un usuario
en un sistema de software. Sin embargo el proceso de desarrollo es ms que un
simple proceso; es un marco de trabajo genrico que puede especializarse para
una gran variedad de sistemas de software, para diferentes reas de aplicacin,
diferentes tipos de organizaciones y diferentes tamaos de proyectos.
El Proceso Unifcado est basado en componentes, lo cual quiere decir que el
sistema de software en construccin est formado por componentes de software
interconectados a travs de interfaces bien defnidas.
El Proceso Unifcado se basa en:
Dirigido por Casos de Uso
Centrado en la Arquitectura
Es Iterativo e Incremental
El RUP se divide en 4 fases:
Inicio, El Objetivo en esta etapa es determinar la visin del proyecto.
Elaboracin, En esta etapa el objetivo es determinar la arquitectura ptima.
Construccin, En esta etapa el objetivo es llevar a obtener la capacidad
operacional inicial.
Transicin, El objetivo es llegar a obtener el release del proyecto.
13
Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual
consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos
de una iteracin se establecen en funcin de la evaluacin de las iteraciones
precedentes.
Vale mencionar que el ciclo de vida que se desarrolla por cada iteracin, es llevada
bajo dos disciplinas:
Disciplina de Desarrollo:
Ingeniera de Negocios: Entendiendo las necesidades del negocio.
Requerimientos: Trasladando las necesidades del negocio a un sistema
automatizado.
Anlisis y Diseo: Trasladando los requerimientos dentro de la arquitectura de
software.
Implementacin: Creando software que se ajuste a la arquitectura y que tenga
el comportamiento deseado.
Pruebas: Asegurndose que el comportamiento requerido es el correcto y que
todo los solicitado esta presente.
Disciplina de Soporte
Confguracin y administracin del cambio: Guardando todas las versiones del
proyecto.
Administrando el proyecto: Administrando horarios y recursos.
Ambiente: Administrando el ambiente de desarrollo.
Distribucin: Hacer todo lo necesario para la salida del proyecto.
Figura_01: Fases e Iteraciones de la Metodologa RUP
14
Es recomendable que a cada una de estas iteraciones se les clasifque y ordene
segn su prioridad, y que cada una se convierte luego en un entregable al cliente.
Esto trae como benefcio la retroalimentacin que se tendra en cada entregable o
en cada iteracin.
Los elementos del RUP son:
Actividades, Son los procesos que se llegan a determinar en cada iteracin.
Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.
Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de
modelo.
Una particularidad de esta metodologa es que, en cada ciclo de iteracin, se hace
exigente el uso de artefactos, siendo por este motivo, una de las metodologas ms
importantes para alcanzar un grado de certifcacin en el desarrollo del software.
Principales Benefcios del RUP:
Provee lineamientos para un desarrollo efciente de software de calidad
Captura-Presenta las mejores prcticas
Aprender de la experiencia anterior
Verifcar la calidad
Desarrollo iterativo
Arquitectura basada en componentes
Modelar visualmente el sistema
Mejora la comunicacin con los usuarios
Extensin del material de capacitacin
Promueve una visin y una cultura Comn
Guas sobre cmo utilizar herramientas
Reduce Riesgos e incrementa la Predictibilidad
Extreme Programing (XP)
Es una de las metodologas de desarrollo de software ms exitosas en la actualidad
utilizadas para proyectos de corto plazo, corto equipo y cuyo plazo de entrega
era ayer. La metodologa consiste en una programacin rpida o extrema, cuya
particularidad es tener como parte del equipo, al usuario fnal, pues es uno de los
requisitos para llegar al xito del proyecto.
Figura_02: Metodologa Extreme Programing
15
Caractersticas de XP, la metodologa se basa en:
Pruebas Unitarias: se basa en las pruebas realizadas a los principales procesos,
de tal manera que adelantndonos en algo hacia el futuro, podamos hacer
pruebas de las fallas que pudieran ocurrir. Es como si nos adelantramos a
obtener los posibles errores.
Refabricacin: se basa en la reutilizacin de cdigo, para lo cual se crean
patrones o modelos estndares, siendo ms fexible al cambio.
Programacin en pares: una particularidad de esta metodologa es que propone
la programacin en pares, la cual consiste en que dos desarrolladores participen
en un proyecto en una misma estacin de trabajo. Cada miembro lleva a cabo
la accin que el otro no est haciendo en ese momento. Es como el chofer y el
copiloto: mientras uno conduce, el otro consulta el mapa.
Qu es lo que propone XP?
Empieza en pequeo y aade funcionalidad con retroalimentacin continua
El manejo del cambio se convierte en parte sustantiva del proceso
El costo del cambio no depende de la fase o etapa
No introduce funcionalidades antes que sean necesarias
El cliente o el usuario se convierte en miembro del equipo
Derechos del Cliente
Decidir que se implementa
Saber el estado real y el progreso del proyecto
Aadir, cambiar o quitar requerimientos en cualquier momento
Obtener lo mximo de cada semana de trabajo
Obtener un sistema funcionando cada 3 o 4 meses
Derechos del Desarrollador
Decidir como se implementan los procesos
Crear el sistema con la mejor calidad posible
Pedir al cliente en cualquier momento aclaraciones de los requerimientos
Estimar el esfuerzo para implementar el sistema
Cambiar los requerimientos en base a nuevos descubrimientos
Lo fundamental en este tipo de metodologa es:
La comunicacin, entre los usuarios y los desarrolladores
La simplicidad, al desarrollar y codifcar los mdulos del sistema
La retroalimentacin, concreta y frecuente del equipo de desarrollo, el cliente y
los usuarios fnales
16
Microsoft Solution Framework (MSF)
Esta es una metodologa fexible e interrelacionada con una serie de conceptos,
modelos y prcticas de uso, que controlan la planifcacin, el desarrollo y la gestin
de proyectos tecnolgicos. MSF se centra en los modelos de proceso y de equipo
dejando en un segundo plano las elecciones tecnolgicas.
Figura_03: Metodologa MSF
MSF tiene las siguientes caractersticas:
Adaptable: es parecido a un comps, usado en cualquier parte como un mapa,
del cual su uso es limitado a un especfco lugar.
Escalable: puede organizar equipos tan pequeos entre 3 o 4 personas, as
como tambin, proyectos que requieren 50 personas a ms.
Flexible: es utilizada en el ambiente de desarrollo de cualquier cliente.
Tecnologa Agnstica: porque puede ser usada para desarrollar soluciones
basadas sobre cualquier tecnologa.
MSF se compone de varios modelos encargados de planifcar las diferentes partes
implicadas en el desarrollo de un proyecto: Modelo de Arquitectura del Proyecto,
Modelo de Equipo, Modelo de Proceso, Modelo de Gestin del Riesgo, Modelo de
Diseo de Proceso y fnalmente el modelo de Aplicacin.
Modelo de Arquitectura del Proyecto: Diseado para acortar la planifcacin
del ciclo de vida. Este modelo defne las pautas para construir proyectos
empresariales a travs del lanzamiento de versiones.
Modelo de Equipo: Este modelo ha sido diseado para mejorar el rendimiento
del equipo de desarrollo. Proporciona una estructura fexible para organizar
los equipos de un proyecto. Puede ser escalado dependiendo del tamao del
proyecto y del equipo de personas disponibles.
Modelo de Proceso: Diseado para mejorar el control del proyecto, minimizando
el riesgo, y aumentar la calidad acortando el tiempo de entrega. Proporciona
una estructura de pautas a seguir en el ciclo de vida del proyecto, describiendo
las fases, las actividades, la liberacin de versiones y explicando su relacin
con el Modelo de equipo.
Modelo de Gestin del Riesgo: Diseado para ayudar al equipo a identifcar
las prioridades, tomar las decisiones estratgicas correctas y controlar
17
las emergencias que puedan surgir. Este modelo proporciona un entorno
estructurado para la toma de decisiones y acciones valorando los riesgos que
puedan provocar.
Modelo de Diseo del Proceso: Diseado para distinguir entre los objetivos
empresariales y las necesidades del usuario. Proporciona un modelo centrado
en el usuario para obtener un diseo efciente y fexible a travs de un
enfoque iterativo. Las fases de diseo conceptual, lgico y fsico proveen tres
perspectivas diferentes para los tres tipos de roles: los usuarios, el equipo y los
desarrolladores.
Modelo de Aplicacin: Diseado para mejorar el desarrollo, el mantenimiento
y el soporte, proporciona un modelo de tres niveles para disear y desarrollar
aplicaciones software. Los servicios utilizados en este modelo son escalables, y
pueden ser usados en un solo ordenador o incluso en varios servidores.
Conclusin: Todas las metodologas modernas usan al UML, para el desarrollo de
sus modelos.
La Metodologa RUP es ms adaptable para proyectos de largo plazo.
La Metodologa XP en cambio, se recomienda para proyectos de corto plazo.
La Metodologa MSF se adapta a proyectos de cualquier dimensin y de
cualquier tecnologa.
Podemos concluir adems, que lo ms importante antes de elegir la metodologa
que usars para la implementacin de tu software, es determinar el alcance que
tendr y luego de ah ver cual es la que ms se acomoda en tu aplicacin.
18
METODOLOGA RUP
1. INTRODUCCIN
Es un proceso para el desarrollo de aplicaciones, es un conglomerado de las mejores
prcticas para conducir las actividades de desarrollo, del equipo de la ingeniera
de software. Como una plataforma de procesos que abarca todas las prcticas de
la industria, el RUP permite seleccionar fcilmente el conjunto de componentes
de proceso que se ajustan a las necesidades especfcas del proyecto. Se podrn
alcanzar resultados predecibles unifcando el equipo con procesos comunes
que optimicen la comunicacin y creen un entendimiento comn para todas las
tareas, responsabilidades y artefactos. Desde un nico sitio web centralizado de
intercambio, el Software Rational, las plataformas, herramientas y expertos de
dominios proveen los componentes de proceso necesarios para el desarrollo de
software de calidad.
Este documento presenta un resumen de Rational Unifed Process (RUP). Se
describe la evolucin del proceso, caractersticas principales y estructura del
proceso. RUP es un producto comercial desarrollado y comercializado por Rational
Software, una compaa de IBM.
2. CARACTERSTICAS ESENCIALES
Los autores de RUP destacan que el proceso de software propuesto por RUP tiene
tres caractersticas esenciales: est dirigido por los Casos de Uso, est centrado
en la arquitectura, y es iterativo e incremental.
Proceso dirigido por Casos de Uso
Los Casos de Uso son una tcnica de captura de requisitos que fuerza a pensar
en trminos de importancia para el usuario y no slo en trminos de funciones
que sera bueno contemplar. Se defne un Caso de Uso como un fragmento de
funcionalidad del sistema que proporciona al usuario un valor aadido. Los Casos
de Uso representan los requisitos funcionales del sistema.
Los Casos de Uso no slo inician el proceso de desarrollo sino que proporcionan
un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son
generados en las diferentes actividades del proceso de desarrollo.
Proceso centrado en la arquitectura
La arquitectura de un sistema es la organizacin o estructura de sus partes ms
relevantes, lo que permite tener una visin comn entre todos los involucrados
(desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria
para controlar el desarrollo.
19
La arquitectura involucra los aspectos estticos y dinmicos ms signifcativos del
sistema, est relacionada con la toma de decisiones que indican cmo tiene que
ser construido el sistema y ayuda a determinar en qu orden. Adems la defnicin
de la arquitectura debe tomar en consideracin elementos de calidad del sistema,
rendimiento, reutilizacin y capacidad de evolucin por lo que debe ser fexible
durante todo el proceso de desarrollo. La arquitectura se ve infuenciada por la
plataforma software, sistema operativo, gestor de bases de datos, protocolos,
consideraciones de desarrollo como sistemas heredados. Muchas de estas
restricciones constituyen requisitos no funcionales del sistema.
Proceso iterativo e incremental
El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido
al equilibrio de la forma y la funcin en el desarrollo del producto, lo cual se consigue
con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso
iterativo e incremental en donde el trabajo se divide en partes ms pequeas o mini
proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya
logrando durante cada mini proyecto, as durante todo el proceso de desarrollo.
Cada mini proyecto se puede ver como una iteracin (un recorrido ms o menos
completo a lo largo de todos los fujos de trabajo fundamentales) del cual se obtiene
un incremento que produce un crecimiento en el producto.
Una iteracin puede realizarse por medio de una cascada como se muestra en
la Figura 04. Se pasa por los fujos fundamentales (Requisitos, Anlisis, Diseo,
Implementacin y Pruebas), tambin existe una planifcacin de la iteracin, un
anlisis de la iteracin y algunas actividades especfcas de la iteracin. Al fnalizar
se realiza una integracin de los resultados con lo obtenido de las iteraciones
anteriores.
Figura_04: Una iteracin RUP
El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada
iteracin aborda una parte de la funcionalidad total, pasando por todos los fujos
de trabajo relevantes y refnando la arquitectura. Cada iteracin se analiza cuando
termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado
los existentes, afectando a las iteraciones siguientes. Durante la planifcacin de
20
los detalles de la siguiente iteracin, el equipo tambin examina cmo afectarn
los riesgos que an quedan al trabajo en curso. Toda la retroalimentacin de la
iteracin pasada permite reajustar los objetivos para las siguientes iteraciones.
Se contina con esta dinmica hasta que se haya fnalizado por completo con la
versin actual del producto.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o
menor hincapi en los distintas actividades.
3. MEJORES PRCTICAS DE RUP
RUP identifca 6 best practices con las que defne una forma efectiva de trabajar
para los equipos de desarrollo de software.
Gestin de requisitos
RUP brinda una gua para encontrar, organizar, documentar, y seguir los cambios
de los requisitos funcionales y restricciones. Utiliza una notacin de Caso de Uso y
escenarios para representar los requisitos.
Desarrollo de software iterativo
Desarrollo del producto mediante iteraciones con hitos bien defnidos, en las cuales
se repiten las actividades pero con distinto nfasis, segn la fase del proyecto.
Desarrollo basado en componentes
La creacin de sistemas intensivos en software requiere dividir el sistema en
componentes con interfaces bien defnidas, que posteriormente sern ensamblados
para generar el sistema. Esta caracterstica en un proceso de desarrollo permite
que el sistema se vaya creando a medida que se obtienen o se desarrollan sus
componentes.
Modelado visual (usando UML)
UML es un lenguaje para visualizar, especifcar, construir y documentar los artefactos
de un sistema software. Es un estndar de la OMG (http://www.omg.org). Utilizar
herramientas de modelado visual facilita la gestin de dichos modelos, permitiendo
ocultar o exponer detalles cuando sea necesario. El modelado visual tambin ayuda
a mantener la consistencia entre los artefactos del sistema: requisitos, diseos e
implementaciones. En resumen, el modelado visual ayuda a mejorar la capacidad
del equipo para gestionar la complejidad del software.
Verifcacin continua de la calidad
Es importante que la calidad de todos los artefactos se evale en varios puntos
durante el proceso de desarrollo, especialmente al fnal de cada iteracin. En esta
verifcacin las pruebas juegan un papel fundamental y se integran a lo largo de todo
21
el proceso. Para todos los artefactos no ejecutables las revisiones e inspecciones
tambin deben ser continuas.
Gestin de los cambios
El cambio es un factor de riesgo crtico en los proyectos de software. Los artefactos
software cambian no slo debido a acciones de mantenimiento posteriores a la entrega
del producto, sino que durante el proceso de desarrollo, especialmente importantes
por su posible impacto son los cambios en los requisitos. Por otra parte, otro gran
desafo que debe abordarse es la construccin de software con la participacin de
mltiples desarrolladores, posiblemente distribuidos geogrfcamente, trabajando a
la vez en una release, y quizs en distintas plataformas. La ausencia de disciplina
rpidamente conducira al caos. La Gestin de Cambios y de Confguracin es la
disciplina de RUP encargada de este aspecto.
4. ESTRUCTURA DEL PROCESO
El proceso puede ser descrito en dos dimensiones o ejes:
Eje horizontal: Representa el tiempo y es considerado el eje de los aspectos
dinmicos del proceso. Indica las caractersticas del ciclo de vida del proceso
expresado en trminos de fases, iteraciones e hitos. Se puede observar en la
Figura 05 que RUP consta de cuatro fases: Inicio, Elaboracin, Construccin y
Transicin. Como se mencion anteriormente cada fase se subdivide a la vez en
iteraciones.
Eje vertical: Representa los aspectos estticos del proceso. Describe el proceso
en trminos de componentes de proceso, disciplinas, fujos de trabajo, actividades,
artefactos y roles.
Figura_05: Estructura de RUP
4.1 Estructura Dinmica del proceso. Fases e iteraciones
RUP se repite a lo largo de una serie de ciclos que constituyen la vida de un
producto. Cada ciclo concluye con una generacin del producto para los clientes.
22
Cada ciclo consta de cuatro fases: Inicio, Elaboracin, Construccin y Transicin.
Cada fase se subdivide a la vez en iteraciones, el nmero de iteraciones en cada
fase es variable.
Cada fase se concluye con un hito bien defnido, un punto en el tiempo en el cual se
deben tomar ciertas decisiones crticas y alcanzar las metas clave antes de pasar
a la siguiente fase, ese hito principal de cada fase se compone de hitos menores
que podran ser los criterios aplicables a cada iteracin. Los hitos para cada una
de las fases son: Inicio, Elaboracin, Construccin, Transicin. Las fases y sus
respectivos hitos se ilustran en la Figura 06.
Figura_06: Fases e hitos en RUP
La duracin y esfuerzo dedicado en cada fase es variable dependiendo de las
caractersticas del proyecto. Sin embargo, la Figura ilustra porcentajes frecuentes
al respecto. Consecuente con el esfuerzo sealado, la Figura ilustra una distribucin
tpica de recursos humanos necesarios a lo largo del proyecto.
Inicio Elaboracin Construccin Transicin
Esfuerzo 5% 20% 65% 10%
Tiempo
Dedicado 10% 30% 50% 10%

Figura: Distribucin tpicas de esfuerzo y tiempo
A. Inicio
Durante la fase de inicio se defne el modelo del negocio y el alcance del proyecto.
Se identifcan todos los actores y Casos de Uso, y se disean los Casos de Uso
ms esenciales (aproximadamente el 20% del modelo completo), se desarrolla una
descripcin del producto fnal a partir de una buena idea. Se desarrolla, un plan de
negocio para determinar que recursos deben ser asignados al proyecto.
Los objetivos de esta fase son:
Establecer el mbito del proyecto y sus lmites.
Encontrar los Casos de Uso crticos del sistema, los escenarios bsicos que
23
defnen la funcionalidad.
Mostrar al menos una arquitectura candidata para los escenarios principales.
Estimar el coste en recursos y tiempo de todo el proyecto.
Estimar los riesgos, las fuentes de incertidumbre.
Los resultados de la fase de inicio deben ser [RSC98]:
Un documento de visin: Una visin general de los requerimientos del proyecto,
caractersticas clave y restricciones principales.
Modelo inicial de Casos de Uso (10-20% completado).
Un glosario inicial: Terminologa clave del dominio.
El caso de negocio.
Lista de riesgos y plan de contingencia.
Plan del proyecto, mostrando fases e iteraciones.
Modelo de negocio, si es necesario
Prototipos exploratorios para probar conceptos o la arquitectura candidata.
B. Elaboracin
El propsito de la fase de elaboracin es analizar el dominio del problema, establecer
los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los
mayores riesgos.
En esta fase se construye un prototipo de la arquitectura, que debe evolucionar
en iteraciones sucesivas hasta convertirse en el sistema fnal. Este prototipo debe
contener los Casos de Uso crticos identifcados en la fase de inicio. Tambin debe
demostrarse que se han evitado los riesgos ms graves.
Defnir, validar y cimentar la arquitectura.
Completar la visin.
Crear un plan fable para la fase de construccin. Este plan puede evolucionar
en sucesivas iteraciones. Debe incluir los costes si procede.
Demostrar que la arquitectura propuesta soportar la visin con un coste
razonable y en un tiempo razonable.
Al terminar deben obtenerse los siguientes resultados:
Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos
y actores identifcados, la mayora de los casos desarrollados.
Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso especfco.
Descripcin de la arquitectura software.
Un prototipo ejecutable de la arquitectura.
Lista de riesgos y caso de negocio revisados.
Plan de desarrollo para el proyecto.
Un caso de desarrollo actualizado que especifca el proceso a seguir.
Un manual de usuario preliminar (opcional).
Si no se superan los criterios de evaluacin quiz sea necesario abandonar el
24
proyecto o replanterselo considerablemente.
C. Construccin
La fnalidad principal de esta fase es alcanzar la capacidad operacional del producto
de forma incremental a travs de las sucesivas iteraciones. Durante esta fase todos
los componentes, caractersticas y requisitos deben ser implementados, integrados
y probados en su totalidad, obteniendo una versin aceptable del producto.
Los objetivos concretos segn incluyen:
Minimizar los costes de desarrollo mediante la optimizacin de recursos y
evitando el tener que rehacer un trabajo o incluso desecharlo.
Conseguir una calidad adecuada tan rpido como sea prctico.
Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan
rpido como sea prctico.
Los resultados de la fase de construccin deben ser :
Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e

Implementacin)
Arquitectura ntegra (mantenida y mnimamente actualizada)
Riesgos Presentados Mitigados
Plan del Proyecto para la fase de Transicin.
Manual Inicial de Usuario (con sufciente detalle)
Prototipo Operacional beta
Caso del Negocio Actualizado
Los criterios de evaluacin de esta fase son los siguientes:
El producto es estable y maduro como para ser entregado a la comunidad de
usuario para ser probado.
Todos los usuarios expertos estn listos para la transicin en la comunidad de
usuarios.
Son aceptables los gastos actuales versus los gastos planeados.
D. Transicin
La fnalidad de la fase de transicin es poner el producto en manos de los usuarios
fnales, para lo que se requiere desarrollar nuevas versiones actualizadas del
producto, completar la documentacin, entrenar al usuario en el manejo del
producto, y en general tareas relacionadas con el ajuste, confguracin, instalacin
y facilidad de uso del producto.
En se citan algunas de las cosas que puede incluir esta fase:
Prueba de la versin Beta para validar el nuevo sistema frente a las expectativas
de los usuarios
Funcionamiento paralelo con los sistemas legados que estn siendo sustituidos
por nuestro proyecto.
25
Conversin de las bases de datos operacionales.
Entrenamiento de los usuarios y tcnicos de mantenimiento.
Traspaso del producto a los equipos de marketing, distribucin y venta.
Los principales objetivos de esta fase son:
Conseguir que el usuario se valga por si mismo.
Un producto fnal que cumpla los requisitos esperados, que funcione y satisfaga
sufcientemente al usuario.
Los resultados de la fase de transicin son :
Prototipo Operacional
Documentos Legales
Caso del Negocio Completo
Lnea de Base del Producto completa y corregida que incluye todos los modelos
del sistema
Descripcin de la Arquitectura completa y corregida
Las iteraciones de esta fase irn dirigidas normalmente a conseguir una nueva
versin.
Los criterios de evaluacin de esta fase son los siguientes:
El usuario se encuentra satisfecho.
Son aceptables los gastos actuales versus los gastos planifcados.

4.2 Estructura Esttica del proceso. Roles, actividades, artefactos y
fujos de trabajo
Un proceso de desarrollo de software defne quin hace qu, cmo y cundo.
RUP defne cuatro elementos los roles, que responden a la pregunta Quin?, las
actividades que responden a la pregunta Cmo?, los productos, que responden
a la pregunta Qu? y los fujos de trabajo de las disciplinas que responde a la
pregunta Cundo? (ver Figura) .
Figura_07: Relacin entre roles, actividades, artefactos
26

Figura_08: Detalle de un workfow mediante roles, actividades y artefactos
A. Roles
Un rol defne el comportamiento y responsabilidades de un individuo, o de un grupo
de individuos trabajando juntos como un equipo. Una persona puede desempear
diversos roles, as como un mismo rol puede ser representado por varias personas.
Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades
como el ser el dueo de un conjunto de artefactos .

RUP defne grupos de roles, agrupados por participacin en actividades relacionadas.
Estos grupos son:
Analistas:
Analista de procesos de negocio.
Diseador del negocio.
Analista de sistema.
Especifcador de requisitos.
Desarrolladores:
Arquitecto de software.
Diseador
Diseador de interfaz de usuario
Diseador de cpsulas.
Diseador de base de datos.
Implementador.
Integrador.
Gestores:
Jefe de proyecto
Jefe de control de cambios.
Jefe de confguracin.
Jefe de pruebas
Jefe de despliegue
27
Ingeniero de procesos
Revisor de gestin del proyecto
Gestor de pruebas.
Apoyo:
Documentador tcnico
Administrador de sistema
Especialista en herramientas
Desarrollador de cursos
Artista grfco
Especialista en pruebas:
Especialista en Pruebas (tester)
Analista de pruebas
Diseador de pruebas
Otros roles:
Stakeholders.
Revisor
Coordinacin de revisiones
Revisor tcnico
Cualquier rol
B. Actividades
Una actividad en concreto es una unidad de trabajo que una persona que desempee
un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto,
normalmente expresado en trminos de crear o actualizar algn producto.
C. Artefactos
Un producto o artefacto es un trozo de informacin que es producido, modifcado
o usado durante el proceso de desarrollo de software. Los productos son los
resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener
el producto fnal .
Un artefacto puede ser cualquiera de los siguientes:
Un documento, como el documento de la arquitectura del software.
Un modelo, como el modelo de Casos de Uso o el modelo de diseo.
Un elemento del modelo, un elemento que pertenece a un modelo como una
clase, un Caso de Uso o un subsistema.
D. Flujos de trabajo
Con la enumeracin de roles, actividades y artefactos no se defne un proceso,
necesitamos contar con una secuencia de actividades realizadas por los diferentes
roles, as como la relacin entre los mismos. Un fujo de trabajo es una relacin
de actividades que nos producen unos resultados observables. A continuacin se
28
dar una explicacin de cada fujo de trabajo.
- Modelado del negocio
Con este fujo de trabajo pretendemos llegar a un mejor entendimiento de la
organizacin donde se va a implantar el producto.
Los objetivos del modelado de negocio son :
Entender la estructura y la dinmica de la organizacin para la cual el sistema
va ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identifcar potenciales
mejoras.
Asegurar que clientes, usuarios fnales y desarrolladores tengan un entendimiento
comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organizacin
objetivo.
Para lograr estos objetivos, el modelo de negocio describe como desarrollar una
visin de la nueva organizacin, basado en esta visin se defnen procesos, roles y
responsabilidades de la organizacin por medio de un modelo de Casos de Uso del
negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se
desarrollan otras especifcaciones tales como un Glosario.
- Requisitos:
Este es uno de los fujos de trabajo ms importantes, porque en l se establece
qu tiene que hacer exactamente el sistema que construyamos. En esta lnea los
requisitos son el contrato que se debe cumplir, de modo que los usuarios fnales
tienen que comprender y aceptar los requisitos que especifquemos.
Los objetivos del fujo de datos Requisitos es :
Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre lo
que el sistema podra hacer.
Proveer a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
Defnir el mbito del sistema.
Proveer una base para la planeacin de los contenidos tcnicos de las iteraciones.
Proveer una base para estimar costos y tiempo de desarrollo del sistema.
Defnir una interfaz de usuarios para el sistema, enfocada a las necesidades y
metas del usuario.
Los requisitos se dividen en dos grupos. Los requisitos funcionales representan
la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso.
Los requisitos no funcionales representan aquellos atributos que debe exhibir el
sistema, pero que no son una funcionalidad especfca. Por ejemplo requisitos de
facilidad de uso, fabilidad, efciencia, portabilidad, etc.
29
Para capturar los requisitos es preciso entrevistar a todos los interesados en el
proyecto, no slo a los usuarios fnales, y anotar todas sus peticiones. A partir de
ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos.
En este fujo de trabajo, y como parte de los requisitos de facilidad de uso, se disea
la interfaz grfca de usuario. Para ello habitualmente se construyen prototipos de
la interfaz grfca de usuario que se contrastan con el usuario fnal.
- Anlisis y Diseo
El objetivo de este fujo de trabajo es traducir los requisitos a una especifcacin
que describe cmo implementar el sistema.
Los objetivos del anlisis y diseo son :
Transformar los requisitos al diseo del futuro sistema.
Desarrollar una arquitectura para el sistema.
Adaptar el diseo para que sea consistente con el entorno de implementacin,
diseando para el rendimiento.
El anlisis consiste en obtener una visin del sistema que se preocupa de ver
qu hace, de modo que slo se interesa por los requisitos funcionales. Por otro
lado el diseo es un refnamiento del anlisis que tiene en cuenta los requisitos no
funcionales, en defnitiva cmo cumple el sistema sus objetivos.
- Implementacin
En este fujo de trabajo se implementan las clases y objetos en fcheros fuente,
binarios, ejecutables y dems. Adems se deben hacer las pruebas de unidad: cada
implementador es responsable de probar las unidades que produzca. El resultado
fnal de este fujo de trabajo es un sistema ejecutable.
En cada iteracin habr que hacer lo siguiente:
Planifcar qu subsistemas deben ser implementados y en que orden deben ser
integrados, formando el Plan de Integracin.
Cada implementador decide en que orden implementa los elementos del
subsistema.
Si encuentra errores de diseo, los notifca.
Se prueban los subsistemas individualmente.
Se integra el sistema siguiendo el plan.
La estructura de todos los elementos implementados forma el modelo de
implementacin. La integracin debe ser incremental, es decir, en cada momento
slo se aade un elemento. De este modo es ms fcil localizar fallos y los
componentes se prueban ms a fondo. En fases tempranas del proceso se pueden
implementar prototipos para reducir el riesgo. Su utilidad puede ir desde ver si el
sistema es viable desde el principio, probar tecnologas o disear la interfaz de
usuario. Los prototipos pueden ser exploratorios (desechables) o evolutivos. Estos
ltimos llegan a transformarse en el sistema fnal.
30
- Pruebas
Este fujo de trabajo es el encargado de evaluar la calidad del producto que estamos
desarrollando, pero no para aceptar o rechazar el producto al fnal del proceso de
desarrollo, sino que debe ir integrado en todo el ciclo de vida.
Esta disciplina brinda soporte a las otras disciplinas. Sus objetivos son:
Encontrar y documentar defectos en la calidad del software.
Generalmente asesora sobre la calidad del software percibida.
Provee la validacin de los supuestos realizados en el diseo y especifcacin
de requisitos por medio de demostraciones concretas.
Verifcar las funciones del producto de software segn lo diseado.
Verifcar que los requisitos tengan su apropiada implementacin.
Las actividades de este fujo comienzan pronto en el proyecto con el plan de prueba
(el cual contiene informacin sobre los objetivos generales y especfcos de las
prueba en el proyecto, as como las estrategias y recursos con que se dotar a esta
tarea), o incluso antes con alguna evaluacin durante la fase de inicio, y continuar
durante todo el proyecto.
El desarrollo del fujo de trabajo consistir en planifcar que es lo que hay que
probar, disear cmo se va a hacer, implementar lo necesario para llevarlos a cabo,
ejecutarlos en los niveles necesarios y obtener los resultados, de forma que la
informacin obtenida nos sirva para ir refnando el producto a desarrollar.
- Despliegue
El objetivo de este fujo de trabajo es producir con xito distribuciones del producto
y distribuirlo a los usuarios. Las actividades implicadas incluyen:
Probar el producto en su entorno de ejecucin fnal.
Empaquetar el software para su distribucin.
Distribuir el software.
Instalar el software.
Proveer asistencia y ayuda a los usuarios.
Formar a los usuarios y al cuerpo de ventas.
Migrar el software existente o convertir bases de datos.
Este fujo de trabajo se desarrolla con mayor intensidad en la fase de transicin, ya
que el propsito del fujo es asegurar una aceptacin y adaptacin sin complicaciones
del software por parte de los usuarios. Su ejecucin inicia en fases anteriores, para
preparar el camino, sobre todo con actividades de planifcacin, en la elaboracin
del manual de usuario y tutoriales.
Gestin del proyecto
La Gestin del proyecto es el arte de lograr un balance al gestionar objetivos,
riesgos y restricciones para desarrollar un producto que sea acorde a los requisitos
de los clientes y los usuarios.
31
Los objetivos de este fujo de trabajo son:
Proveer un marco de trabajo para la gestin de proyectos de software intensivos.
Proveer guas prcticas realizar planeacin, contratar personal, ejecutar y
monitorear el proyecto.
Proveer un marco de trabajo para gestionar riesgos.
La planeacin de un proyecto posee dos niveles de abstraccin: un plan para las
fases y un plan para cada iteracin.
Confguracin y control de cambios
La fnalidad de este fujo de trabajo es mantener la integridad de todos los artefactos
que se crean en el proceso, as como de mantener informacin del proceso evolutivo
que han seguido.
Entorno
La fnalidad de este fujo de trabajo es dar soporte al proyecto con las adecuadas
herramientas, procesos y mtodos. Brinda una especifcacin de las herramientas
que se van a necesitar en cada momento, as como defnir la instancia concreta del
proceso que se va a seguir.
En concreto las responsabilidades de este fujo de trabajo incluyen:
Seleccin y adquisicin de herramientas
Establecer y confgurar las herramientas para que se ajusten a la organizacin.
Confguracin del proceso.
Mejora del proceso.
Servicios tcnicos.
El principal artefacto que se usa en este fujo de trabajo es el caso de desarrollo
que especifca para el proyecto actual en concreto, como se aplicar el proceso,
que productos se van a utilizar y como van a ser utilizados. Adems se tendrn
que defnir las guas para los distintos aspectos del proceso, como pueden ser el
modelado del negocio y los Casos de Uso, para la interfaz de usuario, el diseo, la
programacin, el manual de usuario.
32
TCNICAS DE RECOLECCIN
DE INFORMACIN
Existen varias tcnicas para capturar requisitos de usuarios, de las cuales
examinaremos algunas:
1. La entrevista

Dentro de las tcnicas utilizadas para recopilar informacin, las entrevistas ocupan
un lugar preponderante en consideracin con el tiempo que ocupan y el objetivo
que tienen. Por lo general, son la mayor fuente de informacin del analista. La
entrevista es una forma de conversacin, no de interrogacin.
Durante la entrevista el analista no se limita solo a informarse de los puntos que le
interesan, sino que adems aprovecha la oportunidad para explicar su trabajo a los
usuarios y crear un clima sociolgico favorable.
Para llevar a efecto una entrevista se deben realizar una serie de pasos y cumplir
una serie de reglas para poder asegurar el xito de la misma.
Los distintos pasos que se deben realizar son:
1. Preparacin
2. Ejecucin
3. Recapitulacin
a) Preparacin
Se debe coordinar con el usuario la fecha, la hora y el lugar.
Se debe garantizar la privacidad, evitar las interrupciones y disponer de un
tiempo adecuado.
Se deben de obtener criterios previos acerca de las personas que se van a
entrevistar para poder desarrollar una conversacin ms natural.
Se deben preparar cuidadosamente las preguntas a realizar o la gua de la
entrevista.
b) Ejecucin
Se debe ser correcto y no preguntar cosas que se pueden obtener por otras
vas a menos que se desee comprobar algo.
El tacto, la imparcialidad e incluso la vestimenta apropiada ayudan a asegurar
una entrevista exitosa.
Se debe ser puntual, identifcarse y explicar los objetivos de la entrevista
Se debe prestar la mxima atencin durante el desarrollo, crear un clima
favorable, evitar caer en discusin con los usuarios, no hacer criticas, utilizar
una terminologa adecuada, no adelantarse a ningn criterio ni opinin de
33
los usuarios y mucho menos sacar conclusiones instantneas sobre la
informacin recibida.
Diferenciar entre los hechos y las opiniones, entre la actividad o funcin que
realiza y el como la realiza, tratando siempre que la informacin recopilada
sea lo mas objetiva posible.
Evitar que la entrevista sea larga o se convierta en inoportunas por razones
imprevistas, si esto ocurre se debe posponer.
Al despedirse se debe mostrar agradecimiento y dejar coordinado otro
posible encuentro.
Al fnal se debe hacer una pequea recapitulacin de la informacin recopilada
para verifcar los hechos registrados.

c) Recapitulacin
Se deben revisar las notas para reordenarlas y organizarlas por temas,
pasarlas en limpio y comprobar que no existan contradicciones.
La recapitulacin de las entrevistas se hace en el modelo Registro de
Acuerdos y Observaciones
Entrevistado: Juan Perez (Jefe de Almacn) Fecha: 3 de Marzo
Entrevistador: Ana Garca Tema: Realizar un
Sistema
Objetivos de la Entrevista:
Obtener requerimientos del usuario para realizar un sistema de calidad.
1. Cul es su opinin del sistema de computadora actual?
2. Cules son algunos de los problemas que experimenta para recibir
informacin a tiempo?
3. Describa el proceso de almacn.
4. Qu reportes genera en un mes?
5. Liste sus dos prioridades mximas para el departamento de almacn?
6. Tiene comunicacin automatizado con los dems departamentos?
7. Qu espera del nuevo sistema a implantar?
2. El Cuestionario.
Los cuestionarios constituyen la nica forma posible de poder relacionarse con un
gran nmero de personas para conocer varios aspectos del sistema, sin tener que
estar presente.
Los cuestionarios como medio para recoger opiniones o hacer encuestas pueden
ser de gran utilidad si se usa en forma adecuada, o sea, si se aplican en una
situacin especifca para la cual fueron diseados especialmente y adems este
diseo rene una serie de requisitos.
Hay dos formas de cuestionarios: abiertos y cerrados.
34
Abiertos: Se utilizan par recoger sentimientos, opiniones, referencias.
Cerrados: Limitan las respuestas posibles a travs de un estilo cuidadoso en la
pregunta.
Respuestas de cuestionario cerrado:
si / no

Cree que se cometen muchos errores en la codifcacin de los nmeros de
cuenta en las facturas?
SI NO
De acuerdo/en desacuerdo
Se cometen muchos errores al codifcar los nmeros de cuenta en las facturas:

DE ACUERDO
EN DESACUERDO
Escalas
Se cometen muchos errores al codifcar los nmeros de cuenta en las facturas.
TOTALMENTE DE ACUERDO
DE ACUERDO
NO ESTOY SEGURO
EN DESACUERDO
TOTALMENTE EN DESACUERDO
Nmero
De cada 100 facturas que se procesan cuntas tienen errores? Anote el nmero:
____________
Rango

De cada 100 facturas que se procesan cuntas tienen errores?
0 - 5
6 - 10
11 - 15
16 - 20
21 - 25
26 - 30
31 - 40
41 - 50
Ms de 50

35
3. Revisin de documentos
Toda entidad debe emitir y archivar un conjunto de documentos de informacin
donde aparezcan los indicadores principales de la entidad relacionados con su
actividad fundamental. Por lo general las entidades tambin emiten y archivan un
conjunto de informes o modelos de inters para el organismo central o ministerio
al cual pertenecen. Adems, toda entidad debe tener un Sistema de Contabilidad,
un Sistema de Fuerza de Trabajo uno de Abastecimiento, uno de Medios Bsicos,
etc. Cada uno de los cuales posee toda la informacin de la entidad sobre esos
aspectos especfcos.
Muchos o todos los indicadores que Ud. necesita deben estar refejados en estos
documentos. Pero muchas veces en los documentos no se refeja exactamente lo
que uno quiere buscar y debe hacer un procesamiento de ellos.
A pesar de que se haga un anlisis profundo de los documentos, hay indicadores
que la entidad no recopila y son sumamente tiles para el analista; entonces, hay
que ir a la investigacin o a realizar ciertos experimentos.
4. Investigacin y experimentacin
Dentro de los indicadores que son muy importantes para el analista y que la entidad
generalmente no posee, estn:
El tiempo que se demora realizar cada proceso del sistema actual.
La cantidad de errores que se cometen al realizar los procesos del sistema
actual.
La frecuencia y otros indicadores de algunos documentos.
Ciertas normas y consumos.
Hay dos cosas que por su importancia nos debemos detener en ellos y es como
conocer el tiempo que demora la realizacin de un proceso y la cantidad de errores
que se cometen en un proceso que generalmente son cuestiones de inters.
5. Trabajo creativo en grupos
Brainstorming (Tormenta de ideas)
Permite generar gran cantidad de ideas en breve tiempo. Se desarrolla con un
Grupo de expertos, idealmente de 8 a 10 personas, an cuando puede variar entre
6 y 12, mantenindose efcacia. Se expone un problema a los presentes, o se les
enva un memorndum previo. Las ideas se generan y exponen por los asistentes
en forma clara y precisa, evitando discursos, sin que medie ninguna crtica o
evaluacin de stas, por descabelladas que pudieran parecer.
En esta atmsfera no crtica, las personas se sienten libres para decir lo que
piensan y estas ideas, an en el caso de que no tuvieran valor, pueden dar origen
a otras por asociacin. Las ideas se recogen y listan en pliegos de papel que se
mantienen a la vista de todos. Estas ideas se valoran posteriormente.
36
La generacin de ideas y su recogida puede realizarse, dependiendo de las
caractersticas del Grupo y sus integrantes, segn 3 variantes:
1. Los integrantes dan las ideas espontneamente y se van listando.
2. Se realizan varias rondas, cada integrante lanza una idea en su turno o puede
pasar en una ronda. Se van listando las ideas. Se contina el proceso hasta
que todos pasen.
3. Una persona que acta como facilitador, pide a los presentes que escriban en
una hoja de papel sus ideas. Estas se recogen y organizan en pliegos que se
presentan al Grupo, que puede repetir el proceso de generacin de ideas por
asociacin con las que se presentan.
Merita destacar brevemente el papel que desempea en esta y otras tcnicas
el denominado facilitador, que es quien debe propiciar el clima y los resultados
ptimos; para ello:
No dirige, sino que facilita el trabajo del Grupo, la elaboracin y exposicin
de ideas creativamente.
Brinda confanza para expresar las ideas, evita ataques, permite y promueve
la participacin de todos.
No evala, apoya ni se solidariza con ninguna de las ideas.
Garantiza la agilidad del desarrollo de la actividad y el logro de sus objetivos.
A pesar de ser el brainstorming una poderosa herramienta para la generacin
de ideas, pueden presentarse algunas situaciones tales como:
Las ideas no son expuestas cuidadosa y rigurosamente.
Se monopoliza por uno o varios integrantes del Grupo.
La generacin de ideas puede verse frenada por la presencia de uno o varios
participantes.
Existen confictos o controversias en el seno del Grupo que pueden infuir en la
acogida y posterior valoracin de las ideas.
En estas situaciones es conveniente la utilizacin de otras tcnicas: Brainwriting
(Escritura de ideas), Gallery method ( Galeria de ideas ), Bloc de notas colectivo,
Focus Group, etc.
6. Workshop
Es un taller propiamente el espacio donde se realiza un trabajo manual o artesano,
como el taller de un pintor o un alfarero, un taller de costura o de elaboracin de
alfajores, una reunin para levantamiento de informacin, etc.; aunque tambin
puede designar otros conceptos derivados a ste.

37
Ejemplo de WorkShop
Workshop N 1
Escenario : Ofcina de Administracin
Entrevistado:

Apellidos y Nombres : Betsy Franco Alva
Cargo : Administradora General
E-mail : betsyfranco@hotmail.com
Agenda:

Conocer el funcionamiento general de la empresa.
Identifcar los procesos que se llevan a cabo en las diferentes reas.
Lugar, fecha y hora de la entrevista:
Lugar : Ofcina de Administracin
Fecha : 15 Marzo de 2010
Hora Inicio : 17:30
Hora Fin : 18:30
Preguntas preliminares:
Cul es el giro de la empresa?
Cul es la misin de la empresa?
Cul es su visin?
Cul es el mercado al cual estn dirigidos sus productos: nacional
o internacional?
Quines son sus clientes potenciales?
Quines son sus proveedores?
Quines son la competencia?
Preguntas y respuestas:
1. Qu responsabilidad tiene usted como Administradora General en la empresa?
Soy la responsable de todas las reas de la empresa, es decir, velo por el
cumplimiento de las funciones que se han asignado a cada empleado. Adems
ante cualquier problema que se pudiera presentar soy la responsable directa de
solucionarlo de la mejor manera posible.
38
2. Podra decirme brevemente a que se dedica la empresa?
La empresa naci con la fnalidad de comercializar artculos para un bazar,
electrodomsticos y juguetes, que son importados.
3. Podra describirme la arquitectura de la empresa?
La empresa posee tres reas fundamentales que son Ventas, Compras y
Almacn que funcionan de manera conjunta y ordenada supervisadas por
Administracin General.

4. Podra describir brevemente los procesos de que se llevan a cabo en cada
rea y como los controla?
El Departamento De Ventas se encarga de controlar las ventas mediante la
recepcin de pedidos, es decir todo el manejo de documentacin que circula en
esta rea.
El Departamento de Compra se encarga del control de las compras, es decir de
todo el manejo de documentacin que se emite en esta rea en lo referente a
reabastecimiento de stock.
El Departamento de Almacn se encarga del control del almacn, adems
de generar listados sobre los productos con sus respectivos cdigos que se
requiere para ventas.
5. Actualmente la empresa cuenta con algn sistema que agilice sus operaciones?
No. La mayora de ellas se realizan en forma manual y algunas pocas con la
ayuda de hojas de clculo.
6. Qu es lo que buscan obtener con la implementacin de un sistema?
En todo giro de negocios existen operaciones que se deben realizar con un
debido cuidado y con el ms mnimo error para obtener los mayores benefcios,
y eso es lo que nosotros buscamos; es por ello que requerimos un sistema que
agilice los procesos y los controle, reduciendo al mnimo el tiempo empleado
en ello. Adems la empresa tambin requiere la elaboracin de una pgina
web que se encargue de marketear los artculos que ofrecemos as como que
tambin tenga la caracterstica de enviarnos sus pedidos va correo electrnico,
etc.. Eso es lo que buscamos.
39

El UML es una tcnica de modelado de objetos y como tal supone una abstraccin
de un sistema para llegar a construirlo en trminos concretos. El modelado no es
ms que la construccin de un modelo a partir de una especifcacin. Un modelo
es una abstraccin de algo, que se elabora para comprender ese algo antes de
construirlo. El modelo omite detalles que no resultan esenciales para la comprensin
del original y por lo tanto facilita dicha comprensin. Los modelos se utilizan en
muchas actividades de la vida humana: antes de construir una casa el arquitecto
utiliza un plano, los msicos representan la msica en forma de notas musicales, los
artistas pintan sobre el lienzo con carboncillos antes de empezar a utilizar los leos,
etc. Unos y otros abstraen una realidad compleja sobre unos bocetos, modelos
al fn y al cabo. Los modelos adems, al no ser una representacin que incluya
todos los detalles de los originales, permiten probar ms fcilmente los sistemas
que modelan y determinar los errores. Segn se indica en la Metodologa RUP, los
modelos permiten una mejor comunicacin con el cliente por distintas razones:
Es posible ensear al cliente una posible aproximacin de lo que ser el producto
fnal.
Proporcionan una primera aproximacin al problema que permite visualizar
cmo quedar el resultado.
Reducen la complejidad del original en subconjuntos que son fcilmente
tratables por separado.
Se consigue un modelo completo de la realidad cuando el modelo captura los
aspectos importantes del problema y omite el resto. Los lenguajes de programacin
que estamos acostumbrados a utilizar no son adecuados para realizar modelos
completos de sistemas reales porque necesitan una especifcacin total con detalles
que no son importantes para el algoritmo que estn implementando.
Con la creacin del UML se persigue obtener un lenguaje que sea capaz de
abstraer cualquier tipo de sistema, mediante los diagramas, es decir, mediante
representaciones grfcas que contienen toda la informacin relevante del sistema.
Dando una breve introduccin al tema; se puede decir que UML no es una
metodologa, si no ms bien es un lenguaje (pero no de programacin), una notacin,
que permite visualizar, especifcar, construir y documentar el modelado de sistemas;
sea cual fuere el ciclo de vida elegido para el anlisis, diseo e implementacin del
mismo. UML es de reciente aparicin y, al ser no propietario, es usado y refnado
por muchas empresas, grupos de investigadores y desarrolladores a nivel mundial.
UML signifca Unifed Modeling Language: Lenguaje de Modelado o Modelamiento
Unifcado. El Lenguaje de Modelado Unifcado es un lenguaje usado para especifcar,
UML
40
visualizar y documentar los diferentes aspectos relativos a un sistema de software
bajo desarrollo, as como para modelado de negocios y otros sistemas no software.
Puede ser utilizado con cualquier metodologa, a lo largo del proceso de desarrollo
de software, en cualquier plataforma tecnolgica de implementacin (Unix, Windows
etc.).
Es un sistema notacional (que, entre otras cosas, incluye el signifcado de sus
notaciones) destinado a los sistemas de modelado que utilizan conceptos orientados
a objetos.
Los principales factores que motivaron la defnicin de UML fueron: la necesidad de
modelar sistemas, las tendencias en la industria del software, unifcar los distintos
lenguajes y mtodos existentes e innovar los modelos.
1. DEFINICIONES DE UML
El Lenguaje Unifcado de Modelado prescribe un conjunto de notaciones y
diagramas estndar para modelar sistemas orientados a objetos, y describe la
semntica esencial de lo que estos diagramas y smbolos signifcan. Mientras
que ha habido muchas notaciones y mtodos usados para el diseo orientado
a objetos, ahora los modeladores slo tienen que aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de
software, sistemas de hardware, y organizaciones del mundo real.
El UML es una tcnica de modelado de objetos y como tal supone una abstraccin
de un sistema para llegar a construirlo en trminos concretos. El modelado no
es ms que la construccin de un modelo a partir de una especifcacin. Un
modelo es una abstraccin de algo, que se elabora para comprender ese algo
antes de construirlo. El modelo omite detalles que no resultan esenciales para
la comprensin del original y por lo tanto facilita dicha comprensin.
UML es una consolidacin de muchas de las notaciones y conceptos ms
usadas orientados a objetos. Empez como una consolidacin del trabajo de
Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las
metodologas orientadas a objetos ms populares.
2. BREVE RESEA HISTRICA
El desarrollo de UML comenz en octubre de 1994 cuando Grady Booch y Jim
Rumbaugh de Rational Software Corporation comenzaron a trabajar en la
unifcacin de los lenguajes de modelado Booch y OMT, desde este momento
fueron reconocidos mundialmente en el desarrollo de metodologas orientadas a
objetos. As, en octubre de 1995, terminaron su trabajo de unifcacin obteniendo
el borrador de la versin 0.8 del denominado Unifed Method. Hacia fnes de este
mismo ao, Ivar Jacobson (creador de la metodologa OOSE - Object Oriented
Software Engineer) se uni con Rational Software para obtener fnalmente UML 0.9
y 0.91 en junio y octubre de 1996, respectivamente.
Igualmente, UML incorpora ideas de otros metodlogos entre los que podemos
41
incluir a Peter Coad, Derek Coleman, Ward Cunningham, David Harel, Richard
Helm, Ralph Johnson, Stephen Mellor, Bertrand Meyer, Jim Odell, Kenny Rubin,
Sally Shlaer, John Vlissides, Paul Ward, Rebecca Wirfs-Brock y Ed Yourdon.
Luego, muchas organizaciones como Microsoft, Hewlett-Packard, Oracle, Sterling
Software MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM,
ObjectTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam se
asociaron con Rational Software Corporation para dar como resultado UML 1.0 y
UML 1.1. Hoy en da llegamos hasta UML 1.4 y UML 2.0. En la siguiente fgura se
muestra de forma grfca y resumida la evolucin de UML.
3. CARACTERSTICAS DE UML
UML es una especifcacin de notacin orientada a objetos. Se basa en las
anteriores especifcaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide
cada proyecto en un nmero de diagramas que representan las diferentes vistas
del proyecto. Estos diagramas juntos son los que representa la arquitectura del
proyecto.
UML permite describir un sistema en diferentes niveles de abstraccin, simplifcando
la complejidad sin perder informacin, para que tanto usuarios, lderes y
desarrolladores puedan comprender claramente las caractersticas de la aplicacin.
Defnicin formal de un metamodelo comn que defne el lenguaje para expresar
modelos de anlisis y diseo. Un metamodelo se defne como un modelo que
sirve para expresar otros modelos, y son indispensables para poder defnirlos sin
ambigedades.
42
El mtodo del UML recomienda utilizar los procesos que otras metodologas tienen
defnidos.
4. DIAGRAMAS: Vistazo General
En todos los mbitos de la ingeniera se construyen modelos, en realidad,
simplifcaciones de la realidad, para comprender mejor el sistema que vamos a
desarrollar, los ingenieros de software deberan igualmente construir modelos de
los sistemas software.
Para la construccin de modelos, hay que centrarse en los detalles relevantes
mientras se ignoran los dems, por lo cual con un nico modelo no tenemos
bastante. Varios modelos aportan diferentes vistas de un sistema los cuales nos
ayudan a comprenderlo desde varios frentes. As, UML recomienda la utilizacin de
nueve diagramas para representar las distintas vistas de un sistema.
Los diagramas de UML:
Diagrama de Casos de Uso: modela la funcionalidad del sistema agrupndola en
descripciones de acciones ejecutadas por un sistema para obtener un resultado.
Se utiliza para entender el uso del sistema
Diagrama de Clases: muestra las clases (descripciones de objetos que comparten
caractersticas comunes) que componen el sistema y cmo se relacionan entre s.
Diagrama de Objetos: muestra una serie de objetos (instancias de las clases) y sus
relaciones. A diferencia de los diagramas anteriores, estos diagramas se enfocan
en la perspectiva de casos reales o prototipos. Es un diagrama de instancias de las
clases mostradas en el diagrama de clases.
Diagrama de Secuencia: enfatiza la interaccin entre los objetos y los mensajes
que intercambian entre s junto con el orden temporal de los mismos.
Diagrama de Colaboracin: igualmente, muestra la interaccin entre los objetos
resaltando la organizacin estructural de los objetos en lugar del orden de los
mensajes intercambiados.
Diagrama de Estados: Se utiliza para analizar los cambios de estado de los
objetos. Muestra los estados, eventos, transiciones y actividades de los diferentes
objetos. Son tiles en sistemas que reaccionen a eventos.
Diagrama de Actividades: Es un caso especial del diagrama de estados, simplifca el
diagrama de estados modelando el comportamiento mediante fujos de actividades.
Muestra el fujo entre los objetos. Se utilizan para modelar el funcionamiento del
sistema y el fujo de control entre objetos.
Diagrama de Componentes: muestra la organizacin y las dependencias entre
un conjunto de componentes. Se usan para agrupar clases en componentes o
mdulos.
43
Diagrama de Despliegue (o implementacin): muestra los dispositivos que se
encuentran en un sistema y su distribucin en el mismo. Se utiliza para identifcar
Sistemas de Cooperacin: Durante el proceso de desarrollo el equipo averiguar
de qu sistemas depender el nuevo sistema y que otros sistemas dependern de
l.
5. Vistas
La practica de crear diagramas para visualizar sistemas desde perspectivas o vistas
diferentes no est limitado a la industria de la construccin.
En el contexto del software, existen cinco vistas complementarias que son las ms
importantes para visualizar, especifcar, construir y documentar la arquitectura del
software. En el UML las vistas existentes son:
Vista casos de uso: se forma con los diagramas de casos de uso, colaboracin,
estados y actividades.
Vista de diseo: se forma con los diagramas de clases, objetos, colaboracin,
Vista de procesos: se forma con los diagramas de la vista de diseo. Recalcando
las clases y objetos referentes a procesos.
Vista de implementacin: se forma con los diagramas de componentes,
colaboracin, estados y actividades.
Vista de despliegue: se forma con los diagramas de despliegue, interaccin,
Como podemos ver el nmero de diagramas es muy alto, en la mayora de los
casos excesivos, y UML permite defnir solo los necesarios, ya que no todos son
necesarios en todos los proyectos.
UML esta pensado para el modelado tanto de pequeos sistemas como de sistemas
complejos, y debemos tener en cuenta que los sistemas complejos pueden estar
44
compuestos por millones de lneas de cdigo y ser realizados por equipos de
centenares de programadores.

6. DIAGRAMAS UML 2.0
En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos se clasifca
como se muestra en la fgura 09.
Diagramas Estticos o Estructurales
- Diagrama de Objetos
- Diagrama de Clases
- Diagramas de Componentes
- Diagramas de Estructura compuesta (A partir de UML 2.0)
- Diagramas de Despliegue
- Diagramas de Paquetes
Diagramas Dinmicos o de Comportamiento
- Diagrama de mquina de Estado
- Diagrama de actividad
- Diagrama de Caso de Uso
Diagramas de Interaccin (Subtipo de Diagramas de
Comportamiento)

- Diagrama de Secuencia
- Diagrama de Comunicacin
- Diagrama de Tiempos(A partir de UML 2.0)
- Diagrama de descripcin la interaccin(A partir de UML 2.0)
Figura _09: Jerarqua de los Diagramas de UML 2.0
CAPTULO
2
Modelo de Negocio
Modelo de Caso de Uso del Negocio

Modelo de Anlisis del Negocio
47
La necesidad de esta disciplina surge ante el hecho de que muchos de los productos
de software que se desarrollan automatizan algunos o todos los procesos existentes
en un negocio, y es necesario estudiar las implicaciones de los cambios producidos
por la adopcin de estos productos. Hay que entender cmo funciona el negocio
que se desea automatizar para tener garantas de que el software desarrollado va
a cumplir su propsito y, por esto, se hace un estudio en el dominio del negocio,
adems de un dominio del software.
Los objetivos del modelado de negocio son:
Entender la estructura y la dinmica de la organizacin para la cual el sistema
va ser desarrollado (organizacin objetivo).
Entender el problema actual en la organizacin objetivo e identifcar potenciales
mejoras.
Asegurar que clientes, usuarios fnales y desarrolladores tengan un entendimiento
comn de la organizacin objetivo.
Derivar los requisitos del sistema necesarios para apoyar a la organizacin
objetivo.
El modelo de negocios es una tcnica para comprender los procesos de negocios de
la organizacin. El modelado del negocio est soportado por dos tipos de modelos
de UML: Modelo de Casos de Uso del Negocio y Modelos de anlisis del Negocios.
El Modelo de Casos de Uso del Negocio describe los procesos de negocio de
una empresa en trminos de casos de uso del negocio y actores del negocio que
se corresponden con los procesos del negocio y los clientes, respectivamente. El
modelo de Casos de Uso del Negocio se describe mediante diagramas de casos
de uso.
El Modelo de anlisis del Negocio es un modelo interno a un negocio. Describe
como cada caso de uso de negocio es llevado a cabo por parte de un conjunto
de trabajadores que utilizan un conjunto de entidades del negocio y de entidades
de trabajo. Cada realizacin de un caso de uso del negocio puede mostrarse en
diagramas en diagramas de interaccin y diagramas de actividad. Una entidad
del negocio representa algo, como una factura, que los trabajadores toman,
inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio.
Una unidad del trabajo es un conjunto de esas entidades que conforman un todo
reconocible para un usuario fnal. Las entidades del negocio y las unidades de
trabajo se utilizan para representar los mismos tipos de conceptos que las clases
del dominio, como Pedido, Artculo, Factura y Cuenta. Tambin se tendrn otros
diagramas para mostrar los trabajadores, sus interacciones y como utilizan las
entidades de negocios y las unidades de trabajo.
MODELO DE NEGOCIO
48
Cada trabajador, entidad del negocio y unidad de trabajo puede participar en la
realizacin de ms de un caso de uso del negocio. Por ejemplo, la clase Cuenta
participar probablemente en las tres siguientes realizaciones de casos de uso del
negocio:
En Gestin de Prstamo: De la Solicitud al Desembolso, el dinero que se
adquiere por el prstamo se desembolsa en una cuenta.
En hacer Transferencia y Retirar y Depositar Dinero: El dinero se retira o se
deposita en cuentas y se transfere entre cuentas.
Ventas: Del Pedido a la Entrega implica la transferencia de dinero de la cuenta
del comprador a la del vendedor.
Los creadores de RUP sealan que el modelo de negocio est soportado por dos
artefactos principales:
- Modelo de casos de uso del negocio.
- Modelo de anlisis del negocio
El conjunto completo de artefactos del modelo de negocio, se muestra en la
siguiente fgura:
1. Cundo ser necesario hacer el modelo de negocio?
Cuando el grupo de trabajo es nuevo en la organizacin.
Cuando la organizacin a enfrentado un reciente proceso de reingeniera de
negocios.
Cuando la organizacin esta planifcando un proceso de reingeniera de
negocios.
Cuando el software a construir ser utilizado por una porcin importante de la
organizacin.
Existen fujos de trabajo complejos dentro de la organizacin que no estn
documentados.
49
Cuando se es un consultor en una organizacin en la cul no se ha trabajado
antes.
2. Cundo no ser necesario hacer el modelo de negocio?
Cuando se tiene conocimiento de la estructura de la organizacin, de las
metas, de la visin y de los clientes/usuarios.
Cuando el software a construir ser usado por una pequea parte de la
organizacin, y no tiene un efecto en el resto del negocio.
Cuando los fujos de trabajo de la organizacin estn bien documentados.
Cuando el tiempo no lo permita, no todos los procesos tienen el tiempo
necesario para completar un anlisis del negocio.
3. Actividades para realizar un modelo de negocio
Determinar la situacin de la organizacin
Describir el actual negocio.
Identifcar los procesos de negocio
Refnar las defniciones de los procesos del negocio.
Disear las realizaciones de los procesos del negocio.
Refnar roles y responsabilidades
Explorar procesos automatizados
Desarrollar un modelo de dominio
En este manual, trataremos las actividades ms relevantes que permiten obtener
los artefactos principales del negocio.
50
1. Determinar la situacin de la organizacin:
El objetivo es reconocer el negocio en estudio para delimitarlo. Las actividades que
se llevan a cabo son:
Identifcar la misin y visin de la organizacin y/o reas de estudio que
correspondan y plasmarlo en visin del negocio.
Identifcar los objetivos del negocio, y documentarlos en objetivos del negocio.
Estos objetivos son determinados por los stakeholders y responsables del
negocio y sern usados para validar los casos de uso del negocio.
Identifcar las reglas del negocio y luego plasmarlas en el documento reglas del
negocio.
Elaborar una lista de trminos y defniciones usados comnmente en un glosario
del negocio.
Se ha preferido reunir los documentos anteriormente mencionados en el artefacto
Situacin del Negocio.
2. Identifcar los procesos del Negocio
Requiere haber identifcado los objetivos del negocio. El equipo de trabajo debe tener
claras las fronteras del negocio que est describiendo. Para ello, debe identifcar y
priorizar los casos de uso del negocio y los actores de negocio involucrados.
Para mostrar la interaccin entre actores de negocio y casos de uso de negocio se
crea un diagrama general de casos de uso del negocio.
Por cada caso de uso del negocio, se realiza una especifcacin de caso de uso del
negocio, conocido comnmente como BUCS (Business Use Case Specifcation)
por las iniciales en ingls. En este documento, se indica una descripcin breve del
proceso de negocio.
Para describir los actores del negocio y mostrar mediante un diagrama de casos
de uso del negocio su asociacin con los casos de uso de negocio encontrados, se
utiliza el artefacto actores del negocio.
3. Refnar las defniciones de los procesos de negocio:
a) Detallar la defnicin de los casos de uso del negocio.
b) Describir cmo los casos de uso del negocio soportan los objetivos del
negocio.
c) Verifcar que los casos de uso del negocio representan correctamente
cmo el negocio es conducido.
Aqu se refere a las especifcaciones de caso de uso del negocio, describiendo
paso a paso las actividades que se desarrollan en el proceso de negocio.
MODELO DE CASO DE USO
DEL NEGOCIO
51
1. Disear las realizaciones de los procesos del negocio
Consiste en identifcar todos los roles, productos, entregables del negocio y
describir cmo el proceso del negocio ser llevado a cabo por los trabajadores y
las entidades dentro del negocio.
El documento que plasma la descripcin breve de trabajadores del negocio y cmo
ellos manipulan las entidades del negocio es trabajadores del negocio.
Adems se crea el artefacto entidades del negocio para describir las entidades del
negocio y especifcar, mediante diagramas de estado, los estados de cada una de
las entidades.
Para la realizacin de cada proceso del negocio se crea un diagrama de clases de
negocio y un diagrama de actividades de negocio.
Al fnalizar esta actividad, se completar cada especifcacin de caso de uso del
negocio generado en el modelado de casos de uso de negocio, agregando al fnal
de cada documento, los diagramas de clases y actividades correspondientes.
ESTEREOTIPO DESCRIPCIN
Describe el valor deseado de una
medida en particular a futuro, y se
utiliza para planear y administrar
las actividades del negocio. El
objetivo debe ser claro, mesurable,
alcanzable, realista y sensible al
tiempo.
Describe un proceso de negocio
desde un punto de vista externo
que percibe algn tipo de valor.
Representa un rol que algo o
alguien externo desempea en
relacin con el negocio.
MODELO DE ANLISIS
DEL NEGOCIO
52
Representa un rol interno
al negocio. Colabora con
trabajadores de otro sector, es
notifcado de acontecimientos del
negocio y manipula entidades
de negocio para realizar sus
responsabilidades.
Ente manipulado por actores
del negocio y trabajadores del
negocio.
Coleccin de diagramas que
describe el aspecto interno de los
procesos de negocio (Diagramas
de clases y diagramas de
actividades).
En el Anexo 1 se muestran las plantillas de los documentos que se crean en la
disciplina del modelado de negocio en el siguiente orden:
Situacin del Negocio
Actores del Negocio
Especifcacin de caso de uso del negocio
Trabajadores del Negocio
Entidades del Negocio
Como encontrar trabajadores y entidades de Negocio
TRABAJADOR DE NEGOCIOS (Business Worker)
Un BW representa un rol jugado por alguien o algo dentro del negocio que realiza
alguna actividad dentro del mismo.
Un Business Worker (BW):
Trabaja en una unidad organizacin.
Interacta con otros business worker
Manipula entidades de negocios+
Ejemplos

Vendedor Cajero Aulxiliar de Almacn
53
Dnde encontrar Trabajadores de Negocio - BW?
Roles dentro del negocio
Puestos o cargos dentro de la organizacin
Personas que ejecutan los procesos o las actividades de negocio
Hardware o sistemas informticos dentro del negocio usados en ese momento.
Sugerencia para identifcar adecuadamente los BW:
Son roles (humanos, hardware y software), no personas con nombres propios
Se encuentra dentro de las fronteras del negocio o campo de accin
No deben representar reas, departamentos o partes de una organizacin sino
roles en ejecucin.
No siempre estn asociados con el nombre de un cargo en la planilla de la
organizacin
Cada trabajador de participar en al menos un caso de uso de negocio, sino
participa en ningn proceso debe ser eliminado del modelo.
CheckPoints
El nombre y la descripcin deben ser claros y comprensibles (emplear
sustantivos)
Cada BW debe tener documentada una asociacin con otro BW si se comunican
entre s.
Cada BW deben de participar en un BUC
Cada relacin entre un BW y otros BW o BE debe ser usada en el workfow de
algn BUC
Cada operacin o actividad de un BW debe ser usada debe ser usada en el
workfow de algn BUC.
Cada operacin o actividad de un BW debe ser usada en el workfow de algn
BUC.
ENTIDAD DE NEGOCIO (Business Entity)
Este artefacto representa una pieza de informacin signifcativa que es manipulada
por los actores y trabajadores del negocio. Se refere al estado de la informacin
que pasar entre cada capa como un conjunto de datos que la identifcan una
entidad. Las entidades del negocio de una aplicacin representa entidades reales
y adems suelen ser sustantivos, como por ejemplo: Cliente, Nmina, Factura,
Depsito, etc. Asimismo, las entidades de negocio son la base para compartir
documentos entre los trabajadores del negocio y estas pueden ser utilizadas en
diversas Realizaciones de los Casos de Uso del Negocio.
Una entidad de negocio representa un conjunto de informacin con propiedades,
comportamiento y semntica similares y que es usada, producida o manejada por
trabajadores del negocio cuando ejecutan un caso de uso del negocio.
Pueden ser tangibles e intangibles.
54
Ejemplos
Dnde encontrar entidades de negocio?
Informacin que maneja cada trabajador del negocio
Informacin que necesita ser ingresada, validada y consultada o comunicada en
cada proceso del negocio.
Objetos Fsicos
Informes
Transacciones
Informes
Documentos
Sugerencias para identifcar apropiadamente las entidades de negocio
Participa en al menos un caso de uso
Puede ser usada por diferentes trabajadores del negocio en varios casos de uso
del negocio.
Representan documentos, contratos, informacin solicitada, producto,
conocimiento, etc.
Solo debe ser considerada informacin relevante y persistente al negocio.
Identifcar los atributos de las clases entidades de negocio
Identifcar y describir la informacin que caracteriza a la entidad de negocio
Informacin o propiedades que aporta la entidad del negocio en la ejecucin de
las actividades en que participa.
Solo debe considerarse informacin propia de la entidad del negocio descrita y
no informacin que pertenezca a otra.

55
CASO DESARROLLADO
Segn el fujo de trabajo propuesto desarrolle el modelo de caso de uso.
CASO: SISTEMA DE GESTIN ACADMICA
Flujo de Trabajo:
Flujo bsico
1. El Alumno solicita al Asistente SA realizar un retiro o cambio de horario de un
curso.
2. El Asistente SA verifca si el alumno est matriculado en un determinado curso.
3. Si est matriculado en un determinado curso el Asistente SA verifca si la solicitud
est dentro de la fecha lmite de presentacin.
4. Si la solicitud est dentro de la fecha lmite, se verifca si corresponde a un retiro
o a un cambio de horario.
5. Si es retiro de un curso el Asistente SA registra retiro.
6. Si es un cambio de horario, el Asistente SA muestra los horarios con vacantes
disponibles.
7. El alumno selecciona el horario del curso.
8. El Asistente SA actualiza los datos referentes a la matrcula del alumno.
Flujos alternativos
9. En el punto ( 3 ) si el alumno no est matriculado es rechazado.
10. En el punto ( 4 )si la solicitud ha pasado la fecha lmite, esta es rechazada.
SOLUCIN DEL CASO:
a) Actores del Negocio:
56
b) Casos de uso del Negocio:
c) Diagrama de Caso de uso de negocio:
d) Realizaciones de caso de uso del negocio:
e) Diagrama de clases del negocio:
57
f) Diagrama de Actividades del negocio
58
CASO PROPUESTOS
CASO : Sky
La empresa Sky, es una empresa que ofrece paquetes tursticos nacionales de
calidad al mejor precio del mercado, que tiene como principal objetivo mejorar la
atencin al cliente en un 40%.
El proceso comienza cuando el Gerente Comercial ordena al Asistente Viajes
la elaboracin de los paquetes tursticos a vender, el Asistente se contacta con
empresas operadoras (quienes brindan servicios de hotelera, taxis, tours, etc.)
para realizar los servicios que va a tener el paquete turstico. Se debe tener en
cuenta que cada paquete de viajes no debe tener ms de 3 destinos para no
saturar las visitas y la estancia del viajero sea ms agradable.
Los turistas deben de separar los paquetes tursticos con anticipacin por lo menos
1 semana antes del viaje y as la forma de pago ser ms fcil para el turista. El
Asistente de Viajes ofrece el paquete elaborado al turista interesado, solicitando
los datos para que el Counter evalu disponibilidad de cupos con las empresas
operadoras, si hay disponibilidad el Counter realiza reserva y genera la venta.
La empresa operadora presenta liquidacin al Jefe de Contabilidad, quien verifca
la informacin de la liquidacin y solicita informacin al Jefe de Ventas sobre los
servicios adquiridos para comparar la informacin con la liquidacin y est conforme
el Jefe de Contabilidad registra liquidacin y efecta el pago.
ELABORAR PAQUETE TURSTICO
Objetivo
Innovar la elaboracin de los paquetes en un 30%
Flujo Bsico
1. El Gerente Comercial ordena la creacin de paquetes tursticos al Asistente
de Viajes.
2. El Asistente de Viajes defne especifcaciones de paquetes tursticos y
elabora propuesta de paquete
3. El Asistente de Viajes presenta propuesta al Gerente Comercial.
4. Si el Gerente Comercial acepta la propuesta el Asistente de Viajes establece
los servicios.
5. El Asistente de Viajes busca empresa Operadoras.
6. La Empresa Operadora envan propuesta de servicios al Asistente de Viajes.
7. El Asistente de Viajes evala propuesta de servicios.
8. El Asistente de Viajes selecciona a la empresa operadora.
9. El Asistente de Viajes establece los costos del paquete turstico.
10. El Asistente de Viajes enva la informacin fnal de los paquetes al gerente
comercial y termina el proceso
59
Flujos Alternativos
11. En el punto 4, si el Gerente Comercial no acepta propuesta se repite el paso
2.
12. En el punto 7 cuando el Asistente de Viajes evala la propuesta de la
Empresa.Operadora y ninguna oferta es satisfactoria repite el paso 6.
CASO : Servis
La empresa Servs, es una empresa fnanciera que desea implementar un sistema
que le permite gestionar los procesos del rea de Recursos Humanos (RRHH).
El proceso comienza cuando el Jefe de RRHH revisa la solicitud y determina la
cantidad de personal que se requiere y elabora un comunicado, con el cronograma
para de actividades para la seleccin del personal con sus requisitos.
El Jefe de RRHH revisa la relacin y autoriza la entrega al Comit de Evaluacin.
Luego el Comit califca las pruebas y determina la relacin de candidatos aptos.
El Jefe de RRHH consolida los resultados de las evaluaciones, verifca las
referencias laborales, y selecciona al nuevo personal.
El personal tiene medidas disciplinarias defnidas las cuales se detallan:
Sancin: Accin administrativa que castiga a un trabajador por haber cometido
alguna falta de carcter disciplinario en el desempeo de sus funciones. Puede
ser una amonestacin o suspensin en mayor o menor grado dependiendo de la
gravedad de la falta.
Amonestacin: Advertencia o llamada de atencin verbal o escrita a un trabajador
por haber cometido una falta de carcter disciplinario considerada menor en el
desempeo de sus funciones.
MEDIDA DISCIPLINARIA
Objetivo
Mejorar el control de los trabajadores en un 70%
Flujo Bsico
1. El Jefe de Unidad evala un incidente que involucra a un trabajador.
2. Si el trabajador amerita una sancin el Jefe de Unidad comunica el motivo
y el incidente mediante informe al Jefe de RRHH, sugiriendo la sancin que
se podra aplicar.
3. El Jefe de RRHH evala el informe sobre el incidente.
4. El Jefe de RRHH consulta el record laboral de amonestaciones y sanciones
del trabajador.
5. El Jefe de RRHH segn corresponda, conversa con el trabajador.
6. Al realizar la evaluacin cuando la falta es grave :
a. El Jefe de RRHH informa a la Gerencia de Administracin y recomienda
60
la sancin correspondiente.
b. El Gerente de Administracin revisa el informe preparado por el Jefe
de RRHH sobre el incidente y, de ser necesario consulta con el Jefe de
Unidad.
c. El Gerente de Administracin ratifca o modifca la sancin propuesta por
el rea de RRHH.
d. El Jefe de RRHH comunica al rea de Tecnologa de Informacin para que
se tomen las medidas necesarias con el acceso que tiene el trabajador a
los sistemas de informacin.
e. El Administrador de Redes ejecuta el procedimiento de accesos a usuarios
al sistema, redes, internet y servicios.
f. El Jefe de RRHH, da inicio al cese por despido o suspensin y registra la
sancin.
Flujos Alternativos
7. En el punto 2, si el trabajador slo amerita una amonestacin el Jefe de
Unidad amonesta verbalmente al trabajador y fnaliza el proceso.
8. En el punto 6 cuando la falta no es grave:
a. El Jefe de Unidad genera una carta de amonestacin.
b. El Jefe de Unidad entrega la amonestacin escrita al trabajador, y entregar
el cargo al Jefe de RRHH.
c. El Asistente de RRHH archiva en el legajo personal el cargo de la carta de
amonestacin entregada al trabajador y registra la sancin.
CASO : Empresa ABC
La empresa ABC es una empresa fnanciera que desea implementar un sistema
que le permite gestionar los procesos del rea de Recursos Humanos (RRHH).
El proceso comienza cuando el Jefe de RRHH realiza una medicin peridicamente
del nivel de desempeo de cada trabajador con respecto al cumplimiento de las
funciones asignadas. Para ello verifca que se cumpla con los criterios y plazos de la
evaluacin establecidos en el Programa de Evaluacin Anual para posteriormente
verifcar el resultado de la evaluacin y emitir opinin imparcial sobre los casos
presentados. Finalmente elabora un Informe de evaluacin para consolidar los
resultados en el informe fnal, y enviarlo al Gerente General indicando las brechas
de rendimiento, variables motivacionales.
El Jefe de RRHH debido a estos resultados puede tomar la decisin de rotar al
personal para controlar la correcta y oportuna alternancia de puesto de trabajo y/o
cargo de un trabajador dentro de la organizacin.
ROTACIN DEL PERSONAL
Objetivo
Mejorar productividad de los trabajadores en un 60%
61
Flujo Bsico
1. El Jefe de RRHH elabora el Plan de Rotacin Anual del personal en base a
las necesidades y polticas de recursos humanos.
2. El Jefe de RRHH coordina con los jefes involucrados y con el trabajador.
3. El Jefe de RRHH solicita a la Gerencia General la aprobacin de dicho Plan.
4. El Gerente General revisa y aprueba el Plan de Rotacin de Personal.
5. El Jefe de RRHH hace seguimiento al Plan de Rotacin de Personal o la
Solicitud de Rotacin.
6. Si hay solicitud de rotacin por el trabajador/Jefe de Unidad, el Jefe de RRHH
evala el caso y coordina con el trabajador y los Jefes de las Unidades
involucradas, considerando las polticas de rotacin del personal.
7. El Jefe de RRHH si aprueba la solicitud presenta el informe de rotacin de
personal al Gerente de Administracin.
8. Gerente de Administracin verifca y aprueba el informe de Rotacin de
Personal
9. El Jefe de RRHH registra condiciones de rotacin y aprueba
10. El Jefe de RRHH ingresar toda la informacin correspondiente para el
cambio de perfl del trabajador
Flujos Alternativos
11. En el Punto 6 Si no hay solicitud se pasa al punto 9.
12. En el Punto 7 el Jefe de RRHH no aprueba la solicitud de rotacin informar
al trabajador o al responsable que solicit la rotacin del personal y continua
con el punto 9.

CASO INTEGRADOR
GESTION DE RECURSOS HUMANOS
El proyecto est orientado al desarrollo de un Sistema de Recursos Humanos
para la Empresa Financiera ABC, con la fnalidad de automatizar sus procesos.
El rea de Recursos Humanos (RRHH) de la fnanciera desea implementar un
sistema que le permita gestionar los siguientes procesos que administra:
1. Planeamiento de RRHH
2. Seleccin de Personal
2.1. Reclutamiento y Seleccin
2.2. Contratacin e Induccin
3. Desarrollo del Personal
3.1. Plan de desarrollo
3.2. Capacitacin
3.3. Evaluacin de desempeo
3.4. Rotacin de Personal
62
4. Mantenimiento de Personal
4.1. Legajo de Personal
4.2. Pago de Remuneraciones
4.3. Medidas Disciplinarias
4.4. Cese por despido
4.5. Cese por Renuncia
4.6. Cese por Tiempo de Servicio.
El proyecto desarrollara 2 procesos: Medidas Disciplinarias Y Contratacin de
Personal:
1. Especifcacin del caso de uso del negocio
2. La Realizacin de los caso de uso del negocio
3. Identifcacin de actores y casos de uso de cada negocio
4. Diagrama de caso de uso (inicial) del proceso analizado.
ESTRUCTURA DEL MODELAMIENTO EN RATIONAL ROSE
1. Trazabilidad del Modelo del Negocio al Modelo de Casos de Uso:
A continuacin se detalla la especifcacin de caso de uso del negocio Medidas
Disciplinarias utilizando la plantilla de RUP.
ESPECIFICACIN CASO DE USO DEL NEGOCIO: MEDIDAS DISCIPLINARIAS
Breve Descripcin:
El proceso permite realizar y/o coordinar las acciones necesarias para disciplinar a
un trabajador con amonestaciones o sanciones.
Flujo Bsico:
1. El Jefe de Unidad evala un incidente que involucra a un trabajador.
2. Si el trabajador slo amerita una amonestacin.
2.1 El Jefe de Unidad amonesta verbalmente al trabajador y fnaliza el proceso.
3. Si el trabajador amerita una sancin:
3.1 El Jefe de Unidad comunica el motivo y el incidente mediante informe al Jefe
de RRHH, sugiriendo la sancin que se podra aplicar.
4. El Jefe de RRHH evala el informe sobre el incidente.
5. El Jefe de RRHH consulta el record laboral de amonestaciones y sanciones del
trabajador.
6. El Jefe de RRHH segn corresponda, conversa con el trabajador.
63
7. De la evaluacin, si la falta no es grave:
7.1. El Jefe de Unidad genera una Carta de Amonestacin.
7.2. El Jefe de Unidad entrega la amonestacin escrita al trabajador, y entregar
el cargo al Jefe de RRHH.
7.3. El Asistente de RRHH archiva en el legajo personal el cargo de la Carta de
Amonestacin entregada al trabajador y registra la sancin.
8. Si la falta es grave:
8.1. El Jefe de RRHH informa a la Gerencia de Administracin y recomienda la
sancin correspondiente.
8.2. El Gerente de Administracin revisa el informe preparado por el Jefe de
RRHH sobre el incidente y, de ser necesario consulta con el Jefe de Unidad.
8.3. El Gerente de Administracin ratifca o modifca la sancin propuesta por el
rea de RRHH.
8.4. El Jefe de RRHH comunica al rea de Tecnologa de Informacin para que
se tomen las medidas necesarias con el acceso que tiene el trabajador a los
sistemas de informacin.
8.5. El Administrador de Redes ejecuta el procedimiento de Accesos a Usuarios
al Sistema, Redes, Internet y Servicios.
8.6. El Jefe de RRHH, da inicio al cese por despido o suspensin y registra la
sancin.
8.7. Si la decisin fue una suspensin
8.7.1. El Jefe de RRHH genera la Carta de Suspensin al trabajador.
8.7.2. El Jefe de RRHH entrega la Carta al trabajador con copia al Ministerio
de Trabajo y Promocin del Empleo en caso sea necesario, de
acuerdo a las polticas de personal.
8.7.3. El Trabajador recibe y frmar el cargo de recepcin de la Carta de
Suspensin.
8.7.4. El Asistente de RRHH registra la informacin de suspensin y archiva
el cargo por la entrega de la Carta de Suspensin al trabajador.
8.8. Si la decisin fue un Cese por despido:
8.8.1. El Jefe de RRHH procede con el despido del trabajador (Ver Proceso
de Cese por Despido).
64
Flujos Alternativos
No aplica.
Para estructurar el Modelo de casos de Uso del Negocio y Modelo de Anlisis ver
las fguras 1 y 2.
En el Modelo de Casos de Uso del Negocio crear las carpetas: actores del negocio,
casos de Uso del Negocio y Metas. Posteriormente hacer el Diagrama de caso de
uso del negocio, como se muestra en la fgura 3.
En el Modelo de Anlisis del Negocio crear las carpetas: Trabajadores del negocio,
Entidades del Negocio y realizaciones de casos de Uso del Negocio. Ver la fgura
No. 4.
En la carpeta realizaciones CUN hacer el Diagrama de Actividades, para el proceso
Medidas Disciplinados, como se muestra en la fgura No. 5.
Note que el Diagrama de actividades muestra paso a paso las actividades que
realizan cada uno de los Actores o Trabajadores del Negocio. Las actividades que
se van a automatizar se colocan de color amarrillo.
Una vez identifcados los casos de uso con sus roles a automatizar procedemos a
la Captura de Requerimientos como casos de uso.
Para estructurar el Modelo de casos de Uso del sistema ver la fguras 6. Luego
haremos el diagrama de caso de uso del sistema, como se muestra en la fgura 7.
Figura No 1 Estructura del Modelo de Casos de Uso del Negocio (MCUN)
65
Figura No 2 Estructura del Modelo de Anlisis del Negocio (MAN).
Figura No. 3. DCUN MEDIDAS DISCIPLINARIAS
66
Figura No. 4 TRABAJADORES DEL NEGOCIO
67
F
i
g
u
r
a

N
o
.

5
.

D
I
A
G
R
A
M
A

D
E

A
C
T
I
V
I
D
A
D
E
S

M
E
D
I
D
A
S

D
I
S
C
I
P
L
I
N
A
R
I
A
S
68

Figura No. 6. Estructura MCU
Figura No. 7. DCU Medidas Disciplinarias
69
2. Modelo de Casos de Uso sin trazabilidad del Modelo del Negocio:
Si nosotros describimos un proceso sin utilizar la plantilla de Especifcacin de
Caso de Uso, lo veramos as. Lo ideal es tener la plantilla y hacer su diagrama
de actividades, para poder identifcar claramente los actores y casos de uso del
sistema.
PROCESO: Seleccin de Personal
Para el reclutamiento y seleccin el Gerente de un rea, se ha solicitado personal
al Jefe de Recursos Humanos (RRHH), especifcando el perfl del cargo.
El Jefe de RRHH revisa la solicitud y determina si la cantidad de personal
est contemplado en el presente ao. Si no lo est, lo enva al Gerente de
Administracin para su aprobacin. Luego, revisa y determinar si el personal de
la empresa puede formar parte de la seleccin para cubrir la vacante.
Elabora un comunicado, con el cronograma del proceso de Seleccin y sus
requisitos y lo enva por escrito o correo al Asistente Social.
El Asistente Social convoca al concurso, utilizando los siguientes mecanismos:
pgina web y aviso en el peridico o en las bolsas de trabajo de las universidades.
Luego, recepciona el currculo vitae de los postulantes y registra aquello que
tienen el perfl solicitado. Por ltimo, confecciona la relacin de candidatos pre-
seleccionados y lo remite al Jefe de RRHH.
El Jefe de RRHH revisa la relacin y autoriza la entrega al Comit de Evaluacin.
El Comit de Evaluacin elabora la prueba de conocimientos, la cual es tomada
por el Asistente de Recursos Humanos. Luego el Comit califca las pruebas y
determina la relacin de candidatos aptos.
El Asistente Social comunica va telefnica a los candidatos aptos para la
evaluacin psicolgica respectiva. El psiclogo los evala y enva un informe al
Jefe de RRHH con el resultado de los candidatos fnalistas.
El Jefe de RRHH consolida los resultados de las evaluaciones, verifca las
referencias laborales, a la Central de Riesgos, RENIEC, antecedentes policiales,
base de datos de personas negativas, etc. Luego elabora el cronograma de
entrevistas y entrega al Asistente Social.
El Comit entrevista a los candidatos, elabora un Acta de Seleccin y la suscribe.
Por ltimo, el Jefe de RRHH comunica a los postulantes los resultados fnales.
Una vez seleccionado los candidatos, se da inicio al proceso de contratacin e
induccin de personal.
El Asistente Social entrega la carpeta de bienvenida al personal nuevo o personal
promovido al nuevo cargo.
Si se trata de una contratacin a plazo indeterminado:
70
El Jefe de RRHH genera un memorando de Plazo Indeterminado de Trabajo y
lo enva a la Gerencia de Administracin.
El Gerente de Administracin frma el memorando y lo enva al Asistente Social
para que entregue una copia al trabajador.
Si es a plazo determinado:
El Jefe de RRHH genera el contrato en tres (3) copias y lo enva a la Gerencia
de Administracin.
El Gerente de Administracin frma el Contrato y el Asistente Social enva tres (3)
copias de Contrato de Trabajo al Ministerio de Trabajo y Promocin del Empleo.
El Tutor o Jefe inmediato elabora, revisa y aprueba el Plan de Induccin en
coordinacin con el Jefe de RRHH. Prepara la carpeta de Induccin con el
cdigo de tica, reglamento interno, MOF, manual de polticas y reglamentos
y/o manuales (segn el cargo).
El proceso de Induccin se realiza en dos (2) etapas. Primero se capacita todo
lo relacionado a la empresa y despus las funciones del cargo ocupado.
El Trabajador inicia el trabajo de campo, que consiste en la aplicacin prctica
de lo aprendido con la supervisin del tutor, el que evala y presenta un informe
indicando el resultado de la induccin.
El Gerente de rea evala el informe y presenta un informe al Jefe de RRHH.
El Jefe de RRHH evala el informe y entrega al Asistente para su archivo. Luego,
comunica al trabajador los resultados de la induccin.
Si es favorable el informe, se emite un nuevo contrato, sino se emite la liquidacin
de benefcios sociales.
Para estructurar el Modelo de casos de Uso del Negocio agregar los Actores
y Casos de Uso del Negocio y completar con el Diagrama de CUN, como se
muestra en la fgura No. 8.
En la carpeta realizaciones CUN no se har el Diagrama de Actividades, para el
proceso Capacitacin del Personal.
En el Modelo de casos de Uso del sistema adicionar los actores y casos de uso
del sistema. Posteriormente hacemos el diagrama de caso de uso del sistema,
como se muestra en las fguras 9 y 10.
Se recomienda trabajar con paquetes para cada subsistema.
71

F
i
g
u
r
a

N
o
.

8
.

D
C
U
N

S
E
L
E
C
C
I
N

D
E

P
E
R
S
O
N
A
L
72
F
i
g
u
r
a

N
o
.

9

D
C
U

S
e
l
e
c
c
i
n

d
e

P
e
r
s
o
n
a
l

(
I
n
i
c
i
a
l
)
73
F
i
g
u
r
a

N
o
.

1
0

D
C
U

S
e
l
e
c
c
i
n

d
e

P
e
r
s
o
n
a
l

(
e
s
t
r
u
c
t
u
r
a
d
o
)
74
Finalmente documentamos los artefactos creados para este proceso en el rational,
como se detalla a continuacin.
Identifcacin y documentacin de Actores
a. Gerente de rea.- Gerente de cualquier rea de la empresa que solicita
incorporar personal para cumplir con sus funciones.
b. Jefe de RRHH.- Encargado del rea de RRHH, que tiene como unas de
sus funciones el Reclutamiento y Seleccin de Personal; y la Induccin y
Contratacin de los mismos.
c. Asistente Social.- Personal del rea de RRHH que apoya en el Proceso de
Reclutamiento y Seleccin.
d. Evaluador Psicolgico.- Personal encargado de la evaluacin Psicolgica de
los Postulantes.
e. Postulante.- Usuario que cumple el perfl y cargo y solicita ser considerado
Postulante en el proceso de seleccin.
f. Comit Evaluador.- Personas encargadas de tomar la prueba de
conocimientos y entrevistas a los postulantes.
Identifcacin y documentacin de casos de Uso
Proceso de Reclutamiento y seleccin de Personal
a. Solicitar Personal.- Permite a cualquier Gerente de rea solicitar personal
segn el cargo y perfl.
b. Consultar Cuadro de asignacin de Personal.- Permite al Jefe de RRHH
verifcar el Plan Anual de Contratacin de Personal para c/u de las reas de
la empresa.
c. Elaborar Cronograma Seleccin.- Permite elaborar el cronograma para el
proceso de seleccin, indicando los requisitos para el Postulante.
d. Consolidad Resultados de Evaluaciones.- Permite resumir el resultado de
las evaluaciones que tienen los postulantes.
e. Verifcar Referencias Personales.- Permite al Personal de RRHH verifcar
informacin del Postulante, Consulta a RENIEC, BD Negativas, otras.
f. Elaborar Cronograma Entrevistas.- Permite elaborar el cronograma para
las Entrevistas a los Postulantes.
g. Registrar Postulantes.- Permite al personal de RRHH registrar los datos de
los postulantes que cumplen los requisitos para el cargo (perfl), adems de
listar los candidatos pre-seleccionados.
75
h. Elaborar Prueba.- Permite al personal del Comit Evaluador preparar la
prueba de conocimientos.
i. Listar Candidatos.- Permite al Comit Evaluador, listar los candidatos aptos
a Contratar despus de la Prueba de Conocimientos o Entrevista.
j. Registrar Evaluacin Psicolgica.- Permite al Psiclogo registrar la evaluacin
y listar los candidatos fnalistas para la Entrevista Personal.
k. Enviar CV (Web).- Permite a una persona enviar su CV, para ser aceptado
como postulante.
Proceso de Induccin y Contratacin:
l. Generar Memo CPI.- Permite al Jefe de RRHH generar un Memo para
Contrato a Plazo Indeterminado.
m. Generar Contrato.- Permite al Jefe de RRHH generar un contrato para
Contrato a Plazo Fijo.
n. Emitir Liquidacin.- Permite al Jefe de RRHH emitir la liquidacin de benefcios
sociales a un trabajador de la empresa.
Incluidos Extendidos
o. Buscar Trabajador.- Caso de uso incluido que permite buscar los datos de
un trabajador.
p. Buscar cargo.- Caso de uso incluido que permite buscar el cargo al que se
postula un trabajador.
q. Registrar Nuevo cargo.- Caso de uso extendido que permite registrar un
nuevo cargo dentro de las funciones del personal de la empresa.
76
CAPTULO
3
Modelo de Requerimientos
79
Esta disciplina de Modelo de Requerimientos es desarrollar un modelo da el sistema
que se va a construir. La utilizacin de los casos de uso es una forma adecuada de
crear este modelo.
Requerimientos:
Es una condicin o capacidad a la que la aplicacin o el sistema (siendo
construido).
Un requerimiento de software o aplicacin puede ser defnido como:
a. Una capacidad de software necesaria por el usuario para resolver un
problema o alcanzar un objetivo.
b. Una capacidad de software que debe ser reunida o poseda por un sistema
o componente del sistema para satisfacer un contrato, especifcacin,
estndar, u otra documentacin formal.
Naturaleza de la Especifcacin de Requisitos de Software. Se deben especifcar
los siguientes aspectos:
a. Funcionalidad
b. Interfaz Externa
c. Rendimiento
d. Atributos
e. Restricciones de diseo
Ambiente de la Especifcacin de Requisitos. Debe de estar descrita de tal
manera que no describa aspectos del rea de diseo o de implementacin.
Caractersticas de los Requisitos. Los requisitos descritos deben ser:
a. Completos
b. Implementacin Independiente
c. Consistente y no Ambiguo
d. Preciso
e. Verifcable
f. Que pueda ser ledo
g. Modifcable
Aprobacin del Cliente o patrocinador. Todos los requistos descritos deben
contar con ella. Un punto importante a tener en cuenta es la evolucin de los
mismos y proveer mecanismos que permitan la Evolucin de la Especifcacin de
Requisitos, e incluir requisitos del Proyecto en la Especifcacin de Requisitos.
MODELO DE REQUERIMIENTOS
80
Requisitos tales como:
a. Costo
b. Fecha de Entrega
c. Criterios de Validacin y Verifcacin
Requerimientos, que representan:
Los requerimientos de usuarios representan el conjunto completo de resultados
a ser obtenidos utilizando la aplicacin o sistema.
Los requerimientos de la aplicacin deben mostrar todo lo que la aplicacin o
sistema debe hacer, ms todas las restricciones sobre funcionalidad.
Los requerimientos forman un modelo completo, representando la aplicacin o
sistema total a algn nivel de abstraccin.
Si un producto no es lo que el cliente o los usuarios quieren entonces la calidad
de la construccin es irrelevante.
El rol clave de los requerimientos es mostrar a los desarrolladores y usuarios
que se necesita de un sistema. Proveer los requerimientos forma parte de un
lenguaje que todos comprenden, ya que todos estn involucrados, incluyendo
los clientes.
El primer y bsico rol de los requerimientos es por lo tanto la comunicacin.
Buena Especifcacin de Requerimientos:
Un resultado primario de esta administracin es la Especifcacin de Requerimientos,
la cual defne y documenta en forma completa el comportamiento externo del
sistema a ser construido. Caracterizndose por:
Defnidos sin ambigedad
Son completos
Tienen consistencia
Especifca el origen
Evita detalles de diseo
Estn enumerados
Benefcios de una Buena Administracin de Requerimientos
Mejor control de proyectos complejos
Mejora en la calidad del software y en la satisfaccin del cliente
Reduccin en los retrasos y en los costos del proyecto
Mejora en la comunicacin del equipo
Facilita la conformidad con estndares y regulaciones
Los Problemas de la Administracin de Requerimientos
No son siempre obvios y tienen muchas fuentes.
No son siempre fciles de expresar en palabras.
Hay muchos tipos diferentes a distintos niveles de detalle.
El nmero puede llegar a ser inmanejable.
Estn relacionados a otros en una variedad de formas.
81
Hay muchos interesados y partes responsables.
Pueden ser sensibles al tiempo
El Alto Costo de Errores en los Requerimientos
Hay fuertes evidencias que una efectiva administracin de requerimientos
conducen los ahorros del proyecto integral.
Las tres razones primarias para esto son:
a. Costos de reparar errores en los requerimientos superan en mas de 10 veces
a otros errores.
b. Errores de requerimientos comprenden encima del 40% de todos los errores
de un proyecto de software.
c. Pequeos reducciones en el nmero de errores de requerimientos rinden
grandes dividendos al evitar costos de re-trabajo y das de retraso.
Captura de requisitos:
Los requerimientos pueden ser adecuadamente capturados y comunicados a
travs de Casos de Uso
Los Casos de Uso son importantes instrumentos de planifcacin
Tipos de requerimientos:
1. Requerimientos Funcionales
Describen la funcionalidad o los servicios que se espera proveer el sistema.
Estos dependen del tipo de software y del sistema que se desarrolle y de los
posibles usuarios del software.
Cuando se expresan como requerimientos del usuario, habitualmente se
describen de forma general mientras que los requerimientos funcionales del
82
sistema describen con detalle la funcin de ste, sus entradas y salidas,
excepciones, etc.
Ejemplo - Sistema de Biblioteca
1. El usuario deber tener la posibilidad de buscar referencias bibliogrfcas en
el conjunto inicial de la base de datos o seleccionar un sub conjunto de ella.
2. El sistema deber proveer visores adecuados para que el usuario lea
documentos en el almacn de documentos.
3. A cada pedido se le deber asignar un identifcador nico que el usuario
podr copiar al rea de almacenamiento permanente de la cuenta.
2. Requerimientos No Funcionales
Son aquellos requerimientos que no se referen directamente a las funciones
especfcas que entrega el sistema, sino a las propiedades emergentes
de ste como la fabilidad, la respuesta en el tiempo y la capacidad de
almacenamiento.
De forma alternativa, defnen las restricciones del sistema, como la capacidad
de los dispositivos de entrada/salida y la representacin de datos que se
utiliza en las interfaces del sistema.
Sin embargo, estos requerimientos no siempre se referen al sistema de
software a desarrollar
Ejemplos:
Anlisis de la especifcacin de Requerimientos
El sistema de biblioteca puede almacenar documentos en diferentes formatos y
la intencin de este requerimiento es que los visores para todos estos formatos
estn disponibles.
Sin embargo, el requerimiento es ambiguo puesto que no clarifca que los
visores para cada formato deban ser provistos.
Un desarrollador bajo la presin del tiempo sencillamente podra proporcionar
un visor de texto y afrmar que se ha cumplido el requerimiento.
83
MTRICAS PARA ESPECIFICAR REQUERIMIENTOS NO FUNCIONALES
Identifcacin de Requerimientos y Reglas del Negocio
Para identifcar los requerimientos correctos del negocio primero debemos de
comprender como funciona, es decir cuales son las reglas del negocio.
Mientras ms complejo es el sistema una mayor cantidad de vistas del mismo
son necesarias para comprender su funcionamiento.
Las distintas vistas del negocio pueden conseguirse a travs de un mapeo de la
situacin actual utilizando a un alto nivel:
a. El Diagrama de descomposicin funcional o mapeo de procesos.
b. Las cadenas de responsabilidad para la atencin de los requerimientos
c. Los Diagramas de Actividad
d. Los Diagramas de Colaboracin
e. Los Diagramas de Interaccin de Roles
f. Casos de Uso del Negocio
MATRIZ DE CONSISTENCIA:
Se trata de un instrumento sumamente til para estudiar la relacin causa-efecto que
debe existir entre el propsito buscado por un proyecto, los resultados especfcos
que harn posible el cumplimiento del propsito y las actividades que subyacen y
anteceden al cumplimiento de los objetivos anteriores.
La matriz permite identifcar varios resultados a la vez, los cuales deben guardar una
relacin de causalidad con el propsito. Si no se puede demostrar fehacientemente
84
esa relacin en forma directa, es posible que el resultado que se est planteando
obtener con el proyecto no va a incidir con fuerza en el propsito y por lo tanto
tampoco hay garanta de que llegue a cumplirse. En este caso, de llegarse a esa
conclusin y estando ya defnido el propsito, lo mejor es replantear el tipo de
resultado que se est buscando.
Asimismo, la matriz permite ubicar todas las actividades que se plantean como
necesarias para dar cumplimiento a los resultados. Es posible que varias actividades
guarden relacin causa-efecto con ms de un resultado a la vez, pero esto es un
valor agregado. Lo primero que debe hacerse es determinar, segn cada resultado
especifcado en la matriz, cules son las actividades necesarias y que directamente
le van a afectar en una relacin causa-efecto. Cuando se halla determinado la
validez de esa relacin, se puede pasar a identifcar a que otros resultados va a
contribuir a lograr dicha actividad en forma directa, es decir tambin como un factor
de causa-efecto. Sin embargo, es posible hacer una diferenciacin con puntajes
asignados al grado de infuencia directa que lograr una actividad sobre uno o ms
resultados, entendindose que el valor ms alto se corresponde con el resultado
donde el impacto va ser mayor.
Adicionalmente, la matriz permite sumar en forma vertical, el total de actividades
que requiere un resultado para hacerse realidad. Y por otro lado, permite la suma
horizontal de los resultados que son impactados en una relacin causa-efecto por
una misma actividad, identifcndose as la importancia de una actividad por la
cantidad de resultados a los que va a benefciar. Hay que tener en cuenta que
difcilmente un resultado esperado es originado por un solo elemento activo,
requirindose uno o ms factores complementarios. Es decir, varias variables son
generalmente las causantes de lograr un buen resultado, o de generar un problema.
Descripcin de Actores del Sistema
Se le llama Actor a toda entidad externa al sistema que guarda una relacin con
este y que le demanda una funcionalidad. Esto incluye a los operadores humanos
pero tambin incluye a todos los sistemas externos as como a entidades abstractas
como el tiempo.
En el caso de los seres humanos se pueden ver a los actores como defniciones de
rol, por lo que un mismo individuo puede corresponder a uno o ms Actores. Suele
suceder sin embargo, que es el sistema quien va a tener inters en el tiempo. Es
frecuente encontrar que nuestros sistemas deben efectuar operaciones automticas
en determinados momentos; y siendo esto un requisito funcional obvio, resulta de
inters desarrollar alguna forma de capturar dicho requisito en el modelo de caso
de uso fnal.
Ejemplo de matriz de descripcin de actores:
85
ACTOR ASIGNADO A: RESPONSABILIDAD
Gerente
Gerente general de la
empresa
Responsable de la
produccin de cada
uno de los factores de
la empresa.
Administracin
Administracin de los
procesos fnales de los
Servicios.
Responsable en
el seguimiento de
documentos faltantes
entregados por los
clientes.
Jefe de
coordinacin
Se encarga del orden de
los trabajos y equipos.
Responsable en armar
los equipos para el da.
Atencin al cliente Recepcionista
Responsable en
recepcionar y coordinar
los servicios para
efectuarlos a un da
determinado.

En ingeniera del software, un caso de uso es una tcnica para la captura de
requisitos potenciales de un nuevo sistema o una actualizacin de software.
Cada caso de uso proporciona uno o ms escenarios que indican cmo debera
interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo
especfco. Normalmente, en los casos de usos se evita el empleo de jergas tcnicas,
prefriendo en su lugar un lenguaje ms cercano al usuario fnal. En ocasiones, se
utiliza a usuarios sin experiencia junto a los analistas para el desarrollo de casos
de uso.
Ejemplo:
Nro. Caso de Uso Descripcin
C_01
Registrar vendedor
DTV
Se registra cuando es
nuevo.
C_02 Registrar cliente
Se registra cuando es
nuevo.
C_03
Registrar detalle del
servicio
Se registra direccin,
telfonos, tipo de
servicio, etc.
C_04
Registrar vendedor
Gnesis
Se registra el cdigo de
la empresa GENESIS,
cuando el servicio es
por GARANTIA propia
de la empresa.
C_05 Registrar servicio
Se graba toda
informacin brindada
por el cliente.
86
C_06
Coordinar servicio con
cliente
Se registra la
informacin brindada
por el cliente.
C_07
Actualizar datos del
cliente
Se actualizan los
datos de la extranet
corregidos por el propio
cliente.
C_08 Asignar equipo
Se asigna el equipo
creado segn el da.
Integracin de los Casos de Uso y de Actores
El Lenguaje de Modelado Unifcado defne una notacin grfca para representar
casos de uso llamada modelo de casos de uso. UML no defne estndares para que
el formato casos de uso, y as mucha gente no entiende que esta notacin grfca
defne la naturaleza de un caso de uso; sin embargo una notacin grfca puede
solo dar una vista general simple de un caso de uso o un conjunto de casos de uso.
Los diagramas de casos de uso son a menudo confundidos con los casos de uso.
Mientras los dos conceptos estn relacionados, los casos de uso son mucho ms
detallados que los diagramas de casos de uso.
Ejemplo de Integracin de los Casos de Uso y de Actores:
87
Matriz de Caso de Uso y Requerimiento Funcional
MODELO DE CASO DE USO
Un Diagrama de Casos de Uso muestra la relacin entre los actores y los casos
de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que
se refere a su interaccin externa. En el diagrama de casos de uso se representa
tambin el sistema como una caja rectangular con el nombre en su interior. Los
casos de uso estn en el interior de la caja del sistema, y los actores fuera, y cada
actor est unido a los casos de uso en los que participa mediante una lnea.
Diagrama de Contexto que delimita al Sistema de informacin.
Consolida los mltiples Casos de Uso.
Se puede optar por grafcar de forma que se destaque:
Los CU desde una visin funcional del negocio. (Podran convertirse en Sub-
Sistemas).
Los CU utilizados por un Actor
Incluir breve descripcin
Incluir todos los actores
El Glosario de Trminos nos sirve para darle consistencia a todo el modelo
Podemos agrupar los CU en Paquetes en mltiples jerarquas .
Actor:
Un actor es un agente, alguien o algo que solicita un servicio al sistema o acta
como catalizador para que ocurra algo.
Un actor es algo con comportamiento, como una persona (identifcada por
un rol), un sistema informatizado u organizacin, y que realiza algn tipo de
interaccin con el sistema.. Se representa mediante una fgura humana dibujada
con palotes. Esta representacin sirve tanto para actores que son personas
como para otro tipo de actores.
88
Caso de Uso:
Representa un proceso o un requerimiento solicitado por los usuarios el cual debe
ser satisfecho por el analista programador.
Un caso de uso es una descripcin de la secuencia de interacciones que se producen
entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una
tarea especfca. Expresa una unidad coherente de funcionalidad, y se representa
en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de
uso debajo de l. El nombre del caso de uso debe refejar la tarea especfca que el
actor desea llevar a cabo usando el sistema.
1. Qu es estructurar?
Separar en partes el CU para hacer menos CU
Para que?
a. Simplifcar el CU original
b. Fcil entendimiento y mantenimiento
c. Reutilizar el comportamiento
d. Compartir entre los CU
89
Relaciones
Figura No. 1. Relaciones entre casos de uso
2. Relacin <<Include>>
Dependencia entre 2 CU. CUB depende del CUI
CUI ocurre obligatoriamente en el CUB. Al CUB le interesa el resultado del
CUI
Se extrae comportamiento comn del CU y simplifca CU complejo
CUI es ABSTRACTO, es decir slo ocurre en el contexto de otro
No puede ser iniciado de forma independiente por un Actor.
Figura No. 2. Relacin Include
CU: Retirar Dinero
Flujo Bsico
1. El sistema incluye Identifcar Cliente
2. El sistema muestra opciones
3. El Cliente selecciona Retirar Dinero
CU: Identifcar Cliente
Flujo Bsico
1. Insertar tarjeta
2. Validad tarjeta
3. Ingresa PIN
4. Verifca PIN
Flujos Alternativos
90
A1. No es vlida la tarjeta
A2. Mal el PIN
3. Relacin <<Extend>>
Dependencia entre 2 CU. CUE depende del CUB
CUE ocurre excepcionalmente (opcional) en el CUB
CUB interesa el resultado del CUE
Extrae comportamiento opcional y simplifca un CU complejo
CUE es ABSTRACTO
En ocasiones puede ser iniciado de forma independiente por un Actor.
Figura No. 3. Relacin Extend
CU: Retirar Efectivo
Flujo Bsico
1. El ATM (sistema) incluye Identifcar Cliente
2. El ATM muestra opciones
3. El Cliente selecciona Retirar Efectivo
4. El Cliente ingresa cuenta y monto
5. El ATM enva transaccin al Consorcio del Banco
6. El ATM recibe informacin
7. El ATM muestra opciones
8. El ATM dispensa billetes
9. El ATM devuelve la tarjeta
10. El ATM imprime el Voucher y el CU fnaliza.
Puntos de extensin:
En el punto 7 del FB, si el Cliente selecciona Moneda el CU se extiende al CU
Retirar Moneda.
CU: Retirar Moneda
91
Breve Descripcin
Este CU es extensin del CU Retirar Efectivo.
Flujo Bsico
1. El Cliente ingresa el Tipo y nmero de monedas
2. el ATM calcula el total del retiro y solicita confrmacin
3. El Cliente acepta
4. El ATM dispensa las monedas y el CU fnaliza.
Flujos Alternativos
A1. No existen Monedas
4. Relacin <<Generalization>> entre Casos de Uso:
Relacin de un CUH (hijo) con un CUP (padre).
Describe el comportamiento general compartido por el padre.
Describe el comportamiento especializado en el Hijo.
Figura No. 4. Relacin Generalization Casos de Uso
Comprobar Contrasea:
Validacin de contrasea
Scanear Retina:
Validacin de puntos de retina

5. Relacin <<Generalization>> entre Actores
Actores con caracterstica comunes.
92
Figura No. 5. Relacin Generalization Actores
ESPECIFICACIN DE CASO DE USO
No existe estndar UML para una especifcacin de caso de uso, sin embargo
una plantilla para una especifcacin sencilla de caso de uso utilizada comnmente
contiene la siguiente informacin:
- Nombre del caso de uso.
- Breve descripcin.
- Actores implicados en el caso de uso
- Flujo de eventos
- Pre-Condiciones
- Post-Condiciones
- Puntos de extensin
- Requisitos especiales
- Prototipos
EJEMPLO DE ESPECIFICACIN DE LOS CASOS DE USO DEL SISTEMA
Especifcacin de Caso de Uso: Listar Pedidos:
1. Breve Descripcin:
El caso de uso permite administrar los pedidos de mercancas al almacn.
La atencin a los pedidos se realiza mientras se encuentren en estado No
Atendidos o En Atencin.
2. Flujo de Eventos:
Evento disparador.- El caso de uso comienza cuando el Tcnico de Almacn
(TA) selecciona la opcin Lista de Pedidos en la interfaz principal del sistema.
93
2.1. Flujo Bsico
1. El sistema incluye el caso uso Buscar Usuario.
2. El sistema muestra la interfaz LISTA DE PEDIDOS. La interfaz muestra
la Lista de Pedidos en los estados No Atendidos, En Atencin, Listos
para Envo y Enviados. Las listas contienen los datos: cdigo, fecha de
elaboracin y fecha llegada al almacn. Incluye las opciones: Atender,
Consultar, Cancelar o Salir.
3. El TA selecciona un pedido de la lista de pedidos No atendidos o En
Atencin.
4. Si el TA selecciona Atender
Ir al Sub Flujo Atender Pedido.
5. Si el TA selecciona Consultar
Ir al Sub Flujo Consultar Pedido.
6. Si el TA selecciona Cancelar Pedido
Ir al Sub Flujo Cancelar Pedido.
7. Si el TA Selecciona Salir
El sistema cierra la interfaz principal y el caso de uso termina.
2.2. Sub Flujo Atender Pedido:
1. El sistema muestra la interfaz ATENDER PEDIDO.
En la interfaz se muestran los Datos del usuario: cdigo y nombre, los
Datos del pedido: el cdigo del pedido, fecha de llegada al almacn,
fecha de atencin, direccin de envo y la Lista de productos que
contiene la orden: cdigo del artculo, descripcin, cantidad solicitada,
cantidad asignada, stock real, stock disponible, stock asignado.
Muestra las opciones Guardar, Pasar a Envos, Incidencias y Salir.
2. El TA almacn selecciona una lnea de pedido (producto) para editarla.
Para cada lnea de pedido el TA puede cambiar la cantidad asignada
del stock disponible en el almacn.
3. El sistema comprueba si hay stock sufciente en el almacn y reserva
el stock del almacn.
4. Si el TA decide modifcar otra lnea de pedido, vuelve al punto 2.
94
5. Si el TA selecciona Guardar.
El sistema guarda la orden de pedido en estado En Atencin, muestra
mensaje Pedido en atencin y cierra la interfaz ATENDER PEDIDO.
6. Si el TA selecciona Pasar a Envos.
El sistema guarda la orden de pedido en estado Listo para Envo,
muestra mensaje Listo para envo y cierra la interfaz ATENDER
PEDIDO.
7. Si el TA selecciona Incidencia.
El sistema extiende al caso de uso Registrar Incidencias.
8. Si el TA selecciona Salir:
El sistema muestra un mensaje de confrmacin Est seguro de
No guardar los datos?
El TA confrma
El sistema no almacena la informacin ingresada y cierra la interfaz
ATENDER PEDIDO.
2.3. Sub Flujo Consultar Pedido:
1. El sistema muestra la interfaz ATENDER PEDIDO, con todos los datos del
pedido slo para lectura y la opcin Salir.
2. El TA inspecciona los datos y al fnalizar selecciona Salir
3. El sistema cierra la interfaz ATENDER PEDIDO y regresa a la interfaz
principal.
2.4. Sub Flujo Cancelar Pedido:
1. El sistema muestra un mensaje de confrmacin Esta seguro que desea
eliminar la orden?
2. El TA confrma la cancelacin
3. El sistema cancela el pedido eliminndolo de las listas de atencin.
2.5. Flujos Alternativos:
<Stock en el Lmite>
En el punto 3 del SF Atender Pedido, si el stock disponible queda en cantidad
negativa, el sistema muestra el mensaje Stock en el Lmite. El fujo contina
en el punto 2.
3. Requerimientos Especiales:
El caso de uso debe estar disponible a travs de Internet, previo logeo del usuario.
95
Precondiciones:
1. El TA se haya logeado en el sistema.
2. Los pedidos y productos estn disponibles en el sistema.
5. Poscondiciones:
1. El pedido queda registrado en el sistema en la lista de Pedidos en Atencin.
2. El pedido queda registrado en el sistema en la lista de Listos para envo.
3. El pedido queda cancelado en el sistema.
6. Puntos de Extensin:
1. Caso de Uso Registrar Incidencia, en el paso 7.1. del SF Atender Pedido.
7. Prototipo:
7.1. Listar Pedidos (Flujo Bsico)

96
7.2. Atender un Pedido (Subfujo):
Especifcacin de Caso de Uso: Buscar Usuario
1. Breve Descripcin
El sistema permitir realizar la bsqueda del usuario.
2. Flujo de Eventos
2.1. Flujo Bsico
1. El sistema busca al usuario.
2. El sistema muestra el cdigo y nombre del usuario en la interfaz del caso
de uso que lo invoco y el caso de uso fnaliza.
2.2. Flujos alternativos
<Usuario no encontrado>
Si en el punto 1 no se encuentra al usuario, el sistema muestra un mensaje Usuario
no encontrado en la interfaz del caso de uso que lo invoco y fnaliza el caso de uso.

97
PRIORIZACIN DE CASO DE USO:
Se hace un ranking de CU
El ranking de CU sirve de consulta para guiar el desarrollo de las versiones del
software .
Se consideran aspectos econmicos y de negocio.
Se necesita presentar el resultado del trabajo para su aprobacin al Gerente del
Proyecto.
Importante para planear el desarrollo incremental.
CU Crticos:
Ms importantes para los usuarios porque cubren las principales tareas o
funciones que el sistema ha de realizar. Defnen la arquitectura bsica.
CU Secundarios:
Sirven de apoyo a los casos de uso crticos.
Tienen un impacto ms modesto sobre la arquitectura, pero deben
implementarse pronto porque responden a requerimientos de inters para
los usuarios.
CU Auxiliares:
No son claves para la arquitectura.
Completan casos de uso crticos o secundarios.
CU Opcionales:
Responden a funcionalidades que pueden o no estar en la aplicacin, y que
no son imprescindibles en las primeras versiones.
Descripcin de los requerimientos funcionales y no funcionales.
Requerimientos Funcionales:
Nro. Descripcin Prioridad
RF01
El sistema mostrar reportes diversos segn
los requerimientos del usuario.
Media
RF02
Gestin administrativa y clnica de la historia
del usuario
Alta
RF03
Registrar la obtencin de citas de forma
segura y rpida.
Alta
RF04
Registrar los exmenes clnicos de los
pacientes.
Alta
98
RF05
Registrar y Consultar horario del personal
mediante la interfaz web interna.
Media
RF06
Controlar los productos por laboratorios de las
empresas
Media
RF07 Registrara los medicamentos nuevos Media
RF08
Proporcionar descuentos dependiendo del tipo
de pago.
Media
RF09
Proporcionara comprobante de pago
dependiendo del pedido del cliente y/o paciente
Alta
RF10
Evaluara descuentos dependiendo de la
especialidad a tratar.
Media
RF11
Controlara las fechas de vencimientos de los
productos mediante alertas
Media
Requerimientos No funcionales:
Nro. Descripcin Prioridad
RF01
El tiempo de respuesta a una consulta no debe
exceder de los 3 s.
Alta
RF02 La memoria RAM requerida es de 1 gb. Media
RF03
El sistema es compatible con versin de
Windows Xp o posterior.
Baja
RF04
El sistema debe de ser confable, realizando
procesos seguros.
Alta
RF05
Se deben de tener en cuenta las licencias al
momento de la implantacin de software.
RF06
El sistema debe ser accesible al usuario que
interacte con el.
Alta
RF07
La documentacin proporcionada sobre el uso
del software debe ser clara y concisa.
Baja
RF08
La interfaz de usuario debe adecuarse a los
requerimientos del usuario, mostrando grfcos
en los procesos que lo requieran.
Media
RF09
El sistema debe soportar la cantidad de
usuarios concurrentes.
Alta
RF10
El sistema debe ser accesible a posibles
modifcaciones futuras en su estructura.
Media
RF11 El lenguaje de programacin ser C# Media
99
RESOLUCIN DE EJERCICIOS

Descripcin de los actores del sistema
Nro. Caso de Uso Descripcin
CU001 Registrar pago cita
Tomando los datos principales del
paciente y con el respectivo pago, se
genera la cita con la fecha y hora indicada
por el usuario.
CU002
Registrar pago
farmacia
Se registra el pago del medicamento
aplicando un descuento si se diera el
caso.
CU003
Actualizar historial
clnico
Los datos del paciente, as como
exmenes son registrados en este
documento.
CU004 Consultar horario
Aqu se encuentra registrados los horarios
de los mdicos y especialidades.
CU005 Consular HC
Si el historial clnico existe se procede
a realizar el proceso siguiente en el
escenario donde se encuentre, caso
contrario se crear el historial clnico
tomando los datos inciales del paciente.
CU006 Consultar stock
Realiza una bsqueda del producto en
la Base de Datos, en caso de que no
existiera el sistema emitir un mensaje.
CU007
Registrar
disponibilidad
Para la creacin de los horarios del
personal.
CU008
Registrar orden de
anlisis
Caso de uso generado por el Doctor luego
de haber analizado al paciente.
CU009 Consultar cita
Se verifca la existencia de la cita en el da
y horario establecido.
CU010 Registrar diagnostico
Tratamiento que dar al conocer el medico
luego de culminar la cita.
CU011
Seleccionar
tratamiento
Tratamiento a realizar al paciente.
CU012
Generar cronograma
de pago
Si el pago se realiza con tarjeta de
crdito, entonces se genera el nmero
de cuotas a saldar dicho monto.
CU013 Aperturar HC
Contiene los datos del paciente en la
primera vez que es registrado.
CU014 Registrar paciente Relacionado con Aperturar HC.
CU015 Registrar anlisis
El rea de laboratorio registrar en el HC
el resultado del anlisis.
CU016
Consultar orden de
anlisis
Los exmenes clnicos
CU017 Generar horario
Se generan los horarios disponibles para
cada personal dentro de la clnica.
100
I
n
t
e
g
r
a
c
i
n

d
e

l
o
s

c
a
s
o
s

d
e

u
s
o

y

a
c
t
o
r
e
s
:
101
Especifcacin de los casos de usos
Caso de uso: Generar Horario
Cdigo- Nombre Generar Horario(Doctor)
Descripcin
Este caso de uso inicia cuando el Jefe de Personal
asigna los horarios al personal administrativo y/o
servicios que se brindan dentro de la clnica, cabe
mencionar a: Doctores, Enfermeras, Cajeros, y
Exmenes Clnicos.
Actores Jefe de Personal
Requerimientos
Funcional
RF05 - Registrar y Consultar horario del personal
mediante la interfaz web interna.
Referencias
Especifcacin
Flujo Bsico:
1. El caso de uso comienza cuando el Jefe de Personal solicita Registrar
Horario en el Men Personal.
2. El sistema muestra la interfaz Confgurar Horarios con los siguientes
campos:
Datos del Doctor: Especialidad, Listado de Doctores.
Datos del Turno: Fecha, Horarios de turno.
3. El sistema carga automticamente: Datos de la Especialidad, Listado de
Doctores, Turnos a asignar y listado de consultorios.
4. El sistema emite el caso de uso: Verifcar disponibilidad.
5. El Jefe de Personal selecciona la Especialidad a registrar.
6. El sistema muestra el listado de Doctores pertenecientes a la especialidad
seleccionada.
7. El Jefe de Personal selecciona el Doctor requerido.
8. El Jefe de Personal selecciona las fechas en el calendario y pulsa el
botn para aadirlos a la lista denominada grupo de fechas.
9. El Jefe de Personal, selecciona la fecha y pulsa en el botn <<Buscar
Consultorio>>.
10. El Sistema muestra en un recuadro, el listado de consultorios clasifcados
por colores de acuerdo a su disponibilidad.
102
11. El Jefe de Personal, selecciona el consultorio haciendo clic derecho
sobre el.
12. El sistema oculta el recuadro de consultorios.
13. El Jefe de Personal, pulsa sobre el botn <<Guardar>>
14. El sistema emite un mensaje indicado el estado de registro (registro
aadido, no se pudo aadir el registro).
Flujo Alternativo (Errores, excepciones, situaciones anormales)
<No existen consultorios disponibles>
Si en el punto 10 no se encuentran consultorios disponibles, el caso de uso
fnaliza.
Requerimientos Especiales
Pre-Condiciones
1. Usuario logeado en el sistema.
2. Lista de Especialidades, Doctores, Turnos y Consultorios disponibles.
Post-Condiciones
Puntos de Extensin
Caso de uso: Registrar pago cita
Cdigo- Nombre Registrar pago cita (doctor).
Descripcin
Este caso de uso inicia cuando el Jefe de Personal
asigna los horarios al personal administrativo y/o
servicios que se brindan dentro de la clnica, cabe
mencionar a: Doctores, Enfermeras, Cajeros, y
Exmenes Clnicos.
Actores Cajero Cita
Requerimientos
Funcional
RF02 - Gestin administrativa y clnica de la historia
del usuario
RF03 - Registrar la obtencin de citas de forma
segura y rpida.
RF08 - Proporcionar descuentos dependiendo del tipo
de pago.
RF09 - Proporcionara comprobante de pago
dependiendo del pedido del cliente y/o paciente
RF10 - Evaluara descuentos dependiendo de la
especialidad a tratar.
RF13 - Mediante su interfaz web, el usuario podr
generar una cita desde la comodidad de su hogar.
Referencia
Especifcacin
103
Flujo Bsico:
1. El caso de uso comienza cuando el Cajero solicita Emitir cita en el Men
Caja.
2. El sistema muestra la interfaz CITAS con los siguientes campos: Datos
del Doctor: Nombre, Especialidad.
3. El sistema carga automticamente: Datos de la Especialidad, Listado de
Doctores.
4. El Cajero_Cita selecciona una especialidad.
5. El sistema muestra el registro de Doctores pertenecientes a la especialidad
solicitada.
6. El Cajero_Cita selecciona un Doctor.
7. El Cajero_Cita selecciona una fecha.
8. El Cajero_Cita pulsa en el botn <<Ver>>.
9. El sistema incluye el caso de uso Consulta horario especialidad.
10. El sistema muestra la opcin nueva cita y ver detalle en caso exista
registro con los datos especifcados anteriormente.
11. El sistema muestra el listado de citas generadas en la fecha indicada y
doctor correspondiente.
12. El Cajero_Cita pulsa sobre la opcin <<nueva cita>>.
13. El Sistema muestra el recuadro: Bsqueda de Paciente.
14. El Cajero_Cita pulsa con el Link Nueva Cita.
15. El sistema muestra el cuadro de bsqueda de paciente.
16. El Cajero_Cita ingresa los el criterio de bsqueda indicado,
17. El Cajero_Cita pulsa en el botn buscar.
18. El sistema incluye el caso de uso Consultar historial clnico.
19. El sistema muestra el resultado de dicha bsqueda.
20. El Cajero_Cita selecciona los datos del paciente a registrar.
21. El Cajero_Cita pulsa en el botn <<Asignar>>.
22. El Sistema oculta el recuadro mostrado anteriormente.
23. El Cajero_Cita pulsa sobre el botn Generar Doc. Venta.
24. El sistema muestra la interfaz Documento de Venta.
25. El sistema carga automticamente el detalle de la venta obtenida del
formulario anterior.
26. El Cajero_Cita ingresa los datos del Cliente.
27. El Cajero_Cita elige una de las opciones (boleta o factura).
28. El sistema procesa datos y muestra en pantalla segn el tipo de documento.
29. El Cajero_Cita pulsa en el botn grabar.
30. El sistema guarda los datos en la base de datos correspondiente.
Flujo Alternativo (Errores, excepciones, situaciones anormales)
Si en el punto 8 no existen horarios disponibles, el sistema emite un mensaje
y el caso de uso fnaliza.
Requerimientos Especiales
Pre-Condiciones
1. Usuario logeado en el sistema.
2. Lista de Especialidades, Doctores, Turnos.
3. Listado de paciente disponible.
Post-Condiciones
Puntos de Extensin
104
CASOS PROPUESTOS
CASO : FARMACIA BYC
La farmacia BYC en los ltimos aos ha aumentado el nmero de sucursales y de
usuarios, lo que ha llevado a la necesidad de contar con un Sistema Informacin
que le permita controlar las compras y ventas de cada sucursal.
Cada sucursal cuenta con un almacn propio en donde puede consultar el stock de
sus productos as como almacenarlos cuando estos son adquiridos.
El Qumico Farmacutico podr en el sistema registrar las rdenes de compra de
forma directa sin cotizacin o consultado alguna cotizacin realizada anteriormente.
Una orden de compra contiene los datos de un slo laboratorio, y de los frmacos
que pertenece a ese laboratorio y un frmaco tiene atributos: cdigo, nombre
comercial, unidad medida de presentacin, unidad mnima de dispensacin, valor
ltima adquisicin, descuento.
El Recepcionista puede ingresar en el sistema las rdenes de ingreso de frmacos
por cada orden de compra. El comprobante del proveedor es por cada ingreso y
debe refejar los precios y descuentos acordados en la orden de compra.
Las ventas en farmacia se realizan al contado al cliente externo y empleados,
y al crdito slo a empleados y algunos clientes potenciales autorizado por el
administrador de la farmacia. El cliente se acerca a ventanilla y entrega su receta al
vendedor y este busca los frmacos, si existe todo lo recetado entonces le entrega
una orden de pago y si existe parcialmente le indica el valor de lo existente. Luego
el cliente va a caja (Cajero) y cancela la orden y recibe un comprobante de pago,
luego l entrega la orden cancelada al despachador para su entrega de frmacos.
En la venta es importante que el vendedor antes de realizar la orden de pago
vea que el stock sea menos las cantidades comprometidas por otras rdenes del
mismo producto.
Todo el movimiento y su costo promedio de un producto de un almacn se debe
controlar mediante un Krdex, el cual es consultado por el Qumico Farmacutico.

CASO: BIBLIOTECA El SABIO
La Biblioteca El Sabio del Per desea realizar un sistema para efectuar el control
de prstamos de los libros y cubculos a sus diferentes usuarios.
Los libros son prestados a travs de una forma denominada Solicitud de Prstamo
a los diferentes usuarios, de tal manera que el usuario puede realizar su solicitud
va intranet o en una PC de la biblioteca. De la solicitud de prstamo se almacena el
nmero de la misma, la fecha de solicitud y datos de los usuarios y libros. El sistema
debe verifcar la existencia o disponibilidad del libro. Si el libro no se encuentra el
sistema dar un mensaje El libro no se encuentra disponible
El bibliotecario debe dar la atencin a la solicitud de prstamo y entregar el libro
solicitado.
105
Los usuarios pueden ser de dos tipos: alumnos y profesores. Los profesores pueden
solicitar hasta 5 libros y los alumnos mximo 2.
La reserva de los cubculos es registrada slo por los alumnos en donde deben
indicar fecha reserva, su capacidad y cantidad de equipos con que cuenta.
Los pedidos de los cubculos se efectan a travs de la Internet generndose un
nmero nico para su identifcacin, siendo registrado por los usuarios. Tambin el
sistema debe verifcar disponibilidad de cubculos. De los pedidos de cubculos se
registra la fecha del prstamo, el turno solicitado y su correspondiente aprobacin
que debe ser realizada por el auxiliar de biblioteca.
El jefe de biblioteca tambin puede realizar las funciones del bibliotecario pero
adems es el encargado de abastecer a la biblioteca de nuevos libros, para ello el
sistema le debe permitir realizar una orden de compra al proveedor, solicitando los
libros que han tenido mayor demanda en el ltimo periodo acadmico
La biblioteca aplica sanciones basadas en el tiempo que excedi la entrega de uno
o varios libros. De las sanciones se guarda el tipo de la sancin, fecha inicio, fecha
trmino. Las sanciones se aplican en el momento en que el bibliotecario registra la
devolucin del libro.
106

BIBLIOGRAFA
LIBROS:
Modelamiento de Sistemas con UML (Alberto Tejeda).
Anlisis y Diseo orientado a objetos con UML y el Proceso Unifcado (Stephen
R. Schach).
El Proceso Unifcado de Desarrollo de Software (Ivar Jacobson, Grady Booch
y James Rumbaugh).
Ingeniera del Software - Un Enfoque Practico -(R.S. Pressmam) Sexta
Edicin.
Anlisis y Diseo Orientado a Objetos de Sistemas - (Simon Bennett, Steve Mc
Robb y Ray) Tercera Edicin.
Anlisis de Sistemas de Software ( Zalatiel Carranza).
DIRECCIONES WEB:
http://www.programacionextrema.org/articulos/newMethodology.es.html
http://www.scribd.com/doc/2563977/RUP-UML
http://www.scribd.com/doc/3993682/RUP-UML
http://www.slideshare.net/david.motta/modelo-del-negocio-con-rup-y-uml-
parte-3

3ero Manual IngenieSistemasI

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

3ero Manual IngenieSistemasI

Загружено:

Авторское право:

Доступные форматы

INGENIERA DE

Modelos Completos (Casos de Uso, Anlisis, Diseo, Despliegue e

Вам также может понравиться