1 / 16

THE SQA CHARTER

Software Quality Assurance . 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]

hammett-livingston
Télécharger la présentation

THE SQA CHARTER

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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.

  3. 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

  4. Software Quality Assurance  SQA is concerned with PROCESS IMPROVEMENT • 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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

  9. 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).

  10. 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.

  11. 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).

  12. 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

  13. 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

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

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

More Related