ISO TR 15497:2000 pdf download

ISO TR 15497:2000 pdf download.Road vehicles -Development guidelinesfor vehicle based software.
3.1.2 Lifecycle plans
3.1 .2.1 An appropriate development approach should be defined and documented (e.g. by producing a Software Development Plan, a Quality Plan, a Safety Plan and a Configuration Management Plan). The design material should define:
(a) project organization.
(b) procedures to be followed.
(c) management processes to ensure compliance with the procedures in (b).
(d) planned management reviews of the effectiveness of the procedures in (b) and processes in (c).
(e) specific software deliverables together with their authors and readers.
3.1 .2.2 The project team should progressively produce a Software Development Plan with clearly
defined phases that, comprehensively and cost-effectively, cover the:
• specification
• design
• programming
• integration
• verification and validation (including testing)
• in-service support of the software.
3.1 .2.3 The Safety Plan [14] should aim to ensure that verification and validation are performed throughout the project. These activities should be performed with a rigour appropriate to the integrity level.
3.1 .2.4 Appropriate lifecycle plans should be defined before the start of a project for the system and the software. Figure 2 shows an example lifecycle.
3.1 .2.5 Each individual system should have its own lifecycle that should be compatible with the project definition and the overall vehicle plan. An example is shown in Figure 3.
3.1.3 Planning for verification and validation
3.1 .3.1 The verification and validation activities should be defIned to establish a level of confidence in the software that corresponds the integrity requirements of the system. See Figure 4.
3.1 .3.2 The purpose of software verification [61 is to ensure that each phase of the software development process maintains the attributes of the previous one without introducing errors. The outputs of each phase should be technically evaluated, by analysis and/or inspection with respect to its inputs, including standards and guidelines.
3.1 .3.3 Safety verification is specifically concerned with the safety requirements and should proceed concurrently with the normal design and implementation process. Each phase of the development should also be verified with respect to safety before progressing on to the next development phase.
3.1 .3.4 A verification plan should be established covering each phase of the software lifecycle.
3.1 .3.5 The purpose of software validation [6] is to determine whether the software satisfies its intention and mainly consists of performing tests, but it should also involve analysis and mathematical techniques where appropriate. Full validation of the software cannot usually take place until it has been integrated with the rest of the system and often the vehicle.
3.1 .3.6 Safety validation should be carried out to confirm specifically that all the safety requirements have been met.
3.1 .3.7 A validation plan should be established for the software, system and vehicle.
3.1 .3.8 To be effective, it is recommended that verification and validation are carried out by a person or team exhibiting a degree of independence from the design and implementation appropriate to the integrity requirements of the software and system.
3.1.4 Assessment
3.1 .4.1 It is recommended that a company nominates a suitably qualified 1191 and independent assessor and/or auditor to perform product assessment, in order to act as an advocate for the level of confidence in the safety delivered to the end customer [2].
3.1 .4.2 An assessment process should be performed to demonstrate that the risks associated with the final system are at an acceptable level [14].
3.1 .4.3 The higher levels of integrity should require greater indepeiidence of assessment in order to ensure that there is no bias from the development team, nor misplaced pressure from management.
3.1 .4.4 The degree of independence [141 should be achieved by one or more of:
• different person
• different department or section
• different company or division.
3.1 .4.5 The degree of confidence in a piece of software depends on the quality and the extent of the available information. This should cover the specification, design, implementation and testing of the software.
3.1 .4.6 Preparing for assessment is a task that should begin at the start of a project; this also avoids the possibility of arriving at the point of assessment and finding that a vital piece of information has been omitted or overlooked. Early liaison with the assessor is recommended.
3.1.5 Reuse
3.1 .5.1 “Off the shelf” or commercially available components containing software to be used in a project should be assessed to the required integrity level, and such reuse of existing software should be considered on a case by case basis.
3.1 .5.2 The software that is intended for reuse should be fully compliant with the requirements of the new system that it is intended to be used in.