1. ISO 90003 Tor Stålhane IDI / NTNU

2. What is ISO 90003 ISO 9001 was developed for the production industry but has a rather general structure ISO 90003 describes how to use ISO 9001 for software development ISO 90003 is a set of guidelines – not a standard

3. ISO 90003 ISO 90003 contains the complete ISO 9001 but does not add extra items for all items in the standard We will only look at ISO 90003’s comments for a few, selected parts of ISO 9001. The selection is partly random but is supposed to give an impression of what it is important to consider

4. Requirements for a QA system - 1 Requirements for planning in the QA system should include requirements for Development process – one for each type of project Documents such as requirements specification, architecture description, design description, code and user documentation Project plans, test plans and plans for training

5. Requirements for a QA system - 2 Requirements for planning in the QA system should include requirements for How methods will be adapted to the organization’s projects and development processes Tools and development environment Special conventions, e.g. coding standards and libraries Reuse of software components

6. Responsibility for training - 1 The need for training should be assessed based on what the company uses for development, e.g. Methods and notations Programming languages and tools The company should also provide training pertaining to the domain where the company operates – e.g. banking or train control

7. Responsibility for training - 2 The company should continuously assess the need for new knowledge and techniques in the areas of Development Operation Maintenance Training does not need to be courses – it may be arranged as seminars, workshops or self study activities

8. Development processes - 1 The processes we use must be adapted to the project at hand. When choosing development process we should take into consideration: Project size Complexity Safety and security requirements Project risk

9. Development processes - 2 Design and development may be an evolutionary process. We might therefore need to change one or more procedures during the project The procedures shall focus on What we shall develop How we shall develop it Who shall do what Why shall we do this

10. QA processes When we have a development process, the QA process can be adapted to the development. The QA process has two parts: A generic part – concerns all projects and can be reused. E.g. document templates A project specific part that needs to be adapted to each new project. E.g. test plans

11. QA plan - 1 The QA plan should contain The project plan or a reference to this plan Quality requirements for product and process Project specific procedures Development process, chosen programming language, libraries etc. Criteria for start and acceptance for each activity or step in the process

12. QA plan - 2 The QA plan should contain Methods used for verification – e.g. inspections – and testing Configuration management Who shall approve the results from each process step or activity Training needed What process info need to be generated

13. Product requirements - 1 According to ISO 90003 software may be developed for A single customer A general market As a component for a larger product In all cases, it is important to put a considerable amount of work into developing a set of requirements

14. Product requirements - 2 In order to develop a set of requirements we need procedures and methods that can help us to Reach an agreement on requirements Change requirements Evaluate prototypes and demo versions Document the results from meetings and discussions involving one or more stakeholders

15. Product requirements - 3 The requirements should be developed in cooperation with the customers or users. In order to avoid misunderstandings we should develop a Project dictionary that explains the domain specific terms used in this project A rationale for each requirements – why do we need this

16. Product requirements - 4 The customer should approve the final set of requirements. It is important to be able to trace all requirements, e.g. by using a trace matrix. This matrix should show How each requirement is realized – from high level design down to code or procedure Why each chunk of code is written – which requirement it helps to realize

17. Product requirements - 5 We need to control all changes to requirements. Changes to requirements may lead to changes in the contract The requirements specification may include non-functional requirements, e.g. requirements to reliability, usability etc. The requirements specification may contain requirements to interfaces to other software systems

18. Contract audit - 1 Important things to check: Are we able to fulfill the requirements to –The product –Development process, tools and hardware How large is the risk for cost overruns or delays How do we cooperate with third party companies Legal obligations, e.g. guarantees

19. Contract audit - 2 The contract should be updated when time of delivery, costs or available resources are changed The contract should contain a section on the customer’s obligations to Provide information Participate in discussions related to the requirements Make necessary decisions