SOFTWARE QUALITY ASSURANCE (Part 1) - By Roger Sperman

SOFTWARE QUALITY ASSURANCE

The software engineering approach described in this book works toward a single goal: to produce high-quality software. Yet many readers will be challenged by the question: "What is software quality?"      
Philip Crosby [CRO79], in his landmark book on quality, provides a wry answer to this question:

The problem of quality management is not what people don't know about it. The problem is what they think they do know . .            

In this regard, quality has much in common with sex. Everybody is for it. (Under certain conditions, of course.) Everyone feels they understand it. (Even though they wouldn't want to explain it.) Everyone thinks execution is only a matter of following natural inclinations. (After all, we do get along somehow.) And, of course, most people feel that problems in these areas are caused by other people. (If only they would take the time to do things right.)

Some software developers continue to believe that software quality is something you begin to worry about after code has been generated. Nothing could be further from the truth! Software quality assurance (SQA) is an umbrella activity that is applied throughout the software process.
SQA encompasses (1) a quality management approach, (2) effective software engineering technology (methods and tools), (3) formal technical reviews that are applied throughout the software process, (4) a multi tiered testing strategy, (5) control of software documentation and the changes made to it, (6) a procedure to ensure compliance with software development standards (when applicable), and (7) measurement and reporting mechanisms.

1. QUALITY CONCEPT

It has been said that no two snowflakes are alike.  Certainly when we watch snow falling it is hard to imagine that snowflakes differ at all, let alone that each flake possesses a unique structure. In order to observe differences between snowflakes, we must
examine the specimens closely, perhaps using a magnifying glass. In fact, the closer
we look, the more differences we are able to observe.
This phenomenon, variation between samples, applies to all products of human as well as natural creation. For example, if two “identical” circuit boards are examined closely enough, we may observe that the copper pathways on the boards differ slightly in geometry, placement, and thickness.  In addition, the location and diameter of the holes drilled in the boards varies as well.
All engineered and manufactured parts exhibit variation. The variation between samples may not be obvious without the aid of precise equipment to measure the geometry, electrical characteristics, or other attributes of the parts.  However, with sufficiently sensitive instruments, we will likely come to the conclusion that no two samples of any item are exactly alike.
Variation control is the heart of quality control. A manufacturer wants to minimize the variation among the products that are produced, even when doing something rel-atively simple like duplicating diskettes.  Surely, this cannot be a problem—duplicat-ing diskettes is a trivial manufacturing operation, and we can guarantee that exact duplicates of the software are always created.
Or can we?  We need to ensure the tracks are placed on the diskettes within a specified tolerance so that the overwhelming majority of disk drives can read the diskettes. In addition, we need to ensure the magnetic flux for distinguishing a zero from a one is sufficient for read/write heads to detect. The disk duplication machines can, and do, wear and go out of tolerance.  So even a “simple” process such as disk duplication may encounter problems due to variation between samples. 
But how does this apply to software work? How might a software development organization need to control variation? From one project to another, we want to minimize the difference between the predicted resources needed to complete a project and the actual resources used, including staff, equipment, and calendar time. In general, we would like to make sure our testing program covers a known percentage of the software, from one release to another. Not only do we want to minimize the number of defects that are released to the field, we’d like to ensure that the variance in the number of bugs is also minimized from one release to another. (Our customers will likely be upset if the third release of a product has ten times as many defects as the previous release.) We would like to minimize the differences in speed and accuracy of our hotline support responses to customer problems. The list goes on and on.

1. Quality
   Quality of design refers to the characteristics that designers specify for an item. The grade of materials, tolerances, and performance specifications all contribute to the quality of design. As higher-grade materials are used, tighter tolerances and greater levels of performance are specified, the design quality of a product increases, if the product is manufactured according to specifications.
   Quality of conformance is the degree to which the design specifications are followed during manufacturing. Again, the greater the degree of conformance, the higher is the level of quality of conformance.
   In software development, quality of design encompasses requirements, specifications, and the design of the system. Quality of conformance is an issue focused primarily on implementation.  If the implementation follows the design and the resulting system meets its requirements and performance goals, conformance quality is high.
   
   
   
   
2. Quality Control
   Variation control may be equated to quality control. But how do we achieve quality control? Quality control involves the series of inspections, reviews, and tests used throughout the software process to ensure each work product meets the requirements placed upon it. Quality control includes a feedback loop to the process that created the work product. The combination of measurement and feedback allows us to tune the process when the work products created fail to meet their specifications.
   This approach views quality control as part of the manufacturing process. Quality control activities may be fully automated, entirely manual, or a combination of automated tools and human interaction. A key concept of quality control is that all work products have defined, measurable specifications to which we may compare the output of each process.  The feedback loop is essential to minimize the defects produced.
3. Quality Assurance
   Quality assurance consists of the auditing and reporting functions of management. The goal of quality assurance is to provide management with the data necessary to be informed about product quality, thereby gaining insight and confidence that product quality is meeting its goals. Of course, if the data provided
   through quality assurance identify problems, it is management’s responsibility to address the problems and apply the necessary resources to resolve quality issues.
4. Qost of Quality
   The cost of quality includes all costs incurred in the pursuit of quality or in performing quality-related activities.  Cost of quality studies are conducted to provide a base line for the current cost of quality, identify opportunities for reducing the cost of quality,and provide a normalized basis of comparison. The basis of normalization is almost always dollars. Once we have normalized quality costs on a dollar basis, weHave the necessary data to evaluate where the opportunities lie to improprocesses. Furthermore, we can evaluate the effect of changes in dollar-based terms.
   Quality costs may be divided into costs associated with prevention, appraisal, and failure. Prevention costs include :
   ·         quality planning
   ·         formal technical reviews
   ·         test equipment
   ·         training
   Appraisal costs include activities to gain insight into product condition the “first time through” each process. Examples of appraisal costs include:
   ·         in-process and interprocess
   ·         inspection equipment calibration and maintenance
   ·         testing
   Failure costs are those that would disappear if no defects appeared before shipping a product to customers. Failure costs may be subdivided into internal failure costs and external failure costs. Internal failure costs are incurred when we detect a defect in our product prior to shipment. Internal failure costs include :
   ·         rework
   ·         repair
   ·         failure mode analysis
   External failure costs are associated with defects found after the product has been shipped to the customer. Examples of external failure costs are :
   ·         complaint resolution
   ·         product return and replacement
   ·         help line support
   ·         warranty work