Software Reliability

The CTQs (Critical To Quality) (cont.):

Similar approach was followed for all other features (VOC). At the end of the exercise we had list of all the CTQs mapped to VOC.

Continuous CTQs: mostly performance/responsiveness related e.g. startup time, content feedback time, USB notification time etc.

Discrete CTQs: mostly on the “ilities” such as playability, interoperability, reliability, usability etc. Reliability and Usability being generic are further elaborated later in the chapter in the next section.

Critical factors: mostly compliance related such DivX certification, USB certification, FNAC 4 stars etc.

For both Continuous and discrete CTQs clear targets and specification limits were identified as success factors. For critical factors only verification criteria and method were elaborated.

Software Reliability:

Software by itself does not have a “Constant Failure rate”; hence defining MTBF (Mean Time between Failures) for software alone starts becoming fuzzy. The typical bath-tub curve for software looks something like shown in Figure (Jiantao Pan, 1999).

One way to determine software reliability would be in terms of its robustness. We tried to define Robustness as a CTQ for the product XYZ. This was again turning out to be “critical factor”. So we defined the CTQ (Y) in terms of “Number of Hangs/crashes” in normal use case scenarios as well as stressed situations and target was set at 0.

The lower level factors (X’s) affecting the CTQ robustness was then identified as:

1.       Null pointers

2.       Memory leaks

3.       CPU loading

4.       Exceptions/Error handling

5.       Coding errors