Analisis y Diseño de Sistemas I

[Logo: colocar logo nuevo]
[Fuente: Negrita, Arial 48.]
Análisis y Diseño
de Sistemas I
ANÁLISIS Y DISEÑO DE SISTEMAS I 2
CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

ANÁLISIS Y DISEÑO DE SISTEMAS 3
[Fuente: Negrita, Arial Black 28.]
Índice
Presentación 5
Red de contenidos 7
[Fuente: Negrita, Arial 10]
Unidad de Aprendizaje 1uente: Mayúsculas, Negrita, Arial 11]
INGENIERÍA DE SOFTWARE, RUP y UML 9
1.1 Tema 1 : Ingeniería de Software, RUP y UML 11
1.1.1 : Elementos claves de la Ingeniería de Software 12
1.1.2 : Fases de un proceso de Software 13
1.1.3 : Modelos de Proceso de Software 15
1.1.4 : Metodología RUP (Rational Unified Software) 20
1.1.5 : Mejores Prácticas de RUP 21
1.1.6 : Estructura RUP 22
1.1.7 : El Modelado Visual 26
1.1.8 : UML (Lenguaje de Modelado Unificado) 31
1.1.9 : Diagramas UML 2.0
:
1.2 Tema 2 : Herramientas CASE y entorno IBM-RSA 39
1.2.1 : Objetivos de las herramientas CASE 39
1.2.2 Tipos de herramientas CASE 39
1.2.3 : Ejemplos de herramientas CASE 40
Unidad de Aprendizaje 2
PRIMERA DISCIPLINA DE RUP: MODELADO DE NEGOCIO 44
2.1 Tema 3 : Modelado de Negocio 47
2.1.1 : ¿Cuándo es necesario realizar el Modelado de Negocio? 47
2.1.2 : ¿Cuándo no es necesario realizar el Modelado de Negocio? 48
2.1.3 : Actividades para realizar un Modelado de Negocio 48
2.2 Tema 4 : Modelo de Casos de Uso de Negocio - MCUN 51

2.2.1 : Determinar la situación de la Organización 51
2.2.2 : Identificación de los procesos de negocio 51
2.2.3 : Redefinición de los procesos de negocio 51
2.4.4 : Artefactos del Modelo de Casos de Uso de Negocio 52
2.3 Tema 5 Caso Propuesto: CHASQUI EXPRESS 54

2.3.1 : Solución en Rational Software Architect 56
2.3.2 : Solución en Enterprise Architect - SPARX 58
2.4 Tema 6 : Modelo de Análisis de Negocio - MAN 60

2.4.1 : Diseño de realizaciones de procesos de negocio 60
2.4.2 Artefactos del Modelo de Análisis de Negocio 60
:
2.5 Tema 7 : Caso Propuesto: CHASQUI EXPRESS 62
2.5.3 : Solución en Enterprise Architect - SPARX 70
IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

Unidad de Aprendizaje 3
DISCIPLINA DE LA CAPTURA DE REQUISITOS 75
3.1 Tema 8 : Captura de Requisitos 78
3.1.1 : Importancia de la Captura de Requisitos 78
3.1.2 : Dificultades de la captura de Requisitos 78
3.1.3 : Artefactos de la Captura de Requisitos 79
3.1.4 : Actividades para realizar la Captura de RequisitosRequisitos 80
3.1.5 : Requisitos 82
3.1.6 : Requisitos FURPS+ 84
3.1.7 : Técnicas para capturar requisitos 87
3.1.8 : Captura de requisitos a solicitud del cliente 92
3.1.9 : Captura de Actividades a partir del Diagrama de Actividades de 93
Negocio
3.2 Tema 9 : Modelo de Casos de Uso 102

3.2.1 : Identificación de Actores 103
3.2.2 : Identificación de Casos de Uso 106
3.2.3 : Crear el Diagrama de Casos de Uso 108
3.3 Tema 10 : Estructurando el Modelo de Casos de Uso 114

3.3.1 : Objetivos 114
3.3.2 : Tipos de relaciones 115
3.3.3 : Casos de Uso Abstractos y Concretos 118
3.3.4 : Especificación de Casos de Uso 121
3.3.5 : Priorización de Casos de Uso 122

Presentación
[Fuente: Arial 11]
Análisis y Diseño de Sistemas I (ADS1) es un curso que pertenece a la línea formativa.
Se dicta en las carreras de “Computación e Informática” y “Administración y Sistemas”.
Este curso imparte conocimientos relacionados con proceso de la Ingeniería de
Software que permite a los alumnos utilizar una metodología y el Lenguaje de
Modelamiento Unificado (UML) para desarrollar un software de calidad.
El manual para el curso ha sido diseñado bajo la modalidad de unidades de

aprendizaje, las que se desarrollan durante un número determinado de semanas. En
cada una de ellas, se indica: (1) los logros que se busca alcanzar al término de cada
unidad, (2) el tema tratado y (3) los contenidos del tema a tratar. Asimismo, al final de
cada unidad se encontrará actividades que permitirán afianzar los conocimientos
adquiridos en cada sesión de clase.
El curso es teórico-práctico. Este consiste en un taller de desarrollo de proyectos de

software. En primer lugar, se inicia con la comprensión de la Ingeniería de Software y
el proceso de desarrollo de software utilizando la metodología RUP. Continúa con la
presentación del Lenguaje de Modelamiento Unificado (UML). Luego, se desarrolla la
disciplina del Modelado del Negocio. Por último, se concluye con el desarrollo de la
disciplina de la Captura de Requisitos.
.


Red de contenidos
Análisis y Diseño de Sistemas I
Ingeniería de Software, Disciplina del Modelado Disciplina de la Captura

RUP y UML de Negocio de Requisitos
Ingeniería de Modelado de Captura de

Software Negocio Requisitos
Modelado de
Herramientas Modelo de Casos
Casos de Uso de
CASE de Uso
Negocio
Modelo de
Prototipado de
Análisis de
Casos de Uso
Negocio


[Fuente: Negrita, Arial Black 72, En línea con el texto]
UNIDAD
1
[Título de Unidad. Fuente: Negrita, Arial Black 24]
INGENIERÍA DE SOFTWARE,
METODOLOGÍA RUP Y UML
LOGRO DE LA UNIDAD DE APRENDIZAJE
Al término de la unidad, el alumno es capaz de identificar las ventajas y desventajas
de los modelos de procesos de software, y la importancia de emplear una metodología
de desarrollo de Software (RUP). Finalmente, el alumno es capaz de elaborar los
diagramas UML y se familiariza en el uso de Herramientas CASE.

TEMARIO [LOS TEMAS VAN DENTRO DE LA TABLA]
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 : Fases de un proceso de software
1.1.3 : Modelos de Proceso de Software
1.1.4 : Metodología RUP (Rational Unified Process)
1.1.5 : Mejores Prácticas de RUP
1.1.6 : Estructura de RUP
1.1.7 : Modelado Visual empleando UML
1.1.8 : UML (Lenguaje de Modelamiento Unificado)
1.1.9 : Diagramas UML
1.2 Tema 2 : Herramientas CASE y Entorno de IBM-RSA

1.2.1 : Objetivos de las Herramientas CASE
1.2.2 : Tipos de herramientas CASE
1.2.3 : Ejemplos de herramientas CASE
ACTIVIDADES PROPUESTAS
 Los alumnos resuelven un caso para aplicar los Diagramas UML.


[Subtítulo de Unidad – Nivel 1. Fuente: Arial 14]

1.1. TEMA 1: INGENIERÍA DE SOFTWARE
[Subtítulo de Unidad – Nivel 2. Fuente: Arial 12]
Según la RAE1, ingeniería es el “conjunto de conocimientos orientados a la invención
y utilización de técnicas para el aprovechamiento de los recursos naturales o para la
actividad industrial”, también es la “actividad profesional del ingeniero”. Por otro lado,
el término ingeniero es definido como “Persona con titulación universitaria superior
que la capacita para profesar la ingeniería en alguna de sus ramas”. El diccionario El
Pequeño Larousse, define ingeniería como el “conjunto de conocimientos y técnicas
científicas aplicadas a la invención, perfeccionamiento y utilización de la técnica
industrial en todas sus dimensiones”.
Por otro lado, la RAE también define al software como el “conjunto de programas,
instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora”.
Uniendo ambas definiciones, se puede establecer que la ingeniería de software es el

“uso o aplicación de conocimientos y técnicas científicas para crear programas de
computadora”.
La ingeniería de software puede ser definida de múltiples maneras. Es por ello que
existen muchas definiciones expuestas por autores acreditados que comenzaron en su
momento a utilizar el término, entre ellos Bauer, Boehm Zelkovitz y Sommerville.
Otras propuestas son 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, quien indica que la

ingeniería de software es una tecnología multicapa. Como muestra la figura 1.1,
cualquier enfoque de ingeniería, incluida ingeniería del software como lo indica el
autor, debe apoyarse sobre un compromiso de organización de calidad. La calidad,
según indica, es la concordancia del software producido con los requisitos
explícitamente establecidos, con los estándares de desarrollo prefijados y con los
requisitos implícitos no establecidos formalmente, que desea el usuario.
Figura 1: Capas de la Ingeniería de Software según Pressman
1 RAE. Real Academia Española

2 IEEE, Institute of Electrical and Electronics Engineers
3 ACM, Association for Computing Machinery

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

ingeniería de software es la unión que mantiene juntas las capas de tecnología y que
permite un desarrollo racional y oportuno de la ingeniería de software. El proceso
define un marco de trabajo para un conjunto de áreas clave de proceso que se deben
establecer para la entrega efectiva de la tecnología de la ingeniería de software. Las
áreas claves del proceso forman la base del control de gestión de proyectos del
software y establecen el contexto en el que se aplican los métodos técnicos, se
obtienen productos del trabajo (modelos, documentos, datos, informes, formularios,
etc.), se establecen hitos, se asegura la calidad y el cambio se gestiona
adecuadamente.
Los métodos de la ingeniería del software indican «cómo» construir técnicamente el

software. Estos abarcan una gran gama de tareas que incluyen análisis de requisitos,
diseño, construcción de programas, pruebas y mantenimiento. Los métodos de la
ingeniería del software dependen de un conjunto de principios básicos que gobiernan
cada área de la tecnología e incluyen actividades de modelado y otras técnicas
descriptivas.
Las herramientas de la Ingeniería del software proporcionan un enfoque automático o

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

software es lograr productos de software de calidad (tanto en su forma final como
durante su elaboración), mediante un proceso apoyado por métodos y herramientas.
1.1.1. Elementos claves de la Ingeniería de Software

La ingeniería de software incluye los siguientes elementos clave: paradigmas,
estrategias, métodos o técnicas, herramientas y procesos, los que a continuación se
detallan.
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.
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. Fases de un proceso software

Con independencia del área de aplicación, tamaño o complejidad del proyecto, el
trabajo que se asocia a la ingeniería del software se puede dividir en tres fases
genéricas:
 Fase de definición
 Fase de desarrollo
 Fase de mantenimiento
Figura 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 lo tanto, han de identificarse los requisitos clave del sistema y
del software. Aunque los métodos aplicados durante la fase de definición variarán
dependiendo del paradigma de ingeniería del software (o combinación de paradigmas)
que se aplique, de alguna manera tendrán lugar tres tareas principales:
 La ingeniería de sistemas o de información

 Planificación del proyecto de software
 Análisis de requisitos.

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
cómo ha de realizarse la prueba. Los métodos aplicados durante la fase de desarrollo
variarán, aunque las tres tareas específicas técnicas deberían ocurrir siempre:
 El diseño del Software

 La generación de código
 Las pruebas de software
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, Sistema Operativo, Reglas de Negocio,
etc.)
 Perfectivo: Para agregar otras funciones adicionales que van a producir
beneficios.
 Preventivo: También llamado reingeniería del software. Estos cambios se
realizan a fin 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 e análisis de indicadores.
 Gestión de riesgos.

1.1.3. Modelos de proceso de software

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

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

 Modelo de Construcción de Prototipos
 Modelo de Desarrollo Rápido de Aplicaciones (DRA)
 Modelos Evolutivos de Procesos de Software:
o Modelo Incremental
o Modelo Espiral
o Modelo de Desarrollo Concurrente
 Modelo de Desarrollo basado en Componentes
1.1.3.1. Modelo Cascada

Llamado algunas veces ciclo de vida básica o modelo en cascada. El modelo lineal
secuencial propone un enfoque sistemático, secuencial, para el desarrollo del software
que comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación,
pruebas y mantenimiento. Es ideal para proyectos pequeños, rígidos, y donde se
especifiquen muy bien los requisitos.
Existen algunos problemas que ocurren al utilizar este modelo:
 Los proyectos reales raras veces siguen el modelo secuencial que propone
este modelo, pues traslapan las etapas.
 A menudo es difícil que el cliente exponga explícitamente todos los requisitos.
El interesado debería exponer los requisitos en la etapa inicial, pero en realidad
éste lo hace a lo largo de todo el proceso y esto complica las cosas.
 El cliente debe tener paciencia dado que la primera versión del software se
tendrán recién al final del proceso. A veces, el afán del cliente hace que la
aplicación final no cumplo con los requsitos definidos.

Figura 3: Modelo Cascada
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.
Con este modelo se reduce el riesgo de construir productos que no satisfagan las
necesidades del usuario. Por otro lado, reduce costos y aumenta la probabilidad de
éxito. Pero el problema es que el cliente se sienta decepcionado por no permitirle usar
la primera versión del prototipo o que el desarrollador se sienta tentado en aumentar el
prototipo para construir el sistema final sin tener en cuenta cuestiones de calidad.
Figura 4: Modelo de Construcción de Prototipos

1.1.3.3. Modelo de Desarrollo Rápido de Aplicaciones (DRA)
Es una adaptación a alta velocidad del modelo lineal secuencial en el que se logra el
desarrollo rápido de proyectos grandes utilizando un enfoque de construcción basado
en el componente. Comprende las siguientes fases: Análisis, diseño, código, pruebas
y entrega. Si no existe el compromiso entre clientes y desarrolladores o si los riesgos
técnicos son altos, los proyectos DRA fracasan.
Figura 5: Modelo de Desarrollo Rápido de Aplicaciones
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 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.
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 7: Modelo Espiral
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

modelo de Desarrollo Concurrente es la capacidad de describir las múltiples

actividades del software las que ocurren simultáneamente.
Dado que los requisitos cambian, es muy probable que una vez que haya comenzado
la fase de diseño, sea necesario incorporar cambios. En estos casos No se debe
detener el diseño, sino que se debe continuar “si es posible” al mismo tiempo que se
modifican los requisitos. Por lo tanto en este modelo, diversas actividades pueden
estar ocurriendo concurrentemente.
Figura 8: Modelo de Desarrollo Concurrente
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. Caso siempre hay que hacer ajustes
para adecuarlos.
 Modificación de requisitos: Se adaptan (en lo posible) los requisitos para
concordar con los componentes de la etapa anterior. Si no se puede realizar
modificaciones en los requisitos, hay que seguir buscando componentes más
adecuados (fase 1).
Diseño del sistema con reutilización: Se diseña o reutiliza el marco de trabajo para el
sistema. Se debe tener en cuenta los componentes localizados en la fase 2 para
diseñar o determinar este marco.
Desarrollo e integración: El software que no puede comprarse, se desarrolla. Se
integran los componentes y subsistemas. La integración es parte del desarrollo en
lugar de una actividad separada.

Figura 9: Modelo de basado en componentes
1.1.4. Metodología RUP (Rational Unified Process)

RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un
software que define claramente quien, cómo, cuándo y qué debe hacerse en el
proyecto. Presenta tres características esenciales:
 Dirigido por Casos de Uso: 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.
 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.
Figura 10: Mejores Prácticas RUP
Desarrollo Iterativo
En función de la cada vez mayor complejidad solicitada para los sistemas de software,
ya no es posible trabajar secuencialmente, es decir, definir primero el problema
completo, luego diseñar toda la solución, construir el software y finalmente, testear el
producto. Es necesario un enfoque iterativo, que permita una comprensión creciente
del problema a través de refinamientos sucesivos, llegando a una solución efectiva
luego de múltiples iteraciones acotadas en complejidad.
RUP utiliza y soporta este enfoque iterativo que ayuda a atacar los riesgos mediante la
producción de releases ejecutables progresivos y frecuentes que permiten la opinión e
involucramiento del usuario.
A través de las iteraciones que generan releases ejecutables, se logra detectar en

forma temprana los desajustes e inconsistencias entre los requisitos, el diseño, el
desarrollo y la implementación del sistema, manteniendo al team de desarrollo
focalizado en producir resultados.
Administración de Requisitos
Los requisitos son las condiciones o capacidades que el sistema debe conformar. La
Administración de Requisitos es un enfoque sistemático para hallar, documentar,
organizar y monitorear los requisitos cambiantes de un sistema.
La Administración de Requisitos permite:
a) que las comunicaciones estén basadas en requisitos claramente definidos.

b) que los requisitos puedan ser priorizados, filtrados y monitoreados.
c) que sea posible realizar evaluaciones objetivas de funcionalidad y
performance.
d) que las inconsistencias se detecten fácilmente
RUP describe cómo:
a) Obtener, organizar y documentar la funcionalidad y restricciones requeridas.

b) Documentar y monitorear las alternativas y decisiones.
Las nociones de Casos de Uso y de Escenarios utilizadas en RUP han demostrado ser
una manera excelente de capturar los requisitos funcionales y asegurarse que dirigen
el diseño, la implementación y la prueba del sistema, logrando así que el sistema
satisfaga las necesidades del usuario.
Arquitectura basada en Componentes
El proceso de software debe focalizarse en el desarrollo temprano de una arquitectura

robusta ejecutable, antes de comprometer recursos para el desarrollo en gran escala.
RUP describe cómo diseñar una arquitectura flexible, que se acomode a los cambios,
comprensible intuitivamente y promueve una más efectiva reutilización de software.
Soporta el desarrollo de software basado en componentes: módulos no triviales que
completan una función clara. RUP provee un enfoque sistemático para definir una
arquitectura utilizando componentes nuevos y preexistentes.
Modelamiento Visual
RUP muestra cómo representar el software visualmente para capturar la estructura y

comportamiento de arquitecturas y componentes. 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 cómo
automatizar la integración y administrar la conformación de releases.
1.1.6. Estructura 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 11: Fases y Disciplinas 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.
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 12: Elementos RUP que definen un 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 de proceso
Orientados al desarrollo del software. Comprende:
 Modelado del negocio: Describe la estructura y la dinámica de la organización

donde se va a implantar el sistema que construyamos.
 Requisitos: Establece exactamente lo que tiene que hacer el sistema, para
ello se extrae los requisitos utilizando diferentes métodos.
 Análisis y Diseño: Traduce los requisitos a una especificación que describe
cómo implementar el sistema, creando para ello, diferentes vistas
arquitectónicas.
 Implementación: Tiene en cuenta el desarrollo de software, las pruebas
unitarias y la integración.
 Pruebas: Describe la ejecución de pruebas y las métricas para rastreo de
defectos.
 Despliegue o Implantación: Incluye actividades relacionadas con la entrega
de la aplicación.
1.1.6.4. Flujos de trabajo de apoyo
También conocidos como flujos de trabajo de soporte. Están orientados a la gestión

del proyecto. Éstos son:
 Configuración y Control de cambios: Mantiene la integridad de todos los

artefactos que se crean en el proyecto. También mantiene información del
proceso evolutivo que se ha seguido
 Gestión del proyecto: Es el arte de lograr un balance al gestionar objetivos,
riesgos y restricciones para desarrollar un producto que sea acorde a los
requisitos de los clientes y los usuarios.
 Entorno: Cubre la infraestructura necesaria para desarrollar un sistema.
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 llevar a

cabo un conjunto de actividades como ser el dueño de un conjunto de artefactos. Por

ejemplo, la figura 1.13 ilustra el rol del arquitecto de software.
Figura 13: Actividades de un Arquitecto de Software
A continuación se lista algunos roles específicos dentro de cada rol genérico:
 Analista de Procesos de Negocio

 Diseñador de Negocio
Analistas
 Analista de Sistema
 Especificador de requisitos
 Arquitecto de Software
 Diseñador
 Diseñador de Interfaz de Usuario
Desarrolladores  Diseñador de Cápsulas
 Diseñador de Bases de Datos
 Implementador
 Integrador
 Jefe de Proyecto
 Jefe de Control de Cambios
 Jefe de Configuración
 Jefe de Pruebas
Gestores
 Jefe de Despliegue
 Ingeniero de Procesos
 Revisor de Gestión del Proyecto
 Gestor de Pruebas
 Documentador Técnico
 Administrador de Sistema
Apoyo  Especialista en herramientas
 Desarrollador de cursos
 Artista gráfico

 Especialista en Pruebas (Tester)

Especialista en
 Analista de Pruebas
Pruebas
 Diseñador de Pruebas
 Stakeholders
 Revisor
Otros roles
 Coordinador de revisiones
 Revisor Técnico.
1.1.7. El Modelado 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:
 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. UML (Lenguaje de Modelado Unificado)
El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado visual que se

usa para visualizar, especificar, construir y documentar artefactos de un sistema de
software. 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á pensado 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.
1.1.8.1. Breve Historia
Los lenguajes de modelado de objetos aparecieron en la década de 1980, llegando a

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

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

Rumbaugh se unió a Booch en Rational Software Corporation (empresa donde
trabajaba Booch). Unificaron sus métodos de modelado y elaboraron el borrador de la
versión 0.8 de UML. En 1995 Jacobson también se incorporó a Rational, incorporando
así OOSE a UML. En 1996 se publicó la versión 0.9 de UML. Las tres personalidades
que dieron el origen a UML son conocidas como “los Tres Amigos”.
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.5, la cual fue liberada en marzo del 2015. UML 2.5
incluye tres (03) nuevos diagramas: Diagrama de Modelo, Diagrama de Manifestación,
Diagrama de Arquitectura de Red.
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.
Versión Fecha de lanzamiento

2.5 Marzo 2015
2.4.1 Agosto 2011
2.4 Marzo 2011
2.3 Mayo 2010
2.2 Febrero 2009
2.1.2 Noviembre 2007
2.1.1 Agosto 2007
2.0 Julio 2005
1.5 Marzo 2003
1.4 Septiembre 2001
1.3 Marzo 2000
Tabla 1: Versiones de UML
¿Qué es la OMG?
La OMG (Object Management Group) es una asociación sin fines de lucro formada por
grandes corporaciones, muchas de ellas de la industria del software, como por
ejemplo: IBM, Apple Computer, Sun Microsystems Inc y Hewlett-Packard. Esta
asociación se encarga de la definición y mantenimiento de estándares para
aplicaciones de la industria de la computación. Otro de los estándares definidos por la
OMG, además del UML, es CORBA, el cual permite interoperabilidad multiplataforma a
nivel de objetos de negocio.

1.1.8.2. Objetivos UML
Los objetivos de UML son muchos, pero se pueden sintetizar en las siguientes:
 Visualizar: UML permite expresar de una forma gráfica un sistema de forma

que otro lo puede entender.
 Especificar: UML permite especificar cuáles son las características de un
sistema antes de su construcción.
 Construir: A partir de los modelos especificados se pueden construir los
sistemas diseñados.
 Documentar: Los propios elementos gráficos sirven como documentación del
sistema desarrollado que pueden servir para su futura revisión.
1.1.8.3. Especificaciones fundamentales del UML 2.0
En las versiones previas del UML, se hacía un fuerte hincapié en que UML no era un
lenguaje de programación. Un modelo creado mediante UML no podía ejecutarse. En
el UML 2.0, esta asunción cambió de manera drástica y se modificó el lenguaje, de
manera tal que permitiera capturar mucho más comportamiento (Behavior). De esta
forma, se permitió la creación de herramientas que soporten la automatización y
generación de código ejecutable, a partir de modelos UML.
Para lograr los objetivos de UML enunciados en el punto anterior, varios aspectos del
lenguaje fueron reestructurados y/o modificados. La especificación se separó en
cuatro especificaciones (paquetes) bien definidas, tal como se muestra en la siguiente
figura.
Figura 14: 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,
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. Supra-estructura
La superestructura del UML es la definición formal de los elementos del UML. Es

aquí donde se definen los diagramas y los elementos que los componen. Esta
definición sola contiene más de 640 páginas. La superestructura es utilizada por los
desarrolladores de aplicación. Es aquella sobre la que hablan los libros y la que la
mayoría conoce de versiones anteriores del UML.
Se encuentra dividida en niveles. Estos niveles se conocen como:
 Básico (L1): Contiene los elementos básicos del UML 2.0, entre ellos:
Diagramas de clases, Diagramas de actividades, Diagramas de Interacciones,
y Diagramas de Casos de Uso
 Intermedio (L2): Contiene los siguientes diagramas: Diagramas de estado,
Perfiles, Diagramas de Componentes y Diagramas de despliegue.
 Completo (L3): Representa la especificación del UML 2.0 completa, como por
ejemplo: las Acciones, Características avanzadas y PowerTypes, entre otros.
Es importante destacar que basta con que una herramienta implemente el nivel de
conformidad Básico (L1), para que se considere UML 2.0 compatible. Por eso, es
normal ver una disparidad de características (features) bastante amplia entre dos
herramientas distintas, aunque estas sean UML 2.0 compatibles.
1.1.8.5. Infraestructura
En la Infraestructura del UML se definen los conceptos centrales y de más bajo nivel.
La Infraestructura es una 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.

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)

Figura 15: Jerarquía de 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 encargarán del funcionamiento y la relación entre
uno y otro.
Figura 16: Diagrama de Clases de Análisis

Figura 17: 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.
Figura 18: 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 19: 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 20: Diagrama de Estructura Compuesta
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 21: Diagrama de Despliegue
1.1.9.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 22: Diagrama de Actividades
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 23: 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 24: Diagrama de Casos de Uso
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 solo para aquellas clases que tengan un número de estados bien
definidos y en donde el comportamiento de la clase es afectado y cambiado por los
distintos estados.
Figura 25: Diagrama 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 26: Diagrama de Secuencia
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 27: 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 28: Diagrama de Tiempos
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 29: Diagrama de Interacción

1.2. TEMA 2: HERRAMIENTAS CASE

Las herramientas CASE (Computer Aided Software Engineering) son diversas
aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de
software y reduce el costo de 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 CASE
 Mejorar la productividad en el desarrollo y mantenimiento del software

 Aumentar la calidad del software
 Mejorar el tiempo y coste de desarrollo y mantenimiento de los sistemas
informáticos
 Mejorar la planificación de un proyecto
 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 CASE
La siguiente clasificación es la más habitual basada en las fases del ciclo de desarrollo
que cubren:
 Upper CASE (U-CASE), herramientas que ayudan en las fases de

planificación, análisis de requisitos y estrategia del desarrollo, usando, entre
otros, diagramas UML.
 Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y
diseño de la aplicación.
 Lower CASE (L-CASE), herramientas que semiautomatizan la generación de
código, crean programas de detección de errores, soportan la depuración de
programas y pruebas. Además automatizan la documentación completa de la
aplicación. Aquí pueden incluirse las herramientas de Desarrollo rápido de
aplicaciones.
 Integrated CASE (I-CASE), herramientas que engloban todo el proceso de
desarrollo de software, desde análisis hasta implementación.

1.2.3. Ejemplos de Herramientas CASE
A continuación, se muestran productos que soportan UML 2.0.
1.2.3.1. Rational Software Architect (IBM-RSA)

Es una herramienta de diseño y construcción para arquitectos de software y
desarrolladores sénior para crear aplicaciones en la plataforma Java o en C++.
Permite un desarrollo basado en modelos con el lenguaje UML (Unified Modeling
Language) y unifica todos los aspectos de la arquitectura de la aplicación de software.
Dentro de un equipo de desarrollo, los arquitectos de software y los desarrolladores

senior 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.
Figura 30: Rational Software Architect - IBM

1.2.3.2. Enterprise Architect
Enterprise Architect es una herramienta de análisis y diseño intuitiva, flexible y

poderosa para construir software robusto y mantenible. Desde la recolección de
requerimientos, pasando por el análisis, modelado, implementación y pruebas hasta
despliegue y mantenimiento; Enterprise Architect es una herramienta de modelado
UML rápida, rica en funcionalidad y multiusuario que conduce el éxito de su proyecto
de software.
Enterprise Architect permite al equipo de desarrollo:
 Acompañamiento en todo el proceso de desarrollo.

 Administración de modelos UML.
 Generación de reportes.
 Administración de proyectos.
 Generación de código.
 Ingeniería Inversa.
 Debugging.
 Modelado de datos.
 Modelado de XML.
 Transformaciones MDA.
Enterprise Architect es una herramienta gráfica multiusuario diseñada para al equipo

de desarrollo a construir sistemas robustos y mantenibles. Además posee facilidades
de incorporadas de reportes y documentación, de alta calidad.
Enterprise Architect es una herramienta muy ligera y rápida en su uso. Permite el

trabajo distribuido permitiendo la creación de modelos en parapelo por múltiples
usuarios. Posee además la capacidad de integrarse a controladores de versiones.
Actualmente en su versión 12.1, la cual implementa las últimas actualizaciones de

UML 2.5.
Figura 31: Enterprise Architect - Sparx Systems

1.2.3.3. StarUML
StarUML es una herramienta desarrollada por MKLab. Este software está licenciado
bjo una versión modificada de GNU GPL hasta el 2014, fecha en que una versión
reescrita 2.0.0 fue liberado para pruebas beta bajo un licencia propietaria.
Despues de ser abandonado por algún tiempo, el proyecto tuvo un renacimiento para
pasar de Delphi para Java/Eclipse y luego se detuvo de nuevo. En el 2014, la versión
reescrita fue lanzada como software propietario. Sin embargo, la comunidad de la
versión de código abierto aún continúa activa.
StarUML soporta la mayoría de los tipos de diagramas UML especificados en su

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

Resumen
[Fuente: Arial 11]
1. RUP es un proceso o marco de trabajo para el desarrollo de un proyecto de un

software que define claramente quién, cómo, cuándo y qué debe hacerse en el
proyecto.
2. RUP es un proceso que se describe en dos fases:

a. Fases:
 Inicio
 Elaboración
 Construcción
 Transición
b. Disciplinas:
 Modelado de Negocio
 Requerimientos
 Análisis y Diseño
 Implementación
 Desarrollo de Pruebas
 Gestión de Cambios y Configuración
 Gestión de Proyectos
 Entorno
3. Un rol define el comportamiento y responsabilidades de un individuo o grupo de

individuos.
4. UML es un lenguaje de modelado visual que se usa para visualizar, especificar,

construir y documentar artefactos de un sistema de software.
5. Las Herramientas CASE son aplicaciones informáticas destinadas a aumentar la

productividad en el desarrollo de software y reduce el costo de las mismas en
términos de tiempo y de dinero.
Pueden revisar los siguientes enlaces para ampliar los conceptos vistos en esta
unidad:
[Fuente: Arial 10.]
o http://www.uml.org/
o http://www.sparxsystems.com.au/resources/uml2_tutorial/
o http://staruml.io/

UNIDAD
2
DISCIPLINA DE MODELADO DE
NEGOCIOta, Arial 12]
Al término de la unidad, el alumno sustenta el primer avance de su proyecto
relacionado a la elaboración de la documentación del Modelado de Negocio de un
caso de estudio utilizando una Herramienta CASE. Este avance incluye el desarrollo
del Modelo de Casos de Uso de Negocio (MCUN) y el Modelo de Análisis de Negocio
(MAN).
TEMARIO [LOS TEMAS VAN DENTRO DE LA TABLA]

2.1 Tema 3 : Modelado de Negocio
2.1.1 : ¿Cuándo es necesario realizar el Modelado de Negocio?
2.1.2 : ¿Cuándo no es necesario realizar el Modelado de Negocio?
2.1.3 : Actividades para realizar un Modelado de Negocio
2.2 Tema 4 : Modelo de Casos de Uso de Negocio - MCUN

2.2.1 : Determinar la situación de la Organización
2.2.2 : Identificar los Procesos de Negocio
2.2.3 : Redefinición de los Procesos de Negocio
2.2.4 : Artefactos del Modelo de Casos de Uso de Negocio
2.3 Tema 5 : Caso Propuesto de Modelo de Casos de Uso de Negocio

Caso : Chasqui Express S.A.
2.3.1 : Solución en Rational Software Architect
2.3.2 : Solución en Enterprise Architect - Sparx
2.5 Tema 6 : Modelo de Análisis de Negocio - MAN

2.4.1 : Diseño de realizaciones de los Procesos de Negocio
2.4.2 : Artefactos del Modelo de Análisis de Negocio
2.6 Tema 7 : Caso Propuesto de MCUN y MAN

Caso : Chasqui Express S.A.
2.5.1 : Solución en Rational Software Architect
Caso : Calidad Educatica
2.5.2 Solución en Rational Software Architect
2.5.3 Solución en Enterprise Architect - Sparx
Otros Casos Propuestos
Caso : Imprensa Laser Data
Caso : Pastelo


Fuente: Arial 12]
 Los alumnos desarrollan el Modelo de Casos de Uso de Negocio (MCUN) de los
Procesos de Negocio de un caso propuesto.
 Los alumnos desarrollan el Modelo de Análisis de Negocio (MAN) de los
Procesos de Negocio de un caso propuesto.


2.1. TEMA 3: MODELADO DE NEGOCIO

La necesidad de esta disciplina surge ante el hecho de que muchos de los productos
software que se desarrollan automatizan algunos o todos los procesos existentes en
un negocio, y es necesario estudiar las implicaciones de los cambios producidos por la
adopción de estos productos. Hay que entender cómo funciona el negocio que se
desea automatizar para tener garantías de que el software desarrollado va a cumplir
su propósito, y por esto, se hace un estudio en el dominio del negocio además de en el
dominio del software.
Así, los objetivos de esta disciplina son los siguientes:
 Entender los problemas actuales en la organización objetivo para identificar los

aspectos a mejorar.
 Estudiar el impacto que pueden producir los cambios a nivel organizativo.
 Asegurar que los clientes, usuarios finales, desarrolladores y otros involucrados
tienen una visión común de la organización considerada.
 Obtener los requisitos del sistema software que den soporte a la organización
objetivo.
 Entender como el sistema software encaja en la organización.
Por consiguiente, el Modelo del Negocio proporciona una vista estática de la estructura
de la organización y una vista dinámica de los procesos dentro de la organización.
Los creadores de RUP señalan que el modelo de negocio está soportado por dos
artefactos principales:
 Modelo de casos de uso del negocio (MCUN)

 Modelo de análisis del negocio (MAN)
El modelo de casos de uso de negocio describe los procesos de negocio de una

empresa en términos de casos de uso del negocio y actores del negocio que se
corresponden con los procesos del negocio y los clientes, respectivamente. Por otro
lado, el modelo de análisis del negocio, es un modelo interno a un negocio, que
describe cómo cada caso de uso de negocio es llevado a cabo por un grupo de
trabajadores que utilizan entidades del negocio.
El conjunto completo de artefactos del modelo de negocio, mostrado en la figura 2.1,

captura y presenta el contexto del sistema y sirven como entrada y referencia para la
definición de los requisitos del sistema.
2.1.1. ¿Cuándo es necesario realizar el Modelado de Negocio?
 Cuando el grupo de trabajo es nuevo en la organización.

 Cuando la organización ha enfrentado un reciente proceso de reingeniería de
negocios.
 Cuando la organización está planificando un proceso de reingeniería de
negocios.
 Cuando el software a construir será utilizado por una porción importante de la
organización.
 Existen flujos de trabajo complejos, dentro de la organización, que no están
documentados.

 Cuando se es un consultor en una organización en la cual no se ha trabajado

antes.
Figura 33: Artefactos del Modelado de Negocio
2.1.2. ¿Cuándo no es necesario realizar el Modelado de Negocio?
 Cuando se tiene un conocimiento de la estructura de la organización, de las

metas, de la visión y de los clientes/usuarios.
 Cuando el software a construir será usado por una pequeña parte de la
organización, y no tiene un efecto en el resto del negocio.
 Cuando los flujos de trabajo de la organización están bien documentados.
 Cuando el tiempo no lo permita, no todos los procesos tienen el tiempo
necesario para completar un análisis de negocio.
2.1.3. Actividades para realizar un Modelado de Negocio
Según RUP, el Modelado de Negocio comprende las siguientes actividades:

Figura 34: Actividades del Modelado de Negocio
 Determinar la situación de la organización

 Describir el actual negocio
 Identificar los procesos de negocio
 Refinar las definiciones de los procesos de negocio
 Diseñar las realizaciones de los procesos de negocio
 Refinar roles y responsabilidades
 Explorar procesos automatizados
 Desarrollar un modelado de dominio
En este apartado trataremos la ejecución de actividades relevantes que permiten

obtener los artefactos principales del Modelo de Negocio.
Los pasos que contemplaremos para obtener el Modelo de casos de uso del negocio
son:

 Determinar la situación de la organización

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

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

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. Redefinición de los Procesos de Negocio

Consiste en:
a) Detallar la definición de los casos de uso del negocio.

b) Describir cómo los casos de uso del negocio soportan los objetivos de negocio.
c) Verificar que los casos de uso del negocio representan correctamente cómo el
negocio es conducido.

Aquí se refina la Especificación de Caso de Uso del Negocio, describiendo paso a

paso las actividades que se desarrollan en el proceso de negocio.
2.2.4. Artefactos del Modelo de Casos de Uso de Negocio
Artefacto Descripción
Documento que contiene la visión del negocio, un

glosario de términos del negocio, los objetivos del
negocio y reglas del negocio.
Análisis de Negocio
Es un requisito que debe ser satisfecho por el negocio.
Describe el valor deseado de una medida en particular
a futuro, y se utiliza para planear y administrar las
actividades del negocio. El objetivo debe ser claro,
mesurable, alcanzable, realista y sensible al tiempo.
Se permite la relación de dependencia entre objetivos
Objetivo de Negocio 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
Caso de Uso de Negocio
vista 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.
Actor de Negocio
Representa la vista externa del negocio.
Es un modelo que describe la dirección e intención del
negocio. La dirección es provista por los objetivos del
negocio. Mientras que la intención es expresada por los
diagramas que permiten ver cómo interactuar con el
Modelo de Casos de Uso de
entorno.
Negocio
Reporte que contiene información de los actores del

negocio identificados en el modelo de casos de uso del
negocio.
Actores de Negocio
Documento que contiene las características de un

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

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

el negocio. Ejm:
“El pago de planillas se realizará los días 25 de cada
Reglas de Negocio mes y vía depósito en cuenta bancaria.”
Tabla 2: Artefactos del Modelo de Casos de Uso de Negocio

2.3. TEMA 5: CASO PROPUESTO MODELO DE CASOS DE

USO DE NEGOCIO
CASO: CHASQUI EXPRESS S.A.

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

como en Provincias, lugares a donde los clientes acuden para realizar sus envíos.
Al llegar al Centro de Servicios, el cliente solicita realizar una operación de envío al

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

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

zona de “Salida”.
Al finalizar el día, el Courier encargado de recoger los envíos para transportarlos a la

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

contacta por vía telefónica con un Asesor de Servicio al Cliente, quién le solicita el
número de su guía aérea. El cliente le entrega este dato y el Asesor de Servicio al
Cliente verifica si es correcto y si ha sido registrado. Si existe consulta en el sistema

Global Shipment, el lugar y último checkpoint registrado, luego interpreta la

información y se la brinda al Cliente.
Realizar lo siguiente:
 Elaborar la estructura del Proyecto en una Herramienta CASE.
 Identificar los Casos de Uso de Negocio
 Identificar los Actores de Negocio
 Identificar los Objetivos de Negocio
 Elaborar el Diagrama de Casos de Uso de Negocio.

2.3.1. SOLUCIÓN EN RATIONAL SOFTWARE ARCHITECT :

Estructura del proyecto: Modelo de Casos de Uso de Negocio
Figura 35: Estructura del Modelo de Casos de Uso de Negocio en RSA
2.3.1.1. Casos de Uso de Negocio
Figura 36: Casos de Uso de Negocio en RSA
2.3.1.2. Actores de Negocio
Figura 37: Actores de Negocio en RSA

2.3.1.3. Objetivos de Negocio
Figura 38: Objetivos de Negocio en RSA
2.3.1.4. Diagrama de Casos de Uso de Negocio
Figura 39: Diagrama General de Casos de Uso de Negocio en RSA

2.3.2. SOLUCIÓN EN ENTERPRISE ARCHITECT - SPARX

2.3.2.1. Estructura del proyecto: Modelo de Casos de Uso de Negocio
Figura 40: Estructura del Modelo de Casos de Uso de Negocio en EA
2.3.3. Casos de Uso de Negocio

class CUN
Recepción de paquete Entrega de paquete Seguimiento de paquete
Figura 41: Casos de Uso de Negocio en EA
2.3.4. Actores de Negocio

class AN
«business actor»
Remitente
«business actor»
Cliente
«business actor»
Destinatario
Figura 42: Actores de Negoci en EA

2.3.5. Objetivos de Negocio

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

Reducir el tiempo de env ío de
Reducir el número de paquetes
paquete en un 10% respecto al dañados en un 50% respecto al
período anterior
semestre 2015-II
Figura 43: Objetivos de Negocio en EA
2.3.6. Diagrama de Casos de Uso de Negocio

uc Diagrama General de Casos de Uso de Negocio
Recepción de paquete
«business actor»
Remitente
Seguimiento de
paquete
«business actor»
Cliente
Entrega de paquete
«business actor»
Destinatario
Figura 44: Diagrama General de Casos de Uso en EA

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

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

Consiste en identificar todos los roles, productos, entregables del negocio y describir
cómo el proceso del negocio será llevado a cabo por los trabajadores y las entidades
dentro del negocio.
El documento que plasma la descripción breve de trabajadores del negocio y cómo

ellos manipulan las entidades del negocio es Trabajadores del Negocio.
Además, se crea el artefacto Entidades del Negocio para describir las entidades del
negocio y especificar, mediante diagramas de estado, los estados de cada una de las
entidades.
Para la realización de cada proceso del negocio se crea un Diagrama de Clases de

Negocio y un Diagrama de Actividades de Negocio.
Al finalizar esta actividad, se completará cada Especificación de Caso de Uso del

Negocio generado en el modelo de casos de uso de negocio, agregando al final de
cada documento, los diagramas de clases y actividades correspondientes.
2.4.2. Artefactos del Modelo de Análisis de Negocio
Un trabajador del negocio es un rol interno al negocio.

Colabora con trabajadores de otro sector, es notificado
de acontecimientos del negocio y manipula entidades
de negocio para realizar sus responsabilidades.
Trabajador de Negocio
Ente significativo y persistente manipulado por actores

del negocio y trabajadores del negocio.
Entidad de Negocio
Colección de diagramas que muestra cómo los
trabajadores del negocio y entidades del negocio llevan
a cabo el caso de uso del negocio.
Generalmente se utilizan Diagramas de Clases,
Diagramas de Actividades y Diagramas de
Realización de Casos de
Colaboración para realizar el detalle de cada proceso
Uso de Negocio
de negocio.
Representa la vista interna del negocio.
Es un modelo que describe la realización de los casos
de uso del negocio. Es una abstracción de cómo los
trabajadores del negocio y las entidades de negocio se
Modelo de Análisis de
Negocio
relacionan y de cómo colaboran para realizar los casos

del uso del negocio.
Documento que contiene información de los

trabajadores del negocio identificados en el modelo de
análisis del negocio.
Trabajadores de Negocio
Documento que contiene información de las entidades

del negocio identificadas en el modelo de análisis del
negocio.
Entidades de Negocio
Tabla 3: Artefactos del Modelo de Análisis de Negocio

2.5. TEMA 7: CASO PROPUESTO MCUN Y MAN
CASO: CHASQUI EXPRESS S.A.

Continuaremos con el desarrollo del Modelo de Análisis de Negocio del Caso Chasqui
Express visto anteriormente (pág. 54).
Para el caso en mención realizaremos lo siguiente:

 Elaborar la estructura del MAN del Proyecto en una Herramienta CASE.
 Identificar los Trabajadores de Negocio
 Identificar las Entidades de Negocio
 Identificar las Realizaciones de Negocio
 Elaborar el Diagrama de Estados.
 Elaborar el Diagrama de Actividades de Negocio
 Elaborar el Diagrama de Clases de Negocio

2.5.1. SOLUCIÓN EN RATIONAL SOFTWARE ARCHITECT :

2.5.1.1. Estructura del proyecto: Modelo de Análisis de Negocio
Figura 45: Estructura del Modelo de Análisis de Negocio en RSA
2.5.1.2. Trabajadores de Negocio
Figura 46: Casos de Uso de Negocio en RSA
2.5.1.3. Entidades de Negocio
Figura 47: Actores de Negocio en RSA

2.5.1.4. Realizaciones de Negocio
Figura 48: Realizaciones de Negocio en RSA
2.5.1.5. Diagrama de Estados
Figura 49: Diagrama de Estados de un CDP en RSA

2.5.1.6. Diagrama de Actividades
Figura 50: Diagrama de Atividades en RSA

CASO: CALIDAD EDUCATIVA
La jefa de calidad educativa (JCE) ha solicitado los servicios al área de sistemas para
que sistematice el proceso de encuestas. Para llevar a cabo esta sistematización el
analista realiza el levantamiento de información entrevistando a las personas que
trabajan dentro de este proceso. A continuación un resumen de cómo trabaja esta
área:
El coordinador de sede (CS) solicita a la JCE la elaboración de encuestas a docentes.
JCE elabora las preguntas y comunica a su asistente para que cree el formato de
encuesta y registre las preguntas con sus respectivas opciones. Una vez finalizada la
elaboración, la asistente le entrega el formato terminado a la JCE para su visto bueno.
Una vez aceptado el formato la JCE ordena a su asistente que se acerque a las aulas
para que entregue las encuestas a los alumnos donde procederán a llenarla y
entregarla a la asistente para que calcule el puntaje de cada docente. Obtenido el
puntaje, la asistente informa sobre la evaluación de cada docente a la JCE, con esta
información la JCE genera un informe, el cual será entregado al (CS) quien entrega el
informe a los profesores al final del ciclo.
2.5.2. SOLUCIÓN EN RATIONAL SOFTWARE ARCHITECT

2.5.2.1. Modelo de Análisis de Negocio
Figura 51: Estructura del Modelo de Análisis de Negocio en RSA

Figura 52: Trabajadores de Negocio en RSA
Figura 53: Entidades de Negocio en RSA
Figura 54: Realización de Negocio en RSA

2.5.2.5. Diagrama de estados
Figura 55: Diagrama de estados de una encuesta
2.5.2.6. Diagrama de Clases de Negocio
Figura 56: Diagrama de Clases de Negocio en RSA

2.5.2.7. Diagrama de Actividades de Negocio
Figura 57: Diagrama de Actividades de Negocio en RSA

2.5.3. SOLUCIÓN EN ENTERPRISE ARCHITECT - SPARX :

2.5.3.1. Modelo de Análisis de Negocio
Figura 58: Estructura del Modelo de Análisis en EA

uc TN
Asistente JCE
Figura 59: Trabajadores de Negocio en EA

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

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

OTROS CASOS PROPUESTOS

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

La imprenta “Laser Data”, es una empresa dedicada a la confección de tarjetas y tiene
como objetivos satisfacer en un 100% todos los requerimientos de partes
matrimoniales, quince años, cumpleaños, bautizo, primera comunión, etc.
“Laser Data”, le presta mucha atención a los detalles que las personas buscan,
ofreciendo así productos de calidad, acompañado del mejor servicio de atención del
pedido y a buenos precios. “Laser Data”, cuenta con una gran variedad de partes,
recuerdos y accesorios para todo tipo de ocasión.
Como parte de la estrategia de marketing, “Laser Data” cuenta con socios de negocio
para cada ocasión, por ejemplo, en los matrimonios, tiene convenios con empresas
que organizan las bodas, revistas para novios, tiendas de regalos, agencias de viajes,
etc. Así, cuando una pareja desea casarse y va a uno de los socios de negocio,
también llega a contactarse con “Laser Data” por las buenas recomendaciones.
Al contactarse el cliente o el socio con la empresa, este le envía las especificaciones

de la tarjeta y cantidad al responsable de pedidos(RP) que toma el pedido, quien lo
envía al ejecutivo de cuenta (EC) quien recibe y entrega al diseñador gráfico (DG) el
cual genera la versión de la tarjeta de acuerdo a los requerimientos; devolviendo luego
al EC para que verifique el resultado en consulta con el cliente quien da la autorización
de impresión, por lo que el EC enviara la muestra al equipo de prensa (EP) para que
proceda a imprimir el material solicitado.
El responsable del área de diseño se encarga de tener las últimas tendencias en los
modelos para las tarjetas o partes, teniendo siempre el catálogo de tarjetas
actualizado y dejando para la personalización que el cliente finalmente pueda hacer
sobre la tarjeta.

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

actividades de acuerdo al detalle siguiente:
El jefe de ventas entrega las órdenes de pedidos al jefe de producción quien las recibe
y prepara la orden de producción, el jefe de producción proporciona la orden de
producción al operador para que genere su requerimiento de materia prima e insumo
en base a la orden de producción, dicho requerimiento es entregado al almacenero de
productos en proceso, que se encarga del retiro de las materias primas e insumos,
procede a pesar los ingredientes necesarios para producir la torta, luego entrega los
ingredientes al operador, donde verifica la conformidad de la recepción firma la
atención al requerimiento, en caso contrario no firma documento alguno y solicita que
se complete la atención a su requerimiento. Una vez obtenido los materiales e
insumos el operador inicia su trabajo agregando los ingredientes a la máquina de
batido, haciendo funcionar la máquina, y monitorea el proceso, al término traslada la
mezcla a la máquina dosificadora, activándola y verificando que no se presenten
problemas en el preparado. Finalmente, el operador organiza las tortas preparadas en
las cajas, generando un reporte de producción, entregando los productos y el reporte
al almacenero de productos terminados quien los recepciona dando su conformidad a
la producción.

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

Entidades de Negocio, y Realizaciones de Negocio.
3. Los trabajadores de negocio deben cumplir roles internos al negocio y son quienes
manipulan las entidades de negocio.
4. Las Realizaciones de Negocio está conformado por una colección de diagramas

que dan mayor detalle de las actividades que realizan los trabajadores de negocio
sobre las entidades de negocio.
5. Si desea saber más acerca de estos temas, puede consultar las siguientes
páginas:
 https://www.youtube.com/watch?v=X30Bt1bRsCI
 https://www.youtube.com/watch?v=jXYWTpqjJ6Y

UNIDAD
3
DISCIPLINA DE LA CAPTURA DE
REQUISITOS
Al término de la unidad, el alumno sustenta el proyecto realizado durante el curso
relacionado a la elaboración de la documentación del Modelado de Negocio, Captura
de Requisitos, Modelo de Casos de Uso y Prototipos (GUIs) de un caso de estudio
utilizando una Herramienta CASE. Además, el alumno es capaz de elaborar prototipos
utilizando herramientas de prototipado (GUIs).
TEMARIO
3.1 Tema 8 :
Captura de Requisitos
3.1.1 :
Importancia de la captura de requisitos
3.1.2 :
Dificultades de la captura de requisitos
3.1.3 :
Artefactos de la captura de requisitos
3.1.4 :
Actividades para realizar la Captura de Requisitos
3.1.5 :
Requisitos
3.1.6 :
Requisitos FURPS+
3.1.7 :
Técnicas para capturar requisitos
3.1.8 :
Captura de requisitos a solicitud del cliente
3.1.9 :
Captura de actividades a partir del Diagrama de Actividades de
Negocio.
Caso : El Pirata
3.2 Tema 9 : Modelo de Casos de Uso

3.2.1 : Identificación de Actores
3.2.2 : Identificación de Casos de Uso
3.2.3 : Matriz de Actividades vs Requerimientos
Caso : El Pirata
3.3 Tema 10 : Estructurando el Modelo de Casos de Uso

3.3.1 : Objetivos
3.3.2 : Tipos de relaciones
3.3.3 : Casos de Uso Abstractos y Concretos
3.3.4 : Especificación de Casos de Uso (ECU)
3.3.5 : Priorización de Casos de Uso
Caso Resuelto: Siri Tours
Caso Propuesto: Restauramte El Toyito

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


3.1. TEMA 8: CAPTURA DE REQUISITOS

La Ingeniería de Requisitos se ocupa de la recolección, análisis, especificación y
validación de los requerimientos de software.
[SWEBOK: 2004]
La Ingeniería de Requisitos abarca las actividades de descubrir, documentar y

mantener una serie de requerimientos para un sistema y el uso del término “ingeniería”
implica que se debe usar una serie de técnicas sistemáticas, repetibles para asegurar
que los requerimientos sean completos, consistentes y relevantes.
[Sommerville: 1997]
La ingeniería de requisitos consiste en descrubrir cuáles son las metas, necesidades y

expectativas de los interesados, afinar esas expectativas y comunicarla a los
desarrolladores. Las actividades del proceso de captura de requisitos incluyen la
extracción de requerimientos, el análisis, la especificación y validación.
El esfuerzo principal en esta disciplina es desarrollar un modelo del sistema que se

desea construir.
No existe un proceso único de captura de requisitos que sea válido en todas las
organizaciones, ya que cada organización debe desarrollar su proceso de acuerdo al
tipo de producto software que se esté desarrollando, la cultura organizacional y el nivel
de habilidad y experiencia de los integrantes del equipo de trabajo involucradas en la
captura de requisitos.
3.1.1. Importancia de la Captura de Requisitos

La importancia de la captura de requisitos, radica en lo siguiente:
 Permite estimar costos, tiempos y recursos.
 Disminuye los costos y retrasos del proyecto.
 Mejora la comunicación entre clientes y desarrolladores.
 Evita rechazos de usuarios finales.
3.1.2. Dificultades de la captura de Requisitos

Dentro de las principales dificultades que se pueden presentar podemos mencionar:
 Dejar de lado a ciertos usuarios durante la captura de requisitos.
 Falta de participación del usuario.
 Factores políticos.
 Los requisitos:
o Pueden estar incompletos y no son obvios.
o Vienen de muchas fuentes
o Muchos tipos de requisitos y muchos niveles de detalle.
o Pueden variar con el templo.
Durante el proceso de captura de requisitos es bueno tener en cuenta:

 Objetivos de negocio y ambiente de trabajo.
 Diferentes puntos de vista de los clientes.
 Bareras de comunicación entre clientes y analistas de requerimientos.
 Integración del sistema con otros ya existentes.
 Tamaño de la documentación.

La utilización de los casos de uso complementa el proceso de captura de requisitos,

pues permite materializar cada requerimiento en una funcionalidad del sistema
(requerimeintos funcionales).
El modelo de casos de uso es construido a través de un proceso iterativo durante el

cual las discusiones entre los desarrolladores del sistema y los clientes (y/o usuarios
finales) llevan a una especificación de requisitos en la que todos estén de acuerdo.
Así, los propósitos de la Captura de Requisitos son:
 Establecer y mantener los acuerdos con los clientes y otros interesados

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

El conjunto completo de artefactos de la captura de requisitos, mostrado en la figura
3.1, sirven como entrada y referencia para el análisis, diseño, implementación y
pruebas del sistema.
Figura 62: 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.
Documento que define la opinión de los stakeholders
del producto que se desarrollará, especificada en
términos de necesidades y características claves de
los stakeholders. Contiene un esquema de los
requisitos previstos, el cual proporciona la base
Visión
contractual para los requisitos técnicos más
detallados.

La Especificación de Requisitos de Software es un
documento que enfoca la organización completa de
los requisitos del proyecto.
Comúnmente conocido como SRS por sus iniciales en
Especificación de
inglés. Contiene la lista de requerimientos funcionales
Requisitos de Software
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 dividiéndolo en piezas más pequeñas.
Paquete de Caso de Uso
Es un proceso específico del sistema con identidad

propia, el cual define una secuencia de acciones que
uc Actors
el sistema realiza para un actor en particular.
Caso de Uso
Representa un rol (humano, hardware o software)

externo al sistema con el que se establece intercambio
directo de información.
Puede ser asociado a uno o más casos de uso.
Bibliotecario
Actor
Es un modelo que captura los requisitos funcionales

de los usuarios a un alto nivel y establece la estructura
fundamental del sistema. Es un input esencial para las
actividades en análisis, diseño y pruebas.
Modelo de Casos de Uso
Reporte que contiene información de los actores

identificados en el modelo de casos de uso.
Actores
Documento que contiene las características de un
caso de uso. Contiene primordialmente una
descripción del flujo de eventos que describen la
interacción entre los actores y el sistema. La
especificación también contiene otra información tal
Especificación de
como precondiciones, pos condiciones y requisitos
Casos de Uso
especiales. Se realiza una especificación por caso de
uso.
Tabla 4: Artefactos de la Captura de Requisitos
3.1.4. Actividades para realizar la Captura de Requisitos

Según RUP, la Captura de Requisitos comprende las siguientes actividades:
1. Analizar el problema
2. Entender las necesidades de stakeholders
3. Definir el sistema
4. Administrar el alcance del sistema
5. Refinar la definición del sistema
6. Administrar cambios de requisitos

Figura 63: Proceso de la captura de requisitos
3.1.4.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.
3.1.4.2. Entender las necesidades del Stakeholder
El artefacto principal es el documento Visión refinado. También los requisitos son

discutidos y expresados en términos de Casos de Uso y Actores. Los requisitos no
funcionales, que no son representados en el Modelo de Casos de Uso deberán ser
documentados en Especificaciones Suplementarias.
El analista se relaciona con los stakeholders utilizando técnicas para capturar

requisitos, tales como las entrevistas y prototipos. Por tanto, los stakeholder son
fuentes de requisitos.
Los stakeholders son un grupo de interés cuyas necesidades deben ser satisfechas
por el proyecto. El papel puede ser desempeñado por cualquier persona que es o será
potencialmente afectado por los resultados del proyecto. Por ejemplo: usuarios finales

del sistema, gerentes, accionistas, reguladores quiénes certifican la aceptabilidad del

sistema.
3.1.4.3. Definir el Sistema
Esta actividad se enfoca en identificar a los actores y los casos de uso completamente
para obtener un Modelo de Casos de Uso refinado y expandir los requisitos no
funcionales definidos en el documento de Especificaciones Suplementarias.
3.1.4.4. Administrar el Alcance del Sistema
El alcance del proyecto es definido por el conjunto de requisitos definidos para este. La
clave para manejar un proyecto exitoso es administrar el alcance del proyecto
cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. La
priorización los casos de uso, desarrollado por el arquitecto de software, permite
planificar el proyecto.
3.1.4.5. Refinar la Definción del Alcance
El output de este Workflow del RUP es una comprensión más profunda de la

funcionalidad del sistema expresada en Casos de Uso detallados y documentos de
Especificaciones Suplementarias detallados. Si es necesario, una Especificación de
Requisitos de Software formal puede ser desarrollada, además de los documentos
detallados de Casos de Uso y Especificaciones Suplementarias.
3.1.4.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.5. Requisitos
Un requisito o requerimiento se puede definir como una especificación de lo que el

sistema debe hacer y las restricciones a tener en cuenta.
Según RUP, el requerimiento de software es una especificación de una condición o

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

problema y pueda alcanzar un objetivo.
 Una posibilidad que el software debe cumplir para satisfacer un contrato,
estándar, especificación u otra documentación formalmente impuesta.

3.1.5.1. Tipos de requisitos
Existen dos tipos de requisitos: requisitos funcionales y requisitos no funcionales.
REQUERIMIENTOS
FUNCIONALES NO FUNCIONALES
Figura 64: Tipos de Requerimientos
3.1.5.1.1. Requerimientos Funcionales
Es una declaración de lo que debe hacer el sistema, es la declaración de la función

del sistema. Las características principales de los requerimientos funcionales son las
siguientes:
 Especifican las condiciones que debe ser cumplidas por el sistema.
 Se identifican desde el punto de vista del cliente.
 Se redactan en lenguaje natural.
Ejemplos:
 El sistema debe permitir registrar la información de libros de una biblioteca.
 El sistema debe permitir registrar la información de profesores que dictan los
cursos de baile.
 El sistema debe permitir registrar los horarios de dictado de clase.
 El sistema debe permitir registrar la matricula de alumnos.
 El sistema debe obligar al usuario a cambiar su contraseña cada 60 días.
Los requerimientos funcionales se mencionan inicialmente en la lista de características

del sistema del documento Visión. Cuando se tiene un mayor conocimiento de los
requerimientos funcionales se detallan en el documento SRS (Requerimienos de
Sistema) y pueden en ocasiones establecerse más claramente usando prototipos.
3.1.5.1.2. Requerimientos 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, escalabilidad y otras
características que el sistema debe tener para poder asegurar la calidad del mismo.
Ejemplos:
 El sistema de administración de bibliotecas debe ser escrito en C++.
 El sistema de cajero automático debe validar la tarjeta en menos de 4
segundos.

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

usados: Chrome, Firefox, Internet Explorer y Safari.
Los requerimientos no funcionales se detallan en el documento SRS y/o en el

documento Especificación Suplementaria.
Figura 65: Tipos de Requerimientos No Funcionales
3.1.6. Requisitos FURPS+

Este es un tipo de clasificación de requisitos especificado en la documentación de
RUP. Se utiliza el acrónimo FURPS (por las siglas en inglés) para describir las
principales categorías de requisitos:
 Funcionalidad (Functionality)
 Facilidad de Uso (Usability)
 Confiabilidad (Reliability)
 Rendimiento (Performance)
 Soporte (Supportability)
El símbolo "+" en FURPS+ hace referencia a que se deben incluir otros requisitos,
tales como:
 Restricciones de diseño
 Requisitos de implementación
 Requisitos de interfaz
 Requisitos físicos
3.1.6.1. Funcionales
Los requerimentos funcionales deben incluir:
 Conjunto de características
 Capacidades
 Seguridad
Por ejemplo, para un Sistema de Ventas:

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

 R2: El sistema debe permitir registrar venta de productos.
 R3: El sistema debe permitir reducir stock cuando se realiza la venta.
 R4: El sistema debe permitir identificar al cajero utilizando un usuario y una
clave.
3.1.6.2. Facilidad de Uso

Los requerimentos relacionados a la facilidad de uso deben incluir subcategorías tales
como:
 Factores Humanos
 Estéticos
 Consistencia de Interfaz de Usuario
 Ayuda en línea o “context-sensitive”
 Asistentes (“wizards”)
 Documentación de Usuario
 Materiales de Capacitación/Entrenamiento
Por ejemplo:
 R1: El sistema deberá proporcionar ayudas en línea para orientar al usuario en

el uso de sus interfaces.
 R2: Maximizar eficiencia mediante la navegación con teclado.
 R3: El sistema debe tener interfaces gráficas de administración y de operación
en idioma español y en ambiente 100% Web, para permitir su utilización a
través de navegadores de Internet
3.1.6.3. Confiabilidad
Dentro de los requerimientos relacionados a la confiabilidad podemos mencionar:
 Frecuencia de fallos
 Capacidad de recuperación a fallos
 Posibilidades de predicción del programa
 Precisión
 Tiempo medio de fallos
Por ejemplo:
 R1: El sistema debe registrar los pagos a crédito autorizados que se hagan a
las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan
fallas de energía o del equipo.
 R2: La cuenta del usuario se bloqueará por un lapso de 30 minutos luego de 4
intentos fallidos para evitar vulnerabilidades en la seguridad del sistema.
3.1.6.4. Rendimiento
Los requerimientos de rendimiento están relacionados a las condiciones impuestas a
requisitos funcionales y son tales como:
 Velocidad
 Eficiencia
 Disponibilidad

 Tiempo de Respuesta
 Tiempo de Recuperación
 Uso de recursos
Por ejemplo:
 R1: El tiempo máximo para mostrar el reporte de cuentas por cobrar mediante
un histograma es de 10 segundos.
 R2: El sistema debe estar disponible al 100% o muy cercano a esta
disponibilidad durante el horario hábil laboral de la empresa a nivel nacional, es
decir, de lunes a viernes de 8:00 a.m. a 06:15 p.m., con excepción de los días
festivos.
3.1.6.5. Soporte
Los requerimientos de soporte están relacionados en la capacidad que tiene el
software de ser modificado fácilmente para adecuar mejoras o cambios e incluyen:
 Adaptabilidad
 Facilidad de mantenimiento
 Compatibilidad
 Configurabilidad
 Facilidad de instalación
 Internacionalización
Por ejemplo:
 R1: El sistema debe operar de manera independiente del navegador que se

utilice (Microsoft Internet Explorer 6.0 o superior, Netscape 6.0 o superior,
Mozilla FireFox).
 R2: El sistema deberá estar orientado a que las actualizaciones sólo se hagan
en el sitio del servidor.
3.1.6.6. Restricciones de diseño

Los requerimientos de diseño son también llamados restricciones de diseño, pues
especifican o restringen el diseño de un sistema.
Por ejemplo:
 R1: El sistema deberá considerar en su arquitectura un modelo tres capas, donde

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

Los requerimientos de implementación especifican restricciones de codificación o de
construcción del sistema:
 Estándares requeridos
 Lenguajes de implementación
 Políticas para la integridad de Bases de Datos
 Límite de recursos
 Ambientes de Operación

Por ejemplo:
 R1: El sistema debe desarrollarse en ASP.NET C# con framework 4.5.

 R2: La SGBD utilizado por el sistema será MySQL.
 R3: El sistema debe ser pulblicado en un servidor IIS 7.5.
3.1.6.8. Requisitos de Interfaz

Los requerimientos de interfaz especifican:
 Elementos externos con el que el sistema debe interactuar.
 Restricciones o formatos, tiempos u otros factores usados en tales
interacciones.
Por ejemplo:
 R1: El sistema deberá proporcionar, para los diferentes reportes solicitados,

salidas en documentos electrónicos (Word, Excel y PDF Acrobat).
 R2: En una visión preliminar de impresión se consideraría que todos los textos
estarán relacionados con un visor de PDF, las estadísticas y resultados de
consultas estarán relacionados con Excel 2007 o superior.
3.1.6.9. Requisitos Físicos

Los requisitos físicos especifican características físicas con las que el sistema debe
contar (material, forma, tamaño y peso). Pueden especificarse los requisitos de
hardware.
Por ejemplo:
 R1: Para que un cliente de la aplicación pueda ejecutar procesos, en línea,
considerados en el sistema, la estación de trabajo del usuario deberá cumplir
con los siguientes requisitos mínimos.
Requisitos Físicos
 Procesador 1.0 GHz.
 Memoria 128 MB.
 Disco duro 10 GB.
 Sistema Operativo Windows XP o Linux.
 Navegador internet Explorer 6.0 o
posterior, Mozilla Firefox 2.X, Netscape
Navigator 6.X o posterior con plugins para
Macromedia Flash y Java.
 Conexión a Internet. mínimo 56Kbps
3.1.7. Técnicas para capturar requisitos

Las técnicas de recolección de información de la ingeniería de requisitos surgen como
medio para mejorar la comunicación entre usuarios o clientes y el equipo de trabajo
que desarrolla el software. Esta técnica es importante por dos razones:
1. En ocasiones los desarrolladores no conocen todos los detalles del trabajo de

la organización para la cual están desarrollando el sistema.
2. Los usuarios no saben que información es necesaria y relevante para el
desarrollo de un sistema.

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

las etapas que estas normalmente son aplicadas:
Técnicas Extracción Análisis Especificación Validación

Entrevistas y/o cuestionarios X
Sistemas existentes X X
BrainStorming X X
Observación X
Prototipo Bosquejado X X X
Prototipo Tangible / Usable X X X
FODA X
Cadena de Valor X
Modelo de Clase Conceptual X X
Diagrama de Pescado X X X
Glosario X X X X
Casos de Uso X X X X
CheckList X X
Tabla 5: Herramientas para la captura de requisitos.
3.1.7.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.
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. Para la realización de las entrevistas,
se debe coordinar previamente la fecha y hora de la misma, así como elaborar un plan
de agenda. 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:
o Pregunta abierta: “¿Quién utiliza el sistema?”

o 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. Esta es la única forma de
averiguar lo que realmente necesita.
 Escuche: Esta 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: Esta 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.7.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
Ejemplo:
¿Cree que se cometen muchos errores en la codificación de los números de
cuenta en las facturas?
 DE ACUERDO / EN DESACUERDO
¿Se cometen muchos errores al codificar os números de cuenta en las

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

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

 RANGO
 SELECCIÓN DE RESPUESTAS LIMITADAS

Cuando se presentan errores en la codificación de los números de cuenta en
las facturas, ¿cuál es la causa más frecuente? (Anote el número de la
respuesta apropiada. También la segunda razón más común y la menos
común).
1…
2…
Los buenos cuestionarios se deben diseñar previamente. Un

pensamiento cuidadoso, acompañado de una prueba previa, tanto del
formato como de las preguntas, son la base de una recopilación de
datos significativa a través de cuestionarios.
Pautas que le ayudarán a confeccionar un buen cuestionario:
1. Determine qué datos necesitan recopilarse y qué personas son las más
calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos
variantes y mayor visión identifíquelos también.
2. Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cuáles

pueden ser más útiles, si contienen una sección de respuestas cerradas y otras
de respuestas abiertas.
3. Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las

preguntas extras que son intencionalmente redundantes, pueden ser útiles al
asegurar respuestas consistentes por parte de quien responda.
4. Examine el cuestionario para encontrarle fallas y defectos como:
a. Interrogantes innecesarias.
b. Preguntas que puedan ser mal interpretadas debido a su enfoque o
forma de escritura.
c. Preguntas que el sujeto no pueda responder.
d. Preguntas que están escritas de forma que se escogerá la respuesta
preferida.
e. Preguntas que se interpretaran en forma diferente dependiendo del
marco de referencia de cada entrevistado.
f. Preguntas que no proporcionan opciones adecuadas de respuesta.
g. Un ordenamiento no adecuado de las preguntas y respuestas.
5. Pruébelo previamente en un Grupo pequeño para detectar otros problemas

posibles.

6. Analice la respuesta del Grupo de prueba para asegurar que el análisis de los
datos que se busca se puede llevar a cabo con los datos recopilados. Si los
datos no revelan algo que el analista no conoce, el cuestionario puede no ser
necesario.
7. Realice cambios finales de edición e imprímalo en una forma legible.
8. Distribuya el cuestionario. Cuando sea posible anote el nombre de cada

persona.
3.1.7.3. Lluvia de Ideas

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la
de generar la máxima cantidad posible de requisitos para el sistema. No hay que
detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio
es generar, en una primera instancia, muchas ideas.
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.7.4. Prototipos
Los prototipos son simulaciones o “maquetas” del posible producto software, que
permite a los usuarios, evaluar mejor sus necesidades, analizando si el prototipo se
ajusta a las características del sistema que necesitan.
Los prototipos pueden ser clasificados en dos grandes grupos:
Tipo Descripción
 Consiste en bosquejar la interfaz de usuario con
programas sencillos de dibujo (herramientas Mockup) o
incluir modelos de pantalla en papel.
 Una de las ventajas más importantes es el poco esfuerzo
que se necesita para aplicar cambios.
Prototipo  Una de las desventajas es que el usuario puede no
Bosquejado apreciar la interacción hombre-máquina, sobre todo para
reflejar requerimientos no funcionales como la
usabilidad.Sin embargo, hoy en día está desventaja
puede ser mitigadas a través del uso de Story-boards o el
uso de herramientas Mockup que permiten interacción.

Tipo Descripción
 Los términos tangible y usable se refieren a desarrollar un
sistema (software) que el usuario pueda utilizar, es decir,
con la cual pueda interactuar como si éste fuese el
Prototipo
sistema final.
Tamgible /
usable  Cualquier que sea la herramienta softwate que se utilice
para desarrollar el prototipo, debe consumir poco esfuerzo
y tiempo en la realización de cambios.
Tabla 6: Tipos de Prototipos
3.1.8. Captura de requisitos a solicitud del cliente

Si el equipo de desarrollo tiene un conocimiento de la estructura de la organización, de
las metas, de la visión y de los clientes/usuarios o si sOlo se está añadiendo una
nueva característica a un sistema existente, entonces RUP no recomienda que se
empiece con un Modelado del negocio. En ese caso, RUP recomienda que se
empiece con la Captura de requisitos.
Esta actividad consiste en identificar todas las necesidades de stakeholders. Como se

explicó anteriormente, el término Stakeholder se utiliza para referirse a cualquier
persona o grupo que está interesado por los resultados del proyecto.
Figura 66: 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
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 59 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.9. Captura de Actividades a partir del Diagrama de Actividades

de 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 67: Del Modelo de Negocio al Modelo de Casos de Uso
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 7.
Matriz de Actividades vs Requisitos Funcionales del Sistema <Nombre_de_Sistema>
Proceso de Actividades Responsable Caso de

Requisito Actores Prioridad
Negocio de Negocio de Negocio Uso
R01
R02
R03
Tabla 7: Plantilla de Matriz de Actividades vs Requisitos Funcionales
Una Matriz de Actividades y Requisitos es una herramienta manual utilizada para

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

CASO PROPUESTO: Matriz de Actividades vs Requisitos Funcionales
CASO: EL PIRATA
La cadena de videoclub “El Pirata SA” tiene un gran éxito en el mercado, pero están
teniendo algunos problemas con el grado de satisfacción de sus clientes. Por tal
motivo, se desea agilizar la atención al cliente en 30% con respecto al año 2011.
Un alquiler (CUN1) puede implicar más de una película, pero una única fecha de
devolución. Por cada alquiler se debe registrar el socio, las películas, fecha de alquiler,
fecha de devolución y se calcula de forma automática la tarifa a pagar de acuerdo a
los días de alquiler y si el pago es al crédito el encargado de finanzas efectuará la
correspondiente verificación de las condiciones crediticias del socio en el sistema
INFOCORP, el sistema INFOCORP muestra el estado crediticio del socio, el
encargado de finanzas envía la respuesta a la Recepcionista.
Cuando un socio devuelve (CUN2) una película con retraso, deberá pagar un recargo
que tiene que abonar antes de alquilar otra película. La política de sanciones (cantidad
a abonar) es definida por el Gerente de la Cadena. Un socio no podrá alquilar una
película si tiene pendiente el pago de sanciones. También el socio debe pagar una
multa si pierde o daña la cinta de vídeo.
Los socios pueden hacer reservas de película (CUN3), estén o no alquiladas. Si la

película está alquilada, el socio pasa a una cola de espera para esa película, si no está
alquilada, el encargado la retira de los estantes hasta que el socio pase a recogerla.
Cuando se devuelve la película hay que comprobar si hay reservas para avisar al
socio por teléfono o e-mail. Esta comunicación la realiza el responsable del local, para
lo cual consulta en el sistema el teléfono y el e-mail; y cuando recibe la confirmación
del socio de que se enteró de la disponibilidad de la película solicitada, lo registra en el
sistema.
El socio dispone de dos días para pasar a recogerla, si no lo hace automáticamente le
impondrá un recargo y se anula la reservación. El responsable del local tiene que
actualizar el sistema cuando un socio se lleva la película. Un socio puede cancelar la
reserva, lo que no supone cargo alguno.
Además de las películas, el videoclub también alquila videojuegos (CUN4). Cada

videojuego se caracteriza por el título, temática, argumento y la plataforma sobre la
que puede ejecutarse (playstation, nintendo, PC). Los videojuegos tienen su código de
barras y puede haber varios copias de cada uno. El Gerente de compras también es el
encargado de actualizar esta información.
Alquiler de Películas
Nombre Alquiler de péliculas

 Incrementar el número de reservas en un 15%
Objetivo
 Agilizar el tiempo de respuesta de aceptación en un 5%
Flujo de Trabajo
1. El socio solicita alquiler de películas.

2. Si el socio no tiene reserva la Recepcionista verifica la
Flujo Básico disponibilidad de la película.
3. Si la película está disponible, la recepcionista informa al
cliente sobre tarifas y reglas del alquiler.
4. Si el socio está de acuerdo con lo ofrecido, la Recepcionista

solicita identificación del socio.

5. La Recepcionista genera ticket de alquiler.
6. El socio va a cancelar a la cajera.
7. La Cajera pregunta forma de pago al socio.
8. Si el pago es a crédito, la Cajera entrega los datos al
encargado de finanzas para su respectiva verificación.
9. El encargado de finanzas efectuará la correspondiente
verificación de las condiciones crediticias del socio en el
sistema INFOCORP.
10. El sistema INFOCORP muestra el estado crediticio del socio.
11. El encargado de finanzas envía la respuesta a la Cajera.
12. Si la respuesta confirma la aprobación del crédito entonces
la Cajera genera el documento de crédito.
1. En el paso 2: Si el socio tiene reserva, la Recepcionista:

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

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

Por tanto nuestra matriz va quedando de la siguiente manera:
Matriz de Actividades vs Requisitos Funcionales del Sistema “El Pirata”
Proceso de Actividades de Responsable de Requisito

Caso de Uso Actores Prioridad
Negocio Negocio Negocio (El sistema debe permitir …
Solicita alquiler de Registrar el alquiler de CUS 01-Registrar

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

crediticias evaluación creditica
Envía respuesta
Responsable de
de evaluación
Finanzas
crediticia
Comunica al socio Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
pago en efectivo alquiler Pago
Genera
Registrar documento de CUS 08-Registrar
documento de Cajero R11 Cajero 6
crédito crédito
crédito
Cancela pago al Registrar el alquiler de
Socio R01 Registrar alquiler Recepcionista 7
contado una película
Gestión de
… …
devolución
Gestión de
… …
reserva
Actualización de
… …
stock
La elaboración del Diagrama de Actividades de Negocio facilita la elaboración de la Matriz de Actividades vs. Requerimentos
Funcionales.

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.

3.2. Tema 9: Modelo de Casos de Uso

El modelo de casos de uso es una forma de Ingeniería de requisitos. Este artefacto es
un modelo de las funciones deseadas para el sistema y su entorno, y sirve como
contrato para el cliente y los desarrolladores. Se utiliza como entrada esencial para las
actividades de análisis, diseño y pruebas.
El modelo de casos de uso permite:
 Que los clientes y usuarios validen que el sistema se convierta en lo que

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

 Dirigen todo el proceso de desarrollo, puesto que la mayoría de actividades se
realizan a partir de los casos de uso (planificación, análisis, diseño, validación,
test).
 Son usados para comunicarse con el usuario final y el experto del dominio.
 Son un mecanismo importante para soportar la “trazabilidad” entre modelos.
 Base para el análisis, diseño, casos de prueba, glosario de términos y la guía
del usuario.
 Provee entradas para el planeamiento de proyectos
 Son usados para identificar:
o Quién interactuará con el sistema y qué deberá hacer el sistema.
o Qué interfaz deberá tener el sistema.
 Son usuados para verificar
o Que se capturen todos los requerimientos.
o Que los desarrolladores hayan entendido los requerimientos.
El modelo de casos de uso es empleado no solamente para capturar requisitos de

nuevos sistemas; pues también es utilizado cuando se desea desarrollar nuevas
generaciones de sistemas. Cuando una nueva versión de un sistema es desarrollada,
las nuevas funcionalidades son agregadas al modelo de casos de uso existente,
insertando nuevos actores y casos de uso y modificando las especificaciones de los
actuales casos de uso. El modelo de casos de uso se construye mediante los
siguientes pasos:
1. Encontrar actores y casos de uso

2. Priorizar casos de uso
3. Detallar un caso de uso
4. Crear prototipo de interfaz de usuario
5. Estructurar el modelo de caso de uso
Los elementos de un modelo de caso de uso son:

ANÁLISIS Y DISEÑO DE SISTEMAS (1834) 103
 Actores.
 Casos de Uso
 Asociaciones
3.2.1. Identificación de Actores

Este es uno de los primeros pasos para definir qué o quiénes interactuarán con el
sistema. Antes de indicar cómo se identifican los actores empezaremos por definirlo.
3.2.1.1. Actor
Un actor representa un rol que cierta entidad externa (humano, hardware o software)
adopta cuando interactúa con el sistema directamente.
Otras definiciones complementarias:
 Un actor representa entonces un rol, no es un usuario individual del

sistema. Hay una diferencia entre actor y usuario. Usuario es el que utiliza el
sistema, mientras que el actor representa un cierto rol que uno o más usuarios
pueden desempeñar. Es decir, los actores definen los roles que pueden
representar los usuarios.
 Un actor es una agente, puede representar un humano, una máquina u otro

sistema que solicita un servicio al sistema.
A continuación daremos algunos ejemplos para tener claro lo que constituye un actor.
Muchos usuarios pueden desempeñar el mismo rol. Por ejemplo, la figura 61 muestra
a dos usuarios, Ivar y Mark, que cumplen el rol de operador de una máquina de
reciclaje. Cuando ellos usan la máquina de reciclaje cada uno es representado por una
instancia del actor Operador (Técnico encargado de manejar y hacer que funcionen
ciertos aparatos).
Figura 68: Muchos usuarios un solo rol

También se puede encontrar que el mismo usuario puede ser representado por varios
actores, esto es porque la misma persona puede desempeñar roles diferentes. Por
ejemplo, la figura 62 muestra que un usuario desempeña dos roles: Administrador de
Almacén y Obrero de almacén.
Figura 69: Muchos roles un mismo usuario
3.2.1.2. ¿Cómo identificar actores?

Para identificar adecuadamente a los actores se debe verificar lo siguiente:
 No siempre está asociado con el nombre de un cargo en la planilla de la

organización objetivo. De la misma forma, el nombre no debe representar
áreas ni departamentos sino roles de ejecución.
 Cada actor debe estar asociado con, al menos, un caso de uso, sino participa
en ningún proceso debe ser eliminado.
Para identificar actores debe responder las siguientes preguntas:
 ¿Quién está interesado en cierto requisito?

 ¿Qué rol desempeña desde el punto de vista del sistema?
 ¿Qué otros sistemas interactúan con este sistema?
 ¿Quién administrará y soportará el sistema?
Cualquier individuo, grupo o fenómeno que cumpla con una o más de estas categorías
es candidato para ser un actor. La figura 63 muestra el entorno del sistema del cual se
encontrarán categorías de actores.
Figura 70: Entorno del Sistema

3.2.1.3. Definir las fronteras del Sistema

Encontrar a los actores significa también definir las fronteras del sistema, que ayuda a
comprender el propósito y el alcance del sistema. Sólo aquellos que se comunican
directamente con el sistema son actores. Por ejemplo:
En un sistema de reservas de líneas aéreas, ¿quiénes podrían ser actores? Esto

depende del tipo de sistema que se construye. Si está desarrollando el sistema de
reservaciones, para un agente de viajes, el actor será el agente de viaje. El pasajero
no interactúa con el sistema directamente, entonces no será un actor.
Figura 71: Actores de un Sistema de Compra de Pasajes
En cambio, si está desarrollando un sistema de reservaciones, para que los pasajeros

se puedan conectar a través de Internet, el pasajero ahora sí interactuará con el
sistema y se convertirá en actor.
Figura 72: Actores de un sstema de Compra de Pasajes en línea
3.2.1.4. Sugerencias para identificar actores
 Son roles (humanos, software o hardware), no personas con nombres propios.

 No siempre está asociado con el nombre de un cargo en la planilla de la
organización objetivo.
 El nombre no debe representar áreas, departamentos o partes de una
organización sino roles de ejecución.
 Cada actor debe estar asociado con al menos un caso de uso del sistema.
 Si no participa en ningún proceso debe ser eliminado del modelo.
3.2.1.5. Breve descripción de actores
La breve descripción del actor debe incluir información sobre:

 ¿A qué o a quién representa el actor?
 ¿Por qué el actor es necesario?
 ¿Qué intereses tiene el actor en el sistema?

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

Cliente
tienda para obtener a cambio un reembolso.
El operador es el responsable del mantenimiento de la

Operador
máquina de reciclado.
El administrador es responsable de las cuestiones sobre el

Administrador
dinero y el servicio que la tienda ofrece a los clientes.
Tabla 8: Descripción de Actores
3.2.2. Identificación de Casos de Uso

Cuando su primer esbozo de los actores se completa, el siguiente paso es identificar
los casos de uso del sistema. Los primeros casos de uso son muy preliminares, y que
sin duda tiene que cambiar un par de veces hasta que sean estables. Si el sistema de
visión o de los requisitos son deficientes, o si el sistema de análisis es 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
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.2.1. Casos de Uso

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

 Es iniciado por un actor para invocar una funcionalidad del sistema.
 Es un flujo de eventos completos y significativos.
Cada caso de uso debe tener asignado un nombre descriptivo.breve, que es una frase
compuesta por verbo (infinitivo) y complemento.
A medida que se identifiquen casos de uso, también se pueden encontrar algunos

nuevos actores.

Las características de un caso de uso son:
 Siempre es iniciado por un actor. El actor, directa o indirectamente, ordena al

sistema que se ejecute el caso de uso.
 Provee valor para un actor, es decir, un caso de uso debe entregar algún tipo
de valor tangible para el actor.
 Es completo. Un caso de uso no está completo hasta que el valor final se
produzca.
3.2.2.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.
Las respuestas a las siguientes preguntas ayudarán a encontrar casos de uso:
 ¿Cuáles son las tareas de este actor?

 ¿Cuáles son los casos de uso que le darán soporte y mantenimiento al
sistema?
 ¿Ante qué eventos el actor debe reaccionar?
 ¿Qué información debe dar el sistema al actor?
 ¿Cuáles con los casos de uso que soportan los procesos de negocio?
3.2.2.3. Sugerencias para identificar 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.2.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
adelante, con una descripción paso a paso de lo que el sistema necesita hacer cuando
interactúa con sus actores, en la Especificación de Caso de Uso.
Siguiendo con el ejemplo de la máquina de reciclado, los casos de uso Reciclar

artículos y Agregar nuevo tipo de botella pueden describirse de la siguiente manera:
Caso de Uso Descripción
El usuario utiliza esta máquina de reciclado para obtener

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

Caso de Uso Descripción
Nuevos tipos de botellas se pueden agregar a la máquina

iniciando en "modo de aprendizaje” y la inserción de 5
Agregar tipo de
muestra. De esta manera, la máquina puede medir las botellas
botella
y aprender a identificarlos. El administrador especifica el valor
de reembolso para el nuevo tipo de botella
Tabla 9: Descripción de Casos de Uso
3.2.3. 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.
Es conveniente que los casos de uso se dibujen en el orden en que normalmente los
usará el actor. Opcionalmente, los casos de uso mostrados en el diagrama se pueden
encerrar dentro de un rectángulo que representa los límites del sistema.
El primer diagrama de casos de uso es un esbozo de la comunicación que existe entre

un actor y un caso de uso. Más adelante, se diseña una versión final agregando
asociaciones entre los casos de uso.
La siguiente figura muestra un esbozo del diagrama de casos de uso de una máquina
de reciclado. El rectángulo contiene los casos de uso que constituyen el
comportamiento del sistema.
Figura 73: Diagrama de Casos de Uso
El propósito primario del modelo de casos de uso es comunicar las

funciones y el comportamiento del sistema al cliente o usuario final.

Caso: El Pirata
Ahora, vamos a identificar las funcionalidades del nuevo software.
En primer lugar, del Diagrama de Actividades se obtiene las siguientes actividades a

sistematizar:
 Registrar alquiler
 Buscar película
 Buscar reserva
 Consultar tarifario
 Agregar socio a cola de espera
 Buscar socio
 Registrar Pago
 Responder solicitud de evaluación crediticia
 Registrar crédito
En segundo lugar, ¿Qué es lo que ha solicitado el cliente que nos ha contratado?
Ha solicitado que el registro de socios y de reservas vídeos y juegos vía web.

Asimismo, si sus clientes afiliados lo requieren, deberían actualizar sus datos vía web.
Por consiguiente, tendríamos más requisitos:
 Mantener socio.
 Consultar catálogo de películas
En tercer lugar, es necesario identificar

El resultado de este análisis se documenta en la Matriz de Actividades Vs. Requisitos,
tal como se muestra a continuación:


Solicita alquiler de Registrar el alquiler de CUS 01-Registrar

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

de evaluación Finanzas
crediticia
Comunica al socio Registrar el pago del CUS 07-Registrar
Cajero R08 Cajero 7
pago en efectivo alquiler Pago
Genera
Registrar documento de CUS 08-Registrar
documento de Cajero R11 Cajero 6
credito crédito
crédito
Cancela pago al Registrar el alquiler de
Socio R01 Registrar alquiler Recepcionista 7
contado una película
Gestión de
… …
devolución
Gestión de
… …
reserva
Actualización de
… …
stock
A partir de la Matriz de Actividades vs Requisitos Funcionales es posible identificar los casos de uso que serán considerados
dentro de un paquete llamado “reutilizables”. Los casos de uso que van dentro del paquete “reutilizables” son aquellos casos
de uso incluidos (CUI) por más de un caso base (CUB)

3.2.3.1. Estructura del Modelo de Casos de Uso
Figura 74: Estructura de Modelo de Casos de Uso en RSA
3.2.3.2. Actores
Figura 75: Actores en EA

3.2.3.3. Casos de Uso
Figura 76: Paquetes de Casos de Uso en RSA
Figura 77: Diagrama General de Casos de Uso en RSA

3.3. TEMA 10: ESTRUCTURANDO EL MODELO DE CASOS DE

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

 Extraer el comportamiento común encontrado en varios casos de uso.
 Hacer que el modelo de casos de uso sea fácil de mantener.
La ejecución de cada caso de uso incluye la comunicación con uno o más actores.
Una instancia de un caso de uso siempre es iniciada por un actor pidiendo al sistema
hacer algo. Esto implica que cada caso de uso debe tener la asociación de
comunicación con los actores. La razón de esta norma es hacer cumplir el sistema
para ofrecer sólo la funcionalidad que los usuarios necesitan, y nada más. Si se
encuentran casos de uso que nadie pide significa que algo está mal en el modelo de
caso de uso o en los requisitos.
Sin embargo, hay algunas excepciones a esta regla:
 Si un caso de uso es abstracto (no se instancia por separado, sino en el

contexto de otro caso de uso), su comportamiento no puede incluir la
interacción con algún actor. En ese caso, el caso de uso abstracto no tendrá
ninguna asociación de comunicación con actores.
 Un caso de uso hijo en una relación de generalización no necesita tener un
actor asociado a él si el caso de uso padre describe la comunicación con el
actor.
 Un caso de uso base en una relación include no necesita tener un actor
asociado a él si el caso de uso incluido describe la comunicación con el actor.
 Un caso de uso puede ser iniciado de acuerdo con un horario (por ejemplo, una
vez a la semana o una vez al día), lo que significa que el reloj del sistema es el
iniciador. El reloj del sistema es interno al sistema y el caso de uso no es
iniciado por un actor, sino por un evento interno del sistema. Si ninguna
interacción de actor se produce en el caso de uso, éste no tendrá ninguna
asociación con un actor. Sin embargo, se puede utilizar un actor ficticio
"tiempo" para mostrar cómo el caso de uso es iniciado en el diagrama de casos
de uso.
3.3.1. Objetivos
Los objetivos de esta actividad son:
 Extraer descripciones de funcionalidad (de casos de uso) generales y

compartidas que pueden ser utilizadas por casos de uso más específicos
(generalización).
 Extraer descripciones de funcionalidad (de casos de uso) adicionales u
opcionales que pueden extender casos de uso más específicos (relaciones de
extensión).

 Extraer descripciones de funcionalidad (de casos de uso) adicionales e

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

Existen tres tipos de relaciones entre casos de uso: include, extend y de
generalización. Entre actores se puede utilizar solo la relación de generalización.
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 78: 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 79: Ejecución de la relación de inclusión

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 80: 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 81: Ejecución de la relación de extensión
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 82: Relación de “generalización” entre casos de uso
Figura 83: 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 84: Ejecución de la relación de generalización

3.3.3. Casos de Uso Abstractos y Concretos

Se dice que un caso de uso es abstracto solo si se instancia en el contexto de otro
caso de uso; es decir, dependen de otro caso de uso para instanciarse puesto que no
existe un actor que lo active.
Un caso de uso es concreto si es iniciado por un actor y constituye un completo flujo

de eventos. "Completo" significa que una instancia del caso de uso lleva a cabo toda
la operación solicitada por el actor.
Por lo tanto se puede afirmar que:
 Los casos de uso activados por un actor son concretos.

 Los casos de uso incluidos o extendidos que únicamente pueden instanciarse
cuando son llamados por el caso de uso base son casos de uso abstractos
 En el caso de la generalización, generalmente el caso de uso padre será
abstracto debido a que no están definidos completamente, pues los casos de
uso hijos contienen las funciones específicas requeridas por los actores.
La siguiente figura ilustra ejemplos de casos de uso abstractos y concretos en un

Diagrama de casos de uso estructurado. Es conveniente escribir con letra cursiva el
nombre del caso de uso abstracto.
Figura 85: Diagrama de Casos de Uso estructurado

CASO RESUELTO: EL PIRATA
Elabore el Diagrama de Casos de Uso Estructurado, incluyendo CUB, CUI, CUE, para
el Caso El Pirata presentado en la página 103.
Solución:
El Diagrama General de Casos de Uso Estructurado incluyendo CUB, CUI, CUE es el
siguiente:
Figura 86: Diagrama General de Casos de Uso Estructurado
Antes de resolver el caso propuesto directamente en la herramienta

Case es recomendable realizar un pequeño bosquejo utilzando papel y
lápiz.

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

las relaciones entre las empresas y sus clientes a través de Centros de Contacto
Telefónico o plataformas multicanal (IVR, SMS) para brindar diferentes servicios (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

3.3.4. Especificación de Casos 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:
ESPECIFICACIÓN DE CASOS DE USO

Nombre Indicar el nombre y codificación del CU
Actores Indicar el actor(es) relacionados a este CU
Propósito Indicar el propósito de CU
Breve descripción Breve descripción
Indicar las condiciones que deben cumplirse antes de
Pre-condición
iniciar el CU
Indicar las condiciones que se han cumplido luego de
Post-condición
ejecutar el CU
Indicar el evento que inicia el CU.
Evento disparador Ejemplo: El caso de uso inicia cuando el recepcionista
pulsa el botón “Registrar Solicitud”
Indicar la secuencia de actividades que siguen al
Flujo Básico evento disparador
Indicar la secuencia de actividades de los sub-flujos si

Sub-Flujos
los hubiera
Indicar la secuencia de actividades de los flujos
Flujos Alternos
alternos si los hubiera
Puntos de extensión Indicar los puntos de extensión si los hubiera.
Requerimientos Indicar que requerimientos funcionales son atendidos
Funcionales por el presente CU
asociados
Requerimientos Indicar si existen otros requerimientos a considerar.
especiales
Prototipos
Agregar los prototipos elaborados en función a la ECU

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

los casos de uso según su importancia para establecer el orden de realización de los
mismos. En este sentido, los casos de uso con significado arquitectónico se identifican
y se priorizan. Una vez que se han priorizado los casos de uso, se puede decidir el
orden de desarrollo del sistema.
Se establecen períodos, ciclos o iteraciones de trabajo para desarrollar la realización

de los casos de uso. Se distribuyen los casos de uso en cada ciclo de trabajo; los
casos de uso primarios deben realizarse en primer orden y, luego, los secundarios.
Los casos de uso opcionales se deben dejar para el final de la realización.
3.3.5.1. Objetivos
El propósito de otorgarles prioridad a los USE CASE es identificar los casos de uso
primarios para la presente etapa de desarrollo del proyecto. Según estos criterios, se
determinan los casos de uso críticos para especificarlos en esta etapa del proyecto.
3.3.5.2. Alcance
Dar prioridad 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.
 Nivel crítico (o primario)
Agrupa a los USE CASE que tienen que ver con las funciones básicas del
sistema.
 Nivel de baja importancia (o secundario)

Agrupa a los USE CASE que tienen que ver con las funciones de soporte del
sistema y que no representan mayor riesgo para el proyecto.
3.3.5.4. Factores considerados en la priorización
Se tomaron en cuenta pesos (que representan porcentaje) por cada factor que afecta
a cada USE CASE. Los valores que pueden tomar los factores están en la escala del 1
al 10 (1: menor importancia; 10: mayor importancia). Se considerarán primarios a
aquellos USE CASE que tengan un puntaje mayor a 6.5, ya que esto significa que
superan el 65% de prioridad en el sistema (PONDERACIÓN).
 Importancia en el proceso del negocio: indica la relevancia que tiene la

funcionalidad con el proceso de negocio. Una alta puntuación revela que las
transacciones de la empresa se apoyan considerablemente en la funcionalidad
que tiene este USE CASE. Su ponderación es 0.4.
 Complejidad de desarrollo: Indica la dificultad que se percibe del USE CASE,

en cuanto a las tareas de análisis, diseño, implementación, pruebas e
integración del mismo. Su ponderación es 0.3.
 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.

CASO RESUELTO: SIRI TOURS
La agencia de viajes SIRI TOURS es una agencia que se dedica a la venta de

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

Solución:
Nombre Registrar venta de pasaje

Actores Vendedor
El objetivo del CU es permitir registrar la comprar
Propósito
de uno o más pasajes
El CU permite a un vendedor registrar la venta de
Breve descripción
uno o más pasajes para uno o más personas.
El vendedor debe haber sido validado como
Pre-condición
usuario del sistema
El vendedor ha registrado la venta de uno o más
Post-condición
pasajes dentro en el sistema.
El caso de uso inicia cuando el vendedor pulsa el
Evento disparador
botón “Nueva Venta”
1. El sistema muestra formulario de registro
de venta.
2. El vendedor ingresa los datos necesarios
para la búsqueda de pasajes (lugar de
partida, fecha de partida, lugar de retorno,
fecha de retorno, número de pasajeros).
3. El vendedor pulsa el botón “Buscar”.
4. El sistema muestra el listado de vuelos
disponibles que cumplen con los criterios de
búsquda.
5. El vendedor selecciona el vuelo deseado y
pulsa el botón “Continuar”.
6. El sistema muestra listado de vuelos de
partida y y el costo asociado a cada uno de
ellos.
7. El vendedor selecciona el vuelo de partida y
pulsa el botón “Continuar”.
Flujo Básico 8. El sistema muestra listado de vuelos de
retorno y el costo asociado a cada uno de
ellos.
9. El vendedor selecciona el vuelo de retorno y
pulsa continuar.
10. El sistema muestra formulario para
registrar los datos personales del pasajero
(DNI, nombres, apellidos, dirección,
teléfono, email).
11. El vendedor registra los datos solicitados
por cada pasejero solicitado. Al finalizar
pulsa el botón “Pagar”.
12. El sistema muestra formulario para el
registro del pago.
13. El vendedor registra los datos de la tarjeta
de crédito con la que se efectua la compra y
pulsa el botón “Finalizar”.
14. El sistema muestra información de resumen
de la compra realizada y solicita al

vendedor confirmar la compra.

15. El vendedor confirma la comprar pulsando
el btón “Aceptar”.
16. El sistema registra la compra y envía
confirmación por correo electrónico al
vendedor y a cada uno de los pasajeros. El
Caso de Uso termina.
Sub-Flujos Ninguno
En el paso 16: Si se presentan problemas en el
registro de la compra el sistema muestra mensaje
Flujos Alternos
de error: “Problemas durante el registro de pago.
Favor de contactarse con su banco”
Si la facturación se debe realizar a otra persona, el
vendedor selecciona la opción “Cambiar datos de
Puntos de extensión
facturación”, inmediatamente el sistema invoca al
caso de uso “Registrar datos de Facturación”
RF08: El sistema deb permitir registrar la venta de
uno o más pasajes.
Requerimientos
Funcionales asociados RF10: El sistema debe permitir que los datos de
facturación estén a nombre de una persona
diferente a la de los pasajeros.
Requerimientos especiales Ninguno
Prototipos


CASO PROPUESTO: RESTAURANTE EL TOYITO
Atención de Clientes
El proceso general de Atención de cliente cuenta con varios sub procesos que son
efectuados por: El Maitre, los mozos, el cantor, el cocinero y el cajero. El cliente es
recibido por el Maitre quien pregunta si cuenta con Reserva, verifica su Libro de
Reservas y coloca la Reserva como Realizada. De no contar con una reserva, el
Maitre consulta la disponibilidad de las mesas en su Mapa de Mesas y asigna una
mesa disponible del comedor al comensal.
El Maitre conducirá al cliente a la mesa, asigna a un mozo para la atención y deja una
Carta/Menú al Cliente. El cliente consulta la carta/menú y hace su pedido al Mozo. El
mozo anota el pedido del cliente en un documento llamado Comanda y entrega una
copia a la cocina.
El Cantor revisa la Comanda con el pedido y distribuye: Si el pedido incluye bebidas

gaseosas, las despacha personalmente, si el pedido es de platos para preparar “canta”
la orden al cocinero quien prepara el mismo, una vez que en la cocina es preparado el
pedido, el cantor coloca un visto en la comanda en señal de conformidad como pedido
preparado.
El mozo recibe los platos ubicados en un mostrador y sirve los mismos al cliente, el
mozo visa el original de la comanda como pedido atendido y entrega una copia al
cajero para que posteriormente genere la cuenta del cliente.
El cliente consumirá el plato servido y podrá repetir el proceso de pedido en varias

oportunidades (se generará una comanda por cada pedido extra). Una vez terminado
su consumo solicitará la cuenta al Mozo, éste le traerá un documento llamado
Adelanto de Cuenta, el cual tendrá el detalle de lo consumido, el cliente lo verifica y de
ser conforme procederá a realizar el proceso de Cancelación del Consumo al Mozo
asignado.
Cobranza por Servicios

El cajero consulta el pedido (que normalmente contiene varias comandas) para
obtener el monto a cobrar. Una vez realizado el pago por el cliente, el cajero genera el
documento, registra el pago y le entrega al mozo el documento con el sello de
cancelado.
El mozo se encargará de llevar a la mesa tanto el documento (Boleta o Factura) como
el vuelto respectivo, cerrando así el proceso de cobranza y el proceso de Atención.
ECUN: Atención de Clientes
Flujo de Trabajo
Flujo Básico
1. El caso de uso inicia cuando el cliente llega y solicita servicio.
2. El maitre recibe al cliente y le pregunta si cuenta con reserva.
3. Si el cliente cuenta con reserva, el maitre verifica su Libro de reservas y coloca
la reserva como realizada.
4. El maitre conducirá al cliente a su mesa.
5. El maitre le ofrece algo de beber y si el cliente desea, el maitre llena la
comanda y la lleva al bar y a caja.
6. El maitre asigna un mozo para la atención.
7. El mozo lleva las bebidas a la mesa del cliente y le entrega la carta/Menú y el
proceso termina.

Flujo Alternativo
1. En el punto 1.1.3 si el cliente no cuenta con reserva. El maitre consulta la
disponibilidad de las mesas en su Mapa de Mesas y asigna una mesa
disponible del comedor y continua al paso 1.1.4.
2. En el punto 1.1.5 si el cliente no desea aún algo de beber, el maitre le entrega
la carta/menú, asigna un mozo para la atención y el proceso termina.
Ejercicio:
1. Utilizando la plantilla proporcionada elabore la ECU del ECUN “Atención de
clientes”.
2. Elabore el Modelo de Casos de Uso.
3. Elabore el Diagrama General de Casos de Uso Estructurado.
4. Elabore la ECU de una funcionalidad del Sistema Socrates

Resumen
1. El Modelo de Casos de Uso permite representar las funcionalidades del sistema a
implementar.
2. En el modelo de Casos de Uso se debe identificar a los actores y a los casos de

uso, que son los artefactos relevantes del modelo.
3. En el Modelo de Casos de Uso se crean los siguientes diagramas:
 Diagrama General de Casos de Uso

 Diagrama de Actores
 Diagrama de Casos de Uso por Proceso de Negocio
4. En un Diagrama de Casos de uso se pueden presentar hasta tres tipos de

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

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

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

opcional de un caso base.
8. Si desea saber más acerca de estos temas, puede consultar las siguientes
páginas:
 https://www.youtube.com/watch?v=CC_5hJxdISM
 https://www.youtube.com/watch?v=tR6kv22sxc8

Analisis y Diseño de Sistemas I

Cargado por

Copyright:

Formatos disponibles

Analisis y Diseño de Sistemas I

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Analisis y Diseño de Sistemas I

Cargado por

Copyright:

Formatos disponibles

[Logo: colocar logo nuevo]

[Fuente: Negrita, Arial 48.]

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

[Fuente: Negrita, Arial Black 28.]

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

2.3 Tema 5 Caso Propuesto: CHASQUI EXPRESS 54

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

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

3.2 Tema 9 : Modelo de Casos de Uso 102

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

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

[Fuente: Negrita, Arial Black 28.]

El manual para el curso ha sido diseñado bajo la modalidad de unidades de

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

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

[Fuente: Negrita, Arial Black 28.]

Análisis y Diseño de Sistemas I

Ingeniería de Software, Disciplina del Modelado Disciplina de la Captura

Ingeniería de Modelado de Captura de

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

[Fuente: Negrita, Arial Black 72, En línea con el texto]

[Fuente: Negrita, Arial 12]

1.2 Tema 2 : Herramientas CASE y Entorno de IBM-RSA

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

[Subtítulo de Unidad – Nivel 1. Fuente: Arial 14]

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

Se ha elegido la definición utilizada por Roger Pressman, quien indica que la

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

1 RAE. Real Academia Española

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

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

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

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

Luego de describir cada capa, se puede afirmar que el objetivo de la ingeniería de

1.1.1. Elementos claves de la Ingeniería de Software

1.1.1.3. Métodos o técnicas

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.1.2. Fases de un proceso software

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

1.1.2.1. Fase de definición

 La ingeniería de sistemas o de información

IEST PRIVADO CIBERTEC CARRERA DE TECNOLOGÍA

1.1.2.2. Fase de desarrollo

 El diseño del Software

1.1.2.3. Fase de mantenimiento

 Correctivo: Para corregir los defectos

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

1.1.2.4. Actividades de protección

 Seguimiento y control del proyecto de software.

CARRERAS DE TECNOLOGÍA IEST PRIVADO CIBERTEC

1.1.3. Modelos de proceso de software

Existen muchos modelos de procesos de software, dentro de los cuales podemos

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

1.1.3.1. Modelo Cascada

Existen algunos problemas que ocurren al utilizar este modelo: