Methodology

Methodology

 

In system development, there are many different life cycle models (for example, Spiral, Waterfall, V-Process) that describe the systems design process from initial requirements through to implementation. In order to apply these guidelines, it is important to relate them to the process of system development.

With the experience gained in the field of Systems Design, it has become apparent that the
V-Process model is a widely used and accepted practice for system development.

In the V-Process model, the left leg of the V basically describes the process of system analysis over time. The right leg of the V corresponds to the synthesis path over time, where smaller components are integrated to build the complete product.

The Analysis phases of the V-Process are represented as a consecutive sequence of four steps:

1.
2.
3.
4.

The reason for the partitioning of the design process into these four steps is the idea that in the early stages of the design process the designers must not be concerned with implementation details. In the early stages of gathering the ideas for the system (System Requirements) and then formulating them into a specification (System Specification), the designers are simply concerned with what the system must do.

Functional decomposition then serves as a bridge between Specification and Design. Usually the higher level functions are abstract entities which express ideas that are part of the requirements. The process of decomposing such functions, in effect, describes how to accomplish each of those functions.

In the System Design phase, the designers start to focus on the real-time constraints on the system and the sequencing of the functions. However, the designers are still not concerned with which microprocessor is used nor the available memory.

In the fourth stage (HW/SW Implementation), the designers are concerned with the final implementation details such as Operating System, microprocessor, and the available memory. The designers deal with these detailed issues secure in the knowledge that the overall system concept has been proved in the preceding steps. Thus, these four steps move the design from the conceptual system to the real product.

At this stage in the V-Process model it is necessary to develop the test definition and define the test scenarios to be used for later integration and acceptance testing. The traditional way to create test specifications is in a textual form that describes the component to be tested, applied stimulus, and expected results. However, the problem with this approach is that there is no feedback from test results to the design. At integration when a test produces a result that is different from the predicted result, it is not immediately obvious if it is the test specification that is wrong, or if the problem is in the module being tested.

Since a simulatable Rational Statemate model exists throughout all stages of development, the following actions are possible throughout development:

Therefore, it is vital that Rational Statemate analysis is at the center of the development, driving the development process so that these tests can be accurately defined. Effectively using the analysis capabilities of Rational Statemate shortens the overall system development life cycle.

In the early stages of system development, two types of models are used:

In the Functional Model, the aim is to capture the basic structure, ideas and algorithms for the system. In a Functional Model, the designers are not interested in any details of the implementation. It is a common characteristic of functional models that all the activities in the top-level chart are running concurrently. Also, if there is a bus interface, the designers are only interested in what messages go to and from the bus and are not in the details of message packing. See the Generic Top-Chart Approach for Controller Designs illustration.

The other type of model used at this stage is a Performance Model. At this level of analysis the models are based on queuing theory and the analysis typically involves running very large simulations to statistically analyze the performance of the system. Performance models are used to determine the throughput of the system, determine the response time of the system, and identify any bottlenecks or critical paths.

Moving down through the analysis stages, the next stage is the Implementation Model. The Implementation Model bridges the gap between the functional systems specification and the final software design. This practice enables the software engineers to write the software directly from the specification document produced from the Implementation Model. Hence it is very important that the software engineers are involved in creating this model.

The major change in switching from the Functional to the Implementation Model is that, in the Implementation Model the engineers are primarily concerned with the sequencing and timing of the functions, as only one function can be active at any time (assuming a single processor system). Therefore, control activities must be added, or adapted, to specifically control the sequencing of the functions. Also each function must be modified to become self-terminating so when activated, it executes and then terminates in the same way as the final code will. As part of this Implementation Model, the engineers also want to specify the real-time constraints on the software i.e., how long each function is allocated for execution in the final system.

Obviously there is some element of rework to move from a Functional Model, where everything is concurrent, to an implementation model, where everything is sequential. For the efficiency of the systems development process, it is important that this rework be minimized.

We must always start with the Functional Model, but it is important to define when to stop and switch to Implementation. As soon as the engineers have validated the functional idea, they should move to the Implementation Model. It is recommended not to proceed past the second level decomposition before switching to an Implementation Model.

The Implementation Model is not appropriate in every situation. In the case of a prime and subcontractor relationship, the prime contractor may be responsible for the overall system integration and test while the subcontractor may be responsible for software development. The prime may then test the delivered integrated software against Rational Statemate -defined integration and acceptance tests. In such a situation, the prime contractor should continue to analyze the system with functional modeling and need not concern themselves with the details of implementation.

The Implementation Model can be further extended to encompass Hardware-in-the-Loop analysis. By this, the automatically generated C code prototype is connected into the system by means of a bus interface. The product can be operated with this prototype and final optimizations and testing can be performed. This Hardware-in-the-Loop analysis is really the ultimate in verification, and provides absolute confidence that the specification is correct and the system will work when built.