Introduction to the Team Software Process(sm)
- By Watts S. Humphrey
- Published Aug 24, 1999 by Addison-Wesley Professional. Part of the SEI Series in Software Engineering series.
- Copyright 2000
- Dimensions: 6-1/4x9-1/4
- Pages: 496
- Edition: 1st
- ISBN-10: 0-201-47719-X
- ISBN-13: 978-0-201-47719-1
- eBook (Adobe DRM)
- ISBN-10: 0-7686-8465-X
- ISBN-13: 978-0-7686-8465-0
Register your product to gain access to bonus material or receive a coupon.
Text for a projects-oriented software engineering course using the Team Software Process ("TSP"). Course covering Humphrey's Personal Software Process ("PSP") is prerequisite in most cases.
Product Author Bios
Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software-development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process Program and provided the vision and early leadership for the original Capability Maturity Model (CMM). He also is the creator of the Personal Software Process (PSP) and Team Software Process (TSP). Recently, he was awarded the National Medal of Technology—the highest honor given by the president of the United States to America's leading innovators.
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.
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.
22 of 22 people found the following review helpful
Good introduction to creating software in a team,
This review is from: Introduction to the Team Software Process (Hardcover)This is a good introduction to working in a team and using good software engineering techniques such as planning and inspections. It is geared for undergraduate students, therefore the managerial roles have been created. This would probably not work out of the box for an organization that is already set up. For students, the manager roles give each team member ownership in the product while making sure each aspect of good engineering has an advocate.
The processes are written as scripts. These are very easy to follow and take the guesswork out of how to do each step in the lifecycle.
This is a process book therefore there is not a lot of technically-oriented information in the book. For example, the book tells you that you must design your software. It does not give many guidelines on what a good (object-oriented, client-server, real time, etc.) design might look like. In addition, some of the data bookkeeping is long and involved. A good tool would help with... Read more
Perfectly Introduction to TSP,
Amazon Verified Purchase(What's this?)
This review is from: Introduction to the Team Software Process(sm) (Kindle Edition)I used it to develop a Software Process based on SCRUM and TSP; being more familiar to SCRUM, what I needed was an introduction to TSP, this book was ideal for that, and had many good forms and scripts examples.
Amazon Verified Purchase(What's this?)
This review is from: Introduction to the Team Software Process (Hardcover)I think this book is a very good reference book. You can accomplish all basic steps in Team Software Process through this book. It is clear and detailed.
› See all 8 customer reviews...
Praise For Introduction to the Team Software Process(sm)
"This book is an excellent overview of the processes and practices that software teams should use." -- IEEE Software, December 2000
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|
|8||Postmortem||Launch, strategy, plan|
|11||Postmortem||Launch, strategy, plan|
|15||Postmortem and evaluation|
FIGURE P.1 THE THREE-CYCLE TSPi COURSE
|Cycle Week||Cycle 1|
FIGURE P.2 A SHORT TSPi REQUIREMENTS LIST
|Cycle Week||Cycle 1|
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.
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.
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).
Table of Contents
(Each chapter, except Chapter 18, concludes with a Summary.)
II. THE TSPI PROCESS.
III. THE TEAM ROLES.
IV. USING THE TSPI.
This book includes free shipping!
This book includes free shipping!
eBook (Adobe DRM)
This eBook requires the free Adobe® Digital Editions software.
Before downloading this DRM-encrypted PDF, be sure to:
- Install the free Adobe Digital Editions software on your machine. Adobe Digital Editions only works on Macintosh and Windows, and requires the Adobe Flash Player. Please see the official system requirements.
- Authorize your copy of Adobe Digital Editions using your Adobe ID. If you don't already have an Adobe ID, you can create one here.
Get access to thousands of books and training videos about technology, professional development and digital media from more than 40 leading publishers, including Addison-Wesley, Prentice Hall, Cisco Press, IBM Press, O'Reilly Media, Wrox, Apress, and many more. If you continue your subscription after your 30-day trial, you can receive 30% off a monthly subscription to the Safari Library for up to 12 months. That's a total savings of $199.