INSTITUTO DE EDUCACIÓN SUPERIOR

TECNOLÓGICO PÚBLICO DE HUARMEY

CARRERA PROFESIONAL

COMPUTACIÓN E INFORMÁTICA

“ANALISIS Y DISEÑO DE SISTEMA PARA

MEJORAR EL CONTROL DE CABINAS DE
INTERNET “RUBI“, UTILIZANDO LA
METODOLOGIA RUP EN EL AÑO 2016”.

AUTORA:

Chang Sánchez, Fiorella Rosmery.

ASESOR:

Mg. Antúnez Carrillo, Dennis.

SEMESTRE:

III

Huarmey _ 2016.
DEDICATORIA

El presente informe está dedicado con mucho amor a

toda mi familia y a Dios Todopoderoso por haberme
brindado su apoyo incondicionalmente que gracias a
ellos cada día a día me bendicen y me guían por el
camino correcto de la vida, y del mismo modo a mis
docentes que me brindaron su apoyo en realizar mi
presente informe.

A mi madre Dila Rosmery, por ser ella que siempre

está ahí conmigo apoyándome en cualquier cosa, a mi
padre Marcial Omar y a mis abuelitos Guillermo y Celia
que siempre me brinda su ayuda y comprensión,
motivando mi continua superación profesional.

A los docentes, por su gran capacidad intelectual, por

brindarnos sus grandes conocimientos y enseñanzas
para poder alcanzar nuevos y buenos conocimientos.
 AGRADECIMIENTO

Mi gratitud al “Internet Rubí” a la administradora, Sonia Mariluz Tasayco

Yovera por haberme brindado la oportunidad de realizar mi informe en su
empresa mencionada, de esa manera y nuestros conocimientos teóricos-prácticos
se consoliden con la implementación del informe respectivo.

Le ofrezco mi cordial reconocimiento al gerente de la Empresa del

“Internet Rubí”, Sra. Sonia Mariluz Tasayco Yovera. Por su colaboración en la
ejecución del presente trabajo, y en el interés que ponen en la formación y
revaloración del presente informe.

Al asesor, Mg. Antúnez Carrillo Dennis, por su valiosa dedicación

durante nuestra formación profesional y por el desarrollo de este informe.

Fiorella Rosmery, Chang Sánchez.

 PRESENTACION

El presente informe está dominada “ANALISIS Y DISEÑO DE SISTEMA PARA

MEJORAR EL CONTROL DE CABINAS DE INTERNET “RUBI“, UTILIZANDO
SOFTWARE LICENCIADO CON LA METODOLOGIA RUP EN EL AÑO 2016”.

Este informe nace por la importancia que tiene a realizar un adecuado control de
cabinas de internet, ya que permitirá aun control adecuado, pues logrando que el
encargado pueda mejorar el control de las cabinas de internet y el servicio al
usuario en el “Internet Rubí”.

En el área encargado, se puede observar los problemas que se encuentra en el

control de las cabinas de internet, lo cual se tratara de brindarle el servicio de su
control de sus máquinas y pérdida de tiempo del encargado y esperas continuas
al cliente y así poderles brindarles un buen servicio de calidad para las clientelas.

Por este molestar nace la necesidad expuesta anteriormente, los motivos por los
que se ha creído conveniente preparar y presentar el presente informe, con la
finalidad de mejorar el servicio de control de las cabinas de internet para el
usuario.

El análisis y diseño de sistema de control de cabinas de internet está orientado

para implementar en el área del encargado del dicho internet Rubí lo cual traerá
consigo muchas ventajas resaltantes, que se obtendrá con la implementación del
sistema, pues ayudara el control inmediatamente y la oportuna en las cabinas,
además se mejora la atención al cliente ayudando en buena atención inmediata y
precisa.
 RESUMEN

El siguiente informe de mi proyecto es “ANALISIS Y DISEÑO DE SISTEMA

PARA MEJORAR EL CONTROL DE CABINAS DE INTERNET “RUBI“,
UTILIZANDO SOFTWARE LICENCIADO CON LA METODOLOGIA RUP EN EL
AÑO 2016”.

El siguiente trabajo que a continuación presento contiene información teórica y

práctica para la asignatura de mi informe, cuyo objetivo es expresar los
conocimientos adquiridos a lo largo del estudio de la carrera profesional que se ha
aplicado en la empresa de control de cabinas de “Internet Rubí”.

Por tal motivo se ha desarrollado el presente informe que implica las etapas de
Análisis, Diseño y la presentación de algunos prototipos a fin de sustentar y
demostrar técnicamente la viabilidad de la implementación de un sistema de
control de cabinas de internet.

Espero que este trabajo sirva como guía para la información académica y
profesional de nuestros compañeros de Computación e Informática, quienes
necesitaran de una buena orientación para su desarrollo profesional.

El presente informe se documenta en cinco capítulos, los mismos que brevemente

se describen a continuación.

En el Capítulo I, denominado: Aspectos Generales de la empresa, se define el

negocio a evaluar, teniendo en cuenta la información detalla de su Ubicación
Geográfica, Base Legal de su creación. Áreas que comprenden, Funciones de
principales áreas y su Organigrama; así mismo su Historia y Evolución para
concluir con los servicios que presta. Esta información permitirá analizar y
conocer los órganos y personas involucradas en el proceso de cabina de internet
y Análisis de Matriz Foda.

En el capítulo II, denominado: Análisis del Sistema Actual, se especifica la fase

de recopilación de la Información la formulación del problema, descripción de los
procesos o actividades que se realizan en el sistema actual y finalmente se
concluye identificando los requerimientos.

En el capítulo III, denominado: Análisis y Diseño del Sistema Propuesto, se

explica primeramente las metodologías más usadas en la actualidad,
comparación entre el análisis y diseño orientado a objetos y análisis y diseño
estructurado. Asimismo se realiza la fundamentación de la selección de la
metodología UML y se indica software libre que se utiliza para el modelamiento.

En este capítulo de igual forma se realiza la explicación de la etapa de análisis,

definiendo los requisitos, detallando los casos esenciales de uso, diagramas de
caso de uso, modelo conceptual, diagramas de secuencia y diagrama de
actividades. En la etapa de diseño se explica el tema de los casos reales de uso,
diagrama de clase; la implementación de las bases de datos y las interfaces.

En el capítulo IV, denominado: prototipos del sistema, se trata de fundamentar el

uso de los prototipos de sistemas antes de la implantación, se presentan
prototipos de algunos procesos del sistema propuesto y se concluye explicando la
seguridad del sistema.

En el capítulo v, denominado: Evaluación Económica del proyecto, se realizan el

desarrollo de los estudios de viabilidad y costes – Beneficios, a fin de determinar
la o no viabilidad de la implantación del sistema de control de cabina de internet.

Finalmente, se detalla un glosario de términos a fin de que se pueda entender

algunos términos usados en el presente estudio y la sección de anexos que
contiene, manual de organización y funciones de la institución, actual hoja de
trámite documentario, proformas y presupuestos para el licenciamiento de
software libre, entrevistas e inventarios de equipos.
ABSTRACT
INDICE
CAPITULO
I
ASPECTO GENERALES
ASPECTO GENERALES (INTERNET RUBI)

DATOS GENERALES:

1.1. Datos del estudiante:

1.1.1. Apellidos y nombres: Chang Sánchez, Fiorella Rosmery.
1.1.2. DNI: 73119729
1.1.3. Código: CI 004 - 15
1.1.4. Correo electrónico: Fiorelitha_chang@hotmail.com
1.1.5. Centro de estudios: Instituto de Educación Superior Público de Huarmey.
1.1.6. Carrera profesional: Computación e Informática.
1.1.7. Semestre académico: III
1.1.8. Asesor: Antúnez Carrillo, Dennis.

1.2. Datos de la empresa:

1.2.1. Razón social: “Multiservicios Rubí”.
1.2.2. Ruc: 10218814790
1.2.3. Régimen tributario: RUS
1.2.4. Tipo de contribuyente: Persona Natural con Negocio.

1.3. Datos del negocio:

1.3.1. Código de servicio: 6209 – Otras Actividades De Tecnología De La
Información Y De Servicios Informáticos.
1.3.2. Estado contribuyente: Activo
1.3.3. Sistema de emisión de comprobante: Manual
1.3.4. Comprobantes emite: Boleta

1.4. Domicilio fiscal:

1.4.1. Domicilio fiscal: Av. Grau N°145 Casco Urbano.
1.4.2. Departamento: Ancash
1.4.3. Provincia: Huarmey
1.4.4. Distrito: Huarmey
1.5. Representante:
1.5.1. Apellido y Nombre: Tasayco Yoveira, Sonia Mariluz.
1.5.2. Cargo: Administradora
1.5.3. DNI: 21881479
1.5.4. Dirección: Av. Grau N°145 Casco Urbano.

2. Reseña Histórica:

La empresa del Internet “Multiservicios Rubí” se inició el 07 de Septiembre del

2005 fundada por Sonia Mariluz Tasayco Yoveira quien con la ayuda de una
amiga suya que estudiaban en la Universidad la ayudo y animo a abrir su cabina
de internet para que pueda tener un ingreso económico el cual inicio con 4
máquinas las cuales siguen siendo las mismas en la actualidad.

Pudiéndose llamar una cadena entre amistades entre ellas ya que su amiga
también cuenta con cabinas de internet y librería y ambas se apoyan en las
necesidades que puedan tener, tienen la finalidad de brindar un buen servicio y
ser reconocido por el buen trabajo brindado en el poco tiempo de reconocimiento
por sus vecinos y demás personas que lo visitan, con la finalidad de brindar a sus
clientelas nuevos servicios como ventas de golosinas, ventas de tarjetas y
recargas virtuales, etc.

2.1. Misión:

Satisfacer nuestros clientes de una forma rápida y segura al momento de

realizar la atención al público de servicio general de ventas, jugueria y
cabinas de internet, etc. también bridarle un buen servicio para así hacer que
nuestra empresa crezca.

2.2. Visión:

Ser empresa líder en el suministro, distribución e instalación de nuestros

servicios en los mercados en los que participamos, distinguiéndonos por
proporcionar una alta calidad de servicio y productos a nuestros clientes.
2.3. Valores:

El internet “Rubí”, asume los siguientes valores los cuales permiten que el
servicio realizado tenga una buena calidad.

 Respeto
 Honestidad
 Responsabilidad
 Trabajo
 Paz
 Agradecimiento
 Amistad

3. Ubicación Geográfica:

El internet “Multiservicios Rubí”, tiene como única sede Central en la Ciudad

de Huarmey, Distrito de Huarmey, Provincia de Huarmey, Departamento de
Ancash.

 DIRECCIÓN es Av. Grau N°145 Casco Urbano – Huarmey, Ancash – Perú.

 TELÉFONO: 956847308.
 E-MAIL: multiservcios-rubi@hotmail.com.
 “MULTISERVICIOS
RUBI”

Foto N° 01: Fachada de la empresa “Internet Rubí” que se encuentra

ubicado en la Av. Grau N°145 Casco Urbano – Huarmey.

4. Base legal de la empresa:

En la ciudad de Huarmey, Provincia Huarmey, Departamento de Ancash, a 01

días de Septiembre del dos mil cinco, comparecen ante el Notario Público,
Amador Tito Villena, la Sra. Tasayco Yovera, Sonia Mariluz, de nacionalidad
peruana, con una minuta debidamente firmada para constituir una Empresa
Individual de Responsabilidad Limitada, bajo la denominación “Cabinas de
internet Rubí”.

El capital social de la empresa es de S/ 12,000.00 para el cual solicito un

préstamo cada una suscrita y pagada.

4.1. Áreas que comprende:

 Área Administrativa.
 Área de Secretaria.
 Área de Personal.
 Área de Ventas.
 Área de Productos.
 Área de Compras.
4.2. Funciones del Área:

La empresa de Internet “Multiservicios Rubí”, al igual que todas las empresas,

también tiene su estructura organizacional, que es la siguiente:

 Órgano de Dirección:

Área de Administradora: Tiene toda la facultad de representación legal y gestión

empresarial para la administración de su empresa ya que la administradora viene
a ser el propietario de la empresa. Realiza papeleos del negocio del internet,
ventas y el pago al personal, también está pendiente del estado de las
computadoras.

 Órgano de Apoyo:

Área de Secretaria: Encargada en la elaboración de la empresa y atención al

cliente, hace los pedidos por órdenes de la administradora, también realiza los
pagos y la cobranza de la empresa.

Área de Personal: Realiza actualizar las maquinas, el control de las cabinas,

limpieza del ambiente, realización de las cuentas de alquilar de las cabinas.

Área de Ventas: Promover el marketing que produce ingresos. Una empresa

debe poner un precio inicial cuando desarrolla un nuevo producto.

Área de Productos: Esta encargado a utilizar la fijación de precios de acuerdo al

costo de los materiales utilizados, teniendo en cuenta el medio que los rodea; es
decir viendo los cambios que sucede con la economía.

Área de Compras: Es para la empresa una de las más importantes. Los

términos y significados que se usan para definir elementos que la conforman en la
práctica se usan casi de manera indistinta.
Compras, suministros, materiales, logística entre otros son de los términos más
importantes para referirse a las actividades que se desempeñan en el área de
compras.

4.3. Organigrama Estructural de la Empresa:

GERENTE

ADMINISTRADORA

SECRETARIA

ÁREA DE ÁREA DE ÁREA DE ÁREA DE

PERSONAL VENTAS PRODUCTOS COMPRAS
 5. Análisis De Matriz Foda:

LISTA DE FORTALEZAS LISTA DE DEBILIDADES

F1. Cuenta con D1. Lentas a veces la línea.
Factores Internos computadoras de última D2. Falta de seguridad para
generación mantener en buen estado
F2. Cuenta con los equipos.
protecciones de antivirus D3. Falta de
y actualizaciones de mantenimiento.
programas (juegos, D4. No cuenta con un
antivirus, etc. sistema de control de
Factores Externos F3. Cuenta con local alquiler de cabina de
propio. internet.

LISTA DE FO (MAXI-MAXI) DO (MINI-MAXI)

OPORTUNIDADES Estrategia para maximizar Estrategia para minimizar
tanto las F como las O. las D y maximizar las O.
O1. Aumento de la seguridad 1. Realizar publicidad. 1. concientizar a mantener
en el internet. 2. Realizar nuevos en buen estado todos los
O2. Mayor apoyo en el actualización como materiales que se les brinda
entorno económico. programas y juegos. para su buen
O3. Requerimiento de 3. implementar un sistema aprovechamiento.
personal capacitado. de control para la cabina 2. desarrollo del sistema de
de internet. control en las cabinas de
internet.
LISTA DE AMENAZAS FA (MAXI-MINI) DA (MINI-MINI)
A1. Competencias con otras Estrategia para fortalecer Estrategia para minimizar
cabinas de internet. y minimizar las amenazas. las A como las D.
A2. Repentina ida de luz. 1. Realizar seguridad y 1. Interés del personal a
mejora de sistema de cargo para llevar a cabo
control bien sus funciones.
2. instalación de nuevos 2. Realizar del control y su
programas. mejora para el cliente.
3. Tenga UPS.
CAPITULO
II
ANALISIS DEL SISTEMA ACTUAL
2.1 Acciones Preliminares:

2.1.1 Ciclo de vida de desarrollo del software

Las iteraciones iniciales de la elaboración se centran en el análisis eso contribuye
a obtener una arquitectura estable y sólida y facilita una comprensión en
profundidad de los requisitos. Al término de la fase de elaboración y durante la
construcción, cuando la arquitectura es estable y se comprenden los requisitos, el
énfasis pasa en cambio al diseño y a la implementación.

El propósito objetivo del análisis debe alcanzarse de algún modo en todo

proyecto pero la manera exacta de ver y de emplear el análisis puede diferir de un
proyecto a otro; para lo cual es necesario distinguir tres variantes básicas:
1. El proyecto utiliza un mo0delo de análisis para describir los resultados del
análisis mantiene la consistencia de este modelo a lo largo de todo el ciclo
de vida del software.
2. El proyecto utiliza el modelo de análisis para describir los resultados del
análisis pero considera a este modelo como una herramienta transitoria e
intermedia-quizás de más interés en la fase de elaboración-cuando el
diseño y la implementación están en marcha durante la fase de la
construcción se deja de actualizar el análisis. En su lugar cualquier tema de
análisis que aun “quede” se resuelve como parte integrada dentro del
trabajo de diseño en el modelo de diseño resultante.
3. El proyecto no utiliza en absoluto el modelo de análisis para describir los
resultados del análisis. En cambio, el proyecto analiza los requisitos como
parte integrada en la captura de requisitos o en el diseño.

En el primero de los casos, hará falta un mayor formalismo en el modelo de casos

de uso. Esto puede ser justificable si el cliente es de comprender los resultados.
El segundo caso podría complicar el trabajo de diseño sin embargo, los requisitos
son muy simples y/o son bienes conocidos, si es fácil identificar la forma del
sistema (incluyendo su arquitectura), o si los desarrolladores cuentan con una
cierta comprensión, intuitiva pero correcta, de los requisitos, y son capaces de
construir un sistema que los encarne de una manera directa.
Al elegir entre las dos primeras variantes, se debe sopesar las ventajas de
mantener el modelo del análisis con el coste de mantenerlo durante varias
iteraciones y generaciones por tanto se hace necesario realizar un análisis
coste/beneficio correcto, y decidir si es necesario dejar de actualizar el modelo
análisis- quizá tan pronto como al final de la fase de elaboración – o si,
deberíamos conservarlo y mantenerlo durante el resto de la vida del sistema.

En cuanto a la tercera variante, es correcto que el proyecto puede o no solo evitar

el coste de mantener el modelo de análisis, sino también el introdicirlo9 al
principio (incluyendo el coste en tiempo y recursos que consume el formar a los
desarrolladores- y el hacer que tomen experiencia- en el uso del modelo). Sion
embargo, normalmente las ventajas de trabajar con un model9o de análisis por lo
menos al principio del proyecto sobrepasan los costes de emplearlo; por tanto,
solo deberíamos emplear esta variante en casos excepcionales para sistemas
extraordinariamente simple.

A continuación se ilustra el ciclo de iteraciones.

2.2 Recopilación de la Información:

La recopilación de la información tiene por finalidad los requerimientos del

sistema, así también para conocer cómo trabaja y donde es necesario efectuar
mejoras sí que existe alguno.

Las técnicas a usar son:

Para la encuesta se usa la técnica del cuestionario.

2.2.1 Encuesta:
Es una técnica para obtener información, generalmente de una muestra de
sujetos. La información es recogida usando procedimientos estandarizados de
manera que a cada individuo se les hace la misma pregunta en más o menos la
misma manera.

2.2.2 cuestionario:
Se diseñó para conocer la opinión de los usuarios en diferentes aspectos en
forma directa y simple mediante un análisis de tipo cuantitativo para poder
determinar las conclusiones que se correspondan con los datos recogidos. La
encuesta se desarrolló por muestreo, donde se escogieron mediante
procedimientos estadísticos una parte significativa, teniendo en cuenta el
porcentaje de error calculado para el caso, de esta forma los hallazgos obtenidos
a partir de la muestra pueden generalizarse a todo el universo con un margen de
error conocido y limitado.
Selección de personas a entrevistar:

Para seleccionar a las personas a entrevistar, se deben tener en cuenta los

siguientes requisitos:

 Posición jerárquica, deseable de cada nivel de acuerdo al organigrama de la

organización.
 Que tengan inherencia en la toma de decisiones en el planeamiento y en la
toma de decisiones en el planeamiento y en el diseño de estrategias.
 Que tengan personal a su cargo.
 Que conozcan los procesos del sistema a evaluar.
 Que tengan relación directa con el sistema a evaluar y/o a implantar.
 Deseable antigüedad en la organización.

Teniendo en cuenta los requisitos planteados y seleccionados anteriormente se

decidió por entrevistar a las siguientes personas:

1. Sonia Mariluz, Tasayco Yovera_Administradora.

2. Leidi Luisa, Rosales Pomiano_Personal.
3. Wilber Rolando, Vilca Vargas_Secretario.

2.2.3. Diseño de Entrevistas:

Encuesta técnica que se preparó para el Desarrollo de las Entrevistas, se
plantearon algunas de las siguientes situaciones:

1. ¿Cuenta con una computadora donde se pueda instalar un sistema de control

para poder controlar las demás maquinas?
2. ¿Cuenta usted con un sistema de control de cabinas de internet?
3. ¿Cómo realiza actualmente el control de horas, el ingreso del cliente, salida y
cobranza?
4. ¿Cuáles son los problemas que se le presenta a usted al momento de realizar
manualmente el control de horas, el ingreso del cliente, salida y cobranza?
5. ¿A su parecer cree usted que brinda un buen servicio a los estudiantes y
público en general?
6. ¿Cree que se le es un poco complicado al presentar su informe a la
Administradora de la manera en la que la realiza?
7. ¿Cree usted que con el sistema implementado daría un mejor servicio y una
atención oportuna?
8. ¿Cree que mejoraría su rendimiento laboral contando con un sistema de
control de cabinas de internet?
9. ¿Cree además que mejoraría la imagen de su cabina con la mejora que traerá
este sistema de control?
10. ¿Cree usted que tiene conocimiento y dominio sobre un sistema de control de
cabinas?

2.2.4. Hardware Disponible

 COMPUTADORAS :

Se cuenta con el Siguiente Hardware:

 Halion, 01 Dual Core, Memoria RAM 4GB, Microprocesador 1.3 GHZ,

Disco Duro de 500 Mb.

 SOFTWARE:

o SISTEMAS OPERATIVOS:

Windows 7 Profesional.

o SOFTWARE DE OFIMATICA:

Microsoft Office 2013

o UTITARIOS:

Adobe Reader, Winrar, Nod 32 antivirus.

2.3. Formulación del problema:

La cabina de “Internet Rubí”, cuenta con algunos problemas, pero en este caso
solo trataremos el área de cabina, la cual tiene los siguientes Problemas:

 En la actualidad el área de las cabinas cuenta con cuatro

computadoras y no cuenta con otra cabina de administración, la cual
no cumple con las necesidades que requiere el personal, pues
realmente ello es una gran problemática para esta área.

 El registro de alquiler de las cabinas, informes, etc., son registradas

manualmente en un cuaderno de apuntes lo cual es un riesgo a perder
la información.

 Al momento del alquiler de cabinas el personal no tiene un control

eficiente en determinar las cabinas que se encuentran ocupadas ya
que algunos clientes en especial menores de edad se cambian de
cabinas sin avisar al personal encargado.

 No cuenta con un sistema en específico para llevar en orden los

horarios de ingreso del cliente.

 Por los problemas que se encuentran en el control, los clientes muchas

veces desconfían en su tiempo que ellos han alquilado.
OBJETIVOS DEL PROYECTO:

OBJETIVO GENERAL:

 Determinar y plantear una alternativa de solución informática al

problema de informe y control de cabinas que se da en la calidad de
alquiler en el Internet “Rubí” utilizando la Metodología RUP y Software
Licenciado tanto para el Análisis, Diseño y algunos prototipos de
interfaz.

OBJETIVOS ESPECIFICOS:

 Realizar un trabajo de recopilación necesaria, mediante el método de

entrevistas a las personas que se encuentran inmersas en el proceso
del personal y del control de las cabinas y procedimientos existentes.
 Normar adecuadamente el registro sistematizado de la información al
momento que se realiza el alquiler de cabinas realizando tramite del
personal.
 Modelar el sistema con la metodología RUP, STAR UML 2.6.0.
 Diseñar y construir una base de datos integra y confiable mediante un
sistema de Administración de Base de Datos utilizando Erwin, Work
Benck y Access.
 Plantear un modelo del sistema de control utilizando VISUAL BASIC
6.0.
 Evaluar y especificar el requerimiento de Hardware y Software
necesarios para la instalación e implementación del sistema.
 Determinar la factibilidad económica del proyecto, mediante un análisis
de costos y beneficios.
OBJETIVOS DEL SISTEMA:

 Automatizar el proceso de registro y el control que se tramite en el

internet.
 Implementar un sistema utilizando software licenciado en su totalidad
tanto para el Análisis, Diseño y para su implementación.
 Diseñar interfaces sencillas, amigables, que sean totalmente fácil de
entender y manipular por el personal.
 Brindar seguridad y privacidad en todos sus niveles, tanto en los datos
que se registran como en el acceso.
 Contribuir con los estudiantes y público en general a la ubicación
inmediata del alquiler de las cabinas a través de un fácil procedimiento
de consulta.

 Mostrar mediante reportes en pantalla distintas formas de la

información que se encuentran en la Base de Datos, estos reportes
por pantalla pueden ser luego debidamente impresos.
2.4. Descripción del sistema actual

MODELAMIENTO DEL SISTEMA ACTUAL

Pictogramas Específicos del Proceso Actual:

Fig. (3.2) Esquemas Específicos del Proceso Actual

Y solicita una
cabina.

Fig. (3.2) Esquema Específicos del Proceso Actual

 Diagrama de Flujo del Proceso de Internet “Rubí”

N° ACTIVIDAD CLIENTE PERSONAL ADMINISTRADOR

INICIO

1 Ingresa al internet y
solicita una cabina. 1

2 Busca en su informe de
2
apuntes que cabina está
libre.

Anota el ingreso del

3
3 alquiler hasta la hora que
culmina.

4 Ingresa a la cabina 4
donde va a estar.

5 Paga el alquiler de la 5
cabina.

6 Realiza su informe. 6

Entrega su informe del

7 día al Administrador. 7

Cuadro n° 3.4: Diagrama de Flujo del Proceso de Internet “Rubí”

2.5. Identificación de los requerimientos:

Requerimientos Funcionales:

 Registrar datos de las computadoras en el internet “Rubí”.

 Registrar datos del usuario.
 Registrar y actualizar los alquileres de las diferentes cabinas que existen
en el internet.
 Generar reporte de movimientos de las cabinas.
 Generar reportes de ingresos de alquiler de cabinas.
 Generar reportes de cabinas no alquiladas por parte de los clientes.
 Generar reportes cabinas más solicitadas o con mayor movimiento.
 Generar reporte de todos los movimientos en el internet para entregar al
Administrador.
2.5.1 Análisis de Entradas y Salidas:

Tabla de Eventos

N° EVENTO ENTRADA SALIDA ORIGEN DESTINO

01 Datos
Datos internet cabina Administrador
02 Datos del Dato del
usuario cliente Cliente
03 Solicitud de Ficha de
alquiler de control Cliente
cabinas
04 Tiempo de Ficha de
alquiler control Cliente
05 Orden de baja
de cabina Orden Administración
06 Reporte de Inventario de
cabina bienes Administración
07 Reporte de Lista de fallas
fallas de de cabina Administración
cabinas
08 Reporte de Record de
cabinas cabina Administración
solicitadas alquilada
 ENCUESTA TECNICA
Nombre
Oficina
Cargo

!!! Su opinión es importante: Por favor lea detenidamente cada parámetro de

evaluación u contéstelo, sea lo más consiente y responsable posible.
De esto dependen las mejoras que puedan plantearse en el futuro.

SISTEMA DE CONTROL

NO SI

Cuenta el Internet “Rubí” con un sistema de control.

Actualmente como realizan el Control de las cabinas:

 En forma Manual
 No lo realizan
 A veces lo realizan y a veces no

Cree usted que con el sistema actual:

 La atención es Mala
 La atención es Regular
 La atención es Buena
 La atención es Excelente

Con el sistema actual el control es:

 Inmediata
 Demora poco
 Demora regular
 Demora mucho

Cree que se le es un poco complicado el presentar su Informe

al Administrador de la manera en la que la realiza:

 Poco
 Regular
 Mucho
Cree usted que es necesario contar con un sistema de control de cabinas

La implantación de un sistema de control:

 Mejora su rendimiento profesional

 Mejora su rendimiento personal
 Le ahorraría tiempo para otras funciones
 Realizaría la búsqueda de expedientes forma inmediata
 Mejoraría la imagen de internet “Rubí”.
 Los clientes estarían satisfechos.

Ud. Tiene conocimiento y dominio sobre un sistema de control de cabinas:

Que piensa que debe tener principalmente un sistema de control de cabinas de internet:

EQUIPO - HARDWARE

No Si

Tiene algún equipo asignado a usted para sus funciones.

Si no tiene equipo, cree usted que requiere de una PC

para realizar sus funciones en el sistema de control.

A su parecer cree usted que brinda un buen servicio a los estudiantes y público en
general…… Explique brevemente.

Muchas Gracias
SONIA MARILUZ TASAYCO YOVERA

“ADMINISTRADORA”
 CAPITULO
III
ANALISIS Y DISEÑO DE SISTEMAS PROPUESTO
3.1. Metodología Para El Desarrollo Del Sistema

3.1.1. Análisis Y Diseño Orientados A Objetos

Constituye un enfoque con una forma de modelar un sistema como un grupo de

objetos que interactúan entre sí. Este enfoque representa un dominio absoluto en
términos de conceptos compuestos por verbos y diseños se crea un conjunto de
modelos utilizados una notación acordada como, por ejemplo, el lenguaje
unificado de modelado (UML).

Aplica técnicas de modelado de objetos para analizar los requerimientos para un

contexto por ejemplo, un sistema de negocio, un conjunto de módulos de software
y para diseñar una solución para mejorar los procesos involucrados. No está
restringido al diseño de programas de computadora, sino que cubre sistemas
enteros de distinto tipo. Las metodologías de análisis y diseño más modernas son
casos de uso guiados a través de requerimientos, diseño, implementación,
pruebas y despliegue.

Análisis y diseño orientado a objetos es una fase de la metodología orientada a

objetos para el desarrollo del software, el cual es un método de análisis que
examina desde la perspectiva de las clases y objetos que se encuentran en el
vocabulario del dominio de la palabra. Dentro del análisis y diseño orientados a
objetos se encuentra la UML, que es una herramienta que cumple con una de
estas funciones, ya que ayuda a capturar la idea de un sistema y comunicaría
posteriormente a quien esté involucrado en su proceso de desarrollo.

Hoy en día la tecnología orientada a objetos ya no se aplica solamente a los

lenguajes de programación, además se viene aplicando en el análisis y diseño
con mucho éxito, al igual que en las bases de datos. Es que para hacer una
buena programación orientada a objetos hay que desarrollar todo el sistema
aplicando esta tecnología, de ahí la importancia de analizar y el diseño orientado
a objetos.

La programación orientada a objetos es una de las formas más populares de

programar y viene teniendo gran acogida en el desarrollo de proyectos de
software desde los últimos años. Esta acogida se debe a sus grandes
capacidades y ventajas frente a las antiguas formas de programar.
En conclusión el análisis, diseño orientado a objetos, ha sido desarrollado para
responder a las necesidades de flexibilidad en el sistema de información basada
en computadora. La encapsulación, herencia y polimorfismo, tienen como objetos
proporcionar sistemas complejos con mecanismos para un rápido, fácil y confiable
mantenimiento y cambio de los programas. Aunque, esta inversión se traduce en
menores costos de operación de los sistemas que es probable que requiera una
gran actividad de mantenimiento.

3.1.2. Descripción de las Metodologías más usadas

METDOLOGIA RUP

Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken
Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la
investigación. En 1995 Rational Software compró una compañía sueca llamada
Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los
casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified
Process fue el resultado de una convergencia de Rational Approach y Objectory
(el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el
Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado
en 1998, siendo el arquitecto en jefe Philippe Kruchten.

Fases del Modelo RUP

RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias

iteraciones en número variable según el proyecto y en las que se hace un mayor o
menor hincapié en los distintas actividades.

Inicio

Esta fase tiene como propósito definir y acordar el alcance del proyecto con los
patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión
muy general de la arquitectura de software y producir el plan de las fases y el de
iteraciones posteriores.
Elaboración

En la fase de elaboración se seleccionan los casos de uso que permiten definir la

arquitectura base del sistema y se desarrollaran en esta fase, se realiza la
especificación de los casos de uso seleccionados y el primer análisis del dominio
del problema, se diseña la solución preliminar.

Construcción

El propósito de esta fase es completar la funcionalidad del sistema, para ello se

deben clarificar los requisitos pendientes, administrar los cambios de acuerdo a
las evaluaciones realizados por los usuarios y se realizan las mejoras para el
proyecto.

Transición

El propósito de esta fase es asegurar que el software esté disponible para los
usuarios finales, ajustar los errores y defectos encontrados en las pruebas de
aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se
debe verificar que el producto cumpla con las especificaciones entregadas por las
personas involucradas en el proyecto.

Fase de inicio

Se hace un plan de fases, donde se identifican los principales casos de uso y se

identifican los riesgos. Se concreta la idea, la visión del producto, como se
enmarca en el negocio, el alcance del proyecto. El objetivo en esta etapa es
determinar la visión del proyecto.

Modelado del negocio

En esta fase el equipo se familiarizará más al funcionamiento de la empresa,

sobre conocer sus procesos.

 Entender la estructura y la dinámica de la organización para la cual el

sistema va ser desarrollado.
 Entender el problema actual en la organización objetivo e identificar
potenciales mejoras.
  Asegurar que clientes, usuarios finales y desarrolladores tengan un
entendimiento común de la organización objetivo.

Requisitos

En esta línea los requisitos son el contrato que se debe cumplir, de modo que los
usuarios finales tienen que comprender y aceptar los requisitos que
especifiquemos.

 Establecer y mantener un acuerdo entre clientes y otros stakeholders sobre

lo que el sistema podría hacer.
 Proveer a los desarrolladores un mejor entendimiento de los requisitos del
sistema.
 Definir el ámbito del sistema.
 Proveer una base para estimar costos y tiempo de desarrollo del sistema.
 Definir una interfaz de usuarios para el sistema, enfocada a las
necesidades y metas del usuario.

Fase de elaboración

Se realiza el plan de proyecto, donde se completan los casos de uso y se mitigan

los riesgos. Planificar las actividades necesarias y los recursos requeridos,
especificando las características y el diseño de la arquitectura. En esta etapa el
objetivo es determinar la arquitectura Óptima.

Análisis y Diseño

En esta actividad se especifican los requerimientos y se describen sobre cómo se

van a implementar en el sistema.

 Transformar los requisitos al diseño del sistema.

 Desarrollar una arquitectura para el sistema.
 Adaptar el diseño para que sea consistente con el entorno de
implementación.
Fase de construcción

Se basa en la elaboración de un producto totalmente operativo y en la elaboración

del manual de usuario. Construir el producto, la arquitectura y los planes, hasta
que el producto está listo para ser enviado a la comunidad de usuarios. En esta
etapa el objetivo es llevar a obtener la capacidad operacional inicial.

Implementación

Se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y

demás. El resultado final es un sistema ejecutable.

 Planificar qué subsistemas deben ser implementados y en qué orden

deben ser integrados, formando el Plan de Integración.
 Cada implementador decide en qué orden implementa los elementos del
subsistema.
 Si encuentra errores de diseño, los notifica.
 Se integra el sistema siguiendo el plan.

Diagramas que utiliza la metodológica (RUP):

o Modelo de Dominio
o Modelo de Casos de Uso
o Modelo de Análisis y Diseño
o Modelo de Implementación
o Modelo de Procesos
o Modelo de Seguridad
o Modelo de Interfaz de Usuario

METODOLOGIA SCRUM

Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuch, es
una metodología ágil y flexible para gestionar el desarrollo de software, cuyo
principal objetivo es maximizar el retorno de la inversión para su empresa (ROI).

Implementación: Las clases de objetos y relaciones desarrolladas durante el

análisis y objetos se traducen finalmente a una implementación concreta. Durante
la fase de implementación es importancia tener en cuenta los principios de la
ingeniería del software de forma que la correspondencia con el diseño sea directa
y el sistema implementado sea flexible y extensible. No tiene sentido que
utilicemos AOO y DOO de forma que potenciemos la reutilización de código y la
correspondencia entre el dominio del problema y el sistema informático, si luego
perdemos todas estas ventajas con una implementación de mala calidad.

La metodología OMT emplea tres clases de modelos para describir el

sistema:

Modelo de objetos. Describe la estructura estatica de los objetos del sistema

(identidad, relaciones con otro objetos, atributos y operaciones). El modelo de
objetos proporciona el entorno esencial en el cual se puede situar el modelo
dinámico y el modelo funcional. El objetivo es capturar aquellos conceptos del
mundo real que sean importantes para la aplicación. Se representa mediante
diagramas de objetivos.

Modelo Dinámico: Describe los aspectos de un sistema que tratan de la

temporización y secuencia de operaciones (sucesos que arcan los cambios,
secuencias de sucesos, estados que definen el contexto para los sucesos) y la
organización de sucesos y estados. Captura el control, aunque aspecto de un
sistema que describe las secuencias de operaciones que se producen sin tener
en cuenta lo que hagan las operaciones, aquello a lo que afectan o la forma en
que están implementadas. Se representa gráficamente mediante diagramas de
estado.

Modelo funcional. Describe las transformaciones de valores de datos (funciones,

correspondencias, restricciones y dependientes funcionales) que ocurren dentro
del sistema, captura lo que hace el sistema, independientemente de cuando se
haga o de la forma en que se haga. Se representa mediante diagramas de flujo de
datos.

3.1.3. Comparación entre el análisis y diseño orientados a objetos y el

análisis diseño estructurado

Es importante tener el concepto básico y claro de las diferencias que se

establecen el estructurado y en lo orientado a objetos, es por este motivo que se
muestra a continuación un cuadro donde se podrá visualizar las diferencias que
existen entre ambos.
Análisis y Diseño ESTRUCTURADO Análisis y Diseño ORIENTADO A
OBJETOS
Se basa fundamentalmente en la Busca ante todo descomponer un
descomposición funcional del sistema espacio de problema por objetos y esto
que queremos construir. permite analizar mejor el dominio del
Esta descomposición funcional requiere problema.
traducir el dominio del problema en una El concepto orientado a objetos es más
serie de funciones y sub funciones. Lo simple y permite una mejor
que se puede parecer a la forma más comunicación entre el analista y el
directa de implementar un objetivo experto en el dominio del problema.
deseado, pero el sistema resultante
puede ser demasiado frágil.
Los cambios en los requisitos afectan Las evoluciones de los requisitos
notablemente a la funcionalidad del afectan en mucha menor medida a los
sistema, por lo que afectan mucho al objetos que componen a manejan el
software desarrollado, por lo que puede sistema, que son mucho más estable.
ser necesaria una importante
reestructuración.

3.1.4. Software a utilizar para el modelamiento

MODELADOR STAR UML

Se ha seleccionado el software libre Star UML, para efectos del presente

proyecto.

Es una herramienta para el modelamiento de software basado en los estándares

UML (Unified Modeling Language) y MDA (Model Driven Arquitecture), que en un
principio era un producto comercial y que hace cerca de un año paso de ser un
proyecto comercial (anteriormente llamado plastic) a uno de licencia abierta
GNU/GPL.
Ventajas:

 Software Libre.
 Facilidad de creación de nuevos Diagramas
 Muy personalizable.

3.4.1.1. Rational rose.

Es una orientada a objetos Lenguaje de Modelado (Unified UML ) herramienta de

diseño de software destinado para el modelado y visual componente de
construcción de aplicaciones de software a nivel empresarial.

3.4.1.2. Star Uml 2.6.

Es una herramienta para moldeamiento en los estándares UML que como ya

todos sabemos es un lenguaje gráfico para visualizar, especificar, construir y
documentar y sistema.

Ventajas:

 Es software libre.
 Muy personalizable.

3.4.1.3. Poseidón for uml 8.0

Ahora Poseidón para UML se basa en nuestra plataforma de Poseidón por

DSL. Es una gran herramienta UML con un conjunto completo de diagramas
(Clase del paquete, casos de uso, estado, componente, la actividad y diagramas
de secuencia) y una excelente interfaz de usuario. Proporcionamos magníficas
mejoras en la estabilidad, escalabilidad, el rendimiento, la fiabilidad y la
personalización.
3.1.5. Enfoques de la metodología.

3.1.5.1. Enfoque secuencial:

Sugiere un enfoque sistemático, secuencial, para el desarrollo del software que

comienza en un nivel de sistemas y progresa con el análisis, diseño, codificación,
pruebas y mantenimiento.

Es un ciclo de vida en sentido amplio, que incluye no sólo las etapas de ingeniería
sino toda la vida del producto: las pruebas, el uso (la vida útil del software) y el
mantenimiento.

3.1.5.2. Enfoque cascada:

Es considerado como el enfoque clásico para el ciclo de vida del desarrollo de

sistemas, se puede decir que es un método puro que implica un desarrollo
rígido. Está es una secuencia de actividades(o etapas) que consisten en el
análisis de requerimientos, él diseño, la implementación, la integración y las
pruebas.

El análisis de requerimientos consiste en reunir las necesidades del producto y

casi siempre su salida es texto.

El diseño describe la estructura interna del producto y suele representarse con

diagramas y texto.

La implementación significa programación. Producto de esta etapa es el código

en cualquier nivel, incluido el producido por sistemas de generación automática.

La integración es el proceso de integración es el proceso de ensamblar las

partes para completar el producto.

3.1.5.3. Enfoque Espiral:

Es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de

construcción de prototipos con los aspectos controlados y sistemáticos del
MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo
rápido de versiones incrementales del software que no se basa en fases
claramente definidas y separadas para crear un sistema.
3.1.5.4. Enfoque Incremental:

Combina elementos del Modelo Lineal Secuencial con la filosofía interactiva de

construcción de prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el
tiempo en el calendario. Cada secuencia lineal produce un incremento del
software. El primer incremento generalmente es un producto esencial denominado
núcleo.

3.1.5.5. Enfoque Evolutivo:

Son iterativos, los caracteriza la forma en que permiten que los ingenieros de
software desarrollen versiones cada vez más completas del Software. - Las
estrictas fechas tope del mercado imposibilitan la conclusión de un producto
completo, por lo que se debe presentar una versión limitada para liberar la presión
competitiva y de negocios.

3.1.5.6. Enfoque Prototipado:

Este modelo se utiliza para dar al usuario una vista preliminar de parte
del software. Este modelo es básicamente prueba y error ya que si al usuario no
le gusta una parte del prototipo significa que la prueba fallo por lo cual se debe
corregir el error que se tenga hasta que el usuario quede satisfecho. Además el
prototipo debe ser construido en poco tiempo, usando los programas adecuados y
no se debe utilizar mucho dinero pues a partir de que este sea aprobado nosotros
podemos iniciar el verdadero desarrollo del software.

3.1.5.7. Enfoque Concurrencia:

Propone una filosofía de trabajo basada en sistemas de información y

fundamentada en la idea de convergencia, simultaneidad o concurrencia de la
información contenida en todo el ciclo de vida de un producto sobre el diseño del
mismo.

3.2. Fundamentos para la selección de la metodología.

UML ha sido desarrollo con el propósito de ser útil para modelar diferentes
Sistemas de Información, y no solo es útil para la programación sino también para
modelar negocios, es decir, los procesos y procedimiento que establecen el
funcionamiento de una empresa. Es por ello que la mayoría de proyectos que
usan la Metodología UML.

El lenguaje unificado de Modelamiento es una metodología que tienen como

objetivo conseguir un modelo unificado abierto que siga evolucionando en
conjunto y no por separado.

Es un lenguaje grafico para visualizar, especificar, construir y documentar un

sistema. Uml ofrece un estándar para describir un plano del sistema (modelo),
incluyendo aspectos conceptuales tales como procesos de negocio, funciones del
sistema, y aspectos concretos como expresiones de lenguajes de programación,
esquemas de bases de datos y compuestos reciclados.

Es importante remarca que uml es un “lenguaje de modelo” para especificar o

para describir métodos o procesos. Se utiliza para definir un sistema, para detallar
los artefactos en el sistema y para documentar y construir. Otras palabras, es el
lenguaje en el que esta descrito el modelo.

3.2.1. Fundamentos de la metodología.

 Es el proceso de desarrollo más general de los existentes actualmente.

 Es una forma disciplinada de asignar tareas y responsabilidades en una
empresa de desarrollo (quién hace qué, cuándo y cómo).
3.2.2. Fundamentos para la selección de un enfoque

Enfoque cascada:

 No hace falta mencionar, es un modelo lineal y, por supuesto, los modelos

lineales son las más simples a ser implementadas.

 La cantidad de recursos necesarios para implementar este modelo es

mínimo.

 Una gran ventaja del modelo de cascada es que la documentación se

produce en cada etapa del desarrollo del modelo de cascada. Esto hace
que la comprensión del producto diseñar procedimiento más sencillo.

 Después de cada etapa importante de la codificación de software, las

pruebas se realizan para comprobar el correcto funcionamiento del código.
3.2.3. Fundamentos para la selección del software de modelamiento

Metodología STAR UML

 Software Libre.
 Facilidad de creación de nuevos Diagramas
 Muy personalizable.

3.3. Análisis.

3.3.1. Define requisitos:

Un requisito es una “condición o capacidad que necesita el usuario para resolver

un problema o conseguir un objetivo determinar”. También se aplica a las
condiciones que debe cumplir o poseer un sistema o uno de sus componentes
para satisfacer un contrato, una norma o una especificación.

Un requisito es una necesidad documentada sobre el contenido, forma o

funcionalidad de un producto o servicio. Se usa en un sentido formal en la
ingeniería de sistemas, ingeniera de software e ingeniería de requisitos.

3.3.2. Casos esenciales de uso:

Un caso de uso es una descripción de los pasos o la actividad que deberán

realizarse para llevar a cabo algún proceso. Los porcentajes o entidades que
participaran en un caso de uso se denominan actores. En el contexto de
ingeniería del software, un caso de uso es una secuencia de interacciones que se
desarrollaran entre un sistema y sus actores en respuesta a un evento que indica
un actor principal sobre el propio sistema. Los diagramas de casos de uso sirven
para especificar la comunicación y el comportamiento de un sistema mediante su
interacción con los usuarios y otro sistema.
Tabla 1:

Caso de uso Ingresa a la cabina

Actores Cliente, Personal
Tipo Primario
Descripción El Cliente acude al internet a solicitar
cabina, entonces el personal verifica
en su registro si tiene cabina
disponible.

Tabla 2:

Caso de uso Solicitar Alquiler de la Cabina

Actores Cliente, Personal
Tipo Primario
Descripción El Cliente acude al internet a solicitar
cabina, entonces el personal verifica
en su registro si tiene cabina
disponible.

Tabla 3:

Caso de Uso Registrar Alquiler

Actores Cliente, personal
Tipo Primario
Descripción Una vez entregada la cabina de
internet, el personal registra el alquiler
de la cabina.
Tabla 4:

Caso de Uso Expediente de alquiler de las cabinas

Actores Personal
Tipo Secundario
Descripción El personal tiene que tener un informe
del alquiler de cabinas el cual, tendrá
que entregar al administrador para la
supervisión.

Tabla 5:

Caso de Uso Registrar Alquiler

Actores Personal, administrador
Tipo Secundario
Descripción El administrador solicita implementos
para el internet.

Tabla 6:

Caso de Uso Generar reportes

Actores Personal
Tipo Primario
Descripción El personal siempre tiene que estar
llevando el control de las cabinas, para
ello genera reportes, el cual se enviara
al administrador para que verifiquen el
control del internet.
Tabla 7:

Caso de Uso Orden de baja de maquinas

Actores Administrador
Tipo Secundario
Descripción El administrador genera un reporte, el
cual indicara al personal dar de baja de
algunas máquinas que ya no pueden
brindar la ayuda necesaria a los
clientes, como sabemos siempre hay
mejoras cada año.

Tabla 8:

Caso de Uso Generar Tarjeta de Promoción

Actores Cliente, personal
Tipo Primario
Descripción El administrador generara una tarjeta
de promoción para los clientes, así
podrán registrar y llevar el control de
sus horas gratis.
 CASO DE USO :

Solicitar Alquiler de la Cabina

Personal

Confirma Solicitud

Alquiler

Maquina Cliente
Registrar

Pago

Administardor
Actualizar alquiler
Ver Maquina

Requerimiento de Maquina

Alquiler de Maquinas

Generar Reportes
Ventas/pago

Orden de baja de Maquinas

Generar Tarjeta de Promocion

DIAGRAMA DE REGISTRO DE ALQUILER

1. DIAGRAMA DE REGISTRO DE CLIENTE

2. DIAGRAMA DE REGISTRO DE PROVEEDOR:

3. DIAGRAMA DE REGISTRO DE COMPUTADORA:

4. DIAGRAMA DE REGISTRO DE PAGO:

5. DIAGRAMA DE REGISTRO DE PROMOCION:
DIAGRAMAS DE SECUENCIAS

1. Diagrama de secuencia de registro de cliente:

2. Diagrama de secuencia de Pago:
3. Diagrama de secuencia de registro de Computadora:
4. Diagrama de secuencia de Proveedor:
5. Diagrama de secuencia de registro de Promoción:
3.5 IMPLEMENTACION DE LA BASE DE DATOS

3.5.1 Concepto de Base de Datos

Se define como base de datos como una colección de información
interrelacionadas y almacenadas juntos sin redundancia
prejudicial e innecesaria para servir a múltiples aplicaciones
 Los datos deberán ser almacenados de manera tal que:
 Sean independientes de los programas que los usan
 Presenten un enfoque común y controlado para agregar
nuevos datos, actualizarlos o eliminarlos
 Su estructura sirva de fundamentos al desarrollo de nuevas
aplicaciones.

Entra las ventajas más importantes de una base de datos

podemos resaltar:

 Consistencia de datos
 Compartimiento de datos
 Seguridad de datos
 Integridad de datos
 Independencia de datos: Un cambio en los datos no implica
cambios en el programa o viceversa.
 Mayor estandarización.

Una base de datos es una colección de información organizada

de forma que un programa de ordenador pueda seleccionar
rápidamente los fragmentos de datos que necesite. Una base de
datos es un sistema de archivos electrónico.

3.5.2 Transformación de Diagrama de clase a modelo tabla

Los actuales diseños orientados a trabajar bajo web en intranet o

internet son eficientes, coherentes y menos proclives a los
problemas de actualización que aquejan a muchas otras técnicas
de diseño de base de datos.
En realidad el Software Libre de administración de datos como
Microsoft Visual Basic.
 Al mismo tiempo ha ganado bastante popularidad por lo que cada
día se ha incrementado sus ventajas en lo tocante a funcionalidad
y flexibilidad y además está ganando cada día más usuarios.
Visual Basic, es un software totalmente amigable y sin costo
alguno. Permite implementar bases de datos desde diseñadores
de bases, en el caso específico de este proyecto hemos utilizado
como diseñador de base de datos y diagramas de clases,
diagramas de datos y relaciones Erwin Data Modeler, que al
igual que Visual Basic es libre.
A continuación se ilustra con una interfaz que muestra el Erwin
Data Modeler para generar el diagrama de clases en tablas
ideales orientado a trabajar con Visual Basic.

3.5.3 Modelado Conceptual

3.5.3.1 Ciclo de vida de la Base de Datos.

La primera etapa de un diseño de base de datos es el

diseño del modelo conceptual, en la cual se construye
el esquema de información que se maneja en el área
documentaria, finalmente obtener una representación a
través de los diagrama.

La base de datos son unos de los componentes

principales de un sistema informático; por lo que el ciclo
de vida de un sistema de información está inmerso
directamente al ciclo de vida de la base de daos sobre
la que operara.

A continuación se mencionan las etapas que implican

el ciclo de la base de datos:

1. Planificación de la base de datos.

2. Definición del sistema, especificado el ámbito y los
límites del uso y aplicación de la base de datos.
3. Diseño de base de datos.
4. Implementación
 5. Mantenimiento

El Modelo de datos es el enfoque utilizado para

describir y representar las características y relaciones
entre datos, dentro de la base de datos.
El Modelo Entidad – Relación (E/R), es un modelo de
datos compuesto por objetos llamadas utilizado en el
proceso de diseño y desarrollo de la base de datos dl
sistema de tramite documentario.
Es importante comprender que un nivel más cercano
en la implementación el modelo nos permite
representar los datos y las relaciones entre los datos
mediante un conjunto de tablas que posteriormente
construirá la estructura de la base de datos.

3.5.6 Técnicas de normalización

La normalización es el proceso que permite distribuir todos los

campos de la base de datos en tablas relacionadas entre sí, de
forma que cumplan con el funcionamiento esperado de la base
de datos. Como premisa fundamental partiremos del propio
significado de relación, que supone el agrupar en una misma tabla
todos los campos de información relacionados por su significado.
Para evitar la inconsistencia y duplicidad de datos emplearemos
la técnica de normalización para organizar los campos de datos
en cada tabla. Sin entrar a desarrollar la teoría que hay detrás de
la normalización, usaremos una serie de reglas que pueden
aplicarse para determinar si nuestro diseño tiene sentido.

 Cada campo de una tabla debe contener un único tipo

de información. Esto significa que deberíamos dividir los
campos complejos y evitar la repetición de grupos de
información. Ejemplo: Sería conveniente separar en campos
diferentes el nombre y los apellidos de un cliente, o dividir la
dirección del mismo en los campos necesarios.
  Claves principales. Cada tabla debe tener un único
identificado clave principal, que debe estar formado por uno
o varios campos de la tabla. En una base de datos
relacional, cada uno de los registros de cualquier tabla debe
ser identificado de forma única. Es decir, algún campo o
combinación de varios debe albergar un valor único para
cada registro de la tabla. Este identificador es lo que
denominamos clave principal. Como regla general
deberíamos usar como clave principal el campo más corto
que identifique a cada registro. No obstante es
recomendable la creación de campos artificiales para ser
usados como clave principal.

Dependencia funcional. Para cada valor único de la clave

principal, los valores de las columnas de datos deben estar
relacionados y deben describir completamente el contenido
de la tabla. Esta regla opera de dos formas:

1. En primer lugar no debería haber en una tabla un dato

que no sea relevante del asunto o materia del que trata la
tabla. Por ejemplo, aunque es necesaria la información
del cliente para cada pedido, los clientes serían un asunto
independiente tendrían su propia tabla.
2. En segundo lugar los datos de la tabla deberían describir
completamente la materia de la que trata la tabla. Por
ejemplo, un pedido podría ser enviado a una dirección
diferente a la del cliente, por lo que la adición de la
dirección de envío a la tabla pedido haría que la
información fuese más completa.

Por otro lado, existen cuatro Formas de Normalización, las

mismas que a continuación, se describen brevemente

Primera Forma De Normalización (1FN)

Un conjunto de relaciones esta en 1FN, si todos los atributos

presentes en éstas son atómicos, es decir que cada campo debe
de tener un único valor indivisible. Las relaciones de las entidades
principales presentadas se encuentran en primera forma normal.
En consecuencia establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas.

Segunda Forma De Normalización (2FN)

Se trabaja solo con aquellas relaciones que contienen

dependencias funcionales. Por ejemplo en la relación Usuario,
contiene atributos de documentos que pueden o no presentar un
Usuario, por lo tanto la información en estos documentos obliga a
la creación de una tabla. En consecuencia, establece que todas
las dependencias parciales se deben eliminar y separar dentro de
sus propias tablas. Una dependencia parcial es un término que
describe a aquellos datos que no dependen de la clave de la tabla
para identificarlos

Tercer Forma De Normalización (3FN)

La tercer y ultima forma d normalización establece que hay que

eliminar y separar cualquier dato que no sea clave.

Es decir el valor de esta columna debe depender de la calve todos

los valores deben identificarse únicamente por la clave.

Cuatro Forma Normal

Una tabla esta en cuatro forma normal si y solo si para cualquier

combinación clave-campo no existe valores duplicados.

Quinta Forma Normal Boyce-Codd

La Forma Normal Boyce-Codd (Denominada por sus siglas en

inglés como BCNF or FNBC) es una forma normal utilizada en la
normalización de bases de datos. Es una adaptación vagamente
más segura de lo establecido en la Tercera Forma Normal (3FN).
La forma normal de Boyce-Codd requiere que no existan
dependencias funcionales no triviales de los atributos que no sean
un conjunto de la clave candidata.
3.5.7 Modelado lógico

La arquitectura de base de datos, se divide en tres niveles: el nivel

extremo, conceptual e interno. En la gráfica que se muestra a
continuación se pude observar estos tres niveles:

A continuación se describe el concepto de cada uno de los

niveles:

Nivel Interno: es el nivel más bajo de abstracción y define como

se almacena la información en el soporte físico.

Nivel Conceptual: es el nivel medio de abstracción, se trata de la

representación de los datos del sistema de trámite documentario
de la universidad los ángeles de Chimbote, incluye la definición de
datos y la relación existente entre ellos.

Nivel externo: es el nivel de mayor abstracción, se refiere a las

diferentes necesidades o requerimiento con respecto a la base de
datos por parte de los usuarios.

El modelo de arquitectura de base de datos, permite establecer el

principio de independencia de los datos, esta independencia puede
ser lógica y física.
3.5.8 Modelado físico

Una vez que se han definido las entidades, sus relaciones y sus
atributos o características podemos centrarnos en los requerimientos
de datos para cada entidad.

Se desarrolla un diagrama de estructura de datos a partir del modelo

conceptual y del modelo lógica planteado y, sobre todo basándose
en la técnica de normalización indicada.

Los componentes básicos que se visualizaran en los diagrama o

diseño de estructura de datos son las entidades, atributos,
apuntadores atributos y puntadores lógicos.

Los apuntadores atributos enlazan dos entidades mediante la

información común usualmente en atributo llave en uno y, un atributo
en el otro.

Los apuntadores lógicas identifican las relaciones entre las

entidades, sirven para obtener acceso inmediato a la información en
una entidad.

Los atributos llave pueden ser de dos tipos: las llaves primarias
(PK)* y las llaves foráneas (FK)*.

Con el software que se utilizado para el presente proyecto se podrá

observar las entidades, los campos o tributos juntos con el tipo de
dato así mismo los atributos llave.
3.5.9. Modelo Lógico (ERWIN)
3.6. Modelo Físico (ERWIN)
CAPITULO
IV
INTERFACES
4.1. INTERFACES (ACCES):
PANTALLA MUESTRA REGISTRAR CLIENTE

PANTALLA MUESTRA REGISTRAR ALQUILER

PANTALLA MUESTRA REGISTRAR EGRESOS

PANTALLA MUESTRA REGISTRAR INGRESOS

PANTALLA MUESTRA REGISTRAR PAGO

PANTALLA MUESTRA REGISTRAR PEDIDO

PANTALLA MUESTRA REGISTRAR PERSONAL

PANTALLA MUESTRA REGISTRAR PROMOCION

PANTALLA MUESTRA REGISTRAR PROVEEDOR

PANTALLA CONSULTA DE CLIENTE

PANTALLA MUESTRA CONSULTAS DE FECHAS DE ALQUILER

PANTALLA MUESTRA DE CONSULTA DE NOMBRES Y APELLIDOS DE PERSONAL

PANTALLA MUESTRA DE REPORTES DE ALQUILER

PANTALLA MUESTRA DE REPORTES DE INGRESO

PANTALLA MUESTRA DE REPORTES DE EGRESOS