Chapter 2. Lesson 2: Planning and Measurement

Table of Contents
Interlude: some minor automation
Report R1: LOC counting standard
Report R2: Coding Standards
Program 2A: Simple LOC counter

Introduction to software planning and basic size measurement

Read chapters 3 and 4 of the textbook

Write program 2A using PSP0.1

Write report R1 (LOC counting standard) and R2 (Coding standard)

Interlude: some minor automation

One of the great appeals of the PSP philosophy is that of identifying the repetitive and uninteresting portions of a task and giving them structure and form so that they're easier to accomplish. Surely one of the best ways to do this is automate the process, using the computer itself-- after all, it is supremely qualified for repetitive and uninteresting tasks. And the process of collecting and processing data can (and should be automated.

To that end, I did a quick web search for the "personal software process" and "Emacs" using Google (my favorite search engine), and turned up the University of Karlsruhe's PSP tools page, referenced by a Mr. Lutz Prechelt. I don't know Mr. Prechelt personally, but had corresponded with him before on a scripting language "contest" he was hosting, and the tools on the page seemed consistent with his continuing efforts to improve the software development process.

The only tool I really stuck with so far, though, is pplog-mode, an Emacs add-in package which helps automate the data-collection process. It adds a window in an Emacs project; whenever a loggable item occurs, the developer presses F8 and is greeted with a time-stamp; by typing in a few mnemonic codes, one can log the beginning and end of development phases, interruptions, and defect fixes. A portion of the log I generated while playing with pplog-mode and the Eiffel program from lesson 1 is below:

1999-12-20 18:16:01 bcp                                    (1)
1999-12-20 18:16:02 bi                                     (2)
1999-12-20 18:16:04 ei                                     (3)
1999-12-20 18:16:08 be                                     (4)
1999-12-20 18:16:52 ee cp syn kn main.e                    (5)
   didn't add the word "then" to the if-block
1999-12-20 18:20:24 be
1999-12-20 18:21:52 ee cp syn kn number_list.e
   numerous problems using = instead of := for assignment
Signifies the beginning of the compile phase
The beginning of an interruption
The end of an interruption
The beginning of a defect log
The end of a defect entry, with parameters; this defect was injected in the compile phase, it was a syntax error caused by lack of knowledge, and occurred in file number_list.e, with an associated comment. Since the error log occurs in the compile phase, that's where we assume the error was located and fixed.

The pplog-mode package had a companion piece, evalpplog, a Perl script for parsing logs and gathering information, but the information produced was too copious for me to use, and in a format I didn't like. To get something more to my needs, I cobbled together a python script which can take a "log format" and produce something which will better suit my needs for this independent study:

Table 2-1. Interruptions Recording Log

Student:Victor B. PutzDate:991219
Defect foundTypeReasonPhase InjectedPhase RemovedFix timeComments
991220 18:16:08synkncompilecompile0didn't add the word "then" to the if-block
991220 18:20:24synkncompilecompile1numerous problems using = instead of := for assignment
991220 18:23:00synkncompilecompile2couldn't figure out how to redefine make and call precursor
991220 18:29:26logkncompiletest0wasn't allowing for integer entries in the file (just double)
991220 18:30:03logkncompiletest1wasn't incrementing indices in loops
991220 18:31:57logtypocompiletest0erroneously typed "/" instead of "-" for the top term of the standard dev.

It can produce time logs in addition to defect logs. Hopefully this will suit my needs better, will streamline the process of data collection, and make this a more enjoyable experience; after all, if a process is too difficult to use, developers simply won't use it.

It should be noted that the log tools as they stand have a serious weakness: they only allow the representation of one error at a time, and obviously it's possible to have several extant defects simultaneously. But even the PSP defect recording log has this problem, since it focuses on "fix time"-- so here, we'll only log defects when we're actively focused on fixing them, to better judge fix time.

One last note: the new logging tool allows me to log both a defect type and a defect reason (actually, any number of classifications, but I'll stick to type and reason). This, to me, is critical-- a defect's type is interesting, but a defect's cause is more critical-- it gives me something to work toward; if most of my defects are caused by knowledge of syntax, for example, I can combat that by studying the language's syntax (or by choosing a less-confusing language!). To that end, and because numeric typecodes are poor mnemonics, I will be adopting the following as type and reason codes, taken directly from Lutz Prechelt's defect classification standard at

Table 2-2. Defect Type Classification

ItemShort DescriptionFull Description
Defect Types  
ICInterface CapabilityThe design of an interface is wrong, so that the interface does not provide the functionality that it must provide.
ISInterface SpecificationThe specification of an interface is wrong, so that the parameters involved cannot transfer all of the information required for providing the intended functionality. This is a less fundamental variant of IC: Only parameters need be added.
IDInterface DescriptionThe non-formal part of the description of an interface is incomplete, wrong, or misleading. This is typically diagnosed after an IU. Note that the description of a variable or class attribute or data structure invariant is also an (internal) interface.
IIInterface ImplementationSomething that I cannot influence does not work as it should. This defect should never be used when I am the source of the defect. (In principle, this is a special case of ID.)
IUInterface UseAn interface was used wrongly, i.e., in such a way as to violate the interface specification.
IVData InvariantA special case of IU. The interface violation is: not maintaining the invariant of some variable or data structure. Violating the meaning of a simple variable is a special case of this.
MDMissing Design (of required functionality)A certain requirement is covered nowhere in the design. This is stronger than IC, where the coverage is present, but incomplete.
MIMissing ImplementationA certain part of a design was not implemented. If the part is small, MC, MA or WA may be more appropriate.
MEMissed Error HandlingAn error case was not handled in the program (or not handled properly)
MAMissing AssignmentA single variable was not initialized or updated. Only one statement needs to be added
MCMissing CallA single method call is missing. Only one statement needs to be added.
WAWrong AlgorithmThe entire logic in a method is wrong and cannot provide the desired functionality. More than one statement needs to be added or changed.
WEWrong ExpressionAn expression (in an assignment or method call) computes the wrong value. Only one expression needs to be changed.
WCWrong ConditionSpecial case of WE. A boolean expression was wrong. Only one expression needs to be changed
WNWrong NameSpecial case of WE. Objects or their names were confused. The wrong method, attribute, or variable was used. Only one name needs to be changed.
WTWrong TypeTwo `similar' types were confused.
NotesIC, IS, ID, MD are typically related to the design phase; IU, IV, MI, WE, WC, WN are typically related to implementation. 
Defect Reasons  
OMOmissionI forgot something that I knew I had to do.
IGIgnoranceI forgot something, because I did not know I had to do it.
CMCommissionI did something wrong, although I knew in principle how to do it right.
TYTypoI did something trivial wrong, although I knew exactly how to do it right.
KNKnowledgeI did something wrong, because I lacked the general knowledge (ie education).
INInformationI did something wrong, because I lacked the specific knowledge how to do it right or had received misleading information about how to do it. This refers to a problem in communication.
EXExternalI did nothing wrong. The problem was somewhere else and the defect was introduced by some other person.