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 ------------------------------------------------------------------------ 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) ---------------------- ------------------------------------------------------------------------ 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'.