UNIVERSIDAD AUTONOMA GABRIEL

RENE MORENO
FINOR
INGENIERÍA DE SISTEMAS

SISTEMA DE INFORMACION WEB, PARA LA GESTION

DE RESERVAS DE HORARIOS DE INSCRIPCIONES

CPD-FINOR

Presentado por:

AGUILAR VERDUGUEZ EDWIN

BARRANCOS CARDENAS DANIELA

Montero, Santa Cruz

Contenido
CAPÍTULO I PERFIL DE PROYECTO ............................................................................................................ 3
1.1. INTRODUCCION ....................................................................................................................... 4
1.2. ANTECEDENTES ........................................................................................................................ 4
1.3. DESCRIPCION DEL PROBLEMA ................................................................................................ 5
1.4. SITUACION PROBLEMÁTICA .................................................................................................... 5
1.5. JUSTIFICACION ......................................................................................................................... 5
1.6. OBJETIVOS................................................................................................................................ 5
1.6.1. OBJETIVO GENERAL ......................................................................................................... 5
1.6.2. OBJETIVOS ESPECIFICOS .................................................................................................. 5
1.7. METODOLOGIA.................................................................................................................... 6
1.8. ALCANCE .............................................................................................................................. 6
- Usuarios ................................................................................................................................. 6
- Reservas ................................................................................................................................ 6
- Gestión de tramite ............................................................................................................... 6
CAPÍTULO II REQUERIMIENTOS ................................................................................................................ 7
2.1. REQUERIMIENTOS FUNCIONALES ................................................................................................ 8
Gestionar tramite ........................................................................................................................... 9
Gestionar Usuario.......................................................................................................................... 9
2.2. REQUERIMIENTOS NO FUNCIONALES.......................................................................................... 9
Diseño de la base de datos ................................................................................................................ 11
Diagrama conceptual de la base de datos ........................................ Error! Bookmark not defined.
Diseño Lógico ..................................................................................... Error! Bookmark not defined.

2
CAPÍTULO I
PERFIL DE PROYECTO

3
1.1. INTRODUCCION

La información en una institución conforma la base fundamental para salvaguardar

evidencia de sus actividades, de esta manera facilita la toma de decisiones, la fácil
administración de la información, y la organización de procesos que se llevan a cabo en
dicha institución.

La universidad FINOR no cuenta con un sistema de información web de reservas que sea
capaz de administrar los horarios y asignar a la gran cantidad de alumnos que ingresan
año tras año a inscribirse, generando aglomeraciones o colas muy perjudiciales para los
mismos universitarios así como también exigiendo mayor trabajo laboral a los
administrativos.

El sistema debe ajustarse a las necesidades de la Universidad, considerando, la cantidad

de alumnos, los días de atención, para tener una eficiente inscripción y que puedan ser
atendidos todos sin ninguna complicación.

1.2. ANTECEDENTES

La Facultad Integral del Norte (FINOR) de la Universidad Autónoma Gabriel René Moreno
fue creada hace once años (Año 2005) y establecida en la Ciudad de Montero, Provincia
Obispo Santistevan del Departamento de Santa Cruz, principalmente en respuesta al
nacimiento e implementación de una nueva Universidad que se llamaría “Universidad
Marcelo Quiroga Santa Cruz”, la cual solo esperaba la aprobación de la ley de creación
por parte la Asamblea Legislativa, hasta aquel momento solo existía en Montero una
Unidad Académica de la UAGRM, en la cual se impartía la carrera de Ingeniería Agrícola.
Con el pasar de los años la comunidad universitaria fue creciendo de forma rápida dando
lugar a diferentes problemas de para los nuevos alumnos el poder ingresar a la
universidad. Estos problemas de tipo administrativo gestión y falta de personal estaban
presentes en cada inicio de gestión.
Considerando las dificultades del proceso de inscripción señaladas, se deben buscar
medios o métodos de mejorar tal situación para mejorar la calidad de servicio brindado
en la FINOR, En este contexto es que se debe gestionar tanto para los administrativos
como para el estudiante la implementación y uso de Nuevas Tecnologías de Información.

4
1.3. DESCRIPCION DEL PROBLEMA

En el momento de las inscripciones, retiro, adiciones, hay bastantes alumnos que los
últimos días se aglomeran y ocasionan molestias en el personal del CPD, ya que debido
a que no pueden terminar de atender a todos, tiene que ampliar los días de inscripciones.

1.4. SITUACION PROBLEMÁTICA

La universidad FINOR no cuenta con un sistema de información web de reservas que sea
capaz de administrar los horarios y asignar a la gran cantidad de alumnos que ingresan
año tras año a inscribirse, generando aglomeraciones o colas muy perjudiciales para los
mismos universitarios así como también exigiendo mayor trabajo laboral a los
administrativos.

1.5. JUSTIFICACION

El proyecto sirve para desarrollar un sistema web que sea capaz de administrar los
horarios y poder asignar a cada alumno un horario fijo para su atención y así evitar
aglomeraciones.
Durante el transcurso del desarrollo del sistema se aplicará toda la información obtenida
y los conocimientos propios.

1.6. OBJETIVOS

1.6.1. OBJETIVO GENERAL

Desarrollar un sistema de información web, para la gestión de reservas de horarios de

inscripciones CPD-FINOR.

1.6.2. OBJETIVOS ESPECIFICOS

 Capturar información sobre las causas del problema de inscripción en CPD-

FINOR.
 Analizar la información obtenida.
 Diseñar y desarrollar la base de datos.
 Implementar el sistema de información en capas, haciendo uso de un modelo de
desarrollo de software.
 Hacer pruebas del sistema.

5
1.7. METODOLOGIA
La metodología podemos definirla como: Un Conjunto de métodos que se siguen
en una investigación. El presente trabajo se basa en la metodología de
programación extrema (XP)

1.8. ALCANCE
El sistema de información abarcara los siguientes campos
- Usuarios
Perfiles de usuarios (Administrador, Estudiante)
Administración de privilegios
Registro de usuarios
- Reservas

Registrar reserva de horario

Generar boleta de reserva

- Gestión de tramite
Declarar tipos de trámites
Registro de Trámites y horarios disponibles

6
CAPÍTULO II
REQUERIMIENTOS

7
 2.1. REQUERIMIENTOS FUNCIONALES
2.1.1. REQUERIMIENTOS FUNCIONALES (PRODUCT BACKLOG)

Identificación del documento

Código MTRB-SCRUM-REQ-SRS-001

Título:
Sistema de información web, para la gestión de reservas de horarios de inscripciones CPD-FINOR
Fecha creación

Elaborado por Edwin Aguilar Verduguez

Daniela Barrancos Cárdenas

Lista de distribución

DESARROLLO Edwin Aguilar Verduguez

Daniela Barrancos Cárdenas
{CLIENTE}

Revisión del documento

Revisado por Edwin Calle T.

En fecha 02/06/2016

Aprobación del documento

Aprobado por Edwin Calle T.

En fecha 16/06/2016

Versión Causa el cambio Responsable Fecha

V01 Requerimiento inicial Daniela Barrancos Cárdenas 02/06/2016

V02 Base de Datos Edwin Aguilar Verduguez 09/06/2016

V03 Requerimiento finales Daniela Barrancos Cárdenas 16/06/2016
Edwin Aguilar Verduguez

8
2.2. REQUERIMIENTOS NO FUNCIONALES

Nro. Nombre Del Como probarlo Departamento

Requerimiento (Atributos de calidad)

Administración
RF01 Gestionar Permite modificar, registrar y eliminar los
tramite datos de los trámites.

Administración
RF02 Gestionar tipo Permite registrar, introducir el tipo de
trámite y su descripción.

RF03 Gestionar Permite el registro de la reserva de Estudiante

reserva horarios

RF04 Gestionar Permitirá Registrar, modificar y eliminar Administración

Estudiante los datos de los estudiantes.

RF05 Gestionar Permitirá Registrar, modificar y eliminar Administración

admin los datos de los administradores.

RF06 Gestionar Permitirá Registrar, modificar y eliminar Administración

Usuario los tipos de usuario que interactúan con
el sistema.

RF07 Gestionar Perfil Permitirá Registrar, modificar y eliminar Administración

los distintos perfiles de usuario que se
implementaran en el sistema.

RF08 Gestionar tarea Permitirá Registrar, modificar y eliminar Administración

las diferentes tareas que cada perfil
puede realizar en el sistema.

9
2.2.1. Tiempo de aprendizaje

La capacitación del personal, en el manejo de software y mantenimiento del sistema se deberá

considerar por lo menos 40horas laborales de capacitación (por día mínimo 1hora), hasta que los
lineamientos de manejo del sistema y otros hayan sido debidamente adquiridos por el personal
previamente asignado.

2.2.2. Identificación del usuario propio de la aplicación

El usuario ingresara al sistema con su clave y contraseña, que será validada por el sistema, y los
perfiles del sistema según la tarea asignada.

Contraseña de usuario: para la registración de la contraseña de usuario deberán asegurarse que:

la longitud de la contraseña debe ser de 6 caracteres mínimo, máximo 15

2.2.3. Confiabilidad

Tiempo de disponibilidad del sistema

La aplicación puede estar disponible 10 horas de lunes a Viernes en horarios 08:00 am a 18:00 pm
durante todo el año.

Tiempo fuera de servicio

El tiempo máximo de fuera de operaciones depende del funcionamiento del servidor como ser:
hardware del ordenador, base de datos y la infraestructura de red. El mismo debe ser: fallas
comunes 10 minutos (aprox) o fallas no comunes 1 hora (aprox)

2.2.4. Performance

Acceso de usuarios al sistema:

Los usuarios pueden acceder a los datos en tiempo real.

Tiempo de respuesta

El tiempo de respuesta al acceso del usuario debe ir de 7 segundos, la primera vez que ingresa al
sistema, después menos de 5 segundos

El tiempo de respuesta para una transacción promedio también debe ser de 7 segundos.

Calidad de atención al usuario

El sistema debe poder atender a varios usuarios al mismo tiempo.

10
2.2.5. Restricciones de diseño
Estándares de diseño
HTML
PHP Versión 5.3.1
Hoja de estilo en cascada o CSS
Estándares de arquitectura

 Se debe usar para el desarrollo de software la arquitectura en 3 capas.

 Para la infraestructura de red, se debe implementar la arquitectura Cliente/Servidor.

Motor de base de datos

Se utiliza el motor de base de datos MySQL

Cliente de escritorio
La aplicación deberá ser accesible utilizando un ordenador Core o superior con sistema Operativo
de la línea de Microsoft como ser Windows XP o superior así como también otros sistemas
operativos o distribuciones (Linux, CentOS, BSD), que contengan un navegador web (IE, Firefox,
Chrome, etc)

Servidor de datos
El servidor será: Linux Ubuntu Server 12.04.

Lenguaje de programación
La aplicación debe desarrollarse en el Lenguaje de Programación PHP y del lenguaje de marcas de
hipertexto (HTML) utilizando MySQL para el motor de base de datos.

2.2.6. Interfaces

Interfaz de usuario
No debe existir presencia de imágenes distorsionadas o difíciles de entender. La presentación de
mensaje de error o de infracción al usuario deberá ser lo más específico posible y comunicarse
con el administrador del sistema.

Interfaz del Hardware

Los usuarios necesitan un dispositivo que mediante una interfaz de red (Dominio de red Local),
Active Directory, etc.) Les permita acceder al sistema, vía red Local.

Interfaz de comunicaciones
Existe una conexión entre los usuarios y el servidor donde está alojada la base de datos:

 Los usuarios cliente se conectaran al sistema contable mediante una red local. Esta
conexión la realizarán desde su oficina en la misma infraestructura de la empresa.
 Para el Entorno de Red: la aplicación deberá tener la capacidad de funcionar en un
entorno de red LAN.

Interfaz de software

Cualquier usuario que desee conectarse al sistema web necesitara de un sistema operativo y un
navegador web

11
CAPÍTULO III
ANALISIS

12
 3.1. ESPECIFICACION DE REQUERIMIENTOS DE SOFTWARE
A diferencia de la metodología tradicional, XP utiliza las historias de usuario para la
especificación de requerimiento, permitiendo disminución. XP presenta 4 valores que seguirlos y
utilizarlos facilita la especificación de requerimientos:

 La comunicación: permite que el cliente y el programador lleguen a un acuerdo en la

especialización de requerimientos evitando los malos entendidos.
 La sencillez: es lo que diferencia a XP con las demás metodologías tradicionales las cuales
utilizan estándares para la especificación de requerimientos que hacen del sistema muy
complejo. La sencillez evita la documentación extensa centrándose en lo básico, en lo que
se utiliza en este momento y no en lo que se podría utilizar.
 La realimentación: permite que la especificación de requerimientos se comprenda mejor
con el pasar del tiempo, permitiendo que los usuarios aprendan a escribir mejor las
historias.
 Las historias de usuario: es una pequeña descripción del programa con el fin de estimar
tiempo y costo, el programador pregunta al cliente, aumentando el detalle de cada
historia.

3.2. Historias de usuario

Las historias de usuario permiten obtener los requerimientos del sistema a implementar los
primeros requerimientos por parte del usuario, es importante no detallar las historias del
usuario porque son utilizadas solo para dar una pequeña visión de lo que requiere obtener.
Cuando se inicie la fase de desarrollo el investigador con la ayuda del usuario detallaran las
historias de usuario

3.2.1. Historia de usuario para Gestionar Estudiante

Nro. De historia Titulo

001 Gestionar Estudiante
Descripción
Permite el registro de los datos de un estudiante.
Estimación(HP) Prioridad Dependiente de
24 Alta
Criterios de aceptación

Se registra, modifica y elimina los datos del estudiante.

Responsable
Adjunto

Tabla 3.2.1.- Historia de usuario Gestionar Estudiante

Fuente: Elaboración propia

13
 3.2.2. Historia de usuario para Gestionar administrativo

Nro. De historia Titulo

002 Gestionar Administrativo
Descripción
Permite el registro de los datos de un administrativo.
Estimación(HP) Prioridad Dependiente de
24 Alta
Criterios de aceptación

Se registra, modifica y elimina los datos del administrativo.

Responsable
Adjunto

Tabla 3.2.2.- Historia de usuario Gestionar Administrativo

Fuente: Elaboración propia

14
 3.2.3. Historia de usuario para Gestionar Usuario

Nro. De historia Titulo

003 Gestionar usuario
Descripción
Permite el registro de los diferentes tipos de usuarios.
Estimación(HP) Prioridad Dependiente de
24 media
Criterios de aceptación

* Permitirá Registrar, modificar y eliminar los tipos de usuario que interactúan con el sistema.

Responsable
Adjunto

Tabla 3.2.3- Historia de usuario Gestionar usuarios

Fuente: Elaboración propia

15
 3.2.4. Historia de usuario para gestionar tipo

Nro. De historia Titulo

004 Gestionar Tipo
Descripción
Permite el registro de los diferentes tipos de trámite.
Estimación(HP) Prioridad Dependiente de
24 media
Criterios de aceptación

* Permite registrar, introducir el tipo de trámite y su descripción.

Adjunto

Tabla 3.2.4.- Historia de usuario gestionar tipo

Fuente: Elaboración propia

16
 3.2.5. Historia de usuario para gestionar tramite

Nro. De historia Titulo

Gestionar tramite
005
Descripción
Permite el registro de un trámite.
Estimación(HP) Prioridad Dependiente de
24 Alta 002,004
Criterios de aceptación

* Permite modificar, registrar y eliminar los datos de los trámites

Responsable
Adjunto

Tabla 3.2.5.- Historia de usuario gestionar tramite

Fuente: Elaboración propia

17
 3.2.6. Historia de usuario para gestionar reserva

Nro. De historia Titulo

Gestionar reserva
006
Descripción
Permite la reserva de un horario.
Estimación(HP) Prioridad Dependiente
24 Alta 001,005
Criterios de aceptación

* Se mostrara las reservas realizadas.

Responsable
Adjunto

Tabla 3.5.- Historia de usuario gestionar reserva

Fuente: Elaboración propia

18
CAPÍTULO IV: DISEÑO

19
4.1. Arquitectura de la solución para modelo en capas

Gráfico 4.1. Arquitectura de la solución

Fuente: Elaboración propia

20
4.2. Descripción de la arquitectura de la solución:
A continuación se hace una breve descripción de los distintos componentes que forman
parte de la solución en general.

 clases Datos: Permite hacer la conexión al motor de base de datos de MYSQL,

aquí se encuentra la clase llamada cls_conexion.php, en esta clase están definidos
los métodos principales para las operaciones al momento de manipular datos en
la base de datos, estos métodos son: conectar, desconectar, consultar, etc.
 clases Negocio:
Se encuentra cada una de las clases que componen el cuerpo del sistema, estas
clases se caracterizan por tener la definición de atributos, propiedades y métodos
que permiten dar forma a los objetos del sistema para cada uno de los
requerimientos de negocios del sistema.
 Aplicación de Presentación: Dentro de la aplicación se encuentran todos los
elementos de diseño para el sistema, como ser Formulario Principal, los
formularios de los Pedidos, Categoría, productos, mesa, etc.
Que son la base de diseño para poder invocar a los distintos formularios que
forman parte del sistema.

4.3. Arquitectura de la solución basada en la tecnología web

La programación por capas es un estilo de programación en la que le objetivo primordial es la
separación de la lógica de negocios de la lógica de diseño, un ejemplo básico de esto es separar la
capa de datos de la capa presentación al usuario.

Gráfico 4.2. Arquitectura tres capas

Fuente: [msdn.microsoft.com]

21
La ventaja principal de este estilo, es que en caso de algún cambio sólo se ataca al nivel requerido
sin tener que revisar entre código mezclado. Además permite distribuir el trabajo de creación de
una aplicación por capas, de este modo, cada grupo de trabajo está totalmente abstraído del
resto de niveles.
En el diseño de sistemas informáticos actual se suele usar la arquitectura Programación por capas.
En dicha arquitectura a cada capa se le confía una misión simple, lo que permite el diseño de
arquitecturas escalable (que pueden ampliarse con facilidad en caso de que las necesidades
aumenten).

4.4. Descripción de Capas

Capa de Presentación
Es la que ve el usuario, presenta el sistemas al usuario, le comunica la información y captura la
información del usuario dando un mínimo de proceso (realiza un filtrado previo para comprobar
que no hay errores de formato). Esta capa se comunica únicamente con la capa de negocio.

Capa de Negocio
Es donde residen los programas que se ejecutan, recibiendo las peticiones del usuario y enviando
las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) pues
aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la para
presentación para recibir las solicitudes y presentar los resultados, y con la capa de datos, para
solicitar al gestor de base de datos para almacenar o recuperar los datos en él.
Capa de Datos
Es donde residen los datos. Está formada por uno o más gestores de base de datos que realiza
todo el almacenamiento de datos y reciben solicitudes de almacenamiento o recuperación de
información desde la capa de negocio.

ADO.NET
Los proveedores de acceso a datos ADO.NET (conocidos como “Managed Data Providers”),
representan conjuntos específicos de clases que permiten conectarse e interactuar con una base
de datos, cada uno utilizando un protocolo particular.

ADO.NET provee una arquitectura extensible, posibilitando que terceras partes creen sus propios
proveedores de acceso nativo para aplicaciones .NET.

22
4.5. Diseño de la base de datos
4.5.1. Diagrama conceptual de la base de datos
class Domain Mo...

TIPO
ADMIN
PERFIL - ID: int
- login: varchar - Descripcion: varchar
1
- ID: int - contraseña: varchar 1..
- nombre: char
1..

1..* 1..*

1..* TRAMITE
HORARIO
USUARIO 1..* - Id: int
- fechaini: datetime - ID: int
1.. 1..* -
- CI: int - fechafin: datetime fecha: date
- nombre: varchar - horasxdia: int - hora: time
- direccion: varchar - alumnos: int
- telefono: varchar
1.. 1..

1..*
1..*
ESTUDIANTE
RESERVA
TAREA - registro: int
- contraseña: varchar - id: int
- ID: int 1.. 1..* 1..*
- carrera: varchar
- nombre: char

Gráfico 4.3. Diseño conceptual de la base de datos

Fuente: Elaboración propia

23
4.5.2. Diseño Lógico
4.5.2.1. Diseño lógico relacional

Usuario
CI Nombre Dirección Teléfono Id_perfil
PK FK

Estudiante
Registro Contraseña Carrera
PK

Admin
login Contraseña
PK

Reserva
ID Id_horario Id_tramite Registro_estudiante
PK FK FK FK

Tramite
ID Fechaini fechafin horasxdia alumnos Ci_usuario Id_tipo
PK FK FK

Tipo
Id Descripcion
PK

Tarea
Id Nombre
PK

Perfil
Id Nombre
PK

Horario
ID Fecha hora Id_tramite
PK FK

24
4.5.2.2. Diseño lógico especifico de la base de datos
CREATE TABLE tarea (

id int(11) NOT NULL AUTO_INCREMENT,

nombre char(20) DEFAULT NULL,

PRIMARY KEY (id)

CREATE TABLE perfil (

id int(11) NOT NULL AUTO_INCREMENT,

nombre char(15) DEFAULT NULL,

PRIMARY KEY (id)

CREATE TABLE perfil_tarea (

id_perfil int(11) NOT NULL,

id_tarea int(11) NOT NULL,

PRIMARY KEY (id_perfil,id_tarea),

KEY id_tarea (id_tarea)

CREATE TABLE usuario(

CI int NOT NULL,

nombre VARCHAR(20),

direccion VARCHAR(30),

telefono VARCHAR(10),

id_perfil int,

PRIMARY KEY(CI),

FOREIGN KEY(id_perfil) REFERENCES perfil(id)

25
CREATE TABLE estudiante(

ci_usuario int NOT NULL,

registro int,

contraseña VARCHAR(10),

carrera VARCHAR(50),

PRIMARY KEY(ci_usuario),

FOREIGN KEY(ci_usuario) REFERENCES usuario(CI)

CREATE TABLE admin(

ci_usuario int NOT NULL,

login VARCHAR(10),

contraseña VARCHAR(10),

PRIMARY KEY(ci_usuario),

FOREIGN KEY(ci_usuario) REFERENCES usuario(CI)

CREATE TABLE tipo(

ID int NOT NULL AUTO_INCREMENT,

descripcion VARCHAR(20),

PRIMARY KEY(ID)

CREATE TABLE horario(

ID int NOT NULL AUTO_INCREMENT,

fecha date,

hora time,

id_tramite int,

PRIMARY KEY(ID),

FOREIGN KEY(id_tramite) REFERENCES tramite(id)

26
CREATE TABLE tramite(

ID int NOT NULL AUTO_INCREMENT,

fechaini datetime,

fechafin datetime,

horasxdia int,

alumnos int,

id_tipo int,

ci_usuario int,

PRIMARY KEY(ID),

FOREIGN KEY(id_tipo) REFERENCES tipo(id),

FOREIGN KEY(ci_usuario) REFERENCES admin(ci_usuario)

CREATE TABLE reserva(

ID int NOT NULL AUTO_INCREMENT,

id_horario int,

id_tramite int,

registro_est int,

PRIMARY KEY(ID),

FOREIGN KEY(id_horario) REFERENCES horario(id),

FOREIGN KEY(id_tramite) REFERENCES tramite(id),

FOREIGN KEY(registro_est) REFERENCES estudiante(registro)

27
CAPÍTULO V:
IMPLEMENTACIÓN

28
5.1. APLICACIÓN ESCRITORIO (Código Fuente)
5.1.1. Implementación de Usuario: Clase Usuario, Formulario Usuario Clase
Usuario

29