Risk Analysis and Risk Response
| |
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.
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
| 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:
- Networking Activities Risks
- Service Activities Risks
- 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:
- the value of the asset associated to the risk
- the indicator of the probability of the risk being triggered
- 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: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
| 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 |
||
| 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. |
|
| 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 increased number of interactions with the communities and the increase of the collaborations with other project and initiatives, as documented at [1], prove the strong 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. |
| 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. | -WP3 with the support of WP3 and in close collaboration with the Technical Director and the project governance lead to the preparation of the Application Catalogue, yet available at [2] -4 main application bundles were identified and their visual identity was created. |
| 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 | 2 | 6 | 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 | 1 | 2 | 2 | #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 [3] |
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 | 1 | 1 | 1 | 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 | 2 | 4 | 8 | 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 continuous integration is now performed with Java 7. Minor problems have been fixed. It remains to update the infrastructure with Java 7 and this is currently scheduled in October 2013. |
| 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:
|
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 | 3 | 3 | 9 | All | #2072 | -Provide a stable development infrastructure that reflects the production one. -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. -Several nodes have been replaced in the default development infrastructure to improve the overall availability of the computational and service resources. |
| Long transition periods among adopted technologies | Adopting a new technology for core components without specifying clear directives leads to unnecessary effort | 1 | 3 | 3 | All | #2080 | Make more specific work plans | -During the second period the FeatherWeightStack (FWS) was released by offering a simplified way to interact with the infrastructure. It was planned, then designed, implemented, tested and release having in mind the impact of the change a core component imposes to other software components. The FWS was first introduced at the Technical Committee (Tcom) meeting, then it was released and a training event was organized to another Tcom event. Complete documentation was released and it is accessible through the Developer Guide at How to interface with a gCube-based Infrastructure (a.k.a. Featherweight Stack Client). -A similar approach will be followed with SmartGears, the new framework offering capabilities comparable to gCore in the third reporting period. |
| 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 | 2 | 2 | 4 | 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 |
-VREs are deployed -various actions were taken. |
| 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. | 2 | 2 | 4 | 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) |
-The management and visibility problem was alleviated by scheduling various teleconferences and email exchanges. -Moreover the objective of constructing and evolving a MarineTLO-based warehouse aided the coordination of the related activities. |
| 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 | |
| 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. |
The number of components increase the time of build and increase the time of integration and testing. At the end of the first reporting period, the release 2.8.1 accounted for 665 software components. During the second reporting period, several frameworks were refactored and some of the frameworks were replaced by others. Everything was conceived primarily to satisfy the needs of the EACoP. However, specific effort was also devoted to optimize the software distribution. Thus a number of software packages were replaced with more modern packages and others were changed towards the adoption of common components. This allowed to reduce the overall number of components and consequently the time of integration and testing. At the beginning of the third reporting period, July 2013, the latest gCube release, 2.16, counts for 578 software components. An overall 13% reduction of software components can therefore be accounted despite the fact that several new features and some new software frameworks were added. |
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
