PRACTICAS PRE PROFESIONALES I

“AÑO DE LA INTEGRACIÓN NACIONAL Y EL
RECONOCIMIENTO DE NUESTRA DIVERSIDAD”

UNIVERSIDAD “SAN PEDRO”

FACULTAD DE INGENIERÍA

Escuela Académica Profesional de Ingeniería Informática y de Sistemas

Prácticas Pre-Profesionales

Docente : Ing. PÉREZ URTEAGA, Franklin Luis.

Proyecto :

ANÁLISIS Y DISEÑO DE UN SISTEMA EN EL ÁREA DE VENTAS PARA LA
RESERVA Y VENTA DE PASAJES EN LA EMPRESA
DE TRANSPORTES PERU BUS S.A.C. - CAJABAMBA

Autor : CASTILLO VERA, Anderson M.

Cajabamba, 26 de Julio del 2012.

UNIVERSIDAD SAN PEDRO
ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

DEDICATORIA

Dedico este proyecto a Dios y a mis padres. A Dios
porque ha estado conmigo a cada paso que doy,
cuidándome y dándome fortaleza para continuar, a mis
padres, quienes a lo largo de mi vida han velado por mi
bienestar y educación siendo mi apoyo en todo momento.
Depositando su entera confianza en cada reto que se me
presentaba sin dudar ni un solo momento en mi
inteligencia y capacidad.

Anderson M. Castillo Vera.

CASTILLO VERA Anderson M. 1


AGRADECIMIENTO

Mi más sincero agradecimiento está dirigido hacia la
asistente del área de ventas de la Empresa de Transportes
PERU BUS S.A.C., quien con su ayuda desinteresada, nos
brindó información relevante, próxima, pero muy cercana a
la realidad de nuestras necesidades. Agradezco también a
mi familia por siempre brindarme su apoyo, tanto
sentimental, como económico.

Anderson M. Castillo Vera.



INDICE
CAPÍTULO I : GENERALIDADES

1.1. Descripción de la Organización 7
1.2. Organigrama de la Organización 8
1.3. Situación Problemática 8
1.3.1. Selección del Problema 9
1.3.2. Antecedentes del Problema 9
1.3.3. Formulación del Problema 9
1.3.4. Justificación 10
A. Justificación Operativa 10
B. Justificación Económica 11
C. Justificación Técnica 11
1.4. Objetivos del Proyecto 12
1.4.1. Objetivo General 12
1.4.2. Objetivo Específicos 12
1.5. Limitaciones del Proyecto 12

CAPÍTULO II : MARCO TEÓRICO

2.1. Metodología RUP 14
Características 14
Estructura 16
Fases 17
2.2. Herramientas de Apoyo 21
2.2.1. Rational Rose 21
2.2.2. Lenguaje Unificado de Modelado (UML) 23
a) Diagramas de Estructura 23
Diagramas de Clase 23



Diagramas de Componentes 25
Diagramas de Objetos 25
Diagramas de Paquetes 28
b) Diagramas de Comportamiento 28
Diagramas de Actividad 28
Diagramas de Caso de Uso 28
Diagramas de Estado 31
c) Diagramas de Interacción 32
Diagramas de Secuencia 32
Diagramas de colaboración 33
2.3. Requerimientos del Sistema 34
2.4. Power Builder 10.5 34
2.5. ODBC (Open Data Base Conectivity) 35
2.5.1. Características de ODBC 36
2.5.2. Arquitectura de ODBC 37
2.6. SQL Server 2008 37
2.6.1. Razones para elegir SQL Server 38

CAPÍTULO III: APLICACIÓN DE LA METOLOGÍA RUP

3.1. Etapa de Análisis 40
 La Organización 40
Misión 40
Visión 40
 Equipos 40
 Áreas de la Organización 40
 Organigrama de la Organización 41
 Descripción de Actores 41
Gerente Administrador 41
Contador 42
Asistente de Ventas 42
Asistente del Bus 42



3.2. Etapa de Requerimientos 43
3.2.1. Funciones Básicas 44
3.3. Beneficios del Sistema Informático Propuesto 46
3.3.1. Beneficios Tangibles del Software 46
3.3.2. Beneficios Intangibles 47
3.4. Etapa de Desarrollo 47

3.4.1. Diseño de los Casos de Uso 47
Diagrama de Casos de Uso del Negocio 47
Diagrama de Casos de Uso del Sistema 48
3.4.2. Diseño de Diagramas de Secuencia 52
3.4.3. Diseño de Diagramas de Actividad 55
3.4.4. Diseño de Diagramas de Colaboración 57
3.4.5. Diseño de Diagrama de Clases 59
3.4.6. Diseño de Diagrama Entidad Relación 60
3.5. Costeo 60
3.6. Plan de Contingencia 62

CAPÍTULO IV: CONCLUSIONES Y RECOMENDACIONES

Conclusiones 63

Recomendaciones 64

CAPÍTULO V: BIBLIOGRAFIA

Bibliografía 66

Sitios Web 66



CAPITULO I
GENERALIDADES



1.1. Descripción de la organización:

La Empresa de Transportes PERU BUS S.A.C., nace en el año 1991 en la ciudad
de Trujillo. Donde comenzó brindando servicios de transporte urbano e
interurbano. Desde su comienzo, trataron de ofrecer una alternativa que
signifique el menor costo posible para el usuario sin desmerecer la calidad de sus
servicios en ninguno de sus aspectos.Estas normas fueros guiando fielmente a la
empresa a lo largo de los años que siguieron a su aparición, y de su éxito da fe la
gran acogida que han experimentado, pasando así al servicio interprovincial al
finalizar el año 2002.

La Empresa de Transportes PERU BUS S.A.C. Tiene como principal actividad
el Transporte de Servicio Público. Esta organización actualmente tiene el
permiso de las Rutas Cajabamba – Cajamarca – Trujillo y viceversa, Trujillo -
Lima y viceversa.

La Organización cuenta con una flota de cuatro unidades con los permisos
correspondientes de circulación.

Las unidades ofrecen los siguientes servicios:

 55 asientos cómodos y reclinables.
 Aire acondicionado.
 Cortinas y luz de lectura.
 2 TVs y DVD, para entretenimiento.



1.2. Organigrama de la organización:

1.3. Situación problemática existente:

En la Empresa de Trasportes PERU BUS S.A.C., existen diferentes problemas,
como:

 Demora en la atención a los clientes en el proceso de búsqueda del plano
correspondiente a la fecha indicada por el cliente, como también en el
llenado del pasaje.
 Pérdida y extravío de boletos por parte de la empresa al no contar con una
base de datos para almacenar y registrar las ventas y por ende los pasajes.
 Control deficiente en la venta como también en la reserva de pasajesdebido a
la falta de metodologías y formalidad en estos procesos.



 Demasiado uso de material de escritorio ya sea en los planos para cada
horario de salida de las buses, boletería y manifiestos de pasajeros para la
policía, lo cual involucra también calcadores, lapiceros y marcadores.
 La organización no cuenta con mecanismos adecuados para el control de
almacén. El cual está ocasionando el mal control y distribución de los
pasajes para vender como también de los pasajes ya vendidos.
 Problemas al solicitar algún determinado pasaje en el área de ventas ,lo cual
está ocasionando demora en la entrega de información.

1.3.1. Selección del problema.

Después de haber realizado un análisis sobre los problemas que aquejan a
la Empresa de Trasportes PERU BUS S.A.C., considere el más
importante para la realización del proyecto el siguiente problema:

 Control deficiente en los procesos de venta como también de reserva
de pasajes debido a la falta de metodologías y formalidad en estos
procesos.

1.3.2. Formulación interrogativa del problema:

¿Cómo analizar y diseñar los procesos dentro de la reservas y ventas de
pasajes en la Empresa de Trasportes PERU BUS S.A.C?

1.3.3. Antecedentes del problema:

 UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS
FACULTAD DE INGENIERÍA
DIVISIÓN DE ESTUDIOS PROFESIONALES PARA EJECUTIVOS
CARRERA DE INGENIERÍA DE SISTEMAS

Sistema para Reserva y Venta de Pasajes de una Empresa de
Transporte



PROYECTO PROFESIONAL PRESENTADO POR:
Alvarado Flores, Nathaly (u921136)
Núñez González, Nelzon (u913732)
Callupe Dávila, Raúl Eduardo (u913819)
PARA EL CURSO DE DESARROLLO PARA ENTORNO WEB
PROFESOR:
ING. DAVID RODRÍGUEZ CONDEZO

Lima, 17 de Enero de 2010

 UNIVERSIDAD CATÓLICA DEL NORTE
FACULTAD DE INGENIERÍA Y CIENCIAS GEOLÓGICAS
Departamento de Ingeniería de Sistemas y Computación.
Antofagasta, Chile.
Ingeniería de Software I – Proyecto Reserva y venta de pasajes

1.3.4. Justificación del Proyecto:

A. Justificación operativa.

Este proyecto traerá muchos beneficios para la organización como
también para sus clientes:

- La atención será más rápida y eficiente: Esto será posible a base
de correcciones que se verán gracias al análisis en el área de
venta de la Empresa de Trasportes PERU BUS S.A.C.

- Un eficiente trabajo por parte del encargado de venta de pasajes:
La asistente encargada de la venta de pasajes de la Empresa de
Trasportes PERU BUS S.A.C., será comunicada de los resultados
finales y las causas para poder mejorar los procesos que se dan en



la atención para la venta de pasajes de la empresa antes
mencionada.

- Agilizar la búsqueda de los pasajes ya vendidos: La Empresa de
Trasportes PERU BUS S.A.C., podrá obtener un almacén de
datos y archivos de todos los boletos vendidos en sus distintos
turnos de salida, los cuales se reportaran mensualmente sin
extraviar o dejar alguno en el olvido, evitando así confusiones.
- Permitirá agilizar los procesos empresariales.

B. Justificación Económica.

- Reducir costos en material de escritorio.
- Reducción de personal.
- Permitirá un mejor control de inventarios, reduciendo así la
perdida de productos los cuales ocasionaban perdidas a la
empresa.
- Permitirá la atención a más clientes lo que ocasionará más
ingresos económicos para la empresa.

C. Justificación Técnica.

- Brindar el servicio de venta de pasajes, en forma eficiente.
- Permitirá el ahorro de tiempo.
- La realización del análisis se desarrollará con una metodología a
medida.
- Brindara a la organización un soporte de información adecuada
para el desarrollo de sus procesos ya sea en la venta o en la
reserva de pasajes.



1.4. Objetivos del proyecto.

1.4.1. Objetivo General:
El objetivo general es:

 Analizar y Diseñar los procesos de información en la reserva y venta
de pasajes de la Empresa de Trasportes PERU BUS S.A.C.

1.4.2. Objetivos Específicos:

 Recopilar información del departamento de ventas mediante la
comunicación constante con el vendedor de pasajes, con los clientes
o pasajeros de la empresa, el ayudante de las unidades de transporte
de pasajeros y la dirección de de la Empresa de Trasportes PERU
BUS S.A.C.
 Analizar los requerimientos necesarios para el desarrollo del
proyecto.
 Diseñar el proceso de reserva y venta de pasajes de la Empresa de
Transportes PERU BUS S.A.C., con las herramientas de Rational
Rose.
 Hacer más eficientes los procesos para la reserva y venta de pasajes
de la Empresa de Transportes PERU BUS S.A.C
 Mejorar la atención a los clientes mediante el análisis y el diseño de
los procesos en la reserva y venta de pasajes.

1.5. Limitaciones del proyecto:
 El personal del área de ventas no nos brinda la información requerida por
falta de conocimientos administrativos.
 El análisis es dificultoso por falta de personal con experiencia en el área de
desarrollo de nuestro proyecto.
 La falta de oportunidad para dialogar directamente con la administradora de
la Empresa de Transporte PERU BUS S.A.C. por su residencia en Trujillo,
por lo que no pude contar con mas información que podría facilitar en el
desarrollo del proyecto.


CAPITULO II
MARCO TEORICO



2. Descripción de la Metodología
Para este proyecto utilizaremos la metodología RationalUnifiedProcess (RUP).

2.1. Metodología (RUP)

El Proceso Unificado de Rational, es un marco de desarrollo de software que
se caracteriza por estar dirigido por casos de uso, centrado en la arquitectura y
por ser iterativo e incremental. El refinamiento más conocido y documentado
del Proceso Unificado es el Proceso Unificado de Rational o simplemente
RUP.

El Proceso Unificado no es simplemente un proceso, sino un marco de trabajo
extensible que puede ser adaptado a organizaciones o proyectos específicos.
De la misma forma, el Proceso Unificado de Rational, también es un marco de
trabajo extensible, por lo que muchas veces resulta imposible decir si un
refinamiento particular del proceso ha sido derivado del Proceso Unificado o
del RUP. Por dicho motivo, los dos nombres suelen utilizarse para referirse a
un mismo concepto.

 Características Esenciales:

Proceso Iterativo e Incremental.- El Proceso Unificado es un marco de
desarrollo iterativo e incremental compuesto de cuatro fases
denominadas Inicio, Elaboración, Construcción y Transición. Cada una
de estas fases es a su vez dividida en una serie de iteraciones (la de inicio
sólo consta de varias iteraciones en proyectos grandes). Estas iteraciones
ofrecen como resultado un incremento del producto desarrollado que
añade o mejora las funcionalidades del sistema en desarrollo.

Cada una de estas iteraciones se divide a su vez en una serie de
disciplinas que recuerdan a las definidas en el ciclo de vida clásico o en
cascada: Análisis de requisitos, Diseño, Implementación y Prueba.
Aunque todas las iteraciones suelen incluir trabajo en casi todas las



disciplinas, el grado de esfuerzo dentro de cada una de ellas varía a lo
largo del proyecto.

Diagrama ilustrando como el énfasis relativo en las distintas disciplinas cambia
a lo largo del proyecto.

Proceso dirigido por los Casos de Uso.- En el Proceso Unificado los
casos de uso se utilizan para capturar los requisitos funcionales y para
definir los contenidos de las iteraciones. La idea es que cada iteración
tome un conjunto de casos de uso o escenarios y desarrolle todo el
camino a través de las distintas disciplinas: diseño, implementación,
prueba, etc. el proceso dirigido por casos de uso es el rup. Nota: en UP se
está Dirigido por requisitos y riesgos de acuerdo con el Libro UML 2 de
ARLOW, Jim que menciona el tema.

Proceso Centrado en la arquitectura.- El Proceso Unificado asume que
no existe un modelo único que cubra todos los aspectos del sistema. Por
dicho motivo existen múltiples modelos y vistas que definen la
arquitectura de software de un sistema. La analogía con la construcción
es clara, cuando construyes un edificio existen diversos planos que
incluyen los distintos servicios del mismo: electricidad, fontanería, etc.

Enfocado en los riesgos.- El Proceso Unificado requiere que el equipo
del proyecto se centre en identificar los riesgos críticos en una etapa
temprana del ciclo de vida. Los resultados de cada iteración, en especial



los de la fase de Elaboración deben ser seleccionados en un orden que
asegure que los riesgos principales son considerados primero.

 Estructura de la Metodología RUP

El RationalUnifiedProcess o Proceso Unificado de Racional. Es un
proceso de ingeniería de software que suministra un enfoque para asignar
tareas y responsabilidades dentro de una organización de desarrollo. Su
objetivo es asegurar la producción de software de alta calidad que
satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto
previsible. Es una metodología de desarrollo iterativo enfocada hacia “los
casos de uso, manejo de riesgos y el manejo de la arquitectura”.

El RUP mejora la productividad del equipo ya que permite que cada
miembro del grupo sin importar su responsabilidad específica acceda a la
misma base de datos de conocimiento. Esto hace que todos compartan el
mismo lenguaje, la misma visión y el mismo proceso acerca de cómo
desarrollar software.

Estructura de la metología RUP



Estructura de la metología RUP, veremos una implementación del
desarrollo en espiral. En su estructura se establecen tareas en fases e
iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las
cuales se realizan varias iteraciones en número variable

a) Fases de la Metodología RUP

Las primeras iteraciones (en las fases de Inicio y Elaboración) se
enfocan hacia la comprensión del problema y la tecnología, la
delimitación del ámbito del proyecto, la eliminación de los riesgos
críticos, y al establecimiento de una base de inicio de la arquitectura.

Fase de Inicio.- Durante esta fase de inicio las iteraciones se centran
con mayor énfasis en las actividades de modelamiento de la empresa y
en sus requerimientos

Fase de Elaboración.- Durante esta fase de elaboración, las
iteraciones se centran al desarrollo de la base de la diseño, encierran
más los flujos de trabajo de requerimientos, modelo de la
organización, análisis, diseño y una parte de implementación orientada
a la base de la construcción

Fase de Construcción.- Durante esta fase de construcción, se lleva a
cabo la construcción del producto por medio de una serie de
iteraciones las cuales se seleccionan algunos Casos de Uso, se
redefine su análisis y diseño y se procede a su implantación y pruebas.
En esta fase se realiza una pequeña cascada para cada ciclo, se
realizan tantas iteraciones hasta que se termine la nueva
implementación del producto.

Fase de Transición.- Durante esta fase de transición busca garantizar
que se tiene un producto preparado para su entrega al usuario.

Principales Características:



 Forma disciplinada de asignar tareas y responsabilidades (quién
hace qué, cuándo y cómo).
 Pretende implementar las mejores prácticas en Ingeniería de
Software.
 Desarrollo iterativo.
 Administración de requisitos.
 Uso de arquitectura basada en componentes.
 Control de cambios.
 Modelado visual del software.
 Verificación de la calidad del software.

El RUP es un producto de Rational (IBM). Se caracteriza por ser
iterativo e incremental, estar centrado en la arquitectura y guiado por
los casos de uso. Incluye artefactos (que son los productos tangibles
del proceso como por ejemplo, el modelo de casos de uso, el código
fuente, etc.) y roles (papel que desempeña una persona en un
determinado momento, una persona puede desempeñar distintos roles
a lo largo del proceso).

b) Especificación de las Fases

 Establece oportunidad y alcance.
 Identifica las entidades externas o actores con las que se trata.
 Identifica los casos de uso.

RUP comprende 2 aspectos importantes por los cuales se establecen
las disciplinas:

Proceso: Las etapas de esta sección son:

 Modelado de negocio.
 Requisitos.
 Análisis y Diseño.
 Implementación.
 Pruebas.



Soporte: En esta parte nos conseguimos con las siguientes etapas:

 Gestión del cambio y configuraciones
 Gestión del proyecto
 Entorno

La estructura dinámica de RUP es la que permite que este sea un
proceso de desarrollo fundamentalmente iterativo, y en esta parte se
ven inmersas las 4 fases descritas anteriormente:

 Inicio(También llamado Incepción).
 Elaboración.
 Desarrollo(También llamado Implementación, Construcción).
 Cierre (También llamado Transición).

c) Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura estática)
realiza una serie de artefactos que sirven para comprender mejor tanto
el análisis como el diseño del sistema estos artefactos son los
siguientes:

Inicio:

 Documento Visión
 Especificación de Requerimientos

Elaboración:

 Diagramas de caso de uso

Construcción:

 Documento Arquitectura que trabaja con las siguientes vistas:



Vista Lógica:

 Diagrama de clases
 Modelo E-R (Si el sistema así lo requiere)

Vista de Implementación:

 Diagrama de Secuencia
 Diagrama de estados
 Diagrama de Colaboración

Vista Conceptual:

 Modelo de dominio

Vista física:

 Mapa de comportamiento a nivel de hardware.

d) Implementación de RUP para el Proyecto

La metodología RUP es más apropiada para proyectos grandes
(Aunque también pequeños), dado que requiere un equipo de trabajo
capaz de administrar un proceso complejo en varias etapas. En
proyectos pequeños, es posible que no se puedan cubrir los costos de
dedicación del equipo de profesionales necesarios.



2.2. Herramientas de Apoyo
2.2.1. Rational Rose (RUP)
Es una herramienta de Rational Software Corporationcon el soporte de
UML.
Rose posesionado por RationalObject esta orientado a la Ingeniería del
software, es usado para el análisis, modelado, diseño y construcción
del objeto orientado.Esta dentro de las herramientas de modelamiento
visualSoporte múltiple para el manejo del modelamiento de la
arquitectura.

¿Para qué sirve?

Sirve para el análisis y diseno de sistemas basados en objetos. Rose es
usado para modelar sistemas antes de llevar a cabo los trabajos de
construcción. Esta secuencia de desarrollo es importante para asegurar
la consistencia arquitectónica del sistema. Usando los modelos de
Rose Rational Rose apoya también al planeamiento del negocio, a
través de representaciones que facilitan a los usuarios el mejor
entendimiento de los procesos del negocio haciéndolos más eficientes.
Incluye todos los diagramas de UML: actores, casos de uso, objetos,
clases, componentes y el despliegue de nodos en un sistema. Los
modelos Rose, describen con gran detalle lo que el sistema incluirá y
como funcionará, para que así los diseñadores puedan usar los
modelos como si fueran los planos de un sistema a ser construido (un
planoes una buena analogía para los modelos creados en Rose).

Ventajas:

 Un diseño más rápido: Las aplicaciones se crean a partir de
componentes ya existentes.
 Mantenimiento más sencillo: El enlace dinámico incrementa la
flexibilidad, permitiendo la adhesión de nuevas clases de objetos
sin modificar los actuales.


Características:

 Mantiene la consistencia de losmodelos del sistema software.
 Generación de documentaciónautomáticamente.
 Generación de Código a partir de losModelos.
 Ingeniería Inversa.
 Soporte para análisis de patrones ANSI C++, Rose J y Visual
C++ basado en "DesignPatterns: Elements of Reusable Object-
Oriented Software."
 Característica de control por separado de componentes modelo
que permite una administración más granular y el uso de modelos.
 Soporte de ingeniería Forward y/o reversa para algunos de los
conceptos más comunes de Java 1.5
 La generación de código Ada, ANSI C ++, C++, CORBA, Java y
Visual Basic, con capacidad de sincronización modelo- código
configurables.
 Soporte Enterprise Java Beans™ 2.0
 Capacidad de análisis de calidad de código.
 El Add-In para modelado Web provee visualización, modelado y
las herramientas para desarrollar aplicaciones de Web.
 Modelado UML para trabajar en diseños de base de datos, con
capacidad de representar la integración de los datos y los
requerimientos de aplicación a través de diseños lógicos y físicos.
 Capacidad de crear definiciones de tipo de documento XML
(DTD) para el uso en la aplicación.
 Integración con otras herramientas de desarrollo de Rational.
 Capacidad para integrarse con cualquier sistema de control de
versiones SCC-compliant, incluyendo a RationalClearCase.
 Publicación web y generación de informes para optimizar la
comunicación dentro del equipo.



Sistemas Operativos y Plataformas de Hardware Apropiadas:

 Windows NT
 Windows XP

Rational Rose,es la mejor elección para el ambiente de modelado que
soporte la generación de código a partir de modelos en Ada, ANSI
C++, C++, CORBA, Java™/J2EE™, Visual C++® y Visual Basic®.
Como todos los demás productos Rational Rose,proporciona un
lenguaje común de modelado para el equipo que facilita la creación
de software de calidad más rápidamente.

2.2.2. Lenguaje Unificado de Modelado (UML)
Un modelo UML esta compuesto por tres clases de bloques de
construcción:
 Elementos: Los elementos son abstracciones de cosas reales o
ficticias (objetos, acciones, etc.)
 Relaciones: relacionan los elementos entre sí.
 Diagramas: Son colecciones de elementos con sus relaciones.

Un Diagrama es la representación gráfica de un conjunto de
elementos con sus relaciones. UML ofrece una amplia variedad de
diagramas para visualizar el sistema desde varias perspectivas.

a) Diagramas de Estructura.-Enfatizan en los elementos que deben
existir en el sistema modelado.

Diagrama de clases.-Es un tipo de diagrama estático que
describe la estructura de un sistemamostrando 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.

Representación de:

- Requerimientos en entidades y actuaciones.

- La arquitectura conceptual de un dominio.

- Soluciones de diseño en una arquitectura.

- Componentes de software orientados a objetos.

El diagrama de clases incluye mucha más información como la
relación entre un objeto y otro, la herencia de propiedades de otro
objeto, conjuntos de operaciones/propiedades que son
implementadas para una interfaz gráfica.



Diagrama de componentes.- Es un diagrama tipo del Lenguaje
Unificado de Modelado.

Un diagrama de componentes representa cómo un sistema de
software es dividido en componentes y muestra las dependencias
entre estos componentes. Los componentes físicos incluyen
archivos, cabeceras, bibliotecas compartidas, módulos,
ejecutables, o paquetes. Los diagramas de Componentes
prevalecen en el campo de la arquitectura de software pero
pueden ser usados para modelar y documentar cualquier
arquitectura de sistema.

Debido a que los diagramas de componentes son más parecidos a
los diagramas de casos de usos, éstos son utilizados para modelar
la vista estática y dinámica de un sistema. Muestra la organización
y las dependencias entre un conjunto de componentes. No es
necesario que un diagrama incluya todos los componentes del
sistema, normalmente se realizan por partes. Cada diagrama
describe un apartado del sistema.

En él se situarán librerías, tablas, archivos, ejecutables y
documentos que formen parte del sistema.

Uno de los usos principales es que puede servir para ver qué
componentes pueden compartirse entre sistemas o entre diferentes
partes de un sistema.

Diagramas de objetos.-Son utilizados durante el proceso de
Análisis y Diseño de los sistemas informáticos en la metodología
UML.

Se puede considerar un caso especial de un diagrama de clases en
el que se muestran instancias específicas de clases (objetos) en un
momento particular del sistema. Los diagramas de objetos utilizan
un subconjunto de los elementos de un diagrama de clase. Los



diagramas de objetos no muestran la multiplicidad ni los roles,
aunque su notación es similar a los diagramas de clase.

Una diferencia con los diagramas de clase es que el
compartimiento de arriba va en la forma Nombre de objeto:
Nombre de clase.

Por ejemplo, Miguel: Persona.

Diagrama de estructura compuesta.- Es un tipo de diagrama de
estructura estática en el Lenguaje de Modelado Unificado
(UML), que muestra la estructura interna de una clase y las
colaboraciones que esta estructura hace posibles. Esto puede
incluir partes internas, puertas mediante las cuales, las partes
interactúan con cada una de las otras o mediante las cuales,
instancias de la clase interactúan con las partes y con el mundo
exterior, y conectores entre partes o puertas. Una estructura
compuesta es un conjunto de elementos interconectados que
colaboran en tiempo de ejecución para lograr algún propósito.
Cada elemento tiene algún rol definido en la colaboración.

Las entidades de estructura compuesta claves identificadas en la
especificación UML 2.0 son: clasificadores estructurados, partes,
puertas, conectores, y colaboraciones.

Parte.- Representa un rol jugado en tiempo de ejecución por una
instancia de una clase o por una colección de instancias. La parte
puede nombrar solamente un rol, una superclase abstracta, o
puede nombrar una clase concreta específica. La parte puede
incluir un factor de multiplicidad (cardinalidad).

Puerta.- Es un punto de interacción que puede ser usado para
conectar clasificadores estructurados con sus partes y con el
ambiente. Las puertas pueden opcionalmente especificar los



servicios que proveen y los servicios que requieren de otras partes
del sistema.

Conector.-Un conector une dos o más entidades, permitiéndoles
interactuar en tiempo de ejecución. Un conector es representado
por una línea que une una combinación de partes, puertas y
clasificadores estructurados.

Colaboración.- Es generalmente más abstracta que un
clasificador estructurado. Ésta es mostrada como un óvalo sin
relleno conteniendo los roles que las instancias pueden jugar en la
colaboración.

Clasificador estructurado.- Representa una clase,
frecuentemente una clase abstracta, cuyo comportamiento puede
ser completa o parcialmente descrito mediante interacciones entre
partes.

Diagrama de Despliegue.-Es un tipo de diagrama del Lenguaje
Unificado de Modelado que se utiliza para modelar el hardware
utilizado en las implementaciones de sistemas y las relaciones
entre sus componentes.

Los elementos usados por este tipo de diagrama son nodos
(representados como un prisma), componentes (representados
como una caja rectangular con dos protuberancias del lado
izquierdo) y asociaciones.



En el UML 2.0 los componentes ya no están dentro de nodos. En
cambio, puede haber artefactos u otros nodos dentro de un nodo.
Este tipo de diagrama debemos también añadir que no van a
existir actores para relacionarse con los nodos (no es un diagrama
de casos de uso) si no que las relaciones que pueda haber siempre
seran entre los nodos y por ejemplo con una base de datos.

Diagrama de Paquetes.-Muestra cómo 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.

b) Diagramas de Comportamiento.- Enfatizan en lo que debe
suceder en el sistema modelado.

Diagrama de actividades.- Representa los flujos de trabajo paso
a paso de negocio y operacionales de los componentes en un
sistema. Un Diagrama de Actividades muestra el flujo de control
general.

Es una forma especial de diagrama de estado usado para modelar
una secuencia de acciones y condiciones tomadas dentro de un
proceso.



Diagrama de Casos de Uso.- Es una especie de diagrama de
comportamiento. UML mejorado El Lenguaje de Modelado
Unificado define una notación gráfica para representar casos de
uso llamada modelo de casos de uso. UML no define estándares
para que el formato escrito describa los casos de uso, y así mucha
gente no entiende que esta notación gráfica define la naturaleza de
un caso de uso; sin embargo una notación gráfica puede solo dar
una vista general simple de un caso de uso o un conjunto de casos
de uso.

Las tres relaciones principales entre los casos de uso son
soportadas por el estándar UML, el cual describe notación gráfica
para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include o use).- Es una forma de interacción o
creación, un caso de uso dado puede "incluir" otro caso de uso. El
primer caso de uso a menudo depende del resultado del caso de
uso incluido. Esto es útil para extraer comportamientos



verdaderamente comunes desde múltiples casos de uso a una
descripción individual, desde el caso de uso. El estándar de
Lenguaje de Modelado Unificado de OMG define una notación
gráfica para realizar diagramas de casos de uso, pero no el
formato para describir casos de uso. Mucha gente sufre la
equivocación pensando que un caso de uso es una notación
gráfica (o es su descripción). Mientras la notación gráfica y las
descripciones esto no sirve.

Extensión (Extend).- Es otra forma de interacción, un caso de
uso dado (la extensión) puede extender a otro. Esta relación indica
que el comportamiento del caso de la extensión se utiliza en casos
de uso, un caso de uso a otro caso siempre debe tener extensión o
inclusión. El caso de uso extensión puede ser insertado en el caso
de uso extendido bajo ciertas condiciones. La notación, es una
flecha de punta abierta con línea discontinua, desde el caso de uso
extensión al caso de uso extendido, con la etiqueta «extend». Esto
puede ser útil para lidiar con casos especiales, o para acomodar
nuevos requisitos durante el mantenimiento del sistema y su
extensión.

"La extensión, es el conjunto de objetos a los que se aplica un
concepto. Los objetos de la extensión son los ejemplos o
instancias de los conceptos."

Generalización.- Es la actividad de identificar elementos en
común entre conceptos y definir las relaciones de una superclase
(concepto general) y subclase (concepto especializado). Es una
manera de construir clasificaciones taxonómicas entre conceptos
que entonces se representan en jerarquías de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en
cuanto a la intención y extensión.



Los diagramas de casos de uso son a menudo confundidos con
los casos de uso. Mientras los dos conceptos están relacionados,
los casos de uso son mucho más detallados que los diagramas de
casos de uso.

Diagramas de estado.- Muestran el conjunto de estados por los
cuales pasa un objeto durante su vida en una aplicación en
respuesta a eventos (por ejemplo, mensajes recibidos, tiempo
rebasado o errores), junto con sus respuestas y acciones. También



ilustran qué eventos pueden cambiar el estado de los objetos de la
clase. Normalmente contienen: estados y transiciones. Como los
estados y las transiciones incluyen, a su vez, eventos, acciones y
actividades, vamos a ver primero sus definiciones.

Al igual que otros diagramas, en los diagramas de estado pueden
aparecer notas explicativas y restricciones.

c) Diagramas de Interacción.- Son un subtipo de diagramas de
comportamiento, que enfatiza sobre el flujo de control y de datos
entre los elementos del sistema modelado.

Diagrama de Secuencia.- Es un tipo de diagrama usado para
modelar interacción entre objetos en un sistema según UML.

Un diagrama de secuencia muestra la interacción de un conjunto
de objetos en una aplicación a través del tiempo y se modela para
cada caso de uso. Mientras que el diagrama de casos de uso
permite el modelado de una vista business del escenario, el
diagrama de secuencia contiene detalles de implementación del
escenario, incluyendo los objetos y clases que se usan para
implementar el escenario, y mensajes intercambiados entre los
objetos.

Típicamente se examina la descripción de un caso de uso para
determinar qué objetos son necesarios para la implementación del
escenario. Si se dispone de la descripción de cada caso de uso
como una secuencia de varios pasos, entonces se puede "caminar
sobre" esos pasos para descubrir qué objetos son necesarios para
que se puedan seguir los pasos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas
discontinuas verticales, y los mensajes pasados entre los objetos
como flechas horizontales.



Diagrama de Colaboración.- Modela las interacciones entre
objetos o partes en términos de mensajes en secuencia. Los
diagramas de colaboración representan una combinación de
información tomada desde el diagrama de clases, secuencia, y
diagrama de casos de uso describiendo tanto la estructura estática
como el comportamiento dinámico de un sistema.

Los diagramas de colaboración y de secuencia describen
información similar, y con ciertas transformaciones, pueden ser
transformados unos en otros sin dificultad.

Para mantener el orden de los mensajes en un diagrama de
colaboración, los mensajes son etiquetados con un número
cronológico, y colocados cerca del enlace por el cual se desplaza
el mensaje. Leer un diagrama de colaboración conlleva comenzar
en el mensaje 1.0, y seguir los mensajes desde un objeto hasta el
siguiente, sucesivamente.



2.3. Requerimientos del Sistema
Definiciones:
 Los requerimientos/requisitos de un sistema describen los servicios que
ha de ofrecer el sistema y las restricciones asociadas a su
funcionamiento.
 Propiedades o restricciones determinadas de forma precisa que deben
satisfacerse.
 Un requerimiento, es una característica que el sistema DEBE tener o es
una restricción que el sistema DEBE satisfacer para ser aceptada por el
cliente.
 Levantamiento de requerimientos, es la especificación del sistema en
términos que el cliente entienda, de forma que se constituya en el
contrato entre el cliente y los desarrolladores.

2.4. Power Builder 10.5
Power Builder es un entorno gráfico de programación que está compuesto de
diferentes herramientas que permiten el desarrollo rápido de aplicaciones.
Con estas herramientas se pueden desarrollar aplicaciones Cliente / Servidor a
través de ODBC (Open DataBase Connectivity) o Drivers Nativos para la
Base de Datos. Una aplicación Cliente / Servidor pone en comunicación una
estación de trabajo con un Servidor de Base de Datos Central. Este modelo
consiste en utilizar una Base de Datos que reside en una máquina separada
denominada Servidor. El Software de gestión de Base de Datos se ubica en
las estaciones de trabajo remotas (Clientes). Las aplicaciones que se ejecutan
en las estaciones cliente, acceden a los datos que se encuentran en el servidor.
Es una herramienta de desarrollo empresarial orientada a objetos que permite
construir diferentes tipos de aplicaciones y componentes. Se pueden
desarrollar aplicaciones cliente / servidor, aplicaciones distribuidas y
aplicaciones para Internet. El lenguaje de escritura de PowerBuilder es el
PowerScript. Las escrituras consisten en uso de los comandos, las funciones,
y declaraciones que realizan el proceso en respuesta a un evento. Es un
lenguaje orientado a objetos con las características de herencia, polimorfismo
y encapsulación.



Es un sistema de desarrollo de aplicaciones para creado por Powersoft, que
luego fue comprado por Sybase. PowerBuilder incluye herramientas para la
creación de la interfaz de usuario y reportes, y acceso a bases de datos. Las
herramientas se proveen como un IDE (entorno de desarrollo integrado) para
la creación de aplicaciones de forma rápida.

PowerBuilder es utilizado principalmente para la creación de aplicaciones de
negocios, aunque también posee versiones para crear aplicaciones para
dispositivos móviles.

2.5. ODBC (Open Data Base Conectivity)

O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos
una aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si
después queremos que la misma aplicación, y sin reescribir nada, utilice
tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no
funcionará. Nuestra aplicación, diseñada para un motor concreto, no sabrá
dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no
tendríamos este problema.... aunque eso no es probable que ocurra nunca.

Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro
sea capaz de dialogar con una DB concreta, solo tendríamos que ir cambiando
este elemento, y nuestra aplicación siempre funcionaría sin importar lo que
hay al otro lado... algo así como ir cambiando las boquillas de una manguera.
A esas piezas intercambiables las llamaremos orígenes de datos de ODBC

Casi todas las DB actuales tienen un ODBC. Debido a que este elemento
impone ciertas limitaciones, ya que no todo lo que la DB sabe hacer es
compatible con la aplicación, como velocidad de proceso, tiempos de espera,
máxima longitud de registro, número máximo de registros, versión de SQL,
etc., está cayendo en desuso a cambio de otras técnicas de programación, pero
aún le quedan muchos años de buen servicio.



Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service
Pack 4 o superior instalado (el último publicado es el 6). El Option Pack 4
para actualizar el IIS y las extensiones ASP. SQL Server 6.5 y Access 97. Por
supuesto, también funciona con las versiones modernas de servidores como
2003 Server, y también XP PRO, que lleva un IIS 5.0 de serie. Igualmente es
posible utilizar bases de datos de Access 2000 o 2003.

Esas otras técnicas de programación antes mencionadas, se utilizan ya en el
nuevo Windows 2003, Office 2003 y SQL Server 2000, que además de
ODBC pueden utilizar.... pero esa es otra historia.

Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre
homogéneas, y por el otro permite distintos controladores que aseguran la
conectividad de la aplicación con diferentes bases de datos.

2.5.1. Características ODBC:

Entre sus principales característcas destacan:

 ODBC es una interfaz de programación de aplicaciones estándar
que utiliza
SQL (Structured Query Language).



 Oculta al programador la complejidad a la hora de conectarse a un
origen de datos: por ejemplo, el acceso a los datos a través de
redes de comunicación es transparente.
 Permite a múltiples aplicaciones acceder a múltiples orígenes de
datos.
 Proporciona un modelo de programación homogéneo, es decir,
bases de datos muy diferentes se manejan, vía ODBC, como si
fueran idénticas, siendo ODBC el encargado de realizar las
adaptaciones necesarias.
 Se basa en el modelo cliente/servidor.

2.5.2. Arquitectura de ODBC

Se basa en cuatro componentes:

 Aplicaciones: Son las responsables de interactuar con el usuario y
de llamar a las funciones ODBC para ejecutar sentencias SQL y
recoger los resultados.
 El driver manager: Se encarga de cargar y llamar a los drivers
según lo demanden las aplicaciones.
 Drivers: Procesan las llamadas a las funciones ODBC, ejecutan
sentencias SQL y devuelven los resultados a las aplicaciones. Son
también responsables de interactuar con cualquier capa software
necesaria para acceder a las fuentes de datos, como puede ser el
software de red.
 Orígenes de datos: Consisten en conjuntos de datos, más todo lo
que pueda ser necesario para llegar hasta ellos; sistemas
operativos, gestores de bases de datos, redes de comunicación,
etc.



2.6. SQL Server 2008

Microsoft SQL Server es una base de datos de servidor y una plataforma de
información integral que ofrece un completo conjunto de tecnologías y
herramientas para la empresa que ayudan a las personas a obtener el máximo
valor de la información con el menor coste total de propiedad. Benefíciese de
altos niveles de rendimiento, disponibilidad y seguridad, desarrolla una
gestión más productiva y herramientas de desarrollo, y ofrece una perspectiva
generalizada con Business Intelligence autoservicio (BI).

Una plataforma completa e integrada, Microsoft SQL Server lo reúne todo
para obtener más valor de las actuales capacidades de TI, aumentando la
productividad y la agilidad de los departamentos de TI, y creando
rápidamente aplicaciones flexibles e innovadoras.

2.6.1. Razones para elegir SQL Server

 Las bases de datos de Microsoft ejecutan más bases de datos de
misión crítica en comparación con las bases de datos de Oracle.
 Proporciona 99,9999% de disponibilidad del tiempo de actividad.
 Mayor seguridad de una de las mejores plataformas de bases de
datos.
 Líder indiscutible en pruebas de rendimiento TPC-E.
SQL Server ofrece un ahorro de 460% en el coste anual de
administración por cada base de datos sobre Oracle.
 Microsoft se posiciona como un líder en el Cuadrante Mágico
para Plataformas de Business Intelligence.
 SQL Server supera a IBM DB2 para posicionarse en el segundo
lugar de ingresos por licencias de RDBMS en el año 2009.
 SQL Server reduce el tiempo de inactividad más del 20% por la
migración de un entorno SAP ERP a SQL Server.



CAPITULO III
APLICACIÓN DE LA
METODOLOGIA



3. APLICACIÓN DE LA METODOLOGÍA
3.1. Etapa deAnálisis.

 La Organización:
Razón Social: Empresa de Transportes PERU BUS S.A.C.
RUC: 20439261791
Gerente Administradora: CUEVA DE SANTOS, Dolores Resurrección.
Ubicación: Jr. Miguel Grau Nº 141 - Cajabamba.

Nuestra Misión:

Brindar un servicio de primera calidad en el transporte de pasajeros,
cumpliendo con los estándares de seguridad.
Satisfacer plenamente a nuestros clientes, realizando servicios
de Transporte de calidad, a tiempo, con una excelente actitud de
servicio al mejor precio, sin dejar atrás nuestros valores y raíces.

Nuestra Visión:

Ser una empresa de transporte de pasajeros reconocida a nivel nacional,
cubriendo las principales rutas de nuestro país, y satisfacer así las
exigencias y expectativas de nuestros clientes, teniendo costos
competitivos en el mercado.

 Equipos con los que cuenta la organización.
 Un Teléfono.

 Áreas de la Organización.
 Gerencia.
 Contabilidad.
 Boletería.



 Organigrama de la Organización.

 Descripción de Actores.
La empresa tiene organizado su personal de la siguiente manera:
 Gerente Administrador.- Es la persona que necesita estar mas
informada, teniendo un control y seguimiento de las actividades de
la empresa. Encargado de dirigir el personal y autorizar todas las
operaciones dentro de la empresa y también de administrar los
diferentes recursos de la misma.
Funciones:
- Revisar agenda de cobros y pagos.
- Elaborar cartera de clientes.
- Realizar operaciones bancarias.
- Supervisión de inventarios y cotizaciones.
- Autorización de procesos en la organización.



 Contador.- Encargado de la contabilidad.
Funciones:
- Lleva el registro contable de la empresa.
- Pagos a la Sunat.

 Asistente de Ventas.- Encargada de la venta de pasajes.
Funciones:
- Atención de clientes.
- Dar informe detallado de ventas.
- Vender pasajes para los distintos turnos de la empresa.
- Elabora reportes de actividades en el área de ventas.
- Realiza registro de pasajes vendidos.

 Asistente del Bus.- Encargado de transportar a los pasajeros a su
destino final.
Funciones:
- Lleva el manifiesto de pasajeros de turno.
- Lleva la liquidación de ventas de turno.



DESCRIPCIÓN DE LOS ACTORES

Actores Imagen Casos de Uso
 Registra Pasajeros.
 Realiza venta y reserva de pasajes.
Asistente de
Ventas  Liquidación de turno de ventas.
 Manifiesto de pasajeros.
 Reportes.
 Realiza consulta de Itinerarios.
 Indica tipo de transacción.
 Consulta disponibilidad de asientos.
Cliente
 Determina número de asiento(s).
 Realiza pago.
 Reclama comprobante de pago.
 Realiza consulta y reportes.
 Conocimiento cantidad de ventas y reservas.
Dirección  Conocimiento cantidad de ventas y reservas.
 Liquidación de turno.
 Registra pasajeros.
Asistente del  Realiza venta y reserva de pasajes.
Bus  Liquidación de turno.

3.2. Etapa de Requerimientos
Un proyecto no puede ser exitoso sin una especificación correcta y
exhaustiva de los requerimientos, donde describe las necesidades o deseos de
un producto.

 Registro de ventas.
 Verificación rápida de disponibilidad de asientos.
 Realizar el seguimiento y control de venta de pasajes.



 Conocer de manera específica los pasajeros permanentes de la
organización, con la finalidad de premiarlos ó incentivarlos por su
preferencia.
 Realizar reportes detallados, en los cuales se pueda obserbar de manera
fácil los procesos que se dan en la organización, y así servir como
ayuda basandose en datos reales para la toma de deciciones para
beneficio de la empresa.
 Realizar comprobantes de venta para los clientes o pasajeros.

3.2.1. Funciones Básicas.
Las funciones básicas del sistema son lo que ésta deberá hacer. Éstas
funciones o requerimientos, se detallan a continuación, asignándoles
además una categoría.
En las siguientes tablas se reflejan las funciones del sistema, donde
la primera columna hace referencia a la cantidad de funciones para
una tarea o módulo específico, la segunda columna describe las
funciones en sí, que engloban un módulo, y la tercera columna
muestra las clasificaciones que pueden tener cada función, y entre
ellas están:
 Evidente: Función que debe realizarse, y el usuario debería
saber que se a realizado.
 Oculto: Debe realizarse, aunque no es visible para los usuarios.
 Superflua: Opcionales, su inclusión no repercute
significativamente en el costo ni en otras funciones.



3.2.2. Tabla Registro Pasajeros.
Esta tabla especifica la funcionalidad que tiene el sistema para el
ámbito del registro de los pasajeros de la empresa.
1. REGISTRO PASAJERO
Ref: # Función Categoría
R1.1 Se ingresa datos al registro de pasajeros Evidente

R1.2 Se verifica la existencia del pasajero en Base de Oculta
Datos
R1.3 El sistema registra Datos de pasajero Evidente
R1.4 Genera reporte de pasajero registrado. Oculta

3.2.3. Tabla Registra Venta y Reserva de Pasajes.
La siguiente tabla describe como funciona el sistema sobre la venta y
la reserva de pasajes.
2. REGISTRA VENTA - RESERVA DE PASAJES
Ref:
# Función Categoría
R2.1 Registro venta de pasajes. Evidente
R2.2 Verifica el tipo de transacción e itinerarios. Evidente

R2.3 Incrementa las cantidades del inventario cuando Oculta
realiza una venta.
R2.4 Genera reporte de entrada de nueva venta. Oculta
R2.5 Genera reporte de venta o reserva de pasajes. Oculta

3.2.4. Tabla Muestra Itinerarios.
La tabla muestra Itinerarios, describe especificamente como
funciona el sistema al trabajar en un itinerario determinado.
3. MUESTRA ITENERARIOS

R3.1 Recibe un determino itinerario para realizar viaje Evidente

R3.2 Selecciona asientos disponibles Evidente
El sistema registra los asientos vendidos o
R3.3 Evidente
reservados

R3.4 Reduce la disponibilidad en itinerario indicado Oculta

El sistema manda a imprimir el comprobante de
R3.5 Oculta
venta de pasajes para el cliente



3.2.5. Tabla Muestra Reportes.
Muestra como se dan los reportes finales.
4. MUESTRA REPORTES
Verifica cantidades de pasajes vendidos y
R4.1 Evidente
reserbados.
R4.2 Registra faltantes. Oculta
R4.3 Genera reporte detallado. Evidente

3.3. Beneficios del Sistema Informático propuesto.
Los beneficios obtenidos con el Sistema Informático, responden sobre todo
a la necesidad que tiene la Empresa de Transportes PERU BUS S.A.C. en
las actividades rutinarias que manejan manualmente, las cuales hacen que
los procesos sean lentos y no sean competentes. El SI, reducirá básicamente
el tiempo de espera para los procesos para entonces poder hacer de la
atención el mejor servicio de la organización.

3.3.1. Beneficios Tangibles del Software.
Beneficios tangibles que se obtendrán al desarrollar este proyecto:
- Tiempo.- El tiempo que dedica el usuario en consultar la
existencias de disponibilidad en los distintos itinerarios, se verá
reducido y no tendrá necesidad de hacer ningún trayecto o
proceso manualmente ya que toda la información se encontrara
en la base de datos del sistema para hacer dichos reportes.
- Eficiencia.- Los datos se encontraran en todo momento
actualizados, esto es, serán recuperados, consultados y
actualizados directamente desde la base de datos del sistema.
El tiempo de respuesta, y la ocupación del encargado del área, se
verán mejorados; porque para registrar a un cliente ya no tendrá
que hacerlo manualmente y muchas veces con un mismo cliente,
sino que bastara con que el usuario ingrese al sistema, realizar el
registro y guardarlo en la base de datos por primera y única vez.



3.3.2. Beneficios Intangibles.
- Mejora la imagen empresarial, mediante un servicio rápido,
nuevo y actualizado que brinda la empresa.
- Brindar información clara, oportuna y precisa respecto a los
reportes de ventas.

3.4. Etapa de Desarrollo.
3.4.1. Diseño de los Caso de Uso.
3.4.1.1. Diagrama de Caso de Uso del Negocio.
Modelo que describe los procesos de negocio y sus
relaciones con sus participantes externos, como clientes y
socios.



3.4.1.2. Diagrama de Caso de Uso del Sistema.

El diagrama anterior 3.4.1.2., se enfoca en cómo será
diseñado el sistema, en cómo los actores interactúan con el
sistema.



3.4.1.3. Diagrama de Caso de Uso - Registro Pasajero.

Tabla del Caso de Uso – Registro Pasajeros.

CU: Registro de Pasajeros
Actores: Cliente, Asistente de Ventas
Propósito: Registra a los clientes en la BD del sistema
El Asistente de Ventas registra al cliente en la Base
Resumen: de Datos del sistema para realizar ya sea venta o
reserva en un determinado itinerario.
Tipo: Primario y esencial.
Referencias Cruzadas: R1.1, R1.2, R1.3, R1.4



3.4.1.4. CU - Realiza Venta y Reserva de Pasajes.

Tabla del Caso de Uso – Realiza Venta y Reserva de
Pasajes.

CU: Raliza Venta y Reserva de Pasajes
Actores: Cliente, Asistente de Ventas
Realiza una venta o una reserva para luego
Propósito: registrarlo en la Base de Datos del sistema.

El cliente consulta itinerarios, si existe consulta
disponibilidad de asientos para luego indicar el tipo
Resumen: de transacción que desea, se registra la venta o la
reserva, el cliente realiza el respectivo pago del
servicio y se le hace la entrega del comprobante
para su viaje.
Referencias Cruzadas: R2.1, R2.2, R2.3, R2.4



3.4.1.5. Diagrama de Caso de Uso Consulta Reportes.

Tabla del Caso de Uso – Consulta Reportes.

CU: Consulta Reportes
Actores: Dirección, Asistente de Ventas
Propósito: Realizar conteo de ventas
La dirección solicita un reporte detallado del
inventario de actividades de un periodo
Resumen: determinado, el Asistente de Ventas consulta al
sistema la cantidad de ventas y reservas según lo
solicitado por la Dirección.
Referencias Cruzadas: R4.1, R4.2, R4.3



3.4.2. Diseño de Diagramas de Secuencia.
Un diagrama de secuencia es una forma dediagrama de interacción
que muestra los objetoscomo líneas de vida a lo largo de la página y
consus interacciones en el tiempo representadascomo mensajes
dibujados como flechas desde lalínea de vida origen hasta la línea de
vida destino.Los diagramas de secuencia son buenos paramostrar qué
objetos se comunican con qué otrosobjetos y qué mensajes disparan
esascomunicaciones. Los diagramas de secuencia noestán pensados
para mostrar lógicas deprocedimientos complejos.

A continuación se muestran los Diagramas de Secuencia
correspondientes al Sistema:

3.4.2.1. Diagrama de Secuencia.
 DS - Registro Pasajero.



 DS – Modifica Registro Pasajeros

3.4.2.2. D. de Secuencia-Realiza Venta y Reserva de Pasajes.



3.4.2.3. Diagrama de Secuencia - Consulta Reportes.



3.4.3. Diseño de Diagramas de Actividad.
Representa el comportamiento interno de una operación o de un caso
de uso, bajo la forma de un desarrollo por etapas, agrupadas
secuencialmente.

A continuación se muestran los Diagramas de Actividad
correspondientes al Sistema:

3.4.3.1. Diagrama de Actividad – Registro Pasajeros



3.4.3.2. Diagrama de Actividad – Realiza Venta Y Reserva de
Pasajeros.



3.4.3.3. Diagrama de Actividad – Consulta Reportes.

3.4.4. Diseño de Diagramas de Colaboración.
Los diagramas de colaboración muestran las interacciones que
ocurren entre los objetos que participan en una situación
determinada. Esta es más o menos la misma información que la
mostrada por los diagramas de secuencia, pero destacando la forma
en que las operaciones se producen en el tiempo, mientras que los
diagramas de colaboración fijan el interés en las relaciones entre los
objetos y su topología.
En los diagramas de colaboración los mensajes enviados de un
objeto a otro se representan mediante flechas, mostrando el nombre
del mensaje, los parámetros y la secuencia del mensaje. Los
diagramas de colaboración están indicados para mostrar una
situación o flujo programa específicos y son unos de los mejores
tipos de diagramas para demostrar o explicar rápidamente un proceso
dentro de la lógica del programa.



3.4.4.1. Diagrama de Colaboración – Registro Pasajeros

3.4.4.2. Diagrama de Colaboración – Venta y Reserva de
Pasajeros.



3.4.4.3. Diagrama de Colaboración – Consulta Reportes.

3.4.5. Diseño Diagrama de Clases.



3.4.6. Diseño Diagrama Entidad Relación

3.5. Costos y Presupuestos.
3.5.1. Costos del Software:
Tabla Nº 01: Costos del Software
Windows XP S/. 100
PowerBuilder 10.0 S/. 650
Microsoft SQL Server 2008 S/. 350
Rational Rose – versión prueba S/. 0
Sub Total S/. 1100



3.5.2. Costos del Hardware:
Tabla Nº 05: Costos de Hardware
Impresora S/. 180
Computadora de Escritorio S/. 1500
Sub Total S/. 1680

3.5.3. Costos de Servicios:
Tabla Nº 02: Costos de Servicios
Movilidad S/. 20
Internet S/. 140
Fotocopias S/. 30
Anillados S/. 10
Sub Total S/. 200

3.5.4. Costos de Recursos Humanos:
Tabla Nº 03: Costos de Recursos Humanos
Especialista en Análisis y Diseño (03 meses) s/. 2550
Especialista en Programación (02 meses) s/. 1800
Sub Total s/. 4350

3.5.5. Costos de Materiales:
Tabla Nº 04: Costos de Materiales
04 Discos Compactos CD-R Sony 700Mb S/. 6
Libros S/. 80
Otros Materiales S/. 30
Sub Total S/. 116

3.5.6. Consolidado de Costos:
Tabla Nº 06: Consolidado de Costos
Costos de Software S/. 1100
Costos de Hardware S/. 1680
Costos de Servicios S/. 200
Costos de Recursos Humanos S/. 4350
Costos de Materiales S/. 116
Total S/. 7446



3.6. Plan de Contingencia.
 Comprar un UPS (Acumulador de Energía), en caso de cortes de luz.
 Disponer de Backups.
 Tener siempre activado un Antivirus.

CAPÍTULO IV
CONCLUSIONES Y
RECOMENDACIONES



CONCLUSIONES

 La recopilación de información de la organización fue gracias
al apoyo y a la constante comunicación con el usuario
(Asistente de Ventas), los ayudantes de las unidades de
transportes de los pasajeros, y los clientes. Todo esto para
realizar mejores interfaces en el sistema.
 Se analizaron los requerimientos que el área de ventas
necesitaba y para luego realizar el respectivo diseño de
procesos.
 El diseño de los diferentes procesos y actividades dentro de la
venta y reserva de pasajes se desarrolló con éxito gracias a las
herramientas de Rational Rose.
 Finalmente estoy seguro que el análisis y el diseño
desarrollado en éste proyecto para el área de ventas de la
Empresa de Transportes PERU BUS S.A.C. - Cajabamba, tiene
la factibilidad de mejorar los procesos y actividades para hacer
más eficiente el control en las ventas, como en la atención
para los clientes.



RECOMENDACIONES

Mediante todo lo aprendido en la elaboración de este proyecto,
se puede recomendar a las empresas de diferentes rubros, que
es ganancioso utilizar un software para la optimización de
distintos procesos ya que así se ahorrará tiempo y dinero y
mejorar, y también para hacer la diferencia de aquellas
organizaciones que aún no lo tienen.



CAPÍTULO V
BIBLIOGRAFÍA



BIBLIOGRAFÍA

 Fundamentos de Base de Datos.
Escritor: Silberschats
Editorial: Mc Graw Hill (2002 – Cuarta edición).

 Modelado UML.
Escritor: Cesar Liza Avila
Editorial: Grupo creadores motivando tu naturaleza creativa.

 Desarrollo de Aplicaciones.
Escritor: Carmen CachucajaVilchez
Editorial: Macro.

 Ingeniería del Software – Un enfoque práctico.
Escritor: Pressman R.
Editorial: McGraw Hill (1995 – Tercera edición).

Sitios Web:
 www.solotutoriales.com
 www.abcdatos.com
 www.google.com
 www.lawebdelprogramador.com
 www.conclase.com
 http://es.wikipedia.org/
 http://.vd.mundo.com/


PRACTICAS PRE PROFESIONALES I

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a PRACTICAS PRE PROFESIONALES I

Similar a PRACTICAS PRE PROFESIONALES I (20)

PRACTICAS PRE PROFESIONALES I