Introduction to the Team Software Process(sm)

About

Features

Watts S. Humphrey, a widely respected authority on software process improvement, and a long-time senior manager of software development at IBM, is a Fellow at the Software Engineering Institute at Carnegie Mellon University.



Description

• Copyright 2000
• Dimensions: 6-1/4" x 9-1/4"
• Pages: 496
• Edition: 1st

• Book
• ISBN-10: 0-201-47719-X
• ISBN-13: 978-0-201-47719-1
• eBook (Watermarked)
• ISBN-10: 0-7686-8465-X
• ISBN-13: 978-0-7686-8465-0

Watts Humphrey is the visionary behind the Capability Maturity Model (CMM)(R) and the Personal Software Process (PSP) (sm). The CMM contains a framework for software process improvement at the organizational level. The PSP builds the self-discipline needed for individual programmers to work efficiently and effectively. The author's new Team Software Process (TSP) (sm) details methods to guide the formation of software development teams, to motivate their work, and to enhance their productivity.

This book describes an introductory version of TSP, ideal for smaller projects but also useful for learning basic techniques and procedures that apply to other development projects. Methods presented include:

• how to establish roles;
• how to conceive, design, and plan a project;
• how to track and report on progress.

The book walks readers through a complete development cycle, illustrating:

• how best to use the talents at hand;
• how to formulate well-defined goals;
• how to coordinate activities for maximum progress;
• how to promote effective communication;
• how to alleviate many of the conflicts that undermine teamwork.

Team members should not have to expend valuable time and energy reinventing ways to organize and run their team. By following a proven process, the team will more quickly be able to focus on the successful completion of the project itself. To help a team course apply these methods, the book provides two project exercises, with prescribed development goals and team roles.



Downloads

Support File(s)

TSPi materials are available at http://www.sei.cmu.edu/tsp/tspi



Sample Content

Table of Contents

(Each chapter, except Chapter 18, concludes with a Summary.)

Preface.

I. INTRODUCTION.

1. TSPi Overview.

What Is TSPi?

TSPi Principles.

The TSPi Design.

TSPi Structure and Flow.

The TSPi Process.

The Textbook Structure and Flow.

2. The Logic of the Team Software Process.

Why Projects Fail.

Common Team Problems.

What Is a Team?

Building Effective Teams.

How Teams Develop.

How TSPi Builds Teams.

References.

II. THE TSPI PROCESS.

3. Launching a Team Project.

Why Conduct a Team Launch?

Team Goals.

Team-Member Goals.

The Role Goals.

The TSPi Launch Scripts.

4. The Development Strategy.

Planning First.

What Is a Strategy?

The Conceptual Design.

Risk Management.

A Reuse Strategy.

The Strategy Scripts.

5. The Development Plan.

The Need for Planning.

The TSPi Planning Process.

The TSPi Support Tool.

The Development Plan Scripts.

Tracking the Work.

The Quality Plan.

Reference.

6. Defining the Requirements.

What Are Requirements?

Why We Need Requirements.

Requirements Changes.

The Software Requirements Specification.

The TSPi Requirements Scripts.

References.

7. Designing with Teams.

Design Principles.

Designing in Teams.

Design Standards.

Designing for Reuse.

Designing for Usability.

Designing for Testability.

Design Reviews and Inspections.

The TSPi Design Scripts.

References.

8. Product Implementation.

Design Completion Criteria.

Implementation Standards.

The Implementation Strategy.

Reviews and Inspections.

The IMP Scripts.

Reference.

9. Integration and System Testing.

Testing Principles.

The TSPi Testing Strategy.

The Build and Integration Strategy.

The System Test Strategy.

Test Planning.

Tracking and Measuring Testing.

Documentation.

The TSPi TEST Scripts.

References.

10. The Postmortem.

Why We Need a Postmortem.

What a Postmortem Can Do for You.

The Process Improvement Proposal.

The TSPi Postmortem Scripts.

Reference.

III. THE TEAM ROLES.

11. The Team Leader Role.

The Team Leader's Goals.

Helpful Team Leader Skills and Abilities.

The Team Leader's Principal Activities.

The Team Leader's Project Activities.

12. The Development Manager Role.

The Development Manager's Goals.

Helpful Development Manager Skills and Abilities.

The Development Manager's Principal Activities.

The Development Manager's Project Activities.

13. The Planning Manager Role.

The Planning Manager's Goals.

Helpful Planning Manager Skills and Abilities.

The Planning Manager's Principal Activities.

The Planning Manager's Project Activities.

14. The Quality/Process Manager Role.

The Quality/Process Manager's Goals.

Helpful Quality/Process Manager Skills and Abilities.

The Quality/Process Manager's Principal Activities.

The Quality/Process Manager's Project Activities.

References.

15. The Support Manager Role.

The Support Manager's Goals.

Helpful Support Manager Skills and Abilities.

The Support Manager's Principal Activities.

The Support Manager's Project Activities.

IV. USING THE TSPI.

16. Managing Yourself.

Being Responsible.

Striving for Defined Goals.

Living by Sound Principles.

Your Opinion of Yourself.

Your Opinion of Others.

Your Commitment to Excellence.

Reference.

17. Being on a Team.

The Jelled Team.

Teamwork Obligations.

Communication Among Team Members.

Making and Meeting Commitments.

Participation in the Team's Activities.

Team-building Obligations.

Accepting and Performing a Team Role.

Establishing and Striving to Meet Team Goals.

Building and Maintaining the Team.

References.

18. Teamwork.

Reference.

Appendices.
Appendix A. Need Statements for the TSPi Sample Exercises.

Purpose.

The Change Counter Functional Need Statement.

The Program Analyzer Functional Need Statement.

References.

Appendix B. Software Configuration Management.

The Software Configuration Management Problem.

Software Configuration Management Overview.

The SCM Plan.

The System Baseline.

Automating the SCM Process.

The Software Configuration Management Process.

Appendix C. Software Inspections.

What Are Inspections?

What Makes Inspections Effective?

Inspection Methods.

Inspection Data.

The Inspection Report: Form INS.

Estimating Remaining Defects.

The Importance of High Personal Yields.

Scheduling Inspections.

The TSPi Inspection Script.

References.

Appendix D. The TSPi Scripts.
Appendix E. Role Scripts.
Appendix F. TSPi Forms and Instructions.
Appendix G. The TSPi Standards and Specifications.
Index. 020147719XT04062001

Preface

This book is for students and engineers who have already learned and, preferably, applied the Personal Software Process (PSP)^SM. You may have learned the PSP in a graduate or senior-level course (1) or in an earlier introductory course (2). Alternatively, you may be a practicing engineer who seeks guidance on how to use the PSP in an industrial team environment. In any case, when you have learned the PSP, you have the background to use the methods and practices in this book.

After you have learned the PSP, you may need guidance on applying it to the many tasks of the software process. This is the principal role of the Team Software Process (TSP)^SM: to provide a framework for using sound engineering methods while developing software.

There is a great deal to say about teamwork, and this book covers the basic elements. TSPi (the introductory Team Software Process) introduces team concepts and walks you through the steps of building teams and working on a team. Note, however, that this text is designed for an introductory course and does not cover all the material that you will need to use the TSP for larger-scale industrial projects.

How TSPi Helps Engineers

This book teaches engineers about software development teamwork. TSPi provides a structured set of steps, shows engineers what to do at each step, and demonstrates how to connect these steps to produce a completed product. TSPi also provides two interesting and reasonably challenging project exercises. Each is at the same time small enough to be completed in a few weeks and large enough to simulate a typical small project. When capable engineers follow the guidance provided in this book, they will invariably produce a finished working product.

In the suggested TSPi strategy, teams develop a product in two or three cycles. In the first cycle, teams build a small working product kernel. With each succeeding cycle function is added to this base. This strategy demonstrates the benefits of using data from a prior project to plan a new project. Also, by taking new roles for each cycle, engineers will have two or three quite different experiences in just one project. After several development cycles, engineers will have had a broad exposure to teaming methods, and they are likely to continue using the TSPi methods on their own.

Why TSPi Courses Are Needed

Because project courses have proven to be effective in preparing students for software engineering careers, a growing number of universities now offer them. These courses are often oversubscribed. Students seek material that applies to their future jobs, and they see team courses as meeting this need. After graduation, students and employers report that software project courses are useful preparation for work in industry.

There is now a large body of experience with team project courses (3). Although many of these courses have been successful, three problems are common. First, the students often attempt projects that are too large. Second, they frequently concentrate on the product and ignore the process. Finally, one or more team members are disruptive. Although TSPi cannot prevent all these problems, it provides guidance on how to avoid or mitigate them.

To make effective use of curriculum time, team software courses should be carefully structured and based on proven project experience. Without a defined process or a structured team framework, engineers must figure out for themselves how to run their projects. Without this process and structure, these groups must learn team-building and teamwork basics through an often painful trial-and-error process. This is both expensive and unnecessary because teamwork principles are well known and straightforward.

TSPi guides engineers in effective teamwork methods. It does this by walking them through a team-building process and then using a measured and defined framework for developing products. Assuming that the engineers are PSP-trained, they can follow the TSPi scripts and use the TSPi support tool to plan and manage their work.4 Following TSPi makes engineers' projects much more efficient and permits them to concentrate on learning about software engineering rather than spend an excessive amount of time on team-building and team management issues.

TSPi provides defined team roles that are allocated among the team members. Each role specifies what is expected and when and how each task is to be done. When all team members know what they and everyone else should do, they are in a better position to work effectively as a team. If a team member does not do his or her job, the other team members will know it, and they can deal with the problem. When teams cannot solve interpersonal problems themselves, they are told to call on their instructor or manager for help. The Instructor's Guide for this book suggests methods for handling many common teamwork issues. When student team members have explicit roles and the role responsibilities are clearly defined and visible, instructors can provide fairer and more specific grades. Each student can then be rated on individual performance as well as on the overall team's results. Not only does this approach motivate better performance, but it is also a fairer way to grade team courses.

The Organization of This Book

This book is designed to lead teams through the TSPi process. Following the first two introductory chapters (Part I), the chapters in Part II walk teams through a complete development cycle. The text explains the process scripts and gives examples of the completed TSPi forms. Part III provides detailed descriptions of the TSPi team-member roles: team leader, development manager, planning manager, quality/process manager, and support manager. After reading the chapter on your personal role, you can use these TSPi role scripts for reference while working on the project.

At the start of the TSPi course, each student completes an INFO form (see Appendix F) describing his or her interests and background. The instructor uses this information to divide the class into five-engineer teams and to assign initial roles to the team members. If one or two teams have four or six members, the instructor must make some role adjustments. All the roles must be assigned, and each engineer should have at least one role. For a four-engineer team, the support manager role should be distributed among the team members. For a six-engineer team, the quality/process manager role should be split into two: the quality manager and the process manager.

With the teams selected and roles assigned, the teams start their projects and report on their progress. At the end of each development cycle, the engineers assess the team's overall performance as well as that of each individual role. With this information, the instructor can evaluate the work and better assign team-member roles for the next development cycle. If necessary, the instructor may make some team membership changes, but, unless there are serious problems, teams should be kept together throughout the course.

Using Standard, Predefined Problems

Although TSPi will work for almost any project, this book provides two standard, predefined problems that are designed to meet the needs of a wide variety of courses. Although there could be advantages to using actual customer problems, this practice is not recommended for three reasons. First, courses have firm and unvarying schedules. Although most customers will initially agree to a fixed time scale, few customers know how long it really takes to develop software. Also, because beginning engineers do not generally know how to manage projects on firm schedules, the chances of project failure are high. This problem is compounded by the fact that actual customer requirements are notoriously vague and unstable, leading to frequent changes and extensive delays.

The second reason to use a standard, predefined exercise is that a teamwork course should be designed to teach specific lessons. Although one goal of the project should be to build a working product, the principal course objective should be to demonstrate the benefits of using proven software engineering methods. With an actual customer problem, the first priority must be to satisfy the customer. As the requirements change or the customer takes time to answer questions, the work will slip. As the schedule gets compressed, teams often concentrate on finishing the product and ignore the process. Unfortunately, the principal lesson often learned from such courses is how not to develop software.

The third reason to use a standard, predefined problem is that it permits each team to compare its performance with that of other teams. With several implementations of the same problem, all the teams can participate in the class evaluations. Each team can describe its approach and answer questions about its design, implementation, and test choices. This process graphically shows the effectiveness of various development approaches and provides a body of reference data for evaluating future teams.

Although there are advantages to using standard predefined exercises, they do not expose students to some important issues. For example, without actual experience, it is hard to appreciate the confusion and imprecision of customer need statements. Struggling with vague and changing requirements is an important experience, but it can be taught best in a course that concentrates on the requirements process. The approach recommended here is to first teach effective teamwork and process methods and then, in later courses, focus on the complex issues of larger-scale development projects.

Suggestions for Instructors

This book can be used in several ways. The principal use is in a full one- or two-semester team course. In this configuration, TSPi is used to develop a single product such as either of the two described in Appendix A. A one-semester course would take two or three cycles, whereas a two-semester course would use three or more cycles to build a larger product or a full-function version of the Appendix A products. Depending on the scale of the job, the various process steps could be expanded or reduced. Three course options are shown in Figures P.1, P.2, and P.3.

For each development cycle in Figure P.1, the team plans and tracks its work and completes a full miniproject, including requirements, design, code, and test. At the end of each development cycle, the team assesses team and role performance, and the instructor reassigns the team roles. In a three-cycle project, the engineers gain experience with three essentially complete projects and three different team roles. They also have data from each cycle and can see how their experience from one cycle can be used for the next one.

This book can also be used for teamwork exercises in other courses. Small projects could be done in a single cycle of three to seven weeks. A short requirements cycle could take three or four weeks, whereas a design cycle would take four or five weeks. The shortest initial full development project would take six or seven weeks. Figure P.2 shows a several-week team project to develop a set of requirements in a requirements course. Similarly, a design project might be configured as in Figure P.3. The text can also be used for courses that run on a quarter system. Whereas the full three-cycle course takes 15 weeks, a two-cycle course can be done in 11 weeks, and a one-cycle development project would take 7 weeks.

---

Cycle Week	Cycle 1	Cycle 2	Cycle 3
1	Course introduction, review
2	Launch, strategy
3	Plan
4	Requirements
5	Design
6	Implementation
7	Test
8	Postmortem	Launch, strategy, plan
9	Requirements, design
10	Implementation, test
11	Postmortem	Launch, strategy, plan
12	Requirements, design
13	Implementation, test
14	Test, documentation
15	Postmortem and evaluation

---

FIGURE P.1 THE THREE-CYCLE TSPi COURSE

---

Cycle Week	Cycle 1
1	Launch, plan
2	Requirements
3	Requirements
4	Postmortem

---

FIGURE P.2 A SHORT TSPi REQUIREMENTS LIST

---

Cycle Week	Cycle 1
1	Launch, plan
2	Requirements
3	Design
4	Design
5	Postmortem

---

FIGURE P.3 A SHORT TSPi DESIGN PROJECT

---

In any of these course configurations, the standard TSPi scripts guide the students through forming their teams and planning and implementing their projects. Unless a team has already had experience with a full TSPi course, they will probably not complete any project cycle in less than three or four full weeks. The reason is that it takes time for new team members to learn the process and to figure out how to work together as a team. This is why the first TSPi cycle is planned for seven weeks even though the same work would take only four weeks in a subsequent cycle.

Preparation for This Course

The principal prerequisite for this course is completion of a full PSP course. This PSP course can be either a graduate or an introductory course. If the students took the PSP several semesters ago, they should have used the PSP in their intervening courses. If they have not, they will need a brief refresher lecture or two about PSP planning, data gathering, and quality management. Also, students who have little or no experience using the PSP will almost certainly need careful monitoring and support throughout the team course. Before attempting a team project, students should have a background in software design and software requirements. Exposure to configuration management, project management, and software testing is also helpful. The students must also be fluent in the programming language and the tools they will use.

Acknowledgments

In writing a book, I often become so immersed in the material that I find it hard to see many of the problems that could trouble first-time readers. This is the principal reason that I seek informed reviewers. I have been particularly fortunate with this book, both because many people were willing to help and because their broad range of backgrounds enabled them to make many helpful suggestions. I particularly appreciate the help and support of Susan Brilliant, Dan Burton, Bob Cannon, Audrey Dorofee, Pat Ferguson, Marsha Pomeroy Huff, Mark Klein, Susan Lisack, Rick Long, Steve Masters, Mark Paulk, Bill Peterson, Bill Pollack, Dan Roy, Jeff Schwalb, Girish Seshagiri, Steve Shook, Laurie Williams, Ralph Young, Dave Zacharias, and Sami Zahran. Julia Mullaney was a great help in combing through the manuscript to find problems and inconsistencies in the manuscript and text. I also wish to thank my brother Philip Humphrey for his continued support and informed comments on much of the teamwork material. I am also particularly indebted to Tom Hilburn and Iraj Hirmanpour at Embry Riddle Aeronautical University. Both of them have been long-term supporters of my PSP and TSP work. Tom has also taught team courses using the manuscript for this book. The data from his first course provided much of the material for the examples in the text.

As we at the Software Engineering Institute (SEI) have gained experience with the PSP and TSP, the importance of tool support has become increasingly clear. Jim Over has developed a marvelous tool to support TSPi teams, and he has adapted it specifically to support this book. He has also provided many helpful comments on both the process and the text. For that I am deeply grateful. Again, I am indebted to Peter Gordon and Helen Goldstein and the professional staff at Addison-Wesley. Their help and guidance were invaluable in making the book a reality. Finally, I must again thank Barbara, my wife, for her continued support and good-natured encouragement through yet another book.

I dedicate this book to the memory of my father, Watts S. Humphrey, whose trust, confidence, and enthusiastic support helped and sustained me through my formative years. One of my very earliest memories is of failing first grade. In those days, they did not know about learning disabilities, but my father instinctively knew that I could learn, given proper guidance and instruction. He insisted that I had not flunked, but the school had, so he moved our family to a town where my brothers and I could attend a school that would give me individual instruction. I was extraordinarily fortunate to have had such a father, and I am deeply grateful for his help and support. Although he died many years ago, I still miss him.

Watts S. Humphrey Sarasota, Florida

^SMPersonal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie Mellon University.

1 The advanced PSP course is taught from my text, A Discipline for Software Engineering, Addison-Wesley (1995).

2 The beginning PSP course uses my book Introduction to the Personal Software Process, also from Addison-Wesley (1997).

3 See, for example, A.T. Berztiss, "Failproof Team Projects in Software Engineering Courses," Frontiers in Education Conference (IEEE, 1997); D.H. Hutchens, "Using Iterative Enhancement in Undergraduate Software Engineering Courses," SIGCSE '96; T.J. Scott, "Team Selection Methods For Student Programming Projects," 8th CSEE, '95; and J.E. Tomayko, "Carnegie Mellon Software Development Studio: A Five-Year Retrospective," Proceedings of the Ninth Conference on Software Engineering Education (IEEE Computer Society Press, 1996).

020147719XP04062001



Updates

Submit Errata

