Defect Type and Reason Standard for the PSP

Author: Lutz Prechelt
Course: PSP
Language: more or less language independent
Date: 1996-10-21

Defect Type Standard

Suggestion for how to interpret the defect type categories.
(Supersedes the defect type standard suggested in the PSP book, p. 260)

Each defect class is defined by both the erroneous state and the action needed to fix the defect. This action is easily and correctly identifiable at the time the defect entry is made in the log. Often a defect entails many or complex fix actions. In this case only the most comprehensive defect type should be recorded.

Check which of the following actions count as defects in *your* PSP:

changes of incorrect program behavior
changes of incorrect program documentation
changes of program constructions that with high probability would have lead to defects during program maintenance
changes of improper documentation that with high probability would have lead to defects during program maintenance
improvements of design simplicity
improvements of robustness

Class	Description
10	Documentation problem: documents, comments, or messages are misunderstandable or wrong FIX: correct the document, the comment, or the message
20	Syntax/Static problem: a defect that can USUALLY be detected by the compiler (syntax errors, missing declarations etc. Defects that the compiler has caught only by luck count in other classes!) FIX: correct syntactic or compiler-findable static semantic defect.
30	Build/Package problem: errors in version control or in change management FIX: create or use correct version or correct the change
40	Assignment problem: one-statement defects in data management or procedure calls (e.g. wrong operand or operator in expression, wrong object assigned to, assignment missing or duplicated, call to wrong procedure, call missing) FIX: correct one statement
50	Interface problem: misdesign of interfaces (class, procedure, or data type interface is incomplete or wrong or inappropriate, objects are invisible etc.) FIX: change interface
60	Checking problem: missing, wrong, or inadequate handling of error cases FIX: add or correct error handling
70	Data problem: invariant of variable or data structure violated FIX: correct definition of invariant or correct program code to maintain the invariant
80	Function problem: defects beyond one statement in algorithms or functionality (something done too early or too late, something done in wrong way, algorithm wrong, functionality misdesigned or missing) FIX: add or correct more than one statement
90	System problem with timing, synchronization, network, or hardware; i.e., errors due to influences from outside the scope of the program itself (i.e., the surrounding system/environment) FIX: adapt program to properly handle these influences.
100	Environment problem: defect in development environment or support systems (compiler defects or other tool defects, defects in test drivers or test data etc.) This is the only class of defects that are not the programmer's fault. FIX: correct support system defect or avoid development environment defect

Defect Reason Standard

(PSP book, p. 295)

Tag	Class Name	Description
ed	education	You did not properly understand how to do something
co	communication	You were not properly informed about something by someone else
ov	oversight	You omitted doing something you understood and wanted to do
tr	transcription	You knew what to do but made a mistake in doing it
pr	process	Your process somehow misdirected your actions

Errors resulting from relying on misleading documentation written by yourself, errors from not following your defined process, and errors from not doing routine sanity checks belong to 'process'.