Teoria Ads

Anlisis y Diseo
de Sistemas I
ANLISIS Y DISEO DE SISTEMAS I
ndice
Pgina
Presentacin
Red de contenidos
Unidad de Aprendizaje 1
INGENIERA DE SOFTWARE, RUP Y UML
1.1 Tema 1
: Ingeniera de Software, Metodologa RUP y UML
9
11
1.1.1. : Elementos claves de la Ingeniera de Software
12
1.1.2. : Las fases genricas de un proceso de software
13
1.1.3. : Modelos de Proceso de Software
14
1.1.4. : Metodologa RUP (Rational Unified Process -RUP)
19
1.1.5
20
: Mejores Prcticas de RUP
1.1.6. : Estructura de RUP
22
1.1.7. : Modelamiento Visual empleando el (UML)
25
1.1.8. : El Lenguaje de Modelamiento Unificado
26
1.1.9. : Diagramas de UML 2.0
30
1.2 Tema 2
: Herramienta Case y Entorno de IBM RSA
39
1.2.1. : Objetivos de las herramientas C.A.S.E.
39
1.2.2. : Tipos de herramientas C.A.S.E.
39
1.2.3. : Ejemplos de herramientas C.A.S.E.
39
1.2.4 : Rational Software Architect
42
DISCIPLINA DEL MODELADO DEL NEGOCIO
43
2.1 Tema 3
45
: Modelado del Negocio
2.1.1. : Cundo ser necesario hacer el Modelado de Negocio?
45
2.1.2. : Cundo no ser necesario hacer el Modelado de Negocio?
46
2.1.3. : Actividades para realizar un Modelado de Negocio
46
2.2 Tema 4
: Modelo de Casos de uso del Negocio
48
2.2.1. : Determinar la situacin de la organizacin
48
2.2.2. : Identificar los procesos de negocio
48
2.2.3. : Refinar las definiciones de los procesos de negocio
48
2.2.4. : Artefactos del Modelo de Casos de uso del negocio
49
CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS
CIBERTEC
2.3 Tema 5
: Modelo de Anlisis de Negocio
50
2.3.1. : Disear las realizaciones de los procesos de negocio
50
2.3.2. : Artefactos del Modelo de Anlisis del negocio
51
DISCIPLINA DE LA CAPTURA DE REQUISITOS
63
3.1 Tema 6
65
: Captura de requisitos
3.1.1. : Artefactos de la Captura de Requisitos
65
3.1.2.
67
Actividades para realizar la Captura de Requisitos
3.1.3. : Requerimientos
68
3.1.4.
Requisitos FURPS
69
3.1.5.
Tcnicas para capturar requisitos
72
3.1.6. : Captura de requisitos a solicitud del cliente
76
3.1.7. : Captura de requisitos a partir del diagrama de actividades del

negocio
3.2 Tema 7 : Modelo de casos de uso.
77
84
3.2.1. : Encontrar actores y casos de uso
85
3.2.2.
85
Encontrar actores
3.2.3. : Encontrar casos de uso
88
3.2.4.
90
3.3 Tema 8
Crear el Diagrama de casos de uso

: Estructurando el modelo de casos de uso.
94
3.3.1. : Objetivos
94
3.3.2.
Tipos de relaciones
95
3.3.3.
Casos de uso abstractos y concretos
98
3.3.4. : Especificaciones de casos de uso
100
3.3.5. : Priorizacin de los Casos de Uso
108
CIBERTEC
Presentacin
Anlisis y Diseo de Sistemas I pertenece a la lnea formativa y se dicta en las
carreras de Computacin e Informtica, Administracin y Sistemas. El curso
imparte conocimientos relacionados con el proceso de Ingeniera de Software
Orientado a Objetos que permite a los alumnos utilizar una metodologa y el
lenguaje de modelamiento unificado para desarrollar un software de calidad.
El manual para el curso ha sido diseado bajo la modalidad de unidades de
aprendizaje, las que se desarrollan durante semanas determinadas. En cada una
de ellas, hallar los logros, que debe alcanzar al final de la unidad; el tema tratado,
el cual ser ampliamente desarrollado; y los contenidos, que debe desarrollar, es
decir, los subtemas. Por ltimo, encontrar las actividades que deber desarrollar
en cada sesin, que le permitirn reforzar lo aprendido en la clase.
El curso es terico prctico: consiste en un taller de desarrollo de proyectos de

software. En primer lugar, se inicia con la comprensin de la Ingeniera de Software
y el proceso de desarrollo de software RUP. Contina con la presentacin del
modelamiento visual y el lenguaje de modelamiento unificado UML. Luego, se
desarrolla la disciplina del Modelado del Negocio. Por ltimo, se concluye con el
desarrollo de la disciplina de la Captura de Requisitos.
CIBERTEC
Red de contenidos
Anlisis y Diseo de Sistemas I
Ingeniera de
Software, RUP y
UML
Ingeniera
de
Software
Herramientas
CASE
Disciplina del
Modelado del
Negocio
Modelado
del Negocio
Modelo de
Casos de Uso
del Negocio
Modelo de
Anlisis del
Negocio
Disciplina de la
Captura de
Requisitos
Captura de
Requisitos
Modelo de
Casos de
Uso
Estructuracin del
modelo de casos
de uso
CIBERTEC
CIBERTEC
UNIDAD
1
INGENIERA
DE
SOFTWARE,
METODOLOGA RUP Y UML
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al trmino de la unidad, el alumno, a partir del correcto entendimiento de la
importancia del papel que cumple la Ingeniera de Software dentro de las
organizaciones, describe las ventajas y desventajas de los modelos de
procesos de desarrollo de software y la importancia de emplear metodologa
RUP para el correcto modelado del ciclo de vida de un software. Asimismo, el
alumno describe los diagramas de UML y utiliza la herramienta CASE Rational
Software Architect.
TEMARIO
1.1 Tema 1
1.1.1.
1.1.2.
1.1.3.
1.1.4.
1.1.5.
1.1.6.
1.1.7.
1.1.8.
1.1.9.
1.2 Tema 2
1.2.1.
1.2.2.
1.2.3.
1.2.4.
:
:
:
:
:
:
:
:
:
:
:
:
:
:
Ingeniera de Software, Metodologa RUP y UML

Elementos claves de la Ingeniera de Software
Las fases genricas de un proceso de software
Modelos de Proceso de Software
Metodologa RUP (Rational Unified Process - RUP)
Mejores Prcticas de RUP
Estructura de RUP
Modelamiento Visual empleando el (UML)
El Lenguaje de Modelamiento Unificado
Diagramas de UML
Herramienta Case y Entorno de IBM RSA
Objetivos de las herramientas C.A.S.E.
Tipos de herramientas C.A.S.E.
Ejemplos de herramientas C.A.S.E.
Rational Software Architect
ACTIVIDADES PROPUESTAS
Los alumnos resuelven un caso para aplicar los diagramas de UML.
CIBERTEC
1.1 TEMA 1: INGENIERA DE SOFTWARE

Segn el DRAE1, ingeniera es el Estudio y aplicacin, por especialistas, de las
diversas ramas de la tecnologa., tambin es la Actividad profesional del ingeniero y
el trmino ingeniero lo define como Persona que profesa la ingeniera o alguna de
sus ramas.; mientras que en el diccionario El pequeo Larouse, ingeniera es el
Conjunto de conocimientos y tcnicas cientficos aplicados a la invencin,
perfeccionamiento y utilizacin de la tcnica industrial en todas sus dimensiones.
Por otro lado, en el DRAE encontramos que software es el Conjunto de programas,
instrucciones y reglas informticas para ejecutar ciertas tareas en una computadora.
Uniendo todas estas definiciones, podemos establecer que la ingeniera de software
es el Uso o aplicacin de conocimientos y tcnicas cientficos para crear programas
de computadora.
La ingeniera de software puede ser definida de mltiples maneras. Es por ello que
existen muchas definiciones expuesta por autores acreditados que comenzaron en su
momento a utilizar el trmino, entre ellos Bauer, Boehm, Zelkovitz y Sommerville y
otras dadas por organismos internacionales profesionales de prestigio tales como
IEEE2 o ACM3. Ms adelante la definicin fue incluyendo el trmino de calidad,
mejorando as la definicin de la Ingeniera de Software.
Se ha elegido la definicin utilizada por Roger Pressman, quin indica que la
ingeniera de software es una tecnologa multicapa. Como muestra la figura 1.1,
cualquier enfoque de ingeniera, incluida ingeniera del software como lo indica el
autor, debe apoyarse sobre un compromiso de organizacin de calidad. La calidad,
segn indica, es la concordancia del software producido con los requisitos
explcitamente establecidos, con los estndares de desarrollo prefijados y con los
requisitos implcitos no establecidos formalmente, que desea el usuario.
Figura 1.1.- Capas de la Ingeniera de Software segn Roger Pressman.
El fundamento de la ingeniera del software es la capa de proceso. El proceso de la

ingeniera del software es la unin que mantiene juntas las capas de tecnologa y que
permite un desarrollo racional y oportuno de la ingeniera del software. El proceso
define un marco de trabajo para un conjunto de reas clave de proceso que se deben
establecer para la entrega efectiva de la tecnologa de la ingeniera del software. Las
reas claves del proceso forman la base del control de gestin de proyectos del
software y establecen el contexto en el que se aplican los mtodos tcnicos, se
obtienen productos del trabajo (modelos, documentos, datos, informes, formularios,
etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona
adecuadamente.
1
DRAE, Diccionario de la Real Academia Espaola de la Lengua.

IEEE, Institute of Electrical and Electronics Engineers.
3
ACM, Association for Computing Machinery.
2
CIBERTEC
Los mtodos de la ingeniera del software indican cmo construir tcnicamente el

software. Los mtodos abarcan una gran gama de tareas que incluyen anlisis de
requisitos, diseo, construccin de programas, pruebas y mantenimiento. Los mtodos
de la ingeniera del software dependen de un conjunto de principios bsicos que
gobiernan cada rea de la tecnologa e incluyen actividades de modelado y otras
tcnicas descriptivas.
Las herramientas de la Ingeniera del software proporcionan un enfoque automtico o
semiautomtico para el proceso y para los mtodos. Cuando se integran herramientas
para que la informacin creada por una herramienta la pueda utilizar otra, se establece
un sistema de soporte para el desarrollo del software llamado ingeniera del software
asistida por computadora (CASE).
Luego de describir cada capa, se puede afirmar que el objetivo de la ingeniera de
software es lograr productos de software de calidad (tanto en su forma final como
durante su elaboracin), mediante un proceso apoyado por mtodos y herramientas.
1.1.1. Elementos claves de la Ingeniera de Software

La ingeniera de software incluye los siguientes elementos clave: paradigmas,
estrategias, mtodos o tcnicas, herramientas y procesos, los que a continuacin se
detallan.
1.1.1.1 Paradigmas
Un paradigma representa un enfoque particular o filosofa para la construccin de
software. Cada uno tiene ventajas y desventajas, es por ello que hay situaciones
donde un paradigma resulta ms apropiado que otro.
1.1.1.2 Estrategias
Se denominan estrategias para el desarrollo de software a las distintas maneras en
que se ordena la ejecucin de las actividades requeridas para producir software.
1.1.1.3 Mtodos o tcnicas
Los mtodos o tcnicas indican cmo construir el software tcnicamente y abarcan un
amplio espectro de actividades que incluyen: planificacin y estimacin de proyectos,
anlisis de requisitos y del sistema de software, diseo de la arquitectura de software,
codificacin, documentacin, prueba y mantenimiento.
1.1.1.4 Herramientas
Son instrumentos que suministran un soporte automtico o semiautomtico para el
proceso y para los mtodos. Cuando se integran las herramientas de forma que la
informacin creada por una herramienta pueda ser usada por otra, se establece un
sistema para el soporte de desarrollo del software, llamado ingeniera del software
asistida por computadora (CASE, en ingls). CASE combina software, hardware y
bases de datos sobre la ingeniera del software (una estructura de datos que contenga
la informacin relevante sobre el anlisis, diseo, codificacin y prueba) para crear un
entorno de ingeniera del software anlogo al diseo/ingeniera asistido por
computadora, CAD/CAE para el hardware.
CIBERTEC
10
1.1.1.5 Procesos
Los procesos son la combinacin de estrategias, mtodos y herramientas, que en
forma conjunta dan un resultado particular. Los procesos indicarn qu herramientas
debern utilizarse y cundo se aplican determinados mtodos o tcnicas. Definen la
secuencia en que se aplican los mtodos, los documentos que se requieren, los
controles que aseguren la calidad y las mejores prcticas que permiten a los gestores
a evaluar los progresos. Concretamente, el proceso de desarrollo de software define
quin va a hacer qu, cundo hacerlo y cmo alcanzar un cierto objetivo.
1.1.2. Las fases genricas de un proceso de software

Con independencia del rea de aplicacin, tamao o complejidad del proyecto, el
trabajo que se asocia a la ingeniera del software se puede dividir en tres fases
genricas:
Fase de definicin
Fase de desarrollo
Fase de mantenimiento
DEFINICIN
DESARROLLO
Fallos de definicin
MANTENIMIENTO
Errores
Modificaciones y adaptaciones
Figura 1.2.- Fases genricas de un proceso de software.
1.1.2.1. Fase de definicin

Se centra sobre el qu. Es decir, durante la definicin, el que desarrolla el software
intenta identificar qu informacin ha de ser procesada, qu funcin y rendimiento se
desea, qu comportamiento del sistema, qu interfaces van a ser establecidas, qu
restricciones de diseo existen, y qu criterios de validacin se necesitan para definir
un sistema correcto. Por tanto, han de identificarse los requisitos clave del sistema y
del software. Aunque los mtodos aplicados durante la fase de definicin variarn
dependiendo del paradigma de ingeniera del software (o combinacin de paradigmas)
que se aplique, de alguna manera tendrn lugar tres tareas principales:
La ingeniera de sistemas o de informacin
Planificacin del proyecto del software
Anlisis de requisitos
1.1.2.2. Fase de desarrollo
Se centra en el cmo. Es decir, durante el desarrollo un ingeniero del software intenta
definir cmo han de disearse las estructuras de datos, cmo ha de implementarse la
funcin dentro de una arquitectura de software, cmo han de implementarse los
detalles procedimentales, cmo han de caracterizarse interfaces, cmo ha de
traducirse el diseo en un lenguaje de programacin (o lenguaje no procedimental) y
CIBERTEC
11
cmo ha de realizarse la prueba. Los mtodos aplicados durante la fase de desarrollo

variarn, aunque las tres tareas especficas tcnicas deberan ocurrir siempre:
El diseo del software
La generacin de cdigo
Las pruebas del software
1.1.2.3. Fase de mantenimiento
Se centra en el cambio que va asociado a la correccin de errores, a las adaptaciones
requeridas a medida que evoluciona el entorno del software y a cambios debidos a las
mejoras producidas por los requisitos cambiantes del cliente. Durante la fase de
mantenimiento se encuentran cuatro tipos de cambios:
Correctivo. Para corregir los defectos.
Adaptativo. Para acomodarlo a los cambios de su entorno externo.
(modificaciones en la legislacin, CPU, SO, las reglas de negocio, etc.)
Perfectivo. Para agregar otras funciones adicionales que van a producir
beneficios.
Preventivo. Tambin llamado reingeniera del software, estos cambios se
realizan a fin de que se puedan corregir, adaptar y mejorar ms fcilmente los
programas.
Adems de estas actividades de mantenimiento, los usuarios de software requieren un
mantenimiento continuo. Los asistentes tcnicos a distancia, telfonos de ayuda y
sitios Web de aplicaciones especficas se implementan frecuentemente como parte de
la fase de mantenimiento.
1.1.2.4. Actividades de proteccin
Las fases descritas en esta visin general de la ingeniera del software se
complementan con un nmero de actividades protectoras. Entre las actividades tpicas
de esta categora se incluyen:
Seguimiento y control del proyecto de software
Revisiones tcnicas formales
Garanta de calidad del software
Gestin de configuracin del software
Preparacin y produccin de documentos
Gestin de reutilizacin
Mediciones
Gestin de riesgos
1.1.3. Modelos de proceso de software

Para resolver los problemas reales de una industria, un ingeniero del software o un
equipo de ingenieros debe incorporar una estrategia de desarrollo que acompae al
proceso, mtodos, herramientas y fases genricas descritos en los puntos anteriores.
Esta estrategia a menudo se llama Modelo de Proceso o Paradigma de Ingeniera del
Software. Se selecciona un modelo de proceso para la ingeniera del software segn la
naturaleza del proyecto y de la aplicacin, los mtodos y las herramientas a utilizarse,
y los controles y entregas que se requieren.
CIBERTEC
12
Existen muchos modelos de procesos para la ingeniera de software, entre ellos:
Modelo Lineal Secuencial (Ciclo de Vida Bsico o Modelo de Cascada)

Modelo de Construccin de Prototipos
Modelo DRA (Desarrollo Rpido de Aplicaciones)
Modelos Evolutivos de Procesos de Software:
o El modelo incremental
o El modelo espiral
o El modelo de desarrollo concurrente
Desarrollo basado en componentes
1.1.3.1 Modelo Lineal Secuencial

Llamado algunas veces ciclo de vida bsico o modelo en cascada, el modelo lineal
secuencial propone un enfoque sistemtico, secuencial, para el desarrollo del software
que comienza en un nivel de sistemas y progresa con el anlisis, diseo, codificacin,
pruebas y mantenimiento. Es ideal para proyectos pequeos, rgidos, y donde se
especifiquen muy bien los requisitos.
Existen algunos problemas que ocurren al utilizar este modelo:
Los proyectos reales raras veces siguen el modelo secuencial que propone el
modelo, pues traslapan las etapas.
A menudo es difcil que el cliente exponga explcitamente todos los requisitos. El
interesado debera exponer los requisitos en la etapa inicial, pero en realidad l
lo hace a travs de todo el proceso y esto complica las cosas.
El cliente debe tener paciencia. La primera versin del software llega al final del
proceso, a veces el afn del cliente hace que la aplicacin final no cumpla con
los requisitos
Anlisis
Diseo
Cdigo
Prueba
Mantenimiento
Figura 1.3.- Modelo Lineal Secuencial.
1.1.3.2. Modelo de Construccin de Prototipos

Este modelo comienza con la recoleccin de requisitos, el desarrollador y el cliente
definen los objetivos globales para el software, originndose un diseo rpido que se
centra en una representacin de esos aspectos del software que sean visibles para el
usuario/cliente. De este diseo surge la construccin de un prototipo y este es
evaluado por el cliente/usuario. La interaccin ocurre cuando el prototipo satisface las
necesidades del cliente.
CIBERTEC
13
Con este modelo se reduce el riesgo de construir productos que no satisfagan las
necesidades del usuario. Por otro lado, reduce costos y aumenta la probabilidad de
xito. Pero el problema es que el cliente se sienta decepcionado por no permitirle usar
la primera versin del prototipo o que el desarrollador se sienta tentado en aumentar el
prototipo para construir el sistema final sin tener en cuenta cuestiones de calidad.
Escuchar al
cliente
Construir y revisar la
maqueta
El cliente prueba la
maqueta
Figura 1.4.- Modelo de Construccin de Prototipos.
1.1.3.3 Modelo DRA

Es una adaptacin a alta velocidad del modelo lineal secuencial en el que se logra el
desarrollo rpido de proyectos grandes utilizando un enfoque de construccin basado
en el componente. Comprende las siguientes fases: Anlisis, diseo, cdigo, pruebas
y entrega. Si no existe el compromiso entre clientes y desarrolladores o si los riesgos
tcnicos son altos, los proyectos DRA fracasan.
Figura 1.5.- Modelo de Construccin de Prototipos.
CIBERTEC
14
1.1.3.4 Modelo Incremental

Este modelo combina elementos del modelo lineal secuencial con la filosofa
interactiva de construccin de prototipos; viene a suplir el problema de no poder
retroceder en las fases de desarrollo del software.
El primer incremento es un producto esencial, se afrontan requisitos bsicos, pero
muchas funciones suplementarias quedan sin extraer. El cliente utiliza el producto
central y como resultado de utilizacin o evaluacin, se desarrolla un plan para el
incremento siguiente, este plan afronta la modificacin del producto central para lograr
satisfacer al cliente, la entrega de funciones y caractersticas adicionales. Este proceso
se repite siguiendo la entrega de cada incremento, hasta que se elabore el producto
completo.
Este modelo es apropiado para proyectos de larga duracin que no consuman muchos
recursos y como el producto va desarrollndose incrementalmente, se puede financiar
el proyecto por partes.
Debido a la interaccin con usuarios finales cuando es necesaria la retroalimentacin
hacia el grupo de desarrollo, este proceso puede exigir demasiado tiempo,
agregndose un costo extra a la compaa, pues mientras estos usuarios evalan el
software dejan de ser productivos para la compaa.
Figura 1.6.- Modelo Incremental.
1.1.3.5 Modelo Espiral

Es un modelo de proceso de software evolutivo que acompaa la naturaleza
interactiva de construccin de prototipos con los aspectos controlados y sistemticos
del modelo lineal secuencial. Se desarrolla en una serie de versiones incrementales.
Durante las primeras iteraciones, la versin incremental podra ser un modelo en papel
o un prototipo, las ltimas iteraciones, se producen versiones cada vez ms completas
de ingeniera del sistema. Este modelo se divide en un nmero de actividades
estructurales o regiones de tareas, como comunicacin con el cliente, planificacin,
anlisis de riesgos, ingeniera, construccin y adaptacin, evaluacin del cliente.
CIBERTEC
15
Debido a su complejidad, no se aconseja utilizarlo en pequeos sistemas. Por otro

lado, resulta difcil convencer a grandes clientes de que el enfoque evolutivo es
controlable.
Figura 1.7.- Modelo Incremental.
1.1.3.6 Modelo de Desarrollo Concurrente

Provee una meta descripcin del proceso de software Mientras que en el Espiral la
principal contribucin es que las actividades del software ocurran repetidamente, en el
Concurrente es la capacidad de describir las mltiples actividades del software que
ocurren simultneamente.
Dado que los requisitos cambian es muy probable que una vez haya comenzado la
fase de diseo, sea necesario incorporar cambios. En estos casos No se debe detener
el diseo, sino que se debe continuar si es posible al mismo tiempo que se modifican
los requisitos. Por lo tanto en este modelo, diversas actividades pueden estar
ocurriendo concurrentemente.
Figura 1.8.- Modelo de Desarrollo Concurrente.
CIBERTEC
16
1.1.3.7 Desarrollo Basado en Componentes

Es un modelo fuertemente orientado a la reutilizacin y trabaja sobre la base de
tecnologas orientado a objetos. Este modelo consta de 4 fases ilustradas en la figura
1.9. A continuacin se describe cada fase:
Anlisis de componentes: Se determina qu componentes pueden ser utilizados

para el sistema en cuestin. Casi siempre hay que hacer ajustes para
adecuarlos.
Modificacin de requisitos: Se adaptan (en lo posible) los requisitos para
concordar con los componentes de la etapa anterior. Si no se puede realizar
modificaciones en los requisitos, hay que seguir buscando componentes ms
adecuados (fase 1).
Diseo del sistema con reutilizacin: Se disea o reutiliza el marco de trabajo
para el sistema. Se debe tener en cuenta los componentes localizados en la fase
2 para disear o determinar este marco.
Desarrollo e integracin: El software que no puede comprarse, se desarrolla. Se
integran los componentes y subsistemas. La integracin es parte del desarrollo
en lugar de una actividad separada.
Figura 1.9.- Desarrollo Basado en Componentes.
1.1.4. Metodologa RUP (Rational Unified Process -RUP)

RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un
software que define claramente quien, cmo, cundo y qu debe hacerse en el
proyecto. Presenta tres caractersticas esenciales:
Dirigido por Casos de Uso: Orientan el proyecto a la importancia para el

usuario y lo que ste quiere.
Centrado en la arquitectura: Relaciona la toma de decisiones que indican cmo
tiene que ser construido el sistema y en qu orden.
Iterativo e incremental: Divide el proyecto en mini proyectos donde los casos
de uso y la arquitectura cumplen sus objetivos de manera ms depurada.
Como filosofa RUP maneja seis principios clave:
Adaptacin del proceso. El proceso deber adaptarse a las caractersticas

propias de la organizacin. El tamao del mismo, as como las regulaciones que
lo condicionen, influirn en su diseo especfico. Tambin se deber tener en
cuenta el alcance del proyecto.
Balancear prioridades. Los requisitos de los diversos inversores pueden ser
diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un
balance que satisfaga los deseos de todos.
CIBERTEC
17
Colaboracin entre equipos. El desarrollo de software no lo hace una nica

persona sino mltiples equipos. Debe haber una comunicacin fluida para
coordinar requisitos, desarrollo, evaluaciones, planes, resultados, etc.
Demostrar valor iterativamente. Los proyectos se entregan, aunque sea de un
modo interno, en etapas iteradas. En cada iteracin se analiza la opinin de los
inversores, la estabilidad y calidad del producto, y se refina la direccin del
proyecto as como tambin los riesgos involucrados.
Elevar el nivel de abstraccin. Este principio dominante motiva el uso de
conceptos reutilizables tales como patrn del software, lenguajes 4GL o
esquemas (frameworks) por nombrar algunos. stos se pueden acompaar por
las representaciones visuales de la arquitectura, por ejemplo con UML.
Enfocarse en la calidad. El control de calidad no debe realizarse al final de
cada iteracin, sino en todos los aspectos de la produccin.
1.1.5. Mejores Prcticas de RUP

Por otro lado, RUP describe cmo aplicar efectivamente enfoques comprobados
comercialmente para el desarrollo de software. Estos enfoques son llamados "mejores
prcticas" pues son utilizados en la industria por organizaciones exitosas.
Desarrollo Iterativo
Administracin
de Requisitos
Modelamiento
Visual
Verificacin
Continua de la
Calidad
Control de Cambios
Figura 1.10.- RUP Mejores prcticas.
Desarrollo Iterativo
En funcin de la cada vez mayor complejidad solicitada para los sistemas de software,
ya no es posible trabajar secuencialmente, es decir, definir primero el problema
completo, luego disear toda la solucin, construir el software y finalmente, testear el
producto. Es necesario un enfoque iterativo, que permita una comprensin creciente
del problema a travs de refinamientos sucesivos, llegando a una solucin efectiva
luego
de
mltiples
iteraciones
acotadas
en
complejidad.
RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos mediante la
produccin de releases ejecutables progresivos y frecuentes que permiten la opinin e
involucramiento del usuario.
A travs de las iteraciones que generan releases ejecutables, se logra detectar en
forma temprana los desajustes e inconsistencias entre los requisitos, el diseo, el
desarrollo y la implementacin del sistema, manteniendo al team de desarrollo
focalizado en producir resultados.
Administracin de Requisitos
Los requisitos son las condiciones o capacidades que el sistema debe conformar. La
Administracin de Requisitos es un enfoque sistemtico para hallar, documentar,
organizar y monitorear los requisitos cambiantes de un sistema.
CIBERTEC
18
La Administracin de Requisitos permite:

a)
b)
c)
d)
que las comunicaciones estn basadas en requisitos claramente definidos

que los requisitos puedan ser priorizados, filtrados y monitoreados
que sea posible realizar evaluaciones objetivas de funcionalidad y performance
que las inconsistencias se detecten fcilmente
RUP describe como:

a) Obtener, organizar y documentar la funcionalidad y restricciones requeridas
b) Documentar y monitorear las alternativas y decisiones
Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han demostrado ser
una manera excelente de capturar los requisitos funcionales y asegurarse que dirigen
el diseo, la implementacin y la prueba del sistema, logrando as que el sistema
satisfaga las necesidades del usuario.
Arquitectura basada en Componentes
El proceso de software debe focalizarse en el desarrollo temprano de una arquitectura

robusta ejecutable, antes de comprometer recursos para el desarrollo en gran escala.
RUP describe como disear una arquitectura flexible, que se acomode a los cambios,
comprensible intuitivamente y promueve una ms efectiva reutilizacin de software.
Soporta el desarrollo de software basado en componentes: mdulos no triviales que
completan una funcin clara. RUP provee un enfoque sistemtico para definir una
arquitectura utilizando componentes nuevos y preexistentes.
Modelamiento Visual
RUP muestra como representar el software visualmente para capturar la estructura y

comportamiento de arquitecturas y componentes. Las abstracciones visuales ayudan a
comunicar diferentes aspectos del software; comprender los requisitos, ver como los
elementos del sistema se relacionan entre s, mantener la consistencia entre diseo e
implementacin y promover una comunicacin precisa. El estndar UML (Lenguaje de
Modelado Unificado), creado por Rational Software, es el cimiento para un
modelamiento visual exitosa.
Verificacin continua de la Calidad
Es necesario evaluar la calidad de un sistema respecto de sus requisitos de

funcionalidad, confiabilidad y performance. La actividad fundamental es el testing, que
permite encontrar las fallas antes de la puesta en produccin. RUP asiste en el
planeamiento, diseo, implementacin, ejecucin y evaluacin de todos estos tipos de
testing.
El aseguramiento de la calidad se construye dentro del proceso, en todas las
actividades, involucrando a todos los participantes, utilizando medidas y criterios
objetivos, permitiendo as detectar e identificar los defectos en forma temprana.
Control de Cambios
La capacidad de administrar los cambios es esencial en ambientes en los cuales el

cambio es inevitable. RUP describe como controlar, rastrear y monitorear los cambios
para permitir un desarrollo iterativo exitoso. Es tambin una gua para establecer
espacios de trabajo seguros para cada desarrollador, suministrando el aislamiento de
los cambios hechos en otros espacios de trabajo y controlando los cambios de todos
los elementos de software (modelos, cdigo, documentos, etc.). Describe como
automatizar la integracin y administrar la conformacin de releases.
CIBERTEC
19
1.1.6. Estructura de RUP

RUP es un proceso que puede describirse en dos dimensiones, tal como se muestra
en la figura 1.11, a lo largo de dos ejes:
El eje horizontal representa tiempo y muestra el aspecto dinmico del proceso,

expresado en trminos de ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto esttico del proceso; como est descrito en
trminos de actividades, artefactos, trabajadores o roles y flujos de trabajo.
Figura 1.11.- Estructura de RUP.
1.1.6.1. Fases
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 desarrolla en mayor
o menor proporcin los distintos flujos de trabajo:
Inicio: En esta primera fase se define el alcance y objetivos del proyecto.
Elaboracin: Se desarrolla el plan del proyecto, la especificacin de

caractersticas y la arquitectura base del sistema.
Construccin: Esta fase se concentra en la elaboracin, de un producto

totalmente operativo y eficiente y el manual de usuario.
Transicin: Fase en el cual se instala el producto en el cliente y se entrena a los

usuarios.
CIBERTEC
20
1.1.6.2. Flujos de Trabajo

Los flujos de trabajo son tambin conocidos como disciplinas, consisten en una
secuencia de actividades que producen un resultado observable (artefacto) a cargo de
algn miembro del proyecto (rol).
Figura 1.12.- Elementos de RUP que describen el Flujo de Trabajo.
Existen dos grupos de flujos de trabajo: de proceso y de apoyo. Las que se describirn
a continuacin.
1.1.6.3. Flujos de trabajo del proceso
Orientados al desarrollo del software. Comprende:
Modelado del negocio: Describe la estructura y la dinmica de la organizacin

donde se va a implantar el sistema que construyamos.
Requisitos: Establece exactamente lo que tiene que hacer el sistema, para ello
se extrae los requisitos utilizando diferentes mtodos.
Anlisis y Diseo: Traduce los requisitos a una especificacin que describe

cmo implementar el sistema, creando para ello, diferentes vistas
arquitectnicas.
Implementacin: Tiene en cuenta el desarrollo de software, las pruebas

unitarias y la integracin.
Pruebas: Describe la ejecucin de pruebas y las mtricas para rastreo de

defectos.
Despliegue o Implantacin: Incluye actividades relacionadas con la entrega de

la aplicacin.
1.1.6.4. Flujos de trabajo de apoyo o de soporte

Orientados a la gestin del proyecto. stos son:
Configuracin y Control de cambios: Mantiene la integridad de todos los

artefactos que se crean en el proyecto. Tambin mantiene informacin del
proceso evolutivo que se ha seguido.
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.
Entorno: Cubre la infraestructura necesaria para desarrollar un sistema.
CIBERTEC
21
1.1.6.5. Roles en RUP

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Un miembro del equipo de proyecto
cumple normalmente muchos roles. 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.
Por ejemplo, la figura 1.13 ilustra el rol del arquitecto de software.
Figura 1.13.- Arquitecto de Software.
A continuacin se lista algunos roles especficos dentro de cada rol genrico:

Analistas:
Analista de procesos de negocio.

Diseador del negocio.
Analista de sistema.
Especificador de requisitos.
Desarrolladores:
Arquitecto de software
Diseador
Diseador deinterfaz de usuario
Diseador de cpsulas
Diseador de base de datos
Implementador
Integrador
Gestores:
Jefe deproyecto
Jefe de control de cambios
Jefe de configuracin
Jefede pruebas
Jefe de despliegue
Ingeniero de procesos
Revisor degestin del proyecto
Gestor de pruebas
CIBERTEC
22
Apoyo:
Documentadortcnico
Administrador de sistema
Especialista enherramientas
Desarrollador de cursos
Artistagrfico
Especialista en pruebas:
Especialista en Pruebas(Tester)
Analista de pruebas
Diseador de pruebas
Otros roles:
Stakeholders
Revisor
Coordinacin derevisiones
Revisor tcnico
1.1.7. El modelamiento visual

El Modelado Visual es el modelado de una aplicacin usando notaciones grficas.
Pero, qu tan importante es construir el modelo de una aplicacin? En este sentido
comnmente se hace la comparacin hacia la arquitectura tradicional, en la
construccin de casas. Aun cuando la construccin que se planee hacer sea una casa
sencilla, el resultado ser ms satisfactorio si se cuenta con todo un respaldo en un
correcto diseo.
Booch compara la construccin de software con la construccin de una casa para un
perro, de una casa para una familia y de un gran edificio. En el primer caso no ser tan
evidente la falta de un buen diseo, o al menos nuestro perro no se quejar
demasiado. En el segundo caso, es humanamente posible hacer la construccin de
una casa sin los planos adecuados, pero la casa resultante seguramente tendr varias
carencias, o en el peor de los casos, posiblemente no resistir ciertas condiciones
extremas como un temblor. En el caso del edificio, definitivamente sera un grave error
comenzar la construccin sin los estudios y planos adecuados.
En el caso del software, es curioso como muchos proyectos del tamao de un
rascacielos, son construidos como si se tratara de la casa de un perro. El modelado
visual del software ayuda a capturar las partes esenciales de un sistema:
Se utiliza para capturar los procesos de negocios desde la perspectiva del

usuario.
El Modelado Visual se utiliza para analizar y disear una aplicacin,
distinguiendo entre los dominios del negocio y los dominios de la
computadora.
Ayuda a reducir la complejidad.
El Modelado Visual se realiza de manera independiente al lenguaje de
implementacin.
Promueve la reutilizacin de componentes.
Por otro lado, un modelo se considera como til si presenta las siguientes
caractersticas:
CIBERTEC
23
Preciso: Describen correctamente el sistema a ser construido.

Consistente: Los distintos puntos de vista no expresan cosas que entren en
conflicto entre ellas.
Fcil de comunicrselo a otros. Mejora la comunicacin entre los miembros
del equipo usando un lenguaje grfico.
Fcil de cambiar.
Legible: Todas las representaciones se realizan de la manera ms simple
como sea posible.
1.1.8. El Lenguaje de Modelamiento Unificado

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se
usa para visualizar, especificar, construir y documentar artefactos de un sistema de
software. Captura decisiones y conocimientos sobre los sistemas que se deben
construir. Se usa para entender, disear, configurar, mantener, y controlar la
informacin sobre tales sistemas. El lenguaje de modelado pretende unificar la
experiencia pasada sobre tcnicas de modelado e incorporar las mejores prcticas
actuales en acercamiento estndar. UML incluye conceptos semnticas, notacin y
principios generales. Tiene partes estticas, dinmicas, de entorno y organizativas.
Est pensando para ser utilizado en herramientas interactivas de modelado visual que
tengan generadores de cdigo as como generadores de informes. La especificacin
de UML no define un proceso estndar pero est pensado para ser til en un proceso
de desarrollo iterativo. Pretende dar apoyo a la mayora de los procesos de desarrollo
orientados a objetos.
UML capta la informacin sobre la estructura esttica y el comportamiento dinmico de
un sistema. Un sistema se modela como una coleccin de objetos discretos que
interactan para realizar un trabajo que finalmente beneficia a un usuario externo. La
estructura esttica define los tipos de objetos. El comportamiento dinmico define la
historia de los objetos en el tiempo y la comunicacin entre objetos para cumplir sus
objetivos. El modelar un sistema desde varios puntos de vista, separados pero
relacionados, permite entenderlo para diferentes propsitos.
UML tambin contiene construcciones organizativas para agrupar los modelos en
paquetes, lo que permite a los equipos de software dividir grandes sistemas en piezas
de trabajo, para entender y controlar las dependencias entre paquetes, y para
gestionar las versiones de las unidades de modelo, en un entorno de desarrollo
complejo. Contiene construcciones parea representar decisiones de implantacin y
para elementos de tiempo de ejecucin.
UML no es un lenguaje de programacin. Las herramientas pueden ofrecer
generadores de cdigo de UML para una gran variedad de lenguajes de programacin,
as como construir modelos por ingeniera inversa a partir de programas existentes.
UML no es un lenguaje altamente formal pensando para probar teoremas. Hay varios
lenguajes de ese tipo, pero no son fciles de entender ni de usar para la mayora de
los propsitos. UML es un lenguaje de modelado de propsito general. Para dominios
especializados, tales como la composicin de IUG, diseo de circuitos VLSI, o
inteligencia artificial basada en reglas, podra ser ms apropiada una herramienta
especializada con un lenguaje especial. UML es un lenguaje de modelado discreto. No
se cre para modelar sistemas continuos como los basados en ingeniera y fsica.
UML quiere ser un lenguaje de modelado universal, de propsito general, para
sistemas discretos, tales como los compuestos por software, firmware o lgica digital.
CIBERTEC
24
1.1.8.1 Breve Historia de UML

Los lenguajes de modelado de objetos aparecieron en la dcada de 1980, llegando a
ser unos 50 a mediados de la dcada de 1990. Unos pocos mtodos empezaron a
ganar importancia, ente ellos: el Mtodo OMT (Object-Modeling Technique) de James
Rumbaugh, que era mejor para el anlisis orientado a objetos, el Mtodo Booch de
Grady Booch, el cual era mejor para el diseo orientado a objetos, y el Mtodo OOSE
(Object-Oriented Software Engineering) de Ivar Jacobson, que era un mtodo de
ingeniera de software orientado a objetos.
El esfuerzo para la definicin de UML comenz en Octubre de 1994, cuando
Rumbaugh se uni a Booch en Rational Software Corporation (empresa donde
trabajaba Booch). Unificaron sus mtodos de modelado y elaboraron el borrador de la
versin 0.8 de UML. En 1995 Jacobson tambin se incorpor a Rational, incorporando
as OOSE a UML. En 1996 se public la versin 0.9 de UML. Las tres personalidades
que dieron el origen a UML son conocidas como los Tres Amigos.
Las organizaciones que contribuyeron a la definicin de 1.0 de UML fueron Digital
Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing,
MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. El
borrador de la especificacin UML 1.0 se ofreci para su estandarizacin al OMG en
enero de 1997.
Luego de varios aos y varias modificaciones, OMG adopt la versin oficial de UML
2.0 a principios del ao 2005, versin que integra varios esfuerzos para la
definicin de una semntica de la especificacin ms slida. UML es evolutivo,
actualmente va por la versin 2.4.1. la cual fue liberada en Agosto 2011. UML 2.5 fue
lanzado en octubre de 2012 como una versin "En proceso" y todava tiene que ser
formalmente liberada.
Los documentos de las especificaciones de UML se encuentran en la pgina web de
OMG (Object Management Group). En la siguiente figura se muestra las versiones,
fechas de lanzamiento y URL donde se podr consultar las especificaciones de UML.
Versiones de UML lanzado formalmente por OMG

Versin
2.4.1
2.4
2.3
2.2
2.1.2
2.1.1
2.0
1.5
1.4
1.3
Fecha del lanzamiento

Agosto 2011
Marzo 2011
Mayo 2010
Febrero 2009
Noviembre 2007
Agosto 2007
Julio 2005
Marzo 2003
Setiembre 2001
Marzo 2000
URL
http://www.omg.org/spec/UML/2.4.1
http://www.omg.org/spec/UML/2.4
Versin en proceso de UML

Versin
Fecha del lanzamiento
2.5
October 2012
URL
Figura 1.14.- Lanzamiento de versiones de UML.
CIBERTEC
25
Qu es la OMG?
La OMG (Object Management Group) es una asociacin sin fines de lucro formada por
grandes corporaciones, muchas de ellas de la industria del software, como por
ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard. Esta
asociacin se encarga de la definicin y mantenimiento de estndares para
aplicaciones de la industria de la computacin. Otro de los estndares definidos por la
OMG, adems del UML, es CORBA, el cual permite interoperabilidad multiplataforma a
nivel de objetos de negocio.
1.1.8.2 Objetivos de UML
Los objetivos de UML son muchos, pero se pueden sintetizar en las siguientes:
Visualizar: UML permite expresar de una forma grfica un sistema de forma que
otro lo puede entender.
Especificar: UML permite especificar cules son las caractersticas de un sistema
antes de su construccin.
Construir: A partir de los modelos especificados se pueden construir los sistemas
diseados.
Documentar: Los propios elementos grficos sirven como documentacin del
sistema desarrollado que pueden servir para su futura revisin.
1.1.8.3 Especificaciones fundamentales de UML 2.0

En las versiones previas del UML, se haca un fuerte hincapi en que UML no era un
lenguaje de programacin. Un modelo creado mediante UML no poda ejecutarse. En
el UML 2.0, esta asuncin cambi de manera drstica y se modific el lenguaje, de
manera tal que permitiera capturar mucho ms comportamiento (Behavior). De esta
forma, se permiti la creacin de herramientas que soporten la automatizacin y
generacin de cdigo ejecutable, a partir de modelos UML.
Para lograr los objetivos de UML enunciados en el punto anterior, varios aspectos del
lenguaje fueron reestructurados y/o modificados. La especificacin se separ en
cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la siguiente
figura.
Figura 1.15.- Especificaciones principales de UML 2.0.
Es interesante destacar que el UML 2.0 puede definirse a s mismo. Es decir, su

estructura y organizacin es modelable utilizando el propio UML 2.0; de esta manera,
CIBERTEC
26
se da un ejemplo de utilizacin del UML en un dominio distinto al del desarrollo de

software. En este caso, cada paquete del diagrama representa cada una de las cuatro
especificaciones que componen el lenguaje.
Veamos a continuacin cada una de las principales especificaciones que componen
UML 2.0.
1.1.8.4 Supraestructura
La superestructura del UML es la definicin formal de los elementos del UML Es
aqu donde se definen los diagramas y los elementos que los componen. Esta
definicin sola contiene ms de 640 pginas. La superestructura es utilizada por los
desarrolladores de aplicacin. Es aquella sobre la que hablan los libros y la que la
mayora conoce de versiones anteriores del UML.
Se encuentra dividida en niveles. Estos niveles se conocen como:
Bsico (L1): Contiene los elementos bsicos del UML 2.0, entre ellos: Diagramas
de clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas
de Casos de Uso
Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado,
Perfiles, Diagramas de Componentes y Diagramas de despliegue.
Completo (L3): Representa la especificacin del UML 2.0 completa, como por
ejemplo: las Acciones, Caractersticas avanzadas y PowerTypes, entre otros.
Es importante destacar que basta con que una herramienta implemente el nivel de
conformidad Bsico (L1), para que se considere UML 2.0 compatible. Por eso, es
normal ver una disparidad de caractersticas (features) bastante amplia entre dos
herramientas distintas, aunque stas sean UML 2.0 compatibles.
1.1.8.5 Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de ms bajo nivel.
La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se
modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios
finales del UML; pero provee la piedra fundamental sobre la cual la
Superestructura es definida. La Infraestructura brinda tambin varios mecanismos
de extensin, que hacen del UML un lenguaje configurable. Para los usuarios
normales del UML basta con saber si la infraestructura existe y cules son sus
objetivos.
1.1.8.6 OCL
OCL son siglas en ingls que significan: Object Constraint Language y que en
castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define
un lenguaje simple, para escribir restricciones y expresiones sobre elementos
de un modelo. El OCL suele ser til cuando se est especificando un dominio
particular mediante el UML y es necesario restringir los valores permitidos para los
objetos del dominio. El OCL brinda la posibilidad de definir invariantes, precondiciones,
poscondiciones y restricciones en los elementos de un diagrama. Fue incorporado a
UML en la versin 1.1. Originalmente, fue especificado por IBM y es un ejemplo ms
de las muchas herramientas agregadas a UML.
CIBERTEC
27
1.1.8.7 Intercambio de Diagramas

La especificacin para el intercambio de diagramas fue escrita para facilitar una
manera de compartir modelos, realizados mediante UML, entre diferentes
herramientas de modelado.
En versiones anteriores del UML, se utilizaba un Schema XML para capturar los
elementos utilizados en el diagrama; pero este Schema no deca nada acerca de la
manera en que el modelo deba graficarse. Para solucionar este problema, la nueva
especificacin para el intercambio de diagramas fue desarrollada utilizando un nuevo
Schema XML, que permite construir una representacin SVG (Scalable Vector
Graphics).
Esta especificacin es denominada con las siglas XMI, que en ingls significa: XML
Metadata Interchange; y en castellano se traduce como: XML de Intercambio de
Metadata (datos que representan datos). Tpicamente esta especificacin es
solamente utilizada por quienes desarrollan herramientas de modelado UML.
1.1.9. Diagramas UML 2.0

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera
concreta, es til categorizarlos jerrquicamente, como se muestra en la figura 1.16.
Los Diagramas de Estructura enfatizan en los elementos que deben existir en el
sistema modelado:
Diagrama de clases
Diagrama de componentes
Diagrama de objetos
Diagrama de estructura compuesta (A partir de UML 2.0)
Diagrama de despliegue
Diagrama de paquetes
Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema
modelado:
Diagrama de actividades
Diagrama de casos de uso
Diagrama de mquina de estados
Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que
enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado:
Diagrama de secuencia
Diagrama de comunicacin
Diagrama de tiempos (A partir de UML 2.0)
Diagrama de descripcin de la interaccin (A partir de UML 2.0)
CIBERTEC
Figura 1.16.- Jerarqua de los Diagramas UML 2.0.
1.1.9.1 Diagrama de clases

Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de
un sistema mostrando sus clases, atributos, operaciones y las relaciones entre ellos.
Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los
sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el
sistema, y los componentes que se encargaran del funcionamiento y la relacin entre
uno y otro.
Figura 1.17.- Diagrama de Clases de Anlisis.
Figura 1.18.- Diagrama de Clases de Diseo.
1.1.9.2. Diagrama de componentes

Un diagrama de componentes muestra las organizaciones y dependencias lgicas
entre componentes software (cdigo fuente, binarios o ejecutables). Desde el punto de
vista del diagrama de componentes, se tiene en consideracin los requisitos
relacionados con la facilidad de desarrollo, la gestin del software, la reutilizacin, y las
restricciones impuestas por los lenguajes de programacin y las herramientas
utilizadas en el desarrollo.
Los elementos de modelado dentro de un diagrama de componentes sern
componentes y paquetes. En cuanto a los componentes, slo aparecen tipos de
componentes, ya que las instancias especficas de cada tipo se encuentran en el
diagrama de despliegue.
30
Figura 1.19.- Diagrama de Componentes.
1.1.9.3. Diagrama de objetos

Se puede considerar un caso especial de un diagrama de clases en el que se
muestran instancias especficas de clases (objetos) en un momento particular del
sistema. Utilizan un subconjunto de los elementos de un diagrama de clase. Los
diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notacin es
similar a los diagramas de clase.
Figura 1.20.- Diagrama de Objetos.
1.1.9.4 Diagrama de estructura compuesta

Este tipo de diagrama fue especficamente diseado para la representacin de
patrones de diseo, y es una de las modificaciones de mayor impacto dentro de UML
2.0. Esta modificacin al UML hace que ahora todos los Clasificadores puedan tener
una estructura compuesta. Mediante una composicin de estructuras, el
comportamiento de las instancias de otros Clasificadores (estructura interna)
contenidos en un Clasificador determinado, puede especificarse como Colaboraciones.
Los conceptos principales para describir la estructura interna son: Partes, Puertos y
Conectores.
Figura 1.21.- Diagrama de Estructura Compuesta.
CIBERTEC
31
1.1.9.5 Diagrama de despliegue

Describen la configuracin del entorno de mquinas y redes sobre el que se
distribuyen componentes y procesos del sistema.
Figura 1.22.- Diagrama de Despliegue.
1.9.1.6 Diagrama de actividades

Muestra un flujo ordenado de actividades. Los diagramas de actividades tienen un
amplio nmero de usos, desde definir un flujo de programa bsico, hasta capturar los
puntos de decisin y acciones dentro de cualquier proceso generalizado.
Figura 1.23.- Diagrama de Actividades .
CIBERTEC
32
1.1.9.7 Diagrama de paquetes

Este tipo de diagrama se usa para dividir el modelo en contenedores lgicos
(paquetes) y describen las interacciones entre ellos a un nivel ms alto. Los paquetes
ofrecen
un
mecanismo
general
para
la
organizacin
de
los
modelos/subsistemas/capas agrupando elementos de modelado. Cada paquete se
corresponde a un submodelo (subsistema) del modelo (sistema); se pueden anidar
paquetes. Por ltimo, puede crearse relaciones de dependencia, esto se da cuando un
componente de un paquete necesita un componente de otro paquete.
Figura 1.24.- Diagrama de Paquetes.
1.1.9.8 Diagrama de casos de uso

Este Diagrama permite realizar la especificacin del alcance funcional del producto
software que se construye y de los actores, entes que interactan con el producto
software. Son usados para representar los procesos de negocio de la organizacin
objetivo y las funcionalidades que representan la arquitectura del sistema por cada
proceso de negocio.
Figura 1.25.- Diagrama de Casos de Uso del Negocio.
Figura 1.26.- Diagrama de Casos de Uso.
CIBERTEC
33
1.1.9.9 Diagrama de mquina de estados

Tpicamente este diagrama se utiliza para representar todos los posibles estados que
los objetos de una clase puedan tener. Los diagramas de estado no se hacen para
todas las clases, es slo para aquellas clases que tengan un nmero de estados bien
definidos y en donde el comportamiento de la clase es afectado y cambiado por los
distintos estados.
Figura 1.27.- Diagrama de Mquina de Estados.
1.1.9.10 Diagrama de secuencia

Muestra una secuencia de mensajes pasadas entre los objetos usando una lnea de
tiempo vertical.
Figura 1.28.- Diagrama de Secuencia.
CIBERTEC
34
1.1.9.11 Diagrama de comunicacin

Antes era conocida como diagrama de colaboracin. Muestra la red y la secuencia de
mensajes de comunicaciones entre objetos en tiempo de ejecucin durante una
instancia de colaboracin.
Figura 1.29.- Diagrama de Comunicacin.
1.1.9.12 Diagrama de tiempo

Fusionan los diagramas de secuencia y estados para proveer una vista de un estado
del objeto dentro de una escala de tiempo y los mensajes que modifican ese estado.
til para sistemas de tiempo real, de control automtico, etc.
Figura 1.30.- Diagrama de Tiempo.
CIBERTEC
35
El propsito primario de los diagramas de tiempos (o temporizados) es mostrar los

cambios en el estado, o la condicin, de una lnea de vida de una instancia (de un
Clasificador o un Rol de un clasificador), a lo largo del tiempo y de manera lineal. El
uso ms comn es mostrar el cambio de estado de un objeto a lo largo del tiempo, en
respuesta a los eventos o estmulos aceptados. Un diagrama de tiempos se ve tal y
como lo muestra la figura 1.30. No resulta trivial leer un diagrama de tiempos; si no se
lo conoce, puede resultar poco intuitivo.
1.1.9.13 Diagrama de descripcin de la interaccin
Es un diagrama que muestra cmo interactan varios diagramas de interacciones (por
ejemplo, de secuencias). Este tipo de diagramas es muy til para mostrar de qu
manera distintos escenarios se combinan. En el ejemplo de la figura 2.18, se muestra
la interaccin de un cliente con un cajero ATM, separado en cuatro fragmentos:
Secuencia de login: la cual pedir un usuario y una clave a un cliente. (la

secuencia supone que la clave y usuario ingresados son vlidos).
Secuencia de seleccionar una operacin. Las operaciones permitidas por este
cajero son cancelar o extraer dinero.
Si cancela, se ejecutar la secuencia de deslogueo del cliente. Luego finalizar
la operatoria.
Figura 1.31.- Diagrama de Descripcin de la Interaccin.
CIBERTEC
36
1.2 TEMA 2: HERRAMIENTAS C.A.S.E.

Las herramientas CASE (Computer Aided Software Engineering) son diversas
aplicaciones informticas destinadas a aumentar la productividad en el desarrollo de
software y reduce el costo de las mismas en trminos de tiempo y de dinero. Estas
herramientas nos pueden ayudar en todos los aspectos del ciclo de vida de desarrollo
del software en tareas como el proceso de realizar un diseo del proyecto, clculo de
costos, implementacin de parte del cdigo automticamente con el diseo dado,
compilacin automtica, documentacin o deteccin de errores entre otras.
1.2.1 Objetivos de las herramientas C.A.S.E.
Mejorar la productividad en el desarrollo y mantenimiento del software

Aumentar la calidad del software
Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas
informticos
Mejorar la planificacin de un proyecto
Aumentar la biblioteca de conocimiento informtico de una empresa ayudando a
la bsqueda de soluciones para los requisitos
Automatizar desarrollo del software, documentacin, generacin de cdigo,
pruebas de errores y gestin del proyecto
Ayudar a la reutilizacin del software, portabilidad y estandarizacin de la
documentacin
Gestin global en todas las fases de desarrollo de software con una misma
herramienta
Facilitar el uso de las distintas metodologas propias de la ingeniera del
software.
1.2.2. Tipos de herramientas C.A.S.E.

La siguiente clasificacin es la ms habitual basada en las fases del ciclo de desarrollo
que cubren:
Upper CASE (U-CASE), herramientas que ayudan en las fases de planificacin,

anlisis de requisitos y estrategia del desarrollo, usando, entre otros, diagramas
UML.
Middle CASE (M-CASE), herramientas para automatizar tareas en el anlisis y
diseo de la aplicacin.
Lower CASE (L-CASE), herramientas que semiautomatizan la generacin de
cdigo, crean programas de deteccin de errores, soportan la depuracin de
programas y pruebas. Adems automatizan la documentacin completa de la
aplicacin. Aqu pueden incluirse las herramientas de Desarrollo rpido de
aplicaciones.
Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo de software, desde anlisis hasta implementacin.
1.2.3. Ejemplos de herramientas C.A.S.E.

A continuacin, se muestran productos que soportan UML 2.0.
CIBERTEC
37
Figura 1.32. Paradigma visual.
Figura 1.33. Enterprise Architect.
CIBERTEC
38
Figura 1.34. Rational Software Modeler.
Figura 1.35. Rational Software Architect.
CIBERTEC
39
1.2.4. RATIONAL SOFTWARE ARCHITECT (RSA)

Es una herramienta de diseo y construccin para arquitectos de software y
desarrolladores snior para crear aplicaciones en la plataforma Java o en C++.
Permite un desarrollo basado en modelos con el lenguaje UML (Unified Modeling
Language) y unifica todos los aspectos de la arquitectura de la aplicacin de software.
Dentro de un equipo de desarrollo, los arquitectos de software y los desarrolladores
snior son los responsables de especificar y mantener todos los aspectos de la
arquitectura de una aplicacin. Para manejar las aplicaciones actualmente, se
necesitan herramientas potentes y de fcil configuracin. IBM Rational Software
Architect es una herramienta integrada de diseo y desarrollo que proporciona un
desarrollo basado en modelos con UML (Unified Modeling Language) para crear
aplicaciones y servicios con una buena arquitectura. Rational Software Architect
unifica todos los aspectos del diseo y desarrollo de software en una nica
herramienta fcil y potente. Incluye una funcionalidad completa con Rational
Application Developer for WebSphere Software y est construido sobre la base de la
plataforma abierta y extensible Eclipse, que incluye multitud de estndares abiertos.
Esto permite a los usuarios crear aplicaciones optimizadas para el middleware de IBM,
as como para aquellas desarrolladas utilizando tecnologa middleware de otras
compaas.
La versin actual del Rational Software Architect es 8.0.1 la cual trae una mejora en
cuanto a creacin de modelos y diagramas se refiere.
CIBERTEC
40
UNIDAD
2
DISCIPLINA DEL
DEL NEGOCIO
MODELADO

Al trmino de la unidad, el alumno sustentar el primer avance de su proyecto,
acerca del Modelado de negocio de la empresa en estudio, el cual est
conformado por el Modelo de casos de uso del negocio, en el que identificar
los objetivos, casos de uso y actores del negocio, y realizar el diagrama
general de casos de uso del negocio, mientras que para el Modelo de anlisis
del negocio, a los trabajadores y entidades, y realizar los diagramas de clases
y de actividades del negocio.
TEMARIO
2.1 Tema 3
2.1.1.
2.1.2.
2.1.3.
2.2 Tema 4
2.2.1.
2.2.2.
2.2.3.
2.2.4.
2.3 Tema 5
2.3.1.
2.3.2.
:
:
:
:
:
:
:
:
:
:
:
:
Modelado del Negocio

Cundo ser necesario hacer el Modelado de Negocio?
Cundo no ser necesario hacer el Modelado de Negocio?
Actividades para realizar un Modelado de Negocio
Modelo de Casos de uso del Negocio
Determinar la situacin de la organizacin
Identificar los procesos de negocio
Refinar las definiciones de los procesos de negocio
Artefactos del Modelo de Casos de uso del negocio
Modelo de Anlisis de Negocio
Disear las realizaciones de los procesos de negocio
Artefactos del Modelo de Anlisis dl negocio
Los alumnos desarrollan el Modelo de casos de uso del negocio de un proceso

de negocio.
Los alumnos desarrollan el Modelo de anlisis del negocio de un proceso de
negocio.
CIBERTEC
41
2.1 TEMA 3: MODELADO DEL NEGOCIO

La necesidad de esta disciplina surge ante el hecho de que muchos de los productos
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 en el
dominio del software.
As, los objetivos de esta disciplina son los siguientes:
Entender los problemas actuales en la organizacin objetivo para identificar los
aspectos a mejorar.
Estudiar el impacto que pueden producir los cambios a nivel organizativo.
Asegurar que los clientes, usuarios finales, desarrolladores y otros involucrados
tienen una visin comn de la organizacin considerada.
Obtener los requisitos del sistema software que den soporte a la organizacin
objetivo.
Entender como el sistema software encaja en la organizacin.
Por consiguiente, el Modelo del Negocio proporciona una vista esttica de la estructura
de la organizacin y una vista dinmica de los procesos dentro de la organizacin.
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 modelo de casos de uso de 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. Por otro
lado, el modelo de anlisis del negocio, es un modelo interno a un negocio, que
describe cmo cada caso de uso de negocio es llevado a cabo por un grupo de
trabajadores que utilizan entidades del negocio.
El conjunto completo de artefactos del modelo de negocio, mostrado en la figura 2.1,
captura y presenta el contexto del sistema y sirven como entrada y referencia para la
definicin de los requisitos del sistema.
2.1.1 Cundo ser necesario hacer el Modelado 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 planificando un proceso de reingeniera de
negocios.
Cuando el software a construir ser utilizado por una porcin importante de la
organizacin.
Existen flujos de trabajo complejos dentro de la organizacin que no estn
documentados.
Cuando se es un consultor en una organizacin en la cul no se ha trabajado
antes.
CIBERTEC
42
Figura 2.1.- Artefactos del Modelado de Negocio.
2.1.2 Cundo no ser necesario hacer el Modelado de Negocio?
Cuando se tiene un 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 flujos 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 de negocio.
2.1.3 Actividades para realizar un Modelado de Negocio

Segn RUP, el Modelado de Negocio comprende las siguientes actividades: (Ver figura 2.2)
Describir el actual negocio
Refinar roles y responsabilidades
Explorar procesos automatizados
Desarrollar un modelado de dominio
En este apartado trataremos la ejecucin de actividades relevantes que permiten
obtener los artefactos principales del Modelo de Negocio.
Los pasos que contemplaremos para obtener el Modelo de casos de uso del negocio
son:
CIBERTEC
43
Por ltimo, la actividad que ejecutaremos para obtener el Modelo de anlisis del
negocio es:
Figura 2.2.- El Modelado de Negocio.
CIBERTEC
44
2.2 TEMA 4: MODELO DE CASOS DE USO DEL NEGOCIO

Define un conjunto de acciones que el negocio lleva a cabo y provee resultados de
valor a quienes interactan con el. Son procesos de negocio descritos bajo un punto
de vista externo que percibe algn tipo de valor.
2.2.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:
a) Identificar la misin y visin de la organizacin y/o reas de estudio que
correspondan y plasmarlo en Visin del Negocio.
b) Identificar 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.
c) Identificar las reglas del negocio y luego plasmarlas en el documento Reglas del
Negocio.
d) Elaborar una lista de trminos y definiciones usados comnmente en un Glosario
del Negocio.
Se ha preferido reunir los documentos anteriormente mencionados en el artefacto
Situacin del Negocio.
2.2.2 Identificar los procesos de negocio

Requiere haber identificado los objetivos del negocio. El equipo de trabajo debe tener
claras las fronteras del negocio que est describiendo. Para ello debe identificar 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 de Negocio.
Por cada caso de uso del negocio, se realiza una Especificacin de Caso de Uso del
Negocio, conocido comnmente como BUCS (Business Use Case Specification) 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.
2.2.3 Refinar las definiciones de los procesos de negocio

Consiste en:
a) Detallar la definicin de los casos de uso del negocio.
b) Describir cmo los casos de uso del negocio soportan los objetivos de negocio.
c) Verificar que los casos de uso del negocio representan correctamente cmo el
negocio es conducido.
Aqu se refina la Especificacin de Caso de Uso del Negocio, describiendo paso a
paso las actividades que se desarrollan en el proceso de negocio.
CIBERTEC
45
2.2.4 .Artefactos del Modelo de Casos de uso del negocio

Artefacto
Descripcin
Documento que contiene la visin del negocio, un
glosario de trminos del negocio, los objetivos del
negocio y reglas del negocio.
Situacin del Negocio
Business Goal
Business Use Case
Es un requisito que debe ser satisfecho por el negocio.

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.
Se permite la relacin de dependencia entre objetivos del
negocio y la de soporte de un caso de uso del negocio.
Define un conjunto de acciones que el negocio lleva a
cabo y provee resultados de valor a quienes interactan
con el.
Describe un proceso de negocio desde un punto de vista
externo que percibe algn tipo de valor.
Definen los lmites de la organizacin.
Representa un rol que algo o alguien externo desempea
en relacin con el negocio.
Puede ser asociado a uno ms casos de uso del
negocio.
Business Actor
Representa la vista externa del negocio.

Es un modelo que describe la direccin e intencin del
negocio. La direccin es provista por los objetivos del
negocio. Mientras que la intencin es expresada por los
diagramas que permiten ver cmo interactuar con el
entorno.
Business Use Case Model
Reporte que contiene informacin de los actores del

negocio identificados en el modelo de casos de uso del
negocio.
Business Actor
Documento que contiene las caractersticas de un

proceso de negocio. Se realiza una especificacin por
cada caso de uso de negocio.
Business Use-Case
Specification
Reglas de negocio
Es una poltica o condicin que debe ser satisfecha por

el negocio. Ejm:
El pago de planillas se realizar los das 25 de cada
mes y va depsito en cuenta bancaria.
Tabla 2.1.- Artefactos del Modelo de Casos de Uso del Negocio.
CIBERTEC
46
2.3 TEMA 5: MODELO DE ANLISIS DEL NEGOCIO

Es un modelo interno a un negocio. Detalla cmo el proceso es implementado
internamente. Incluye una descripcin de los business workers, las entidades del
negocio que se manipulan y cmo los business workers manipulan estas entidades
para llevar a cabo el proceso del negocio mediante diagramas de interaccin.
2.3.1 Disear las realizaciones de los procesos de negocio

Consiste en identificar 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 especificar, 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 finalizar esta actividad, se completar cada Especificacin de Caso de Uso del
Negocio generado en el modelo de casos de uso de negocio, agregando al final de
cada documento, los diagramas de clases y actividades correspondientes.
2.3.2. Artefactos del Modelo de Anlisis dl negocio

Artefacto
Business Worker
Descripcin
Un trabajador del negocio es un rol interno al
negocio. Colabora con trabajadores de otro
sector, es notificado de acontecimientos del
negocio y manipula entidades de negocio para
realizar sus responsabilidades.
Ente significativo y persistente manipulado por
actores del negocio y trabajadores del negocio.
Business Entity
Business Use Case

Realization
Coleccin de diagramas que muestra cmo los

trabajadores del negocio y entidades del negocio
llevan a cabo el caso de uso del negocio.
Generalmente se utilizan Diagramas de Clases,
Diagramas de Actividades y Diagramas de
Colaboracin para realizar el detalle de cada
proceso de negocio.
CIBERTEC
47
Representa la vista interna del negocio.

Es un modelo que describe la realizacin de los
casos de uso del negocio. Es una abstraccin de
cmo los trabajadores del negocio y las entidades
de negocio se relacionan y de cmo colaboran
para realizar los casos del uso del negocio.
Business Analysis
Model
Reporte que contiene informacin de los

trabajadores del negocio identificados en el
modelo de anlisis del negocio.
Business Worker
Reporte que contiene informacin de las

entidades del negocio identificadas en el modelo
de anlisis del negocio.
Business Entity
Tabla 2.2.- Artefactos del Modelo de Anlisis del Negocio.
CIBERTEC
48
CASO DE ESTUDIO N1: ELCTRICA S.A.

Elctrica es una empresa dedicada a la venta de artculos electrodomsticos. Esta
empresa cuenta con diferentes puntos de venta. Cada punto de venta cuenta con
cajeros, vendedores y su propio almacn.
Un da X en Elctrica comienza cuando un cliente solicita al vendedor un producto que

se encuentra en vitrina. El vendedor verifica el stock de ese producto y si hay stock, le
muestra e informa de las caractersticas de ese producto. Si el cliente est de acuerdo
con el producto ofrecido, el vendedor le generar un ticket de pedido indicndole el
cdigo del producto y el precio.
El cliente se dirige a caja y el cajero le solicita el ticket de pedido para que le genere el
comprobante de pago. El cajero le pregunta al cliente la forma de pago, efectivo o
tarjeta, si el cliente informa que pagara en efectivo le solicita el dinero y genera el
comprobante de pago, si el cliente informa que es tarjeta, el cajero le solicitara la
tarjeta (Crdito o dbito) y su DNI para pasar la tarjeta por el terminal de POS y
generar el Boucher, luego de ello le genera el comprobante de pago al cliente.
Ya con el comprobante el cliente se dirige al vendedor para que le haga entrega del
producto.
GLOSARIO
Las tarjetas de dbito pueden utilizarse para disponer de efectivo en las sucursales
bancarias y cajeros automticos, consultar el saldo y los movimientos de la cuenta
asociada.
En el caso de la tarjeta de crdito, el monto a pagar oscila entre un mnimo y el total

gastado, pero la parte de deuda no saldada implica un inters que el titular deber
abonar en sus pagos siguientes.
Objetivos del negocio:
Agilizar la atencin al cliente en un 5% con respecto al ao 2013..
Conocer el progreso de las ventas mensuales.
El Flujo de trabajo para el proceso Venta de Electrodomsticos se muestra a

continuacin:
CIBERTEC
49
Flujo Trabajo
Flujo Bsico
1. El cliente solicita el electrodomstico que se encuentra en vitrina.
2. El vendedor verifica existencia del electrodomstico.
3. Si existe, el vendedor muestra el electrodomstico al cliente.
4. El cliente evala el electrodomstico.
5. Si est de acuerdo con el electrodomstico ofrecido, el vendedor genera el
ticket de pedido.
6. El vendedor emite el ticket de pedido al cliente.
7. El cliente entrega el ticket de pedido al cajero
8. El cajero pregunta forma de pago Efectivo o tarjeta
9. Si el cliente responde efectivo ,entrega el dinero
10. El cajero genera el comprobante de pago.
11. El cajero emite el comprobante de pago al cliente.
12. El cliente entrega la copia del comprobante al vendedor.
13. El vendedor sella el comprobante y entrega el electrodomstico.
14. El cliente recibe el electrodomstico y finaliza el proceso.
Flujos alternativos
.En el punto 3, si no hay stock disponible, el vendedor le ofrece un electrodomstico
sustituto al cliente y contina con el paso 4.
1. En el punto 5, si no est de acuerdo con el electrodomstico ofrecido, termina
el proceso.
2. En el punto 9, el cliente puede pagar con tarjeta crdito o dbito:
a.
b.
c.
d.
e.
Si el cliente responde pago con tarjeta

El cajero solicita la tarjeta al usuario.
El cliente entrega tarjeta y DNI.
El cajero pasa la tarjeta por el terminal POS.
Si es con tarjeta de crdito:
i. El terminal de POS genera el Boucher.
ii. El Servicio de Banca actualiza la cuenta de la empresa.
iii. El cajero entrega el Boucher para su firma.
iv. El cliente firma el Boucher.
f. Si es con tarjeta de dbito:
i. El cliente ingresa su clave secreta en el terminal POS
ii. El terminal de POS genera el Boucher.
iii. El Servicio de Banca actualiza la cuenta del cliente.
g. El cajero genera el CDP, entrega el CDP y el Boucher al cliente.
h. El caso de uso contina en el paso 12.
CIBERTEC
50
Solucin de caso propuesto

1. Estructura de proyecto Modelo de casos de uso del negocio.
2. Casos de uso del negocio
3. Objetivos del negoci
4. Diagrama de Casos de Uso del Negocio Vs. Objetivos del Negocio
CIBERTEC
51
5. Actores de negocio
6. Creacin del Diagrama general de casos de uso del negocio.
7. Estructura del Modelo de anlisis del negocio
CIBERTEC
52
8. Trabajadores del negocio
9. Entidades del negocio
10. Diagrama de clases de negocio
CIBERTEC
53
11. descripcin de los elementos de un diagrama de actividades.

Artefacto
Descripcin
Particin asignada para cada rol.
Nodo inicial que indica el inicio del
Diagrama de Actividades.
Define una accin de la actividad.
Es conveniente nombrar las
actividades con verbos en tercera
persona.
Este nodo representa un punto

en una actividad donde un flujo
de entrada se divide en varios
flujos de salida.
Este nodo representa un punto
en una actividad donde varios
flujos
de
entrada
estn
sincronizados en un nico flujo
de salida.
Control de decisin a partir del
cual se especifica una pregunta
que lleva a dos o ms flujos de
acciones.
Almacn de datos que representa
la instancia de una clase
persistente.
Flujo de objeto utilizado para
representar relaciones INPUT y/o
OUTPUT entre una accin e
instancia de entidad de negocio.
Flujo de control utilizado para
representar
relaciones
entre
acciones.
Conector de flujo entre acciones
o acciones y almacn de datos.
Nodo Final que indica finalizacin
de una secuencia de actividades.
Un Diagrama de Actividades
puede tener ms de un tipo de
fin.
CIBERTEC
54
12. Diagrama de actividades
CIBERTEC
55
Desarrolle el siguiente caso propuesto
CASO DE ESTUDIO N2: PANDERO

La empresa Pandero SAC es una prestigiosa empresa dedicada a fondos colectivos,
el fondo colectivo es una modalidad bajo la cual se adquieren bienes, a travs de los
aportes mensuales de un nmero determinado de cuotas a pagar peridicamente por
las personas naturales y se desea automatizar sus procesos esperando ser la
empresa nmero 1 del mercado. Esperan lograrlo a partir de la automatizacin
del
100% de las transacciones y de un control total de las aportaciones..
El principal proceso de la empresa se inicia cuando el cliente se acercan a la tienda a

realizar las consultas sobre el precio de los autos y las cuotas a pagar que se ofrecen,
el Cliente es atendido por un vendedor quien le brinda toda la informacin que
necesita, si el cliente est de acuerdo y acepta las condiciones se genera un
certificado de Pandero por el monto total del auto que desea comprar, el cliente debe
pagar su cuota de inscripcin de $200. Esta cuota puede pagarse en el local con
tarjeta de crdito o dbito.
Mensualmente se realiza el sorteo de los autos y lo inicia el Gerente General que le

informa al asistente de sorteos que selecciona la lista de clientes al da en el pago de
sus cuotas y sortee para obtener un ganador a quien se le entrega un auto. El cliente
ganador debe pagar su cuota de Adjudicacin por $500 y la puede pagar en el local
con tarjeta de crdito o dbito.
Flujo de trabajo del proceso: Realizar Adjudicacin del Pandero
Flujo de Trabajo
Flujo Bsico
1. El Gerente General solicita al asistente iniciar el sorteo
2. El asistente de sorteo genera la lista de clientes al da en sus cuotas.
3. El asistente de sorteo genera un boleto por cada cliente
4. El asistente de sorteo entrega la lista de clientes y los boletos al jefe de
sorteos.
5. El jefe de sorteos ingresa los boletos en un nfora.
6. El jefe de sorteo saca del nfora el boleto ganador y llama al cliente
7. El cliente se acerca con su certificado de Pandero.
CIBERTEC
56
8. El jefe de sorteo verifica los datos del certificado

9. Si los datos son correctos el Jefe de sorteo le emite al cliente una Constancia
de Adjudicacin y le informa que debe de pasar a caja a cancelar la cuota de
Adjudicacin
10. El cliente se acerca a caja
11. El cajero le solicita la Constancia de Adjudicacin y el Certificado de Pandero
12. El cliente entrega la Constancia de Adjudicacin y Certificado de Pandero.
13. El cajero verifica la Constancia de Adjudicacin y el Certificado de Pandero
14. El cajero solicita el pago de la Cuota de Adjudicacin
15. El cliente paga la cuota de Adjudicacin
16. El cajero entrega el comprobante de pago y sella la Constancia
de
Adjudicacin como cancelada

17. El cliente recoge su auto y se retira
1.1. Flujos Alternativos
1. En el punto 9, si los datos del ganador no son conformes
2. El jefe de sorteo saca nuevamente otro boleto y contina en el paso 7.
CIBERTEC
57
Resumen
El Modelado del negocio es una tcnica para comprender los procesos de negocio
de la organizacin objetivo.
El Modelo de casos de Uso del Negocio es un modelo elaborado bajo una
perspectiva externa del negocio.
El Modelo de Anlisis del Negocio detalla cmo el proceso de negocio es
implementado internamente.
Si desea saber ms acerca de estos temas, puede consultar las siguientes
pginas.
http://www-128.ibm.com/developerworks/rational/library/5167.html
Aqu hallar una descripcin de los elementos del modelado de negocio.
CIBERTEC
58
CIBERTEC
59
UNIDAD
3
DISCIPLINA DE LA CAPTURA DE
REQUISITOS
Al trmino de la unidad, los alumnos, trabajando en equipo, elaborarn y sustentarn su
proyecto final sobre el modelado del negocio y la captura de requisitos, en el que
identifica el modelo de casos de uso del negocio, el modelo de anlisis del negocio, y el
modelo de casos de uso con sus respectivos artefactos, aplicando la metodologa RUP,
el lenguaje de modelado UML y la herramienta IBM Rational Software Architect.
TEMARIO
3.1 Tema 6
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
3.1.7.
3.2 Tema 7
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.3 Tema 8
3.3.1.
3,3,2.
3.3.3.
3.3.4.
3.3.5.
: Captura de requisitos
: Artefactos de la Captura de Requisitos
Actividades para realizar la Captura de Requisitos
: Requerimientos
Requisitos FURPS
Tcnicas para capturar requisitos
: Captura de requisitos a solicitud del cliente
: Captura de requisitos a partir del diagrama de actividades del negocio
: Modelo de casos de uso.
: Encontrar actores y casos de uso
Encontrar actores
: Encontrar casos de uso
Crear el Diagrama de casos de uso
: Estructurando el modelo de casos de uso.
: Objetivos
Tipos de relaciones
Casos de uso abstractos y concretos
: Especificaciones de casos de uso
: Priorizacin de los Casos de Uso
Los alumnos clasificarn los requisitos de una lista propuesta segn las categoras
descritas por el modelo FURPS+.
Los alumnos identifican los requisitos funcionales a partir de un Diagrama de
Actividades del Negocio
Los alumnos identifican actores y casos de uso a partir de un caso propuesto.
CIBERTEC
60
3.1 TEMA 6: CAPTURA DE REQUISITOS

El esfuerzo principal en esta disciplina es desarrollar un modelo del sistema que se va
a construir. La utilizacin de los casos de uso es una forma adecuada de crear ese
modelo. Esto es debido a que los requisitos funcionales se estructuran de forma
natural mediante casos de uso.
Los casos de uso proporcionan un medio intuitivo y sistemtico para capturar los
requisitos funcionales con un nfasis especial en el valor aadido para cada usuario
individual o para cada sistema externo.
El modelo de casos de uso es construido a travs de un proceso iterativo durante el
cual las discusiones entre los desarrolladores del sistema y los clientes (y/o usuarios
finales) llevan a una especificacin de requisitos en la que todos estn de acuerdo.
As, los propsitos de la disciplina de Requisitos son:
Establecer y mantener los acuerdos con los clientes y otros interesados

(stakeholders) sobre lo que el sistema debe hacer.
Proporcionar a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
Definir las fronteras del sistema.
Proveer la base para planificar las iteraciones.
Proporcionar la base para estimar los costos y tiempos del desarrollo del
sistema.
Definir las interfaces de usuario con el sistema, enfocado a las necesidades y
objetivos de los usuarios.
3.1.1 Artefactos de la Captura de Requisitos

El conjunto completo de artefactos de la captura de requisitos, mostrado en la figura
3.1, sirven como entrada y referencia para el anlisis, diseo, implementacin y
pruebas del sistema.
Figura 3.1.- Artefactos de la Captura de Requisitos.
CIBERTEC
61
La propuesta del curso, para una solucin de mediana envergadura, es crear los
artefactos proporcionados en la tabla 3.1.
Artefacto
Vision
Software Requirements
Specification
Use-Case Package
Descripcin
Documento que define la opinin de los stakeholders del
producto que se desarrollar, especificada en trminos de
necesidades y caractersticas claves de los stakeholders.
Contiene un esquema de los requisitos previstos, el cual
proporciona la base contractual para los requisitos tcnicos
ms detallados.
La Especificacin de Requisitos de Software es un
documento que enfoca la organizacin completa de los
requisitos del proyecto.
Comnmente conocido como SRS por sus iniciales en
ingls. Contiene la lista de requerimientos funcionales y no
funcionales.
Es una coleccin de casos de uso, de actores, de relaciones,
de diagramas, y de otros paquetes de ser necesario; es
utilizado para estructurar el modelo de casos de uso
dividindolo en piezas ms pequeas.
Es un proceso especfico del sistema con identidad propia, el
cual define una secuencia de acciones que el sistema realiza
para un actor en particular.
Use Case
Representa un rol (humano, hardware o software) externo al

sistema con el que se establece intercambio directo de
informacin.
Puede ser asociado a uno o ms casos de uso.
Actor
Use Case Model
Es un modelo que captura los requisitos funcionales de los

usuarios a un alto nivel y establece la estructura fundamental
del sistema. Es un input esencial para las actividades en
anlisis, diseo y pruebas.
Reporte que contiene informacin de
identificados en el modelo de casos de uso.
los
actores
Actor
Use-Case Specification
Documento que contiene las caractersticas de un caso de

uso. Contiene primordialmente una descripcin del flujo de
eventos que describen la interaccin entre los actores y el
sistema. La especificacin tambin contiene otra informacin
tal como precondiciones, pos condiciones y requisitos
especiales. Se realiza una especificacin por caso de uso.
Tabla 3.1.- Artefactos del Modelo de Casos de Uso.
CIBERTEC
62
3.1.2 Actividades para realizar la Captura de Requisitos

Segn RUP, la Captura de Requisitos comprende las siguientes actividades:
Analizar el problema
Entender las necesidades de stakeholders
Definir el sistema
Administrar el alcance del sistema
Refinar la definicin del sistema
Administrar cambios de requisitos
Figura 3.2.- La Captura de Requisitos.
3.1.2.1 Analizar el Problema

El documento Visin es el principal artefacto en el cual el anlisis del problema es
documentado.
Para determinar el alcance inicial del proyecto, los lmites del sistema deben ser
definidos. El analista de sistema identifica usuarios y sistemas, representado por
actores, los cuales interactan con el sistema. En este caso, el analista crea el Modelo
de Casos de Uso que contendr slo los actores.
CIBERTEC
63
3.1.2.2 Entender las Necesidades del Stakeholder

El artefacto principal es un documento refinado de la Visin. Tambin los requisitos
son discutidos y expresados en trminos de Casos de Uso y Actores. Los requisitos no
funcionales, que no son representados en el Modelo de Casos de Uso debern ser
documentados en Especificaciones Suplementarias.
El analista se relaciona con los stakeholders utilizando tcnicas para capturar
requisitos, tales como las entrevistas si se encuentra en las primeras iteraciones de
esta disciplina y prototipos si se encuentra en las ltimas iteraciones.
Los stakeholders son un grupo de inters cuyas necesidades deben ser satisfechas
por el proyecto. El papel puede ser desempeado por cualquier persona que es (o
ser potencialmente) afectado por los resultados del proyecto. Por lo tanto, son
fuentes de requisitos. Por ejemplo: usuarios finales del sistema, gerentes, accionistas,
reguladores quines certifican la aceptabilidad del sistema.
3.1.2.3 Definir el Sistema
En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso
completamente para obtener un Modelo de Casos de Uso refinado y expandir los
requisitos no funcionales definidos en los documentos de especificaciones
suplementarias.
3.1.2.4 Administrar el Alcance del Sistema
El alcance del proyecto es definido por el conjunto de requisitos definidos para ste. La
clave para manejar un proyecto exitoso es administrar el alcance del proyecto
cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. La
priorizacin los casos de uso, desarrollado por el arquitecto de software, permite
planificar el proyecto.
3.1.2.5 Refinar la Definicin del Sistema
El output de este Workflow del RUP es una comprensin ms profunda de la
funcionalidad del sistema expresada en Casos de Uso detallados y documentos de
Especificaciones Suplementarias detallados. Si es necesario, una Especificacin de
Requisitos de Software formal puede ser desarrollada, adems de los documentos
detallados de Casos de Uso y Especificaciones Suplementarias.
3.1.2.6 Administrar los Cambios de Requisitos
Los cambios a los requisitos impactan los modelos producidos en el Workflow de
Anlisis y Diseo, el modelo de pruebas creado en el Workflow de Pruebas y el
material de soporte al usuario final del Workflow de Despliegue. Las relaciones de
trazabilidad son establecidas para identificar las relaciones entre los requisitos y otros
artefactos. Las relaciones de trazabilidad son la clave para entender el impacto del
cambio de los requisitos.
3.1.3. Requerimientos
Un requerimiento se define como una condicin o capacidad a la que debe ajustarse el
sistema que se construye para satisfacer un contrato, norma, especificacin u otro
documento formalmente impuesto.
CIBERTEC
64
El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para
un sistema es llamado ingeniera de requisitos. La meta de la ingeniera de requisitos
(IR) es entregar una especificacin de requisitos de software correcta y completa.
Algunos otros conceptos de ingeniera de requisitos son:
Segn Pressman Ingeniera de Requisitos ayuda a los ingenieros de software a
entender mejor el problema en cuya solucin trabajarn. Incluye el conjunto de tareas
que conducen a comprender cul ser el impacto del software sobre el negocio, qu
es lo que el cliente quiere y cmo interactuarn los usuarios finales con el software.
Por otro lado, Somerville define que La ingeniera de requisitos es el proceso de
desarrollar una especificacin de software. Las especificaciones pretenden comunicar
las necesidades del sistema del cliente a los desarrolladores del sistema.
En sntesis, el proceso de ingeniera de requisitos se utiliza para definir todas las
actividades involucradas en el descubrimiento, documentacin y mantenimiento de los
requisitos para un producto de software determinado, donde es muy importante tomar
en cuenta que el aporte de la IR vendr a ayudar a determinar la viabilidad de llevar a
cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un
subproceso de obtencin y anlisis de requisitos, su especificacin formal, para
finalizar con el subproceso de validacin donde se verifica que los requisitos realmente
definen el sistema que quiere el cliente.
3.1.3.1 Tipos de requisitos

Existen dos tipos de requisitos: requisitos funcionales y requisitos no funcionales.
3.1.3.1.1 Requisitos Funcionales
Son lo que los usuarios requieren que el sistema haga y son usados para expresar el
comportamiento de un sistema, especificando las condiciones de entrada y salida que
el sistema debe cumplir. Los casos de uso son usados para establecer lo que el
sistema debe hacer. Un estudio profundo del rea de estudio usando casos de uso
permite conocer las necesidades de los usuarios. Estos requisitos pueden
establecerse ms claramente usando prototipos.
3.1.3.1.2 Requisitos No Funcionales
Son restricciones que especifican propiedades del sistema, tales como facilidad de
uso, restricciones del entorno o de implementacin, rendimiento, dependencias de
plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad y escalabilidad.
El incumplimiento de un requerimiento no funcional puede significar que
el sistema entero sea inutilizables. Por ejemplo, si un sistema de
contabilidad no cumple sus requisitos de fiabilidad, no se certificar
como seguro para el funcionamiento; si un sistema de control de tiempo
real no cumple sus requisitos de rendimiento, las funciones de control
no funcionaran correctamente.
3.1.4 Requisitos FURPS+

Este es un tipo de clasificacin de requisitos especificado en la documentacin de
RUP. Se utiliza el acrnimo FURPS (por las siglas en ingls) para describir las
principales categoras de requisitos:
Funcionalidad (Functionality)
Facilidad de Uso (Usability)
CIBERTEC
65
Confiabilidad (Reliability)
Rendimiento (Performance)
Soporte (Supportability)
El smbolo "+" en FURPS+ hace referencia a que se deben incluir otros requisitos,
tales como:
Restricciones de diseo
Requisitos de implementacin
Requisitos de interfaz
Requisitos fsicos
3.1.4.1 Funcionales
Los requisitos funcionales deben incluir:
Conjunto de caractersticas
Capacidades
Seguridad
Por ejemplo, para un Sistema de Ventas:
R1: Mostrar descripcin y precio de productos.
R2: Registrar venta de productos.
R3: Reducir stock cuando se realiza la venta.
R4: Identificar al cajero utilizando un usuario y una clave.
3.1.4.2 Facilidad de Uso
Deben incluir subcategoras tales como:
Factores Humanos
Estticos
Consistencia de Interfaz de Usuario
Ayuda en lnea o context-sensitive
Asistentes (wizards)
Documentacin de Usuario
Materiales de Capacitacin/Entrenamiento
Por ejemplo:
R1: El sistema deber proporcionar ayudas en lnea para orientar en el uso de las
interfaces.
R2: Maximizar eficiencia mediante la navegacin con teclado.
R3: El sistema debe tener interfaces grficas de administracin y de operacin en
idioma espaol y en ambiente 100% Web, para permitir su utilizacin a travs de
navegadores de Internet
3.1.4.3 Confiabilidad
Frecuencia de fallos
Capacidad de recuperacin a fallos
Posibilidades de prediccin del programa
Precisin
Tiempo medio de fallos
Por ejemplo:
CIBERTEC
66
R1: El sistema debe registrar los pagos a crdito autorizados que se hagan a las
cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de
energa o del equipo.
R2: La cuenta del usuario se bloquear por un lapso de 30 minutos luego de 4 intentos
fallidos para evitar vulnerabilidades en la seguridad del sistema.
3.1.4.4 Rendimiento
Condiciones impuestas a requisitos funcionales y son tales como:
Velocidad
Eficiencia
Disponibilidad
Tiempo de Respuesta
Tiempo de Recuperacin
Uso de recursos
Por ejemplo:
R1: El tiempo mximo para mostrar el reporte de cuentas por cobrar mediante un
histograma es de 20 segundos.
R2: El sistema debe estar disponible al 100% o muy cercano a esta disponibilidad
durante el horario hbil laboral de la empresa a nivel nacional, es decir, de lunes a
viernes de 8:00 a.m. a 5:00 p.m., con excepcin de los das festivos.
3.1.4.5 Soporte
Es la capacidad que tiene el software de ser modificado fcilmente para adecuar
mejoras o cambios. Incluye:
Adaptabilidad
Facilidad de mantenimiento
Compatibilidad
Configurabilidad
Facilidad de instalacin
Internacionalizacin
Por ejemplo:
R1: El sistema debe operar de manera independiente del navegador que se utilice
(Microsoft Internet Explorer 6.0 o superior, Netscape 6.0 o superior, Mozilla
FireFox).
R2: El sistema deber estar orientado a que las actualizaciones slo se hagan en el
sitio del servidor.
3.1.4.6 Restricciones de Diseo
Tambin llamados restricciones de diseo, especifican o restringen el diseo de un
sistema.
Por ejemplo:
R1: El sistema deber considerar en su arquitectura un modelo tres capas, donde se
definen tres componentes lgicos de manera independiente: servicios de presentacin o
interfaz de usuario, servicios de funcionalidad y servicios de datos.
3.1.4.7 Requisitos de implementacin
Especifica restricciones de codificacin o de construccin del sistema:
CIBERTEC
67
Estndares requeridos
Lenguajes de implementacin
Polticas para la integridad de Bases de Datos
Lmite de recursos
Ambientes de Operacin
Por ejemplo:
R1: El sistema debe desarrollarse con el lenguaje JAVA V1.6.
3.1.4.8 Requisitos de interfaz
Especifica:
Elemento externo con el que el sistema debe interactuar
Restricciones o formatos, tiempos u otros factores usados en tales interacciones
Por ejemplo:
R1: El sistema deber proporcionar, para los diferentes reportes solicitados, salidas
en documentos electrnicos (Word, Excel o Acrobat Reader).
R2: En una visin preliminar de impresin se considerara que todos los textos estarn
relacionados con un visor de PDF, las estadsticas y resultados de consultas estarn
relacionados con Excel 2003.
3.1.4.9 Requisitos fsicos
Especifican caractersticas fsicas que el sistema debe poseer. Por ejemplo: material,
forma, tamao y peso. Pueden especificarse los requisitos de hardware.
Por ejemplo:
R1: Para que un cliente de la aplicacin pueda ejecutar procesos, en lnea, considerados
en el sistema el punto de acceso deber cumplir con los siguientes requisitos
mnimos.
o Procesador 1.0 GHz.
o Memoria 128 MB.
o Disco duro 10 GB.
o Sistema Operativo Windows XP o Linux.
o Navegador internet Explorer 6.0 o posterior, Mozilla Firefox
2.X, Netscape Navigator 6.X o posterior con plugins para
Macromedia Flash y Java.
o Conexin a Internet. mnimo 56Kbps
3.1.5 Tcnicas para capturar requisitos

Existen varias tcnicas para capturar requisitos de usuarios y de las cuales
examinaremos algunas de ellas.
3.1.5.1 Entrevistas
Utilizada para reunir informacin proveniente de una persona o de un grupo de
personas. Generalmente, los encuestados son usuarios de los sistemas existentes o
usuarios en potencia del sistema propuesto. En algunos casos, son gerentes o
empleados que proporcionan datos para el sistema propuesto o que sern afectados
por l.
CIBERTEC
68
El xito de esta tcnica, depende de la habilidad del entrevistador para crear un clima
de confianza y de su preparacin para la misma. Despus de la entrevista, se debe
analizar la informacin obtenida y construir algunos requisitos candidatos.
Los puntos esenciales de esta tcnica se anotan a continuacin:
Dos entrevistadores: Conviene que dos personas realicen la entrevista para
mejorar la gestin del tiempo, pues uno conduce la entrevista y el otro supervisa
la interaccin y toma notas.
Formule tanto preguntas abiertas como cerradas: Las preguntas abiertas no
presuponen ninguna respuesta particular y animan al entrevistado a hablar sobre
el problema, mientras que las preguntas cerradas presentan un intervalo
especfico de respuesta. Ejemplos:
Pregunta abierta: Quin utiliza el sistema?
Pregunta cerrada: Utiliza usted el sistema?
No invente una solucin, pues puede pensar que tiene una muy buena idea de lo
que necesitan los grupos de decisin, pero debe mantener esta preconcepcin a
un lado durante la entrevista. sta es la nica forma de averiguar lo que
realmente necesita.
Escuche: sta es la nica forma en la que averiguar qu quieren los grupos de
decisin, por lo tanto djeles tiempo para hablar. Permtales hablar sobre una
pregunta y que la exploren de su propia forma. Si busca respuestas especficas,
es posible que invente una solucin y formule preguntas cerradas basndose en
esa invencin.
No adivine los pensamientos: sta es una habilidad humana muy importante ya
que es la base de la empata. Sin embargo, no es recomendable cuando trata de
obtener requisitos, pues puede acabar especificando lo que usted necesita en
lugar de con lo que necesitan los grupos de decisin.
3.1.5.2 Cuestionarios
Los cuestionarios pueden ser un suplemento de utilidad para las entrevistas. Son
excelentes para conseguir respuestas a preguntas cerradas. Puede descubrir
preguntas claves a partir de las entrevistas e incorporar stas en un cuestionario que
puede distribuir a una audiencia ms amplia. Esto le puede ayudar a validar su
entendimiento de los requisitos.
Por el tipo de preguntas que contiene, existen dos tipos de cuestionarios: abiertos y
cerrados.
Abiertos: No presuponen ninguna respuesta particular y animan al entrevistado a
hablar sobre el problema para obtener opiniones y/o referencias.
Cerrados: Limitan las respuestas posibles a travs de un estilo cuidadoso en la
pregunta.
Los tipos de respuestas de un cuestionario cerrado podran ser los siguientes:
SI/NO
Cree que se cometen muchos errores en la codificacin de los nmeros de cuenta en
las facturas?
SI
NO
DE ACUERDO/EN DESACUERDO
Se cometen muchos errores al codificar os nmeros de cuenta en las facturas?
CIBERTEC
69
DE ACUERDO
EN DESACUERDO
ESCALAS
Se cometen muchos errores al codificar 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
SELECCIN DE RESPUESTAS LIMITADAS

Cuando se presentan errores en la codificacin de los nmeros de cuenta en las
facturas, cul es la causa ms frecuente? (Anote el nmero de la respuesta
apropiada. Tambin la segunda razn ms comn y la menos comn).
1....
2....
Los buenos cuestionarios se deben disear previamente. Un pensamiento cuidadoso,
acompaado de una prueba previa, tanto del formato como de las preguntas, son la
base de una recopilacin de datos significativa a travs de cuestionarios.
Pautas que le ayudarn a confeccionar un buen cuestionario:
1. Determine qu datos necesitan recopilarse y qu personas son las ms
calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos
variantes y mayor visin identifquelos tambin.
2. Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cules
pueden ser ms tiles, si contienen una seccin de respuestas cerradas y otras
de respuestas abiertas.
CIBERTEC
70
3. Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las

preguntas extras que son intencionalmente redundantes, pueden ser tiles al
asegurar respuestas consistentes por parte de quien responda.
4. Examine el cuestionario para encontrarle fallas y defectos como:
a. Interrogantes innecesarias.
b. Preguntas que puedan ser mal interpretadas debido a su enfoque o
forma de escritura.
c. Preguntas que el sujeto no pueda responder.
d. Preguntas que estn escritas de forma que se escoger la respuesta
preferida.
e. Preguntas que se interpretaran en forma diferente dependiendo del
marco de referencia de cada entrevistado.
f. Preguntas que no proporcionan opciones adecuadas de respuesta.
g. Un ordenamiento no adecuado de las preguntas y respuestas.
5. Prubelo previamente en un Grupo pequeo para detectar otros problemas
posibles.
6. Analice la respuesta del Grupo de prueba para asegurar que el anlisis de los
datos que se busca se puede llevar a cabo con los datos recopilados. Si los
datos no revelan algo que el analista no conoce, el cuestionario puede no ser
necesario.
7. Realice cambios finales de edicin e imprmalo en una forma legible.
8. Distribuya el cuestionario. Cuando sea posible anote el nombre de cada
persona.
3.1.5.3 Lluvia de ideas (Brainstorm)
Este es un modelo que se usa para generar ideas. La intencin en su aplicacin es la
de generar la mxima cantidad posible de requisitos para el sistema. No hay que
detenerse en pensar si la idea es o no del todo utilizable. La intencin de este ejercicio
es generar, en una primera instancia, muchas ideas.
Las reglas bsicas a seguir son:
Los participantes deben pertenecer a distintas disciplinas y, preferentemente,
deben tener mucha experiencia. Esto trae como consecuencia la obtencin de
una cantidad mayor de ideas creativas.
Conviene suspender el juicio crtico y se debe permitir la evolucin de cada una
de las ideas, porque si no se crea un ambiente hostil que no alienta la
generacin de ideas.
Por ms locas o salvajes que parezcan algunas ideas, no se las debe descartar,
porque luego de maduradas probablemente se tornen en un requerimiento
sumamente til.
A veces ocurre que una idea resulta en otra idea, y otras veces podemos
relacionar varias ideas para generar una nueva.
Escribir las ideas sin censura.
3.1.5.4 Prototipos
Durante la actividad de extraccin de requisitos, puede ocurrir que algunos requisitos
no estn demasiado claros o que no se est muy seguro de haber entendido
CIBERTEC
71
correctamente los requisitos obtenidos hasta el momento, todo lo cual puede llevar a
un desarrollo no eficaz del sistema final.
Entonces, para validar los requisitos hallados, se construyen prototipos. Los prototipos
son simulaciones del posible producto, que luego son utilizados por el usuario final,
permitindonos conseguir una importante retroalimentacin en cuanto a si el sistema
diseado sobre la base de los requisitos recolectados le permite al usuario realizar su
trabajo de manera eficiente y efectiva.
El desarrollo del prototipo comienza con la captura de requisitos. Desarrolladores y
clientes se renen y definen los objetivos globales del software, identifican todos los
requisitos que son conocidos, y sealan reas en las que ser necesaria la
profundizacin en las definiciones. Luego de esto, tiene lugar un diseo rpido. El
diseo rpido se centra en una representacin de aquellos aspectos del software que
sern visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseo
rpido lleva a la construccin de un prototipo.
3.1.6 Captura de requerimientos a solicitud del cliente

Si el equipo de desarrollo tiene un conocimiento de la estructura de la organizacin, de
las metas, de la visin y de los clientes/usuarios o si slo se est aadiendo una nueva
caracterstica a un sistema existente, entonces RUP no recomienda que se empiece
con un Modelado del negocio. En ese caso, RUP recomienda que se empiece con la
Captura de requisitos.
Esta actividad consiste en identificar todas las necesidades de stakeholders. Como se
explic anteriormente, el trmino Stakeholder se utiliza para referirse a cualquier
persona o grupo que est interesado por los resultados del proyecto.
Clasificacin y
organizacin de
requisitos
Descubrimiento de
requisitos
Ordenacin por
prioridades y negociacin
de requisitos
Documentacin de
requisitos
Figura 3.3.- El proceso de obtencin y anlisis de requisitos.
Obtener y comprender los requisitos de los stakeholders es difcil por varias razones:
Los stakeholders a menudo no conocen lo que desean obtener del sistema
informtico excepto en trminos muy generales; puede resultarles difcil
CIBERTEC
72
expresar lo que quieren que haga el sistema o pueden hacer demandas

irreales debido a que no conocen el coste de sus peticiones.
Los stakeholders expresan los requisitos distintos con sus propios trminos
de forma natural y con un conocimiento implcito de su trabajo.
Diferentes requisitos de diferentes stakeholders tienen concordancia y
algunos generan conflictos.
En la figura 3.3 se muestra un modelo general para obtener y analizar requisitos. Con
cada vuelta del ciclo de este modelo la comprensin de los requisitos por parte del
analista mejorar.
Cada equipo de desarrollo tendr su propia versin o instancia de este modelo,
dependiendo de la habilidad del personal, el tipo de sistema a desarrollar y los
estndares utilizados.
Los pasos a seguir son:
1. Descubrimiento de requisitos. Es el proceso de interactuar con los stakeholders
del sistema para recopilar sus requisitos. Para ello, se utilizan tcnicas de
captura de requisitos como las entrevistas y prototipos.
2. Clasificacin y organizacin de requisitos. En esta actividad, el analista toma la
recopilacin no estructurada de requisitos, grupos relacionados de requisitos y
los organiza en grupos coherentes.
3. Ordenacin por prioridades y negociacin de requisitos. Inevitablemente, cuando
existen muchos stakeholders involucrados, los requisitos entrarn en conflicto.
Esta actividad se refiere a ordenar segn las prioridades de requisitos, y a
encontrar y resolver los requisitos en conflicto a travs de la negociacin.
4. Documentacin de requisitos. Se documentan los requisitos y se contina en la
siguiente vuelta de la espiral. Se pueden producir documentos de requisitos
formales o informales como por ejemplo: Modelo de casos de uso para requisitos
funcionales y Especificacin de Requisitos de Software que contiene todos los
tipos de requisitos (funcionales y no funcionales) del sistema.
3.1.7 Captura de requerimientos a partir del diagrama de actividades del

negocio
Mediante la utilizacin del modelo del negocio como entrada, el analista emplea una
tcnica sistemtica para crear un modelo de casos de uso tentativo. Para ello, el
analista construir un diagrama de casos de uso tomando como punto de partida los
diagramas de actividades.
En primer lugar, se obtienen los requisitos funcionales a partir de las actividades
candidatas a ser informatizadas. Luego, con estos requisitos se crean los casos de
uso. Las actividades que no sern soportadas por el sistema no les correspondern un
caso de uso. Los actores se identificarn a partir de los roles (trabajadores o actores
del negocio) que realizan las actividades del negocio a informatizar.
Figura 3.3.- Del Modelo del Negocio al Modelo de Casos de Uso
CIBERTEC
73
Es importante documentar el seguimiento de estos elementos: actividades a

informatizar, requisitos funcionales y casos de uso. Ms an, si se trata de seguir
requisitos funcionales de casos de uso, el cual es un proceso complicado por el hecho
de que existe una relacin muchos a muchos entre ellos. Un caso de uso puede tratar
muchos requisitos funcionales y un requerimiento funcional puede estar presente en
varios casos de uso diferentes.
Afortunadamente, existen herramientas de ingeniera de requisitos como el Requisite
Pro y DOORS. Pero si no tiene ningn soporte de herramienta de modelado, tiene que
hacer el trabajo manualmente. Un buen enfoque es crear una matriz denominada
Matriz de Actividades y Requisitos. Estas matrices se crean a menudo en hojas de
clculo. La plantilla se proporciona en la Tabla 3.2.
Tabla 3.2.- Plantilla de Matriz de Actividades y Requisitos.
Una Matriz de Actividades y Requisitos es una herramienta manual utilizada para

obtener requisitos funcionales a partir de actividades del negocio que se van a
informatizar. Una vez identificado los requisitos funcionales, se crean los casos de uso.
Por otro lado, los actores son creados a partir de los responsables de las actividades
del negocio que se tienen en la matriz.
Caso de Estudio N1 Requerimientos

Continuaremos con el ejemplo de la unidad de aprendizaje anterior de Venta de
Electrodomsticos. Se debe de Seleccionar las actividades relevantes que podran
automatizar y marcarlas de un color diferente:
Resaltar las siguientes acciones

o
o
o
o
o
Verificar existencia de producto

Generar Ticket
Emitir ticket
Generar CDP
Entregar producto
CIBERTEC
74
CIBERTEC
75
CIBERTEC
La Matriz de Actividades y Requisitos para el sistema de punto de venta es el siguiente:
Matriz de actividades y requisitos del sistema <Sistema venta de electrodomesticos>

Proceso
de
Negocio
Realizar
venta
Actividad del
Negocio
Verificar existencia
de producto
Generar Ticket
Emitir ticket
Generar CDP
Entregar producto
Responsabl
e del
Negocio
Requerimiento
Vendedor
R01
Vendedor
Vendedor
Cajero
Vendedor
R02
r03
R04
R05
Verificar si existe el
producto
Generar de ticket
imprimir ticket
Generar Cdp
Descargar stock
Caso de Uso
Actores
buscar producto
Vendedor
Generar Ticket
Vendedor
generar CDP
Cajero
Iteracin #
o
Prioridad
77
Luego, el Diagrama de Casos de Uso Inicial resultante ser el siguiente:
Este Diagrama de Casos de Uso debe ser refinado. Nuevos casos de uso sern
detectados al describir cada caso de uso obtenido; para ello, se utiliza el documento
Especificacin de Caso de Uso (Ver tema: Desarrollo de Especificaciones de Casos de
Uso).
Por ltimo, los nuevos casos de uso sern agregados en un diagrama denominado
Diagrama Estructurado de Casos de Uso, consiguiendo de esta manera, la versin
final del Modelo de Casos de Uso (Ver tema: Estructurando el Modelo de Casos de
Uso).
CARRERAS PROFESIONALES
CIBERTEC
78
1. De la lista, clasifique los requisitos segn las categoras de FURPS+.
R01. El sistema deber garantizar que su despliegue se pueda realizar, ya sea en el
lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits
sin que esto afecte el rendimiento del mismo.
R02. El sistema debe contar con un Manual Tcnico de Referencia para la
Aplicacin, el cual estar orientado a profesionales capacitados en aspectos
tcnicos del rea de sistemas.
R03. La clave de los usuarios considerar las siguientes polticas:
- Expirar segn parametrizacin del sistema
- Tener mnimo una longitud de 8 caracteres
- Contener letras y nmeros
- No puede contener espacios
- No pueden repetirse las 3 ltimas contraseas
- No contendr el nombre o apellido de la persona duea del usuario
R04. El cdigo fuente del sistema deber cumplir con el estndar de codificacin
definido en el documento Estndares y Nomenclaturas de Cdigo Fuente.
R05. Utilizar el idioma castellano para los mensajes y textos en la Interfaz.
R06. El sistema ser utilizado por clientes de todo el mundo. Adicionalmente, la
Organizacin Pro-Turismo exige que para anunciar servicios en su portal, stos
deben estar provistos en espaol, ingls y portugus. Estos tres idiomas deben
ser soportados por el producto desarrollado.
R07. El sistema deber permitir la creacin, modificacin, activacin, desactivacin y
autorizacin de los roles de usuarios definidos.
R08. El sistema deber prever contingencias que pueden afectar la prestacin
estable y permanente del servicio.
La siguiente es la lista de las contingencias que se deben tener en cuenta y se
pueden considerar crticas:
Sobrecarga del sistema por volumen de usuarios.
Cada del sistema por sobrecarga de procesos.
Cada del sistema por sobrecarga de transacciones.
Cada del sistema por volumen de datos excedido en la base de datos.

R09. El sistema deber contar con el manual de FAQ (Frequent Asked Questions),
en lnea e impreso, que es un resumen con las respuestas a las preguntas ms
frecuentes que se hacen los usuarios.
R10. El sistema debe considerar en su arquitectura, el patrn de diseo MVC.
CIBERTEC
79
3.2 TEMA 7: MODELO DE CASOS DE USO

El modelo de casos de uso captura los requisitos funcionales de los usuarios a un alto
nivel y establece la estructura fundamental del sistema. Este modelo utiliza actores y
casos de uso. Los actores son los roles que los usuarios pueden representar y los
casos de uso representan lo que los usuarios deberan poder hacer con el sistema.
Este modelo no incluye los requisitos no funcionales ni los requisitos funcionales
internos. No usa descomposicin funcional. El modelo resultante es fcil de entender y
debe ser verificado por los usuarios antes de empezar a construir el sistema.
El modelo de casos de uso es empleado no solamente para capturar requisitos de
nuevos sistemas; tambin es utilizado cuando nuevas generaciones de sistemas son
desarrolladas. Cuando una nueva versin de un sistema es desarrollada, las nuevas
funcionalidades son agregadas al modelo de casos de uso existente, insertando
nuevos actores y casos de uso y modificando las especificaciones de los actuales
casos de uso.
El modelo de casos de uso se construye mediante los siguientes pasos:
Encontrar actores y casos de uso

Priorizar casos de uso
Detallar un caso de uso
Crear prototipo de interfaz de usuario
Estructurar el modelo de caso de uso
Estos pasos no tienen por qu ser ejecutados en ningn orden en particular y a

menudo se hacen simultneamente. De hecho, podemos trabajar por mltiples vas
que producen un resultado final equivalente. Podemos, por ejemplo, comenzar
encontrando algunos casos de uso (la actividad de Encontrar Actores y Casos de
Uso), despus disear las interfaces de usuario (la actividad de Crear Prototipo de
Interfaz de Usuario), para darnos cuenta de que necesitamos aadir un nuevo caso de
uso (as que retrocederemos a la actividad de Encontrar Actores y Casos de Uso,
rompiendo la secuencia estricta marcada), y as sucesivamente.
Los resultados de la primera iteracin a travs de este flujo de trabajo consisten en
una primera versin del modelo de casos de uso. Los resultados de cualquier iteracin
subsiguiente consistirn entonces en nuevas versiones de artefactos involucrados en
la creacin del modelo de casos de uso. Hay que recordar que todos los artefactos se
contemplan y mejoran incrementalmente a travs de iteraciones.
Las distintas actividades en el modelado de caso de uso adoptan formas diferentes en
diferentes fases del proyecto. Por ejemplo, cuando un analista ejecuta la actividad de
Encontrar Actores y casos de Uso durante la fase de inicio, identificar muchos
actores y casos de uso nuevos. Pero cuando la actividad se realiza durante la fase de
construccin, el analista har cambios secundarios en la lista de actores y casos de
uso, tales como la creacin de un diagrama de casos de uso que describe mejor el
modelo de casos de uso desde una perspectiva en particular.
CIBERTEC
80
3.2.1. Encontrar actores y casos de uso

Lo primero que necesita hacer cuando piense en crear un sistema es decidir dnde se
encuentran los lmites del sistema. Es decir, necesita decidir qu o quines utilizan el
sistema (los actores) y qu beneficios especficos ofrece el sistema a esos actores (los
casos de uso).
3.2.2. Encontrar actores

ste es uno de los primeros pasos para definir qu o quines interactuarn con el
sistema. Antes de indicar cmo se identifican los actores empezaremos por definirlo.
3.2.2.1 Actor
Un actor representa un rol (humano, hardware o software) externo al sistema con el
que se establece intercambio directo de informacin.
Hay una diferencia entre actor y usuario. Usuario es el que utiliza el sistema, mientras
que el actor representa un cierto rol que un usuario puede desempear. Es decir que
los actores definen los roles que pueden representar los usuarios.
A continuacin daremos algunos ejemplos para tener claro lo que constituye un actor.
Muchos usuarios pueden desempear el mismo rol. Por ejemplo, la figura 3.4 muestra
a dos usuarios, Ivar y Mark, que cumplen el rol de operador de una mquina de
reciclaje. Cuando ellos usan la mquina de reciclaje cada uno es representado por una
instancia del actor Operador.
Sin embargo, en algunas situaciones, una sola persona desempea el rol
representado por el actor. Por ejemplo, puede haber slo una persona desempeando
el papel de administrador del sistema para un sistema bastante pequeo.
Figura 3.4.- Muchos usuarios representados por un actor.
Tambin podemos encontrar que el mismo usuario puede ser representado por varios
actores, esto es porque la misma persona puede desempear roles diferentes. Por
CIBERTEC
81
ejemplo, la figura 3.5 muestra que un usuario desempea dos roles: Jefe de Almacn
y Personal de almacn.
Figura 3.5.- Un usuario representado por dos actores.
3.2.2.2 Cmo identificar actores

Para identificar actores debe responder las siguientes preguntas:
Qu actores del negocio o trabajadores del negocio son responsables de las

actividades a informatizar?
Qu grupos de usuarios necesitan ayuda del sistema para llevar a cabo sus
tareas?
Qu grupos de usuarios son fundamentales para ejecutar las funciones
principales del sistema?
Qu grupos de usuarios son los que llevarn a cabo funciones secundarias
como mantenimiento o administracin?
El sistema a desarrollar interactuar con algn hardware o sistema de
software?
Cualquier individuo, grupo o fenmeno que cumpla con una o ms de estas categoras
es candidato para ser un actor. La figura 3.6 muestra el entorno del sistema del cual se
encontrarn categoras de actores.
Figura 3.6.- Entorno del sistema.
Para determinar si se tienen los actores correctos, se puede elegir dos o tres personas
que usarn el sistema y, a continuacin, ver si el conjunto de actores obtenido es
suficiente para cubrir sus necesidades.
CIBERTEC
82
Por ltimo, se completa la identificacin de actores al obtener todos los casos de uso
del sistema que conlleva a crear otros actores o eliminar a algunos que existen. Este
proceso de refinamiento se ver en el prximo captulo Estructurando el Modelo de
Casos de Uso.
3.2.2.3 Definicin de las fronteras del sistema
Encontrar a los actores significa tambin definir las fronteras del sistema, que ayuda a
comprender el propsito y el alcance del sistema. Slo aquellos que se comunican
directamente con el sistema son actores. Por ejemplo:
En un sistema de reservas de lneas areas, quines podran ser actores? Esto
depende del tipo de sistema que se construye. Si est desarrollando el sistema de
reservaciones, para un agente de viajes, el actor ser el agente de viaje. El pasajero
no interacta con el sistema directamente, entonces no ser un actor.
Figura 3.7.- Actores de un Sistema de Reservaciones I.
En cambio, si est desarrollando un sistema de reservaciones, para que los pasajeros

se puedan conectar a travs de Internet, el pasajero ahora s interactuar con el
sistema y se convertir en actor.
Figura 3.8.- Actores de un Sistema de Reservaciones II.
3.2.2.4 Tiempo como actor

Aunque claramente el tiempo es una entidad externa al sistema (por lo que cumple
con la primera mitad de la definicin de un actor) difcilmente podremos pensar que el
tiempo se encuentra interesado en una funcionalidad de nuestro sistema.
En este caso, es el sistema quien va a tener inters en el tiempo, debido a que 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 casos de uso. La tcnica es introducir al actor Tiempo,
quien est asociado a casos de uso que capturan una funcionalidad automtica.
Un ejemplo de esto sera un respaldo automtico del sistema que se ejecuta todas las
noches o la generacin automtica de reporte de ventas diario, tal como se ilustra en
la siguiente figura.
CIBERTEC
83
Figura 3.9.-. Tiempo como actor.
3.2.2.5 Sugerencias para identificar adecuadamente a los actores del sistema
Son roles (humanos, software o hardware), no personas con nombres propios.

No siempre est asociado con el nombre de un cargo en la planilla de la
organizacin objetivo.
El nombre no debe representar reas, departamentos o partes de una
organizacin sino roles de ejecucin.
Cada actor debe estar asociado con al menos un caso de uso del sistema.
Si no participa en ningn proceso debe ser eliminado del modelo.
3.2.2.6 Breve Descripcin de actores

La breve descripcin del actor debe incluir informacin sobre:
A qu o a quin representa el actor?

Por qu el actor es necesario?
Qu intereses tiene el actor en el sistema?
La breve descripcin debe ser realizada en pocas lneas tanto en el Modelo de Casos
de Uso como en el documento Actores del Sistema. Por ejemplo, para una mquina de
reciclado, los actores Cliente, Operador y Administrador pueden ser descritos de la
siguiente manera:
Cliente: El cliente recoge botellas, latas y cajas en casa y los trae a la tienda para
obtener a cambio un reembolso.
Operador: El operador es el responsable del mantenimiento de la mquina de
reciclado.
Administrador: El administrador es responsable de las cuestiones sobre el dinero y
el servicio que la tienda ofrece a los clientes.
3.2.3. Encontrar casos de uso

Cuando su primer esbozo de los actores se completa, el siguiente paso es identificar
los casos de uso del sistema. Los primeros casos de uso son muy preliminares, y que
sin duda tiene que cambiar un par de veces hasta que sean estables. Si el sistema de
visin o de los requisitos son deficientes, o si el sistema de anlisis es vaga, la
funcionalidad del sistema ser poco clara. Por lo tanto, usted debe preguntarse
constantemente si ha encontrado los correctos casos de uso. Adems, usted debe
estar preparado para agregar, eliminar, combinar y dividir los casos de uso antes de
CIBERTEC
84
llegar a una versin final. Usted recibir una mejor comprensin de los casos de uso
una vez que se han descrito en detalle.
3.2.3.1 Caso de Uso
Un caso de uso es un fragmento de funcionalidad que el sistema ofrece para aportar
un resultado de valor para los actores. De manera ms precisa, un caso de uso
especifica una secuencia de acciones que el sistema ejecuta interactuando con sus
actores e incluyendo alternativas dentro de la secuencia. Las acciones pueden
involucrar la comunicacin con un determinado nmero de actores as como tambin
realizar clculos y trabajos dentro del sistema.
Las caractersticas de un caso de uso son:
Siempre es iniciado por un actor. El actor, directa o indirectamente, ordena al

sistema que se ejecute el caso de uso.
Provee valor para un actor, es decir, un caso de uso debe entregar algn tipo de
valor tangible para el actor.
Es completo. Un caso de uso no est completo hasta que el valor final se
produzca.
3.2.3.2 Cmo identificar casos de uso

La mejor manera de encontrar casos de uso es considerar lo que cada actor requiere
del sistema. Recuerde que el sistema existe slo para sus usuarios, y por lo tanto
debe partir de las necesidades de los usuarios.
Si cuenta con un Modelo de Negocio, los diagramas de actividades del Modelo de
Anlisis de Negocio sern utilizados para empezar a identificar casos de uso (como se
ha descrito en el punto 4 de la semana 8).
Las respuestas a las siguientes preguntas ayudarn a encontrar casos de uso:
Cules son las actividades del negocio objetos de automatizacin?

Cules son las tareas que el actor desea que el sistema desarrolle?
El actor crea, almacena, cambia, elimina o consulta datos en el sistema?
El actor necesita informar al sistema cambios generados en el entorno
circundante al sistema?
El actor necesita ser informado sobre la ocurrencia de situaciones externas al
sistema?
3.2.3.3 Sugerencias pasa identificar adecuadamente a los casos de uso
Son procesos o funcionalidades del sistema, que en la mayora de los casos

corresponden con opciones de ejecucin.
Deben estar asociados a por lo menos un actor del sistema u otro caso de uso
del sistema.
Representan la generalidad del comportamiento del proceso y no una instancia o
escenario especfico o caso muy particular del sistema.
3.2.3.4 Breve Descripcin de casos de uso

La breve descripcin del caso de uso debe reflejar su propsito, resumiendo las
acciones que ejecuta el caso de uso al interactuar con los actores. Esta descripcin se
realiza, en primer lugar con algunas frases en el Modelo de Casos de Uso y ms
CIBERTEC
85
adelante, con una descripcin paso a paso de lo que el sistema necesita hacer cuando
interacta con sus actores, en la Especificacin de Caso de Uso.
Siguiendo con el ejemplo de la mquina de reciclado, los casos de uso Reciclar
artculos y Agregar nuevo tipo de botella pueden describirse de la siguiente manera:
Reciclar artculos: El usuario utiliza esta mquina de reciclado para obtener
automticamente un recibo que indica el monto calculado por el nmero de artculos
(botellas, latas y cajas) reciclados. El recibo es cobrado en una caja registradora
(mquina).
Agregar un nuevo tipo de botella: Nuevos tipos de botellas se pueden agregar a la
mquina iniciando en "modo de aprendizaje y la insercin de 5 muestra. De esta
manera, la mquina puede medir las botellas y aprender a identificarlos. El
administrador especifica el valor de reembolso para el nuevo tipo de botella.
3.2.4. Crear el Diagrama de casos de uso

El diagrama de casos de uso muestra cmo se relacionan los casos de uso con los
actores. Pueden disearse varios diagramas de casos de uso, cada uno, creado en un
paquete que contiene un conjunto de casos de uso. La organizacin por paquetes
puede ser de acuerdo a cada proceso de negocio.
Empiece dibujndolos en la esquina superior izquierda. Los casos de uso deben
dibujarse en el orden en que normalmente los usar el actor. Opcionalmente, los
casos de uso mostrados en el diagrama se pueden encerrar dentro de un rectngulo
que representa los lmites del sistema.
El primer diagrama de casos de uso es un esbozo de la comunicacin que existe entre
un actor y un caso de uso. Ms adelante, se disea una versin final agregando
asociaciones entre los casos de uso. Ver mucho ms sobre los tipos de asociaciones
en la siguiente semana con el tema Estructurando el Modelo de Casos de Uso.
La siguiente figura muestra un esbozo del diagrama de casos de uso de una mquina
de reciclado. El rectngulo contiene los casos de uso que constituyen el
comportamiento del sistema.
Figura 3.10.-. Diagrama de Casos de Uso.
CIBERTEC
86
Caso de Estudio N1 Crear modelo de casos de uso

Ahora, vamos a identificar las funcionalidades del nuevo software.
En primer lugar, del Diagrama de Actividades se obtiene las siguientes actividades
a sistematizar:
Consulta Stock de electrodomsticos.

Genera ticket de pedido.
Genera comprobante de pago.
En segundo lugar, Qu es lo que ha solicitado el cliente que nos ha

contratado?
Ha solicitado que el registro de los pedidos sea va web y que sean registrados por sus
clientes afiliados. Asimismo, si sus clientes afiliados lo requieren, deberan actualizar
sus datos va web. Por consiguiente, tendramos ms requisitos:
Registrar afiliacin para el cliente no afiliado

Actualizar datos de afiliacin para el cliente afiliado
Consultar pedidos para el vendedor
Por otro lado, debemos tomar en cuenta otros requisitos que sern necesarios
para controlar el proceso. Por ejemplo:
Actualizar estado de pedido a CANCELADO cuando el cliente

pague su pedido.
El resultado de este anlisis se documenta en la Matriz de Actividades Vs. Requisitos,

tal como se muestra a continuacin:
CIBERTEC
87
Matriz de Actividades Vs. Requisitos Funcionales del Sistema de Ventas

Proceso de Negocio
Venta de
Electrodomsticos
Actividad del Negocio
Consulta Stock
electrodomsticos
Genera ticket de
pedido
Genera comprobante
de pago
Responsable
del
Negocio
Requisito
Consultar Stock de
Electrodomsticos
Vendedor
R01
Vendedor
R02 Generar Pedido
Cajero
R03 Registrar Pago de Pedido
Actualizar estado de
R04
pedido a CANCELADO
R05 Registrar Afiliacin
R06
R07 Consultar Pedidos
Actualizar datos de
afiliacin
Caso de Uso
CUS01
Consultar Stock de
Electrodomsticos
CUS02 Generar Pedido
CUS03
Registrar Pago de
Pedido
CUS04 Registrar Afiliacin

CUS05
Actualizar datos de
afiliacin
CUS06 Consultar Pedidos
Actores
Vendedor
Cliente Afiliado
Cliente Afiliado
Cliente No Afiliado
Cliente Afilado
Vendedor
Explicacin:
A partir de los requisitos se crean los casos de uso. Puede existir el caso en que ms de un requisito se implemente en un caso de uso,
como por ejemplo el caso de uso de sistema CUS03 contiene dos requisitos.
En la columna de actores se indican los roles que interactuarn con los casos de uso identificados. Como nuestro cliente ha solicitado
implementar una solucin web para el registro de pedidos, el rol Cliente afiliado ser quien realice esa funcionalidad y no el Vendedor.
CIBERTEC
88
CIBERTEC
3.3 TEMA 8: ESTRUCTURANDO DEL

CASOS DE USO
89
MODELO DE
Esta actividad se centra en relacionar los casos de uso y los actores del sistema, e
identificar sus comportamientos opcionales y excepcionales. Se establece las
inclusiones, extensiones y generalizaciones entre casos de uso, y las generalizaciones
entre actores.
Existen tres razones para estructurar el modelo de casos de uso:
Hacer que los casos de uso sean fciles de entender.
Extraer el comportamiento comn encontrado en varios casos de uso.
Hacer que el modelo de casos de uso sea fcil de mantener.

La ejecucin de cada caso de uso incluye la comunicacin con uno o ms actores.
Una instancia de un caso de uso siempre es iniciada por un actor pidiendo al sistema
hacer algo. Esto implica que cada caso de uso debe tener la asociacin de
comunicacin con los actores. La razn de esta norma es hacer cumplir el sistema
para ofrecer slo la funcionalidad que los usuarios necesitan, y nada ms. Si se
encuentran casos de uso que nadie pide significa que algo est mal en el modelo de
caso de uso o en los requisitos.
Sin embargo, hay algunas excepciones a esta regla:
Si un caso de uso es abstracto (no se instancia por separado, sino en el contexto

de otro caso de uso), su comportamiento no puede incluir la interaccin con
algn actor. En ese caso, el caso de uso abstracto no tendr ninguna asociacin
de comunicacin con actores.
Un caso de uso hijo en una relacin de generalizacin no necesita tener un actor
asociado a l si el caso de uso padre describe la comunicacin con el actor.
Un caso de uso base en una relacin include no necesita tener un actor asociado
a l si el caso de uso incluido describe la comunicacin con el actor.
Un caso de uso puede ser iniciado de acuerdo con un horario (por ejemplo, una
vez a la semana o una vez al da), lo que significa que el reloj del sistema es el
iniciador. El reloj del sistema es interno al sistema y el caso de uso no es iniciado
por un actor, sino por un evento interno del sistema. Si ninguna interaccin de
actor se produce en el caso de uso, ste no tendr ninguna asociacin con un
actor. Sin embargo, se puede utilizar un actor ficticio "tiempo" para mostrar cmo
el caso de uso es iniciado en el diagrama de casos de uso.
3.3.1 Objetivos
Los objetivos de esta actividad son:
Extraer descripciones de funcionalidad (de casos de uso) generales y
compartidas que pueden ser utilizadas por casos de uso ms especficos
(generalizacin).
Extraer descripciones de funcionalidad (de casos de uso) adicionales u
opcionales que pueden extender casos de uso ms especficos (relaciones de
extensin).
Extraer descripciones de funcionalidad (de casos de uso) adicionales e
incondicionales incluidas en la ejecucin de casos de uso especficos (relaciones
de inclusin)
CIBERTEC
90
3.3.2 Tipos de relaciones

Existen tres tipos de relaciones entre casos de uso: include, extend y de
generalizacin. Entre actores se puede utilizar slo la relacin de generalizacin.
3.3.2.1 Relacin include
Una relacin include se define como la utilizacin de los pasos de un caso de uso
como parte de la secuencia de otro caso de uso al que se llamar caso de uso base.
El caso de uso incluido nunca se encuentra aislado, sino que es instanciado slo como
parte de algn caso de uso base que lo incluye.
Esta relacin se usa para evitar describir el mismo flujo de eventos repetidas veces,
poniendo el comportamiento comn en un caso de uso aparte y que ser incluido por
un caso de uso base.
Su representacin grfica con es la siguiente:
Figura 3.11.- Relacin <<include>> entre casos de uso.
Para entender la ejecucin de un caso de uso incluido analice la siguiente figura.

Puede observar que el comportamiento del caso de uso incluido se inserta en un punto
del caso de uso base. Cuando una instancia de caso de uso, el cual sigue la
descripcin de un caso de uso base, llega a un punto en donde la relacin include es
definida, seguir la descripcin del caso de uso incluido. Una vez que la inclusin se
lleva a cabo, la instancia del caso de uso regresar al caso de uso base, en el punto
donde se detuvo.
Figura 3.12.- Ejecucin de la inclusin.
CIBERTEC
91
3.3.2.2 Relacin extend

Una relacin extend se define como la agregacin de pasos a la secuencia del caso de
uso original, que pasar a conocerse como caso de uso base. Esta extensin se
realiza en puntos indicados, llamados puntos de extensin, de manera especfica
dentro de la secuencia del caso de uso base. El caso de uso puede estar aislado pero,
en algunas condiciones, su comportamiento puede extenderse con el comportamiento
de otro caso de uso.
Esta relacin se utiliza para modelar la parte de un caso de uso que el usuario puede
ver como comportamiento opcional del sistema. De esta forma, se separa el
comportamiento opcional del obligatorio.
Su representacin grfica es la siguiente:
Figura 3.13.- Relacin <<extend>> entre casos de uso.
La siguiente figura ilustra la ejecucin de un caso extendido. Note que cuando una
instancia del caso de uso base, llega a un lugar en donde un punto de extensin se ha
definido, la condicin en la correspondiente relacin extend es evaluada. Si la
condicin es verdadera, la instancia del caso de uso seguir la extensin; de lo
contrario, la extensin no se ejecuta.
Una vez que la instancia de caso de uso ha realizado la extensin, la instancia de caso
de uso reanuda su ejecucin al caso de uso base, en el punto donde se detuvo.
Figura 3.14.- Ejecucin de la extensin.
CIBERTEC
92
3.3.2.3 Relacin de generalizacin

La generalizacin entre casos de uso es como la generalizacin entre clases. En este
caso significa que el caso de uso hijo hereda el comportamiento y el significado del
caso de uso padre; el hijo puede aadir o redefinir el comportamiento del padre. La
relacin de generalizacin puede representarse tambin entre actores.
Su representacin grfica es la siguiente:
Figura 3.15.- Relacin de generalizacin entre casos de uso.
Figura 3.16.- Relacin de generalizacin entre actores.
Una instancia de caso de uso ejecutada por el caso de uso hijo seguir el flujo de
eventos descritos por el caso de uso padre, insertando comportamiento adicional y
modificando el comportamiento, tal como se define en el flujo de eventos del caso de
uso hijo.
Figura 3.17.- Ejecucin de la generalizacin.
CIBERTEC
93
3.3.3 Casos de usos abstractos y concretos

Se dice que un caso de uso es abstracto slo si se instancia en el contexto de otro
caso de uso, es decir, dependen de otro caso de uso para instanciarse puesto que no
existe un actor que lo active.
Un caso de uso es concreto si es iniciado por un actor y constituye un completo flujo
de eventos. "Completo" significa que una instancia del caso de uso lleva a cabo toda la
operacin solicitada por el actor.
Por lo tanto podemos afirmar que:
Los casos de uso activados por un actor son concretos.
Los casos de uso incluidos o extendidos que nicamente pueden instanciarse

cuando son llamados por el caso de uso base son casos de uso abstractos
En el caso de la generalizacin, generalmente el caso de uso padre ser

abstracto debido a que no estn definidos completamente, pues los casos de
uso hijos contienen las funciones especficas requeridas por los actores.
La siguiente figura ilustra ejemplos de casos de uso abstractos y concretos en un

Diagrama de casos de uso estructurado. Es conveniente escribir con letra cursiva el
nombre del caso de uso abstracto.
Figura 3.18.- Diagrama de casos de uso estructurado.
CIBERTEC
94
Elabore el Diagrama de Casos de Uso Estructurado del siguiente caso.
COLABORA- PERU
Colabora Per es una compaa dedicada a la prestacin de servicios de atencin de
las relaciones entre las empresas y sus clientes a travs de Centros de Contacto
Telefnico o plataformas multicanal (IVR, SMS) para brindar diferentes servicios (Tele
marketing, Tele cobranza, Fidelizacin, Gestin de Datos, etc.) para aquellas
empresas o instituciones que gestionan grandes carteras de clientes o demandan una
fluida relacin con sus usuarios.
El principal proceso de la compaa se inicia cuando una empresa se pone en
contacto con nuestra compaa Colabora Per, es atendido por un vendedor quien
registra un presupuesto previamente se verifica si la empresa ya se encuentra
registrado, de no encontrarse deber de registrarla como nueva empresa.
Posteriormente cuando el vendedor gestiona la obtencin del contrato el Jefe de
Marketing registrara un contrato, previamente se obtuvo los costos del presupuesto,
detallara las especificaciones del contrato y entregara una copia a la empresa
contratante y al Gerente de Ventas
El Gerente de Ventas enva una copia del contrato al jefe de Operaciones para iniciar
la atencin del contrato, el jefe de Operaciones llama a la empresa contratante para
que nos entrega la lista de deudores a llamar por telfono, Con la informacin se
registra un control de trabajo, donde se importa la data de deudores entregada, esta
informacin se carga quedando en un estado sin gestionar, previamente busco a la
empresa para asignar los deudores Luego las tele operadoras de tele marketing
ingresan al sistema al mdulo de gestin y seleccionaran la lista de deudores a
gestionar haciendo una bsqueda por control de trabajo, luego que se contactan con
los deudores y aceptan las condiciones se le cambia el estatus a gestin aceptada. Al
final del da el Jefe de operaciones genera un reporte con los datos de los deudores
que aceptaron la gestin, para ser enviados a la empresa contratante, previamente
hizo una bsqueda por control de trabajo. Adicionalmente ingresa al mdulo de
administracin de gestiones donde verifica las gestiones de las tele operadoras,
previamente hizo una bsqueda por control de trabajo.
Mensualmente el Jefe de Operaciones registra en el sistema una factura donde
detalla la cantidad de gestiones aceptadas, previamente busco a la empresa
contratante para signarle la factura
CIBERTEC
95
3.3.4. Especificacin de caso de uso

No existe estndar UML para una especificacin de caso de uso. Sin embargo, una
plantilla para una especificacin 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. Incluye el flujo bsico, sub flujos y flujos
alternativos
Precondiciones
Pos condiciones
Puntos de extensin
Requisitos especiales
Prototipos
A continuacin se detalla cmo se debe de registrar la Especificacin de caso de uso
1.1 Nombre del caso de uso

El nombre del caso de uso debe empezar con un verbo en infinitivo que plasme la
funcionalidad del caso de uso. Veamos algunos casos:
Para el mantenimiento de datos maestros, los cuales poseen subflujos

como: Agregar, Modificar, Eliminar, etc.
Mantener <Nombre de la informacin que mantiene>
Por ejemplo: Mantener Productos, Mantener Cliente.
Para el tratamiento de documentos legales, formales o de

transacciones. Para tener el control adecuado de los perfiles de los
usuarios y niveles de seguridad se suelen crear varios casos de uso
que manipulan este tipo de documento.
En caso de agregar:
Registrar/Generar <Nombre del documento formal>
Por ejemplo: Generar Factura, Generar Contrato.
En caso de modificar o eliminar depender del documento y de cmo
es tratado en la organizacin. Por ejemplo:
Para eliminar una factura se creara el caso de uso Anular Facturar
que registra el motivo de la anulacin y que cambia el estado de la
factura a anulada y para modificar una factura se crear el caso de
uso Generar Nota de Crdito, ya que legalmente una factura no se
puede modificar sin un documento que sustente el cambio.
Para el tratamiento de la bsqueda de informacin.

Buscar/Consultar <Informacin a buscar>
Por ejemplo: Buscar Productos, Consultar Clientes.
CIBERTEC
96
Para el tratamiento de la verificacin de la informacin, la cual retorna

un valor de verdadero o falso dependiendo de si encontr o no la
informacin.
Verificar/Validar <informacin a verificar>
Por ejemplo: Verificar Existencia de Producto, Validar Existencia de
Usuario.
Para el tratamiento de documentos informales o de uso interno, el cual

incluye las opciones de mantenimiento en un slo caso de uso.
Gestionar/Administrar <Nombre del documento informal>
Por ejemplo: Administrar Cotizacin, Gestionar Nota de Pedido.
Es necesario aclarar que si uno de los documentos informales origin
un documento formal ya no se puede modificar o anular. Por ejemplo,
una cotizacin que se aprueba y genera una factura ya no podra
modificarse o anularse.
1.2 Breve descripcin

Debera ser un solo prrafo que resuma el objetivo del caso de uso.
1.3 Actores
Desde el punto de vista de un caso de uso especfico, existen dos tipos de actores:
Actores primarios o principales: Activan el caso de uso.
Actores secundarios: Interactan con el caso de uso despus de

haberse activado.
1.4 Flujo de eventos

Es una secuencia enumerada de pasos que describe la interaccin del actor con el
caso de uso. Incluye: Flujo bsico, subflujos y flujos alternativos.
1.4.1 Flujo bsico
Es el flujo principal del caso de uso y presenta las siguientes reglas:
a) El primer paso
Empieza por el actor primario haciendo algo para activar el caso de
uso. As:
1. El Caso de uso se inicia cuando <actor> <funcin>
Por ejemplo:
1. El Caso de uso se inicia cuando la Recepcionista
selecciona la opcin Generar Reserva en la
interfaz del men principal.
Si el tiempo es el actor, se empieza as:
1. El Caso de uso se inicia cuando es el fin de
semana.
Si el caso de uso es abstracto, comienza as:
CIBERTEC
97
1. El Caso de Uso se inicia cuando es invocado por

otro caso de uso base.
b) Centrase en el qu, no en el cmo
Mantenga los detalles de diseo fuera del caso de uso.
Por ejemplo, el siguiente paso es incorrecto.
5. El Cliente pulsa el botn Aceptar.
La mejor forma de expresar ese paso es la siguiente:
4. El Cliente selecciona Aceptar Pedido.
c) Referencia a un caso de uso incluido
Para especificar la invocacin a un caso de uso incluido se utiliza la
siguiente expresin:
El sistema Incluye el CU Buscar Habitacin.
Por ejemplo:
7. La recepcionista solicita Buscar Habitaciones
disponibles.
8. El sistema Incluye el CU Buscar Habitacin.
d) Ramificacin dentro de un flujo
Para indicar una ramificacin en el flujo se utiliza la palabra Si. La
condicin sujeta puede llevar a un conjunto de sub-acciones
(desviaciones simples) o a un subflujo (desviaciones complejas).
El siguiente ejemplo utiliza ramificaciones.
5. Si la Recepcionista elige un cliente
a. Si selecciona Modificar ver el Subflujo
Modificar Cliente
b. Si selecciona Eliminar ver el Subflujo
Eliminar Cliente.
e) Repeticin dentro de un flujo
Para indicar la repeticin de un conjunto de acciones se utiliza al
final de la accin la siguiente expresin:
Si <actor> <funcin>, repite los pasos del <X1> al <X2>.
Por ejemplo:
...
7. La recepcionista solicita Buscar Habitaciones
disponibles.
8. El sistema Incluye el CU Buscar Habitacin.
9. El sistema muestra las habitaciones disponibles.
10. La Recepcionista ingresa la cantidad de personas
para la habitacin seleccionada.
11. El sistema valida la cantidad de personas
ingresada.
12. El sistema calcula y muestra el subtotal del
precio a pagar y el monto total.
CIBERTEC
98
13. Si la Recepcionista quiere seleccionar

habitacin, repite los pasos del 7 al 12.
...
otra
1.4.2 Subflujos
Es opcional en un caso de uso. Pueden presentarse varios subflujos y
cada uno de ellos sigue las mismas reglas del flujo bsico.
1.4.3 Flujos alternativos
Son rutas de acceso alternativas a travs del caso de uso que capturan
errores, ramificaciones e interrupciones en el flujo principal. En la figura
11.1 se ilustran los caminos posibles de una instancia de caso de uso
(escenario).
11.1. Caminos del Flujo de eventos.

A continuacin se muestra dos flujos alternativos para el caso de uso
Generar Orden de Reparacin.
<Automvil no Registrado>
En el punto 8, si el sistema verifica que el Automvil no
est registrado muestra el MSG Automvil no registrado,
la Secretaria puede ir a Registrar Automvil y continuar
con el paso 9.
<Cancelar>
Si la Secretaria solicita Cancelar antes de Grabar la
Orden de Reparacin, el sistema cierra la interfaz y el
caso de uso finaliza.
1.5 Precondiciones
Restringen el estado del sistema antes de que el caso de uso pueda empezar. Si un
caso de uso no tiene ninguna precondicin se debera escribir Ninguna. Por
ejemplo:
1. El Recepcionista est logeado en el sistema.
2. Lista de Clientes disponibles.
3. Lista de Habitaciones disponibles.
1.6 Poscondiciones
Restringen el estado del sistema despus de que el caso de uso se ha ejecutado. Si
un caso de uso no tiene ninguna poscondicin se debera escribir Ninguna. Por
ejemplo:
CIBERTEC
99
1. En el sistema queda registrado la reserva con su

detalle.
2. Las habitaciones seleccionadas se actualizan al estado
Reservadas.
1.7 Puntos de extensin

Se utiliza para hacer referencia a un caso de uso extendido. Pueden existir varios
puntos de extensin. Por ejemplo:
En el paso 5, el sistema extiende al caso de uso Mantener
Clientes Flujo bsico Agregar Cliente.
1.8 Requisitos especiales

En esta seccin se especifican los requisitos no funcionales asociados a este caso de
uso. A continuacin se muestra un requerimiento fsico para el caso de uso Generar
Factura:
Contar con Formato especial para imprimir las facturas,
con el Logo de la empresa.
1.9 Prototipos
En esta seccin se muestran las interfaces grficas de usuario diseadas para el caso
de uso. No es relevante mostrar las interfaces de los mensajes de advertencias o
error.
Ejemplo de especificacin de casos de uso
Especificacin de caso de uso: Generar Reserva de

Habitacin
1. Breve Descripcin
El caso de uso permite a la Recepcionista de un Hotel generar una reserva de
habitacin(es).Adems de saber en qu estado se encuentra la habitacin:
reservado, ocupado o disponible.
2. Actor(es)
Recepcionista
3. Flujo de Eventos
3.1. Flujo Bsico
1.
El Caso de uso se inicia cuando la Recepcionista selecciona la opcin

Generar Reserva en la interfaz del men principal.
2.
El sistema muestra la interfase RESERVA con los siguientes datos:

Datos del cliente: Cdigo y Nombres y Apellidos.
Datos de la Reserva: fecha de la reserva y cantidad de das a hospedarse.
CIBERTEC
100
Datos de las habitaciones: Nmero de habitacin, Tipo, Categora,

capacidad, monto por da, Sub Total y Monto Total.
Adems incluye las opciones: Buscar Cliente, Buscar Habitaciones,
Agregar, Eliminar, Grabar Reserva y Salir.
3.
La Recepcionista selecciona Buscar Cliente.
4.
El sistema Incluye el CU Buscar Cliente.
5.
El sistema muestra los datos del cliente.
6.
La recepcionista ingresa la fecha de reserva y cantidad de das.
7.
La recepcionista solicita Buscar Habitaciones disponibles.
8.
El sistema Incluye el CU Buscar Habitacin.
9.
El sistema muestra datos de habitacin disponible.
10. La Recepcionista ingresa la cantidad de personas para la habitacin

seleccionada y selecciona Agregar.
11. El sistema valida la cantidad de personas ingresada.
12. El sistema calcula y muestra subtotal y monto total a pagar.
13. Si la Recepcionista quiere seleccionar otra habitacin, se repite del paso 7
al 12.
14. La Recepcionista selecciona Grabar Reserva.
15. El sistema autogenera un nmero de reserva.
16. El sistema graba la reserva con su detalle y actualiza la(s) habitacin(es)
en estado Reservado.
17. El sistema muestra el nmero de reserva y el MSG Reserva generada
con el Nro. 99999.
18. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del
men principal del sistema y finaliza el caso de uso.
3.2. Subflujos
Ninguno.
3.3. Flujos Alternativos
<Cliente no existe>
En el paso 5, si el sistema detecta que el cliente no existe muestra el MSG:
Cliente no existe y ofrecer la posibilidad de registrar al nuevo cliente.
CIBERTEC
101
<Habitaciones no disponibles>
En el paso 9, si el sistema detecta que no hay habitaciones disponibles
muestra el MSG: No hay habitaciones disponibles y finaliza el caso de uso.
<Cantidad de Personas incorrecta>
En el paso 12, si la Recepcionista ingres una cantidad mayor a la capacidad
de la habitacin seleccionada, el sistema muestra el MSG Ingrese una
cantidad de personas menor o igual a la capacidad de la habitacin y contina
con el paso 10.
<Eliminar habitacin>
Si la Recepcionista solicita Eliminar una habitacin seleccionada, antes de
Grabar, el sistema lo borra del detalle y el caso de uso contina en el paso 13.
4. Precondiciones
4.1. El Recepcionista est logueado en el sistema.
4.2. Lista de Clientes disponibles.
4.3. Lista de habitaciones disponibles.
5. Pos condiciones
5.1. En el sistema queda registrado la reserva con su detalle.
5.2. Las habitaciones seleccionadas se actualizan en estado Reservadas.
6. Puntos de Extensin
En el paso 5, el sistema extiende al caso de uso Mantener Clientes Flujo bsico
Agregar Cliente.
7. Requisitos Especiales
Ninguno.
CIBERTEC
102
8. Prototipos
CIBERTEC
103
3.3.5. Priorizacin de casos de uso

Es la actividad de arquitectura y planificacin de proyecto el cual consiste en clasificar
los casos de uso segn su importancia para establecer el orden de realizacin de los
mismos. En este sentido, los casos de uso con significado arquitectnico se identifican
y se priorizan. Una vez que se han priorizado los casos de uso, se puede decidir el
orden de desarrollo del sistema.
Se establecen perodos, ciclos o iteraciones de trabajo para desarrollar la realizacin
de los casos de uso. Se distribuyen los casos de uso en cada ciclo de trabajo; los
casos de uso primarios deben realizarse en primer orden y, luego, los secundarios.
Los casos de uso opcionales se deben dejar para el final de la realizacin.
3.3.5.1. Objetivos
El propsito de la priorizacin de los USE CASE es identificar los casos de uso
primarios para la presente etapa de desarrollo del proyecto. Segn estos criterios, se
determinan los casos de uso crticos para especificarlos en esta etapa del proyecto.
3.3.5.2. Alcance
La priorizacin permitir darle la debida atencin (y con mas tiempo) a los USE CASE
ms complejos e importante.
3.3.5.3. Priorizacin
Distingue a los USE CASE crticos o primarios de los secundarios. Ms adelante, se
especifica el criterio utilizado para determinar cules son primarios y cules son
secundarios.
o Nivel crtico (o primario)
Agrupa a los USE CASE que tienen que ver con las funciones bsicas
del sistema.
o 3.2. Nivel de baja importancia (o secundario)
Agrupa a los USE CASE que tienen que ver con las funciones de
soporte del sistema y que no representan mayor riesgo para el
proyecto.
3.3.5.4. Factores tomados en cuenta en la priorizacin
Se tomaron en cuenta pesos (que representan porcentaje) por cada factor que afecta
a cada USE CASE. Los valores que pueden tomar los factores estn en la escala del 1
al 10 (1: menor importancia; 10: mayor importancia). Se considerarn primarios a
aquellos USE CASE que tengan un puntaje mayor a 6.5, ya que esto significa que
superan el 65% de prioridad en el sistema (PONDERACIN).
Importancia en el proceso del negocio: indica la relevancia que tiene la

funcionalidad con el proceso de negocio. Una alta puntuacin revela que las
transacciones de la empresa se apoyan considerablemente en la funcionalidad
que tiene este USE CASE. Su ponderacin es 0.4.
Complejidad de desarrollo: Indica la dificultad que se percibe del USE CASE, en
cuanto a las tareas de anlisis, diseo, implementacin, pruebas e integracin del
mismo. Su ponderacin es 0.3.
CIBERTEC
104
Riesgo asociado: Indica la relacin que se percibe entre el USE CASE y la lista
de riesgos. Un alto valor en este factor indica que el caso de uso tiene bastantes
riesgos o riesgos de alto valor asociados. Los USE CASE con alto valor en este
factor pueden ser considerados primarios debido a que deben ser enfrentados en
las etapas iniciales. Su ponderacin es 0.2.
Impacto de los requerimientos no funcionales: Indica cmo afectan los
requerimientos no funcionales (usability, reliability, performance, supportability) al
proceso del negocio y en qu manera el USE CASE se vera comprometido. Su
ponderacin es 0.1.
EJEMPLO DE PRIORIZACION DE LOS CASOS DE USO LACTEOS LA LUZ

I. A continuacin se muestra los Subsistemas de Lcteos La Luz, de acuerdo a sus
objetivos y tareas.
SUBSISTEMAS
Servicios al cliente
Gestin de ventas
Tareas del despachador
Tareas ejecutivas.
A. Servicios al cliente
1. Registrar cliente
2. Elaborar pedido
3. Rastrear pedido
4. Consultar cuenta
5. Acusar recibo / reclamo
Importancia
en el
proceso del
negocio
Registrar cliente
10
Elaborar pedido
9
Rastrear pedido
6
Consultar
9
cuenta
Acusar recibo
5
/reclamo
Complejidad
de desarrollo
Riesgo
asociado
Impacto de
requerimientos
no funcionales
Total
6
7
8
8
9
7
5
6
9
9
8
9
8.5
8
6.75
8
B. Gestin de ventas
1. Aceptar / Rechazar pedido
2. Facturar pedidos
3. Actualizar cuenta
4. Consolidar pedido
5. Ordenar produccin
CIBERTEC
Aceptar
/Rechazar
pedido
Facturar
pedidos
Actualizar
cuenta
Consolidar
pedido
Ordenar
produccin
105
Importancia
en el
proceso del
negocio
8
Complejidad
de desarrollo
Riesgo
asociado
Impacto de
requerimientos
no funcionales
Total
8.25
8.5
10
7.5
C. Tareas del despachador

1. Configurar despachos
2. Rastrear pedido
3. Configurar embalaje
4. Configurar ruta
5. Acusar recibo / reclamo
6. Devolver mercanca
Configurar
despachos
Rastrear pedido
Configurar
embalaje
Configurar ruta
Acusar recibo /
reclamo
Devolver
mercanca
Importancia
en el
proceso del
negocio
9
Complejidad
de desarrollo
Riesgo
asociado
Impacto de
requerimientos
no funcionales
Total
7
8
6
8
7
7
6
7
6.5
7.5
7
4
6
5
8
7
6
6
6.75
5.5
5.25
D. Tareas Ejecutivas
1. Obtener informacin de productos
2. Evaluar el desempeo de productos
3. Generar informe
Obtener
informacin de
productos
Evaluar el
desempeo de
productos
Generar
informe
CIBERTEC
Importancia
en el
proceso del
negocio
8
Complejidad
de desarrollo
Riesgo
Asociado
Impacto de
requerimientos
no funcionales
Total
7.75
7.25
106
II. Luego de haber priorizado cada subsistema, se agrupa por iteraciones, esta
agrupacin consiste en tomar los 3 CU ms importantes del subsistema (con
mayor ponderacin). Ests iteraciones debern ser desarrolladas en la fase de
construccin del proceso del sistema.
A. Servicios al cliente
Iteracin 1
Registrar cliente
Consultar cuenta
Elaborar pedido
Iteracin 2
Rastrear pedido
Acusar Recibo / Reclamo
B. Gestin de ventas
Iteracin 1
Actualizar cuenta
Facturar pedidos
Consolidar pedido
Iteracin 2
Ordenar roduccin
Aceptar / Rechazar Pedido
C. Tareas del despachador
Iteracin 1
Configurar embalaje
Configurar despacho
Configurar ruta
Iteracin 2
Rastrear pedido
Devolver mercanca
Acusar Recibo / Reclamo
8.5
8
8
6.75
5
8.5
8.2
7.5
6
5
7.5
7
6.75
6.5
5.25
D. Tareas ejecutivas
Iteracin 1
Evaluar desempeo del producto 7.75
Generar informe
Obtener informacin de productos 7
5.5
7.25
Nota.- Requerimientos primarios sern aquellos que presenten un puntaje mayor a 6.5.
CIBERTEC
107
Resumen
El Modelado de casos uso nos permite representar las funcionalidades del
sistema a implementar.
El Modelo de casos de uso contiene a los actores y casos de uso, que son los
artefactos relevantes del modelo.
En el Modelo de casos de uso se crean los siguientes diagramas:
Diagrama de actores
Diagrama de casos de uso por proceso de negocio
Existen tres relaciones entre casos de uso: Generalizacin, include y extend.
La generalizacin tambin se puede dar entre actores.
En una relacin de generalizacin, el caso de uso hijo hereda la estructura,
comportamiento y las relaciones del padre.
En una relacin include, el caso de uso incluido encapsula el comportamiento
necesario y reutilizado por varios casos de uso base.
En una relacin extend, el caso de uso extendido encapsula el
comportamiento opcional de un caso de uso base.
CIBERTEC
108
CASOS PCTICOS
Caso N1: Limpia Total S.A.

Limpia Total S.A. es una empresa especializada en servicios de limpieza integral
mantenimiento y servicios complementarios, labor que desarrolla en forma profesional
y acorde con los requerimientos de sus clientes para que estos puedan delegar a
terceros los servicios y as dedicarse plenamente a su negocio. Esta compaa espera
para el ao 2008 ser la nmero 1 en los servicios de limpieza y espera lograrlo a
travs de un control total de los gastos del servicio y un control total en la distribucin
del trabajo de los empleados.
La empresa tiene en su equipo comercial la difcil tarea de obtener contratos de
servicios de limpieza, esta tarea se inician cuando un cliente se pone en contacto con
la empresa, Es atendido por un vendedor quien le genera una cotizacin, verifica
previamente si el cliente se encuentra registrado. si no se encuentra lo registrara en el
sistema. Posteriormente el vendedor trata de concretar la aprobacin de la cotizacin,
cuando el cliente acepta las condiciones el supervisor de Ventas registra el contrato,
obteniendo previamente los datos de la Cotizacin registrada. Todos los contratos son
entregados al Gerente General, quien evala cada contrato y registra el resultado de la
evaluacin, previamente realizo una bsqueda de contratos. .El Supervisor de ventas
tiene una consulta detallada de todas las cotizaciones, debiendo realizar una
bsqueda de cotizaciones adems el Supervisor puede actualizar los datos de los
clientes.
El Gerente General entrega copias de los contratos al departamento de cobranza, la
secretaria de cobranza emite los Comprobante de pagos (Facturas), previamente
realizo una bsqueda de contratos. Todos los Viernes la Secretaria Genera las Hojas
de Ruta de Cobranza, en esta hoja se asigna un cobrador a cada Comprobante
emitido, previamente realizo una bsqueda de comprobantes. La Secretaria entrega la
Hoja de Ruta y los comprobante de pago asignados (Factura) a cada cobrador, al final
del da el cobrador entrega la Hoja de Ruta, los comprobantes de pago(Facturas) y el
Voucher del depsito de la cuenta bancaria a la secretaria; quien registra el pago de
los comprobantes de pago(Facturas). Previamente realizo una bsqueda de
comprobantes. Adicionalmente la secretaria de cobranza puede actualizar los datos de
los clientes como telfono, correo, direccin, etc.
CIBERTEC
109
Caso N2: Automotriz El Chasqui.

La importadora Automotriz Chasqui es una prestigiosa empresa de venta de vehculos
de transporte de pasajeros de la marca JAC esta empresa es distribuidor exclusivo en el
PERU y tiene como visin para el ao 2011 convertirse en la empresa lder en la venta de
vehculos de pasajeros, para ello tiene como meta a corto plazo contratar a vendedores A1
para su equipo de ventas y abaratar en 10% los costos de importacin de los vehculos por
reduccin del flete.
Diariamente los clientes se apersonan a los locales de la empresa a consultar los precios
de los vehculos, e informndoles que le empresa les puede poner en contacto con varios
bancos, para ello si est interesado debe de llenar una solicitud de crdito y traer la
documentacin solicitada tales como, copia de DNI, boleta de pago, etc., Cuando ya lleno
la solicitud el vendedor registrara en el sistema la solicitud, verificando previamente si el
cliente se encuentra registrado, si no se encontrase deber de regstralo en el sistema,
registrando la solicitud como por aprobar. Posteriormente el Jefe de ventas ingresara al
sistema para aprobar o cancelar la solicitud segn el status de verificacin del cliente;
previamente se realiz la bsqueda de la solicitud. Si la solicitud fue aprobada se le informa
al cliente que deber de hacer el pago del 20% del valor del automvil en caja. El cajero
ingresara al sistema para generar el comprobante de pago de la cuota inicial; y le
generara el calendario de pago de las cuotas pactadas. Previamente verifico el status de la
solicitud como aprobada para aceptar el pago.
Otro Servicio de la empresa es el mantenimiento de los vehculos en el taller, el cliente

llevara su vehculo para su mantenimiento. El asistente del taller ingresara al sistema
una solicitud de servicio, verificando previamente si el cliente se encuentra registrado,
si no se encontrase deber de regstralo en el sistema, registrando la solicitud como
por atender. Despus de que el servicio fue dado el cliente se acercara al rea de
facturacin, el cajero tomara toda la informacin del sistema valindose de la solicitud
de servicio y verificando todo los servicios que se le dio al auto generando el
comprobante de pago correspondiente y registrando la solicitud como cancelada
CIBERTEC
110
Glosario
Artefacto
Pieza discreta de informacin que es utilizada o producida por un proceso de
desarrollo de software.
Caso de uso abstracto
Un caso de uso es abstracto slo si se instancia en el contexto de otro caso de uso, es
decir, dependen de otro caso de uso para instanciarse puesto que no existe un actor
que lo active.
Caso de uso concreto
Un caso de uso es concreto si es iniciado por un actor y constituye un completo flujo
de eventos. "Completo" significa que una instancia del caso de uso lleva a cabo toda la
operacin solicitada por el actor.
Condicin de guardia
Condicin que se debe satisfacer para permitir que se dispare una transicin asociada.
Es utilizado en Diagrama de actividades a partir de un control de decisin.
CASE Computer Aided Software Engineering
Ingeniera de Software asistida por computadora.
Diagrama
Representacin grfica de un conjunto de elementos, representado en la mayora de
casos como un grafo conexo de nodos (elementos) y arcos (relaciones).
Diagrama de actividades
Diagrama que muestra el flujo de control datos entre actividades. Cubren la vista
dinmica de un sistema.
Diagrama que representa procesos de negocio o funcionalidades del sistema y
externos.
Diagrama de clases
Muestra un conjunto de clases y sus relaciones.
Diagrama de componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes
(elementos de implementacin) del sistema.
Diagrama de comunicacin
Diagrama de interaccin que resalta la organizacin estructural de objetos que envan
y reciben mensajes.
CIBERTEC
111
Diagrama de despliegue
Muestra la configuracin en tiempo de ejecucin de los nodos de procesamiento y
dispositivos que componen una red.
Diagrama de estados
Representa los estados potenciales de los objetos y las transiciones entre esos
estados.
Diagrama de objetos
Muestra un conjunto de objetos y enlaces en un momento dado.
Diagrama de Secuencia
Diagrama de interaccin que resalta la secuencia temporal de los mensajes entre
objetos.
Elemento
Constituyente atmico de un modelo.
Escenario
Secuencia especfica de acciones que ilustra un comportamiento.
Especificacin
Descripcin textual de la sintaxis y la semntica de un bloque de construccin
especfico; descripcin declarativa de lo que algo es o hace.
Estereotipo
Extensin del vocabulario de UML que permite crear nuevos bloques de construccin
derivados a partir de los existentes pero especficos a un problema concreto.
Herramienta CASE
Aplicacin informtica destinada a aumentar la productividad en el desarrollo de
software reduciendo el coste de las mismas en trminos de tiempo y de dinero.
Instancia
Manifestacin concreta de un bloque de construccin de UML.
Modelo
Un modelo es una representacin de un sistema o aplicacin. Un modelo UML es un
modelo que utiliza la notacin del Lenguaje Unificado de Modelado para representar
grficamente un sistema en distintos niveles de abstraccin.
Notacin
Sistema de signos convencionales que se adoptan para expresar un conjunto de
conceptos sobre el sistema de software por desarrollar.
OMG Object Management Group
Consorcio del cual forman parte las empresas ms importantes que se dedican al
desarrollo de software.
OMT Object-Modeling Technique
Es un mtodo para el modelado orientado a objetos, creado por James Rumbaugh,
que dio mayor nfasis a las notaciones grficas para el anlisis orientado a objetos.
CIBERTEC
112
OOSE Object-Oriented Software Engineering

Es un mtodo de ingeniera de software orientado a objetos, creado por James
Rumbaugh. Ha sido llamado un enfoque para el manejo de casos de uso, en este
enfoque el modelo de casos de uso sirve como un modelo central del cual todos los
otros modelos son derivados.
Perfiles UML
Constituyen el mecanismo que proporciona el UML para extender su sintaxis y su
semntica para expresar los conceptos especficos de un determinado dominio de
aplicacin.
Refinamiento
Relacin que representa una especificacin ms completa de algo que ya ha sido
especificado a cierto nivel de detalle.
Requisito
Caracterstica, propiedad o comportamiento deseado de un sistema.
RSA Rational Software Architect
Herramienta CASE de diseo y construccin para arquitectos de software y
desarrolladores snior para crear aplicaciones en la plataforma Java o en C++.
Permite un desarrollo basado en modelos con el lenguaje UML y unifica todos los
aspectos de la arquitectura de la aplicacin de software.
RUP Rational Unified Process
Proceso Unificado de Rational, metodologa del proceso de ingeniera de software que
proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de
una organizacin del desarrollo.
Stakeholder
Personas u organizaciones que estn directamente involucradas en la elaboracin o
tomas de decisiones claves acerca de la funcionalidad y propiedades de un sistema
software.
UML Unified Modeling Language
Lenguaje unificado de modelado, notacin estndar para el modelado de sistemas
Software.
Workspace
Es un directorio que representa el espacio de trabajo y el cual contendr los proyectos
que se crean en la herramienta RSA.
CIBERTEC

Teoria Ads

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Teoria Ads

Transféré par

Droits d'auteur :

Formats disponibles

Anlisis y Diseo

ANLISIS Y DISEO DE SISTEMAS I

: Ingeniera de Software, Metodologa RUP y UML

1.1.1. : Elementos claves de la Ingeniera de Software

1.1.2. : Las fases genricas de un proceso de software

1.1.3. : Modelos de Proceso de Software

1.1.4. : Metodologa RUP (Rational Unified Process -RUP)

: Mejores Prcticas de RUP

1.1.6. : Estructura de RUP

1.1.7. : Modelamiento Visual empleando el (UML)

1.1.8. : El Lenguaje de Modelamiento Unificado

1.1.9. : Diagramas de UML 2.0

: Herramienta Case y Entorno de IBM RSA

1.2.1. : Objetivos de las herramientas C.A.S.E.

1.2.2. : Tipos de herramientas C.A.S.E.

1.2.3. : Ejemplos de herramientas C.A.S.E.

1.2.4 : Rational Software Architect

: Modelado del Negocio

2.1.1. : Cundo ser necesario hacer el Modelado de Negocio?

2.1.2. : Cundo no ser necesario hacer el Modelado de Negocio?

2.1.3. : Actividades para realizar un Modelado de Negocio

: Modelo de Casos de uso del Negocio

2.2.1. : Determinar la situacin de la organizacin

2.2.2. : Identificar los procesos de negocio

2.2.3. : Refinar las definiciones de los procesos de negocio

2.2.4. : Artefactos del Modelo de Casos de uso del negocio

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

: Modelo de Anlisis de Negocio

2.3.1. : Disear las realizaciones de los procesos de negocio

2.3.2. : Artefactos del Modelo de Anlisis del negocio

3.1.1. : Artefactos de la Captura de Requisitos

Actividades para realizar la Captura de Requisitos

Tcnicas para capturar requisitos

3.1.6. : Captura de requisitos a solicitud del cliente

3.1.7. : Captura de requisitos a partir del diagrama de actividades del

3.2.1. : Encontrar actores y casos de uso

3.2.3. : Encontrar casos de uso

Crear el Diagrama de casos de uso

Casos de uso abstractos y concretos

3.3.4. : Especificaciones de casos de uso

3.3.5. : Priorizacin de los Casos de Uso

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

El curso es terico prctico: consiste en un taller de desarrollo de proyectos de

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

Anlisis y Diseo de Sistemas I

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

Ingeniera de Software, Metodologa RUP y UML

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

1.1 TEMA 1: INGENIERA DE SOFTWARE

Figura 1.1.- Capas de la Ingeniera de Software segn Roger Pressman.

El fundamento de la ingeniera del software es la capa de proceso. El proceso de la

DRAE, Diccionario de la Real Academia Espaola de la Lengua.

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS

ANLISIS Y DISEO DE SISTEMAS I

Los mtodos de la ingeniera del software indican cmo construir tcnicamente el

1.1.1. Elementos claves de la Ingeniera de Software

CARRERA DE COMPUTACIN E INFORMTICA Y ADMINISTRACIN Y SISTEMAS