Ingeniería de Software FLASHBUY
Enviado por peperoni728 • 11 de Septiembre de 2022 • Biografías • 2.199 Palabras (9 Páginas) • 107 Visitas
Desarrollo del Sistema 1.0 | Agregar el logo |
Equipo de trabajo: Fidel Fernando Caicedo, Sofia Zapata, Esneider, Felipe Arredondo | Versión: 3.0 |
Universidad EAFIT
Departamento de Informática y Sistemas
Ingeniería de Software
FLASHBUY
Contenido
Sección 1. Generalidades del proyecto 3
1.1. Descripción del problema y su solución 3
1.2. User Story Map 3
Sección 2: Evaluación del Sprint 2 3
Sección 3: Sprint Backlog (Sprint 3) 3
Sección 4: Aspectos estructurales y arquitectónicos de la solución 3
4.1. Estilos Arquitectónicos 3
4.3. Vista conceptual 4
4.4. Vista lógica 4
4.5. Vista de implementación 5
4.6. Vista física 5
Sección 5: Principios de diseño 5
5.1. Principios SOLID 5
5.2. Patrones GRASP 5
5.3. Clean Code 6
Sección 6: Avances en cuanto a funcionalidad y demostración 6
Conclusiones y lecciones aprendidas 7
Referencias 7
Sección 1. Generalidades del proyecto
Descripción del problema y su solución
En muchas tiendas de barrio o tiendas de mediano tamaño al ofrecer precios tan buenos, económicos y baratos, se presenta entonces aglomeraciones, donde después se generan largas filas en las compras y a veces se puede perder el trackeo del inventario y en estas aglomeraciones, puede pasar un sinfín de problemas, Por eso nosotros ofrecemos una solución con nuestro Software Flashbuy, el cual es una aplicación con dos funciones más importantes, hacer un autocheck-in donde la persona puedo escanear el producto que esta comprado y pagarlo sin necesidad de un cajero y su segundo funcionamiento es el de Registro de Inventario de la tienda, de esa forma podemos crear una relación simbiótica en la cual al escanearse y pagarse un producto, este aparece reflejado su cambio en tiempo real en el inventario virtual de la tienda, así los dueños o administradores pueden ver en cualquier momento que cambios se están realizando en el sistema.
1.2. User Story Map
https://miro.com/app/board/uXjVOJ2AXl4=/
[pic 1]
Sección 2: Evaluación del Sprint 2
[pic 2]
Sección 3: Sprint Backlog (Sprint 3)
[pic 3]
(Link al Tablero: https://dev.azure.com/FidelCaicedo/FlashBuy/_workitems/recentlyupdated/)
[pic 4]
Sección 4: Aspectos estructurales y arquitectónicos de la solución
Estilos Arquitectónicos
Tipo Aplicación | Aplicación Web |
Estilo arquitectónico y descripción del estilo | Cliente/Servidor: es una arquitectura donde las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, quien le da respuesta. Esta idea también se puede aplicar a programas que se ejecutan sobre una sola computadora, aunque es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras. Modelo Vista Controlador (MVC): es un estilo que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. Se trata de un modelo muy maduro y que ha demostrado su validez a lo largo de los años en todo tipo de aplicaciones, y sobre multitud de lenguajes y plataformas de desarrollo. |
Lenguaje programación | JavaScript |
Aspectos técnicos | Hacemos uso de OAuth2 |
Frameworks | React |
- Atributos de Calidad
Eficiencia
- El sistema debe ser capaz de procesar N transacciones por segundo. Esto se medirá por medio de la herramienta aplicada al Software Testing de servicios web.
- Toda funcionalidad del sistema y transacción de venta debe responder al usuario en menos de 5 segundos.
- El sistema FLASHBUY debe ser capaz de operar adecuadamente con hasta 10.000 usuarios con sesiones concurrentes.
- Los datos modificados en la base de datos deben ser actualizados para todos los usuarios que acceden en menos de 2 segundos.
Seguridad lógica y de datos
- Los permisos de acceso al sistema podrán ser cambiados solamente por el administrador.
- Todas las comunicaciones externas entre servidores de datos, aplicación y cliente del sistema deben estar encriptadas utilizando el algoritmo RSA.
- Si se identifican ataques de seguridad o brecha del sistema, el mismo no continuará operando hasta ser desbloqueado por un administrador de seguridad.
Usabilidad
- El tiempo de aprendizaje del sistema por un usuario deberá ser menor a 30 min.
- La tasa de errores cometidos por el usuario deberá ser menor del 1% de las transacciones totales ejecutadas en el sistema.
- El sistema debe contar con manuales de usuario estructurados adecuadamente.
- El sistema debe proporcionar mensajes de error que sean informativos y orientados a usuario final.
- La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la adecuada visualización en múltiples computadores personales, dispositivos tableta y teléfonos inteligentes.
- El sistema debe poseer interfaces gráficas bien formadas y claras.
Dependibilidad
- El sistema de ventas debe tener una disponibilidad del 99,99% de las veces en que un usuario intente accederlo.
- El tiempo para iniciar o reiniciar el sistema no podrá ser mayor a 8 minutos.
- La tasa de tiempos de falla del sistema no podrá ser mayor al 0,5% del tiempo de operación total.
- La probabilidad de falla del Sistema no podrá ser mayor a 0,05.
Vista conceptual
[pic 5]
Eliminar Producto hace parte de la historia de usuario “Deseleccionar Producto”: Yo como comprador, necesito que la aplicación web permita quitar algún producto que haya registrado para poder cambiar mis decisiones de compra.
Realizar Pago hace parte de la historia de usuario “Generar Pago”: Yo como dueño de un negocio, necesito que la aplicación web genere pagos para que se puedan realizar compras desde allí.
Actualizar Inventario hace parte de la historia de usuario “Actualización de Inventario”: Yo como dueño de un negocio, necesito que la aplicación web actualice mi inventario en tiempo real para tener mejor control de mi negocio
...