IEEE 730

1. IEEE 730 Tor Stålhane IDI / NTNU

2. Purpose Reference documents Management Documentation Standards, practices and metrics Reviews and audits Test Problem reporting Tools, techniques and methodologies Code control Media control Supplier control Records collection, maintenance and retention Training Risk management Contents

3. Quality plan The quality plan shall contain the sections shown in the content slide. The standard describes the contents of each section – including subsections If one or more of these sections are irrelevant for the current project, the section shall still be included but with the statement “Not relevant” or an other term to this effect.

4. Purpose • The purpose of the QA plan • Which software components – e.g. subsystems – are covered by the plan • For each component we need to describe • The component’s name • The purpose of the component • Which parts of the life cycle that is covered by the plan

5. Reference documents Contains a list of all documents that are referenced in the QA plan, e.g. • Test plan • Documentation standard • Problem reports • IEEE standard for software terms

6. Management This section has three subsections • Organization • Tasks, split up into • Which parts of the life cycle are covered • Tasks to be done • Couplings between tasks and important project milestones • Who is responsible for what

7. Documentation - 1 This part has three subsections • Purpose, where we describe • The documents that must be produces. We must cover the whole life cycle specified • How will the documents be controlled • Our minimum requirements for documentation, which must include this standard’s minimum requirements • Miscellaneous – other things that we want to include

8. Documentation - 2 This standard’s minimum requirements for documentation: • SRS – Software Requirements Specifications • SDD – Software Design Description • SVVR Software Verification and Validation Report • Use documentation • SCMP – Software Configuration Managment Plan

9. Standards, practices and metrics - 1 Purpose • Identify standards, practices, conventions and metrics that will be used in the project • Describe how we will control that the identified practices, conventions and metrics are used

10. Standards, practices and metrics - 2 The contents of this section must, as a minimum, contain standards for • Documentation • How to describe the logical structure of the software • Coding • Comments inserted into the code • Testing • Selected software and project metrics

11. Standards, practices and metrics - 3 Examples of useful metrics include measurements for • The number of decisions • The number of error messages • Implemented requirements • Project plan deviations

12. Reviews and audits – 1 As a minimum we need to describe how we will perform the following reviews: • SRR – Software Requirements Review • PDR – Preliminary Design Review • CDR – Critical Design Review • SVVPR – Software Validation and Verification Plan Review

13. Reviews and audits – 2 More reviews: • Functions review – is all functionality implemented? • Physical review – are all software and all documents consistent? • Reviews performed during the development process • Management periodical audits

14. Reviews and audits – 3 • Audits during the development process • Code vs. design documentation • Control of all interfaces • Design vs. functional requirements • Functional requirements vs. test case descriptions • SCMPR – Software Configuration Management Plan Review

15. Reviews and audits – 4 • Post Mortem Review – what can we learn form this project? • Other reviews, e.g. UDR – User Documentation Review

16. Test This section shall include all tests that are not already included in SVVP This includes descriptions of test methods to be used.

17. Problem reporting We need to describe • Procedures used when reporting, tracing and solving problems. This goes for problems pertaining to • Software development • Maintenance • Development process • Who is responsible for controlling that the procedures are used

18. Tools, techniques and methodologies All tools, techniques and methods used shall have a short description where we describe: • The tool, method or technique itself • How and for what purpose it should be used • Why did we chose this tool, technique or method

19. Code control For all code that is under version control, we need to describe how we shall • Perform maintenance • Store the code – e.g. on what type of media • Keep the code safe from virus, theft and so on • Document it

20. Media control For all media used, we need to describe • The software needed to read from and write to the media • How we will protect the media against • Unauthorized access • Destruction or harm due to accidents

21. Supplier control –1 How will we control that software supplied by a third party satisfy our quality requirements? We need to consider two types of third party software, i.e. software that • Is already developed – components off the shelf, reuse or customer made • Will be developed for this project

22. Supplier control – 2 Software that is already developed – components off the shelf (COTS), reuse or customer made For this case we need to describe how we will verify and validate this software with respect to its quality

23. Supplier control - 3 Software that will be developed for this project. For this case we need to describe how we will control that the development company uses a quality assurance standard that is acceptable for our project

24. Records collection, maintenance and retention Here we need to describe • Which project documents shall be retained • How shall we maintain these documents • How shall we keep the documents safe from unauthorized access

25. Training Here we need to describe the training needed for developers and management in order to satisfy the requirements in this QA plan.

26. Risk management Here we need to describe the methods and procedures used to handle risk in the project. This includes methods for • Risk identification – what are the most important project risks • Risk assessment – probability / frequency and consequences • Risk surveillance – will it happen • Risk control – possible actions