|New from||Used from|
No Kindle device required. Download one of the Free Kindle apps to start reading Kindle books on your smartphone, tablet, and computer.
To get the free app, enter your e-mail address or mobile phone number.
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.
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).