Deliverable D1.2 Project Quality Assurance...

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



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.



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.



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



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



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



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



List of Tables

Table 1: Deliverables review and approval procedure. ................................................................. 22

Table 2: Indicative Deliverable Review Checklist. ......................................................................... 22



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



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.



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):



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.



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.



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.



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,



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.



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.



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.



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”.



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.



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.



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.



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



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.



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.



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,



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.



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



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.



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).



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/

http://svnbook.red-bean.com/

Date post:	09-Sep-2018
Category:	Documents
Upload:	ngokien
View:	219 times
Download:	0 times