Integration methods

A function-by-function integration method should be used that:

• establishes the infrastructure functions first.

• harmonises with the delivery plan.

It is necessary to establish the infrastructure functions to minimise the amount of test software needed. Examples of infrastructure functions are those that provide data input and output. Building the infrastructure saves the effort of providing drivers and stubs for the components that use it. The infrastructure provides the kernel system from which the rest of the system can grow.

42 ESA PSS-05-05 Issue 1 (May 1992) METHODS FOR DETAILED DESIGN AND PRODUCTION

In an incremental development, the delivery plan can constrain the integration method by forcing functions to be delivered in a user-specified order, not one that minimises the integration effort.

Each function will be provided by a group of components that may be integrated 'top-down' and 'bottom-up'. The idea of integrating all the components at one level before proceeding to the next is common to both methods. In top-down integration, the next level to integrate is always the next lower one, while in bottom-up integration the next higher level is integrated.

The integration methods are described in more detail below.

Punction-by-function

The steps in the function-by-function method are to:

1) select the functions to be integrated;

2) identify the components that carry out the functions;

3) identify the component dependencies (i.e. input data flows or control flows).

4) order the components by the number of dependencies (i.e. fewest dependencies first):

5) when a component depends on another later in the order, create a driver to simulate the input of the component later in the order;

6) introduce the components with the fewest dependencies first.

This approach minimises the number of stubs and drivers required. Stubs and drivers simulate the input to a component, so if the 'real' tested components provide the input, effort does not need to be expended on producing stubs and drivers.

Data flow diagrams are useful for representing component dependencies. Output flows that are not input to any other component should be omitted from the diagram.

When the incremental delivery life cycle approach is being used, the basic procedure above must be modified:

a) define the functions; b) define when the functions are required: c) for each release; do steps 1) to 6) above.

ESAPSS-05-05 Issue 1 (May 1992) 43 METHODS FOR DETAILED DESIGN AND PRODUCTION

Dependencies with components in a previous or a future release are not counted. If one component depends upon another in a previous release, the existing software can satisfy the dependency. If the component depends upon a component in a future release then a driver to simulate the input must be provided.

Top-down integration

The top-down approach to integration is to use 'stub' modules to represent lower-level modules. As modules are completed and tested, they replace the stubs. Stubs can be used to implement test cases.

Date: 2016-01-03; view: 801