Arias_CL

Vista previa del material en texto

Sistema para la Gestión del Registro
Técnico de Vuelo para la aviación comercial
Item Type info:eu-repo/semantics/bachelorThesis
Authors Arias Camacho, Lenny; Cabezas Piedra, Luis Bernardo
Publisher Universidad Peruana de Ciencias Aplicadas (UPC)
Rights Attribution-NonCommercial-ShareAlike 4.0 International;
info:eu-repo/semantics/openAccess
Download date 11/02/2024 21:53:27
Item License http://creativecommons.org/licenses/by-nc-sa/4.0/
Link to Item http://hdl.handle.net/10757/671032
http://creativecommons.org/licenses/by-nc-sa/4.0/
http://hdl.handle.net/10757/671032
 
 
 
 
UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS 
FACULTAD DE INGENIERÍA 
 
PROGRAMA ACADÉMICO DE INGENIERÍA DE SISTEMAS 
 
Sistema para la Gestión del Registro Técnico de Vuelo para la aviación 
comercial 
 
TRABAJO DE SUFICIENCIA PROFESIONAL 
Para optar el título profesional de Ingeniero de Sistemas 
 
AUTOR(ES) 
Arias Camacho, Lenny 0000-0002-8478-4935 
Cabezas Piedra, Luis Bernardo 0009-0004-1648-8757 
 
ASESOR(ES) 
Burga Durango, Daniel Wilfredo 0000-0003-0312-727X 
 
 
Lima, 14 de noviembre de 2023 
 
DEDICATORIA 
 
Terminar este proyecto no hubiera sido posible sin el apoyo de mis padres Bernardo y 
Justina, que me apoyaron en todo momento brindándome su amor, trabajo y sacrificio. 
Gracias por enseñarme a afrontar las dificultades sin perder nunca la cabeza ni morir en el 
intento. Gracias a ustedes he podido lograr llegar hasta aquí, ha sido un orgullo y privilegio 
ser su hijo. A mis hermanos por estar siempre presentes, acompañándome y regalarme su 
apoyo moral. Mi sobrina Valeria que me inspira a seguir saliendo adelante. Y a ese último 
amor que a lo largo de mi vida me alentó a terminar el proyecto, me enseño y regalo los 
más lindos momentos. 
Luis Bernardo Cabezas Piedra 
 
 
A mi padre quien fue y siempre será mi guía y mi mayor inspiración. A mi hermano quien 
es uno de los profesionales que más admiro en esta vida. 
Lenny Arias Camacho 
 
 
 
 
 
 
 
 
 
AGRADECIMIENTOS 
 
Le brindamos un agradecimiento especial al Sr. Iván Esparta, quien tuvo la visión de 
innovar en el mercado aeronáutico peruano con este proyecto y no dudó en brindar todo su 
apoyo y dedicación para lograr su realización. 
 
RESUMEN 
Gestionar el Registro Técnico de Vuelo (RTV) físicamente implica el transporte constante 
entre las áreas que intervienen en el proceso de vuelo. Los documentos pueden desde 
extraviarse e impedir realizar la siguiente etapa del proceso que significa riesgos económicos 
hasta poner en peligro la vida de las personas. 
El grupo oficial de documentos tiene validez solo en su versión original, tener copia de los 
documentos no es óptimo pues debe mantenerse actualizado con la información real y 
fidedigna, lo que implica arriesgar la información de muchos registros, así como una 
compleja carga de datos físicos para todos los operarios del proceso. 
Se requería contar con la información a disposición en cualquier momento, por ello se optó 
por una aplicación móvil con posibilidad de operar fuera de línea. Todo ello de la mano de 
una aplicación web que permita el control y administración de los documentos para el 
personal de operaciones. 
Luego de la implementación se lograron hitos importantes como, la reducción casi total de 
los tiempos en el transporte y/o consulta de documentos, se redujo el índice de documentos 
corregidos. La emisión de informes legales e indicadores operativos y gestión se automatizó 
en su totalidad. Se identificaron brechas de seguridad que significaban riesgos operativos. 
Se descentralizó el trabajo operativo ya que, un piloto podía trabajar a la par en un RTV que 
un mecánico. Fue evaluado y avalado por la autoridad aeroportuaria que, inspeccionó la 
implementación del proyecto y brindo el visto bueno para la migración a las operaciones 
digitales. 
 
Palabras clave: Registro técnico de vuelo; aviación comercial; aplicación móvil; aplicación 
web. 
 
System for the Management of the Technical Flight Record for a Commercial Airline 
ABSTRACT 
Managing the Flight Technical Log (FTR) physically involves constant transportation 
between the areas involved in the flight process. The documents can go astray and prevent 
the next step of the process from being carried out, which means economic risks or even 
endangering people's lives. 
The official set of documents is only valid in its original version, having a copy of the 
documents is not optimal because it must be kept updated with real and reliable information, 
which implies risking the information of many records, as well as a complex load of physical 
data for all the operators of the process. 
It was necessary to have the information available at any time, so a mobile application with 
the possibility of operating offline was chosen. All this hand in hand with a web application 
that allows the control and management of documents for operations personnel. 
After the implementation, important milestones were achieved, such as the almost total 
reduction of time in the transport and/or consultation of documents, the rate of corrected 
documents was reduced. The issuance of legal reports and operational and management 
indicators was fully automated. Security breaches that represented operational risks were 
identified. Operational work was decentralized, since a pilot could work at the same time in 
an RTV as a mechanic. It was evaluated and endorsed by the airport authority, which 
inspected the implementation. 
Keywords: technical flight log; commercial aviation; mobile app; Web Application. 
 
 
 
TABLA DE CONTENIDOS 
1 CAPÍTULO 1: DEFINICIÓN DEL PROYECTO ................................................. 11 
1.1 ANTECEDENTES ................................................................................................... 11 
1.2 DESCRIPCIÓN DE LA ORGANIZACIÓN ................................................................. 11 
1.2.1 Misión .............................................................................................................. 11 
1.2.2 Visión .............................................................................................................. 12 
1.2.3 Valores ............................................................................................................. 12 
1.2.4 Organigrama .................................................................................................... 12 
1.2.5 Cadena de Valor .............................................................................................. 13 
1.3 ANÁLISIS DEL PROBLEMA ................................................................................... 13 
1.3.1 Planteamiento del Problema ............................................................................ 13 
1.4 OBJETIVOS .......................................................................................................... 14 
1.4.1 General............................................................................................................. 14 
1.4.2 Específicos ....................................................................................................... 14 
1.4.3 Indicadores de Éxito ........................................................................................ 15 
1.5 PLANIFICACIÓN DEL PROYECTO ........................................................................ 15 
2 CAPÍTULO 2: MARCO TEÓRICO ....................................................................... 16 
2.1 MARCO CONCEPTUAL ........................................................................................ 16 
2.1.1 Servicios de Azure ........................................................................................... 16 
2.1.2 Registro Técnico de vuelo ............................................................................... 16 
2.1.3 Discrepancia ....................................................................................................17 
2.1.4 JSON ................................................................................................................ 17 
2.2 ESTÁNDARES, FRAMEWORKS Y BUENAS PRÁCTICAS .......................................... 17 
2.2.1 SCRUM ........................................................................................................... 17 
2.2.2 PMBOK ........................................................................................................... 18 
2.2.3 XAMARIN ...................................................................................................... 18 
2.2.4 MVC ................................................................................................................ 18 
2.2.5 MVVM ............................................................................................................ 18 
2.2.6 ASP.NET Web API ......................................................................................... 18 
2.3 BASES LEGALES Y MARCO NORMATIVO ........................................................... 19 
2.3.1 Reglamento D.S. N.º 050-2001-MTC ............................................................. 19 
2.3.2 Resolución Ministerial N.º 361-2011-MTC/02 – Reglamento de Infracciones y 
Sanciones Aeronáuticas ............................................................................................... 19 
2.3.3 Ley N. ª 27261 - Ley de Aeronáutica Civil ..................................................... 19 
2.3.4 Regulaciones Aeronáuticas del Perú. (RAP) Licencias para Pilotos y sus 
Habilitaciones. ............................................................................................................. 19 
3 CAPÍTULO 3: DESARROLLO DEL PROYECTO .............................................. 19 
3.1 DISEÑO DE LA SOLUCIÓN .................................................................................... 20 
3.1.1 Análisis de tecnología para el proyecto ........................................................... 20 
3.2 DESARROLLO DE LA SOLUCIÓN .......................................................................... 24 
3.2.1 AS-IS ............................................................................................................... 24 
3.2.2 Equipo de Proyecto .......................................................................................... 26 
3.2.3 Arquitectura Física .......................................................................................... 28 
3.2.4 Arquitectura Lógica ......................................................................................... 30 
3.2.1 Análisis ............................................................................................................ 32 
3.2.1 Desarrollo ........................................................................................................ 36 
3.3 VALIDACIÓN DEL PROYECTO ............................................................................. 37 
3.3.1 Resultados ........................................................................................................ 41 
3.4 INTERPRETACIÓN DE LOS RESULTADOS ............................................................. 41 
3.5 PLAN DE CONTINUIDAD ...................................................................................... 44 
3.5.1 Objetivo General.............................................................................................. 44 
3.5.2 Objetivo Específicos ........................................................................................ 44 
3.5.3 Beneficios ........................................................................................................ 44 
3.5.4 Roles para el soporte........................................................................................ 45 
3.5.5 Procedimiento de Soporte ................................................................................ 46 
3.5.6 Gestión de Incidentes....................................................................................... 46 
3.5.7 Gestión de problemas ...................................................................................... 47 
3.5.8 Gestión de cambios .......................................................................................... 47 
3.5.9 Gestión de seguridad ....................................................................................... 48 
4 CONCLUSIONES Y RECOMENDACIONES ...................................................... 49 
4.1 CONCLUSIONES .................................................................................................... 49 
4.2 RECOMENDACIONES ............................................................................................. 49 
5 REFERENCIAS ........................................................................................................ 50 
 
ÍNDICE DE TABLAS 
Tabla 1. Descripción del problema y sus antecedes. ............................................................. 4 
Tabla 2. Descripción de los indicadores de éxito. ................................................................. 5 
Tabla 3. Planificación del proyecto. ...................................................................................... 6 
Tabla 4. Descripción de los criterios para Benchmarking. .................................................. 11 
Tabla 5. Priorización de criterios para Benchmarking. ....................................................... 11 
Tabla 6. Benchmarking proveedores en la nube.................................................................. 11 
Tabla 7. Criterios analizados de propuesta escogida. .......................................................... 12 
Tabla 8. Puntuación Benchmarking de Frameworks para aplicativo móvil. ....................... 13 
Tabla 9. Priorización de criterios para Benchmarking. ..................................................... 233 
Tabla 10. Benchmarking Framework aplicaciones móvil. .................................................. 13 
Tabla 11. Criterios analizados de propuesta escogida. ........................................................ 14 
Tabla 12. Resultados de encuesta, medición Likert. ........................................................... 31 
Tabla 13. Resultado en porcentajes tiempos de acceso RTV. ............................................. 32 
Tabla 14. Resultado en porcentajes índice de correcciones RTV. ...................................... 32 
Tabla 15. Resultado de reducción de multas y/o sanciones por extravío de RTV. ............. 33 
Tabla 16. Resultado en porcentajes incremento de seguridad RTV. ................................... 33 
Tabla 17. Resultado en porcentajes índice de perdidas RTV. ............................................. 33 
Tabla 18. Resultado en porcentajes Control de discrepancias RTV.................................... 34 
Tabla 19. Niveles de servicio en procedimiento de Soporte. .............................................. 36 
 
 
 
 
ÍNDICE DE FIGURAS 
Figura 01Organigrama ATSA ............................................................................................. 12 
Figura 02 Cadena valor ATSA ............................................................................................ 13 
Figura 03 AS-IS ................................................................................................................... 26 
Figura 04 Equipo de Proyecto ........................................................................................... 288 
Figura 05 Arquitectura Física .......................................................................................... 3020 
Figura 06 Arquitectura Lógica .......................................................................................... 322 
Figura 07 Estructura Análisis e Implementación. ............................................................. 322 
Figura 08 Diagrama Requerimientos. ................................................................................333 
Figura 09 Mockup de tiempo de vuelo .............................................................................. 355 
Figura 10 Mockup de tiempo de vuelo – Agregar ............................................................. 366 
Figura 11 Tiempo de vuelo desarrollado ........................................................................... 377 
Figura 12 Eficiencia en tiempos de acceso en un RTV. .................................................... 388 
Figura 13 Índice de correcciones de en un RTV. .............................................................. 399 
Figura 14 Índice de reducción en multas y/o sanciones por extravío de en un RTV. ....... 399 
Figura 15 Incremento de seguridad de en un RTV. ......................................................... 4030 
Figura 16 Índice de Registro Técnico de Vuelo extraviados o perdidos. ........................ 4030 
Figura 17 Optimización del control de discrepancias de un RTV. .................................. 4131 
 
 
https://upcedupe-my.sharepoint.com/personal/u201223292_upc_edu_pe/Documents/Titulacion2023/GRUPO17_Arias_Cabezas_Ver_3.2.docx#_Toc150624893
https://upcedupe-my.sharepoint.com/personal/u201223292_upc_edu_pe/Documents/Titulacion2023/GRUPO17_Arias_Cabezas_Ver_3.2.docx#_Toc150624894
CAPÍTULO 1: DEFINICIÓN DEL PROYECTO 
Antecedentes 
Toda aeronave lleva consigo el registro histórico de parámetros y características de sus partes 
y piezas, con el fin de controlar su mantenimiento y posibles fallas que conlleven a riesgos de 
seguridad. 
Las operaciones de aerotransporte en el Perú son normadas por la DGAC (Dirección General 
de Aeronáutica Civil), esta entidad determina las regulaciones, normas y reglamentos que debe 
cumplir todo operador de aerotransporte para poder ejercer funciones en el espacio aéreo del 
Perú. En el 2001, la presidencia de la república aprobó la “Ley de Aeronáutica Civil – Ley 
27261”, mediante decreto supremo, N.º 050-2001-MTC, que, entre sus aspectos más 
resaltantes, determina que la DGAC es la autoridad que supervisa y controla las operaciones 
de aerotransporte en el Perú. En el artículo 27 y 28 de esta ley, se especifica la obligatoriedad 
de llevar consigo siempre el Registro Técnico de Vuelo (Ministerio de Transportes y 
Comunicaciones, 2023). 
Descripción de la Organización 
La organización objeto de estudio Aero Transporte S.A. es una empresa peruana que supera 
los 43 años en el mercado aeronáutico. Se dedica a ofrecer servicios exclusivos de vuelos VIP, 
vuelos de tipo chárter de pasajeros y de tipo chárter de carga, servicios de ambulancia aérea, 
servicio de operaciones de base fija (FBO) y cuenta con taller de mantenimiento aeronáutico 
(TMA) con calidad, enfocándose en la eficiencia y altos estándares de seguridad (Atsa Airlines, 
2023). 
En el año 2017 incursiona en vuelos comerciales con ruta a Chachapoyas y a la actualidad ya 
brinda vuelos con destinos a Tingo María, Huánuco y Punta Sal. Actualmente realiza en 
promedio 10 vuelos diarios. 
Misión 
Atsa Airlines (2023) en su artículo Nosotros, indica que su misión es “Brindar servicios 
aeronáuticos integrales con los más altos estándares de seguridad y calidad con el fin de 
satisfacer las necesidades de nuestros clientes superando sus expectativas” (párr. 2). 
Visión 
Atsa Airlines (2023) en su artículo Nosotros, indica que su visión es “Posicionarnos a nivel 
nacional e internacional como la organización líder en brindar soluciones aeronáuticas 
integrales” (párr. 3). 
Valores 
Se demuestra los valores de la organización objetivo en los siguientes puntos Atsa Airlines 
(2023) publicados en su artículo Nosotros: 
• Seguridad: En cada una de las operaciones. 
• Calidad: En los servicios y atención al cliente. 
• Pasión: Por lo que se hace (párr. 4). 
 
Organigrama 
La organización objetivo cuenta con una gerencia general y sus respectivas gerencias de apoyo, 
las cuales se caracterizan por ser una empresa de servicios. Esta distribución se representa en 
la Figura 01. 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
 
 
Figura 01 
Organigrama ATSA 
 
 
 
 
Cadena de Valor 
En la Figura 02 se muestra la estructura de la cadena de valor de la empresa ATSA. 
 
Figura 02 
Cadena valor ATSA 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Análisis del Problema 
A continuación, se detallará el planteamiento del problema, antecedentes y objetivos. 
Planteamiento del Problema 
El Registro Técnico de Vuelo es un conjunto de documentos legales que son constantemente 
auditados por la Dirección General de Aeronáutica Civil (DGAC). La gestión de esta 
información es realizada por las diferentes áreas que interactúan en el ciclo de vida de un vuelo. 
Por lo tanto, es imprescindible que estos documentos viajen constantemente entre cada uno de 
sus responsables de un vuelo, generando lentitud en su transporte, riesgo de pérdida, daño de 
la información o control ineficiente de la evolución histórica de su información. Esto tiene 
como consecuencia la afectación de los vuelos que puede reflejarse en retraso de las 
operaciones o cancelación de los vuelos (lo que pone en riesgo el prestigio frente a los clientes), 
además de riesgos operativos (que puede generar riesgo en la vida de los operarios, tripulantes 
y clientes) y como problema más grave las multas y sanciones que la normativa dictamine. 
La empresa cuenta con diversos modelos de aeronaves para las cuales se ha diseñado 
documentos (formatos) específicos según sus características (como por ejemplo los parámetros 
de vuelo). 
Los problemas y sus antecedentes son detallaos en la Tabla 1. 
 
Descripción del problema y sus antecedes. 
PROBLEMA ANTECEDENTES 
 
Se generan retrasos, 
perdidas, información 
incorrecta que devienen en 
multas, cancelación de 
vuelos entre otros, debido 
a que la gestión del 
registro técnico de vuelo 
se realiza manualmente, 
llevando la documentación 
de área en área. 
• La aviación comercial registró a comienzos del 
año 2021 un total de casi 22 mil aeronaves 
comerciales a nivel mundial y se estima que para 
el 2041 se llegue a un total de 45 mil aeronaves 
(One Air, 2023), lo que hace inviable la gestión 
manual del registro técnico de vuelo que pasa por 
numerosas áreas que puede generar extravíos y 
demoras. 
 
• La DGCA (Dirección General de Aviación Civil) 
realiza auditorías a diferentes aerolíneas donde 
aplica multas por no cumplir con la 
documentación, procedimientos o presentar 
deficiencias en sus procesos por no cumplir con el 
control correcto de registro técnico de vuelo. 
(Indian Aviation News, 2023). 
 
Objetivos 
General 
Implementar un sistema que permita gestionar el registro técnico de vuelo, sus anexos e 
historial. 
Específicos 
OE1: Analizar tecnologías, dispositivos y plataformas de un sistema que permita el Registro 
Técnico de Vuelo. 
OE2: Diseñar arquitectura física y lógica de un sistema que permita el registro técnico de vuelo. 
OE3: Validar y desplegar la plataforma de un sistema de registro técnico de vuelo que garantice 
la operatividad del sistema. 
OE4: Elaborar un plan continuidad que garantice el funcionamiento del registro técnico de 
vuelo, anexos e historial. 
Indicadores de Éxito 
Se identificaron 04 indicadores de éxito para este proyecto y son los siguientes que se muestran 
en la Tabla2. 
 
Descripción de los indicadores de éxito. 
Indicador de éxito Objetivo 
IE01 Acta de aprobación de las tecnologías, dispositivos plataformas 
analizadas para el registro técnico de vuelo por parte Gerente de 
Operaciones. 
IE02 Acta de aprobación de la arquitectura física y lógica por parte de la 
Gerencia de Sistemas Integrados de Gestión y TI. 
IE03 Resultado de las encuestasal personal con un nivel de satisfacción 
mayor al 90% que certifica y valida el funcionamiento del registro 
técnico de vuelo. 
IE04 Acta de aprobación del plan de continuidad que brinde la viabilidad 
técnica de los registros técnicos de vuelo, anexos e historial del 
Gerente de Operaciones. 
Planificación del Proyecto 
La planificación, seguimiento y control del proyecto se realizó basándose en la guía de buenas 
prácticas PMBOK (Guía del PMBOK®), contando con un comité de dirección del proyecto 
cuyos integrantes fueron gerentes de la empresa. El liderazgo quedó a cargo de la Gerencia de 
Sistemas Integrados de Gestión y TI. Para mayor control de este proyecto, que, al ser nuevo y 
cambiante, se definió que los productos entregables se subdividieran en Sprints, cuya duración 
dependía de la complejidad y prioridad del requerimiento. Gracias a ello, se pudo llevar un 
control adecuado y no hubo variabilidad importante en los tiempos de ejecución del proyecto 
como se muestra en la Tabla 3. 
 
 
Planificación del proyecto. 
REGISTRO TÉCNICO DE VUELO 146 días lun 04/06/18 
 INICIO 3 días lun 04/06/18 
 PLANIFICACION 23 días jue 07/06/18 
 EJECUCIÓN 119 días lun 09/07/18 
 Sprint 1 7 días mar 10/07/18 
 Sprint 2 7 días jue 19/07/18 
 Sprint 3 20 días lun 30/07/18 
 Sprint 3 5 días lun 27/08/18 
 Sprint 4 5 días lun 03/09/18 
 Sprint 5 15 días lun 10/09/18 
 Sprint 6 60 días lun 01/10/18 
 CONTROL 36 días lun 04/06/18 
 CIERRE 1 día lun 24/12/18 
 
CAPÍTULO 2: MARCO TEÓRICO 
Marco Conceptual 
Servicios de Azure 
“Azure es la plataforma pública en la nube de Microsoft. Azure ofrece una amplia gama de 
servicios, lo que incluye las funcionalidades de plataforma como servicio (PaaS), 
infraestructura como servicio (IaaS) y servicio de base de datos administrado” (Ekuan et al., 
2023, párr. 1). 
Según Microsoft (s.f.-a) en su artículo ¿Qué es Azure? Afirma que “El 95 % de las empresas 
de la lista Fortune 500 confía en Azure para obtener servicios en la nube de confianza. Además, 
asevera que empresas de todos los tamaños y niveles de experiencia usan Azure en su 
transformación digital” (párr. 7). 
Para este proyecto se implementaron los servicios: Azure App Services y Azure SQL. 
Azure App Services es la plataforma que permite albergar y ejecutar aplicaciones seguras en 
la web como páginas web y API’s de servicios. 
Microsoft (s.f.-b) Azure SQL Server es la plataforma de SQL Server en la nube de Microsoft 
que permite ser repositorio de datos, así como ejecutar consultas y sentencias SQL. 
Registro Técnico de vuelo 
Es un conjunto de documentos que contienen información de una aeronave, mantiene el 
registro del ciclo de vida de un avión, datos del vuelo, discrepancias, el mantenimiento y el 
personal. 
Se utilizan en los diversos sectores, los más comunes en servicios comerciales y de defensa 
donde se busca almacenar la información sobre la calidad de la aviación, el mantenimiento, 
prevención y acciones correctoras. IBM (2021a) detalla en su artículo libros de registro de 
vuelo que todos estos registros proporcionan una visión intuitiva para los pilotos, mecánicos e 
ingenieros de vuelo de ver y documentar datos relacionados con la capacidad de servicio de las 
aeronaves, datos de vuelo, el personal, el reabastecimiento, entre otras. 
Discrepancia 
IBM (2021b) en su artículo creación de discrepancias y acciones correctoras indica que Hace 
referencia a un defecto o deficiencia observada en las condiciones de mantenimiento de una 
aeronave o parte de la aeronave o sus registros de mantenimiento. “Si existen varios registros 
de discrepancia, aquel cuyo estado sea más grave se enlazará con el estado de la aeronave. Por 
ejemplo, un libro de registro de vuelo tiene dos registros de discrepancia. Una discrepancia está 
relacionada con una luz dañada y se permite que la aeronave vuele en determinadas 
condiciones. La otra discrepancia está relacionada con una grieta en el fuselaje, lo cual requiere 
una atención inmediata” (IBM, 2021b, párr.8). 
JSON 
IBM (2021c) en su artículo formato JSON explica que “Es un formato ligero de intercambio 
de datos de fácil lectura y escritura para los programadores y fácil de interpretar y crear para 
las maquinas. JSON es una agrupación o forma parte del lenguaje de programación JavaScript 
que lo convierte en un lenguaje que permite realizar transacciones o intercambios de datos de 
forma ideal” (párr.1). 
Estándares, frameworks y buenas prácticas 
 
SCRUM 
Es un proceso de administración que permite gestionar proyectos de software con metodologías 
agiles, se encuentra basado en los principios de aprendizaje de una organización. Estos 
principios son el pensamiento sistémico, el dominio personal, los modelos mentales, la visión 
compartida y el aprendizaje en equipo. (Cruz et al., 2023). 
En otras palabras, este conjunto de prácticas permite la gestión de proyectos de forma ágil, 
anima a los equipos a auto organizarse mientras abordan problemas; aprender mediante 
experiencias y a recapacitar sobre sus logros y errores para mejorar continuamente. (De Toro, 
2022). 
PMBOK 
El Project Management Institute (Guía del PMBOK®) es la organización líder para el 
desarrollo en gestión de proyectos, es la responsable de la elaboración del PMBOK. El 
PMBOK está basado en procesos de buenas prácticas, consistentes y predecibles pues se 
encuentran en constante evaluación del desempeño de sus procesos que permitan sus mejoras, 
esto permitirá aumentar la eficiencia y reducir las amenazas. Detallado en su guía PMBOK 
(Guía del PMBOK®). 
El estándar para la gestión de proyectos por lo tanto guía los comportamientos y acciones de 
los profesionales de proyectos como otras áreas interesadas basándose en 12 principios de 
gestión de proyectos y ocho dominios de desempeños del proyecto. (Project Management 
Institute, 2021), puntos críticos para lograr objetivos favorables del proyecto. 
XAMARIN 
Según Microsoft (s.f.-c) en el portal de Xamarin, indica que este framework permite crear 
interfaces de usuario nativas en cada plataforma (Android e IOS) y escribir la lógica de negocio 
en C# que se comparte entre plataformas. Puede llegar a compartir el 80% del Código de la 
aplicación. 
MVC 
El patrón MVC, divide las aplicaciones en tres componentes principales los que se detallan 
como el modelo, la vista y el controlador, que proporciona una estructura organizada del 
trabajo, mejora el mantenimiento de la aplicación y brinda un acoplamiento mínimo entra cada 
una de las capas. Este patrón ha sido desarrollado por Trygve M. H. Reenskaug a finales de los 
años 70. (López, 2009). 
MVVM 
Es un patrón de diseño que está diseñado en base a tres componentes principales, el modelo, la 
vista y el modelo de vista. Minimiza la complejidad y aumenta la capacidad de prueba y 
reutilización, en la cual introduce un nuevo objeto denominado ViewModel que fusiona en un 
solo objeto la vista y el controlador y lo llama modelo de vista que aumenta la independencia 
de los datos y el encapsulamiento de la lógica de la aplicación (Aljamea & Alkandari, 2018). 
1.1.6 ASP.NET Web API 
Web API de .NET es un marco de trabajo desarrollado por Microsoft para facilitar y agilizar 
la creación de APIS REST y RESTFULL en proyectos web. Una de sus características es la 
posibilidad de implementar controladores Web y API a la vez, lo que permite implementar un 
solo proyecto web que cumple la función de aplicación web y APIS a la vez. 
Bases Legales y Marco Normativo 
Reglamento D.S. N.º 050-2001-MTC 
Artículo 27.- “Las aeronaves civiles deben llevar consigo el respectivo libro de a bordo, 
también llamado Bitácora o Informe Técnico de Vuelo (ITV)” (Ministerio de Transportes y 
Comunicaciones, 2001, Decreto Supremo 050-2001-MTC, Artículo 27). 
“El libro de a bordo puede ser solicitado en cualquier momento por los funcionarios 
competentesde la DGAC. El explotador está obligado a extender las copias del libro de a bordo 
que le sean requeridas” (Ministerio de Transportes y Comunicaciones, 2001, Decreto Supremo 
050-2001-MTC, Artículo 27). 
Artículo 28.- “El libro de a bordo debe ser presentado a la DGAC para su autorización, antes 
de ser utilizado por el explotador. El formato y características especiales del libro de a bordo 
es establecido por la DGAC” (Ministerio de Transportes y Comunicaciones, 2001, Decreto 
Supremo 050-2001-MTC, Artículo 28). 
Resolución Ministerial N.º 361-2011-MTC/02 – Reglamento de Infracciones y Sanciones 
Aeronáuticas 
Artículo 20.- Infracciones Imputables al Personal Aeronáutico, con carácter muy grave 
y sujeta a sanción de multa o inhabilitación temporal de las autorizaciones 
correspondientes: Como no reportar las fallas técnicas de la aeronave o las fallas 
operativas de su responsabilidad, en el informe técnico de vuelo o documento 
correspondiente (Ministerio de Transportes y Comunicaciones, 2011, Resolución 
Ministerial N.º 361-2011-MTC/02, Artículo 20). 
Ley N. ª 27261 - Ley de Aeronáutica Civil 
Disposiciones generales de la ley de aeronáutica civil. (Ministerio de Transportes y 
Comunicaciones, 2000). 
Regulaciones Aeronáuticas del Perú. (RAP) Licencias para Pilotos y sus Habilitaciones. 
Reglamentos y obligaciones de los pilotos con respecto al libro de vuelo. (Ministerio de 
Transportes y Comunicaciones, 2023) 
CAPÍTULO 3: DESARROLLO DEL PROYECTO 
En el siguiente capítulo se analizará las diferentes propuestas que cumplan con los objetivos 
específicos planteados. 
Diseño de la Solución 
Se mostrará a continuación el objetivo número uno referente a realizar el análisis de las 
tecnologías, dispositivos y plataformas que permitieron el registro técnico de vuelo. 
Análisis de tecnología para el proyecto 
Se presentan los análisis comparativos Benchmarking de las diferentes tecnologías 
implementadas en la realización del proyecto. Se analizará la mejor plataforma para el 
almacenamiento, acceso remoto y procesamiento de datos de todos los registros que componen 
el registro técnico de vuelo. 
Proveedores de servicios en la nube para Benchmarking 
 
Se analizó 3 proveedores de servicios en la nube como Azure, Google Cloud y AWS para 
determinar quién cumplía con los requerimientos para la implementación de servicios en la 
nube para servicios de almacenamiento y seguridad. 
 
• Azure: Integrada por más de 200 productos y servicios en la nube que brindan diversas 
alternativas respaldadas en sus características de seguridad y continuidad de productos. 
 
• Google Cloud: Dispone de herramientas para poder desarrollar y administrar 
aplicaciones, además cuenta con infraestructura para el procesamiento, 
almacenamiento y redes. 
 
• AWS: Brinda servicios en la nube para almacenamiento, aplicaciones móviles, bases 
de datos, etc. Además, ofrece respaldar y guardar información de una manera 
sintetizada con gran capacidad de recuperación de datos, sin embargo, en menor escala 
que Azure. 
La descripción de los criterios se muestra en la Tabla 4. 
 
 
Descripción de los criterios para Benchmarking. 
 
Se muestra la priorización de criterios para Benchmarking en la Tabla 5. 
 
Priorización de criterios para Benchmarking 
 Criterios A B C D E Total Impacto 
A Seguridad x 3 2 4 4 13 22% 
B Servicios 3 x 3 3 2 11 18% 
C Precio 3 3 x 4 2 12 20% 
D Disponibilidad 4 4 3 X 4 15 25% 
E Soporte 2 3 1 3 x 9 15% 
Total 60 100% 
 Nota. 1 Muy bajo, 2 Bajo, 3 Alto, 4 Muy Alto 
 
Se muestra los resultados de los tres proveedores de servicios en la nube en la Tabla 6. 
 
 
Benchmarking proveedores en la nube 
 Azure Google Cloud AWS 
Criterios Impacto Puntaje Promedio Puntaje Promedio Puntaje Promedio 
Seguridad 22% 4 0.88 4 0.88 4 0.88 
Servicios 18% 3 0.54 2 0.36 3 0.54 
Precio 20% 3 0.60 2 0.40 3 0.60 
Disponibilidad 25% 4 1 3 0.75 4 1 
Soporte 15% 4 0.60 3 0.45 2 0.30 
Total 100% 18 3.62 14 2.84 16 3.32 
 
Después de haber realizado el análisis Benchmarking para elegir al proveedor de servicios en 
la nube para las funciones de almacenamiento, acceso remoto y procesamiento de datos de 
todos los registros que componen el registro técnico de vuelo se determinó que, la mejor 
alternativa fue Azure por las siguientes razones mostradas en la Tabla 7. 
Nº Criterio Descripción 
1 Seguridad Información importante que necesita protección de los datos, 
recuperación y seguridad de la información. 
2 Servicios Mantenimiento, soporte, disponibilidad, entre otros servicios que 
ofrece cada proveedor en la nube. 
3 Precio Estimación de los costos de cada plataforma de cada proveedor. 
4 Disponibilidad Tiempo de operatividad asegurada medida en porcentaje de cada 
proveedor de nube. 
5 Soporte Tiempo de respuesta de cada proveedor ante incidencias o caídas 
de la plataforma. 
 
Criterios analizados de propuesta escogida 
Criterio Motivo 
Seguridad Azure te brinda protección de los datos, recuperación y seguridad de la 
información además de la opción de seguridad configurable, así como la 
capacidad de controlarlas por lo que puedes personalizar la seguridad. 
Servicios Azure es una plataforma que ofrece diversos servicios que proporcionan 
funcionalidades como servicios de plataforma, servicios de infraestructura 
como y servicios de base de datos administrados. 
Precio Google Cloud es sin embargo el proveedor que brinda el precio más 
accesible, mientras Azure y AWS tiene precios similares. 
Disponibilidad Sin duda se escoge Azure pues brinda una alta recuperación de datos antes 
desastres, mantiene los datos durables en dos ubicaciones, su disponibilidad 
garantiza el acceso desde internet mediante una puerta de enlace con 
disponibilidad sostenida. 
Soporte Azure brinda tiempos de respuesta más rápidos a sus competidores que 
garantizan un soporte más ágil antes caídas. 
 
Framework para el desarrollo de la aplicación móvil 
 
Se analizó distintos frameworks para determinar cuál cumplía con los requisitos en la 
implementación para el registro técnico de vuelo y que se pueda implementar de diferentes 
aplicativos móviles, llegando analizar Flutter, React Native y Xamarin. 
 
• Flutter: Framework para el desarrollo de aplicaciones móviles, sus orígenes están basados 
en el lenguaje Dart la que nos permite desarrollar aplicaciones para Android y IOS, pero 
no cuenta aún para desarrollo en plataformas como macOS, Windows o Linux, implementa 
funcionalidades flexibles y amigable. 
• React Native: Es un Framework con código abierto y nos permite también implementar 
aplicaciones nativas para el desarrollo en plataformas de Ios y Android basada en lenguajes 
de JavaScript y ReactJS, uno de sus inconvenientes es que no convierte la totalidad del 
código en una aplicación nativa. 
• Xamarin: Framework que nos facilita poder compilar código abierto en aplicaciones 
modernas y nos brinda mayor rendimiento para IOS, Android y Windows. A diferencias de 
otros proveedores Xamarin comparte hasta en un 90% de la aplicación entre diferentes 
plataformas, brindándole al desarrollador poder implementar la lógica de negocio en un 
solo lenguaje o reutilizar su código, llegando a conseguir un mejor rendimiento. 
 
La descripción de los criterios se muestra en la Tabla 8 
 
 
Puntuación Benchmarking de Frameworks para aplicativo móvil. 
Nº Criterio Descripción 
1 Facilidad de uso Simplicidad en el aprendizaje y desarrollo del framework donde se 
incluye la curva de aprendizaje e implementación. 
2 Documentación Disponibilidad de material, tutoriales, manuales que faciliten el 
aprendizaje y uso del framework. 
3 Productividad Ahorro de tiempo para el desarrollo de la aplicación que permita 
obtener resultados para el desarrollador. 
4 Velocidad y 
Rendimiento 
Capacidad de adaptarse de manera eficiente a la plataforma y 
mejora de estándares de desarrolloq aumenten el rendimiento y 
velocidad de respuesta. 
5 Arquitectura Composición de la plataforma para el desarrollo de aplicaciones 
nativas, facilidad de implementación y compatibles con 
bibliotecas nativas. 
 
La asignación para la priorización se muestra en la Tabla 9. 
 
Priorización de criterios para Benchmarking 
 Criterios A B C D E Total Impacto 
A Facilidad de uso x 4 3 4 3 14 21% 
B Documentación 4 x 2 1 4 11 17% 
C Productividad 3 2 x 4 4 13 20% 
D Velocidad y Rendimiento 4 1 3 X 4 12 18% 
E Arquitectura 4 4 4 4 x 16 24% 
Total 66 100% 
Nota. 1 Muy bajo, 2 Bajo, 3 Alto, 4 Muy Alto 
Se muestra los resultados del Benchmarking para los frameworks de aplicaciones móvil en la 
Tabla 10. 
 
Benchmarking Framework aplicaciones móvil 
 Flutter React Native Xamarin 
Criterios Impacto Puntaje Promedio Puntaje Promedio Puntaje Promedio 
Facilidad de uso 21% 3 0.63 2 0.42 4 0.84 
Documentación 17% 3 0.51 3 0.51 3 0.51 
Productividad 20% 3 0.60 2 0.40 4 0.80 
Velocidad y Rendimiento 18% 3 0.54 3 0.54 3 0.54 
Arquitectura 24% 3 0.72 3 0.72 4 0.96 
Total 100% 15 3 13 2.59 18 3.65 
 
Después de haber realizado el análisis Benchmarking entre los framework elegidos para el 
desarrollo de la plataforma móvil del registro técnico de vuelo se determinó que la mejor opción 
fue Xamarin por los siguientes motivos mostrados en la Tabla 11. 
 
Criterios analizados de propuesta escogida 
Criterio Motivo 
Facilidad de uso Xamarin es un Framework de fácil aprendizaje ya que cuenta con el 
soporte de Microsoft. Al basarse en C#, es de fácil adaptación para 
equipos de desarrollo basados en tecnologías .Net. 
Documentación Los 3 frameworks disponen de información, tutoriales y guías que 
facilitan el aprendizaje y uso. 
Productividad Xamarin permite al desarrollador implementar mejoras XAML, 
funciona con todas las bibliotecas y controles de terceros, los 
formularios son compatibles con IOS, Android, UWP y WPF. Además, 
funciona en todos los objeticos de implementación legítimos incluidos 
simuladores, emuladores y dispositivos físicos. 
Velocidad y 
Rendimiento 
Los 3 frameworks analizados cumplen con mostrar un rendimiento y 
velocidad en sus implementaciones, quienes nos permiten utilizar 
código nativo para lograr un mejor rendimiento y aplicaciones rápidas 
Arquitectura Sin duda Xamarin muestra una mejor arquitectura que compone de una 
plataforma de diseño visual para crear aplicaciones nativas, además de 
poder utilizar su arquitectura en plataformas Android, Ios y Windows y 
fue el principal criterio por su elección en la implantación del proyecto. 
 
Desarrollo de la Solución 
AS-IS 
En análisis AS-IS se realizó a alto nivel, resaltando los procesos más importantes de la 
operación del Registro Técnico de Vuelo. 
El proceso inicia por parte de la Gerencia de Operaciones, el controlador de operaciones inicia 
la programación de vuelo (como prerrequisitos debe recibir la orden de parte de la Gerencia 
Comercial). Para programar un vuelo se tiene como condición que la aeronave se encuentre 
operativa (no tenga discrepancias pendientes o al menos no tenga discrepancias que impiden 
la operación de vuelo). En la programación se asigna una aeronave, su equipo de mecánicos 
(deben estar capacitados para brindar operaciones sobre la marca y modelo de aeronave) y 
tripulación (capitán, mecánico y tripulación debidamente capacitados y con licencia de operar 
la aeronave según su marca y modelo). 
El siguiente proceso lo ejecuta el “mecánico inspector” que es el responsable de validar y 
liberar la aeronave. Inicia ejecutando las operaciones de prevuelo (inspección general de la 
aeronave, validación de controles de combustible, aceite, etc). En esta etapa se valida el 
Registro Técnico de Vuelo y se constata que no haya discrepancias pendientes o al menos no 
discrepancias que impidan las operaciones de vuelo. El mecánico inspector prepara y libera la 
aeronave (en conjunto con el equipo de mecánicos asignados). Luego solicita al personal de 
traslado a pista (mecánicos) y realiza la liberación de la aeronave (Firmar la etapa de prevuelo, 
comunicar al capitán y entregar el Registro Técnico de Vuelo). 
La siguiente etapa la ejecuta el “Capitán” asignado, quien como primera acción realiza la 
inspección previa (inspección del documento de Registro Técnico de Vuelo, inspección visual 
de la aeronave y validación de la tripulación). Si la inspección es conforme, inicia las 
operaciones de vuelo. Sin embargo, si en la inspección ha identificado una discrepancia que 
ponga en riesgo la operación de vuelo, se procede a emitir la discrepancia correspondiente e 
informar al controlador de operaciones. Si sucede esto, la operación de vuelo se cancela 
definitivamente. 
Luego de realizar las operaciones de vuelo, se entrega el Registro Técnico de Vuelo al “Piloto” 
quien se encarga de ir registrando los controles de vuelo, en especial los controles de la 
aeronave en velocidad crucero (momento en que la aeronave se desempeña en su máxima 
capacidad, por lo general es cuando culmina la fase de elevación y realiza vuelo plano). 
Si durante la operación de vuelo se registró una discrepancia, se registra en el Registro Técnico 
de Vuelo toda la información correspondiente. 
Para finalizar, el capitán realiza el “Fin de vuelo” y procede con la liberación de la aeronave 
notificando al controlador de operaciones. 
Si el vuelo posee más de una pierna (tramo de vuelo), se realizan las operaciones de vuelo 
desde el inicio del proceso, pero manteniendo el mismo Registro Técnico de Vuelo. 
El proceso general de vuelo se muestra el diagrama AS-IS en la figura 03. 
 
Figura 03 
AS-IS 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Equipo de Proyecto 
El desarrollo e implementación del proyecto estuvo a cargo de un equipo conformado por 4 
grupos de perfiles. 
En el grupo de alta dirección se encontraba el Product Owner que a su vez fue el Sponsor ya 
que sobre la Gerencia de Operaciones recayó la responsabilidad absoluta del proyecto, así 
como fue la que dirigió el presupuesto. 
El equipo de Gestión fue conformado por actores principales: 
• Project Manager: el Gerente de TI fue el responsable de dirigir todo el proyecto. 
• Process Owner: El dueño de proceso estaba representado por el jefe de pilotos ya que 
la mayor parte de las operaciones recaían sobre los pilotos, adicionalmente a la jerarquía 
que posee dentro de la empresa. 
• DevOps Senior: Fue el responsable de la parte técnica del proyecto, así como gestionar 
el ciclo de vida de las labores que se ejecutaron en cada etapa de la implementación. 
El equipo de Análisis fue conformado por los actores que identificaron, analizaron y 
optimizaron cada aspecto de las operaciones del proyecto y fue conformado por: 
• IT Consultant: responsable de analizar y gestionar la parte técnica y funcional del 
proyecto orientado al equipo técnico. A su vez realizó las labores de analizar e 
implementar los componentes en Azure. 
• Project Analyst: responsable de controlar y gestionar los avances del proyecto. 
• Process Leader: responsable identificar y brindar información del proceso por parte de 
los mecánicos. Indicaba información de cómo se ejecutaban las operaciones para poner 
en marcha los vuelos. 
• Key User: los capitanes brindaron la retroalimentación correspondiente a cómo 
gestionaban los registros técnicos de vuelo. 
El equipo de ejecución fue conformado por los responsables de realizar el sistema de gestión 
de registro técnico de vuelo y estaba conformado por: 
• Senior Developer: responsable realizar los desarrollos más complejos, aplicación móvil 
y dirigir el equipo técnico. 
• Front End Developer: responsable de desarrollar y optimizar las interfaces visuales de 
los aplicativos. 
• Back End Developer: se encargó deimplementar las funcionalidades y API’s que 
brindaron soporte a los aplicativos. 
• DBA: responsable del desarrollo y gestión de las bases de datos. 
La jerarquía y distribución del equipo de proyecto se representa en la Figura 04. 
 
Figura 04 
Equipo de Proyecto 
 
 
 Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Arquitectura Física 
La arquitectura física de esta implementación se agrupa en 4 grandes capas, una que agrupa los 
dispositivos físicos en que se instalaron los aplicativos y 3 de ellas basadas en la nube de 
Microsoft. 
La primera capa, “Endpoints físicos” es la capa en la que se encuentran los dispositivos físicos 
que pertenecen a los actores del sistema. Está distribuida en 2 componentes, el primero un 
aplicativo móvil (instalado en celulares y Tablet Android e IOS) la cual mantiene una base de 
datos móvil local (Realms) para asegurar la operatividad online y offline. Por otra parte, están 
los dispositivos como laptops y desktops en los que se consume el portal administrativo del 
sistema. 
La segunda capa, “Servicios de Aplicaciones Azure” contiene las aplicaciones basadas en la 
nube de Azure de tipo PAAS (Platform As Service) a las cuales se accede mediante protocolo 
HTTPS certificado mediante un SSL (Secure Socket Layer). Dentro de esta capa se identifican 
2 grupos. El primer grupo está conformado por 2 componentes, los cuales brindan 
funcionalidad al portal y API (Application Programming Interface) mediante un proyecto 
WebAPI de .Net, el cual brinda las funciones de un portal web y a su vez expone servicios de 
tipo API REST en un solo aplicativo, lo que ahorra costos y tiempos de desarrollo. El segundo 
grupo es otro proyecto externo conformado por la API REST de seguridad la cual brinda los 
servicios de autenticación de usuarios, firma digital, perfiles y roles de usuario. 
La tercera capa está compuesta de los servicios de base de datos Azure SQL Server de tipo 
PAAS, los cuales están protegidos por los firewalls de Azure, que proporciona seguridad ante 
intentos de acceso no permitido. 
La cuarta capa está conformada por los componentes de Backup y contingencia compuestos de 
un servidor en la nube que contiene servicios que realizan las copias de seguridad de base de 
datos y las implementan en un servidor SQL Server de reflejo (actualizado cada día) y un File 
Server (Servidor de archivos) que alberga las copias de seguridad históricas de las bases de 
datos. 
Para su mejor identificación, se muestra la arquitectura física en la figura 05. 
 
 
 
 
 
Figura 05 
Arquitectura Física 
 
 
 Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Arquitectura Lógica 
Los roles que interactúan en el proyecto son: Piloto, Mecánico y Controlador de operaciones. 
El controlador de operaciones válida y genera las órdenes de vuelo, así como válida que la 
aeronave se encuentre apta para brindar operaciones. 
El Mecánico se encarga de realizar las operaciones de pre-vuelo, y brinda el visto bueno para 
el piloto. 
El Piloto realiza la ejecución del vuelo e interactúa con el aplicativo controlando y 
administrando información de las operaciones de vuelo. 
El proyecto ha sido gestionado íntegramente en tecnologías y frameworks de Microsoft. Para 
la gestión de cambios y control de fuentes se basó en Azure Devops, teniendo como control de 
código fuente GitHUB. 
Los dispositivos que disponen de acceso al sistema son celulares y tablets (para el acceso 
mediante la aplicación móvil), además de laptops o desktops para el acceso al portal 
administrativo. 
La capa frontal (front end) se implementó con 2 componentes principales: 
Aplicación móvil basada en Xamarin Forms (.Net basado en lenguaje C#) permite 
implementarse en Android e IOS. 
Aplicación Web de administración la cual está basada en HTML5, CSS y Javascript con el 
Framework visual Bootstrap y el patrón MVC. 
En la capa transversal se implementaron 2 componentes, el framework Web API de Visual 
Studio .NET sirvió para implementar la API en la que se exponen los controladores que 
permiten interactuar a los componentes front-end con la base de datos Por otro lado, para la 
aplicación móvil se implementó el patrón MVVM (Model View View Model) que permite 
administrar la interacción entre la interfaz visual con la base de datos local (Realms). 
La capa de backend contiene 2 motores de base de datos: 
La base de datos móvil local basada en Realms permite al aplicativo móvil albergar la 
información de los registros técnicos de vuelo para asegurar la operatividad en línea y fuera de 
línea. 
La base de datos Azure SQL Server registra toda la información del proyecto en la nube a la 
cual se accede mediante el ORM Entity Framework de Microsoft. 
Para su mejor entendimiento, se muestra la arquitectura lógica en la figura 06. 
 
 
 
Figura 06 
Arquitectura Lógica 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
1.1.1 Análisis 
La estrategia de análisis de requerimientos se siguió bajo el enfoque ágil. En tal sentido, los 
diversos equipos de proyecto ejecutaron el análisis y desarrollo de requerimientos en base a la 
siguiente estructura mostrada en la figura 07: 
 
Figura 07 
Estructura Análisis e Implementación. 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
El primer paso fue la elaboración de las historias de usuario, realizadas en base a una entrevista 
con el solicitante del requerimiento. Como resultado de esa etapa, se elaboraron los mockups 
correspondientes, que brindaron una visión general del resultado esperado. Cuando se aprobaba 
el mockup se procedía con el desarrollo correspondiente. Cada una de estas etapas era iterativa 
bajo constante retroalimentación. 
En base al análisis general, se identificaron los requerimientos de alto nivel representados en 
el siguiente diagrama de la figura 08: 
Figura 08 
Diagrama Requerimientos. 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Luego de ello, se inició con la elaboración de las historias de usuario. Como ejemplo para este 
informe de las 21 historias de usuario se ha tomado la que cuenta con mayor complejidad lógica 
y funcional, la cual se detalla a continuación: 
H006 – Tiempo de vuelo: El control de tiempos de vuelo era muy importante en el proceso de 
elaboración de un RTV debido a que en este se lleva el registro de cada pierna de vuelo (tramo 
entre cada aeropuerto) y se detallan los tiempos tomados, así como datos de control como 
cantidad de clientes y peso total de la aeronave. 
H006 – Tiempo de vuelo 
Prioridad Alta Riesgo de desarrollo Alto 
Sprint asignado 2 Responsable Senior developer 
Elaborado por IT Consultant 
Solicitante Key user 
Descripción 
Se requiere poder llevar el control de cada pierna de vuelo (pierna es un término 
aeronáutico el cual refiere a cada tramo de vuelo entre cada aeropuerto). Este control 
conlleva los tiempos block, tiempos flight, tiempos de día y tiempo de noche, así como 
controles de cantidad de tripulación y peso por pierna. 
Validación 
El usuario puede gestionar los tiempos de vuelo del RTV. 
 
El resultado de esta etapa inicial fue el mockup H006 – Tiempo de vuelo. Con este mockup se 
logró automatizar el control de los tiempos de vuelo ya que cada valor registrado afectaba 
directamente al registro de aeronave y motores. 
 
Figura 09 
Mockup de tiempo de vuelo 
 
 
 Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilacióny análisis de la empresa en estudio. 
 
Al hacer click en el botón “+” se muestra la ventana de agregar tiempo de vuelo. También se 
puede editar el tiempo de vuelo haciendo click sobre la fila requerida o eliminar presionando 
el botón de eliminar de cada fila. 
 
Figura 10 
Mockup de tiempo de vuelo – Agregar 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
1.1.1 Desarrollo 
El resultado del desarrollo de la historia de usuario se representó en el aplicativo móvil y contó 
con la aprobación del solicitante. Este entregable se representa en la figura 11 tiempo de vuelo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 11 
Tiempo de vuelo desarrollado 
 
 
 
Nota. La información fue extraída de una fuente privada, la misma que es consecuencia de la 
recopilación y análisis de la empresa en estudio. 
Validación del Proyecto 
Después de implementado el sistema y entendiendo las necesidades que los usuarios requerían 
para la mejora de los procesos en el registro técnico de vuelo, se realizaron encuestas para 
poder validar que, nuestro sistema cumpla con las necesidad y expectativas requeridos. Para 
ello se usó el método de medición Likert planteándose las siguientes preguntas realizadas a 20 
trabajadores que actualmente usan el sistema entre operarios, pilotos, técnicos de vuelo, 
mecánicos, etc. 
Para todas les peguntas se usó la siguiente escala: 
Totalmente en 
Desacuerdo 
En 
Desacuerdo 
 
Ni de Acuerdo, ni 
en Desacuerdo 
 
De 
Acuerdo 
 
Totalmente de 
Acuerdo 
 
Pregunta 1: ¿Considera que ha mejorado la eficiencia en el tiempo de acceso de un registro 
técnico de vuelo? 
 
Se muestra los resultados de las encuestas en la mejora en los tiempos de accesos en un RTV 
en la figura 12. 
 
Figura 12 
Eficiencia en tiempos de acceso en un RTV. 
 
 
Pregunta 2: ¿La implementación del sistema logró mejorar el índice de correcciones del registro 
técnico de vuelo? 
 
Se muestra los resultados de las encuestas en la mejora en los índices de correcciones de 
accesos en un RTV en la figura 13. 
 
 
 
 
 
 
 
Figura 13 
Índice de correcciones de en un RTV. 
 
 
 
Pregunta 3: ¿Considera que se redujeron las multas y/o sanciones por extravío de los RTV? 
 
Se muestra los resultados de las encuestas en la reducción en multas y/o sanciones por extravío 
en un RTV en la figura 14. 
 
Figura 14 
Índice de reducción en multas y/o sanciones por extravío de en un RTV. 
 
 
Pregunta 4: ¿El desarrollo del sistema para usted logró incrementar la seguridad de un registro 
técnico de vuelo? 
 
Se muestran los resultados de las encuestas en el incremento de la seguridad de un RTV en la 
figura 15. 
 
Figura 15 
Incremento de seguridad de en un RTV. 
 
 
 
Pregunta 5: ¿Considera usted que el índice de registro técnico de vuelos extraviados o perdidos 
ha disminuido? 
 
Se muestran los resultados de las encuestas en la disminución de los RTV extraviados o 
perdidos en la figura 16. 
 
Figura 16 
Índice de Registro Técnico de Vuelo extraviados o perdidos. 
 
Pregunta 6: ¿Considera usted que se ha optimizado el control de discrepancias en el registro 
técnico de vuelo? 
 
Se muestran los resultados de las encuestas en la optimización del control de discrepancias de 
un RTV en la figura 17. 
 
Figura 17 
Optimización del control de discrepancias de un RTV. 
 
 
Resultados 
A continuación, se muestra los resultados de las 6 preguntas realizadas a un total de 20 
encuestados entre pilotos, operarios, técnicos, entre otros en la Tabla 12. 
 
 
Resultados de encuesta, medición Likert. 
 
Totalmente 
en 
Desacuerdo 
En 
Desacuerdo 
Ni de 
Acuerdo, ni 
en 
Desacuerdo 
De 
Acuerdo 
Totalmente 
De acuerdo 
Total de 
Encuestados 
Pregunta 1 0 0 0 3 17 20 
Pregunta 2 0 0 0 0 20 20 
Pregunta 3 0 0 0 1 19 20 
Pregunta 4 0 0 3 5 12 20 
Pregunta 5 0 0 0 0 20 20 
Pregunta 6 0 2 1 5 12 20 
 
Interpretación de los Resultados 
En base a las encuestas recogidas a los usuarios que utilizan el sistema se obtuvo la siguiente 
interpretación de los resultados para el registro técnico de vuelo: 
1. De acuerdo con la eficiencia de mejora en los tiempos de acceso al registro técnico de 
vuelo, después de haber realizado la encuesta a un número de 20 encuestados se determinó: 
 
Los encuestados consideraron que los tiempos de acceso a los registros técnicos de vuelo 
tuvieron un aumento en eficiencia de un 85% indicando estar totalmente de acuerdo, pues ya 
contaban con una herramienta en los diferentes dispositivos para realizar la carga de la 
información y evitar buscar los informes en diferentes archivos físicos o tener que trasladarse 
desde cualquier punto a los archivos para poder realizar la búsqueda, generando pérdida de 
tiempo. El 15% manifestó está de acuerdo en la mejora en los accesos a los registros técnicos 
de vuelo. Finalmente, no hubo encuestados que manifestaron no estar a favor del aumento en 
la eficiencia. Se muestra en la tabla 13: 
 
 
 
Resultado en porcentajes tiempos de acceso RTV 
 
2. Con relación a la mejora en el índice de correcciones de un registro técnico de vuelo, se 
obtuvo los siguientes resultados en base a los 20 encuestados. 
Los 20 encuestados estuvieron totalmente de acuerdo en que, el índice de correcciones en cada 
uno de los documentos que conforman el registro técnico de vuelo aumento en 100% pues al 
tener una aplicación en cada uno de los dispositivos que maneja cada usuario como técnicos, 
pilotos, operarios, entre otros ya no presentaba documentación con errores, borrones, 
enmendaduras o deterioro que generaban una presentación deficiente y eran rechazadas, 
obligando nuevamente a llenar cada formato generando demoras. Los resultados se muestran 
en la Tabla 14. 
 
Resultado en porcentajes índice de correcciones RTV. 
 
3. Con respecto a las multas y/o sanciones por extravío de RTV, se obtuvo los siguientes 
resultados. 
Después de realizar la encuesta a un total de 20 participantes se obtuvo que, el 95% de 
encuestados está totalmente de acuerdo en que se redujeron las multas y/o sanciones derivadas 
del extravío de RTV. Los resultados se muestran en la Tabla 15. 
 
Resultado de reducción de multas y/o sanciones por extravío de RTV 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 0 0 15% 85% 100% 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 0 0 0 100% 100% 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 0 0 5% 95% 100% 
4. De acuerdo con el incremento en la seguridad de los documentos que conforman un registro 
técnico de vuelo, después de la evaluación de la encuesta realizada se mostraron los 
siguientes resultados: 
En base a los 20 encuestados el 60% manifestó estar totalmente de acuerdo que todos los 
reportes de un registro técnico de vuelo incremento considerablemente ya que, contar con un 
aplicativo les brindaba solo un acceso con los permisos respectivos, manteniendo segura toda 
la información. 
Por otro lado, el 25% indico estar de acuerdo con haber reflejado mayor seguridad de todos los 
registros. Sin embargo, el 15% expresa que no está de acuerdo ni en desacuerdo con la mejora 
en la seguridad pues basan su opinión que la información puede ser de igualmente vulnerable 
a través de programas maliciosos. Los resultados se muestran en la Tabla 16. 
 
Resultado en porcentajes incremento de seguridad RTV 
 
5. En base al índice de pérdida o extravió de los documentos que conforman un registro 
técnico de vuelo se obtuvo los siguientes porcentajes después de la evaluación:La respuesta de los 20 encuestados demostraron que están totalmente de acuerdo en que el 
índice de pérdidas de los documentos o formatos de un registro técnico de vuelo se redujo en 
un 100%, ya no existen registros que se reporten como perdidos o extraviados, todo se 
almacena a través de la implementación en el sistema, cada colaborador de ATSA ya no tiene 
la necesidad de guardar físicamente los registros que generaban en la mayoría de los casos que 
estos documentos puedan perderse. Este índice ha brindado una gran mejora en los tiempos 
para los registros pues toda la documentación se encuentra almacenada permitiendo a cada 
trabajador realizar su labor correspondiente de manera óptima y segura. Los resultados se 
muestran en la Tabla 17. 
 
Resultado en porcentajes índice de perdidas RTV 
 
6. Finalmente, se obtiene la interpretación de los resultados en la optimización del control de 
discrepancias en un registro técnico de vuelo: 
De un total de 20 encuestados, el 60% está totalmente de acuerdo que se mejoró en el control 
de discrepancias, teniendo en cuenta que este control hace referencia a los defectos o alguna 
deficiencia encontrada en una aeronave. Se refleja que los registros de mantenimiento se 
mantenían actualizados, agilizando las coordinaciones para poder tomar acciones correctivas 
de manera más eficientes y en menor tiempo, además de ello, poder determinar qué aeronave 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 0 15% 25% 60% 100% 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 0 0 0 100% 100% 
tenía que ser prioridad en la atención, controlando y gestionando con las diferentes áreas el 
levantamiento de las deficiencias encontradas. También conlleva a la mejora significativa en 
la reducción de posibles accidentes, multas impuestas por la DGAC y por ende en la diminución 
de posibles gastos generados por las multas impuestas. 
El 25% manifestó estar de acuerdo también en la mejora en el control, indicando que ahora es 
más accesible a la información del registro de las discrepancias y enfocar la actividad en 
levantar las deficiencias encontradas. 
El 10% indica que no está de acuerdo, ni en desacuerdo con la optimización. Para ellos, tener 
el registro físico o digital emplea el mismo plazo para la corrección o levantamiento de estas 
incidencias encontradas. Finalmente, el 5% respondió estar en desacuerdo pues no encuentra 
una demora o no visualiza una optimización para este control, teniendo los mismos tiempos 
para llegar a levantar toda observación. Los resultados se muestran en la Tabla 18. 
 
Resultado en porcentajes Control de discrepancias RTV 
 
Plan de Continuidad 
 
Se elabora el plan de continuidad con la finalidad de poder alcanzar los objetivos principales y 
el funcionamiento del servicio, además de tener un respaldo para la restauración de cada uno 
de los procesos críticos del negocio pues al generar una falla, estos afectarían en conseguir los 
resultados óptimos para el servicio. Entonces entendemos que con el plan de continuidad 
buscamos asegurar la viabilidad y duración del proyecto y disminuir los riesgos o amenazas a 
niveles manejables. 
Objetivo General 
Elaborar un plan de continuidad para alcanzar la mejor performance de todas las 
funcionalidades implementadas en el sistema, que cumpla los objetivos y brinde la solución 
planteada, además de preparar un plan de acción que responda a las incidencias que puedan 
presentarse y garantizar la disponibilidad, integridad y confidencialidad de la información. 
Objetivo Específicos 
• OE1: Analizar la organización 
• OE2: Identificar amenazas y riesgos en los procesos 
• OE3: Elaborar plan de acción o contingencia 
• OE4: Diseñar mejoras en procesos a través de pruebas con usuarios 
 
Beneficios 
• Sostener un nivel óptimo en los procesos de la aplicación. 
Totalmente de 
Desacuerdo 
En 
Desacuerdo 
Ni de Acuerdo, ni en 
Desacuerdo 
De 
Acuerdo 
Totalmente de 
Acuerdo 
Total de 
Encuestados 
0 10% 5% 25% 60% 100% 
• Priorizar las amenazas o incidencias para el control y acción para evitarlos. 
• Evitar o reducir ocurrencias de incidentes. 
• Mantener actualizado nuestro plan de riegos, control de Backup de base de datos, 
cambios de estados. 
Roles para el soporte 
Después de la implementación del sistema que cumple las necesidades requeridas por la 
organización, se definen los roles y sus responsabilidades para el cumplimiento de los 
objetivos. 
 
• Administrador TI: 
➢ Se encarga de que los procesos en las actividades diarias que han sido 
implementados en el sistema se ejecuten eficientemente. 
➢ Se hace responsable de toda la seguridad en la información y la infraestructura 
tecnológica. 
➢ Debe garantizar que el sistema cumpla con los requisitos del negocio y elaborar 
planes de acción ante cualquier amenaza. 
 
• Service Desk: 
➢ Supervisa el funcionamiento de la solución para que se cumpla el plan de 
continuidad. 
➢ Recibe solicitudes sobre cada incidencia para poder brindar la atención respectiva. 
➢ Realiza el seguimiento de las incidencias hasta la solución y brindar los informes 
a cada usuario. 
➢ Reporta las soluciones a las áreas encargadas. 
 
• Administrador de BD: 
➢ Responsable del soporte de las bases de datos implementadas en los sistemas. 
➢ Brinda solución ante posibles caídas en los servidores de bases de datos. 
 
• Equipo de desarrollo: 
➢ Encargado de todo el soporte ante los problemas de desarrollo de las aplicaciones. 
➢ Reportar fallos encontrados y brindar las soluciones correspondientes. 
• Seguridad TI: 
➢ Responsable de garantizar toda la seguridad, la confidencialidad y disponibilidad 
de la información de la organización. 
• Gestor de riesgos: 
➢ Debe identificar los riesgos potenciales que afecten o puedan afectar a la empresa 
y brindar alternativas para poder mitigarlos. 
 
Procedimiento de Soporte 
Basado en el modelo conceptual de ITIL se implementa los procedimientos para el soporte que 
nos pueda dar el resultado óptimo y los tiempos de respuesta adecuados. Se muestran en la 
Tabla 19. 
 
Niveles de servicio en procedimiento de Soporte. 
 
Gestión de Incidentes 
Una incidencia genera siempre la reducción en la calidad del servicio ya que, interrumpe el 
correcto funcionamiento del sistema. Es te proceso se encarga de recibir todas las incidencias 
que reportan los usuarios y busca restaurar en el menor tiempo el funcionamiento para que 
pueda reducir el impacto negativo en el negocio. 
Beneficios: 
• Alinear los procesos de TI a los objetivos de la empresa para dar prioridad al manejo 
de las incidencias y el impacto que puedan tener. 
• Aumentar el control tanto en los procesos y monitoreo de los servicios, mejorando el 
registro, seguimiento, y la documentación de las incidencias reportadas. 
• Minimizar la interrupción de las incidencias. 
• Aumentar la disponibilidad del sistema. 
• Levantar los procesos principales de la aplicación en menores tiempos y reducir el 
impacto negativo y tiempos muertos del servicio. 
• Optimizar los recursos y facilitar la administración. 
 
Proceso: 
1. Registro de las incidencias. 
2. Priorizar las incidencias. 
3. Brindar el soporte en primer nivel. 
4. Validación y diagnóstico. 
5. Resolución de las incidencias. 
6. Verificación y conformidad del usuario. 
7. Cierre de las incidencias reportada. 
 
Niveles 
Tiempo de respuesta y 
evaluación 
Tipo de consulta o problema 
Nivel 1 De 30 a 45 min 
• Consulta básica 
• Help Desk 
• Solución a los problemas. 
Nivel 2 De 1 - 3 horas • Problemas complejos 
Nivel 3 X días de evaluación 
• Problemas identificados que requieren el apoyo de 
un equipo. 
Gestión de problemas 
Buscamos poder encontrar el origende cada problema que se reporta o se registran y comenzar 
a encontrar o plantear la solución más factible y económica. Se llevará el monitoreo constante 
para verificar el avance y de acuerdo con ello poder implementar medidas correctivas. 
 
Alcance: 
Se busca reducir el impacto de cada incidencia presentada, identificando las causas o posibles 
incidentes potenciales. Tiene un alcance desde el recibimiento de los registros que son 
derivados desde la gestión de incidencias hasta el envío de los requerimientos de soluciones o 
cambios a la gestión de cambios. 
 
Beneficios: 
• Disminuir la cantidad de incidentes. 
• Prevención de nuevos incidentes. 
• Brindar información y soluciones para el soporte de incidencias encontradas. 
 
 
Proceso: 
1. Identificar las incidencias y brinda soluciones parciales. 
2. Priorizar el problema de acuerdo con su criticidad. 
3. Asignar los recursos correspondientes para cada problema. 
4. Investigar y diagnosticar la causa raíz de las incidencias. 
5. Derivar cada error al control de errores. 
6. Evaluar el error reportado. 
7. Plantear la solución final. 
8. Cerrar el error reportado. 
 
Gestión de cambios 
Tiene como finalidad recibir cada una de las solicitudes de cambio, poder evaluar su viabilidad 
de cada propuesta, para poder determinar si es factible aprobar o rechazar la solicitud. Una vez 
aprobada el cambio evaluaremos su implementación y los resultados obtenidos. 
 
Alcance: 
Siempre se encuentra limitada a los cambios en las configuraciones base de los activos y cada 
elemento de configuración en el ciclo de vida de los procesos. Cada empresa define los cambios 
a gestionarse, los cambios que son prioritarios y cuáles pueden ser cubiertos y cuáles no. 
 
Beneficios: 
• Estar pendiente de cada cambio en los servicios con el objetivo de disminuir los 
resultados adversos a lo planificado. 
• Reducir los tiempos de caída. 
 
Proceso: 
1. Crear la solicitud de cambio. 
2. Evaluar cada solicitud de cambio. 
3. Aprobar el cambio. 
4. Planificar cada cambio. 
5. Realizar pruebas en los cambios. 
6. Implementar el cambio. 
7. Analizar el performance y rendimiento del cambio. 
8. Cerrar el proceso de cambio. 
 
Responsables: 
• Jefe del área de sistemas. 
• Jefe del área de desarrollo. 
• Administrador de redes 
• Administrador de hardware. 
 
Gestión de seguridad 
Este proceso busca cumplir con los estándares de seguridad en base a los acuerdos SLAs y 
reducir los riesgos de seguridad que identificaron o los que aún no se han identificado, pero 
que puedan ser una amenaza para la continuidad del sistema. Se puede determinar que su 
objetivo principal es diseñar políticas de seguridad que se encuentren alineadas a las 
necesidades del negocio y con los responsables del proceso. 
 
Alcance: 
Se encuentra delimitada desde la identificación de los riesgos de seguridad hasta la 
implementación de los cambios en el sistema o su infraestructura. 
 
Beneficios: 
• Minimizar el impacto que afecte la disponibilidad del servicio. 
• Reducir el tiempo de interrupciones generados por ataques informáticos. 
• Disminuir la cantidad de incidentes. 
• Asegurar la preservación, integralidad, confidencialidad y disponibilidad de los datos. 
 
Proceso: 
1. Identificar los eventos. 
2. Elaborar informes de eventos que afecten o vulneren la seguridad. 
3. Plantear estrategias de seguridad. 
4. Evaluar las estrategias de seguridad. 
5. Planificar y ejecutar dichas estrategias. 
6. Validar las estrategias de seguridad. 
7. Registrar las políticas de seguridad. 
 
Responsables: 
• Jefe del área de seguridad de la información. 
• Jefe del área de sistemas. 
• Administrador del área de desarrollo. 
• Administrador de redes. 
CONCLUSIONES Y RECOMENDACIONES 
Conclusiones 
En base a los objetivos planeados, la validación del proyecto y la interpretación de los 
resultados obtenidos, podemos inferir lo siguiente: 
- En base a los resultados de la encuesta 01, podemos inferir que el tiempo de consulta 
de los RTV se ha reducido al menos en un 95%, lo que implica que se han logrado 
satisfacer los objetivos e indicadores de éxito del proyecto. 
- Implementar el proyecto ha reducido los números de RTV extraviados en su totalidad, 
por ello, se ha mitigado los índices de perdida de la información. 
- Se redujo la totalidad de correcciones o borrones de documentos ya que, al ser un 
registro sistematizado, se permitió la posibilidad de corregir observaciones y/o errores 
antes de finalizar la creación de un RTV. 
- Como se mitigó el número de RTV extraviados, con correcciones y/o borrones, se 
redujo el índice de multas o sanciones en al menos 95%. 
- Sistematizar y optimizar el registro y control de discrepancias ha incrementado la 
seguridad de los vuelos en al menos 85% según la encuesta realizada al personal. 
Recomendaciones 
Gracias a los resultados del proyecto y los objetivos cumplidos, se puede sugerir las siguientes 
oportunidades de mejora: 
- Integrar el registro discrepancias con el ERP de la empresa, los que permitirá optimizar 
los procesos operativos y de compras, reduciendo los tiempos de atención de 
discrepancias y los costos que conllevan. 
- Lleva un control de los dispositivos IOS (IPad) que se utilizan en la empresa, debido a 
que el soporte de Apple bloquea la instalación de aplicaciones en dispositivos muy 
antiguos (al menos 3 versiones de IOS anterior a la actual). 
- Preparar el proyecto para la futura migración a .Net MAUI que es la evolución de 
Xamarin propuesta por Microsoft, lo que reforzara que el proyecto se mantenga 
operativo. 
- Integrar la creación de los RTV con el sistema comercial, que es el lugar donde nacen 
y se formalizan las órdenes de vuelo. 
REFERENCIAS 
Aljamea, M., & Alkandari, M. (2018). MMVMi: A Validation Model for MVC and MVVM 
Design Patterns in iOS Applications. IAENG International Journal of Computer Science, 
45 (3), 377–389. De 
https://www.iaeng.org/IJCS/issues_v45/issue_3/IJCS_45_3_03.pdf. 
 
Atsa Airlines. (s.f.). Nosotros. Recuperado 11 de noviembre de 2023, de 
https://www.atsaairlines.com/nosotros. 
 
Cruz, L. M. H., Turriza, J. L. L., Huh, Y. P., Turriza, J. M. L., Salgado, F. Á. Á., & Álvarez, 
D. C. M. (2023). Los roles del marco de trabajo Scrum: un análisis de competencias y 
habilidades. Revista Ibérica De Sistemas e Tecnologías De Información, E58, 450-458. 
https://wwwproquest.upc.elogim.com/scholarly-journals/los-roles-del-marco-de-
trabajo-scrum-un-análisis/docview/2839525245/se-2. 
 
De Toro, Á. (2022, agosto 18). ¿Qué es Scrum? Conoce el Framework que agiliza el Trabajo 
en Equipo. Revista Escuela de Negocios y Dirección. Recuperado el 5 de setiembre de 
2023, de https://www.escueladenegociosydireccion.com/revista/business/scrum-
framework-agiliza-trabajo-equipo. 
 
IBM. (2021a). Libros de registro de vuelo. Recuperado el 9 de setiembre de 2023, de 
https://www.ibm.com/docs/es/maximo-for-aviation/7.6.2?topic=books-flight-log. 
 
IBM. (2021b). Creación de discrepancias y acciones correctoras. Recuperado el 7 de octubre 
de 2023, de https://www.ibm.com/docs/es/maximo-for-aviation/7.6.2?topic=books-
flight-log. 
 
IBM. (2021c). Formato JSON. Recuperado el 7 de octubre de 2023, de 
https://www.ibm.com/docs/es/integration-designer/8.5.5?topic=formats-javascript-
object-notation-json-format. 
 
Indian Aviation News (2023, 31 de julio). DGCA slaps Rs 30 lakh fine on IndiGo for 
frequent tail strikes as audit shows systemic deficiencies. Indian Aviation News. 
https://swebebsco.upc.elogim.com/ehost/detail/detail?vid=0&sid=87326c13-703f-42ac-
8e5e-f168b3440598%40redis&bdata=Jmxhbmc9ZXM%3d#AN=169693570&db=aps 
 
https://www.iaeng.org/IJCS/issues_v45/issue_3/IJCS_45_3_03.pdf
https://www.atsaairlines.com/nosotros
https://wwwproquest.upc.elogim.com/scholarly-journals/los-roles-del-marco-de-trabajo-scrum-un-análisis/docview/2839525245/se-2
https://wwwproquest.upc.elogim.com/scholarly-journals/los-roles-del-marco-de-trabajo-scrum-un-análisis/docview/2839525245/se-2