Metodologia rup

Proyecto de desarrollo del Software Rational Unified Process

METODOLOGIA
RUP
(RATIONAL UNIFIED PROCESS)

Proyecto: __________________________________________

Sistema: ___________________________________________

Integrantes:

Jefe de Proyecto: ________________________________________

Colaboradores:

1- Colaborador1
2- Colaborador2
3- Colaborador….n

Prof. Ayquipa Cordova, Godofredo


FASE
DE
INICIO

Consideraciones:

1- Aspectos generales de la organización
2- Plan de desarrollo de software
3- Modelo de Negocio
a- Unidad Organizacional
b- Paquete de Negocio
c- Diagrama de Paquete de Negocio
d- Diagrama de Caso de Uso de Negocio
e- Especificaciones de Caso de Uso de Negocio
f- Diagrama de Actividad de Negocio
g- Diagrama de Objetos de Negocio



PROYECTO DE DESARROLLO DE SOFTWARE

ASPECTOS ORGANIZACIONALES

1- Organización
1.1- Introducción
1.2- Reseña histórica
1.3- Ubicación Geográfica

2- Estructura Organizacional
2.1- Visión
2.2- Misión
2.3- Metas
2.4- Objetivo
- General
- Específicos
2.5- Organigrama

3- Área de Desarrollo

3.1- Descripción del área
3.2- Aspectos generales del área
- Visión
- Misión
- Metas
3.3- Integrantes del área
- Cargo
- Funciones
- Responsabilidades
3.4- Definición y descripción del problema
- Administrativo
- Organizacional

3.5- Recomendaciones

- Administrativo

- Organizacional

3.5- Áreas Involucradas

3.6- Formatos manuales



1- Organización

Una organización es un conjunto de elementos, compuesto principalmente por personas, que actúan e
interactúan entre sí bajo una estructura pensada y diseñada para que los recursos humanos, financieros,
físicos, de información y otros, de forma coordinada, ordenada y regulada por un conjunto de normas,
logren determinados fines, los cuales pueden ser de lucro o no.

1.1- Introducción
Descripción de la organización, rubro, dirección, etc...
1.2- Reseña histórica
Origen, creación y evolución de la organización
1.3- Ubicación Geográfica (mapa)

2- Estructura Organizacional
2.1- Visión
Define y describe la situación futura que desea tener la empresa, el propósito de la visión es
guiar, controlar y alentar a la organización en su conjunto para alcanzar el estado deseable de la
organización.

Ejemplo:

“La Visión es ser un Grupo energético y de servicios líder y en continuo crecimiento, con
presencia multinacional, que se distinga por proporcionar una calidad de servicio excelente a sus
clientes, una rentabilidad sostenida a sus accionistas, una ampliación de oportunidades de
desarrollo profesional y personal a sus empleados y una contribución positiva a la sociedad
actuando con un compromiso de ciudadanía global.”

2.2- Misión:

Define el negocio al que se dedica la organización, las necesidades que cubren con sus
productos y servicios, el mercado en el cual se desarrolla la empresa y la imagen pública de
la empresa u organización.

Ejemplo:

“La Misión del Grupo Gas Natural es atender las necesidades energéticas de la sociedad,
proporcionando a sus clientes servicios y productos de calidad respetuosos con el medio
ambiente, a sus accionistas una rentabilidad creciente y sostenible y a sus empleados la
posibilidad de desarrollar sus competencias profesionales.”

2.3- Metas y Objetivos

Una metas, es pues lo que conduce a lograr el objetivo, y en consecuencia, el objetivo es el
resultado de haber alcanzado cada una de las metas necesarias o planteadas para lograr el
objetivo propuesto.

Ejemplo:

Un ejemplo más clásico de lo que es un objetivo y lo que es una meta, son las vueltas
ciclísticas como el Tour de Francia, la vuelta a Colombia o a España. El objetivo es ganar el



título o la vuelta. Las metas será ganar cada una de las etapas. Aquí también podemos ver
que existen lo que llaman metas volantes y/o los premios de montaña.

2.5- Organigrama

El organigrama se define como la representación gráfica de la estructura orgánica de una
institución o de una de sus áreas y debe reflejar en forma esquemática la descripción de las
unidades que la integran, su respectiva relación, niveles jerárquicos y canales formales de
comunicación.

3- Área de Desarrollo
Establecer el área de desarrollo (organigrama)

3.1- Descripción del área

Describir todas las actividades realizadas en el área.

3.2- Aspectos generales del área.

Visión, Misión y Metas

3.3- Integrantes del área

Empleados que laboran en el área, elaborar un cuadro donde se describa lo siguiente:

Integrante Cargo Funciones Responsabilidades

3.4- Definición y descripción del problema

Cuadro donde se menciona todos los problemas (administrativo y organizacional)
puntuales y una breve descripción del mismo.



Administrativo
Problemas Descripcion

Problema1
Problema2

Organizacional
Problemas Descripcion

Problema1
Problema2

3.5- Recomendaciones

Administrativo
Recomendaciones Descripcion

Recomendación 1
Recomendación 2

Organizacional
Recomendaciones Descripcion

Recomendación 1
Recomendación 2

3.6- Aéreas Involucradas

Identificar las aéreas que están relacionadas con el área en estudio

3.7- Formatos Manuales

Insertar todos los formatos manuales existentes en el área.



PLAN DE DESARROLLO DE SOFTWARE

1. Introducción

2. Vista General del Proyecto
2.1 Propósito, Alcance y Objetivos
2.2 Suposiciones y Restricciones
2.3 Entregables del proyecto
2.4 Evolución del Plan de Desarrollo del Software

3. Organización del Proyecto
3.1 Participantes en el Proyecto
3.3 Roles y Responsabilidades

4. Gestión del Proceso
4.1 Tecnologia de Informacion
4.1..1 Evaluacion Tecnologica
4.1.2 Recomendaciones
4.2 Plan del Proyecto
4.2.1 Plan de las Fases
4.2.2 Calendario del Proyecto



Plan de Desarrollo del Software
1. Introducción
La introducción es una breve descripción de de las razones por las cuales se lleva a cabo este
proyecto de desarrollo, también una breve descripción de la metodología a implementar.

La introducción del plan de desarrollo del software debe dar una visión del documento completo.
Debe incluir el propósito, alcance, definiciones, acrónimos, abreviaturas y referencias de este plan

Ejemplo1:

“Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la
propuesta elaborada como respuesta al proyecto de prácticas de la asignatura de Laboratorio de
Sistemas de Información de la Facultad de Informática de la Universidad Católica. Este documento
provee una visión global del enfoque de desarrollo propuesto.
El proyecto ha sido ofertado por Patricio Orlando Letelier Torres basado en una metodología de
Rational Unified Process en la que únicamente se procederá a cumplir con las tres primeras fases que
marca la metodología, constando únicamente en la tercera fase de dos iteraciones. Es importante
destacar esto puesto que utilizaremos la terminología RUP en este documento. Se incluirá el detalle
para las fases de Inicio y Elaboración y adicionalmente se esbozarán las fases posteriores de
Construcción y Transición para dar una visión global de todo proceso.
El enfoque desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las
características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y
los artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de
RUP.”
2. Vista General del Proyecto
2.1 Propósito, Alcance y Objetivos
Propósito: el propósito define lo que se espera lograr a través del proyecto mismo. Este debe incluir
referencias sobre la duración, el lugar, la cantidad, la calidad y los beneficiarios.

Un propósito adecuadamente definido constituye la clave para el éxito del proyecto. La definición de
otros elementos del proyecto fluye del propósito.

Ejemplo:

- Evaluar la efectividad de las técnicas de captura de requisitos, en pequeñas empresas de
desarrollo de software.
- Desarrollar y evaluar un interfaz de usuario para paquetes estadísticos.
- Producir y evaluar lenguajes de cuarta generación para el desarrollo de bases de datos.

Objetivo:
Los objetivos representan los logros significativos en el camino hacia el propósito final del proyecto.

Ejemplo:

- Definir las pautas, controles y procedimientos que debe reunir el marco para la administración
de proyectos relacionados al desarrollo de sistemas de información.
- Documentar las diferentes técnicas actuales para la predicción de las variaciones de los índices
de Bolsa;
- Desarrollar un modelo apropiado con una red neuronal artificial:
- Reunir datos para el análisis y la evaluación;



- Evaluar el modelo utilizando las técnicas estadísticas adecuadas;
- Redactar un informe final.
Alcance: Definir límites del trabajo y partes del proyecto.

“Hacer lo que hay que hacer y no hacer lo que no hay que hacer”.

Ejemplo:

- Todas las áreas de servicios informáticos y los sitios donde se realicen proyectos de desarrollos
o adquisición de sistemas de información en el Estado Provincial, comprendidos en el Decreto
Acuerdo 462/96.
2.2 Suposiciones y Restricciones
Los supuestos o factores exógenos son aquellas condiciones que se hallan afuera del control (o la
influencia) inmediata del proyecto, pero son necesarias para lograr los objetivos del mismo. Un
proyecto es siempre una contribución limitada al desarrollo que depende de factores externos para su
éxito.

Ejemplo:

Suposiciones
 Ayudara a mejorar el manejo y el control de sus productos generando más tiempo
y disponibilidad en la venta y alquiler de estos.
 Estará a corde con el desarrollo tecnológico puesto que sería el primer sistema que
tendría la empresa.
Restricciones
 El personal no se encuentra capacitado para el uso del software.
 No contar con licencia necesaria para poder instalar el software (lenguaje de
programación asp.net).

2.3 Entregables del proyecto

Definición:

Dado que el objetivo final del proyecto es la entrega de un subsistema informático (entregable)
veamos algunas definiciones y utilidades de los entregables. Los entregables los definiremos como
"Productos que, en un cierto estado, se intercambian entre los clientes y los desarrolladores a lo largo
de la ejecución del proyecto informático".

Los entregables los clasificamos como relativos al objetivo y relativos a la gestión del proyecto. Son
entregables relativos al objetivo todos aquellos documentos que hacen referencia exclusivamente al
sistema de información y al subsistema informático en desarrollo. Pertenecen a este conjunto los
requisitos del sistema, la especificación del sistema, la documentación del diseño, él código fuente,
los programas ejecutables, los manuales de usuario, etc. Los entregables relativos a la gestión del
proyecto hacen referencia a aquellos documentos que se refieren a la situación en que se encuentra
un proyecto, previsiones de costes, gastos realizados, informe sobre ambientes de trabajo, etc., siendo
su objetivo el poder controlar el proyecto. Pertenecen a esta clase la planificación del proyecto, los



presupuestos, los documentos de control de la planificación o de la calidad, los estudios de riesgos
durante el desarrollo, etc.

A continuación se indican y describen cada uno de los artefactos que serán generados y utilizados
por el proyecto y que constituyen los entregables. Esta lista constituye la configuración de RUP
desde la perspectiva de artefactos, y que proponemos para este proyecto.

Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental),
todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual,
sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos.
Sin embargo, el resultado de cada iteración y los hitos del proyecto están enfocados a conseguir un
cierto grado de completitud y estabilidad de los artefactos. Esto será indicado más adelante cuando
se presenten los objetivos de cada iteración.

1) Plan de Desarrollo del Software
Es el presente documento.

2) Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos
(Agentes de registro, solicitantes finales, otros sistemas etc.). Permite situar al sistema en el contexto
organizacional haciendo énfasis en los objetivos en este ámbito. Este modelo se representa con un
Diagrama de Casos de Uso usando estereotipos específicos para este modelo.

3) Modelo de Objetos del Negocio
Es un modelo que describe la realización de cada caso de uso del negocio, estableciendo los
actores internos, la información que en términos generales manipulan y los flujos de trabajo
asociados al caso de uso del negocio. Para la representación de este modelo se utilizan
Diagramas de Colaboración (para mostrar actores externos, internos y las entidades
(información) que manipulan, un Diagrama de Clases para mostrar gráficamente las entidades
del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo.

4) Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de
ellas. Se representa mediante Diagramas de Casos de Uso.

5) Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con
una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de
documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos
no-funcionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá
adjuntarse una representación gráfica mediante un Diagrama de Actividad.

6) Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las
interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los
requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con
alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo
al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de
Elaboración, los otros serán desechados. Asimismo, este artefacto, será desechado en la fase de



Construcción en la medida que el resultado de las iteraciones vayan desarrollando el producto
final.

7) Modelo de Análisis y Diseño

Este modelo establece la realización de los casos de uso en clases y pasando desde una
representación en términos de análisis (sin incluir aspectos de implementación) hacia una de
diseño (incluyendo una orientación hacia el entorno de implementación), de acuerdo al avance
del proyecto.

8) Modelo de Datos
Previendo que la persistencia de la información del sistema será soportada por una base de datos
relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo
con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un
Diagrama de Clases (donde se utiliza un profile UML para Modelado de Datos, para conseguir
la representación de tablas, claves, etc.).

9) Lista de Riesgos
Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados
en orden decreciente de importancia y con acciones específicas de contingencia o para su
mitigación.

Ejemplo:

La gestión de un proyecto de software exitoso requiere entender qué puede salir mal. A continuación
se indican 10 señales de que un proyecto esté en peligro.

1. El personal de software no entiende las necesidades de sus clientes.

2. El ámbito del producto está más definido

3. Los cambios se gestionan mal

4. La tecnología elegida cambia

5. Las necesidades comerciales cambian

6. Los plazos de entrega no son realistas

7. Los usuarios se resisten

8. Se pierde el patrocinio

9. El equipo de proyecto carece de personal con las habilidades apropiadas

10. Los gestores evitan las mejores prácticas y las lecciones aprendidas



2.4 Evolución del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisará semanalmente y se refinará antes del comienzo de
cada iteración.

3. Organización del Proyecto
Describe la arquitectura organizacional del equipo de desarrollo.

En la planificación se fracciona las actividades de modo que resulte fácil la realización y control de
cada tarea.

Hay que crear las condiciones que:

• faciliten la coordinación: puesta en marcha, toma de decisiones, seguimiento y
finalización de tareas.
• facilite comunicarse a las personas encargadas de cada tarea, con las personas que
realizan la misma u otras tareas asociadas a la suya.



3.1 Participantes en el Proyecto

Jefe de Proyecto.
Aquí se declara el perfil del candidato a este puesto, así como su nombre y apellidos
Analista de Sistemas.
Analistas - Programadores.
Aquí se declara el perfil de los candidatos a estos puestos, así como sus nombres y apellidos
Ingeniero de Software.

3.2 Roles y Responsabilidades
A continuación se describen las principales responsabilidades de cada uno de los puestos en el
equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que
desempeñan en RUP.

Puesto Responsabilidad

El jefe de proyecto asigna los recursos, gestiona las prioridades,
coordina las interacciones con los clientes y usuarios, y mantiene al
equipo del proyecto enfocado en los objetivos. El jefe de proyecto
también establece un conjunto de prácticas que aseguran la
Jefe de Proyecto
integridad y calidad de los artefactos del proyecto. Además, el jefe de
proyecto se encargará de supervisar el establecimiento de la
arquitectura del sistema. Gestión de riesgos. Planificación y control
del proyecto.

Captura, especificación y validación de requisitos, interactuando con
el cliente y los usuarios mediante entrevistas. Elaboración del
Analista de Sistemas
Modelo de Análisis y Diseño. Colaboración en la elaboración de las
pruebas funcionales y el modelo de datos.

Construcción de prototipos. Colaboración en la elaboración de las
Programador pruebas funcionales, modelo de datos y en las validaciones con el
usuario

Gestión de requisitos, gestión de configuración y cambios,
elaboración del modelo de datos, preparación de las pruebas
Ingeniero de Software
funcionales, elaboración de la documentación. Elaborar modelos de
implementación y despliegue.



4. Gestión del Proceso
La Gestión de Proyectos tiene como finalidad principal la planificación, el seguimiento y control de
las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema
de Información. Como consecuencia de este control es posible conocer en todo momento qué
problemas se producen y resolverlos o paliarlos de manera inmediata.

4.1 Tecnología de Información
- Evaluación Tecnológica
- Recomendaciones
4.2 Plan del Proyecto
En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.
4.2.1 Plan de las Fases

El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas. La
siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada fase (para
las fases de Construcción y Transición es sólo una aproximación muy preliminar)

Fase Nro. Iteraciones Duración

Fase de Inicio 1 17-set-30

Fase de Elaboración 1 1-oct-11-nov

Fase de Construcción 1 12-nov-24-dic

Fase de Transición 1 25-dic-5feb

Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la
realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la
mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose
en mayor o menor grado de a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque
en ella lo ensombrecido marca el énfasis de cada disciplina (workflow) en un momento determinado
del desarrollo.



Los hitos que marcan el final de cada fase se describen en la siguiente tabla.

Descripción Hito

Fase de Inicio En esta fase desarrollarán los requisitos del producto desde la
perspectiva del usuario, los cuales serán establecidos en el artefacto
Visión. Los principales casos de uso serán identificados y se hará un
refinamiento del Plan de Desarrollo del Proyecto. La aceptación del
cliente /usuario del artefacto Visión y el Plan de Desarrollo marcan el
final de esta fase.

Fase de En esta fase se analizan los requisitos y se desarrolla un prototipo de
Elaboración arquitectura (incluyendo las partes más relevantes y / o críticas del
sistema). Al final de esta fase, todos los casos de uso correspondientes
a requisitos que serán implementados en la primera release de la fase
de Construcción deben estar analizados y diseñados (en el Modelo de
Análisis / Diseño). La revisión y aceptación del prototipo de la
arquitectura del sistema marca el final de esta fase. En nuestro caso
particular, por no incluirse las fases siguientes, la revisión y entrega de
todos los artefactos hasta este punto de desarrollo también se incluye
como hito. La primera iteración tendrá como objetivo la identificación
y especificación de los principales casos de uso, así como su
realización preliminar en el Modelo de Análisis / Diseño, también
permitirá hacer una revisión general del estado de los artefactos hasta
este punto y ajustar si es necesario la planificación para asegurar el
cumplimiento de los objetivos. Ambas iteraciones tendrán una
duración de una semana.

Fase de Durante la fase de construcción se terminan de analizar y diseñar
Construcción todos los casos de uso, refinando el Modelo de Análisis / Diseño. El
producto se construye en base a 2 iteraciones, cada una produciendo
una release a la cual se le aplican las pruebas y se valida con el
cliente / usuario. Se comienza la elaboración de material de apoyo



al usuario. El hito que marca el fin de esta fase es la versión de la
release 2.0, con la capacidad operacional parcial del producto que
se haya considerado como crítica, lista para ser entregada a los
usuarios para pruebas beta.

Fase de En esta fase se prepararán dos releases para distribución,
Transición asegurando una implantación y cambio del sistema previo de
manera adecuada, incluyendo el entrenamiento de los usuarios. El
hito que marca el fin de esta fase incluye, la entrega de toda la
documentación del proyecto con los manuales de instalación y todo
el material de apoyo al usuario, la finalización del entrenamiento de
los usuarios y el empaquetamiento del producto.

4.2.2 Calendario del Proyecto
A continuación se presenta un calendario de las principales tareas del proyecto incluyendo sólo las
fases de Inicio y Elaboración. Como se ha comentado, el proceso iterativo e incremental de RUP está
caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del
proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto
pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. La
siguiente figura ilustra este enfoque, en ella lo ensombrecido marca el énfasis de cada disciplina
(workflow) en un momento determinado del desarrollo.



Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica cuándo el
artefacto en cuestión tiene un estado de completitud suficiente para someterse a revisión y probación,
pero esto no quita la posibilidad de su posterior refinamiento y cambios.

Calendario Fase de Inicio

Calendario Fase de Elaboración



Fase de Construcción

Fase de Transición



MODELO DE NEGOCIO

1. CONCEPTO:
Un modelo del negocio es una abstracción de cómo funciona la organización.
Provee una vista simplificada de la estructura y comportamiento del negocio que actuará como la
base de comunicación, mejora o innovación del negocio, así como también para definir los requisitos
de los diferentes sistemas de software que pueden soportar al negocio.
El Modelo de negocio es un modelo que refleja gráficamente las metas y funciones que persigue el
negocio. Se usa como una entrada esencial para identificar roles y entregables en la organización.

Así, los objetivos de la etapa de modelado del negocio son los siguientes:

Entender los problemas actuales en la organización o empresa para identificar los aspectos a mejorar.
Comprender la estructura y el dinamismo de la organización o empresa para la cual se va a
desarrollar el sistema software.
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.
Entender como el sistema software encaja en la organización.
Entender los mecanismos del negocio actual
Evaluar los procesos actuales
Formar una base para mejorar/innovar el negocio actual
Formar una base para un sistema de información que apoya al negocio permitiendo definir los
requisitos funcionales y no funcionales de un futuro sistema informático.

Para conseguir estos objetivos el flujo de trabajo de la etapa de Modelado del Negocio consta de las siguientes
etapas:

Evaluar el estado del Negocio.
Análisis del Negocio.
Identificar Procesos de Negocio.
Definir y Refinar los Procesos de Negocio.
Diseño de la Realización de los Procesos de Negocio.
Evaluación.

Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Modelado del
Negocio son:

Especificación del Negocio, que incluye Visión del Negocio y Glosario de Términos.
Modelo de Casos de Uso del Negocio, que incluye Especificación de Casos de Uso, Descripción de
Actores, Diagrama de Casos de Uso e Informe del Modelo de Casos de Uso.
Modelo interno del Negocio, que incluye el Modelo de Objetos del Negocio y la Realización de los
Casos de Uso.
Informe de Evaluación.
Documento de Arquitectura del Negocio.

El Modelo de Caso de Uso de negocio es usado por:

Los stakeholders, los analistas y los diseñadores de procesos de negocio, para entender y mejorar la
manera cómo funciona el negocio y se relaciona con su ambiente.



Los analistas de sistemas y arquitectos de software, para mantener el contexto del desarrollo del
software.
El gerente del proyecto, para planificar el volumen y contenido de las iteraciones durante el
modelado de negocio y hacer el seguimiento del progreso.

2. Elementos del Modelo de Negocio
a- Unidad Organizacional
b- Paquete de Negocio
c- Diagrama de Paquete de Negocio
d- Diagrama de Caso de Uso de Negocio
e- Especificaciones de Caso de Uso
f- Diagrama de Actividad de Negocio
g- Diagrama de Objetos de Negocio

Unidad Organizacional

La unidad Organizacional es un contenedor de objetos de negocio, representa la organización

Libreria Juanito S.A
Unidad Organizacional

Paquete de Negocio

Representa las áreas de la organización.

Paquete de Negocio



Compras
Ventas

Almacen

Diagrama de Paquete de Negocio

- Representa la interrelación de las áreas con el área en desarrollo
- Muestra la dependencia de las áreas

DIAGRAMA DE PAQUETE DE NEGOCIO

Compras

Ventas

Almacen

Diagrama de Caso de Uso de Negocio

Muestra los Casos de Uso de negocio, Actores del negocio, Trabajadores del negocio y las
interacciones entre ellos para una organización.
Modela lo qué hace una compañía, quién está dentro y quién está fuera de la compañía.
Da el alcance de la organización, visualizando lo que abarca y cuáles son sus fronteras.



Elementos:

1. Actores: Agente que interactúa con determinado proceso de negocio.

- Actor de Negocio: Un actor del negocio, es cualquier persona o cualquier cosa
externa a la organización pero que obra recíprocamente con ella.
Por ejemplo, para su organización serian los clientes, sus acreedores, sus
inversionistas, o sus proveedores. Cada uno de estos actores tiene un interés en las
acciones de la empresa. Cliente
En UML se modela un actor del negocio usando la siguiente figura:
El icono representa a una persona, pero el actor de negocios no es necesariamente un
individuo. Puede representar a un grupo de personas o a una compañía

- Trabajador de Negocio:
Un trabajador de negocios es un rol dentro de la organización. Importante, los
trabajadores del negocio son roles no posiciones. Una persona puede tener
varios roles, pero una sola posición. La ventaja de diagramar roles es que estos
no cambian con demasiada frecuencia en el tiempo, las posiciones si.
En UML un trabajador de negocios se representa con el siguiente icono:
Vendedor

2. Caso de Uso de Negocio:
- Un caso del uso de negocio representa un conjunto de tareas relacionadas que
generan un resultado de valor para los actores de negocio.
- En otros términos, los casos del uso de negocio le dicen al lector lo que la
organización hace para proporcionarle el valor de negocio que los individuos
que interactúan con él esperan.
- El conjunto de los casos del uso de negocio para una organización debe
describir completamente lo que el negocio hace.
- Los casos de uso de negocio cuenta con el siguiente formato: Verbo +
Sustantivo
- En UML, se usa el siguiente icono para los casos de uso de negocio.

3. Especificaciones de un Caso de Uso de Negocio:
- Para cada caso de uso del negocio, se debe crear un cierto tipo de informe que permite saber
específicamente qué va a suceder dentro del caso del uso.
- El flujo de trabajo se puede documentar de dos formas. La más simple es crear una lista
numerada, paso a paso de qué sucede mientras que progresa el caso del uso.
- La problemática con la forma simple de escribir el flujo de trabajo, se presenta cuando
existe una gran cantidad de condiciones lógicas, lo que provoca poca claridad.
- Para solucionar este problema se pueden utilizar los Diagramas de Actividad, que nos
permiten mostrar de forma grafica los flujos de trabajo, la secuencia de los pasos y quien es
responsable de realizar cada paso.
- A cada caso de uso del negocio se le debe asociar una documentación que sigue el siguiente
formato.



4. Relaciones entre Actores: Generalización
- Es una relación entre actores de negocio que muestra que
cuando un actor “específico” (el descendiente) está
presente, todas las características (atributos, operaciones y
asociaciones) que son descritas para el actor “genérico”
(el ascendente) del cuál hereda, van a estar presentes. Persona
- Una generalización de un actor de negocio “A” a un actor
de negocio “B”, indica que una instancia de A puede
activar la misma clase de casos de uso que una instancia
de B.
- En UML, la relación de generalización se muestra de la
siguiente manera:
Natural Juridico

5. Relaciones entre Casos de Uso y Actores: Asociación Unidireccional
- Una línea de un actor de negocio a un caso del uso de negocio indica que el actor activa el
caso de uso.
- En UML, la relación de asociación se muestra de la siguiente manera:

Solicitar Credito
Cliente

Evaluar Credito
Vendedor



6. Relaciones entre Casos de Uso de Negocio:
- Include (Inclusión): una instancia del Caso de Uso origen incluye también el
comportamiento descrito por el Caso de Uso destino, en un caso de uso incluido no
interviene un determinado actor.

<<include>>
-

Caso de Uso Origen Caso de Uso Destino

Ejemplo:

Evaluar Credito
Credito

<<include>>

<<include>>

Analizar Documentos Analizar Riesgo

- Extend (extensión): el Caso de Uso origen extiende el comportamiento del Caso de Uso
destino, en un caso de uso extendido puede intervenir un determinado actor de negocio.

<<extend>>
Caso de Uso Origen Caso de Uso destino



Ejemplo:

Solicitar Prestamo
Cliente

<<extend>>
[tarjeta caducada]

Solicitar Nueva T arjeta

Ejercicio 1: Sociedad de amigos del libro

La sociedad de amigos del libro se dedica a la venta de libros a sus socios a través del teléfono. Esta sociedad
actúa como intermediario entre las editoriales y sus socios, proporcionándoles los libros que estos solicitan a
precios reducidos. La empresa está estructurada en varios departamentos, uno de los cuales se encarga de los
pedidos, almacén y el de contabilidad.

Los socios pueden realizar sus pedidos por teléfono al departamento de pedidos. En la petición se especifican
los siguientes datos: nombre del socio y el número de ejemplares solicitados por título. Previamente a la
aceptación del pedido, se verifica que el socio este registrado y que no tenga ninguna cuota vencida o pagos
pendientes. Para ello se hacen las comprobaciones oportunas y en cualquiera de estos supuestos el pedido se
rechaza (lo que se comunica al socio en el momento). Si todo es correcto se elabora la nota de pedido y pasa a
la situación de pendiente por atender.

El departamento de pedidos utiliza dos o tres veces a la semana los pedidos pendientes para generar un pedido
a las editoriales (un listado con los títulos solicitados y el número total de ejemplares de cada título). Cuando
se reciben los libros, el departamento de almacén verifica el estado del producto, si existe alguna anomalía
con el libro, este es devuelto a la editorial y esta correcto se procede a la distribución en los anaqueles, el
departamento de almacén entrega los documentos (guía y factura) de la editorial a contabilidad para ser
cancelada.

Preguntas:

Realice el diagrama de casos de uso de negocio correspondiente



Ejercicio 2: Fabrica de productos

Proceso de negocio:

1. La venta de productos comienza cuando un cliente se acerca al local de la empresa y es atendido por
un asesor de ventas que toma su pedido generando una orden de pedido, en esta orden se detalla los
datos del cliente y las características de los productos requeridos.
2. La orden de pedido es pasada al asistente de ventas, quién se encargará de llevarla al jefe de
producción en el área de producción para su análisis.
3. El pedido es revisado por el jefe de producción para que analice la factibilidad de fabricar los
productos con las características requeridas.
4. La factibilidad se basa primero en si antes se ha fabricado un producto con similares características,
en caso contrario se analiza la dificultad del producto para aceptar o negar el pedido.
5. En caso de ser factible la fabricación del producto, el jefe de producción emite una lista de la materia
prima necesaria, esta lista se le envía al operario de almacén para que revise el stock y dé un
estimado de tiempo en que la materia prima estaría disponible para su utilización, mientras que el
jefe de producción va calculando el tiempo que se tomaría para la fabricación.
6. En caso de que se pueda fabricar el producto, la información que emita el operario es necesaria para
generar el informe de evaluación.
7. Luego, el jefe de producción específica su respuesta en un informe de evaluación que contiene el
costo y la fecha de producción; este documento se envía al asesor de ventas a través de su asistente;
en caso de ser una respuesta afirmativa, también se genera una orden de producción.
8. El asesor de ventas comunica la respuesta al cliente, si es afirmativa se procede a generar una orden
de pago.
9. El cliente se acerca con la orden de pago a la caja, en donde la cajera finalmente generara un
comprobante de pago, pudiendo ser una boleta o factura
10. Termina el proceso.
Preguntas:

1. Realice el diagrama de casos de uso de negocio correspondiente.



DIAGRAMA DE ACTIVIDAD DE NEGOCIO

Es la representación de una secuencia de actividades dentro de un caso de uso de negocio. Provee una manera
grafica de documentar un caso de uso de negocio.

 Un diagrama de la actividad en una realización del caso del uso del negocio ordenar la tareas o las
actividades que logran una o más metas de negocio, que satisfacen la iteración entre los Actores
externos del negocio y los trabajadores internos del negocio.

 Se usa separadores de Línea para representar principalmente trabajadores del negocio, y de cómo
estos realizan el negocio

 los flujos del objeto se utilizan para demostrar cómo las entidades de negocio se crean y se utilizan
en un Flujo

Elementos:

1- Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.

2- Actividad de Negocio: Una actividad representa la acción que será realizada por un caso de
uso de negocio la cual es representada dentro de un ovalo.

3- Transición: Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra,
la transición es representada simplemente por una línea con una flecha en su terminación para indicar
dirección.

4- Bifurcación (decisión): Una ramificación ocurre cuando existe la posibilidad que ocurra más de
una transición (resultado) al terminar determinada actividad. Este elemento es representado a
través de un rombo.

5- Barra de Sincronización: Representa actividades paralelas.

6- Fin: El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico
de color negro sólido.

7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a
lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en
canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la
actividad.



Ejemplo 1

Ejemplo2



Ejemplo 3

Ejercicio:

1. Realizar el Diagrama de Actividades y para modelar el siguiente flujo de control:

Un cliente desea obtener una cuenta corriente a su nombre en un negocio particular. El
gerente atiende la solicitud y solicita un informe de las referencias comerciales
proporcionadas por el cliente, al centro de Referencias Comerciales. Si el gerente acepta la
solicitud, fija un monto máximo y abre la cuenta corriente solicitada. El gerente rechaza la
solicitud si: el cliente ya posee una cuenta abierta, si no tiene referencias comerciales en el
centro de Referencias Comerciales o si éste devuelve un informe negativo.

2. Realizar un Diagrama de Actividades para modelar la compra de viajes.

Una persona que desee adquirir un viaje deberá dirigirse a las oficinas de compañía aérea
correspondiente con su DNI. La secretaria de ventas de viajes de la compañía, se encarga de
recibir la documentación del cliente (pasajero).Con estos datos, la secretaria busca en el
archivo las fichas de pasajeros registrados (tendrá una ficha si anteriormente ha realizado un



viaje con la compañía). En el caso de que el cliente no posea una ficha, se la completa en el
momento. La secretaria pedirá los datos del viaje a realizar (origen, destino y fecha de
partida) e informará los costos. Una vez completados estos pasos, la secretaría verificará la
disponibilidad del viaje. En caso negativo, se ofrecerá al cliente alguna alternativa con
respecto a la fecha de partida. El cliente puede aceptar alguna de estas propuestas o bien
cancelar la operación. Si el cliente acepta, deberá suministrar sus datos de tarjeta de crédito
o bien pagar en efectivo. En el caso de que el cliente pague con tarjera, la secretaria deberá
verificar la disponibilidad del crédito para ese cliente comunicándose con el “Centro
Internacional de Crédito (C.I.C.)” quién será el que confirmará si el cliente cuenta con el
crédito correspondiente para abonar el viaje.

3. Un paciente es atendido en un Consultorio Odontológico. El paciente ingresa al consultorio,
la secretaria verifica si el paciente tiene un turno otorgado, y sólo en ese caso el mismo será
atendido. Si el paciente posee una mutual por la cual atiende el odontólogo, entrega la orden
correspondiente a la Secretaría. Si no posee mutual, debe pagar un monto fijo por la
consulta y la secretaria le entrega el recibo del pago correspondiente.

Si es la primera vez que el paciente es atendido por el odontólogo, la secretaria realiza una
historia clínica tomando sus datos personales, y luego se la entrega al odontólogo.

Una vez atendido, el odontólogo registra los datos de la consulta en la historia clínica del
paciente. En caso que sea necesario, finalizada la consulta, el odontólogo se comunica con
la secretaria para acordar un nuevo turno para el paciente.

4. Elaborar el diagrama de actividad :

El cliente envía una orden de pedido, que debe incluir la fecha de solicitud, datos del cliente
y productos solicitados. Es posible que sea un empleado del departamento comercial quien
introduzca el pedido, a petición de un cliente que realizó su pedido por teléfono o lo envió
por fax o correo ordinario al depto. comercial de la empresa.

- El empleado revisa el pedido (completándolo, si es necesario), y comienza su
procesamiento enviándolo al jefe técnico, que está encargado de su análisis.
- El jefe técnico analiza la viabilidad de cada producto del pedido por separado:

· Si el producto pedido está en el catálogo, su fabricación es aceptada.

· En caso contrario, es considerado un producto especial, y el jefe técnico estudia su
producción:

- Si es viable, la fabricación del producto especial es aceptada;

- Si no es viable, el producto especial no será fabricado.

Una vez estudiado el pedido completo, el jefe técnico...

· Informa al departamento comercial de la aceptación o rechazo de cada producto pedido;

· Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para
cada producto, a partir de una plantilla de fabricación (la estándar si el producto estaba
catalogado, o una nueva, específicamente diseñada para el producto, si éste no estaba en el



catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda pendiente de su
lanzamiento.

El comercial comunica al cliente el resultado final del análisis de su pedido.



MODELO DE ANALISIS DE NEGOCIO

El modelo del análisis de negocio describe la realización de los casos del uso del negocio en función a la
interacción entre los trabajadores del negocio y las entidades de negocio.

Sirve como abstracción de cómo los trabajadores del negocio y las entidades de negocio necesitan ser
relacionados y de cómo necesitan colaborar para realizar los casos del uso del negocio.

El propósito del modelo del análisis de negocio es describir cómo se realizan los casos del uso del negocio.

El modelo del caso del uso del negocio describe qué sucede entre los Acores de negocio y el negocio, y no
hace ninguna asunción sobre la estructura del negocio.

El modelo del análisis de negocio, define los trabajadores internos del negocio y la información que utilizan
(las entidades de negocio), describen su organización estructural en las unidades independientes (sistemas del
negocio), y definen cómo obran recíprocamente para realizar el comportamiento descrito en los casos del uso
del negocio.

El analista del negocio es responsable de la estructura y de la integridad del modelo, mientras que los
diseñadores del negocio son responsables de detallar elementos dentro del modelo.

El modelo también es utilizado por los analistas de sistemas para derivar requisitos del software, basados en
cómo el sistema de software será utilizado como parte de los procesos del negocio. Los arquitectos del
software utilizan el modelo para definir una arquitectura del software que para la organización y para
identificar clases en modelos del análisis y del diseño del software

Elemnetos:

1- Bussiness Enty o Entidad de Negocio: ente manipulado por los trabajadores de negocio,
representa el lugar donde se almacena o consulta datos de forma manual.

2- Bussiness Worker o trabajador de negocio: rol o roles dentro del proceso de negocio que
manipula las entidades de negocio.

3- Business use case realization o Realizacion de Caso de Uso de Negocio

4- Diagrama de Actividad de Negocio
5- Diagrama de Objetos de Negocio: Representa las responsabilidades de los trabajadores de negocio
con respecto a las entidades de negocio y las relaciones entre las mismas entidades de negocio.
6- Diagrama de colaboracion de negocio



Ejemplo de daigrama de objetos de negocio:



FASE
DE
ELABORACION
1- Diagrama de Paquete de Sistema
2- Modelo de Caso de Uso (Modelo de Requisitos)
a- Diagrama de caso de uso
b- Diagrama de Actividad
c- Especificaciones de caso de uso
3- Prototipos (interfaz de usuario)



1- DIAGRAMA DE PAQUETE DE SISTEMA

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra como un sistema está dividido en
agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete
está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía
lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y
minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes
son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las
dependencias entre ellos pueden indicar el
orden de desarrollo requerido.

2- MODELO DE CASO DE USO

El Modelo de Casos de uso es un modelo que
describe los requerimientos funcionales del
sistema en forma de Casos de uso.
En UML los Casos de Uso son los principales
medios para capturar la funcionabilidad del
sistema desde la perspectiva del usuario y
muchas veces puede reemplazar al documento
“requisitos funcionales”

a- Diagrama de Caso de Uso:
Un diagrama de Casos de Uso muestra
las distintas operaciones que se
esperan de una aplicación o sistema y
cómo se relaciona con su entorno
(usuarios u otras aplicaciones).
El diagrama de casos de uso
representa la forma en cómo un
Cliente (Actor) opera con el sistema
en desarrollo, además de la forma, tipo
y orden en como los elementos
interactúan (operaciones o casos de
uso).
Secuencia de transacciones desarrolladas por un sistema en respuesta a un evento iniciado por un
actor
Sirven para especificar la funcionalidad y el Comportamiento de un sistema
Un diagrama de caso de uso muestra las relaciones entre actores y casos de uso dentro del sistema
Un caso de uso es una unidad coherente de una funcionalidad provista por el sistema (o una clase)

Elementos:

Caso de Uso: es una representación de una unidad discreta de trabajo realizada por un usuario usando el
sistema en operación. Se ejecuta en su totalidad o no se ejecuta nada, devolviendo algo de valor al
usuario.

Es una operación/tarea específica que se realiza tras una orden de algún agente interno, sea desde una
petición de un actor o bien desde la invocación desde otro caso de uso.



Actor: Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es
importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente
representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Relación: Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representa
simplemente con una línea). Relacion entre casos de uso : Include y Extend

b- Diagrama de actividad de sistema
El diagrama de actividad muestra el orden en el que
se van realizando tareas dentro de un sistema.
Los diagramas de actividad describen la secuencia
de las actividades en un sistema.

Elementos:

1- Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido.

2- Actividad de Sistema: Una actividad representa la acción que será realizada por un caso de uso
de negocio la cual es representada dentro de un ovalo. actividad

3- Transición: Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra, la
transición es representada simplemente por una línea con una flecha en su terminación para indicar
dirección.

4- Bifurcación (decisión): Una ramificación ocurre cuando existe la posibilidad que ocurra más de una
transición (resultado) al terminar determinada actividad. Este elemento es representado a través de
un rombo.



5- Barra de Sincronización: Representa actividades paralelas.

6- Fin: El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico
de color negro sólido.

7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a
lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en
canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la
actividad.

c- Especificaciones de Caso de Uso: cuenta con el siguiente formato.

1- Nombre del Caso de Uso
1.1- Descripcion
2- Flujo de Eventos
2.1- Flujo Basico
2.2- Flujos Alternativos
2.2.1- Flujo alternativo
2.2.2- Otro flujo alternativo
3- Precondiciones
3.1- Una Precondicion
3.2- Otra precondicion
4- Poscondiciones
4.1- Una poscondicion
4.2- Otra poscondicion

Ejemplo de especificaciones de caso de uso:

Especificación de Caso de Uso

1- Registrar Producto
1.1 Breve Descripción
Permite al jefe de almacén tener una gestión de productos para luego poder adminístralos en el
funcionamiento de nuestro sistema, el jefe de almacén podrá crear, editar y eliminar producto(s)
según sea el criterio de la empresa.

2- Flujo de Eventos
2.1 Flujo Básico
El sistema muestra la interfaz “Gestionar Producto” con los criterios de búsqueda que son los
campos: código, modelo, marca, nombre producto, categoría además de las opciones buscar, editar,
nuevo, eliminar.

2.1.1- Crear Producto
1. El caso de uso comienza cuando el Jefe de Almacén solicita” Nuevo” en la interfaz Gestión
Productos.
2. El sistema muestra la interfaz “Crear Producto”.
3. El Jefe de Almacén selecciona Categoría (partes y piezas, periféricos y accesorios y suministros)



4. El sistema retorna lista de tipo de Producto en base a la categoría.
5. El jefe de Almacén selecciona Tipo de Producto (según la categoría).
6. El sistema retorna lista de marcas en base al Tipo de producto.
7. El jefe de almacén selecciona marca.
8. El jefe de Almacén ingresa Modelo.
9. El jefe de Almacén Ingresa Una breve descripción.
10. El jefe de Almacén elige la opción de Grabar para guardar el nuevo Producto Creado.
11. El Sistema Guarda registro nuevo del producto ingresado.
12. El Sistema genera mensaje de confirmación de creación de producto.
13. El sistema regresa a la interfaz de Gestión de Producto.

2.1.2- Editar Producto
1. El jefe de almacén ingresa el criterio de búsqueda del producto en la interfaz Gestión de
Productos.
2. El jefe de almacén selecciona el botón “Buscar”
3. Se ejecuta el caso de uso extendido Buscar Producto
4. El sistema muestra el producto(s) y sus datos en una tabla en la interfaz de Gestión Producto
5. El jefe de almacén presiona “editar” en el producto que desea modificar.
6. El sistema muestra la interfaz Editar producto
7. El jefe de almacén modifica los datos del producto según criterio
8. El jefe de Almacén selecciona grabar
9. El sistema guarda los datos modificados y genera un mensaje “Actualización Completada”
10. El Jefe de almacén presiona “Aceptar”
11. El Sistema regresa a la interfaz Gestión de Productos.
2.1.3- Eliminar Producto
1. El jefe de almacén ingresa el criterio de búsqueda del producto en la interfaz de Gestión de
productos.
2. El jefe de almacén selecciona buscar
3. Se ejecuta el caso de uso extendido Buscar Producto
4. El sistema muestra el producto(s) y sus datos en una tabla en la interfaz de Gestión Producto
5. El Jefe de almacén selecciona el producto(s) que desea eliminar presionando en el checkbox
correspondiente.
6. El Jefe de almacén presiona el botón “Eliminar”
7. El sistema muestra mensaje “Seguro que desea eliminar el producto(s) seleccionado(s) de la lista”



8. El jefe de Almacén confirma presionando el botón Aceptar
9. El sistema elimina el producto(s) seleccionado de la base de datos
10. El sistema limpia los campos del producto
2.2- Flujos Alternativos
2.2.1- < Error falta ingresar datos obligatorios >
En el punto 10 del crear producto, cuando el usuario selecciona guardar sin haber llenado todos los
campos requeridos, el sistema muestra un mensaje de error “Falta llenar campos” y lo retorna al la
interfaz Crear Producto.
2.2.2- <No coloca criterio de búsqueda>
Si en editar producto y eliminar producto el jefe de almacén presionar buscar sin ingresar un criterio
de búsqueda, el sistema mostrara en la tabla todos los productos ingresados hasta el momento

2.2.3 <Error no seleccionar producto>
En el punto 6 de eliminar producto, cuando el usuario selecciona eliminar sin haber seleccionado el
producto, el sistema muestra un mensaje de erro “Falta seleccionar producto a eliminar” y lo retorna
a la interfaz eliminar producto.
3- Precondiciones
3.1- El Jefe de Almacén tiene que estar logeado en el sistema
3.2- Que existan productos ingresados a la base de datos
4- Pos condiciones
4.1- El sistema ha actualizado la lista de productos
Ejemplo de especificaciones de Caso de Uso

Especificación de Caso de Uso

1- Gestión de Clientes
1.1- Descripción
Este caso de uso resume la utilidad de alta, baja y modificación de los datos registrados en la base de
datos de la plantilla de clientes que tiene la empresa. El usuario de ventas, ya sea representante de
ventas, operadora o cliente on-line, podrá acceder a los datos correspondientes a cada uno y realizar
modificaciones. Los representantes de ventas solamente pueden modificar o eliminar clientes que
estén asociados a los mismos, y el alta asociará automáticamente al cliente con dicho representante.
Los clientes on-line solo podrán modificar datos propios, eliminarse como clientes o darse de alta
como uno nuevo sin que dé lugar a repeticiones. Por último, la operadora podrá modificar, dar de
alta o eliminar cualquier cliente.
2- Flujo de Eventos
Flujo Básico
1. El Usuario de Ventas puede seleccionar dar de alta un nuevo cliente, pasar al punto 2; dar de baja un
cliente, pasar al punto 3; modificar datos de un cliente, pasar al punto 4.
2. El Usuario de Ventas solicita el alta de un nuevo cliente.
2.1. El sistema muestra los campos de datos necesarios a introducir; los campos a rellenar son: DNI/CIF,
Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono, E-mail y Cuenta Bancaria.
2.2. El Usuario de Ventas pulsa el botón introducir datos. Pasar al punto 5.
3. El Usuario de Ventas solicita la baja de un cliente.
3.1. El sistema muestra el campo DNI/CIF a introducir necesario para la baja.
3.2. El Usuario de Ventas introduce el DNI/CIF del cliente que desea eliminar y pulsa “entrar”.



3.3. El sistema muestra los campos de los datos del cliente que se ha solicitado para la baja.
3.4. El Usuario de Ventas pulsa el botón borrar de su interfaz gráfica.
3.5. El sistema genera un mensaje de aviso de borrado y solicita la confirmación de la eliminación.
3.6. El Usuario de Ventas puede confirmar la eliminación del cliente pulsando el botón Aceptar, o bien
puede cancelar el borrado pulsando el botón Cancelar. Pasar al punto 5.
4. El Usuario de Ventas solicita la modificación de datos de un cliente.
4.1. El sistema muestra el campo DNI/CIF a introducir necesario para la modificación. El sistema
muestra los datos del cliente que se ha solicitado para la modificación.
4.2. El Usuario de Ventas puede modificar cualquiera de los datos de los campos mostrados por el
sistema, éstos son: DNI/CIF, Nombre, País, Provincia, Localidad, Dirección, Código Postal,
Teléfono, E-mail y Cuenta Bancaria.
4.3. El Usuario de Ventas puede solicitar guardar los datos modificados pulsando el botón Modificar de
la interfaz gráfica.
4.4. El sistema genera un mensaje de aviso de modificación y solicita la confirmación de la misma.
4.5. El Usuario de Ventas puede confirmar la modificación del cliente pulsando el botón Aceptar, o bien
puede cancelar el borrado pulsando el botón Cancelar. Pasar al punto 5.

Flujos Alternativos
En el punto 2.2
El sistema comprueba que los datos del nuevo cliente, DNI/CIF no se corresponden con ningún otro cliente de
la base de datos. En caso afirmativo, generará un mensaje de error comunicando que dicho cliente ya está
dado de alta en la base de datos. El sistema comprueba que se han introducido todos los datos restantes, en
caso de que no se hayan introducido datos en los campos Nombre, País, Provincia, Localidad, Dirección,
Código Postal, Teléfono y Cuenta Bancaria, el sistema generará un mensaje de error

3- PROTOTIPO O INTERFAZ DE USUARIO

Esta es una de las partes más importantes de cualquier programa ya que determina que tan fácilmente es
posible que el programa haga lo que el usuario quiere hacer. Un programa muy poderoso con una interfaz
pobremente elaborada tiene poco valor para un usuario no experto.

La elaboración de una interfaz de usuario, bien diseñada, exige una gran dedicación pues generalmente
las interfaces son grandes, complejas y difíciles de implementar, depurar y modificar. Hoy en día las
interfaces de manipulación directa (también llamadas interfaces gráficas de usuario, GUI por sus siglas
en inglés) son prácticamente universales. Las interfaces que utilizan ventanas, íconos menú se han
convertido en estándar en los materiales computacionales.

Ejemplo de interfaz de usuario:



Hotel

El dueño de un hotel nos pide desarrollar un programa para consultar las habitaciones disponibles y poder
reservar habitaciones en su hotel.

El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habituales
y esporádicos. Una reserva almacena datos del cliente, de la habitación reservada, la fecha de
comienzo y el número de días que será ocupada la habitación.

El recepcionista del hotel debe poder hacer las siguientes operaciones:

 Obtener un listado de las habitaciones disponible de acuerdo a su tipo.

 Preguntar por el precio de una habitación de acuerdo a su tipo.

 Preguntar por el descuento ofrecido a los clientes habituales.

 Preguntar por el precio total para un cliente dado, especificando su número de reserva, tipo de
habitación y número de noches.

 Dibujar en pantalla la foto de una habitación de acuerdo a su tipo.

 Reservar una habitación especificando el número de la pieza, reserva y nombre del cliente.

 Eliminar una reserva especificando el número de la habitación.

El administrador puede usar el programa para:

 Cambiar el precio de una habitación de acuerdo a su tipo.

 Cambiar el valor del descuento ofrecido a los clientes habituales.

 Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen
treinta días).



El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a su vez
permitir agregar nuevas consultas.

Obtener el diagrama de casos de uso.



FASE
DE
CONSTRUCCION
1- Modelo de Análisis
a- Caso de Uso Análisis
b- Clase Análisis
- Clase Boundary
- Clase Control
- Clase Entidad
c- Diagrama de Colaboración Clase Análisis
d- Diagrama de Secuencia Clase análisis
2- Modelo de Datos (Data Modeler Diagram)



1- MODELO DE ANALISIS
- El modelo de análisis es una especificación detallada de los requerimientos y trabajos.
- Lo usan los desarrolladores para entender los casos de uso, refinándolos como
colaboraciones entre clasificadores conceptuales.
- El modelo de análisis se usa para crear un sistema robusto con reuso considerable de
componentes
- El modelo de análisis es un modelo conceptual y no un proyecto de la implementación.
- Especificación detallada (precisa) de requisitos.
- Refina los casos de uso como colaboraciones entre clasificadores:
Clasificadores: clases de análisis, paquetes.
Colaboraciones: realizaciones de los casos de uso.

MODELO DE CASO DE USO MODELO DE ANALISIS
Se describe utilizando el lenguaje del cliente Se describe utilizando el lenguaje del programador
Vista externa del sistema Vista interna del sistema
Estructurado por casos de uso Estructurado por clases y paquetes
Se usa primariamente como un contrato Se utiliza principalmente por los
entre el cliente y desarrolladores, determina desarrolladores para entender QUE hará el
QUE hará el sistema y se decide si el sistema y plantear interacciones que
sistema se llevará a cabo o no comiencen a definir el COMO

Puede contener redundancias e Se reducen considerablemente las
inconsistencias redundancias e inconsistencias

Captura las funcionalidades del sistema Refina y describe la forma en que se
realizarán las funcionalidades del sistema

Define los CASOS DE USO y a futuro Define REALIZACIONES DE CASOS DE
serán analizados en el Modelo de Análisis USO, donde cada uno representa el análisis
de un caso de uso particular

2- ARTEFACTOS DEL ANALISIS

a- CLASES DE ANALISIS: representan una abstracción de una o varias clases y/o subsistemas en
el diseño del sistema.
b- REALIZACIONES DE CASOS DE USO: descripción de la realización de cada caso de uso en
término de clases de análisis y la interacción entre objetos de análisis.
c- PAQUETES DE ANALISIS: permiten organizar el modelo de análisis en piezas manejables.
Pueden contener realizaciones de casos de uso, clases de análisis y otros paquetes de análisis.
d- DESCRIPCIÓN DE LA ARQUITECTURA: vista arquitectónica del Modelo de Análisis mostrando
sus artefactos más significativo

3- ACTIVIDADES DEL ANALISIS
a- ANALIZAR CADA CASO DE USO
- Identificar Clases de Análisis _ UML- Diagrama de Clases
- describir la interacción entre objetos de análisis
- UML -Diagrama de Colaboración, descripción Textual
- Capturar requerimientos especiales
b- ANALISIS ARQUITECTONICO



- Realizar un bosquejo del modelo de análisis identificando los paquetes de análisis, clases de
análisis y requerimientos especiales más importantes.

c- ANALIZAR PAQUETE
- Agrupar clases en paquetes cuando es necesario.
- Asegurar que cada paquete de análisis es lo más independiente posible de otros.
- Asegurar que cada paquete de análisis satisface su propósito de realización de ciertas clases
y casos de uso.
d- ANALIZAR CADA CLASE DE ANALISIS
- Asignar un nombre, Identificar Atributos, Identificar relaciones.
- Identificar Responsabilidades: compilación de todos los roles que la clase juega en todas las
realizaciones de casos de uso.
- Capturar requerimientos especiales.

4- TIPOS DE CLASE DE CLASES DE ANALISIS
a- CLASES LIMITE (Boundary class o interfaz):
- Modelan interacción entre el sistema y sus actores.
- Clarifican los requisitos en la frontera entre sistema y usuarios. Cambios en los
interfaces de usuario, de comunicación, etc.
afectan a las clases frontera.
- Representan abstracciones de ventanas,
formularios, sensores, terminales y APIs
(Application Program Interfaces).
- Deben estar asociados a un acto.

b- CLASES ENTIDAD (Entity class):
- Modelan información persistente.
- Las clases entidad muestran la estructura lógica de los datos

c- CLASES CONTROL (Control class):
- representan coordinación, secuencia miento, transacciones y control de objetos.
- Buscar una información concreta de una clase conociendo alguno de los valores de sus
atributos
- Crear/modificar/eliminar información
- Realizar procesos/cálculos relacionados con la lógica del negocio
- No pueden conectarse directamente con los actores



Ejemplo

Caso de Uso: INSERTAR CLIENTE
Precondición: existe un cliente para ser ingresado al sistema.
Pos condición: se registra el nuevo cliente en el sistema o el cliente ya estaba cargado.
FLUJO DE EVENTOS PRINCIPAL
Secretaria Sistema
1. Ingresa el DNI del cliente. 2. Chequea existencia.
3. Ingresa nro socio, nombre, teléfono y localidad 4. Include (buscar localidad)
5. Carga al nuevo cliente.
FLUJO DE EVENTOS ALTERNATIVOS
2.1. El cliente ya existe, el sistema informa tal situación y termina el caso de
uso.
4.1. La localidad ingresada no existe, debe ingresar una localidad existente.

SOLUCION:

1- Clase Análisis:

IU_Cliente Cliente
Ctrl_Cliente

2- Diagr
ama de Clase Análisis y Diagrama de Colaboración

IU_Cliente Ctrl_Cliente Cliente

Ctrl_Localidad



4: Ingresar otros datos 5: Enviar Datos

1: Ingresar DNI 2: Chequear DNI

7: Guardar Nvo Cliente
: Secretaria : IU_Cliente : Ctrl_Cliente

3: Obtener Cliente

6: Buscar localidad

: Cliente
: Ctrl_Localidad

3- Atributos y responsabilidades de la clase
Atributos: DNI, nombre, teléfono,
nrosocio. Localidad??
Responsabilidades:brindar y
mantener guardada los datos del
cliente. (set y get).

: Cliente

Atributos: ??.
Responsabilidades: recibir los datos
ingresados por el usuario. Chequear
formato de los datos ingresados.
: IU_Cliente
Mostrar resultados al usuario.

Atributos: ??.
Responsabilidades: chequear la
existencia del cliente, enviar datos
para ser guardados, buscar la
: Ctrl_Cliente localidad ingresada.



4- Diagrama de Secuencia

: Cliente : Ctrl_Cliente : Ctrl_Localidad : IU_Cliente : Secretaria

1. Ingresar DNI

2. Chequear DNI

3. Obtener Cliente

4. Ingresar otros datos

5. Enviar Datos

6. Buscar localidad

7. Guardar Nvo Cliente

5- REALIZACION EN ANALISIS DE LOS CASOS DE USO
- Es una colaboración que describe cómo se realiza en análisis un caso de uso en términos de
clases de análisis y sus interacciones.
- Es una colaboración que indica cómo se realiza/ejecuta un caso de uso.
- La realización en análisis de un caso de uso, incluye:
a- diagramas de clases: clases participantes
b- diagramas de interacción: escenarios del CU.
c- descripción textual del flujo de eventos
d- nada de requisitos no funcionales (hasta el diseño).



Modelo de Caso de Uso Modelo de Analisis

Use Case Realizacion en analisis

6- DIAGRAMA DE CLASE
- Una clase de análisis puede participar en varios casos de uso.
- Algunas responsabilidades, atributos y asociaciones suelen ser específicos de un sólo caso
de uso.

7- DIAGRAMA DE INTERACCION
- La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a
una clase límite.
- Se van a utilizar diagramas de colaboración.
- Ejemplo: Caso de uso “Publicar notas” del actor “Profesor”.



Ejemplo: ANALISIS DE CASO DE USO: SACAR DINERO



FASE
DE
TRANSICION
3- Modelo de Diseño

e- Diseño de Caso de Uso
f- Diagrama de Clase
- Elementos
- Relaciones
- Multiplicidad
g- Diagrama de Clase Interfaz
h- Diagrama de Clase Entidad
i- Diagrama de Colaboración
j- Diagrama de Secuencia

4- Modelo Implementación

a- Diagrama de Despliegue
b- Diagrama de Componentes

5- Modelo de Prueba

a- Especificaciones de caso de Prueba



MODELO DE DISEÑO

1- Concepto
El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el
propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para
permitir su interpretación y realización física.
La Fase de diseño (y los modelos UML resultantes expande y detalla los modelos de análisis
tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es
especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y
construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis
fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos,
interfaz de usuario, comunicación, dispositivos, etc.
La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del
diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar
con precisión los requerimientos del cliente.
El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un
conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema
a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un
conjunto de revisiones técnicas:
El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y
debe acumular todos los requisitos implícitos que desea el cliente.
Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y
mantienen el Software.
El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los
dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación.



2- Diseño de Caso de Uso

El principal objetivo de esta etapa es refinar las realizaciones de los casos de uso a través de nuevas
iteraciones en el proceso. Además, también se debe refinar el modelo de diseño y los requisitos de
las operaciones de las clases de diseño.
Esta actividad es básicamente el centro del proceso de creación del modelo de diseño, en el que se
irán refinando, iteración a iteración, el diseño de los casos de uso y de las operaciones obtenidas a
partir de ellos, que aparece plasmado en el modelo de clases de diseño.
Este Modelo de Diseño se reflejará en Diagramas de Clases de Diseño donde aparecerán las clases
de diseño utilizadas para realizar los casos de uso, los atributos de estas clases, las operaciones de las
mismas y las relaciones existentes entre ellas.
Dentro de esta actividad se realizarán las siguientes acciones:

Refinar las realizaciones de casos de uso ya realizadas en iteraciones anteriores.
Describir las interacciones entre los objetos de diseño.
Simplificar diagramas de secuencia haciendo uso de subsistemas. Estos serán descritos en la
siguiente actividad de esta fase.
Refinar el modelo de comportamiento de los casos de uso y la descripción del flujo de eventos.
Unificar las clases de diseño y los subsistemas que aparecerán en la solución diseñada.
Continuamente se deberá completar y evaluar el modelo de diseño (clases de diseño) que se
modificará a lo largo de esta actividad.

Caso de Uso Realizacion Caso de Uso realizacion Diseño

3- Diagrama de Clase

Los diagramas de clases muestran un resumen del sistema en términos de sus clases y las
relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactúa, pero no
cómo interactúa o qué pasa cuando ocurre la interacción.
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de agregación.
El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir
los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos
del sistema o de un modelo de programación.
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema
mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son
utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño
conceptual de la información que se manejará en el sistema, y los componentes que se
encargaran del funcionamiento y la relación entre uno y otro.



Elementos del Diagrama de Clase

Clase:
- Una clase refiere genéricamente a los objetos de una familia que se perciben con
propiedades y comportamiento comunes.
- Es la unidad básica que encapsula toda la información de un Tipo de
Objeto (un objeto es una instancia de una clase).
- Un objeto es algo distinguible que percibimos como que tiene
existencia, sea física o conceptual.
- Objeto: Es una instancia de una clase. Ejemplo: Zapato mocasín.
- En UML, una clase es representada por un rectángulo que posee tres
divisiones:
- Nombre: Cada clase debe tener un nombre que la distinga de otras
clases.
- Atributo: representa alguna propiedad de la clase, que se encuentra
en todas las instancias de la clase.
- definen la estructura de una clase y de sus correspondientes objetos.
- Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos.
- Dentro de una clase, los nombres de los atributos deben ser únicos (aunque puede aparecer
el mismo nombre de atributo en diferentes clases).
- En el momento de incluir atributos en la descripción de una clase se debe distinguir entre
los atributos los cuales reflejan las características de los objetos en el mundo real, y los
identificadores los cuales son utilizados
- exclusivamente por razones de implementación. Estos identificadores internos del sistema
no deben ser incluidos como atributos.

- Operaciones o Métodos: Las operaciones son funciones o transformaciones que se aplican
a todos los objetos de una clase particular. La operación puede ser una acción ejecutada por
el objeto o sobre el objeto.



- Visibilidad en los atributos:

a- Public (+, ): Indica que el atributo será visible tanto dentro como fuera de la
clase, es decir, es accesible desde todos lados.

b- Private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase
(sólo sus métodos lo pueden acceder).

c- Protected (#, ): Indica que el atributo no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de las subclases que se
deriven (herencia).

- Visibilidad en el Método

a- Public (+, ): Indica que el método será visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.

b- Private (-, ): Indica que el método sólo será accesible desde dentro de la clase
(sólo otros métodos de la misma clase lo pueden acceder).

c- Protected (#, ): Indica que el atributo no será accesible desde fuera de la clase,
pero si podrá ser accesado por métodos de la clase además de las subclases que se
deriven (herencia)


Metodologia rup

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Metodologia rup

Similar a Metodologia rup (20)

Metodologia rup