Manual 2020 Análisis y Diseño de Sistemas I (WS2392) PDF

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.

Índice
Presentación 5
Red de contenidos 7
UNIDAD DE APRENDIZAJE 1: INTRODUCCIÓN A LA INGENIERÍA DE 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 : Herramientas 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 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

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

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 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 la 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.


Red de contenidos
ANÁLISIS Y DISEÑO DE SISTEMAS I
INTRODUCCIÓN A LA INGENIERÍA DE
SOFTWARE
• Ingeniería de Software, RUP y UML
• Herramientas CASE
DISCIPLINA DE MODELADO DE NEGOCIO

• Modelado de Negocio
• Modelo de Casos de Uso del Negocio - MCUN
• Caso propuesto del Modelo de Casos de Uso
del Negocio. Caso: Chasqui Express S.A.
• Modelo de Análisis del Negocio - MAN
• Caso Propuesto de MCUN y MAN
DISCIPLINA DE LA CAPTURA DE
REQUISITOS
• Captura de Requisitos
• Modelo de Casos de Uso
• Estructurando el Modelo de Casos de Uso


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 : Herramientas CASE

1.2.1 : Objetivos de las herramientas CASE
1.2.2 : Tipos de herramientas CASE
1.2.3 : Ejemplos de herramientas CASE

ACTIVIDADES PROPUESTAS
 Los alumnos resuelven un caso para aplicar los Diagramas UML.

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

Según la RAE1, ingeniería es el “conjunto de conocimientos orientados a la invenció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 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 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://es.slideshare.net/urielal/unidad-i-introduccion-a-la-ingenieria-de-software-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

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 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 (tanto en su forma final como durante su elaboración),
mediante un proceso apoyado por métodos y herramientas.

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
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
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
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
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
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 alcanzar
un cierto objetivo.

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
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. 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
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.

c. Fase de mantenimiento
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: Para corregir los defectos.
 Adaptativo: Para acomodarlo a los cambios de su entorno externo. (modificaciones en
la legislación, CPU, Sistema Operativo, Reglas de Negocio, etc.).
 Perfectivo: Para agregar otras funciones adicionales que van a producir beneficios.
 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
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 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.

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 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
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.

Figura 1.3: Modelo Cascada

Fuente. – Tomado de https://sites.google.com/site/proyectoadpmodelosdedesarrollo/home/modelo-en-cascada
b. Modelo de Construcción de Prototipos
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.blogspot.es/1193024400/

c. Modelo de Desarrollo Rápido de Aplicaciones (DRA)
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 Rápido de Aplicaciones

Fuente. – Tomado de http://informatica2dge1.blogspot.com/2007/03/modelo-de-desarrollo-rpido-de.html
d. Modelo Incremental
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 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.

Figura 1.6: Modelo Incremental

Fuente. – Tomado de http://marich.blogspot.es/media/cache/resolve/media/files/01/109/382/2016/03/incrementos.png
e. Modelo Espiral
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.mobincube.mobi/section22612264.html

f. Modelo de Desarrollo Concurrente
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 Concurrente

Fuente. – Tomado de http://2.bp.blogspot.com/_sfHdvu3TAuo/SP5FkT9cZWI/AAAAAAAAAA0/ekPifJ2lL54/s1600-
h/concurrente.jpg
g. Desarrollo basado en componentes
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.

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.flickr.com/photos/48425423@N06/4434551590

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: Los casos de uso son un medio para determinar los requisitos
correctos y utilizarlos para conducir el proceso de desarrollo.
 Centrado en la arquitectura: Se describe mediante diferentes vistas del sistema en

construcción.
 Iterativo e 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 (JACOSON
Ivar, 2000).
Como filosofía RUP maneja seis principios clave:

 Adaptación del 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. 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. 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. 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. 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. El control de calidad no debe realizarse al final de cada iteración,

sino en todos los aspectos de la producción.

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.ecured.cu/images/8/8d/Aup2.JPG
Modelo. El objetivo de esta disciplina es comprender el negocio de la organización, el dominio

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

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
calidad. Esto incluye encontrar defectos, validar que el sistema funciona como se diseñó y
verificar que se cumplan los requisitos.
Despliegue. El objetivo de esta disciplina es planificar la entrega del sistema y ejecutar el plan
para que el sistema esté disponible para los usuarios finales.
Gestión de la 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 administración de los cambios en ellas.
Gestión del proyecto. El objetivo de esta disciplina es dirigir las actividades 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

Medio 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://image.slidesharecdn.com/diapo01-110826210447-phpapp01/95/rup-13-728.jpg?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.
b. que los requisitos puedan ser priorizados, filtrados y monitoreados.
c. que sea posible realizar evaluaciones objetivas de funcionalidad y performance.
d. que las inconsistencias se detecten fácilmente.

RUP describe cómo:

a. Obtener, organizar y documentar la funcionalidad y restricciones requeridas.
b. Documentar y monitorear las alternativas y decisiones.
Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han demostrado ser una manera
excelente de capturar los requisitos funcionales y asegurarse que dirigen el 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 otros 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.

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 https://metodoss.com/wp-content/uploads/La-metodolog%C3%ADa-RUP-.png
a. Fases
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.
 Elaboración: Se desarrolla el plan del proyecto, la especificación de características y la
arquitectura base del sistema.
 Construcción: Esta fase se concentra en la elaboración, de un producto totalmente
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.

b. Flujos de Trabajo
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 http://www.vlaredo.galeon.com/index22.jpg
Existen dos grupos de flujos de trabajo: de proceso y de apoyo. Las que se describirán a
continuación.
c. Flujos de trabajo de proceso
Orientados al desarrollo del software. Comprende:

 Modelado del negocio: Describe la estructura y la dinámica de la organización donde se
va a implantar el sistema que construyamos.
 Requisitos: Establece exactamente lo que tiene que hacer el sistema, para ello se extrae
los requisitos utilizando diferentes métodos.
 Análisis y 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: Tiene en cuenta el desarrollo de software, las pruebas unitarias y la
integración.
 Pruebas: Describe la ejecución de pruebas y las métricas para rastreo de defectos.
 Despliegue o Implantación: Incluye actividades relacionadas con la entrega de la
aplicación.

d. Flujos de trabajo de apoyo
También conocidos como flujos de trabajo de soporte. Están orientados a la gestión del
proyecto. Éstos son:
 Configuración y Control de 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: Es el arte de lograr un balance al gestionar objetivos, riesgos y

restricciones para desarrollar un producto que sea acorde a los requisitos de los clientes
y los usuarios.
 Entorno: Cubre la infraestructura necesaria para desarrollar un sistema.

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

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 Technique) de James Rumbaugh, que era mejor para el
análisis orientado a objetos, el Método Booch de Grady Booch, el cual era mejor para el diseño
orientado a objetos, y el Método 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, 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, versión que integra varios esfuerzos para la definición de una
semántica de la especificación más 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.

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: UML permite expresar de una forma gráfica un sistema de forma que otro lo
puede entender.
 Especificar: UML permite especificar cuáles son las características de un sistema antes
de su construcción.
 Construir: A partir de los modelos especificados se pueden construir los sistemas
diseñados.
 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.

Figura 1.14: Especificaciones principales de UML 2.0

Fuente. – Tomado de https://epidataconsulting.com/tikiwiki/show_image.php?name=ArticuloUML01
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. 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): Contiene los elementos básicos del UML 2.0, entre ellos: Diagramas de
clases, Diagramas de actividades, Diagramas de Interacciones, y Diagramas de Casos de
Uso.
 Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado, Perfiles,
Diagramas de Componentes y Diagramas de despliegue.
 Completo (L3): Representa la especificación del UML 2.0 completa, como, por ejemplo:
las Acciones, Características avanzadas y PowerTypes, entre otros.
Es importante destacar que basta con 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.

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://www.uml-diagrams.org/uml-25-diagrams.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.

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

sobre el flujo de control y de datos entre los elementos del sistema modelado:
 Diagrama de secuencia.
 Diagrama de 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 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

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.net/profile/Carlos_Gonzalez235/publication/323919133/figure/fig1/AS:606749048442881@15216716
54958/Figura-28-Diagrama-de-clases-del-patron-de-diseno-MVC-Fuente-A-System-of-Patterns.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
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

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 Actividades

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 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 los 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

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

1.2. TEMA 2: HERRAMIENTAS CASE

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), 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), herramientas para automatizar tareas en el análisis y diseño de

la aplicación.
 Lower 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), 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)
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.

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
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 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 a controladores de versiones.

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 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, aunque no bajo la licencia GPL. Esta nueva versión incluye además
soporte para extensiones, compatibilidad con el sistema operativo OSX y una nueva interfaz de
usuario.

Figura 1.28: StarUML

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

Resumen
1. RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un software
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:

a. Fases:
 Inicio
 Elaboración
 Construcción
 Transición
b. Disciplinas:
 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

individuos.
4. UML es un lenguaje de modelado visual que se usa para visualizar, especificar, construir
y documentar artefactos de un sistema de software.
5. Las Herramientas CASE son 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.
Recursos
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o https://www.omg.org/
o http://www.uml.org/
o http://www.sparxsystems.com.au/resources/uml2_tutorial/
o http://staruml.io/


UNIDAD
2
DISCIPLINA DE MODELADO DE NEGOCIO
Al término de la unidad, el alumno sustenta el primer avance de su proyecto 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

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
 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.

2.1. TEMA 3: MODELADO DE NEGOCIO

La necesidad de esta disciplina surge ante el hecho de que muchos de los productos software
que se desarrollan automatizan algunos o todos los procesos existentes en un negocio, y es
necesario estudiar las implicaciones de los cambios producidos por la 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 antes.

Figura 2.1: Artefactos del Modelado de Negocio

Fuente. – Tomado de https://player.slideplayer.es/7/1675528/data/images/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.

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.


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

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
y plasmarlo en Visión del Negocio.
b. Identificar los objetivos del negocio, y documentarlos en Objetivos del Negocio. Estos
objetivos son determinados por los stakeholders y responsables del negocio y 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.
d. Elaborar una lista de términos y definiciones usados comúnmente en un Glosario del
Negocio.
Se ha preferido reunir los documentos anteriormente mencionados en el artefacto Situación del

Negocio.
2.2.2. Identificar los procesos de negocio
Requiere haber identificado los objetivos del negocio. El equipo de trabajo debe tener claras las
fronteras del negocio que está describiendo. Para ello debe identificar y priorizar los casos de
uso del negocio y los actores de negocio involucrados.
Para mostrar la interacción entre actores de negocio y casos de uso de negocio se crea un
Diagrama General de Casos de Uso de Negocio.
Por cada caso de uso del negocio, se realiza una 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.
b. Describir cómo los casos de uso del negocio soportan los objetivos de negocio.
c. Verificar que los casos de uso del negocio representan correctamente cómo el negocio
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.

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 información de los actores del negocio

identificados en el modelo de casos de uso 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 bancaria.”
Tabla 2.1: Artefactos del Modelo de Casos de Uso de Negocio

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

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 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 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 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.

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.

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

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

2.3.2. Solución del caso en Enterprise Architect - 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 Entrega de paquete Seguimiento de paquete
Figura 2.8: Casos de Uso de Negocio en EA

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

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


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

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 correspondientes.
2.4.2. Artefactos del Modelo de Análisis de Negocio: Plantilla MAN
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 de los casos de uso
del negocio. Es una abstracción de cómo los trabajadores del
negocio y las entidades de negocio se relacionan y de cómo
Modelo de Análisis de
colaboran para realizar los casos del uso del negocio.
Negocio

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

2.5. TEMA 7: CASO PROPUESTO DE MCUN Y MAN
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

Figura 2.13: Casos de Uso de Negocio en RSA
Figura 2.14: Actores de Negocio en RSA
Realizaciones de Negocio
Figura 2.15: Realizaciones de Negocio en RSA

Diagrama de Estados
Figura 2.16: Diagrama de Estados de un CDP en RSA

Diagrama de Actividades
Figura 2.17: Diagrama de Actividades en RSA

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.

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
Figura 2.19: Trabajadores de Negocio en RSA

Figura 2.20: Entidades de Negocio en RSA
Diagrama de estados
Figura 2.22: Diagrama de estados de una encuesta

Diagrama de Clases de Negocio
Figura 2.23: Diagrama de Clases de Negocio en RSA

Diagrama de Actividades de Negocio
Figura 2.24: Diagrama de Actividades de Negocio en RSA

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
uc TN
Asistente JCE
Figura 2.26: Trabajadores de Negocio en EA

class EN
Encuesta Aula Alumno Docente
Informe Empleado
Figura 2.27: Trabajadores de Negocio en EA

uc RN
RN_Encuesta a
CUN01: Encuesta a docentes
docentes
Figura 2.28: Realizaciones de Negocio en EA

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 todo 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, también llega a contactarse con “Laser Data”
por las buenas recomendaciones.
Al contactarse el cliente o el socio con la empresa, este le envía las especificaciones de la tarjeta
y cantidad al responsable de pedidos(RP) que toma el pedido, quien 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 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.

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 que genere su requerimiento de materia prima e insumo en base a la orden de producción,
dicho requerimiento es entregado al almacenero de productos en proceso, que se 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.

Resumen
1. El Modelo de Análisis es un modelo interno a un negocio.
2. En el modelo de Análisis se debe identificar los Trabajadores de Negocio, Entidades de

Negocio, y Realizaciones de Negocio.
3. Los trabajadores de negocio deben cumplir roles internos al negocio y son quienes
manipulan las entidades de negocio.
4. Las Realizaciones de Negocio está conformado por una colección de diagramas que dan
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:
o https://www.youtube.com/watch?v=X30Bt1bRsCI
o https://www.youtube.com/watch?v=jXYWTpqjJ6Y

UNIDAD
3
DISCIPLINA DE LA CAPTURA DE
REQUISITOS
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

3.3.4 : Especificación de Casos de Uso -ECU

3.3.5 : Priorización de Casos de Uso
 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.

3.1. TEMA 8: CAPTURA DE REQUISITOS

La Ingeniería de Requisitos se ocupa de la recolección, análisis, especificación y validación de los
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 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 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.

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.
 Proporcionar la base para estimar los costos y tiempos del desarrollo del sistema.
 Definir las interfaces de usuario con el sistema, enfocado a las necesidades y objetivos
de los usuarios.
3.1.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.
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
uc Actors 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.
Bibliotecario
Actor

Es un modelo que captura los requisitos funcionales de los

usuarios a un alto nivel y establece la estructura fundamental
del sistema. Es un input esencial para las actividades en
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.
2. Entender las necesidades de stakeholders.
3. Definir el sistema.
4. Administrar el alcance del sistema.
5. Refinar la definición del sistema.
6. Administrar cambios de requisitos.
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 con el sistema. En este caso, el analista crea el Modelo de Casos de Uso que
contendrá sólo los actores.
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 tanto, los stakeholder son fuentes de requisitos.
Los stakeholders son un grupo de interés cuyas necesidades deben ser satisfechas por el
proyecto. El papel puede ser desempeñado por cualquier persona que es o será potencialmente
afectado por los resultados del proyecto. Por ejemplo: usuarios finales del sistema, gerentes,
accionistas, reguladores quiénes certifican la aceptabilidad del sistema.

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.

Ejemplos:
 El sistema debe permitir registrar la información de libros de una biblioteca.
 El sistema debe permitir registrar la información de profesores que dictan los cursos de
baile.
 El sistema debe permitir registrar los horarios de dictado de clase.
 El sistema debe permitir registrar la matrícula de alumnos.
 El sistema debe 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 Requerimientos No Funcionales

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: El sistema deberá proporcionar ayudas en línea para orientar al usuario en el uso de
sus interfaces.
 R2: Maximizar eficiencia mediante la navegación con teclado.
 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.

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: 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: 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: El tiempo máximo para mostrar el reporte de cuentas por cobrar mediante un
histograma es de 10 segundos.
 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: El sistema debe operar de manera independiente del navegador que se utilice
(Microsoft Internet Explorer 6.0 o superior, Netscape 6.0 o superior, Mozilla FireFox).
 R2: El sistema deberá estar orientado a que las actualizaciones sólo se hagan en el sitio
del servidor.

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: El sistema deberá considerar en su arquitectura un modelo tres capas, donde se
definen tres componentes lógicos de manera independiente: servicios de presentación
o interfaz de usuario, servicios de funcionalidad y servicios de datos.
 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: El sistema debe desarrollarse en ASP.NET C# con framework 4.5.
 R2: La SGBD utilizado por el sistema será MySQL.
 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: El sistema deberá proporcionar, para los diferentes reportes solicitados, salidas en
documentos electrónicos (Word, Excel y PDF Acrobat).
 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.

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 especificarse los requisitos de hardware.
Por ejemplo:
 R1: Para que un cliente de la aplicación pueda ejecutar procesos, en línea, considerados
en el sistema, la estación de trabajo del usuario deberá cumplir con los siguientes
requisitos 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.

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
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.

Por el tipo de preguntas que contiene, existen dos tipos de cuestionarios: abiertos y cerrados.
 Abiertos: No presuponen ninguna respuesta particular y animan al entrevistado a hablar
sobre el problema para obtener opiniones y/o referencias.
 Cerrados: Limitan las respuestas posibles a 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

 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
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
ú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
que son intencionalmente redundantes pueden ser útiles al asegurar respuestas
consistentes por parte de quien responda.
4. Examine el cuestionario para encontrarle fallas y defectos como:
a. Interrogantes innecesarias.
b. Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de
escritura.
c. Preguntas que el sujeto no pueda responder.
d. Preguntas que están escritas de forma que se escogerá la respuesta preferida.
e. Preguntas que se interpretaran en forma diferente dependiendo del marco de
referencia de cada entrevistado.
f. Preguntas que no proporcionan opciones adecuadas de respuesta.
g. Un ordenamiento no adecuado de las preguntas y respuestas.
5. Pruébelo previamente en un Grupo pequeño para detectar otros problemas posibles.
6. Analice la respuesta del Grupo de prueba para asegurar que el análisis de los datos que
se busca se puede llevar a cabo con los datos recopilados. Si los datos no revelan algo
que el analista no conoce, el cuestionario puede no ser necesario.
7. Realice cambios finales de edición e imprímalo en una forma legible.
8. Distribuya el cuestionario. Cuando sea posible anote el nombre de cada persona.
Lluvia de Ideas
Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de generar
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.

Prototipos
Los prototipos son simulaciones o “maquetas” del posible producto software, que permite a los
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 Prototipos

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; 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
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, 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.
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. 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.

b. Diseño de la experiencia de usuario
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 casos es posible compartir con
el cliente, se generan ideas para aprovechar las oportunidades y resolver los problemas que
surgen en la fase del análisis de la investigación del usuario. Recopilamos todas las ideas,
comentarios y sugerencias del equipo de diseño, que surgen con total libertad, recogiendo
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 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: 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: 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: 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.

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 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.net/profesoryesith/procesos-de-la-ingenieria-de-requisitos
Obtener y comprender los requisitos de los stakeholders es difícil por varias razones:
 Los stakeholders a menudo no conocen 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
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.

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 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://flylib.com/books/1/560/1/html/2/files/08fig04.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.

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.

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 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.

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.
2. Si el socio no tiene reserva la Recepcionista verifica la disponibilidad
de la película.
3. Si la película está disponible, la recepcionista informa al cliente
sobre tarifas y reglas del alquiler.
4. Si el socio está de acuerdo con lo ofrecido, la Recepcionista solicita
identificación del socio.
5. La Recepcionista genera ticket de alquiler.
6. El socio va a cancelar a la cajera.
Flujo Básico
7. La Cajera pregunta forma de pago al socio.
8. Si el pago es a crédito, la Cajera entrega los datos al encargado de
finanzas para su respectiva verificación.
9. El encargado de finanzas efectuará la correspondiente verificación
de las condiciones crediticias del socio en el sistema INFOCORP.
10. El sistema INFOCORP muestra el estado crediticio del socio.
11. El encargado de finanzas envía la respuesta a la Cajera.
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:

a. Consulta la reserva.
b. Si no ha sido cancelada se continua con el paso 5, si ha sido
cancelada se continua con el paso 1.
2. En el paso 3, Si la película no está disponible, el socio pasa a una
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
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
Recepcionista cambia el estado del ticket de alquiler (cancelado).
5. En el paso 12, si la respuesta 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.

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:

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 Recepcionista 10
reserva
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


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.

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.
 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.

3.2. TEMA 9: MODELO DE CASOS DE USO

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 que el sistema se convierta en lo 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 los 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 se
construye mediante los siguientes pasos:
1. Encontrar actores y casos de uso
2. Priorizar casos de uso
3. Detallar un caso de uso
4. Crear prototipo de interfaz de usuario
5. Estructurar el modelo de caso de uso
Los elementos de un modelo de caso de uso son:

 Actores.
 Casos de Uso.
 Asociaciones.

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. 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 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

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/actor_6894F48D.html
También se puede encontrar que el mismo usuario puede ser representado por varios actores,
esto es porque la misma persona puede desempeñar roles diferentes. Por ejemplo, la figura 3.5
muestra que un usuario desempeña dos roles: Administrador de Almacén y Obrero de almacén.

Figura 3.5: Muchos roles un mismo usuario

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/actor_6894F48D.html
¿Cómo identificar actores?
Para identificar adecuadamente a los actores 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 a los actores significa también definir las fronteras del sistema, que ayuda a
comprender el propósito y el alcance del sistema. Sólo aquellos que se comunican 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
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

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
como en el documento Actores del 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

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.

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 Reciclar 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

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 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.

Caso: El Pirata
Ahora, vamos a identificar las funcionalidades del nuevo software.
En primer lugar, del Diagrama 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 Actividades Vs. Requisitos, tal

como se muestra a continuación:


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
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


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
A partir de la Matriz de Actividades vs Requisitos Funcionales es posible identificar los 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)

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

Casos de Uso
Figura 3.10: Paquetes de Casos de Uso en RSA
Figura 3.11: Diagrama General de Casos de Uso en RSA

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

Esta actividad se centra en relacionar los casos de uso y los actores del sistema, e identificar sus
comportamientos opcionales y excepcionales. Se establece las inclusiones, extensiones y
generalizaciones entre casos de uso, y las generalizaciones entre actores.
Existen tres razones para estructurar el modelo de casos de uso:

 Hacer que los casos de uso sean 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 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)

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 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 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

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/resources/include2.gif

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 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

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/resources/extend2.gif

Relación de “generalización”
La generalización entre casos de uso es como la generalización entre clases. En este caso significa
que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre; el hijo
puede 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.

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

https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/guidelines/resources/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.

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

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.

CASO PROPUESTO: COLABORA-PERU
Colabora Perú es una compañía dedicada a la prestación de servicios de atención de las

relaciones entre las empresas y sus clientes a través de Centros de Contacto Telefónico o
plataformas multicanal (IVR, SMS) para brindar diferentes servicios (Telemarketing, Tele
cobranza, Fidelización, Gestión de Datos, etc.) para aquellas empresas o instituciones que
gestionan grandes carteras de clientes o demandan una fluida relación con sus usuarios.
El principal proceso de la compañía se inicia cuando una empresa se pone en contacto con
nuestra compañía “Colabora Perú”, es atendido por un vendedor quien registra un presupuesto
previamente se verifica si la empresa ya se encuentra registrado, de no encontrarse deberá de
registrarla como nueva empresa. Posteriormente cuando el vendedor gestiona la obtención del
contrato el Jefe de Marketing registrara un contrato, previamente se obtuvo los costos del
presupuesto, detallara las especificaciones del contrato y entregara una copia a la empresa
contratante y al Gerente de Ventas.
El Gerente de Ventas envía una copia del contrato al jefe de Operaciones para iniciar la atención
del contrato, el jefe de Operaciones llama a la empresa contratante para que nos entrega la lista
de deudores a llamar por teléfono, Con la información se registra un control de trabajo, donde
se importa la data de deudores entregada, esta información se carga quedando en un estado sin
gestionar, previamente busco a la empresa para asignar los deudores Luego las tele operadoras
de tele marketing ingresan al sistema al módulo de gestión y seleccionaran la lista de deudores
a gestionar haciendo una búsqueda por control de trabajo, luego que se contactan con los
deudores y aceptan las condiciones se le cambia el estatus a gestión aceptada. Al final del día el
jefe de operaciones genera un reporte con los datos de los deudores que aceptaron la gestión,
para ser enviados a la empresa contratante, previamente hizo una búsqueda por control de
trabajo. Adicionalmente ingresa al módulo de administración de gestiones donde verifica las
gestiones de las teleoperadoras, previamente hizo una búsqueda por control de trabajo.
Mensualmente el Jefe de Operaciones registra en el sistema una factura donde detalla la

cantidad de gestiones aceptadas, previamente busco a la empresa contratante para signarle la
factura.

3.3.4. Especificación de Casos de Uso - ECU
No existe estándar UML para una especificación de caso de uso. Sin embargo, una plantilla para
una especificación sencilla de caso de uso utilizada comúnmente contiene la siguiente
información:
 Nombre del caso de uso.
 Breve descripción.
 Actores implicados en el caso de uso.
 Flujo de eventos. Incluye el flujo básico, sub-flujos y flujos alternativos.
 Precondiciones.
 Pos condiciones.
 Puntos de extensión.
 Requisitos especiales.
 Prototipos.
A continuación, se detalla cómo se debe de registrar la Especificación de caso de uso:
ESPECIFICACIÓN DE CASOS DE USO

Nombre Indicar el nombre y codificación del CU
Actores Indicar el actor(es) relacionados a este CU
Propósito Indicar el propósito de CU
Breve descripción Breve descripción
Indicar las condiciones que deben cumplirse antes de iniciar el
Precondición
CU
Indicar las condiciones que se han cumplido luego de ejecutar
Poscondición
el CU
Indicar el evento que inicia el CU.
Evento disparador Ejemplo: El caso de uso inicia cuando el recepcionista pulsa el
botón “Registrar Solicitud”
Indicar la secuencia de actividades que siguen al evento
Flujo Básico
disparador
Indicar la secuencia de actividades de los sub-flujos si los
Sub-Flujos
hubiera
Indicar la secuencia de actividades de los flujos alternos si los
Flujos Alternos
hubiera
Puntos de extensión Indicar los puntos de extensión si los hubiera.
Requerimientos Funcionales Indicar que requerimientos funcionales son atendidos por el
asociados presente CU
Requerimientos especiales Indicar si existen otros requerimientos a considerar.
Prototipos
Agregar los prototipos elaborados en función a la ECU

Figura 3.21: Plantilla para especificación de Caso de Uso
3.3.5. Priorización de Casos de Uso
Es la actividad de arquitectura y planificación de proyecto el cual consiste en clasificar los casos

de uso según su importancia para establecer el orden de realización de los mismos. En este
sentido, los casos de uso con significado arquitectónico se identifican y se priorizan. Una vez que
se han priorizado los casos de uso, se puede decidir el orden de desarrollo del sistema.
Se establecen períodos, ciclos o iteraciones de trabajo para desarrollar la realización de los casos
de uso. Se distribuyen los casos de uso en cada ciclo de trabajo; los casos de uso primarios deben
realizarse en primer orden y, luego, los secundarios. Los casos de uso opcionales se deben dejar
para el final de la realización.
Objetivos
El propósito de otorgarles prioridad a los USE CASE es identificar los casos de uso primarios para
la presente etapa de desarrollo del proyecto. Según estos criterios, se determinan los casos de
uso críticos para especificarlos en esta etapa del proyecto.
Alcance
Dar prioridad permitirá darle la debida atención (y con más tiempo) a los USE CASE más
complejos e importante.

Priorización
Distingue a los USE CASE críticos o primarios de los secundarios. Más adelante, se especifica el
criterio utilizado para determinar cuáles son primarios y cuáles son secundarios.
 Nivel crítico (o primario)
Agrupa a los USE CASE que tienen que ver con las funciones básicas del sistema.
 Nivel de baja importancia (o secundario)
Agrupa a los USE CASE que tienen que ver con las funciones de soporte del sistema y que no
representan mayor riesgo para el proyecto.
Factores considerados en la priorización
Se tomaron en cuenta pesos (que representan porcentaje) por cada factor que afecta a cada
USE CASE. Los valores que pueden tomar los factores están en la escala del 1 al 10 (1: menor
importancia; 10: mayor importancia). Se considerarán primarios a aquellos USE CASE que tengan
un puntaje mayor a 6.5, ya que esto significa que superan el 65% de prioridad en el sistema
(PONDERACIÓN):
 Importancia en el proceso del negocio: Indica la relevancia que tiene la funcionalidad
con el proceso de negocio. Una alta puntuación revela que las transacciones de la
empresa se apoyan considerablemente en la funcionalidad que tiene este USE CASE. Su
ponderación es 0.4.
 Complejidad de desarrollo: Indica la dificultad que se percibe del USE CASE, en cuanto
a las tareas de análisis, diseño, implementación, pruebas e integración del mismo. Su
 Riesgo asociado: Indica la relación que se percibe entre el USE CASE y la lista de riesgos.
Un alto valor en este factor indica que el caso de uso tiene bastantes riesgos o riesgos
de alto valor asociados. Los USE CASE con alto valor en este factor pueden ser
considerados primarios debido a que deben ser enfrentados en las etapas iniciales. Su
 Impacto de los requerimientos no funcionales: Indica cómo afectan los requerimientos

no funcionales (usability, reliability, performance, supportability) al proceso del negocio
y en qué manera el USE CASE se vería comprometido. Su ponderación es 0.1.

CASO RESUELTO: SIRI TOURS
La agencia de viajes SIRI TOURS es una agencia que se dedica a la venta de pasajes, reserva de
hoteles y paquetes de viajes.
La venta de pasajes inicia cuando un cliente se acerca al counter de atención. Una vez dentro,
solicita un ticket de atención y espera su turno de ser atendida. Llegado su turno, se acerca a la
ventanilla y pregunta los horarios que hay disponibles para un determinado destino. El asistente
de ventas le informa sobre los horarios disponibles y los tipos de servicio que contiene cada uno
de ellos, pudiendo ser: económico, ejecutivo, y vip. El cliente selecciona uno de los horarios
ofrecidos y le indica al asistente de ventas el número de pasajes que desea comprar. El asistente
de ventas realiza la reserva y la confirmación de la misma. El asistente le pregunta al cliente si
existe algún tipo de restricción en relación a la comida para los pasajeros. Si las hay, el asistente
registra las restricciones y luego solicita la modalidad de pago. El cliente procede a indicar la
modalidad y a realizar el pago. El asistente procede a emitir el comprobante de pago y luego a
la impresión de los pasajes. El cliente recibe los pasajes y procede a retirarse del counter.
ECUN: Venta de Pasajes
Flujo Básico
1. El cliente se acerca a ventanilla y pregunta los horarios que hay de salida para su destino
deseado.
2. La asistente de ventas informa sobre los horarios y tipos de servicios que tienen cada
uno de ellos.
3. El cliente selecciona uno de los horarios y servicios ofrecidos, indicando el número de
pasajes deseados.
4. La asistente de ventas procede a reservar y confirmar los pasajes requeridos.
5. La asistente de ventas pregunta sobre algún tipo de preferencia y/o restricción de los
pasajeros en la alimentación a brindarse durante el servicio.
6. El cliente indica preferencias y/o restricciones en la alimentación de cada uno de los
pasajeros para los que está adquiriendo sus boletos.
7. La asistente de ventas procede a registrar las preferencias y/o restricciones indicadas.
8. La asistente de ventas informa el monto a pagar y pregunta modalidad de pago que
prefiere el cliente.
9. El cliente indica modalidad de pago deseada y procede a realizar el pago.
10. La asistente de ventas procede a emitir los pasajes solicitados.
11. El cliente recibe los pasajes con la conformidad de los mismos y finaliza el proceso.
Ejercicio:
Utilizando la plantilla proporcionada elabore la ECU del ECUN “Venta de pasajes”.

Solución:

Nombre Registrar venta de pasaje.
Actores Vendedor.
Propósito El objetivo del CU es permitir registrar la comprar de uno o más pasajes.
El CU permite a un vendedor registrar la venta de uno o más pasajes
Breve descripción
para uno o más personas.
Pre-condición El vendedor debe haber sido validado como usuario del sistema.
El vendedor ha registrado la venta de uno o más pasajes dentro en el
Post-condición
sistema.
Evento disparador El caso de uso inicia cuando el vendedor pulsa el botón “Nueva Venta”.
1. El sistema muestra formulario de registro de venta.
2. El vendedor ingresa los datos necesarios para la búsqueda de
pasajes (lugar de partida, fecha de partida, lugar de retorno,
fecha de retorno, número de pasajeros).
3. El vendedor pulsa el botón “Buscar”.
4. El sistema muestra el listado de vuelos disponibles que
cumplen con los criterios de búsqueda.
5. El vendedor selecciona el vuelo deseado y pulsa el botón
“Continuar”.
6. El sistema muestra listado de vuelos de partida y el costo
asociado a cada uno de ellos.
7. El vendedor selecciona el vuelo de partida y pulsa el botón
“Continuar”.
8. El sistema muestra listado de vuelos de retorno y el costo
asociado a cada uno de ellos.
Flujo Básico
9. El vendedor selecciona el vuelo de retorno y pulsa continuar.
10. El sistema muestra formulario para registrar los datos
personales del pasajero (DNI, nombres, apellidos, dirección,
teléfono, email).
11. El vendedor registra los datos solicitados por cada pasajero
solicitado. Al finalizar pulsa el botón “Pagar”.
12. El sistema muestra formulario para el registro del pago.
13. El vendedor registra los datos de la tarjeta de crédito con la
que se efectúa la compra y pulsa el botón “Finalizar”.
14. El sistema muestra información de resumen de la compra
realizada y solicita al vendedor confirmar la compra.
15. El vendedor confirma la comprar pulsando el botón “Aceptar”.
16. El sistema registra la compra y envía confirmación por correo
electrónico al vendedor y a cada uno de los pasajeros. El Caso
de Uso termina.
Sub-Flujos Ninguno.
En el paso 16: Si se presentan problemas en el registro de la compra el
Flujos Alternos sistema muestra mensaje de error: “Problemas durante el registro de
pago. Favor de contactarse con su banco”.
Si la facturación se debe realizar a otra persona, el vendedor selecciona
Puntos de extensión la opción “Cambiar datos de facturación”, inmediatamente el sistema
invoca al caso de uso “Registrar datos de Facturación”.
RF08: El sistema debe permitir registrar la venta de uno o más pasajes.
Requerimientos
RF10: El sistema debe permitir que los datos de facturación estén a
Funcionales asociados
nombre de una persona diferente a la de los pasajeros.
Requerimientos especiales Ninguno.


Prototipos

CASO PROPUESTO: RESTAURANTE EL TOYITO
Atención de Clientes
El proceso general de Atención de cliente cuenta con varios sub procesos que son efectuados
por: El Maitre, los mozos, el cantor, el cocinero y el cajero. El cliente es recibido por el Maitre
quien pregunta si cuenta con Reserva, verifica su Libro de Reservas y coloca la Reserva como
Realizada. De no contar con una reserva, el Maitre consulta la disponibilidad de las mesas en su
Mapa de Mesas y asigna una mesa disponible del comedor al comensal.
El Maitre conducirá al cliente a la mesa, asigna a un mozo para la atención y deja una
Carta/Menú al Cliente. El cliente consulta la carta/menú y hace su pedido al Mozo. El mozo anota
el pedido del cliente en un documento llamado Comanda y entrega una copia a la cocina.
El Cantor revisa la Comanda con el pedido y distribuye: Si el pedido incluye bebidas gaseosas,
las despacha personalmente, si el pedido es de platos para preparar “canta” la orden al cocinero
quien prepara el mismo, una vez que en la cocina es preparado el pedido, el cantor coloca un
visto en la comanda en señal de conformidad como pedido preparado.
El mozo recibe los platos ubicados en un mostrador y sirve los mismos al cliente, el mozo visa el
original de la comanda como pedido atendido y entrega una copia al cajero para que
posteriormente genere la cuenta del cliente.
El cliente consumirá el plato servido y podrá repetir el proceso de pedido en varias

oportunidades (se generará una comanda por cada pedido extra). Una vez terminado su
consumo solicitará la cuenta al Mozo, éste le traerá un documento llamado Adelanto de Cuenta,
el cual tendrá el detalle de lo consumido, el cliente lo verifica y de ser conforme procederá a
realizar el proceso de Cancelación del Consumo al Mozo asignado.
Cobranza por Servicios
El cajero consulta el pedido (que normalmente contiene varias comandas) para obtener el
monto a cobrar. Una vez realizado el pago por el cliente, el cajero genera el documento, registra
el pago y le entrega al mozo el documento con el sello de cancelado.
El mozo se encargará de llevar a la mesa tanto el documento (Boleta o Factura) como el vuelto
respectivo, cerrando así el proceso de cobranza y el proceso de Atención.

ECUN: Atención de Clientes
Flujo de Trabajo
Flujo Básico
1. El caso de uso inicia cuando el cliente llega y solicita servicio.

2. El maitre recibe al cliente y le pregunta si cuenta con reserva.
3. Si el cliente cuenta con reserva, el maitre verifica su Libro de reservas y coloca la reserva
como realizada.
4. El maitre conducirá al cliente a su mesa.
5. El maitre le ofrece algo de beber y si el cliente desea, el maitre llena la comanda y la
lleva al bar y a caja.
6. El maitre asigna un mozo para la atención.
7. El mozo lleva las bebidas a la mesa del cliente y le entrega la carta/Menú y el proceso
termina.
Flujo Alternativo
1. En el punto 1.1.3 si el cliente no cuenta con reserva. El maitre consulta la disponibilidad

de las mesas en su Mapa de Mesas y asigna una mesa disponible del comedor y continua
al paso 1.1.4.
2. En el punto 1.1.5 si el cliente no desea aún algo de beber, el maitre le entrega la
carta/menú, asigna un mozo para la atención y el proceso termina.
Ejercicio:
1. Utilizando la plantilla proporcionada elabore la ECU del ECUN “Atención de clientes”.

2. Elabore el Modelo de Casos de Uso.
3. Elabore el Diagrama General de Casos de Uso Estructurado.
4. Elabore la ECU de una funcionalidad del Sistema Sócrates.

Resumen
1. El Modelo de Casos de Uso permite representar las funcionalidades del sistema a
implementar.
2. En el modelo de Casos de Uso se debe identificar a los actores y a los casos de uso, que
son los elementos relevantes del modelo.
3. En el Modelo de Casos de Uso se crean los siguientes diagramas:

 Diagrama General de Casos de Uso.
 Diagrama de Actores.
 Diagrama de Casos de Uso por Proceso de Negocio.
4. En un Diagrama de Casos de uso se pueden presentar hasta tres tipos de relaciones:

“include”, “extend” y “generalización”.
5. En una relación de generalización, el caso de uso hijo hereda la estructura,

comportamiento y las relaciones del padre.
6. En una relación include, el caso de uso incluido encapsula el comportamiento necesario

y es reutilizado por varios casos base
7. En una relación extend, el caso de uso extendido encapsula el comportamiento opcional

de un caso base.
Recursos
Puede revisar los siguientes enlaces para ampliar los conceptos vistos en esta unidad:
o Metodología RUP (Rational Unified Process)
https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/index.htm#core.base_rup/guidances/s
upportingmaterials/welcome_2BC5187F.html
o Modelo de Casos de Uso:
https://cgrw01.cgr.go.cr/rup/RUP.es/SmallProjects/core.base_rup/workproducts/rup_usec
ase_model_EF15E534.html
o Tutorial usando Rational Software Architect (RSA)
https://www.youtube.com/watch?v=CC_5hJxdISM
https://www.youtube.com/watch?v=tR6kv22sxc8

Bibliografía
 Booch Grady, Rumbaugh James y Jacobson Ivar (2006). El Lenguaje Unificado de
Modelado – UML 2.0. Madrid: Pearson – Addison Wesley – 2da. Edición.
(005.117 BOOC 2006)
 Quatrany Terry y Palistrant Jim (2006). Visual Modeling with IBM Rational Software
Architect and UML Upper Saddle River. NJ: IBM Press.
(005.118 QUAT/V)
 Jacobson Ivar, Booch Grady y Rambaugh James (2000). El Proceso Unificado de

Desarrollo de Software. Madrid: Pearson Educación.
(005.1068 JACO)
 Pressman Roger (2010). Ingeniería del Software: un enfoque práctico. Madrid: MC Graw-
Hill.
(005.1 PRES 2002)
 Sommerville Ian (2011). Ingeniería del Software. México: Pearson Educación – 9na
Edición.
 Bruegge, Bernd y Dutoit, Allen (2002). Ingeniería de Software Orientada a Objetos.

México, D.F.: Pearson Educación.
(005.117 BRUE)
 Stevens, Perdita y Pooley Rob (2002). Utilización de UML en Ingeniería del Software con
Objetos y Componentes. Madrid: Pearson Educación.
(005.117 STEV)
 Craig Larman (2010). Uml y Patrones. Prentice Hall.
 Visión General de la Metodología RUP

https://sceweb.uhcl.edu/helm/RationalUnifiedProcess/
 RUP mejores practicas

https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/12
51_bestpractices_TP026B.pdf
 Acceso a la página oficial de UML

https://www.uml.org/

Manual 2020 Análisis y Diseño de Sistemas I (WS2392) PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Manual 2020 Análisis y Diseño de Sistemas I (WS2392) PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Análisis y Diseño de

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

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

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

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

1.2 Tema 2 : Herramientas CASE 39

UNIDAD DE APRENDIZAJE 2: DISCIPLINA DE MODELADO DE NEGOCIO 45

2.1 Tema 3 : Modelado de Negocio 47

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

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

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

2.5 Tema 7 : Caso Propuesto de MCUN y MAN 63

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

3.1 Tema 8 : Captura de Requisitos 79

3.2 Tema 9 : Modelo de Casos de Uso 105

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

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

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

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

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

ANÁLISIS Y DISEÑO DE SISTEMAS I

DISCIPLINA DE MODELADO DE NEGOCIO

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

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

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

1.2 Tema 2 : Herramientas CASE

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

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

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

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

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

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

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

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

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

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

1.1.1. Elementos claves de la Ingeniería de Software

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

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

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

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

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

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

1.1.2. Fases de un proceso software

Definición Desarrollo Mantenimiento Gestión

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

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

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

Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas

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

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

1.1.3. Modelos de Proceso de Software

Existen algunos problemas que ocurren al utilizar este modelo:

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

Figura 1.3: Modelo Cascada

b. Modelo de Construcción de Prototipos

Figura 1.4: Modelo de Construcción de Prototipos

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

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

Figura 1.5: Modelo de Desarrollo Rápido de Aplicaciones

El primer incremento es un producto esencial, se afrontan requisitos básicos, pero muchas

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

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