Ecosystem Approach Community of Practice: Validation

Goal and Overview

According to the Description of Work, the conception and validation of concrete applications serving the business cases is part of the WP3 activity. The goal of the validation activity is to

• document status and issues on harmonization approaches, and
• validate implemented policies and business cases, their functionality and conformance to requirements.

The approach taken in iMarine builds on the experience gained in the validation efforts of the preceding D4ScienceAn e-Infrastructure operated by the D4Science.org initiative.-II project, where the FURPS model was adopted to generate templates against which to 'benchmark' the performance of a component.

FURPS is an acronym representing a model for classifying software quality attributes (functional and non-functional requirements):

• Functionality - Feature set, Capabilities, Generality, Security
• Usability - Human factors, Aesthetics, Consistency, Documentation
• Reliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
• Performance - Speed, Efficiency, Throughput, Response time
• Supportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Serviceability, Localizability

The validation in iMarine, where the commitments of the EA-CoPCommunity of Practice. reaches further then in the previous project, validation will be done on requirements and specifications produced by the EA-CoPCommunity of Practice., where these can be aligned with iMarine Board Work Plan objectives.

This implies that the validation is not equivalent to testing individual component behavior and performance in the e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large., but assesses to progress towards achieving a Board objective. This gives the validation an important role in one of the Board main activities priority setting to improve the sustainability of the e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large..

Validation thus focuses on project outputs, and does not intend to influence the underlying software architecture, development models, software paradigms or code base.

A validation is triggered by the release of a software component, part thereof, or data source that is accessible by project partners through a GUI in the e-InfrastructureAn operational combination of digital technologies (hardware and software), resources (data and services), communications (protocols, access rights and networks), and the people and organizational structures needed to support research efforts and collaboration in the large..

Procedure(s) and Supporting tools

The validation procedure

Once a VREVirtual Research Environment. is released, those Board Members that have expressed their interest in the component (through the Board Work Plan) are alerted by the WP3 Leader, and the validation commences with the compilation of a set of questions, based on the above FURPS criteria.

The feed-back is collected by the WP3 Leader, discussed with the technical Director or other project representatives, and, when necessary, enhancement tickets are produced, with a clear reference to the released component.

If the released VREVirtual Research Environment. is validated the first time, the Round 1 results are discussed with the validators and the EA-CoPCommunity of Practice. representatives they represent. If needed, the iMarine project is asked to add or edit modifications to the delivered functionality. If these modifications exceed the level of enhancement tickets, a Round 2 validation is foreseen, which can be followed by other rounds until a satisfactory level of completeness has been achieved.

The reporting on the wiki

Validation results will also be documented in this wiki, which will contain the name of the component validated, the dates of validation, the results. Tickets will refer to the component name, the page where to validator comment originated, a descriptive text, and links to relevant documentation on the iMarine Board work plan and the validation wiki page.

Validation Results: Detailed Reports

One page for each "item" / functional area that is target of the validation activity;

VREVirtual Research Environment.'s and gCubeApps

• Data management with ICIS and related VREVirtual Research Environment.'s
  • VTI
  • SPREAD
  • Statistical analysis with R and the statistical service
• Reporting with FCPPS and related VREVirtual Research Environment.'s
  • Reporting
  • Documents Workflow and FiMES integration
  • New reporting VREVirtual Research Environment.’s: VME DB and Fisheries Country Profiles
• Species distribution map generation with AquaMaps VREVirtual Research Environment.
  • Data management
  • Map generation
• Biodiversity data discovery and access with the BiodiversityResearchEnvironment
• Ecological Modeling
• ScalableDataMining

Other community operated iMarine tools

• VREVirtual Research Environment. Management Tools
  • User and roles management
  • The shared workspace and other e-infrastructure driven communication facilities
• Remote connections (E.g. download from url’s)
  • Geoserver facilities
  • GeoNetwork facilities
• SDMX-registries
• Knowledge bases
  • FLOD
  • VocBench