REPORTE FINAL DE SERVICIO

SOCIAL
PRESENTA
Emanuel Muñoz Santana

DOMICILIO

CORREO ELECTRÓNICO
– @hotmail.com

TELÉFONO PARTICULAR

CARRERA
Ingeniería en Sistemas Computacionales

MATRÍCULA

FECHA DE INICIO Y TERMINACIÓN DE SERVICIO SOCIAL

08 de Julio 2024 – 08 de Enero 2025

1
Desarrollo
Actividades realizadas
El presente reporte detalla las actividades realizadas durante el Servicio Social, las
cuales se centraron en el desarrollo de plataformas digitales y la implementación de
soluciones tecnológicas innovadoras. Este documento abarca las etapas de
levantamiento de requerimientos, análisis, diseño, programación, pruebas,
despliegue y mantenimiento de sistemas. Las actividades tuvieron como objetivo
principal satisfacer necesidades específicas de usuarios a quienes van a beneficiar,
a través de soluciones personalizadas y efectivas.

Plataforma web de encuestas a la medida

Se desarrolló una plataforma destinada a la evaluación de las barreras para la
adopción de energía renovable en México. Este proyecto comenzó con un análisis
detallado de requerimientos para identificar las necesidades clave del sistema.
Se contaba principalmente un archivo en Excel Interactivo el cual era enviado a los
encuestados individualmente, y posteriormente era regresado el mismo al remitente
una vez contestado, lo cual resultaba poco eficiente en cuanto al tiempo y
facilidades para recuperar los datos, al igual que dificultaba su respuesta dado al
empleo de macros, los cuales Microsoft Excel (en sus distintas versiones superior a
2007) categorizan como inseguros, bloqueándolos al momento y haciendo
inservible la encuesta.

Ilustración 1 - Archivo de Excel inicial de la encuesta que se enviaba a los encuestados y fue utilizado como
base

3
Para poder desarrollar las áreas de mejora de este proyecto, se optó por desarrollar
desde cero un sistema basado en web a la medida del funcionamiento del archivo
de Excel replicando/extrapolando su comportamiento, para poder organizar cada
apartado según los requerimientos y posteriormente poder recuperar la información
ya centralizada de una forma más fácil, sin comprometer la seguridad del usuario
encuestado ni tampoco pasar por el proceso de abrir el archivo de Excel, y volver a
enviarlo al remitente.

Requerimientos de software: Encuesta personalizada para la adopción

de energía renovable en México
Objetivo
Desarrollar un sistema personalizado basado en web para la recuperación de
encuestas sobre la adopción de energía renovable en México. Permitirá a los
encuestados evaluar diversos factores que influyen en su adopción presentando un
planteamiento y factores a medir dependiendo de su peso de acuerdo con la
preferencia del usuario, proporcionando resultados detallados que serán
gestionados desde un panel administrativo, en el cual se podrán descargar cada
uno de ellos individualmente (por encuestado), y generar cuentas de usuario con un
único destinatario previamente designado.
Requerimientos Funcionales
Autenticación de usuarios
• Implementará un sistema de login.
• Las cuentas de usuario y contraseñas serán generadas por el administrador
de forma aleatoria y se enviarán dichas credenciales al encuestado
designado.
• La información personal de cada usuario será confidencial. No se conocerán
nombres u otro dato vinculante.
• Poder redirigir a un usuario encuestado o administrador automáticamente
desde una única pantalla de login.
Base de datos
• Utilizará una base de datos SQL.
• Se calcularán los resultados desde un panel administrativo para su posterior
descarga.
• La información debe ser jerarquizada y emplear llaves foráneas para
maximizar su rendimiento y funcionalidad.

4
Gestión de usuarios
• El administrador asignará un tipo de sector a cada cuenta de usuario
utilizando un control select de Bootstrap.
• Los usuarios y contraseñas serán generados aleatoriamente y podrán ser
compartidos con los encuestados correspondientes según su sector.
• Del encuestado solo se conocerá su cuenta de usuario, contraseña y sector.
Respuestas a los reactivos
• La respuesta a cada reactivo estará delimitada por dos factores de acuerdo
con su peso.
• Se presentarán 17 factores que deben relacionarse entre sí basándose en la
experiencia del encuestado.
• El encuestado deberá responder a cada reactivo considerando dos factores,
con una barra de desplazamiento de acuerdo con su inclinación partiendo
desde cero en el centro. Si se mueve a la izquierda, marcará su preferencia
a un factor desde 0 a 100, y viceversa. Se recuperará la medida del factor
dominante y se insertará en la base de datos una única vez.
Ejemplo
Si usted considera que el Factor A incide más que el Factor B en la adopción de
Energía Renovable en México, deberá mover la barra gris hacia el lado izquierdo,
colocándola en el valor (de 0 a 100) en cuanto a la medida de la incidencia, en este
ejemplo es 40%

Ilustración 2 - Esquematización del sistema de ponderación de cada reactivo

5
Descarga de resultados
• En el panel administrativo se podrán descargar los resultados de respuestas
de cada encuestado de forma individual en un archivo XLS previamente
definido en una plantilla. A su vez, se podrá dar un seguimiento oportuno de
los encuestados que ya dieron una respuesta.
Resultados y Exportación
Cálculo de resultados
• Calcular los resultados desde un panel administrativo.
• Mostrar el factor dominante con el porcentaje seleccionado.
Exportación de datos
• Utilizar funcionalidades en PHP para exportar cada registro en formato para
MS Excel (XLS).
• Generar un archivo XLS por cada encuestado a partir de una plantilla
previamente establecida.
Finalización de la encuesta
• Mostrar una página de agradecimientos al finalizar la encuesta.
• Incluir una opción para cerrar sesión y no permitir volver a iniciar sesión.

Ilustración 3 - Esquemático de la interacción de un usuario encuestado

6
Requerimientos no funcionales
Seguridad
• Los datos personales y las respuestas de los usuarios deben ser manejados
de manera confidencial.
• Implementar medidas de seguridad en el almacenamiento de contraseñas
(hashing).
• Utilizar HTTPS para asegurar la transmisión de datos entre el cliente y el
servidor por la parte del servidor.
Escalabilidad
• Concurrencia prevista: El sistema debe ser capaz de manejar un gran
número de usuarios y respuestas sin pérdida de rendimiento.
Usabilidad
• La interfaz debe ser intuitiva y fácil de usar tanto para los encuestados como
para los administradores.
• Los encuestados responderán cada reactivo uno a la vez, confirmando su
inclinación con una barra de desplazamiento y un botón para pasar al
siguiente. Se hará el uso de acordeones para simplificar la interacción.
Rendimiento
• El sistema se debe cargar rápidamente y responder de manera ágil a las
interacciones del usuario.
Requerimientos específicos
Interfaz de Encuesta
Diseño de la encuesta
• Cada categoría corresponde a una página diferente a evaluar.
• Cada página mostrará la distribución de factores específica para cada
categoría.
• Usar un control de rango de Bootstrap para permitir a los usuarios ajustar el
porcentaje de incidencia de cada factor.
Indicaciones de rellenado
• Presentar 17 factores a relacionar con base en la experiencia del encuestado.
• Mostrar un control de rango para ajustar el porcentaje de incidencia de cada
factor, con un valor entre 0 y 100.

7
 • Mostrar el factor dominante con el porcentaje seleccionado.
Distribución de Categorías y Factores
Categorías contempladas
• Categoría 1 - Red_Conexion_A
• Categoría 2 - Personal_B
• Categoría 3 - Inf_Tec_C
• Categoría 4 - Madurez_D
• Categoría 5 - Costo_Prod_E
• Categoría 6 - Incentivo_Inicial_F
• Categoría 7 - Opinion_Comunidad_G
• Categoría 8 - Financiamiento_H
• Categoría 9 - Conciencia_I
• Categoría 10 - Politicas_J
• Categoría 11 - Cambio_Gob_K
• Categoría 12 - Pobreza_L
• Categoría 13 - Capacitacion_M
• Categoría 14 - Comunicacion_N
• Categoría 15 - Conflicto_Poder_O
• Categoría 16 - Interes_Social_P
• Categoría 17 - Cultura_Q_R
Descripción de los factores
• FACTOR A: Falta de redes de transmisión eléctrica en zonas con potencial
de producción de energías renovables.
• FACTOR B: Falta de personal formado en el desarrollo e implantación de
proyectos de energías renovables.
• FACTOR C: Falta de información técnica para el desarrollo y la ejecución de
proyectos de energías renovables.
• FACTOR D: Falta de diversificación de las energías renovables debido a la
madurez de cada tecnología

8
 • FACTOR E: Costo elevado de la generación de energía renovable en
comparación con los costes de producción de la energía convencional.
• FACTOR F: Falta de promoción de incentivos fiscales para invertir en
tecnologías de energías renovables
• FACTOR G: No tener en cuenta a las personas de las comunidades locales
• FACTOR H: Falta de subvenciones para financiar las energías renovables en
comparación con las fuentes tradicionales
• FACTOR I: Falta de concienciación entre los usuarios potenciales de la
tecnología debido a que las empresas dedican poco tiempo a concientizar
• FACTOR J: Política energética basada en los combustibles fósiles
• FACTOR K: Cambios en el gobierno y en las políticas gubernamentales
• FACTOR L: Los ingresos económicos y la pobreza de la población impiden
la implantación de energías renovables
• FACTOR M: Falta de programas formales de formación para personas en
este campo
• FACTOR N: Poca comunicación entre el gobierno, el sector privado y el
sector público
• FACTOR O: En ausencia de gobernanza, el poder se ejerce para poner en
marcha proyectos de energías renovables, sin tener en cuenta el contexto
sociocultural, generando conflictos y nuevos poderes.
• FACTOR P: Escasa participación e interés de la sociedad debido a la
incipiente información sobre proyectos de energías renovables
• FACTOR Q: La cultura mexicana no valora los beneficios medioambientales
de las energías renovables tanto como otros países.
• FACTOR R: Cambio de uso del suelo, fragmentación del paisaje y posibles
alteraciones de la fauna y la flora.
Tecnologías empleadas
Para el desarrollo de este sistema se consideran diversas tecnologías establecidas
en web, las cuales son de código abierto. Su uso comercial o institucional es
permitido sin ninguna regalía previa.
En este proyecto se han utilizado varios paquetes y tecnologías, cada uno con un
propósito específico:

9
1. PHP: Lenguaje de programación del lado del servidor utilizado para manejar la
lógica de negocio, interactuar con la base de datos y procesar las solicitudes del
cliente.
2. MySQL: Sistema de gestión de bases de datos relacional utilizado para
almacenar y gestionar la información de los usuarios, sectores y respuestas de
encuestas.
3. Bootstrap: Framework de CSS utilizado para diseñar y estilizar la interfaz de
usuario de manera responsiva y atractiva. En este proyecto, se utiliza la versión
4.5.2.
4. FontAwesome: Biblioteca de iconos que proporciona una amplia gama de iconos
vectoriales que se pueden personalizar con CSS. Se utiliza para mejorar la interfaz
de usuario con iconos visualmente atractivos.
5. DataTables: Plugin de jQuery que añade funcionalidades avanzadas a las tablas
HTML, como la paginación, búsqueda y ordenación. Se utiliza para gestionar y
mostrar información de manera eficiente.
6. Toastr: Biblioteca de notificaciones que permite mostrar mensajes emergentes
de manera elegante y no intrusiva. Se utiliza para proporcionar retroalimentación al
usuario sobre las acciones realizadas, como la creación o eliminación de usuarios,
y si las respuestas en cada reactivo de la encuesta se han almacenado de forma
correcta. También permite visualizar errores.
7. jQuery: Biblioteca de JavaScript que simplifica la manipulación del DOM, el
manejo de eventos y las solicitudes AJAX. Se utiliza para interactuar con el DOM y
realizar solicitudes asíncronas al servidor.
8. AJAX: Técnica de desarrollo web que permite actualizar partes de una página
web sin recargarla completamente. Se utiliza para enviar y recibir datos del servidor
de manera asíncrona, mejorando la experiencia del usuario.
9. HTML: Lenguaje de marcado utilizado para estructurar el contenido de las
páginas web. En este proyecto, se utiliza para crear la estructura básica de las
páginas de gestión de usuarios y formularios.
10. CSS: Lenguaje de hojas de estilo utilizado para describir la presentación de un
documento HTML. Se utiliza junto con Bootstrap para estilizar la interfaz de usuario.
11. JavaScript: Lenguaje de programación del lado del cliente utilizado para crear
interactividad en las páginas web. Se utiliza para manejar eventos, realizar
solicitudes AJAX y manipular el DOM.

10
12. Sesiones en PHP: Mecanismo de gestión de sesiones utilizado para mantener
el estado del usuario a lo largo de su interacción con la aplicación. Se utiliza para
verificar el acceso y permisos de los usuarios.
13. Password Hashing (BCRYPT): Algoritmo de cifrado utilizado para proteger las
contraseñas de los usuarios almacenadas en la base de datos. Se utiliza para cifrar
las contraseñas antes de almacenarlas, mejorando la seguridad de la aplicación.
Estas tecnologías y paquetes se combinan para crear esta solución de manera
robusta y segura, proporcionando una experiencia de usuario fluida y eficiente.
Requisitos para el software
• Almacenamiento en un servidor web (hosting proporcionado por un tercero o
equipo previamente adaptado para cumplir esta funcionalidad).
• Contar con apache o lighttpd.
• Disponer de acceso a internet o una red interna (localhost o intranet).
• Contar con un sistema gestor de base de datos (SGDB) MySQL o MariaDB.
Almacenamiento de datos
Debido a la estructura de los datos presentados, se desarrollará una base de datos
relacional para mantener integra la información.
Premisa:
Este sistema de encuestas debe permitir a los usuarios responder a una serie de
preguntas donde seleccionan entre dos factores usando un control deslizante para
indicar la preponderancia de un factor sobre otro. La base de datos debe almacenar
información de usuarios, factores, categorías y respuestas de encuestas.

Entidades y Atributos

Entidades Principales
• Usuario
o id_usuario (PK)
o usuario
o password
o sector
o check_respuesta (boolean)

11
 • Factor
o id_factor (PK)
o nombre_factor
o contenido_factor
• Categoría
o id_categoria (PK)
o nombre_categoria
• Encuesta
o id_encuesta (PK)
o id_usuario (FK)
o id_categoria (FK)
• Respuesta
o id_respuesta (PK)
o id_encuesta (FK)
o id_factor_1 (FK)
o id_factor_2 (FK)
o factor_dominante
o porcentaje_incidencia
Entidades Secundarias
• Sector
o id_sector (PK)
o nombre_sector

12
Ilustración 4 - Modelo relacional de las tablas que conforman la base de datos

Cardinalidad
1. Usuario se relaciona con Sector de muchos a uno (N:1)
2. Usuario se relaciona con Encuesta de uno a muchos (1:N)
3. Categoría se relaciona con Encuesta de uno a muchos (1:N)
4. Encuesta se relaciona con Respuesta de uno a muchos (1:N)
5. Factor se relaciona con Respuesta dos veces de mochos a muchos (N:N) a
través de los campos idfactor1 y idfactor2

Plan de Implementación
1. Fase 1: Recolección de Requerimientos y Análisis
o Reunión con las partes interesadas para definir los requerimientos
detallados.
o Análisis de los requerimientos y elaboración del documento de
requerimientos.

13
 2. Fase 2: Diseño
o Diseño de la arquitectura del sistema.
o Diseño de la base de datos.
o Diseño de la interfaz de usuario.
3. Fase 3: Desarrollo
o Desarrollo del backend y frontend.
o Integración de la base de datos.
o Implementación de funcionalidades de autenticación y gestión de
usuarios.
o Implementación de la lógica de las encuestas y el cálculo de
resultados.
4. Fase 4: Pruebas
o Pruebas de funcionalidad
o Pruebas de descarga e integridad de información.
5. Fase 5: Despliegue a producción
o Despliegue en el entorno de producción.
o Configuración de seguridad y rendimiento.

Todas las fases se han completado de forma satisfactoria.

El proyecto se ha liberado a manera de código abierto, para que otros usuarios
puedan tomarlo y adaptarlo a sus necesidades. En la presente sección se describirá
de forma verbal y/o explicita el funcionamiento interno (backend) de este software.

Descripción conceptual de la Base de Datos SQL

Se creó desde cero una base de datos conceptual, diseñada para almacenar datos
de encuestas de manera eficiente y garantizar su accesibilidad a partir del
funcionamiento de la encuesta en archivo Excel de origen, y los requerimientos
recuperados en las entrevistas.
A continuación, se describe en detalle la estructura y funcionamiento de cada una
de las tablas que componen la base de datos.

14
Tablas y sus relaciones

Tabla categoría
La tabla categoría almacena las diferentes categorías de factores que se evaluarán
en las encuestas.
• id_categoria: Identificador único de la categoría (clave primaria).
• nombre_categoria: Nombre de la categoría.
CREATE TABLE IF NOT EXISTS `categoría` (
`id_categoria` int NOT NULL AUTO_INCREMENT,
`nombre_categoria` varchar(50) COLLATE utf8mb3_unicode_ci
NOT NULL,
PRIMARY KEY (`id_categoria`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

Ejemplo de datos:
id_categoria nombre_categoria

1 Red_Conexion_A

2 Personal_B

3 Inf_Tec_C

Tabla encuesta
La tabla encuesta registra las encuestas realizadas por los usuarios y las categorías
a las que pertenecen.
• id_encuesta: Identificador único de la encuesta (clave primaria).
• id_usuario: Identificador del usuario que realizó la encuesta (clave foránea).
• id_categoria: Identificador de la categoría de la encuesta (clave foránea).

15
CREATE TABLE IF NOT EXISTS `encuesta` (
`id_encuesta` int NOT NULL AUTO_INCREMENT,
`id_usuario` int DEFAULT NULL,
`id_categoria` int DEFAULT NULL,
PRIMARY KEY (`id_encuesta`),
KEY `id_usuario` (`id_usuario`),
KEY `id_categoria` (`id_categoria`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

Ejemplo de datos:
id_encuesta id_usuario id_categoria

1 1 1
2 2 2
3 3 3

Tabla factor
La tabla factor almacena los factores que se evaluarán en las encuestas.
• id_factor: Identificador único del factor (clave primaria).
• nombre_factor: Nombre del factor.
• contenido_factor: Descripción del factor.

CREATE TABLE IF NOT EXISTS `factor` (

`id_factor` int NOT NULL AUTO_INCREMENT,
`nombre_factor` varchar(50) COLLATE utf8mb3_unicode_ci NOT
NULL,
`contenido_factor` text COLLATE utf8mb3_unicode_ci NOT NULL,
PRIMARY KEY (`id_factor`)

16
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

Ejemplo de datos:
id_factor nombre_factor contenido_factor

1 Falta de redes de transmisión Descripción detallada del factor

eléctrica 1.
2 Falta de personal formado Descripción detallada del factor
2.
3 Falta de información técnica Descripción detallada del factor
3.

Tabla respuesta
La tabla respuesta registra las respuestas de los encuestados a los factores
evaluados.
• id_respuesta: Identificador único de la respuesta (clave primaria).
• id_encuesta: Identificador de la encuesta a la que pertenece la respuesta
(clave foránea).
• id_factor_1: Identificador del primer factor evaluado (clave foránea).
• id_factor_2: Identificador del segundo factor evaluado (clave foránea).
• factor_dominante: Identificador del factor dominante (clave foránea).
• porcentaje_incidencia: Porcentaje de incidencia del factor dominante.

CREATE TABLE IF NOT EXISTS `respuesta` (

`id_respuesta` int NOT NULL AUTO_INCREMENT,
`id_encuesta` int DEFAULT NULL,
`id_factor_1` int DEFAULT NULL,
`id_factor_2` int DEFAULT NULL,
`factor_dominante` int NOT NULL,
`porcentaje_incidencia` decimal(5,2) NOT NULL,

17
 PRIMARY KEY (`id_respuesta`),
KEY `id_encuesta` (`id_encuesta`),
KEY `id_factor_1` (`id_factor_1`),
KEY `id_factor_2` (`id_factor_2`),
KEY `factor_dominante` (`factor_dominante`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

Ejemplo de datos:
id_respu id_encue id_facto id_facto factor_domin porcentaje_incid
esta sta r_1 r_2 ante encia

1 1 1 2 1 75.00
2 2 2 3 2 60.00
3 3 1 3 3 80.00

Tabla sector
La tabla sector almacena los diferentes sectores a los que pertenecen los usuarios.
• id_sector: Identificador único del sector (clave primaria).
• nombre_sector: Nombre del sector.

CREATE TABLE IF NOT EXISTS `sector` (

`id_sector` int NOT NULL AUTO_INCREMENT,
`nombre_sector` varchar(50) COLLATE utf8mb3_unicode_ci NOT
NULL,
PRIMARY KEY (`id_sector`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

18
Ejemplo de datos:
id_sector nombre_sector

1 Energía
2 Educación
3 Salud

Tabla usuario
La tabla usuario almacena la información de los usuarios que realizan las encuestas.
• id_usuario: Identificador único del usuario (clave primaria).
• usuario: Nombre de usuario.
• password: Contraseña del usuario.
• id_sector: Identificador del sector al que pertenece el usuario (clave
foránea).
• check_respuesta: Indicador de si el usuario ha respondido la encuesta
(booleano).
•

CREATE TABLE IF NOT EXISTS `usuario` (

`id_usuario` int NOT NULL AUTO_INCREMENT,
`usuario` varchar(50) COLLATE utf8mb3_unicode_ci NOT NULL,
`password` varchar(255) COLLATE utf8mb3_unicode_ci NOT NULL,
`id_sector` int DEFAULT NULL,
`check_respuesta` tinyint(1) DEFAULT '0',
PRIMARY KEY (`id_usuario`),
KEY `id_sector` (`id_sector`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3
COLLATE=utf8mb3_unicode_ci;

19
Ejemplo de datos:
id_usuario usuario password id_sector check_respuesta

1 user1 hashed_password_1 1 1

2 user2 hashed_password_2 2 0

3 user3 hashed_password_3 3 1

Restricciones y relaciones
Restricciones para la tabla encuesta
• encuesta_ibfk_1: Clave foránea que relaciona id_usuario con
usuario(id_usuario).
• encuesta_ibfk_2: Clave foránea que relaciona id_categoria con
categoría(id_categoria).

ALTER TABLE `encuesta`

ADD CONSTRAINT `encuesta_ibfk_1` FOREIGN KEY (`id_usuario`)
REFERENCES `usuario` (`id_usuario`),
ADD CONSTRAINT `encuesta_ibfk_2` FOREIGN KEY
(`id_categoria`) REFERENCES `categoría` (`id_categoria`);

Restricciones para la tabla respuesta

• respuesta_ibfk_1: Clave foránea que relaciona id_encuesta con
encuesta(id_encuesta).
• respuesta_ibfk_2: Clave foránea que relaciona id_factor_1 con
factor(id_factor).
• respuesta_ibfk_3: Clave foránea que relaciona id_factor_2 con
factor(id_factor).
• respuesta_ibfk_4: Clave foránea que relaciona factor_dominante con
factor(id_factor) con eliminación en cascada y actualización en cascada.

20
ALTER TABLE `respuesta`
ADD CONSTRAINT `respuesta_ibfk_1` FOREIGN KEY
(`id_encuesta`) REFERENCES `encuesta` (`id_encuesta`),
ADD CONSTRAINT `respuesta_ibfk_2` FOREIGN KEY
(`id_factor_1`) REFERENCES `factor` (`id_factor`),
ADD CONSTRAINT `respuesta_ibfk_3` FOREIGN KEY
(`id_factor_2`) REFERENCES `factor` (`id_factor`),
ADD CONSTRAINT `respuesta_ibfk_4` FOREIGN KEY
(`factor_dominante`) REFERENCES `factor` (`id_factor`) ON
DELETE CASCADE ON UPDATE CASCADE;

Restricciones para la tabla usuario

• usuario_ibfk_1: Clave foránea que relaciona id_sector con
sector(id_sector).

ALTER TABLE `usuario`

ADD CONSTRAINT `usuario_ibfk_1` FOREIGN KEY (`id_sector`)
REFERENCES `sector` (`id_sector`);

Funcionamiento de la base de datos

1. Categorías y Factores: Las categorías y factores se definen previamente y
se almacenan en las tablas categoría y factor.
2. Usuarios: Los usuarios se registran en la tabla usuario, asignándoles un
sector y generando credenciales de acceso.
3. Encuestas: Cuando un usuario completa una encuesta, se registra en la
tabla encuesta, vinculando al usuario y la categoría correspondiente.
4. Respuestas: Las respuestas de los usuarios a los factores evaluados se
almacenan en la tabla respuesta, registrando los factores comparados y el
factor dominante con su porcentaje de incidencia.
5. Relaciones: Las claves foráneas aseguran la integridad referencial entre las
tablas, garantizando que las relaciones entre usuarios, encuestas, factores y
categorías se mantengan consistentes.

21
La programación de la plataforma incluyó la creación de una interfaz de
administración para gestionar encuestas, resultados y usuarios. Se implementó la
funcionalidad de acordeones para organizar las encuestas y facilitar su navegación.
Además, se desarrollaron funcionalidades para exportar los resultados de los
encuestados a hojas de cálculo de Excel, permitiendo un análisis detallado por cada
usuario.

Ilustración 5 - Progreso de la programación de la plataforma

Se presentarán a continuación a detalle las interfaces de usuario desarrolladas para

ambos roles (administrador y encuestado) con todas sus funcionalidades.

22
Descripción de las pantallas del sistema
Login/Inicio de sesión
A partir de una única pantalla de inicio de sesión, tanto usuarios encuestados como
administradores podrán desempeñar sus actividades, facilitando la interacción con
el sistema.
Si un usuario encuestado no ha iniciado su encuesta o no la ha concluido, al iniciar
sesión, se le redirigirá a su pantalla correspondiente hasta terminar. Una vez
respondido el último reactivo, el campo check_respuesta en la tabla usuarios
dentro de la base de datos, se marcará como verdadero, significando que la
encuesta ha sido finalizada. Si el usuario encuestado vuelve a iniciar sesión, se hará
una validación adicional para únicamente redirigir a una página de agradecimiento.
Si un usuario es administrador del sistema, se redirigirá al momento a un dashboard
accesible únicamente por este rol, donde se podrán llevar a cabo las acciones
administrativas como crear nuevos usuarios encuestados o administradores,
descargar los resultados, visualizarlos en tiempo real, y modificar valores de los
reactivos a presentar a los usuarios encuestados.

Ilustración 6 - Flujo de interacción del inicio de sesión

23
La pantalla de inicio de sesión es accesible al momento que el usuario ingrese a la
dirección principal de la plataforma.

Ilustración 7 - Pantalla de login

Accediendo como administrador

El dashboard administrativo incluye todas las funcionalidades para la administración
de todas las variables y descarga/visualización en tiempo real de los resultados de
las encuestas. Estas funcionalidades son accesibles únicamente si una cuenta de
usuario en su campo id_sector es 1, debido a que lógicamente un usuario
administrador no está asociado a ningún sector asociado a un encuestado. Este
sector se encuentra establecido por defecto como admon.

Ilustración 8 - Página de #inicio para el Panel Administrativo

24
Gestión de usuarios
En esta vista, los administradores pueden gestionar las cuentas de los usuarios
encuestados. La tabla presenta una lista de usuarios con columnas que incluyen el
nombre de usuario, el sector al que pertenecen, si han respondido la encuesta y las
acciones disponibles para cada usuario.

Ilustración 9 - Página de Gestión de usuarios (#gestionUsuarios) para usuarios administradores

En la parte derecha de la pantalla, se encuentra un formulario para crear un nuevo

usuario. Los administradores pueden seleccionar el sector al que pertenecerá el
nuevo usuario y asignarle un tipo de usuario, ya sea "Encuestado" o
"Administrador". Esta funcionalidad permite una gestión eficiente y organizada de
los usuarios del sistema, facilitando el seguimiento y la administración de las
encuestas. Un usuario encuestado o administrador solo puede ser eliminado
(columna Acciones) únicamente si no ha respondido la encuesta, pudiendo dar la
oportunidad a generar correcciones en el caso que se haya creado una cuenta de
forma incorrecta, asociando su sector a uno no correspondiente. Por cuestiones de
las restricciones, las cuentas de usuario no pueden ser modificadas una vez
creadas.

Ilustración 10 - Sección para la creación de nuevos usuarios dependiendo de su tipo

25
En esta misma página, se crean los usuarios dependiendo del tipo de usuario a
considerar. Para conservar la privacidad, tanto las contraseñas como los nombres
de usuario para el inicio de sesión son generados de forma aleatoria mediante un
algoritmo.

Ilustración 11 - Detalles desplegados al momento de crear una nueva cuenta de usuario

Lógicamente, la creación de usuarios comienza con la selección del sector y el tipo

de usuario (encuestado o administrador) en un formulario. Al enviar el formulario, se
realiza una solicitud AJAX que envía los datos al servidor. El servidor recibe la
solicitud y verifica si el sector seleccionado es `admon`; si es así, obtiene el
`id_sector` correspondiente de la tabla `sector` en la base de datos. Luego, se
comprueba si el nombre de usuario ya existe en la base de datos. Si el usuario no
existe, se inserta un nuevo registro en la tabla de usuarios con el nombre de usuario,
la contraseña cifrada (usando BCRYPT) y el `id_sector` correspondiente. Si la
inserción es exitosa, se devuelve una respuesta indicando el éxito de la operación.
Finalmente, en el cliente, se muestra un modal con las credenciales del nuevo
usuario, permitiendo copiarlas y compartirlas con el destinatario. (Ilustración 11)
Esto está diseñado para que el texto generado se envíe por correo o mensajería
instantánea en el momento al destinatario, y simplifica el proceso de creación de
cuentas al no requerir más datos adicionales que los necesarios para organizar la
información de los resultados de las encuestas, sin comprometer datos personales.

26
Resultados de encuestas

Ilustración 12 - Página para la visualización de los resultados de cada encuesta activa relacionada a un usuario
encuestado de forma individual (#verResultados)

En esta vista, los administradores pueden ver el estado de las encuestas realizadas
por los usuarios. La tabla presenta una lista de encuestas con columnas que
incluyen el ID del usuario (gestionado de forma interna auto_increment en la
base de datos), el nombre de usuario, el sector al que pertenecen, el estado de la
encuesta y la barra de progreso.
Las acciones disponibles para cada encuesta incluyen ver el progreso y descargar
los resultados en formato Excel. La barra de progreso indica visualmente el avance
de cada encuesta, permitiendo a los administradores hacer un seguimiento visual
rápido del estado de las respuestas.
La ventana emergente que se abre al seleccionar la opción "Ver Progreso" en la
vista de "Resultados de Encuestas". Esta ventana presenta una tabla detallada con
el progreso de la encuesta de un usuario específico. La tabla incluye columnas para
los factores comparados, el porcentaje de incidencia de cada factor y el factor
dominante.
Esta funcionalidad permite a los administradores revisar en detalle las respuestas
de cada usuario, facilitando el análisis y la gestión de los datos recopilados.
Proporciona una vista clara y organizada del progreso de la encuesta, lo que es
esencial para la evaluación y el seguimiento de las respuestas.

27
Ilustración 13 - Ventana emergente visible al dar clic "Ver Progreso" por cada registro.

Ilustración 14 - Descarga de los archivos en Excel con las respuestas de cada encuesta con el formato solicitado
en los requerimientos, una vez que se haya terminado por completo

Modificar factores
En esta vista, los administradores pueden gestionar y editar el contenido de los
factores disponibles en el sistema de encuestas. La tabla presenta una lista de
factores con columnas que incluyen el ID del factor, el nombre del factor y su
contenido descriptivo.

28
Ilustración 15 - Página para la visualización y edición de Factores que se muestran a evaluar en la encuesta
(#gestionarFactores)

Cada factor tiene un botón "Editar" asociado, que permite a los administradores
modificar el contenido descriptivo del factor. Al hacer clic en este botón, se abre una
ventana modal donde se puede cambiar únicamente el contenido que describe al
factor en específico.

Ilustración 16 - Ventana modal en #gestionFactores que permite modificar el contenido/descripción de cada

factor. Su nombre no puede ser modificado.

Esta ventana contiene un campo de texto prellenado con el contenido actual del
factor seleccionado.

29
Los administradores pueden modificar este contenido y guardar los cambios,
asegurando que la descripción del factor refleje correctamente el criterio a evaluar
en la encuesta. Esta capacidad de edición es crucial para adaptar el sistema a
nuevas necesidades o ajustes en los criterios de evaluación.
La funcionalidad permite a los administradores mantener actualizada y precisa la
información de los factores, asegurando que las encuestas sean claras y relevantes
para los encuestados.
Actualizar Sectores
En esta vista, los administradores pueden gestionar los sectores a los cuales se
asocian los usuarios encuestados. La tabla presenta una lista de sectores con
columnas que incluyen el ID del sector y el nombre del sector.

Ilustración 17 - Página para la actualización de los Sectores disponibles, además de su creación o eliminación
(#gestionSectores)

Las acciones disponibles para cada sector incluyen editar y eliminar. Además, hay
un botón "Agregar Sector" que permite a los administradores añadir nuevos sectores
a la lista. Al seleccionar cualquiera de estas acciones, se abren ventanas modales
que facilitan la gestión de los sectores.
Se tienen excepciones tales como no permitir su eliminación en el caso que se
encuentren relacionados con alguna clase de usuario, por cuestiones de integridad
de la información y normalización de la base de datos generada de acuerdo a los
requerimientos recuperados.

30
Ilustración 18 - Ventana modal activada al opimir el botón "Agregar Sector" para incorporar este nuevo dato para
su uso.

Esta funcionalidad es esencial para mantener actualizada la información de los

sectores y asegurar que los usuarios encuestados estén correctamente
categorizados, lo que facilita el análisis y la gestión de los datos recopilados en las
encuestas. Estos Sectores se asignan en una lista desplegable (Ilustración 10) a los
usuarios encuestados que se pueden crear.
Cambiar Categorías
En esta vista, los administradores pueden modificar los nombres de las categorías
que se utilizarán en la encuesta. La tabla presenta una lista de categorías con
columnas que incluyen el ID y el nombre de cada categoría, junto con un botón de
acción para editar.

31
Ilustración 19 - Página para cambiar los nombres de las categorías mostradas en la encuesta
(#gestionCategorias)

Al hacer clic en el botón "Editar" de cada registro, se abre una ventana modal que
permite al administrador cambiar el nombre de la categoría seleccionada. Esta
funcionalidad permite personalizar las categorías de la encuesta sin añadir o
eliminar las existentes, asegurando que la estructura de la encuesta se mantenga
intacta mientras se adaptan los nombres según sea necesario.
Esta vista es esencial para mantener la relevancia y claridad de las categorías en la
encuesta, facilitando una mejor comprensión y participación de los encuestados.
Accediendo como usuario encuestado
Cuando un usuario encuestado accede a la plataforma una vez y sus credenciales
se le hayan entregado, antes de acceder a los reactivos, tendrá que leer una serie
de indicaciones (extrapoladas del archivo de Excel original) para responder de
manera adecuada todos los reactivos, que se mostrarán una vez que el usuario
deslice hasta abajo para dar clic en el botón “Comenzar Encuesta”

32
Ilustración 20 - Página de apertura a la encuesta visible para cualquier usuario encuestado que inicie sesión
(encuesta.php)

En la parte inferior se mantiene una barra de progreso la cual incrementará de forma

gradual conforme se avance en la encuesta entre categorías y la cantidad de
reactivos contestados, que no es necesario que se lleven un orden concreto.
Se desplazará entre categorías de forma automática una vez que se hayan
completado todos los reactivos correspondientes.

Ilustración 21 - Página correspondiente a una categoría en específico al momento de responder la encuesta y

sus reactivos correspondientes (encuesta.php#respondiendoEncuesta)

33
Flujo detallado de procesos para contestar la encuesta
1. Inicio de Sesión como Encuestado: El usuario inicia sesión en la plataforma.
2. ¿Encuesta Finalizada?: Se verifica si la encuesta ya ha sido completada.
• Sí: Si la encuesta está finalizada, el usuario es redirigido a la Página
de Agradecimientos.
• No: Si la encuesta no está finalizada, el usuario es redirigido a
la Categoría Actual donde dejó de responder.
3. Redirigir a Categoría Actual: El usuario es llevado a la categoría donde dejó
de responder.
4. ¿Reactivo Completado?: Se verifica si el reactivo actual ha sido completado.
• Sí: Si el reactivo está completado, se verifica si ¿Todos los Reactivos
Completados en la Categoría?.
• No: Si el reactivo no está completado, se muestra el Siguiente
Reactivo.
5. ¿Todos los Reactivos Completados en la Categoría?: Se verifica si todos los
reactivos de la categoría actual han sido completados.
• Sí: Si todos los reactivos están completados, se verifica si ¿Es la
Última Categoría?.
• No: Si no todos los reactivos están completados, se muestra
el Siguiente Reactivo.
6. ¿Es la Última Categoría?: Se verifica si la categoría actual es la última.
• Sí: Si es la última categoría, se Finaliza la Encuesta.
• No: Si no es la última categoría, se pasa a la Siguiente Categoría.
7. Pasar a la Siguiente Categoría: El usuario es redirigido a la siguiente
categoría y el proceso se repite desde la Categoría Actual.
8. Finalizar Encuesta: La encuesta se marca como completada y el usuario es
redirigido a la Página de Agradecimientos.
9. Página de Agradecimientos: Se muestra una página de agradecimientos al
usuario.

34
 10. Cerrar Sesión: El usuario tiene la opción de cerrar sesión en cualquier
momento.
• Sí: Si el usuario da clic en el botón ‘Cerrar Sesión’, se realiza el cierre
de la sesión activa y redirecciona al login.
• No: Si el usuario no elige cerrar sesión, continúa en la Categoría
Actual.

Ilustración 22 - Diagrama de flujo para la apertura de la encuesta por parte de usuarios encuestados.

35
Material de apoyo generado
Para distribuir a los usuarios encuestados, o delegar administradores adicionales,
se redactaron y crearon tutoriales en video que explican a detalle el funcionamiento
de la plataforma.
Software empleado
- Camtasia Studio 9 (edición de video)
- Microsoft Clipchamp (para TTS)

Ilustración 23 - Captura de pantalla mostrando la linea del tiempo de un video en edición

Este material fue concluido y cargado a YouTube para que su accesibilidad siempre
esté garantizada, estando disponible en los siguientes enlaces:
- Manual de usuario para usuarios encuestados :
https://www.youtube.com/watch?v=RL7FQf00rYg
- Manual de usuario para usuarios administradores :
https://www.youtube.com/watch?v=ioLc6hjn8_4
Cierre del proyecto
El proyecto fue finalizado exitosamente y puesto en producción, donde se le dio
mantenimiento a lo largo del periodo vigente del servicio social, con acciones tales
como solución de bugs menores y mantenimiento del servidor en funcionamiento
para otorgar una gran disponibilidad con la investigación en uso cuyos datos serán
empleados. Su periodo de desarrollo activo abarcó dos meses.

36
Creación de formulario para recuperar datos personales de
alumnos de nuevo ingreso

Premisa
Dado a la apertura del semestre Agosto - Diciembre 2024, se tenía la necesidad en
la división de Ingeniería en Energías renovables el adquirir información de contacto
y datos personales principales de los alumnos de nuevo ingreso para la carrera. Por
ello, se realizó la elaboración de una encuesta la cual los alumnos contestarían una
única vez, que tuviera buena presentación, y un manejo fácil para los usuarios.
Para cumplir con este requisito, se optó por usar Microsoft Forms, una solución
gratuita (alternativa a Google Forms) para generar formularios de una manera
sencilla y que resulten atractivos.

Ilustración 24 - Captura de pantalla de la encuesta final desplegada (portada)

Para poder recuperar toda la información requerida para conocer a los alumnos, se
elaboraron una serie de planteamientos divididos en secciones, abarcando desde
datos personales, escuela de preferencia, especialidad cursada, sustento
económico, conocimientos principales y preferencia de la carrera, lugar de
residencia, y presupuestos. Con estos datos, se da apertura a poder ofrecer ayuda
u orientación según sea requerido de forma personalizada.
Se consideraron respuestas abiertas cortas y de selección múltiple.

37
Planteamientos

38
39
40
Resultados
Se pudieron abarcar la mayoría de los alumnos de nuevo ingreso y los datos
recuperados fueron de gran ayuda para conocer tanto sus preferencias y aptitudes
de la carrera, como también tomar medidas para ayudarlos según sea requerido.

41
Se abarcó un total de 14 alumnos, y la encuesta estuvo activa durante Agosto y
Septiembre del 2024.

Ilustración 25 - Extracto del reporte final de las respuestas

Ilustración 26 - Extracto del archivo en Excel con todas las respuestas generadas con filtros

La actividad fue finalizada de manera exitosa.

42
Microaplicación web para el cálculo de biodigestores

Antecedentes
Para obtener diversos datos calculados a partir de una serie de fórmulas, en la
división de Ingeniería en Energías Renovables del Instituto Tecnológico Superior de
Huichapan, en conjunto con la empresa AIPIR GRUPO PROYECTOS VERDES
desarrollaron una solución, que a partir de una serie de datos de entrada otorgaba
diversos datos precisos para establecer parámetros de diseño para un biodigestor.
Al igual que el proyecto anterior, este tenía áreas de mejora a considerar y
problemáticas en su ejecución, debido a que se construyó en una hoja de Excel con
macros programados en Visual Basic y un formulario, dificultando su mantenimiento,
escalabilidad, implementación de nuevas funcionalidades, en conjunto a su
ejecución ya que los macros son categorizados como inseguros, susceptibles a
infiltración de malware e incompatibilidades cuando se abre el archivo en distintos
sistemas operativos o versiones de Microsoft Office.

Ilustración 27 - Captura de pantalla con la solución existente que se tomó como base

Por estas razones detectadas, se recuperó este proyecto existente, y se comenzó

a la elaboración de una nueva solución la cual optaría a construirse nuevamente,
pero en una aplicación web, accesible desde el navegador, prescindiendo de usar
Excel para realizar estos cálculos de una manera más conveniente, accesible desde
cualquier dispositivo con internet y un navegador actualizado.

43
Propuesta la actividad, comenzó la creación de un nuevo documento de
requerimientos preliminares para desarrollar este nuevo software teniendo como
base el existente, añadiendo una serie de mejoras para hacerlo mucho más
funcional y que pueda cumplir las necesidades donde se emplee a mediano plazo.

Requerimientos de software: Microaplicación web para el cálculo de

biodigestores

Descripción General del Software

Software basado en web hecho para facilitar el diseño y dimensionamiento de
biodigestores tipo hongo. La herramienta permite calcular las dimensiones óptimas
y la producción de biogás en base a datos específicos proporcionados por el
usuario.
Alcance del Proyecto
• Desarrollo de una interfaz web intuitiva y responsiva.
• Implementación de algoritmos de cálculo precisos para determinar las
dimensiones y características de los biodigestores.
• Generación de informes simplificados con ilustraciones esquemáticas del
biodigestor diseñado.
• Inclusión de funcionalidades como descarga de resultados en PDF y
visualización de esquemas dinámicos.
Público Objetivo
• Agricultores interesados en implementar sistemas de biodigestión en sus
explotaciones.
• Estudiantes y profesionales del sector ambiental y energético.
• Organizaciones que promueven el uso de energías renovables.
• Interesados en conocer los beneficios y el diseño de biodigestores para una
implementación adecuada.
Uso Previsto
La herramienta apoya el proceso de diseño de biodigestores permitiendo el ingreso
de parámetros específicos como:
• Número de vacas.
• Cantidad diaria de excreta por animal.
• Relación estiércol/agua.

44
 • Altura del cilindro.
• Tiempo de residencia.
Los usuarios obtendrán cálculos detallados y podrán adaptarlas a su
implementación.
Componentes Principales
1. Interfaz de Usuario: Diseño basado en HTML, CSS y Bootstrap, con
validación dinámica mediante JavaScript. (Ilustración 25)
1. Presentación de diapositivas: De acuerdo con los requerimientos,
incluir en la cabecera una presentación de diapositivas con imágenes
representativas a biodigestores, que se ejecutará mientras el usuario
tenga activa la página, empleando la librería de JavaScript ‘Vegas’.
2. Formulario: Campos de entrada de texto para ingresar
obligatoriamente todos los datos que posteriormente serán empleados
para devolver los resultados una vez tratados.
2. Lógica de Cálculo: Implementada en PHP para procesar los datos
ingresados y realizar los cálculos correspondientes.
3. Visualización de Resultados: Generación de una ilustración con las
medidas de forma representativa y devolución de los cálculos regresados en
una tabla.

Ilustración 28 - Esquema preliminar de la primera propuesta de interfaz de usuario

45
Funcionalidades Específicas
Entrada de Datos
1. Número de Vacas: Cantidad total de animales.
2. Excreta Diaria: Rango de 25 a 45 kg por animal.
3. Relación Estiércol/Agua: Opciones de 2:1 o 3:1.
4. Tiempo de Residencia: Rango de 20 a 40 días.
5. Altura del Cilindro: Opciones de 1.2m o 1.5m.
Cálculos Realizados
1. Volumen de Mezcla: Calculado con base en la excreta total y la relación
estiércol/agua.
2. Volumen del Biodigestor: Determinación del volumen óptimo considerando
el tiempo de residencia.
3. Producción de Biogás: Estimación basada en un factor promedio de
producción por kilogramo de excreta.
4. Dimensiones del Biodigestor: Cálculo del radio, diámetro y altura de la
cúpula.
5. Esquema Gráfico: Generación de un diagrama representativo con
proporciones reales.
Objetivos del Sistema
• Proveer una herramienta accesible y precisa para el dimensionamiento de
biodigestores.
• Automatizar los cálculos necesarios para el diseño de biodigestores tipo
hongo.
• Facilitar la interpretación de resultados mediante visualizaciones gráficas.
• Simplificar la toma de decisiones para agricultores, estudiantes y
profesionales.

46
Requerimientos Funcionales
1. El usuario ingresará datos relacionados con el número de vacas, excreta
diaria, tiempo de residencia y altura del cilindro.
2. La microaplicacioón calculará:
o Volumen total del biodigestor.
o Producción de biogás diaria.
o Dimensiones específicas del biodigestor (radio, diámetro y altura).
o Restricciones de los datos de entrada por cada campo de texto
definidas por parte del solicitante de esta solución.
3. Los resultados incluirán visualizaciones gráficas y su descarga.
4. El sistema no almacenará datos y será totalmente funcional sin necesidad de
registro o inicio de sesión.

Ilustración 29 - Interacción entre usuario y sistema

47
Requerimientos No Funcionales
1. La interfaz debe ser intuitiva y accesible en navegadores modernos.
2. Los cálculos deben completarse en menos de 2 segundos.
3. La herramienta será responsiva y compatible con dispositivos móviles.
4. La documentación del software incluirá:
o Fórmulas utilizadas.
o Funcionalidades.
Tecnologías y Herramientas Utilizadas
Frontend
• HTML5
• CSS3
• JavaScript (ES6+)
• Bootstrap 5.3.0-alpha1
• jQuery 3.5.1
Backend
• PHP
o GD Library (para generación de imágenes)
Cambios Finales Incorporados
• Adaptación exclusiva para biodigestores tipo hongo.
Consideraciones Finales
Se busca democratizar el acceso a herramientas de cálculo en el ámbito de la
biodigestión, promoviendo la sostenibilidad y el aprovechamiento eficiente de
residuos orgánicos. Su diseño enfocado en la usabilidad y precisión lo convierte en
una opción ideal para agricultores, profesionales y entusiastas.

Análisis Detallado de Fórmulas del Biodigestor

1. Datos de Entrada
• $numeroAnimales: Cantidad de animales

• $cantidadExcreta: Kg de excreta por animal/día (25-45kg)

• $tiempoResidencia: Días de retención (20-40 días)

• $relacionEstiercolAgua: Proporción agua:estiércol (1:2 o 1:3)

48
 • $alturaCilindro: Altura del cilindro (1.2m o 1.5m)

2. Fórmulas Paso a Paso

2.1 Excretas Totales (kg/día)

$excretasTotales = $numeroAnimales * $cantidadExcreta;
• Ejemplo: 10 vacas × 30 kg = 300 kg/día

2.2 Volumen de Mezcla (m³)

$volumenMezcla = (($excretasTotales * $relacionEstiercolAgua)
+ $excretasTotales) / 1000;
• Si relación es 1:2
• Ejemplo: ((300 kg × 2) + 300 kg) / 1000 = 0.9 m³
• División por 1000 convierte de litros a m³

2.3 Volumen del Cilindro (m³)

$volumenCilindro = $volumenMezcla * $tiempoResidencia;
• Ejemplo: 0.9 m³ × 30 días = 27 m³

2.4 Volumen de Gas (m³)

$volumenGas = $excretasTotales * 0.035;
• Factor 0.035: producción de gas por kg de excreta
• Ejemplo: 300 kg × 0.035 = 10.5 m³ de gas/día

2.5 Volumen de Cúpula (m³)

$volumenCupula = $volumenCilindro * 0.45;

• 45% del volumen del cilindro

• Ejemplo: 27 m³ × 0.45 = 12.15 m³

49
2.6 Radio y Diámetro (m)
$radio = sqrt($volumenCilindro / (pi() * $alturaCilindro));
$diametro = $radio * 2;
• Fórmula derivada de V = πr²h
• Ejemplo: Si h=1.5m, r = √(27/(π×1.5)) = 2.39m

2.7 Altura de Cúpula (m)

$alturaCupula = $radio / 3;

• Relación estándar para cúpulas

• Ejemplo: 2.39m / 3 = 0.80m

2.8 Volumen Final Total (m³)

$volumenFinal = $volumenCilindro + $volumenCupula;

• Suma del volumen total

• Ejemplo: 27 + 12.15 = 39.15 m³

3. Consideraciones Importantes
• Todas las medidas están en sistema métrico
• Los volúmenes se expresan en metros cúbicos (m³)
• Las longitudes en metros (m)
• Las excretas en kilogramos (kg)
• Factor de gas (0.035) basado en promedios experimentales
• Relación de cúpula (0.45) es un estándar de diseño

Descripción de la microaplicación

Flujo Principal de la Aplicación

1. El sistema inicia con index.php como punto de entrada

50
2. Se carga la presentación de diapositivas con la librería Vegas para el fondo
dinámico
3. Se inicializa el iframe con la calculadora (aislada con motivos de desarrollo y
escalabilidad)
4. Se espera a que el usuario ingrese los datos. Si estos son válidos, se enviarán al
backend.
5. Una vez procesados los datos, se generará la imagen ilustrativa de las medidas
del biodigestor y se regresarán los resultados al frontend para que el usuario pueda
visualizarlos, corregir los datos ingresados y volver a calcularlos.

Ilustración 30 - Apertura y procesos principales de la microaplicación

51
Desarrollo del proyecto
Una vez recuperados los requerimientos de software y estudiado el archivo de Excel
como base, se tomaron las fórmulas para obtener los cálculos a partir de los datos
de entrada (embebidas en ese proyecto) para extrapolarlas en el nuevo código.

Ilustración 31 - Captura de pantalla de la programación de la microaplicación en curso

Su funcionamiento se divide en dos segmentos (acordeones), el primero “Ingresar

Datos” para escribir los datos en cada campo de texto con las validaciones
requeridas para que todos los campos sean obligatorios, y el segundo de resultados
el cual se apertura de forma automática una vez y los cálculos se hayan realizado.

Ilustración 32 - Captura de pantalla con la entrada de datos vacía

Cuando se da clic en el botón “Calcular” (cuyo se activa cuando todos los campos
de entrada estén rellenos) se apertura el acordeón “Resultados de Cálculo” con los

52
resultados y la imagen representativa con las dimensiones del biodigestor, la cual
se puede descargar al momento.

Ilustración 33 - Captura de pantalla con los datos devueltos

Durante su desarrollo, se establecieron valores cerrados entre un rango para poder

garantizar valores más acercados a la realidad reflejados en los valores finales y el
gráfico generado con ellos.
Puesta en producción
Finalizado, se subió a un hosting web gratuito para poder ser consumido de manera
preliminar por personas especializadas para obtener una retroalimentación de la
funcionalidad de esta microaplicación y posteriormente adecuarla a los próximos
requerimientos que se generasen.
Fue presentado a un representante de la empresa AIPIR GRUPO PROYECTOS
VERDES obteniendo una recepción positiva. Debido a cuestiones de tiempo y
disponibilidad quedó pendiente el continuar la conversación con otros
representantes debido a su poca disponibilidad de tiempo.
Empleando las redes sociales, se realizó su difusión con personas de acuerdo con
el perfil donde se encamina la microaplicación para obtener retroalimentación
adicional y dar apertura para continuar su desarrollo, con la finalidad de otorgar una
funcionalidad completa, funcional y que sea de ayuda para mejorar la eficiencia en
la toma de decisiones para diseñar un biodigestor del tipo hongo de acuerdo con su
contexto.

53
Ilustración 34 - Captura de pantalla de la distribución de la microaplicación en un grupo de Facebook con
temática de Biodigestores

El desarrollo de una versión preliminar completamente funcional de esta actividad

fue finalizado con éxito y actualmente se encuentra disponible para su uso en el
siguiente enlace:
- https://drift3.alwaysdata.net/calculadoraBiodigestor/
La dirección web presente en este documento es provisional y está sujeta a
cambios. Es probable que a mediano plazo sea migrado a otro hosting/servicio.

54
Plataforma web para la distribución y redacción de artículos
científicos y académicos.

Introducción
En la actualidad, la difusión de artículos científicos y académicos enfrenta barreras
que dificultan el acceso a la información y la participación activa en la generación
de conocimiento. La mayoría de las plataformas existentes están diseñadas
exclusivamente para la consulta de materiales, limitando la posibilidad de que
cualquier persona pueda contribuir con sus ideas y perspectivas. Estas restricciones
excluyen a individuos sin afiliaciones académicas formales, perpetuando un entorno
donde el conocimiento queda relegado a grupos cerrados.
La necesidad de una herramienta accesible, inclusiva y funcional surge para
democratizar el proceso de creación, revisión y publicación de artículos científicos.
Una plataforma que permita tanto a expertos como a principiantes redactar y
compartir sus investigaciones, obtener retroalimentación en tiempo real y generar
materiales de calidad profesional, con todas las herramientas integradas en un solo
lugar, podría transformar radicalmente la manera en que el conocimiento es creado
y distribuido.
Premisa
La carencia de un espacio accesible y abierto para la creación y difusión de artículos
científicos y académicos limita el alcance del conocimiento a círculos cerrados y
exclusivos. Esto plantea la oportunidad de desarrollar una plataforma web inclusiva
y fácil de usar, diseñada para que cualquier persona, independientemente de su
experiencia o cargo, pueda contribuir al desarrollo y la distribución de nuevo
conocimiento. Esta plataforma permitiría a los usuarios redactar, revisar y publicar
artículos científicos o académicos, brindando herramientas accesibles para el
aprendizaje colaborativo y la divulgación científica sin barreras.
Planteamiento de la Plataforma
Para poder encaminar su desarrollo, se realizaron una serie de sesiones con el
solicitante de esta herramienta para empezar a esbozar las primeras ideas e
impresiones del propósito y elementos que la conformarían. (Ilustración 44)
Se generó una serie de lluvia de ideas para verificar la viabilidad del proyecto, y los
puntos principales que se deberían respetar a lo largo del desarrollo de proyecto.

55
Ilustración 35 - Extracto de los planteamientos para el desarrollo del proyecto en la primera sesión de la
entrevista para generar los requerimientos de software

La plataforma propuesta se conceptualiza como un espacio abierto para la

redacción, revisión y publicación de artículos científicos y académicos. Se diseñaría
para que cualquier persona, sin importar su experiencia o afiliación, pueda contribuir
al conocimiento global de manera profesional y estructurada. Entre las principales
características se incluyen:
• Redacción integral: Herramientas accesibles para escribir artículos
científicos desde cero, incluyendo cuadros de texto configurables y opciones
de formato estandarizado.
• Revisión colaborativa: Funcionalidades para recibir comentarios de
revisores, editores y otros usuarios que fomenten la mejora continua de los
artículos.

56
 • Generación de portadas: Opciones para diseñar portadas atractivas y
profesionales para cada artículo, destacando su relevancia y contenido.
• Distribución digital: Los artículos podrán descargarse en formato PDF o
visualizarse en un lector inmersivo dentro de la plataforma.
• Interactividad social: Espacios para que otros usuarios puedan comentar,
compartir sus ideas y retroalimentar las publicaciones, creando una
comunidad de aprendizaje colaborativo.
Estado del arte
El desarrollo de esta plataforma toma inspiración y aprendizaje de otras iniciativas
y herramientas, analizando sus fortalezas y limitaciones para construir una solución
innovadora. Se partió como base el enfoque en revistas ya que la metodología a
emplear en su distribución es la más cercana a comparación de un artículo
completamente científico:
1. Portal de Revistas de la UNAM
La Universidad Nacional Autónoma de México (UNAM) ofrece un portal que alberga
una amplia colección de revistas científicas y académicas en diversas áreas del
conocimiento. Este portal facilita el acceso a artículos de investigación y contribuye
significativamente a la difusión del conocimiento en México.
Disponible en: https://revistas.unam.mx/catalogo/
2. Redalyc (Red de Revistas Científicas de América Latina y el Caribe, España
y Portugal)
Redalyc es un sistema de información científica que integra revistas de acceso
abierto, promoviendo la visibilidad de la producción científica en Iberoamérica.
Aunque permite la consulta gratuita de artículos, no ofrece herramientas integradas
para la creación o revisión de contenidos por parte de los usuarios.
Disponible en: https://www.redalyc.org/
3. SciELO México
SciELO México es una hemeroteca virtual que reúne una colección de revistas
mexicanas de todas las áreas del conocimiento. Desarrollada por la Dirección
General de Bibliotecas y Servicios Digitales de Información de la UNAM, facilita el
acceso abierto a artículos científicos, pero no proporciona funcionalidades para la
creación o edición de contenidos por parte de los usuarios.
Disponible en: https://www.scielo.org.mx/scielo.php

57
4. Portal de Revistas Científicas y Académicas de la Universidad Autónoma de
Zacatecas
Este portal alberga diversas revistas especializadas en áreas como ciencias
jurídicas, sociales y de la salud, entre otras. Aunque facilita el acceso a contenidos
académicos, no ofrece funcionalidades para la creación o edición de artículos por
parte de los usuarios.
Disponible en: https://revistas.uaz.edu.mx/
5. Saber Más - Revista de Divulgación Científica de la Universidad Michoacana
de San Nicolás de Hidalgo
"Saber Más" es una revista de divulgación científica y tecnológica editada por la
Universidad Michoacana de San Nicolás de Hidalgo, a través de la Coordinación de
la Investigación Científica. Su objetivo es acercar el conocimiento científico a la
sociedad, presentando artículos en un lenguaje accesible para el público general.
Sin embargo, su modelo se centra en la difusión de contenidos elaborados por
académicos y expertos, sin ofrecer herramientas para que el público en general
pueda redactar, revisar o publicar sus propios artículos.
Disponible en: https://www.sabermas.umich.mx
6. SlideShare y Scribd
SlideShare es una plataforma que permite a los usuarios compartir presentaciones
en diversos formatos, como PowerPoint y PDF. Es útil para almacenar, distribuir y
administrar presentaciones en la web con un apartado social mínimo.
Por su parte, Scribd es una biblioteca digital que alberga una amplia variedad de
documentos, incluyendo libros electrónicos, audiolibros, revistas y más. Los
usuarios pueden subir y compartir documentos, facilitando el acceso a una vasta
colección de contenidos.
Recuperamos ambas ya que su apartado social, apariencia y funcionalidades se
acercan al enfoque que se estaría trabajando en el desarrollo de esta nueva
solución.
Disponibles en: https://es.slideshare.net/ & https://es.scribd.com/home
Análisis Comparativo
Las plataformas mencionadas desempeñan un papel crucial en la difusión del
conocimiento científico y académico, ofreciendo acceso a una amplia gama de
publicaciones y presentaciones. Sin embargo, comparten una limitación común: se
enfocan principalmente en la consulta y compartición de contenidos ya elaborados,
sin proporcionar herramientas integradas que permitan a los usuarios crear, revisar
y publicar sus propios artículos científicos dentro de la misma plataforma.

58
Diferenciación de la Plataforma Propuesta
La plataforma propuesta busca superar estas limitaciones al ofrecer un entorno
integral donde los usuarios puedan:
• Redactar artículos científicos utilizando herramientas de edición
especializadas.
• Revisar y recibir retroalimentación de otros miembros de la comunidad en
tiempo real.
• Generar portadas y formatos profesionales para sus publicaciones.
• Interactuar socialmente mediante comentarios y discusiones, fomentando
una comunidad colaborativa y dinámica.
Al integrar estas funcionalidades en un solo espacio, la plataforma no solo facilitará
el proceso de creación y publicación de artículos científicos, sino que también
promoverá la inclusión y participación de una comunidad más amplia en la
generación y difusión del conocimiento académico.

Requerimientos de Software preliminares de la Plataforma

para la redacción y publicación de artículos científicos y
académicos.
Fecha de corte: septiembre – octubre 2024 – Algunos datos pueden estar incompletos o no
ser fieles al producto final dadas a las iteraciones establecidas en su desarrollo.

Descripción del proyecto

Plataforma basada en web para la publicación y lectura de revistas y publicaciones
de carácter científico y divulgativo, ofreciendo un acceso libre y gratuito a todos los
contenidos. Permitirá que los usuarios visualicen, descarguen publicaciones en
formato PDF, marquen como favoritos los artículos, guardado de extractos para
motivos de investigación, y comentarios.
Los usuarios registrados tendrán la opción de personalizar su experiencia, mientras
que revisores, moderadores y administradores podrán gestionar la revisión y
administración de las publicaciones. La plataforma será construida a base de
tecnologías web.
Propósito
Facilitar la publicación, distribución y consumo de artículos de investigación en
formato digital. La plataforma busca que tanto investigadores como el público en
general tengan una herramienta fácil de usar para la difusión y consulta de material
académico y divulgativo. Además, se contará con un comité revisor encargado de
evaluar todas las publicaciones, asegurando que el contenido cumpla con los más
altos estándares de calidad y formalidad académica.

59
Revisión y corrección
• Los revisores tendrán acceso a un panel donde podrán evaluar el contenido
de los artículos.
• El comité revisor, compuesto por expertos en diversas áreas, será el
encargado de garantizar que todas las publicaciones cumplan con los
lineamientos formales establecidos y mantengan un alto nivel de calidad en
términos de contenido, estructura y formato.
• Los revisores podrán sugerir cambios o correcciones a los autores antes de
aprobar una publicación.
• El sistema notificará a los autores sobre la solicitud de modificaciones y
permitirá la edición y reenvío de los artículos.
Planteamiento
En la actualidad, existen diversas plataformas diseñadas para la distribución y
consulta de documentos académicos, divulgativos y de investigación. A
continuación, se describen algunos de los portales más populares y sus
características:
1. Studocu: Es una plataforma muy utilizada por estudiantes de todo el mundo
para compartir apuntes, resúmenes y otros materiales académicos. Aunque
facilita el acceso a información relevante para el estudio, no impone un
control estricto sobre la calidad ni el formato de los documentos subidos. Esto
puede derivar en una falta de formalidad y coherencia en los materiales,
especialmente en aquellos que pretenden ser utilizados en contextos
académicos rigurosos.
2. SlideShare: Especializada en la compartición de presentaciones en formato
de diapositivas, SlideShare es ampliamente usada para divulgar contenido
educativo, profesional y académico. Sin embargo, se centra más en la
exposición visual que en la redacción formal de textos, lo que limita su utilidad
para la distribución de artículos científicos o documentos que requieren
seguir lineamientos estrictos de formato como APA o MLA.
3. Scribd: Es una biblioteca digital que permite a los usuarios compartir una
variedad de documentos, incluyendo libros, artículos y presentaciones.
Aunque ofrece una amplia gama de contenidos, Scribd carece de
mecanismos de estandarización del formato de los documentos, lo que
puede resultar en una experiencia de lectura inconsistente cuando se trata
de trabajos académicos que requieren normas formales de redacción.
4. Academia.edu: Esta plataforma está orientada a la publicación y difusión de
artículos académicos. Aunque permite a los investigadores compartir su
trabajo con una comunidad global, tampoco garantiza que los documentos

60
 subidos sigan un formato específico, lo que puede dificultar la comparación
y evaluación entre diferentes publicaciones.
Objetivo
Democratizar el acceso a la ciencia y otros campos de estudio al permitir que
cualquier persona pueda leer, descargar y compartir artículos científicos o de
carácter académico. La plataforma debe ofrecer una experiencia de usuario
inmersiva y accesible, con un diseño sencillo pero funcional.
Alcance
• Usuarios sin registro: Pueden visualizar artículos, comentar, y descargar los
artículos en formato PDF.
• Usuarios registrados: Pueden gestionar su lista de favoritos, subir artículos y
revistas, acceder a una bitácora de estudio, obtener citas en formato APA y
recibir recomendaciones personalizadas.
• Revisores: Pueden revisar, comentar y aprobar/rechazar publicaciones, así
como sugerir cambios a los autores.
• Moderadores: Pueden editar, eliminar y ocultar publicaciones, así como
moderar los comentarios de los usuarios.
• Administradores: Tienen control completo de la plataforma, incluyendo el
acceso al panel de administración, gestión del servidor y configuración global
de la plataforma.
Alcance específico
• Plataforma accesible desde cualquier dispositivo con conexión a internet.
• Visualización de revistas y artículos con contenido destacado.
• Herramientas de búsqueda predictiva, descarga de artículos en PDF y
gestión de favoritos y comentarios.
• Sistema de notificaciones tanto por correo como dentro de la plataforma.
Tecnologías y herramientas por utilizar
• NodeJS con NextJS: Para la lógica del lado del servidor (Fontend y Backend).
• MySQL: Para la gestión y almacenamiento de la base de datos.
• JavaScript: Para el cuadro de búsqueda predictivo y las interacciones
dinámicas.
• Correo Electrónico SMTP: Para la gestión de notificaciones y verificaciones
que el usuario recibirá.

61
Características de la plataforma
• Visualización de artículos y revistas: Los usuarios podrán ver una portada y
el contenido destacado de revistas y artículos.
• Búsqueda predictiva: Cuadro de búsqueda avanzada para encontrar
artículos y revistas por tema, título o autor.
• Comentarios y Favoritos: Los usuarios podrán comentar y marcar artículos
como favoritos para lectura futura.
• Descarga en PDF: Posibilidad de descargar artículos completos en formato
PDF.
• Notificaciones: Sistema de notificaciones por correo electrónico y dentro de
la plataforma para alertas de revisiones, publicaciones y comentarios.
• Panel Administrativo: Gestión de usuarios, publicaciones, comentarios y
estado del servidor.
Funcionalidades principales
• Publicación de artículos: Los usuarios registrados pueden crear artículos
utilizando un editor de texto dentro de la plataforma, dando la posibilidad de
incorporar ilustraciones, embebidos (como contenido a YouTube, Vimeo,
SoundCloud y TikTok), apartado de referencias bibliográficas y anexos.
• Revisión de publicaciones: El contenido subido pasa por un proceso de
revisión a cargo de revisores que pueden solicitar correcciones.
• Panel administrativo: Gestión de usuarios, publicaciones, comentarios, y
estado del servidor. Funciones adicionales para moderadores y
administradores.
• Notificaciones: Alertas por correo y en la plataforma sobre revisiones,
comentarios, avisos del sistema y actualizaciones.
• Panel de interacción: Usuarios pueden marcar artículos como favoritos,
comentar y acceder a una bitácora de estudio.
Tipos de usuario
1. Usuario Sin Acceder: Podrá visualizar todos los artículos, comentarlos, y
descargarlos en PDF.
2. Usuario Registrado:
o Puede personalizar su experiencia con una bitácora de estudio.
o Subir artículos y revistas.

62
 o Acceso a un editor con herramientas específicas para crear y
visualizar publicaciones antes de enviarlas a revisión.
3. Revisor:
o Revisa, sugiere cambios y aprueba artículos y revistas.
o Comunicación con autores a través de la plataforma y correo.
4. Moderador:
o Puede eliminar, ocultar o editar publicaciones.
o Modera los comentarios e interacciones de la plataforma.
5. Administrador:
o Control completo del sitio web.
o Administración de usuarios y contenido.
o Monitorización del estado del servidor.
8. Funcionalidades
1. Funcionalidades del Usuario Sin Acceder:
o Visualización de artículos y revistas.
o Búsqueda predictiva de contenido.
o Descarga de artículos en formato PDF.
o Posibilidad de comentar en las publicaciones.
2. Funcionalidades del Usuario Registrado:
o Todo lo que puede hacer el usuario sin acceso.
o Acceso a la bitácora de estudio.
o Guardar artículos como favoritos.
o Subir y gestionar artículos/revistas.
o Uso del editor de texto para crear artículos.
o Visualización de artículos antes de enviar a revisión.
3. Funcionalidades del Revisor:
o Acceso a un panel de revisión.
o Revisión y comentarios sobre las publicaciones.
o Aprobación o solicitud de modificaciones en las publicaciones.

63
 o Envío de notificaciones automáticas a los autores.
4. Funcionalidades del Moderador:
o Gestión de publicaciones: editar, eliminar y ocultar.
o Moderación de comentarios e interacciones.
o Visualización de estadísticas de interacción de usuarios.
5. Funcionalidades del Administrador:
o Control completo de la plataforma, incluyendo la gestión de
moderadores y revisores.
o Acceso a todas las funcionalidades de los otros tipos de usuario.
o Configuración del servidor y variables globales.
Requerimientos funcionales
Gestión de usuarios:
• Los usuarios deben poder registrarse en la plataforma con un correo
electrónico y contraseña.
• Los usuarios deben poder iniciar sesión con sus credenciales.
• Recuperación de contraseñas mediante enlace enviado por correo
electrónico.
• Los usuarios registrados pueden editar su perfil y personalizar su experiencia
de visualización de artículos.
Publicación de artículos:
• Los usuarios registrados pueden crear y publicar artículos utilizando un editor
de texto enriquecido con la fuente estandarizada.
• El editor de texto permite agregar imágenes en formato JPG, PNG o WEBP
y enlaces embebidos a videos de YouTube o Vimeo.
• Los artículos publicados deben pasar por un proceso de revisión antes de ser
visibles públicamente.
• Todos los artículos/publicaciones tendrán una imagen de portada que el
usuario podrá cargar en tamaño equivalente a Carta, mostrando las
indicaciones sobre dimensiones y verificaciones para mantener una
consistencia, o en su defecto la propia plataforma generará una de manera
genérica si el usuario decide no subir alguna.

64
Revisión y corrección:
• Los revisores deben tener acceso a un panel de revisión de artículos.
• Los revisores pueden sugerir cambios o correcciones a los artículos
enviados.
• El sistema debe notificar a los autores cuando un revisor solicite cambios en
su artículo.
• Los autores pueden editar y reenviar el artículo para revisión.
Visualización de artículos:
• Los usuarios sin registro deben poder ver y descargar todos los artículos en
la plataforma en formato PDF.
• Los usuarios registrados pueden guardar artículos en su bitácora de estudio
para leerlos más tarde.
• Los artículos deben mostrar una portada, descripción y permitir la interacción
mediante comentarios y marcado como favorito.
Búsqueda predictiva:
• Implementación de un cuadro de búsqueda predictiva que permita a los
usuarios buscar artículos y revistas por palabras clave.
• El sistema debe sugerir resultados mientras el usuario escribe.
Gestión de comentarios:
• Los usuarios registrados pueden comentar en los artículos publicados.
• Los moderadores deben poder editar, eliminar o bloquear comentarios
inapropiados.
Notificaciones y alertas:
• El sistema debe enviar notificaciones por correo electrónico a los usuarios
cuando sus artículos sean revisados o aprobados.
• Notificaciones internas en la plataforma para alertar de interacciones con las
publicaciones.
Requerimientos no funcionales
Rendimiento:

65
 • La plataforma debe cargar los artículos en menos de 3 segundos, incluyendo
imágenes y otros elementos multimedia. Para lograr esto, se emplearán
diversos métodos de compresión del contenido.
• La búsqueda predictiva debe mostrar resultados relevantes en menos de 2
segundos.
Escalabilidad:
• La arquitectura debe permitir la adición de nuevos módulos o funcionalidades
sin impactar el rendimiento.
• Debe soportar hasta 1000 usuarios concurrentes inicialmente, con capacidad
de expansión.
Seguridad:
• Debe implementarse encriptación SSL para proteger la transmisión de datos
entre el servidor y el cliente.
• Los datos sensibles, como contraseñas, deben ser almacenados utilizando
hashing seguro (bcrypt).
• Se debe proteger contra ataques comunes como inyección SQL, cross-site
scripting (XSS) y cross-site request forgery (CSRF).
Compatibilidad:
• La plataforma debe ser accesible desde los navegadores más populares
(Chrome, Firefox, Safari, Edge).
• Debe ser completamente responsiva, permitiendo su uso en dispositivos
móviles, tabletas y computadoras de escritorio.
Usabilidad:
• La interfaz debe ser intuitiva y fácil de navegar para todos los usuarios,
independientemente de su nivel técnico.
• El diseño debe seguir principios de accesibilidad, incluyendo soporte para
lectores de pantalla y una paleta de colores adecuada para personas con
daltonismo.
Disponibilidad:
• La plataforma debe estar disponible el 99.9% del tiempo, con mantenimiento
planificado fuera de las horas pico.
• La base de datos debe contar con redundancia para evitar pérdida de datos
en caso de fallos del servidor.

66
Privacidad:
• El sistema debe cumplir con normativas de privacidad como el GDPR,
permitiendo a los usuarios eliminar su cuenta y todos sus datos asociados.
Requerimientos específicos
Base de datos:
• La base de datos debe estar construida en MySQL, optimizada para
consultas rápidas y manejo eficiente de grandes volúmenes de datos.
• Debe tener tablas separadas para usuarios, artículos, revisiones,
comentarios y bitácoras de estudio.
Interfaz de usuario (UI):
• La plataforma debe usar componentes propios y Tailwind CSS para un diseño
limpio y moderno, con una paleta de colores definida en el diseño.
• Debe permitir personalización mínima por parte del usuario (modo
claro/oscuro).
Exportación de artículos:
• Los artículos deben ser exportables a PDF, conservando el formato estándar
y las imágenes incrustadas.
• Para la exportación y redacción se empleará HTML como notación base para
facilitar el proceso y garantizar la integridad y correcta visualización de los
archivos resultantes.
Límite de caracteres:
• El editor de texto para la creación de artículos debe limitar la cantidad de
caracteres a 10,000 dado al enfoque de esta plataforma.
Notificaciones por correo:
• El sistema debe integrar una funcionalidad de notificaciones automáticas por
correo para confirmar registro, envíos de artículos, revisiones y publicación.
Además, se integrarán en la plataforma misma a manera de campana.
Procesamiento de imágenes:
• Las imágenes subidas deben ser redimensionadas automáticamente para
optimizar el tiempo de carga, manteniendo una resolución adecuada para
visualización.

67
Actividades
El proyecto será desarrollado bajo la metodología Scrum, adaptada para su
ejecución por una sola persona. Aunque el desarrollo se realiza de forma individual,
se mantendrá un ciclo de retroalimentación frecuente con revisiones cada tres
semanas, siguiendo la estructura iterativa e incremental de dicha metodología. La
idea principal es obtener retroalimentación continua sobre los avances, ajustar la
dirección del proyecto en función de las observaciones y asegurar la corrección de
errores en las fases tempranas del desarrollo.
Estructura
• Sprints: Se manejarán ciclos de trabajo llamados sprints de tres semanas,
al final de los cuales se presentará el avance logrado. La duración de cada
sprint permite avanzar en funcionalidades clave y recibir retroalimentación
para ajustar detalles antes de continuar con nuevas características.
• Reuniones de retroalimentación: Al final de cada sprint, se presentará el
progreso para revisión y comentarios. Estos comentarios serán incorporados
en el siguiente sprint.
• Planificación y tareas: Se dividirá el proyecto en pequeñas actividades
alcanzables representando una serie de metas y se dará por terminada hasta
que su funcionalidad sea tal cual la esperada. Dicho avance será anotado en
una bitácora de manera informal por motivos de seguimiento.
Planificación y entrega de Sprints
1.Inicio
Actividades:
• Definir el objetivo y alcance del proyecto.
• Identificar las necesidades y requisitos de los usuarios.
• Crear un diagrama de flujo del proceso de gestión de tareas.
Entregable:
• Documento de Requisitos (PDF):
o Descripción detallada de las funcionalidades y características del
proyecto.

68
 o Requisitos de usabilidad, rendimiento y seguridad.
Fecha de Entrega: Primera semana de septiembre
2. Diseño
Actividades:
• Crear prototipos de la interfaz de usuario (UI) y experiencia de usuario (UX).
• Definir la arquitectura de la base de datos (MySQL).
• Seleccionar las tecnologías y herramientas a utilizar (PHP).
Entregable:
• Documento de Diseño (PDF):
o Prototipos de pantallas y flujos de navegación.
o Guía de estilo y paleta de colores.
Fecha de Entrega: Primera semana de septiembre
3. Desarrollo
Actividades:
• Crear la base de datos y modelos de datos.
• Desarrollar la lógica de negocio y funcionalidades.
• Implementar la autenticación y autorización de usuarios.
• Crear la interfaz de usuario y experiencia de usuario.
Entregable:
1. Documento de Arquitectura de la Base de Datos (PDF):
o Diagrama de entidad-relación (ER).
o Descripción de las tablas y campos.
2. Código Fuente:
o Archivos de código de la aplicación web (HTML, CSS, JavaScript,
etc.).
o Documentación de la estructura de directorios y archivos.
Fecha de Entrega:
• 17 de octubre de 2024 (11:00 - 13:00)
4. Pruebas

69
Actividades:
• Realizar pruebas unitarias y de integración.
• Realizar pruebas de usabilidad y experiencia de usuario.
• Identificar y corregir errores.

Entregable:
• Documento de Pruebas (PDF):
o Plan de pruebas y casos de prueba.
o Resultados de las pruebas y reporte de errores.
Fecha de Entrega: Primera semana de diciembre 2024

5. Implementación preliminar
Actividades:
• Desplegar la aplicación en un servidor web.
• Configurar el entorno de producción.
• Realizar pruebas finales.
• Realizar actualizaciones y mejoras continuas.
• Corregir errores y bugs.
• Añadir nuevas funcionalidades.
Entregables:
1. Documento de Mantenimiento y Actualizaciones (PDF):
o Instrucciones para realizar actualizaciones y mantenimiento.
o Proceso para reportar y corregir errores.
2. Manual de Usuario Preliminar (PDF):
o Guía para los usuarios finales.
o Instrucciones para utilizar las funcionalidades del proyecto.
Fecha de Entrega: Segunda semana de diciembre 2024

70
Esquemas de funcionalidades
Diagrama de clases
Se describen las entidades principales del sistema: Usuario, Artículo, Revisión y
Comentario, con sus atributos y métodos.

Ilustración 36 - Diagrama de clases con las entidades principales del backend establecidas en sus
funcionalidades

Diagrama de secuencia para generar publicaciones/artículos

Se presentan los pasos involucrados en el proceso de subir y revisar un artículo por
parte del usuario y revisor. (Ilustración 37)

71
Ilustración 37 - Diagrama de secuencia preliminar del flujo para la apertura de publicaciones posterior a su
revisión

Diagrama de secuencia para la revisión de publicaciones/artículos

Ilustración 38 - Diagrama de secuencia preliminar de la revisión de artículos realizados por los usuarios para
posteriormente ser devueltos con correcciones o publicados

72
Arquitectura básica de la plataforma web
Se muestra la relación entre las capas de la aplicación: presentación, lógica de
negocio, base de datos y las interacciones entre los diferentes componentes de la
plataforma.
Los componentes están en constante comunicación con la base de datos de manera
bidireccional mediante una API REST (análogo a la lógica de negocio), y a su vez
desempeñan una función designada de acuerdo con la acción o su contexto.

Ilustración 39 - Esquemático simplificado del flujo de información presente en Axotl Xires

Extracto de la arquitectura desarrollada

Por el lado del backend, se desarrolló una API REST adecuada para garantizar su
escalabilidad y facilitar el desarrollo con la integración de nuevas funcionalidades,
facilitando su mantenimiento.
Descripción
En el centro se encuentra la API REST con NodeJS y Express que actúa como
núcleo, conectándose con diversos servicios y middlewares. Los clientes (frontend)
interactúan con la API a través de peticiones HTTP. La API utiliza dos middlewares
principales: uno para autenticación (Auth) que gestiona la seguridad y los tokens
JWT, y otro para la gestión de archivos (Upload). La base de datos MySQL almacena
toda la información persistente. Los recursos estáticos se organizan en tres
directorios principales: assets/ para recursos generales, uploads/ para archivos
subidos por usuarios, y fonts/ para tipografías del sistema.

73
Ilustración 40 - Arquitectura del backend (API REST) para el consumo de información y archivos estáticos como
imágenes

Autenticación
Comienza cuando un usuario intenta iniciar sesión mediante POST
La API verifica las credenciales contra la base de datos y, si son válidas, genera un
token JWT a través del middleware de autenticación. Este token se devuelve al
usuario junto con sus datos básicos. Para las subsiguientes peticiones autenticadas,
el cliente debe incluir el token en el encabezado Bearer, que será verificado por el
middleware antes de permitir el acceso a los recursos protegidos.

Ilustración 41 - Diagrama de secuencia para el establecimiento de una autenticación para un usuario sin
privilegios administrativos

74
Estados de Publicaciones
publicación comienza en estado "Borrador", donde el autor puede editarla
libremente. Al enviarla, pasa a estado "EnRevision" donde los moderadores pueden
evaluarla. Desde ahí, puede ser "Aprobada" pasando a estado "Publicado", o
"Rechazada" volviendo a "Borrador" para su corrección. El estado "Publicado"
representa el final del ciclo básico, aunque la publicación podría ser retirada o
archivada posteriormente.
Flujo de la revisión de un artículo/publicación
Una contribución debe ser aprobada previamente antes de ser hecho pública. Su
publicación será realizada una vez que los revisores hayan indicado las
correcciones necesarias y a su vez el usuario los haya corregido.

Ilustración 42 - Flujo completo preliminar para la revisión y aprobación de publicaciones

Identidad de la marca
Para otorgar un mayor atractivo visual, identificación e identidad, se estableció bajo
la marca Axotl Xires o formalmente Axotl Xires Publicaciones

75
Ilustración 43 - Identidad oficial (versión banner) de Axotl Xires. Trabajo propio

La mascota de la marca para la plataforma “Axotl” se establece bajo los criterios de

color de un Ajolote, debido a una cuestión estratégica.
El ajolote (Ambystoma mexicanum) es una especie que despierta gran interés en la
comunidad científica debido a sus extraordinarias capacidades regenerativas.
Puede regenerar extremidades completas, órganos e incluso partes de su cerebro,
lo que lo convierte en un sujeto de estudio crucial en campos como la medicina
regenerativa y la biología del desarrollo.
Con su apariencia peculiar y adorable, el ajolote es visualmente cautivador. Sus
"sonrisas" características y sus branquias externas que parecen una corona lo
hacen muy atractivo y memorable, ideal para una mascota de marca, además
complementándose con su rica historia cultural, apareciendo en la mitología azteca.
Esto permite establecer conexiones entre la ciencia y la cultura, enriqueciendo el
contenido de la plataforma.
Paleta de colores PANTONE
Los tonos morados no son tan comúnmente utilizados en marcas como otros
colores, lo que permite a una marca destacar y ser percibida como original y única,
reforzando la idea de creatividad. Esta paleta además de simbolizar neutralidad y
profesionalidad evoca sensaciones de misterio e intriga, lo que puede simbolizar el
proceso de descubrimiento y aprendizaje continuo asociado con la sabiduría, a lo
cual el giro de esta plataforma va inclinado a la distribución y publicación de
contenido de carácter científico, académico y profesional.
Muestra de los colores seleccionados
La representación del color puede variar de acuerdo con la configuración de su
monitor.

76
Colores para área pública

Púrpura intenso (PANTONE P 93-8 C):

Este color dominante evoca la curiosidad, la creatividad y el misterio, aspectos
fundamentales en la ciencia. También puede representar la piel húmeda y vibrante
del ajolote, que tiene tonos púrpuras en algunas variedades. Es un color que atrae
la atención y sugiere un contenido intrigante y fascinante.
Lila suave (PANTONE P 93-5 C):
Este tono más claro complementa al púrpura intenso y puede representar la
suavidad de la piel del ajolote. En el contexto de la divulgación científica, sugiere
accesibilidad y comprensión, haciendo que la ciencia parezca menos intimidante.

Colores para área administrativa

Gris neutro (PANTONE P 169-4 C):

El gris aporta balance y seriedad a la paleta. Representa el aspecto formal y riguroso
de la ciencia, además de poder evocar las rocas o el fondo de los hábitats acuáticos
del ajolote. Es un color versátil para fondos o textos.

77
Azul medio (PANTONE P 108-7 C):
Este azul evoca el agua, hábitat natural del ajolote. En el contexto científico, sugiere
profundidad de conocimiento, confiabilidad y calma. Puede usarse para destacar
información importante o enlaces.
Azul oscuro (PANTONE P 108-16 C):
El tono más oscuro de la paleta aporta solidez y autoridad. Representa las
profundidades del conocimiento científico y las aguas más profundas donde habitan
los ajolotes. Es ideal para encabezados o pies de página.

Dominio web
Se seleccionó una dirección con terminación (dominio) .org debido a que el giro de
la plataforma se basará en ser sin ánimo de lucro y a su vez permitirá su
establecimiento formal como portal para la difusión de artículos científicos y
conocimiento en general, sin un fin comercial o lucrativo.
Actualmente ya se encuentra reservado para su uso.

Pruebas preliminares en un ambiente de desarrollo

Las pruebas fueron realizadas en una revisión prematura de proyecto, en diciembre
2024. La solución en este momento se encuentra alrededor de un 70% de
desarrollo.

78
Ambiente de pruebas

Pruebas de Compatibilidad en Navegadores

Descripción:
Se realizaron pruebas de funcionamiento para asegurar que la plataforma Axotl
Xires es compatible con los navegadores modernos más comunes. Estas pruebas
comprueban el correcto renderizado de la interfaz de usuario, navegación y
funcionalidad general. Su ambiente principal es en un entorno local de desarrollo.
Se analizarán las rutas y componentes más críticos en el presente documento.

Navegadores Probados:

1. Microsoft Edge
○ Versión: 13.10.2903.70 (64 bits)
○ Estado: Pruebas realizadas con éxito.
2. Firefox Developer Edition
○ Versión: 134.0b5 (64 bits)
○ Estado: Pruebas realizadas con éxito.

Observación:
La interfaz y funcionalidades clave, como la navegación entre secciones y el uso del
buscador, funcionan de manera óptima en ambos navegadores, en diciembre de
2024.

Ilustración 44 - Muestra de los navegadores empleados al momento de desarrollo y la ejecución de pruebas

79
Apertura inicial
Ruta: / (home)
Descripción:
Se realizaron pruebas de apertura inicial del sitio en los navegadores en modo
incógnito para comprobar su comportamiento.
Observaciones:
La apertura se realiza de manera correcta, mostrando skeleton loaders mejorando
la experiencia de usuario, antes que el contenido esté listo para presentarse. En el
caso de un entorno de producción, se mostrarán mientras se descarga el contenido.
Se prepara el espacio donde se colocará cada contenido antes de presentarse,
anticipando estos factores.

Ilustración 45 - Primera apertura de Axotl Xires en Microsoft Edge

La API REST se conecta de forma adecuada y realiza las peticiones necesarias para
componer la ruta. Entre ellas se invocan los perfiles de los usuarios para obtener
información, y rutas referentes a detalles de las publicaciones, para ser
presentadas.

80
Ilustración 46 - Comportamiento de la API REST en la apertura

Análisis de la ruta home

Sección izquierda:

● Página principal de Axotl Xires: Muestra la página de inicio de la plataforma

Axotl Xires, diseñada para la divulgación de publicaciones científicas y
académicas.
● Elementos principales:
○ Logo de la plataforma: Un simpático axolotl sonriente.
○ Título principal: "Descubre y Comparte Conocimiento Científico".
○ Subtítulo: "Una plataforma dedicada a la divulgación de publicaciones
científicas y académicas, creada por y para la comunidad
investigadora."
○ Botón de llamada a la acción: "Explorar publicaciones".
○ Sección de "Publicaciones Recientes" con una imagen de ejemplo.
○ Botón para crear una cuenta.

Sección derecha:

● Consola del navegador: Muestra la consola del navegador, que proporciona

información técnica sobre la página web.
● Detalles técnicos:
○ Solicitudes HTTP: Se muestran múltiples solicitudes HTTP
realizadas al servidor, incluyendo métodos (GET, POST), rutas,
códigos de estado y tamaños de respuesta.
○ Cabeceras HTTP: Se muestran las cabeceras de las respuestas
HTTP, que contienen información adicional sobre el contenido y
configuración de la respuesta.
○ Elementos de la página: Se muestran elementos del DOM
(Document Object Model) de la página, como etiquetas HTML, estilos
CSS y scripts JavaScript.

81
 ○ Mensajes de consola: Se muestran mensajes de consola, que
pueden ser útiles para depurar y entender el funcionamiento de la
página.

Ilustración 47 - Comportamiento en Red de la carga de contenido al momento de renderizar la página de

apertura

Una vez recibidas, procesadas y renderizadas las solicitudes, se carga el contenido

respectivo. Los skeleton loader desaparecen.

Ilustración 48 - Muestra de la página completamente renderizada con los loaders desactivados dada a la carga
completa del contenido

82
Solicitudes HTTP en la ruta /home

Ilustración 49 - Muestra del consumo de red y datos transferidos

Nos centramos en la línea de tiempo de las solicitudes HTTP que se realizan

cuando se carga la página. Esta proporciona una visión clara de:

● Número de solicitudes: Se realizaron 24 solicitudes diferentes para cargar

todos los recursos necesarios de la página.
● Tipo de recursos: Se cargaron diversos tipos de recursos, incluyendo
imágenes (png, jpeg), hojas de estilo (css), scripts (js), fuentes (woff2) y otros
formatos.
● Tamaño de los recursos: El tamaño total de los recursos descargados fue
de 43.3 MB.
● Tiempo de carga: El tiempo total de carga fue de 1.38 segundos.
● Estado de las solicitudes: La mayoría de las solicitudes se completaron con
éxito (código de estado 200), pero algunas fallaron (código de estado 404).

83
Observaciones adicionales:

● Optimización de imágenes: Se han utilizado diferentes formatos de imagen

(png, jpeg) y niveles de compresión para reducir el tamaño de los archivos y
mejorar el tiempo de carga.
● Uso de caché: Algunos recursos, como las fuentes y ciertas imágenes, se
cargaron desde el caché, lo que reduce el tiempo de carga.
● Minificación de archivos: Los archivos CSS y JavaScript parecen estar
minificados, lo que reduce su tamaño y mejora el rendimiento.
● Carga diferida de scripts: Algunos scripts se cargan de forma diferida o
asíncrona, lo que permite que la página se renderice más rápidamente.

Implicaciones para el rendimiento:

● Tiempo de carga: El tiempo de carga de 1.38 segundos es relativamente

bueno, pero podría optimizarse aún más reduciendo el tamaño de los
archivos más grandes o utilizando técnicas de compresión más avanzadas.
● Experiencia del usuario: Un tiempo de carga más rápido mejora la
experiencia del usuario y reduce la tasa de abandono.
● SEO: Google y otros motores de búsqueda valoran la velocidad de carga de
una página web, por lo que optimizar el rendimiento puede mejorar el
posicionamiento en los resultados de búsqueda. Esto se abordará cuando el
sitio se encuentre en producción para consumo masivo.

Recomendaciones:

● Analizar las solicitudes 404: Identificar y corregir los recursos que no se

encuentran para evitar solicitudes innecesarias.
● Optimizar aún más las imágenes: Explorar opciones como WebP o AVIF
para reducir aún más el tamaño de las imágenes sin perder calidad.
● Reducir el número de solicitudes: Combinar archivos CSS y JavaScript, o
utilizar herramientas de empaquetado como Webpack para reducir el número
de solicitudes HTTP.
● Implementar la carga perezosa de imágenes: Cargar las imágenes solo
cuando sean visibles en la pantalla para mejorar el tiempo de carga inicial.
● Utilizar una CDN: Una Content Delivery Network puede mejorar el tiempo
de carga al servir los recursos desde servidores ubicados más cerca de los
usuarios. La opción seleccionada será bajo Cloudflare, en su entorno de
producción, conjunto a las optimizaciones proporcionadas por Vercel.

84
Carga de perfiles de usuario
Ruta: /perfiles/{idUsuario}

Descripción:
Se realizaron pruebas al acceder a la página de perfil de usuario, donde se debe
cargar la información personal y estadísticas del usuario, además de ejecutar
solicitudes a la API REST para recuperar los datos asociados.

Ilustración 50 - Consumo de la API REST con el consumo de información asociado a un perfil de usuario

Observaciones Técnicas:

1. Visualización de Datos:
En la captura, se muestra el perfil del usuario con:
○ Nombre: "Juan Perez".
○ Nombramiento: "Maestro en algo interesante".
○ Publicaciones: "0".
○ Fecha de registro: "26 de noviembre de 2024".
○ Último acceso: "Hoy".
2. Solicitudes a la API:
Se generaron solicitudes GET hacía las siguientes rutas:
○ : Recuperación de la foto de perfil.
○ Recuperación de datos generales del usuario
por su ID.

85
 ○ : Consulta de
publicaciones realizadas por el usuario.
3. Estado de las respuestas:
○ Código 304: Indica que los datos no han cambiado desde la última
solicitud, utilizando caché de manera efectiva.
○ Código 404: La ruta para publicaciones devueltas no existe o no
encuentra resultados en la base de datos para el usuario.
4. Tiempo de Respuesta:
Los tiempos promedio de las solicitudes oscilaron entre 2.1 ms y 3.9 ms,
evidenciando un rendimiento adecuado.
5. Depuración en Navegador:
La consola del navegador muestra múltiples solicitudes ejecutadas
correctamente, mientras se gestionan los estados de carga y los eventos de
la página.

Resultados Esperados:

● El perfil de usuario debe cargar correctamente todos los datos relevantes

(nombre, nombramiento, estadísticas, publicaciones).
● Las imágenes deben ser visibles sin errores de carga.
● Las solicitudes de API deben responder con los códigos HTTP adecuados y
datos relevantes.

Se detectó un error de ruta para publicaciones del usuario (código 404). Requiere
revisión en la API o en los datos almacenados para garantizar que las publicaciones
asociadas se recuperen correctamente. En este caso el usuario no tiene
publicaciones asociadas, por lo cual se deben mejorar aquellas solicitudes para
mejorar su manejo y optimizar el consumo de la API.

Validaciones de carga de rutas que requieran un inicio de sesión.

Resumen de la situación:

● SVG animado: Al acceder a una ruta protegida por autenticación en Axotl

Xires, se muestra un SVG animado como indicación visual mientras se
realiza la verificación de autenticación.
● Redirección a /login: Si el usuario no está autenticado, se redirige
automáticamente a la página de inicio de sesión (/login).

86
Ilustración 51 - Análisis del comportamiento de un SVG animado representando un loader renderizado
preparando el contenido posterior a mostrar

Análisis:

Se pueden observar varias solicitudes HTTP que se realizan al cargar la página.

Estas solicitudes son necesarias para obtener los recursos (HTML, CSS, JavaScript,
imágenes, etc.) que conforman la página y para realizar las verificaciones de
autenticación.

Posibles implementaciones y consideraciones:

1. Componentes clave:

● SVG animado:
○ Se utiliza una librería o framework de animación (como React Spring,
Framer Motion, o una solución personalizada con CSS) para crear el
efecto visual del SVG.
○ El SVG se renderiza en la página y se inicia la animación al cargar la
página o al detectar que se requiere autenticación.
● Lógica de autenticación:
○ Se utiliza un middleware o interceptor para verificar si el usuario está
autenticado antes de permitir el acceso a la ruta protegida.
○ Si el usuario no está autenticado, se redirige a la página de inicio de
sesión.

2. Flujo de la aplicación:

1. El usuario accede a una ruta protegida.

2. Se realiza una solicitud al servidor para verificar la autenticación.

87
 3. Mientras se espera la respuesta del servidor, se muestra el SVG animado.
4. Si el usuario está autenticado:
○ Se carga el contenido de la página protegida.
○ Se detiene la animación del SVG.
5. Si el usuario no está autenticado:
○ Se redirige al usuario a la página de inicio de sesión.
○ Se detiene la animación del SVG.

3. Consideraciones adicionales:

● Experiencia del usuario: El SVG animado debe ser visualmente atractivo y

proporcionar una buena experiencia de usuario mientras se espera la
verificación de autenticación.
● Rendimiento: La animación del SVG no debe afectar negativamente al
rendimiento de la aplicación. En esta revisión, se requiere mejorar su
comportamiento ya que se ha detectado ralentizaciones al cargarse al
momento.

Creación de portadas
Ruta: /redactar

Descripción:
Se probó el creador de portadas avanzado disponible en la página /redactar
de Axotl Xires. Esta funcionalidad permite a los usuarios generar una portada para
sus publicaciones científicas y académicas mediante una imagen proporcionada,
con dimensiones de 500x500 pixeles.

Ilustración 52 - Comportamiento del componente asociado a la creación de portadas personalizadas (preliminar)

88
Características del Componente

1. Ubicación:
Se encuentra en la sección inicial de la página /redactar bajo el apartado
de portada.
○ Botón visible: "Crear portada".
○ Aparece un modal con herramientas para subir imágenes y
personalizar la portada.
2. Funcionalidades Principales:
○ Carga de Imágenes: Permite subir una imagen en formatos estándar
(como PNG o JPEG).
○ Generación de Portada: Integra opciones para ajustar el diseño final
con herramientas que permiten visualizar el resultado.
○ Guardado: Botón "Guardar portada" para confirmar el diseño.
3. Tiempos de Respuesta:
○ Solicitudes GET de imágenes y recursos cargan con tiempos
promedio de 2 a 14 ms.
○ Estado 200 indica correcto manejo de los recursos de portada.
○ Recursos SVG y otros assets visuales responden correctamente.
4. Problemas Detectados:
○ Responsividad:
El modal tiene dificultades de ajuste en entornos móviles, lo que limita
su uso óptimo únicamente a dispositivos de escritorio.
○ Interfaz de Usuario:
Elementos del modal podrían solaparse en ventanas de tamaño
reducido.

Resultados Esperados

1. Creador Responsivo:
○ Adaptar el diseño del modal para pantallas pequeñas con ajustes en
CSS y Tailwind.
○ Incorporar breakpoints para mejorar la usabilidad en dispositivos
móviles.
2. Optimización Visual:
○ Refinar elementos para evitar solapamientos o vistas incompletas en
pantallas no estándar.
3. Mensajes de Error:
○ Incluir retroalimentación clara cuando no se cargue una imagen válida
o no cumpla los requisitos.

89
Recomendaciones

● Revisar el diseño responsivo para garantizar la funcionalidad en todos los

dispositivos.
● Verificar el comportamiento en distintos navegadores y tamaños de pantalla.
● Probar con usuarios reales para evaluar la experiencia de carga y
personalización.

Se cuentan con las validaciones necesarias para únicamente permitir imágenes con
las dimensiones mencionadas como mínimo, garantizando la calidad de las
portadas resultantes.

Ilustración 53 - Alerta generada a manera de control de excepciones al cargar una imagen para crear una
portada

Al importar la imagen, se puede generar movimiento (ajuste) mediante un canvas.

La imagen proporcionada se almacena de manera local, por lo cual siempre
tendremos el archivo original para trabajar en el momento.

90
Ilustración 54 - Almacenamiento local de la imagen proporcionada por el usuario

Observaciones: Se considera mejorar aspectos de la programación ya que se

encuentra duplicado el componente asociado a manipular la imagen en cuanto a su
desplazamiento y ajustes.
La funcionalidad para añadir texto, cambiar tipografías, colores, alineaciones y
rotaciones funciona de manera adecuada.

Ilustración 55 - Muestra de las funcionalidades para colocar texto y su personalización dentro del canvas donde
se crea la portada

91
Cuando se da clic en Guardar Portada, la imagen resultante se guardará de forma
local, para posteriormente ser enviada a la API REST que se encargará de hacer un
manejo con ella para almacenarla.

Ilustración 56 - Vista para la edición de una publicación una vez que esta ha sido guardada como borrador

Se consume la API para poder almacenar los datos de un nuevo borrador, y

posteriormente almacena la imagen de portada en una ruta predeterminada, con un
nombre asociado exactamente a esa publicación.
Área de mejora: En una próxima implementación se considera almacenar este
contenido multimedia en un bucket dedicado para el manejo de contenido,
invocando el fichero necesario cuando se requiera bajo una arquitectura
funcionando de manera asíncrona.

Ilustración 57 - Consumo de la API REST y almacenamiento de archivos estáticos (imágenes) - Preliminar

92
Recuperación de portadas

Contexto:

● Página: /perfiles/mispublicaciones
● Funcionalidad: Mostrar las publicaciones de un usuario en diferentes
estados (borrador, publicado, en revisión, rechazado).
● Herramienta: Consola del navegador (Network tab)

Lógica:
● Solicitud inicial: Al cargar la página, se realiza una solicitud al servidor para
obtener la información básica del usuario (ID, nombre, etc.).
● Solicitudes por cada estado: Se realizan solicitudes separadas para
obtener las publicaciones en cada estado (borrador, publicado, en revisión,
rechazado). Estas solicitudes podrían incluir filtros para obtener solo las
publicaciones del usuario actual y en el estado específico.
● Renderizado de la interfaz: El frontend recibe los datos de las solicitudes y
los utiliza para renderizar la interfaz de usuario, mostrando las publicaciones
en las secciones correspondientes.
● Paginación: Si el número de publicaciones es muy grande, es probable que
se implemente una paginación para cargar las publicaciones de forma
gradual a medida que el usuario navega.

Observaciones:

Rutas de API: Las rutas típicas incluyen

, etc., realizando consultas a una base de datos para obtener la
información necesaria.
Estados de las solicitudes: La mayoría de las solicitudes tienen un estado 200
(OK), lo que significa que se han completado correctamente. Sin embargo, también
pueden aparecer estados como 304 (Not Modified) si el navegador tiene una versión
en caché del recurso.
Tiempos de respuesta: Los tiempos de respuesta varían según la complejidad de
la solicitud y la carga del servidor. En general, se busca que los tiempos de
respuesta sean lo más bajos posibles para ofrecer una buena experiencia al usuario.
Las imágenes referentes a cada portada se recuperan al momento de acuerdo a la
asociación que tienen por publicación.

93
Ilustración 58 - Consumo de imágenes de portada asociadas a una publicación desde la API REST

Se podría optimizar más al invocar la imagen de perfil, debido a que primero

recuperamos una imagen de perfil por defecto en el caso que no se haya localizado
en primera instancia al momento de invocar el contenido.

Ilustración 59 - Señalamiento de área de mejora para el consumo de archivos estáticos por defecto desde la
API REST

Búsqueda dinámica

Captura 1: Página Inicial de Búsqueda

● Estado Inicial:
○ La barra de búsqueda se encuentra en la parte superior de la
página.
○ No hay resultados mostrados hasta que el usuario ingresa un
término.
○ Diseño limpio y minimalista, con un área reservada para mostrar
los resultados.

94
Ilustración 60 - Apertura de la página de búsqueda con skeleton loaders mostrados mientras se consultan los
resultados

Captura 2: Resultados Positivos de Búsqueda

● Interacción:
○ Se buscó un término.
○ La página devuelve múltiples resultados con información detallada:
1. Título de la publicación.
2. Resumen breve.
3. Imagen de portada.
● Funcionalidad Observada:
○ Resultados ordenados en tarjetas.
○ Cada tarjeta incluye:
1. Imagen de portada (cargada correctamente).
2. Título y resumen relevantes.
3. Redirección esperada a la publicación mediante su ID al dar clic
en cada tarjeta de resultado.

La búsqueda consume la API de forma dinámica al momento y esta devuelve un

resultado actualizado con aquellas publicaciones que hayan hecho match con las
palabras ingresadas.

95
Ilustración 61 - Muestra de la página de búsqueda con publicaciones que cumplan con los criterios de búsqueda

Captura 3: Búsqueda sin Resultados

● Interacción:
○ Se buscó el término bu.
○ La plataforma muestra el mensaje: "No se encontraron resultados".
● Funcionalidad Observada:
○ Barra de búsqueda conserva el término ingresado.
○ Visualización correcta del mensaje vacío.
○ Las solicitudes de la API (GET ) retornan
código 304, lo que indica que no hubo actualizaciones en los datos en
caché.

96
Ilustración 62 - Consulta de información desde la API REST que se hace al instante que se coloca cualquier
carácter en el cuadro de búsqueda

Análisis y Observaciones

1. Resultados de Búsqueda:
○ El sistema filtra correctamente las publicaciones según los términos
ingresados.
○ Cuando no hay coincidencias, el mensaje es claro y no genera
confusión.
2. Rendimiento:
○ Las solicitudes a la API presentan tiempos de respuesta rápidos.
○ Uso eficiente del estado 304 para recursos no modificados,
optimizando el rendimiento.
3. Detalles Visuales:
○ Diseño responsivo y alineado con la estética general de Axotl Xires.
Se debe mejorar la alineación y tamaño de los skeleton loader.
○ Tarjetas de resultados bien distribuidas con datos clave.

Pruebas de Visualización de Publicaciones por ID

Captura 1: Carga Inicial de la Publicación

● Estado Inicial:
○ Al ingresar a la página de una publicación, se muestra un diseño base
mientras se realiza la carga de datos desde la API.
○ Espacios de la interfaz ocupados por placeholders (contenedores
vacíos).

97
 ● Funcionalidad Observada:
○ La interfaz permanece limpia y organizada mientras los datos se
cargan.
○ Proporciona un diseño consistente y evita que la página se vea rota o
desordenada durante la carga.

Ilustración 63 - Muestra de la carga inicial de la página pára ver una publicación mientras se consultan los datos
desde la API REST

Captura 2: Publicación Renderizada

● Estado Post-Carga:
○ Se muestra la información específica de la publicación seleccionada:
■ Título ("Ajolotes").
■ Resumen y detalles de la publicación.
■ Encabezados y estilo del contenido (e.g., texto en negritas o
cursiva).
■ Imagen o logotipo representativo.
● Funcionalidad Observada:
○ La visualización incluye un cuadro de datos adicionales sobre la
publicación:
■ Fecha de creación.
■ Autor de la publicación.
■ Número de comentarios.
○ Botones interactivos ("Añadir a favoritos", "Ver").

98
Ilustración 64 - Renderizado completo de una página de publicación

Captura 3: Actividad en la API

● Interacción con la API:

○ Varias solicitudes se realizan para recopilar los datos necesarios:
■ GET :id: Devuelve la información
básica de la publicación.
■ GET
idUsua
rio: Verifica si el usuario ha marcado la publicación como
favorita.
■ GET :id: Obtiene información del autor de
la publicación.
■ GET :id: Recupera la
imagen de perfil del autor.
● Datos Observados:
○ Las solicitudes retornan mayormente con estado 304 (Not Modified),
indicando que los datos no han cambiado en el servidor y se están
usando recursos en caché para mejorar el rendimiento.
○ El tiempo promedio de respuesta es eficiente (generalmente menor a
50 ms por solicitud en el entorno local).

99
Ilustración 65 - Consumo de información asociadas a una publicación desde la API REST

Análisis y Observaciones

1. Carga de Datos:
○ La estructura inicial placeholder asegura una experiencia de usuario
fluida, eliminando problemas de "carga incompleta".
○ La segmentación de datos en solicitudes independientes permite
modularidad y optimización del uso de caché.

Recomendaciones de Mejora

1. Rendimiento:
○ Evaluar la posibilidad de combinar algunas solicitudes relacionadas
(e.g., favoritos y datos del autor) para reducir la cantidad de llamadas
a la API.
2. Visualización Inicial:
○ Incluir animaciones sutiles para placeholders durante la carga.
3. Datos Dinámicos:
○ Mejorar la experiencia del usuario al actualizar automáticamente
ciertos datos dinámicos, como los favoritos, sin requerir recargas.

Estado actual
A la fecha de redacción de este documento, el proyecto sigue en desarrollo activo y
se llevará de forma extraoficial a lo que abarca el periodo de tiempo de este servicio,
formando parte de un proyecto adicional de gran impacto que se le dará seguimiento
a mediano plazo, con autorización del Mtro Donaji Jimenez Islas, Docente de la
División de Ingeniería en Energías Renovables de ITESHU.

100
Conclusiones
El Programa de Servicio Social detallado abarcó el desarrollo de tres proyectos
principales, cada uno con un impacto claro en sus respectivos ámbitos. Estas
actividades incluyeron la creación de una plataforma de encuestas a la medida, una
microaplicación web para el cálculo de biodigestores y una plataforma web para la
redacción y distribución de artículos científicos y académicos.
A continuación, se presenta una recapitulación detallada de cada proyecto con sus
respectivos requerimientos, así como una conclusión sobre los resultados finales.
Plataforma de encuestas a la medida
Este proyecto buscó superar las limitaciones de un sistema basado en archivos de
Excel interactivos, mediante el desarrollo de una solución web personalizada para
recopilar y gestionar datos sobre las barreras en la adopción de energía renovable
en México.
Se trabajaron los siguientes puntos:
• Autenticación de usuarios: Sistema de login con credenciales generadas
aleatoriamente, confidencialidad de datos personales y redirección
automática según el tipo de usuario.
• Base de datos: Gestión de datos jerarquizados con relaciones bien definidas
y exportación de resultados en formato XLS.
• Gestión de usuarios: Asignación de sectores y generación aleatoria de
cuentas para encuestados.
• Respuestas a reactivos: Uso de controles deslizantes para evaluar la
incidencia de factores, con almacenamiento centralizado y cálculos
jerarquizados.
• Seguridad: Hashing de contraseñas y uso de HTTPS.
• Usabilidad: Interfaz intuitiva con funcionalidades responsivas para
encuestados y administradores.
Resultados:
Se centralizó y optimizó el manejo de encuestas, facilitando la recopilación y análisis
de datos con un sistema eficiente, seguro y accesible para los usuarios.

101
Microaplicación web para el cálculo de biodigestores
El objetivo de este proyecto fue reemplazar una herramienta en Excel con macros
inseguros por una solución basada en web, capaz de calcular y diseñar
biodigestores de tipo hongo.
Se trabajaron los siguientes puntos:
• Descripción general: Desarrollo de una interfaz intuitiva, cálculos precisos
para dimensionamiento de biodigestores y generación de informes gráficos
descargables.
• Funcionalidades específicas: Entrada de datos clave como número de
vacas, excreta diaria, relación estiércol-agua, tiempo de residencia y altura
del cilindro.
• Cálculos realizados: Estimaciones de volumen de mezcla, biodigestor,
producción de biogás, dimensiones y esquemas gráficos representativos.
• Tecnologías utilizadas: HTML5, CSS3, JavaScript (Bootstrap y jQuery),
PHP (lógica y generación de gráficos), y la biblioteca GD.
• Usabilidad: Tiempo de respuesta inferior a 2 segundos, compatibilidad móvil
y accesibilidad sin registro.
Resultados:
La herramienta mejoró significativamente la escalabilidad y accesibilidad,
permitiendo a agricultores, estudiantes y profesionales diseñar biodigestores de
manera eficiente y confiable. Su difusión se generará a corto plazo y ha dado
buenas impresiones por parte de personal especializado.

Plataforma web para la distribución y redacción de artículos científicos y

académicos
Este proyecto buscó democratizar la generación y publicación de conocimiento
mediante una plataforma abierta para redactar, revisar y distribuir artículos.
Requerimientos de software:
• Redacción y revisión: Herramientas integradas para edición colaborativa,
generación de portadas profesionales y correcciones basadas en
retroalimentación de revisores.
• Distribución digital: Descarga en formato PDF, lectura inmersiva en la
plataforma y funcionalidad social para comentarios y favoritos.
• Usuarios: Opciones personalizables para autores, revisores y
administradores, asegurando calidad mediante comités de evaluación.

102
 • Tecnologías: Basada en un enfoque modular para garantizar escalabilidad
y facilidad de uso.
Resultados:
Se establecieron las pautas y el desarrollo inicial preliminar de una solución inclusiva
y funcional que supera las limitaciones de otras plataformas existentes al integrar la
creación, revisión y publicación en un único entorno. El proyecto llevará de forma
extraoficial a lo que abarca el periodo de tiempo de este servicio, formando parte de
un proyecto adicional de gran impacto que se le dará seguimiento a mediano plazo,
garantizando la finalidad inicial dada a este proyecto y el establecimiento de la
marca creada. Posteriormente se realizarán los trámites necesarios para registro de
propiedad intelectual.

Conclusión general
En conjunto, las actividades desarrolladas durante el servicio social lograron
satisfacer necesidades específicas en áreas clave como la recopilación de datos, la
optimización de herramientas de diseño técnico y la democratización del
conocimiento. Individualmente, cada proyecto destacó por su enfoque innovador: la
plataforma de encuestas mejoró la seguridad y eficiencia en la recopilación de
datos; la microaplicación de biodigestores ofreció una herramienta accesible y
escalable para fomentar prácticas sostenibles; y la plataforma de redacción
académica proporcionó un entorno integral para la creación y distribución de
contenido científico aún en desarrollo.
El éxito de estos proyectos radicó en la correcta identificación de problemas, el
diseño de soluciones adaptadas y la implementación de tecnologías modernas que
garantizan su funcionalidad, escalabilidad y relevancia a largo plazo.

103
Sugerencias
Implementar un sistema de seguimiento digital para proyectos de servicio
social:
Desarrollar una plataforma web donde los prestadores de servicio social puedan
registrar sus actividades, avances y entregables en tiempo real, permitiendo un
monitoreo continuo por parte de la Oficina. Esto optimizaría la supervisión y
reduciría la dependencia de reportes físicos o entregas periódicas.
Establecer un repositorio de proyectos exitosos:
Crear un repositorio público donde se documenten los proyectos de servicio social
destacados, incluyendo el alcance, tecnologías utilizadas, resultados y
aprendizajes. Esto podría servir como referencia para futuros prestadores,
promoviendo la innovación y la colaboración.
Posterior a terminar el servicio, crear un espacio para que todos los alumnos puedan
exponer su trabajo, para brindar sugerencias y retroalimentación, facilitando la
difusión de los resultados finales y los beneficios que dio cada alumno en su servicio
social.
Desarrollar guías de buenas prácticas para el servicio social:
Diseñar manuales o lineamientos que detallen buenas prácticas en la ejecución de
proyectos, como la identificación de necesidades reales, el levantamiento de
requerimientos, el diseño centrado en el usuario y la documentación adecuada. Esto
mejorará la calidad general de los proyectos.
Establecer alianzas con sectores especializados:
Colaborar con empresas, organizaciones no gubernamentales y entidades
gubernamentales para identificar problemas específicos que puedan ser abordados
por prestadores de servicio social. Esto asegurará que los proyectos tengan
relevancia práctica y un impacto directo en el entorno.

104
Muñoz Santana Emanuel Mtro. Donaji Jimenez Islas

Docente de la División de Ingeniería

en Energías Renovables de ITESHU.

_______________________________________

105
Glosario
A usuarios ajustar un valor
moviendo un control horizontal o
• AJAX (Asynchronous
vertical.
JavaScript and XML): Técnica de
desarrollo web que permite la • Concurrencia: Capacidad de un
comunicación asíncrona entre sistema para manejar múltiples
cliente y servidor, facilitando la procesos o usuarios
actualización parcial de una simultáneamente.
página sin necesidad de
D
recargarla completamente.
• DataTables: Plugin de jQuery
• API (Application Programming
para gestionar tablas HTML,
Interface): Conjunto de reglas y
añadiendo funcionalidades como
protocolos que permiten la
búsqueda, paginación y
interacción entre diferentes
ordenación.
aplicaciones o sistemas.
• Dashboard: Interfaz gráfica que
• Autenticación de usuarios:
consolida y organiza información
Proceso de verificación que
clave para facilitar la gestión y el
permite confirmar la identidad de
monitoreo de datos.
un usuario antes de otorgar
acceso a un sistema. • Diagrama relacional:
Representación gráfica que
B
describe cómo se relacionan las
• Biodigestor: Sistema diseñado tablas en una base de datos.
para procesar desechos orgánicos
E
mediante fermentación
anaeróbica, produciendo biogás y • Entidades (Base de datos):
fertilizantes naturales. Representación de objetos o
conceptos del mundo real,
• Bootstrap: Framework CSS para
estructurados en tablas con
el diseño de interfaces web
atributos específicos.
responsivas y atractivas.
• Excel interactivo: Documento en
• BCRYPT: Algoritmo de hashing
Microsoft Excel que utiliza macros
utilizado para proteger
o funciones avanzadas para
contraseñas mediante cifrado
proporcionar interactividad.
seguro.
• Exportación de datos: Proceso
C
de convertir datos de un sistema
• CSS (Cascading Style Sheets): en un formato compatible con
Lenguaje de estilo usado para otras aplicaciones, como archivos
definir la apariencia y el diseño de Excel o PDF.
documentos HTML.
F
• Control deslizante: Componente
interactivo que permite a los

106
 • Factor dominante: Elemento con • Inteligencia colectiva: Proceso
mayor peso en la evaluación de un colaborativo donde múltiples
reactivo o en el cálculo de usuarios aportan conocimientos o
resultados. ideas para mejorar un resultado.
• Frontend: Parte del desarrollo J
web que se encarga de la interfaz
• JavaScript: Lenguaje de
gráfica y la interacción directa con
programación utilizado para
el usuario.
añadir interactividad y
• Framework: Conjunto de funcionalidades dinámicas a
herramientas y bibliotecas páginas web.
predefinidas que facilitan el
• jQuery: Biblioteca de JavaScript
desarrollo de aplicaciones.
que simplifica la manipulación del
G DOM, eventos y animaciones.
• GD Library: Biblioteca en PHP L
utilizada para la manipulación de
• Login: Pantalla o proceso de
imágenes, como la creación de
inicio de sesión que permite a los
gráficos o esquemas.
usuarios acceder al sistema
• Generación de portadas: introduciendo credenciales como
Funcionalidad que permite crear usuario y contraseña.
diseños personalizados para
M
documentos o artículos.
• Macros: Secuencias
H
automatizadas de comandos o
• Hashing: Proceso de convertir instrucciones programadas para
datos en un formato cifrado que no realizar tareas repetitivas en
puede ser revertido fácilmente, aplicaciones como Excel.
utilizado para proteger
• Modelo relacional: Estructura de
contraseñas.
datos que organiza la información
• HTML (HyperText Markup en tablas relacionadas por claves
Language): Lenguaje estándar foráneas.
para estructurar contenido en la
P
web.
• PHP (Hypertext Preprocessor):
• Hosting: Servicio que
Lenguaje de programación del
proporciona almacenamiento en
lado del servidor utilizado para
línea para alojar sitios web o
construir aplicaciones web
aplicaciones.
dinámicas.
I
• Progresividad: Incremento
• Interfaz gráfica: Diseño visual gradual en un proceso, como una
que facilita la interacción del barra de progreso que refleja el
usuario con el sistema a través de avance de una encuesta o tarea.
elementos visuales como botones,
menús y formularios.

107
 • Publicación científica: permite crear, gestionar y
Documento formal que presenta manipular bases de datos de
resultados de investigaciones, manera eficiente.
generalmente revisado por pares y
T
destinado a la comunidad
académica. • Toastr: Biblioteca de JavaScript
para mostrar notificaciones
R
emergentes elegantes y no
• Requerimientos funcionales: intrusivas.
Especificaciones que describen
• TTS (Text-to-Speech):
qué debe hacer un sistema para
Tecnología que convierte texto en
cumplir con las necesidades del
voz, utilizada para crear
usuario.
narraciones automatizadas en
• Requerimientos no funcionales: videos.
Características del sistema
U
relacionadas con su calidad, como
rendimiento, seguridad y • Usabilidad: Grado en que un
usabilidad. sistema puede ser utilizado con
eficacia, eficiencia y satisfacción
• Respuestas a reactivos:
por parte de los usuarios.
Proceso de interacción en el que
los encuestados responden a V
preguntas evaluativas utilizando
un control específico. • Vegas: Librería JavaScript para la
creación de fondos dinámicos con
S transiciones y efectos visuales.
• Seguridad (Informática): • Visualización de datos:
Prácticas y tecnologías Representación gráfica de
destinadas a proteger los datos y información para facilitar su
la integridad de un sistema contra análisis e interpretación.
accesos no autorizados.
W
• SQL (Structured Query
Language): Lenguaje utilizado • Web responsiva: Diseño que
para interactuar y gestionar bases adapta la apariencia y
de datos relacionales. funcionalidad de un sitio web a
diferentes dispositivos y tamaños
• Sistema gestor de bases de de pantalla.
datos (SGDB): Software que

108
Ilustraciones y esquemáticos
Ilustración 1 - Archivo de Excel inicial de la encuesta que se enviaba a los encuestados y
fue utilizado como base .......................................................................................................... 3
Ilustración 2 - Esquematización del sistema de ponderación de cada reactivo ................... 5
Ilustración 3 - Esquemático de la interacción de un usuario encuestado ............................. 6
Ilustración 4 - Modelo relacional de las tablas que conforman la base de datos ............... 13
Ilustración 5 - Progreso de la programación de la plataforma............................................. 22
Ilustración 6 - Flujo de interacción del inicio de sesión ....................................................... 23
Ilustración 7 - Pantalla de login ............................................................................................ 24
Ilustración 8 - Página de #inicio para el Panel Administrativo ............................................. 24
Ilustración 9 - Página de Gestión de usuarios (#gestionUsuarios) para usuarios
administradores .................................................................................................................... 25
Ilustración 10 - Sección para la creación de nuevos usuarios dependiendo de su tipo ..... 25
Ilustración 11 - Detalles desplegados al momento de crear una nueva cuenta de usuario 26
Ilustración 12 - Página para la visualización de los resultados de cada encuesta activa
relacionada a un usuario encuestado de forma individual (#verResultados) ..................... 27
Ilustración 13 - Ventana emergente visible al dar clic "Ver Progreso" por cada registro. ... 28
Ilustración 14 - Descarga de los archivos en Excel con las respuestas de cada encuesta
con el formato solicitado en los requerimientos, una vez que se haya terminado por
completo ............................................................................................................................... 28
Ilustración 15 - Página para la visualización y edición de Factores que se muestran a
evaluar en la encuesta (#gestionarFactores) ...................................................................... 29
Ilustración 16 - Ventana modal en #gestionFactores que permite modificar el
contenido/descripción de cada factor. Su nombre no puede ser modificado...................... 29
Ilustración 17 - Página para la actualización de los Sectores disponibles, además de su
creación o eliminación (#gestionSectores) .......................................................................... 30
Ilustración 18 - Ventana modal activada al opimir el botón "Agregar Sector" para
incorporar este nuevo dato para su uso. ............................................................................. 31
Ilustración 19 - Página para cambiar los nombres de las categorías mostradas en la
encuesta (#gestionCategorias) ............................................................................................ 32
Ilustración 20 - Página de apertura a la encuesta visible para cualquier usuario
encuestado que inicie sesión (encuesta.php) ...................................................................... 33
Ilustración 21 - Página correspondiente a una categoría en específico al momento de
responder la encuesta y sus reactivos correspondientes
(encuesta.php#respondiendoEncuesta) .............................................................................. 33
Ilustración 22 - Diagrama de flujo para la apertura de la encuesta por parte de usuarios
encuestados. ........................................................................................................................ 35
Ilustración 23 - Captura de pantalla mostrando la linea del tiempo de un video en edición
.............................................................................................................................................. 36
Ilustración 24 - Captura de pantalla de la encuesta final desplegada (portada) ................. 37
Ilustración 25 - Extracto del reporte final de las respuestas ................................................ 42
Ilustración 26 - Extracto del archivo en Excel con todas las respuestas generadas con
filtros ..................................................................................................................................... 42
Ilustración 27 - Captura de pantalla con la solución existente que se tomó como base .... 43

109
Ilustración 28 - Esquema preliminar de la primera propuesta de interfaz de usuario ........ 45
Ilustración 29 - Interacción entre usuario y sistema ............................................................ 47
Ilustración 30 - Apertura y procesos principales de la microaplicación ............................... 51
Ilustración 31 - Captura de pantalla de la programación de la microaplicación en curso .. 52
Ilustración 32 - Captura de pantalla con la entrada de datos vacía .................................... 52
Ilustración 33 - Captura de pantalla con los datos devueltos .............................................. 53
Ilustración 34 - Captura de pantalla de la distribución de la microaplicación en un grupo de
Facebook con temática de Biodigestores ............................................................................ 54
Ilustración 35 - Extracto de los planteamientos para el desarrollo del proyecto en la
primera sesión de la entrevista para generar los requerimientos de software ................... 56
Ilustración 36 - Diagrama de clases con las entidades principales del backend
establecidas en sus funcionalidades ................................................................................... 71
Ilustración 37 - Diagrama de secuencia preliminar del flujo para la apertura de
publicaciones posterior a su revisión ................................................................................... 72
Ilustración 38 - Diagrama de secuencia preliminar de la revisión de artículos realizados
por los usuarios para posteriormente ser devueltos con correcciones o publicados ......... 72
Ilustración 39 - Esquemático simplificado del flujo de información presente en Axotl Xires
.............................................................................................................................................. 73
Ilustración 40 - Arquitectura del backend (API REST) para el consumo de información y
archivos estáticos como imágenes ...................................................................................... 74
Ilustración 41 - Diagrama de secuencia para el establecimiento de una autenticación para
un usuario sin privilegios administrativos ............................................................................. 74
Ilustración 42 - Flujo completo preliminar para la revisión y aprobación de publicaciones 75
Ilustración 43 - Identidad oficial (versión banner) de Axotl Xires. Trabajo propio ............... 76
Ilustración 44 - Muestra de los navegadores empleados al momento de desarrollo y la
ejecución de pruebas ........................................................................................................... 79
Ilustración 45 - Primera apertura de Axotl Xires en Microsoft Edge .................................... 80
Ilustración 46 - Comportamiento de la API REST en la apertura ........................................ 81
Ilustración 47 - Comportamiento en Red de la carga de contenido al momento de
renderizar la página de apertura .......................................................................................... 82
Ilustración 48 - Muestra de la página completamente renderizada con los loaders
desactivados dada a la carga completa del contenido ........................................................ 82
Ilustración 49 - Muestra del consumo de red y datos transferidos ...................................... 83
Ilustración 50 - Consumo de la API REST con el consumo de información asociado a un
perfil de usuario .................................................................................................................... 85
Ilustración 51 - Análisis del comportamiento de un SVG animado representando un loader
renderizado preparando el contenido posterior a mostrar .................................................. 87
Ilustración 52 - Comportamiento del componente asociado a la creación de portadas
personalizadas (preliminar) .................................................................................................. 88
Ilustración 53 - Alerta generada a manera de control de excepciones al cargar una imagen
para crear una portada ......................................................................................................... 90
Ilustración 54 - Almacenamiento local de la imagen proporcionada por el usuario ............ 91
Ilustración 55 - Muestra de las funcionalidades para colocar texto y su personalización
dentro del canvas donde se crea la portada ........................................................................ 91
Ilustración 56 - Vista para la edición de una publicación una vez que esta ha sido
guardada como borrador ...................................................................................................... 92

110
Ilustración 57 - Consumo de la API REST y almacenamiento de archivos estáticos
(imágenes) - Preliminar ........................................................................................................ 92
Ilustración 58 - Consumo de imágenes de portada asociadas a una publicación desde la
API REST ............................................................................................................................. 94
Ilustración 59 - Señalamiento de área de mejora para el consumo de archivos estáticos
por defecto desde la API REST ........................................................................................... 94
Ilustración 60 - Apertura de la página de búsqueda con skeleton loaders mostrados
mientras se consultan los resultados ................................................................................... 95
Ilustración 61 - Muestra de la página de búsqueda con publicaciones que cumplan con los
criterios de búsqueda ........................................................................................................... 96
Ilustración 62 - Consulta de información desde la API REST que se hace al instante que
se coloca cualquier carácter en el cuadro de búsqueda ..................................................... 97
Ilustración 63 - Muestra de la carga inicial de la página pára ver una publicación mientras
se consultan los datos desde la API REST ......................................................................... 98
Ilustración 64 - Renderizado completo de una página de publicación ................................ 99
Ilustración 65 - Consumo de información asociadas a una publicación desde la API REST
............................................................................................................................................ 100

111