A Technical History of the SEI

Personal Software Process and Team Software Process
The Challenge: Improving Software Quality During Development
As the use of computers and the development of software grew in the 1960s and 1970s, it was accompanied
by growing pains: many projects failed to deliver quality products within a predictable
time or budget and project failure was common [Humphrey 1989]. In response to a request from
the Department of Defense, the SEI led the development of the Capability Maturity Model
(CMM), which captured organizational best practices for software development [Paulk 1993].
Maturity relates to the degree of formality and optimization of processes, from ad hoc practices, to
formally defined steps, to managed result metrics, to active optimization of the processes. When
the model was applied to an existing organization’s software development processes, it provided
an effective approach toward improving them.
Although the CMM began to see widespread adoption, some problems remained. An early misperception
of the CMM was that it did not apply to small organizations or projects. Another issue
was that the CMM told people what to do, it did not help them understand how, and software development
practice was nearer a craft than an engineering discipline. Most finished software products
could be made to work, but only after extensive testing and repair. And as software programs
grew larger and larger, the difficulty of finding and fixing problems also began to increase exponentially.
A Solution: Personal Software Process and Team Software Process
Because he believed software quality starts with the individual engineer, an SEI Fellow decided to
apply the underlying principles of the CMM to the software development practices of a single developer.
From 1989 to 1993, he wrote more than 60 programs and more than 25,000 lines of code
using CMM practices and concluded that the management principles embodied in the CMM were
just as applicable to individual software engineers. The resulting process was the Personal Software
Process (PSP) [Humphrey 1994].
The PSP is a structured software development process that helps software engineers understand
and improve their performance by using a disciplined, data-driven procedure. It includes effective
defect management techniques and comprehensive planning, tracking, and analysis methods. PSP
training follows an evolutionary improvement approach: engineers learning to integrate the PSP
into their processes beginning at the first level and progressing in process maturity to the final
level. Each level has detailed scripts, checklists, and templates to guide engineers through required
steps that help individual engineers improve their own personal software process. Properly
used, the PSP provides the historical data engineers need to better make and meet commitments.
It soon became obvious that, while excellent results were possible using the PSP, it was almost
impossible to maintain the discipline required for PSP practices if the surrounding environment
did not encourage and demand them. Systems development is a team activity, and the effectiveness
of the team largely determines the quality of the engineering. A process for the smallest operational
unit in most organizations, the project team, called Team Software Process (TSP) was designed
in 1996 [Humphrey 2000].
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 144
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.