Adding initial SVVP

SRS/index.adoc

@@ -31,7 +31,7 @@
 :pdf-stylesdir: resources/themes
 :pdf-style: custom
 :media: screen
-:title-logo-image: image::DESIDE.png[top=5%, align=right, pdfwidth=6.96in]
+:title-logo-image: image::DESIDE.png[top=5%, align=right]
 
 = {doc-title}: {doc-num}
 

SVP/01.introduction/00.introduction.adoc

@@ -0,0 +1,22 @@
+
+= Introduction
+
+== Purpose and Scope
+
+This document represents the Software Verification and Validation Plan (SVVP) for the {component-name} project.
+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.
+
+== Structure of the Document
+
+Section 2 - <<mainOverview>>::
+This section provides an overview of the {component-name}
+
+Section 3 - <<mainVerification>>::
+This section provides the software verification and validation plans, activities, resources, acceptance criteria, schedule and change control.
+
+include::03.reference-docs.adoc[leveloffset=+1]
+
+include::04.terminology.adoc[leveloffset=+1]
+
+include::05.glossary.adoc[leveloffset=+1]

SVP/01.introduction/03.reference-docs.adoc

@@ -0,0 +1,20 @@
+
+= Reference Documents
+
+The following is a list of Applicable and Reference Documents with a direct bearing on the content of this document.
+
+[cols="2,7a,2a"]
+|===
+| Reference | Document Details | Version
+
+| [SOW]
+| Statement of Work Destination Earth DESP Use Cases selection - Round 1 +
+Reference: CS301353.Docref.0002
+| 1.0
+
+| [Proposal]
+| Proposal No. 8482: DestinE Sea Ice Decision Enhancement (DESIDE)
+| 1.1 +
+06/06/2023
+
+|===

SVP/01.introduction/04.terminology.adoc

@@ -0,0 +1,55 @@
+
+= Terminology
+
+The following terms have been used in this document.
+
+[cols="1,3"]
+|===
+| 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.
+
+|===

SVP/01.introduction/05.glossary.adoc

@@ -0,0 +1,44 @@
+
+= Glossary
+
+The following acronyms and abbreviations have been used in this document.
+
+[cols="1,6"]
+|===
+| 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
+| 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
+|===

SVP/02.overview/00.overview.adoc

@@ -0,0 +1,64 @@
+[[mainOverview]]
+= Overview
+
+This section provides an overview of the {project} {component-name}. It highlights the services identified by the functionalities which they provide together with a comprehensive overview of the information model forming the foundation of the developed software. The figure below outlines the architectural overview of the services.
+
+.VS System architecture overview
+image::architecture.png[]
+
+== Software services
+
+An overview of services is given in the following subchapters. For a broader description of these services refer to the link:https://esa.pages.eox.at/pdgs/documentation/SDD/index.html[Software Design Document].
+
+=== Web Client
+
+The Web Client is a browser based interactive web application which consumes the Renderer and Cache services in order to portray imagery, display metadata, enable download, and query functionality.
+
+=== Cache
+
+The purpose of this service is to provide a caching layer for the WMS interface of the Renderer service, as visualizations may be computationally costly to produce.
+
+=== Renderer
+
+The Renderer service renders the imagery to visualizations for clients and provides OGC Web Services using OpenSearch, WMS, & WCS. The WMS requests are also rendered using this service if received from the Cache. It is based on the core image like the Registrar and uses the EOxServer rendering and service capabilities.
+
+=== Registrar
+
+The purpose of the Registrar service is to register data products from different data sources. It is based on the core image like the Renderer and in addition to using EOxServer as a backend it can be extended to support different backends.
+
+=== Harvester
+
+The Harvester is a separate service based on the harvester image, and its purpose is to fetch data from existing systems, such as Spatio-Temporal asset Catalog and API, OpenSearch, S3, Swift and Local files.
+This data is collected in a STAC item form and sent down the processing pipeline.
+
+=== Scheduler
+
+The Scheduler is its own service and enables sending a signal to any component on a fixed schedule.
+
+=== Preprocessor
+
+The Preprocessor is based on the preprocessor image and it receives preprocess requests coming from the Harvester in order to translate data to a COG. After that the files are sent to the Registrar.
+
+=== Fluentd
+
+Stream oriented data collector for a unified logging layer.
+Forms a part of the EFK (Elasticsearch, Fluentd, Kibana) log storage, aggregation and visualization stack.
+
+=== Elasticsearch
+
+Real-time, distributed search engine which allows for full-text and structured search.
+Forms a part of the EFK (Elasticsearch, Fluentd, Kibana) log storage, aggregation and visualization stack.
+
+=== Kibana
+
+Data visualization frontend and dashboard for Elasticsearch.
+Forms a part of the EFK (Elasticsearch, Fluentd, Kibana) log storage, aggregation and visualization stack.
+
+=== Curator
+
+Elasticsearch Curator allows to manage Elasticsearch indices and snapshots and via filters to progressively remove indices.
+
+=== Reverse Proxy
+
+As a configured instance of Traefik software, this service provides a unified interface and routing to the provided services together with authentication and authorization facilities.
+It provides the main HTTP interface for the whole system. All requests are internally routed via a mapping configuration.

SVP/03.verification/00.verification.adoc

@@ -0,0 +1,31 @@
+[[mainVerification]]
+= 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.
+
+
+include::01.activities.adoc[leveloffset=+1]
+
+include::02.criteria.adoc[leveloffset=+1]
+
+include::03.resources.adoc[leveloffset=+1]
+
+include::04.change.adoc[leveloffset=+1]
+
+include::05.schedule.adoc[leveloffset=+1]
+
+include::06.code.adoc[leveloffset=+1]
+
+include::07.performance.adoc[leveloffset=+1]

SVP/03.verification/01.activities.adoc

@@ -0,0 +1,6 @@
+= Verification activities
+
+This section outlines the verification activities for key DESIDE components.
+
+== TBD
+

SVP/03.verification/02.criteria.adoc

@@ -0,0 +1,20 @@
+= Verification criteria and acceptance
+
+Types of verifications performed:
+
+* Tests
+* Demonstration
+
+== 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.
+
+== 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.

SVP/03.verification/03.resources.adoc

@@ -0,0 +1,22 @@
+= Verification resources
+
+This section outlines the resources which are utilized for conducting of the verification activities.
+
+The main resources are:
+
+1. GitLab Runner
+2. GitHub Actions
+
+These resources offer the necessary infrastructure and automation capabilities to execute the verification activities effectively. The use of a self-hosted GitLab Runner and GitHub Actions ensures reliable and controlled environments for conducting the tests and analyzing the results.
+
+== GitLab Runner
+
+The ETL components and system testing utilize a self-hosted GitLab Runner for test execution.
+The self-hosted GitLab Runner provides a dedicated environment for running tests and ensures consistent and controlled testing conditions.
+The configuration and management of the GitLab Runner are handled internally by the project team.
+
+== GitHub Actions
+
+Some testing activities make use of GitHub Actions for test execution.
+GitHub Actions provide an automated workflow and testing environment for running tests on the server.
+The GitHub Actions workflow is configured and maintained within the project's GitHub repository.

SVP/03.verification/04.change.adoc

@@ -0,0 +1,34 @@
+= Verification change control
+
+Change control procedures are implemented to manage any changes to the software system during the verification process. This ensures that changes are properly evaluated, documented, and approved to maintain the integrity of the verification effort. The following steps outline the change control process:
+
+Change Identification:
+
+- Any proposed change to the software system is identified and documented.
+- Changes can include modifications to requirements, design, code, or any other aspect of the system that may impact verification.
+
+Change Impact Assessment:
+
+- The impact of the proposed change on the verification effort is assessed.
+- The verification team evaluates the potential effects of the change on test plans, test cases, test data, verification schedule, and other relevant aspects.
+- The assessment considers the potential risks and benefits of implementing the change.
+
+Change Approval:
+
+- The proposed change is reviewed and approved by the designated change control authority.
+- The approval decision is based on the impact assessment, project priorities, and alignment with the overall project goals.
+- The change control authority may consist of project managers, stakeholders, or a designated change control board.
+
+Change Implementation:
+
+- Once the change is approved, it is implemented according to the established procedures.
+- The necessary modifications are made to the affected artifacts, such as test plans, test cases, or verification documentation.
+- The verification team ensures that the necessary updates are communicated to all relevant stakeholders.
+
+verification Impact Review:
+
+- After implementing the change, the verification team reviews the impact of the change on the verification activities.
+- Test plans, test cases, or any other affected verification artifacts are updated to reflect the changes.
+- The verification team verifies that the implemented change does not adversely affect the overall verification process or compromise the quality of the software system.
+
+Effective change control procedures help maintain the integrity and reliability of the verification effort by ensuring that any changes to the software system are properly evaluated, documented, and incorporated into the verification process. These procedures help minimize risks associated with changes and ensure that the verification remains aligned with the project goals.

SVP/03.verification/05.schedule.adoc

@@ -0,0 +1,13 @@
+= Verification schedule
+
+The software verification activities will be conducted in a flexible manner that accommodates the dynamic nature of the development process. While there is no fixed schedule for the verification activities, the following approach is adopted:
+
+1. Iterative verification: The verification process is integrated into the development iterations or cycles. As each component or feature reaches a stable state, verification activities are performed to ensure its functionality, performance, and compliance.
+
+2. Continuous Integration: The verification activities are integrated into the continuous integration and delivery (CI/CD) pipeline. Automated tests are triggered upon code changes, ensuring that the software system is continuously verified as new features or updates are introduced.
+
+3. Trigger-Based verification: verification activities may be triggered by specific events, such as significant changes in the software system, updates to dependencies, or critical bug fixes. These triggers initiate a focused verification effort to ensure the stability and reliability of the affected areas.
+
+4. verification on Demand: verification activities may be requested by stakeholders, such as project managers, clients, or regulatory bodies. These requests are addressed promptly, and verification efforts are planned and executed accordingly.
+
+The absence of a fixed schedule allows for a flexible and adaptable approach to software verification, enabling the verification activities to align with the evolving nature of the software development process. The verification plan is continuously updated to incorporate any changes or adjustments to the verification timeline.