This project has received funding from Horizon 2020, European Union’s
Framework Programme for Research and Innovation, under grant agreement
No. 653355
Deliverable D1.2 Project Quality Assurance Manual
Work Package 1 Project Management
FORENSOR Project
Grant Agreement No. 653355
Call H2020-FCT-2014-2015 “Fight against Crime and terrorism”
Topic FCT-05-2014 “Law enforcement capabilities topic 1: Develop novel monitoring systems and
miniaturised sensors that improve Law Enforcement Agencies' evidence- gathering abilities”
Start date of the project: 1 September 2015
Duration of the project: 36 months
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 2 of 32
Disclaimer
This document contains material, which is the copyright of certain FORENSOR contractors, and
may not be reproduced or copied without permission. All FORENSOR consortium partners have
agreed to the full publication of this document. The commercial use of any information contained
in this document may require a license from the proprietor of that information. The reproduction
of this document or of parts of it requires an agreement with the proprietor of that information.
The document must be referenced if used in a publication.
The FORENSOR consortium consists of the following partners.
No. Name Short Name Country
1 ETHNIKO KENTRO EREVNAS KAI TECHNOLOGIKIS ANAPTYXIS CERTH GR
2 JCP-CONNECT SAS JCP-C FR
3 STMICROELECTRONICS SRL STM IT
4 FONDAZIONE BRUNO KESSLER FBK IT
5 EMZA VISUAL SENSE LTD EMZA IL
6 SYNELIXIS LYSEIS PLIROFORIKIS AUTOMATISMOU & TILEPIKOINONION MONOPROSOPI EPE
SYNELIXIS GR
7 VRIJE UNIVERSITEIT BRUSSEL VUB BE
8 ALMAVIVA - THE ITALIAN INNOVATION COMPANY SPA ALMAVIVA IT
9 VISIONWARE-SISTEMAS DE INFORMACAO SA VISIONWARE PT
10 VALENCIA LOCAL POLICE PLV ES
11 POLÍCIA JUDICIÁRIA (MINISTÉRIO DA JUSTIÇA) MJ PT
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 3 of 32
Document Information
Project short name and number FORENSOR (653355)
Work package WP1
Number D1.2
Title Project Quality Assurance Manual
Responsible beneficiary CERTH
Involved beneficiaries JCP-C, SYN
Type1 R
Dissemination level2 PU
Contractual date of delivery 30/09/2015
Last update 30/09/2015
1 Types. R: Document, report (excluding the periodic and final reports); DEM: Demonstrator, pilot, prototype, plan designs; DEC: Websites, patents filing, press & media actions, videos, etc.; OTHER: Software, technical diagram, etc. 2 Dissemination levels. PU: Public, fully open, e.g. web; CO: Confidential, restricted under conditions set out in Model Grant Agreement; CI: Classified, information as referred to in Commission Decision 2001/844/EC.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 4 of 32
Document History
Version Date Status Authors,
Reviewers Description
v 0.1 08/09/2015 Template CERTH Project deliverable template.
v 0.2 11/09/2015 Draft CERTH Table of contents and document structure.
v 0.3 18/09/2015 Draft CERTH First draft of the document.
v 0.4 23/09/2015 Draft SYNELIXIS, FBK Internal review comments and feedback.
v 1.0 30/09/2015 Final CERTH Final document for submission.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 5 of 32
Acronyms and Abbreviations
Acronym/Abbreviation Description
AP Action Point
CA Consortium Agreement
CV Curriculum Vitae
DMS Document Management System
DoA Description of Action
Dx.y Deliverable x.y; ‘x’ is the number of the WP where the deliverable belongs and ‘y’ is the number of the deliverable.
FORENSOR FOREnsic evidence gathering autonomous seNSOR
GA Grant Agreement
KOM Kickoff Meeting
KPI Key Performance Indicator
LVS Layout Vs Schematic
PC Project Coordinator
PMC Project Management Committee
PSC Project Steering Committee
PTM Project Technical Manager
ToC Table of Contents
WP Work Package
WPL Work Package Leader
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 6 of 32
Contents
1 Introduction ........................................................................................................................... 12
2 FORENSOR Project Management Context ............................................................................ 12
2.1 Quality Manager ............................................................................................................ 13
2.1.1 Short CV of FORENSOR Quality Manager Dr Nicholas Vretos ............................... 14
2.2 Risk Manager ................................................................................................................. 14
2.2.1 Short CV of FORENSOR Risk Manager Mr Roman Kaurson ................................... 15
3 Quality Assurance Strategy ................................................................................................... 15
3.1 Legal and Ethical Considerations ................................................................................... 16
3.2 Quality Assurance Tools ................................................................................................ 16
3.2.1 Supporting Documents .......................................................................................... 16
3.2.2 Project Templates .................................................................................................. 16
3.2.3 Quality Dashboard ................................................................................................. 17
3.2.4 Detailed Task Work plans (DTWs) ......................................................................... 20
3.2.5 Document Management System (DMS) ................................................................ 21
3.3 Quality Assurance Processes ......................................................................................... 21
3.3.1 Quality Evaluation Process .................................................................................... 21
3.3.2 Deliverables Review and Approval Procedure ...................................................... 21
3.3.3 External Advisory Board ........................................................................................ 24
4 Software Quality Assurance .................................................................................................. 24
4.1 Generic Software Development Guidelines .................................................................. 25
4.1.1 Least Privilege Principle ......................................................................................... 25
4.1.2 The Simplicity Principle.......................................................................................... 25
4.2 Software Development Management ........................................................................... 25
4.2.1 Separation of Duties .............................................................................................. 26
4.2.2 Configuration Management .................................................................................. 26
4.2.3 Review of Requested Changes .............................................................................. 26
4.3 Code Development Practices ........................................................................................ 26
4.3.1 Be Defensive .......................................................................................................... 26
4.3.2 Inter-process Communication ............................................................................... 26
4.3.3 Perform Data Integrity Checks .............................................................................. 26
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 7 of 32
4.3.4 Checksums ............................................................................................................. 27
4.3.5 Buffer Overflows .................................................................................................... 27
4.3.6 Fail-Safe ................................................................................................................. 27
4.3.7 Error Handling........................................................................................................ 27
4.3.8 Redundant Code .................................................................................................... 27
4.3.9 Data Hiding ............................................................................................................ 28
4.3.10 Backdoors .............................................................................................................. 28
4.3.11 Logging ................................................................................................................... 28
4.4 Code Management and Versioning ............................................................................... 29
5 Hardware Quality Assurance ................................................................................................. 29
5.1 Hardware Development Guidelines .............................................................................. 30
5.1.1 The Simplicity Principle.......................................................................................... 30
5.2 Hardware Development Management ......................................................................... 30
5.3 Hardware Development Practices ................................................................................. 30
5.3.1 Layout Vs Schematic (LVS) ..................................................................................... 30
5.3.2 Monte Carlo Simulation......................................................................................... 30
5.3.3 Post-Layout Simulation .......................................................................................... 31
5.3.4 Built-In Test............................................................................................................ 31
5.3.5 Redundancy ........................................................................................................... 31
5.3.6 Design for reuse ..................................................................................................... 31
6 Risk Management .................................................................................................................. 31
7 References ............................................................................................................................. 32
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 8 of 32
List of Figures
Figure 1: Project management structure and procedures in a nutshell. ...................................... 13
Figure 2: FORENSOR Presentation Template. ............................................................................... 17
Figure 3: FORENSOR Deliverables and Milestones Worksheet featuring the ‘Explore’ button
provided by Google Sheets (on the right). .................................................................................... 18
Figure 4: FORESNOR Action Points Worksheet. ............................................................................ 19
Figure 5: FORENSOR Effort Worksheet. ........................................................................................ 20
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 9 of 32
List of Tables
Table 1: Deliverables review and approval procedure. ................................................................. 22
Table 2: Indicative Deliverable Review Checklist. ......................................................................... 22
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 10 of 32
Executive Summary
Task 1.2 “Project Quality and Risk Management” (Leader: CERTH, Contributors: JCP-C, SYNELIXIS)
of WP1 “Project Management” is in essence a monitoring loop running throughout the lifetime of
the FORENSOR project evaluating the quality of work and deliverables and assessing internal and
external risks. This deliverable – a quality assurance manual as we call it – along with D1.3 “Project
Risk Management Plan” (M3) which delves with risk management, set the guidelines for the
aforementioned monitoring loop. It must be noted, though, that any rules and regulations
presented within this Project Quality Assurance Manual are supplementary to the Consortium
Agreement as well as the Grant Agreement.
Since Quality Assurance (as well as Risk Management) are parts of the overall project
management process a brief overview of the FORENSOR management context is initially provided
in this document. The overall Project Management structure of FORENSOR is presented and
detailed descriptions of the Quality and Risk Management roles are provided. The role of Quality
Manager has been assigned by the Project Steering Committee – during the project kick-off
meeting which took place on 2-3 September 2015 in Thessaloniki, Greece – to Dr Nicholas Vretos
(CERTH) while the role of Risk Manager has been assigned to Mr Roman Kaurson (JCP-C). Short
CVs of both Dr Vretos and Mr Kaurson are provided.
FORENSOR quality assurance strategy can be summarized in the following commitment: “The
FORENSOR Consortium recognises that dedication to quality is vital to the FORENSOR Project
mission and essential for delivering consistent results”. Core quality assurance objectives are
quality work and deliverables and keeping project in track (in line with DoA). Moreover,
FORENSOR Consortium commits that all project activities will be carried out in compliance with
established ethical principles and the applicable law.
In his effort to achieve quality assurance objectives, the FORENSOR Quality Manager will have in
hand a number of quality assurance tools and processes, namely:
Quality assurance tools
o Supporting Documents, like the CA, DoA, GA and relevant project deliverables).
o Templates.
o Quality Dashboard consisting of a KPIs, a Deliverables and Milestones, an APs, and
a PMs Worksheet.
o Detailed Task Work plans (DTWs).
o Document Management System (DMS).
Quality assurance processes
o Quality evaluation process.
o Deliverables review procedure.
o Help of the External Advisory Board (EAB).
Moreover, the Quality Manager must ensure that software development in FORENSOR follows
the specific guidelines that are presented in detail within this document. Being a multi-party and
multi-national project, FORENSOR will deliver software created by different companies and
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 11 of 32
research institutions. This software needs to be integrated and in order to have the least amount
of issues as possible, it needs to have a well-managed lifecycle.
Accordingly, FORENSOR will deliver hardware that has to meet several requirements, provided
from different partners of the project. In this case, the hardware development needs well
controlled design steps to be done, in order to minimize errors that could heavily affect the design
phases, turning into a large delay in the manufacturing step. The Quality Manager must also
ensure that hardware development in FORENSOR follows the specific guidelines that are
presented in detail within this document.
The FORENSOR Consortium is aware that a variety of risks may impact project schedule and
project objectives, and may even lead to contractual issues. For this reason a Project Risk
Management Plan (D1.3) will be released in M3 of the project lifetime (30 November 2015) and
updated in M6 with SWOT analysis.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 12 of 32
1 Introduction Quality Assurance (as well as Risk Management) issues in FORENSOR are handled within the
second task of WP1 “Project Management”:
Task 1.2 Project Quality and Risk Management (Leader: CERTH, Contributors: JCP-C, SYNELIXIS)
This task is in essence a monitoring loop that will run throughout the lifetime of the project in
order to continuously:
evaluate the quality of work and deliverables;
assess internal and external risks.
Specifically, project progress in terms of timeline and quality will be periodically reviewed and
internal and external risks will be periodically monitored, identified and mitigated by suggesting
appropriate measures.
In order to better organise and keep track of the aforementioned monitoring processes two
respective deliverables are foreseen to be produced early in the project lifetime:
D1.2 “Project Quality Assurance Manual” (M1), the present deliverable, and
D1.3 “Project Risk Management Plan” (M3).
Since Quality Assurance (as well as Risk Management) are parts of the overall project
management process we will initially provide (in the next section) a brief overview of the
management context in FORENSOR focusing on the quality and risk related management roles.
Finally, it is important to note that any rules and regulations presented within this Project Quality
Assurance Manual are supplementary to the Consortium Agreement as well as the Grant
Agreement. Many items regulated there are NOT repeated here, but should be taken into
account.
2 FORENSOR Project Management Context FORENSOR is a project of considerable size while the FORESNOR consortium has a significant
number of partners in different domains (technical, legal, security), including a non-EU partner
(EMZA, Israel). Therefore, special attention is required with regards to project management in
order to ensure smooth running of the project, appropriateness with ethical constraints, technical
excellence and the achievement of stated goals.
Having this in mind, the FORENSOR consortium agreed on an unambiguous management
structure, which is simple but takes account of the complexity of a project of this size and
ambition. A detailed description of the FORENSOR management structure and procedures can be
of course found in the respective section of the project’s Description of Action (DoA Part B, Section
3.2). Here we provide a summary of the key aspects of this structure, especially those related to
quality and risk management, for the convenience of the reader.
In a nutshell, the project management structure of FORENSOR is as follows (see also Figure 1):
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 13 of 32
The WP technical groups ensure day-to-day WP work; each group is composed of the
technical representatives of all partners involved in the respective WP and chaired by the
respective WP Leader.
The Project Management Committee is the executive body of the project (under the
guidance of the Project Steering Committee); it is chaired by the Project Technical Leader.
The Project Steering Committee establishes the main lines of the project; it is chaired by
the Project Coordinator.
The General Assembly approves project budget and general annual objectives; it is
chaired by the Project Coordinator.
General Assembly
All Partners
WP9 Dissemination and ExploitationTechnical Group
External advisory boards (EAB, EMB)
Security Advisory BoardProject Security Officer
Project Management CommitteeCoordinator, WP Leaders
- IPR Manager- Quality Manager
-Risks Manager- Business Development Manager
- Ethical Manager
Steering Committee
All Partners (Technical)
Pro
ject
Off
ice
Leg
al,
Fin
an
cia
l an
d a
dm
inis
tra
tive
su
pp
ort
WP2Technical
Group
WP3Technical
Group
WP4Technical
Group
WP5Technical
Group
WP6Technical
Group
WP7Technical
Group
WP8Technical
Group
Figure 1: Project management structure and procedures in a nutshell.
In the centre of the above figure one can see the two management roles that are related to the
work that will be conducted within Task 1.2 “Project Quality and Risk Management” of the
FORENSOR project:
Quality Manager
Risk Manager
2.1 Quality Manager The role of the Quality Manager is to keep FORENSOR focused on its objectives of producing high
quality technical outputs and adopting standard-based approaches. In the line of this Project
Quality Assurance Manual, the Quality Manager will be asked periodically to review technical
progress in order to ensure that the project remains innovative, driven by requirements of end-
users, open to collaborations and to market needs and forward looking. Fulfilment of those
requirements will ensure that FORENSOR is producing an outcome of high technical quality.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 14 of 32
The Quality Manager is responsible for the quality of all project deliverables; details on internal
review and approval procedures of the FORENSOR deliverables are given later on. However,
quality shall not only be addressed for the deliverables but also for the project process itself. Thus
management process and developments of the project will be submitted to periodical reviewing
by the Quality Manager with respect to:
Staying focused on project objectives of focusing on end-user requirements, high quality
technical outputs, market proximity and standard-based approaches.
Adequacy of the project management plan and how the work performed complies with it
including IPR management and results dissemination.
How well the project processes are synchronized and inter-linked.
Identification and evaluation of activities and results that would adversely affect the
achievement of the project objectives.
Process improvement in the project by identifying deviations and changes.
During the Kick-off Meeting of the FORENSOR project – which took place on 2-3 September 2015
in Thessaloniki, Greece – the Project Steering Committee assigned the role of Quality Manager for
the FORENSOR project to Dr Nicholas Vretos (CERTH). A short curriculum vitae of Dr Vretos is
provided below.
2.1.1 Short CV of FORENSOR Quality Manager Dr Nicholas Vretos Dr Nicholas Vretos obtained the degree of BSc in Computer Science from the University Pierre et
Marie Curie (Paris VI) in 2002 and his Ph.D. from the Aristotle University of Thessaloniki in 2012.
During elaboration of his thesis, he taught as assistant and worked as a research assistant in
Artificial Intelligence and Information Analysis Laboratory. He has worked in 9 European projects
as a researcher, technical manager, quality manager, work package leader and other. He has
published more than 25 articles in scientific journals and conference proceedings and a book
chapter. He is a member of the IEEE and has committed as a reviewer for several journals and
conferences in the field of image, video and 3D information processing. His main interests are in
image and video processing, semantic analysis, neural networks and 3D data processing.
2.2 Risk Manager Having in mind that risk may have an impact on the project schedule and objectives, and finally
may lead to contractual issues, the role of Risk Manager has been foreseen. The Risk Manager will
be asked periodically to review project progress as well as the risk items table to ensure that
FORENSOR remains in line with its technical objectives. Finally, he will be also in charge of keeping
up-to-date the “Project Risk Management Plan” (D1.3) that will be produced by WP1 on M3 of
the project lifetime.
During the Kick-off Meeting of the FORENSOR project – which took place on 2-3 September 2015
in Thessaloniki, Greece – the Project Steering Committee assigned the role of Risk Manager for
the FORENSOR project to Mr Roman Kaurson (JCP-C). A short curriculum vitae of Mr Kaurson is
provided below.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 15 of 32
2.2.1 Short CV of FORENSOR Risk Manager Mr Roman Kaurson Roman KAURSON has 12 years of project management experience and led a number R&D projects
in the different ICT domains. Before joining JCP-C he obtained experience from industrial and
research domain, worked in electronics company, where managed group of 13 engineers. Later
he moved to Orbis Systems Oy to Project Manager position where he developed and set-up
project management system and he was responsible for R&D projects in machine vision, RF and
cable. After joining JCP-Connect in 2010, he coordinated several FP7 projects (e.g. FP7
ACCORDANCE STREP, FP7 GameArch SA) and contributed to number of projects as a Partner (e.g.
FP7 I-SEARCH STREP, FP7 OASE IP). He holds MSc degree in Telecommunications from Technical
University of Tallinn, Estonia.
3 Quality Assurance Strategy The FORENSOR Consortium recognises that one important factor in assuring quality is a constant
re-examination of our own work against the needs of planned objectives. In this way, we can
assure ourselves that we are maintaining appropriate standards and also demonstrate
accountability to the Commission and the public in general of our work. The FORENSOR
Consortium agrees to the following statement:
The FORENSOR Consortium recognises that dedication to quality is vital to
the FORENSOR Project mission and essential for delivering consistent results.
The core quality assurance objectives in FORENSOR are:
Ensuring quality of the produced deliverables.
Ensuring quality of the internal deliveries and processes.
Ensuring that the project remains in line with the Description of Action at all times.
Those objectives will be achieved – by the responsible person, i.e. the Quality Manager – with the
help of a number of tools and processes that are described below.
Particular attention will be given to the documentation supporting application and adaptation
software, and development and integration tools, as these are the basis for future exploitation.
Moreover, in order to limit any duplication of information and to facilitate an efficient
communication process by both real and virtual channels, the distribution of all relevant project
information will be channelled to one key person for each partner. This person will act as partner
switchboard, thus ensuring that the concerned person within its organisation is reached by the
communication.
Finally, it should be noted that all Quality Assurance efforts described here are meant to be
performed in parallel with – rather than at the expense of – Quality Assurance activities set out
by respective Quality and Compliance Systems that individual partners use.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 16 of 32
3.1 Legal and Ethical Considerations The FORENSOR Consortium is committed to ensuring that all actions and activities within the
FORENSOR Project will be carried out in compliance with:
(i) established ethical principles including the highest standards of research integrity – as
set out, for instance, in the European Code of Conduct for Research Integrity [1] — and
including, in particular, avoiding fabrication, falsification, plagiarism or other research
misconduct, and
(ii) applicable international, EU and national law.
3.2 Quality Assurance Tools
3.2.1 Supporting Documents Besides this Project Quality Assurance Manual, the Quality Manager will also have at his disposal
and will be able to consult a series of other documents that will act as supplementary sources of
information:
The Consortium Agreement (CA) which legally defines all aspects of cooperation between
the Partners of the FORENSOR Consortium.
The Description of Action (DoA) Part A and Part B which provide a complete and detailed
description of the contractually agreed action (project and work plan).
The Grant Agreement (GA) which sets out the rights and obligations and the terms and
conditions applicable to the grant awarded to the beneficiaries for implementing the
action.
Relevant project deliverables, e.g. D1.1 “Project Management Manual” (M1) and D1.3
“Project Risk Management Plan” (M3), as well as any other project deliverable that might
be useful to the Quality Manager, e.g. all deliverables of WP1, WP2 reports etc.
3.2.2 Project Templates Based on the belief that consistency is a key aspect of quality, the FORENSOR Consortium will
devise and use a series of uniform and universal templates for the various project aspects. Up to
the moment when this report was written the following templates have been prepared and
disseminated to the project partners:
FORENSOR Presentation Template (Figure 2). A template for all internal and external
presentations that are related to the FORENSOR project, ensuring a uniform appearance
and bearing the logo of the European Commission and of the FORENSOR project and all
necessary disclaimers.
FORENSOR Deliverable Template. A template for all report deliverables of the project,
ensuring a uniform appearance and bearing the logo of the European Commission and of
the FORENSOR project and all necessary disclaimers. The reader can get a good idea of
what this template is by going through the present document. The template defines a
series of quality controls for project deliverables and provides a series of features that
enhance quality of the documents such as:
o a proper front page with all the necessary logos and project/document
information,
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 17 of 32
o appropriate headers and footers providing useful document and document
navigation information,
o all necessary disclaimers and copyright information,
o a concise overview of all document information,
o a table presenting all document history (changes) from initial draft to final
document,
o an acronyms and abbreviations table,
o table of contents and lists of figures and tables,
o an executive summary of the document, and
o a uniform formatting template.
Other templates are currently under way, e.g. a resources and effort (PMs) allocation template,
and more may be created in due time as needed.
Figure 2: FORENSOR Presentation Template.
3.2.3 Quality Dashboard The FORENSOR Quality Manager will have at his disposal a Quality Dashboard for the real time,
online monitoring of project progress, consisting of a series of Worksheets depicting the actual
status of various aspects of project work in comparison to planned and/or contractually agreed
progress. The various Worksheets are described below but as they are all created using Google
Sheets they share a couple of common features which are expected to be useful to the Quality
Manager:
Ability to cooperatively and simultaneously edit the Worksheet from anywhere, with any
authorised entity.
Explore button (Figure 3, on the right side of the image). A feature allowing the automatic,
on the spot creation of various diagrams giving insight to the Worksheet data.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 18 of 32
Figure 3: FORENSOR Deliverables and Milestones Worksheet featuring the ‘Explore’ button provided by Google Sheets (on the right).
3.2.3.1 Key Performance Indicators (KPIs) Worksheet
A basis for measuring the quality of the conducted work in FORENSOR are the Key Performance
Indicators specified throughout the project DoA. A special Worksheet has been devised for the
continuous monitoring of all project KPIs. The Quality Manager will have access to the KPIs
Worksheet in order to follow close the project progress. The KPIs Worksheet currently
incorporates the following information: Name (of the KPI), Current Value, Target Value,
Responsible Beneficiary (Partner), and Comments.
3.2.3.2 Deliverables and Milestones Worksheet
A Worksheet containing all project deliverables and milestones has already been created giving
full insight to all aspects of deliverable preparation, review (internal) and submission (Figure 3).
The Quality Manager will be able to organise and sort the deliverables and milestones virtually
any way he sees fit in order to gain the best overview of how project work is progressing. The
Deliverables and Milestones Worksheet currently incorporates the following information:
Number (ID), Title, WP, Leader, Internal Reviewer #1, Internal Reviewer #2, Type, Dissemination
Level, Due Date (Project Month), Due Date (calendar date), Review Date, Submitted (date), and
Status.
3.2.3.3 Action Points Worksheet
FORENSOR foresees keeping of meeting minutes for all physical or virtual (audioconferences,
teleconferences, etc.) meetings of the project. In fact, the collaborative, real time, online keeping
of minutes has been selected as the preferred method (using Google Docs) and has been already
successfully applied at the kick-off and at one audioconference that has been conducted up to
now.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 19 of 32
The minutes of each project meeting usually contain Action Points (APs), concrete actions that
have to be performed by one or more Partners in a specific time period. A specific Worksheet has
been created for all APs of the project giving the ability to the Quality Manager (among other
authorised people) to have a real time, online, clear, fine-grained view of how project work is
progressing (Figure 4). Again here the user is able to organise and sort APs virtually any way he
likes in order to gain best insight. APs Worksheet currently incorporates the following
information: ID, Description, Responsible (partner), Deadline, and Status.
Figure 4: FORESNOR Action Points Worksheet.
3.2.3.4 Effort Worksheet
A generic Worksheet depicting all project effort per partner, WP, Task, etc. has been created. It is
intended to be used mainly by the Project Coordinator but the Quality Manager will also be able
to access this Worksheet (in consultation with the PC) in order to assess if project resources are
properly used.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 20 of 32
Figure 5: FORENSOR Effort Worksheet.
3.2.4 Detailed Task Work plans (DTWs) The basic building block of the FORENSOR work plan is the Task. A number of specific Tasks forms
a WP and the nine WPs of the project form the whole work plan. For this reason it is very
important, quality wise, to have a mechanism that facilitates smooth, coordinated, and successful
execution of Tasks.
FORENSOR adopts such a mechanism, namely the Detailed Task Work plan (DTW). DTW is an
internal document describing in detail and in a predefined format a specific Task. It’s a
disambiguation mechanism that will be used to eliminate the risk of different understanding of
the work to be done, among partners involved in the specific Task.
Α DTW should contain at least following information:
Partners PM allocation
Objectives and description of the Task
Identification of sub-tasks
Risks and/or issues
Requests for contribution
Contribution of the Task to the Deliverable(s) it feeds
Initial ToC of the respective Deliverable(s)
The creation of a DTW will be the first action of every starting Task in FORENSOR. DTW creation
and distribution to involved Partners is a responsibility of the Task Leader. A template for DTW is
provided in D1.1 “Project Management Manual”.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 21 of 32
3.2.5 Document Management System (DMS) A full scale Document Management System (DMS) will be used by the FORENSOR Consortium for
management of all project deliverables. The DMS will be described in D1.1 “Project Management
Manual” (M1).
3.3 Quality Assurance Processes The following processes will be employed by the Quality Manager and the Consortium in general
in order to evaluate quality of work and deliverables and assess internal and external risks.
3.3.1 Quality Evaluation Process Besides the high level supervision of the Quality Manager, day to day work progress will be
constantly monitored and supervised by the Work Package Leaders (WPLs) and the Technical
Manager of the Project. The Quality and Technical Manager will be frequently contacting each
other and when needed evaluation meetings will be carried out to evaluate the work and progress
of the project.
As mentioned earlier, a basis for measuring the quality of the conducted work in FORENSOR are
the Key Performance Indicators specified throughout the project DoA. Furthermore, the
publication of achieved results in journals as well as European and international conferences will
be taken as a measure of success for the involved universities and research teams. The mechanism
for reviewing progress against identified success criteria has been described earlier (section
3.2.3.1).
Finally, as part of the evaluation process, we will apply a risk management approach assessing risk
in technical, operational and human resources, the probability that they happen and the impact
they will have in the project. Risks will be reported in the management reports as well as the
actions to reduce the threats and to solve the situations when these threats materialise. A brief
introduction to the FORENSOR Risk Management Plan is given in section 5 of the present
document. However Risk Management issues will be analysed in depth within D1.3 “Project Risk
Management Plan” (M3).
The present document, Project Quality Assurance Manual will be peer reviewed by the
Coordinator prior to approval and will be kept up to date by the Quality Manager throughout the
project lifetime. Every person working on FORENSOR in every partner organisation will be
required to have access to, and to have read, the Project Quality Assurance Manual.
3.3.2 Deliverables Review and Approval Procedure Project deliverables consist in reports, white papers, documents, laboratory models,
demonstrations, prototypes, field trials, etc. The Document Editor of a deliverable is usually the
Partner responsible for the specific task where the deliverable belongs. The respective WPL first
approves a deliverable (if needed), then appointed reviewers, followed by the Technical Manager
(in cases of technical deliverables) and finally the Project Coordinator approves and submits the
deliverable (Table 1). The reviewers are appointed by the Quality Manager and approved by the
Project Management Committee (PMC), and are usually internal to the project, however
preferably not involved directly in the production of the specific deliverable under review.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 22 of 32
Table 1: Deliverables review and approval procedure.
Step When3 Who What
#1 42 (6
weeks) Document
Editor
Submits Table of Contents (ToC), sections contents in bullet form with brief explanation, and writing allocation (who is writing each section) for the deliverable (to WPL, PTM, PSC, PMC).
#2 39 WPL, PTM, PSC, PMC
Provide comments/ feedback.
#3 21 (3
weeks) Document
Editor Submits final draft of the deliverable (to the Quality Manager, PSC, and PMC).
#4 20 Quality
Manager Sends final draft of the deliverable to the Internal Reviewers.
#5 14 (2
weeks) Internal
Reviewers Provide comments/ feedback.
#6 7 (1
week) Document
Editor Submits final version of the deliverable (to the Project Coordinator).
#7 1 Project
Coordinator Approves and uploads the deliverable to the EC services.
An indicative Deliverable Review Checklist is provided below.
Table 2: Indicative Deliverable Review Checklist.
Aspect Item Yes No Comments
Presentation
The document structure is consistent with the format and content specified in the project plan.
Each page has been visually inspected for correct page numbers.
Each page has been visually inspected for correct spacing.
Each page has been visually inspected for appropriate page breaks (no headings or subheadings at the end of a page without following text).
Footnotes or endnotes are numbered in sequence.
Body text matches standard font, color, size styles.
Headings match standard font, color, size styles.
Table of Contents
The table of contents reflects correct page numbers and section names.
Each section of the document that should appear in the Table of Contents, does appear.
The sequence of numbers in the Table of Contents is correct.
The format of each entry in the Table of Contents is correct (for example, level two entries appear in
3 This column shows the days before the contractual delivery date.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 23 of 32
accordance with the formatting standards for level two entries).
Appendices are identified in sequence by letter or number.
Body of Document
The document text is concise and clear.
Spelling and grammar check are complete.
The writing style and grammar are of high quality.
The document uses consistent tense.
The language is appropriate for the audience.
Sentences use simple structures - there are no complex and confusing sentences.
The transitions from one section to another are smooth.
Unnecessary information and words are eliminated.
Each acronym or abbreviation is introduced the first time it is used.
The document adheres to any other special items defined in the project's standards for readability.
Consistency
Names and terminology used consistently throughout the document (e.g., proper nouns capitalized).
All charts, graphs, and diagrams are labeled accurately and consistently.
Internal cross-references within the document are accurate.
All hyperlinks have been tested and work.
References to other existing documents are valid.
The material is consistent with other existing documents.
Content
The purpose of the document is clear and complete.
The scope of the document is accurate and complete.
The document satisfies the defined goals and objectives.
The document flow and structure are logical for the reader to follow.
The potential impact on future deliverables has been considered.
The material appears to be technically accurate.
The material appears to be feasible.
The potential resources cost and/or schedule impact have been considered, where appropriate.
Risk factors have been considered, where appropriate.
All sensitive or proprietary data has been redacted or masked.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 24 of 32
All personal data, privacy, and/or other details are specified.
3.3.3 External Advisory Board All quality assurance procedures described up to now are mostly internal. Nevertheless, quality
assurance best practices require also the existence of external reviewing and quality assessment
processes in order to fully ensure objectivity. For this reason we have foreseen the creation of an
External Advisory Board (EAB). EAB is a group of experts and organisations that are external to
the FORENSOR Consortium.
Activities of the FORENSOR consortium will be scrutinized by the external Advisory Board
(involving, amongst others, ethical/legal experts). For example, amicable redress mechanisms,
such as referral to the EAB, will be offered to participants in research and any incidental findings
will be immediately referred to the EAB (among other, internal, entities).
Moreover, the participation of EAB (involving, amongst others, external end-user organisations)
in the project will improve quality of the project outcomes through helping to articulate demands
in user terms, and facilitate the development and validation of an efficient forensic evidence
gathering sensor. Specifically, EAB will be mainly involved in the definition of FORENSOR
specifications (Task 3.1) as well as in the test and evaluation of the system prototype, through
field tests (Task 8.4). It will also be asked to freely contribute to other project activities, for
example by reading documents delivered by the project, giving suggestions and indications to the
FORENSOR Consortium and providing the Consortium itself with operational knowledge about
the issues implied by the FORENSOR project.
4 Software Quality Assurance Being a multi-party and multi-national project, FORENSOR will deliver software created by
different companies and research institutions. This software needs to be integrated and in order
to have the least amount of issues as possible, there needs to be a common software
development methodology. In this regard, software development must follow a well-managed
lifecycle, so as to keep the project moving in the right direction. The adoption of a suitable
development methodology cannot be overlooked. FORENSOR’s software products will adhere to
the following lifecycle phases:
Definition and analysis of requirements: this phase analyses the end-user needs and
produces a set of requirements for the targeting system, focusing on functions and
operations that are expected to be supported. Requirements are broken up into
functional and non-functional. A good way to document functional requirements is using
Use Cases, but documentation will not be limited to Use Cases. Non-functional
requirements describe performance and system-wide characteristics and they are
important to be gathered, as they have a major impact on the overall architecture, design
and performance.
System design: the objective of this phase is to transform the requirements into a
complete and detailed design and functional specification, describing how to deliver the
required functionality. An initial plan with all the allocated resources, timeframes and test
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 25 of 32
schedules should also be provided. All the documentation produced as a result of this
phase should be used as a reference for the actual code development.
Development: this is the phase where the real code takes place. It converts the technical
design into a complete information system. It includes acquiring and installing system
environments, creating and testing databases, preparing test procedures, coding and
compiling, refining programs.
Integration and testing: in this phase, all the pieces developed or acquired are put
together and checked for errors, bugs and interoperability. This phase can involve a
variety of testing types that include: unit testing, system testing, integration testing,
regression testing, user acceptance testing and performance testing.
Installation and deployment: this is the final stage of development, where the software
is put into production and becomes operational, supporting actual business processes.
4.1 Generic Software Development Guidelines This section provides a generic set of guidelines for software development within FORENSOR.
4.1.1 Least Privilege Principle Every program or piece of code produced by FORENSOR should operate using the least set of
privileges necessary to complete the job. This, among other, applies to:
• Access to objects within an application.
• Database access – use minimum rather than administrator privileges.
• Development environment – developers’ access to code is restricted to that required
to accomplish their tasks.
• Network access – disable any ports or services not required for the system’s
operation.
This principle should be applied on every object and not just on sensitive information.
4.1.2 The Simplicity Principle Software designs and the respective code development of FORENSOR should be kept as simple as
possible, without sacrificing security for simplicity. Simpler code tends to be of higher quality and
less prone to errors, for a number of reasons:
• Easier to get right.
• Easier to understand and analyse (so flaws are more easily identified).
• Easier to evolve and change.
• Tend to be smaller, so there is less to go wrong.
• Easier to test and debug.
• Easier to review by third party or code reviewers.
4.2 Software Development Management This section addresses administrative guidelines under which FORENSOR software is designed,
coded, tested and maintained.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 26 of 32
4.2.1 Separation of Duties The pool of FORENSOR programmers should be assigned with a well-defined and separate set of
duties, so as each one, individually, is more focused and more productive. In FORENSOR
separation of duties includes:
• Provide to developers access only to that portion of the code for which he/she is
responsible.
• Split the software development tasks in modules or pieces and allocate them to
separate programmers.
• There should be a clear separation between developers and testers, with the former
not being responsible for the actual testing of the software.
4.2.2 Configuration Management The source code of FORENSOR should be stored centrally and access to it should be personalised
and restricted to authorised individuals. Any source changes should be authorized and done for
specific and well understood and documented reasons. Through the software configuration
management, any code change of FORENSOR will be traceable and documented.
4.2.3 Review of Requested Changes Any changes requested during the development phase of FORENSOR, should be carefully
reviewed to examine all the implications, especially those related with interfaces between
software modules. All changes have to be properly authorised and approved and all this activity
has to be logged for review purposes.
4.3 Code Development Practices This section identifies certain practices that will be followed by FORENSOR programmers during
code development.
4.3.1 Be Defensive FORENSOR will consider all the information carried by objects as private, unless it is explicitly set
to public. There is no need to unnecessarily expose functionality or information, if this is not really
needed or if this is not part of the object’s public interface.
4.3.2 Inter-process Communication Inter-process communication should be scrutinised to identify any information leakage.
Procedures and functions would typically allow the exchange of information among them for
further processing. Programmers should carefully examine the directions that this information
flows and the subjects that have access to this information to avoid any unauthorised or
unforeseen flow of information.
4.3.3 Perform Data Integrity Checks Whenever data is being inputted by the user, transmitted or restored from storage types, one
should perform integrity checks to make sure that the data is valid. Apart from the input validation
mechanisms, the development should also include integrity checks from and to the source and
destination of the data flow. Nothing should be assumed and nothing should be taken for granted.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 27 of 32
4.3.4 Checksums Checksum are typically used to protect the integrity of the code. Fragments of code that handle
critical information should employee checksum mechanisms to guarantee that no code is planted
in an unauthorised manner. The checksum values are stored with the application. Each time a
code fragment is called the checksum is recomputed.
4.3.5 Buffer Overflows Buffer overflows can occur due to bad instructions and more specifically, when appropriate
checks are not enforced on the length of input data or data passed for further processing. Extra
data can slip into the system and be executed in privileged mode, thus having access to more
system resources. Languages that do not perform run-time boundary checks on buffers/arrays,
like C/C++ or assembly, are more susceptible to this kind of issues compared to languages that
can either throw an exception (like Java or .Net Languages) or resize arrays before processing (like
Perl).
4.3.6 Fail-Safe Many circumstances during the system’s operation are unpredictable, and cannot be foreseen.
As a result, they are hard to plan for or have the necessary code in place to deal with them. Such
unpredictable situations should fall into more general categories of failures. This way the
developer does not have to account for every single case of system failure. A fail-safe mechanism
should brink the system to a well-known state in case of an unpredicted exception or error.
4.3.7 Error Handling Proper error handling is a major issue in development practices. Thus, in FORENSOR proper error
handling will ensure that the system will not crash under any circumstances and that no sensitive
information is revealed. This includes information about the code, the OS used, the make and
version of the database etc.
When designing and implementing the error handling mechanism, one should keep in mind that
the program should check for all possible error codes and exceptions and explicitly handle each
case. Furthermore, the application should be in a constant state of “anticipate an error”, even in
pieces of the code that “cannot go wrong”.
It is important that error messages do not convey any important or sensitive information to the
end-user. Error messages only have to inform the end-user that something has gone wrong or it
did not manage to perform the task it was asked to. The error message should tell the end-user
the type of error, but not any details about what caused the error or why. Typical error messages
are “Request Denied”, “Access is denied”, “You do not have permission to perform this task”, “An
error has occurred”, etc.
All errors should be recorded in detail in an error log. Specific details about the user accessing the
application, the time of the error, the possible cause of the error should be kept in the log.
4.3.8 Redundant Code Redundant code is typically the outcome of poor software design, and this is something that must
be avoided in FORENSOR. Eliminating redundancies makes the code more readable and auditable,
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 28 of 32
as it becomes simpler. Some of the practices that will be followed to eliminate redundant code
include the following:
• Break functionality into simple tasks, so that certain functions can be reused.
• Make appropriate use of object oriented techniques, where possible.
• Reuse objects. Care should be taken though, so that object reuse does not result in
any unexpected flow of information.
• Make sure that there is no more than one instance of the same or similar functions
that can otherwise be represented by a single function.
4.3.9 Data Hiding Data hiding is the ability of objects to shield variables from external access and it is essential,
especially for processes that handle sensitive data. In object-oriented programming languages
this can be achieved by appropriate use of the encapsulation. Using encapsulation, keeps the data
safe from outside interface and misuse. One way to think about encapsulation is as a protective
wrapper that prevents code and data from being arbitrarily accessed by other code defined
outside the wrapper.
4.3.10 Backdoors Although it is considered bad practice, backdoors are used during development to simplify certain
tasks. The backdoors are typically inserted to bypass processing stages, controls or security
mechanisms, when these are not required during development. Moreover, software hooks might
be inserted into code for testing or modification purposes. FORENSOR developers should refrain
from using these techniques, as it is not unlikely to forget to remove or disable any backdoors
after development. However, if backdoors are used during the development phase, they must all
be recorded and at the test phase each and every backdoor should be tested whether it is still
open, or if it has been fixed.
4.3.11 Logging FORENSOR recognizes that logging of system and user events and actions is essential for analysing
what happened and for what reason. A uniform logging mechanism will be utilized that provides
the ability to choose the type of information that is logged and the granularity of information held
for each log entry. As a general rule of thumb, all security critical operations and interactions
should be logged. Moreover, erroneous or invalid statuses should be written to a log. The types
of information that can be logged include the following:
• Error messages
• File access
• Application security violations
• Failed user authentication attempts
• Communication errors
• Unauthorised attempts to access services not supported by the system
Log entries should carry enough information to facilitate auditing, including event origins, the
time that the event occurred and the type of the event. A criticality flag can also be set based on
a predefined event classification, to further facilitate auditing.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 29 of 32
4.4 Code Management and Versioning FORENSOR has a subversion repository for the management and versioning of the source code.
Subversion (SVN) is one of the most popular software versioning and revision control systems
distributed under an open source license [2]. It has been chosen for FORENSOR project to provide
version control and backup facilities. SVN has many features and advantages in comparison to
other version control tools. Both directories and files are versionable in SVN. This means that
moving or renaming a directory is a first-class operation, files within the directory automatically
move with it and history is preserved correctly. SVN uses a database transaction analogy when a
user commits a change to the repository, making sure that either the entire change is successfully
committed or it’s aborted and rolled back. It also has excellent network support. It is very easy
and efficient to manage branching, merging and tagging with SVN. SVN provides true cross-
platform support. It is adopted by some well-known source code hosting websites such as Google
Code and SourceForge.
5 Hardware Quality Assurance FORENSOR will deliver hardware that has to meet several requirements, provided from different
partners of the project. In this case, the hardware development needs well-controlled design
steps to be done, in order to minimize errors that could heavily affect the design phases, turning
into a large delay in the manufacturing step. FORENSOR’s hardware development will adhere to
the following phases:
Definition of requirements: this phase analyses the overall functionality of the system
that will be defined both by the end-user needs and by the technological constraints. The
definition of main sensor parameters have a relevant impact on the final architecture of
the sensor as well as on the performance of the system which has to process data coming
from the output of the vision sensor. The analysis of a benchmark of images or video
extracted from the selected Use Cases will be essential to identify critical parameters and
main system requirements. An off-line processing of the acquired videos will be necessary
to emulate the final system performance taking into account the technological constraints
of the system, mainly related to the limited resource of energy and processing
capabilities.
Development: in this phase, the architecture of the hardware will be defined and divided
into functional blocks. For each functional block, input-output timing and voltage
specifications will be assigned as well as different operating modes. The most critical
blocks will be also equipped with additional electronics for test and debug purposes.
Manufacturing and testing: after the manufacturing phase, electrical and functional tests
will be conducted and experimental results will be compared with the simulated output.
If necessary, single blocks will be separately tested to identify potential bugs that need to
be corrected in a next design phase. To speed up the sensor test and debug phases,
dedicated input/output pads on the chip will be used. This is particularly important for
testing some critical hidden blocks.
Integration: the hardware will be integrated with the other components and the overall
functionality will be tested to be aligned with the simulated results. A specific attention
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 30 of 32
will be paid to the most power-hungry blocks in order to meet the low power
consumption requirements of the system. The interface between the vision sensor and
the embedded processor, core of the system, will be carefully analysed for improving the
communication among the different blocks of the system.
Deployment: in this last phase, the hardware will be produced according with the
FORENSOR activity plan.
5.1 Hardware Development Guidelines This section provides a generic set of guidelines for hardware development within FORENSOR.
5.1.1 The Simplicity Principle Each design phase should be kept as simple as possible for the following reasons:
• more robust;
• requires less electronics;
• occupies less silicon area;
• easier to be tested.
5.2 Hardware Development Management This section addresses administrative guidelines under which FORENSOR hardware is designed,
manufactured and tested.
• The responsibility of the entire sensor design phase will be assigned to one designer,
thus achieving a more reliable and a faster design;
• The hardware architecture will be divided into well-defined functional modules
(analogue, digital, mixed). Each module will be assigned to one designer, which will
be responsible for the specific task.
• Each designer, assigned to one block, will have access to the other modules of the
sensor to be interfaced to the block itself.
• The test of the sensor will be not necessarily assigned to one designer.
5.3 Hardware Development Practices This section identifies certain practices that will be followed by FORENSOR designers during
hardware development.
5.3.1 Layout Vs Schematic (LVS) LVS is typically used to verify the correct correspondence between the circuit diagram and the
physical representation. This will guarantee that the manufactured circuit will behave as the
simulated one.
5.3.2 Monte Carlo Simulation In order to guarantee a more robust design with respect to different working conditions, Monte
Carlo simulation will be used. This analysis is particularly useful in the vision sensor design in order
to estimate possible offsets or gain variations across the array due to transistor mismatches. In
case of critical situations, appropriated techniques will be taken into account to mitigate the issue.
Noise analysis will be also taken into account when necessary.
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 31 of 32
5.3.3 Post-Layout Simulation If available from the technology, a post layout simulation will be performed which is crucial for
these functional blocks which may have criticalities. In order to estimate and in case reduce the
contribution of parasitic elements in the circuit functionality. The iteration of more steps will be
needed for a circuit improvement.
5.3.4 Built-In Test Some additional blocks may be embedded into the architecture allowing built-in test capabilities.
By doing this, the final test activity will be easier and faster. This approach can be adopted on each
functional block of the architecture or at least on those blocks recognized as critical (analogue,
mixed analogue/digital).
5.3.5 Redundancy Some redundancy may be considered in chip design in order to by-pass potential bugs in some
functional blocks. However, this practice should be adopted only in specific modules that are
considered critical. In this case, multiplexers will be used to switch between one block to the
other.
5.3.6 Design for reuse This is a good practice in chip design. Some building blocks designed during the first chip
development may be re-used in the second chip as well. These blocks after being characterized
and validated, will become part of a custom low-power library of cells, available for future designs.
The main advantage is a significant reduction of the successive design phases.
6 Risk Management The FORENSOR Consortium is aware that a variety of risks may impact project schedule and
project objectives, and may even lead to contractual issues. For this reason the role of Risk
Manager has been foreseen as described in section 2.2.
The Risk Manager will periodically identify and monitor internal and external risks and suggest
appropriate measures. Moreover, the Project Risk Management Plan will be released in M3 of the
project lifetime (30 November 2015) and updated in M6 with SWOT analysis.
Internal risks can be due to a variety of reasons:
Technical, e.g. ambitious objective set.
Organizational, e.g. under-performing partner or partner leaving the project.
Executional, e.g. key milestone or critical deliverable delayed.
Communication issues between partners.
IPR.
In FORENSOR mitigation will be undertaken at the appropriate level in the project organisation:
WPL, PMC, PSC or General Assembly in accordance with the rules defined in the DoA (Part B) and
D1.3.
An initial list of the general risks already identified in the project with respective mitigation plans
has been already given for every specific work package in the DoA (Part B).
D1.2 Project Quality Assurance Manual
FORENSOR Project Page 32 of 32
A number of other issues related to Risk Management will be elaborated within D1.3, e.g.:
Risk Management strategy, methodology, responsibility, and monitoring.
Risk identification, classification, and qualification.
Risk response plans, and contingency planning.
Risk register.
7 References
[1] European Science Foundation (ESF) and All European Academies (ALLEA) (March 2011). The
European Code of Conduct for Research Integrity. ISBN: 978-2-918428-37-4.
[2] Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato (2013). Version Control with
Subversion. Retrieved September 25, 2015, from http://svnbook.red-bean.com/