John Montgomery
Creating reliable software is hard. Creating it consistently sounds like something you do with eye of newt and a bubbling caldron. But it's not: It's a product of the management of process, methods, and tools -- basic quality management. Applying concepts from total quality management to software engineering isn't new, but adopting a complete structure for this application is just becoming popular.
Supermodel
One of the leading structures comes from the Software Engineering Institute (SEI) at Carnegie Mellon University (
http://www.sei.cmu.edu/
). The Department of Defense spo
nsored the SEI with a charter to "advance the practice of software engineering." One of the prime areas of SEI's focus is process, and the lens it uses is the
Capability Maturity Model (CMM)
.
The CMM has five levels that describe advances in the software engineering process. The first level, according to Dave Zubrow, leader of the Software Engineering Measurement and Analysis Team at SEI, "is really no level -- there's no real process at all, and everything is pretty much done ad hoc."
The second level implements processes that make software engineering repeatable. It introduces project planning and tracking, and, most important, it gets project management in place.
The third level documents and standardizes processes at an organizational level. The keys of this level are requirements management, project planning, and project tracking across the organization.
The fourth level focuses on product and process quality -- being able to take measurements about what's hap
pening and feed that information back in a way that project leaders can react to it and use it to make improvements across the organization. At this level, project management can set targets, plan ahead for desired quality, and create a process to meet those targets. In quality management terms, this is the level for eliminating the unique happenings that impact quality.
The fifth and final level is an ongoing improvement process. It works on defect prevention, technology-change management, and process-change management. Says Zubrow, "The idea is to proactively make changes to your software engineering environment to become more efficient and effective."
NASA's Three Rules
SEI's model isn't the only one. For 20 years, the Software Engineering Lab (SEL) at NASA's Goddard Space Flight Center (
http://fdd.gsfc.nasa.gov/seltext.html
) has been working on improving software quality.
Where SEI's CMM takes a top-down approach and works with processes and practices, SEL assumes "that each organization is unique, and because of that, we don't think there is a set of universal practices," according to Rose Pajerski, director of SEL. "There are lots of lists of `best practices.' You have to weigh that against what you want to see in your environment."
SEL's system has three basic steps. The first step is to understand the baseline by collecting product and process data such as error characteristics and also more subjective information (e.g., what mangers think). This step culminates with identifying improvement opportunities and setting clear, measurable product goals. The second step is to experiment with the process and assess the impact of the experiments on the product. The third step is packaging, where SEL pushes the baseline data, experiment results, and updated process into the organization.
SEL has applied its method to itself. Its business goals were to improve softwa
re-development and testing processes and reduce its budget. The practice it employed was a software clean room. The clean room's goal is to build error-free software through statistical quality control.
This means, among other things, that development and testing occur separately -- developers rely on peer review and code reading to ensure that the code does what it's supposed to. Testing concerns itself with quality assessment (not debugging). These two departments pass information back and forth frequently, resulting in an iterative development process. According to Pajerski, SEL reached its goals: The developers are providing high-quality code, and it's costing less.
A Quality Attitude
The two methods are more similar than different. Both of them emphasize quality management concepts, such as implementing repeatable processes, gathering hard statistics about elements such as failure rates, and working with the process to reach your goals. And both stress setting goals
and adapting the method to meet them.
These ideas aren't new -- they've been around at least since Philip Crosby penned
Quality Is Free
in 1979. So why isn't everyone implementing them? The answer is attitude. An understanding of how to achieve quality must permeate an organization. "People are looking for silver bullets. But it's about instilling a new discipline," Zubrow concludes.
illustration_link (158 Kbytes)
John Montgomery is BYTE's features editor You can reach him on the Internet or BIX at
jmontgomery@bix.com
.
Make Quality Job 1
