Software Assessment for Shipboard Computer Based System

Transcription

1 Software Assessment for Shipboard Computer Based System July 2008 Guidance Note NI 425 DT R01 E Marine Division Paris La Défense Cedex - France Tel: +33 (0) Fax: +33 (0) Marine website: veristarinfo@bureauveritas.com 2008 Bureau Veritas All rights reserved

2 MARINE DIVISON GENERAL CONDITIONS ARTICLE BUREAU VERITAS is a Society the purpose of whose Marine Division (the Society ) is the classification ( Classification ) of any ship or vessel or structure of any type or part of it or system therein collectively hereinafter referred to as a Unit whether linked to shore, river bed or sea bed or not, whether operated or located at sea or in inland waters or partly on land, including submarines, hovercrafts, drilling rigs, offshore installations of any type and of any purpose, their related and ancillary equipment, subsea or not, such as well head and pipelines, mooring legs and mooring points or otherwise as decided by the Society. The Society: prepares and publishes Rules for classification, Guidance Notes and other documents ( Rules ); issues Certificates, Attestations and Reports following its interventions ( Certificates ); publishes Registers The Society also participates in the application of National and International Regulations or Standards, in particular by delegation from different Governments. Those activities are hereafter collectively referred to as Certification The Society can also provide services related to Classification and Certification such as ship and company safety management certification; ship and port security certification, training activities; all activities and duties incidental thereto such as documentation on any supporting means, software, instrumentation, measurements, tests and trials on board The interventions mentioned in 1.1., 1.2. and 1.3. are referred to as Services. The party and/or its representative requesting the services is hereinafter referred to as the Client. The Services are prepared and carried out on the assumption that the Clients are aware of the International Maritime and/or Offshore Industry (the Industry ) practices The Society is neither and may not be considered as an Underwriter, Broker in ship s sale or chartering, Expert in Unit s valuation, Consulting Engineer, Controller, Naval Architect, Manufacturer, Shipbuilder, Repair yard, Charterer or Shipowner who are not relieved of any of their expressed or implied obligations by the interventions of the Society. ARTICLE Classification is the appraisement given by the Society for its Client, at a certain date, following surveys by its Surveyors along the lines specified in Articles 3 and 4 hereafter on the level of compliance of a Unit to its Rules or part of them. This appraisement is represented by a class entered on the Certificates and periodically transcribed in the Society s Register Certification is carried out by the Society along the same lines as set out in Articles 3 and 4 hereafter and with reference to the applicable National and International Regulations or Standards It is incumbent upon the Client to maintain the condition of the Unit after surveys, to present the Unit for surveys and to inform the Society without delay of circumstances which may affect the given appraisement or cause to modify its scope The Client is to give to the Society all access and information necessary for the performance of the requested Services. ARTICLE The Rules, procedures and instructions of the Society take into account at the date of their preparation the state of currently available and proven technical knowledge of the Industry. They are not a code of construction neither a guide for maintenance or a safety handbook. Committees consisting of personalities from the Industry contribute to the development of those documents The Society only is qualified to apply its Rules and to interpret them. Any reference to them has no effect unless it involves the Society s intervention The Services of the Society are carried out by professional Surveyors according to the Code of Ethics of the Members of the International Association of Classification Societies (IACS) The operations of the Society in providing its Services are exclusively conducted by way of random inspections and do not in any circumstances involve monitoring or exhaustive verification. ARTICLE The Society, acting by reference to its Rules: reviews the construction arrangements of the Units as shown on the documents presented by the Client; conducts surveys at the place of their construction; classes Units and enters their class in its Register; surveys periodically the Units in service to note that the requirements for the maintenance of class are met. The Client is to inform the Society without delay of circumstances which may cause the date or the extent of the surveys to be changed. ARTICLE The Society acts as a provider of services. This cannot be construed as an obligation bearing on the Society to obtain a result or as a warranty The certificates issued by the Society pursuant to 5.1. here above are a statement on the level of compliance of the Unit to its Rules or to the documents of reference for the Services provided for. In particular, the Society does not engage in any work relating to the design, building, production or repair checks, neither in the operation of the Units or in their trade, neither in any advisory services, and cannot be held liable on those accounts. Its certificates cannot be construed as an implied or express warranty of safety, fitness for the purpose, seaworthiness of the Unit or of its value for sale, insurance or chartering The Society does not declare the acceptance or commissioning of a Unit, nor of its construction in conformity with its design, that being the exclusive responsibility of its owner or builder, respectively The Services of the Society cannot create any obligation bearing on the Society or constitute any warranty of proper operation, beyond any representation set forth in the Rules, of any Unit, equipment or machinery, computer software of any sort or other comparable concepts that has been subject to any survey by the Society. ARTICLE The Society accepts no responsibility for the use of information related to its Services which was not provided for the purpose by the Society or with its assistance If the Services of the Society cause to the Client a damage which is proved to be the direct and reasonably foreseeable consequence of an error or omission of the Society, its liability towards the Client is limited to ten times the amount of fee paid for the Service having caused the damage, provided however that this limit shall be subject to a minimum of eight thousand (8,000) Euro, and to a maximum which is the greater of eight hundred thousand (800,000) Euro and one and a half times the above mentioned fee. The Society bears no liability for indirect or consequential loss such as e.g. loss of revenue, loss of profit, loss of production, loss relative to other contracts and indemnities for termination of other agreements All claims are to be presented to the Society in writing within three months of the date when the Services were supplied or (if later) the date when the events which are relied on of were first known to the Client, and any claim which is not so presented shall be deemed waived and absolutely barred. ARTICLE Requests for Services are to be in writing Either the Client or the Society can terminate as of right the requested Services after giving the other party thirty days' written notice, for convenience, and without prejudice to the provisions in Article 8 hereunder The class granted to the concerned Units and the previously issued certificates remain valid until the date of effect of the notice issued according to 7.2. hereabove subject to compliance with 2.3. hereabove and Article 8 hereunder. ARTICLE The Services of the Society, whether completed or not, involve the payment of fee upon receipt of the invoice and the reimbursement of the expenses incurred Overdue amounts are increased as of right by interest in accordance with the applicable legislation The class of a Unit may be suspended in the event of non-payment of fee after a first unfruitful notification to pay. ARTICLE The documents and data provided to or prepared by the Society for its Services, and the information available to the Society, are treated as confidential. However: Clients have access to the data they have provided to the Society and, during the period of classification of the Unit for them, to the classification file consisting of survey reports and certificates which have been prepared at any time by the Society for the classification of the Unit ; copy of the documents made available for the classification of the Unit and of available survey reports can be handed over to another Classification Society Member of the International Association of Classification Societies (IACS) in case of the Unit s transfer of class; the data relative to the evolution of the Register, to the class suspension and to the survey status of the Units are passed on to IACS according to the association working rules; the certificates, documents and information relative to the Units classed with the Society may be reviewed during IACS audits and are disclosed upon order of the concerned governmental or inter-governmental authorities or of a Court having jurisdiction. The documents and data are subject to a file management plan. ARTICLE Any delay or shortcoming in the performance of its Services by the Society arising from an event not reasonably foreseeable by or beyond the control of the Society shall be deemed not to be a breach of contract. ARTICLE In case of diverging opinions during surveys between the Client and the Society s surveyor, the Society may designate another of its surveyors at the request of the Client Disagreements of a technical nature between the Client and the Society can be submitted by the Society to the advice of its Marine Advisory Committee. ARTICLE Disputes over the Services carried out by delegation of Governments are assessed within the framework of the applicable agreements with the States, international Conventions and national rules Disputes arising out of the payment of the Society s invoices by the Client are submitted to the Court of Nanterre, France Other disputes over the present General Conditions or over the Services of the Society are exclusively submitted to arbitration, by three arbitrators, in London according to the Arbitration Act 1996 or any statutory modification or re-enactment thereof. The contract between the Society and the Client shall be governed by English law. ARTICLE These General Conditions constitute the sole contractual obligations binding together the Society and the Client, to the exclusion of all other representation, statements, terms, conditions whether express or implied. They may be varied in writing by mutual agreement The invalidity of one or more stipulations of the present General Conditions does not affect the validity of the remaining provisions The definitions herein take precedence over any definitions serving the same purpose which may appear in other documents issued by the Society. BV Mod. Ad. ME 545 j - 16 February 2004

3 Table of Contents 1. General General Field of application References Definitions Abbreviation Software requirement General Functional requirements Safety of operation Monitoring Fall-Back arrangement Documentation Software Development process General Software Quality Plan (Guidelines) Software Assessment Software classification Software Category notations Software Assessment...16 Annex A Questionnaire on the tests and inspections to be performed...19 Annex B Software Quality Plan Guidelines...27 B.1. Development and design...29 B.1.1. Scope...29 B.1.2. Development Projects...29 B.1.3. Design description...29 B.1.4. Re-use...30 B.2. Methodology for development...30 B.2.1. Development planning...30 B.2.2. Specification requirements...30 B.2.3. Preliminary design...31 B.2.4. Detailed design...31 B.2.5. Coding and module testing...32 B.2.6. Integration testing...32 B.2.7. Validation and installation...33 B.2.8. Exploitation...33 B.3. Responsibility...33 B.3.1. Product Manager...33 B.3.2. Development Manager...33 B.3.3. Project Manager...34 B.4. Execution...34 B.4.1. Requirements...34 B.4.2. Project Handbook...34 B.4.3. Project Plan...34 B.4.4. Manning Plan...35 B.4.5. Cost Plan...35 B.4.6. Documentation Plan...35 B.4.7. Test Plans...35 july 2008 Bureau Veritas 3

4 B.5. Project Monitoring...35 B.6. Project Evaluation...36 B.7. Design Review...36 B.7.1. Purpose...36 B.7.2. Scope...36 B.7.3. Responsibility...36 B.7.4. Constitution of the Design Review Board...36 B.8. Prototype...36 B.8.1. Documentation...37 B.8.2. Factory Acceptance Test...37 B.8.3. Hand-over Meeting...37 B.8.4. Training...37 B.9. Relevant Documents...37 B.10. Test and verification of software...37 B.11. Software Test Documentation...38 B Software Test and Verification Plan...38 B Software Test Specification...38 B Test Log...38 B.12. Failure report...39 B.13. Software maintenance...39 Index of Table Table I: System/software categories...15 Table II: Example of assignment to system/software categories...16 Table III: Tests reports and documentation to be submitted Bureau Veritas July 2008

5 1. General 1.1. General This document is intended to assess software fitted on shipboard computer based system Within the scope of these Guidance Note, an assessment attestation may be issued Software assessment block diagram O p e r a t i o n a l C o n d i t i o n Safe Navigation Avoiding: - grounding - collision - any damage - uncontrolled Reducing: - failure effect Increasing: - availability - reliability Control system: - steering - speed governor - course tracking - main engine Protection System - motor - fire Alarm monitoring - fire - engine management - navigation - pwr mgnt system (PMS) Information system Support system 1 - General 2 - Software Requirements 2.1 General - Safety of operation - Monitoring - Fall Back Arrangement - Operation - Software classification - Software Category 2.2 Software Specification - Functional Requirement - Specific Requirement - Standard requirement - Other Requirement 3 - Software Development Process 3.1 General - Description - Development and design - Responsibility - Project Plan - Test Plan - Methodology - SQP - SOLAS EC IEC IEC IACS ISO 9001 ISO IEC IEC IEC Route monitoring Traffic surveillance Manoeuvring Communication Manual Steering Safety Operations Docking Loading Habitability 4 - Software Assessment - Category - Condition of granting - Guideline - Annex A question - Annex B software quality plan example Bureau VERITAS procedures Software Assessment Certificate july 2008 Bureau Veritas 5

6 1.2. Field of application The present provisions especially apply to software involved in computer based systems which perform one or more of the following functions; related to essential services as defined in NR467 Rules for the Classification of Steel Ships, Pt C, Ch 2, Sec 1, i.e.: Propulsion plant and auxiliaries ( Diesel engine, main boilers and turbine, electric motor, gearing, CPP...) Steering Navigation (centralized navigation system ) Electricity production (power management electrical protection) Fire detection and fire fighting(alarm System...) Automation systems Cargo (load computer) External and internal communication (network ) Safety systems (ESD ) Instrumentation (Gas detection, Intelligent sensor, ) They may also apply to software related to non essential services such as Air Conditioning management system, etc References This rule note is based on the principle, derived from the following rules and standards: International Maritime Organisation: SOLAS. IEC : Maritime navigation and radio communication equipment and systems - General requirements - Methods of testing and required test results. IEC : Functional Safety of Electric / Electronic / Programmable Electronic Safety-Related Systems. Part3: Software Requirements. IEC : Electrical installations in ships Part 504: Special features Control. and instrumentation.. IEC : Safety instrumented systems for the process industry sector. DO 178B: Software Considerations in Airborne Systems and Equipment Certification. BV Rules Part C chapter 3 IMO MSC Circular N 891 Guidelines for the on-board use and application of computers ISO/IEC : Software engineering - Guidelines for the application of ISO 9001:2000 to computer software ISO 9001: Quality management systems Requirements IACS Unified Requirement E 22: Unified requirement for the on board use and application of programmable electronic systems 1.4. Definitions Alarm: audible and visual signal announcing a condition requiring immediate attention or user action. Application Software: software performing tasks specific to the actual configuration of the computer based system and supported by the basic software. Basic software: the minimum software, which includes firmware and middleware, required to support the application software. Code: implementation of particular data on a particular computer program in a symbolic form, such as source code, object code, or machine code. Computer: A programmable electronic device for storing and processing data, making calculation, or performing control. Notes: a) Generally, the term computer means a digital computer. b) A computer may consist of a stand-alone unit or may consist of several interconnected units and includes any programmable electronic systems (PES), including mainframe, minicomputer or microcomputer. 6 Bureau Veritas July 2008

7 Computer-based system: A system of one or more computers, associated software, peripherals, and interfaces. Detailed design: logic continuation of preliminary design, considered as a process of separating, usually with the express purpose of isolating one or more attribute(s) of the software, to prevent specific interactions and cross-coupling interference. Fall back arrangement: automatic reaction of the system to a failure to provide the best possible functionality. Functionality: ability to perform an intended function which uses systems of display, controls, and instrumentations. Integration testing: Tests allowing verifying the transitions between different parts of program. Integrated system: A combination of computer-based systems, which are interconnected in order to allow centralised access to sensor information and/or command/control. Notes: a) Integrated systems may, for example, perform one or more of the following operations: b) Passage execution (e.g. steering, speed control, traffic surveillance, voyage planning). c) Communications (e.g. radiotelephone, radio telex, GMDSS). d) Machinery (e.g. power management, machinery monitoring, fuel oil, / lubrication oil transfer). e) Cargo (e.g. cargo monitoring, inert gas generation, loading/discharging). f) Safety and security (e.g. Fire detection, fire pump control, watertight doors). Integrated navigation system: combination of systems or functions of navigational aids those are interconnected to increase safe and efficient navigation when used by suitably qualified personnel. Integrity: property of information as being accurate, valid with regard to specified requirements, and verified by comparing data from more than one independent source. Metrics: Refers to the specific measures used in studying a particular process or organisation. Module testing: Each software module is individually tested to detect and correct errors. Operating systems (OS): Set of computer programs that manages the hardware and software resources of a computer. Preliminary design: first approach of software architecture, structure selected to implement the software requirements. Software component: self-contained part, combination of parts, sub-assemblies, or units which performs a distinct function in a system. Software integration: process of combining software components. Software: computer programs, and possibly associated documentation and data pertaining to the operation of a computer system. Software development planning: description of software life cycle and software development environment. It is an estimated timetable of tasks where restraints, critical points, and resources are identified. Software requirements: description of what is to be produced by the software given input and constraints. Software requirements include both high level requirements and low-level requirements. System data: data that is used by the system for the processing and display of essential information. System data of the same type is from the same source. System data, at least for primary navigation information, has been checked for integrity. july 2008 Bureau Veritas 7

8 System integrator: organisation responsible for ensuring that the system complies with the requirements of this standard. Testing: Operation intended to control the correct operation of an apparatus or the good execution of a program as a whole. Verification: Confirmation, through the provision of objective evidence, that specified requirements have been fulfilled. Validation: Confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled. Validity: conformity of information with formal and logical criteria, or the marking of data as being good or no good (valid or invalid) for the intended use Vessel: water craft of any description, including non-displacement craft, craft and seaplanes, used or capable of being used as a means of transportation on water Warning: signal announcing a condition requiring non-immediate attention for precautionary reasons 1.5. Abbreviation DR DRB ECO EUT FAT IEEE MMI UDF PMS SQA Design Review Design Review Board Engineering Change Order Equipment Under Test Factory Acceptance Test Institute of Electrical and Electronics Engineers Man-Machine Interface Unit Development Folder Power Management System Software Quality assurance 8 Bureau Veritas July 2008

9 2. Software requirements 2.1. General Standards/guidelines and naming conventions are to be specified for the document and followed throughout the documents The basic software is to be developed in consistent and independent modules. A self-checking function (e.g. auto test) is to be provided to identify failure of software module. When hardware (e.g. input /output devices, communication links, memory, etc.) is arranged to limit the consequences of failures (e.g. modular concept), the corresponding software is also to be separated in different software modules ensuring the same degree of independence, in order to avoid a common single failure Application software is to be tested to verify the ability to perform intended functions with all systems interconnected (or by means of simulation tools, as relevant) The code of practice employed in the design and testing of the integral software to the operation of the equipment under test is to be specified and conform to a quality control system audited by a competent authority The code of practice is to define the methodology used in the development of the software and the standards applied following criteria: a) Complex software is to be structured to support separate testing of single modules or of groups of associated modules. b) The structure is to support maintenance and updates of software by minimizing the risk of undetected problems failures and non regression. c) The manufacturer is to supply documentation demonstrating that the software of the System is developed and tested according to the code of practice and to this document A description of operating system configuration is to be documented (listing, limitations, parameters ). The functions delivered within the operating system packages are to be limited to those needed by the system. The unused options are to be invalidated The tools and additional software are to be identified and documented Functional requirements Functional requirements are to be uniquely numbered Interface requirements to other functions or external entities are to be clearly identified All common functions are to be identified The requirements are to be stated so that they are discrete, unambiguous and testable Each decision, selection, and computational function that the software must perform is to be clearly defined A dictionary for all data elements is to be provided. The data dictionary is to be complete. july 2008 Bureau Veritas 9

10 2.3. Safety of operation Facilities are to be provided for protecting all operational software incorporated in the equipment Any software required in equipment to facilitate operation in accordance with its equipment standard, including that for its initial activation/reactivation, is to be permanently installed with the equipment, in such a way that it is not possible for the user to have access to this software It is not to be possible for the operator to augment, amend, or erase, during normal use, any program software in the equipment required for operation in accordance with the equipment standard. Data used during operation and stored in the system is to be protected in such a way, that necessary modifications and amendments by the user cannot endanger its integrity and correctness Default values are to be inserted whenever relevant to facilitate the required operation of the equipment Display and update of essential information available in the equipment as well as safety related function is not to be inhibited due to operation of the equipment in any particular mode, for example dialogue mode The system is to give an indication when presented information is uncertain or derived from conflicting sources Software is to be protected against intrusion by efficient protections, such as antivirus, password levels, firewalls, as relevant Monitoring Means is to be provided to monitor automatically the operational software and stored data of the equipment. The check is to be carried out during system start-up and at regular intervals, as indicated in the manufacturer's documentation. In the case of a non-automatically recoverable error or failure, the system is to release an independent alarm observable to the user on the workstation. (e.g.: Watchdog) An error log must be installed and activated in order to supervise the program execution and it unwished execution An alarm is to be triggered before the lack of computer resources could endanger the software execution Fall-Back arrangement After a failure, or when sensor data become invalid, the software is to support the availability of essential information and functions, by using appropriate fallback arrangements It is to be clearly indicated when the mode in use is not the normal mode to fully perform the function of the software After a fallback arrangement, recovery of normal operation is only to be restored upon confirmation by the operator. Power interruption or intentional shut down is not to be treated as a Fallback condition 2.6. Documentation The document is to be concise and easy to follow The level of detail provided is to be appropriate to the purpose of the document. 10 Bureau Veritas July 2008

11 The information is to contain the evidence of document control (e.g. second reading, check by other person than the author ) The Software Requirement Specification is to describe a high level system overview The internal and external interface and data flows are to be described in high level system diagrams The system function and/or data flow is to be clearly and completely described The software environment (hardware, software, resources, and users) is to be specified All referenced documents, definitions acronyms and abbreviations are to be listed The Software Requirement Specification is to contain a general description of the software system and operational concepts The user characteristics are to be defined General design, implementation constraints, dependencies are to be noted. General assumptions that affect implementation are to be stated Timing requirements are to be provided. Timing and memory limits are to be compatible with hardware constraints Any limit and/or restriction on software performance are to be defined (e.g. contract requirements, hardware capability...) Each function is to be defined separately, with its purpose and scope The functional requirements are to be stated in terms of inputs, outputs and processing The functional requirements are to be the bases for detailed design and functional tests cases The software Requirement Specification is to include a description of the performance requirements for each function The hardware limitations are to be identified for each function The following are to be identified: Environmental conditions (risk of inadvertent alteration of software) Computer software inventory (list of existing software intended to be used) Databases, Test software (simulator ) Tests methods (tests demonstration, analysis or inspection and acceptance criteria) Computer hardware resources A software user s guide is to be available for assessment. july 2008 Bureau Veritas 11

12 3. Software Development process 3.1. General Support tools and programming languages a) A suitable set of integrated tools, including languages, compilers, configuration management tools, and when applicable, automatic testing tools, are to be selected for the required software category. The availability of suitable tools to supply the relevant services over the whole software lifetime is to be considered. b) Coding standards are to be: Reviewed by the assessor; Used for the development of all software. c) The coding standards specify good programming practice, proscribe unsafe language features, and specify procedures for source code documentation. As a minimum, the following information is to be contained in the source code documentation: Legal entity (for example company, author(s), etc ); Description; Inputs and outputs; Configuration management history. d) The software is to be produced to achieve modularity, testability and capability of safe modification. e) For each major component or subsystem described in the software architecture design, further refinement of the design is to be based on a partitioning into software modules (i.e. specification of the software system design). The design of each software module and the tests to be applied to each software module is to be specified Code implementation a) The source code: is to be readable, understandable and testable; is to satisfy the specified requirements for software module design; is to satisfy the specified requirements of the coding standards; is to satisfy all relevant requirements specified during safety analyse. b) Each module of software code is to be reviewed Module testing a) Each software module is to be tested as required during software specification. b) These tests are to demonstrate that each software module performs the intended function and does not lead to unintended behaviour (e.g. software is robust to unattended input data). c) The results of the software module testing are to be documented. d) The procedures for corrective action on failure of test are to be specified Integration testing a) Software integration tests are to be specified concurrently during the specification and development phases. b) The specification of software integration tests are to include: The division of the software into manageable integration sets; Test cases and test data; Types of tests to be performed; Test environment, tools, configuration and programs; Test criteria on which the completion of the test will be judged; and Procedures for corrective action on failure of test. c) The tests are to demonstrate that all software modules and software components/ subsystems interact correctly to perform their intended function and do not lead to any unintended behaviour. d) The results of software integrating testing are to be documented; stating objectives and test criteria have been met. Reasons of any failure are to be analysed. e) During software integration, any modification or change is to be subjected to an impact analysis, which determines all software modules influenced, and the necessary re-verification and re-design activities. 12 Bureau Veritas July 2008

13 Validation a) The pass/fail criteria for achievement of software validation is to include: The required input signals with their sequences and their values; The anticipated output signals with their sequences and their values; and Other acceptance criteria, for example memory usage, timing and value tolerances Software modification a) Prior to carrying out any software modification, relevant procedures are to be made available. b) A modification is to be initiated within the scope of authorized procedure for which specifications are to be detailed as follows: The reasons of change; The proposed changed; The possible hazard. c) An analysis is to be carried out on the impact of the proposed software modification on the system functionalities in order to determine: whether or not a hazard and risk analysis is required; which software lifecycle phases will need to be repeated. d) The impact analysis results are to be documented. e) Regression tests are to be specified Verification a) The verification of software is to be planned according to software quality plan. b) The software verification planning refers to the criteria, techniques, and tools to be used in the verification activities, and address: The evaluation of the safety integrity requirements where applicable; The selection of documentation strategies, activities and techniques; The selection and utilisation of verification tools; The evaluation of verification results; The corrective actions to be taken. c) Documentary evidence is to point out that software control has been satisfactorily completed at each step. d) For each verification step documentation is to include: Identification of items; Identification verification data; Non-conformances. e) The following verification activities are to be performed: Verification of software requirements; verification of software architecture; verification of software system design; verification of software modules design; verification of code; data verification; software module testing; software integration testing; programmable hardware integration testing; Software safety requirements testing, where applicable. f) Regression tests are to be performed, after modifications, where applicable Software Quality Plan (Guidelines) Generality The Software Quality Assurance (SQA) Plan establishes the methods to be used to achieve the objectives of the SQA process. The SQA Plan may include descriptions of process improvement, metrics, and progressive management methods. This plan should include: a) Environment: A description of the SQA environment, including scope, organizational responsibilities and interfaces, standards, procedures, tools and methods. b) Authority: A statement of the SQA authority, responsibility, and independence, including the approval authority for software products. july 2008 Bureau Veritas 13

14 c) Activities: The SQA activities that are to be performed for each software life cycle process and throughout the software life cycle including: SQA methods, for example, reviews, audits, reporting, inspections, and monitoring of the software life processes. Activities related to the problem reporting, tracking and corrective action system. A description of the software conformity review activity. d) Transition criteria: The transition criteria for entering the SQA process. e) Timing: The timing of the SQA process activities in relations to the activities of the software life cycle processes. f) SQA Records: A definition of the records is produced by the SQA process. g) Supplier s control: A description of the means of insuring those sub-tier suppliers processes and outputs will comply with the SQA Plan Quality assurance and control Quality assurance and control are based on the production and the follow-up of the quality plan. The quality plan is to be updated following the development progress. It is to be reviewed by all the participants in its production. Note 1: ISO/IEC gives guidelines for the application of ISO 9001 to the development, supply, and maintenance of software. Note 2: Refer also to SOLAS Ch. V Reg Bureau Veritas July 2008

15 4. Software Assessment 4.1. Software classification The guidance is based on the classification defined for the computer-based systems. The computer based systems are to be assigned into three system categories as shown in Table I, according to the possible extent of damage caused by a single failure within the computer-based systems. Consideration is to be given to the extent of the damage directly caused by a failure, but not to any consequential damage. Identical redundancy will not be taken into account for the assignment of a system category. The assignment of a computer-based system to the appropriate system category is to be made according to the greatest likely extent of direct damage. For example, refer to Table II Note: Where independent effective backup or other means of averting danger is provided the system category III may be decreased by one category. Table I: System/software categories Category Effects System functionality I II III Those systems, failure of which will not lead to dangerous situations for human safety, safety of the vessel and/or threat to the environment. Those systems, failure of which could eventually lead to dangerous situations for human safety, safety of the vessel and / or threat to the environment Those systems, failure of which could immediately lead to dangerous situations for human safety, safety of the vessel and / or threat to the environment. Monitoring function for Informational administrative tasks Alarm & monitoring functions Control functions which are necessary to maintain the ship in its normal operational and habitable conditions Control functions for maintaining the vessel s propulsion and steering Safety functions (1) Navigation Functions (1) Software systems related to safety functions are subjected to specific analysis by the Society in accordance within IEC x (e.g. emergency shut-down engine safeties) july 2008 Bureau Veritas 15

16 Category Examples (1) I II III Table II: Example of assignment to system/software categories Maintenance support systems Information and diagnostic systems Alarm & monitoring equipment Tank capacity measuring equipment Control systems for auxiliary machinery Main propulsion remote control systems Fire detection systems Fire extinguishing systems Bilge systems Governors Machinery protection systems/equipment Burner control systems Electronic fuel injection for diesel engines Loading instrument, Stability computer Navigation equipment used for course control Control systems for propulsion and steering Course control systems, including positioning systems where manual intervention to avert danger in the event of failure or malfunction is no longer possible (1) The examples listed are not exhaustive 4.2. Software Category notations To the three categories of software defined in 4.1 correspond respectively three notations as follows: ST1: software category I ST2: software category II ST3: software category III The category notations are brought on attestation certifying that the considered software has been examined by the Society, in accordance with the requirements of the present document. The attestation, issued within the scope of the Bureau Veritas Marine Division General Conditions, is valid five years. After this period, it may be renewed, the possible modifications being submitted to the Society. Any changes in software design or in using conditions, which would have not be submitted to the Society, could entail withdrawal of these attestations 4.3. Software Assessment Condition of granting Software approval is granted, subject to the assessment of the development quality and test results as referred in. The whole documentation and test evidence are to be provided to the Society. Additional documents may be requested for evaluation of software A Software Assessment attestation may be issued at the request of the manufacturer when approval is granted 16 Bureau Veritas July 2008

17 Documentation Table III: Tests reports and documentation to be submitted No. Tests and evidence Software Category I II III 1. Evidence of quality system 1.1. Quality plan for software M S S 1.2. Quality control in production M M 1.3. Final test reports M S S 1.4. Traceability of software M M S 2. Evidence of software validity requirements : - safety of operation - Monitoring - Fallback arrangement 2.1. Software description M M S 2.2. Failure analysis for safety related functions only M S 3. Evidence of software testing 3.1. Evidence of software testing according to quality plan M S 3.2. Analysis regarding existence and fulfilment of programming M S procedures for safety related functions 3.3. Code inspection, walk through M 4. Software tests (1) 4.1. Module tests M S 4.2. Subsystem tests M S 4.3. System Tests M S 5. Performance tests 5.1. Integration test M W 5.2. Fault simulation W W 5.3. Factory acceptance Test (FAT) M W W 6. Modifications 6.1. Tests after modifications (2) W/S W/S 7. User s guide M = Evidence kept by manufacturer and submitted on request S = Evidence checked by the society W = To be witnessed by the society (1) In addition to the above, specific tests for program approval would be required for system which are parts of safety system or which integrate safety functions (See Note 1 Table II.) (2) Subsequent significant modifications to the software are to be submitted for approval. Note: A significant modification is a modification which influences the functionality and/or safety of the system july 2008 Bureau Veritas 17

18 18 Bureau Veritas July 2008

19 Annex A Questionnaire on the tests and inspections to be performed july 2008 Bureau Veritas 19

20 20 Bureau Veritas July 2008

21 REF Description Y, N, NA ST I ST II ST III Documentation provided GENERAL Are requested document lists available SOFTWARE REQUIREMENT 2.1 General a) b) Are standards and naming conventions specified? Is the software developed in independent modules to limit the consequence of failure? Is the software tested to verify the ability to perform intended functions? Is the code of practice specified and conform to a quality control system? Is complex software structured to support separated testing of single modules or of groups of associated modules? Is the structure able to support maintenance and updates? Is configuration of operating system documented? Are tools and additional software identified and documented? 2.2 Functional requirements Are functional requirements clearly identified and documented? 2.3 Safety of operation Is software protected by facilities incorporated in the equipment? Is software part of equipment installed with the equipment in such a way that it is not possible for the user to have access? Is software part of equipment protected against modification by the user? Does the software contain default values to facilitate the user when needed? Can the display and update of essential operation be run during any other particular mode? Does the equipment indicate if information is uncertain? Is software protected against intrusion? july 2008 Bureau Veritas 21

22 REF Description Y, N, NA ST I ST II ST III Documentation provided 2.4 Monitoring Is mean provided to monitor the equipment automatically, checked at regular intervals? Does the system release an alarm in case of non automatically recoverable error? Is an error log installed and activated in order to supervise the program execution and it unwished execution? Is an alarm triggered before the memory is full? 2.5 Fallback arrangement Is it indicated if the mode in use is not the normal mode to fully perform the function? Does fallback arrangements support essential information and function in case of failure? After fallback arrangement, is recovery of normal operation restored upon operator confirmation? 2.6 Documentation Is documentation concise, including functional descriptions, all evidences of control, interfaces, limitations? SOFTWARE DEVELOPMENT PROCESS a) b) c) d) e) Support tools and programming language Are integrated tools selected for the required software category? Are the coding standards reviewed by the assessor and used for the development of all the software? Are legal entity, description, inputs and outputs, configuration management history contained in the source code? Can the software be modular, testable and safely modifiable? Is each module software design and tested separately? 22 Bureau Veritas July 2008

23 REF Description Y, N, NA ST I ST II ST III Documentation provided Code implementation a) a) a) a) b) Is the source code readable, understandable and testable? Does the source code satisfy the specified requirements for a software module design? Does the source code satisfy the specified requirements of the coding standards? Does the source code satisfy all relevant requirements specified during safety analyse? Is each module of software code reviewed? Module testing a). Is each software module tested? b) Do the tests show that each module performs its intended function and does not perform unintended function? c). Are the result of module testing documented? d). Are the procedures for corrective action on failure of tests specified? Integration testing a) b) b) b) b) b) b) c) d) e) Are the software integration tests specified during the specification and development phases? Do integration tests specify the division of the software into manageable integration sets? Do integration tests specify test cases and test data? Do integration tests specify types of tests to be performed? Do integration tests specify test environments, tools, configuration and programs? Are test criteria specified, on which the completion of the test will be jugged? (expected results) Do integration test specify procedures for corrective action of failure of test? Do the software tests demonstrate the protection against unintended behaviour? Are the results of integration software tests documented, indicating reason of failure, if any? Is an analyse carried out when a modification of software is necessary during the integration software? july 2008 Bureau Veritas 23

24 REF Description Y, N, NA ST I ST II ST III Documentation provided Validation a) Do the pass/fail criteria for validation include input/output signals with their sequences and values and other acceptance criteria? Software modification a) b). c) d) Are procedures of modification available? Are the modification initiated within of an authorised procedure? Is an analyse on the impact of software modification on system functionalities performed and documented? e) Are regression tests specified? Verification a) b) Is the verification software available and planned in accordance with the quality plan? Are criteria, techniques, and tools used for verification activities planned? c) Is the documentation result available? d) Are evidences of all steps of verification available? e) Have all verification activities been performed (specification, design, coding, testing)? f) Have regression tests been performed after modifications? SOFTWARE QUALITY PLAN Generality Have standards / guidelines been identified to define the work product? Has project specific criteria been added? Was this assessment conduct as scheduled? Is there evidence that the work product was reviewed by all stakeholders? Have acceptance criteria been established for the work product? Does the work product have a clearly define purpose and scope? Does the purpose specify what software items are covered by the plan? Does the purpose specify the intended use of the software? 24 Bureau Veritas July 2008

25 REF Description Y, N, NA ST I ST II ST III Documentation provided Does the purpose state what portion of the life cycle is covered by the plan? Does the plan contain applicable references? Are versions and dates provided for each reference document? Does the plan contain a section outlining the management structure for the project? Does the plan detail the documentation governing the development, verification, validation, use and maintenance of the software produced? Is there a set of documents listed and described? Does this plan list which documents are to be assessed by the Software Quality Plan? Are standards, practices, and quality requirements use identified (e.g. IEC, ISO, IEEE )? Does this plan describe how process and product conformance shall be monitored and assured (e.g. tracked, reported, and trended)? Is there a schedule of reviews? Does the plan describe Software Quality Plan's role at reviews? Does the plan identify and describe the Software Quality Plan's role in the software verification? Does the plan identify and describe the Software Quality Plan's role in the software validation? Does the plan describe the practices and procedures reporting, tracking, and problem resolution? Does the plan discuss which tools and techniques shall be used to support software assurance activities (e.g. checklists, plan and report templates, tracking databases)? Does the plan discuss how insight / oversight will be accomplished to ensure supplier control to customer requirements (e.g. inspections, assessments / audits, monthly status reports)? july 2008 Bureau Veritas 25