5 Software quality assurance (SQA)

5.1 Key to ensuring software quality in e-navigation is to address the quality attributes that need to be considered in the development and design of e-navigation systems as highlighted in figure 1.

5.2 Software in support of e-navigation can be a product on its own, or part of a larger system and includes data and information. A key function of e-navigation software is to harmonize, integrate, exchange, present and analyze maritime data and information to meet user needs.

5.3 Functional Safety: The performance of systems related to e-navigation software should be assured in terms of required functions and level of integrity. The reliability and availability of safety-related functions should be specified based on stakeholder requirements and traceable through documentation. Functional safety requirements should be defined, implemented and managed throughout the life cycle. The required level of functional safety can vary depending on the designed functionality and intended use, and should be determined by an appropriate risk-based process. Guidance for ensuring functional safety is provided in IEC 61508 or relevant standards.

5.4 Security: It is important to consider and properly address security to prevent cyber-attacks, hacking or other illegal intrusions. Any e-navigation implementation should provide a secure digital environment, in particular: addressing avoidance, prevention and detection of any cyber security threats, locally, regionally and internationally. Guidance on software and cyber security is provided in ISO/IEC 27000 or relevant standards.

5.6 The Product quality model categories are: functional suitability, performance efficiency, compatibility, usability^footnote, reliability, security, maintainability and portability.

5.7 Software quality is also dependant on the quality of input data, which should conform to relevant international standards. As shown in figure 1, data quality is one of the key attributes of e-navigation systems. Data quality requirements and data quality characteristics should be based on ISO/IEC 25012 and related standards (i.e. International Hydrographic Organization (IHO) standards for nautical information including Electronic Navigational Charts (ENC)). These standards propose a general data quality model to support organizations to acquire, manipulate and use data with the necessary quality characteristics. It is recommended that Data Quality Assurance (DQA) is performed using a quality management system such as ISO/IEC 90003 or relevant standards.

5.9 Producers of input data should have life cycle management practices in place to handle possible data format changes during the life cycle. These life cycle management practices should include timely announcements to software producers and end users about such changes. As part of DQA, producers of input data should test all data in service for conformance with relevant international standards.

5.10 The quality-in-use of a system characterizes the impact that the product (system or software product) has on stakeholders, measuring effectiveness, efficiency, freedom from risk and satisfaction in specific contexts of use. It is determined by the quality of the software, hardware and operating environment and by the characteristics of the users, tasks and social environment. All these factors contribute to the quality-in-use of the system. Examples of quality-in-use measures are given in ISO/IEC 25024.

5.11 Appendix 2 provides details of recommended sub-activities to be undertaken during the software life cycle to ensure the development of better quality software.

5.12 Software quality evaluation: The required software quality depends on the intended use or objectives of the system of which the software is a part. Software products need to be evaluated during design, implementation and integration to determine whether the relevant quality characteristics are met.

5.14 For each activity, applicable measurement tools, constraints, inputs and outputs are identified. Outputs of previous activities can be used as inputs to subsequent stages. The first activity may include output from previous evaluations as an input.

5.15 When an evaluation is performed concurrently with software product development, associated activities can be performed as part of software life cycle processes (ISO/IEC 12207 or relevant standards) and/or system life cycle processes (ISO/IEC 15288 or relevant standards).

Activity 1: Definition of stakeholders and system requirements

5.17 This activity involves specifying the required characteristics and identifying the context of use of the system being developed. During this activity validation and conformance requirements of the system will also be identified.

Activity 2: Analysis of system requirements

5.18 This activity involves defining a set of functional and non-functional system requirements with various configurations developed in order to ensure an optimized solution. This activity results in a prioritized, approved and updated set of system requirements including SQA requirements which are consistent and traceable.

Activity 3: Software architecture design and implementation

5.19 This activity involves defining and structuring the elements of the system, ensuring it meets defined software quality requirements. The verification between the system requirements and the system architecture should also be carried out during this stage. A strategy for software integration based on the priorities of the system requirements needs to be developed with criteria to verify compliance.

5.20 An important aspect to be considered during the early stages of software design is software reuse. This needs to be considered during stages 1 to 3 of the software life cycle. Software reuse is the use of existing software assets in some form within a software development process. Software assets include products from prior developments such as components, test suites, designs and documentation. Software assets may be modified as needed to meet new system requirements.

Activity 4: Software testing, installation and acceptance

5.21 This activity ensures that the integrated software is compliant with the system requirements. Appropriate methods and standards for testing software should be developed to ensure the reliability and validity of the software qualification test and, as much as possible, conformance to expected results. Software qualification testing should take place in its intended operational environment. As previously mentioned, appropriate test data sets provided by relevant international organizations such as IALA and IHO should be used to ensure conformance to shore-based data. An important pre-condition is to ensure that the use of shore- and ship-based data has been subject to a DQA process. This activity also involves evaluating and testing the integrated system using pre-defined criteria, with evidence produced that demonstrates quality assurance.

5.22 Verification of conformance: It is recommended that certificates of conformance to existing software and data quality should meet relevant standards to ensure the verification of software systems.

5.23 It is recommended that the verification process for e-navigation SQA be carried out by reviewing the related documents on the e-navigation software system or data, by inspecting the implementation of the e-navigation software system and testing the software functions. It is recommended that the testing environment covers berth-to-berth operation, ship-to-ship communication, ship-to-shore communication as well as shore-to-shore communication.

Activity 5: Software operation and maintenance

5.24 This activity involves the identification and evaluation of conditions for correct operation of the software in its intended environment. An operation and maintenance strategy needs to be developed in consultation between the software developers and users. This will ensure that any software and system modifications, upgrades, changes to the existing system interface and updating of system and software documentation are appropriately managed and do not compromise product requirements or safety.

Activity 6: System disposal

5.25 A system disposal strategy should be developed to facilitate knowledge retention and analysis of long-term impacts. A hardware disposal strategy should also be developed to promote the use of non-hazardous materials during manufacturing.

5.26 Note that some of the software quality activities described in this section will also overlap with the HCD process activities described in section 6.