Introduction to the Team Software Process(sm) and over one million other books are available for Amazon Kindle. Learn more

Vous voulez voir cette page en français ? Cliquez ici.


or
Sign in to turn on 1-Click ordering.
or
Amazon Prime Free Trial required. Sign up when you check out. Learn More
More Buying Choices
Have one to sell? Sell yours here
Start reading Introduction to the Team Software Process(sm) on your Kindle in under a minute.

Don't have a Kindle? Get your Kindle here, or download a FREE Kindle Reading App.

Introduction to the Team Software Process(sm) [Hardcover]

Watts S. Humphrey
3.0 out of 5 stars  See all reviews (4 customer reviews)
List Price: CDN$ 78.99
Price: CDN$ 49.76 & FREE Shipping. Details
You Save: CDN$ 29.23 (37%)
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
Only 1 left in stock (more on the way).
Ships from and sold by Amazon.ca. Gift-wrap available.
Want it delivered Friday, July 11? Choose One-Day Shipping at checkout.

Formats

Amazon Price New from Used from
Kindle Edition CDN $35.05  
Hardcover CDN $49.76  
Paperback --  

Book Description

Aug. 24 1999 020147719X 978-0201477191 1
This book describes an introductory version of TSP (Team Software Process), ideal for smaller projects but also useful for learning basic forms and procedures that apply to other development projects. Methods presented include- how to establish roles; how to conceive, design, and plan a project; and how to track and report on progress. The book walks students 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; and how to alleviate many of the conflicts that undermine teamwork.
The book provides two project exercises, with prescribed development goals and team roles, to help students master this proven process.

Special Offers and Product Promotions

  • Get $20 Off: Get the Amazon.ca Rewards Visa Card and Get $20.00 Off Instantly upon approval. Learn more.

Customers Who Bought This Item Also Bought


Product Details


Product Description

From Amazon

Aimed at the computer science student, Introduction to the Team Software Process provides a textbook-style introduction to the author's Team Software Process (TSP), a rigorous group-based design process that stresses planning, metrics, scripts, accountability, and ultimately, higher code quality. Although best suited for a semester- or two-semester-length course, this book provides a useful model for any team development effort.

This textbook focuses squarely on the team-based nature of successful software development. The author, who also invented the Personal Software Process (PSP), outlines the steps for "staffing" a classroom-based software project with different multiple member roles, such as team leaders and development managers. The Team Software Process (TSP) outlined here stresses accountability through numerous scripts and metrics. (An appendix features over 80 pages of scripts and forms that would be used over the course of the semester.) Not only does the author provide a thorough guide to choosing the right team role that fits your personality and skills, but several sections offer some "motivational speaking" on the advantage of "discipline," both as a person and software engineer.

This book does a particularly good job of defining a team's role for each stage in the development process, beginning from the initial planning stages to requirements definition, implementation, testing, and postmortem followup. There are hints for dealing with missed deadlines, staffing, and design problems.

The reality is that teams are used throughout the software industry, but many computer science students do not get much experience working in successful teams. As a first encounter with team development, Introduction to the Team Software Process provides a model for serious implementation of a smart, rigorous software method that can put readers on the right track with group development. --Richard Dragan

Topics Covered: Team Software Process (TSP) basics and scripts, building production software teams, team goals, team roles, planning, risk management, quality plan, requirements, design principles, product implementation, integration and system testing, test planning, defect tracking, documentation, conducting postmortems, team leaders, development managers, planning managers, quality/process managers, support managers.

From the Inside Flap

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 WeekCycle 1Cycle 2Cycle 3 1Course introduction, review   2Launch, strategy   3Plan   4Requirements   5Design   6Implementation   7Test   8PostmortemLaunch, strategy, plan  9 Requirements, design  10 Implementation, test  11 PostmortemLaunch, strategy, plan 12  Requirements, design 13  Implementation, test 14  Test, documentation 15  Postmortem and evaluation

FIGURE P.1 THE THREE-CYCLE TSPi COURSE

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

FIGURE P.2 A SHORT TSPi REQUIREMENTS LIST

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

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.

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

Customer Reviews

3.0 out of 5 stars
3.0 out of 5 stars
Most helpful customer reviews
3.0 out of 5 stars I tsp book April 11 2011
By Sveta
Format:Hardcover
This book is a very good on-hand referencing material for TSP practitioners:team leads, candidate coaches and TSP team members. It has scripts (process descriptions), forms and comments for all needs
Was this review helpful to you?
1.0 out of 5 stars totalitarian control is not the answer May 18 2004
By A Customer
Format:Hardcover
A state-of-the-art process for producing PL/I programs on punchcards. If you can master PSP/TSP, you will be more effective than 99% of all software developers at filling out forms and producing status reports. A shockingly wasteful approach to quality management.
Was this review helpful to you?
5.0 out of 5 stars Outstanding Reference for Software Engineers Oct. 23 2000
By A Customer
Format:Hardcover
I've been involved with many different projects in a team environment. This book contains some of the best and most respected procedures to complete a team project. I've used these methods and they work well! The principles outlined in this book apply to more than just software engineering. Take a look! You'll be glad you did!
Was this review helpful to you?
3.0 out of 5 stars Good introduction to creating software in a team Aug. 29 2000
Format: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 this.
Overall, this is a good tutorial and a good reference book. I used this book as a graduate student, and I continue to pull ideas out of it for use in my work.
Was this review helpful to you?
Most Helpful Customer Reviews on Amazon.com (beta)
Amazon.com: 3.6 out of 5 stars  8 reviews
23 of 23 people found the following review helpful
3.0 out of 5 stars Good introduction to creating software in a team Aug. 29 2000
By Proggoddess - Published on Amazon.com
Format: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 this.
Overall, this is a good tutorial and a good reference book. I used this book as a graduate student, and I continue to pull ideas out of it for use in my work.
5.0 out of 5 stars Perfectly Introduction to TSP March 18 2012
By Marcel - Published on Amazon.com
Format:Kindle Edition|Verified Purchase
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.
4.0 out of 5 stars Good navigation March 5 2012
By Ethan1985 - Published on Amazon.com
Format:Hardcover|Verified Purchase
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.
9 of 14 people found the following review helpful
5.0 out of 5 stars Outstanding Reference for Software Engineers Oct. 22 2000
By A Customer - Published on Amazon.com
Format:Hardcover
I've been involved with many different projects in a team environment. This book contains some of the best and most respected procedures to complete a team project. I've used these methods and they work well! The principles outlined in this book apply to more than just software engineering. Take a look! You'll be glad you did!
3 of 5 people found the following review helpful
5.0 out of 5 stars Excellent Process for Software Devleopment March 30 2005
By Michael - Published on Amazon.com
Format:Hardcover
My software team used the TSP for developing a 3 release Java application over 12 weeks. There is a stiff learning curve, but once you learn it, you can quickly realize the results. This book takes the guesswork out of developing software. If you have a dedicated team that will take the time to learn it, you will be very happy with the results.
Search Customer Reviews
Only search this product's reviews

Look for similar items by category


Feedback