Destination Earth DESP Use Cases: DestinE Sea Ice Decision Enhancement (DESIDE) Software Verification and Validation Plan SVVP
COMMENTS and ISSUES |
PDF This document is available in PDF format here. |
EUROPEAN SPACE AGENCY CONTRACT REPORT |
EOX IT Services GmbH |
- AMENDMENT HISTORY
-
This document shall be amended by releasing a new edition of the document in its entirety.
The Amendment Record Sheet below records the history and issue status of this document.Table 1. Amendment Record Sheet ISSUE DATE REASON 0.1
11/12/2023
Initial in-progress draft
0.2
22/04/2024
Update for Review 1
1.0
22/04/2024
First released version
1.1
19/09/2024
Second released version
1. Introduction
1.1. Purpose and Scope
This document represents the Software Verification and Validation Plan (SVVP) for the DESIDE project 8482 with ESA contract 4000140320/23/I-NS. This document describes generic regression/unit tests that are run on the software when new commits are performed to ensure the software is still functioning as expected.
1.2. Structure of the Document
1.3. Reference Documents
The following is a list of Applicable and Reference Documents with a direct bearing on the content of this document.
Reference | Document Details | Version |
---|---|---|
[SOW] |
Statement of Work Destination Earth DESP Use Cases selection - Round 1 |
1.0 |
[Proposal] |
Proposal No. 8482: DestinE Sea Ice Decision Enhancement (DESIDE) |
1.1 |
1.4. Terminology
The following terms have been used in this document.
Term | Meaning |
---|---|
Admin |
User with administrative capabilities on a platform. |
Code |
The codification of an algorithm performed with a given programming language - compiled to Software or directly executed (interpreted) within the platform. |
Discovery |
User finds products/services of interest to them based upon search criteria. |
Interactive Web Application |
An Interactive Application for analysis provided as a rich user interface through the user’s web browser. |
Key-Value Pair |
A key-value pair (KVP) is an abstract data type that includes a group of key identifiers and a set of associated values. Key-value pairs are frequently used in lookup tables, hash tables and configuration files. |
Object Store |
A computer data storage architecture that manages data as objects. Each object typically includes the data itself, a variable amount of metadata, and a globally unique identifier. |
Products |
EO data (commercial and non-commercial) and Value-added products. |
Software |
The compilation of code into a binary program to be executed within the platform on-line computing environment. |
User |
An individual using the services. |
Visualization |
To obtain a visual representation of any data/products held within the platform - presented to the user within their web browser session. |
Web Coverage Service (WCS) |
OGC standard that provides an open specification for sharing raster datasets on the web. |
Web Feature Service (WFS) |
OGC standard that makes geographic feature data (vector geospatial datasets) available on the web. |
Web Map Service (WMS) |
OGC standard that provides a simple HTTP interface for requesting geo-registered map images from one or more distributed geospatial databases. |
Web Map Tile Service (WMTS) |
OGC standard that provides a simple HTTP interface for requesting map tiles of spatially referenced data using the images with predefined content, extent, and resolution. |
Web Processing Services (WPS) |
OGC standard that defines how a client can request the execution of a process, and how the output from the process is handled. |
1.5. Glossary
The following acronyms and abbreviations have been used in this document.
Term | Definition |
---|---|
ADD |
Architecture Design Document |
AOI |
Area of Interest |
API |
Application Programming Interface |
COG |
Cloud optimized GeoTiff |
EO |
Earth Observation |
EOX |
EOX IT Services GmbH |
ESA |
European Space Agency |
FUSE |
Filesystem in Userspace |
ICD |
Interface Control Document |
JSON |
JavaScript Object Notation |
KVP |
Key-value Pair |
M2M |
Machine-to-machine |
OGC |
Open Geospatial Consortium |
PMP |
Project Management Plan |
REST |
Representational State Transfer |
SDD |
Software Design Document |
SFTP |
Secure File Transfer Protocol |
SRF |
Software Reuse File |
SRN |
Software Release Note |
SRP |
Software Release Plan |
SRS |
Software Requirements Specification |
SSH |
Secure Shell |
STAC |
Spatio-Temporal Asset Catalog |
SUM |
Software User Manual |
SVVP |
Software Verification and Validation Plan |
SVVR |
Software Verification and Validation Report |
TOI |
Time of Interest |
UMA |
User-Managed Access |
US |
User Story |
WCS |
Web Coverage Service |
WFS |
Web Feature Service |
WMS |
Web Map Service |
WMTS |
Web Map Tile Service |
WPS |
Web Processing Service |
WPS-T |
Transactional Web Processing Service |
2. Overview
Polar View Earth Observation Limited is working in collaboration with EOX IT Services, Drift+Noise Polar Services, the Danish Meteorological Institute, the Norwegian Meteorological Institute, and the Finnish Meteorological Institute to develop a fully functional Use Case that utilizes the DESP/DestinE system capabilities and data and adds value to meet the needs of policy and decision makers who require information on the past, current, and forecasted sea ice and other relevant conditions for operational purposes in the Baltic Sea, European Arctic Ocean, and the rest of the polar regions.
The Use Case will build on and complement existing operational and climate sea ice products and services including those provided by the Copernicus Marine Service, the national Ice Services, the ESA Polar Thematic Exploitation Platform (Polar TEP), and the commercial Drift+Noise IcySea app. The Use Case will augment and improve on the current offerings by:
-
Aggregating information of different types and from different sources to provide common products that span jurisdictional boundaries.
-
Producing new products that will improve the ability of users to make good decisions.
-
Making the products available in ways and means that are appropriate for the skills and requirements of different user communities.
One driver for the project is the regulation of the International Maritime Organization (IMO) of the United Nations mandating that ships operating in the polar regions meet certain requirements (the Polar Code). Among other things, the Polar Code specifies a range of information that ships traveling in polar waters are required to access for planning and operations. The Use Case will demonstrate the value of short and medium-term forecasts of sea ice, meteorological, and ocean conditions suitable for strategic and tactical decision making by ships and their owners.
A second driver for the project is the effect of climate change on polar conditions that will impact long-term planning and policy development for polar operations such as fishing, tourism, scientific research campaigns, oil and gas development, and supplying northern communities. The Use Case will deliver long-term forecasts of how changing sea ice and other conditions will affect where different types of ships will be able to travel in the polar regions compared to historical averages.
Benefits to polar operations and the rest of society will include increased safety of life and property, decreased pollution, and protection of sensitive environmental areas.
3. Verification
The verification approach for the DESIDE system consists of a combination of unit testing, integration testing, and system testing.
Unit Testing: Each component of the data pipeline undergoes thorough unit testing. Unit tests are designed to verify the individual functionality of each component in isolation. The unit tests ensure that the components perform as expected and adhere to the defined requirements.
Integration Testing: Integration testing is conducted to verify the interactions and compatibility between the components of the data pipeline. Integration tests are executed to ensure proper data flow and integration points between the components. These tests focus on verifying the overall functionality and communication of the integrated components.
Server Testing: The server responsible for data sharing is subjected to a comprehensive set of tests. These tests cover various aspects, including data input/output verification, data storage and retrieval, error handling, and performance under different load conditions. The server tests are designed to ensure the reliability, stability, and efficiency of the data sharing functionality.
System Testing: The main repository, which contains the deployment and bundling system, is verified through system testing. System tests are designed to evaluate the end-to-end functionality and behavior of the software system as a whole. These tests cover various scenarios and use cases to ensure that the system operates as intended and meets the specified requirements.
To facilitate the testing process, the pytest
framework has been selected as the primary testing tool. pytest
offers ease of use, is widely adopted within the industry, and provides comprehensive documentation. Its rich set of features enables efficient test development, execution, and result analysis.
The rationale behind this approach is to ensure that each component of the software system is thoroughly verified in isolation, as well as in conjunction with other components to verify their integration. By adopting a combination of unit testing, integration testing, and system testing, we aim to identify and address any issues early in the development cycle, ensuring the delivery of a high-quality and reliable software system.
3.1. Verification activities
This section outlines the verification activities for key DESIDE components.
Requirement | System Requirement ID | Description | Verification method |
---|---|---|---|
Interactive dashboard |
REQ01 |
Data relevant for the Use Cases are available in online Polar Dashboard |
Demonstration |
Data access |
REQ02 |
Data relevant for the Use Cases are available through Polar TEP Interactive development environment |
Demonstration |
Connection between IcySea and Polar TEP |
REQ03 |
Ensuring data transfer and connection between IcySea and Polar TEP |
Testing |
Available DESP Data |
REQ04 |
The available DESP data is accessible via the provided Jupyter notebook. |
Demonstration |
Available Data |
REQ05 |
The available fallback data is accessible via the provided Jupyter notebook. |
Demonstration |
Available DESP Data |
REQ06 |
The available DESP data is accessible via the provided Jupyter notebook. |
Demonstration |
Available Data |
REQ07 |
The available fallback data is accessible via the provided Jupyter notebook. |
Demonstration |
Available DESP Data |
REQ08 |
The available DESP data is accessible via the provided Jupyter notebook. |
Demonstration |
Available Data |
REQ09 |
The available fallback data is accessible via the provided Jupyter notebook. |
Demonstration |
Available Data |
REQ10 |
The available RCM data is accessible via the dashboard visualisation. |
Demonstration |
Available Data |
REQ11 |
The available sea ice chart data are accessible via the dashboard and usable by polaris algorithm. |
Demonstration |
3.2. Verification criteria and acceptance
Types of verifications performed:
-
Tests
-
Demonstration
3.2.1. Test
Test Execution: The primary acceptance criteria for verification is that all tests, including unit tests, integration tests, and system tests, pass successfully without any critical failures or errors.
Test Results: The verification process will consider the test results generated from the execution of the test suite. The results should indicate a high percentage of passed tests, demonstrating that the software system meets the expected functionality and behavior.
Error Handling: The software system should exhibit appropriate error handling mechanisms. Verification will verify that error messages are displayed accurately, and the system recovers gracefully from errors without causing any data loss or instability.
3.2.2. Demonstration
In addition to testing, demonstration will be conducted as part of the verification process. The demonstration aims to showcase the functionality, features, and capabilities of the software system in a real or simulated environment.
By including a demonstration as part of the verification process, we aim to provide stakeholders with a tangible and visual representation of the software system’s capabilities. The demonstration serves as an effective means to validate the software against the specified requirements and ensure that it meets the expectations of the end-users and stakeholders.
<< End of Document >>