PSP: A Self-Improvement Process for Software Engineers (SEI Series in Software Engineering) / Edition 1

Hardcover (Print)
Buy Used
Buy Used from BN.com
$41.17
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $15.55
Usually ships in 1-2 business days
(Save 77%)
Other sellers (Hardcover)
  • All (14) from $15.55   
  • New (9) from $47.41   
  • Used (5) from $15.55   

Overview

Most software-development groups have embarrassing records: By some accounts, more than half of all software projects are significantly late and over budget, and nearly a quarter of them are cancelled without ever being completed. Although developers recognize that unrealistic schedules, inadequate resources, and unstable requirements are often to blame for such failures, few know how to solve these problems. Fortunately, the Personal Software Process (PSP) provides a clear and proven solution. Comprising precise methods developed over many years by Watts S. Humphrey and the Software Engineering Institute (SEI), the PSP has successfully transformed work practices in a wide range of organizations and has already produced some striking results.

This book describes the PSP and is the definitive guide and reference for its latest iteration. PSP training focuses on the skills required by individual software engineers to improve their personal performance. Once learned and effectively applied, PSP-trained engineers are qualified to participate on a team using the Team Software Process (TSP), the methods for which are described in the final chapter of the book. The goal for both PSP and TSP is to give developers exactly what they need to deliver quality products on predictable schedules.

PSPSM: A Self-Improvement Process for Software Engineers presents a disciplined process for software engineers and anyone else involved in software development. This process includes defect management, comprehensive planning, and precise project tracking and reporting.

The book first scales down industrial software practices to fit the needs of the module-sized program development, then walks readers through a progressive sequence of practices that provide a sound foundation for large-scale software development. By doing the exercises in the book, and using the PSP methods described here to plan, evaluate, manage, and control the quality of your own work, you will be well prepared to apply those methods on ever larger and more critical projects.

Drawing on the author’s extensive experience helping organizations to achieve their development goals, and with the PSP benefits well illustrated, the book presents the process in carefully crafted steps. The first chapter describes overall principles and strategies. The next two explain how to follow a defined process, as well as how to gather and use the data required to manage a programming job. Several chapters then cover estimating and planning, followed by quality management and design. The last two chapters show how to put the PSP to work, and how to use it on a team project. A variety of support materials for the book, as described in the Preface, are available on the Web.

If you or your organization are looking for a way to improve your project success rate, the PSP could well be your answer.

Read More Show Less

Product Details

  • ISBN-13: 9780321305497
  • Publisher: Addison-Wesley
  • Publication date: 3/11/2005
  • Series: SEI Series in Software Engineering Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 346
  • Product dimensions: 6.50 (w) x 9.56 (h) x 0.99 (d)

Meet the Author

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.

Read More Show Less

Read an Excerpt

The record of most development groups is poor, but the record of software groups is particularly bad. The Standish Group reports that more than half of all software projects are seriously late and over budget, and that nearly one-quarter of them are cancelled without being finished.1 Under 30% of the projects were considered successful. Most of the software developers I know are well aware of these problems and can even explain their causes: unrealistic schedules, inadequate resources, and unstable requirements. Although these problems are common and not hard to solve, few developers know how.

It is tempting to blame others for our difficulties, but a victimlike attitude doesn’t solve problems. When you approach these software management problems in the proper way, you can generally solve them. However, this requires skills and practices that you may not have learned. It also requires dealing with management on management’s terms. You can gain the required practices with the Personal Software Process (PSP).2 This book describes the PSP and explains the practices and methods you will need to deliver quality products on predictable schedules. After learning these skills, you will be qualified to participate on a team that uses the Team Software Process (TSP). Such teams are called self-directed because they define their own working practices and negotiate their plans and schedules with management. The final chapter of the book describes the TSP and how it helps to put you in charge of your own work.Being a Software Engineer

An engineer is someone who knows how to consistently and predictably do quality work. Many of the states inthe United States have regulations governing the practice of engineering and they do not allow people to call themselves engineers unless they have demonstrated competence in their professional specialty. Most engineering fields were originally established because the public demanded protection from unqualified work, particularly in building construction, steam power plants, and the like. Without such licensing, steam boilers frequently exploded and bridges collapsed. Although licensing did not magically solve all of these problems, it has been a big help.

Licensed engineers use known and proven methods, they are tested to ensure that they consistently do quality work, and they are required to demonstrate their competence at producing safe products. The difference between a licensed engineer and any other technical worker is that the engineer knows the proper ways to do his or her job and is required by law to work that way regardless of management, customer, or other pressures.

If we are to call ourselves engineers, we must learn to produce quality products on predictable schedules. This requires that we learn how to consistently meet our commitments and that we know how to handle the normal challenges of creative development work. Software development is the most challenging professional occupation I know of and we must all consistently use the best available methods to meet our management’s and our customers’ needs. Quality Problems

Poor quality management causes many of today’s software problems. Most software professionals spend nearly half of their time testing and fixing their products during development and final testing. Poor quality also leads to schedule problems, with defective products delivered long after they were committed. Although fixing a few defects may seem inconvenient, even fairly small programs can have hundreds of defects, and finding and fixing them can take many weeks or even months. Software quality starts with the individual developer. If any of the program modules that we develop have numerous defects, they will be hard to test, take time to integrate into larger systems, and be troublesome for our users.

Most of us can be highly productive when writing very small programs. However, our productivity falls off sharply when we develop larger programs. Although developing bigger systems involves some added architectural and design work, most of the added effort is caused by defects. The average amount of time it takes to find and fix each defect increases exponentially as programs become larger. However, if you can consistently write high-quality module-size programs, you will produce better products and improve your and your organization’s productivity.

A disciplined software engineering process includes effective defect management, comprehensive planning, and precise project tracking and reporting. This book shows you how to use these disciplines to do better development work as an individual and as a TSP team member. It also shows why these practices are essential if you want to manage your own work.The Benefits of Being a Software Engineer

As our lives increasingly depend on software, the demands for safety, security, and quality will only increase. This means that the demand for capable software professionals will also increase. Unfortunately, few software developers have any way to distinguish themselves from the many programmers who bang out poor-quality code. With PSP training, you can apply to the Software Engineering Institute to become a PSP-certified software professional. This will distinguish you from the many developers who have no unique qualifications. PSP training will also qualify you to participate on a TSP team, and PSP certification will assure potential employers that you are a professional who is capable of producing high-quality software for predictable costs and on committed schedules. Other personal benefits of PSP certification are the added recognition of being a skilled software professional and easier access to more responsible and higher-paying positions. Developers with such qualifications are now widely sought and will be increasingly needed in the future.Who Should Learn the PSP?

Modern technical work involves many specialties, and the people who participate in developing modern products and systems now come from a wide range of disciplines. To produce quality products on predictable schedules, all of the work that these people do must be planned, managed, and quality-controlled. This means that just about everyone associated with system development must know how to do disciplined engineering work. It also means that just about anyone doing such work would benefit from learning the PSP.

Although the examples and exercises in this book concern developing small programs, this is only because, even for small programs, software development is a marvelously rich process that can be measured and analyzed. This makes the software process particularly suitable for teaching disciplined engineering practices. Most modern professionals in almost any technical field now learn to write programs during their education, so the PSP course is appropriate for almost anyone planning an engineering or technical career, and it is particularly appropriate for anyone planning to work in product or system development. The Approach Taken by This Book

With the growing importance of software and software products, organizations will increasingly need software engineers who consistently use disciplined personal practices. To meet this need, we must learn and consistently practice these disciplines with every program we write. If we don’t use sound development practices when writing module-size programs, there is little chance that we will use them when writing large programs.

When students start to program, they generally begin by learning a programming language. They practice on toy problems and develop the personal skills to deal with issues at this toy level. As they take more courses, they build their personal skills and can soon develop fairly large programs relatively quickly. These programming-in-the-small skills, however, are inherently limited. Although they may suffice on small-scale individual tasks, they do not provide an adequate foundation for solving the problems of large-scale, multiperson, distributed project teams.

This book follows a fundamentally different strategy. It scales down industrial software practices to fit the needs of module-size program development. It then walks you through a progressive sequence of software processes that provide a sound foundation for large-scale software development. By doing the exercises and using the methods described in this book, you will learn how to use the methods for yourself. Once you have learned and used these practices on module-size programs, you will have the skills to use them on larger projects. Although some additional requirements, design, implementation, and testing methods are needed for developing large programs, the basic software engineering disciplines taught by this book apply directly to large-scale system development. The reason, of course, is that large systems are built from collections of program modules that are much like the programs you develop in the PSP course.

The principal goal of this book is to guide you in developing the personal software engineering skills that you need to perform at your very best. Consider the challenge of improving personal performance. In sports, for example, runners know the length of the track, their personal time, their fastest time, and the record time for each event. With proper coaching and guidance, they learn their personal strengths and weaknesses and see how to improve. In software, without clear performance measures, few of us can understand our personal strengths and weaknesses or see how to improve. The methods in this book will help you to assess your own performance, to identify ways to improve, and to guide your improvement efforts.

In addition to helping you improve your personal performance, this book will also help you build the engineering skills needed for large-scale software work. You will learn how to make accurate plans, how to estimate the accuracy of these plans, and how to track your performance against them. You will use defect management, design and code reviews, design templates, and process analysis. You will do this with a defined and measured personal software process. These measurement and analysis disciplines will help you to evaluate your performance, to understand your strengths, and to see where you should try to improve. From all of this you will develop the tools you need to continue personal improvement throughout your professional career.What’s Involved in Learning the PSP

In learning the PSP, the benefits you get will depend on the effort you invest. Although there are many ways to organize a PSP course, the basic requirements are reading the 14 chapters of this book and completing the programming and report exercises provided on the SEI Web site (www.sei.cmu.edu/tsp/psp.html). This web site also includes various course plans. The original PSP course called for a total of ten exercise programs and five report exercises. Other strategies have used various numbers of program exercises, but the basic requirement is to write a program at each of the six PSP process levels plus an additional two to four programs to master the methods and build the data to support your continuing work.

Reading the chapters should not take too long; the time it takes to write the programs can vary widely. These PSP exercise programs have now been written many thousands of times, and I use a sample of 8,100 sets of PSP program data for many examples in this book. In writing these programs, half of the developers spent less than four hours each, and one-third averaged under three hours. To minimize your time, use the programming language and environment that you know best, and keep your designs simple and straightforward.

Because the PSP course involves writing programs, people often think it is a programming course. It is not. Even after writing all of the assigned programs, if you did not follow the prescribed PSP processes and gather, analyze, and use all of the specified data, you would not learn the PSP. This is a process course, and to avoid wasting your time, follow the prescribed process to write each program. If you have problems doing this, ask your instructor for help.

The following two suggestions will ensure that you get the most from the PSP course. First, do not substitute programs from your work for those called for by the text. Of the thousands of developers who have completed PSP training, no one has done this successfully. Taking this course involves learning new and unfamiliar methods. The exercises in this course are like experiments, and working programmers are universally reluctant to experiment with unfamiliar methods when they work on a project. Second, do not merely read the book and then try to apply the methods without doing the exercises. Until you have completed the course and the exercises, you will not be able to apply the methods on the job. At least, nobody has done so thus far. Book Overview

The 14 chapters of this book introduce the PSP methods in steps. Chapter 1 describes the overall principles of the PSP and the introduction strategy. Chapters 2 and 3 explain how to follow a defined process and how to gather and use the data required to manage a programming development job. Chapters 4, 5, 6, and 7 cover estimating and planning, and Chapters 8 through 12 cover quality management and design. Chapter 13 describes how to use the PSP for various kinds of work, and Chapter 14 describes how the PSP methods are used in the TSP process and how the TSP guides PSP-trained software engineers in using these methods on a project. It also discusses the personal issues involved in learning and using the PSP.Support Materials

This book has extensive support materials, which are available at www.sei.cmu.edu/tsp/psp.html. The support items are a data-gathering and planning tool, the PSP exercise assignment kits, and reference materials. Also included are pointers to PSP course descriptions and the addresses of SEI-authorized organizations that can help you to introduce and use the PSP and TSP in your organization. The PSP also be taught as a university course. For this purpose, the online support materials include an instructor’s guide, suggested slides for PSP course lectures, and class exercises. These items are also publicly available on the Web site.Book Background and History

This is the fourth book I have written on the PSP. I wrote A Discipline for Software Engineering in 19953 and I published Introduction to the Personal Software Process in 1997.4 Introduction to the Team Software Process followed in 2000.5 The Discipline book was for a graduate course in computer science, and the introductory books were texts for undergraduate courses. In the intervening years, thousands of software developers have taken the PSP course and hundreds of TSP teams have used the PSP methods on their projects. The results have been far better than I had hoped.

This experience demonstrated that a PSP textbook was needed for industrial software developers. Although Discipline for Software Engineering covers all of the required materials, it also includes a number of topics that are of more academic interest and are not essential for teaching industrial software developers. Because course duration is a principal concern for industrial organizations, these more academic topics have been omitted from this book.Notes

1. The Standish Group International, Inc., 586 Olde King’s Highway, Dennis, MA 02638; www.standishgroup.com.
2. Personal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie Mellon University.
3. Watts Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995.
4. Watts Humphrey, Introduction to the Personal Software Process, Addison-Wesley, 1997.
5. Watts Humphrey, Introduction to the Team Software Process, Addison-Wesley, 2000.

Read More Show Less

Table of Contents

Preface xiii

Chapter 1: The Personal Process Strategy 1

1.1. The PSP’s Purpose 3

1.2. The Logic for a Software Engineering Discipline 4

1.3. Using Disciplined Development Practices 6

1.4. Operational Processes 6

1.5. Defining and Using a Personal Process 7

1.6. Learning to Use a Personal Process 8

1.7. Preparing for the Team Software Process 9

1.8. Summary 9

Reference 10

Chapter 2: The Baseline Personal Process 11

2.1. What Is a Process? 12

2.2. Defining Your Own Process 13

2.3. Baseline Process Contents 14

2.4. Why Forms Are Helpful 16

2.5. The PSP Process Elements 17

2.6. The PSP0 Process 18

2.7. PSP0 Measures 20

2.8. Time Recording 21

2.9. Defect Recording 24

2.10. The PSP0 Project Plan Summary 30

2.11. The Compile Phase 31

2.12. Incremental Development 32

2.13. PSP Tool Support 34

2.14. Summary 34

2.15. Exercises 34

Chapter 3: Measuring Software Size 35

3.1. Size Measures 35

3.2. Establishing a Database Counting Standard 40

3.3. Establishing a Line-of-Code Counting Standard 40

3.4. Size Accounting 42

3.5. Using Size Data 45

3.6. Calculating Productivity 47

3.7. Size Counters 48

3.8. Other Size Measures 53

3.9. Summary 54

3.10. Exercises 54

References 55

Chapter 4: Planning 57

4.1. The Planning Process 58

4.2. Why Make Plans? 59

4.3. What Is a Plan? 60

4.4. The Contents of a Software Plan 60

4.5. Planning a Software Project 62

4.6. The Conceptual Design 63

4.7. Plan Quality 65

4.8. Planning Issues 65

4.9. Summary 66

Reference 67

Chapter 5: Software Estimating 69

5.1. Size Estimating Principles 69

5.2. The Conceptual Design 70

5.3. Proxy-Based Estimating 71

5.4. Using Proxies in Estimating 75

5.5. Producing the Relative-Size Table 78

5.6. Estimating Considerations 80

5.7. Summary 84

Chapter 6: The PROBE Estimating Method 85

6.1. Estimating from Data 85

6.2. Proxy-Based Estimating 87

6.3. Estimating with Limited Data 95

6.4. An Estimating Example 100

6.5. Estimating Nonprogramming Tasks 102

6.6. Considerations in Using PROBE 105

6.7. Summary 108

6.8. Exercises 108

Chapter 7: Software Planning 109

7.1. Plan Requirements 109

7.2. Project and Period Plans 111

7.3. Producing the Schedule 113

7.4. Making the Schedule 115

7.5. Earned Value 119

7.6. An Earned Value Example 120

7.7. Comments on the EV Example 123

7.8. Estimating Accuracy 125

7.9. The Prediction Interval 126

7.10. Alerting Management to Changes 128

7.11. Planning Considerations 129

7.12. Summary 131

7.13. Exercises 132

References 132

Chapter 8: Software Quality 133

8.1. The PSP Quality Strategy 135

8.2. What Is Software Quality? 135

8.3. The Economics of Software Quality 136

8.4. Defect Types 141

8.5. Personal Quality Practices 142

8.6. Quality Measures 143

8.7. Quality Management 153

8.8. Personal Quality Management 154

8.9. Managing Product Quality 156

8.10. PSP Improvement Practices 157

8.11. Defect Prevention 158

8.12. Summary 160

References 161

Chapter 9: Design and Code Reviews 163

9.1. What Are Reviews? 164

9.2. Why Review Programs? 164

9.3. Review Principles 168

9.4. The PSP Code Review Process 173

9.5. The Code Review Checklist 176

9.6. Design Reviews 181

9.7. Design Review Principles 183

9.8. Review Measures 187

9.9. Review Issues 194

9.10. Summary 201

9.11. Exercises 202

References 202

Chapter 10: Software Design 203

10.1. What Is Design? 204

10.2. Why Design? 206

10.3. The Design Process 207

10.4. Design Levels 210

10.5. Design and Development Strategies 216

10.6. Design Quality 220

10.7. Summary 223

References 224

Chapter 11: The PSP Design Templates 225

11.1. Design Representation 226

11.2. The Design Templates 229

11.3. The Operational Specification Template (OST) 230

11.4. The Functional Specification Template (FST) 233

11.5. The State Specification Template (SST) 236

11.6. The Logic Specification Template (LST) 240

11.7. A State-Machine Design Example 241

11.8. Using the PSP Design Templates 246

11.9. Using the Design Templates in Large-Scale Design 248

11.10. Summary 250

11.11. Exercises 250

References 250

Chapter 12: Design Verification 253

12.1. Why Verify Programs? 254

12.2. Design Standards 257

12.3. Execution-Table Verification 258

12.4. Trace-Table Verification 262

12.5. Verifying State Machines 265

12.6. Loop Verification 271

12.7. Other Analytical Verification Methods 277

12.8. Verification Considerations 280

12.9. Summary 284

12.10. Exercises 284

References 285

Chapter 13: Process Extensions 287

13.1. Customizing the Development Process 289

13.2. Why Define a Process? 290

13.3. The PSP Process Strategy 291

13.4. Defining a Process 291

13.5. Process Evolution 294

13.6. Example Processes 298

13.7. Process Development Considerations 306

13.8. Summary 307

13.9. Exercises 308

References 308

Chapter 14: Using the Personal Software Process 309

14.1. Development Challenges 309

14.2. The Team Software Process (TSP) 313

14.3. The Logic of the TSP 314

14.4. Teambuilding 314

14.5. The TSP Launch Process 316

14.6. The TSP Coach 317

14.7. Managing Your Own Project 318

14.8. TSP Results 322

14.9. The Rewards of Teamwork 322

14.10. The TSP Team of One 323

14.11. Your Future in Software Engineering 326

References 327

Index 329

Read More Show Less

Preface

The record of most development groups is poor, but the record of software groups is particularly bad. The Standish Group reports that more than half of all software projects are seriously late and over budget, and that nearly one-quarter of them are cancelled without being finished.1 Under 30% of the projects were considered successful. Most of the software developers I know are well aware of these problems and can even explain their causes: unrealistic schedules, inadequate resources, and unstable requirements. Although these problems are common and not hard to solve, few developers know how.

It is tempting to blame others for our difficulties, but a victimlike attitude doesn’t solve problems. When you approach these software management problems in the proper way, you can generally solve them. However, this requires skills and practices that you may not have learned. It also requires dealing with management on management’s terms. You can gain the required practices with the Personal Software Process (PSP).2 This book describes the PSP and explains the practices and methods you will need to deliver quality products on predictable schedules. After learning these skills, you will be qualified to participate on a team that uses the Team Software Process (TSP). Such teams are called self-directed because they define their own working practices and negotiate their plans and schedules with management. The final chapter of the book describes the TSP and how it helps to put you in charge of your own work.

Being a Software Engineer

An engineer is someone who knows how to consistently and predictably do quality work. Many of the states in the United States have regulations governing the practice of engineering and they do not allow people to call themselves engineers unless they have demonstrated competence in their professional specialty. Most engineering fields were originally established because the public demanded protection from unqualified work, particularly in building construction, steam power plants, and the like. Without such licensing, steam boilers frequently exploded and bridges collapsed. Although licensing did not magically solve all of these problems, it has been a big help.

Licensed engineers use known and proven methods, they are tested to ensure that they consistently do quality work, and they are required to demonstrate their competence at producing safe products. The difference between a licensed engineer and any other technical worker is that the engineer knows the proper ways to do his or her job and is required by law to work that way regardless of management, customer, or other pressures.

If we are to call ourselves engineers, we must learn to produce quality products on predictable schedules. This requires that we learn how to consistently meet our commitments and that we know how to handle the normal challenges of creative development work. Software development is the most challenging professional occupation I know of and we must all consistently use the best available methods to meet our management’s and our customers’ needs.

Quality Problems

Poor quality management causes many of today’s software problems. Most software professionals spend nearly half of their time testing and fixing their products during development and final testing. Poor quality also leads to schedule problems, with defective products delivered long after they were committed. Although fixing a few defects may seem inconvenient, even fairly small programs can have hundreds of defects, and finding and fixing them can take many weeks or even months. Software quality starts with the individual developer. If any of the program modules that we develop have numerous defects, they will be hard to test, take time to integrate into larger systems, and be troublesome for our users.

Most of us can be highly productive when writing very small programs. However, our productivity falls off sharply when we develop larger programs. Although developing bigger systems involves some added architectural and design work, most of the added effort is caused by defects. The average amount of time it takes to find and fix each defect increases exponentially as programs become larger. However, if you can consistently write high-quality module-size programs, you will produce better products and improve your and your organization’s productivity.

A disciplined software engineering process includes effective defect management, comprehensive planning, and precise project tracking and reporting. This book shows you how to use these disciplines to do better development work as an individual and as a TSP team member. It also shows why these practices are essential if you want to manage your own work.

The Benefits of Being a Software Engineer

As our lives increasingly depend on software, the demands for safety, security, and quality will only increase. This means that the demand for capable software professionals will also increase. Unfortunately, few software developers have any way to distinguish themselves from the many programmers who bang out poor-quality code. With PSP training, you can apply to the Software Engineering Institute to become a PSP-certified software professional. This will distinguish you from the many developers who have no unique qualifications. PSP training will also qualify you to participate on a TSP team, and PSP certification will assure potential employers that you are a professional who is capable of producing high-quality software for predictable costs and on committed schedules. Other personal benefits of PSP certification are the added recognition of being a skilled software professional and easier access to more responsible and higher-paying positions. Developers with such qualifications are now widely sought and will be increasingly needed in the future.

Who Should Learn the PSP?

Modern technical work involves many specialties, and the people who participate in developing modern products and systems now come from a wide range of disciplines. To produce quality products on predictable schedules, all of the work that these people do must be planned, managed, and quality-controlled. This means that just about everyone associated with system development must know how to do disciplined engineering work. It also means that just about anyone doing such work would benefit from learning the PSP.

Although the examples and exercises in this book concern developing small programs, this is only because, even for small programs, software development is a marvelously rich process that can be measured and analyzed. This makes the software process particularly suitable for teaching disciplined engineering practices. Most modern professionals in almost any technical field now learn to write programs during their education, so the PSP course is appropriate for almost anyone planning an engineering or technical career, and it is particularly appropriate for anyone planning to work in product or system development.

The Approach Taken by This Book

With the growing importance of software and software products, organizations will increasingly need software engineers who consistently use disciplined personal practices. To meet this need, we must learn and consistently practice these disciplines with every program we write. If we don’t use sound development practices when writing module-size programs, there is little chance that we will use them when writing large programs.

When students start to program, they generally begin by learning a programming language. They practice on toy problems and develop the personal skills to deal with issues at this toy level. As they take more courses, they build their personal skills and can soon develop fairly large programs relatively quickly. These programming-in-the-small skills, however, are inherently limited. Although they may suffice on small-scale individual tasks, they do not provide an adequate foundation for solving the problems of large-scale, multiperson, distributed project teams.

This book follows a fundamentally different strategy. It scales down industrial software practices to fit the needs of module-size program development. It then walks you through a progressive sequence of software processes that provide a sound foundation for large-scale software development. By doing the exercises and using the methods described in this book, you will learn how to use the methods for yourself. Once you have learned and used these practices on module-size programs, you will have the skills to use them on larger projects. Although some additional requirements, design, implementation, and testing methods are needed for developing large programs, the basic software engineering disciplines taught by this book apply directly to large-scale system development. The reason, of course, is that large systems are built from collections of program modules that are much like the programs you develop in the PSP course.

The principal goal of this book is to guide you in developing the personal software engineering skills that you need to perform at your very best. Consider the challenge of improving personal performance. In sports, for example, runners know the length of the track, their personal time, their fastest time, and the record time for each event. With proper coaching and guidance, they learn their personal strengths and weaknesses and see how to improve. In software, without clear performance measures, few of us can understand our personal strengths and weaknesses or see how to improve. The methods in this book will help you to assess your own performance, to identify ways to improve, and to guide your improvement efforts.

In addition to helping you improve your personal performance, this book will also help you build the engineering skills needed for large-scale software work. You will learn how to make accurate plans, how to estimate the accuracy of these plans, and how to track your performance against them. You will use defect management, design and code reviews, design templates, and process analysis. You will do this with a defined and measured personal software process. These measurement and analysis disciplines will help you to evaluate your performance, to understand your strengths, and to see where you should try to improve. From all of this you will develop the tools you need to continue personal improvement throughout your professional career.

What’s Involved in Learning the PSP

In learning the PSP, the benefits you get will depend on the effort you invest. Although there are many ways to organize a PSP course, the basic requirements are reading the 14 chapters of this book and completing the programming and report exercises provided on the SEI Web site (www.sei.cmu.edu/tsp/psp.html). This web site also includes various course plans. The original PSP course called for a total of ten exercise programs and five report exercises. Other strategies have used various numbers of program exercises, but the basic requirement is to write a program at each of the six PSP process levels plus an additional two to four programs to master the methods and build the data to support your continuing work.

Reading the chapters should not take too long; the time it takes to write the programs can vary widely. These PSP exercise programs have now been written many thousands of times, and I use a sample of 8,100 sets of PSP program data for many examples in this book. In writing these programs, half of the developers spent less than four hours each, and one-third averaged under three hours. To minimize your time, use the programming language and environment that you know best, and keep your designs simple and straightforward.

Because the PSP course involves writing programs, people often think it is a programming course. It is not. Even after writing all of the assigned programs, if you did not follow the prescribed PSP processes and gather, analyze, and use all of the specified data, you would not learn the PSP. This is a process course, and to avoid wasting your time, follow the prescribed process to write each program. If you have problems doing this, ask your instructor for help.

The following two suggestions will ensure that you get the most from the PSP course. First, do not substitute programs from your work for those called for by the text. Of the thousands of developers who have completed PSP training, no one has done this successfully. Taking this course involves learning new and unfamiliar methods. The exercises in this course are like experiments, and working programmers are universally reluctant to experiment with unfamiliar methods when they work on a project. Second, do not merely read the book and then try to apply the methods without doing the exercises. Until you have completed the course and the exercises, you will not be able to apply the methods on the job. At least, nobody has done so thus far.

Book Overview

The 14 chapters of this book introduce the PSP methods in steps. Chapter 1 describes the overall principles of the PSP and the introduction strategy. Chapters 2 and 3 explain how to follow a defined process and how to gather and use the data required to manage a programming development job. Chapters 4, 5, 6, and 7 cover estimating and planning, and Chapters 8 through 12 cover quality management and design. Chapter 13 describes how to use the PSP for various kinds of work, and Chapter 14 describes how the PSP methods are used in the TSP process and how the TSP guides PSP-trained software engineers in using these methods on a project. It also discusses the personal issues involved in learning and using the PSP.

Support Materials

This book has extensive support materials, which are available at www.sei.cmu.edu/tsp/psp.html. The support items are a data-gathering and planning tool, the PSP exercise assignment kits, and reference materials. Also included are pointers to PSP course descriptions and the addresses of SEI-authorized organizations that can help you to introduce and use the PSP and TSP in your organization. The PSP also be taught as a university course. For this purpose, the online support materials include an instructor’s guide, suggested slides for PSP course lectures, and class exercises. These items are also publicly available on the Web site.

Book Background and History

This is the fourth book I have written on the PSP. I wrote A Discipline for Software Engineering in 19953 and I published Introduction to the Personal Software Process in 1997.4 Introduction to the Team Software Process followed in 2000.5 The Discipline book was for a graduate course in computer science, and the introductory books were texts for undergraduate courses. In the intervening years, thousands of software developers have taken the PSP course and hundreds of TSP teams have used the PSP methods on their projects. The results have been far better than I had hoped.

This experience demonstrated that a PSP textbook was needed for industrial software developers. Although Discipline for Software Engineering covers all of the required materials, it also includes a number of topics that are of more academic interest and are not essential for teaching industrial software developers. Because course duration is a principal concern for industrial organizations, these more academic topics have been omitted from this book.

Notes

1. The Standish Group International, Inc., 586 Olde King’s Highway, Dennis, MA 02638; www.standishgroup.com.
2. Personal Software Process, PSP, Team Software Process, and TSP are service marks of Carnegie Mellon University.
3. Watts Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995.
4. Watts Humphrey, Introduction to the Personal Software Process, Addison-Wesley, 1997.
5. Watts Humphrey, Introduction to the Team Software Process, Addison-Wesley, 2000.

0321305493P03172005

Read More Show Less

Customer Reviews

Average Rating 5
( 6 )
Rating Distribution

5 Star

(5)

4 Star

(1)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 6 Customer Reviews
  • Anonymous

    Posted April 15, 2005

    review before compiling?

    The intent is to reduce the defect rate in software. With an emphasis on doing this when we have several million lines of source code. All the more so if the application might involve safety issues or be critical to its company's bottom line. Humphrey points out that the writing of such large code might typically follow practices used for code bodies orders of magnitude smaller. But that this leads to far too many defects. He explains that PSP offers a discipline for the individual programmer to follow. And how this can be scaled to a team of programmers. PSP stresses investing in design time and review time, relative to the actual coding time. It's big on writing down the times spent on these stages, so that you have actual quantities to see and from which to get metrics. You cannot improve what you cannot measure. The review time is considered a good investment, for finding bugs here is inherently more productive than relying on a downstream testing stage or user feedback. Perhaps the most contentious aspect is whether to do a review of your code before compiling it?! Many will not. After all, the compiler can swiftly find the syntax errors. Why waste time looking for these beforehand? Isn't this a retrograde step? The book's rejoinder is that syntax errors might be considered to be distributed like more serious logic errors. Hence, if you review before compiling, and find 80% of the syntax errors that the compiler finds, then perhaps you only also found 80% of the logic errors. Opps? A simple and ingenious self diagnostic tool. But despite the logic of this, water will flow uphill before any significant portion of programmers adopts this method. Pressing 'make' or its equivalent to do a compilation is simply too easy. The book is on far more plausible ground describing the other aspects of PSP.

    1 out of 1 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted January 13, 2014

    Silverfang

    Never mind not here

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 19, 2013

    To Peace

    Great! -Jaysoar

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 11, 2013

    To Peace the epic

    Shes gonna join WindClan? No way.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 10, 2013

    Min to Peace

    Huge fan of the story! Thank you for using Raindapple in rp :) its also one of my favorite names!!! Keep up the story please! I luv! ~Min

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted April 10, 2013

    Kate and the Clans ~ Chapter 3

    "There are four Clans of wild cats. These Clans are WindClan, RiverClan, ShadowClan, and my previous Clan, ThunderClan." Bluestar stops for a moment. "Wait, previous? Which Clan are you in now?" I ask. "StarClan. StarClan is a place for the loyal who have died." Alarm makes my....fur....prickle as she says this. "You're dead?" I gasp. But I quickly calm myself, and even laugh. "This is nothing but a dream! A stupid, stupid dream!" I say in between the crazy giggles. I laugh for a long time. Long enough that my stomach starts to hurt, my eyes are tearing up, and I'm gasping for breath. But I eventually stop, and my somber mood sets in. "No....this isn't a dream. Nightmare. This is a nightmare." I say quietly. The tears are now threatining to spill over. I look up to Bluestar. "Why? Why have you done this to me?" Oddly enough, I feel betrayed. But I shouldn't. Anger, yes. Confusion, yes. But not betrayal. Because for there to be betrayal, one has to trust another. And I've only known this cat for not even an hour. "Go. Find a Clan, and join." She says softly. She touches her nose to my forehead, and a warm, glowing feeling settles over my body, only lasting for a few moments. I look up to her, surprised to find that she seems bigger. I step back, towards the lake, and find that my new body seems to have shrunk. And, around my face in particular, it looks as though my fur has grown more fuzzy and soft. I turn back around just in time to see Bluestar disappearing. "No! Wait! Bluestar, come back!" I shriek, pouncing on the place where she had been. I grunt when I end up landing chin-first, a jolt of pain searing through my jaw. I lay there for a few moments, unsure of what to do. I really wish that I hadn't gone all insane, so that Bluestar could have explained more. But would she have? I'm honestly not sure if she's my ally.....or my enemy. And if she's the latter, why would she give me information that could help me get back to where I was before? But perhaps if I find one of these Clans, perhaps then some more of this confusing puzzle could be revealed. Maybe I could join....StreamClan, was it? CreekClan.....no......WaterClan? I can't remember. Something to do with liquid, I was sure. I shrug to myself and pick a random direction, heading across clear moorland, no trees or growth of any kind in my sight. Just as I'm nearing a forest, after what seems like hours of walking, I hear an angry yowl behind me, and turn to see a group of cats racing towards me at full speed.~~~~~~~~~~Originally, I was going to have Bluestar explain it ALL. Then I realized that I was giving the info away too fast, and have now decided to slowly give it away over the chapters. >:3 Deal with it. Also, I want to thank everyone who has posted good reviews of my fanfic! Thanks so much! And a particular thank you belongs to Min for giving me some great name ideas! Hope you don't mind if I use Raindapple in a RP, I think it's a really cool name! Also, if you have a question or want to hear any news involving this story(i.e. when/if a new chapter is up), then go to 'kate and the clans' first result!

    Was this review helpful? Yes  No   Report this review
Sort by: Showing all of 6 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)