0
4/11/2012   © David I. Heimann   1
Contents• Introduction to SQA and IEEE 730• Process Implementation• Product Assurance• Process Assurance• Annexes and Summ...
4/11/2012   © David I. Heimann   3
What is IEEE 730?• Gives guidance and establishes requirements for  Software Quality Assurance in a software project.• The...
The 43 System &Software Process Areas                                    SQA                                    Process   ...
What Is Software Quality Assurance?  • A set of activities that →       – defines and assesses the adequacy of software   ...
ꞌꞌEstablished Requirementsꞌꞌ  • The set of requirements that the project has:       – verified as satisfying project-speci...
SQA Is Not • Testing • Reviewing or Auditing • Done only at the end of development • Reactive • A gate or ꞌꞌpoliceꞌꞌ • An ...
Why SQA? • Fewer defects in the processes used to develop   software. • Fewer defects in business rules and requirements. ...
You Don’t Want This            http://www.amazingonly.com/cartoon/software-bugs-life/4/11/2012                            ...
4/11/2012   © David I. Heimann   11
SQA Activity AreasI.          Process ImplementationII.         Product AssuranceIII. Process AssuranceThere are 16 SQA ta...
Process Implementation Tasks •    Establish the SQA Processes •    Coordinate with related software processes •    Plan SQ...
Product & Process Assuranceroduct Assurance  Software product conforms to established   requirementsrocess Assurance  Pr...
Product Assurance Tasks •    Evaluate plans for conformance •    Evaluate products for conformance •    Evaluate products ...
Process Assurance Tasks •     Evaluate lifecycle processes for conformance •     Evaluate environments for conformance •  ...
4/11/2012   © David I. Heimann   17
I. Process Implementation                        Dilbert, by Scott Adams, via http://madhusudhan.info/Comics/Dilbert/ 4/11...
Task 1 – Establish the SQA Process  Define an effective SQA process that identifies what to    do and how to:      – Do it...
Task 2 – Coordinate with RelatedSoftware Process  Enable SQA to integrate activities with other software    processes, suc...
Task 3 – Planning the SQA Activities  • Adapt the generic SQA processes to the specific    needs of the project.  • Result...
Outline for the SQA Plan  4/11/2012       © David I. Heimann   22
Task 4 – Executing the SQA Plan  • Execute the SQAP.  • Revise the SQAP as appropriate.  • Raise non-comformances when pro...
Task 5 – Manage SQA Records  • Records are created, maintained, and made available    to project personnel and management....
Task 6 – Evaluate Organizational Objectivity  • Those who perform SQA activities must have the    organizational objectivi...
4/11/2012   © David I. Heimann   26
II. Product Assurance             http://www.amazingonly.com/cartoon/software-bugs-life/ 4/11/2012                        ...
Task 7 – Evaluate Plans for Conformance  •    Identify plans required by the contract.  •    Raise non-conformances when p...
Task 8 – Evaluate Products for Conformance  •    Identify products/documentation required by the       contract.  •    Ide...
Task 9 – Evaluate Product for Acceptability  • Determine project’s understanding of conditions for    product acceptance. ...
Task 10 – Evaluate Product Support  • Have acquirer’s expectations for product support    and cooperation been established...
Task 11 – Measure Products  • Do the project measures accurately and objectively    represent the quality of the software ...
4/11/2012   © David I. Heimann   33
III. Process Assurance             http://softwaretestingandqa.blogspot.com/ (and Calvin &             Hobbes) 4/11/2012  ...
Task 12 – Evaluate Life Cycle Processes  • Does the software development life cycle conform to    project plans and fit wi...
Task 13 – Evaluate Environments  • Do the software development environments conform    to project plans?  • Do the softwar...
Task 14 – Evaluate Subcontractor Processes  • Do subcontractor processes conform to    requirements passed down?  • Have a...
Task 15 – Measure Processes  • Do the project measures support effective    management of the software processes?  • Do th...
Task 16 – Assess Staff Skill & Knowledge  • Do the staff, including SQA staff, assigned to the    project have the knowled...
4/11/2012   © David I. Heimann   40
Annexes •   Guidance for SQA Plans •   IEEE 730 and IEEE 12207 SQA Outcomes •   IEEE 730 and Agile Software Development • ...
Other Informative Material1. Comparison of old & new SQA Plan outline2. IEEE 730 and CMMI3. IEEE 730 and SPICE4. IEEE 730 ...
IEEE 730 and Agile•   In Agile, the product backlog plays a role of the ꞌꞌcontractꞌꞌ.    730 shows how to use the product ...
IEEE 730 and CMMI•   CMMI has 16 core process areas. The two that relate to quality    are PPQA (Product and Process Quali...
Software Integrity Levels•   A set of discrete values used to represent the level of risk of a    software product.•   The...
Summary • IEEE 730 provides a foundation for Software Quality   Assurance, which in turns provides confidence that   softw...
Available Articles (see sign-up sheet)4/11/2012        © David I. Heimann        47
4/11/2012   © David I. Heimann   48
Upcoming SlideShare
Loading in...5
×

A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard

369

Published on

The IEEE is in the process of updating and adding significant content to its IEEE-730-2002 standard on Software Quality Assurance (SQA). The new version will coordinate with the four process areas and sixteen SQA tasks in the IEEE-12207-2008 standard “Systems and Software Engineering: Software Life Cycle Processes”, providing detailed elaborations for these areas and tasks.

The presentation provides a brief overview of these areas and tasks, discuss the difference between SQA and testing, and cover the annexes in IEEE 730 that provide industry-specific information as well as the relationships with software process approaches such as CMMI, Agile, SPICE, CSQE, PMBOK, and VSEs.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
369
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "A Guide to the Forthcoming 2012 Revision of the IEEE Software Quality Assurance Standard"

  1. 1. 4/11/2012 © David I. Heimann 1
  2. 2. Contents• Introduction to SQA and IEEE 730• Process Implementation• Product Assurance• Process Assurance• Annexes and Summary4/11/2012 © David I. Heimann 2
  3. 3. 4/11/2012 © David I. Heimann 3
  4. 4. What is IEEE 730?• Gives guidance and establishes requirements for Software Quality Assurance in a software project.• The very first published software engineering standard – 1981.• Forthcoming version of IEEE 730 greatly expands on existing version of 2002.• Amplifies Software Quality Assurance tasks in IEEE 12207 -- Software Life Cycle Processes.• SQA is one of 43 system and software process areas identified in IEEE 12207 (see next slide for chart).4/11/2012 © David I. Heimann 4
  5. 5. The 43 System &Software Process Areas SQA Process Related Processes 4/11/2012 © David I. Heimann 5
  6. 6. What Is Software Quality Assurance? • A set of activities that → – defines and assesses the adequacy of software processes to → – provide evidence for a justified statement of confidence that → – the software processes will produce software products that → – conform to their established requirements. 4/11/2012 © David I. Heimann 6
  7. 7. ꞌꞌEstablished Requirementsꞌꞌ • The set of requirements that the project has: – verified as satisfying project-specific criteria (such as clarity, suitability, and feasibility) – validated to be faithful reflections of stakeholder requirements. • Established requirements are accepted by the project to form the basis of product development. 4/11/2012 © David I. Heimann 7
  8. 8. SQA Is Not • Testing • Reviewing or Auditing • Done only at the end of development • Reactive • A gate or ꞌꞌpoliceꞌꞌ • An organizational unit (though some units may be named ꞌꞌSQAꞌꞌ) 4/11/2012 © David I. Heimann 8
  9. 9. Why SQA? • Fewer defects in the processes used to develop software. • Fewer defects in business rules and requirements. • Fewer defects in the software products. • Defects are found much earlier in lifecycle and so cost far less to address. • Reduce and eliminate waste. • Generate confidence throughout the lifecycle that activities will go well. 4/11/2012 © David I. Heimann 9
  10. 10. You Don’t Want This http://www.amazingonly.com/cartoon/software-bugs-life/4/11/2012 © David I. Heimann 10
  11. 11. 4/11/2012 © David I. Heimann 11
  12. 12. SQA Activity AreasI. Process ImplementationII. Product AssuranceIII. Process AssuranceThere are 16 SQA tasks in these 3 activity areas4/11/2012 © David I. Heimann 12
  13. 13. Process Implementation Tasks • Establish the SQA Processes • Coordinate with related software processes • Plan SQA activities • Execute the SQA Plan • Manage SQA records • Evaluate organizational objectivity 4/11/2012 © David I. Heimann 13
  14. 14. Product & Process Assuranceroduct Assurance  Software product conforms to established requirementsrocess Assurance  Project activities conform to accurate and effective defined processes 4/11/2012 © David I. Heimann 14
  15. 15. Product Assurance Tasks • Evaluate plans for conformance • Evaluate products for conformance • Evaluate products for acceptability • Evaluate product lifecycle support for conformance • Measure products 4/11/2012 © David I. Heimann 15
  16. 16. Process Assurance Tasks • Evaluate lifecycle processes for conformance • Evaluate environments for conformance • Evaluate subcontractor processes for conformance • Measure processes • Assess staff skill and knowledge 4/11/2012 © David I. Heimann 16
  17. 17. 4/11/2012 © David I. Heimann 17
  18. 18. I. Process Implementation Dilbert, by Scott Adams, via http://madhusudhan.info/Comics/Dilbert/ 4/11/2012 © David I. Heimann 18
  19. 19. Task 1 – Establish the SQA Process Define an effective SQA process that identifies what to do and how to: – Do it well – Confirm it is done right – Measure and track it – Manage and improve it – Encourage using it to improve quality 4/11/2012 © David I. Heimann 19
  20. 20. Task 2 – Coordinate with RelatedSoftware Process Enable SQA to integrate activities with other software processes, such as: 1. Verification, Validation, Review, and Audit 2. Project Planning 3. Technical Processes 4. Implementation Processes 5. Reuse Processes 6. Agreement 4/11/2012 © David I. Heimann 20
  21. 21. Task 3 – Planning the SQA Activities • Adapt the generic SQA processes to the specific needs of the project. • Results are documented in the Software Quality Assurance Plan (SQAP). • This is where SQA is adapted to the specific nature of the project (e.g., Agile, CMMI, embedded, etc.) 4/11/2012 © David I. Heimann 21
  22. 22. Outline for the SQA Plan 4/11/2012 © David I. Heimann 22
  23. 23. Task 4 – Executing the SQA Plan • Execute the SQAP. • Revise the SQAP as appropriate. • Raise non-comformances when products or processes do not conform to their requirements. • Create and use SQA records to improve quality. 4/11/2012 © David I. Heimann 23
  24. 24. Task 5 – Manage SQA Records • Records are created, maintained, and made available to project personnel and management. • Records aim to document that project activities: – Are performed in accordance with project plans. – Comply with the contract. – Support the identification and rectification of problems, causes, and improvements. – Enable information sharing. 4/11/2012 © David I. Heimann 24
  25. 25. Task 6 – Evaluate Organizational Objectivity • Those who perform SQA activities must have the organizational objectivity and authority to make objective evaluations and verify problem resolutions. • Three important aspects of objectivity are: – Technical Independence: Not involved in the development of the products being evaluated. – Managerial Independence: Not reporting to individuals responsible for product development/project management. – Financial Independence: Budget not controlled by individuals responsible for product development/project management. 4/11/2012 © David I. Heimann 25
  26. 26. 4/11/2012 © David I. Heimann 26
  27. 27. II. Product Assurance http://www.amazingonly.com/cartoon/software-bugs-life/ 4/11/2012 © David I. Heimann 27
  28. 28. Task 7 – Evaluate Plans for Conformance • Identify plans required by the contract. • Raise non-conformances when plans do not conform to the contract (or when the contractural requirements are inadequate). • Raise non-conformances when plans are not mutually consistent. 4/11/2012 © David I. Heimann 28
  29. 29. Task 8 – Evaluate Products for Conformance • Identify products/documentation required by the contract. • Identify allocated requirements and ensure adequacy. • Ensure that evaluations of software products/documentation for conformance against the requirements are performed. 4/11/2012 © David I. Heimann 29
  30. 30. Task 9 – Evaluate Product for Acceptability • Determine project’s understanding of conditions for product acceptance. • Prior to delivery, evaluate the level of confidence that the software products and related documentation will be acceptable to the acquirer. Note -- Depending on contractual agreements (e.g., Agile environments), the customers themselves may make some acceptability determinations prior to delivery. 4/11/2012 © David I. Heimann 30
  31. 31. Task 10 – Evaluate Product Support • Have acquirer’s expectations for product support and cooperation been established and documented? • Have they been met? • If the SQA process ends at delivery, how is suitable support ensured? 4/11/2012 © David I. Heimann 31
  32. 32. Task 11 – Measure Products • Do the project measures accurately and objectively represent the quality of the software products? • Are improvements done as a result of the product measurements effective in improving product quality? • Do the measurements of software products satisfy the measurement requirements and conform to the measurement plans? 4/11/2012 © David I. Heimann 32
  33. 33. 4/11/2012 © David I. Heimann 33
  34. 34. III. Process Assurance http://softwaretestingandqa.blogspot.com/ (and Calvin & Hobbes) 4/11/2012 © David I. Heimann 34
  35. 35. Task 12 – Evaluate Life Cycle Processes • Does the software development life cycle conform to project plans and fit with contractural requirements? • Does the execution of project activities conform to the project plans? • Does the execution of project activities yield products that conform to requirements? 4/11/2012 © David I. Heimann 35
  36. 36. Task 13 – Evaluate Environments • Do the software development environments conform to project plans? • Do the software test environments conform to project plans? 4/11/2012 © David I. Heimann 36
  37. 37. Task 14 – Evaluate Subcontractor Processes • Do subcontractor processes conform to requirements passed down? • Have acquisition needs, goals, product, and service criteria been identified? Have they been met? 4/11/2012 © David I. Heimann 37
  38. 38. Task 15 – Measure Processes • Do the project measures support effective management of the software processes? • Do the project measures meet the information needs necessary for managing effective processes? • Does the executed measurement process satisfy the measurement requirements and conform to the measurement plans? 4/11/2012 © David I. Heimann 38
  39. 39. Task 16 – Assess Staff Skill & Knowledge • Do the staff, including SQA staff, assigned to the project have the knowledge, skills, and abilities to perform their assigned roles? • Have education and training plans been developed? Are they effective? 4/11/2012 © David I. Heimann 39
  40. 40. 4/11/2012 © David I. Heimann 40
  41. 41. Annexes • Guidance for SQA Plans • IEEE 730 and IEEE 12207 SQA Outcomes • IEEE 730 and Agile Software Development • IEEE 730 and Very Small Enterprises (VSE) • Software Integrity Levels & Assurance Cases • Corrective and Preventive Action 4/11/2012 © David I. Heimann 41
  42. 42. Other Informative Material1. Comparison of old & new SQA Plan outline2. IEEE 730 and CMMI3. IEEE 730 and SPICE4. IEEE 730 and Bodies of Knowledge (BOK)5. Industry-Specific Guidance6. Product Support7. System vs. Software QA8. Software Tool Validation9. Tools, Techniques, and Methods 4/11/2012 © David I. Heimann 42
  43. 43. IEEE 730 and Agile• In Agile, the product backlog plays a role of the ꞌꞌcontractꞌꞌ. 730 shows how to use the product backlog in its role as a contract.• The product SQA portion of SQA Plan specifies the Agile ꞌꞌdoneꞌꞌ criteria.• Non-conformances are inserted into the backlog and addressed in the appropriate sprints.• Evaluation of product for acceptance is a continual process in Agile, not just at end of project.• IEEE 730 has an annex on Agile with further details.4/11/2012 © David I. Heimann 43
  44. 44. IEEE 730 and CMMI• CMMI has 16 core process areas. The two that relate to quality are PPQA (Product and Process Quality Assurance) and VER (Verification).• Since CMMI does not specify a particular process flow, CMMI- conforming organizations need to design their own PPQA process.• IEEE 730 provides details for this process design.• VER process area implements product quality assurance according to the plan in PPQA. 730 covers both product and process quality assurance.• 730 has associated materials with maps between 730 and CMMI.4/11/2012 © David I. Heimann 44
  45. 45. Software Integrity Levels• A set of discrete values used to represent the level of risk of a software product.• The software integrity level of a product or component determines the level of rigor and quality assurance to be applied in their development and implementation.• See sample software integrity description below:Level Description4 Catastrophic failure – loss of life, economic/social loss, system loss3 Serious failure – loss of system, data, usability2 Moderate failure – must correct and re-run1 Minor failure – workaround is possible4/11/2012 © David I. Heimann 45
  46. 46. Summary • IEEE 730 provides a foundation for Software Quality Assurance, which in turns provides confidence that software products will conform to their established requirements and satisfy the customer. • IEEE 730 addresses the three areas of SQA: Process Implementation, Product Assurance, and Process Assurance. • IEEE 730 can be used to prove conformance where SQA conformance is required, and to provide guidance where SQA conformance is desired. 4/11/2012 © David I. Heimann 46
  47. 47. Available Articles (see sign-up sheet)4/11/2012 © David I. Heimann 47
  48. 48. 4/11/2012 © David I. Heimann 48
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×