Product Description

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.

Product Details

• Amazon Sales Rank: #101323 in Books
• Published on: 2005-03-13
• Original language: English
• Number of items: 1
• Binding: Hardcover
• 368 pages

From the Back Cover

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.

PSP^SM: 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.

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

Excerpt. © Reprinted by permission. All rights reserved.

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.¹ 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).² 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 managemen...

Customer Reviews

Applies well in some but not all situations...
As an IT professional and software developer, I'm all for standards and processes. PSP - A Self-Improvement Process for Software Engineers by Watts S. Humphrey (Addison-Wesley) outlines a personal methodology for improving your development efforts. But it's definitely not applicable to all environments...

Chapter List: The Personal Process Strategy; The Baseline Personal Process; Measuring Software Size; Planning; Software Estimating; The PROBE Estimating Method; Software Planning; Software Quality; Design and Code Reviews; Software Design; The PSP Design Templates; Design Verification; Process Extensions; Using The Personal Software Process; Index

From an overall perspective, I think the concepts in here are good and the book is well-written. Watts has devised a methodology that a developer can apply on their own to improve their coding, estimating, and defect resolution skills. This is done by extensive measurement and recording of statistic and time taken to accomplish certain tasks. These numbers are transferred to forms that can then be statistically analyzed to see the trends and make corrections in your techniques based on personal problem areas. The advantage that this methodology offers is that you don't have to get buy-in from an entire department in order to implement it. Conversely, PSP can be extended to apply to a team development environment in order to improve everyone's ability to work and develop code as a group.

Where I start to have issues is that it doesn't translate well to all environments. It's best applied to situations where you're developing programs with actual lines of code (like Java or C++) that allow you to do things like count lines of code, program sizes, or function points. It doesn't address rapid application development (RAD) environments like Lotus Notes/Domino very well, as "lines of code" is often next to nothing. Graphical design techniques that code underlying "plumbing" will make your numbers seem very small. Counting and tracking defects could be useful, but once again you'll often have to ignore stats related to defects per program size. You'll also need to be pretty comfortable with statistics to work with this methodology, as Watts gets into some pretty large formulas to generate the "score" of some of the tracking measures.

This is one of those books where if I were coding 15000 line Java programs, I might be really excited. Developing in a RAD environment makes me see a lot of this as unnecessary tracking for tracking's sake. But if you're a "true software engineer" in the most traditional sense, you'll probably find things in here that you'll want to try out.

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.

A crackpot who made it big.
Watts Humphery is a crackpot. There are some perfectly splendid, even renown authors in software engineering such as Brooks and Sommerville. Those books are practical guides to the management of software projects and even the solution of large and complex software problems. Watts Humphery, on the other hand seems to have arrived at this demented philosophy that the solution to every software problem is careful time logging! He even describes how he logs and categorizes his time as an author as if it were somehow instrumental to his writing process. He believes that any technical problem can be solved by nothing more than measuring the process by which it is solved. Some of the things he lists as goals, such as "zero errors on the first compile" take no account of the problems of incompletely documented systems and experimental coding, which is often unavoidable, especially for younger programmers. If your professor lists this as the course text, drop the course and start looking for a better university!