Implement the use of McCabe's metric as a design rule of thumb measure of complexity, as an aid to productivity evaluation, and as an indicator of test complexity.Hitachi Method
Implement the necessary tools for calculating Halstead's metrics automatically from source code. Produce bug predictions as a starting point for determining expected test effort.
Modify the metrics you use by continuing feedback over several projects with the intent of making them better. Keep an eye on the literature for promising new metrics, especially those whose validity has been independently confirmed.
Be sure that management understands the differences between hardware and software reliability and the state-of-the-art of software reliability theory. Protect the contract signers from premature agreement to the use of a software reliability prediction model of dubious validity.
Track the literature in hope that useful methods of predicting software reliability emerge.
Try the Hitachi method for predicting test completion rate. Try it at several levels - from programs, the test cases, and schedules; for subsystems, their test cases, and schedules, and for the whole system
Track other progress measures that are easy to implement from existing paperwork and testing by-products. Use normalized times so you can compare large projects with small. You might find a new, useful relation.
Plan all testing in advance and require estimates of the number of test cases expected for each element's element level testing, integration, functional testing, and system acceptance testing. Uniform standards are needed for subtest scope to assure reasonable homogeneity across subtests.Some Slides About Software Metrics
Once integration testing starts, plot subtest completion rates and cumulative bug detection rates
For long, large projects the data should be relatively smooth. If not, use regression techniques.
Monitor these curves weekly to find if you are in the first or second phase. The second phase is marked by a dramatic increase in the test completion rate. If this is delayed beyond the 25% schedule point, corrective action is warranted. If delayed beyond the 50% point, a catastrophe is inevitable
Monitor the bug detection rate for a peak. This should occur approximately midway during the test period. After the rate starts to drop, calculate the critical value (i.e. derivative of the bug detection rate divided by the peak bug detection rate). If this is positive its time to panic
The cumulative data should be examined at least weekly, and revised predictions of the phases produced weekly.
