DESIGN FOR SIX SIGMA (DFSS) TEAM AND TEAM SOFTWARE PROCESS (TSP) - Software Design for Six-Sigma: A Roadmap for Excellence - page 240

In this chapter we will explore further the Personal Software Process and the Team
Software Process highlighting interfaces with DFSS practices and exploring areas
where DFSS can add value through a deployment example.

10.2 THE PERSONAL SOFTWARE PROCESS (PSP)

DFSS teams can use the TSP to apply integrated team concepts to the development
of software-intensive systems. The PSP is the building block of TSP. The PSP is
a personal process for developing software or for doing any other defined activity.
The PSP includes defined steps, forms, and standards. It provides a measurement
and analysis framework for characterizing and managing a software professional's
personal work. It also is defined as a procedure that helps to improve personal
performance (Humphrey, 1997). A stable, mature PSP allows teams to estimate and
plan work, meet commitments, and resist unreasonable commitment pressures. Using
the PSP process, the current performance of an individual could be understood and
could be equipped better to improve the capability (Humphrey, 1997).
The PSP process is designed for individual use. It is based on scaled-down indus-
trial software practice. The PSP process demonstrates the value of using a defined and
measured process. It helps the individual and the organization meet the increasing
demands for high quality and timely delivery. It is based on the following principles
(Humphrey, 1997):

PSP Principles 1: The quality of a software system is determined by the quality
of its worst developed component. The quality of a software component is
governed by the quality of the process used to develop it. The key to quality is
the individual developer's skill, commitment, and personal process discipline.
PSP Principles 2: As a software professional, one is responsible for one's
personal process. And should measure, track, and analyze one's work. Lessons
learned from the performance variations should be incorporated into the
personal practices.

The PSP is summarized in the following phases:

PSP0: Process Flow PSP0 should be the process that is used to write software.
If there is no regular process, then PSP0 should be used to design, code, compile,
and test phases done in whatever way one feels is most appropriate. Figure 10.1
shows the PSP0 process flow.
The first step in the PSP0 is to establish a baseline that includes some basic
measurements and a reporting format. The baseline provides a consistent basis
for measuring progress and a defined foundation on which to improve.
PSP0 critical-to-satisfaction measures include:
The time spent per phase—Time Recording Log
The defects found per phase—Defect Recording Log