Part 1: A „Six tau software development process"

Part 1: Introduction of a „six tau software development process”

There is a general trend in automotive industry: the vehicle architecture changes from a decentralized to a centralized one. Instead of applying many decentralized electronic control units (ECUs), a few centralized high-performance controllers (HPCs) will become the core of an intelligent connected vehicle. However, high-performance computers feature multiple micro controller cores hosting a huge amount of software code. Hence, software is becoming the automotive industry’s core enabler.

Generally, a major challenge is the development of large-scale software systems (above or significantly above 1 million lines of code) under the pressure of shrinking development cycles and increasing quality expectations. Of course, highest software quality expectations are a key of autonomous driving vehicles.

Typically, in software development we distinguish between a feature implementation and an error correction phase. The first phase is mainly dedicated to the implementation of required features or functions. The second phase is most often required for the detection and correction of remaining software bugs to meet given quality criteria. An example of a software release criteria might be the remaining errors per thousand lines of code (< 0.5 errors/kloc recommended).

Software reliability growth models are typically used to predict the total number of remaining defects in a software system after the feature implementation phase is completed. However, it would be much more interesting to predict the number of injected defects in a software system already during the feature implementation phase. A precondition for such an approach is continuous integration (CI) and continuous testing (CT) of software as well as continuous bug fixing (CB) during the feature implementation phase. CI, CT, and CB are applied in both an iterations-based software development process and an agile software development process. Regular failure detection data can be used to predict the number of injected defects in a software system during the feature implementation phase.

Even more importantly, beside the total number of defects the prediction provides another timeliness parameter measuring the performance of CI/CT/CB. We will denote this parameter tau and will explain later why named tau. The parameter tau is crucial for the following: a) effectiveness of continuous integration, testing, bug fixing, b) software maturity after feature implementation and c) predicted software quality at release point of time (i.e., start of production (SOP)).

Let us assume that Tsop denotes the time from start of development to release point of time of a software system. Then, the required and recommended process timeliness tau = Tsop/6. In this case, 4 x tau will be spent for the feature implementation phase and 2 x tau are needed for the error correction phase. The performance of a six-tau software development process ensures that 75% of defects will be detected until end of the feature implementation phase and 95% of defects will be detected until release point of time (SOP), meaning at the end of the error correction phase.

In next upcoming part 2 I will elaborate more on the prediction method which is based on software reliability growth models. In part 3 I will explain the timeliness of a software development process. Part 4 is dedicated to a six-tau software development process. Finally, part 5 covers a real example.