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

Verificacin

Modelo Conceptual

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?

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?

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 modelo 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 modelos 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 el 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