Memoria_EPSU0760

Vista previa del material en texto

Tr
eb
al
lF
in
al
d
e
G
ra
u Aplicación Web para Gestión de Vuelos y
Pasajeros en Privilege Style S.A.
GERMÁN MARTÍNEZ
Tutor
Carlos Juiz
Escuela politécnica superior
Universidad de las Islas Baleares
Grado en Ingeniería Informática
Palma, 4 de septiembre de 2016
En primer lugar, quiero agradecer a mi familia su apoyo incondicional durante estos
cortos pero intensos cuatro años, estoy seguro de que sin ellos no habría conseguido
estar donde estoy ahora.
En segundo lugar, quiero agradecer a mi tutor los consejos y el asesoramiento que me
ha proporcionado a lo largo de este proyecto. Su profesionalidad e interés han sido un
claro ejemplo para mí y lo seguirán siendo en el futuro.
Finalmente, me gustaría agradecer a la empresa Privilege Style S.A. el facilitarme y
permitirme realizar un proyecto de estas características, ayudándome y confiando en
mí en todo momento.
ÍNDICE GENERAL
Índice general III
Índice de figuras V
ACRÓNIMOS VII
RESUMEN IX
1 INTRODUCCIÓN 1
2 OBJETIVOS 3
2.1. Generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Particulares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 TECNOLOGÍAS 5
3.1. Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Controlador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Herramienta de Construcción y Compilación de Proyectos . . . . . . . . 6
3.5. Control de Versiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.6. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.7. Servlet Container . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.8. Sistema Operativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.9. Entorno de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.10. Otras Tecnologías y/o Frameworks . . . . . . . . . . . . . . . . . . . . . . 8
4 DESARROLLO 9
4.1. Definición del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.3. Módulos y Funcionalidades . . . . . . . . . . . . . . . . . . . . . 35
4.4. Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 RESULTADOS Y DISCUSIÓN 47
6 CONCLUSIÓN Y LÍNEAS DE FUTURO 49
III
IV ÍNDICE GENERAL
6.1. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2. Líneas de Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A RESUMEN DEL PROCESO DE ENVÍO Y RECEPCIÓN DE INFORMACIÓN DE
UN VUELO 51
A.1. Solicitud de Nueva Operación de Vuelo . . . . . . . . . . . . . . . . . . . 51
A.2. Previo al Vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.3. Creación del Vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
A.4. Gestión y Envío de la PNL . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.5. Confirmación de Recepción de un Vuelo . . . . . . . . . . . . . . . . . . 52
A.6. Cambios de Última Hora . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
A.7. Cierre de un Vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Bibliografía 53
ÍNDICE DE FIGURAS
4.1. Métodología SCRUM simplificada . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Metodología SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Modelo Entidad-Relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. Estructura del Proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Paquete Privilege App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.6. Paquete Privilege Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Paquete Privilege Data Constant . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.8. Paquete Privilege Data Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.9. Paquete Privilege Data Implementation . . . . . . . . . . . . . . . . . . . . . 16
4.10. Paquete Privilege Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.11. Paquete Privilege Data Repository . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.12. Paquete Privilege Web Imagen 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.13. Paquete Privilege Web Imagen 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.14. Paquete Privilege Web Bean . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.15. Paquete Privilege Web Constant . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.16. Paquete Privilege Web Controller . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.17. Paquete Privilege Web Flight Controller . . . . . . . . . . . . . . . . . . . . . 22
4.18. Paquete Privilege Web Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.19. Paquete Privilege Web Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.20. Paquete Privilege Web Interceptor . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.21. Paquete Privilege Web Json . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.22. Paquete Privilege Web Json Beans . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.23. Paquete Privilege Web Startup . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.24. Paquete Privilege Web Validator . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.25. Paquete Privilege Web View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.26. Paquete Privilege Web Resources . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.27. Paquete Privilege Web App Resources . . . . . . . . . . . . . . . . . . . . . . 27
4.28. Paquete Privilege Web App WEB-INF . . . . . . . . . . . . . . . . . . . . . . . 29
4.29. Paquete PVG Utils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.30. Paquete PVG Utils Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.31. Paquete PVG Utils Dyna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.32. Paquete PVG Utils Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.33. Paquete PVG Utils Pojo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.34. Paquete PVG Utils Util . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.35. Paquete PVG Utils Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.36. Paquete PVG Utils Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
V
VI Índice de figuras
4.37. Configuración del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.38. Página de Bienvenida de la Aplicación . . . . . . . . . . . . . . . . . . . . . . 35
4.39. Acceder a la creación del vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.40. Creación del vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.41. Datos del Vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.42. Vista en un Vuelo ya Creado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.43. Cargar Pasajeros desde una lista en CSV . . . . . . . . . . . . . . . . . . . . . 38
4.44. Crear Nuevo Pasajero desde la Aplicación . . . . . . . . . . . . . . . . . . . . 39
4.45. Modificar Vuelo y Pasajeros a su Estado de no Enviado . . . . . . . . . . . . 39
4.46. Editar un Vuelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.47. Crear Itinerario de Viaje . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.48. Realizar Conciliación de Pasajeros Manual . . . . . . . . . . . . . . . . . . . 40
4.49. Eliminación Múltiple de Pasajeros . . . . . . . . . . . . . . . . . . . . . . . . 41
4.50. Procesos de la Parte Superior de la Página . . . . . . . . . . . . . . . . . . . . 41
4.51. Formulario de Envío de PNLs . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.52. Vista de Información de Aviones . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.53. Formulario de Creación de Aviones . . . . . . . . . . . . . . . . . . . . . . . . 43
4.54. Lista de Pasajeros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.55. Lista de Pasajeros de un Vuelo Concreto . . . . . . . . . . . . . . . . . . . . . 44
4.56. Formulario para la Creación y Edición de Pasajeros . . . . . . . . . . . . . . 44
4.57. Lista de Aerolíneas Registradas . . . . . . . . . . . . . . . . . . . . . . . . . . 45
ACRÓNIMOS
TFG Trabajo Final de Grado
PNL Passengers Name List
ADL Additional Name List
UN/EDIFACT United Nations rules for Electronic Data Interchange for Administration,
Commerce and Transport
PRL Passenger Reconcile List
CSV Comma-Separated Values
PDF Portable Document Format
DCS Departure Control System
SITA International Society of Aeronautical Telecommunications
IATA Asociación Internacional del Transporte Aéreo
PNR Passengers Name Register
API Información Anticipada sobre los Pasajero
JPA Java Persistence API
ORM Object-Relational mapping
JDBC Java Database Connectivity
JNDI Java Naming and Directory Interface
XHTML eXtensible HyperText Markup Language
UIB Universidad de las Islas Baleares
HTML HyperText Markup
MVC Modelo Vista Controlador
IDE Integrated Development Environment
EJB Enterprise JavaBeans
VII
VIII ACRÓNIMOS
CRM Customer Relationship Management
PFS Passenger Final Sales
XSLT EXtensible Stylesheet Language
XML eXtensible Markup Language
URL Uniform Resource Locator
PSCRM Passenger Services Conference Resolutions Manual
RESUMEN
El presente trabajo de fin de grado consiste en el desarrollo de una aplicación web
para la gestión de vuelos y pasajeros en la empresa Privilege Style S.A.
Al contrario que en compañías de vuelos regulares, los clientes no emiten un billete
individualmente, si no que un grupo de pasajeros alquilan o contratan un avión para
su uso exclusivo durante un número de saltos, o en durante un tiempo (días, semanas,
incluso meses). En la mayoría de los casos, un representante del grupo es el encargado
de gestionar el alquiler de los vuelos y de facilitar la información necesaria a la compañía
que opera el vuelo, aunque en otras ocasiones, es una empresa la que contrata los
servicios de un avión para hacer un número estipulado de vuelos.
Es evidente que un representante o empresa no puede estar rellenando formularios
de una página para más de 200 pasajeros por vuelo y por ello, es necesario facilitarle
esta gestión.
Partiendo de una gestión que se realiza con hojas de Excel y Outsourcing, se cons-
truirá una aplicación que haga todas las gestiones necesarias con la mínima implicación
de los agentes involucrados, tanto internos como externos. Al mismo tiempo, se preten-
de tener un registro de todos los pasajeros que han volado en la compañía y los vuelos
realizados, cumpliendo así con la normativa española que se expone a continuación:
Resolución de 14 de febrero de 2007, de la Subsecretaría del Ministerio de la Pre-
sidencia, por la que se dispone la publicación de la Resolución de las Secretarías
de Estado, de Seguridad, del Ministerio del Interior y de Inmigración y Emigra-
ción, del Ministerio de Trabajo y Asuntos Sociales, por la que se determinan las
rutas sobre las que se establecen obligaciones de información por parte de las
compañías, empresas de transportes o transportistas.
Directiva 2004/82/CE del Consejo de la Unión Europea de 29 de abril de 2004
sobre la obligación de los transportistas de comunicar los datos de las perso-
nas transportadas de forma telemática y anticipada a la llegada a destino, más
conocido como .API", en inglés.
Directiva (UE) 2016/681 del Parlamento Europeo y del Consejo de 27 de abril de
2016 relativa a la utilización de datos del registro de nombres de los pasajeros
(PNR) para la prevención, detección, investigación y enjuiciamiento de los delitos
de terrorismo y de la delincuencia grave.
Anexo 9 al Convenio de la Organización de Aviación Civil Internacional (OA-
CI), sobre facilitación de la aviación civil, normas, métodos recomendados y
procedimientos internacionales de formalidades de aduana e inmigración.
IX
X RESUMEN
Además de la normativa anterior, el programa permite la comunicación bidirec-
cional entre la compañía aérea y los sistema informáticos de control de pasajeros
de los aeropuertos, en término de enviar la información previa a la salida para la
facturación, equipaje, envío a las Autoridades aduaneras y migratorias, informa-
ción personal, selección de servicios como asientos, comidas o promociones... y
posteriormente permite la reconciliación de los pasajeros que efectivamente han
embarcado y su equipaje tanto para la compañía aérea como para que el aero-
puerto de destino conozca esa información. Todo ello siguiendo las taxonomías y
estructura de mensajes diseñadas por la Asociación Internacional del Transporte
Aéreo (IATA).
C
A
P
Í
T
U
L
O
1
INTRODUCCIÓN
La empresa Privilege Style S.A., aerolínea de vuelos chárter y miembro del Grupo
Empty Leg, necesita obtener una herramienta para la gestión de vuelos y pasajeros para
cumplir con la normativa española, y facilitar el envío y la recepción de información de
pasajeros y vuelos en formato Passengers Name List (PNL), Additional Name List (ADL),
United Nations rules for Electronic Data Interchange for Administration, Commerce and
Transport (UN/EDIFACT), Passenger Reconcile List (PRL), EXCEL, Comma-Separated
Values (CSV) y Portable Document Format (PDF), a los distintos organismos nacionales
e internacionales de seguridad y control en el ámbito de la aviación.
Actualmente, la gestión de vuelos y pasajeros se realizan mediante hojas de Excel
y subcontratando los servicios para pasar la información a los formatos necesarios
propios de la aviación. La gestión con Excel produce muchos problemas de espacio en
los servidores y es necesaria la implicación de varios trabajadores para poder sostener
estos procesos. Por otra parte, la subcontratación de los servicios necesarios, suponen
un gran coste por vuelo, que varía dependiendo del país de origen y de destino.
Todo esto, junto a la necesidad por cumplir la normativa española, ha hecho nece-
saria la búsqueda de una alternativa que automatice la mayoría de los procesos y que
facilite la gestión de la información.
Por ello, ha aparecido la necesidad de crear un sistema que permita facilitar todas
las gestiones, facilitando el trabajo a los agentes internos y externos para cada uno de
los vuelos. El sistema creado, se basa en una aplicación web que permite crear vuelos,
añadir pasajeros a un vuelo y enviar toda la información de un vuelo a los distintos
agentes involucrados. Además, se requiere la creación de procedimientos que lean
automáticamente la información que llega a un correo por parte de los servidores
aeroportuarios, y el envío automático de información a los departamentos que la
requieran.
Esta aplicación se realiza utilizando el lenguaje JAVA, con la ayuda de varios fra-
meworks que permiten el modelo en tres capas, el envío y la lectura de correos, la
exportación de documentos y la visualización multiplataforma en formato web.
De esta forma, se pretende ahorrar espacio, centralizar el acceso desde cualquier
1
1. INTRODUCCIÓN
parte con varios usuarios, ahorrar los costes de subcontratación por cada vuelo, ahorrar
tiempo a los clientes y cumplir con la normativa española.
2
C
A
P
Í
T
U
L
O
2
OBJETIVOS
2.1. Generales
El proyecto surge por la necesidad de cumplir con la normativa españolay al mismo
tiempo, ahorrar costes en recursos tanto humanos como monetarios.
El objetivo principal es crear una aplicación web que sea accesible por los distintos
departamentos que realizan la gestión de vuelos y pasajeros, facilitando las tareas que
se están realizando actualmente, y al mismo tiempo, mejorar el flujo de información
entre ellos.
La aplicación debe permitir la creación, gestión y búsqueda de vuelos, pasajeros
y aviones, el envío de información a los Departure Control System (DCS) de los aero-
puertos, hacer envíos utilizando la tecnología de direcciones International Society of
Aeronautical Telecommunications (SITA), avisar a los departamentos de información
relevante sobre los vuelos y realizar procesos automáticos de lectura y envío de correos.
2.2. Particulares
Existen varias aplicaciones similares en el mercado (Ryanair, Iberia, Air Europa?),
pero en todas ellas los usuarios o clientes son los que sacan su propio billete y éste
queda registrado en el vuelo seleccionado. Con esta aplicación, se pretenden crear
más de 200 pasajeros en un vuelo importando un simple CSV, ahorrando tiempo y
facilitando al representante del grupo realizar estas gestiones.
Otro de los objetivo, es mantener la información privada y poder gestionarla y/o
manipularla sin la necesidad de terceros, manteniendo los datos de los clientes más
seguros y proporcionando una base tecnológica para añadir nuevas funcionalidades
en un futuro.
Finalmente, el desarrollo e implantación de esta aplicación debe asegurar el cum-
plimiento de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de
Carácter Personal.
3
C
A
P
Í
T
U
L
O
3
TECNOLOGÍAS
A la hora de realizar la aplicación web, se deben tomar decisiones técnicas im-
portantes que repercutirán en el rendimiento, mantenimiento y la evolución de la
aplicación. En este caso, se ha decidido optar por desarrollar en lenguaje JAVA ya que
a día de hoy se considera que es uno de los lenguajes de programación más robustos
para entornos de desarrollo empresariales, con una de las comunidades más grandes
en internet.
Las aplicaciones de portales, intranets, etc? se suelen disputar entre .NET y JAVA, se
podría decir que son los dos pilares fundamentales en el ámbito de las aplicaciones
empresariales en estos momentos. De todas formas, en España, la que más soporte ha
recibido y en la que la mayoría de las empresas están trabajando es JAVA por su facilidad
para permitir hacer desarrollos con un coste bajo, ya que la mayoría de funcionalidades
ya están desarrolladas, hay mucho soporte por parte de la comunidad y además era
la tecnología con la que más soltura tenía gracias a los conceptos estudiados en la
Universidad de las Islas Baleares (UIB).
Otra de las razones por la que se ha tomado esta decisión, es el soporte tan grande
que recibe java de webs como Stack Overflow, una de las mejores páginas de referencia
para los programadores para aportar nuevas ideas y resolver problemas en el ámbito
de la programación. En [1] se puede ver como JAVA es claramente el más soportado.
Por otra parte, otro de los pilares fundamentales para el desarrollo de la aplicación
en JAVA es SPRING MVC, que proporciona una implementación en tres capas, separan-
do el modelo, de la vista y de los controladores utilizando inyección de dependencias
en un marco de trabajo bien estructurado, haciendo más sencillo el workflow de la
aplicación y facilitando la implementación de otras tecnologías.
Finalmente, Javascript, HTML5 y Bootstrap serán los lenguajes predominantes en
la vista (lo que ve el usuario) y Thymeleaf para las plantillas HTML, facilitando el diseño
de la interfaz y así permitir una mejor experiencia de usuario.
A continuación, se definen las tecnologías de cada una de las capas de la aplicación
definiendo el por qué se han elegido estas y no otras.
5
3. TECNOLOGÍAS
3.1. Modelo
Se ha elegido Java Persistence API (JPA) [2] (ya que Oracle ha creado este estándar
para unir todo lo relacionado con base de datos) como base o forma de hacer todo lo
relacionado con base de datos, ya que, lo que se pretende es tener una sola API para
toda la persistencia en JAVA, sea cual sea la implementación. Su función principal es
hacer que las peticiones que se manejan sobre la base de datos y la definición de las
tablas, sea independiente de la base de datos que se esté utilizando. Spring ha utilizado
este estándar junto al proveedor Hibernate [3] para controlar toda la gestión de base de
datos y aplicarla a su contexto.
Hibernate, al ser uno de los Object-Relational mapping (ORM) más consolidado
dentro de la comunidad, es la implementación más viable. Su función principal es la
de implementar el estándar JPA y manejar las conexiones con las bases de datos(Java
Database Connectivity (JDBC), Java Naming and Directory Interface (JNDI)).
3.2. Vista
Dentro de todas las posibilidades( JSP [4], Velocity [5], FreeMarker [6] ), etc se ha ele-
gido una que utiliza eXtensible HyperText Markup Language (XHTML), de esta manera
nos aseguramos que el código de la vista sea un HyperText Markup (HTML) válido y
también, forzando que la lógica se ejecute en la parte del servidor y no pueda ejecutarse
en la parte de la vista (Scriptlets). Es el framework llamado Thymeleaf [7] que también
tiene soporte por parte de Spring. Ya que en Privilege Style se utilizan navegadores
modernos, se ha podido utilizar HTML5 [8] y CSS3 [9], ya que Thymeleaf está muy
orientado a HTML5. También se ha utilizado Bootstrap [10] ya que es uno de los fra-
meworks más utilizado para realizar diseños responsivos utilizando las tecnologías de
HTML5, CSS3 y Javascript [11] utilizando Jquery [12].
3.3. Controlador
Se ha elegido Spring Modelo Vista Controlador (MVC) [13] por su versatilidad a la
hora de utilizar todo tipo de herramientas para gestionar las peticiones; ayudas para
crear API’s rest json, servir ficheros estáticos, servir páginas web utilizando plantillas e
inyección de dependencias.
3.4. Herramienta de Construcción y Compilación de
Proyectos
Maven [14] es la tecnología que se encarga del empaquetado y las dependencias del
proyecto. Nos facilita además, la estructura inicial en base a las tecnologías que se van a
utilizar. Toda la configuración se detalla en el archivo pom.xml donde declararemos un
listado de todas las dependencias y su versión. Estas dependencias pueden ser tanto
públicas [15], privadas, locales o compartidas en un repositorio privado. Adicionalmen-
te, en el pom.xml se pueden agregar pluggins que nos ejecutarán acciones después de
haber compilado, como generar un archivo .war para desplegar en el servidor, ejecutar
tests, generar código automáticamente o cualquier acción previa a la compilación.
6
3.5. Control de Versiones
3.5. Control de Versiones
Para el sistema de versionado se ha utilizado GIT [16] ya que es el sistema de
versionado más consolidado entre la comunidad, permite tener un repositorio local y
otro remoto a la vez y una gran facilidad para resolver conflictos entre versiones.
Para tener un servidor externo de GIT se ha utilizado la plataforma de GITHub [17]
ya que permite tener repositorios privados por un bajo coste, permite ver el control del
código de manera sencilla y muestra gráficas o el historial de lo que se ha cargado en el
servidor (pudiendo ver los archivos y las diferencias entre versiones previas). Además
tiene una API pública con la cual servicios de servidores como Heroku [18] pueden
beneficiarse de su integración. Finalmente, casi todos los Integrated Development
Environment (IDE) incluido eclipse ya tienen pluggins que integran GIT y hacen más
fácil su uso.
3.6. Base de Datos
PostgreSQL [19] es una de las bases de datos de código libre más soportadas que
se puede instalar en casi todos los sistemas operativos (UNIX, Windows) y es muy
riguroso con el estándar SQL. Esta tecnología que lleva bastante tiempo ha dado buenos
resultados, además, ofrece un cliente (Pgadmin III [20]) que ya tiene todas las utilidades
de un cliente gráfico.
Finalmente,hay muchas ayudas para crear scripts automatizados que creen copias
diarias/semanales/mensuales en otras bases de datos o simplemente para exportar los
datos y hacer copias de seguridad con postgreSQL, facilitando así el trabajo tedioso de
estos procedimientos.
3.7. Servlet Container
Tomcat [21] fue uno de los primeros servidores de código libre en implementar los
servlet container, además de ser ligero y facilitar la comunicación con Apache Server.
Agrega ayudas como los conectores JNDI a base de datos que permite que la aplicación
no tenga acceso a las credenciales de la conexión.
Hoy en día, es el servidor más comúnmente utilizado a no ser que se necesiten
características de JAVA EE [22] como por ejemplo Enterprise JavaBeans (EJB) [23], que
en tal caso se suele utilizar JBoss [24].
3.8. Sistema Operativo
Se ha utilizado Ubuntu Server [http://www.ubuntu.com/] ya que no consume tanto
como un Windows Server, permite gestionar las carpetas, permisos, etc? de una forma
más sencilla y rápida.
La creación de Scripts automatizados y el soporte para temas de servidores es muy
amplia en Internet.
La configuración es específica y permite configurar todo hasta el último detalle
entrando en la configuración avanzada del sistema.
7
3. TECNOLOGÍAS
3.9. Entorno de desarrollo
Se ha escogido Eclipse [25] como IDE ya que ofrece facilidades tanto para el desarro-
llo de JAVA (autocompletar, validación) y tiene soporte para Maven y para GIT. Además
da facilidades para instalar el Tomcat localmente.
Por otra parte, tiene un repositorio de pluggins que facilitan los desarrollos para
casi todos los Frameworks.
3.10. Otras Tecnologías y/o Frameworks
Además de las tecnologías nombradas anteriormente, se utilizan un conjunto de
frameworks, librerías y tecnologías que ayudan a gestionar temas de logs, envío de
correo, exportación de PDFs, y otros como Itext [26], mimemessage [27], Jackson [28],
log4j [29] y opencsv [30].
8
C
A
P
Í
T
U
L
O
4
DESARROLLO
Hoy en día, en el mundo del desarrollo del software, los proyectos se gestionan
por fases e hitos, creando una serie de actividades y secuenciándolas en el tiempo.
Esto permite tener un control de las tareas a realizar, los tiempos, recursos, etc? que
pretenden generar el producto o proyecto resultante de la forma más eficiente y eficaz
posible. Cada vez más, las empresas se están dando cuenta de que muchas veces este
tipo de procedimientos no funcionan, ya que el cliente siempre está pidiendo nuevas
funcionalidades y/o cambios, y necesitan buscarse nuevos métodos que permitan esa
interacción continua con el cliente para saber cuáles son sus necesidades y así, poder
dar una respuesta adecuada a sus expectativas.
Entre estas metodologías, se encuentra la metodología SCRUM [31]. En esta ocasión,
se ha decidido por realizar una versión reducida dados los recursos y las necesidades
propias del cliente.
Figura 4.1: Métodología SCRUM simplificada
El dueño del producto, en este caso PRIVILEGE STYLE, asigna al responsable de IT
9
4. DESARROLLO
el rol de SCRUM Master, observando las distintas fases del ciclo de producción.
El equipo de desarrollo obtiene las necesidades del proyecto haciendo las reunio-
nes necesarias con los distintos interesados o participantes, las divide en paquetes o
elementos, y se decide cuáles de estos paquetes se dividen en tareas estimando un
tiempo entre una semana y un mes, desarrollando así, un conjunto de paquetes que se
convertirán en un entregable.
Además, el equipo de desarrollo se reúne diariamente con el SCRUM Master para
notificarle que se hizo el día anterior, que se va a desarrollar hoy y que impedimentos
se han encontrado a la hora de realizar los distintos paquetes o tareas.
Finalmente, el incremento creado se sube a producción y los usuarios prueban
y usan las nuevas funcionalidades. Una vez probado y en pleno funcionamiento, se
realiza una última reunión con el equipo de desarrollo, el SCRUM Master que al mismo
tiempo realiza las funciones del dueño del producto y las distintas partes interesadas.
De esta forma, se recibe el mayor ?feedback? posible para saber si hay que realizar
algunas modificaciones, añadir paquetes a la pila de entregables o continuar con los
paquetes ya definidos.
Todo este proceso desencadena en una última reunión para saber que mejoras,
modificaciones o procesos, son necesarios realizar en el ciclo de vida de la metodología
SCRUM en las próximas iteraciones.
Figura 4.2: Metodología SCRUM
10
4.1. Definición del proyecto
4.1. Definición del proyecto
El proyecto a realizar, tiene que permitir el envío de pasajeros a los DCS de los
aeropuertos utilizando los formatos PNLs y ADLs, la recepción y lectura en tiempo real
de PRLs, la creación de vuelos y pasajeros, búsqueda de pasajeros, itinerarios de viaje,
gestión de aviones, gestión de aerolíneas, chequeo de pasajeros manual y automático,
reportes en PDF, EXtensible Stylesheet Language (XSLT), CSV,UN/EDIFACT y lectura
de CSV para creación automática de pasajeros y vuelos.
El estudio e implementación de los formatos PNL, ADL y PRL, se realiza con el
manual de la Asociación Internacional del Transporte Aéreo (IATA) ?Passenger Services
Conference Resolutions Manual? (IATA Passenger Services Conference Resolutions
Manual (PSCRM)). Que es el encargado de definir el estándar de comunicaciones de
datos entre servidores mediante direcciones SITA.
Las tecnologías a utilizar son las nombradas en la sección de tecnologías de este
documento ??.
4.2. Beneficios
El ahorro que se obtiene de eliminar la subcontratación para enviar los datos de los
pasajeros a los DCS de los aeropuertos, ahorra un coste significativo por vuelo. Además,
el trabajo que alivia a los recursos de la empresa es muy grande, antes se necesitaban
dos personas exclusivamente para realizar todas las gestiones que proporciona la
aplicación, actualmente, con pocas horas, una sola persona puede encargarse de este
trabajo.
Otro de los beneficios más claros en la realización de esta aplicación es el cumpli-
miento con la normativa española.
Finalmente, la aplicación permite un control de los pasajeros y de los vuelos que se
han sido operados por la compañía, pudiendo sacar en un futuro, todo tipo de reportes
y estadísticas.
4.3. Diseño
4.3.1. Base de Datos
Las tablas de las que dispone el proyecto son: aerolíneas, aeropuertos, países, tipos
de documentos, vuelos, tipos de vuelos, comidas, géneros, pasajeros, tipo de pasajero,
provincias, matrículas de aviones, asientos, requisitos especiales y usuarios.
A continuación se puede ver el modelo entidad-relación, y los atributos de cada
una de las tablas:
11
4. DESARROLLO
Figura 4.3: Modelo Entidad-Relación
Finalmente, se van a describir cada una de las tablas y explicar a grandes rasgos los
detalles y las relaciones de cada una de ellas.
Airlines: contiene las aerolíneas con las que se comunica la compañía. Cada
vuelo podrá tener una o más aerolíneas asociadas a él.
Airports: contiene todos los aeropuertos operables por la compañía, cada vuelo
tendrá un aeropuerto de salida y uno de llegada.
Flighs: contiene todos los vuelos que se ha realizado la compañía. Un vuelo
contiene N pasajeros.
Registrations: esta tabla contiene todos los aviones con los que opera la compa-
ñía. Un vuelo solo puede tener un avión asociado. Esta tabla también contiene
algunos datos interesantes sobre el avión, como su matrícula y el número total
de pasajeros que puede transportar.
FlightTypes: tipos de vuelo que puede haber. DOMESTIC (vuelo en España),
SCHENGEN (vuelo en uno de los aeropuertos que forman parte del tratado
SCHENGEN), INTERNATIONAL (vuelo dentro del continente Europeo fuera del
12
4.3. Diseño
tratado SCHENGEN) y SPECIAL (vuelo intercontinental o fuera del continente
Europeo).
Foods: lista de comidas que se ofrecen en los vuelos. Su función es ser asignada a
un usuario para saber su preferencia antes de volar y hacer una estimación de las
necesidades y peticiones que se harán en el vuelo.
Paxtypes: tabla con lostipos de pasajeros.
Genders: tipos de género (Masculino/Femenino).
Countries: lista de países. Cada país puede tener N aeropuertos.
Porvinces: lista de provincias, cada país puede tener N provincias.
Seats: Asientos por avión, cada avión tiene asociado N asientos con su clase
(primera clase, clase turista?) y cada pasajero tiene asociado un asiento.
Doctypes: tipos de documentos (pasaporte, DNI)
Spcs: contiene las necesidades específicas de los pasajeros como por ejemplo
una silla de ruedas.
Passengers: contiene todos los pasajeros que han volado para la compañía.
Users: usuarios que acceden a la aplicación.
4.3.2. Estructura
La estructura del proyecto está formada por cuatro paquetes. A continuación se
definirán cada uno de ellos.
Figura 4.4: Estructura del Proyecto
Privilege-App
El paquete privilege-app, es el proyecto padre, aquí se compilan el resto de proyectos
para conseguir el archivo .war que utilizará el servidor para arrancar la aplicación.
13
4. DESARROLLO
Figura 4.5: Paquete Privilege App
Privilege-Data
El paquete privilege-data, es el paquete con todas las funcionalidades orientadas al
modelo de la base de datos.
Figura 4.6: Paquete Privilege Data
Constant: este paquete contiene las variables de todos los atributos de las tablas
como constantes para ser utilizadas en otras clases.
14
4.3. Diseño
Figura 4.7: Paquete Privilege Data Constant
Service: contiene las interfaces de los servicios o métodos que se usarán para
obtener información de las diferentes tablas.
Figura 4.8: Paquete Privilege Data Service
Implementation: contiene la implementación de cada uno de los servicios o
métodos declarados en la interfaz.
15
4. DESARROLLO
Figura 4.9: Paquete Privilege Data Implementation
Model: contiene todas las clases propias a las tablas de la base de datos y las
relaciones entre cada uno de los campos. Aquí también se declaran primary keys,
las foreign keys, las relaciones manyToOne, manyToMany, secuencias de id, y en
definitiva, toda la configuración relacionada con cada una de las tablas.
16
4.3. Diseño
Figura 4.10: Paquete Privilege Data Model
Repository: finalmente, el package repository contiene las peticiones o llamadas
SQL a la base de datos de cada una de las tablas.
17
4. DESARROLLO
Figura 4.11: Paquete Privilege Data Repository
Privilege-Web
Por otro lado, el paquete privilege-web, contiene los controladores, la lógica de
negocio y la vista.
18
4.3. Diseño
Figura 4.12: Paquete Privilege Web Imagen 1
19
4. DESARROLLO
Figura 4.13: Paquete Privilege Web Imagen 2
Bean: contiene los beans o pojos que no concuerdan con ninguna tabla de la
aplicación.
Figura 4.14: Paquete Privilege Web Bean
Constant: contiene las constants que se van a utilizar para los mapeos, los nom-
bres de las páginas, etc? De esta forma, evitamos tener que modificar el texto en
toda la aplicación cuando hay que cambiar una Uniform Resource Locator (URL)
por ejemplo.
20
4.3. Diseño
Figura 4.15: Paquete Privilege Web Constant
Controller: contiene los controladores genéricos de la aplicación. En un futuro,
cuando haya otra aplicación relacionada con privipax, se creará un package con
el nombre del tema y finalizado con la palabra controller como se ha hecho con
vuelos.
Figura 4.16: Paquete Privilege Web Controller
Flight Controller: contiene los controladores específicos de la aplicación de vue-
los. Todas las peticiones para ver tablas, formularios, etc. pasarán por estos con-
troladores que serán los encargados de llamar a los Helper para realizar la lógica
de negocio y devolver una respuesta al usuario.
21
4. DESARROLLO
Figura 4.17: Paquete Privilege Web Flight Controller
Form: contiene las clases que se refieren a los datos que van a llegar de los
formularios.
Figura 4.18: Paquete Privilege Web Form
Helper: aquí se trata la lógica de negocio. Son los métodos que devuelven las
respuestas a las peticiones hechas a los controladores.
22
4.3. Diseño
Figura 4.19: Paquete Privilege Web Helper
Interceptor: estas clases se ejecutan antes de que las llamadas lleguen a los con-
troladores. Vendrían a ser filtros para cada una de las peticiones. Entre ellos están
el filtro de codificación, que convierte los datos que se reciben al formato que
corresponda, el filtro de página, que cambia los textos de la vista dependiendo
de la página a la que haga la petición y el filtro de seguridad que controla el tema
de autorización y autenticación.
Figura 4.20: Paquete Privilege Web Interceptor
Json: contiene los servicios que responden a las peticiones Ajax con un Json.
23
4. DESARROLLO
Figura 4.21: Paquete Privilege Web Json
Json Beans: POJOs o Beans que contienen los atributos que se enviarán en el
JSON.
Figura 4.22: Paquete Privilege Web Json Beans
Startup: esta clase se ejecuta cuando se inicia el servidor. Su papel es iniciar los
procesos o demonios que utilice la aplicación. Por ejemplo, es el encargado de
crear el proceso que envía un correo a las 20:00 con los datos de los vuelos del
día siguiente a las direcciones correspondientes.
Figura 4.23: Paquete Privilege Web Startup
24
4.3. Diseño
Validator: contiene los validadores de los atributos que llegan del formulario. Así
se evita que algún dato no contenga los valores apropiados para ser guardado.
También rellena un mapeado para devolver los errores de cada campo a la vista
marcándolos de color rojo o verde dependiendo de su validez.
Figura 4.24: Paquete Privilege Web Validator
View: contiene las variables que vamos a tener disponsibles en la vista XHTML.
Figura 4.25: Paquete Privilege Web View
Resources: contiene todos los textos de la aplicación. De esta forma, si se quisiese
implementar otro idioma, bastaría con copiar el archivo, traducir los textos y
modificar levemente la configuración.
25
4. DESARROLLO
Figura 4.26: Paquete Privilege Web Resources
Webapp Resources: Aquí se ubican las fuentes, las imágenes, el Javascript y los
estilos que se usarán en las páginas XHTML.
26
4.3. Diseño
Figura 4.27: Paquete Privilege Web App Resources
27
4. DESARROLLO
Webapp WEB-INF: finalmente, la carpeta WEB-INF, contiene los archivos de
configuración en xml de SPRING, Views, log4j y web.
28
4.3. Diseño
Figura 4.28: Paquete Privilege Web App WEB-INF
29
4. DESARROLLO
Dentro de apps, contiene las carpetas de pnl, error, header, home, include y login
que se definen a continuación:
Pnl: contiene los formularios y las vistas completas de HTML de cada una de
las interfaces de la aplicación. Incluye los formularios de avión, vuelo y pasajeros,
la página del envío del pnl, las tablas de aviones, asientos de un avión, aerolíneas,
vuelo y pasajeros y la página principal de vuelos.
Error: páginas de error 403, 404 y 500 personalizadas.
Header: cabecera que se mostrará en todas las páginas. Carga los datos
dinámicamente con los valores que llegan del controlador.
Home: página de bienvenida.
Include: includes que se harán en todas las páginas. Actualmente solo con-
tiene los mensajes de error. Su funcionalidad es que si ha habido un error en
la validación del formulario, cargue un HTML en un div específico para leer y
mostrar los errores que llegan del controlador.
Login: página de login.
Pvg-Utils
Finalmente, el paquete pvg-utils, es el encargado de tener todas las funcionali-
dades genéricas de la aplicación. Así se evita la duplicidad de código, se aumenta la
productividad y mejora la estructura del proyecto.
30
4.3. Diseño
Figura 4.29: Paquete PVG Utils
Constant: contiene las constantes de spring, de caracteres, strings y mime types,
genéricos en cualquier aplicación.
31
4. DESARROLLO
Figura 4.30: Paquete PVG Utils Constant
Dyna: clase para crear clases y objectos dinámicamente.
Figura 4.31: Paquete PVG Utils Dyna
Encoding: lista de utilidades para pasar de una codificación a otra.
Figura 4.32: Paquete PVG Utils Encoding
Pojo: utilidades para clases genéricas de ayuda.
Figura 4.33: Paquete PVG Utils Pojo
32
4.3. Diseño
Util: utilidades generalespara validaciones, cambios de formato, o cualquier tipo
de herramienta que permita utilizar objetos específicos como un fichero, y nos
de los métodos genéricos de este.
Figura 4.34: Paquete PVG Utils Util
Web: utilidades para las peticiones que van desde la vista al controlador y vice-
versa.
Figura 4.35: Paquete PVG Utils Web
33
4. DESARROLLO
Test: clases de Test para validar el funcionamiento de las utilidades.
Figura 4.36: Paquete PVG Utils Test
Servers
Contiene todos los archivos de configuración, las políticas y propiedades del servi-
dor Tomcat 7.
En el archivo de configuración context.xml, encontramos las conexiones JDBC a las
bases de datos.
Por otra parte, en el archivo server.xml, se encuentra toda la configuración de
puertos, direcciones, caché, protocolos y un apuntador al archivo de inicialización de
la aplicación. En nuestro caso apunta a un archivo .war.
El archivo de configuración tomcat-users.xml, define los usuarios y los roles para
conectarse al manager y al servidor.
Finalmente, el archivo web.xml define los valores por defecto de todas las aplicacio-
nes iniciadas por esta instancia del Tomcat.
34
4.3. Diseño
Figura 4.37: Configuración del servidor
4.3.3. Módulos y Funcionalidades
Página Principal
En la página de bienvenida o home, aparecen todos los vuelos de Privilege Style
dados de alta, con la siguiente información: Air carrier, número de vuelo, tipo de vuelo,
aeropuertos de salida y de llegada, fecha de salida, hora local de salida, matrícula y el
número total de pasajeros incluidos en la PNL. Estos datos se pueden ordenar por el
campo que interese y se pueden realizar búsquedas de vuelos filtrando por todos los
campos. Además, se puede elegir el número de vuelos para visualizar en pantalla (entre
10 y 100 entradas, o verlos todos).
Figura 4.38: Página de Bienvenida de la Aplicación
View: para entrar en el vuelo ya creado y obtener información más detallada
del mismo. Debajo aparece todo el listado de pasajeros. Es editable y permite
modificar cualquiera de los datos de vuelo y pasajeros.
Edit: permite modificar datos del vuelo.
Delete: permite cancelar un vuelo, eliminándolo así del listado.
Open Flight /Status: Un vuelo solo puede estar OPEN (enmarcado en color verde
cuando no se ha enviado PNL y azul si está enviada) o CLOSED(enmarcado de
color rojo). Si está cerrado se muestra el icono de un ojo que permite abrir de
35
4. DESARROLLO
nuevo el vuelo. Solo podrá realizar modificaciones el personal con los corres-
pondientes permisos, y una vez cerrado el vuelo cualquier modificación quedará
registrada con el usuario.
Gestión de Vuelos
Acceso a nuevo Vuelo: botón que permite dar de alta un vuelo nuevo. La informa-
ción del vuelo se debe introducir en mayúsculas y debe ser exactamente igual
a la información de la Hoja Excel de entrada de datos. Además, se puede des-
cargar la versión más actualizada de esta hoja en el enlace EXCEL PASSENGERS
TEMPLATE.
Figura 4.39: Acceder a la creación del vuelo
Creación y de edición de un Vuelo: pulsando el botón NEW FLIGHT se abre la
pantalla FLIGH FORM para dar de alta un vuelo nuevo con los siguientes campos
(los registros de deben ser exactamente iguales a los del archivo CSV importado):
Figura 4.40: Creación del vuelo
1. Air Carrier: actualmente se solita a todos los Agentes de Handling que abran
los vuelos en sus DCS como P6 (código IATA de 2 caracteres de Privilege
Style), aunque también se están utilizando PVG y 9-.
2. Flight number: sólo se introducirá el número de vuelo, sin código de com-
pañía.
3. Registration: despliega menú con las matrículas de la flota PVG y sus con-
figuraciones de asientos reales. También, permite acceder a AIR CARRIER
FORM e introducir aviones nuevos.
4. Departure airport: Código IATA de 3 letras del aeropuerto de origen.
5. Departure local time: Hora local de salida del vuelo en formato de 24 horas:
HH:MM.
36
4.3. Diseño
6. Departure date: fecha de salida según la hora local en el origen en formato
DD-MM-AAAA.
7. Arrival airport: Código IATA de 3 letras del aeropuerto de destino.
8. Arrival local time: Hora local de llegada del vuelo en formato de 24 horas en
formato DD-MM-AAAA.
9. Arrival date: fecha de llegada del vuelo según la hora local en el destino en
formato DD-MM-AAAA.
10. Select file: para importar listado de pasajeros desde archivo CSV.
11. Excel passengers template: permite descargar el archivo Excel actualizado
para cumplimentar con los datos de pasajeros enviados por el cliente.
12. Flight type: indica el tipo de vuelo según sea schengen, internacional, do-
méstico o especial. Si se deja vacío, el vuelo se crea por defecto según la
normativa actual correspondiente, teniendo en cuenta los aeropuertos de
origen y destino.
13. Register new flight: Registra todos los datos del vuelo creando una línea
nueva en el listado de vuelos de Privilege Style.
Datos de un Vuelo: para acceder a un vuelo creado, tenemos que dirigirnos a la
sección de view flight en la tabla de vuelos.
Figura 4.41: Datos del Vuelo
Cuando accedemos al vuelo, muestra todos los datos del vuelo, con la siguiente
información:
1. Tipo de vuelo: Schengen, internacional, doméstico o especial.
2. Configuración del avión.
3. Matrícula y Cía. Transportista.
4. Pasajeros totales por clases. Además desglose por clases de asientos y avisa
de si hay niños y/o bebés.
5. Pasajeros embarcados: total de pax embarcados tras reconciliación con
PRL/Passenger Final Sales (PFS).
6. Pasajeros procesables ?PROCESSABLE?: son aquellos que tienen introduci-
da toda la información necesaria para ser incluidos y enviados en la PNL.
37
4. DESARROLLO
7. Pasajeros no procesables ?UNPROCESSABLE?: en color azul, son aquellos a
los que les falta algún dato obligatorio en función del tipo de vuelo y serán
incluidos de una forma especial en la PNL.
8. Aeropuertos de salida y llegada.
9. Horas locales de salida y llegada.
10. Fechas de salida y llegada del vuelo (según horarios locales de origen y
destino).
11. PNL enviada (TRUE) o no (FALSE).
12. Direcciones SITA y/o de correo electrónico donde se ha enviado la PNL.
Figura 4.42: Vista en un Vuelo ya Creado
Procesos dentro de un vuelo: seguidamente a los datos del vuelo se disponen una
serie de botones que permiten realizar distintos procesos:
1. Load Passengers list with CSV file: carga el listado de pasajeros del archivo
CSV dentro del vuelo en el que se está trabajando.
Figura 4.43: Cargar Pasajeros desde una lista en CSV
2. Create New Passenger: permite añadir pasajeros de forma individual antes
del envío de la PNL. Si se crea un nuevo pasajero tras el envío inicial de
la PNL, se genera un mensaje ADL, que llegará directamente al DCS de la
base.
38
4.3. Diseño
Figura 4.44: Crear Nuevo Pasajero desde la Aplicación
3. Modify flight and passengers to unsent: es un botón de emergencia que
permite el reenvío de PNL en caso de error de envío/recepción, modifica el
estatus del vuelo y pasajeros a NO ENVIADOS.
Figura 4.45: Modificar Vuelo y Pasajeros a su Estado de no Enviado
4. Edit flight: edita el vuelo para modificar cualquiera de los datos.
Figura 4.46: Editar un Vuelo
5. Start itinerary report: genera un documento donde aparecen todos los deta-
lles del pasajero y su itinerario. Es un documento meramente informativo y
no equivale a un título de transporte o billete de viaje, aunque es la intención
que tiene para un futuro.
39
4. DESARROLLO
Figura 4.47: Crear Itinerario de Viaje
6. Start checking: una vez despegado el avión y tras la recepción de los listados
PFS y PRL, se puede realizar la reconciliación de pax de forma manual, se-
leccionando aquellos que han volado, y así cerrar el vuelo en la plataforma.
Figura 4.48: Realizar Conciliación de Pasajeros Manual
7. Start multiple delete: sirve para cancelar pasajeros, en bloque o individual-
mente.
40
4.3. Diseño
Figura 4.49: Eliminación Múltiple de Pasajeros
A continuación se detallan los procesos de la parte superior.
Figura 4.50: Procesos de la Parte Superiorde la Página
8. Send PNL: donde se introducirá la dirección sita para el envío de la lista de
pasajeros PROCESABLES. Por defecto, se recibirá una copia de todos los
envíos PNL y ADL en la dirección PMIPVP6. Para acceder solo tenemos que
darle al botón de Send PNL, cuando cargue la página, se mostrará el campo
donde se introducen las direcciones SITA y/o dirección de correo electró-
nico (si aplica) de destino. Se pueden añadir tantas como sean requeridas.
Estas quedarán guardadas y visibles debajo de los datos del vuelo.
Figura 4.51: Formulario de Envío de PNLs
En el listado de vuelos, la línea aparecerá en color azul una vez enviada la
PNL: Flight opened and PNL sent.
Todos los envíos de PNL/ADL generan un e-mail de envío automático al
departamentos de control de operaciones con el desglose de pasajeros por
género: M/F/CHD/INF, a tener en cuenta para el despacho de vuelo.
41
4. DESARROLLO
Tras el envío inicial de la PNL, los posibles cambios en cuanto a pasajeros,
documentación obligatoria, etc., siempre y cuando se haga dentro del tiem-
po establecido (antes del comienzo de la facturación), serán enviados de
forma automatizada desde la plataforma con un mensaje ADL, por defecto,
a la misma dirección de la PNL.
9. Generate PNL as TXT: genera la PNL en formato de texto.
10. Generate ICTS CSV report: archivo en formato específico para envío de
Información Anticipada sobre los Pasajero (API).
11. Generate PAX CSV report: archivo conteniendo todos los pasajeros en el
mismo formato del CSV original.
12. Generate eXtensible Markup Language (XML): mensaje en formato XML
para envío de API.
13. Passengers Report: genera un listado de pasajeros en formato PDF, que con-
tiene toda la información del vuelo y de pasajeros: nº de billete, Passengers
Name Register (PNR), nombre y apellidos, asiento, grupo, observaciones,
requerimientos especiales, si llevan bebé y si han sido reconciliados, total de
pax en la PNL, total reconciliados y además, no reconciliados y desglosados
por Male/Femail/CHD/INF.
14. Flight Departure: Una vez despegado el avión, el Agente de Handling, según
requerimiento de Privilege Style, deberá reportar los siguientes mensajes
con propósito de reconciliación de pasajeros:
• PRL: contiene toda la información del pasajero cargada en la PNL/PNR
que previamente fue enviada al DCS para el proceso de facturación.
• PFS: contiene recuento de pasajeros que han embarcado, con los cam-
bios producidos entre lo reservado y lo finalmente procesado.
Las modificaciones de pasajeros que se realicen una vez superada la fecha y
hora de salida del vuelo, no generarán mensaje ADL, de esta forma se puede
realizar chequeo manual de pasajeros para cerrar el vuelo sin correr el riesgo
de enviar mensajes una vez ha salido el vuelo. A la recepción de PRL/PFS, un
proceso de la aplicación realizará un chequeo automático que reconciliará a
los pasajeros que finalmente han volado, creará los que no estaban enviados
inicialmente y marcará como UNCHECKED los que no hayan embarcado.
Tras este proceso, se cerrará el vuelo de forma automática.
15. Conversión de EXCEL a CSV: para importar la lista de pasajeros recibida del
cliente se debe, previamente, convertir la Hoja Excel de entrada de datos
preparada a tal efecto, en archivo con formato CSV. Se usarán los comandos
Ctrl+T, y se guardará donde interese recuperarla posteriormente.
Gestión de Aviones
Ver información de aviones: se muestra una tabla de la flota actual de PRIVILEGE
STYLE con la siguiente información y los siguientes campos:
42
4.3. Diseño
Figura 4.52: Vista de Información de Aviones
1. Registration: matrícula del avión con formato XX-XXX o X-XXXX.
2. Code: código que indica la configuración física de asientos del avión por
clases.
3. Total passengers: capacidad total de pasajeros del avión.
4. Model: tipo de avión.
5. Airline: aerolínea a la que pertenece el avión.
6. Date of manufacture: fecha de fabricación.
7. Remark: permite añadir cualquier información adicional respecto al avión.
8. View seating plan: se despliega AIRCRAFT DATA con la información del
avión y toda la disposición de asientos y clases.
9. Edit aircraft: deriva a la pantalla AIR CARRIER FORM y permite desde aquí
modificar los datos.
10. Delete aircraft: elimina el avión.
Creación y Edición de un Avión: este botón permite dar de alta un nuevo avión
desde AIR CARRIER FORM, donde es obligatorio cumplimentar todos los campos.
Desde el enlace EXCEL SEATS TEMPLATE se descarga la plantilla donde se deben
incluir todos y cada uno de los asientos del avión seguidos de la clase, coincidien-
do con la configuración real y la capacidad del avión (total de pasajeros) para
posteriormente cargarlos en la plataforma.
Además, permite que la aplicación localice las líneas en caso de repetición de
asientos en la hoja Excel, y no permite importar el archivo CSV, dando un men-
saje de error. Tras el proceso de registro se creará una nueva línea en VIEW
AIRCRAFTS.
Figura 4.53: Formulario de Creación de Aviones
43
4. DESARROLLO
Gestión de Pasajeros
Ver Lista de Pasajeros:función que permite localizar a un pasajero de entre todos
los vuelos cargados en el sistema.
Figura 4.54: Lista de Pasajeros
Se puede ajustar la búsqueda poniendo cualquier campo que sirva para filtrar.
Si separamos las palabras con espacio permite buscar en varias columnas a la
vez. Además de poder ver un listado completo de todos los pasajeros y todos los
vuelos, también podemos ver los pasajeros de cada vuelo en la vista del vuelo.
Figura 4.55: Lista de Pasajeros de un Vuelo Concreto
Creación y Edición de un Pasajero: si se edita un pasajero, se deriva a una pantalla
que contiene toda su información, donde se puede modificar o añadir informa-
ción: asientos, requerimientos especiales, observaciones, etc. También puede
accederse desde la vista de un vuelo. Además, todas las modificaciones que se
hagan tras el envío de la PN! (PN!) serán destinadas a la base con un mensaje
ADL.
Figura 4.56: Formulario para la Creación y Edición de Pasajeros
44
4.3. Diseño
Gestión de Aerolíneas
Todas las aerolíneas con las que se realicen vuelos deben ser previamente dadas
de alta en la plataforma por el administrador del sistema, está dirección servirá para
realizar el envío automático de desglose de pasajeros (esta información se facilita a
efecto de despacho de vuelos).
Figura 4.57: Lista de Aerolíneas Registradas
Errores
Los datos de vuelo introducidos no son correctos: no se importa el listado de
pasajeros / NO se carga PNL.
Motivo:
1. No coinciden los datos del vuelo cargado en PRIVIPAX con los que contiene
el archivo CSV que queremos importar.
2. Alguna información no tiene el formato correcto en la hoja Excel.
Solución:
1. Editar y modificar el vuelo en PRIVIPAX o modificar la Hoja Excel y volver a
importar, dependiendo de donde se encuentre la información incorrecta.
El Total de Pasajeros Importados no Corresponden en Número con los Pasajeros
de la hoja Excel: si se importa el listado de pasajeros, no se cargan todos los
pasajeros o si permite envío de PNL.
Motivo:
1. No se han introducido datos correctamente en la hoja Excel.
Solución:
1. Corregir hoja Excel añadiendo tipo de pasajero. Cancelar la lista de pasajeros
incompleta importada, y volver a importar la lista corregida.
Error de Asientos Duplicados: no carga la PNL.
Motivo:
45
4. DESARROLLO
1. El cliente ha asignado asientos iguales a más de un pasajero.
Solución:
1. La aplicación detecta los nombres de los pasajeros y las filas correspondien-
tes en la hoja Excel. Se deben corregir en esta hoja para poder importar
listado, bien cambiando asientos o bien dejándolos en blanco.
Error de Documentos Duplicados: no carga la PNL.
Motivo:
1. Existen pasajeros con duplicidad en el número de pasaporte.
Solución:
1. Dejar el número en blanco y se cargará el pasajero aunque aparecerá como
no procesable si se trata de un vuelo internacional o especial.
Fallo en el Envío del PNL: En caso de que se produzca un fallo en elenvío de
la PNL por motivos ajenos a la aplicación, como fallos en el servidor DCS de
destino, u otros problemas relacionados con direcciones SITA, se procederá de la
siguiente manera:
1. Envío del archivo Excel con la información de los pasajeros directamente al
handling. Se procesará la información directamente en los mostradores de
facturación.
2. Envío desde sistema local del departamento de informática que crearán
vuelo nuevo, se cargará la lista de pasajeros con formato PNL y se procederá
al envío con la ayuda de los técnicos.
4.4. Testing
Cada vez que se añade una nueva funcionalidad, se prueba en local con vuelos de
prueba y con cuentas de correo personales. Si todo está bien, el SCRUM Master da el
visto bueno y se sube a producción.
Seguidamente, el testeo de la aplicación pasa a realizarse por los operarios que van
a utilizar el sistema, ellos son los encargados de probar las nuevas funcionalidades y
en el caso de necesitarlo, contactar con los handling de los aeropuertos para hacer
pruebas en entornos reales.
46
C
A
P
Í
T
U
L
O
5
RESULTADOS Y DISCUSIÓN
Actualmente la aplicación está siendo usada por los departamentos de Operaciones
Tierra y Operaciones Vuelo de la empresa y ya se han registrado más de 1.000 vuelos y
más de 200.000 pasajeros.
Los distintos organismos que realizan las auditorias en la empresa, tanto en el ám-
bito de seguridad, como en el operacional y también el legislativo, están muy contentos
con la rapidez y la efectividad que aporta la aplicación para recoger la información
relativa a los pasajeros y los vuelos, ya que siempre se cierran los vuelos con los datos
reales. Además, proporciona toda clase de reportes que muestran el procedimiento y la
información obtenida y/o enviada en cada una de las fases del vuelo.
Vistos los datos obtenidos, la empresa ha decidido por seguir apostando en la rea-
lización de aplicaciones propias personalizadas, siendo esta la primera de las cinco
que actualmente están funcionando en producción (gestión de tripulaciones, ges-
tión de riesgos asociados a la seguridad, directorio de Handling, Intranet y Customer
Relationship Management (CRM)).
El objetivo principal de la empresa es obtener una serie de aplicaciones, actual-
mente semi-conectadas, para poder ofrecer una plataforma común a todos los depar-
tamentos, y que así, la información sea manipulada por todos los trabajadores de la
empresa dependiendo de los permisos que hayan sido configurados, evitando duplicar
la información y obteniendo la información de forma centralizada.
47
C
A
P
Í
T
U
L
O
6
CONCLUSIÓN Y LÍNEAS DE FUTURO
En este último apartado se describen las conclusiones posteriores a la realización
del Trabajo Final de Grado (TFG), a fin de revisar los objetivos que fueron planteados en
los distintos apartados durante su realización y para comprobar el grado de satisfacción
de cada uno de ellos.
Tras este análisis se introducen algunas líneas futuras donde se podrían seguir
avanzando en la creación de funcionalidades del proyecto, en este caso, de la apli-
cación. El presente TFG ha tenido como resultado la creación de una aplicación de
vuelos amigable y sencilla que permite obtener información de los vuelos, los pasajeros
asociados a estos vuelos, los aviones disponibles, la configuración de asientos y las
aerolíneas que recibirán los datos para procesar los pasajeros de dichos vuelos.
6.1. Conclusiones
En este apartado se describen una serie de objetivos que se plantearon para la reali-
zación del Trabajo Fin de Grado y se exponen las conclusiones sobre su cumplimiento:
1. Se ha llevado a cabo una evaluación de soluciones existentes, donde se ha ana-
lizado el desarrollo de aplicaciones, la selección de tecnologías a utilizar y el
desarrollo de un análisis de requisitos para la aplicación.
2. Se ha conseguido la creación de una interfaz con capacidad de mostrar la infor-
mación necesaria de forma intuitiva y sin la necesidad de realizar muchos pasos
para llegar a los objetivos.
3. Se ha conseguido que la aplicación muestre los vuelos, pasajeros, aerolíneas y
aviones para tener un control de esta información y crear un espacio común para
la gestión de estos datos.
49
6. CONCLUSIÓN Y LÍNEAS DE FUTURO
4. Y por último, gracias a todos los objetivos planteados, se ha logrado el desa-
rrollo de una aplicación multiplataforma, robusta y eficiente, disponible desde
cualquier plataforma simplemente utilizando un navegador web.
Tras haber cumplido los objetivos principales planteados, se puede llegar a la con-
clusión de que se ha alcanzado satisfactoriamente los objetivos del TFG.
La realización de este TFG ha conllevado un amplio estudio sobre los formatos PNL,
ADL, PRL, PFS, sobre las tecnologías para crear procesos automatizados, creación de
PDF, CSV y EXCEL, la lectura de CSV y el envío y lectura de correos de forma automa-
tizada. Además de ampliar los conocimientos en herramientas como, JQuery, HTML,
CSS, Javascript, SPRING MVC, Hibernate y JPA 2.0.
Durante el desarrollo de la aplicación se han presentado diversas dificultades a las
que me he tenido que enfrentar, como el desconocimiento total de algunas tecnolo-
gías o dificultades en las consultas, transferencias de archivos y configuración de la
estructura.
Cabe decir que el presente TFG ha sido una labor enriquecedora, proporcionando
y reforzando conocimientos. Gracias a éste he adquirido experiencia de cómo enfren-
tarme a problemas reales a la hora de realizar una aplicación web.
6.2. Líneas de Futuro
Para finalizar, en este apartado se presentarán posibles líneas de futuro para esta
aplicación. Éstas pueden ser estudiadas y desarrolladas con gran probabilidad conti-
nuando con el trabajo ya realizado.
Esta aplicación es solo el comienzo de un conjunto de aplicaciones relacionadas
con la aviación. Se pretende crear un conjunto de aplicaciones que estén relacionadas
y que permitan la obtención de toda la información posible sobre un vuelo operado
por la compañía. Estas aplicaciones que se plantean para un futuro son:
1. Aplicación para el control de equipajes de pasajeros.
2. Automatización para generar las tarjetas de embarque.
3. Aplicación de catering enlazada a los vuelos.
4. Aplicación de incidencias, mejoras y modificaciones necesarias para aplicar en
los vuelos.
5. Aplicación para el mantenimiento de los aviones. Incluye todo tipo de piezas del
avión, cambios y repuestos.
6. Aplicación para la gestión de tripulaciones de un vuelo. Esto incluye la organiza-
ción de las tripulaciones añadiendo condiciones para saber si ese tripulante está
habilitado para volar en ese vuelo y si se pasa de las horas de trabajo estipuladas
por la normativa y/o la ley.
7. Aplicación para visualizar el estado de los aviones, su ubicación y planificación
diaria, semanal, mensual y anualmente.
8. Mejora de la interfaz y mejora del diseño responsive.
50
A
P
É
N
D
I
C
E
A
RESUMEN DEL PROCESO DE ENVÍO Y
RECEPCIÓN DE INFORMACIÓN DE UN
VUELO
A.1. Solicitud de Nueva Operación de Vuelo
En el momento en que se confirma una nueva operación, se solicita al Agente de
Handling la siguiente información:
Sistema DCS que utiliza.
Direcciones sita o e-mail donde requieren el envío de PNL’s. Se les informa
además de la dirección sita para envío y recepción de mensajes de Privilege Style
como recordatorio: PMIPVP6.
A.2. Previo al Vuelo
Se solicita vía e-mail que abran el vuelo en su DCS con el prefijo IATA de 2 caracteres
de la cía. P6, con la configuración física del avión programado. En algunas bases se abre
con PVG.
Posteriormente, se les informará del número total de pasajeros (adultos + INF)
incluidos en la PNL.
A.3. Creación del Vuelo
Se crea el nuevo vuelo en la plataforma.
51
A. RESUMEN DEL PROCESO DE ENVÍO Y RECEPCIÓN DE INFORMACIÓN DE
UN VUELO
A.4. Gestión y Envío de la PNL
1. Recepción de la Hoja Excel de entrada de datos en el formato a tal efecto.
2. Revisión de datos (información del vuelo y campos obligatorios) y corrección
(mayúsculas, caracteres especiales,etc.).
3. Conversión del archivo Excel a formato CSV con los comandos CTRL+T.
4. Desde FLIGHT DATA se pulsa Examinar para localizar el archivo CSV y se importa
la lista de pax pulsando Load Pax List with CSV file.
5. Verificar que la PNL se ha cargado correctamente en PRIVIPAX: pasajeros totales,
no procesados, información obligatoria, tipo de vuelo, requerimientos especiales,
INF, comidas, etc.
6. Enviar PNL.
A.5. Confirmación de Recepción de un Vuelo
Tras el envío de la PNL se solicitará al Agente de Handling vía e-mail, ACK de la
correcta recepción, confirmando el total de pasajeros.
Les indicaremos además los nombres de los pasajeros UNPROCESSABLE (desde
la exportación del PNL en la vista del vuelo), que se presentarán en el mostrador de
facturación y donde se deberán verificar sus datos.
Se les recordará que inmediatamente después de la salida del vuelo deben reportar
los listados PFS y PRL para reconciliación de pasajeros y archivo documental.
A.6. Cambios de Última Hora
Cualquier cambio de última hora dentro del tiempo límite establecido, será enviado
automáticamente desde la plataforma en un mensaje ADL, y por defecto a la misma
dirección sita donde se envió la PNL.
Se solicitará ACK al Agente de Handling de la recepción de estos cambios.
A.7. Cierre de un Vuelo
A la recepción de los listados PFS y PRL se realizará chequeo automático de recon-
ciliación de pasajeros y cierre del vuelo. En el passengers report aparecerá el total de
pasajeros que han subido al vuelo, según aparezcan o no en estos listados. Se puede
hacer reconciliación manual de pasajeros (según necesidades) con el botón de start
checking en la vista del vuelo. En este caso, se crearán los pasajeros nuevos y se mar-
carán todos los que han volado. Al finalizar con finish checking, quedarán listados los
pasajeros embarcados y se cerrará el vuelo.
52
BIBLIOGRAFÍA
[1] “Stack overflow tags,” 04/09/2016. [Online]. Available: http://stackoverflow.com/
tags 3
[2] “Jpa,” 04/09/2016. [Online]. Available: http://www.oracle.com/technetwork/java/
javaee/persistence-jsp-136066.html 3.1
[3] “Hibernate,” 04/09/2016. [Online]. Available: http://hibernate.org/orm/ 3.1
[4] “Jsp,” 04/09/2016. [Online]. Available: https://es.wikipedia.org/wiki/JavaServer_
Pages 3.2
[5] “Velocity,” 04/09/2016. [Online]. Available: http://velocity.apache.org/engine/1.7/
translations/user-guide_es.html 3.2
[6] “Freemarker,” 04/09/2016. [Online]. Available: http://freemarker.org/ 3.2
[7] “Thymeleaf,” 04/09/2016. [Online]. Available: http://www.thymeleaf.org/
documentation.html 3.2
[8] “Html5,” 04/09/2016. [Online]. Available: https://developer.mozilla.org/es/docs/
HTML/HTML5 3.2
[9] “Css3,” 04/09/2016. [Online]. Available: https://developer.mozilla.org/es/docs/
Web/CSS/CSS3 3.2
[10] “Bootstrap,” 04/09/2016. [Online]. Available: http://getbootstrap.com/ 3.2
[11] “Javascript,” 04/09/2016. [Online]. Available: https://developer.mozilla.org/es/
docs/Web/JavaScript 3.2
[12] “Jquery,” 04/09/2016. [Online]. Available: https://jquery.com/ 3.2
[13] “Spring mvc,” 04/09/2016. [Online]. Available: http://docs.spring.io/spring/docs/
current/spring-framework-reference/htmlsingle/ 3.3
[14] “Maven,” 04/09/2016. [Online]. Available: https://maven.apache.org/ 3.4
[15] “Maven repository,” 04/09/2016. [Online]. Available: https://mvnrepository.com/
3.4
[16] “Git,” 04/09/2016. [Online]. Available: https://git-scm.com/ 3.5
[17] “Github,” 04/09/2016. [Online]. Available: https://github.com/ 3.5
53
http://stackoverflow.com/tags
http://stackoverflow.com/tags
http://www.oracle.com/technetwork/java/javaee/persistence-jsp-136066.html
http://www.oracle.com/technetwork/java/javaee/persistence-jsp-136066.html
http://hibernate.org/orm/
https://es.wikipedia.org/wiki/JavaServer_Pages
https://es.wikipedia.org/wiki/JavaServer_Pages
http://velocity.apache.org/engine/1.7/translations/user-guide_es.html
http://velocity.apache.org/engine/1.7/translations/user-guide_es.html
http://freemarker.org/
http://www.thymeleaf.org/documentation.html
http://www.thymeleaf.org/documentation.html
https://developer.mozilla.org/es/docs/HTML/HTML5
https://developer.mozilla.org/es/docs/HTML/HTML5
https://developer.mozilla.org/es/docs/Web/CSS/CSS3
https://developer.mozilla.org/es/docs/Web/CSS/CSS3
http://getbootstrap.com/
https://developer.mozilla.org/es/docs/Web/JavaScript
https://developer.mozilla.org/es/docs/Web/JavaScript
https://jquery.com/
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/
http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/
https://maven.apache.org/
https://mvnrepository.com/
https://git-scm.com/
https://github.com/
BIBLIOGRAFÍA
[18] “Heroku,” 04/09/2016. [Online]. Available: https://www.heroku.com/ 3.5
[19] “Postgresql,” 04/09/2016. [Online]. Available: https://www.postgresql.org/ 3.6
[20] “Pgadmin,” 04/09/2016. [Online]. Available: https://www.pgadmin.org 3.6
[21] “Tomcat,” 04/09/2016. [Online]. Available: http://tomcat.apache.org/ 3.7
[22] “Java ee,” 04/09/2016. [Online]. Available: http://www.oracle.com/technetwork/
java/javaee/documentation/index.html 3.7
[23] “Ejb,” 04/09/2016. [Online]. Available: https://es.wikipedia.org/wiki/Enterprise_
JavaBeans 3.7
[24] “Jboss,” 04/09/2016. [Online]. Available: http://www.jboss.org/ 3.7
[25] “Eclipse,” 04/09/2016. [Online]. Available: https://eclipse.org/home/index.php
3.9
[26] “itext,” 04/09/2016. [Online]. Available: http://itextpdf.com/ 3.10
[27] “Mimemessage,” 04/09/2016. [Online]. Available: http://docs.oracle.com/javaee/
6/api/javax/mail/internet/MimeMessage.html 3.10
[28] “Jackson,” 04/09/2016. [Online]. Available: https://github.com/FasterXML/
jackson 3.10
[29] “Log4j,” 04/09/2016. [Online]. Available: http://logging.apache.org/log4j/2.x/ 3.10
[30] “Opencsv,” 04/09/2016. [Online]. Available: http://opencsv.sourceforge.net/ 3.10
[31] “Scrum,” 04/09/2016. [Online]. Available: https://proyectosagiles.org/
que-es-scrum/ 4
54
https://www.heroku.com/
https://www.postgresql.org/
https://www.pgadmin.org
http://tomcat.apache.org/
http://www.oracle.com/technetwork/java/javaee/documentation/index.html
http://www.oracle.com/technetwork/java/javaee/documentation/index.html
https://es.wikipedia.org/wiki/Enterprise_JavaBeans
https://es.wikipedia.org/wiki/Enterprise_JavaBeans
http://www.jboss.org/
https://eclipse.org/home/index.php
http://itextpdf.com/
http://docs.oracle.com/javaee/6/api/javax/mail/internet/MimeMessage.html
http://docs.oracle.com/javaee/6/api/javax/mail/internet/MimeMessage.html
https://github.com/FasterXML/jackson
https://github.com/FasterXML/jackson
http://logging.apache.org/log4j/2.x/
http://opencsv.sourceforge.net/
https://proyectosagiles.org/que-es-scrum/
https://proyectosagiles.org/que-es-scrum/
	Índice general
	Índice de figuras
	ACRÓNIMOS
	RESUMEN
	1 INTRODUCCIÓN
	2 OBJETIVOS
	2.1 Generales
	2.2 Particulares
	3 TECNOLOGÍAS
	3.1 Modelo
	3.2 Vista
	3.3 Controlador
	3.4 Herramienta de Construcción y Compilación de Proyectos
	3.5 Control de Versiones
	3.6 Base de Datos
	3.7 Servlet Container
	3.8 Sistema Operativo
	3.9 Entorno de desarrollo
	3.10 Otras Tecnologías y/o Frameworks
	4 DESARROLLO
	4.1 Definición del proyecto
	4.2 Beneficios
	4.3 Diseño
	4.3.1 Base de Datos
	4.3.2 Estructura
	4.3.3 Módulos y Funcionalidades
	4.4 Testing
	5 RESULTADOS Y DISCUSIÓN
	6 CONCLUSIÓN Y LÍNEAS DE FUTURO
	6.1 Conclusiones
	6.2 Líneas de Futuro
	A RESUMEN DEL PROCESO DE ENVÍO Y RECEPCIÓN DE INFORMACIÓN DE UN VUELO
	A.1 Solicitud de Nueva Operación de Vuelo
	A.2 Previo al Vuelo
	A.3 Creación del Vuelo
	A.4 Gestión y Envío de la PNL
	A.5 Confirmación de Recepción de un Vuelo
	A.6 Cambios de Última Hora
	A.7 Cierre de un Vuelo
	Bibliografía