Complete
Recommended and additional and supplementary reading materials
include:
The Team Software ProcessSM (TSPSM) (CMU/SEI-2000-TR-023).
The Team Software ProcessSM (TSPSM): An Overview and
Preliminary Results of Using Disciplined Practices (CMU/SEI-2000-TR-015).
Building High Performance Teams Using Team Software
ProcessSM (TSPSM) and Personal Software
ProcessSM (PSPSM) - Home Page http://www.sei.cmu.edu/tsp
Organizations that develop software recognize that controlling
their software processes significantly affects their ability to be
successful in business. However, organizations still struggle when
trying to apply disciplined methods in software process.
Historically, this struggle has resulted from a lack of operational
procedures for use by teams and individuals in developing software in
a disciplined fashion. The Team Software Process (TSP)1
was designed to provide both a strategy and a set of operational
procedures for using disciplined software process methods at the
individual and team levels.
Watts Humphrey developed the Personal Software Process
(PSP)2 and the TSP as a follow-up to his work with the
Capability Maturity Model (CMM)3. The PSP is a defined
process for individuals [Humphrey
95] that operationally enacts the concepts and principles
prescribed by the CMM. It is the foundation from which the TSP was
developed for teams. The TSP represents an operational process for
teams that may be used as a strategy for implementing the CMM
framework on teams.
The TSP is a fully defined and measured process that teams can use
to plan their work, execute their plans, and continuously improve
their software development processes. The TSP process is defined in a
series of process scripts that describe all aspects of project
planning and product development. The process includes team role
definitions, defined measures, and the postmortem process. Teams
using the TSP practice those processes areas that are prescribed by
the CMM Maturity Level 5. Their team processes are repeatable,
defined, measured, and managed quantitatively. However, it should be
noted that the TSP can and has been used successfully by
organizations at levels 1, 2, 3, and 5. [McAndrews
00] In fact, the use of the TSP may even help low maturity
organizations to have teams quickly start behaving like a level 5
organization. Also, using the TSP will help the organization
recognize how the process areas operate at each maturity level.
Within the TSP scripts, there are operational definitions of the
measures to be used as part of the process. These measures include
basic size (thousands of lines of code [KLOC]), time (minutes
and hours), and quality (defects), as well as derived measures for
productivity (KLOC/hour), process yield (percentage of defects
removed before a particular process phase), and defect densities
(defects/KLOC) of finished products. The process establishes how
these measures are defined, estimated, collected, reported, and
analyzed. The process also makes use of the team's historical data,
as well as industry planning and quality guidelines. Tools are
available to help facilitate the TSP.
A typical software engineering team spends a great deal of time
and creative energy struggling with questions concerning goals, team
roles, quality, development, management, and multiple other issues.
In fact, a team's ability to deal with these issues can affect their
success. The TSP provides explicit guidance on how to answer these
questions and accomplish the team's objectives. The TSP shows
engineering teams how to produce quality products for planned costs
and on aggressive schedules. It achieves this by showing teams how to
manage their work and by making them owners of their plans and
processes. The TSP also helps to accelerate software process
improvement.
The TSP has been used with software-only teams and with mixed
teams composed of hardware, software, systems, and test
professionals. The TSP can be used on teams that typically range in
size from 2 to about 150 individuals. The TSP has been used for both
new development and enhancement, and on applications ranging from
commercial software to embedded real-time systems. It is also
applicable in maintenance and support environments.
Since the TSP technology is new, it has not yet gained widespread
use. It also takes time to obtain data on projects because software
projects in industry typically take months or years to complete.
Furthermore, because of competition in the software industry, and the
resulting sensitivity about sharing data, it can be difficult to
persuade organizations to release their data to the public and to
participate in studies such as this. Consequently, there are limited
data at this time on TSP application. However, there have been a few
published results, and they are compelling. [McAndrews
00]
Introducing the TSP into engineering organizations is the
principal focus of the TSP effort at the Software Engineering
Institute (SEI). The TSP was designed for engineering teams, and its
introduction has been initially targeted at teams developing
software-intensive products. To support use by industrial teams that
include other than software specialties, the SEI has developed an
introductory PSP course for professionals who are not software
proficient. It has also introduced a series of training and
qualification programs so that organizations can obtain their own PSP
instructors. In addition, the SEI provides TSP coach training so that
organizations can launch and coach their own TSP teams. The SEI has
established relationships with a number of transition partners who
are qualified to teach the PSP and to coach TSP teams.
The TSP requires careful introduction strategies that include PSP
training. The initial reason for developing the TSP was to provide an
environment where PSP-trained engineers would find it natural to use
disciplined methods. PSP training by itself had not been found
sufficient to get engineers to consistently use the methods
[Ferguson
97]. There are several reasons why this is the case. First,
without training, managers generally do not understand the PSP
methods or appreciate their benefits. They then often object to their
engineers spending time on planning, doing personal reviews, or
gathering and analyzing data. Second, disciplined work is hard to do
even with support and coaching. Without such help, long periods of
sustained disciplined work are almost impossible. The initial
motivation for the TSP design was to address these problems.
[Humphrey
00]
The TSP is a stand-alone technology used to produce effective
teams. It can be used independent of, and in conjunction with,
various development methodologies. TSP, like PSP, is complementary to
organizational software process improvements efforts based on the CMM
for Software [Paulk
95]. The CMM is an organization-focused process-improvement
framework that provides a disciplined, efficient organizational
environment for software engineering work. The PSP equips engineers
with the personal skills and methods to do high-quality work and
participate in organizational process improvement. Of the 18 key
process areas in the CMM, PSP covers 12 of the 18, and the TSP covers
16.
The TSP is being developed for a wider range of project
applications, including large multi-teams, geographically distributed
teams, and functional teams.
This technology is classified under the following categories.
Select a category for a list of related topics.
|
[Ferguson 97]
|
Ferguson, P.; Humphrey, W. S.;
Khajenoori, S.; Macke, S.; and Matvya, A. "Introducing the
Personal Software Process: Three Industry Case Studies."
IEEE Computer 30 (May 1997): 24-31.
|
|
[Ferguson 99]
|
Ferguson, P.; Leman, G.; Perini, P.;
Renner, S.; and Seshagiri, G. Software Process Improvement
Works! Advanced Information Services Inc.
(CMU/SEI-99-TR-027, ADA371804). Pittsburgh, Pa.: Software
Engineering Institute, Carnegie Mellon University,
1999.
|
|
[Humphrey 95]
|
Humphrey, Watts. A Discipline for
Software Engineering. Reading, MA: Addison-Wesley
Publishing Company, 1995.
|
|
[Humphrey 00]
|
Humphrey, Watts. The Team Software
ProcessSM (TSPSM)
(CMU/SEI-2000-TR-023).
Pittsburgh, Pa.: Software Engineering Institute, Carnegie
Mellon University, 2000.
|
|
[McAndrews 00]
|
McAndrews, Donald R. The Team Software
ProcessSM (TSPSM): An Overview and Preliminary
Results of Using Disciplined Practices (CMU/SEI-2000-TR-015).
Pittsburgh, Pa.: Software Engineering Institute, Carnegie
Mellon University, 2000.
|
|
[Musson 99]
|
Musson, R. "The Results of Using the TSP
on Small Teams." Proceedings of the 1999 Software
Engineering Symposium. (Pittsburgh, Pa., Software
Engineering Institute, September 1999).
|
|
[Paulk 95]
|
Paulk, Mark C. The Capability
Maturity Model: Guidelines for Improving the Software
Process. Reading, MA: Addison-Wesley Publishing
Company, 1995.
|
|
[Vu 00]
|
Vu, J. "Process Improvement in the Boeing
Company." Proceedings of the 2000 Software Engineering
Process Group (SEPG) Conference. Seattle, WA, Software
Engineering Process Group, March 2000.
|
|
[Webb 99]
|
Webb, D. and Humphrey, W. Using the TSP
on the TaskView Project. Cross Talk: The Journal of
Defense Software Engineering 12, 2 (February 1999).
|
|
[Webb 00]
|
Webb, D. Managing Risk with the Team
Software Process. Cross Talk: The Journal of Defense
Software Engineering 13, 6 (June 2000).
|
Don McAndrews, SEI
Lauren Heinz, SEI
Watts Humphrey, SEI
1 May 2001 (original)
1 Personal Software Process and PSP are
service marks of Carnegie Mellon University.
2 Capability Maturity Model and CMM are
service marks of Carnegie Mellon University.
3 Team Software Process and TSP are
service marks of Carnegie Mellon University.
