學術研究的範圍多半起自conceptual model，例如課本例題或是作業，或是論文要研究的多階層供應鏈，因此沒有validation的步驟，但是仍需進行程式的verification。初學者經常在解決所有程式的語法錯誤(syntax error)，便以為大功告成，而忽略了程式裡隱藏的邏輯錯誤(logical errors)。這種錯誤可能導致顧客或訂單的處理流程不同於conceptual model的原先設定，甚至只在少數情形下才有差異，雖然模擬程式可以執行，但是產生的模擬結果已有偏差(bias)。因此，模擬程式必須經過合理的verification步驟，有足夠的數據證明無誤後，才可進行實驗分析。
Validation/Verification Techniques
1. Animation
程式設計者可透過動畫觀察程式的運作是否與預期的方式相符。一般的ARENA程式可觀察entity的流程，例如晚到的緊急訂單是否優先處理，或是排隊的顧客是否會選擇較短的隊伍。通常動畫也可以提供給熟悉系統的人員，以確認模擬的運作與實際狀況吻合。
2. Comparison with Analytical Models
學術上的conceptual model很多出自於可求出理論解的數學模式，例如服務系統擁有多位效率與能力不同的人員，如果改為人員的效率與能力完全相同，則可用等候理論求出理論解。因此我們可驗證程式在這種有理論解的特殊情況下，模擬結果是否正確。
3. Analysis of Input/Output Relationship
假設對於系統已有初步的了解，尤其是控制參數對於系統績效的影響方向，則可以驗證模擬結果的變化是否一致。例如從庫存管理的觀點來看，增加安全庫存量可減少缺貨量，但是會增加持有成本，如果模擬的測試結果顯示缺貨量並未減少，則有理由懷疑程式內有邏輯錯誤。
4. Comparison with Real Systems
如果模擬程式是針對真實世界的系統而建構，則可以比較模擬的結果與實際的數據，例如訂單處理時間或庫存缺貨率是否與系統最近的實際表現相彷。
5. Evaluation under Extreme Condition
在極端的設定下，通常可以預知系統績效，因此可以驗證模擬的結果是否一致。例如將兩種訂單的處理流程設為相同，則相關的績效應該沒有統計上的差異。另一個例子是在庫存管理模式中將安全庫存大幅提高，觀察缺貨率是否降到0。
6. Operational Graphics
模擬軟體通常提供動態圖表的功能，在模擬進行時可顯示重要指標的變化，這可以作為驗證的依據。例如以圖表顯示石化業儲存槽的庫存降到安全下限時，會減量供應下游工廠，或者要求同業以轉運的方式支援供貨。
7. Traces
最直接的檢驗方式是按照流程順序逐一檢查每個步驟，尤其是流程分岔點的決策方式是否正確，但是這種方式效果有限。很多模擬軟體提供step by step的模擬執行方式，可以檢驗程式的運作過程是否與conceptual model一致，也可以觀察系統在特定時間的詳細狀態。例如重要訂單到達後應該被優先排入生產排程，則可利用trace的功能檢查訂單排序是否按照原先設計的方式進行調整。
Suggestions
1. Construct submodels to simplify validation.
如果系統相當龐大，可以先從其中一部份開始，確定無誤後，再逐步擴大到完整的規模。例如模擬供應鏈的運作，可以先建立經銷商銷售與補貨過程，再加入物流中心出貨與補貨過程，最後加入製造商接單生產與出貨的部份。另一種方式是分別建立供應鏈各個成員的處理流程，最後再連結成完整的系統，ARENA提供這種submodel的建模方式。
2. Start with a standard model. Then add particular features.
先建立一個容易驗證的基本模式，確定無誤後再加入系統運作的特色。例如模擬大賣場的結帳過程，可以先假設櫃檯數目不會增減，或是顧客在等候過程中不會轉到較短的隊伍，確定基本模式無誤後，再加入於尖峰與離峰時段調整櫃檯數目的決策，以及排隊的顧客會轉到較短的隊伍的特色。
3. Ask someone else to walk through the entire model.
由於先入為主的盲點作祟，自己建立的程式通常不容易發現錯誤，可以請熟悉系統與模擬軟體的同學或同事代為檢查，透過問答的溝通方式，可以發現隱藏的問題。
|
