Difference between revisions of "Risk Analysis and Risk Response"

Revision as of 09:10, 2 September 2013 (view source) Panagiotis.liakos (Talk | contribs) (→‎Service Activities) ← Older edit		Revision as of 09:11, 2 September 2013 (view source) Panagiotis.liakos (Talk | contribs) (→‎Service Activities) Newer edit →
Line 518:		Line 518:
	| align="center" | [https://issue.imarine.research-infrastructures.eu/ticket/2072 #2072]		| align="center" | [https://issue.imarine.research-infrastructures.eu/ticket/2072 #2072]
	| -Provide a stable development infrastructure that reflects the production one		| -Provide a stable development infrastructure that reflects the production one
−	-Perform more tests on the components before being released	+	|-Perform more tests on the components before being released
	|-Several improvements have been agreed and put in place in the second reporting period. Among the other, the deployment of a new dedicated development infrastructure to deploy and test the latest component composing the security framework released in gCube, the so called SOA3.<br>-Several nodes have been replaced in the default development infrastructure to improve the overall availability of the computational and service resources.		|-Several improvements have been agreed and put in place in the second reporting period. Among the other, the deployment of a new dedicated development infrastructure to deploy and test the latest component composing the security framework released in gCube, the so called SOA3.<br>-Several nodes have been replaced in the default development infrastructure to improve the overall availability of the computational and service resources.
	|-		|-

---

Revision as of 09:11, 2 September 2013

Contents 1 Introduction 2 Risk Management Methodology 2.1 Overview 2.1.1 Risk Evaluation 2.2 Risk Identification 2.3 Risk Classification 2.4 Risk Monitoring 2.5 Risk Resolution 3 Identified Risks 3.1 Networking Activities 3.2 Service Activities 3.3 Research and Technological Development 4 Top Identified Risks 4.1 Risk Resolution

Introduction

The goal of the risk analysis and risk response activity is to provide the consortium with guidelines and instruments for managing the actual and potential risks that can occur during the project's lifetime. The full risk management procedure and methodology is available at D1.1.

The contingency planning will be part of the D2.4 deliverable and as of type "Other" this page will be used to serve the main content of the deliverable.

Risk Management Methodology

Overview

A risk management methodology is a set of methods and procedures used to identify both the risks the project is subject to as well as the actions to take in order to identify their happening and consequently react to minimize their effect.
The methodology consists of several steps; These are the risk identification, classification, monitoring and resolution.

• Risk identification: It identifies the risks that the different parts of the project (i.e. its assets like the developed or deployed system) are exposed to and evaluates each risk by attaching qualitative and quantitative attributes to the risk, leading to subsequent quantification of the impact that the risk will have, the probability of occurrence, and the value of the assets

• Risk classification: It identifies the most important risks and promotes in subsequent steps the actions to be taken to safeguard the assets. The prioritization of risks attempts to handle first the risks with greatest impact on the project outcomes and greatest probability of occurrence, and last the risks with lowest impact on the project outcomes and lowest probability of occurrence.

• Risk monitoring: It identifies the procedures to monitor the risks according to the priorities identified in the risk classification phase.

• Risk resolution: It identifies the strategies to reduce the probability of occurrence of a risk or the countermeasure needed to limit its effects.

Risk Evaluation

The evaluation of a risk is performed by identifying the probability of occurrence and the impact for each risk. The probability for a particular source/problem to occur is not a strictly mathematical probability factor. For the majority of the risks there are no formulas or there is not enough experimental data to calculate the probability of occurrence. Thus it is not easily quantifiable. The impact measures the damage that will be caused to the object element in case of occurrence of the risk.
This case of difficult evaluation of the basic metrics of risk evaluation is actually typical in IT projects where probabilities are estimated by indirect methods such as “expert” opinions, offers, negotiations etc. In the iMarine case, this activity relies on “expert” opinions that evaluate the risks. Moreover, the terms “probability rank” and “impact rank”, which are more appropriate for the iMarine case, have been adopted. Probability rank liberates the analysis from the strict mathematical terms, which in any case is not objectively useful in this

context, while Impact rank adds a degree of freedom and uses indirect reference to absolute costs of risk appearance. The following table presents the convention defined for risk evaluation.

Probability Rank		Impact Rank
Description	Value	Description	Value
None	0	None	0
Very Low	1	Doesn’t affect the activity	1
Low	2	Affects the activity but a workaround is not needed	2
Medium	3	Affects the activity and it's recommended to put in place a workaround	3
High	4	Affects the activity and it's mandatory to put in place a workaround	4
Very High	5	Affects the activity that has to be completely rethought	5
Certain	10	Blocks the activity	10

Risk Identification

The first part of the risk analysis phase is about identifying and labeling the risks the project is exposed to. The identification of a risk is based on the usage of the terms source/problem and is further explained by the terms object/impact

• The source/problem can be anything external or internal to the project that behaves outside the margins it is expected to behave. Typically these margins should be settled by the specifications, however these are not those that are of interest to our risk management, but rather the margins on which the plan of the project has been settled on. Multiple sources logically combined can form one risk
• The object/impact is always internal to the project. Object can be any element that is affected by a source/problem while the impact is the problem raised in the object, expressed in qualitative and/or quantitative manner.
  

Because of their knowledge of the domain, work package leaders and project managers, in cooperation with tasks leaders when required, are the best candidates to identify possible risks affecting the activity of the project. Work package leaders identify low-level risks and their impact, while project managers identify high-level risks that are not directly conceivable at lower layers.

In order to identify risks they should:

• Evaluate the applicability of common risks proposed by various methodologies. Subsequently perform a fine-grained extension of the common risks to the elements of the project that comply with the risk definition
• Analyse the methodology commonly used by the target communities and evaluate the distance between their approaches and the ones proposed by the project
• Enumerate all the dependencies of software components and work plans at the task level and enhance this information with the effects caused by the event of failure, delay, misbehaviour (lack of features, performance, etc.)

After the identification of the risks, a number of additional steps have to be performed:

• Identification and removal of duplicated risks
• Homogenisation of the terminology
• Sorting of risks according to the source/problem. Multiple effect source/problem can be grouped in one element with multiple objects/impacts
  • The identified risks are grouped into 3 different categories:

1. Networking Activities Risks
2. Service Activities Risks
3. Research and Technological Development Activities Risks

• As an initial indicator, the likelihood of appearance of the risk can also be attached.

The risk identification is a continuous task. When work package leaders or project managers decide to declare a new risk this should be done either immediately or during the next monthly activity report. If no risks are identified this should be communicated to the QATF when the Quarterly Report is produced.

• The declaration of new risks is carried out by creating a new ticket with type “risk” using the TRAC web interface available at:

https://issue.imarine.research-infrastructures.eu/newticket

Risk Classification

Risk classification is the main task of the risk analysis phase. Having:

1. the value of the asset associated to the risk
2. the indicator of the probability of the risk being triggered
3. the impact this will have on the particular asset

it is possible to estimate the importance of the risk.

The measurement of risks is typically called risk exposure. Since, the risk exposure is mathematically calculated as the product of probability by impact, it will not be used.

Instead the “risk exposure ranking” will be measured to classify risks:
Risk Exposure Ranking = Value of Asset X Probability Ranking X Impact Ranking

The value of the asset can be defined as follows:

• All assets that do not depend on other assets
  • Value of asset = 1;
• All assets that depend on other assets
  • Value of asset = C-Value
  • C-Value = K * Value of lower level asset (K <= 1; e.g. K = 0.9 and so on to reduce the value of the assets that depend on a chain of assets)

Two approaches are recommended to sort the classified risks:

• Sort the risks by Probability Rank. This allows focusing on the risks most likely to happen and then investigate the chains they are taking place.
• Sort the risks by Risk Exposure Rank. This captures most serious problems that can affect the asset and then investigate the related events.

Some of the identified risks could belong to different categories, having different probability and impact values on each category. For those risks we keep the maximum exposure rank.

Risk Monitoring

The most effective way of monitoring risks is the continuous update of the top-ranked risks as defined in the risk plan. Among the top-ranked risks it is important to implement the actions of the risks that entered the list since the last evaluation. It is also required to update the status on all other risks. For this purpose, for each risk the following information is also maintained:

• Current position in the top-n ranking
• Previous position in the top-n ranking
• Risk description
• Progress towards resolution

The risk monitoring is a continuous task. However it is mandatory to follow the risk plan status every time the QAFT re-sorts the existing risks to understand which risks are now top-ranked and require therefore close monitoring. If a risk increases its exposure rank, the projects managers should introduce more accurate countermeasures and inform the PMB to allow a high-level discussion. Similarly but with the reverse impact, risks that gradually diminish, have their countermeasures relaxed.

The following report can be used to update the list with the identified risks: Project Risks Tickets

Risk Resolution

For the resolution of risks, a number of methods can be applied:

• Avoid the occurrence of the risk by reducing the probability of its triggering events
• Avoid the risk by removing its connection with project activities
• Transfer the danger to another party or asset to reduce the probability of occurrence
• Acceptance of the risk and implementation of its countermeasure
• Acceptance of the risk with late reaction
• Exploitation of risk side effects to balance their impact

Identified Risks

The following tables contain all the identified risks. These risks are either identified by the QATF, or by the Work and Task Package leaders. They may have been reported using the TRAC system, the monthly activity report or can be directly reported through this page.

When adding a new risk the following information should be provided:

• Risk: The name of the risk
• Description: A brief description of the risk
• Risk Probability: The probability of the risk using one of the values described at the Risk Evaluation section
• Risk Impact: The impact of the risk using one of the values described at the Risk Evaluation section
• Work Package: The Work Package(s) that the risk belongs to
• Related Ticket: The Track ticket number pointing to the identified risk
• Countermeasures: The possible countermeasures to be taken if the risk occurs
• Applied Countermeasures: A brief description of the applied countermeasures and/or the related ticket numbers

Networking Activities

engagement of the community. It was the result of the implementation of the plan and the availability of the technology that proved to attract more and more interest in the second reporting period. See: http://www.i-marine.eu/Content/eTraining.aspx?id=966eac93-d64e-47a4-ab63-d160dae21976&category=0_7000000_7070000

Risk	Description	Risk Probability	Risk Impact	Risk Exposure Ranking	Work Package	Related Ticket	Countermeasures	Applied Countermeasures
High staff turnover	Given the complexity of the iMarine environment, skilled staff may leave the project for longer-term and higher paying positions within industry The virtual nature of the organisation may increase the probability of this risk	2	3	6	All	-	-Project management should verify training plans for the younger researchers/developers to ensure that they continuously evolve within the project. -Plan two or three occasions per year where all project staff can get together. -Consider staff satisfaction review across the project
Lack of organisational coherence	Could be caused by one or more specific underlying reasons ranging from communication difficulties at one or another of the member organisations	2	3	6	All	-	- Minimise the risk occuring by implementing a project structure in which the key main stakeholders are identified at this point in time -Ensure the consensual values within the project, the effective use of communications technology and the frequent planning control and review.
Serious disputes between consortium members		2	3	6	All	-	-Aim to minimise the chances of disputes occuring by ensuring regular and clear communication between consortium members -Work package leaders should aim to follow an attitude of openess and trust, wehrever possible -Where pre-dispute areas are suspected, offline discussions should be initiated -Where disputes become unavoidable, conflict resolutions procedures will be invoked -Ensure the consensual values within the project, the effective use of communications technology and the frequent planning control and review.
EA-CoPCommunity of Practice. technologies becomes obsolete	The CoPCommunity of Practice. employs a wide variety of technologies, often released many years ago. They may need to change them to become a viable partner.	4	2	8	All	-	-The gCube services do not depend on these external facilities. If software needs upgrade, this is beyond the project scope. However, the data infrastructure may offer solutions.
EA-CoPCommunity of Practice. Software is not released on time	This risk is very common in any project with a collaborative plan of development activities. Late delivery only affects EA-CoPCommunity of Practice. activities.	3	3	9	All	-	-The Agile development approach provides opportunities to assess the direction of the ongoing activities, and mitigate the impact -Appropriate boards within the project will continuously monitor this risk and take corrective actions
Multi-disciplinary nature of the consortium may lead to disciplines working in silos	Lack of communication, limited understanding of the needs and difficulties in testing/feedback	2	3	6	All	-	-Work package leaders must ensure reglar presence at the quarterly face-to-face meetings of the PEB in order to prevent "silo" work packages -Regular communication thourgh virtual means will prevent isolation
Lack of motivation and/or participation in the Virtual and the Project Events	Recruiting both appropriate speakers and participants to attend this event involve skilled staff with experience in developing marketing and promotional strategies as well as a vast network database of competent names which focus on benefits of the individual attending.	2	2	4	WP4	#2077	-The iMarine partners boast high-level networks specific contacts which will be contacted according to the specific event organised. The partners have proved over the last 2 years are able to obtain active participation from key experts in the field. The involvement of the existing CoPCommunity of Practice. community and its related contact network will also help mitigate this risk. The iMarine board contacts contribute to the mitigation of this risk. -Social networks like LinkedIN and Twitter will be also exploited to raise the appropriate interest on the initiative.
Project software is not delivered on time or misses specifications	WP3 translates the EA-CoPCommunity of Practice. in development goals that cannot be achieved by RTD for any reason	3	3	9	All	-	-Representatives of RTD will be included in the NA3 work package by assuring the feasibility of the goals according to RTD requirements and effort.
Difficulty increasing users’ participation to engage in iMarine training activities	To accelerate the adoption of the e-infrastructure governance model, to create awareness of the services provided, etc., users‟ participation must increase.	3	3	9	All	-	-The introduction of virtual tools is a proven mechanism for engaging and involving users in training activities reducing costs and the learning-implementation process as users may have their individual timeframe to complete courses
Users' unwillingness to use the available software	End users may not use the available software and the available web applications	3	3	9	All	-	-Develop mobile applications for easier access and adoptation through smart phones and tablets
Expected co-funding / collaboration is not achieved	The projects supporting external applications development are delayed or cancelled, and the in-kind inputs from partners are not delivered as promised. The risk is medium since the core parts of the use cases are designed to be tackled with project funds or external funding sources already approved.	3	2	6	All	-	-The iMarine Board will mostly have to face priority settings, so efforts will be reported on areas where resources are guaranteed -The Steering Board should make decisions in the best interest of the EA-CoPCommunity of Practice. -The iMarine Board are made up of decision-makers who can certainly influence co-funding opportunities
EA-CoPCommunity of Practice. Policy expectations are too diverse for being consistently developed for iMarine	Too many expectations are formulated, the opinions of different members are too strongly diverging on the solutions. The risk is real but has been minimized by attempting to being together actors of the EA-CoPCommunity of Practice. which share common interests and standards	3	4	12	All	-	-The iMarine Board will create clusters of common interest in order to facilitate negotiation; it will also have flexible strategies for the development of policies, bottom-up or top down or a mixture of both depending on the complexity. It will be aware that progress on policies will be uneven depending on the topics
Management of Semantic Clusters activities	It seems that some key partners of the semantic cluster have not adopted the ticket-based management style. Furthermore, sometimes their responses are very slow (weeks). Poor management of semantic cluster requirements which does not aid scheduling the required technical activities	3	4	12	WP3	#1042	-The wiki page of the semantic cluster achievements/plans (http://wiki.i-marine.eu/index.php/Semantic_cluster_achievements) should be improved and related to specific tickets
Lack of visibility through media channels and external events	Lack of visibility through media channels and external events regarding project's achievements and offered functionality	4	4	16	WP4	#2076	-Consortium members have established close links with key media channels and are active not only at national level but also internationally. Event attendance will be strategically identified and actively promoted through partner networks and synergies.	-It was decided to promote the iMarine visibility through a dedicated mobile application. It was named AppliFish and its success - proved by more than 4000 downloads in few weeks - globally distributed around the world strongly helped in increasing the iMarine visibility and the interest around the iMarine initiative.
Lack of community involvement	Engaging the stakeholders to use the e-infrastructure is a very important outcome and key to its strategic objective for sustainability	3	4	12	WP4	#2078	-iMarine has produced a User Engagement Plan that draws on its extensive partner networks and synergies targeting audiences from policy and the marine research domain. -The initiative will leverage improved messaging and continue to use multiple communication channels in its outreach, including social networks (e.g. 400+ LinkedIn? connections), events target key audiences, press and media activities. -The effectiveness of the plan will be monitored through dedicated WP4 monthly calls.
Lack of understanding of the iMarine offering and services	Lack of understanding of the iMarine offering and services given the wide spectrum of services and tools potentially offered by the e-infrastructure.	1	2	2	WP4	#2084	-iMarine has planned periodic communication messaging revision. The revised messaging is based on a more user-centric approach that focuses on enabling better marine knowledge supporting better informed policy making and necessary to advance marine research. This renewed focus is supported by the guidance of the Steering Board and coordinated through WP4, for example, reviewing and updating key information on iMarine and promoting its training programme, Further, WP4 expertise in marketing and communication is exploited to convey the right message to the right target users.
Difficulty increasing users’ participation to engage in iMarine training activities	To accelerate the adoption of the e-infrastructure governance model, to create awareness of the services provided, etc., users’ participation must increase.	3	3	9	WP4	#2073	-One of the aims of WP4 is to disseminate the enabling capabilities of iMarine and facilitate uptake in real-world settings. iMarine is using a structured approach to its online training: target audiences, learning outcomes and previous experience required and combines this with multimedia content that is easy to follow and remember.	-Training for interesting users is available on the project's website (eTRaining)
Lack of scientific publications	Lack of scientific publications	2	3	6		#2086		-The production of scientific publications is largely increased in the second reporting period. As expected, after the first reporting period - mainly dedicated to the analysis of the requirements and definition of new pattern to solve them -The second period was reach of scientific publications as reported at [1]

Service Activities

Risk	Description	Risk Probability	Risk Impact	Risk Exposure Ranking	Work Package	Related Ticket	Countermeasures	Applied Countermeasures
Unavailability of dedicated computing and storage resources	The computing and storage resources provided by the project partners represented in WP5 are not made available	1	3	3	5	-	The required amount of resources can be acquired from external cloud providers like MS Azure, thanks to gCube cloud extension and the collaboration with Microsoft which will give us enough computing and storage capacity if needed.
Unavailability of on-demand computing and storage resources	The computing and storage resources provided on-demand as cloud resources in WP5 are not made available. Alternatively, the gCube extension to access clouds resources is not operational	3	3	9	5	-	The required amount of resources will be discussed with the project partners to understand their availability to provide more dedicated nodes
Impossible to access resources from other infrastructures	The resources provided by other (data) infrastructures (from the D4ScienceAn e-Infrastructure operated by the D4Science.org initiative. Infrastructure and others) are not reachable and cannot be consumed from the iMarine 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.	3	3	9	5	-	The Service Activity teams of both infrastructures establish direct communication to analyse the problem. If required, the defined interoperability solutions are updated and the development teams involved
Useless procedures	The identified procedures to manage 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., the VREs, and the software release are useless and introduce delays	2	3	6	5-6-7	-	-The reasons for the misalignment between procedures and daily practices are analysed and improvements to the current procedures proposed and tested -The advisement from external experts may be established
Unclear or unstable requirements	The requirements and concrete use cases identified by the EA-CoPCommunity of Practice. are not clear or unstable and do not allow the definition of appropriate Virtual Research EnvironmentA ''system'' with the following distinguishing features: ''(i)'' it is a Web-based working environment; ''(ii)'' it is tailored to serve the needs of a Community of Practice; ''(iii)'' it is expected to provide a community of practice with the whole array of commodities needed to accomplish the community’s goal(s); ''(iv)'' it is open and flexible with respect to the overall service offering and lifetime; and ''(v)'' it promotes fine-grained controlled sharing of both intermediate and final research results by guaranteeing ownership, provenance, and attribution.	3	4	12	6	-	More regular and face-to-face meetings between the EA-CoPCommunity of Practice. members and the technical teams are established to promote a clear communication between the two teams and a detailed discussion of the requirements
Low quality of the delivered community tools and gCube common tools	The applications and tools developed by the user communities and/or the gCube common tools are not deployable or are of low quality	3	3	9	6	-	The effort on the development support task (T6.4) is intensified to allow a better communication and support to the developers of these applications and tools
Unavailability of data resources	The data resources planned for the different use cases are not delivered and made available by the user communities	3	4	12	6	-	Direct contact with the user communities and increased support is put in place to understand the reasons for the unavailability of the data resources. The policies for data provision may be revised
Limited or unavailable VREVirtual Research Environment. functionality	The identified VREVirtual Research Environment. functionality is not provided or do not satisfied the initial requirements	2	4	8	6	-	Define very clearly the planned VREVirtual Research Environment. functionality. Push developers to deliver early prototypes and users to provide early feedback
Unavailability of build and testing tools	The tools defined to integrate and test the project source code are not made available	10	10	100	7	#1040	-Other instances of the same tools are exploited (e.g. an ETICS instance is hosted at CERN and run by EMI project, however Engineering (E-IIS) will also install an instance in its premises) -The usage of other tools is considered	The ETICS infrastructure hosted at CERN is planned to be shutdown at the end of April 2013. Therefore members of WP7 have planned to upgrade the ETICS instance at Engineering and perform the migration of the integration activity on that instance during the Q1 2013. The start of the migration activity is planned for January 2013 and will give enough time to complete it on time.
Possible security issues on the production infrastructure.	End of Public updates of the the Java SE version 6	10	4	40	5-7	#1041	The public updates for JAVA SE v 6 , which is the base of our infrastructure nodes, will stop on February 2013. The exploitation of JAVA SE 7 should be planned ASAP in order to avoid possible issues in the production environment.	The WP5 and WP7 teams have discussed the issue and decided to start from Jan 2013 to integrate the gCube software using JAVA SE 7, in order to understand possible incompatibility issues . The WP5 members have also planned during Q1 2013 the migration to JAVA 7 of all the infrastructure nodes.
The gCube Container is becoming obsolete	The gCube Services are hosted on a customized version of the Globus ws-core container that is no longer supported by the developers. The container implements a flat class loader and it's shipped with a long list of components quite outdated. Upgrading to a new version of JAVA will break some of the components that are shipped with the container. Moreover the development of new services will introduce component versions clashing with the ones shipped with the container and we are also limited from the performance point of view	2	4	8	All	#2070	Remove the dependency to gCore framework and rely on standard active technologies	To remove the dependency to gCore a new framework has been designed and it is currently under testing. The framework is called SmartGears and it is currently tested in the implementation of the new TabularData service. SmartGears provides the same gCore capabilities but the remote deployment that will be added later with a dedicated per-container extensions.
The gCube software is not distributed in a standard bundle	The gCube software is packaged and distributed in a custom way that is not following the standard packaging available in the *nix systems (rpm, deb etc). The software bundles that are delivered by WP7 are installed trough the gCube Enabling layer using dynamic deployment. This impacts mainly two aspects: The iMarine infrastructures upgrades are not performed following a simple and straightforward procedure because the gCube Enabling layer do not implement software upgrades The installation of iMarine software by not members of the project is discouraged because of the complexity of the installation process.	4	4	16	WP7	#2075	Use a standard packaging for the gCube system
Diversity of development and production infrastructure	Development infrastructure does not reflect the production one, leading to inadequate testing of the released components	4	4	16	All	#2072	-Provide a stable development infrastructure that reflects the production one
Long transition periods among adopted technologies	Adopting a new technology for core components without specifying clear directives leads to unnecessary effort	2	3	6	All	#2080	Make more specific work plans
Provide a new domain model representation for a given service	With the new Featherweight stack new naming conventions were adopted in order to represent Information System resources. The naming of concepts adopted in the java library representation differs from the one used in the Resouce Model XSD. This could lead to user unwillingness to use new facilities or inability to understand the new naming.	3	3	9	WP8	#2071	Provide detailed documentation about changes in the wiki so that developers are informed about changes on the usage of API for accessing a service.	Provided documentation on the wiki Related ticket: #847
Poor requirements analysis	Requirements listed on TRAC often miss a context description or detailed information about the missing functionality, required enhancements. Managing requirements through TRAC can also be a time consuming for requirements analyst because the tool is not aimed at handling the problem of requirement analysis.	3	2	6	WP8-9	#2074	Provide better means for requirements to be disseminated from stakeholders to requirements analysts. The tool should also provide extensive support for classification of requirements, metadata and dissemination.	During the second period, the proposal of new requirements was changed. The stakeholders, organized through the 4 project clusters in WP3, convey on a common list of requirements. Those are then discussed in dedicated and thematic conference call where priorities assigned. Then requirement analyst meet and define the plan for implementation that it is documented through tickets in TRAC. It remains unchanged the exploitation of tickets for the enhancements. This mainly means that the requirements to improve a delivered functionality are still managed through tickets, while the requirements for new functionality are managed with a more direct interaction with the stakeholders.
Usage of different Dependency Injection frameworks	When a system that is composed by multiple subsystems is developed by several developers, if there is no common contract on which technologies to use for DI each developer is left to choose the technology that best suit his needs or competence. This can bring to having system with multiple DI containers.	2	1	2	All WPs	#2083	An agreement on which DI framework should be used by developers can be followed.	The gCube SmartGears - currently under testing and initial exploitation by the Tabular Data Manager service - is the new framework that will progressively replace gCore. It allows to exploit any available dependency injection technology. Thus, different gCube-aware application will be able to exploit different dependency injection technologies without any problem. The old components developed with gCore instead have to follow the provided recommendation for the dependency injection technology.
Software Maintenance issues	Poorly produced software can bring to high coupling and low cohesion. These two factors can bring to difficult software maintenance and can also bring to the dismissal of entire systems.	3	4	12	All WPs	#2082	Knowledge dissemination
Naming conventions for project identification	Projects developed for the gCube system must be identified on several systems (svn, issue tracker, continuous integration system, maven repository, gcube information system). A clear guideline on how to provide an identifier for those systems for a given project is missing, therefore developers can use different naming conventions.	5	4	20	All WPs	#2085	Guidelines on the identification and naming of components must be put in place and documented on the wiki. The continuous integration system can optionally provide means to check compliance to those guidelines.

Research and Technological Development

Risk	Description	Risk Probability	Risk Impact	Risk Exposure Ranking	Work Package	Related Ticket	Countermeasures	Applied Countermeasures
Foundation Technology becomes obsolete	The gCube system is build on technologies released a few years ago. It may be needed to change them to maintain a state-of-the-art status of gCube	5	3	15	All RTD	-	gCube services do not deal directly with these underlying facilities. gCore framework was impemented to isolate the services from the underlying layers. This layer can be evolved to minimise the impact of the risk over the services	A middle-ware library (named micro-lib) is being developed to offer flexibility in using other containers when gcore becomes obsolete.
Software is not released on time	This risk is very common in any project with a consistent plan of development activities. Instances of the risk highly affect all the other work packages' activity	3	4	12	All RTD	-	-The Agile development approach adopted in RTD will provide many opportunities to assess the direction of the project through incremental and iterative work cadences and short integration cycle -Appropriate boards within the project will continuously monitor clues of this risk and take corrective actions
Community of Practices cannot be implemented	WP3 translates the CoPCommunity of Practice. in development goals that cannot be achieved by RTD for any reason	2	3	6		-	Representatives of RTD will be included in the WP3 work package by assuring the feasibility of the goals according to RTD requirements and effort
gCube Search does not cover the requirements of xSearch for search across independent data sources (such as independent CoPCommunity of Practice. search services)	The use of xSearch in gCube for the respective users will be compromised	4	4	16	10	#1047	-Be ready to demonstrate Xsearch independently of gCube Search -XSearch will be able to demonstrate its functionality over search results stemming from internal iMarine data sources, assuming that these results are properly ranked -Recommend and encourage the responsible partners of gCube search to focus on the fusion of external search systems and to plan testing activities over some existing CoPCommunity of Practice. search systems (e.g. FIGIS, Ecoscope). The related CoPCommunity of Practice. partners should be also involved and share the responsibility for this.
CoPCommunity of Practice. partners and gCube Search/XSearch	During our discussions about XSearch (the 1st year) we have realized that some CoPCommunity of Practice. partners seem to be reluctant in adopting tightly integrated to gCube solutions. Sometimes it seems that they prefer libraries, APIs, web apps, services, etc.	3	3	9	6-10	#1046	-Should decide now what will be demonstrated at the second review (related to: #1042) -To promote the opinion that it is beneficial for gCube to offer value-added services on top of existing external systems (e.g. external search systems) (related ticket: #1047)
Services scale out	In a vast collaborative environment, scalability is one of the key issues that must be preserved. Actions must be taken in order to continuously investigate for possible bottlenecks that may violate this commitment.	3	3	9	All RTD		Services should always be redesigned, if needed, with scalability, bottleneck reduction, preservation of all useful features and new additions and improvements in mind. This will enable services to fully exploit the available computational resources in the infrastructure and achieve significant gains in scalability.
Adoption unwillingness for developed software	In such a dynamically changing development environment, it is difficult to always adapt to latest developed software, whereas desire for stability or denial of transition may also arise. This could probably lead to reduced collaboration.	2	4	8	All RTD		- Provide common use case - Comply with partner needs	- Simplified interfaces (Client Libraries) - Adoption of standards / Simplified APIs - Due to the high probability of this risk a new component, named "FeatherWeight stack" has been introduced to mitigate this risk. Related ticket is: #853 - etc.
Adoption of new technologies	Occasionally, before used technologies becoming too obsolete, there is a need for replacement with more latest ones. The technological transition sometimes may be risky if the new technology is not completely suitable and compatible or if the integration process with gCube lasts longer than initially planned.	3	4	12	All RTD		Whenever a decision choice for a new technology adoption has to be taken due to the restrictions of the current technologies, the selection out of the set of candidate technologies has be made very carefully in order to maintain every current feature while no time will be wasted in integration drawbacks that may emerge.	- Before adopting a new technology, the alternative solutions are examined and the most appropriate and easy to adopt is being selected. Related ticket for the new index service is 896
Obsolete technologies	Some gCube services are build over technologies released a few years ago. It may be needed to change them to maintain a state-of-the-art status of these services.	3	4	12	All RTD		The gCube Services that became obsolete need to either upgrade the underlying technology or replace it with a more suitable.	Due to the probability of having performance issues when the load will be increased, indexing mechanism is in progress of replacement of the underlying mechanism and adapt to new solutions. Related ticket is: 882
Dismissal of components with many dependants	Dismissal of components with many dependants may lead to delays of the upcoming releases and may introduce new bugs in existing components	2	3	6	All RTD	#2079	Evaluate such decisions and their impact to other components
Dismiss unused and obsolete components as soon as possible	Components that are not being used should be dismissed, in order to avoid the maintenance procedures	1	2	2	All RTD	#2081	-A component that is not used in any VREVirtual Research Environment. should be removed. -A component that is no longer needed (e.g. its facilities have been replaced by another component), then it should be dismissed.

Top Identified Risks

This section will contain the top 10 of the identified risks based on their Risk Exposure Ranking.

• Last update: 08/30/2013

#	Risk	Risk Probability	Risk Impact	Risk Exposure Ranking	Previous position in the top list	Category
1	Naming conventions for project identification	5	4	20	4	SA
2	The gCube software is not distributed in a standard bundle	4	4	16	6	SA
3	Lack of visibility through media channels and external events	3	4	12	7	NA
4	Software Maintenance issues	3	4	12	10	SA
5	Provide a new domain model representation for a given services	3	3	9	13	RTD
6	Diversity of development and production infrastructures	3	3	9	8	SA
7	End of JAVA SE 6 public updates	2	4	8	2	SA
8	The gCube Container is becoming obsolete	2	4	8	5	RTD
9	Lack of community involvement	2	4	8	11	NA
10	Difficulty increasing users’ participation to engage in iMarine training activities	2	3	6	14	NA
11	Poor requirements analysis	3	2	6	3	RTD
12	Dismissal of components with many dependants	2	3	6	18	SA
13	Management of Semantic Clusters activities	2	2	4	12	RTD
14	CoPCommunity of Practice. partners and gCube Search/XSearch	2	2	4	15	RTD
15	gCube Search does not cover the requirements of xSearch	2	2	4	9	RTD
16	Lack of motivation and/or participation in Project Events	2	2	4	20	NA
17	Long transition periods among adopted technologies	1	3	3	19	RTD
18	Dismiss unused and obsolete components as soon as possible	1	2	2	21	SA
19	Usage of different Dependency Injection frameworks	2	1	2	16	RTD
20	Lack of understanding of the iMarine offering and services	1	2	2	17	NA
21	Lack of scientific publications	1	2	2	22	NA
22	CERN ETICS infrastructure dismissal	1	1	1	1	SA

NOTE: In the category section the allowed values are:

• Networking Activities -> NA
• Service Activities -> SA
• Research and Technological Development -> RTD

Risk Resolution

In this section the corrective actions put in place when a certain risk occurred during the project lifetime. Resolution actions are specific for each risk and thus a per-risk description is provided. It is important to notice that these corrective actions have a cost and that the diverse corrective actions/procedures with different costs can be put in place to attack the same risk. The one reported below has been identified by carefully evaluating various aspects including the impact of the risk, the cost of the actions and the characteristics of the context, i.e. the iMarine project. Moreover, these procedures can partially resolve/mitigate the risk or generate another risk.

The section will be updated periodically based on the above list and the risks' occurrences

• Foundation Technology becomes obsolete

A middle-ware library (named micro-lib) is being developed to offer flexibility in using other containers when gcore becomes obsolete.

• Unavailability of Building tools

The ETICS infrastructure hosted at CERN is planned to be shutdown at the end of April 2013. Therefore members of WP7 have planned to upgrade the ETICS instance at Engineering and perform the migration of the integration activity on that instance during the Q1 2013. The start of the migration activity is planned for January 2013 and will give enough time to complete it on time.

• Possible Security issues on the production infrastructure

The WP5 and WP7 teams have discussed the issue and decided to start from Jan 2013 to integrate the gCube software using JAVA SE 7, in order to understand possible incompatibility issues . The WP5 members have also planned during Q1 2013 the migration to JAVA 7 of all the infrastructure nodes.

• Lack of visibility through media channels and external events

It was decided to promote the iMarine visibility through a dedicated mobile application. It was named AppliFish and its success - proved by more than 4000 downloads in few weeks - globally distributed around the world strongly helped in increasing the iMarine visibility and the interest around the iMarine initiative.

• Difficulty increasing users’ participation to engage in iMarine training activities

Training for interesting users is available on the project's website. See: eTraining

• Provide a new domain model representation for a given service

Documentation is available on the wiki

• The gCube Container is becoming obsolete

To remove the dependency to gCore a new framework has been designed and it is currently under testing. The framework is called SmartGears and it is currently tested in the implementation of the new TabularData service. SmartGears provides the same gCore capabilities but the remote deployment that will be added later with a dedicated per-container extensions.

• Adoption unwillingness for developed software

Simplified interfaces (Client Libraries), Adoption of standards / Simplified APIs. Due to the high probability of this risk a new component, named "FeatherWeight stack" has been introduced to mitigate this risk.

• Adoption of new technologies

Before adopting a new technology, the alternative solutions are examined and the most appropriate and easy to adopt is being selected. For every a new component the survey is reported at the related tickets