You are on page 1of 69

Proyecto de Ingeniería de Software

1. Inicio
1.1. Visión del proyecto
1.1.1. Caso de negocio

 INTRODUCCIÓN

El ambiente actual en el proceso de negocios no se abastece con el recurso humano, es por
ello que se propone el uso de Software, el cual trabaja de una manera automatizada
Estando inmersos en un mundo tecnológico y de procesos automatizados, el restaurant
chifa WHEN WHA que se dedica a la elaboración de platillos de comida oriental y de muy
novedosas presentaciones, se ha visto en la necesidad de implementar un sistema que
permita gestionar los pedidos y llevar una adecuada contabilidad de estos para lo cual ha
requerido de nuestros servicios.
OBJETIVO
Sistematizar los pedidos del restaurant chifa WHEN WHA con el fin de llevar un control y
contabilidad de ellas para cubrir la necesidad tecnológica que requiere el restaurante.
ÁMBITO
El sistema será realizado para el restaurant chifa WHEN WHA ubicado en la Av. Cesar
Vallejo 26, Villa el Salvador, Lima Región, Villa EL Salvador

ALCANCE
* El sistema a desarrollar solo se enfocará en el registro de los pedidos, la contabilidad de
ellos, la actualización de los platillos en los registros y el conteo de estos al finalizar el día.

* El sistema no tomara en cuenta el manejo de personal, así como sus sanciones y pagos,
tampoco tomara en cuenta el inventario de insumos.
DEFINICIONES Y ACRÓNIMOS

 Limpio: las pantallas que se encuentran incluidas dentro del proceso de ventas en la cual va
a ser usada el Sistema no tienen muchos componentes, pero los suficientes para poder
realizar el negocio.
 Robusto: Amplia integración y seguridad de los datos usados en el sistema.
 Tiempo Real: Trabajo que se realiza al instante mediante el uso de red interna.
 GUI: Grafical Unit Interfaz, Interfaz Grafica
 Herramientas CASE: Aplicaciones informáticas que nos permiten ayudar en todos los
aspectos de ciclo de vida del software, en tareas como el proceso de realizar el diseño del
proyecto, documentación, etc. Permite aumentar nuestra productividad en el desarrollo del
mismo y reducir el coste en términos

Son aplicaciones software que respaldan el desarrollo y el mantenimiento del software.
Permiten:

- Modelamiento de Datos
- Control de revisión
- Generación de Código

 Patrones de Diseño: Modelo o solución a un problema de diseño no trivial que es efectiva y
reusable.
 Gestor de Base de Datos: Aplicaciones dedicadas a servir de interfaz entre la base de datos,
el usuario y las aplicaciones clientes que las utilizan. Entre las cuales MySql (Workbench
con PHPMyAdmin)
 Patrones de Arquitectura: Es el esquema de organización de un sistema software. Proveen
un conjunto de subsistemas predefinidos, especificando sus responsabilidades e incluyen
reglas y guías para organizar las relaciones entre ellos.

 DESCRIPCIÓN GENERAL DEL SISTEMA

DESCRIPCIÓN DE LA SITUACIÓN ACTUAL
El restaurant chifa WHEN WHA cuenta con 4 mozos por cada piso del establecimiento, un
personal en caja y un administrador que supervisa el servicio perenemente y los reclamos
de los clientes , los pedidos son tomados por los mozos de forma manual tomando nota del
pedido y la mesa con una hoja, y un lapicero entregadas al personal de cocina en orden de
llegada , los cocineros realizan la preparación de los platillos según las hojas de pedidos
dejadas por los mozos y entregadas conforme van elaborándose , llaman a los mozos
mediante una campana indicando que el pedido se encuentra listo.
Para llevar la contabilidad del día se contabiliza todas las boletas de pedidos y se anota en
un cuaderno de registro que maneja el administrador.
ENTORNO DEL SISTEMA

Indicar si es un producto independiente o parte de un sistema mayor. En el caso de tratarse
de un producto que forma parte de un sistema mayor, un diagrama que sitúe el producto
dentro del sistema e identifique sus conexiones facilitas la comprensión.
En este punto también se describirá la relación del sistema con otros sistemas propios de la
organización. Asimismo, se enumerarán la descripción global del sistema, y su integración
dentro del mapa de sistemas de la consejería.

El sistema de gestión de pedidos del restaurante brindará información para el sistema de
inventariado de insumos, así como también tomará información de este para que en base a
ello el área de inventario de productos realice las compras necesarias de insumos.

CAPACIDADES DEL PRODUCTO
CARACTERÍSTICAS DEL PRODUCTO
Proveer reportes. El sistema proveerá reportes detallados de los pedidos realizados por
fecha y hora, código de mesero, y pedido.
Realizar pedidos: El mesero podrá realizar pedidos de bebidas o platos por número de
mesa.
Almacenar datos: Guardar datos detallados de los pedidos realizados con detalles.
Ver pedidos instantáneamente: El equipo de bar y cocina deberán ver los pedidos realizado
por mesero y hora del pedido.
VENTAJAS
La creación del sistema de gestión de pedidos tiene las siguientes ventajas:
Reportes detallados: Almacenamiento de los pedidos realizados detalladamente.
Agiliza el despacho de los pedidos: Al realizarse un pedido este se visualizará
instantáneamente en el área de cocina.
Los jefes podrán monitorizar los pedidos del negocio: cualquier administrador tendrá
siempre a su disposición los datos actualizados de pedidos por mesa y mesero.
Reducción de la pérdida de tiempo: Se atenderá a los clientes de manera rápida y así
aumentar la cantidad de clientes diariamente.
Documentación de todas las ventas realizadas: El sistema guardará en la base de datos cada
venta diaria para ser analizada cuando el administrador lo decida.
Se obtendrán los siguientes beneficios tangibles:

COSTO FACTIBILIDAD .

RIESGOS .

la cual utilizando el marco de trabajo de scrum el proyecto avanzará por incrementos distribuido de la siguiente manera: Conclusión Para resumir y concluir esta presentación vemos que el negocio está en un estado deficiente ya que se toma demasiado tiempo en el proceso de hacer los pedidos.3. Como equipo SCRUM necesitamos tener las bases elementales para este proceso de agilización de los procesos mismos del restaurante. al no atenderlos el restaurante se mantiene ocupado y no da espacio para nuevos clientes lo que causa una perdida al negocio.1. hemos hecho los estudios para saber las necesidades del negocio tomando en cuenta todos los contra posibles y sabemos que este software será aprovechado bien por el restaurant chifa WHEN WHA .2. puedan distribuir acciones a otras tareas más relevantes del mismo servicio de atención.1. lo que causa que se satisfaga a los clientes con menos prontitud. PLAZO / HITOS REQUERIDOS El plazo propuesto para concluir con el proyecto gestión de pedidos es de 2 meses.Con este sistema lograremos agilizar los pedidos de este restaurante implementando tecnología de una manera inteligente para la rápida atención al cliente y facilitar el trabajo de los empleados. por lo cual se le está brindando un sistema acorde a sus necesidades para que de esta manera. Visión y misión de la empresa . Reunión de la visión del proyecto Reunión de la Visión del Proyecto Lo que se desea con la realización de este proyecto es brindarle a la cadena de restaurantes WHEN WHA un sistema que benificiaría la productividad del mismo resumiendo funciones involucradas y agilizando los procesos medios que se necesita en la atención de pedidos encomendados por los clientes del restaurante. 1. 1.

con el objetivo de incrementar su competitividad y productividad. Para ello implementamos soluciones prácticas adaptadas a sus necesidades desarrollando un sistema practico y manejable. VISIÓN: . Visión de la Empresa MISIÓN: Proporcionar la tecnología de software más innovadora a medida de las necesidades del restaurante .

En nuestra visión queremos brindar un sistema que marque la diferencia en cuanto a la atención y a la gestión de del negocio de un restaurante. y teniendo un cumplimiento optimo de estas exigencia de manera innovadora y flexible.Ser la compañía más innovadora y referente en el sector.  No tener experiencia en desarrollo de scrum.  Habilidades para la innovación. Análisis foda Análisis Foda El análisis FODA nos ayudara a realizar una análisis interno (Fortalezas y Debilidades) y externo (Oportunidades y Amenazas). .  Estrategias y objetivos definidos. Fortalezas  Buen ambiente laboral.1. Debilidades  No disponer de mucho tiempo para los avances diarios.4. 1.acoplándonos a la exigencias que cada cliente pueda definir.  Conocimiento del mercado.  Equipo de trabajo capaz de afrontar el proyecto.  Buena calidad del producto final.

Esto es clave para iniciar con éxito nuestro proyecto utilizando la metodología ágil de desarrollo de software.1. y transmitir esa visión a todo el equipo. Productowner identificado Product Owner El product owner es un actor clave para el desarrollo de nuestro proyecto y una de sus responsabilidades es tener una visión de lo que desea construir. Por lo tanto queda como product owner Aldo de la Cruz con un puntaje de 26. Amenazas  Cambio de las necesidades y gustos del cliente.  Necesidad del producto. Oportunidades  Competencia débil. que es una lista priorizada de características del producto.  Cambios en el entorno. Los puntajes que se darán a cada uno será del 1-10.5. . el integrante con mayor puntaje sera elegido product owner. 1. Para ello hemos evaluado a todos los integrantes del equipo para analizar las capacidades de cada uno y así designar el responsable para que mejor cumpla la función del product owner.  Mercado mal atendido. El product owner hace esto a través del product backlog.

1.2. El Scrum Master debe ayudar a la gente que está fuera del equipo Scrum a entender qué interacciones con el equipo son positivas y aportan valor al equipo y cuáles no. Es el responsable de asegurarse de que todo el equipo entiende Scrum y actúa en consecuencia a su teoría.2. el Scrum Master se centra en el proceso Scrum. Identificar al SCRUM MASTER Identificar al Scrum Master Mientras que el Product Owner se centra en el valor y tiene la visión de negocio. actúa como mentor y ayuda a resolver los impedimentos que vayan surgiendo.1. Scrummaster descripción Scrum Master . 1. prácticas y reglas.

Eliminar los problemas que impidan progresar al equipo de desarrollo. De forma general.Enseñándole técnicas para gestionar efectivamente el Product Backlog y maximizar el valor de negocio. Sprint Review. el equipo de desarrollo o incluso la organización entera. . asegurarse de que duren el tiempo establecido y cumplan su objetivo (Daily meeting. .Auto-organizarse y convertirse en equipos multifuncionales. Sprint Planning Meeting. . a entender e implantar Scrum. el integrante con mayor puntaje sera elegido scrum master. para el Product Owner. En cuanto al equipo de desarrollo. . El Scrum Master sirve al Product Owner: . .Que entiendan los ítems del Product Backlog. Los puntajes que se darán a cada uno será del 1-10.Crear productos que aporten valor al cliente o usuario.Participar en las reuniones de Scrum. Otros deberes: . Por lo tanto queda como scrum master Elard Torres con un puntaje de 26. También debe colaborar y trabajar con otros Scrum Masters para encontrar formas de mejorar la implantación de Scrum en la organización. planificando la implantación de Scrum junto con la organización. el Scrum Master puede realizar cursos de formación o eventos sobre Scrum. el Scrum Master ayuda a: .El scrum master debe ayudar también a toda la organización.Ayudándole a entender la agilidad. Sprint Retrospective). si es necesario.

. Identificación STAKEHOLDES Identificacion Stakeholders Hemos identificado al Stakeholder que nos brindara un apoyo para guiarnos en el desarrollo del proyecto scrum .Este viene ser el Administrador del chifa restaurante WHEN WHA. 1.3.

Equipo SCRUM Equipo SCRUM Aldo De la Cruz Flores Product Owner Responsable de maximizar el valor del producto y del trabajo en equipo. 1.4. .

entregada y decisoria al momento de elegir un paso a seguir en el desarrollo de software. . Elard Torres Silva Scrum Master Responsable de asegurar que scrum es entendido y adoptado Características: Por ser una persona determinada a los objetivos y enfocado en el entendimiento de todos los pasos a seguir al momento de la elaboración del proyecto. Características: Por ser una persona responsable.

El administrador del when whan nos facilito información de como se maneja sistemas dentro de el restaurante pero que estos sistemas solo se especializa en otros aspectos (insumo. resolviendo estos con responsabilidad y mucha precausión.los cuales son reflejados en las epicas mostrada durante el proyecto.6. Epicas .Mediante dos reuniones iniciales hemos visto que este a su vez tenia un panorama muy amplio en las labores que desempeñan dentro del restaurante ( Cajero . Este a su vez nos ah mostrado el interés de un sofware que pueda agilizar los procesos de ventas dentro del restaurante . Mesero y Jefe de ventas) . Reuniones del grupo de usuarios Reuniones del grupo de usuarios Mediante la identifiacion de stakeholder hemos definido al administrador del restaurante whenwha .José Huari Zanca Equipo Scrum Características: Por ser una persona lógica y determinada con el fin de hallar la solución específica a cada problema presentado. Por lo tanto se vio interesado en un sistema que se pueda implementar a la parte de ventas . 1.5. nos brindo la información de cuales eran los puntos a seguir para poder satisfacer las necesidades que hacían falta en sistemas antes implementandos en el restaurante .etc). 1.Es por eso que lo hemos visto justo usuario que puede opinar y dar criterios sobre las necesidades que exigirian las labores antes mencionadas. almacenes .

uno que sea el cajero y el otro el administrador. Prototipo . Como dueño del restaurante viendo lo que es la parte de pedido y no haberlo especificado antes.Quiero que haya dos tipos de usuario. EP05: Como administrador del chifa When Wha . EP09: Como dueño del restaurante quiero que se pueda generar un reporte de ventas donde se puedan ver todas las ventas que se han hecho durante el dia. quiero agregar nuevos platos. EP04: Como administrador del chifa When Wha . quiero agregar al pedido lo que es la parte de una vizualizacion de la cuenta (pre- cuenta) antes de generar un comprobante. EP02: Establecer las tarifas óptimas para aquellos platos de mayor venta.7. Epicas EP01: Quiero revisar el desempeño histórico de las ventas diarias. EP03: Establecer la tarifa óptima para los platos en base a las tarifas de otros restaurantes chifas comparables con el mío. agregar precio y agregar toda la información que respecta al plato. EP08: Como dueño del restaurante quiero que se pueda generar un comprobante a partir de lo consumido por el cliente y esto implica lo que es factura y boleta. y así tener la materia prima necesaria para la realización de dichos platos.Quiero que solo el administrador pueda tener acceso modificar. EP06: Como administrador de chifa When Wha . EP07: Como dueño del restaurante quiero que se pueda generar un comprobante a partir de lo consumido por el cliente y esto implica lo que es factura y boleta. 1. para poder identificar los platos y productos de mejor desempeño.

vive en villa el salvador padre de dos hijos. con el objetivo de incrementar su competitividad y productividad. para la. 2. Para ello implementamos soluciones prácticas adaptadas a sus necesidades desarrollando un sistema practico y manejable. Sprints del proyecto 2. Prototipo Carlos Andree tiene 35 años es el cajero del restaurante chifa WHEN WHA. por ser una persona con estudios de cajero desea tener un sistema que pueda sistematizar su trabajo diario y ahorrar tiempo y dedicarse a llevar otra carrera como administración de empresas o la carrera de contabilidad . .1. Primer sprint MISIÓN Proporcionar la tecnología de software más innovadora a medida de las necesidades del restaurante . los cuales le causa molestia cuando tiene que juntar cada boleta y factura diaria. contabilización. de Tiene a su cargo los reportes finales de ventas diarias.

el manejo de pedidos y proporcionar la información de las ventas echas durante el día. y teniendo un cumplimiento optimo de estas exigencia de manera innovadora y flexible.  Habilidades para la innovación. El sistema no tomara en cuenta el manejo de personal.  Mercado mal atendido. VISIÓN En nuestra visión queremos brindar un sistema que marque la diferencia en cuanto a la atención y a la gestión de del negocio de un restaurante. así como sus sanciones y pagos. Alcance El sistema a desarrollar solo se enfocará en el manejo de platos .  Cambios en el entorno.  Necesidad del producto. Debilidades  No disponer de mucho tiempo para los avances diarios. PLAN DE DESARROLLO DEL SOFTWARE Brindar una herramienta tecnológica adecuada en la gestión y manejo de la información dentro del restaurante WHEN WHA con el fin de llevar un control y contabilidad de ellas para cubrir la necesidad que requiere dicha empresa.  No tener experiencia en desarrollo de scrum.Ser la compañía más innovadora y referente en el sector.  Equipo de trabajo capaz de afrontar el proyecto. acoplándonos a la exigencias que cada cliente pueda definir.  Buena calidad del producto final. ANÁLISIS FODA Fortalezas  Buen ambiente laboral.  Conocimiento del mercado. Oportunidades  Competencia débil.  Estrategias y objetivos definidos. Amenazas  Cambio de las necesidades y gustos del cliente. .

1. Establecer las tarifas óptimas para aquellos platos de mayor venta. 3.2. 2.1. 2. Epicas del proyecto EPICAS DEL PROYECTO Como administrador del restaurante chifa WHEN WHA: 1. y así tener la materia prima necesaria para la realización de dichos platos. para poder identificar los platos y productos de mejor desempeño. Establecer la tarifa óptima para los platos en base a las tarifas de otros restaurantes chifas comparables con el mío. Quiero revisar el desempeño histórico de las ventas diarias.1. 2. Historias de usuario HISTORIAS DE USUARIO .

para el ágil atendimiento al cliente.HU01: Loguear Usuario Como dueño del restaurante quiero que el sistema tenga un menú de ingreso de usuario generando así seguridad del sistema. . HU02:Disponibilidad de mesa: Como dueño del restaurante quiero que los meseros tenga manejo de la información de que mesa está ocupada y que mesa esta disponibles.

Pendiente: Coloque para todas las tarjetas que no están en las columnas "Listo" o "En proceso" para el sprint actual. Hecho: las tarjetas se acumulan aquí cuando terminan. Historias de Usuario : la descripción de la historia ("Como usuario queremos . Se eliminan al final del sprint. Para verificar: muchas tareas tienen tarjetas de tarea de prueba correspondientes. . El programador que decide trabajar en él lo mueve cuando está lista para comenzar la tarea. El tablero contiene seis columnas para indicar el progreso de las tareas estimadas para el sprint.HU03: Manejo de pedido del cliente Como dueño del restaurante quiero que se pueda ver. modificar o anularlo el pedido del cliente si es que este cambia de pedido.1. A veces eliminamos algunos o todos durante un sprint si hay muchas tareas realizadas.") se muestra en esa fila.3. Riesgo: Inconvenientes presentados al realizarse algunas tareas. Scrumboard SCRUMBOARD Una herramienta utilizada por el Equipo Scrum para planificar y dar seguimiento a nuestro proyecto durante cada sprint. En Progreso: cualquier tarjeta en la que se esté trabajando va aquí. 2. ingresar ..

1. 2. . Base de datos Base De Datos Aquí mostraremos la colección de información organizada y relacionada que nos permita almacenar los datos pertenecientes al sistema y así ofrecer la mejor manera de almacenar un banco de datos con facilidad y de manera organizada.4.

6.5. 2. Reuniones de equipo REUNIONES DEL EQUIPO SCRUM . Normalmente se utiliza para saber cuánto nos faltará para terminar las historias comprometidas en un sprint 2.1.1. Diagrama de burn down chart DIAGRAMA BURN DOWN CHART El diagrama de Burndown nos serivirá en nuestro proyecto para saber el tiempo que falta para completar el trabajo.

1. El objetivo de estas reuniones es facilitar la transferencia de información y la colaboración entre los miembros del equipo al poner de manifiesto puntos en que nos podemos ayudar unos a otros para aumentar la productividad.7.El equipo Scrum se reunió para poder desarrollar debate sobre la presentación del primer sprint. Entregables ENTREGRABLE 1ER SPRINT BASE DE DATOS: link SOFTWARE: link MANUAL DE USUARIO: link 2.8. 2. Reunión de retrospectiva Reunión de retrospectiva del 1er Sprint .1.

A continuación les mostraremos los puntos tratados en nuestra reunión de retroalimentación:  Falto implementación de burndown chart para conocer el tiempo aproximado en que se terminó el sprint. • Obtener una rentabilidad anual del 25%.1.  Creación de vídeos para mostrar de que manera hemos ido desarrollando nuestro proyecto.2. Objetivos específicos • Elevar la eficiencia de la producción en un 20%. eficiencia en su control de productos.2.  Implementación adecuada de los métodos de priorizacion para obtener una medida de tamaño relativo de todas las historias respecto a sí mismas o el trabajo necesario para realizarlos. 2. donde el equipo analiza las formas de mejorar los procesos y el rendimiento a medida que avanzan al siguiente sprint. Segundo sprint OBJETIVOS Objetivos generales Proporcionar el sistema como herramienta para el control y flujo de informacióncon soluciones a la medida de acuerdo con los requerimientos del cliente que facilite la automatización de la lógica y análisis de pedidos. 2. Planificación de lanzamiento Planificación de Lanzamiento .El ciclo del sprint termina con una Reunión de Retrospectiva del Sprint (Retrospect Sprint Meeting).

IMPLICADOS :  Scrum Master . 2.Está formado por el conjunto de profesionales que cada Sprint trabaja de forma colaborativa para desarrollar un incremento de producto completo y potencialmente entregable. .por lo tanto las dos historias que hemos elegido en consenso son:  Luego de haber planteado las historias se tomo paso a poder elaborar la lista de tareas que se realizaran para poder satisfacer lo requerido por las historia de usuario.  Equipo de desarrollo .2. Reunión de planificación del Segundo Sprint En la reunión de planificación hemos concordado en elegir solo dos historias de usuario con mayor prioridad para presentar en el segundo sprint .  Product owner .El método de priorización que hemos aplicado es de los 100 puntos para poder priorizar las historias.Se ocupa de la vista detallada de la pila de producto y los criterios de aceptación.2. Seguimiento del sprint Seguimiento del Sprint  Estas estimaciones ayudran a los miembros del equipo para comprobar el número de horas de trabajo cada miembro tiene para la iteración.El scrum master actuará como un facilitador para el equipo de entrega en el sprint.

3.2. Lista de tareas Lista de Tareas La lista de tareas que el equipo ha elaborado en la reunión de planificación de la iteración como plan para completar los objetivos del proyecto y que se comprometerá a demostrar al cliente finalizada la iteración. en forma de incremento de producto preparado para ser entregado son las siguientes: . Hemos dispuesto para esto el compromiso de los miembros para realizar las tareas y hemos aproximado el tiempo que se tomará cada tarea y quien la desempeñará: 2.

Historias de usuario Historias de Usuario .2.5.4. 2. Épicas del proyecto ÉPICAS DEL PROYECTO El nivel de agrupación por encima de las historias de usuario que permite clasificar las mismas por funcionalidades. módulos. subsistemas.2. etc. 2.

2. Criterios de aceptación CRITERIOS DE ACEPTACIÓN .2.6.

4.1. HU08: Loguear usuarios con privilegios Criterios de aceptación: 1. Poder mostrar los nuevos platos o los platos modificados . 2. Al seleccionar una categoría deberá de mostrar los platos dentro de esa categoría. HU03: Manejo de los platos  Criterios de aceptación: 1. Pendiente: - En Progreso: - Para verificar: La revisión minuciosa de la base de datos en función a los nuevos requerimientos y los avances. Se deberá poder seleccionar cada plato y poder acceder a un menú de modificación aparir de un botón. Si se accede a un usuario no registrado deberá aparecer un mensaje de error. Historias de Usuario : Manejo de platos y Loguear usuarios con privilegios. 2. 3. 2. 2.7. . Que para cada usuario tenga privilegios diferentes a los otros usuarios diferenciandoles por el rango o funciones que cumple en el restaurante. 3. Se debe prever las necesidades del cliente en este caso el chifa WHEN WHA en base a los requisitos que solicite el Administrador del restaurante. La información de las categorías del menú deberá presentar para seleccionar . Al ingresar el usuario administrador deberá acceder al menú de manejo de plato 3. Scrumboard SCRUMBOARD Una herramienta utilizada por el Equipo Scrum para planificar y dar seguimiento a nuestro proyecto durante cada sprint.2. Que los privilegios asignados a cada usuario del sistema sean correctos. A partir de un botón poder acceder a un menú donde se pueda agregar un nuevo plato. El tablero contiene seis columnas para indicar el progreso de las tareas estimadas para el sprint. Al ingresar el usuario del cajero deberá de aparecer solo el botón de pedido disponible. 5.

en este sprint se ha priorizado dos historias de usuario que son manejo de los platos y loguear usuarios con privilegios. para no crear un . A veces eliminamos algunos o todos durante un sprint si hay muchas tareas realizadas. 2. Hecho: Las tarjetas se acumulan aquí cuando terminan.8. VERIFICAR Aquí se demostrará y se validará todos los resultados conseguidos en el sprint. DIMENSIONES DE CALIDAD 1. Por ello. Se eliminan al final del sprint. HACER Es aquí donde se crea todos los entegrables para el proyecto basados en las historias de usuario. Planificación de calidad PLANIFICACIÓN DE CALIDAD PLANIFICAR La planificación para nuestro proyecto esta basado en función a la priorización de cada historia de usuario. Riesgo: Inconvenientes presentados al realizarse algunas tareas. cumpliendo con los estándares de las reuniones diarias y optimizando cada incremento.Cumplimiento de expectativas del Cliente (Product Owner) Hay que cumplir con las expectativas del consumidor o usuario final de producto.2. que es quien va a comprarlo o verse beneficiado en su utilización.

El producto debe ser mantenible. GESTIÓN DE CALIDAD DE LAS HISTORIAS DE USUARIO DEL PROYECTO ACTUAR Definir acciones correctoras a realizar en el siguiente ciclo para mejorar los resultados y enviar los entregables. 4. El producto debe comportarse de la manera esperada. 3.Calidad interna.Calidad externa. su compromiso con el proyecto y con la empresa. funcionamiento correcto.producto que nadie va a comprar o una aplicación que nadie va a utilizar. 2. debe poder evolucionar a un ritmo sostenido. tanto a nivel funcional como no funcional (rendimiento. usabilidad. . el cliente debería conocer quién es y qué necesita el consumidor o usuario final.Satisfacción del equipo que esté orgulloso de su trabajo.). etc. para mantener su motivación.

2. Entregables Entregables BASE DE DATOS .9.2.

2. Videos de reuniones Videos de Reuniones Reunion de planificacion del Segundo Sprint: Poker plannig: 2. retrospectiva. Links del software. Retrospectiva Retrospectiva 2do Sprint 1. 2. planeacion de lanzamiento. priorizar y orden a la hora de exponer. base de datos y manual 2.10.11. .2.Grabar videos el cual pueda mostrar las reuniones diarias.

5.3. Cambios aceptados Cambios aceptados Los cambios que el cliente ha manifestado luego de la presentación del entregable del segundo Sprint. 2.3. luego creado las tareas que habremos que desarrollar para poder cumplir con las historias .al ver que la priorizacion de este.3. según el cliente. Definir bien los roles con sus respectivos metodologías de aceptación. es mucho mas alta que las ultimas . Reunión de planificación Reunión de planificación En la reunión de planificación hemos acordado las historias que hemos de elegir para este Sprint.y las personas que pueden desarrollarlas. ya que en scrum no solo se basa en el software sino en agregar los incrementos paso a paso.be/SWxaf3_KtCE 2.2.3. es la incorporación de lo que es una visualización de una pre-cuenta. Tercer sprint 2. 4. Además hemos dado visto bueno incorporar ese nuevo cambio al Sprint que presentaremos .Ampliar documentación a todos los puntos. Documentar detalladamente el caso de negocio del proyecto.1. en el siguiente vídeo mostramos esta reunión importante: https://youtu.

2. 2. Épicas Épicas del Proyecto 1.Como dueño del restaurante quiero que se pueda generar un comprobante a partir de lo consumido por el cliente y esto implica lo que es factura y boleta. quiero agregar al pedido lo que es la parte de una vizualizacion de la cuenta (pre-cuenta) antes de generar un comprobante.Como dueño del restaurante viendo lo que es la parte de pedido y no haberlo especificado antes. Prototipo (Personajes) . por el echo que esta relacionado con el pedido del cliente y la creación de factura y boleta.historias a elegir .3.3. Este nuevo cambio esta especificado tanto en la segunda épica de este Sprint y Historia numero 09 dentro de lo que es la pila del producto.

contabilización. es por ello que aquí te mostramos nuestras historias priorizadas para este sprint: . Se puede escribir una historia que abarque una amplia funcionalidad.Carlos Andree tiene 35 años es el cajero del restaurante chifa WHEN WHA. Historias de usuario Historia de Usuario Uno de los beneficios de las historias de usuario es que pueden escribirse en variados niveles de detalle. los cuales le causa molestia cuando tiene que juntar cada boleta y factura diaria. 2. de Tiene a su cargo los reportes finales de ventas diarias. por ser una persona con estudios de cajero desea tener un sistema que pueda sistematizar su trabajo diario y ahorrar tiempo y dedicarse a llevar otra carrera como administración de empresas o la carrera de contabilidad . para la.4.3. vive en villa el salvador padre de dos hijos.

.

6.5. Como hemos acordado en la reunión de planificación . 2.3.3. Lista de tareas Lista de Tareas Dentro de la reunión de planificación hemos acordado las tareas que se van a desempeñar las cuales son las siguientes: 2. hemos determinado la duración de cada tarea que le llevara a cada encargado de estas poder terminarlas. Planificación de lanzamiento Planificación de Lanzamiento Para nuestra planificación de lanzamiento hemos se estima que la duración del Tercer Sprint tendrá un tiempo de 3 Semanas empezando del día 6 de noviembre y culminando el día 27 de noviembre del 2017. . las tareas acordadas y el trabajo que nos costara hacerlas.

Seguimiento del sprint Seguimiento del Sprint Durante las tres semanas de duración del Sprint hemos tenido un seguimiento de como se ah avanzado las tareas durante este Srpint: Primera Semana: Segunda Semana: Tercera Semana: Proceso de ejecución del 3er Sprint .7. 2.3.

Riesgo: Inconvenientes presentados al realizarse algunas tareas. A veces eliminamos algunos o todos durante un sprint si hay muchas tareas realizadas. El tablero contiene seis columnas para indicar el progreso de las tareas estimadas para el sprint. realizar factura y generar pre-cuenta. . Hecho: Las tarjetas se acumulan aquí cuando terminan. En Progreso: . Historias de Usuario : Realizar boleta. Pendiente: -Tareas que falta realizar.Linea Azul: Tiempo estimado Linea Naranja: Tiempo real 2.Tareas que se están desarrollando en la actualidad.3. Se eliminan al final del sprint.8. Scrumboard Scrumboard Una herramienta utilizada por el Equipo Scrum para planificar y dar seguimiento a nuestro proyecto durante cada sprint. Para verificar: La revisión minuciosa de cada parte que debe ser incluída en la implementación de las historias de usuario.

Aquí mostraremos algunas pantallas del avance diario de nuestro proyecto mediante el tablero de de scrum board: PRIMERA SEMANA SEGUNDA SEMANA .

TERCERA SEMANA .

2. 2. 3. 4.nombre. Atravez de un boton generar boleta poder guardar los datos .direccion). Acceder mediante un botón a una interfaz de boleta. Acceder mediante un botón a una interfaz de factura. Atravesar de un botón generar boleta poder guardar los datos. Mostrar el pedido . 2. Mostrar el El total dentro de la interfaz y el pedido que se ha hecho. Mostrar mensaje al terminar de guardar los datos .nombre. 2. Poder llenar los campos que debe tener una boleta(dni. el IGV y total contando el Igv dentro de la interfaz.direccion). Criterios de aceptación Criterios de Aceptación HU05: Generar Factura 1. 5. Acceder mediante un botón a una interfaz de Pre-Cuenta. HU06: Generar Boleta 1.3.verificando los mismos. Mostrar mensaje al terminar de guardar los datos . 3. Vizualizar el pedido del cliente y el total.verificando los mismos. 4. Poder llenar los campos que debe tener una factura(ruc. 5. HU09: Vizualizar una precuenta 1. .el total .9.

-Implementar el modelo con cada fase del scrum con los 19 procesos .12.4.10.y las personas que pueden desarrollarlas.11.1. para genera mayor claridad al Sprint.4. base de datos. Entregables Software. -Nuestro seguimiento del proyecto con el trello esta muy limitado. Videos de reuniones Videos de Reuniones REUNIÓN DE PLANIFICACIÓN DEL TERCER SPRINT En esta reunión de planificación se designaron las tareas a cada uno de los miembros de equipo. Cuarto sprint 2. 2. Mostrar mensaje al terminar de guardar los datos . 4.3. manual de usuario 2. la solución que hemos planteado es el echo de poder implementar lo que son traficas de porcentaje del avance de las tareas. labores las cuales fueron asignadas por el Product Owner. METODOLOGÍA DEL POKER PLANNING PARA LA DETERMINACIÓN DE TAREAS En este video se puede apreciar como se determinó el nivel de importancia de cada tarea asignada a cada uno de los miembros del equipo scrum.verificando los mismos.3. dentro de la pagina ya que solo hemos planteado o abarcado algunos puntos por cada Sprint . Atraves de un botón generar pre-cuenta guardar la pre-cuenta. 2. Reunión de planificación Reunión de Planificación En la reunión de planificación de este 4to Sprint hemos acordado las historias que hemos de elegir para este Sprint. . 2. esta historia que eligiriemos sera la ultima historia que nos queda por completar .luego de seleccionar la historia hemos creado las tareas que habremos que desarrollar para poder cumplir con las historias .3. Retrospectiva Retrospectiva Lo que hemos aprendido o los errores que hemos tenido dentro de lo que es el Tercer Sprint son lo siguientes: -Modificar el nombre de las tareas para que sea mas entendible para el cliente.3.

que a su vez es una de las que requieren trabajo aunque no sea de tanta prioridad para el cliente durante los primeros Sprint's.4. Historias de usuario Historias de Usuario En este Sprint presentaremos la ultima historia de usuario . 2. en forma de incremento de producto preparado para ser entregado son las siguientes: .  Como dueño del restaurante quiero que pueda mostrar también ventas echas en días anteriores o la fecha que yo quiera.2. 2. Épicas Epicas  Como dueño del restaurante quiero que se pueda generar un reporte de ventas donde se puedan ver todas las ventas que se han hecho durante el día tanto facturas. 2.4. Lista de tareas Lista de Tareas La lista de tareas que el equipo del proyecto ha elaborado en la reunión de planificación de la iteración como plan para completar los objetivos del proyecto y que se comprometerá a demostrar al cliente finalizada la iteración.4.3.4.

las tareas acordadas y el trabajo que nos costara hacerlas.4. Como hemos acordado en la reunión de planificación . Planificación de lanzamiento Planificacion de Lanzamiento Para nuestra planificación de lanzamiento hemos se estima que la duración del Cuarto Sprint tendrá un tiempo de 3 Semanas empezando del día 28 de noviembre y culminando el día 18 de diciembre del 2017. .5. hemos determinado la duración de cada tarea y hemos comprometido a cada integrante desarrollar segun su disponibilidad y conocimientos . 2.

4.6. 2. Seguimiento del sprint Seguimiento del Sprint Durante las tres semanas de duración del Sprint hemos tenido un seguimiento de como se ah avanzado las tareas durante este Sprint: Primera semana Segunda semana Tercera semana Ejecución completa Proceso de ejecución del sprint: .

El Software debe facturas las facturas del rango de fechas antes ingresadas 4.4. Criterios de aceptación Criterios de Aceptación HU07: Crear Reporte de Ventas 1. manual 2. El Software debe listar las facturas del rango de fechas antes ingresadas 3. 2.4.4.8. El software debe ingresar el rango de fechas donde se quieran ver las ventas. Linea Roja: Tiempo estimado Linea Azul: Tiempo real 2. Scrumboard . base de datos.9.7. Entregables Software. El software Mostrar un total de todas las ventas del día o el intervalo señalado. 2.

cada miembro del equipo utiliza adhesivos de colores más pequeños sobre cada tarea. en forma de post-its virtuales. Scrumboard La lista de objetivos a completar en el Sprint se puede gestionar mediante el scrumboard. aqui se muestra el 4to sprint realizado en cuatro semanas. SEMANA 1 SEMANA 2 SEMANA 3 . y se irán moviendo hacia la derecha para cambiarlas de estado (pendientes de iniciar. Al lado de cada objetivo se ponen las tareas necesarias para completarlo. de manera que se pueda ver en qué tareas está trabajando cada cual. en progreso. hechas).

4. Retrospectiva .10.4. Videos de reunión No hay xD 2.SEMANA 4 FINAL 2.11.

Historias de usuario Historias de Usuario Lista completa a todas las historias a realizar en todo el proyecto: 3. Planificación y estimación 3. Estimación hu Estimacion de la Historias de Usuario Se presenta el tiempo estimado a cumplir en la realización de cada historia de usuario. .2.1. sujeto a variaciones según la directriz del Producto Owner. Tampoco hay xD 3.

4. Identificar tareas hu Identificar Tareas TAREAS DEL SPRINT N° 001 . 3.3. Comprometer hu Comprometer Historias de Usuario Se presenta al miembro del equipo que debe dar mayor prioridad a cierta historia de usuario sabiendo también que apoyará en las demás como parte de la metodología Scrum donde evaluamos la factibilidad de cada miembro del equipo Scrum para que realice dicha labor. 3.

tiempo: 6 horas Prioridad: 10 .5.TAREAS DEL SPRINT N° 002 TAREAS DEL SPRINT N° 003 TAREAS DEL SPRINT N° 004 3. Backlog priorizado producto hu Backlog Priorizado del Producto: HU01: Loguear Usuario Como dueño de restaurante chifa deseo que el sistema me permita loguear usuarios para la seguridad de mi sistema.

modificar o eliminar . para el ágil atendimiento al cliente. ingresar . Siendo esto último solo accesible para administradores. según la disposición de la administración. Tiempo: 9 horas Prioridad: 20 HU04: Manejo del pedido del cliente Como dueño del restaurante quiero que se pueda ver. . Tiempo: 8 horas Prioridad:20 HU05: Generar Factura   Como dueño del restaurante quiero que se pueda generar una factura. tiempo: 8 horas Prioridad: 18 HU03: Manejo de los platos  Como dueño del restaurante quiero que el sistema tenga disponible virtualmente el menú.  Tiempo: 9 horas  Prioridad: 10 HU07: Crear reporte de ventas Como dueño del restaurante quiero que se pueda generar un reporte de ventas donde se puedan ver todas las ventas que se han hecho durante el dia. HU02: Disponibilidad de mesa:  Como dueño del restaurante quiero que los meseros tenga manejo de la información de que mesa está ocupada y que mesa esta disponible además de poder hacer reservas. además de poder ingresar nuevos plato . modificar o anularlo el pedido del cliente si es que este cambia de pedido.  Tiempo: 9horas Prioridad: 10 HU06: Generar Boleta   Como dueño del restaurante quiero que se pueda generar una boleta de pago .

   Tiempo: 3 horas  Prioridad: 8 4. Implementación Implementación Para poder tener una visión global de Scrum y cada paso que realizamos en la implementación de nuestro proyecto. Tiempo: 2 horas Prioridad: 15 HU09: Vizualizar una precuenta . . Tiempo: 7 horas Prioridad:8 HU08: Loguear Usuarios con Privilegios Como dueño del restaurante quiero que el sistema me permita loguear por privilegios diferenciando entre administrador y cajero. Como dueño del restaurante quiero ver antes de generar una factura o boleta una pre cuenta que se pueda visualizar. aquí brindaremos un resumen general y original de cada paso que hemos necesitado para poner en marcha y tener un óptimo resultado en nuestro proyecto.

. 4. el Scrum Master Elard Torres Silva y el Product Owner Aldo de la Cruz Flores.1. Sprint Backlog Aquí se mostrará la lista de tareas asociadas con las historias de usuario incluidas en todos los sprint. Típicamente la precisión de las estimaciones va a variar dependiendo de las habilidades del equipo. El esfuerzo estimado se expresa en términos de los criterios de estimación acordados por el equipo. Crear entregables Crear Entregables El equipo principal de Scrum está conformado por el Equipo Scrum Junior Huari Zanca.

SCRUMBOARD
El equipo elaboró esta lista de tareas e historia de usuarios en cada parte del
proyecto y en base de la reunión de planificación de la iteración La lista va
evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente) a medida
que la iteración avanza, especialmente durante la reunión diaria de sincronización.
Los tableros que se mostraron en cada sprint reflejan como nos a servido esta
herramienta como radiador de información tanto para el equipo como para
cualquier otra persona relacionada con el proyecto.

IMPEDIMENT LOG
Los obstáculos o barreras que reducieron la productividad del Equipo Scrum
mostraremos a continuación . hay muchos tipos de impedimentos que siguiendo
un modelo Scrum aparecen y hacen que el contenido ( en funcionalidad de
producto) del Sprint se vea reducido o alterado. Mostraremos algunos de los
cuales retraso nuestros avances.
Reuniones muy largas que afectaron al equipo ya que se estaba trabajando en
el Sprint y por tanto les hacen perder tiempo para dedicarse a lo planificado en el
Sprint.

Enfermedad de un miembro del equipo. Inasistencia de algún integrante del
equipo por motivo de salud.

inestabilidad de Hardware y/o Software : cuando el sistema operativo de uno de
nuestros ordenadores falló retazando el trabajo esto afectó ya que el Sprint se
encontraba en pruebas de integración.

el IDE. lo cual se solucionó por la intervención rápida del product owner y scrum master. la cual utilizando el marco de trabajo de scrum el proyecto avanzará por incrementos distribuido de la siguiente manera: . Problemas con las herramientas : Algunos problemas con las herramientas que usábamos al inicio del proyecto para el desarrollo. mal entendidas por el equipo son también ffue un impedimento para el desarrollo. CRONOGRAMA El plazo propuesto para concluir con el proyecto gestión de pedidos es de 2 meses.Backlog poco concreto : falta de detalle en las historias de usuario.

2. En la cual todos los miembros del equipo nos reunimos aquí se busca que todos los integrantes del Equipo Scrum estén presentes. ¿Qué he hecho desde la última reunión? 2. . Sin embargo. la reunión no se cancela o se retrasa si uno o más miembros no pueden asistir. 4. tales discusiones sucedieron después de la reunión a fin de garantizar que el Daily Standup y que sea breve para dar un reporte sobre su progreso en el sprint y planificar las actividades del día. En la reunión cada miembro del Equipo Scrum da respuesta a las tres preguntas diarias las cuales son: 1. . ¿Qué tengo planeado hacer antes de la siguiente reunión? 3. Realizar daily standup Realizar Daily Standup El Daily Standup es la breve reunión diaria con un time-box de 15 minutos. ¿Qué impedimentos u obstáculos (si los hubiera) estoy enfrentando en la actualidad? Se recomiendan los debates entre el Scrum Master y el equipo o entre los miembros del Equipo Scrum.

ya que incluye riesgos identificados y evaluados relacionados al proyecto. riesgo o incertidumbre y dependencias. este se considera como entregable rechazado . El siguiente Backloglink llevara aldel Priorizado backlog priorizado Producto Entregables rechazados En en nuestro proyecto no existe entregables rechazados. simplemente permanecen en el Backlog Priorizado del Producto y no se marcan como terminados. pero en el caso que exista en ciertos proyectos se da porque un entregable no cumple con los criterios de aceptación. También incluye cambios aprobados que pueden ser priorizados adecuadamente en el Backlog Priorizado del Producto. Refinar el backlog priorizado del producto Refinar el Backlog Priorizado del Producto Backlog Priorizado del Producto El Backlog Priorizado del Producto se basa en tres factores principales: valor. Los entregables rechazados generalmente no se mantienenen una lista por separado. Reuniones de revisión del Backlog Priorizado del Producto El Product Owner Aldo de la Cruz a tenido varias reuniones por separado con los stakeholders relevantes.3. 4. También se le conoce como Backlog Priorizado del Producto del riesgo ajustado. con el ScrumMaster y con el Equipo Scrum a fin de asegurarse de contar con la información .

al ver que la priorización de este. Además hemos dado visto bueno incorporar ese nuevo cambio al Sprint que presentaremos. es la incorporación de lo que es una visualización de una pre- cuenta. Solicitudes de cambio aprobadas Los cambios que el cliente ha manifestado luego de la presentación del entregable del segundo Sprint. es mucho mas alta que las ultimas historias a elegir . . gracias a ello se ha cumplido con todas las historias de usuario de la mejor manera. según el cliente. Este nuevo cambio esta especificado tanto en la segunda épica de este Sprint y Historia numero 09 dentro de lo que es la pila del producto.suficiente para actualizar el Backlog Priorizado del Producto en el proceso de su refinamiento. por el echo que esta relacionado con el pedido del cliente y la creación de factura y boleta.

Demostrar y validar el sprint Demostrar y Validar el Sprint 1. del cual analizándolos y realizándolo su respectivo estudio tenemos las acciones preventivas para tal caso y de esa manera no tener problemas en el desarrollo de nuestro proyecto. Equipo principal de Scrum Equipo SCRUM . Revisión y retrospectiva 5.Riesgos identificados Los riesgos que mostramos a continuación son los que descubrimos al iniciar el proyecto.1. 5.

Tal vez no exista un lanzamiento programado al final de cada iteración del sprint. un lanzamiento puede planificarse después de completar todos los sprint. Criterio de aceptación de las Criterios de historias del usuario Aceptación Sprint 2 Criterios de Aceptación Sprint 3 Criterios de Aceptación Sprint 4 5. Entregables Sprint 2 Entregables Sprint 3 Entregables Sprint 4 3. Stakeholder(s) Identificacion Stakeholders 6. Entregables del sprint Al final de cada sprint completamos un incremento de producto o entregable. En ocasiones. Cronograma de planificación del lanzamiento El cronograma de planificación del lanzamiento de nuestro proyecto es una de las fases más importantes del proceso indica cuáles entregables serán entregados al cliente.2. El entregable incluyo todas las características y funcionalidades definidas en las historias de usuario que se incluyen en cada sprint la cuales fueron evaluadas Entregables Sprint 1 satisfactoriamente. así como los intervalos planificados y fechas para los lanzamientos. . Sprint Backlog Tareas e historia de usuario 4.

El objetivo fue mejorar de manera continua la productividad y la calidad al entregar un producto y los incrementos que se fueron agregando conforme el producto se fue desarrollando. donde el lanzamiento se da en una fecha predefinida. Dependiendo de la estrategia de la organización. Las reuniones diarias son cruciales para encaminar al proyecto por el camino de la perfección porque de esa manera se corrige errores se agregan nuevas cosas se eliminan riesgos 3. El proyecto nos ayudo a conocer las mejores practicas de desarrollo de la metodología ágil en Scrum.2. 2. como equipo aprendimos a analizar las etapas mas sensibles al desarrollar el sprint y de que manera contrarrestar los riesgos que se presentan en todo proyecto. . Riesgos identificados 5. Entregables link 7. las sesiones de la planificación del lanzamiento en los proyectos pueden estar guiadas por la funcionalidad donde el objetivo es la entrega una vez que se ha desarrollado un conjunto predeterminado de funcionalidades. o bien. Retrospectiva del sprint Retrospectiva del Sprint 1. la planificación puede estar impulsada por la fecha.

Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. Hay que darles el entorno y el apoyo que necesitan. Principio 5 Los proyectos se desarrollan en torno a individuos motivados. y confiarles la ejecución del trabajo. Principios Scrum PRINCIPIOS SCRUM Principio 1 Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continuada de software con valor. Principio 9 La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad. Principio 3 Entregamos software funcional frecuentemente. o el arte de maximizar la cantidad de trabajo no realizado. con preferencia por periodos de tiempo lo más corto posibles. Principio 8 Los procesos Ágiles promueven el desarrollo sostenible. . desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. Principio 2 Aceptamos que los requisitos cambien. Principio 10 La simplicidad. Principio 6 El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara. Principio 4 Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.6. Los promotores. es esencial. Principio 7 El software funcionando es la principal medida progreso. entre dos semanas y un mes. incluso en etapas tardías del desarrollo.

1. Entregables ENTREGABLES ENTREGABLE 1ER SPRINT: link ENTREGABLE 2DO SPRINT: link ENTREGABLE 3ER SPRINT: link ENTRETABLE 4TO SPRINT: link . Manuales de usuario MANUALES DE USUARIO: MANUAL DE USUARIO 1ER SPRINT: link MANUAL USUARIO 2DO SPRINT: link MANUAL USUARIO 3ER SPRINT: link MANUAL USUARIO 4TO SPRINT: link 7. Principio 12 A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. 7.Principio 11 Las mejores arquitecturas.2. requisitos y diseños emergen de equipos auto-organizados. Lanzamiento 7.