Análisis y Diseño de

Sistemas I
 

ANÁLISIS Y DISEÑO DE SISTEMAS I 2

Curso Análisis y Diseño de Sistemas I (2392)

Formato Manual de curso
Autor Institucional Cibertec
Páginas 134 p.
Elaborador Pérez Vega, Saúl Mateo
Revisor de Contenidos De La Cruz Mercado, Ronald Stevens

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 3

Índice
Presentación 5
Red de contenidos 7

UNIDAD DE APRENDIZAJE 1: INTRODUCCIÓN A LA INGENIERÍA DE SOFTWARE 

SOFTWARE  9

1.1 Tema 1 : Ingeniería de Software, RUP y UML 11

1.1.1 : Elementos claves de la Ingeniería de Software 13
1.1.2 : Fases de un proceso de software 14
1.1.3 : Modelos de Proceso de Software 16
1.1.4 : Metodología RUP (Rational Unified Process) 22
1.1.5 : Metodología AUP (Agile Unified Process) 23
1.1.6 : Mejores Prácticas de RUP 24
1.1.7 : UML (Lenguaje de Modelamiento Unificado) 30
1.1.8 : Diagramas de UML 2.5 33

1.2 Tema 2 
2  : Herramientas CASE 
CASE  39
1.2.1 : Objetivos de las herramientas CASE 39
1.2.2 : Tipos de herramientas CASE 39
1.2.3 : Ejemplos de herramientas CASE 39

UNIDAD DE APRENDIZAJE 2: DISCIPLINA DE MODELADO DE NEGOCIO 

NEGOCIO  45

2.1 Tema 3 : Modelado de Negocio 47

2.1.1 : ¿Cuándo es necesario realizar el Modelado de Negocio? 47
2.1.2 : ¿Cuándo no es necesario realizar el Modelado de Negocio? 48
2.1.3 : Actividades para realizar un Modelado de Negocio 48

2.2 Tema 4 : Modelo de Casos de Uso del Negocio - MCUN 51

2.2.1 : Determinar la situación de la organización 51
2.2.2 : Identificar los procesos de negocio 51
2.2.3 : Redefinición de los procesos de negocio 51
2.2.4 : Artefactos del Modelo de Casos de Uso de Negocio 52

Caso propuesto del Modelo de Casos de Uso del Negocio. Caso: Chasqui
2.3 Tema 5 : 53
Express S.A.
2.3.1 : Solución del caso en Rational Software Architect 55
2.3.2 : Solución del caso en Enterprise Architect - Sparx 57

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 4

2.4 Tema 6 : Modelo de Análisis del Negocio - MAN 61

2.4.1 : Diseño de realizaciones de procesos de negocio 61
2.4.2 : Artefactos del Modelo de Análisis de Negocio: Plantilla MAN 61

2.5 Tema 7 : Caso Propuesto de MCUN y MAN 63

2.5.1 : Caso: Chasqui Express S.A. - Solución en Rational Software Architect 63

2.5.2 : Caso: Calidad Educativa - Solución en Rational Software Architect 67
2.5.3 : Caso: Calidad Educativa - Solución en Enterprise Architect – Sparx 72
2.5.4 : Otros casos propuestos 74

UNIDAD DE APRENDIZAJE 3: DISCIPLINA DE LA CAPTURA DE REQUISITOS 77

3.1 Tema 8 : Captura de Requisitos 79

3.1.1 : Importancia de la Captura de Requisitos 79
3.1.2 : Dificultades de la captura de Requisitos 79
3.1.3 : Artefactos de la Captura de Requisitos 80

3.1.4 : Actividades para realizar la Captura de Requisitos 81

3.1.5 : Requisitos FURPS+ 84
3.1.6 : Técnicas para capturar requisitos 88
3.1.7 : Experiencia de usuario (UX Design) 92
3.1.8 : Captura de requisitos a solicitud del cliente 94
Captura de Actividades a partir del Diagrama de Actividades de Negocio -
3.1.9 : 95
Caso: El Pirata: Plantilla de MCU

3.2 Tema 9 : Modelo de Casos de Uso 105

3.2.1 : Identificación de Actores 106
3.2.2 : Identificación de Casos de Uso 109
3.2.3 : Crear el Diagrama de Casos de Uso - Caso: El Pirata 111

3.3 Tema 10 : Estructurando el Modelo de Casos de Uso 117

3.3.1 : Objetivos 117
3.3.2 : Tipos de relaciones 118
3.3.3 : Casos de Uso Abstractos y Concretos 121
3.3.4 : Especificación de Casos de Uso -ECU 125
3.3.5 : Priorización de Casos de Uso 126

Bibliografía 134

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 5

Presentación
Análisis y Diseño de Sistemas I (ADS-I) es un curso que pertenece a la línea formativa. Se dicta
en la carrera profesional de “Computación e Informática”. Este curso imparte conocimientos
relacionados con proceso de la Ingeniería de Software que permite a los alumnos utilizar una
metodología y el Lenguaje de Modelamiento Unificado (UML) para desarrollar un software de
calidad.

El manual para el curso

c urso ha sido diseñado bajo la modalidad de unidades de aprendizaje, las que
se desarrollan durante un número determinado de semanas. En cada una de ellas, se indica: (1)
los logros que se busca alcanzar al término de cada unidad, (2) el tema tratado y (3) los
contenidos del tema a tratar. Asimismo, al final de cada unidad se encontrará actividades que
permitirán afianzar los conocimientos adquiridos en cada sesión de clase.

El curso es teórico-práctico. Este consiste en un taller de desarrollo de proyectos de software.

En primer lugar, se inicia con la comprensión de la Ingeniería de Software y el proceso de
desarrollo de software utilizando la metodología RUP. Continúa con lal a presentación del 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.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 6

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 7

Red de contenidos

ANÁLISIS Y DISEÑO DE SISTEMAS I

INTRODUCCIÓN A LA INGENIERÍA DE
SOFTWARE
• In
Inggenier
niería
ía de Soft
Softw
war
aree, RUP y UM
UMLL
• Herr
Herramie
amienta
ntass CASE

DISC
DISCIP
IPLI
LINA
NA DE MODE
MODELA
LADO
DO DE NEGO
NEGOCI
CIO
O
• Mode
Modela
lado
do de Ne
Nego
goci
cio
o
• Modelo de Casos de Uso del Negocio - MCUN
• Caso propuesto del Modelo de Casos de Uso
del Ne
del Nego
goci
cio.
o. Ca
Caso
so:: Ch
Chas
asqu
quii Ex
Expr
pres
esss S.A.
S.A.
• Mod
odeelo de Anál
Anális
isis
is de
dell Neg
egoc
ocio
io - MA
MAN N
• Cas
asoo Propuesto de MCUN y MAN

DISCIPLINA DE LA CAPTURA DE
REQUISITOS
• Captur
Capturaa de Re
Requi
quisit
sitos
os
• Modelo de Casos de Uso
• Es
Estr
truc
ucttur
uran
ando
do el Mod
odeelo de Ca
Caso
soss de Uso

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 8

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 9

UNIDAD 

1
INTRODUCCIÓN A LA INGENIERÍA DE
SOFTWARE
LOGRO DE LA UNIDAD DE APRENDIZAJE 
Al término de la unidad, el alumno es capaz de identificar las ventajas y desventajas de
los modelos de procesos de software, y la importancia de emplear una metodología de
desarrollo de Software (RUP) y AUP. Finalmente, el alumno es capaz de elaborar los
diagramas UML y se familiariza en el uso de Herramientas CASE.

TEMARIO 

1.1 Tema 1 : Ingeniería de Software, RUP y UML

1.1.1 : Elementos claves de la Ingeniería de Software
1.1.2 : Fases de un proceso de software
1.1.3 : Modelos de Proceso de Software
1.1.4 : Metodología RUP (Rational Unified Process)
1.1.5 : Metodología AUP (Agile Unified Process)
1.1.6 : Mejores Prácticas de RUP
1.1.7 : UML (Lenguaje de Modelamiento Unificado)
1.1.8 : Diagramas de UML 2.5

1.2 Tema 2 
2  : Herramientas CASE 
CASE 
1.2.1 : Objetivos de las herramientas CASE
1.2.2 : Tipos de herramientas CASE
1.2.3 : Ejemplos de herramientas CASE

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 10

ACTIVIDADES PROPUESTAS 

   Los alumnos resuelven un caso para aplicar los Diagramas UML.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 11

1.1.   TEMA 1: INGENIERÍA DE SOFTWARE, RUP y UML

1.1.
Según la RAE1, ingeniería
ingeniería  es el “conjunto de conocimientos orientados a la invención
i nvención y utilización
de técnicas para el aprovechamiento de los recursos naturales o para la actividad industrial”,
también es la “actividad profesional del ingeniero”. Por otro lado, el término ingeniero
ingeniero   es
definido como “Persona con titulación universitaria superior que la capacita para profesar la
ingeniería en alguna de sus ramas”.

Por otro lado, la RAE también define al software

software  como el “conjunto de programas, instrucciones
y reglas informáticas para ejecutar ciertas tareas en una computadora”. 

Uniendo ambas definiciones, se puede establecer que la ingeniería de software es el “uso o

aplicación de conocimientos y técnicas científicas para crear programas de computadora”.  

Se ha elegido la definición utilizada por Roger Pressman, quien indica que la ingeniería de
software es una tecnología multicapa. Como muestra la figura 1.1, cualquier enfoque de
ingeniería, incluida ingeniería del software como lo indica el autor, debe apoyarse sobre un
compromiso de organización de calidad. La calidad, según indica, es la concordancia del software
producido con los requisitos explícitamente establecidos, con los estándares de desarrollo
prefijados y con los requisitos implícitos no establecidos formalmente, que desea el usuario.

Figura 1.1: Capas de la Ingeniería de Software según Pressman

Fuente.  – Tomado de https://e
https://es.slideshare.ne
s.slideshare.net/urielal/unida
t/urielal/unidad-i-introduccion-a-la
d-i-introduccion-a-la-ingenieria-de
-ingenieria-de-software
-software-is
-is

El fundamento de la ingeniería de software es la capa de proceso. El proceso de la ingeniería de

software es la unión que mantiene juntas las capas de tecnología y que permite un desarrollo
racional y oportuno de la ingeniería de 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
tecnología de la ingeniería de software. Las áreas claves del proceso forman la base del control
de gestión de proyectos del software y establecen el contexto en el que se aplican los métodos
técnicos, 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
 RAE. Real Academia Española

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 12

Los métodos de la ingeniería del software indican «cómo» construir técnicamente el software.
Estos abarcan una gran gama de tareas que incluyen análisis de requisitos, diseño, construcción
de programas, pruebas y mantenimiento. Los métodos de la ingeniería del software dependen
de un conjunto de principios básicos que gobiernan cada área de la tecnología e incluyen
actividades de modelado y otras técnicas
téc nicas descriptivas.

Las herramientas de la Ingeniería del software proporcionan un enfoque automático o

semiautomático para el proceso y para los métodos. Cuando se integran herramientas para que
la información creada por una herramienta la pueda utilizar otra, se establece un sistema de
soporte para el desarrollo del software llamado ingeniería del software asistida por
computadora (CASE).

Luego de describir cada capa, se puede afirmar que el objetivo de la ingeniería de software es
lograr productos de software de calidad
cal idad (tanto en su forma final como durante su elaboración),
mediante un proceso apoyado por métodos y herramientas.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 13

1.1.1.  Elementos claves de la Ingeniería de Software

La ingeniería de software incluye los siguientes elementos clave: paradigmas, estrategias,

métodos o técnicas, herramientas y procesos, los que a continuación se detallan:

a.  Paradigmas
a. 

Un paradigma representa un enfoque particular o filosofía para la construcción de software.

Cada uno tiene ventajas y desventajas, es por ello, que hay situaciones donde un paradigma
resulta más apropiado que otro.

b.  Estrategias
b. 

Se denominan estrategias para el desarrollo de software a las distintas maneras en que se

ordena la ejecución de las actividades requeridas para producir software.

c.  Métodos o técnicas

c. 

Los métodos o técnicas indican cómo construir el software técnicamente y abarcan un amplio
espectro de actividades que incluyen: planificación y estimación de proyectos, análisis de
requisitos y del sistema de software, diseño de la arquitectura de software, codificación,
documentación, prueba y mantenimiento.

d.  Herramientas
d. 

Son instrumentos que suministran un soporte automático o semiautomático para el proceso y

para los métodos. Cuando se integran las herramientas de forma que la información creada por
una herramienta pueda ser usada por otra, se establece un sistema para el soporte de desarrollo
del software, llamado ingeniería del software asistida por computadora (CASE, en inglés). CASE
combina software, hardware y bases de datos sobre la ingeniería del software (una estructura
de datos que contenga la información relevante sobre el análisis, diseño, codificación y prueba)
para crear un entorno de ingeniería del software análogo al diseño/ingeniería asistido por
computadora, CAD/CAE para el hardware.

e.  Procesos
e. 

Los procesos son la combinación de estrategias, métodos y herramientas que, en forma

conjunta, dan un resultado particular. Los procesos indicarán qué herramientas deberán
utilizarse y cuándo se aplican determinados métodos o técnicas. Definen la secuencia en que se
aplican los métodos, los documentos que se requieren, los controles que aseguren la calidad y
las mejores prácticas que permiten a los gestores a evaluar los progresos. Concretamente, el
proceso de desarrollo de software define quién va a hacer qué, cuándo hacerlo y cómo
có mo alcanzar
un cierto objetivo.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 14

1.1.2.  Fases de un proceso software

Con independencia del área de aplicación, tamaño o complejidad del proyecto, el trabajo que
se asocia a la ingeniería del software se puede dividir en tres fases genéricas:
  Fase de definición.


  Fase de desarrollo.


  Fase de mantenimiento.


Definición Desarrollo Mantenimiento Gestión

•Planificación •Diseño •Mantenimiento •Seguimiento y

•Requerimientos •Codificación •Adaptación control
•Análisis de •Pruebas •Mejora •Revisiones
Sistema técnicas
•Calidad de SW
•Gestión de
Riesgos

Figura 1.2: Fases genéricas de un proceso de software

a.  Fase de definición

a. 

Se centra sobre el qué. Es decir, durante la definición, el que desarrolla el software intenta
identificar qué información ha de ser procesada, qué función y rendimiento se desea, qué
comportamiento del sistema, qué interfaces van a ser establecidas, qué restricciones de diseño
existen, y qué criterios de validación se necesitan para definir un sistema correcto.
cor recto. Por lo tanto,
han de identificarse los requisitos clave del sistema y del software. Aunque los métodos
aplicados durante la fase de definición variarán dependiendo del paradigma de ingeniería del
software (o combinación de paradigmas) que se aplique, de alguna manera tendrán lugar tres
tareas principales:
  La ingeniería de sistemas o de información.


  Planificación del proyecto de software.



  Análisis de requisitos.


b.  Fase de desarrollo

b. 

Se centra en el cómo. Es decir, durante el desarrollo un ingeniero del software intenta definir
cómo han de diseñarse las estructuras de datos, cómo ha de implementarse la función dentro
de una arquitectura de software, cómo han de implementarse los detalles procedimentales,
cómo han de caracterizarse interfaces, cómo ha de traducirse el diseño en un lenguaje de
programación (o lenguaje no procedimental) y cómo ha de realizarse la prueba. Los métodos
aplicados durante la fase de desarrollo variarán, aunque las tres tareas específicas técnicas
deberían ocurrir siempre:
  El diseño del Software.


  La generación de código.


  Las pruebas de software.



ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 15

c.  Fase de mantenimiento

c. 

Se centra en el cambio que va asociado a la corrección 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
 Correctivo:: Para corregir los defectos.
  Adaptativo
 Adaptativo:: Para acomodarlo a los cambios de su entorno externo. (modificaciones en
la legislación, CPU, Sistema Operativo, Reglas de Negocio, etc.).
  Perfectivo:
Perfectivo: Para agregar otras funciones adicionales que van a producir beneficios.
  Preventivo
Preventivo:: También llamado reingeniería del software. Estos cambios se realizan a fin
de que se puedan corregir, adaptar y mejorar más fácilmente los programas.

Además de estas actividades de mantenimiento, los usuarios de software requieren un

mantenimiento continuo. Los asistentes técnicos a distancia, teléfonos de ayuda y sitios Web de
aplicaciones específicas se implementan frecuentemente como parte de la fase de
mantenimiento.

d.  Actividades de Gestión

d. 

Las fases descritas en esta visión general de la ingeniería del software se complementan con un
número de actividades protectoras. Entre las actividades
act ividades típicas de esta categoría se incluyen:

  Seguimiento y control del proyecto de software.
  Revisiones técnicas formales.
  Garantía de calidad del software.
  Gestión de configuración del software.
  Preparación y producción de documentos.
  Gestión de reutilización
  Mediciones e análisis de indicadores.
  Gestión de riesgos.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 16

1.1.3.  Modelos de Proceso de Software

Para resolver los problemas reales de una industria, un ingeniero de software o un equipo de
ingenieros deben incorporar una estrategia de desarrollo que acompañe al proceso, métodos,
herramientas y fases genéricas descritos en los puntos anteriores. Esta estrategia a menudo se
llama Modelo de Proceso o Paradigma de la Ingeniería del Software. Se selecciona un modelo
de proceso para la ingeniería del software según la naturaleza del proyecto y de su aplicación,
los métodos y las herramientas a utilizarse, los controles y las entregas que se requieren.

Existen muchos modelos de procesos de software, dentro de los

lo s cuales podemos mencionar:
  Modelo Cascada (Ciclo de Vida Básico o Modelo Lineal Secuencial).


  Modelo de Construcción de Prototipos.



  Modelo de Desarrollo Rápido de Aplicaciones (DRA).



  Modelos Evolutivos de Procesos de Software:



o  Modelo Incremental.
o  Modelo Espiral.
o  Modelo de Desarrollo Concurrente.
  Modelo de Desarrollo basado en Componentes.


a.  Modelo Cascada

a. 

Llamado algunas veces ciclo de vida básica o modelo en cascada. El modelo lineal secuencial
propone un enfoque sistemático, secuencial, para el desarrollo del software que comienza en
un nivel de sistemas y progresa con el análisis, diseño, codificación, pruebas y mantenimiento.
Es ideal para proyectos pequeños, rígidos, 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 este modelo,


pues traslapan las etapas.

  A menudo es difícil que el cliente exponga explícitamente todos los requisitos. El


interesado debería exponer los requisitos en la etapa inicial, pero en realidad éste lo
hace a lo largo de todo el proceso y esto complica las cosas.
  El cliente debe tener paciencia dado que la primera versión del software se tendrá recién


al final del proceso. A veces, el afán del cliente hace que la aplicación final no cumplo
con los requisitos definidos.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 17

Figura 1.3: Model

Modelo
o Cascada
Fuente.  – Tomado de 
de  https://sites.google.com/site/proyectoadpmodelosdedesarrollo/home/modelo-en-cascada

b.  Modelo de Construcción de Prototipos

b. 

Este modelo comienza con la recolección de requisitos. El desarrollador y el cliente definen los
objetivos globales para el software, originándose un diseño rápido que se centra en una
representación de esos aspectos del software que sean visibles para el usuario/cliente. De este
diseño surge la construcción de un prototipo y este es evaluado por el cliente/usuario. La
interacción ocurre cuando el prototipo satisface las necesidades del cliente.

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 versión 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.

Figura 1.4: Modelo de Construcción de Prototipos

Fuente.  – Tomado de http://scruz334.
http://scruz334.blogspot.e
blogspot.es/1193024400/
s/1193024400/

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 18

c.  Modelo de Desarrollo Rápido de Aplicaciones (DRA)

c. 

Es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el desarrollo
rápido de proyectos grandes utilizando un enfoque de construcción basado en el componente.
Comprende las siguientes fases: Análisis, diseño, código, pruebas y entrega. Si no existe el
compromiso entre clientes y desarrolladores o si los riesgos técnicos son altos, los proyectos
DRA fracasan.

Figura 1.5: Modelo de Desarrollo

Fuente.  – Tomado de http://informatica2dge1.blo
http://info Rápido
rmatica2dge1.blogspot.com/ de Aplicaciones
gspot.com/2007/03/mode
2007/03/modelo-de-desarro
lo-de-desarrollo-rpido-de.ht
llo-rpido-de.html
ml

d.  Modelo Incremental

d. 

Este modelo combina elementos del modelo lineal secuencial con la filosofía interactiva de
construcción 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 básicos, pero muchas

funciones suplementarias quedan sin extraer. El cliente utiliza el producto central y como
resultado de utilización o evaluación, se desarrolla un plan para el incremento siguiente, este
plan afronta la modificación del producto central para lograr satisfacer al cliente, la entrega de
funciones y características adicionales. Este proceso se repite siguiendo la entrega de cada
incremento, hasta que se elabore el producto
pro ducto completo.

Este modelo es apropiado para proyectos de larga duración que no consuman muchos recursos
y como el producto va desarrollándose incrementalmente, se puede financiar el proyecto por
partes.

Debido a la interacción con usuarios finales cuando es necesaria la retroalimentación hacia el

grupo de desarrollo, este proceso puede exigir demasiado tiempo, agregándose un costo extra
a la compañía, pues mientras estos usuarios evalúan el software dejan de ser productivos para
la compañía.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 19

Figura 1.6: Modelo Incremental

Fuente. – Tomado de http://maric
http://marich.blogspot.
h.blogspot.es/media/ca
es/media/cache/resolve
che/resolve/media/file
/media/files/01/109/382/2016/0
s/01/109/382/2016/03/incremento
3/incrementos.png
s.png

e.  Modelo Espiral

e. 

Es un modelo de proceso de software evolutivo que acompaña la naturaleza interactiva de

construcción de prototipos con los aspectos controlados y sistemáticos del modelo lineal
secuencial. Se desarrolla en una serie de versiones incrementales. Durante las primeras
iteraciones, la versión incremental podría ser un modelo en papel o un prototipo, las últimas
iteraciones, se producen versiones cada vez más completas de ingeniería del sistema. Este
modelo se divide en un número de actividades estructurales o regiones de tareas, como
comunicación con el cliente, planificación, análisis de riesgos, ingeniería, construcción y
adaptación, evaluación del cliente.

Debido a su complejidad, no se aconseja utilizarlo en pequeños sistemas. Por otro lado, resulta
difícil convencer a grandes clientes de que el enfoque evolutivo es controlable.

Figura 1.7: Modelo Espiral

Fuente.  – Tomado de http://dizbih.
http://dizbih.mobincube.mo
mobincube.mobi/section22612264.
bi/section22612264.html
html

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 20

f.  Modelo de Desarrollo Concurrente

f. 

Provee una meta descripción del proceso de software. Mientras que en el Espiral la principal
contribución es que las actividades del software ocurran repetidamente, en el modelo de
Desarrollo Concurrente es la capacidad de describir las múltiples actividades del software las
que ocurren simultáneamente.

Dado que los requisitos cambian, es muy probable que una vez que haya comenzado la fase de
diseño, sea necesario incorporar cambios. En estos casos No se debe detener el diseño, 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 Concurren

Concurrente
te
Fuente.  – Tomado de 
de  http://2.bp.blogspot.com/_sfHdvu3TAuo/SP5FkT9cZWI/AAAAAAAAAA0/ekPifJ2lL54/s1600-
h/concurrente.jpg

g.  Desarrollo basado en componentes

g. 

Es un modelo fuertemente orientado a la reutilización y trabaja sobre la base de tecnologías

orientado a objetos. Este modelo consta de 4 fases ilustradas en la figura 1.9. A continuación se
describe cada fase:
  Análisis de componentes: Se determina qué componentes pueden ser utilizados para el


sistema en cuestión. Caso siempre hay que hacer ajustes para adecuarlos.
  Modificación 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 más adecuados (fase 1).

Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el sistema. Se
debe tener en cuenta los componentes localizados en la fase 2 para diseñar o determinar este
marco.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 21

Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se integran los

componentes y subsistemas. La integración es parte del desarrollo en lugar de una actividad
separada.

Figura 1.9: Modelo de basado en componentes

Fuente. – Tomado de https://www.
https://www.flickr.com/
flickr.com/photos/48425423
photos/48425423@N06/4434551590
@N06/4434551590

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 22

1.1.4.  Metodología RUP (Rational Unified Process)

RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un software que

define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto. Presenta tres
características esenciales:
  Dirigido por Casos de Uso:
 Uso: Los casos de uso son un medio para determinar los requisitos
correctos y utilizarlos para conducir el proceso de desarrollo.

   Centrado en la arquitectura:
arquitectura : Se describe mediante diferentes vistas del sistema en
construcción.

   Iterativo e incremental:
incremental: Es práctico dividir el trabajo en partes más pequeñas o mini
proyectos, cada mini proyecto es una iteración que resulta en un incremento
i ncremento (JACOSON
Ivar, 2000).

Como filosofía RUP maneja seis principios clave:

c lave:
  Adaptación del proceso.
 proceso. El proceso deberá adaptarse a las características propias de la
organización. El tamaño de este, así como las regulaciones que lo condicionen, influirán
en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

   Balancear prioridades.
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.

   Colaboración entre equipos.

equipos. El desarrollo de software no lo hace una única persona
sino múltiples equipos. Debe haber una comunicación fluida para coordinar requisitos,
desarrollo, evaluaciones, planes, resultados, etc.

   Demostrar valor iterativamente.

iterativamente. Los proyectos se entregan, aunque sea de un modo
interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la
estabilidad y calidad del producto, y se refina la dirección del proyecto, así como
también los riesgos involucrados.

   Elevar el nivel de abstracción.

abstracción . Este principio dominante motiva el uso de conceptos
reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks)
por nombrar algunos. Éstos se pueden acompañar por las representaciones visuales de
la arquitectura, por ejemplo, con UML.

   Enfocarse en la calidad.
calidad. El control de calidad no debe realizarse al final de cada iteración,
sino en todos los aspectos de la producción.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 23

1.1.5.  Metodología AUP (Agile Unified Process)

El proceso unificado ágil (Agile UP) es un enfoque simplificado para el desarrollo de software
basado en el proceso unificado Rational (RUP) de IBM. El ciclo de vida de Agile UP es serial en lo
grande, iterativo en lo pequeño, entregando lanzamientos incrementales a lo largo del tiempo1.

Figura 1.10: Metodología AUP

Fuente.  – Tomado de https://www.
https://www.ecured.cu/i
ecured.cu/images/8/8d/Aup2.
mages/8/8d/Aup2.JPG
JPG

Modelo. El objetivo de esta disciplina es comprender el negocio de la organización, el dominio

Modelo.
del problema que aborda el proyecto e identificar una solución viable para abordar el dominio
del problema.

Implementación. El objetivo de esta disciplina es transformar su (s) modelo (s) en código

Implementación.
ejecutable y realizar un nivel básico de pruebas, en particular pruebas unitarias.

Prueba. El objetivo de esta disciplina es realizar una evaluación objetiva para garantizar la
Prueba.
calidad. Esto incluye encontrar defectos, validar que el sistema funciona como se diseñó y
verificar que se cumplan los requisitos.
r equisitos.

Despliegue
Despliegue.
para que el .sistema
El objetivo
estéde esta disciplina
disponible es usuarios
para los planificarfinales.
la entrega del sistema y ejecutar el plan

Gestión de la configuración.
configuración. El objetivo de esta disciplina es gestionar el acceso a los productos
de trabajo de su proyecto. Esto incluye no solo el seguimiento de las versiones de productos de
trabajo a lo largo del tiempo, sino también el control y la
l a administración de los cambios en ellas.

Gestión del proyecto.

proyecto. El objetivo de esta disciplina es dirigir las actividades
ac tividades que tienen lugar en
el proyecto. Esto incluye administrar riesgos, dirigir personas (asignar tareas, rastrear el
progreso, etc.) y coordinar con personas y sistemas fuera del alcance del proyecto para
asegurarse de que se entregue a tiempo y dentro del presupuesto.

1 http://www.ambysoft.com/unifiedprocess/agileUP.html  
http://www.ambysoft.com/unifiedprocess/agileUP.html 

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 24

Medio ambiente.
ambiente. El objetivo de esta disciplina es apoyar el resto del esfuerzo asegurando que
el proceso, la orientación (estándares y directrices) y las herramientas (hardware, software, etc.)
estén disponibles para el equipo según sea necesario.

1.1.6.  Mejores Prácticas de RUP

Por otro lado, RUP describe cómo aplicar efectivamente enfoques comprobados
comercialmente para el desarrollo de software. Estos enfoques son llamados "mejores
prácticas" pues son utilizados en la industria por organizaciones exitosas.

Figura 1.11: Mejores Prácticas RUP

Fuente. – Tomado de https://imag
https://image.slidesha
e.slidesharecdn.com/diapo
recdn.com/diapo01-110826210447-phpapp
01-110826210447-phpapp01/95/rup-13-728.j
01/95/rup-13-728.jpg?cb=1314392962
pg?cb=1314392962

Desarrollo Iterativo

En función 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 diseñar
toda la solución, construir el software y finalmente, testear el producto. Es necesario un enfoque
iterativo, que permita una comprensión creciente del problema a través de refinamientos
sucesivos, llegando a una solución efectiva luego de múltiples iteraciones acotadas en
complejidad.

RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos mediante la
producción de releases ejecutables progresivos y frecuentes que permiten la opinión e
involucramiento del usuario.

A través de las iteraciones que generan releases ejecutables, se logra detectar en forma
temprana los desajustes e inconsistencias entre los requisitos, el diseño, el desarrollo y la
implementación del sistema, manteniendo al team de desarrollo focalizado en producir
resultados.

Administración de Requisitos

Los requisitos son las condiciones o capacidades que el sistema debe conformar. La
Administración de Requisitos es un enfoque sistemático para hallar, documentar, organizar y
monitorear los requisitos cambiantes de un sistema.

La Administración de Requisitos permite:

a.  que las comunicaciones estén basadas en requisitos claramente definidos.
a. 
b.  que los requisitos puedan ser priorizados, filtrados y monitoreados.
b. 
c.  que sea posible realizar evaluaciones objetivas de funcionalidad y performance.
d.  que las inconsistencias se detecten fácilmente.
d. 

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 25

RUP describe cómo:

a.  Obtener, organizar y documentar la funcionalidad y restricciones requeridas.
a. 
b.  Documentar y monitorear las alternativas y decisiones.
b. 

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 diseño, la
implementación 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
cómo diseñar una arquitectura flexible, que se acomode a los cambios, comprensible
intuitivamente y promueve una más efectiva reutilización de software. Soporta el desarrollo de
software basado en componentes: módulos no triviales que completan una función clara. RUP
provee un enfoque sistemático para definir una arquitectura utilizando componentes nuevos y
preexistentes.

Modelamiento Visual

RUP muestra cómo representar el software visualmente para capturar la estructura y

comportamiento de arquitecturas y componentes.

Verificación 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 producción. RUP asiste en el planeamiento, diseño, implementación,
ejecución y evaluación 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 también una guía para establecer espacios de trabajo seguros
para cada desarrollador, suministrando el aislamiento de los cambios hechos en ootros
tros espacios
de trabajo y controlando los cambios de todos los elementos de software (modelos, código,
documentos, etc.). Describe cómo automatizar la integración y administrar la conformación de
releases.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 26

Estructura RUP

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

expresado en términos de ciclos, fases, iteraciones, y metas.

   El eje vertical representa el aspecto estático del proceso; como está descrito en
términos de actividades, artefactos, trabajadores o roles y flujos de trabajo.

Figura 1.12: Fases y Disciplinas de RUP

Fuente.  – Tomado de 
de  https://metodoss.com/wp-content/uploads/La-metodolog%C3%ADa-RUP-.png

a.  Fases
a. 

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en
número variable según el proyecto y en las que se desarrolla en mayor o menor proporción los
distintos flujos de trabajo:
Inicio:: En esta primera fase se define el alcance y objetivos del proyecto.
Inicio
Elaboración:: Se desarrolla el plan del proyecto, la especificación de características y la
Elaboración
arquitectura base del sistema.
Construcción:: Esta fase se concentra en la elaboración, de un producto totalmente
Construcción
operativo y eficiente y el manual de usuario.
Transición:: Fase en el cual se instala el producto en el cliente y se entrena a los usuarios.
Transición

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 27

b.  Flujos de Trabajo

b. 

Los flujos de trabajo son también conocidos como disciplinas, consisten en una secuencia de
actividades que producen un resultado observable (artefacto) a cargo de algún miembro del
proyecto (rol).

Figura 1.13: Elementos RUP que definen un Flujo de Trabajo

Fuente. – Tomado de 
de  http://www.vlaredo.galeon.com/index22.jpg

Existen dos grupos de flujos de trabajo: de proceso y de apoyo.

apoyo . Las que se describirán a
continuación.

c.  Flujos de trabajo de proceso

c. 

Orientados al desarrollo del software. Comprende:

  Modelado del negocio:
 negocio: Describe la estructura y la dinámica de la organización donde se
va a implantar el sistema que construyamos.
  Requisitos
Requisitos:: Establece exactamente lo que tiene que hacer el sistema, para ello se extrae
los requisitos utilizando diferentes métodos.
  Análisis y Diseño:
 Diseño: Traduce los requisitos a una especificación que describe cómo
implementar el sistema, creando para ello, diferentes vistas arquitectónicas.


  Implementación
Implementación:
: Tiene en cuenta el desarrollo de software, las pruebas unitarias y la
integración.
  Pruebas
Pruebas:: Describe la ejecución de pruebas y las métricas para rastreo de defectos.
  Despliegue o Implantación:
Implantación: Incluye actividades relacionadas con la entrega de la
aplicación.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 28

d.  Flujos de trabajo de apoyo

d. 

También conocidos como flujos de trabajo de soporte.

soporte. Están orientados a la gestión del
proyecto. Éstos son:
  Configuración y Control de cambios:
 cambios : Mantiene la integridad de todos los artefactos que
se crean en el proyecto. También mantiene información del proceso evolutivo que se ha
seguido.


  Gestión del proyecto:
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
Entorno:: Cubre la infraestructura necesaria para desarrollar un sistema.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 29

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 llevar a cabo un conjunto
de actividades como ser el dueño de un conjunto de artefactos.

A continuación, se lista algunos roles específicos dentro de cada rol genérico:

   Analista de Procesos de Negocio

   Diseñador de Negocio
Analistas
   Analista de Sistema
   Especificador de requisitos

   Arquitecto de Software
   Diseñador
   Diseñador de Interfaz de Usuario
Desarrolladores    Diseñador de Cápsulas
   Diseñador de Bases de Datos
   Implementador
   Integrador

   Jefe de Proyecto
   Jefe de Control de Cambios
   Jefe de Configuración
   Jefe de Pruebas
Gestores
   Jefe de Despliegue
   Ingeniero de Procesos
   Revisor de Gestión del Proyecto
   Gestor de Pruebas

   Documentador Técnico
   Administrador de Sistema
Apoyo    Especialista en herramientas
   Desarrollador de cursos


  Artista gráfico

   Especialista en Pruebas (Tester)

Especialista en
   Analista de Pruebas
Pruebas
   Diseñador de Pruebas

   Stakeholders
   Revisor
Otros roles
   Coordinador de revisiones
   Revisor Técnico
Tabla 1.1: Roles en la Metodología RUP

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 30

1.1.7.  UML (Lenguaje de Modelado 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.

UML capta la información sobre la estructura estática y el comportamiento dinámico de un

sistema. Un sistema se modela como una colección de objetos discretos que interactúan para
realizar un trabajo que finalmente beneficia a un usuario externo. La estructura estática define
los tipos de objetos. El comportamiento dinámico define la historia de los objetos en el tiempo
y la comunicación entre objetos para cumplir sus objetivos. El modelar un sistema desde varios
puntos de vista, separados pero relacionados, permite entenderlo para diferentes propósitos.

UML también 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 implantación y para elementos de tiempo de ejecución.

UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de

código de UML para una gran variedad de lenguajes de programación, así como construir
modelos por ingeniería inversa a partir de programas existentes.

Breve Historia

Los lenguajes de modelado de objetos aparecieron en la década de 1980, llegando a ser unos 50
a mediados de la década de 1990. Unos pocos métodos empezaron a ganar importancia, ente
ellos: el Método OMT (Object-Modeling
OMT (Object-Modeling Technique) de James Rumbaugh, que era mejor para el
análisis orientado a objetos, el Método Booch de
Booch de Grady Booch, el cual era mejor para el diseño
orientado a objetos, y el Método OOSE OOSE  (Object-Oriented Software Engineering) de Ivar
Jacobson, que era un método de ingeniería de software orientado a objetos.

El esfuerzo para la definición de UML comenzó en octubre de 1994,

1994, cuando Rumbaugh se unió
a Booch en Rational Software Corporation (empresa donde trabajaba Booch). Unificaron sus
métodos de modelado y elaboraron el borrador de la versión 0.8 de UML. En 1995 Jacobson
también se incorporó a Rational, incorporando así OOSE a UML. En 1996 se publicó la versión
0.9 de UML. Las tres personalidades que dieron el origen a UML son conocidas como “los Tres
Amigos”. 

Luego de varios años y varias modificaciones, OMG adoptó la versión oficial de UML 2.0 a
principios del año 2005,
2005 , versión que integra varios esfuerzos para la definición de una
semántica de la especificación más sólida.
sólida. UML es evolutivo, actualmente va por la versión 2.5,
la cual fue liberada en marzo del 2015. UML 2.5 incluye tres (03) nuevos diagramas: Diagrama
de Modelo, Diagrama de Manifestación, Diagrama de Arquitectura de Red.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 31

Versión Fecha de lanzamiento

2.5 Marzo 2015
2.4.1 Agosto 2011
2.4 Marzo 2011
2.3 Mayo 2010
2.2 Febrero 2009
2.1.2 Noviembre 2007

2.1.1 Agosto 2007

2.0 Julio 2005
1.5 Marzo 2003
1.4 Septiembre 2001
1.3 Marzo 2000
Tabla 1.2: Versiones de UML

¿Qué es la OMG?

La OMG (Object Management Group) es una asociación 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 asociación se encarga de la definición
y mantenimiento de estándares para aplicaciones de la industria de la computación. Otro de los
estándares definidos por la OMG, además del UML, es CORBA, el cual permite interoperabilidad
multiplataforma a nivel de objetos de negocio.

Objetivos UML

Los objetivos de UML son muchos, pero se pueden sintetizar en las siguientes:
  Visualizar
 Visualizar:: UML permite expresar de una forma gráfica un sistema de forma que otro lo
puede entender.
  Especificar
 Especificar:: UML permite especificar cuáles son las características de un sistema antes
de su construcción.
  Construir
 Construir:: A partir de los modelos especificados se pueden construir los sistemas
diseñados.
  Documentar
 Documentar:: Los propios elementos gráficos sirven como documentación del sistema
desarrollado que pueden servir para su futura revisión.

Especificaciones fundamentales del UML 2.0

En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un lenguaje de
programación. Un modelo creado mediante UML no podía ejecutarse. En el UML 2.0, esta
asunción cambió de manera drástica y se modificó el lenguaje, de manera tal que permitiera
capturar mucho más comportamiento (Behavior). De esta forma, se permitió la creación de
herramientas que soporten la automatización y generación de código 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 especificación se separó en cuatro especificaciones
(paquetes) bien definidas, tal como se muestra en la siguiente figura.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 32

Figura 1.14: Especificaciones principales de UML 2.0

Fuente.  – Tomado de https://epidataconsult
https://epidataconsulting.com/tikiw
ing.com/tikiwiki/show_image
iki/show_image.php?name=A
.php?name=ArticuloUML
rticuloUML01
01

Veamos a continuación cada una de las principales especificaciones que componen UML 2.0.

Supra-estructura

La superestructura del UML es la definición formal de los elementos del UML.

UML. Es aquí donde se
definen los diagramas y los elementos que los componen. Esta definición sola contiene más de
640 páginas. La superestructura es utilizada por los desarrolladores de aplicación. Es aquella
sobre la que hablan los libros y la que la mayoría conoce de versiones anteriores del UML.

Se encuentra dividida en niveles. Estos niveles se conocen como:

  Básico (L1):
 (L1): Contiene los elementos básicos del UML 2.0, entre ellos: Diagramas de
clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas de
d e Casos de
Uso.
  Intermedio (L2):
 (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles,
Diagramas de Componentes y Diagramas de despliegue.
  Completo (L3):
 (L3): Representa la especificación del UML 2.0 completa, como, por ejemplo:
las Acciones, Características avanzadas y PowerTypes,
P owerTypes, entre otros.

Es importante destacar que basta con

co n que una herramienta implemente el nivel de conformidad
Básico (L1), para que se considere UML 2.0 compatible. Por eso, es normal ver una disparidad
de características (features) bastante amplia entre dos herramientas distintas, aunque estas
sean UML 2.0 compatibles.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 33

1.1.8.  Diagramas de UML 2.5

En UML 2.5 existen diferentes tipos de diagramas. Para comprenderlos de manera concreta, es
útil categorizarlos jerárquicamente, como se muestra en la figura 1.15.

Figura 1.15: Diagramas UML 2.5

Fuente.  – Tomado de https://ww
https://www.uml-diagrams.
w.uml-diagrams.org/uml-25-dia
org/uml-25-diagrams.png
grams.png

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera concreta, es
útil categorizarlos jerárquicamente, como se muestra en la figura 1.15.

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 máquina de estados.



IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 34

Los Diagramas de Interacción son un subtipo de diagramas de comportamiento, que enfatiza

sobre el flujo de control
co ntrol y de datos entre los elementos del sistema modelado:
  Diagrama de secuencia.


  Diagrama de comunicación.


  Diagrama de tiempos (A partir de UML 2.0).



  Diagrama de descripción de la interacción (A partir de UML 2.0).



Figura 1.16: Jerarquía de Diagramas UML 2.0

Fuente.  – Tomado de 
de  http://2.bp.blogspot.com/-Oo_tSfmmKrM/TepNO5-uPBI/AAAAAAAAACw/1OEwj-a-DyA/s1600/uml.bmp

Diagrama de Casos de Uso

Este diagrama permite realizar la especificación del alcance funcional del producto software que
se construye y de los actores, entes que interactúan con el producto software. Son usados para
representar los procesos de negocio de la organización objetivo y las funcionalidades que
representan la arquitectura del sistema por cada proceso de negocio.

Figura 1.17: Diagrama de Casos de Uso

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 35

Diagrama de Clases

Un diagrama de clases es un tipo de diagrama estático 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 análisis y diseño de los sistemas; donde se crea el diseño
conceptual de la información que se manejará en el sistema y los componentes que se
encargarán del funcionamiento y la relación entre uno y otro.

Figura 1.18: Diagrama de Clases de Análisis

Figura 1.19: Diagrama de Clases de Diseño

Fuente. – Tomado de
https://www.researchgate
https://www.researchgate.net/prof
.net/profile/Carlos_G
ile/Carlos_Gonzalez235/publi
onzalez235/publication/323919133/
cation/323919133/figure/fig1/AS:
figure/fig1/AS:606749048442881@15
606749048442881@15216716
216716
54958/Figura-28-Diagrama-de-clas
54958/Figura-28-Dia grama-de-clases-del-patr
es-del-patron-de-diseno-M
on-de-diseno-MVC-Fuente-A
VC-Fuente-A-System-of
-System-of-Patterns.
-Patterns.png
png

Diagrama de componentes
Un diagrama de componentes muestra las organizaciones y dependencias lógicas entre
componentes software (código fuente, binarios o ejecutables). Desde el punto de vista del
diagrama de componentes, se tiene en consideración los requisitos relacionados con la facilidad
facili dad
de desarrollo, la gestión del software, la reutilización, y las restricciones impuestas por los
lenguajes de programación y las herramientas utilizadas en el desarrollo.

Figura 1.20: Diagrama de Componentes

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 36

Diagrama de Despliegue

Describen la configuración del entorno de máquinas y redes sobre el que se distribuyen

componentes y procesos del sistema.

Figura 1.21: Diagrama de Despliegue

Diagrama de Actividades

Muestra un flujo ordenado de actividades. Los diagramas de actividades tienen un amplio

número de usos; desde definir un flujo de programa básico, hasta capturar los puntos de
decisión y acciones dentro de cualquier proceso generalizado.

Figura 1.22: Diagrama de Actividade

Actividadess

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 37

Diagrama de Paquetes

Este tipo de diagrama se usa para dividir el modelo en contenedores lógicos (paquetes) y
describen las interacciones entre ellos a un nivel más alto. Los paquetes ofrecen un mecanismo
general para la organización de los modelos/subsistemas/capas agrupando elementos de
modelado.

Figura 1.23: Diagrama de Paquetes

Fuente.  – Tomado de 
de  http://1.bp.blogspot.com/-jamGt7PY_uE/U-
s_3WTO8BI/AAAAAAAAIwg/wQGtl7i9Mk0/s1600/Ejemplo%2Bde%2BDiagrama%2Bde%2BPaquetes%2B-%2BNew%2BPage.png

Diagrama de Máquina de Estados

Típicamente este diagrama se utiliza para representar todos los posibles estados que lo
loss objetos
de una clase puedan tener. Los diagramas de estado no se hacen para todas las clases, es solo
para aquellas clases que tengan un número de estados bien definidos y en donde el
comportamiento de la clase es afectado y cambiado por los distintos estados.

Figura 1.24: Diagrama de estados

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 38

Diagrama de Secuencia

Muestra una secuencia de mensajes pasadas entre los objetos usando una línea de tiempo
vertical.

Figura 1.25: Diagrama de Secuencia

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 39

1.2.   TEMA 2: HERRAMIENTAS CASE

1.2.
Las herramientas CASE (Computer Aided Software Engineering) son diversas aplicaciones
informáticas destinadas a aumentar la productividad en el desarrollo de software y reduce el
costo de estas en términos 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 diseño del proyecto, cálculo de costos, implementación de parte del código
automáticamente con el diseño dado, compilación automática, documentación o detección de
errores entre otras.

1.2.1.  Objetivos de las Herramientas CASE

  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 informáticos.
  Mejorar la planificación de un proyecto.
  Automatizar desarrollo del software, documentación, generación de código, pruebas de
errores y gestión del proyecto.
  Ayudar a la reutilización del software, portabilidad y estandarización de la
documentación.

1.2.2.  Tipos de herramientas CASE

La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo que
cubren:
  Upper CASE (U-CASE),
 (U-CASE), herramientas que ayudan en las fases de planificación, análisis
de requisitos y estrategia del desarrollo, usando, entre otros, diagramas UML.

  Middle CASE (M-CASE),

(M-CASE), herramientas para automatizar tareas en el análisis y diseño de
la aplicación.

  Lower CASE (L-CASE),

(L-CASE), herramientas que semiautomatizan la generación de código,
crean programas de detección de errores, soportan la depuración de programas y
pruebas. Además, automatizan la documentación completa de la aplicación. Aquí
pueden incluirse las herramientas de Desarrollo rápido de aplicaciones.

  Integrated CASE (I-CASE),

(I-CASE), herramientas que engloban todo el proceso de desarrollo de
software, desde análisis hasta implementación.

1.2.3.  Ejemplos de herramientas CASE

A continuación, se muestran productos que soportan UML 2.0.

a.  Rational Software Architect (IBM-RSA)

a. 

Es una herramienta de diseño y construcción para arquitectos de software y desarrolladores

sénior 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 aplicación de software.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 40

La versión actual del Rational Software Architect es 9.7.x la cual trae una mejora en cuanto a
creación de modelos y diagramas se refiere.

Figura 1.26: Rational Software Architect - IBM

b.  Enterprise Architect

b. 

Enterprise Architect es una herramienta de análisis y diseño intuitiva, flexible y poderosa para
construir software robusto y mantenible. Desde la recolección de requerimientos, pasando por
el análisis, modelado, implementación y pruebas hasta despliegue y mantenimiento; Enterprise
Architect es una herramienta de modelado UML rápida, rica en funcionalidad y multiusuario que
conduce el éxito de su proyecto de software.

Enterprise Architect permite al equipo de desarrollo:

  Acompañamiento en todo el proceso de desarrollo.


  Administración de modelos UML.



  Generación de reportes.


  Administración de proyectos.


  Generación de código.


  Ingeniería Inversa.


  Debugging.


  Modelado de datos.


  Modelado de XML.


  Transformaciones MDA.


Enterprise Architect es una herramienta gráfica multiusuario diseñada para al equipo de

desarrollo a construir sistemas robustos y mantenibles. Además, posee facilidades de
incorporadas de reportes y documentación, de alta
al ta calidad.

Enterprise Architect es una herramienta muy ligera y rápida en su uso. Permite el trabajo
distribuido permitiendo la creación de modelos en paralelo por múltiples usuarios. Posee
además la capacidad de integrarse
i ntegrarse a controladores de versiones.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 41

Actualmente en su versión 14.x, la cual implementa las últimas actualizaciones de UML 2.5.

Figura 1.27: Enterprise Architect - Sparx Systems

Fuente.  – Tomado de 
de  http://www.sparxsystems.com.ar/products/ea/

StarUML
StarUML es una herramienta desarrollada por MKLab. Este software está licenciado bajo una
versión modificada de GNU GPL hasta el 2014, fecha en que una versión reescrita 2.0.0 fue
liberado para pruebas beta bajo una licencia propietaria.

Después de ser abandonado por algún tiempo, el proyecto tuvo un renacimiento para pasar de
Delphi para Java/Eclipse y luego se detuvo de nuevo. En el 2014, la versión reescrita fue lanzada
como software propietario. Sin embargo, la comunidad de la versión de código abierto aún
continúa activa.

StarUML soporta la mayoría de los tipos de diagramas UML especificados en su versión 2.x.

Su versión más reciente de sus autores originales está disponible para su descarga bajo el
nombre de StarUML2,
soporte para aunque
extensiones, no bajo la
compatibilidad licencia
con GPL.operativo
el sistema Esta nueva
OSXversión incluye
y una nueva además
interfaz de
usuario.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 42

Figura 1.28: StarUML

Fuente.  – Tomado de http://staruml.io/image/
http://staruml.io/image/screenshot
screenshot_jumbotron.
_jumbotron.png
png

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 43

Resumen
1.  RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un software
1. 
que define claramente quién, cómo, cuándo y qué debe hacerse en el proyecto.

2.  RUP es un proceso bidimensional que se describe en:

2. 
a.  Fases:
  Inicio


  Elaboración


  Construcción


  Transición


b.  Disciplinas:
b. 
  Modelado de Negocio


  Requerimientos


  Análisis y Diseño


  Implementación


  Desarrollo de Pruebas


  Gestión de Cambios y Configuración



  Gestión de Proyectos


  Entorno


3.  Un rol define el comportamiento y responsabilidades de un individuo o grupo de

3. 
individuos.

4.  UML es un lenguaje de modelado visual que se usa para visualizar, especificar, construir
4. 
y documentar artefactos de un sistema de software.

5.  Las Herramientas CASE son aplicaciones informáticas destinadas a aumentar la

5. 
productividad en el desarrollo de software y reduce el costo de estas en términos de
tiempo y de dinero.

Recursos
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o  https://www.omg.org/  
https://www.omg.org/
o  http://www.uml.org/
http://www.uml.org/  
o  http://www.sparxsystems.com.au/resources/uml2_tutorial/  
http://www.sparxsystems.com.au/resources/uml2_tutorial/
o  http://staruml.io/  
http://staruml.io/

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 44

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 45

UNIDAD 

DISCIPLINA DE MODELADO DE NEGOCIO

LOGRO DE LA UNIDAD DE APRENDIZAJE 
2
Al término de la unidad, el alumno sustenta el primer avance de su proyecto
p royecto relacionado
a la elaboración de la documentación del Modelado de Negocio de un caso de estudio
utilizando una Herramienta CASE. Este avance incluye el desarrollo del Modelo de Casos
de Uso de Negocio (MCUN) y el Modelo de Análisis de Negocio (MAN).

TEMARIO 

2.1 Tema 3 : Modelado de Negocio

2.1.1 : ¿Cuándo es necesario realizar el Modelado de Negocio?
2.1.2 : ¿Cuándo no es necesario realizar el Modelado de Negocio?
2.1.3 : Actividades para realizar un Modelado de Negocio

2.2 Tema 4 : Modelo de Casos de Uso del Negocio - MCUN

2.2.1 : Determinar la situación de la organización
2.2.2 : Identificar los procesos de negocio
2.2.3 : Redefinición de los procesos de negocio
2.2.4 : Artefactos del Modelo de Casos de Uso de Negocio

Caso propuesto del Modelo de Casos de Uso del Negocio. Caso:

2.3 Tema 5 :
Chasqui Express S.A.
2.3.1 : Solución del caso en Rational Software Architect
2.3.2 : Solución del caso en Enterprise Architect - Sparx

2.4 Tema 6 : Modelo de Análisis del Negocio - MAN

2.4.1 : Diseño de realizaciones de procesos de negocio
2.4.2 : Artefactos del Modelo de Análisis de Negocio: Plantilla MAN

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 46

2.5 Tema 7 : Caso Propuesto de MCUN y MAN

Caso: Chasqui Express S.A. - Solución en Rational Software
2.5.1 :
Architect
2.5.2 : Caso: Calidad Educativa - Solución en Rational Software Architect
2.5.3 : Caso: Calidad Educativa - Solución en Enterprise Architect – Sparx
2.5.4 : Otros casos propuestos

ACTIVIDADES PROPUESTAS 

   Los alumnos desarrollan el Modelo de Casos de Uso de Negocio (MCUN) de los

Procesos de Negocio de un caso propuesto.
   Los alumnos desarrollan el Modelo de Análisis de Negocio (MAN) de los Procesos
de Negocio de un caso propuesto.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 47

2.1.   TEMA 3: MODELADO DE NEGOCIO 

2.1.
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 adopción de estos
productos. Hay que entender cómo funciona el negocio que se desea automatizar para tener
garantías de que el software desarrollado va a cumplir su propósito, y por esto, se hace un

estudio en el dominio del negocio además de en el dominio del software.

Así, los objetivos de esta disciplina son los siguientes:
  Entender los problemas actuales en la organización 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 visión común de la organización considerada.

  Obtener los requisitos del sistema software que den soporte a la organización objetivo.


  Entender como el sistema software encaja en la organización.



Por consiguiente, el Modelo del Negocio proporciona una vista estática de la estructura de la
organización y una vista dinámica de los procesos dentro de la organización.

Los creadores de RUP señalan que el modelo de negocio está soportado por dos artefactos
principales:
  Modelo de casos de uso del negocio (MCUN)


  Modelo de análisis del negocio (MAN)



El modelo de casos de uso de negocio describe los procesos de negocio de una empresa en
términos 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 análisis del
negocio es un modelo interno a un negocio, que describe cómo 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 definición de los
requisitos del sistema.

2.1.1.  ¿Cuándo es necesario realizar el Modelado de Negocio?

  Cuando el grupo de trabajo es nuevo en la organización.

  Cuando la organización ha enfrentado un reciente proceso de reingeniería de negocios.
  Cuando la organización está planificando un proceso de reingeniería de negocios.
  Cuando el software a construir será utilizado por una porción importante de la
organización.
  Existen flujos de trabajo complejos, dentro de la organización, que no están
documentados.
  Cuando se es un consultor en una organización en la cual no se ha trabajado
tra bajado antes.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 48

Figura 2.1: Artefactos del Modelado de Negocio

Fuente.  – Tomado de https://pla
https://player.slideplay
yer.slideplayer.es/7/1675528/da
er.es/7/1675528/data/image
ta/images/img64.png
s/img64.png

2.1.2.  ¿Cuándo no es necesario realizar el Modelado de Negocio?

   Cuando se tiene un conocimiento de la estructura de la organización, de las metas, de

la visión y de los clientes/usuarios.
   Cuando el software a construir será usado por una pequeña parte de la organización, y
no tiene un efecto en el resto del negocio.
   Cuando los flujos de trabajo de la organización están bien documentados.
   Cuando el tiempo no lo permita, no todos los procesos tienen el tiempo necesario para
completar un análisis de negocio.

2.1.3.  Actividades para realizar un Modelado de Negocio

Según RUP, el Modelado de Negocio comprende las siguientes actividades:

  Determinar la situación de la organización.


  Describir el actual negocio.



  Identificar los procesos de negocio.



  Refinar las definiciones de los procesos de negocio.



  Diseñar las realizaciones de los procesos de negocio.



  Refinar roles y responsabilidades.



  Explorar procesos automatizados.



  Desarrollar un modelado de dominio.



En este apartado trataremos la ejecución de actividades relevantes que permiten obtener los
artefactos principales del Modelo de Negocio.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 49

Los pasos que contemplaremos para obtener el Modelo de casos de uso del negocio son:
  Determinar la situación de la organización.


  Identificar los procesos de negocio.



  Refinar las definiciones de los procesos de negocio.



Por último, la actividad que ejecutaremos para obtener el Modelo de análisis del negocio es:
  Diseñar las realizaciones de los procesos de negocio.


IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 50

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 51

2.2.   TEMA 4: MODELO DE CASOS DE USO DE NEGOCIO - MCUN

2.2.
Define un conjunto de acciones que el negocio lleva a cabo y provee resultados de valor a
quienes interactúan con él. Son procesos de negocio descritos bajo un punto de vista externo
que percibe algún tipo de valor.

2.2.1.  Determinar la situación de la organización

El objetivo es reconocer el negocio en estudio para delimitarlo. Las actividades que se llevan a
cabo son:
a.  Identificar la misión y visión de la organización y/o áreas de estudio que correspondan
a. 
y plasmarlo en Visión del Negocio.
b.  Identificar los objetivos del negocio, y documentarlos en Objetivos del Negocio. Estos
b. 
objetivos son determinados por los stakeholders y responsables del negocio y serán
usados para validar los casos de uso del negocio.
c.  Identificar las reglas del negocio y luego plasmarlas en el documento Reglas del Negocio.
c. 
d.  Elaborar una lista de términos y definiciones usados comúnmente en un Glosario del
d. 
Negocio.

Se ha preferido reunir los documentos anteriormente mencionados en el artefacto Situación del

Negocio..
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 interacción entre actores de negocio y casos de uso de negocio se crea un
Diagrama General de Casos de Uso de Negocio.
Nego cio.

Por cada caso de uso del negocio, se realiza una Especificación de Caso de Uso del Negocio, en
este documento se indica una descripción breve del proceso de negocio.

Para describir los actores del negocio y mostrar mediante un diagrama de casos de uso del
negocio su asociación con los casos de uso de negocio encontrados se utiliza el artefacto Actores
del Negocio.

2.2.3.  Redefinición de los procesos de negocio

Consiste en:
a.  Detallar la definición de los casos de uso del negocio.
a. 
b.  Describir cómo los casos de uso del negocio soportan los objetivos de negocio.
b. 
c.  Verificar que los casos de uso del negocio representan correctamente cómo el negocio
c. 
es conducido.

Aquí se refina la Especificación de Caso de Uso del Negocio, describiendo paso a paso las
actividades que se desarrollan en el proceso de negocio.

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 52

2.2.4.  Artefactos del Modelo de Casos de Uso de Negocio

Artefacto Descripción

Documento que contiene la visión del negocio, un glosario de

términos del negocio, los objetivos del negocio y reglas del
negocio.
Análisis de Negocio

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 relación de dependencia entre objetivos del
Objetivo de Negocio 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 interactúan con él.
Describe un proceso de negocio desde un punto de vista
externo que percibe algún tipo de valor.
Caso de Uso de Negocio Definen los límites de la organización.

Representa un rol que algo o alguien externo desempeña en

relación con el negocio.
Puede ser asociado a uno o más casos de uso del negocio.
Actor de Negocio

Representa la vista externa del negocio.

Es un modelo que describe la dirección e intención del
negocio. La dirección es provista por los objetivos del
negocio. Mientras que la intención es expresada por los
diagramas que permiten ver cómo interactuar con el
Modelo de Casos de Uso de entorno.
Negocio

Reporte que contiene

identificados información
en el modelo de casosde
delos actores
u so
uso del negocio
del negocio.
Actores de Negocio

Documento que contiene las características de un proceso de

negocio. Se realiza una especificación por cada caso de uso
Especificación de Caso de Uso de negocio.
de Negocio

Es una política o condición que debe ser satisfecha por el

negocio. Ejm:
“El pago de planillas se realizará los días 25 de cada mes y vía
Reglas de Negocio depósito en cuenta bancar ia.” 
Tabla 2.1: Artefactos del Modelo de Casos de Uso de Negocio
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 53

2.3.   TEMA 5: CASO PROPUESTO DEL MODELO DE CASOS DE USO DE

2.3.
NEGOCIO. CASO: CHASQUI EXPRESS S.A.
CASO: CHASQUI EXPRESS S.A.

Usted ha sido contratado para trabajar en el proyecto: Sistema de Venta de Servicios Postales
para la empresa Chasqui Express. Esta compañía tiene como principal servicio, la entrega de
paquetes y documentos hacia diferentes destinos por vía aérea, tanto en el interior del país
como en las principales ciudades del mundo.

Actualmente en el Perú, Chasqui Express tiene 15 Centros de Servicios, tanto en Lima como en
Provincias, lugares a donde los clientes acuden para realizar sus envíos.

Al llegar al Centro de Servicios, el cliente solicita realizar una operación de envío al Asesor de
Servicio al Cliente, éste le pide el nombre de la ciudad
ci udad destino; si se trata de un paquete lo coloca
en la balanza y anota el peso. Con esta información, busca en el tarifario el valor de venta del
servicio a cobrar más los extra-cargos, en seguida le comunica al cliente y pide su conformidad
para continuar. Si el Cliente acepta, el Asesor de Servicio al Cliente le pide los datos del
Remitente, su documento de Identidad (RUC, DNI, Carnet de Extranjería u otros), nombre,
dirección completa, teléfono y correo electrónico. Luego pide los datos personales del
Destinatario: Nombre y Apellidos, Dirección completa, Código Postal, Teléfono.

El Asesor de Servicio al Cliente emplea toda la información recabada, registra la guía aérea y la
emite con 4 copias; además, le solicita al Cliente la forma de pago del servicio, realiza la cobranza
y finalmente la registra, emitiendo la Factura o Boleta de Venta. Antes de finalizar la atención,
el Asesor de Servicio al Cliente registra el número de guía aérea, la fecha y la hora en que recibe
el documento o paquete en una aplicación de uso global denominada Global Shipments; esta
información se denomina checkpoint (punto de control) “Pick
“P ick Up“(recojo). Un checkpoint es un
código de evento que sirve para otorgar trazabilidad a los envíos desde que son tomados por
Chasqui Express hasta la entregarle al destinatario. Para Finalizar, el Asesor de Servicio
S ervicio al Cliente
le entrega al Cliente una copia de la Guía Aérea y su correspondiente documento de venta
(Boleta o Factura).

El Asesor de Servicio al Cliente, pega la guía aérea en el envío, luego la coloca en la zona de
“Salida”. 

Al finalizar el día, el Courier encargado de recoger los envíos para transportarlos a la Oficina
Central, se dirige según su ruta a la Estación de Servicios para recoger los envíos dejados, estos
están ubicados en la “Zona de Salida”, son tomados por el Courier y escaneados (tiene adherido
la guía aérea) por un dispositivo móvil para registrar el checkpoint “With Courier” (con el
Courier). Cada cierto tiempo este dispositivo móvil transmite los checkpoints a través de una
conexión GPRS contratada a Telefónica hacia el sistema Global Shipments. Todos los envío son
colocados en la unidad móvil y transportados a la Oficina Central. En este lugar los operadores
se encargan de hacer la separación de los envíos por tipo: envíos domésticos a un lado y en otros
envíos internacionales, luego se hace un ordenamiento por ciudad destino.

Eventualmente, el Cliente requiere averiguar el estado de su envío, entonces se contacta por vía
telefónica con un Asesor de Servicio al Cliente, quién le solicita el número de su guía aérea. El
cliente le entrega este dato y el Asesor de Servicio al Cliente verifica si es correcto y si ha sido
registrado. Si existe consulta en el sistema Global Shipment, el lugar y último checkpoint
registrado, luego interpreta la información y se la brinda al Cliente.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 54

Realizar lo siguiente:
  Elaborar la estructura del Proyecto en una Herramienta CASE.


  Identificar los Casos de Uso de Negocio



  Identificar los Actores de Negocio



  Identificar los Objetivos de Negocio



  Elaborar el Diagrama de Casos de Uso de Negocio.


 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 55

2.3.1.  Solución del caso en Rational Software Architect

Estructura del proyecto: Modelo de Casos de Uso de Negocio

Figura 2.2: Estructura del Modelo de Casos de Uso de Negocio en RSA

Casos de Uso de Negocio

Figura 2.3: Casos de Uso de Negocio en RSA

Actores de Negocio

Figura 2.4: Actores de Negocio en RSA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 56

Objetivos de Negocio

Figura 2.5: Objetivos de Negocio en RSA

Diagrama de Casos de Uso de Negocio

Figura 2.6: Diagrama General de Casos de Uso de Negocio en RSA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 57

2.3.2.  Solución del caso en Enterprise Archi

Architect
tect - Sparx

Estructura del proyecto: Modelo de Casos de Uso de Negocio

Figura 2.7: Estructura del Modelo de Casos de Uso de Negocio en EA

Casos de Uso de Negocio

class CUN

Recepción de paquete En
nttre ga
ga de pa qu
que tte
e Se
eg
gui mi
mi en
ento de pa qu
que te
te

Figura 2.8: Casos de Uso de Negocio en EA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 58

Actores de Negocio

class AN

«business actor»
Remitente

«business actor»
Cliente

«business actor»
Destinatario

Figura 2.9: Actores de Negocio en EA

Objetivos de Negocio

class ON

«Business Goal»
Optimizar el proceso de
envío de paquetes en un
20%

«Business Goal»
«Business Goal»
Reducir el tiempo de envío de
Reducir el número de paquetes
paquete en un 10% respecto al
dañados en un 50% respecto al
período anterior 
semestre 2015-II

Figura 2.10: Objetivos de Negocio en EA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 59

Diagrama de Casos de Uso de Negocio

uc Diagrama General de Casos de Uso de Negocio

Recepción de paquete

«business actor»
Remitente

Seguimiento de
paquete

«business actor»
Cliente

Entrega de paquete

«business actor»
Destinatario

Figura 2.11: Diagrama General de Casos de Uso en EA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 60

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 61

2.4.   TEMA 6: MODELO DE ANÁLISIS DE NEGOCIO - MAN

2.4.
Es un modelo interno a un negocio. Detalla cómo el proceso es implementado internamente.
Incluye una descripción de los business workers, las entidades del negocio que se manipulan y
cómo los business workers manipulan estas entidades para llevar a cabo el proceso del negocio
mediante diagramas de interacción.

2.4.1.  Diseño de realizaciones de procesos de negocio

Consiste en identificar todos los roles, productos, entregables del negocio y describir cómo el
proceso del negocio será llevado a cabo por los trabajadores y las entidades dentro del negocio.

El documento que plasma la descripción breve de trabajadores del negocio y cómo ellos
manipulan las entidades del negocio es Trabajadores del Negocio.

Además, 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 realización 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 Especificación 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
act ividades correspondientes.

2.4.2.  Artefactos del Modelo de Análisis de Negocio: Plantilla MAN

Artefacto Descripción

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.
Trabajador de Negocio

Ente significativo y persistente manipulado por actores del

negocio y trabajadores del negocio.
Entidad de Negocio

Colección de diagramas que muestra cómo 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
Realización de Casos de Uso Actividades y Diagramas de Colaboración para realizar el
de Negocio detalle de cada proceso de negocio.

Representa la vista interna del negocio.

Es un modelo que describe la realización
r ealización de los casos de uso
del negocio. Es una abstracción de cómo los trabajadores
t rabajadores del
negocio y las entidades de negocio se relacionan y de cómo
Modelo de Análisis de
Negocio colaboran para realizar los casos del uso del negocio.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 62

Artefacto Descripción

Documento que contiene información de los trabajadores

del negocio identificados en el modelo de análisis del
negocio.
Trabajadores de Negocio

Documento que contiene información de las entidades del

negocio identificadas en el modelo de análisis del negocio.
Entidades de Negocio
Tabla 2.2: Artefactos del Modelo de Análisis de Negocio
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 63

2.5.   TEMA 7: CASO PROPUESTO DE MCUN Y MAN

2.5.

2.5.1.  Caso: Chasqui Express S.A. - Solución en Rational Software Architect

Continuaremos con el desarrollo del Modelo de Análisis de Negocio del Caso Chasqui Express
visto anteriormente en la página 53.

Para el caso en mención realizaremos lo siguiente:

  Elaborar la estructura del MAN del Proyecto en una Herramienta CASE.


  Identificar los Trabajadores de Negocio.



  Identificar las Entidades de Negocio.



  Identificar las Realizaciones de Negocio.



  Elaborar el Diagrama de Estados.



  Elaborar el Diagrama de Actividades de Negocio.



  Elaborar el Diagrama de Clases de Negocio.



SOLUCIÓN EN RATIONAL SOFTWARE ARCHITECT  – (RSA)

Estructura del proyecto: Modelo de Análisis de Negocio

Figura 2.12: Estructura del Modelo de Análisis de Negocio en RSA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 64

Trabajadores de Negocio

Figura 2.13: Casos de Uso de Negocio en RSA

Entidades de Negocio

Figura 2.14: Actores de Negocio en RSA

Realizaciones de Negocio

Figura 2.15: Realizaciones de Negocio en RSA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 65

Diagrama de Estados

Figura 2.16: Diagrama de Estados de un CDP en RSA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 66

Diagrama de Actividades

Figura 2.17: Diagrama de Actividade

Actividadess en RSA
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 67

2.5.2.  Caso: Calidad Educativa - Solución en Rational Software Architect

La jefa de calidad educativa (JCE) ha solicitado los servicios al área de sistemas para que
sistematice el proceso de encuestas. Para llevar a cabo esta sistematización el analista realiza el
levantamiento de información entrevistando a las personas que trabajan dentro de este
proceso. A continuación, un resumen de cómo trabaja esta área:

El coordinador de sede (CS) solicita a la JCE la elaboración de encuestas a docentes.

JCE elabora las preguntas y comunica a su asistente para que cree el formato de encuesta y
registre las preguntas con sus respectivas opciones. Una vez finalizada la elaboración, la
asistente le entrega el formato terminado a la JCE para su visto bueno.

Una vez aceptado el formato la JCE ordena a su asistente que se acerque a las aulas para que
entregue las encuestas a los alumnos donde procederán a llenarla y entregarla a la asistente
para que calcule el puntaje de cada docente. Obtenido el puntaje, la asistente informa sobre la
evaluación de cada docente a la JCE, con esta información la JCE genera un informe, el cual será
entregado al (CS) quien entrega el informe a los profesores al final del ciclo.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 68

SOLUCIÓN EN RATIONAL SOFTWARE ARCHITECT

Modelo de Análisis de Negocio

Figura 2.18: Estructura del Modelo de Análisis de Negocio en RSA

Trabajadores de Negocio

Figura 2.19: Trabajadores de Negocio en RSA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 69

Entidades de Negocio

Figura 2.20: Entidades de Negocio en RSA

Realizaciones de Negocio

Diagrama de estados

Figura 2.22: Diagrama de estados de una encuesta

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 70

Diagrama de Clases de Negocio

Figura 2.23: Diagrama de Clases de Negocio en RSA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 71

Diagrama de Actividades de Negocio

Figura 2.24: Diagrama de Actividades de Negocio en RSA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 72

2.5.3.  Caso: Calidad Educativa - Solución en Enterprise Architect - Sparx

SOLUCIÓN EN ENTERPRISE ARCHITECT - SPARX

Modelo de Análisis de Negocio

Figura 2.25: Estructura del Modelo de Análisis en EA

Trabajadores de Negocio

uc TN

 Asistente JCE

Figura 2.26: Trabajadores de Negocio en EA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 73

Entidades de Negocio

class EN

Encuesta   Aula  Alum no Docente

Informe   Empleado

Figura 2.27: Trabajadores de Negocio en EA

Realizaciones de Negocio

uc RN

RN
RN_Encuesta
_Encuesta a
CUN01: Encuesta a docentes
docentes

Figura 2.28: Realizaciones de Negocio en EA

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 74

2.5.4.  Otros casos propuestos

Con el fin de reforzar los conocimientos y actividades necesarias para elaborar un Modelo de
Casos de Uso de Negocio (MCUN) y Modelo de Análisis de Negocio (MAN), se sugiere desarrollar
los siguientes casos:

CASO: IMPRENTA LASER DATA

La imprenta “Laser Data”, es una empresa dedicada a la confección de tarjetas y tiene como
objetivos satisfacer en un 100% todos los requerimientos de partes matrimoniales, quince años,
cumpleaños, bautizo, primera comunión, etc.

“Laser Data”, le presta mucha atención a los detalles que las personas buscan, ofreciendo así
productos de calidad, acompañado del mejor servicio de atención del pedido y a buenos precios.
“Laser Data”, cuenta con una gran variedad de partes, recuerdos y accesorios para ttodo
odo tipo de
ocasión.

Como parte de la estrategia de marketing, “Laser Data” cuenta con socios de negocio para cada
ocasión, por ejemplo, en los matrimonios, tiene convenios con empresas que organizan las
bodas, revistas para novios, tiendas de regalos, agencias de viajes, etc. Así, cuando una pareja
desea casarse y va a uno de los socios de negocio, tam bién llega a contactarse con “Laser Data”
por las buenas recomendaciones.
Al contactarse el cliente o el socio
soc io con la empresa, este le envía las especificaciones de la tarjeta
y cantidad al responsable de pedidos(RP)
pedidos(RP) que toma el pedido, quie quien
n lo envía al ejecutivo de
cuenta (EC) quien recibe y entrega al diseñador gráfico (DG) el cual genera la versión de la tarjeta
de acuerdo a los requerimientos; devolviendo luego al EC para que verifique el resultado en
consulta con el cliente quien da la autorización de impresión, por lo que el EC enviara la muestra
al equipo de prensa (EP) para que proceda
proceda a imprimir el material solicitado.

El responsable del área de diseño se encarga de tener las últimas tendencias en los modelos
para las tarjetas o partes, teniendo siempre el catálogo de tarjetas actualizado y dejando para
la personalización que el cliente finalmente pueda hacer sobre la tarjeta.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 75

CASO: DON PASTEL

En una empresa dedicada a la elaboración de pasteles y tortas, se realizan las actividades de

acuerdo con el detalle siguiente:

El jefe de ventas entrega las órdenes de pedidos al jefe de producción quien las recibe y prepara
la orden de producción, el jefe de producción proporciona la orden de producción al operador

para
dichoque genere su requerimiento
requerimiento es entregadode materia prima
al almacenero deeproductos
insumo enen
base a la orden
proceso, que de
se producción,
encarga del
retiro de las materias primas e insumos, procede a pesar los ingredientes necesarios para
producir la torta, luego entrega los ingredientes al operador, donde verifica la conformidad de
la recepción firma la atención al requerimiento, en caso contrario no firma documento alguno y
solicita que se complete la atención a su requerimiento. Una vez obtenido los materiales e
insumos el operador inicia su trabajo agregando los ingredientes a la máquina de batido,
haciendo funcionar la máquina, y monitorea el proceso, al término traslada la mezcla a la
máquina dosificadora, activándola y verificando que no se presenten problemas en el
preparado. Finalmente, el operador organiza las tortas preparadas en las cajas, generando un
reporte de producción, entregando los productos y el reporte al almacenero de productos
terminados quien los recepciona dando su conformidad a la producción.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 76

Resumen
1.  El Modelo de Análisis es un modelo interno a un negocio.
1. 

2.  En el modelo de Análisis se debe identificar los Trabajadores de Negocio, Entidades de

2. 
Negocio, y Realizaciones de Negocio.

3.  Los trabajadores de negocio deben cumplir roles internos al negocio y son quienes
3. 
manipulan las entidades de negocio.

4.  Las Realizaciones de Negocio está conformado por una colección de diagramas que dan
4. 
mayor detalle de las actividades que realizan los trabajadores de negocio sobre las
entidades de negocio.

Recursos
Puede visualizar los siguientes enlaces para ampliar los conceptos vertidos en esta unidad:
https://www.youtube.com/watch?v=X30Bt1bRsCI 
  https://www.youtube.com/watch?v=X30Bt1bRsCI
https://www.youtube.com/watch?v=jXYWTpqjJ6Y   
o
o   https://www.youtube.com/watch?v=jXYWTpqjJ6Y
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 77

UNIDAD 

DISCIPLINA DE LA CAPTURA DE
REQUISITOS
3
LOGRO DE LA UNIDAD DE APRENDIZAJE 
Al término de la unidad, el alumno sustenta el proyecto realizado durante el curso
relacionado a la elaboración de la documentación del Modelado de Negocio, Captura de
Requisitos, Modelo de Casos de Uso y Prototipos (GUIs) de un caso de estudio utilizando
una Herramienta CASE. Además, el alumno es capaz de elaborar prototipos utilizando
herramientas de prototipado (GUIs).

TEMARIO 

3.1 Tema 8 : Captura de Requisitos

3.1.1 : Importancia de la Captura de Requisitos
3.1.2 : Dificultades de la captura de Requisitos
3.1.3 : Artefactos de la Captura de Requisitos
3.1.4 : Actividades para realizar la Captura de Requisitos
3.1.5 : Requisitos FURPS+
3.1.6 : Técnicas para capturar requisitos

3.1.7 : Experiencia de usuario (UX Design)

3.1.8 : Captura de requisitos a solicitud del cliente
Captura de Actividades a partir del Diagrama de Actividades de
3.1.9 :
Negocio - Caso: El Pirata: Plantilla de MCU

3.2 Tema 9 : Modelo de Casos de Uso

3.2.1 : Identificación de Actores
3.2.2 : Identificación de Casos de Uso
3.2.3 : Crear el Diagrama de Casos de Uso - Caso: El Pirata

3.3 Tema 10 : Estructurando el Modelo de Casos de Uso

3.3.1 : Objetivos
3.3.2 : Tipos de relaciones
3.3.3 : Casos de Uso Abstractos y Concretos
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 78

3.3.4 : Especificación de Casos de Uso -ECU

3.3.5 : Priorización de Casos de Uso

ACTIVIDADES PROPUESTAS 

  Los alumnos clasificarán los requisitos de una lista propuesta según las categorías
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.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 79

3.1.   TEMA 8: CAPTURA DE REQUISITOS

3.1.
La Ingeniería de Requisitos se ocupa de la recolección, análisis, especificación y validación de los
l os
requerimientos de software.
[SWEBOK: 2004]

La Ingeniería de Requisitos abarca las actividades de descubrir, documentar y mantener una serie
de requerimientos para un sistema y el uso del término “ingeniería” implica que se debe usar una
serie de técnicas sistemáticas, repetibles para asegurar que los requerimientos sean completos,
consistentes y relevantes.
[Sommerville: 1997]

3.1.1.  Importancia de la Captura de Requisitos

La importancia de la captura de requisitos radica en lo siguiente:

  Permite estimar costos, tiempos y recursos.


  Disminuye los costos y retrasos del proyecto.



  Mejora la comunicación entre clientes

 cl ientes y desarrolladores.
  Evita rechazos de usuarios finales.


3.1.2.  Dificultades de la captura de Requisitos

Dentro de las principales dificultades que se pueden presentar podemos mencionar:

  Dejar de lado a ciertos usuarios durante la captura de requisitos.


  Falta de participación del usuario.



  Factores políticos.


  Los requisitos:


o  Pueden estar incompletos y no son obvios.

o  Vienen de muchas fuentes
o  Muchos tipos de requisitos y muchos niveles de detalle.
o  Pueden variar con el templo.

Durante el proceso de captura de requisitos es bueno tener en cuenta:

  Objetivos de negocio y ambiente de trabajo.


  Diferentes puntos de vista de los clientes.



  Barreras de comunicación entre clientes y analistas de requerimientos.



  Integración del sistema con otros ya existentes.



  Tamaño de la documentación.


La utilización de los casos

c asos de uso complementa el proceso de captura de requisitos, pues permite
materializar cada requerimiento en una funcionalidad del sistema (requerimientos funcionales).

El modelo de casos de uso es construido a través de un proceso iterativo durante el cual las
discusiones entre los desarrolladores del sistema y los clientes (y/o usuarios finales) llevan a una
especificación de requisitos en la que todos estén de acuerdo.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 80

Así, los propósitos de la Captura 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.



   Definir
Proporcionar la base para
las interfaces estimar
de usuario loselcostos
con y tiempos
sistema, deladesarrollo
enfocado del sistema.
las necesidades y objetivos
de los usuarios.

3.1.3.  Artefactos de la Captura de Requisitos

El conjunto completo de artefactos de la captura de requisitos, mostrado en la siguiente tabla,

sirven como entrada y referencia para el análisis, diseño, implementación y pruebas del sistema.

La propuesta del curso, para una solución de mediana envergadura, es crear los artefactos
proporcionados en la tabla 3.1.

Artefacto Descripción

Documento que define la opinión de los stakeholders del

producto que se desarrollará, especificada en términos de
necesidades y características claves de los stakeholders.
Contiene un esquema de los requisitos previstos, el cual
Visión proporciona la base contractual para los requisitos técnicos
más detallados.

La Especificación de Requisitos de Software es un documento

que enfoca la organización completa de los requisitos del
proyecto.
Comúnmente conocido como SRS por sus iniciales en inglés.
Especificación de Requisitos de Contiene la lista de requerimientos funcionales y no
Software funcionales.

Es una colección 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
dividiéndolo en piezas más pequeñas.
Paquete de Caso de Uso

Es un proceso específico del sistema con identidad propia, el

cual define una secuencia de acciones que el sistema realiza
para un actor en particular.
Caso de Uso

Representa un rol (humano, hardware o software) externo al

sistema con el que se establece intercambio directo de
información.
Puede ser asociado a uno o más casos de uso.
Actor
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 81

Artefacto Descripción

Es un modelo que captura los requisitos funcionales de los

usuarios a un alto nivel y establece la estructura fundamental
fundam ental
del sistema. Es un input esencial para las actividades en
análisis, diseño y pruebas.
Modelo de Casos de Uso

Reporte que contiene información de los actores

identificados en el modelo de casos de uso.
Actores

Documento que contiene las características de un caso de

uso. Contiene primordialmente una descripción del flujo de
eventos que describen la interacción entre los actores y el
sistema. La especificación también contiene otra información
Especificación de tal como precondiciones, post condiciones y requisitos
Casos de Uso especiales. Se realiza una especificación por caso de uso.
Tabla 3.1: Artefactos de la Captura de Requisitos

3.1.4.  Actividades para realizar la Captura de Requisitos

Según RUP, la Captura de Requisitos comprende las siguientes actividades:

1.  Analizar el problema.
1. 
2.  Entender las necesidades de stakeholders.
2. 
3.  Definir el sistema.
3. 
4.  Administrar el alcance del sistema.
4. 
5.  Refinar la definición del sistema.
5. 
6.  Administrar cambios de requisitos.
6. 

Analizar el Problema

El documento Visión es el principal artefacto en el cual el análisis del problema es documentado.

Para determinar el alcance inicial del proyecto, los límites del sistema deben ser definidos. El
analista de sistema identifica usuarios y sistemas, representado por actores, los cuales

interactúan conloselactores.
contendrá sólo sistema. En este caso, el analista crea el Modelo de Casos de Uso que

Entender las necesidades del Stakeholder

El artefacto principal es el documento Visión refinado. También los requisitos son discutidos y
expresados en términos de Casos de Uso y Actores. Los requisitos no funcionales, que no son
representados en el Modelo de Casos de Uso deberán ser documentados en Especificaciones
Suplementarias.

El analista se relaciona con los stakeholders utilizando técnicas para capturar requisitos, tales
como las entrevistas y prototipos. Por
Po r tanto, los stakeholder son fuentes de requisitos.

Los stakeholders son un grupo de interés cuyas necesidades deben ser satisfechas por el
proyecto.por
afectado El papel puede ser del
los resultados desempeñado porejemplo:
proyecto. Por cualquierusuarios
personafinales
que es del
o será potencialmente
sistema, gerentes,
accionistas, reguladores quiénes certifican la aceptabilidad del sistema.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 82

Definir el Sistema

Esta actividad 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 el documento de Especificaciones Suplementarias.

Administrar el Alcance del Sistema

El alcance del proyecto es definido por el conjunto de requisitos definidos para este. 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 priorización los casos de uso,
desarrollado por el arquitecto de software, permite planificar el proyecto.

Refinar la Definición del Alcance

El output de este Workflow del RUP es una comprensión más profunda de la funcionalidad del
sistema expresada en Casos de Uso detallados y documentos de Especificaciones
Suplementarias detallados. Si es necesario, una Especificación de Requisitos de Software formal
puede ser desarrollada, además de los documentos detallados de Casos de Uso y
Especificaciones Suplementarias.

Administrar los cambios de Requisitos

Los cambios a los requisitos impactan los modelos producidos en el Workflow de Análisis y
Diseño, 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.

Requisitos

Un requisito o requerimiento se puede definir como una especificación de lo que el sistema debe
hacer y las restricciones a tener en cuenta.

Según RUP, el requerimiento de software es una especificación de una condición o posibilidad

que un sistema debe cumplir y que buscar especificar:
  Una capacidad de software necesaria para que el usuario solucione un problema y


pueda alcanzar un objetivo.

  Una posibilidad que el software debe cumplir para satisfacer un contrato, estándar,


especificación u otra documentación formalmente impuesta.

Tipos de requisitos

Existen dos tipos de requisitos: requisitos funcionales y requisitos no funcionales.

Requerimientos Funcionales

Es una declaración de lo que debe hacer el sistema, es la declaración de la función del sistema.
Las características principales de los requerimientos funcionales son las siguientes:

  Especifican las condiciones que debe ser cumplidas por el sistema.
  Se identifican desde el punto de vista del cliente.
  Se redactan en lenguaje natural.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 83

Ejemplos:
  El sistema debe permitir registrar
 permitir registrar la información de libros de una biblioteca.
  El sistema debe permitir registrar
 permitir registrar la información de profesores que dictan los cursos de
baile.
  El sistema debe permitir registrar
 permitir registrar los horarios de dictado de clase.
  El sistema debe permitir registrar
 permitir registrar la matrícula de alumnos.
  El sistema debe obligar al
 obligar al usuario a cambiar su contraseña cada 60 días.

Los requerimientos funcionales se mencionan inicialmente en la lista de características del

sistema del documento Visión. Cuando se tiene un mayor conocimiento de los requerimientos
funcionales se detallan en el documento SRS (Requerimientos de Sistema) y pueden en
ocasiones establecerse más claramente usando prototipos.

Requerimientos No Funcionales

Son limitaciones sobre servicios o funciones que ofrece el sistema. Incluyen restricciones tanto
de temporización y del proceso de desarrollo, como impuestas por los estándares. Los
requerimientos no funcionales se suelen aplicar al sistema como un todo, más que a
características o a servicios individuales del sistema.

Pueden relacionarse con propiedades emergentes, como la fiabilidad, tiempo de respuesta y uso

de almacenamiento; pueden definir restricciones sobre la implementación del sistema, como las
capacidades de los dispositivos I/O o las representaciones de datos usados en las interfases con
otros sistemas; como rendimiento, la seguridad o disponibilidad, especifican o restringen por lo
general características del sistema como un todo  (SOMMERVILLE, Ingeniería de Software, 2011).

Ejemplos:
  El sistema de administración de bibliotecas debe ser escrito en C++.


  El sistema de cajero automático debe validar la tarjeta en menos de 4 segundos.



  El sistema de florerías debe poder ser visualizado en los 4 exploradores más usados:


Chrome, Firefox, Internet Explorer y Safari.

Los requerimientos no funcionales se detallan en el documento SRS y/o en el documento

Especificación Suplementaria.

Figura 3.1: Tipos de Requerimie

Requerimientos
ntos No Funcionales
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 84

3.1.5.  Requisitos FURPS+

Este es un tipo de clasificación de requisitos especificado en la documentación de RUP. Se utiliza

el acrónimo FURPS (por las siglas en inglés) para describir las principales categorías de requisitos:
  Funcionalidad (Functionality)


  Facilidad de Uso (Usability)



  Confiabilidad (Reliability)


  Rendimiento (Performance)
  Soporte (Supportability)

El símbolo "+" en FURPS+ hace referencia a que se deben incluir otros requisitos, tales como:
  Restricciones de diseño


  Requisitos de implementación


  Requisitos de interfaz


  Requisitos físicos


Funcionales

Los requerimientos funcionales deben incluir:

  Conjunto de características.


  Capacidades.



  Seguridad.

Por ejemplo, para un Sistema de Ventas:

  R1: El sistema debe permitir mostrar descripción y precio de productos.


  R2: El sistema debe permitir registrar venta de productos.



  R3: El sistema debe permitir reducir stock cuando se realiza la venta.



  R4: El sistema debe permitir identificar al cajero utilizando un usuario y una clave.


Facilidad de Uso

Los requerimientos relacionados a la facilidad de uso deben incluir subcategorías tales como:
  Factores Humanos.


  Estéticos.


  Consistencia de Interfaz de Usuario.




  Ayuda en línea o “context-sensitive”.
  Asistentes (“wizards”).
  Documentación de Usuario.
  Materiales de Capacitación/Entrenamiento.

Por ejemplo:
  R1:
 R1: El sistema deberá proporcionar ayudas en línea para orientar al usuario en el uso de
sus interfaces.
  R2:
 R2: Maximizar eficiencia mediante la navegación con teclado.
  R3:
 R3: El sistema debe tener interfaces gráficas de administración y de operación en idioma
español y en ambiente 100% Web, para permitir su utilización a través de navegadores
de Internet.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 85

Confiabilidad

Dentro de los requerimientos relacionados a la confiabilidad podemos mencionar:

  Frecuencia de fallos.


  Capacidad de recuperación a fallos.



  Posibilidades de predicción del programa.



  Precisión.


  Tiempo medio de fallos.

Por ejemplo:
  R1:
 R1: El sistema debe registrar los pagos a crédito autorizados que se hagan a las cuentas
por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energía o del
equipo.
  R2:
 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.

Rendimiento

Los requerimientos de rendimiento están relacionados a las condiciones impuestas a requisitos

funcionales y son tales como:
  Velocidad.



  Eficiencia.
   Disponibilidad.
   Tiempo de Respuesta.
   Tiempo de Recuperación.
   Uso de recursos.

Por ejemplo:
  R1:
 R1: El tiempo máximo para mostrar el reporte de cuentas por cobrar mediante un
histograma es de 10 segundos.
  R2:
 R2: El sistema debe estar disponible al 100% o muy cercano a esta disponibilidad
durante el horario hábil laboral de la empresa a nivel nacional, es decir, de lunes a
viernes de 8:00 a.m. a 06:15 p.m., con excepción de los días festivos.

Soporte

Los requerimientos de soporte están relacionados en la capacidad que tiene el software de ser
modificado fácilmente para adecuar mejoras o cambios e incluyen:
  Adaptabilidad.


  Facilidad de mantenimiento.


  Compatibilidad.


  Configurabilidad.


  Facilidad de instalación.


  Internacionalización.


Por ejemplo:
  R1:
 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:
 R2: El sistema deberá estar orientado a que las actualizaciones sólo se hagan en el sitio
del servidor.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 86

Restricciones de diseño

Los requerimientos de diseño son también llamados restricciones de diseño, pues especifican o
restringen el diseño de un sistema.

Por ejemplo:
  R1:
 R1: El sistema deberá considerar en su arquitectura un modelo tres capas, donde se

definen
o tres
interfaz de componentes lógicos
usuario, servicios de manera independiente:
de funcionalidad y servicios de servicios
datos. de presentación
  R2:
R2: El sistema de matrícula deberá considerar la utilización de un servicio web con la
RENIEC para verificar los datos del alumno.

Requisitos de implementación

Los requerimientos de implementación especifican restricciones de codificación o de

construcción del sistema:
  Estándares requeridos.


  Lenguajes de implementación.


  Políticas para la integridad de Bases de Datos.



  Límite de recursos.


  Ambientes de Operación.


Por ejemplo:
  R1:
 R1: El sistema debe desarrollarse en ASP.NET
A SP.NET C# con framework 4.5.
  R2:
 R2: La SGBD utilizado por el sistema será MySQL.
  R3:
 R3: El sistema debe ser publicado en un servidor IIS 7.5.

Requisitos de Interfaz

Los requerimientos de interfaz especifican:

  Elementos externos con el que el sistema debe interactuar.


  Restricciones o formatos, tiempos u otros factores usados en tales interacciones.



Por ejemplo:
  R1:
 R1: El sistema deberá proporcionar, para los diferentes reportes solicitados, salidas en
documentos electrónicos (Word, Excel y PDF Acrobat).
  R2:
R2: En una visión preliminar de impresión se consideraría que todos los textos estarán
relacionados con un visor de PDF, las estadísticas y resultados de consultas estarán
relacionados con Excel 2007 o superior.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 87

Requisitos Físicos

Los requisitos físicos especifican características físicas con las que el sistema debe contar
(material, forma, tamaño y peso). Pueden
P ueden especificarse los requisitos de hardware.

Por ejemplo:
  R1: Para que un cliente
 cl iente de la aplicación pueda ejecutar procesos, en línea, considerados

en el sistema,
requisitos la estación de trabajo del usuario deberá cumplir con los siguientes
mínimos.

Requisitos Físicos

  Procesador 1.0 GHz.

  Memoria 128 MB.
  Disco duro 10 GB.
  Sistema Operativo Windows XP o Linux.
  Navegador internet Explorer 6.0 o posterior, Mozilla
Firefox 2.X, Netscape Navigator 6.X o posterior con plugins
para Macromedia Flash y Java.
  Conexión a Internet. mínimo 56Kbps.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 88

3.1.6.  Técnicas para capturar requisitos

Las técnicas de recolección de información de la ingeniería de requisitos surgen como medio

para mejorar la comunicación entre usuarios o clientes y el equipo de trabajo que desarrolla el
software. Esta técnica es importante por dos razones:
1.  En ocasiones los desarrolladores no conocen todos los detalles del trabajo de la
1. 
organización para la cual están desarrollando el sistema.
2.  Los usuarios no saben que información es necesaria y relevante para el desarrollo de un
sistema.

A continuación, se muestra un listado de herramientas para la captura de requisitos en las

etapas que estas normalmente son aplicadas:

Técnicas Extracción Análisis Especificación Validación

Entrevistas y/o cuestionarios X
Sistemas existentes X X
BrainStorming X X
Observación X
Prototipo Bosquejado X X X

Prototipo Tangible / Usable X X X

FODA X
Cadena de Valor X
Modelo de Clase Conceptual X X
Diagrama de Pescado X X X
Glosario X X X X
Casos de Uso X X X X
CheckList X X
Tabla 3.2: Herramientas para la captura de requisitos

Entrevistas

Utilizada para reunir información 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 serán afectados por él.
  No invente una solución.


  Escuche.


  No adivine los pensamiento.



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 más
amplia. Esto le puede ayudar a validar su entendimiento de los requisitos.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 89

Por el tipo de preguntas que contiene, existen dos tipos de cuestionarios: abiertos y cerrados.
  Abiertos
 Abiertos:: No presuponen ninguna respuesta particular y animan al entrevistado a hablar
sobre el problema para obtener opiniones y/o referencias.
  Cerrados
 Cerrados:: Limitan las respuestas posibles a través de un estilo cuidadoso en la pregunta.

Los tipos de respuestas de un cuestionario cerrado podrían ser los siguientes:

  SI/NO

Ejemplo:

¿Cree que se cometen muchos errores en la codificación de los números de cuenta en las
facturas?

   DE ACUERDO / EN DESACUERDO

¿Se cometen muchos errores al codificar os números de cuenta en las facturas?

   ESCALAS

¿Se cometen muchos errores al codificar los números de cuenta en las facturas?


  NÚMERO

¿De cada 100 facturas que se procesan cuántas tienen errores? Anote el número: _______

   RANGO
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 90

  SELECCIÓN DE RESPUESTAS LIMITADAS

Cuando se presentan errores en la codificación de los números de cuenta en las facturas, ¿cuál
es la causa más frecuente? (Anote el número de la respuesta apropiada. También la segunda
razón más común y la menos común).

1… 

2… 

Los buenos cuestionarios se deben diseñar previamente. Un

pensamiento cuidadoso, acompañado de una prueba previa, tanto del
formato como de las preguntas, son la base de una recopilación de
datos significativa a través de cuestionarios.

Pautas que le ayudarán a confeccionar un buen cuestionario:

1.  Determine qué datos necesitan recopilarse y qué personas son las más calificadas para
1. 
proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visión
identifíquelos también.
2.  Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cuáles pueden ser más
2. 
útiles, si contienen una sección de respuestas cerradas y otras de respuestas abiertas.
3.  Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras
3. 
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:
4. 
a.  Interrogantes innecesarias.
a. 
b.  Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de
b. 
escritura.
c.  Preguntas que el sujeto no pueda responder.
c. 
d.  Preguntas que están escritas de forma que se escogerá la respuesta preferida.
d. 
e.  Preguntas que se interpretaran en forma diferente dependiendo del marco de
e. 
referencia de cada entrevistado.
f.  Preguntas que no proporcionan opciones adecuadas de respuesta.
f. 
g.  Un ordenamiento no adecuado de las preguntas y respuestas.
g. 
5.  Pruébelo previamente en un Grupo pequeño para detectar otros problemas posibles.
5. 
6.  Analice la respuesta del Grupo de prueba para asegurar que el análisis de los datos que
6. 
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 edición e imprímalo en una forma legible.
7. 
8.  Distribuya el cuestionario. Cuando sea posible anote el nombre de cada persona.
8. 

Lluvia de Ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar
g enerar
la máxima cantidad posible de requisitos para el sistema. No hay que detenerse en pensar si la
idea es o no del todo utilizable. La intención de este ejercicio es generar, en una primera
instancia, muchas ideas.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 91

Prototipos

Los prototipos son simulaciones o “maquetas” del posible producto software, que permite a los
lo s
usuarios, evaluar mejor sus necesidades, analizando si el prototipo se ajusta a las características
del sistema que necesitan.

Los prototipos pueden ser clasificados en dos grandes grupos:

Tipo Descripción
   Consiste en bosquejar la interfaz de usuario con programas
sencillos de dibujo (herramientas Mockup) o incluir modelos
de pantalla en papel.
   Una de las ventajas más importantes es el poco esfuerzo que
se necesita para aplicar cambios.
Prototipo
   Una de las desventajas es que el usuario puede no apreciar la
Bosquejado
interacción hombre-máquina, sobre todo para reflejar
requerimientos no funcionales como la usabilidad. Sin
embargo, hoy en día está desventaja puede ser mitigadas a
través del uso de Story-boards o el uso de herramientas
Mockup que permiten interacción.

   Los términos tangible y usable se refieren a desarrollar un

sistema (software) que el usuario pueda utilizar, es decir, con
Prototipo Tangible / la cual pueda interactuar como si éste fuese el sistema final.
usable    Cualquier que sea la herramienta software que se utilice para
desarrollar el prototipo, debe consumir poco esfuerzo y
tiempo en la realización de cambios.
Tabla 3.3: Tipos de Prototipo
Prototiposs
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 92

3.1.7.  Experiencia de usuario (UX Design)

¿Qué es UX Design?

UX Design es un elemento fundamental para crear sitios web y contenido digital; digital; es una
disciplina que se ocupa directamente de la experiencia de los usuarios en relación con un buen
contenido, accesible y capaz de despertar emociones positivas en el usuario Web. Cuidando el
aspecto gráfico, caracterizado por la facilidad de navegación y el nivel de satisfacción del
usuario. Esto tiene como objetivo estimular las emociones y la curiosidad, animas las actividades
de compra o la generación de clientes potenciales, cómo el completar un formulario de
contacto.

Fases del Proceso de diseño UX

a.  Investigación del usuario

a. 

Al igual que todas las actividades digitales dirigidas hacia el usuario, UX Design también requiere
una actividad de análisis, a menudo definida como investigación del usuario, dirigida a identificar
al público deseado, conocer las necesidades y la intención del usuario. Por lo tanto, se trata de
realizar análisis e investigaciones utilizando técnicas online y offline, para recoger datos valiosos
sobre los usuarios. Estos datos son esenciales para el diseño de un sitio web y sus contenidos.

Las actividades online,

online, como el análisis SEO, ayudan a comprender el comportamiento de los
usuarios que navegan por una web para que pueda optimizarse. Esta investigación también debe
realizarse en otros sitios web que tratan temas similares. Un análisis SEO definirá la intención
de los usuarios al obtener los resultados más relevantes proporcionados por los motores de
búsqueda. Esto se hace estudiando las palabras clave relacionadas con el área de referencia e
identificando el contenido y los sitios web más visitados. Una prueba de usabilidad ayudará a
resaltar los errores que se deben evitar durante el desarrollo del nuevo sitio web.
web .

Los métodos de investigación offline más tradicionales son las encuestas, los informes de lectura
y los documentos relacionados con el sector. Estas deben ser fuentes confiables para un análisis
del mercado y su público.

Se considera útil también la creación de un mapa del Customer Journey del usuario. Es esencial
tener un diagrama que represente las diferentes fases, rutas y puntos de contacto a través de
los cuales el usuario alcanza un objetivo o se convierte.
co nvierte. El análisis de este proceso hace posible
resaltar los comportamientos, así como las motivaciones, dificultades y necesidades del usuario.
La identificación de los principales obstáculos en la ruta de navegación permite el diseño de
nuevos embudos que son más efectivos y atractivos.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 93

b.  Diseño de la experiencia de usuario

b. 

Después de haber identificado y analizado al público relevante, llega el momento de la

elaboración de la experiencia del usuario que uno desea crear.

Planificar: A través de una fase de brainstorming, que en algunos

Planificar: al gunos casos es posible compartir con
el cliente, se generan ideas para aprovechar las oportunidades y resolver los problemas que
surgen en la yfase
comentarios del análisis
sugerencias del de la investigación
equipo de diseño, del
que usuario. Recopilamos
surgen con todasrecogiendo
total libertad, las ideas,
incluso las propuestas más banales y disruptivas, para evaluar todas las posibilidades.
Posteriormente, se examinan y seleccionan aquellas que se consideran relevantes para el
proyecto. Esta es la fase post-it. Al organizar los post-its en un tablero de anuncios, se puede
crear un mapa visual que abrirá el debate para seleccionar las ideas más válidas.

Procedemos entonces a crear un Sitemap basado en las ideas surgidas en la fase anterior, para
resaltar la importancia del contenido
co ntenido y la estructura de navegación de un sitio web. Estos mapas
a menudo también se producen para aplicaciones móviles y son útiles para mostrar cómo se
organizarán los contenidos, se dividirán en secciones y páginas individuales, y cómo el usuario
puede moverse de una sección a otra con facilidad. En general, también se establece un primer
diagrama del flujo de la ruta de conversión del usuario.

Se crea entonces el Wireframe de la nueva web, un prototipo digital, y trabajamos en la entrega

al cliente del mock-up. Estas son generalmente imágenes estáticas, que se pueden transformar
en presentaciones interactivas, para que el cliente entienda la navegabilidad y la interacción con
el usuario.

Presentación y Pruebas de entrega:

entrega : Una vez obtenida la aprobación de los clientes, se crea un
prototipo basado en la web, interactivo y navegable para confirmar la funcionalidad y la
satisfacción mediante la prueba.

Prueba de Usabilidad:
Usabilidad: La UX está enfocada en el usuario. Por esta razón, es imposible probar el
prototipo de la web sin probarlo primero en usuarios reales.

Existen muchas técnicas para evaluar el éxito de un proyecto de diseño de UX, que aplicándolas
puedes crear un informe de usabilidad, que se compartirá con el cliente, generalmente
compuesto por:
  Información sobre las pruebas realizadas: que se probó, dónde, cuándo y con qué


equipo.
  Metodología: cómo se realizó la encuesta, qué actividades se solicitaron a los usuarios,


qué datos fueron recogidos, quiénes eran los participantes y cuáles eran sus
características demográficas.
  Análisis de los resultados: la presentación de los datos recopilados consiste en gráficos,


infografías y posibles comentarios de los usuarios.

  Resultados y recomendaciones: una lectura de lo que surge a partir del análisis de datos,


incluyendo los aspectos más apreciados y negativos, junto con una propuesta para la
resolución de problemas, la optimización del diseño y la interfaz de usuario.

Análisis de Resultados:
Resultados: Después de haber hecho el producto final y de lanzarlo, es
necesario monitorizar los resultados de la web, verificar los datos de uso y la composición del
grupo de usuarios para obtener información sobre cómo mejorar la usabilidad.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 94

3.1.8.  Captura de requisitos a solicitud del cliente

Si el equipo de desarrollo tiene un conocimiento de la estructura de la organización, de las

metas, de la visión y de los clientes/usuarios o si solo se está añadiendo una nueva característica
a un sistema existente, entonces RUP no recomienda que se empiece con un Modelado del
negocio. En ese caso, RUP
R UP recomienda que se empiece con la Captura de requisitos.

Esta actividad consiste en identificar todas las necesidades de stakeholders. Como se explicó
anteriormente, el término Stakeholder se utiliza para referirse a cualquier persona o grupo que
está interesado por los resultados del proyecto.

Figura 3.2: Proceso de obtención y análisis de requisitos

Fuente.  – Tomado de https://www.slideshare.ne
https://www.slideshare.net/profesor
t/profesoryesith/proceso
yesith/procesos-de-la-ingenie
s-de-la-ingenieria-de-requisito
ria-de-requisitoss

Obtener y comprender los requisitos de los stakeholders es difícil por var

varias
ias razones:
  Los stakeholders a menudo no conocen
 co nocen lo que desean obtener del sistema informático
excepto en términos muy generales; puede resultarles difícil expresar lo que quieren
que haga el sistema o pueden hacer demandas irreales debido a que no conocen el coste
c oste
de sus peticiones.
  Los stakeholders expresan los requisitos distintos con sus propios términos de forma


natural y con un conocimiento implícito de su trabajo.

  Diferentes requisitos de diferentes stakeholders tienen concordancia y algunos generan


conflictos.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 95

3.1.9.  Captura de Actividades a partir del Diagrama de Actividades de Negocio - Caso:

El Pirata: Plantilla de MCU

Mediante la utilización del modelo del negocio como entrada, el analista emplea una técnica
sistemática 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
L as actividades que no
serán soportadas por el sistema no les corresponderán un caso de uso. Los actores se
identificarán a partir de los roles (trabajadores o actores del negocio) que realizan las actividades
del negocio a informatizar.

Figura 3.3: Del Modelo de Negocio al Modelo de Casos de Uso

Fuente.  – Tomado de https://fl
https://flylib.com/books
ylib.com/books/1/560/1/html/
/1/560/1/html/2/files/08fig04.
2/files/08fig04.gif
gif

Es importante documentar el seguimiento de estos elementos: actividades a informatizar,

requisitos funcionales y casos de uso. Más aún, si se trata de seguir requisitos funcionales de
casos de uso, el cual es un proceso complicado por el hecho de que existe una relación 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.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 96

Afortunadamente, existen herramientas de ingeniería de requisitos como el Requisite Pro y

DOORS. Pero si no tiene ningún 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 cálculo. La plantilla se proporciona en
la Tabla 3.4.

Matriz de Actividades vs Requisitos Funcionales del Sistema <Nombre_de_Sistema>

Proceso de Actividades Responsable
Requisito Caso de Uso Actores Prioridad
Negocio de Negocio de Negocio
R01
R02
R03
Tabla 3.4: Plantilla de Matriz de Actividades vs Requisitos Funcionales

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.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 97

CASO PROPUESTO: Matriz de Actividades vs Requisitos Funcionales

CASO: EL PIRATA

La cadena de videoclub “El Pirata SA” tiene un gran éxito en el mercado, pero están teniendo
algunos problemas con el grado de satisfacción de sus clientes. Por tal motivo, se desea agilizar
la atención al cliente en 30% con respecto al año 2011.

Un alquiler (CUN1) puede implicar más de una película, pero una única fecha de devolución. Por
cada alquiler se debe registrar el socio, las
l as películas, fecha de alquiler, fecha de devolución y se
calcula de forma automática la tarifa a pagar de acuerdo a los días de alquiler y si el pago es al
crédito el encargado de finanzas efectuará la correspondiente verificación de las condiciones
crediticias del socio en el sistema INFOCORP, el sistema INFOCORP muestra el estado crediticio
del socio, el encargado de finanzas envía la respuesta a la Recepcionista.

Cuando un socio devuelve (CUN2) una película con retraso deberá pagar un recargo que tiene
que abonar antes de alquilar otra película. La política de sanciones (cantidad a abonar) es
definida por el Gerente de la Cadena. Un socio no podrá alquilar una película si tiene pendiente
el pago de sanciones. También el socio debe pagar una multa si pierde o daña la cinta de vídeo.

Los socios pueden hacer reservas de película (CUN3), estén o no alquiladas. Si la película está
alquilada, el socio pasa a una cola de espera para esa película, si no está alquilada, el encargado
la retira de los estantes hasta que el socio pase a recogerla. Cuando se devuelve la película hay
que comprobar si hay reservas para avisar al socio por teléfono o e-mail. Esta comunicación la
realiza el responsable del local, para lo cual consulta en el sistema el teléfono y el e-mail; y
cuando recibe la confirmación del socio de que se enteró de la disponibilidad de la película
solicitada, lo registra en el sistema.

El socio dispone de dos días para pasar a recogerla, si no lo hace automáticamente le impondrá
un recargo y se anula la reservación. El responsable del local tiene que actualizar el sistema
cuando un socio se lleva la película. Un socio puede cancelar la reserva, lo que no supone cargo
alguno.

Además de las películas, el videoclub también alquila videojuegos (CUN4). Cada videojuego se
caracteriza por el título, temática, argumento y la plataforma sobre la que puede ejecutarse
(playstation, nintendo, PC). Los videojuegos tienen su código de barras y puede haber varias
copias de cada uno. El Gerente de compras también es el encargado de actualizar esta
información.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 98

Alquiler de Películas

Nombre Alquiler de películas

Incrementar el número de reservas en un 15%
Objetivo
Agilizar el tiempo de respuesta de aceptación en un 5%
Flujo de Trabajo
1.   El socio solicita alquiler de películas.
1.
2.   Si el socio no tiene reserva la Recepcionista verifica la disponibilidad
2.
de la película.
3.   Si la película está disponible, la recepcionista informa al cliente
3.
sobre tarifas y reglas del alquiler.
4.   Si el socio está de acuerdo con lo ofrecido, la Recepcionista solicita
4.
identificación del socio.
5.   La Recepcionista genera ticket de alquiler.
5.
6.   El socio va a cancelar a la cajera.
6.
Flujo Básico
7.   La Cajera pregunta forma de pago al socio.
7.
8.   Si el pago es a crédito, la Cajera entrega los datos al encargado de
8.
finanzas para su respectiva verificación.
9.   El encargado de finanzas efectuará la correspondiente verificación
9.
de las condiciones crediticias del socio en el sistema INFOCORP.
10.   El sistema INFOCORP muestra el estado crediticio del socio.
10.
11.   El encargado de finanzas envía la respuesta a la Cajera.
11.
12.  Si la respuesta confirma la aprobación del crédito entonces la Cajera
genera el documento de crédito.

1.   En el paso 2: Si el socio tiene reserva, la Recepcionista:

1.
a.  Consulta la reserva.
a. 
b.  Si no ha sido cancelada se continua con el paso 5, si ha sido
b. 
cancelada se continua con el paso 1.
2.   En el paso 3, Si la película no está disponible, el socio pasa a una
2.
cola de espera para esa película y termina el caso de uso.
3.   En el paso 4, si el socio no está de acuerdo con lo ofrecido termina
3.
Flujo
el caso de uso.
Alternativo
4.   En el paso 8, si el pago no es a crédito, es decir es al contado, la
4.
Recepcionista cambia el estado del ticket de alquiler (cancelado).
5.   En el paso 12, si la respuesta
5. r espuesta es negativa, la recepcionista comunica
al socio la realización del pago al contado:
a.  Si cancela al contado, la Recepcionista cambia el estado del
ticket de alquiler (cancelado).
b.  Si no cancela al contado, termina el proceso.
b. 
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

Solución:

Del enunciado podemos identificar claramente la existencia de cuatro (04) Casos de Uso de Negocio. El Diagrama de Actividades de Negocio es el siguiente:

ANÁLISIS Y DISEÑO DE SISTEMAS I 100

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 101

Por tanto nuestra matriz va quedando de la siguiente manera:

Matriz de Actividades vs Requisitos Funcionales del Sistema “El Pirata” 

Proceso de Actividades de Responsable de Requisito

Caso de Uso Actores Prioridad
Negocio Negocio Negocio (El sistema debe permitir … 

Solicita alquiler de Registrar el alquiler de CUS 01-Registrar

Socio R01 Recepcionista 7
película una película alquiler
Verifica Verificar la
CUS 02- Buscar
disponibilidad de Recepcionista R02 disponibilidad de una Recepcionista 8
película
película película
CUS 03-Buscar
Consulta reserva Recepcionista R03 Buscar una reserva reserva Recepcionista 10
Informa a cliente
Registrar tarifario de CUS 04-Consultar
sobre tarifas y Recepcionista R04 Recepcionista 10
alquiler tarifario
reglas de alquiler
Coloca al socio en Agregar socio a una cola CUS 05-Agregar socio
Recepcionista R05 Recepcionista 6
cola de espera de espera de películas a cola de espera
Gestión de Solicita
alquiler identificación de Recepcionista
socio R06 Buscar a un socio CUS 06- Buscar socio Recepcionista 10
Entrega
Socio
identificación
Genera ticket de
Recepcionista Registrar el alquiler de CUS 01-Registrar
alquiler R01 Recepcionista 7
una película alquiler
Se dirige a caja Socio
Pregunta forma de Considerar distintos CUS 07-Registrar
Cajero R07 Cajero 7
pago medios de pago Pago
Cambia estado del Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
ticket a cancelado alquiler Pago
Entrega datos al
Solicitar la validación de CUS 08-Solicitar
responsable de Cajero R09 Cajero 5
condición crediticia validación crediticia
finanzas

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 102

Matriz de Actividades vs Requisitos Funcionales del Sistema “El Pirata” 

Proceso de Actividades de Responsable de Requisito Caso de Uso Actores Prioridad

Negocio Negocio Negocio (El sistema debe permitir … 
Verifica
Responsable de
condiciones
Finanzas CUS 09-Responder
crediticias Registrar resultado de Responsable de
R10 solicitud de 5
Envía respuesta evaluación crediticia Finanzas
Responsable de evaluación crediticia
de evaluación
Finanzas
crediticia
Comunica al socio Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
pago en efectivo alquiler Pago
Genera
Registrar documento de CUS 08-Registrar
documento de Cajero R11 Cajero 6
crédito crédito
crédito
Cancela pago al Registrar el alquiler de
Socio R01 Registrar alquiler Recepcionista 7
contado una película
Gestión de
…  … 
devolución

Gestión de reserva …  … 

Actualización de
stock …  … 

La elaboración del Diagrama de Actividades de Negocio facilita la elaboración de la Matriz de

Actividades vs. Requerimientos Funcionales.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ACTIVIDADES PROPUESTAS

De la lista, clasifique los requisitos según las categorías de FURPS+.

El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en el lado

R01 del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits sin
que esto afecte el rendimiento del mismo.
El sistema debe contar con un Manual Técnico de Referencia para la Aplicación,
R02 el cual estará orientado a profesionales capacitados en aspectos técnicos del área
de sistemas.
La clave de los usuarios considerará las siguientes políticas:
   Expirar según parametrización del sistema
   Tener mínimo una longitud de 8 caracteres
R03    Contener letras y números
   No puede contener espacios
   No pueden repetirse las 3 últimas contraseñas
   No contendrá el nombre o apellido de la persona dueña del usuario
El código fuente del sistema deberá cumplir con el estándar de codificación
R04
definido en el documento “Estándares y Nomenclaturas de Código Fuente”. 
R05 Utilizar el idioma castellano para los mensajes y textos en la Interfaz.
El sistema será utilizado por clientes de todo el mundo. Adicionalmente, la
Organización Pro-Turismo exige que, para anunciar servicios en su portal, éstos
R06
deben estar provistos en español, inglés y portugués. Estos tres idiomas deben
ser soportados por el producto desarrollado.
El sistema deberá permitir la creación, modificación, activación, desactivación y
R07
autorización de los roles de usuarios definidos.
El sistema deberá prever contingencias que pueden afectar la prestación estable
y permanente del servicio. La siguiente es la lista de las contingencias que se
deben tener en cuenta y se pueden considerar críticas:
R08    Sobrecarga del sistema por volumen de usuarios.
usuari os.
   Caída del sistema por sobrecarga de procesos.
   Caída del sistema por sobrecarga de transacciones.
   Caída del sistema por volumen de datos excedido en la base de datos.
El sistema deberá contar con el manual de FAQ (Frequent Asked Questions), en
R09 línea e impreso, que es un resumen con las respuestas a las preguntas más
frecuentes que se hacen los usuarios.
R10 El sistema debe considerar en su arquitectura, el patrón de diseño MVC.
 

ANÁLISIS Y DISEÑO DE SISTEMAS I 104

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 105

3.2.   TEMA 9: MODELO DE CASOS DE USO

3.2.
El modelo de casos de uso es una forma de Ingeniería de requisitos. Este artefacto es un modelo
de las funciones deseadas para el sistema y su entorno, y sirve como contrato para el cliente y
los desarrolladores. Se utiliza como entrada esencial para las actividades de análisis, diseño y
pruebas.

El modelo de casos de uso permite:

  Que los clientes y usuarios validen
 val iden que el sistema se convierta en llo
o que esperan.
  Que los desarrolladores del sistema construyan lo que se espera.


Cada caso de uso del modelo se describe detalladamente, mostrando paso a paso, el modo en
el que el sistema interactúa con los actores y lo que el sistema hace en cada caso de uso. El
Diagrama de Casos de Uso ilustra cuáles son los roles (actores) de los usuarios y la funcionalidad
del sistema (caso de uso) requerida. De esta forma, permite ver el sistema entero como una caja
negra; se puede ver qué hay fuera del sistema y cómo reacciona a loslo s elementos externos, pero
no se puede ver cómo funciona por dentro.

Dentro de las ventajas de este modelo se puede mencionar lo siguiente:

  Delimitan el alcance del sistema.


  Dirigen todo el proceso de desarrollo, puesto que la mayoría de las actividades se



realizan a partir de los casos de uso (planificación, análisis, diseño, validación, test).
  Son usados para comunicarse con el usuario final y el experto del dominio.


  Son un mecanismo importante para soportar la “trazabilidad” entre modelos. 



  Base para el análisis, diseño, casos de prueba, glosario de términos y la guía del usuario.


  Provee entradas para el planeamiento de proyectos.



  Son usados para identificar:



o  Quién interactuará con el sistema y qué deberá hacer el sistema.

o  Qué interfaz deberá tener el sistema.
  Son usados para verificar:


o  Que se capturen todos los requerimientos.

o  Que los desarrolladores hayan entendido los requerimientos.

El modelo de casos de uso es empleado no solamente para capturar requisitos de nuevos

sistemas; pues también es utilizado cuando se desea desarrollar nuevas generaciones de
sistemas. Cuando una nueva versión 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 sese
construye mediante los siguientes pasos:
1.  Encontrar actores y casos de uso
1. 
2.  Priorizar casos de uso
2. 
3.  Detallar un caso de uso
3. 
4.  Crear prototipo de interfaz de usuario
4. 
5.  Estructurar el modelo de caso de uso
5. 

Los elementos de un modelo de caso de uso son:

  Actores.


  Casos de Uso.


  Asociaciones.

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 106

3.2.1.  Identificación de Actores

Este es uno de los primeros pasos para definir qué o quiénes interactuarán con el sistema. Antes
de indicar cómo se identifican los actores empezaremos por definirlo.

Actor

Un actor representa un rol que cierta entidad externa (humano, hardware o software) adopta
cuando interactúa con el sistema directamente.

Otras definiciones complementarias:

  Un actor representa entonces un rol, no es un usuario individual del sistema
 sistema.. Hay una
diferencia entre actor y usuario. Usuario es el que utiliza el sistema, mientras que el
actor representa un cierto rol que uno o más usuarios pueden desempeñar. Es decir, los
actores definen los roles que pueden representar los usuarios.

  Un actor es una agente, puede representar un humano, una máquina u otro sistema que
solicita un servicio al sistema.

A continuación, daremos algunos ejemplos para tener claro lo

l o que constituye un actor. Muchos
usuarios pueden desempeñar el mismo rol. Por ejemplo, la figura 3.6 muestra a dos usuarios,
Ivar y Mark, que cumplen el rol de operador de una máquina de reciclaje. Cuando ellos usan la
máquina de reciclaje cada uno es representado por una instancia del actor Operador (Técnico
encargado de manejar y hacer que funcionen ciertos aparatos).

Figura 3.4: Muchos usuarios un solo rol

Fuente. – Tomado de
https://cgrw01.cgr.go.cr/rup/R
https://cgrw01.cgr.go.cr/rup/RUP.es/Large
UP.es/LargeProjects/
Projects/core.base
core.base_rup/guidances/guide
_rup/guidances/guidelines/acto
lines/actor_6894F48D.html
r_6894F48D.html

También se puede encontrar que el mismo usuario puede ser representado por varios actores,
esto es porque la misma
m isma persona puede desempeñar roles diferentes. Por ejemplo, la figura 3.5
3 .5
muestra que un usuario desempeña dos roles: Administrador de Almacén y Obrero de almacén.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 107

Figura 3.5: Muchos roles un mismo usuario

Fuente. – Tomado de
https://cgrw01.cgr.go.cr/rup/R
https://cgrw01.cgr.go.cr/rup/RUP.es/Large
UP.es/LargeProjects/
Projects/core.base
core.base_rup/guidances/guide
_rup/guidances/guidelines/acto
lines/actor_6894F48D.html
r_6894F48D.html

¿Cómo identificar actores?

Para identificar adecuadamente a los actores

ac tores se debe verificar lo siguiente:
  No siempre está asociado con el nombre de un cargo en la planilla de la organización


objetivo. De la misma forma, el nombre no debe representar áreas ni departamentos

sino roles de ejecución.
  Cada actor debe estar asociado con, al menos, un caso de uso, sino participa en ningún


proceso debe ser eliminado.

Para identificar actores debe responder las siguientes preguntas:

  ¿Quién está interesado en cierto requisito?


  ¿Qué rol desempeña desde el punto de vista del sistema?



  ¿Qué otros sistemas interactúan con este sistema?



  ¿Quién administrará y soportará el sistema?



Cualquier individuo, grupo o fenómeno que cumpla con una o más de estas categorías es
candidato para ser un actor. La figura 63 muestra el entorno del sistema del cual se encontrarán
categorías de actores.

Definir las fronteras del Sistema

Encontrar
comprender a ellos actores ysignifica
propósito el alcancetambién definir
del sistema. Sólolas fronteras
aquellos delcomunican
que se sistema, que ayuda a
directamente
con el sistema son actores. Por ejemplo:

En un sistema de reservas de líneas aéreas, ¿quiénes podrían ser actores? Esto depende del tipo
de sistema que se construye. Si está desarrollando el sistema de reservaciones, para un agente
a gente
de viajes, el actor será el agente de viaje. El pasajero no interactúa con el sistema directamente,
entonces no será un actor.

Figura 3.6: Actores de un Sistema de Compra de Pasajes

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 108

En cambio, si está desarrollando un sistema de reservaciones, para que los pasajeros se puedan
conectar a través de Internet, el pasajero ahora sí interactuará con el sistema y se convertirá en
actor.

Figura 3.7: Actores de un sistema de Compra de Pasajes en línea

Sugerencias para identificar actores

  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 organización
objetivo.
  El nombre no debe representar áreas, departamentos o partes de una organización sino
roles de ejecución.
  Cada actor debe estar asociado con al menos un caso de uso del sistema.


  Si no participa en ningún proceso debe ser eliminado del modelo.

Breve descripción de actores

La breve descripción del actor debe incluir información sobre:

  ¿A qué o a quién representa el actor?


  ¿Por qué el actor es necesario?



  ¿Qué intereses tiene el actor en el sistema?



La breve descripción debe ser realizada en pocas líneas tanto en el Modelo de Casos de Uso 
Uso 
como en el documento Actores del Sistema.
Sistema. Por ejemplo, para una máquina de reciclado, los
actores Cliente, Operador y Administrador pueden ser descritos de la siguiente manera:

Actor Descripción

El cliente recoge botellas, latas y cajas en casa y los trae a la

Cliente
tienda para obtener a cambio un reembolso.

El operador es el responsable del mantenimiento de la

Operador
máquina de reciclado.

El administrador es responsable de las cuestiones sobre el

Administrador
dinero y el servicio que la tienda ofrece a los clientes.
Tabla 3.5: Descripción de Actores
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 109

3.2.2.  Identificación de 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 visión o de los requisitos son
deficientes, o si el sistema de análisis es vago, la funcionalidad del sistema será poco clara. Por
lo tanto, usted debe preguntarse constantemente si ha encontrado los correctos casos de uso.
Además, usted debe estar preparado para agregar, eliminar, combinar y dividir los casos de uso
antes de llegar a una versión final. Usted recibirá una mejor comprensión de los casos de uso
una vez que se han descrito en detalle.

Casos de Uso

Un caso de uso especifica una secuencia de acciones que el sistema ejecuta interactuando con
sus actores e incluyendo alternativas dentro de la secuencia. Otras definiciones
complementarias pueden ser:
  Modelo el diálogo entre los actores y el sistema.


  Es iniciado por un actor para invocar una funcionalidad del sistema.



  Es un flujo de eventos completos y significativos.



Cada caso de uso debe tener asignado un nombre descriptivo, breve, que es una frase
compuesta por verbo (infinitivo) y complemento o acción.

A medida que se identifiquen casos de uso, también se pueden encontrar algunos nuevos
actores.

Las características 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 algún tipo de valor


tangible para el actor.

  Es completo. Un caso de uso no está completo hasta que el valor final se produzca.


¿Cómo identificar Casos de Uso?

La mejor manera de encontrar casos de uso es preguntarse qué quiere el actor hacer con el
sistema. Recuerde que el sistema existe sólo 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 Análisis de
Negocio serán utilizados para empezar a identificar casos de uso.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 110

Las respuestas a las siguientes preguntas ayudarán a encontrar casos de uso:

  ¿Cuáles son las tareas de este actor?


  ¿Cuáles son los casos de uso que le darán soporte y mantenimiento al sistema?


  ¿Ante qué eventos el actor debe reaccionar?



  ¿Qué información debe dar el sistema al actor?



  ¿Cuáles con los casos de uso que soportan los procesos de negocio?


Sugerencias para identificar a los casos de uso

  Son procesos o funcionalidades del sistema.
  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 específico o caso muy particular del sistema.

Breve descripción de Casos de Uso

La breve descripción del caso de uso debe reflejar su propósito, resumiendo las acciones que
ejecuta el caso de uso al interactuar con los actores. Esta descripción se realiza, en primer lugar,
con algunas frases en el Modelo de Casos de Uso y más adelante, con una descripción paso a
paso de lo que el sistema necesita hacer cuando interactúa con sus actores, en la Especificación
de Caso de Uso.
Siguiendo con el ejemplo de la máquina de reciclado, los casos de uso R
Reciclar
eciclar artículos y Agregar
nuevo tipo de botella pueden describirse de la siguiente manera:

Caso de Uso Descripción

El usuario utiliza esta máquina de reciclado para obtener

Imprimir reporte automáticamente un recibo que indica el monto calculado por el
diario número de artículos (botellas, latas y cajas) reciclados. El recibo es
cobrado en una caja registradora (máquina).

Nuevos tipos de botellas se pueden agregar a la máquina iniciando en

"modo de aprendizaje” y la inserción de 5 muestra. De esta manera, la
Agregar tipo de
máquina puede medir las botellas y aprender a identificarlos. El
botella administrador especifica el valor de reembolso para el nuevo tipo de
botella.
Tabla 3.6: Descripción de Casos de Uso
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 111

3.2.3.  Crear el Diagrama de Casos de Uso - Caso: El Pirata

El diagrama de casos de uso muestra cómo se relacionan los casos de uso con los actores.
Pueden diseñarse varios diagramas de casos de uso, cada uno, creado en un paquete que
contiene un conjunto de casos de uso. La organización por paquetes puede ser de acuerdo a
cada proceso de negocio.

Es conveniente que los casos de uso se dibujen 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 rectángulo que representa los límites
l ímites del sistema.

El primer diagrama de casos de uso es un esbozo de la comunicación que existe entre un actor
y un caso de uso. Más adelante, se diseña una versión final agregando asociaciones entre los
casos de uso.

La siguiente figura muestra un esbozo del diagrama de casos de uso de una máquina de
reciclado. El rectángulo contiene los casos de uso que constituyen el comportamiento del
sistema.

Figura 3.7: Diagrama de Casos de Uso

El propósito primario del modelo de casos de uso es comunicar las

funciones y el comportamiento del sistema al cliente o usuario final.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 112

Caso: El Pirata

Ahora, vamos a identificar las funcionalidades del nuevo software.

En primer lugar, del Diagrama

Diagr ama de Actividades se obtiene las siguientes actividades a sistematizar:
  Registrar alquiler.


  Buscar película.



  Buscar reserva.
  Consultar tarifario.
  Agregar socio a cola de espera.
  Buscar socio.
  Registrar Pago.
  Responder solicitud de evaluación crediticia.
  Registrar crédito.

En segundo lugar, ¿Qué es lo que ha solicitado el cliente que nos ha contratado?

Ha solicitado que el registro de socios y de reservas vídeos y juegos vía web. Asimismo, si sus
clientes afiliados lo requieren, deberían actualizar sus datos vía web. Por consiguiente,
tendríamos más requisitos:
  Mantener socio.



  Consultar catálogo de películas

En tercer lugar, es necesario identificar:

  El resultado de este análisis se documenta en la Matriz de Ac

Actividades
tividades Vs. Requisitos, tal
como se muestra a continuación:
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 113

Matriz de Actividades vs Requisitos Funcionales del Sistema “El Pirata” 

Proceso de Actividades de Responsable de Requisito

Caso de Uso Actores Prioridad
Negocio Negocio Negocio (El sistema debe permitir …  

Solicita alquiler de Registrar el alquiler de CUS 01-Registrar

Socio R01 Recepcionista 7
película una película alquiler
Verifica Verificar la
CUS 02- Buscar
disponibilidad de Recepcionista R02 disponibilidad de una Recepcionista 8
película
película película
CUS 03-Buscar
Consulta reserva Recepcionista R03 Buscar una reserva Recepcionista 10
reserva
Informa a cliente
sobre tarifas y Recepcionista R04 Registrar tarifario de CUS 04-Consultar Recepcionista 10
alquiler tarifario
reglas de alquiler
Coloca al socio en Agregar socio a una cola CUS 05-Agregar socio
Recepcionista R05 Recepcionista 6
cola de espera de espera de películas a cola de espera
Gestión de Solicita
alquiler identificación de Recepcionista
socio R06 Buscar a un socio CUS 06- Buscar socio Recepcionista 10
Entrega
Socio
identificación
Genera ticket de
Recepcionista Registrar el alquiler de CUS 01-Registrar
alquiler R01 Recepcionista 7
una película alquiler
Se dirige a caja Socio
Pregunta forma de Considerar distintos CUS 07-Registrar
Cajero R07 Cajero 7
pago medios de pago Pago
Cambia estado del Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
ticket a cancelado alquiler Pago
Entrega datos al
Solicitar la validación de CUS 08-Solicitar
responsable de Cajero R09 Cajero 5
condición crediticia validación crediticia
finanzas

IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 114

Matriz de Actividades vs Requisitos Funcionales del Sistema “El Pirata” 

Proceso de Actividades de Responsable de Requisito Caso de Uso Actores Prioridad

Negocio Negocio Negocio (El sistema debe permitir …  
Verifica
Responsable de
condiciones
Finanzas CUS 09-Responder
crediticias Registrar resultado de Responsable de
R10 solicitud de 5
Envía respuesta evaluación crediticia Finanzas
Responsable de evaluación crediticia
de evaluación
Finanzas
crediticia
Comunica al socio Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
pago en efectivo alquiler Pago
Genera
Registrar documento de CUS 08-Registrar
documento de Cajero R11 Cajero 6
crédito crédito
crédito
Cancela pago al Registrar el alquiler de
Socio R01 Registrar alquiler Recepcionista 7
contado una película
Gestión de
…  … 
devolución

Gestión de
…  … 
reserva

Actualización
stock de …  … 

A partir de la Matriz de Actividades vs Requisito s Funcionales es posible identificar lo s casos de uso que serán considerados
dentro de un paquete llamado “reutilizables”. Los casos de uso que van dentro del paquete “reutilizables” son aquellos casos
de uso incluidos (CUI) por más de un caso base (CUB)
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

Estructura del Modelo de Casos de Uso

Figura 3.8: Estructura de Modelo de Casos de Uso en RSA

Actores

Figura 3.9: Actores en RSA

 

ANÁLISIS Y DISEÑO DE SISTEMAS I 116

Casos de Uso

Figura 3.10: Paquetes de Casos de Uso en RSA

Figura 3.11: Diagrama General de Casos de Uso en RSA

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 117

3.3.   TEMA 10: ESTRUCTURANDO EL MODELO DE CASOS DE USO

3.3.
Esta actividad se centra en relacionar los casos de uso y los
lo s 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 fáciles de entender.


  Extraer el comportamiento común encontrado en varios casos de uso.



  Hacer que el modelo de casos de uso sea fácil de mantener.



La ejecución de cada caso de uso incluye la comunicación con uno o más 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 asociación de comunicación con los actores. La razón de esta
norma es hacer cumplir el sistema para ofrecer
o frecer sólo la funcionalidad que los usuarios necesitan,
y nada más. 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 interacción con algún actor. En ese
caso, el caso de uso abstracto no tendrá ninguna asociación de comunicación con
actores.
  Un caso de uso hijo en una relación de generalización no necesita tener un actor


asociado a él si el caso de uso padre describe la comunicación con el actor.

  Un caso de uso base en una relación include no necesita tener un actor asociado a él si


el caso de uso incluido describe la comunicación 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 día), 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 interacción de actor se produce en el caso de
uso, éste no tendrá ninguna asociación con un actor. Sin embargo, se puede utilizar un
actor ficticio "tiempo" para mostrar cómo 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 más específicos (generalización).

  Extraer descripciones de funcionalidad (de casos de uso) adicionales u opcionales que


pueden extender casos de uso más específicos (relaciones de extensión).

  Extraer descripciones de funcionalidad (de casos de uso) adicionales e incondicionales


incluidas en la ejecución de casos de uso específicos (relaciones de inclusión)

 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 118

3.3.2.  Tipos de relaciones

Existen tres tipos de relaciones entre casos de uso: include, extend y de generalización. Entre
actores se puede utilizar solo la relación de generalización.

Relación “include” 

Una relación include

include se
 se define como la utilización 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 sólo como parte de algún caso de uso base que lo
incluye.

Esta relación se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el
comportamiento común en un caso de uso aparte y que será incluido por un caso de uso base.

Su representación gráfica con es la siguiente:

Figura 3.12: Relación “include” entre casos de uso  

Para entender la ejecución de un caso

c aso 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 descripción de un caso de uso base, llega a
un punto en donde la relación include es definida, seguirá la descripción del caso de uso incluido.
Una vez que la inclusión se lleva a cabo, la instancia del caso de uso regresará al caso de uso
base, en el punto donde se detuvo.

Figura 3.13: Ejecución de la relación de inclusión

Fuente. – Tomado de
https://cgrw01.cgr.go.cr/rup/
https://cgrw01.cgr.go.cr/rup/RUP.es/L
RUP.es/LargeProject
argeProjects/core.ba
s/core.base_rup/guidances/
se_rup/guidances/guidelines/res
guidelines/resources/include2.gif
ources/include2.gif
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 119

Relación “extend” 

Una relación extend se define como la agregación de pasos a la secuencia del caso de uso
original, que pasará a conocerse como caso de uso base. Esta extensión se realiza en puntos
indicados, llamados puntos de extensión, de manera específica 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 relación 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 representación gráfica es la siguiente:

Figura 3.14: Relación “extend” entre casos de uso  

La siguiente figura ilustra la ejecución de un caso extendido. Note que cuando una instancia del
caso de uso base, llega a un lugar en donde un punto de extensión se ha definido, la condición
en la correspondiente relación extend es evaluada. Si la condición es verdadera, la instancia
i nstancia del
caso de uso seguirá la extensión; de lo contrario, la extensión no se ejecuta.

Una vez que la instancia de caso de uso ha realizado la extensión, la instancia de caso de uso
reanuda su ejecución al caso de uso base, en el punto donde se detuvo.

Figura 3.15: Ejecución de la relación de extensión

Fuente. – Tomado de
https://cgrw01.cgr.go.cr/rup/R
https://cgrw01.cgr.go.cr/rup/RUP.es/La
UP.es/LargeProject
rgeProjects/core.base
s/core.base_rup/guidances/gui
_rup/guidances/guidelines/reso
delines/resources/exte
urces/extend2.gif
nd2.gif
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 120

Relación de “generalización” 

La generalización entre casos de uso es como la

l a generalización entre clases. En este caso significa
que el caso de uso hijo hereda el comportamiento
c omportamiento y el significado del caso de uso padre; el hijo
puede añadir o redefinir el comportamiento del padre. La relación de generalización puede
representarse también entre actores.

Su representación gráfica es la siguiente:

Figura 3.16: Relación de “generalización” entre casos de uso  

Figura 3.17: Relación de “generalización” 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.
 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 121

Figura 3.18: Ejecución de la relación de generalización

Fuente. – Tomado de
https://cgrw01.cgr.go.cr/rup/R
https://cgrw01.cgr.go.cr/rup/RUP.es/Large
UP.es/LargeProjects/
Projects/core.base
core.base_rup/guidances/guide
_rup/guidances/guidelines/resou
lines/resources/ucgen3.gif
rces/ucgen3.gif

3.3.3.  Casos de Uso Abstractos y Concretos

Se dice que un caso de uso es abstracto solo 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 operación solicitada
por el actor.

Por lo tanto, se puede 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 generalización, generalmente el caso de uso padre será abstracto debido


a que no están definidos completamente, pues los casos de uso hijos contienen las
funciones específicas requeridas por los actores.
 IES CIBERTEC S.A.C. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

ANÁLISIS Y DISEÑO DE SISTEMAS I 122

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.19: Diagrama de Casos de Uso estructurado

 ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN IES CIBERTEC S.A.C.

ANÁLISIS Y DISEÑO DE SISTEMAS I 123

CASO RESUELTO: EL PIRATA

Elabore el Diagrama de Casos de Uso Estructurado, incluyendo CUB, CUI, CUE, para el Caso El
Pirata presentado en la página 96.

Solución:

El Diagrama General de Casos de Uso Estructurado incluyendo CUB, CUI, CUE es el siguiente:

Figura 3.20: Diagrama General de Casos de Uso Estructurado

Antes de resolver el caso propuesto directamente en la herramienta Case es

recomendable realizar un pequeño bosquejo utilizando papel y lápiz.