PSP++ is a tool to help you estimate the time and amount of code required to write a piece of software. It uses the PROBE method described in Watts S. Humphrey's A Discipline for Software Engineering. The basis of this method is that if your predictions are wrong, they are probably wrong somewhat consistently. That is, you probably either consistently over- or underestimate the size of your projects.
Given a history of your predictions and the corresponding actual results, PSP++ will take your latest prediction and make a prediction of its own, using that history to inform it.
Download the PSP++ installation archive into the directory where you intend to put the folders containing the project list file and your project files.
Rules for recording PSP data
(main "input/" "output/" state)The specified "input/" and "output/" strings specify input and output directories. They are named "input/" and "output/" in the installation examples provided with the PSP++ installation archive.
("Generated report for PSP Revision" STATE)and a new report will exist in the output directory.
PSP reads all its inputs from a single directory. That directory must contain a file named projects.txt, which will tell it what your projects (historical and current) are called. These projects are simply listed one per line, with the most recent last. For each project listed, there should exist a corresponding text file in the input directory. For example, if your projects.txt contains
trig stat graphyour input directory should contain (alongside projects.txt) trig.txt, stat.txt, and graph.txt. A report will be generated for the graph project, using the trig and stat projects as history.
To give some basic information about the project in the report, PSP++ asks for your name, the program's name, your instructor's name, and the date. These can be left out if you so choose. This section takes the following form:
name: Your Name date: November 11, 2009 program: Exercise 1 instructor: Dr. Instructor
There are two types of predicted objects: new and reused. In a new object, you simply estimated how many lines it will take. For a reused object, you estimate lines of base, added, modified, and removed code. "Base" lines refers to how large the object is when you start with it. "Added," "modified," and "removed" lines refer to how much you add to, modify of, or remove from that base. For any object, you can also name it, classify it into a type, and write a comment. (There are no restrictions on any of these fields.)
An example section follows. Note that lines starting with # are comments.
new objects: #### file-bundle module #### - name: read-bundle estimated lines: 25 type: IO - name: write-bundle estimated lines: 25 type: IO - name: get-from-bundle estimated lines: 6 type: Calculation reused objects: - name: split-on-whitespace type: Parse estimated base: 22
Next comes the time log. The times in this section are used to inform PSP++'s later time predictions. Each work period is tagged with a phase, which can be named as you choose. For example, you might choose to tag work sessions as "plan", "code", or "test". This choice will be reflected as categories in the report generated. Comments should specifically describe activities and insights of the work period. An example time log follows. Vague comments are unacceptable.
Note: The PSP++ software limits the comment field to one line. One way to deal with this limitation is to use an editor that renders the display in line-wrap mode without inserting end-of-line separators. No matter how you deal with the one-line comment field, descriptive comments, with specifics, are required for each time-log entry.
time log: - date: Nov 19, 2009 start time: 3:00PM end time: 4:15PM phase: plan comment: Group meeting during class time. Planned out input format, modular breakdown. - date: Nov 19, 2009 start time: 5:30PM end time: 5:49PM phase: plan comment: Planned output document. [THIS COMMENT IS TOO VAGUE] - date: Nov 21, 2009 start time: 6:07PM end time: 7:43PM phase: code comment: Implemented string distance algorithm. [COMMENTS SHOULD BE DESCRIPTIVE, WHICH MAKES TOO LONG FOR ONE LINE, BUT THE PSP++ SOFTWARE ONLY ALLOW ONE LINE. IT HELPS A LITTLE TO USE AN EDITOR IN LINE-WRAP MODE. REGARDLESS, IT IS IMPORTANT TO MAKE COMMENTS SPECIFIC AND DESCRIPTIVE.] Discovered that string distances are always natural numbers. Experimented with a tail recursive implementation, but found that structural induction led to a clearly correct solution with less than 5% loss in time of computation and an average 20% increase in space required by computation.
In the defect log, you list and categorize any defects you added to (and fixed in) the software. Like with the time log, these can be categorized by whatever system you choose. Defect descriptions should be specific and usually should lead to a new test in the test suite.
Note: The PSP++ software limits the comment field to one line. It helps a little to use an editor in line-wrap mode. No matter how you deal with this limitation, descriptive comments, with specifics, are required for each defect.
defect log: - date: Nov 19, 2009 type: Contract fix time: 3 comment: Found that negative input to distance function triggered system crash. Added test specifying negative input and correct response. [AGAIN, COMMENTS ARE LIMITED TO ONE LINE BY THE PSP++ SOFTWARE, BUT MUST BE SPECIFIC AND WITH REASONABLE DETAIL, WHICH MAKES THEM TOO LONG FOR ONE LINE. IT HELPS TO USE AN EDITOR IN LINE-WRAP MODE.]
- date: Nov 19, 2009 type: API fix time: 2 comment: logic error [THIS DESCRIPTION IS TOO VAGUE]
- date: Nov 19, 2009 type: API fix time: 2 comment: Confused char-code with code-char
actual added lines: 825 actual base lines: 87 actual modified lines: 56 actual removed lines: 12