ISO Tor Stålhane IDI / NTNU

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

ISO ISO 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 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 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