9. Gesti´ on de la configuraci´ on 140
9.2. Separaci´ on de ambientes
de los sprints. Al principio, el equipo tenia poca experiencia en el ´area de gesti´on de en proyectos reales, por lo que a la hora de planificar y estimar un nuevo sprint, el equipo inclu´ıa todos los tickets correspondientes a ese sprint, sumados a los pen- dientes desprints anteriores. Esto generaba una acumulaci´on de deuda t´ecnica que, a medida que avanzaba el proyecto, se convirti´o r´apidamente en un problema. Para solucionarlo, el equipo decidi´o buscar asesoramiento externo con Rafael Bentancur, un experto en el ´area de gesti´on de proyectos, quien aport´o consejos valiosos en cuanto a c´omo mejorar el proceso de gesti´on del proyecto.
Entre los consejos de Rafael, el equipo comenz´o a implementar estos tres:
1. Comenzar a medir la velocidad de desarrollo
2. Planificar sprints al 90 % de la capacidad y dejar 10 % para imprevistos 3. Re-estimar ´epicas peri´odicamente hasta el final de proyecto
Figura 4.7: Reuni´on de Gesti´on con Rafael Bentancur
Con estos cambios el equipo comenz´o a mejorar el proceso de gesti´on del proyecto, lo que permiti´o reducir la acumulaci´on de deuda t´ecnica y avanzar de manera m´as eficiente en el proyecto.
Finalmente, el proyecto culmin´o con un producto estable y probado en un ambiente de pre-producci´on con usuarios reales. El producto todav´ıa no se encuentra expues-
proyectada para finales de abril de 2023.
En cuanto a los puntos fuertes del proceso de gesti´on se puede remarcar que el equipo demostr´o una gran capacidad de adaptaci´on y cambio en respuesta a las necesidades del proyecto. Adem´as, fue capaz de implementar cambios importantes que le per- mitieron avanzar m´as eficientemente y lograr una mayor calidad en el producto final.
Entre los puntos d´ebiles del proceso de gesti´on del proyecto se encuentra la falta de experiencia en el mismo, lo cual llevo a una acumulaci´on constante de deuda t´ecnica durante una parte del proyecto. Adem´as, la falta de claridad de los interesados en cuanto a la fecha de lanzamiento del producto gener´o cierta incertidumbre en el equipo, propia de la inexperiencia.
A continuaci´on se detallan los requerimientos funcionales relevados que deb´ıa cum- plir el sistema:
RF1. Registro y Login de Administradores
Actor: Administradores de TEKO/NMC
Un usuario administrador deber´a poder invitar a otros usuarios administradores a la plataforma envi´andole un correo electr´onico que contenga un link. Una vez abierto dicho link los deber´a redirigir a la pantalla registro de la plataforma web. Tambi´en se deber´a soportar la opci´on de reenv´ıo de invitaci´on.
RF2. Registro y Login de Voluntarios
Actor: Voluntario
Los usuarios voluntarios podr´an registrarse a trav´es de la aplicaci´on m´ovil con Single- Sign-On utilizando su cuenta de Google, Facebook o Apple. Se deber´a ofrecer una pantalla de registro que permita a cualquier persona registrarse como voluntario de NMC ingresando sus datos.
RF3. Registro y Login de Centros de Acopio
Actor: Usuario centro de acopio
Un usuario administrador deber´a poder crear un centro de acopio desde la web ingre- sando sus datos. Una vez ingresada dicha informaci´on se deber´a finalizar el registro del centros de acopio a la plataforma envi´andole un correo electr´onico al responsable que contenga un link.
Una vez abierto dicho link los deber´a redirigir a la pantalla finalizaci´on de registro de centro de acopio de la plataforma web donde el mismo deber´a ingresar la contra- se˜na. Una vez finalizado el registro podr´a ingresar sesi´on desde la pagina de login de la plataforma web.
RF4. Gesti´on de Voluntarios
Actor: Administradores de NMC
El sistema debe permitir a los administradores visualizar los datos de cada usuario registrado en la aplicaci´on m´ovil as´ı como deshabilitar un voluntario en caso que sea necesario. Se deber´a soportar filtrado de usuario por nombre, edad y departamento.
RF5. Gesti´on de Centros de Acopio
Actor: Administradores de NMC
El sistema debe permitir a los administradores visualizar los datos de cada centro de acopio as´ı como la baja y modificaci´on en caso que sea necesario. Tambi´en se deber´a soportar filtrado de centros por nombre y ubicaci´on.
RF6. Gesti´on de ceniceros p´ublicos
Actor: Administradores de NMC
El sistema debe permitir a los administradores visualizar los datos de cada cenicero publico as´ı como soportar la alta, baja y modificaci´on de los mismos.
RF7. Visualizaci´on de mapa de centros de acopio y colilleros
Actor: Voluntarios de NMC
El mapa en la aplicaci´on m´ovil deber´a permitir a los voluntarios visualizar la ubi- caci´on de los centros de acopio as´ı como de los colilleros disponibles en Uruguay.
RF8. Entrega de residuos en centros de acopio
Actor: Voluntarios de NMC/Centro de acopio
Un voluntario deber´a poder realizar la entrega de sus residuos recolectados en un centro de acopio registrado en la plataforma. Para esto, se presentar´a presencialmen- te en el centro de acopio, realizar´a la carga de datos de su recolecci´on a trav´es de la aplicaci´on m´ovil, y esta entrega deber´a ser verificada por un usuario responsable del centro de acopio receptor a trav´es de la aplicaci´on web.
El usuario responsable del centro de acopio validar´a que los datos ingresados sean consistentes con la entrega realizada y en ese caso podr´a confirmar la recepci´on. En caso de existir cualquier inconveniente podr´a rechazar la recepci´on.
RF9. Solicitud de recolecci´on en domicilio
Actor: Voluntarios de NMC
Un voluntario deber´a poder solicitar que sus residuos sean recolectados en su ho- gar por otro voluntario. Para esto deber´an comenzar una solicitud v´ıa la aplicaci´on m´ovil, en la que cargue la informaci´on necesaria de sus residuos, su disponibilidad horaria en el d´ıa y direcci´on de retiro para que otro voluntario pase por su domicilio a recolectar el acopio. En esta instancia, el sistema deber´a enviar una notificaci´on push a los voluntarios que se encuentren dentro del mismo departamento a la direc- ci´on de la recolecci´on.
Los voluntarios que reciben la notificaci´on push deber´an poder aceptar o rechazar la solicitud de recolecci´on a trav´es de la aplicaci´on m´ovil.
Una vez aceptada la solicitud por un voluntario, se deber´a mostrar un mensaje infor- mativo al voluntario solicitante indicando que su solicitud fue aceptada. Tambi´en se desplegar´an los datos del voluntario que acept´o la solicitud de recolecci´on (nombre y numero de tel´efono).
Se dar´a la opci´on a ambas partes de en cualquier momento rechazar o completar la acci´on una vez que el retiro haya finalizado subiendo una foto de forma opcional como prueba de la acci´on y se deber´a notificar a los voluntarios involucrados de dichas acciones.
Nota 1: En cualquier momento el solicitante puede eliminar la solicitud. Si al cabo de 24 horas de iniciada la solicitud esta aun no ha sido asignada, el solicitante deber´a tener la opci´on de reenviar una notificaci´on a los voluntarios de la zona.
RF10. Consulta de Acciones
Actor: Administradores de NMC
El usuario administrador deber´a poder visualizar en la aplicaci´on web una lista completa con las acciones realizadas por los voluntarios en la plataforma, para mo- nitorear la actividad realizada por la organizaci´on en tiempo real.
Tambi´en deber´a poder buscar, ordenar y filtrar acciones espec´ıficas seg´un los siguien- tes filtros: Fecha de realizaci´on, el voluntario que realiz´o la acci´on, el voluntario que acept´o la solicitud (en caso de retiro en domicilio), el centro de acopio (en caso de haber sido una entrega en centro de acopio), y el estado de la solicitud.
RF11. Contenido variable en aplicaci´on m´ovil
Actor: Administradores de NMC
Los administradores deber´an poder modificar una secci´on de contenido din´amico de la aplicaci´on m´ovil. Para esto, deber´an poder visualizar las im´agenes actualmente activas, cambiarlas de orden, darlas de baja, y cargar nuevas im´agenes, desde el portal web. Tambi´en deber´an poder asociarles un link web.
Estas im´agenes deber´an desplegarse en la pantalla principal de la aplicaci´on m´ovil y al ser seleccionadas redirigir´an al usuario al link asociado.
RF12. Reportes ambientales
Actor: Voluntarios de NMC
Los voluntarios deber´an poder reportar a los administradores de NMC desde la apli- caci´on m´ovil sobre situaciones ambientales que entiendan importante comunicar.
Para esto, deber´an contar con un formulario dentro de la aplicaci´on d´onde podr´an redactar un mensaje y adjuntar una imagen opcionalmente.
RF13. Inicio de consultas/reportes de empresas
Actor: Empresas
Al igual que en el RF13, las empresas que tengan contratado el servicio de NMC deber´an poder contactarse con los administradores de la plataforma desde el portal web, ya sea para consultas, reportes y advertencias, u otro tipo de mensajes.
El seguimiento y respuesta a estas consultas ser´a gestionado por fuera del sistema, de igual modo que con las consultas/reportes de los voluntarios
RF14. Visualizaci´on y resoluci´on de reportes de voluntarios
Actor: Administradores de NMC/TEKO
Los administradores deber´an poder visualizar un listado con las consultas/reportes de los voluntarios y empresas (RF13 y RF14) desde la aplicaci´on web. Pudiendo visualizar imagen y mensaje escrito en el reporte como tambi´en la informaci´on de contacto de quien creo el reporte. Para facilitar el seguimiento de estos reportes, el administrador podr´a marcarlas como “leidas”.
Nota: La respuesta a estos reportes no entra dentro del alcance del proyecto. Asu- mimos que en caso de ser necesario una respuesta por parte de los administradores, podr´ıan hacerlo a trav´es de canales de comunicaci´on tradicionales como Whatsapp o correo electr´onico, utilizando los datos adjuntos a la consulta.
RF15. Administraci´on de constantes
Actor: Administradores de TEKO/NMC
Un usuario administrador deber´a tener la posibilidad de modificar las constantes del sistema desde la aplicaci´on web sin necesidad de acceder a la base de datos direc- tamente para facilitar la gesti´on del producto. De especial importancia son poder
modificar las unidades de medida y los materiales disponibles para las entregas.
RF16. Registro de Empresas mediante invitaci´on
Actor: Administradores de TEKO
Un usuario administrador deber´a poder invitar a otros usuarios clientes a la plata- forma, envi´andole un correo electr´onico que contenga unlink de acceso. Primero el administrador deber´a llenar los datos b´asicos de la empresa y una vez completado se enviar´a el mail de invitaci´on. Luego de abierto dicho link los deber´a redirigir a la pantalla registro de empresa en la plataforma web. Tambi´en se deber´a soportar la opci´on de reenv´ıo de invitaci´on.
RF17. Gesti´on de Empresas
Actor: Administradores de TEKO
El sistema deber´a permitir a los administradores la visualizaci´on de los datos de cada empresa registrada y filtrado por nombre de las mismas. Tambi´en se deber´a permitir al administrador editar los datos de las empresas registradas en el sistema.
RF18. Registro de recolecci´on
Actor: Administradores de TEKO
El usuario administrador deber´a poder ingresar un registro de recolecci´on de resi- duos, especificando acopio recolectado (peso y material), empresa en la que hizo la recolecci´on, fecha y responsable de recolecci´on.
Se deber´a permitir borrado de registros contemplando que se puede cargar mal un dato.
RF19. Registro de facturaci´on
Actor: Administradores de TEKO
El usuario administrador deber´a poder ingresar un factura al sistema, especificando monto, fecha, vencimiento y empresa a la que hizo la factura.
Se deber´a permitir borrado de facturas contemplando que se puede cargar mal un dato.
RF20. Ficha de Cliente Empresa
Actor: Administradores de TEKO y empresas
Se deber´a poder visualizar los detalles de una empresa mostrando datos de la misma, incluyendo detalles del plan actual en cuanto a recolecciones y facturaci´on.
Para una empresa accediendo a su propia ficha solo se permitir´a la visualizaci´on de dichos datos. Para un administrador se habilitar´a la modificaci´on del plan y gesti´on de la facturaci´on.
RF21. Constancia de recolecci´on
Actor: Empresas
Se deber´a generar de forma din´amica una constancia de recolecci´on mensual con la informaci´on cargada en el sistema. Dicha constancia podr´a ser visualizada por las empresas en cualquier momento. Tambi´en se deber´a soportar la opci´on de descargar las mismas en formato PDF.
RF22. Resumen de estado de la organizaci´on
Actor: Administradores TEKO
Se deber´a visualizar undashboard con m´etricas que representen el estado de la ope- rativa general de TEKO. La informaci´on relevante para mostrar en esta secci´on es:
cantidad de empresas registradas, facturaci´on mensual, recolecciones mensuales, y planes activos.
A continuaci´on se presenta el an´alisis realizado en relaci´on a los requerimientos funcionales previamente mencionados.
Usabilidad
La usabilidad refiere a la facilidad con que un sistema es comprendido y utilizado por parte de sus usuarios, y el esfuerzo que deben realizar para completar una tarea deseada.
A pesar de que la usabilidad es un atributo de calidad que se tuvo en cuenta para todo el sistema, el equipo entendi´o que este seria clave para flujos que involucraran a voluntarios de NMC y empresas clientes de TEKO, con el objetivo de lograr la adopci´on de la aplicaci´on por parte de los voluntarios y maximizar el valor agregado a las empresas. En particular determinados flujos contaron con un an´alisis y asegu- ramiento del cumplimiento del atributo en profundidad:
1. RF8. El proceso de entrega de los residuos recolectados en centros de acopio era un flujo fundamental de la aplicaci´on de voluntarios. La mayor´ıa de los usuarios utilizar´ıan la aplicaci´on con este fin, por lo que era sumamente im- portante pensar en un flujo amigable, f´acilmente entendible, que un usuario promedio sintiera c´omodo y pr´actico de utilizar. Adem´as, este flujo involucraba al actor centro de acopio en el sistema web, por lo que deb´ıa ser cuidadosa- mente dise˜nado para garantizar su entendimiento y eficacia.
2. RF9. La solicitud de recolecci´on en domicilio era una funcionalidad de la apli- caci´on que pretend´ıa lograr la colaboraci´on entre distintos tipos de voluntarios (aquellos m´as y menos activos). El logro de un flujo pr´actico permitir´ıa que un n´umero significante de personas pudieran comenzar a colaborar con la organi- zaci´on desde la comodidad de su hogar. Por esta raz´on fue importante analizar y dise˜nar este flujo cuidadosamente, para garantizar su usabilidad.
3. RF20. La ficha de empresa es la funcionalidad principal con la que las em- presas interactuar´ıan durante su sesi´on en el sistema. Por esta raz´on, y consi- derando que la propuesta de valor de TEKO previamente no pasaba por una componente tecnol´ogica, fue importante lograr una experiencia de usuario ami- gable, que invitara a las empresas a querer utilizar el sistema para visualizar el detalle del plan contratado, facturaci´on e informaci´on del impacto logrado.
4. RF21. El servicio contratado por las empresas se resume en la gesti´on inte- gral de sus residuos colillas, y a la posterior validaci´on del impacto ambiental positivo logrado por la empresa. Por esta raz´on, era importante lograr una experiencia usuaria agradable en el flujo de acceso a las constancias de reco- lecci´on, ya que se trataba de la principal raz´on de utilizaci´on del sistema.
Mantenibilidad
El producto deb´ıa estar estructurado de tal forma que realizar cambios ya sea para extender su funcionalidad o para arreglar defectos fuera un proceso directo y sin dificultades importantes.
Considerando que los sistemas desarrollados serian puestos en producci´on y conti- nuar´ıan siendo mantenidos por terceros ajenos al equipo posteriormente, el sistema deb´ıa permitir extender sus funcionalidades de forma directa y accesible. Para esto era necesario dise˜narlo correctamente para que las actividades de mantenimiento no se volvieran complejas ni trajeran complicaciones inesperadas.
Esto abarc´o a todas las funcionalidades del sistema y tuvo implicancias directas en la forma de estructurar la arquitectura, que se mencionar´an m´as adelante en la secci´on 7.5 Dise˜no de sistemas.
Portabilidad
Este atributo se refleja en t´erminos del costo relacionado a adaptar los sistemas de su plataforma original a una plataforma nueva, soportar nuevos tipos de dispositi- vos, y las implicancias t´ecnicas y funcionales que ese proceso puede implicar.
El sistemamobile para voluntarios deber´ıa estar preparado para soportar la mayor cantidad de dispositivos posibles, considerando la diversidad de perfiles de volun- tarios, y tambi´en que estos deber´ıan poder interactuar con la plataforma desde sus dispositivos personales. Esto implicaba considerar el uso de los recursos disponibles, las limitantes tecnol´ogicas existentes, compatibilidad entre las herramientas usadas y los dispositivos, entre otros factores.
1. RF2. El registro y login de los voluntarios requer´ıa flujos con distintos pro- veedores de identidad, entre estos Google y Apple. La integraci´on con dichos proveedores podr´ıa tener implicancias en la implementaci´on dependiendo del sistema operativo, ya que ciertas funcionalidades nativas de Android son utili- zadas por la autenticaci´on con Google, as´ı como algunas de iOS son utilizadas por la autenticaci´on con Apple.
2. RF7.La visualizaci´on en un mapa de los centros de acopio y colilleros p´ublicos era una funcionalidad que deber´ıa ser desarrollada con especial atenci´on en que la compatibilidad con los sistemas operativos seleccionados fuera respetada. Al interactuar con caracter´ısticas nativas del dispositivo como los mapas, podr´ıa ser desafiante garantizar una amplia compatibilidad.
3. RF9. La solicitud de recolecci´on a domicilio de un voluntario ser´ıa una funcio- nalidad que utilizar´ıa notificaciones push para la comunicaci´on con los clientes
m´oviles, por lo que era importante comprobar el correcto funcionamiento en iOS y Android, para las distintas versiones de sistemas operativos compatibles con la aplicaci´on.
Seguridad
Este atributo de calidad es una medida de la habilidad de un sistema de proteger la informaci´on y los datos del acceso desautorizado.
Considerando el hecho de que en el sistema de empresas se ofrec´ıa una soluci´on multitenant, se volv´ıa necesario dise˜nar la soluci´on teniendo en cuenta la funciona- lidad de control de acceso estricto, manejo de roles y permisos. Tambi´en se deber´ıa garantizar el manejo seguro de los datos personales y empresariales de los usuarios.
Esto alcanzaba a casi todos los flujos de la aplicaci´on, seg´un lo indicado en la si- guiente tabla.
Rol Requerimientos Funcionales
Administrador RF1, RF3, RF4, RF5, RF6, RF11, RF12
RF15, RF16, RF17, RF18, RF19, RF20, RF21, RF22 Voluntario RF2, RF8, RF9, RF10, RF13
Centro de Acopio RF8
Empresa RF14, RF17, RF20, RF21
Tabla 5.1: Control de Acceso por RF
Escalabilidad
Escalabilidad es la capacidad del sistema de aumentar su carga de trabajo sin reducir su rendimiento, es decir, crecer en su base de usuarios sin ver limitado el funciona- miento.
En el caso de NMC, la escala de su base de usuarios ser´ıa peque˜na en una primera instancia, pero estaba proyectado un crecimiento sostenido para los pr´oximos a˜nos, por lo que la aplicaci´on deber´ıa poder soportar el flujo de usuarios esperado a futuro y sus respectivos datos generados (M´as detalle sobre estimaciones de crecimiento en la secci´on 6.1 Hip´otesis y estimaciones).
1. RF4, RF5, RF6, RF10, RF14, RF17 La gesti´on de entidades deber´ıa so- portar el aumento de la base de usuarios. Las funcionalidades de administrador deber´ıan continuar funcionando sin percances una vez que los listados crecie- ran en volumen, manteniendo el correcto funcionamiento en las funciones de b´usqueda, filtrado y ordenado particularmente.
2. RF7. Una vez que la cantidad de ceniceros p´ublicos y centros de acopios