Ingeniería y sus
Alcances, Revista de Investigación
Septiembre-diciembre
2024 / Volumen 8 / No. 22
ISSN:
2664 – 8245
ISSN-L: 2664 - 8245
https://revistaingenieria.org
pp. 163 - 175
Diseño de un
sistema distribuido para gestión de OLT
Design of a distributed system for OLT management
Projeto de um sistema distribuído para gestão de OLT
Carlos Peliza
https://orcid.org/0000-0002-2901-185X
Leandro Alfaro
https://orcid.org/0009-0008-6905-5460
Universidad
Nacional de La Matanza. San Justo, Argentina
Artículo recibido
19 de julio 2024 | Aceptado 21 de agosto 2024 | Publicado 23 de octubre 2024
Escanea en tu
dispositivo móvil o revisa este artículo en:
https://doi.org/10.33996/revistaingenieria.v8i22.125
RESUMEN
En Argentina, las PYME operan con un ajustado sistema
de costos que, en entornos de competencia, debe buscar la reducción constante.
El objetivo es proponer un sistema distribuido para gestión de OLT. Se enmarca
en un enfoque mixto y tipo proyectiva y se adopta un diseño descriptivo. Se
llevó a cabo un diagnóstico inicial y una revisión documental. La metodología empleada incluyó un diagnóstico basado en
una revisión bibliográfica. Los resultados identificaron una demanda
insatisfecha en el mercado por sistemas de gestión intuitivos, escalables y
adaptados a las necesidades específicas de las PYME ISP. Las empresas buscan
herramientas que les permitan optimizar sus operaciones, mejorar la atención al
cliente y reducir costos. Las conclusiones delinean un modelo de desarrollo
diseñado para satisfacer las necesidades específicas de las PYME ISP en la
gestión de redes FTTH. Este modelo, enriquecido por los aportes teóricos y
técnicos de la academia, garantiza una solución personalizada y adaptable a las
particularidades del sector.
Palabras clave: Diseño; Distribuido; G-Pon; Microservicios; PYME
ABSTRACT
In Argentina, SMEs operate with an adjusted cost
system that, within competitive environments, must seek constant reduction. The
objective is to propose a distributed system for OLT management. It is framed
in a mixed and projective approach and adopts a descriptive design. An initial
diagnosis and document review were carried out. The methodology employed
included a diagnosis based on a bibliographical review. The results identified
an unsatisfied demand in the market for intuitive, scalable and adapted
management systems adapted to the specific needs of PYME ISPs. Companies are
looking for tools that allow them to optimize their operations, improve customer
service and reduce costs. The conclusions outline a development model designed
to satisfy the specific needs of SME ISPs in the management of FTTH networks.
This model, enriched by theoretical and technical contributions from academia,
guarantees a personalized and adaptable solution to the particularities of the
sector.
Key words: Design; Distributed; G-Pon; Microservices; SME
Na Argentina, o PYME opera com um sistema de custos ajustado que, em
ambientes de competência, deve buscar a redução constante. O objetivo é propor
um sistema distribuído para gerenciamento de OLT. É marcado em uma abordagem
mista e tipo projetiva e adotado um design descritivo. Foi levado a cabo um
diagnóstico inicial e uma revisão documental. A metodologia empregada incluiu
um diagnóstico baseado em uma revisão bibliográfica. Os resultados
identificaram uma demanda insatisfatória no mercado por sistemas de
gerenciamento intuitivos, escalonáveis e adaptados às necessidades específicas
do ISP PYME. As empresas buscam ferramentas que lhes permitam otimizar suas
operações, melhorar a atenção ao cliente e reduzir custos. As conclusões
delineiam um modelo de desenvolvimento projetado para satisfazer as
necessidades específicas do ISP PYME no gerenciamento de redes FTTH. Este modelo,
enriquecido pelos esportes teóricos e técnicos da academia, garante uma solução
personalizada e adaptável às particularidades do setor.
Palavras-chave: Design; Distribuído; G-Pon; Microsserviços; PME
INTRODUCCIÓN
Un área de intensa investigación en los
últimos años, ha sido la gestión de redes ópticas pasivas (PON) y, en
particular, de los terminales de línea óptica (OLT). Numerosos estudios han
abordado la necesidad de desarrollar sistemas de gestión más eficientes y
escalables para hacer frente al creciente volumen de datos y la complejidad de
las redes de acceso de nueva generación (Agenda digital para América Latina y
el Caribe, (ELAC), 2022) afirma que, las tecnologías digitales han crecido
exponencialmente y su uso se ha globalizado.
En este sentido, un aspecto relevante
al diseñar un sistema de gestión de OLT es la capacidad de garantizar la
calidad de servicio (QoS) y la seguridad de la red. A este respecto, Li et al.
(2021) presentan un algoritmo de asignación de recursos dinámico que optimiza
la QoS en redes PON, considerando factores como el tráfico variable y las
restricciones de capacidad. Los autores enfatizan la necesidad de mecanismos de
seguridad robustos para proteger la información sensible y prevenir ataques
cibernéticos.
En el contexto argentino, las
Pequeñas y Medianas Empresas (PYME) del sector de servicios de internet (ISP)
enfrentan un desafío constante como es, optimizar sus costos operativos en un
mercado altamente competitivo. Por tradición, la gestión de las redes de estos proveedores
se ha llevado a cabo en forma manual, lo cual implica una considerable
inversión de tiempo y recursos humanos en tareas repetitivas y propensas a
errores. De allí que, a medida que la economía global se vuelve cada vez más
competitiva y digitalizada, las PYMEs deben adaptarse para sobrevivir y
prosperar (BeJob, (2023).
Como alternativa, algunas PYME
recurren a soluciones de gestión remota ofrecidas por proveedores extranjeros,
sin embargo, estas suelen presentar costos elevados y una dependencia de
divisas extranjeras (CEPAL, 2011). Ante este escenario, surge la necesidad de
desarrollar soluciones de gestión de redes locales que sean eficientes,
escalables y adaptadas a las necesidades específicas de las PYME argentinas. Se
debe recalcar además que, las PYMES están integradas al aparato productivo,
como parte de la cadena de valor, coadyuva en la diversificación y dinamización
de la economía. Ello se manifiesta en su potencialidad para la creación de
empleo y fomentar la riqueza (Cardozo, et al., 2012)
En este sentido, afrontar la
utilización y desarrollo de un framework, es inalcanzable para cada PYME en
particular. Sin embargo, el espíritu emprendedor, la comunión de intereses y la
colaboración de la academia, puede conformar un universo propicio para encarar
tal desafío. Cabe destacar que según UNIR (2022) un framework es un esquema o
marco de trabajo que ofrece una estructura base para elaborar un proyecto con
objetivos específicos, una especie de plantilla que sirve como punto de partida
para la organización y desarrollo de software.
Hay que resaltar también que, el
dinámico panorama tecnológico argentino, las Pequeñas y Medianas Empresas
(PYME) del sector de servicios de internet (ISP) se enfrentan a un desafío
apremiante como es optimizar sus operaciones en un contexto de creciente
competencia y volatilidad económica. Además, la dependencia de soluciones
extranjeras, además de generar una fuga de divisas, limita la capacidad de
adaptación a las particularidades del mercado local. Esta situación genera una
brecha digital que dificulta la competitividad de las PYME argentinas y
restringe el acceso a servicios de internet de calidad para un amplio sector de
la población.
En atención a todo lo planteado, esta
investigación tiene como objetivo proponer un sistema distribuido para gestión
de OLT y sintetiza los pasos seguidos en la búsqueda de un modelo funcional de
desarrollo que brinde la posibilidad de gestionar una red FTTH a PYME ISP
basado en las necesidades y experiencias propias del universo a satisfacer con
el aporte técnico y teórico de la academia. Por lo dicho, se ha dividido en
tres secciones: La opinión del ISP, el Back End y el Front End.
MÉTODO
El enfoque de la investigación se
abordó desde un enfoque mixto combinando elementos tanto cualitativos como
cuantitativos, para ofrecer una visión integral de la problemática de las PYME
ISP en Argentina, es tipo proyectiva y se adopta un diseño descriptivo. La
metodología empleada incluyó un diagnóstico basado en una revisión bibliográfica.
Se inicia con un diseño descriptivo, caracterizando el estado actual de la
gestión de redes en estas empresas. A partir de este diagnóstico, se proyecta
una solución innovadora. El diagnóstico, basado en una revisión bibliográfica y
entrevistas con expertos, permitió identificar las brechas existentes en los
sistemas de gestión de OLT.
Para sintetizar, detectados los
problemas comunes que enfrentaban los ISP FTTH encuestados en la gestión de su
sistema de ABM(Alta/Baja/Modificación), con posterioridad a la selección
acotada de los problemas, se avanzó con la observación sobre la forma de
solución posible de implementar y finalmente, con la ayuda de los medios
brindados por un ISP se decidieron las mejores soluciones arquitectónicas de
red según la teoría y práctica actual.
RESULTADOS Y DISCUSIÓN
Diagnóstico para recabar las necesidades a satisfacer
Para diseñar cualquier sistema de
usuario es fundamental conocer los puntos problemáticos que dicha
implementación busca resolver. En ese sentido, resulta primordial la opinión
del potencial beneficiario, pero de acuerdo lo expresado por Donald Norman (1988), en su libro “Psicología de los objetos
cotidianos”, también es imperativo que el desarrollo permita logra una
remembranza de algo conocido, para facilitar la etapa de aprendizaje del uso.
Por lo antes expuesto, para esta
investigación se ha consultado a PYME ISP de la zona oeste del conurbano
bonaerense, de la labor de encuestas realizadas se pudo determinar 43% de los
encuestados no poseen sistemas de gestión automatizados, pero quienes lo hacen
(57%), expresan que su uso es intuitivo, destacando SmartOLT como el más usado.
Por otra parte, la forma de pago sobresaliente, para las suscripciones es el
abono por cantidad de OLT, aunque todos manifiestan su preferencia por un
sistema de canon anual y pagadero en pesos.
Un punto expresado como positivo se
encontró al consultar sobre la conveniencia de permitir la operación por lotes
mediante la ingesta de archivos ofimáticos (de extensión .xls o .csv). El procesamiento
también llamado batch es una característica que permite importantes ahorros en
tiempo de trabajo.
Otro indicador interesante de la
tarea de encuestas realizadas es el referido a la gestión de los clientes, como
se muestra en la figura 1, donde se pone de manifiesto la preferencia de
realizar la diligencia de los abonados al servicio en un punto unificado,
conocido como oficina central, aunque para ello deba usarse un sistema remoto.
Es decir, los ISP prefieren gestionar sus servicios usando un sitio único, aun
teniendo la posibilidad de tener a sus operadores trabajando desde sitios
remotos.
Figura 1. Preferencia sobre la forma
de gestión del Cliente
*SGC (Sistema de Gestión de Clientes)
Un punto destacado dentro de las
opiniones recabadas, fue la referencia a mejoras respecto de los productos que
los ISP utilizan al gestionar, donde la necesidades recogidas mencionaron que
les gustaría contar con un medio que se integre con otros sistemas de gestión
(por ejemplo de stocks) y consideraban virtuoso que el sistema de clientes
permitiera de manera sencilla el blanqueo y reseteo de la clave de WIFI de los
usuarios de su red, aspecto que identificaron como una tarea que ocupa gran
parte de los reclamos que reciben.
Diseño de un Back End como sistema distribuido
El Back End o Core de un sistema
constituye una de las partes principales de la estructura, la otra es
denominada Front End. Es posible trazar una semejanza con la arquitectura
Servidor – Cliente donde el Back cumple la función de brindar servicios al
Front. Una de las diferencias que puede establecerse entre ambas desde el punto
de vista del programador radica en el acceso que tiene el usuario final del
desarrollo luego de puesto a funcionar, así las cosas, una vez funcionando solo
accede el desarrollador o personal capacitado de mantenimiento. Por el
contrario, el Front End, es la parte donde el cliente ingresa regularmente para
ejecutar su trabajo, es la sección expuesta a la operación de plantilla y la
que debe ser intuitiva en el uso.
Partiendo de los preceptos de
Arquitectura limpia (Martin, 2017) para
cumplir con un correcto desarrollo debe buscarse la separación en dependencias
que serán una capa para la lógica del negocio y otra para la interfaz gráfica
de usuario. Esta situación, adicionalmente, permite distribuir los recursos
para aumentar el avance, potenciando las habilidades de cada desarrollador.
Dentro de las decisiones tomadas para
desarrollar un sistema de Back-End, una selección importante fue optar entre
sistemas monolíticos o distribuidos. El análisis de pros y contras de cada tipo
de arquitectura es un tema en sí mismo. Sin embargo, en el caso de este
trabajo, se ha considerado la escalabilidad del sistema como el factor
determinante. No afirmamos que un enfoque sea mejor que el otro, sino que
sirven para propósitos distintos. Las ventajas principales del enfoque
monolítico por sobre el enfoque de microservicios son:
1- la velocidad de desarrollo de un monolito es bastante
superior comparado con un enfoque de microservicios. no hay que estar
integrando diferentes servicios con sus respectivas APIS como sea cual fuere el
protocolo de comunicación.
2- El monolito requiere una destreza técnica menor
para su implementación, sumado a lo anterior, resulta más fácil relacionarse
entre módulos, los cuales además son más fáciles de debuggear (proceso de
encontrar y solucionar errores en el código fuente de cualquier software) a la
hora de buscar problemas.
La principal contra del monolito es
que genera problemas de escalabilidad a largo plazo si no se planifica bien la
cantidad de usuarios estimados y funcionalidades prestadas (Reche, 2022). En
este sentido, optar por arquitectura de sistemas distribuidos, debe mencionarse
como una opción costosa cuando hace uso de recursos, pero en los momentos
iniciales del trabajo y debido a la baja demanda, ello no ocurre. Por lo tanto,
se ha considerado la posibilidad de migrar lentamente de un servidor a una
estructura en grilla cuando sea necesario.
Siguiendo las actividades
estructurales: comunicación, planeación, modelado, construcción y despliegue (Pressman, 1982), en la actualidad el trabajo
transita por la etapa de modelado del sistema distribuido. La figura 2 exhibe
una primera aproximación mediante el uso de microservicios.
Figura 2. Modelado de la arquitectura
distribuida seleccionada para el uso mediante microservicios.
Los microservicios son tanto un
estilo de arquitectura como un modo de programar software. Se centran en dividir
las aplicaciones en elementos más pequeños e independientes entre sí
(Whitestack, 2023). De esta forma conseguiremos crear aplicaciones que sean más
fáciles de escalar, de dar mejor mantenimiento y que sus partes puedan ser
reutilizables. a diferencia del enfoque tradicional y monolítico de las
aplicaciones, en el que todo se compila en una sola pieza. (Orozco Fernández, 2024).
La Figura 3, a continuación, expone
la opción monolítica luego descartada para este trabajo en función del criterio
de selección elegido. En resumen, entre dos opciones de sistemas, hemos elegido
la más fácilmente escalable.
Figura 3. Comparativa gráfica entre
arquitecturas monolítica y por microservicios
Patrones de diseño en microservicios usados para la investigación
En el diseño del patrón
arquitectónico que se usará en la solución se combinan la solución API Gateway donde
en esencia, un
API Gateway actúa como un punto de entrada centralizado para todas las
solicitudes de clientes que acceden a servicios dentro de un sistema con la
arquitectura dirigida por eventos que se utiliza para responder a un “evento”
en tiempo real o lo más cercano posible a que este ocurra.
La API Gateway se sitúa entre las
aplicaciones de clientes y los microservicios funciona como un intermediario
entre los clientes y los diferentes microservicios que componen la aplicación
(ver abajo a la izquierda de la figura 2)., y como un proxy inverso que
redirige las solicitudes del cliente a los servicios. Además de esto, la puerta
de enlace de la API puede proporcionar otros servicios transversales como
autenticación, terminación SSL y caché.
Las razones para utilizar este patrón en vez de la
comunicación directa son varias:
Facilita que los clientes puedan
acceder a los diferentes servicios del sistema, ya que proporciona
una única interfaz de entrada para ellos. De esta forma, los clientes
no tienen por qué conocer la ubicación específica de cada servicio, lo que
reduce la complejidad y el acoplamiento.
Permite gestionar de manera
centralizada aspectos como la seguridad, la autenticación, la autorización y el
monitoreo. Esto simplifica la implementación de políticas de seguridad y
facilita la aplicación de actualizaciones o cambios en estas políticas. Permite
realizar enrutamiento inteligente de solicitudes, redirigiendo las peticiones a
los servicios correspondientes en función de diversos criterios, como la ruta
de la URL, el tipo de solicitud o los encabezados HTTP. Esto mejora la
flexibilidad y la capacidad de escalabilidad de la arquitectura.
A su vez puede realizar funciones de
caché, compresión y optimización de solicitudes para mejorar el rendimiento
general del sistema. Además, puede implementar técnicas de balanceo de carga
para distribuir la carga de manera equitativa entre los servicios subyacentes,
Figura 4.
Figura 4. Esquema de Arquitectura
basada en eventos más API Gateway. Un evento dispara acciones desde el api
gateway a los microservicios que responden en "tiempo real"
Diseño de un Front End por requisitos no funcionales
El autor Garrett (2021) explica en su
libro "The Elements of User Experience" que crear un diseño de
interacción exitoso requiere más que simplemente crear un diseño visual que sea
agradable. También es fundamental definir y satisfacer las necesidades de los
usuarios.
El autor aporta una comprensión de la
experiencia del usuario y afirma que el contenido es tan importante como la
experiencia de navegación de un sitio; por lo tanto, es lo que siente una
persona al interactuar con el producto o servicio de una empresa. Cuando ocurre
esta interacción, las respuestas generadas, como sensaciones y sentimientos, se
analizan y se trabajan para que sean siempre las mejores posibles. La
investigación ha sido atravesada por dos vertientes de análisis, el cromático y
el funcional.
En primer lugar, buscando brindar una
interfaz de carácter profesional y frío según los conceptos y ejercicios de
Albers (Interacción del color, 2010).
Figura 5:
Figura 5. Imagen extraída de La
interacción del color de Josef Albers
Desde el punto de vista funcional, se
ha optado por usar lo que Adobe color identifica como tendencias en interfaz de
usuario, que puede observarse en el vínculo Tendencias de color, Stock, colores de Behance | Adobe
Color. Entre las preferencias también se
optó por colores conocidos por su asociación al ecosistema profesional como ser
azul.
El azul es tranquilidad, confianza y
estabilidad. Los diferentes tonos de azul, como el azul marino, son los mejores
colores para evocar un sentimiento de confianza. Es el color de logo más
utilizado por las empresas de la lista Fortune 500. Además, este color es uno
de los favoritos tanto de los hombres como de las mujeres. El azul es el color
de logo preferido por las empresas tecnológicas y financieras.
Sintetizando, se eligió usar colores
combinados para la presentación visual como lo indica la figura 4 y colores de
reconocido uso corporativo para las partes que requieren la intervención de
operadores Figura 5, todos dentro del ámbito de los definidos como fríos,
Figura 6.
Figura 6. Interfaz de accesos al sistema
Figura 7. Secciones operativas de
colores corporativos
Para el desarrollo de la aplicación,
la opción considerada como más conveniente por su actual uso en la industria de
la programación fue React (https://es.react.dev/). Permite combinar interfaces de usuario, llamadas componentes, para
formar pantallas, páginas y aplicaciones. Brinda la posibilidad de construir tanto
aplicaciones web como nativas utilizando las mismas habilidades y reutilizando
los componentes.
Adicionalmente, el uso de
programación reactiva y el paradigma “Observer”,
permiten que, en lugar de sondear eventos para los cambios, los eventos se realicen
de forma asíncrona para que los observadores puedan procesarlos (durante la
investigación, los observadores son los elementos de React que definiremos en
la interfaz), Figura 8.
Figura 8. Caracterización de una
aplicación reactiva
Por otro lado, y como parte de las
decisiones operativas para iniciar el desarrollo, se optó por usar prototipado
no funcional basados en que el requisito funcional lo especifica el usuario,
mientras que el requisito no funcional lo especifica personal técnico como arquitecto,
líderes técnicos y desarrolladores de software y en los momentos iniciales del
trabajo, las primeras definiciones deben correr por cuenta de estos últimos.
Actualmente, el trabajo se halla en
la configuración de un prototipo funcional evolutivo que mejorará a medida que
se realicen más iteraciones entre usuario, diseñador del Front End y pruebas de
validación funcional. Estamos pasando de la etapa de usabilidad a la de
experiencia de usuario. Mas precisamente, en la etapa de usabilidad se intentó
una interfaz minimalista con pocos ítems e información, con colores que no
distraigan al usuario y que sea eficiente al realizar una acción, buscando
minimizar la cantidad de tareas o pasos para poder cumplirla.
CONCLUSIONES
A partir del análisis exhaustivo de
las necesidades de las PYME ISP y del diseño conceptual del sistema de gestión,
se pueden extraer conclusiones significativas y trazar un camino claro hacia la
implementación exitosa de esta solución. En primer lugar, se ha identificado
una demanda insatisfecha en el mercado por sistemas de gestión intuitivos,
escalables y adaptados a las necesidades específicas de las PYME ISP. Las
encuestas realizadas han revelado que las empresas buscan herramientas que les
permitan optimizar sus operaciones, mejorar la atención al cliente y reducir
costos.
En segundo lugar, el diseño
propuesto, basado en una arquitectura de microservicios, ofrece una solución
flexible y escalable que puede adaptarse a las necesidades cambiantes de las
PYME ISP. La modularidad de esta arquitectura permite desarrollar y desplegar
nuevas funcionalidades de forma independiente, facilitando la evolución del
sistema a lo largo del tiempo. Sin embargo, es fundamental reconocer que el
desarrollo de un sistema de esta envergadura requiere de una planificación
cuidadosa y una ejecución rigurosa.
En otros puntos conclusivos se tiene
que, la interacción academia-sistema productivo suele atravesar complicaciones
entre las que pueden mencionar el pasaje a productivo de entornos que no han
sido sometidos a un profundo testeo. En tal sentido, un diseño arquitectónico
funcional y robusto debe someterse a test que garanticen su funcionamiento,
pero contar con un entorno de pruebas similar a uno real generalmente no es
posible. En particular, las pruebas de estrés son esenciales, pero contar con
un entorno de pruebas que simule condiciones reales a gran escala no es
económicamente viable. Por ejemplo, no es posible probar el sistema con 4000
clientes simultáneos, ni disponer de un sistema con esa capacidad solo para
pruebas.
De igual forma, la transferencia de
conocimiento en esta investigación ha sido bidireccional y dinámica. Los
estudiantes, como principales receptores, han adquirido habilidades prácticas y
conocimientos especializados al abordar un problema real del sector. Es así
como, este proceso no solo ha enriquecido la formación académica, sino que
también genera un impacto positivo en su capacidad de innovación y resolución
de problemas. La mediación en este intercambio ha sido clave para garantizar la
pertinencia de la investigación y su alineación con las necesidades del sector.
La perspectiva de incluir como
función la innovación social en las universidades, es una de las fuerzas de
cambio más importantes que pueden ser asumidas. Con la reformulación de las
relaciones sociales (tanto globales como locales) hacia una sociedad del
conocimiento, la universidad está en vías de una transformación profunda. No se
trata de un cambio parcial o en algún nivel educativo específico, tampoco de la
redefinición de los actores o de los sectores que participan directamente en
ella, sino del pasar de los ambientes de enseñanza establecidos por los
profesores a los de los estudiantes, de la enseñanza al aprendizaje, de los
sujetos pasivos y receptivos a la gestión y a la autoridad de los sujetos como
entes activos y participativos. (Didriksson
Takayanagui, 2015)
En resumen, los ISP pyme podrán
contar con un sistema de gestión ABM de clientes desarrollado de acuerdo con
sus necesidades, sin que ello los obligue a contar con personal capacitado en
informática o desarrollo de sistemas, ya que no forma parte del Core business.
Los alumnos, pueden desarrollar su espíritu emprendedor a la vez que actuando
en campo reciben de primera mano la problemática profesional a la que se
enfrentan en su campo de estudio. Mientras que la academia deja de ser un
arcano para volverse una entidad cercana tanto en la solución de problemas como
en la generación de profesionales.
Los próximos pasos de este trabajo de
investigación y desarrollo serán los de focalizar los esfuerzos en poner
productiva nuestra arquitectura, mientras se optimiza y depura la interfaz de
usuario.
CONFLICTO DE INTERESES.
Los autores declaran que no existe
conflicto de intereses para la publicación del presente artículo científico.
REFERENCIAS BIBLIOGRÁFICAS
Albers, J. (2010). Interacción del color. Alianza
Editorial.
BeJob (2023). Desafíos y
Oportunidades para las PYMEs en la Era Digital: Cómo Superar Obstáculos y
Potenciar el Crecimiento. https://bejob.com/desafios-y-oportunidades-para-las-pymes/
Didriksson, A. (2015). El futuro anterior. La universidad como
sistema de producción de conocimientos,aprendizajes e innovación social.
CLACSO.
Li,
Z., Wang, J., y Zhang, Q. (2021). Dynamic resource allocation for QoS
provisioning in optical access networks. IEEE/ACM Transactions on Networking,
29(2), 612-625. https://onlinelibrary.wiley.com/doi/10.1155/2021/8381998
Cardozo
E., Velasquez de Naime Y, Rodriguez Monroy C . (2012) http://adingor.es/congresos/web/uploads/cio/cio2012/SP_06_Entorno_Economico_Gestion_Economica_y_Finanzas/1345-1352.pdf
CEPAL (2011) Eliminando
barreras: El financiamiento a las pymes en América Latina.
https://repositorio.cepal.org/server/api/core/bitstreams/7336fcfb-b028-4188-b089-68107c721da6/content
CEPAL. Tecnologías digitales
para un nuevo futuro ELAC (2022). Li, Z., Wang, J., y Zhang, Q. (2021). Dynamic resource allocation for QoS
provisioning in optical access networks. IEEE/ACM Transactions on Networking,
29(2), 612-625. https://onlinelibrary.wiley.com/doi/10.1155/2021/8381998
Garrett,
Jesse James (2021) Elementos de la Experiencia de Usuario.
https://www.uxables.com/diseno-ux-ui/elementos-de-la-experiencia-de-usuario-jesse-james-garrett/
Martin,
R. C. (2017). Clean Architecture-A
craftsman's guide to software structure a design. Pearson.
https://doi.org/978-0134494166
Norman,
D. (1988). The Psychology of Everyday
Things. Basic Books. https://doi.org/0465067093
Orozco Fernández, A. (Junio
17/2024). Hiberus Blog. https://www.hiberus.com/crecemos-contigo/patrones-de-diseno-en-microservicios/
Pressman, R. (1982). Ingenieria del Software. Un Enfoque
Practico. Mc Graw- Hill. https://doi.org/978-607-15-0314-5
Reche, J. (2022) Monolito o microservicios? Ventajas
y desventajas.
https://www.ithinkupc.com/es/blog/monolito-o-microservicios-ventajas-y-desventajas
UNIR,
(2022) Formación profesional. Framework: qué es, para qué sirve y algunos
ejemplos. https://unirfp.unir.net/revista/ingenieria-y-tecnologia/framework/
Whitestack
(2023) Microservicios: ¿Qué son y qué tipos existen? ¿Cómo funciona su
arquitectura?. https://whitestack.com/es/blog/microservicios/