NURY ANDREA MARTINEZ PEÑUELA

MODELADO DE SISTEMAS

IMPELEMENTACION ETAPAS METODOLOGIA RUP

UNIPANAMERICANA

INGENIERIA DE SISTEMAS
 INTRODUCCION

En el presente trabajo muestra el trabajo realizado en el curso de modelado de sistemas de Ingeniería de

Sistemas, proyecto que quiere mostrar la metodología RUP en el estudio del caso de Taxis de la empresa
de don Rómulo. La empresa no cuenta con un sistema informático acorde a sus necesidades y lleva por
intermedio de papel todos sus registros. La idea principal es elaborar un sistema que permita tener un
control de la flota, por medio de dispositivos móviles, y que también permita gestionar la flota con una
aplicación web.

Demos entonces una pequeña definición de la metodología RUP Es un proceso de ingeniería

de software. Provee un ciclo de vida con las disciplinas para el desarrollo de sistemas
informáticos. Tecnología orientada a objetos.
 OBJETIVOS

El objetivo del proyecto es desarrollar un prototipo de sistema para la gestión de servicios de radio taxis
utilizando tecnologías web, móviles y geoposicionamiento satelital.

Investigar todas de las tecnologías necesarias para realizar del prototipo Web, Web móvil y sistema de
seguimiento (GPS).

Recabar toda la información del cliente objetivo, su forma de trabajo e identificar sus falencias.

Elaborar una solución que permita mejorar la forma de trabajo de este tipo de empresas, así como
también la correcta integración de las tecnologías utilizadas.

Desarrollar un prototipo funcional que sea capaz de administrar una empresa de radio taxis.

Evaluar la solución propuesta mediante pruebas de software.

 FLUJOS DE TRABAJO PORPUESTOS PARA LA EMPRESA

PASOS:

Recepción del pedido: Aquí el recepcionista se encarga de verificar el tipo de llama si esta para: realizar
un pedido, modificar un pedido o para cancelar.

Realizar pedido. Se capturan los datos tanto como del cliente como del pedido que desea realizar, en
caso de que el cliente no esté registrado se registra.

Registran datos. Se registrará el tipo del pedido, se le asigna un vehículo. Este último ya se encuentra
con un conductor asignado.

Despacho del móvil. En este punto encontramos dos casos posibles.

• El primero de ellos es que el móvil salga directamente de la central al origen de cliente

• Bien seria cuando el conductor tiene que terminar un pedido en curso para acudir al nuevo

Modificar un pedido. En este caso el cliente debe tener un pedido relacionado, al cual le desee modificar
un campo.

Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o bien por el ID del pedido.

Se modifican. Los datos del pedido a decisión del cliente.

Guardado. De los nuevos datos del pedido

Cancelación de pedido. El cliente quiere cancelar una reserva realizada anteriormente.

Búsqueda. La búsqueda del pedido se realiza mediante Rut del cliente o bien por el ID del pedido.

Eliminación. Se elimina el pedido.

PASOS PARA MANEJO DE WEB

Descripción de los pasos:

Loguin. El Cliente al ingresar a la Sucursal Virtual debe identificarse.

Realizar pedido. Se capturan los datos tanto como del cliente como del pedido que desea realizar, en caso
de que el cliente no esté registrado se registra.

Registran datos. Se registrará el tipo del pedido, se le asigna un vehículo. Este último ya se encuentra con
un conductor asignado.

Confirmación. Luego de confirma se le entrega el ID del pedido al cliente.

No Registrado. Se debe registrar el cliente para realizar el pedido

Registrar. Se registra el cliente, capturando sus datos, luego se direcciona al Loguin.

Cancelar. No desear registrarse

 SISTEMA A IMPEMENTAR

Diseño e implementación de un sistema que nos permita gestionar una empresa de radio taxis, desde la
entrada de un pedido hasta que el servicio allá concluido. Todo esto implementando una aplicación web,
una web móvil, además de contar con un sistema de seguimiento por cada automóvil que pertenezca a la
empresa.

TAREAS POR REALIZAR EN EL SISTEMA:

Gestión Pedidos Para los pedidos van a existir 3 formas de realizar un pedido, con esto pretendemos darle
al cliente una mayor diversidad a la hora de necesitar un móvil:

Internet. El cliente deberá entregar una serie de datos personales como del pedido, el administrador será
avisado automáticamente de que hay un pedido vía internet y este estará a cargo de dar de alta el pedido,
avisándole oportunamente al cliente. La ventaja que ofrece este módulo será que el cliente podrá reservar
con una mayor cantidad de tiempo su radio taxi.

Internet móvil: Estará enfocado al cliente que cuente con un dispositivo móvil con capacidad de navegar
por internet, por lo que se creará un módulo dedicado para el pedido por este tipo de dispositivos, su
funcionamiento será igual al de vía internet. La ventaja que nos entregará este tipo de pedido será captar
al cliente que no puede realizar un pedido telefónico y no se encuentra cerca de un computador.
Vamos a asignar estado a los pedidos de los usuarios:

• Pedido Activo: Esto quiere decir que el servicio se encuentra en curso, ya se encuentra con un
cliente y un vehículo asignado.
• Pedido Reservado: El pedido no se ha realizado y no tiene asignado un automóvil, el sistema para
este tipo de pedidos deberá entregar una alerta cuanto este próximo a cumplirse fecha y/u hora
del pedido
• Pedido Terminado: Este tipo de pedido tendrá información de que automóvil lo realizo y su costo

Gestión o seguimiento de Flota:

Para la gestión de la flota se creará un módulo donde el administrador pueda llevar un registro de todos
los automóviles que componen la flota, donde se podrá ver el estado en que se encuentra cada vehículo
(operativo o en mantención), los conductores que tienen asignados, datos propios de cada uno (patente,
revisión técnica, capacidad) además de un detalle de la última reparación que se le realizó a cada vehículo.

Seguimiento satelital:

Cada automóvil contará con un sistema GPS, con el cual se podrá conocer la posición actual de cada uno
de éstos, lo que permitirá asignar el automóvil que se encuentre más próximo a un nuevo cliente
Conductores:

Se creará un registro de cada conductor que trabaje en la empresa, con todos sus datos personales y con
los viajes que allá realizado en un periodo de tiempo, además de tener una bitácora de observaciones.
Los conductores serán ingresados previamente por el administrador a cargo.

Responsabilidad del administrador:

Se creará un registro de administrador, con todos los datos personales, el cual gestionará los choferes, la
flota, recepcionistas y nuevos administradores. Se creará un administrador root para poder utilizar por
primera vez el sistema.

Recepción:

Se creará un registro recepcionista, con todos los datos personales, los permisos que se le otorgarán serán
la gestión de los pedidos y de los clientes. Un recepcionista deberá ser registrado por un administrador
para poder utilizar el sistema.
Usuario Final:

Se confeccionará un registro de cada cliente, de sus últimos pedidos, si necesita algún tipo de atención
especial (para personas con capacidades especiales). Un cliente deberá registrarse en el sistema si desea
hacer un pedido vía internet e internet móvil.

METODOLOGIA ORIENTADA A OBJETOS

Abstracción: Expresa las características esenciales de un objeto, las cuales distinguen al objeto de los
demás.

Encapsulamiento: Se denomina encapsulamiento al ocultamiento de los datos miembro de un objeto, de

manera que sólo se puede cambiar mediante las operaciones definidas para ese objeto

Herencia: La herencia permite definir nuevas clases a partir de otras clases ya existentes, de modo que
presenten las mismas características y comportamiento de éstas, así como otras adicionales.

Polimorfismo: El polimorfismo es la propiedad en la que una función que tiene el mismo nombre en
diferentes clases se ejecuta de forma diferente en cada clase.
 ARQUITECTURA

Se ocupará la arquitectura de 3 capas, la cual es una especialización de la arquitectura cliente-servidor

donde la carga se divide en tres partes con un reparto claro de funciones: una capa para la presentación,
otra para el cálculo y otra para el almacenamiento.

Presentación: Esta capa se comunica únicamente con la capa de negocio. También es conocida como
interfaz gráfica y debe tener la característica de ser entendible y fácil de usar para el usuario.

Negocio: Se denomina capa de negocio o lógica del negocio porque es aquí donde se establecen todas las
reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes
y presentar los resultados, y con la capa de datos.

Capa de datos: Aquí es donde residen los datos y es la encargada de acceder a los mismos. Está formada
por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben
solicitudes de almacenamiento o recuperación de información desde la capa de negocio.
Su enfoque principal es implementar interfaces de usuario.

• No todas las peticiones de la aplicación necesitan un modelo o una vista.

• Los elementos que se carguen dependen del tipo de petición y recursos que se requieran.

• Un controlador puede servir sólo para alternar el estado de una aplicación, o para retornar información
no analizada directamente desde un servicio de terceros.

HERRAMIENTAS DE OFIMATICA A UTILIZAR:

Microsoft Word. Es un programa editor de texto ofimático, permite crear documentos sencillos o
profesionales. Es el más popular en su estilo.

Microsoft PowerPoint: Es un programa que permite hacer presentaciones, y es usado ampliamente los
ámbitos de negocios y educacionales.

StarUml: Software gratuito, que permite confeccionar distintos tipos de diagramas y UML.

DIA: Software gratuito, que también permite el manejo de diagramas y uml. Utilizado para resolver las
falencias del anterior.
Flujos de trabajo: La enumeración de roles, actividades y artefactos no define un proceso, necesitamos
definir la secuencia de actividades realizadas por los diferentes roles, así como la relación entre los
mismos, que nos producen unos resultados observables. El RUP define varios flujos de trabajo distintos,
entre los que distingue entre dos grupos, los de proceso, y los de apoyó. Las distintas iteraciones que
realizar consistirán en la ejecución de estos flujos de trabajo con una mayor o menos intensidad.

FASES:
FASE DE INCEPCION:

En esta fase se establece el caso del negocio para el sistema y se delimita el alcance del proyecto. Para
lograrlo, es necesario identificar todas las entidades eternas con las que el sistema va a interactuar
(actores) y se define la naturaleza de esta interacción a alto nivel. Lo que implica identificar todos los casos
de uso y describir algunos (los más significativos). El caso de negocio incluye criterio de éxito, evaluación
de riesgos y estimación de recursos necesarios, y un plan de fase que muestre las fechas de las etapas
principales. Al final de la fase de incepción, los entregables son generalmente:

• Documento de visión: Visión general de requerimientos, características clave y restricciones principales.

• Modelo de casos de uso inicial

• Glosario de proyecto inicial

• Caso de negocio Inicial: Incluye contexto del negocio, criterio de éxito (proyección de ingresos,
reconocimiento de mercado, entre otros) y pronóstico financiero

• Evaluación de riesgos inicial

• Plan del proyecto que muestre fases e iteraciones

• Modelo de negocio, en caso de ser necesario

• Uno o varios prototipos

La finalización de la fase de incepción se da el primer hito mayor del proyecto:

Los objetivos hitos del ciclo de vida. Los criterios de evaluación para la fase de incepción son:

• Concurrencia de las partes interesadas en la definición de alcance y estimación de costos/programas

(horarios).

• Evidencia de entendimiento de los requerimientos mediante la comprobación de los casos de uso

primarios.

• Credibilidad de los estimados de costos/programas, prioridades, riesgos y proceso de desarrollo.

• Detalle y extensión de cualquier prototipo arquitectónico que se ha desarrollado.

• Gastos actuales Vs. Gastos planeados

FASE DE ELABORACIÓN:

El propósito de la fase de elaboración es analizar el dominio del problema, establecer un fundamento

arquitectónico, desarrollar el plan del proyecto y eliminar los elementos de mayor riesgo para el proyecto.
Para lograr estos objetivos, se debe tener una vista del cuadro completo del sistema. Las decisiones sobre
la arquitectura se deben hacer entendiendo el sistema completo: su alcance, requerimientos funcionales
y no funcionales como requerimientos de rendimiento. Es fácil argumentar que la fase de elaboración es
la más crítica de las cuatro fases, Al final de esta fase, se considera que la “ingeniería difícil” se ha
completado y que el proyecto ha pasado por el día más importante de consideración del proyecto: la
decisión de continuar o no hacia las fases de construcción y transición. Mientras el proceso siempre tiene
que hacer cambios, las actividades de la fase de elaboración aseguran que la arquitectura, requerimientos
y planes estén suficientemente estables y que los riesgos estén suficientemente mitigados, de manera
que se pueda determinar predeciblemente el costo y el programa para conclusión del desarrollo. En la
fase de elaboración un prototipo de arquitectura ejecutable se construye en una o más iteraciones,
dependiendo del alcance, tamaño, riesgo y novedad del proyecto.

El resultado de la fase de elaboración es:

• Un modelo de caso de uso (completo por lo menos el 80%), en donde todos los casos de uso y actores
han sido identificados y más casos de uso han sido elaborados.

• Requerimientos suplementarios capturando lo requerimientos no funcionales y cualquier

requerimiento que no esté asociado con un caso de uso específico.

• Descripción de una Arquitectura de Software.

• Prototipo arquitectónico ejecutable.

• Lista de riesgos y casos de negocio revisados.

• Un plan de desarrollo para el proyecto global, incluyendo el plan del proyecto desglosado, mostrando
iteraciones y criterios de evaluación para cada iteración.

• Un caso de desarrollo actualizado especificando el proceso que se usará.

• Un manual de usuario preliminar (opcional)

Al final de la fase de elaboración se da el segundo mayor hito del ciclo de vida. En este punto se examina
los objetivos y alcance detallados del sistema, la selección de la arquitectura y la resolución de los mayores
riesgos.

FASE DE CONSTRUCCION

En la fase de construcción, todos los componentes que faltan y las características de la aplicación se
desarrollan e integran en el producto, y todas las características se prueban. La fase de construcción es de
cierto modo un proceso de manufactura que pone énfasis en manejar los recursos y controlar las
operaciones para optimizar costos, programaciones y calidad. En este sentido, la mentalidad de
administración sigue una transición desde el desarrollo de propiedad intelectual durante las fases de
incepción y elaboración, hasta el desarrollo de un producto desplegable durante las fases de construcción
y transición. Muchos proyectos son lo suficientemente grandes para que los incrementos de la
construcción en paralelo puedan ser generados. Estas actividades en paralelo pueden acelerar
significativamente la capacidad de despliegues; pero también pueden incrementar la complejidad de
administrar los recursos y sincronización del flujo de trabajo. Una arquitectura robusta es más fácil de
construir. Esta es una razón por la cual el desarrollo balanceado de la arquitectura y del plan es enfatizado
durante la fase de elaboración. La salida de la fase de construcción es un producto listo para ponerlo en
las manos de los usuarios finales.

Como mínimo consiste de:

• Producto de software integrado en la plataforma adecuada.

• Manuales de usuario.

• Descripción de la versión actual. Al final de la fase de construcción se da el tercer hito mayor, en este
punto se decide si el software, los sitios y los usuarios están listos para operar, sin exponer al proyecto a
altos riesgos. Este hito comúnmente se denomina la versión “beta” .

FASE DE TRANSICION

El propósito de la fase de transición es justamente la transición del producto de software en la comunidad

de usuarios. Una vez que el producto se ha entregado al usuario final, surgen inconvenientes y requieren
nuevas versiones, corregir algunos problemas o terminar las características que fueron pospuestas. La
fase de transición se da cuando una línea base está suficientemente avanzada para ser desplegada en el
dominio del usuario final. Esto requiere casi siempre que algunos subconjuntos utilizables del sistema se
hayan completado en un nivel aceptable de calidad y que la documentación de usuario esté disponible de
manera que la transición de resultados positivos para todas las partes. Esto incluye:

• Pruebas “beta” para validar el nuevo sistema en contraste con las expectativas del usuario.

• Operación paralela con un sistema heredado al cual está reemplazando.

• Conversión de bases de datos operacionales.

• Capacitación a usuarios y personal de mantenimiento.

• Emprender el producto al mercado, distribución y grupos de venta. La fase de transición se enfoca en

las actividades requeridas para poder entregar el software a los usuarios. Típicamente, esta fase incluye
algunas iteraciones, incluyendo versiones beta, versiones generales disponibles, bug-fix 3 y versiones de
mejora. En este punto del ciclo de vida la retroalimentación de los usuarios debe ser tomada
primariamente para ajustar, configurar, instalar y ver las dificultades de usabilidad del producto. Los
objetivos primarios de la fase de transición incluyen:

• Lograr que el usuario pueda usar el producto por sí mismo.

• Lograr que la concurrencia desplegada de las partes interesadas esté completa y consistente con el
criterio de evaluación de la visión.

• Lograr la línea base del producto final tan rápida y económicamente efectiva como sea posible. Al final
de la fase de transición se da el cuarto hito mayor del proyecto. En este punto se decide si los objetivos
fueron logrados y si se debería empezar otro ciclo de desarrollo.
 Análisis de Diseño de Describir Describir
Arquitectura Arquitectura Concurrencia Distribución

Arquitecto

Análisis de Diseño de
Casos de Uso Casos de Uso

Diseñador de
Casos de Uso

Análisis de Diseño de
Objetos Objetos

Diseñador

Revisor de Revisar el Revisar el Revisar la

Diseño Análisis Diseño Arquitectura
Recursos por asignar en el proyecto:

Analistas

• Analista del Proceso del Negocio

• Diseñador del Negocio

• Revisor del Modelo del Negocio

• Revisor de Requerimientos

• Analista del Sistema

• Especificador de Casos de Uso

• Diseñador de Interfaz del Usuario

Desarrolladores

• Arquitecto

• Revisor de la Arquitectura

• Diseñador de Cápsulas

• Revisor del Código y Revisor del Diseño

• Diseñador de la Base de Datos

• Diseñador

• Implementador y un Integrador

Probadores Profesionales

• Diseñador de Pruebas

• Probador

Encargados

• Encargado de Control del Cambio

• Encargado de la Configuración

• Encargado del Despliegue

• Ingeniero de Procesos

• Encargado de Proyecto

• Revisor de Proyecto

Otros
• Cualquier trabajador

• Administrador del Sistema

DIAGRAMA CASO DE USO

DESPLIEGUE
FASE DE DESARROLLO
 IMPLEMENTACION

DIAGRAMA DE SECUENCIAS
ESTADOS
DIAGRAMA DE COLABORACION
MARCO DE TRABAJO PARA LA APLICACIÓN WEB (RUP)
Fase de Cierre: El propósito de esta fase es asegurar que el software esté disponible para los usuarios
finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios
y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones
entregadas por las personas involucradas en el proyecto.

Para analizar un sistema debemos tener en cuenta todos sus componentes o etapas: estado actual de la
empresa, recopilar información o documentación, personas que actúan, interacción, qué se evidencia y
qué se quiere o puede mejorar, establecer un plan de acción (mirando varias posibilidades), ejecutar el
plan de acción, capacitar en las acciones tomadas y los controles a ejecutar, realimentar los resultados de
acuerdo a los hallazgos o resultados finales y reiniciar el proceso para no caer en la entropía. Para un
adecuado estudio de un sistema se debe revisar cuidadosamente el sistema de manera integral y también
el detalle de cada subsistema, revisar los procesos internos que lo compone, analizar de qué forma
interactúan y proponer cambios de acuerdo a los hallazgos iniciales planificando cuidadosamente a dónde
queremos llevar el sistema y qué acciones se deben ejecutar después de realizar los ajustes según los
hallazgos finales (realimentación).