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

PSP2: Personal Quality Management Process PSP2 adds review tech-
niques to PSP1 to help the software professional find defects early when
they are least expensive to fix. It comprises gathering and analyzing the de-
fects found in compile and test of the software professional's earlier pro-
grams. With these data, one can establish review checklists and make one's
own process quality assessments. PSP2 addresses the design process in a
nontraditional way. Here, PSP does not tell a software professional how to
design but rather how to complete a design. PSP2 establishes design com-
pleteness criteria and examines various design verification and consistency
techniques.
PSP3: A Cyclic Personal Process There are times when a program gets bigger
[e.g., a program of 10,000 lines of code (LOCs)]. This type of a program is
too big to write, debug, and review using PSP2. In that case, instead of PSP2,
use the abstraction principle embodied in PSP3. The PSP3 is an example of
a large-scale personal process. The strategy is to subdivide a larger program
into PSP2-sized pieces (a few thousand LOCs, KLOCs). The first build is a
base module or kernel that is enhanced in iterative cycles. In each cycle, a
complete PSP2 is performed, including design, code, compile, and test. Each
enhancement builds on the previously completed increments, so PSP3 is suitable
for programs of up to several thousand LOCs (Humphrey, 1997). Its strategy is
to use a cyclic process. Each cycle is progressively unit tested and integrated,
and at the end, you have the integrated, complete program ready for system
integration or system test (Kristinn et al., 2004).
PSP3: A Cyclical Personal Process PSP3 starts with a requirements and plan-
ning step that produces a conceptual design for the overall system, estimates its
size, and plans the development work (Kristinn et al., 2004). In the high-level
design, the product's natural division is identified and a cyclic strategy is de-
vised. After a high-level design review, then cyclic development takes place. A
good rule of thumb is to keep each cycle between 100 and 300 lines of new
and changed source code (Kristinn et al., 2004). In cyclic development, the
specifications for the current cycle are established. Each cycle essentially is a
PSP2 process that produces a part of the product. Because each cycle is the
foundation for the next, the review and tests within a cycle must be as complete
as possible. Scalability is preserved as long as incremental development (cycle)
is self-contained and defect free. Thus, thorough design reviews and compre-
hensive tests are essential parts of the cyclic development process (Kristinn
et al., 2004). In cyclic testing, the first test will generally start with a clean
slate. Each subsequent cycle then adds functions and progressively integrates
them into the previously tested product. After the final cycle, the entire program
would be completely unit and integration tests. This PSP3 designed software
is now ready for system test or for integration into a larger system. Figure
10.3 shows the evolution of PSP processes from PSP0 to PSP3, whereas Fig-
ure 10.4 shows evolution within each of the PSP stages and its final evolution
to PSP3.