A Technical History of the SEI

The principal motivator for the development of the TSP was the conviction that engineering teams
could do extraordinary work, but only if they were properly formed, suitably trained, staffed with
skilled members, and effectively led. The objective of the TSP is to build and guide such teams.
The TSP software development cycle begins with the launch, a planning process led by a specially
trained coach. The launch is designed to begin the team-building process, and during this
time teams and managers establish goals, define team roles, assess risks, estimate effort, allocate
tasks, and produce a team plan. During an execution
phase, developers track planned and actual effort, schedule,
and defects, meeting regularly (usually weekly) to
report status and revise plans. An important element of
the TSP is the measurement framework. Engineers using
the TSP collect three basic measures: size, time, and defects.
They use many other measures that are derived
from these three basic measures. The measurement
framework consolidates individual data into a team perspective.
The data collected are analyzed weekly by the
team to understand project status against schedule and
quality goals. A development cycle ends with a post
mortem to assess performance, revise planning parameters,
and capture lessons learned for process improvement.
The Consequence: Improved Quality at
the Individual and Team Levels
Experience with the TSP has shown that it improves the
quality and productivity of engineering teams while helping
them to more precisely meet cost and schedule commitments.
A study undertaken in 2003 demonstrated that
teams using the TSP were able to meet critical business
needs by delivering essentially defect-free software on
schedule and with better productivity. While industry data
indicated that over half of all software projects were more
than 100 percent late or were cancelled, the 20 TSP projects
in 13 organizations included in the study delivered
their products an average of 6 percent later than they had
planned. These TSP teams also improved their productivity
by an average of 78 percent. The teams met their
schedules while producing products that had 10 to 100
times fewer defects than typical software products. They
delivered software products with average quality levels of
5.2 sigma, or 60 defects per million parts (lines of code).
In several instances, the products delivered were defect
free [Davis 2003].
The View from Others
Our schedule reliability is now +/-
10 percent from –50/+200 percent
and our defect density at the team
level has been reduced by over 50
percent.
One of my first projects as an embedded
systems programmer finished
on the day we planned to finish
six months earlier. I attribute
the success to planning at a better
granularity and making full use of
the earned value tracking. The day
we got 100 percent earned value
was the day we planned to get 100
percent value, and we as a team
celebrated like we had won a basketball
game.
Multiple projects in our organization
have been able to keep within
their time schedules (+/- three
weeks) over a six-month span. This
is something we [had] not been
able to accomplish in the past.
This is one of the reasons that
management is very happy with
the TSP process.
These quotes are from a team that
attended the PSP for Engineers
course and used PSP in its organization
to meet TSP goals [Davis
2003].
CMU/SEI-2016-SR-027 | SOFTWARE ENGINEERING INSTITUTE | CARNEGIE MELLON UNIVERSITY 145
Distribution Statement A: Approved for Public Release; Distribution is Unlimited.