Frontier Journal       

Exclusive Frontier Coverage on Technology and Business Issues in High-tech Industry              Vol. 3 No. 12 December 2006

As software becomes a progressively larger part of all systems, sound software-development methods should be more widely adopted. Unfortunately the software community has been slow to learn from hardware groups and hardware groups have been equally slow to learn and adopt sound software methods. Many important advancements in science and engineering come from other fields. For example, the software community ultimately did adopt sound project estimating, planning, and tracking methods from their hardware brethren. Even though these methods had been widely practiced in hardware development, it was a long time before they were generally used by software groups.

My experience with this problem started at IBM some 40 years ago. The OS/360 system-development project was in serious trouble and new management was brought in. Fortunately, some of these new managers had also worked in hardware and systems development and understood the importance of planning. In only a few months, this critical OS/360 project started delivering product releases on schedule, and they didn¨t miss a single commitment for over two years. While this may seem like a modest step to most experienced hardware developers, it was a non-trivial achievement. The OS/360 development project involved several thousand developers distributed over most of IBM¨s then 15 software development laboratories in the US and Europe.

Even though the IBM software community generally adopted sound engineering planning and management methods over 30 years ago, the rest of industry did not start using them until the Software Engineering Institute (SEI) began to introduce the CMM in 1987. Now, standard estimating, planning, and tracking methods are widely used in the better software organizations.

What is most disturbing is that the reverse problem is true today. The hardware folks are not learning from their software brethren. Many software projects involve large numbers of developers all designing, enhancing, and repairing the same code. Large-scale software-development groups have learned through painful experience that rigorous change control and disciplined configuration management are essential. During my days at IBM, I was surprised at how long it took for the hardware community to adopt these well-proven software practices to control microcode development, which is essentially software work.

While software change-control and configuration-management methods have and are being more widely adopted by the more progressive hardware shops, these hardware groups have largely ignored some of the newest advances in teamworking methods and software quality management. These newer methods are embodied in something called the Team Software Process (TSP) [Humphrey 2002, 2006]. Even though the TSP name might imply that these methods would only work for software, that is not the case. Two hardware design teams have used the TSP to design nuclear reactors, and one systems-engineering team is using it to design enhancements for a Navy aircraft. None of these teams have any software engineering members.

These methods are equally effective for both hardware and software groups because they are based on a set of principles that apply to all types of development work. These TSP principles are as follows.

， The performance of a development organization is determined by the performance of its development projects.

， The performance of a development project is determined by the performance of its development teams.

， The performance of a development team is determined by the performance of its members.

， The performance of the development team members is determined by the processes and practices they use in their personal work.

， Unless developers use defined and measured practices, they will not be able to significantly improve their performance.

The SEI has defined a family of methods and a way to teach these methods to developers and their teams. These methods are explained in several books, but the principles are straightforward [Humphrey 2002, 2005, 2006]. In summary, the TSP practices are as follows. The teams and team members must know how to define and improve measurable and operationally useful processes.

， The teams and team members must define the processes they will use.

， The team members must follow these defined processes when they do their work.

， The team members must measure their processes as they work.

， The teams and team members must make their own plans.

， The team members must regularly track and report on their own work to their teams.

， The teams must regularly track and report on their work to management.

， The teams and team members must consistently measure and manage the quality of their work.

， The teams and team members regularly analyze their process data and establish improvement plans.

While the TSP methods could help all kinds of development teams, hardware groups that do a lot of programming work would find them particularly helpful. By introducing the TSP, software groups generally improve productivity by over 70%, improve project predictability and schedule performance, and dramatically reduce testing time. Typical test-time reductions are from about 40% of the project schedule to under 10%. Figure 1 shows the large test-time savings achieved by one TSP project.

Based on several years of work with hundreds of development teams in dozens of organizations, we now know that the TSP can help teams consistently deliver quality products on schedule and for their planned costs [Davis 2003, McAndrews 2000]. It can also help development organizations meet the increasing challenges posed by the growing size and complexity of modern systems-development projects.

References

[Davis 2003] N. Davis and J. Mullaney, ＾Team Software Process (TSP) in Practice,￣ SEI Technical Report CMU/SEI-2003-TR-014, September 2003. [Humphrey 2002] W. S. Humphrey, Winning with Software: an Executive Strategy. Reading, MA: Addison-Wesley, 2002. [Humphrey 2005] W. S. Humphrey, PSP: A Self-Improvement Process for Software Engineers. Reading, MA: Addison-Wesley, 2005. [Humphrey 2006] W. S. Humphrey, TSP: Leading a Development Team, Reading, MA: Addison-Wesley, 2006. [McAndrews 2000] Donald R. McAndrews, ＾The Team Software Process (TSP): An Overview and Preliminary Results of Using Disciplined Practices,￣ Technical Report CMU/SEI-2000-TR-015, ESC-TR-2000-105.