Members Log In to My ASQ Members Log In   View Shopping Cart Shopping Cart   Quality Progress Magazine Quality Progress Magazine Make Good Great
Magazines & Journals
Software Quality Professional

Printer Friendly
Issues
I Want To
Article Access Key
  • Public Article
  • Log-In to View
  • Full, Senior, or Fellow members with no subscription.
  • Full, Associate, Forum/Division, Senior or Fellow members who are also subscribers.
  • Enterprise and Site Members have access to all issues.

December 2002
Volume 5 • Number 1

Contents

From the Editor

As editor of one of the journals published by the American Society for Quality (ASQ), I was asked to join the other journal editors in providing a guest editorial for the newest ASQ publication, Six Sigma Forum Magazine. My comments were published in the August 2002 issue.

Given that most of you probably did not have the opportunity to see that material—and because I continue to solicit such content for this journal—I would like to share a version of those thoughts with the readers of SQP.

I welcome the renewed interest in, and heightened commitment to, process improvement represented by Six Sigma initiatives.

As a quality professional with a career in software development and assessment, I am heartened to see Six Sigma expand beyond its manufacturing origins with an ever-wider application of systematic techniques for understanding customers, refining business processes, and making fact-based decisions.

Software-dependent systems have often seemed a breed apart in the eyes of both customers and quality professionals. How often do we see these systems fail and realize that consumers would not tolerate such imperfection in tangible goods or well-defined services? Is it because of a culture of valuing technically elegant solutions, whose deficiencies are
tolerated because of the “gee whiz” nature of the technology?

The wonder is that so many organizations have done as well as they have for so long with software-intensive systems that have been developed, operated, and maintained in essentially a craftsman mode. The majority of software suppliers score out as “Level One,” where ad hoc activities depend for success on strong personalities and heroic actions.

We can scarcely be content with such immaturity. From automobile performance to financial transactions to infrastructure control, our society has become critically reliant
on all manner of software-dependent systems. Indeed, the Six Sigma enterprise itself, with its data gathering and computational requirements, stands or falls on the availability and accuracy of software tools.

A data-driven approach to analyzing the root causes of business problems may well provide the catalyst to remind us that computationally intensive systems are not acquired or used in isolation from the larger business processes and market environment of an organization.

Software Quality Professional published its first (and, to date, only) article on this topic in December 2001: “Six Sigma for Internet Application Development” by H. James Harrington and Tom McNellis. ASQ’s Software Division included Robert Stoddard’s informative presentation “Six Sigma for Software” in its sponsored track at the May 2002 Annual Quality Congress. We are actively on the lookout for more such material.

We are learning that measurement systems must look at total system life-cycle costs and focus on actions that minimize these costs. As recognized in a cost-of-quality model, the costs to control quality are planned, scheduled, and budgeted. On the other hand, the costs of not controlling quality accumulate from failures that seem to happen at the most inconvenient times and often are budget busters. Planning and implementing process improvement are deliberate investments. When these measures prove inadequate, an organization enters the unscripted realm of crisis response, disaster recovery, and reputation repair.

The primary challenge I see is the application of statistical analysis to the proper “figure of merit” for software quality. Six Sigma practitioners must identify useful metrics and use them both to identify areas needing improvement and to validate process changes.

Software product defect counts are not truly satisfactory as a measure of quality or a target for process improvement. Defects (a static property) may or may not lead to unacceptable
system behavior (a dynamic property). It is the frequency and severity of these failures that truly measure quality, yet failure data are a lagging indicator when we need a leading indicator. What leading indicators can we identify for software quality?

I look to the continued maturing of Six Sigma, especially as the methodology is turned upon itself for refinement. Its application to software development can lead to the virtuous cycle of improved tools providing improved insights for providing even more improved tools.

Success stories are always inspiring and can be instructive to others. I call upon you to embark upon improvement initiatives and then to share your own success stories with the wider community. The pages (and Web site) of this journal are open to your submissions.
Let us hear from you.

-Taz

The full text of this article may be found in the print journal. To subscribe go to /quality-press/display-item/index.html?item=SUBSCR_SQP .

Return to Top