How does the TSP address Quality?

“The primary focus of TSP team members is on producing high quality components and products”.³ The TSP leverages defect prevention methods and early defect removal methods. The strategy is to inject fewer defects during development and to find and fix the remaining defects earlier and much more effectively prior to software system test.

The TSP recognizes that software development is intellectual work done by people who, because they are human, consistently inject defects as they do their work. The TSP quality planning process takes this into consideration and develops an estimate of the number of defects that will be injected and builds a plan to remove those defects.

Many organizations assume that the software system test team will find several defects during their testing. This can lead to a very time-consuming and expensive testing phase where it can be very difficult to determine when the product will be ready.

One of the key philosophical differences is that the TSP attempts to remove the vast majority, if not all, of the defects prior to software system testing. When a group is challenged with a goal of “Near-Zero defects delivered to system test”, they look for a way to accomplish this. This results in significantly fewer defects found in system test and shorter system test durations. The TSP provides the skill training and essential framework enabling organizations to achieve such superior software quality performance.

Another essential element of the TSP planning is that the plan includes all of the early defect removal practices in it and allocates the appropriate amount of time to perform those activities effectively. Many organizations build schedules that include the development activities of requirements, design, and code but often times leave it up to the developers to “find time” to peer review these work products.

Microsoft IT has achieved significant quality improvements using the TSP quality practices. The number of defects in System Test was reduced from 473 found in Version 2.4 down to 10 found in Version 2.5 (Figure 6). Defects found in User Acceptance Test were reduced from 153 down to 3.

Doesn’t this approach take longer?

The simple answer is no. Correctly using the TSP approach gives you the quality and schedule predictability benefits while reducing the amount of expensive rework typically experienced at the end of the lifecycle. It is human nature to quickly jump to the conclusion that if you add more process steps to your current process, things will take longer. This actually does occur in many of our day-to-day activities. The opposite happens with the TSP.

With TSP, defects are removed earlier in the process at a much lower cost than removing them later in the process. Defects removed by early reviews and inspections take a fraction of the time to find and fix as compared to removing them in system test (Figure 6).

Intuit has achieved significant productivity improvements through the use of TSP (Figure 7). Doing it right in the first place takes less time.

Why aren’t more companies using the TSP?

It appears that the use of the TSP is very limited in the medical device arena. The TSP offers higher quality, better schedule predictability, and increased productivity – so why aren’t more people using it? The reasons are not so clear.

Informal shows-of-hands at conferences, where TSP presentations have been given, show very little awareness of the TSP by the medical device community. One of the purposes of this series of articles is to raise awareness of the TSP as a leading software development method available for the medical device community to leverage, and to encourage people to take a look.

Some organizations already have process or quality improvement initiatives in progress and are reluctant to move away from these efforts. TSP is very flexible and can easily be integrated into and supplement existing efforts.

It is human nature to assume that more structured processes with more steps might take longer. As discussed earlier, this is typically not true at all with TSP teams (Figure 7).

TSP/PSP and Agile

Some organizations have implemented Agile methods. TSP/PSP and Agile can be a strong combination. According to McHale, “When you investigate the details, you will see that these two methods at least, Agile and PSP/TSP, are not the options of an either-or choice, but compatible practices that have produced some remarkable results.” “What they may not know (yet) is that Agile co-exists quite comfortably – one might even say “thrives” – when applied with PSP/TSP”.⁶ With the recent release of the “Guidance on the use of AGILE practices in the development of medical device software,” this could be the perfect marriage.⁷

Is the TSP for you?

• How well do your teams produce reliable schedules?
• What are your current levels of defects found in software system test?
• How many defects do your customers report?
• How many customer-reported defects result in adverse events reportable to the Food and Drug Administration?
• What would your world be like if you:
  • Could reliably estimate the completion date of a project?
  • Could significantly reduce the number of defects found in software system test?
  • Could significantly reduce the number of defects found by your customers?
• What would this ultimately mean to patient safety?

References

1. Jones, C. (2010). Software Engineering Best Practices: Lessons from Successful Projects in the Top Companies, McGraw-Hill.
2. National Medal of Technology Winner Watts Humphrey (2010). 1927-2010 (Software Engineering Institute, Carnegie Mellon University, University News Items, October 28, 2010).
3. Humphrey, W.S., Chick, T.A., Nichols, W., and Pomeroy-Huff, M. (July 2010) Team Software Process (TSP) Body of Knowledge. SEI Technical Report CMU/SEI-2010-TR-020.
4. Over, J. (2010). Team Software Process, (Software Engineering Institute, Carnegie Mellon University).
5. Over, J. (2010). Introduction to the Team Software Process, (Software Engineering Institute, Carnegie Mellon University).
6. McHale, J. (2010). Capers Jones’s New Book Ranks PSP/TSP and Agile as Top Method. (Carnegie Mellon University).
7. Guidance on the use of AGILE practices in the development of medical device software. (2012).  Association for the Advancement of Medical Instrumentation, Arlington: Virginia.

Additional Resources

Humphrey, W.S. and Over, J.W. (2011). Leadership, Teamwork, and Trust: Building a Competitive Software Capability. Addison-Wesley.

Special permission to reproduce portions of the “Team Software Process” ©2010 and the “Introduction to the Team Software Process” ©2010 by Carnegie Mellon University, has been granted by the Software Engineering Institute. The Personal Software Process(SM), PSP(SM), Team Software Process(SM), and TSP(SM) are service marks of Carnegie Mellon University.