Está en la página 1de 68

AO DE LA INTEGRACIN NACIONAL Y EL

RECONOCIMIENTO DE NUESTRA DIVERSIDAD

UNIVERSIDAD SAN PEDRO

FACULTAD DE INGENIERA
Escuela Acadmica Profesional de Ingeniera Informtica y de Sistemas
Prcticas Pre-Profesionales

Docente

Proyecto

Ing. PREZ URTEAGA, Franklin Luis.

ANLISIS Y DISEO 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

DEDICATORIA

Dedico este proyecto a Dios y a mis padres. A Dios


porque ha estado conmigo a cada paso que doy,
cuidndome y dndome fortaleza para continuar, a mis
padres, quienes a lo largo de mi vida han velado por mi
bienestar y educacin 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.

AGRADECIMIENTO

Mi ms 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 informacin relevante, prxima, pero muy cercana a
la realidad de nuestras necesidades. Agradezco tambin a
mi familia por siempre brindarme su apoyo, tanto
sentimental, como econmico.

Anderson M. Castillo Vera.

INDICE
CAPTULO I : GENERALIDADES
1.1.

Descripcin de la Organizacin

1.2.

Organigrama de la Organizacin

1.3.

Situacin Problemtica

1.3.1. Seleccin del Problema

1.3.2. Antecedentes del Problema

1.3.3. Formulacin del Problema

1.3.4. Justificacin

10

1.4.

1.5.

A. Justificacin Operativa

10

B. Justificacin Econmica

11

C. Justificacin Tcnica

11

Objetivos del Proyecto

12

1.4.1. Objetivo General

12

1.4.2. Objetivo Especficos

12

Limitaciones del Proyecto

12

CAPTULO II: MARCO TERICO


2.1.

2.2.

Metodologa RUP

14

Caractersticas

14

Estructura

16

Fases

17

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 Interaccin

32

Diagramas de Secuencia

32

Diagramas de colaboracin

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. Caractersticas de ODBC

36

2.5.2. Arquitectura de ODBC

37

SQL Server 2008

37

2.6.1. Razones para elegir SQL Server

38

2.6.

CAPTULO III: APLICACIN DE LA METOLOGA RUP


3.1.

Etapa de Anlisis

40

La Organizacin

40

Misin

40

Visin

40

Equipos

40

reas de la Organizacin

40

Organigrama de la Organizacin

41

Descripcin de Actores

41

Gerente Administrador

41

Contador

42

Asistente de Ventas

42

3.2.
3.3.

3.4.

Asistente del Bus

42

Etapa de Requerimientos

43

3.2.1. Funciones Bsicas

44

Beneficios del Sistema Informtico Propuesto

46

3.3.1. Beneficios Tangibles del Software

46

3.3.2. Beneficios Intangibles

47

Etapa de Desarrollo

47

3.4.1. Diseo 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. Diseo de Diagramas de Secuencia

52

3.4.3. Diseo de Diagramas de Actividad

55

3.4.4. Diseo de Diagramas de Colaboracin

57

3.4.5. Diseo de Diagrama de Clases

59

3.4.6. Diseo de Diagrama Entidad Relacin

60

3.5.

Costeo

60

3.6.

Plan de Contingencia

62

CAPTULO IV: CONCLUSIONES Y RECOMENDACIONES


Conclusiones

63

Recomendaciones

64

CAPTULO V: BIBLIOGRAFIA
Bibliografa

66

Sitios Web

66

CAPITULO I
GENERALIDADES

1.1.

Descripcin de la organizacin:

La Empresa de Transportes PERU BUS S.A.C., nace en el ao 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 aos que siguieron a su aparicin, y de su xito da fe la
gran acogida que han experimentado, pasando as al servicio interprovincial al
finalizar el ao 2002.
La Empresa de Transportes PERU BUS S.A.C. Tiene como principal actividad
el Transporte de Servicio Pblico. Esta organizacin actualmente tiene el
permiso de las Rutas Cajabamba Cajamarca Trujillo y viceversa, Trujillo Lima y viceversa.
La Organizacin cuenta con una flota de cuatro unidades con los permisos
correspondientes de circulacin.
Las unidades ofrecen los siguientes servicios:

55 asientos cmodos y reclinables.

Aire acondicionado.

Cortinas y luz de lectura.

2 TVs y DVD, para entretenimiento.

1.2.

Organigrama de la organizacin:

1.3.

Situacin problemtica existente:

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


como:
Demora en la atencin a los clientes en el proceso de bsqueda del plano
correspondiente a la fecha indicada por el cliente, como tambin en el
llenado del pasaje.
Prdida y extravo 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 tambin en la reserva de pasajesdebido a
la falta de metodologas y formalidad en estos procesos.

Demasiado uso de material de escritorio ya sea en los planos para cada


horario de salida de las buses, boletera y manifiestos de pasajeros para la
polica, lo cual involucra tambin calcadores, lapiceros y marcadores.
La organizacin no cuenta con mecanismos adecuados para el control de
almacn. El cual est ocasionando el mal control y distribucin de los
pasajes para vender como tambin de los pasajes ya vendidos.
Problemas al solicitar algn determinado pasaje en el rea de ventas ,lo cual
est ocasionando demora en la entrega de informacin.
1.3.1. Seleccin del problema.
Despus de haber realizado un anlisis sobre los problemas que aquejan a
la Empresa de Trasportes PERU BUS S.A.C., considere el ms
importante para la realizacin del proyecto el siguiente problema:
Control deficiente en los procesos de venta como tambin de reserva
de pasajes debido a la falta de metodologas y formalidad en estos
procesos.
1.3.2. Formulacin interrogativa del problema:
Cmo analizar y disear 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 INGENIERA
DIVISIN DE ESTUDIOS PROFESIONALES PARA
EJECUTIVOS CARRERA DE INGENIERA DE
SISTEMAS
Sistema para Reserva y Venta de Pasajes de una
Empresa de Transporte

PROYECTO PROFESIONAL PRESENTADO POR:


Alvarado Flores, Nathaly
(u921136) Nez Gonzlez,
Nelzon (u913732) Callupe
Dvila, Ral Eduardo (u913819)
PARA EL CURSO DE DESARROLLO PARA ENTORNO
WEB PROFESOR:
ING. DAVID RODRGUEZ CONDEZO
Lima, 17 de Enero de 2010

UNIVERSIDAD CATLICA DEL NORTE


FACULTAD DE INGENIERA Y CIENCIAS GEOLGICAS
Departamento de Ingeniera de Sistemas y Computacin.
Antofagasta, Chile.
Ingeniera de Software I Proyecto Reserva y venta de pasajes

1.3.4. Justificacin del Proyecto:


A. Justificacin operativa.
Este proyecto traer muchos beneficios para la organizacin como
tambin para sus clientes:
-

La atencin ser ms rpida y eficiente: Esto ser posible a base


de correcciones que se vern gracias al anlisis 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

CASTILLO VERA
Anderson M.

1
0

la atencin para la venta de pasajes de la empresa antes


mencionada.
-

Agilizar la bsqueda de los pasajes ya vendidos: La Empresa de


Trasportes PERU BUS S.A.C., podr obtener un almacn 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. Justificacin Econmica.
-

Reducir costos en material de escritorio.

Reduccin de personal.

Permitir un mejor control de inventarios, reduciendo as la


perdida de productos los cuales ocasionaban perdidas a la
empresa.

Permitir la atencin a ms clientes lo que ocasionar ms


ingresos econmicos para la empresa.

C. Justificacin Tcnica.
-

Brindar el servicio de venta de pasajes, en forma eficiente.

Permitir el ahorro de tiempo.

La realizacin del anlisis se desarrollar con una metodologa a


medida.

Brindara a la organizacin un soporte de informacin adecuada


para el desarrollo de sus procesos ya sea en la venta o en la
reserva de pasajes.

CASTILLO VERA
Anderson M.

1
1

1.4.

Objetivos del proyecto.


1.4.1. Objetivo General:
El objetivo general es:
Analizar y Disear los procesos de informacin en la reserva y venta
de pasajes de la Empresa de Trasportes PERU BUS S.A.C.
1.4.2. Objetivos Especficos:
Recopilar informacin del departamento de ventas mediante la
comunicacin 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 direccin de de la Empresa de Trasportes PERU
BUS S.A.C.
Analizar los requerimientos necesarios para el desarrollo del
proyecto.
Disear 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 ms eficientes los procesos para la reserva y venta de pasajes
de la Empresa de Transportes PERU BUS S.A.C
Mejorar la atencin a los clientes mediante el anlisis y el diseo 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 informacin requerida por
falta de conocimientos administrativos.
El anlisis 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 informacin que podra facilitar en el

desarrollo del proyecto.

CAPITULO II
MARCO TEORICO

CASTILLO VERA
Anderson M.

1
3

2.

Descripcin de la Metodologa
Para este proyecto utilizaremos la metodologa RationalUnifiedProcess (RUP).
2.1. Metodologa (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 ms 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 especficos.
De la misma forma, el Proceso Unificado de Rational, tambin 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.

Caractersticas Esenciales:
Proceso Iterativo e Incremental.- El Proceso Unificado es un marco de
desarrollo iterativo e incremental compuesto de cuatro

fases

denominadas Inicio, Elaboracin, Construccin y Transicin. Cada una


de estas fases es a su vez dividida en una serie de iteraciones (la de inicio
slo consta de varias iteraciones en proyectos grandes). Estas iteraciones
ofrecen como resultado un incremento del producto desarrollado que
aade 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 clsico o en
cascada: Anlisis de requisitos, Diseo, Implementacin y Prueba.
Aunque todas las iteraciones suelen incluir trabajo en casi todas las

disciplinas, el grado de esfuerzo dentro de cada una de ellas vara 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 iteracin
tome un conjunto de casos de uso o escenarios y desarrolle todo el
camino a travs de las distintas disciplinas: diseo, implementacin,
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 mltiples modelos y vistas que definen la
arquitectura de software de un sistema. La analoga con la construccin
es clara, cuando construyes un edificio existen diversos planos que
incluyen los distintos servicios del mismo: electricidad, fontanera, etc.
Enfocado en los riesgos.- El Proceso Unificado requiere que el equipo
del proyecto se centre en identificar los riesgos crticos en una etapa
temprana del ciclo de vida. Los resultados de cada iteracin, en especial

los de la fase de Elaboracin deben ser seleccionados en un orden que


asegure que los riesgos principales son considerados primero.

Estructura de la Metodologa RUP


El RationalUnifiedProcess o Proceso Unificado de Racional. Es un
proceso de ingeniera de software que suministra un enfoque para asignar
tareas y responsabilidades dentro de una organizacin de desarrollo. Su
objetivo es asegurar la produccin de software de alta calidad que
satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto
previsible. Es una metodologa 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 especfica acceda a la
misma base de datos de conocimiento. Esto hace que todos compartan el
mismo lenguaje, la misma visin y el mismo proceso acerca de cmo
desarrollar software.

Estructura de la metologa RUP

Estructura de la metologa RUP, veremos una implementacin 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 nmero variable
a) Fases de la Metodologa RUP
Las primeras iteraciones (en las fases de Inicio y Elaboracin) se
enfocan hacia la comprensin del problema y la tecnologa, la
delimitacin del mbito del proyecto, la eliminacin de los riesgos
crticos, 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 Elaboracin.- Durante esta fase de elaboracin, las
iteraciones se centran al desarrollo de la base de la diseo, encierran
ms los flujos de trabajo de requerimientos, modelo de la
organizacin, anlisis, diseo y una parte de implementacin orientada
a la base de la construccin
Fase de Construccin.- Durante esta fase de construccin, se lleva a
cabo la construccin del producto por medio de una serie de
iteraciones las cuales se seleccionan algunos Casos de Uso, se
redefine su anlisis y diseo y se procede a su implantacin y pruebas.
En esta fase se realiza una pequea cascada para cada ciclo,
realizan

tantas iteraciones hasta

que

se termine

la

se

nueva

implementacin del producto.


Fase de Transicin.- Durante esta fase de transicin busca garantizar
que se tiene un producto preparado para su entrega al usuario.
Principales Caractersticas:

Forma disciplinada de asignar tareas y responsabilidades (quin


hace qu, cundo y cmo).

Pretende implementar las mejores prcticas en Ingeniera de


Software.

Desarrollo iterativo.

Administracin de requisitos.

Uso de arquitectura basada en componentes.

Control de cambios.

Modelado visual del software.

Verificacin 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 cdigo
fuente, etc.) y roles (papel que desempea una persona en un
determinado momento, una persona puede desempear distintos roles
a lo largo del proceso).
b) Especificacin 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 seccin son:

Modelado de negocio.

Requisitos.

Anlisis y Diseo.

Implementacin.

Pruebas.

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

Gestin del cambio y configuraciones

Gestin del proyecto

Entorn
o

La estructura dinmica 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(Tambin llamado Incepcin).

Elaboracin.

Desarrollo(Tambin llamado Implementacin, Construccin).

Cierre (Tambin llamado Transicin).

c) Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica)
realiza una serie de artefactos que sirven para comprender mejor tanto
el anlisis como el diseo del sistema estos artefactos son los
siguientes:
Inicio:

Documento Visin

Especificacin de Requerimientos

Elaboracin:

Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:

Vista Lgica:

Diagrama de clases

Modelo E-R (Si el sistema as lo requiere)

Vista de Implementacin:

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboracin
Vista Conceptual:

Modelo de dominio
Vista fsica:

Mapa de comportamiento a nivel de hardware.

d) Implementacin de RUP para el Proyecto


La metodologa RUP es ms apropiada para proyectos grandes
(Aunque tambin pequeos), dado que requiere un equipo de trabajo
capaz de administrar un proceso complejo en varias etapas. En
proyectos pequeos, es posible que no se puedan cubrir los costos de
dedicacin del equipo de profesionales necesarios.

CASTILLO VERA
Anderson M.

2
0

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 Ingeniera del
software, es usado para el anlisis, modelado, diseo y construccin
del objeto orientado.Esta dentro de las herramientas de modelamiento
visualSoporte mltiple para el manejo del modelamiento de la
arquitectura.

Para qu sirve?
Sirve para el anlisis y diseno de sistemas basados en objetos. Rose es
usado para modelar sistemas antes de llevar a cabo los trabajos de
construccin. Esta secuencia de desarrollo es importante para asegurar
la consistencia arquitectnica del sistema. Usando los modelos de
Rose Rational Rose apoya tambin al planeamiento del negocio, a
travs de representaciones que facilitan a los usuarios el mejor
entendimiento de los procesos del negocio hacindolos ms 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 diseadores puedan usar los
modelos como si fueran los planos de un sistema a ser construido (un
planoes una buena analoga para los modelos creados en Rose).
Ventajas:

Un diseo ms rpido: Las aplicaciones se crean a partir de


componentes ya existentes.

Mantenimiento ms sencillo: El enlace dinmico incrementa la


flexibilidad, permitiendo la adhesin de nuevas clases de objetos
sin modificar los actuales.

CASTILLO VERA
Anderson M.

2
1

Caractersticas:
Mantiene la consistencia de losmodelos del sistema software.
Generacin de documentacinautomticamente.
Generacin de Cdigo a partir de losModelos.
Ingeniera Inversa.
Soporte para anlisis de patrones ANSI C++, Rose J y Visual
C++ basado en "DesignPatterns: Elements of Reusable ObjectOriented Software."
Caracterstica de control por separado de componentes modelo
que permite una administracin ms granular y el uso de modelos.
Soporte de ingeniera Forward y/o reversa para algunos de los
conceptos ms comunes de Java 1.5
La generacin de cdigo Ada, ANSI C ++, C++, CORBA, Java y
Visual Basic, con capacidad de sincronizacin modelo- cdigo
configurables.
Soporte Enterprise Java Beans 2.0
Capacidad de anlisis de calidad de cdigo.
El Add-In para modelado Web provee visualizacin, modelado y
las herramientas para desarrollar aplicaciones de Web.
Modelado UML para trabajar en diseos de base de datos, con
capacidad de representar la integracin de los datos y los
requerimientos de aplicacin a travs de diseos lgicos y fsicos.
Capacidad de crear definiciones de tipo de documento XML
(DTD) para el uso en la aplicacin.
Integracin con otras herramientas de desarrollo de Rational.
Capacidad para integrarse con cualquier sistema de control de
versiones SCC-compliant, incluyendo a RationalClearCase.
Publicacin web y generacin de informes para optimizar la
comunicacin dentro del equipo.

CASTILLO VERA
Anderson M.

2
2

Sistemas Operativos y Plataformas de Hardware Apropiadas:

Windows NT
Windows XP

Rational Rose,es la mejor eleccin para el ambiente de modelado que


soporte la generacin de cdigo a partir de modelos en Ada, ANSI
C++, C++, CORBA, Java/J2EE, Visual C++ y Visual Basic.
Como todos los dems productos Rational Rose,proporciona un
lenguaje comn de modelado para el equipo que facilita la creacin
de software de calidad ms rpidamente.

2.2.2.

Lenguaje Unificado de Modelado (UML)


Un modelo UML esta compuesto por tres clases de bloques de
construccin:

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 representacin grfica 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 esttico 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 anlisis y diseo de los sistemas, donde se
crea el diseo conceptual de la informacin que se manejar en el

sistema, y los componentes que se encargaran del funcionamiento


y la relacin entre uno y otro.
Representacin de:
- Requerimientos en entidades y actuaciones.
- La arquitectura conceptual de un dominio.
- Soluciones de diseo en una arquitectura.
- Componentes de software orientados a objetos.
El diagrama de clases incluye mucha ms informacin como la
relacin entre un objeto y otro, la herencia de propiedades de otro
objeto,

conjuntos

de

operaciones/propiedades

implementadas para una interfaz grfica.

que

son

Diagrama de componentes.- Es un diagrama tipo del Lenguaje


Unificado de Modelado.
Un diagrama de componentes representa cmo un sistema de
software es dividido en componentes y muestra las dependencias
entre estos componentes. Los componentes fsicos incluyen
archivos,

cabeceras,

bibliotecas

compartidas,

mdulos,

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 ms parecidos a
los diagramas de casos de usos, stos son utilizados para modelar
la vista esttica y dinmica de un sistema. Muestra la organizacin
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 situarn libreras, 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
Anlisis y Diseo de los sistemas informticos en la metodologa
UML.
Se puede considerar un caso especial de un diagrama de clases en
el que se muestran instancias especficas 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 notacin 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 esttica 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
interactan con cada una de las otras o mediante las cuales,
instancias de la clase interactan 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 ejecucin para lograr algn propsito.
Cada elemento tiene algn rol definido en la colaboracin.
Las entidades de estructura compuesta claves identificadas en la
especificacin UML 2.0 son: clasificadores estructurados, partes,
puertas, conectores, y colaboraciones.
Parte.- Representa un rol jugado en tiempo de ejecucin por una
instancia de una clase o por una coleccin de instancias. La parte
puede nombrar solamente un rol, una superclase abstracta, o
puede nombrar una clase concreta especfica. La parte puede
incluir un factor de multiplicidad (cardinalidad).
Puerta.- Es un punto de interaccin 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 ms entidades, permitindoles
interactuar en tiempo de ejecucin. Un conector es representado
por una lnea que une una combinacin de partes, puertas y
clasificadores estructurados.
Colaboracin.-

Es

generalmente

ms

abstracta

que

un

clasificador estructurado. sta es mostrada como un valo sin


relleno conteniendo los roles que las instancias pueden jugar en la
colaboracin.
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 estn dentro de nodos. En


cambio, puede haber artefactos u otros nodos dentro de un nodo.
Este tipo de diagrama debemos tambin aadir 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 cmo un sistema est dividido
en agrupaciones lgicas mostrando las dependencias entre esas
agrupaciones. Dado que normalmente un paquete est pensado
como un directorio, los diagramas de paquetes suministran una
descomposicin de la jerarqua lgica de un sistema.
Los Paquetes estn normalmente organizados para maximizar la
coherencia interna dentro de cada paquete y minimizar el
acoplamiento externo entre los paquetes. Con estas

lneas

maestras sobre la mesa, los paquetes son buenos elementos de


gestin. 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 notacin grfica para representar casos de
uso llamada modelo de casos de uso. UML no define estndares
para que el formato escrito describa los casos de uso, y as mucha
gente no entiende que esta notacin grfica define la naturaleza de
un caso de uso; sin embargo una notacin grfica 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 estndar UML, el cual describe notacin grfica
para esas relaciones. Veamos una revisin de ellas a continuacin:
Inclusin (include o use).- Es una forma de interaccin o
creacin, 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 mltiples casos de uso a una


descripcin individual, desde el caso de uso. El estndar de
Lenguaje de Modelado Unificado de OMG define una notacin
grfica para realizar diagramas de casos de uso, pero no el
formato para describir casos de uso. Mucha gente sufre la
equivocacin pensando que un caso de uso es una notacin
grfica (o es su descripcin). Mientras la notacin grfica y las
descripciones esto no sirve.
Extensin (Extend).- Es otra forma de interaccin, un caso de
uso dado (la extensin) puede extender a otro. Esta relacin indica
que el comportamiento del caso de la extensin se utiliza en casos
de uso, un caso de uso a otro caso siempre debe tener extensin o
inclusin. El caso de uso extensin puede ser insertado en el caso
de uso extendido bajo ciertas condiciones. La notacin, es una
flecha de punta abierta con lnea discontinua, desde el caso de uso
extensin 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
extensin.
"La extensin, es el conjunto de objetos a los que se aplica un
concepto. Los objetos de la extensin son los ejemplos o
instancias de los conceptos."
Generalizacin.- Es la actividad de identificar elementos en
comn entre conceptos y definir las relaciones de una superclase
(concepto general) y subclase (concepto especializado). Es una
manera de construir clasificaciones taxonmicas entre conceptos
que entonces se representan en jerarquas de clases. Las subclases
conceptuales son conformes con las superclases conceptuales en
cuanto a la intencin y extensin.

CASTILLO VERA
Anderson M.

3
0

Los diagramas de casos de uso son a menudo confundidos con


los casos de uso. Mientras los dos conceptos estn relacionados,
los casos de uso son mucho ms 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 aplicacin en
respuesta a eventos (por ejemplo, mensajes recibidos, tiempo
rebasado o errores), junto con sus respuestas y acciones. Tambin
CASTILLO VERA
Anderson M.

3
1

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 Interaccin.- 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 interaccin entre objetos en un sistema segn UML.
Un diagrama de secuencia muestra la interaccin de un conjunto
de objetos en una aplicacin a travs 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 implementacin del
escenario, incluyendo los objetos y clases que se usan para
implementar el escenario, y mensajes intercambiados entre los
objetos.
Tpicamente se examina la descripcin de un caso de uso para
determinar qu objetos son necesarios para la implementacin del
escenario. Si se dispone de la descripcin 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 lneas
discontinuas verticales, y los mensajes pasados entre los objetos
como flechas horizontales.

Diagrama de Colaboracin.- Modela las interacciones entre


objetos o partes en trminos de mensajes en secuencia. Los
diagramas de colaboracin representan una combinacin de
informacin tomada desde el diagrama de clases, secuencia, y
diagrama de casos de uso describiendo tanto la estructura esttica
como el comportamiento dinmico de un sistema.
Los diagramas de colaboracin y de secuencia describen
informacin similar, y con ciertas transformaciones, pueden ser
transformados unos en otros sin dificultad.

Para mantener el orden de los mensajes en un diagrama de


colaboracin, los mensajes son etiquetados con un nmero
cronolgico, y colocados cerca del enlace por el cual se desplaza
el mensaje. Leer un diagrama de colaboracin 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 caracterstica que el sistema DEBE tener o es


una restriccin que el sistema DEBE satisfacer para ser aceptada por el
cliente.

Levantamiento de requerimientos, es la especificacin del sistema en


trminos 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 grfico de programacin que est compuesto de
diferentes herramientas que permiten el desarrollo rpido de aplicaciones.
Con estas herramientas se pueden desarrollar aplicaciones Cliente / Servidor a
travs de ODBC (Open DataBase Connectivity) o Drivers Nativos para la
Base de Datos. Una aplicacin Cliente / Servidor pone en comunicacin una
estacin de trabajo con un Servidor de Base de Datos Central. Este modelo
consiste en utilizar una Base de Datos que reside en una mquina separada
denominada Servidor. El Software de gestin 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 caractersticas de herencia, polimorfismo
y encapsulacin.

Es un sistema de desarrollo de aplicaciones para creado por Powersoft, que


luego fue comprado por Sybase. PowerBuilder incluye herramientas para la
creacin 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 creacin de aplicaciones de forma rpida.
PowerBuilder es utilizado principalmente para la creacin de aplicaciones de
negocios, aunque tambin posee versiones para crear aplicaciones para
dispositivos mviles.

2.5. ODBC (Open Data Base Conectivity)


O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos
una aplicacin para acceder a las tablas de una DB de Access, qu ocurrir si
despus queremos que la misma aplicacin, y sin reescribir nada, utilice
tablas de SQL Server u otra DB cualquiera? La respuesta es sencilla: no
funcionar. Nuestra aplicacin, diseada para un motor concreto, no sabr
dialogar con el otro. Evidentemente, si todas las DB funcionaran igual, no
tendramos 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 tendramos que ir cambiando
este elemento, y nuestra aplicacin siempre funcionara sin importar lo que
hay al otro lado... algo as como ir cambiando las boquillas de una manguera.
A esas piezas intercambiables las llamaremos orgenes 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 aplicacin, como velocidad de proceso, tiempos de espera,
mxima longitud de registro, nmero mximo de registros, versin de SQL,
etc., est cayendo en desuso a cambio de otras tcnicas de programacin, pero
an le quedan muchos aos 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, tambin funciona con las versiones modernas de servidores como
2003 Server, y tambin XP PRO, que lleva un IIS 5.0 de serie. Igualmente es
posible utilizar bases de datos de Access 2000 o 2003.
Esas otras tcnicas de programacin antes mencionadas, se utilizan ya en el
nuevo Windows 2003, Office 2003 y SQL Server 2000, que adems de
ODBC pueden utilizar.... pero esa es otra historia.
Esta es la idea: por un lado el ODBC provee de unas caracteristicas siempre
homogneas, y por el otro permite distintos controladores que aseguran la
conectividad de la aplicacin con diferentes bases de datos.

2.5.1. Caractersticas ODBC:


Entre sus principales caracterstcas destacan:

ODBC es una interfaz de programacin de aplicaciones estndar


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 travs de
redes de comunicacin es transparente.

Permite a mltiples aplicaciones acceder a mltiples orgenes de


datos.

Proporciona un modelo de programacin homogneo, es decir,


bases de datos muy diferentes se manejan, va ODBC, como si
fueran idnticas, 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


segn lo demanden las aplicaciones.

Drivers: Procesan las llamadas a las funciones ODBC, ejecutan


sentencias SQL y devuelven los resultados a las aplicaciones. Son
tambin responsables de interactuar con cualquier capa software
necesaria para acceder a las fuentes de datos, como puede ser el
software de red.

Orgenes de datos: Consisten en conjuntos de datos, ms todo lo


que pueda ser necesario para llegar hasta ellos; sistemas
operativos, gestores de bases de datos, redes de comunicacin,
etc.

2.6. SQL Server 2008


Microsoft SQL Server es una base de datos de servidor y una plataforma de
informacin integral que ofrece un completo conjunto de tecnologas y
herramientas para la empresa que ayudan a las personas a obtener el mximo
valor de la informacin con el menor coste total de propiedad. Benefciese de
altos niveles de rendimiento, disponibilidad y seguridad, desarrolla una
gestin ms productiva y herramientas de desarrollo, y ofrece una perspectiva
generalizada con Business Intelligence autoservicio (BI).
Una plataforma completa e integrada, Microsoft SQL Server lo rene todo
para obtener ms valor de las actuales capacidades de TI, aumentando la
productividad y la agilidad de los departamentos de TI, y creando
rpidamente aplicaciones flexibles e innovadoras.
2.6.1. Razones para elegir SQL Server
Las bases de datos de Microsoft ejecutan ms bases de datos de
misin crtica en comparacin 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.
Lder

indiscutible

en

pruebas

de

rendimiento

TPC-E.

SQL Server ofrece un ahorro de 460% en el coste anual de


administracin por cada base de datos sobre Oracle.
Microsoft se posiciona como un lder en el Cuadrante Mgico
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 ao 2009.
SQL Server reduce el tiempo de inactividad ms del 20% por la
migracin de un entorno SAP ERP a SQL Server.

CAPITULO III
APLICACIN DE LA
METODOLOGIA

3.

APLICACIN DE LA METODOLOGA
3.1. Etapa deAnlisis.

La Organizacin:
Razn Social: Empresa de Transportes PERU BUS S.A.C.
RUC: 20439261791
Gerente Administradora: CUEVA DE SANTOS, Dolores Resurreccin.
Ubicacin: Jr. Miguel Grau N 141 - Cajabamba.
Nuestra Misin:
Brindar un servicio de primera calidad en el transporte de pasajeros,
cumpliendo con los estndares 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 atrs nuestros valores y races.
Nuestra Visin:
Ser una empresa de transporte de pasajeros reconocida a nivel nacional,
cubriendo las principales rutas de nuestro pas, y satisfacer as las
exigencias y expectativas de nuestros clientes, teniendo costos
competitivos en el mercado.

Equipos con los que cuenta la organizacin.


Un Telfono.

reas de la Organizacin.
Gerencia.
Contabilidad.
Boletera.

CASTILLO VERA
Anderson M.

4
0

Organigrama de la Organizacin.

Descripcin 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 tambin de administrar los
diferentes recursos de la misma.
Funciones:

CASTILLO VERA
Anderson M.

Revisar agenda de cobros y pagos.

Elaborar cartera de clientes.

Realizar operaciones bancarias.

Supervisin de inventarios y cotizaciones.

Autorizacin de procesos en la organizacin.


4
1

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

Atencin 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 liquidacin de ventas de turno.

DESCRIPCIN DE LOS ACTORES


Actores

Imagen

Asistent
e de
Ventas

Cliente

Direccin

Casos de Uso

Registra Pasajeros.
Realiza venta y reserva de pasajes.
Liquidacin de turno de ventas.
Manifiesto de pasajeros.
Reportes.

Realiza consulta de Itinerarios.


Indica tipo de transaccin.
Consulta disponibilidad de asientos.
Determina nmero de asiento(s).
Realiza pago.
Reclama comprobante de pago.
Realiza consulta y reportes.
Conocimiento cantidad de ventas y reservas.
Conocimiento cantidad de ventas y reservas.
Liquidacin de turno.
Manifiesto de pasajeros.

Registra pasajeros.
Realiza venta y reserva de pasajes.
Liquidacin de turno.
Manifiesto de pasajeros.

Asistente
del
Bus

3.2. Etapa de Requerimientos


Un proyecto no puede ser exitoso sin una especificacin correcta y
exhaustiva de los requerimientos, donde describe las necesidades o deseos de
un producto.

Registro de ventas.

Verificacin rpida de disponibilidad de asientos.

Realizar el seguimiento y control de venta de pasajes.

Conocer de manera especfica los pasajeros permanentes de la


organizacin, con la finalidad de premiarlos incentivarlos por su
preferencia.

Realizar reportes detallados, en los cuales se pueda obserbar de manera


fcil los procesos que se dan en la organizacin, 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 Bsicas.


Las funciones bsicas del sistema son lo que sta deber hacer. stas
funciones o requerimientos, se detallan a continuacin, asignndoles
adems una categora.
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 mdulo especfico, la segunda columna describe las
funciones en s, que engloban un mdulo, y la tercera columna
muestra las clasificaciones que pueden tener cada funcin, y entre
ellas estn:
Evidente: Funcin que debe realizarse, y el usuario debera
saber que se a realizado.
Oculto: Debe realizarse, aunque no es visible para los usuarios.
Superflua:

Opcionales,

su

inclusin

no

significativamente en el costo ni en otras funciones.

repercute

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:
Funcin
#
R1.1 Se ingresa datos al registro de pasajeros
R1.2 Se verifica la existencia del pasajero
en Base de Datos

Categor
a
Evidente
Oculta

R1.3 El sistema registra Datos de pasajero


R1.4 Genera reporte de pasajero registrado.

Evidente
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
Ref:
#
Funcin
R2.1 Registro venta de pasajes.
R2.2 Verifica el tipo de transaccin e itinerarios.

PASAJES
Categor
a
Evident
e
Evident
e
Oculta

R2.3 Incrementa las cantidades del


inventario cuando realiza una venta.
R2.4 Genera reporte de entrada de nueva venta.
R2.5 Genera reporte de venta o reserva de
pasajes.

Oculta
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
Funcin

Ref:
#
R3.1 Recibe un determino itinerario para
realizar viaje
R3.2 Selecciona asientos disponibles
El sistema registra los asientos
R3.3
vendidos o reservados

R3.4 Reduce la disponibilidad en itinerario


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

Categor
a
Evidente
Evidente
Evidente
Oculta
Oculta

3.2.5. Tabla Muestra Reportes.


Muestra como se dan los reportes finales.
4. MUESTRA REPORTES
Ref:
Funcin
#
Verifica cantidades de pasajes
R4.1 vendidos y reserbados.

Categor
a
Evidente

R4.2 Registra faltantes.


R4.3 Genera reporte detallado.

Oculta
Evidente

3.3. Beneficios del Sistema Informtico propuesto.


Los beneficios obtenidos con el Sistema Informtico, 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 bsicamente
el tiempo de espera para los procesos para entonces poder hacer de la
atencin el mejor servicio de la organizacin.
3.3.1. Beneficios Tangibles del Software.
Beneficios tangibles que se obtendrn 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 ningn trayecto o
proceso manualmente ya que toda la informacin se encontrara
en la base de datos del sistema para hacer dichos reportes.

Eficiencia.- Los datos se encontraran en todo momento


actualizados, esto es, sern recuperados, consultados y
actualizados directamente desde la base de datos del sistema.
El tiempo de respuesta, y la ocupacin del encargado del rea, se
vern 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 rpido,


nuevo y actualizado que brinda la empresa.

Brindar informacin clara, oportuna y precisa respecto a los


reportes de ventas.

3.4. Etapa de Desarrollo.


3.4.1. Diseo 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 cmo ser


diseado el sistema, en cmo los actores interactan con el
sistema.

3.4.1.3. Diagrama de Caso de Uso - Registro Pasajero.

Tabla del Caso de Uso Registro Pasajeros.


CU:
Actores:
Propsito:
Resumen:
Tipo:
Referencias
Cruzadas:

Registro de Pasajeros
Cliente, Asistente de Ventas
Registra a los clientes en la BD del sistema
El Asistente de Ventas registra al cliente
en la Base de Datos del sistema para
realizar ya sea venta o reserva en un
determinado
itinerario.
Primario y esencial.
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:
Actores:
Propsito:

Resumen:

Tipo:
Referencias
Cruzadas:

CASTILLO VERA
Anderson M.

Raliza Venta y Reserva de Pasajes


Cliente, Asistente de Ventas
Realiza una venta o una reserva
para luego registrarlo en la Base
de Datos del sistema.
El cliente consulta itinerarios, si existe
consulta disponibilidad de asientos para
luego indicar el tipo de transaccin 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.
Primario y esencial.
R2.1, R2.2, R2.3, R2.4

5
0

3.4.1.5. Diagrama de Caso de Uso Consulta Reportes.

Tabla del Caso de Uso Consulta Reportes.


CU:
Actores:
Propsito:

Resumen:

Tipo:
Referencias
Cruzadas:

CASTILLO VERA
Anderson M.

Consulta Reportes
Direccin, Asistente de Ventas
Realizar conteo de ventas
La direccin solicita un reporte
detallado del inventario de actividades
de un periodo determinado, el
Asistente de Ventas consulta al sistema
la cantidad de ventas y reservas segn
lo solicitado por la Direccin.
Primario y esencial.
R4.1, R4.2, R4.3

5
1

3.4.2. Diseo de Diagramas de Secuencia.


Un diagrama de secuencia es una forma dediagrama de interaccin
que muestra los objetoscomo lneas de vida a lo largo de la pgina y
consus interacciones en el tiempo representadascomo mensajes
dibujados como flechas desde lalnea de vida origen hasta la lnea 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 noestn pensados
para mostrar lgicas deprocedimientos complejos.
A continuacin 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. Diseo de Diagramas de Actividad.


Representa el comportamiento interno de una operacin o de un caso
de uso, bajo la forma de un desarrollo por etapas, agrupadas
secuencialmente.
A continuacin se

muestran

los Diagramas

correspondientes al Sistema:
3.4.3.1.

Diagrama de Actividad Registro Pasajeros

de Actividad

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. Diseo de Diagramas de Colaboracin.


Los diagramas de colaboracin muestran las interacciones que
ocurren entre los objetos que participan en una situacin
determinada. Esta es ms o menos la misma informacin 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 colaboracin fijan el inters en las relaciones entre los
objetos y su topologa.
En los diagramas de colaboracin los mensajes enviados de un
objeto a otro se representan mediante flechas, mostrando el nombre
del mensaje, los parmetros y la secuencia del mensaje. Los
diagramas de colaboracin estn indicados para mostrar

una

situacin o flujo programa especficos y son unos de los mejores


tipos de diagramas para demostrar o explicar rpidamente un proceso
dentro de la lgica del programa.

3.4.4.1. Diagrama de Colaboracin Registro Pasajeros

3.4.4.2. Diagrama de Colaboracin Venta y Reserva de


Pasajeros.

3.4.4.3. Diagrama de Colaboracin Consulta Reportes.

3.4.5. Diseo Diagrama de Clases.

3.4.6. Diseo Diagrama Entidad Relacin

3.5. Costos y Presupuestos.


3.5.1. Costos del Software:
Tabla N 01: Costos del Software
Windows XP
S/.
PowerBuilder 10.0
S/.
Microsoft SQL Server 2008
S/.
Rational Rose versin prueba
S/.
Sub Total S/.

CASTILLO VERA
Anderson M.

10
0
65
0
35
00
110
0

6
0

3.5.2. Costos del Hardware:


Tabla N 05: Costos de Hardware
Impresora
S/.
Computadora de Escritorio
S/.
Sub Total S/.

18
0
150
0
168
0

3.5.3. Costos de Servicios:


Movilidad
Internet
Fotocopias
Anillados

Tabla N 02: Costos de Servicios


S/.
S/.
S/.
S/.
Sub Total S/.

20
140
30
10
200

3.5.4. Costos de Recursos Humanos:


Tabla N 03: Costos de Recursos Humanos
Especialista en Anlisis y Diseo (03 meses) s/. 255
Especialista en Programacin (02 meses)
s/. 0
180
Sub Total s/. 0
435
0

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/. 11
6

3.5.6. Consolidado de Costos:


Costos
Costos
Costos
Costos
Costos

CASTILLO VERA
Anderson M.

de
de
de
de
de

Tabla N 06: Consolidado de Costos


Software
S/.
Hardware
S/.
Servicios
S/.
Recursos Humanos
S/.
Materiales
S/.
Total S/.

110
0
168
020
0
435
011
6
744
6
6
1

3.6. Plan de Contingencia.


Comprar un UPS (Acumulador de Energa), en caso de cortes de luz.
Disponer de Backups.
Tener siempre activado un Antivirus.

CAPTULO IV
CONCLUSIONES Y
RECOMENDACIONES

CONCLUSIONES

La recopilacin de informacin de la organizacin fue gracias


al apoyo y a la constante comunicacin 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 diseo de
procesos.
El diseo 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 anlisis y el diseo
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
ms eficiente el control en las ventas, como en la atencin
para los clientes.

RECOMENDACIONES

Mediante todo lo aprendido en la elaboracin de este proyecto,


se puede recomendar a las empresas de diferentes rubros, que
es ganancioso utilizar un software para la optimizacin de
distintos procesos ya que as se ahorrar tiempo y dinero y
mejorar, y tambin para hacer la diferencia de aquellas
organizaciones que an no lo tienen.

CAPTULO V
BIBLIOGRAFA

BIBLIOGRAFA

Fundamentos de Base de Datos.


Escritor: Silberschats
Editorial: Mc Graw Hill (2002 Cuarta edicin).

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

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

Ingeniera del Software Un enfoque prctico.


Escritor: Pressman R.
Editorial: McGraw Hill (1995 Tercera edicin).
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/

También podría gustarte