SQA V And V Intro & History


Published on

This presentation will help you better understand Software Quality Assurance, Verification & Validation and its history.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Dial into Meeting Place - 7927
  • SQA V And V Intro & History

    1. 1. SQA / V & V May 15, 2009
    2. 2. Questions you have… <ul><li>So what is SQA? </li></ul><ul><li>What do I need to know about it? </li></ul><ul><li>Why is it important to me? </li></ul><ul><li>What is V & V and how does it fit with SQA? </li></ul><ul><li>Who will be impacted by the intro of SQA/V&V? </li></ul><ul><li>How will SQA / V&V effect the next release of SDLC, EPIP, ExPIP? </li></ul><ul><li>What is being added to our capital/expense processes that I need to know about? </li></ul>
    3. 3. Simple definitions <ul><li>Quality testing – process of planning and executing tests to identify defects, failures, and incompatibilities </li></ul><ul><li>Quality control – measured degree of conformance to functional requirements, standards (according to Good Software Engineering Practices – GSEP) e.g. inspections, audits, KPIs) </li></ul><ul><li>Quality Assurance (aka. SQA) </li></ul><ul><ul><li>activities planned (process) and conformance established in (requirements, standards, budget) provide adequate confidence in software development for business solutions. </li></ul></ul><ul><ul><li>it is the implementation of policies and procedures intended to prevent defects from occurring in the first place. </li></ul></ul>
    4. 4. Quality Software Portability Product transition Reusability Interoperability Correctness Product operation Reliability Efficiency Integrity Usability Product revision Maintainability Flexibility Testability Source: McCall’s factor model tree
    5. 5. What do I need to know about SQA? <ul><li>Brief history of Quality’s history </li></ul><ul><li>The exponential cost of defects </li></ul><ul><li>Everyone has the responsibility for quality </li></ul><ul><li>Measuring quality will help us better manage quality </li></ul><ul><li>Sound requirements are key…we build code and maintain code, when we build requirements, we should maintain requirements </li></ul>
    6. 6. Heritage of Software Quality Assurance <ul><li>Early 50’s software procured by Dept of Defense (DoD) </li></ul><ul><ul><li>Behind schedule </li></ul></ul><ul><ul><li>Over budget </li></ul></ul><ul><ul><li>Had many technical problems </li></ul></ul><ul><ul><li>Software never worked as intended </li></ul></ul><ul><ul><li>Projects cancelled after before anything of value could be delivered </li></ul></ul><ul><ul><li>Lacked visibility of software development projects </li></ul></ul><ul><li>From this evolved from base principles of Independent Verification & Validation (IV&V) </li></ul>
    7. 7. Birth of IV & V <ul><li>For Atlas Missile Program </li></ul><ul><ul><li>“ independent software tester” was established hired to perform unbiased software testing </li></ul></ul><ul><ul><li>Role of “IV&V contractor” was born </li></ul></ul><ul><ul><li>During the 70’s, software development expanded and companies experienced the same thing the DoD experienced </li></ul></ul><ul><ul><li>Even into the 80’s many projects in development became “disasters” </li></ul></ul><ul><ul><li>Usage today of IV&V contractors is quite comprehensive </li></ul></ul><ul><ul><li>Additionally, from this “software crisis”, the emergence of Software Quality Assurance (SQA) was born </li></ul></ul>
    8. 8. SQA, the Early Years <ul><li>Initially, SQA struggled to show value </li></ul><ul><ul><li>In 1990’s software complexity increased significantly </li></ul></ul><ul><ul><li>Competitive business pressures existed </li></ul></ul><ul><ul><li>Professionals performing SQA functions lacked formal training </li></ul></ul><ul><ul><li>Many learned SQA practices on-the-job </li></ul></ul><ul><ul><li>Learning institutions failed to recognize SQA as a legitimate discipline </li></ul></ul><ul><li>SQA eventually matured and was recognized and now provides exponential value in today’s complex software development process environment </li></ul>
    9. 9. So, What is SQA? <ul><li>Pillars of SQA (Quality starts at the beginning) </li></ul><ul><ul><li>Product </li></ul></ul><ul><ul><ul><li>Solid requirements </li></ul></ul></ul><ul><ul><ul><li>Project Dev plans and Quality plans </li></ul></ul></ul><ul><ul><ul><li>Configuration management plans </li></ul></ul></ul><ul><ul><ul><li>Software quality metrics and KPIs </li></ul></ul></ul><ul><ul><li>Process </li></ul></ul><ul><ul><ul><li>Formal design reviews </li></ul></ul></ul><ul><ul><ul><li>Peer reviews, Inspections and Audits </li></ul></ul></ul><ul><ul><ul><li>Comprehensive Software testing </li></ul></ul></ul><ul><ul><ul><li>Quality training and participation </li></ul></ul></ul><ul><ul><ul><li>Project, process, & quality standards and compliance </li></ul></ul></ul>
    10. 10. IEEE/ISO 9000 Definition of SQA <ul><li>Software Quality Assurance is: a systematic, planned set of actions necessary to provide adequate confidence that the software development process or the maintenance process of a software system product conforms to established functional technical requirements as well as with the managerial requirements of keeping the schedule and operation within the budget ary confines. </li></ul>
    11. 11. Why is SQA important to me? <ul><li>Provides a framework for each participant to be responsible for quality </li></ul><ul><li>Enables empowerment as each participant engages in product delivery </li></ul><ul><li>Shared accountability for meeting our customer expectations and delivering quality solutions. </li></ul>
    12. 12. Software defects identified early in the development lifecycle, translates into a significant cost savings over the duration of the project
    13. 13. Nine major causes of software errors <ul><li>Faulty requirements definition </li></ul><ul><li>Business – IT communication failures </li></ul><ul><li>Deliberate deviations from software requirements </li></ul><ul><li>Logical design errors </li></ul><ul><li>Coding errors </li></ul><ul><li>Non-compliance with documentation and coding instructions </li></ul><ul><li>Shortcomings of the testing process </li></ul><ul><li>User interface procedure errors </li></ul><ul><li>General documentation errors </li></ul><ul><li>Source: Software Quality Assurance by Daniel Galin </li></ul>
    14. 14. Where will I see SQA and how will I recognize it? <ul><li>Analysis </li></ul><ul><li>Requirements Development and Management </li></ul><ul><li>Change Impact Analysis </li></ul><ul><li>Requirements Walk-throughs & Peer Reviews </li></ul><ul><li>Design </li></ul><ul><li>Requirements Traceability and Repository </li></ul><ul><li>Design Document review </li></ul><ul><li>Design Walk-throughs & Peer Reviews </li></ul><ul><li>BRD & FSD Reconciliation </li></ul><ul><li>Functional Decomposition </li></ul><ul><li>Coding </li></ul><ul><li>Code Walk-throughs, Inspections and Audits </li></ul><ul><li>Peer Reviews </li></ul><ul><li>Software Configuration Mgmt Plan </li></ul><ul><li>Testing </li></ul><ul><li>Test Plan Walk-throughs </li></ul><ul><li>Causal Analysis </li></ul><ul><li>KPIs & Metrics </li></ul><ul><li>Separation of QA Testing and UAT testing </li></ul>
    15. 15. <ul><li>It must be understood that quality cannot be the assigned function of any one person or organization; rather, it must be the primary responsibility of every person involved in the development of the product. </li></ul>Quality is everyone's job!
    16. 16. What is V & V and how does it fit with SQA? <ul><li>Verification ensures that “you built it right.” </li></ul><ul><li>Validation ensures that “you build what the customer asked for.” </li></ul><ul><li>V & V laid the foundation for SQA </li></ul>
    17. 17. Verification & Validation Model BRD’s FSD’s DDD’s Reviews Walk-throughs Audits Integration & Smoke Testing Functional & Regression Testing UAT & Beta Testing
    18. 18. V & V Practices <ul><li>Design Reviews – participants are project leads and business sponsors and are charged with formally ensuring the design documents are reviewed and approved before the project development begins </li></ul><ul><li>Peer Reviews: Walk-throughs – informal review of designs and constructed code which includes an overview of the objective and developed artifacts </li></ul><ul><li>Peer Reviews: Inspections – formal review of designs and constructed code with an objective focused on corrective action – contribute more significantly to overall SQA </li></ul><ul><li>Software Audits – evaluation of conformance of software products to standards, guidelines, plans and procedures </li></ul><ul><li>Traceability – mapping of requirements, specifications, and tests to ensure complete coverage </li></ul>
    19. 19. Metrics & KPIs <ul><li>In-process QA Metrics </li></ul><ul><ul><li>M1: Test Execution Progress </li></ul></ul><ul><ul><li>M2: Test Execution by Functional Areas </li></ul></ul><ul><ul><li>M3: Open Defects in Release by Status </li></ul></ul><ul><ul><li>M4: Test Design Coverage by Modules </li></ul></ul><ul><ul><li>M5: Code Stability by Builds </li></ul></ul><ul><li>Testing Effectiveness Metrics </li></ul><ul><ul><li>M6: Defect Leakage </li></ul></ul><ul><ul><li>M7: Defect Removal Efficiency (DRE) </li></ul></ul><ul><ul><li>M8: DRE Trend by Releases </li></ul></ul><ul><li>Production Stability Metrics </li></ul><ul><ul><li>M9: Production Defects by Severity </li></ul></ul><ul><ul><li>M10: Trend of Production Defects (weekly, monthly) </li></ul></ul>
    20. 20. Sample SQA Dashboard views Defect Removal Efficiency - M7 Defect Leakage – M6 M5
    21. 21. Benefits of SQA <ul><li>SQA activities provide independent and objective assessments of the processes and quality of the product with time to react . </li></ul><ul><li>The further along a project is within the development lifecycle; the more costly it becomes to resolve defects. </li></ul><ul><li>Requirements management greatly enhances processes, which provide a clear goal of complete and testable requirement specifications. </li></ul><ul><li>Design and code inspections, as well as post mortems, assist in improving process performance and better efficiencies for future projects. </li></ul>
    22. 22. Critical Success factors of SQA <ul><li>Senior Management support of SQA initiative and process enhancements </li></ul><ul><li>Establish teams’ commitments to follow and comply with SQA process </li></ul><ul><li>Monitor and analyze the SQA process adoption (KPIs, PPQA) </li></ul>
    23. 23. Quotes <ul><li>“To change the quality of your software, you need to change the process used to create it” – Watts Humphrey </li></ul><ul><li>“We can’t manage what you can’t measure” – W. Edwards Deming </li></ul>
    24. 24. In summary <ul><li>This presentation was to introduce you to Software Quality Assurance </li></ul><ul><li>We defined the differences between verification and validation (V & V) </li></ul><ul><li>Highlighted benefits and critical success factors for SQA </li></ul><ul><li>Thank you </li></ul><ul><li>Questions ? </li></ul>