Decide How to Use Work Products

Make a decision about what work products are to be used and how they are to be used.  In addition to identifying what work products are to be used, it is also important to also tailor each work product to be used to fit the needs of the project. 

The table below specifies which Implementation work products are recommended and which are considered optional (i.e., may only be used in certain cases). For additional tailoring considerations, see the tailoring section of the work product description page.

Decide Unit Test Coverage

Decide the extent to which unit testing will be performed and the level of code coverage, which has a  scale that goes from informal to 100% code coverage. This scale is described in the  Test Plan.

The level of unit test coverage is often driven by the needs of the integration and system testers, to whom the code was handed over. The system testers 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. You do, however, 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 that requires 100% code coverage during construction and transition does not usually require that during elaboration because many classes are only partially implemented at that stage.

Decide How to Review Code

Decide to what extent the code should be reviewed. 

The advantages of code reviews are:

• To enforce and encourage 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's more important to review results from all authors and Implementers than to review all source code files.
• To find errors that automated tests do not find. Code reviews catch errors not encountered in testing.
• To share knowledge between individuals and to transfer knowledge from the more experienced individuals to the less experienced individuals.

The disadvantages of code reviews are:

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

For more information about code reviewing, also see Task: Review Code.

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

• Not enough data is collected to verify if code reviewing actually works.
• Too much data is collected.
• Implementers are very protective about their code.
• The reviews get bogged down in formalities.
• Administrating reviews takes too much effort.

Keep the following in mind to make the best possible use of code reviews:

• Collect only adequate data.
• Measure the performance of the reviews and display the result.
• Use reviews in a "lean" way.

For more information on review levels, see Guideline: Review Levels.