SGP: SISTEMA DE GESTIÓN DE PEDIDOS - UAB Barcelona
SGP: SISTEMA DEGESTIÓN DE PEDIDOSMemoria del proyectode Ingenieria Técnica enInformática de Gestiónrealizada porFrancisco Rodríguez Hernanzy dirigido porMónica DenhamEscola d’EnginyeriaSabadell, septiembre de 2010
SGP: Sistema de Gestión de PedidosLa abajo firmante, Mónica Denham,profesora de l'Escola d’Enginyeria de la UAB,CERTIFICA:Que el trebajo al que corresponde lapresente memoriaha estado realitzado bajo su direcciónpor en Francisco Rodriguez HernanzY para que conste firma la presente.Sabadell, -----Firmado: Mónica Denham2
SGP: Sistema de Gestión de PedidosResumenEste proyecto tiene como objetivo desarrollar una aplicación en formato web capaz de darsoporte a la gestión de los pedidos de restaurante. El proyecto incluye un entorno de trabajopara un administrador con pequeños módulos que ayudaran a realizar un buenmantenimiento del sistema.Nuestro objetivo comprenderá la creación de un pedido y sus posteriores fases hasta sufinalización.3
SGP: Sistema de Gestión de PedidosÍNDICEResumen. 3ÍNDICE . 41. PRESENTACIÓN . 71.1. Resumen . 71.2. Estado del arte . 71.3. Objetivo y alcance previstos . 111.4. Justificación. 112. ESTUDIO DE VIABILIDAD. 132.1. Introducción . 132.2. Objeto . 132.2.1. Situación del estudio . 132.2.2. Perfil de los usuarios del proyecto . 132.2.3. Objetivos . 142.3. Recursos. 142.3.1. Recursos de desarrollo . 142.3.2. Recursos de implementación . 152.4. Planificación del proyecto. 152.4.1. Planificación inicial . 152.4.2. Modelo de desarrollo . 172.5. Conclusiones . 183. ANALISIS DEL PROYECTO . 193.1. Requerimientos funcionales . 193.1.1. Visión general . 193.1.2. Requisitos funcionales de usuarios . 193.1.3. Vistas de casos de uso . 223.1.4. Diagramas de secuencia. 254
SGP: Sistema de Gestión de Pedidos3.2. Requerimientos no funcionales . 264. DISEÑO . 284.1. Introducción . 284.1.1. Selección del entorno de desarrollo . 284.1.2. Selección de base de datos . 284.1.3. Diagrama de Entidad-Relación . 304.2. Estructura de la base de datos . 304.2.1. Contenido de las tablas de la base de datos . 314.3. Arquitectura de la aplicación . 345. IMPLEMENTACIÓN . 355.1. Introducción . 355.2. Codificación de las diferentes capas de la aplicación. 355.2.1. Interfaces . 355.2.2. Entorno de usuarios. 375.2.4. Capa de datos . 416. PRUEBAS . 426.1. Pruebas de compatibilidad . 426.2. Pruebas de seguridad . 426.3. Pruebas de integración de servicio . 436.4. Pruebas según el tipo de usuario . 436.4.1. Usuario administrador . 436.4.2. Usuario cliente . 456.4.3. Usuario personal . 466.4.4. Usuario cocina . 487. CONCLUSIONES Y RESULTADOS . 497.1. Consecución de objetivos . 497.2. Desviaciones observadas . 495
SGP: Sistema de Gestión de Pedidos7.3. Líneas de ampliación . 507.4. Valoración personal de la experiencia. 508. ANEXO I: CASOS DE USO. 529. ANEXO II: DIAGRAMAS DE SECUENCIA. 6310. BIBLIOGRAFIA. 7110.1. Programación . 7110.1.1. Paginas web. 7110.1.2. Libros. 7110.2. Confección de la memoria . 716
SGP: Sistema de Gestión de Pedidos1. PRESENTACIÓN1.1. ResumenLa situación habitual en un restaurante en cuanto a pedidos, tiempo de espera, facturacióncorrecta, entre otros, no es la más ideal en la mayoría de los casos, lo que hace que resultedifícil dar un buen servicio al cliente, sobre todo durante las horas de mayor ocupación dellocal.Los recursos con los que se cuentan en un local de este tipo (restaurante, bar, etc.) sonescasos, y esto obliga al personal del restaurante a tener que desplazarse un gran un númerode veces de un lugar a otro para poder cumplir con su labor, ocasionando deficiencias en elservicio, olvido de órdenes, retardos, y equivocaciones en los pedidos debido a que elsistema que se utiliza es manual.Todo lo anteriormente explicado conlleva pérdidas económicas y de clientela que puedendeterminar el éxito o fracaso del negocio. Es por eso que se propone diseñar e implementarun sistema que brinde flexibilidad gracias al uso de terminales táctiles en cada unas de lasmesas, las cuales aumentarán la participación del cliente, otorgará flexibilidad por medio desus módulos configurables, ofrecerá información precisa garantizada por la aplicación, llevaráa cabo el control de usuarios, la integración de los procesos del negocio por medio de losdistintos módulos del sistema, optimización de los mismos debido a que el sistema reduce eltiempo de ejecución de los procesos y usabilidad. En el actual ámbito de desarrollo, elsistema será implementado y testeado sin la utilización de terminales táctiles (debido a sufalta de disponibilidad). Se asumen terminales con dispositivos de tipo ratón. De esta forma,es posible el desarrollo de la funcionalidad completa del software, previniendo que el cambioa pantallas táctiles sea mínimo.1.2. Estado del arteUn software de gestión de pedidos para restaurantes debe abarcar numerosas alternativasde facturación y control. Y debe ser lo más flexible posible. No son las mismas necesidadespara un restaurante de clase A que en un fast food. Debe ser una herramienta moldeable alas necesidades de control y gestión que precisa el cliente.Las necesidades más básicas para un restaurante son: disponer de un sitio donde ofertar losproductos, un sistema para la gestión de pedidos, y un registro donde poder almacenardichos pedidos y el coste de los mismos.7
SGP: Sistema de Gestión de PedidosActualmente, en el mercado se pueden encontrar numerosas soluciones software, lascuales se dedican a la gestión de restaurantes, cumpliendo con las necesidades másbásicas mencionadas previamente. Además, se pretende una mayor participación delcliente en el proceso de la gestión de pedidos, ya que con esa participación se ahorrarántiempos y mal entendidos, aparte de que sea de fácil manejo.Después de haber realizado una búsqueda de diferentes soluciones y aplicaciones quecumplen con las necesidades básicas, a continuación se van a citar las diferentes solucionesencontradas: AZHosteleriao hp RestaWebo http://www.techni-web.es RestBaro http://www.restbar.com/A continuación se detallan las principales características y carencias de dichas soluciones:AZHosteleriaEstá destinado a la gestión integral de negocios relacionados con la hostelería, y es poseedorde unas características que harán más simples todas las tareas a realizar en este entorno.Incluye TPV (terminal punto de venta) tanto táctil como de pantalla no táctil.Está preparado para gestionar distintas mesas, con precios diferentes según se trate de mesao barra. Ofrece control de camareros con distintos perfiles de acceso. Además de emitirtickets, puede emitir facturas, albaranes, compras, etc.También está habilitado para trabajar en red y mediante lector de código de barras aúncuando se use en el modo de pantalla táctil.Figura 1.1 – Pantalla principal AZHosteleria8
SGP: Sistema de Gestión de PedidosLa principal carencia de esta solución es la falta de participación del cliente en el proceso dehacer un pedido, aparte de que no se lleva ningún control del estado del pedido.RestaWebPropone una solución de TPV (terminal punto de venta, Figura 1.3) táctil y software degestión ágil y moderna para coordinar las operaciones tanto de comedor como de cocina y lagestión administrativa del establecimiento.Está pensado para dar solución a las ventas de mostrador que se realizan en un restaurante ocafetería. Sustituye la forma tradicional de trabajo en los restaurantes. Los empleadospueden anotar los artículos de cada mesa, mediante una interfaz totalmente gráfica y táctil,generándose automáticamente los pedidos a cocina y las líneas de stock.Existe la posibilidad de utilizar varios idiomas, para un uso más personalizado.Figura 1.2 – Pantalla principal RestaWebFigura 1.3 – TPV de RestaWeb9
SGP: Sistema de Gestión de PedidosAl reducir los desplazamientos del personal y mejorar la comunicación, reducirá el tiempo derotación de la mesa notablemente, especialmente en momentos de máxima ocupación.La solución de RestaWeb pese a ser bastante buena, carece de la participación del cliente,estos es algo que se busca desde el principio.RestBarEl programa RestBar integra las diferentes áreas de control para su negocio, la facturación demesas, ventas rápidas y servicio express (delivery), recetas y costos, la caja (ingresos yegresos de dinero), los inventarios de bebidas, insumos y otros, control de entradas y salidasde empleados, las cuentas por cobrar a clientes, las cuentas por pagar a proveedores, lasreservaciones de clientes, la planeación de eventos (cálculo de requerimientos de insumos),estadísticas mensuales varias y utilitarios. Además de una ágil y completa interfaz táctil o"touchscreen" para el trabajo de los camareros y cajeros.Figura 1.4 – Pantalla principal de RestBarFigura 1.5 – Listado de mesas de RestaBar10
SGP: Sistema de Gestión de PedidosUtiliza también TPV, y como la opción anterior, RestaWeb, vuelve a tener la carencia de laparticipación con el cliente, aparte de que todo el sistema está centralizado en un mismopunto, el TPV.En conclusión, todos las soluciones vistas, complacen las necesidades básicas, disponer de unsitio donde ofertar los productos, un sistema para la gestión de pedidos, y un registro dondepoder almacenar dichos pedidos y el coste de los mismos, pero ninguno de ellos cumple elrequisito de la participación del cliente a la hora de la gestión de pedidos, ya que todas lassoluciones encontradas utilizan TPV a la vez que utilizan camareros, es decir, laimplementación del TPV hace que la participación del cliente no aparezca.1.3. Objetivo y alcance previstosAutomatizar la gestión de pedidos de una empresa relacionada con el sector de larestauración. Para esto se desarrollará una aplicación Web que permita gestionar lainformación sobre pedidos, como así también información relacionada a los usuariosregistrados. Lograr una mayor participación del cliente a la hora de realizar pedidos,consiguiendo mejorar el tiempo del proceso de gestión de los mismos.También manejará información referente a los productos ofrecidos, y permitirá realizar partede la facturación de la empresa.1.4. JustificaciónEs habitual que en este tipo de empresas (restaurantes, bares, taperías, etc.), el proceso deatención al cliente se realice de forma que no deje satisfecho al cliente: ¿cuántas veces nosquejamos porque se tarda demasiado tiempo en ser atendidos?, o por el contrario, ¿aún nohemos decidido qué elegir y el encargado de registrar los pedidos ya está dispuesto a tomarnota?Las ventajas que obtendrá la empresa con la utilización de un sistema que automatice lagestión de pedidos son múltiples. Las más importantes se pueden resumir en: Mejorar la atención al cliente: el cliente podrá pedir cualquier producto cuando él lodeseé, sin depender de la disponibilidad de otra persona (camarero). El sistema realizará la gestión de una parte del manejo económico de la empresa:cada pago de un pedido se registrará, permitiendo conocer cuánto dinero ha dehaber en la caja, al final del día, del mes o durante un determinado periodo detiempo.11
SGP: Sistema de Gestión de Pedidos Ahorrar en personal, ya que la automatización de procesos, hace que intervenganmenos personas, y que se puedan dedicar a otros procesos internos. Colaborar con el medio ambiente ahorrando en papel, ya que cada vez que senecesite actualizar la carta con los productos ofertados, no hará falta volver aimprimir nuevas cartas. Realizar estadísticas y estudios, ya que se dispondrá de información almacenada en labase de datos, relacionada a los pedidos realizados por los clientes.Las desventajas que obtendrá la empresa con la utilización de un sistema que automatice lasgestión de pedidos son muy pocas. Las más importantes se pueden resumir: Inversión inicial, ya que al ser un sistema desarrollado a medida, supone un costemás amplio. Hardware, dependiendo del que se disponga, hay que hacer una inversión económicamayor o menor.Automatizar un sistema o procesos conlleva a una serie de ventajas y desventajas. Comohemos demostrado, en este caso las ventajas son mayores que las desventajas, por lo querealizar esta automatización tendrá como resultado un beneficio con respecto al sistema sinautomatizar.12
SGP: Sistema de Gestión de Pedidos2. ESTUDIO DE VIABILIDAD2.1. IntroducciónEl objetivo del estudio de viabilidad es el análisis de un conjunto concreto de necesidadespara proponer una solución a corto plazo, que tenga en cuenta restricciones económicas,técnicas, legales y operativas.El estudio de viabilidad se orientará a la especificación de requisitos ya que costos, riesgos,problemas legales, etc., están fuera de este proyecto.Durante el desarrollo de este capítulo se analizará el alcance de la necesidad planteada y seidentifican las restricciones relativas a la sincronización con otros procesos, que puedaninterferir en la planificación y futura puesta a punto del sistema objeto de estudio. Estainformación se recoge en el apartado de requisitos.2.2. Objeto2.2.1. Situación del estudioEl proyecto está pensado para restaurantes que no dispongan de un sistema automatizadopara la gestión de sus pedidos.Después de haber analizado distintas necesidades de restaurantes que no disponen deningún sistema automatizado de gestión, a continuación se exponen las necesidades demejora más importantes de dichos sistemas: Gestión de pedidos.Control de productos ofertados.Control de cuentas parcial.2.2.2. Perfil de los usuarios del proyectoComo se explicará en el capítulo 3, existen distintos tipos de usuarios, para los cuales elsistema ofrecerá un conjunto de funcionalidades específicas. Independientemente del tipode usuario, el sistema será desarrollado con el objetivo de que sea fácil de utilizar, intuitivo yque no se requiera conocimiento previo por parte de los usuarios, para que sea accesible acualquier tipo de persona, tenga conocimientos de las nuevas tecnologías o no.13
SGP: Sistema de Gestión de Pedidos2.2.3. ObjetivosA. Objetivo GeneralDesarrollar un sistema de gestión de información de pedidos basado en módulosconfigurables, que permita automatizar parte del proceso generado por un cliente: ordenarsu comida, facturarla, atenderla, etc. Además, el sistema permitirá manejar la informaciónasociada a las distintas comidas ofrecidas.B. Objetivos específicos Mejorar la gestión actual de los pedidos realizados por los clientes. Agilizar y mejorar el proceso de la información centralizada. Información centralizadase entiende como pedidos, información de productos y facturas. Detectar fallos/errores entre los teóricos productos ofertados y los reales:actualización de productos. Comprobar que los productos ofertados son loscorrectos. Generar una cuenta/factura al finalizar el servicio. Ha de recoger informaciónreferente a los productos consumidos y el precio de los mismos. Los usuarios se han de identificar para utilizar la aplicación. Implementar un sistemapara el control de permisos. Mejorar la implicación del sistema con el cliente.2.3. Recursos2.3.1. Recursos de desarrolloRequisitos mínimos para el desarrollo de la aplicación. Hardware:o PC/MAC 2.0 GHz, 1Gb memoria RAM, 100Gb de disco duro.o Conexión a internet: 1Mb. Software:o Servidor Web: Apache.o Entorno de desarrollo: Eclipse for php developers.o Base de datos: MySQL.14
SGP: Sistema de Gestión de PedidosoooooEditor de base de datos: phpMyAdmin.Programacion web: PHP, HTML, AJAX, jQuery.Sistema Operativo: Windows XP/Linux/MAC OSNavegador: Mozilla Firefox/Google Chrome/OperaDocumentación del proyecto: Open OfficeEn el capitulo 4, se explicarán las tecnologías mencionadas en la lista previa.2.3.2. Recursos de implementaciónRequisitos mínimos para la implementación de la aplicación. Servidoro Servidor LAMP (Linux, Apache, MySQL, PHP), 1Gb memoria RAM, 1 GB de discoduro. Hardware del terminal del administrador/cocina/personalo PC/MAC 2.0 GHz, 1Gb memoria RAM, 1 Gb de disco duro. Software del terminal del administrador/cocina/personalo Navegador: Mozilla Firefox/Google Chrome/Opera Hardware del terminal del clienteo PC/MAC 2.0 GHz, 1Gb memoria, 1 Gb de disco duro.o Monitor LCD chasis de pantalla táctil 3M MicroTouch 15”.o Ratón, en caso de no disponer pantalla táctil. Software del terminal del clienteo Navegador: Mozilla Firefox/Google Chrome/Opera2.4. Planificación del proyecto2.4.1. Planificación inicialNumero12TareaInicio del proyecto: asignación ymatriculación del proyectoPlanificaciónDescripciónAsignación y matriculación del proyectoelegido.Planificar las tareas del proyecto,subtareas y tiempos.15
SGP: Sistema de Gestión de Pedidos34Análisis de la aplicaciónEstudio del lenguaje5Diseño de la aplicación6Desarrollo de la aplicación7Pruebas8Implementación910Generación de documentos (memoriadel proyecto)Cierre del proyecto11Defensa del proyectoAnálisis de requisitos del sistema.Estudio de lenguaje en el cual seimplementara la aplicaciónDiseño de las distintas partes queconforman la aplicación.Desarrollar la aplicación una vezrealizado las fases de análisis y diseño.Realización de pruebas del sistema: Compatibilidad Seguridad Integración del servicio Según el tipo de usuarioInstalación y configuración del sistemaen un ordenadorGeneración de la memoria del proyecto,detallando los pasos seguidos.Comprobación de que el proyecto estácorrectamente concluido.Defensa del proyecto delante de untribunal.En la figura 2.1 se muestra una tabla, la primera hace referencia a la planificación, en la cualaparecen una columna con las horas que se habían previsto para la realización del sistema.Figura 2.1 – Tareas del sistema, con duración prevista.* 1 día 24 horas.A continuación se muestra un diagrama de Gantt, en el cual aparecen las actividadesnecesarias para desarrollar el sistema.16
SGP: Sistema de Gestión de PedidosFigura 2.2 – Diagrama de Gantt de las tareas del proyecto.2.4.2. Modelo de desarrolloSe ha elegido el modelo de desarrollo evolutivo, que es una metodología de desarrollo desoftware muy relacionada con, pero claramente distinta de, desarrollo por prototipos. Elénfasis está puesto sobre la importancia de obtener un sistema de producción flexible yexpandible. Así, si los requerimientos cambian durante el desarrollo del sistema, entoncescon un mínimo de esfuerzo y tiempo se puede desarrollar un sistema de trabajo flexible.La diferencia fundamental entre desarrollo evolutivo y prototipos de software es que eldesarrollo evolutivo busca reemplazar el viejo sistema con uno nuevo que tendría lapropiedad de satisfacer los nuevos requerimientos lo más rápido posible. En contraste,prototipos usa un enfoque iterativo sólo para determinar los requerimientos17
SGP: Sistema de Gestión de Pedidosorganizacionales. Por lo tanto el tiempo tomado entre cada iteración es mucho másimportante para el desarrollo evolutivo.El desarrollo evolutivo asume que los requerimientos de un proyecto están sujetos a cambioscontinuos, por lo cual es necesario definir una estrategia de desarrollo que refleje estasituación.La idea entonces de la metodología de desarrollo evolutivo es estar liberandoconstantemente una nueva versión del sistema que sea completamente funcional; así, cadasistema producto de las iteraciones sucesivas del método tendría incorporado los nuevosrequerimientos que ha sido posible identificar y que no estarían considerados en la anteriorversión.Así, las etapas del desarrollo evolutivo tienen por objetivo extender los incrementos de unproducto de software operacional, en las direcciones determinadas por la evolución de laexperiencia operacional.El método evolutivo tiene la gran ventaja de reconocer la existencia de una constante decambios en los requerimientos y, desde esta premisa, propone una solución, la cual es válidapara la solución de ese problema pero que no resolvería la inquietud original.2.5. ConclusionesDespués de haber analizado el problema, ver qué soluciones existen en la actualidad exteriorpara solucionar este problema, podemos llegar a las siguientes conclusiones: No existe prácticamente en el mercado un software que se adapte a todas lasnecesidades buscadas.Los recursos para el desarrollo e implementación del software no son difíciles deconseguir, excepto las pantallas táctiles para la cual se propone como alternativa lautilización de ratones.Existe una programación la cual ayuda para llevar un seguimiento de las mismas.El modelo de desarrollo es idóneo para este tipo de proyectos.Una vez expuestas las conclusiones, la última conclusión que se podría extraer es que esteproyecto es “VIABLE”.18
SGP: Sistema de Gestión de Pedidos3. ANALISIS DEL PROYECTO3.1. Requerimientos funcionales3.1.1. Visión generalComo ya se ha mencionado, este proyecto tiene como objetivo desarrollar un aplicativo enformato web capaz de dar soporte a la gestión de pedidos de un restaurante y su posterioratención.Nuestro objetivo comprende desarrollar un sistema de gestión de restaurantes basado enmódulos configurables, que permita automatizar parte del proceso generado por un cliente:ordenar su comida, facturarla, atenderla, etc.El modulo de gestión de pedidos está diseñado para contener la información de los pedidosque se encuentren activos mediante la utilización de una base de datos. Dentro de cadapedido se sabrá que productos se ha elegido, y sus características.Además existe la posibilidad de mantener y manejar la información de los productosofertados, mesas y datos personales de los clientes. El administrador tiene la posibilidad demodificar toda esta información.Existirán al menos cuatro tipos de usuarios a saber: Administrador: Administración de productos, mesas y facturas. Camarero: Modificación de pedidos y atención de los mismos. Cocinero: Atención de los pedidos, modificación del estado de cada pedido. Cliente: Creación de pedidos.3.1.2. Requisitos funcionales de usuariosA continuación se presentan los requisitos funcionales de cada tipo de usuario, con fin dedetallar los roles o capacidades de cada uno de ellos en el proyecto. Usuario cliente. Acciones que puede realizar el usuario cliente:19
SGP: Sistema de Gestión de Pedidoso Registrarse Si el cliente desea obtener la factura de su pedido, deberá registrarse paraque el sistema utilice sus datos personales. Si por alguna razón ajena alsistema, el usuario no desea registrarse, existe la posibilidad de utilizar untipo de cliente “anónimo”.o Crear pedido. Una vez el cliente haya consultado los productos.o Agregar un producto al pedido.o Visualizar pedido. Siempre puede saber qué productos existen en el pedido y el costo de losmismos (unitario y en general, lo que se lleva gastado).o Modificar el pedido antes de la confirmación de envío. Antes de enviar el pedido, se preguntará si todos los productos introducidosson los correctos, puesto que una vez confirmado ya no se tiene laposibilidad de modificarlo, sólo puede añadir más productos a su pedido.o Elegir cómo se efectuará el pago del pedido. Elegir la forma de pago entre las opciones: pago en metálico, pago contarjeta de crédito o Pay-pal.o Elegir el idioma que desee utilizar entre los idiomas disponibles.Acciones que no puede realizar el usuario cliente:o No puede agregar productos nuevos a la lista de productos ofertados.o Modificar/anular el contenido del pedido una vez haya sido confirmado. Una vez confirmados los productos que componen el pedido, éste ya no tieneposibilidad alguna de sufrir una modificación o una anulación.o Varios pedidos desde una misma mesa. Sólo es posible realizar un pedido desde una mesa, no hay posibilidad dehacer varios pedidos por mesa. Se puede ir agregando productos al pedido,siempre que no esté en estado “CERRADO”.20
SGP: Sistema de Gestión de Pedidos Usuario personal. Acciones que puede realizar el usuario personal:o Modificar/anular pedidos. Se puede modificar o anular el contenido de un pedido desde este usuario si,y solo si, el producto no tiene estado “servido”.o Consultar productos ofertados Consultar los productos que están ofertados.o Identificar mesas Identificar cada terminal con el número de mesa correspondiente.o Elegir el
SGP: Sistema de Gestión de Pedidos 9 La principal carencia de esta solución es la falta de participación del cliente en el proceso de hacer un pedido, aparte de que no se lleva ningún control del estado del pedido. RestaWeb Propone una solución de TPV (terminal punto de venta, Figura 1.3) táctil y software de
El Sistema Operativo Linux Javier Parapar Contenido Contenido 1 El software libre y Linux. Distribuciones 2 Primeros pasos en Linux 3 Instalaci on de distribuciones 4 Gesti on de archivos (I) 5 Gesti on de archivos (y II) 6 Edicion de archivos de texto 7 Gesti on de usuarios y procesos 8 Shell scripts 9 Arranque, reinicio y apagado del sistema 10 Logs del sistema 11 Sistema gr afico Xwindow
Oil-free compressed air 0 50(Without frozen) 0.15 0.6 Unit SGP-L280 SGP-L416 SGP-L560 Nozzle number Supplied air pressure Max. vacuum pressure Suction flow rate Air consumption amount Exhausted air sound volume Pcs MPa (-)kPa L/min(ANR) L/min(ANR) Vacuum port open dB(A) Vacuum port close dB(A) 0.45 70 323 104 71 64 1 0.55 90 356 126 55 2 0 .
Un Modelo de Gesti n para la Supervisi n Escolar fue elaborado por la Direcci n General de Desarrollo de la Gesti n e Innovaci n Educativa, de la Subsecretar a de Educaci n B sica, en el marco del Programa Escuelas de Calidad, y es una obra derivada de los libros Orientaciones t cnicas para fortalecer la acci n
Flexovit — — — Razorblade A60SST Razorblade A24T, 30V, 36T —— Pearl — Redline Max Slimcut — Slimcut — Slimcut Pro-V, Silverline — Pferd — SGP-ZA-Q-INOX SG-A-R-INOX, SGP-A-S-INOX SG-A-S, SGP-A-T — PSF-A-P S-G-N-ALU Sait — Z-tech XA46R — A60S, Saitech SAIT.M.X A46N Spedecut — ————A46, 60 TBXX —
La comunicazione non verbale – Interpretazione del linguaggio del corpo, dei gesti e della mimica facciale „Arbeitswelt 2020“ 25 - 29 aprile 2016 A Nell-Breuning-Haus, Wiesenstraße 17, D-52134 Herzogenrath Martedì, 26 aprile, ore 14:30 Comunicazione non verbale Interpretazione del linguaggio del corpo, dei gesti e della mimica facciale
Gli italiani, si sa, sono famosi per il loro gesticolare ed il muoversi con animosità mentre parlano. Alcuni gesti, inoltre, hanno veramente un significato più complesso che può sostituire non solo una parola ma i
Bin Kassim Mohd Rafi (Sgp) Binte Jaffar Satimah (Sgp) Binti Johari Ramlah (Mys) Binti Punari Lela Suhaili (Mys) Binti Samsudin Nurul Raihana (Mys) Blaire Emily Kilner (Usa) Blaire St. John (Usa) Blanca Oyervides Flores (Mex) Bonnie Brookshire (Usa) Bonnie Petroschuk (Usa) Boon Theng Ong (Mys) Boryana Iribadzhakova (Usa) Bowes, Megan (Usa)
Agile Development and Scrum Scrum is, as the reader supposedly knows, an agile method. The agile family of development methods evolved from the old and well- known iterative and incremental life-cycle approaches. They were born out of a belief that an approach more grounded in human reality – and the product development reality of learning, innovation, and change – would yield better .
