Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Agile Crash Course: Agile Project Management & Delivery - Master the most important concepts & tools of Agile

Your Company Name Here - Reach 30'000 visitors/month and 35'000 software development professionals for $145.

Personal Quality Management with the Personal Software Process

Alan S. Koch, ASK Process

Abstract

Software development organizations have a variety of mechanisms at their disposal to help in managing and improving the quality of the products they produce. Quality Assurance organizations, problem reporting systems, software process improvement and peer reviews (to name just a few) are important tools for product quality enhancement. But an often-overlooked piece of the quality puzzle may well provide the most effective means to improve product quality: the individual software engineer.

After a short introduction to what the Personal Software Process (PSP) SM ("Personal Software Process" and "PSP" are Service Marks of Carnegie Mellon University) is, we will highlight the ways in which individual engineers (and their organizations) can benefit from adding the PSP's Personal Quality Management techniques to their professional repertoires. We will take a brief look at the benefits that have been achieved by those who have already learned to apply these principles in their work. Then we will examine in more detail the specific activities PSP-trained engineers engage in to manage the quality of the software they produce. We will look at everything from simple defect logging, to personal and peer reviews, to developing a personal quality plan and using it to guide your work.

What is the PSP?

The concepts and activities discussed in this article are the quality management aspects of the Personal Software Process (PSP) developed by Watts S. Humphrey of the Software Engineering Institute (SEI), and described in his book, PSP(sm): A Self-Improvement Process for Software Engineers [Humphrey].

The PSP is more than just training; it is a boot camp consisting of about 40 hours of classroom instruction, 10 programming assignments, and 3 data-analysis exercises, requiring a total of about 150 hours for the average programmer to complete.

The result of the PSP boot camp is that the programmers don't just learn about good processes, they actually improve their own processes,measure the effects of those process changes, quantify the benefits they have experienced, and set goals for further improvements. The PSP achieves these results by leading students through three steps.

In PSP0, they lay a simple foundation for the learning to come:

  • Following simple process scripts,
  • Collecting three basic measures of their work (time spent, size of products produced, and defects corrected), and
  • Performing a simple post-project analysis.

In PSP1, they begin to build the capability to plan and manage their own work, setting the stage for Personal Quality Management:

  • Following a defined project planning process,
  • Using their own prior data to make increasingly more accurate estimates for each programming assignment, and
  • Planning their work at a level of detail that allows them to track and manage their progress.

In PSP2, they focus on achieving significant quality improvements by learning how to engage in Personal Quality Management:

  • Using their prior data to plan for incremental improvements in the quality of their programs,
  • Removing defects early using personal review techniques guided by their own prior defect performance, and
  • Identifying and capitalizing on defect prevention opportunities in their program design and implementation methods.

Those who complete the PSP boot camp emerge with the knowledge and skills to make accurate plans, work to those plans, and produce superior quality products.

The Motivation for Personal Quality Management

Most programmers have never learned to apply personal quality management techniques like those described in this article in their work. This is because our educational system has generally ignored the topic, and in the software business, "quality assurance" often refers to little more than testing. This is unfortunate, because vast opportunities for improving the quality of the software we produce are being missed as we continue with business as usual.

This is surprising, given that these techniques are anything but new. Other engineering disciplines have embraced them for decades and manufacturers and engineering companies have been applying them for nearly fifty years. Methods like these have been researched and described by such luminaries as Walter A. Shewhart and W. Edwards Deming as well as their more modern counterparts.

Watts Humphrey, in the PSP has given programmers the opportunity to understand these methods and apply them to software development. Those who have done so have found the effects on their work to be dramatic, with the improvement in the quality of their software the most obvious and rewarding aspect. These individuals have begun to take control of the task of writing programs, and are taking the first steps toward changing "software engineering" into a true engineering discipline.

Defect Content as a Dimension of Quality</p>

When we think of software quality, we tend to think about defects. This is a natural tendency, since defective software isn't good for much. But defects (or more correctly, lack of defects) is not the only, or even the most important dimension of quality. Other dimensions of quality include Usability, Maintainability, Install-ability, Security, and Reliability. In any product, each of these dimensions is important to one degree or another, and every development project must be careful to pay appropriate attention to them.But from the point of view of Personal Quality Management, defect management is first priority. This is true for two reasons:

  • The other dimensions of quality are issues of either product requirements or organizational standards. While the individual software engineer can affect these things, they are not under his or her direct control.
  • Defect injection is a purely personal phenomenon. Each person's defect numbers, types and patterns are unique, and require personalized actions to effectively detect and eliminate them.

You may note throughout this article that I will never refer to "bugs". I believe that this term trivializes a very important issue, making it sound minor, or even cute. In fact, defective software wastes millions of dollars for companies and individuals throughout the world. And as we become more and more dependent on software for critical functions, it is becoming important to organizations' and individuals' health and life. In order to focus on defects as a quality management priority, we must understand their nature. This nature can be summed up this way:

  • Software that contains one or more defects is "defective".
  • Defects are the result of human errors.
  • All humans make errors.
  • All software engineers are human.

Therefore, defect management must be the first quality management focus for all Software Engineers.

Career Enhancement by Reducing Both Costs and Defects

As professionals, we Software Engineers must assume responsibility for the quality of the products we produce. Our employers pay us for producing not just software, but good software, high-quality software.

The quality assurance organization cannot be thought of as the people who are responsible for quality. Indeed, of all members of the organization, they are in the position that is least able to affect the quality of the product. Testing and other QA activities can detect defects and make sure that they are removed, but quality cannot be tested into the product at the end. Quality must be built in or it will be absent. Therefore, the software engineers are the ones who have the most direct impact on the quality of the product.

It is easy to lose sight of the tremendous costs that defects cause for our employers. Integration and system test can account for 50% of development time (and most of that time is spent in remediation and re-testing to eliminate the scores of defects that are commonly found). Then post-release defect mitigation and removal can cost more than the original development effort (including testing)! Supporting customers, investigating problems and releasing patches consume huge amounts of time and effort. And the cost of defects in loss of customer good will and market image goes beyond even that.

Defect removal costs escalate with each passing lifecycle phase. Different people have estimated different costs at the various phases, but they tend to agree that the costs rise (possibly even exponentially) with each passing phase. (e.g. A defect that might cost one dollar to fix in the requirements phase may cost $10 during design, $100 during coding, $1,000 in test and $10,000 in the field.) Regardless of the specific numbers one might cite, the cost escalation is obvious from the fact that we talk about removing "defects per hour" before Integration, and spending "hours per defect" during and after Integration.

Your value to your employer will be enhanced by your ability to produce salable (or usable) software at a minimum cost. Although the early defect detection and prevention methods we will discuss all have costs associated with them, they are demonstrably less expensive than removing the same defects later in the software lifecycle. So you can reduce costs through defect prevention and early defect removal, while at the same time producing more salable or usable software with fewer delivered defects. You enhance your career and value to your employer by exercising professional responsibility and managing your own quality.

Quality of Work-Life Issues

Practitioners of Personal Quality Management have also found that it has a positive impact on the quality of their work-life.

Most of us went into programming because we enjoy building things and seeing the results of our labor. We like the challenge of figuring out how to attack a problem, of designing the structures and algorithms that will get the job done, and even of writing the code to make it all happen. And we like to see the fruit of our labor integrated into a system that meets people's needs or provides an important service.

But between the coding and use, there is a long and (for most of us) painful time of fighting our way past defect after defect. It starts with the compiler leading us around by our noses, complaining about every little typo and syntax error, and often totally misinterpreting what the code was supposed to say. Then after achieving a clean compile, we try over and over again to get the program to do the right thing. It loops, it hangs, it crashes; and now the debugger is the thing that is dragging us around by the nose. For each problem we fix, there seems always to be another one lurking in the shadows. And even more frustrating is that too often our fix was the cause of the ensuing problem!

But releasing the software doesn't end this frustration. Right when we're in the middle of designing the next interesting program, we get interrupted to fix a latent problem. There is a fuming customer and an unhappy boss, so we must drop everything to make an emergency fix. And to add insult to injury, the interruption of our design work is likely planting the seeds for future problems and their interruptions and frustrations.

Personal Quality Management allows us to gain control over defects. Instead of being ruled by the defects in our software, we can gain the upper hand. We can understand them, find them, remove them earlier and even avoid them altogether. That means that we will spend a much greater proportion of our time on the tasks we enjoy, and less on the problems we missed. That is a significant improvement in our work-life!

© 2000-2007 Copyright ASK Process, Inc.

Go to page 2   Back to the archive list

Methods & Tools
is supported by


Simpliv IT Courses

Vornexinc.com

Testmatick.com

Software Testing
Magazine


The Scrum Expert