Part 3: A „Six tau software development process”

Let us talk about the timeliness of a software development process. Let us assume that Tsop denotes the time from start of development to release point of time of a software system. In general, Tsop is the sum of the feature implementation time or code complete time Tcc and the error correction time Tec. Note, that typical software development projects (urgently) need an error correction phase unless a strict zero-defect software development approach is applied during the feature implementation phase.

As said in part 1, the required and recommended process timeliness parameter tau = Tsop/6. Or, in other words, Tcc = 4 x tau and Tec = 2 x tau to detect 75% of defects until end of Tcc and 95% of defects until end of Tec. Therefore, at the start of a software development project, we can already calculate the required process timeliness parameter tau resulting finally in a high-quality software release. Let us view a real example with Tcc = 76 weeks. In this case, the required process timeliness parameter tau would be 19 weeks. The error correction phase would be 2 x tau = 38 weeks.

To understand tau, we must remind ourselves of the fundamental principle of software reliability growth models: the failure inflow is proportional to residual defects at any time t. Without explaining the math, we will get following equation for tau:

tau [weeks]= residual defects (t) [failures]  /  failure inflow (t) [failures/week]

It is worth to explain the meaning of this important equation. Let us assume that there are 1000 remaining defects in our software system and no further defects will be injected. Then, tau = 25 weeks would result in a failure inflow per week depicted by the table below. There are 36% remaining defects after 25 weeks (1 x tau). In other words, 64% of the defects will be detected after 1 x tau. Not shown in below table, there are 13% remaining defects after 50 weeks (2 x tau) or 87% of the defects will be detected after 2 x tau.

In a summary, the shorter the timeliness parameter tau the larger is the failure inflow per week and the shorter is the overall error correction time.

The timeliness parameter tau has an analogy with the characteristic time constant of a resistor R and a capacitor C connected in series. The name tau is associated with the time constant tau = R x C, which determines the charging and discharging speed of a capacitor. Remember after 1 x tau the capacitor is either 63% charged or discharged.

What impacts the process timeliness parameter tau? Tau mainly depends on the test efficiency of a software project: a) continuous integration of new code, b) availability of strong software/system test cases and continuous test case execution, c) a comprehensive test strategy/concept d) homogenous test effort per test week/day etc. Tau also depends on the error resolution cycle time of a software project: a) failure analysis capability (front desk), b) high-level design models for failure location (use cases, behavioral description, message sequence diagrams, etc.), c) modularity of design, code understanding, inline documentation, etc.

Keep in mind that the process timeliness parameter tau is a strong performance indicator for continuous integration, continuous testing and continuous bug fixing.

Finally, let us consider an example to demonstrate the strong impact of tau: totally, 10.000 defects are assumed to be finally injected in code during the feature implementation phase. A linear defect injection is assumed (homogeneous code error density). The time to code complete (Tcc) is 160 days. The following pictures illustrate two different curves, respectively: the cumulated injected defects and the cumulated detected failures. We will distinguish 4 scenarios: great process timeliness (tau = 1/8 x Tcc), good process timeliness (tau = 1/4 x Tcc), insufficient process timeliness (tau = 1/2 x Tcc) and no process timeliness (tau = 1 x Tcc).

Scenario 1, great process timeliness: tau = 20 days = 1/8 x Tcc. More than 85% of the defects will be detected until the end of the feature implementation phase. It can be shown that there is a time shift of 1 x tau between the defect injection and failure detection curve starting from 40 days (2 x tau) onwards until Tcc = 160 days. Overall, after already 5 x tau more than 95% of defects will be detected. Meaning, an error correction phase of less than 1 x tau is sufficient.

Scenario 2, good process timeliness: tau = 40 days = 1/4 x Tcc. About 75% of the defects will be detected until the end of the feature implementation phase. It can be shown that there is a time shift of 1 x tau between the defect injection and failure detection curve starting from 80 days (2 x tau) onwards until Tcc = 160 days. Overall, after 6 x tau more than 95% of defects will be detected. Meaning, an error correction phase of 2 x tau is recommended.

Scenario 3, insufficient process timeliness: tau = 80 days = 1/2 x Tcc. A little bit more than 50% of the defects will be detected until the end of the feature implementation phase. In this case, there is no constant time shift between the defect injection and failure detection curve. The error detection phase is as long as the feature implementation phase (2 x tau = 160 days).

Scenario 4, no process timeliness: tau = 160 days = 1 x Tcc. Much less than 50% of the defects will be detected until the end of the feature implementation phase. Also in this case, there is no constant time shift between the defect injection and failure detection curve. To detect at least 90% of the defects, the error detection phase (2 x tau = 320 days) will be significantly longer than the feature implementation phase (1 x tau = 160 days).