Introduction To The Team Software Process (sm)

(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.

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 typicalsmall 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.

FIGURE P.1 THE THREE-CYCLE TSPi COURSE

FIGURE P.2 A SHORT TSPi REQUIREMENTS LIST

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 fortun