Facultad de Tecnologías Libres

“Aplicación Móvil para el Parque

Científico Tecnológico de La Habana”

Trabajo de diploma para optar por el título de

Ingeniero en Ciencias Informáticas

Autor: Liannis Cabrera Expósito

Tutores: [Link] Daniel José Olazabal Guerra P.A
Ing. Alejandro Romero Martínez P.I

La Habana, junio de 2025

Año 67 de la Revolución
 Declaración de autoría

DECLARACIÓN DE AUTORÍA

La autora del trabajo de diploma con título “Aplicación Móvil para el Parque Científico
Tecnológico de la Habana” concede a la Universidad de las Ciencias Informáticas los
derechos patrimoniales de la investigación, con carácter exclusivo. De forma similar, se declara
como única autora de su contenido. Para que así conste, firma la presente a los 21 días del mes
de mayo del año 2025.

Liannis Cabrera Expósito

_______________________
Firma de la Autora

[Link]. Daniel José Olazabal Guerra P.A Ing. Alejandro Romero Martínez P.I

_______________________ _______________________
Firma del Tutor Firma del Tutor

I
 DATOS DE CONTACTO

Nombre y Apellidos del Tutor: Daniel José Olazabal Guerra

Títulos académicos: Licenciado en Tecnología de la Salud en Gestión de la Información en
Salud. Máster en Informática Médica Aplicada.
Lugar de trabajo: Centro de Investigaciones sobre Longevidad, Envejecimiento y Salud (CITED).
Universidad de las Ciencias Informáticas (UCI). Facultad de Tecnologías Libres (FTL).
Formación de postgrado recibida: Maestría en Informática Médica Aplicada. Doctorando en
Ciencias de la Educación Médica.
Categoría docente: Profesor Auxiliar.
Categoría científica: Investigador Auxiliar.
Responsabilidades laborales asumidas: Responsable de Seguridad Informática, Administrador
de Red. Profesor Universitario. Facultad de Tecnología de la Salud Dr. Octavio de la Concepción
y de la Pedraja. Universidad de Ciencias Médicas Dr. Carlos J. Finlay Camagüey. Profesor
Auxiliar Facultad de Tecnología de la Salud de la Universidad de Ciencias Médicas de La Habana
y de la Universidad de las Ciencias Informáticas.
Experiencia profesional: 18 años de labor en el área de la Informática Médica, Registros
Médicos y Estadísticas de Salud, Información Científica y Gestión de Proyectos de Ciencia,
Tecnología e Innovación.
Líneas de trabajo y/o investigación: Formación de competencias informacionales en
estudiantes universitarios, gestión de proyectos informáticos y de ciencia, tecnología e
innovación.
Correo electrónico: djolazabal@[Link]; [Link]@[Link]
Perfiles en redes profesionales:
ORCID: [Link]
ResearchGate:[Link]
Linkedin:[Link]

II
Nombre y Apellidos del Tutor: Alejandro Romero Martínez
Títulos académicos: Ingeniero en ciencias informáticas
Lugar de trabajo: Universidad de las Ciencias Informáticas (UCI). Facultad de Tecnologías
Libres (FTL).
Formación de postgrado recibida:
Categoría docente: Instructor
Categoría científica:
Responsabilidades laborales asumidas: Ha impartido la asignatura de Estructura de Datos.
Actualmente se desempeña como Profesor Principal del tercer año en la Facultad de Tecnologías
Libres.
Experiencia profesional: Graduado en el año 2023 de Ingeniería en Ciencias Informáticas en la
Universidad de las Ciencias Informáticas. Ha impartido la asignatura de Estructura de Datos,
Ingeniería de Software y Programación Web
Líneas de trabajo y/o investigación:
Correo electrónico: alejandrorm@[Link]
Ing. Alejandro Romero Martínez, graduado en el año 2023 de Ingeniería en Ciencias Informáticas
en la Universidad de las Ciencias Informáticas. Posee categoría docente de Auxiliar Técnico de la
Decencia. Ha impartido la asignatura de Estructura de Datos. Actualmente se desempeña como
Profesor Principal del tercer año en la Facultad de Tecnologías Libres. alejandrorm@[Link]

III
 Agradecimientos

AGRADECIMIENTOS

En primer lugar, quisiera expresar mi más sincero agradecimiento a la Universidad de las

Ciencias Informáticas por brindarme la oportunidad de desarrollar este trabajo de diploma, así

como por el apoyo académico y logístico durante todo el proceso de investigación y desarrollo.

Agradezco profundamente a mis tutores de tesis, el [Link] Daniel José Olazabal Guerra y Ing.

Alejandro Romero Martínez P.I, por su valioso asesoramiento, orientación y apoyo constante a lo

largo de la realización de este trabajo. Su experiencia y dedicación fueron fundamentales para la

culminación de este proyecto. A los miembros del tribunal que evaluaron mi trabajo, por su tiempo

y por las recomendaciones que permitieron enriquecer la calidad del presente estudio. Asimismo,

quiero agradecer a mis compañeros de clase y amigos, cuyo apoyo y motivación han sido

esenciales en los momentos más desafiantes. Su compañía ha sido una fuente de inspiración a

lo largo de toda la carrera. Agradezco especialmente a mi familia, por su amor incondicional,

comprensión y paciencia. Sin su apoyo constante, este logro no hubiera sido posible. Finalmente,

a todas las personas que de una u otra manera contribuyeron al desarrollo de este proyecto, ya

sea con su tiempo, conocimientos o colaboración directa, mi más sincero agradecimiento.

IV
 Dedicatoria

DEDICATORIA

Este trabajo está dedicado con todo mi amor y gratitud a mi madre, quien, aunque no se

encuentra físicamente conmigo, siempre ha sido mi mayor fuente de apoyo, amor y fortaleza. Su

sabiduría y su dedicación, tanto en los momentos de alegría como en los de dificultad, han sido

fundamentales para llegar hasta aquí. A pesar de la distancia, su presencia ha estado conmigo en

cada paso de este camino.

También dedico este trabajo a mi familia, que siempre ha estado a mi lado, brindándome su amor,

paciencia y comprensión. Sin su apoyo constante, este logro no hubiera sido posible. Gracias por

su confianza, por su aliento y por estar siempre presentes, incluso cuando los desafíos parecían

insuperables.

A ustedes, con todo mi corazón, les dedico este esfuerzo y este logro.

V
 Resumen

RESUMEN

La investigación aborda el desarrollo de una aplicación móvil para el Parque Científico Tecnológi-
co de La Habana, con el objetivo de mejorar la accesibilidad y la experiencia de usuario a la infor-
mación de la institución. Ante las limitaciones actuales de visualización y funcionalidad en dispo-
sitivos móviles, se plantea una solución tecnológica que optimice la interacción de los usuarios
con los servicios y contenidos ofrecidos en la plataforma web. La metodología empleada en esta
investigación combina métodos teóricos y empíricos, como el análisis bibliográfico, el diseño y
modelado de la aplicación móvil, y la observación para entender las necesidades y comporta-
mientos de los usuarios. Se llevaron a cabo evaluaciones de la experiencia de usuario a través
de pruebas de usabilidad para garantizar la efectividad de la solución propuesta. Como resultado,
se logró el desarrollo de una aplicación móvil que facilita el acceso a los servicios del parque, me-
jora la navegación, la interactividad y la accesibilidad, en especial para aquellos usuarios que pre-
fieren utilizar dispositivos móviles. La implementación de esta aplicación se considera una mejora
significativa en la optimización de la experiencia digital de los usuarios del Parque Científico Tec-
nológico de La Habana.

Palabras clave
Aplicación móvil, accesibilidad, experiencia de usuario, Parque Científico Tecnológico, optimiza-
ción.

ABSTRACT

The research focuses on the development of a mobile application for the Havana Science and
Technology Park, aiming to enhance accessibility and user experience when interacting with the
institution’s information. Given the current limitations in visualization and functionality on mobile
devices, a technological solution is proposed to optimize user interaction with the services and
content provided through the web platform. The methodology used in this study combines theoret-
ical and empirical approaches, including bibliographic analysis, design and modeling of the mobile

VI
 Resumen

application, and observational techniques to understand user needs and behavior. User experi-
ence evaluations were conducted through usability testing to ensure the effectiveness of the pro-
posed solution. As a result, a mobile application was successfully developed that facilitates ac-
cess to the park’s services, improves navigation, interactivity, and accessibility—especially for
users who prefer using mobile devices. The implementation of this application represents a signifi-
cant improvement in optimizing the digital experience of users at the Havana Science and Tech-
nology Park.
Keywords
Mobile application, accessibility, user experience, Science and Technology Park, optimization.

VII
 Tabla de Contenidos

TABLA DE CONTENIDOS

Introducción....................................................................................................................................12
CAPÍTULO I: FUNDAMENTOS TEÓRICOS DEL DESARROLLO DE APLICACIONES MÓVILES
PARA LA ACCESIBILIDAD DIGITAL.............................................................................................19
I.1 Conceptualización de la investigación..................................................................................19
I.2 Análisis de aplicaciones móviles para sitios de comunicación de información en el Parque
Científico Tecnológico................................................................................................................29
I.2.1 Análisis del estudio de aplicaciones homólogas.............................................................31
I.3 Tecnologías para el desarrollo del sistema...........................................................................37
I.3.1 Metodología de desarrollo de software seleccionada.....................................................37
I.4 Lenguajes, herramientas y tecnología..................................................................................42
1.4.1Lenguaje y herramienta para el modelado de la solución...............................................42
1.4.2 Lenguajes de programación...........................................................................................44
1.4.3 Herramienta para el diseño de prototipos de interfaz....................................................46
1.4.4 Entorno de desarrollo integrado.....................................................................................47
1.4.5 Herramienta para el diseño de prototipos de interfaz....................................................48
1.4.6 Gradle 8.14.................................................................................................................... 49
Conclusiones del capítulo..........................................................................................................50
CAPÍTULO II: DISEÑO DE LA SOLUCIÓN PROPUESTA AL PROBLEMA CIENTÍFICO ANÁLISIS
Y DISEÑO DE LA APLICACIÓN ANDROID PARA EL PORTAL INSTITUCIONAL DE EL
PARQUE CIENTÍFICO TECNOLÓGICO DE LA HABANA (3CE)..................................................51
II.2 Descripción del negocio.......................................................................................................51
II.2 Planificación......................................................................................................................... 54
II.2.1 Propuesta de Solución...................................................................................................56
II. 3 Requisitos del Sistema........................................................................................................56
II. 3.1 Requisitos funcionales.................................................................................................. 56
II.3.2 Requisitos no Funcionales.............................................................................................59
II. 4 Historias de Usuario (HU)...................................................................................................61
II.5 Tarjeta CRC......................................................................................................................... 67

VIII
 Tabla de Contenidos

II.6 Arquitectura del Software.....................................................................................................72

II.7 Patrones de Diseño............................................................................................................. 74
Conclusiones del capítulo..........................................................................................................78
CAPÍTULO III: IMPLEMENTACIÓN Y PRUEBAS DE LA APLICACIÓN ANDROID PARA LA
MEJORA DE ACCESIBILIDAD Y EXPERIENCIA DE USUARIO EN EL PORTAL
INSTITUCIONAL DEL PARQUE CIENTÍFICO TECNOLÓGICO DE LA HABANA........................79
III.1 Implementación...................................................................................................................79
III.2 Estándares de Codificación................................................................................................ 79
III.3 Diagrama de Despliegue.....................................................................................................81
III.4.1 Estrategia de Pruebas...................................................................................................82
III.4.2 Pruebas Unitarias..........................................................................................................83
III.4.4 Pruebas de Compatibilidad...........................................................................................96
Conclusiones Integradas.........................................................................................................98
III.4.5 Pruebas de Usabilidad................................................................................................100
Conclusiones Parciales............................................................................................................103
Conclusiones Generales.............................................................................................................. 104
Recomendaciones....................................................................................................................... 106
Referencias Bibliográficas............................................................................................................107
ANEXOS...................................................................................................................................... 112

IX
 Índices

ÍNDICE DE TABLAS
Tabla 1: Enfoques respecto a las políticas de las versiones de las API……………………………14
Tabla 2: Comparación de aplicaciones…………………………………………………………………22
Tabla 3: Comparación entre metodologías de desarrollo…………………………………………....28
Tabla 4: Comparación de lenguajes de programación……………………………………………….32
Tabla 5: Requisitos Funcionales para la Aplicación Móvil del Parque Científico Tecnológico de
La Habana………………….……………………………………………………………………………....49
Tabla 6: Historia de Usuario no. 1 para la App Móvil 3CE……………………………………………54
Tabla 7: Historia de Usuario no. 2 para la App Móvil 3CE……………………………………………55
Tabla 8: Historia de Usuario no. 3 para la App Móvil 3CE……………………………………………55
Tabla 9: Historia de Usuario no. 4 para la App Móvil 3CE……………………………………………56
Tabla 10: Historia de Usuario no. 5 para la App Móvil 3CE……………………….…………………57
Tabla 11: Historia de Usuario no. 6 para la App Móvil 3CE……………………….…………………57
Tabla 12: Historia de Usuario no. 7 para la App Móvil 3CE……………………….…………………58
Tabla 13: Historia de Usuario no. 8 para la App Móvil 3CE……………………….…………………58
Tabla 14: Historia de Usuario no. 9 para la App Móvil 3CE……………………….…………………59
Tabla 15: Historia de Usuario no. 10 para la App Móvil 3CE……………………….……………….59
Tabla 16: Tarjeta CRC – Información Institucional……………………………...…………………….61
Tabla 17: Tarjeta CRC – Servicios ofrecidos…….……………………………...…………………….61
Tabla 18: Tarjeta CRC – Proyectos incubados….……………………………...…………………….62
Tabla 19: Tarjeta CRC – Casos de Éxito..….…….……………………………...…………………….62
Tabla 20: Tarjeta CRC – Convocatorias...….…….……………………………...…………………….63
Tabla 21: Tarjeta CRC – Incentivos y Beneficios..……………………………...…………………….63
Tabla 22: Tarjeta CRC – Contacto y Ubicación….……………………………...…………………….64
Tabla 23: Tarjeta CRC – Noticias y Eventos….….……………………………...…………………….65
Tabla 24: Tarjeta CRC – FAQ…………………..….……………………………...…………………….65
Tabla 25: Tarjeta CRC – Testimonios…………….……………………………...…………………….66

X
 Índices

Tabla 26: Estrategia de Pruebas…………………………….………………………………………….78

Tabla 27: Evolución de Resultados de Pruebas Unitarias……………………………………………83
Tabla 28: Escenario de Prueba 1………………………….……………………………………………88
Tabla 29: Escenario de Prueba 2………………………….……………………………………………88
Tabla 30: Escenario de Prueba 3………………………….……………………………………………89
Tabla 31: Escenario de Prueba 4………………………….……………………………………………90
Tabla 32: Resultados de Validación Funcional por Iteración ..………………………………………91
Tabla 33: Dispositivos empleados en las pruebas de compatibilidad………………………….…...93
Tabla 34: Resultados de Pruebas de Compatibilidad………………..………………………….…....96
Tabla 35: Promedio de las puntuaciones otorgadas por los usuarios……………..………………..70

XI
 Índices

ÍNDICE DE FIGURAS

Figura 1: Arquitectura de Android……………………………..………………………………………..13

Figura 2: Modelo de Dominio……………………………………………………………………………44

Figura 3: Representación del estilo arquitectónico Monolítico………………………………………68

Figura 4: Patrón GRASP: Experto en Información………………………………………..…………..69

Figura 5: Patrón GRASP Creador 1..………………………………………………….……………….70

Figura 6: Patrón GRASP Creador 2…………………………………………………………………….71

Figura 7: Fórmula para calcular el promedio de las relaciones entre clases….………………….. 71

Figura 8: Patrón GoF: Singleton………………………………………...………………………………72

Figura 9: Nombre de las funciones y llave de cierre………………………………………………….75

Figura 10: Sentencia y cuerpo de la función……………………………...…………………………...75

Figura 11: Llave de apertura…………………………………..………………………………………...76

Figura 12: Diagrama de Despliegue………………………………..…………………………………..76

Figura 13: Grafo de la función menú………………………………..………………………………….80

Figura 14: Código de la función menú…………………………………………………..…………….66

Figura 15: Representación del resultado de la encuesta………………………………..…………100

XII
 Introducción

INTRODUCCIÓN

El auge de las aplicaciones móviles ha sido un factor clave en la digitalización del gobierno en
muchos países. Desde hace más de una década, el acceso masivo a teléfonos inteligentes y ta-
bletas ha transformado la interacción entre las administraciones públicas y la ciudadanía, facili-
tando la prestación de servicios e información de manera más inmediata y eficiente (Carnerero &
Pérez, 2011).
Este fenómeno ha influido significativamente en la modernización de sectores estratégicos como
la educación, la salud y el comercio, permitiendo la creación de plataformas digitales que mejoran
la accesibilidad y la calidad de los servicios. En particular, los gobiernos han incorporado aplica-
ciones móviles para optimizar procesos administrativos, agilizar trámites y fortalecer la comunica-
ción con los ciudadanos, respondiendo a la creciente demanda de inmediatez y disponibilidad de
información en tiempo real (Cepeda et al., 2022).
El avance de la tecnología móvil no solo ha transformado la relación entre los ciudadanos y las
instituciones gubernamentales, sino que también ha permitido la automatización de procesos cla-
ve, la personalización de servicios y la mejora en la eficiencia operativa de los organismos públi-
cos. Hoy en día, numerosas administraciones han implementado soluciones digitales con el obje-
tivo de ofrecer plataformas más intuitivas, accesibles y adaptadas a las necesidades de la pobla-
ción (González & Martínez, 2023).
En América Latina, la adopción de tecnologías móviles ha cobrado especial relevancia debido al
aumento sostenido en el acceso a Internet y la penetración de dispositivos inteligentes. Según
Cubadebate (2024), el número de usuarios de telefonía móvil en la región ha crecido exponen-
cialmente, facilitando la integración de nuevas soluciones digitales en el ámbito gubernamental.
Este crecimiento ha permitido la digitalización de procesos administrativos, la mejora en la ges-
tión de recursos públicos y el desarrollo de sistemas más transparentes y accesibles.
Asimismo, la tecnología móvil ha promovido una mayor participación ciudadana en la toma de
decisiones gubernamentales, permitiendo el acceso a plataformas interactivas que informan, edu-
can y facilitan la comunicación directa con las autoridades. La evolución tecnológica ha dado lu-

1
 Introducción

gar a iniciativas de gobierno digital que buscan fortalecer la relación entre el Estado y la socie-
dad, promoviendo modelos de gestión más eficientes y sostenibles (Fernández, 2021)
Cuba no ha sido ajena a esta transformación. En los últimos años, el país ha experimentado un
crecimiento notable en el uso de tecnologías de la información y la comunicación (TIC), impulsa-
do por la expansión del acceso a Internet y la proliferación de dispositivos móviles. De acuerdo
con una encuesta realizada por Cubadebate en 2023, el 92% de los cubanos utiliza Internet todos
los días, mientras que el 51% emplea teléfonos móviles como su principal herramienta para acce-
der a información gubernamental (Cubadebate, 2024). Este cambio ha generado nuevas oportu-
nidades para mejorar la interacción entre el gobierno y la población, facilitando la digitalización de
servicios clave en distintos ámbitos.
A pesar de los avances tecnológicos, aún persisten desafíos relacionados con la optimización de
plataformas digitales para dispositivos móviles. Muchas instituciones gubernamentales han mi-
grado sus servicios a entornos digitales, pero la adaptación de estos sistemas a interfaces móvi-
les sigue siendo limitada en algunos casos, afectando la accesibilidad y la experiencia de usuario.
La implementación de soluciones tecnológicas centradas en dispositivos móviles se ha convertido
en una necesidad fundamental para garantizar un acceso ágil y eficiente a los servicios guberna-
mentales (Fernández, 2021).
El Parque Científico Tecnológico de La Habana es un ejemplo destacado del modelo de desarro-
llo innovador en Cuba, el cual integra la Universidad de las Ciencias Informáticas y otros centros
de desarrollo de software e investigación (Torralbas Ezpeleta et al., 2021). A pesar de los desa-
fíos tecnológicos, se busca posicionar esta universidad como un modelo consolidado a nivel inter-
nacional, a través de la cooperación académica y empresarial (Torralbas Ezpeleta et al., 2021).
El acceso a la información institucional del Parque Científico Tecnológico de La Habana (3CE)
por parte de clientes y visitantes enfrenta desafíos en términos de disponibilidad y adaptabilidad a
dispositivos móviles. Actualmente, la información sobre servicios, proyectos y oportunidades del
Parque no se presenta de manera optimizada para smartphones desde el portal web institucional,
lo que dificulta la experiencia de los usuarios que buscan acceder a estos datos desde sus dispo-
sitivos.

2
 Introducción

En un contexto donde la mayoría de los usuarios prefieren consultar información a través de sus
teléfonos móviles, la ausencia de una plataforma dedicada con una interfaz intuitiva y accesible
limita el alcance del Parque y la efectividad de su comunicación institucional. Además, la falta de
un enfoque mobile-first impide que los contenidos sean fácilmente navegables, afectando la inte-
racción y comprensión de la información.
Ante esta situación problemática, la autora identifica como problema de investigación: ¿Cómo
contribuir a un mejor acceso a la información institucional que provee el Parque Científico Tecno-
lógico de La Habana?
Se define como objeto de estudio: accesibilidad a la información institucional a través de aplica-
ciones móviles, enmarcado en el campo de acción: aplicaciones móviles Android para la accesi-
bilidad a la información institucional del Parque Científico Tecnológico de La Habana.
Para dar solución al problema planteado, se establece como objetivo general: desarrollar una
aplicación móvil para dispositivos con sistema operativo Android, que contribuya a una mejor ac-
cesibilidad a la información institucional del Parque Científico Tecnológico de La Habana
Objetivos específicos:
1. Realizar un estudio sobre los referentes teóricos relacionados con el desarrollo de aplica-
ciones móviles en parques científicos y tecnológicos.
2. Identificar las funcionalidades más relevantes y demandadas por los usuarios que deben
ser incluidas en la aplicación móvil para dar respuesta a sus necesidades de información
institucional.
3. Desarrollar una aplicación móvil funcional y estable para dispositivos con sistema operati-
vo Android, que brinde el acceso a contenidos institucionales con estructura adaptada
para que garantice un rendimiento eficiente en entornos móviles.
4. Validar el desempeño de la aplicación mediante pruebas de software, que permitan la
evaluación de su efectividad en términos de accesibilidad, interacción y satisfacción del
usuario final.

3
 Introducción

Se plantea como idea a defender que la implementación de una aplicación móvil Android,
diseñada bajo un enfoque mobile-first y centrado en el usuario, contribuirá a mejorar la
accesibilidad a la información institucional del Parque Científico Tecnológico de La Habana.

Para llevar el desarrollo de la investigación se emplearon los siguientes métodos científicos de

investigación:

Métodos teóricos: permiten describir las relaciones esenciales del objeto de investigación no
observables directamente, cumpliendo con la construcción del conocimiento que facilite la
interpretación conceptual de los datos empíricos, la construcción y desarrollo de teorías(Perea
et al., 2021) .

Analítico – sintético: para el estudio de las fuentes bibliográficas existentes referentes al

tema, identificando los elementos más importantes y necesarios para dar solución al pro-
blema planteado.

El método histórico-lógico: se utiliza para identificar las tendencias actuales de los

sistemas de acceso a la información institucional y su evolución, además en la recopilación
de información para el estudio de sistemas homólogos.

Modelación: Es utilizada para elaborar los diagramas correspondientes a la

representación de la propuesta de solución, al permitir la definición y descripción de las
funcionalidades que la conforman. En la investigación se utiliza para hacer diagrama de
despliegue y diagrama de clases.

Métodos empíricos: Los métodos de investigación empírica abarcan una serie de

procedimientos prácticos que, junto con los medios de investigación, permiten descubrir las
características fundamentales y las relaciones esenciales del objeto de estudio. Estos métodos
constituyen una etapa en el proceso de investigación en la cual el contenido se basa
principalmente en la experiencia y se somete a un proceso de elaboración racional, siendo
expresado en un lenguaje específico(Chagoya, 2008).

4
 Introducción

Análisis documental: se utiliza en la consulta de la literatura especializada en las

temáticas a fines de la investigación y para conformar el marco teórico.

Observación: sirve para valorar las tecnologías y aplicaciones existentes, además de

comparar con sistemas homólogos y así poder definir la propuesta, dando a conocer lo
que hace falta realizar y como se realizará (ver anexo1).

La presente investigación se estructuró en tres capítulos, conformados de la siguiente forma:

Capítulo 1: Fundamentación teórica: En este capítulo se exponen los conceptos asociados a la
solución de la problemática y varias de las soluciones existentes a nivel mundial sobre aplicacio-
nes móviles para divulgación de información que utilizan API. Además, se analizan las herramien-
tas, lenguajes y tecnologías a tener en cuenta para el proceso de desarrollo de soluciones basa-
das en aplicaciones móviles.
Capítulo 2: Análisis y diseño de la propuesta de solución: En este capítulo se documenta todo el
proceso de elaboración de la aplicación de manera detallada y se desglosan las características
funcionales que debe cumplir el sistema de acuerdo a la metodología de desarrollo escogida. Se
describen los patrones utilizados en la solución, así como las características propias del sistema
a desarrollar en cuanto a medios y herramientas utilizados.
Capítulo 3. Implementación y pruebas de validación: En este capítulo Se explican los estilos de
programación y estándares de codificación empleados y por último se describen las pruebas de
software que demuestran que la aplicación funciona correctamente.

5
 Capítulo I

CAPÍTULO I: FUNDAMENTOS TEÓRICOS DEL DESARROLLO DE APLICACIONES MÓVILES

PARA LA ACCESIBILIDAD DIGITAL

El presente capítulo tiene como objetivo abordar los diferentes elementos que brindan la base
teórica y conceptual para el desarrollo de la aplicación móvil propuesta. Se analizan un grupo de
herramientas y tecnologías que, desde el punto de vista práctico, pueden ser empleadas para
lograr el propósito de la investigación. Se realiza, además, un análisis sobre los aspectos funda-
mentales del sistema operativo Android. De este modo, se podrá realizar una correcta interpreta-
ción de la situación problemática y del problema a resolver.

I.1 Conceptos asociados a la investigación

Dispositivos móviles
Un dispositivo móvil es un aparato de pequeño tamaño, con algunas capacidades de
procesamiento, con conexión permanente o intermitente a una red, con memoria limitada,
que ha sido diseñado específicamente para una función, pero que puede llevar a cabo
otras funciones más generales. De acuerdo con esta definición existen multitud de
dispositivos móviles, desde los reproductores de audio portátiles hasta los navegadores
GPS, pasando por los teléfonos móviles, los PDAs o los Tablet PCs (Niño 2011; Garrido,
Schlesinger y Hoganson 2011)

Aplicación móvil
Una aplicación móvil, también llamada app móvil o APK, es un tipo de software diseñado
para ejecutarse en teléfonos inteligentes, tabletas y otros dispositivos móviles. Permite a
los usuarios realizar tareas de cualquier tipo: profesional, educativa, informativa, de ocio
y/o servicios (López, 2020). Califica una aplicación móvil como un programa adaptado a
las características y especificaciones de los dispositivos móviles, permitiendo cubrir

6
 Capítulo I

prácticamente cualquier necesidad de forma ubicua desde su descarga en línea (González

& Pérez, 2022; Ramírez, 2021; Pérez, 2023, Hernández, 2021).

Sistema operativo Android

Android es un sistema operativo y una pila de software creados para una serie de
dispositivos con diferentes factores de forma, como teléfonos, tabletas, wearables,
televisores, automóviles y dispositivos conectados (Projects, 2021). Los objetivos
principales de Android son crear una plataforma abierta disponible para que las
operadoras, los fabricantes de equipos originales y los desarrolladores realicen sus ideas y
ofrezcan productos de éxito en el mundo real que mejoren la experiencia móvil de los
usuarios (García, 2022). Android bajo la definición de Google se considera un "software
stack" o una pila de software, ya que está conformada por:
• El sistema operativo, donde todas las funciones se desarrollan.
• El middleware que permite la conexión entre redes.
• Las aplicaciones que constituyen todos los programas que el teléfono puede ejecutar
(Vásquez & Rodríguez, 2021).
Es un sistema de código abierto, robusto y con miles de desarrolladores y aplicaciones en
el mundo.
Android domina la cuota de mercado de los smartphones con un 86.8% según el Interna-
tional Data Corporation en 2018 (IDC, 2018). Samsung, su contribuyente número uno, per-
manece en el lugar más alto en ventas. Todo lo anteriormente mencionado fue considera-
do para decidir utilizar el sistema operativo Android para la propuesta de solución. Esta
decisión responde, además, a la política de utilización de software libre en la que se en-
cuentra enmarcada Cuba (González, 2022).

Accesibilidad de la información
El acceso a la información abarca diversas temáticas relacionadas con la disponibilidad,
accesibilidad y asequibilidad de la información. Entre estos aspectos se incluyen el

7
 Capítulo I

multilingüismo, los metadatos, la interoperabilidad, los programas informáticos de código

abierto, el contenido libre y las licencias Creative Commons, así como las necesidades
especiales de las personas con discapacidad (UNESCO, 2017).
La accesibilidad a la información se refiere a la capacidad de todas las personas,
independientemente de sus habilidades, ubicación geográfica o contexto cultural, para
obtener, entender y utilizar la información de manera efectiva. Este concepto abarca tanto
la disponibilidad física de la información como la capacidad de los usuarios para acceder a
ella y beneficiarse de su contenido. Es fundamental para promover la equidad y la
inclusión en la sociedad, asegurando que todos tengan las mismas oportunidades de
acceder a los recursos y conocimientos necesarios para su desarrollo personal y
profesional (Carbo & Smith, 2008).

Información institucional
Según Bruzón (2024), el Gobierno de España (2023) plantea que la información
institucional se refiere a la gestión y difusión de datos que las organizaciones y entidades
públicas o privadas generan y utilizan para comunicar su identidad, actividades y objetivos
a sus diferentes públicos, que requiere la aplicación de técnicas de gestión para el manejo
efectivo de la información.

I.2 Análisis de aplicaciones móviles para sitios de comunicación de información en el

Parque Científico Tecnológico

El desarrollo de las tecnologías de la información y la comunicación (TIC) ha tenido un impacto

significativo en el sector científico y tecnológico, especialmente en los Parques Científicos y Tec-
nológicos (PCT), donde la innovación y la conectividad son factores clave para el desarrollo de
nuevos proyectos. Las aplicaciones móviles juegan un papel fundamental en la mejora de la co-
municación y el acceso a información en tiempo real, lo que permite a los investigadores, em-
prendedores y empresas vinculadas a un PCT interactuar de manera eficiente, acceder a recur-
sos actualizados y compartir resultados y conocimientos.

8
 Capítulo I

En el contexto de un PCT, las aplicaciones móviles específicas facilitan la difusión de investiga-

ciones, programas de incubación, eventos académicos y científicos, así como la interacción entre
las entidades que componen el parque. Por ejemplo, aplicaciones diseñadas para los PCT pue-
den incluir funcionalidades como la programación de actividades, acceso a bases de datos de
investigación, herramientas de colaboración en línea y notificaciones sobre eventos o publicacio-
nes relevantes. Además, la adopción de TIC a través de estas aplicaciones optimiza los procesos
administrativos y de gestión dentro del PCT, mejorando la eficiencia en la interacción entre los
distintos actores que operan en este entorno.
En cuanto a la accesibilidad de estas aplicaciones, las tecnologías móviles permiten a los usua-
rios del PCT acceder a la información desde cualquier lugar, lo que resulta esencial para aquellos
que, por razones de trabajo o investigación, se encuentran fuera de las instalaciones del parque.
Esto también es crucial para el fortalecimiento de las redes de cooperación científica, ya que faci-
lita la comunicación entre las distintas partes interesadas, sin importar las barreras geográficas.
El uso de aplicaciones móviles en los PCT también plantea desafíos, especialmente en cuanto a
la adaptación de los sistemas a las características locales de conectividad, sobre todo en países
en vías de desarrollo, donde el acceso a Internet y la infraestructura tecnológica pueden ser limi-
tados. A pesar de esto, las aplicaciones móviles representan una oportunidad para superar estas
limitaciones, proporcionando una vía directa y accesible para que los miembros de un PCT inte-
ractúen y aprovechen los recursos disponibles.
Dentro del desarrollo de las aplicaciones móviles, existen diferentes clasificaciones. A
continuación, la descripción de los tres tipos según (Torres, 2022):
Aplicaciones nativas: Las aplicaciones nativas son aquellas desarrolladas bajo un lenguaje y
entorno de desarrollo específico, lo que permite que su funcionamiento sea muy fluido y estable
para el sistema operativo en el que fue creada. La opción principal para desarrollar en Android es
Java y Kotlin (González, 2021).
Aplicaciones web: Son usadas para brindar accesibilidad a la información desde cualquier
dispositivo, sin importar el sistema operativo, ya que solo se necesita un navegador para acceder
a ellas. Están desarrolladas usando lenguajes para el desarrollo web como HTML, CSS y

9
 Capítulo I

JavaScript, y marcos de trabajo para el desarrollo de aplicaciones web, como Jquery Mobile,
Sencha y Kendo UI, entre otros (Pérez & Fernández, 2021).
Aplicaciones híbridas: Este tipo de aplicaciones combina aspectos de las aplicaciones nativas y
de las aplicaciones web, según convenga. La facilidad que brinda este tipo de desarrollo es que
no hay un entorno específico para su uso, y la mayoría de las herramientas son de uso gratuito,
pudiendo integrarse con las herramientas de aplicaciones nativas (Torres, 2022).
A la hora de desarrollar aplicaciones móviles, existen muchas opciones a las cuales recurrir,
dependiendo del tipo de información que se desea brindar y la forma en que se va a realizar. El
uso de los recursos de los dispositivos móviles y su sistema operativo son datos fundamentales a
tener en cuenta (González, 2021).
En esta investigación, se ha decidido implementar una aplicación móvil nativa que permitirá
optimizar el rendimiento del portal 3CE en dispositivos móviles, manteniendo la integridad de las
funcionalidades esenciales del portal y mejorando la interacción de los usuarios con los servicios
ofrecidos.

I.2.1 Análisis del estudio de aplicaciones homólogas

En la actualidad, el desarrollo de aplicaciones móviles para información institucional ha experi-

mentado un crecimiento significativo. Diversas investigaciones internacionales y nacionales han
abordado la problemática con diferentes enfoques, ofreciendo aplicaciones con funcionalidades
variadas que pueden servir de referencia para el desarrollo de la propuesta de solución plantea-
da.

El objetivo de este estudio es analizar sistemas homólogos existentes, tanto a nivel internacional
como en Cuba, para identificar elementos de diseño, arquitectura, lenguajes de programación y
funcionalidades comunes que puedan tomarse como referencia en la definición de los requisitos
funcionales de la propuesta de solución.

10
 Capítulo I

Fueron analizadas once (11) aplicaciones homólogas que coinciden en alguna medida con los
objetivos que se persiguen con el desarrollo de la aplicación propuesta. Para el desarrollo del
estudio se tomaron en cuenta las siguientes características:

1. Diseño Visual:

El diseño visual constituye el marco estético de una aplicación, integrando principios de composi-
ción, colorimetría, tipografía y jerarquía visual. Su propósito es generar coherencia gráfica, facili-
tar la comprensión del contenido y promover una experiencia atractiva y armoniosa para el usua-
rio. Según Tomita (2015), el diseño visual debe contemplarse como un recurso comunicativo que
influye directamente en el procesamiento cognitivo del usuario.

2. Interfaz de Usuario (UI)

La UI abarca los elementos gráficos e interactivos que conforman la superficie de contacto entre
el usuario y el sistema. Incluye botones, formularios, iconografía y estructuras de navegación. Un
diseño de UI eficiente debe propiciar una interacción intuitiva, fluida y coherente con los objetivos
funcionales de la aplicación. Bödkker (2021) destaca que el diseño de interfaces influye directa-
mente en la percepción de usabilidad por parte del usuario.

3. Accesibilidad

La accesibilidad es un principio fundamental en el desarrollo inclusivo. Asegura que las aplicacio-

nes sean utilizables por personas con diversas capacidades físicas, sensoriales o cognitivas. Su
implementación involucra la optimización de contraste visual, etiquetado semántico, navegación
mediante teclado y compatibilidad con tecnologías de asistencia como lectores de pantalla. Ordo-
ñez, Hilera y Cueva (2022) evidencian que el desarrollo guiado por modelos permite una integra-
ción más sistemática de requisitos de accesibilidad.

4. Optimización Mobile-first

11
 Capítulo I

El enfoque mobile-first prioriza la experiencia en dispositivos móviles desde las etapas iniciales
del diseño. Este paradigma reconoce la creciente prevalencia del acceso móvil y establece pau-
tas para garantizar responsividad, eficiencia de carga, jerarquización del contenido y adaptabili-
dad funcional en pantallas reducidas. Ramu (2023) propone estrategias de optimización centra-
das en el rendimiento, la gestión energética y la adaptabilidad a entornos de red variables.

5. Estrategias de Optimización de Aplicaciones Móviles

Las estrategias de optimización en aplicaciones móviles se enfocan en mejorar el rendimiento, la

eficiencia energética y la experiencia del usuario en condiciones reales de uso. Estas incluyen
técnicas de prueba de rendimiento, gestión de procesos en segundo plano, reducción de activi-
dad de red y optimización del uso de CPU y batería. Según Ramu (2023), la integración de estas
estrategias en el ciclo de desarrollo permite anticipar cuellos de botella y garantizar una experien-
cia fluida y satisfactoria en dispositivos móviles.

Tabla 2: Comparación de aplicaciones

Aplicación Diseño/UI Accesibilidad Optimización Mobile-

first / Metodologías

Espaitec App Interfaz limpia e intui- Navegación jerarqui- Diseño adaptable y

tiva, orientada a la zada que facilita el responsive, priorizan-
visualización de even- acceso rápido a infor- do la experiencia móvil
tos y notificaciones mación sobre eventos mediante notificacio-
clave. y proyectos. nes en tiempo real.

12
 Capítulo I

Tech Park Finder Interfaz basada en la Filtros de búsqueda Estrategia mobile-first

geolocalización, con avanzados y presenta- centrada en la optimi-
mapas interactivos y ción clara de la infor- zación de datos geolo-
visualización de datos mación de cada par- calizados y una inter-
estructurados. que. faz interactiva.

PCT Valencia App Diseño rico en conte- Interfaz adaptativa que Integración de actuali-
nido con secciones atiende a distintos per- zaciones en tiempo
diferenciadas (even- files de usuario y ne- real y servicios inte-
tos, formación, colabo- cesidades de informa- ractivos, garantizando
ración). ción detallada. rendimiento en dispo-
sitivos móviles.

InnoApps Interfaz colaborativa Herramientas integra- Metodologías mobile-

con énfasis en la ges- das que facilitan la first que priorizan la
tión de proyectos y colaboración y el ac- conectividad y la
networking entre usua- ceso a contenidos ac- adaptabilidad a diver-
rios. tualizados de forma sas condiciones de
sencilla. uso.

ParkWay Diseño minimalista Notificaciones perso- Optimización enfoca-

con elementos visua- nalizadas y un sistema da en eficiencia y velo-
les destacados, ideal de búsqueda intuitivo cidad, garantizando
para emprendedores y que mejora la expe- rapidez en la búsque-
startups. riencia de usuario. da y acceso a oportu-

13
 Capítulo I

nidades.

TecnoPark Interfaz orientada a la Accesibilidad reforza- Accesibilidad reforza-

gestión colaborativa, da mediante guías, da mediante guías,
con módulos para cur- alertas y una estructu- alertas y una estructu-
sos, eventos y proyec- ra intuitiva para em- ra intuitiva para em-
tos. prendedores y colabo- prendedores y colabo-
radores. radores

Smart Park App Diseño multifuncional Integración de múlti- Alta adaptabilidad y

y modular, adaptable a ples servicios que faci- robustez en condicio-
diversos mercados y litan el acceso a dife- nes de conectividad
personalizable según rentes tipos de conte- variable, mediante un
usuario. nido de forma clara. enfoque mobile-first
bien definido.

CubaEmprende Diseño sencillo y Plataforma optimizada Enfoque mobile-first

adaptable que conecta para superar limitacio- adaptado al contexto
a emprendedores con nes locales, facilitando nacional, priorizando
actores del ecosiste- el acceso incluso en funcionalidades esen-
ma innovador. infraestructuras bási- ciales frente a limita-
cas. ciones tecnológicas.

Red de Innovación en Interfaz colaborativa Plataforma integrado- Metodología mobile-

Cuba con una estructura ra y responsive que first que garantiza una
organizada para el favorece la comunica- experiencia uniforme y

14
 Capítulo I

intercambio de infor- ción y la interconexión manejo eficiente de la

mación entre actores. entre instituciones. información en dispo-
sitivos móviles.

TecnoCuba App Interfaz informativa Acceso ágil a la infor- Desarrollo mobile-first

con secciones bien mación mediante me- con soporte offline,
definidas (proyectos, canismos de caching y mitigando problemas
noticias, convocato- actualizaciones auto- de conectividad y ase-
rias). máticas. gurando el acceso
continuo a los conteni-
dos.

Ciencia y Tecnología Diseño con jerarquía Soporte multiformato Optimización mobile-

Cuba visual clara para noti- (texto, multimedia) y first que adapta la pre-
cias y eventos, facili- adaptación a distintas sentación de conteni-
tando la segmentación dimensiones de panta- dos a diversas condi-
del contenido. lla para mayor clari- ciones de conectividad
dad. y dispositivos

Fuente: elaboración propia.

Las aplicaciones móviles analizadas en el estudio de homólogos son de uso público, pero no ocu-
rre así con el código fuente de las mismas por lo que no pueden ser adaptadas al contexto del
Parque Científico Tecnológico de la Habana. Estas están disponibles y es común que se use SO
Android, cuenten con un menú lateral y muestren el tipo de servicio que ofrece la institución.

15
 Capítulo I

El análisis comparativo de aplicaciones móviles internacionales y nacionales evidencia que los

usuarios demandan funcionalidades que permitan el acceso inmediato y detallado a la informa-
ción, con una interfaz intuitiva y herramientas colaborativas que potencien el networking. En este
sentido, la incorporación de notificaciones en tiempo real, sistemas de búsqueda avanzados, mó-
dulos de interacción y accesibilidad offline se perfilan como elementos esenciales para la aplica-
ción móvil del Parque Científico Tecnológico de La Habana.

I.3 Tecnologías para el desarrollo del sistema.

A continuación, se presentan las diferentes herramientas utilizadas durante el desarrollo de la

aplicación móvil, así como las características que estas presentan.

I.3.1 Metodología de desarrollo de software seleccionada

Una metodología de desarrollo de software es un conjunto de procedimientos, técnicas, herra-

mientas y documentos auxiliares que guían a los desarrolladores en el proceso de implementa-
ción de nuevos sistemas de información (Peñalvo, Holgado & Ingelmo, 2020). La selección de la
metodología adecuada es fundamental para el éxito de un proyecto, ya que esta define qué hacer
y cómo hacerlo, y sostiene todo el proceso posterior de desarrollo, desde el diseño hasta la im-
plementación.

Las metodologías se agrupan en dos grandes tipos según sus características fundamentales: las
metodologías tradicionales (o prescriptivas) y las metodologías ágiles (o ligeras).

Metodología Tradicional: Las metodologías tradicionales se centran en el control del proceso de

desarrollo, siguiendo un enfoque estructurado y bien documentado. Este tipo de metodologías
favorece la rigidez, el control y la planificación exhaustiva, lo cual garantiza que el software sea
de alta calidad y eficiente, pero a un alto costo. Las fases de trabajo están claramente definidas, y
el proceso se detalla minuciosamente en la etapa inicial, lo que las hace menos flexibles ante
cambios durante el desarrollo. Ejemplos de metodologías tradicionales incluyen RUP (Rational

16
 Capítulo I

Unified Process) y MSF (Microsoft Solutions Framework), que requieren documentación detallada
y una planificación precisa del proyecto desde su inicio (Fuentes, 2015).

Metodología Ágil: Las metodologías ágiles, por otro lado, ofrecen flexibilidad y rapidez en la adap-
tación a los cambios, lo que las convierte en una excelente opción para proyectos en entornos
volátiles. Estas metodologías permiten la mejora continua del software mediante iteraciones rápi-
das y ciclos de retroalimentación constante. En lugar de enfocarse en la planificación rigurosa y la
documentación exhaustiva, las metodologías ágiles priorizan la colaboración entre los desarrolla-
dores y los usuarios finales, lo que facilita la creación de soluciones más alineadas con las nece -
sidades reales. Algunas de las metodologías ágiles más populares incluyen Scrum, XP (Extreme
Programming) y AUP (Agile Unified Process) (Gabriel, 2016).

La principal ventaja de las metodologías ágiles radica en su eficiencia en términos de tiempo y

recursos, siendo más económicas en comparación con las tradicionales, sin comprometer la cali-
dad del producto final (Gabriel, 2015).

Metodologías para el Desarrollo de Aplicaciones Móviles

En el ámbito del desarrollo de aplicaciones móviles, existen metodologías específicas que se

adaptan mejor a las particularidades de este tipo de proyectos. Entre las más destacadas se en-
cuentran las metodologías Mobile-D y HMD, que están especialmente diseñadas para garantizar
la flexibilidad y la eficiencia en el desarrollo de aplicaciones móviles.

1. Mobile-D: Desarrollada por el equipo de investigación del VTT (Technical Research Centre
of Finland), esta metodología se organiza en cinco fases: exploración, inicialización, pro-
ducción, estabilización y prueba del sistema. Cada una de estas fases tiene subfases de
planificación, trabajo y liberación, lo que permite una gestión más dinámica y adaptada a
los cambios durante el ciclo de vida del proyecto (Fuentes, 2015).

17
 Capítulo I

2. HMD (Hybrid Methodology Design): Esta metodología combina los enfoques del desarrollo
adaptativo de software (ASD) y el diseño de nuevos productos (NPD). Su ciclo de vida in-
cluye fases tradicionales como análisis, diseño, implementación, pruebas y transición, pero
integra un enfoque híbrido que ayuda a mitigar los riesgos de desarrollo mediante la intro-
ducción de iteraciones tempranas y segmentadas (Gabriel, 2015).
3. Proceso de Desarrollo Móvil en Espiral: Este modelo está basado en el modelo de desa-
rrollo en espiral, y se enfoca en la participación del usuario en todas las fases del ciclo de
vida de la aplicación móvil. Se prioriza la usabilidad y la evaluación constante mediante
prototipos, permitiendo que el software evolucione con un enfoque centrado en el usuario
(Fuentes, 2015).

Tabla 3 Comparación entre metodologías de desarrollo

Adecuación para el
Metodología Ventajas Desventajas
Proyecto
- Adecuada para equi-
pos pequeños. - Enfo-
Perfecta para proyec-
que en la codificación - Poca documenta-
tos con equipos pe-
XP (Extreme Progra- y entrega continua. - ción. - Requiere parti-
queños y cuando los
mming) Flexibilidad y adapta- cipación constante del
cambios frecuentes
ción a cambios. - Re- cliente.
son necesarios.
lación cercana cliente-
desarrollador.
- Buen enfoque para - Requiere más tiem- Menos adecuada por
equipos medianos a po para planificación y el tamaño pequeño
Scrum grandes. - Ofrece cla- gestión. - Puede ser del equipo y la necesi-
ridad en roles y res- menos flexible que dad de interacción
ponsabilidades. XP. constante.
- Rigidez ante cam- No ideal debido a la
- Fases claramente
bios. - Lento para falta de flexibilidad y la
Waterfall (Tradicional) definidas. - Documen-
adaptarse a entornos interacción limitada
tación completa.
cambiantes. con el cliente.
RUP (Rational Unified Enfoque estructurado Baja flexibilidad ante Proyectos con requisi-
Process) y planificado. <br> - cambios. <br> - Alto tos bien definidos y
Documentación deta- costo y mayor tiempo estables, donde se

18
 Capítulo I

Adecuación para el
Metodología Ventajas Desventajas
Proyecto
llada y control riguroso
del desarrollo.<br> -
de planificación y eje- justifica una planifica-
Orientado a lograr alta
cución. ción exhaustiva.
calidad en el producto
final.
Proceso bien definido
Proyectos instituciona-
con énfasis en control Menor adaptabilidad
les o de gran escala
y documentación com- ante cambios impre-
MSF (Microsoft Solu- que requieran altos
pleta.<br> - Garantiza vistos.<br> - Mayor
tions Framework) niveles de control y
un seguimiento preci- inversión en tiempo y
predictibilidad en el
so del ciclo de vida del recursos.
desarrollo.
proyecto.
Combina la rigurosi-
Proyectos que buscan
dad de los enfoques Puede requerir ajustes
un balance entre pla-
tradicionales con la importantes en la cul-
nificación detallada y
flexibilidad de metodo- tura de desarrollo y
AUP (Agile Unified agilidad, especialmen-
logías ágiles.<br> - mayor coordinación
Process) te cuando se desea
Permite iteraciones entre equipos.<br> -
una transición gradual
rápidas y una adapta- Requiere alta comuni-
desde métodos tradi-
ción intermedia a cación interna.
cionales.
cambios.
Fases específicas (ex-
ploración, inicializa- Requiere una coordi- Proyectos móviles de
ción, producción, esta- nación meticulosa en mediana a alta com-
bilización y prueba) la transición entre fa- plejidad donde es es-
Mobile-D adaptadas al desarro- ses.<br> - La gestión encial seguir etapas
llo móvil.<br> - Permi- de múltiples subfases bien definidas y flexi-
te una gestión dinámi- puede incrementar la bles para ajustar fun-
ca y respuesta a cam- complejidad operativa. cionalidades.
bios propios del móvil.
Combina enfoques del La integración de dos
Proyectos móviles
desarrollo adaptativo y enfoques puede gene-
innovadores que ne-
del diseño de nuevos rar complejidades en
HMD (Hybrid Metho- cesiten gestionar ries-
productos.<br> - Intro- la coordinación y eje-
dology Design) gos y requerimientos
duce iteraciones tem- cución.<br> - Requie-
cambiantes mediante
pranas para detectar y re un equipo versátil y
un enfoque híbrido.
mitigar riesgos. bien organizado.
Proceso de Desarrollo Fuerte énfasis en la Las iteraciones conti- Proyectos en los que
Móvil en Espiral participación y retroali- nuas pueden extender la experiencia del

19
 Capítulo I

Adecuación para el
Metodología Ventajas Desventajas
Proyecto
mentación del usuario el tiempo total de de-
usuario y la usabilidad
en cada iteración.<br> sarrollo.<br> - Mayor
sean prioritarias, per-
- Permite la validación esfuerzo en la evalua-
mitiendo actualizar el
constante mediante ción y reconfiguración
diseño con base en
prototipos que enfo- en función del feedba-
prototipos y pruebas.
can la usabilidad. ck.
Fuente: elaboración propia.

Selección de la Metodología para la Aplicación Móvil del Parque Científico Tecnológico de la Ha-
bana (PCT)
En este caso, para la implementación de la aplicación móvil del Parque Científico Tecnológico de
La Habana (PCT), se ha decidido adoptar la metodología XP (Extreme Programming) debido a
las características y beneficios que ofrece, especialmente en proyectos con equipos pequeños y
dinámicos. Dado que la implementación se realizará por un único desarrollador, la metodología
XP se adapta muy bien al proyecto, ya que pone énfasis en la codificación constante, la flexibili -
dad en la documentación y la rapidez en la entrega de prototipos funcionales.

Además, la naturaleza cambiante de los requisitos de un proyecto de este tipo, donde los ajustes
pueden ser frecuentes debido a las nuevas necesidades del PCT, hace que la metodología XP
sea una excelente opción, ya que se enfoca en la adaptabilidad y la relación constante con el
cliente (en este caso, el equipo de desarrollo o las partes interesadas dentro del PCT). La interac-
ción directa entre el cliente y el desarrollador, un principio fundamental de XP, permite que cual-
quier cambio necesario se pueda integrar rápidamente al sistema, reduciendo la posibilidad de
malentendidos o retrasos.

I.4 Lenguajes, herramientas y tecnología.

A continuación, se definen las herramientas, lenguajes y tecnologías que apoyarán el desarrollo

de la investigación.

20
 Capítulo I

1.4.1Lenguaje y herramienta para el modelado de la solución.

Para el modelado se emplea el Lenguaje Unificado de Modelado (UML) en la versión 2.5. El UML
es un lenguaje de modelado visual de propósito general que se utiliza para especificar, visualizar,
construir y documentar los artefactos de un sistema de software. Captura decisiones y
conocimiento sobre sistemas que deben ser construidos. Se usa para comprender, diseñar, ojear,
configurar, mantener y controlar la información sobre tales sistemas(Rumbaugh et al., 2010).
UML facilita el proceso de diseño de tal forma que el propietario del producto, clientes,
desarrolladores y otras personas involucradas en el desarrollo del sistema lo comprendan. Por
las características antes mencionadas y debidas a que el equipo de desarrollo cuenta con
experiencia en la utilización del lenguaje, se decide emplearlo.

Herramienta de Ingeniería de Software Asistida por Computadora (CASE)

Las herramientas CASE son un conjunto de programas y ayudas que dan asistencia a los
analistas, ingenieros de software y desarrolladores, durante todos los pasos del ciclo de vida de
desarrollo de un software. El Lenguaje Unificado de Modelado (UML), permite visualizar,
especificar, construir y documentar los artefactos de un sistema que involucra el desarrollo de un
software(Sommerville, 2005).

Visual Paradigm for UML 17.1:

Visual Paradigm para UML es una herramienta para desarrollo de aplicaciones utilizando
modelado UML, ideal para Ingenieros de Software, analistas de sistemas y arquitectos de
sistemas que están interesados en construcción de sistemas a gran escala y necesitan
confiabilidad y estabilidad en el desarrollo orientado a objetos. Es una herramienta
multiplataforma, por lo que tiene la capacidad de ejecutarse sobre diferentes sistemas
operativos(Visual Paradigm, 2024a).

Principales características de Visual Paradigm for UML(Visual Paradigm, 2024b).

21
 Capítulo I

 Entorno de creación de diagramas UML 2.5.

 Herramientas de modelado eficientes que incluyen reutilización de elementos,
transformación de diagramas, validación de sintaxis, y propiedades personalizadas.
 Lenguaje estándar, común a todo el equipo de desarrollo.
 Existen varias versiones compatibles con diferentes plataformas, usadas para necesidades
específicas del equipo de desarrollo.
 Permite la integración con Android Studio.

Dadas las características antes mencionadas se selecciona esta herramienta ya que el equipo de
desarrollo la conoce y tiene experiencia en su uso, permite la integración con UML y con el
entorno de desarrollo integrado Android Studio que emplean los desarrolladores.

1.4.2 Lenguajes de programación

En el desarrollo de aplicaciones móviles para la plataforma Android, se pueden utilizar diversos

lenguajes de programación. Cada uno tiene características que los hacen más adecuados según
los requisitos del proyecto. A continuación, se describen los lenguajes más utilizados en el desa-
rrollo móvil para Android, y se analiza la opción elegida para el proyecto. (Fowler, 2018).

Tabla 4: Comparación de lenguajes de programación

Adecuación para el
Lenguaje Ventajas Desventajas
Proyecto

- Language robusto y
Java - Sintaxis más extensa Java sigue siendo una
ampliamente utilizado.
y menos moderna que opción válida y confia-
Gran soporte de bi- Kotlin. - Menor conci- ble para el desarrollo
bliotecas y framewo- de aplicaciones An-

22
 Capítulo I

Adecuación para el
Lenguaje Ventajas Desventajas
Proyecto

droid, aunque puede

rks. - Estabilidad en el no ser la más eficiente
desarrollo de aplica- sión y legibilidad. frente a Kotlin en pro-
ciones Android. yectos nuevos. (Fow-
ler, 2018).

Kotlin es una excelen-

- Sintaxis más moder-
te opción para el de-
na y concisa. - Total - Requiere un aprendi-
sarrollo de Android,
interoperabilidad con zaje adicional para
Kotlin pero no es el lenguaje
Java. - Recomendado aquellos acostumbra-
elegido para este pro-
por Google para el dos a Java.
yecto. (Google Deve-
desarrollo Android.
lopers, 2017).

C y C++ pueden ser

- Mayor control sobre - Mayor complejidad útiles en aplicaciones
los recursos del dispo- en la gestión de me- que requieren un alto
sitivo. - Ideal para apli- moria. - Menos acce- rendimiento, pero no
C y C++
caciones de alto rendi- sibilidad y soporte di- son adecuados para
miento y recursos limi- recto para el desarro- el desarrollo general
tados. llo de apps Android. de aplicaciones An-
droid. (Fowler, 2018).

23
 Capítulo I

Adecuación para el
Lenguaje Ventajas Desventajas
Proyecto

Aunque viable, Visual

Basic no es recomen-
dado para el desarro-
- Sintaxis sencilla, - No es comúnmente
llo de aplicaciones
ideal para desarrolla- utilizado en el desa-
Android debido a su
Visual Basic dores principiantes. - rrollo de Android. -
poca presencia en
Compatible con el Limitado en compara-
este ámbito y la pre-
ecosistema de .NET. ción con Java o Kotlin.
valencia de otros len-
guajes más adecua-
dos. (Microsoft, 2023).

C# con Xamarin pue-

de ser adecuado para
- Permite la reutiliza- - Menos soporte y re- proyectos que tam-
ción de código entre cursos que Java o bién deben ejecutarse
plataformas con Xa- Kotlin para Android. - en otras plataformas,
.NET (C#)
marin. - Ideal para Requiere integración pero no es la opción
proyectos multiplata- adicional con platafor- más común ni eficien-
forma. mas como Xamarin. te para aplicaciones
Android nativas. (Fow-
ler, 2018).

Fuente: elaboración propia.

24
 Capítulo I

Elección del Lenguaje para el Proyecto

Para el desarrollo de la aplicación móvil, se ha decidido utilizar Kotlin, es un lenguaje de progra-

mación moderno, multiplataforma que puede ser utilizado para varios fines, por esta razón los
programadores lo utilizan para el desarrollo móvil en Android como en iOS; este también es cono-
cido por su diseño práctico y su concisa sintaxis, además que permite la reutilización de código y
compartir entre los desarrolladores el uso de múltiples proyectos(JetBrains, 2024).

Se elige este lenguaje de programación ya que es el lenguaje oficial para el desarrollo de

aplicaciones Android y viene integrado con el entorno de desarrollo Android Studio, posee una
sintaxis parecida a Java conocida por los desarrolladores. Este lenguaje de programación posee
una comunidad activa y recursos abundantes esto se traduce en documentación, tutoriales lo que
facilita su aprendizaje.

1.4.3 Herramienta para el diseño de prototipos de interfaz

Para el diseño de prototipos de interfaz se utiliza Microsoft PowerPoint, esta es una herramienta
desarrollada por Microsoft, que forma parte integral del paquete de productividad de Microsoft
Office. Utilizada globalmente en el ámbito académico, empresarial y personal, que permite crear
presentaciones visualmente dinámicas (Wang, 2018).
Se elige esta herramienta para el diseño de prototipos de interfaz ya que es ideal para
principiantes debido a su interfaz intuitiva y fácil de usar incluso para aquellos que no tienen
experiencia en diseño gráfico, ofrece una amplia gama de formas, iconos, imágenes y
herramientas de texto que se puedes utilizar para diseñar elementos de interfaz. PowerPoint es
compatible con múltiples plataformas, incluyendo Windows, macOS, y versiones móviles.

1.4.4 Entorno de desarrollo integrado

Un entorno de desarrollo integrado o entorno de desarrollo interactivo, en inglés Integrated Deve-

lopment Environment (IDE), es una aplicación informática que proporciona servicios integrales

25
 Capítulo I

para facilitarle al desarrollador o programador el desarrollo de software. Es un sistema de softwa-

re para el diseño de aplicaciones que combina herramientas del desarrollador comunes en una
sola interfaz gráfica de usuario (GUI). Los IDEs están diseñados para aumentar la productividad
del desarrollador al reducir la necesidad de cambiar entre diferentes aplicaciones. Además, inte-
gran herramientas fundamentales como compiladores, depuradores y editores de texto en una
interfaz unificada (Elmasri, 2021).

Generalmente, un IDE cuenta con las siguientes características:

1) Editor de código fuente: editor de texto que ayuda a escribir el código de software con funcio-
nes como el resaltado de la sintaxis con indicaciones visuales, el relleno automático específico
del lenguaje y la comprobación de errores a medida que se escribe el código.

2) Automatización de compilaciones locales: herramientas que automatizan tareas sencillas e

iterativas como parte de la creación de una compilación local del software para su uso por parte
del desarrollador, como la compilación del código fuente de la computadora en un código binario,
el empaquetado del código binario y la ejecución de pruebas automatizadas.

3) Depurador: programa que sirve para probar otros programas y mostrar la ubicación de un
error en el código original de forma gráfica (Microsoft, 2021).

Android Studio Jellyfish | 2024.3.2

Es el IDE proporcionado por Google para el desarrollo de aplicaciones para Android y se basa en
IntelliJ IDEA. Además del potente editor de códigos y las herramientas para desarrolladores de
IntelliJ, Android Studio ofrece funciones que aumentan la productividad durante la compilación de
aplicaciones para Android, como las siguientes(Android Developers, 2024b):

• Sistema de compilación flexible basado en Gradle.

26
 Capítulo I

• Un emulador rápido con varias funciones, que permite crear y probar aplicaciones en una
variedad de dispositivos virtuales con diferentes tamaños de pantalla, resoluciones y versiones de
Android, permitiendo ejecutar las aplicaciones para verificar su rendimiento y funcionamiento en
un entorno controlado.
• Un entorno unificado en el que puedes realizar desarrollos para todos los dispositivos Android.
• Instant Run, para aplicar cambios mientras tu aplicación móvil se ejecuta sin la necesidad de
compilar un nuevo paquete de aplicación Android (APK).
• Integración de plantillas de código y GitHub, para ayudarte a compilar funciones comunes de las
aplicaciones e importar ejemplos de código.
• Gran cantidad de herramientas y frameworks de prueba.
Por las características antes mencionadas se selecciona como entorno de desarrollo integrado a
Android Studio, ya que este es el entorno oficial para el desarrollo de aplicaciones Android, posee
una interfaz intuitiva que facilita a los desarrolladores la creación y gestión de proyectos, una de
sus grandes ventajas es que posee un emulador integrado que permite simular diferentes
dispositivos y configuraciones, lo que facilita las pruebas en tiempo real sin la necesidad de un
dispositivo físico. Su integración con otras herramientas permite a los desarrolladores gestionar
todos los aspectos del ciclo de vida de la aplicación desde una única plataforma lo que optimiza
la productividad.

Por todas estas características, se ha decidido utilizar Android Studio como el entorno de desa-
rrollo para la creación de la aplicación móvil.

1.4.5 Herramienta para el diseño de prototipos de interfaz.

Para el diseño de prototipos de interfaz se utiliza Microsoft PowerPoint, esta es una herramienta
desarrollada por Microsoft, que forma parte integral del paquete de productividad de Microsoft
Office. Utilizada globalmente en el ámbito académico, empresarial y personal, que permite crear
presentaciones visualmente dinámicas (Wang, 2018).

27
 Capítulo I

Se elige esta herramienta para el diseño de prototipos de interfaz ya que es ideal para
principiantes debido a su interfaz intuitiva y fácil de usar incluso para aquellos que no tienen
experiencia en diseño gráfico, ofrece una amplia gama de formas, iconos, imágenes y
herramientas de texto que se puedes utilizar para diseñar elementos de interfaz. PowerPoint es
compatible con múltiples plataformas, incluyendo Windows, macOS, y versiones móviles.

1.4.6 Gradle 8.14

Gradle 7.6 es una herramienta para automatizar la construcción de proyectos, tareas de

compilación, pruebas, empaquetado y el despliegue de los mismos(Gradle Inc., 2023). Utilizado
como compilador de disimiles lenguajes de programación como Java, Python, C/C++, etcétera.
Provee plugins y otras herramientas para la integración con IDEs como Eclipse, Android Studio e
IntelliJ, a su vez es un plugin, lo que facilita su actualización y su exportación de un proyecto a
otro. Gradle 7.6 permite reutilizar código fácilmente, hace sencilla la tarea de configurar y
personalizar la compilación, permite la distribución sencilla de código al resto del mundo y
gestiona las dependencias de forma potente y cómoda ya que está basado en Maven. Esta
herramienta emplea al java (Compilador de Java o Java Compiler) para programar mediante
“Scripting” el funcionamiento de la integración modular de la aplicación y permite compilar la
aplicación mientras es desarrollada(Gradle Inc., 2023).

1.4.7 Android SDK

El SDK (Software Development Kit, Kit de Desarrollo de Software), es un conjunto de
herramientas y programas de desarrollo que permite al programador crear aplicaciones para un
determinado paquete de software, estructura de software, plataforma de hardware, sistema de
computadora, consulta de videojuego, sistema operativo o similar(Alegsa, 2023). El SDK de
Android contiene las herramientas para desarrollar aplicaciones desde la línea de comandos, así
como otras herramientas que ayudaran a encontrar y diagnosticar problemas, y optimizar las
aplicaciones.

28
 Capítulo I

El SDK de Android incluye:

 Librerías necesarias.
 Entorno de depuración.
 Emulador de dispositivos móviles.
 Documentación relevante para las API de Android.
 Código fuente de ejemplo.
 Tutoriales para el sistema operativo Android.

1.4.8 Jetpack Compose

Jetpack Compose es un kit de herramientas moderno diseñado para simplificar el desarrollo de
IU. Combina un modelo de programación reactivo con la concisión y facilidad de uso del lenguaje
de programación Kotlin. Es totalmente declarativo, lo que significa que describes tu IU si llamas a
una serie de funciones que transforman datos en una jerarquía de IU. Cuando los datos
subyacentes cambian, el framework vuelve a ejecutar estas funciones automáticamente y
actualiza la jerarquía de la IU por ti(Android Developers, 2024a).
Se utiliza esta herramienta para el desarrollo de las interfaces de usuario ya que reduce el código
necesario para crear las interfaces, se puede hacer en Kotlin simplificando el desarrollo, en lugar
de usar archivos XML separados para definir las vistas lo que disminuye la posibilidad de errores,
permitiendo a los desarrolladores alcanzar el mismo resultado con menos líneas de código.

Conclusiones del capítulo

En este capítulo, la realización del estudio de los sistemas homólogos permitió determinar las
principales características y funcionalidades de las soluciones que brindan información de
entidades que ofrecen a nivel tanto nacional como internacional. Además, la descripción de los
principales conceptos posibilitó adquirir una mayor comprensión de los temas relacionados con el
objeto de estudio. Por otra parte, el análisis de diferentes herramientas y tecnologías permitió
alcanzar los conocimientos necesarios para seleccionar las adecuadas para el desarrollo de la

29
 Capítulo I

solución. Por lo que, se decide utilizar como entorno de desarrollo integrado Android Studio, XP
como metodología a utilizar para guiar el desarrollo de la aplicación Android, y como lenguaje de
programación Kotlin para la implementación de la propuesta de solución.

30
 Capítulo II

CAPÍTULO II: DISEÑO DE LA SOLUCIÓN PROPUESTA AL PROBLEMA CIENTÍFICO

ANÁLISIS Y DISEÑO DE LA APLICACIÓN ANDROID PARA EL PORTAL INSTITUCIONAL DE
EL PARQUE CIENTÍFICO TECNOLÓGICO DE LA HABANA (3CE).

En el presente capítulo se describen las principales características de la propuesta de solución.

Se presenta el modelo de dominio que contiene los conceptos del negocio y sus relaciones. Se
realiza la identificación de los requisitos tanto funcionales como no funcionales, para definir de
manera precisa las expectativas y necesidades del cliente, en este sentido se utilizan las historias
de usuario como herramienta fundamental para la descripción de requisitos y definir
funcionalidades claves del sistema. Se especifica la arquitectura de la aplicación y los patrones
de diseño reconocidos para abordar problemas frecuentes.

II.2 Descripción del negocio

Para un mayor entendimiento del problema, es necesario primero aclarar las terminologías aso-
ciadas al negocio, con el objetivo de establecer un marco conceptual que permita la creación de
la aplicación. Esta descripción aborda los actores involucrados en el negocio, el modelo de nego-
cio, y el modelo conceptual o de dominio que guiarán la posterior confección de la aplicación.

31
 Capítulo II

Modelo de negocio

El modelo de negocio de la aplicación está centrado en proporcionar una solución tecnológica

que facilite la gestión, seguimiento y optimización de los recursos y proyectos dentro del Parque
Científico Tecnológico de la Habana (PCT). El PCT es un espacio destinado a fomentar la inno-
vación, el desarrollo tecnológico y la colaboración entre empresas, instituciones académicas y
gubernamentales. A través de la aplicación, se pretende ofrecer a los actores del PCT una plata-
forma que centralice la gestión de proyectos, el acceso a recursos y la colaboración en tiempo
real (Cuban Tech, 2024). El modelo de negocio está basado en un servicio B2B (Business to Bu-
siness), ya que los principales usuarios de la aplicación serán empresas e instituciones asociadas
al parque (González, 2023).

La aplicación estará diseñada para facilitar la gestión de proyectos, optimizar la colaboración en-
tre las partes interesadas y ofrecer herramientas que permitan el seguimiento en tiempo real de
las iniciativas dentro del parque (González, 2023). Además, se proporcionará acceso a servicios
clave como la gestión de datos, el acceso a recursos compartidos y la interacción con otras enti-
dades dentro del ecosistema del PCT (Cuban Tech, 2024).

Actores del negocio

Los actores del negocio en este contexto son los diferentes grupos o individuos que interactúan
con la plataforma, tanto de manera directa como indirecta. Los principales actores incluyen:

1. Administradores del PCT: Son responsables de gestionar la plataforma, administrar las

cuentas de los usuarios, asegurar el acceso a los recursos y monitorear el desarrollo de
proyectos dentro del parque. Los administradores también gestionan la configuración ge-
neral de la aplicación (González, 2023).
2. Empresas e Instituciones participantes: Son las entidades que forman parte del PCT, las
cuales utilizarán la aplicación para gestionar proyectos, acceder a recursos y colaborar con

32
 Capítulo II

otras instituciones. Estas empresas pueden ser startups, universidades, o centros de in-
vestigación (Cuban Tech, 2024).
3. Investigadores y Desarrolladores: Son los usuarios dentro de las empresas e instituciones
que utilizan la plataforma para gestionar proyectos de investigación, compartir conocimien-
tos y colaborar con otros actores dentro del PCT (González, 2023).
4. Usuarios Administrativos: Son aquellos responsables de la administración de recursos es-
pecíficos dentro de los proyectos, como la gestión de fondos, equipos o espacios físicos
dentro del PCT (Cuban Tech, 2024).

Modelo conceptual o de dominio

El modelo conceptual o modelo de dominio se refiere a la representación abstracta de los ele-
mentos clave y las relaciones dentro del sistema, que sirve como base para la creación de la apli-
cación. En este caso, los componentes principales del modelo conceptual incluyen:

1. Proyecto: Representa una iniciativa de investigación o desarrollo dentro del PCT, que invo-
lucra una serie de actividades, recursos y actores (Cuban Tech, 2024).
2. Recurso: Hace referencia a cualquier tipo de recurso que pueda ser utilizado en los pro-
yectos, como equipos, espacios físicos, personal o financiación (González, 2023).
3. Colaboración: Relaciona a los actores que trabajan conjuntamente en proyectos o compar-
ten recursos entre sí dentro del PCT (Cuban Tech, 2024).
4. Tarea: Representa las acciones específicas que deben llevarse a cabo dentro de un pro-
yecto o actividad de colaboración (González, 2023).Este modelo conceptual facilitará la
organización de la información y las funcionalidades que deben ser implementadas en la
aplicación. Además, servirá para garantizar la integridad de los datos y la correcta interre-
lación de los distintos elementos dentro del sistema (Cuban Tech, 2024).

33
 Capítulo II

Figura 2: Modelo de Dominio (elaboración propia).

II.2 Planificación

La planificación constituye la primera fase del ciclo de vida de la metodología Extreme Program-
ming (XP). En esta etapa, los usuarios definen, a grandes rasgos, las funcionalidades y los requi-
sitos que desean obtener de la aplicación. El equipo de desarrollo se familiariza con las tecnolo-
gías y herramientas seleccionadas para llevar a cabo el proyecto. Además, se realiza un análisis
de los conceptos fundamentales asociados al proceso, tal y como se plantea en Fuentes (2015).

1. Definición de Requisitos y Funcionalidades

Los usuarios, en colaboración con los stakeholders, identifican y priorizan las necesidades funda-
mentales de la aplicación. Se utiliza la técnica de historias de usuario para plasmar de manera
sencilla y directa las expectativas y objetivos, permitiendo que cada funcionalidad se relacione
con una necesidad concreta del Parque Científico Tecnológico de la Habana (PCT). Este enfoque
asegura que las funcionalidades a desarrollar están alineadas con los objetivos del modelo de
negocio, que busca optimizar la gestión de recursos y la colaboración entre las distintas entida-
des del PCT (González, 2023; Cuban Tech, 2024).

34
 Capítulo II

2. Familiarización con Tecnologías y Herramientas

Paralelamente a la definición de requisitos, el equipo de desarrollo se encamina a familiarizarse
con las tecnologías y herramientas seleccionadas para el proyecto. Esto incluye el dominio de las
plataformas de desarrollo Android, el uso de librerías y frameworks que permitan la implementa-
ción de una arquitectura offline-first (por ejemplo, Room para el manejo de bases de datos locales
y WorkManager para la sincronización en segundo plano), así como herramientas de gestión de
versiones y de integración continua. Este proceso de capacitación y adaptación es fundamental
para garantizar que el equipo esté preparado para afrontar las iteraciones de desarrollo de mane-
ra eficiente y de acuerdo a las exigencias del entorno tecnológico actual.

3. Análisis de Conceptos Fundamentales

Siguiendo lo planteado en Fuentes (2015), se realiza un análisis detallado de los conceptos
esenciales de XP, tales como:
-Comunicación frecuente: La importancia de mantener un canal abierto y continuo entre los
usuarios y el equipo de desarrollo, lo que facilita la rápida identificación de desviaciones y la in-
corporación de cambios.
- Simplicidad en el diseño: En lugar de sobrecargar el diseño inicial, se opta por soluciones sim-
ples que respondan a lo solicitado, permitiendo su mejora y adaptación en las iteraciones poste-
riores.
- Retroalimentación temprana: Las iteraciones cortas y continuas permiten evaluar el producto
en desarrollo y realizar ajustes basados en la retroalimentación, lo que mejora el alineamiento
con las expectativas del cliente.
Estos principios son esenciales para construir una aplicación que no solo cumpla con las funcio-
nalidades básicas, sino que lo haga de forma flexible y adaptativa ante cambios futuros.

4. Planificación de Iteraciones y Releases

35
 Capítulo II

Con los requerimientos iniciales y el análisis tecnológico completo, se procede a organizar el tra-
bajo en iteraciones cortas y altamente colaborativas. Se define un ¨release plan¨ en el que se es-
tablecen los objetivos de cada iteración, priorizando aquellas funcionalidades críticas para el co-
rrecto funcionamiento de la aplicación. Cada iteración contempla:
- La implementación de nuevas historias de usuario
- Pruebas unitarias y de integración que aseguren la calidad del software.
- Reuniones de retroalimentación y revisión, que permitan adaptar el producto según las necesi-
dades emergentes.
Este enfoque iterativo permite que el desarrollo se mantenga en constante evolución y ajuste,
asegurando una solución final alineada a los objetivos del PCT.

5. Conclusión de la Fase de Planificación

La planificación en XP sienta las bases para un desarrollo ágil, en el que la comunicación, la sim-
plicidad y la adaptación continua son fundamentales. Este proceso inicial no solo define el alcan-
ce y la arquitectura potencial de la aplicación, sino que también establece un marco de colabora-
ción y aprendizaje continuo entre los usuarios y el equipo de desarrollo. Así, se garantizan las
condiciones para desarrollar una solución tecnológica robusta y flexible, capaz de gestionar y di-
fundir la información de manera eficiente en el Parque Científico Tecnológico de La Habana.

II.2.1 Propuesta de Solución

Se propone el desarrollo de una aplicación móvil para el Parque Científico Tecnológico de La Ha-
bana (3CE) que brinde a los usuarios una interfaz intuitiva y accesible desde sus smartphones sin
la necesidad de una conexión a internet constante. Esta aplicación debe ser diseñada bajo el en-
foque mobile-first, lo que prioriza una navegación fluida y una presentación de contenidos adapta-
da a las pantallas pequeñas.

36
 Capítulo II

II. 3 Requisitos del Sistema

El Product Backlog es una lista organizada de requisitos que se mantiene para un producto.
Estos elementos están ordenados por el Propietario del producto, quien también decide las
prioridades de las historias de usuario y es quien puede reordenar la lista durante o al final del
sprint(Mahalakshmi & Sundararajan, 2013). Los requerimientos para un sistema son
descripciones de lo que el sistema debe hacer: el servicio que ofrece y las restricciones en su
operación. Tales requerimientos reflejan las necesidades de los clientes por un sistema que
atienda cierto propósito, como sería controlar un dispositivo, colocar un pedido o buscar
información (Sommerville, 2005). Suelen clasificarse en requisitos funcionales y requisitos no
funcionales.

II. 3.1 Requisitos funcionales

Los requisitos funcionales, tal y como especifica Ramos (2017), son aquellos que están directa-
mente relacionados con las funciones o las respuestas que el sistema debe proporcionar. Estos
requisitos incluyen restricciones impuestas al funcionamiento del sistema, como limitaciones de
tiempo, presupuesto, proceso de desarrollo, políticas de la organización, entre otros.

Para desarrollar la aplicación para el Parque Científico Tecnológico de La Habana (3CE), es es-
encial definir una serie de requisitos funcionales que aseguren que la plataforma cumpla adecua-
damente con las necesidades de los usuarios. Entre estos, se destacan las funcionalidades que
permitirán a los usuarios acceder rápidamente a la información sobre servicios, proyectos e inte-
racciones dentro del parque, así como la capacidad de consultar eventos y participar activamente
en la comunidad tecnológica de 3CE.

Después del encuentro inicial con el cliente y un análisis exhaustivo de los requerimientos, se
identificaron un total de 10 requisitos funcionales, los cuales fueron evaluados y clasificados se-
gún la prioridad que el cliente asignó a cada uno, en función de sus necesidades y expectativas.
Para complementar este proceso, se realizó un estudio comparativo con aplicaciones similares

37
 Capítulo II

en el ámbito de parques científicos y tecnológicos, lo que permitió validar la viabilidad y alinea-

ción de los requisitos con las mejores prácticas del sector. La tabla siguiente muestra los requisi-
tos funcionales, con su respectiva prioridad y análisis de complejidad:

Tabla 5: Requisitos Funcionales para la Aplicación Móvil del Parque Científico Tecnológico de La
Habana (elaboración propia).

No Nombre Descripción Prioridad Complejidad

RF.1 Mostar información El sistema debe mostrar una Alta Media
básica del parque sección que explique la misión,
visión, objetivos y funciones
principales del Parque Científico
Tecnológico de La Habana
RF.2 Listar servicios dispo- El sistema debe mostrar una alta media
nibles lista de los servicios ofrecidos
RF.3 Mostrar servicios dis- El sistema debe mostrar los Alta Alta
ponibles servicios disponibles que ofrece
la institución
RF.4 Listar proyectos incu- El sistema debe mostrar un lis- alta media
bados tado con los proyectos encuba-
dos
RF.5 Mostrar proyectos El sistema debe presentar infor- Media Media
incubados mación sobre los proyectos de
innovación tecnológica incuba-
dos en el parque.
RF.6 Mostrar casos de El sistema debe mostrar una Media Baja
éxcito pantalla de testimonios y ejem-
plos de proyectos que han teni-

38
 Capítulo II

No Nombre Descripción Prioridad Complejidad

do éxito dentro del parque, mos-
trando el impacto positivo de su
incubación.
RF.7 Listar casos de éxcito El sistema debe listar los casos media media
de éxcito de proyectos realiza-
dos por el parque
RF.8 Listar convocatorias El sistema debe mostrar una alta media
lista con las convocatorias acti-
vas
RF.9 Mostrar convocato- El sistema debe mostrar infor- Alta Media
rias activas mación actualizada sobre con-
vocatorias, concursos y oportu-
nidades de financiamiento dis-
ponibles para proyectos de in-
novación.
RF.10 Listar incentivos El sistema debe mostrar una Media media
lista con los incentivos ofrecidos
por el parque.
RF.11 Mostar incentivos El sistema debe mostrar los de- Media media
talles de los incentivos
RF.12 Listar beneficios El sistema debe mostrar los de- media media
talles los de beneficios que ofre-
ce el parque .
RF.13 Mostrar beneficios El sistema debe mostrar benefi- media Media
cios que ofrece el parque a las
empresas y emprendedores

39
 Capítulo II

No Nombre Descripción Prioridad Complejidad

RF.14 Mostrar noticias y El sistema debe mostrar una Media Baja
eventos sección de noticias y eventos
relacionados con el parque, in-
cluyendo actividades, conferen-
cias y talleres
RF.15 Mostrar preguntas El sistema debe mostrar deta- Media Baja
frecuentes lles sobre la sección con res-
puestas a preguntas frecuentes
sobre el parque.
RF.16 Listar preguntas fre- El sistema debe mostrar una Media Baja
cuentes lista con las preguntas mas rea-
lizadas sobre el parque.
RF.17 Listar testimonios de El sistema debe mostrar una Alta media
usuários lista con los testimonios de per-
sonalidades que trabajaron con
el parque.
RF.18 Mostrar testimonios el sistema debe ofrecer una Baja Baja
de usuarios sección con testimonios de
usuarios que han interactuado
con el parque, compartiendo
sus experiencias y recomenda-
ciones.
Fuente: elaboración propia.

II.3.2 Requisitos no Funcionales

40
 Capítulo II

Los requisitos no funcionales son aquellos que no se refieren directamente a funciones

específicas del sistema, sino que engloban otras características y/o restricciones. Abarcan mucho
más que al sistema de software a desarrollar, incluyen desde la política del cliente y el
desarrollador hasta factores externos al proceso de desarrollo (Sommerville, 2005). Para alcanzar
la satisfacción del cliente y una buena calidad del funcionamiento del sistema se definen los
siguientes requisitos no funcionales según lo establecido por las normas ISO 25000 Calidad del
Producto de Software, específicamente la ISO/IEC 25010, la cual define las características de
calidad que se tienen en cuenta al evaluar las propiedades de un producto de software.

RnF1. Requerimientos de software

 Sistema operativo Android con versión 9.0 o superior.

RnF2. Requerimientos de hardware

 Memoria RAM del dispositivo con capacidad mínima de 256 MB.
 Almacenamiento interno con capacidad mínima de 180 MB.

RnF3. Usabilidad
 Interfaz de usuario intuitiva y fácil de usar, los usuarios no deben necesitar más de
3 a 4 clics para acceder a cualquier contenido o funcionalidad clave de la aplicación.

RnF4. Diseño y apariencia

 El color predominante de la aplicación debe ser azul.
 La aplicación Android tiene un diseño responsive, lo cual se aplica para que se
adapte al tamaño y orientación de la pantalla y así se pueda usar en cualquier
dispositivo móvil.
 Incluir información de contacto, como direcciones, números de teléfono, correos
electrónicos y formularios de contacto, así como la ubicación del parque en un
mapa interactivo

41
 Capítulo II

RnF5. Rendimiento y Eficiencia

 Tiempo de Respuesta: La aplicación debe cargar cualquier contenido o funcionali-
dad clave en un tiempo máximo de 2 a 3 segundos, incluso en condiciones de red
fluctuantes.
 Optimización de Recursos: La aplicación debe optimizar el uso de la batería y mini-
mizar el consumo de datos durante las actualizaciones y sincronizaciones.

RnF6. Seguridad
 Comunicación Segura: Toda la información debe transmitirse utilizando protocolos
seguros, por ejemplo, HTTPS, para proteger los datos del usuario.
 Almacenamiento Seguro: Los datos sensibles que se almacenen localmente (por
ejemplo, en el modo offline-first) deben cifrarse de forma que se protejan en caso de
extravío o acceso no autorizado.
 Gestión de Errores: La aplicación debe manejar de forma segura cualquier error o
fallo, evitando la exposición de información sensible y mostrando mensajes claros al
usuario.

RnF7. Confiabilidad y Disponibilidad

 Tolerancia a Fallos: La aplicación debe estar preparada para operar en modo offline
sin comprometer la experiencia del usuario. En caso de error de sincronización, se
debe notificar al usuario y reintentar la actualización automáticamente en segundo
plano.
 Capacidad de Recuperación: Ante caídas o errores críticos, la aplicación debe po-
der recuperarse sin pérdida de datos y con el menor tiempo de inactividad posible.

RnF8. Mantenibilidad y Escalabilidad

42
 Capítulo II

 Modularidad del Código: El sistema debe diseñarse con una arquitectura modular
que permita incorporar y actualizar funcionalidades sin afectar el funcionamiento
global de la aplicación.
 Documentación y Estándares: El desarrollo debe seguir estándares de codificación
y contar con documentación técnica exhaustiva para facilitar actualizaciones futuras.
 Escalabilidad: La aplicación debe prepararse para soportar la incorporación de nue-
vas funcionalidades y mayor cantidad de usuarios sin degradar el rendimiento.

RnF9. Portabilidad y Compatibilidad

 Adaptabilidad a Dispositivos: Aunque ya se indica que la aplicación debe ser res-
ponsive, se debe validar que funcione correctamente en una amplia gama de dispo-
sitivos Android, considerando diferentes tamaños de pantalla y capacidades.
 Interoperabilidad: La aplicación debe integrarse eficazmente con otros servicios o
sistemas, en caso de requerir intercambio de datos con el portal web o con otros
sistemas institucionales.

RnF10. Accesibilidad
 Interfaz Inclusiva: Asegurarse de que la interfaz cumpla con pautas de accesibilidad,
como contraste de colores adecuado, posibilidad de ajustar el tamaño de la fuente y
soporte para lectores de pantalla para usuarios con discapacidades.
 Navegación Simplificada: Además de la usabilidad (3 a 4 clics para acceder a fun-
ciones clave), se debe garantizar que la estructura y navegación de la aplicación
sean intuitivas para todo tipo de usuarios, incluidos aquellos con poca experiencia
digital.

43
 Capítulo II

II. 4 Historias de Usuario (HU)

Las historias de usuario se usan, en el contexto de la ingeniería de requisitos ágil, como una
herramienta de comunicación que combina las fortalezas de ambos medios: escrito y verbal.
Describen, en una o dos frases, una funcionalidad de software desde el punto de vista del
usuario, con el lenguaje que éste emplearía. El foco está puesto en qué necesidades o
problemas soluciona lo que se va a construir (Menzinsky et al., 2022). Esta herramienta agiliza la
administración de requisitos reduciendo la cantidad de documentos formales, las mismas son
escritas en un lenguaje común fácil de entender para el usuario.
En la metodología XP, las historias de usuario se definen como breves descripciones que
capturan los requerimientos del sistema desde la perspectiva del usuario final, comúnmente
expresadas en el formato “Como [rol], quiero [acción] para [beneficio]” (Atlassian, s.f.). Este estilo
de redacción se orienta a que el desarrollador comprenda y priorice la funcionalidad en términos
de valor para el usuario.
Según el Departamento Nacional de Planeación (s.f.), la elaboración de una historia de usuario
debe incluir elementos esenciales como un título descriptivo, una narrativa concisa, criterios de
aceptación y la asignación de una prioridad. Estos componentes facilitan la interacción y
comunicación entre los equipos de desarrollo y los stakeholders, orientando la planificación y
ejecución del proyecto de manera iterativa.
Además, en el enfoque XP se añaden atributos específicos a las historias de usuario, tales como
la estimación del esfuerzo, la prioridad técnica y la vinculación con otras historias o épicas, lo que
permite gestionar el proyecto de forma dinámica y adaptativa (Historia de Usuario en XP, s.f.).
Esta práctica colaborativa y flexible es clave para responder de manera ágil a los cambios en los
requerimientos y garantizar la entrega continua de valor.
En síntesis, las historias de usuario en XP no solo sirven para transmitir de manera sencilla las
necesidades del cliente, sino que también constituyen una herramienta de planificación y
coordinación que orienta la distribución del trabajo durante las iteraciones, asegurando una
adecuada evolución del proyecto y una mayor satisfacción del usuario.

44
 Capítulo II

Este enfoque permite obtener una visión clara de los requisitos, asegurando que el desarrollo
esté alineado con las necesidades del usuario final y no únicamente con las funcionalidades
técnicas. A continuación, se presentan las historias de usuario para los requisitos funcionales
identificados en el sistema de la aplicación móvil 3CE.
Tabla 6: Historia de Usuario no.1 para la App Móvil 3CE

Historia de Usuario

Número: HU_1 Nombre: Mostrar información básica del parque

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 6 horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como usuario, quiero acceder a una sección que explique la misión, visión y ob-
jetivos del parque para entender su propósito

Observaciones: Presenta los elementos institucionales clave del 3CE.

Prototipo de interfaz

45
 Capítulo II

Fuente: elaboración propia.

Tabla 7: Historia de Usuario no.2 para la App Móvil 3CE

Historia de Usuario

Número: HU_2 Nombre: Listar servicios disponibles

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 8 horas

46
 Capítulo II

Complejidad: Media Tiempo real: 6 horas

Descripción: Como emprendedor, quiero consultar una lista de servicios para saber qué op-
ciones tengo en el parque.

Observaciones: Se muestra una lista de coworking, asesoría, infraestructura.

Prototipo de interfaz

47
 Capítulo II

Fuente: elaboración propia.

Tabla 8: Historia de Usuario no.3 para la App Móvil 3CE

Historia de Usuario

Número: HU_3 Nombre:Mostrar servicios disponibles

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 8 horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como usuario, quiero acceder al detalle de cada servicio con descripción, hora-
rios y contacto.

Observaciones: Se muestra los detalles de los servicios que ofrece el parque.

Prototipo de interfaz

48
 Capítulo II

Fuente: elaboración propia.

Tabla 9: Historia de Usuario no.4 para la App Móvil 3CE

Historia de Usuario

Número: HU_4 Nombre:Listar proyectos incubados

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 8 horas

49
 Capítulo II

Complejidad: Media Tiempo real: 6 horas

Descripción: Como visitante, quiero ver los nombres y sectores de los proyectos incubados
para conocer el ecosistema innovador.

Observaciones: Se muestra listado con filtros por categoría.

Prototipo de interfaz

Fuente: elaboración propia.

Tabla 10: Historia de Usuario no.5 para la App Móvil 3C

Historia de Usuario

50
 Capítulo II

Número: HU_5 Nombre: Mostrar proyectos incubados

Programador: Liannis Cabrera Iteración asignada: 2

Prioridad: Alta Tiempo estimado: 8 horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como usuario, quiero ver los proyectos de innovación incubados para conocer
su alcance.

Observaciones: Se muestra la información organizada en tarjetas con nombre del proyecto,

resumen y logros.

Prototipo de interfaz

51
 Capítulo II

Fuente: elaboración propia.

Tabla 11: Historia de Usuario [Link] la App Móvil 3CE

Historia de Usuario

Número: HU_6 Nombre: Mostrar casos de éxcito

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: media Tiempo estimado: 6 horas

Complejidad: baja Tiempo real: 4 horas

52
 Capítulo II

Descripción: Como usuario, quiero ver ejemplos de proyectos exitosos para entender el im-
pacto del parque.

Observaciones: Se muestra información detallada de los casos de excito

Prototipo de interfaz

Fuente: elaboración propia.

Tabla 12: Historia de Usuario no.7 para la App Móvil 3CE

Historia de Usuario

53
 Capítulo II

Número: HU_7 Nombre: Listar casos de éxito

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: media Tiempo estimado: 6 horas

Complejidad: media Tiempo real: 4 horas

Descripción: Como visitante, quiero ver un listado claro de los casos exitosos agrupa-
dos por año.

Observaciones: Se muestra una lista de los casos de excito

Prototipo de interfaz

54
 Capítulo II

Fuente: elaboración propia.

Tabla 13: Historia de Usuario no.8 para la App Móvil 3C

Historia de Usuario

Número: HU_8 Nombre: listar convocatorias activas

Programador: Liannis Cabrera Iteración asignada: 1

55
 Capítulo II

Prioridad: Alta Tiempo estimado: 8 horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como emprendedor, quiero ver todas las convocatorias activas organizadas cro-
nológicamente.

Observaciones: Se muestra una lista con las convocatorias. Incluir filtros por fecha, categoría
o estado.

Prototipo de interfaz

56
 Capítulo II

Fuente: elaboración propia.

Tabla 14: Historia de Usuario no.9para la App Móvil 3C

Historia de Usuario

Número: HU_9 Nombre: Mostrar convocatorias activas

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 8 horas

57
 Capítulo II

Complejidad: Media Tiempo real: 6 horas

Descripción: Como emprendedor, quiero ver las convocatorias activas para saber cómo parti-
cipar en oportunidades de innovación.

Observaciones: Se muestra la información sobre las convocatorias. Incluir filtros por fecha,
categoría o estado.

Prototipo de interfaz

58
 Capítulo II

Fuente: elaboración propia.

Tabla 15: Historia de Usuario no.10 para la App Móvil 3CE

Historia de Usuario

Número: HU_10 Nombre: Listar incentivos

Programador: Liannis Cabrera Iteración asignada: 1

59
 Capítulo II

Prioridad: media Tiempo estimado: 7horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como empresa, quiero ver qué incentivos existen para valorar mi participación
en el parque.

Observaciones: Se muestra una lista con los incentivos que ofrece el parque .

Prototipo de interfaz

60
 Capítulo II

Fuente: elaboración propia.

Tabla 16: Historia de Usuario no.11para la App Móvil 3CE

Historia de Usuario

Número: HU_11 Nombre: Mostrar incentivos

Programador: Liannis Cabrera Iteración asignada: 1

Prioridad: media Tiempo estimado: 8 horas

Complejidad: Media Tiempo real: 6 horas

Descripción: Como empresa, quiero conocer los incentivos ofrecidos por el parque para eva-
luar la conveniencia de integrarme.

Observaciones: Se muestra ejemplos detalles de los incentivos que ofrece el parque.

Prototipo de interfaz

61
 Capítulo II

Fuente: elaboración propia.

Tabla 17: Historia de Usuario no.12 para la App Móvil 3CE

Historia de Usuario

Número: HU_12 Nombre: listar beneficios.

Programador: Liannis Cabrera Iteración asignada: 3

Prioridad: media Tiempo estimado: 4horas

62
 Capítulo II

Complejidad: Media Tiempo real: 3horas

Descripción: Como visitante, quiero conocer qué beneficios ofrece el parque a incubados y
residentes.

Observaciones: mostrar lista de beneficios .

Prototipo de interfaz

Fuente: elaboración propia.

63
 Capítulo II

Tabla 18: Historia de Usuario no.13para la App Móvil 3CE

Historia de Usuario

Número: HU_13 Nombre: Mostrar beneficios

Programador: Liannis Cabrera Iteración asignada: 3

Prioridad: media Tiempo estimado: 4horas

Complejidad: Media Tiempo real: 3horas

Descripción: Como interesado, quiero ver los detalles específicos de cada beneficios.

Observaciones: mostrar detalles específicos de cada beneficios

Prototipo de interfaz

64
 Capítulo II

Fuente: elaboración propia.

Tabla 19: Historia de Usuario no.14para la App Móvil 3CE

Historia de Usuario

Número: HU_14 Nombre: Mostrar noticias y eventos.

Programador: Liannis Cabrera Iteración asignada: 3

Prioridad: media Tiempo estimado: 4horas

65
 Capítulo II

Complejidad: Media Tiempo real: 3horas

Descripción: Como visitante, quiero consultar noticias y eventos del parque para estar infor-
mado

Observaciones: Permitir acceso offline y orden cronológico.

Prototipo de interfaz

Fuente: elaboración propia.

66
 Capítulo II

Tabla 20: Historia de Usuario no.15 para la App Móvil 3CE

Historia de Usuario

Número: HU_15 Nombre: Mostrar preguntas frecuentes (FAQ)

Programador: Liannis Cabrera Iteración asignada: 3

Prioridad: media Tiempo estimado: 4horas

Complejidad: Media Tiempo real: 3 horas

Descripción:Como usuario, quiero ver respuestas a preguntas frecuentes para entender pro-
cesos y servicios sin asistencia externa.

Observaciones: Posibilidad de búsqueda y categorización.

Prototipo de interfaz

67
 Capítulo II

Fuente: elaboración propia.

Tabla 21: Historia de Usuario no.16 para la App Móvil 3CE

Historia de Usuario

Número: HU_16 Nombre: Listar preguntas frecuentes

Programador: liannis cabrera Iteración asignada: 1

68
 Capítulo II

Prioridad: Alta Tiempo estimado: 5 horas

Complejidad: Media Tiempo real: 3 horas

Descripción: Como visitante, quiero ver agrupadas las preguntas más comunes por tema.

Observaciones: Se muestra una lista con las preguntas frecuentes.

Prototipo de interfaz

Fuente: elaboración propia.

69
 Capítulo II

Tabla 22: Historia de Usuario no.17 para la App Móvil 3CE

Historia de Usuario

Número: HU_17 Nombre: Listar testimonios de usuários

Programador: liannis cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 5 horas

Complejidad: Media Tiempo real: 3 horas

Descripción: Como nuevo usuario, quiero ver opiniones anteriores para tener referencias del par-
que.

Observaciones: Se muestra una lista con opiniones anteriores de clientes.

Prototipo de interfaz

70
 Capítulo II

Fuente: elaboración propia.

Tabla 23: Historia de Usuario no.18 para la App Móvil 3CE

Historia de Usuario

Número: HU_18 Nombre: Mostrar testimonios de usuários

Programador: liannis cabrera Iteración asignada: 1

Prioridad: Alta Tiempo estimado: 5 horas

71
 Capítulo II

Complejidad: Media Tiempo real: 3 horas

Descripción: Como usuario curioso, quiero leer comentarios detallados y experiencias completas
de otros.

Observaciones: Se muestra detalles de las opiniones anteriores de clientes.

Prototipo de interfaz

Fuente: elaboración propia.

72
 Capítulo II

II.5 Tarjeta CRC

En Programación Extrema (XP), las Tarjetas CRC (Class Responsibility Collaborator) son una
herramienta esencial en la etapa de diseño orientado a objetos. Estas tarjetas se utilizan para
representar de manera sencilla las clases de un sistema, evidenciando en cada una de ellas tres
aspectos fundamentales: el nombre de la clase, sus responsabilidades (es decir, lo que debe
hacer) y sus colaboradores (las otras clases con las que interactúa para cumplir dichas
responsabilidades) (Lean Mind, 2022).
La técnica de utilizar tarjetas CRC se basa en la simplicidad y la comunicación efectiva dentro del
equipo de desarrollo. Al disponer de una representación física o visual de cada clase, los
miembros del equipo pueden debatir y ajustar el diseño colaborativamente durante las fases
iniciales del proyecto. Este proceso estimula la discusión sobre las interacciones entre objetos y
permite identificar, de forma temprana, posibles solapamientos o lagunas en la asignación de
responsabilidades ([Link], s.f.).
Entre los beneficios que aportan las tarjetas CRC se encuentra la claridad en la definición de
roles, lo que favorece la toma de decisiones en el diseño del sistema. Además, al fomentar un
enfoque colaborativo, se garantiza que la responsabilidad por el diseño sea compartida por todo
el equipo, alineando a los desarrolladores en torno a una visión común y simplificada de la
arquitectura. Esta herramienta, por tanto, no solo ayuda a estructurar el sistema de forma
intuitiva, sino que también fortalece la comunicación, elemento clave en las prácticas ágiles de
XP (Lean Mind, 2022).
En definitiva, las tarjetas CRC son una técnica que facilita el modelado y análisis de clases en
entornos XP. Su implementación contribuye a definir correctamente las responsabilidades y
colaboraciones de cada componente del sistema, permitiendo un diseño modular, claro y
adaptable a los cambios inherentes a los proyectos ágiles.
Tabla 16: Tarjeta CRC – Información Institucional
Tarjeta CRC Clase Responsabilidades Colaboradores
Información InformaciónInstitucional Mostrar la misión, vi- UI, Sistema de Ges-

73
 Capítulo II

Institucional sión, historia y valores tión de Contenidos

del parque. (CMS)
Incluir datos sobre la
identidad institucional
de 3CE.

Fuente: elaboración propia.

Tabla 17: Tarjeta CRC – Servicios ofrecidos
Tarjeta CRC Clase Responsabilidades Colaboradores
Servicios Ofrecidos Servicios-ofrecidos Listar y detallar los UI, Información
servicios que brinda el Institucional
parque (como cowo-
rking, asesoramiento e
infraestructura).
- Presentar imágenes
y descripciones rele-
vantes en un formato
adaptable a distintos
dispositivos.

Fuente: elaboración propia.

Tabla 18: Tarjeta CRC – Proyectos incubados

Tarjeta CRC Clase Responsabilidades Colaboradores
Proyectos Incubados Proyectos Incubados Mostrar información UI, Base de Datos
sobre los proyectos de
innovación tecnológica

74
 Capítulo II

incubados en el par-
que.
- Destacar objetivos,
logros y potencial de
colaboración o inver-
sión.

Fuente: elaboración propia.

Tabla 19: Tarjeta CRC –Casos de Éxito

Tarjeta CRC Clase Responsabilidades Colaboradores
Casos de Éxito CasosExito -Presentar ejemplos y UI, Proyectos
casos de éxito Incubados
destacados dentro del
parque.
- Mostrar evidencias
(textuales y
multimedia) que
demuestren el impacto
y la efectividad de la
incubación.
Fuente: elaboración propia.

Tabla 20: Tarjeta CRC – Convocatorias

Tarjeta CRC Clase Responsabilidades Colaboradores
Convocatorias Convocatorias - Listar convocatorias UI, Sistema de Ges-
y oportunidades de tión de Contenidos

75
 Capítulo II

financiamiento dispo- (CMS)

nibles.
- Detallar requisitos,
fechas de cierre y con-
diciones para partici-
par en cada convoca-
toria.

Fuente: elaboración propia.

Tabla 21: Tarjeta CRC – Incentivos y Beneficios

Tarjeta CRC Clase Responsabilidades Colaboradores
Incentivos y Benefi- IncentivosBeneficios - Listar y detallar los UI,
cios incentivos y beneficios InformaciónInstitucional
que ofrece el parque
para empresas y em-
prendedores.
| - Explicar de manera
clara y concisa las
ventajas competitivas
y de cooperación que
se ofrecen.

Fuente: elaboración propia.

Tabla 22: Tarjeta CRC – Contacto y Ubicación

Tarjeta CRC Clase Responsabilidades Colaboradores

76
 Capítulo II

Contacto y Ubicación ContactoUbicacion | - Mostrar números UI, Sistema de Mapas

de teléfono, correo,
dirección y enlaces a
redes sociales.
- Incluir un mapa inte-
ractivo o enlaces que
muestren la ubicación
exacta del parque.

Fuente: elaboración propia.

Tabla 23: Tarjeta CRC – Noticias y Eventos

Tarjeta CRC Clase Responsabilidades Colaboradores
Noticias y Eventos Noticiaseventos - Mostrar titulares, fe- UI, Sistema de
chas y resúmenes de Gestión de Contenidos
noticias y eventos re- (CMS)
lacionados con el par-
que.
- Actualizar de forma
periódica la informa-
ción y sincronizar los
datos mostrados.

Fuente: elaboración propia.

Tabla 24: Tarjeta CRC – FAQ

77
 Capítulo II

Tarjeta CRC Clase Responsabilidades Colaboradores

FAQ FAQ - Organizar y mostrar UI, Base de Datos
preguntas frecuentes
categorizadas.
| UI, Base de Datos
|
| | - Proveer res-
puestas claras y enla-
ces a recursos o infor-
mación adicional.

Fuente: elaboración propia.

Tabla 25: Tarjeta CRC – Testimonios

Tarjeta CRC Clase Responsabilidades Colaboradores
Testimonios Testimonios - Mostrar reseñas y UI, Base de Datos
testimonios de usua-
rios, incluyendo alias,
fecha y comentarios.
- Permitir la ordena-
ción y el filtrado de los
testimonios para facili-
tar la consulta.

Fuente: elaboración propia.

II.6 Arquitectura del Software

Estilo arquitectónico MVVM (Model–View–ViewModel)

78
 Capítulo II

El patrón arquitectónico MVVM se propone como una alternativa modular y escalable al estilo
monolítico tradicional. Este enfoque permite separar claramente la interfaz de usuario, la lógica
de presentación y el manejo de datos, facilitando el mantenimiento, la reutilización de
componentes y la evolución futura de la aplicación. MVVM es especialmente adecuado para
aplicaciones móviles desarrolladas con Jetpack Compose, ya que promueve una estructura
reactiva y desacoplada que mejora la experiencia del usuario y la eficiencia del desarrollo.
A continuación, se describe cómo está estructurado este estilo arquitectónico en la propuesta de
solución:
View (Interfaz de Usuario – UI)
Representa la capa visual e interactiva de la aplicación, construida con componentes de Jetpack
Compose como Text, Image, Button, LazyColumn, entre otros. Esta capa se encarga de mostrar
los datos al usuario y capturar sus acciones, sin contener lógica de negocio. La UI observa los
datos expuestos por el ViewModel y se actualiza automáticamente cuando estos cambian.
ViewModel (Lógica de Presentación y Navegación)
Actúa como intermediario entre la UI y el modelo de datos. Gestiona el estado de la interfaz,
transforma los datos para su presentación y maneja la navegación entre pantallas utilizando
NavHost y NavController. También encapsula la lógica de interacción del usuario, como
validaciones, actualizaciones de estado y respuestas a eventos. El uso de State, MutableState,
LiveData o StateFlow permite mantener la UI sincronizada con los datos de forma reactiva.
Model (Gestión de Datos Interna)
Esta capa contiene los datos estáticos y recursos locales necesarios para el funcionamiento de la
aplicación. Incluye estructuras de datos, constantes, archivos JSON o recursos embebidos que
no requieren conexión a internet. El modelo es independiente de la UI y del ViewModel, lo que
permite su reutilización y prueba aislada. En esta propuesta, el modelo también gestiona el
estado persistente de la aplicación mediante mecanismos como remember, State o DataStore.

79
 Capítulo II

Figura 3. Representación del estilo arquitectónico MVVM

Fuente: Adaptado de GeeksforGeeks

II.7 Patrones de Diseño

Los patrones de diseño son una descripción de clases y objetos comunicándose entre sí,
adaptada para resolver un problema de diseño general en un contexto particular. Es una técnica
para flexibilizar el código haciéndolo satisfacer ciertos criterios, una manera más práctica de
describir ciertos aspectos de la organización de un programa y conexiones entre componentes
del programa(Sommerville, 2005).

Patrones GRASP:

80
 Capítulo II

Los patrones GRASP (Patones de Principios Generales para Asignar Responsabilidades) son
principios fundamentales en el diseño orientado a objetos que ayudan a asignar
responsabilidades a las clases(Larman, 2002).
Asignar nombre a los patrones mejora la comunicación, a continuación, se identifican los
principales patrones GRASP utilizados en la implementación de la aplicación:

 Experto en Información: Se utiliza con frecuencia en la asignación de responsabilidades,

es un principio básico que suele usarse en el diseño orientado a objetos. El uso de este
patrón da pie a un bajo acoplamiento y una alta cohesión, lo que favorece tener sistemas
más robustos y de fácil mantenimiento. El cumplimiento de una responsabilidad requiere a
menudo información distribuida en varias clases de objetos(Larman, 2002).
En la aplicación el empleo de este patrón se evidencia en la clase [Link], esta
maneja la información de la navegación a las diferentes pantallas (ver ilustración ).

Figura 4: Patrón GRASP: Experto en Información.

Fuente: Elaboración Propia.

 Controlador: El controlador actúa como un intermediario entre la interfaz de usuario y el

sistema subyacente. Su función principal es recibir las solicitudes de servicio desde la
capa de interfaz de usuario y coordinar la ejecución de las operaciones necesarias, dele-
gando tareas a otros objetos según sea necesario. Esto permite que el controlador gestio-
ne el flujo de datos y eventos sin que la interfaz de usuario esté directamente acoplada a
la lógica de negocio(Larman, 2002).

81
 Capítulo II

En la aplicación el empleo de este patrón se evidencia en la clase [Link] propor-

cionando una clara separación de responsabilidades, centralizando la lógica de navega-
ción y el manejo de eventos del usuario. Esto permite que la interfaz de usuario se man-
tenga enfocada en su función, mientras que AppNavigator coordina las transiciones entre
pantallas (ver figura 5).

Creador: Define qué clase debe ser responsable de crear instancias de otras clases. La
creación de instancias es una de las actividades más comunes en un sistema orientado a
objetos. En consecuencia, es útil contar con un principio general para la asignación de las
responsabilidades de creación. Si se asignan bien, el diseño puede soportar un bajo aco-
plamiento, mayor claridad, encapsulación y reutilización(Larman, 2002).

En la aplicación el empleo de este patrón se evidencia en la clase [Link], donde se

crea una lista de objetos que representan recursos de imágenes. (Ver ilustración 5). Se
crea un objeto que ejecuta una tarea en un bucle infinito con un retraso de 3 segundos.
(Ver ilustración).

Figura 5. Patrón GRASP Creador 1.

Fuente: Elaboración Propia.

Figura 6: Patrón GRASP Creador2.

82
 Capítulo II

Fuente: Elaboración Propia.

 Bajo Acoplamiento: El acoplamiento es una medida de la fuerza con que un elemento está
conectado a, tiene conocimiento de, confía en, otros elementos. Un elemento con bajo (o
débil) acoplamiento no depende de demasiados otros elementos, estos elementos pueden
ser clases, subsistemas, sistemas, etcétera. Una clase con alto (o fuerte) acoplamiento
confía en muchas otras clases(Larman, 2002).
El uso de este patrón se evidencia a partir del indicador de promedio de relaciones entre
clases este se calcula de la siguiente forma (ver ilustración):

2 ∗ Número de Relaciones ( R)
Promedio de Relaciones por Clase=
Número de Clases(C )

Figura 7: Fórmula para calcular el promedio de las relaciones entre clases.

Fuente: (Walpole et al., 2016) “Modificado por el autor”.

Donde R = 20 y C = 11 para un promedio de 1.8 relaciones por clase, por lo que se puede
considerar que el diseño de la aplicación tiene un bajo acoplamiento.

Figura 7 representación de patrón GRASP bajo acoplamiento

83
 Capítulo II

 Alta Cohesión: En cuanto al diseño de objetos, la cohesión (o de manera más específica,

la cohesión funcional) es una medida de la fuerza con la que se relacionan y del grado de
focalización de las responsabilidades de un elemento. Un elemento con responsabilidades
altamente relacionadas, y que no hace una gran cantidad de trabajo, tiene alta cohesión.
Estos elementos pueden ser clases, subsistemas, etcétera. El nivel de cohesión no se
puede considerar de manera aislada a otras responsabilidades y otros principios como los
patrones Experto y Bajo Acoplamiento (Larman, 2002).
El uso de este patrón se evidencia en el diseño de la aplicación ya que este se
complementa con el uso del patrón experto en información y bajo acoplamiento, donde
cada clase está enfocada a tareas específicas y bien definidas, logrando que estas se
centren en su contenido y responsabilidades.

FIGURA 8 representación del patrón GRASP alta cohesión.

Patrones GoF: Los patrones GoF (Patrones de la Pandilla de los Cuatro) fueron publicados por
Gamma, Helm, Johnson y Vlossodes en 1995. Conocidos como patrones de la pandilla de los
cuatro (gang of four). Se clasifican en creacionales, estructurales y de comportamiento (Gamma
et al., 1995).
Patrones de diseño creacionales: Los que se ocupan de la creación de un objeto.
 Singleton: Este patrón restringe la inicialización de una clase para garantizar que solo se
pueda crear una instancia de la clase.
El uso de este patrón creacional se evidencia mediante la utilización de un Scaffold como
instancia única en la aplicación, este proporciona una estructura básica y organizada de la
interfaz de usuario, siguiendo los lineamientos de Material Design, incluye elementos como la
barra superior y el menú lateral.

84
 Capítulo II

Figura 8: Patrón GoF: Singleton

Fuente: Elaboración Propia

Conclusiones del capítulo

A partir del desarrollo de este capítulo, quedan expuestos los elementos principales para el
correcto desarrollo de la propuesta de solución. El análisis de requisitos en términos de
funcionalidad permite realizar una correcta planificación de la implementación. La definición de
las historias de usuario permite describir correctamente los aspectos principales a tener en
cuenta a la hora del desarrollo, estableciendo sus prioridades, orden de implementación e
iteraciones. El empleo de la arquitectura Monolítica y los patrones de diseño GRASP y GoF
contribuyen al diseño de la aplicación y proporcionan una estructura sólida, aplicando buenas
prácticas de programación.

85
 Capítulo III

CAPÍTULO III: IMPLEMENTACIÓN Y PRUEBAS DE LA APLICACIÓN ANDROID PARA LA

MEJORA DE ACCESIBILIDAD Y EXPERIENCIA DE USUARIO EN EL PORTAL
INSTITUCIONAL DEL PARQUE CIENTÍFICO TECNOLÓGICO DE LA HABANA.

El presente capítulo describe la fase de implementación y pruebas para la aplicación Android

propuesta, se describen los estándares de codificación para mejorar la legibilidad del código, la
aplicación es sometida a una etapa de pruebas para verificar el cumplimiento de los
requerimientos del sistema y el correcto funcionamiento de la aplicación, concluyendo con los
resultados del proceso.

III.1 Implementación

La fase de implementación en el desarrollo de software, que sigue a la planificación, análisis y

diseño, convierte las ideas y diseños en código utilizando herramientas y entornos de desarrollo
seleccionados previamente. Es un paso crucial que transforma el diseño en un producto funcional
que cumple con las necesidades del cliente. La codificación de la propuesta de solución inicia
una vez que se definen las historias de usuario correspondientes a cada iteración y se realiza el
diseño de la aplicación, la fase de implementación es esencial para materializar los planes y
objetivos del proyecto, asegurando que se entregue un producto final de alta calidad.

III.2 Estándares de Codificación

Las normas o estándares de codificación son un conjunto de directrices, reglas y

recomendaciones que guían a los equipos de desarrollo en la escritura y estructura del código en
un lenguaje de programación específico. Estas normas establecen convenciones sobre la
estructura, el estilo de escritura, la nomenclatura y otros aspectos que impactan la legibilidad,
coherencia, calidad y mantenibilidad del código. Su objetivo es facilitar la colaboración entre
desarrolladores y la detección de errores, asegurando un código más entendible y manejable.
(Carhuapoma, 2023).

86
 Capítulo III

A continuación, se presentan las normas de codificación del lenguaje de programación Kotlin

utilizados en la implementación de la propuesta de solución:
 Los nombres de las funciones deben seguir la convención de mayúsculas y minúsculas, y
deben ser verbos o frases verbales.
 La llave de cierre se encuentra en su propia línea después de la última línea de código del
cuerpo de la función. La llave de cierre debe alinearse con la palabra clave fun al
comienzo de la función.

fun IconBar(selectedIndex: Int, onIconSelected: (Int) -> Unit) {

...
}

Figura 9: Nombre de las funciones y llave de cierre.

Fuente: Elaboración propia.

 Cada sentencia debe estar en su propia línea.

 El cuerpo de la función debe tener una sangría de 4 espacios.

val icons=listOf(
[Link].ic_launcher_foreground,
[Link].ic_launcher_foreground,
[Link].ic_launcher_foreground,
[Link].ic_launcher_foreground)

Figura 10: Sentencia y cuerpo de la función.

Fuente: Elaboración propia.

-Cada declaración y llamada a función está correctamente separada.

-Cada línea dentro del cuerpo está correctamente indexada.

87
 Capítulo III

 La llave de apertura debe aparecer al final de la línea donde comienza la función.

 Debe haber un espacio antes de la llave de apertura.

fun DescripcionScreen(navController: NavHostController) {

Figura 11: Llave de apertura.

Fuente: Elaboración propia.

III.3 Diagrama de Despliegue

Los componentes del diseño del despliegue describen cómo se organizarán y distribuirán las func
ionalidades del software y sus subsistemas dentro del entorno físico de computación que los sop
ortará. Esto incluye la asignación de recursos de hardware, la configuración de redes, la instalaci
ón de middleware y la integración con otros sistemas y servicios. El diseño del despliegue garanti
za que todas las partes del software funcionen de manera eficiente y segura en el entorno previst
o, optimizando el rendimiento y la escalabilidad del sistema (Pressman, 2010b).

Figura 12: Diagrama de Despliegue

Fuente: Elaboración Propia.

88
 Capítulo III

 Dispositivo Móvil (Sistema Operativo Android, versión 9.0 o superior): representa el

dispositivo físico en el que se ejecutará la aplicación Android. Se refiere específicamente a
un teléfono móvil que utilizarán los usuarios finales, este debe tener una versión de
Android compatible con la aplicación, 9.0 o superior.
 Protocolo Seguro de Transferencia de Hipertexto (HTTPS): representa el protocolo de
transferencia de hipertexto seguro que cifra los datos transmitidos entre el dispositivo móvil
y la tienda de aplicaciones a través del puerto 443.
 Portal web de la institución: representa el portal web de la institución al cual se
conectará la app para actualizar la información necesaria.

III.4 Pruebas de software

Las pruebas de software constituyen la mayor parte del esfuerzo técnico en el desarrollo de
software. Independientemente del tipo de software que se esté creando, una estrategia efectiva
para planificar, ejecutar y controlar pruebas sistemáticas debe comenzar con la evaluación de
pequeños componentes del software y expandirse gradualmente hasta abarcar el programa
completo(Pressman, 2010b).
El propósito principal de las pruebas de software es identificar y corregir errores. En el caso del
software convencional, este objetivo se alcanza a través de una serie de pasos de prueba bien
definidos y estructurados. Además, estas pruebas no solo buscan errores, sino que también
aseguran que el software cumpla con los requisitos especificados y funcione de manera eficiente
y segura.

III.4.1 Estrategia de Pruebas

Una estrategia de pruebas de software actúa como una hoja de ruta detallada que especifica los
pasos necesarios para llevar a cabo las pruebas, el momento adecuado para planificar y ejecutar
dichos pasos, así como la cantidad de esfuerzo, tiempo y recursos que se necesitarán. Por lo
tanto, cualquier estrategia de pruebas debe incluir la planificación de las pruebas, el diseño de
casos de prueba, la ejecución de las pruebas y la recopilación y evaluación de los resultados.

89
 Capítulo III

Además, es fundamental que esta estrategia sea flexible y adaptable a los cambios en los
requisitos del software y a las nuevas tecnologías emergentes, garantizando así la calidad del
producto final (ver tabla 9) (Pressman, 2010b).

Tabla 26: Estrategia de Pruebas

Pruebas de software Descripción
Unitarias Se realizan para verificar el funcionamiento de la aplicación, que
cada componente opere como se espera.

Pruebas del Sistema Estas pruebas se realizan para validar que cada función del software
funcione como se espera y según
los requisitos especificados.

Pruebas no funcionales
Pruebas de Verifican que la aplicación funcione en varios dispositivos.
Compatibilidad

Pruebas de Usabilidad Se realizan para evalúan cuán fácil e intuitiva es la aplicación para
los usuarios finales, observando su interacción real.

Fuente: Elaboración Propia.

III.4.2 Pruebas Unitarias

La prueba de unidad se centra en verificar la parte más pequeña del software: los componentes o
módulos. Utilizando la descripción del diseño de cada componente como referencia, se evalúan
las rutas de control clave para identificar errores dentro del módulo. La complejidad de estas
pruebas y los errores que pueden encontrar son limitados debido al enfoque específico de las
pruebas unitarias. Estas pruebas analizan la lógica interna y las estructuras de datos del

90
 Capítulo III

componente, y pueden llevarse a cabo simultáneamente en varios componentes(Pressman,

2010a).

Prueba del camino básico:

La prueba de camino básico es un tipo de prueba de "caja blanca" que se centra en validar el
código de nuestros sistemas para asegurarnos de que todo funcione correctamente. Esto implica
verificar que todas las instrucciones del programa se ejecuten al menos una vez, garantizando
así la cobertura completa del código. A continuación, se detallan las pruebas de camino básico
para la función Menú de la clase [Link].

Los pasos para desarrollar la prueba del camino básico son:

1.- Dibujar el grafo de flujo.
2.- Calcular la complejidad ciclomática.
3.- Determinar el conjunto básico de caminos independientes.

Paso 1: Dibujar el grafo de flujo: Identificamos los nodos que compondrán el grafo de flujo y los
caminos que se pueden seguir durante la ejecución del programa. Esto nos permite visualizar las
rutas posibles y estructurar el análisis del comportamiento del código. (Ver ilustración 14).

91
 Capítulo III

Figura 13: Grafo de la función menú.

Fuente: Elaboración propia.

Paso 2: Complejidad ciclomática: La complejidad ciclomática cuantifica el número de rutas

independientes dentro del código que se está probando. Se calcula usando la fórmula de
McCabe:
V ( G )=E − N + 2
Fuente:Naik y Tripathy, 2008
a: Es el número de aristas.
n: Es el número de nodos (vértices).
Para nuestro grafo:
 Número de nodos N=8N = 8.
 Número de aristas E=10E = 10.
Entonces:
V(G)=10−8+2=4V(G) = 10 - 8 + 2 = 4

92
 Capítulo III

La complejidad ciclomática es 4, lo que significa que hay 4 caminos linealmente independientes

en el grafo. (ver figura 13).

Paso 3: Determinar el Conjunto Básico de Caminos Independientes.

Se van formando los caminos independientes (4 según la complejidad ciclomática) desde el más
largo al más corto observando nuestro grafo de flujo.
En la figura 10 se muestra el ejemplo de la clase [Link]:, específicamente la función
menú, la cual presenta una complejidad ciclomática de 4.

Caminos Independientes:
Camino 1: Inicio -> Nodo 2 -> Nodo 3 -> Nodo 4 -> Nodo 5 -> Nodo 6 -> Nodo 7 -> Nodo 8.
Camino 2: Inicio -> Nodo 2 -> Nodo 3 -> Nodo 4 -> Nodo 5 -> Nodo 7 (bucle del for con
diferentes valores de índice) -> Nodo 8.
Camino 3: Inicio -> Nodo 2 -> Nodo 3 -> Nodo 4 -> Nodo 5 -> Nodo 8.
Camino 4: Inicio -> Nodo 2 (expanded es false) -> Nodo 8.

Casos de Prueba
Caso de Prueba para el Camino Básico 1:
 Descripción: Verificar que el menú no se muestra cuando expanded es false.
 Condición de ejecución: expanded es false.
 Procedimiento de prueba: Automatizada.
 Datos de entrada: expanded = false, lastSelectedIndex = -1.
 Tipo de dato esperado: No se visualizan elementos del menú.
 Evaluación del caso de prueba: La prueba es exitosa si no se encuentran nodos con
textos especificados.

Caso de Prueba para el Camino Básico 2:

 Descripción: Verificar que el menú se muestra cuando expanded es true.

93
 Capítulo III

 Condición de ejecución: expanded es true.

 Procedimiento de prueba: Automatizada.
 Datos de entrada: expanded = true, lastSelectedIndex = -1.
 Tipo de dato esperado: Los elementos del menú como "Descripcion", "Convocatorias",
“Noticias” están visibles.
 Evaluación del caso de prueba: La prueba es exitosa si todos los nodos con los textos
especificados se visualizan correctamente.

Caso de Prueba para el Camino Básico 3

 Descripción: Verificar que al hacer clic en el ítem "Inicio", la navegación se realiza
correctamente.
 Condición de ejecución: expanded es true, lastSelectedIndex = -1.
 Procedimiento de prueba: Automatizada.
 Datos de entrada: expanded = true, lastSelectedIndex = -1.
 Tipo de dato esperado: El NavController navega a "main".
 Evaluación del caso de prueba: La prueba es exitosa si el NavController recibe una
llamada al método navigate con el argumento "home".
A continuación, se muestra el código de la función menú de la clase [Link]:

94
 Capítulo III

Figura 14: Código de la función menú.

Fuente: Elaboración Propia.

A continuación, se presenta un registro técnico que resume la evolución del comportamiento del
componente menú en la clase [Link] a través de tres iteraciones consecutivas.

Tabla 27: Evolución de Resultados de Pruebas Unitarias

Iteración Camino Evaluado Ejecuciones Éxito (%) Observaciones Técnicas
Menú no visible (ex- Comportamiento intermitente en
1 10 90%
panded = false) la inicialización de la variable.
Visualización del
Inconsistencia leve al renderizar
1 menú (expanded = 10 95%
elementos.
true)
Flujo sin interacción
1 10 100% Ejecuciones estables.
adicional
Navegación a Ajuste requerido en la simulación
1 10 90%
“home” del clic.
Fallos corregidos respecto a la
2 Menú no visible 10 100%
iteración anterior.

95
 Capítulo III

Iteración Camino Evaluado Ejecuciones Éxito (%) Observaciones Técnicas

Visualización del
2 10 100% Estabilidad lograda.
menú
Flujo sin interacción
2 10 100% Comportamiento sostenido.
adicional
Navegación a Incidencia leve subsanada con
2 10 95%
“home” ajustes en mocks.
Todos los caminos Comportamiento óptimo en todas
3 40 100%
(1 a 4) las rutas evaluadas.
Fuente: elaboración propia.
Análisis Evolutivo de Calidad

Durante las tres iteraciones, se observó una mejora progresiva en la estabilidad del componente,
gracias al enfoque incremental de XP:

Iteración 1: Se identificaron incidencias menores que fueron inmediatamente considera-

das para refactorización.

Iteración 2: Las mejoras implementadas permitieron estabilizar el flujo, especialmente en

la navegación.

Iteración 3: Se alcanzó un comportamiento estable en todas las pruebas, reflejando una

madurez funcional del módulo.

Las pruebas unitarias aplicadas al componente menú de la clase [Link] evidenciaron una
mejora progresiva y sostenida a lo largo de tres iteraciones. En la primera, se identificaron fallos
intermitentes en la inicialización de variables y en la simulación de interacciones, lo cual permitió
detectar oportunamente áreas críticas de mejora. En la segunda iteración, tras aplicar correccio-
nes, las ejecuciones reflejaron un comportamiento más estable, con tasas de éxito superiores al
95% en todos los caminos evaluados. Finalmente, en la tercera iteración, se alcanzó un 100% de
éxito en todas las ejecuciones, demostrando que los ajustes implementados consolidaron la ro-
bustez del módulo.

96
 Capítulo III

III.4.3 Pruebas de Caja Negra

Las pruebas de caja negra constituyen una metodología de evaluación del software cuyo objetivo
es verificar el comportamiento funcional del sistema a partir de sus especificaciones y
requerimientos, sin analizar la estructura interna del código (Delta Protect, 2025). Este enfoque
se centra exclusivamente en la relación entre las entradas que se proporcionan al sistema y las
salidas que este genera, lo que permite validar que el producto final se comporte conforme a lo
esperado.

Análisis de Requerimientos y Especificaciones

El primer paso consiste en examinar detalladamente la documentación del sistema, que incluye
las historias de usuario, los casos de uso y las especificaciones funcionales y no funcionales.
Este análisis resulta fundamental para identificar los criterios de aceptación, las condiciones de
entrada válidas e inválidas, así como las salidas esperadas, sin necesidad de conocer la lógica
interna del software (Zaptest, 2023).

Diseño de Casos de Prueba

Sobre la base del análisis anterior, se procede a diseñar el conjunto de casos de prueba
utilizando técnicas clásicas de caja negra. Entre las técnicas más reconocidas se destacan:

 Partición de Equivalencia: Esta técnica consiste en dividir el dominio de entrada en clases

homogéneas tanto válidas como inválidas, de modo que se reduce el número de casos de
prueba necesarios sin comprometer la cobertura de las condiciones de entrada (Delta
Protect, 2025).
 Análisis de Valores Límite (Boundary Value Analysis): Se centra en evaluar los puntos
extremos de cada clase de equivalencia, ya que los errores tienden a ocurrir en los límites del
rango permitido. Esta técnica es esencial para detectar defectos que no se identificarían
mediante pruebas con valores intermedios (Zaptest, 2023).

97
 Capítulo III

 Pruebas Basadas en Casos de Uso: Consiste en la elaboración de escenarios de prueba que

simulan situaciones reales de interacción con el sistema, permitiendo comprobar que la
funcionalidad responda de forma adecuada en cada flujo de trabajo esperado (Delta Protect,
2025).

Ejecución y Registro de Resultados

Una vez diseñados, los casos de prueba se ejecutan en un entorno que simula las condiciones
reales de uso del sistema. Durante la ejecución se documentan de forma rigurosa los datos de
entrada empleados, los resultados observados y se realiza la comparación con los resultados
esperados. Esta trazabilidad es crucial para evaluar la conformidad del sistema con los
requerimientos especificados y para identificar cualquier desviación en su comportamiento
(Zaptest, 2023).

Evaluación y Retroalimentación
Finalmente, se analizan los resultados de los casos de prueba para identificar errores o
desviaciones en el comportamiento del sistema. Las discrepancias detectadas se registran y se
comunican al equipo de desarrollo, permitiendo que se realicen las correcciones pertinentes. Este
ciclo iterativo de evaluación y retroalimentación es esencial para garantizar que el sistema
cumpla con los criterios de aceptación definidos y ofrezca un rendimiento robusto y confiable
(Delta Protect, 2025).

Caso de Uso “Mostrar Noticias y Eventos”

El presente caso de uso tiene como objetivo proveer una sección en la aplicación en la que se
visualicen noticias y eventos relacionados con el parque tales como actividades, conferencias y
talleres de modo que el usuario se mantenga informado sobre las iniciativas y actividades del
mismo. Se establece que, para asegurar la operatividad sin conexión a Internet, la aplicación
debe mostrar la información almacenada en la memoria local, actualizándose automáticamente al
detectar conectividad.

98
 Capítulo III

Identificación del Caso de Uso

Título: Mostrar Noticias y Eventos
Actor Primario: Usuario (visitante o interesado en la información del parque)
Objetivo: Proveer una sección en la aplicación que presente noticias y eventos relacionados con
el parque, posibilitando la visualización de datos almacenados localmente en modo Offline y su
actualización automática cuando se disponga de conexión a Internet (Delta Protect, 2025).

Flujo Principal (Escenario Exitoso):

1. El usuario accede al menú principal de la aplicación.
2. El usuario selecciona la opción “Noticias y Eventos”.
3. El sistema consulta la memoria local y muestra la lista de noticias y eventos almacenados.
4. Al detectar conexión a Internet, el sistema consulta el servicio web o la base de datos
externa para actualizar la información almacenada.
5. La interfaz muestra la lista actualizada de noticias y eventos, ordenada de forma
cronológica o según la relevancia.

Flujos Alternativos:
No se Encuentran Noticias o Eventos:
1. El usuario ingresa a la sección “Noticias y Eventos”.
2. El sistema no encuentra registros en la memoria local y muestra un mensaje informativo, por
ejemplo: “No hay noticias o eventos disponibles en este momento”.

Error en la Actualización de la Información:

1. El usuario selecciona “Noticias y Eventos”.
2. Se produce un error en la consulta al servicio web (por ejemplo, por problemas de conexión o
fallo del servidor).

99
 Capítulo III

3. El sistema mantiene la información local y muestra un mensaje de error (“Error al actualizar la

información, intente más tarde”), ofreciendo la opción de reintentar la actualización. (Delta
Protect, 2025)

Diseño de Escenarios de Prueba

Con base en el caso de uso “Mostrar Noticias y Eventos”, se han diseñado los siguientes
escenarios para validar la funcionalidad mediante pruebas basadas en casos de uso:

Tabla 28: Escenario de Prueba 1 - Visualización Exitosa con Datos Almacenados

Precondición Datos de Entrada Pasos Resultado Esperado
Existen noticias y Navegación a la 1. El usuario ingresa a la Se muestran
eventos sección “Noticias y pantalla de “Noticias y correctamente las
previamente Eventos” sin Eventos”. noticias y eventos
almacenados en la conexión a 2. El sistema carga y disponibles,
memoria local de la Internet. muestra la información permitiendo al
aplicación almacenada en la usuario acceder a la
memoria local. información en modo
Offline.
Fuente: elaboración propia.

Tabla 29: Escenario de Prueba 2 - Actualización de Información al Conectar a Internet

Precondición Datos de Entrada Pasos Resultado Esperado
Existen registros Navegación a la 1. El usuario accede a El sistema actualiza
almacenados sección “Noticias y “Noticias y Eventos” y, la información local y
localmente y se Eventos”; en modo Offline, se muestra la versión
dispone de transición de modo muestran los datos más reciente de
conexión a Internet. Offline a online. almacenados noticias y eventos.

100
 Capítulo III

Precondición Datos de Entrada Pasos Resultado Esperado

localmente.
2. El sistema detecta la
conexión a Internet y
procede a consultar el
servicio web.
3. La información se
actualiza
automáticamente en la
interfaz
Fuente: elaboración propia.

Tabla 30: Escenario de Prueba 3 - Sin Noticias ni Eventos Disponibles

Precondición Datos de Entrada Pasos Resultado Esperado
No existen registros Navegación a la 1. El usuario ingresa a Se muestra
de noticias o sección “Noticias y “Noticias y Eventos”. correctamente el
eventos Eventos” 2. El sistema detecta la mensaje informativo,
almacenados en la ausencia de registros indicando la falta de
memoria local. y, en consecuencia, datos.
muestra un mensaje
informativo (“No hay
noticias o eventos
disponibles en este
momento”).
Fuente: elaboración propia.

101
 Capítulo III

Tabla 31: Escenario de Prueba 4 - Error en la Actualización en Línea

Precondición Datos de Entrada Pasos Resultado Esperado
Existen noticias y Navegación a la 1. El usuario accede a El sistema notifica el
eventos sección “Noticias y “Noticias y Eventos” y error y permite
almacenados, pero Eventos” en se muestran los datos reintentar la
se fuerza un error condiciones de almacenados actualización sin afectar
en la consulta de conectividad localmente. la visualización de los
actualización (por inestable. 2. Se produce un error al datos locales.
ejemplo, mediante intentar actualizar la
fallo de conexión). información (fallo en la
consulta al servicio
web).
3. El sistema mantiene la
información local,
muestra un mensaje
de error (“Error al
actualizar la
información, intente
más tarde”) y ofrece la
opción de reintentar la
actualización.
Fuente: elaboración propia

Ejecución y Registro de Resultados

Durante la fase de pruebas, cada escenario se ejecuta en un entorno que simula las condiciones
reales de uso de la aplicación. Para ello se registra de forma sistemática:
Entradas: Selección de la opción “Noticias y Eventos” y condiciones de conectividad (sin
conexión, con conexión o intermitente).

102
 Capítulo III

Acciones Realizadas: Navegación a la sección, carga de datos locales, intento de actualización

mediante consulta al servicio web.
Resultados Observados: Visualización correcta de datos, presentación de mensajes informativos
o de error, según corresponda.
Verificación: Comparación entre los resultados obtenidos y los resultados esperados para cada
escenario.
La siguiente tabla presenta de manera consolidada los resultados obtenidos en tres sprints de
pruebas, detallando los escenarios de prueba, las ejecuciones, la tasa de éxito y las
observaciones relevantes:

Tabla 32: Resultados de Validación Funcional por Iteración

Escenario
Iteración Ejecuciones Éxito (%) Observaciones Técnicas
Evaluado
Visualización con Demoras leves en modo offline;
1 10 90%
datos locales actualización parcial.
Actualización online
Fallas intermitentes en sin-
1 con conectividad 10 85%
cronización.
inestable
Sin datos Mensaje informativo mostrado
1 10 100%
disponibles correctamente.
Error en actual- Mensaje de error correcto; rein-
1 10 90%
ización tento no siempre activado.
Visualización con
2 10 100% Carga optimizada; sin demoras.
datos locales
Mejora significativa; una inciden-
2 Actualización online 10 95%
cia menor.
Sin datos
2 10 100% Comportamiento esperado.
disponibles
Error en actual- Reintento funcional en la mayoría
2 10 95%
ización de los casos.
Todos los escenar- Comportamiento estable y valida-
3 40 100%
ios anteriores do en todos los casos.
Fuente: elaboración propia.

103
 Capítulo III

Análisis Iterativo
Iteración 1: Se identificaron puntos críticos en la sincronización y manejo de errores, lo que
permitió priorizar mejoras funcionales.
Iteración 2: Las correcciones aplicadas mejoraron la experiencia del usuario, especialmente en
condiciones de conectividad variable.
Iteración 3: Se alcanzó una validación completa del módulo, con comportamiento consistente en
todos los escenarios funcionales
Conclusión sobre los Resultados de las Pruebas Funcionales (Caja Negra)
Las pruebas funcionales realizadas sobre el módulo “Mostrar Noticias y Eventos” permitieron
evaluar su comportamiento frente a diversos escenarios de uso real. En la primera iteración se
observaron incidencias en la actualización de datos en línea bajo condiciones de conectividad
variable, así como demoras en el despliegue local en modo offline. Estas situaciones fueron
abordadas en las siguientes iteraciones. En la segunda, se registró una mejora significativa en la
eficiencia del módulo, aunque persistió un caso aislado de inestabilidad durante la sincronización.
Para la tercera iteración, todos los casos fueron superados con éxito, alcanzándose una tasa de
éxito del 100% en cada prueba.

III.4.4 Pruebas de Compatibilidad

Las pruebas de compatibilidad constituyen un proceso esencial en el desarrollo de aplicaciones

móviles, ya que permiten evaluar la interacción del software con diversas configuraciones de har-
dware y versiones del sistema operativo. Para el presente estudio se han seleccionado dispositi-
vos que ejecutan versiones de Android mayores o iguales a 9.0 y dispositivos cuya versión es
inferior a 9.0, considerando únicamente modelos que continúan disponibles en el mercado y no
se encuentran descontinuados (Android Developers, 2022; CDD, 2021). Esta estrategia resulta
fundamental para identificar posibles conflictos en la ejecución de la aplicación, derivados tanto
de limitaciones en las APIs modernas como de restricciones en recursos de hardware.

104
 Capítulo III

En paralelo, se ha analizado la arquitectura de hardware de cada dispositivo, ya que esta variable

influye directamente en el rendimiento y la estabilidad del software. En el ecosistema Android se
distinguen principalmente dos arquitecturas relevantes para el presente estudio:

ARM64-v8a: Utilizada en la mayoría de los dispositivos modernos, que ofrecen un mejor

manejo de la memoria y un rendimiento optimizado.

ARMv7: Frecuente en equipos de gama baja o en aquellos que operan con versiones anti-
guas del sistema operativo, los cuales pueden presentar limitaciones para soportar las tec-
nologías y APIs actuales.

A continuación, se muestra la tabla de dispositivos evaluados, en la que se especifica el modelo,

la versión de Android, la capacidad de memoria RAM, la arquitectura de hardware utilizada, el
resultado de la prueba y, en caso de incompatibilidad, las razones que justifican el fallo.

Tabla 33: Dispositivos empleados en las pruebas de compatibilidad

Versión
Marca Modelo RAM Arquitectura Resultado Observaciones
Android

Galaxy
Samsung 11.0 4GB ARM64-v8a Pasa Compatible.
A03S

Google Pixel 7 13.0 6GB ARM64-v8a Pasa Compatible.

Google Pixel 3 9.0 2GB ARM64-v8a Pasa Compatible: cumple

con los requerimientos
mínimos de rendi-

105
 Capítulo III

Versión
Marca Modelo RAM Arquitectura Resultado Observaciones
Android

miento y manejo de
APIs.

Moto G
Motorola 10.0 4GB ARM64-v8a Pasa Compatible.
Power

Redmi
Xiaomi 11.0 4GB ARM64-v8a Pasa Compatible.
Note 11

OnePlus OnePlus 9 11.0 8GB ARM64-v8a Pasa Compatible.

No compatible: la ver-
sión de Android es
inferior a 9.0, lo que
Xiaomi Redmi 7A 8.1 2GB ARMv7 No Pasa impide el uso de APIs
y funcionalidades mo-
dernas requeridas por
la aplicación.

Samsung Galaxy J2 8.1 (An- 1GB ARMv7 No Pasa No compatible: las

Core droid limitaciones de la ver-
Go) sión del sistema ope-

106
 Capítulo III

Versión
Marca Modelo RAM Arquitectura Resultado Observaciones
Android

rativo y los recursos

de hardware impiden
soportar las funcionali-
dades mínimas de la
app.

No compatible: la ver-
sión de Android no
cumple con los requi-
sitos mínimos estable-
Motorola Moto E5 8.0 1GB ARMv7 No Pasa
cidos, afectando la
ejecución correcta y la
experiencia del usua-
rio.

Fuente: elaboración propia.

La siguiente tabla presenta de manera consolidada los resultados obtenidos en tres sprints de
pruebas de compatibilidad, detallando el escenario de prueba, las ejecuciones, la tasa de éxito y
las observaciones relevantes.

Registro Técnico de Resultados de Pruebas de Compatibilidad

107
 Capítulo III

Este registro forma parte del proceso de validación continua promovido por XP. Las pruebas se
ejecutaron al cierre de cada iteración para asegurar que el sistema se comporta correctamente
en diferentes entornos de ejecución. Los resultados fueron utilizados para retroalimentar decisio-
nes de ajuste y delimitación del soporte técnico.
Tabla 34: Resultados de Pruebas de Compatibilidad

Escenario
Iteración Ejecuciones Éxito (%) Observaciones Técnicas
Evaluado
Android ≥ 9.0 Demoras iniciales leves; actuali-
1 10 90%
(ARM64-v8a) zación parcial en algunos casos.
Fallos críticos por incompatibili-
Android < 9.0
1 10 30% dad con APIs modernas; sincroni-
(ARMv7)
zación fallida.
Android ≥ 9.0 Optimización efectiva de recur-
2 10 100%
(ARM64-v8a) sos; ejecución sin incidencias.
Android < 9.0 Mejora parcial; persisten errores
2 10 40%
(ARMv7) en actualización y visualización.
Android ≥ 9.0 Desempeño óptimo; todas las
3 10 100%
(ARM64-v8a) funcionalidades operativas.
Incompatibilidades estructurales
Android < 9.0
3 10 0% impiden la ejecución correcta del
(ARMv7)
módulo.

Resultados Técnicos de Pruebas de Compatibilidad

Durante tres ciclos de iteración, se evaluó la compatibilidad del sistema en dispositivos Android
con diferentes arquitecturas y versiones del sistema operativo, identificándose diferencias
significativas en el comportamiento entre entornos modernos y obsoletos.

Android ≥ 9.0 (ARM64-v8a):

Iteración 1: La aplicación presentó un comportamiento funcional aceptable (90%), con leves
demoras en la carga inicial y en la actualización automática bajo ciertas condiciones de red.
Iteración 2: Se alcanzó una compatibilidad completa (100%) tras optimizaciones en la gestión de
recursos, lo cual permitió una ejecución fluida del módulo.

108
 Capítulo III

Iteración 3: Se confirmó la estabilidad del sistema, con una ejecución sin errores ni degradación
de rendimiento (100%).

Android < 9.0 (ARMv7):

Iteración 1: Se identificaron fallos graves de compatibilidad (30%), provocados por la
imposibilidad de ejecutar funciones que dependen de APIs modernas.
Iteración 2: Se logró una mejora leve (40%) mediante ajustes parciales, aunque persistieron
problemas en la sincronización y actualización de datos.
Iteración 3: Las ejecuciones fallaron en su totalidad (0%), confirmando la incompatibilidad del
sistema con esta arquitectura debido a limitaciones estructurales y de sistema operativo.
Resumen del resultado: Las pruebas de compatibilidad demostraron que el sistema es estable y
funcional únicamente en dispositivos que operan con Android 9.0 o superior y arquitectura
ARM64-v8a. En contraste, dispositivos con versiones anteriores o arquitecturas obsoletas
presentaron fallos críticos que imposibilitan su uso operativo. Estos resultados sustentan la
decisión técnica de establecer Android 9.0 como requisito mínimo de compatibilidad, asegurando
así una experiencia de usuario robusta, segura y alineada con las capacidades del software
desarrollado.

III.4.5 Pruebas de Usabilidad

Las pruebas de usabilidad en aplicaciones móviles evalúan cómo los usuarios interactúan con la
aplicación y cómo esta guía sus acciones, proporcionando retroalimentación significativa y
manteniendo una interacción coherente. El enfoque aquí es determinar en qué medida la interfaz
facilita la experiencia del usuario. (Pressman, 2010).

Son los usuarios finales quienes las llevan a cabo las pruebas de usabilidad. El proceso incluye
los siguientes pasos:
1. Definir categorías de usabilidad y establecer objetivos para cada una.

109
 Capítulo III

2. Diseñar pruebas que evalúen esos objetivos.

3. Seleccionar participantes para las pruebas.
4. Registrar la interacción de los participantes con la aplicación durante la evaluación.
5. Crear un mecanismo para medir la usabilidad de la app.

Para realizar esta prueba se lleva a cabo una evaluación de usabilidad mediante el cuestionario
estándar, System Usability Scale (SUS) o Escala de Usabilidad del Sistema. Es una herramienta
estándar para medir la usabilidad de un sistema o producto El cuestionario consiste en 10
preguntas que evalúan distintos aspectos de la usabilidad del sistema. Las preguntas abarcan
aspectos como la facilidad de uso, la complejidad del sistema, la integración de funciones y la
confianza del usuario al interactuar con el sistema. Al final, las respuestas se procesan para
obtener una puntuación global que varía de 0 a 100, proporcionando una medida cuantitativa de
la usabilidad del sistema (Albert & Tullis, 2022).

Descripción del procedimiento realizado:

Seleccionar a los Participantes

Se elige una muestra de 5 usuarios los cuales representan el público objetivo de la aplicación.
Incluye usuarios con diferentes niveles de experiencia en el uso de aplicaciones móviles para
obtener una perspectiva amplia.

Proporcionar Acceso a la Aplicación

Permite que los usuarios instalen la aplicación en sus dispositivos Android, estos interactúan con
la aplicación durante un tiempo determinado, explorando varias secciones como: descripción,
misión, visión, capacitación y atención a la población.

Proporcionar el Cuestionario SUS

110
 Capítulo III

Después de usar la aplicación, los usuarios deben completar la encuesta SUS, que consta de 10
preguntas con respuestas en una escala de Likert de 1 a 5. Las preguntas evalúan diversos
aspectos de la usabilidad de la aplicación (ver anexo 3).

Analizar los Resultados

Puntuaciones: Los usuarios responden en una escala de Likert de 1 a 5 para cada pregunta (1 =
Totalmente en desacuerdo, 5 = Totalmente de acuerdo). Para preguntas impares (positivas):
resta 1 de la puntuación del usuario. Para preguntas pares (negativas): resta la puntuación del
usuario de 5. Suma los resultados y multiplícalos por 2.5 para obtener la puntuación final (0 a
100) (Albert & Tullis, 2022).

Tabla 35: Promedio de las puntuaciones otorgadas por los usuarios.

Usuario Puntuación
Usuario 1 75
Usuario 2 77
Usuario 3 82
Usuario 4 77
Usuario 5 75
Promedio 77

Fuente: Elaboración Propia.

Interpretar la Puntuación:

El promedio total de las puntuaciones otorgadas por los usuarios permite determinar la usabilidad
del sistema. Una puntuación promedio superior a 68 indica una buena usabilidad, sugiriendo que
la aplicación es fácil de usar y cumple con las expectativas de los usuarios. En cambio, una pun-
tuación inferior a 68 puede revelar problemas de usabilidad que requieren atención. Además del

111
 Capítulo III

promedio, se pueden analizar las respuestas individuales para identificar patrones o áreas espe-
cíficas que necesiten mejoras.

Figura 15: Representación del resultado de la encuesta.

Fuente: Elaboración Propia.

Los resultados de la encuesta SUS indican que la aplicación tiene una buena usabilidad, con una
puntuación promedio de 78. Esto sugiere que los usuarios encuentran la aplicación fácil de usar,
intuitiva y funcional. La alta puntuación demuestra que la mayoría de los participantes tienen una
experiencia positiva al interactuar con la aplicación, cumpliendo y superando las expectativas en
términos de accesibilidad y facilidad de uso. Esta retroalimentación es valiosa para confirmar que
el diseño y la implementación de la aplicación están alineados con los principios de una buena
usabilidad.

Conclusiones Parciales

La investigación y la elección de estándares de codificación han sido fundamentales para

asegurar la legibilidad y coherencia del código a lo largo del desarrollo del proyecto. Este enfoque
no solo ayudó a prevenir errores, sino que también contribuyó a mejorar la calidad general de la
aplicación. Las pruebas de software desempeñaron un papel crucial al garantizar que la
aplicación funcionara de acuerdo con las expectativas establecidas. A través de estas pruebas,
se identificaron errores y problemas antes de la entrega final del sistema, lo que permitió realizar

112
 Capítulo III

las correcciones necesarias de manera oportuna. En conjunto, estos esfuerzos han resultado en
un producto más funcional y confiable, listo para satisfacer las necesidades de los usuarios
finales.

113
 Conclusiones

CONCLUSIONES

 La aplicación móvil desarrollada contribuye significativamente a mejorar el acceso a la

información institucional del Parque Científico Tecnológico de La Habana, al centralizar y
digitalizar contenidos clave como misión, visión, servicios, proyectos y convocatorias,
presentándolos de forma clara y adaptativa para dispositivos Android.
 La integración de funcionalidades identificadas como buenas prácticas en aplicaciones
móviles de parques científicos y tecnológicos como notificaciones, búsqueda avanzada y
soporte offline permitió construir una solución contextualizada a las condiciones tecnológicas
del entorno cubano.
 La estrategia de pruebas de usabilidad aplicada permitió detectar y corregir deficiencias en la
interfaz y navegación, lo que resultó en una aplicación estable, funcional y alineada con las
necesidades de los usuarios.
 La validación empírica mediante prototipos, historias de usuario y tarjetas CRC facilitó la
definición de requerimientos funcionales y el diseño modular del sistema, fortaleciendo la
planificación y ejecución del desarrollo.

114
 Recomendaciones

RECOMENDACIONES

A pesar de los avances logrados, se identifican limitaciones relacionadas con la infraestructura

digital y la conectividad. Se recomienda continuar con estudios de campo, incorporar
retroalimentación de usuarios y explorar tecnologías emergentes como inteligencia artificial para
futuras versiones de la aplicación..

115
 Referencias Bibliográficas

REFERENCIAS BIBLIOGRÁFICAS

Acosta Espinoza, J. L., Lenin León Yacelga, A. R., Sanafria Michilena, W. G., Acosta Es-
pinoza, J. L., Lenin León Yacelga, A. R., & Sanafria Michilena, W. G. (2022). Las aplicacio-
nes móviles y su impacto en la sociedad. Revista Universidad y Sociedad, 14(2), 237-243.

Aduana Nacional de Bolivia. (2023). Aplicaciones de Android en Google Play.

[Link]

Albert, B., & Tullis, T. (2022). Measuring the User Experience: Collecting, Analyzing, and
Presenting UX Metrics. Morgan Kaufmann.

Alegsa, L. (2023, junio 12). Definición de SDK. [Link].

[Link]

Almeida, E. (2019). ¿Aplicación monolítica o distribuida?

[Link]

Android Developers. (2024a). Aspectos básicos de Jetpack Compose. Android Developers.

[Link]

Android Developers. (2024b). Introducción a Android Studio. Android Developers.

[Link]

Beck, K. (2004). JUnit Pocket Guide. O’Reilly Media.

Blancarte Iturralde, O. (2020). Introducción a la Arquitectura de Software un Enfoque Prácti-

co.

116
 Referencias Bibliográficas

BRUZÓN, A. Aplicación Android para el portal institucional de la Contraloría General de la

República de Cuba. Trabajo de Diploma. Universidad de las Ciencias Informáticas, UCI, 2024.

Carbo, T., & Smith, M. M. (2008). Global information ethics: Intercultural perspectives on past
and future research. Journal of the American Society for Information Science and Technology.
[Link]

Carhuapoma, L. (2023). Normas de Codificación y Calidad del Código: Guía para Desarrolla-
dores. [Link]
codigo-guia-para-desarrolladores

Carnerero, F., & Pérez, A. (2011). Acceso a la información a partir de dispositivos móviles
para mejorar la ocupabilidad. Universidad Oberta de Cataluña.

Chagoya, E. (2008). Métodos y técnicas de investigación.

[Link]

Cockburn, A. (2002). Agile software development. Boston: Addison-Wesley.

[Link]

Contraloría General de la República de Costa Rica. (2024). Aplicaciones de Android en

Google Play. [Link]
id=[Link].app_e6c43e318725497da5de52321dedee89.app

Contraloría General de la República de Cuba. (2024a). Atención a la población | Contraloría

General de la República de Cuba. [Link]

Contraloría General de la República de Cuba. (2024b). Capacitación | Contraloría General

de la República de Cuba. [Link]

117
 Referencias Bibliográficas

Contraloría General de la República de Cuba. (2024c). Misión y visión | Contraloría General

de la República de Cuba. [Link]

Contraloría General de la República de Cuba. (2024d). Sistema de control interno | Contra-

loría General de la República de Cuba. [Link]
interno

Carbo, T.; Smith, M. M. Global information ethics: Intercultural perspectives on past and futu-
re research [en línea]. Journal of the American Society for Information Science and Technolo-
gy, 2008. [Consulta: 8 julio 2025]. Disponible en:
[Link]

Cubadebate. (2022). Disponible aplicación Banmet de Banco Metropolitano con nuevas pres-
taciones—Cubadebate. Cubadebate - Cubadebate, Por la Verdad y las Ideas.
[Link]
metropolitano-con-nuevas-prestaciones/

Cubadebate. (2024). Gobierno digital en Cuba: Avances y desafíos en la integración y simpli-

ficación de trámites - Cubadebate. Cubadebate - Cubadebate, Por la Verdad y las Ideas.
[Link]
en-la-integracion-y-simplificacion-de-tramites/

Dalmau Palomino, D. E., & Guzmán Hernández, Y. (2023). UNA METODOLOGÍA PARA LA
RENDICIÓN DE CUENTAS DE LA ADMINISTRACIÓN A LOS TRABAJADORES.
[Link]
[Link]

Fiscalía General de Cuentas de Panamá. (2015). Acerca de la Fiscalía de Cuentas. Fiscalía

General de Cuentas. [Link]

118
 Referencias Bibliográficas

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Elements of
Reusable Object-Oriented Software. Pearson Deutschland GmbH.

García Peñalvo, J., & García Holgado, A. (2023). Modelo de Dominio en Ingeniería de So-
ftware [Universidad de Salamanca].
[Link]
da8643a8a060/content

Gartner Inc. (2016). Doce habilidades ágiles para desarrolladores de software.

[Link]

GlosarioIT. (2024). Glosario informático—Definición de términos informáticos.

[Link]

Gobierno de España. (2023). GUÍA LEY DE TRANSPARENCIA, ACCESO A LA INFORMA-

CIÓN PÚBLICA Y BUEN GOBIERNO.
[Link]
15371987773a/Ley_de_transparencia_v2.pdf

Gradle Inc. (2023). Gradle User Manual.

[Link]

Guevara, A. (2010). Punto Seguridad Digital en Dispositivos Móviles.

[Link]

JetBrains. (2024). Kotlin Programming Language. Kotlin. [Link]

Larman, C. (2002). Applying UML and Patterns: An Introduction to Object-oriented Analysis

and Design and the Unified Process. Prentice Hall Professional.

119
 Referencias Bibliográficas

Letelier, P., & Pandarés, C. (2006). Metodologías ágiles para el desarrollo de software: eX-
treme Programming (XP). [Link]

Lombao Martínez, M. J. (2021). ILEX Asesoramiento Jurídico. APKlis.

[Link]

Mahalakshmi, & Sundararajan. (2013). Traditional SDLC Vs Scrum Methodology – A Com-

parative Study. [Link]
repid=rep1&type=pdf&doi=7740829e70c028a75780d3b7bd034345beb940c4

Melián Hernández, J. A. (2006). Relaciones y diferencias entre fiscalización y auditoría. Ra-

zones para una reforma de las normas de auditoría del sector público. [Link]
content/uploads/PDF/200607_39_33.pdf

Menzinsky, A., López, G., Palacio, J., Sobrino, M. Á., Álvarez, R., & Rivas, V. (2022). His-
torias de Usuario.

Ortiz Tanori, A. R., & García Mireles, G. (2008). Estimación en proyectos de software basa-
do en “PLANNING POKER”.
[Link]

Perea, A., Cerón, A., Figueroa, J. G., & Cerón, H. (2021). Métodos teóricos de la investiga-
ción [UNIVERSIDAD AUTÓNOMA DEL ESTADO DE HIDALGO].
[Link]
[Link]?sequence=1&isAllowed=y

Pérez Romero, J. (1999). Derecho administrativo general. EUNED.

Pressman, R. S. (2005). Ingeniería del Software. Un Enfoque Practico.

[Link]

120
 Referencias Bibliográficas

Pressman, R. S. (2010a). Ingeniería del software: Un enfoque práctico. McGraw-Hill Intera-

mericana.

Pressman, R. S. (2010b). Software engineering: A practitioner’s approach (7th ed). McGraw-

Hill Higher Education.

Quispe, K. V. C. (2022). Desarrollo de aplicaciones móviles usando el lenguaje Kotlin. Dialo-

gos Abiertos, 1(1), Article 1. [Link]

Robledo Sacristán, C., & Robledo Fernández, D. (2012). Programación en Android.

Rumbaugh, J., Jacobson, I., & Booch, G. (2010). Unified Modeling Language.
[Link]
%20by%20James%[Link]

Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum:
The Rules of the Game. [Link]
[Link]

Sebesta, R. W. (2002). Concepts of programming languages. Boston: Addison Wesley.

Sommerville, I. (2005). Ingeniería de Software Séptima Edición. Pearson Education, SA.

Universidad de las Ciencias Informáticas. (2020). iLex Notario. APKlis.

[Link]

Visual Paradigm. (2024a). Acerca de Visual Paradigm.

[Link]

Visual Paradigm. (2024b). Paradigma visual: UML, Agile, PMBOK, TOGAF, BPMN y más.
[Link]

121
 Referencias Bibliográficas

Walpole, R., Myers, R., & Myers, S. (2016). Probability statistics for Engineers scientists.
Pearson Education Limited. [Link]
scientists_compress

Wang, W. (2018). Office 2019 For Dummies. John Wiley & Sons.

Carnerero, J., & Pérez, R. (2011). Impacto de las aplicaciones móviles en la digitalización
gubernamental. Editorial Académica.

Cepeda, L., Gómez, R., & Torres, M. (2022). Transformación digital y aplicaciones móviles
en la gestión pública. Revista de Tecnología y Gobierno, 18(2), 45-62.

Cubadebate. (2024). Encuesta sobre el acceso a internet en Cuba. Cubadebate. Disponible

en: [URL de la fuente].

Fernández, C. (2021). Participación ciudadana y digitalización: el impacto de las TIC en go-

biernos latinoamericanos. Universidad Nacional de Buenos Aires.

González, P., & Martínez, S. (2023). Desarrollo de plataformas digitales para la optimización
de servicios gubernamentales. Editorial Innovación Tecnológica.

Lean Mind. (2022). CRC Cards (Class Responsibility Collaborator) – Lean Mind.

[Link].. (s.f.). Tarjetas CRC (Colaborador de Responsabilidad Colectiva)

Atlassian – Historias de Usuario. (s.f.). Disponible en:

<[Link]

Departamento Nacional de Planeación. (s.f.). Guía para la Elaboración y Presentación de

Historias de Usuario. Disponible en: <[Link]
%C3%B3n+oficial+historias+de+usuario+XP>.

122
 Referencias Bibliográficas

Historia de Usuario en XP – Metodologías Ágiles. (s.f.). Disponible en:

<[Link]
%C3%A1giles-desarrollo-software.zp068o4q>

123
 Referencias Bibliográficas

John Wiley & Sons, [Link], Kshirasagar y TRIPATHY, Priyadarshi. Software testing and quality
assurance: theory and practice. Hoboken:

Bödkker, S. (2021): Methods for User Interface Design. En: Bødker, S. User Interface Design:
Advice to the Designer. [en línea]. CRC Press. [Consulta: 8 julio 2025]. Disponible en:
[Link]

Tomita, K. (2015): Principles and elements of visual design: A review of the literature on visual
design of instructional materials. Educational Studies (Institute for Educational Research and
Service, International Christian University). [en línea]. [Consulta: 8 julio 2025]. Disponible en:
[Link]

Ordoñez, V.; Hilera, J.R.; Cueva, J.M. (2022): Accessibility engineering in web evaluation
process: a systematic literature review. Universal Access in the Information Society. [en línea].
Springer. [Consulta: 8 julio 2025]. Disponible en: [Link]
023-00967-2

Ramu, V.B. (2023): Performance Testing and Optimization Strategies for Mobile Applications.
International Journal of P2P Network Trends and Technology, vol. 13, núm. 2, pp. 1–6. [en línea].
[Consulta: 8 julio 2025]. Disponible en: [Link]
issue-2/[Link]

124
 Anexos

ANEXOS

Anexo 1: Guía de Observación para identificar tecnologías y herramientas en el

desarrollo de aplicaciones móviles Android.

Observador: Liannis Cabrera Expósito.

Lugar: Laboratorio de práctica profesional 204, Centro de Software Libre (CESOL).

Objetivo: Identificar y tomar notas sobre las principales tecnologías y herramientas

utilizadas por los especialistas en el desarrollo de aplicaciones Android y funcionalidades
en las aplicaciones creadas por estos.

Guía de Observación:

1. Aspectos técnicos (tecnologías y herramientas utilizadas)

 Se toma nota sobre los lenguajes de programación predominantes.
 Se listan los frameworks y bibliotecas utilizadas.
 Se enumeran las herramientas de desarrollo que se están utilizando.
 ¿Qué especialistas utilizan estas tecnologías y herramientas?

2. Funcionalidades y apariencia de las aplicaciones.

 Se toma nota sobre las principales características y funcionalidades de las aplicaciones
desarrolladas por los especialistas.
 ¿Cómo son visualmente las interfaces de usuario?
 ¿Cuáles son los problemas comunes enfrentados durante el desarrollo?
 Se anotan las soluciones y enfoques utilizados para resolver estos problemas.
 Anexos

Resultados de la observación:
Se identifica como predominante el lenguaje de programación Kotlin. Para la
implementación de las interfaces de usuario, XML (Lenguaje de Marcado Extensible) y el
framework Jetpack Compose, las herramientas y tecnologías Android SDK, Gradle, y el
entorno de desarrollo Android Studio.
De las aplicaciones desarrolladas por estos especialistas se identifican funcionalidades
como: menú desplegable en la barra superior, facilitando la navegación entre pantallas,
preferencias para el cambio de modos claro y oscuro, estas aplicaciones visualmente
siguen las directrices de Material Design con interfaces modernas y atractivas, tienen un
diseño responsive, que se adapta al tamaño y orientación de la pantalla el cual se verifica
probando la aplicación en diferentes dispositivos virtuales emulados mediante el Android
Studio.

Anexo 3: Encuesta SUS realizada a los usuarios tomados como muestra.

Cuestionario SUS

Por favor, evalúa cada una de las siguientes afirmaciones sobre el sistema que
has utilizado, utilizando la siguiente escala:

 1= Totalmente en desacuerdo
 2= En desacuerdo
 3= Ni de acuerdo ni en desacuerdo
 4= De acuerdo
 5= Totalmente de acuerdo

1. Me resulta fácil utilizar este sistema.

2. Encontré este sistema innecesariamente complejo.

 Anexos

3. Me gustaría que el sistema fuera más fácil de usar.

4. El sistema me resulta muy incómodo de usar.

5. Me resulta fácil aprender a utilizar este sistema.

6. Necesito apoyo técnico para aprender a utilizar este sistema.

7. Puedo manejar con facilidad todas las funcionalidades que se esperan de

este sistema.

8. Me siento muy seguro usando este sistema.

9. Es muy complicado utilizar este sistema.

10. Me gustaría utilizar este sistema con más frecuencia.

Anexo 4 Resultado de la encuesta realizada a los usuarios:

Puntuaciones otorgadas por los usuarios

Us P P P P P P P P P P T
ua- r r r r r r r r r r o
rio e e e e e e e e e e t
s g g g g g g g g g g a
u u u u u u u u u u l
n n n n n n n n n n
t t t t t t t t t t
a a a a a a a a a a
1 2 3 4 5 6 7 8 9 1
0
 Anexos

Us 5 5 4 4 3 3 3 2 2 2 3
ua- 0
rio
1
Us 5 5 5 5 4 3 3 2 2 1 3
ua- 1
rio
2
Us 5 5 5 5 4 4 3 3 2 2 3
ua- 3
rio
3
Us 5 3 5 2 4 4 3 5 5 1 3
ua- 1
rio
4
Us 1 2 2 3 3 4 5 5 5 5 3
ua- 0
rio
5

Puntuación otorgada por el usuario 1: 30 * 2.5 = 75

Puntuación otorgada por el usuario 2: 31 * 2.5 = 77
Puntuación otorgada por el usuario 3: 33 * 2.5 = 82
Puntuación otorgada por el usuario 4: 31 * 2.5 = 77
Puntuación otorgada por el usuario 5: 30 * 2.5 = 75
 Anexos

Promedio de las puntuaciones otorgadas por los usuarios

75+77+82+77+75 = 386 / 5 = 77