Est´ andares

Modificabilidad

La elecci´on de tecnolog´ıas fue realizada para promover software modificable. Se opt´o por usar lenguajes del paradigma de POO con la utilizaci´on de principios como SOLID [73] que promueven la extensi´on y modificabilidad controlada del c´odigo.

Testeabilidad

El RNF13 trata de contar con al menos 90% de cobertura en los tests au- tom´aticos, en nuestro caso unitarios y de integraci´on, hechos conJest [92], descrito en la secci´on 8.3.3. Pruebas de software. Esto mejora la mantenibilidad, aumen- tando la facilidad de nuestrosoftware a ser modificado, dado que en caso de realizar una modificaci´on se pueden correr los tests para asegurar que las funcionalidades cubiertas por estos siguen funcionando correctamente.

Se adjunta evidencia de haber logrado esta cobertura enbackend:

Figure 5.15: Cobertura de pruebas.

5.4.7 Escalabilidad

El cliente expres´o que al desarrollar debemos tener en cuenta que nuestras aplica- ciones potencialmente ser´an usadas por un subconjunto de su gran base de usuarios.

Evidencia de que contamos con una aplicaci´on escalable, es decir, que cumple con lo pactado en el RNF11 (ver apartado 4.3.7) se puede ver en la imagen del cumplimiento de rendimiento previamente adjuntada (figura 5.15), donde se hace una prueba de carga que llega hasta al rededor de 3500 peticiones por minuto con un 0% de errores.

Escalabilidad horizontal

Nuestra arquitectura debe soportar m´ultiples instancias de la aplicaci´on funcio- nando simult´aneamente para cumplir con el RNF11, con un servicio de balanceador de carga encarg´andose de proporcionar cantidades similares de carga entre las dis- tintas instancias.

Containerizaci´on

El uso de im´agenes de Docker mejor´o la escalabilidad del sistema dado que al escalar horizontalmente se pueden levantar nuevas instancias en menor tiempo. Esto permite responder a la nueva carga de usuarios lo antes posible.

Esto tambi´en facilita futuras automatizaciones como usar Docker Swarm [93] o Kubernetes [94] para el escalado.

Escalabilidad vertical

Se puede modificar la configuraci´on de GCP para contar con instancias con mejores recursos, por ejemplo aumentar la cantidad de memoria RAM.

5.5 Validaciones de la arquitectura

La validaci´on de la arquitectura del sistema es un paso crucial en cualquier proyecto. Una vez que se ha dise˜nado una arquitectura, es necesario asegurarse de que esta cumpla con los requisitos y expectativas del cliente, as´ı como de los expertos t´ecnicos involucrados en el proyecto. En esta secci´on se describir´a c´omo se valid´o la arquitectura propuesta, explicando los pasos seguidos y los resultados obtenidos.

5.5.1 Revisi´ on t´ ecnica

La validaci´on de la arquitectura se llev´o a cabo mediante una revisi´on t´ecnica liderada por el cliente. Como ya se explic´o antes Ben Pham (director y arquitecto principal desoftware) y Sravya Patruni (ingeniera desoftware senior) fueron exper- tos t´ecnicos que conoc´ıan el proyecto en profundidad y aportaron una perspectiva valiosa sobre la arquitectura propuesta.

El proceso de validaci´on comenz´o con una presentaci´on detallada de la arquitec- tura propuesta, que inclu´ıa diagramas, descripciones de componentes y explicaciones de c´omo los distintos elementos interactuaban entre s´ı. Durante la presentaci´on, se explic´o c´omo se hab´ıan tomado en cuenta las restricciones del proyecto y se mostr´o c´omo se hab´ıan solucionado los problemas identificados en las etapas previas.

El cliente plante´o preguntas y comentarios durante la presentaci´on, y el equipo de desarrollo proporcion´o respuestas detalladas y justificaciones para cada uno de ellas.

Tambi´en se discutieron posibles mejoras y optimizaciones que podr´ıan realizarse en la arquitectura, algunas siendo descartadas por el cliente como se detalla en el Anexo 12.

En este cap´ıtulo se ha demostrado lo interesante que puede ser el proceso de investigaci´on en la construcci´on de una aplicaci´on iOS y watchOS con SwiftUI. Durante el desarrollo, se enfrentaron desaf´ıos que pusieron a prueba el conocimiento aprendido durante la carrera y la habilidad del equipo.

Uno de los mayores desaf´ıos fue el desarrollo de la funcionalidad de offline en la aplicaci´on. Esto implic´o el dise˜no de una arquitectura adecuada que permitiera almacenar datos y permitir el funcionamiento sin conexi´on a internet.

En cuanto al uso de los patrones arquitect´onicos descritos en este cap´ıtulo, se cree que usar Clean Architecture ayud´o a lograr una arquitectura mantenible. El equipo contaba con experiencia trabajando con arquitecturas en este patr´on, tanto independientemente como en combinaci´on con el patr´on MVVM. La combinaci´on de estos patrones permiti´o una mayor modularidad y escalabilidad en el proyecto de frontend, facilitando la integraci´on de nuevos componentes y los cambios a lo largo del ciclo de vida de la aplicaci´on. En definitiva, se cree que el uso de los patrones elegidos result´o altamente beneficioso para el equipo.

La poca madurez de watchOS por parte de Apple tambi´en present´o un desaf´ıo adicional para el equipo. Esto se puede ver reflejado en la falta deAPIs que a´un no est´an disponibles para la plataforma de Apple Watch, por ejemplo NWPathMoni- tor [49].

Otro desaf´ıo significativo fue la integraci´on con Ulta, ya que se encontraron lim- itantes y la empresa fue cambiando sus APIs durante el desarrollo del proyecto.

El equipo tuvo que adaptarse a estos cambios sobre la marcha, y fue gracias a la arquitectura s´olida que se hab´ıa establecido que pudo hacerse de manera r´apida y eficiente.

En conclusi´on, el desarrollo de esta aplicaci´on present´o desaf´ıos significativos, pero el proceso de investigaci´on fue muy interesante y permiti´o al equipo de desar- rollo superar los obst´aculos que se presentaron. La arquitectura que se estableci´o desde el principio fue clave para permitir al equipo adaptarse a los cambios y lograr un producto adecuado a las expectativas t´ecnicas del cliente.

6. Gesti´ on del proyecto

En este cap´ıtulo se detallar´an las actividades de gesti´on del proyecto llevadas a cabo, as´ı como las decisiones m´as importantes tomadas en el proceso. Tambi´en se abordar´an las estrategias implementadas para gestionar los riesgos principales. Cabe recordar que el marco de gesti´on utilizado fue detallado en el cap´ıtulo 3, donde se describieron las caracter´ısticas de los diferentes marcos de gesti´on aplicados a lo largo del proyecto, as´ı como los roles y responsabilidades de los miembros del equipo.

6.1 Beneficios del uso de metodolog´ıas ´ agiles para la gesti´ on del proyecto

La utilizaci´on de metodolog´ıas ´agiles en la gesti´on del proyecto ha demostrado ser altamente beneficiosa. Estas metodolog´ıas permiten un enfoque m´as flexible, iterativo y colaborativo, lo que ha facilitado el alcance de los objetivos del proyecto y la satisfacci´on de las necesidades del cliente. A continuaci´on, se presentan los principales beneficios de su uso.

6.1.1 Adaptabilidad y flexibilidad

Las metodolog´ıas ´agiles permiten afrontar cambios en los requerimientos y pri- oridades del proyecto de manera eficiente.

Dada la naturaleza del mismo, donde el cliente dej´o en claro que se buscaba proactividad por parte del equipo y daba lugar para que al avanzar en el proyecto, si se detectaba alguna oportunidad, pudieran agregarse nuevos requerimientos.

Sumado a la flexibilidad en cuanto a requerimientos, un desaf´ıo de este proyecto era la gesti´on del tiempo disponible por el equipo, por lo que contar con un enfoque

´

agil que permitiera actualizar las prioridades conforme se avanzaba fue un gran beneficio.

Las metodolog´ıas ´agiles promueven la transparencia, inspecci´on y adaptaci´on, por lo que sigui´endolas el equipo fue capaz de adaptarse r´apidamente para garantizar que el producto final cumpl´ıa con las expectativas del cliente [95].

6.1.2 Colaboraci´ on e interacci´ on constante con el cliente

El enfoque ´agil foment´o la comunicaci´on constante y efectiva entre el equipo y el cliente, en contraste con los enfoques tradicionales, que suelen limitar la comuni- caci´on a momentos espec´ıficos del proyecto [96]. Esto puede generar malentendidos y desalineaciones, lo cual hubiese sido sumamente perjudicial en un proyecto como este, ya que los mismos se hubieran detectado en una etapa muy tard´ıa, sin dar lugar a reajustar su curso.

Uno de los aspectos en los que el equipo considera que la interacci´on constante con el cliente ha sido beneficiosa, es en la construcci´on de una relaci´on s´olida y efectiva entre las partes. Sin dudas, una buena relaci´on entre el equipo y el cliente durante el transcurso del proyecto fue un factor clave para el ´exito del mismo. Sin embargo, alcanzar esta relaci´on no era tarea f´acil, debido a la gran diferencia en la cultura laboral que exist´ıa con los representantes del cliente.

El hecho de mantener una cadencia de comunicaci´on semanal con el cliente, propia de los proyectos con metodolog´ıas ´agiles [97], permiti´o a ambas partes cono- cerse mejor entre s´ı, incluyendo la forma de expresarse de cada uno. Esta result´o

En conclusi´on, la colaboraci´on cercana y frecuente con el cliente no solo asegur´o un buen relacionamiento entre las partes, sino que tambi´en garantiz´o que el producto final estuviera alineado con las necesidades y objetivos del cliente, maximizando as´ı la satisfacci´on y el ´exito del proyecto.

6.1.3 Entrega temprana y continua de valor

Las metodolog´ıas ´agiles se enfocan en la entrega de valor a lo largo del proyecto mediante iteraciones y entregas incrementales.

Gracias a esto, el cliente pudo validar las funcionalidades de la aplicaci´on en cada etapa del desarrollo, lo que disminuy´o el riesgo de insatisfacci´on y permiti´o una gesti´on m´as efectiva del tiempo y recursos, enfoc´andose en aquellas funcionalidades que generan un mayor valor.

Adem´as, la entrega continua de valor fue un gran beneficio, ya que le permiti´o al equipo la obtenci´on de retroalimentaci´on por parte del cliente tras probar la aplicaci´on en cada iteraci´on.

6.1.4 Aprendizaje del equipo

El enfoque ´agil promueve la mejora continua y el aprendizaje a trav´es de la reflexi´on y ajuste de las pr´acticas del equipo. Al ser un equipo numeroso, era necesario contar con mecanismos de mejora a lo largo del proyecto.

Gracias a los eventos que el marco ´agil brind´o, el equipo pudo identificar y abor- dar los desaf´ıos o problemas conforme iban sucediendo, mejorando as´ı la eficiencia y efectividad del mismo.

la gesti´on de sus proyectos de forma interna. El acceso a Jira se realiz´o mediante credenciales proporcionadas porUlta, y se utiliz´o una red privada virtual [99] (VPN por sus siglas en ingl´es) para poder ingresar a la plataforma.

Esta herramienta proporcion´o diversos beneficios durante el desarrollo del proyecto.

En primer lugar, su integraci´on con BitBucket permiti´o que la gesti´on del c´odigo fuente fuera m´as fluida y eficiente. Adem´as, al estar orientada a proyectos ´agiles, la herramienta se adapt´o perfectamente al marco de trabajo scrum, a la cual el equipo estaba acostumbrado. Jira proporcion´o una f´acil visualizaci´on de las his- torias de usuario y sus tareas asociadas, lo que permiti´o mantener un seguimiento constante del progreso. La visualizaci´on pr´actica tanto del backlog del producto como de lossprints permiti´o que se pudiera planificar mejor el trabajo a realizar en cada iteraci´on.

Otro beneficio importante de Jira fue su integraci´on con el cliente, lo que per- miti´o que los reportes de las pruebas de exploraci´on fueran entregados directamente en la plataforma, y que el equipo pudiera ser etiquetado en cualquier consulta rela- cionada con el proyecto. Adem´as, el product owner pudo ver directamente desde la herramienta la evoluci´on del proyecto, lo que permiti´o tomar decisiones m´as infor- madas y oportunas.

6.2.3 Clockify

Se utiliz´oClockify como una herramienta de gesti´on de tiempo. Uno de los inte- grantes del equipo ya contaba con experiencia previa en el uso de esta herramienta, lo que permiti´o integrarla f´acilmente en el flujo de trabajo.

Una de las principales funcionalidades de Clockify es que permite realizar un seguimiento preciso del tiempo dedicado a cada tarea del proyecto. El objetivo de su uso fue identificar en qu´e se estaba dedicando m´as tiempo y as´ı ajustar el enfoque del esfuerzo seg´un fuera necesario. Esto se pudo hacer en gran medida, aunque debido a que no se lleg´o a conocer todo el potencial de la herramienta, no

se pudo sacar mayor provecho de la misma para generar reportes m´as precisos.

6.3 Gesti´ on del alcance

La gesti´on del alcance es crucial para garantizar el ´exito de cualquier proyecto, ya que ayuda al equipo a tener un control adecuado sobre las tareas que deben realizarse, para cumplir con los objetivos establecidos dentro de los l´ımites de tiempo con recursos disponibles.

En este cap´ıtulo se explora c´omo se llev´o a cabo la gesti´on del alcance durante el proyecto, incluyendo la definici´on del alcance, la utilizaci´on de herramientas para su gesti´on y su relaci´on con las etapas del marco de trabajo elegido.

6.3.1 Definici´ on del alcance

El alcance del proyecto estaba limitado por el tiempo, ya que se deb´ıa cumplir con fechas establecidas por la universidad. Por lo tanto, fue importante definir las funcionalidades del proyecto de manera eficiente para poder cumplir con el alcance dentro del tiempo establecido.

Las funcionalidades se definieron durante la etapa de ingenier´ıa de requerimientos llevada a cabo en conjunto con el cliente (ver cap´ıtulo 4). Cada requerimiento funcional (representado en una historia de usuario) y requerimiento no funcional, fue priorizado. Esta prioridad se valid´o con elproduct owner del proyecto.

Gracias a la priorizaci´on, el equipo pudo centrarse durante los primeros sprints en realizar aquellas funcionalidades que el cliente consideraba m´as valiosas. Lo

Los planes dereleases son una pr´actica complementaria a scrum, que mira hacia adelante en varios sprints y proporciona un estimado de cu´ando estar´a disponible un conjunto coherente de funcionalidades [100].

Durante la etapa dediscovery, adem´as de definir que se iban a tener instancias de demostraci´on con cliente para que brindara retroalimentaci´on de forma temprana, tambi´en se gener´o un plan dereleases, tanto del backend como de las aplicaciones.

El plan inicial fue tener tres releases, finalizando a comienzos de diciembre y dejando el tiempo restante hasta enero para pruebas y soluci´on de defectos. Cada uno de los releases corresponder´ıa a un timebox¹ con un objetivo de entregable definido junto con el cliente.

Figure 6.1: Primer plan de release del sistema.

Pero este plan fue modificado a partir de la mitad delsprint 0. El equipo evalu´o las tareas que quedaban por terminar de dichosprint, y determin´o que para la fecha

1Untimebox es un enfoque en el que se establece un periodo de tiempo espec´ıfico para trabajar en un objetivo. En lugar de trabajar hasta alcanzar el objetivo, el trabajo se detiene al final de la caja de tiempo y se eval´ua lo que se logr´o en ese per´ıodo. [101]

del primer release no se iban a haber implementado las funcionalidades estimadas en un comienzo.

Siguiendo el principio de calidad integrada [102], el equipo decidi´o incluir las pruebas en el proceso de desarrollo, al igual que la resoluci´on de los defectos encon- trados, en lugar de dedicar la mayor parte de diciembre a las pruebas y arreglo de defectos.

Esta decisi´on ten´ıa como objetivo que el equipo iterara sobre un producto con calidad, y por consiguiente lograra trabajar de forma eficiente. De esta manera, se iban a detectar los errores en el c´odigo y defectos en las aplicaciones prematuramente, aprendiendo de estos para evitar cometerlos durante el resto del proyecto. Como resultado de esto el equipo pudo ver que a medida que el proyecto iba creciendo las pruebas encontraban errores m´as complejos, producto de la complejidad que adquir´ıa el sistema. Por lo tanto, mitigar los defectos encontrados de manera temprana fue beneficioso a largo plazo.

A ra´ız de esto, se gener´o un segundo plan con solo dosreleases. Luego del primer release, estaba planificado con el cliente realizar pruebas con expertos en el dominio del problema (ver apartado 2.1), para obtener retroalimentaci´on que pudiera resultar valiosa para el desarrollo restante. En el ´ultimo release, que ser´ıa a mediados de diciembre, se har´ıan pruebas de usabilidad con usuarios deUlta, dejando el resto de dicho mes para implementar ajustes a partir de los resultados obtenidos.

Figure 6.2: Segundo plan de release del sistema.

El equipo comenz´o a preparar el primer release a comienzos de noviembre. Esto fue un gran acierto, ya que se descubri´o de forma temprana que elrelease delbackend no lo podr´ıan realizar los miembros del equipo por falta de permisos, que no se les pod´ıa brindar por pol´ıticas de seguridad de Ulta. As´ı que se necesit´o que dicho release lo hiciera la representante t´ecnica que estaba trabajando con el equipo.

Tom´o semanas coordinar con el cliente los permisos, accesos y despliegue tanto del backend como las aplicaciones frontend, pero finalmente el 21 de noviembre se hizo el primerrelease exitoso del proyecto. Despu´es de esto, el equipo cre´o dos gu´ıas que detallaban los pasos necesarios para desplegar el sistema, principalmente con el objetivo de transferir ese conocimiento a la representante t´ecnica deUlta, que solo se especializaba enbackend y no sab´ıa c´omo realizar este tipo de despliegues. Estas gu´ıas se pueden ver en el Anexo 18, y el detalle de c´omo hacer los despliegues en la secci´on 7.1.1. Control de cambios.

Luego de esto, el equipo aprovech´o para generar despliegues luego de cadasprint, para que las pruebas de exploraci´on hechas por el cliente fueran realizadas en un ambiente lo m´as similar a producci´on. Estos despliegues de versiones intermedias

del producto no forman parte del plan de release, sino que son un complemento a las iteraciones.

Si bien se ten´ıa planificado que el primer release lo probaran expertos de Ulta, esto no se pudo gestionar, ya que dicho equipo no ten´ıa la disponibilidad horaria durante ese per´ıodo. Por lo tanto, estas pruebas se dejaron para hacer junto con las de los usuarios, al terminar el proyecto.

El desarrollo finaliz´o el 2 de enero de 2023, dando fin a la etapa dedelivery.

Figure 6.3: Burn up chart [103] con la evoluci´on del backlog del producto y los releases.

Aunque durante el desarrollo se presentaron algunos retrasos (que se pueden ver en la figura 6.3), el equipo logr´o mantener el enfoque en las historias de usuario relacionadas con los objetivos comprometidos para el primer release, por lo que

con los objetivos del ´ultimo sprint. M´as adelante durante esta secci´on, se detallar´a m´as sobre estas decisiones tomadas.

Esta modificaci´on en la fecha de finalizaci´on, y por consiguiente el release final, se produjo como consecuencia de nuevas funcionalidades que se agregaron durante el proyecto. Estas ten´ıan como objetivo brindar un producto m´as completo, mejorando la experiencia de usuario. Se agregaron funcionalidades relacionadas con el skin tracking,widgets para el dispositivo celular, y la posibilidad de recuperar una rutina eliminada.

A partir del ´ultimo release se comenzaron a preparar las pruebas que se iban a realizar con usuarios y expertos. Finalmente, las pruebas con usuarios no se pudieron hacer por limitaciones de la empresa.

Luego del ´ultimo release se tuvieron que hacer arreglos debido a cambios en los servicios de Ulta con los que interoperaba el backend. En consecuencia, se hizo un release extra despu´es de finalizada la etapa dedelivery.