Guidelines: Important Decisions in Implementation

Decide which artifacts to use and how to use each of them. The table below describes which artifacts that always should be used (i.e. mandatory), and which can be used in some cases. The tailoring comments gives some guidelines to how you can tailor each artifact.

For a complete description of each artifact, see Implementation Artifacts. For each artifact read the section "Tailoring" where the advantages and disadvantages of that specific artifact are discussed.

Artifact	Tailoring Comments
Implementation model	Mandatory
Implementation subsystem	Use this if you need to organize the components.
Component	Mandatory. The issue is what different stereotypes to use.
Integration Build Plan	Use this if you need to plan the integration. Omit it only when the integration is trivial.
Software Architecture Document (Implementation View)	Use this only if you have an implementation model that differs from the design model.

Identify Configuration Items

Read Implementation Artifacts, then decide which of the artifacts that should be handled as separate configuration items.

It is up to each project team to decide what needs to be handled as separate configuration items. It is basically a matter of how you want to control versions of subsystems and their components. Consider how you will work with the implementation model.

The answer to these questions will help you decide the size of the configuration items that constitute the implementation model.

If you have one person responsible for one subsystem, or if single subsystem is optional or interchangeable, make each such package into a configuration item.

In a small project it may be enough to let the entire implementation model be one configuration item.

When you develop a system incrementally, make sure that you create a baseline at the end of each iteration. In this way, you can control the difference, iteration to iteration.

Implementation Subsystem

An implementation subsystem exists both as a modeling element in your modeling tool and as a directory (a file library) in the development environment. From a configuration management point of view, the subsystem is a configuration of components, and possibly other enclosed subsystems. Most configuration management systems also give you the opportunity to control the import dependencies between subsystems, to make sure that the system will confirm to the layered structure you have defined.

Component

Components are the main configuration items. Notice that in many object-oriented programming languages, for example, (Ada, C++, and Java) a class is separated in two files, one file that describes the specification of the class, and another file that contains the implementation of the class.

Decide Unit Test Coverage

Decide the extent to which unit testing should be performed; the level of code coverage. The scale goes from informal to 100% code coverage. This scale is described in the Test Plan.

The level of coverage in unit test is often driven by the needs of the integration and system testers, to whom the code is handed over. They are dependent on the quality of the code for their work. If the code has too many defects, the integration and system testers will send the code back to the implementers too often. This is a sign of a poor development process, and the solution may be to require the implementers to do more thorough unit testing.

Of course, you cannot expect the unit tested code to be completely free of defects. But, you need to find a "healthy" balance between unit testing, and quality.

The level of unit test coverage can also differ between different phases. Even, a safety critical project requiring 100% code coverage during construction and transition does not usually require that during elaboration, because many classes are only partly implemented at that stage.

Decide How to Review Code

Decide to what extent the code should be reviewed. The advantages and disadvantages of code reviews are:

+ It enforces and encourages a common coding style on the project. Code reviewing is an efficient way to make the members of the project follow the Programming Guidelines. To ensure this, it is more important to review results from all authors/Implementers, than to review all source code files.

+ To find errors that automated tests does not find. Code reviews catch errors other than testing.

+ To share knowledge between individuals, and to transfer knowledge from the more experienced individuals to the less experienced individuals.

- If not done properly, it may be inefficient. There is a danger that code reviewing is done "just because we have to", and as an efficient complement to automated testing.

Code reviewing adds a significant value to the project. All projects that starts to measure the levels of bugs and maintenance problems related to code reviews, claim that they gain performance from the reviews. However in many organizations is it hard to make them "take off". There are several reasons for that: