DISEÑO E IMPLEMENTACIÓN DE UN SOFTWARE ORIENTADO A LA WEB

PARA LA GESTIÓN DE RECETAS, CONTROL DE INVENTARIO Y COSTEO

PARA RESTAURANTE.

JULIAN ANDRES PATIÑO MARIN

LUIS ALFONSO ZULETA GIRALDO

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y CIENCIAS
DE LA COMPUTACIÓN
PROGRAMA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
PEREIRA
2016
 DISEÑO E IMPLEMENTACIÓN DE UN SOFTWARE ORIENTADO A LA WEB
PARA LA GESTIÓN DE RECETAS, CONTROL DE INVENTARIO Y COSTEO
PARA RESTAURANTE.

JULIAN ANDRES PATIÑO MARIN

LUIS ALFONSO ZULETA GIRALDO

PROYECTO DE GRADO PARA OPTAR AL TÍTULO DE

INGENIERO DE SISTEMAS Y COMPUTACIÓN

CARLOS ALBERTO OCAMPO SEPULVEDA

INGENIERO DE SISTEMAS Y COMPUTACIÓN
ASESOR DE PROYECTO DE GRADO

UNIVERSIDAD TECNOLÓGICA DE PEREIRA

FACULTAD DE INGENIERÍAS ELÉCTRICA, ELECTRÓNICA, FÍSICA Y CIENCIAS
DE LA COMPUTACIÓN
PROGRAMA INGENIERÍA DE SISTEMAS Y COMPUTACIÓN
PEREIRA
2016
 AGRADECIMIENTOS

Quiero agradecer a mi familia por el apoyo durante todo el tiempo que me acompañaron
en esta etapa de mi vida, a mis tíos por su ayuda y hospitalidad en estos años. Agradecer
amigos y docentes que me ayudaron el crecimiento profesional, especialmente a Paola
Agudelo, que sus regaños constantes levantaban mis ánimos. A mi amiga Alejandra Parra
que fue la mejor compañía de todos estos años. A mi compañero Nelson Escobar, por
toda lo que aprendí a su lado, su conocimiento tan amplio aun me sorprende cada día y a
Bryan Moreno con el que disfrute muchos pasos adentro y fuera del campus. En especial
agradecimiento a Julián Patiño mi compañero de proyecto de grado, un gusto culminar
esta etapa juntos y espero que tenga una buena vida ingeniero y al ingeniero Carlos
Alberto Ocampo que nos asesoró y acompaño en la construcción del proyecto. La verdad
tengo muchas personas que agradecer por tantos momentos de alegrías y tristezas, y
aunque es muy grande la lista agradezco a todos aquellos futuros ingenieros con los que
compartí mi etapa universitaria. Mis primos Daniela, Camila, Nathalia, Sofía, Nicolás y
mi ahijada Salome que han sido mi fuente de motivación cada día. Llegue aquí derrotado
por mis pensamientos y me voy como el ganador que mis padres han luchado toda su
vida, desde el primer día que partí de casa ellos han estado pendientes de mí y nunca falto
una llamada desde lejos, gracias a mis padres y sobre todo mi viejo que espero este
momento como un sueño propio. Lo logre papá.
Luis Alfonso Zuleta Giraldo.

Agradecimientos a mi familia, en especial a mis padres que me han acompañado a pesar

de las adversidades en mi vida universitaria, ellos me han brindado apoyo moral en los
momentos de intento de deserción y esto es lo que más agradezco porque me ha ayudado
a tener tenacidad en los capítulos más difíciles. También quiero agradecer al ingeniero
Carlos Alberto Ocampo que fue la persona que nos guio en esta etapa de culminación y
obviamente también a todos los otros profesores que hicieron su mejor esfuerzo para que
lográramos adquirir los fundamentos necesarios para enfrentar la vida laboral. También
me dirijo a mis amigos Luis Alfonzo Zuleta, Juan Ernesto Rico, Juan Sebastián Herrera
y Johany Quintero por todos esos momentos gratificantes y que nunca llegaré a olvidar.
Gracias a todos.
Julián Andrés Patiño Marín.
 TABLA DE CONTENIDO

1. INTRODUCCIÓN ............................................................................................. 1
2. CAPÍTULO I – GENERALIDADES ................................................................... 2
2.1. PLANTEAMIENTO DEL PROBLEMA ............................................................ 2
3. JUSTIFICACIÓN .............................................................................................. 4
4. OBJETIVOS ..................................................................................................... 5
4.1. OBJETIVO GENERAL ................................................................................... 5
4.2. OBJETIVO ESPECÍFICOS ............................................................................ 5
5. ALCANCE DEL PROTOTIPO A DESARROLLAR ............................................ 6
6. CAPÍTULO II - MARCO REFERENCIAL .......................................................... 7
6.1. METODOLOGIA ............................................................................................ 7
6.1.1. INGENIERÍA DE SOFTWARE .................................................................. 7
6.1.2. PROCESO DE SOFTWARE..................................................................... 8
6.1.3. MODELO DE PROCESOS DE DESARROLLO DE SOFTWARE ............. 9
6.1.3.1 MODELO POR PROTOTIPOS ............................................................. 9
6.1.3.1.1. CICLO DE VIDA DE UN SISTEMA BASADO EN PROTOTIPO ... 10
6.1.4. METODOLOGÍAS ÁGILES ..................................................................... 11
6.1.4.1. PROGRAMACIÓN EXTREMA .......................................................... 12
6.1.5. LEVANTAMIENTO Y ANÁLISIS DE REQUERIMIENTOS ...................... 13
6.1.5.1. HISTORIAS DE USUARIO ................................................................ 14
6.1.6. DISEÑO DE SOFTWARE ....................................................................... 15
6.1.6.1. UML (LENGUAJE UNIFICADO DE MODELADO) ............................. 15
6.1.6.1.1. CASOS DE USO .......................................................................... 17
6.1.6.1.2. DIAGRAMA DE CLASES ............................................................. 17
6.1.6.1.3. DIAGRAMA DE COMPONENTES ............................................... 18
6.1.6.1.4. DIAGRAMA DE ACTIVIDADES ................................................... 18
6.1.6.1.5. DIAGRAMA DE DESPLIEGUE .................................................... 18
6.1.6.2. MODELO RELACIONAL ................................................................... 18
6.1.6.3. ARQUITECTURA DE SOFTWARE ................................................... 19
6.1.6.3.1. MODELO VISTA CONTROLADOR .............................................. 19
6.1.7. CODIFICACIÓN ..................................................................................... 20
6.1.8. PRUEBAS .............................................................................................. 20
 6.1.9. ENTREGA .............................................................................................. 21
6.1.10. ESTÁNDARES WEB ............................................................................ 21
6.1.10.1. HTML .............................................................................................. 21
6.1.10.2. CSS ................................................................................................. 21
6.1.10.3. PYTHON ......................................................................................... 21
6.1.10.4. FRAMEWORK................................................................................. 22
6.1.10.4.1. DJANGO .................................................................................... 22
6.1.10.5. MYSQL .............................................................................................. 23
6.2. DESARROLLO ............................................................................................ 23
6.2.1. RECETA DE COCINA .......................................................................... 23
6.2.1.1. NOMBRE DE LA RECETA ................................................................ 23
6.2.1.2. PORCIONES ..................................................................................... 24
6.2.1.3. ANÁLISIS NUTRICIONAL ................................................................. 24
6.2.1.4. TIEMPO DE PREPARACIÓN ............................................................ 24
6.2.1.5. TIEMPO DE COCCIÓN ..................................................................... 24
6.2.1.6. INGREDIENTES ............................................................................... 25
6.2.1.7. INDICACIONES ................................................................................ 25
6.2.2. COMENSAL ........................................................................................... 25
6.2.3. GASTRONOMÍA..................................................................................... 25
6.2.4. ADMINISTRADOR DE COCINA ............................................................. 26
6.2.5. CHEF ..................................................................................................... 26
6.2.6. ALMACÉN .............................................................................................. 26
6.2.7. BODEGA ................................................................................................ 27
6.2.8. ALIMENTO PERECEDERO ................................................................... 27
6.2.9. ALIMENTO NO PERECEDERO ............................................................. 27
6.2.10. MENÚ ................................................................................................... 28
7. CAPÍTULO III - OTRAS CONSIDERACIONES ................................................. 29
7.1. SITUACION LEGAL Y NORMATIVO ........................................................... 29
7.2. GEOLOCALIZACIÓN................................................................................... 29
8. CAPÍTULO IV - DEFINICIÓN DE LOS REQUERIMIENTOS DEL SISTEMA ..... 30
8.1. LEVANTAMIENTO DE REQUERIMIENTOS................................................ 30
8.1.1. HISTORIAS DE USUARIO ..................................................................... 32
8.2. DISEÑO DEL SISTEMA .............................................................................. 32
 8.2.1. VISTA DE ESCENARIOS (CASOS DE USO) ......................................... 32
8.2.2. VISTA DE PROCESOS (DIAGRAMA DE ACTIVIDADES)...................... 36
8.2.3. VISTA LOGICA (DIAGRAMAS DE CLASES) ......................................... 36
8.2.4. VISTA DE DESARROLLO (DIAGRAMA DE COMPONENTES) ............. 37
8.2.5. VISTA FISICA (DIAGRAMA DE DESPLIEGUE) ..................................... 38
8.3. MODELO RELACIONAL .............................................................................. 38
9. CONCLUSIONES ............................................................................................. 40
10. RECOMENDACIONES ................................................................................... 41
11. BIBLIOGRAFÍA ............................................................................................... 42
12. WEB-GRAFÍA ................................................................................................. 43
 LISTA DE DIAGRAMAS

DIAGRAMA DE CASO DE USO: ROOT .......................................................................... 33

DIAGRAMA DE CASO DE USO: CHEF........................................................................... 34
DIAGRAMA DE CASO DE USO: MESERO..................................................................... 35
DIAGRAMA DE ACTIVIDADES # 1: INICIO DE SECCION ......................................... 68
DIAGRAMA DE ACTIVIDADES # 2: RECUPERAR CONTRASEÑA ........................... 69
DIAGRAMA DE ACTIVIDADES # 3: CREAR USUARIO .............................................. 70
DIAGRAMA DE ACTIVIDADES # 4: EDITAR USUARIO............................................. 71
DIAGRAMA DE ACTIVIDADES # 5: CONSULTAR USUARIO ................................... 72
DIAGRAMA DE ACTIVIDADES # 6: ELIMINAR USUARIO ........................................ 73
DIAGRAMA DE ACTIVIDADES # 7: ORDENES EN COLA ......................................... 74
DIAGRAMA DE ACTIVIDADES # 8: SERVIR ORDEN ................................................. 75
DIAGRAMA DE ACTIVIDADES # 9: FACTURAR ORDEN .......................................... 76
DIAGRAMA DE ACTIVIDADES # 10: ESCOGER PLATO ............................................ 77
DIAGRAMA DE ACTIVIDADES # 11: PREPARAR PLATO ......................................... 78
DIAGRAMA DE ACTIVIDADES # 12: CREAR MENU .................................................. 79
DIAGRAMA DE ACTIVIDADES # 13: ELIMINAR MENU ............................................ 80
DIAGRAMA DE ACTIVIDADES # 14: SELECCIONAR MENU .................................... 81
DIAGRAMA DE ACTIVIDADES # 15: INVENTARIO ................................................... 82
DIAGRAMA DE ACTIVIDADES # 16: VER MENU DEL DIA ...................................... 83
DIAGRAMA DE ACTIVIDADES # 17: TOMAR ORDEN ............................................... 84
DIAGRAMA DE ACTIVIDADES # 18: AÑADIR ORDEN .............................................. 85
 LISTA DE TABLAS

Tabla 1: Historia de usuario 1............................................................................................... 45

Tabla 2: Historia de usuario 2............................................................................................... 45
Tabla 3: Historia de usuario 3............................................................................................... 46
Tabla 4: Historia de usuario 4............................................................................................... 46
Tabla 5: Historia de usuario 5............................................................................................... 47
Tabla 6: Historia de usuario 6............................................................................................... 47
Tabla 7: Historia de usuario 7............................................................................................... 48
Tabla 8: Historia de usuario 8............................................................................................... 48
Tabla 9: Historia de usuario 9............................................................................................... 49
Tabla 11: Historia de usuario 11........................................................................................... 49
Tabla 12: Historia de usuario 12........................................................................................... 49
Tabla 13: Historia de usuario 13........................................................................................... 50
Tabla 14: Historia de usuario 14........................................................................................... 50
Tabla 15: Historia de usuario 15........................................................................................... 50
Tabla 16: Historia de usuario 16........................................................................................... 51
Tabla 17: Historia de usuario 17........................................................................................... 51
Tabla 18: Historia de usuario 18........................................................................................... 51
Tabla 19: Historia de usuario 19........................................................................................... 52
Tabla 20: Historia de usuario 20........................................................................................... 52
Tabla 21: Historia de usuario 21........................................................................................... 53
Tabla 22: Historia de usuario 22........................................................................................... 53
Tabla 23: Historia de usuario 23........................................................................................... 53
Tabla 24: Caso de uso #1...................................................................................................... 55
Tabla 25: Caso de uso #2...................................................................................................... 55
Tabla 26: Caso de uso #3...................................................................................................... 56
Tabla 27: Caso de uso #4...................................................................................................... 57
Tabla 28: Caso de uso #5...................................................................................................... 58
Tabla 29: Caso de uso #6...................................................................................................... 59
Tabla 30: Caso de uso #7...................................................................................................... 60
Tabla 31: Caso de uso #8...................................................................................................... 61
Tabla 32: Caso de uso #9...................................................................................................... 62
Tabla 33: Caso de uso #10.................................................................................................... 62
Tabla 34: Caso de uso #11.................................................................................................... 63
Tabla 35: Caso de uso #12.................................................................................................... 64
Tabla 36: Caso de uso #13.................................................................................................... 65
Tabla 37: Caso de uso #14.................................................................................................... 66
Tabla 38: Caso de uso #15.................................................................................................... 67
 LISTA DE ANEXOS

ANEXO 1 ............................................................................................................................. 45
HISTORIAS DE USUARIO ................................................................................................ 45
ANEXO 2 ............................................................................................................................. 54
ESPECIFICACIONES DE CASOS DE USO ...................................................................... 54
ANEXO 3 ............................................................................................................................. 68
DIAGRAMA DE ACTIVIDADES ...................................................................................... 68
ANEXO 4 ............................................................................................................................. 86
MODELO RELACIONAL .................................................................................................. 86
ANEXO 5 ............................................................................................................................. 89
PLAN DE PRUEBAS DE APLICACIÓN MISTER CHEF ................................................ 89
 1. INTRODUCCIÓN

Con los sistemas informáticos de hoy en día es posible aprovechar los recursos
disponibles que cada vez evolucionan de manera más precoz, y hacer más fácil el camino
para encontrar soluciones que sean útiles a los problemas de la sociedad.
Los aplicativos web 1 (web-based application) es un tipo especial de aplicación
cliente/servidor, donde el cliente (navegador o explorador) como el servidor (el servidor
web) y el protocolo que se comunican (HTTP) están estandarizados y no han de ser
creados por el programador de aplicaciones. Es una herramienta importante para
desarrollar aplicativos para manejo accesible y fácil entendimiento en el usuario, que
utilizamos para la creación del software implementado al chef o administrador de un
restaurante.

Entonces nos preguntamos, ¿Hasta qué punto son útiles las aplicaciones actuales para
chef? ¿Pueden estas aplicaciones agilizar las tareas relacionadas con la cocina? ¿Será que
estas aplicaciones tienen todo lo que necesita un verdadero chef o más aún, un
restaurante? Google Play ofrece muchas aplicaciones con variedad de recetas para llevar a
cabo, donde se exponen listas de materiales y modos de preparación, y en muchos casos
además de fotografías, también se incluyen comentarios de los usuarios de apps, acerca de
los resultados obtenidos al realizar las recetas. 2 Dada una gran lista de aplicaciones
alojada en la web, muchas de estas o la mayoría están orientadas a los cocineros amateur
y además su funcionalidad va orientada solo a la gestión de recetas, entonces creemos que
sería bueno para los negocios como los hoteles y restaurantes un aplicativo que aparte de
la gestión de recetas, controle el inventario y costeo de productos para la cocina.

1
Sergio Luján Mora. Programación de aplicaciones web: historia, principios básicos y clientes web, Editorial Club Universitario,
2002, p. 48
2
La mejores apps de Android para cocineros amateur ..." 2014. 19 Oct. 2015 <http://www.androidexperto.com/aplicaciones-
android/mejores-apps-android-cocineros/>
1
 2. CAPÍTULO I – GENERALIDADES

2.1. PLANTEAMIENTO DEL PROBLEMA

Los chefs y/o administradores de un restaurante de hoy en día, tienen a la mano el uso de
la tecnología para solución de problemas de administración o innovación de manera más
fácil en el control y uso de la cocina. Pero aún se encuentran problemas causados en la
preparación de platos del menú.

En el momento de elaborar un platillo se presenta en algunos casos, que la poca

información que se tiene sobre la cantidad total de los ingredientes, no exista una
advertencia para tomar medidas inmediatas para reemplazar el ingrediente escaseado o
una comunicación oportuna con el proveedor de suministros, logran que no se cumpla el
objetivo y por consiguiente la insatisfacción del cliente o comensal.

Este problema se da a causa de un mal manejo en el control de inventario de bodega de

cocina y también, por aquellos productos o ingredientes que se encuentran en la bodega.
En su mayoría, estos productos cuentan con fecha de vencimiento por tener un rango de
tiempo muy corto, lo que la hace la causa primordial y de riesgo; lograr una solución a
estas causas del problema, ayudará a evitar pérdidas económicas, de salubridad y sobre
todo una mala imagen publicitaria que los clientes o comensales puede dar hacia el
negocio.

Por otro lado, se puede ha comprobado que otro problema recurrente es el exceso de
comida que no se utiliza, y en ese caso se tenga que desperdiciar. Dejando en un segundo
plano los efectos que causa en lo económico, administrativo o publicitario, el desperdicio
de comida es un problema muy grave que afecta a la sociedad.

Un ejemplo de desperdicio es el problema que se presenta en los restaurantes españoles,

donde la mala previsión a la hora de hacer la compra ocasiona gran cantidad de alimento
elaborado que se desperdicia. Los establecimientos encargan más cantidad de la que
precisan, hasta el punto de que el 60% de lo que tiran a la basura es fruto de ese error de
cálculo 3. Los restaurantes necesitan una manera ágil y eficiente de realizar los cálculos de
cuánta materia prima deben comprar, y de esta manera se puede evitar el derroche de
comida y consigo disminuir los costos para el negocio.

3
"Los restaurantes tiran 63.000 toneladas de comida ... - Público." 2014. 25 Nov. 2015 <http://www.publico.es/espana/restaurantes-
tiran-63-000-toneladas.html>

2
Según la FAO (Organización de las Naciones Unidas para la Alimentación y la
Agricultura) cada año los alimentos que producimos pero luego no comemos consumen
un volumen de agua equivalente al caudal anual del Volga y son responsables de añadir 3
300 millones de toneladas de gases de efecto invernadero a la atmósfera del planeta;
entonces el problema del derroche en la compra de alimentos genera consecuencias
ambientales que a futuro van a ser de gran preocupación porque la tierra va a llegar hasta
el punto que ya no puede dar abasto en la producción de alimentos 4.

El Subsecretario General de la ONU y Director Ejecutivo el Programa de Naciones

Unidas para el Medio Ambiente (PNUMA), Achim Steiner, señaló por su parte que: "El
PNUMA y la FAO han identificado la pérdida y el desperdicio de alimentos -el
despilfarro- como una gran oportunidad para que los países hagan una transición hacia
una economía verde inclusiva, de bajas emisiones de carbono y eficiente en el uso de los
recursos. El excelente informe presentado hoy por la FAO destaca los múltiples
beneficios que pueden obtenerse -en muchos casos a través de medidas sencillas y
sensatas en por ejemplo hogares, comercios, restaurantes, escuelas y empresas- y que
pueden contribuir a la sostenibilidad del medio ambiente, mejoras económicas, a la
seguridad alimentaria y la realización del Desafío Hambre Cero del Secretario General de
las Naciones Unidas.

Todo se centra a un descontrol del cálculo en las cantidades necesarias de los ingredientes
en la elaboración de un plato del menú, los chefs o administradores de cocina son
personas y como personas cometen errores ocasionando estos problemas que afecta tanto
al restaurante en lo económico como la comunidad en lo social con el desperdicio de
alimentos.

4
"FAO - Noticias: El desperdicio de alimentos daña al clima, el ..." 2013. 25 Nov. 2015
<http://www.fao.org/news/story/es/item/196368/icode/>

3
 3. JUSTIFICACIÓN

En el proceso de la elaboración de los platos del menú de un restaurante, se realiza la

digitalización, administración y un manejo en los ingredientes desde la bodega con el fin
de hacer más óptima la utilización de cada uno de los productos, evitando así el
desperdicio o escasez de comida que afecte la parte interna y externa del negocio.

La implementación del software de gestión de recetas es un apoyo en la preparación de

los platos del menú de manera sencilla, eficaz, monitoreada y segura, permitiendo la
reducción de costos y tiempos muertos en su elaboración. Obteniendo la información
adecuada para ahorrar costos y pérdidas, en especial las pérdidas de productos y bajar los
altos índices de desperdicio utilizados en su preparación, sin que se perjudique o deteriore
la calidad del plato.

Solucionando los problemas mencionados anteriormente se logra poder agilizar los

procesos del restaurante a un beneficio económico, obtener un mejor nivel de vida para
lograr desperdiciar menos comida que otros puedan acceder a ella y consumirla, entonces
obtenemos una mayor calidad en la prestación del servicio y beneficio hacia la comunidad
y buena imagen al negocio.

4
 4. OBJETIVOS

4.1. OBJETIVO GENERAL

Desarrollar un software orientado a la web de gestión de recetas, inventario y costeo para
restaurante.

4.2. OBJETIVO ESPECÍFICOS

● Realizar levantamiento de requerimientos.
● Realizar análisis detallados de los requerimientos y restricciones.
● Realizar diseño UML del sistema.
● Implementar módulos para el manejo y control de pedidos, recetas e inventario de
bodega.
● Diseñar plan de pruebas para los módulos respectivos.

5
 5. ALCANCE DEL PROTOTIPO A DESARROLLAR

Este documento es un desarrollo de análisis y procesos para lograr con éxito la

construcción del software dedicado a la gestión de recetas del restaurante, utilizando
metodologías de levantamientos de requerimientos para conocer sobre la elaboración de
los platos, el seguimiento del proceso desde que se pide la orden, su preparación y la
cierre de la cuenta con el total de pedido del cliente.

El control y manejo sobre el inventario antes posibilidades de escasez y/o desperdicio de

los alimentos, todo desarrollado por técnicas de ingeniería de software utilizando como
implementación de la metodología Programación extrema (XP), vistas 4+1, el diseño de
un plan de pruebas y los manuales necesarios para mejor entendimiento al usuario. El
aplicativo se compone de los siguientes módulos de funcionalidad y sus respectivas
funciones:

• Módulo de gestión de usuarios. Es el encargado de la autenticación de los

usuarios y de la administración de sus respectivos perfiles.
• Módulo de gestión de recetas. Se utiliza para llevar a cabo la preparación de
comidas realizando los cálculos de cantidad de cada ingrediente dependiendo del
número de platos que se desee preparar, además actualiza el inventario una vez
que se ha culminado con esta tarea.
• Módulo de inventario. Realiza las consultas a la disponibilidad de ingredientes
en bodega, así como también la actualización de estos y la generación de la alarma
en caso de que las existencias empiecen a agotar.
• Módulo de órdenes. Se encarga de tomar órdenes y añadir más platos del menú o
productos del restaurante a su respectiva mesa.

6
 6. CAPÍTULO II - MARCO REFERENCIAL

6.1. METODOLOGIA
En esta sección se presentan cada uno de los conceptos, procedimientos y herramientas
que se utilizaron en la construcción del aplicativo del sistema (lenguajes de programación,
técnicas de desarrollo, metodologías entre otros).

6.1.1. INGENIERÍA DE SOFTWARE

¿Qué es el Software?
El software de una computadora es el producto que construye los programadores
profesionales y al que después le dan mantenimiento durante un largo tiempo. Incluyen
programas que se ejecutan dentro de una computadora de cualquier tamaño y arquitectura,
contenido que se presenta a medida de que se ejecutan los programas de cómputo e
información descriptiva tanto en una copia dura como en formatos virtuales que engloban
virtualmente a cualesquiera medios electrónicos. La ingeniería de software está formada
por un proceso, un conjunto de métodos (prácticas) y un arreglo de herramientas que
permite a los profesionales elaborar software de cómputo de alta calidad 5.

En la actualidad, el software tiene un papel dual. Es un producto y al mismo tiempo es el

vehículo para entregar un producto. En su forma de producto, brinda el potencial de
cómputo incorporado en el hardware del cómputo o, con más amplitud, en una red de
computadoras a las que se accede por medio de un hardware loca. Ya sea que resida en un
teléfono móvil u opere en el interior de una computadora central, el software es un
transformador de información -produce, administra, adquiere, modifica, despliegue o
transmite información que puede ser tan simple como un solo bit o tan compleja como
una presentación con multimedios generada a partir de datos obtenidos de decenas de
fuentes independientes-. Como vehículo utilizado para distribuir el producto, el software
actúa como la base para el control de la computadora (sistemas operativos), para la
comunicación de información (redes) y para la creación y control de otros programas
(herramientas y ambientes de software).

El software distribuye el producto más importante de nuestro tiempo: información.

Transforma los datos personales (por ejemplo, las transacciones financieras del individuo)
de modo que puedan ser más útiles en un contexto local, administra la información de
negocios para mejorar la competitividad, provee una vía para las redes mundiales de
información (el internet) y brinda los medios para obtener la información en todas sus
formas 6.

5
Roger S. Pressman. Ingeniería del Software Un enfoque moderno, McGrawHill, 2010, p. 28
6
ibidem, p. 30.
7
¿Qué es la Ingeniería de Software?
La ingeniería de software es una disciplina de la ingeniería que comprende todos los
aspectos de la producción del software desde las etapas iniciales de la especificación del
sistema, hasta el mantenimiento de éste después de que se utiliza. En esta definición,
existen dos frases claves:

1. Disciplina de ingeniería. Los ingenieros hacen que las cosas funcionen.

Aplican teorías, métodos y herramientas donde sean convenientes, pero las
utilizan de forma selectiva y siempre tratando de descubrir soluciones a los
problemas, aun cuando existan teorías y métodos aplicables para
resolverlos. Los ingenieros también saben que deben trabajar con
restricciones financieras y organizacionales, por lo que buscan soluciones
tomando en cuenta restricciones.
2. Todos los aspectos de producción del software. La ingeniería del software
no sólo comprende los procesos técnicos de desarrollo de software, sino
también con actividades tales como la gestión de proyectos de software y
desarrollo de herramientas, métodos y teorías de apoyo de producción de
software 7.

6.1.2. PROCESO DE SOFTWARE

Un proceso es un conjunto de actividades, acciones y tareas que se ejecutan cuando va a
crearse algún producto del trabajo. Una actividad busca lograr un objetivo amplio (por
ejemplo, comunicación con los participantes) y se desarrolla sin importar el dominio de la
aplicación, tamaño del proyecto, complejidad del esfuerzo o grado de rigor con el que se
usará la ingeniería del software. Una acción (diseño de la arquitectura) es un conjunto de
tareas que producen un producto importante de trabajo (por ejemplo, un modelo de diseño
de la arquitectura). Una tarea se centra en un objetivo pequeño pero bien definido (por
ejemplo, realizar una prueba unitaria) que produce un resultado tangible.

La estructura del proceso establece el fundamento el proceso completo de la ingeniería de

software por medio de la identificación de un número pequeño de actividades
estructurales que sean aplicables a todos los proyectos de software, sin importar su
tamaño o complejidad. Una estructura del proceso general para la ingeniería de software
consta de cinco actividades:

Comunicación. Antes de que comience cualquier trabajo técnico, tiene importancia

crítica comunicarse y colaborar con el cliente (y con otros participantes). Se busca

7
Ian Sommerville. Ingeniería del Software, PEARSON Educación, 2005, p. 23
8
entender los objetivos de los participantes respecto del proyecto, y reunir los
requerimientos que ayuden a definir las características y funciones del software.

Planeación. Cualquier viaje complicado se simplifica si existe un mapa. Un proyecto de

software es un viaje difícil, y la planeación crea un “mapa” que guía al equipo mientras
viaja. El mapa -llamado plan del proyecto de software- define el trabajo de ingeniería de
software al describir las tareas técnicas por realizar, los riesgos probables, los recursos
que se requieren, los productos del trabajo que se obtendrán y una programación de las
actividades.

Modelado. Crea un “bosquejo” del objeto por hacer en fin entender el panorama general.
Si se requiere, refine el bosquejo con más y más detalles en un esfuerzo por comprender
mejor el problema y cómo resolverlo. Un ingeniero de software hace lo mismo al crear
modelos a fin de entender mejor los requerimientos del software y el diseño los satisfará.

Construcción. Esta actividad combina la generación de código (ya sea manual o

automatizada) y las pruebas que se requieren para descubrir errores en este.

Despliegue. El software (como entidad completa o como un incremento parcialmente

terminado) se entrega al constructor que lo evalúa y que le da retroalimentación, misma
que se basa en dicha evaluación 8.

6.1.3. MODELO DE PROCESOS DE DESARROLLO DE SOFTWARE

6.1.3.1 MODELO POR PROTOTIPOS

Los prototipos nacieron como un método para acelerar la definición de los requisitos de
software por construir. Un prototipo es un programa. La idea principal es hacer un modelo
de la aplicación y presentarla al cliente, sobre todo su nivel de interfaces y otras salidas
(consultas, reportes). El cliente hará sus observaciones acerca de lo que ve en ese modelo,
y el programador modificara ese modelo de acuerdo con dichas observaciones. El proceso
se repite hasta alcanzar cubrir todos los requerimientos del producto de un software,
pasándose luego a construir la aplicación (muy probablemente, aprovechando la
programación efectuada en el prototipo). Los problemas detectados en este modelo son
los siguientes:

a) El prototipo es un software en “borrador” no un producto de ingeniería

como tal. Sin embargo puede, puede causar falsas expectativas al cliente en
el sentido de que es un producto consolidado. En el momento en que los

8
Roger S. Pressman. op. cit., p. 40.
9
 ingenieros tarden en hacer el software apropiado, podría darse un efecto de
ansiedad en el cliente, adverso para la salud del proyecto.
b) De no establecerse claramente los alcances del producto, en cada revisión
del producto se podrían “desbordar” los requisitos, lo cual haría tender a
un proyecto sin fin.

Para aplicaciones no muy complejas en procesamiento, orientadas

fuertemente a presentar muchas salidas, este paradigma podría acomodarse
bien 9.

El modelo de prototipos permite que todo el sistema, o algunos de sus partes, se

construyan rápidamente para comprender con facilidad y aclarar ciertos aspectos en los
que se aseguren que el desarrollador, el usuario, el cliente estén de acuerdo en lo que se
necesita así como también la solución que se propone para dicha necesidad y de esta
forma minimizar el riesgo y la incertidumbre en el desarrollo, este modelo se encarga del
desarrollo de diseños para que estos sean analizados y prescindir de ellos a medida que se
adhieran nuevas especificaciones, es ideal para medir el alcance del producto, pero no se
asegura su uso real.

Este modelo principalmente se lo aplica cuando un cliente define un conjunto de objetivos

generales para el software a desarrollarse sin delimitar detalladamente los requisitos de
entrada procesamiento y salida, es decir cuando el responsable no está seguro de la
eficacia de un algoritmo, de la adaptabilidad del sistema o de la forma en que interactúa el
hombre y la máquina. Este modelo se encarga principalmente de ayudar al ingeniero de
sistemas y al cliente a entender de mejor manera cuál será el resultado de la construcción
cuando los requisitos estén satisfechos 10.

6.1.3.1.1. CICLO DE VIDA DE UN SISTEMA BASADO EN

PROTOTIPO
Una maqueta o prototipo de pantallas muestra la interfaz de la aplicación, su cara externa,
pero dicha interfaz está fija, estática, no procesa datos. El prototipo no tiene desarrollada
una lógica interna, sólo muestra las pantallas por las que irá pasando la futura aplicación.
Por su parte, el prototipo funcional evolutivo desarrolla un comportamiento que satisface
los requisitos y necesidades que se han entendido claramente.

9
Roberto Cortés Morales. Introduccion al analisis de sistemas y la ingeniería del software, Editorial Universidad Estatal a Distancia
EUNED, 2006, p. 23
10
"INGENIERÍA DE SOFTWARE: MODELO DE PROTOTIPO." 2011. 28 Oct. 2015
<http://gestionrrhhusm.blogspot.com/2011/05/modelo-de-prototipo.html>

10
Realiza, por tanto, un proceso real de datos, para contrastarlo con el usuario. Se va
modificando y desarrollando sobre la marcha, según las apreciaciones del cliente. Esto
ralentiza el proceso de desarrollo y disminuye la fiabilidad, puesto que el software está
constantemente variando, pero, a la larga, genera un producto más seguro, en cuanto a la
satisfacción de las necesidades del cliente.

Cuando un prototipo se desarrolla con el sólo propósito de precisar mejor las necesidades
del cliente y después no se va a aprovechar ni total ni parcialmente en la implementación
del sistema final se habla de un prototipo desechable. Para que la construcción de
prototipos sea posible se debe contar con la participación activa del cliente 11.

6.1.4. METODOLOGÍAS ÁGILES

La ingeniería de software ágil combina una filosofía con un conjunto de lineamientos de
desarrollo. La filosofía pone en énfasis en: la satisfacción del cliente y en la entrega
rápida del software incremental, los equipos pequeños y muy motivados para efectuar el
proyecto, los métodos informales, los productos del trabajo con mínima ingeniería de
software y la sencillez general en el desarrollo. Los lineamientos de desarrollo enfatizan
la entrega sobre el análisis y el diseño (aunque estas actividades no se desalientan) y
continúa entre desarrolladores y clientes.

¿Por qué es importante?

El ambiente moderno de negocios genera sistemas basados, en computadora y productos
de software evolucionada rápido y constantemente. La ingeniería de software ágil
representa una alternativa razonable a la ingeniería de software convencional para ciertas
clases de software y en algunos tipos de proyectos. Asimismo se ha demostrados que
concluye con rapidez sistema exitosos.

Permanecen las actividades estructurales fundamentales: comunicación, planeación,

modelado, construcción y despliegue. Pero se transforman en un conjunto mínimo de
tareas que lleva al equipo de proyecto hacia la construcción y entrega.

Tanto el cliente como el ingeniero de software tiene la misma perspectiva: el único

producto del trabajo realmente importante es un “incremento de software” operativo se
entrega al cliente exactamente en la fecha acordada 12.

¿Qué es un proceso ágil?

11
“Modelo Prototipo.” 2013. Abril 28. 2016 <https://santmp.files.wordpress.com/2013/03/modelo-de-prototipo.pdf>
12
Roger S. Pressman. op. cit., p. 55
11
Cualquier proceso del software ágil se caracteriza por la forma en la que aborda cierto
número de suposiciones clave acerca de la mayoría de proyectos de software.

1. Es difícil predecir qué requerimientos de software persistirán y cuales cambiarán.

También es difícil pronosticar cómo cambiarán las prioridades del cliente a
medida que avanza el proyecto.
2. Para muchos tipos de software, el diseño y la construcción están imbricados. Es
decir, ambas actividades deben ejecutarse en forma simultánea, de modo que los
modelos de diseño se aprueben a medida que se crean. Es difícil predecir cuánto
diseño se necesita antes de que se use la construcción para probar el diseño.
3. El análisis, el diseño, la construcción y las pruebas no son tan predecibles como
nos gustaría (desde un punto de vista de planeación) 13.

6.1.4.1. PROGRAMACIÓN EXTREMA

La programación extrema es un enfoque orientado a objetos como paradigma preferido de
desarrollo, y engloban un conjunto de reglas y prácticas que ocurren en el contexto de
cuatro actividades estructurales: planeación, diseño, codificación y pruebas.

Planeación. La actividad de planeación comienza escuchando -actividad para recabar

requerimientos que permite que los miembros técnicos del equipo XP entiendan el
contexto del negocio para el software y adquieran la sensibilidad de la salida y
características principales y funcionalidad que se requiere-. Escuchar lleva a la creación
de algunas “historias” que describen la salida necesaria, características y funcionalidad
del software que se va a elaborar.

Diseño. El diseño XP sigue rigurosamente el principio MS (mantenlo sencillo). Un diseño

sencillo siempre se prefiere sobre una representación más compleja. Además, el diseño
guía la implementación de una historia conforme se escribe: nada más y nada menos. Se
desalienta el diseño de funcionalidad adicional porque el desarrollador supone que
requerirá después.

Codificación. Después que las historias han sido desarrolladas y de que se ha hecho el
trabajo de diseño preliminar, el equipo no inicia la codificación, sino que desarrolla una
serie de pruebas unitarias a cada una de las historias que se van a incluir en la entrega en
curso (incremento de software). Una vez creada la prueba unitaria, el desarrollador está
mejor capacitado para centrarse en lo que debe implementarse para pasar la prueba. No se
agrega nada extraño (MS), Una vez que el código es terminado, se le aplica de inmediato

13
Roger S. Pressman. op. cit., p. 60
12
una prueba unitaria, con lo que se obtiene retroalimentación instantánea para los
desarrolladores.

Pruebas. Ya se dijo que la creación de pruebas unitarias antes de que comience la

codificación es un elemento clave del enfoque de XP. Las pruebas unitarias que se crean
deben implementarse con el uso de una estructura que permita automatizarlas (de modo
que puedan ejecutarse en repetidas veces y con facilidad). Esto estimula una estrategia de
pruebas de regresión siempre que se modifique el código (lo que ocurre con frecuencia,
dada la filosofía en XP) 14.

6.1.5. LEVANTAMIENTO Y ANÁLISIS DE REQUERIMIENTOS

Los requerimientos para un sistema son la descripción de los servicios proporcionados por
el sistema y sus restricciones operativas. Estos requerimientos reflejan las necesidades de
los clientes de un sistema que ayude a resolver algún problema como el control de un
dispositivo, hacer un pedido o encontrar una información. El proceso de descubrir,
analizar, documentar y verificar estos servicios y restricciones se denomina ingeniería de
requerimientos (RE).

El término requerimiento no se utilizó de una forma constante en la industria del software.

En algunos casos, un requerimiento es simplemente una declaración abstracta de alto
nivel de un servicio que debe proporcionar el sistema o una restricción de este.

Algunos de los problemas que surgen durante el proceso de ingeniería de requerimientos

son resultado de no hacer una clara separación entre estos diferentes niveles de
descripción. Aquí se distinguen utilizando la denominación requerimientos del usuario
para designar los requerimientos abstractos de alto nivel, y requerimientos del sistema
para designar la descripción detallada de lo que el sistema debe hacer 15.

La obtención y análisis de requerimientos pueden afectar a varias personas de la

organización. El término stakeholder se utiliza para referirse a cualquier persona o grupo
que se verá afectado por el sistema, directa o indirectamente. Entre los stakeholders se
encuentran los usuarios finales que interactúan con el sistema y aquellos en la
organización que se pueden ver afectados por su instalación. Otros stakeholder del
sistema pueden ser los ingenieros que desarrollan o dan mantenimiento a otros sistemas
relacionados, los gerentes del negocio, los expertos en el dominio del sistema y los
representantes de los trabajadores.

14
Roger S. Pressman. op. cit., p. 65
15
Ian Sommerville. op. cit., p. 122
13
En la etapa de la documentación de requerimientos, los requerimientos que se han
obtenido se documentan de tal forma que se pueden utilizar para ayudar al descubrimiento
de nuevos requerimientos. En esta etapa, se puede producir una versión inicial del
documento de requerimientos del sistema, pero faltaran secciones y habrá requerimientos
incompletos. Por otra parte, los requerimientos se pueden documentar como tablas en un
documento o en tarjetas. Redactar requerimientos en tarjetas (el enfoque utilizado en la
programación extrema) puede ser muy efectivo, ya que son fáciles de manejar, cambiar y
organizar para los stakeholders 16.

6.1.5.1. HISTORIAS DE USUARIO

Es una técnica utilizada en el desarrollo de software, consiste en la redacción de un
requerimiento en unas pocas frases, adicional a esto se utiliza el lenguaje común del
usuario. Las historias de usuario son ideales para desarrollos con metodologías ágiles,
definen las especificaciones del proyecto, posteriormente y debido a la prioridad asignada
a cada una, se acomodan dentro de las diferentes iteraciones y se realizan los estimados en
tiempos para la realización de cada historia, este proceso lo realizan los desarrolladores.
Características de una historia de usuario:

Independiente. Pueden existir historias con tengan dependencias con otras, es necesario
separar de manera que resulten lo más independiente posible, ya que esta independencia
es clave a la hora de la etapa del diseño.

Negociable. Las pruebas de validación son la manera en que los clientes pueden verificar
el alcance de la historia de usuario.

Valoradas por clientes o usuarios. Las historias de usuarios son importantes para
clientes y usuarios, deben reflejar lo que ellos esperan, no lo que el desarrollador quiera
hacer.

Estimables. Cuando se estiman los tiempos para cada historia de usuario es más fácil
definir cuánto tiempo se tardará un proyecto.

Pequeñas. Deben ser pequeñas por la naturaleza iterativa de los proyectos donde se
utilizan.

Verificables. Debe ser posible la verificación de los logros obtenidos en las historias de
usuario en cada entregable de los proyectos 17.

16
Ian Sommerville. op. cit., p. 149
17
Mike Cohn, 2004"User Stories Applied", , Addison Wesley
14
 6.1.6. DISEÑO DE SOFTWARE
El diseño de software agrupa el conjunto de principios, conceptos y prácticas que llevan al
desarrollo del sistema o un producto de alta calidad. Los principios de diseño establecen
una filosofía general que guía el trabajo de diseño que debe ejecutarse. Deben de
entenderse los conceptos de diseño antes de aplicar la mecánica de este, y la práctica de
diseño en sí lleva a la creación de distintas representaciones del software que sirve como
guía para la actividad de construcción que siga 18.

6.1.6.1. UML (LENGUAJE UNIFICADO DE MODELADO)

El lenguaje unificado de modelado o UML (Unified Modeling Language) es el sucesor de
la oleada de métodos de análisis y diseño orientado a objetos (OOA&D) que surgió a
finales de la década de 1980 y principios de la siguiente. El UML unifica, sobre todo, los
métodos de Booch, Rumbaugh (OMT) y Jacobson, pero su alcance llegar a ser mucho
más amplio.

Decimos, que el UML es un lenguaje de modelado, y no un método. La mayor parte de

los métodos consisten, al menos en principio, en un lenguaje y en un proceso para
modelar. El lenguaje de modelado es la notación (principalmente gráfica) de que se valen
los métodos para expresar los diseños. El proceso es la orientación que nos dan sobre los
paso a seguir para hacer el diseño.

En resumidas cuentas, la cuestión fundamental del desarrollo del software es la escritura

del código. Después de todos los diagramas son solo imágenes bonitas. Ningún usuario va
a agradecer la belleza de los dibujos; lo que el usuario quiere es software que funciones 19.

Cuando se aplica UML al diseño de software, se trata de llevar la idea original o la

abstracción del problema a una parte o bloque de software y su implementación. UML
proporciona un medio para capturar y examinar requisitos (diagramas de casos de uso), un
concepto importante pero, a veces, difícil de comprender para un programador novel.
Existen diagramas para capturar cuales son las partes del software que cumplen con
ciertos requisitos (diagramas de colaboración). Otros diagramas sirven para capturar
exactamente cómo realizan sus requisitos esas partes del sistema (diagramas de secuencia
y diagramas de cartas de estado). Por último, hay diagramas para mostrar todo lo que la se
acopla y ejecuta de modo conjunto (diagramas de componentes y diagramas de cartas y de
despliegue) 20.

Vistas 4+1
18
Roger S. Pressman. op. cit., p. 184
19
Martin Fowler con Kendall Scott. UML gota a gota, PEARSON Educación, 1999, p. 7
20
Luis Joyanes Aguilar, Ignacio Zahonero Martinez. Programación en C, C++, Java y UML, 2010, p. 454
15
Una de las herramientas para representar modelos de arquitectura anteriores al UML es la
denominada vistas 4+1 propuesta por Kruchten. Surge esta necesidad cuando un
desarrollador inicia el modelado de un problema; lógicamente en este proceso se hace
énfasis en proporcionar la mayor información del mismo a través de los diagramas que se
utilicen para su descripción, esto trae consigo que puedan suceder conflictos en la
representación de la arquitectura del sistema. Esta arquitectura de software propuesta por
Kruchten es una forma de resolver esta problemática.

El modelo describe la arquitectura de software del sistema a través de 5 vistas

concurrentes. Kruchten las agrupa estas 5 vistas por su naturaleza en 3 apartados; el
conceptual donde sitúa a la vista lógica y la de procesos, el físico que lo compone las
vistas de componentes y la distribuida y por último la funcional la que se refiere a la vista
de casos de uso.

Vista lógica. Es aquella que trata de clases y subsistemas, tiene las siguientes
particularidades: soporta los requerimientos funcionales (estos son asignados por el
usuario final), identifica mecanismos y diseña elementos comunes a través del sistema;
utiliza los diagramas de clases y la notación de Booch. Además de utilizar el estilo
arquitectónico orientado a objetos.

Vista concurrente o de procesos. Describe el diseño de concurrencia y aspectos de

sincronización. Especifica las líneas de mando que ejecutan cada operación en cada una
de las clases señaladas en la vista lógica. Los diseñadores realizan esta vista en varios
niveles de abstracción, además de dividir el software en conjuntos independientes de
tareas, es decir, se empaqueta en pequeños programas o librerías del subsistema.

Vista de componentes o de desarrollo. Describe la organización estática de software en

los ambientes de desarrollo. Es una importante característica de lógica en casos de vistas,
autónomas, persistentes y de distribución, describe la participación en diferentes
operaciones, determina si existe persistencia entre un objeto y otro, además determina el
estado de los objetos y operaciones de accesibilidad por muchos nodos.

Vista distribuida o física se refiere a la implementación en módulos y fragmentación en

muchas capas. Colecciona las categorías de clases y grupos. Describe el mapeo del
software en el hardware y toma en cuenta los requerimientos funcionales del sistema,
tales como confiabilidad, respuesta y escalabilidad.

Vista de casos de uso o escenarios. Gobierna los requerimientos que son necesarios para
el usuario final, y construye elementos comunes a través del sistema. Esta vista es
redundante relacionado con el conjunto que forman las anteriores de ahí que se le
16
denomina +1, pero su inclusión es vital ya que desempeña dos roles importantes, actúa
como indicador que ayuda al diseñador a descubrir los elementos de la arquitectura
durante su diseño y valida e ilustra el diseño de la misma. La notación es similar a la que
se utiliza en la vista lógica, a excepción de que usa los conectores de la vista de procesos
para indicar la interacción entre objetos 21.

6.1.6.1.1. CASOS DE USO

Diagrama de uso de caso UML ayudan a determinar la funcionalidad y características del
software desde la perspectiva del usuario. Para proporcionar una aproximación a la
manera en la que funcionan los casos de uso y los diagramas de uso de caso, se crearán
algunos para una aplicación de software que gestiona archivos de música digital, similar
al software iTunes de Apple. Algunas de las cosas que puede incluir el software son
funciones para:

● Descargar un archivo de música MP3 y almacenarlo en la biblioteca de la

aplicación.
● Capturar música de streaming (transmisión continua) y almacenarla en la
biblioteca de la aplicación.
● Gestionar la biblioteca de la aplicación (por ejemplo, borrar canciones u
organizarlas en listas de reproducción).
● Quemar en CD una lista de las canciones de la biblioteca.
● Cargar una lista de las canciones de la biblioteca en un iPod o reproductor MP3.
● Convertir una canción de formato MP3 a formato AAC y viceversa.

Ésta no es una lista exhaustiva, pero es suficiente para entender el papel de los casos de
uso y los diagramas de uso de caso. Un caso de uso describe la manera en la que un
usuario interactúa con el sistema, definiendo los pasos requeridos para lograr una meta
específica (por ejemplo, quemar una lista de canciones en un CD). Las variaciones en la
secuencia de pasos describen varios escenarios (por ejemplo, ¿y si todas las canciones de
la lista no caben en un CD?). Un diagrama UML de uso de caso es un panorama de todos
los casos de uso y sus relaciones. El mismo proporciona un gran cuadro de la
funcionalidad del sistema 22.

6.1.6.1.2. DIAGRAMA DE CLASES

El diagrama de clases describe los tipos de objetos que hay en el sistema y las diversas
clases de relaciones estáticas que existen entre ellos. Hay dos tipos principales de
relaciones estáticas: asociaciones y subtipos. Los diagramas de clases también muestran

21
"THE 4+1 VIEW MODEL OF ARCHITECTURE." . 6 May. 2016
<http://docente.ucol.mx/almoradi/public_html/Respaldo/resumen3.htm>
22
Ian Sommerville. op. cit., p. 730.
17
los atributos y operaciones de una clase y las restricciones a que se ven sujetos, según la
forma en que se conecten los objetos 23.
6.1.6.1.3. DIAGRAMA DE COMPONENTES
El diagrama de componentes describe la composición física del sistema de software (y,
eventualmente, de su entorno organizativo) en componentes, a efectos de construcción y
funcionamiento. La descomposición del diagrama de componentes se realiza en términos
de componentes y de relaciones entre los mismos 24.

6.1.6.1.4. DIAGRAMA DE ACTIVIDADES

Un diagrama de actividad UML muestra el comportamiento dinámico de un sistema o de
parte de un sistema a través del flujo de control entre acciones que realiza el sistema. Es
similar a un diagrama de flujo, excepto porque un diagrama de actividad puede mostrar
flujos concurrentes. El componente principal de un diagrama de actividad es un nodo
acción, representado mediante un rectángulo redondeado, que corresponde a una tarea
realizada por el sistema de software. Las flechas desde un nodo acción hasta otro indican
el flujo de control; es decir, una flecha entre dos nodos acción significa que, después de
completar la primera acción, comienza la segunda acción. Un punto negro sólido forma el
nodo inicial que indica el punto de inicio de la actividad. Un punto negro rodeado por un
círculo negro es el nodo final que indica el fin de la actividad 25.

6.1.6.1.5. DIAGRAMA DE DESPLIEGUE

El diagrama de despliegue permite (en inglés, deployment) mostrar la arquitectura en
tiempo de ejecución del sistema respecto a hardware y software. El diagrama de
despliegue se utiliza en el diseño y la implementación. Se pueden distinguir componentes
(como los del diagrama de componentes) y nodos, así como las relaciones entre todos
estos. Es más limitado que el diagrama de componentes, en el sentido de que representa la
estructura del sistema solo en tiempo de ejecución, pero no en tiempo de desarrollo o
compilación. Sin embargo, resulta más amplio en el sentido de que puede contener más
clases de elementos 26.

6.1.6.2. MODELO RELACIONAL

El modelo relacional es sin lugar a dudas el fundamento de la tecnología moderna de base
de datos; este fundamento es el que hace de este campo una ciencia. Entonces, todo libro
sobre fundamentos de la tecnología de bases de datos que no incluya una minuciosa
cobertura de modelo relacional es por definición superficial. De igual forma, difícilmente
23
Martin Fowler con Kendall Scott. op. cit., p. 62
24
Benet Campderrich Falgueras. Ingeniería de software, Editorial UOC, 2003. p.102.
25
Ian Sommerville. op. cit., p. 735.
26
Benet Campderrich Falgueras. op. cit. p. 105.
18
se puede justificar cualquier afirmación de dominar el campo de las bases de datos si
quien lo afirma no comprende a fondo el modelo relacional. El modelo relacional se
ocupa de tres aspectos principales de la información: la estructura de datos, la
manipulación de datos y la integridad de datos 27.

6.1.6.3. ARQUITECTURA DE SOFTWARE

Cuando se piensa en la arquitectura de una construcción, llegan a la mente muchos
atributos distintos. En el nivel más sencillo, se considera la forma general de la estructura
física. Pero, en realidad, la arquitectura es mucho más que eso. Es la manera en la que los
distintos componentes del edificio se integran para formar un todo cohesivo. Es la forma
en la que la construcción se adapta a su ambiente y se integra a los demás edificios en la
vecindad. Es el grado en el que el edificio cumple con su propósito y en el que satisface
las necesidades del propietario. Es la sensación estética de la estructura —el efecto visual
de la edificación— y el modo en el que se combinan texturas, colores y materiales para
crear la fachada en el exterior y el “ambiente de vida” en el interior. Es los pequeños
detalles: diseño de las lámparas, tipo de piso, color de las cortinas... la lista es casi
interminable. Y, finalmente, es arte.

La arquitectura no es el software operativo. Es una representación que permite 1) analizar

la efectividad del diseño para cumplir los requerimientos establecidos, 2) considerar
alternativas arquitectónicas en una etapa en la que hacer cambios al diseño todavía es
relativamente fácil y 3) reducir los riesgos asociados con la construcción del software 28.

6.1.6.3.1. MODELO VISTA CONTROLADOR

El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la
organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el
usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación). De
esta forma, dividimos el sistema en tres capas donde, como explicaremos más adelante,
tenemos la encapsulación de los datos, la interfaz o vista por otro y por último la lógica
interna o controlador. El patrón de arquitectura "modelo vista controlador", es una
filosofía de diseño de aplicaciones, compuesta por:

Modelo. Contiene el núcleo de la funcionalidad (dominio) de la aplicación. Encapsula el

estado de la aplicación. No sabe nada / independiente del Controlador y la Vista.

Vista. Es la presentación del Modelo. Puede acceder al Modelo pero nunca cambiar su
estado. Puede ser notificada cuando hay un cambio de estado en el Modelo.

27
C.J. Date. Introducción a los sistemas de bases de datos, PEARSON Educación, 2001, p. 109.
28
Roger S. Pressman. op. cit., p. 207.
19
Controlador. Reacciona a la petición del Cliente, ejecutando la acción adecuada y
creando el modelo pertinente.

Para entender cómo funciona nuestro patrón Modelo vista controlador, se debe entender la
división a través del conjunto de estos tres elementos y cómo estos componentes se
comunican unos con los otros y con otras vistas y controladores externos al modelo
principal. Para ello, es importante saber que el controlador interpreta las entradas del
usuario (tanto teclado como el ratón), enviado el mensaje de acción al modelo y a la vista
para que se proceda con los cambios que se consideren adecuados 29.

6.1.7. CODIFICACIÓN
En esta etapa se tienen que traducir dichos algoritmos a un lenguaje de programación
específico; es decir, las acciones definidas en los algoritmos hay que convertirlas a
instrucciones. Para codificar un algoritmo hay que conocer la sintaxis del lenguaje al que
se va a traducir. Sin embargo, independientemente del lenguaje de programación en que
esté escrito un programa, será su algoritmo el que determine su lógica. La lógica de un
programa establece cuáles son sus acciones y en qué orden se deben ejecutar. Por tanto, es
conveniente que todo programador aprenda a diseñar algoritmos antes de pasar a la fase
de codificación 30.

6.1.8. PRUEBAS
Los niveles de prueba son diferentes ángulos de verificar y validar un producto de
software. Es como el tomar una radiografía a un cuerpo humano desde diferentes lados y
buscar donde hay un problema en los huesos. Existen diferentes niveles de prueba de
Software, los principales son la Prueba unitaria que es la que realizan los desarrolladores
de software en su código o componente. La prueba de integración que es realizada
también por el desarrollador de software y consiste en validar las conexiones e integración
entre dos o más componentes (códigos) de software, estos dos niveles de prueba son
realizados a través de la técnica de caja blanca. Otro nivel de prueba es la prueba
funcional, es preparada y ejecutada por un grupo independiente al desarrollador, y
consiste en validar el apego funcional del software contra los requerimientos
especificados por el usuario, esta es ejecutada utilizando la técnica de caja negra. Otro
nivel de prueba es la prueba de usuario o UAT, y es realizada por el usuario final del

29
“Patrón de arquitectura Modelo Vista Controlador (MVC).” , May. 15 2016
<http://www.lab.inf.uc3m.es/~a0080802/RAI/mvc.html>
30
“Codificación del software.” 2009, May. 15 2016 <https://ciclodevidasoftware.wikispaces.com/codificacion+del+software>
20
producto de software con el propósito de validar si el producto de software hace o se
comporta funcionalmente como lo especificó en sus requerimientos iniciales 31.
6.1.9. ENTREGA
Una entrega es el resultado del proyecto que se entrega al cliente. De forma general, se
entrega al final de una fase principal del proyecto como la especificación, el diseño, etc. 32.

6.1.10. ESTÁNDARES WEB

Un estándar es un conjunto de reglas normalizadas que describen los requisitos que deben
ser cumplidos por un producto, proceso o servicio, con el objetivo de establecer un
mecanismo base para permitir que distintos elementos hardware o software que lo
utilicen, sean compatibles entre sí. El W3C, organización independiente y neutral,
desarrolla estándares relacionados con la Web también conocidos como
Recomendaciones, que sirven como referencia para construir una Web accesible,
interoperable y eficiente, en la que se puedan desarrollar aplicaciones cada vez más
robustas 33.

6.1.10.1. HTML
El HTML es un lenguaje de marcación de elementos para la creación de documentos
hipertexto, muy fácil de aprender, lo que permite que cualquier persona, aunque no haya
programado en la vida, pueda enfrentarse a la tarea de crear una web. HTML es fácil y
pronto podremos dominar el lenguaje 34.

6.1.10.2. CSS
Hojas de Estilo en Cascada (Cascading Style Sheets), es un mecanismo simple que
describe cómo se va a mostrar un documento en la pantalla, o cómo se va a imprimir, o
incluso cómo va a ser pronunciada la información presente en ese documento a través de
un dispositivo de lectura. Esta forma de descripción de estilos ofrece a los desarrolladores
el control total sobre estilo y formato de sus documentos 35.

6.1.10.3. PYTHON
Un lenguaje de programación de alto nivel que fue diseñado con una sintaxis muy limpia
que permitiese obtener códigos que fuesen fáciles de leer, es multiplataforma y soporta
orientación a objetos, programación imperativa e, incluso, programación funcional 36.

31
“Pruebas del software.” 2011, May. 15 2016 <http://ingenieriadepruebasdelsoftware.blogspot.com.co/2011/01/niveles-
de-prueba-del-software.html>
32
Ian Sommerville. op. cit., p. 90.
33
“Guía breve de estándares web.” May. 12 2016 <http://www.w3c.es/Divulgacion/GuiasBreves/Estandares>
34
“Qué es HTML.” 2001, May, 12 2016 <http://www.desarrolloweb.com/articulos/que-es-html.html>
35
“Guía breve de CSS.” May. 12 2016 <http://www.w3c.es/Divulgacion/GuiasBreves/HojasEstilo>
36
“Historia del Software: el lenguaje Python.” 2011, May. 12 2016<http://hipertextual.com/archivo/2011/12/lenguaje-python/>
21
 6.1.10.4. FRAMEWORK
Siendo muy simple, es un esquema (un esqueleto, un patrón) para el desarrollo y/o la
implementación de una aplicación. Sí, es una definición muy genérica, pero también
puede serlo un framework: sin ir más lejos, el paradigma MVC (Model-View-Controller)
dice poco más que “separa en tu aplicación la gestión de los datos, las operaciones, y la
presentación”. En el otro extremo, otros frameworks pueden llegar al detalle de definir los
nombres de ficheros, su estructura, las convenciones de programación, etc. Los
frameworks no necesariamente están ligados a un lenguaje concreto, aunque sea así en
muchas ocasiones.

¿Qué ventajas tiene utilizar un ‘framework’?

Las que se derivan de utilizar un estándar; entre otras:
● El programador no necesita plantearse una estructura global de la aplicación,
sino que el framework le proporciona un esqueleto que hay que “rellenar”.
● Facilita la colaboración. Cualquiera que haya tenido que “pelearse” con el
código fuente de otro programador (¡o incluso con el propio, pasado algún
tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que
sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos
colaborativos.
● Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al
framework concreto para facilitar el desarrollo 37.

6.1.10.4.1. DJANGO
Es un framework para aplicaciones web gratuito y open source, escrito en Python. Es un
WEB framework - un conjunto de componentes que te ayudan a desarrollar sitios web
más fácil y rápidamente. Verás, cuando estás construyendo un sitio web, frecuentemente
necesitas un conjunto de componentes similares: una manera de manejar la autenticación
de usuarios (registrarse, iniciar sesión, cerrar sesión), un panel de administración para tu
sitio web, formularios, una forma de subir archivos, etc. Por suerte para ti, hace tiempo
varias personas notaron que los desarrolladores web enfrentan problemas similares
cuando construyen un sitio nuevo, por eso juntaron cabezas y crearon frameworks
(Django es uno de ellos) que te ofrecen componentes listos para usarse. Los frameworks
existen para ahorrarte tener que reinventar la rueda y ayudarte a aliviar la carga cuando
construyes un sitio 38.

37
“¿Qué es un ‘framework’?.” 2006, May. 15 2016 <http://jordisan.net/blog/2006/que-es-un-framework/>
38
“¿Qué es Django?. 2013, May. 15 2016 <http://tutorial.djangogirls.org/es/django/>
22
 6.1.10.5. MYSQL
MySQL es un sistema de administración de bases de datos (Database Management
System, DBMS) para bases de datos relacionales. Así, MySQL no es más que una
aplicación que permite gestionar archivos llamados de bases de datos. MySQL fue escrito
en C y C++ y destaca por su gran adaptación a diferentes entornos de desarrollo,
permitiendo su interacción con los lenguajes de programación más utilizados como PHP,
Perl y Java y su integración en distintos sistemas operativos. 39.

6.2. DESARROLLO

6.2.1. RECETA DE COCINA

Lista de ingredientes y una serie de instrucciones para realizar un plato de cocina
particular. Las recetas pueden ser transmitidas de generación en generación mediante
libros de cocina (a veces también recetarios), o creadas a partir de la experiencia. La
receta debe tener, como mínimo, tres apartados: título, ingredientes y elaboración.

Los tratados modernos de cocina suelen tener recetas con una composición descriptiva
similar a la siguiente:

● Una lista de los ingredientes requeridos con sus cantidades o proporciones.

● Guía de elaboración indicando como elaborar los alimentos paso a paso y
detallando los procedimientos usados.
● El tiempo que tardará en hacerse el plato. A veces se indica separado en fases
como preparación y cocinado.
● La dificultad de elaboración del plato, también expresado frecuentemente como
nivel de experiencia del cocinero.
● Fotografías de la receta terminada y de los ingredientes.
● El número de comensales servidos con los ingredientes.
● Lista del equipamiento de cocina necesario y entorno requerido para la
preparación del plato.
● Una lista ordenada de las tareas a realizar.
● A veces comentarios de cocineros, autores y recopilación de diferentes
experiencias 40.

6.2.1.1. NOMBRE DE LA RECETA

El nombre de la receta te indica lo que estarás preparando. Algunas recetas hasta tienen
una breve descripción de la comida o la bebida. Por ejemplo, puede decir "Licuado de

39
“¿Qué es MySQL?.” 2005, May. 12 2016 <http://www.esepestudio.com/noticias/que-es-mysql>
40
"Receta de cocina | Salud180." 2012. 28 Oct. 2015 <http://www.salud180.com/salud-z/receta-de-cocina>
23
fruta tropical —una bebida de verano refrescante y saludable". Algunas recetas también
incluyen un dibujo o una foto para mostrarte el aspecto de la comida o bebida cuando está
terminada 41.

6.2.1.2. PORCIONES
El número de porciones es importante para saber cuánta bebida o comida podrás hacer
con esa receta. Pero es fácil preparar más cantidad (el doble o el triple) o menos cantidad
(la mitad) 42.

6.2.1.3. ANÁLISIS NUTRICIONAL

Algunas personas se fijan en el análisis nutricional de una receta antes de decidir
prepararla. Este análisis te indica cuantas calorías tiene cada porción. También es posible
que indique lo siguiente:

● Grasas
● Proteína
● Hidratos de carbono
● Fibra
● Minerales (como el calcio o el hierro)
● Vitaminas (como la vitamina C)

Esta información es importante especialmente para los adultos y los niños que deben
seguir una dieta especial para mantenerse sanos 43.

6.2.1.4. TIEMPO DE PREPARACIÓN

El tiempo de preparación te indica cuánto tiempo te llevará preparar la comida o bebida.
Esto es importante ya que sabrás cuánto tiempo necesitarás. Y si estás preparando una
cena, sabrás cuándo debes comenzar a prepararla 44.

6.2.1.5. TIEMPO DE COCCIÓN

El tiempo de cocción es el tiempo que la comida tendrá que estar en el horno. En ciertas
recetas, no tienes que hacer nada durante el tiempo de cocción. Pero en otras recetas, es
posible que tengas que resolver o controlar la cocción de vez en cuando 45.

41
“Cómo leer una receta de cocina.” 2013. 25 Abr. 2016 <http://kidshealth.org/es/kids/read-a-recipe-esp.html>
42
Loc. cit.
43
Loc. cit.
44
Loc. cit.
45
Loc. cit.
24
 6.2.1.6. INGREDIENTES
Esta es la lista de todo lo que necesitas para cocinar. La mayoría de las listas de
ingredientes en recetas son fáciles de seguir. A veces las recetas incluyen información de
un ingrediente especial, como por ejemplo:

●
Ingredientes opcionales, los cuales no son necesarios pero pueden utilizarse
para lograr más sabor o un sabor diferente.
● Ingredientes sin una medida específica. Es posible que diga "Sal, a gusto". Esto
significa que puedes agregar la cantidad que desees en la receta. Puedes
agregar un poco o mucho.
Algunas listas de ingredientes te dicen lo que debes hacer inclusive antes de comenzar
con las indicaciones. Por ejemplo, "un pepino en rodajas finas" o "un huevo batido" 46.

6.2.1.7. INDICACIONES
Las indicaciones te dicen los pasos que debes tomar para hacer la comida. En muchas
recetas, las indicaciones se enumeran o listan en líneas por separado para que se entiendan
mejor y sean más fáciles de seguir 47.

6.2.2. COMENSAL
Es la persona que come con otras en el mismo lugar o mesa. El comensal se demuestra a
sí mismo y a la mesa que anhela conocer nuevos sabores, sentir, buscar un significado
diferente en el plato. Ser buen comensal es acercarse a nuevas propuestas, a restaurantes y
platos de cuyo gusto, olor e incluso presentación dudamos. 48.

6.2.3. GASTRONOMÍA
La gastronomía es el acto de cocinar dentro de un contexto más amplio donde hay
elementos relacionados con las maneras en la mesa (comportamientos individuales y
colectivos ligados con la alimentación), elementos socio antropológico (creencias,
supersticiones, prohibiciones, preferencias, elecciones alimentarias, orden culinario) y, en
especial, elementos simbólicos.
La alimentación es un acto social, regido por normas y significaciones, como si se tratara
de un segundo lenguaje, que permite a los miembros de una sociedad determinada
ubicarse dentro del mundo e integrarse como grupo social, para reafirmar su pertenencia
(identidad con los miembros de una cierta comunidad) 49.

46
Loc. cit.
47
Loc. cit.
48
“Las características del buen comensal.” 2015. 25 Abr. 2016 <http://elcellerdecanroca.bbva.com/las-caracter%C3%ADsticas-del-
buen-comensal>
49
“¿Qué es la gastronomía?.” 2013. 25 Abr. 2016 <http://cocinayvino.net/gastronomia/especiales/1589-que-es-la-gastronomia.html>
25
 6.2.4. ADMINISTRADOR DE COCINA
El administrador de cocina de un restaurante debe saber administrar los recursos de los
que dispone para ello debe identificar los diferentes problemas que se forjan, saber
descomponerlos en partes y analizarlos. Organizar el trabajo y administrar los tiempos de
forma adecuada, así mismo emprender los recursos de seguimiento de información a las
mismas.

La propia operatividad de la actividad de servicios demanda que sea hábil para gestionar
y/o rectificar las acciones implementadas del producto de la planificación y que van a
estar presididas por la capacidad que tenga de modificar las pautas del trabajo cuando
surgen dificultades o cambios 50.

6.2.5. CHEF
Persona que cocina por oficio y profesión. Se categorizan las funciones en la cocina, dado
el hecho que el conocimiento y especialidades de los diversos cocineros implican el éxito
de una cocina de clase y satisfacción de los clientes. Es una figura de las más reconocidas
en todo el mundo dentro las profesiones, es una posición que requiere una serie de
características las cuales la han hecho tan famoso

Es responsable de la salud y la correcta nutrición de todos los comensales quienes optan

por sus servicios De su imaginación paladar, conocimientos, etc. depende en un 100% la
economía del restaurante. El Chef debe ser un experto en cocina y conocer con propiedad
sobre productos, administración, contabilidad, derecho, nutrición, enología, costeos,
química, historia y geografía estos últimos dos para poder conocer mejor a los productos
y saber cómo utilizarlos adecuadamente, entre otros 51.

6.2.6. ALMACÉN
Un almacén básicamente es un espacio, recinto, edificio, o instalación donde se suele
guardar la mercancía, pero al mismo tiempo puede hacer otras funciones, como por
ejemplo el acondicionamiento de productos determinados, hacer recambios, tanto para el
mantenimiento como para la existencia técnica. La característica que puede tener un almacén
son:

● Frío
● Caliente
● Peligroso
● Valor

50
“¿Cómo debe ser un administrador de restaurante.” 2014. 25 Abr. 2016
<http://gastronomiaygestion.blogspot.com.co/2014/04/como-debe-ser-un-administrador-de.html>
51
“Chef.”2014. 25 Abr. 2015 <http://www.ecured.cu/Chef>
26
Sus funcionalidades son recibir mercancías y se responsabiliza de las mercancías que
recibe de transportistas externos o provenientes de una fábrica cercana. Identifica las
mercancías, luego se registran y se anotan las cantidades recibidas de cada artículo. En el
almacén han de prohibirse expresamente las tareas que no sean específicamente de
almacenamiento 52.

6.2.7. BODEGA
La bodega sería el sub-departamento encargado del almacenamiento, conservación,
control y distribución de vinos, aguas, licores, a los departamentos correspondientes bar,
comedor, cocina. La ubicación de estos departamentos debe tener en cuenta una serie de
factores como son:

● Fácil acceso para los proveedores.

● Cercano a las zonas de producción, (cocina central, comedor) y contigua a la zona
de almacenamiento por frío.

No deben almacenarse conjuntamente productos alimenticios con productos no

alimenticios, en particular con sustancias peligrosas, como detergentes, raticidas,
insecticidas, lejías, etc. Los productos se ordenan y clasifican por categorías, respetando
su modo de conservación. Los productos deben protegerse y ordenarse de modo que se
reduzcan los riesgos de contaminación 53.

6.2.8. ALIMENTO PERECEDERO

Son aquellos que comienzan una descomposición de forma sencilla. Agentes como la
temperatura, la humedad o la presión son determinantes para que el alimento comience su
deterioro. A temperatura ambiente se almacenan los productos alimenticios perecederos,
es decir, aquéllos cuya vida útil es larga y no precisan de condiciones especiales de
conservación (por ejemplo pastas, latas, cereales, etc.). Los locales que se utilicen para
almacenar estos alimentos tienen que ser frescos, secos y bien ventilados 54.

6.2.9. ALIMENTO NO PERECEDERO

El frío se utiliza para almacenar gran variedad de alimentos, cocinados y, por supuesto,
los congelados y ultra congelados. La refrigeración permite conservar los alimentos
perecederos (carne, pescado, huevos, frutas y verduras, etc.) por un período breve de
tiempo. Las temperaturas óptimas de refrigeración se encuentran comprendidas entre +1 y

52
“En el restaurante: Almacenamiento de materias primas.” 2013. 25 Abr. 2016
<http://enelrestaurante.blogspot.com.co/2013/03/almacenamiento-de-materias-primas.html>
53
Loc. cit.
54
Loc. cit.
27
+5 °C. Siempre que sea posible, se dispondrán cámaras de refrigeración separadas para
alimentos crudos y alimentos cocinados, con el fin de evitar la contaminación cruzada.
Cuando esto no sea posible, conviene colocar los alimentos crudos siempre debajo de los
cocinados, para evitar el riesgo de contaminación por goteo y suciedad y siempre deben
estar debidamente protegidos e identificados. Los productos congelados y ultra
congelados se almacenan en cámaras a temperaturas mucho más bajas, inferiores o
iguales a-18 °C 55.

6.2.10. MENÚ
El menú de un restaurante es la recopilación de todo el concepto gastronómico del lugar.
Del tipo de comida que ofrezcas en el menú y la extensión del mismo dependerá la
calidad y variedad de tus insumos e inventario, el nivel de experiencia y especialidad del
personal que contrates y el equipo e instalaciones necesarias. Fast food, cafetería,
desayunos, bar o comida de especialidad, no importa cuál sea, es muy importante que
cuentes con un menú claro y estético que atrape la atención de tus clientes 56.

55
Loc. cit.
56
“El menú: una de tus mejores cartas de presentación.” 2013. 25 Abr. 2016
<http://www.elclaustro.edu.mx/claustronomia/index.php/investigacion/197-el-menu-una-de-tus-mejores-cartas-de-presentacion>
28
 7. CAPÍTULO III - OTRAS CONSIDERACIONES

7.1. SITUACION LEGAL Y NORMATIVO

Los vegetales son alimentos que perecen con mucha facilidad por eso se debe tener un
control y técnicas de manejo en la etapa de cultivo, procesamiento, transporte y consumo
dado el decreto No. 2333 de 1982. Así mismo se regula la producción y expedido de los
productos cárnicos procesados dados por el decreto No. 2162 de 1983 y para las
regulaciones de los productos de pesca se dará por el decreto No. 561 de 1984.

Las normas técnicas colombiana NTC 512-1 para el rotulado de alimento envasado y
materias primas para el consumo humano se da por la resolución No. 5109 de 2005, esta
norma informa al consumidor sobre el producto y que esta información sea lo
suficientemente clara y comprensible para evitar engaños o confusiones.

Para la aprobación del proyecto como trabajo de grado se maneja mediante el consejo
académico en su acuerdo No 12 de 2015, donde se modifica el acuerdo No. 25 de 2005
para la reglamentación de trabajos de grado de la Universidad Tecnológica de Pereira.

7.2. GEOLOCALIZACIÓN
La mayoría de los casos, los restaurantes pequeños o grandes tienen la costumbre de
desperdiciar alimentos a veces por la demanda y otras por el vencimiento de algunos
ingredientes como los vegetales. Estas pérdidas no son tomadas en cuenta pero afecta la
economía del restaurante. Provocando en algunos casos la mala publicidad del negocio
por el desperdicio de los alimentos, esto es causado al mal manejo en la preparación de
platos del menú, las cantidades no son exactas y se exagera en su producción.

La mayoría de los restaurantes se encuentran ubicados en zonas de centro de las ciudades

o en puntos estratégicos de masas para el consumo de los comensales. Este proyecto
permite de ayudar a disminuir esas pérdidas en cantidades mínimas, ayudando a un mejor
manejo y cuidado de los alimentos sin perder la calidad y estabilidad del negocio. El
aporte que deseamos es tener un mejor control de los alimentos para ayudar no solo la
economía del restaurante, sino para aportar a la comunidad la manera de evitar la pérdida
de alimentos que otros negocios o personas pueden utilizar y consumir.

29
 8. CAPÍTULO IV - DEFINICIÓN DE LOS REQUERIMIENTOS DEL SISTEMA

8.1. LEVANTAMIENTO DE REQUERIMIENTOS

Esta parte del proyecto se procede a identificar los diferentes requerimientos del sistema,
además están representados haciendo uso de la técnica de prototipos no funcionales, esto
con el fin de visualizar un adelanto de cómo es la interfaz gráfica del sistema junto con
todas sus funcionalidades. Entonces, a partir de lo anterior se levantaron los
requerimientos para la creación del software para la gestión de recetas, control de
inventario y costeo para restaurante.

El sistema permite el manejar de tres tipos de usuarios

● Mesero. Contiene id, tipo de usuario, contraseña, documento de identidad, nombre
y apellidos, teléfono, email, dirección y edad. Puede acceder a las siguientes
funcionalidades:

1) Tomar orden: El mesero puede tomar una orden del cliente de acuerdo al
menú del día y registrarla en la cola de órdenes. Una orden contiene id
orden, número de mesa de la orden y fecha.
2) Plato del día:
a) Puede visualizar el menú del día.

● Chef. Contiene id, tipo de usuario, contraseña, documento de identidad, nombre y

apellidos, teléfono, email, dirección y edad. Tiene acceso a las siguientes
funcionalidades:

1) Las órdenes en cola: Aparece un listado con las mesas que presentan
órdenes en un momento dado. Luego se procede a seleccionar una de estas
mesas para procesar el pedido.
2) Órdenes procesadas: Se listan las últimas cinco órdenes ejecutadas.
3) Selección de menú del día: El chef selecciona un menú para un día
correspondiente y luego puede visualizar todos los menús.
4) Administrar menús:
a) Crear menú.
b) Modificar menú.
c) Eliminar menú.

● Root (Administrador de Bases de datos). Puede crear, modificar y eliminar

usuarios chef y meseros. Actualizar el inventario de cocina. Del usuario se interesa
conocer nombre y contraseña.

30
Inventario
● Cada uno de los ítems del inventario tiene un id, nombre, descripción, unidad de
medida y cantidad disponible.
● Se parametrizan cada uno de los tipos de ítems de inventario de tal manera que
cuando las cantidades de cada elemento se encuentre cerca del límite de escasez,
el sistema muestra una alerta al usuario chef para que tome las medidas
correspondientes.

Generalidades
● Las mesas se encuentran numeradas para que el mesero se disponga a registrar la
orden que será recibida por el chef.
● La orden contiene la elección de uno o más platos del menú ofrecido por el
restaurante.
● La orden tiene que estar identificada por el número de mesa donde se registró el
pedido.
● Una orden puede de tener más de un plato del menú o producto que se referencia
en la carta.
● El mesero dispone de una lista de platos del menú igual a la carta que se le entrega
al comensal para su orden.
● La lista se divide en las categorías que el restaurante maneja en la elaboración de
los platillos.
● Los productos que no se incluyen en el plato del menú, también se encuentran en
una categoría aparte.
● El chef o administrador de cocina recibe la orden con la información de los platos
a preparar.
● Las órdenes se juntaran en una lista con prioridad de llegada para despachar.
● El chef o administrador de cocina puede seleccionar una orden para obtener la
información sobre el plato a elaborar. Tendrá información de las cantidades
necesarias de cada ingrediente en su preparación.
● Las listas de platos solo tiene información de los ingredientes del plato más no el
costo de él.
● En caso una posible escasez del producto se muestra en pantalla el nombre del
producto resaltado en rojo.
● El programa tiene un panel para comunicarse con los distribuidores para la compra
del producto que se encuentra en límites de escasez.
● Una vez procesada la orden, ésta desaparecerá de la lista para darle prioridad a la
siguiente orden.
● En el proceso de procesar la orden esta se guardara en un historial de órdenes para
un manejo y control del inventario.
31
 ● El programa cuenta con un backup para tener un mejor manejo de la información
ante posibles fallas.
● El menú está compuesto por todos los platos y bebidas, el plato tiene un código,
descripción sobre la preparación e ingredientes.
● Un ingrediente pertenece a uno o varios platos, tiene un id plato, id ingrediente,
nombre, cantidad y disponibilidad.

8.1.1. HISTORIAS DE USUARIO

Los requerimientos del sistema se construyeron a partir de la técnica de historias de
usuario (HU), cada una de las HU pertenecen a un proceso detallado en el levantamiento
de requerimientos del sistema. Dentro de la metodología de ingeniería utilizada para el
desarrollo del proyecto las HU son una pieza importante para el entendimiento de los
procesos y en la construcción del diseño del sistema. (Ver ANEXO 1 Historias de
Usuario).

8.2. DISEÑO DEL SISTEMA

La siguiente fase de la metodología de ingeniería del software es el diseño, a continuación
se describen las vistas 4+1 del proyecto.

8.2.1. VISTA DE ESCENARIOS (CASOS DE USO)

Cada escenario modelado por un diagrama de caso de uso viene especificado en una
tabla donde se enfrenta el usuario y el sistema para cada proceso un mejor seguimiento
detallado sobre lo que ocurre normalmente por cada actividad del sistema. (Ver ANEXO
2 Especificaciones de Casos de Uso).

32
DIAGRAMA DE CASO DE USO: ROOT

33
DIAGRAMA DE CASO DE USO: CHEF

34
DIAGRAMA DE CASO DE USO: MESERO

35
 8.2.2. VISTA DE PROCESOS (DIAGRAMA DE ACTIVIDADES)
Cada actividad del sistema es modelado por un diagrama de actividades (Ver ANEXO 3
Diagrama de Actividades).

8.2.3. VISTA LOGICA (DIAGRAMAS DE CLASES)

36
8.2.4. VISTA DE DESARROLLO (DIAGRAMA DE COMPONENTES)

37
 8.2.5. VISTA FISICA (DIAGRAMA DE DESPLIEGUE)

8.3. MODELO RELACIONAL

Diagrama y especificaciones de los atributos del MER (Ver ANEXO 3 MODELO
RELACIONAL).

38
39
 9. CONCLUSIONES

Realizando un correcto proceso de levantamiento de los requerimientos, aseguramos el

éxito durante todas las etapas del desarrollo del producto, las funcionalidades del sistema,
los tipos de usuarios y sus privilegios. Los análisis a tiempo sobre los procesos del sistema
nos ayudan a reducir las probabilidades de fallas y consecuencias en el proyecto.

La metodología agile aplicada es muy útil, aunque se tuvieron algunas desventajas que
con tiempo y prevención se pudieron solucionar a tiempo, y asegurar la calidad del
proyecto. El proyecto realizado entro a una primera fase y el cual requiere a futuro una
retroalimentación para cumplir con más éxito el total de sus funcionalidades.

En la codificación, la utilización de frameworks aporta ventajas de tiempo en el

desarrollo, dado que su objetivo principal es brindar una manera organizada de codificar a
través de patrones (MVC), y servir como estructura de trabajo y plantilla de codificación.

El diseño de software nos ofrece una vista global del sistema y sus escenarios, a través de
los diagramas un mejor entendimiento de la lógica, física y dinámica del sistema. Las
pruebas se realizaron por cada proceso separado del sistema para garantizar el
cumplimiento de los requerimientos iniciales.

Cumplimos con objetividad cada una de las etapas de la ingeniería de software, aunque
tuvimos problemas con los deberes de cada integrante se designó al comienzo del
proyecto, por falta de tiempo para realizar reuniones de equipo y revisión de las tareas en
proceso. Las correcciones se hicieron al límite de entrega del proyecto, dejando escrito
que las funcionalidades cumplen con los requerimientos iniciales pero faltan más
optimización y desarrollo para mejoras de los procesos que se espera solucionar a futuro.

40
 10. RECOMENDACIONES

El sistema necesita una mejor optimización de sus funcionalidades que se deben

mejorar a futuro. Para esto se debe conocer con detalle los niveles y aspectos del sistema
para el cual se encuentra dirigido. Esta desarrollado para funcionar en aplicaciones
móviles con la recomendación de hacer una transición adecuada en la comunicación de
la orden cuando se encuentra lista para servir en la mesa del cliente.

Mejorar el diseño del aplicativo para una mejor visualización e imagen del producto,
respectando sus funcionalidades iniciales y lograr que el usuario entienda de manera
fácil sus funciones. Se debe optimizar minimizar los procesos para lograr una
normalización eficaz de los datos. Estos cambios deben de estar sujetos a política de
seguridad de la información, para asegurar la integridad, disponibilidad y
confidencialidad de los datos.

41
 11. BIBLIOGRAFÍA

Sergio Luján Mora. Programación de aplicaciones web: historia, principios básicos y

clientes web, Editorial Club Universitario, 2002.

Roger S. Pressman. Ingeniería del Software Un enfoque moderno, McGrawHill, 2010.

Ian Sommerville. Ingeniería del Software, PEARSON Educación, 2005.

Roberto Cortés Morales. Introduccion al analisis de sistemas y la ingeniería del software,

Editorial Universidad Estatal a Distancia EUNED, 2006.

Mike Cohn, User Stories Applied, Addison Wesley, 2004.

Martin Fowler con Kendall Scott. UML gota a gota, PEARSON Educación, 1999.

Luis Joyanes Aguilar, Ignacio Zahonero Martinez. Programación en C, C++, Java y UML,
2010.

Benet Campderrich Falgueras. Ingeniería de software, Editorial UOC, 2003.

C.J. Date. Introducción a los sistemas de bases de datos, PEARSON Educación, 2001.

42
 12. WEB-GRAFÍA

"La mejores apps de Android para cocineros amateur ..." 2014. 19 Oct. 2015
<http://www.androidexperto.com/aplicaciones-android/mejores-apps-android-cocineros/>

"INGENIERÍA DE SOFTWARE: MODELO DE PROTOTIPO." 2011. 28 Oct. 2015

<http://gestionrrhhusm.blogspot.com/2011/05/modelo-de-prototipo.html>
"Definicion de UML - Alegsa." 2007. 28 Oct. 2015
<http://www.alegsa.com.ar/Dic/uml.php>

"Definición de casos de uso - IBM." 2014. 28 Oct. 2015 <http://www-

01.ibm.com/support/knowledgecenter/SSWSR9_11.0.0/com.ibm.pim.dev.doc/pim_tsk_ar
c_definingusecases.html?lang=es>

"Elementos de UML." 2014. 28 Oct. 2015

<https://docs.kde.org/stable/es/kdesdk/umbrello/uml-elements.html>

"Modelo entidad-relación - Cursos Programación - arroba ..." 2005. 28 Oct. 2015

<http://www.formauri.es/arrobamasmas/Cursos/index.php?apdo=05&curso=51&cap=2>

"Receta de cocina | Salud180." 2012. 28 Oct. 2015 <http://www.salud180.com/salud-

z/receta-de-cocina>

"El Chef Como Administrador - BuenasTareas.com." 2012. 28 Oct. 2015

<http://www.buenastareas.com/ensayos/El-Chef-Como-Administrador/5639745.html>

"Definiciones de chef, chef ejecutivo, subchef, cadete de ..." 2012. 28 Oct. 2015
<http://gastronomia.laverdad.es/preguntas/terminologia/definiciones-chef-chef-ejecutivo-
subchef-cadete-cocina-entremettier-rotisseur-patissier-9374.html>

"alimentos perecederos,semiperecederos,no perecederos." 2013. 28 Oct. 2015

<http://paolasalascocina.blogspot.com/2013/02/alimentos-perecederossemi-
perecederosno.html>

“Nuevas tecnologías en restaurantes.” 2014. 29 Oct. 2015

<http://www.revistalabarra.com.co/ediciones/ediciones-2014/edicion-67/informe-
6/nuevas-tecnologias-en-restaurantes.htm>

“Las nuevas tecnologías en los restaurantes.” 2012. 29 Oct. 2015

<http://www.mesafija.com/noticia/25/82/las-nuevas-tecnologias-en-los-restaurantes>

“7 formas en que la tecnología cambiará los restaurantes.” 2015. 29 Oct 2015

43
<http://www.planetajoy.com/?+7+formas+en+las+que+la+tecnolog%EDa+cambiar%E1+
los+restaurantes&page=ampliada&id=7610>

“Todo los artículos de: Restaurantes-Revista Turismo y Tecnología.” 2015. 29 Oct. 2015
<http://www.turismoytecnologia.com/todos-los-articulos-de-
tecnologia/itemlist/tag/Restaurantes>

44
 ANEXO 1

HISTORIAS DE USUARIO

Historia de Usuario

Número: 1 Nombre: Inicio de Sesión.

Prioridad en Negocio: Iteración Asignada:

Descripción:
El sistema permitir al usuario entrar a la aplicación ingresando:
● Nombre de usuario.
● Contraseña de Usuario.
Una vez validada la sesión, se muestra la página principal correspondiente a cada
tipo de usuario.
Observaciones: Ninguna.

Tabla 1: Historia de usuario 1

Historia de Usuario

Número: 2 Nombre: Recuperar Contraseña.

Prioridad en Negocio: Iteración Asignada:

Descripción:
El sistema permite al usuario recuperar contraseña, ingresando en la opción
Recuperar Contraseña. Luego se escribe el correo del usuario, el sistema envía el
mensaje validando que sea el correo correspondiente del usuario con la
información de la contraseña olvidada.
Observaciones: Ninguna.

Tabla 2: Historia de usuario 2

Historia de Usuario

Número: 3 Nombre: Usuario Administrador.

Prioridad en Negocio: Iteración Asignada:

Descripción:
45
El usuario Root o Administrador es el encargado de la administración del sistema,
sus funcionalidades son el manejo de la BD y digitalizar la información del
inventario.
Observaciones: El usuario Root administra el SGBD para el control y seguridad
de la información.

Tabla 3: Historia de usuario 3

Historia de Usuario

Número: 4 Nombre: Gestión de Usuarios.

Prioridad en Negocio: Iteración Asignada:

Descripción: El sistema permite las siguientes funcionalidades sobre los usuarios:
● Crear Usuario.
● Eliminar Usuario.
● Consultar Usuario.
● Modificar Usuario
Observaciones: Las funciones Crear y Eliminar están disponibles por el usuario
Administrador. Las demás funciones son accesibles desde el sistema para los otros
tipos de usuario.

Tabla 4: Historia de usuario 4

Historia de Usuario

Número: 5 Nombre: Crear Usuario.

Prioridad en Negocio: Iteración Asignada:

Descripción: El sistema permite al usuario Administrador crear un nuevo usuario,
para esto cuenta con un formulario que proporcionar la siguiente información:
● Tipo de usuario.
● Nombre de Usuario.
● Contraseña.
● Documento de identidad.
● Nombre.
● Apellidos.
● Teléfono.
● Email.
46
 ● Dirección.
● Fecha de nacimiento.
Al final se guardan los datos, en caso contrario se puede cancelar la acción.
Observaciones: Todos los campos son obligatorios. El usuario Administrador solo
crea dos tipos de usuario (Mesero o Chef).

Tabla 5: Historia de usuario 5

Historia de Usuario

Número: 6 Nombre: Consultar Usuario.

Prioridad en Negocio: Iteración Asignada:

Descripción: Cualquier usuario puede visualizar su propia cuenta con la siguiente
información en pantalla:
● Nombre.
● Alias.
● Correo electrónico.
● Tipo de usuario.
● Género.
● Tipo de documento.
● Número de documento.
● Dirección.
● Teléfono.
● Fecha de nacimiento.
Al final puede volver a la vista anterior.
Observaciones: Solo el usuario Administrador puede consultar la lista de perfiles
de todos los usuarios y su información contenida.

Tabla 6: Historia de usuario 6

Historia de Usuario

Número: 7 Nombre: Editar Usuario.

Prioridad en Negocio: Iteración Asignada:

Descripción: El usuario puede editar su propia cuenta con la siguiente
información en pantalla:
● Nombre.
47
 ● Alias.
● Correo electrónico.
● Tipo de usuario.
● Género.
● Tipo de documento.
● Número de documento.
● Dirección.
● Teléfono.
● Fecha de nacimiento.
● Contraseña
Al final se guardan los datos, en caso contrario se puede cancelar la acción.
Observaciones: Esta funcionalidad solo está disponible para los usuarios Mesero
y Chef.

Tabla 7: Historia de usuario 7

Historia de Usuario

Número: 8 Nombre: Eliminar Usuario.

Prioridad en Negocio: Iteración Asignada:

Descripción: El sistema permite al usuario Administrador eliminar un usuario del
sistema. En caso contrario puede cancelar la opción.
Observaciones: Esta función sólo está disponible por el usuario
Administrador.

Tabla 8: Historia de usuario 8

Historia de Usuario

Número: 9 Nombre: Usuario Chef.

Prioridad en Negocio: Iteración Asignada:

Descripción: Ésta vista contará con las siguientes funcionalidades:
● Lista de órdenes.
● Facturar Orden.
● Escoger Plato..
● Gestión de menús.
● Inventario.
48
Observaciones: Solo el chef tiene acceso a estas funciones.

Tabla 9: Historia de usuario 9

Historia de Usuario

Número: 10 Nombre: Lista de órdenes.

Prioridad en Negocio: Iteración Asignada:

Descripción: El Usuario Chef puede visualizar las órdenes pendientes
identificadas por un id único, y una funcionalidad Servir Orden para tener detalle
del pedido. Puede volver a la anterior ventana.
Observaciones: Consultar Historia de Usuario Servir orden.

Tabla 10: Historia de usuario 10

Historia de Usuario

Número: 11 Nombre: Servir orden.

Prioridad en Negocio: Iteración Asignada:

Descripción: El Usuario Chef selecciona una orden para visualizar los elementos
que esta contiene y poder servir el plato. Puede volver a la anterior ventana.
Observaciones: Solo el chef tiene acceso a esta vista.

Tabla 11: Historia de usuario 11

Historia de Usuario

Número: 12 Nombre: Factura orden.

Prioridad en Negocio: Iteración Asignada:

Descripción: El chef puede ver las mesas que se encuentran con órdenes de pedido
despachadas, y así proceder a imprimir la factura.
Observaciones: Solo el chef tiene acceso a esta vista.

Tabla 12: Historia de usuario 12

49
Historia de Usuario

Número: 13 Nombre: Escoger Plato.

Prioridad en Negocio: Iteración Asignada:

Descripción: Se tiene acceso a un formulario consistente con el menú del día en el
cual se selecciona el plato que desea preparar.
Observaciones: Consultar Historia de Usuario Preparar Plato.

Tabla 13: Historia de usuario 13

Historia de Usuario

Número: 14 Nombre: Preparar Plato.

Prioridad en Negocio: Iteración Asignada:

Descripción: El usuario digita la cantidad de platos del menu que va a preparar,
luego aparece la cantidad necesaria de ingredientes para su elaboración.
Observaciones: Solo el chef tiene acceso a esta vista.

Tabla 14: Historia de usuario 14

Historia de Usuario

Número: 15 Nombre: Gestión de menús

Prioridad en Negocio: Iteración Asignada:

Descripción: En esta vista accede a las siguientes funcionalidades:

● Crear menú.
● Eliminar Menú
● Seleccionar menú del día.

Observaciones: Solo el Usuario Chef puede cumplir esta funcionalidad.

Tabla 15: Historia de usuario 15

Historia de Usuario

Número: 16 Nombre: Crear menú.

50
Prioridad en Negocio: Iteración Asignada:
Descripción: El Usuario Chef puede visualizar una lista de primeros platos,
segundos platos, postres y líquidos que escoge mediante una lista de productos que
ofrece para crear un menú. Después de escoger el menú se guardan los cambios
realizados.
Observaciones: Solo el Usuario Chef puede cumplir esta funcionalidad.

Tabla 16: Historia de usuario 16

Historia de Usuario

Número: 17 Nombre: Eliminar menú.

Prioridad en Negocio: Iteración Asignada:

Descripción: El Usuario Chef selecciona un menú de la lista que se visualiza, para
luego elegir el que desea eliminar. Se puede cancelar la opción.
Observaciones: Solo el Usuario Chef puede cumplir esta funcionalidad.

Tabla 17: Historia de usuario 17

Historia de Usuario

Número: 18 Nombre: Selección menú del día.

Prioridad en Negocio: Iteración Asignada:

Descripción: El Usuario Chef puede seleccionar en una lista de menús creados
anteriormente, para elegir el menú del día. Se puede cancelar la opción.
Observaciones: Solo el Usuario Chef solo puede cumplir esta funcionalidad.

Tabla 18: Historia de usuario 18

Historia de Usuario

Número: 19 Nombre: Inventario.

Prioridad en Negocio: Iteración Asignada:

Descripción: El Usuario Chef puede buscar un elemento del inventario para
obtener los datos de la consulta realizada.
51
Observaciones:
● Debajo de la barra de búsqueda aparecen todos los elementos del inventario
independientemente de que no se realice ninguna búsqueda.
● El Usuario Chef solo puede visualizar los datos del inventario, mas no
podrá editarlos.

Tabla 19: Historia de usuario 19

Historia de Usuario

Número: 20 Nombre: Usuario Mesero.

Prioridad en Negocio: Iteración Asignada:

Descripción: El usuario mesero ingresa al sistema tiene acceso a las siguientes
funcionalidades:
● Tomar orden.
● Añadir Orden.
● Ver menú del día.
Observaciones: Consultar Historias de Usuario correspondientes a cada una de las
funcionalidades mencionadas.

Tabla 20: Historia de usuario 20

Historia de Usuario

Número: 21 Nombre: Tomar orden.

Prioridad en Negocio: Iteración Asignada:

Descripción: Seleccionada la mesa para la orden, el mesero se dispone a tomar la
orden dependiendo del menú del día y para esto contará con un formulario en el
cual debe digitar las cantidades de cada uno de los ítems de la carta, además cuenta
con una opción para cancelar la orden y otra opción para enviar orden. Una vez se
envía la orden, se actualizarán las órdenes en cola pertenecientes a la funcionalidad
del chef.
Observaciones:
● El formulario para tomar la orden varía dependiendo del menú del día.
● El menú del día lo establece el Usuario Chef.
● Solo el Usuario Mesero puede acceder a esta vista.

52
Tabla 21: Historia de usuario 21

Historia de Usuario

Número: 22 Nombre: Añadir Orden.

Prioridad en Negocio: Iteración Asignada:

Descripción: El usuario mesero visualiza una lista de órdenes que aún no se
encuentran facturadas y luego procede a seleccionar una de estas para añadir un
nuevo elemento a la orden, tiene una opción para cancelar la orden y otra opción
para enviar orden. Cuando se envía la orden, se actualizan las órdenes en cola
pertenecientes a la funcionalidad del chef.
Observaciones:
● El formulario para tomar la orden depende del menú del día.
● El menú del día lo establece el Usuario Chef.
● Solo el Usuario Mesero puede acceder a esta vista.

Tabla 22: Historia de usuario 22

Historia de Usuario

Número: 23 Nombre: Ver menú del día.

Prioridad en Negocio: Iteración Asignada:

Descripción: El mesero puede visualizar los platos correspondientes al menú del
día. Puede volver a la ventana anterior.
Observaciones: Solo el Usuario Mesero puede acceder a esta vista.

Tabla 23: Historia de usuario 23

53
 ANEXO 2

ESPECIFICACIONES DE CASOS DE USO

Caso de uso # 1
Caso de uso Iniciar Sesión
Actores Root, Mesero y Chef
Propósito Permite a los usuarios acceder a la
plataforma, diligenciando los campos
nombre de usuario y contraseña de usuario.
Resumen Comienza cuando el usuario decide iniciar
sesión para ingresar al sistema y acceder a
sus funcionalidades de la aplicación.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa nombre y contraseña. 2. El sistema comprueba que los datos
ingresados por el usuario coincidan con los
de la bases de datos.
3. El sistema deja al usuario acceder al
perfil.
Curso Alterno Iniciar Sesión
Acción 2: Si el sistema detecta que los datos ingresados por el usuario son incorrectos
debe notificarle al usuario que los datos son incorrectos y debe regresar al paso 1.
Sección Recuperar contraseña
1. El usuario accede a la funcionalidad 2. El sistema permite al usuario ingresar a la
Recuperar Contraseña. vista recuperar contraseña.
3. El usuario debe ingresar el correo que 4. El sistema verifica el correo del usuario
registro en la base de datos. sea el que se encuentra en la base de datos.
5. El sistema envía un correo electrónico al
correo que corresponde el nombre de
usuario con la contraseña olvidada.
Curso Alterno Recuperar contraseña
Acción 4. Si el nombre de usuario ingresado no corresponde con el asociado en la base

54
de datos del sistema, regresa al paso 3.

Tabla 24: Caso de uso #1

Caso de uso # 2
Caso de uso Crear Usuario
Actores Root
Propósito Permite al usuario crear un usuario y
registrarlo en la base de datos.
Resumen Comienza cuando el usuario decide crear
una o varios tipos de usuarios.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. Ingresar a Crear Usuario. 2. El sistema comprueba si el usuario que
está accediendo puede usar esta función.
3. El sistema muestra el formulario para la
creación del nuevo usuario.
4. El usuario diligencia el formulario. 5. El sistema comprueba que los datos
ingresados coinciden.
6. El sistema guarda la cuenta y termina la
acción.
Curso Alterno Crear Usuario
Acción 2: Si el usuario que está tratando de crear una cuenta no tiene la autorización no
permite la acción y muestra un mensaje diciendo que no está autorizado a realizar la
acción y vuelve al paso 1.
Acción 5: Si uno o varios de los datos no coinciden, el sistema cancela la acción y
vuelve al paso 4.

Tabla 25: Caso de uso #2

Caso de uso # 3
Caso de uso Editar Usuario
Actores Mesero y Chef
55
Propósito Permite a los usuarios editar su cuenta de
usuario.
Resumen Comienza cuando el usuario decide editar o
modificar una su cuenta de usuario.
Tipo Esencial
Referencias
Curso Normal de los eventos
Acción de los actores Respuesta del sistema
1. El usuario decide realizar cambios a su 2. El sistema comprueba que el usuario
cuenta de usuario, a través de la tenga los permisos para acceder a esta
funcionalidad de Editar Usuario. funcionalidad.
3. El sistema muestra los datos para
modificar.
4. El usuario realiza los cambios. 5. El sistema comprueba que todos los
campos del formulario coincidan.
6. El sistema acepta los cambios y los
guarda.
Curso Alterno Editar Usuario
Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.
Acción 5: Si uno o varios de los datos no coinciden, el sistema cancela la acción y
vuelve al paso 4 para mostrar al usuario los datos incorrectos.

Tabla 26: Caso de uso #3

Caso de uso # 4
Caso de uso Consultar Usuario
Actores Root, Mesero y Chef
Propósito Permite a los usuarios consultar su cuenta
de usuario.
Resumen Comienza cuando el usuario decide
consultar la información de su propia cuenta
del usuario.
Tipo Esencial
Referencias
56
 Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario decide Consultar la 2. El sistema comprueba que el usuario que
información de una cuenta o la suya propia está tratando de acceder tenga el permiso.
accediendo a la función Consultar Cuenta.
3. El sistema muestra una lista de usuarios
que puede consultar.
4. El usuario selecciona cuenta a consultar 5. El sistema muestra todos los datos que
allí se encuentran registrados en la cuenta
seleccionada.
6. El usuario termina sección si no tiene
más cuentas a consultar.
Curso Alterno Consultar Usuario
Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.
Acción 6: Si el usuario desea consultar otras cuentas de usuario, regresara al paso 3.

Tabla 27: Caso de uso #4

Caso de uso # 5
Caso de uso Eliminar Usuario
Actores Root
Propósito Permite al usuario eliminar una o varias
cuentas.
Resumen Comienza cuando el usuario decide
eliminar una o varias cuentas.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario decide acceder a la función 2. El sistema comprueba que el usuario que
Eliminar cuenta. está tratando de acceder tenga el permiso.
3. El sistema muestra una lista de cuentas a
eliminar.
4. El usuario elige la cuenta a eliminar y 5. El servidor Acepta la solicitud y guarda
57
decide realizar la acción. los cambios en la base de datos.
Curso Alterno Eliminar Usuario
Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.
Acción 4: Si el usuario decide cancelar la acción podrá cancelar la acción y finalizar.

Tabla 28: Caso de uso #5

Caso de uso # 6
Caso de uso Ordenes en Cola
Actores Chef
Propósito Permite al usuario acceder al sistema para
visualizar las órdenes pendientes a
despachar.
Resumen Comienza cuando se tienen órdenes
pendientes por despachar.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa a Lista de Ordenes. 2. El sistema comprueba que el usuario que
está tratando de acceder tenga el permiso.
3. El sistema muestra una lista de órdenes a
despachar.
4. El usuario escoge orden para elaborar y 5. El sistema muestra la información de la
servir. orden (Sección Servir Orden).
6. El sistema actualiza la lista de órdenes
para repetir el proceso.
Curso Alterno Ordenes en Cola
Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.
Acción 6: Si el sistema tiene más órdenes en lista vuelve al paso 3.
Sección Servir Orden
1. El usuario accede a una lista de órdenes 2. El sistema muestra la información de la

58
en cola y selecciona una. orden.
3. El usuario consulta la información de la
orden.
4. El usuario prepara la orden y le indica al 5. El sistema Sirve la Orden y cambia de
sistema Servir Orden. estado actualizando las órdenes en lista y
guarda la información.
6. El sistema vuelve a la vista de Órdenes
en cola.
Curso Alterno Servir Orden
Acción 1. Si el usuario no desea ver la orden puede devolver a la ventana principal.
Acción 4. Si el usuario no desea Servir la Orden puede cancelar la opción y volver a la
vista de Ordenes en cola.

Tabla 29: Caso de uso #6

Caso de uso # 7
Caso de uso Facturar Orden
Actores Chef
Propósito Permite al usuario facturar una orden.
Resumen Comienza cuando el usuario Chef decide
imprimir el recibo de una mesa.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa a la opción Facturar 2. El sistema comprueba los permisos del
Orden. usuario.
3. El sistema muestra la lista de mesas con
órdenes sin facturar.
4. El usuario elige la mesa a imprimir 5. El sistema muestra la información de la
recibo. mesa con todas las órdenes sin facturar.
6. El usuario le indica al sistema imprimir 6. El sistema imprime la factura y guarda
factura. los cambios.
Curso Alterno Facturar Orden

59
Acción 2: Si el sistema detecta que el usuario no cuenta con los permisos debe cancelar
la acción y regresa al usuario al paso 1, mostrando un mensaje de error en los permisos.
Acción 6: Si el usuario no desea imprimir factura se cancela la opción y vuelve al paso
1.

Tabla 30: Caso de uso #7

Caso de uso # 8
Caso de uso Escoger Plato
Actores Chef
Propósito Permite al usuario acceder al sistema para
elaborar un plato del menú.
Resumen Comienza cuando se desea conocer
información sobre la preparación de un
plato del menú.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa a Escoger Plato. 2. El sistema comprueba que el usuario que
está tratando de acceder tenga el permiso.
3. El sistema muestra los platos indicados
para el menú del día. (Sección Preparar
Plato).
Curso Alterno Escoger Plato
Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.
Sección Preparar Plato
1. El sistema muestra una lista de platos del
menú.
2. El usuario selecciona un plato del menú. 3. El sistema le pide al usuario un valor
numérico positivo de cantidad para la
información de ingredientes necesarios para
elaborar el plato.
4. El usuario ingresa la cantidad de platos a 5. El sistema comprueba si existe la

60
preparar. cantidad ingresada.
6. El sistema muestra las cantidades de
ingredientes del plato seleccionado.
7. El usuario visualiza la información y 8. El sistema descuenta las cantidades
dispone a oprimir el botón Aceptar. ingresadas del Inventario y guarda los
cambios.
9. El sistema vuelve a la vista principal del
usuario.
Curso Alterno Preparar Plato
Acción 4. Si el usuario no desea agregar cantidades puede cancelar la opción al paso 1.
Acción 5. Si el sistema detecta que no existe escasez de ingredientes le mostrara un
mensaje al usuario y volverá a la ventana principal.

Tabla 31: Caso de uso #8

Caso de uso # 9
Caso de uso Crear Menú
Actores Chef
Propósito Permite al usuario Chef crear menús.
Resumen Comienza cuando el usuario Chef decide
crear un menú del día.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario decide crear un menú. 2. El sistema comprueba que el usuario que
está intentando ingresar a la función este
autorizado.
3. El sistema muestra una lista de platos
para registrar el nuevo menú y un valor para
su venta.
4. El usuario elige los platos para crear el 5. El sistema comprueba que los datos
nuevo menú. coincidan y guarda los cambios realizados.
6. El sistema lo devuelve a la ventana de
anterior.
61
 Curso Alterno Eliminar Menú
Acción 2: Si el sistema detecta que el usuario no cuenta con los permisos debe cancelar
la acción y regresa al usuario al paso 1, mostrando un mensaje de error en los permisos.
Acción 4: Si usuario decide cancelar la opción volverá al paso 1.
Acción 5: Si el sistema detecta que alguno de los campos del formulario no coincide,
cancela la acción y regresa al paso 4 mostrando los campos que no coinciden.

Tabla 32: Caso de uso #9

Caso de uso # 10
Caso de uso Eliminar Menú
Actores Chef
Propósito Permite al usuario Chef eliminar menús.
Resumen Comienza cuando el usuario Chef decide
eliminar un menú de la lista de menús.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario decide eliminar un menú. 2. El sistema comprueba que el usuario
que está intentando realizar esta acción
tenga los permisos necesarios.

3. El sistema muestra el listado de los

menús a eliminar.
4. El usuario elige el menú a eliminar y 5. El sistema acepta la solicitud y guarda
realizar la acción. los.
Curso Alterno Eliminar Menú

Acción 2: Si el sistema detecta que el usuario no tiene permisos para acceder a esta
aplicación, el sistema devuelve al usuario al paso 1 y muestra un mensaje de error en la
autorización del usuario.
Acción 4: Si el usuario decide cancelar la acción puede volver a la ventana principal.

Tabla 33: Caso de uso #10

62
Caso de uso # 11
Caso de uso Seleccionar Menú
Actores Chef
Propósito Permite al usuario Chef eliminar menús.
Resumen Comienza cuando el usuario Chef decide
eliminar un menú de la lista de menús.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario decide seleccionar un menú 2. El sistema comprueba los permisos del
del día. usuario.

3. El sistema entrega una lista de menús a

seleccionar.

4. El usuario selecciona el menú. 5. El sistema guarda los cambios.

Curso Alterno Seleccionar Menú

Acción 2: Si el sistema detecta que el usuario no cuenta con los permisos debe cancelar
la acción y regresa al usuario al paso 1, mostrando un mensaje de error en los permisos.
Acción 4: Si el usuario desea cancelar la opción volverá a la ventana principal.

Tabla 34: Caso de uso #11

Caso de uso # 12
Caso de uso Inventario
Actores Chef
Propósito Permite al usuario buscar algún producto en
la base de datos del inventario.
Resumen Comienza cuando el usuario Chef decide
obtener información sobre algún producto
que se encuentre en el inventario del
restaurante.

63
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa a Inventario 2. El sistema comprueba que el usuario
tenga la autorización para usar esta
funcionalidad

3. El sistema entrega una lista de

productos visibles y una caja de
brusquedad especifica.

4. El usuario ingresa el nombre del 5. El sistema muestra la información del

producto a buscar. producto.

6. El usuario termina sección si no tiene

más cuentas a consultar.

Curso Alterno Inventario

Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.

Acción 6: Si el usuario desea seguir consultando regresara al paso 3.

Tabla 35: Caso de uso #12

Caso de uso # 13
Caso de uso Ver menú del día
Actores Mesero
Propósito Permite al usuario visualizar el menú del
día.
Resumen Comienza cuando el usuario Mesero decide
obtener información sobre el menú del día
del restaurante.
Tipo Esencial
Referencias
Curso Normal de los Eventos
64
Acción de los actores Respuesta del sistema
1. El usuario ingresa a Menú del día. 2. El sistema comprueba que el usuario
tenga la autorización para usar esta
funcionalidad

3. El sistema entrega una visualización

sobre la información del menú del día.

4. El usuario termina ve la información.

Curso Alterno Ver menú del día

Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.

Tabla 36: Caso de uso #13

Caso de uso # 14
Caso de uso Tomar orden
Actores Mesero
Propósito Permite al usuario tomar la orden de la
mesa.
Resumen Comienza cuando el usuario Mesero toma
la orden de una mesa asignada.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa a Tomar Orden. 2. El sistema comprueba que el usuario
tenga la autorización para usar esta
funcionalidad

3. El sistema entrega una lista de mesas

para asignar orden.

4. El usuario selecciona una mesa para 5. El sistema verifica la disponibilidad de

asignar orden. la mesa.

65
 6. El sistema muestra los platos
disponibles para asignar a la orden.

7. El usuario toma la orden de los platos 8. El sistema guarda la información y lo

por cantidades con las cantidades registra en la base de datos.
correspondientes.

Curso Alterno Tomar orden

Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.

Acción 5: Si el sistema identifica que la mesa no está disponible, cancela la acción y

vuelve al paso 4.

Acción 7: El usuario puede cancelar la orden y volver a la ventana principal.

Tabla 37: Caso de uso #14

Caso de uso # 15
Caso de uso Añadir Orden
Actores Mesero
Propósito Permite al usuario añadir una orden a una
mesa.
Resumen Comienza cuando el usuario Mesero añade
una orden de más a las órdenes de la mesa
que se encuentre sin facturar.
Tipo Esencial
Referencias
Curso Normal de los Eventos
Acción de los actores Respuesta del sistema
1. El usuario ingresa Añadir Orden. 2. El sistema comprueba que el usuario
tenga la autorización para usar esta
funcionalidad

3. El sistema entrega una lista de mesas

que tiene órdenes asignadas para agregar
nueva orden.

66
4. El usuario selecciona una mesa para 5. El sistema muestra los platos
asignar la nueva orden. disponibles para asignar a la orden.

6. El usuario toma la orden de los platos 8. El sistema guarda la información y lo

por cantidades con las cantidades registra en la base de datos.
correspondientes.

Curso Alterno Añadir Orden

Acción 2: Si el sistema identifica que el usuario no tiene los permisos para acceder a la
funcionalidad, cancela la acción y vuelve al paso 1.

Acción 6: El usuario puede cancelar la orden y volver a la ventana principal.

Tabla 38: Caso de uso #15

67
 ANEXO 3

DIAGRAMA DE ACTIVIDADES

DIAGRAMA DE ACTIVIDADES # 1: INICIO DE SECCION

68
DIAGRAMA DE ACTIVIDADES # 2: RECUPERAR CONTRASEÑA

69
DIAGRAMA DE ACTIVIDADES # 3: CREAR USUARIO

70
DIAGRAMA DE ACTIVIDADES # 4: EDITAR USUARIO

71
DIAGRAMA DE ACTIVIDADES # 5: CONSULTAR USUARIO

72
DIAGRAMA DE ACTIVIDADES # 6: ELIMINAR USUARIO

73
DIAGRAMA DE ACTIVIDADES # 7: ORDENES EN COLA

74
DIAGRAMA DE ACTIVIDADES # 8: SERVIR ORDEN

75
DIAGRAMA DE ACTIVIDADES # 9: FACTURAR ORDEN

76
DIAGRAMA DE ACTIVIDADES # 10: ESCOGER PLATO

77
DIAGRAMA DE ACTIVIDADES # 11: PREPARAR PLATO

78
DIAGRAMA DE ACTIVIDADES # 12: CREAR MENU

79
DIAGRAMA DE ACTIVIDADES # 13: ELIMINAR MENU

80
DIAGRAMA DE ACTIVIDADES # 14: SELECCIONAR MENU

81
DIAGRAMA DE ACTIVIDADES # 15: INVENTARIO

82
DIAGRAMA DE ACTIVIDADES # 16: VER MENU DEL DIA

83
DIAGRAMA DE ACTIVIDADES # 17: TOMAR ORDEN

84
DIAGRAMA DE ACTIVIDADES # 18: AÑADIR ORDEN

85
 ANEXO 4

MODELO RELACIONAL

ESPECIFICACION DE ATRIBUTOS MER

Usuario
• ID: CHAR[20] PK
• CONTRASENA: CHAR[15]
86
 • TIPOUSUARIO: CHAR[10]
• NOMBRES: CHAR[40]
• APELLIDOS: CHAR[40]
• TELEFONO: BIGINT
• EMAIL: EMAILFIELD
• DIRECCION: CHAR[50]
• FECHANACIMIENTO: DATE
Root
• ID: INT PK
Mesero
• ID: INT PK
Chef
• ID: INT PK
Plato
• IDPLATO : INT PK
• NOMRE : CHAR[]
• TIPO : CHAR[]
• RECETA : CHAR[]
• PRECIO : LONG INT
Menú
• IDMENU: INT PK.
• PRECIO: LONG INT.
• ESTADO: BOOL.
Menú_platos
• IDMENU : INT
• IDPLATO : INT
Inventario
• IDINGREDIENTE : INT PK
• NOMBRE : CHAR[20]
• DESCRIPCION : CHAR[40]
• UNIDADMEDIDA : CHAR[20]
• CANTIDADDISPONIBLE : INT
• PRECIOUNIDAD : LONG INT
• CANTIDADMINIMA : INT
• ALERTA : BOOL
Orden
• IDORDEN : INT PK
• MESA : INT
• IDMESERO : INT
• ESTADO : CHAR[20]
87
Descripción_orden
• IDORDEN: INT PK
• MESA: INT
• IDPLATO: INT
• CANTIDAD: INT
Ingrediente
• IDPLATO: INT PK
• IDINGREDIENTE: CHAR []
• CANTIDAD: INT

88
 ANEXO 5

PLAN DE PRUEBAS DE APLICACIÓN MISTER CHEF

Introducción
Se redacta el plan de pruebas con el que se evaluaron las funcionalidades del software
codificado por el desarrollador del proyecto. Este documento no pretende sobrecargar las
tareas del desarrollador, sino mostrar una demostración que el trabajo realizado cumpla
con los objetivos del proyecto.

Elementos a Probar
Se realizaron pruebas modulares al software, incluyeron los siguientes módulos:
a) Gestión de usuarios. El módulo de gestión de usuarios consta de la creación,
modificación, eliminación y consulta de perfiles de usuario.
b) Autenticación. El módulo de autenticación es el que permite ingresar a los
usuarios a la aplicación por medio de un nombre de usuario y contraseña.
c) Gestión de recetas. Encargado de colaborar con la preparación de platos
entregándole al usuario chef los ingredientes necesarios para llevar a cabo esta
tarea.
d) Toma de orden. Permite al usuario mesero tomar una orden de acuerdo con el
menú del día y enviarla al chef.
e) Gestión de menús. Encargado de crear, eliminar y establecer el menú del día
de acuerdo a los platos que maneja el restaurante.
f) Inventario. Permite visualizar y actualizar la disponibilidad de productos para
preparar las comidas.
g) Atender orden. Atiende las ordenes tomadas por el mesero visualizando el
detalle de estas y poder servir el plato.
h) Facturar. Calcular el costo de la orden.

89
 Lista de riesgos de software

Riesgo. Descripción.

El servidor no funciona. Las pruebas no se pueden llevar a cabo

porque el servidor que tiene los datos con
los que trabaja el aplicativo está caído por
alguna razón.

Prototipos cambiantes. El desarrollador realizó algunas

modificaciones a la funcionalidad, pero no
advirtió sobre el cambio que se le debía
hacer al prototipo correspondiente.

Falta de recursos. Cuando se realizaron las pruebas puede que

no se obtuvieran los recursos suficientes
para llevarlas a término exitoso, por
ejemplo, se necesita un computador con más
capacidad de procesamiento, la red de
internet se encuentra caída, etc.

Tiempo reducido para las pruebas. Se necesitó más tiempo del asignado para
las pruebas y por lo tanto no se logró testear
las funcionalidades previstas.

90
 Alcance de las pruebas
Se prueban las siguientes funcionalidades: Gestión de usuarios, autenticación, gestión de
recetas, toma de orden, gestión de menús, inventario, atender orden y facturar.

Enfoque
Se realizan los siguientes tipos de pruebas:

• Pruebas de humo: Elegimos un conjunto de funcionalidades significativas, no

hace falta que sean todas las de la aplicación, y hacemos varias pasadas por cada
una de ellas. No es necesario que la cobertura sea amplia, ni forzar los límites,
basta con hacer una navegación pasando por las pantallas correspondientes
verificando que el comportamiento es el esperado.
• Pruebas de funcionalidad: Verificamos si el sistema lleva a cabo correctamente
todas las funciones requeridas, se debe verificar la validación de los datos y se
deben realizar pruebas de comportamiento ante distintos escenarios o vistas.
Nota: Estas pruebas se realizarán de manera manual.
• Pruebas de seguridad: Verifica que los usuarios solo puedan acceder a las
funcionalidades que tienen permitido hacerlo, y que solo los que tengan permiso
puedan realizar cambios en la base de datos.
Nota: Las pruebas se realizaron manualmente.

Criterios de paso/fallo para cada elemento

Modulo Criterio de Paso Criterio de Fallo

a) Gestión de usuarios. El sistema permite crear, No se puede realizar
consultar, editar y eliminar alguna de las
usuarios. siguientes acciones:
crear, consultar, editar
y eliminar usuarios de
la manera esperada.
b) Autenticación. El sistema permite realizar Los usuarios pueden
una correcto autenticación acceder con una
al usuario. contraseña inválida.
c) Gestión de recetas. El sistema muestra la El sistema realizó de
información para preparar el manera incorrecta los
plato de forma correcta y cálculos de los
además descuenta los ítems ingredientes para
correspondientes del preparar el plato.
inventario. El sistema no
disminuyó de manera
correcta las
disponibilidades de
91
 inventario.
d) Toma de orden. Se logró tomar y enviar la La orden no se pudo
orden de acuerdo al menú tomar o los datos que
del día y se aprobó la se le envían al chef no
validación de los datos de la son consistentes.
orden por parte del usuario
chef.
e) Gestión de menús. Se puede crear un menú del No se puede realizar
día de acuerdo con los alguna de las
platos establecidos en el siguientes acciones:
restaurante. Crear, eliminar o
Se puede cambiar el menú establecer menú del
del día. día.
Se puede eliminar el menú
del día.
f) Inventario. El sistema permite No se puede actualizar
visualizar los elementos del o visualizar los
inventario y además lo elementos de
actualiza de manera inventario.
correcta.
g) Atender orden. Se puede visualizar todos No se puede visualizar
los elementos de la orden todos los elementos de
para servir el/los plato(s). la orden para servir
el/los plato(s).
h) Facturar Los cálculos de los totales y La factura presenta
subtotales de la factura se inconsistencias con los
realizan de manera correcta. precios.

92
 Criterios de suspensión y requisitos de reanudación

Criterios de suspensión Requisitos de reanudación.

Fallos en la conexión con internet. La conexión con internet es eficiente.

El servidor web no está disponible. El servidor web se encuentra disponible.

No hay conexión con la base de datos. Se puede efectuar la conexión con la base de
datos.

La aplicación no pasó las pruebas generales Se realizaron las correcciones en la

o pruebas de humo. aplicación para que pasara las pruebas de
humo.

Documentos a entregar.
a. Documento de plan de pruebas.
b. Documentos casos y reporte de pruebas.

Necesidades de entorno.
c. Computador con un procesador de 2.0 GHz y 2 núcleos (lógicos o físicos), 2 GB
de memoria RAM.
d. Navegadores webs (Mozilla, Chrome, Internet Explorer) últimas versiones.

Responsabilidades
Julián Andrés Patiño: Desarrollador.

93
 ID Caso Descripción Paso a Paso Se debe
REQ Cumplir Salida
Tipo de Entrada Salida Esperada Observaciones
o HU Obtenida
Prueba SI NO
Ingresar a la página web
julian2016.pythonanywhere.com URL Abrir inicio de Página de
pf1 1 X
visitantes. inicio.

1) Escribimos el nombre de
usuario y contraseña.
2) Damos clic en ingresar Página principal
Usuario, Página
pf2 1 correspondiente al X
contraseña. principal.
tipo de usuario.

PRUEBAS 1) Hacemos click en la opción

DE tomar orden.
2) Seleccionamos una mesa. Re direcciona
FUNCIONA pf3 Cantidades de Re direccionar la
21 3) Ingresamos las cantidades de platos X la página
LIDAD. página principal.
los platos que se desean. principal.
4) Damos clic en enviar.
1) Entramos a la opción añadir
más platos a la orden.
Re direcciona
2) Seleccionamos la mesa. Cantidades de Re direcciona la
pf4 22 X la página
3) Ingresamos las cantidades de platos página principal.
principal.
los platos que se desean.
4) Damos clic en enviar.
1) Entramos a la opción añadir -Cuando intentamos Mensaje: El
-Valores
más platos a la orden. digitar letras no nos valor debe ser Los valores deben ser
pf5 22 negativos. X
2) Seleccionamos la mesa. deja. superior o igual superiores a 1
- Letras
3) Ingresamos valores negativos -Cuando intentamos a cero.
94
 y letras enviar valores Además el
4) Damos clic en enviar. negativos aparece un sistema no
mensaje de ingresar permite digitar
números positivos. palabras o
caracteres
diferentes de
números.
1) Ingresamos a la página de
administración de base de datos.
Los elementos
2) Entramos al inventario.
Los elementos a los a los cuales se
3) Ponemos en alarma la
cuales se les cambió les cambió el
disponibilidad de varios
el estado de alarma estado de
elementos.
Cambio de deben aparecer junto alarma
pf6 4) Cerramos sesión. X
estado con su cantidad en el aparecieron en
5) Ingresamos como chef.
cuadro rojo de la el cuadro rojo
6) Visualizamos en la página
página principal de de la página
principal si el cuadro que aparece
usuario chef. principal de
en rojo contiene los elementos
usuario chef.
cambiados a estado de alarma.

1) Estando logueados como chef

ingresamos a la opción lista de Aparece una tabla con Se pudo
URL
órdenes. las columnas plato y visualizar la
indicando el
pf7 11 2) Seleccionamos una mesa cantidad describiendo X orden de
número de
dando clic en el botón ver. los platos de una manera
mesa.
orden. correcta.

95
 1) Estando logueados como chef Aparece una
ingresamos a la opción preparar lista de
plato. Aparece una lista de ingredientes
Cantidades de
13, 2) Seleccionamos el plato a ingredientes con su con su
pf8 platos a X
14 preparar. respectiva cantidad y respectiva
preparar.
3) Digitamos la cantidad de unidad de medida. cantidad y
platos a preparar. unidad de
medida.
1) Estando logueados como chef
ingresamos a la opción preparar El sistema no deja
El sistema
plato. preparar el plato y
permite
13, 2) Seleccionamos el plato a Valores aparece un mensaje
pf9 X ingresar los
14 preparar. negativos. que dice: solo se
valores
3) Digitamos una cantidad pueden digitar valores
negativos.
negativa. negativos.

1) Estando logueados como chef

ingresamos a la opción gestión de
Selección de Re direcciona a
15, menús. Re direcciona a la
pf10 platos de X la página
16 2) Ingresamos a crear menú. página principal.
nuevo menú. principal.
3) Seleccionamos los platos
correspondientes y guardamos.
1) Estando logueados como chef
ingresamos a la opción gestión de El sistema no
menús. El sistema no
almacena el
15, 2) Ingresamos a crear menú. almacena el menú y
pf11 No aplica. X menú y vuelve
16 3) Damos click en el botón vuelve a cargar el
a cargar el
guardar sin seleccionar ningún formulario.
formulario
plato.

96
 1) Estando logueados como chef
El sistema
ingresamos a la opción gestión de
elimina el
menús. El sistema elimina el
Selección de menú
15, 2) Ingresamos a eliminar menú. menú seleccionado y
pf12 menú a X seleccionado y
17 3) Seleccionamos un menú a re direcciona a la
eliminar. re direcciona a
eliminar. página principal.
la página
4) Damos clic en el botón
principal.
eliminar
1) Estando logueados como chef
ingresamos a la opción gestión de Se muestra el
menús. El sistema vuelve a siguiente
15, 2) Ingresamos a eliminar menú. cargar el formulario mensaje de
pf13 No aplica. X error: menu
17 3) Damos clic en el botón para eliminar el
eliminar sin seleccionar un menú menú. matching query
does not exist.

1) Estando logueados como chef

El sistema
ingresamos a la opción gestión de
El sistema cambia el cambia el
menús. Selección de
15, menú del día y re menú del día y
pf14 2) Ingresamos a establecer menú nuevo menú X
18 direcciona a la página re direcciona a
del día. del día.
principal. la página
3) Seleccionamos un menú y
principal.
damos clic en guardar.
1) Estando logueados como chef
ingresamos a la opción gestión de Se muestra el
menús. El sistema no cambia siguiente
15, 2) Ingresamos a establecer menú el menú del día y mensaje de
pf15 No aplica. x error: menu
18 del día. vuelve a cargar el
3) Damos clic en guardar sin formulario. matching query
seleccionar ningún menú del día. does not exist.

97
 1) Estando logueados como chef Se carga la
ingresamos a la opción página de
Se carga la página de
inventario. inventario
inventario mostrando
mostrando una
una barra de búsqueda
barra de
pf16 19 URL y una tabla que x
búsqueda y una
describe todos los
tabla que
elementos del
describe todos
inventario.
los elementos
del inventario.
1) Estando logueados como chef La búsqueda se
ingresamos a la opción realizó de
inventario. manera
Si el elemento existe,
2) Buscamos un elemento del satisfactoria.
este aparecerá en una
inventario haciendo uso de la Para el caso de
tabla con todas las
barra de búsqueda. búsqueda de un
Cadena de características, de lo
pf17 19 x elemento que
caracteres. contrario, aparecerá
no existe
un mensaje de no se
apareció un
encontraron
mensaje que
elementos.
dice: no se
encontraron
elementos.
1) Estando logueados como chef
ingresamos a la opción mi perfil Se visualizaron
Se debe cargar una
de usuario. los datos del
vista con todos mis
pf18 6 2) Ingresamos a la opción URL x perfil de
datos de perfil
consultar mi perfil. usuario
excepto la contraseña.
logueado.

98
 1) Estando logueados como chef
ingresamos a la opción mi perfil
El sistema
de usuario.
El sistema guarda los guarda los
2) Ingresamos a la opción editar
Datos de cambios y re cambios y re
pf19 7 mi perfil. x
usuario. direcciona a la página direcciona a la
3) Aparecerá un formulario con
principal. página
los datos a editar.
principal.
4) Cambiamos los campos a
desear y guardamos los cambios.
1) Estando logueados como chef El sistema
El sistema mostrará
ingresamos a la opción facturar. mostró los
los detalles de la
2) Seleccionamos una orden detalles de la
Identificador factura con el valor
pf20 12 identificada por el número de x factura y
de mesa. total, además
mesa. cambió su
cambiará su estado a
estado a
facturada.
facturada.
1) Se intenta ingresar a la El sistema no
aplicación con una contraseña El sistema no permite permite entrar
Nombre de
incorrecta. entrar re re
ps1 1 usuario y X
direccionando a la direccionando
contraseña.
PRUEBAS página de inicio. a la página de
DE inicio.
SEGURIDA 2) Se intenta acceder a la El sistema no
D aplicación con un usuario que no El sistema no permite permite entrar
Nombre de
existe. entrar re re
ps2 1 usuario y X
direccionando a la direccionando
contraseña.
página de inicio. a la página de
inicio.

99
 1) Estando logueado como chef
ingresaremos a un link que hace El sistema no dejará
El sistema
que el chef ingrese a
Toda parte del usuario mesero. permitió
ps3 URL esta funcionalidad y X
s. ingresar a esta
re direccionará a la
funcionalidad.
página principal.

100
 Reporte de pruebas aplicación Mister Chef.
Fecha: 25/05/16

# Error ID caso de prueba Descripción. Estado final

1 pf9 El sistema permite
ingresar los valores
negativos en la
funcionalidad
preparar plato.
2 pf13 El sistema no
verificó en la
funcionalidad de
eliminar menú que
por lo menos uno de
los campos del
check box radio
button fuera
seleccionado.
3 pf15 El sistema no
verificó en la
funcionalidad de
selección de menú
del día que por lo
menos uno de los
campos del check
box radio button
fuera seleccionado.
4 ps3 El sistema permitió
ingresar a una
funcionalidad que no
corresponde al tipo
de usuario.

101
102