Difference between revisions of "Ecosystem Approach Community of Practice: The iMarine Board"

From D4Science Wiki
Jump to: navigation, search
(The Overall Flow of the Work Plan)
(Harmonization of systems)
 
(75 intermediate revisions by 2 users not shown)
Line 3: Line 3:
 
|}
 
|}
 
== Overview ==
 
== Overview ==
The primary goal of the iMarine Board is to define the data e-Infrastructure governance model, with a sustainability focus, and to formulate a set of organizational and technological policy recommendations regulating the resources shared and services provided by the infrastructure.
+
“The primary goal of the iMarine Board is to define the data e-Infrastructure governance model, with a sustainability focus, and to formulate a set of organizational and technological policy recommendations regulating the resources shared and services provided by the infrastructure.”
 +
 
 +
This goal will be achieved by the Board by providing assistance and recommendations to the iMarine e-Infrastructure partners in orchestrating the activities to ensure an effective exploitation of the e-infrastructure. The Board has a primary role in outreach and marketing of the e-infrastructure, and its activities range from identifying opportunities for collaboration and sharing of resources, to organizing the collection of requirements, support to implementing solutions, and ensuring packaging of outcomes in manageable resources.
 +
 
 +
The Board is convened for formal '''meeting sessions''' every 6 months.
 +
 
 +
Formal aspects of the Board (mandate, membership, officers, decision making process, operational policies, ...) are defined in Board’s '''Rules and procedures'''.
 +
 
 +
The Board operates by defining among it’s members and the EA-CoP a range of objectives, and the '''work plan''' to achieve these. The objectives are verifiable outcomes that will be validated to measure project success.
  
 
== Rules and Procedures ==
 
== Rules and Procedures ==
  
<font color=red>TO BE COMPLETED. A draft version (pending Board Approval), is available [http://dlib.sns.it/bscw/bscw.cgi/d249391/iMarineBoardRules_v5.pdf here]</font>
+
The June 2012 version of the Rules and Procedures governing the operations of the iMarine Board is available [http://goo.gl/rkkL1I here]
 +
 
 +
=== Criteria for prioritization ===
 +
The Rules and Procedures refer to a set of criteria that govern the prioritization setting of initiatives in the Board's decision making process.  
 +
 
 +
These criteria were agreed at the iMarine Board kick-off meeting, They are:
 +
* Users now;
 +
* Co-funding;
 +
* Project structural allocation of resources;
 +
* Clearly referred to in the iMarine Description of Work;
 +
* Related to EA-CoP business cases;
 +
* The proposed actions support sustainability aspects relevant to the EA-CoP;
 +
* Consistency with EC regulations/strategies such as INSPIRE;
 +
* Re-usability with clear benefits to EA-CoP representatives and proven compatibility with EA-CoP resources.
 +
 
 +
== Overall workplan ==
 +
 
 +
=== WP3 objectives and activities ===
 +
 
 +
Project activities involving the EA-CoP take place under WP3. These activities are organized according to the three main objectives:
 +
 
 +
'''1. Operations of the iMarine Board''':
 +
*  Meetings of the iMarine Board
 +
*  Meetings of the iMarine Advisory Council
 +
*  Mobilization of/mediation with the wider EA-CoP concerned by the three Business cases
 +
 
 +
'''2. Governance and Policy developments'''
 +
 
 +
The Governance relate to the activities of the EA-CoP where they interact with the e-Infrastructure. It describes how Deliverable D3.2 (M10) and D3.3 (M29), that report on this governance, are achieved.
 +
*  Development of the Sustainability plan
 +
*  Development of Governance model
 +
*  Development of Data Policies
 +
*  Development of Software Policies
 +
*  Development of guidelines and best practices
 +
 
 +
'''3. Harmonization of systems and schemas'''
 +
 
 +
Harmonization activities are organized by technical clusters and can be validated through the VREs set-up to serve the Business cases
 +
*  VREs planning
 +
*  Technical Clusters: Statistical; Biodiversity; Geospatial; Semantics
 +
 
 +
.
 +
=== Status of Board's overall workplan ===
 +
 
 +
At its first session, the iMarine Board has initiated the elaboration of an '''overall workplan''' which spans across the entire project duration. This workplan provides an overview of Board's activities and related timing expectations, and is used to identify possible conflicting use of project resources in order to decide on priorities.
 +
 
 +
* after Board 1 meeting - the [http://goo.gl/rgfBLj Board Work Plan] overview in Excel format (Registration required)
 +
 
 +
* after Board 3 meeting - the Board Work Plan was updated until July 2013
 +
 
 +
* The '''[[Ecosystem_Approach_Community_of_Practice_Overview:_Clusters#Cluster_Work_Plans_in_iMarine | Cluster Work Plans ]]''' page describes the work plans scheduled by the technical clusters;
 +
 
 +
== Implementation results ==
 +
 
 +
This section describes the tangible outputs of activities listed in the above workplan
 +
 
 +
=== Mediation with the CoP concerned by the Business cases ===
 +
 
 +
==== iMarine Board '''meetings''' ====
 +
They constitute the primary mechanism for mediation among the EA Community of Practice directly involved in the project. The '''[[Ecosystem_Approach_Community_of_Practice:_Meetings | meetings]]''' page documents the events organised to support the board activity including their reports, recommendations and conclusions;
 +
* iMarine kick-off meeting
 +
* First iMarine Board meeting  (March 2012)-  this meeting has elaborated  the '''[[Ecosystem_Approach_Community_of_Practice:_The_iMarine_Board#Rules_and_Procedures | iMarine Board Rules and Procedures]]''' ; this page describes the regulations and principles supporting the operation of this board;
 +
* First Advisory Council meeting (March 2012)- this meeting has brought together for the first time the 5 advisors who were presented the iMarine's objectives and strategy and the potential for the platform.
 +
* Second iMarine Board meeting (October 2012) -  this meeting has discussed a second version of the Data access and sharing policy, and consolidated the plans regarding the harmonization of systems.
 +
* Third iMarine Board meeting (March 2013) - this meeting further discussed the Data access and sharing policies, and review the progress towards work plan objectives.
 +
* Second Advisory Council meeting (March 2013)- the meeting was organized in conjunction with the third iMarine Board meeting in Rome, and presented the results and collected feedback and advice from the Bard Advisors.
 +
 
 +
==== iMarine collaborations ====
 +
 
 +
iMarine collaborations progressively develop through various stages, starting with a Mobilization/outreach phase and pursued further with negotiation then implementation phases. The progressin collaboration can be tracked in the [[IMarine_Liaisons]]
 +
 
 +
===== Mobilization through outreach =====
 +
The mediation efforts of the iMarine Board are primarily geared towards serving the three '''Business cases'''. The '''[[Ecosystem_Approach_Community_of_Practice:_iMarine_Business_Cases | iMarine Business Cases]]''' page describes policy driven business needs which will eventually  be supported by one or more VRE's.
 +
 
 +
The iMarine Board must first mobilize the concerned CoP; this mobilisation effort calls for '''liaison and outreach''' activities to the EA-CoP, as identified by the iMarine Board.
 +
 
 +
By Board2 (October 2012) the following outreach activities had been recorded:
 +
* BC2 - Presentation of iMarine to High Seas Deep Seas VME community (December 2011)
 +
* BC3 - Presentation of iMarine to GEF/ABNJ Tuna project (FAO team in February 2012; Steering Committee in June 2012)
 +
* BC1 - Presentation of iMarine to DG-MARE (June 2012)
 +
* BC3 - Presentation of iMarine to SmartFish Indian Ocean community (July 2012, Harmonization workshop)
 +
* Attendance of the ICES Conference
 +
 
 +
===== Negotiation phase =====
 +
A second phase in the mobilization requires more targetted mediation efforts in order to progressively refine which are the more specific needs which iMarine can address in support of the concerned CoP and business case.
 +
 
  
== Workplan ==
 
  
=== What are iMarine Work Plans ===
+
By Board3 (March 2013), a comprehensive iMarine Collaborations deliverable has been produced. These collaborations are at various stages of development. See the iMarine liaison page.
  
In the iMarine project Deliverable ''D3.1, EA-CoP Operation'', WP3 documents the functioning of the EA-CoP. The deliverable is this wiki articulated with a web based tool for managing the meetings, their reports and progress reports, recommendations and conclusions; the imarine Board channel. Deliverable chapters are Work plans, iMarine Board meetings, and Supported Business Cases. The chapters are implemented as section of the wiki.
+
=== Governance ===
  
This section, on work plans, describes the 2 main activities related to work plans over a given period of time. They first cover the activities needed to convince decision makers such as the iMarine Board for its approval, then as a guiding document for the activities to be carried out during that time period, and how to validate the results.
+
Conclusions of the D4Science project and the first iMarine forums stress that the Governance proposal must be adjusted to the business model and to the size of the CoP which can be expected at the end of the iMarine project. Developing a governance proposal is therefore tightly related to the sustainability plan.  
  
The iMarine Board meeting section contains the documented response of the Board individual members or the body as a whole on the presented work plans.
+
* the '''[[Ecosystem_Approach_Community_of_Practice: Sustainable use of the data e-Infrastructure | Sustainable use of the data e-Infrastructure]]''' page;
  
The last wiki section will cover the rationale behind the decision process that will govern the selection of the business cases to support and it will illustrate the features of the third and unselected business case that could be addressed in the remaining selected business cases. Part of this rationale will relate to the feasibility of the implementation through work plans.
+
* '''[[Ecosystem_Approach_Community_of_Practice:_Governance | Governance]]''' page;
  
=== Work Plans in iMarine ===
 
The main purpose of the work plans are to provide the iMarine Board with a planning and management instrument (tool) that provides a framework for '''planning activities''', and that can serve as a '''guide''' for carrying out that work. The scope is the interface between Board and project activities; they aim to implement a iMarine Board technical goal. They do therefore not cover iMarine Board deliberations or governance activities, technical activities below the radar of the Board, and maintenance.
 
  
It also contributes to project transparency, as the plans are accessible to those persons or organizations who have a need or a right to know what will happen, when, and why, during the project.
 
  
The work plans relate to objectives specified in the DoW. They are orthogonal to the Work Packages (WP), as their implementation typically requires effort from several WP's. They are also agnostic of Business Cases (BC's), as these relate to a CoP vision that may have little or nothing to do with the tools and resources needed to achieve it. Work Plan specify a strategy to operate in a specific time segment with effort from one or more WP’s. They identify (as goals) the problems to be solved, make them finite, precise and verifiable as objectives, indicate the resources needed and constraints to be overcome, outline a strategy, and identifies the actions to be taken in order to reach the objectives and complete and validate the outputs.
+
Policies constitute key Governance instruments. The iMarine project will develop Data oriented policies, and Software oriented policies. See the '''[[Ecosystem_Approach_Community_of_Practice: iMarine Policies | iMarine Policies]]''' page;
  
The DoW does much the same, but for the whole time period of the project, and it is written prior to project approval as a justification for approval of the project, not for it’s output.
+
The first draft of iMarine Data Access and Sharing policy has been presented at the first iMarine Board meeting
 +
* the '''[[EA-CoP Data Access and Sharing Policies]]''' page;
  
In order to efficiently plan the resources, work plans can cut across the Business Cases. It makes little sense to implement solutions for e.g. geospatial data management separately for each business case. This necessitated the definition of clusters, as described in the DoW.
 
 
When approved, the work plan serves as a guide to actions to be taken in order to reach the objectives, written so as to be transparent to anyone, inside or outside the implementing group, in describing those objectives, and outputs, and justifying the actions to be taken.
 
  
The strategy is based on the problems that are to be solved and what resources are available for solving the problems and what hindrances are to be overcome. The strategy of choice to reach the solution, according to the DoW, is based on well-proven Agile
+
Guidelines and best practices enable a practical implementation of the above policies through more user oriented description:
Development principles. Software components will be developed and released in short and continuous iterations, each release addressing the need of new functionality or the need to revise existing functionality. This choice impacts on how problems are described; rather than a few large problems, they need to cover multiple smaller ones.
+
* the '''[[Ecosystem_Approach_Community_of_Practice: iMarine Guidelines and Best Practices | iMarine Guidelines and Best Practices]]''' page;
  
The goals and objectives (when accomplished) are the output of the project. They must therefore be formulated thus that they are measurable. The outputs are validated, and thus need to be enriched with information on their required quality with regards to performance, completeness and coverage.  
+
.
  
The resources (when used) are the inputs of the project, and the aim of the strategy is to convert inputs into outputs.
+
=== Harmonization of systems ===
  
==== Period Covered by Work Plans ====
+
Board's objectives include organizing the collection of requirements accross the three Business cases, providing support to implementing solutions, and ensuring packaging of outcomes in manageable resources. This sub-set of objectives are articulated under the "Harmonization of systems".  
The optimum length for a work plan is between six and twelve months. A three month work plan is too short, considering the amount of time and effort needed to prepare the plan. A twenty four month work plan might be too long, because conditions change during a whole year, and by the end of the year the objectives and priorities may have have all become different. They should align with the general project reviews.
+
  
=== The Structure and Content of the Work Plans ===
+
As mentioned above, the response to Business case needs will be delivered through a set of VREs. Furthermore, the first iMarine Board meeting has described how a team work organized by technical clusters can better contribute to achieve harmonization of schemas and IT solutions across business cases.
An iMarine work plan includes the following parts:
+
* Abstract or Executive Summary;
+
* Introduction and Background (The Problems);
+
* Goals and Objectives (The Outputs);
+
* Resources and Constraints (The Inputs);
+
* Strategy and Actions (from Inputs to Outputs);
+
* Appendices (Budget, Resources, Documents, Schedule and Others).
+
  
==== The Overall Flow of the Work Plan ====
+
The '''''[[Ecosystem_Approach_Community_of_Practice:_Requirements | Requirements]]''''' area contains:
The work plan consists of a main text and appendices. The appendices may include budgets, agreements, external resources, data formats, etc. They are put into appendices at the end of the work plan, as they do not form part of the argument.
+
  
iMarine takes an Agile approach to programming, and the work plans do not need contain details at the start of any activity. Where these are known, or where there are expected dependencies on tools, services or other resources, these need to be described first.  
+
* the '''[[Ecosystem_Approach_Community_of_Practice:_VRE_planning | VRE planning]]''' page which describes the EA-CoP desiderata in terms of a composition of services and resources, delivered as a packaged single unit to the CoP. A VRE provides a defined set of services for a specific group of users that collaborate on a specified task or workflow. An alternative approach to VREs are gCube apps. In the context of the CoP desiderata, no difference is made.
  
Work plans are initiated in WP3 and identified and aligned with the content of the DoW. This ensures that they provide a relevant progress towards the realization of one or more business cases and that the project as a whole benefits from their services. After drafting, they work plan needs approval in the iMarine Board, following Board procedures. If an agreement has been reached, the work plan is forwarded to the Project Executive Board, from where implementation effort from the technical work packages will be identified. WP3 will collaborate with WP6 and representatives of the iMarine Board to monitor implementation.
+
* the '''[[Ecosystem_Approach_Community_of_Practice_Overview:_Clusters | Clusters]]''' page describes how the CoP organizes the requirements collection and discussion on high-level topics in a set of organic, but also technological clusters; geospatial, biodiversity, statistics, and semantic technologies all are supported by technologies that overlap in functionality with other clusters, yet are still easily identifiable as falling within one of the clusters.
  
=== Work Plan Pages ===
+
* the Use Cases articulated around specific exploitation scenarios of infrastructure resources by communities capture the functional and organization requirements to complete a defined set of activities. The descriptions for not only the base for benchmarking the completeness of the proposed solution, but are also used to validate the technology package.
  
* [[ICIS Draft Work Plan Q2-3 2012 | Statistics Draft Work Plan Q2-3 2012 ]]
+
=== Validation ===
* [[Semantics Draft Work Plan Q2-3 2012]]
+
According to the Description of Work, the goal of this activity is (i) to document status and issues on harmonization approaches, and
* [[Geospatial Draft Work Plan Q2-3 2012]]
+
(ii) to validate implemented policies and business cases, their functionality and conformance to requirements.
* [[Biodiversity Draft Work Plan Q2-3- 2012]]
+
  
== Meetings ==
+
The '''''[[Ecosystem_Approach_Community_of_Practice:_Validation|Validation]]''''' area describes:
 +
* The procedure followed to validate VRE's;
 +
* The overall results; i.e. the appreciation of the e-infrastructure by the EA-CoP;
 +
* The validation activity results; a VRE may be validated multiple times, and the activity results are reported here.

Latest revision as of 12:36, 15 January 2014

Overview

“The primary goal of the iMarine Board is to define the data 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. governance model, with a sustainability focus, and to formulate a set of organizational and technological policy recommendations regulating the resources shared and services provided by the infrastructure.”

This goal will be achieved by the Board by providing assistance and recommendations to the iMarine 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. partners in orchestrating the activities to ensure an effective exploitation of the e-infrastructure. The Board has a primary role in outreach and marketing of the e-infrastructure, and its activities range from identifying opportunities for collaboration and sharing of resources, to organizing the collection of requirements, support to implementing solutions, and ensuring packaging of outcomes in manageable resources.

The Board is convened for formal meeting sessions every 6 months.

Formal aspects of the Board (mandate, membership, officers, decision making process, operational policies, ...) are defined in Board’s Rules and procedures.

The Board operates by defining among it’s members and the EA-CoPCommunity of Practice. a range of objectives, and the work plan to achieve these. The objectives are verifiable outcomes that will be validated to measure project success.

Rules and Procedures

The June 2012 version of the Rules and Procedures governing the operations of the iMarine Board is available here

Criteria for prioritization

The Rules and Procedures refer to a set of criteria that govern the prioritization setting of initiatives in the Board's decision making process.

These criteria were agreed at the iMarine Board kick-off meeting, They are:

  • Users now;
  • Co-funding;
  • Project structural allocation of resources;
  • Clearly referred to in the iMarine Description of Work;
  • Related to EA-CoPCommunity of Practice. business cases;
  • The proposed actions support sustainability aspects relevant to the EA-CoPCommunity of Practice.;
  • Consistency with EC regulations/strategies such as INSPIRE;
  • Re-usability with clear benefits to EA-CoPCommunity of Practice. representatives and proven compatibility with EA-CoPCommunity of Practice. resources.

Overall workplan

WP3 objectives and activities

Project activities involving the EA-CoPCommunity of Practice. take place under WP3. These activities are organized according to the three main objectives:

1. Operations of the iMarine Board:

  • Meetings of the iMarine Board
  • Meetings of the iMarine Advisory Council
  • Mobilization of/mediation with the wider EA-CoPCommunity of Practice. concerned by the three Business cases

2. Governance and Policy developments

The Governance relate to the activities of the EA-CoPCommunity of Practice. where they interact with 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.. It describes how Deliverable D3.2 (M10) and D3.3 (M29), that report on this governance, are achieved.

  • Development of the Sustainability plan
  • Development of Governance model
  • Development of Data Policies
  • Development of Software Policies
  • Development of guidelines and best practices

3. Harmonization of systems and schemas

Harmonization activities are organized by technical clusters and can be validated through the VREs set-up to serve the Business cases

  • VREs planning
  • Technical Clusters: Statistical; Biodiversity; Geospatial; Semantics

.

Status of Board's overall workplan

At its first session, the iMarine Board has initiated the elaboration of an overall workplan which spans across the entire project duration. This workplan provides an overview of Board's activities and related timing expectations, and is used to identify possible conflicting use of project resources in order to decide on priorities.

  • after Board 1 meeting - the Board Work Plan overview in Excel format (Registration required)
  • after Board 3 meeting - the Board Work Plan was updated until July 2013

Implementation results

This section describes the tangible outputs of activities listed in the above workplan

Mediation with the CoPCommunity of Practice. concerned by the Business cases

iMarine Board meetings

They constitute the primary mechanism for mediation among the EA Community of PracticeA term coined to capture an "activity system" that includes individuals who are united in action and in the meaning that "action" has for them and for the larger collective. The communities of practice are "virtual", ''i.e.'', they are not formal structures, such as departments or project teams. Instead, these communities exist in the minds of their members, are glued together by the connections they have with each other, as well as by their specific shared problems or areas of interest. The generation of knowledge in communities of practice occurs when people participate in problem solving and share the knowledge necessary to solve the problems. directly involved in the project. The meetings page documents the events organised to support the board activity including their reports, recommendations and conclusions;

  • iMarine kick-off meeting
  • First iMarine Board meeting (March 2012)- this meeting has elaborated the iMarine Board Rules and Procedures ; this page describes the regulations and principles supporting the operation of this board;
  • First Advisory Council meeting (March 2012)- this meeting has brought together for the first time the 5 advisors who were presented the iMarine's objectives and strategy and the potential for the platform.
  • Second iMarine Board meeting (October 2012) - this meeting has discussed a second version of the Data access and sharing policy, and consolidated the plans regarding the harmonization of systems.
  • Third iMarine Board meeting (March 2013) - this meeting further discussed the Data access and sharing policies, and review the progress towards work plan objectives.
  • Second Advisory Council meeting (March 2013)- the meeting was organized in conjunction with the third iMarine Board meeting in Rome, and presented the results and collected feedback and advice from the Bard Advisors.

iMarine collaborations

iMarine collaborations progressively develop through various stages, starting with a Mobilization/outreach phase and pursued further with negotiation then implementation phases. The progressin collaboration can be tracked in the IMarine_Liaisons

Mobilization through outreach

The mediation efforts of the iMarine Board are primarily geared towards serving the three Business cases. The iMarine Business Cases page describes policy driven business needs which will eventually be supported by one or more VREVirtual Research Environment.'s.

The iMarine Board must first mobilize the concerned CoPCommunity of Practice.; this mobilisation effort calls for liaison and outreach activities to the EA-CoPCommunity of Practice., as identified by the iMarine Board.

By Board2 (October 2012) the following outreach activities had been recorded:

  • BC2 - Presentation of iMarine to High Seas Deep Seas VME community (December 2011)
  • BC3 - Presentation of iMarine to GEF/ABNJ Tuna project (FAO team in February 2012; Steering Committee in June 2012)
  • BC1 - Presentation of iMarine to DG-MARE (June 2012)
  • BC3 - Presentation of iMarine to SmartFish Indian Ocean community (July 2012, Harmonization workshop)
  • Attendance of the ICES Conference
Negotiation phase

A second phase in the mobilization requires more targetted mediation efforts in order to progressively refine which are the more specific needs which iMarine can address in support of the concerned CoPCommunity of Practice. and business case.


By Board3 (March 2013), a comprehensive iMarine Collaborations deliverable has been produced. These collaborations are at various stages of development. See the iMarine liaison page.

Governance

Conclusions of the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. project and the first iMarine forums stress that the Governance proposal must be adjusted to the business model and to the size of the CoPCommunity of Practice. which can be expected at the end of the iMarine project. Developing a governance proposal is therefore tightly related to the sustainability plan.


Policies constitute key Governance instruments. The iMarine project will develop Data oriented policies, and Software oriented policies. See the iMarine Policies page;

The first draft of iMarine Data Access and Sharing policy has been presented at the first iMarine Board meeting


Guidelines and best practices enable a practical implementation of the above policies through more user oriented description:

.

Harmonization of systems

Board's objectives include organizing the collection of requirements accross the three Business cases, providing support to implementing solutions, and ensuring packaging of outcomes in manageable resources. This sub-set of objectives are articulated under the "Harmonization of systems".

As mentioned above, the response to Business case needs will be delivered through a set of VREs. Furthermore, the first iMarine Board meeting has described how a team work organized by technical clusters can better contribute to achieve harmonization of schemas and IT solutions across business cases.

The Requirements area contains:

  • the VRE planning page which describes the EA-CoPCommunity of Practice. desiderata in terms of a composition of services and resources, delivered as a packaged single unit to the CoPCommunity of Practice.. A VREVirtual Research Environment. provides a defined set of services for a specific group of users that collaborate on a specified task or workflow. An alternative approach to VREs are gCube apps. In the context of the CoPCommunity of Practice. desiderata, no difference is made.
  • the Clusters page describes how the CoPCommunity of Practice. organizes the requirements collection and discussion on high-level topics in a set of organic, but also technological clusters; geospatial, biodiversity, statistics, and semantic technologies all are supported by technologies that overlap in functionality with other clusters, yet are still easily identifiable as falling within one of the clusters.
  • the Use Cases articulated around specific exploitation scenarios of infrastructure resources by communities capture the functional and organization requirements to complete a defined set of activities. The descriptions for not only the base for benchmarking the completeness of the proposed solution, but are also used to validate the technology package.

Validation

According to the Description of Work, the goal of this activity is (i) to document status and issues on harmonization approaches, and (ii) to validate implemented policies and business cases, their functionality and conformance to requirements.

The Validation area describes:

  • The procedure followed to validate VREVirtual Research Environment.'s;
  • The overall results; i.e. the appreciation of the e-infrastructure by the EA-CoPCommunity of Practice.;
  • The validation activity results; a VREVirtual Research Environment. may be validated multiple times, and the activity results are reported here.