ICT Seventh Framework Programme (ICT FP7)

Grant Agreement No: 318497

Data Intensive Techniques to Boost the Real – Time Performance of Global
Agricultural Data Infrastructures

D1.4.3. Quality Assurance & Risk Assessment Plan

Deliverable Form

Project Reference No. ICT FP7 318497

Deliverable No. D1.4.3

Relevant Workpackage: WP1: Project Management

Nature: R

Dissemination Level: PU

Document version: Final V3.0

Date: 21/11/2014

Authors: UAH, NCSR-D

Document description: This deliverable will incorporate details about SemaGrow’s quality assurance
processes. It defines all processes and instruments to be used for the regular
quality monitoring and risk assessment of the project in the form of a handbook
for project partners. Furthermore, it will include a Critical Path Analysis (CPA) of
the main project activities, identifying risk points, and procedures to deal with
them. This deliverable will also include the Quality Assurance performance
indicators
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Document History

Version Date Author (Partner) Remarks

Draft v0.1 14/01/2013 UAH Document Setup

Draft v0.5 25/01/2013 UAH, NCSR-D Draft Version

Draft v1.0 16/04/2013 UAH, NCSR-D Internal Review

Version 1.0 30/04/2013 UAH, NCSR-D Delivered as D1.4.1

Draft v1.5 15/11/2013 UAH, NCSR-D Updates, Revisions

Draft v1.7 29/11/2013 UAH, NCSR-D Internal Review

Draft v2.0 06/12/2013 UAH, NCSR-D Revisions

Version 2.0 20/12/2013 UAH, NCSR-D Delivered as D1.4.2

Draft v3.0 15/10/2014 UAH, NCSR-D Revisions

Version 3.0 31/10/2014 UAH, NCSR-D Delivered as D1.4.3

Page 2 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

EXECUTIVE SUMMARY
This document addresses the Quality Assurance and the Risk Management Plan. The aim of this deliverable is to
describe the mechanisms that will be used throughout the project in order to ensure the quality level of the project
deliverables and the project outcomes.
This document will also serve as a guide to the project coordinator, in order to ensure that quality reviews will occur at
appropriate points in the project, and as a reference for all project partners, in order to understand their
responsibilities, regarding the project deliverables and outcomes.
In this context, quality control mechanisms are defined as well as Critical Path Analysis, in order to be easy to identify
important tasks and dependencies that are critical for the success of the project. This document will also serve as a
detailed guide to the SemaGrow partners in order to establish effective cooperation within the consortium and ensure
the highest level of project documentation. Moreover, the document outlines the success criteria for each deliverable,
defines the structure of each deliverable, describes the quality review techniques according to PRINCE2 technique and
also defines configuration management procedures and change control.
The last chapter of the document is devoted to the potential problems that may occur during the project: It includes
not only a detailed description of potential risks, but also management procedures that will be applied to either avoid
the potential risk or minimize its negative impact.
This document should be used as a reference by the project coordinator and all project partners.

Page 3 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

TABLE OF CONTENTS
LIST OF FIGURES ........................................................................................................................................................... 5

LIST OF TABLES ............................................................................................................................................................. 6

LIST OF TERMS AND ABBREVIATIONS ........................................................................................................................... 7

1. INTRODUCTION..................................................................................................................................................... 8

1.1 Purpose and Scope ............................................................................................................................................... 8

1.2 Relation of D1.1 and D1.4.1 .................................................................................................................................. 8
1.3 Audience ............................................................................................................................................................... 8
1.4 Deliverable Structure ............................................................................................................................................ 8

2. QUALITY APPROACH ............................................................................................................................................. 9

2.1 Planning ................................................................................................................................................................ 9

2.2 Quality Assurance ................................................................................................................................................. 9
2.3 Quality Responsibilities ....................................................................................................................................... 10
2.4 Critical Path Analysis ........................................................................................................................................... 13

3. QUALITY CONTROL...............................................................................................................................................15

3.1 Quality Methods ................................................................................................................................................. 15

3.2 Deliverable Descriptions and Quality Criteria ..................................................................................................... 15
3.3 Deliverable Development Approach ................................................................................................................... 17
3.3.1 General & Deliverable Quality Indicators ................................................................................................... 18
3.3.2 Work Package Progress Indicators .............................................................................................................. 19
3.3.3 Technology Indicators ................................................................................................................................. 20
3.4 Quality Recording................................................................................................................................................ 22
3.4.1 Actions ........................................................................................................................................................ 22
3.4.2 Decisions ..................................................................................................................................................... 22

4. QUALITY GUIDELINES ...........................................................................................................................................23

4.1 Publication Tools ................................................................................................................................................. 23

4.2 Document Types ................................................................................................................................................. 23
4.3 Configuration Management ................................................................................................................................ 25
4.4 Change Control ................................................................................................................................................... 25

5. RISK MANAGEMENT ............................................................................................................................................27

5.1 Scope................................................................................................................................................................... 27
5.2 Risk Assumption .................................................................................................................................................. 27
5.3 Risk Assessment .................................................................................................................................................. 27

Page 4 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

LIST OF FIGURES
Figure 1: Quality Relationship ............................................................................................................................................. 12
Figure 2: Deliverable Production Process ........................................................................................................................... 18
Figure 3: Change Control Approach .................................................................................................................................... 26
Figure 4: Risk Analysis Process ............................................................................................................................................ 27

Page 5 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

LIST OF TABLES
Table 1: Performance Indicators ......................................................................................................................................... 10
Table 2: Key Milestones ...................................................................................................................................................... 13
Table 3: Deliverables List .................................................................................................................................................... 17
Table 4: General Quality Indicator ...................................................................................................................................... 18
Table 5: Deliverables Quality Indicators ............................................................................................................................. 19
Table 6: Work Package Quality Indicators .......................................................................................................................... 20
Table 7: Technology Quality Indicators .............................................................................................................................. 22
Table 8: Sample Risk Methodology ..................................................................................................................................... 28
Table 9: Management Risks ................................................................................................................................................ 30
Table 10: Technical Risks .................................................................................................................................................... 31

Page 6 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

LIST OF TERMS AND ABBREVIATIONS

Term/Abbreviation Definition

Consortium Overall description of the joint partnership of the SemaGrow parties

refers to the monitoring and co-financing unit of the project in the context of the
European Commission
ICT Policy Support Programme, which is represented by the Project Officer (PO)
(EC)
and any other appointed personnel

the organisations (including the Coordinator) that have formally committed

Partner (through their accession to the Grant Agreement) to carry out the working
activities of the SemaGrow project

an independent check that the project outputs fit for purpose or meet
Quality Assurance
requirements

the process of monitoring specific project outcomes to determine whether they

Quality Control comply with relevant standards and of identifying ways to eliminate causes of
unsatisfactory performance

a set of grouped work activities that have been described Description of Work
Work Package (WP)
(DoW), resulting in a number of deliverables

Terms used in a quality context are sometimes interpreted differently or interchangeably by various people.
This can lead to misunderstandings. For the purposes of the SemaGrow project management methodology,
the terminology used in this deliverable is derived from international ISO 9000 standards.

Page 7 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

1. INTRODUCTION

1.1 Purpose and Scope

The present deliverable facilitates Partners cooperation in the project, by defining a set of rules and guidelines for the
organisation and delivery of the day-to-day work.
The plan summarises what has to be achieved by the project, aiming of helping all the partners in procedures related to
management and quality control. It is a fundamental working tool that every partner is invited to refer to, when a
deliverable is to be prepared, a meeting to be organised or a problem to be solved.

1.2 Relation of D1.1 and D1.4.3

The tasks of D1.1 "Project Management Plan" and D1.4.1 "Quality Assurance and Risk Assessment Plan" are closely
connected. D1.1 is a general overview of the management procedure of the SemaGrow project, whereas D1.4.3 is a
reference to everyday management tasks.
1.3 Audience
This deliverable has been created specifically for the SemaGrow Partners, describing the quality procedures to be
followed for the duration of the project

1.4 Deliverable Structure

Some content within this plan is derived from the contract and its annexes, while other sections have been defined and
written specifically for this document.
The document is structured in the following manner:
Chapter 2: Quality Approach – the second chapter outlines the quality planning defining the outputs required by the
project, with their respective quality criteria, quality methods and the quality responsibilities of those involved. It also
explains the role of Critical Path Analysis and presents how it will be applied throughout the project.
Chapter 3: Quality Control: – the third chapter presents the control methods that will be applied in order to ensure the
high quality outcome of the project as well the responsibilities of project partners in this area. It details the quality
criteria for each deliverable, describes the deliverable development approach and sets out the quality indicators. It also
describes the quality review technique based on the PRINCE2 standards and the recording mechanism.
Chapter 4: Quality Guidelines – the fourth chapter presents the general principles and guidelines of creating the
documentation for the project: it describes the main types of documents, the desired structure and the methods and
procedures of configuration management and change control to be used in the SemaGrow project.
Chapter 5: Risk Management – the last chapter outlines potential risks as well as presents the detailed description of
their nature, contingency and threshold level. Also monitoring mechanisms that will be applied in case any potential
risk occurs are presented in this section.

Page 8 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

2. Quality Approach

2.1 Planning
Quality Management is defined as the coordinated activities to direct and control a project with respect to quality. The
Consortium Lead (UAH) recognises that each of the Partners may have their own documented quality management
system; however for ease of coordination the project will put its own quality processes in place.
Quality planning is about defining the outputs required by the project, with their respective quality criteria, quality
assessment methods and the quality responsibilities of the involved partners. Quality assurance provides control to the
project direction, ensures that the management is of a high quality with respect to the nature of the project and that
the project complies with relevant corporate or programme management standards and policies.
The purpose of quality planning is to provide a secure basis for:
 Project Board agreements on the overall quality expectations, the products required with their associated
quality criteria, the means by which quality will be achieved and assessed, and ultimately, the acceptance
criteria by which the projects products will be judged
 Communicating these agreements unambiguously so all project Partners have a common understanding of
what the project is setting out to achieve
 Control i.e. establishing an effective baseline for the projects quality controls and a secure means of achieving
deliverables that are fit for purpose
This plan forms (a) a guide for the project coordinator to follow in order to ensure that the quality reviews occur at
appropriate points in the project, and (b) a reference for all project partners in order to understand their
responsibilities, thus delivering high quality deliverables and outcomes to help SemaGrow achieve its goals.

2.2 Quality Assurance

SemaGrow will apply ISO/IEC 19796-1 to its own operations. ISO/IEC 19796-1 is a framework to describe, compare,
analyse, and implement quality management and quality assurance approaches. It will serve to compare different
existing approaches and to harmonize these towards a common quality model. It consists of the following items:
 description scheme for quality management
 process model defining the basic processes to be considered when managing quality
 conformance statement for the decision format
The ISO/IEC 19796-1 standard was developed by the Working Group 5 “Quality Assurance and Descriptive Frameworks”
of the standardization committee ISO/IEC JTC1 SC36. The quality standard contains the reference process model
“Reference Framework for the Description of Quality Approaches” (RFDQ) to help stakeholders to document and (re-
)define their everyday business and processes.
Evaluation within this project is to be both formative and summative. The former is essentially self-assessment and will
be carried out by all partners. The summative evaluation will involve external as well as internal evaluation.
SemaGrow outputs and processes will be qualified and quantified according to the quality assurance mechanism that is
described in this document. In general, quality assurance in the project will be carried out in two levels: the progress
monitoring level, related to monitoring both the formal milestones of the project as well as a set of WP-internal
milestones of smaller granularity, and the project output assessment level, related to the assessment of the different
output types of the project (e.g. content output, technical/software output, evaluation/validation output,
dissemination/valorisation output, scientific output).
There are many areas to be evaluated. These can be divided into two main elements: outputs and processes. Output is
what is achieved by the project and whether this represents success or failure – with respect to contractual targets. It
could also consider: Innovation – whether anything genuinely new has been developed; Quality of outputs and
outcomes; and Impact. Process looks at how outputs were achieved, including: Transnationality – success and partner
contributions – value added; Partnership working – overall management and effectiveness of partner contributions;
Validity – whether needs of both partners and the project have been met; and Dissemination - whether potential target
audiences have been reached and across the consortium. The table below shows performance indicators for the project
implementation.

Page 9 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Nature Methodology for data collection

Questionnaires filled-in through an interview with the partners

Effective project management
– six monthly intervals (UAH)
Feedback from partners (All)
Standards adoption
Feedback from liaisons with standards (NCSR-D)
Dissemination activities have reached a wide Completion of valorisation plans and activity reports using
audience of potential targets in all Member States standard templates (All)
Qualitative questionnaire (UAH, SWC), targeting potential
Sustainability & Exploitation Network users of the SemaGrow outcomes, will provide feedback so as
to align RTD activities with real market /business needs.
Set measurable goals in terms of numbers of access,
Web site and online dissemination channels download, upload, rating, etc. and evaluate these every three
months (UAH)
Deliverables Peer reviews (All)
Table 1: Performance Indicators

Six monthly reports will include on-going evaluation of activities and impact (based on the criteria above) and it is
anticipated that these areas will be based on data collected not only from partners themselves but also from other
organizations, in particular Member States that are participating in the project activities. To achieve this, focus groups
will be held – in parallel with piloting activities – in order to provide feedback from stakeholders external to the project.
This approach recognizes that evaluation needs to be placed at the centre of the planning and development processes
and also that, not only is analysis of information collected for monitoring purposes important, but also evaluation from
partners and key stakeholders. Therefore, those involved in the on-going quality assurance and formative evaluation
processes include:
• The partnership
• Beneficiary Groups
• Social Partners (representatives of employers and employees)
• Local, regional and national organizations
• Other EC projects
• Other policy makers

2.3 Quality Responsibilities

The SemaGrow Project participants will collaborate throughout the project in order to meet all the SemaGrow
objectives. Effective collaboration requires central co-ordination, clear rules for communication and unambiguous
mechanisms for decision-making. These principles are detailed in “D1.1-Project Management Plan”. Whilst everyone on
the project has a responsibility to deliver high quality deliverables and project outcomes, the key project roles in this
area are the following:
Project Management Board
 Highest level authority when making key quality decisions
 Regularly verify the progress of work, the quality of results and their correspondence with the overall project
objectives and time scheduling;
 Set tolerances for the Quality Assurance Sub-Committee
 Decide whether deliverables pass internal review and can be submitted to the Commission

Project Coordinator
 Responsible for day-to-day quality management tasks
 Ensures that Documents Commissions meet quality expectations and acceptance criteria
 Prepares and maintains the product descriptions

Page 10 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

 Ensures that Work Package Leaders implement the quality control measures
 Address possible conflicts, looking for the widest internal consensus and taking care that project internal rules
are respected, including legal and ethical obligations; in the event that consensus is not reached, apply the
rules for problem management and conflict solving.

The Project Coordinator is Prof. Miguel-Angel Sicilia (http://www.cc.uah.es/msicilia/) who is a Professor at the
Computer Science Dept. of UAH. Miguel-Angel is currently coordinating the FP7 INFRA agINFRA and the CIP PSP VOA3R
projects that are working on the creation of large scale virtual data infrastructures for agriculture and aquaculture. He is
the Editor-in-Chief of the International Journal of Metadata, Semantic & Ontologies (IJMSO) and the International
Journal of Service Science, Management, Engineering, and Technology (IJSSMET). In 2005 he has launched and has
served in various Chairing roles for the annual Metadata and Semantics Research Conference (MTSR) that has a rather
applied and multi-disciplinary nature with established domain-specific tracks like the Metadata & Semantics for
Agriculture, Food & Environment one that has been organized in MTSR since 2007.
Scientific Manager
 Responsible for the scientific vision of the project
 Responsible for the scientific supervision of the work packages, planning and control of activities
 Responsible for guiding all activities related to the research of the project on intelligent information
management topics
Dr. Vangelis Karkaletsis (http://users.iit.demokritos.gr/~vangelis/) serves as the SemaGrow Scientific Manager (SM). Dr.
Vangelis Karkaletsis is a Research Director at NCSR-D and head of the Software and Knowledge Engineering Laboratory
of the Institute of Informatics and Telecommunications of NCSR-D. He is the Technical Manager of the FP7 ICT NOMAD
project on web content analysis for e-government applications, and has served as the Project or Technical Manager in
FP projects such as QUATRO Plus, MedIEQ, and OntoSum. He belongs to the Adjunct Faculty of the Dept. of Computer
Science & Engineering, University of Texas at Arlington (UTA), USA; also regularly serving as a lecturer in postgraduate
courses at the University of Athens, Greece. He has served as the Chair of the 12th Conference of the European Chapter
of the Association for Computational Linguistics (EACL-2009), the 6th Hellenic Conference on Artificial Intelligence
(SETN-10), and has served in the past as the Vice-chair of the Hellenic Association of Artificial Intelligence (EETN).
Technical Manager
 Responsible for the technical vision of the project.
 Responsible for monitoring the technical development and the integration of all deployed services
Dr. Stasinos Konstantopoulos (http://www.iit.demokritos.gr/people/konstantopoulos-stasinos) serves as the Technical
Manager (TM). Stasinos is MEng in Computer Engineering and Informatics (University of Patras, Greece, 1997), MSc in
Artificial Intelligence (Edinburgh University, U.K., 1998), PhD on Computational Logic and Language Technology
(Groningen University, the Netherlands, 2003) and has been affiliated to the Institute of Informatics &
Telecommunications, NCSR "Demokritos" since 2004 through several national, FP6-IST, and FP7-ICT projects. He was
previously leading WP3 in the SemaGrow project. He is also actively involved in W3C activities and has participated in
various Working Groups and Community Groups, including the POWDER Working Group (2007-2009) where he
contributed the logical foundations of the POWDER Recommendation. He currently participates in the newly
established CVSW Working Group (2014).
The Quality Assurance Sub-Committee
 Will monitor the WP activities
 Guide the implementation and assessment of milestones and deliverables
 Take necessary actions to adjust, modify and fasten the activity of a Work Package
 Account for feedback from the WP leaders and the Quality Manager
 Decide whether deliverables pass internal review and can be submitted to the Commission

Work Package Leaders

 Co-ordinate the development activities in the corresponding Work Package
 Keep the Board and the Project Coordinator informed about the development and progress status on a regular
basis. In particular they shall:
 technically coordinate the WP, steering it towards its objectives;
 define the detailed WP plan and objectives and control their execution;

Page 11 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

 report about work progress, deliverables, achievements, deviations from schedule, problems, results,
following the reporting methodology adopted in the project

A summary of the quality relationship between each of these roles is provided in the diagram below.

European
Commission

Activity Reports
Project Reviews

Project Board

Activity Reports
Project Meetings

Quality Assurance
Project Coordinator
Sub Committee
Project Meetings
Deliverable Peer Reviews Conference Calls
(Inspection and Testing) Activity Reports

Work Package
Leaders

Figure 1: Quality Relationship

Expert Steering Group

The project’s Expert Steering Group (ESG) has been finalized consists of external experts from relevant scientific,
research and technical fields. The ESG will need to meet annually with the PB, virtually or physically, in order to review
the project progress and achievements to date and will advise the project on its future paths. This is why the members
of the ESG have been selected among key research figures of the Semantic Web and Intelligent Information
Management domains. The following persons are the members of the ESG:
Dr. Ivan Herman (http://www.ivan-herman.net) graduated as mathematician at the Eötvös Loránd University of
Budapest, Hungary, in 1979. After a brief scholarship at the Université Paris VI he joined the Hungarian research
institute in computer science (SZTAKI) where he worked for 6 years. He left Hungary in 1986 and, after a few years in
industry in Munich, Germany, he joined the Centre for Mathematics and Computer Sciences (CWI) in Amsterdam where
he had a tenure position since 1988. He received a PhD degree in Computer Science in 1990 at the University of Leiden,
in the Netherlands. He joined the W3C Team as Head of W3C Offices in January 2001 while maintaining his position at
CWI. He served as Head of Offices until June 2006, then as Semantic Web Activity Lead until December 2013. Since June
of 2013, he is a Digital Publishing Activity Lead. Before joining W3C he worked in quite different areas (distributed and
dataflow programming, language design, system programming), but he spend most of his research years in computer
graphics and information visualization. He also participated in various graphics related ISO standardization activities and
software developments.
Dr. Alfio Ferrara (http://islab.di.unimi.it/homePage/alfio/) assistant professor of Computer Science at the University of
Milano, where he received his Ph.D. in Computer Science in 2005. His research interests include database and semi-
structured data integration, Web-based information systems, ontology engineering, and knowledge representation and
evolution. On these topics, he works in national and international research projects, including the recent EU FP6
BOEMIE (Bootstrapping Ontology Evolution with Multimedia Information Extraction) project, the FP6 INTEROP NoE
(Interoperability Research for Networked Enterprises Applications and Software) project, and the ESTEEM (Emergent
Semantics and cooperaTion in multi-knowledgE EnvironMents) PRIN project funded by the Italian Ministry of Education,
University, and Research. He is also author of several articles and papers in international journals and conferences
about ontology management and matching.
Dr. Minos Garofalakis (http://www.softnet.tuc.gr/~minos/) is Professor of Computer Science at the School of ECE of
the Technical University of Crete in Chania, Greece, and the Director of the Software Technology and Network
Applications Laboratory (SoftNet). He also served as the ECE Department Chair for the period 9/2011-9/2013. Finally,
he is Member of the Board of Directors of Information Society, S.A., a Greek government organization for advancing
large-scale, national-level efforts in Information and Communication Technologies. His current research interests lie in
the areas of probabilistic data management, approximate query processing, data streaming, network management, big
data analytics and mining, and XML and text databases

Page 12 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

2.4 Critical Path Analysis

To understand where and when key quality reviews need to take place, the project has undertaken a critical path
analysis (CPA) to show the major dependencies between tasks. The CPA shows the following key milestones:

WP Expected
No Milestone Name Means of Verification1
involved date

Project setup: Project Management Plan, PO, DV (D1.1, D1.2.1, D1.4.1, D2.1.1, D2.2.1,
first version of Quality Insurance & Risk WP1 D2.3.1, D7.1.1, D7.2.1, D7.3)
MS1 Assessment Plan, first version of Data WP2 M6
Stream & Collections, first version of Use WP7 (All deliverables were submitted
Cases, Project website and Fact Sheet successfully)

Initial Testing Methodology & (1st Review)

Preliminary Prototypes: Intermediate use PO, DV (D1.2.2, D1.3.1, D1.4.2, D2.1.2,
cases and architecture. Preliminary D2.2.2, D3.1.1, D3.2.1, D4.1, D5.1.1, D5.4.1,
component prototypes (resource D6.1.1, D7.1.2, D7.2.2, D7.4.1, D7.5.1)
MS2 discovery, ontology alignment). Initial All M12
rigorous experimental testing (All deliverables were submitted
methodology (to be refined and finalized successfully)
on sync with the evolution of research Official EC Review scheduled for 21 January
results). 2014

First version of Functional Prototype: PO, DV (D1.2.3, D3.3.1, D3.4.1,D5.2.1,

WP1
Preliminary component prototypes D5.3.1, D5.4.2, D6.1.2)
WP3
MS3 (content classification & ontology M18
WP5
evolution, heterogeneous distributed (All deliverables were submitted
WP6
semantic querying). Final piloting plan. successfully)

(2nd Review)
PO, DV (D1.2.4, D.1.3.2, D1.4.3, D2.1.3,
Final Use Cases & Interim Integrated &
D2.3.3, D4.2, D4.3, D5.1.2, D5.4.3, D6.2.1,
Evaluated Prototype: Use Cases finalized.
D6.3.1, D7.1.3, D7.2.3, D7.4.2, D7.5.2)
MS4 Interim prototype integrated. Interim All M24
(All deliverables were submitted
sustainability, uptake & marketing
successfully
positioning plan.
Official EC Review scheduled for 12
December 2014

Prototype integrated in real-life

infrastructure & Project Results (Final Review)
Assessment: PO, UE, DV (D1.2.5, D1.2.6, D1.3.3, D2.3.4,
MS5 Final architecture, Final prototype All M36 D3.1.2, D3.2.2, D.3.3.2, D3.4.2, D4.4, D5.3.2,
integrated, evaluated, and deployed. D5.4.4, D5.5, D6.2.2, D6.3.2, D6.4, D7.1.4,
Final sustainability, uptake & marketing D7.2.4, D7.4.3, D7.5.3, D7.6)
positioning plan.

Table 2: Key Milestones

1
DV: Peer Reviewed corresponding deliverables. PO: Assessed by Project Officer UE: Evaluated by users

Page 13 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

At these milestones, the Project Coordinator needs to review project achievements against the Project Plan to ensure
work is on track. Any changes or deviations will need to be reviewed and approved by the Project Board (see chapter
4.4 on Change Control).

Page 14 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

3. Quality Control
Quality control focuses on the operational techniques and activities used by those involved in the project to:
 Fulfil the requirements for quality (i.e. inspections and testing)
 Identify ways of eliminating causes of unsatisfactory performance

3.1 Quality Methods

SemaGrow’s approach to quality is based upon creating deliverables throughout the project that contribute to
delivering the required project output and impact.
SemaGrow will mainly use the “Appraisal” method for determining quality. Through this method the finished
products/deliverables are assessed for completeness and fitness. There are two types of appraisal method depending
on the extent to which it is possible to define objective quality criteria.
 Testing – if the quality criteria are truly objective and quantifiable
 Inspection – if some subjective judgement is required
A quality inspection is a systematic, structured assessment of a deliverable conducted in a documented and organised
fashion. This approach to quality inspection can be used:
 During the development of deliverables
 To mark the completion and approval of deliverables
 To complement testing, e.g. simply for checking test results
An overview of how a quality inspection (review) should be managed can be found in Chapter 3.4.

3.2 Deliverable Descriptions and Quality Criteria

The following table presents the expected deliverables and the partners which are responsible for reviewing the
corresponding deliverable.
Del.
Deliverable name Reviewers
no.
D1.1 Project Management Plan -

D1.2.1 6-monthly Report -

D1.2.2 12-monthly Report -

D1.2.3 6-monthly Report -

D1.2.4 12-monthly Report -

D1.2.5 6-monthly Report -

D1.2.6 Final Report -

D1.3.1 Annual Public Report -

D1.3.2 Annual Public Report -

D1.3.3 Annual Public Report -

D1.4.1 Quality Assurance & Risk Assessment Plan -

D1.4.2 Quality Assurance & Risk Assessment Plan -

D1.4.3 Quality Assurance & Risk Assessment Plan -

D2.1.1 Envisaged Applications & Use Cases NCSR-D, SWC

D2.1.2 Envisaged Applications & Use Cases NCSR-D, SWC
D2.1.3 Envisaged Applications & Use Cases NCSR-D, SWC

Page 15 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

D2.2.1 Data Streams & Collections NCSR-D, SWC

D2.2.2 Data Streams & Collections NCSR-D, SWC
D2.3.1 Large Scale Distributed Architecture SWC, UNITOV
D2.3.2 Large Scale Distributed Architecture SWC, UNITOV
D2.3.3 Large Scale Distributed Architecture SWC, UNITOV
D2.3.4 Large Scale Distributed Architecture SWC, UNITOV
D3.1.1 Techniques for Resource Discovery UAH, SWC
D3.1.2 Techniques for Resource Discovery UAH, SWC
D3.2.1 Techniques for Ontology Alignment FAO, DLO
D3.2.2 Techniques for Ontology Alignment FAO, DLO
D3.3.1 Techniques for Content Classification & Ontology Evolution FAO, DLO
D3.3.2 Techniques for Content Classification & Ontology Evolution FAO, DLO
D3.4.1 Techniques for Heterogeneous Distributed Semantic Querying AK, SWC
D3.4.2 Techniques for Heterogeneous Distributed Semantic Querying AK, UAH
D4.1 Scalability & Robustness Experimental Methodology AK, FAO
D4.2 Experimental Report on Current Data Sets AK, FAO
D4.3 RDF Triple Generator of Realistic Data Sets SWC, AK
D4.4 Experimental Report on Projected Data Sets AK, FAO
D5.1.1 Semantic Store Infrastructure NCSR-D, SWC
D5.1.2 Semantic Store Infrastructure NCSR-D, SWC
D5.2 Synergetic Semantic Annotation Environment UAH, UNITOV
D5.3.1 Automatic Rigorous Testing Components AK, FAO
D5.3.2 Automatic Rigorous Testing Components AK, FAO
D5.4.1 Integrated SemaGrow Stack API components NCSR-D, AK
D5.4.2 Integrated SemaGrow Stack API components NCSR-D, AK
D5.4.3 Integrated SemaGrow Stack API components NCSR-D, AK
D5.4.4 Integrated SemaGrow Stack API components NCSR-D, AK
D5.5 Prototype integration with agINFRA NCSR-D, AK
D6.1.1 Piloting Plan UAH, NCSR-D
D6.1.2 Piloting Plan UAH, NCSR-D
D6.2.1 Pilot Deployment NCSR-D, SWC
D6.2.2 Pilot Deployment NCSR-D, SWC
D6.3.1 Pilot Trials NCSR-D, SWC
D6.3.2 Pilot Trials NCSR-D, SWC
D6.4 Integrated Evaluation Report & Recommendations DLO, FAO
D7.1.1 Project Fact Sheet -
D7.1.2 Project Fact Sheet -
D7.1.3 Project Fact Sheet -
D7.1.4 Project Fact Sheet -
D7.2.1 Project Website -

Page 16 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

D7.2.2 Project Website -

D7.2.3 Project Website -
D7.2.4 Project Website -
D7.3 Dissemination & Awareness Plan -
D7.4.1 Annual Dissemination & Awareness Report -
D7.4.2 Annual Dissemination & Awareness Report -
D7.4.3 Annual Dissemination & Awareness Report -
D7.5.1 Sustainability, Uptake & Market Positioning Plan UAH, NCSR-D
D7.5.2 Sustainability, Uptake & Market Positioning Plan UAH, NCSR-D
D7.5.3 Sustainability, Uptake & Market Positioning Plan UAH, NCSR-D
D7.6 Knowledge Kit -
Table 3: Deliverables List

3.3 Deliverable Development Approach

Each deliverable will be created according to the set process shown in the figure below. Firstly, the Work Package
Leader responsible for a particular deliverable will present the proposed structure of the deliverable as well as the task
allocation between project participants to the Project Coordinator for approval. Once the Deliverable Development
Plan is confirmed by the Project Coordinator, all Project Partners will focus on providing appropriate content to the
partner responsible for the corresponding deliverable. Based on the received input, the WP leader will prepare the final
draft of the deliverable and will circulate it to the relevant project partners for feedback, 4 weeks before the deadline
of the deliverable. The review period for the reviewers takes one week. Based on received comments, the responsible
partner will have a period of one week to undertake all necessary improvements and changes in the document and
prepare a pre-final version to be sent for review to partners selected by the Project Coordinator, 2 weeks before the
deadline. Reviewers will have 1 week to complete the review. After this period the partner who is responsible for the
deliverable has a timeframe of 1 week for the revision and integration of comments and improvement suggestions.
Then final version is sent to the Project Coordinator for EC submission.
All reviewers will be asked to comment on the deliverable draft document and undertake overall assessment, evaluate
the deliverable against the Technical Annex description and look at the general quality of the deliverable. The table
below presents the phases and the timeframes of the deliverable production process:

Page 17 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Proposed structure (table of contents)

WP Manager:
with allocation of tasks to specific
Deliverable Development Plan
partners – approved by project
(DDP) coordinator
DDP (- 8 weeks)

Contributors: Work undertaken by individual partners

Inputs Required to collect required data and information

WP Manager: Collation of content to populate

Document Composition and document and final draft made available
Added Value to reviewers who have 1 week for review.

FINAL DRAFT (- 4 weeks)

Comments from reviewers fed back to
Reviewers the WP leader and pre-final version is
Comments produced / sent to mandatory partners 2
weeks before deadline
PRE-FINAL DRAFT (- 2 weeks)

Mandatory Partners Review: 1 week for official review by two

mandatory partners selected by Project
Quality Check
Coordinator

WP Manager has 1 week before the

deadline to revise the deliverable based
Revision by WP Manager:
on input received from the reviewers
Final Revision and produce final version

FINAL VERSION

Project coordinator sends copy to the

Project Coordinator:
European Commission
Final Validation

Figure 2: Deliverable Production Process

3.3.1 General & Deliverable Quality Indicators

At the beginning of the deliverable production process, the Project Coordinator will evaluate the Deliverable
Development Plan proposed by the Work Package Leader. The Project Coordinator will check the following indicators:

Quality Indicator Reference

The proposed contents are in accordance with the
SemaGrow DOW
objectives stated in the Description of Work

The allocation of the tasks is realistic and consistent SemaGrow DOW

with the roles of the partners in the work package/task. Project meetings

The timetable proposed is realistic and matches the

SemaGrow DOW
deadline highlighted in the Description of Work
Table 4: General Quality Indicator

During the production of the deliverable, there may be other intermediate phases where the Project Coordinator is
asked to review partial drafts, but because of time constraints this cannot be established as a rule. During the whole
process of draft production, each partner will be responsible for checking the quality of the deliverable as it progresses
(according to the same indicators in the table below).
The Project Manager and Quality Assurance Sub-committee will evaluate the final draft of each deliverable. The
following table provides a short list of indicators that the Quality Manager will use to assess the general quality of each
deliverable.

Page 18 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Quality Indicator Reference

The deliverable is in accordance with the objectives
SemaGrow DOW
stated in the Description of Work

The deliverable offers complete documentation on the SemaGrow DOW

work done in the corresponding WP/Task Project meetings
The deliverable is compliant with the templates and
editing guidelines as outlined within the Management SemaGrow D1.1 Management Plan
Plan
Editing to cover:
• Language and syntax errors
• Structure
The deliverable is clear and legible • Use of pictures, tables and
diagrams
• Clear distinction between body
and annexes
Content check covering:
• Missing Parts
The deliverable is complete • Non-existent references
• Topics not covered
• Unclear arguments
SemaGrow DOW
The deliverable is useful for the target reader/audience
Project Dissemination Plan

This document (for referencing and

Version history is clear and well documented
coding rules)
Table 5: Deliverables Quality Indicators
As a result of this exercise, the Lead Reviewer will prepare a statement summarising the results, the problems found
and their severity, the actions taken and the final evaluation of the Deliverable and will feed it back to the Project
Coordinator and the WP Leader. This process will be repeated until the deliverable’s quality is considered satisfactory.

3.3.2 Work Package Progress Indicators

The Work-package Leader will be in charge of assuring that the work is carried out according to schedule and that the
expected deliverables are produced.
The Quality Assurance process is also concerned with discovering and handling errors as early in the project lifecycle as
possible. As soon as any risk is identified, the WP leader will define a mitigation strategy as outlined in Chapter 5.
The progress of work will be tracked with the following objectives:

Quality Indicator Reference

SemaGrow DOW
The activity corresponds to the project specifications
This document

Development is consistent with user requirements User requirements

SemaGrow DOW
The development activity is based on a solid work plan
WP work plan
Monitoring Reports
All steps of development activity are fully documented Internal Reports
Deliverables

Page 19 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Internal documents
Architecture is available
Deliverables

There is a realistic risk assessment and recovery plan Internal documents

Table 6: Work Package Quality Indicators

3.3.3 Technology Indicators

The SemaGrow service will be evaluated applying the standard indicators as defined by the reference document ISO/IEC
25010:2011: Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE)
- System and software quality models’.
This document sets a number of characteristics and sub characteristics for external and internal quality assessment, as
per the following table:

Quality Indicator Reference

The capability of the software product to provide functions that
Functionality meet stated and implied needs when the software is used under
specified conditions.
The capability of the software products to provide an appropriate
Suitability
set of functions for specified tasks and user objectives.

The capability of the software product to provide the right or

Accuracy
agreed results or effects with the needed degree of precision.

The capability of the software product to interact with one of

Interoperability
more specified systems
The capability of the software product to protect information and
data so that unauthorised persons or systems cannot be read or
Security
modify them and authorised persons or systems are not denied
access to them
The capability of the software product to adhere to standards,
Functionality compliance conventions, or regulations in laws and similar prescriptions
relating to functionality.
The probability that the software will not cause the failure of a
Reliability
system for a specified time under specified conditions.

The capability of the software product to avoid failure as a result

Maturity
of faults in the software.
The capability of the software product to re-establish a specified
Recoverability level of performance and recover the data directly affected in the
case of a failure.
The capability of the software product to adhere to standards,
Reliability Compliance
conventions or regulations relating to reliability.
The capability of the software product to be understood learned,
Usability used and attractive to the user, when used under specified
conditions.

Page 20 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

The capability of the software product to enable the user to

Understandability understand whether the software is suitable, and how it can be
used for particular tasks and conditions of use.
The capability of the software product to enable the user to learn
Learnability
its application.

The capability of the software product to enable the user to

Operability
operate and control it.

Attractiveness The capability of the software product to be attractive to the user.

The capability of the software product to adhere to standards,

Usability compliance
conventions, style guides or regulations relating to usability.
The capability of the software product to provide appropriate
Efficiency performance, relative to the amount of resources used, under
stated conditions.
The capability of the software product to provide appropriate
Time behaviour response and processing times and throughput rates when
performing its function, under stated conditions.
The capability of the software product to use appropriate amounts
Resource utilization and types of resources when the software performs its function
under stated conditions.
The capability of the software product to adhere to standards and
Efficiency compliance
conventions relating to efficiency.
The capability of the software product to be modified.
Modifications may include corrections, improvements or
Maintainability
adaptation of the software to changes in environment, and in
requirements and functional specifications.
The capability of the software product to be diagnosed for
Analyzability deficiencies or causes of failures in the software, or for the parts
to be modified to be identified.
The capability of the software product to enable a specified
Changeability
modification to be implemented.

The capability of the software product to avoid unexpected effects

Stability
from modifications of the software.

The capability of the software product to enable modified

Testability
software to be validated.

The capability of the software product to adhere to standards or

Maintainability compliance
conventions relating to maintainability.

The capability of the software product to be transferred from one

Portability
environment to another.
The capability of the software product to be adapted for different
Adaptability specified environments without applying actions or means other
than those provided for this purpose for the software considered.

Page 21 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

The capability of the software product to be installed in a specified

Installability
environment.
The capability of the software product to co-exist with other
Co-existence independent software in a common environment sharing common
resources.
The capability of the software product to be used in place of
Replaceability another specified software product for the same purpose in the
same environment.
The capability of the software product to adhere to standards or
Portability compliance
conventions relating to portability.
Table 7: Technology Quality Indicators

3.4 Quality Recording

3.4.1 Actions
Actions are specific activities which are required for the project to move forward. They are normally the consequence
of decisions made during meetings, of Project Management Board decisions made by e-mail or tele-conference or they
may correspond to deadlines set in the Description of Work.
Meeting minutes will contain a record for each action with the following data:
• WPx: .Work Package & Work Package Title
• Partner/s: The partner or partners responsible for that action.
• Description: A short description of the action.
• Date: The completion date for the particular action.

3.4.2 Decisions
Decisions are official statements that are approved at the Project Board level. Decisions may affect the project in terms
of schedule, budget, corrective or back-up actions, technological choices, etc. The record for each decision will be as
follows:
Ref. WP/task Decision Notes

Their status becomes OK when the issue has been solved (usually translated into an Action or a Decision).

Page 22 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

4. Quality Guidelines

4.1 Publication Tools

In order to ensure easy access to the project documents and to reduce potential editorial burdens, Microsoft Word and
Excel will be used as standard tools for the project, together with MS PowerPoint and Adobe PDF. The minimum version
is Microsoft Office 2007 and partners should save the documents in the docx format.
Participants will use electronic mail facilities to enable the distribution of documents by electronic means, thus reducing
the delays associated with other methods of distribution.
Note that large attachments to e-mails should be zipped.
The subject of all project e-mails should begin with “[SemaGrow]:” to allow users to filter e-mails using e-mail client
facilities.

4.2 Document Types

Within the SemaGrow project, there are three distinct documents types envisaged:
 Documents for the Agency: these documents include Deliverables, Interim and Final Progress Reports and Cost
Statements.
 PowerPoint presentations for internal and external use: e.g. for project meetings, reviews, presentation during
workshops, exhibitions, conferences etc.
 Word documents for internal use: e.g. Agendas, Minutes, Technical contributions, other contributions etc.
The template to be used for creating and presenting all documents for the Agency (deliverables, progress reports etc.)
are available through the SemaGrow website. The template and consequently the documents for the Agency will show
the following pieces of information on the cover page:

 Title and Logos: the title of the document will be shown along with the relevant logos, such as the project logo,
the EU flag2 in order to acknowledge receipt of European Community funding 3 etc. According to the 2008
Project Management Guidelines, the European flag must be given appropriate prominence when displayed
together with the project’s logo.

 Partners: The names of the partners, who contributed to the document.

 Dates, due and actual: The due submission date along the actual submission date must be provided.

 Leading organisation: The name of the lead organisation for the preparation of the document must be
indicated here.

 Revision: This field denotes the version of the document which may be in the forms of v1, v2, v01 etc. The
value ‘Final’ denotes that the version of the document is the final and the submitted one.

 Dissemination level: In this field the list of persons or groups involved in the document distribution is reported.
The dissemination level field can have one of the following possible values:
o PU: The document is open and public to everyone
o PP: The document is restricted to the eParticipation Preparatory Action participants, including
European Commission services and project reviewers
o RE: The document is restricted to a specified group
o CO: The document is confidential i.e. restricted to the consortium members, including Agency and
Commission and project reviewers.

2
http://europa.eu/abc/symbols/emblem/download_en.htm
3
See Article II of the Grant Agreement

Page 23 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Documents internal to the project may also use this field for indicating the relevant work package with the
format WPx.

The predetermined structure of each document’s contents is broken down in the following sections:

 History: The History page will report version, date, modification reason, and organisation/author that have
performed the respective modification. Versioning will be kept as follows:
o Version integers are kept for document submission to the Agency. The first submission of a document
to the Agency will be marked as v1. If a second submission is needed, this will be v2 etc.
o Version decimals (in other words, releases) will be used for communication between partners. The
first draft version to be communicated within the Consortium will be vX.1, the second vX.2 etc.

 Executive Summary: An executive summary is a report, proposal, or portfolio, etc in miniature (usually one to
two pages). That is, the executive summary contains enough information for the readers to become
acquainted with the full document without reading it. Usually, it contains a statement of the problem, some
background information, a description of any alternatives, and the major conclusions. Someone reading an
executive summary should get a good idea of main points of the document without becoming bogged down
with details.

An executive summary differs from an abstract in that the former’s purpose is to inform the reader of the
points to be covered in the report without any attempt to tell what is said about them. Covering no more than
one to two pages in length, the executive summary is longer and is a highly condensed version of the most
important information the full document contains. Both the executive summary and the abstract are
independent elements rather than a part of the body of the document. Both are placed at the beginning of the
document.
With the possible exception of the conclusion and the recommendations, the executive summary is the most
important part of a report. As such, it should be the best-written and most polished piece of the document.
This is because many readers may only look at the executive summary when deciding whether or not to read
the entire document. In short, it may be expected that an executive summary will be read more frequently and
by more people than the entire document.
Since the executive summary is a condensation, when creating it, any preliminaries, details, and illustrative
examples must be omitted. In this respect, the main ideas should be included as well as the facts, the
necessary background to understand the problem, the alternatives, and the major conclusions. Brevity and
conciseness are the keys to a well-written summary.
Therefore, the structure of a comprehensive executive summary would address and incorporate the following
points:
o First, the objective and the scope of the document are described. In a concise, comprehensive and
straightforward way, it is explained what this document aims to do and how this is going to be done.
For example “In this report we identify future research priorities for eParticipation researchers. We do
this by first setting the context by providing the trajectory of eParticipation from its early days to
current practice. We then consider this current situation...”
o Second, the methodology and/or the rationale of the document are presented in order to provide an
overview of how the research results were obtained. For example, “The research priorities were
identified through analysing the literature – both workshop reports and scientific published papers
by...”
o Third, the main results/outcomes of the document are described. For example, “This coding resulted
in six main areas of barriers and challenges which are listed below: Complexity of research field
addresses problems...”
o Finally, if it is highly necessary some conclusions may be provided.

 Table of Contents

 List of figures

 List of tables

Page 24 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

 List of abbreviations and terms: a list providing the full titles and/or explanations of the abbreviation and terms
used in the document

 Introduction: this is a beginning section which states the purpose and goals of the following writing within the
document. This is generally followed by the main body and conclusions.

 Main body: the main body, as the name suggests, is the most important part of the document. The subject of
the document is explored and valid reasons and justifications are given.
 References: a reference is a previously published written work within academic publishing which has been
used as a source for theory or claims referred to which are used in the document. References contain complete
bibliographic information so the interested reader can find them in a library. References are added either at
the end of each document or at the end of the relevant section.

 Annexes: These sections may contain collection of supplementary material

In order to ensure homogeneity and quality of every document produced by the SemaGrow consortium, apart from the
afore-mentioned sections of the templates, attention will be paid to the following
 Headers and footers of each document will be formatted according to template guidelines
 Fonts, paragraphs, bullets, numbered lists etc. will be formatted using the predetermined styles
 Captions to all tables and figures will be used
 Automatic cross-referencing for tables and figures in the main body will be used to ensure readability
 Referencing should follow the IEEE 2006 referencing method or the ISO 690. References in main body should
be in the form of [1], [2], etc.

4.3 Configuration Management

File names of documents will follow a specific format to ensure correct communication of the documents without
losing track of their circulation. This becomes particularly important for documents that require consecutive
contributions from partners and that may circulate frequently and successively within the Consortium
The file name format is:

SemaGrow_ContentDescription_VER
ContentDescription A short description of the file’s content
VER Version number (v1, v01, …)

The file name format regarding the Deliverables is:

SemaGrow _Dxy_deliverable name_VER

Deliverable Name The title of the deliverable
VER Version number (v1, v01, …)

4.4 Change Control

Change management is the process for requesting, reviewing, approving, carrying out and controlling changes to a
projects deliverables. The process for change control is based upon:
 Responsibilities
 Tolerance for changes at different project levels
 Tools to be used to manage the change process

Any participant in the SemaGrow project may raise a Change Request. The Project Coordinator will ensure they are
captured and are proactively managed to conclusion. An initial review should be made to examine the need for the

Page 25 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

change, how it could be achieved and what the consequences would be. The most appropriate member of the Project
Team would normally perform this review. Based on those conclusions, the recommended action would be proposed
which would be one of three possible courses:
 Minor changes within scope can be approved by the Project Coordinator
 Any change affecting the deadline of a deliverable or outcome would need to be reviewed by the Project
Director and shared with the Project Board who would confirm the necessary revisions to get the project back
on course
 Changes of scope and contract revisions would require the approval of the European Commission

The diagram below highlights SemaGrow’s approach to change control.

Change Control Process

Commission Project
Project Partners Project Director
Officer

Identify
Potential Capture
Change

Review Assign for

Assessment Review

Propose Contract
Action Revision

Assign for Approve for

Action
Action Action

Review Action

Agree Closure

Figure 3: Change Control Approach

Page 26 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

5. Risk Management

5.1 Scope
Risk management is concerned with identifying potential problems and eliminating or reducing the damage the
realisation of those risks would cause. Failure to adequately manage risks will threaten the success of the project.
Risk management is the responsibility of the Project Management Board, and chiefly of the Project Coordinator. A well-
planned approach to risk control will allow the project team to concentrate resources in those areas where risk is high
and reduce risks to acceptable limits.
Risk assessment and management will be conducted at the start of the project and also throughout the project lifecycle
to ensure that risks are acknowledged and controlled. It is usually impossible to eliminate all risks, but they can be
recognised and dealt with. The risk management process requires that each risk is assessed and measures formulated
to prevent it (avoidance actions) or minimise its effect (amelioration actions). Both need to be considered because
avoidance measures may fail.
As the project proceeds, the nature of risks is changing. Old risks disappear and new ones come up. Consequently, risk
management is a continuous process thus risks should be regularly reviewed and reassessed.

5.2 Risk Assumption

The success of the SemaGrow project basically depends on four major assumptions:

1. Funding will not be reduced during the projects lifecycle.

2. Project partners are fully committed to delivering deliverables and achieving the goals of the project and will
all sign a consortium agreement.
3. SemaGrow aims to use more agricultural data than the volume initially contributed by the data partners, from
across Europe/world and open to all interested stakeholders - however the main rigorous testing experiments
and results will be on the promised data volume described in Annex II of the SemaGrow DOW.
4. Other FP7 projects will be willing to work in conjunction with SemaGrow.

5.3 Risk Assessment

The first step is to identify and evaluate the potential risks in the planned work. At the beginning of each work package
(WP) it is the responsibility of the WP Leader to conduct a risk assessment, ensuring that due consideration has been
given to all risks associated with the WP which is to be commenced. The following figure explains the process behind
risk analysis.
Find and define risk
Identify Risks
Identify Ownership

Decide probability of risk occuring

Assess Risks
Assess likely impact of risk

Plan against and manage the risk

Create Action Plan to Reduce Risk
Take preventative or corrective action

Review and update the risk plan

Monitor and Review Risk
throughout the project lifecycle

Collate Feedback on Success Levels Learn from experience

Figure 4: Risk Analysis Process

Page 27 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Risk management in SemaGrow will take place at three levels:

1. At the strategic level: concentrates on the relation between the project and the consortium with its environment.
Risk management at this level is the responsibility of the Project Consortium (PC).
2. At the tactical level: concentrates on the WPs’ contribution to the project objective. Risk management at this level
is the responsibility of the PC and the Project Board (PB)/Work Package Leaders (WPL).
3. At the operational level: concentrates on the activities within the work packages, which is the responsibility of
each WPL.
The initial risk factors that can be identified, which may apply to all three levels, are the following:
 Complexity - the activities may be too complex to realize.
 Scope - the total set of activities may be too large for the partners to realize and/or manage.
 Capacity - one or more of the partners may not be able to honour its commitments without the others having the
capacity to fill the gap.
 Reliability - the project methods and strategies applied could be inappropriate to realize the intended outcomes.
 Validity - the outcomes may not reflect the real needs and priorities of the stakeholders
 Sustainability - the project outcomes may not lead to a sustainable outcome.
In the risk management elaboration to be carried out within SemaGrow, each one of the risk factors will be analysed at
each one of the three levels, and will be detailed in terms of: identified and quantified risks; contingency action per
identified risk; monitoring mechanism; quantified threshold level; and line of action when threshold is overstepped. It
will build on the strategic risk assessment directions that the PB and PC will be responsible for.

Complexity Scope Capacity Reliability Validity Sustainability

The project
The total set of
One or more of methods and The outcomes do The project
RISK of activities is too
The activities are the partners is strategies applied not reflect the real outcomes may
Overall large for the
too complex to not able to are inappropriate needs and not lead to a
project partners to
realize. honour its to realize the priorities of the sustainable
activities realize and/or
commitments intended stakeholders. outcome.
manage.
outcomes.
Review the
activities and/or Prioritize and/or Replace Adjust project Adjust the project Adjust the
Actions scale down scale down defaulting methods and activities and project activities
project ambitions. partners. strategies. outputs. and outputs.
ambitions.

PC, SM, TM,PB PC, PB PC, PB PC, SM, PB PC, PB PC, SL, PB
Decision
(upon agreement (upon agreement (upon agreement (upon agreement (upon agreement (upon agreement
Maker
with PO) with PO) with PO) with PO) with PO) with PO)

Table 8: Sample Risk Methodology

SemaGrow is a research project with partners from several countries and different expertise; hence, the partners had
to clearly identify a number of management risks. In order to minimize the risks, the partners have concretized the
project proposal as much as possible and have agreed on the global project tasks. Furthermore, an elaborate project
management structure has been defined in order to monitor the cooperation between the partners and identify and
investigate management risks as soon as possible. In SemaGrow, the following potential management risks have been
mainly foreseen, and corresponding contingency plans are suggested.

Page 28 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

Risk Probability Impact Mitigation and Contingency Plans

Management Risks

Monitoring the effort spent and regularly

comparing actual and planned achievements, the
management team will identify any slippage and
Critical Path Awareness. Within the ensure that any underestimations of effort are dealt
critical path a delay of a deliverable with as early as possible.
would result also in a delay of the Medium Low
following development, prototypes, In the unlikely event of delays or underestimated
tasks and work packages. effort remaining unnoticed and undealt with for
longer periods, the management team, in
consultation with the EC services, will appropriately
adjust the work plan and/or reallocate effort.

Underestimation of the required

Medium Medium As above.
effort.

Loss of key personnel and delays due Each partner is responsible for making sure that the
to re-hiring. Low Medium case of personnel turnover can be handled
adequately.

Beneficiary goes out of business or If possible, we will aim at finding a suitable

relevant unit of a beneficiary is shut replacement partner and rearrange the tasks within
down during the duration of the Low Medium the project in agreement with the project officer. If
project. this is not possible, a contract amendment will be
aimed for.

The initial project deliverables consist of analysis

and assessment reports and could be started to
work on by already available personnel. Major RTD
activities start after M03 of the project. It should
also be noted that SemaGrow draws on existing
solutions and software, in particular in the first
project year.
Late availability of personnel causing
Medium Medium In the unlikely event of delays in the availability of
delays in the initial project phase.
key personnel, the available personnel will
temporarily assume more responsibilities and
allocate more effort to SemaGrow than originally
planned, until the new personnel is available. There
is sufficient overlap in expertise both inside and
across the SemaGrow consortium members to
ensure that this can be achieved.

In the extremely unlikely event that organizations

such as DLO and the UN’s FAO are unable to
The worsening global financial
maintain their repositories on-line, SemaGrow will
situation distracts data providers
carry out its pilots over locally stored data provided
from providing their resources online Low High
by these organizations. The technologies will be
as money is fed into other important
developed and tested, but their actual deployment
areas
delayed until FAO and DLO reinstate their on-line
services.

Page 29 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

A considerable volume of relevant data is currently

freely available, and more is becoming available
every day.

SemaGrow fails to secure external Even in the extremely unlikely event that this trend
Low Low is reversed to the point where there is no relevant
data due to IPR or privacy issues
public data whatsoever, the data that consortium
members have direct access to and/or ownership
over (cf. Annex II) is adequate to satisfy the
project’s development and pilot needs.
Table 9: Management Risks

In SemaGrow, the following potential technical risks have been mainly foreseen, and corresponding contingency plans
are suggested.

Risk Probability Impact Mitigation and Contingency Plans

Technical Risks

In order to avoid misspecification of software

functionalities, SemaGrow will follow an iterative
development process and involve stakeholders in all stages
Failure to meet user of the development.
requirements. The software
Low High In the unlikely event that the drafted requirements turn
functionalities do not meet
user requirements. out to be unsatisfiable within project scope, the
requirements deliverable will be updated, providing
detailed explanations for the failure to meet the original
requirements.

SemaGrow will increase the expressivity of the extended

URI conventions in SemaGrow POWDER formalism, in order to capture more complex
data sources are not patterns. This will add overhead for the execution of the
Medium Low
amenable to POWDER regular expressions, but will only shift the performance
compression curve to a slightly more computationally expensive
position, without compromising its scalable shape.

New repositories will have to go through a (fully

The Dynamic Huffman coding automated) stage where initial frequencies are computed.
scheme envisaged for Domain-independent knowledge can also be used to
indexing sub-strings of URIs is High Low initialize repositories (e.g., http://www is frequent). This
excessively inefficient for new will have a slight impact on decoding efficiency, as the
repositories. initial decoding table has to be loaded, but with
appropriate caching this can be kept to a minimum.

Since SemaGrow relies on approximations to guarantee

efficiency, similar mechanisms will be used to guarantee
the graceful degradation of the query mapping methods
Ontology alignment fails to
when confronting difficult alignment situations.
identify usable mappings Medium Medium
Furthermore, advanced alignment evaluation methods will
between data sources
ensure that the user application is aware of these
approximations, and can request the manual inspection
and correction of the mapping model.

Page 30 of 31
 D1.4.3 Quality Assurance & Risk Assessment Plan FP7-ICT-2011.4.4

The projection model and parameters will be continuously

monitored and refined by comparing projections with
Projected data using for
subsequent data made available during the project's
rigorous testing proves to be Medium Low
lifetime. This will provide us with high-quality model and
unrealistic
parameters by project's end, as well as a clear idea about
their true accuracy.

Consulting effort is foreseen for the scientific and technical

director (NCSR-D) to assist user partners in forging
requirements that can be met within the scope of the
User requirements are too project.
ambitious or beyond project Low High In the unlikely event that the drafted requirements turn
scope out to be unsatisfiable within project scope, the
requirements deliverable will be updated, providing
detailed explanations for the failure to meet the original
requirements.

Early RTD successes indicate

The work plan foresees overlapping
that even more ambitious
Medium Medium specification/development/evaluation cycles, providing
user requirements could be
the opportunity for the refinement of user requirements.
met

System architecture will be based on open protocols to

achieve maximum flexibility.
Integration of the SemaGrow In the unlikely event that some of the SemaGrow tools
tools may prove too difficult Medium High cannot be integrated, they will be delivered as stand-alone
for the project's resources. tools. The overall system will be accordingly amended in
order to provide the functionality in the absence of these
tools.

Risk of 3rd parties publishing

SemaGrow will welcome the opportunity for cross-
similar results as SemaGrow,
Low Low fertilization and result sharing and will divert resources to
for instance similar open-
more ambitious advancements.
source tools.

SemaGrow develops foundational technologies that can

New policies by new
be applied on a variety of fields and applications. In the
governments around the use
unlikely event that new policies void the current
of ICT and research impact Low High
application domain, or open up significant opportunities in
SemaGrow either as an
a different field, the project’s exploitation plan will be
opportunity or threat.
accordingly updated or extended.

SemaGrow will need to

respond to changes in the
SemaGrow develops foundational technologies that are
European programme such as Low Low
not tied to any particular standard and schema.
amendments to metadata
standards and mapping
Table 10: Technical Risks

Page 31 of 31