UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA

La Universidad Católica de Loja

ÁREA TÉCNICA

SISTEMAS INFORMÁTICOS Y COMPUTACIÓN

TRABAJO DE TITULACIÓN

Definición e implementación del ecosistema de negocio del

Proyecto Ascendere mediante la construcción de una
plataforma digital

Autor (a): Hurtado Duarte, Jorge Alcivar - Rosero Soto, Jonathan Andrés

Director (a): Cabrera Silva, Armando Augusto

LOJA - ECUADOR

2022
 2

Dedicatoria

Dedico este trabajo:

A mis padres Jorge Hurtado y Elsa Duarte, quienes me han acompañado durante mi etapa
de crecimiento personal y profesional.

A mis hermanos Edward y Henry por demostrarme su paciencia y gran cariño.

A mí queridos sobrinos Alejandra y Javier quien me ha llenado de muchos momentos de

alegría y felicidad.

A mi querida compañera Ariana, por toda la alegría y paciencia desde el momento que me
acompañó mi vida.

Jorge Hurtado

Dedico este trabajo:

Le dedico este trabajo completamente a mi madre Maritza Maribel Soto Carrión, fuiste y
siempre serás la persona más importante de mi vida. Ojalá hubieses podido estar aquí
para leer este trabajo de titulación ya que sin tus enseñanzas sobre responsabilidad y
dedicación esto no hubiese sido posible.

Jonathan Rosero
 3

AGRADECIMIENTOS

Agradezco…

A la Universidad Técnica Particular de Loja, por la oportunidad brindada de alcanzar un

nuevo reto profesional.

Al Mgtr, Armando Cabrera, director de tesis quien compartió sus conocimientos y

comprensión durante este proceso de aprendizaje.

Al equipo de trabajo Ascendere y a su directora María Isabel Loaiza, por la apertura y

confianza brindada para demostrar mis aprendizajes y conocimientos.

A mis colegas y amigos Bruno, Jonathan, Luis, Ricardo y Ariana con los cuales tuve la
fortuna de coincidir y compartir.

Jorge Hurtado

Agradezco…

A la Universidad Técnica Particular de Loja, por la oportunidad brindada de alcanzar un

nuevo reto profesional.

Al Mgtr, Armando Cabrera, director del trabajo de titulación quien nos tuvo paciencia y nos
supo guiar durante todo este proceso.

A mi padre Carlos Rosero por su apoyo incondicional, con tu ayuda he podido culminar
esta etapa de mi vida, eres el mejor papa que me pudo tocar.

A mis hermanas Ainoha Rosero, Cristina Rosero y Leia Rosero, ustedes han sido la luz
que a alumbrado mi vida en los momentos más difíciles de la misma.

Al equipo de Ascendere a María Isabel Loaiza, Nuve Briceño y Angie Salazar, gracias a su
confianza en nosotros logramos desarrollarnos como profesionales.
 4

A mis amigos de toda esta etapa de mi vida Bruno Esparza, Luis Ortiz, Ricardo Arrobo y
por sobre todo a Jorge Hurtado tu has sido como un hermano y sin ti no hubiese podido
realizar este trabajo yo solo, siempre te estaré agradecido por esto. Y a todos mis amigos
que se mantuvieron pendientes de mí, dándome su cariño y apoyo.

Por último, agradezco a mi compañera de vida Jessica Caraguay por haber estado desde
el principio hasta el fin de este trabajo de titulación, apoyándome durante todo el
desarrollo, por la paciencia que tuviste, por los consejos y por impulsarme a superarme y
seguir mis sueños.

Jonathan Rosero
 5

ÍNDICE DE CONTENIDO

Dedicatoria 1

Agradecimientos 3

Índice de Contenido 4

Resumen 7

Abstract 8

Introducción 9

Capítulo uno 11

Generalidades 11
Problemática 11
Justificación 12
Objetivos 12
Objetivos Específicos 12
Metodología 13
Resultados de la investigación 13
Actividades de la Investigación 13
Resultados de la investigación 13

Capítulo dos 15

Proyecto Ascendere 15
Innovación Docente 15
Proyectos de innovación 16
Buenas Prácticas 16
Semestre Ascendere 16
Formación Docente 17
Evaluación Docente 17
Laboratorio de Investigación e Innovación Docente (LiiD) 17

Capítulo tres 19

Marco teórico 19
Gestión de proyectos 19
Proyectos 19
Importancia de la gestión de proyectos 20
Estándares para la gestión de proyectos 21
ISO 21500:2012 21
 6

Ecosistemas digitales 24
Características y beneficios de los ecosistemas digitales 25
Evolución de los ecosistemas digitales 26
Apertura de los ecosistemas 27
Grupos y dominios de los ecosistemas 29
Aplicaciones CLOUD. 30
Características esenciales de la computación en nube 30
Modelos de servicios en la nube 31
Aplicaciones Tradicionales frente a aplicaciones nativas en la nube 32
Principios de las aplicaciones nativas de la nube 33
Microservicios 34
Arquitecturas orientadas a servicios 35
Características de los microservicios 36
Desafíos de los microservicios 36
Beneficios de los microservicios 36
Cuando utilizar la arquitectura de microservicios 37
Kubernetes 37
Arquitectura de Kubernetes 37
Componentes de Kubernetes 39

Capítulo cuatro 41

Diseño de la solución 41
Metas y limitaciones arquitectónicas 41
Análisis de la plataforma 41
Cadena de valor 42
Mapa de capacidades 42
Esquema de desarrollo 43
Arquitectura de la plataforma 44
Casos de Uso 45
Gestión de convocatorias 46
Gestión de postulación 48
Requerimientos de Usuario 51
Relación entre historias épicas y diagramas de caso de uso. 51
Historias épicas 52
Diagramas de Clase 53
Microservicio de Usuarios 54
Microservicio de Inventario 54
Microservicio de Convocatoria 55
Microservicio de Postulación 56
Microservicio de Proyectos 57
 7

Capítulo cinco 59

Desarrollo 59
Tecnologías empleadas 59
Canalización de DevOps 59
Clúster de kubernetes 60
Servidores multi nube 62
Desarrollo de la Plataforma 62
Diseño de la Plataforma 62
Desarrollo de la canalización de DevOps 64
Desarrollo de microservicios 67
Implementación WSO2 68

Capítulo seis 70

Resultados y conclusiones 70
Plataforma Ascendere 70
Convocatorias 70
Postulaciones 71
Recursos 72
Implementación de microservicios 73
API Manager 74
Conclusiones 74

Capítulo siete 76

Trabajos Futuros 76

Referencias 77
 8

RESUMEN

Tomando en consideración que en el actual mercado empresarial mantenerse

competitivo implica adoptar las mejores prácticas arquitectónicas y operar sistemas de
manera segura, confiable, eficiente, rentable y sostenible; el presente trabajo tiene como
objetivo abordar e implementar los temas de ecosistemas y plataformas digitales dentro
del Proyecto Ascendere, perteneciente a la Universidad Técnica Particular de Loja. El
trabajo se centró en el análisis de las deficiencias respecto a los procesos y actividades de
la gestión de proyectos dentro de Ascendere. Para el análisis se emplea el ciclo de vida de
los proyectos y grupos de procesos como recomienda la ISO 21500. En base al análisis,
para la implementación de la plataforma y asegurar sistemas óptimos se abordan los
cuatro principios de las aplicaciones nativas en la nube, la arquitectura basada en
servicios; la comunicación impulsada por API; la infraestructura de contenedores; y el
proceso de DevOps. Por último, para asegurar el rendimiento de la plataforma se definen
acuerdos de nivel de servicio para evaluar su desempeño.

Palabras claves: ecosistemas digitales, plataformas digitales, gestión de proyectos.

 9

ABSTRACT

Taking into consideration that in the current business market, staying competitive

implies adopting the best architectural practices and operating systems in a safe, reliable,

efficient, profitable and sustainable manner, this paper aims to address and implement the

issues of ecosystems and digital platforms within the Ascendere Project, belonging to the

Universidad Técnica Particular de Loja. The work focused on the analysis of the

deficiencies regarding the processes and activities of project management within

Ascendere. The analysis used the life cycle of projects and groups of processes as

recommended by ISO 21500. Based on the analysis, to implement the platform and ensure

optimal systems, the four principles of cloud-native application, service-based architecture;

API-driven communication; container infrastructure; and DevOps process are addressed.

Finally, to ensure platform performance, service level agreements are defined to evaluate

platform performance.

Keywords: digital ecosystems, digital platforms, project management.

 10

INTRODUCCIÓN

El Proyecto Ascendere es una iniciativa enmarcada en el Plan Estratégico de

Desarrollo Institucional, que nace con el propósito de trabajar y agrupar aquellas iniciativas
que potencien las competencias de los docentes a través de la innovación académica y la
investigación en nuevas metodologías de educación y uso de las TIC, en la Universidad
Técnica Particular de Loja. Ascendere surge con una ideología de empresa tradicional
cuya cadena de valor lineal está enfocada en el desarrollo de proyectos de innovación
educativa, la formación docente y la evaluación constante de los mismos. Los procesos y
operaciones de Ascendere ocurren de forma manual y los objetivos se centran en la
eficiencia operativa, más no en la experiencia del docente como usuario.

Las tecnologías digitales han revolucionado las formas de cómo se crea valor en
las empresas y sectores verticales, incluyendo la educación. En los últimos años, una
extensión de la revolución de la creación de valor en las empresas ha sido la aparición de
plataformas y ecosistemas digitales. Los ecosistemas digitales son un grupo
interdependiente de empresas, personas y/o cosas que comparten plataformas digitales
estandarizadas con un propósito mutuamente beneficioso, como el beneficio comercial, la
innovación o el interés común (Avramakis et al., 2019). Mientras que las plataformas
digitales incluyen plataformas globales que permiten construir una gama de productos
sobre ellas.

A medida que los ecosistemas se afianzan más y capturan más mercados

disponibles, las empresas que no participan directa o indirectamente en un ecosistema
pueden tener dificultades para competir (Newman, 2016). Si continúa la tendencia de los
ecosistemas digitales, las demás organizaciones están obligadas a formar parte de los
ecosistemas o a convertirse en uno. Además, la integración de ecosistemas permite a las
empresas aprovechar las tecnologías nuevas y heredadas, y crear procesos
automatizados a su alrededor, para hacer crecer un negocio continuamente.

Según Jacobides et al. (2019) las plataformas digitales se están expandiendo en

todos los sectores tanto de producción como de servicios, reconfigurando los modelos de
negocio de una amplia gama de industrias, desde las finanzas y la atención sanitaria hasta
los medios de comunicación y el comercio minorista, al tiempo que crean divisiones
fundamentalmente nuevas de responsabilidad pública y privada. Las empresas que
 11

impulsan esta tendencia son diversas y dispares. Algunas son empresas nativas digitales,
otras son gigantes de la economía digital. Otras, aún, son empresas tradicionales que se
están adaptando a un mundo digital más amplio adoptando una plataforma activa y una
estrategia de ecosistema.

Ascendere depende de un modelo estratégico empresarial heredado que no es

capaz de seguir el ritmo de todo el trabajo que se realiza cada semestre. Debido a que
dentro del apartado de Innovación Docente constantemente se presentan nuevas
iniciativas, proyectos o eventos que buscan mejorar el nivel educativo de la institución y de
la comunidad que nos rodea. Por tanto, se requiere adoptar una alternativa de integración
más nueva y simple, considerando que las soluciones actuales están resultando cada vez
más costosas en términos económicos de igual forma en productividad.

En consecuencia, es necesario la definición e implementación de un ecosistema de

negocio que permita producir una disrupción de la cadena de valor lineal del Proyecto
Ascendere, mediante la construcción de una plataforma digital centrada en el usuario, lo
cual supondrá mejorar: el modelo de ingresos, gobernanza, estrategia de negocio y
comunidades.

Este documento se presenta en 7 capítulos estructurados de la siguiente manera:

el capítulo 1 detalla el enfoque del proyecto presentado la problemática, justificación,
objetivos y la metodología del proyecto; el capítulo 2 presenta el contexto de la
problemática analizando el Proyecto Ascendere; en el capítulo 3 abarca el estudio de
literatura abarcando los temas fundamentales para el desarrollo; en el 4 y 5 capítulo se
presenta la solución y el proceso de desarrollo de la misma detallando cada una de la
fases necesarias y finalmente el capítulo 6 y 7 da a conocer la conclusiones,
recomendaciones y resultados finales del trabajo.
 12

CAPÍTULO UNO

GENERALIDADES

El capítulo describe la problemática presente en el Proyecto Ascendere dentro de los

procesos y actividades utilizados para llevar a cabo el seguimiento y control del desarrollo

de los proyectos de innovación. Así mismo, se plantea la solución propuesta, detallando

los objetivos y la metodología empleada en el trabajo de titulación con la finalidad de

establecer las bases y alcance del proyecto.

1.1 PROBLEMÁTICA

El Proyecto Ascendere (desde ahora Ascendere) es una iniciativa enmarcada en el

Plan Estratégico de Desarrollo Institucional de la Universidad Técnica Particular de Loja

(desde ahora UTPL). El propósito de Ascendere es trabajar y agrupar iniciativas que

promueven las competencias de los docentes a través de la innovación académica, la

investigación en nuevas metodologías de educación y uso de las TIC.

En cada período académico se desarrollan proyectos impulsados y apoyados por

parte de Ascendere. Sin embargo, la estructura de dirección y gestión de proyectos

empleada genera los siguientes problemas:

● La dificultad para entender el alcance y objetivos del proyecto.

● La dificultad de asignación y distribución de recursos a cada proyecto.

● La falta de evidencias de las actividades realizadas.

● La dificultad para llevar el seguimiento y control de los proyectos.

● Inconvenientes en la revisión y evaluación de los resultados del proyecto.

Con la finalidad de apoyar al departamento de Innovación Docente, este estudio

tiene como meta desarrollar un ecosistema de negocio mediante la construcción de una

plataforma digital a través de un estándar internacional para mejorar la dirección, gestión e

 13

interacción de las actividades, uso de recursos, calidad y eficiencia de los proyectos de

innovación docente.

1.2 JUSTIFICACIÓN

En la actualidad, Ascendere dispone de procesos, herramientas y recursos que han

sido elaborados y desarrollados de forma improvisada sin contar con un estándar,

ocasionando dificultades para seguir el ritmo de trabajo que se realiza cada semestre. En

línea con esto, el aumento de proyectos y propuestas que buscan mejorar el nivel

educativo de la institución, muestran la necesidad de implementar una estructura y

arquitectura, que permita adaptarse al crecimiento de nuevas capacidades de negocio.

1.3 OBJETIVOS

El objetivo general del presente trabajo de titulación es definir e implementar el

ecosistema de negocio del Proyecto Ascendere mediante la construcción de una

plataforma digital.

1.3.1 Objetivos Específicos

● Explorar conceptos, estudios de casos, modelos y estructuras a través de una

revisión exhaustiva de la literatura para comprender los elementos claves y

necesarios dentro de las plataformas y ecosistemas digitales.

● Definir la estrategia y los mecanismos para diseñar de la plataforma digital a través

de la identificación de los diferentes niveles de participantes del ecosistema de

negocio con la finalidad de garantizar su sostenibilidad a corto y largo plazo.

● Definir el esquema arquitectónico de la plataforma a través de la identificación de

estándares y procesos de orquestación abierta para garantizar la funcionalidad,

fiabilidad, interoperabilidad y eficiencia del ecosistema.

● Evaluar el desempeño de la plataforma con base en los acuerdos de nivel de

servicio (SLA) definidos con la finalidad de encontrar oportunidades de mejora.

 14

1.4 METODOLOGÍA

La estrategia de desarrollo se basa en el diseño de la ciencia como un enfoque de

investigación del trabajo de titulación. El marco de investigación utilizado se adoptó a partir

de (Mirko y Swurthz, 1995). El marco consta de cuatro actividades de investigación:

construir, evaluar, teorizar y justificar, y de cuatro resultados de investigación: constructos,

modelos, métodos e instanciación.

1.4.1. Resultados de la investigación

Actividades de la Investigación

● Construir, se refiere a la construcción de constructos, modelos, métodos y

artefactos que demuestran que pueden construirse.

● Evaluar, se refiere a determinar si se ha realizado algún progreso en relación con

los constructos, modelos, métodos e instancias.

● Teorizar, se refiere a la construcción de teorías que explican cómo o por qué

sucede algo. En el caso de la investigación de TI e IS, esta es a menudo una

explicación de cómo o por qué un artefacto funciona dentro de su entorno.

● Justificar, se refiere a la prueba de la teoría y requiere la recopilación de evidencia

científica que respalde o refute la/s teoría/s planteadas.

1.4.2. Resultados de la investigación

● Constructo, conformar el fundamento y vocabulario del dominio de negocio.

● Modelo, definir el conjunto de proposiciones o declaraciones que expresan

relaciones entre constructos. En las actividades de diseño, los modelos

representan situaciones como declaraciones de problemas y soluciones.

● Método, definir el conjunto de pasos (un algoritmo o directriz) que se utilizarán para

realizar una tarea. Los métodos se basan en un conjunto de constructos

subyacentes (lenguaje) y una representación (modelo) del espacio de la solución.

 15

● Instanciación, implementación de un artefacto en su entorno. La investigación de TI

crea instancias de sistemas de información específicos y herramientas que abordan

diversos aspectos del diseño de sistemas de información. Las instancias

operativizan los constructos, modelos y métodos.

 16

CAPÍTULO DOS

PROYECTO ASCENDERE

Las instituciones de educación superior juegan un papel fundamental en el avance

de la ciencia y tecnología, sin embargo, las instituciones de educación superior

latinoamericanas poseen metodologías o herramientas que limitan la capacidad de

adaptación ante cambios de la industria, y tienden a ser instituciones conservadoras y con

un enfoque tradicionalista.

A partir del año 2015, se propone la implementación del Proyecto Ascendere, una

iniciativa que acoge aquellos proyectos que potencian las competencias pedagógicas de

los docentes a través de la innovación y formación académica y la investigación en nuevas

metodologías de educación y uso de las TIC (Salazar et al., 2016). El nombre nace de la

consigna de la UTPL que se encuentra en su mismo escudo, “Memento Ascendere

Semper”, cuyo significado es “Recuerda Superarte Siempre”. Una premisa que reafirma el

constante compromiso con la innovación.

El Proyecto Ascendere es desarrollado en el Vicerrectorado Académico de UTPL

bajo la Dirección de Innovación, Formación y Evaluación Docente. Para dar cumplimiento

a los objetivos propuestos en el proyecto y en busca de la calidad de la docencia, se crean

los apartados: Innovación, Formación y Evaluación Docente. En las siguientes secciones

se profundizará en este tema.

2.1. INNOVACIÓN DOCENTE

El apartado de Innovación Docente tiene el propósito de cambiar, transformar y

mejorar la práctica pedagógica de los docentes mediante la participación de todos los

miembros de la comunidad educativa (Salazar et al., 2016). Para cumplir con el propósito

se busca crear como eje principal a la comunicación entre docentes y estudiantes dentro y

fuera de clases. La innovación, como en clases teóricas, prácticas y tutorías, tiene el

 17

objetivo de enriquecer el aprendizaje del estudiante y la adquisición de competencias

profesionales.

Para poder cumplir el objetivo de Innovación Docente, se realiza semestralmente una

convocatoria para que los docentes participen con sus propuestas de proyectos enfocados

en la enseñanza aprendizaje. La convocatoria es dirigida a todo el plantel docente de

UTPL, con el fin de que implementen nuevas estrategias de enseñanza aprendizaje.

Potenciando el uso creativo de diferentes herramientas dentro y fuera del aula, implicando

a los estudiantes activamente en su proceso de aprendizaje (Loaiza et al., 2020).

2.1.1. Proyectos de innovación

Los proyectos de innovación tienen la duración de dos ciclos académicos, su

implementación y elaboración de informes debe ser según el plazo establecido por la

Dirección de Formación, Innovación y Evaluación Docente. Estos proyectos requieren la

constitución de un equipo de trabajo de al menos tres docentes. Para la valoración se

considerará que, en lo posible, se implemente el proyecto en asignaturas de modalidad

presencial y abierta y a distancia.

2.1.2. Buenas Prácticas

Las buenas prácticas tienen la duración de un semestre, su implementación y

elaboración de informes debe ser según el plazo establecido por la Dirección de

Formación, Innovación y Evaluación Docente. En este tipo de propuestas podrán participar

como mínimo dos docentes.

2.1.3. Semestre Ascendere

La propuesta del Semestre Ascendere se desarrolla a partir del año 2019 y tiene

como objetivo diseñar “asignaturas que trabajen en forma integral” cuya finalidad es

resolver un reto planteado, unificando el desarrollo de las asignaturas ofertadas en un

semestre o periodo académico determinado, mediante la planificación micro curricular,

 18

para lo cual el equipo de docentes responsables de las asignaturas trabajan de forma

coordinada respecto a los contenidos, actividades, recursos y evaluación que llevan al

desarrollo Los profesores de Modalidad Presencial, Abierta y de Postgrados presentan

propuestas de Buenas Prácticas Docentes, enmarcadas en la implantación de estrategias

de enseñanza aprendizaje, que potencian el uso creativo de diferentes herramientas

dentro y fuera del aula. Para la presentación de proyectos de innovación en la docencia, se

consideran las siguientes líneas estratégicas: y resolución del reto planteado.

2.2. FORMACIÓN DOCENTE

La mayoría de los profesores que ingresan a la universidad tienen escasa o nula

formación pedagógica (Loaiza et al., 2018). Por esto, Ascendere crea el programa de

formación docente en búsqueda de concebir la calidad de la docencia y el desarrollo de la

planta docente. Este programa acompaña al profesorado durante su proceso de desarrollo

profesional docente, considerando su formación inicial como su formación permanente.

Dota sólidas bases teóricas para que se apliquen y traduzcan en el desarrollo de buenas

prácticas e innovación docente (Loaiza et al., 2020).

2.3. EVALUACIÓN DOCENTE

Constituye un compromiso de toda la comunidad académica universitaria, cuyos

resultados servirán para participar activamente en el mejoramiento continuo de la calidad

de la UTPL. Por lo que, una vez realizado el proceso, se analizan todas las actividades

que se enmarcan en docencia, investigación y gestión académica.

2.4. LABORATORIO DE INVESTIGACIÓN E INNOVACIÓN DOCENTE (LIID)

EL LiiD es un espacio de la UTPL orientado al desarrollo de la innovación e

investigación educativa a nivel local, nacional e internacional. Busca canalizar y fortalecer

todas las iniciativas de la comunidad universitaria de la UTPL que potencien el aprendizaje

y la enseñanza con el uso de las nuevas tecnologías, recursos educativos abiertos y

 19

nuevas metodologías de enseñanza–aprendizaje. De igual manera, pretende apoyar a

todos los investigadores que quieran explorar nuevas formas de trabajo científico

encaminado a mejorar la docencia universitaria. Este laboratorio coordina, juntamente con

el laboratorio de Inteligencia Artificial y MediaLab, el diseño y desarrollo de proyectos,

prototipos y más actividades relacionadas a cumplir con los objetivos antes mencionados.
 20

CAPÍTULO TRES

MARCO TEÓRICO

El presente capítulo constituye la base conceptual del proyecto, abordando los temas

fundamentales para su concepción. Se inicia con el análisis de la gestión y dirección de

proyectos, después, se aborda las temáticas de ecosistemas y plataformas digitales

aplicados a Ascendere, por último, tenemos los temas relacionados con los cuatro

principios del desarrollo e implementación de las aplicaciones nativas en la nube.

3.1. GESTIÓN DE PROYECTOS

La gestión de proyectos es una disciplina vital, que hoy en día, muchas

organizaciones se encuentran en la situación de tener que decidir sobre la implementación

de un estándar. Pero a pesar de las diferentes guías y estándares existentes en torno a la

dirección y gestión de proyectos muchas organizaciones no los consideran, como es el

caso de Ascendere. En consecuencia, es necesario conocer los temas referentes a la

gestión de proyectos.

3.1.1. Proyectos

El estándar ISO (2021) define un proyecto como un conjunto único de procesos que

consta de actividades coordinadas y controladas con fechas de inicio y finalización,

realizadas para lograr los objetivos del proyecto. Adicionalmente el Management Institute

Project (2017) detalla a un objetivo como un resultado hacia el cual se debe dirigir el

trabajo, una posición estratégica a ser alcanzada, un propósito a ser logrado, un resultado

a ser obtenido, un producto a ser producido, o un servicio a ser realizado.

Los proyectos surgen como respuesta a una necesidad, pueden estar enfocados a

darle solución a un problema o permitirle a una organización aprovechar una oportunidad

(Moreno Monsalve et al., 2016). Por eso, los proyectos dentro de las organizaciones

impulsan el cambio y permiten la creación de valor empresarial. Como valor empresarial

 21

entendemos como el beneficio (tangible, intangible o ambos) que los resultados de un

proyecto específico proporcionan a sus interesados. (Management Institute Project, 2017)

3.1.2. Importancia de la gestión de proyectos

La gestión de proyectos es la aplicación de métodos, herramientas, técnicas y

competencias a un proyecto, e incluye la integración de las diversas fases del ciclo de vida

del proyecto (ISO, 2021).

Los beneficios que aporta una gestión eficaz y eficiente de proyectos tanto a

individuos u organizaciones, según el Management Institute Project (2017) son:

● Cumplir con los objetivos comerciales;

● Satisfacer las expectativas de las partes interesadas;

● Ser más predecible;

● Aumentar las posibilidades de éxito;

● Entregar los productos adecuados en el momento adecuado;

● Resolver problemas y cuestiones;

● Responder a los riesgos de manera oportuna;

● Optimizar el uso de los recursos de la organización;

● Identificar, recuperar o poner fin a los proyectos que fracasan;

● Gestionar las limitaciones (por ejemplo, el alcance, la calidad, el calendario, los

costos, los recursos);

● Equilibrar la influencia de las limitaciones en el proyecto (por ejemplo, el aumento

del alcance puede aumentar el costo o el calendario); y

● Manejar el cambio de una mejor manera.

Mientras que las cosas típicas que pueden salir mal en un proyecto, debido a la mala

gestión o la ausencia de una gestión de proyectos, según el Management Institute Project

(2017) son:
 22

● Fechas límite incumplidas,

● Sobrecostos,

● Mala calidad,

● Retrabajo,

● Expansión incontrolada del proyecto,

● Pérdida de reputación de la organización,

● Partes interesadas insatisfechas y

● Fallo en la consecución de los objetivos por los que se acometió el proyecto.

3.1.3. Estándares para la gestión de proyectos

Cuando se habla de estándares, la primera idea es pensar en estándares publicados

por un organismo oficial de estándares. A nivel internacional, será la Organización

Internacional de Normalización (ISO por sus siglas en inglés). A nivel nacional, se trata de

Organismos Nacionales de Normalización (NSB por sus siglas en inglés) que son

miembros de la ISO (por ejemplo, Instituto Nacional Estadounidense de Normas (ANSI por

sus siglas en inglés), Instituto Británico de Normas (BSI por sus siglas en inglés), Instituto

Nacional de Normas Alemán (DIN, del nombre alemán Deutsches Institut für Normung)).

En algunas áreas, las normas europeas (EN, del nombre alemán Europäische Norm)

también son importantes. La ventaja de las normas ISO es que se extienden por todo el

mundo.

El estándar ISO 21500 es la base para desarrollar una serie de nuevos estándares

nacionales e internacionales para la gestión de proyectos, programas y carteras. Por eso

es tan general que debería ser aplicable a una amplia variedad de estilos, tamaños y

niveles de complejidad de proyectos. En particular, apoyará la cooperación en proyectos

internacionales. El objetivo no era crear una norma para fines especiales como por
 23

ejemplo, capacitación y certificación o cumplir con los requisitos para el nivel de trabajo de

Ascendere.

3.1.4. ISO 21500:2021

La ISO 21500 especifica el contexto organizativo y los conceptos subyacentes para

llevar a cabo la gestión de proyectos, programas y carteras. También, proporciona

orientación para que las organizaciones puedan adoptar y mejorar la gestión de proyectos

(ISO, 2021). En consecuencia, el estándar provee una visión general y de alto nivel que

beneficiará a Ascendere al modificar recursos, herramientas y procesos en base a ciclo de

vida y grupo de procesos de los proyectos especificados en el estándar.

Ciclo de vida del proyecto. Abarca el período desde el inicio del proyecto hasta su

finalización. Las fases están divididas por puntos de decisión, que pueden variar según el

entorno organizacional. Los puntos de decisión facilitan la gobernanza del proyecto. Al final

de la última fase, el proyecto debería haber proporcionado todos los entregables. Ver

Figura 1.

Figura 1

Interacciones de grupos de procesos

Nota. Adaptado de Process groups interactions, de (ISO, 2021).

 24

Grupos de procesos. Cada grupo de procesos consta de procesos que son

aplicables a cualquier fase o proyecto del proyecto. Estos procesos, definidos con más

detalle en términos de propósito, descripción y entradas y salidas primarias se muestran

en la Tabla 1. Los grupos de procesos son independientes del área de aplicación o del

enfoque de la industria.

Tabla 1

Procesos de dirección y gestión de proyectos.

Grupos de Grupo de procesos

materias
Inicio Planificación Implementaci Control Cierre
ón

Integración 4.3.2 4.3.3 4.3.4 Dirigir el 4.3.5 4.3.7

Desarrolla Desarrollar los trabajo del Controlar el Cerrar la
r planes del proyecto trabajo del fase del
carta del proyecto proyecto 4.3.6 proyecto
proyecto Controlar los o el
cambios proyecto
4.3.8
Recopilar
las
lecciones
aprendida
s

Parte 4.3.9 4.3.10

interesada Identificar Gestionar las
las partes partes
interesada interesadas
s

Alcance 4.3.11 Definir 4.3.14

el alcance Controlar el
4.3.12 Crear alcance
la estructura
de desglose
de trabajo
4.3.13 Definir
las
actividades
 25

Recurso 4.3.15 4.3.16 Estimar 4.3.18 4.3.19

Establece los recursos Desarrollar el Controlar los
r el equipo 4.3.17 Definir equipo de recursos
de la proyecto 4.3.20
proyecto organización Gestionar el
del proyecto equipo de
proyecto

Tiempo 4.3.21 4.3.24

Secuenciar Controlar el
las cronograma
actividades
4.3.22 Estimar
la duración de
las
actividades
4.3.23
Desarrollar el
cronograma

Costo 4.3.25 Estimar 4.3.27

los costos Controlar los
4.3.26 costos
Desarrollar el
presupuesto

Riesgo 4.3.28 4.3.30 Tratar 4.3.31

Identificar los los riesgos Controlar los
riesgos 4.3.29 riesgos
Evaluar los
riesgos

Calidad 4.3.32 4.3.33 4.3.34

Planificar la Realizar el Realizar el
calidad aseguramient control de la
o de la calidad calidad

Adquisidores 4.3.35 4.3.36 4.3.37

Planificar las Seleccionar Administrar
adquisiciones los los contratos
proveedores

Comunicació 4.3.38 4.3.39 4.3.40

n Planificar las Distribuir la Gestionar las
comunicacion información comunicacion
es es
 26

Nota. Adaptado de Project management processes cross-referenced to process and subject groups,

por (ISO, 2021).

Una vez hemos tratado la dirección y gestión de proyectos desde la perspectiva de

la ISO 21500. Continuaremos con la temática de ecosistemas digitales, donde nos

centraremos en conocer cómo se lleva a cabo la construcción y funcionamiento de estos

en el entorno de Ascendere.

3.2. ECOSISTEMAS DIGITALES

Como lo define Gartner (2018) un ecosistema digital es un grupo interdependiente de

empresas, personas y / o cosas que comparten plataformas digitales estandarizadas con

un propósito mutuamente beneficioso, como beneficio comercial, innovación o interés

común. (Gartner, 2018; como se citó en Avramakis et al., 2019)

Un ecosistema digital es, por lo tanto, un conjunto de clientes, productores,

proveedores y otras empresas o servicios interesados, conectados por medio de una

plataforma (Avramakis et al., 2019), con el fin de compartir recursos, experiencias e

información para mejorar el valor de los productos o servicios ofertados.

En el centro del ecosistema digital se encuentra una empresa plataforma conocida

como patrocinador de la plataforma, la cual se encarga de crear los estándares de

interacción entre los miembros. Como lo menciona Jacobides las empresas plataformas

crecen a un ritmo sorprendente en comparación con sus competidores establecidos

(Jacobides et al., 2019). Las empresas logran este crecimiento gracias a un fenómeno

denominado “efecto de red”, donde cada nuevo participante aporta nuevos datos y eso

aumenta el valor de la red para los participantes existentes. (Avramakis et al. 2019)

La ley de Metcalfe recae en dos supuestos implícitos: 1) Cada usuario agrega valor

a la red (ó al menos su contribución es igual a la contribución marginal por usuario). 2) La

habilidad para comunicarse entre los usuarios no es afectada por el ingreso de nuevos
 27

usuarios” (Larrosa, 2000). Permitiendo profundizar en el valor creciente a lo que aparecen

los nuevos participantes en el ecosistema.

3.2.1. Características y beneficios de los ecosistemas digitales Características y

beneficios de los ecosistemas digitales

Los ecosistemas digitales presentan características y beneficios que provocan que

las empresas plataformas que se encuentran en el centro de las relaciones, crezcan de

forma acelerada en comparación a las empresas tradicionales. En Newman (2016) se

destacan las principales características y beneficios:

Entorno colaborativo abierto. Para que las empresas mejoren el valor de los

productos o servicios ofertados deben centrarse en sus capacidades organizativas,

enfocándose en cerrar la brecha de habilidades de TI (tecnologías de la información en

inglés).

Fomenta las relaciones cooperativas. Como habíamos descrito anteriormente los

ecosistemas se basan en las relaciones de los interesados para mejorar el valor de estas.

Permitiendo a todas las partes interesadas como proveedores, productores u otras

empresas compartir sus recursos e información para solventar las necesidades de los

clientes.

Apoya a una cultura de innovación. Los entornos verdaderamente colaborativos

fomentan la colaboración en la empresa. Las empresas plataformas adoptan la idea de

que cada miembro de su ecosistema digital es un jugador valioso que puede impulsar el

éxito servicio o producto.

Facilita la adaptación a las necesidades de los clientes. La capacidad de

adaptarse es un factor determinante para mantener un ecosistema, debido a que los

socios y proveedores cambian también lo hacen las necesidades de los clientes. Los
 28

ecosistemas al tener varios involucrados enfocados en cubrir las necesidades de los

clientes, pueden adaptarse a mayor velocidad a los cambios que sufran los clientes.

3.2.2. Evolución de los ecosistemas digitales

Para que una empresa tradicional se convierta en un ecosistema digital eficiente

debe madurar y pasar por tres etapas de evolución (Figura 2).

Figura 2

Etapas de la evolución del ecosistema

Nota. Adaptado de Digital ecosystems: extending the boundaries of value creation in insurance por

(Avramakis et al., 2019)

Etapa Inicial. Un modelo tradicional parte de una cadena de valor que empieza por

los proveedores o productores hasta llegar a los clientes o consumidores. Al comenzar a

construir un ecosistema tomamos este modelo tradicional y lo transformamos en un

modelo básico de centro y radio, en el que la empresa plataforma, conecta las entidades y

recopila comentarios sobre las necesidades de los miembros. (Avramakis et al. 2019).

En la primera etapa es el patrocinador el que decide los estándares y técnicas para

la interacción, lo que le confiere un alto grado de control. De esta forma se eliminan los
 29

proveedores intermediarios entre el productor principal con el consumidor o cliente. En

esta etapa Ascendere adquiere el rol de patrocinador gestionando la interacción entre los

docentes con los departamentos de las direcciones de Innovación, Formación y

Evaluación.

Etapa Formativa. Durante esta etapa el patrocinador desempeña un papel central

en la interacción, al igual que en la etapa anterior. En lo que se diferencia es que, en esta

etapa, los miembros colaboran entre sí más libremente, pero en un entorno cerrado

(Avramakis et al. 2019). En esta etapa Ascendere permite la comunicación entre los

docentes postulantes con el personal de Innovación Docente, delimitando el nivel de

participación o acción del departamento.

Etapa de Madurez. En este punto del ecosistema digital, aparecen nuevos servicios

y empresas interesadas, que promueven el colectivismo. Es en esta etapa en la que el

patrocinador enriquece sus capacidades operativas al brindar acceso a otros servicios,

empresas, herramientas de software, entre otras (Avramakis et al. 2019). En esta etapa

Ascendere contará con servicios relacionados a otros departamentos de la universidad

(laboratorios, departamento financiero, facultades, entre otros) y podrá compartir sus

servicios a otras universidades o instituciones enfocados en el área educativa.

3.2.3. Apertura de los ecosistemas

Como establecimos antes el eje central de los ecosistemas es una plataforma, la

misma que define las reglas de interacción entre los miembros. Entre las reglas que

existen se determina la apertura que hay para participar. Las reglas de gobernanza o

apertura motivan la participación ya sea entre un cliente y un productor, un cliente y

contenido web, o una cliente y otro cliente; estas participaciones crean un nuevo valor al

ecosistema (Jacobides et al. 2019).

 30

Los ecosistemas según la apertura hacia las partes interesadas se pueden dividir en

cuatro escenarios (Figura 3):

Figura 3

Representación de la apertura del ecosistema de Ascendere

Nota. Adaptado de Digital ecosystems: extending the boundaries of value creation in insurance por

(Avramakis et al., 2019)

Apertura a los proveedores. Cuando un ecosistema está abierto hacia los

proveedores, eliminan la mayor cantidad de restricciones, lo que permite que los

proveedores se unan libremente, establezcan precios e interactúen directamente con los

clientes (candado verde). (Avramakis et al. 2019). Las otras partes interesadas se filtran

por el patrocinador de la plataforma (candado rojo), para garantizar la seguridad de los

datos compartidos. Para este caso se da mayor libertad al uso de datos por parte de

docentes como a los departamentos de Innovación, Formación y Evaluación Docente;

mientras que se privan de ciertos privilegios de acceso a las otras partes interesadas,
 31

como podría ser, la imposibilidad de revisar el historial docente por parte de otras

universidades.

Apertura a los socios. En este escenario, las otras partes interesadas pueden

acceder al ecosistema, mientras que a los proveedores se les crean altas barreras de

entrada. (Avramakis et al. 2019). En este caso se priva de acceso a los departamentos de

Innovación, Formación y Evaluación Docente, favoreciendo el acceso a los servicios y

datos del ecosistema a otras partes interesadas, como lo sería el departamento financiero

teniendo libre acceso al historial docente, lo que ayudaría a evaluar la financiación de los

proyectos de innovación.

Apertura a los proveedores de ecosistemas. En este caso los proveedores son

interfaces para el ecosistema y llevan a los usuarios. Sin embargo, el patrocinador del

ecosistema es el propietario de la propiedad intelectual. (Avramakis et al. 2019). Para este

escenario serían los departamentos de Innovación, Formación y Evaluación Docente,

quienes brindarán los servicios a la plataforma siendo Ascendere dueño de la propiedad

intelectual de cada servicio compartido por cada integrante del ecosistema.

Apertura a otros patrocinadores de ecosistemas. Durante este escenario, otros

patrocinadores pueden contribuir en las mejoras al ecosistema y desarrollar conjuntamente

la propiedad intelectual. (Avramakis et al. 2019). Este escenario es el más favorable para

Ascendere, pues permite la conexión de otros ecosistemas enriqueciendo las posibilidades

de desarrollo del proyecto Ascendere como plataforma.

3.2.4. Grupos y dominios de los ecosistemas

Un cambio importante provocado por las tecnologías digitales ha sido la creación de

modelos de comercio electrónico que permiten monetizar y cobrar a través de un modelo

transaccional online (Skilton, 2016). Esta perspectiva ha sido descrita por los modelos de
 32

colaboración empresa a empresa (B2B por sus siglas del inglés), empresa a consumidor

(B2C por sus siglas del inglés).

Esta modificación de los modelos de comercio y mercado funciona gracias a que los

ecosistemas operan en grupos amplios, los que a su vez se dividen en dominios

(Avramakis et al. 2019). Ascendere tras avanzar en las etapas de evolución, aprovecha su

relación y experiencia del trabajo con los docentes, para trazar sus servicios a nuevos

dominios, principalmente orientados a universidades interesadas en mejorar su plantel

educativo (Figura 4).

Figura 4

Grupos y dominios dentro del ecosistema Ascendere

Nota. Adaptado de Digital ecosystems: extending the boundaries of value creation in insurance por

(Avramakis et al., 2019)

Con esto las empresas que comenzaron en segmentos B2C han empezado a

expandirse hacia usuarios B2B, ya que los productos orientados al consumidor a menudo

también se pueden implementar en el contexto B2B (Avramakis et al. 2019). Esto provoca
 33

que los ecosistemas puedan crear productos y servicios más fáciles de adoptar a todos los

entornos disponibles.

El rápido crecimiento de los ecosistemas digitales se debe a la maduración de las

tecnologías como aplicaciones cloud, interfaces de programación de aplicaciones (API),

arquitecturas modulares y analíticas. En la siguiente sección abordamos la principal

tecnología para trabajar en ecosistemas digitales: las aplicaciones cloud.

3.3. APLICACIONES CLOUD.

El software es cada vez más importante para las empresas por la manera en que

interactúan e innovan con los usuarios para mantener su competitividad en la velocidad de

desarrollo y de entrega de aplicaciones (Red Hat, 2019). Para lograr satisfacer el mercado

con un ritmo acelerado de cambios y construir plataformas óptimas es necesario optar por

modelos de desarrollo y de distribución que sean ágiles y flexibles.

Peter y Timothy (2011) del Instituto Nacional de Estándares y Tecnología (NIST por

sus siglas del inglés) definen a la computación en la nube como:

- Un modelo que permite el acceso ubicuo, cómodo y bajo demanda a un conjunto

compartido de recursos informáticos configurables (por ejemplo, redes, servidores,

almacenamiento, aplicaciones y servicios) que pueden ser rápidamente

aprovisionados y liberados con un mínimo esfuerzo de gestión o de interacción con

el proveedor de servicios.

Para Red Hat (2019) en cambió una aplicación nativa en la nube es una aplicación

creada para aprovechar los modelos de computación en la nube a fin de aumentar la

velocidad, flexibilidad y calidad, a la vez que se reducen los riesgos de implementación.

3.3.1. Características esenciales de la computación en nube

Peter y Timothy (2011) definen a las características esenciales del modelo de la

computación en la nube de la siguiente manera:

 34

- La primera característica como el servicio bajo demanda. Bajo demanda significa

que se puede comprar cuando se necesita, durante el tiempo que se necesite, y

devolverlo cuando se termine. El autoservicio se refiere a la capacidad del

consumidor de comprar, desplegar y cerrar los servicios sin ninguna ayuda del

proveedor de servicios.

- La segunda característica es el amplio acceso a la red. La nube es una oferta

siempre activa y accesible, los usuarios tienen acceso inmediato a todos los

recursos y activos disponibles.

- La tercera característica, la puesta en común de recursos, donde la combinación de

muchos recursos informáticos en granjas o pools que pueden servir a muchos

consumidores simultáneamente permite la asignación y reasignación dinámica de

recursos, la previsibilidad de los costes, el control de los recursos informáticos y de

recursos informáticos y un mayor índice de utilización de la infraestructura.

- La cuarta característica se centra en la elasticidad. Las capacidades de los

productos y servicios se desarrollan, adquieren, fijan su precio y se aprovisionan de

forma elástica, lo que permite responder rápidamente a la demanda de los

usuarios, que cambia continuamente.

- La última característica mencionada es la nube como servicio. La computación en

nube ofrece de forma nativa un componente único e importante que los

despliegues tradicionales de TI han tenido dificultades para ofrecer: la medición y el

control del consumo y la utilización de los recursos. el consumo y la utilización de

los recursos.

3.3.2. Modelos de servicios en la nube

En la actualidad, podemos encontrar desplegados tres diferentes modelos de

servicios en la nube, estos son: Software como servicio (SaaS por sus siglas en inglés),
 35

Plataforma como Servicio (PaaS por sus siglas en inglés) e Infraestructura como Servicio

(IaaS por sus siglas en inglés). Cada uno de estos modelos está destinado a resolver

requerimientos distintos acoplados a las necesidades específicas de cada empresa. A

continuación, veremos detalladamente cada uno de los modelos, descritos por Peter y

Timothy (2011):

SaaS. SaaS ofrece el mayor nivel de abstracción en la nube. Este modelo permite

un acceso rápido a las aplicaciones listas para usar basadas en la nube. En otras

palabras, software en la nube, donde los clientes evitan la pila de computación

subyacente, las tasas de licencia o el mantenimiento de la infraestructura. Sólo acceden a

la aplicación, normalmente a través de Internet. La mayoría de los proveedores de SaaS

funcionan con acceso por suscripción o gratuito con acceso limitado.

PaaS: El modelo PaaS es esencialmente un modelo adaptado para que los

desarrolladores construyan, prueben y organicen sus aplicaciones. En el modelo PaaS, los

usuarios tienen acceso a marcos de trabajo para crear y desplegar aplicaciones en la

nube, incluyendo modelos de programación, configuraciones de entorno y autoescalado.

Sin embargo, el proveedor sigue gestionando todos los recursos, como el

almacenamiento, la red y los servidores. En resumen, el servicio en la nube proporciona al

cliente la capacidad de crear rápidamente aplicaciones con un modelo de nube elástica.

IaaS: IaaS es una provisión virtual de recursos informáticos. La mayoría de los

proveedores de IaaS muestran toda una gama de infraestructuras informáticas, como

almacenamiento y servidores, con un alto grado de control sobre estos recursos. En IaaS,

los desarrolladores pueden desplegar y ejecutar software arbitrario, ajustar el número de

recursos utilizados de forma flexible y pagar sólo por los recursos utilizados.
 36

3.3.3. Aplicaciones Tradicionales frente a aplicaciones nativas en la nube

Durante décadas, muchas de las aplicaciones no fueron diseñadas teniendo en

cuenta experiencias digitales. Estos enfoques de desarrollo eran secuenciales y en

cascada, que dieron como resultado el modelo de aplicación monolítica. Un monolito es

una arquitectura en la que todos los módulos relevantes se empaquetan juntos como una

única unidad de ejecución desplegable. Utiliza un diseño en capas, con capas separadas

para la interfaz de usuario, la lógica de la aplicación y el acceso a los datos. (Lavann et al.,

2021)

Este modelo presentó ineficiencias debido a que la infraestructura estática y los

largos ciclos de desarrollo significaban que había poca ventaja en descomponer las

aplicaciones más allá de unos pocos niveles, un cambio en cualquier servicio de aplicación

requería que todo su nivel se volviera a probar y se volviera a implementar. (Russinovich,

2016)

A pesar de las limitaciones de un monolito, puede tener sentido como punto de

partida para una aplicación. Los monolitos suelen ser el camino más rápido para crear una

prueba de concepto o un producto mínimo viable (Lavann et al., 2021). Sin embargo, a

medida que la complejidad de la aplicación aumenta, los monolitos son difíciles de

construir, depurar o modificar. En este punto, una aplicación nativa en la nube proporciona

agilidad a largo plazo lo que facilita crear aplicaciones basadas en servicios que se pueden

implementar de forma independiente y que tienen ciclos de vida granulares y autónomos,

esto permite un mejor mantenimiento en sistemas complejos, grandes y altamente

escalables (de la Torre et al., 2020).

Las diferencias entre el desarrollo de las aplicaciones nativas en la nube y el

desarrollo de las aplicaciones tradicionales se pueden observar en la Tabla 2.

Tabla 2
 37

El desarrollo de aplicaciones tradicionales frente al desarrollo de aplicaciones nativas en la

nube.

Tradicional Nativo en la nube

Centrado Antigüedad y estabilidad Rapidez de comercialización

Metodología de Desarrollo semiágil en cascada Desarrollo ágil, DevOps

desarrollo

Equipos Equipos aislados de desarrollo, Equipos colaborativos de DevOps

operaciones, control de calidad
y seguridad

Ciclos de Largos Cortos y continuos

entrega

Arquitectura de Con conexión directa Sin conexión directa

aplicaciones Monolítica Basada en servicios
Comunicación basada en la
interfaz de programación de
aplicaciones (API)

Infraestructura Centrada en el servidor Centrada en contenedores

Diseñada para las instalaciones Diseñada para las instalaciones y
Dependiente de infraestructura la nube
Expandible verticalmente Portátil entre la infraestructura
Con preparación previa para Expandible horizontalmente
capacidad pico Capacidad según se solicite
Nota. Adaptado de El camino a las Aplicaciones Nativas en la nube por (Red Hat, 2019)

3.3.4. Principios de las aplicaciones nativas en la nube

Como se había especificado anteriormente las aplicaciones nativas en la nube están

desarrolladas con el fin de aprovechar la computación en la nube, para ello el diseño de

las aplicaciones debe conllevar cuatro principios básicos, para Red Hat (2019) estos

principios son:

Arquitectura basada en servicios. Una arquitectura basada en servicios, como los

microservicios, es un enfoque para desarrollar una colección de servicios pequeños,

modulares y poco acoplados. Entre las arquitecturas basadas en servicios más populares

tenemos:
 38

- Microservicios, como su nombre indica, una arquitectura de microservicios es un

enfoque para la generación de una aplicación de servidor como un conjunto de

servicios pequeños. (de la Torre et al., 2020)

- Serverless o arquitecturas sin servidor permiten desarrollar aplicaciones en la nube

sin tener que provisionar o gestionar servidores. El desarrollador especifica

funciones con puntos de entrada y salida bien definidos, y el proveedor en la nube

se encarga de todos los demás aspectos de la ejecución (Crane & Lin, 2017).

- Las arquitecturas orientadas a servicios (SOA por sus siglas en inglés), se

estructuran descomponiendo a una aplicación en varios servicios, se diferencian de

los microservicios en que mantienen una misma base de datos en vez de bases de

datos separadas por cada micro. Suelen utilizarse para integrar aplicaciones

grandes, complejas y monolíticas (Richardson, 2019).

Comunicación basada en API. Los servicios son expuestos a través de API ligeras

e independientes de la tecnología para comunicarse entre ellos. Esto reduce la

complejidad y la sobrecarga del despliegue, la escalabilidad y el mantenimiento. La

comunicación mediante interfaces de programación permite a las empresas crear nuevas

capacidades internamente y exponerlas externamente.

Infraestructura basada en contenedores. La tecnología de contenedores utiliza

capacidades de virtualización del sistema operativo para dividir recursos informáticos

disponibles entre varias aplicaciones, al mismo tiempo que garantiza que las aplicaciones

sean seguras y estén aisladas entre sí.

Al tener que hacer uso de una infraestructura basada en contenedores se hace

imperativo el trabajar con orquestadores. Un orquestador como la propia palabra indica, lo

podemos definir con un “director de orquesta”, donde cada uno de los elementos a dirigir

es un contenedor. Un orquestador tiene sentido cuando tenemos que manejar un sistema

 39

con muchos contenedores implementados sobre multitud de servidores, es decir, en un

entorno clusterizado. En este escenario el manejo manual se complica demasiado. Un

orquestador se encarga, entre otras cosas, de:

● Controlar y dirigir la creación de contenedores,

● Verificar su correcta ejecución

Ofrecer una correcta gestión de errores.

Proceso de DevOps. El desarrollo de aplicaciones para los enfoques nativos en la

nube utiliza los métodos y principios de DevOps; cabe aclarar que DevOps es una cultura

y no una herramienta. Es la idea de que los desarrolladores y las operaciones deben

trabajar juntos para ofrecer software de alta calidad a un ritmo acelerado. El proceso

DevOps tiene como objetivo cerrar la brecha entre los equipos de desarrollo y operación,

para que puedan trabajar como uno solo (Red Hat, 2019).

Los equipos ponen en práctica el método DevOps implementando determinadas

prácticas a lo largo del ciclo de vida de las aplicaciones. Algunas de estas prácticas

ayudan a agilizar, automatizar y mejorar una fase específica (Azure Docs, 2019), como es

la implementación y entregas continuas (CI/CD por sus siglas en inglés).

Cuando se habla de CI/CD, en realidad se está hablando de varios procesos

relacionados: integración continua, entrega e implementación continuas. Azure Docs

(2019) define a cada uno de estos procesos como:

- Integración continua. Los cambios de código se combinan con frecuencia en la

rama principal. Los procesos automatizados de compilación y pruebas garantizan

que el código de la rama principal siempre tenga una calidad de producción.

- Entrega continua. Los cambios en el código que pasan el proceso de CI se

publican automáticamente en un entorno similar al de producción. La

implementación en el entorno de producción real puede requerir aprobación

 40

manual, pero, en caso contrario, se realiza automáticamente. El objetivo es que el

código siempre esté listo para implementarse en producción.

- Implementación continua. Los cambios de código que pasan los dos pasos

anteriores se implementan automáticamente en producción.

Los equipos tienen muchas herramientas de DevOps para facilitar la adopción de

una cultura de DevOps en su organización. La mayoría de los equipos confían en varias

herramientas y, de este modo, crean cadenas de herramientas personalizadas que se han

adaptado a sus necesidades en cada fase del ciclo de vida de las aplicaciones. (Azure

Docs, 2019)

3.4. MICROSERVICIOS

En el subcapítulo anterior se detallaron los principios para el diseño de aplicaciones

nativas en la nube, el primer principio nos habla del uso de arquitecturas basadas en

servicios, arquitecturas que permiten resolver las necesidades latentes de las

organizaciones de alinear el modelo de negocio con los servicios tecnológicos, con el

objetivo de ser más competitivos y poder dar respuesta en el tiempo oportuno a las

exigencias del mercado. (Arango Serna et al., 2010)

Dentro de la gama de arquitecturas basadas en servicios encontramos la

arquitectura de microservicios, la cual consiste en una colección de pequeños servicios

autónomos, donde cada servicio es independiente e implementa una única capacidad de

negocio (Wasson & Narumoto, 2017). La arquitectura de los microservicios se está

convirtiendo en el método preferido para aplicaciones grandes y complejas basadas en

múltiples subsistemas independientes en forma de servicios autónomos.

Como muestra la Figura 5, en el enfoque monolítico tradicional, la aplicación se

escala clonando toda la aplicación en varios servidores/VM. En el enfoque de

microservicios, la funcionalidad se segrega en servicios más pequeños, por lo que cada

 41

servicio puede escalar de forma independiente. El enfoque de microservicios permite

cambios ágiles y una rápida iteración de cada microservicio, ya que se pueden cambiar

áreas específicas y pequeñas de aplicaciones complejas, grandes y escalables.

Figura 5

Despliegue monolítico frente al enfoque de microservicios

Nota. Adaptado de .NET Microservicies Architecture for Containerized .NET Applications por (de la

Torre, Wagner, et.al 2020)

3.4.1. Características de los microservicios

Como lo menciona Vettor & Smith (2021) los microservicios comparten las siguientes

características:

● Cada uno implementa una capacidad de negocio específica dentro de un contexto

de dominio más amplio.

● Cada uno se desarrolla de forma autónoma y puede desplegarse

independientemente.
 42

● Cada uno es autónomo y encapsula su propia tecnología de almacenamiento de

datos (SQL, NoSQL) y plataforma de programación.

● Cada uno se ejecuta en su propio proceso y se comunica con los demás utilizando

protocolos de comunicación estándar como HTTP/HTTPS, WebSockets o AMQP.

● Se componen juntos para formar una aplicación

3.4.2. Beneficios y desafíos de los microservicios

Vettor & Smith (2021) nos recalca los beneficios y los desafíos del uso de la

arquitectura de microservicios, debido a las amplias características centradas en la

implementación de servicios independientes y débilmente acoplados. Los beneficios que

nos presentan este tipo de arquitecturas son:

● Permite la entrega y el despliegue continuos de aplicaciones grandes y complejas.

● Los servicios son pequeños y de fácil mantenimiento.

● Los servicios se pueden desplegar de forma independiente.

● Los servicios son escalables de forma independiente.

● La arquitectura de microservicios permite que los equipos sean autónomos.

● Permite experimentar y adoptar fácilmente nuevas tecnologías.

● Tiene un mejor aislamiento de fallos.

Incluso en escenarios en los que los microservicios ofrecen una implementación

eficaz e independiente de la funcionalidad, límites de subsistema seguros y diversidad

tecnológica, también plantean muchos desafíos nuevos. Para Vettor (2021) los desafíos

relacionados con los microservicios son, entre otros:

● El desarrollo de aplicaciones distribuidas, como los modelos de datos fragmentados

e independientes

● Lograr una comunicación resistente entre los microservicios

● La necesidad de coherencia final

 43

● La complejidad operativa.

Para utilizar microservicios, debemos considerar las necesidades específicas de la

empresa y valorar tanto los beneficios como los desafíos al desarrollar esta arquitectura.

La arquitectura de microservicios, solo algunos escenarios específicos y determinados

tipos de aplicaciones son adecuados para las aplicaciones basadas en microservicios, por

ello Wasson & Narumoto (2017) nos recomienda aplicar la arquitectura de microservicios

cuanto tenemos:

● Aplicaciones grandes que requieren una alta velocidad de lanzamiento

● Aplicaciones complejas que necesitan ser altamente escalables

● Aplicaciones con muchos dominios o subdominios, y en una organización formada

por pequeños equipos de desarrollo.

3.4.3. Principales orquestadores para microservicios

Al desarrollar aplicaciones nativas en la nube bajo una arquitectura de

microservicios, debemos tomar en cuenta el uso de contenedores para el encapsulamiento

de los servicios; y como habíamos detallado con anterioridad al existir gran cantidad de

contenedores se hace necesario el uso de orquestadores. Entre los orquestadores más

utilizados mencionados por Delgado Pedraza y Pineda Parra (2019) para la

implementación de microservicios tenemos:

- Docker Swarm. Se puede definir como un administrador y/o orquestador de

contenedores, ejecutados dentro de un clúster. Está compuesto por varios hosts de

Docker que se ejecutan en modo enjambre. Cada uno de estos hosts cumplen una

función específica dentro de la composición de los servicios.

- Apache Mesos. Es un orquestador de servicios, el cual funciona de forma similar

al kernel de linux, corre en cada máquina del clúster y provee diferentes servicios
 44

con API 's para la administración y programación de elementos entre todos los

ambientes interactuantes dentro de un sistema.

- Kubernetes. Es conocido como un sistema de código abierto para automatizar la

implementación, el escalado y la administración de aplicaciones en contenedores,

Agrupa los contenedores que conforman una aplicación en unidades lógicas para

una fácil administración y manejo.

3.5. KUBERNETES

Cuando se habla de microservicios es necesario una plataforma que permita la

automatización y administre las cargas de trabajo y servicios. Es por ello que en 2014

Google lanza Kubernetes una plataforma para orquestar la ejecución de aplicaciones en

contenedores (Kubernetes, 2020).

Ahora procederemos a hacer una revisión de la arquitectura de Kubernetes para

entender su funcionamiento.

3.5.1. Arquitectura de Kubernetes

Como lo afirma Nogués (2018), Kubernetes se encarga de distribuir los contenedores

en pods, y los pods a su vez se pueden juntar en nodos. El conjunto de nodos formará un

clúster, siendo esta la estructura básica de Kubernetes. En la figura 6 se detalla la

arquitectura de Kubernetes con sus secciones.

Figura 6

Arquitectura de Kubernetes
 45

Nota. Adaptado de (Red Hat, 2021)

A continuación, se explicarán los elementos presentes en la arquitectura de

Kubernetes.

Pods. Un pod es la agrupación de contenedores en una misma máquina o host, que

comparten los mismos recursos. Es por ello por lo que se entiende que un pod es un host

lógico dentro de un clúster. Al pertenecer los contenedores a un mismo host lógico, estos

se alcanzan entre sí dado que comparten una dirección IP creando una red privada

(Nogués, 2018).

Nodos. Como detallamos anteriormente los pods se agrupan en una misma máquina

(un ordenador local o una máquina virtual). Moreno Monsalve (2016) nos explica que si

bien se suele entender que en clúster (conjunto de nodos) es donde se ejecutan las
 46

aplicaciones, realmente la aplicación se ejecuta en los nodos siento los contenedores

distribuidos por Kubernetes de manera automática (Nogués, 2018).

Los nodos se dividen en dos tipos: los nodos esclavos y los nodos máster o panel de

control.

Nodo máster. Los nodos máster son aquellos encargados de administrar y planificar

los pods que se encuentran ejecutando en los nodos del clúster, esto se realiza mediante

componentes que detallaremos más adelante (Nogués, 2018).

Clúster. Como ya lo habíamos mencionado con anterioridad un clúster es el

conjunto de varios nodos incluyendo al nodo máster. Esto permite que la aplicación

funcione como una sola unidad orquestada por el máster, evitando instalar una aplicación

directamente en una única máquina o host (Nogués, 2018). En la figura 6 se ve la

estructura de un clúster formada como mínimo por dos nodos y una serie de componentes

que se detallarán posteriormente.

3.5.2. Componentes de Kubernetes

Para el correcto funcionamiento de un clúster de Kubernetes existen diversos

componentes ubicados en los nodos y en el nodo máster o plano de control.

Componentes del nodo máster. Los componentes que se encuentran en este nodo

son los encargados de tomar decisiones globales sobre todo el clúster, detectando y

respondiendo a eventos del clúster (Kubernetes, 2020). A continuación, se detallan los

componentes encontrados en este nodo.

● kube-apiserver: es el servidor de API del plano de control de Kubernetes, es

conocido como el frontend de Kubernetes.

● etcd: es el almacén de datos del clúster de Kubernetes, aquí se guardan todos los

datos de configuración e información sobre el estado del clúster.

● kube-sheduler: es el componente pendiente de los pods, este componente se

 47

encarga de asignar los pods en los nodos en los que serán ejecutados.

● kube-controller-manager: es el componente encargado de la gestión de los

controladores y ejecución del clúster. Los controladores se encargan de ejecutar

nodos, replicar y mantener el número correcto de pods, construcción de endpoints

y creación de cuentas y tokens de acceso a la API.

● cloud-controller-manager: es el encargado de ejecutar controladores que

interactúan con los proveedores en la nube (Kubernetes, 2020).

Componentes del nodo. Cada nodo cuenta con componentes que se encargan del

mantenimiento de los pods proporcionando un entorno de ejecución de Kubernetes.

● Motor de tiempo de ejecución de contenedores: los nodos poseen un motor de

ejecución de contenedores el más usado para Kubernetes es Docker, aunque

también admite containerd, rkt y CRI-O.

● kubelet: es el encargado de controlar que todos los contenedores se ejecuten en un

pod, para lo cual se mantiene en comunicación con el plano de control.

● kube-proxy: este componente facilita los servicios de red de Kubernetes, mediante

un proxy de red que administra las comunicaciones de red dentro y fuera del clúster

(Red Hat, 2021).

 48

CAPÍTULO CUATRO

DISEÑO DE LA SOLUCIÓN

El presente capítulo aborda el diseño arquitectónico de la plataforma, partiendo del

análisis de los procesos y capacidades de Ascendere.

4.1. METAS Y LIMITACIONES ARQUITECTÓNICAS

Las plataformas digitales pueden ser variadas y complejas, desde simples mercados

y sistemas de redes sociales hasta entornos más complejos, donde los desarrolladores de

aplicaciones pueden crear y vender sus productos digitales (Zutshi & Grilo, 2019). Para

contextualizar el modelo de la arquitectura y los componentes que intervienen, se trabaja

en base a un mapa de capacidades, que posteriormente permitirá el diseño de casos de

uso.

● Del lado del usuario

Dentro de los consumidores y productores encontramos tanto a docentes, como

estudiantes y universidades que se involucran con la plataforma. Con la finalidad de

construir una plataforma atractiva para los usuarios, se incluye el diseño de experiencias

móviles centradas en cada uno de los participantes.

● Del lado del negocio

Se define el modelo de negocio de Ascendere para promover el compromiso entre

los actores del ecosistema. Se considera cada una de las motivaciones de los actores para

construir una propuesta de valor que permita crear una plataforma sostenible y escalable

dentro del mercado.

4.2. ANÁLISIS DE LA PLATAFORMA

Para poder convertir a Ascendere en un ecosistema digital se ha convenido construir

una Plataforma Digital, que permita la escalabilidad de las funciones de Formación,

Innovación y Evaluación. Una arquitectura de Plataforma está basada en conectar a varios

 49

clientes (aplicaciones móviles, páginas web, etc.) mediante la exposición de sus datos

gracias a APIs, esto también permite que desarrolladores terciarios puedan crear APIs y

aplicaciones en base a los datos que expone la organización.

4.2.1. Cadena de valor

Ascendere actualmente cuenta con tres departamentos: Innovación, Formación y

Evaluación Docente. Para el inicio de este proyecto se ha trabajado únicamente con el

departamento de Innovación Docente, encargado de la gestión de los Proyectos de

Innovación Docente, Buenas Prácticas y Retos. Estos son proyectos elaborados por los

docentes de la Universidad Técnica Particular de Loja, enfocados a la mejora educativa

dentro y fuera de la universidad.

En base al componente de Innovación se estructura una cadena de valor, descrita en

la figura 7 con los procesos y subprocesos de gestión de Proyectos de Innovación

Docente, siguiendo el estándar de gestión de proyectos ISO 21500.

Figura 7

Cadena de valor de Innovación Docente

Nota. Cadena de valor de los procesos y subprocesos de Innovación Docente aplicando los

estándares de la ISO 21500

4.2.2. Mapa de capacidades

Mediante un proceso de descomposición funcional a la cadena de valor de

Innovación Docente se diseña el mapa de capacidades tomando en cuenta los procesos y

 50

actividades del estándar ISO 21500. En la figura 8 se describen las capacidades,

funcionalidades y servicios de Innovación Docente.

Figura 8

Mapa de capacidades

Figura 8.1

Mapa de capacidades - Convocatoria

Figura 8.2

Mapa de capacidades - Postulación

 51

Figura 8.3

Mapa de capacidades - Gestión y seguimiento

 52

Figura 8.4

Mapa de capacidades - Cierre del proyecto

 53

4.3. ESQUEMA DE DESARROLLO

El éxito en el desarrollo requiere que las organizaciones doten de herramientas a

los desarrolladores que les permitan crear productos de manera productiva, escalar la

innovación, colaborar de forma global y segura. En consecuencia, se seleccionan las

herramientas que mejoren la colaboración, reduzcan el cambio de contexto, introduzcan la

automatización, aprovechando la observabilidad y el monitoreo para construir de forma

rápida y efectiva un software, acorde a las necesidades del negocio.

En la figura 9 se muestra la canalización de DevOps orientada a satisfacer las

necesidades del proyecto, considerando las habilidades y experiencia del equipo de

desarrollo.

Figura 9

Diagrama de canalización de DevOps

 54

4.4. ARQUITECTURA DE LA PLATAFORMA

La arquitectura, se desarrolla mediante el mapa de capacidades descrito

anteriormente, para el siguiente trabajo se decidió emplear los procesos de Convocatorias

y Postulaciones.

La arquitectura para el Proyecto Ascendere definida en la figura 10, considera el uso

de API Management que permita la creación de nuevas APIs por parte de otros

desarrolladores, el manejo y mantenimiento de las APIs ya existentes y la conexión con los

clientes. A esto le sumamos que la lógica de Ascendere estará descrita mediante una

arquitectura de microservicios, la cual estará orquestada con Kubernetes y a su vez al

requerir de una gran escalabilidad, hace necesario el uso de una arquitectura multi nube.

Figura 10

Diagrama de los componentes de la Arquitectura

Como se visualiza en la Figura 10 tenemos dos clústeres de Kubernetes con un nodo

cada clúster para Ascendere, estos nodos son: convocatoria-ascendere y

postulacion-ascendere, cada uno de ellos posee un el Nodo Maestro (Panel de Control)

 55

el cual se encuentra instanciado automáticamente en cada uno de los proveedores en la

nube. Este Nodo llamado Panel de control nos ayuda a servir mediante un API la

información expuesta por los microservicios, también se encarga del escalamiento

automático de los Nodos utilizando los Replicasets que son un conjunto de instrucciones

para mantener tres pods funcionando en todo momento, así como un balanceador de

carga para cada pod dentro de los Nodos.

Los Nodos de convocatoria-ascendere y postulacion-ascendere encapsulan los

procesos del apartado de Innovación Docente de Ascendere, estos son nodos esclavos

manejados por los nodos Maestro de cada cluster, cada Nodo se encuentra en un

proveedor de nube distintos para aprovechar los servicios otorgados por DigitalOcean y

Google Cloud.

4.5. CASOS DE USO

Los casos de uso son una excelente manera de proporcionar un proceso paso a

paso de cómo debería funcionar el sistema. Permiten al desarrollador ver lo que se

necesita y lo que no se necesita para asegurarse de que está desarrollando el software

correcto, es por ello que para esquematizar el funcionamiento de la plataforma Ascendere

se decidió por los casos de uso.

En base al mapa de capacidades se estructuran los casos de uso por cada módulo,

describiendo la interacción de los actores, con las funcionalidades de primer y segundo

nivel de la plataforma Ascendere.

Según el análisis realizado se crearon los módulos de:

- Gestión de convocatorias

- Gestión de postulación

A continuación, se detallaran cada uno de los módulos

 56

4.5.1. Gestión de convocatorias

El primer módulo de convocatorias abarca todo el proceso de gestión de las

convocatorias, detallado en la figura 11.

Figura 11

Diagrama de casos de uso de Gestión de Convocatorias

4.5.1.1. Caso de uso crear convocatoria

 57

El primer caso de uso detallado en la tabla 3, es la creación de la convocatoria

donde el gestor de la innovación después de autentificarse podrá proporcionar toda la

información necesaria y crear la líneas estratégicas para la convocatoria.

Tabla 3

Especificación del caso de uso crear convocatoria

Nombre del caso de uso Crear convocatoria

Descripción Para el presente caso de uso se describe cuando el gestor

crea una convocatoria.

Actores Gestor de innovación

Precondiciones El gestor de innovación debe estar autentificado

Postcondiciones Convocatoria creada

Flujo de eventos 1. El gestor ingresa la información en la convocatoria.

2. El gestor agrega líneas estratégicas, recursos,
resultados esperados, anexos, tipos de proyectos y
rúbrica a la convocatoria.

4.5.1.2. Caso de uso validar convocatoria

En el caso de uso de revisar convocatoria, se permite acceder al gestor de

innovación a las convocatorias creadas, realizar cambios respectivos, y validar los

objetivos y líneas estratégicas, como se muestra en la tabla 4.

Tabla 4

Especificación del caso de uso revisar convocatoria

Nombre del caso de uso Validar convocatoria

Descripción El caso de uso describe como el gestor realiza cambios en

la información de la convocatoria y procede a validar la
información de los objetivos y líneas estratégicas.

Actores Gestor de innovación

Precondiciones - El gestor de innovación debe estar autentificado

- Se ha creado una convocatoria previamente
 58

Postcondiciones Convocatoria validada

Flujo de eventos 1. El gestor accede a la convocatoria creada.

2. El gestor valida los objetivos, líneas estratégicas de
la convocatoria.

Flujo alterno 3. El gestor actualiza la información de la convocatoria.

4.5.1.3. Caso de uso publicar convocatoria

En la tabla 5 se muestra el caso de uso publicar convocatoria donde el gestor

permite notificar a todos los docentes.

Tabla 5

Especificación del caso de uso publicar convocatoria

Nombre del caso de uso Publicar convocatoria

Descripción El caso de uso describe cómo el gestor finaliza todo el

proceso de gestión de convocatorias al publicar la
convocatoria para todos los docentes.

Actores Gestor de innovación

Precondiciones - El gestor de innovación debe estar autentificado

- Se ha creado una convocatoria previamente
- La convocatoria ha sido aprobada

Postcondiciones Convocatoria publicada

Flujo de eventos 1. El gestor accede a la convocatoria validada.

2. El gestor pública la convocatoria.
3. El gestor envía la convocatoria generada a los
docentes.

4.5.2. Gestión de postulación

El segundo módulo abarca toda la gestión de la postulación del proyecto de

Innovación Docente, esto se ve reflejado en la figura 12.

Figura 12

Diagrama de casos de uso de gestión de postulación

 59

4.5.2.1. Caso de uso registrar propuesta

En el caso de uso para iniciar la postulación del proyecto de Innovación Docente se

registra el acta del proyecto con los elementos iniciales del proyecto. En la tabla 6 se

especifica el caso de uso.

Tabla 6

Especificación del caso de uso registrar propuesta

Nombre del caso de uso Registrar propuesta

Descripción El caso de uso describe cómo el docente registra el

proyecto, ingresando sus datos como coordinador del
proyecto, los principales docentes involucrados, objetivos y
alcance.
 60

Actores Docente

Precondiciones El docente debe estar autentificado

Postcondiciones Propuesta del proyecto registrada

Flujo de eventos 1. El docente revisa la convocatoria vigente del actual

periodo.
2. El docente ingresa la información del proyecto a
postular.
3. El docente agrega el equipo de trabajo y cronograma.

4.5.2.2. Caso de uso evaluar propuesta

En la tabla 7 se especifica el caso de uso de evaluar propuesta, en este caso de uso

el gestor de innovación del vicerrectorado académico revisa la propuesta registrada por el

docente.

Tabla 7

Especificación del caso de uso evaluar propuesta

Nombre del caso de uso Evaluar propuesta

Descripción El caso de uso describe cómo el gestor de innovación del

vicerrectorado académico evalúa la información descrita en
el acta del proyecto, así como la información de los
docentes involucrados y cronograma de actividades.

Actores Gestor de Innovación, Docente

Precondiciones El acta debe ser registrada

Postcondiciones Propuesta de proyecto validada

Flujo de eventos 1. El gestor de innovación revisa la propuesta del

proyecto.
2. El gestor de innovación valida la información.
3. El gestor de innovación envía una notificación al
docente con el estado de la evaluación.

Flujo alterno 4. El docente actualiza la información de la propuesta.

4.5.2.3. Caso de uso publicar propuesta

 61

En el caso de uso publicar propuesta, permite al gestor de innovación hacer pública

la propuesta ante los demás docentes, como se muestra en la tabla 8.

Tabla 8

Especificación del caso de uso registrar el plan de gestión del proyecto

Nombre del caso de uso Publicar propuesta

Descripción El caso de uso describe cómo el gestor finaliza todo el

proceso de gestión de postulación al publicar la propuesta
para todos los docentes.

Actores Docente, Gestor de Innovación

Precondiciones El acta del proyecto debe estar validada y aprobada

Postcondiciones Plan de gestión de proyecto registrado

Flujo de eventos 1. El gestor accede a la propuesta de proyecto validada.

2. El gestor pública la propuesta.
3. El gestor envía la notificación del estado de la
propuesta.

4.6. REQUERIMIENTOS DE USUARIO

En el actual apartado se describen y definen las necesidades de los actores dentro

de la plataforma.

4.6.1. Relación entre historias épicas y diagramas de caso de uso.

Como en el apartado anterior se han desarrollado los diagramas de los casos de

uso para el desarrollo de la plataforma, es conveniente considerar a las historias de

usuario como una forma adicional para la descripción de requerimientos, facilitando el

proceso tras el análisis realizado dentro de los flujos de eventos.

Se considera necesario las historias de usuario ya que nos facilita desarrollar cada

requisito funcional dentro de un entorno ágil, permitiendo añadir más detalle de desarrollo

como es la prioridad y criterios de aceptación.

 62

Actualmente se opta por un desarrollo centrado en las historias de usuario, en el

presente proyecto hemos optado por diagramas de casos de uso debido a la correlación

que existe entre el análisis del flujo y el mapa de capacidades.

4.6.2. Historias épicas

En esta sección se describen las historias épicas relacionadas a la especificación

de los casos de uso desarrollados en la sección anterior, donde se pueden ver la división

de la plataforma Ascendere y sus necesidades como historias épicas y estas a su vez

divididas en historias de usuario.

Épica Historias de usuario

Cómo usuario Cómo usuario

Quiero registrarme en la plataforma
Para contribuir con el desarrollo de los
proyectos de innovación docente
Quiero un formulario de registro
Para crear mi cuenta
Cómo usuario
Quiero establecer mi rol
Para crear gestionar mi participación

Cómo usuario
Quiero postear información
Para compartir hechos y datos con la
comunidad de usuarios

Cómo usuario
Quiero seguir a otro usuario
Para obtener información de otros usuarios

Cómo gestor de innovación Cómo gestor de innovación

Quiero gestionar los recursos del
laboratorio de innovación e investigación
docente
Para tener un control sobre ellos
Quiero poder generar nuevos recursos
Para que los docentes puedan hacer uso
Cómo gestor de innovación
Quiero poder visualizar el inventario de
recursos
Para poder gestionar su uso

Cómo docente
Quiero poder realizar un pedido
Para hacer uso de los recursos del
laboratorio

Cómo gestor de innovación Cómo gestor de innovación


Quiero registrar convocatorias
Para tener un control sobre ellas
Cómo docente
Quiero registrar una postulación
Para iniciar el proceso de gestión de
proyectos de innovación docente
Cómo docente
Quiero registrar los planes del proyecto
validado
Para gestionar el proyecto
4.7. DIAGRAMAS DE CLASE
Dentro de un entorno de arquitecturas de microservicios para el desarrollo de cada
servicio, se ha implementado un diagrama de clase desde la especificación de casos de
uso.
63
Quiero un formulario de registro
Para registrar nuevas convocatorias
Cómo gestor de innovación
Quiero visualizar las convocatorias
generadas
Para poder gestionarlas
Cómo gestor de innovación
Quiero publicar una convocatoria
Para que los docentes puedan postular
Cómo docente
Quiero un formulario de registro
Para registrar un nuevo proyecto
Cómo docente
Quiero visualizar mis postulaciones
generadas o de las que formó parte
Para poder gestionarlas
Cómo gestor de innovación
Quiero validar una postulación
Para que los docentes puedan proceder a
gestionar los planes del proyecto
Cómo docente
Quiero un formulario de registro
Para registrar los distintos planes de
gestión del proyecto
Cómo docente
Quiero visualizar mis planes de gestión del
proyecto que formó parte
Para poder gestionarlos
Cómo gestor de innovación
Quiero validar los planes de gestión
Para que los docentes puedan comenzar a
desarrollar el proyecto
 64

4.7.1. Microservicio de Convocatoria

Se encarga de permitir que un usuario administrador pueda crear una convocatoria

con la siguiente información: antecedentes objetivos, reconocimiento, compromiso, fechas

de postulación, resultados esperados, rúbricas de evaluación, recursos disponibles, líneas

estratégicas, anexos y tipos de proyectos, según detalla la Figura 15.

Figura 15

Diagrama de clases del microservicio de convocatoria.

4.7.2. Microservicio de Postulación

Permite a un docente postularse a la última convocatoria registrada. Este

microservicio basa su formato en los requerimientos señalados en la ISO 21500 tales

 65

como: justificación, alcance, objetivos, requerimientos de alto nivel, resultados,

restricciones y cronograma. Adicionalmente permite realizar la evaluación por cada

propuesta en torno a la rúbrica de la convocatoria de acuerdo con lo establecido en la

Figura 16.

Figura 16

Diagrama de clases del microservicio de postulación.

4.7.3. Microservicio de Usuarios

Este microservicio se encuentra enfocado en almacenar datos de docentes

(persona), tales como información personal, asignaturas y facultades, adicionalmente,

cada docente posee un rol que se emplea dentro de la Gestión de Proyectos

(Administrador/Usuario) como se muestra en la Figura 13.

 66

Figura 13

Diagrama de clases del microservicio de usuarios.

4.7.4. Microservicio de Inventario

Este microservicio se encuentra orientado a permitir la realización de pedidos por

parte de los docentes a los administradores, almacenando información como la cantidad

de recursos disponibles y prestados, como se señala en la Figura 14.

Figura 14

Diagrama de clases del microservicio de inventario.

67
 68

CAPÍTULO CINCO

DESARROLLO

El presente capítulo aborda el desarrollo de la plataforma Ascendere a nivel de

tecnologías empleadas. En este capítulo se detallarán desde el desarrollo de los

microservicios, la configuración del clúster de kubernetes, además de las herramientas de

automatización basadas en los conceptos de DevOps.

5.1. TECNOLOGÍAS EMPLEADAS

Para la construcción de la plataforma Ascendere se usaron varias herramientas de

código abierto las cuales dividiremos a continuación en herramientas para la canalización

de DevOps, creación del clúster de kubernetes y servidores multi nube.

5.1.1. Canalización de DevOps

Dado que no existe una canalización de DevOps estándar, el diseño y la

implementación de una canalización dentro de Ascendere se realizó con base en la pila de

tecnología, el nivel de experiencia y el presupuesto. Como resultado se selecciona un

grupo de herramientas detalladas en la Tabla 9.

Tabla 9

Herramientas por cada componente de una canalización de DevOps

Componente Herramienta Uso

Planificación Asana Se utilizó para gestionar los flujos de trabajo del

proyecto Ascendere, dado que ofrece la
posibilidad de llevar de forma detallada todas las
etapas de gestión de proyectos desde el inicio
hasta el cierre de cada una, así mismo
conectará a todo el equipo de trabajo mejorando
la organización y planificación para llevar todo el
proyecto de la manera adecuada.

Slack Se utilizó para mejorar la comunicación del

equipo de trabajo y la capacidad de respuesta,
gracias a las características como:
notificaciones, filtrados por canales, proyectos,
 69

tipos de problemas, prioridades y configuración

de bots de otras herramientas.

Codificación GitHub Se utilizó para el control de código fuente

(alojamiento de código para el control de
versiones y la colaboración).

Visual Studio Se utilizó como entorno de desarrollo integrado

(IDE), debido a la amplia gama de extensión e
integración con las herramientas detalladas.

Compilación Docker Se utilizó para contenerizar cada uno de los

microservicios desarrollados, gracias a la
facilidad de la portabilidad que nos permite el
adecuado funcionamiento de los microservicios
en diferentes entornos.

Kubernetes Facilita las tareas de gestión de arquitectura

basadas en arquitecturas, implementación de
contenedores, las actualizaciones, el
descubrimiento de servicios, el
aprovisionamiento de almacenamiento, el
equilibrio de carga y la supervisión del estado.

Integración y GitHub Actions Se utilizó para la construcción de los diferentes

entrega continua pipelines de los microservicios almacenados en
GitHub.

Pruebas Flutter, Golang Para las respectivas pruebas se utilizan la

propias librerías y paquetes de los lenguajes de
programación seleccionados

Monitoreo WSO2 Se utilizaron las herramientas proporcionadas

por WSO2 para llevar a cabo el monitoreo de la
utilización de la API y el acceso a los
microservicios.

5.1.2. Clúster de kubernetes

Para la implementación del clúster de kubernetes que formará la plataforma

Ascendere se optó por las siguientes herramientas detalladas en la Tabla 10.

Tabla 10
 70

Herramientas para la creación y gestión del clúster de kubernetes para la plataforma

Ascendere.

Grupo Componente Herramienta Detalles

Frontend Framework Flutter Flutter es un framework de

desarrollo híbrido que permite el
desarrollo rápido y ágil para las
diversas plataformas como web,
Android y iOS.

El proyecto se desarrolló en flutter

debido a la necesidad de desplegar
una aplicación tanto web como
móvil.

Backend Lenguaje Go/Golang Existen diferentes lenguajes de

programación con características
distintivas, por tanto, para el
presente proyecto se seleccionó
Go, gracias a su funcionalidades
optimizadas para el desarrollo
concurrente y paralelo.

Api API WSO2 API Manager es una

Management Management plataforma completa para crear,
WSO2 integrar y exponer sus servicios
digitales como API administradas
en la nube, en las instalaciones y
en arquitecturas híbridas para
impulsar su estrategia de
transformación digital.

Permite a los desarrolladores de

API diseñar, publicar y administrar
el ciclo de vida de las API y los
administradores de productos de
API para crear productos de API a
partir de una o más API.

Integración con Integrador Business Process Server (BPS)

servicios web empresarial escalable y estable ayuda a
externos WSO2 aumentar la productividad y mejorar
la competitividad al permitir a los
desarrolladores implementar
 71

fácilmente procesos y modelos

comerciales escritos con BPEL y
BPMN.

5.1.3. Servidores multi nube

Al pensar en Ascendere como un ecosistema digital, nos vimos en la obligación de

usar un esquema de múltiples nubes que soporten todos los procesos. En la Tabla 11 se

detallan las nubes escogidas para albergar la plataforma.

Tabla 11

Herramientas para la creación y gestión del clúster de kubernetes para la plataforma

Ascendere.

Nombre Definición Detalles

Digital Ocean Es un proveedor de servidores Para la gestión de las postulaciones

virtuales privados, cuya mayor se creó un nodo con un pod de
característica es la escalabilidad. Postulaciones y tres réplicas, el cual
se destinó a un cluster de
Kubernetes en la nube de Digital
Ocean.

GCP Google Cloud Plataform, es una Se creó un cluster de Kubernetes en

plataforma que ofrece servicios
de tecnología de la información
en la nube, la gran característica
de esta plataforma es la
flexibilidad y eficiencia de sus
servicios.
GCP con un nodo con pods para la
gestión de Convocatorias, Usuarios
y Recursos, cada pod cuenta con su
respectivas réplicas.

Docker Hub Docker Hub es un servicio de En esta plataforma se encuentran

registro de contenedores las imágenes de los microservicios
(Docker), en esta plataforma se de Ascendere dockerizados.
ubican todas las imágenes de los
contenedores de los
microservicios de Ascendere.
 72

5.2. DESARROLLO DE LA PLATAFORMA

Para el desarrollo de la plataforma Ascendere, se utilizaron las herramientas

preseleccionadas que permitieron la creación y posterior modificación de la misma, de

acuerdo a la especificación de casos de uso e historias de usuario.

A continuación, se detallan las fases del desarrollo para la construcción de la

plataforma.

5.1.1. Diseño y prototipado de la Plataforma

En el diseño se consideraron elementos y patrones centrados en el personal de

gestión del departamento de Innovación Docente y en los docentes que harán uso de la

plataforma. Las funcionalidades dentro del diseño están alineadas a la especificación de

casos de uso e historias de usuario.

Para iniciar el proceso de diseño se desarrolló el mapa del sitio (Sitemap de su

nombre en inglés), donde se mapean los flujos de actividades que podrán realizar tanto el

gestor de innovación como el docente:

- Actividades del gestor de innovación: crear una convocatoria, revisar convocatorias

creadas, publicar convocatorias, revisar listado de recursos, añadir o modificar

recursos, revisar o aceptar postulaciones, revisar usuarios y modificar roles de

usuario.

- Actividades del docente: revisar la última convocatoria vigente, crear una

postulación, revisar el estado de postulaciones creadas y acceder a la red de

docentes.

De acuerdo a las actividades delimitadas en el Sitemap, se procede con la

investigación visual de elementos y recursos a utilizar en el prototipado de la plataforma.

Los elementos básicos de diseño son establecidos por parte de Ascendere, determinando

la paleta de colores, estructura y tipografía acorde a la marca del proyecto.

 73

Con la investigación visual y las actividades identificadas, se procede a desarrollar

el prototipo de la plataforma, mediante el uso de bocetos de alto nivel (wireframes de su

nombre en inglés) como se muestran en la Figura 15.

Figura 15

Prototipos de alto nivel de la plataforma

5.1.2. Desarrollo de la canalización de DevOps de la plataforma Ascendere

En esta sección, veremos cómo se llevó a cabo la construcción de la canalización

de DevOps para el desarrollo de la plataforma mediante el uso de flujos de trabajo para

cada una de las actividades.

Inicialmente se crea cada uno de los repositorios del proyecto en GitHub, en este

caso un repositorio para la aplicación web/móvil y para cada uno de los microservicios,

posteriormente utilizaremos GitHub Actions a fin de facilitar la creación de los flujos de

trabajo que sean necesarios para su respectivo repositorio.

Al crear un flujo de trabajo en GitHub, es necesario crear una carpeta llamada

workflows en la ruta .github del repositorio, que almacena cada uno de los flujos de
 74

trabajo. Dentro de la carpeta podemos agregar los flujos de trabajo que sean necesarios.

Para el repositorio de la aplicación web/móvil creamos un flujo de trabajo orientado a

realizar despliegue de aplicación en web (deploy_web.yml) y otro para generar los

instaladores de aplicación móvil (relese.yml) como se muestra en la Figura 16. En el caso

de los microservicios en cambio tenemos un flujo para realizar los test (test.yml) y otro

para desplegar el microservicio a su respectiva nube (deploy_gke.yml) como se muestra

en la Figura 17.

Figura 16.

Flujos de trabajo del repositorio de la aplicación web/móvil.

Figura 17.

Flujos de trabajo del repositorio del microservicio de usuarios.

 75

Un flujo de trabajo consta de la siguiente estructura, comenzamos especificando su

nombre y después de la palabra “on” definimos que eventos de control del repositorio

pueden hacer que se ejecute el flujo, si es necesario se declaran variables de ambiente

después de la palabra “env” (Ver Figura 18). Posteriormente estableceremos los trabajos

que queremos que realice el flujo, para esto utilizaremos la palabra “jobs”, en este flujo de

trabajo creamos dos trabajos, uno para el registro de la imagen en Docker Hub y otro para

el despliegue en Google Cloud.

Para cada trabajo se establece su nombre, el ambiente donde se ejecuta

(runs-on), dependencias a otros trabajos (needs), el entorno (environment) y los pasos

que tendrá que seguir el trabajo (steps). Los pasos pueden ejecutar comandos, tareas de

configuración o acciones dentro del repositorio. Como se muestra en la Figura 19 para el

trabajo del despliegue del microservicio a la nube definen los siguientes pasos:

1. Accedemos al repositorio.

2. Configuramos la interfaz de línea de comando de gcloud.

3. Ingresamos las credenciales de Google Kubernetes Engine (GKE por sus siglas

en inglés).

4. Desplegamos la imagen de Docker Hub a GKE de acuerdo a la configuración de

Kubernetes de los archivos de service.yml (Ver Figura 20) y deployment.yml

(Ver Figura 21). El primer archivo nos permite crear el servicio que expondrá

nuestro microservicio y el segundo archivo se establece la configuración de los

pods en ejecución.

Figura 18.

Flujo de trabajo para el despliegue del microservicios de usuarios a la nube

 76

Figura 19.

Trabajos del flujo de trabajo para el despliegue del microservicios de usuarios

Figura 20.

Archivo service.yml
 77

Figura 21.

Archivo deployment.yml
 78

Para llevar a cabo todo el desarrollo de la Plataforma se construyeron diferentes

flujos de trabajo por cada uno de los repositorios, siguiendo la estructura del flujo de

trabajo abordado anteriormente, a continuación revisaremos los flujos de trabajo

implementados:

5.1.2.1. Canalización para la publicación de imagen de Docker Hub

Para la canalización se consideran los siguientes pasos:

1. Acceder al repositorio

2. Iniciar sesión en Docker Hub

3. Construir y enviar la imagen de Docker

4. Publicar la imagen en Docker Hub

Figura 18

Canalización para la publicación de imagen de Docker Hub

5.1.2.2. Canalización para el despliegue Google Kubernetes Engine

Para realizar la canalización de despliegue para Google Kubernetes Engine (GKE)

es indispensable haber desplegado la imagen del contenedor en Docker Hub:

1. Acceder al repositorio

2. Configuración de gcloud CLI

 79

3. Ingresar credenciales GKE

4. Desplegar la imagen de Docker Hub a GKE

Figura 19

Canalización para el despliegue Google Kubernetes Engine

5.1.2.3. Canalización para el despliegue en Digital Ocean

Para realizar la canalización de despliegue para Digital Ocean es indispensable

haber desplegado la imagen del contenedor en Docker Hub:

1. Acceder al repositorio

2. Instalar Doctl

3. Guardar información de Kubeconfig

4. Desplegar la imagen de Docker Hub a Digital Ocean

5. Verificar el despliegue

Figura 20

Canalización para el despliegue en Digital Ocean

 80

5.1.2.4. Canalización para testing

Para cada microservicio se implementan los respectivos archivos de test

dependiendo del lenguaje de programación y ejecuta su implementación automática con la

canalización señalada en la figura 21.

Figura 21

Canalización de testing de Go
 81

5.1.3. Desarrollo de microservicios

En base a la especificación de casos de uso obtenidos del análisis de negocio se

implementan las diferentes clases, atributos, operaciones y relaciones entre objetos.

Se inició por establecer el sistema de ficheros, para lo que se utilizaron cinco

carpetas para almacenar el código: bd carpeta en la que se almacena todo lo referente a

conexiones con la base de datos, models en esta carpeta se guardan las clases creadas

para cada micro, routers esta carpeta está diseñada para almacenar el código que

permite realizar peticiones http y crear los endpoints de acceso, middlew aquí se

encuentran todos los middlewares (un middleware es una función que toma una función y

retorna otra función, de esta forma podemos encapsular varias funciones en una sin que

ninguna de estas funciones conozca el estado de las otras); por último existe la carpeta

handlers donde se ubican los controladores encargados de escribir los encabezados y

cuerpos de respuesta, además de almacenar una asignación entre las rutas de URL

predefinidas.

Una vez definido el sistema de archivos se procede a instanciar las librerías que se

van a usar, en nuestro caso al usar el lenguaje GO, se debe crear un archivo denominado

go.mod en el cual se escribe el link desde el cual se extraerán las librerías necesarias.

Cabe destacar que al utilizar GO con la librería gorilla-mux (Ver Figura 22) nos ahorramos

el uso de Frameworks para el desarrollo de Backend, esto permite que el código pueda

compilar a mayor velocidad.

Figura 22

Importación de librerías en GO
 82

Después de instanciar las librerías en GO se procedió a crear los modelos según el

diagrama de clase especificado para cada microservicio, GO como tal no tiene un sistema

de clases como sí poseen otros lenguajes de programación, en vez de eso posee un

sistema denominado estructuras, estas estructuras se comportan como clases pudiendo

mantener propiedades como la herencia y polimorfismo. Algo que permite GO es que al

momento de crear una estructura se puede definir el cómo vendrán los datos de la base de

datos (en este caso al usar MongoDB como base de datos el formato de los datos es

bson) y el formato con el que expondremos los datos (json), tal cual se evidencia en la

Figura 23.

Figura 23

Modelo de Convocatoria en GO
 83

Al tener todos los modelos del microservicio implementados, pasamos a desarrollar

las conexiones a la base de datos, aunque en GO no existan como tal las clases si se

mantiene la programación orientada a objetos incluyendo los principios que rodean este

paradigma. Por ello se optó por mantener dichos principios creando archivos por cada

función de crear, buscar, actualizar y eliminar (CRUD por sus siglas en inglés), de esta

manera se consigue el principio de responsabilidad única. En la Figura 24 se puede

apreciar la conexión con la base de datos para el registro del tipo de proyectos, cómo se

optó por el uso de MongoDB no se obtienen tablas sino colecciones de datos, ya que los
 84

datos se guardan en registros y no existen las relaciones, en cambio en MongoDB se

crean referencias a otras colecciones o registros.

Figura 24

Conexión con la base de datos MongoDB utilizando GO

Cuando ya tenemos las conexiones a la base de datos, procedemos a crear los

enrutamientos, estas son funciones HTTP a las que les llegarán una petición con datos

desde el Header o el Body y enviarán una respuesta de igual manera mediante el Header

o el Body. Es en este momento en el que se describen los códigos de error como el 404 o

el 501, como se puede ver en la Figura 25.

Figura 25

Enrutamiento para la búsqueda de una convocatoria en GO

 85

Una vez terminado de escribir los enrutamientos, desarrollamos los middleware

necesarios para validar los Tokens de acceso y chequear que exista una conexión a la

base de datos, al crear los middleware podemos reutilizar el código y usar nuestras

funciones middleware cuando hagamos la llamada a las otras funciones. En la Figura 26

se muestra el middleware para validar el Token de acceso, este recibe como parámetro

cualquier función (las funciones routers creadas anteriormente), y devuelve una función

que nos demuestra si el Token es válido o no.

Figura 26

Middleware para la validación de Tokens en GO

 86

Para poder crear el Endpoint que es consumido por el Frontend, se utilizó un

Handler que contiene cada ruta que se expondrá, conectado a la función del paquete

router correspondiente y el valor del puerto por el cual saldrá la información. Ver Figura 27.

Figura 27

Endpoints y puerto de acceso para el microservicio de convocatorias en GO

 87

Para finalizar el desarrollo se crea un archivo para realizar la compilación del

microservicio, este archivo es el main.go, como se encuentra en la Figura 28 tenemos una

verificación de la conexión a la base de datos y se realiza un llamado a los handlers

creados.

Figura 28

Archivo principal para realizar la ejecución del microservicio de convocatorias en GO

Cuando terminamos una sección del desarrollo, actualizamos los cambios en el

repositorio de pruebas, este repositorio se encuentra conectado directamente con los

servidores de Heroku, el cual nos permite probar uno a uno los microservicios, de esta

forma reducimos los costos del desarrollo de los microservicios. En la Figura 29 se

aprecian los microservicios en el entorno de pruebas de Heroku.

Figura 29

Entorno de pruebas de Heroku para el despliegue del microservicio de convocatorias

 88

Para las pruebas empleadas de los respectivos Endpoints obtenidos de cada

microservicio utilizamos Postman en esta herramienta colocamos el tipo de petición (GET,

POST, PUT, DELETE), junto con el Endpoint generado y el Header o Body

correspondiente; de esta manera podemos probar el funcionamiento de los Endpoints sin

necesidad de crear un Frontend. En la Figura 30 se muestra el test del Endpoint para

iniciar sesión del microservicio del usuario, en este caso no se envía nada por el Header

únicamente el usuario y la contraseña mediante el Body, y esperamos de regreso la

contestación del servidor. Si la información y la petición son correctas se envía un mensaje

en este caso el Token del usuario y un código 200, en caso de tener un error se enviará un

código 400 y un mensaje de error.

Figura 30

Ejemplo de Endpoint para el ingreso de sesión del microservicio de usuarios.

 89

Cuando ya se ha probado el microservicio en el entorno de test de Heroku se

procedió a unir los cambios con los de la rama principal del repositorio, una vez se envían

los cambios comienza el proceso de canalización de DevOps para el despliegue a

producción de los microservicios hacia las distintas nubes.

5.1.4. Implementación WSO2

Para la implementación de WSO2 se desplegó mediante una máquina virtual alojada

en DigitalOcean, la imágen oficial del API Manager. Cabe destacar que para el correcto

funcionamiento del API Manager se requiere de un mínimo de 4Gb de Ram y 2vCPUs,

para nuestro caso usamos una instancia de CPUs compartida para reducir los costos de

desarrollo.

WSO2 en su API Manager nos brinda 3 servicios, el primero es el de gestión de

usuarios y roles para poder administrar el ecosistema (sistema carbon), el segundo es

para la publicación de APIs (sistema publisher) y el tercero es el que permite usar las APIs

(sistema devportal).
 90

En el sistema carbon se pueden crear nuevos usuarios y asignar roles o crear roles

mediante la cantidad de permisos que se quiera conferir al ecosistema. Entre los roles por

defecto que nos brinda WSO2 tenemos:

- Admin: es el rol de administración tiene control absoluto sobre el ecosistema

pudiendo gestionar la información de todos los otros usuarios.

- Publisher: es el rol encargado de la publicación de APIs y el control de los mismos.

- Developer: el usuario con este rol puede crear aplicaciones que harán uso de las

APIs publicadas en el ecosistema.

En el sistema publisher se crearon una API por cada microservicio y se conectaron al

endpoint de los pods. Esto nos genera un nuevo endpoint con la url del API Manager, el

puerto de exposición, el nombre del microservicio y la versión actual. Al publicar una API

se puede configurar la cantidad de llamadas al endpoint realizado y el plan de costos, en

este caso se decidió mantener el uso de los servicios gratuitos y la cantidad de llamadas

ilimitadas. En la figura 22 se puede apreciar las APIs publicadas dentro del ecosistema de

Ascendere.

Figura 22

APIs de Ascendere publicadas en WSO2

 91

Para terminar con la implementación de WSO2 se utilizó el sistema de Devportal,

mediante el cual se creó una aplicación denominada innovacion-docente. Una vez creada

la aplicación se procedió a suscribirse a cada API que se encuentre en estado de

publicación. Al estar suscrito se genera un token de la aplicación que será usado por los

distintos frontends para consumir la información de los microservicios. En la figura 23

podemos observar la aplicación generada en WSO2 y sus suscripciones a los APIs.

Figura 23

Aplicación para la gestión de Innovación Docente de Ascendere en WSO2

 92

5.1.5. Desarrollo web y móvil

se uso flutter se consumio los apis conectandose al api manager con manejo de json web

tokens para autenticar el inicio de sesión y los permisos de acceso al api, etc
 93

CAPÍTULO SEIS

RESULTADOS, CONCLUSIONES Y RECOMENDACIONES

El actual capítulo aborda la etapa final del presente proyecto de investigación,

comprenderá la muestra de resultados y conclusiones del desarrollo e implementación de

la plataforma digital Ascendere.

6.1. PLATAFORMA ASCENDERE

La Plataforma Ascendere consta de los apartados de convocatorias, postulaciones

y recursos abarcando sus respectivas capacidades. La plataforma está preparada y

optimizada para su funcionamiento tanto en dispositivos móviles, como en su versión web

en los diferentes navegadores.

Consta de dos versiones, una orientada para los administradores, y otra dirigida a

los docentes.

6.1.1. Convocatorias

La plataforma permite la creación y gestión de las convocatoria para los

administrativos, así como la visualización de las convocatoria vigente para la versión de los

docentes.

Figura 24

Creación de convocatorias en la Plataforma Ascendere

 94

6.1.2. Postulaciones

La plataforma permite a los docentes realizar el registro propuestas de los

proyectos, proporcionando toda la información necesaria. Por el lado de administradores

se muestra un listado de las postulaciones existentes, para su respectiva validación.

Figura 25

Creación de una postulación en la Plataforma Ascendere

 95

Figura 26

Listado de postulaciones en la Plataforma Ascendere

6.1.3. Recursos

Adicionalmente, la plataforma consta de un apartado orientado a la gestión de

recursos, donde permite el control de la cantidad de recursos existentes y disponibles, de

 96

tal manera que facilita la distribución de los mismos para el desarrollo de los proyectos

propuestos para la convocatoria vigente.

Figura 27

Apartado de Recursos en la Plataforma Ascendere (versión móvil)

6.1.4. Implementación de microservicios

La implementación de cada microservicio se realizó en su respectiva nube,

además, los microservicios constan de tres pods y un balanceador de cargas externo. En

la Tabla 12 se detallan los resultados obtenidos dentro del periodo activo de los mismos.

Tabla 12

Resultados de la implementación de los microservicios

 97

Nombre del Nube Caracterí Pods en Revisiones Reinicios Nombre del

microservicio sticas ejecución activas servicio de
Hardware balancear de
cargas externo

micro-convocato Google Autopilot 3 8 0 micro-convoca

rias-deployment Cloud (autoesc torias-deploym
alable) ent-service

micro-resources- Google Autopilot 3 2 0 micro-resourc

deployment Cloud (autoesc es-deployment
alable) -service

micro-users-depl Google Autopilot 3 2 0 micro-users-d

oyment Cloud (autoesc eployment-ser
alable) vice

micro-postulacio Digital 1 vCPU 3 3 0 micro-postulac

nes-deployment Ocean 2 GB iones-deploym
Ram ent-service
50 GB
disco

6.1.5. API Manager

La Plataforma Ascendere consta de un marketplace de APIs como se puede

visualizar en la figura 26, listo para el consumo de terceros, ofreciendo los servicios

implementados, mediante el registro de las aplicaciones que solicitan su acceso. Este

apartado de Ascendere permite definir valores y costos limitando el acceso a los servicios

a otros miembros del ecosistema.

Figura 26

Marketplace de la Plataforma Ascendere

 98

6.1.6. ACUERDOS DE NIVEL DEL SERVICIO

Una vez obtenida la plataforma Ascendere se estableció un Acuerdo de Nivel de

Servicio (SLA por sus siglas en inglés) en conjunto con el director de Innovación,

Formación y Evaluación al Docente. Ascendere establece un contrato para con los

gestores y docentes que harán uso de la plataforma, este contrato vendría a ser un SLA de

Servicio, como se demuestra en la Figura 27, Ascendere se compromete a la

disponibilidad de todos sus servicios.

Figura 27

SLA de la plataforma Ascendere

 99

Para poder cumplir con lo estipulado en el SLA de la plataforma Ascendere se

realizaron pruebas de carga a los microservicios simulando el acceso de 500 usuarios

concurrentes, cada uno de los usuarios realizó 20 sesiones dentro de la aplicación. En la

Tabla 13 se detallan los resultados obtenidos de las pruebas realizadas.

Tabla 13

Resultados de las pruebas de carga en los microservicios

Nombre del Cantidad Cantidad CPU Promedio de Número de Porcentaje de

microservicio de de Carga errores disponibilidad
Usuarios sesiones
Activos por Usuario

micro-convocato 500 20 55.43% 0.15 min 1 99.98%

rias-deployment

micro-resources- 500 20 15.77% 0.085 min 0 100%

deployment

micro-users-depl 500 20 18.10% 0.063 min 0 100%

oyment

micro-postulacio 500 20 89.31% 0.87 min 4 99.96%

nes-deployment
 100

Para determinar la disponibilidad completa de la plataforma se realizó un promedio

del porcentaje de disponibilidad de cada uno de los microservicios. La forma en la que se

determinó el porcentaje de disponibilidad de cada uno de los microservicios fue restando el

100% de disponibilidad a la multiplicación de los errores totales por cien y esa cantidad

dividirla por la cantidad de sesiones realizadas (para cada microservicio la cantidad de

sesiones realizadas es diez mil, esto se debe a que cada usuario realizó veinte sesiones y

se especificó la cantidad de quinientos usuarios). De esta manera se calculó la

disponibilidad completa de la plataforma dándonos un 99.985% de disponibilidad lo que

redondeado a dos cifras nos devuelve un 99.99% de disponibilidad cumpliendo con el SLA

estipulado por la Dirección de Innovación, Formación y Evaluación Docente.

6.2. CONCLUSIONES

El propósito de este trabajo fue definir e implementar el ecosistema de negocio del

Proyecto Ascendere. En base a los resultados, se puede concluir que se logró la

construcción del ecosistema Ascendere mediante una plataforma digital. Para esta primera

iteración se redujo el alcance al departamento de Innovación Docente. Vale la pena

explorar la finalización del ecosistema anexando los otros dos departamentos de la

dirección de Innovación, Formación y Evaluación Docente.

El segundo objetivo de este estudio fue investigar el uso de plataformas y

ecosistemas digitales en las empresas y los beneficios que éstas les otorgan, para su

posterior construcción. Este estudio ha demostrado que, en general el uso de plataformas

y ecosistemas digitales benefician a las empresas que quieran movilizar sus procesos

hacia mercados digitales, de igual forma ayudan a la automatización de procesos y

mejoran la experiencia de los usuarios. Cabe destacar que la mayoría de documentación

 101

encontrada corresponde a revistas y artículos empresariales, existe muy poca

investigación sobre la construcción de ecosistemas desde el punto de vista informático, es

por ello por lo que el presente estudio sienta las bases para futuras investigaciones sobre

el desarrollo de ecosistemas digitales y plataformas.

El alcance de este trabajo fue limitado en términos de la cantidad de procesos que

se desarrollaron para la plataforma Ascendere, sin embargo se establece un diseño del

ecosistema para los restantes departamentos de la dirección de Innovación, Formación y

Evaluación Docente. Esto con el afán de que pueda ser utilizado para futuros trabajos y

mejoramiento de la plataforma.

La arquitectura planteada para la plataforma Ascendere ha proporcionado una

visión más profunda de los ecosistemas digitales y su funcionamiento. También ha

planteado la abertura del ecosistema para que futuros trabajos permitan el acoplamiento

de otras plataformas o ecosistemas, pudiendo ser de ayuda para el trabajo conllevado

dentro de la Universidad Técnica Particular de Loja.

El último objetivo de este trabajo fue el de establecer un SLA que permita evaluar el

desempeño de la plataforma. En base a los resultados de la evaluación realizada análisis,

se puede concluir que la plataforma cumple con la disponibilidad dispuesta en el SLA de

la plataforma, a pesar del uso de una máquina virtual administrada manualmente con bajos

recursos para el nodo de postulacion-ascendere. También como demuestran los

resultados los microservicios se mantuvieron encendidos y operativos durante todo el

proceso de desarrollo, sin presentar fallas o errores que los hagan re construirse.

6.3. RECOMENDACIONES
 102

Para la plataforma Ascendere se diseñó una arquitectura basada en microservicios

para disminuir el uso de microservicios encendidos se recomienda optar por una

arquitectura híbrida, utilizando los microservicios para los procesos de mayor demanda y

otras arquitecturas como serverless para procesos más rutinarios y sencillos.

Para mantener la plataforma Ascendere se debería considerar el cambio de cluster

para el nodo de postulacion-ascendere, de uno administrado manualmente hacia uno

autoadministrado o autopilot, esto con el fin de mejorar el autoescalamiento y reducir la

tasa de errores presentes.

 103

CAPÍTULO SIETE

TRABAJOS FUTUROS

La importancia del proyecto Ascendere no solo radica en su actual implementación,

sino que además, posee una gran capacidad de adaptación en diversos entornos de

modelos de negocio, tal es el caso de los diferentes departamentos de Ascendere e

incluso de toda la Universidad Técnica Particular de Loja.

Como propuesta de modelos que podrían aplicarse a futuro encontramos:

● Frente a las necesidades de los docentes durante el desarrollo de sus actividades

académicas, Ascendere busca potenciar la capacitación continua, a través de

diferentes recursos. Este planteamiento nos permite integrar dentro de la

plataforma, nuevas funcionalidades dirigidas a la formación docente, permitiendo

incluso al ecosistema integrar empresas enfocadas en la capacitación docente, así

como, instituciones educativas interesadas en la capacitación de su personal.

● Al considerar el entorno de la UTPL como un ecosistema digital, se puede generar

plataformas pertenecientes a diferentes departamentos de esta universidad, lo que

permitirá habilitar servicios y productos, facilitando la comunicación e integración de

la información de las diferentes áreas de esta institución.

 104

REFERENCIAS

Arango Serna, M., Londoño Salazar, J., & Zapata Cortés, J. (2010). Arquitectura orientada

a servicios en el contexto de la arquitectura empresarial. Escuela de Ingeniería de

Sistemas, Universidad Nacional de Colombia Sede Medellín, 7(2), 74–88.

Avramakis, E., Anchen, J., & Raverkar, A. K. (2019). Digital ecosystem: extending the

boundaries of value creation in insurance. Swiss Re Institute, January, 1–11.

https://www.swissre.com/dam/jcr:e1f92bbd-0557-487a-87c5-c2f94ac6b32a/SRI _

Expertise Publication _ Digital ecosystems_WEB.pdf

Azure Docs, M. (2019). ¿Qué es DevOps? 1.

https://azure.microsoft.com/es-mx/overview/what-is-devops/#devops-overview

Crane, M., & Lin, J. (2017). An exploration of serverless architectures for information

retrieval. ICTIR 2017 - Proceedings of the 2017 ACM SIGIR International Conference

on the Theory of Information Retrieval, 241–244.

https://doi.org/10.1145/3121050.3121086

de la Torre, C., Wagnwer, B., & Rousos, M. (2020). .NET Microservicies Architecture for

Containerized .NET Applications. Microsoft .NET 5 Support, 5, 350.

Delgado Pedraza, L., & Pineda Parra, O. D. (2019). MODELO PARA LA ORQUESTACIÓN

DE MICROSERVICIOS CON KUBERNETES APLICADO AL SERVICIO DE

CONTROL DE VERSIONES GIT. Universidad Distrital Francisco José de Caldas.

ISO. (2021). ISO 21500: Project, programme and portfolio management — Context and

concepts Management. INTERNATIONAL STANDARD, 13.

Jacobides, M. G., Sundararajan, A., & Van Alstyne, M. W. (2019). Designing digital

ecosystems. Platforms and Ecosystems: Enabling the Digital Economy, February,

13–18. www.weforum.org

Kubernetes. (2020). ¿Qué es Kubernetes? Kubernetes Docs.

 105

https://kubernetes.io/es/docs/concepts/overview/what-is-kubernetes/

Larrosa, J. M. (2000). Enmiendas a la Ley de Metcalfe. Universidad Nacional Del Sur,

1–13.

http://jlarrosa.tripod.com/files/metcalfe.pdf%5Cnhttp://es.wikipedia.org/wiki/Ley_de_M

etcalfe

Lavann, EdPrice-MSFT, Alexbuckgit, Neilpeterson, Dsk-2015, DCtheGeek, David-stanford,

Adamboeglin, V-albemi, VeronicaWasson, & TheGitHubBro. (2021). Migrate a

monolith application to microservices using domain- driven design Apply

domain-driven design Start to retire the monolith. Microsoft Docs.

https://docs.microsoft.com/en-us/azure/architecture/microservices/migrate-monolith

Loaiza, M. I., Acosta, S., Andrade, P. S., & Salazar, A. del C. (2018). Proyecto Ascendere.

Gestionando un ecosistema de Formación e Innovación Docente en la Educación

Superior. 5o Congreso Internacional de Innovación Educativa - Ponencia de

Innovación Proyecto. http://library1.nida.ac.th/termpaper6/sd/2554/19755.pdf

Loaiza, M. I., Nuve, B. P., Salazar, A. D. C., & Colindres, D. I. (2020). PROYECTO

ASCENDERE. CREANDO UN ECOSISTEMA DE INNOVACIÓN DOCENTE. Premio

Interamericano MEIN En Educación Superior, 42–53.

http://library1.nida.ac.th/termpaper6/sd/2554/19755.pdf

Management Institute Project. (2017). A GUIDE TO THE PROJECT MANAGEMENT

BODY OF KNOWLEDGE.

Moreno Monsalve, N. A., Sánchez Ayala, L. M., & Velosa García, J. D. (2016). Introducción

a la gerencia de proyectos: conceptos y aplicación. In Introducción a la gerencia de

proyectos: conceptos y aplicación. https://doi.org/10.21158/9789587564501

Newman, D. (2016). That Creating A Digital Ecosystem That Benefits Your Business.

Forbes.
 106

https://www.forbes.com/sites/danielnewman/2016/12/20/creating-a-digital-ecosystem-t

hat-benefits-your-business/?sh=795ee3076f01

Nogués, J. (2018). Orquestación de contenedores con Kubernetes.

https://e-archivo.uc3m.es/handle/10016/29528

Peter, M., & Timothy, G. (2011). The NIST Definition of Cloud Computing. NIST, 7.

Red Hat. (2019). El camino a las aplicaciones nativas de la nube. 8 pasos para guiar su

camino. Redhat, 1(1), 12.

http://www.comoves.unam.mx/numeros/articulo/164/el-camino-a-las-percepciones

Red Hat. (2021). Introducción a la arquitectura de Kubernetes. Red Hat.

https://www.redhat.com/es/topics/containers/kubernetes-architecture

Richardson, C. (2019). Microservices Patterns. MANNING SHELTER ISLAND.

Russinovich, M. (2016). Microservices: An application revolution powered by the cloud.

Microsoft Docs.

https://azure.microsoft.com/en-us/blog/microservices-an-application-revolution-powere

d-by-the-cloud/

Salazar, A. D. C., Beltrán, A. M., & Loaiza, M. I. (2016). Proyecto Ascendere: Un

ecosistema de prácticas de Innovación Docente en la UTPL. July 2016.

https://doi.org/10.4995/inred2016.2016.4299

Skilton, M. (2016). Building Digital Ecosystem Architectures. In Building Digital Ecosystem

Architectures. https://doi.org/10.1057/9781137554123

Vettor, R., & Smith, S. (2021). Architecting Cloud-Native .NET Apps for Azure.

Wasson, M., & Narumoto, M. (2017). Cloud Application Architecture Guide. Microsoft

Press, 333. http://www.microsoft.com/en-us/download/details.aspx?id=16236

Zutshi, A., & Grilo, A. (2019). The Emergence of Digital Platforms: A Conceptual Platform

Architecture and impact on Industrial Engineering. Computers and Industrial

 107

Engineering, 136(July), 546–555. https://doi.org/10.1016/j.cie.2019.07.027

 108

Apéndice

Apéndice 1: Informe Técnico 1: DevOps.

Apéndice 2: Informe Técnico 2: Arquitectura de Plataforma.