Universidad ORT Uruguay Facultad de Ingeniería
SCSE: Sistema para Control y Seguimiento de Envíos
Entregado como requisito para la obtención del título de Licenciado/a en Sistemas
Autores
Gabriel Valdomir Muslera - 191621 Nicolás Magliano Pereira - 201435
Tutora
Helena Garbarino
2022
Declaración de Autoría
Nosotros, Gabriel Valdomir Muslera y Nicolás Magliano Pereira, declaramos que el trabajo que se presenta en esa obra es de nuestra propia mano. Podemos asegurar que:
• La obra fue producida en su totalidad mientras realizábamos el proyecto de la carrera;
• Cuando hemos consultado el trabajo publicado por otros, lo hemos atribuido con claridad;
• Cuando hemos citado obras de otros, hemos indicado las fuentes. Con excepción de estas citas, la obra es enteramente nuestra;
• En la obra, hemos acusado recibo de las ayudas recibidas;
• Cuando la obra se basa en trabajo realizado conjuntamente con otros, hemos explicado claramente qué fue contribuido por otros, y que fue contribuido por nosotros;
• Ninguna parte de este trabajo ha sido publicada previamente a su entrega, excepto donde se han realizado las aclaraciones correspondientes.
Gabriel Valdomir Muslera Nicolás Magliano Pereira 8 de abril del 2022 8 de abril del 2022
Agradecimientos
Este proyecto no habría sido posible sin la dedicación y participación de los integrantes del equipo, Nicolás Magliano Pereira y Gabriel Valdomir Muslera.
Dichos integrantes agradecen el enormemente el apoyo de la tutora, la Dra.
Helena Garbarino, sus aportes con una perspectiva profesional por su amplia trayectoria liderando y tutorando proyectos, fue crucial para mejorar la calidad y aplicación de técnicas de éste.
La participación y confianza del gerente de la compañía ‘EntregasUY’, Gustavo Pierro, fue otra muy importante para este proyecto, ya que fue él quien abrió las puertas de su negocio exponiendo sus datos y la operativa, para hacer este proyecto posible.
El apoyo por parte de la Universidad ORT Uruguay fue fundamental, con el aporte de docentes muy profesionales que siempre apoyaron y guiaron en el mejor uso de buenas prácticas con bibliografías, toda la infraestructura proporcionada para poder implementar herramientas de calidad en sus laboratorios, y la facilitación de licencias de diversas herramientas de software.
Finalmente, los integrantes no pueden dejar de agradecer el constante apoyo incondicional de sus familiares y amigos, quienes supieron estar en los momentos de mayor tensión como soportes emocionales empáticos, cruciales para la
estabilización psicológica del equipo.
Abstract
El proyecto de SCSE: Sistema para Control y Seguimiento de Envíos nace para ofrecer una herramienta de integración a una empresa logística,
‘EntregasUY™’, con el objetivo de facilitar sus operaciones. En manos de un entusiasta equipo, este proyecto tiene expectativas de evolución para poder convertirse en una herramienta que cambie la forma de organizar y distribuir los recursos de las empresas.
Tras un exhaustivo relevamiento de requerimientos contra los actores de la empresa ‘EntregasUY™’, y la incorporación de una metodología ágil como SCRUM, mediante el uso de un amplio abanico de técnicas de desarrollo, como los principios de un código limpio[1], las heurísticas de Nielsen[2], los principios y patrones del desarrollo de las aplicaciones de software[3], entre otros, sumados al uso de un amplio abanico de tecnologías como Angular™, ASP.NET Core™, GitHub™, Heroku™, Netlify™, entre otros, se desarrolló una Rest API a modo de MVP
(producto mínimamente viable) con el objetivo de introducirse en el mercado con una solución robusta y fácilmente adaptable a problemas similares.
Para asegurar la calidad se plantearon objetivos, estándares y métricas, entre esas se incluyeron expectativas de latencia, ajuste al calendario, cobertura de
testing, entre otros. Donde finalmente, dadas las definiciones anteriores, la solución implementada cumple en gran medida las expectativas del equipo, con un trabajo que requirió un total de 520 horas de dedicación total.
Finalmente, gracias a la buena selección de roles en un equipo de 2
integrantes, la buena definición de herramientas de comunicación entre equipo-tutor y equipo-cliente, el buen análisis de riesgos para desarrollar planes de mitigación y contingencias, y sin lugar a dudas la selección de una metodología ágil para el desarrollo se puede ver que hubo un buen ajuste al calendario.
Resultando así un proyecto con vías de evolución, que expuso a los miembros del equipo a un entorno divergente, que los llevó a una importante experiencia de aprendizaje.
Palabras Clave
Angular
ASP.NET Core Buenas prácticas C#
Código limpio EntregasUY Framework
Integración Tecnológica Logística
MVP Rest API
Sistema para Control de Envíos Sistema para Seguimiento de Envíos
Sistema para Control y Seguimiento de Envíos
Glosario
● Angular: Es un framework para aplicaciones web desarrollado en TypeScript, de código abierto, mantenido por Google™.
● API: Conjunto de funciones y procedimientos que ofrece cierta biblioteca para ser utilizada por otro software como una capa de abstracción.
● Burndown chart: Gráfico que muestra evolución de los sprint y los puntos restantes del total del product backlog a lo largo de la vida del proyecto.
● C#™: Lenguaje de programación desarrollado y estandarizado por Microsoft™ como parte de su plataforma .NET™.
● Deploy: se refiere al proceso de llevar una aplicación web a sus posibles consumidores, lo que debe estar 100% en línea para su uso.
● Docker™: Docker™ es un proyecto de código abierto que automatiza el despliegue de aplicaciones.
● Feedback: Proceso en el cual se devuelve una serie de comentarios sobre algo con el fin de mejorarlo.
● Imágenes: Se trata de la creación de capturas del código actual y guardados en un archivo que se le referencia como imagen en Docker™, que luego son utilizadas para publicar el código.
● MVP: Del inglés “Minimum Viable Product”, es el producto mínimamente viable para poder comenzar a comercializar.
● Postear: Llamamos postear al acto de publicar nuestro código o imágenes Docker™ en las herramientas de deploy elegidas por el equipo que componen la arquitectura.
● Product Owner: Representante de la empresa que se le realiza el software que es responsable de asegurar que el equipo aporte valor al negocio.
● Publish: Llamamos publish al acto de publicar el código o imágenes Docker™
en las herramientas de deploy elegidas por el equipo que componen la arquitectura.
● Repositorio: Lugar donde se almacena el código del proyecto.
● Scrum: Scrum es un marco de trabajo para desarrollo ágil de software. Se aplican de manera regular un conjunto de buenas prácticas para trabajar colaborativamente, en equipo y obtener el mejor resultado posible de proyectos.
● Sesión: es un mecanismo utilizado permite conservar información sobre un usuario al pasar de una página a otra. Este es guardado por lo general en una base de datos de los servidores.
● Testear: Proceso por el cual una persona analiza un objeto (en este caso programa) con el fin de verificar su correcto funcionamiento.
● Token: Recurso Utilizado para identificar las sesiones de un usuario, alojado en la máquina del mismo (Tipo de cookie).
● Usuario: Persona que va a hacer uso de la aplicación.
Índice
1. Introducción 17
1.1. Motivación 17
1.2. El equipo de proyecto 17
1.3. El cliente 18
1.4. Objetivos 18
1.4.1. Del proyecto 18
1.4.2. Académicos 19
1.4.3. Del producto 19
1.5. Descripción del problema 19
1.6. Descripción de la solución 20
1.7. Propuesta de valor 20
1.8. Evaluación de oportunidad 20
1.9. Organización del documento 21
1.9.1. Capítulo 1: Introducción 21
1.9.2. Capítulo 2: Ingeniería de requerimientos 21
1.9.3. Capítulo 3: Diseño arquitectónico 21
1.9.4. Capítulo 4: Gestión de calidad 21
1.9.5. Capítulo 5: Gestión de la configuración 22
1.9.6. Capítulo 6: Gestión del proyecto 22
1.9.7. Capítulo 7: Conclusiones 22
2. Ingeniería de requerimientos 23
2.1. Introducción 23
2.2. Proceso de ingeniería de requerimientos 23
2.2.1. Card 23
2.2.2. Conversation 23
2.2.3. Confirmation 24
2.3. Requerimientos 24
2.3.1. Principales funcionalidades 24
2.3.2. Actores del sistema 24
2.3.3. Requerimientos funcionales dentro del alcance pactado 25
2.3.4. Requerimientos fuera del alcance pactado 26
2.3.5. Diagramas de flujo 26
2.3.6. Requerimientos no funcionales 27
2.3.7. Carta de intención de desarrollo pactado 28
2.3.8. Prioridad de requerimientos 28
2.3.9. Evolución del Product Backlog 30
2.4. Manual de usuario 30
3. Diseño arquitectónico 32
3.1. Introducción 32
3.2. Análisis de requerimientos no funcionales 32
3.3. Decisiones de diseño 32
3.4. Herramientas y tecnologías de desarrollo 33
3.4.1. Listado de herramientas y tecnologías 33
3.4.1.1. Tecnologías Implementadas 33
3.4.1.2. Web service 34
3.4.1.3. Interfaz 34
3.4.1.4. Base de datos 34
3.4.1.5. Entorno de desarrollo 35
3.4.1.6. Control de versiones 35
3.4.2. Justificación de herramientas y tecnologías 35
3.4.2.1. Tecnologías implementadas 35
3.4.2.2. Web service 36
3.4.2.3. Interfaz 36
3.4.2.4. Base de datos 36
3.4.2.5. Entorno de desarrollo 36
3.4.2.6. Control de versiones 37
3.5. Arquitectura de deploy 37
3.5.1. Backend 37
3.5.2. Frontend 38
3.5.3. Diagrama de deploy 38
3.6. Vistas 39
3.6.1. Estructura del proyecto 40
3.6.2. Vistas de comportamiento 41
3.6.3. Diagrama de entidades 42
3.7. Especificación de API 44
3.7.1. Criterios para cumplir con API REST 44
3.7.2. Especificaciones de los recursos 44
4. Gestión de la calidad 45
4.1. Introducción 45
4.2. Objetivos 45
4.3. Aseguramiento de la calidad (SQA) 45
4.4. Principales actividades de SQA 46
4.4.1. Definición de estándares 46
4.4.2. Pruebas de concepto de tecnologías 46
4.4.3. Testing 46
4.5. Definición de métricas 47
4.5.1. Introducción 47
4.5.2. Métricas de proceso 47
4.5.3. Métricas de producto 47
4.6. Evolución y análisis de métrica 48
4.6.1. Proceso 48
4.6.2. Producto 52
4.7. Testing 53
4.7.1. Unit testing 54
4.7.2. Mock testing 54
4.7.3. Postman testing 55
4.7.4. Testing exploratorio 57
4.8. Docker 58
5. Gestión de la configuración 60
5.1. Introducción 60
5.2. Repositorio 60
5.3. Respaldo 61
5.4. Identificación de las CI’s 61
5.5. Control de versiones 62
6. Gestión del proyecto 63
6.1. Introducción 63
6.2. Metodología de gestión de proyecto 63
6.3. Metodología del proceso de construcción de software 63
6.3.1. Roles 63
6.3.2. Artefactos 64
6.3.3. Ceremonias 64
6.4. Gestión del tiempo 64
6.4.1. Definición de actividades 64
6.4.2. Secuenciamiento de actividades 65
6.4.3. Estimación de recursos y duración 66
6.4.4. Desarrollo del cronograma 66
6.4.5. Etapas del proyecto 66
6.4.6. Roles y responsabilidades 67
6.4.7. Disponibilidad del equipo 68
6.5. Gestión de riesgos 69
6.5.1. Planificación de los riesgos 69
6.5.1.1. Categorías de riesgos 69
6.5.1.2. Identificación 70
6.5.1.3. Metodología de gestión de riesgo 70
6.5.1.4. Riesgos sobre product owner 71
6.5.1.5. Riesgos del proyecto 71
6.5.1.6. Riesgos sobre el tutor 72
6.5.1.7. Riesgos sobre tecnologías 73
6.5.1.8. Riesgos sobre el equipo 73 6.5.2. Plan de mitigación y contingencia de riesgos 74 6.5.2.1. Contingencia de riesgos sobre product owner 74 6.5.2.2. Mitigación de riesgos sobre product owner 74
6.5.2.3. Contingencia de riesgo de proyecto 74
6.5.2.4. Mitigación de riesgos de proyecto 75
6.5.2.5. Contingencia de riesgos sobre tecnologías 75 6.5.2.6. Mitigación de riesgos sobre tecnologías 75 6.5.2.7. Contingencia de riesgos sobre el equipo 75
6.5.2.8. Mitigación de riesgos sobre el equipo 75
6.5.3. Plan de mitigación y contingencia de riesgos posteriores 76
6.5.3.1. Mitigación de riesgos de proyecto 76
6.5.3.2. Contingencia de riesgos de proyecto 76
6.5.4. Evolución de riesgos 76
6.5.4.1. Análisis de la evolución de riesgos 77
6.6. Gestión de las comunicaciones 78
6.6.1. Comunicación interna 79
6.6.2. Comunicación externa 80
6.7. Resultados de los sprints 81
7. Conclusión 83
Referencias bibliográficas 85
Anexos 86
Anexos Capítulo 1 86
Anexos 1.2. El equipo de proyecto 86
Anexo 1.2.1: CV Gabriel Valdomir Muslera 86
Anexo 1.2.2: CV Nicolás Magliano Pereira 87
Anexos Capítulo 2 88
Anexo 2.2. Proceso de ingeniería de requerimientos 88 Anexo 2.2.3: Carta de conformidad de requerimientos 88
Anexo 2.3. Requerimientos 91
Anexo 2.3.5: Diagramas de flujo 91
Anexo 2.3.5.1: Diagramas del proceso sin solución 91 Anexo 2.3.5.2: Diagramas del proceso con solución 93
Anexo 2.3.5.3: Casos de uso 97
Anexo 2.3.5.3.1: Crear pedido 97
Anexo 2.3.5.3.2: Crear nuevo usuario tienda 98
Anexo 2.3.5.3.3: Cerrar pedido 99
Anexo 2.3.9: Evolución del product backlog 100
Anexos Capítulo 3 101
Anexo 3.4. Herramientas y tecnologías de desarrollo 101 Anexo 3.4.1: Listado de herramientas y tecnologías 101
Anexo 3.4.1.4: MER 101
Anexo 3.6. Vistas 102
Anexo 3.6.1: Diagramas de vistas 102
Anexo 3.6.1.1: Vistas de bienvenida 102
Anexo 3.6.1.2: Vistas de administrador 103
Anexo 3.6.1.3: Vistas de chofer 104
Anexo 3.6.1.4: Vistas de cliente 104
Anexo 3.6.2: Diagramas de interacción 105
Anexo 3.6.2.1: Interacción Login 105
Anexo 3.6.2.2: Interacción solicitud pedido 106
Anexo 3.6.2.3: Interacción realización pedido 107 Anexo 3.6.2.4: Interacción solicitud registro 108 Anexo 3.6.2.5: Interacción aprobación registro 109
Anexo 3.6.3: Diagramas de entidades 110
Anexo 3.6.3.1: Diagrama UML inicial de clases del dominio 110
Anexo 3.6.3.2: Diagrama UML acceso a datos 111
Anexo 3.6.3.3: Diagrama UML capa de negocios 112
Anexo 3.6.3.4: Diagrama UML validadores 113
Anexo 3.7. Especificación de API 114
Anexo 3.7.1: Criterios para cumplir con API Rest 114
Anexo 3.7.1.1: Mecanismos de autenticación 114
Anexo 3.7.1.2: Manejo general de los códigos de la API 115
Anexo 3.7.2: Especificaciones de recursos 116
Anexo 3.7.2.1: Recursos clientes 116
Anexo 3.7.2.2: Recursos choferes 118
Anexo 3.7.2.3: Recursos administrador 120
Anexo 3.7.2.4: Recursos zonas personalizadas 122
Anexo 3.7.2.5: Recursos pedidos 125
Anexos Capítulo 4 128
Anexo 4.6. Evolución y análisis de métrica 128
Anexo 4.6.1: Planificación Inicial GANTT 128
Anexo 4.6.2 GANTT Final 129
Anexo 4.7. Testing 130
Anexo 4.7.1: Unit Testing 130
Anexo 4.7.2: Mock Testing 132
Anexo 4.7.3: Postman testing 136
Anexo: 4.7.3.1: POST Administrador 136
Anexo 4.7.3.2: 201 Administrador Created 137
Anexo 4.7.3.3: POST Pedido 137
Anexo 4.7.4: Testing Exploratorio 138
Anexo 4.7.4.1: Escenarios Exploratorios 138
Anexo 4.7.4.2: Lista de clientes pendientes de aprobación 140
Anexo 4.7.4.3: Lista de choferes 140
Anexo 4.7.4.4: Lista de pedidos disponibles 140
Anexo 4.7.4.5: Pedidos de un chofer 141
Anexo 4.7.4.6: Pedidos de un cliente 141
Anexos Capítulo 6: Gestión del proyecto 142
Anexo 6.5. Gestión de riesgos 142
Anexo 6.5.1: Planificación de riesgos 142
Anexo 6.5.1.4. Riesgos sobre product owner 142
Anexo 6.5.1.5. Riesgos del proyecto 142
Anexo 6.5.1.6. Riesgos sobre tecnologías 143
Anexo 6.5.1.7. Riesgos sobre el equipo 144
Anexo 6.7: Resultados de Sprints 145
Anexo 6.7.1: Plan y Resultados de Sprint 1 145
Anexo 6.7.2: Plan y Resultados de Sprint 2 147
Anexo 6.7.3: Plan y Resultados de Sprint 3 150
Anexo 6.7.4: Plan y Resultados de Sprint 4 153
Anexo 6.7.5: Plan y Resultados del Sprint 5 155
1. Introducción
En este capítulo se explica quién es el cliente y sus inquietudes. Quienes son los integrantes del equipo, cuáles son los objetivos del proyecto, cómo este
documento está organizado y cómo el equipo piensa aportar valor con una descripción de alto nivel de la solución.
1.1. Motivación
Se considera que este proyecto, además de apoyar a los negocios locales, puede posicionarlos en un mercado pujante como el de la logística, incluso mejorar los procesos y la experiencia de los clientes que utilizan servicios logísticos
internacionalmente.
El equipo es muy entusiasta y nota valor en trabajar con nuevas tecnologías como APIs de mapas que manejan datos en tiempo real, tal y como comprender otros sectores y áreas, con el fin de entrenar sus habilidades.
1.2. El equipo de proyecto
El equipo cuenta con 2 integrantes, ambos de la carrera de Licenciatura en Sistemas.
Gabriel Valdomir, un estudiante de la ciudad de Rivera, que como Chief Technology Officer (CTO) de un pequeño emprendimiento llamado “MiEdificio™”, obtuvo
experiencia en integración tecnológica con sistemas de terceros, en la comprensión de problemas fuera del área, y en el buen desempeño en entornos críticos y
cambiantes. Teniendo que resolver integraciones con empresas como WhatsApp™, Twilio™ y ABITAB™, se puede ver su currículum en Anexo 1.2.1: CV Gabriel
Valdomir Muslera.
Nicolás Magliano, un estudiante de la ciudad de Maldonado, le apasiona la ciencia de datos por lo cual realizó la profundización de la carrera en esta área. En la actualidad, se desempeña como consultor del equipo de Data & Analytics de
Quanam™ desde hace ya medio año, enfocándose en el área de Data & Analytics, se puede ver su currículum en Anexo 1.2.2: CV Nicolás Magliano Pereira.
1.3. El cliente
El cliente es la empresa EntregasUY™ cuyo dueño es Gustavo Pierro, él durante muchos años de su vida fue dueño y socio de UES envíos hasta que decidió venderla.
EntregasUY™ es una PYME de 8 empleados, con una estructura que se puede apreciar en la imagen 1.3.1 Organigrama de EntregasUY™, que se dedica a trabajar en la cadena de distribución de aquellas compañías que requieren sus servicios. La empresa consta de 1 gerente general y 7 choferes que son los que van a llevar los pedidos, al ser una pequeña empresa el gerente general es el que
realizará las tareas que sean necesarias suplir desde la perspectiva de una compañía, por ejemplo, recursos humanos.
Imágen 1.3.1 Organigrama de EntregasUY™
1.4. Objetivos
En principio, el equipo detecta 3 perspectivas, que valen la pena separar para explicar los objetivos.
1.4.1. Del proyecto
Ligado a que este proyecto nace de los problemas del cliente Gustavo Pierro, el proyecto tiene como objetivo satisfacer las necesidades que se presentan en su
negocio, tanto para él, como para sus funcionarios y clientes, logrando mejorar así la gestión de los pedidos que le realizan.
1.4.2. Académicos
De la mano con que este proyecto tiene un carácter académico, el equipo tiene como objetivo poder realizar un proyecto completo y correcto, aplicando los conocimientos adquiridos en la carrera, con el fin de poder demostrar que están capacitados como para obtener el título de “Licenciado en Sistemas”.
Además, el proyecto tiene como objetivo aprender nuevas tecnologías, como API de mapas en tiempo real, ya que el equipo estima que es una tecnología muy usada, por lo cual creen que es importante saber manejarla.
1.4.3. Del producto
Además de los objetivos anteriores, este proyecto espera transformarse en producto, y tiene objetivos de calidad evaluados con una serie de métricas que se pueden ver en el Capítulo 4: Gestión de calidad, tales como disponibilidad, tolerancia a fallos, usabilidad, entre otros.
1.5. Descripción del problema
El gerente general (Gustavo Pierro) de la compañía EntregasUY™ trabaja hace varios años en la cadena de distribución de aquellas compañías que requieren sus servicios. De su experiencia, encuentra que el proceso tiene múltiples
ineficiencias, por lo que es necesario un estudio y rediseño del mismo. Asimismo, la incorporación de tecnología daría soporte a los nuevos procesos permitiendo
alcanzar los objetivos antes mencionados.
En la actualidad, lleva a cabo la gestión de los envíos que le solicitan en una planilla Microsoft Excel® compartida, al igual que la gestión de los clientes y sus pedidos, separándolos por hojas. Las rutas para realizar la distribución quedan a criterio del repartidor. Estas prácticas fueron útiles cuando la empresa era pequeña, pero a medida que comenzó a crecer su cartera de clientes, estas prácticas se
comenzaron a volver caóticas, y de la mano con éste caos, comenzaron a aparecer errores de gestión, y tomar decisiones inciertas.
1.6. Descripción de la solución
El equipo le plantea al cliente una Web API desarrollada en ASP.NET Core™
y Angular™, hosteada en servidores de Heroku™, Netlify™ y la base de datos en AWS™, para dar solución a las necesidades de los actores de su empresa
(administrador, repartidores y tiendas), centrándose en la facilidad de uso y la calidad.
Aunque el MVP únicamente requiera procesos de gestión e historial de pedidos, se incluyó el manejo de zonas de distribución y etiquetas QR dado el interés del cliente.
1.7. Propuesta de valor
La principal propuesta de valor que se espera ofrecer con la solución es la facilidad del trabajo, mediante la unificación de herramientas y la automatización en medida de lo posible. Esto desencadenará que tanto los clientes como los
funcionarios tengan tareas más sencillas, por lo que el manejo del activo principal de la empresa, que son los pedidos, podrá ser realizado de mejor manera.
1.8. Evaluación de oportunidad
Junto a la motivación del equipo, los integrantes consideran que es una gran oportunidad trabajar con el sector logístico, ya que es un sector que mueve parte importante de la economía, por lo cual aprender de esta industria es sin lugar a dudas una gran oportunidad.
Otra oportunidad detectada es la posibilidad de transformar el proyecto en un producto comercializable a terceros.
1.9. Organización del documento
En esta sección se explica cómo está constituido el presente documento, cuáles son sus capítulos, cuál es el propósito de cada uno y sus temáticas.
1.9.1. Capítulo 1: Introducción
En este capítulo se presenta la temática introductoria e inicial para este
proyecto, además de poder ver un breve resumen respecto a qué trata cada capítulo del documento, podrá conocer a los integrantes del equipo, cómo éste está formado y qué los motiva. Se plantean también los objetivos del proyecto, académicos, y del producto.
Finalmente, se plantea una descripción de los problemas que presenta el cliente en su empresa, cuál es la solución que propone el equipo para dar fin a estos problemas y cómo ésta aporta valor al mismo, y las puertas que abre a los
integrantes del equipo trabajar sobre este proyecto.
1.9.2. Capítulo 2: Ingeniería de requerimientos
En este capítulo se explican las técnicas que aplicó el equipo para poder comprender el problema, para poder así describir una serie de funcionalidades que aportarían a cada actor de los que se identificaron, se mostrará también cómo resuelve los problemas hoy en día el cliente, y cómo nosotros planeamos facilitar esas técnicas.
1.9.3. Capítulo 3: Diseño arquitectónico
En este capítulo el equipo explica cuáles fueron las decisiones de diseño que tomaron para poder armar la solución para el cliente, se muestran las herramientas y las tecnologías que se usaron y se explica por qué se seleccionó cada una de ellas.
Finalmente se muestra también la estructura general del sistema y sus pantallas.
1.9.4. Capítulo 4: Gestión de calidad
En este capítulo se muestran cuáles fueron las prácticas ejecutadas por el equipo para asegurar la calidad en el proyecto, cuáles fueron las pruebas que realizó
el equipo para evaluarlo, y cuáles fueron las métricas en las que se basó el equipo para decidir si algo era o no aceptable.
1.9.5. Capítulo 5: Gestión de la configuración
En este capítulo se explica cómo los integrantes del equipo hicieron para poder trabajar de forma conjunta en el código, cómo se manejaron las versiones y qué herramientas fueron necesarias para esto.
1.9.6. Capítulo 6: Gestión del proyecto
En éste capítulo se explica cuáles fueron las técnicas de gestión del proyecto aplicadas por el equipo, cuáles fueron los roles y sus responsabilidades, las
ceremonias y artefactos necesarios, cómo se utilizaron los tiempos, incluidas la planificación separada por etapas y herramientas para controlar el tiempo, los riesgos identificados y un plan de acción para los que resultaron más preocupantes, y finalmente se explica cómo los integrantes manejaron las comunicaciones entre ellos, y cómo se comunicaron con los interesados para poder sacar el proyecto adelante.
1.9.7. Capítulo 7: Conclusiones
En este capítulo se hace un cierre del proyecto, donde se cuentan las experiencias que tuvieron los integrantes del equipo durante el período, qué cosas aprendieron y cómo creen que resultó el proyecto.
2. Ingeniería de requerimientos
2.1. Introducción
En este capítulo se describe el proceso de selección, validación y especificación de requerimientos del Sr. Gustavo Pierro, product owner de EntregasUY™ de acuerdo con las necesidades identificadas.
2.2. Proceso de ingeniería de requerimientos
Para poder relevar los requerimientos se utilizó la técnica CCC(card,
conversation and confirmation)[4]. Antes de poder aplicar esta técnica el equipo tuvo que capacitar al product owner en ella ya que el mismo no conocía de qué se
trataba.
Una vez finalizada la capacitación, se procedió a entregar al cliente el formato a utilizar en la tarjeta, un archivo Microsoft Excel® compartido para realizar la tarea de forma más dinámica y no tener que recurrir a reuniones presenciales.
2.2.1. Card
En la primera instancia (Card) se notó la necesidad de manejar 3 actores principales: Administrador, Choferes y Tiendas.
Posteriormente, se detectó que el resultado de los requerimientos escritos era muy ambiguo o resultaba en historias épicas por lo que se volvió a capacitar al product owner en el proceso, donde hizo énfasis en cómo construir una historia correcta y a deconstruir historias épicas en unas más simples para alivianar su carga.
2.2.2. Conversation
Una vez terminado el proceso anterior, se pasó a incluir detalles y
comentarios sobre requerimientos particulares. Esto incluyó información sobre datos involucrados o el proceso de solución para realizar correctamente el diagrama de flujo.
2.2.3. Confirmation
Para la validación se decidió realizar los diagramas de flujo que representan los procesos de negocio y presentarlos al product owner.
Una vez validados, quedan definidos los requerimientos de la solución.
Asociado a lo anterior se describió la solución final, incluyendo las tecnologías para satisfacer las necesidades, requerimientos funcionales y no funcionales, lo cual incluyó una carta de conformidad respecto a los requerimientos acordados dentro del plazo del proyecto, firmada por los integrantes del equipo, el product owner y el tutor, se puede ver esta carta en el Anexo 2.2.3: Carta de conformidad de requerimientos.
2.3. Requerimientos
2.3.1. Principales funcionalidades
Mediante el proceso anterior, el cliente describe un grupo de tareas básicas para la operativa natural del trabajo de los actores de EntregasUY™, éstas incluyen la realización y gestión de los pedidos. Es importante que las empresas cliente de EntregasUY™ puedan realizar sus solicitudes de distribución, tal y como es
importante que los choferes puedan ver las solicitudes que fueron aceptadas por el gerente de la compañía.
Además, el gerente, quien lleva a cabo las finanzas de la empresa, necesita tener acceso y buen control respecto a los pedidos en distintos estados de sus clientes, necesita tener el poder de asignar a un chofer un pedido pendiente, y también, para poder realizar los pagos de sueldos y conocer las deudas de los
clientes, necesita poder filtrar los pedidos por chofer, por estado de pago, por cliente, por periodo, o una combinación de las anteriores.
2.3.2. Actores del sistema
Se identificaron 3 actores:
● Administrador: Un usuario único que tiene acceso a todas las funcionalidades y tiene poderes de borrar y agregar a su necesidad ítems del sistema.
● Usuario tienda: Empresas que utilizan los servicios de EntregasUY™, requieren agregar pedidos y ver un historial de ellos con su estado.
● Usuario repartidor: Choferes de EntregasUY™, requieren ver los paquetes asignados, y modificar los estados de los mismos.
2.3.3. Requerimientos funcionales dentro del alcance pactado
En esta sección se listan los requerimientos funcionales propuestos por el product owner en el formato descrito en la sección anterior.
● R1: Como tienda quiero solicitar registro para usar servicios en el sistema.
● R2: Como tienda quiero poder modificar mis datos para poder cambiarlos.
● R3: Como tienda quiero cargar pedidos para que sean llevados a su destino.
● R4: Como tienda quiero poder modificar un pedido para cambiarlos previo a que sean retirados.
● R5: Como tienda quiero imprimir etiquetas de mi producto para poder identificarlos.
● R6: Como tienda quiero ver un histórico de mis pedidos para poder visualizarlos.
● R7: Como administrador quiero dar de alta usuarios choferes para que usen el sistema.
● R8: Como administrador quiero aceptar solicitudes de registro de tiendas para poder usar el sistema.
● R9: Como administrador quiero modificar datos de choferes para realizarles cambios de datos.
● R10: Como administrador quiero darlos de baja a un chofer para que no usen el sistema.
● R11: Como administrador quiero definir la hora límite que cada tienda puede registrar pedidos para cumplir con el envío en el mismo día.
● R12: Como administrador quiero poder definir tarifas individuales para tiendas y choferes para cobrarles según mis preferencias.
● R13: Como administrador quiero poder ver las fichas de mi cliente para visualizar su información.
● R14: Como administrador quiero crear zonas personalizadas para poder asignar mejor los pedidos.
● R15: Como administrador quiero poder ver el historial de pedidos y entregas según cliente y chofer para poder visualizarlos.
● R16: Como chofer quiero ver los pedidos entregados por mi para supervisar mi trabajo.
● R17: Como chofer quiero poder cerrar un pedido al entregarlo para cambiar su estado.
2.3.4. Requerimientos fuera del alcance pactado
● R18: Como chofer quiero ver un panel donde figuren mis pedidos pendientes de retirar o levantar para organizar mejor mi trabajo.
● R19: Como administrador quiero poder asignar un pedido o un retiro a un chofer con ruta en curso para poder incorporarlo al recorrido.
● R20: Como cliente quiero saber un estimativo de hora de entrega para poder estar presente para recibirlo.
● R21: Como administrador quiero poder asignarle un recorrido de entregas o retiro a un chofer para que realice su trabajo del día.
● R22: Como chofer quiero ver los pedidos geolocalizados en Google Maps™
para poder tomar alternativas.
● R23: Como administrador quiero ver al chofer en tiempo real directo en el mapa para poder supervisar.
● R24: Como tienda quiero integrar mi sistema para no ingresar los pedidos a mano.
● R25: Como chofer quiero saber los km gastos diarios para llevar un control de gastos.
● R26: Como administrador quiero recibir alertas cuando los productos no fueron entregados para notificar a los clientes.
● R27: Como chofer quiero escanear un pedido para que me arme la ruta.
● R28: Como administrador quiero notificar al cliente cuando un pedido no es realizado para que estén al tanto de todo.
2.3.5. Diagramas de flujo
En esta sección se presentan los procesos que se espera que los distintos actores del sistema realicen para poder llevar a cabo sus tareas o necesidades, esto
siempre fue comparado contra el proceso original de la empresa, para que éste facilitara, o permitiera al usuario realizar de forma más sencilla lo que realizaba antes, por la larga extensión de estos diagramas, serán presentados en los anexos.
En Anexo 2.3.5.1: Diagramas del proceso sin solución, podrá ver cómo los 3 distintos actores interactuaban con un abanico de herramientas para poder hacer solicitudes, sacar historiales o actualizar datos, además de que no había
mecanismos para facilitar esas tareas. En el Anexo 2.3.5.2: Diagramas del proceso con solución podrá ver cuáles son los procesos que se necesitan con la solución para poder resolver las necesidades de los 3 usuarios, no solo notando que tendrán muchas facilidades en relación a los procesos anteriores, sino que ahora tendrán también mecanismos de repetición, autocompletado, y otras técnicas que harán que la tarea sea más sencilla y más eficiente, tal y como se puede ver en Anexo 2.3.5.3:
Casos de uso, que muestra los casos de uso con cursos alternativos para crear pedidos, crear nuevos usuarios de tipo tienda, y cómo concretar un pedido.
2.3.6. Requerimientos no funcionales
Los requerimientos no funcionales que describe el product owner son los siguientes:
● RNF1: La solución debe ser sencilla de utilizar para todos los actores, puesto a que argumenta que la forma de solucionar sus problemas ya es compleja.
● RNF2: La solución debe poder ser ejecutada en computadoras con sistemas operativos basados en “Windows 7®+” o celulares basados en un sistema operativo “Android 6™+” con conexión a internet.
● RNF3: La solución debe presentar una tasa de errores inferior al 5%. Es decir, que al menos un 95% de las acciones deben dar resultados correctos.
● RNF4: Ninguna de las funciones debe tardar más de 1 minuto en ser ejecutada.
● RNF5: Los datos personales de todos los tipos de usuarios deben estar protegidos y encriptados en las bases de datos.
2.3.7. Carta de intención de desarrollo pactado
El equipo decidió implementar un documento donde se pacte el alcance propuesto en los requerimientos para evitar que existiera presión por parte del cliente en futuras reuniones y poder lograr un MVP simple y sencillo cuando se culmine el plazo, el mismo se encuentra en el Anexo 2.2.3: Carta conformidad de requerimientos.
2.3.8. Prioridad de requerimientos
A cada requerimiento se le asignó una prioridad que va desde el 0 (menos importante) al 10 (más importante), que refleja la necesidad del cliente en que esté incluida en el MVP del producto, se puede ver la prioridad de los requerimientos y su organización en la imagen 2.3.8: Prioridad de requerimientos.
Imagen 2.3.8: Prioridad de requerimientos
2.3.9. Evolución del Product Backlog
En el Anexo 2.3.9: Evolución del product backlog se puede ver cómo
evolucionó el proceso de los sprints en función de la evolución del proyecto contra lo planificado en la imagen 2.3.8: Prioridad de requerimientos, además se incluyeron las actividades que no habían sido planificadas, como la acción del login, tareas de conectar las capas del sistema, entre otros.
2.4. Manual de usuario
Para el desarrollo del manual de usuario, el equipo manejó varias técnicas, entre ellas, utilizar un estilo de “Manual documentado” con todas las acciones, o un
“Manual guía” con ejemplos, finalmente, el equipo optó por realizar un manual de usuario en video alojado en la nube de YouTube™ con el canal Tutoriales
EntregasUY, pues se consideró que sería un manual mucho más ameno, amigable, y tentador para mirar por parte del usuario.
En lo que respecta a manuales para el usuario se realizó un tutorial para los clientes, con el título Tutorial realización pedido EntregasUY, que muestra al usuario cómo realizar un pedido, como chequearlo o revisar sus pedidos, y al final cómo imprimir etiquetas con los datos del mismo. Para los choferes también se realizó un tutorial con el título Tutorial manejo de pedidos para choferes de EntregasUY donde les muestra cómo concretar pedidos y monitorear su historial de pedidos
concretados.
Para el administrador, que es el usuario con más funcionalidades se le realizaron cuatro videotutoriales, el primero Tutorial manejo clientes para
administradores de EntregasUY enseña al usuario a realizar las acciones básicas con los clientes, lo cual implica aceptar sus solicitudes de registro, ver sus datos, y actualizar sus contraseñas. El segundo, Tutorial manejo choferes para
administradores de EntregasUY enseña al usuario a realizar las acciones básicas con los choferes, lo cual implica registrarlos, ver sus datos, actualizar sus
contraseñas y comunicarse con ellos. El tercer videotutorial, Tutorial manejo de pedidos para Administradores de EntregasUY, el cual es el tutorial de mayor duración (en total 3 minutos y medio), pues implica ejemplos de cómo monitorear historiales de clientes y choferes, como ver los datos de sus pedidos, además, como
sacar un informe de Microsoft Excel™ con los pedidos del día. Finalmente el cuarto, Tutorial manejo de zonas personalizadas para administradores de EntregasUY enseña al administrador a crear zonas personalizadas, verlas y cómo manipularlas.
Finalmente hay dos tutoriales generales que enseñan a los usuarios a registrarse al sistemas en caso de ser clientes en el Tutorial de registro al sistema EntregasUY, y a ingresar al sistema y manejar los datos personales de la cuenta en Tutorial de Login a EntregasUY.
3. Diseño arquitectónico
3.1. Introducción
En este capítulo se explican las decisiones tecnológicas que se tomaron y se detalla la arquitectura de la solución.
3.2. Análisis de requerimientos no funcionales
● RNF 1: Para que la solución sea sencilla de utilizar para todos los actores, el equipo planea aferrarse a las heurísticas de Nielsen.
● RNF 2: En este requerimiento el equipo entiende que la API a crear debe de ser responsiva hacia los dispositivos y sistemas operativos requeridos. Para este caso, se utilizó Angular™, CSS™ y Bootstrap™ como herramientas para resolver dicho requerimiento.
● RNF 3: Se entiende que una buena selección de solución de dominio resuelve gran parte de los problemas de funcionamiento, pero por otro lado el equipo utilizará AWS™ para asegurarse que el acceso a datos esté siempre
disponible y pueda enfrentarse a posibles ataques de forma estable.
● RNF 4: Este requerimiento viene de la mano con las soluciones arquitectónicas de deploy, Heroku™ y Netlify™ presentan servidores
gratuitos, pero creemos que capaz no cumplan con la expectativa de tiempo en las ejecuciones.
● RNF5: El requerimiento de seguridad no fue cumplido pues, aunque el equipo entiende que es un aspecto importante, el representante del cliente no lo vio como algo a priorizar, por lo que las actividades de encriptación quedaron planificadas para futuras liberaciones, pero no fueron actividades dentro del alcance para el MVP.
3.3. Decisiones de diseño
● Para facilitar la extensión a futuros clientes, el equipo decidió extender el dominio para no acoplarse a la realidad de un solo cliente. De esta forma cumple OCP(Open closed principle)[3], [5].
● Para realizar la lógica de negocio el equipo utilizó el método Strategy[3] y de esta forma se pudieron realizar cambios de estrategias fácilmente, en caso de que cambien las formas de enviar pedidos o de realizar los ingresos.
● Para la buena legibilidad del código y fácil mantenimiento se mantendrán los lineamientos de Clean Code[1].
● Se siguió SRP (Single Responsability Principle)[3] tanto en clases del
backend como del frontend, para que cada bloque tenga una única razón de ser y una única razón de cambiar.
● Las clases del backend cumplen con DIP (Dependency Inversion Principle)[3]
donde las clases no dependen de concreciones, sino de contratos, y a su vez, éstos contratos procuran seguir ISP (Interface Segregation Principle)[3] donde cada contrato intenta tener la menor cantidad de términos posibles, para evitar dependencias innecesarias.
● Tal y como se puede ver en el Capítulo 4: Gestión de Calidad, Sección 6.2 Evolución y análisis de métrica de producto, gracias a la aplicación de
inversión de dependencias la solución obtuvo una buena relación abstracción inestabilidad, por lo que se cumple con los principios SAP y SDP
(abstracciones y dependencias estables)[3].
3.4. Herramientas y tecnologías de desarrollo
En esta sección se explican cuáles fueron las tecnologías que se
implementaron y sobre qué entornos fueron desarrolladas para poder ofrecer la solución. Seguido de esto se justifica el motivo por el cual el equipo seleccionó cada una de ellas.
3.4.1. Listado de herramientas y tecnologías
3.4.1.1. Tecnologías Implementadas
Para la solución se evaluaron tecnologías ya existentes, con el objetivo de aprovechar los dispositivos con los que EntregasUY™ ya contaba, y evitar la necesidad de dedicarle tiempo y recursos a problemas ya resueltos.
Entre estos problemas, se destaca el uso de Amazon RDS™ como motor de bases de datos para solucionar la disponibilidad y velocidad de la base de datos.
Cabe destacar que AWS™ ofrece 12 meses gratuitos de alojamiento de base de datos.
Además, a falta de un servidor en la compañía EntregasUY™, el equipo utilizó un hosting para que la API planteada pueda dar respuesta en tiempo real a los
equipos que realizan las solicitudes, para eso se decidió utilizar Heroku™ como hosting del backend y Netlify™ para el frontend, principalmente por brindar servicios gratuitos, compatibles con las tecnologías seleccionadas.
3.4.1.2. Web service
Luego de analizar las opciones, el equipo decidió que una buena solución a los problemas de EntregasUY™ sería ofrecer un web service donde pudieran interactuar los 3 actores principales del proyecto planteados en 2.3.2. Actores del sistema, donde las tiendas pudieran efectuar sus pedidos, los choferes pudieran corroborarlos para efectuarlos y el administrador pueda realizar mediciones y estudios de los pedidos de una tienda y del desempeño de un chofer.
Ésta capa de servicios fue implementada en C#™ utilizando el framework de ASP.NET Core™.
3.4.1.3. Interfaz
Siempre con un foco en la usabilidad y la aplicación de las heurísticas de Nielsen[2], el objetivo del equipo fue construir una interfaz amigable para el usuario, efectuando pruebas de forma recurrente contra el product owner, para que éste aportara su punto de vista respecto a la facilidad de uso, implementándolo en el framework de Angular™.
3.4.1.4. Base de datos
Para administrar los datos referentes a los pedidos y otras actividades de la compañía, el equipo realizó un modelo lógico de datos (Modelo Entidad-Relación)[6], el consecuente pasaje a tablas e implementarlo en MySQL™ utilizando la
herramienta MySQL Workbench™. Esta será hospedada en AWS™ en el servicio de
Amazon RDS™, se puede visualizar la estructura de las tablas en el Anexo 3.4.1.4:
MER.
3.4.1.5. Entorno de desarrollo
Para el entorno de desarrollo el equipo optó por utilizar la herramienta Visual Studio Code™.
3.4.1.6. Control de versiones
Para el control de versiones y repositorio el equipo decidió utilizar un repositorio en GitHub™ y manejarlo con su interfaz nativa, GitHub Desktop™.
A su vez se implementa la herramienta Docker™ para la creación de
imágenes de versiones estables y poder ejecutarlas fácilmente, independizando al proyecto de la configuración del equipo.
3.4.2. Justificación de herramientas y tecnologías
En esta sección se explica el motivo por el cual se seleccionó cada una de las tecnologías plasmadas en la sección anterior, es importante destacar que en este aspecto hubo una importante limitante, la cual se dio ante la indisponibilidad de recursos económicos, el cliente no está dispuesto a dedicar efectivo para la realización del proyecto, por lo cual las herramientas que seleccionamos se ven limitadas a versiones gratuitas.
Y aunque siempre el equipo discutió e investigó respecto a cuáles tecnologías podrían ser las más eficientes y compatibles para la solución, en algunas ocasiones, particularmente en las que no se encontraba ninguna justificación
negativa, se eligieron las herramientas sobre las que los integrantes ya tenían experiencia.
3.4.2.1. Tecnologías implementadas
El equipo eligió utilizar los servicios de AWS™ para el uso de bases de datos porque entiende que esta empresa es un gigante tecnológico a nivel mundial,
prestando servicio a miles de compañías con una baja tasa de errores, además de
ofrecer un buen manejo del consumo, simplicidad y seguridad, además de un uso gratuito de 12 meses de sus servicios de Amazon RDS™.
Por otro lado, las tecnologías de Heroku™ y Netlify™ ofrecen de manera totalmente gratuita el hosting de servicios, facilitando el problema de recursos, cabe destacar que dichas aplicaciones ofrecen una integración sencilla del código a través de contenedores de imágenes o mediante el código publicado en un repositorio Github™, facilitando además la integración continua, y la fácil entrega del código.
3.4.2.2. Web service
El equipo decidió integrar tecnologías con el lenguaje C#™ en el framework ASP.NET Core™ debido a su alta compatibilidad con herramientas al día de hoy, es un lenguaje muy documentado por la empresa que le da soporte y muchos
independientes, se estima que se encontrarán ejemplos de soluciones para un amplio espectro de problemas.
3.4.2.3. Interfaz
Para la implementación de las funcionalidades del web service mencionado anteriormente, el equipo optó por utilizar el framework de Angular™ basado en las experiencias de los integrantes, siempre con el foco en facilitar el trabajo de los actores del sistema. Para poder mejorar la calidad y el aspecto de esta parte, se utilizaron varias librerías de terceros para HTML™ y CSS™, entre ellas Bootstrap™, y FontAwesome™.
3.4.2.4. Base de datos
Para la gestión de los datos, ante el bajo flujo de consultas de una pequeña empresa local, el equipo entiende que administrarlos con una base de datos en MySQL™ es lo más práctico.
3.4.2.5. Entorno de desarrollo
El motivo por el cual el equipo decidió utilizar un IDE como Visual Studio Code™ es porque es una herramienta tan básica como potente. La herramienta es compatible con una amplia gama de lenguajes de programación, admite la
instalación de diversas extensiones, y es capaz de satisfacer todas las necesidades para el desarrollo de un proyecto de este nivel.
3.4.2.6. Control de versiones
Para la gestión del repositorio y parte del versionado, el equipo optó por el abanico de herramientas de GitHub™, ya que es una herramienta muy utilizada hoy en día por muchos proyectos, por lo cual se pueden encontrar herramientas de terceros que estén publicadas para aportar más a la solución, además de ser una herramienta muy estable y con buena reputación.
Para el resto de los controles de versiones se implementaron imágenes de Docker con un tag correspondiente al día de construcción de esta “ddMMyyyy”.
3.5. Arquitectura de deploy
En esta sección se presentará los componentes que comprenden la arquitectura del deploy hecho por el equipo.
3.5.1. Backend
Para el deploy del backend en un inicio el equipo pensó en utilizar la
herramienta Amazon EC2™ que brinda de forma gratuita y de por vida una instancia de máquina virtual, con capacidad de hasta 1.000.000 millón de consultas
mensuales. Esto fue descartado posteriormente debido a que la curva de aprendizaje de utilizar las herramientas de Amazon EC2™ eran muy grandes y demandaban mucho tiempo.
Como alternativa se utilizó Heroku™ que proveía una solución tan sencilla, que con simplemente indicar una rama del proyecto en nuestro repositorio GitHub™, este sería compilado y puesto a disposición en un URL publicado para ser utilizado como nexo entre el frontend y las bases de datos permitiendo una comunicación fluida de las funciones de la solución.
Se utilizaron contenedores de imágenes de Docker™, donde cada 2 semanas se actualizan, quedando disponibles los nuevos cambios.
3.5.2. Frontend
Para el frontend, Heroku™ no soporta el framework Angular™ utilizado, por lo que el equipo necesitó otra herramienta que lo permitiera. De esta manera se
concluyó que lo mejor sería utilizar Netlify™, orientada a lenguajes de frontend y facilidad de hostear dichas aplicaciones.
Netlify™ tiene una versión gratuita que permite de por vida publicar una aplicación frontend, resolviendo la problemática del proyecto. Funciona igual que Heroku™, solamente que no tiene soporte de Imágenes de Docker™, por lo que tuvimos que indicar de qué rama debía de obtener el código a compilar para hostear.
3.5.3. Diagrama de deploy
En el diagrama presentado en la Imagen 3.5.3.1: Arquitectura de deploy se puede observar cómo interactúan las componentes de la arquitectura a grandes rasgos.
Imagen 3.5.3.1: Arquitectura de deploy
3.6. Vistas
En esta sección se presentará la estructura a nivel arquitectónico de la solución propuesta, con mayor nivel de detalle en algunas funciones cruciales para mostrar el flujo comunicativo entre las capas del sistema.
3.6.1. Estructura del proyecto
Tal y como se puede apreciar en la imagen 3.6.1.1: Diagrama de paquetes de EntregasUY[9], la solución está basada en una estructura de microservicios, donde una capa de frontend se encarga de presentar las funcionalidades disponibles y las respuestas que provienen de una capa que expone los servicios de un backend.
Imagen 3.6.1.1: Diagrama de paquetes de EntregasUY
El backend, conformado por 3 capas generales, donde una capa sería la responsable del manejo de datos (Acceso a Datos), otra capa del manejo de los dominios y problemas del negocio (Negocio), y la última, la capa de presentación de servicios (Servicios).
Cada capa del backend al igual que la capa del frontend, tienen un conjunto de paquetes con responsabilidades más específicas.
En la capa de frontend se tiene un paquete que se encarga de manejar todas las vistas con las que interactúan los usuarios, y es la encargada de mostrar y
solicitar los servicios del sistema, este paquete es el de “Components”; luego el paquete “Models” se encarga de manejar las definiciones de la capa de servicios en el frente; y el paquete “Services” es el encargado de realizar peticiones a la capa de servicios.
En la capa de acceso a datos además del subpaquete de contexto, el cual define los parámetros de creación de las bases de datos en función de los objetos del dominio utilizando la Fluent API de Entity Framework™, se tiene el paquete de acceso a datos, el cual es el encargado de hacer las operaciones sobre los datos, implementando los contratos que definen las interfaces del paquete de interfaces del acceso a datos.
Al igual que el último paquete mencionado, y como se comentó en la Sección 3 de éste mismo capítulo, los paquetes de validación y lógica de negocio, son los encargados de satisfacer las necesidades del mismo y ejecutar sus reglas, también implementan contratos definidos por interfaces, y para las acciones más complejas de esos contratos, se tiene una serie de métodos privados para modularizar el
código, y adherirse más a los lineamientos de un código limpio[1]. Finalmente, dentro de esta capa está incluido el paquete de dominio, el cual define los conceptos que maneja la compañía y que se planea resolver con la solución.
Finalmente, en la capa de servicios, el paquete “Controller” es el encargado de responder a las peticiones del usuario con funcionalidades de la lógica,
manejando errores de la forma que se definen en el paquete “Filters” con modelos de datos idénticos a los de la capa de aplicación en el paquete “Models”.
3.6.2. Vistas de comportamiento
Tal y como se puede apreciar en los diagramas del Anexo 3.6.1: Diagramas de vistas[9], el sistema ofrece una serie de funcionalidades, altamente conexas y navegables.
Se definieron diagramas de comunicación para algunos servicios importantes del sistema en Anexo 3.6.2: Diagramas de interacción[9], para poder reflejar mejor el flujo de comunicación del mismo. En el Anexo 3.6.2.1: Interacción login se puede visualizar cómo se realizó la identificación de cada tipo de usuario, desde que el
usuario ingresa sus credenciales, hasta que se inserta la sesión en el repositorio del tipo de usuario que ingresó credenciales, con la comunicación de todas las capas intermedias en dicho proceso, además al final también se incluye el error resultante de que las credenciales no sean correctas. Se realizó algo similar en el Anexo 3.6.2.2: Interacción solicitud pedido, donde se muestra el proceso por el cual se realiza por parte de un cliente la solicitud de un pedido y en el Anexo 3.6.2.3:
Interacción realización pedido muestra el proceso para que el chofer finalice un pedido. De la misma forma que se hizo para los pedidos, en el Anexo 3.6.2.4:
Interacción solicitud registro se muestra el proceso para solicitar registro en el
sistema y en el Anexo 3.6.2.5: Interacción aprobación registro se muestra el proceso para la aprobación de un registro por parte de un usuario administrativo.
3.6.3. Diagrama de entidades
Finalmente, para cerrar esta sección y presentar las clases de los paquetes presentados en la subsección 3.6.1. Estructura del proyecto.
Primeramente se presenta en la Imagen 3.6.3.1 Diagrama final de clases del dominio[7], el diagrama final en el que resultó el paquete dominio, que si se lo compara con el inicial presentado en Anexo 3.6.3.1: Diagrama UML inicial de clases del dominio[9], se nota gran estabilidad, la principal diferencia radica en cómo se manejaron las zonas personalizadas y las rutas, ya que el diagrama final agrega sólo dos nuevos objetos “Coordenada” y “CódigoPostal”. Además, por datos que fueron surgiendo en los feedbacks del cliente, se reveló información necesaria de los clientes y de los pedidos.
Imagen 3.6.3.1 Diagrama Final de Clases del Dominio
Además, en el Anexo 3.6.3.2: Diagrama UML acceso a datos[9] se pueden visualizar las clases y métodos del paquete de acceso a datos, en el Anexo 3.6.3.3:
Diagrama UML capa de negocios[9] las clases y métodos del paquete de lógica del negocio, muy relacionado con el diagrama del Anexo 3.6.3.4: Diagrama UML validadores[9] donde se verán las clases y métodos del paquete de validaciones, éstos diagramas se plantearon al inicio, y sus principales cambios fueron la
incorporación de nuevos métodos privados para resolver los problemas complejos en forma modular, más allá de eso, se mantuvieron bastante estables, es por eso que no se presentan como en el caso del dominio, un comparativo de diagramas iniciales contra diagramas finales.
3.7. Especificación de API
3.7.1. Criterios para cumplir con API REST
Se utilizaron únicamente los verbos HTTP (PUT, POST, GET, DELETE) para los distintos recursos y con códigos de respuesta ya establecidos (como 200, 201, 400, 403, 404).
● La URL base es lo más simple posible.
● Los endpoints tienen nombres concretos y están en plural.
● Las solicitudes no tienen estado.
● Todos los endpoint no pasan 3 niveles de profundidad.
● Todos los servicios son simples y consistentes. Por ejemplo, si se le pide que retorne una lista está devuelve los objetos que corresponden.
● En ningún momento utilizamos alguna solicitud que no cumpla REST.
Para conocer respecto a los mecanismos de autenticación y el manejo general de los códigos de error, dirigirse al Anexo 3.7.1.1: Mecanismos de autenticación y Anexo 3.7.1.2: Manejo general de los códigos de la API.
3.7.2. Especificaciones de los recursos
En esta sección se presentan los recursos expuestos por la API de la solución, separados por cada área de interés de los mismos. Por motivos de su extensión y formato específico, éstos se presentan en el Anexo 3.7.2:
Especificaciones de recursos, donde los recursos para los clientes, choferes,
administradores, zonas y pedidos, se presentan en Anexo 3.7.2.1: Recursos clientes, Anexo 3.7.2.2: Recursos choferes, Anexo 3.7.2.3: Recursos administrador, Anexo 3.7.2.4: Recursos zonas personalizadas, y Anexo 3.7.2.5: Recursos pedidos, respectivamente.
4. Gestión de la calidad
4.1. Introducción
En esta sección se explicará cuáles son los objetivos, las técnicas y las métricas para evaluar la calidad, tanto en la ejecución del proceso de este proyecto, como en el producto resultante del mismo.
4.2. Objetivos
El proceso de este proyecto tiene como objetivos:
● Los requerimientos planteados dentro del alcance deben lograr desarrollarse en los tiempos planificados.
● Debe haber al menos un 90% de cobertura de código realizado probado.
● No debe haber liberaciones no funcionales.
● Se debe realizar una liberación cada 2 semanas.
● Todas las actividades realizadas deben ser documentadas según el formato presentado en el documento 302 por la Universidad ORT.
El producto final, fruto de este proyecto, tiene como objetivos:
● Ofrecer una solución integral para un amplio abanico de problemas que necesita resolver el cliente.
● Utilizar las técnicas de gestión y desarrollo aprendidas a lo largo de la carrera y aplicarlas a un entorno real.
● Aprender el uso de nuevas tecnologías e incorporación de soluciones a medida bajo demanda.
● Obtención del título “Licenciado/a en Sistemas”.
4.3. Aseguramiento de la calidad (SQA)
Para asegurar la calidad del proceso, el equipo tuvo que definir ciertos
estándares básicos para evaluar objetivamente las decisiones que podían tomar, con el foco en evitar los desperdicios y reducir costos, en parte por lo planteado en el Capítulo 3, Sección 4.2 Justificación de herramientas y tecnologías, que los fondos
para este proyecto son escasos. Una vez definidos estos conceptos, el equipo podría comenzar a mejorar de forma continua, entregando a los actores de EntregasUY™ una solución que consideren “buena”.
4.4. Principales actividades de SQA
En esta sección se definen los conceptos de calidad en los cuales los
integrantes del equipo se centraron para poder decir que la solución ofrecida era “de calidad” y cómo hicieron para validarlas.
4.4.1. Definición de estándares
● Mediante el uso de la técnica TDD[8] en todas las iteraciones del desarrollo, el equipo apunta a tener una solución con un menor número de errores, y poder enfocarse en los requisitos concretos.
● Mediante la incorporación de un Código limpio[1] el equipo espera tener un código más sencillo de comprender, resultando en un sistema más
mantenible.
● Mediante el modelado de la solución con Diagramas UML 2.5[7] se espera poder tener un diseño detallado de la solución de alto nivel, que dará lugar a que el desarrollo sea más sencillo, minimizando errores.
● Mediante el uso de principios de diseño de software[3], el equipo espera tener un sistema de mejor calidad, con mayor estabilidad, abierto al cambio.
● Patrones de diseño[3]
4.4.2. Pruebas de concepto de tecnologías
● El tiempo medio de respuesta de consulta es un aspecto importante, ya que, si el sistema tarda demasiado en ofrecer una respuesta, resultará siendo poco eficaz.
● La estabilidad es otro aspecto importante, ya que, si el sistema está caído la mayoría del tiempo, resultará siendo poco eficiente.
4.4.3. Testing
● Caja Blanca
○ TDD[8] para la cobertura automatizada de cada una de las componentes desarrolladas en la API.
● Caja Negra
○ Pruebas funcionales para evaluar que las piezas trabajen de forma correcta en conjunto, centrándose en casos bordes.
○ Pruebas exploratorias para evaluar el comportamiento en estados esperados del sistema.
4.5. Definición de métricas
En esta sección se definen las métricas que el equipo planteó para poder evaluar de forma más empírica que tanto se cumplieron los objetivos de calidad, y que tan acertadas fueron las tecnologías seleccionadas.
4.5.1. Introducción
Para esta sección, se separarán las métricas que fueron aplicadas en el proceso, en el producto y en el proyecto, para poder tener un vistazo más claro de cómo el equipo evaluó cada componente del proyecto.
4.5.2. Métricas de proceso
● Ajuste al calendario
● Horas de trabajo por tarea
● Metodología constante
● Horas de planificación
4.5.3. Métricas de producto
● Abstracción de las clases
● Inestabilidad de las clases
● Cohesión relacional entre clases
● Cobertura de código
4.6. Evolución y análisis de métrica
Para medir el progreso del proyecto y tener una planificación, el equipo optó por realizar un diagrama de GANTT con un plan de cómo avanzar en el proyecto, con responsabilidades definidas, y con las tareas separadas por fases del proyecto, desde la fase pre-inicial que implicó la selección del proyecto, continuada por una fase inicial donde el equipo definió el problema, seleccionó las tecnologías estudió los posibles riesgos y las nuevas tecnologías que deberían aprender a manejar los integrantes para llevarlo a cabo, una validación contra el cliente, entre otras
actividades, este diagrama inicial se puede ver en el Anexo 4.6.1: Planificación Inicial GANTT.
A medida que se avanzó en el proyecto, algunas tareas se desviaron de la planificación, por problemas de estimación, falta de conocimiento en el área, malinterpretar algo expresado por el cliente, entre otras cuestiones, que llevaron a reajustar los tiempos, volver a planificar las actividades, resultando en el diagrama final que es a modo de histórico en lugar de planificación futura, y se puede apreciar en el Anexo 4.6.2: GANTT Final.
4.6.1. Proceso
Si se comparan los diagramas, se puede ver que hubo un atraso en la
definición del plan de comunicación y del plan de calidad, esto se debió a que el plan inicial suponía en la fase 1 muchas actividades en paralelo que fueron
subestimadas, como la identificación de riesgos; además, cuando se definieron las metodologías, se seleccionó la técnica de CCC[4] tal y como se explicó en el Capítulo 2: Ingeniería de requerimientos, Sección 2: Proceso de ingeniería de requerimientos, lo que requirió capacitar al cliente. Por otra parte, las tareas de capacitación en las nuevas tecnologías y validarlas llevó un tiempo que requería el registro de AWS™, que requirió una solicitud de una tarjeta bancaria de crédito, que en este caso utilizamos una tarjeta prepaga de crédito Alfabrou™, pero dichas solicitudes llevaron tiempo, por lo que el equipo aprovechó ese tiempo para llevar a cabo la fase 2.
Con lo que respecta a la segunda fase del proyecto, el equipo creyó oportuno comenzar a configurar los ambientes de las tecnologías definidas a medida que se llevaba a cabo el diseño de la solución presentado en el Capítulo 3: Diseño
arquitectónico, lo cual adelantó los ambientes y atrasó el diseño, sin salir de las fechas estimadas para esta fase.
En la tercera etapa del proyecto se puede apreciar la planificación para el desarrollo que llevó el total planificado de 5 sprints de la metodología empleada explicada en el Capítulo 6: Gestión del Proyecto, Sección 3: Metodología del proceso de construcción de software, pero por motivos de vacaciones, el equipo decidió atrasar una semana la finalización de ésta fase, y adelantarla, mientras se terminaba de diseñar algunos aspectos de la arquitectura, para poder tener 2 semanas de vacaciones en las semanas desde el 20 de diciembre hasta la semana del 27 de diciembre, fechas entre las cuales se incluía navidad y año nuevo.
Ésta decisión de retrasar la tercera fase del proyecto, evidentemente atrasó la cuarta, semanas entre las cuales se ejecutaron el set de pruebas funcionales y pruebas con el cliente, que sacaron a la luz algunos arreglos que el equipo consideró que rápidamente podían resolverlos, considerados como “horas de retrabajo
dedicadas al desarrollo”.
Finalmente, la fase de documentación fue una fase que se extendió desde el inicio hasta el final del proyecto, ya que desde el inicio el equipo intenta llevar una documentación concisa del trabajo que fue realizando, para evitar el desorden al final. La fecha de entrega de los diagramas fue colocada cerca de un mes antes de la fecha real de entrega del proyecto, para tener tiempo de presentar la
documentación al tutor, y obtener comentarios para mejorarla.
El equipo no considera que las 3 desviaciones de la planificación hubieran afectado negativamente al proyecto, ya que la metodología seleccionada supone ajustarse sobre la marcha.
Utilizando la herramienta Toggl™ el equipo pudo medir que las horas de desarrollo estuvieron sobre las 260 horas, tal y como se puede apreciar en la imagen 4.6.1.1: Horas de desarrollo, que si las dividimos en el tiempo de la fase de
desarrollo (10 semanas de 5 días), obtendremos que la dedicación de los integrantes fue de, en promedio, 5.2 horas diarias.
Imagen 4.6.1.1: Horas de desarrollo
Por otra parte, el equipo dedicó un total de 110 horas hombre (55 por integrante) tal y como se puede apreciar en la imagen 4.6.2.1: Horas de planificación a la planificación del proyecto, en reuniones, ya fueran éstas entre integrantes del equipo, con el tutor, o con el cliente.
Imagen 4.6.1.2: Horas de planificación
Finalmente, el equipo además dedicó un total de 110 horas hombre (55 por integrante) tal y como se puede apreciar en la Imagen 4.6.1.3: Horas de documentación a la documentación de las actividades del proyecto, a priori, sin incluir las horas de reajustes posteriores a la revisión por parte del tutor.
Imagen 4.6.1.3: Horas de documentación
Resultando así en un proyecto que llevó un total de 480 horas de trabajo desde la fase 1, previo a la definición de tecnologías, hubieron más horas de trabajo desde fines de agosto en la extensión de la fase 0 y parte de la fase 1, estas horas fueron registradas utilizando la herramienta Google Calendar™, para lo cual se llegaron a registrar 40 horas de trabajo, que se
