Iteración 0

Documento Resumen de la Iteración 0

Documento Resumen Iteración 0

Diagrama de requisitos

Lo primero que hemos realizado es un análisis textual del documento del cliente sobre las funciones que debe tener su aplicación. De ese documento hemos sacado los siguientes requisitos.

Diagrama de requisitos v_1.0

Realización de la versión inicial del diagrama de requisitos de uso (Diagrama de Requisitos v_1.0), en la que incluimos los requisitos funcionales a tener en cuenta de nuestro proyecto. Este consta de los siguientes:

• Ver configuración de mesas
  • Muestra la configuración de mesas.
• Asignar una mesa a cliente y camarero
  • Al asignar la mesa al cliente se marca la mesa como ocupada.
• Cancelar la asignación de mesa
  • Si el cliente se retrasa 20 minutos, se cancela la asignación de mesa y su estado pasa a disponible.
• Anotar la comanda de los usuarios
  • Los camareros apuntan la comanda de los usuarios, teniendo a su disposición la información de los platos disponibles.
• Secuenciar estado de mesas
  • Cambio de estados de las mesas del restaurante: {Libre, Reservada, Ocupada, Pidiendo, En Espera de Comida, Servidos, Esperando la Cuenta, Pagando, En Preparación}; se almacenan todas las transacciones.
• Aviso a camarero tras la expiración del tiempo de estado
  • Se avisa a los camareros cuando el estado de una mesa expira en tiempo preestablecido.
• Guardar la hora en la que el camarero le dedica atención a los usuarios al comienzo de cada estado
  • El camarero se acerca a una mesa y automáticamente se guarda la hora en la que se le empieza a dedicar atención a los usuarios en cada uno de los estados.
• Notificar a los camareros de que los platos y la bebida están listos
  • Los cocineros avisan a los camareros cuando los platos y bebidas están disponibles para ser servidos a los clientes, en un plazo no superior a lo establecido, pasando del estado "En Espera de Comida" a "Servidos".
• Realización de estadísticas (por restaurante y ciudad, y por número de clientes en cada mesa)
  • Tiempo medio de toma de comandas
  • Tiempo medio de preparación de comidas
  • Tiempo medio de estrega de la nota
  • Tiempo medio de preparación para que la mesa quede libre
• Pago y liberación de mesa
  • Los clientes terminan de comer, piden al camarero la cuenta y el estado pasa a "Esperando la Cuenta". El camarero solicita al sistema que imprima la cuenta de la consumición, que podrá ser pagado en efectivo o tarjeta de crédito por los clientes. Una vez los clientes abandonan la mesa el camarero la prepara para los siguientes comensales (estado "En Preparación"). Cuando finaliza, devuelve la mesa al estado "Libre".

Diagrama de requisitos v_1.0

Diagrama de requisitos v_1.2

Realización de la segunda versión del diagrama de requisitos del proyecto (Diagrama de requisitos v_1.2), en la que se incluyen dos nuevos requisitos, descritos a continuación:

• Aprovisionar el almacén cuando se hace una previsión de las comidas
  • Se realiza una previsión de comidas a realizar, y al determinar los ingredientes necesarios se aprovisiona el almacén en base a nuestra previsión, actualizando la base de datos (también para las bebidas).
• Actualizar el stock del almacén al preparar un plato
  • Cuando las reservas de un determinado ingrediente caen por debajo de un determinado umbral de calidad, el sistema lanza una alarma a Almacén para que aprovisione más ingredientes.

Diagrama de requisitos v_1.2

Diagrama de requisitos v_1.3 Final

Versión final del diagrama de requisitos del proyecto (Diagrama de requisitos v_1.3 Final), en la que se incluye un último requisito al diagrama:

• Autenticarse
  • Como van a acceder varios tipos de usuarios al sistema y cada uno debe tener unas funciones específicas, será necesario un control de autentificación que les permita acceder a la parte del sistema que necesitan.

Diagrama de requisitos v_1.3

Los requisitos finales que hemos recogido son:

En esta tabla se incluyen la lista de requisitos final, con el número asignado a cada de uno de los mismos en base a un estándar (REQ###, donde ### representa la numeración del requisito en la lista), seguidos cada uno de ellos de una descripción en la que se remarca el objetivo a cumplir por cada requisito.

Requisitos finales

Casos de uso global

Diagrama de casos de uso global v_1.0

Diagrama de caso de usos global v_1.0

En el diagrama de casos de uso identificamos dos actores: el jefe de sala y el camarero

• jefe de sala: Los casos de usos para el jefe de sala son:

  • Ver configuración mesas: este caso de uso permite mostrar las mesas disponibles en el local, además del número de comensales de estas y el estado en el que están dichas mesas.
  • Asignar una mesa: El cliente llamara por teléfono al restaurante o acudirá para solicitar una reserva de una mesa, el jefe de sala tomará los datos al cliente y realizara la reserva de la mesa.
    • Si pasado un tiempo prudencial el cliente no acude a la reserva, ésta será cancelada.

• Consultar estadísticas: El jefe de sala podrá consultar las estadísticas de los platos e ingredientes pedidos por los clientes de dicho restaurante.

• Camarero:

  • Anotar la comanda: El camarero anotará la comanda del cliente cuando esté en su mesa.
  • Pago y liberación de mesa: El camarero realizara el cobro a los clientes y preparar la mesa para los siguientes.

*Ambos podrán:

• Secuenciar el estado de las mesas.

Diagrama de casos de uso global v_1.1

Diagrama de caso de usos global v_1.1

• En la primera versión del diagrama de casos de uso nos hemos dado cuenta de que necesitamos más casos de uso para satisfacer los requisitos funcionales del cliente. Se han añadido dos actores: cocina y almacén.

• El almacén podrá hacer uso del sistema para realizar una previsión de las comidas para tener el almacén siempre sumistrado.

• En cocina, se deberá poder notificar de que los platos pedidos por los clientes ya están preparados además de actualizar el almacén cada vez que se cocina un plato y lanzar una alarma si las provisiones bajan de cierto umbral.

Diagrama de casos de uso global v_1.2

Diagrama de caso de usos global v_1.2

• En esta versión hemos añadido un nuevo caso de uso que es necesario para poder diferenciar el tipo de usuario que se es dentro del sistema: autentificarse. A este caso de uso tendrán acceso todos los usuarios del sistema. Además se ha cerrado el universo del programa a una aplicación monolítica de escritorio.

Diagrama de casos de uso global v_1.4 Final

Diagrama de caso de usos global v_1.4

• Como cambios finales del diagrama de casos de uso, se ha añadido un nuevo actor del sistema, el usuario general del que heredaran los demás actores. Este usuario tendrá acceso a la autenticación y después del tipo de actor que seas tendrás acceso a los demás casos de uso.

Casos de uso finales

Estimación de tiempo y prioridades

Estimación de tiempo y prioridades V_1.0.0

Estimación final

Cada tarea será desempeñada por dos personas, las iteraciones principales (aquellas con prioridad 1 a 6) tienen una carga de trabajo de 73 horas con lo cual para finalizarlo en la fecha prevista (23 noviembre) se necesita una media de horas de trabajo semanales por cada grupo de empleados de 10 horas. Cada trabajador tendrá un salario hora de 18 euros.

Estimación de tiempo y prioridades V_1.1.0

El cambio realizado es sobre esta estimación es el cambio de dos prioridades, al considerar que el CDU010 tiene que tener una prioridad más baja (más importante) que el CDU008. Por tanto, hemos realizado un cambio en las prioridades y el CDU010 pasa a tener una prioridad 8 y el CDU008 pasa a tener una prioridad 9.

Estimación de tiempo y prioridades V_2.0.0 (Final)

Tras la realización de la iteración 1, nos hemos dado cuenta de que hemos hecho una estimación muy pesimista de los tiempos de trabajo de las disciplinas de la ingeniería del software de cada iteración. Por tanto, hemos hecho una nueva estimación más objetiva y optimista que la anterior, más cercana a la realidad.

Diagrama de Gantt V_1.0.0 (Final)

Estimación de imputación de horas línea base V_1.0.0 (Final)

Imputación de horas línea base Real V_1.0.0 (Final)

Estimación de imputación de horas V_1.0.0 (Final)

Estimación de módulos V_1.0.0

Hemos decidido hacer ese reparto de los casos de uso en los módulos que implementaremos:

• El módulo 1 y el principal será el módulo de reserva de mesas. Este módulo abarcará los primeros 5 casos de uso. La versión final resultante de la implementación de los 5 casos de uso será la 5.0.0 (consideramos que un módulo cambia de versión 1.X.X a 2.X.X cuando ha realizado un cambio grande, en este caso la implementación completa de un caso de uso).

• El módulo 2 será el módulo de control de acceso o módulo de autenticación.

A partir de este punto nuestra aplicación cumplirá el producto mínimo viable (V_1.0.0)

• El módulo tres será el encargado de la gestión de los camareros: CDU007 y CDU010
• El módulo cuatro es el encargado de la gestión de la cocina: CDU008
• El módulo cinco el responsable de lanzar los avisos cuando el tiempo de los estados supra un umbral de tiempo: CDU006
• El módulo seis, posibilitara la creación de las estadísticas. CDU009
• El modulo siete, el módulo de almacén que abarcará los casos de uso: CDU011, CDU012 y CDU013