Faculty of air transport engineering the department of «air navigation systems»

Case Study
A technique in which a real or fictional situation or series of events are
presented to trainees for their analysis and consideration of possible solutions
or problems identified. Their findings in a real situation can be compared with
what actually occurred. Manipulations of equipment where the instructor provides the necessary feedback. The provision of knowledge and skills by means of a computer with numerous interactions, student response analysis and allowing when appropriate free individual rhythm of learning (self-paced manner). It allows to practice in restricted or in real time a part of the skills necessary for the operational task in a possibly not realistic environment (e.g. 2D aerodrome).

2. 
   Flexible methodologies in simulation
   

When creating complex simulation models, the developer faces a number of problems that are almost impossible to successfully solve at the initial stages of work on a project. So, Yu. N. Pavlovsky points out that “among complex” processes, a significant class is made up of those that are a combination of several simultaneously occurring interrelated, but of different scale in time processes, for the preparation of models which require characteristic orders of magnitude characteristic scales of averaging over time. Quite often there is a situation where among the interacting processes a small number of “main” ones can be distinguished, the characteristics of which we are interested in, and it is precisely for the forecast of these characteristics that a model is developed. The characteristic time scale of the other processes is much smaller, and we are interested in their characteristics insofar as they affect the characteristics of the main processes. Thus, the ongoing processes are divided into “slow”, the development forecast of which we are interested in, and “fast”, the characteristics of which we are not interested in, but their influence on slow ones must be taken into account.”
Accordingly, the complex system under investigation is usually presented as some “slow” model, whose behavior depends on the behavior of one or more “fast” models. The influence of “fast” processes on “slow” ones in a model can be taken into account in two ways: either consider the fast process in detail at the appropriate time scale and, in fact, build a separate model for it, or refuse detailed modeling and replace the corresponding process characteristics with random variables. The second method, obviously, is much simpler, but does not always provide the required level of accuracy, and in some cases it is simply impossible to obtain distribution functions of random variables that describe the effect of fast processes on slow ones.
Thus, complex systems are characterized by the presence of such an embedded hierarchy of fast and slow processes, that is, by the presence of several levels of abstraction. Accordingly, the developer of the simulation model faces a difficult problem: at what level of abstraction should you stop when creating the model to ensure the necessary modeling accuracy, but at the same time not make the system unnecessarily complicated. At the initial stages of development, it is rather difficult and far from always possible to precisely determine this boundary. In fact, defining the boundaries of modeling is one of the main and most complex problems facing the developers of the model.
In real large-scale projects, this problem should be solved in close interaction between the developers and the customer, since only he ultimately determines in which tasks the simulation model is used and whether it is adequate. But the customer can evaluate the adequacy of the model only by the results of its practical operation. Consequently, one of the most important conditions for success is the organization of quick and high-quality feedback with the customer at the stages of operation of the model, assessing the adequacy and deciding on the direction of its further development.
Thus, in practice, the preferred strategy is the iterative development of the simulation model “from simple to complex”: first, a fairly simple model with a single level of abstraction is constructed, where the behavior of all “fast” models is described, for example, using random value generators. Such a simple model can be relatively quickly implemented, tested, and in practice evaluated by the customer in terms of utility for solving the problem. The comments received are compiled into the new system requirements. As necessary, “fast” models become more complicated, additional levels of abstraction are introduced - the model develops and improves, the development cycle repeats.
However, the implementation of such an iterative approach is complicated by a number of problems. One of the main difficulties is change control. At each iteration, the software system must be modified in a certain way. In this case, the changes should relate to strictly defined aspects of the behavior of the developed system, without affecting the rest. In practice, it can be very difficult to ensure. The problem is compounded by the fact that with the development of a software system, the complexity of development increases nonlinearly. All this fully applies to the development of simulation models.
In addition, the preparation, conduct, and analysis of the results of simulation experiments are usually associated with the processing of large amounts of data, which is especially typical for complex systems. Accordingly, the practical use of such simulation models is impossible without the corresponding auxiliary software. In such cases, the creation of a simulation model should be accompanied by the development of a software package, which greatly complicates the task facing the developers.
Thus, iterative creation of simulation models in accordance with the “from simple to complex” strategy is impossible without an appropriately organized and methodologically supported process for developing software systems. Moreover, this applies both to the software implementation of the model itself, and to the software package as a whole, which ensures the practical use of the model. The development process should be streamlined so that it is possible to adjust this process itself, respond quickly to changes in requirements, direct the development of the simulation model in the right direction and control the consequences of these changes.
“Traditional” software development methods, which can be divided into a “code and fix” approach and predictive (“heavy”) methodologies, do not provide the required qualities of the development process.
The “code and fix” approach, in fact, is a rejection of a single development plan, and can be described as intuitive. The lack of organization often leads to the fact that over time the system more and more gets out of the control of developers, the complexity and laboriousness of making changes and new functionality increases more and more. Thus, this approach does not provide the necessary level of controllability of the development process.
In contrast to the described approach, the “classical” methodologies put the development plan and strict adherence to it in the process of creating a software product at the forefront. Almost all such methodologies are based on the “waterfall (cascade) model” of software product development (classical life cycle), where the stages of analysis and design (that is, the planning stage) precede the stage of implementation and research of the software system (pic 1.1)

Analizing

Projecting

Coding

Testing

escort