Process script for PSP 01
# created: 1998-09-02, Lutz Prechelt
# changed: 2000-11-02, Matthias Mueller
RCS: $Id: script.PSP01.html,v 1.2 2000/11/02 14:11:47 muellerm Exp $
You can either use this script as is, or adapt it to your needs.
If you adapt it, summarize the changes below.
These sections will follow below (the abbreviations given in parentheses are
the phase names to be used in the time/defect log):
For details not given here, see the templates and process scripts
mentioned in the overview on pages 650-651 in the PSP book.
- Planning (pl)
- Postmortem (pm)
- Create a new working directory.
- Have your process materials at hand: historical data, scripts,
- Have your support tools at hand: development environment,
time/defect logging tool, evalpplog.
Arbitrary repetitive cycles or partial cycles
through these subphases
are possible, as seems appropriate for the problem at hand.
In this case, apply the instructions below to appropriate parts
of your program instead of to the whole.
However, do not make the individual subphase-phases too small,
because that would mean too much trial-and-error and too little thinking.
- Obtain and understand the requirements description of the
program to be written.
- Instantiate a project plan summary template. Fill in its header.
- Estimate the total new and changed lines of code required for
completing the program. Enter it in the plan summary.
- Based on total new and changed lines and
the average time per line required in previous programs,
estimate the total time required for this program.
Enter it in the plan summary.
- Based on the expected total time for this program and the average
fraction of the time spent for each phase in previous programs,
estimate the expected time for each phase for this program.
Enter them in the plan summary. Tip.
- Instantiate the
activity-form. Fill in its header.
- Output of this phase: partially completed plan summary.
- Design your program.
Write a short document that describes the design in a top-down
fashion, starting with the general idea and proceeding through all
levels of decomposition into parts.
- (Note: if the program is small, the design document need not be
separate; it can be integrated in the code in the form
of comments. Tip.)
- During the design process, whenever you find a defect in some
part of your design which you thought was already complete, enter it in
the time/defect log.
- Output of this phase: complete design documents.
- Implement your program as specified in your design.
Update the design documents wherever you decide not to follow the
- Follow your coding standard.
- During coding, whenever you find a defect in some
part of your code which you thought was already complete, enter it in
the time/defect log.
During defect correction, update the design documents if necessary.
- Output of this phase: complete source code (and possibly
updated design documents).
- Review your code and make sure it is correct.
Enter any defects in the time/defect log.
- Output of this phase: corrected source code (and possibly
updated design documents).
- Compile your program.
- Enter all non-trivial defects (found by the compiler or by
yourself) in the time/defect log.
A defect is non-trivial if the compiler would not find it under
less lucky circumstances. Example: you have reversed the order of
two arguments to a method and received a type mismatch error --
had the types been identical, the compiler would not find such a
defect. Thus it should be entered in the log.
(In contrast, most syntactical errors and forgotten declarations
are trivial defects and need not be counted -- but this varies
depending on the programming language.)
- Output of this phase: corrected source code, executable program
(and possibly updated design documents).
- Design and create a number of test cases. If possible, store the
cases in files.
- Execute each test case and fix any problems. Repeat this until
all test cases can be executed with the correct result.
- Output of this phase: test report, corrected source code, defect-free
executable program (and possibly updated design documents).
- Create the time/defect log evaluation using evalpplog.
- Enter the 'actual' values for 'time', 'defects injected', and
'defects found' for each phase in the project plan summary.
- Compute the actual size information using your LOC counter
program and, if necessary, locdelta. (Watch out to correct for items
moved from one place to another within a file or between files.)
Enter the values in the plan summary.
- Enter the accumulated values for all programs written so far in
the 'Sum-to-date' column.
- Update your historical productivity database by adding a record
consisting of projected new and changed lines, actual new and
changed lines, actual total time.
(Just use a flat ASCII file, one line per record.)
- Shortly review the data in the plan summary and recall the
execution of the project. Then write a short project legacy at the
bottom of the plan summary document.
- Create the results webpage with all relevant documents
(as mentioned in (and based on) the exercise task description webpage).
- Output of this phase: completed plan summary, updated
historical database, webpage with all documents.
Even for substantial programs design document and code can be
literate programming is used.
Writing pseudocode first is actually a very nice way of programming.
The bad thing is that it usually means double work, not to talk of the
effort of keeping it in sync with the actual code during
Inner-procedural refinements are sometimes a way out of this problem.
They allow to write pseudocode and then attach the program to it,
so that no rewriting need be done and the pseudocode becomes tightly
integrated with the actual code and is easy to maintain.
See C-Refine as an
example. This is a preprocessor that implements refinements for
C, C++, or Java.
Specifying preconditions and postconditions is also called
design by contract. It was made popular
by the designer of Eiffel, Bertrand Meyer.
Design by contract has the advantage that design violations can be
tested in the implementation by generating code that
actually tests the assertions at run tine.
In C or C++, assertions (preconditions, postconditions,
invariants, or intermediate conditions at some point in the code)
are usually implemented using the assert() macro from the header file
This is a rather primitive facility, but already quite useful.
Eiffel has more powerful mechanisms that are built right into the
For Java there is a preprocessor called
implements are rather powerful assertion mechanism, even including
You can compute various sum-to-date or average-to-date or percentage
data (for time and defects) automatically by just
applying evalpplog to all of your
previous ppl files at once.
Last modified: 2000-11-02 15:11:31, Matthias Mueller
muellerm @ ira.uka.de