Es por esto que nace BlueDepot, un sistema de gestión de almacenes (WMS) lite, un sistema de gestión de almacenes en versión lite, con las funcionalidades críticas para gestionar y controlar las operaciones de un almacén, ubicado en la nube y a un coste reducido. buscando de esta manera atacar el sector de la industria que ha sido descuidado. Es un software dirigido al sector logístico específico que se centra en facilitar y mejorar las funciones básicas del almacén.
Indice
1.1 ¿Cómo surge el proyecto?
Objetivos
OP2: Entregar un producto funcional, listo para la venta y uso por parte del cliente adecuado, que contenga al menos el 80% de la funcionalidad acordada con nuestro cliente 4i. OP4: Entregar al cliente un producto terminado que no contenga errores en las funcionalidades críticas del sistema.
Entorno conceptual de Software Factory
Descripción del equipo
Estructura del documento
Esta sección describe los objetivos que el equipo se marcó con el objetivo de asegurar la calidad del proyecto. En este apartado el equipo presenta las conclusiones del proyecto ya realizado, el cumplimiento de los objetivos previamente propuestos y los aprendizajes y lecciones aprendidas por el equipo.
Contexto
Asesorar a sus clientes sobre estos sistemas y ofrecer servicios de consultoría dentro del sector logístico les permitió inevitablemente convertirse en expertos en este campo y afrontar diversos retos en la cadena de actividades logísticas. Pudieron determinar que las mayores deficiencias se encuentran en la gestión interna de los almacenes.
Introducción a la industria
El último actor es el operario, que es el encargado de realizar y realizar gran parte de las tareas del almacén. Finalmente, la última etapa del flujo es cuando la mercancía sale del almacén.
Problemas identificados
Ver Apéndice 12.1 Precios de WMS para ver análisis y diferentes costos sobre WMS ofrecidos en el mercado. Se pueden encontrar más ejemplos de interfaces obsoletas en el Apéndice 12.10 Interfaces WMS existentes.
Solución propuesta
Para abordar el problema P1 de dificultades on-premise, el problema P3 de complejidad y el problema P2 de altos costos de los WMS actuales, se propone realizar un WMS Lite en la nube que incluya solo las funcionalidades que los clientes consideran críticas para su funcionamiento. . . El costo de comenzar a utilizar la plataforma se reducirá, ya que al estar en línea y ubicada en la nube, no requiere instalaciones y lo único que los usuarios deben hacer para comenzar a utilizarla es registrarse y esperar la aprobación de los clientes.
Principales funcionalidades
Cuando se arma un pedido, el sistema se encargará de analizar qué caja de Gatorades se debe enviar primero, dependiendo de la regla de salida asociada a ese producto. En este caso, la regla para retirar la caja de Gatorades puede ser retirar la más cercana a su vencimiento, por lo que el sistema debe informar al operador en qué estante se encuentra almacenada la caja de Gatorade más cercana a su vencimiento.
Alcance del proyecto
Dependiendo del tamaño de algunos repositorios y los posibles problemas de conectividad que puedan ocurrir, el sistema podrá realizar algunas funciones sin conexión, generando un uso continuo de la web incluso si el usuario pierde la conexión a Internet. En este apartado se explican las características del proyecto y del cliente que motivaron la elección de la metodología de trabajo.
Características del proyecto
Por otro lado, era importante considerar que el cliente detrás del proyecto estaba formado por dos personas, lo que podía resultar riesgoso. Un pequeño error en la comprensión del dominio significaría cambios en el futuro del proyecto.
Características del equipo
Contamos con expertos como mentores y referentes en los desafíos presentados, que participaron en reducir errores y asegurar la calidad de los resultados. Como se mencionó en el capítulo 4.1 Características del proyecto, el cliente no contaba con conocimientos técnicos, lo que resultó ser un desafío y a la vez una gran ventaja.
Metodología de trabajo
Cabe señalar que no todas las ceremonias se aplicaron estrictamente de la manera que sugiere SCRUM. Se decidió adaptar algunas de las ceremonias para sacarles el máximo provecho y se adaptaron a las características del proyecto en cuestión.
Ceremonias
Este método de estimación y la ejecución de la ceremonia se explican con más detalle en la sección 7.3.1 Iteraciones de planificación. Esta ceremonia y la aplicación de la técnica “Iniciar, Parar, Continuar” se explican con más detalle en la sección 7.3.3 Evaluación de las iteraciones.
Artefactos
Tareas pendientes: en esta columna se encuentran aquellas tareas que esperan ser iniciadas, pero que deben completarse en el sprint actual. Revisión: En esta columna estarán aquellas tareas que se han desarrollado pero aún están esperando ser revisadas y aprobadas.
Ciclo de vida
Roles del equipo
Proceso
A medida que avanzaba el proyecto, el equipo se encargó de validar los resultados con el cliente. De todas formas, como parte del proceso de validación, el equipo visitó un almacén donde pudieron comparar lo desarrollado con el mundo físico y real de la industria.
Funcionalidades
Esta regla permitirá que los artículos se retiren del almacén en orden de llegada y se basa en la fecha en que se recibieron los artículos en el almacén. El sistema ofrecerá la posibilidad de visualizar el stock disponible de cada uno de los productos, independientemente de aquellos que se encuentren en posición de espera o envío.
Requerimientos no funcionales
El sistema debe bloquear la cuenta del usuario después de 10 intentos de inicio de sesión. El sistema debe solicitar confirmación a los usuarios que se encuentran en el sistema antes de iniciar sesión.
Restricciones
Conclusiones y lecciones aprendidas
Se debe lograr una cobertura de pruebas unitarias de al menos el 70% en el código de funcionalidades críticas. A su vez, la comunicación durante el desarrollo permitió el constante intercambio de opiniones y la detección de errores en el producto por parte del cliente.
Vistas de arquitectura
La clase Repositorio tiene estos métodos y es necesario indicar la entidad con la que se desea interactuar en la base de datos. Este módulo define la excepción que se utilizará para indicar un error en todos los microservicios.
Twelve Factor App
Es fundamental declarar y aislar dependencias; un proyecto nunca debe depender de la existencia explícita de paquetes instalados en el sistema. Un ejemplo de esto son las bases de datos, como se menciona en el principio de configuración, la dirección de la base de datos y los detalles de inicio de sesión necesarios se encuentran en los archivos de configuración. Si desea utilizar uno diferente, simplemente cambie la variable de configuración correspondiente.
Backend
Por otro lado, proporcionar un generador de migración, es decir, la capacidad de aplicar y revertir cambios en la estructura de la base de datos sin perder los datos existentes. Esto proporcionó la capacidad de realizar cambios controlados en la base de datos, con la capacidad de retroceder en caso de errores.
Frontend
Bootstrap es de gran tamaño y la mayoría de los componentes que ofrece probablemente no se utilicen en el sitio. La idea es que el operador sincronice la información del dispositivo antes de entrar al almacén y perder la conexión.
Infraestructura
S3 (Servicio de almacenamiento simple) es un servicio de almacenamiento de objetos en la nube proporcionado por AWS. Es un servicio en la nube sin servidor que permitió al equipo ejecutar código de forma automática y escalable por completo.
Atributos de calidad
Esta táctica implica garantizar que el usuario tenga los permisos necesarios para acceder o realizar cualquier acción en el sistema. La adaptabilidad está relacionada con los costos que implica implementar un cambio en el sistema.
Conclusiones y lecciones aprendidas
Este factor fue fundamental para el equipo, ya que no había miembros con experiencia en diseño. El equipo cree que la implementación continua podría haberse implementado antes en el proyecto.
Herramientas de gestión
Esta sección de la documentación describe cómo se gestionó el proyecto durante las tres etapas de descubrimiento, desarrollo y finalización. Se describen las estrategias y la implementación del método utilizado junto con la forma de trabajo del equipo.
Etapas
En este punto, el equipo estaba a cargo de investigar el dominio comercial y recopilar los requisitos. En la etapa final del proyecto, el equipo se centró en otros entregables que estaban dentro del alcance del proyecto, como la implementación de manuales y la preparación de documentación académica.
Aplicación de Scrum
Una vez que se seleccionaron y estimaron todas las tareas del sprint, esto se convirtió en el trabajo pendiente del sprint. En los sprints que el equipo consideró necesarios, la primera evaluación realizada al final del sprint fue la revisión del sprint.
Gestión de la documentación académica
Para estas reuniones, el equipo se reunió virtualmente la mayor parte del tiempo y se utilizó la técnica de retroalimentación "Empezar, detener, continuar". Luego, el supervisor revisó la sección nuevamente y agregó comentarios si era necesario, siguiendo así un proceso iterativo de retroalimentación en cada sección hasta obtener la mejor documentación académica posible.
Plan de releases
El primer plan generado se puede encontrar en el anexo 12.9 Plan de lanzamientos de Evolution, se planificaron un total de 4 lanzamientos. El equipo se quedó atrás en el sprint 5 antes de llegar al primer lanzamiento, ya que no se completaron todos los ABM y el progreso en el pedido no se consideró suficiente, por lo que se llegó a un acuerdo con el cliente para no generar esta versión vista en la fecha especificada.
Métricas de gestión
Por ello, partimos de estimaciones menos ambiciosas, que se fueron incrementando en el futuro, para buscar la velocidad óptima del equipo. En el último sprint se nota una disminución en la velocidad debido a un cambio en el esfuerzo frente a la documentación de la mayoría de los miembros del equipo.
Gestión de la comunicación
En cuanto a la comunicación interna entre los 5 miembros del equipo, se decidió utilizar principalmente dos herramientas: Discord y Whatsapp, cada una con un propósito diferente. Se creó un servidor "Tesis" en Discord y se creó para usar el canal de llamadas de audio y video para varios eventos como Sprint Planning y Sprint Retrospectives.
Gestión de riesgos
Acción de respuesta: se requiere mitigar el riesgo de la siguiente manera: escribiendo desde el inicio las funcionalidades clave acordadas con el cliente. Acción de respuesta: Buscamos mitigar el riesgo de la siguiente manera: confiar en estándares de desarrollo de UI reconocidos.
Protocolo de resolución de conflictos
Los conflictos moderados eran conflictos que, si bien no afectaban a todo el sistema, sí afectaban a una parte entera del mismo, como por ejemplo un cambio en la gestión de recepción de productos en un almacén. Finalmente, los conflictos menores eran conflictos que no afectaban a una parte importante del sistema, como un cambio menor en la interfaz de usuario.
Conclusiones y lecciones aprendidas
El equipo consideró conflictos críticos aquellos cuya decisión afectó a todo el sistema o a gran parte de él, como la decisión de cambiar el esquema de una tabla maestra en una base de datos. El equipo entendió la vitalidad de la comunicación para mantener el proyecto bajo control y evitar malentendidos.
Definición de calidad
Prácticas de aseguramiento de la calidad
En otros microservicios como productos y usuarios se logró una cobertura promedio del 46,7% de líneas, estas se comunican con otros microservicios para consultar la información necesaria en el flujo de pedidos. A lo largo del año se realizaron diversas demostraciones con clientes para validar el producto en desarrollo (ver anexo 12.32 Reuniones.
Métricas
En cualquier caso, el equipo cree que esto también puede deberse a la gran cantidad de código que se escribió en el frontend, lo que genera una mayor posibilidad de generar errores o detalles. Como se puede observar en los informes de microservicios del Anexo 12.16 de SonarQube, en todos los casos se mantuvo por debajo del 5%, lo cual es un valor aceptable según lo especificado en los requisitos no funcionales (RNF5.
Conclusiones y lecciones aprendidas
Por otro lado, el equipo cree que RNF13 podría haber sido más ambicioso y apuntado a una mayor cobertura. El equipo concluyó que la aplicación del proceso de calidad permitió obtener un producto de calidad que satisface las necesidades del cliente, como lo demuestran las validaciones realizadas.
Identificación de elementos de configuración
Léame de la biblioteca común de blue-depot-commons ● Notas resultantes de reuniones con el cliente ● Documento de especificaciones proporcionado por el cliente ● Informes de las 3 revisiones.
Herramientas utilizadas
Organización de los repositorios
Gestión de versiones
Las ramas principales fueron main y development, donde main era la rama principal y development era la rama de desarrollo en la que se integraban diversas funcionalidades. A medida que avanzaba el proyecto, a medida que el equipo se perfeccionó y ya se codificaron partes más grandes, las sucursales se redujeron en tamaño en términos de funcionalidad y compromiso.
Gestión de cambios
Se analizó qué impacto tendría en el proyecto teniendo en cuenta la etapa en la que se encontraba. Si se decidía seguir adelante, el camino dependía de si se trataba de una nueva funcionalidad o un error, su prioridad y la etapa en la que se encontraba. proyecto donde se descubrió la necesidad del cambio.
Documentación
Conclusiones y lecciones aprendidas
En cambio, el equipo se apegó al modelo de ramificación de Git Flow, ya que era en el que tenían mayor conocimiento y experiencia, y aunque permitía un desarrollo fluido, el equipo podría haber considerado otras estrategias de trabajo, como el Desarrollo Basado en Trunk. Al completar el proyecto, el equipo siente que podrían haber evaluado ambos flujos de trabajo, comparado sus ventajas y desventajas y tomado una decisión más informada sobre cuál sería la mejor opción para el proyecto.
Conclusiones generales
Análisis de Objetivos Planteados .1 Objetivos del producto
El equipo concluyó que el objetivo podría haberse determinado mejor, ya que no se tuvo en cuenta la anomalía positiva, como fue el caso. El objetivo era que el equipo utilizara al menos tres habilidades clave de desarrollo e ingeniería de software.
Próximos pasos
Precios WMS
Épicas
Quiero poder solicitar un conjunto de informes del sistema para poder ver las estadísticas. Quiero iniciar sesión para tener información de pronóstico para el día y estadísticas.
Maqueta WMS
Bocetos en Miró de diseño UI
Ejemplo de la página con diferentes tamaños de pantalla
Usabilidad
Ejemplos Vistas de Órdenes BlueDepot
