Reingenieria y rediseno de interfaz y funcionalidad de la plataforma web ayudrg

Vista previa del material en texto

UNIVERSIDAD NACIONAL DEL CENTRO 
DE LA PROVINCIA DE BUENOS AIRES 
FACULTAD DE CIENCIAS EXACTAS 
TANDIL, ARGENTINA 15 de jul de 2022 
 
REINGENIERÍA Y REDISEÑO DE 
INTERFAZ Y FUNCIONALIDAD DE LA 
PLATAFORMA WEB AYUD@RG 
 
 
 
Darío Fernández Torre y Santiago Wagner 
 
Directora: María Rosa Dos Reis 
Co-Director: Alfredo Teyseyre 
 
 
 
1 
Agradecimientos 
A nuestras familias, amigos, compañeros y docentes que, con su apoyo 
incondicional a lo largo de todos estos años, transformaron la carrera en un 
cúmulo de gratas experiencias que nos acompañarán de por vida. 
No solo queremos dedicarles este trabajo, sino recalcar la importancia que 
ha tenido su soporte para el desarrollo y finalización del mismo y decir que 
definitivamente cada elemento el mismo refleja una parte de cada uno de ellos. 
Darío y Santiago. 
 
 
2 
Índice 
Capítulo 1: Reingeniería De La Plataforma Web AYUD@RG 10 
1.1. Motivación 12 
1.2. Objetivo 14 
1.3. Estructura, Alcance y Limitaciones 16 
1.4. Organización del Informe 18 
Capítulo 2: Presentación De La Herramienta AYUD@RG 20 
2.1. Sistemas de donación 20 
2.1.1. Contexto 20 
2.1.2. Vínculo de los autores con el proyecto 23 
2.2. Aproximación a la problemática 25 
2.2.1. Análisis previos 25 
2.2.2. Profundizando sobre las problemáticas 26 
2.2.3. Recapitulación 30 
Capítulo 3: Solución Propuesta 32 
3.1. Atributos de calidad 32 
3.2. Planteo de solución y Diseño de arquitectura 33 
3.2.1. Beneficios 35 
3.3. Metodología de desarrollo 37 
3.3.1. Contexto social 37 
3.3.2. Métodos ágiles 39 
3.3.2.1. Kanban 40 
3.3.2.2. Herramientas 41 
Capítulo 4: Desarrollo 48 
4.1 Primeros pasos 48 
4.1.1. Uso de frameworks 48 
4.2 Presentación 50 
4.2.1. Estudios complementarios 50 
4.2.2. Importancia del diseño de las vistas 53 
4.2.3. Diseño de interfaces 54 
4.2.3.1. Enfoque para la presentación de conjuntos de datos 56 
4.2.3.2. Evaluación 57 
4.2.4. Implementación 60 
 
3 
4.2.4.1. Creación de la aplicación 60 
4.2.4.2. Entorno de desarrollo y despliegue 61 
4.2.4.3. Vistas comunes 65 
4.2.4.4. Vistas específicas y roles de los actores 72 
4.2.4.5. Flujos de donación y voluntariado 77 
4.2.4.6. Angular PWA 88 
4.3 Aplicación y lógica del negocio 91 
4.3.1. Primeros pasos 92 
4.3.2. Entorno de desarrollo 93 
4.3.3. Implementación de la API Rest 94 
4.3.4. Deployment de la API Rest 95 
4.4 Persistencia y base de datos 95 
4.4.1 Análisis y modelado de datos 96 
4.4.2 Implementación de la estructura de datos 98 
Capítulo 5: Pruebas Y Resultados 101 
5.1. Pruebas internas 102 
5.2. Testing Scope 102 
5.3. Testing del backend 103 
5.3.1. Testing Manual 103 
5.3.2. Testing Automático 105 
5.4. Testing del frontend 106 
5.4.1. Testing Manual 107 
5.4.2. Testing Automático 107 
5.5. Resultados 109 
5.5.1. Resultados del Backend 109 
5.5.2. Resultados del Frontend 110 
Capítulo 6: Conclusiones 114 
6.1. Generales 114 
6.2. Evaluaciones Personales 116 
6.3. Futuro 117 
Referencias 119 
 
 
 
4 
Índice De Figuras 
 
Fig. 1. Interacción entre los elementos de una PWA. 15 
Fig. 2. Esquema elemental que representa la arquitectura de tres niveles 16 
Fig. 3. Modelo de Cuatro Pilares propuesto por Regattieri, Gamberi y Manzini 24 
Fig. 4. Resultados de la resolución del caso utilizando decisión multicriterio 26 
Fig. 5. La ayuda numérica opcional 29 
Fig. 6. Al intentar realizar una operación no permitida se muestra este mensaje 30 
Fig. 7. Arquitectura de tres niveles planteada 34 
Fig. 8. Vista parcial de los tableros utilizados 42 
Fig. 9. Vista general de los tableros creados en la herramienta Trello 43 
Fig. 10. Vista del canal creado en Slack. 44 
Fig. 11. Representación gráfica de los elementos del proceso de esquematización 52 
Fig. 12. Disposición y variantes de los logotipos presentados como parte del testing 52 
Fig. 13. Distribución gráfica de los resultados elegidos 53 
Fig. 14. Árbol de vistas de navegación de la interfaz creados en Adobe XD 56 
Fig. 15. Prototipos de la interfaz de usuario realizados en Adobe XD 58 
Fig. 16. Vista principal de los archivos disponibles del proyecto de Angular 63 
Fig. 17. Código .yml del workflow configurado 64 
Fig. 18. Acción de Github en ejecución que permite el continuous deployment 65 
Fig. 19. Diseño de vistas para inicio de sesión y registro. 66 
Fig. 20. Vistas de inicio de sesión y registro de nuevos usuarios 67 
Fig. 21. Diseño de la vista del menú principal realizado en la fase de maquetado 68 
Fig. 22. Vista de la página de inicio para todos los usuarios de la plataforma 69 
Fig. 23. La vista de preguntas frecuentes 70 
Fig. 24. Página de contacto 71 
Fig. 25. Página estática con información sobre la Asociación Civil. 71 
Fig. 26. Vista de la maqueta final para las vistas del perfil de usuario y de edición de 
datos personales 73 
Fig. 27. Capturas de la implementación en Angular 73 
Fig. 28. En esta vista, un encargado puede crear campañas de donación 74 
Fig. 29. La lista de instituciones administrada por el encargado 75 
Fig. 30. Esta vista se utiliza para el alta de instituciones 75 
Fig. 31. En esta vista se puede apreciar el listado de categorías 76 
 
5 
Fig. 32. Esta vista posee las estadísticas de uso de la plataforma 76 
Fig. 33. Esta vista muestra todas las campañas de ayuda listadas 77 
Fig. 34. Demandas que solicita la institución para la campaña actual. 78 
Fig. 35. El usuario no dispone de recursos que coincidan con la categoría de los 
demandados 78 
Fig. 36. Vista de gestión de recursos para los usuarios. 79 
Fig. 37. Formulario dinámico de carga de recursos. 79 
Fig. 38. Formulario de donación para una demanda determinada. 80 
Fig. 39. Pantalla de éxito mostrada al usuario que inicia una donación. 80 
Fig. 40. Vista de detalles (usuario) para la donación del flujo ejemplificado. 81 
Fig. 41. Panel de donaciones entrantes para la institución gestionada. 81 
Fig. 42. Vista de detalles (encargado) 82 
Fig. 43. Vista de detalles (usuario) para la donación, ahora con estado ACEPTADA 83 
Fig. 44. Vista de detalles (usuario) para la donación, ahora con estado COMPLETA 83 
Fig. 45. Formulario en modal para la calificación de transacciones. 84 
Fig. 46. Panel de recursos de la institución (vista del rol encargado). 84 
Fig. 47. En la vista de donaciones se listan las donaciones realizadas por el usuario 85 
Fig. 48. Vista de detalles de la campaña con voluntariado habilitado. 86 
Fig. 49. Formulario en modal para la postulación a un voluntariado. 86 
Fig. 50. Se presentan los voluntariados en los que participa el usuario 87 
Fig. 51. Vista de detalles del voluntariado (encargado). 87 
Fig. 52. Formulario en modal para la carga de un registro del voluntariado. 88 
Fig. 53. Evolución del voluntariado plasmado en los registros de la vista de detalles. 88 
Fig. 54. Vista de Aplicación en el navegador Google Chrome. 91 
Fig. 55. Herramienta Web Spring Initializr 93 
Fig. 56. Flujo de control y datos de la aplicación. 94 
Fig. 57. Dashboard de Heroku correspondiente al deployment 95 
Fig. 58. Diagrama de clase correspondiente al modelo de la API REST anterior 96 
Fig. 59. Diagrama de clase correspondiente al modelo de la API REST actual 98 
Fig. 61. Tabla en MySQL resultante del mapeo del POJO de la Fig. 55. 99 
Fig. 62. Vista de la herramienta MySQL Workbench. 100 
Fig. 63. Respuesta obtenida tras una autenticación exitosa usando Postman. 104 
Fig. 64. Respuesta obtenida tras la creación de un recurso 105 
Fig. 65. Ejecución de los test de una de las colecciones de endpoints en Postman. 106 
Fig. 66. Secuencia de pasos ejecutados para la prueba de inicio de sesión 108 
 
6 
Fig. 67. Resultado de la herramienta Lighthouse de Google 111 
Fig. 68. Motivos del puntaje en relación a la optimización para motores de búsqueda. 111 
Fig. 69. Tiempos medidos utilizando Performance Insights. 113 
Fig. 70. Puntajes de Lighthouse para Mercadolibre y Facebookrespectivamente. 113 
 
 
 
7 
Índice De Tablas 
Tabla 1. Lista de requerimientos funcionales principales 97 
Tabla 2. Resultado general obtenido a partir de los casos de testing manuales. 109 
Tabla 3. Desglose de la severidad de los casos que no fueron exitosos durante el test 
manual. 109 
Tabla 4. Resultado general obtenido a partir de los casos de testing automático a partir 
de Postman. 110 
Tabla 5. Desglose de la severidad de los casos no exitosos detectados durante el testing 
automático. 110 
 
 
 
8 
Resumen 
En conjunto con la Asociación Civil Proyecto Koinonía, se realizó un 
proceso de revalorización de la herramienta solidaria llamada AYUD@RG, la cual 
consiste en una solución integral para las instituciones que vinculan la oferta y 
demanda de productos y servicios en el marco de proyectos organizacionales 
solidarios que involucren el proceso de donación. 
La herramienta fue desarrollada íntegramente por alumnos y docentes de 
la carrera Ingeniería de Sistemas con el aval institucional de la Facultad de 
Ciencias Exactas de la UNICEN a lo largo de su ciclo de vida, por lo que este aporte 
significativo continúa con el legado del desarrollo histórico gracias a la 
incorporación de tecnologías, mediante la puesta en marcha de un proceso basado 
en el planteo e instanciación de una nueva arquitectura. 
En particular se realizó un rediseño absoluto de su interfaz y el código que 
se ejecuta en el servidor para dar soporte a la funcionalidad presentada; utilizando 
Angular y Spring Boot respectivamente como pilares de la arquitectura, se 
garantizaron la viabilidad y el soporte a largo plazo del sistema mediante la 
utilización de tecnología de punta y ampliamente difundida en el mercado actual. 
 
 
 
 
9 
Acrónimos 
● API: Application Programming Interface 
● E2E: End to End. 
● FAQ: Frequently Asked Question 
● FCP: First Contentful Paint 
● OOP: Object Oriented Programming 
● ORM: Object Relational Mapping 
● PWA: Progressive Web App 
● REST: Representational State Transfer 
● SDP: Software Development Plan 
● SOC: Separation Of Concerns 
● ST: Sistema de Trazabilidad. 
● TICs: Tecnologías de la Información y la Comunicación 
● UX: User Experience 
● VCS: Version Control System 
● YAML: YAML Ain't Markup Language 
 
10 
Capítulo 1: Reingeniería De La 
Plataforma Web AYUD@RG 
Al observar por un instante a cualquier grupo de individuos en la sociedad 
actual, en la mayoría de los ámbitos posibles podrá notarse un rasgo distintivo: el 
contacto permanente con las tecnologías de la información, y en particular con sus 
dispositivos móviles personales, entre los cuales se encuentran los teléfonos 
celulares y tablets, que han mutado en computadoras de bolsillo con innumerables 
avances y campos de aplicación. Su uso ha aumentado de forma tal que, en 
términos temporales, el mismo representa el doble en relación al que los usuarios 
pasan en computadoras de escritorio, e incluso en múltiples países se trata de los 
únicos dispositivos a través de los cuales acceden a Internet (Google et al., s.f.). 
Este factor de absoluta cotidianeidad con respecto a la utilización de los 
apodados teléfonos inteligentes (por su traducción del inglés smartphone) está 
ligado al sinfín de aplicaciones móviles nativas y sitios web optimizados para su 
visualización en pantallas de formato reducido que el mercado tiene para ofrecer, 
transformándose estos últimos en herramientas fundamentales en la vida de los 
usuarios. Esto provoca en consecuencia que organizaciones de todo tipo decidan 
desarrollar aplicaciones para dispositivos móviles con el fin de adecuarse a esta 
tendencia e interactuar con su audiencia objetivo, y así finalmente reforzar el 
vínculo con la misma con el objetivo de alcanzar sus metas organizacionales de 
manera simple y elegante (Wetzler, 2020). 
Sin embargo, a pesar de que el desarrollo de aplicaciones nativas puede 
haber parecido una buena solución al masificarse su producción y facilitarse la 
distribución a través de las tiendas de aplicaciones que cada fabricante propone, 
los datos muestran que la popularidad de este camino se encuentra en declive 
debido a que lograr convencer al público de que instalen y utilicen aplicaciones 
nuevas que se encuentran a la deriva en el congestionado océano rojo (término 
propuesto por Chan Kim y Renée Mauborgne en 2004) de los portales de 
distribución, implica atravesar con detenimiento un engorroso proceso cuyo éxito 
 
11 
se reserva generalmente (debido a múltiples factores) a las aplicaciones más 
populares del momento (Ater, 2017, pp. 17-18). 
En este contexto surge el concepto de Aplicaciones Web Progresivas, 
abreviadas PWA por sus siglas del inglés Progressive Web Apps. Las mismas 
pueden definirse como una extensión de las aplicaciones web tradicionales, es 
decir, software que se ejecuta en el navegador. Estas podrían ubicarse en la 
intersección de los universos de las aplicaciones móviles nativas y los sistemas 
tradicionales con interfaces ofrecidos a través de sitios web. Las PWA extienden 
la noción de estos últimos ofreciendo ciertas características discernibles tales 
como: disponibilidad independiente de la conexión, tiempos de carga rápidos, 
notificaciones push, acceso desde la pantalla de inicio, y aspecto de aplicación 
nativa; todo esto haciendo énfasis en proveer una funcionalidad multiplataforma 
sencilla y transparente al usuario (Ater, 2017, pp. 19-20). 
Por otro lado, es prudente mencionar que no todos los nichos dentro del 
mundo de las aplicaciones se encuentran saturados o monopolizados (y como 
apreciación personal de los autores, probablemente la sociedad aún se encuentre 
lejos de ese punto), siendo uno de estos y de particular interés debido a su 
vinculación con el presente trabajo, el de las aplicaciones de carácter solidario. En 
este contexto se ubica la herramienta AYUD@RG1 perteneciente a la asociación 
civil Proyecto Koinonia, cuyo propósito es el de actuar como nexo informatizado 
coordinador y vinculante en campañas y redes de asistencia solidarias mediante 
tecnologías web (Armentano et. al. 2019). Dentro de esta plataforma, múltiples 
organizaciones participan con la posibilidad de armar sus propios proyectos de 
ayuda social y personalizar la demanda de recursos, mientras que por otro lado 
los usuarios interesados colaboran mediante donaciones de los elementos 
solicitados, los cuales pueden pertenecer a los conjuntos de productos o servicios. 
Resulta claro entonces que la evolución de las tendencias y tecnologías en 
el campo de las aplicaciones web posee un dinamismo significativo. Esto genera 
como inevitable consecuencia la necesidad de mantener el ritmo de actualización 
de los sistemas mediante iteraciones recurrentes para no quedar fuera del radar 
 
1 https://www.proyectokoinonia.org.ar/ayudarg/ 
 
12 
de los usuarios. He aquí donde el tiempo desde que fue concebida la aplicación 
inicialmente comienza a notarse al surgir problemas específicos e identificarse 
limitaciones que complican el uso diario de la plataforma, y por ende, reducen su 
atractivo (sobre todo para el público que aún no ha tenido contacto con la misma). 
De esta forma, considerando esta problemática, los autores detallan de 
manera clara en este informe el proceso necesario para lograr crear una 
arquitectura más adecuada a través de la reingeniería del sistema, con el objetivo 
de dar soporte a la herramienta mencionada a lo largo del tiempo y sin grandes 
complicaciones a la hora de extender su funcionalidad; utilizando algunos 
principios del diseño de interacción centrado en los usuarios, una metodologías 
de desarrollo ágil y tecnologías estándares en la industria. 
1.1. Motivación 
 Extendiendo un poco la dinámica socio - tecnológica introducida 
anteriormente, en la actualidad los usuarios se han habituado a las experiencias 
de aplicaciones ofrecidaspor los líderes de su respectivo segmento de mercado. 
Estos sistemas de gran complejidad pueden identificarse fácilmente porque 
presentan como características clave altos grados de optimización con respecto a 
su funcionalidad y tiempos de respuesta, así como también un nivel de usabilidad 
elevado. Los ejemplos habituales son las redes sociales como Facebook2 y Twitter3 
y plataformas de comercio electrónico entre las cuales destacan Mercadolibre4 y 
Amazon5; su existencia y éxito se debe probablemente a factores irrepetibles, pero 
los autores consideran que el diseño de soluciones que se asemejen a la 
experiencia ofrecida por estos referentes es una inteligente forma de aprovechar 
sus años de trayectoria e investigación, que sin duda logran reducir la curva de 
aprendizaje requerida para utilizar herramientas que presenten vistas 
equivalentes y familiares para los usuarios. 
 
2 https://www.facebook.com/ 
3 https://www.twitter.com/ 
4 https://www.mercadolibre.com/ 
5 https://www.amazon.com/ 
 
13 
Al relevar los elementos del sistema AYUD@RG que constituyen el 
conjunto de preocupaciones fundamentales de la disciplina interacción humano-
computadora (Hewett et. al., 1992) a ser considerados, se identifican aquellos 
causantes de ir en detrimento de los intereses del proyecto y consecuentemente 
de los actores involucrados. Mediante un proceso de revisión producto de 
reuniones con los responsables de la plataforma e internalización de algunos 
elementos presentados en Análisis Y Propuesta De Mejoras En La Usabilidad Del 
Sitio Web Ayud@rg (Barreiro, s.f.) se arribó a la conclusión de que existen 
múltiples problemáticas que dificultan de sobremanera la usabilidad general de la 
plataforma, y sobre todo para aquellos usuarios no bien versados en las 
capacidades técnicas requeridas para operarla. Las mismas son de vital 
importancia en el proceso de reformulación de los elementos clave del sistema. 
A su vez y por fuera de los elementos propios de la usabilidad, durante esta 
captura se plantean los elementos funcionales faltantes identificados por parte de 
los administradores a lo largo de los años en los que se utilizó la herramienta. Los 
mismos suponen un desafío en sí mismos debido al componente de 
heterogeneidad tecnológica y de enfoques de diseño utilizados para el desarrollo 
de sus diferentes componentes sobre los cuales se ahondará en el próximo 
capítulo. Y por otro lado se menciona como cambio fundamental la necesidad de 
lograr la adaptación de la plataforma a dispositivos móviles. 
La incorporación de este conglomerado de cambios representa un desafío 
de elevada complejidad, dado que la herramienta en sí no fue construida con la 
mayoría de estos puntos dentro de su umbral de planificación. Entonces, visto y 
considerando que se trata de un proyecto solidario activo y con origen puntual en 
la Facultad de Ciencias Exactas de la UNICEN, se hace evidente la posibilidad de 
replantear el desarrollo de la plataforma por completo con el fin de realizar un 
aporte de magnitud que revalorice el esfuerzo de los estudiantes y docentes 
involucrados en este proyecto a lo largo de los años, y a su vez garantice a la 
comunidad el acceso a una herramienta atractiva que potencie el impacto social 
generado hasta ahora. 
 
14 
1.2. Objetivo 
El objetivo principal de este trabajo final consiste en llevar a cabo un 
completo proceso de reingeniería y rediseño de la plataforma AYUD@RG, que 
posibilite en particular reafirmar las cuestiones elementales analizadas 
anteriormente como parte de su motivación. 
Ahora bien, la tarea principal implica en simultáneo, objetivos secundarios 
a ser resueltos mediante la incorporación de nuevas tecnologías y gracias a la 
utilización de herramientas de trabajo vinculadas al desarrollo web. Uno de ellos 
es el poder brindar un aumento drástico de la usabilidad a través del replanteo de 
las interfaces gráficas mediante la utilización de técnicas de Diseño de UX6. En 
paralelo y siguiendo con los últimos estándares de extensibilidad, se busca 
también permitir la incorporación de nuevas funcionalidades que aporten valor al 
uso cotidiano de la plataforma y garantizar la facilidad de poder modificarlas y 
mantenerlas en el tiempo. Y, por último, es deseable en simultáneo extender el 
alcance de la plataforma con el fin de lograr que el mismo sistema se adapte tanto 
a dispositivos de escritorio como móviles de manera dinámica y de forma 
transparente al usuario. 
La necesidad de llevar adelante el proceso mencionado deriva 
eventualmente en el desarrollo de un sistema que extiende enormemente sus 
capacidades previas a través de la implementación de una Aplicación Web 
Progresiva (de ahora en adelante PWA) dadas las virtudes mencionadas 
brevemente en el cuarto párrafo de esta introducción y cuyo comportamiento en 
relación al manejo de solicitudes y cómo sería la estructura de la misma una vez 
instanciada puede visualizarse en el esquema de la Fig. 1. 
 
 
 
 
6 El diseño de UX hace referencia al conjunto de aspectos de la interacción entre el usuario con 
todos los elementos del sistema organizacional. 
 
15 
 
Fig. 1. Interacción entre los elementos de una PWA. Un Service Worker se ejecuta en el 
navegador junto con la aplicación y se encarga de mostrar elementos cacheados y 
realizar las peticiones correspondientes a la red. 
Su resolución se propulsa a partir del planteo de la utilización de una 
arquitectura de tres niveles (IBM, s.f.), siendo éstos: Presentación, 
Aplicación/Lógica y Datos como puede verse en la Fig. 2. El primer nivel 
mencionado es el encargado de dar soporte a la PWA, por lo que la elección de un 
framework que facilite la construcción de aplicaciones web interactivas de manera 
estructurada es determinante. Este nivel se comunica directamente con el inferior 
a través de una API7, es decir “el conjunto de definiciones y protocolos que son 
necesarios para la construcción e integración del software de la aplicación” 
(RedHat, s.f.), la cual se implementa utilizando el estilo arquitectónico REST8 
(Fielding, 2000), e interactúa con un repositorio ubicado en el último nivel con el 
objetivo de brindar almacenamiento persistente. 
 
 
7 Interfaz de programación de aplicaciones, por su sigla del inglés, application programming 
interface. 
8 Transferencia de estado representacional, del inglés representational state transfer, hace 
referencia a un estilo de arquitectura de software. 
 
16 
 
Fig. 2. Esquema elemental que representa la arquitectura de tres niveles planteada para 
dar soporte al nuevo sistema y la interacción entre las correspondientes capas. 
1.3. Estructura, Alcance y Limitaciones 
 Resulta claro que más allá del conjunto de objetivos introducidos, y de las 
implicaciones de un proceso de reingeniería como el que se decide llevar a cabo, 
el mismo debe acotarse en algunos puntos concretos. De esta forma y repasando 
lo expuesto como objetivo, el proyecto final se enfoca principalmente en llevar 
adelante la realización de dos grandes grupos de tareas puntuales. Por un lado, se 
prioriza preservar la mecánica de uso de la plataforma enfocándose en revisar los 
procesos funcionales básicos, pero dejando planteada una arquitectura extensible 
que permita adicionar funcionalidades no contempladas sin grandes 
complicaciones. Y por otro lado también se busca mejorar significativamente su 
usabilidad mediante técnicas de diseño que permiten abordar las problemáticas 
previamente identificadas a posteriori por los actores responsables de su gestión. 
 En primera instancia, el desarrollo de este nuevo sistema contempla la 
mayor parte de las conocidas etapas del ciclo de desarrollo de software9: la 
planificación del mismo, la captura de requerimientos, e iteraciones dedicadas al 
diseño, instanciación y pruebas del mismo. Considerando esto resultará 
interesante explayarse sobre la metodología conel objetivo de recalcar que se 
plantea el desarrollo del sistema desde una perspectiva que posee gran influencia 
 
9 Ciclo de desarrollo de sistemas, de sus siglas en inglés por Systems Development Cycle. 
 
17 
ágil; y de esta forma se establece la realización de múltiples iteraciones en las 
cuales se ejecutan tareas heterogéneas en diferente grado con el fin de tener un 
producto funcional al final de cada una de ellas. 
Como puntapié del proyecto y en particular comenzando incluso tiempo 
antes de la etapa de desarrollo del presente trabajo final, se realizó un profundo 
análisis de la plataforma en su estado inicial como parte de la captura de 
requerimientos necesaria. Se especifica que este proceso comienza antes debido a 
los vínculos previos de los autores con los docentes encargados de la plataforma, 
tópico que será desarrollado puntualmente en el próximo capítulo. Como parte de 
este trabajo, nuevamente se realiza la identificación y especificación de los casos 
de uso que contemplarían la funcionalidad total de la plataforma, en pos de 
verificar las bases previas y extenderlas para cumplir con la funcionalidad 
esperada y acordada con los interesados del Proyecto Koinonía mediante la 
comunicación permanente. 
En relación al diseño se trata el relevamiento de tecnologías necesarias 
para lograr cubrir los requerimientos del software y materializar efectivamente la 
arquitectura planteada. Asimismo, y vinculado al concepto de mejora de la 
usabilidad definido como uno de los pilares el proyecto, se desprende la necesidad 
de reevaluar las debilidades presentes en la interfaz gráfica para rediseñar el 
frontend10 (Barreiro, s.f.), no solo orientando el desarrollo a mejorar la experiencia 
de los usuarios sino efectivamente centrándose en ellos al seleccionar las prácticas 
de diseño más apropiadas. Asimismo, es indispensable también determinar las 
estructuras de datos que permitan implementar las funcionalidades requeridas de 
manera eficiente, manteniendo un alto nivel de escalabilidad, extensibilidad, 
rendimiento e integridad de datos. 
Vinculado a la instanciación, el enfoque de los esfuerzos gira en torno al 
desarrollo del backend de la plataforma, siguiendo los principios del estilo 
 
10 Frontend y backend hacen referencia a la separación de intereses entre la capa de presentación 
y la de acceso a datos, respectivamente. 
 
18 
arquitectónico REST y de las correspondientes vistas vinculadas a la UI11 a ser 
mostrados en el frontend para interactuar con sus servicios. 
Y en relación a las pruebas a realizarse sobre el sistema puede decirse que 
las mismas se realizan como parte de cada iteración, conformando así “pruebas 
ágiles” que garanticen efectivamente la consistencia esperada de un producto 
funcional sobre la finalización de cada una. 
Habiendo planteado esto, es aquí donde ya puede delimitarse un horizonte 
de límites para este proyecto final en relación a su alcance dadas las etapas de 
desarrollo. Por un lado, las pruebas a realizar se demarcan en un entorno de 
recursos de hardware limitados pero suficientes para identificar las 
problemáticas que el uso cotidiano de la misma puede acarrear. Esto se debe en 
particular al estrecho vínculo que existe con la etapa de despliegue o deployment12 
posterior a la finalización del desarrollo de la nueva herramienta; puesto que si 
bien se instancia el sistema en el entorno mencionado (destinado y reservado a la 
ejecución de pruebas internas), la articulación en un ámbito de producción 
acarrearía sus respectivos seguimientos y conjuntos de pruebas que habrían de 
exceder el ámbito y propósito de este proyecto final. 
1.4. Organización del Informe 
Habiendo introducido propiamente los elementos que han de servir de guía 
para el lector al facilitar su grado de familiaridad con el proyecto de forma 
considerable, en esta sección se finaliza ese complemento dando una breve 
descripción de los contenidos a ser desarrollados a lo largo de cada uno de los 
capítulos subsiguientes. 
Ampliando la mayoría de los elementos introducidos en el presente 
capítulo, el Capítulo 2 hace especial énfasis en desarrollar las características 
históricas de la herramienta AYUD@RG, y la vinculación progresiva de los autores 
en el ecosistema de la misma mediante la investigación complementaria. También 
 
11 La interfaz de usuario o UI, por sus siglas del inglés User Interface, implica los medios a través 
de los cuales los usuarios se comunican con el sistema. 
12 Transferencia del producto desde el estado de desarrollo a un estado permanente. 
 
19 
se realiza una aproximación a la problemática mediante la definición y explicación 
de las ideas principales y sus ramificaciones, que surgen de la investigación 
realizada por los autores. 
Prosiguiendo con el Capítulo 3, se presenta al lector con la solución 
propuesta por los autores, referenciando a los elementos del proceso tenidos en 
cuenta para arribar a la misma y la justificación de por qué se considera que se 
trata de una buena propuesta evaluando el marco tecnológico actual y sus 
posibilidades. A modo de preámbulo de la instanciación del sistema de esta 
solución, también se desarrolla la elección de la metodología de desarrollo en 
cuestión, la relevancia del contexto mundial y sus implicaciones, y las 
herramientas necesarias para lograr llevarla a cabo de la manera más fluida y 
coordinada posible. 
Luego en el Capítulo 4 se desarrolla la implementación, producto de la 
utilización de la metodología descrita en el inmediato anterior, desglosando su 
composición en los dos grandes grupos que conforman el frontend y el backend de 
la plataforma. Para dar soporte a estos mismos se introducen a las tecnologías y 
herramientas utilizadas a lo largo del capítulo y la justificación de su elección 
frente a las posibles alternativas investigadas. 
Acercándose al final del trabajo, el Capítulo 5 presenta al lector con las 
pruebas realizadas, dificultades y errores encontrados al realizar las mismas junto 
con las acciones correctivas ejecutadas, y los resultados a los que se arribó con 
respecto al proceder durante esta etapa. 
Para dar cierre al informe se encuentra el Capítulo 6. En este se muestran 
las conclusiones finales que pudieron extraerse del análisis global del trabajo y 
que surgieron a partir de la experiencia obtenida de este proceso. También se 
realizan evaluaciones personales de los autores, y se brindan una lista de posibles 
mejoras sugeridas para incorporar al sistema en el futuro, un breve desarrollo de 
las mismas. 
Por último, se presenta la sección de Referencias que brinda la bibliografía 
de textos y publicaciones utilizadas en la confección del trabajo. 
 
20 
Capítulo 2: Presentación De La 
Herramienta AYUD@RG 
El presente capítulo se muestra al lector con el objetivo de introducirlo en 
materia del rol que cumple la herramienta sobre la cual se centra el trabajo a nivel 
social, y sobre el estado de la misma; entendiéndose y aplicándose esto tanto a una 
escala global en relación a tecnologías y el contexto, como así también desde un 
punto de vista local deteniéndose en los elementos circundantes a la plataforma. 
Para esto se realiza en primera instancia una descripción sobre los 
sistemas de donación y su grado de informatización en la actualidad, describiendo 
apropiadamente los conceptos necesarios en relación a estos para facilitar su 
comprensión. Mediante este enfoque se va desde lo general hacia lo particular 
prosiguiendo con el vínculo de los autores con la herramienta. 
De esta forma se facilita consecuentemente la comprensión de las 
problemáticas que se desean resolver y que desencadenan la decisión de realizar 
un proceso de reingeniería sobre la herramienta completa, el cual se profundiza 
en los capítulos restantes del informe. 
2.1. Sistemas de donación 
2.1.1. Contexto 
El concepto de donación, al que se hará referenciade ahora en adelante, 
implica un aporte particular cedido con el objetivo de dar impulso a iniciativas de 
cualquier tipo. Estos usuarios que dan origen al proceso saben de la relevancia y 
el impacto que este produce lo cual contribuye a la motivación original del mismo. 
Entre las razones primordiales que propician la realización de donaciones se 
encuentran el compromiso social de los individuos y la satisfacción personal. En 
el primer caso se reconoce la existencia de una problemática o carencia 
determinada del entorno que requiere una solución, y en el segundo resulta clave 
comprender que la garantía de estar ayudando a solucionar un problema 
 
21 
vinculado al ambiente en el que coexisten los individuos aporta sin lugar a dudas 
un gran regocijo al usuario donante (Blog de ACNUR, 2017). 
En relación a esto, y ampliando con respecto a su impacto, podría decirse 
que en los tiempos que corren las donaciones están posicionadas a nivel mundial 
como uno de los tipos de acciones humanitarias que ganan más adeptos día a día. 
Considerando su comprobada efectividad en materia de resolución de 
problemáticas sociales se infiere que la solidaridad, el altruismo y la empatía son 
valores vigentes y necesarios para el correcto desenvolvimiento de cualquier 
proceso de donación. 
El público en general realiza aportes benéficos en función de los recursos 
solicitados por las organizaciones (o simplemente porque están disponibles y se 
reconoce que existe una demanda permanente de los mismos), y en paralelo 
impulsados por su motivación (recordando la importancia de estos dado que la 
oferta es siempre insuficiente para satisfacer la demanda). Por otro lado, las 
donaciones organizacionales e individuales son un componente crítico de muchos 
proyectos, especialmente si los recursos que se les asignan o las contribuciones 
institucionales son insuficientes para cubrir las necesidades que los han motivado. 
Ahora bien, el dinamismo de los procesos de este estilo, en general no se 
encuentra soportado por sistemas circundantes en su gran mayoría con el fin de 
potenciar su alcance. De esta forma y como otro factor motivante entonces, surge 
la necesidad de plantear sistemas informáticos que permitan mejorar estas 
interacciones. Es por esto que las plataformas de donación en línea, aunque son 
un fenómeno reciente, se están volviendo más importantes para las 
organizaciones sin fines de lucro, lo que les permite llegar a una población objetivo 
más amplia de donantes a un costo relativamente bajo. Usar plataformas en línea 
para generar donaciones del público (a nivel local, nacional, e internacionalmente) 
se está convirtiendo en una forma popular y relativamente económica para 
muchas ONG para lograr sus objetivos organizacionales (Shier, 2012). 
Redondeando las ideas, básicamente todos los proyectos sociales tienen 
una cosa en común: requieren recursos específicos para implementarse de 
manera efectiva, lo que significa que la asignación y gestión adecuada de estos es 
 
22 
fundamental para que tengan éxito y alcancen sus objetivos; pero en simultáneo 
requerirían de sistemas eficientes y eficaces que den soporte a esta transferencia 
para lograr cumplir con sus objetivos fundacionales. 
En relación a estos sistemas se encuentra como un actor local fundamental 
la Asociación Civil Proyecto Koinonía. Ésta nace con el objetivo de facilitar la 
puesta en marcha de herramientas tecnológicas al servicio de la sociedad, 
permitiendo al tercer sector, formado por organizaciones no gubernamentales 
(ONG), conectar con otros sectores sociales en pos del bien mayor. Se posiciona en 
particular como una organización sin fines de lucro que promueve y brinda un 
conjunto de servicios a varios sectores de la sociedad (incluyendo individuos, 
estados, empresas y organizaciones no gubernamentales) basados en la 
implementación, configuración, aplicación, y uso de las tecnologías de la 
información y la comunicación (TICs), entre ellas, y sobre las cuales se trabajó en 
este proyecto específicamente, se encuentra la herramienta AYUD@RG. 
La herramienta en sí se presenta como una solución integral para trabajar 
en redes sociales de instituciones que conectan la oferta y la demanda de recursos 
(productos y/o servicios). De esta forma, el sistema constituye el puente entre las 
necesidades de la comunidad plasmadas a través de proyectos en las instituciones 
con vocación social y la ayuda brindada por la sociedad en general, la cual puede 
dirigirse hacia una campaña particular o simplemente ofrecerse a través del 
mismo sistema (Proyecto Koinonía, s.f.). 
Esta herramienta fue creada y mejorada íntegramente por estudiantes y 
profesores de la Facultad de Ciencias Exactas de la Universidad Nacional del 
Centro de la Provincia de Buenos Aires (UNICEN) y por supuesto ha contado a lo 
largo de su trayectoria con la ayuda de los miembros del propio Proyecto 
Koinonía. AYUD@RG apoya la toma de decisiones y permite una mejor gestión en 
red donde las organizaciones que forman parte del sistema arman sus propios 
proyectos de asistencia social y personalizan la demanda de recursos. La 
herramienta posibilita a través de la gestión del conocimiento de la red, 
administrar y asignar los recursos sociales de una manera más eficiente, colaborar 
 
23 
en la administración de proyectos y construir el conocimiento interorganizacional 
(Benito et. al, 2012). 
Por otro lado, debe tenerse en cuenta que, los servicios desarrollados por 
Proyecto Koinonía son expuestos a distintos niveles y experiencias en las ONGs 
que los utilizan, con realidades que presentan características comunes: atienden 
necesidades sociales y la demanda de recursos suele ser superior a la oferta 
(Illescas et. al., 2020). Debido a esto, resulta fundamental tener tantas métricas 
como sea posible para todos los elementos en el flujo de la realización de 
donaciones para ayudar en la mejora continua de los procesos solidarios, cuyas 
expectativas o necesidades no son idénticas para todas las instituciones. 
2.1.2. Vínculo de los autores con el proyecto 
Si bien la plataforma AYUD@RG comenzó a operar desde hace algunos 
años, se trata de un concepto establecido en la ciudad de Tandil de forma 
relativamente reciente, para el cual la cantidad de campañas comenzó a aumentar 
gradualmente en los últimos tiempos. Este crecimiento genera indefectiblemente 
la aparición de nuevas problemáticas a tratar, y dentro de este conjunto se 
identificó con anterioridad al presente trabajo la necesidad de implementar un 
Sistema de Trazabilidad13 de recursos efectivo; cuya motivación se originó debido 
a la determinación de que el historial de los recursos involucrados posee 
información valiosa para extender la visión general del uso de la plataforma 
AYUD@RG, tanto a nivel de funcionalidad como de flexibilidad para incorporar 
nuevas herramientas en el futuro. 
Los autores se involucraron con la plataforma AYUD@RG mediante la 
implementación del mencionado Sistema de Trazabilidad en el marco de la 
presentación del Trabajo Final de la cátedra Investigación Operativa. El mismo se 
creó para mantener la información relacionada al historial de donaciones de un 
recurso a lo largo de su vida en la plataforma. Dicha funcionalidad dejó sentadas 
las bases, en relación a la generación de datos, que permitirían obtener informes 
y métricas relacionadas al camino de los recursos que han sido ofrecidos y/o 
 
13 Sistema estructurado de tal forma que permite la reconstrucción total o parcial del ciclo de vida 
de un conjunto determinado de productos físicos (Bendaoud et. al., 2012). 
 
24 
donados en el futuro, y con respecto al impacto inmediato, poder mantener un 
seguimiento más detallado del estado de los mismos. 
El diseño de la API Rest utilizado en este trabajo preliminar serviría de base 
y puntapié para el nuevo sistema de la herramienta AYUD@RG. En casode desear 
profundizar más sobre el mismo, los detalles generales del desarrollo se 
encuentran publicados en los Anales del Congreso XXXIII ENDIO - XXXI EPIO 
VIRTUAL 2021. En este, los autores decidieron utilizar los cuatro pilares del 
framework de Sistemas de Trazabilidad propuesto por Gamberi, Manzini y 
Regattieri (2007) representados en la Figura 3, a modo de guía para el diseño. Para 
finalizar de dar soporte al ST se incorporaron endpoints específicos en la API 
diseñada a modo de herramientas de trazabilidad para recuperar información 
sobre los recursos y se planteó la utilización de códigos QR asociados al ID de cada 
recurso. 
 
Fig. 3. Modelo de Cuatro Pilares propuesto por Regattieri, Gamberi y Manzini (2007) 
aplicado a la trazabilidad de donaciones. 
En base a esto es prudente recalcar que “un ST permite no solo realizar un 
seguimiento tanto de los productos o servicios ofrecidos en las donaciones, sino 
también de las actividades involucradas en el proceso. (...) De esta forma se logra 
la trazabilidad efectiva en el sistema para la cadena de donaciones siempre que se 
respete el funcionamiento y la utilización de las herramientas disponibles por 
completo por parte de los actores responsables de interactuar con el ST. Siendo 
así, será de vital importancia procurar la correcta utilización por parte de los 
usuarios del ecosistema digital” (Fernández Torre y Wagner, 2021). Por lo que el 
 
25 
proceso a llevar a cabo tendría en cuenta esta premisa fundamental a la hora de 
establecer sus requerimientos y atributos de calidad asociados. 
2.2. Aproximación a la problemática 
Como se introdujo previamente en la sección de Motivación del Capítulo 1, 
debido al estado de la plataforma y la forma en la que fue concebida y perpetuada 
históricamente mediante diferentes aportes mixtos, se planteó la necesidad de 
llevar a cabo un completo proceso de reingeniería. Será conveniente entonces, 
comenzar a indagar más específicamente el estado que posee el sistema y los 
problemas que presenta con el fin de reforzar los conceptos que fomentan la 
realización de este proyecto. 
2.2.1. Análisis previos 
Los autores desde un primer momento comenzaron a familiarizarse con las 
problemáticas desde un rol de usuarios en la primera toma de contacto. Luego, y 
como se explicó anteriormente, prosiguieron interiorizándose desde los roles de 
desarrolladores internos al plantear el proceso que establecía el marco de trabajo, 
los métodos y el código y herramientas de software necesarias para implementar 
un sistema de trazabilidad. 
Al presentarse la oportunidad de perpetuar el trabajo previo en un nuevo 
sistema mediante el rediseño de la arquitectura del sistema, se procede 
necesariamente con análisis más profundos como parte de la planificación dentro 
del ciclo de vida del desarrollo. De este proceso en el que se tuvo la oportunidad 
de tomar contacto con múltiples materiales bibliográficos, en particular resulta 
del interés de los autores la publicación “Organización De Las Prioridades De La 
Herramienta AYUD@RG Por Medio De AHP” (Dos Reis et. al. 2018) en la cual se 
establece y detalla un orden de prioridades en línea con los fines institucionales y 
acorde a criterios preseleccionados de un conjunto de requerimientos (Fig. 4), 
cuyos juicios son orientados a lograr un crecimiento con el objetivo de que la 
herramienta AYUD@RG pueda crecer y funcionar de manera correcta al dar 
servicio al mayor número de ONGs posibles. 
 
26 
 
Fig. 4. Resultados de la resolución del caso utilizando decisión multicriterio para un 
conjunto de requerimientos propuestos para la plataforma. 
El mencionado trabajo concluye que la flexibilización de la herramienta, 
entendiendo esto como el aprovechamiento de las facilidades provistas por las 
diferentes redes sociales y un incremento del grado de amigabilidad de la 
plataforma para con los usuarios, son la prioridad máxima. Efectivamente resulta 
de vital importancia entonces considerar que la misma debería ser lo más intuitiva 
posible, objetivos que podrían lograrse mediante la simplificación de su uso y la 
ampliación del conjunto de usuarios que podrían llegar a utilizarla sin demasiadas 
dificultades. 
2.2.2. Profundizando sobre las problemáticas 
Los problemas que posee la versión actual de la plataforma (v1.8 ß) se 
deben principalmente a su arquitectura de tipo monolítica. Esta se gestó como un 
producto de requisitos no demasiado claros en las primeras fases del desarrollo 
de la herramienta debido a la necesidad de adaptarse a los procesos propios de 
distintas instituciones. A esto también se sumó el acople de porciones de software 
desarrollado por múltiples equipos diferentes, que trabajaron de manera 
independiente del resto y con una falta de eje central de diseño que respetar. Dicha 
arquitectura en términos generales posee varias ventajas en lo que respecta a 
desarrollo y deployment si se aplica de manera planificada y en proyectos no tan 
 
27 
abarcativos, estando esta última característica lejos del caso de AYUD@RG debido 
a su naturaleza de herramienta integral. 
En su estado actual, la plataforma posee una gran barrera de entrada para 
los nuevos equipos de desarrollo, dado que dispone de conjuntos de código 
heterogéneos. Esto, sumado a la falta de documentación y la inexistencia de un eje 
arquitectónico en términos de patrones de diseño, es posible haya sido el 
resultado de un desarrollo guiado por las necesidades particulares de cada 
institución en su momento, lo que obligó a cambiar los requisitos de la plataforma 
a medida que se avanzaba en el desarrollo. A su vez, la implementación de nuevas 
funcionalidades se dificulta debido a esto e, incluyendo también entre las causas, 
la falta de modularidad de las funciones debido a la naturaleza tightly-coupled14 
del código de la plataforma en la actualidad. Es en estos casos (de aplicaciones tan 
abarcativas) en el que se hace presente la necesidad de aplicar el concepto de 
separation of concerns15, dividiendo la aplicación en módulos o secciones 
específicas, cada una con una responsabilidad bien definida (Mili, 2004). 
De esta forma resulta evidente que mediante el empeño puesto en 
complacer las particularidades de los procesos de donación propios de distintas 
instituciones, se perdió control progresivamente sobre el hilo conductor del 
desarrollo de la plataforma, limitando su escalabilidad y performance. Si bien para 
un número reducido de instituciones puede parecer una práctica atractiva, a 
medida que ese número aumenta, se vuelve imposible que la plataforma soporte 
todos y cada uno de los detalles que cada institución posee sobre sus procesos de 
operación diaria. En algún momento, previo al desarrollo y durante la fase de 
diseño, es necesario consensuar en un proceso de donación estándar, lo 
suficientemente potente y definido, que permita a la plataforma servir como 
herramienta para los procesos de donación de todas las instituciones, debiendo 
ellas adaptarse al proceso propuesto por la plataforma (que surge del 
 
14 Este término en inglés hace referencia al elevado grado de acoplamiento y dependencia entre 
las rutinas del sistema. 
15 Se refiere a un principio de diseño orientado a la separación de un sistema informático en 
diferentes secciones orientadas al tratamiento de diferentes conjuntos de información. 
 
28 
relevamiento de todos los procesos y mediante el establecimiento de un proceso 
estándar) y no viceversa. 
Asimismo, se presentan también problemáticas relativas al modelado de 
los datos que dieron origen a una base de datos no normalizada, la cual dificulta el 
desarrollo de funcionalidades relativas a la trazabilidad de las donaciones, 
nuevamente mencionando que quizás haya sido producto de un contexto poco 
claro al inicio del proceso de desarrollo y que el mismo fue mutando a medida que 
se añadían nuevos requerimientos sinanalizar el impacto que los mismos tendrían 
a la hora de ser implementados. 
Por otro lado, si bien con respecto a los problemas vinculados a la 
funcionalidad es sabido que la herramienta no dispone del Sistema de 
Trazabilidad integrado debido a que el mismo depende necesariamente del código 
desarrollado por los autores con anterioridad; también será prudente recapitular 
algunos de los elementos identificados por quienes escriben como problemas 
relacionados a la usabilidad en la versión 1.8 ß de la herramienta AYUD@RG. Entre 
los elementos prioritarios relacionados se incluyen: 
● Baja usabilidad debido a fallas de UI: Si bien no se pretende hacer un 
análisis detallado de todos los elementos que actúan en detrimento de la 
usabilidad, es fundamental mencionar este apartado. En Análisis Y 
Propuesta De Mejoras En La Usabilidad Del Sitio Web Ayud@rg (Barreiro, 
s.f.) se realizaron pruebas de usabilidad y se concluyó en términos 
generales que aún se requiere trabajo de adecuación de la interfaz si se 
desea que cualquier usuario pueda utilizar la plataforma. 
● Diseño no adaptable: De la mano con las fallas en la interfaz de usuario y 
también en perjuicio de la experiencia de usuario, se encontró una 
aplicación web que no adapta su interfaz a los múltiples tamaños de 
pantalla existentes. Considerando que más del 90% de los usuarios suele 
acceder a internet a través de dispositivos móviles (AIMC, 2021), el hecho 
de tener un sitio prácticamente inutilizable desde este tipo de dispositivos 
le resta un enorme valor a la plataforma. 
 
29 
● Flujo de donación complejo: Si bien existen elementos que intentan dar 
una pauta de cuál debería ser el proceso a seguir (como la ayuda numérica 
mostrada en la Figura 5), no queda del todo claro para los usuarios menos 
experimentados cuales son los pasos a seguir en caso de querer realizar un 
aporte de cualquier tipo. 
 
Fig. 5. La ayuda numérica opcional permite definir la secuencia de pasos a seguir para 
algunas de las secciones de la plataforma. Si bien es un enfoque interesante, se deben 
buscar prácticas menos invasivas para mejorar la experiencia. 
● Errores frecuentes: En ocasiones al utilizar la plataforma de manera 
normal se presentan errores a través de toasts16 que resultan por lo general 
poco amigables y confusos (ver ejemplo de la Figura 6), y que suelen 
tratarse con redirecciones más amigables hacia la acción que el usuario 
desea. Por otro lado, también se identifican errores de tipo lógico en la 
funcionalidad del sistema que van en detrimento de la experiencia de los 
usuarios poco experimentados con gran probabilidad de provocar 
lamentablemente que estos pierdan el interés. 
 
16 Pequeño mensaje contenido en un cuadro que desaparece por sí solo después de unos segundos. 
Es un reporte sencillo que informa al usuario de una situación específica y no le impide continuar 
utilizando la aplicación. 
 
30 
 
Fig. 6. Al intentar realizar una operación no permitida se muestra este mensaje, cuando 
en realidad el usuario no debería llegar a esa instancia en el uso normal. 
● Navegación confusa: Esto está estrechamente ligado a cuestiones de la 
planificación de la interfaz, y se debe a la presencia o ausencia de 
componentes específicos de la misma. Dos ejemplos claros y puntuales son 
los botones de llamado a la acción principal17 de la vista escondidos o 
inexistentes en las diferentes vistas; y la poca delimitación que existen 
entre los roles de los usuarios con respecto a la interfaz visible, es decir, un 
usuario puede ver páginas y componentes que no debería considerando su 
rol (por ejemplo, elementos pensados para administración que son visibles 
para usuarios comunes). 
Con esto en vista, la solución de los autores, qué será analizada en más 
profundidad en el capítulo siguiente, buscará atacar todos los mencionados 
problemas partiendo de un extenso análisis de la funcionalidad a implementar, 
definiendo un scope de desarrollo claro y partiendo de un modelado de datos que 
permita, de manera óptima y eficiente, llevar a cabo la construcción de la 
plataforma deseada y lograr que contenga el conjunto funcionalidades planteadas, 
mediante la implementación de código escalable y extensible. 
2.2.3. Recapitulación 
Considerando el enorme grado de heterogeneidad histórico de la 
plataforma AYUD@RG de Proyecto Koinonía, y reconociendo que los avances en 
el área de la informatización de la ayuda social alcanzados por la mencionada 
Asociación Civil en conjunto con los alumnos y docentes de la facultad son de un 
inmenso valor; se desea preservar mecánica, funcionalidad y practicidad del 
 
17 El diseño orientado al llamado a las acciones (CTA) suele utilizarse en aplicaciones comerciales, 
pero sus técnicas son efectivas cuando se desea crear software accesible. 
 
31 
sistema para lograr continuar con su operatoria de forma ininterrumpida y 
conseguir en paralelo homogeneizar la base de código. 
Teniendo en cuenta entonces, la existencia de un elevado nivel de 
complejidad en algunos de los procesos vigentes en la versión 1.8 ß, tanto desde 
el punto de vista del aporte histórico con respecto a su conformación y desarrollo 
y el procesamiento de datos que realizan, como así también desde el de los 
usuarios que interactuaban con el sistema a diario; el problema principal radica 
en lograr poder perpetuar la mayor parte de la funcionalidad posible realizando 
en paralelo un balance sobre los elementos que deben simplificarse y/o adecuarse 
al implementar la nueva arquitectura. Sumado a esto, debe recordarse que el 
trabajo preliminar sobre el Sistema de Trazabilidad no se encuentra integrado en 
la Versión 1.8 ß (última versión con arquitectura previa a la planteada en este 
trabajo), pero resulta indispensable contar con el mismo por los motivos 
expuestos y detallados en aquel trabajo preliminar. 
Por último, englobando los elementos que consolidan esta problemática, se 
encuentra la cuestión de la factibilidad del proyecto, es decir si el conjunto de 
tareas a proponer es viable de acuerdo al tiempo y los recursos de los cuales 
disponen los autores en relación al marco académico en el que se realiza este 
proyecto. Resulta ligeramente evidente concluir que, a pesar de que la factibilidad 
se encuentra dada en parte debido a la delimitación del alcance del proyecto 
establecida inicialmente, su existencia no deja de ser menos relevante debido a la 
imprevisibilidad inherente a las estimaciones y la naturaleza del contexto en el 
que finalmente se irá desarrollando el trabajo; siendo estas cuestiones abordadas 
en los capítulos siguientes con más detalle. 
 
32 
Capítulo 3: Solución Propuesta 
Incentivados por el conglomerado de motivos expuestos en relación al 
estado actual del sistema y con el propósito de preservar las mecánicas y nexos 
adyacentes y a su vez optimizarlos, se decide realizar un proceso de reingeniería 
sobre el sistema tal y como se introdujo previamente. Este proceso se caracteriza 
primordialmente por las decisiones de implementar una aplicación web 
totalmente renovada y crear un backend robusto y escalable. 
En particular en este capítulo se describe la solución propuesta por los 
autores haciendo énfasis en particular en su descripción arquitectónica en 
conjunto con sus beneficios para la cual se desarrollarán las bandas 
correspondientes a la misma en conjunto. Y por otro lado y de igual relevancia 
para la conformación de la solución, se plantea la metodología a utilizar en 
relación con el contexto en el que se desenvuelve el equipo de trabajo. 
3.1. Atributos de calidad 
Uno de los conceptos más importantes en materia de arquitectura de 
software, es el de atributo de calidad. En base a las necesidades del proyecto y a 
las problemáticas presentes en la solución actual, se definen una serie de atributos 
de calidad que sirven como eje primordial a la solución propuesta quebusca, 
desde la arquitectura de software, subsanar las limitaciones que impactan 
negativamente a la aplicación en su estado actual. Los atributos de calidad 
seleccionados a tener en cuenta son los siguientes: 
● Escalabilidad 
● Extensibilidad 
● Inclusión 
● Usabilidad 
● Modularidad 
● Rendimiento 
 
 
33 
3.2. Planteo de solución y Diseño de arquitectura 
La arquitectura de software representa el primer conjunto de decisiones 
de diseño del sistema. Estas primeras decisiones son las más difíciles de corregir 
y las más difíciles de cambiar más adelante en el proceso de desarrollo, y tienen 
los efectos de mayor alcance. Según Bass et. al. (2003), desde una perspectiva 
técnica existen fundamentalmente tres razones que contribuyen a la importancia 
de la arquitectura de software: 
● Comunicación entre las partes interesadas: La arquitectura de software 
representa una abstracción común de un sistema que la mayoría (sino 
todas) de las partes interesadas del sistema pueden usar como base para el 
entendimiento mutuo, la negociación, el consenso y la comunicación. 
● Primeras decisiones de diseño: La arquitectura de software manifiesta las 
decisiones de diseño más tempranas sobre un sistema, y estos enlaces 
tempranos tienen un peso significativo con respecto a su impacto 
individual en relación al desarrollo restante del sistema, su 
implementación y el mantenimiento durante su vida útil. También es el 
punto más temprano en el que se pueden analizar las decisiones de diseño 
que rigen el sistema que se va a construir. 
● Abstracción transferible de un sistema: La arquitectura de software 
constituye un modelo relativamente pequeño y comprensible de cómo se 
estructura un sistema y cómo funcionan juntos sus elementos, y este 
modelo es transferible entre sistemas. En particular, se puede aplicar a 
otros sistemas que exhiban atributos de calidad y requisitos funcionales 
similares y puede promover la reutilización a gran escala. 
 Tal y como se introdujo al inicio de este informe, durante la confección del 
plan de trabajo se planteó que el desarrollo de la solución sería resuelto utilizando 
una arquitectura de tres niveles: Presentación, Aplicación/Lógica y Datos (Fig. 7). 
La misma es simple de entender y utilizar, con una clara separación de intereses 
(SoC). Debido a esto último, la capacidad de realizar pruebas se simplifica 
logrando que cada capa sea testeable, mantenible y fácil de actualizar. 
 
34 
 
Fig. 7. Arquitectura de tres niveles planteada para dar soporte al nuevo sistema e 
interacción entre sus elementos. 
La principal ventaja de una arquitectura de tres niveles, es la 
independencia de los mismos, permitiendo su desarrollo, modificación y testing 
en paralelo, pudiendo, potencialmente, ser montados en infraestructuras también 
independientes. Como se verá luego, la sección 3.2.1 ahondará con más detalle 
sobre los beneficios que posee esta arquitectura, pero es necesario ahora describir 
cada una de estas bandas en relación a la solución a instanciar. 
Nivel de presentación 
El nivel de presentación (presentation tier) se compone de la interfaz de 
usuario y lo relacionado a la interacción del mismo con la aplicación. La aplicación 
web a desarrollar en el framework Angular como parte del presente trabajo, 
representa a este nivel. 
Nivel de Aplicación 
El nivel de aplicación (application tier) posee la lógica del negocio y es el 
corazón de la aplicación. Cuenta con el conjunto de reglas del negocio y es el 
encargado de procesar la información provista por el nivel de presentación, 
pudiendo comunicarse también, con el nivel de persistencia de datos. La API Rest 
 
35 
a desarrollar en el framework Spring Boot cumple el rol de nivel de aplicación en 
la arquitectura de 3 niveles planteada. 
Nivel de persistencia de datos 
Por último, el nivel de persistencia de datos (data tier) es el encargado de 
guardar los datos de manera persistente. No existe comunicación directa entre 
este nivel y el de presentación como puede apreciarse en el diagrama expuesto. 
Toda comunicación se lleva a cabo a través del nivel de aplicación. En el presente 
caso, este nivel se implementa utilizando MySQL, un sistema de gestión de base de 
datos relacionales desarrollado por Oracle y que en la actualidad es considerado 
como uno de los sistemas de base de datos de código abierto más populares del 
mundo en el contexto de las aplicaciones web. 
3.2.1. Beneficios 
Con respecto al primer atributo de calidad mencionado en la sección 3.1 
del presente capítulo, la escalabilidad, se plantea en la dimensión geográfica del 
alcance que posee el sistema. El término hace referencia a la cualidad del sistema 
resultante para mantener la eficacia cuando se expande de un área pequeña a una 
región más grande; para este caso es deseable entonces lograr que la plataforma 
pueda expandir su operatoria de Tandil hacia más ciudades sin que esto signifique 
un impacto en el rendimiento como sucedería con la plataforma en su estado 
actual. 
Prosiguiendo, la extensibilidad es una medida de la capacidad de un 
sistema para extenderse y la cantidad de esfuerzo necesario para hacerlo 
mediante el crecimiento asociado al agregar nuevas características en el futuro sin 
interrumpir las operaciones actuales. Las extensiones en particular se pueden 
realizar agregando una nueva funcionalidad o modificando la funcionalidad 
actual, y la solución propuesta permite añadir mejoras sin comprometer la 
funcionalidad actual del sistema, lo cual se encuentra en congruencia con una de 
las características históricas de la plataforma actual, que permitía a grupos de 
alumnos participar en el desarrollo de nuevas funcionalidades para sumar al 
proyecto AYUD@RG. Sin embargo, dada la naturaleza monolítica de la 
 
36 
arquitectura presente en la plataforma, el añadir nuevas características 
funcionales se vuelve dificultoso. 
Por otro lado, la inclusión como atributo de calidad se relaciona 
estrechamente con el concepto de “diversidad” en relación a los diferentes tipos 
de usuarios, y consecuentemente intentar garantizar que todos estos participen 
en la mayor medida posible. Esto también se conoce como “diseño universal”, y si 
bien este concepto cubre una amplia gama de temas, para este proyecto en 
particular y dadas las expectativas acordes a un sistema de carácter solidario, se 
tienen en cuenta los aspectos necesarios para la orientación de la plataforma 
hacia: personas con bajo nivel de alfabetización, personas con conexiones de bajo 
ancho de banda o que utilizan tecnologías más antiguas, usuarios nuevos y poco 
frecuentes, y, usuarios de dispositivos móviles. 
Continuando, se reconoce a la usabilidad, entendiendo esta como el 
proceso de desarrollo de un sistema efectivo, eficiente y agradable de usar; 
consecuentemente el diseño de la experiencia del usuario (UX) forma parte de la 
usabilidad. Esto incluye por lo general aspectos amplios que afectan a todos los 
usuarios y no afectan en particular a los grupos de personas con discapacidades, y 
si bien la investigación y la práctica de la usabilidad con frecuencia no cumplen 
adecuadamente con los requisitos de las personas con discapacidades, los autores 
decidieron hacer énfasis en especial sobre un desarrollo de "usabilidad accesible" 
teniendo en cuenta las prácticas recomendadas en WCAG 2, en contraste con la 
poco clara UX/UI presente en la plataforma actual. 
Cómo se mencionó en la sección 3.2, la arquitectura de tres niveles permite 
alcanzar un alto grado de modularidad separando el diseño de la solución en tres 
bandas (o tiers): Presentación, Aplicación/Lógica de Negocios y Persistencia de 
datos. Es la misma naturaleza loose-coupling de esta arquitectura que permite 
contar con módulos bien definidos, cada uno con su conjunto determinado de 
responsabilidades. Como consecuencia de la elevada modularidad de la soluciónpropuesta, se hacen presentes otras características que también hacen a la calidad 
del sistema: 
● Testeabilidad: cada módulo o banda puede ser testeado por separado. 
 
37 
● Modificabilidad: los cambios a nivel de módulo no impactan en el resto 
siempre y cuando la comunicación entre módulos siga el mismo formato. 
3.3. Metodología de desarrollo 
Según Seguetech Technologies (2015), seguir una metodología lo mejor 
definida posible permite que un proyecto produzca mejores estimaciones, 
entregue sistemas sólidos, mantenga informado a los participantes interesados, 
establezca una imagen clara del trabajo por delante y detecte las dificultades 
antes, dando el tiempo adecuado para realizar mejoras. 
La metodología de desarrollo a utilizar para llevar a cabo este trabajo final 
forma parte de la solución y posee un nivel de relevancia equivalente a la 
arquitectura de software que acompaña la propuesta. 
Con todo esto en mente es fundamental la elección de una metodología que 
se adecúe a la dinámica de trabajo de los miembros que conforman el equipo, es 
decir los autores, y que pondere de forma apropiada su viabilidad en relación con 
sus capacidades y el contexto en el que se encuentran. 
3.3.1. Contexto social 
Miles de desarrolladores de software comenzaron a trabajar desde casa 
cuando el nuevo coronavirus tomó por absoluta sorpresa a todo el planeta a 
principios de 2020. La mayoría se vio obligada a hacer esto con poca antelación, 
en circunstancias difíciles y condiciones estresantes; y considerando lo inusual 
que es trabajar desde casa en esta ocasión, en gran cantidad de casos la 
problemática se cierne en que: en lugar de trabajar desde una oficina en casa o una 
ubicación remota propiamente equipada, las áreas designadas terminaron 
recayendo en los dormitorios y mesas de comedores. 
Los grandes conjuntos determinados por estudiantes, investigadores y 
desarrolladores de software por igual se encontraron en circunstancias inusuales 
como resultado de este brote de COVID-19. El estrés, la soledad, las limitaciones 
de viaje, el cierre de empresas y la falta de instalaciones educativas y de 
acondicionamiento físico tuvieron un impacto real en múltiples áreas. Trabajar 
 
38 
desde casa en estas circunstancias fue fundamentalmente diferente a la forma 
previa en la que era concebido el trabajo hogareño. 
En Pandemic programming (Ralph et. al., 2020) se da a conocer la primera 
investigación a gran escala sobre cómo el trabajar desde casa durante una 
pandemia afectó a los conjuntos mencionados, mediante una serie de numerosas 
contribuciones significativas entre las cuales se presenta: 
● evidencia de que la productividad y el bienestar disminuyeron; 
● evidencia de que la productividad y el bienestar general están 
estrechamente relacionados; 
● y un modelo que explica y predice los efectos de la pandemia en la 
productividad y bienestar. 
 Resulta claro entonces que los autores de este informe se vieron afectados 
de forma análoga por esta situación, por lo que encontrar métodos que puedan 
integrarse a la metodología de desarrollo y a su vez permitan coordinar el trabajo 
y comunicarse de forma remota considerando que ninguno es nativo de la ciudad 
en donde se encuentra la facultad, es de importancia superlativa para lograr 
mantener un nivel de productividad aceptable en el contexto mencionado. 
Considerando entonces que es necesario instanciar un entorno en el cual 
se pueda realizar un trabajo de esta magnitud a distancia de la manera más fluida 
posible y considerando la necesidad de comunicarse para llevar a cabo la 
organización del mismo y propiciar el intercambio de ideas permanente, se decide 
optar por los métodos de tipo ágil debido a sus características que serán 
profundizadas en la próxima sección. En particular, Nevo y Chengalur-Smith 
(2011) encuentran que al usar herramientas de TICs como la mensajería 
instantánea, las videoconferencias y la voz sobre IP, es probable que los miembros 
del equipo aumenten su capacidad para practicar métodos ágiles; y sus resultados 
sugieren que el uso de este tipo de métodos integrados con las mencionadas 
tecnologías impactan positivamente sobre la comunicación del equipo, y por lo 
tanto no solo sería factible, sino que también podría ser valioso para los equipos 
virtuales de desarrollo de software, como el encargado de llevar a cabo este 
proceso de reingeniería. 
 
39 
3.3.2. Métodos ágiles 
Con lo dicho en vista, es prudente mencionar entonces que antes de iniciar 
un proyecto de software, se considera fundamental determinar las tareas a 
realizar y administrar adecuadamente la asignación de estas entre las personas 
involucradas. Por lo tanto, la planificación es importante ya que da como resultado 
un desarrollo de software eficaz (Thakur, s.f.). Por otra parte, la planificación 
ayuda a identificar desafíos y barreras futuras, de esta forma en lugar de encontrar 
problemas durante la codificación del sistema, pudieron detectarse con 
anticipación y ajustar la estrategia de trabajo sin grandes penalizaciones 
temporales. 
En particular el modelo se enfoca en ciclos iterativos e incrementales en 
donde el trabajo se debe completar en iteraciones dentro de todo cortas y 
manejables (sprints). Si bien no se pretende llegar a la formalidad de establecer un 
plan de desarrollo de software o SDP, se desean establecer pasos generales de 
manera más informal para cada uno de los sprints a pesar de que su duración no 
se monitoree estrictamente como en otras técnicas ágiles formales (por ejemplo, 
Scrum). Estos ofrecen a los autores información relevante en relación a las tareas 
a ejecutar y la capacidad de monitorear estas actividades necesarias para la 
instanciación del sistema de información, especificando para cada elemento los 
métodos a emplear y la estrategia a seguir. De esta forma, el alcance general del 
proyecto se divide en una serie de requisitos o tareas a completar y el equipo 
establece las funcionalidades que se deberían abordar en ese ciclo al comienzo de 
cada iteración. Al final de cada una de estas, el producto debe estar listo (dentro 
de lo esperado y/o pactado) para la aprobación de los interesados al final de cada 
iteración. Para mostrar el producto de manera continua, esta forma de ciclo de 
vida requiere que los autores mantengan de forma altamente involucrada a todas 
las partes, estando estas compuestas por los directores del trabajo y los 
representantes de Proyecto Koinonía. 
En base a lo expuesto y en conjunto con las cuestiones elementales 
expuestas en el Manifesto de desarrollo de software ágil18, puede clasificarse el 
 
18 https://agilemanifesto.org/ 
 
40 
ciclo de vida de este trabajo final como adaptativo o ágil, dado que el mismo se 
caracteriza por el predominante nivel de reacción a los altos niveles de cambio, la 
participación continua de las partes interesadas y la priorización de la agilidad, 
versatilidad y flexibilidad por sobre una forma definida de desarrollo con reglas 
demasiado estrictas. 
Entonces debe quedar claro que, si bien los autores se abocan a intentar 
maximizar los principios del desarrollo ágil, no debe confundirse a los mismos con 
un grado absoluto de improvisación sobre el conjunto de tareas a realizar. Aunque 
cabe recalcar que, en cierta medida, la improvisación puede estimular la 
innovación (Crossan et al., 2005) y a su vez mejorar la velocidad de 
implementación al reducir los requisitos de planificación (Weick, 1998), las cuales 
son características deseables para obtener agilidad en la implementación de 
sistemas de tecnologías de la información. 
De esta forma se pretende que mediante la combinación de estas máximas 
propuestas, los aportes de cada uno de los autores, a pesar de la distancia y el 
contexto descrito, se integren de forma más cohesiva conforme avance el tiempo. 
Esto puede lograrse al contar rápidamentecon software funcional para mostrar a 
los interesados y ejecutar efectivamente acciones correctivas en cada iteración, 
gracias al vínculo permanente que se desea mantener con ellos con el objetivo de 
relevar opiniones y sugerencias para el proceso. 
3.3.2.1. Kanban 
En el marco de la metodología de trabajo utilizada debe mencionarse el uso 
de tableros de tipo Kanban: estos comprenden un sistema visual muy popular que 
ayuda de manera significativa a la hora de desarrollar software. 
Según lo concluido por Ahmad et. al (2014), los impulsores principales para 
adoptar Kanban en empresas de software son mejorar la colaboración en equipo 
y el flujo de desarrollo, acortar el tiempo de comercialización, aumentar la 
producción y fomentar la transparencia organizacional; y en particular, entre las 
ventajas que se obtienen con mayor frecuencia al emplear Kanban se encuentran: 
 
41 
una mayor visibilidad del trabajo, una mayor transparencia en el este y su 
comunicación, y un mejor control del flujo. 
Esta herramienta permite gestionar el trabajo a medida que se avanza en 
el proceso, y si bien requiere por supuesto comunicación en tiempo real sobre las 
actividades que lleva a cabo el equipo, presenta para ambos autores una 
transparencia sobre el trabajo realizado mucho mayor y una flexibilidad 
insuperable dado el contexto mencionado. 
Los elementos de trabajo (proceso o flujo de trabajo y trabajo real que pasa 
por el mismo) se representan visualmente en un tablero de este tipo, lo que 
permite a los miembros ver el estado de cada uno en cualquier momento. Estos 
tableros (virtuales en este caso como requerimiento para el trabajo remoto) 
utilizan tarjetas y columnas que permiten comprometerse con la cantidad de 
trabajo adecuada a ser realizada y llevarla a cabo. Debido a esto se suele decir que 
Kanban funciona como un pull system análogo a lo que sería un product backlog en 
Scrum; con la diferencia de que en este caso resulta claro que no existe un sprint 
backlog per se, sino que las tareas a realizar se establecen de manera dinámica y 
presencial en reuniones entre los autores. 
3.3.2.2. Herramientas 
Con el objetivo de facilitar y dar soporte a la realización del trabajo 
utilizando la metodología introducida, se utilizan un conjunto de sencillas pero 
poderosas herramientas consideradas adecuadas para las tareas de organización 
y comunicación que serán introducidas a continuación. 
La herramienta Tasklist es utilizada inicialmente por los autores para 
plantear un tablero de tipo Kanban sencillo y adaptado a los requerimientos de su 
grupo de trabajo. Como puede observarse en la Fig. 8 se dividen las tareas entre 
las generales, y las cuestiones propias de implementación categorizadas en los 
grandes grupos de frontend y backend. De esta forma se logra un nivel de 
granularidad adecuado en relación a la cantidad de tareas en proporción con el 
tamaño de equipo y las especialidades de sus integrantes. 
 
42 
 
Fig. 8. Vista parcial de los tableros utilizados para enumerar las tareas a realizar en 
relación a todos los elementos del trabajo final. 
A pesar de que Tasklist presentó la posibilidad de que los autores trabajen 
utilizando tableros Kanban en primera instancia, se trataba de una herramienta 
gratuita no muy popular; esto conllevó a la lamentable consecuencia de que el 
servicio cesara a principios del año 2022. Debido a esto los mismos se vieron 
obligados a encontrar una alternativa equivalente para continuar con la misma 
metodología de trabajo y ritmo pactados. La alternativa encontrada fue Trello. 
Esta herramienta también presenta una forma sencilla de crear un tablero 
de Kanban virtual. A pesar de tener mayor dificultad en la configuración inicial, 
definitivamente tiene mucho más poder, y esta versatilidad se ve reflejada en el 
impacto de productividad que tuvo la transición hacia esta herramienta. La misma 
permite por supuesto crear listas digitales que representan las tareas en una vista 
de tablero Kanban que facilita tanto acceder a la misma como también gestionarla 
de manera remota y simultánea, y ampliar su funcionalidad mediante widgets que 
potencian sus capacidades. 
En este caso, existiendo la posibilidad de asignar códigos de colores en 
relación a las categorías de las tareas y asignar a cada miembro del equipo 
diferentes tareas, se opta por una disposición Kanban más tradicional, en la que 
las tareas se encuentran en la misma lista, aquellas bloqueadas debido a una 
dependencia directa de una o más tareas se indican en una segunda lista, y en la 
última se colocan las terminadas. Posteriormente se añade una lista general para 
 
43 
tareas vinculadas a organización. Un ejemplo de la evolución de las tareas en 
función del tiempo puede verse ejemplificado en la Figura 9. En relación a las 
capacidades de la herramienta, se debe mencionar el grado de versatilidad que 
brinda en relación a sus integraciones con otras herramientas y la posibilidad de 
enviar y recibir notificaciones a los integrantes, por ejemplo, para coordinar 
reuniones y confirmar la asistencia de cada uno a las mismas o reprogramarlas 
para días y horarios más convenientes. 
Por otra parte, la comunicación es un elemento importante del proceso de 
desarrollo de software que expande su influencia hacia numerosas áreas. Si bien 
muchos factores pueden afectar el éxito del proyecto, los aspectos más relevantes 
de que resulten frustrados suelen estar vinculados a la comunicación ineficaz del 
equipo, que a menudo es la causa principal del fracaso de los proyectos de 
ingeniería complejos. La comunicación entre las partes interesadas también es un 
punto de falla (que afecta las expectativas, los requisitos, las estimaciones, los 
cronogramas, etc.) del proyecto (DeFranco, 2017). 
 
 
Fig. 9. Vista general de los tableros creados en la herramienta Trello con la utilización de 
asignación de tareas por usuario y códigos de color según el área de especialidad. 
 
44 
La herramienta Slack19 ofrece, en términos sencillos, un medio de 
comunicación con notificaciones multiplataforma e integración con comandos de 
las herramientas de desarrollo más populares. Esta promete brindar “canalización 
de entrega de principio a fin”, recorriendo todo el proceso de desarrollo a lo largo 
del ciclo de vida de desarrollo del sistema. Y si bien los autores consideran que se 
trata claramente de una exageración con fines marketineros, su utilidad general 
desde el punto de vista de practicidad comunicacional a lo largo del trabajo es 
fundamental. 
Para su utilización, se procede a crear un espacio de trabajo y un canal 
(espacio de conversación) dedicado a todo lo relacionado específicamente al 
desarrollo de la tesis de grado cuyo aspecto puede visualizarse en la Fig. 10. De 
esta forma se puede colaborar en especificaciones, revisiones de código y estados 
de implementación con gran facilidad. 
 
Fig. 10. Vista del canal creado en Slack. En el mismo se ven las notificaciones creadas por 
la integración con Trello al realizar algún cambio relacionado con las tareas y con Github 
al actualizar alguno de los repositorios del proyecto. 
Por otro lado, la potencia de la integración de Trello y Git con el canal de 
Slack creado, genera un nivel de transparencia que permite realizar captura 
 
19 https://slack.com/intl/es-ar/ 
 
45 
problemas y asignaciones para su resolución rápidamente, comentar en tiempo 
real sobre cualquiera de estos tópicos y en definitiva lograr que cada autor se 
concentre en sus prioridades eliminando en simultáneo posibles redundancias o 
malentendidos. 
En términos generales permite a los autores poseer visibilidad en tiempo 
real del progreso y las decisiones del proyecto, y dejar un registro de los mismos 
en relación a las conversaciones entabladas para consulta permanente. 
Prosiguiendo con las herramientas, debe recalcarse que el uso de un 
servicio