Skip to content

Enunciado Proyecto

Jump to bottom
Blazutan edited this page Aug 19, 2026 · 2 revisions

Proyecto de curso: Sistema de Gestión de Pedidos — PoliRestaurante

Docente: Yamid Ramirez, MsC

1. Contexto

PoliRestaurante es un restaurante de comida rápida que atiende tanto en salón como para llevar. Actualmente, los pedidos se toman en papel, lo que genera errores de comunicación entre los meseros y la cocina, pérdida de tickets, demoras en la preparación y dificultad para saber en qué estado se encuentra cada pedido.

La administración del restaurante ha contratado a su equipo de desarrollo para construir un sistema de gestión de pedidos que digitalice este proceso, permitiendo que meseros, cocina y administración trabajen sobre la misma información en tiempo real.

Este proyecto debe desarrollarse cubriendo las cinco fases del ciclo de vida del software:

  1. Análisis
  2. Diseño
  3. Construcción
  4. Pruebas
  5. Despliegue

Cada fase tiene entregables obligatorios que se evalúan de forma independiente.

2. Objetivo general

Diseñar y construir un sistema web que permita gestionar el ciclo de vida de un pedido en PoliRestaurante, desde que el mesero lo toma hasta que se entrega al cliente, con visibilidad diferenciada según el rol del usuario.

3. Roles del sistema

Rol Descripción Acciones principales
Mesero Toma los pedidos en las mesas Crear pedido, agregar/quitar productos, asignar mesa, marcar como entregado
Cocina Prepara los pedidos Ver cola de pedidos pendientes, cambiar estado a "En preparación" y "Listo"
Administrador Gestiona el restaurante Gestionar menú (productos, precios, categorías), gestionar mesas, gestionar usuarios, ver reportes de ventas y tiempos de preparación

4. Flujo de estados del pedido

El ciclo principal de un pedido es:

PENDIENTE → EN PREPARACIÓN → LISTO → ENTREGADO
     ↓              ↓
     └──────────────┴──→ CANCELADO

Estados

  • Pendiente: el mesero acaba de crear el pedido; aún no lo ha visto cocina.
  • En preparación: cocina tomó el pedido y lo está preparando.
  • Listo: cocina terminó de preparar el pedido; está esperando a que el mesero lo recoja.
  • Entregado: el mesero llevó el pedido a la mesa o al cliente.
  • Cancelado: el pedido se anula. Por ejemplo, si el cliente se retira o existe un error en la toma del pedido.

Regla: Solo es posible cancelar un pedido si este no ha sido entregado.

Cada cambio de estado debe quedar registrado con marca de tiempo, para poder calcular posteriormente cuánto demora un pedido en cada etapa.

5. Entidades principales sugeridas

Usuario

  • id
  • nombre
  • rol
  • credenciales

Mesa

  • id
  • número
  • estado: libre / ocupada

Categoría

  • id
  • nombre

Ejemplos: Entradas, Platos fuertes, Bebidas, Postres.

Producto

  • id
  • nombre
  • descripción
  • precio
  • categoría
  • disponibilidad

Pedido

  • id
  • mesa
  • mesero
  • estado
  • fecha_creación
  • fecha_última_actualización

DetallePedido

  • id
  • pedido
  • producto
  • cantidad
  • notas

Ejemplo de nota:

"Sin cebolla"

HistorialEstado

  • id
  • pedido
  • estado
  • fecha
  • usuario_que_cambió

6. Entregables por fase

Fase 1 — Análisis

  • Documento de requerimientos funcionales y no funcionales.
  • Historias de usuario con criterios de aceptación.
    • Mínimo: 8 historias de usuario.
    • Deben cubrir los 3 roles del sistema.
  • Diagrama relacional.
  • Diagrama de clases de arquitectura.
  • Diagrama de componentes.
  • Diagrama de despliegue.
  • Los diagramas deben estar formalizados en notación UML.

Fase 2 — Construcción Backend

  • Repositorio Git con historial de commits por integrante.
  • Implementación funcional de los 3 módulos en Backend:
    • Mesero
    • Cocina
    • Administración

Fase 3 — Construcción Frontend

  • Repositorio Git con historial de commits por integrante.
  • Implementación funcional de los 3 módulos en Frontend:
    • Mesero
    • Cocina
    • Administración

7. Restricciones de equipo

  • Los equipos deben estar conformados por 3 estudiantes.
  • Todos los integrantes deben tener una participación visible en el repositorio mediante commits.

8. Criterios de evaluación

Cada estudiante debe sustentar, en la sesión siguiente a la explicación teórica, su avance en el proyecto o la actividad que se haya indicado.

Si no se entrega en la clase siguiente, se puede entregar 15 días después de la explicación, pero con una penalización del 40 %.

Importante: Las excusas se deben presentar en la clase inmediatamente después de ocurrido el incidente.

Clone this wiki locally