Rating: 
Summary: New Concepts, New Paradigm
Review: We, as the authors of Inroads, are responding to critique of our book. Comments are somewhat misleading to others who are considering our book, and we wish to clarify some issues.
First, let us comment on the book itself. Our original intent in writing a quality book was to divide up the chapters between us and to tie everything to existing technology, as it relates to Software Quality. The book was intended to be a survey, with a minimal number of completely developed concepts.
In terms of our backgrounds: For more than 25 years, Vern pioneered, developed, and taught Software Engineering courses for IBM Technical Education. As a Professor of Computer Science, he taught the same courses in a different format at Brigham Young University for about the same period of time. He served as Vice President of Software Development at Novell, where they developed an outstanding test organization. He also spent 2 years at SunSoft as a Senior Staff Engineer in the Software Engineering group. He has consulted widely in industry and helped Microsoft and other companies develop test organizations and implement testing strategies, and he has given many keynote addresses at major international conferences on Software Design, Getting Software Products to Market, Software Testing, and Software Quality Assurance. He was on IBM's release team for Information Engineering and Software Economics and participated in their installation into various Fortune 500 companies.
Alka is a Certified Lead ISO-9000 auditor with Registrat Accreditation Board (RAB); she is also a Certified Quality Analyst. She has 19 years of experience in software development and quality. She has been a frequent speaker on quality assurance issues at various international as well as domestic events and has consulted with companies such as Bank of America, Pacific Bell, Apple, Charles Schwaub, Cisco, Pacific Gas and Electricity, and others. She is an adjunct professor at Santa Clara University in the MBA program for Computer Science. She is also an instructor for University of California, Berkeley (extension), and University of Santa Cruz (extension). Alka won the 1997 Silicon Valley "Corporate Woman Advocate of the Year" Award for her accomplishments in the Software Quality field. She is the president of Bay Area Quality Assurance Association and has been an applied Total Quality Advisory Board Member for UC Berkeley Extension and also an advisory board member to the certificate program in Continuous Improvement and Quality Management for UC Santa Cruz extension. She is the vice president of the Indian Business and Professional Women Organization. Recently, she has been asked to head a committee to design a certificate in Software Testing and Quality Assurance for UC Berkeley Extension.
Based on many years of practical experience, through Vern's current position as a Vice President at Digital Technology International, we developed a completely new paradigm for software delivery and software quality. We readily recognized that we were building on the shoulders of many earlier software pioneers, and our book was dedicated to some of them. {Please note that in our dictionary, we find that the definition of a paradigm relates to either a "model" or a "pattern" and it is in that context that we are using it. Basically, we have taken a product delivery process similar to those used in manufacturing and modified it to fit Deming's model, as applied to software.
As we developed this new paradigm for a Deming-oriented Product Delivery Process, we recognized that much of the traditional approach to software development could not be used in the traditional manner.
New Concepts:
The new paradigm came from taking old, widely used patterns and converting them to a completely different context, which fits well into the dictionary's definition of "paradigm."
[1] Since a Product Delivery Process is a "process," it naturally follows the structure theorem of Structured Programming and conforms to general systems theory.
[2] The model, at any given point, was to take an ad hoc team, have them build a "product", have them create a "filter," and then have them pass the product through the filter. If it does not pass that filter, then both filter and the product are fixed. Note that filters provide 3 types of information, regardless of the form they take:
(1) They measure completeness.
(2) They measure accuracy (as opposed to "precision.").
(3) They measure quality (of each part).
For this to work, there must be a way to link each of these processes for building products to other parts of the delivery system. Each filter has a person who is "accountable" for determining if the product or any other product, at that point, passes the filter. At each point in the process, where there is a hand-off, both individuals involved certify that all previous steps have been taken and that the successive versions of the product, i.e., Product Positioning Document, Preliminary Marketing and Sales Plans, Software Architecture, the actual Software Program, Delivery System, etc. have passed through the appropriate filters.
Note that we talk about ad hoc teams, based on our 20+ years of experience using them, at appropriate points throughout the book, not just at the one point, where Mr. Meyn expected more help. We have interacted personally with Michael Fagan, Tom Gilb (whose book was not out when ours was submitted for publication), and others, including Tom DeMarco, and we count them as personal friends.
Filters can be checklists, templates, forms, computer screens, etc. They are characterized by the fact that, as with a coffee filter we describe in the book, the "grounds" (errors) are filtered out. If later on, a defect is found, we go back and fix the hole in the filter, and any other potential holes which allowed the error to pass through. This allows us to define errors as process failures rather than coding errors (or other types of errors). Rather than using metrics to determine several months or years later what the quality of our product might be, the filters provide us with immediate feedback, and EVERY PART OF THE PROCESS THAT WAS BROKEN, I.E., LET THE ERROR PASS THROUGH is fixed, as well as the defect. This allows us to find training errors, errors in sales brochures, marketing and product design failures, installation errors, and documentation errors, as well as errors in the code.
[3] Any error can be applied to the ISO-9000 and CMM standards of:
(1) Error detection.
(2) Root cause.
(3) Corrective action.
(4) Preventive action.
This leads to "continuous process improvement" leading to "zero defects,"etc.
Evidently Mr. Meyn missed the point that the checklists provided, as well as templates and outlines in the appendix. These are tools and will only work if they are part of the process model (e.g., paradigm) on which they are based.
As to our "promise of a new paradigm in software quality assurance," the paradigm provides:
[1] A model or pattern for a product delivery process, with an extremely effective feedback mechanism.
[2] A set of programming and software architectural quality standards to which the product must conform, but they are extremely sensitive to "technological failures." Thus, there is no discussion or arguments as to what to include and what not to include on the part of team participants. We chose to define our quality standards in terms of their impact on the new paradigm, rather than parrot back the IEEE standards, which we feel only partially fit.
[3] The ability to have both the software product and its quality measures conform to "zero defect" standards is also important. Because the filters "learn" while they are being used, they gradually evolve into more and more effective tools. They are not static, nor is the proce
| 
