|
Building a simulation is not as easy as many people believe. It includes all the development processes of a sophisticated software system, plus additional steps that seem to be "forgotten" or ignored by many organizations that sponsor simulation developments. The following provides an overview of the major processes in a simulation development, highlighting some of the processes that are often forgotten or ignored, leading in turn to many of the cost and schedule overruns in simulation developments. There are five major processes: 1) Requirement development, 2) Modeling decisions, 3) Knowledge Acquisition and Engineering, 4) Modeling, and 5) Software Implementation. These processes are not sequential but are a complex set of interacting processes. Figure 1 depicts these processes with detail added to show the complexity.
|
|
|
The Requirement Development process for a simulation is similar to a standard software system requirement development until the functional requirements are allocated to the potential system components. The major difference is an iterative process, in which modeling or representation decisions are constantly being addressed, that results in 1) the way in which the processes and entities are represented and 2) the way in which the modeling techniques and data that are used for the representations are chosen. In most simulation developments this complex iteration is over simplified or naively ignored. In many cases the functional requirements step is "over simplified" and the simulation and database functions are handed off to software engineers without representation and modeling decisions being made before they start an Object Oriented Analysis. There seems to be a belief that the software team can figure out how to represent the processes and entities as part of the software specification and implementation process; this is formula for disaster. How the processes and entities are represented should be driven by:
|
| 1) the intended use (which drives the level of detail needed), |
| 2) the understanding of the real world process (you can only represent what you know), |
| 3) the ability to represent the details mathematically (you need to be able to develop a mathematical representation), |
| 4) the availability of data for the selected mathematical representation (data may not exist to support some of the good mathematical representations), |
| 5) the ability of computer technology to perform the number of calculations needed for a representation fast enough to make it reasonable (some mathematical representations require too many calculations to make them practical), and |
| 6) the cost to develop the total set of mathematical representations and gather the associated data (it may be easy to develop some of the mathematical representations in a series of processes and gather the requisite data for these representations, but the time to represent and gather data for the total number of processes may be overwhelming). |
|
Unfortunately, too many simulation development programs don't understand this iterative representational part of the overall development process and they ignore it until it is too late. Some development projects go on for 5 to 7 years and management never understands why the software engineers are not producing a simulation that is useful. The representation must match the intended use and the representation must be defined before the software engineers start. Quite often software engineers ignore the representation or modeling task and attempt to do the modeling as a last minute endeavor that is very seldom adequate. The Knowledge Acquisition and Knowledge Engineering (KA/KE) process (see Figure 1) provides the information needed about the processes and entities that must be represented; this is seldom done correctly or in a timely manner. Since the entire development process is iterative, this sub process is essential throughout the development.
|
|
Once the modeling is done properly and modeling techniques and data are selected, it is time to turn the development process over to the software engineers. The software engineers build prototypes of "parts" of the simulation to make sure the techniques work and the results for small portions of the simulation are reasonable. When there is consensus that the representation and modeling techniques are appropriate, it is time to turn to traditional software development methods. Figure 1 suggests that the appropriate approach is to use standard Object Oriented methods. As software environments improve, this may or may not be the ideal approach in the future, but for now it seems to have significant advantages that make it the best choice.
|
|
From Object Oriented Analysis forward, the steps to build a simulation do not significantly vary from a standard software development project. However, there is a Validation and Verification process that must be performed for a simulation that is different from a standard software IV&V process. It is most effective and efficient to do this from the very beginning of the development process. There will be a separate Fact Sheet that addresses this aspect of a simulation development process.
|
|
In summary, a simulation should be developed in three phases: 1) user to functional requirements, 2) representation requirements and modeling, and 3) software implementation. The second phase is very complex and consists of three iterative processes: a) modeling decisions, b) Knowledge Acquisition and Engineering, and c) modeling. Most simulations cost too much or fail because this second phase is poorly done.
|
| |
| Download as Word Document |
| Download as PDF |
.gif){kind=spacer}
