ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/7244/1/CD-5392.pdf ·...
104
ESCUELA POLITÉCNICA NACIONAL FACULTAD DE INGENIERÍA DE SISTEMAS DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN DE MOVIMIENTO DE PAQUETES PARA EMPRESAS DE COURIER. APLICACIÓN A UN CASO DE ESTUDIO PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN NICOLALDE FREIRE DAVID ALEJANDRO [email protected] PÉREZ ALMEIDA DIEGO ANDRÉS [email protected] DIRECTOR: MSc. Ing. MARCOS RAÚL CÓRDOVA BAYAS [email protected] Quito, Noviembre 2013
Transcript of ESCUELA POLITÉCNICA NACIONALbibdigital.epn.edu.ec/bitstream/15000/7244/1/CD-5392.pdf ·...
ESCUELA POLITÉCNICA NACIONAL
FACULTAD DE INGENIERÍA DE SISTEMAS
DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN
DE MOVIMIENTO DE PAQUETES PARA EMPRESAS DE
COURIER. APLICACIÓN A UN CASO DE ESTUDIO
PROYECTO PREVIO A LA OBTENCIÓN DEL TÍTULO DE INGENIERO EN
SISTEMAS INFORMÁTICOS Y DE COMPUTACIÓN
NICOLALDE FREIRE DAVID ALEJANDRO
PÉREZ ALMEIDA DIEGO ANDRÉS
DIRECTOR: MSc. Ing. MARCOS RAÚL CÓRDOVA BAYAS
Quito, Noviembre 2013
DECLARACIÓN
Nosotros, Diego Andrés Pérez Almeida, David Alejandro Nicolalde Freire
declaramos bajo juramento que el trabajo aquí descrito es de nuestra autoría; que
no ha sido previamente presentada para ningún grado o calificación profesional; y,
que hemos consultado las referencias bibliográficas que se incluyen en este
documento.
A través de la presente declaración cedemos nuestros derechos de propiedad
intelectual correspondientes a este trabajo, a la Escuela Politécnica Nacional,
según lo establecido por la Ley de Propiedad Intelectual, por su Reglamento y por
la normatividad institucional vigente.
Diego Andrés Pérez Almeida David Alejandro Nicolalde Freire
CERTIFICACIÓN Certifico que el presente trabajo fue desarrollado por Diego Andrés Pérez Almeida
y David Alejandro Nicolalde Freire, bajo mi supervisión.
Ing. Raul Córdova Bayas
DIRECTOR DE PROYECTO
AGRADECIMIENTOS Gracias a todos los que estuvieron conmigo a lo largo de este proyecto y
confiaron en mí.
A Deivid, por ser más que un compañero un amigo incondicional.
A mi Pauli, que me apoyó y acompañó desde que comencé hasta que terminé.
A mi familia, amigos, a nuestro director Raúl Córdova, a mis profes de la poli. A
todos, Gracias!
Diego
AGRADECIMIENTOS
Tomando las palabras de un grande de la música:
"¡No solo no hubiéramos sido nada sin
ustedes, sino con toda la gente que
estuvo a nuestro alrededor desde el
comienzo; algunos siguen hasta hoy!
¡Gracias totales!"
Gustavo Cerati
Soda Stereo, 1997
Gracias a mi pana Diego por los buenos y malos ratos. ¡Lo Logramos!
Gracias a todos los panas de la escuelita, del cole y de la U. ¡Toda la vida
carnaval!
Pocas palabras. Sencillas y complejas a la vez. A todos los que se cruzaron y
dejaron su huella en este largo camino, ¡GRACIAS TOTALES!
Niko
DEDICATORIA A Laura. Mi tía, mi segunda madre.
Diego
DEDICATORIA A Ustedes, mis padres, de la paciencia, el amor y mentes lúcidas que aún me
guían inapagables.
A Ti, el alma incondicional e enigmática, palabra precisa, sonrisa amplia y mirada
cautivante.
A Ustedes mis hermanos, de diferencias y similitudes grabadas en anécdotas
coleccionables.
A Ustedes mis sobrinas, la alegría, las ocurrencias, las enseñanzas y caritas
pintadas de colores.
A Ustedes, mi familia de cimientos firmes, unión duradera y siempre con ganas de
ayudarte.
Y a Ustedes los de la amistad sincera, paso nocturno, buen juego, risas e
historias interminables.
Niko
CONTENIDO 1. CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA .................................................................................. 1
1.1 DESCRIPCIÓN GENÉRICA DE LOS PROCESOS DE LAS EMPRESAS DE COURIER .................................. 1 1.1.1 EMPRESAS DE COURIER ............................................................................................................... 1 1.1.2 Procesos de una empresa courier ................................................................................................ 3
1.1.2.1 Gestión Administrativa y Logística ..................................................................................................... 3 1.1.2.2 Gestión Jurídica .................................................................................................................................. 4 1.1.2.3 Gestión de Tecnologías de la Información y Comunicaciones ............................................................ 6 1.1.2.4 Gestión de Servicio al Cliente ............................................................................................................. 7 1.1.2.5 Gestión de Comercialización y Ventas ............................................................................................... 8 1.1.2.6 Courier................................................................................................................................................ 9
1.1.2.6.1 Terminología.................................................................................................................................. 9 1.1.2.6.2 Categorización de mercaderías para Courier .............................................................................. 10 1.1.2.6.3 Proceso de importación............................................................................................................... 11 1.1.2.6.4 Proceso de Desaduananización (Nacionalización de mercadería) ............................................... 13 1.1.2.6.5 Proceso de Liquidación ................................................................................................................ 14
1.1.3 SITUACIÓN ACTUAL ................................................................................................................... 15 1.1.4 PROPUESTA DE SOLUCIÓN ......................................................................................................... 15
1.2 SELECCIÓN Y JUSTIFICACIÓN DE METODOLOGÍA DE DESARROLLO ................................................ 16 1.2.1 CARACTERÍSTICAS DEL PROYECTO ............................................................................................. 16 1.2.2 METODOLOGÍAS TRADICIONALES VS ÁGILES............................................................................. 17 1.2.3 SELECCIÓN DE METODOLOGÍA DE DESARROLLO ÁGIL .............................................................. 19
1.3 SELECCIÓN Y JUSTIFICACIÓN DE HERRAMIENTAS DE DESARROLLO ............................................... 21 1.3.1 SISTEMA DE GESTIÓN DE BASE DE DATOS (DBMS) .................................................................... 21 1.3.2 LENGUAJE DE PROGRAMACIÓN ................................................................................................ 21 1.3.3 FRAMEWORK DE DESARROLLO ................................................................................................. 22
1.3.3.1 Kohana Framework [26] ................................................................................................................... 22 1.3.3.2 Zend PHP [27] ................................................................................................................................... 23 1.3.3.3 Symfony [28] .................................................................................................................................... 23 1.3.3.4 Kohana Framework vs Zend PHP vs Symfony ................................................................................... 24
1.3.4 SERVIDOR WEB .......................................................................................................................... 24 1.3.5 ENTORNO DE DESARROLLO INTEGRADO (IDE) .......................................................................... 25 1.3.6 HERRAMIENTAS CASE ................................................................................................................ 25
1.4 PRESUPUESTO GENERAL DEL SISTEMA .......................................................................................... 25
2. CAPÍTULO II: DESARROLLO DEL SISTEMA .......................................................................................... 28
2.1 REQUERIMIENTOS .......................................................................................................................... 28 2.1.1 USUARIOS DEL SISTEMA ............................................................................................................ 28
2.1.1.1 Administrador .................................................................................................................................. 28 2.1.1.2 Gerente ............................................................................................................................................ 28 2.1.1.3 Operador de Call Center (Servicio al Cliente) ................................................................................... 28 2.1.1.4 Operador de Call Center (Publicidad) ............................................................................................... 29
2.1.2 HISTORIAS DE USUARIO ............................................................................................................. 29 2.1.2.1 Gestión Administrativa ..................................................................................................................... 30 2.1.2.2 Gestión de Carga .............................................................................................................................. 32 2.1.2.3 Gestión de Reportes ......................................................................................................................... 33
2.2 ANÁLISIS ......................................................................................................................................... 34 2.2.1 ESTIMACIÓN DE ESFUERZO........................................................................................................ 34 2.2.2 Priorización ................................................................................................................................ 35 2.2.3 PLAN DE ENTREGAS ................................................................................................................... 36
2.3 DISEÑO ........................................................................................................................................... 37 2.3.1 DISEÑO ARQUITECTÓNICO DEL SISTEMA .................................................................................. 37
2.3.1.1 Arquitectura MVC (Modelo – Vista – Controlador) .......................................................................... 37 2.3.2 TARJETAS CRC ............................................................................................................................ 38
2.3.2.1 TARJETAS CRC DEL SISTEMA ............................................................................................................. 39 2.3.3 DIAGRAMA DE CLASES ............................................................................................................... 43
2.3.3.1 Elementos y sintaxis de un diagrama de clases ................................................................................ 43
2.3.3.1.1 Clase ............................................................................................................................................ 43 2.3.3.1.2 Atributos ...................................................................................................................................... 44 2.3.3.1.3 Métodos ...................................................................................................................................... 44 2.3.3.1.4 Relaciones ................................................................................................................................... 44
2.3.3.2 Diagrama de Clases del Sistema ....................................................................................................... 47 2.3.4 DIAGRAMA FÍSICO DE LA BASE DE DATOS ................................................................................. 48
2.3.4.1 Diccionario de Datos del Sistema ..................................................................................................... 50 2.3.5 DISEÑO DE INTERFACES DE USUARIO ........................................................................................ 57
2.3.5.1 Consideraciones Generales .............................................................................................................. 58 2.4 IMPLEMENTACIÓN ......................................................................................................................... 61
2.4.1 PROGRAMACIÓN ....................................................................................................................... 61 2.4.1.1 PHP ................................................................................................................................................... 61
2.4.1.1.1 Estándares de programación PHP ............................................................................................... 61 2.4.1.1.2 Modelos en Kohana Framework .................................................................................................. 64 2.4.1.1.3 Controladores en Kohana Framework ......................................................................................... 64 2.4.1.1.4 Vistas en Kohana Framework ...................................................................................................... 66
2.4.2 JQUERY (JAVASCRIPT) ................................................................................................................ 67 2.4.3 CSS (CaSCADE STYLE SHEETS) .................................................................................................... 68
PRUEBAS ............................................................................................................................................. 69 2.5 ............................................................................................................................................................... 69
2.5.1 Pruebas de aceptación ............................................................................................................... 69
3. CAPÍTULO III: CASO DE ESTUDIO ....................................................................................................... 76
3.1 DESCRIPCIÓN DEL CASO DE ESTUDIO ............................................................................................. 76 3.2 IMPLEMENTACIÓN DEL SISTEMA ................................................................................................... 77 3.3 ANÁLISIS DE RESULTADOS .............................................................................................................. 82
4. CONCLUSIONES Y RECOMENDACIONES ......................................... ¡ERROR! MARCADOR NO DEFINIDO.
4.1 CONCLUSIONES .............................................................................................................................. 85 4.2 RECOMENDACIONES ...................................................................................................................... 86
BIBLIOGRAFÍA ........................................................................................................................................... 87
GLOSARIO ................................................................................................................................................. 89
ANEXOS .................................................................................................................................................... 91
ÍNDICE DE TABLAS
Tabla 1.1: Clasificación de Mercaderías para envíos mediante Courier .......................................... 11 Tabla 1.2: Valores de impuestos y tributos por categoría de mercadería de Courier ..................... 14 Tabla 1.3: Metodologías Tradicionales vs Metodologías ágiles ....................................................... 18 Tabla 1.4: Tabla de Ponderación ...................................................................................................... 20 Tabla 1.5: Características de principales metodologías ágiles ......................................................... 20 Tabla 1.6: Kohana vs Zend PHP vs Symfony ..................................................................................... 24 Tabla 1.7: Presupuesto de Recursos Humanos ................................................................................ 26 Tabla 1.8: Presupuesto de Gastos Administrativos .......................................................................... 26 Tabla 1.9: Presupuesto de Gastos en Hardware .............................................................................. 26 Tabla 1.10: Presupuesto de Gastos en Software ............................................................................. 26 Tabla 1.12: Presupuesto General del Sistema .................................................................................. 27 Tabla 2.1: Historia de Usuario – Administración de Perfiles ............................................................ 30 Tabla 2.2: Historia de Usuario – Administración de Usuarios. ......................................................... 30 Tabla 2.3: Historia de Usuario – Administración de Contactos. ....................................................... 30 Tabla 2.4: Historia de Usuario – Administración de Competencia. ................................................. 31 Tabla 2.5: Historia de Usuario – Administración de Clientes. .......................................................... 31 Tabla 2.6: Historia de Usuario – Administración de Prospectos. ..................................................... 31 Tabla 2.7: Historia de Usuario – Administración de Tipos de Carga. ............................................... 32 Tabla 2.8: Historia de Usuario – Administración de Agentes Destinatarios. ................................... 32 Tabla 2.9: Historia de Usuario – Administración de Promociones. .................................................. 32 Tabla 2.10: Historia de Usuario – Administración de Paquetes. ...................................................... 33 Tabla 2.11: Historia de Usuario – Reporte de Clientes/Prospectos. ................................................ 33 Tabla 2.14: Priorización de historias de usuario. ............................................................................. 36 Tabla 2.15: Plan de Entregas. ........................................................................................................... 36 Tabla 2.16: Tarjeta CRC - Cliente ...................................................................................................... 39 Tabla 2.17: Tarjeta CRC - Observación ............................................................................................. 39 Tabla 2.18: Tarjeta CRC - Competidor .............................................................................................. 40 Tabla 2.19: Tarjeta CRC - Contacto................................................................................................... 40 Tabla 2.20: Tarjeta CRC – Agente Destinatario ................................................................................ 41 Tabla 2.21: Tarjeta CRC – Promoción ............................................................................................... 41 Tabla 2.22: Tarjeta CRC – Tipo de Contenido ................................................................................... 41 Tabla 2.23: Tarjeta CRC - Paquete .................................................................................................... 42 Tabla 2.24: Tarjeta CRC - Usuario ..................................................................................................... 43 Tabla 2.25: Tarjeta CRC – Perfil ........................................................................................................ 43 Tabla 2.26: Nivel de acceso .............................................................................................................. 44 Tabla 2.27: Cardinalidad en UML ..................................................................................................... 45 Tabla 2.28: Diccionario de Datos: Entidad Customer ....................................................................... 51 Tabla 2.29: Diccionario de Datos: Entidad Customer Observation .................................................. 51 Tabla 2.30: Diccionario de Datos: Entidad Customer Email ............................................................. 52 Tabla 2.31: Diccionario de Datos: Entidad Customer Address ......................................................... 52 Tabla 2.32: Diccionario de Datos: Entidad Customer Phone ........................................................... 52 Tabla 2.33: Diccionario de Datos: Entidad Customer Attachment .................................................. 52 Tabla 2.34: Diccionario de Datos: Entidad Profile ............................................................................ 53 Tabla 2.35: Diccionario de Datos: Entidad Action ............................................................................ 53 Tabla 2.36: Diccionario de Datos: Entidad Allowed Actions ............................................................ 53 Tabla 2.37: Diccionario de Datos: Entidad User ............................................................................... 54 Tabla 2.38: Diccionario de Datos: Entidad Package ......................................................................... 55 Tabla 2.39: Diccionario de Datos: Entidad Content Type................................................................. 56
Tabla 2.40: Diccionario de Datos: Entidad Status ............................................................................ 56 Tabla 2.41: Diccionario de Datos: Entidad Offer .............................................................................. 56 Tabla 2.42: Diccionario de Datos: Entidad Receiver Agent .............................................................. 57 Tabla 2.43: Diccionario de Datos: Entidad Country ......................................................................... 57 Tabla 2.46: Prueba de Aceptación – Actualizar Perfil ...................................................................... 71 Tabla 2.47: Prueba de Aceptación – Activar/Desactivar Perfil ........................................................ 72 Tabla 2.48: Prueba de Aceptación – Nuevo Usuario ........................................................................ 73 Tabla 2.49: Prueba de Aceptación – Actualizar Usuario .................................................................. 74 Tabla 2.50: Prueba de Aceptación – Activar/Desactivar Usuario .................................................... 75 Tabla 3.1 Modelo de Encuesta para recolección de datos .............................................................. 82 Tabla 3.2: Resultados de Encuestas ................................................................................................. 83
ÍNDICE DE FIGURAS
Figura 1.1: Acumulación de paquetes Courier por empresa............................................................. 2 Figura 1.2: Principales ciudades beneficiarias de Remesas (Millones de USD) [2] ........................... 2 Figura 1.3: Organigrama Estructural de la Empresa “RUMICOURIER Cía. Ltda.”[4] ......................... 4 Figura 1.4: INCOTERMS 2010 .......................................................................................................... 10 Figura 2.1: Arquitectura MVC del sistema ....................................................................................... 38 Figura 2.2: Ejemplo de Generalización con UML ............................................................................. 45 Figura 2.3: Ejemplo de Asociación con UML .................................................................................... 45 Figura 2.4: Ejemplo de Composición con UML................................................................................. 46 Figura 2.5: Ejemplo de Agregación con UML ................................................................................... 46 Figura 2.6: Ejemplo de Dependencia con UML ................................................................................ 46 Figura 2.7: Diagrama de Clases del Sistema ..................................................................................... 47 Figura 2.8: Diagrama Físico de la Base de Datos .............................................................................. 49 Figura 2.9: Interfaz de inicio de sesión mostrando validaciones de datos ...................................... 58 Figura 2.10: Interfaz de Inicio de Sesión con un ingreso erróneo al Sistema. ................................. 59 Figura 2.11: Interfaz de Administración de Perfiles con Mensaje de Creación exitosa. .................. 59 Figura 2.12: Interfaz de Administración de Usuarios ....................................................................... 60 Figura 2.13: Interfaz de Nuevo Usuario con botón de regreso ........................................................ 60 Figura 2.14: Interfaz de creación de Usuario. .................................................................................. 61 Figura 2.15: Estándar para nombres de clases ................................................................................ 62 Figura 2.16: Estándar para nombres de funciones y valores de retorno en Kohana Framework ... 62 Figura 2.17: Estándar para llaves y paréntesis de apertura y cierre, en estructuras de control ..... 63 Figura 2.18: Estándar para lista de argumentos, en funciones y métodos ...................................... 63 Figura 2.19: Estándar para lista de argumentos, en funciones y métodos ...................................... 64 Figura 2.20: Modelo Usuario, en Kohana Framework ..................................................................... 64 Figura 2.21: Controlador y acción de Usuario, en Kohana Framework ........................................... 65 Figura 2.22: Instanciación de una vista y envío de variables a vista, en Kohana Framework .......... 66 Figura 2.23: Vista por defecto de Usuario, en Kohana Framework ................................................. 66 Figura 2.24: Ejemplo de Implementación de Código jQuery (javascript) ........................................ 67 Figura 2.25: Ejemplo de Código CSS ................................................................................................. 68 Figura 3.1: Archivo de Configuración del sistema ............................................................................ 78 Figura 3.2: Llamada al sistema desde un navegador convencional (Mozilla Firefox) ...................... 78 Figura 3.3: Creación de Perfiles de Usuario ..................................................................................... 79 Figura 3.4: Perfiles de Usuario ......................................................................................................... 80 Figura 3.5: Creación de Usuario ....................................................................................................... 80 Figura 3.6: Creación de Clientes ....................................................................................................... 81 Figura 3.7: Creación de Paquete ...................................................................................................... 81 Figura 3.8: Movimiento de Paquete ................................................................................................. 82
INTRODUCCIÓN
Actualmente las empresas de Courier, dedicadas al envío y recepción de
paquetes internacionales, han tenido un auge considerable en el Ecuador. Por
este motivo es importante que tengan un sistema informático que les permita
automatizar sus tareas y el manejo de la información. Beneficiando así, tanto a
sus usuarios, empleados, y por consiguiente a sus clientes, ofreciéndoles
información actualizada, confiable, e integra.
Mediante este documento se describe los procesos involucrados en el
“DESARROLLO DE UNA APLICACIÓN WEB PARA LA GESTIÓN DE
MOVIMIENTO DE PAQUETES PARA EMPRESAS DE COURIER”.
Este sistema permitirá automatizar procesos que actualmente son realizados
manualmente, tales como: gestión de información de clientes y prospectos,
gestión de movimiento de paquetes; reportes de clientes, paquetes y
observaciones.
En el Capítulo I se presenta una descripción genérica de los procesos de las
empresas de Courier así como también se analizan a profundidad los
subprocesos desde que un paquete es enviado hasta que llega hasta las manos
del cliente. Además se elige XP (Extreme Programming) como metodología de
desarrollo, y se eligen y exponen las herramientas a utilizar en este proceso. Se
incluye también un presupuesto general para el desarrollo este proyecto.
En el Capítulo II se establecen y analizan los requerimientos mediante las
historias de usuario. Se presenta el análisis de los mismos con su respectiva
estimación de esfuerzo, priorización y plan de entregas. Se define el diseño
arquitectónico del sistema (Modelo - Vista - Controlador) y las tarjetas CRC, que
sirven como base para la elaboración del diagrama de clases y diagrama físico de
la base de datos. Se define el diccionario de datos, así como el diseño de
interfaces. Se describen los estándares de programación utilizados para la
codificación del sistema. Finalmente se elaboran las pruebas de aceptación del
sistema.
En el Capítulo III se describe la implementación del sistema en el caso de estudio
(TransferCargo S.A), así como el análisis de resultados en la misma.
En el Capítulo IV se establecen las conclusiones y recomendaciones obtenidas
en el desarrollo del proyecto de titulación.
1
1. CAPÍTULO I: PLANTEAMIENTO DEL PROBLEMA
1.1 DESCRIPCIÓN GENÉRICA DE LOS PROCESOS DE LAS EMPRESAS DE COURIER
1.1.1 EMPRESAS DE COURIER
Según las leyes vigentes del Ecuador, específicamente en el Reglamento para la
aplicación del impuesto a la salida de divisas, y con Registro Oficial N° 336 de
Mayo de 2008 se menciona: “Las empresas de Courier, para efectos de la
aplicación de esta ley se dividen en dos tipos:
1. Mensajería expresa o correos rápidos: son sociedades reguladas por la
Superintendencia de Compañías, que prestan el servicio de envío o traslado de
encomiendas, paquetes o sobres al exterior.
2. Courier propiamente dichos: son sociedades reguladas por la
Superintendencia de Compañías, que prestan el servicio de transferencias,
traslado o envío, y recepción de divisas, paquetes, encomiendas y sobres, desde
y hacia el exterior.”[1]
En el Ecuador, según cifras del Banco Central, hasta el 2006, existían 232
empresas de Courier registradas y legalmente constituidas en la Superintendencia
de Compañías, estando hasta ese año 140 activas. En el 2012 en cambio, se
encontraban registradas y activas 159 empresas de Courier, sin embargo tan solo
62 empresas eran reconocidas por la Corporación Aduanera Ecuatoriana y
cumplían con los requisitos de ley para desarrollar actividades de transporte bajo
Courier.
En función de la encuesta realizada por el BCE y la Universidad de Cuenca en el
2004, se conoce que la mayoría de envíos por medio de Courier se los realiza por
empresas anexas a bancos tanto del Ecuador como internacionales; así mismo un
informe del FOMEN-BID concluye que los dos tercios de remesas enviadas hacia
el Ecuador llegan a través de estas empresas especializadas en Courier. En este
contexto se tiene la Figura 1.1 que muestra los porcentajes de acumulación de
paquetes totales Courier por cada empresa.
2
Figura 1.1: Acumulación de paquetes Courier por empresa.
Como se puede apreciar la mayoría de envíos, específicamente el 40%, se los
realiza con grandes empresas de Courier como son Delgado Courier (parte de
Delgado Travel) y DHL, empresa alemana internacional dedicada a estos
servicios.
En cuanto a aporte financiero, la mayoría se concentra en Guayaquil, seguida por
Cuenca y Quito. Así se tiene en la Figura 1.2. el total de beneficio monetario, para
cada ciudad haciendo uso de este medio, según el boletín del tercer trimestre de
2012 del Banco Central del Ecuador.
Figura 1.2: Principales ciudades beneficiarias de Remesas (Millones de USD) [2]
Delgado Courier28%
DHL12%
Corpuaustro8%
Sur Express5%
Orient Courier
5%
Otros42%
3
1.1.2 PROCESOS DE UNA EMPRESA COURIER
Una empresa de Courier posee los procesos generales de una empresa de
servicios siendo el proceso de Courier en sí el más importante. A continuación se
describen los principales procesos de las empresas de Courier.
1.1.2.1 Gestión Administrativa y Logística
“Algunos analistas consideran que la logística es un mercado diferente de los
servicios básicos y de los urgentes y que se diferencia de ambos por la inclusión
de nuevas prestaciones de mayor valor añadido. La logística se define como el
mercado de los servicios de planeamiento, implementación y control del flujo y
almacenamiento de bienes, servicios e información relacionada, desde el punto
de origen al punto de destino, de acuerdo con los requerimientos del cliente.” [3]
En el ámbito nacional, por ejemplo, DHL ofrece algunos tipos de soluciones en
logística: Transporte de Carga, Almacenaje y Distribución, Intermediación
aduanera, entre otros. DHL Ecuador maneja un sistema de Área de Clientes que
permite a los usuarios de los diferentes servicios logísticos rastrear sus paquetes
o mercaderías, esto ayuda a crear un valor agregado, donde el usuario tiene la
tranquilidad de estar trabajando con una empresa seria con prestigio y respaldo
tecnológico.
Referente a la logística dirigida a las pequeñas o medianas empresas de Courier
se puede decir que, si bien cuentan con sistemas eficientes de transporte, no se
genera adecuadamente el valor agregado de confiabilidad y seguridad que
necesita el cliente. En nuestro caso de estudio por ejemplo, esta confiabilidad,
seguridad y eficiencia son valores que crecen con publicidad indirecta mediante
referencias de antiguos clientes, es así que, dichos valores no son cuantificables
en la mayoría de los casos.
Por otro lado en cuanto a la administración de una empresa de Courier de
acuerdo a la realidad nacional y de las pequeñas y medianas empresas se han
4
determinado tres departamentos estratégicos de acuerdo a las necesidades del
negocio: administración, operaciones y logística, contabilidad y comercialización,
las cuales éstas directamente reguladas por la Gerencia General.
Sin embargo, en la mayoría de los casos no se tiene personal exclusivo para
estos procesos, como podemos observar en un organigrama estructural básico de
una empresa mediana de Courier en la Figura 1.3.
Figura 1.3: Organigrama Estructural de la Empresa “RUMICOURIER Cía. Ltda.” [4]
1.1.2.2 Gestión Jurídica
La gestión jurídica juega un papel importante en conjunto con la realidad del sitio
geográfico donde se desarrollan las actividades económicas de la organización.
“La ocurrencia de cambios sociales, económicos y regulatorios ha incidido
acentuadamente sobre la marcha de las empresas. Esta dinámica trajo consigo la
necesidad de modificación de los esquemas de conducción de las organizaciones,
5
debiendo las áreas jurídicas asumir mayores desafíos para construir valor y
mantener a los entes dentro del marco de legalidad.” [5]
Un aspecto importante para una empresa de Courier es cumplir con los
requerimientos establecidos por la ley ecuatoriana para la importación y
exportación de productos, vamos a enfocarnos los requerimientos legales para las
compañías de Courier:
· Solicitud de Autorización para brindar el servicio de tráfico postal
internacional y correos rápidos o Courier dirigida al Gerente General de la
Corporación Aduanera Ecuatoriana.
· Copia certificada de la escritura en donde conste el estatuto vigente de la
empresa, en cuyo objeto social debe constar esta actividad.
· Copia certificada del nombramiento del Representante Legal de la
empresa, actualizado e inscrito en el Registro Mercantil.
· Si se trata de una empresa extranjera, adicionalmente debe demostrar que
está domiciliada en el país.
· Listado de el o los nombres comerciales con los que prestarán el servicio
de correos rápidos o Courier.
· Copia del Registro Único de Contribuyentes actualizado.
· Copia certificada de las declaraciones de impuesto a la renta de los dos
últimos ejercicios económicos, en caso de aplicarse.
· Indicación de los aeropuertos internacionales a través de los cuales se
produciría el ingreso y salida de los envíos postales.
· Copia del comprobante de pago de la tasa de postulación.
· Copia del comprobante de pago de la tasa extraordinaria de inscripción.
Todos los demás que estén contemplados en la Ley Orgánica de Aduanas y su
Reglamento General.” [6]
Un departamento jurídico vanguardista puede ser una ventaja competitiva. Evita
retrasos en trámites o confusión de documentación. Además de mantener un
marco saludable de apego a la ley.
6
1.1.2.3 Gestión de Tecnologías de la Información y Comunicaciones
La gestión de tecnologías de la información y comunicaciones (TICs) es un
proceso indispensable dentro de una empresa de Courier, puesto que con este,
se asegura que tanto el software como el hardware sean los adecuados y que
apoyen a los objetivos y modelo de negocio de la empresa. Sin embargo, las
pequeñas y medianas empresas de Courier obvian este proceso, y tan solo tienen
servicios ocasionales externos para esta tarea, lo que conlleva a problemas
informáticos más graves, o pérdida directa en la rentabilidad. En contraste, las
grandes empresas de Courier se benefician e incrementan su producción gracias
al uso adecuado de las TICs1, la correcta aplicación de hardware y software
específico para cada una de sus tareas, como el uso de plataformas como
Asterisk2 para el Call Center, ó de RFID3 (Radio Frequency Identification) para el
seguimiento de paquetes, usado por ejemplo por DHL.
Por este motivo, la gestión de TICs es sumamente importante para una empresa
Courier, tal como Erik Brager, jefe del equipo de producción de DHL, lo mencionó
“Las TIC son cada vez más importantes para DHL, como para cualquier empresa
de distribución y transporte. Para los pedidos en línea y para el seguimiento y
localización de los envíos, no contar con las TIC es simplemente inconcebible.
Nuestros clientes nos piden continuamente más información y más rápidamente
sobre dónde se encuentran sus paquetes. Para ello, confiamos en un sistema de
seguimiento y localización que nos permite informarles con la mayor exactitud
posible. El flujo de transporte físico y los flujos de información virtual deben, por
así decirlo, estar sincronizados a todos los niveles.” [7]
A nivel nacional, respecto al uso de TICs en las empresas de Courier, se tiene por
ejemplo a RECAPT, domiciliada en la ciudad de Guayaquil la cual cuenta con un
Centro de Procesamiento de Datos (CPD) que sigue las recomendaciones de las
mejores prácticas en IT (ITIL v.3) y normas en infraestructura de LAN y WAN, en 1 TIC: Tecnologías de la Información y de la Comunicación.
2 Asterisk: es un programa de software libre (bajo licencia GPL) que proporciona funcionalidades de una
central telefónica (PBX) y VoIP 3 RFID: Siglas de Radio FrequencyIdentification.es un sistema de almacenamiento y recuperación de datos
remoto que usa dispositivos denominados etiquetas RFID.
7
las que según sus objetivos generales de servicio asegura no solo disponibilidad
si no calidad en las trasmisión de información, dando un mejor servicio tanto a
clientes como al personal interno.
Las diferentes oficinas se encuentran integradas a las varias plataformas
disponibles a través de robustas redes de comunicaciones, además estas
plataformas cuentan con redundancia para asegurar disponibilidad de
información.
1.1.2.4 Gestión de Servicio al Cliente
Un proceso importante para cualquier empresa de servicios, es mantener al
cliente satisfecho. Para ello es importante que el cliente sienta que está protegido
y ha hecho bien en contratar un servicio con una determinada empresa. En el
caso de las empresas de Courier, este proceso es uno de los más importantes
también, puesto que los envíos por este medio se pueden dar continuamente, y al
tener a un cliente fiel, la empresa se asegura que tendrá ingresos de este cliente,
así como también tendrá buenos comentarios y recomendaciones que pueden
conllevar a futuros clientes.
Debido a que el proceso de Courier es muy largo y posee muchos procedimientos
desde que el cliente solicita el servicio hasta que el servicio se completa, lo que
desean los clientes es conocer información y situación de su paquete, es decir, en
donde está, en qué estado está, y en qué fecha llegó a esa situación, en el menor
tiempo posible. Esto es un derecho que legalmente también posee un cliente tal
como está establecido en la Ley Orgánica de Defensa del Consumidor: “El
consumidor tiene derecho a la información adecuada, veraz, clara, oportuna y
completa sobre los bienes y servicios ofrecidos en el mercado, así como sus
precios, características, calidad, condiciones de contratación y demás aspectos
relevantes de los mismos, incluyendo los riesgos que pudieren prestar” [8].
Para ofrecer esta información las empresas de Courier, sobre todo las empresas
grandes y medianas (DHL, Delgado Travel, TransferCargo, Correos del Ecuador,
etc.) se ayudan de páginas web que permiten a los usuarios conocer algunos de
8
estos datos ingresando la guía del paquete directamente. Sin embargo, esta
utilidad es de gran ayuda solo a un reducido porcentaje de población del Ecuador
que cuenta con Internet y con el conocimiento necesario para manejarlo, según el
último censo poblacional realizado por el INEC en 2011, se determinó que tan
solo el 31.4% de la población utiliza Internet y por tanto accedería a esta vía de
información. Por este motivo, para solventar las necesidades de las personas que
no utilizan internet, algunas empresas también poseen call centers de servicio al
cliente, para brindarles la misma información pero haciendo uso solamente de una
llamada telefónica. Por lo general esta línea tiene los mismos horarios de atención
que las oficinas, y posee amplia demanda.
1.1.2.5 Gestión de Comercialización y Ventas
Las empresas Courier necesitan elaborar estrategias de venta, investigar sus
posibles clientes y también decidir cómo y mediante qué medios llegarán a ese
cliente. Este proceso es indispensable en empresas de servicios, y en las
empresas Courier no es la excepción, puesto que pueden ganar más clientes y
por ende más rentabilidad.
Así pues, las empresas de Courier, dependiendo de su tamaño, utilizan publicidad
tanto directa e indirecta. Mucho más utilizada por pequeñas y medianas empresas
de Courier es la publicidad directa, que es aquella que busca resultados en
tiempo mínimo y con contacto directo con el cliente. Para ello se utilizan correos
electrónicos masivos, folletos o anuncios impresos, marketing 2.0 a través de
redes sociales como Facebook y Twitter, y llamadas telefónicas mediante call
center para ofrecer y publicitar sus servicios. Al contrario, y utilizado mucho más
por empresas de Courier grandes, es la publicidad indirecta, ya que al ser
famosas, y con gran experiencia llegan a los clientes mediante recomendaciones
de otros usuarios satisfechos que ya han hecho uso del servicio.
Cuando el cliente requiere del servicio de Courier se realiza la cotización
correspondiente, que incluye los gastos de su compra en el exterior, los gastos
por cuestiones arancelarias, aduaneras y de impuestos, el flete, y la comisión
9
para la empresa de Courier. Si el cliente está de acuerdo, se efectúa la
facturación del mismo y empieza el proceso de Courier en sí.
1.1.2.6 Courier
Es el proceso clave y operacional de una empresa de Courier. Según la aduana
del Ecuador, el Courier es “El envío de paquetes y/o bultos a través de cualquier
clase de correo, sea éste público o privado hacia el extranjero cuyo valor en
aduana no exceda del límite que se establece en el reglamento y se
despacharán mediante formalidades simplificadas, conforme los procedimientos
que establezca la Aduana del Ecuador.” [9] El Courier está conformado por una
serie de procedimientos, documentos y trámites que deben ser realizados para
que un paquete pueda finalmente llegar a las manos del cliente. Esto por lo
general implica una compra en el extranjero, la importación de este paquete hacia
el país de destino, y el desaduanamiento del mismo (nacionalización de
mercaderías).
1.1.2.6.1 Terminología
Los involucrados en todo el proceso que implica el Courier, necesitan una forma
de establecer responsabilidades y guías sin importar el país en donde se los
realice. Así la Cámara de Comercio Internacional creó los “Términos de Comercio
Internacional” (INCOTERMS4), que son un conjunto de reglas para el
establecimiento de responsabilidades tanto del comprador como el vendedor en
actividades de compra-venta internacional. En el caso del Ecuador, se utiliza
INCOTERMS Versión 2010, que delimita las responsabilidades del vendedor y
comprador como se muestra en la Figura 1.4
4 INCOTERMS: Siglas de International Commercial Terms, son términos de tres letras cada uno que reflejan
las normas, de aceptación voluntaria de dos partes (compradora y vendedora), acerca de las condiciones de entrega de paquetes.
10
Figura 1.4: INCOTERMS 2010 [10]
1.1.2.6.2 Categorización de mercaderías para Courier
La Corporación Aduanera del Ecuador, determina y especifica categorías de
mercaderías, por su peso y valor, que se sujetan a este tipo de envío, como se
muestra en la Tabla 1.1. Es importante acotar que el FOB (Free on Board)
perteneciente al INCOTERMS 2010 es un valor referencial para efectuar la
categorización.
Categoría Descripción
A Documentos Impresos: libros, cartas, postales, periódicos,
fotografías; contenidos en medios de audio y video, magnéticos,
electromagnéticos, electrónicos.
B
(Necesitan
DAS-C)5
Menor o igual a 4Kg y US$400 FOB6 Paquetes cuyo peso sea
menor o igual a 4 kg. y su valor FOB sea menor o igual a los US$
400,00, siempre que se trate de bienes de uso para el destinatario y
5 DAS- C: Declaración Aduanera Simplificada – Courier: Es un formulario para servicios de Courier, mediante
el cual se especifica la información de un paquete y se lo pone a consideración de la aduana.
11
sin fines comerciales.
C
(Necesitan
DAS-C)
Menor o Igual a 50Kg y US$2.000 FOB Paquetes cuyo peso no
exceda los 50 kg. ni el valor FOB de US$ 2.000,00. (Excepciones:
repuestos para la industria, equipos médicos, o medios de
transporte, se admitirá un peso de hasta 200 kg., y el FOB no supere
los US$ 2.000,00, y no sean más de 10 unidades. Entran
automáticamente a esta categoría y con impuestos específicos
adicionales: Videojuegos, Perfumes, Bebidas Alcohólicas, Escopetas
y pistolas y TVs.
D Textiles y calzados. Menores o iguales a 20Kg. y US$2.000 FOB
Todas las prendas, textiles y calzados, que no se contemplen en la
Categoría B, deberán obligatoriamente declararse en esta categoría,
y el peso no puede excederse a los 20 kg. ni sobrepasar los US$
2.000,00
E
(Necesitan
DAS-C)
Medicina sin fines comerciales, equipos ortopédicos, órganos y
tejidos .Paquetes con medicinas sin fines comerciales, siempre que
arriben a nombre de una persona natural; aparatos ortopédicos,
órganos, tejidos y células; fluidos humanos; equipos y aparatos para
personas con discapacidad. No contempla limitaciones de peso y
valor.
F
(Necesitan
DAS-C)
Libros, y Equipos de computación y sus partes Paquetes con
libros o similares, o equipos de computación y sus partes; siempre
que la partida específica dentro de los capítulos 1 al 97 del Arancel
Nacional de Importaciones tenga tarifa 0%. Estos artículos están
exentos de toda limitación de peso y valor.
Tabla 1.1: Clasificación de Mercaderías para envíos mediante Courier
1.1.2.6.3 Proceso de importación
a) Nota de Pedido: cuando la mercadería ya ha sido comprada en un país
extranjero, y se encuentre en las bodegas de la empresa de Courier en ese
6 FOB: Free on Board, o Franco a Bordo es una clausula de comercio internacional que se refiere al valor de
venta de los productos en el extranjero, más el costo de los fletes, seguros y otros gastos necesarios para hacer llegar la mercancía hasta la aduana de salida
12
país, se realiza la nota de pedido en el país destino. Este es un documento
obligatorio que se entrega a la Aduana del país de destino, donde se incluyen
los datos del importador y exportador, el país de origen, el lugar de embarque,
el lugar de destino, la vía de transporte (aérea, marítima o terrestre), término
de la mercadería (FOB, CIF7, CyF), la moneda, la forma de pago, la fecha, y la
fecha de inicio de la negociación.
b) Conocimiento de embarque: la empresa de transporte, ya sea esta aérea,
marítima o terrestre entregará un documento al importador, que contiene
básicamente datos de la mercadería o paquetes, y un código único con el cual
se identificará a la misma. El importador a su vez debe entregar este
documento a la aduana. Este documento toma el nombre dependiendo la vía
de transporte, si es que es marítima se lo llama “conocimiento de embarque”,
si es aérea, se lo llama “guía aérea” y finalmente si es terrestre, se lo llama
“carta de porte”.
c) Certificado de Inspección: es un documento que certifica que la mercadería
recibida pasó la inspección y verificación satisfactoriamente.
d) Manifiesto de Carga: el manifiesto de carga es un documento obligatorio que
llega a la Aduana junto con la mercadería. En este se informa la vía de
transporte en la que vino la mercadería, el lugar determinado y la fecha
establecida a ser recibida, la fecha del embarque, y el peso de la misma.
e) Factura comercial: cuando se hace el pacto de compra y venta internacional,
se realiza un contrato que es plasmado en una factura comercial, que
contendrá datos específicos de la mercadería, como su peso, unidades, y
precios, además de marcas y especificaciones de cada una de ellas que
acordaron tanto el vendedor como el comprador. Este documento se entregará
obligatoriamente también a la aduana, y será el que sirva como base para la
declaración aduanera.
7 CIF: (Costo, Seguro y Flete) es la suma de gastos generados hasta que la mercancía llegue al puerto de
destino incluyendo los gastos del seguro, transporte y despacho.
13
f) Declaración Aduanera Simplificada (DAS): las empresas de Courier tienen la
ventaja de que tan solo necesitan pasar por los anteriores pasos, y tener esos
documentos para ya realizar la declaración aduanera, es decir no necesitan
permiso previamente de un banco como garantía o DUI (Documento Único de
Importación). Esta declaración aduanera simplificada contiene todos los
detalles de la mercadería y es entregada a la aduana.
g) Declaración Aduanera del Valor (DAV8): posteriormente se firma un juramento
escrito obligatorio, generado por la aduana en el cual el importador certifica
que el valor y peso consignados son los verdaderos. Con este se procede
desaduanizar el paquete o mercadería.
1.1.2.6.4 Proceso de Desaduananización (Nacionalización de mercadería)
a) Digitalización: después de entregar el DAV y los demás documentos (DAS,
Factura Comercial, Conocimiento de embarque) se procede a la digitalización,
donde personal de aduana ingresa los datos al sistema informático de servicio
aduanero.
b) Aforo: personal de la aduana verifica los documentos físicos con la información
ingresada en el sistema, así como la consistencia de datos y la correcta
declaración de los paquetes. Este procedimiento se lo realiza por la
verificadora, que es una empresa elegida por sorteo. Existen dos tipos de
aforo.
El aforo físico es aquel en donde se verifica la mercadería física y su
contenido, además de comparar si el peso y el contenido corresponden a lo
declarado. Si el peso excede al que está declarado en más del 10% del mismo
se considera un delito aduanero (cargos, multas y sanciones) mientras que si
excede en menos del 10% declarado en se considera solo una falta (multa
mínima). Si el peso es menor al declarado solo se tributará el que llegó.
8 DAV (Declaración Andina del Valor): es un documento soporte de la declaración de importación. En ella se
consignan toda la información técnica respecto a las condiciones y circunstancias de la operación comercial que da lugar a la importación de la mercancía, que sirven para determinar el valor aduanero de la misma.
14
El aforo documental en cambio, consiste en verificar si es que los datos
declarados coinciden con la documentación adjunta.
Al pasar por estos dos aforos si es que es el caso, se registrará una fecha de
aprobación o de aforo, además de una numeración de aprobación para la
declaración. Con esto ya podemos ir al proceso de liquidación.
1.1.2.6.5 Proceso de Liquidación
a) Determinación de Liquidación: después de pasar el aforo se determina el
monto total de tributos a pagar por el importador, tomando en cuenta los
valores de impuestos y tributos según la categorización de la mercadería,
como se muestra en la Tabla 1.2.
Categoría Subcategoría Ad Valorem9 IVA FodInfa Específico
A 0% 0% 0% B 0% 0% 0% C 20% 12% 0.5% Videojuegos 20% 12% 0.5% Incrementa
35% Perfumes 20% 12% 0.5% 200% Bebidas
alcohólicas 20% 12% 0.5% 25%
Escopetas 20% 12% 0.5% 300% ICE TV de 14 a 20
pulgadas 5% 12% 0.5% 39.97
TV de 21 a 32 pulgadas
5% 12% 0.5% 73.11
TV de 33 a 41 pulgadas
5% 12% 0.5% 140.32
TV de 42 a 50 pulgadas
5% 12% 0.5% 158.14
TV de más de 50 pulgadas
5% 12% 0.5%
D 10% 12% 0.5% E 0% 12% 0.5% F 0% 12% (En
libros 0%) 0.5%
Tabla 1.2: Valores de impuestos y tributos por categoría de mercadería de Courier
9 Ad Valorem: es un impuesto basado en el valor de un bien inmueble o mueble. Es especificado por el
reglamento de aduanas de cada país.
15
b) Papeleta de liquidación: después de calculados los valores, la aduana entrega
esa información en una papeleta para su pago posterior en los bancos
autorizados por el Ministerio de Finanzas para recaudar estos montos.
c) Pago de tributos e impuestos: después de pagar este rubro se entrega a la
aduana el comprobante, se comprueba que lo liquidado y lo pagado sean
correctos y se entrega el paquete o mercadería al importador.
1.1.3 SITUACIÓN ACTUAL
Actualmente la mayoría de empresas de Courier del Ecuador, sobretodo
medianas y pequeñas empresas, gestionan la información de cada uno de los
paquetes que envían y reciben de forma manual y mediante hojas de cálculo
Excel, así como también información de sus clientes y prospectos, contactos,
competidores y usuarios. Además, para poner en conocimiento de esta
información a todos los empleados (operadores de call center, personal de
aduana, mandos gerenciales), se la transmite por medio de correos electrónicos o
USB, lo que dificulta conocer si es que la información recibida es actualizada y si
es que no ha sido alterada o editada en medio de este proceso, es decir no se
puede garantizar la integridad de la misma. Tampoco se puede garantizar
seguridad ni confidencialidad, puesto que al transmitirla por estos medios, y no
tener un esquema de permisos y perfiles, se corre el riesgo de que esta
información pueda ser vista por terceras personas no autorizadas. Finalmente
mediante esta información no necesariamente correcta, los operadores del call
center (servicio al cliente), y la página web informan a los usuarios de la situación
de su paquete. Por ello este proceso supone falta de seguridad, integridad,
confidencialidad, disponibilidad y fiabilidad en la información, lo cual produce
pérdida de tiempo tanto para los empleados como también para los clientes.
1.1.4 PROPUESTA DE SOLUCIÓN
Se propone desarrollar un sistema web de gestión de movimiento de paquetes
para empresas de Courier, que permita tener siempre disponible y actualizada la
información de cada uno de los paquetes que son enviados por este medio. Al ser
una aplicación web, se podrá acceder desde cualquier parte del mundo a una
16
gran velocidad, y de forma simultánea (varios usuarios podrán acceder a la
información al mismo tiempo y a la misma información).
El sistema además permitirá administrar la información de clientes, prospectos de
clientes, empresas competidoras y contactos, información valiosa para este tipo
de empresas. Para garantizar la seguridad, el sistema tendrá un sistema
jerárquico de perfiles y permisos, que permitirán solo a usuarios autorizados y
mediante autenticación acceder a los diferentes módulos del sistema.
También generará reportes tanto de los paquetes como de clientes, que
contribuyan a los gerentes a la toma de decisiones, o como medio informativo.
La automatización de estos procesos permitirá a las empresas de Courier mejorar
el desempeño de sus empleados, y por ende, el servicio que ofrecen a sus
clientes.
1.2 SELECCIÓN Y JUSTIFICACIÓN DE METODOLOGÍA DE DESARROLLO
1.2.1 CARACTERÍSTICAS DEL PROYECTO
Antes de seleccionar una metodología de desarrollo, es preciso determinar
primero las características para el presente proyecto. A continuación se describen
cada una de ellas:
· Los clientes están dispuestos a colaborar: La empresa de Courier en la que se
va a realizar el caso de estudio (TransferCargoUSA) está dispuesta a
colaborar constantemente con los desarrolladores, y ofrecer toda la
información concerniente a los procesos utilizados en la misma.
· Equipo de trabajo pequeño: El equipo de desarrollo será integrado por dos
personas.
· Tiempos cortos: Es importante que el presente proyecto se lo realice en el
tiempo más corto posible.
· Requerimientos flexibles: Al estar el cliente continuamente en contacto con el
equipo de desarrollo, los requerimientos y cambios resultan constantes.
17
· Costos mínimos: El desarrollo del presente proyecto está enfocado a
pequeñas y medianas empresas de Courier, por lo que su costo no puede ser
muy elevado. Esto incluye también, un costo mínimo en herramientas.
· Entregables continuos: Es importante que el cliente pueda plasmar sus
requerimientos en tiempo mínimo y ponerlo en funcionamiento de manera
continua.
· Flexibilidad de planificación y gestión: El presente proyecto al tener la
colaboración del cliente constantemente, no necesita de una planificación
rígida y sin posibilidad de cambios. Tampoco una gestión que cumpla
excesivas reglas.
Después de explicar cada una de las características del proyecto, se determinará
la metodología que mejor se adapte. Para realizar esto, se define en primera
instancia qué es una metodología de desarrollo de software. Una metodología de
desarrollo de Software es “El conjunto de procedimientos, técnicas, herramientas
y un soporte documental que ayudan a realizar un nuevo software”. [11] Esto
contribuye ampliamente para que un proyecto tenga éxito, cumpla con plazos
acordados, y el producto finalizado de software sea de calidad. Existen dos
grandes grupos de metodologías de desarrollo de software: las tradicionales, y las
ágiles. A continuación se presentan las características de cada una de ellas.
1.2.2 METODOLOGÍAS TRADICIONALES VS ÁGILES
A continuación en la Tabla 1.3 se presentan las características de metodologías
tradicionales y ágiles, y las del proyecto. En la tabla se agrega un visto para
aquella que se alinea mejor con las características del proyecto.
Característica Proyecto Tradicionales Ágiles
Enfoque Orientado a
personas
Orientadas a los
procesos
Orientada a las personas
Adaptación a
cambios
Flexible a
cambios
Alto costo en la
realización de
cambios
Flexible a cambios
durante todo el
desarrollo del proyecto
18
de Software
Documentación Documentación
mínima
Documentación
detallada y
exhaustiva
Documentación mínima
y necesaria
Control y
gestión
No necesita
excesivas
reglas.
Tiene gran
cantidad de
normas o reglas
para
planificación,
control y gestión
de riesgo.
Posee pocas normas y
reglas. Es más abierta al
criterio de las personas a
cargo del proyecto
Planificación Plan de
proyecto
flexible y
abierto a
cambios
El proyecto se
basa en un plan
de proyecto
El proyecto no cumple
un plan de proyecto. Se
basa en los objetivos y
valor del negocio.
Ciclos Varios Fijos y limitados
Numerosos y sin límite
Tamaño de
Proyectos
Pequeño Grandes Pequeños y medianos
Tamaño del
equipo de
proyecto
Pequeño (2
personas y el
cliente)
Grandes Pequeños
Cultura de
equipo
Abierto Sujeta a mandos
de control
Compañerismo y
solidaridad
Relación con el
cliente
Con constante
contacto con el
cliente durante
el desarrollo.
Mediante
reuniones fijas,
preestablecidas y
mínimas
El cliente es parte del
equipo de desarrollo
durante todo el proyecto
Tabla 1.3: Metodologías Tradicionales vs Metodologías ágiles
19
De la Tabla 1.3 se concluye que el mejor tipo de metodología de desarrollo para el
presente proyecto es una metodología ágil.
1.2.3 SELECCIÓN DE METODOLOGÍA DE DESARROLLO ÁGIL
Para seleccionar la metodología ágil más adecuada para el presente proyecto, se
muestra en la Tabla 1.5 tomada de [12] una comparación de seis características
que se definen a continuación, calificadas de acuerdo a la Tabla 1.4 de
ponderaciones:
· Sistema como algo cambiante: esta característica se refiere a la flexibilidad y
capacidad que tendrá el sistema a ser desarrollado, para incorporar nuevos
requerimientos sobre la marcha, así como cambios de requerimientos. Como
se puede observar en la Tabla 1.5, Crystal es el que menos puntaje tiene, y
esto es porque a diferencia de las demás metodologías ágiles, Crystal no
cubre todo el ciclo de vida del proyecto, por lo que los requerimientos deben
ser cambiados o añadidos tan solo al principio del proyecto.
· Colaboración: son los valores y filosofía en los que se encuentran
interrelacionados las partes involucradas en el desarrollo de Software. Debido
a que es un principio del Manifiesto Ágil, en todas, tanto XP, Scrum, Crystal y
ASD se incluye al cliente como parte del equipo de desarrollo. Y además se
incentiva el compañerismo y la confianza.
· Resultados: los resultados se refieren al éxito del sistema desarrollado
después de aplicar la metodología. Como se observa en la Tabla 1.5, todas las
metodologías ágiles principales poseen máximo puntaje, puesto que el cliente
al colaborar y revisar sus requerimientos constantemente, en la mayoría de
casos, el sistema final satisface sus requerimientos.
· Simplicidad: es la facilidad para poner en práctica los diferentes principios,
reglas y procedimientos de una metodología. XP al tener reglas muy flexibles y
precisas, es fácil de aplicar, además la relación con el cliente es directa y
continua, por lo que tiene la calificación más alta. Scrum en cambio, al tener
20
las opiniones del cliente en reuniones periódicas (cada dos a cuatro semanas),
puede tener dificultades de comunicación o entendimiento entre las partes.
Crystal y ASD en cambio, requieren muchos responsables para la toma de
decisiones, puesto que son diseñados para equipos grandes.
· Adaptabilidad: es la capacidad que tiene una metodología para adaptarse a
nuevos cambios, y más no luchar contra ellos. XP, Scrum y Crystal tratan de
evitarlos con la comunicación continua y la intervención directa del cliente.
ASD (Adaptable Software Development) en cambio toma como principio
fundamental la adaptación a los cambios, por lo que la metodología en si está
basado en una adaptación continua a circunstancias cambiantes a lo largo del
ciclo de vida.
PONDERACIÓN DESCRIPCIÓN
1 Excelente
2 Muy buena
3 Buena
4 Regular
5 Mala
Tabla 1.4: Tabla de Ponderación
XP Scrum Crystal ASD
Sistema como algo
cambiante
5 5 4 5
Colaboración 5 5 5 5
Resultados 5 5 5 5
Simplicidad 5 4 3 3
Adaptabilidad 4 4 4 5
Total 24 23 22 23
Tabla 1.5: Características de principales metodologías ágiles
21
Se puede concluir de la Tabla 1.4, que XP10 obtiene el mayor puntaje de agilidad,
y además se adapta a las características del proyecto y experiencia de los
desarrolladores. Por tanto se escoge XP (eXtremme Programming) como
metodología para el desarrollo del presente proyecto.
1.3 SELECCIÓN Y JUSTIFICACIÓN DE HERRAMIENTAS DE DESARROLLO
En una aplicación web es necesario considerar 6 tipos de herramientas:
· DBMS
· Lenguaje de programación
· Framework de Desarrollo
· Servidor Web
· Entorno de desarrollo Integrado (IDE)
· Herramientas Case
1.3.1 SISTEMA DE GESTIÓN DE BASE DE DATOS (DBMS11)
Se ha decidido utilizar MySQL como sistema de gestión de base de datos ya que
al tener una licencia libre GNU/GPL reduce costos para el proyecto alineándose a
las características del mismo. Además es el más rápido de los DBMS open source
y sobretodo el que menos recursos utiliza. También posee aplicaciones de
terceras partes como PhpMyAdmin o MySQL Workbench que permiten al
desarrollador utilizarlo y configurarlo de manera gráfica y sencilla. En nuestro caso
utilizaremos MySQL mediante PhpMyAdmin.
1.3.2 LENGUAJE DE PROGRAMACIÓN
Se utilizará PHP12 como lenguaje de programación para la aplicación web, ya que
primeramente es un lenguaje libre 100%, lo que contribuirá a reducir costos del
proyecto y posee además óptima integración con MySQL, el motor de base de
10
XP: (eXtreme Programming) es una metodología de desarrollo ágil de la ingeniería de software formulada por Kent Beck. 11
DBMS:Database management system, es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos 12
PHP: Acrónimo de HypertextProcessor. Lenguaje de programación de lado del servidor para realizar aplicaciones web.
22
datos escogida para el proyecto. Finalmente y no menos importante, PHP es el
lenguaje que posee mayor documentación, además de su capacidad
multiplataforma y versatilidad. Por otro lado los programadores de este proyecto
tienen gran experiencia y dominio en este lenguaje.
1.3.3 FRAMEWORK DE DESARROLLO
Existen varios Frameworks13 diseñados para la utilización de PHP, que es el
lenguaje de programación que vamos a utilizar para el proyecto. A continuación
presentamos los Frameworks más utilizados para aplicaciones web con PHP.
1.3.3.1 Kohana Framework [26]
Es un Framework para aplicaciones web PHP basado en CodeIgniter. Implementa
el patrón Modelo-Vista-Controlador (MVC14). Entre las principales características
que posee son las siguientes:
· Extremadamente seguro
· Extremadamente ligero
· Mínima curva de aprendizaje
· Utiliza el patrón MVC y HMVC
· Compatibilidad UTF-8 100%
· Arquitectura con bajo acoplamiento
· Extremadamente sencillo de extender
· Programación orientada a objetos estricto
· Sencilla abstracción de base de datos mediante librerías SQL
· Múltiples drivers de sesión
· Un Poderoso gestor de eventos que permite pequeñas modificaciones
dinámicamente
13 Framework: Es 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 similar. 14
MVC: Modelo-Vista-Controlador es un patrón de arquitectura de software que separa los datos y la lógica de negocio de una aplicación de la interfaz de usuario y el módulo encargado de gestionar los eventos y las comunicaciones
23
1.3.3.2 Zend PHP [27]
Es un framework de código abierto para desarrollar aplicaciones web y servicios
web con PHP 5. ZF es una implementación que usa código 100% orientado a
objetos. La estructura de los componentes de ZF es algo único; cada componente
está construido con una baja dependencia de otros componentes. Esta
arquitectura débilmente acoplada permite a los desarrolladores utilizar los
componentes por separado. Aunque se pueden utilizar de forma individual, los
componentes de la biblioteca estándar de Zend Framework conforman un potente
y extensible framework de aplicaciones web al combinarse. ZF ofrece un gran
rendimiento y una robusta implementación MVC, una abstracción de base de
datos fácil de usar, y un componente de formularios que implementa la prestación
de formularios HTML, validación y filtrado, Empresas como Google, Microsoft y
StrikeIron se han asociado con Zend para proporcionar interfaces de servicios
web y otras tecnologías que desean poner a disposición de los desarrolladores de
Zend Framework.
1.3.3.3 Symfony [28]
Symfony es un completo framework diseñado para optimizar el desarrollo de las
aplicaciones web basado en el patrón Modelo Vista Controlador. Para empezar,
separa la lógica de negocio, la lógica de servidor y la presentación de la
aplicación web. Proporciona varias herramientas y clases encaminadas a reducir
el tiempo de desarrollo de una aplicación web compleja. Además, automatiza las
tareas más comunes, permitiendo al desarrollador dedicarse por completo a los
aspectos específicos de cada aplicación. El resultado de todas estas ventajas es
que no se debe reinventar la rueda cada vez que se crea una nueva aplicación
web. Symfony está desarrollado completamente en PHP 5.3. Ha sido probado en
numerosos proyectos reales y se utiliza en sitios web de comercio electrónico de
primer nivel. Symfony es compatible con la mayoría de gestores de bases de
datos, como MySQL, PostgreSQL, Oracle y Microsoft SQL Server.
24
1.3.3.4 Kohana Framework vs Zend PHP vs Symfony
A continuación mediante la Tabla 1.6 se expone los principales aspectos
concernientes al desarrollo del proyecto, con su calificación respectiva de acuerdo
a la tabla de ponderación en la Tabla 1.4:
Kohana Zend PHP Symfony
Orientación a
objetos
5 5 5
Paradigma MVC 5 5 5
Facilidad de
sentencias SQL
5 3 4
Facilidad de
utilización
5 2 4
Facilidad de
configuración
4 2 4
Experiencia de
los
programadores
5 3 0
Total 29 20 22
Tabla 1.6: Kohana vs Zend PHP vs Symfony
Debido a los puntajes obtenidos en la Tabla 1.5, se ha escogido Kohana
Framework PHP para desarrollar el proyecto. Cabe destacar que los aspectos en
los que más difiere a los otros dos Frameworks es su facilidad de configuración y
utilización, así como la experiencia que se posee en este Framework.
1.3.4 SERVIDOR WEB15
Puesto que el lenguaje de programación seleccionado para la aplicación es PHP
con Kohana Framework; se usará como servidor web Apache ya que es el más
15
Servidor Web: Es un programa informático que procesa una aplicación del lado del servidor realizando conexiones bidireccionales y/o unidireccionales y síncronas o asíncronas con el cliente generando una respuesta en cualquier lenguaje o Aplicación del lado del cliente.
25
afín a PHP, es libre (reduce costos del proyecto), y además es independiente del
sistema operativo en el cual se lo utilice.
1.3.5 ENTORNO DE DESARROLLO INTEGRADO (IDE)
Los IDEs son software que ayudan al programador a tareas como la codificación,
depuración y corrección de errores de código. Así pues se ha escogido Netbeans
IDE 6.9 puesto que permite trabajar en cualquier tipo de plataforma, ya sea
Windows o Linux, además de tener varias utilidades para la codificación en PHP.
1.3.6 HERRAMIENTAS CASE16
Se utilizará StarUML para el diseño y modelado de los distintos diagramas. Esta
herramienta tiene la ventaja que contempla los estándares y sintaxis de UML17.
Además es una herramienta libre, por lo que no representa costos adicionales al
proyecto.
1.4 PRESUPUESTO GENERAL DEL SISTEMA
Para el presupuesto general del sistema se han tomado en cuenta todos los
factores que inciden en el desarrollo del proyecto, que son los siguientes:
· Recursos Humanos: estos costos incluyen la mano de obra y servicios de los
involucrados en el desarrollo del proyecto. Los cálculos de costos del
personal, son basados en sueldos mensuales promedio en el mercado
ecuatoriano, tomando como referencia que el proyecto durará 60 días
laborables y por tanto 240 horas. Para el presente proyecto estos costos se
muestran en la Tabla 1.7:
16
Herramienta Case: (Ingeniería de Software Asistida por Computadora) son diversas aplicaciones informáticas destinadas a aumentar la productividad en el desarrollo de software reduciendo el costo de tiempo y dinero 17
UML: Son las siglas de UnifiedModelingLanguage.Es un lenguaje de modelado de sistemas de software respaldado por elOMG (Object Management Group).
26
Valor hora trabajo
Cantidad (horas) Total
Jefe de proyecto $ 12,50 240,00 $ 3000,00 Desarrollador Master $ 4,375 240,00 $ 1050,00
Total $ 4.050 Tabla 1.7: Presupuesto de Recursos Humanos
· Gastos Administrativos: estos costos incluyen los viáticos y alimentación
utilizados a lo largo del desarrollo del proyecto. A continuación en la Tabla 1.8
se presenta el detalle de estos gastos. Para el cálculo se toma en cuenta los
20 días laborales de duración del proyecto :
Valor Unitario
Cantidad (días) Total
Viáticos $ 1,50 60,00 $ 90,00 Almuerzos $ 3,00 60,00 $ 180,00
Total $ 270,00 Tabla 1.8: Presupuesto de Gastos Administrativos
· Hardware: dentro de este presupuesto se incluye el costo de los equipos
utilizados para el desarrollo del proyecto, dicho costo se ve reflejado en la
Tabla 1.9:
Valor Unitario Cantidad Total
Impresora $ 200,00 1,00 $ 200,00 Computadores $ 750,00 2,00 $ 1.500,00
Total $ 1.700,00 Tabla 1.9: Presupuesto de Gastos en Hardware
· Software: estos gastos incluyen costos de licencias y soporte, que se
presentan en la Tabla 1.10 :
Valor Unitario Cantidad Total Razón
Kohana Framework PHP $ 0,00 1,00 $ 0,00 Licencia BSD (Libre) Servidor web Apache $ 0,00 1,00 $ 0,00 Licencia Apache (Libre) DBMS MySQL $ 0,00 1,00 $ 0,00 Licencia GNU GPL StarUML $ 0,00 1,00 $ 0,00 Licencia GNU GPL
Total $ 0,00 Tabla 1.10: Presupuesto de Gastos en Software
27
· Insumos: en esta categoría se incluyen los gastos de servicios básicos y de
gastos que no intervienen directamente en el desarrollo del proyecto. En la
Tabla 1.11 se muestra el detalle de este tipo de gasto.
Valor Unitario
Cantidad (meses) Total
Energía $ 25,00 1,50 $ 37,50 Agua $ 5,00 1,50 $ 7,50 Oficina (CDs,papelería,etc) $ 20,00 3,00 $ 60,00 Teléfono e internet $ 30,00 3,00 $ 90,00
Total $ 195,00 Tabla 1.11: Presupuesto de Gasto en Insumos.
En la Tabla 1.12 se muestra el presupuesto general del proyecto tomando en
cuenta los gastos antes detallados. Es importante tomar en cuenta que los totales
no incluyen impuestos y tampoco gastos por imprevistos.
Total
Recursos Humanos $ 4.050,00 Administrativos $ 270,00 Hardware $ 1.700,00 Software $ 0,00 Insumos $ 195,00 Valor Neto $ 6.215,00 Utilidad (Con fines académicos) 0%
$ 0,00
Total $ 6.215,00 Utilidad (Con fines comerciales) 30%
$ 1.864.5
Total comercial $ 8079,50 Tabla 1.12: Presupuesto General del Sistema
28
2. CAPÍTULO II: DESARROLLO DEL SISTEMA
2.1 REQUERIMIENTOS
Los requerimientos han sido extraídos de reuniones continuas con cada uno de
los usuarios que van a utilizar el sistema, con lo que se ha podido determinar 12
historias de usuarios agrupadas en módulos y administraciones.
2.1.1 USUARIOS DEL SISTEMA
En las reuniones con mandos gerenciales en una empresa de Courier, y tomando
en consideración las necesidades globales de este tipo de empresas, se ha
determinado los usuarios del mismo. Los cuales serán los beneficiarios de las
funcionalidades del sistema.
2.1.1.1 Administrador
Es el usuario encargado de configurar y gestionar todo el sistema para poder
utilizar la gestión de movimiento de paquetes. Así entonces podrá administrar
usuarios, perfiles de usuarios, competidores empresariales, contactos, clientes,
prospectos de clientes, tipos de carga, agentes destinatarios y promociones.
También podrá utilizar la gestión de movimiento de paquetes y generar reportes.
2.1.1.2 Gerente
Es el encargado de ingresar nuevos usuarios al sistema, con su respectiva
información, y además de asignarle el perfil que crea conveniente. A diferencia del
administrador, no podrá dar de baja a usuarios, ni tampoco administrar los perfiles
de usuarios. Si podrá utilizar las demás administraciones y generar reportes.
2.1.1.3 Operador de Call Center (Servicio al Cliente)
Es el encargado de informarle al cliente la información acerca de su paquete. Por
tanto tendrá acceso a la gestión de movimiento de paquetes, pero solo podrá
observar la información, más no modificarla o borrarla. Tendrá acceso también a
la administración de clientes y reportes.
29
2.1.1.4 Operador de Call Center (Publicidad)
Es el encargado de ingresar nuevos prospectos de clientes y clientes, así como
ingresar observaciones acerca de los mismos.
2.1.2 HISTORIAS DE USUARIO
Las historias de usuario suelen ser una parte central de las metodologías de
desarrollo ágil, en este caso XP. Se toman en cuenta parámetros básicos e
importantes para el desarrollo, tales como riesgo y esfuerzo según referencia
bibliográfica [35], la cual cuenta también con una buena definición del formato de
historias de usuario. Es así que se tienen los siguientes conceptos:
· Riesgo: se pueden mencionar el uso de tecnología desconocida y
restricción en disponibilidad de recursos humanos, de hardware o software.
· Esfuerzo: es un cálculo basado en puntos, que corresponden a semanas
ideales de trabajo, tomando en cuenta el esfuerzo asociado a pruebas
unitarias, integración de módulos, pruebas de aceptación y refactorización
del código.
Cada historia de usuario, en el formato definido en [35], deben contener los
siguientes elementos:
· Número: identificador numérico de la historia de usuario.
· Nombre: denominación que se le da a la historia de usuario para facilitar su
posterior identificación.
· Usuario: es el encargado dentro del sistema quien realizará las
operaciones detalladas en las historias de usuario.
· Riesgo en Desarrollo: se basa en el riesgo que enfrenta el equipo de
desarrollo en la obtención de resultados de una historia de usuario, para
que satisfaga los requerimientos del cliente. Puede ser alto, medio o bajo.
· Prioridad en Negocio: definido por el cliente, es el grado de prioridad para
el desarrollo de cada historia de usuario.
· Puntos Estimados: puntos de esfuerzo determinado por la duración de
desarrollo de la historia de usuario.
· Descripción: explicación del requerimiento expresado en la historia de
usuario. Puede ser susceptible a cambios durante la etapa de desarrollo.
30
· Observaciones: puntos que describan o aclaren la descripción y la historia
de usuario en sí.
2.1.2.1 Gestión Administrativa
Historia de Usuario
Número: 01 Nombre de funcionalidad: Administración de Perfiles
Usuario: Administrador Puntos Estimados: 0,2 Riesgo en Desarrollo: Medio (Alta/Media/Baja)
Prioridad en el negocio: Alta (Alta/Media/Baja)
Descripción: el administrador del sistema tendrá acceso para crear, modificar o desactivar perfiles de usuario, estos perfiles se definirán mediante accesos a diferentes funcionalidades, definidas en la creación de un nuevo perfil.
Observaciones: la administración de perfiles no necesita la creación previa de algún otro elemento. Se definen las funcionalidades generales como Administración, Gestión de Carga y Reportes, cada una con sus funcionalidades específicas.
Tabla 2.1: Historia de Usuario – Administración de Perfiles
Historia de Usuario
Número: 02 Nombre de funcionalidad: Administración de Usuarios
Usuario: Administrador Puntos Estimados: 0,6 Riesgo en Desarrollo: Medio (Alta/Media/Baja)
Prioridad en el negocio: Alta (Alta/Media/Baja)
Descripción: el administrador del sistema tendrá acceso para crear, modificar o desactivar usuarios, estos usuarios se definirán mediante un nombre y la asignación de un perfil previamente creado.
Observaciones: se necesita por lo menos un perfil creado para poder crear un usuario.
Tabla 2.2: Historia de Usuario – Administración de Usuarios.
Historia de Usuario
Número: 03 Nombre de funcionalidad: Administración de Contactos
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,6 Riesgo en Desarrollo: Bajo (Alta/Media/Baja)
Prioridad en el negocio: Media (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá la facultad de crear, modificar o desactivar contactos relacionados con la empresa.
Observaciones: se entiende como contactos a las personas naturales o jurídicas de las cuales se necesitan información para usarla como medio de difusión de promociones o contratación de servicios externos en el presente o futuro próximo.
Tabla 2.3: Historia de Usuario – Administración de Contactos.
31
Historia de Usuario
Número: 04 Nombre de funcionalidad: Administración de Competencia
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,2 Riesgo en Desarrollo: Bajo (Alta/Media/Baja)
Prioridad en el negocio: Baja (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá la facultad de crear, modificar o desactivar registros de competencia.
Observaciones: se entiende como competencia a las personas naturales o jurídicas que ofrecen los mismos servicios o productos, de las cuales se necesitan información relacionada a éstos.
Tabla 2.4: Historia de Usuario – Administración de Competencia.
Historia de Usuario
Número: 05 Nombre de funcionalidad: Administración de Clientes
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,8 Riesgo en Desarrollo: Alto (Alta/Media/Baja)
Prioridad en el negocio: Alta (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá la facultad de crear, modificar o desactivar clientes.
Observaciones: se entiende como cliente a las personas naturales o jurídicas las cuales han realizado alguna compra en la empresa y de las cuales se tienen datos y documentos importantes para agilitar tramites, por ejemplo copias de cédula, pasaporte, RUC, etc.
Tabla 2.5: Historia de Usuario – Administración de Clientes.
Historia de Usuario
Número: 06 Nombre de funcionalidad: Administración de Prospectos
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,8 Riesgo en Desarrollo: Medio (Alta/Media/Baja)
Prioridad en el negocio: Alta (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá la facultad de crear, modificar o desactivar prospectos.
Observaciones: se entiende como prospecto a las personas naturales o jurídicas las cuales han mostrado algún tipo de interés en los servicios de la empresa, no es obligatorio llenar todos los campos de datos, además un prospecto tiene la facilidad de convertirse en cliente.
Tabla 2.6: Historia de Usuario – Administración de Prospectos.
32
2.1.2.2 Gestión de Carga
Historia de Usuario
Número: 07 Nombre de funcionalidad: Administración de Tipos de Carga
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,2 Riesgo en Desarrollo: Bajo (Alta/Media/Baja)
Prioridad en el negocio: Media (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá la facultad de crear, modificar o desactivar diversos tipos de carga.
Observaciones: se entiende como tipo de carga al tipo de contenido que llevan los paquetes, es decir puede ser un paquete normal, frágil o delicado, depende las necesidades del usuario pueden crearse el número de tipos de carga que desee.
Tabla 2.7: Historia de Usuario – Administración de Tipos de Carga.
Historia de Usuario
Número: 08 Nombre de funcionalidad: Admin. de Agentes Destinatarios
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,2 Riesgo en Desarrollo: Bajo (Alta/Media/Baja)
Prioridad en el negocio: Media (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá acceso para crear, modificar o desactivar agentes destinatarios.
Observaciones: se entiende como agente destinatario a las personas naturales o jurídicas quienes reciben los diferentes paquetes en sus oficinas antes de ser enviados a su destino final. Estos agentes destinatarios son empresas aliadas que permiten el descongestionamiento de recepción y envío de paquetes.
Tabla 2.8: Historia de Usuario – Administración de Agentes Destinatarios.
Historia de Usuario
Número: 09 Nombre de funcionalidad: Administración de Promociones
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,2 Riesgo en Desarrollo: Bajo (Alta/Media/Baja)
Prioridad en el negocio: Baja (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá acceso para crear, modificar o desactivar promociones.
Observaciones: se entiende como promoción como la preparación de las condiciones óptimas para dar un artículo a conocer o para incrementar las ventas. Generalmente son creadas en fechas especiales.
Tabla 2.9: Historia de Usuario – Administración de Promociones.
33
Historia de Usuario
Número: 10 Nombre de funcionalidad: Administración de Paquetes
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 1,4 Riesgo en Desarrollo: Alto (Alta/Media/Baja)
Prioridad en el negocio: Alta (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá acceso para crear, modificar o desactivar paquetes. Se toma en cuenta que en la modificación de paquetes es necesario manejar los diferentes estados por los que atraviesa el paquete.
Observaciones: se entiende como paquete al artículo que se transporta y se entrega al cliente solicitante. Estos paquetes son el objetivo de la actividad económica de la empresa. Se entiende como estado del paquete al lugar o trámite en donde se encuentra el paquete.
Tabla 2.10: Historia de Usuario – Administración de Paquetes.
2.1.2.3 Gestión de Reportes
Historia de Usuario
Número: 11 Nombre de funcionalidad: Reporte de Clientes/Prospectos
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,6 Riesgo en Desarrollo: Medio (Alta/Media/Baja)
Prioridad en el negocio: Media (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá acceso para crear un reporte de clientes/prospectos definido por un rango de fechas de creación, país, tipo (cliente o prospecto) y estado (activo o inactivo).
Observaciones: el reporte debe ser traducido a un archivo Excel o PDF para que pueda ser manipulado o impreso.
Tabla 2.11: Historia de Usuario – Reporte de Clientes/Prospectos.
Historia de Usuario Número: 12 Nombre de funcionalidad: Reporte de Carga
Usuario: Administrador y Usuarios con perfil asignado.
Puntos Estimados: 0,6
Riesgo en Desarrollo: Medio (Alta/Media/Baja)
Prioridad en el negocio: Media (Alta/Media/Baja)
Descripción: el administrador del sistema o usuario con permisos adecuados tendrá acceso para crear un reporte de carga definido por los siguientes campos de filtrado: Cliente, Usuario que registró el paquete, agente destinatario, tipo de carga, promoción y estado del paquete .
Observaciones: el reporte debe ser traducido a un archivo Excel o PDF para que pueda ser manipulado o impreso.
Tabla 2.12: Historia de Usuario – Reporte de Carga.
34
2.2 ANÁLISIS
Una vez definidas las funcionalidades del sistema mediante historias de usuario,
se debe realizar un análisis en cuanto se refiere a tiempo y esfuerzo requeridos a
lo largo del desarrollo del proyecto, mediante este análisis podemos obtener una
estimación muy próxima a la realidad de los recursos necesarios para cumplir con
los objetivos y requerimientos planteados en cada una de las historias de
usuarios.
De acuerdo a la metodología que se está utilizando (XP), es necesario una
continua comunicación y colaboración entre el equipo de desarrollo y el cliente,
obteniendo de esta manera retroalimentación constante para que los objetivos se
cumplan siempre acorde al deseo del cliente.
2.2.1 ESTIMACIÓN DE ESFUERZO
A continuación se tiene un listado de aspectos importantes que permitirán una
mejor estimación de tiempo y esfuerzo realizado en el desarrollo del proyecto.
Estos aspectos se manejan de forma general de acuerdo a la metodología XP y a
la experiencia del grupo de desarrollo, y se complementan con otros definidos en
la referencia bibliográfica [35]:
· La jornada de trabajo será de 4 horas al día (Medio tiempo).
· El calendario de trabajo semanal se establece en 5 días laborables.
· El equipo de desarrollo está conformado por dos personas.
· Un punto estimado es considerado como una semana de trabajo para el
equipo de desarrollo.
· El riesgo es considerado como criterio del equipo de desarrollo y trata de
valorar las complicaciones que pueden presentarse.
· La prioridad es igualmente una valoración de la importancia que tiene la
historia de usuario para el cliente.
En la Tabla 2.13 se observa la estimación de esfuerzo realizado para el desarrollo
de la aplicación. Este formato de tabla es un complementario entre los que están
definidos en las referencias bibliográficas [35] y [36]:
35
No.
Historia Nombre Historia Riesgo Prioridad
Puntos
Estimados
(1 pto = 1
semana)
Tiempo
(días
medio
tiempo)
01 Administración de Perfiles Medio Alta 0,4 2
02 Administración de Usuarios Medio Alta 1,2 6
03 Administración de Contactos Bajo Media 1,2 6
04 Administración de Competencia Bajo Baja 0,4 2
05 Administración de Clientes Alto Alta 1,6 8
06 Administración de Prospectos Medio Alta 1,6 8
07 Administración de Tipos de Carga Bajo Media 0,4 2
08 Admón. de Agentes Destinatarios Bajo Media 0,4 2
09 Administración de Promociones Bajo Baja 0,4 2
10 Administración de Paquetes Alto Alta 2,0 10
11 Reporte de Clientes/Prospectos Medio Media 1,2 6
12 Reporte de Carga Medio Media 1,2 6
Tabla 2.13: Estimación de Esfuerzos
2.2.2 PRIORIZACIÓN
Se definen presumiblemente las iteraciones del proyecto y qué historias de
usuarios van en cada una de ellas. Para establecer dichas iteraciones se toman
en cuenta el esfuerzo realizado, el costo en tiempo, la prioridad que tiene en la
empresa y el riesgo que se genera en el proceso de desarrollo. En la Tabla 2.14
se han clasificado las historias de usuario agrupadas por iteración:
Nº Historia
Nombre Historia Iteración
01 Administración de Perfiles 1
02 Administración de Usuarios 1
03 Administración de Contactos 1
04 Administración de Competencia 1
07 Administración de Tipos de Carga 2
08 Admón. de Agentes Destinatarios 2
36
09 Administración de Promociones 2
05 Administración de Clientes 2
06 Administración de Prospectos 2
10 Administración de Paquetes 3
11 Reporte de Clientes/Prospectos 3
12 Reporte de Carga 3
Tabla 2.14: Priorización de historias de usuario.
2.2.3 PLAN DE ENTREGAS
Para cada historia de usuario, además de tener asignada una iteración tentativa,
es importante determinar rangos de fechas en los cuales se van cumpliendo los
objetivos. En este caso se toma en cuenta que todas las historias de usuario se
realizarán de manera secuencial, pero dado el caso se pueden llegar a hacer
simultáneamente consiguiendo así, la reducción del tiempo total de desarrollo.
En la Tabla 2.15 se observa los detalles de las fechas asignadas para cada
historia de usuario.
Nº Historia
Nombre Historia Iteración Fecha Inicio Fecha Fin
01 Administración de Perfiles 1 01/07/2013 02/07/2013
02 Administración de Usuarios 1 03/07/2013 10/07/2013
03 Administración de Contactos 1 11/07/2013 18/07/2013
04 Administración de Competencia 1 19/07/2013 22/07/2013
07 Administración de Tipos de Carga 2 23/07/2013 24/07/2013
08 Admin. de Agentes Destinatarios 2 25/07/2013 26/07/2013
09 Administración de Promociones 2 29/07/2013 30/07/2013
05 Administración de Clientes 2 31/07/2013 09/08/2013
06 Administración de Prospectos 2 12/08/2013 21/08/2013
10 Administración de Paquetes 3 22/08/2013 04/09/2013
11 Reporte de Clientes/Prospectos 3 05/09/2013 12/09/2013
12 Reporte de Carga 3 13/09/2013 19/09/2013
Tabla 2.15: Plan de Entregas.
37
2.3 DISEÑO
2.3.1 DISEÑO ARQUITECTÓNICO DEL SISTEMA
Para el presente proyecto se utilizará un diseño arquitectónico que se ajuste con
el desarrollo web. Para ello se ha escogido una arquitectura de tres capas MVC
(Modelo Vista Controlador), que consiste en una especialización de la arquitectura
Cliente – Servidor. Además es la arquitectura utilizada por Kohana PHP
Framework, el framework escogido para el desarrollo del presente proyecto. Tiene
como principal ventaja la reutilización de código y la separación de conceptos en
el código, características que facilitan la organización y posterior mantenimiento
de código.
2.3.1.1 Arquitectura MVC (Modelo – Vista – Controlador)
· Modelo: es la representación de la información con la cual el sistema opera,
por lo tanto gestiona todos los accesos a dicha información y las bases de
datos, tanto consultas como actualizaciones, implementando también los
privilegios de acceso que se hayan descrito en las especificaciones de la
aplicación. Envía a la vista aquella parte de la información que en cada
momento se le solicita para que sea mostrada. Para el presente proyecto se
utilizará ORM18 (Object-Relational Mapping), integrado en Kohana Framework,
para realizar las llamadas a la base de datos MySQL.
· Controlador: responde a eventos (usualmente acciones del usuario) e invoca
peticiones al modelo cuando se hace alguna solicitud sobre la información (por
ejemplo, editar un documento o un registro en una base de datos). También
puede enviar comandos a su vista asociada si se solicita un cambio en la
forma en que se presenta de modelo, por tanto se podría decir que el
controlador hace de intermediario entre la vista y el modelo. Kohana
Framework, utiliza clases y controladores escritos en PHP.
18
ORM: Object-Relational mapping, es una técnica de programación para convertir datos entre el sistema de tipos utilizado, en un lenguaje de programación orientado a objetos y la utilización de una base de datos relacional, utilizando un motor de persistencia.
38
· Vista: presenta el modelo (información) en un formato adecuado para
interactuar, usualmente la interfaz de usuario. Para el presente proyecto se
utilizará HTML, CSS y librerías javascript (jQuery).
Así entonces en la Figura 2.1 se ilustra la arquitectura MVC utilizado en el
desarrollo del presente proyecto:
Navegador web
Figura 2.1: Arquitectura MVC del sistema
2.3.2 TARJETAS CRC
Las tarjetas CRC fueron propuestas por Kent Beck y Ward Cunningham y
representan objetos; la clase a la que pertenece el objeto se escribe arriba de
cada tarjeta, las responsabilidades u objetivos que debe llevar a cabo el objeto se
escriben a la izquierda, y la derecha las clases que se relacionan con dicho
objeto. Su gran ventaja es que permite estimar si el conjunto de clases obtenida
hasta este punto (o versiones posteriores del mismo) responden bien a las
necesidades del sistema, y además estas se convierten en una aproximación para
el diagrama de clases. [37]
Servidor Web CONTROLADOR
(PHP)
VISTA (PHP, JQuery,
HTML, Javascript, AJAX)
MODELO (PHP, ORM)
Base de Datos (MySQL)
39
2.3.2.1 TARJETAS CRC DEL SISTEMA
CLIENTE
RESPONSABILIDADES COLABORADORES Atributos:
· Id · Código · Número de Identificación (CI, pasaporte) · Nombres · Apellidos · Nombre del representante legal (Si es que
es empresa) · Apellido del representante legal (Si es que
es empresa) · Teléfono del representante legal (Si es
que es empresa) · Ciudad · País · Dirección · Teléfono · Email · Código Postal · Datos Adjuntos · Estado (Activado, desactivado) · Tipo (Cliente ó prospecto) · Fecha de Creación
Operaciones · Ver Cliente · Actualizar Cliente · Consultar Cliente
· Paquete · Usuario · Observación
Tabla 2.16: Tarjeta CRC - Cliente
OBSERVACIÓN RESPONSABILIDADES COLABORADORES
Atributos: · Id · Observación · Estado · Razón · Fecha de Creación · Fecha de Recordatorio · Número de Cotización · Promoción
Operaciones · Ver observación
· Cliente · Usuario · Promoción
Tabla 2.17: Tarjeta CRC - Observación
40
COMPETIDOR
RESPONSABILIDADES COLABORADORES Atributos:
· Id · Nombre · Ciudad · País · Dirección · Teléfono · Email · Observación · Datos Adjuntos · Fecha de Creación
Operaciones · Ingresar Competidor · Actualizar Competidor · Eliminar Competidor · Consultar Competidor
· Usuario
Tabla 2.18: Tarjeta CRC - Competidor
CONTACTO RESPONSABILIDADES COLABORADORES
Atributos: · Id · Nombre · Ciudad · País · Dirección · Teléfono · Email · Observación · Fecha de Creación
Operaciones · Ingresar Contacto · Actualizar Contacto · Eliminar Contacto · Consultar Contacto
· Usuario
Tabla 2.19: Tarjeta CRC - Contacto
AGENTE DESTINATARIO
RESPONSABILIDADES COLABORADORES Atributos:
· Id · Nombre · Dirección · Email
· Paquete
41
· Teléfono · Observaciones · Fecha de Creación · Estado
Operaciones: · Ver Agente Destinatario · Crear Agente Destinatario · Actualizar Agente Destinatario · Desactivar Agente Destinatario
Tabla 2.20: Tarjeta CRC – Agente Destinatario
PROMOCIÓN RESPONSABILIDADES COLABORADORES
Atributos: · Id · Nombre · Descripción · Estado
Operaciones: · Consultar Promoción · Crear Promoción · Actualizar Promoción · Desactivar Promoción
· Paquete
Tabla 2.21: Tarjeta CRC – Promoción
TIPO DE CONTENIDO RESPONSABILIDADES COLABORADORES
Atributos: · Id · Nombre · Prefijo · Estado
Operaciones: · Consultar Tipo de Contenido · Crear Tipo de Contenido · Actualizar Tipo de Contenido · Desactivar Tipo de Contenido
· Paquete
Tabla 2.22: Tarjeta CRC – Tipo de Contenido
PAQUETE RESPONSABILIDADES COLABORADORES
Atributos: · Id · Código
· Cliente · Agente Destinatario
42
· Descripción · Cliente · Agente Destinatario · Promoción · Tipo de Contenido · Usuario · Fecha de Creación · Fecha de embarque · Número de cajas en embarque · Guía de embarque · Fecha de arribo · Número de cajas arribo · Fecha en aduana · Número de refrendo · Fecha en aforo · Fecha en liquidación de impuestos · Número de comprobante de
liquidación · Fecha de pago de impuestos · Fecha en Bodegas · Fecha de pago de cliente · Fecha de despacho a cliente · Estado del paquete
Operaciones:
· Consultar Paquetes · Ingresar Paquete · Ver Paquete · Actualizar Paquete · Cargar formulario de embarque · Cargar formulario de arribo · Cambiar estado · Cambiar estado múltiple · Cambiar a estado previo · Cambiar a estado previo múltiple
· Usuario · Tipo de Contenido
Tabla 2.23: Tarjeta CRC - Paquete
USUARIO RESPONSABILIDADES COLABORADORES
Atributos: · Id · Nombre de Usuario · Contraseña · Identificación · Nombre · Apellido · Ciudad · Dirección · Celular
· Perfil · Paquete · Cliente
43
· Teléfono · Email · Estado · Fecha de Creación
Operaciones: · Autenticar · Permitir Acceso · Ver Usuarios · Crear usuario · Actualizar usuario · Desactivar Usuario
Tabla 2.24: Tarjeta CRC - Usuario
PERFIL
RESPONSABILIDADES COLABORADORES Atributos:
· Id · Nombre · Estado
Operaciones: · Ver Perfiles · Crear Perfil · Actualizar Perfil · Desactivar Perfil · Cargar acción
· Usuario
Tabla 2.25: Tarjeta CRC – Perfil
2.3.3 DIAGRAMA DE CLASES
El diagrama de clases sirve para visualizar las relaciones entre las clases que
posee el sistema, además de mostrar cada uno de los atributos y métodos de
cada clase. A continuación se explica cada uno de los elementos que conforman
un diagrama de clases, así como la sintaxis utilizada. [38]
2.3.3.1 Elementos y sintaxis de un diagrama de clases
2.3.3.1.1 Clase
Una clase es un elemento que define los atributos y comportamientos que un
objeto podrá generar. Las clases se representan por rectángulos que muestran el
nombre de la clase y opcionalmente el nombre de las operaciones y atributos.
44
2.3.3.1.2 Atributos
Son las características propias de cada clase, cada uno de ellos puede tener
distinto nivel de acceso y un tipo de dato. A continuación en la Tabla 2.25 se
muestra la notación UML de los distintos niveles de acceso:
Notación UML Nivel de Acceso Descripción
+ Público (Public) Son accesibles desde cualquier clase.
- Privado (Private) Son accesibles solo desde la misma clase
donde fueron declarados.
# Protegido (Protected) Son accesibles desde la misma clase que
donde fueron declarados y en sus subclases.
Tabla 2.26: Nivel de acceso
En PHP, los atributos por defecto son declarados como públicos. En Kohana
Framework al utilizar ORM en cambio, los declara por defecto como protegidos.
Por ejemplo: # nombre
2.3.3.1.3 Métodos
Los métodos son la forma en cómo una clase interactúa con su entorno, se
muestran al menos con su nombre y nivel de acceso. Al igual que los atributos, el
nivel de acceso puede ser prívate, public o protected, como se expone en la Tabla
2.25. En PHP, los métodos por defecto son declarados como públicos.
Por ejemplo: + PermitirAcceso()
2.3.3.1.4 Relaciones
Implica que dos elementos del modelo tienen una relación usualmente
implementada como una variable de instancia de una clase. Este conector puede
incluir roles nombrados en cada extremo, cardinalidad, dirección y restricciones
dependiendo el tipo de relación. [39]
Las clases se puede relaciones (estar asocionadas) con otras de diferentes
maneras:
· Generalización: La generalización es uno de los conceptos fundamentales de
la programación orientada a objetos, en la que una clase «recoge» todos los
atributos y operaciones de la clase de la que es heredera, y puede
45
alterar/modificar algunos de ellos, así como añadir más atributos y
operaciones propias. En UML, las generalizaciones se representan por medio
de una línea que conecta las dos clases, con una flecha en el lado de la clase
base como se muestra en el ejemplo de la Figura 2.2:
Figura 2.2: Ejemplo de Generalización con UML
· Asociación: representa una relación entre clases, y aporta la semántica común
y la estructura de muchos tipos de «conexiones» entre objetos, pueden tener
un papel que especifica el propósito de la asociación y pueden ser
unidireccionales o bidireccionales. Cada extremo de la asociación también
tiene un valor de cardinalidad. La cardinalidad esta dado según la Tabla 2.26:
·
Notación UML Descripción
1...* Uno o muchos
0..* Cero o muchos
m (m denota un
número)
Número fijo
Tabla 2.27: Cardinalidad en UML
Las asociaciones se representan por medio de líneas que conectan las clases
participantes en la relación, con su respectiva cardinalidad. [40] Como se
muestra en el ejemplo de la Figura 2.3:
Figura 2.3: Ejemplo de Asociación con UML
PersonaExterna
Contacto Competidor
Paquete Tipo de Contenido0..* 1
46
· Composición / Agregación: Cuando se requiere componer objetos que son
instancias de clases definidas por el desarrollador de la aplicación, tenemos
dos posibilidades:
o Por Valor (Composición): Es un tipo de relación estática, en donde el
tiempo de vida del objeto incluido está condicionado por el tiempo de
vida del que lo incluye. En UML son representados por un rombo
pintado, como se observa en el ejemplo de la Figura 2.4.
Opcionalmente pueden tener cardinalidad.
Figura 2.4: Ejemplo de Composición con UML
o Por Referencia (Agregación): Es un tipo de relación dinámica, en donde
el tiempo de vida del objeto incluido es independiente del que lo incluye.
En UML son representados por un rombo transparente, como se
observa en el ejemplo de la Figura 2.5. Opcionalmente pueden tener
cardinalidad.
Figura 2.5: Ejemplo de Agregación con UML
· Dependencia: Representa un tipo de relación en la que una clase es
dependiente de otro objeto/clase para su instanciación. Se denota por una
flecha punteada. [41]
Figura 2.6: Ejemplo de Dependencia con UML
Perfil Acción
0..*1
Paquete Cliente1 1
Factura.. Encabezado Factura
47
2.3.3.2 Diagrama de Clases del Sistema
Después de analizar las tarjetas CRC (Clase – Responsabilidad – Colaboración ),
y además tener definida la sintaxis UML para el diagrama de clases, se obtiene el
diagrama de clases del sistema mostrado en el Figura 2.7:
Figura 2.7: Diagrama de Clases del Sistema
48
2.3.4 DIAGRAMA FÍSICO DE LA BASE DE DATOS
Según el diagrama de clases, se ha elaborado el diagrama físico de la base de
datos que se muestra en la Figura 2.8, con las siguientes consideraciones en
base a los requerimientos específicos del cliente:
· Deben existir múltiples teléfonos, direcciones, emails y archivos adjuntos para
clientes.
· Los países son precargados, y estarán disponibles para escogerlos en todas
las administraciones cuando se los requiera.
· Para el presente proyecto no se tomaran en cuenta a contactos ni
competidores, ya que no intervienen en la gestión de movimiento de paquetes
· El idioma para los campos de bases de datos, deberá ser en inglés, al igual
que las variables y métodos en el código de programación.
Este diagrama además se lo puede encontrar en el Anexo digital II, para una
mejor visualización.
49
Figura 2.8: Diagrama Físico de la Base de Datos
use
r
id pro
_id
cou
_id
use
rna
me
pa
ssw
ord
do
cum
en
td
ocu
me
nt_
typ
efi
rstn
am
ela
stn
am
eci
tya
dd
ress
ph
on
em
ob
ile
ma
ilst
atu
scr
ea
te_
da
te
int
int
int
varc
ha
r(1
00
)va
rch
ar(
10
0)
varc
ha
r(1
5)
EN
UM
('C','
O')
varc
ha
r(2
55
)va
rch
ar(
25
5)
varc
ha
r(2
55
)va
rch
ar(
25
5)
varc
ha
r(1
5)
varc
ha
r(1
5)
varc
ha
r(2
55
)E
NU
M('A
CT
IVE
','IN
AC
TIV
E')
tim
est
am
p
<p
k><
fk1
><
fk2
>
cust
om
er
id cou
_id
cod
ed
ocu
me
nt
do
cum
en
t_ty
pe
firs
tna
me
firs
t_la
stn
am
ese
con
d_
last
na
me
leg
al_
firs
tna
me
leg
al_
last
na
me
leg
al_
ph
on
eci
typ
ost
al_
cod
est
atu
sty
pe
cre
ate
_d
ate
int
int
varc
ha
r(1
0)
varc
ha
r(1
5)
EN
UM
('C','
O')
varc
ha
r(2
55
)va
rch
ar(
25
5)
varc
ha
r(2
55
)va
rch
ar(
25
5)
varc
ha
r(2
55
)va
rch
ar(
15
)va
rch
ar(
10
0)
varc
ha
r(1
5)
EN
UM
('AC
TIV
E','
INA
CT
IVE
')E
NU
M('P
RO
SP
EC
T','
CL
IEN
T')
tim
est
am
p
<p
k><
fk>
pa
cka
ge
id cus_
idst
a_
idco
n_
idu
se_
idre
c_id
off
_id
cod
ed
esc
rip
tio
ncr
ea
te_
da
tem
iam
i_d
ate
ship
pin
g_
da
tesh
ipp
ing
_g
uid
em
iam
i_b
oxe
se
cua
do
r_d
ate
ecu
ad
or_
bo
xes
cust
om
s_d
ate
cou
nte
rsig
n_
nu
mb
er
ap
pra
isa
l_d
ate
liq
uid
ati
on
_d
ate
liq
uid
ati
on
_n
um
be
rta
xes_
da
teq
uit
o_
da
tep
aid
_d
ate
de
live
red
_d
ate
int
int
int
int
int
int
int
varc
ha
r(1
2)
varc
ha
r(2
55
)ti
me
sta
mp
da
teti
me
da
teti
me
varc
ha
r(1
1)
int
da
teti
me
int
da
teti
me
varc
ha
r(3
0)
da
teti
me
da
teti
me
varc
ha
r(3
0)
da
teti
me
da
teti
me
da
teti
me
da
teti
me
<p
k><
fk5
><
fk6
><
fk3
><
fk4
><
fk2
><
fk1
>
all
ow
ed
_a
ctio
ns
id act
_id
url
int
int
varc
ha
r(2
55
)
<p
k><
fk>
act
ion
id pa
ren
t_id
na
me
lin
kw
eig
ht
int
int
varc
ha
r(5
0)
varc
ha
r(2
55
)d
eci
ma
l
<p
k>
pro
file
id na
me
sta
tus
int
varc
ha
r(1
20
)e
nu
m('A
CT
IVE
','IN
AC
TIV
E')
<p
k>
cou
ntr
y
id na
me
int
varc
ha
r(2
55
)<
pk>
cust
om
er_
ad
dre
ss
id cus_
ida
dd
ress
int(
25
5)
int
varc
ha
r(2
55
)
<p
k><
fk>
cust
om
er_
em
ail
id cus_
ide
ma
il
int
int
varc
ha
r(2
55
)
<p
k><
fk>
cust
om
er_
att
ach
me
nt
id cus_
idfi
le
int
int
varc
ha
r(2
55
)
<p
k><
fk>
cust
om
er_
ph
on
e
id cus_
idp
ho
ne
typ
e
int
int
nu
me
ric(
15
,0)
EN
UM
('MO
BIL
','C
ON
VE
NT
ION
AL
')
<p
k><
fk>
cust
om
er_
ob
serv
ati
on
id cus_
idu
se_
ido
bse
rva
tio
nst
atu
sre
aso
n
int
int
int
varc
ha
r(2
55
)E
NU
M('N
OR
MA
L','
RE
MIN
DE
R')
EN
UM
('OF
FE
R','
QU
OT
E','
OT
HE
R')
<p
k><
fk1
><
fk2
>
off
er
id na
me
de
scri
pti
on
sta
tus
int
varc
ha
r(2
55
)va
rch
ar(
25
5)
EN
UM
('AC
TIV
E','
INA
CT
IVE
')
<p
k>
rece
ive
r_a
ge
nt
id na
me
ad
dre
ssp
ho
ne
mo
bil
em
ail
ob
serv
ati
on
cre
ate
_d
ate
sta
tus
int
varc
ha
r(2
55
)va
rch
ar(
25
5)
nu
me
ric(
15
,0)
nu
me
ric(
15
,0)
varc
ha
r(2
55
)va
rch
ar(
25
5)
tim
est
am
pE
NU
M('A
CT
IVE
','IN
AC
TIV
E')
<p
k>
con
ten
t_ty
pe
id na
me
pre
fix
sta
tus
int
varc
ha
r(2
55
)va
rch
ar(
1)
EN
UM
('AC
TIV
E','
INA
CT
IVE
')
<p
k>
sta
tus
id na
me
ali
as
int
varc
ha
r(1
00
)va
rch
ar(
25
5)
<p
k>
pro
file
_a
ctio
n
id act
_id
int
int
<p
k,fk
1>
<p
k,fk
2>
50
2.3.4.1 Diccionario de Datos del Sistema
Un diccionario de datos permite conocer todos los datos involucrados en el flujo
del sistema, así como el tipo, la longitud y descripción de cada uno de ellos. A
continuación se presentan cada uno de ellos por cada entidad de base de datos.
ENTIDAD: CUSTOMER ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del cliente.
code Variable characters (10) Es el código propio de TransferCargo de un cliente. De la siguiente manera: Prefijo “TC” seguido de 8 dígitos, de 00000000 a 99999999, incrementados secuencialmente. Es obligatorio.
document Variable characters (15) Es el número de identificación del cliente. Es obligatorio.
document_type ENUM('C'.'O') Es el tipo de identificación del cliente. C si es la cédula, O si es otros (RUC, Pasaporte, etc). Es obligatorio.
firstname Variable characters (255) Es el nombre del cliente. Es obligatorio.
first_lastname Variable characters (255) Es el primer apellido del cliente. Es obligatorio.
second_lastname Variable characters (255) Es el segundo apellido del cliente.
legal_firstname Variable characters (255) Es el nombre del representante legal, en caso de que fuera una empresa.
legal_lastname Variable characters (255) Es el apellido del representante legal, en caso de que fuera una empresa.
legal_phone Variable characters (15) Es el teléfono del representante legal, en caso de que fuera una empresa.
city Variable characters (100) Es la ciudad de vivienda del cliente
51
postal_code Variable characters (15) Es el código postal del cliente.
status ENUM('ACTIVE'.'INACTIVE') Es el estado del cliente en el sistema. Es obligatorio.
type ENUM('PROSPECT'.'CLIENT') Es el tipo de cliente. Puede ser un prospecto (Aún no es cliente) ó un cliente. Es obligatorio.
create_date Timestamp Es la fecha de creación del cliente en el sistema.
Tabla 2.28: Diccionario de Datos: Entidad Customer
ENTIDAD: CUSTOMER OBSERVATION ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de la observación de cliente.
observation Variable Characters (255) Es la observación acerca de un cliente. Es obligatorio.
status ENUM ('NORMAL'.'REMINDER') Es el estado de la observación. Puede ser normal (NORMAL) ó con recordatorio (REMINDER). Es obligatorio.
reason ENUM ('OFFER'.'QUOTE'.'OTHER')
Es la razón de la observación. Puede ser por promoción (OFFER), cotización (QUOTE), u otro (OTHER). Es obligatorio.
create_date Timestamp Es la fecha de creación de la observación en el sistema.
reminder_date Date Es la fecha para el recordatorio, si es que el estado fuese REMINDER.
quote_number Variable Character (15) Es el número de cotización, si es que la razón fuese QUOTE.
Tabla 2.29: Diccionario de Datos: Entidad Customer Observation
ENTIDAD: CUSTOMER EMAIL ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de un
52
email de un cliente. email Variable Characters (255) Es la dirección electrónica
de un email de un cliente. Es obligatorio.
Tabla 2.30: Diccionario de Datos: Entidad Customer Email
ENTIDAD: CUSTOMER ADDRESS ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de una dirección de un cliente.
address Variable Characters (255) Es la dirección física de un cliente. Es obligatorio.
Tabla 2.31: Diccionario de Datos: Entidad Customer Address
ENTIDAD: CUSTOMER PHONE ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del teléfono de un cliente.
phone Number (15) Es el número telefónico de un cliente. Es obligatorio.
type ENUM ('MOBIL'.'CONVENTIONAL')
Es el tipo de teléfono. Puede ser celular (MOBIL) ó convencional (CONVENTIONAL)
Tabla 2.32: Diccionario de Datos: Entidad Customer Phone
ENTIDAD: CUSTOMER ATTACHMENT ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de un archivo adjunto de un cliente.
file Variable Characters (255) Es el path (ruta) de un archivo adjunto de un cliente. Es obligatorio.
Tabla 2.33: Diccionario de Datos: Entidad Customer Attachment
ENTIDAD: PROFILE ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del perfil
53
de usuario. name Variable characters (120) Es el nombre del perfil de
usuario. Es obligatorio. status ENUM ('ACTIVE'.'INACTIVE') Es el estado del perfil de
usuario. Puede estar activo (ACTIVE) ó desactivado (INACTIVE). Es obligatorio.
Tabla 2.34: Diccionario de Datos: Entidad Profile
ENTIDAD: ACTION ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de la acción de perfil.
parent_id Integer Es la acción padre si es que existiese. Sirve para armar el menú.
name Variable characters (50) Es el alias o nombre de la acción. Es el nombre que se mostrará en el menú.
link Variable characters (255) Es el link (url) de la acción de perfil. A este link irá dirigido la acción
weight Decimal Es el peso de la acción. Sirve para armar el menú.
Tabla 2.35: Diccionario de Datos: Entidad Action
ENTIDAD: ALLOWED ACTIONS ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de la acción permitida.
url Variable characters (255) Es el url permitido para cada acción.
Tabla 2.36: Diccionario de Datos: Entidad Allowed Actions
ENTIDAD: USER ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del usuario.
username Variable Characters (100) Es el alias de acceso del usuario. Es obligatorio.
password MD5 (100) Es el password del usuario, codificado con MD5. Es obligatorio.
document Variable Characters (15) Es el número de identificación del usuario. Es obligatorio.
document_type ENUM('C'.'O') Es el tipo de identificación
54
del usuario. Si es cédula (C), ó si es otros la O (RUC, Pasaporte, etc). Es obligatorio.
firstname Variable Characters (255) Es el nombre del usuario. Es obligatorio.
lastname Variable Characters (255) Es el apellido del usuario. Es obligatorio.
city Variable Characters (255) Es la ciudad de vivienda del usuario.
address Variable Characters (255) Es la dirección de vivienda del usuario.
phone Number (15) Es el teléfono del usuario. mobil Number (15) Es el número celular del
usuario. email Variable Characters (255) Es la dirección electrónica
del usuario. status ENUM ('ACTIVE'.'INACTIVE') Es el estado del usuario en
el sistema. Puede estar activado (ACTIVE) ó desactivado (INACTIVE).
create_date Timestamp Es la fecha de creación del usuario en el sistema.
Tabla 2.37: Diccionario de Datos: Entidad User
ENTIDAD: PACKAGE ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del paquete.
code Variable Characters (12) Es el código del paquete. Este es un código propio de la empresa. Dado de la siguiente manera: Prefijo “TC” seguido de 10 dígitos secuenciales. Es obligatorio.
description Variable Characters (255) Es una descripción del contenido del paquete.
create_date Timestamp Es la fecha de creación del paquete en el sistema.
miami_date Date & Time Es la fecha en la que el paquete llegó a las bodegas de Miami, procedente de cualquier parte de EEUU.
shipping_date Date & Time Es la fecha en la que el paquete fue embarcado rumbo a Ecuador.
shipping_guide Variable characters (11) Es la guía de embarque. El cual es una cadena de 11 caracteres, entre números y
55
letras. miami_boxes Integer Es el número de cajas que
conforman el paquete, y que estaban en Miami.
ecuador_date Date & Time Es la fecha de arribo al Ecuador del paquete.
ecuador_boxes Integer Es el número de cajas del paquete que fueron recibidas en Ecuador.
customs_date Date & Time Es la fecha en la que el paquete se encuentra en aduana.
countersign_number Variable characters (30) Es el número de refrendo del paquete.
appraisal_date Date & Time Es la fecha en la que el paquete está en el aforo.
liquidation_date Date & Time Es la fecha en la que se liquidan los costos de aforo.
liquidation_number Variable characters (30) Es el código de liquidación del paquete
taxes_date Date & Time Es la fecha en la que se efectúa el pago de impuestos
quito_date Date & Time Es la fecha en la que el paquete está en las bodegas de Quito.
paid_date Date & Time Es la fecha de pago del cliente por su paquete.
delivered_date Date & Time Es la fecha de despacho del paquete al cliente.
Tabla 2.38: Diccionario de Datos: Entidad Package
ENTIDAD: CONTENT TYPE ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del tipo de contenido de un paquete.
name Variable characters (255) Es el nombre o alias de un tipo de contenido de un paquete. Es obligatorio.
prefix Variable characters (1) Es un prefijo de una letra que servirá para identificar el tipo de contenido en el código del paquete. Es obligatorio.
description Variable characters (255) Es la descripción del tipo de contenido de un paquete. Es obligatorio.
status ENUM ('ACTIVE'.'INACTIVE') Es el estado del tipo de contenido de un paquete.
56
Puede estar activo (ACTIVE) ó desactivado (INACTIVE). Es obligatorio.
Tabla 2.39: Diccionario de Datos: Entidad Content Type
ENTIDAD: STATUS ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del estado de un paquete.
name Variable characters (100) Es el nombre del estado, por el que atraviesa un paquete. Se utilizará en el código fuente. Es obligatorio.
alias Variable characters (255) Es el alias del estado. Se utilizará para la presentación. Es obligatorio.
Tabla 2.40: Diccionario de Datos: Entidad Status
ENTIDAD: OFFER ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador de una promoción.
name Variable characters (255) Es el nombre de la promoción. Es obligatorio.
description Variable characters (255) Es la descripción de la promoción.
status ENUM('ACTIVE'.'INACTIVE') Es el estado de la promoción. Puede estar activa (ACTIVE) o desactivada (INACTIVE). Es obligatorio.
Tabla 2.41: Diccionario de Datos: Entidad Offer
ENTIDAD: RECIEVER AGENT
ATRIBUTO TIPO DE DATO DESCRIPCIÓN Id Serial Este campo es obligatorio, y es
auto incremental. Sirve como identificador del usuario.
name Variable characters (255) Es el nombre de un agente destinatario. Es obligatorio.
address Variable characters (255) Es la dirección de un agente destinatario.
phone Number (15) Es el teléfono de un agente destinatario.
mobil Number (15) Es el celular de un agente
57
destinatario. email Variable characters (255) Es el correo electrónico de un
agente destinatario. observation Variable characters (255) Es las observaciones de un
agente destinatario. create_date Timestamp Es la fecha y hora de creación
de un agente destinatario. status ENUM('ACTIVE'.'INACTIVE') Es el estado de un agente
destinatario en el sistema. Este puede estar activado (ACTIVE), ó desactivado (INACTIVE). Es obligatorio.
Tabla 2.42: Diccionario de Datos: Entidad Receiver Agent
ENTIDAD: COUNTRY
ATRIBUTO TIPO DE DATO DESCRIPCIÓN
Id Serial Este campo es obligatorio, y es auto incremental. Sirve como identificador del país.
name Variable characters (255) Es el nombre del país. Es obligatorio.
Tabla 2.43: Diccionario de Datos: Entidad Country
2.3.5 DISEÑO DE INTERFACES DE USUARIO
El presente proyecto se enfoca en brindar facilidad de navegación a sus usuarios
manteniendo estándares de calidad visual y funcional. Para ello, se estandarizará
las formas y elementos de formularios, títulos, menús, entre otros, y se respeta la
distribución de las pantallas, formatos y nombres.
Para cumplir el objetivo descrito se hará uso de la norma ISO19 9241-151:2008,
denominada: “Ergonomics of human system interaction – Guidance on World
Wide Web user interfaces”. [42]
Todos los módulos en los que se ha dividido el proyecto trabajarán de acuerdo a
los estándares establecidos en esta sección, para de esta manera poder
integrarlos fácilmente y de manera correcta. Cabe resaltar que en el producto
final, algunos elementos pueden variar, más no las convenciones para nombres y
tamaños; además, las imágenes mostradas son referenciales y no reflejan el
producto final. Las características o consideraciones generales tomadas para el
19
ISO: (Organización Internacional de Normalización) es el organismo encargado de promover el desarrollo de normas internacionales y estándares.
58
diseño de interfaces que se detallan a continuación fueron tomadas de la
referencia bibliográfica [43].
2.3.5.1 Consideraciones Generales
· El sistema debe presentar la información claramente al usuario, es decir
mostrar un título adecuado por cada pantalla, minimizando el uso de
abreviaturas y proporcionando una retroalimentación de usuario clara.
· El sistema debe ser consistente a lo largo de sus pantallas. Se puede lograr
consistencia por medio de:
o Ubicación de títulos, fecha, hora y mensajes de operador, en todas las
pantallas.
o Saliendo de cada pantalla mediante la misma opción (a través de
enlaces, botones o pulsando sobre un gráfico determinado).
o El uso de colores de manera homogénea para todas las pantallas.
o El uso de iconos para operaciones establecidos de manera similar.
· El Sistema debe realizar un reconocimiento de la aceptación de entrada, es
decir, el reconocimiento que la entrada está en la forma correcta. Antes del
envío de datos a servidor, se debe validar en la medida de lo posible que lo
que se desea ingresar sea correcto, o, por lo menos, sea un valor posible,
como se observa en la Figura 2.9.
Figura 2.9: Interfaz de inicio de sesión mostrando validaciones de datos
59
· El sistema debe informar de forma clara y explícita del problema que puede
existir con los datos ingresados en los casos que sea necesario, como se
observa en la Figura 2.10.
Figura 2.10: Interfaz de Inicio de Sesión con un ingreso erróneo al Sistema.
· Los usuarios deben saber cuándo su petición está completa y si pueden
efectuar nuevas solicitudes; para ello el sistema desplegará un mensaje de
retroalimentación, como se observa en la Figura 2.11:
Figura 2.11: Interfaz de Administración de Perfiles con Mensaje de Creación exitosa.
60
· El título de la página debe permitir al usuario identificar claramente en qué
lugar del sistema se encuentra ubicado, como se observa en la Figura
2.12:
Figura 2.12: Interfaz de Administración de Usuarios
· En caso de interfaces secuenciales, se debe permitir al usuario acceso a la
siguiente o anterior interfaz, como se observa en la Figura 2.13. se tiene el
botón “Regresar”:
Figura 2.13: Interfaz de Nuevo Usuario con botón de regreso
61
· Los campos de solo lectura o no editables no permiten situar el cursor para
editar la información, y permanecen opacos.
· El cursor se localiza automáticamente de arriba hacia abajo y de izquierda
a derecha cuando se pulsa la tecla “Tab”. Es importante que la distribución
de los campos en los formularios sea simétrica, como se muestra en la
Figura 2.14:
Figura 2.14: Interfaz de creación de Usuario.
2.4 IMPLEMENTACIÓN
2.4.1 PROGRAMACIÓN
2.4.1.1 PHP
2.4.1.1.1 Estándares de programación PHP
Para la elaboración de código del presente proyecto se utilizarán los estándares
de programación PSR020, PSR1, PSR2, y PSR3 [44], aceptados y oficiales de la
comunidad de desarrolladores de PHP; además se utilizará los estándares
propios de Kohana Framework [45]. Entre las consideraciones más importantes
se tienen las siguientes: 20
PSR: (PHP Specification Request) son una serie de estándares de programación para PHP creados por el FIG (PHP Framework Interoperability Group) y aceptados por la comunidad oficial de desarrolladores PHP.
62
· El código PHP debe utilizar las etiquetas largas <?php ?> o las etiquetas
cortas para imprimir salida de información <?= ?>; No se debe emplear otras
variantes.
· Los archivos sólo deben utilizar una codificación UTF-8 21.
· El código escrito para PHP 5.2.x o inferior debería emplear una convención de
pseudo-espacios de nombres con prefijos en los nombres de las clases con el
formato Proveedor_. Un ejemplo de ello se muestra en la Figura 2.15:
Figura 2.15: Estándar para nombres de clases
· Las funciones se escriben con notación camelCase() a menos que la notación
propia del Framework sea otra. En el caso de Kohana Framework se utiliza la
notación snake_case (minúsculas separado por guión bajo _ ). Además estas
funciones deberán devolver un solo valor. Esto se observa en el ejemplo de la
Figura 2.16:
Figura 2.16: Estándar para nombres de funciones y valores de retorno en Kohana Framework
21
UTF-8: Es un formato de codificación de caracteres Unicode e ISO 10646 utilizando símbolos de longitud variable. Está definido como estándar por la RFC 3629.
63
· Las constantes deben ser definidas en mayúsculas y utilizando guion bajo (_)
cómo separador.
· Las llaves de apertura de las clases deben ir en la línea siguiente, y las llaves
de cierre deben ir en la línea siguiente al cuerpo de la clase.
· Las llaves de apertura de las estructuras de control deben estar en la misma
línea, y las de cierre deben ir en la línea siguiente al cuerpo. Además Los
paréntesis de apertura en las estructuras de control no deben tener un espacio
después de ellos, y los paréntesis de cierre no deben tener un espacio antes
de ellos, como se observa en la Figura 2.17:
Figura 2.17: Estándar para llaves y paréntesis de apertura y cierre, en estructuras de control
· Pueden añadirse líneas en blanco para mejorar la lectura del código y para
indicar bloques de código que estén relacionados.
· Las constantes de PHP true, false y null deben estar en minúsculas.
· En la lista de argumentos de una función o método no debe haber un espacio
antes de cada coma y debe haber un espacio después de cada coma. Los
argumentos con valores por defecto del método deben ir al final de la lista de
argumentos, como se observa en la Figura 2.18:
Figura 2.18: Estándar para lista de argumentos, en funciones y métodos
· Para los comentarios en PHP están permitidos los símbolos de apertura /* y //,
y los símbolos */ para cierre. No se debe utilizar el símbolo #. Es importante
expresar el tipo de variable resultado de cada función con la sintaxis @param
[tipo de dato] [variable]. Se puede observar un ejemplo de comentarios en
PHP en la Figura 2.19:
64
Figura 2.19: Estándar para lista de argumentos, en funciones y métodos
2.4.1.1.2 Modelos en Kohana Framework
Kohana Framework al estar diseñado en un paradigma Modelo – Vista –
Controlador, utiliza sintaxis determinada para cada una de ellas. En el caso de los
modelos según la documentación propia de Kohana Framework [46] se lo debe
implementar como se muestra en la Figura 2.20, que representa al modelo User
(Usuario) del sistema:
Figura 2.20: Modelo Usuario, en Kohana Framework
Donde se observa lo siguiente:
· El nombre de la clase está dada por la notación Model_Nombredelmodelo.
· La clase hereda de ORM, que permite manejar y extraer los atributos
directamente desde la base de datos.
· La variable propia de ORM $_table_name cargará la tabla de base de datos
escrita en minúsculas. En este caso la tabla usuario.
· Las variables $_has_many, $_belongs_to, $_has_one propias de ORM sirven
para establecer relaciones entre modelos. Como se observa en la Figura 2.20,
un usuario pertenece a un perfil.
2.4.1.1.3 Controladores en Kohana Framework
En el caso de los controladores, Kohana Framework expone en su documentación
[47] reglas importantes en la elaboración de controladores para su correcta
funcionalidad, entre los más importantes están los siguientes:
65
· Los controladores o carpetas que los contienen deben estar alojados en
clases/controllers
· El nombre de archivo de un controlador debe ser igual al modelo, y debe estar
en minúsculas.
· El nombre de la clase está dada por la notación
Controller_Nombredecarpeta_Nombredelcontrolador, y hereda del controlador
por defecto como se observa en la Figura 2.21.
· Las acciones (métodos) del controlador no deben utilizar notación camelCase,
sino snake_case22 (palabras separadas por _) como se observa en la Figura
2.21, donde se muestra el controlador Usuario y la acción index (por defecto
de Kohana Framework).
Figura 2.21: Controlador y acción de Usuario, en Kohana Framework
22
Snake Case: Es la práctica de la escritura de palabras o frases en la que los elementos se separan con un compuesto subrayado guión bajo (_) y sin espacios, con la letra inicial de cada elemento por lo general en minúsculas también.
66
2.4.1.1.4 Vistas en Kohana Framework
En Kohana Framework las vistas son de código HTML. Pero se instancian y
registran variables desde el controlador. Para instanciar una vista se utiliza la
función View::factory, y para registrar una variable en ella, la función set, como
podemos observar en la Figura 2.22:
Figura 2.22: Instanciación de una vista y envío de variables a vista, en Kohana Framework
Para llamar desde las vistas a las variables registradas en el controlador basta
con crear una variable con el alias de esa variable (primer parámetro de la función
set). A continuación en la Figura 2.23 se muestra una parte de la vista por defecto
del controlador usuario, y además la llamada de la variable $users registrada en el
controlador:
Figura 2.23: Vista por defecto de Usuario, en Kohana Framework
67
2.4.2 JQUERY (JAVASCRIPT)
Para el presente proyecto se utilizará jQuery, la cual es una biblioteca JavaScript
pero que sintetiza, facilita y acorta el código. Además permite la manipulación de
objetos HTML, el control de eventos y las peticiones ajax mucho más rápido y
simple. Se utilizará jQuery para las acciones AJAX23, validaciones de campos, y
además la manipulación de HTML. Cada archivo de javascript tendrá la notación
propia de jQuery como se muestra en el ejemplo de la Figura 2.24:
Figura 2.24: Ejemplo de Implementación de Código jQuery (javascript)
23
AJAX : Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas sin la necesidad de recargar toda una página web completa
68
2.4.3 CSS (CASCADE STYLE SHEETS)
Mediante las hojas de estilo en cascada se puede dar formato visual a HTML.
Esto se logra aplicando diversas propiedades tanto de tipo estético como visual, a
cada atributo HTML mediante código CSS.
Para el presente proyecto se ha utilizado CSS 3, aceptado por la mayoría de
navegadores modernos, tales como Mozilla Firefox, Google Chrome, Safari, IE8,
etc. Se muestra un ejemplo de su utilización en la Figura 2.25:
Figura 2.25: Ejemplo de Código CSS
69
2.5 PRUEBAS
2.5.1 PRUEBAS DE ACEPTACIÓN
Las pruebas fueron diseñadas por el equipo de desarrollo en base a los requisitos
funcionales especificados en la fase de análisis, mientras que le ejecución y
aprobación final correspondieron al usuario.
Las historias de usuario definidas en el numeral 2.1.2 fueron la base para la
realización de las pruebas de aceptación. El formato para las mismas se muestra
en la Tabla 2.44 [48] y sus componentes se definen a continuación:
· Caso de Prueba: es el nombre del módulo que se está probando.
· Opción de Prueba: nombre de la opción del menú que está siendo probada.
· Número de caso de Prueba: número del caso de prueba.
· Número de Historia de Usuario: número de historia de usuario que está
siendo probada.
· Nombre de Caso de Prueba: nombre del caso de prueba que se realiza.
· Precondiciones: condiciones previas para ejecutar la prueba.
· Datos: todo lo que el usuario ingresa, modifica o consulta.
· Pasos: actividades secuenciales que el usuario debe realizar para obtener los
resultados.
· Resultado Esperado: resultado que se pretende obtener al realizar la prueba.
· Evaluación: resultado obtenido de la prueba.
Tabla 2.44: Formato para Prueba de Aceptación
PRUEBAS DE ACEPTACIÓN
Caso de Prueba: Opción de Prueba:
Número de Caso de Prueba: Número de Historia de Usuario:
Nombre de Caso de Prueba:
Precondiciones:
Datos:
Pasos:
Resultado Esperado:
Evaluación:
70
En las Tablas 2.45 a 2.50 se muestran seis de las pruebas de aceptación y sus
resultados. Las restantes pruebas de aceptación se encuentran en el Anexo III.
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Perfiles
Número de Caso de Prueba: 01 Número de Historia de Usuario: 01
Nombre de Caso de Prueba: Nuevo Perfil
Precondiciones: Usuario debe tener permisos de administración de perfiles.
Datos:
Nombre de Perfil Variable characters 120
Funciones:
· Administración: o Perfiles o Usuarios o Contactos o Competencia o Clientes o Prospectos
· Gestión de Carga o Tipos de Carga o Agentes Destinatarios o Promociones o Paquetes
· Reportes
Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False)
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Perfiles; se muestra el índice de la Administración de Perfiles. Ir a la parte superior izquierda y escoger vínculo a Nuevo Perfil, se despliega formulario de ingreso de datos para nuevo perfil. Completar los datos y guardar.
Resultado Esperado: Recibir un mensaje de confirmación de creación exitosa de perfil en la interface principal de Administración de Perfiles, y una nueva fila en la tabla principal con los datos del nuevo perfil. Esto significa un almacenamiento exitoso en la base de datos.
Evaluación: Se recibe mensaje de confirmación de creación exitosa de perfil y los datos se guardan exitosamente.
Tabla 2.45: Prueba de Aceptación – Nuevo Perfil
71
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Perfiles
Número de Caso de Prueba: 02 Número de Historia de Usuario: 01
Nombre de Caso de Prueba: Actualizar Perfil
Precondiciones: Usuario debe tener permisos de administración de perfiles.
Datos:
Nombre de Perfil Variable characters 120
Funciones:
· Administración: o Perfiles o Usuarios o Contactos o Competencia o Clientes o Prospectos
· Gestión de Carga o Tipos de Carga o Agentes Destinatarios o Promociones o Paquetes
· Reportes
Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False) Boolean(True/False)
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Perfiles; se muestra el índice de la Administración de Perfiles. Al final de cada registro se encuentran dos enlaces, escoger vínculo Actualizar, se despliega formulario de ingreso de datos del perfil seleccionado. Completar los datos y guardar.
Resultado Esperado: Recibir un mensaje de confirmación de actualización exitosa de perfil en la interface principal de Administración de Perfiles, y la fila en la tabla principal con los datos actualizados del perfil. Esto significa un almacenamiento exitoso en la base de datos.
Evaluación: Se recibe mensaje de confirmación de actualización exitosa de perfil y los datos se guardan exitosamente.
Tabla 2.46: Prueba de Aceptación – Actualizar Perfil
72
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Perfiles
Número de Caso de Prueba: 03 Número de Historia de Usuario: 01
Nombre de Caso de Prueba: Activar / Desactivar Perfil
Precondiciones: Usuario debe tener permisos de administración de perfiles.
Datos:
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Perfiles; se muestra el índice de la Administración de Perfiles. Al final de cada registro se encuentran dos enlaces, escoger vínculo Activar / Desactivar, se despliega un mensaje de cuadro de decisión para desactivar / activar el perfil seleccionado. Confirmar o cancelar.
Resultado Esperado: Recibir un mensaje de confirmación de Activado/Desactivado exitoso del perfil en la interface principal de Administración de Perfiles, la fila en la tabla principal con el estado del perfil actualizado. Esto significa un almacenamiento exitoso en la base de datos.
Evaluación: Se recibe mensaje de confirmación de actualización exitosa de perfil y los datos se guardan exitosamente.
Tabla 2.47: Prueba de Aceptación – Activar/Desactivar Perfil
73
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Usuarios
Número de Caso de Prueba: 04 Número de Historia de Usuario: 02
Nombre de Caso de Prueba: Nuevo Usuario
Precondiciones: Usuario debe tener permisos de administración de usuarios.
Datos:
Tipo de documento ENUM(‘C’,O’’)
Identificación Variable Character 15
Nombres Variable Character 255
Apellidos Variable Character 255
Nombre de Usuario Variable Character 100
Perfil Variable Character 120
País Variable Character
Ciudad Variable Character 255
Dirección Variable Character 255
Teléfono Number 15
Celular Number 15
E-mail Variable Character 255
Contraseña MD5(100)
Confirmar Contraseña MD5(100)
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Usuarios; se muestra el índice de la Administración de Usuarios. Ir a la parte superior izquierda y escoger vínculo a Nuevo Usuario, se despliega formulario de ingreso de datos para nuevo usuario. Completar los datos y guardar.
Resultado Esperado: Recibir un mensaje de confirmación de creación exitosa de usuario en la interface principal de Administración de Usuarios, y una nueva fila en la tabla principal con los datos del nuevo usuario. Esto significa un guardado exitoso de datos en la base.
Evaluación: Se recibe mensaje de confirmación y los datos se guardan exitosamente. Tabla 2.48: Prueba de Aceptación – Nuevo Usuario
74
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Usuarios
Número de Caso de Prueba: 05 Número de Historia de Usuario: 02
Nombre de Caso de Prueba: Actualizar Usuario
Precondiciones: Usuario debe tener permisos de administración de usuarios.
Datos:
Tipo de documento ENUM(‘C’,O’’)
Identificación Variable Character 15
Nombres Variable Character 255
Apellidos Variable Character 255
Nombre de Usuario Variable Character 100
Perfil Variable Character 120
País Variable Character
Ciudad Variable Character 255
Dirección Variable Character 255
Teléfono Number 15
Celular Number 15
E-mail Variable Character 255
Contraseña MD5(100)
Confirmar Contraseña MD5(100)
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Usuarios; se muestra el índice de la Administración de Usuarios. Al final de cada registro se encuentran 2 enlaces, escoger vínculo Actualizar, se despliega formulario de ingreso de datos del usuario seleccionado. Completar los datos y guardar.
Resultado Esperado: Recibir un mensaje de confirmación de actualización exitosa de usuario en la interface principal de Administración de Usuarios, se observa en la fila en la tabla principal los datos actualizados del usuario. Esto significa una actualización exitosa de datos en la base.
Evaluación: Se recibe mensaje de confirmación y los datos se guardan exitosamente. Tabla 2.49: Prueba de Aceptación – Actualizar Usuario
75
PRUEBA DE ACEPTACIÓN
Caso de Prueba: Administración del Sistema
Opción de Prueba: Usuarios
Número de Caso de Prueba: 06 Número de Historia de Usuario: 02
Nombre de Caso de Prueba: Activar / Desactivar Usuario
Precondiciones: Usuario debe tener permisos de administración de usuarios.
Datos:
Pasos: Una vez iniciada la sesión, dirigirse a la pestaña Administración, se despliega un menú, escoger opción Usuarios; se muestra el índice de la Administración de Usuarios. Al final de cada registro se encuentran 2 enlaces, escoger vínculo Activar / Desactivar, se despliega un mensaje de cuadro de decisión para desactivar / activar el usuario seleccionado. Confirmar o cancelar.
Resultado Esperado: Recibir un mensaje de confirmación de Activado/Desactivado exitoso del perfil en la interface principal de Administración de Usuarios, se observa la fila en la tabla principal con los datos actualizados del usuario. Esto significa una actualización exitosa de datos en la base.
Evaluación: Se recibe mensaje de confirmación y los datos se guardan exitosamente. Tabla 2.50: Prueba de Aceptación – Activar/Desactivar Usuario
76
3. CAPÍTULO III: CASO DE ESTUDIO
El caso de estudio fue realizado en la Empresa TransferCargo S.A., donde se
implementó el sistema y se utilizó la información proporcionada por esta empresa.
3.1 DESCRIPCIÓN DEL CASO DE ESTUDIO
TransferCargo S.A. es una empresa ecuatoriana de Courier y envíos fundada en
1998, ubicada al Norte de Quito, en el sector de El Inca, en las calles Pablo del
Solar E4-123 e Isla Seymour. Esta empresa tiene como misión "Asesorar a
nuestros clientes de la forma más conveniente, ágil y segura para hacer sus
importaciones desde los Estados Unidos con la finalidad de optimizar los
recursos tanto humanos, económicos y materiales." [49]
La visión de la empresa es "lograr que las barreras de distancia y procesos entre
dos diferentes países sean superados para alcanzar un bien común, así los
ecuatorianos disfrutaremos de los nuevos productos que el mundo nos brinda."
[49]
Actualmente TransferCargo S.A realiza los procesos referentes a gestión de
paquetes manualmente, registrando los datos en hojas de cálculo Excel, con lo
que se corre el riesgo de información duplicada, mal escrita y sin posibilidad de
reportes.
Cuando el paquete pasa de un estado a otro, el personal de Transfer Cargo o el
personal de aduanas envían una lista indicando los códigos de los paquetes que
cambiaron de estado. Los mandos gerenciales corroboran esta información y
registran los nuevos datos en la hoja de cálculo Excel y proceden a distribuir esta
información entre todos los empleados (operadores de call center, personal de
aduana, mandos gerenciales) por medio de correos electrónicos o dispositivos de
almacenamiento USB, lo que dificulta conocer si es que la información recibida es
actualizada y si es que no ha sido alterada o editada en medio de este proceso.
Mediante esta información no necesariamente correcta, los operadores del call
77
center (servicio al cliente), y la página web informan a los usuarios de la situación
de su paquete, hasta que llega a sus manos.
3.2 IMPLEMENTACIÓN DEL SISTEMA
El sistema será implementado en un computador de Transfer Cargo, que servirá
para crear un ambiente local de pruebas, con las características descritas en la
Tabla 3.1. Dependerá de Transfer Cargo implementar el sistema en el hosting24
definitivo, con sus respectivas credenciales y dominio.
CARACTERÍSTICA DESCRIPCIÓN
Procesador Intel Core i7-4960HQ Processor (6M
Cache, up to 3.80 GHz)
RAM 16 GB
Disco Duro 4 TB
Sistema Operativo Windows Server 2008
Tabla 3.1: Características del Computador para la implementación del Sistema
El computador tuvo previamente instalados y configurados los siguientes
componentes de software:
· Servidor web: Apache 2.2.14
· Lenguaje de programación: PHP 5.3
· Administrador de base de datos: MySQL 5.1
Para implementar el sistema se siguió el siguiente procedimiento:
· Copiar la carpeta que contiene el código fuente de Kohana Framework,
llamado “TRANSFERCARGO” en la ubicación del servidor web. En el caso de
apache, será en la carpeta htdocs/.
· Importar el script en la base de datos ubicado en
../TRANSFERCARGO/db/transfer_db.sql .
24
Web Hosting: es el servicio que provee a los usuarios de Internet un sistema para poder almacenar información, imágenes, vídeo, o cualquier contenido accesible vía web
78
· En el archivo de configuración ubicado en
../TRANSFERCARGO/aplication/config/database.php se ingresarán las
credenciales de la base de datos creada anteriormente. Este archivo se
muestra en la Figura 3.2:
Figura 3.1: Archivo de Configuración del sistema
· Si todo el procedimiento fue correcto, al ingresar en cualquier navegador e
ingresar a http://localhost/TRANSFERCARGO se obtendrá la pantalla que se
muestra en la Figura 3.3.
Figura 3.2: Llamada al sistema desde un navegador convencional (Mozilla Firefox)
79
Si es que se requiere acceder al sistema desde otra computadora o dispositivo
desde la misma red, simplemente deberá reemplazar localhost25, por la dirección
ip del servidor o el alias del mismo.
Una vez realizados los pasos anteriores, el sistema comenzó a funcionar y
entregar los resultados esperados. El manual de instalación y técnico detallado se
encuentra en el Anexo IV.
Ya instalado, se ingresaron los datos necesarios para el sistema. Así se ingresó
los perfiles de usuario que se van a utilizar como se muestra en la Figura 3.4.
Figura 3.3: Creación de Perfiles de Usuario
En la Figura 3.4 se visualiza la lista de perfiles creados anteriormente.
25
Localhost: Es la dirección IP de loopback 127.0.0.1 en IPv4, o la dirección ::1 en IPv6. Es utilizado para acceder a aplicaciones web localmente.
80
Figura 3.4: Perfiles de Usuario
Se ingresaron todos los parámetros necesarios para utilizar la gestión de
movimiento de paquetes. Tales como usuarios, agentes destinatarios,
promociones, sucursales, tipos de carga. Se muestra un ejemplo del ingreso de
un usuario en la Figura 3.5.
Figura 3.5: Creación de Usuario
81
Se ingresaron clientes reales para efectuar envíos reales y evaluar la facilidad del
sistema, como se muestra en la Figura 3.6.
Figura 3.6: Creación de Clientes
Se realizó el ingreso de paquetes sin ninguna novedad como se muestra en la
Figura 3.7, y además se probó los distintos estados que estos puedan tener como
se muestra en la Figura 3.8.
Figura 3.7: Creación de Paquete
82
Figura 3.8: Movimiento de Paquete
El manual de usuario del sistema, que posee los pasos anteriores descritos en
detalle, y además de toda la funcionalidad del sistema, se encuentra en el manual
de usuario en el Anexo V.
3.3 ANÁLISIS DE RESULTADOS
Para el análisis de resultados se diseñó una encuesta que fue aplicada a varios
funcionarios de la empresa. El diseño de la encuesta se muestra en la Tabla 3.2 y
los resultados en la Tabla 3.2:
Perfil de Usuario:
1. ¿Cree Ud. que el sistema de gestión web ayuda a brindar un mejor servicio
a sus clientes? Si, No. ¿Por qué?
2. ¿Cree Ud. que el sistema ayuda a optimizar el uso de recursos? ¿De qué
tipo? Si, No. ¿Por qué?
3. De los procesos implementados ¿Cuál ha sido en el que ha observado una
mejora sustancial? Perfiles, Usuarios, Clientes, Paquetes. ¿Por qué?
4. En cuanto al aspecto visual ¿Qué opinión tiene acerca del sistema?
Excelente, Bueno, Malo, Regular ¿Por qué?
5. Desde el punto de vista de usuario ¿Qué dificultades de uso o navegación
encontró en el sistema? Explique
6. ¿Qué recomendaciones haría para mejorar el sistema en los módulos a los
que tiene acceso de acuerdo a su perfil?
Tabla 3.1 Modelo de Encuesta para recolección de datos
83
Tab
la 3
.2:
Res
ult
ado
s d
e E
ncu
esta
s
Per
fil
de
Usu
ario
P
reg
un
ta 1
P
reg
un
ta 2
P
reg
un
ta 3
P
reg
un
ta 4
P
reg
un
ta 5
P
reg
un
ta 6
Ger
ente
Gen
eral
Sí,
ya q
ue a
utom
atiz
ando
el
proc
eso
perm
ite a
horr
ar ti
empo
y
brin
darle
la in
form
ació
n al
clie
nte
con
rap
idez
.
Sí,
el r
ecur
so p
rimor
dial q
ue
se a
horr
a co
n es
te s
iste
ma
es ti
empo
.
El p
roce
so d
e U
suar
ios,
Clie
ntes
y P
aque
tes
son
los
prin
cipal
es y
mej
ora
n pa
ra
bien
los
proc
esos
de
man
ejo
de in
form
ació
n en
est
os
aspe
ctos
.
Bue
no,
los
colo
res
coor
dinan
con
los
de la
empr
esa,
ser
ía im
port
ante
que
los
reco
rdat
orio
s
teng
an u
n co
lor
más
llam
ativ
o n
ada
más
.
Nin
guna
, el
sis
tem
a
es m
uy in
tuiti
vo y
mue
stra
lo q
ue s
e
nece
sita
par
a
trab
ajar.
Ser
ía r
ecom
enda
ble q
ue e
l
cam
bio
de e
stad
o de
paqu
etes
pue
da s
er m
últip
le
o m
asiv
o. A
dem
ás s
e
vuel
ve in
disp
ensa
ble te
ner
un r
epor
te d
e ob
serv
acio
nes
de c
lient
es
por
cada
oper
ador
que
las
real
izó
.
Ger
ente
Reg
ion
al
Sí,
porq
ue t
odas
las
pers
onas
tiene
n ac
ceso
a la
mis
ma
info
rmac
ión
desd
e cu
alqui
er
part
e
del m
undo
.
Sí,
el t
iem
po
es u
n re
curs
o
impo
rtan
te y
a qu
e se
agi
litan
los
proc
esos
.
Pro
ceso
de
Paq
uete
s y
Clie
ntes
son
el e
je p
rinci
pal
del n
egoc
io.
Exc
elent
e,
lleva
los
mis
mos
colo
res
que
repr
esen
tan
a
la e
mpr
esa
y co
n
tona
lidad
es s
obria
s qu
e
ayud
an a
la in
tuic
ión
del
usua
rio.
Nin
guna
, de
prim
era
man
o se
mue
stra
fáci
l de
usar
y n
o
gene
ra
com
plic
acio
nes.
El c
olor
de lo
s m
ensa
jes
de
valid
ació
n de
berí
a se
r m
ás
fuer
te,
por
ejem
plo e
l roj
o.
Ade
más
que
los
repo
rtes
sean
exp
orta
bles,
ya
sea
a
Exc
el o
PD
F.
Op
. Cal
l
Cen
ter
Sí,
nos
perm
ite a
los
oper
ador
es
guar
dar
info
rmac
ión
cons
iste
nte
grac
ias
a la
s di
stin
tas
valid
acio
nes.
Y a
dem
ás y
a no
hay
vers
ione
s di
stin
tas
de la
info
rmac
ión.
Sí,
el p
rinci
pal
rec
urso
es
tiem
po, p
ero
adic
iona
l
recu
rsos
de
pape
lerí
a qu
e
se u
saba
n pa
ra g
uard
ar
info
rmac
ión
de c
lient
es.
En
el p
roce
so d
e re
gist
ro d
e
clie
ntes
y t
ambi
én
la o
pció
n
pros
pect
os, y
a qu
e fa
cilit
a el
ingr
eso
y m
anej
o de
cad
a
uno
de e
stos
.
Buen
o, lo
s co
lore
s se
empa
reja
n co
n lo
s de
la
empr
esa,
las
alert
as d
eben
lleva
r co
lore
s m
ás fu
erte
s.
Nin
guna
, lo
util
ice
fáci
lment
e.
Nin
guna
Op
erar
io
Ad
uan
a
Sí,
ya q
ue p
erm
ite te
ner
un
cont
rol a
decu
ado
de lo
s en
víos
tant
o vi
sual
com
o en
rep
orte
s
físic
os.
Sí,
tiem
po e
s lo
prin
cipal
ya
que
se ti
ene
la in
form
ació
n
disp
onib
le a
cua
lqui
er
mom
ent
o.
El c
ontr
ol d
e pa
quet
es e
s el
que
más
me
sirve
, pu
esto
que
rev
iso
el a
vanc
e de
los
mis
mos.
Exc
elent
e, s
on lo
s co
lore
s
de la
em
pres
a y
ayud
an a
resa
ltar
lo im
port
ant e
,
com
o tít
ulos
o r
ótul
os.
Nin
guna
.
Ser
ía b
ueno
que
se
pres
ente
en
la li
sta
de
paqu
etes
, que
est
ado
es e
l
sigui
ent
e y
ante
rior
para
cada
paq
uete
.
84
Después de los resultados obtenidos de la encuesta en la Tabla 3.3 realizada a
dos mandos gerenciales y dos operativos se concluye que el sistema cumple con
los requerimientos iniciales del cliente, y se toma en cuenta los siguientes
cambios y funcionalidades del sistema de acuerdo a las recomendaciones:
· Los recordatorios de la pantalla principal se cambiaron de color celeste a
naranja.
· Los mensajes de validación de datos se cambiaron de color azul a rojo.
· En la lista de paquetes, se agregaron etiquetas indicando su estado
anterior y próximo.
· Se implementó un reporte de observaciones de clientes y prospectos
según operador.
· Se implementó la exportación de reportes a formato Excel o PDF.
· Se implementó la funcionalidad de cambio de estado para múltiples
paquetes.
85
3.4 CONCLUSIONES
· La metodología XP se adaptó a las características del proyecto, puesto que se
cumplió tanto con tiempos y con las historias de usuario determinadas.
· Se promovió el trabajo en pareja como parte del ciclo de desarrollo de
software, cumpliendo así con uno de los principios fundamentales de la
metodología XP, además de la interacción continua con el cliente para
establecer adecuadamente los requerimientos.
· Los cambios sugeridos durante el desarrollo del sistema fueron adaptados
exitosamente y en poco tiempo, por lo que se comprobó también que la
metodología XP permite un desarrollo incremental basado en pequeñas partes
funcionales, evitando un gran impacto sobre el resto del sistema.
· El Framework utilizado en el proyecto Kohana Framework, facilitó las tareas de
programación e interacción MVC, ya que permitió escalabilidad y facilidad al
crear nuevas funcionalidades.
· Mediante la automatización de los procesos implicados en la gestión de
movimiento de paquetes, se optimizará el uso de recursos de la empresa,
puesto que se disminuye el uso de tiempo tanto para los operadores de call
center, aduana, y por tanto de los clientes, cumpliendo así con los objetivos
del presente proyecto de tesis.
86
3.5 RECOMENDACIONES
· Es recomendable, incentivar la comunicación como eje transversal del
desarrollo de cualquier proyecto basado en metodología XP, puesto que el
éxito de esta metodología depende de las correctas relaciones entre el equipo
de desarrollo y el cliente.
· Para la implementación del sistema en la red global, se recomienda utilizar un
servidor Hosting dedicado, puesto que es importante que el sistema no
comparta recursos de servidor, ya que esto puede afectar la estabilidad,
velocidad y rendimiento del sistema.
· Es importante en un futuro añadir al sistema funcionalidades para otros
procesos de la empresa, tales como funcionalidades telefónicas mediante
Asterisk, o implementación de etiquetas y lectores RFID (Radio Frequency
Identification) a lo largo de todo el proceso de Courier.
· Para el correcto uso del sistema, se recomienda realizar un taller de
capacitación dirigido a las personas que van a utilizar y administrar el sistema
desarrollado.
· Para garantizar el mantenimiento y escalabilidad del sistema, es importante
conservar la estructura del Framework, además de hacer uso de sus
estándares de programación y codificación cuando se agreguen nuevas
funcionalidades o se hagan cambios al sistema.
87
BIBLIOGRAFÍA [1] República del Ecuador, Registro Oficial N° 336. Reglamento para la aplicación del impuesto
de Divisas. Ecuador, 2008.
[2] Banco Central del Ecuador, Evolución de las Remesas del Tercer Trimestre de 2012. Ecuador, 2012.
[3] Club Raíz. Raíz Emprendedor. [Online]. http://www.raizemprendedor.com/Definicion-de-Courier-Paqueteria-y-Logistica/81
[4] Jhisela María Cárdenas Navarrete, “CREACIÓN DE UNA EMPRESA DE SERVICIOS COURIER
UBICADA EN LA PARROQUIA ELOY ALFARO DEL CANTÓN QUITO”. Quito, 2012.
[5] Universidad de Belgrano. (2013, Apr.) [Online]. http://www.ub.edu.ar/posgrados/continua/archivos_primer_semestre/Gesti%C3%B3n%20Jur%C3%ADdica %20de%20la%20Empresa.pdf
[6] Coordinación General de Gestión Aduanera, Boletín 259-2009, Dec. 04, 2009.
[7] Zetes. (2010, Octubre) Zetes. [Online]. http://www.zetes.com/en/press-and-events/newsletter/globe7/vision-on-market
[8] República del Ecuador, Registro Oficial N°116. Ley Orgánica de Defensa del Consumidor. Artículo 4. Numeral 4. Quito, Ecuador, 2000.
[9] Aduana del Ecuador. (2012) Aduana del Ecuador. [Online]. http://www.aduana.gob.ec/pro/courier.action
[10] Instituto de Promoción de Exportaciones e Inversiones del Ecuador. (2011) [Online]. http://www.proecuador.gob.ec/servicio-al-exportador/intercoms/
[11] Universidad de Castilla de la Mancha. Metodologías de desarrollo de Software. Documento PDF.
[12] J. Highsmith, "Agile Software Development Ecosystems".: Addison-Wesley, 2002.
[13] Elisa Gallo and Mikel Vergara. European Software Institute. [Online]. http://www.esi.es/Berrikuntza
[14] Universidad Politécnica de Valencia. [Online]. http://noqualityinside.com.ar/nqi/nqifiles/XP_Agil.pdf#page=2&zoom=auto,0,542
[15] Iparbit. [Online]. http://www.iparbit.es/desarrollo_met_Manifiesto.html
[16] Iparbit. [Online]. http://www.iparbit.es/desarrollo_met_Manif_Ppios.html
[17] Extreme Programming Comunity. Extreme Programming. [Online]. www.extremeprogramming.org, c2.com/cgi/wiki?ExtremeProgramming
[18] Ingeniería de Software México. [Online]. http://ingenieriadesoftware.mex.tl/52812_Scrum.html
[19] Crystal Methodologies Blog. [Online]. http://crystalmethodologies.blogspot.com/
[20] Wiki del programador. [Online]. http://developerwiki.egafutura.com/glosario/metodologia-agil-asd-adaptive-software-development
[21] Cyta. [Online]. http://www.cyta.com.ar/ta0502/b_v5n2a1.htm
[22] Wikibooks. [Online]. http://es.wikibooks.org/wiki/Fundamentos_de_programaci%C3%B3n/Herramientas_de_desarrollo
[23] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_bases_de_datos
[24] Daniel Pecos. [Online]. http://danielpecos.com/docs/mysql_postgres/x57.html#AEN59
[25] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Framework
88
[26] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Kohana
[27] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Zend_Framework
[28] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Symfony
[29] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Servidor_web
[30] Apache Software Fundation. Apache Software Fundation. [Online]. http://httpd.apache.org/ABOUT_APACHE.html
[31] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Servidor_HTTP_Apache
[32] Wikipedia. [Online]. http://es.wikipedia.org/wiki/Internet_Information_Services
[33] [Online]. http://casidiablo.net/el-servidor-apache-tomcat/
[34] FDS Herramientas Case. [Online]. http://fds-herramientascase.blogspot.com/
[35] VALAREZO VARGAS Roberto JARRIN ORTIZ María, Desarrollo e Implementación del Sistema de Gestión Académica y Administración vía Web para el Colegio Modelo Politécnico. Quito: EPN, 2010.
[36] Kent BECK and Martin FOWLER, Planning Extreme Programming., 2000.
[37] Samer Hassan. Tarjetas CRC. pdf.
[38] Universidad de Chile. Modelo de Clases. [Online]. http://users.dcc.uchile.cl/~psalinas/uml/modelo.html#clase
[39] SPARX Systems. SPARX Systems. [Online]. http://www.sparxsystems.com.ar/resources/tutorial/uml2_classdiagram.html
[40] KDE. KDE Documentation. Elementos de UML. [Online]. http://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html
[41] Universidad de Chile. Tutorial de UML. Modelo de Clases. [Online]. http://users.dcc.uchile.cl/~psalinas/uml/modelo.html
[42] ISO. ISO. [Online]. http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=37031
[43] Sandra Mendoza. (2010, Jan.) TP2-20100-Modulo5. [Online]. http://tp2-20100-modulo5.googlecode.com/svn/trunk/documentos/PrimerEntregable/Primer%20Entregable/Est%c3%a1ndar%20de%20Interfaz%20Gr%c3%a1fica.doc
[44] PHP Fig. PHP Fig Standards. [Online]. https://github.com/php-fig/fig-standards/tree/master/accepted/es
[45] Kohana Framework. Convenciones Kohana Framework. [Online]. http://kohanaframework.org/3.1/guide/kohana/conventions
[46] Kohana Framework. Kohana Framework Models. [Online]. http://kohanaframework.org/3.1/guide/kohana/mvc/models
[47] Kohana Framework. Kohana Framework Controllers. [Online]. http://kohanaframework.org/3.1/guide/kohana/mvc/controllers
[48] Kent Beck, Extreme Programming Explained, Segunda ed. Boston: Addison Wesley, 2004.
[49] TransferCargo S.A. TransferCargo S.A. [Online]. http://www.tc-ecuador.com/index.php?route=information/information&information_id=4
89
GLOSARIO
Aduana: Oficina pública, establecida generalmente en las costas y fronteras, para
registrar, en el tráfico internacional, los géneros y mercaderías que se importan o
exportan, y cobrar los derechos que adeudan.
Aplicación Informática: Es un tipo de programa informático diseñado como
herramienta para permitir a un usuario realizar uno o diversos tipos de trabajo.
Aplicación Web: Son aquellas Aplicaciones que los usuarios pueden utilizar
accediendo a un servidor web a través de Internet o de una intranet mediante un
navegador. En otras palabras, es una aplicación software que se codifica en un
lenguaje soportado por los navegadores web en la que se confía la ejecución al
navegador.
Carga: Cosa transportada a hombros, a lomo, o en cualquier tipo de vehículo.
Cliente: Aquella persona quien accede a un producto o servicio por medio de una
transacción financiera (dinero) u otro medio de pago. En nuestro caso específico
son todas las personas que envían un paquete o carga mediante el servicio de
transporte.
Contacto: En nuestro caso específico, son aquellas personas que aún no se
convierten en clientes, pero se les ofrece el servicio de envío de carga y
paquetes.
Courier: Es una persona o compañía que envía paquetes o encomiendas con
gran velocidad, seguridad y seguimiento.
Destinatario: Persona a quien va dirigido o destinado algo.
Embarque: Introducir algo en una embarcación, en un avión o en un tren.
90
Estado de la carga: Es aquel estado del proceso de enviar y recibir, en el que se
encuentra un determinado paquete.
Internet: Es un conjunto descentralizado de redes de comunicación
interconectadas que utilizan la familia de protocolos TCP/IP, garantizando que las
redes físicas heterogéneas que la componen funcionen como una red lógica
única, de alcance mundial.
Kohana: Es un framework para aplicaciones web para PHP5 que implementa el
patrón de Modelo Vista Controlador Jerárquico (HMVC).
Navegador Web: Es una aplicación que opera a través de Internet, interpretando
la información de archivos y sitios web para que podamos ser capaces de leerla,
(ya se encuentre ésta alojada en un servidor dentro de la World Wide Web o en
un servidor local).
Paquete: Conjunto de de cosas de una misma o distinta clase no muy abultado.
PHP: PHP Hypertext Pre Processor es un lenguaje de programación interpretado,
y diseñado originalmente para la creación de páginas web dinámicas.
Proveedor: Se aplica a la persona que provee o abastece a otra persona de lo
necesario o conveniente para un fin determinado.
Remitente: Persona que envía una carta,paquete,etc.,con su nombre y señas en
el remite.
Web: Es un sistema de distribución de información basado en hipertexto o
hipermedios enlazados y accesibles a través de Internet.
91
ANEXOS
ANEXO I: Código Fuente y Scripts del Sistema (Digital).
CD-ROM: /ANEXOS/Anexo I: Código Fuente/CodigoFuente.zip
ANEXO II: Modelo físico de base de datos del sistema (Digital).
CD-ROM: /ANEXOS/Anexo II/ ModeloFisicoSistema.pdf
ANEXO III: Pruebas de aceptación del sistema (Digital).
CD-ROM: /ANEXOS/Anexo III/ PruebasDeAceptacion.pdf
ANEXO IV: Manual de Instalación del Sistema (Digital).
CD-ROM: /ANEXOS/Anexo IV/ ManualDeInstalacion.pdf
ANEXO V: Manual de Usuario del Sistema (Digital).
CD-ROM: /ANEXOS/Anexo V/ ManualDeUsuario.pdf
