analisis diseÑo e implementaciÓn de un...
TRANSCRIPT
1
ANALISIS DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE
INFORMACIÓN PARA LA GESTIÓN DE ALQUILER Y MANTENIMIENTO DE
VEHICULOS.
YESID ORDUZ NAVARRETE
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS.
FACULTAD DE INGENIERÍA.
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS.
BOGOTÁ.
2016
2
ANALISIS DISEÑO E IMPLEMENTACIÓN DE UN SISTEMA DE
INFORMACIÓN PARA LA GESTIÓN DE ALQUILER Y MANTENIMIENTO DE
VEHICULOS.
YESID ORDUZ NAVARRETE
Proyecto de Pasantía para optar al título de
Ingeniero de Sistemas.
Director Interno:
Ing. Joaquín Javier Meza
Docente Universidad Distrital.
Director Externo:
Ing. Hals Rodríguez Santamaría.
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS.
FACULTAD DE INGENIERÍA.
PROYECTO CURRICULAR DE INGENIERÍA DE SISTEMAS.
BOGOTÁ.
2016
3
Tabla de contenido INTRODUCCIÓN………………………………………………………...2
1. FORMULACIÓN DEL PROBLEMA………………….………………....3
1.1.Descripción del Entorno……………………….…….….….………….3
1.2. Definición del Problema……………………………….…..………….3
2. JUSTIFICACION……………………………………………..…….….….4
2.1. Justificación Operativa……………………………………..…..……..4
2.2. Justificación Académica………………………………...…...……….5
3. OBJETIVOS…………………………………………………..…...………6
3.1. OBJETIVO GENERAL…………………………….…...……………6
3.2. OBJETIVOS ESPECÍFICOS……………………..…………………..6
4. ALCANCES Y LIMITACIONES…………………………………………7
4.1. ALCANCES…………………………………………………………..7
4.2. LIMITACIONES………………………………………...……………8
4.3.PARTICIPANTES EN EL PROYECTO………………..…………….8
5. MARCO REFERENCIAL….……………………………………………..9
5.1. Conceptos Relacionados con el Diseño de la Aplicación…......….…..9
5.1.1. Patrones de Diseño……………………………………….…..……..9
5.1.2. Ventajas de los patrones………………………………….………10
5.1.3. Modelo Vista Controlador……………………………..…………11
5.1.4. Arquitectura De Tres Capas…………………………..………….14
5.2.MARCO TEÓRICO…..………………………………….….……….16
5.2.1. FRAMEWORK………………………………………....…………16
5.2.2. Arquitectura……………………………………………...…………18
5.2.2.1. Modelo……….…………………………………………………..18
5.2.2.2. Vista……………………………………………….……………..18
5.2.2.3. Controlador……………………………………..………………..18
5.2.3. Estructura…………………………………………………………..19
5.2.3.1. Lógica………………………………………………..…………..19
5.2.4. Framework Laravel………………………….……….……………20
5.2.4.1. Componentes De Laravel……………….………………...……..21
5.2.4.2. Arquitectura Laravel……………………………………..….…..22
5.2.4.2.1. Ciclo De Vida De Una Solicitud……………………..……..…22
5.2.4.2.2. Estructura De La Aplicación………………………..…………23
5.2.4.2.3. Serviceproviders (Proveedores De Servicio)………….....……24
5.2.4.2.4.ServiceContainer……………………………………....……….25
5.2.4.2.5. Contratos (Contracts)………………….…………………..…..26
5.2.4.2.6. Facade………………………………..………………….……..27
5.5.5. Características De Laravel……………………………...………….27
6. DISEÑO METODOLOGICO…………………….……………….…..…29
6.1.Conocimiento Global de la Empresa…………….…………………..29
6.1.1.Reseña Histórica………………………………………………..….29
6.1.2. Objetivos de la organización……………………………...……….30
6.1.3. Definición de la Actividad de la Empresa…………………………31
6.1.4. Misión…………………………………………………………….32
6.1.5. Evaluación de la Misión……………………………….…………32
4
6.1.6. Matriz DOFA………………………………………..……………33
7. DESARROLLO DE SOFTWARE………………………….……………34
7.1. Fases Del Proyecto…………………………………………..………34
7.1.1. Fase de Inicio………………………….……….……………..……34
7.1.2. Modelado del Sistema………………….……..….…………….….34
7.1.3. Escenarios………………………….……….…………….…….….35
7.1.4. Fase de Elaboración……….……………….……..…………….….37
7.1.4.1 Actores Del Sistema………………….…………………………..38
7.1.4.2.Especificaciones De Casos De Uso………………….…………..40
8. MODELOS DE ANALISIS Y DISEÑO…………………………...…….43
8.1. Clases conceptuales………………………………………………….44
8.2. Modelo Entidad – Relación……………………………...…………..45
8.2.1. Diccionario de datos…………………………………...…………..46
8.3. Modelo de despliegue………………………………..………………54
8.4. Modelo vista controlador…………………………………………….55
8.5. Fase de construcción….……………………………………….....….56
8.5.1. Interfaces………..…...……………………………………...……..57
8.5.1.1. Interfaz de ingreso de usuarios al sistema……………………….57
8.5.1.2. Interfaz gestionar conductor…………………………………..…58
8.5.1.3. Interfaz gestionar vehículo…………………………………..…..58
8.5.1.4. Interfaz ver facturas…………………………………………..….59
8.5.1.5. Interfaz registrar daño de vehículo…………………..…………..59
8.5.1.6. Interfaz solicitud de alquiler……………………………………..60
8.5.1.7. Interfaz agendar vehículo………………………………………..60
8.5.1.8. Interfaz ingresar cliente…………………………...……………..61
8.5.1.9. Interfaz ingresar vehículo a taller………………………………..61
8.5.1.10. Interfaz entregar vehículo……………………………………....62
8.5.1.11.Interfaz registrar arreglo de vehículo……………………..…….62
8.5.2. Interfaces definitivas…………………………………………...….63
8.5.2.1. Interfaz de ingreso al sistema……………………………………63
8.5.2.2. Interfaz para cambiar el password……………………………....64
8.5.2.3. Interfaz de cambio de password…………………………………65
8.5.2.4. Interfaz de inicio del sistema…………………………………....65
8.5.2.5. Interfaz formulario de ingreso de solicitud……………………..66
8.5.2.6. Detalle de solicitud…………………………………………..….67
8.5.2.7. Interfaz lista de chequeo de salida de vehículo………………….68
8.5.2.8. Interfaz lista de chequeo de entrega de vehículo…………….….70
8.5.2.9. Interfaz de factura sin novedades…………………………..……72
8.5.2.10. Interfaz de factura con novedades……………………………...73
8.5.2.11. Interfaz de visualización de facturas generadas………………..74
8.5.2.13. Interfaz de visualización de vehículos………………………....74
8.5.2.14. Interfaz de visualización de clientes…………………………...75
8.5.2.15. Interfaz actualización de los datos de clientes………………....75
8.5.2.16. Interfaz de registro de nuevos clientes…………………………76
9. CONCLUSIONES………………………………………………………..77
10. BIBLIOGRAFIA…………………………………………...…………….78
5
INTRODUCCIÓN
Este trabajo de pasantía es realizado en la empresa ORION TECHNOLOGIES que
se dedica al desarrollo de soluciones en sistemas, esta empresa convoco a
estudiantes de último semestre de Ingeniería de Sistemas interesados en realizar
su trabajo de grado en la modalidad de pasantía, llevando a cabo el proceso de
selección de la persona idónea para realizar el proyecto. Las actividades que se
dispusieron fueron bajo la dirección del Ingeniero coordinador del proyecto en la
empresa.
En este proyecto se diseñó e implemento una aplicación para el manejo de alquiler
de vehículos en una empresa de transportes (TRANSPORTES ZAMBRANO) para
la empresa ORION TECHNOLOGIES.
Este sistema consiste en un software para manejar los procesos de alquiler y
mantenimiento de vehículos, haciendo modelado, integración, monitoreo y control
de los procesos operativos llevados a cabo por los actores que intervienen en cada
una de las capas del negocio.
Se Utilizó la metodología basada en los principios de Análisis y diseño orientado a
objetos, también la metodología RUP de diseño y desarrollo de software establecido
en UML para realizar el análisis de requerimientos, diseñar y elaborar casos de uso,
prototipos, para su posterior desarrollo.
6
1. FORMULACIÓN DEL PROBLEMA
1.1. Descripción del Entorno
TRANSPORTE ZAMBRANO es una empresa dedicada al servicio de transporte
fluvial, terrestre de pasajeros y carga, también se dedica al alquiler de vehículos,
con más de 10 años de experiencia prestando sus servicios en la zona del
Magdalena medio, siempre ha pensado en la satisfacción de los clientes; teniendo
proyectado expandir sus servicios a nivel nacional.
Al ser fundada TRANSPORTE ZAMBRANO se propuso dos metas principales
ofrecer un excelente servicio y crecer, pero después de diez años el desarrollo y
crecimiento no ha sido el planeado, debido a factores que afectan a la mayoría de
las empresas de este sector como la competencia, problemas económicos y de
orden público del país, etc.; en ese tiempo trabajando la empresa no se había
preocupado por al manejo de su información y procesos, los cuales son llevados de
forma casi manual y sin ninguna estructura que facilite su registro, control y
búsqueda cuando sea requerido.
1.2. Definición del Problema
En el momento de comenzar con el proyecto la empresa venía realizando su trabajo
de la misma forma que lo hacía cuando fue fundada hace 10 años, es decir llevando
toda la información y registros de forma manual, las bases de datos de sus clientes
y proveedores estaban registradas en libros lo que impedía llevar un control total de
sus operaciones, el control de los alquileres, así como todos los datos que tienen
que ver y se desprenden de cada operación realizada. Desde la parte administrativa
no se había reconocido la importancia que tiene poder acceder a la información de
7
forma rápida y eficiente, esta imposibilidad que tenía la empresa dificultaba que
tuviera una operación eficiente.
A pesar de tener una estructura organizativa relativamente simple los procesos
administrativos, y operativos que efectúa no lo son, no contaba con ningún sistema
de información con el que pudiera hacer un seguimiento continuo de la información
que era actualizada constantemente en las áreas administrativas y operativas, lo
cual permitía factores de riesgo en la obtención de los objetivos organizacionales.
La ausencia de algún sistema le da paso a que se presenten y repitan los problemas
que siempre ha tenido la empresa, no poder controlar la gran cantidad de
información diversa que se maneja esto genera retardos, mala toma de decisiones
y acciones a nivel táctico y operativo, que van en deterioro del cumplimiento de los
objetivos que tiene la empresa.
2. JUSTIFICACION
2.1. Justificación Operativa
Se justifica la implementación de un software para el manejo del alquiler de
vehículos para la empresa Transportes Zambrano el cual permitirá, una vez
desarrollado en su totalidad y en óptimo funcionamiento, entre otros beneficios la
automatización de la actividad principal de la empresa coordinando las funciones y
procedimientos de personas y sistemas, mejora continua en la ejecución de
procesos al facilitar el acceso a la información, facilita la cooperación directa y el
compromiso conjunto de los empleados en la realización de sus labores.
Proporciona una disponibilidad mayor de la información en el momento justo que es
requerida alcanzando un control efectivo de las actividades de la empresa, eliminar
la dificultad de recopilar la información en lugares distantes, evitado errores pérdidas
8
de tiempo y recursos en los procedimientos que se llevan a cabo además de su
mejoramiento continuo.
Por tal motivo, es necesario que la empresa, cuente con este sistema, que permite
controlar identificar, evaluar y manejar de manera efectiva el proceso de alquiler de
vehículos; minimizando los inconvenientes que han impedido su crecimiento.
2.2. Justificación Académica
El proyecto recogió las herramientas de conocimiento adquiridas durante el
transcurso la carrera, en particular de aquellas áreas relativas al desarrollo de
software, métodos, procedimientos, y aquellas que tienen que ver con el diseño y
modelado de Software para manejo de procedimientos en arquitectura web de tres
capas, procurando una adaptación de esos modelos académicos a las condiciones
y particularidades propias del entorno de la empresa.
En ese aspecto se ubica también la motivación principal del trabajo en el sentido de
entendimiento y responsabilidad que como estudiante participé del proyecto posee
frente al objetivo, realizándolo a través de la pasantía como modalidad de trabajo
de grado
9
3. OBJETIVOS
3.1. OBJETIVO GENERAL
Diseñar desarrollar e implementar una aplicación computacional mediante
framework libre y PHP software que permita el manejo y gestión del alquiler de
vehículos sobre infraestructuras livianas, minimizando los procesos y
procedimientos actuales.
3.2. OBJETIVOS ESPECÍFICOS
Realizar el análisis de procesos que se llevan a cabo en Transporte
Zambrano.
Unificar las actividades del negocio y coordinar las acciones y procedimientos
de personas y sistemas en torno al trabajo.
Facilitar búsqueda rápida de los datos fundamentales para el desarrollo diario
de las actividades del negocio.
Aumentar la cooperación directa y el compromiso conjunto de los
trabajadores de la empresa en el paso para la optimización de los procesos
operativos del negocio.
Implementar una solución que facilite el procesamiento de las entradas de
información rápidamente, así como la codificación de acuerdo a las
necesidades.
10
Aumentar el nivel de rendimiento en todas las operaciones del negocio para
garantizar la satisfacción del cliente.
4. ALCANCES Y LIMITACIONES
A continuación, se especifican los alcances del proyecto teniendo en cuenta el
tiempo, el área que va a ocupar y la formulación del problema.
4.1. ALCANCES
Los alcances son:
Definir los diagramas de flujo para la empresa.
Generar los modelos de análisis y diseño del software para manejar los
alquileres de vehículos y el mantenimiento de los mismos en Transportes
Zambrano.
Diseñar la base de datos para el software de sistema de información
Diseñar una interfaz gráfica amigable para los usuarios del software
Tomar la información desde las fases de moldeamiento o implementación e
introducir cambios de ser necesario en los procesos.
11
4.2. LIMITACIONES
Las limitaciones son:
Debe contemplarse las implicaciones de los siguientes puntos críticos:
La solución será compatible con los equipos de la empresa.
La solución debe adaptarse a la normativa de protección de
información, seguridad en las trasmisiones de datos, etc.
No será un Sistema que permita establecer Normatividad ni Estatutos.
No permitirá realizar análisis contable ni financiero de la empresa.
El Sistema no se aplicará Directamente a la Gestión de calidad,
Aunque permite ajustar los procesos como parámetros de la
normatividad ISO 9001.
4.3. PARTICIPANTES EN EL PROYECTO
Se incluye el personal que designó empresa Orion Technologies para supervisar
el desarrollo de proyecto además de los partícipes directos, revisores, director
interno u otros participantes que se estimen convenientes para proporcionar los
requisitos y validar el sistema.
Director interno: Ingeniero Joaquín Javier Meza docente de la Universidad
Distrital acompañamiento durante todo el desarrollo y avance del proyecto
12
Director externo: Ingeniero Hals Rodríguez Santamaría designado por la
empresa para supervisar y asesorar en todo el desarrollo del proyecto.
Analista de Sistemas. El perfil establecido es: Ingeniero en Informática con
conocimientos de UML, labor que llevo a cabo el pasante Yesid Orduz
Analistas - Programadores. Con experiencia en el entorno de desarrollo del
proyecto, con el fin de que los prototipos puedan ser lo más cercanos posibles
al producto final. Este trabajo realizado por el pasante Yesid Orduz.
Ingeniero de Software. El perfil establecido es: Alumno que pertenezca al
Proyecto Curricular de ingeniería de Sistemas realizando labores de gestión
de requisitos, gestión de configuración, documentación y diseño de datos.
Labor realizada por le pasante Yesid Orduz.
5. MARCO REFERENCIAL
5.1. Conceptos Relacionados Con El Diseño De La Aplicación
5.1.1. Patrones de Diseño
El diseño es un modelo del sistema, realizado con una serie de principios y técnicas,
que permite describir el sistema con el suficiente detalle como para ser
implementado. Pero los principios y reglas no son suficientes, en el contexto de
diseño se puede observar que los diseñadores e ingenieros de software tienen
esquemas y estructuras de solución que usan numerosas veces en función del
contexto del problema.
El patrón es un esquema de solución que se aplica a un tipo de problema, esta
aplicación del patrón no es mecánica, sino que requiere de adaptación y matices.
Los patrones se clasifican según el propósito para el que han sido definidos:
13
Creacionales: solucionan problemas de creación de instancias. Nos ayudan a
encapsular y abstraer dicha creación.
Estructurales: solucionan problemas de composición (agregación) de clases y
objetos.
De Comportamiento: soluciones respecto a la interacción y responsabilidades entre
clases y objetos, así como los algoritmos que encapsulan.
Según el ámbito se clasifican en patrones de clase y de objeto:
Catálogo de patrones de diseño de Gamma et al. (1994)
5.1.2. Ventajas de los patrones
La clave para la reutilización es anticiparse a los nuevos requisitos y cambios, de
modo que los sistemas evolucionen de forma adecuada. Cada patrón permite que
algunos aspectos de la estructura del sistema puedan cambiar independientemente
de otros aspectos. Facilitan la reusabilidad, extensibilidad y mantenimiento.
Un patrón es un esquema o micro arquitectura que supone una solución a
problemas (dominios de aplicación) semejantes (aunque los dominios de problema
pueden ser muy diferentes e ir desde una aplicación CAD a un cuadro de mando
14
empresarial). Interesa constatar una vez más la vieja distinción entre dominio del
problema (donde aparecen las clases propias del dominio, como cuenta, empleado,
coche o beneficiario) y el dominio de la solución o aplicación (donde además
aparecen clases como ventana, menú, contenedor o listener). Los patrones son
patrones del dominio de la solución.
También conviene distinguir entre un patrón y una arquitectura global del sistema.
Por decirlo en breve, es la misma distancia que hay entre el diseño de un
componente (o módulo) y el análisis del sistema. Es la diferencia que hay entre el
aspecto micro y el macro, por ello, en ocasiones se denomina a los patrones como
"microarquitecturas".1
En resumen, un patrón es el denominador común, una estructura común que tienen
aplicaciones semejantes. Esto también ocurre en otros órdenes de la vida. Por
ejemplo, en nuestra vida cotidiana aplicamos a menudo el esquema saludo-
presentación-mensaje-despedida en ocasiones diversas, que van desde un intento
de ligar hasta dar una conferencia (si todavía no cree que existan patrones o que
no son útiles intente ligar con el esquema despedida-mensaje-presentación-saludo,
a ver qué ocurre).
5.1.3. Modelo Vista Controlador
Para el diseño de aplicaciones con sofisticadas interfaces se utiliza el patrón de
diseño Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con
más frecuencia que los almacenes de datos y la lógica de negocio. Se trata de
realizar un diseño que desacople la vista del modelo, con la finalidad de mejorar la
reusabilidad. De esta forma las modificaciones en las vistas impactan en menor
medida en la lógica de negocio o de datos.
___________________________
1Tomado de: http://inggabrielrodriguezmolinares.blogspot.com.co/2012/03/patrones-de-desarrollo-de-
software.html
15
Elementos del patrón:
Modelo: datos y reglas de negocio
Vista: muestra la información del modelo al usuario
Controlador: gestiona las entradas del usuario
http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10
Un modelo puede tener diversas vistas, cada una con su correspondiente
controlador. Un ejemplo clásico es el de la información de una base de datos, que
se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc.1
El modelo es el responsable de:
o Acceder a la capa de almacenamiento de datos. Lo ideal es que el
modelo sea independiente del sistema de almacenamiento.
o Definir las reglas de negocio (la funcionalidad del sistema). Un ejemplo
de regla puede ser: "Si la mercancía pedida no está en el almacén,
consultar el tiempo de entrega estándar del proveedor".
o Llevar un registro de las vistas y controladores del sistema.
o Si se está ante un modelo activo, notificar a las vistas los cambios que
en los datos pueda producir un agente externo (por ejemplo, un fichero
___________________________
1Tomado de: revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10
16
batch que actualiza los datos, un temporizador que desencadena una
inserción, etc).
El controlador es responsable de:
o Recibir los eventos de entrada (un clic, un cambio en un campo de
texto, etc.).
o Contener las reglas de gestión de eventos, del tipo "SI Evento Z,
entonces Acción W". Estas acciones pueden suponer peticiones al
modelo o a las vistas. Una de estas peticiones a las vistas puede ser
una llamada al método "Actualizar ()". Una petición al modelo puede
ser "Obtener tiempo de entrega (nueva orden de venta)".
Las vistas son responsables de:
o Recibir datos del modelo y la muestra al usuario.
o Tener un registro de su controlador asociado (normalmente porque
además lo instancia).
o Poder dar el servicio de "Actualización ()", para que sea invocado por
el controlador o por el modelo (cuando es un modelo activo que
informa de los cambios en los datos producidos por otros agentes).
Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los
datos) es la navegación web, que responde a las entradas del usuario, pero no
detecta los cambios en datos del servidor.
17
http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10
Pasos:
El usuario introduce el evento.
El Controlador recibe el evento y lo traduce en una petición al Modelo
(aunque también puede llamar directamente a la vista).
El modelo (si es necesario) llama a la vista para su actualización.
Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
El Controlador recibe el control.
5.1.4. Arquitectura De Tres Capas
La programación por capas es una arquitectura cliente-servidor en el que el 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 consiste en separar la capa de datos de la capa de
presentación al usuario.
La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en
varios niveles y, en caso de que sobrevenga algún cambio, solo se ataca al nivel
requerido sin tener que revisar entre código mezclado. Un buen ejemplo de este
método de programación sería el modelo de interconexión de sistemas abiertos.
18
Además, permite distribuir el trabajo de creación de una aplicación por niveles; de
este modo, cada grupo de trabajo está totalmente abstraído del resto de niveles, de
forma que basta con conocer la API que existe entre niveles.
En el diseño de sistemas informáticos actual se suelen usar las arquitecturas
multinivel o Programación por capas. En dichas arquitecturas a cada nivel se le
confía una misión simple, lo que permite el diseño de arquitecturas escalables (que
pueden ampliarse con facilidad en caso de que las necesidades aumenten).1
Capas y niveles
1. Capa de presentación: la que ve el usuario (también se la denomina "capa
de usuario"), presenta el sistema al usuario, le comunica la información y
captura la información del usuario en un mínimo de proceso (realiza un
filtrado previo para comprobar que no hay errores de formato). También es
conocida como interfaz gráfica y debe tener la característica de ser
"amigable" (entendible y fácil de usar) para el usuario. Esta capa se comunica
únicamente con la capa de negocio.
2. Capa de negocio: es donde residen los programas que se ejecutan, se
reciben las peticiones del usuario y se envían las respuestas tras el proceso.
Se denomina capa de negocio (e incluso de lógica del negocio) porque es
aquí donde se establecen todas las reglas que deben cumplirse. Esta capa
se comunica con la capa de presentación, para recibir las solicitudes y
presentar los resultados, y con la capa de datos, para solicitar al gestor
de base de datos almacenar o recuperar datos de él. También se consideran
aquí los programas de aplicación.
3. Capa de datos: es donde residen los datos y es la encargada de acceder a
los mismos. Está formada por uno o más gestores de bases de datos que
realizan todo el almacenamiento de datos, reciben solicitudes de
almacenamiento o recuperación de información desde la capa de negocio.
___________________________
1Tomado de: http://www.academia.edu/10102692/Arquitectura_de_n_capas
19
Todas estas capas pueden residir en un único ordenador, si bien lo más usual es
que haya una multitud de ordenadores en donde reside la capa de presentación
(son los clientes de la arquitectura cliente/servidor). Las capas de negocio y de datos
pueden residir en el mismo ordenador, y si el crecimiento de las necesidades lo
aconseja se pueden separar en dos o más ordenadores. Así, si el tamaño o
complejidad de la base de datos aumenta, se puede separar en varios ordenadores
los cuales recibirán las peticiones del ordenador en que resida la capa de negocio.
5.2. MARCO TEÓRICO
Con el fin de alcanzar cada uno de los objetivos propuestos, se plantea una
metodología basada en: RUP (Rational Unified Proccess) la cual utiliza UML como
lenguaje de Modelado
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo
e incremental), todos los artefactos son objeto de modificaciones a lo largo del
proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una
versión definitiva y completa de cada uno de ellos.
5.2.1. FRAMEWORK
La palabra inglesa "framework" (infraestructura, armazón, marco) define, en
términos generales, un conjunto estandarizado de conceptos, prácticas y criterios
para enfocar un tipo de problemática particular que sirve como referencia, para
enfrentar y resolver nuevos problemas de índole similar1.
En el desarrollo de software, un framework o infraestructura digital, es una
estructura conceptual y tecnológica de soporte definido, normalmente con artefactos
o módulos concretos de software, que puede servir de base para la organización y
desarrollo de software. Típicamente, puede incluir soporte
___________________________
1Tomado de: https://es.wikipedia.org/wiki/Framework
20
de programas, bibliotecas, y un lenguaje interpretado, entre otras herramientas,
para así ayudar a desarrollar y unir los diferentes componentes de un proyecto.
Representa una arquitectura de software que modela las relaciones generales de
las entidades del dominio, y provee una estructura y una especial metodología de
trabajo, la cual extiende o utiliza las aplicaciones del dominio
Los frameworks tienen como objetivo principal ofrecer una funcionalidad definida,
auto contenida, siendo construidos usando patrones de diseño, y su característica
principal es su alta cohesión y bajo acoplamiento. Para acceder a esa funcionalidad,
se construyen piezas, objetos, llamados objetos calientes, que vinculan las
necesidades del sistema con la funcionalidad que este presta. Esta funcionalidad,
está constituida por objetos llamados fríos, que sufren poco o ningún cambio en la
vida del framework, permitiendo la portabilidad entre distintos sistemas.
Frameworks conocidos que se pueden mencionar por ejemplo son Spring
Framework, Hibernate, donde lo esencial para ser denominados frameworks es
estar constituidos por objetos casi estáticos con funcionalidad definida a nivel grupo
de objetos y no como parte constitutiva de estos, por ejemplo en sus métodos, en
cuyo caso se habla de un API o librería. Algunas características notables que se
pueden observar:
La inversión de control: en un framework, a diferencia de las bibliotecas, el
flujo de control no es dictado por el programa que llama, sino por el mismo.21
La funcionalidad o comportamiento predeterminado: un marco tiene un
comportamiento predeterminado. Este comportamiento por defecto debe ser
un comportamiento útil, definido e identificable.
Su extensibilidad: un marco puede ser ampliado para proporcionar una
funcionalidad específica. El frame, en general, no se supone que deba ser
modificado, excepto en cuanto a extensibilidad. Los usuarios pueden ampliar
sus características, pero no deben ni necesitan modificar su código.
5.2.2. Arquitectura
21
Dentro de este aspecto, podemos basarnos en el modelo–vista–controlador o MVC
(Controlador => Modelo => Vista), ya que debemos fragmentar
nuestra programación. Tenemos que contemplar estos aspectos básicos en cuanto
a la implementación de nuestro sistema:
5.2.2.1. Modelo
Este miembro del controlador maneja las operaciones lógicas, y de manejo de
información (previamente enviada por su ancestro), para resultar de una forma
explicable y sin titubeos. Cada miembro debe ser meticulosamente llamado, con su
correcto nombre y en principio, con su verdadera naturaleza: el manejo de
información, su complementación directa.
5.2.2.2. Vista
Al final, a este miembro de la familia le corresponde dibujar, o expresar la última
forma de los datos: la interfaz gráfica que interactúa con el usuario final del
programa (GUI). Después de todo, a este miembro le toca evidenciar la información
obtenida hasta hacerla llegar al controlador. Solo (e inicialmente), nos espera
demostrar la información.
5.2.2.3. Controlador
Con este apartado podemos controlar el acceso (incluso todo) a nuestra aplicación,
y esto puede incluir: archivos, scripts, y/o programas; cualquier tipo de información
que permita la interfaz. Así, podremos diversificar nuestro contenido de forma
dinámica, y estática (a la vez); pues, solo debemos controlar ciertos aspectos (como
se ha mencionado antes).
22
5.2.3. Estructura
Dentro del controlador, modelo o vista, se pueden manejar datos, y depende de
cada uno cómo interpretar y manejar esos datos. Se sabe que el único dato de una
dirección estática web es: conseguir un archivo físico en el disco duro o de Internet,
etcétera e interpretado o no, el servidor responde.
El modelo, al igual que el controlador y la vista, maneja todos los datos que se
relacionen consigo (solo es el proceso medio de la separación por capas que ofrece
la arquitectura MVC). Y solo la vista, puede demostrar dicha información. Con lo
cual ya se ha generado la jerarquía de nuestro programa: Controlador, Modelo y
Vista.
5.2.3.1. Lógica
Al parecer, debemos inyectar ciertos objetos dentro de sus parientes en esta
aplicación, solo así compartirán herencia y coherencia en su aplicación.
Rápidamente, para una aplicación web sencilla debemos establecer estos objetos:
Una base (MVC)
23
Controlador: este debe ser capaz de manejar rutas, archivos, clases,
métodos y funciones.
Modelo: es como un script habitual en el servidor, solo que agrupado
bajo un 'modelo' reutilizable.
Vista: como incluyendo cualquier archivo en nuestra ejecución, muy
simple.
Un sistema
Ruteador: con él podemos dividir nuestras peticiones sin tantas
condicionales.
Cargador
5.1.4. FRAMEWORK LARAVEL
Para la implementación del sistema se trabajara directamente con Laravel un
Framework desarrollado para implementar aplicaciones en PHP.
Laravel es un framework de código abierto para desarrollar aplicaciones y servicios
web con PHP 5. Su filosofía es desarrollar código PHP de forma elegante y simple,
evitando el "código espagueti". Fue creado en 2011 y tiene una gran influencia de
frameworks como Ruby on Rails, Sinatra y ASP.NET1
Laravel tiene como objetivo ser un framework que permita el uso de una sintaxis
elegante y expresiva para crear código de forma sencilla y permitiendo multitud de
funcionalidades. Intenta aprovechar lo mejor de otros frameworks y aprovechar las
características de las últimas versiones de PHP.2. Gran parte de Laravel está
formado por dependencias, especialmente de Symfony, esto implica que el
desarrollo de Laravel dependa también del desarrollo de sus dependencias
___________________________
1Tomado de: http://cayab.com.mx/laravel-framework-para-php/
24
5.1.4.1. COMPONENTES DE LARAVEL
Lo basico: El framework posee lo que ya imaginamos: Router, Models,
Layouts, Views, Controllers, etc. Para los templates utiliza un engine propio
que se llama Blade, que tiene algunos helpers copados.
Artesano: Cliente de consola que permite ejecutar comandos propios del
framework. Es muy versátil, potente e incluso nos permite extenderlo creando
nuestras propias tareas para que estén disponibles desde este cliente.1.
Compositor: Esto permite modificar y agregar los paquetes que queramos
incluso permitiéndonos generar paquetes nuestros, configurarlos en el
composer son e incluirlos en nuestra aplicación con un composer update. Tal
es el uso y los beneficios de Composer que Laravel utiliza muchos paquetes
de otros frameworks como Symfony (Artisan es una extensión de su consola)
entre otros..
Migraciones: Lo que incorpora Laravel es la posibilidad de llevar un control
de versiones también de nuestra base de datos. Esto, combinado con un
sistema de seeding nos permite tener nuestra aplicación descargada y
funcionando en unos pocos comandos.
Recursos: se incorpora el concepto de resource permitiéndonos programar
nuestros controladores como si fueran un API Rest y que sean consumidos
de la misma forma. Es decir que para agregar un elemento hacemos
un POST /resource, para obtener un listado un GET /resource, para obtener
un elemento GET /resource/{id}, etc. Esto nos permite liberar y consumir
nuestra aplicación como un API sin tener que modificar nada, y dándonos la
posibilidad de integrarla y de que sea integrada por otros sistemas.
ORM: Object-Relational Mapping para nuestra base de datos. Nos permite
interactuar con nuestra base de datos como si cada tabla fuera un Modelo,
respetando más fielmente la división MVC.
25
5.1.4.2. ARQUITECTURA LARAVEL
5.1.4.2.1. CICLO DE VIDA DE UNA SOLICITUD
El punto de entrada de todas las peticiones a una aplicación Laravel es el
archivo public/index.php. Todas las peticiones son dirigidas a este archivo por la
configuración del servidor web (Apache / Nginx). El archivo index.php no contiene
mucho código. Más bien, es un simple punto de entrada para cargar el resto del
framework.1
El archivo index.php carga la definición del autoloader generado por Composer y
luego retorna una instancia de la aplicación de Laravel desde el
script bootstrap/app.php.
HTTP / Console Kernels
A continuación, la petición de entrada es enviada al núcleo HTTP o bien al núcleo
de consola, dependiendo del tipo que sea dicha petición de entrada a la aplicación.
Estos dos núcleos son el lugar central por el pasan todas las peticiones.
El núcleo HTTP extiende de la clase Illuminate\Foundation\Http\Kernel, que define
un array de configuraciones de arranque que serán lanzadas antes de que la
petición sea ejecutada.
Service Providers
Los service providers son la clave del arranque de una aplicación Laravel. Se crea
una instancia de la aplicación, se registran los service providers y se interpreta la
solicitud con la aplicación ya arrancada.
De forma predeterminada, el AppServiceProvider está casi vacío. Este provider es
un buen lugar para añadir los elementos de arranque de la aplicación e incluso
___________________________
1Tomado de: http://laraveles.com/docs/5.0/lifecycle
26
bindings del service container. Por supuesto, para aplicaciones grandes, puedes
crear varios service providers más específicos.
5.1.4.2.2. ESTRUCTURA DE LA APLICACIÓN
La estructura por defecto de la aplicación Laravel está destinada a proporcionar un
buen punto de partida tanto para aplicaciones grandes como para aplicaciones
pequeñas. Aun así, se puede de organizar la aplicación. Laravel no impone casi
ninguna restricción respecto a donde se encuentra una clase en el proyecto,
siempre y cuando Composer sea consciente de ella para poder cargarla al arrancar
de la aplicación.
El directorio raíz
El directorio raíz de una nueva instalación nueva de Laravel contiene una serie de
directorios:
El directorio app, contiene el código base de tu aplicación.
La directorio bootstrap contiene unos archivos que arrancar el marco de trabajo y
configuran carga automática, así como una carpeta de caché que contiene algunos
archivos de marco para la optimización del rendimiento de arranque genera.
El directorio config, como su nombre indica, contiene todos los archivos de
configuración de tu aplicación.
El directorio resources contiene sus puntos de vista , los activos brutos ( LESS,
SASS , CoffeeScript ) , y los archivos de localización .
El directorio storage contiene plantillas compiladas de Blade, sesiones basadas en
archivos, archivos de caché y otros archivos generados por el framework.
27
El directorio tests contiene pruebas de sus pruebas automatizadas. Un ejemplo es
el de PHPUnit fuera de la caja.
El directorio vendor contiene sus dependencias del compositor.
El directorio de la aplicación
El directorio app viene con una variedad de directorios adicionales, tales
como Console, Http, y Providers. Piensa en los directoriosConsole y Http como
proveedores de un API al "core" de la aplicación. El protocolo HTTP y CLI son
mecanismos (pasarelas) para interactuar con tu aplicación, pero en realidad no
contienen lógica de la aplicación. El directorio Console contiene todos tus
comandos de Artisan, mientras el directorio Http contiene tus controladores, filtros y
peticiones.
5.1.4.2.3. SERVICE PROVIDERS (PROVEEDORES DE SERVICIO)
Los proveedores de servicios son el centro de toda la configuración de arranque de
Laravel. Tu propia aplicación, al igual que todos los servicios del núcleo de Laravel,
también tiene su configuración de arranque mediante proveedores de servicios.
Writing Service Providers
Todos los proveedores de servicios extienden de la
clase Illuminate\Support\ServiceProvider. Esta clase abstracta requiere que al
menos definas el método register en tu proveedor. Dentro del método register, sólo
se debe obligar a las cosas en el contenedor de servicios
Registrar proveedores
Todos los proveedores están registrados en el archivo de
configuración config/app.php. Este archivo contiene un array de proveedores del
28
cual puedes obtener un listado de nombres de tus proveedores de servicios. Por
defecto, este array también incluye un conjunto de proveedores de servicios del
núcleo de Laravel. Estos proveedores inicializan los componentes del núcleo de
Laravel, tales como el proveedor de correos, colas, caché y otros.
Proveedores diferidos
Laravel compila y almacena una lista de todos los servicios ofrecidos por
proveedores de servicios diferidos, junto al nombre de su clase proveedora del
servicio. Entonces, sólo cuando se intenta resolver alguno de estos servicios,
Laravel carga el proveedor de servicio.
5.1.4.2.4. SERVICE CONTAINER
El contenedor de servicios laravel es una poderosa herramienta para la gestión de
las dependencias de la clase y la realización de la inyección de dependencia. La
inyección de dependencia es una frase de fantasía que en esencia significa esto:
dependencias de clase se " inyecta" en la clase a través del constructor o , en
algunos casos , los métodos de "ajuste " .
Binding (enlazar)
Casi todos los enlaces de container de servicio se registrarán dentro de los
proveedores de servicios; Sin embargo, no hay necesidad de obligar a las clases en
el recipiente si no dependen de ninguna interfaces. El contenedor no necesita ser
instruido cómo construir estos objetos, ya que se puede resolver de forma
automática este tipo de objetos "concretas" que utilizan los servicios de reflexión de
PHP.
Binding A Singleton
29
El método Singleton se une a una clase o interfaz en el container que sólo debe ser
resuelto de una vez, y luego esa misma instancia será devuelto en llamadas
posteriores en el container
Binding Instances
Podrías enlazar una instancia de un objeto existente al container utilizando el
método instance. Se retornará esa misma instancia en llamadas posteriores al
container
Enlazando (binding) interfaces a implementaciones
Una de las características del service container es su capacidad para enlazar una
interfaz a una implementación determinada.
Binding contextual
En ocasiones puedes tener dos clases que utilizan la misma interfaz, pero quieres
inyectar implementaciones diferentes a cada clase. Por ejemplo, cuando nuestro
sistema recibe un nuevo Pedido, podemos querer lanzar un evento vía PubNub en
lugar de Pusher. Laravel provee una simple y fluida interfaz para definir este
comportamiento
5.1.4.2.5. CONTRATOS (CONTRACTS)
Los Contracts de Laravel son un conjunto de interfaces que definen los principales
servicios proporcionados por el framework. Por ejemplo,
a Illuminate\Contracts\Queue\ define los métodos necesarios para poner en cola
trabajos, mientras que Illuminate\Contracts\Mail\Mailer contract define los métodos
necesarios para el envío de correo electrónico.
Cada Contract tiene una implementación correspondiente proporcionada por el
framework. Por ejemplo, laravel proporciona una implementación de cola con una
30
variedad de conductores, y una implementación de cliente de correo que es
alimentado por SwiftMailer .
Todos los Contract de Laravel se encuentran en su propio repositorio de GitHub.
Esto proporciona un punto de referencia rápida para todos los contratos disponibles,
así como un paquete único, disociada que pueden ser utilizados por los
desarrolladores de paquetes.
5.1.4.2.6. FACADE
Fachadas proporcionan una interfaz de "estática" a las clases que están disponibles
en la aplicación del contenedor de servicios . Laravel incluye muchas fachadas, las
"fachadas" de laravel sirven Como un "Proxy estático" para clases subyacentes en
el contenedor de servicios, proporcionando el beneficio de una sintaxis concisa y
expresiva, Manteniendo mayor estabilidad y flexibilidad que los métodos
tradicionales estáticos.
En el contexto de una aplicación Laravel, una facade es una clase que provee
acceso a un objecto desde el contenedor. El mecanismo que hace que esto funcione
es la clase Facade. fachadas de laravel , y cualquier fachadas personalizadas que
cree , se extenderán a la clase
5.1.5. CARACTERÍSTICAS DE LARAVEL
Modularidad: Laravel se ha construido utilizando más de 20 librerías
diferentes fuertemente integradas con el gestor de dependencias Composer
Testeabilidad: construido para facilitar el testeo, Laravel tiene con varios
asistentes (helpers) que ayudan a visitar las rutas de testeo, navegando por
el HTML resultante para asegurar que los métodos que se llaman desde las
diferentes clases sean correctos, e incluso a impersonar a los usuarios.
31
Enrutamiento (routing): Laravel proporciona una extrema flexibilidad en la
definición de las rutas de la aplicación. Inspirado en la filosofía de los micro-
frameworks Sinatra y Silex. Todavía más, es posible adjuntar funciones de
filtro que se ejecuten en rutas específicas.
Gestor de configuración: frecuentemente la aplicación se ejecutará en
diferentes entornos, esto quiere decir que tanto la base de datos como
credenciales o dominios serán diferentes si se ejecutan el local en el entorno
de test o en los servidores de producción. Laravel nos permite definir
configuraciones separadas para cada uno de los entornos.
Confeccionador de consultas y ORM (Object Relational Mapper): cuando
se instala Laravel viene con un constructor de consultas, este nos permite
lanzar consultas a la base de datos con una sintaxis PHP de métodos
enlazados, en lugar de tener que escribir la SQL completa. Además
proporciona un ORM y una implementación de Registro Activo
(ActiveRecord) llamado Eloquent, que permite definir modelos
interconectados. Estos componentes son compatibles con bases de datos
tales como PostgreSQL, SQLite, MySql, MS SQL Server.
Confeccionador esquema, migraciones y repoblaciones: inspirado por la
filosofía Rails, estas características permiten definir un esquema de base de
datos dentro de PHP y mantener un registro de los cambios para así ayudar
en la migración de base de datos. Las repoblaciones (Seeding) permiten
poblar las tablas seleccionadas de una base de datos una vez realizada la
migración para de esta forma rellenar con datos las tablas.1
Motor de plantillas: Laravel viene con Blade, un lenguaje ligero de plantillas
con el cual se pueden crear diseños anidados con bloques predefinidos en el
que el contenido se inserta dinámicamente. Además Blade guarda en caché
los archivos generados.
Email: con la clase Mail que es un derivado de la librería SwiftMailer, Laravel
proporciona una forma muy sencilla de enviar e-mails, con contenido HTML
y adjuntos.
___________________________
1Tomado de: http://www.bcnbit.com/laravel-4-resumen-para-principiantes-parte-i/
32
Autenticación: Laravel viene con las herramientas para crear en toda web
un formulario de registro, autenticación e incluso envio de contraseñas a
usuarios que no la recuerden.
Redis: es un sistema de almacenamiento clave-valor en memoria que tiene
fama de ser extremadamente rápido.
Colas: Laravel se integra con diversos servicios de colas, tales como
Amazon SQS o IronMQ, para permitir el aplazamiento de tareas que son muy
intensivas en recursos, así por ejemplo podemos enviar una gran cantidad
de e-mails ejecutando esta tarea en segundo plano en lugar de hacer que el
usuario espere delante de la pantalla.
6. DISEÑO METODOLOGICO
6.1. Conocimiento Global De La Empresa
6.1.1. Reseña Histórica
Fundada en el año 2004, Transportes Zambrano con más de 10 años de combinada
experiencia de nivel profesional para transportar carga y pasajeros y en los últimos
5 años también con el alquiler de vehículos prestando un servicio bueno a sus
clientes. La empresa ofrece los servicios de un equipo de conductores y mecánicos
expertos, además de los funcionarios administrativos personas con experiencia y
compromiso de ofrecer el mejor servicio a sus clientes.
Desde su creación la empresa ha venido mejorando poco a poco sus procesos y
servicios, cuenta entre sus clientes a empresas de varios sectores que avalan su
calidad y cumplimiento. Aplican sus conocimientos para ofrecer un servicio que
responde a necesidades específicas. Además de especializarse en los sectores
empresariales ya que está avalada por el ministerio de transporte.
Estructura organizativa
33
Tomado organigrama Transportes Zambrano
6.1.2. Objetivos de la Organización
Objetivos de TRANSPORTES ZAMBRANO
Cumplir las responsabilidades individuales para fortalecer la imagen
institucional.
Desarrollar con efectividad las tareas encomendadas
Emprender actuaciones bajo criterios de discerniendo ético en la gestión
institucional
Se entregan resultados de calidad en base a la planificación institucional
Desarrollar con efectividad las tareas encomendadas
Demostrar vocación de servicio y sentido de pertenencia frente a la
entidad, ejerciendo el liderazgo necesario para dar cumplimiento a los
objetivos de la organización, respetando el medio ambiente.
Aplicar la cultura de calidad en el servicio, ofreciendo una amplia
cobertura, que permita responder efectivamente frente a las exigencias
del mercado de un mundo globalizado.
Gerente
Subgerente
cordinador mantenimiento
cordinador alquiler
cordinador de transporte
conductores
Tesoreria Contaduria Secretaria
34
Cooperación permanente y continua en el desarrollo en los procesos de la
organización y en las relaciones interpersonales con los clientes y
usuarios.
6.1.3. Definición de la Actividad de la Empresa
TRANSPORTES ZAMBRANO es una empresa dedicada al transporte de
mercancías y personas, se dedica a ofrecer a sus clientes los servicios de transporte
de pasajeros, carga y alquiler de vehículos de acuerdo con las necesidades
específicas de cada uno de ellos, también tiene proyectado ampliar más su parque
automotor para ofrecer un mejor servicio. Su actividad principal es el transporte de
personas, de ahí se desprenden otras actividades relacionadas como el transporte
de mercancía y el alquiler de vehículos.
6.1.4. Misión
TRANSPORTE FLUVIAL ZAMBRANO & H S.A.S, es una empresa de Transporte
Fluvial y Terrestre de personal, que cuenta con un equipo humano de óptima calidad
que trabaja siempre pensando en la satisfacción de nuestros clientes, ofrecemos
los mejores servicios buscando siempre la excelencia para llegar a un nivel de
servicio que nos permite alcanzar un desarrollo integral como persona y como
empresa.
Participamos activamente en el desarrollo socio-económico de la región,
convirtiéndonos en aliados estratégicos de nuestros clientes, proporcionando
soluciones a medida de sus necesidades.
Así garantizamos un desempeño industrial y comercial exitoso en medio de una
competencia cada vez más fuerte.
35
6.1.5. Evaluación de la Misión
Clientes “…trabaja siempre pensando en la satisfacción de nuestros
clientes” – puede ser cualquier cliente no limite su población
objetivo
Producto o
servicio
“…proporcionando soluciones a medida de sus necesidades”
– Soluciones tecnológicas de acuerdo al negocio del cliente
Mercado Cualquier empresa o persona que quiera una solución
tecnológica para su negocio.
Tecnología No aplica
Interés por la
supervivencia,
crecimiento y
rentabilidad
“…buscando siempre la excelencia para llegar a un nivel de
servicio que nos permite alcanzar un desarrollo integral como
persona y como empresa.” se evidencia el interés de
sobrevivir al mercado cambiante y globalizado, también el
interés por crecer teniendo rentabilidad.
Filosofía “…ofrecemos los mejores servicios buscando siempre la
excelencia” – Apoyar a sus clientes a la consecución de los
objetivos de negocio propios ofreciendo calidad en el servicio.
Concepto de sí
misma
No Aplica
Interés por la
imagen pública
“Participamos activamente en el desarrollo socio-económico
de la región, convirtiéndonos en aliados estratégicos de
nuestros clientes” – Preocupación por la región donde trabaja
y la imagen ante sus clientes
Interés por el
empleado
No Aplica
6.1.6. Matriz DOFA
Esta sección tiene como objetivo conocer cuáles son las fortalezas y debilidades
dentro de la empresa, identificar que amenazas y oportunidades que presentan
en su contexto. Con esto obtendremos una claridad de las necesidades actuales
en la empresa
36
Herramientas utilizadas desactualizadas Amplia experiencia en el sector
Demoras en la atención
Cumplimiento de las necesidades del
cliente
Falta de seguimiento a los procesos Personal idóneo
Reconocimiento de los clientes
Oportunidades Debilidades Fortalezas
Conocer mucho más los
requerimientos del cliente
* Incentivar la generación de evaluación
de desempeño por parte del cliente y
documentar los resultados
* Hacer seguimiento de procesos en todos
los niveles
Estar actualizados con las herramientas
usadas
* Identificar futuros requerimientos del
cliente con anterioridad para realizar
propuestas de innovación
Hacer seguimiento de cada cliente
mediante herramientas actualizadas
Aprovechar las herramientas
tecnologías
Crecimiento de la población y
empresas en el sector
Atención personalizada al
cliente
Amenazas
Evaluación de desempeño por
parte del cliente
* Hacer seguimiento de procesos para
evitar demoras
* Provocar participación activa en los
espacios de socialización y capacitación
de los empleados en la retroalimentación
de la empresa donde se propongan ideas
de mejora
* generar estrategias de comercialización
para competir en el mercado
* tener en cuenta con anterioridad los
cambios en el mercado
Hacer evaluación y proyección de costos
con más anterioridad
Costo de la gasolina
Competencia de nuevas
empresas grandes y pequeñas
Situación de orden público de la
zona
7. DESARROLLO DE SOFTWARE
7.1. FASES DEL PROYECTO
A continuación se indican y describen cada uno de las fases a seguir en el proyecto.
Esta lista constituye la configuración de RUP desde la perspectiva de artefactos, y
que utilizaremos para este proyecto.
37
Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo
e incremental), todos los artefactos1 son objeto de modificaciones a lo largo del
proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una
versión definitiva y completa de cada uno de ellos.
7.1.1. Fase de Inicio
En esta fase se desarrolló el Análisis de requerimientos: se estudian los requisitos
del sistema y se desarrollan, detallando los casos generales y los especiales, los
cuales se evaluarán dentro de la oficina de Orion Technologies para posibles
ajustes. Esta etapa contempla, por supuesto, Casos de uso del Sistema,
Secuencias y Colaboraciones, se hizo un refinamiento del Plan de Desarrollo del
Proyecto, la aceptación del cliente / usuario del artefacto Visión y el Plan de
Desarrollo marcaron el final de esta fase.
7.1.2. Modelado del Sistema
El modelado del negocio se basa en los diagramas principales de modelo de casos
de uso del negocio para cada cliente del Sistema.
La empresa interactúa con distintos elementos externos, entre los que se identifican
el Cliente (persona entidad encargada de hacer los pedidos), el vendedor (persona
encargada de las ventas), el proveedor (persona o entidad que provee los insumos)
y el técnico (se encarga de ensamblar y reparar equipos).
7.1.3. Escenarios Gerente
1 Se define como artefacto un producto de una iteración en el ciclo de desarrollo en la metodología RUP:
desde un código software hasta documentos técnicos.
38
Cliente Secretaria
Agregar vehículo
39
Coordinador
Coordinador mantenimiento
Conductor de mantenimiento
Mecánico Supervisor Taller
40
7.1.4. Fase de Elaboración
En esta fase se analizan los requisitos y se desarrolla un prototipo de arquitectura
(incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase,
todos los casos de uso correspondientes a requisitos que serán implementados en
la primera versión de la fase de Construcción deben estar analizados y diseñados
(en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la
arquitectura del sistema marca el final de esta fase..
7.1.4.1. Actores Del Sistema
Un actor es una persona, sistema o dispositivo que interactúa con el sistema,
iniciando, recibiendo los resultados o participando en algunas de las acciones de un
caso de uso. Por lo general representa un rol. Los actores utilizados para las
especificaciones definidas a partir de los siguientes numerales son:
PERFIL 1 Gerente
Descripción Persona previamente seleccionada, encargada de:
Ingresar nuevos conductores al sistema
Agregar nuevo vehículo al stock
Consultar las facturas de arreglos de vehículos.
Hacer consultas de información variada.
Gerencia de la empresa
Comentarios Ninguno
41
Actor perfil 1
Actor perfil 2
Actor perfil 3
PERFIL 2 Secretaria
Descripción Persona previamente seleccionada, encargada de:
Ingresar solicitud de alquiler
Recibir solicitudes de alquiler.
Elaborar la facturas de venta
Responder emails.
Atender solicitudes de los clientes
Consultar información l acerca de los insumos en el
inventario
Ingresar clientes nuevos
Comentarios Ninguno
PERFIL 3 Cliente
Descripción Persona, encargada de:
Solicitar productos al vendedor
Hacer el pago de sus pedidos.
Comentarios Ninguno
PERFIL 3 Coordinador
Descripción Persona previamente seleccionada, encargada de:
Coordinar las labores de su área
Entregar vehículos
Recibir vehículos
Comentarios Ninguno
PERFIL 3 Mecánico
42
7.1.4.2. Especificaciones De Casos De Uso
Las especificaciones de casos de uso están divididas según el subsistema al que
pertenezcan:
UC-01 Solicitar alquiler
Descripción El sistema recibe el requerimiento del alquiler por parte del cliente.
Precondición ninguna.
Secuencia Normal
Paso Acción 1 El cliente hace la solicitud del alquiler.
2 El cliente del sistema entra a la opción de menú: crear nueva solicitud de alquiler
3 El cliente entra toda la información correspondiente a la solicitud.
Descripción Persona o entidad, previamente seleccionada encargada de:
Reparar vehículos
Prevenir daños
Registrar daños
Registrar reparación
Responder por garantías.
Dar asesorías técnicas
Comentarios Ninguno
PERFIL 3 Supervisor taller
Descripción Persona o entidad, previamente seleccionada encargada de:
Supervisar ingreso de vehículos
Supervisar salida de vehículos
Agregar empresas
Comentarios Ninguno
43
4 Termina el proceso de mostrarle al cliente la Creación exitosa de la solicitud.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
4 El vehículo no está disponible.
3 En caso de que falte información al ingreso del, el Sistema informará al Cliente que falta ingresar un Campo.
Rendimiento Paso Tiempo
4 30 segundos
Comentarios ninguna
UC-02 Consultar solicitud de alquiler
Descripción El sistema la consulta.
Precondición El solicitante es un Actor PERFIL1 el cual esta previamente validado en el sistema.
Secuencia Normal
Paso Acción 1 El sistema verifica el Perfil del Solicitante. 2 El usuario del sistema entra a la opción de menú: consultar 3 Termina el proceso de mostrarle al usuario la información
Pos condición El sistema queda listo para ingresar nueva búsqueda Excepciones paso Acción
3 Información no disponible.
Rendimiento Paso Corta De Tiempo
4 2 segundos
Comentarios ninguna
UC-03 Agendar vehículo
Descripción El sistema agenda un vehículo Precondición Solicitud de alquiler
Secuencia Normal
Paso Acción 1 El usuario del sistema ingresa al módulo de agenda vehículo .
2 El usuario del sistema entra a la opción de menú: crear nueva solicitud de alquiler
3 El sistema muestra al usuario la Creación exitosa.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
1 Solicitud previa de alquiler
Rendimiento Paso Tiempo
4 30 segundos
Comentarios ninguna
44
UC-04 Facturar servicio
Descripción El sistema realiza la factura por el pago de un servicio.
Precondición Solicitud de alquiler.
Secuencia Normal
Paso Acción 1 El usuario del sistema ingresa al módulo de facturación.
2 El usuario del sistema ingresa los datos solicitados
3 Termina el proceso de mostrarle al usuario la Creación exitosa de la factura.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
1 Solicitud de alquiler.
Rendimiento Paso Tiempo
4 30 segundos
Comentarios ninguna
UC-05 Lista de chequeo recepción de vehículo
Descripción El usuario ingresa el estado de un vehículo que llega.
Precondición ninguna
Secuencia Normal
Paso Acción 1 El usuario del sistema ingresa al módulo de ingresar vehículo .
2 El usuario del sistema ingresa los datos solicitados del vehículo
3 Termina el proceso de mostrarle al usuario el ingreso exitoso del vehículo.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
1 Vehículo no registrado .
Rendimiento Paso Tiempo
4 15 minutos
Comentarios ninguna
UC-06 Consultar daños de vehículo
Descripción El usuario consulta los daños registrados de un vehículo Precondición El Vehículo debe haber ingresado previamente
Paso Acción
45
Secuencia Normal
1 El usuario del sistema ingresa al módulo de buscar vehículo .
2 El usuario del sistema ingresa los datos solicitados del vehículo
3 Termina el proceso de mostrarle al usuario la información correspondiente al vehículo buscado.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
1 Vehículo no registrado .
Rendimiento Paso Tiempo
4 15 segundos
Comentarios ninguna
UC-07 Registrar daños de vehículo
Descripción El usuario ingresa los daños de un vehículo Precondición El Vehículo debe haber ingresado previamente
Secuencia Normal
Paso Acción 1 El usuario del sistema ingresa al módulo de buscar vehículo .
2 El usuario del sistema ingresa los datos solicitados del vehículo
3 Termina el proceso con el registro de la información correspondiente al vehículo buscado.
Pos condición El sistema queda listo para ingresar nueva solicitud Excepciones paso Acción
1 Vehículo no registrado .
Rendimiento Paso Tiempo
4 15 segundos
Comentarios ninguna
8. MODELOS DE ANALISIS Y DISEÑO
A continuación se presentan los modelos definidos en RUP como modelo de datos
y modelo de análisis / diseño. Constará de un diagrama de clases en el que se
muestran tan sólo las clases generadas a partir de los casos de uso incorporados a
la aplicación hasta la segunda iteración de la fase de construcción, y de un modelo
de datos (modelo relacional) donde se muestran las entidades que participan en las
relaciones definidas en él.
46
8.1. Clases conceptuales
Diagrama de Clases
Modelo de dominio
En este modelo de clases podemos ver los objetos del dominio del problema, o sea
objetos que tienen una equivalentes al área de la aplicación. Así es como el usuario
debe identificar los todos los conceptos, las relaciones entre todas las entidades
comprendidas en el ámbito del dominio del problema, y podemos identificar los
atributos.
Es importante aclarar que aquí no se trata de un conjunto que corresponden a
clases software, u objetos software con compromisos.
Diagrama realizado con ArgoUML
47
8.2. Modelo Entidad – Relación
48
8.2.1. Diccionario de datos
Alquiler
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idalquiler INT(11) ✔ ✔ ✔
fechainicio DATETIME ✔
fechafin DATETIME ✔
costo FLOAT ✔
estado TINYINT(4) ✔
clientes_idclientes INT(11) ✔
Aseguradora
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idaseguradora INT(11) ✔ ✔ ✔
aseguradora VARCHAR(45) NULL
Checklist
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
vehiculos_alquiler_idvehiculosalquiler
INT ✔
item_checklist_iditem INT ✔
calificacion TINYINT
fecha_calificacion DATETIME
idchk INT ✔ ✔
observacion VARCHAR(45)
49
Clientes
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idclientes INT(11) ✔ ✔ ✔
nombres VARCHAR(45) ✔
apellidos VARCHAR(45) ✔
documento INT(11) ✔
telefono VARCHAR(45) ✔
correo VARCHAR(45) NULL
cargo VARCHAR(45) ✔
empresas_idempresa INT(11) ✔
usuarios_Idusuario INT(11) ✔
detalle_mantenimiento
Column name DataType Primary
Key Not Null
Unique
Index
Binary Column
Unsigned Data
Auto Incremental
Default
iddetallemantenimiento INT(11) ✔ ✔ ✔
costo INT(11) ✔
Id_mecanico INT(11) ✔
mantenimiento_idmantenimiento
INT(11) ✔
mecanicos_idmecanico INT(11) ✔
tipo_mantenimiento_idtipo_mantenimiento
INT ✔
detalle_partes
Column name DataType Primary Key
Not Null
Unique
Index
Binary Colum
n
Unsigned Data
Auto Incremental
Default
detalle_mantenimiento_iddetallemantenimiento
INT(11) ✔ ✔
partes_vehiculo_idPartes_Vehiculo
INT(11) ✔ ✔
observacion TEXT ✔
imagen_antes VARCHAR(100)
correctivo VARCHAR(100)
imagen_despues VARCHAR(100)
50
empleados
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idempleado INT(11) ✔ ✔ ✔
nombres VARCHAR(45) ✔
apellidos VARCHAR(45) ✔
documento INT(11) ✔
telefono INT(11) ✔
fecha_nacimiento DATE ✔
correo VARCHAR(45) ✔
licencia VARCHAR(45) ✔
contacto_emergencia VARCHAR(45) ✔
Estado_civil_idEstado_civil INT(11) ✔
tiposangre INT(11) ✔
tipolicencia VARCHAR(4) ✔
eps_ideps INT(11) ✔
empresas
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idempresa INT(11) ✔ ✔ ✔
razonsocial VARCHAR(45) ✔
NIT VARCHAR(45) ✔
representante VARCHAR(45) ✔
telefono VARCHAR(45) ✔
correo VARCHAR(45) ✔
eps
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
ideps INT(11) ✔ ✔ ✔
eps VARCHAR(45) ✔
especialidad
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
51
idEspecialidad INT(11) ✔ ✔ ✔
Especialidad VARCHAR(45) NULL
estado
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idestado INT(11) ✔ ✔ ✔
estado VARCHAR(45) ✔
mantenimiento
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idmantenimiento INT(11) ✔ ✔ ✔
Fecha_ingreso DATE ✔
Fecha_entrega DATE ✔
vehiculos_idvehiculo INT(11) ✔
taller_idtaller INT(11) ✔
estado INT
seguros
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idSeguros INT(11) ✔ ✔ ✔
Fecha_expedicion DATETIME ✔
Fecha_caducidad DATETIME ✔
Radicado VARCHAR(45) ✔
aseguradora_idaseguradora INT(11) ✔
tipo_seguro_idtipo_seguro INT(11) ✔
vehiculos_idvehiculo INT(11) ✔
marca
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idmarca INT(11) ✔ ✔ ✔
marca VARCHAR(45) ✔
mecanicos
52
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idmecanico INT(11) ✔ ✔ ✔
nombre VARCHAR(45) ✔
apellido VARCHAR(45) NULL
migrations
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
migration VARCHAR(255) ✔
batch INT(11) ✔
municipio
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idmunicipio INT(11) ✔ ✔ ✔
municipio VARCHAR(45) ✔
partes_vehiculo
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idpartes_vehiculo INT(11) ✔ ✔ ✔
nombre_parte VARCHAR(60) ✔
periodicidad_mantenimiento INT
rol
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idrol INT(11) ✔ ✔ ✔
rol VARCHAR(45) ✔
sobrecosto
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
vehiculos_alquiler_idvehiculosalquiler INT ✔ ✔
monto INT ✔
tipo_sobrecosto_idtipo_sobrecosto INT ✔ ✔
solicitud
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idsolicitud INT(11) ✔ ✔ ✔
fechainicio DATE ✔
fechafinal DATE ✔
53
alquiler_idalquiler INT(11) ✔
tiene_conductor TINYINT ✔
modoentrega TINYINT ✔
modorecepcion TINYINT ✔
taller
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idtaller INT(11) ✔ ✔ ✔
nombre VARCHAR(45) NULL
telefono VARCHAR(45) ✔
direccion VARCHAR(45) ✔
NIT VARCHAR(45) ✔
representantelegal VARCHAR(45) ✔
especialidad_idEspecialidad INT(11) ✔
municipio_idmunicipio INT(11) ✔
tipo_seguro
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idtipo_seguro INT(11) ✔ ✔ ✔
tipo_seguro VARCHAR(45) NULL
tipo_sobrecosto
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idtipo_sobrecosto INT ✔ ✔
tipo_sobrecostocol VARCHAR(45) ✔
tipovehiculo
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idtipo INT(11) ✔ ✔ ✔
tipovehiculo VARCHAR(45) NULL
54
tipovehiculo_por_solicitud
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
tipovehiculo_idtipo INT(11) ✔ ✔
solicitud_idsolicitud INT(11) ✔ ✔
numero VARCHAR(45) ✔
usuarios
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
Idusuario INT(11) ✔ ✔ ✔
username VARCHAR(32) ✔
password VARCHAR(64) ✔
email VARCHAR(320) ✔
rol_idrol INT(11) ✔
vehiculos
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
idvehiculo INT(11) ✔ ✔ ✔
matricula VARCHAR(45) ✔
modelo VARCHAR(45) ✔
capacidad VARCHAR(45) ✔
cilindraje VARCHAR(45) ✔
chasis VARCHAR(45) ✔
costocomercial VARCHAR(9) ✔
imagen VARCHAR(45) ✔
tipo_vehiculo_idtipo INT(11) ✔
marca_idmarca INT(11) ✔
color_idcolor INT(11) ✔
consumo VARCHAR(45)
vehiculos_alquiler
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
55
vehiculos_idvehiculo INT(11)
alquiler_idalquiler INT(11) ✔
modoentrega TINYINT
modorecepcion TINYINT
empleados_idempleado INT(11)
tiene_conductor TINYINT ✔
kilometrajeinicial FLOAT ✔
kilometrajefinal FLOAT
idvehiculosalquiler INT ✔ ✔ ✔
vehiculos_estado
Column name DataType Primary
Key Not Null
Unique Index
Binary Column
Unsigned Data
Auto Incremental
Default
vehiculos_idvehiculo INT(11) ✔
estado_idestado INT(11) ✔
fecha DATE ✔
idve VARCHAR(45) ✔ ✔
56
8.3. Modelo de despliegue
Este es un diagrama estructurado que muestra la arquitectura del sistema desde el
punto de vista de la distribución de los artefactos del software en los destinos de
despliegue.
El diagrama muestra la configuración de nodos de procesamiento en tiempo de
ejecución y las instancias de componentes y objetos que se encuentran dentro de
esos nodos. Los componentes representan manifestaciones de ejecución de
unidades de código.
Diagrama realizado con ArgoUML
57
8.4. Modelo vista controlador
Ese modelo se compone de tres componentes que son: el modelo, la vista y el
controlador, es decir, por un lado define elementos para la representación de la
información, y por otro lado para la interacción del usuario, esto permite separar
los componentes del software dependieno de su trabajo que realizan.
El Modelo: En esta capa se trabaja con los datos, y contiene las peticiones para
acceder y actualizar el estado de la información. Los datos están guardados en
la base de datos, entonces en esta capa tendremos todas las funciones que
accederán a las tablas y realizan las ordenes selects, updates, inserts, etc.
La Vista: es la representacion visual de los datos, interpreta el codigo de la
aplicación en las interfaces de usuario En la vista generalmente trabajamos con
los datos, sin embargo, no se realiza un acceso directo a éstos. Las vistas
requerirán los datos a los modelos y ellas se creará la salida, tal como la
aplicación requiera.
El Controlador: Esta es la capa que sirve de conexión entre las vistas y los
modelos, respondiendo a los eventos que puedan solicitarse para generar las
necesidades de nuestra aplicación. Desde esta capa no se manipulan
directamente datos, ni se muestra ningún tipo de salida, sino lo que hace es
servir de enlace entre los modelos y las vistas para implementar las diversas
necesidades del desarrollo.
58
Diagrama realizado con ArgoUML
8.5. Fase de construcción
Durante la fase de construcción se terminan de analizar y diseñar todos los casos
de uso, refinando el Modelo de Análisis / Diseño. Se codifica el sistema detallado
previamente, en base al análisis y diseño realizado en las fases anteriores, esta
etapa es la más importante ya que se creará la base de datos y se desarrollarán los
diferentes módulos para el Sistema, el producto se construye en base a 2
iteraciones, cada una produciendo una versión a la cual se le aplican las pruebas y
se valida con el cliente / usuario. Se comienza la elaboración de material de apoyo
al usuario.
59
8.5.1. Interfaces
A continuación se presentan los prototipos de las interfaces gráficas de usuario
diseñadas para demostrar la funcionalidad de la aplicación. Cabe Citar que se
presentan únicamente los prototipos de interfaces de usuario al cliente además
incluyen funcionalidades de una futura segunda fase de construcción del sistema.
Los modelos y diseños de las interfaces prototipo y finales son propiedad de la
empresa ORION TECNOLOGIES.
8.5.1.1. Interfaz de ingreso de usuarios al sistema
60
8.5.1.2. Interfaz gestionar conductor
8.5.1.3. Interfaz gestionar vehículo
61
8.5.1.4. Interfaz ver facturas
8.5.1.5. Interfaz registrar daño de vehículo
62
8.5.1.6. Interfaz solicitud de alquiler
8.5.1.7. Interfaz agendar vehículo
63
8.5.1.8. Interfaz ingresar cliente
8.5.1.9. Interfaz ingresar vehículo a taller
64
8.5.1.10. Interfaz entregar vehículo
8.5.1.11. Interfaz registrar arreglo de vehículo
65
8.5.2. Interfaces definitivas
Las siguientes interfaces corresponden a los diseños finales aprobados por el
cliente, este diseño posee una funcionalidad mejorada significativamente en cuanto
a su usabilidad. Cabe anotar que por pedido del cliente para esta fase no se
contempla el trabajo con roles para cada actividad, por lo tanto en esta primera fase
todo el proceso de alquiler lo realiza un solo usuario.
8.5.2.1. Interfaz de ingreso al sistema
Mediante esta interfaz el usuario puede ingresar al sistema escribiendo su email y
password y presionando el botón login. El usuario puede dar clic en el link olvidaste
tu password, para ir a la interfaz de recuperación de clave.
66
8.5.2.2. Interfaz para cambiar el password
En esta interfaz el usuario ingresa su dirección de correo y presiona el botón de
enviar contraseña al correo. El sistema enviara un correo con el link de recuperación
de password.
Email de recuperación de password
El sistema enviará un correo con el link de recuperación de password.
67
8.5.2.3. Interfaz de cambio de password
Interfaz que ve el usuario cuando ingresa al link que es enviado al correo electrónico
para recuperación de contraseña.
8.5.2.4. Interfaz de inicio del sistema
En esta nueva interfaz se presenta un calendario el cual muestra los agendamientos
de vehículos que están activos y pendientes, y por lo tanto las fechas de
disponibilidad para hacer un nuevo agendamiento, también se puede navegar por
cualquier fecha para verificar la disponibilidad.
68
8.5.2.5. Interfaz formulario de ingreso de solicitud
Al dar clic en una fecha disponible el sistema desplegara un formulario para realizar
una nueva solicitud de agendamiento de un vehículo. El usuario ingresa los datos
referentes a dicha solicitud como son: fecha de solicitud, fecha de entrega, nombre
del cliente, tipo de vehículo solicitado y demás. También hay un botón donde se
puede ver la factura generada para dicha solicitud. Al dar clic en guardar solicitud la
solicitud quedara generada la factura.
69
8.5.2.6. Detalle de solicitud
Al dar clic sobre una solicitud ya agendada el usuario observara una interfaz donde
se presentan todos los detalles de una solicitud en curso.
70
8.5.2.7. Interfaz lista de chequeo de salida de vehículo
Mediante esta interfaz se verifica el estado de cada vehículo que va a ser entregado
a un cliente. El usuario da clic sobre la casilla de verificación del ítem
correspondiente a verificar para darlo como revisado y aprobado.
71
Si al dar clic en el botón verificar no se ha aprobado algún ítem de la lista, el vehículo
no se puede dar por aprobado para entrega al cliente y se mostrara el respectivo
mensaje de lista de chequeo no aprobada.
En caso de que la lista de chequeo haya sido aprobada en su totalidad el sistema
mostrara una interfaz de lista aprobada.
72
8.5.2.8. Interfaz lista de chequeo de entrega de vehículo
Mediante esta interfaz se verifica el estado de cada vehículo que va a ser recibido
de un cliente. El usuario da clic sobre la casilla de verificación del ítem
correspondiente a verificar para darlo como revisado y aprobado.
Si al dar clic en el botón verificar no se ha aprobado algún ítem de la lista, el vehículo
no se puede dar por aprobado para ser recibido y se generara una factura por los
73
cobros adicionales generados, además se mostrara el respectivo mensaje de lista
de chequeo no aprobada.
En caso de que la lista de chequeo haya sido aprobada en su totalidad el sistema
mostrara una interfaz de lista aprobada sin generar cobros adicionales.
74
8.5.2.9. Interfaz de factura sin novedades
Una vez que se haya validado la lista de chequeo de entrega de vehículo, el usuario
podrá generar la factura.
75
8.5.2.10. Interfaz de factura con novedades
Si algún ítem de la lista de chequeo no fue aprobado la factura mostrara los ítems
a pagar de la lista de chequeo no aprobados.
76
8.5.2.11. Interfaz de visualización de facturas generadas
Se puede observar un listado histórico de las facturas generadas para los clientes.
8.5.2.12.
8.5.2.13. Interfaz de visualización de vehículos
Aquí se puede ver el listado de los vehículos registrados en el sistema.
77
8.5.2.14. Interfaz de visualización de clientes
Este es un listado de los clientes registrados en la base de datos, también se puede
actualizar la información de un cliente.
8.5.2.15. Interfaz actualización de los datos de clientes
El usuario podrá actualizar los datos de un cliente dando clic en el link actualizar de
a la interfaz anterior.
78
8.5.2.16. Interfaz de registro de nuevos clientes
El usuario podrá registrar los datos de un nuevo cliente dando clic en el botón de
nuevo cliente.
79
9. CONCLUSIONES
Es importante para toda empresa realizar un proceso de evaluación y gestión
de los procesos que desarrolla. Gracias a esta reingeniería de procesos, la
organización TRANSPORTES ZAMBRANO pudo encontrar nuevas
oportunidades para, no sólo optimizar tiempo y recursos en los mismos, sino
encontrar nuevos modelos de negocio.
Los modelos de negocio actuales requieren estar apoyados en las
tecnologías de la información y comunicaciones (TICS), pero estas requieren
a su vez, para una adecuada implementación y despliegue en la
organización, métodos sistemáticos y ciclos de vida basados en ingeniería
de software, acordes con el tipo de solución tecnológica a desplegar. En el
caso particular del sistema de información objeto de estudio del presente
documento, se eligió un patrón arquitectónico (Modelo Vista Controlador), el
cual soporta toda una solución tecnológica basada en patrones de diseño
bajo un lenguaje orientado a objetos de última generación (PHP 5.2), y
tecnologías cliente (Javascript , CSS, HTML5).
De acuerdo a los resultados obtenidos se puede concluir que se debe
impulsar actualización de los datos antiguos en el nuevo sistema de
información para poder obtener un beneficio adecuado con la herramienta
implementada, acorde con el modelo de negocio que persigue la
organización.
Es completamente recomendable la implementación de software sistema de
información en cualquier empresa que desee estar en crecimiento continuo
80
10. BIBLIOGRAFÍA
PRESSMAN, Roger S. Ingeniería de Software, un enfoque práctico. Mc Graw Hill, 2010.
Erich Gamma. Patrones de diseño. Pearson 1° Edición 2003
Luke Welling, Laura Thomsom. Desarrollo Web con PHP y MySql. Pearson 3° Edición 2005
Chris Pitt. PRO PHP MVC (professional apress). Apress 1edición.
Martin Bean. Laravel 5 Essentials. Packt Publishing 2015.
Chuck Heintzelman. Laravel 5.1 Beauty: Creating Beautiful Web Apps in Laravel 5.1. Createspace; Edición: 1 2015.
Kyrnin Jennifer. Bootstrap in 24 Hours, Sams Teach Yourself. SAMS DIV OF PEARSON; Edición 1 2015
Collection 5974: Designing, Deploying, and Managing a Network Solution for a Small- and Medium-Sized Business
Building Web Objects Applications. Jesse Feiler. McGraw-Hill Osborne Media. Nov 01, 2001
UML y Patrones. 2ª Edición. Craig Larman. Prentice Hall. 2003
http://www.elserver.com/conociendo-laravel-el-framework-que-revoluciono-php/
https://es.wikipedia.org/wiki/Programacion_por_capas
http://codehero.co/laravel-4-desde-cero-estructura-del-proyecto/
http://laraveles.com/docs/5.1/lifecycle
http://www.bcnbit.com/laravel-4-resumen-para-principiantes-parte-i/
http://revistatelematica.cujae.edu.cu/index.php/tele/article/viewFile/15/10
http://blog.devacademy.la/post/94202131491/tutorial-laravel-introducci%C3%B3n-y-conceptos