6.

- Verificacin y Validacin

Una de las tareas ms importantes y difciles en la simulacin es la verificacin y validacin del modelo. Las salidas del modelo se van a utilizar para obtener conclusiones para el sistema real, por lo que es muy importante que se confe en el modelo para garantizar que ste va a ser utilizado, y esto va a ser trabajo de las personas que desarrollan el modelo.

6.1.- Introduccin
Dado que el modelo es una abstraccin del sistema real debemos preguntarnos si existe una correspondencia entre el sistema real y el modelo. Los trminos ms usados para describir el proceso mediante el cual el modelo es una representacin creble del sistema real son verificacin y validacin del modelo. La verificacin se refiere a la construccin correcta de un modelo. Se puede definir verificacin como el proceso de determinar si la lgica operacional del modelo (programa de ordenador) se corresponde con la lgica del diseo. En trminos ms simples, consiste en determinar si hay errores en el programa. La validacin se refiere a la construccin de un modelo correcto. La validacin es el proceso de determinar si el modelo, como abstraccin, es una buena representacin del sistema. Usualmente la validacin se consigue a travs de la calibracin del modelo, en un proceso iterativo de comparacin del comportamiento del modelo con el del sistema y usar las diferencias entre ambos para mejorar el modelo. Este proceso se repite hasta que el modelo se considera aceptable.

Verificacin y Validacin

En este captulo vamos a describir mtodos que han sido recomendados y usados en la verificacin y validacin del modelo. La mayora de los mtodos son comparaciones subjetivas informales mientras que unos pocos son procesos estadsticos formales.

6.2.- El papel de la verificacin y la validacin

Cuando construimos un modelo de un sistema real, se atraviesan una serie de etapas o niveles de modelizacin. Se comienza estudiando el sistema real y a continuacin se construye un modelo conceptual que contiene todos los elementos que se consideran relevantes del sistema. Desde este se pasa a un modelo lgico que contiene las relaciones lgicas entre los elementos. Por ltimo se construye el modelo de ordenador (o modelo de simulacin) que ejecuta la lgica recogida en la fase anterior. El desarrollo del modelo es un proceso iterativo en el que hay sucesivos refinamientos en cada etapa. El paso entre las distintas etapas est marcado por el xito o fracaso al realizar la verificacin y la validacin en las mismas. Cuando se valida un modelo se establece que el modelo es una representacin creble del sistema real, cuando se verifica un modelo se determina si la lgica del modelo ha sido correctamente implementada. Dado que los objetivos de la verificacin y de la validacin son diferentes tambin lo son las tcnicas para realizarlos. Se han de establecer una serie de criterios que sirvan para decidir si el modelo supera o no los procesos de verificacin y validacin. Se ha de tener presente que en un modelo se pueden excluir aspectos del sistema real que se cree que no son importantes para responder a las cuestiones planteadas sobre el sistema y que el modelo debe responder, de forma que en fases tempranas se ha de fijar tambin cules son dichas cuestiones. Por ejemplo considerando que se quiere simular un supermercado, se ha de identificar cules son las cuestiones que se espera que responda el modelo. El administrador y los usuarios del sistema nos pueden ayudar a identificarlas. Podemos suponer que despus de consultar con el administrador y los usuarios del supermercado, posibles cuestiones pueden ser: Cul es la relacin entre el nmero de cajeros y empaquetadores con respecto al tiempo de espera en cola? Qu efecto produce la existencia o no de cajas rpidas con respecto al tiempo de espera en cola? Qu efecto produce con respecto al tiempo de espera en cola el hecho de que ms de un cajero comparta empaquetador? Cul puede ser el efecto de hacer que los cajeros puedan abrir o cerrar las cajas segn la cola de espera aumente o disminuya?

94

Verificacin y Validacin

Para construir el modelo conceptual se necesita identificar aquellos elementos del sistema real que van a ser incluidos en el modelo, as como los sucesos que ocurren. En esta etapa se deben identificar las variables exgenas y endgenas, sucesos externos, variables de estado y medidas de ejecucin. Despus de identificar dichos elementos se han de presentar a los usuarios y administradores del sistema para establecer que el modelo contiene los aspectos necesarios del sistema para responder a las cuestiones planteadas. Vemos que la validacin comienza desde la primera etapa de desarrollo del modelo. Una vez que se tiene el modelo conceptual se pasa a desarrollar el modelo lgico, el cual incorpora los elementos, sucesos y variables incluidas en el modelo anterior. Puede ocurrir que durante esta etapa se descubran fallos en el modelo conceptual, lo cual implicara una nueva revisin del modelo. El proceso de comprar el modelo lgico con modelo conceptual implica validacin y verificacin. El modelo lgico debe ser una representacin adecuada de la lgica del modelo conceptual. Una vez que el modelo ha sido programado, se ha de verificar que como tal programa no contiene errores y que es una correcta representacin del modelo lgico. Para terminar se ha de validar el modelo comprobando que es una correcta representacin del sistema real y por tanto puede responder de forma fiable a las cuestiones planteadas en la fase de construccin del modelo conceptual. No existen un mtodo o un conjunto de tcnicas para verificar y validar el modelo de simulacin y el proceso es ms un arte que una ciencia. En la Tabla 6.1 podemos resumir el papel que la verificacin y la validacin desempean en la simulacin.
Nivel de Modelizacin Modelo Conceptual Verificacin Validacin Contiene el modelo todos los elementos, sucesos, y relaciones relevantes? Podr el modelo responder a las cuestiones planteadas? Incluye el modelo todos los elementos considerados en el modelo conceptual? Contiene todas las relaciones del modelo conceptual? Es el modelo una representacin vlida del sistema real? Puede el modelo duplicar el comportamiento del sistema real? Es creble el modelo para los expertos del sistema?

Modelo Lgico

Modelo de ordenador/Modelo de Simulacin

Estn los eventos representados correctamente? Son las frmulas matemticas y las relaciones correctas? Estn las medidas estadsticas formuladas correctamente? Contiene el cdigo todos los aspectos del modelo lgico? Estn las estadsticas y las frmulas calculadas correctamente? Contiene el modelo errores de codificacin?

Tabla 6.1. Verificacin y Validacin en los diferentes niveles de modelizacin.

95

Verificacin y Validacin

A continuacin pasamos a ver aproximaciones y mtodos tiles en el proceso de establecer que el modelo de simulacin es una representacin creble del sistema real.

6.3.- Validacin del modelo conceptual

El primer paso en la construccin de un modelo de simulacin es la formulacin del modelo conceptual. sta es la base en el proceso de desarrollo, por lo que se ha de realizar de forma cuidadosa. La validacin del modelo conceptual consiste en establecer si con la abstraccin que hemos realizado sobre el sistema real, se podr responder a las cuestiones planteadas. Se puede ver como el proceso en el cual el analista de la simulacin, las personas que tienen que tomar las decisiones sobre el sistema y el administrador del sistema, se ponen de acuerdo sobre qu aspectos del sistema real deben ser incluidos en el modelo, y qu informacin debe dar el modelo como salida. Dado que no hay un mtodo estndar para la validacin del modelo conceptual, se va a presentar una serie de aproximaciones que son tiles para establecer si los aspectos del sistema real, recogidos en el modelo conceptual son los importantes para el propsito de la simulacin.

6.3.1.- Representacin de los sucesos del sistema

El grafo de sucesos es un mtodo que sirve para describir de forma grfica los sucesos y los elementos de un sistema de eventos discretos. Dicha representacin tambin puede resultar til para la validacin del modelo conceptual. En dicha representacin en forma de grafo, como se vio en el captulo 1, los nodos representan los sucesos y los arcos las conexiones entre sucesos. Dichos arcos pueden ser de dos tipos indicando si la ocurrencia del suceso es incondicional o est condicionada al cumplimiento de ciertos aspectos. Se pueden utilizar los siguientes smbolos para construir el grafo:

Suceso i

Conexin Incondicional
Conexin Condicional

Retomando el problema del supermercado, podemos modelar conceptualmente el sistema como una iteracin de sucesos:

96

Verificacin y Validacin

Sucesos 1. Llegada del Cliente.

2. Cliente selecciona caja. 3. Cajero empieza.

4. Cajero termina. 5. Empaquetador empieza. 6. Empaquetador termina. 7. Salida del Cliente. ~ =Enlace condicional.

Figura 6.1. Representacin mediante el grafo de sucesos

La representacin grfica puede ser til como un puente entre el modelo conceptual y el modelo lgico y adems puede servir como una poderosa herramienta de ayuda a la comunicacin entre analistas y las personas que tratan el sistema. De forma similar al grafo de sucesos se puede utilizar el diagrama de flujo del modelo, que representa el flujo de entidades a travs del sistema (segn la aproximacin elegida en el desarrollo del modelo).

6.3.2.- Identificacin explcita de los elementos que han de estar en el modelo

En la mayora de los casos, el modelo no puede contener cada detalle del sistema real, pero s debe incluir aquellos elementos que sean relevantes para responder a las cuestiones planteadas. Debemos identificar todos los sucesos, facilidades, equipamiento, reglas de operacin, variables de estado, variables de decisin y medidas de ejecucin que van a formar parte del modelo de simulacin. Existen tres filosofas para decidir qu elementos del sistema real incluir en el modelo:

Incluir todos los aspectos del sistema real que parecen influir en su comportamiento y luego simplificar el modelo para quedarse slo aquellos elementos que son ms relevantes. Empezar con un modelo simple del sistema real e ir aadiendo complejidad a ste hasta llegar a tener elementos suficientes para responder a las cuestiones planteadas. Hacer un gasto inicial de esfuerzo y tiempo tratando de identific ar los elementos del sistema que tienen mayor importancia para responder a las cuestiones planteadas.

Antes de pasar a construir el modelo lgico se ha de estar seguro que el modelo conceptual es una buena abstraccin del sistema real. En el ejemplo del supermercado se pueden identificar los siguientes elementos, para ser incluidos en el modelo conceptual: Sucesos Llegada del Cliente. Cliente selecciona caja.

97

Verificacin y Validacin

Cajero empieza. Cajero termina. Empaquetador empieza. Empaquetador termina. Salida del Cliente. Facilidades Cajeros Empaquetadores Variables de estado Nmero de clientes en cada cola Estado de los cajeros (libre, ocupado) Estado de los empaquetadores (libre, ocupado) Medidas de ejecucin Tiempo de espera de los clientes Utilizacin de los cajeros Utilizacin de los empaquetadores Variables de decisin Nmero de cajeros Nmero de empaquetadores Nmero de cajas rpidas Nmero mximo de productos para poder utilizar una caja rpida Reglas de operacin Los clientes seleccionan siempre la caja que tenga menos clientes en cola No existen movimientos de clientes de una cola a otra Aspectos del sistema real que no se han incluido Desplazamientos de los clientes de una cola a otra Qu ocurre cuando no se cumple las reglas de las cajas rpidas Picos en las llegadas de los clientes Fallos en los equipos Absentismo de los cajeros o de los empaquetadores

6.4.- Verificacin y validacin del modelo lgico

El modelo lgico (diagrama de flujo) sirve como puente entre el modelo conceptual y el modelo de ordenador. Si el model o conceptual se ha construido bien, la verificacin del modelo lgico no es un proceso complejo. Una aproximacin para la verificacin del modelo lgico se centra en responder a las siguientes cuestiones:

Estn procesados correctamente los sucesos del modelo? Son vlidas las frmulas matemticas y las relaciones incluidas en el modelo? Estn calculadas correctamente las estadsticas y medidas de ejecucin?

6.4.1.- Verificacin y Validacin del procesamiento de los sucesos

El modelo lgico, para ser vlido, ha de contener todos los sucesos incluidos en el modelo conceptual, as como la lgica para una correcta planificacin de los sucesos futuros. Se debe validar que el modelo lgico contiene todos los sucesos del modelo conceptual, as como verificar las

98

Verificacin y Validacin

conexiones entre ellos. Por ltimo se ha de verificar que todas las variables de estado cambian correctamente ante la ocurrencia del suceso que las afectan. Un mtodo que se puede utilizar para la verificacin y validacin del procesamiento de los sucesos dentro del modelo lgico es una revisin en la que el desarrollador del modelo lgico debe explicar con detalle la lgica del modelo a los otros miembros del proyecto de simulacin.

6.4.2.- Verificacin de las frmulas y las relaciones

Dentro de un modelo de simulacin existen un conjunto implcito o explcito de relaciones y funciones matemticas: la generacin de nmeros y variables aleatorias estn basados en mtodos matemticos y la mayora de los modelos tienen leyes de conservacin que deben cumplirse. Cuando se construye el modelo lgico, se ha de tener cuidado en que estn bien calculados los elementos matemticos y que las relaciones de conservacin han de preservarse. Algunos de estos errores lgicos se pueden detectar cuando el modelo se implementa como un programa de ordenador, pero incluso en esta etapa se ha de tener cuidado con que las funciones y las relaciones matemticas sean correctas. Como ejemplo en el supermercado se debe mantener siempre que el nmero de clientes que estn en cola junto con los que estn siendo servidos, tiene que ser igual al nmero de clientes en el supermercado.

6.4.3.- Verificacin de las estadsticas y medidas de ejecucin

Un error que puede darse en los modelos de simulacin es que ante la ocurrencia de un suceso no haya un cambio adecuado en las medidas de ejecucin. Un mtodo para verificar que las estadsticas y las medidas de ejecucin se modifican adecuadamente, consiste en asociar con cada suceso una lista completa de todas las estadsticas y medidas que se ven afectadas por la ocurrencia de dicho suceso. En algunos lenguajes de simulacin (GPSS, SIMAN, SIMSCRIPT), algunos tipos de medidas se recogen automticamente cuando se ejecuta la simulacin, de forma que al ser esto transparente al analista, se reduce la probabilidad de errores estadsticos.

6.5.- Verificacin del modelo de ordenador

Una vez que el modelo lgico ha sido verificado y validado, se ha de implementar el modelo de ordenador. El modelo de ordenador se verifica para mostrar que la implementacin es correcta y no contiene errores. Esto es diferente a mostrar que el modelo es una representacin adecuada del sistema real, lo que sera la validacin del modelo. Algunos de los mtodos de verificacin del modelo de ordenador son propios de la simulacin, mientras que otros se utilizan en cualquier desarrollo de software. El esfuerzo necesario para la verificacin del modelo depende del lenguaje de programacin que se haya utilizado y no hay un acuerdo fuerte sobre una metodologa general. La verificacin del
99

Verificacin y Validacin

modelo de ordenador es una de las pocas actividades en el proceso de simulacin en la que el analista no recibe ayuda por parte de los administradores y usuarios del sistema. Las siguientes aproximaciones se pueden utilizar para verificar el modelo de ordenador:

Mtodos de programacin estructurada Trazas de simulacin Pasar test al programa Chequear las relaciones lgicas Comparar con modelos analticos Usar representaciones grficas

6.5.1.- Mtodos de programacin estructurada

Los defensores de la programacin estructurada argumentan que si se siguen las normas de este paradigma, ser ms fcil en los programas resultantes la verificacin, la deteccin de errores y la modificacin de los mismos. Los principios de la programacin estructurada incluyen:

Diseo descendente: el programa se disea comenzando por el nivel ms alto, que est descompuesto en mdulos los cuales a su vez se pueden volver a descomponer. Modularidad: cada mdulo es responsable de una nica funcin. Refinamiento por pasos: cada mdulo se desarrolla usando un refinamiento paso a paso de la funcin final que tendr dicho mdulo. Mdulos compactos: los mdulos no tendrn muchas lneas de cdigo. Estructuras de control: todo el cdigo se debe poder escribir con las estructuras IFTHEN-ELSE, WHILE, REPEAT-UNTIL, FOR y CASE.

6.5.2.- Trazas de simulacin

Muchos lenguajes de simulacin ofrecen la posibilidad de trazar la simulacin a medida que ocurre. GPSS y SIMAN, pueden representar el flujo de las entidades a travs del modelo, mientras que SIMSCRIPT puede listar la secuencia de procesos y sucesos ejecutados. Cuando se utiliza un lenguaje de propsito general, el analista debe incluir esta posibilidad de traza dentro del programa.

6.5.3.- Tests
Pasar tests al programa consiste en realizar una serie de pruebas controladas sobre l. Los dos tipos de tests ms comunes son los tests ascendentes y los descendentes. En los tests ascendentes se comienza por comprobar los mdulos bsicos y luego se pasa a probar las interrelaciones entre ellos hasta que el modelo ha sido probado como un nico sistema. En el diseo descendente las pruebas comienzan con el mdulo principal y van bajando hasta los mdulos bsicos.
100

Verificacin y Validacin

Una vez que el modelo ha sido probado, se debe ejecutar bajo condiciones extremas. En el ejemplo del supermercado, se debe probar el modelo cuando la proporcin de llegadas de clientes es mayor que la capacidad de servicio por parte de los cajeros. De forma similar se puede simular el supermercado con una razn de llegada muy baja.

6.5.4.- Chequear las relaciones lgicas

En la mayora de los model os de simulacin hay relaciones lgicas que se deben mantener durante la ejecucin. Dichas relaciones pueden estar basadas en leyes de conservacin o pueden ser estadsticas por naturaleza. Si stas no se mantienen en algn momento, el programa no es una correcta implementacin del modelo lgico.

6.5.5.- Verificacin con modelos analticos

Aunque los modelos de simulacin son a menudo utilizados para analizar sistemas que no se pueden modelar mediante mtodos analticos, a veces podemos seleccionar datos y parmetros para la simulacin de forma que se pueda comparar sus resultados con los de un modelo analtico. En el ejemplo del supermercado, si en el modelo de simulacin suponemos que no hay empaquetadores, que existe una nica cola de clientes y que los tiempos entre llegadas y de servicio siguen una distribucin exponencial con media constante, podemos comparar los resultados de la simulacin con los resultados de un modelo analtico de colas M/M/s. De esta forma, podemos comparar ambos, lo que nos ayuda a comprobar si el modelo de simulacin es o no correcto.

6.5.6.- Verificacin mediante representaciones grficas

Un animacin on-line de la ejecucin de la simulacin puede ayudar a la deteccin de errores en el modelo (tambin puede ayudar en la interpretacin de los datos de la simulacin). El problema que tiene realizar la animacin es que hace que la ejecucin sea ms lenta.

6.6.- Validacin del modelo de ordenador

Una vez que el modelo de ordenador se ha verificado, se ha de determinar si es una correcta representacin del sistema real. En el proceso de validacin del modelo han de intervenir el analista y las personas relacionadas con el sistema. Un test para validar el sistema es ver si las personas relacionadas con el sistema confan en el modelo y estn dispuestos a utilizarlo. La importancia de la credibilidad en el modelo es la mayor razn del inters tan difundido en realizar una animacin de la salida de la simulacin. La animacin es una forma efectiva para que los analistas comuniquen la esencia del modelo al administrador. Un modelo es desarrollado siempre para un conjunto particular de propsitos. Un modelo de un determinado sistema puede ser vlido para un propsito y no ser vlido para otro.

101

Verificacin y Validacin

Ha de quedar claro que la validacin no es algo que se ha de hacer cuando el modelo ha sido desarrollado, sino que ha de hacerse desde el principio. Vamos a ver una serie de mtodos de validacin como:

Comparacin de los resultados de salida del modelo con los del sistema real. Mtodo Delphi. Test de Turing. Comportamiento en casos extremos.

6.6.1.- Comparacin de los resultados de salida del modelo con los del sistema real
Este mtodo se podr aplicar en aquellos casos en los que el sistema exista y se pueda experimentar con l de forma que se obtengan datos de salida del mismo. Este mtodo consiste en ejecutar el modelo y obtener una serie de datos de salida y comparar stos, mediante algn mtodo estadstico, con resultados que se tengan del sistema. Debemos comparar dos conjuntos de datos, de alguna forma, para determinar si el modelo es una representacin adecuada del sistema real. Una primera aproximacin sera utilizar uno de los test estadsticos clsicos (como Chicuadrado o Kolmogorov-Smirnov para dos muestras) para determinar si las distribuciones subyacentes a los dos conjuntos de datos se pueden ver como la misma. Sin embargo, los procesos de salida de la mayora de los sistemas reales y simulaciones no son estacionarios y son autocorrelados, de forma que ninguno de estos tests es directamente aplicable. Hay distintos mtodos de comparacin, a continuacin vamos a ver uno de ellos:

6.6.1.1.- Aproximacin basada en un intervalo de confianza

Vamos a describir una aproximacin para comparar un modelo con el sistema real suponiendo que es posible recoger un conjunto numeroso de salidas para ambos. Suponemos que recogemos m conjuntos independientes de datos del sistema y n del modelo. Sea xj e yj la media de las observaciones en el j-simo conjunto de datos del sistema y del modelo respectivamente. Los xj s son variables IID con media x=E(xj ) y tambin los yj s son variables IID con media y=E(yj ). Intentamos comparar el modelo con el sistema construyendo un intervalo de confianza = x y . Construir dicho intervalo de confianza es preferible a comprobar la hiptesis nula H 0 : x = y , por varias razones:

El modelo es una aproximacin del sistema real por lo que H0 es claramente falsa en la mayora de los casos.

102

Verificacin y Validacin

Un intervalo de confianza da ms informacin que el test de hiptesis correspondiente. Si el test de hiptesis indica que x y , el intervalo de confianza adems indica la magnitud en la que difieren.

Construir un intervalo de confiaza para es un caso especial del problema de comparar dos sitemas. Podemos construir el intervalo de confianza utilizando la aproximacin Paired-t o la aproximacin Welch. La aproximacin de paired-t requiere que m=n pero permite que xj est correlada con yj. La aproximacin de Welch se puede usar para cualesquiera valores de m=2 y n= 2 , pero requiere que los xj s sean independientes de los yj s. Suponemos que construimos un intervalo de confianza del 100(1-a)% para usando alguna de las aproximaciones y obtenemos un lmite superior s(a) y un lmite inferior i(a) del intervalo correspondiente. Si 0 [i ( ), s( )] , entonces la diferencia observada entre x y y se dice que es estadsticamente significativa. Esto equivale a rechazar la hiptesis nula H 0 : x = y a favor de la hiptesis alternativa H1 : x y .

6.6.2.- Mtodo Delphi

Este mtodo se utiliza cuando no se tienen datos o se dispone de muy pocos, acerca del sistema que se est considerando. En este mtodo, se selecciona un grupo de expertos los cuales deben llegar a un consenso en las respuestas que den acerca de una serie de preguntas que se les plantean. En un entorno de simulacin los expertos pueden ser los administradores y usuarios del sistema y las cuestiones son acerca del comportamiento del sistema bajo ciertas condiciones de operacin. El mtodo Delphi excluye las discusiones cara a cara entre los miembros del grupo. En este mtodo se les plantea al grupo una serie de cuestiones

Se enva un cuestionario a cada miembro del grupo. Para la validacin de un modelo de simulacin, las cuestiones podran tratar sobre las respuestas del sistema real ante ciertas entradas o cambios en su estructura. Basndose en las respuestas dadas a las cuestiones planteadas, se elaboran nuevos cuestionarios que van centrndose en temas ms especficos. Los nuevos cuestionarios se envan al grupo junto con las respuestas obtenidas a las cuestiones en rondas anteriores.

Estos tres pasos se repiten hasta que el analista consiga de los expertos una prediccin de la respuesta de sistema. Una crtica de este mtodo es que consume mucho tiempo. No necesariamente debe suponer un tiempo adicional en el proyecto de simulacin, ya que se puede ir realizando paralelamente al desarrollo del modelo. Su costo puede resultar caro, pero no mucho ms que otros mtodos de

103

Verificacin y Validacin

validacin. En general, aunque se critique que los mtodos de validacin son caros y consumen tiempo, ms costoso es construir un modelo que no sea vlido. Otra crtica que se hace al mtodo es que si el grupo de expertos lo que va a hacer es predecir el comportamiento del sistema por qu no usar el mtodo en lugar del modelo de simulacin? En algunas situaciones este mtodo puede ser utilizado, sin embargo, normalmente no es prctico mantener el grupo de expertos para predecir el comportamiento del sistema ante los posibles cambios que se planteen. Incluso si se pudiera mantener el tiempo de respuesta podra ser muy largo.

6.6.3.- Test de Turing

Alan Turing sugiri este mtodo como un test de inteligencia artificial. En este test, a un experto, o grupo de expertos, se le presentan resmenes o informes de resultados de ejecucin del sistema y del modelo, a los que se les ha dado el mismo formato. Estos informes se reparten aleatoriamente a los ingenieros y administradores del sistema, para ver si son capaces de discernir cules son los reales del sistema y cuales la imitacin resultado de la simulacin. Si los expertos no son capaces de distinguir entre ambos, se puede concluir que no hay evidencias para considerar inadecuado al modelo. Si descubren diferencias las respuestas sobre lo que encuentran inconsistente se puede utilizar para realizar mejoras en el modelo. Se puede considerar que este mtodo es el inverso al mtodo de Delphi. En el test de Turing se consulta a los expertos para ver si son capaces de identificar las respuestas del sistema, mientras que en el de Delphi se pregunta a los expertos para que predigan las respuestas del sistema. Aunque este test parece muy intuitivo, hay muy pocos informes de su uso, ya que requiere un esfuerzo considerable para formatear las medidas de ejecucin del sistema a la hora de crear el informe que se da a los expertos. Otra dificultad est en ajustar las medias del sistema real ya que en ellas intervienen elementos que no se han considerado en el modelo. Por ltimo este test requiere un anlisis estadstico por parte del grupo de expertos para determinar si hay diferencias significativas entre el informe real y el simulado.

6.6.4.- Validacin de comportamientos en casos extremos

Ocasionalmente se puede observar el comportamiento del sistema bajo condiciones extremas. Esta es una situacin ideal para recoger datos de las medidas de ejecucin del sistema real de forma que luego se puedan comparar con los resultados de la simulacin, una vez que se ejecute el modelo bajo situaciones similares. Tambin es posible que los expertos del sistema puedan predecir el comportamiento del sistema bajo condiciones extremas y utilizar estas predicciones para validar el modelo.

6.7.- Ayuda para la validacin de los modelos

Para ayudar en el proceso de validacin y dar credibilidad a los modelos de simulacin, Naylor y Figuer formularon una aproximacin en tres fases que se describe a continuacin:

104

Verificacin y Validacin

Construccin de un modelo con alta apariencia de validez. Validar las suposiciones del modelo. Comparar las transformaciones de entrada en salidas en el modelo con las correspondientes en el sistema real.

6.7.1.- Desarrollo de un modelo con alto grado de validacin

El primer objetivo en la simulacin es construir un modelo que parezca razonable en apariencia para aquellas personas que conocen el sistema. Los usuarios potenciales del modelo deben estar implicados en el procesos de construccin, desde su conceptualizacin hasta su implementacin, para asegurar que el modelo va a tener un alto grado de realismo. Los usuarios potenciales y aquellas personas que conocen el sistema, pueden evaluar las salidas del modelo para evaluar si stas son razonables y pueden ayudar a identificar deficiencias en el modelo. As se puede realizar un proceso de calibracin de forma que se vayan realizando mejoras iterativas en el modelo partiendo de las deficiencias encontradas. El objetivo en este paso es la de recolectar la mayor cantidad posible de informacin acerca del sistema que se desea modelizar, de forma que el modelo que se construya sea una buena representacin de ste. La informacin se puede tomar de distintas fuentes, tales como:

Conversaciones con los expertos del sistema: un modelo de simulacin no es una abstraccin desarrollada por un analista que trabaja aislado, sino que ste debe trabajar con las personas que estn ntimamente familiarizadas con el sistema. Lo normal no es que una persona o un nico documento recojan toda la informacin acerca del sistema, de forma que habr que consultar a varias personas y recolectar varios documentos. Por ejemplo, si se quiere modelizar un sistema de manufactura, se ha de obtener informacin preguntando a los operadores de las mquinas, ingenieros industriales, administradores, etc. Observacin del sistema: Si existe el sistema real que se intenta simular o uno similar al l debemos obtener datos de ste para usarlos en nuestro modelo. Estos datos puede que estn disponibles en registros histricos o por e l contrario puede que sea necesario recolectarlos. Se ha de tener cuidado a la hora de recolectar datos de forma que se haga correctamente, y que los datos que se recojan tengan un formato adecuado y sean representativos del sistema que va a ser modelado. Por ejemplo si se recolectan datos de un campo de pruebas militares, las condiciones de combate son diferentes a las de un enfrentamiento real, por lo que los datos recogidos no van a ser representativos en el caso de querer modelar un combate real. Si queremos simular un banco y observamos el funcionamiento de uno para poder obtener la distribucin del tiempo entre llegadas, s que estaramos recogiendo datos representativos.

105

Verificacin y Validacin

Teora existente: Por ejemplo si estamos simulando un banco, la teora existente nos dice que la razn de llegada de los clientes, con bastante probabilidad, sigue una variable exponencial. Resultados rele vantes de modelo de simulacin similares: si existen modelos similares al que se desea construir se puede utilizar informacin de stos y aspectos que podemos tener en cuenta para nuestro modelo. Experiencia/intuicin: a menudo es necesario hacer uso de la experiencia y de la intuicin para formular hiptesis acerca de ciertos componentes de operacin de un sistema complejo, particularmente si el sistema no existe actualmente. Se supone que dichas hiptesis deben ser justificadas en etapas posteriores de este proceso de validacin.

En resumen podemos decir que para que el modelo que vamos a construir tenga una alta apariencia de credibilidad y validez es necesario obtener toda la informacin posible acerca del sistema y para esto es necesario interactuar con el administrador/cliente de forma regular durante todo el transcurso del estudio de la simulacin y realizar una serie de revisiones de la informacin obtenida para as comprobar que las informaciones locales obtenidas no son contradictorias.

6.7.2.- Comprobacin de las suposiciones hechas en el modelo

Las suposiciones hechas en el modelo pueden ser de dos clases: acerca de la estructura y acerca de los datos. Las suposiciones de estructura implican cuestiones acerca de cmo opera el sistema y normalmente se hacen simplificaciones y abstracciones de la realidad. Por ejemplo en el caso de un banco, los clientes pueden formar una nica cola o formar una por cada cajero; puede que los clientes se puedan mover de cola cuando vean que una de ellas avanza ms rpidamente. As mismo, el nmero de cajeros puede ser fijo o variable. Estas suposiciones en cuanto a la estructura deben ser verificadas mediante observaciones hechas en periodos de tiempo apropiados adems de mediante el dilogo con administradores y cajeros. Las suposiciones acerca de los datos deben verificarse haciendo una recoleccin fiable de datos y en un correcto anlisis de los mismos. Cuando combinamos dos o ms conjuntos de datos recogidos en diferentes periodos de tiempo, debemos hacer un estudio, mediante test, para ver si los podemos unir para formar una nica muestra. El anlisis de los datos consiste en tres pasos:

Identificar la distribucin apropiada. Estimar los parmetros de la distribucin que se ha supuesto. Validar el modelo estadstico supuesto mediante tests como el de chi-cuadrado o Kolmogorov-Smirnov.

En esta segunda etapa se ha de comprobar que las suposiciones hechas en las etapas anteriores son ciertas. Es importante que se usen datos representativos en la construccin del modelo y es igualmente importante poner cuidado cuando se estructuran dichos datos. Por ejemplo, si para un mismo

106

Verificacin y Validacin

fenmeno aleatorio observamos varios conjuntos de datos, podemos utilizar todos estos conjuntos de datos como una nica muestra slo si se comprueba la homogeneidad de dichos conjuntos (para ello su puede utilizar el test de Kruskal-Wallis). Otra herramienta til durante esta segunda fase es el anlisis del impacto de los valores de entrada sobre las salidas. Si una salida es muy sensible a los cambios en ciertos aspectos del modelo, dichos aspectos deben ser modelados ms cuidadosamente y se necesitar una mejor especificacin de los mismos.

6.7.3.- Determinar cmo son de representativos los datos de salida de la simulacin.

El test ms definitivo para la validacin del modelo de simulacin es ver que sus resultados de salida se parecen fielmente a los datos de salida que podran esperarse del sistema. Esto, a menudo, no se puede realizar. Por un lado puede ocurrir que el sistema no exista e incluso en el caso de que exista y se puedan observar sus salidas, la comparacin no es tan simple como puede parecer. Resulta que los procesos de salida de la mayora de los sistema del mundo real y simulacin son no estacionarios (las distribuciones de sucesivas observaciones cambian con el tiempo) y autocorrelados (las observaciones del proceso estn correladas unas con otras). De forma que los tests estadsticos clsicos de observaciones IID no se pueden aplicar directamente. Por otro lado, debido a que el modelo es slo una aproximacin al sistema real, una hiptesis nula de que el sistema y el modelo son el mismo es claramente falsa. Por lo que nos vamos a preguntar si las diferencias entre el sistema y el modelo son o no lo suficientemente significativas para afectar a algunas de las conclusiones sobre el sistema que se derivan del modelo. Si al intentar comparar los resultados de salida del modelo y del sistema vemos que existen diferencias significativas, podemos utilizar la informacin que se deriva de estas discrepancias para mejorar el modelo. A este procedimiento se le llama calibracin del modelo y contina hasta que los conjuntos de datos de salida del sistema y del modelo se parecen razonablemente. Sin embargo, debemos preguntarnos si este procedimiento produce un modelo vlido del sistema en general, o si slo es representativo para un conjunto de datos particular. Lo que podemos hacer es utilizar un conjunto de datos para calibrar el modelo y usar otro conjunto para realizar la comparacin con el sistema. Para comparar los resultados del modelo con los del sistema podemos utilizar procedimientos tales como el test de Turing o Delphi, o podemos utilizar otros procedimientos estadsticos para comparar las salidas observadas del sistema real con las de la salida de la simulacin.

6.8.- Calibracin y validacin del modelo

La calibracin es un proceso iterativo en el que se compara el modelo con el sistema real, se realizan cambios y ajustes en el modelo, se vuelve a comparar el modelo revisado con el sistema real, se hacen ajustes adicionales, y as hasta que el modelo resulta una buena aproximacin al sistema real Figura 6.2.
107

Verificacin y Validacin

Modelo Inicial

Comparacin Sistema Real 1 Revisin Modelo

2 Revisin Modelo

Figura 6.2. Proceso iterativo de la calibracin

Esta comparacin del modelo con el sistema real, se puede realizar a travs de conjuntos de test, que pueden ser subjetivos u objetivos. Los primeros implican a personas que conocen aspectos del sistema y pueden hacer juicios sobre el modelo. Los test objetivos necesitan datos sobre el comportamiento del sistema para poder compararlos con los datos sobre el comportamiento del modelo. Una posible crtica en este proceso de calibracin es que se llegue a validar el modelo con el mismo conjunto de datos con el que se ha ido calibrando, lo cual puede significar que el modelo se ajusta bien a ese conjunto de datos en particular. Para evitar este problema se puede recolectar un nuevo conjunto de datos para ser usado en la etapa final de validacin. Si se descubren discrepancias inaceptables entre el modelo y el sistema en la etapa de validacin, el modelador debe volver a la fase de calibracin hasta que el modelo sea aceptable.

6.9.- Revisiones estructuradas

La revisin estructurada es una tcnica que se usa para aplicaciones de programacin y su uso no est restringido a los modelo de simulacin. Dicha tcnica fue propuesta para conseguir programas correctos y estructurados. Para que este proceso de revisin se haga bien, se han de seguir una serie de normas:

Las revisiones pueden ser formales o informales. Las informales son ms espontneas mientras que las formales son ms estructuradas y necesitan ms planificacin y preparacin. Ambas deben ser usadas durante el desarrollo de un producto software grande. Los miembros que han de formar parte del equipo de la revisin estructura son:

El autor: persona que ha desarrollado y presentar el modelo. El moderador: persona que planifica, ordena la revisin y realiza las labores de coordinacin durante la revisin.

108

Verificacin y Validacin

El secretario: toma notas durante la revisin para que quede un registro permanente de ella. Ir anotando los posibles defectos que los miembros detecten en el producto para que luego los desarrolladores puedan realizar las correcciones. Supervisor de mantenimiento: persona que revisa el producto desde el punto de vista del mantenimiento. Para los modelos de simulacin, el mantenimiento equivale a las modificaciones que se deben incluir par aadir caractersticas adicionales del sistema real. Supervisor de estndares: persona que se encarga de vigilar que en todo momento el producto cumpla con los estndares necesarios. Representante del usuario: revisa el producto desde el punto de vista de que el producto es un modelo del sistema real. Otros revisores: otras personas que contribuyen a la revisin del producto.

No hay una demarcacin estricta de las responsabilidades de los miembros del equipo de revisin y cualquier miembro puede manifestar cuestiones sin que pertenezcan a su funcin especial en el equipo.

Durante la revisi n no se corrigen errores, sino que son anotados para que posteriormente los desarrolladores puedan corregirlos. Las revisiones estructuradas no deben ser muy largas, tpicamente suelen durar como mucho una hora. La misin principal de las revisiones es enc ontrar fallos que los desarrolladores no hayan detectado.

6.10.- Conclusiones
Para realizar la simulacin se ha de determinar qu aspectos del sistema real necesitan incorporarse al modelo y qu aspecto se deben ignorar. Vamos a describir algunas lneas para determinar el nivel de detalle necesario en el modelo de simulacin:

Definir cuidadosamente, al principio del estudio, las cuestiones de inters tales como las medidas de ejecucin, la forma en la que el modelo va a ser usado y las configuraciones alternativas del sistema de inters. Los modelos no son universalmente vlidos, sino que son diseados para propsitos especficos. Si las cuestiones de inters no se especifican no se puede saber si se ha conseguido el nivel de detalle deseado en el modelo. Usar expertos y anlisis de sensibilidad, para ayudar a determinar el nivel de detalle en el modelo. Se puede preguntar a personas familiarizadas con sistemas similares al de inters acerca de cules son los aspectos ms importantes. En cuanto a los anlisis de

109

Verificacin y Validacin

sensibilidad se pueden usar para determinar qu parmetros, distribuciones o subsistemas tienen ms impacto sobre las medidas de ejecucin.

Uno de los errores puede ser incluir una excesiva cantidad de detalles en el modelo. Es mejor empezar con un mode lo moderadamente detallado y posteriormente incluir ms detalles si se considera necesario. Si son muchos los aspectos de inters que hay que estudiar, es conveniente usar un modelo sin refinar o un modelo analtico para identificar los factores importantes antes de desarrollar un modelo de simulacin detallado.

Para incrementar la credibilidad en el modelo y conseguir que este sea usado, es conveniente que participen en el proceso de su construccin los administradores del sistema.

110