Difference between revisions of "DJRA2.1 Report on Scenario Specific Technology Development"
m (→AquaMaps Scenario) |
|||
| (29 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
| − | = | + | [[Category:TO BE REMOVED]] |
| + | |||
| + | {|align=right | ||
| + | ||__TOC__ | ||
| + | |} | ||
| + | |||
The content of this report captures the development status of all software components that are direct or indirect consequence of the work performed by the Joint Research Activity 2 (JRA2) work package of the D4ScienceII project. | The content of this report captures the development status of all software components that are direct or indirect consequence of the work performed by the Joint Research Activity 2 (JRA2) work package of the D4ScienceII project. | ||
The objective of this work package is to cover the design and implementation case-specific needs for each particular interoperable infrastructure. Each case is analyzed and the system to implement it, on the side of the interoperating infrastructure, is designed in detail. Following the initial design, each case implements the specific components required so that it can exploit the facilities offered by the evolving ecosystem core and it can export the identified interoperable features to the rest of the ecosystem cases. | The objective of this work package is to cover the design and implementation case-specific needs for each particular interoperable infrastructure. Each case is analyzed and the system to implement it, on the side of the interoperating infrastructure, is designed in detail. Following the initial design, each case implements the specific components required so that it can exploit the facilities offered by the evolving ecosystem core and it can export the identified interoperable features to the rest of the ecosystem cases. | ||
| − | The cases involved in these scenarios are the ones defined by the high level needs and requirements exposed by the one of the following infrastructures and have been | + | The cases involved in these scenarios are the ones defined by the high level needs and requirements exposed by the one of the following infrastructures and have been specified through the NA4 and NA5 processes. The interoperability cases through this process evolved to specific implementation requirements whose definition and status of implementation is reported here. The implementation is performed in the context of the following tasks: |
| − | *INSPIRE specific implementation | + | * [[#INSPIRE|INSPIRE specific implementation]] |
| − | *DRIVER specific implementation | + | * [[#DRIVER|DRIVER specific implementation]] |
| − | *AquaMaps specific implementation | + | * [[#AquaMaps|AquaMaps specific implementation]] |
| − | *FCPPS specific implementation | + | * [[#FCPPS|FCPPS specific implementation]] |
| − | *ICIS specific implementation | + | * [[#ICIS|ICIS specific implementation]] |
| − | + | The progress is reported both in the context of each individual task as well as in the direction of ecosystem interoperability. The report groups related functionalities (from an implementation point of view), with respect to their impact on components that are involved. Thus, the status of development is presented by functional group. This status can be the result of the combined statuses of the various elements involved in a particular functional scope. Furthermore, as a single component might expose more than a single functional facet, it might be implicitly or explicitly involved in several functional groups. | |
| − | As a result of | + | As a result of one or more requirements, development can aim for: |
| − | *An entirely new software suite (Service including libraries and user interface elements if applicable) for extending gCube | + | * An entirely new software suite (Service including libraries and user interface elements if applicable) for extending gCube to cover new domains. |
| − | *A minor new component (of any of the aforementioned types) that plugs into the infrastructure (or to a particular existing component) in well defined areas, adding to its behavior. | + | * A minor new component (of any of the aforementioned types) that plugs into the infrastructure (or to a particular existing component) in well defined areas, adding to its behavior. |
| − | * Modification/extension of existing components, for provision of new functionality or modification/improvement of the existing one. | + | * Modification/extension of existing components, for provision of new functionality or modification/improvement of the existing one. |
| − | + | Requirements characterizing each case are documented in the dedicated wiki pages of '''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/NA5_Home NA5]'''. The guidelines governing the activities performed in this context can be found at the respective '''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/Communities_Practices_and_Requirements:_Guidelines_and_Template guidelines page]'''. The study of the documentation and requirements produced through these pages are the subject of analysis of dedicated system analysts producing a complete report documented under the '''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/Virtual_Organisations_and_Virtual_Research_Environments_Planning SA2 wiki]'''. This product is the basis upon which TRAC tickets are created to further link and monitor development activities. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | == Status == | |
| − | = | + | === INSPIRE === |
| − | '' | + | The '''requirements''' characterizing the INSPIRE scenario are documented in a dedicated wiki page ('''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/INSPIRE_Scenario INSPIRE Scenario]''') as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge. |
| − | + | The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the '''actions''' needed to satisfy them. This activity is ''continuous'', i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page ('''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/INSPIRE_Scenario_Analysis INSPIRE Scenario Analysis]'''). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The planned actions are recorded through TRAC tickets and organized into a '''living report''' ('''[https://issue.d4science-ii.research-infrastructures.eu/report/30 Report #30]''') that provide its users with an ever updated account on the '''scenario specific technology development activities''', including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | '' | + | |
| − | + | ||
| − | '' | + | |
| − | + | ||
| − | '' | + | |
| − | + | ||
| − | '' | + | |
| − | + | Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, '''current defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/39 Report #39]) and '''resolved defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/40 Report #40]). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, '''current incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/1 '''Report #1''']) and '''resolved incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/2 '''Report #2'''] and [https://issue.d4science-ii.research-infrastructures.eu/report/11 '''Report #11''']). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | [ | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | === | + | === DRIVER === |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The '''requirements''' characterizing the DRIVER scenario are documented in a dedicated wiki page ('''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/DRIVER_Scenario DRIVER Scenario]''') as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge. | |
| − | + | ||
| − | The | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the '''actions''' needed to satisfy them. This activity is ''continuous'', i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page ('''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/DRIVER_Scenario_Analysis DRIVER Scenario Analysis]'''). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ' | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | The planned actions are recorded through TRAC tickets and organized into a '''living report''' ('''[https://issue.d4science-ii.research-infrastructures.eu/report/31 Report #31]''') that provide its users with an ever updated account on the '''scenario specific technology development activities''', including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date. | |
| − | + | ||
| − | The | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, '''current defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/39 Report #39]) and '''resolved defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/40 Report #40]). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, '''current incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/1 '''Report #1''']) and '''resolved incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/2 '''Report #2'''] and [https://issue.d4science-ii.research-infrastructures.eu/report/11 '''Report #11''']). | |
| − | + | === AquaMaps === | |
| − | The | + | The '''requirements''' characterizing the AquaMaps scenario are documented in a dedicated wiki page ('''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/AquaMaps_Scenario AquaMaps Scenario]''') as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge. |
| − | The | + | The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the '''actions''' needed to satisfy them. This activity is ''continuous'', i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page ('''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/AquaMaps_Scenario_Analysis AquaMaps Scenario Analysis]'''). |
| − | + | The planned actions are recorded through TRAC tickets and organized into a '''living report''' ('''[https://issue.d4science-ii.research-infrastructures.eu/report/32 Report #32]''') that provide its users with an ever updated account on the '''scenario specific technology development activities''', including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date. | |
| − | + | Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, '''current defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/39 Report #39]) and '''resolved defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/40 Report #40]). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | ' | + | |
| − | + | ||
| − | ' | + | |
| − | + | ||
| − | '' | + | |
| − | + | In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, '''current incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/1 '''Report #1''']) and '''resolved incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/2 '''Report #2'''] and [https://issue.d4science-ii.research-infrastructures.eu/report/11 '''Report #11''']). | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | '' | + | |
| − | + | ||
| − | '' | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | '' | + | |
| − | = | + | === FCPPS === |
| − | '' | + | The '''requirements''' characterizing the FCPPS scenario are documented in a dedicated wiki page ('''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/FCPPS_Scenario FCPPS Scenario]''') as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge. |
| − | + | The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the '''actions''' needed to satisfy them. This activity is ''continuous'', i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page ('''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/FCPPS_Scenario_Analysis FCPPS Scenario Analysis]'''). | |
| − | + | ||
| − | + | The planned actions are recorded through TRAC tickets and organized into a '''living report''' ('''[https://issue.d4science-ii.research-infrastructures.eu/report/33 Report #33]''') that provide its users with an ever updated account on the '''scenario specific technology development activities''', including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date. | |
| − | + | ||
| − | + | Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, '''current defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/39 Report #39]) and '''resolved defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/40 Report #40]). | |
| − | + | ||
| − | + | In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, '''current incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/1 '''Report #1''']) and '''resolved incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/2 '''Report #2'''] and [https://issue.d4science-ii.research-infrastructures.eu/report/11 '''Report #11''']). | |
| − | + | ||
| − | + | === ICIS === | |
| − | + | ||
| − | + | The '''requirements''' characterizing the ICIS scenario are documented in a dedicated wiki page ('''[https://networking.wiki.d4science-ii.research-infrastructures.eu/networking/index.php/ICIS_Scenario ICIS Scenario]''') as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge. | |
| − | + | ||
| − | + | The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the '''actions''' needed to satisfy them. This activity is ''continuous'', i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page ('''[https://service.wiki.d4science-ii.research-infrastructures.eu/service/index.php/ICIS_Scenario_Analysis ICIS Scenario Analysis]'''). | |
| − | + | ||
| − | + | The planned actions are recorded through TRAC tickets and organized into a '''living report''' ('''[https://issue.d4science-ii.research-infrastructures.eu/report/34 Report #34]''') that provide its users with an ever updated account on the '''scenario specific technology development activities''', including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date. | |
| + | |||
| + | Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, '''current defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/39 Report #39]) and '''resolved defects''' ([https://issue.d4science-ii.research-infrastructures.eu/report/40 Report #40]). | ||
| + | |||
| + | In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, '''current incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/1 '''Report #1''']) and '''resolved incidents''' ([https://support.d4science-ii.research-infrastructures.eu/report/2 '''Report #2'''] and [https://issue.d4science-ii.research-infrastructures.eu/report/11 '''Report #11''']). | ||
Latest revision as of 20:01, 6 July 2016
The content of this report captures the development status of all software components that are direct or indirect consequence of the work performed by the Joint Research Activity 2 (JRA2) work package of the D4ScienceII project.
The objective of this work package is to cover the design and implementation case-specific needs for each particular interoperable infrastructure. Each case is analyzed and the system to implement it, on the side of the interoperating infrastructure, is designed in detail. Following the initial design, each case implements the specific components required so that it can exploit the facilities offered by the evolving ecosystem core and it can export the identified interoperable features to the rest of the ecosystem cases.
The cases involved in these scenarios are the ones defined by the high level needs and requirements exposed by the one of the following infrastructures and have been specified through the NA4 and NA5 processes. The interoperability cases through this process evolved to specific implementation requirements whose definition and status of implementation is reported here. The implementation is performed in the context of the following tasks:
- INSPIRE specific implementation
- DRIVER specific implementation
- AquaMaps specific implementation
- FCPPS specific implementation
- ICIS specific implementation
The progress is reported both in the context of each individual task as well as in the direction of ecosystem interoperability. The report groups related functionalities (from an implementation point of view), with respect to their impact on components that are involved. Thus, the status of development is presented by functional group. This status can be the result of the combined statuses of the various elements involved in a particular functional scope. Furthermore, as a single component might expose more than a single functional facet, it might be implicitly or explicitly involved in several functional groups.
As a result of one or more requirements, development can aim for:
- An entirely new software suite (Service including libraries and user interface elements if applicable) for extending gCube to cover new domains.
- A minor new component (of any of the aforementioned types) that plugs into the infrastructure (or to a particular existing component) in well defined areas, adding to its behavior.
- Modification/extension of existing components, for provision of new functionality or modification/improvement of the existing one.
Requirements characterizing each case are documented in the dedicated wiki pages of NA5. The guidelines governing the activities performed in this context can be found at the respective guidelines page. The study of the documentation and requirements produced through these pages are the subject of analysis of dedicated system analysts producing a complete report documented under the SA2 wiki. This product is the basis upon which TRAC tickets are created to further link and monitor development activities.
Status
INSPIRE
The requirements characterizing the INSPIRE scenario are documented in a dedicated wiki page (INSPIRE Scenario) as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge.
The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the actions needed to satisfy them. This activity is continuous, i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page (INSPIRE Scenario Analysis).
The planned actions are recorded through TRAC tickets and organized into a living report (Report #30) that provide its users with an ever updated account on the scenario specific technology development activities, including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date.
Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, current defects (Report #39) and resolved defects (Report #40).
In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, current incidents (Report #1) and resolved incidents (Report #2 and Report #11).
DRIVER
The requirements characterizing the DRIVER scenario are documented in a dedicated wiki page (DRIVER Scenario) as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge.
The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the actions needed to satisfy them. This activity is continuous, i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page (DRIVER Scenario Analysis).
The planned actions are recorded through TRAC tickets and organized into a living report (Report #31) that provide its users with an ever updated account on the scenario specific technology development activities, including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date.
Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, current defects (Report #39) and resolved defects (Report #40).
In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, current incidents (Report #1) and resolved incidents (Report #2 and Report #11).
AquaMaps
The requirements characterizing the AquaMaps scenario are documented in a dedicated wiki page (AquaMaps Scenario) as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge.
The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the actions needed to satisfy them. This activity is continuous, i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page (AquaMaps Scenario Analysis).
The planned actions are recorded through TRAC tickets and organized into a living report (Report #32) that provide its users with an ever updated account on the scenario specific technology development activities, including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date.
Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, current defects (Report #39) and resolved defects (Report #40).
In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, current incidents (Report #1) and resolved incidents (Report #2 and Report #11).
FCPPS
The requirements characterizing the FCPPS scenario are documented in a dedicated wiki page (FCPPS Scenario) as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge.
The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the actions needed to satisfy them. This activity is continuous, i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page (FCPPS Scenario Analysis).
The planned actions are recorded through TRAC tickets and organized into a living report (Report #33) that provide its users with an ever updated account on the scenario specific technology development activities, including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date.
Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, current defects (Report #39) and resolved defects (Report #40).
In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, current incidents (Report #1) and resolved incidents (Report #2 and Report #11).
ICIS
The requirements characterizing the ICIS scenario are documented in a dedicated wiki page (ICIS Scenario) as part of the project deliverable DNA5.1 Communities Practices and Requirements. The production of these requirements is led by scenario representatives. The set of requirements is expected to evolve during the project lifetime. During the project lifetime, requirements can be revised and reinforced after evaluation of implementation of the requested facilities. In addition, new requirements may emerge.
The so produced requirements are analyzed by a multidisciplinary team involving NA, SA and JRA representatives with the goal (i) to reach a common understanding of the community desiderata and (ii) to identify the actions needed to satisfy them. This activity is continuous, i.e. the team will discuss the existing requirements, agree on approaches and solutions to satisfy the faced issues and plan the activities (namely technology development and deployment) to resolve them. This activity is documented in a dedicated wiki page (ICIS Scenario Analysis).
The planned actions are recorded through TRAC tickets and organized into a living report (Report #34) that provide its users with an ever updated account on the scenario specific technology development activities, including their state (e.g. if the activity is complete, the percentage of completion), a detailed description of the specific activity, the planned and actual completion date.
Other development activities results from defects discovered after the release of the artifacts (e.g. known bugs). These are captured by two specific live reports, current defects (Report #39) and resolved defects (Report #40).
In addition to the development activities captured by the reports above, other stems from incidents and malfunctions discovered while exploiting the technology in the production infrastructure. They are captured by two specific living reports, current incidents (Report #1) and resolved incidents (Report #2 and Report #11).
