Section 3 Software
Clasification Society 2024 - Version 9.40
Clasifications Register Rules and Regulations - Rules and Regulations for the Classification of Offshore Units, July 2022 - Part 3 Functional Unit Types and Special Features - Chapter 15 Integrated Software Intensive Systems - Section 3 Software

Section 3 Software

Parent topic: Chapter 15 Integrated Software Intensive Systems

3.1 General, scope and objectives

3.1.1 Where software is used as the implementation technology for the ISIS then the additional requirements in 3.1.2 to 3.1.9 are to be applied. Where a proposed activity is not undertaken, justification is to be documented and submitted.

3.1.2 A plan for the production of software is to be produced and is to include, but not limit to, the elements listed below.
  1. A full list of software components being developed and, for each, what is required to be produced including code artefacts, tools, specifications, design models, and documentation.
  2. The identification of the deliverables, including those for the purposes of late project phase activities such as boat/platform integration, boat trials, operations and maintenance.
  3. Details of any work that is being subcontracted and how the subcontract will be managed, including specifically ensuring that the Software Development Plan for the software lifecycle will be adhered to.
  4. An identification of the principal project risks arising from the development work.
  5. A definition of the software lifecycle is to be deployed.
  6. The processes, methods, techniques and tools to be used for each phase of the software lifecycle, including:
    • pedigree of chosen language, tools and design methods;
    • the identification of specific software architecture and software design features appropriate to the reliance being placed on the software; and
    • verification performed at each stage of the lifecycle including measures to show that all the requirements, have been correctly translated or implemented by the lifecycle phase activities.
  7. Identify the key personnel in the software development team and in any subcontractors, and their responsibilities. The competency of software development team, especially experience of using the processes, methods, techniques and tools to be used.
  8. Analysis of the software architecture and the software design to confirm that the specific design features which are implemented by functions to satisfy the requirements will work as intended in all modes of operation and failure conditions.
  9. Details of the code implementation and coding standards to be applied to ensure that the software code will be reliable and maintainable.
  10. Validation activities to demonstrate that the functions of the software specifically implemented to satisfy the requirements will operate as intended in all feasible operating scenarios, including:
    • testing to show that hazard mitigations work as intended;
    • testing and demonstration of safe and acceptable behaviour even in unexpected states, modes and failure conditions; and
    • testing that functions implemented to satisfy the requirements work in all credible operating scenarios.

3.1.3 Additional requirements for verification and validation of software components in software-based control systems that handles safety and critical operational functions are listed in 3.1.4 to 3.1.9.

3.1.4 Evidence of satisfying the requirements of ISO/IEC 21119: Software and Systems Engineering – Software Testing, or ISO/IEC 61508-3 Functional safety of electrical/electronic/programmable, is to meet requirements 3.1.5 to 3.1.9 in this sub-Section.

3.1.5 Evidence is to be submitted that software test scenarios and software test results cover all of the independent paths. Evidence is to be submitted that test results and software static tests on control flow, data flow and design review are to be used to analyse the quality of software code.

3.1.6 For the purpose of black-box testing, evidence is to be submitted that test results, methods, techniques and tools that are acceptable to LR are applied before and after integrations.

3.1.7 Evidence is to be submitted that test results and software tests listed below are to be applied for software verification:
  1. Dynamic analysis and testing for:
    • Boundary values, structural test coverage (entry points) 100 per cent and structural test coverage (statements) 100 per cent.
  2. Static analysis and testing for:
    • Control flow, data flow and design review.
  3. Functional and black box testing on:
    • Equivalence classes and input partition testing including boundary value analysis.
  4. Performance testing for:
    • Response timings and memory constraints, performance requirements.
  5. Data recording and analysis.
  6. Regression testing.
3.1.8 Evidence is to be submitted that test results and software tests listed below are to be applied for software validation:
  • Functional and black box testing.

3.1.9 Evidence that coding reviews have been undertaken is to be submitted.

Copyright 2022 Clasifications Register Group Limited, International Maritime Organization, International Labour Organization or Maritime and Coastguard Agency. All rights reserved. Clasifications Register Group Limited, its affiliates and subsidiaries and their respective officers, employees or agents are, individually and collectively, referred to in this clause as 'Clasifications Register'. Clasifications Register assumes no responsibility and shall not be liable to any person for any loss, damage or expense caused by reliance on the information or advice in this document or howsoever provided, unless that person has signed a contract with the relevant Clasifications Register entity for the provision of this information or advice and in that case any responsibility or liability is exclusively on the terms and conditions set out in that contract.