ISO 90003 Tor Stlhane IDI NTNU What is

ISO 90003 Tor Stålhane IDI / NTNU

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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