Análisis y Diseño

de Sistemas I
ANÁLISIS Y DISEÑO DE SISTEMAS I 2

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 3

Página

Índice
Presentación 5
Red de contenidos 7
Unidad de Aprendizaje 1
INGENIERÍA DE SOFTWARE, RUP Y UML 9
1.1 Tema 1 : Ingeniería de Software, Metodología RUP y UML 11
1.1.1. : Elementos claves de la Ingeniería de Software 12
1.1.2. : Las fases genéricas de un proceso de software 13
1.1.3. : Modelos de Proceso de Software 14
1.1.4. : Metodología RUP (Rational Unified Process -RUP) 19
1.1.5 : Mejores Prácticas de RUP 20
1.1.6. : Estructura de RUP 22
1.1.7. : Modelamiento Visual empleando el (UML) 25
1.1.8. : El Lenguaje de Modelamiento Unificado 26
1.1.9. : Diagramas de UML 2.0 30
1.2 Tema 2 : Herramienta Case y Entorno de IBM RSA 39
1.2.1. : Objetivos de las herramientas C.A.S.E. 39
1.2.2. : Tipos de herramientas C.A.S.E. 39
1.2.3. : Ejemplos de herramientas C.A.S.E. 39
1.2.4 : Rational Software Architect 42

Unidad de Aprendizaje 2
DISCIPLINA DEL MODELADO DEL NEGOCIO 43
2.1 Tema 3 : Modelado del Negocio 45
2.1.1. : ¿Cuándo será necesario hacer el Modelado de Negocio? 45
2.1.2. : ¿Cuándo no será necesario hacer el Modelado de Negocio? 46
2.1.3. : Actividades para realizar un Modelado de Negocio 46
2.2 Tema 4 : Modelo de Casos de uso del Negocio 48
2.2.1. : Determinar la situación de la organización 48
2.2.2. : Identificar los procesos de negocio 48
2.2.3. : Refinar las definiciones de los procesos de negocio 48
2.2.4. : Artefactos del Modelo de Casos de uso del negocio 49

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 4

2.3 Tema 5 : Modelo de Análisis de Negocio 50

2.3.1. : Diseñar las realizaciones de los procesos de negocio 50
2.3.2. : Artefactos del Modelo de Análisis del negocio 51

Unidad de Aprendizaje 3
DISCIPLINA DE LA CAPTURA DE REQUISITOS 63
3.1 Tema 6 : Captura de requisitos 65
3.1.1. : Artefactos de la Captura de Requisitos 65
3.1.2. Actividades para realizar la Captura de Requisitos 67
3.1.3. : Requerimientos 68
3.1.4. Requisitos FURPS 69
3.1.5. Técnicas para capturar requisitos 72
3.1.6. : Captura de requisitos a solicitud del cliente 76
3.1.7. : Captura de requisitos a partir del diagrama de actividades del 77
negocio
3.2 Tema 7 : Modelo de casos de uso. 84
3.2.1. : Encontrar actores y casos de uso 85
3.2.2. Encontrar actores 85
3.2.3. : Encontrar casos de uso 88
3.2.4. Crear el Diagrama de casos de uso 90
3.3 Tema 8 : Estructurando el modelo de casos de uso. 94
3.3.1. : Objetivos 94
3.3.2. Tipos de relaciones 95
3.3.3. Casos de uso abstractos y concretos 98
3.3.4. : Especificaciones de casos de uso 100
3.3.5. : Priorización de los Casos de Uso 108

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 5

Presentación
Análisis y Diseño de Sistemas I pertenece a la línea formativa y se dicta en las
carreras de Computación e Informática, Administración y Sistemas. El curso
imparte conocimientos relacionados con el proceso de Ingeniería de Software
Orientado a Objetos que permite a los alumnos utilizar una metodología y el
lenguaje de modelamiento unificado 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 semanas determinadas. En cada una
de ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema tratado,
el cual será ampliamente desarrollado; y los contenidos, que debe desarrollar, es
decir, los subtemas. Por último, encontrará las actividades que deberá desarrollar
en cada sesión, que le permitirán reforzar lo aprendido en la clase.

El curso es teórico práctico: 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 RUP. Continúa con la presentación del
modelamiento visual y el lenguaje de modelamiento unificado UML. Luego, se
desarrolla la disciplina del Modelado del Negocio. Por último, se concluye con el
desarrollo de la disciplina de la Captura de Requisitos.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 6

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 7

Red de contenidos

Análisis y Diseño de Sistemas I

Ingeniería de Disciplina del Disciplina de la

Software, RUP y Modelado del Captura de
UML Negocio Requisitos

Ingeniería Modelado Captura de

de del Negocio Requisitos
Software
Modelo de
Casos de Uso Modelo de
Herramientas del Negocio Casos de
CASE Uso

Modelo de
Análisis del Estructuración del
Negocio modelo de casos
de uso

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 8

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 9

UNIDAD

1
INGENIERÍA DE SOFTWARE,
METODOLOGÍA RUP Y UML
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno, a partir del correcto entendimiento de la
importancia del papel que cumple la Ingeniería de Software dentro de las
organizaciones, describe las ventajas y desventajas de los modelos de
procesos de desarrollo de software y la importancia de emplear metodología
RUP para el correcto modelado del ciclo de vida de un software. Asimismo, el
alumno describe los diagramas de UML y utiliza la herramienta CASE Rational
Software Architect.

TEMARIO
1.1 Tema 1 : Ingeniería de Software, Metodología RUP y UML
1.1.1. : Elementos claves de la Ingeniería de Software
1.1.2. : Las fases genéricas de un proceso de software
1.1.3. : Modelos de Proceso de Software
1.1.4. : Metodología RUP (Rational Unified Process - RUP)
1.1.5. : Mejores Prácticas de RUP
1.1.6. : Estructura de RUP
1.1.7. : Modelamiento Visual empleando el (UML)
1.1.8. : El Lenguaje de Modelamiento Unificado
1.1.9. Diagramas de UML
1.2 Tema 2 : Herramienta Case y Entorno de IBM RSA
1.2.1. : Objetivos de las herramientas C.A.S.E.
1.2.2. : Tipos de herramientas C.A.S.E.
1.2.3. : Ejemplos de herramientas C.A.S.E.
1.2.4. : Rational Software Architect

ACTIVIDADES PROPUESTAS
 Los alumnos resuelven un caso para aplicar los diagramas de UML.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 10

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 11

1.1 TEMA 1: INGENIERÍA DE SOFTWARE

Según el DRAE1, ingeniería es el “Estudio y aplicación, por especialistas, de las
diversas ramas de la tecnología.”, también es la “Actividad profesional del ingeniero” y
el término ingeniero lo define como “Persona que profesa la ingeniería o alguna de
sus ramas.”; mientras que en el diccionario El pequeño Larouse, ingeniería es el
“Conjunto de conocimientos y técnicas científicos aplicados a la invención,
perfeccionamiento y utilización de la técnica industrial en todas sus dimensiones”.

Por otro lado, en el DRAE encontramos que software es el “Conjunto de programas,

instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.”

Uniendo todas estas definiciones, podemos establecer que la ingeniería de software

es el “Uso o aplicación de conocimientos y técnicas científicos para crear programas
de computadora”.

La ingeniería de software puede ser definida de múltiples maneras. Es por ello que
existen muchas definiciones expuesta por autores acreditados que comenzaron en su
momento a utilizar el término, entre ellos Bauer, Boehm, Zelkovitz y Sommerville y
otras dadas por organismos internacionales profesionales de prestigio tales como
IEEE2 o ACM3. Más adelante la definición fue incluyendo el término de calidad,
mejorando así la definición de la Ingeniería de Software.

Se ha elegido la definición utilizada por Roger Pressman, quién 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 Roger Pressman.

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

ingeniería del 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 del software. El proceso
define un marco de trabajo para un conjunto de áreas clave de proceso que se deben
establecer para la entrega efectiva de la tecnología de la ingeniería del 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
DRAE, Diccionario de la Real Academia Española de la Lengua.
2
IEEE, Institute of Electrical and Electronics Engineers.
3
ACM, Association for Computing Machinery.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 12

Los métodos de la ingeniería del software indican «cómo» construir técnicamente el

software. Los métodos 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.

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

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

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

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 13

1.1.1.5 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. Las fases genéricas de un proceso de 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
Fallos de definición

MANTENIMIENTO
Errores

Modificaciones y adaptaciones

Figura 1.2.- Fases genéricas de un proceso de software.

1.1.2.1. 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 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 del software
 Análisis de requisitos

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 14

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

1.1.2.3. 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, SO, las 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.

1.1.2.4. Actividades de protecció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
 Gestión de riesgos

1.1.3. Modelos de proceso de software

Para resolver los problemas reales de una industria, un ingeniero del software o un
equipo de ingenieros debe incorporar una estrategia de desarrollo que 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 Ingeniería del
Software. Se selecciona un modelo de proceso para la ingeniería del software según la
naturaleza del proyecto y de la aplicación, los métodos y las herramientas a utilizarse,
y los controles y entregas que se requieren.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 15

Existen muchos modelos de procesos para la ingeniería de software, entre ellos:

 Modelo Lineal Secuencial (Ciclo de Vida Básico o Modelo de Cascada)

 Modelo de Construcción de Prototipos
 Modelo DRA (Desarrollo Rápido de Aplicaciones)
 Modelos Evolutivos de Procesos de Software:
o El modelo incremental
o El modelo espiral
o El modelo de desarrollo concurrente
 Desarrollo basado en componentes

1.1.3.1 Modelo Lineal Secuencial

Llamado algunas veces ciclo de vida básico 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 el
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 él
lo hace a través de todo el proceso y esto complica las cosas.
 El cliente debe tener paciencia. La primera versión del software llega al final del
proceso, a veces el afán del cliente hace que la aplicación final no cumpla con
los requisitos

Análisis Diseño Código Prueba Mantenimiento

Figura 1.3.- Modelo Lineal Secuencial.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 16

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.

Escuchar al Construir y revisar la

cliente maqueta

El cliente prueba la
maqueta

Figura 1.4.- Modelo de Construcción de Prototipos.

1.1.3.3 Modelo 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 Construcción de Prototipos.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 17

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

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 18

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

1.1.3.6 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
Concurrente es la capacidad de describir las múltiples actividades del software que
ocurren simultáneamente.

Dado que los requisitos cambian es muy probable que una vez 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.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 19

1.1.3.7 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. Casi 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.- Desarrollo Basado en Componentes.

1.1.4. Metodología RUP (Rational Unified Process -RUP)

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

software que define claramente quien, cómo, cuándo y qué debe hacerse en el
proyecto. Presenta tres características esenciales:
 Dirigido por Casos de Uso: Orientan el proyecto a la importancia para el
usuario y lo que éste quiere.
 Centrado en la arquitectura: Relaciona la toma de decisiones que indican cómo
tiene que ser construido el sistema y en qué orden.
 Iterativo e incremental: Divide el proyecto en mini proyectos donde los casos
de uso y la arquitectura cumplen sus objetivos de manera más depurada.

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 del mismo, 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.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 20

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

Desarrollo Iterativo

Administración Verificación
de Requisitos Modelamiento Continua de la
Visual Calidad

Control de Cambios

Figura 1.10.- RUP – Mejores prácticas.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 21

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

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

Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han demostrado ser
una manera excelente de capturar los requisitos funcionales y asegurarse que dirigen
el 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 como 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 como representar el software visualmente para capturar la estructura y
comportamiento de arquitecturas y componentes. Las abstracciones visuales ayudan a
comunicar diferentes aspectos del software; comprender los requisitos, ver como los
elementos del sistema se relacionan entre sí, mantener la consistencia entre diseño e
implementación y promover una comunicación precisa. El estándar UML (Lenguaje de
Modelado Unificado), creado por Rational Software, es el cimiento para un
modelamiento visual exitosa.

 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 como
automatizar la integración y administrar la conformación de releases.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 22

1.1.6. Estructura de RUP

RUP es un proceso que puede describirse en dos dimensiones, tal como se muestra
en la figura 1.11, a lo largo de dos ejes:

 El eje horizontal representa tiempo y muestra el aspecto 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.11.- Estructura de RUP.

1.1.6.1. Fases
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias
iteraciones en 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.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 23

1.1.6.2. 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.12.- Elementos de RUP que describen el Flujo de Trabajo.

Existen dos grupos de flujos de trabajo: de proceso y de apoyo. Las que se describirán
a continuación.

1.1.6.3. Flujos de trabajo del 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.

1.1.6.4. Flujos de trabajo de apoyo o de soporte

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.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 24

1.1.6.5. Roles en RUP

Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de
individuos trabajando juntos como un equipo. Un miembro del equipo de proyecto
cumple normalmente muchos roles. Las responsabilidades de un rol son tanto el llevar
a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos.
Por ejemplo, la figura 1.13 ilustra el rol del arquitecto de software.

Figura 1.13.- Arquitecto de Software.

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

Analistas:
 Analista de procesos de negocio.
 Diseñador del negocio.
 Analista de sistema.
 Especificador de requisitos.

Desarrolladores:
 Arquitecto de software
 Diseñador
 Diseñador deinterfaz de usuario
 Diseñador de cápsulas
 Diseñador de base de datos
 Implementador
 Integrador

Gestores:
 Jefe deproyecto
 Jefe de control de cambios
 Jefe de configuración
 Jefede pruebas
 Jefe de despliegue
 Ingeniero de procesos
 Revisor degestión del proyecto
 Gestor de pruebas

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 25

Apoyo:
 Documentadortécnico
 Administrador de sistema
 Especialista enherramientas
 Desarrollador de cursos
 Artistagráfico

Especialista en pruebas:
 Especialista en Pruebas(Tester)
 Analista de pruebas
 Diseñador de pruebas

Otros roles:
 Stakeholders
 Revisor
 Coordinación derevisiones
 Revisor técnico

1.1.7. El modelamiento visual

El Modelado Visual es el modelado de una aplicación usando notaciones gráficas.

Pero, ¿qué tan importante es construir el modelo de una aplicación? En este sentido
comúnmente se hace la comparación hacia la arquitectura tradicional, en la
construcción de casas. Aun cuando la construcción que se planee hacer sea una casa
sencilla, el resultado será más satisfactorio si se cuenta con todo un respaldo en un
correcto diseño.

Booch compara la construcción de software con la construcción de una casa para un

perro, de una casa para una familia y de un gran edificio. En el primer caso no será tan
evidente la falta de un buen diseño, o al menos nuestro perro no se quejará
demasiado. En el segundo caso, es humanamente posible hacer la construcción de
una casa sin los planos adecuados, pero la casa resultante seguramente tendrá varias
carencias, o en el peor de los casos, posiblemente no resistirá ciertas condiciones
extremas como un temblor. En el caso del edificio, definitivamente sería un grave error
comenzar la construcción sin los estudios y planos adecuados.

En el caso del software, es curioso como muchos proyectos del tamaño de un

rascacielos, son construidos como si se tratara de la casa de un perro. El modelado
visual del software ayuda a capturar las partes esenciales de un sistema:
 Se utiliza para capturar los procesos de negocios desde la perspectiva del
usuario.
 El Modelado Visual se utiliza para analizar y diseñar una aplicación,
distinguiendo entre los dominios del negocio y los dominios de la
computadora.
 Ayuda a reducir la complejidad.
 El Modelado Visual se realiza de manera independiente al lenguaje de
implementación.
 Promueve la reutilización de componentes.

Por otro lado, un modelo se considera como útil si presenta las siguientes
características:

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 26

 Preciso: Describen correctamente el sistema a ser construido.

 Consistente: Los distintos puntos de vista no expresan cosas que entren en
conflicto entre ellas.
 Fácil de comunicárselo a otros. Mejora la comunicación entre los miembros
del equipo usando un lenguaje gráfico.
 Fácil de cambiar.
 Legible: Todas las representaciones se realizan de la manera más simple
como sea posible.

1.1.8. El Lenguaje de Modelamiento Unificado

El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se

usa para visualizar, especificar, construir y documentar artefactos de un sistema de
software. Captura decisiones y conocimientos sobre los sistemas que se deben
construir. Se usa para entender, diseñar, configurar, mantener, y controlar la
información sobre tales sistemas. El lenguaje de modelado pretende unificar la
experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas
actuales en acercamiento estándar. UML incluye conceptos semánticas, notación y
principios generales. Tiene partes estáticas, dinámicas, de entorno y organizativas.
Está pensando para ser utilizado en herramientas interactivas de modelado visual que
tengan generadores de código así como generadores de informes. La especificación
de UML no define un proceso estándar pero está pensado para ser útil en un proceso
de desarrollo iterativo. Pretende dar apoyo a la mayoría de los procesos de desarrollo
orientados a objetos.

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.
UML no es un lenguaje altamente formal pensando para probar teoremas. Hay varios
lenguajes de ese tipo, pero no son fáciles de entender ni de usar para la mayoría de
los propósitos. UML es un lenguaje de modelado de propósito general. Para dominios
especializados, tales como la composición de IUG, diseño de circuitos VLSI, o
inteligencia artificial basada en reglas, podría ser más apropiada una herramienta
especializada con un lenguaje especial. UML es un lenguaje de modelado discreto. No
se creó para modelar sistemas continuos como los basados en ingeniería y física.
UML quiere ser un lenguaje de modelado universal, de propósito general, para
sistemas discretos, tales como los compuestos por software, firmware o lógica digital.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 27

1.1.8.1 Breve Historia de UML

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

Las organizaciones que contribuyeron a la definición de 1.0 de UML fueron Digital

Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing,
MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments y Unisys. El
borrador de la especificación UML 1.0 se ofreció para su estandarización al OMG en
enero de 1997.

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.4.1. la cual fue liberada en Agosto 2011. UML 2.5 fue
lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser
formalmente liberada.

Los documentos de las especificaciones de UML se encuentran en la página web de

OMG (Object Management Group). En la siguiente figura se muestra las versiones,
fechas de lanzamiento y URL donde se podrá consultar las especificaciones de UML.

Versiones de UML lanzado formalmente por OMG

Versión Fecha del lanzamiento URL
2.4.1 Agosto 2011 http://www.omg.org/spec/UML/2.4.1
2.4 Marzo 2011 http://www.omg.org/spec/UML/2.4
2.3 Mayo 2010 http://www.omg.org/spec/UML/2.3
2.2 Febrero 2009 http://www.omg.org/spec/UML/2.2
2.1.2 Noviembre 2007 http://www.omg.org/spec/UML/2.1.2
2.1.1 Agosto 2007 http://www.omg.org/spec/UML/2.1.1
2.0 Julio 2005 http://www.omg.org/spec/UML/2.0
1.5 Marzo 2003 http://www.omg.org/spec/UML/1.5
1.4 Setiembre 2001 http://www.omg.org/spec/UML/1.4
1.3 Marzo 2000 http://www.omg.org/spec/UML/1.3

Versión en proceso de UML

Versión Fecha del lanzamiento URL
2.5 October 2012 http://www.omg.org/spec/UML/2.5

Figura 1.14.- Lanzamiento de versiones de UML.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 28

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

1.1.8.2 Objetivos de UML

Los objetivos de UML son muchos, pero se pueden sintetizar en las siguientes:
 Visualizar: UML permite expresar de una forma 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.

1.1.8.3 Especificaciones fundamentales de 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.15.- Especificaciones principales de UML 2.0.

Es interesante destacar que el UML 2.0 puede definirse a sí mismo. Es decir, su
estructura y organización es modelable utilizando el propio UML 2.0; de esta manera,

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 29

se da un ejemplo de utilización del UML en un dominio distinto al del desarrollo de

software. En este caso, cada paquete del diagrama representa cada una de las cuatro
especificaciones que componen el lenguaje.

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

UML 2.0.

1.1.8.4 Supraestructura
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 éstas sean UML 2.0 compatibles.

1.1.8.5 Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de más bajo nivel.
La Infraestructura es un meta-modelo (un modelo de modelos) y mediante la misma se
modela el resto del UML. Generalmente, la infraestructura no es utilizada por usuarios
finales del UML; pero provee la piedra fundamental sobre la cual la
Superestructura es definida. La Infraestructura brinda también varios mecanismos
de extensión, que hacen del UML un lenguaje configurable. Para los usuarios
normales del UML basta con saber si la infraestructura existe y cuáles son sus
objetivos.

1.1.8.6 OCL
OCL son siglas en inglés que significan: Object Constraint Language y que en
castellano se traducen como: Lenguaje de Restricciones de Objetos. El OCL define
un lenguaje simple, para escribir restricciones y expresiones sobre elementos
de un modelo. El OCL suele ser útil cuando se está especificando un dominio
particular mediante el UML y es necesario restringir los valores permitidos para los
objetos del dominio. El OCL brinda la posibilidad de definir invariantes, precondiciones,
poscondiciones y restricciones en los elementos de un diagrama. Fue incorporado a
UML en la versión 1.1. Originalmente, fue especificado por IBM y es un ejemplo más
de las muchas herramientas agregadas a UML.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 30

1.1.8.7 Intercambio de Diagramas

La especificación para el intercambio de diagramas fue escrita para facilitar una
manera de compartir modelos, realizados mediante UML, entre diferentes
herramientas de modelado.
En versiones anteriores del UML, se utilizaba un Schema XML para capturar los
elementos utilizados en el diagrama; pero este Schema no decía nada acerca de la
manera en que el modelo debía graficarse. Para solucionar este problema, la nueva
especificación para el intercambio de diagramas fue desarrollada utilizando un nuevo
Schema XML, que permite construir una representación SVG (Scalable Vector
Graphics).
Esta especificación es denominada con las siglas XMI, que en inglés significa: XML
Metadata Interchange; y en castellano se traduce como: XML de Intercambio de
Metadata (datos que representan datos). Típicamente esta especificación es
solamente utilizada por quienes desarrollan herramientas de modelado UML.

1.1.9. Diagramas UML 2.0

En UML 2.0 hay 13 tipos diferentes de diagramas. Para comprenderlos de manera

concreta, es útil categorizarlos jerárquicamente, como se muestra en la figura 1.16.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el

sistema modelado:
 Diagrama de clases
 Diagrama de componentes
 Diagrama de objetos
 Diagrama de estructura compuesta (A partir de UML 2.0)
 Diagrama de despliegue
 Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema

modelado:
 Diagrama de actividades
 Diagrama de casos de uso
 Diagrama de 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)

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

Figura 1.16.- Jerarquía de los Diagramas UML 2.0.
1.1.9.1 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 encargaran del funcionamiento y la relación entre
uno y otro.

Figura 1.17.- Diagrama de Clases de Análisis.

Figura 1.18.- Diagrama de Clases de Diseño.

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

Los elementos de modelado dentro de un diagrama de componentes serán

componentes y paquetes. En cuanto a los componentes, sólo aparecen tipos de
componentes, ya que las instancias específicas de cada tipo se encuentran en el
diagrama de despliegue.
ANÁLISIS Y DISEÑO DE SISTEMAS I 33

Figura 1.19.- Diagrama de Componentes.

1.1.9.3. Diagrama de objetos

Se puede considerar un caso especial de un diagrama de clases en el que se
muestran instancias específicas de clases (objetos) en un momento particular del
sistema. Utilizan un subconjunto de los elementos de un diagrama de clase. Los
diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es
similar a los diagramas de clase.

Figura 1.20.- Diagrama de Objetos.

1.1.9.4 Diagrama de estructura compuesta

Este tipo de diagrama fue específicamente diseñado para la representación de
patrones de diseño, y es una de las modificaciones de mayor impacto dentro de UML
2.0. Esta modificación al UML hace que ahora todos los Clasificadores puedan tener
una estructura compuesta. Mediante una composición de estructuras, el
comportamiento de las instancias de otros Clasificadores (estructura interna)
contenidos en un Clasificador determinado, puede especificarse como Colaboraciones.
Los conceptos principales para describir la estructura interna son: Partes, Puertos y
Conectores.

Figura 1.21.- Diagrama de Estructura Compuesta.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 34

1.1.9.5 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.22.- Diagrama de Despliegue.

1.9.1.6 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.23.- Diagrama de Actividades.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 35

1.1.9.7 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. Cada paquete se
corresponde a un submodelo (subsistema) del modelo (sistema); se pueden anidar
paquetes. Por último, puede crearse relaciones de dependencia, esto se da cuando un
componente de un paquete necesita un componente de otro paquete.

Figura 1.24.- Diagrama de Paquetes.

1.1.9.8 Diagrama de casos de uso

Este Diagrama permite realizar la 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.25.- Diagrama de Casos de Uso del Negocio.

Figura 1.26.- Diagrama de Casos de Uso.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 36

1.1.9.9 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 sólo 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.27.- Diagrama de Máquina de Estados.

1.1.9.10 Diagrama de secuencia

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

Figura 1.28.- Diagrama de Secuencia.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 37

1.1.9.11 Diagrama de comunicación

Antes era conocida como diagrama de colaboración. Muestra la red y la secuencia de
mensajes de comunicaciones entre objetos en tiempo de ejecución durante una
instancia de colaboración.

Figura 1.29.- Diagrama de Comunicación.

1.1.9.12 Diagrama de tiempo

Fusionan los diagramas de secuencia y estados para proveer una vista de un estado
del objeto dentro de una escala de tiempo y los mensajes que modifican ese estado.
Útil para sistemas de tiempo real, de control automático, etc.

Figura 1.30.- Diagrama de Tiempo.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 38

El propósito primario de los diagramas de tiempos (o temporizados) es mostrar los

cambios en el estado, o la condición, de una línea de vida de una instancia (de un
Clasificador o un Rol de un clasificador), a lo largo del tiempo y de manera lineal. El
uso más común es mostrar el cambio de estado de un objeto a lo largo del tiempo, en
respuesta a los eventos o estímulos aceptados. Un diagrama de tiempos se ve tal y
como lo muestra la figura 1.30. No resulta trivial leer un diagrama de tiempos; si no se
lo conoce, puede resultar poco intuitivo.

1.1.9.13 Diagrama de descripción de la interacción

Es un diagrama que muestra cómo interactúan varios diagramas de interacciones (por
ejemplo, de secuencias). Este tipo de diagramas es muy útil para mostrar de qué
manera distintos escenarios se combinan. En el ejemplo de la figura 2.18, se muestra
la interacción de un cliente con un cajero ATM, separado en cuatro fragmentos:

 Secuencia de login: la cual pedirá un usuario y una clave a un cliente. (la

secuencia supone que la clave y usuario ingresados son válidos).
 Secuencia de seleccionar una operación. Las operaciones permitidas por este
cajero son cancelar o extraer dinero.
 Si cancela, se ejecutará la secuencia de deslogueo del cliente. Luego finalizará
la operatoria.

Figura 1.31.- Diagrama de Descripción de la Interacción.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 39

1.2 TEMA 2: HERRAMIENTAS C.A.S.E.

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 las mismas 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 C.A.S.E.

 Mejorar la productividad en el desarrollo y mantenimiento del software

 Aumentar la calidad del software
 Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas
informáticos
 Mejorar la planificación de un proyecto
 Aumentar la biblioteca de conocimiento informático de una empresa ayudando a
la búsqueda de soluciones para los requisitos
 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
 Gestión global en todas las fases de desarrollo de software con una misma
herramienta
 Facilitar el uso de las distintas metodologías propias de la ingeniería del
software.

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

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 C.A.S.E.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 40

Figura 1.32. Paradigma visual.

Figura 1.33. Enterprise Architect.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 41

Figura 1.34. Rational Software Modeler.

Figura 1.35. Rational Software Architect.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 42

1.2.4. RATIONAL SOFTWARE ARCHITECT (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.

Dentro de un equipo de desarrollo, los arquitectos de software y los desarrolladores

sénior son los responsables de especificar y mantener todos los aspectos de la
arquitectura de una aplicación. Para manejar las aplicaciones actualmente, se
necesitan herramientas potentes y de fácil configuración. IBM Rational Software
Architect es una herramienta integrada de diseño y desarrollo que proporciona un
desarrollo basado en modelos con UML (Unified Modeling Language) para crear
aplicaciones y servicios con una buena arquitectura. Rational Software Architect
unifica todos los aspectos del diseño y desarrollo de software en una única
herramienta fácil y potente. Incluye una funcionalidad completa con Rational
Application Developer for WebSphere Software y está construido sobre la base de la
plataforma abierta y extensible Eclipse, que incluye multitud de estándares abiertos.
Esto permite a los usuarios crear aplicaciones optimizadas para el middleware de IBM,
así como para aquellas desarrolladas utilizando tecnología middleware de otras
compañías.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 43

UNIDAD

2
DISCIPLINA DEL MODELADO
DEL NEGOCIO
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno sustentará el primer avance de su proyecto,
acerca del Modelado de negocio de la empresa en estudio, el cual está
conformado por el Modelo de casos de uso del negocio, en el que identificará
los objetivos, casos de uso y actores del negocio, y realizará el diagrama
general de casos de uso del negocio, mientras que para el Modelo de análisis
del negocio, a los trabajadores y entidades, y realizará los diagramas de clases
y de actividades del negocio.

TEMARIO
2.1 Tema 3 : Modelado del Negocio
2.1.1. : ¿Cuándo será necesario hacer el Modelado de Negocio?
2.1.2. : ¿Cuándo no será necesario hacer 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
2.2.1. : Determinar la situación de la organización
2.2.2. : Identificar los procesos de negocio
2.2.3. : Refinar las definiciones de los procesos de negocio
2.2.4. : Artefactos del Modelo de Casos de uso del negocio
2.3 Tema 5 : Modelo de Análisis de Negocio
2.3.1. : Diseñar las realizaciones de los procesos de negocio
2.3.2. : Artefactos del Modelo de Análisis dl negocio

ACTIVIDADES PROPUESTAS
 Los alumnos desarrollan el Modelo de casos de uso del negocio de un proceso
de negocio.
 Los alumnos desarrollan el Modelo de análisis del negocio de un proceso de
negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 44

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 45

2.1 TEMA 3: MODELADO DEL NEGOCIO

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

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 será necesario hacer el Modelado de Negocio?

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

 Cuando la organización a enfrentado un reciente proceso de reingeniería de
negocios.
 Cuando la organización esta 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 cuál no se ha trabajado
antes.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 46

Figura 2.1.- Artefactos del Modelado de Negocio.

2.1.2 ¿Cuándo no será necesario hacer 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: (Ver figura 2.2)
 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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 47

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

Figura 2.2.- El Modelado de Negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 48

2.2 TEMA 4: MODELO DE CASOS DE USO DEL NEGOCIO

Define un conjunto de acciones que el negocio lleva a cabo y provee resultados de
valor a quienes interactúan con el. 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, conocido comúnmente como BUCS (Business Use Case Specification) por
las iniciales en inglés. 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 Refinar las definiciones 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.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 49

2.2.4 .Artefactos del Modelo de Casos de uso del 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.
Situación del 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.
Business Goal Se permite la relación de dependencia entre objetivos del
negocio y la de soporte de un caso de uso del negocio.
Define un conjunto de acciones que el negocio lleva a
cabo y provee resultados de valor a quienes interactúan
con el.
Describe un proceso de negocio desde un punto de vista
Business Use Case externo que percibe algún tipo de valor.
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 ó más casos de uso del
negocio.

Business Actor
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
entorno.
Business Use Case Model
Reporte que contiene información de los actores del
negocio identificados en el modelo de casos de uso del
negocio.
Business Actor
Documento que contiene las características de un
proceso de negocio. Se realiza una especificación por
cada caso de uso de negocio.
Business Use-Case
Specification
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 depósito en cuenta bancaria.”
Reglas de negocio

Tabla 2.1.- Artefactos del Modelo de Casos de Uso del Negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 50

2.3 TEMA 5: MODELO DE ANÁLISIS DEL NEGOCIO

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.3.1 Diseñar las realizaciones de los 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.3.2. Artefactos del Modelo de Análisis dl negocio

Artefacto Descripción
Un trabajador del negocio es un rol interno al
negocio. Colabora con trabajadores de otro
sector, es notificado de acontecimientos del
negocio y manipula entidades de negocio para
Business Worker
realizar sus responsabilidades.

Ente significativo y persistente manipulado por

actores del negocio y trabajadores del negocio.

Business Entity
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 Actividades y Diagramas de
Business Use Case Colaboración para realizar el detalle de cada
Realization proceso de negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 51

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 colaboran
para realizar los casos del uso del negocio.
Business Analysis
Model
Reporte que contiene información de los
trabajadores del negocio identificados en el
modelo de análisis del negocio.
Business Worker
Reporte que contiene información de las
entidades del negocio identificadas en el modelo
de análisis del negocio.
Business Entity

Tabla 2.2.- Artefactos del Modelo de Análisis del Negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 52

CASO DE ESTUDIO N°1: ELÉCTRICA S.A.

Eléctrica es una empresa dedicada a la venta de artículos electrodomésticos. Esta
empresa cuenta con diferentes puntos de venta. Cada punto de venta cuenta con
cajeros, vendedores y su propio almacén.

Un día X en Eléctrica comienza cuando un cliente solicita al vendedor un producto que

se encuentra en vitrina. El vendedor verifica el stock de ese producto y si hay stock, le
muestra e informa de las características de ese producto. Si el cliente está de acuerdo
con el producto ofrecido, el vendedor le generará un ticket de pedido indicándole el
código del producto y el precio.

El cliente se dirige a caja y el cajero le solicita el ticket de pedido para que le genere el
comprobante de pago. El cajero le pregunta al cliente la forma de pago, efectivo o
tarjeta, si el cliente informa que pagara en efectivo le solicita el dinero y genera el
comprobante de pago, si el cliente informa que es tarjeta, el cajero le solicitara la
tarjeta (Crédito o débito) y su DNI para pasar la tarjeta por el terminal de POS y
generar el Boucher, luego de ello le genera el comprobante de pago al cliente.
Ya con el comprobante el cliente se dirige al vendedor para que le haga entrega del
producto.

GLOSARIO
Las tarjetas de débito pueden utilizarse para disponer de efectivo en las sucursales
bancarias y cajeros automáticos, consultar el saldo y los movimientos de la cuenta
asociada.

En el caso de la tarjeta de crédito, el monto a pagar oscila entre un mínimo y el total

gastado, pero la parte de deuda no saldada implica un interés que el titular deberá
abonar en sus pagos siguientes.

Objetivos del negocio:

 Agilizar la atención al cliente en un 5% con respecto al año 2013..
 Conocer el progreso de las ventas mensuales.

El Flujo de trabajo para el proceso “Venta de Electrodomésticos” se muestra a

continuación:

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 53

Flujo Trabajo
Flujo Básico
1. El cliente solicita el electrodoméstico que se encuentra en vitrina.
2. El vendedor verifica existencia del electrodoméstico.
3. Si existe, el vendedor muestra el electrodoméstico al cliente.
4. El cliente evalúa el electrodoméstico.
5. Si está de acuerdo con el electrodoméstico ofrecido, el vendedor genera el
ticket de pedido.
6. El vendedor emite el ticket de pedido al cliente.
7. El cliente entrega el ticket de pedido al cajero
8. El cajero pregunta forma de pago Efectivo o tarjeta
9. Si el cliente responde efectivo ,entrega el dinero
10. El cajero genera el comprobante de pago.
11. El cajero emite el comprobante de pago al cliente.
12. El cliente entrega la copia del comprobante al vendedor.
13. El vendedor sella el comprobante y entrega el electrodoméstico.
14. El cliente recibe el electrodoméstico y finaliza el proceso.
Flujos alternativos
.En el punto 3, si no hay stock disponible, el vendedor le ofrece un electrodoméstico
sustituto al cliente y continúa con el paso 4.
1. En el punto 5, si no está de acuerdo con el electrodoméstico ofrecido, termina
el proceso.
2. En el punto 9, el cliente puede pagar con tarjeta crédito o débito:
a. Si el cliente responde pago con tarjeta
b. El cajero solicita la tarjeta al usuario.
c. El cliente entrega tarjeta y DNI.
d. El cajero pasa la tarjeta por el terminal POS.
e. Si es con tarjeta de crédito:
i. El terminal de POS genera el Boucher.
ii. El Servicio de Banca actualiza la cuenta de la empresa.
iii. El cajero entrega el Boucher para su firma.
iv. El cliente firma el Boucher.
f. Si es con tarjeta de débito:
i. El cliente ingresa su clave secreta en el terminal POS
ii. El terminal de POS genera el Boucher.
iii. El Servicio de Banca actualiza la cuenta del cliente.
g. El cajero genera el CDP, entrega el CDP y el Boucher al cliente.
h. El caso de uso continúa en el paso 12.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 54

Solución de caso propuesto

1. Estructura de proyecto Modelo de casos de uso del negocio.

2. Casos de uso del negocio

3. Objetivos del negoció

4. Diagrama de Casos de Uso del Negocio Vs. Objetivos del Negocio

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 55

5. Actores de negocio

6. Creación del Diagrama general de casos de uso del negocio.

7. Estructura del Modelo de análisis del negocio

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 56

8. Trabajadores del negocio

9. Entidades del negocio

10. Diagrama de clases de negocio

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 57

11. descripción de los elementos de un diagrama de actividades.

Artefacto Descripción

Partición asignada para cada rol.

Nodo inicial que indica el inicio del

Diagrama de Actividades.

Define una acción de la actividad.

Es conveniente nombrar las
actividades con verbos en tercera
persona.

Este nodo representa un punto

en una actividad donde un flujo
de entrada se divide en varios
flujos de salida.

Este nodo representa un punto

en una actividad donde varios
flujos de entrada están
sincronizados en un único flujo
de salida.

Control de decisión a partir del

cual se especifica una pregunta
que lleva a dos o más flujos de
acciones.

Almacén de datos que representa

la instancia de una clase
persistente.

Flujo de objeto utilizado para

representar relaciones INPUT y/o
OUTPUT entre una acción e
instancia de entidad de negocio.

Flujo de control utilizado para

representar relaciones entre
acciones.

Conector de flujo entre acciones

o acciones y almacén de datos.
Nodo Final que indica finalización
de una secuencia de actividades.
Un Diagrama de Actividades
puede tener más de un tipo de
fin.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 58

12. Diagrama de actividades

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 59

ACTIVIDADES PROPUESTAS
Desarrolle el siguiente caso propuesto

CASO DE ESTUDIO N°2: PANDERO

La empresa Pandero SAC es una prestigiosa empresa dedicada a fondos colectivos,
el fondo colectivo es una modalidad bajo la cual se adquieren bienes, a través de los
aportes mensuales de un número determinado de cuotas a pagar periódicamente por
las personas naturales y se desea automatizar sus procesos esperando ser la
empresa número 1 del mercado. Esperan lograrlo a partir de la automatización del
100% de las transacciones y de un control total de las aportaciones..

El principal proceso de la empresa se inicia cuando el cliente se acercan a la tienda a

realizar las consultas sobre el precio de los autos y las cuotas a pagar que se ofrecen,
el Cliente es atendido por un vendedor quien le brinda toda la información que
necesita, si el cliente está de acuerdo y acepta las condiciones se genera un
certificado de Pandero por el monto total del auto que desea comprar, el cliente debe
pagar su cuota de inscripción de $200. Esta cuota puede pagarse en el local con
tarjeta de crédito o débito.

Mensualmente se realiza el sorteo de los autos y lo inicia el Gerente General que le

informa al asistente de sorteos que selecciona la lista de clientes al día en el pago de
sus cuotas y sortee para obtener un ganador a quien se le entrega un auto. El cliente
ganador debe pagar su cuota de Adjudicación por $500 y la puede pagar en el local
con tarjeta de crédito o débito.

Flujo de trabajo del proceso: Realizar Adjudicación del Pandero

Flujo de Trabajo
Flujo Básico
1. El Gerente General solicita al asistente iniciar el sorteo
2. El asistente de sorteo genera la lista de clientes al día en sus cuotas.
3. El asistente de sorteo genera un boleto por cada cliente
4. El asistente de sorteo entrega la lista de clientes y los boletos al jefe de
sorteos.
5. El jefe de sorteos ingresa los boletos en un ánfora.
6. El jefe de sorteo saca del ánfora el boleto ganador y llama al cliente
7. El cliente se acerca con su certificado de Pandero.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 60

8. El jefe de sorteo verifica los datos del certificado

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

1.1. Flujos Alternativos

1. En el punto 9, si los datos del ganador no son conformes

2. El jefe de sorteo saca nuevamente otro boleto y continúa en el paso 7.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 61

Resumen

 El Modelado del negocio es una técnica para comprender los procesos de negocio
de la organización objetivo.

 El Modelo de casos de Uso del Negocio es un modelo elaborado bajo una

perspectiva externa del negocio.

 El Modelo de Análisis del Negocio detalla cómo el proceso de negocio es

implementado internamente.

 Si desea saber más acerca de estos temas, puede consultar las siguientes
páginas.

 http://www-128.ibm.com/developerworks/rational/library/5167.html
Aquí hallará una descripción de los elementos del modelado de negocio.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 62

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 63

UNIDAD

3
DISCIPLINA DE LA CAPTURA DE
REQUISITOS
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, los alumnos, trabajando en equipo, elaborarán y sustentarán su
proyecto final sobre el modelado del negocio y la captura de requisitos, en el que
identifica el modelo de casos de uso del negocio, el modelo de análisis del negocio, y el
modelo de casos de uso con sus respectivos artefactos, aplicando la metodología RUP,
el lenguaje de modelado UML y la herramienta IBM Rational Software Architect.

TEMARIO
3.1 Tema 6 : Captura de requisitos
3.1.1. : Artefactos de la Captura de Requisitos
3.1.2. Actividades para realizar la Captura de Requisitos
3.1.3. : Requerimientos
3.1.4. Requisitos FURPS
3.1.5. Técnicas para capturar requisitos
3.1.6. : Captura de requisitos a solicitud del cliente
3.1.7. : Captura de requisitos a partir del diagrama de actividades del negocio
3.2 Tema 7 : Modelo de casos de uso.
3.2.1. : Encontrar actores y casos de uso
3.2.2. Encontrar actores
3.2.3. : Encontrar casos de uso
3.2.4. Crear el Diagrama de casos de uso
3.3 Tema 8 : 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. : Especificaciones de casos de uso
3.3.5. : Priorización de los Casos de Uso

ACTIVIDADES PROPUESTAS
 Los alumnos clasificarán los requisitos de una lista propuesta según las categorías
descritas por el modelo FURPS+.
 Los alumnos identifican los requisitos funcionales a partir de un Diagrama de
Actividades del Negocio
 Los alumnos identifican actores y casos de uso a partir de un caso propuesto.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 64

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 65

3.1 TEMA 6: CAPTURA DE REQUISITOS

El esfuerzo principal en esta disciplina es desarrollar un modelo del sistema que se va
a construir. La utilización de los casos de uso es una forma adecuada de crear ese
modelo. Esto es debido a que los requisitos funcionales se estructuran de forma
natural mediante casos de uso.

Los casos de uso proporcionan un medio intuitivo y sistemático para capturar los
requisitos funcionales con un énfasis especial en el valor añadido para cada usuario
individual o para cada sistema externo.

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 disciplina de Requisitos son:

 Establecer y mantener los acuerdos con los clientes y otros interesados
(stakeholders) sobre lo que el sistema debe hacer.
 Proporcionar a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
 Definir las fronteras del sistema.
 Proveer la base para planificar las iteraciones.
 Proporcionar la base para estimar los costos y tiempos del desarrollo del
sistema.
 Definir las interfaces de usuario con el sistema, enfocado a las necesidades y
objetivos de los usuarios.

3.1.1 Artefactos de la Captura de Requisitos

El conjunto completo de artefactos de la captura de requisitos, mostrado en la figura
3.1, sirven como entrada y referencia para el análisis, diseño, implementación y
pruebas del sistema.

Figura 3.1.- Artefactos de la Captura de Requisitos.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 66

Artefacto Descripción
Documento que define la opinión de los stakeholders del
producto que se desarrollará, especificada en términos de
necesidades y características claves de los stakeholders.
Vision Contiene un esquema de los requisitos previstos, el cual
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.
Software Requirements Comúnmente conocido como SRS por sus iniciales en
Specification inglés. Contiene la lista de requerimientos funcionales y no
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
Use-Case Package dividiéndolo en piezas más pequeñas.
Es un proceso específico del sistema con identidad propia, el
cual define una secuencia de acciones que el sistema realiza
para un actor en particular.
Use Case

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

sistema con el que se establece intercambio directo de
información.
Puede ser asociado a uno o más casos de uso.

Actor
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
Use Case Model análisis, diseño y pruebas.

Reporte que contiene información de los actores

identificados en el modelo de casos de uso.

Actor

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
Use-Case Specification sistema. La especificación también contiene otra información
tal como precondiciones, pos condiciones y requisitos
especiales. Se realiza una especificación por caso de uso.

Tabla 3.1.- Artefactos del Modelo de Casos de Uso.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 67

3.1.2 Actividades para realizar la Captura de Requisitos

Según RUP, la Captura de Requisitos comprende las siguientes actividades:
 Analizar el problema
 Entender las necesidades de stakeholders
 Definir el sistema
 Administrar el alcance del sistema
 Refinar la definición del sistema
 Administrar cambios de requisitos

Figura 3.2.- La Captura de Requisitos.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 68

3.1.2.2 Entender las Necesidades del Stakeholder

El artefacto principal es un documento refinado de la Visión. 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 si se encuentra en las primeras iteraciones de
esta disciplina y prototipos si se encuentra en las últimas iteraciones.

Los stakeholders son un grupo de 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 lo tanto, son
fuentes de requisitos. Por ejemplo: usuarios finales del sistema, gerentes, accionistas,
reguladores quiénes certifican la aceptabilidad del sistema.

3.1.2.3 Definir el Sistema

En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso
completamente para obtener un Modelo de Casos de Uso refinado y expandir los
requisitos no funcionales definidos en los documentos de especificaciones
suplementarias.

3.1.2.4 Administrar el Alcance del Sistema

El alcance del proyecto es definido por el conjunto de requisitos definidos para éste. La
clave para manejar un proyecto exitoso es administrar el alcance del proyecto
cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. La
priorización los casos de uso, desarrollado por el arquitecto de software, permite
planificar el proyecto.

3.1.2.5 Refinar la Definición del Sistema

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.

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

3.1.3. Requerimientos
Un requerimiento se define como una condición o capacidad a la que debe ajustarse el
sistema que se construye para satisfacer un contrato, norma, especificación u otro
documento formalmente impuesto.

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 69

El proceso de recopilar, analizar y verificar las necesidades del cliente o usuario para
un sistema es llamado ingeniería de requisitos. La meta de la ingeniería de requisitos
(IR) es entregar una especificación de requisitos de software correcta y completa.

Algunos otros conceptos de ingeniería de requisitos son:

Según Pressman “Ingeniería de Requisitos ayuda a los ingenieros de software a

entender mejor el problema en cuya solución trabajarán. Incluye el conjunto de tareas
que conducen a comprender cuál será el impacto del software sobre el negocio, qué
es lo que el cliente quiere y cómo interactuarán los usuarios finales con el software”.

Por otro lado, Somerville define que “La ingeniería de requisitos es el proceso de
desarrollar una especificación de software. Las especificaciones pretenden comunicar
las necesidades del sistema del cliente a los desarrolladores del sistema”.

En síntesis, el proceso de ingeniería de requisitos se utiliza para definir todas las

actividades involucradas en el descubrimiento, documentación y mantenimiento de los
requisitos para un producto de software determinado, donde es muy importante tomar
en cuenta que el aporte de la IR vendrá a ayudar a determinar la viabilidad de llevar a
cabo el software (si es factible llevarlo a cabo o no), pasando posteriormente por un
subproceso de obtención y análisis de requisitos, su especificación formal, para
finalizar con el subproceso de validación donde se verifica que los requisitos realmente
definen el sistema que quiere el cliente.

3.1.3.1 Tipos de requisitos

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

3.1.3.1.1 Requisitos Funcionales

Son lo que los usuarios requieren que el sistema haga y son usados para expresar el
comportamiento de un sistema, especificando las condiciones de entrada y salida que
el sistema debe cumplir. Los casos de uso son usados para establecer lo que el
sistema debe hacer. Un estudio profundo del área de estudio usando casos de uso
permite conocer las necesidades de los usuarios. Estos requisitos pueden
establecerse más claramente usando prototipos.

3.1.3.1.2 Requisitos No Funcionales

Son restricciones que especifican propiedades del sistema, tales como facilidad de
uso, restricciones del entorno o de implementación, rendimiento, dependencias de
plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad y escalabilidad.

El incumplimiento de un requerimiento no funcional puede significar que

el sistema entero sea inutilizables. Por ejemplo, si un sistema de
contabilidad no cumple sus requisitos de fiabilidad, no se certificará
como seguro para el funcionamiento; si un sistema de control de tiempo
real no cumple sus requisitos de rendimiento, las funciones de control
no funcionarían correctamente.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 70

 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

3.1.4.1 Funcionales
Los requisitos funcionales deben incluir:
 Conjunto de características
 Capacidades
 Seguridad

Por ejemplo, para un Sistema de Ventas:

R1: Mostrar descripción y precio de productos.
R2: Registrar venta de productos.
R3: Reducir stock cuando se realiza la venta.
R4: Identificar al cajero utilizando un usuario y una clave.

3.1.4.2 Facilidad de Uso

Deben incluir 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 en el uso de las
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

3.1.4.3 Confiabilidad
 Frecuencia de fallos
 Capacidad de recuperación a fallos
 Posibilidades de predicción del programa
 Precisión
 Tiempo medio de fallos

Por ejemplo:

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 71

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.

3.1.4.4 Rendimiento
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 20 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 5:00 p.m., con excepción de los días festivos.

3.1.4.5 Soporte
Es la capacidad que tiene el software de ser modificado fácilmente para adecuar
mejoras o cambios. Incluye:
 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.

3.1.4.6 Restricciones de Diseño

También llamados restricciones de diseño, 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.

3.1.4.7 Requisitos de implementación

Especifica restricciones de codificación o de construcción del sistema:

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 72

 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 con el lenguaje JAVA V1.6.

3.1.4.8 Requisitos de interfaz

Especifica:
 Elemento externo con el que el sistema debe interactuar
 Restricciones o formatos, tiempos u otros factores usados en tales interacciones

Por ejemplo:
R1: El sistema deberá proporcionar, para los diferentes reportes solicitados, salidas
en documentos electrónicos (Word, Excel o Acrobat Reader).
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 2003.

3.1.4.9 Requisitos físicos

Especifican características físicas que el sistema debe poseer. Por ejemplo: 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 el punto de acceso deberá cumplir con los siguientes requisitos
mínimos.
o Procesador 1.0 GHz.
o Memoria 128 MB.
o Disco duro 10 GB.
o Sistema Operativo Windows XP o Linux.
o Navegador internet Explorer 6.0 o posterior, Mozilla Firefox
2.X, Netscape Navigator 6.X o posterior con plugins para
Macromedia Flash y Java.
o Conexión a Internet. mínimo 56Kbps

3.1.5 Técnicas para capturar requisitos

Existen varias técnicas para capturar requisitos de usuarios y de las cuales

examinaremos algunas de ellas.

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 73

El éxito de esta técnica, depende de la habilidad del entrevistador para crear un clima
de confianza y de su preparación para la misma. Después de la entrevista, se debe
analizar la información obtenida y construir algunos requisitos candidatos.

Los puntos esenciales de esta técnica se anotan a continuación:

 Dos entrevistadores: Conviene que dos personas realicen la entrevista para
mejorar la gestión del tiempo, pues uno conduce la entrevista y el otro supervisa
la interacción y toma notas.
 Formule tanto preguntas abiertas como cerradas: Las preguntas abiertas no
presuponen ninguna respuesta particular y animan al entrevistado a hablar sobre
el problema, mientras que las preguntas cerradas presentan un intervalo
específico de respuesta. Ejemplos:
 Pregunta abierta: “¿Quién utiliza el sistema?”
 Pregunta cerrada: “¿Utiliza usted el sistema?”
 No invente una solución, pues puede pensar que tiene una muy buena idea de lo
que necesitan los grupos de decisión, pero debe mantener esta preconcepción a
un lado durante la entrevista. Ésta es la única forma de averiguar lo que
realmente necesita.
 Escuche: Ésta es la única forma en la que averiguará qué quieren los grupos de
decisión, por lo tanto déjeles tiempo para hablar. Permítales hablar sobre una
pregunta y que la exploren de su propia forma. Si busca respuestas específicas,
es posible que invente una solución y formule preguntas cerradas basándose en
esa invención.
 No adivine los pensamientos: Ésta es una habilidad humana muy importante ya
que es la base de la empatía. Sin embargo, no es recomendable cuando trata de
obtener requisitos, pues puede acabar especificando lo que usted necesita en
lugar de con lo que necesitan los grupos de decisión.

3.1.5.2 Cuestionarios
Los cuestionarios pueden ser un suplemento de utilidad para las entrevistas. Son
excelentes para conseguir respuestas a preguntas cerradas. Puede descubrir
preguntas claves a partir de las entrevistas e incorporar éstas en un cuestionario que
puede distribuir a una audiencia 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
¿Cree que se cometen muchos errores en la codificación de los números de cuenta en
las facturas?
SI
NO

 DE ACUERDO/EN DESACUERDO
¿Se cometen muchos errores al codificar os números de cuenta en las facturas?

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 74

DE ACUERDO
EN DESACUERDO

 ESCALAS
¿Se cometen muchos errores al codificar los números de cuenta en las facturas?
TOTALMENTE DE ACUERDO
DE ACUERDO
NO ESTOY SEGURO
EN DESACUERDO
TOTALMENTE EN DESACUERDO

 NÚMERO
De cada 100 facturas que se procesan cuántas tienen errores? Anote el número:
____________

 RANGO

¿De cada 100 facturas que se procesan 0-5

cuántas tienen errores? 6 - 10
11 - 15
16 - 20
21 - 25
26 - 30
31 - 40
41 - 50
Más de 50

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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 75

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.

3.1.5.3 Lluvia de ideas (Brainstorm)

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.

Las reglas básicas a seguir son:

 Los participantes deben pertenecer a distintas disciplinas y, preferentemente,
deben tener mucha experiencia. Esto trae como consecuencia la obtención de
una cantidad mayor de ideas creativas.
 Conviene suspender el juicio crítico y se debe permitir la evolución de cada una
de las ideas, porque si no se crea un ambiente hostil que no alienta la
generación de ideas.
 Por más locas o salvajes que parezcan algunas ideas, no se las debe descartar,
porque luego de maduradas probablemente se tornen en un requerimiento
sumamente útil.
 A veces ocurre que una idea resulta en otra idea, y otras veces podemos
relacionar varias ideas para generar una nueva.
 Escribir las ideas sin censura.

3.1.5.4 Prototipos
Durante la actividad de extracción de requisitos, puede ocurrir que algunos requisitos
no estén demasiado claros o que no se esté muy seguro de haber entendido

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 76

correctamente los requisitos obtenidos hasta el momento, todo lo cual puede llevar a
un desarrollo no eficaz del sistema final.

Entonces, para validar los requisitos hallados, se construyen prototipos. Los prototipos
son simulaciones del posible producto, que luego son utilizados por el usuario final,
permitiéndonos conseguir una importante retroalimentación en cuanto a si el sistema
diseñado sobre la base de los requisitos recolectados le permite al usuario realizar su
trabajo de manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requisitos. Desarrolladores y

clientes se reúnen y definen los objetivos globales del software, identifican todos los
requisitos que son conocidos, y señalan áreas en las que será necesaria la
profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El
diseño rápido se centra en una representación de aquellos aspectos del software que
serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño
rápido lleva a la construcción de un prototipo.

3.1.6 Captura de requerimientos a solicitud del cliente

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

las metas, de la visión y de los clientes/usuarios o si sólo 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.

Clasificación y Ordenación por

organización de prioridades y negociación
requisitos de requisitos

Descubrimiento de Documentación de
requisitos requisitos

Figura 3.3.- El proceso de obtención y análisis 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

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 77

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.

En la figura 3.3 se muestra un modelo general para obtener y analizar requisitos. Con
cada vuelta del ciclo de este modelo la comprensión de los requisitos por parte del
analista mejorará.

Cada equipo de desarrollo tendrá su propia versión o instancia de este modelo,

dependiendo de la habilidad del personal, el tipo de sistema a desarrollar y los
estándares utilizados.
Los pasos a seguir son:
1. Descubrimiento de requisitos. Es el proceso de interactuar con los stakeholders
del sistema para recopilar sus requisitos. Para ello, se utilizan técnicas de
captura de requisitos como las entrevistas y prototipos.
2. Clasificación y organización de requisitos. En esta actividad, el analista toma la
recopilación no estructurada de requisitos, grupos relacionados de requisitos y
los organiza en grupos coherentes.
3. Ordenación por prioridades y negociación de requisitos. Inevitablemente, cuando
existen muchos stakeholders involucrados, los requisitos entrarán en conflicto.
Esta actividad se refiere a ordenar según las prioridades de requisitos, y a
encontrar y resolver los requisitos en conflicto a través de la negociación.
4. Documentación de requisitos. Se documentan los requisitos y se continúa en la
siguiente vuelta de la espiral. Se pueden producir documentos de requisitos
formales o informales como por ejemplo: Modelo de casos de uso para requisitos
funcionales y Especificación de Requisitos de Software que contiene todos los
tipos de requisitos (funcionales y no funcionales) del sistema.

3.1.7 Captura de requerimientos a partir del diagrama de actividades del

negocio

Mediante la 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 del Negocio al Modelo de Casos de Uso

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 78

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

Tabla 3.2.- Plantilla de Matriz de Actividades y Requisitos.

Una Matriz de Actividades y Requisitos es una herramienta manual utilizada para

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

Caso de Estudio N°1 Requerimientos

Continuaremos con el ejemplo de la unidad de aprendizaje anterior de Venta de

Electrodomésticos. Se debe de Seleccionar las actividades relevantes que podrían
automatizar y marcarlas de un color diferente:

 Resaltar las siguientes acciones

o Verificar existencia de producto

o Generar Ticket
o Emitir ticket
o Generar CDP
o Entregar producto

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 79

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 80

CARRERA DE COMPUTACIÓN E INFORMÁTICA Y ADMINISTRACIÓN Y SISTEMAS CIBERTEC

 La Matriz de Actividades y Requisitos para el sistema de punto de venta es el siguiente:

Matriz de actividades y requisitos del sistema <Sistema venta de electrodomesticos>

Proceso Responsabl Iteración #
Actividad del
de e del Requerimiento Caso de Uso Actores o
Negocio
Negocio Negocio Prioridad
Verificar existencia Verificar si existe el
Vendedor R01 buscar producto Vendedor
de producto producto
Generar Ticket Vendedor R02 Generar de ticket
Realizar Generar Ticket Vendedor
Emitir ticket Vendedor r03 imprimir ticket
venta
Generar CDP Cajero R04 Generar Cdp
generar CDP Cajero
Entregar producto Vendedor R05 Descargar stock
ANÁLISIS Y DISEÑO DE SISTEMAS I 82

Luego, el Diagrama de Casos de Uso Inicial resultante será el siguiente:

Este Diagrama de Casos de Uso debe ser refinado. Nuevos casos de uso serán
detectados al describir cada caso de uso obtenido; para ello, se utiliza el documento
Especificación de Caso de Uso (Ver tema: Desarrollo de Especificaciones de Casos de
Uso).

Por último, los nuevos casos de uso serán agregados en un diagrama denominado
Diagrama Estructurado de Casos de Uso, consiguiendo de esta manera, la versión
final del Modelo de Casos de Uso (Ver tema: Estructurando el Modelo de Casos de
Uso).

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 83

ACTIVIDADES PROPUESTAS

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

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

lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits
sin que esto afecte el rendimiento del mismo.

R02. El sistema debe contar con un Manual Técnico de Referencia para la

Aplicación, el cual estará orientado a profesionales capacitados en aspectos
técnicos del área de sistemas.

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

R04. El código fuente del sistema deberá cumplir con el estándar de codificación
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.

R06. 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
deben estar provistos en español, inglés y portugués. Estos tres idiomas deben
ser soportados por el producto desarrollado.

R07. El sistema deberá permitir la creación, modificación, activación, desactivación y

autorización de los roles de usuarios definidos.

R08. 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:
 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.

R09. El sistema deberá contar con el manual de FAQ (Frequent Asked Questions),
en 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.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 84

3.2 TEMA 7: MODELO DE CASOS DE USO

El modelo de casos de uso captura los requisitos funcionales de los usuarios a un alto
nivel y establece la estructura fundamental del sistema. Este modelo utiliza actores y
casos de uso. Los actores son los roles que los usuarios pueden representar y los
casos de uso representan lo que los usuarios deberían poder hacer con el sistema.

Este modelo no incluye los requisitos no funcionales ni los requisitos funcionales

internos. No usa descomposición funcional. El modelo resultante es fácil de entender y
debe ser verificado por los usuarios antes de empezar a construir el sistema.

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

nuevos sistemas; también es utilizado cuando nuevas generaciones de sistemas son
desarrolladas. 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:

 Encontrar actores y casos de uso

 Priorizar casos de uso
 Detallar un caso de uso
 Crear prototipo de interfaz de usuario
 Estructurar el modelo de caso de uso

Estos pasos no tienen por qué ser ejecutados en ningún orden en particular y a
menudo se hacen simultáneamente. De hecho, podemos trabajar por múltiples vías
que producen un resultado final equivalente. Podemos, por ejemplo, comenzar
encontrando algunos casos de uso (la actividad de Encontrar Actores y Casos de
Uso), después diseñar las interfaces de usuario (la actividad de Crear Prototipo de
Interfaz de Usuario), para darnos cuenta de que necesitamos añadir un nuevo caso de
uso (así que retrocederemos a la actividad de Encontrar Actores y Casos de Uso,
rompiendo la secuencia estricta marcada), y así sucesivamente.

Los resultados de la primera iteración a través de este flujo de trabajo consisten en

una primera versión del modelo de casos de uso. Los resultados de cualquier iteración
subsiguiente consistirán entonces en nuevas versiones de artefactos involucrados en
la creación del modelo de casos de uso. Hay que recordar que todos los artefactos se
contemplan y mejoran incrementalmente a través de iteraciones.

Las distintas actividades en el modelado de caso de uso adoptan formas diferentes en

diferentes fases del proyecto. Por ejemplo, cuando un analista ejecuta la actividad de
Encontrar Actores y casos de Uso durante la fase de inicio, identificará muchos
actores y casos de uso nuevos. Pero cuando la actividad se realiza durante la fase de
construcción, el analista hará cambios secundarios en la lista de actores y casos de
uso, tales como la creación de un diagrama de casos de uso que describe mejor el
modelo de casos de uso desde una perspectiva en particular.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 85

3.2.1. Encontrar actores y casos de uso

Lo primero que necesita hacer cuando piense en crear un sistema es decidir dónde se
encuentran los límites del sistema. Es decir, necesita decidir qué o quiénes utilizan el
sistema (los actores) y qué beneficios específicos ofrece el sistema a esos actores (los
casos de uso).

3.2.2. Encontrar actores

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

3.2.2.1 Actor
Un actor representa un rol (humano, hardware o software) externo al sistema con el
que se establece intercambio directo de información.

Hay una diferencia entre actor y usuario. Usuario es el que utiliza el sistema, mientras
que el actor representa un cierto rol que un usuario puede desempeñar. Es decir que
los actores definen los roles que pueden representar los usuarios.

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

Sin embargo, en algunas situaciones, una sola persona desempeña el rol

representado por el actor. Por ejemplo, puede haber sólo una persona desempeñando
el papel de administrador del sistema para un sistema bastante pequeño.

Figura 3.4.- Muchos usuarios representados por un actor.

También podemos encontrar que el mismo usuario puede ser representado por varios
actores, esto es porque la misma persona puede desempeñar roles diferentes. Por

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 86

ejemplo, la figura 3.5 muestra que un usuario desempeña dos roles: Jefe de Almacén
y Personal de almacén.

Figura 3.5.- Un usuario representado por dos actores.

3.2.2.2 Cómo identificar actores

Para identificar actores debe responder las siguientes preguntas:

 ¿Qué actores del negocio o trabajadores del negocio son responsables de las
actividades a informatizar?
 ¿Qué grupos de usuarios necesitan ayuda del sistema para llevar a cabo sus
tareas?
 ¿Qué grupos de usuarios son fundamentales para ejecutar las funciones
principales del sistema?
 ¿Qué grupos de usuarios son los que llevarán a cabo funciones secundarias
como mantenimiento o administración?
 ¿El sistema a desarrollar interactuará con algún hardware o sistema de
software?

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 3.6 muestra el entorno del sistema del cual se
encontrarán categorías de actores.

Figura 3.6.- Entorno del sistema.

Para determinar si se tienen los actores correctos, se puede elegir dos o tres personas
que usarán el sistema y, a continuación, ver si el conjunto de actores obtenido es
suficiente para cubrir sus necesidades.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 87

Por último, se completa la identificación de actores al obtener todos los casos de uso
del sistema que conlleva a crear otros actores o eliminar a algunos que existen. Este
proceso de refinamiento se verá en el próximo capítulo “Estructurando el Modelo de
Casos de Uso”.

3.2.2.3 Definición de 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.7.- Actores de un Sistema de Reservaciones I.

En cambio, si está desarrollando un sistema de reservaciones, para que los pasajeros

se puedan conectar a través de Internet, el pasajero ahora sí interactuará con el
sistema y se convertirá en actor.

Figura 3.8.- Actores de un Sistema de Reservaciones II.

3.2.2.4 Tiempo como actor

Aunque claramente el tiempo es una entidad externa al sistema (por lo que cumple
con la primera mitad de la definición de un actor) difícilmente podremos pensar que el
tiempo se encuentra interesado en una funcionalidad de nuestro sistema.

En este caso, es el sistema quien va a tener interés en el tiempo, debido a que deben
efectuar operaciones automáticas en determinados momentos; y siendo esto un
requisito funcional obvio, resulta de interés desarrollar alguna forma de capturar dicho
requisito en el modelo de casos de uso. La técnica es introducir al actor “Tiempo”,
quien está asociado a casos de uso que capturan una funcionalidad automática.

Un ejemplo de esto sería un respaldo automático del sistema que se ejecuta todas las
noches o la generación automática de reporte de ventas diario, tal como se ilustra en
la siguiente figura.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 88

Figura 3.9.-. Tiempo como actor.

3.2.2.5 Sugerencias para identificar adecuadamente a los actores del sistema

 Son roles (humanos, software o hardware), no personas con nombres propios.
 No siempre está asociado con el nombre de un cargo en la planilla de la
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.

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

Cliente: El cliente recoge botellas, latas y cajas en casa y los trae a la tienda para
obtener a cambio un reembolso.

Operador: El operador es el responsable del mantenimiento de la máquina de

reciclado.

Administrador: El administrador es responsable de las cuestiones sobre el dinero y

el servicio que la tienda ofrece a los clientes.

3.2.3. Encontrar casos de uso

Cuando su primer esbozo de los actores se completa, el siguiente paso es identificar

los casos de uso del sistema. Los primeros casos de uso son muy preliminares, y que
sin duda tiene que cambiar un par de veces hasta que sean estables. Si el sistema de
visión o de los requisitos son deficientes, o si el sistema de análisis es vaga, 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

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 89

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.

3.2.3.1 Caso de Uso

Un caso de uso es un fragmento de funcionalidad que el sistema ofrece para aportar
un resultado de valor para los actores. De manera más precisa, un caso de uso
especifica una secuencia de acciones que el sistema ejecuta interactuando con sus
actores e incluyendo alternativas dentro de la secuencia. Las acciones pueden
involucrar la comunicación con un determinado número de actores así como también
realizar cálculos y trabajos dentro del sistema.

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.

3.2.3.2 Cómo identificar casos de uso

La mejor manera de encontrar casos de uso es considerar lo que cada actor requiere
del sistema. Recuerde que el sistema existe 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 (como se
ha descrito en el punto 4 de la semana 8).

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

 ¿Cuáles son las actividades del negocio objetos de automatización?

 ¿Cuáles son las tareas que el actor desea que el sistema desarrolle?
 ¿El actor crea, almacena, cambia, elimina o consulta datos en el sistema?
 ¿El actor necesita informar al sistema cambios generados en el entorno
circundante al sistema?
 ¿El actor necesita ser informado sobre la ocurrencia de situaciones externas al
sistema?

3.2.3.3 Sugerencias pasa identificar adecuadamente a los casos de uso

 Son procesos o funcionalidades del sistema, que en la mayoría de los casos
corresponden con opciones de ejecución.
 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.

3.2.3.4 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

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 90

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:

Reciclar artículos: El usuario utiliza esta máquina de reciclado para obtener

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

Agregar un nuevo tipo de botella: 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 máquina puede medir las botellas y aprender a identificarlos. El
administrador especifica el valor de reembolso para el nuevo tipo de botella.

3.2.4. Crear el Diagrama de casos de uso

El diagrama de casos de uso muestra 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.

Empiece dibujándolos en la esquina superior izquierda. Los casos de uso deben

dibujarse en el orden en que normalmente los usará el actor. Opcionalmente, los
casos de uso mostrados en el diagrama se pueden encerrar dentro de un 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. Verá mucho más sobre los tipos de asociaciones
en la siguiente semana con el tema Estructurando el Modelo de Casos de Uso.

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

Figura 3.10.-. Diagrama de Casos de Uso.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 91

Caso de Estudio N°1 Crear modelo de casos de uso

Ahora, vamos a identificar las funcionalidades del nuevo software.

En primer lugar, del Diagrama de Actividades se obtiene las siguientes actividades

a sistematizar:
 Consulta Stock de electrodomésticos.
 Genera ticket de pedido.
 Genera comprobante de pago.

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

contratado?
Ha solicitado que el registro de los pedidos sea vía web y que sean registrados por sus
clientes afiliados. Asimismo, si sus clientes afiliados lo requieren, deberían actualizar
sus datos vía web. Por consiguiente, tendríamos más requisitos:
 Registrar afiliación para el cliente no afiliado
 Actualizar datos de afiliación para el cliente afiliado
 Consultar pedidos para el vendedor

Por otro lado, debemos tomar en cuenta otros requisitos que serán necesarios
para controlar el proceso. Por ejemplo:
 Actualizar estado de pedido a “CANCELADO” cuando el cliente
pague su pedido.

El resultado de este análisis se documenta en la Matriz de Actividades Vs. Requisitos,

tal como se muestra a continuación:

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 92

Matriz de Actividades Vs. Requisitos Funcionales del Sistema de Ventas

Responsable
Proceso de Negocio Actividad del Negocio del Requisito Caso de Uso Actores
Negocio
Consulta Stock Consultar Stock de Consultar Stock de
Vendedor R01 CUS01 Vendedor
electrodomésticos Electrodomésticos Electrodomésticos
Genera ticket de
Vendedor R02 Generar Pedido CUS02 Generar Pedido Cliente Afiliado
pedido
Genera comprobante
Cajero R03 Registrar Pago de Pedido
de pago Registrar Pago de
Venta de CUS03 Cliente Afiliado
Actualizar estado de Pedido
Electrodomésticos - - R04
pedido a “CANCELADO”
- - R05 Registrar Afiliación CUS04 Registrar Afiliación Cliente No Afiliado
Actualizar datos de Actualizar datos de
- - R06 CUS05 Cliente Afilado
afiliación afiliación
- - R07 Consultar Pedidos CUS06 Consultar Pedidos Vendedor

Explicación:

A partir de los requisitos se crean los casos de uso. Puede existir el caso en que más de un requisito se implemente en un caso de uso,
como por ejemplo el caso de uso de sistema CUS03 contiene dos requisitos.

En la columna de actores se indican los roles que interactuarán con los casos de uso identificados. Como nuestro cliente ha solicitado
implementar una solución web para el registro de pedidos, el rol “Cliente afiliado” será quien realice esa funcionalidad y no el Vendedor.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 93

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 94

3.3 TEMA 8: ESTRUCTURANDO DEL 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)

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 95

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 sólo la relación de generalización.

3.3.2.1 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.11.- 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.12.- Ejecución de la inclusión.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 96

3.3.2.2 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.13.- 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.14.- Ejecución de la extensión.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 97

3.3.2.3 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.15.- Relación de generalización entre casos de uso.

Figura 3.16.- 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.17.- Ejecución de la generalización.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 98

3.3.3 Casos de usos abstractos y concretos

Se dice que un caso de uso es abstracto sólo 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 podemos afirmar que:

 Los casos de uso activados por un actor son concretos.

 Los casos de uso incluidos o extendidos que únicamente pueden instanciarse

cuando son llamados por el caso de uso base son casos de uso abstractos

 En el caso de la 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.18.- Diagrama de casos de uso estructurado.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 99

ACTIVIDADES PROPUESTAS
Elabore el Diagrama de Casos de Uso Estructurado del siguiente caso.

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 (Tele
marketing, 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 tele operadoras,
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

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 100

3.3.4. Especificación de caso de uso

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

1.1 Nombre del caso de uso

El nombre del caso de uso debe empezar con un verbo en infinitivo que plasme la
funcionalidad del caso de uso. Veamos algunos casos:
 Para el mantenimiento de datos maestros, los cuales poseen subflujos
como: Agregar, Modificar, Eliminar, etc.
Mantener <Nombre de la información que mantiene>
Por ejemplo: “Mantener Productos”, “Mantener Cliente”.

 Para el tratamiento de documentos legales, formales o de

transacciones. Para tener el control adecuado de los perfiles de los
usuarios y niveles de seguridad se suelen crear varios casos de uso
que manipulan este tipo de documento.
En caso de agregar:
Registrar/Generar <Nombre del documento formal>
Por ejemplo: “Generar Factura”, “Generar Contrato”.
En caso de modificar o eliminar dependerá del documento y de cómo
es tratado en la organización. Por ejemplo:
Para eliminar una factura se crearía el caso de uso “Anular Facturar”
que registra el motivo de la anulación y que cambia el estado de la
factura a anulada y para modificar una factura se creará el caso de
uso “Generar Nota de Crédito”, ya que legalmente una factura no se
puede modificar sin un documento que sustente el cambio.

 Para el tratamiento de la búsqueda de información.

Buscar/Consultar <Información a buscar>
Por ejemplo: “Buscar Productos”, “Consultar Clientes”.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 101

 Para el tratamiento de la verificación de la información, la cual retorna

un valor de verdadero o falso dependiendo de si encontró o no la
información.
Verificar/Validar <información a verificar>
Por ejemplo: “Verificar Existencia de Producto”, “Validar Existencia de
Usuario”.

 Para el tratamiento de documentos informales o de uso interno, el cual

incluye las opciones de mantenimiento en un sólo caso de uso.
Gestionar/Administrar <Nombre del documento informal>
Por ejemplo: “Administrar Cotización”, “Gestionar Nota de Pedido”.
Es necesario aclarar que si uno de los documentos informales originó
un documento formal ya no se puede modificar o anular. Por ejemplo,
una cotización que se aprueba y genera una factura ya no podría
modificarse o anularse.

1.2 Breve descripción

Debería ser un solo párrafo que resuma el objetivo del caso de uso.

1.3 Actores
Desde el punto de vista de un caso de uso específico, existen dos tipos de actores:
 Actores primarios o principales: Activan el caso de uso.
 Actores secundarios: Interactúan con el caso de uso después de
haberse activado.

1.4 Flujo de eventos

Es una secuencia enumerada de pasos que describe la interacción del actor con el
caso de uso. Incluye: Flujo básico, subflujos y flujos alternativos.

1.4.1 Flujo básico

Es el flujo principal del caso de uso y presenta las siguientes reglas:

a) El primer paso
Empieza por el actor primario haciendo algo para activar el caso de
uso. Así:
1. El Caso de uso se inicia cuando <actor> <función>

Por ejemplo:
1. El Caso de uso se inicia cuando la Recepcionista
selecciona la opción “Generar Reserva” en la
interfaz del menú principal.

Si el tiempo es el actor, se empieza así:

1. El Caso de uso se inicia cuando es el fin de
semana.

Si el caso de uso es abstracto, comienza así:

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 102

1. El Caso de Uso se inicia cuando es invocado por

otro caso de uso base.
b) Centrase en el qué, no en el cómo
Mantenga los detalles de diseño fuera del caso de uso.

Por ejemplo, el siguiente paso es incorrecto.

5. El Cliente pulsa el botón Aceptar.

La mejor forma de expresar ese paso es la siguiente:

4. El Cliente selecciona “Aceptar Pedido”.

c) Referencia a un caso de uso incluido

Para especificar la invocación a un caso de uso incluido se utiliza la
siguiente expresión:
El sistema Incluye el CU Buscar Habitación.

Por ejemplo:

7. La recepcionista solicita “Buscar Habitaciones”

disponibles.
8. El sistema Incluye el CU Buscar Habitación.

d) Ramificación dentro de un flujo

Para indicar una ramificación en el flujo se utiliza la palabra Si. La
condición sujeta puede llevar a un conjunto de sub-acciones
(desviaciones simples) o a un subflujo (desviaciones complejas).

El siguiente ejemplo utiliza ramificaciones.

5. Si la Recepcionista elige un cliente
a. Si selecciona “Modificar” ver el Subflujo
Modificar Cliente
b. Si selecciona “Eliminar” ver el Subflujo
Eliminar Cliente.

e) Repetición dentro de un flujo

Para indicar la repetición de un conjunto de acciones se utiliza al
final de la acción la siguiente expresión:
Si <actor> <función>, repite los pasos del <X1> al <X2>.

Por ejemplo:
...
7. La recepcionista solicita “Buscar Habitaciones”
disponibles.
8. El sistema Incluye el CU Buscar Habitación.
9. El sistema muestra las habitaciones disponibles.
10. La Recepcionista ingresa la cantidad de personas
para la habitación seleccionada.
11. El sistema valida la cantidad de personas
ingresada.
12. El sistema calcula y muestra el subtotal del
precio a pagar y el monto total.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 103

13. Si la Recepcionista quiere seleccionar otra

habitación, repite los pasos del 7 al 12.
...

1.4.2 Subflujos
Es opcional en un caso de uso. Pueden presentarse varios subflujos y
cada uno de ellos sigue las mismas reglas del flujo básico.

1.4.3 Flujos alternativos

Son rutas de acceso alternativas a través del caso de uso que capturan
errores, ramificaciones e interrupciones en el flujo principal. En la figura
11.1 se ilustran los caminos posibles de una instancia de caso de uso
(escenario).

11.1. Caminos del Flujo de eventos.

A continuación se muestra dos flujos alternativos para el caso de uso

“Generar Orden de Reparación”.

<Automóvil no Registrado>
En el punto 8, si el sistema verifica que el Automóvil no
está registrado muestra el MSG “Automóvil no registrado”,
la Secretaria puede ir a “Registrar Automóvil” y continuar
con el paso 9.

<Cancelar>
Si la Secretaria solicita “Cancelar” antes de Grabar la
Orden de Reparación, el sistema cierra la interfaz y el
caso de uso finaliza.

1.5 Precondiciones
Restringen el estado del sistema antes de que el caso de uso pueda empezar. Si un
caso de uso no tiene ninguna precondición se debería escribir “Ninguna”. Por
ejemplo:

1. El Recepcionista está logeado en el sistema.

2. Lista de Clientes disponibles.
3. Lista de Habitaciones disponibles.

1.6 Poscondiciones
Restringen el estado del sistema después de que el caso de uso se ha ejecutado. Si
un caso de uso no tiene ninguna poscondición se debería escribir “Ninguna”. Por
ejemplo:

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 104

1. En el sistema queda registrado la reserva con su

detalle.
2. Las habitaciones seleccionadas se actualizan al estado
“Reservadas”.
1.7 Puntos de extensión
Se utiliza para hacer referencia a un caso de uso extendido. Pueden existir varios
puntos de extensión. Por ejemplo:

En el paso 5, el sistema extiende al caso de uso Mantener

Clientes – Flujo básico “Agregar Cliente”.

1.8 Requisitos especiales

En esta sección se especifican los requisitos no funcionales asociados a este caso de
uso. A continuación se muestra un requerimiento físico para el caso de uso “Generar
Factura”:

Contar con Formato especial para imprimir las facturas,

con el Logo de la empresa.

1.9 Prototipos
En esta sección se muestran las interfaces gráficas de usuario diseñadas para el caso
de uso. No es relevante mostrar las interfaces de los mensajes de advertencias o
error.

Ejemplo de especificación de casos de uso

Especificación de caso de uso: Generar Reserva de

Habitación
1. Breve Descripción
El caso de uso permite a la Recepcionista de un Hotel generar una reserva de
habitación(es).Además de saber en qué estado se encuentra la habitación:
reservado, ocupado o disponible.

2. Actor(es)
Recepcionista

3. Flujo de Eventos
3.1. Flujo Básico
1. El Caso de uso se inicia cuando la Recepcionista selecciona la opción
“Generar Reserva” en la interfaz del menú principal.
2. El sistema muestra la interfase RESERVA con los siguientes datos:
Datos del cliente: Código y Nombres y Apellidos.
Datos de la Reserva: fecha de la reserva y cantidad de días a hospedarse.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 105

Datos de las habitaciones: Número de habitación, Tipo, Categoría,

capacidad, monto por día, Sub Total y Monto Total.
Además incluye las opciones: Buscar Cliente, Buscar Habitaciones,
Agregar, Eliminar, Grabar Reserva y Salir.
3. La Recepcionista selecciona “Buscar Cliente”.
4. El sistema Incluye el CU Buscar Cliente.
5. El sistema muestra los datos del cliente.
6. La recepcionista ingresa la fecha de reserva y cantidad de días.
7. La recepcionista solicita “Buscar Habitaciones” disponibles.
8. El sistema Incluye el CU Buscar Habitación.
9. El sistema muestra datos de habitación disponible.
10. La Recepcionista ingresa la cantidad de personas para la habitación
seleccionada y selecciona Agregar.
11. El sistema valida la cantidad de personas ingresada.
12. El sistema calcula y muestra subtotal y monto total a pagar.
13. Si la Recepcionista quiere seleccionar otra habitación, se repite del paso 7
al 12.
14. La Recepcionista selecciona “Grabar Reserva”.
15. El sistema autogenera un número de reserva.
16. El sistema graba la reserva con su detalle y actualiza la(s) habitación(es)
en estado “Reservado”.
17. El sistema muestra el número de reserva y el MSG “Reserva generada
con el Nro. 99999”.
18. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del
menú principal del sistema y finaliza el caso de uso.
3.2. Subflujos
Ninguno.
3.3. Flujos Alternativos
<Cliente no existe>
En el paso 5, si el sistema detecta que el cliente no existe muestra el MSG:
“Cliente no existe” y ofrecerá la posibilidad de registrar al nuevo cliente.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 106

<Habitaciones no disponibles>
En el paso 9, si el sistema detecta que no hay habitaciones disponibles
muestra el MSG: “No hay habitaciones disponibles” y finaliza el caso de uso.

<Cantidad de Personas incorrecta>

En el paso 12, si la Recepcionista ingresó una cantidad mayor a la capacidad
de la habitación seleccionada, el sistema muestra el MSG “Ingrese una
cantidad de personas menor o igual a la capacidad de la habitación” y continúa
con el paso 10.

<Eliminar habitación>
Si la Recepcionista solicita “Eliminar” una habitación seleccionada, antes de
Grabar, el sistema lo borra del detalle y el caso de uso continúa en el paso 13.

4. Precondiciones
4.1. El Recepcionista está logueado en el sistema.
4.2. Lista de Clientes disponibles.
4.3. Lista de habitaciones disponibles.

5. Pos condiciones
5.1. En el sistema queda registrado la reserva con su detalle.
5.2. Las habitaciones seleccionadas se actualizan en estado “Reservadas”.

6. Puntos de Extensión
En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico
“Agregar Cliente.

7. Requisitos Especiales
Ninguno.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 107

8. Prototipos

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 108

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.

3.3.5.1. Objetivos

El propósito de la priorización de 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.

3.3.5.2. Alcance
La priorización permitirá darle la debida atención (y con mas tiempo) a los USE CASE
más complejos e importante.

3.3.5.3. 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.
o Nivel crítico (o primario)
Agrupa a los USE CASE que tienen que ver con las funciones básicas
del sistema.
o 3.2. Nivel de baja importancia (o secundario)
Agrupa a los USE CASE que tienen que ver con las funciones de
soporte del sistema y que no representan mayor riesgo para el
proyecto.

3.3.5.4. Factores tomados en cuenta en la 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 ponderación es 0.3.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 109

 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 ponderación es 0.2.
 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.

EJEMPLO DE PRIORIZACION DE LOS CASOS DE USO “LACTEOS LA LUZ”

I. A continuación se muestra los Subsistemas de “Lácteos La Luz”, de acuerdo a sus

objetivos y tareas.

SUBSISTEMAS
 Servicios al cliente
 Gestión de ventas
 Tareas del despachador
 Tareas ejecutivas.

A. Servicios al cliente
1. Registrar cliente
2. Elaborar pedido
3. Rastrear pedido
4. Consultar cuenta
5. Acusar recibo / reclamo

Importancia Complejidad Riesgo Impacto de Total

en el de desarrollo asociado requerimientos
proceso del no funcionales
negocio
Registrar cliente 10 6 9 9 8.5
Elaborar pedido 9 7 7 9 8
Rastrear pedido 6 8 5 8 6.75
Consultar 9 8 6 9 8
cuenta
Acusar recibo 5 5 3 7 5
/reclamo

B. Gestión de ventas
1. Aceptar / Rechazar pedido
2. Facturar pedidos
3. Actualizar cuenta
4. Consolidar pedido
5. Ordenar producción

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 110

Importancia Complejidad Riesgo Impacto de Total

en el de desarrollo asociado requerimientos
proceso del no funcionales
negocio
Aceptar 8 4 5 3 5
/Rechazar
pedido
Facturar 9 7 8 9 8.25
pedidos
Actualizar 9 7 9 9 8.5
cuenta
Consolidar 10 6 8 6 7.5
pedido
Ordenar 6 8 7 3 6
producción

C. Tareas del despachador

1. Configurar despachos
2. Rastrear pedido
3. Configurar embalaje
4. Configurar ruta
5. Acusar recibo / reclamo
6. Devolver mercancía

Importancia Complejidad Riesgo Impacto de Total

en el de desarrollo asociado requerimientos
proceso del no funcionales
negocio
Configurar 9 6 6 7 7
despachos
Rastrear pedido 7 6 7 6 6.5
Configurar 8 8 7 7 7.5
embalaje
Configurar ruta 7 6 8 6 6.75
Acusar recibo / 4 5 7 6 5.5
reclamo
Devolver 4 7 5 5 5.25
mercancía

D. Tareas Ejecutivas
1. Obtener información de productos
2. Evaluar el desempeño de productos
3. Generar informe

Importancia Complejidad Riesgo Impacto de Total

en el de desarrollo Asociado requerimientos
proceso del no funcionales
negocio
Obtener 8 7 7 6 7
información de
productos
Evaluar el 9 8 7 7 7.75
desempeño de
productos
Generar 7 8 7 7 7.25
informe

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 111

II. Luego de haber priorizado cada subsistema, se agrupa por iteraciones, esta
agrupación consiste en tomar los 3 CU más importantes del subsistema (con
mayor ponderación). Estás iteraciones deberán ser desarrolladas en la fase de
construcción del proceso del sistema.

A. Servicios al cliente
 Iteración 1
Registrar cliente 8.5
Consultar cuenta 8
Elaborar pedido 8
 Iteración 2
Rastrear pedido 6.75
Acusar Recibo / Reclamo 5
B. Gestión de ventas
 Iteración 1
Actualizar cuenta 8.5
Facturar pedidos 8.2
Consolidar pedido 7.5
 Iteración 2
Ordenar roducción 6
Aceptar / Rechazar Pedido 5

C. Tareas del despachador

 Iteración 1
Configurar embalaje 7.5
Configurar despacho 7
Configurar ruta 6.75
 Iteración 2
Rastrear pedido 6.5
Devolver mercancía 5.25
Acusar Recibo / Reclamo 5.5

D. Tareas ejecutivas
 Iteración 1
Evaluar desempeño del producto 7.75
Generar informe 7.25
Obtener información de productos 7

Nota.- Requerimientos primarios serán aquellos que presenten un puntaje mayor a 6.5.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 112

Resumen
 El Modelado de casos uso nos permite representar las funcionalidades del
sistema a implementar.

 El Modelo de casos de uso contiene a los actores y casos de uso, que son los
artefactos relevantes del modelo.

 En el Modelo de casos de uso se crean los siguientes diagramas:

 Diagrama de casos de uso

 Diagrama de actores
 Diagrama de casos de uso por proceso de negocio

 Existen tres relaciones entre casos de uso: Generalización, include y extend.

La generalización también se puede dar entre actores.

 En una relación de generalización, el caso de uso hijo hereda la estructura,

comportamiento y las relaciones del padre.

 En una relación include, el caso de uso incluido encapsula el comportamiento

necesario y reutilizado por varios casos de uso base.

 En una relación extend, el caso de uso extendido encapsula el

comportamiento opcional de un caso de uso base.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 113

CASOS PÁCTICOS

Caso N°1: “Limpia Total S.A.”

Limpia Total S.A. es una empresa especializada en servicios de limpieza integral
mantenimiento y servicios complementarios, labor que desarrolla en forma profesional
y acorde con los requerimientos de sus clientes para que estos puedan delegar a
terceros los servicios y así dedicarse plenamente a su negocio. Esta compañía espera
para el año 2008 ser la número 1 en los servicios de limpieza y espera lograrlo a
través de un control total de los gastos del servicio y un control total en la distribución
del trabajo de los empleados.

La empresa tiene en su equipo comercial la difícil tarea de obtener contratos de

servicios de limpieza, esta tarea se inician cuando un cliente se pone en contacto con
la empresa, Es atendido por un vendedor quien le genera una cotización, verifica
previamente si el cliente se encuentra registrado. si no se encuentra lo registrara en el
sistema. Posteriormente el vendedor trata de concretar la aprobación de la cotización,
cuando el cliente acepta las condiciones el supervisor de Ventas registra el contrato,
obteniendo previamente los datos de la Cotización registrada. Todos los contratos son
entregados al Gerente General, quien evalúa cada contrato y registra el resultado de la
evaluación, previamente realizo una búsqueda de contratos. .El Supervisor de ventas
tiene una consulta detallada de todas las cotizaciones, debiendo realizar una
búsqueda de cotizaciones además el Supervisor puede actualizar los datos de los
clientes.

El Gerente General entrega copias de los contratos al departamento de cobranza, la

secretaria de cobranza emite los Comprobante de pagos (Facturas), previamente
realizo una búsqueda de contratos. Todos los Viernes la Secretaria Genera las Hojas
de Ruta de Cobranza, en esta hoja se asigna un cobrador a cada Comprobante
emitido, previamente realizo una búsqueda de comprobantes. La Secretaria entrega la
Hoja de Ruta y los comprobante de pago asignados (Factura) a cada cobrador, al final
del día el cobrador entrega la Hoja de Ruta, los comprobantes de pago(Facturas) y el
Voucher del depósito de la cuenta bancaria a la secretaria; quien registra el pago de
los comprobantes de pago(Facturas). Previamente realizo una búsqueda de
comprobantes. Adicionalmente la secretaria de cobranza puede actualizar los datos de
los clientes como teléfono, correo, dirección, etc.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 114

Caso N°2: “Automotriz El Chasqui.”

La importadora “Automotriz Chasqui” es una prestigiosa empresa de venta de vehículos
de transporte de pasajeros de la marca “JAC”” esta empresa es distribuidor exclusivo en el
PERU y tiene como visión para el año 2011 convertirse en la empresa líder en la venta de
vehículos de pasajeros, para ello tiene como meta a corto plazo contratar a vendedores A1
para su equipo de ventas y abaratar en 10% los costos de importación de los vehículos por
reducción del flete.

Diariamente los clientes se apersonan a los locales de la empresa a consultar los precios
de los vehículos, e informándoles que le empresa les puede poner en contacto con varios
bancos, para ello si está interesado debe de llenar una solicitud de crédito y traer la
documentación solicitada tales como, copia de DNI, boleta de pago, etc., Cuando ya lleno
la solicitud el vendedor registrara en el sistema la solicitud, verificando previamente si el
cliente se encuentra registrado, si no se encontrase deberá de regístralo en el sistema,
registrando la solicitud como por aprobar. Posteriormente el Jefe de ventas ingresara al
sistema para aprobar o cancelar la solicitud según el status de verificación del cliente;
previamente se realizó la búsqueda de la solicitud. Si la solicitud fue aprobada se le informa
al cliente que deberá de hacer el pago del 20% del valor del automóvil en caja. El cajero
ingresara al sistema para generar el comprobante de pago de la cuota inicial; y le
generara el calendario de pago de las cuotas pactadas. Previamente verifico el status de la
solicitud como aprobada para aceptar el pago.

Otro Servicio de la empresa es el mantenimiento de los vehículos en el taller, el cliente

llevara su vehículo para su mantenimiento. El asistente del taller ingresara al sistema
una solicitud de servicio, verificando previamente si el cliente se encuentra registrado,
si no se encontrase deberá de regístralo en el sistema, registrando la solicitud como
por atender. Después de que el servicio fue dado el cliente se acercara al área de
facturación, el cajero tomara toda la información del sistema valiéndose de la solicitud
de servicio y verificando todo los servicios que se le dio al auto generando el
comprobante de pago correspondiente y registrando la solicitud como cancelada

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 115

Glosario

Artefacto
Pieza discreta de información que es utilizada o producida por un proceso de
desarrollo de software.

Caso de uso abstracto

Un caso de uso es abstracto sólo si se instancia en el contexto de otro caso de uso, es
decir, dependen de otro caso de uso para instanciarse puesto que no existe un actor
que lo active.

Caso de uso concreto

Un caso de uso es concreto si es iniciado por un actor y constituye un completo flujo
de eventos. "Completo" significa que una instancia del caso de uso lleva a cabo toda la
operación solicitada por el actor.

Condición de guardia
Condición que se debe satisfacer para permitir que se dispare una transición asociada.
Es utilizado en Diagrama de actividades a partir de un control de decisión.

CASE Computer Aided Software Engineering

Ingeniería de Software asistida por computadora.

Diagrama
Representación gráfica de un conjunto de elementos, representado en la mayoría de
casos como un grafo conexo de nodos (elementos) y arcos (relaciones).

Diagrama de actividades
Diagrama que muestra el flujo de control datos entre actividades. Cubren la vista
dinámica de un sistema.

Diagrama de casos de uso

Diagrama que representa procesos de negocio o funcionalidades del sistema y
externos.

Diagrama de clases
Muestra un conjunto de clases y sus relaciones.

Diagrama de componentes
Muestra la organización y las dependencias entre un conjunto de componentes
(elementos de implementación) del sistema.

Diagrama de comunicación
Diagrama de interacción que resalta la organización estructural de objetos que envían
y reciben mensajes.

CIBERTEC CARRERAS PROFESIONALES

ANÁLISIS Y DISEÑO DE SISTEMAS I 116

Diagrama de despliegue
Muestra la configuración en tiempo de ejecución de los nodos de procesamiento y
dispositivos que componen una red.

Diagrama de estados
Representa los estados potenciales de los objetos y las transiciones entre esos
estados.

Diagrama de objetos
Muestra un conjunto de objetos y enlaces en un momento dado.

Diagrama de Secuencia
Diagrama de interacción que resalta la secuencia temporal de los mensajes entre
objetos.

Elemento
Constituyente atómico de un modelo.

Escenario
Secuencia específica de acciones que ilustra un comportamiento.

Especificación
Descripción textual de la sintaxis y la semántica de un bloque de construcción
específico; descripción declarativa de lo que algo es o hace.

Estereotipo
Extensión del vocabulario de UML que permite crear nuevos bloques de construcción
derivados a partir de los existentes pero específicos a un problema concreto.

Herramienta CASE
Aplicación informática destinada a aumentar la productividad en el desarrollo de
software reduciendo el coste de las mismas en términos de tiempo y de dinero.

Instancia
Manifestación concreta de un bloque de construcción de UML.

Modelo
Un modelo es una representación de un sistema o aplicación. Un modelo UML es un
modelo que utiliza la notación del Lenguaje Unificado de Modelado para representar
gráficamente un sistema en distintos niveles de abstracción.

Notación
Sistema de signos convencionales que se adoptan para expresar un conjunto de
conceptos sobre el sistema de software por desarrollar.

OMG Object Management Group

Consorcio del cual forman parte las empresas más importantes que se dedican al
desarrollo de software.

OMT Object-Modeling Technique

Es un método para el modelado orientado a objetos, creado por James Rumbaugh,
que dio mayor énfasis a las notaciones gráficas para el análisis orientado a objetos.

CARRERAS PROFESIONALES CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS I 117

OOSE Object-Oriented Software Engineering

Es un método de ingeniería de software orientado a objetos, creado por James
Rumbaugh. Ha sido llamado “un enfoque para el manejo de casos de uso”, en este
enfoque el modelo de casos de uso sirve como un modelo central del cual todos los
otros modelos son derivados.

Perfiles UML
Constituyen el mecanismo que proporciona el UML para extender su sintaxis y su
semántica para expresar los conceptos específicos de un determinado dominio de
aplicación.

Refinamiento
Relación que representa una especificación más completa de algo que ya ha sido
especificado a cierto nivel de detalle.

Requisito
Característica, propiedad o comportamiento deseado de un sistema.

RSA Rational Software Architect

Herramienta CASE 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 y unifica todos los
aspectos de la arquitectura de la aplicación de software.

RUP Rational Unified Process

Proceso Unificado de Rational, metodología del proceso de ingeniería de software que
proporciona un enfoque disciplinado para asignar tareas y responsabilidades dentro de
una organización del desarrollo.

Stakeholder
Personas u organizaciones que están directamente involucradas en la elaboración o
tomas de decisiones claves acerca de la funcionalidad y propiedades de un sistema
software.

UML Unified Modeling Language

Lenguaje unificado de modelado, notación estándar para el modelado de sistemas
Software.

Workspace
Es un directorio que representa el espacio de trabajo y el cual contendrá los proyectos
que se crean en la herramienta RSA.

CIBERTEC CARRERAS PROFESIONALES