Documentos de Académico
Documentos de Profesional
Documentos de Cultura
RENE MORENO
FINOR
INGENIERÍA DE SISTEMAS
CPD-FINOR
Presentado por:
2
CAPÍTULO I
PERFIL DE PROYECTO
3
1.1. INTRODUCCION
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.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.
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
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
- 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)
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
Lista de distribución
En fecha 02/06/2016
8
2.2. REQUERIMIENTOS NO FUNCIONALES
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.
9
2.2.1. Tiempo de aprendizaje
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.
2.2.3. Confiabilidad
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.
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
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.
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
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 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:
Responsable
Adjunto
13
3.2.2. Historia de usuario para Gestionar administrativo
Responsable
Adjunto
14
3.2.3. Historia de usuario para Gestionar Usuario
* Permitirá Registrar, modificar y eliminar los tipos de usuario que interactúan con el sistema.
Responsable
Adjunto
15
3.2.4. Historia de usuario para gestionar tipo
Adjunto
16
3.2.5. Historia de usuario para gestionar tramite
Responsable
Adjunto
17
3.2.6. Historia de usuario para gestionar reserva
Responsable
Adjunto
18
CAPÍTULO IV: DISEÑO
19
4.1. Arquitectura de la solución para modelo en capas
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.
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).
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
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 (
nombre VARCHAR(20),
direccion VARCHAR(30),
telefono VARCHAR(10),
id_perfil int,
PRIMARY KEY(CI),
25
CREATE TABLE estudiante(
registro int,
contraseña VARCHAR(10),
carrera VARCHAR(50),
PRIMARY KEY(ci_usuario),
login VARCHAR(10),
contraseña VARCHAR(10),
PRIMARY KEY(ci_usuario),
descripcion VARCHAR(20),
PRIMARY KEY(ID)
fecha date,
hora time,
id_tramite int,
PRIMARY KEY(ID),
26
CREATE TABLE tramite(
fechaini datetime,
fechafin datetime,
horasxdia int,
alumnos int,
id_tipo int,
ci_usuario int,
PRIMARY KEY(ID),
id_horario int,
id_tramite int,
registro_est int,
PRIMARY KEY(ID),
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