Background

What is the PSP(SM)

The Personal Software Process(SM), created by Watts Humphrey of the Software Engineering Institute, is described in the books A Discipline for Software Engineering. Engineers using the PSP to develop software follow defined processes and collect detailed metrics on the time required to produce a product, the defects that were injected and removed at various stages in development, and the size of the finished product.

These metrics are then analyzed using statistical methods, enabling engineers to produce highly accurate estimates based on historical data, track progress and quality of a project in progress, predict schedule impacts, and predict the quality of a finished software product. The PSP encourages engineers to quantitatively determine ways to improve their process.

For more information on the PSP, see the official PSP website, maintained by Carnegie Mellon University.

What is the TSP(SM)?

The Team Software Process(SM), also created by Watts Humphrey, is a process framework for teams of PSP-trained engineers. The TSP scales well and can be used by teams of 3 to 20 people to develop software products of significant size and complexity.

Teams of engineers using both the PSP and the TSP to develop software have consistently observed remarkable improvements in their work:

  • End-to-end productivity improvements of 20% – 150%
  • 99% reductions in system test defects, and virtually defect-free released software.
  • Schedule estimates accurate to within 10% (4% error on average)

For more information on the TSP, see the official TSP website, maintained by Carnegie Mellon University.

Why build a tool?

Both the PSP and the TSP require the collection and analysis of metrics at a very fine-grained level. Further, TSP requires teams to roll-up individual metrics to produce team metrics. Once data are collected at this level, statistical analyses of the data permit remarkable planning, tracking, prediction, and control of software products and projects.

These metrics collection and analysis processes, however, are not trivial. In any real-world project, tool support for the PSP and TSP become important considerations. Although studies have demonstrated that people can maintain their productivity when using the PSP without tool support, the “frustration factor” inherent with such an approach tries the patience of all but the most disciplined engineers, making PSP behaviors difficult to sustain.

Ideally, PSP/TSP practitioners would like to have a support tool that:

  • Allows data at the personal level to be collected quickly and easily, with minimal frustration.
  • Can be integrated with existing development environments and project management tools.
  • Allows individuals to collaborate on the execution of a process (even if they are geographically distributed).
  • Allows data at the individual level to be rolled up to produce team-level or organizational-level metrics.
  • Protects the privacy of individuals, and prevents unauthorized people from seeing or using their data.
  • Supports powerful analyses of data at the individual, team, organizational, and enterprise levels, and allows existing (external) applications to access the data (while still maintaining the security mentioned above).
  • Supports arbitrary processes (including processes that have yet to be written), and arbitrary new process tools.

This initiative aims to develop an open-source tool to meet all of these needs.


Personal Software Process(SM), PSP(SM), Team Software Process(SM), and TSP(SM) are service marks of Carnegie Mellon University. The open source team that writes the Process Dashboard is not affiliated with Carnegie Mellon University.

On-the-job use of the Process Dashboard is not intended to replace formal PSP training or TSP coaching. Engineers interested in using the PSP should complete a PSP training course. Teams interested in using the TSP should contact the SEI or an SEI Partner for TSP support.