Herramienta de simulación de colas para dimensionar puntos de servicio

Trabajo de Final de Grado Grado en Ingeniería en Tecnologías Industriales Herramienta de simulación de colas para dimensionar puntos de servicio MEMORIA Autor: David Caballero Flores Director: Pere Grima Cintas Convocatoria: Septiembre, 2016 Escola Tècnica Superior d’Enginyeria Industrial de Barcelona Lo importante es no dejar de hacerse preguntas. Albert Einstein Herramienta de simulaci´on de colas para dimensionar puntos de servicio iii Resumen Este proyecto tiene por objetivo el desarrollo de un programa inform´atico de c´odigo libre, con interfaz de usuario y capaz de modelar y simular de forma flexible un sistema de colas. El m´ovil del programa es poder valorar el comportamiento de un punto de servicio frente a la llegada de usuarios y, estudiar mediante simulaciones y extracciones de datos, si es m´as o menos ´optimo que otras configuraciones del mismo sistema. Para su desarrollo se ha utilizado el lenguaje de programaci´on Python y, entre otros, el m´odulo SimPy para construir el gestor de la simulaci´on y QtDesigner para el dise˜no de la interfaz de usuario. SimuQ 1.0 se convierte, al final del proyecto, en una herramienta vers´atil a la hora de definir sistemas de colas que modelan puntos de servicio. Es capaz de simular el comportamiento del sistema e incluso mostrar la simulaci´on por pantalla para casos poco complejos. Tras la simulaci´on se generan archivos de datos que permiten tomar decisiones y valorar la eficiencia del sistema. Por ser una primera versi´on y formar parte de un proyecto de final de carrera, con calendario de entrega y presentaci´on, se han limitado las l´ıneas de desarrollo. Sin embargo, el hecho de ser de c´odigo libre, permite que el programa se siga desarrollando o se pueda modificar para un uso espec´ıfico de sus funciones. En este texto y en el propio c´odigo se puede encontrar la informaci´on necesaria para comprender el funcionamiento de SimuQ 1.0. iv Herramienta de simulaci´on de colas para dimensionar puntos de servicio Herramienta de simulaci´on de colas para dimensionar puntos de servicio v ´ Indice general Resumen III Lista de figuras VI 1. Prefacio 1 1.1. Contextodelproyecto ................................. 1 1.2. Antecedentes ...................................... 2 1.3. Motivaci´on y justificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introducci´on 5 2.1. Objetivos ........................................ 5 2.2. Alcanceylimitaciones ................................. 6 3. Elementos y caracter´ısticas de un sistema de colas 7 3.1. Elementos de un sistema de colas . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Usuarios..................................... 7 3.1.2. Ventanasdeservicio .............................. 8 3.1.3. Cola....................................... 8 3.1.4. Reloj....................................... 8 3.2. Caracter´ısticas de un sistema de colas . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Patr´on de llegada de los usuarios . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Patr´on de servicio de las ventanas . . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. Disciplinadecola................................ 11 3.2.4. Capacidad del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.5. N´umero de puntos de servicio por ventana o servidores en paralelo . . . . 12 3.2.6. N´umero de etapas de servicio . . . . . . . . . . . . . . . . . . . . . . . . . 12 vi Herramienta de simulaci´on de colas para dimensionar puntos de servicio 4. Herramientas para el desarrollo del programa 15 4.1. Lenguaje de programaci´on y entorno de desarrollo . . . . . . . . . . . . . . . . . 15 4.2. M´odulosylibrer´ıas................................... 16 4.3. Constructordeinterfaz................................. 18 4.4. Compilador ....................................... 18 5. Desarrollo de SimuQ 1.0 19 5.1. Definici´ondelsistema ................................. 19 5.1.1. Nombrar´ıtems ................................. 19 5.1.2. Ventanasdeservicio .............................. 20 5.1.3. Usuarios, definici´on de las llegadas . . . . . . . . . . . . . . . . . . . . . . 23 5.1.4. Configuraci´on de la simulaci´on . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.5. Funciones y variables esenciales . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2. Ejecuci´on de la simulaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.1. Elementos del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.2. Funciones y m´etodos principales . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.3. S´ıntesis de la simulaci´on gr´afica . . . . . . . . . . . . . . . . . . . . . . . . 36 5.3. Visualizaci´ondedatos ................................. 38 6. Resultados 41 6.1. Alcancedeobjetivos .................................. 41 6.2. Diagramasdeflujo ................................... 42 6.3. Relaci´ondeerrores................................... 42 7. Planificaci´on temporal y costes 47 Conclusiones y l´ıneas futuras 49 Agradecimientos 51 Bibliograf´ıa 53 Bibliograf´ıa complementaria 55 Herramienta de simulaci´on de colas para dimensionar puntos de servicio vii ´ Indice de figuras 3.1. Ejemplo de funci´on de densidad de una distribuci´on Normal. Fuente: Wikipedia. 11 3.2. Esquema de cola monocanal y multicanal. Extra´ıda de [2]. . . . . . . . . . . . . 12 4.1. Logo de Python. .................................... 16 4.2. Logo de Spyder. .................................... 16 5.1. Esquema de diferentes tipos de ventana definibles con SimuQ 1.0. ........ 21 5.2. Esquema de definici´on de patr´on de llegada de usuarios con SimuQ 1.0. . . . . . 24 5.3. Per´ıodos de llegadas de usuarios de 200 cada 500 con un tiempo de simulaci´on de1800.......................................... 26 5.4. C´odigo para crear el entorno de simulaci´on con SimPy. Extra´ıdo de intensive simulation.py. .................................... 29 5.5. C´odigo de ejemplo para lanzar un evento de petici´on de una ventana de servicio (windows) con prioridad prio. ............................ 30 5.6. Expresi´on para poner a la cola un evento de avanzar el reloj un tiempo de (t atention A+dead time A). C´odigo extra´ıdo de intensive simulation.py. . . . . 31 5.7. C´odigo para lanzar la simulaci´on mediante la funci´on user generator. Extra´ıdo de intensive simulation.py................................ 32 5.8. Diagrama de flujo de la funci´on choose window(user). ............... 33 5.9. C´odigo para comparar par´ametros entre opci´on de ir a dos ventanas o a una que ofrezca dos servicios. Extra´ıdo de intensive simulation.py. ............. 35 5.10. Diagrama de flujo del m´etodo param de la clase Windows.............. 35 5.11. C´odigo para recalcular el par´ametro param de una ventana con prioridad frente a un usuario no prioritario. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.12. Ejemplo simulaci´on gr´afica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.13. Ejemplo de gr´afico interactivo de evoluci´on temporal de colas. . . . . . . . . . . . 39 6.1. Diagrama de flujo de la interfaz de SimuQ 1.0. . . . . . . . . . . . . . . . . . . . 43 viii Herramienta de simulaci´on de colas para dimensionar puntos de servicio 6.2. Diagrama de flujo del proceso de simulaci´on intensiva de SimuQ 1.0. . . . . . . . 44 6.3. ´ Arbol de fallos de SimuQ 1.0. ............................ 45 7.1. Diagrama de Gantt del desarrollo del proyecto. . . . . . . . . . . . . . . . . . . . 47 Herramienta de simulaci´on de colas para dimensionar puntos de servicio 7 Cap´ıtulo 3 Elementos y caracter´ısticas de un sistema de colas En este cap´ıtulo, a modo de marco te´orico, se identificar´an los elementos que forman un sistema de colas gen´erico y, a continuaci´on, se estudiar´an las caracter´ısticas que definen el sistema. De esta manera, una vez conocidos los elementos y sus caracter´ısticas se podr´a pasar a valorar y definir la manera en la se implementar´an en el programa. 3.1. Elementos de un sistema de colas A continuaci´on se mencionan y se explican los elementos, f´ısicos o no, que forman un sistema de colas. 3.1.1. Usuarios El usuario es el elemento que llega al sistema, dispuesto a esperar una cola, para recibir uno o m´as servicios. Es un elemento din´amico. Esto quiere decir que su estado, definido por sus variables, cambia en funci´on del tiempo. Pese a que usuario tiene una connotaci´on de persona, cabe decir que se pueden definir usuarios que sean, por ejemplo, piezas que esperen a ser procesadas en una m´aquina. En ese caso, la m´aquina ser´ıa la ventana de servicio que, no tiene porqu´e ser tampoco una taquilla convencional. Para definir un usuario que llega al sistema, se puede hacer a partir de las siguientes variables: Identificador. Tipo de usuario. 8 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Tipo(s) de servicio(s) que requiere. Tipo(s) de servicio(s) que ya ha recibido. Tiempo de llegada. N´umero m´aximo de personas en la cola o tiempo que est´a dispuesto a esperar. 3.1.2. Ventanas de servicio Las ventanas de servicio son los puntos del sistema que, con una capacidad de atenci´on determinada, satisfacen las necesidades de servicios de los usuarios. Para definir una ventana del sistema, se pueden utilizar las siguientes variables: Identificador. Tipos de usuario a los que da servicio. Tipos de servicio que ofrece. N´umero de servidores en paralelo. Tiempo de atenci´on. Tiempo muerto entre servicios. 3.1.3. Cola La cola tambi´en es un elemento din´amico del sistema. La fila de usuarios que se encuentran a la espera de una ventana de servicio forma la cola de esa ventana. Dicha fila est´a ordenada seg´un una prioridad establecida. Los par´ametros que definen una cola gen´erica son los siguientes: N´umero de usuarios en cola. Disciplina de la cola. N´umero m´aximo de usuarios en cola. 3.1.4. Reloj El reloj del sistema es un elemento intangible pero importante a la hora de lanzar y coordinar eventos en diferentes instantes de tiempo. El reloj marca el instante en el que se encuentra el sistema respecto a un instante inicial que se toma de referencia. El reloj queda definido al determinarse el instante inicial o tiempo cero. 3.2. Caracter´ısticas de un sistema de colas Las caracter´ısticas que definen un sistema de colas y que se mencionan en esta secci´on se basan en la recopilaci´on de Jos´e Pedro Garc´ıa Sabater en [2]. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 9 3.2.1. Patr´on de llegada de los usuarios Si se observa la llegada de usuarios a un sistema cualquiera, seguramente parezca que no existe ning´un patr´on entre llegadas consecutivas. Sin embargo, normalmente existen una gran cantidad de factores que determinan que un usuario decida ir al sistema en un momento u otro y que permiten modelar con precisi´on la llegada de usuarios mediante variables estad´ısticas. Entonces, se dice que la llegada es estoc´astica, pues depende de una variable aleatoria. Para el caso de procesos, por ejemplo, la llegada de piezas a la m´aquina s´ı que est´a m´as determinada por el propio proceso y no est´a sometida a tanta aleatoriedad. La determinaci´on de las variables aleatorias que definen las llegadas de usuarios se escapa del objetivo del proyecto. Sin embargo, su uso est´a fuertemente anclado a la definici´on del modelo de simulaci´on y, es por ello, que se har´a una revisi´on de los principales modelos utilizados para definir llegadas de usuarios. Distribuci´on exponencial y de Poisson Las distribuciones m´as utilizadas a la hora de definir llegadas consecutivas de usuarios son la distribuci´on exponencial y la distribuci´on de Poisson. Entre ambas distribuciones existen caracter´ısticas que las relacionan. Sin embargo, mientras la distribuci´on exponencial es continua y, dada una media λ, contiene las probabilidades para cada tiempo entre llegadas consecutivas, la distribuci´on de Poisson, a partir de una media λ, contiene las probabilidades de que, en un tiempo determinado, lleguen kusuarios al sistema. La relaci´on ambas distribuciones indica que, si el n´umero de llegadas sigue una distribuci´on de Poisson de media λ, el tiempo entre llegadas sigue una distribuci´on exponencial de media (1/λ) y viceversa. Pese a ser las m´as conocidas o extendidas, las distribuciones que se han explicado no son, ni mucho menos, las que mejor se adaptan a todos los procesos. Es por ello que, a la hora de modelar un sistema, se debe ser conocedor de las diferentes distribuciones y como determinar, a partir del sistema real, las variables que las definen. A continuaci´on se enumeran otras conocidas distribuciones estad´ısticas, continuas (´utiles para representar tiempo) o discretas (´utiles para representar n´umero de usuarios): Continuas Continua uniforme. Erlang. Normal. Discretas Uniforme discreta. Bernoulli. Binomial. 10 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Las llegadas consecutivas de usuarios pueden ser individuales o en lotes. Esto supone que el patr´on de llegadas debe contener informaci´on estad´ıstica sobre la probabilidad de que los usuarios lleguen al sistema en grupo (y dimensiones del grupo) o solos. Por ´ultimo, se debe definir si el patr´on de llegadas es estacionario (si se mantiene constante) o no-estacionario (si varia a lo largo del tiempo). Es muy habitual que el patr´on de llegadas sea no-estacionario. Ocurre, por ejemplo, en un bar-restaurante donde, en horas de comida, el n´umero de clientes que llega aumenta respecto al resto del d´ıa. Igualmente ocurre momentos antes del inicio de cada pel´ıcula en las taquillas de un cine o en horas de cierre de oficinas en los peajes de las salidas de Barcelona. 3.2.2. Patr´on de servicio de las ventanas El tiempo de atenci´on en una ventana no es, tampoco, una constante. Puede seguir una distribuci´on de probabilidad concreta para cada tipo de usuario y servicio o incluso para cada ventana de atenci´on. Adem´as, el patr´on de tiempo de atenci´on puede ser estacionario y noestacionario e incluso depender de otras variables. Ejemplos de estas variables pueden ser el n´umero de personas en la cola, la hora del d´ıa o las horas acumuladas de trabajo de las personas que trabajan en las ventanas. De modo que el rendimiento de las ventanas a la hora de dar el servicio puede ser dependiente. Es importante en muchas ocasiones tener en cuenta un tiempo muerto entre servicios. En cualquier sistema, hay un tiempo en el que el usuario est´a recibiendo el servicio y, una vez finalizado el servicio y el usuario abandona la ventana, transcurre un tiempo hasta que el siguiente usuario, que estaba esperando en la cola, comienza a recibir su servicio. A esto se le llama tiempo muerto y, puede ser m´as o menos amplio en funci´on del motivo que lo origine. Por ejemplo, el tiempo muerto ser´a bajo si simplemente contempla el cambio entre un usuario y otro. Sin embargo, puede ser elevado si la ventana de servicio ha de ser acondicionada entre servicio y servicio (como puede ser el caso de un consultorio m´edico o una sala de dar masajes). Distribuci´on Normal Ya se han mencionado con anterioridad algunas de las m´as conocidas distribuciones de probabilidad. Adem´as, se han explicado brevemente la distribuci´on exponencial y de Poisson, v´alidas tambi´en para definir el tiempo de atenci´on en una ventana de servicio. Por su utilidad a la hora de definir el tiempo de atenci´on, en este apartado se har´a una introducci´on a la distribuci´on Normal. La distribuci´on Normal, tambi´en conocida como distribuci´on de Gauss, depende de dos par´ame- Herramienta de simulaci´on de colas para dimensionar puntos de servicio 11 tros estad´ısticos; µyσ2que corresponden respectivamente a la media y a la varianza (el cuadrado de la desviaci´on est´andar) de su funci´on de probabilidad. Esta funci´on tiene como peculiaridad el ser de forma acampanada y sim´etrica, centrada en el par´ametro µ. Figura 3.1: Ejemplo de funci´on de densidad de una distribuci´on Normal. Fuente: Wikipedia. 3.2.3. Disciplina de cola La disciplina de la cola hace referencia a la forma en que los usuarios se ordenan en la cola para ser atendidos. La m´as conocida y extendida es la disciplina FIFO, del ingl´es First in, First out, donde el orden se establece a medida que llegan los usuarios. As´ı, el que llega antes tiene prioridad ante el que llega m´as tarde. Existe tambi´en la disciplina de cola opuesta, donde el ´ultimo en llegar es el primero en ser atendido. Se trata de la disciplina LIFO, del ingl´es Last in, First out. Puede haber disciplinas de cola en las que existe otro tipo de prioridad de atenci´on. Por ejemplo, colas en que los clientes del tipo A son prioritarios respecto a los del tipo B. Entonces se distingue entre dos tipos; preemptive, si al llegar el usuario prioritario es atendido inmediatamente sin importar si alg´un otro usuario est´a utilizando la ventana de servicio en esos momentos o, no-preemptive si, pese a ponerse delante en la cola, el usuario prioritario debe esperar a que se libere la ventana para ser atendido. Se puede hablar en esta secci´on del comportamiento de los usuarios frente a la cola. Las decisiones que puede tomar un usuario que no est´a dispuesto a esperar un largo tiempo a ser atendido pueden ser muy impredecibles y, son situaciones complejas de modelar. Existe la posibilidad de que el usuario, al llegar y ver una cola larga o prever que el tiempo de espera va ser grande, abandone directamente el sistema. Tambi´en es posible que lo haga una vez ya ha esperado un tiempo determinado en el sistema o que incluso llegado ese tiempo, decida cambiar de cola. Estas situaciones se pueden modelar simplificando el comportamiento de los usuarios y limitando la capacidad del sistema. 12 Herramienta de simulaci´on de colas para dimensionar puntos de servicio 3.2.4. Capacidad del sistema Se le llama capacidad del sistema a la cantidad m´axima de usuarios que pueden estar esperando en las colas del sistema. En el caso de que exista tal limitaci´on, se trata de un problema de colas finitas. Se ha comentado en el apartado anterior que son muy comunes a la hora de simplificar el hecho de que usuarios decidan esperar una cola o marcharse de ella. El otro caso es el de problemas de colas infinitas. En estos, la capacidad del sistema es ilimitada y, por lo tanto, la cantidad de usuarios esperando a ser atendidos no est´a acotada por ning´un valor. 3.2.5. N´umero de puntos de servicio por ventana o servidores en paralelo Para acceder a un tipo servicio se puede establecer una cola por cada punto de servicio o, se puede establecer una sola cola que alimente a una serie de servidores en paralelo. V´ease en la Figura 3.2 los dos tipos de formaciones de cola; monocanal y multicanal. Figura 3.2: Esquema de cola monocanal y multicanal. Extra´ıda de [2]. Para ejemplificar el caso de una formaci´on de cola monocanal, imag´ınese una serie de cajas de atenci´on de una gran tienda de ropa. Existe una ´unica cola y, cuando una caja queda libre, se avisa al primer cliente de la cola que ha de ir a la caja liberada. Igualmente sirve de ejemplo si los clientes obtienen un n´umero al llegar al sistema y son llamados por orden num´erico a la ventanilla que ha quedado libre. En un supermercado, sin embargo, los clientes de colocan en una cola independiente delante de la caja a la que eligen ir. 3.2.6. N´umero de etapas de servicio Por ´ultimo, el sistema de colas puede ser unietapa o multietapa. En los sistemas unietapa el usuario requiere un servicio del sistema y, tras cubrirlo, lo abandona. Por su lado, en los sistemas multietapa el usuario puede requerir m´as de un servicio en el sistema y, de ser menester, pasar por m´as de una ventana de servicio antes de abandonar el sistema. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 13 A modo de ejemplo, para comprar un bocadillo o un refresco en una feria, es muy t´ıpico primero tener que comprar el tique correspondiente en una ventana y luego ir a otra ventana a intercambiarlo por el producto. Este es un claro ejemplo de sistema multietapa. Tambi´en puede darse el caso de una combinaci´on de sistema multietapa y unietapa. Si pensamos en unos lavabos, habr´a usuarios que ´unicamente han de acceder a lavarse las manos. Sin embargo, existir´a un grupo de usuarios que ha de utilizar el servicio y despu´es lavarse las manos. 14 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Herramienta de simulaci´on de colas para dimensionar puntos de servicio 15 Cap´ıtulo 4 Herramientas para el desarrollo del programa En el presente cap´ıtulo se justificar´an las herramientas utilizadas para el desarrollo de SimuQ 1.0. A trav´es de la propia experiencia y la bibliograf´ıa consultada se justificar´an las elecciones del lenguaje de programaci´on, editor, librer´ıas utilizadas, compilador, etc. 4.1. Lenguaje de programaci´on y entorno de desarrollo Son muchos los lenguajes de programaci´on que existen actualmente. Seg´un el ´ Indice TIOBE, elaborado por una empresa holandesa especializada en evaluar la calidad de programas inform´aticos, y consultado en [5], los cinco lenguajes m´as populares a fecha de consulta son, por orden: Java, C, C++, C# y Python. El lenguaje adoptado para llevar a cabo el proyecto ha sido Python. El principal motivo es la experiencia y familiaridad que ya se ten´ıa con este lenguaje al haber trabajado en el desarrollo de anteriores programas menos complejos. Adem´as, de entre las ventajas que ofrece Python, se destacan para el desarrollo del proyecto la gran cantidad de librer´ıas que se encuentran al alcance de cualquier usuario, la simplicidad y legibilidad que permite ser comprendido por otros usuarios, su formato multiplataforma y multiparadigma (con opci´on de crear programas para cualquier Sistema Operativo, orientando a objetos o con paradigma imperativo) y su gran vinculaci´on con el entorno cient´ıfico. Esto ´ultimo facilita el acceso a librer´ıas matem´aticas y estad´ısticas e incluso la posibilidad de llamar a lenguajes m´as espec´ıficos para la estad´ıstica, como el lenguaje R. Por ´ultimo, otra ventaja de Python es que puede ser compilado en otros lenguajes. 16 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Evidentemente no todo son ventajas. Al asumir Python como lenguaje de programaci´on, se renuncia a la potencia de, por ejemplo, lenguajes como C y C++. Sin embargo, el sacrificio de potencia no es grave al ser Python un lenguaje suficientemente r´apido para el prop´osito del proyecto. Figura 4.1: Logo de Python. Una vez escogido el lenguaje, se debe escoger el entorno de trabajo. Python es un lenguaje que puede ser escrito en cualquier editor de texto como, por ejemplo, el bloc de notas de Windows. Existen, adem´as, editores de texto m´as espec´ıficos que facilitan la escritura y lectura de c´odigo gracias a la diferenciaci´on de fuentes y colores que autom´aticamente utilizan para variables, funciones, palabras clave del lenguaje, etc. Ejemplos de estos editores de texto son Emacs y SciTE. Por otro lado, existen los Entornos de Desarrollo Integrado (IDE). Estos programas disponen de herramientas que facilitan mucho la tarea de escribir el c´odigo. Se escogi´o la IDE de Spyder por, adem´as de tener las ventajas de un editor de texto avanzado, permite ejecutar el c´odigo en un terminal, acceder a la documentaci´on de objetos y cuenta con un explorador de variables y unas herramientas muy interesantes para depurar el c´odigo. Adem´as, es muy f´acil de instalar y tiene una interfaz amigable que resalta errores y advertencias a tiempo en el que se escribe el c´odigo del programa. Figura 4.2: Logo de Spyder. 4.2. M´odulos y librer´ıas A la hora de desarrollar un programa Python se definen clases y funciones que desempe˜nan, en conjunto, la funci´on del programa. En muchos casos existen m´odulos o librer´ıas que ya Herramienta de simulaci´on de colas para dimensionar puntos de servicio 23 Diferencias entre simulaci´on intensiva y gr´afica Por lo que a ventanas de servicio se refiere, existen algunas diferencias entre la opci´on de simulaci´on intensiva y la opci´on gr´afica. Cuando se escoge la simulaci´on intensiva, se pueden definir tantas ventanas de servicio como se quiera y, cada una de ellas, puede atender hasta 10000 usuarios en paralelo. Sin embargo, para evitar colapsos en la interfaz en el momento de mostrar sistemas muy complejos, se opt´o por limitar la cantidad de ventanas a cinco y, a dos, el n´umero de atenciones en paralelo de cada una. De esta manera, SimuQ 1.0 puede gestionar y mostrar durante la simulaci´on gr´afica un m´aximo de diez puntos de servicio y cinco colas. 5.1.3. Usuarios, definici´on de las llegadas Al Validar y guardar las ventanas creadas en la fase anterior, el programa desbloquea las casillas necesarias de la siguiente fase, la definici´on de llegadas de usuarios. Esto quiere decir que, aunque se hayan definido en la primera fase tres tipos de usuario y tres tipos de servicio, si ´unicamente se ha creado una ventana que da servicio A a usuarios tipo P; solamente se podr´an definir la llegada de usuarios P que requieran servicio A. De esta manera se evita que se generen usuarios que no pueden ser atendidos en el sistema. Patr´on de llegadas En esta fase pues, toca definir el patr´on de llegadas de usuarios. SimuQ 1.0 ofrece una ´unica forma de hacerlo. El tiempo entre llegadas consecutivas de usuarios se define con el par´ametro estad´ıstico λ, media de una distribuci´on exponencial. Antes de continuar, cabe resaltar que si se trata de una simulaci´on gr´afica, el par´ametro λse ha de dar en segundos. Esto es debido a que las funciones internas de simulaci´on a tiempo real trabajan con segundos. Por ser las distribuciones exponencial y de Poisson las m´as utilizadas para modelar patrones de llegadas a un sistema y, siendo estad´ısticamente equivalentes si se relacionan correctamente sus medias, se opt´o por implementar ´unicamente la distribuci´on exponencial. Incluir otras distribuciones podr´ıa ser tambi´en el m´ovil de mejoras de SimuQ. Ya se ha insistido con anterioridad en el af´an por la simpleza e intuitividad de la GUI. Es por ello que se opt´o por definir el patr´on de llegadas mediante un ´unico par´ametro λque defina el tiempo de llegada de un nuevo usuario al sistema (y no un par´ametro para cada tipo de usuario). La forma de introducir datos acerca de la probabilidad de que el usuario sea de un tipo u otro o el servicio que requiere, es a trav´es de porcentajes. As´ı pues, se deber´an definir los porcentajes de probabilidad de que el usuario sea de cada tipo. Luego, a cada tipo de usuario le corresponden porcentajes acerca de la probabilidad de requerir un servicio u otro. V´ease la 24 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Figura 5.2. El esquema completo corresponde al de simulaci´on intensiva, mientras que los recuadros mostrados en verde corresponden a la parte del esquema que coincide con la definici´on del patr´on en simulaci´on gr´afica. En el mismo esquema, el grupo de porcentajes de tipos de usuario (en azul) deber´a sumar 100 %. Igualmente, cada uno de los grupos de porcentajes p´urpuras, si el porcentaje de tipo de usuario correspondiente es diferente de cero, deber´a sumar tambi´en 100 %. En caso de no ser as´ı, tras hacer clic en el bot´on de Validar y guardar aparecer´a una ventana emergente indicando el error. Figura 5.2: Esquema de definici´on de patr´on de llegada de usuarios con SimuQ 1.0. El patr´on de llegadas queda definido casi totalmente en SimuQ 1.0 con lo expuesto anteriormente. Se vio en la secci´on 3.2.1, que el patr´on de llegadas puede ser estacionario o no estacionario y puede contemplar llegadas de usuarios individuales o en grupo. Respecto a las llegadas individuales o en grupo, el programa desarrollado en este proyecto asume que los par´ametros introducidos hacen referencia a llegadas individuales. Bien es cierto que estad´ısticamente pueden existir llegadas casi simult´aneas al sistema, pero SimuQ 1.0 no contempla la opci´on de definirlas como tal. Sin embargo, en la siguiente y ´ultima fase de definici´on del sistema, el programa ofrece la opci´on de asignar per´ıodos de llegadas a usuarios. Se ver´a m´as adelante, pues, que se puede definir un patr´on de llegadas no estacionario con periodicidad. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 25 N´umero de etapas de servicio En el apartado 3.2.6 se vio que un sistema puede ser unietapa o multietapa. SimuQ 1.0, en la opci´on de simulaci´on intensiva, permite definir un sistema al que llegan usuarios que requieren uno o dos servicios. En el esquema de la Figura 5.2 se ve como a cada tipo de usuario-servicio se le puede a˜nadir un porcentaje correspondiente a la probabilidad de que un usuario de esas caracter´ısticas, tras el servicio 1, requiera el servicio 2 (que se define con un comboBox al lado del porcentaje). Esta opci´on ampl´ıa mucho el abanico de tipos de sistemas definibles con el programa. A pesar de ello, una pr´oxima mejora podr´ıa ser a˜nadir la posibilidad de contemplar m´as de dos etapas (dos servicios) y la posibilidad de definir diferentes segundos servicios para un mismo tipo de usuario y servicio. 5.1.4. Configuraci´on de la simulaci´on En la ´ultima fase de definici´on del sistema, antes de poder ejecutar la simulaci´on, se introducen los par´ametros que gobiernan el tiempo de atenci´on en las ventanas de servicio, los per´ıodos de llegada de usuarios y el tiempo total que se desea ejecutar la simulaci´on. Patr´on de servicio de las ventanas En SimuQ 1.0, el patr´on de servicio de las ventanas, visto en el apartado 3.2.2, se define en su totalidad a partir de los par´ametros estad´ısticos de las distribuciones normales (µ, σ2) que gobiernan los tiempos de atenci´on y tiempos muertos entre servicios para cada pareja serviciousuario. Al Validar y guardar los cambios tras crear las ventanas en la fase dos, SimuQ 1.0 determina cuales son las posibles parejas usuario-servicio que se pueden dar durante la simulaci´on en funci´on de las ventanas creadas y, en esta ´ultima fase, pide que se introduzcan todos los par´ametros para definir los tiempos de atenci´on. La definici´on de los tiempos muertos es opcional para cada pareja usuario-servicio. El tiempo de simulaci´on y los tiempos de per´ıodos de llegada de usuarios que se definir´an a continuaci´on, han de concordar en unidades temporales todos ellos con el par´ametro λdefinido en la fase dos (Ventanas de servicio). En la opci´on de simulaci´on gr´afica, no solamente han de concordar, sino que todos ellos deben estar expresados en segundos (s). SimuQ 1.0 admite solamente la opci´on de definir un patr´on de servicio estacionario a partir de par´ametros de distribuciones normales. Sin embargo, pueden existir patrones no estacionarios, 26 Herramienta de simulaci´on de colas para dimensionar puntos de servicio dependientes de variables externas o incluso ser estacionarios y depender de otras distribuciones de probabilidad. Pese a que, como ya se ha comentado en anteriores ocasiones, se han escogido los casos m´as generales y comunes para desarrollar la primera versi´on del programa, el a˜nadir cualquier funci´on adicional que admita la definici´on de otros patrones de servicio ser´ıa un valor a˜nadido al programa que, por acotaciones temporales no entran dentro los objetivos de este proyecto. Per´ıodos de llegada de usuarios Por ´ultimo, a parte de introducir el tiempo que se quiere hacer durar la simulaci´on, existe la opci´on de modificar el patr´on de llegadas y hacerlo no-estacionario. Si se marca la casilla del checkBox y se introduce el per´ıodo de llegadas de forma v´alida, el patr´on de llegadas ser´a peri´odico. Tendr´a espacios de tiempo en que los usuarios llegan de forma continua siguiendo la ley exponencial y el patr´on definido en la tercera fase y, existir´an espacios de tiempo donde no llegar´an usuarios. El per´ıodo se define con la longitud temporal total del mismo y el tiempo durante el cual llegan usuarios. V´ease ejemplo en la Figura 5.3. Para que sea v´alido, la longitud total del per´ıodo ha de ser m´as peque˜na o igual que el tiempo total de simulaci´on. Igualmente el tiempo de llegadas ha de ser m´as peque˜no que el del per´ıodo entero y ambos diferentes de cero. Figura 5.3: Per´ıodos de llegadas de usuarios de 200 cada 500 con un tiempo de simulaci´on de 1800. Diferencias entre simulaci´on intensiva y gr´afica En el cierre de esta secci´on, antes de pasar a ver la ejecuci´on de la simulaci´on en SimuQ 1.0, se comentan las diferencias entre la simulaci´on intensiva y gr´afica en la ´ultima fase de definici´on. A parte de la obligatoriedad de definir todos los tiempos en segundos (s), la simulaci´on gr´afica presenta una ´ultima diferencia. Se trata de un factor de velocidad de simulaci´on. En otras palabras, se utiliza para regular la velocidad en que la simulaci´on va a ser ejecutada y mostrada en pantalla. Si el factor es unitario, cada segundo ser´a un segundo de simulaci´on. Si el factor es Herramienta de simulaci´on de colas para dimensionar puntos de servicio 27 diez, la simulaci´on correr´a diez veces m´as r´apida. 5.1.5. Funciones y variables esenciales En este apartado se har´a una s´ıntesis de las principales funciones y variables definidas en el archivo de programa con el nombre de SimuQ.py, que gobierna el funcionamiento de la GUI y el almacenamiento de los inputs 3del usuario. El archivo contiene distintas clases de Python para gestionar las diferentes ventanas de la interfaz. Las funciones de las que vamos a hablar en este apartado son comunes (con peque˜nas variaciones) en la clase Intensive Simulation yGraphical Simulation, que gobiernan la ventana de simulaci´on intensiva y gr´afica respectivamente. Se seguir´a el mismo orden de definici´on del sistema para comentar las funciones. En primer lugar, tras escribir el nombre de los tipos de usuario y servicio en la primera fase, el programa genera un diccionario de Python con la informaci´on introducida que ser´a consultado por el programa para traducir sus variables internas a variables del usuario de SimuQ 1.0. La funci´on que lo genera y completa siguientes fases de la interfaz con los nombres introducidos, es validate users services(self). Esta se ejecuta cuando se pulsa el bot´on de Validar y guardar. La segunda fase est´a gobernada por dos funciones principales. Cada vez que se hace clic en el bot´on A˜nadir, se llama a la funci´on add windows(self) que guarda la informaci´on de la ventana creada en el diccionario de Python con el nombre de windows in. Este diccionario contiene la siguiente informaci´on acerca de cada ventana: identificador de la ventana, si es o no de tipo prioritario, tipos de usuarios que atiende y servicios que ofrece y cuales de ellos son prioritarios (si los hay) y, por ´ultimo, el numero de servidores en paralelo. La otra funci´on, validate windows, gobierna acciones sobre la interfaz. Desbloquea o bloquea opciones de la GUI para continuar la definici´on del sistema de forma correcta. Una vez definido el patr´on de llegadas de usuarios en la tercera fase y hacer clic al bot´on de Validar y guardar de la GUI, la funci´on validate users(self) se encarga de guardar los datos las variables siguientes: users type in,users service in,users after service in ylamda (no es lambda por ser un nombre reservado de Python). Las ´ultimas dos funciones a comentar en esta secci´on pertenecen a la fase de definici´on del patr´on de atenci´on y configuraci´on general de la simulaci´on. La primera de ellas es la funci´on add param normal(self) que es llamada cada vez que se pulsa el bot´on A˜nadir para definir un 3Del ingl´es, cualquier entrada de informaci´on al programa. 28 Herramienta de simulaci´on de colas para dimensionar puntos de servicio tiempo de atenci´on. Esta funci´on almacena en el diccionario t atention in, para cada pareja servicio-usuario, los par´ametros estad´ısticos de la distribuci´on normal del tiempo de atenci´on y el tiempo muerto entre servicios (si se define). Por su lado, la funci´on validate configuration simulation(self), lanzada al pulsar el bot´on Validar y guardar, guarda el tiempo de simulaci´on introducido y los per´ıodos de llegadas de usuarios (en caso de estar definidos). En simulaci´on gr´afica, guarda tambi´en el factor de velocidad de simulaci´on. Adem´as, valida que todo est´e correctamente definido y, de ser as´ı, desbloquea el bot´on para iniciar la simulaci´on. 5.2. Ejecuci´on de la simulaci´on En esta secci´on se explicar´an las clases y funciones principales involucradas en la ejecuci´on y gesti´on de la simulaci´on. Adem´as se explicar´a la manera en la que se definen los elementos del sistema vistos en el apartado 3.1. Sobre todo, esta parte del texto es importante para comprender como funciona la simulaci´on y de que manera se han solventado problemas importantes; por ejemplo, el algoritmo que selecciona a que ventana decide ir el usuario que llega al sistema. Saber como funciona este algoritmo puede permitir a usuarios de SimuQ 1.0 hacer modificaciones en ´el para adaptarlo a sistemas m´as espec´ıficos. Una vez el sistema est´a completamente definido, se desbloquea el bot´on para empezar la simulaci´on. Al pulsarlo, el programa llama a la funci´on Execute Simulation(datos) que tiene como variables de entrada las definidas en el apartado 5.1.5 y que, en el texto, han sido substituidas por la variable datos. La funci´on con el mismo nombre, pero correspondiente a cada tipo de simulaci´on se encuentra en los archivos graphical simulation.py yintensive simulation.py. El programa acceder´a a una u otra en funci´on de la modalidad de simulaci´on escogida. Ambos archivos, graphical simulation.py yintensive simulation.py, importan los archivos User Class.py yWindows Class.py que contienen las clases User,Graphic User,Windows y Graphic Windows. Adem´as importan el archivo distributions.py, que contiene funciones para generar variables aleatorias de distintas distribuciones estad´ısticas. 5.2.1. Elementos del sistema En este apartado se plantea la forma en la que se implementan los diferentes elementos te´oricos del sistema en la simulaci´on. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 29 Entorno de simulaci´on Para gestionar los eventos de la simulaci´on, SimPy necesita crear el entorno que contendr´a los elementos del sistema gestionados por el m´odulo. SimPy ofrece la posibilidad de crear dos tipos de entornos diferentes. Uno de ellos, utilizado en la simulaci´on intensiva, ejecuta la simulaci´on a la velocidad de computaci´on del ordenador. El otro, utilizado en la simulaci´on gr´afica, ejecuta la simulaci´on a tiempo real. Es decir, un segundo real equivale a un segundo en la simulaci´on. Pese a ejecutarse en tiempo real, este entorno permite acelerar la velocidad de simulaci´on mediante un factor que se introduce como variable al instanciarse el entorno. Figura 5.4: C´odigo para crear el entorno de simulaci´on con SimPy. Extra´ıdo de intensive simulation.py. Usuarios Los usuarios del sistema no son elementos que puedan crearse en forma de objetos de alguna clase de SimPy. Por este motivo se han definido las clases User yGraphic User. La clase User es utilizada en ambos modos de simulaci´on. Los usuarios, objetos de la clase, tienen por atributos el identificador con el n´umero de usuario y el tipo, el servicio o servicios que requiere. Adem´as, durante la simulaci´on, se definen atributos de cada usuario como el tiempo de llegada, tiempo de espera y ventana de atenci´on. De esta manera se almacenan datos de la simulaci´on en cada usuario. Al iniciar cualquier simulaci´on se crea un diccionario Python llamado Users que contiene todos los usuarios que van llegando al sistema, de modo que quedan accesibles en cualquier momento que se requiera. Por su lado, la clase Graphic User que hereda de la clase pygame.sprite.Sprite se utiliza ´unicamente en la simulaci´on gr´afica para gestionar la representaci´on en pantalla. Al heredar de la clase pygame.sprite.Sprite, permite tener asociado el usuario a una imagen y asignarle una posici´on en la pantalla. Adem´as permite crear grupos de sprites. Se trabaja de forma que las colas de usuarios frente a las ventanas de servicio sean grupos de sprites, muy ´utiles para ser modificados o representados en bloque. 30 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Ventanas de servicio Para la gesti´on de ventanas de servicio se ha definido la clase Windows que hereda de la clase simpy.resources.resource.PriorityResource. Las ventanas del sistema, objetos de la clase Windows tienen, adem´as de los atributos y funciones de la clase de SimPy, otros atributos como el identificador (n´umero de ventana), tipo de usuario que atiende y tipo de servicio que ofrece, prioridades de atenci´on y otros atributos como listas que permiten almacenar informaci´on durante la simulaci´on. Al inicio de cada simulaci´on se crea un diccionario de Python que contiene todas las ventanas (objetos de la clase Windows) del sistema. La clase Windows tiene definidos los m´etodos param yparam B a los que se dedicar´a un apartado m´as adelante por su importancia en el c´odigo. Una de las ventajas de heredar de la clase de SimPy para PriorityResources es que la gesti´on de los eventos de salida y entrada de usuarios a la ventana est´a implementada en la clase mediante iteradores de Python. Adem´as, ofrece la posibilidad de poner a la cola eventos con mayor o menor prioridad. En la Figura 5.5 se muestra el c´odigo para poner a la cola (o no, si la ventana est´a libre) un evento de petici´on de ventana con prioridad. Cuando se libera la ventana y se lanza este evento (por ser el siguiente en la cola), el c´odigo contin´ua ejecutando lo que siga a los puntos suspensivos. Figura 5.5: C´odigo de ejemplo para lanzar un evento de petici´on de una ventana de servicio (windows) con prioridad prio. Pese a ser elementos est´aticos durante la simulaci´on, tambi´en se ha definido una clase Graphic Windows que hereda de la clase pygame.sprite.Sprite. Esta clase, igual que la clase Graphic User se utiliza durante la simulaci´on gr´afica para gestionar la representaci´on del grupo de ventanas en pantalla. Colas La gesti´on de colas en SimuQ 1.0, en realidad, no se lleva a cabo creando objetos cola de cada unas de ventanas de servicio. El caso es que los atributos y m´etodos de la clase Windows permiten acceder a listas de usuarios en la cola de la ventana, capacidad y usuarios utilizando Herramienta de simulaci´on de colas para dimensionar puntos de servicio 31 el recurso al mismo tiempo. Mediante estos atributos y m´etodos se lleva a cabo la gesti´on de las colas. Reloj El reloj de cualquier simulaci´on en SimuQ 1.0 se inicializa en cero y finaliza en el valor de la variable simulation time. Durante la simulaci´on, el reloj avanza (se actualiza) con la l´ınea de c´odigo de la Figura 5.6. Este m´etodo de la clase simpy.Environment nos permite avanzar el tiempo del reloj el valor que se introduce como variable entre par´entesis. Figura 5.6: Expresi´on para poner a la cola un evento de avanzar el reloj un tiempo de (t atention A+dead time A). C´odigo extra´ıdo de intensive simulation.py. 5.2.2. Funciones y m´etodos principales Vista la manera en que SimuQ 1.0 implementa los elementos del sistema, en este apartado se ver´an las funciones y m´etodos principales que se utilizan para gestionar los estados de estos elementos durante el proceso de simulaci´on. Execute Simulation Ya se ha mencionado con anterioridad la funci´on Execute Simulation(datos). Es la que recibe todos los datos recogidos por la GUI y gobierna la preparaci´on e inicio de la simulaci´on. Cuando se llama a la funci´on Execute Simulation(datos) se inician procesos de generaci´on del entorno, se crean las ventanas de servicio, se definen las subfunciones simulation, choose windows yuser generator y se crean diccionarios y variables que se usar´an durante la simulaci´on. Funci´on user generator(env, lamda) El primer proceso que Execute Simulation(datos) lanza es la llamada a la subfunci´on user generator(env, lamda). Esta es una funci´on que contiene un bucle infinito y que, por lo tanto, por ella sola no parar´ıa de ejecutarse. Sin embargo, las l´ıneas de c´odigo de la Figura 5.7 que lanzan la funci´on como un proceso del entorno de SimPy, permiten ejecutar el proceso hasta que el reloj interno de la simulaci´on alcance el valor de simulation time. Una vez lanzada por primera vez, user generator(env, lamda) genera tiempos de llegadas de usuarios (a trav´es de las funciones de distributions.py ylamda) y, si se encuentran dentro de 32 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Figura 5.7: C´odigo para lanzar la simulaci´on mediante la funci´on user generator. Extra´ıdo de intensive simulation.py. per´ıodos de llegada de usuarios, genera objetos de la clase User yGraphic User(si la simulaci´on se muestra por pantalla), actualiza el reloj interno con cada llegada, registra informaci´on del nuevo usuario y llama a la funci´on simulation(user) osimulation(user, graphic user ), seg´un proceda, para continuar la simulaci´on. Funciones simulation(user) y simulation(user, graphic user) El esquema b´asico de ambas funciones es exactamente el mismo. La ´unica diferencia es que, la funci´on usada para la simulaci´on gr´afica requiere el objeto de la clase Graphic User para mostrar el usuario en la pantalla. Las dos funciones reciben al objeto de la clase User y lanzan el algoritmo que determina a que ventana decidir´a ir el usuario (funci´on choose window(user)). Una vez determinado, ejecutan el request de la Figura 5.5 para colocar al usuario en la cola de la ventana seleccionada. Por ´ultimo gestionan la actualizaci´on del reloj de simulaci´on una vez el usuario ha salido de la ventana y gestionan el almacenamiento de datos de la simulaci´on. Funci´on choose window(user) Esta funci´on retorna, dado un usuario, la ventana en la que se pondr´a a esperar la cola para ser atendido. Existen situaciones en las que es evidente el comportamiento que tendr´a el usuario. Por ejemplo, si hay dos ventanas que pueden dar servicio en igualdad de condiciones y, en una de ellas hay cola y en la otra no, el usuario ir´a directamente a la ventana en la que no ha de esperar. Sin embargo, existen muchas otras situaciones en las que la decisi´on del usuario es m´as compleja y tiene en cuenta muchos factores. Por este motivo es importante explicar la manera en que SimuQ 1.0 toma dicha decisi´on. De esta manera se podr´a comprender la simulaci´on que se ejecute y, en caso de ser menester, se podr´ıa modificar el c´odigo para adaptar las decisiones a sistemas espec´ıficos. Se explicar´a esta parte del c´odigo ´unicamente para la funci´on que pertenece a intensive simulation.py. La perteneciente a graphical simulation.py tiene la misma estructura pero con un desarrollo m´as simple. Por este motivo, basta con entender la m´as compleja, para saber Herramienta de simulaci´on de colas para dimensionar puntos de servicio 39 Figura 5.13: Ejemplo de gr´afico interactivo de evoluci´on temporal de colas. Graficar Boxplot de los tiempos de espera La segunda opci´on muestra otra ventana emergente con gr´aficos. En este caso los gr´aficos son de tipo boxplot en los que se muestran los tiempos de espera de todos los usuarios del sistema. Por un lado se muestra un boxplot de los tiempos de espera generales (de todo el sistema) y, por otro lado, se muestra un boxplot para cada ventana de servicio. Extraer documento de texto con datos El documento de texto con datos es un resumen de algunos datos estad´ısticos post-simulaci´on. Se detalla el n´umero de usuarios que han llegado al sistema y los que han sido atendidos durante el tiempo de simulaci´on, en total y por cada ventana. Adem´as, se muestra informaci´on de los tiempos de espera como el m´aximo, el medio y el percentil del 95 %. Extraer documento de simulaci´on La ´ultima opci´on muestra un texto en el que se han escrito de forma ordenada cronol´ogicamente los eventos que han cambiado el estado del sistema. Llegadas y salidas de usuarios as´ı como informaci´on acerca del tiempo de llegada, de atenci´on, ventana de servicio, etc. Se utilicen o no las opciones de visualizaci´on de datos de la interfaz de SimuQ 1.0, el programa guarda en la carpeta los dos documentos de texto descritos anteriormente; el de datos y el de la simulaci´on. Adem´as, gracias al m´odulo xlsxwriter se exportan datos a un documento Excel que se guarda en la misma carpeta, bajo el nombre de simulation excel file. Este archivo contiene datos de los usuarios; identificador, tipo, servicio, segundo servicio (si lo hay), tiempo de llegada, ventana de servicio, ventana de segundo servicio (si lo hay), tiempo de servicio y 40 Herramienta de simulaci´on de colas para dimensionar puntos de servicio tiempo de espera. Tambi´en contiene datos de cada una de las ventanas en forma de parejas tiempo-n´umero de personas en la cola. El documento Excel permite a los usuarios del programa explotar los datos seg´un sus intereses. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 41 Cap´ıtulo 6 Resultados Este cap´ıtulo puede servir de s´ıntesis del capitulo anterior por mostrarse los resultados tras el desarrollo del programa. Cabe pues, hacer una valoraci´on de los resultados obtenidos en base al alcance de los objetivos planteados al inicio del proyecto. Adem´as, esta secci´on se valdr´a de herramientas gr´aficas como diagramas de flujo para representar el esquema del funcionamiento del programa final y un ´arbol de fallos para sintetizar las fuentes que pueden hacer que el programa presente errores. 6.1. Alcance de objetivos Llegados al punto en que se han cerrado, para este proyecto, las l´ıneas de desarrollo de SimuQ 1.0, si se valora el alcance de objetivos, el resultado es muy positivo. Se ha conseguido desarrollar un programa que, pese a presentar limitaciones de dise˜no m´as o menos significativas, puede resolver simulaciones de una gran cantidad de sistemas de colas. Gracias a la versatilidad que se ha dado al programa en todas las funciones de definici´on implementadas, se consigue poder definir sistemas tan diversos como; un sistema de peajes, unos lavabos p´ublicos, las taquillas de un cine, un aparcamiento de coches y motos, una gasolinera, etc. (se pueden consultar ejemplos resueltos con SimuQ 1.0 en el Ap´endice B). Como se ha dicho, existen limitaciones de dise˜no que impiden, por ejemplo, limitar la capacidad de las colas o del sistema, definir patrones de llegada o de atenci´on de usuarios que sigan distribuciones diferentes a la exponencial y normal o definir sistemas multietapa con m´as de dos etapas. Sin embargo, gracias al haber escrito y comentado el c´odigo del programa en lengua inglesa, se da accesibilidad a m´as usuarios que requieran, por motivos individuales o para mejorar el programa, entender y modificar o extender partes del c´odigo e implementar nuevas 42 Herramienta de simulaci´on de colas para dimensionar puntos de servicio caracter´ısticas. Las herramientas que ofrece SimuQ 1.0 para visualizar los datos permiten tomar decisiones sencillas, como por ejemplo descartar un sistema en que el gr´afico de colas en funci´on del tiempo contenga ventanas donde la curva es mon´otonamente creciente. Para tomar decisiones m´as complejas sobre el dimensionamiento, se pueden extraer datos del archivo de Excel que el programa crea al final de cada simulaci´on. Por ´ultimo, se ha logrado cumplir con el objetivo de poder mostrar la ejecuci´on de una simulaci´on por pantalla y controlar la velocidad del proceso. Pese a ser menos potente que la intensiva, esta opci´on tambi´en es bastante vers´atil y permite igualmente visualizar y extraer datos de simulaci´on. 6.2. Diagramas de flujo En esta secci´on se presentan los diagramas de flujo del programa-resultado del proyecto; SimuQ 1.0. Se muestran los diagramas de flujo del funcionamiento de la interfaz, en Figura 6.1 y del proceso de simulaci´on, representativo tanto de la opci´on intensiva como gr´afica, en Figura 6.2. 6.3. Relaci´on de errores SimuQ 1.0 como cualquier proceso inform´atico y m´as, siendo una primera versi´on, puede presentar errores o fallos de ejecuci´on. En el ´arbol de fallos de la Figura 6.3 se muestran todas las acciones conocidas que acaban haciendo fallar al programa de un modo u otro. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 43 Figura 6.1: Diagrama de flujo de la interfaz de SimuQ 1.0. 44 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Figura 6.2: Diagrama de flujo del proceso de simulaci´on intensiva de SimuQ 1.0. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 45 Figura 6.3: ´ Arbol de fallos de SimuQ 1.0. 46 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Herramienta de simulaci´on de colas para dimensionar puntos de servicio 47 Cap´ıtulo 7 Planificaci´on temporal y costes Este cap´ıtulo se dedica a presentar, mediante un gr´afico de Gantt (ver Figura 7.1), las fases que se han seguido para desarrollar el proyecto y como se han dividido temporalmente en los casi siete meses que ha durado el trabajo. Adem´as, se har´a un c´alculo estimado de los costes que ha supuesto SimuQ 1.0. Figura 7.1: Diagrama de Gantt del desarrollo del proyecto. Puesto que para el desarrollo de SimuQ 1.0 y la memoria no se ha requerido ninguna herramienta de pago y ya se dispon´ıa del hardware, los costes del proyecto se calcular´an a partir de las horas que se han empleado para llevarlo a cabo. 48 Herramienta de simulaci´on de colas para dimensionar puntos de servicio Para hacer el c´alculo de las horas, se ha tenido en cuenta una media de dos horas diarias durante los d´ıas laborales de los siete meses. El precio de la hora para un graduado en ingenier´ıa industrial se ha estimado en 35 e. 2h·5 d´ıas ·4 semanas ·7 meses = 280h 280h ·35e= 9800 e El c´alculo del coste se puede redondear sin problemas a 10000esi se tienen en cuenta las horas que el tutor ha empleado en la gu´ıa y supervisi´on del trabajo y otros gastos derivados de desplazamientos y material de oficina. Herramienta de simulaci´on de colas para dimensionar puntos de servicio 55 Bibliograf´ıa complementaria [1] Cao, Ricardo. 2002. Introducci´on a la simulaci´on y a la teor´ıa de colas. A Coru˜na, NETBIBLO, S.L. 224p. [2] Jorba, A. yMasdemont, J. 1995. Introducci´o a la simulaci´o. Barcelona, Edicions UPC. 198p. P´ags. 1-65 [3] Matplotlib development team, 18 de junio de 2016 Documentaci´on del m´odulo Matplotlib. (Disponible en: http://matplotlib.org/. Consultado en 2016) [4] Pygame Community, Agosoto 2009 Documentaci´on del m´odulo Pygame. (Disponible en: http://www.pygame.org/docs//. Consultado en 2016) [5] 1994-2016 SmartDraw, LLC, 2016. Programa e informaci´on sobre el diagrama de flujo. (Disponible en: https://www.smartdraw.com/flowchart/. Consultado el 18 de agosto de 2016)