practicas pre profecionales proyectofinal.docx

106
“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.

Upload: gonzalezalfredo

Post on 22-Dec-2015

39 views

Category:

Documents


7 download

TRANSCRIPT

“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

CASTILLO VERA Anderson 1

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

INDICECAPÍ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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

CAPITULO I

GENERALIDADES

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 7

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 8

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 9

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

CASTILLO VERA Anderson 1

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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

CASTILLO VERA Anderson 1

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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.

CASTILLO VERA Anderson 1

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CAPITULO II

MARCO TEORICO

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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:

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 1

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:

CASTILLO VERA Anderson 2

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

CASTILLO VERA Anderson 2

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

CASTILLO VERA Anderson 2

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 2

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

CASTILLO VERA Anderson 3

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

CASTILLO VERA Anderson 3

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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).

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 3

CAPITULO III APLICACIÓN DE LAMETODOLOGIA

CASTILLO VERA Anderson 4

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

CASTILLO VERA Anderson 4

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

DESCRIPCIÓN DE LOS ACTORES

Actores Imagen Casos de Uso

Asistente de Ventas

Registra Pasajeros. Realiza venta y reserva de pasajes. Liquidación de turno de ventas. Manifiesto de pasajeros. Reportes.

Cliente

Realiza consulta de Itinerarios. Indica tipo de transacción. Consulta disponibilidad de asientos. Determina número de asiento(s). Realiza pago. Reclama comprobante de pago.

Dirección

Realiza consulta y reportes.

Conocimiento cantidad de ventas y reservas.

Conocimiento cantidad de ventas y reservas. Liquidación de turno. Manifiesto de pasajeros.

Asistente del Bus

Registra pasajeros.

Realiza venta y reserva de pasajes.

Liquidación de turno.

Manifiesto de pasajeros.

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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 PASAJERORef: # Función CategoríaR1.1 Se ingresa datos al registro de pasajeros Evidente

R1.2 Se verifica la existencia del pasajero en Base de Datos

Oculta

R1.3 El sistema registra Datos de pasajero EvidenteR1.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 PASAJESRef:

# Función CategoríaR2.1 Registro venta de pasajes. EvidenteR2.2 Verifica el tipo de transacción e itinerarios. Evidente

R2.3 Incrementa las cantidades del inventario cuando realiza una venta.

Oculta

R2.4 Genera reporte de entrada de nueva venta. OcultaR2.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 ITENERARIOSRef: # Función Categoría

R3.1 Recibe un determino itinerario para realizar viaje Evidente

R3.2 Selecciona asientos disponibles Evidente

R3.3 El sistema registra los asientos vendidos o reservados

Evidente

R3.4 Reduce la disponibilidad en itinerario indicado Oculta

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

3.2.5. Tabla Muestra Reportes.

Muestra como se dan los reportes finales.

4. MUESTRA REPORTESRef: # Función Categoría

R4.1Verifica cantidades de pasajes vendidos y reserbados. Evidente

R4.2 Registra faltantes. OcultaR4.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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 4

3.4.1.3. Diagrama de Caso de Uso - Registro Pasajero.

Tabla del Caso de Uso – Registro Pasajeros.

CU: Registro de PasajerosActores: Cliente, Asistente de VentasPropósito: Registra a los clientes en la BD del sistema

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

Tipo: Primario y esencial.Referencias Cruzadas: R1.1, R1.2, R1.3, R1.4

CASTILLO VERA Anderson 5

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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 PasajesActores: Cliente, Asistente de Ventas

Propósito:Realiza una venta o una reserva para luego registrarlo en la Base de Datos del sistema.

Resumen:

El cliente consulta itinerarios, si existe consulta disponibilidad de asientos para luego indicar el tipo 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.

Tipo: Primario y esencial.Referencias Cruzadas: R2.1, R2.2, R2.3, R2.4

CASTILLO VERA Anderson 5

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

3.4.1.5. Diagrama de Caso de Uso Consulta Reportes.

Tabla del Caso de Uso – Consulta Reportes.

CU: Consulta ReportesActores: Dirección, Asistente de VentasPropósito: Realizar conteo de ventas

Resumen:

La dirección 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 según lo solicitado por la Dirección.

Tipo: Primario y esencial.Referencias Cruzadas: R4.1, R4.2, R4.3

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

DS – Modifica Registro Pasajeros

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

3.4.2.3. Diagrama de Secuencia - Consulta Reportes.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

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

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

3.4.3.2. Diagrama de Actividad – Realiza Venta Y Reserva de

Pasajeros.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

3.4.4.1. Diagrama de Colaboración – Registro Pasajeros

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

Pasajeros.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 5

3.4.4.3. Diagrama de Colaboración – Consulta Reportes.

3.4.5. Diseño Diagrama de Clases.

CASTILLO VERA Anderson 6

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

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 SoftwareWindows XP S/. 100PowerBuilder 10.0 S/. 650Microsoft SQL Server 2008 S/. 350Rational Rose – versión prueba S/. 0

Sub Total S/. 1100

CASTILLO VERA Anderson 6

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

3.5.2. Costos del Hardware:

Tabla Nº 05: Costos de HardwareImpresora S/. 180Computadora de Escritorio S/. 1500

Sub Total S/. 1680

3.5.3. Costos de Servicios:

Tabla Nº 02: Costos de ServiciosMovilidad S/. 20Internet S/. 140Fotocopias S/. 30Anillados S/. 10

Sub Total S/. 200

3.5.4. Costos de Recursos Humanos:

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

Sub Total s/. 4350

3.5.5. Costos de Materiales:

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

Sub Total S/. 116

3.5.6. Consolidado de Costos:

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

Total S/. 7446

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

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 YRECOMENDACIONES

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

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.

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

CAPÍTULO V

BIBLIOGRAFÍA

UNIVERSIDAD SAN PEDRO

ESCUELA PROFECIONAL DE INGENIERÍA INFORMÁTICA Y DE SISTEMAS

CASTILLO VERA Anderson 6

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/