THE SQA CHARTER Find defects so they can be REMOVED Anticipate defects so they can be PREVENTED.  Software Quality Assurance 

CONCEPTS: The Two V's Validation: "Are we building the right product?"[End-User] Verification: "Are we building the product right?" NOTE: A program totally lacking documentation may pass the test of VALIDATION, but may fail VERIFICATION if the organization requires comments in the code.  Software Quality Assurance 

PREMISE Definition: Correctly following a correct process yields a correct product. Thus, SQA has three concerns: (1) End-product (2) The process (3) Adherence to the process  Software Quality Assurance 

SQA is concerned with PROCESS IMPROVEMENT (1) An excellent process prevents certain defects (2) A good process detects certain defects and ensures that they are REMOVED (3) Defects can be traced back to steps in the process where they are introduced, or where they escaped detection. (4) An excellent process traces defects back to the root cause, then eliminates the root cause.  Software Quality Assurance 

A DILEMA: CONSISTENCY Example: Suppose you took an English paper to three different teachers and go grades of C, A, and B. Each grade reflects that teacher's judgment of the QUALITY of the paper. But lack of consistency makes it hard for you to know the true quality of the paper. Consistency Requirement: The judgment of quality must be independent of the person performing the assessment. SQA must be more that a set of opinions.  Software Quality Assurance 

FOUNDATIONS OF SQA: MENTALITY: SQA is obsessive about finding defects. STANDARDS: Set of products generated by a software development, and the rules for creating the product. content -- what must be included in the product style -- the appearance/format of product (e.g., double-spaced, font size, layout) semantics -- whether the information is meaningful and correct.  Software Quality Assurance 

FOUNDATIONS OF SQA [continued] Standards must be well defined, and assistance must be provided to ensure conformance to style and content: std_ file => definition of the product frm_ file => blank form for specifying an actual product.  Software Quality Assurance 

FOUNDATIONS OF SQA [continued] CHECKLISTS: List of the types of defects (errors) that may occur for a given type of product. Each type of product has its own checklist Checklist is NEGATIVE, pointing out the type of DEFECT Checklist is based on ACTUAL ERRORS -items will be added as needed -some items will become obsolete when the process begins to prevent a particular type of defect  Software Quality Assurance 

FOUNDATIONS OF SQA [continued] DEFECT METRICS: Defects of each type are tallied (counted) and reported. It is possible to identify the MOST COMMON defect, and to show TRENDS (over time, some defects should drop off the "best seller" list).  Software Quality Assurance 

FOUNDATIONS OF SQA [continued] CAUSAL ANALYSIS: SQA should understand when and how a particular defect was introduced. Problem tracking database Root cause analysis Recommendation for process improvement to prevent or detect defect Defect "age analysis" -- how long defect existed before being detected.  Software Quality Assurance 

THE IMPACTS OF SQA ON AN ORGANIZATION: (1) ATTITUDES: Usually SQA seen in negative light, since their job is to bring BAD NEWS (here's what's wrong) Positive perspective: SQA "has the back" of the software developers, even the organization. SQA should be integrated into the software process, rather than lying in ambush after the fact. (2) SQA may cause REWORK to be done Resistance by developers, management, because of schedule Slips and cost overruns. Organization must understand the COST OF QUALITY: Lack of quality results in loss of customers (sales revenue).  Software Quality Assurance 

THE SQA QUALITY AUDIT Function: Perform an assessment of the quality of a product. Inputs: Products (e.g., files containing one or more products of the given type) Product Standards (from SQA) Checklist (from SQA) Outputs: Tallied checklists Red-lined (edited, handwritten) hardcopies Audit summary report Revisions to the checklist  Software Quality Assurance 

THE SQA QUALITY AUDIT [continued] Follow-Up: SQA disseminates findings to developers Developers fix errors Findings as inputs to Defect Causal Analysis Findings combined into organization statistics  Software Quality Assurance 

THE SQA CHARTER Find defects so they can be REMOVED Anticipate defects so they can be PREVENTED.  Software Quality Assurance 

THE END OF THIS MODULE This is THE END of the Software Quality Assurance Module !!!  Software Quality Assurance 