Page 239 -

210 PART TWO MANAGING SOFTWARE PROJECTS

This relatively simple concept represents an important step towards the creation of
an adaptive software engineering process in which changes are made to improve
“20 percent of the those elements of the process that introduce error.
code has 80 percent
of the defects. Find To illustrate this, assume that a software engineering organization collects infor-
them, fix them!” mation on defects for a period of one year. Some of the defects are uncovered as soft-
Lowell Arthur ware is being developed. Others are encountered after the software has been released
to its end-users. Although hundreds of different errors are uncovered, all can be
tracked to one (or more) of the following causes:
• incomplete or erroneous specifications (IES)
• misinterpretation of customer communication (MCC)
• intentional deviation from specifications (IDS)
• violation of programming standards (VPS)
WebRef
• error in data representation (EDR)
The Chinese Association
for Software Quality • inconsistent component interface (ICI)
presents one of the most
comprehensive quality • error in design logic (EDL)
Web sites at
www.casq.org • incomplete or erroneous testing (IET)
• inaccurate or incomplete documentation (IID)
• error in programming language translation of design (PLT)

• ambiguous or inconsistent human/computer interface (HCI)
• miscellaneous (MIS)
To apply statistical SQA, Table 8.1 is built. The table indicates that IES, MCC, and EDR
are the vital few causes that account for 53 percent of all errors. It should be noted,
however, that IES, EDR, PLT, and EDL would be selected as the vital few causes if
only serious errors are considered. Once the vital few causes are determined, the
software engineering organization can begin corrective action. For example, to cor-
rect MCC, the software developer might implement facilitated application specifica-
tion techniques (Chapter 11) to improve the quality of customer communication and
specifications. To improve EDR, the developer might acquire CASE tools for data mod-
eling and perform more stringent data design reviews.
It is important to note that corrective action focuses primarily on the vital few. As
the vital few causes are corrected, new candidates pop to the top of the stack.
Statistical quality assurance techniques for software have been shown to provide
substantial quality improvement [ART97]. In some cases, software organizations have
achieved a 50 percent reduction per year in defects after applying these techniques.
In conjunction with the collection of defect information, software developers can
calculate an error index (EI) for each major step in the software process {IEE94]. After
analysis, design, coding, testing, and release, the following data are gathered:
E i = the total number of errors uncovered during the ith step in the software engi-
neering process