In this short article, I will try to give a simple overview of the PSP as we practice it, what I am describing here reflects my understanding and my practice. If you want formal articles that describe what PSP is, please refer to the references section in this article.

PSP is CMM level 5 applied to a single programmer. In other words, how a single programmer could apply engineering discipline on just himself. I really like this approach, as it comes to basics, the single programmer who is writing source code for the system.

Many small corporations in Egypt have small projects that a single programmer develops from start to end, such projects exist even in medium corporations, especially if they are using modern high level languages, modern development tools, and their large reusable code libraries. For the above reasons, I feel happy with the PSP training, as we are again going to basics and speaking practically; this could help us in our corporation to develop better.

In a nutshell, PSP is a way to develop software using a defined process. The process describes how to collect quantitive metrics regarding performance and quality; and how to find ways to improve continuously.
The magic of PSP formal training is that, we practice it through 10 real programming assignments; some of them are not trivial. So, the PSP training can’t be taken by non programmers.

The relation between PSP and CMM:
In Fig-1, we show the CMM levels and mark by “*” all key practices that at least partially are covered by PSP. It’s clear that a large percent of CMM key practices are covered in PSP.

Fig-1 (from “A Discipline for Software Engineering by Watts S. Humphery”)

PSP Levels:
As everything in life is developing incrementally, so is the PSP: We started with PSP0, PSP1.0, PSP2.0 and then PSP3. Every new process version introduces new changes in the process. This incremental approach is really natural; I don’t expect any success if someone is going to practice PSP2 or PSP3 directly.

In Fig-2, we show the levels of PSP, in each level, new concepts are introduced and a new programming assignment is given to practice the new concepts in actual programming work.

Fig-2 (from “A Discipline for Software Engineering by Watts S. Humphery”)

PSP0: The Baseline Process:
The baseline is simply what we already do in developing software, getting requirements, creating design, writing code, and testing; but you would record all the time spent in each phase and would record all the defects you found and how much time it took to fix them.

In the Postmortem report (a report you write at the end of every assignment), you count how much defects are injected and removed from each development phase. Actually PSP0 is the basic training on using a defined process and writing basic reports.

We started the first assignment using paper forms which were tedious but helped us to concentrate on the new concepts rather than to use a tool that could distract us from the new concepts. In later assignments, we used a nice spreadsheet that is provided by the instructor.
In PSP0.1 we start the basis to measure size by following a coding standard. We also used the PIP (Process Improvements Proposal) which is a structured document to record our process problems and improvements suggestions.

PSP1.0: The Personal Planning Process:
The size estimation OLOC (Object Lines Of Code) is used and compared to the actual. We use a size template to write all objects (Classes in C++ and Java) and how much functions will exist in each object and the expected lines of code per function.

Now with a history you can just estimate OLOC and let the spreadsheet calculate the expected time by using statistical linear regression once there was a correlation [linear relation] between your old LOC and time in previous projects. Of course the estimation will be based on your past data, so you should make sure to record consistent and accurate data to get quality estimates. The spread sheet will also compute automatically the time spent in each development phase based on your past history.

This was a great step, I don’t have to estimate time anymore, I will just estimate size using familiar Object Oriented techniques and then estimate the lines of code. The time is automatically calculated using statistical linear regression.

Also in this phase we learn to write test report to record all test cases used to verify the program is correct.
In projects that span many days or weeks, task planning and schedule planning will be a critical issue. First you estimate size and time required (task planning), then make a schedule. The schedule will allocate already estimated tasks to real resources. The schedule tracking is so important, and a corrective action is necessary once a plan slip is detected.

PSP2: Personal Quality Management:
At this step, we already have a very good data about our defects, we analyze defects carefully and devise several approaches to minimize them:

Reviews:
Using structured design review and code review that is based on a checklist, we can greatly reduce defects even before the first compilation and test.
In order to improve the review effectiveness, a peer review is introduced. As we know, we get used of our mistakes, so that we no longer see them. Other minds/eyes will easily detect many of these defects.

Design process:
Through the focus on how to verify the completeness of a design, not necessarily how the design it self is made, verifying the design completeness will eliminate a large source of defects. Actually design completeness check can be done on many phases, like requirements; sure it will be ideal to have requirements completeness criteria before development.

PSP3: A Cyclic Personal Process:
Using PSP2 is perfect in small scale projects, but what if you have a large project? The idea is to divide the project into many PSP2 projects, so each cycle of development is based on high quality previous cycles. If the previous PSP2 cycles are badly done, the test will be a complex task, so we focus on doing PSP2 completely in each cycle.

Tool Support, the PSP Dashboard:
Of course tool support will help us to make following the process easier, I tried to use process dashboard as advised by our instructor Dan Roy, and find it helpful. I encourage every trained PSP to use it, however I think it will be complex and unintelligible to anyone who is not familiar with the PSP through formal training or at least with the help of a formal PSP programmer.
Finally, we started to use PSP in-house, but we still have no concrete experience until now, I hope that anyone who would have that experience to share it with us.

References and additional resources:

• The Complete PSP Book: A Discipline for Software Engineering by Watts S. Humphery
• The SEI PSP page:http://www.sei.cmu.edu/tsp/psp.html
• PSP Body of Knowledge:http://www.sei.cmu.edu/tsp/psp/bok/index.html
• PSP Dashboard at http://processdash.sourceforge.net/overview.html