The Personal Software Process (PSP) is a software development “exercise” intended to help software engineers understand their own personal strengths and weaknesses in the software development process. At its heart, it consists of doing some estimates before you start work (how long will design take, how many bugs do you think you’ll write, etc.), keeping detailed records while you work, and then comparing reality to your estimates. Doing so helps you understand where your weaknesses (if you estimate 10 bugs but end up writing 100) and strengths are.
You can read more about the PSP in the original report. I’ve modified some of the forms to make them (hopefully) simpler to fill out.
To complete the PSP, you will need the PSP spreadsheet as well as these instructions.
The PSP spreadsheet consists of several sheets, each with some information for you to fill in as you go through the development process (fields that you should fill in are highlighted in light blue).
Getting started
To begin with the PSP, you should fill in the following fields on the PSP summary page:
Name, date, and the assign(ment) that you are working on
All of the highlighted fields in the “Estimate” column. This is where you try to estimate:
- How many lines of code this assignment will take (the first section)
- How much time each phase of the development will take (second section)
- How many “defects” (bugs) you will create during each phase
- How many defects you will fix in each phase
Software development phases
The PSP follows a traditional software development structure (“waterfall”). The phases of development are as follows:
Planning – Informal design, thinking about the problem
Design – More formal design, making design documents, taking notes about program structure, etc.
Code – Actually writing code
Compile – Compiling code, including time needed to get libraries, include files, makefiles, etc. working.
Test – Testing the compiled program
Postmortem – After the program is finished, time spent thinking about it in retrospect, evaluating your performance, making changes to your development process based on what you learned, etc.
Plan Summary sheet
The Plan Summary sheet summarizes all of the estimated and recorded values (time, and lines-of-code) over the entire project. Some details on particular fields:
“Final LOC/Hour” is a (calculated) field showing how many lines of code per hour you anticipate writing/actually wrote.
“Estimate” is how much time/code you think you’ll need. “Actual” is how much you measured yourself actually needing (the later sheets help you keep track of how much time you use, and how many LOC you write).
“Created” is how many lines of code you wrote when you first sat down, before you started fixing things.
“Δ lines” is how many lines were added/removed, as part of fixing defects. The actual value is calculated for you, as the sum of the ΔL column in the defect log.
“Final LOC” should be the total number of lines in your project when you are completely finished.
(See page 30 in the PSP report for more details.)
On the server, there’s a utility called cloc which can count the number of
lines in a source file, being smart about skipping blank lines and comments.
Time in phase
This section is used to summarize the total amount of time (in minutes) you spend in each of the development phases. You only have to fill in the initial estimates; the spreadsheet will copy the actual measured time from the time log. (The exception is the “postmortem” phase, as that is not tracked on the time log.)
Defects injected
A “defect” is something that is wrong with your program. It could be a spelling error in a comment, a bug in your code, an incorrect design that led you to use the wrong algorithm, etc. In this section you keep track of how many defects you “injected” in each phase. Note that this means that when you find a defect you need to “track it back to the source” to figure out which phase it originated in!
As with the time summary, the actual values will be filled in for you, from the defect log. You only have to fill in the estimates, before you start.
Defects removed
Similarly, this section tracks how many defects you fixed during each phase. Ideally the total number of defects fixed should be equal to the total number injected, but if there are any problems left that you couldn’t figure out before submitting, then the two numbers won’t balance out.
As with the time summary, the actual values will be filled in for you, from the defect log. You only have to fill in the estimates, before you start.
“After development” refers to defects fixed after development has technically completed.
Time log
The time log sheet is intended to help you keep detailed records of how much time (to the minute) you spend in each of the phases. Most of the columns should be self-explanatory. The “Int. mins.” column is for “interruption minutes”, time spent during a given development session when you were interrupted for whatever reason. (For long interruptions it’s probably better to count the beginning and end as two separate sessions.)
The “total by phase” box will automatically calculate the total time spent in each phase (provided you are careful to use the phase names exactly as shown).
Defect log
The defect log sheet is intended to help you keep detailed records of every “defect” you added and removed from your project. When you find a defect, you should fill in
Inject – the phase in which the defect was originally added (use the phase names as given on the right, so that the automatic totals will work).
Remove – the phase in which the defect was removed
Type – the type of defect; a reference to the different types is given on the right. (If you use the defect types exactly as listed, the sheet will total up how many defects of each type you wrote/fixed.)
Fix time – how long it took you to fix this particular defect
Fix ref. – If you are fixing a defect that was originally injected in the process of fixing some other defect, fill this in with the number of the original defect. This helps you keep track of whether your bug fixing activities are actually adding more bugs!
Description – A (short) description of the defect
Submission
If you can, upload the completed spreadsheet into your assignment’s directory on the server; otherwise, you can just email it to me (please mention “PSP” somewhere in your message, so I can search for it easily).