producer d4 1 - platform toolset integration methodology …€¦ · · 2018-02-02cf fokus...

PeRsOnalized DocUmentary

[ICT-21-2016] Support technology transfer to the creative industries

D4.1 – Platform toolset integration methodology

Deliverable No.

Work packageNo.

WP4

Task No. T4.1

Lead beneficiary

Dissemination level

Nature of Deliverable

Delivery date

Status

File Name:

Project start date, duration

This project has received funding from the European Union’s Horizon 2020 Research and

The Framework Programme for Research & Innovation

Innovation actions (IA)

Project Title:

PeRsOnalized DocUmentary Creation based on Automatically Annotated Content

ProducerGrant Agreement No: 731893

2016] Support technology transfer to the creative industries

Deliverable

Platform toolset integration methodology

4.1

Work package Title PRODUCER Platform Integrtion, Evaluation and Bencmarking

Task Title Platform Toolset Integration

HIT

PU

Report

31-07-2017

D: draft

[PRODUCER] D4.1 - Platform toolset integration methoology_v1.docx

01 January 2017, 18 months

This project has received funding from the European Union’s Horizon 2020 Research andunder Grant Agreement n°731893.

The Framework Programme for Research & Innovation

Creation based on Automatically Annotated Content

2016] Support technology transfer to the creative industries

Platform toolset integration methodology

PRODUCER Platform Integra-tion, Evaluation and Bench-

Platform Toolset Integration

Platform toolset integration method-

This project has received funding from the European Union’s Horizon 2020 Research and innovation programme

Version of2017-07-28

D4.1 Platform toolset integration methodology

List of Reviewers

# Surname

1. Ioanna Roussaki

2. Stefano Miccoli

Version Date

0.1 15/06/2017

0.96 12/07/2017

0.97 21/07/2017

Full name

Christopher Ververidis

Panagiotis Sampatakos

Panagiotis Veltsistas

# Full name

1. Christian Fuhrhop

2. George Mitsis

3. George Marinellis

4. Louay Bassbouss

5. Nikos Kalatzis

6. Pasquale Panuccio

.1 Platform toolset integration methodology

Authors List

Reviewers List

List of Reviewers (in alphabetic order)

Initials BeneficiaryName

Contact email

IR ICCS [email protected]

SM FINCONS [email protected]

Document history

Status Modifications made by

Table of Contents C.Ververidis

All sections C.Ververidis

P.Sampatakos

P.Veltsistas

Section 4 C.Ververidis

Louay Bassbous

Christian Fuhrhop

Leading Authors (Editor)

Initials Benefi-ciaryName

Contact email

CV HIT [email protected]

PS HIT [email protected]

PV HIT [email protected]

Co-authors (in alphabetic order)

Initials Benefi-ciaryName

Contact email

CF FOKUS [email protected]

GM ICCS [email protected]

GM ICCS [email protected]

LB FOKUS [email protected]

NK ICCS [email protected]

PPFIN-

[email protected]

page 2

Contact email

[email protected]

[email protected]

Modifications made by

C.Ververidis - HIT

C.Ververidis – HIT

P.Sampatakos – HIT

P.Veltsistas - HIT


Louay Bassbous – FOKUS

Christian Fuhrhop - FOKUS

Contact email

innovations.com

innovations.com

innovations.com

Contact email

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]

[email protected]



0.98 24/07/2017

0.99 24/07/2017

1 28/07/2017

Abbreviation Definition

CA Consortium Agreement

CoA Coordination Agreement

DoW Description of Work

EC European Commission

IPR Intellectual Property Rights

NDA Non-

PO Project

QA Quality Assurance

R&D Research and Development

WP Work Package

Abbreviation Definition

CA Consortium Agreement

CoA Coordination Agreement

DoW Description of Work

EC European Commission

IPR Intellectual Property

NDA Non-

PO Project Officer

QA Quality Assurance


Pasquale PanuccioCONS

George Mitsis

Nikos Kalantzis

George Marinellis

First review of deliverable Ioanna Roussaki

Second review of deliverable Stefano Miccoli

All sections C.Ververidis

P.Sampatakos

P.Veltsistas

Abbreviation List

Definition

Consortium Agreement

Coordination Agreement

Description of Work

European Commission

Intellectual Property Rights

-disclosure agreement

Project Officer

Quality Assurance

Research and Development

Work Package

Partner Short Names

Definition

Consortium Agreement

Coordination Agreement

Description of Work

European Commission

Intellectual Property Rights

-disclosure agreement

Project Officer

Quality Assurance

page 3

Pasquale Panuccio – FIN-

George Mitsis – ICCS

Kalantzis – ICCS

George Marinellis - ICCS

Ioanna Roussaki - ICCS

Stefano Miccoli - FINCONS


P.Sampatakos – HIT

P.Veltsistas - HIT



R&D Research and Development

WP Work Package

Acknowledgement: The research leading to these results has received funding from the European Uion's Horizon 2020 Programme (H2020

Disclaimer: This document does not represent the opinion of the European Commupean Community is not responsible for any use that might be made of its content.

This document may contain material, which is the copyright of certain PRODUCER consortium parties,and may not be reproduced or copied without permission. Alagreed to full publication of this document. The commercial use of any information contained in thisdocument may require a license from the proprietor of that information.

Neither the PRODUCER consortium as a whole, norrant that the information contained in this document is capable of use, nor that use of the information isfree from risk, and does not accept any liability for loss or damage suffered by any person using thisformation.


Research and Development

Work Package

The research leading to these results has received funding from the European Uion's Horizon 2020 Programme (H2020-ICT-2016, call ICT-21-2016) under grant agreement n°

This document does not represent the opinion of the European Commupean Community is not responsible for any use that might be made of its content.

This document may contain material, which is the copyright of certain PRODUCER consortium parties,and may not be reproduced or copied without permission. All PRODUCER consortium parties haveagreed to full publication of this document. The commercial use of any information contained in thisdocument may require a license from the proprietor of that information.

Neither the PRODUCER consortium as a whole, nor a certain party of the PRODUCER consortium warant that the information contained in this document is capable of use, nor that use of the information isfree from risk, and does not accept any liability for loss or damage suffered by any person using this

page 4

The research leading to these results has received funding from the European Un-2016) under grant agreement n° 731893.

This document does not represent the opinion of the European Community, and the Euro-

This document may contain material, which is the copyright of certain PRODUCER consortium parties,l PRODUCER consortium parties have

agreed to full publication of this document. The commercial use of any information contained in this

a certain party of the PRODUCER consortium war-rant that the information contained in this document is capable of use, nor that use of the information isfree from risk, and does not accept any liability for loss or damage suffered by any person using this in-



Executive Summary

This document describes the comprehensive integrationdeployment strategy for the software components developed in PRODUCER, and how thesesoftware modules, sub-systems and systems willprototype platform. The document also provides the skeleton architecture of the PRODUCERplatform.

In line with the agile approach to software development, integration should be performed icrementally and continuously. By using a code version management system, it will be ensuredthat all developers have access to the latest versions of the code base. The code analysis andquality inspection will be performed by dedicated tools (e.g. SonarQube) and this analysis onPRODUCER components will be part of the continuous integration. The use of a continuousintegration server will ensure that the components are built after each change in the build rpository, and that the automated tests are executed. This approach will bevelopment and prototyping period after the rampnents and modules from different partners will be frequently integrated. However, it should benoticed that the ramp-up phase is mainly for the initiand therefore, the methodology described in the document has not been fully applied in thphase.

The deployment timeline for all three development and integration phases is presented. It cocerns the following stages:

The implementation of the standalone version of the platform tools The integration of all tools into the platform The validation and demo of the platform

The integration testing plan will be based on anthe quality of the integrated code, tests will be performed continuously throughout the projectwith regards to a number of quality attributes, including performance, scalability, stability andresilience.


Executive Summary

This document describes the comprehensive integration methodology, integration testingdeployment strategy for the software components developed in PRODUCER, and how these

systems and systems will be integrated and deployed into a commonThe document also provides the skeleton architecture of the PRODUCER

In line with the agile approach to software development, integration should be performed isly. By using a code version management system, it will be ensured

that all developers have access to the latest versions of the code base. The code analysis andquality inspection will be performed by dedicated tools (e.g. SonarQube) and this analysis onPRODUCER components will be part of the continuous integration. The use of a continuousintegration server will ensure that the components are built after each change in the build rpository, and that the automated tests are executed. This approach will bevelopment and prototyping period after the ramp-up phase. Throughout this period, compnents and modules from different partners will be frequently integrated. However, it should be

up phase is mainly for the initialization of the tools (standalone versions)and therefore, the methodology described in the document has not been fully applied in th

The deployment timeline for all three development and integration phases is presented. It co

of the standalone version of the platform toolsThe integration of all tools into the platformThe validation and demo of the platform

will be based on an iterative and incremental approach.code, tests will be performed continuously throughout the project

with regards to a number of quality attributes, including performance, scalability, stability and

page 5

methodology, integration testing anddeployment strategy for the software components developed in PRODUCER, and how these

be integrated and deployed into a commonThe document also provides the skeleton architecture of the PRODUCER

In line with the agile approach to software development, integration should be performed in-sly. By using a code version management system, it will be ensured

that all developers have access to the latest versions of the code base. The code analysis andquality inspection will be performed by dedicated tools (e.g. SonarQube) and this analysis onPRODUCER components will be part of the continuous integration. The use of a continuousintegration server will ensure that the components are built after each change in the build re-pository, and that the automated tests are executed. This approach will be utilized for the de-

up phase. Throughout this period, compo-nents and modules from different partners will be frequently integrated. However, it should be

alization of the tools (standalone versions)and therefore, the methodology described in the document has not been fully applied in that

The deployment timeline for all three development and integration phases is presented. It con-

iterative and incremental approach. To ensurecode, tests will be performed continuously throughout the project

with regards to a number of quality attributes, including performance, scalability, stability and



Table of Contents

List of Figures ................................

List of Tables ................................

1 Introduction................................

1.1 Purpose, context and scope of this deliverable

2 Software Implementation & Integration Methodology

3 PRODUCER Platform Architecture

3.1 Cross Component Direct Interconnection

3.1.1 Audience Building Tool

3.1.2 Integrated Trends Discovery Tool

3.1.3 Open Content Discovery Tool

3.1.4 Multimedia Content Storage, Search & Retrieval Tool

3.1.5 Automatic Annotation Tool

3.1.6 Interactive-enriched Video Creation Tool

3.1.7 360° Video Playout Tool

3.1.8 Second Screen Framework

3.1.9 Social Recommendation & Personalization Tool

3.2 PRODUCER platform skeleton architecture

3.3 Presentation Layer ................................

3.3.1 Dashboard - Common front

3.4 Application Layer ................................

3.4.1 Front-End Integration Sub

3.4.1.1 Authentication Manager (a.k.a Single

3.4.2 Back-End Integration Sub

3.4.2.1 Audience Building Tool

3.4.2.2 Integrated Trends Discovery Tool

3.4.2.3 Open Content Discovery Tool

3.4.2.4 Automatic Annotation Tool

3.4.2.5 Interactive-enriched Video Creation Tool

3.4.2.6 360° Video Playout Tool

3.4.2.7 Second Screen Framework

3.4.2.8 Social Recommendation & Personalization Tool

3.5 Data Layer ................................


4 Integration Methodology Timeline

4.1 Ramp-up phase (standalone tools)

4.2 Core Integration phase

4.3 Demo/Pilot phase ................................


................................................................................................................................

................................................................................................................................

................................................................................................................................

context and scope of this deliverable................................................................

Software Implementation & Integration Methodology ................................................................

PRODUCER Platform Architecture ................................................................................................

Cross Component Direct Interconnection ................................................................

Audience Building Tool ................................................................................................

Integrated Trends Discovery Tool ................................................................

Open Content Discovery Tool ................................................................

Multimedia Content Storage, Search & Retrieval Tool................................

Automatic Annotation Tool ................................................................................................

enriched Video Creation Tool ................................................................

360° Video Playout Tool ................................................................................................

Second Screen Framework ................................................................................................

Social Recommendation & Personalization Tool ................................................................

PRODUCER platform skeleton architecture................................................................

................................................................................................

Common front-end (GUI) Development................................

................................................................................................

End Integration Sub-Layer ................................................................

Authentication Manager (a.k.a Single-Sign-On Manager) ................................

End Integration Sub-Layer ................................................................

Audience Building Tool ................................................................................................

Integrated Trends Discovery Tool ................................................................

Open Content Discovery Tool ................................................................

Automatic Annotation Tool ................................................................

enriched Video Creation Tool ................................................................

360° Video Playout Tool ................................................................................................

Second Screen Framework ................................................................

Social Recommendation & Personalization Tool ................................

................................................................................................

Multimedia Content Storage, Search & Retrieval Tool................................

Integration Methodology Timeline ................................................................................................

up phase (standalone tools) ................................................................

Core Integration phase ................................................................................................

................................................................................................

page 6

.............................................8

..............................................8

..........................................9

..........................................9

.........................................9

...................................11

................................................12

.........................................12

........................................................13

..............................................................13

.........................................................13

...................................13

.............................................14

.......................................14

..................................14

.................................14

.............................................15

...................................................15

...........................................................15

......................................................16

..........................................................16

...............................................16

..........................................................16

.....................................16

....................................................17

..........................................................17

...............................................................18

.........................................18

...................................19

..............................................................19

.............................................................19

................................................................20

.........................................................20

.....................................20

..........................................................21

.............................................22

.....................................................23



5 Testing Process Management

5.1 Software Quality Assurance

5.1.1 Software Quality Models

5.1.2 The ISO/IEC 25010 Model

5.2 PRODUCER’s Testing Methodology

5.2.1 PRODUCER’s Agile Testing Levels

5.2.2 PRODUCER’s Integration Testing

5.2.3 Integration testing approach

5.2.4 Manual Testing ................................

6 Integration Process Management Tools

6.1 Software Configuration Management

6.1.1 Project Management with JIRA

6.1.2 Code Management with Git

6.2 Code Analysis & Quality Measurement

6.2.1 Inspection of Code Quality

6.3 Integration Strategies ................................

6.4 Integration Process of the PRODUCER Platform Prototype

6.4.1 Code Synchronization

6.4.2 Front-end & Back-end Development

6.4.3 Code Publishing................................

6.4.4 Global Build ................................

6.4.5 Work-flow Adaptation

6.4.6 Reporting ................................

7 Conclusion................................

References ................................................................


ocess Management ................................................................................................

Software Quality Assurance ................................................................................................

Software Quality Models................................................................................................

The ISO/IEC 25010 Model ................................................................................................

PRODUCER’s Testing Methodology................................................................

PRODUCER’s Agile Testing Levels ................................................................

PRODUCER’s Integration Testing................................................................

Integration testing approach ................................................................................................

................................................................................................

n Process Management Tools ................................................................

Software Configuration Management................................................................

Project Management with JIRA ................................................................

Code Management with Git ................................................................................................

Code Analysis & Quality Measurement................................................................

Inspection of Code Quality ................................................................................................

................................................................................................

Integration Process of the PRODUCER Platform Prototype................................

Code Synchronization ................................................................................................

end Development ................................................................

................................................................................................

................................................................................................

w Adaptation ................................................................................................

................................................................................................

................................................................................................................................

................................................................................................

page 7

..........................................24

.....................................24

.......................................24

...................................25

........................................................27

.....................................................27

........................................................28

.................................29

.....................................................31

...........................................................32

.......................................................32

............................................................33

..................................33

....................................................34

...................................34

...............................................35

....................................................35

..........................................36

....................................................36

....................................................36

..........................................................36

...........................................37

..............................................................37

.........................................37

...............................................38



List of Figures

Figure 1: Integration Steps ................................

Figure 2: Integration methodology

Figure 3: Platform high level architecture

Figure 4: Platform skeleton architecture

Figure 5: Exemplary Integration Timeline

Figure 6: Ramp-up phase ................................

Figure 7: Integration phase deployment planning

Figure 8: Demo phase deployment planning

Figure 9: Several perspectives on software quality.

Figure 10: ISO/IEC 25010 Quality model for external and internal quality

Figure 11: Quality in use characteristics

Figure 12: Agile Testing Levels

Figure 13: Multi-staging in Jenkins

Figure 14: Human confirmation of successful test execution

Figure 15: Setting environment variables in Jenkins

Figure 16: Setting up cases using Tarantula

Figure 17: Define new test object in Tarantula

Figure 18: Software quality dimensions supported by SonarQube

Figure 19: Integration Strategies

Figure 20: PRODUCER’s Integration Process

List of Tables

Table 1: Cross-component direct communications.

Table 2: Ramp-up activities ................................

Table 3: Integration phase activities

Table 4: Demo/Pilot phase activities

Table 5: Software Quality Models

Table 6: Software Integration Test Plan


................................................................................................

Figure 2: Integration methodology ................................................................................................

Figure 3: Platform high level architecture ................................................................

Figure 4: Platform skeleton architecture ................................................................

Figure 5: Exemplary Integration Timeline................................................................

................................................................................................

Figure 7: Integration phase deployment planning ................................................................

Demo phase deployment planning................................................................

Figure 9: Several perspectives on software quality. ................................................................

Figure 10: ISO/IEC 25010 Quality model for external and internal quality ................................

Figure 11: Quality in use characteristics ................................................................

le Testing Levels ................................................................................................

staging in Jenkins ................................................................................................

Figure 14: Human confirmation of successful test execution................................

Figure 15: Setting environment variables in Jenkins ................................................................

Figure 16: Setting up cases using Tarantula................................................................

Figure 17: Define new test object in Tarantula................................................................

Figure 18: Software quality dimensions supported by SonarQube ................................

Figure 19: Integration Strategies ................................................................................................

Figure 20: PRODUCER’s Integration Process ................................................................

component direct communications. ................................................................

................................................................................................

Table 3: Integration phase activities ................................................................................................

phase activities ................................................................................................

Table 5: Software Quality Models ................................................................................................

Table 6: Software Integration Test Plan ................................................................

page 8

......................................................9

.......................................10

...........................................................11

.............................................................15

...........................................................21

.....................................................21

.............................................22

.......................................................23

..........................................24

.......................................26

.............................................................27

............................................28

......................................30

...........................................................31

.........................................31

.......................................................32

....................................................32

..................................................35

..........................................35

....................................................36

..........................................12

...................................................22

....................................22

....................................23

.........................................25

...............................................................28



1 Introduction

1.1 Purpose, context and scope of this deliverable

This deliverable defines the basis for integrating the toolsplatform will consist of. The integration methodology described is aligned with the current tooldevelopment plan and the initial PRODUCER platform architecture. Sing an iterative and incremental development approach that is divided into three developmentcycles, therefore the integration plan may change as a result of evolutionsaptations in the project. In general, the integratition of different components and applications (tools). In PRODUCER, the tools which are dveloped in the technical work package (WP3) shall be integrated into one prototype platform.The integration plan providedplatform prototype. Finally, the platform architecture skeleton is provided in this document toserve as the reference point not only for the integratorsvelopers.

2 Software Implementation

In software engineering, the software development process is divided into several tasks in oder to facilitate the project management andstrategy can be adopted for the specification of the integration methodology.that are iterated throughout a typical

A short description of the afore

Planning: At first thetesting planning. Hereby the timelines are drawn and the scheduling for all activities &efforts until the end of the project is defined as agreed by the consortium partners.this point, it should be noted that the efforts fothe activities of the “Planning”deliverable “D2.1 - Report on investors’ and viewers’ requirements and usage scenaios”.


Purpose, context and scope of this deliverable

This deliverable defines the basis for integrating the tools which will compose. The integration methodology described is aligned with the current tool

development plan and the initial PRODUCER platform architecture. Since PRODUCER is uing an iterative and incremental development approach that is divided into three developmentcycles, therefore the integration plan may change as a result of evolutions

in the project. In general, the integration serves for the composition and concatention of different components and applications (tools). In PRODUCER, the tools which are dveloped in the technical work package (WP3) shall be integrated into one prototype platform.The integration plan provided in this deliverable will also describe the testing

the platform architecture skeleton is provided in this document toserve as the reference point not only for the integrators, but also for all component (tool

Software Implementation & Integration Methodology

In software engineering, the software development process is divided into several tasks in othe project management and ensure the quality of the final outcome. The same

strategy can be adopted for the specification of the integration methodology.out a typical integration planning are presented in

Figure 1: Integration Steps

hort description of the afore-depicted tasks follows below:

: At first the definition of the integration planning takes placeHereby the timelines are drawn and the scheduling for all activities &

efforts until the end of the project is defined as agreed by the consortium partners.this point, it should be noted that the efforts for producing the current deliverable fall inthe activities of the “Planning” step, while the Requirements definition was part of the

Report on investors’ and viewers’ requirements and usage scena

page 9

will compose the PRODUCER. The integration methodology described is aligned with the current tool

ince PRODUCER is us-ing an iterative and incremental development approach that is divided into three developmentcycles, therefore the integration plan may change as a result of evolutions and respective ad-

on serves for the composition and concatena-tion of different components and applications (tools). In PRODUCER, the tools which are de-veloped in the technical work package (WP3) shall be integrated into one prototype platform.

in this deliverable will also describe the testing of the integratedthe platform architecture skeleton is provided in this document to

but also for all component (tool) de-

Methodology

In software engineering, the software development process is divided into several tasks in or-the quality of the final outcome. The same

strategy can be adopted for the specification of the integration methodology. The distinct tasksin Figure 1.

place, as well as theHereby the timelines are drawn and the scheduling for all activities &

efforts until the end of the project is defined as agreed by the consortium partners. Atr producing the current deliverable fall in

, while the Requirements definition was part of theReport on investors’ and viewers’ requirements and usage scenar-



Requirements: Herein,are responsible for the development of the individual tools and the final integrated plaform.

Design: During this stepopment of the final integrated platform will be based on these designs.cludes a small fraction of thechitecture of the Final Integrated Platform, as described in Sectiondocument

Modules Developmenteach individual tool/ componentD3.2 & D3.3) are referring to.

Integration & Testingsame platform, the establishment of the intracertain workflows and useconsists of a parallel testing phase that will be continuous and iterative and will covernot only single tools but also the integration tests, including functional andsues. These two sub-document, respectively.

Deployment & Evaluationfidelity laboratory environment or in a simulated operationalplace, at this step. Hereby, the Pilot Acceptance Testing (PAT) will also be carried out.Of course, the results of the PAT will be used for the application of corrective actions inthe development & integrationuser evaluation process ofof which will also lead to

In order to achieve the integration of allure 2.


Herein, the system’s requirements are identified from the partners thatare responsible for the development of the individual tools and the final integrated pla

step the integrated platform’s layout is designed. Thentegrated platform will be based on these designs.

a small fraction of the efforts to be put in D3.1; D3.2 & D3.3chitecture of the Final Integrated Platform, as described in Section

Development: This step refers to the development and the finalization/ component. Herein, the main efforts foreseen for WP3 (incl. D3.1;

D3.2 & D3.3) are referring to.

Integration & Testing: Herein, the putting together of each distinct tool within thesame platform, the establishment of the intra-communications and the facilitation ofcertain workflows and use-cases will be performed. As explained below, this

a parallel testing phase that will be continuous and iterative and will covernot only single tools but also the integration tests, including functional and

-steps are dealt with in Section 4 and Sectiondocument, respectively.

Evaluation: The deployment of the finally integrated platformfidelity laboratory environment or in a simulated operational environment will take

Hereby, the Pilot Acceptance Testing (PAT) will also be carried out.he results of the PAT will be used for the application of corrective actions in

the development & integration step. Last but not least, this step also includesprocess of the system (e.g. through questionnaires

also lead to corrective technical actions of the platform

In order to achieve the integration of all modules a spiral strategy is followed as shown in

Figure 2: Integration methodology

page 10

identified from the partners thatare responsible for the development of the individual tools and the final integrated plat-

designed. The actual devel-ntegrated platform will be based on these designs. This step in-

efforts to be put in D3.1; D3.2 & D3.3, as well as the ar-chitecture of the Final Integrated Platform, as described in Section 3.2 of the current

and the finalization ofHerein, the main efforts foreseen for WP3 (incl. D3.1;

Herein, the putting together of each distinct tool within thecommunications and the facilitation of

cases will be performed. As explained below, this step alsoa parallel testing phase that will be continuous and iterative and will cover

not only single tools but also the integration tests, including functional and technical is-and Section 6 of the current

integrated platform in high-environment will take

Hereby, the Pilot Acceptance Testing (PAT) will also be carried out.he results of the PAT will be used for the application of corrective actions in

this step also includes the end-the system (e.g. through questionnaires, etc.), the analysis

actions of the platform, where necessary.

followed as shown in Fig-



This methodology separatespeatedly. In the first cycle of this procedure, the actors’ requirements will be detected duringthe Analysis Session and the initial specifications will be defined during the Specificationsion. Taking this collected information into consideration an early version of all modules will bedeveloped and the first release of the platform, with all the modules integrated, will be pulished. In the second cycle of the procedure, the preparation forstared. At first, the demo/pilot requirements will be created. Following that, the final specifictions together with the demo/pilot specifications will be agreed. At the end of the second cycleof the development Session, all theform will be ready for the final version.

3 PRODUCER Platform A

Apart from the design of the internal architecture of each distinct component that will be dfined in the deliverables “D3.1& “D3.3 - Post-production related toolsPRODUCER platform has also to be defined at this stage, so as to lead and to facilitate theearly adaptation adjustments for each component.

In this respect, this Section deals with the more concise definition of both PRODUCER’s coceptual (a.k.a. “high-level architecture”) and skeleton architecture.DUCER platform high level architectureas an integrated product consisting of a series of different but smoothly cooperatinents/tools, which will facilitate the film producers in the documentary creation process.Through the platform front-end the users/producers can be single loggedferent tools. Each tool consists of a backities and services and a user-organized in three main categories, based on the phase of the documentary creation processthat they mainly support, i.e. prepre-production phase will be able to interact with wellvided by the latter APIs. The platform consistswhich reside in the same server (i.e. IeVCT,ture contains a central common database sharable to all the platform’s tools.

Figure


This methodology separates the whole procedure in four (4) sessions that are followed rpeatedly. In the first cycle of this procedure, the actors’ requirements will be detected during

and the initial specifications will be defined during the Specification. Taking this collected information into consideration an early version of all modules will be

developed and the first release of the platform, with all the modules integrated, will be pulished. In the second cycle of the procedure, the preparation for the

pilot requirements will be created. Following that, the final specificpilot specifications will be agreed. At the end of the second cycle

, all the modules will be finalized and after the integration, the plaform will be ready for the final version.

Platform Architecture

Apart from the design of the internal architecture of each distinct component that will be d.1 - Pre-production related tools”; “D3.2 - Production related tools

production related tools” of WP3, the overall architecture of the integratedPRODUCER platform has also to be defined at this stage, so as to lead and to facilitate the

rly adaptation adjustments for each component.

In this respect, this Section deals with the more concise definition of both PRODUCER’s colevel architecture”) and skeleton architecture. Figure

high level architecture. The envisioned PRODUCER platform will be releasedas an integrated product consisting of a series of different but smoothly cooperati

, which will facilitate the film producers in the documentary creation process.end the users/producers can be single logged-in and use all the di

ferent tools. Each tool consists of a back-end engine, being responsible for its main functiona-friendly interface in the front-end system. The producer tools are

organized in three main categories, based on the phase of the documentary creation processthat they mainly support, i.e. pre-production, production and post-production.

production phase will be able to interact with well-known social networks through the prThe platform consists of several distributed tools, as well as tools

eside in the same server (i.e. IeVCT, 360° VPT, SSF and SRPT). Finally the architeture contains a central common database sharable to all the platform’s tools.

Figure 3: Platform high level architecture

page 11

that are followed re-peatedly. In the first cycle of this procedure, the actors’ requirements will be detected during

and the initial specifications will be defined during the Specification Ses-. Taking this collected information into consideration an early version of all modules will be

developed and the first release of the platform, with all the modules integrated, will be pub-the demos/pilots will be

pilot requirements will be created. Following that, the final specifica-pilot specifications will be agreed. At the end of the second cycle

modules will be finalized and after the integration, the plat-

Apart from the design of the internal architecture of each distinct component that will be de-Production related tools”

” of WP3, the overall architecture of the integratedPRODUCER platform has also to be defined at this stage, so as to lead and to facilitate the

In this respect, this Section deals with the more concise definition of both PRODUCER’s con-Figure 3 displays the PRO-

. The envisioned PRODUCER platform will be releasedas an integrated product consisting of a series of different but smoothly cooperating compo-

, which will facilitate the film producers in the documentary creation process.in and use all the dif-

sponsible for its main functional-end system. The producer tools are

organized in three main categories, based on the phase of the documentary creation processproduction. The tools of the

known social networks through the pro-of several distributed tools, as well as tools

, SSF and SRPT). Finally the architec-ture contains a central common database sharable to all the platform’s tools.



3.1 Cross Component Direct

Table 1 describes direct interconnections between components in the PRODUCER systemThe non-empty cells of the table describe components with direct communication where thedirections of the data flows are indicated by

ABT ITDT

Audience BuildingTool

Integrated TrendsDiscovery Tool

Open Content Dis-covery Tool

Multimedia Con-tent Storage,Search & RetrievalTool

Automatic Annota-tion Tool

Interactive-enriched VideoCreation Tool

360° Video PlayoutTool

Second ScreenFramework

Social Recommen-dation & Personal-ization Tool

Table 1: Cross

Indicates that the direction of the information’s flow is from the tool of the corresponding row to the tool of the coresponding column

Indicates direction from the tool of the

3.1.1 Audience Building Tool

The Audience Building Tool will communicate directly with the ITDT in order to sendtion about a project (e.g. film/documentary) that is to be created and based on thithe ITDT will be able to correlate the project with current trends.

Similarly, the ABT will communicate with the OCDT in order to send information related to theproducer’s projects.

Moreover, the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. This will enable content uploaded to the ABT to bestored into and retrieved from the

Finally, the ABT will communiccial connections to the users of the ABT after processing information that come from the ABT.The Audience Building Tool will communicate directly with the ITDT in order to send information about a project (e.g. film/documentary) that is to be created and based on this infomation ITDT will be able to correlate the project with current trends.


Cross Component Direct Interconnection

direct interconnections between components in the PRODUCER systemempty cells of the table describe components with direct communication where the

directions of the data flows are indicated by the arrows.

ITDT OCDT MCSSR AAT IeVCT

: Cross-component direct communications.

Indicates that the direction of the information’s flow is from the tool of the corresponding row to the tool of the co

Indicates direction from the tool of the corresponding column to the tool of the corresponding row

Audience Building Tool

The Audience Building Tool will communicate directly with the ITDT in order to sendabout a project (e.g. film/documentary) that is to be created and based on thi

the ITDT will be able to correlate the project with current trends.

Similarly, the ABT will communicate with the OCDT in order to send information related to the

Moreover, the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. This will enable content uploaded to the ABT to bestored into and retrieved from the MCSSR.

Finally, the ABT will communicate with the SRPT in order to let the second to recommend scial connections to the users of the ABT after processing information that come from the ABT.The Audience Building Tool will communicate directly with the ITDT in order to send in

a project (e.g. film/documentary) that is to be created and based on this infomation ITDT will be able to correlate the project with current trends.

page 12

direct interconnections between components in the PRODUCER system.empty cells of the table describe components with direct communication where the

360°VPT SSF SRPT

Indicates that the direction of the information’s flow is from the tool of the corresponding row to the tool of the cor-

corresponding column to the tool of the corresponding row

The Audience Building Tool will communicate directly with the ITDT in order to send informa-about a project (e.g. film/documentary) that is to be created and based on this information

Similarly, the ABT will communicate with the OCDT in order to send information related to the

Moreover, the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. This will enable content uploaded to the ABT to be

ate with the SRPT in order to let the second to recommend so-cial connections to the users of the ABT after processing information that come from the ABT.The Audience Building Tool will communicate directly with the ITDT in order to send in-

a project (e.g. film/documentary) that is to be created and based on this infor-



Similarly the ABT will communicate with the OCDT in order to send information related to theproducer’s projects.

Moreover the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. Thus multimedia content uploaded to the ABT will beable to be stored to and to be retrieved from MCSSR.

Finally, the ABT will communicate with the SRPT in order the second to recommend socialconnections to the users of the ABT after processing information coming from the ABT

3.1.2 Integrated Trends Discovery Tool

The ITDT will receive input from the ABT and the OCDT ining the correlation of the retrieved data with the current trends. The results of the ITDT analsis will not be stored to the common database managed by the MCSSR, as the tool will haveits own database.

3.1.3 Open Content Discov

The OCD will directly integrate with the Multimedia Content Storage, Search & Retrieval Toolto ingest multimedia content. The OCD will send the download URL of the multimedia contentselected, along with metadata info so that the MCSSR will store

Moreover the OCD will communicate directly with the ITDT and the ABT for sending and rceiving data respectively (as described in


The Multimedia Content Storage, Search & Retrieval Tool

The Automatic Annotation Tool, in order to receive the results of the annotation proess from the AAT. The MCSSR will receive the metadata information generated fromthe analysis of the multimedia content performed by the AAT, alonof the multimedia content. The identifier of the content is previously sent from theMCSSR to the AAT each time new material becomes available into the MCCSR.

The Interactive-Enriched Video Creation Tool in order to store enriched vidwith metadata related to the enrichment process.

The Audience Building Tool in order to store multimedia content that has been uloaded through the ABT and in order to allow the ABT users to search and retrievestored multimedia content.

The Open Content Discovery Tool in order to store new multimedia content providedby the OCDT.

The 360° Video Playout Tool in order to supply the 360° VPT with 360° videos. TheAPI may also possibly allow the 360° VPT to store the processed videos in theMCSSR.

The Second Screen Framework in order to provide stored multimedia content.

The Social Recommendation & Personalization Tool in order the latter to be able to retrieveinformation about the stored data and metadata.

3.1.5 Automatic Annotation Tool

The Automatic Annotation Tool will directly integrate with MCSSR tool to provide annotationsfor the content. The MCSSR tool will provide


Similarly the ABT will communicate with the OCDT in order to send information related to the

Moreover the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. Thus multimedia content uploaded to the ABT will beable to be stored to and to be retrieved from MCSSR.

the ABT will communicate with the SRPT in order the second to recommend socialconnections to the users of the ABT after processing information coming from the ABT

Integrated Trends Discovery Tool

The ITDT will receive input from the ABT and the OCDT in order to provide metadata concering the correlation of the retrieved data with the current trends. The results of the ITDT analsis will not be stored to the common database managed by the MCSSR, as the tool will have

Open Content Discovery Tool

The OCD will directly integrate with the Multimedia Content Storage, Search & Retrieval Toolto ingest multimedia content. The OCD will send the download URL of the multimedia contentselected, along with metadata info so that the MCSSR will store those into its repository.

Moreover the OCD will communicate directly with the ITDT and the ABT for sending and rrespectively (as described in Sections 3.1.2 and Section 3.1.1

Multimedia Content Storage, Search & Retrieval Tool

Multimedia Content Storage, Search & Retrieval Tool will provide an API to:

The Automatic Annotation Tool, in order to receive the results of the annotation proess from the AAT. The MCSSR will receive the metadata information generated fromthe analysis of the multimedia content performed by the AAT, alonof the multimedia content. The identifier of the content is previously sent from theMCSSR to the AAT each time new material becomes available into the MCCSR.

Enriched Video Creation Tool in order to store enriched vidwith metadata related to the enrichment process.

The Audience Building Tool in order to store multimedia content that has been uloaded through the ABT and in order to allow the ABT users to search and retrievestored multimedia content.

Content Discovery Tool in order to store new multimedia content provided

The 360° Video Playout Tool in order to supply the 360° VPT with 360° videos. TheAPI may also possibly allow the 360° VPT to store the processed videos in the

Second Screen Framework in order to provide stored multimedia content.

The Social Recommendation & Personalization Tool in order the latter to be able to retrieveinformation about the stored data and metadata.

Automatic Annotation Tool

tation Tool will directly integrate with MCSSR tool to provide annotationsfor the content. The MCSSR tool will provide to the AAT, through its API

page 13

Similarly the ABT will communicate with the OCDT in order to send information related to the

Moreover the ABT will communicate with the Multimedia Content Storage, Search & RetrievalTool through APIs provided by the latter. Thus multimedia content uploaded to the ABT will be

the ABT will communicate with the SRPT in order the second to recommend socialconnections to the users of the ABT after processing information coming from the ABT

order to provide metadata concern-ing the correlation of the retrieved data with the current trends. The results of the ITDT analy-sis will not be stored to the common database managed by the MCSSR, as the tool will have

The OCD will directly integrate with the Multimedia Content Storage, Search & Retrieval Toolto ingest multimedia content. The OCD will send the download URL of the multimedia content

those into its repository.

Moreover the OCD will communicate directly with the ITDT and the ABT for sending and re-3.1.1, respectively).

API to:

The Automatic Annotation Tool, in order to receive the results of the annotation proc-ess from the AAT. The MCSSR will receive the metadata information generated fromthe analysis of the multimedia content performed by the AAT, along with the identifierof the multimedia content. The identifier of the content is previously sent from theMCSSR to the AAT each time new material becomes available into the MCCSR.

Enriched Video Creation Tool in order to store enriched video along

The Audience Building Tool in order to store multimedia content that has been up-loaded through the ABT and in order to allow the ABT users to search and retrieve

Content Discovery Tool in order to store new multimedia content provided

The 360° Video Playout Tool in order to supply the 360° VPT with 360° videos. TheAPI may also possibly allow the 360° VPT to store the processed videos in the

Second Screen Framework in order to provide stored multimedia content.

The Social Recommendation & Personalization Tool in order the latter to be able to retrieve

tation Tool will directly integrate with MCSSR tool to provide annotationsthrough its API, the content to be



processed. The AAT will internally process thecomputer vision algorithms. Then the AAenrich stored content metadataauthenticated to the AAT using its REST API.

The AAT will also communicateproduced by the IeVC tool.

3.1.6 Interactive-enriched Video Creation Tool

The Interactive-enriched Video Creation Toolder to retrieve videos to be processed and toto the enrichment process

The IeVC tool will also communicate with thewith annotated data produced by the AAT

Furthermore, the IeVCT will communicate with the

3.1.7 360° Video Playout Tool

The 360° Video Playout Tool has the main goal to prepare a 360° video for playback on lowcapability devices like TVs. The default 360° player used in IeVCT is based on local renderingof the 360° video in the Browser. This will not work on HbbTV or devices like Chromecast.

This Tool gets the 360° video from the MCSSR Tool using the URL of the 360° video. Thevideo will be processed and the output video segments will be storedand also on MCSSR. During Streaming, the video segment files need to beStreaming Server of the tool’s backis also part of this tool. The default player of the IeVCT can tPlayer so the interaction with the SRPT will remain. Usability measures will be taken to adaptthe user experience to the given controllers, such as TV remote in place of keyboard, mouseand touch screens.

Concerning the communication with the players from 360VPT and the SSF, the players willcapture the user interactions with the multimedia content and send them to the SRPT for futher analysis.

3.1.8 Second Screen Framework

The Second Screen Framework consists of a Standalone Servercommunication with the Server works through the JavaScript client so the server functionalitiesare hidden for the developer. The JavaScript Client can be integrated in any PRODUCER aplication that may integrate components fromVideo. There is no need for interaction between the Second Screen Server and other PRCUDER tools, although the SSF will be able to communicate with the MCSSR and the SRP.

3.1.9 Social Recommendation & Personali

The SRPT will communicate with the ABT in order to recommend social connections to theABT.

Since the MCSSR is responsible to store data and metadata,with the MCSSR in order to get hold of that information. The Sthe MCSSR can store and offerrichments paired with each video.

Concerning the communication with the players from 360VPT and the SSF, the players will


internally process the received content and extract annotationithms. Then the AAT will return the annotation results to the MCSSR

enrich stored content metadata. In order to use AAT’s functionality the MCSSR tool has to getusing its REST API.

communicate with the MCSSR in order to automatically annotate videos

enriched Video Creation Tool

enriched Video Creation Tool will communicate directly with the MCSSRprocessed and to store enriched video along with metadata related

will also communicate with the MCSSR tool in order to further enrich the videosproduced by the AAT.

will communicate with the 360° VPT tool.

360° Video Playout Tool

The 360° Video Playout Tool has the main goal to prepare a 360° video for playback on lowcapability devices like TVs. The default 360° player used in IeVCT is based on local rendering

e 360° video in the Browser. This will not work on HbbTV or devices like Chromecast.

This Tool gets the 360° video from the MCSSR Tool using the URL of the 360° video. Thevideo will be processed and the output video segments will be stored in the tool’s

also on MCSSR. During Streaming, the video segment files need to beof the tool’s back-end and from there to be sent to the 360° TV Player which

is also part of this tool. The default player of the IeVCT can then be replaced bythe interaction with the SRPT will remain. Usability measures will be taken to adapt

the user experience to the given controllers, such as TV remote in place of keyboard, mouse

ation with the players from 360VPT and the SSF, the players willcapture the user interactions with the multimedia content and send them to the SRPT for fu

Second Screen Framework

The Second Screen Framework consists of a Standalone Server and JavaScript Client. Thecommunication with the Server works through the JavaScript client so the server functionalities

hidden for the developer. The JavaScript Client can be integrated in any PRODUCER aplication that may integrate components from other tools like 360° Video Player and Interactive

There is no need for interaction between the Second Screen Server and other PR, although the SSF will be able to communicate with the MCSSR and the SRP.

Social Recommendation & Personalization Tool

The SRPT will communicate with the ABT in order to recommend social connections to the

Since the MCSSR is responsible to store data and metadata, SRPT will need to communicatewith the MCSSR in order to get hold of that information. The SRPT will provide APIs so that

store and offer metadata for videos, as well as the annotations and the erichments paired with each video.


page 14

content and extract annotations usingresults to the MCSSR to

functionality the MCSSR tool has to get

in order to automatically annotate videos

will communicate directly with the MCSSR in or-store enriched video along with metadata related

in order to further enrich the videos

The 360° Video Playout Tool has the main goal to prepare a 360° video for playback on lowcapability devices like TVs. The default 360° player used in IeVCT is based on local rendering

e 360° video in the Browser. This will not work on HbbTV or devices like Chromecast.

This Tool gets the 360° video from the MCSSR Tool using the URL of the 360° video. Thein the tool’s back-end

also on MCSSR. During Streaming, the video segment files need to be available to thebe sent to the 360° TV Player which

hen be replaced by 360° TVthe interaction with the SRPT will remain. Usability measures will be taken to adapt

the user experience to the given controllers, such as TV remote in place of keyboard, mouse

ation with the players from 360VPT and the SSF, the players willcapture the user interactions with the multimedia content and send them to the SRPT for fur-

and JavaScript Client. Thecommunication with the Server works through the JavaScript client so the server functionalities

hidden for the developer. The JavaScript Client can be integrated in any PRODUCER ap-other tools like 360° Video Player and Interactive

There is no need for interaction between the Second Screen Server and other PRO-, although the SSF will be able to communicate with the MCSSR and the SRP.

The SRPT will communicate with the ABT in order to recommend social connections to the

will need to communicatewill provide APIs so that

metadata for videos, as well as the annotations and the en-




capture the user interactions with the multimedia content and send them to theple calls on a REST API that thecontain which user performs the action, in which video and what action occurred (play, sclick enrichment, share enrichment, like/dislike). Thethe player and store them locally for further processing.

Regarding communication of the SRPT with the IEVCT, the Web Player offered by IEVCT willbe sending user tracking data like play/pause, clickinteract with the IeVC tool in order to provide enrichment recommendations or filtering in orderfor personalised documentary version production to be enabled.

3.2 PRODUCER platform skeleton architecture

Figure 4 displays the PRODUCER platform’s skeleton architecture, consisting of three basiclayers i.e. Presentation Layerconsists of two sub-layers namely: theIntegration Sub-Layer. In the following sections each one of the architecture’s layers are dtailed.

Figure

3.3 Presentation Layer

3.3.1 Dashboard - Common front

The only component that resides in the Presentation Layer is the Dashboard. The Dashboardcan be described as a unique aggregator of several UIs. As it has been already mentioned theenvisioned PRODUCER platform will be released as an integrated product cories of different but smoothly cooperating components. Each one of the tools, except from theAutomatic Annotation Tool (AAT), is consisting of a back


interactions with the multimedia content and send them to theple calls on a REST API that the SRPT will provide. Information to be captured and sent willcontain which user performs the action, in which video and what action occurred (play, sclick enrichment, share enrichment, like/dislike). The SRPT API will collectthe player and store them locally for further processing.

Regarding communication of the SRPT with the IEVCT, the Web Player offered by IEVCT willuser tracking data like play/pause, clicks on certain element etc.

interact with the IeVC tool in order to provide enrichment recommendations or filtering in orderfor personalised documentary version production to be enabled.

platform skeleton architecture

displays the PRODUCER platform’s skeleton architecture, consisting of three basicyer, Application Layer, and Data Layer. The Application Layer

layers namely: the Front-End Integration Sub-Layerthe following sections each one of the architecture’s layers are d

Figure 4: Platform skeleton architecture

Presentation Layer

Common front-end (GUI) Development

The only component that resides in the Presentation Layer is the Dashboard. The Dashboardcan be described as a unique aggregator of several UIs. As it has been already mentioned theenvisioned PRODUCER platform will be released as an integrated product cories of different but smoothly cooperating components. Each one of the tools, except from theAutomatic Annotation Tool (AAT), is consisting of a back-end and a user friendly front

page 15

interactions with the multimedia content and send them to the SRPT via sim-will provide. Information to be captured and sent will

contain which user performs the action, in which video and what action occurred (play, stop,collect the data sent from

Regarding communication of the SRPT with the IEVCT, the Web Player offered by IEVCT willon certain element etc. The SRP tool will

interact with the IeVC tool in order to provide enrichment recommendations or filtering in order

displays the PRODUCER platform’s skeleton architecture, consisting of three basic. The Application Layerayer and the Back-End

the following sections each one of the architecture’s layers are de-

The only component that resides in the Presentation Layer is the Dashboard. The Dashboardcan be described as a unique aggregator of several UIs. As it has been already mentioned theenvisioned PRODUCER platform will be released as an integrated product consisting of a se-ries of different but smoothly cooperating components. Each one of the tools, except from the

end and a user friendly front-end as



well as. Thus, the Dashboard provides a common UI thdividual tool UIs and the services provided by the AAT. By being l(see Section 3.4.1.1) the userthe tools will follow certain guidelines in order to be uniform.

3.4 Application Layer

3.4.1 Front-End Integration Sub

The application layer is the core layer of the PRODUCER’s platform and is csub-layers, the Front-End Integration SubFront-End Integration Sub-Layenism in order to integrate all the several distinct UIs in

3.4.1.1 Authentication Manager (a.k.a Single

Each stand-alone tool of the PRODUCER platform has been developed as a web applicationthat requires some form of authentication to access its features and services. Due to thetively high number of the PRODUCER toolseach time he/she tries to access a tool,Thus, a Single-Sign-On (SSO) authentication mechanism will be implemented allowinto have access to the platform’

The idea of the SSO is that there is athentication procedure is performed, so as to allow users to access all the differentPRODUCER platform with a single log

3.4.2 Back-End Integration Sub

The Back-End Integration Subfor their main functionalities and servicesrectly or via the Multimedia Content Storage Search & Retrieval Tool (MCSSR) which providesAPIs for accessing the PRODUCER’s common database.

3.4.2.1 Audience Building Tool

The Audience Building Tool (ABT)with existing Social Media via their official API’s.

User registration on the platform will be available either directly (i.e. the user will register withhis/hers email, username, password etc.) or by using an existing Social Media accountFacebook, twitter, google etc.)

After his/her registration, the user will be able to make connections (i.e. friends) and post topicspecific marked (e.g. hashtagrestrictions (visibility, privacy, expiration date/time etc.)“friend’s” wall, and/or forwarded to other social media.

Amongst the registered users’ available options will be to perform searches within all availablecontent marked as “public”, initiate discussion threads for certain topics and participate in eisting ones, edit his/her friends’ list (e.g. add, remove friends, organize them in groups etc.),edit his/hers profile with new information and more.

Additionally, analytics tool will balong with a gamification related record/achievement profile.


well as. Thus, the Dashboard provides a common UI that allows the users to access all the idividual tool UIs and the services provided by the AAT. By being logged-

) the user will be able to access the UIs of all the components. The UIs ofthe tools will follow certain guidelines in order to be uniform.

Application Layer

End Integration Sub-Layer

The application layer is the core layer of the PRODUCER’s platform and is cEnd Integration Sub-Layer and the Back-End Integration Sub

Layer utilizes the Common Dashboard and a single sign on mechnism in order to integrate all the several distinct UIs in a common UI.

Authentication Manager (a.k.a Single-Sign-On Manager)

alone tool of the PRODUCER platform has been developed as a web applicationthat requires some form of authentication to access its features and services. Due to the

of the PRODUCER tools and in order to avoid asking a user’s credentialstries to access a tool, a centralized login system has become a necessity

On (SSO) authentication mechanism will be implemented allowinto have access to the platform’s tools with a single log-in procedure.

The idea of the SSO is that there is a central authentication domain, through which thethentication procedure is performed, so as to allow users to access all the differentPRODUCER platform with a single log-in.

End Integration Sub-Layer

End Integration Sub-Layer contains the back-end of the each tool that ismain functionalities and services. The tools’ back-end may communica

rectly or via the Multimedia Content Storage Search & Retrieval Tool (MCSSR) which providesAPIs for accessing the PRODUCER’s common database.

Audience Building Tool

(ABT) will be a stand-alone web-based platforming Social Media via their official API’s.

User registration on the platform will be available either directly (i.e. the user will register withhis/hers email, username, password etc.) or by using an existing Social Media accountFacebook, twitter, google etc.)

After his/her registration, the user will be able to make connections (i.e. friends) and post topichashtag) multi-media or textual content. Depending on the poster’s setprivacy, expiration date/time etc.); the posted content will be visible to

“friend’s” wall, and/or forwarded to other social media.

Amongst the registered users’ available options will be to perform searches within all available, initiate discussion threads for certain topics and participate in e

ing ones, edit his/her friends’ list (e.g. add, remove friends, organize them in groups etc.),edit his/hers profile with new information and more.

Additionally, analytics tool will be provided for monitoring the topics-specific approval/fame/etc.along with a gamification related record/achievement profile.

page 16

at allows the users to access all the in--in on the dashboard

will be able to access the UIs of all the components. The UIs of

The application layer is the core layer of the PRODUCER’s platform and is consisting of twoEnd Integration Sub-Layer. The

a single sign on mecha-

alone tool of the PRODUCER platform has been developed as a web applicationthat requires some form of authentication to access its features and services. Due to the rela-

and in order to avoid asking a user’s credentialsa centralized login system has become a necessity.

On (SSO) authentication mechanism will be implemented allowing users

, through which the au-thentication procedure is performed, so as to allow users to access all the different tools of the

tool that is responsibleend may communicate either di-

rectly or via the Multimedia Content Storage Search & Retrieval Tool (MCSSR) which provides

atform communicating

User registration on the platform will be available either directly (i.e. the user will register withhis/hers email, username, password etc.) or by using an existing Social Media account (e.g.

After his/her registration, the user will be able to make connections (i.e. friends) and post topic-epending on the poster’s set

the posted content will be visible to

Amongst the registered users’ available options will be to perform searches within all available, initiate discussion threads for certain topics and participate in ex-

ing ones, edit his/her friends’ list (e.g. add, remove friends, organize them in groups etc.),

specific approval/fame/etc.



Finally, a tool that will allow the gamification properties and parameters definition will be prvided, in order to be used by th

3.4.2.2 Integrated Trends Discovery Tool

The Integrated Trends Discovery Tool (ITD(re)orientation of documentary production ideas and estimate how appealing these contentcreation ideas will be to potential audiences. The ITDing search trends, keyword research,clude: Google tools (Google Trends and AdWords etc.), Twitter Analytics, YouTube Treand Facebook Topic data. The goal of ITDtools on content-related trends and visualize these in a user friendly manner to address theneeds of content production professionals performing research aboutopics to evaluate the respective interest of various audiences based on a number of criteria.ITDT will allow to:

Identify and evaluate audience’s generic interest for a specific topic and analyse audence’s characteristics

Identify significant dates or other time related patterns (seasonal habits) related to thetopic (This can also be important for selecting the appropriate time period for releasingthe Documentary - a common marketing practice in other areas)

Identify locations of significance related to the topic

Identify additional aspects of a topic that might not be obviously linked to it

Evaluate the additional aspects in terms of significance and correlation with the initialtopic

Identify a set of specific questions

The following sources of information have been evaluated:Words, Twitter search engineowner), Facebook (statistics and deevaluation).

Level of demographic details primarily dependsgroups whose data are accessibleSecondly depends on the data access policyof content trends (e.g., Facebook, Google). For example Facebook announced “FacebookTopic data” that will allow marketers to identify what audiences are saying on Facebook aevents, brands, subjects and activities, all in a way that keeps personal information private”. Indemographics, for instance, you get to see the region, gender, and age of your target audence. All of these details are already specified in a person’scation, the specified region will be considered as the user’s place of residence, not the geolocation, as privacy is an essential aspect of Facebook Topic Datanounced before some years it is still notchanged its data policies, restricting apps access to “friends” user data.

3.4.2.3 Open Content Discovery Tool

The Open Content Discovery Tool is a websearch across several sources of open content through a unique interface.

1 https://www.facebook.com/business/news/topic


Finally, a tool that will allow the gamification properties and parameters definition will be prvided, in order to be used by the platform administrators.

Integrated Trends Discovery Tool

The Integrated Trends Discovery Tool (ITDT) aims to support the formulation, validation and(re)orientation of documentary production ideas and estimate how appealing these content

will be to potential audiences. The ITDT will integrate existing tools for monitoing search trends, keyword research, and social media analytics. Examples of such tools iclude: Google tools (Google Trends and AdWords etc.), Twitter Analytics, YouTube Treand Facebook Topic data. The goal of ITDT is to couple the results of the various available

related trends and visualize these in a user friendly manner to address theneeds of content production professionals performing research about potential documentarytopics to evaluate the respective interest of various audiences based on a number of criteria.

Identify and evaluate audience’s generic interest for a specific topic and analyse aud

Identify significant dates or other time related patterns (seasonal habits) related to thetopic (This can also be important for selecting the appropriate time period for releasing

a common marketing practice in other areas)

tions of significance related to the topic


Evaluate the additional aspects in terms of significance and correlation with the initial

Identify a set of specific questions that internet users have for the specific topic

The following sources of information have been evaluated: Google Trends and Google, Twitter search engine, YouTube (statistics and demographics available to channel

owner), Facebook (statistics and demographics available to group owner), Reddit (ongoing

Level of demographic details primarily depends on the availability of engaged existing userdata are accessible, for instance, through their webpage or YouTube channel.

data access policy applied by the social media acting as sourcesof content trends (e.g., Facebook, Google). For example Facebook announced “FacebookTopic data” that will allow marketers to identify what audiences are saying on Facebook aevents, brands, subjects and activities, all in a way that keeps personal information private”. Indemographics, for instance, you get to see the region, gender, and age of your target audence. All of these details are already specified in a person’s Facebook account. In case of lcation, the specified region will be considered as the user’s place of residence, not the geolocation, as privacy is an essential aspect of Facebook Topic Data1. Although this was anounced before some years it is still not available. In another case in April 2015 Facebookchanged its data policies, restricting apps access to “friends” user data.

Open Content Discovery Tool

The Open Content Discovery Tool is a web-based application that aims to help users tosearch across several sources of open content through a unique interface.

https://www.facebook.com/business/news/topic-data

page 17

Finally, a tool that will allow the gamification properties and parameters definition will be pro-

) aims to support the formulation, validation and(re)orientation of documentary production ideas and estimate how appealing these content

will integrate existing tools for monitor-media analytics. Examples of such tools in-

clude: Google tools (Google Trends and AdWords etc.), Twitter Analytics, YouTube Trends,is to couple the results of the various available

related trends and visualize these in a user friendly manner to address thet potential documentary

topics to evaluate the respective interest of various audiences based on a number of criteria.

Identify and evaluate audience’s generic interest for a specific topic and analyse audi-

Identify significant dates or other time related patterns (seasonal habits) related to thetopic (This can also be important for selecting the appropriate time period for releasing


Evaluate the additional aspects in terms of significance and correlation with the initial

that internet users have for the specific topic

Google Trends and Google Ad-(statistics and demographics available to channel

mographics available to group owner), Reddit (ongoing

the availability of engaged existing userwebpage or YouTube channel.

applied by the social media acting as sourcesof content trends (e.g., Facebook, Google). For example Facebook announced “FacebookTopic data” that will allow marketers to identify what audiences are saying on Facebook aboutevents, brands, subjects and activities, all in a way that keeps personal information private”. Indemographics, for instance, you get to see the region, gender, and age of your target audi-

Facebook account. In case of lo-cation, the specified region will be considered as the user’s place of residence, not the geo-

. Although this was an-available. In another case in April 2015 Facebook

based application that aims to help users tosearch across several sources of open content through a unique interface.



The users of the tool are the producers of documentaries, which through a single access pointmay find useful multimedia materials (text, video, audio, images, etc.) to the realizatediting of professional documentaries. The tool also allows editors to search content not onlyusing keywords, but also starting from phrases via semantic search. It’s up to the tool to autmatically translate these queries into keywords and combinsearch among several sources.

Search results will be presented in an intuitive and straightforward manner, thanks to webbased user interface implemented using the best offsive and fluid applications.

The user can tag results as "preferred" in order to save specific multimedia content that areconsidered “relevant” for him. He can also choose the multimedia content to be subsequentlysent to the MCSSR to be stored and used later forContent Discovery Tool can be used to search and feed the “Multimedia Content Storage,Search & Retrieval Tool” through an integration layer implemented using standard REST APIThe Open Content Discovery Tool is a wacross several sources of open content through a unique interface.

The users of the tool are the producers of documentaries, which through a single access pointmay find useful multimedia materials (text,editing of professional documentaries. The tool also allows you to search the contents not onlyusing keywords, but allows you to do searches based on phrases and semantic search. It’s upto the tool to automatically translate these queries and combine it in an optimized format tosearch among several sources.

Search results will be presented in an intuitive and straightforward manner, thanks to webbased user interface implemented using the best offsive and fluid applications.

The user can tag some content as "preferred" in order to save particular multimedia contentthat are considered “relevant” for him. He also can choose the multimedia content to be susequently sent to the shared repository system can be saved on it. Hence the Open ContentDiscovery Tool can be used to search and feed the “Multimedia Content Storage, Search &Retrieval Tool” through an integration layer implemented using standard REST API

3.4.2.4 Automatic Annotation Tool

The ΑΑT is an application to annotate the multimedia content (videos in our case) automaticaly. Its main functionality is to detect faces and objects. In a secondary step it tries to recognizethe detected faces/objects, by trying to

The detection process can be parametrized on its precision and accuracy. Moreover an avanced user has the ability to add custom prelike eyes, nose, etc.

The recognition process will be based on a training set of faces and objects. The completness of the training set will affect the accuracy of the detection process

3.4.2.5 Interactive-enriched Video Creation Tool

Interactive Video Tool creates an interactive venabling your audience to explore shop, learn and play while they watch video. Interactive andtime independent navigation opens new ways to enrich video content

Interactive Video Tool technology opens up new ways of interaction between the content andyourthe target audience. Clickable objects turn the raw video content into an interactive videosurface. The viewer decides what kind of information and level of det


The users of the tool are the producers of documentaries, which through a single access pointmay find useful multimedia materials (text, video, audio, images, etc.) to the realizat

iting of professional documentaries. The tool also allows editors to search content not onlyusing keywords, but also starting from phrases via semantic search. It’s up to the tool to autmatically translate these queries into keywords and combine them in an optimized format tosearch among several sources.

Search results will be presented in an intuitive and straightforward manner, thanks to webbased user interface implemented using the best off-the-shelf technologies to create respo

The user can tag results as "preferred" in order to save specific multimedia content that areconsidered “relevant” for him. He can also choose the multimedia content to be subsequentlysent to the MCSSR to be stored and used later for documentary production. Hence the OpenContent Discovery Tool can be used to search and feed the “Multimedia Content Storage,Search & Retrieval Tool” through an integration layer implemented using standard REST APIThe Open Content Discovery Tool is a web-based application aims helping users to searchacross several sources of open content through a unique interface.

The users of the tool are the producers of documentaries, which through a single access pointmay find useful multimedia materials (text, video, audio, images, etc.) to the realization and

iting of professional documentaries. The tool also allows you to search the contents not onlyusing keywords, but allows you to do searches based on phrases and semantic search. It’s up

tomatically translate these queries and combine it in an optimized format tosearch among several sources.

Search results will be presented in an intuitive and straightforward manner, thanks to webbased user interface implemented using the best off-the-shelf technologies to create respo

The user can tag some content as "preferred" in order to save particular multimedia contentthat are considered “relevant” for him. He also can choose the multimedia content to be su

y sent to the shared repository system can be saved on it. Hence the Open ContentDiscovery Tool can be used to search and feed the “Multimedia Content Storage, Search &Retrieval Tool” through an integration layer implemented using standard REST API

matic Annotation Tool

The ΑΑT is an application to annotate the multimedia content (videos in our case) automaticaly. Its main functionality is to detect faces and objects. In a secondary step it tries to recognizethe detected faces/objects, by trying to match them with faces/objects from a current dataset.

The detection process can be parametrized on its precision and accuracy. Moreover an avanced user has the ability to add custom pre-trained datasets to detect face characteristics

The recognition process will be based on a training set of faces and objects. The completness of the training set will affect the accuracy of the detection process.

enriched Video Creation Tool

Interactive Video Tool creates an interactive video experience. Objects are clickable and areenabling your audience to explore shop, learn and play while they watch video. Interactive andtime independent navigation opens new ways to enrich video content

Interactive Video Tool technology opens up new ways of interaction between the content andyourthe target audience. Clickable objects turn the raw video content into an interactive videosurface. The viewer decides what kind of information and level of detail he wants to receive in

page 18

The users of the tool are the producers of documentaries, which through a single access pointmay find useful multimedia materials (text, video, audio, images, etc.) to the realization and

iting of professional documentaries. The tool also allows editors to search content not onlyusing keywords, but also starting from phrases via semantic search. It’s up to the tool to auto-

e them in an optimized format to

Search results will be presented in an intuitive and straightforward manner, thanks to web-shelf technologies to create respon-

The user can tag results as "preferred" in order to save specific multimedia content that areconsidered “relevant” for him. He can also choose the multimedia content to be subsequently

documentary production. Hence the OpenContent Discovery Tool can be used to search and feed the “Multimedia Content Storage,Search & Retrieval Tool” through an integration layer implemented using standard REST API.

based application aims helping users to search

The users of the tool are the producers of documentaries, which through a single access pointvideo, audio, images, etc.) to the realization and

iting of professional documentaries. The tool also allows you to search the contents not onlyusing keywords, but allows you to do searches based on phrases and semantic search. It’s up

tomatically translate these queries and combine it in an optimized format to

Search results will be presented in an intuitive and straightforward manner, thanks to web-helf technologies to create respon-

The user can tag some content as "preferred" in order to save particular multimedia contentthat are considered “relevant” for him. He also can choose the multimedia content to be sub-

y sent to the shared repository system can be saved on it. Hence the Open ContentDiscovery Tool can be used to search and feed the “Multimedia Content Storage, Search &Retrieval Tool” through an integration layer implemented using standard REST API.

The ΑΑT is an application to annotate the multimedia content (videos in our case) automatical-ly. Its main functionality is to detect faces and objects. In a secondary step it tries to recognize

match them with faces/objects from a current dataset.

The detection process can be parametrized on its precision and accuracy. Moreover an ad-trained datasets to detect face characteristics

The recognition process will be based on a training set of faces and objects. The complete-

ideo experience. Objects are clickable and areenabling your audience to explore shop, learn and play while they watch video. Interactive and

Interactive Video Tool technology opens up new ways of interaction between the content andyourthe target audience. Clickable objects turn the raw video content into an interactive video

ail he wants to receive in



addition to the video. Therefore Interactive Video Tool supports a variety of supplemental content as video, audio, images, text, documents up to seamless integration of web contents andsocial media. Video content, enriched witengages and entertain viewers and allows for advanced storylines and character development.

Interactive Video Tool Key facts:

Interactivity through clickable video objects

Content Management

Video Delivery and Syndication

Branded and customized Players for all major platforms

360° Video Support

3.4.2.6 360° Video Playout Tool

The Cloud-based 360° Video Playout enables high quality 360° video experience on low cpability devices, such as Hybrid TVs (HbbTV),e.g. on mobile devices. In 360° video the full spherical image of any direction of view is availble in every moment while the spectator can freely change her individual perspective of view.The delivery of this huge source video material consumes a large bandwidth and results in aconsiderable processing load for the view projection and rendering. Devices as HbbTV Termnals are not capable, in terms of programmatic features, of performing the necessary imagetransformations.

The Cloud-based 360° Video Playout for HbbTV performs the rendering of the individual viewon server side so that only the selected video content is streamed to the end device. This rduces the bandwidth needed or, put the other way aroundlivered on a given bandwidth. It also diminishes the requirements for the end device to simplyplay back a usual video stream in order to provide the full 360° video experience.

3.4.2.7 Second Screen Framework

The Second Screen Framework is an implementation of upcoming web standards and tecnologies related to key multiscreen features such as discovery, pairing, launch, communicationand synchronization of apps and media across multiple devices. It provides technologies toconnect multiple screens together so that applications can make use of and interact directlywith all accessible screens. As a result, application developers are able to provide a better uer experience and create a richer content presentation to the user. Mrequire thinking about aspects that do not necessarily have to be addressed when buildingsingle-screen applications. This, for example, includes discovery, synchronization, adaptationand distribution of content, security and alignerating systems. The Second Screen Frameworkcomprehensive solution for multiscreen application development and deployment.

3.4.2.8 Social Recommendation & Personalization To

The SRPtool can be used as amentary, by filtering enrichments and/or providing enrichment suggestions to the IeVC toolbased on the targeted audience preferencessystem whose job is to recommend content in a personalized manner. When a new user iscreated in the PRODUCER platform, a user record is created in the SRP tool database. As theuser interacts with the content on


addition to the video. Therefore Interactive Video Tool supports a variety of supplemental content as video, audio, images, text, documents up to seamless integration of web contents andsocial media. Video content, enriched with such kind of features, increases viewer retention,engages and entertain viewers and allows for advanced storylines and character development.

Interactive Video Tool Key facts:

Interactivity through clickable video objects

Delivery and Syndication

Branded and customized Players for all major platforms

360° Video Playout Tool

based 360° Video Playout enables high quality 360° video experience on low cpability devices, such as Hybrid TVs (HbbTV), or in cases of constrained network connectivitye.g. on mobile devices. In 360° video the full spherical image of any direction of view is availble in every moment while the spectator can freely change her individual perspective of view.

his huge source video material consumes a large bandwidth and results in aconsiderable processing load for the view projection and rendering. Devices as HbbTV Termnals are not capable, in terms of programmatic features, of performing the necessary image

based 360° Video Playout for HbbTV performs the rendering of the individual viewon server side so that only the selected video content is streamed to the end device. This rduces the bandwidth needed or, put the other way around, allows for a higher quality video dlivered on a given bandwidth. It also diminishes the requirements for the end device to simplyplay back a usual video stream in order to provide the full 360° video experience.

Second Screen Framework

n Framework is an implementation of upcoming web standards and tecnologies related to key multiscreen features such as discovery, pairing, launch, communicationand synchronization of apps and media across multiple devices. It provides technologies to

nnect multiple screens together so that applications can make use of and interact directlywith all accessible screens. As a result, application developers are able to provide a better uer experience and create a richer content presentation to the user. Multiscreen applicationsrequire thinking about aspects that do not necessarily have to be addressed when building

screen applications. This, for example, includes discovery, synchronization, adaptationand distribution of content, security and alignment of user preferences all across different o

The Second Screen Framework addresses all these topics and provides acomprehensive solution for multiscreen application development and deployment.

Social Recommendation & Personalization Tool

The SRPtool can be used as a post production tool to create different “versions” of the docmentary, by filtering enrichments and/or providing enrichment suggestions to the IeVC toolbased on the targeted audience preferences. In PRODUCER, it acts as a recommendationsystem whose job is to recommend content in a personalized manner. When a new user iscreated in the PRODUCER platform, a user record is created in the SRP tool database. As theuser interacts with the content on the platform, the user's profile is updated. When the PR

page 19

addition to the video. Therefore Interactive Video Tool supports a variety of supplemental con-tent as video, audio, images, text, documents up to seamless integration of web contents and

h such kind of features, increases viewer retention,engages and entertain viewers and allows for advanced storylines and character development.

based 360° Video Playout enables high quality 360° video experience on low ca-or in cases of constrained network connectivity

e.g. on mobile devices. In 360° video the full spherical image of any direction of view is availa-ble in every moment while the spectator can freely change her individual perspective of view.

his huge source video material consumes a large bandwidth and results in aconsiderable processing load for the view projection and rendering. Devices as HbbTV Termi-nals are not capable, in terms of programmatic features, of performing the necessary image

based 360° Video Playout for HbbTV performs the rendering of the individual viewon server side so that only the selected video content is streamed to the end device. This re-

, allows for a higher quality video de-livered on a given bandwidth. It also diminishes the requirements for the end device to simplyplay back a usual video stream in order to provide the full 360° video experience.

n Framework is an implementation of upcoming web standards and tech-nologies related to key multiscreen features such as discovery, pairing, launch, communicationand synchronization of apps and media across multiple devices. It provides technologies to

nnect multiple screens together so that applications can make use of and interact directlywith all accessible screens. As a result, application developers are able to provide a better us-

ultiscreen applicationsrequire thinking about aspects that do not necessarily have to be addressed when building

screen applications. This, for example, includes discovery, synchronization, adaptationment of user preferences all across different op-

addresses all these topics and provides acomprehensive solution for multiscreen application development and deployment.

post production tool to create different “versions” of the docu-mentary, by filtering enrichments and/or providing enrichment suggestions to the IeVC tool

. In PRODUCER, it acts as a recommendationsystem whose job is to recommend content in a personalized manner. When a new user iscreated in the PRODUCER platform, a user record is created in the SRP tool database. As the

the platform, the user's profile is updated. When the PRO-



DUCER platform wants to propose content to a user, it will ask the SRP tool for the most apropriate content to provide, which will be personalized and tailored to the user’s profile, preerences and interaction history. Theprofiles of other similar users.

Recommendation of content can also be provided to content providers seeking appropriatecontent for a specific target group, based on the Seo, enrichments can be paired with it to provide a richer user experience. The SRP tool can beused as a post production tool to create different "versions" of trichments based on the target groups' preferences.

3.5 Data Layer

In the data layer resides the PRODUCER’s common database in which all the shared infomation (e.g. multimedia contents) is stored. Through the& Retrieval (MCSSR) Tool and its proany other tool.


Except from each tool’s database a common repository/database was decided to be used forthe storage of multimedia contents. The common dthe overall architecture and can be accessed by any tool of the platform that utilizes the Multimedia Content Storage, Search & Retrieval (MCSSR) Tool.

The MCSSR will provide the ability to search, save, andSuch contents can originate from legacy multimedia systems or populated through researchwith the Open Content Discovery Tool.

The MCSSR encapsulates several components, such as storage, search including metadata,editing and converting content, and intelligent partition into categories, along with savingmetadata generated by the Automatic Annotation Tool. The MCSSR thus represents the coreof the multimedia contents of the entire PRODUCER framework, providing intecomponents of the overall architecture that can interact with it, reading, editing, deleting anduploading data.

The final users of the tool will be the producers who will interact with the MCSSR using an ituitive graphical user interface

4 Integration Methodology

The overall time-scheduling for the platform’s integration activities are defined and describedin this section, starting from M6shown in

Figure 5. It should be noted that the same period also coincides on the timespan that WP4 isactive.


DUCER platform wants to propose content to a user, it will ask the SRP tool for the most apropriate content to provide, which will be personalized and tailored to the user’s profile, pre

interaction history. The respective content recommendations may also consider the

Recommendation of content can also be provided to content providers seeking appropriatecontent for a specific target group, based on the SRPT's user database. After creating the vieo, enrichments can be paired with it to provide a richer user experience. The SRP tool can beused as a post production tool to create different "versions" of the documentary, by filtering e

e target groups' preferences.

In the data layer resides the PRODUCER’s common database in which all the shared infomation (e.g. multimedia contents) is stored. Through the Multimedia Content Storage, Search

and its provided APIs the common database can be accessed by

Multimedia Content Storage, Search & Retrieval Tool

Except from each tool’s database a common repository/database was decided to be used forthe storage of multimedia contents. The common database is located within the Data layer ofthe overall architecture and can be accessed by any tool of the platform that utilizes the Multimedia Content Storage, Search & Retrieval (MCSSR) Tool.

The MCSSR will provide the ability to search, save, and view all available multimedia contents.Such contents can originate from legacy multimedia systems or populated through researchwith the Open Content Discovery Tool.

The MCSSR encapsulates several components, such as storage, search including metadata,editing and converting content, and intelligent partition into categories, along with savingmetadata generated by the Automatic Annotation Tool. The MCSSR thus represents the coreof the multimedia contents of the entire PRODUCER framework, providing intecomponents of the overall architecture that can interact with it, reading, editing, deleting and

The final users of the tool will be the producers who will interact with the MCSSR using an ituitive graphical user interface that is used through the browser.

Methodology Timeline

for the platform’s integration activities are defined and describedfrom M6 and spanning throughout the project’s lifetime (i.e. M18)

It should be noted that the same period also coincides on the timespan that WP4 is

page 20

DUCER platform wants to propose content to a user, it will ask the SRP tool for the most ap-propriate content to provide, which will be personalized and tailored to the user’s profile, pref-

content recommendations may also consider the

Recommendation of content can also be provided to content providers seeking appropriateRPT's user database. After creating the vid-

eo, enrichments can be paired with it to provide a richer user experience. The SRP tool can behe documentary, by filtering en-

In the data layer resides the PRODUCER’s common database in which all the shared infor-Multimedia Content Storage, Search

vided APIs the common database can be accessed by

Except from each tool’s database a common repository/database was decided to be used foratabase is located within the Data layer of

the overall architecture and can be accessed by any tool of the platform that utilizes the Multi-

view all available multimedia contents.Such contents can originate from legacy multimedia systems or populated through research

The MCSSR encapsulates several components, such as storage, search including metadata,editing and converting content, and intelligent partition into categories, along with savingmetadata generated by the Automatic Annotation Tool. The MCSSR thus represents the coreof the multimedia contents of the entire PRODUCER framework, providing interfaces to othercomponents of the overall architecture that can interact with it, reading, editing, deleting and

The final users of the tool will be the producers who will interact with the MCSSR using an in-

for the platform’s integration activities are defined and describedout the project’s lifetime (i.e. M18), as

It should be noted that the same period also coincides on the timespan that WP4 is



Figure

In order to facilitate the integration process and to have a more structured and easier orgaized management of the integration activities, the aforementioned period, of 13 months in total,has been split in 3 sub-periods, with well defined, distinct but complementary activities, as dscribed in the following paragraphs of this section.

4.1 Ramp-up phase (standalone tools)

The ramp-up phase rendersPRODUCER platform that spans from M6 untilure 6.

The activities it covers and are planned to be finalized during the aforementioned period aredescribed in Table 2.


Figure 5: Exemplary Integration Timeline

In order to facilitate the integration process and to have a more structured and easier orgaintegration activities, the aforementioned period, of 13 months in total,

periods, with well defined, distinct but complementary activities, as dscribed in the following paragraphs of this section.

up phase (standalone tools)

the initiation/preparation phase of the integration period for thethat spans from M6 until end of M12 as illustrated in the timeline of

Figure 6: Ramp-up phase

it covers and are planned to be finalized during the aforementioned period are

Signifies the end of the month

MS signifies project milestone

D signifies project deliverable

page 21

In order to facilitate the integration process and to have a more structured and easier organ-integration activities, the aforementioned period, of 13 months in total,

periods, with well defined, distinct but complementary activities, as de-

the integration period for theas illustrated in the timeline of Fig-

it covers and are planned to be finalized during the aforementioned period are

Signifies the end of the month

signifies project milestone

signifies project deliverable



Step Activities

Build Development of each stand Front/Back end development of each tool

Integration/Validation

Integration Identification of specifications & requirements for integration Definition of the hybrid components Definition and implementation of the tools’ interfaces Validation of each stand Implementation of the single sign on mechani

Deployment Deployment of stand

4.2 Core Integration phase

The second phase regards the main integration phasecovering a wide-range of application from the preduction phase itself will be integrated into the PRODUCER platthe specifications and the architecture of the latter. This phase is sch

M15, as also shown in Figure

Figure

The activities are planned to be carried out during

Step Activities

Build Corrective actions for each tool and for the platform as

Integration/Validation Development/finalization of the common Front Verification of the implemented interfaces

Deployment Validation of the data flows in the integrated platform


Table 2: Ramp-up activities

Activities

Development of each stand-alone toolFront/Back end development of each tool

Integration methodology planningIdentification of specifications & requirements for integrationDefinition of the hybrid componentsDefinition and implementation of the tools’ interfacesValidation of each stand-alone toolImplementation of the single sign on mechanism

Deployment of stand-alone tools

Integration phase

regards the main integration phase, whereby the distinctly developedrange of application from the pre-production, the post-production and the pr

integrated into the PRODUCER platform prototypethe specifications and the architecture of the latter. This phase is scheduled to span from M13

Figure 7.

Figure 7: Integration phase deployment planning

The activities are planned to be carried out during this core period are described in

Table 3: Integration phase activities

Activities

Corrective actions for each tool and for the platform as

Development/finalization of the common Front-endVerification of the implemented interfaces

Validation of the data flows in the integrated platform

page 22

Identification of specifications & requirements for integration

Definition and implementation of the tools’ interfaces

, whereby the distinctly developed toolsproduction and the pro-prototype, according to

eduled to span from M13-

period are described in Table 3.

Corrective actions for each tool and for the platform as whole based on DAT

Validation of the data flows in the integrated platform



4.3 Demo/Pilot phase

Last but not least, the finalmethodology (see Section 5.2.1lect bugs and feedback, and apply any final corrective actions on the integrated platform

phase spans from M16-M18, as shown in

Figure

The activities are planned to be carried out during the Demo/Pilot period are described inble 4, below.

Step Activities

Build Final Build of integrated platform

Integration/Validation Application of corrective actions based

Deployment Deployment o

Evaluation Evaluation of the final platform base


phase regards the application of the Pilot Acceptance5.2.1) in a simulated end-user environment in order to furthe

lect bugs and feedback, and apply any final corrective actions on the integrated platform

M18, as shown in Figure 8.

Figure 8: Demo phase deployment planning

The activities are planned to be carried out during the Demo/Pilot period are described in

Table 4: Demo/Pilot phase activities

Activities

Final Build of integrated platform

Application of corrective actions based on PAT

Deployment of the final integrated platform

Evaluation of the final platform based on users’ feedback (e.g. questionnaires)

page 23

ilot Acceptance Testinguser environment in order to further col-

lect bugs and feedback, and apply any final corrective actions on the integrated platform. This

The activities are planned to be carried out during the Demo/Pilot period are described in Ta-

on users’ feedback (e.g. questionnaires)



5 Testing Process Management

As it also becomes apparent from the basic integration steps descriptionsSection 2 (see also Figure 1)specific tools that are meant to facilitate the Testing “subtion presents some widely known tools and methodologies that are meant to facilitate the Tesing Process during the PRODUCER’s platform integration.

5.1 Software Quality Assurance

The requirements of a software quality model are a necessarycedure. Figure 9 presents seve

Figure 9

The technical quality concept adopted by PRODUCER includes both the endDIASET, FlyingEye, Domino ProductionsICCS, FOCUS & FINCONS) perspective

5.1.1 Software Quality Models

PRODUCER developers need a comprehensive model for the early evaluation of softwarequality. There are many software product quality models that defineing software quality.

Three commonly used models are

McCall's model [3] includes& transition.

Boehm's model [4] is based on a wider range of characteristics anddependent criteria thatpen especially whenprocess.

FURPS model [10] stands for functionality, usability, reliability, performance and suportability. These characteristics can be used as both product requirements and inproduct quality assessment.

Dromey's model [11] consists of three principal elements, namely 4 product propeties, 13 quality attributes and means of linking them.

ISO/IEC 25010 modelnumber of attributes.


Process Management

becomes apparent from the basic integration steps descriptions, the “Integration & Testing” step requires the utilization of some

specific tools that are meant to facilitate the Testing “sub-step”. In this respect, the current sely known tools and methodologies that are meant to facilitate the Tes

ing Process during the PRODUCER’s platform integration.

Assurance

a software quality model are a necessary prerequisiteseveral perspectives on software quality [2]:

9: Several perspectives on software quality.

The technical quality concept adopted by PRODUCER includes both the endDIASET, FlyingEye, Domino Productions) perspective and the developer partners’ (i.e.

perspective.

Quality Models

PRODUCER developers need a comprehensive model for the early evaluation of softwarequality. There are many software product quality models that define several

used models are summarized below:

includes eleven criteria encompassing product operation, revision

is based on a wider range of characteristics anda that interact with each other and often cause conflict

especially when these criteria are incorporated into the software development

stands for functionality, usability, reliability, performance and suThese characteristics can be used as both product requirements and in

product quality assessment.

[11] consists of three principal elements, namely 4 product propeties, 13 quality attributes and means of linking them.

model [5] includes eight quality characteristics, each having a large

page 24

becomes apparent from the basic integration steps descriptions in the beginning ofrequires the utilization of some

step”. In this respect, the current sec-ly known tools and methodologies that are meant to facilitate the Test-

prerequisite for the testing pro-

The technical quality concept adopted by PRODUCER includes both the end-users’ (i.e. ME-and the developer partners’ (i.e. HIT,

PRODUCER developers need a comprehensive model for the early evaluation of softwareral attributes concern-

criteria encompassing product operation, revision

is based on a wider range of characteristics and includes nineteeninteract with each other and often cause conflict. Conflicts hap-

into the software development

stands for functionality, usability, reliability, performance and sup-These characteristics can be used as both product requirements and in

[11] consists of three principal elements, namely 4 product proper-

eight quality characteristics, each having a large



The criteria and goals defined in each of these models areModel includes a number of criteria under its characteristics of maintainability.

Criteria/Characteristics

Correctness

Reliability

Integrity

Usability

Efficiency

Maintainability

Testability

Interoperability

Flexibility

Reusability

Portability

Clarity

Modifiability

Documentation

Resilience

Understandability

Validity

Functionality

Generality

Economy

Criteria in McCall's and Boehm's model are not independent; they interact with each other andoften cause conflict, especially when software providers try to incorporate them into the software development process. Out ofand comprehensive one and will therefore beprocess of the PRODUCER platformincorporating some of quality model characteristics into our online quality analysis tool (seeSection 6.2).

5.1.2 The ISO/IEC 25010 Model

The software product quality encompasses three gradually dependent dimensions in theISO/IEC 25010 model:

“Internal quality” refers to the developer perspective on static aspects of the system,for example the architecture & implementation of the system.

“External quality” refers to the externally observed behaviour and functioning of thesystem either when it is executed or it


The criteria and goals defined in each of these models are listed in TableModel includes a number of criteria under its characteristics of maintainability.

Table 5: Software Quality Models

McCall Boehm FURPS Dromey

X X X

X X X X

X X

X X X X

X X X X

X X X X

X X

X

X X

X X X

X X X

X

X

X

X

X

X X

X

X

in McCall's and Boehm's model are not independent; they interact with each other andoften cause conflict, especially when software providers try to incorporate them into the soft

Out of all these models, the ISO 25010 model is tand comprehensive one and will therefore be adopted in the quality assurance and validationprocess of the PRODUCER platform prototype. To achieve that, we will make best efforts forincorporating some of quality model characteristics into our online quality analysis tool (see

The ISO/IEC 25010 Model

The software product quality encompasses three gradually dependent dimensions in the

refers to the developer perspective on static aspects of the system,for example the architecture & implementation of the system.

refers to the externally observed behaviour and functioning of thesystem either when it is executed or it is hosted in a simulated/controlled environment.

page 25

Table 5. Note that the ISOModel includes a number of criteria under its characteristics of maintainability.

Dromey ISO/IEC 25010

maintainability

X

X

X

X

maintainability

X

maintainability

maintainability

X

in McCall's and Boehm's model are not independent; they interact with each other andoften cause conflict, especially when software providers try to incorporate them into the soft-

these models, the ISO 25010 model is the most recentin the quality assurance and validation

. To achieve that, we will make best efforts forincorporating some of quality model characteristics into our online quality analysis tool (see

The software product quality encompasses three gradually dependent dimensions in the

refers to the developer perspective on static aspects of the system,

refers to the externally observed behaviour and functioning of theis hosted in a simulated/controlled environment.



“Quality in use” refers to user's perception of the system quality, while achievinggoals in a particular environment/context of use.

The internal & external qualitycharacteristics as depicted inmodel for quality assessment of a software system and will be addressed by a quality inspetion tool (see Section 6.2) throughout the varioity assurance process prior to site deployments.

Figure 10: ISO/IEC 25010 Quality model for external and internal quality

The quality in use conveys user's perspective on the systemcharacteristics of the quality in use

the end user. Quality in use can be used complementary to considering the quality of the sytem to refer to the overall capability of the system to enable specified users to achieve goalsconcerning its quality characteristics, such as effectiveness, productivity, safetusability. The quality in use is measured by the results of its concrete usage in context, ratherthan by properties of the software itself. Its evaluation will involve participation of developersworking with the PRODUCER platform


refers to user's perception of the system quality, while achievinggoals in a particular environment/context of use.

internal & external quality is modelled in terms of eight characteristics and numerous subcharacteristics as depicted in Figure 10. These characteristics provide a valuable, himodel for quality assessment of a software system and will be addressed by a quality inspe

) throughout the various stages of the PRODUCER testing and quaity assurance process prior to site deployments.

: ISO/IEC 25010 Quality model for external and internal quality

conveys user's perspective on the system quality. Figurequality in use that refers to system’s effective usage and perception by

can be used complementary to considering the quality of the sytem to refer to the overall capability of the system to enable specified users to achieve goalsconcerning its quality characteristics, such as effectiveness, productivity, safet

is measured by the results of its concrete usage in context, ratherthan by properties of the software itself. Its evaluation will involve participation of developersworking with the PRODUCER platform prototype.

page 26

refers to user's perception of the system quality, while achieving

is modelled in terms of eight characteristics and numerous sub-. These characteristics provide a valuable, high-level

model for quality assessment of a software system and will be addressed by a quality inspec-us stages of the PRODUCER testing and qual-

: ISO/IEC 25010 Quality model for external and internal quality

Figure 11 summarizes thethat refers to system’s effective usage and perception by

can be used complementary to considering the quality of the sys-tem to refer to the overall capability of the system to enable specified users to achieve goalsconcerning its quality characteristics, such as effectiveness, productivity, safety, satisfaction &

is measured by the results of its concrete usage in context, ratherthan by properties of the software itself. Its evaluation will involve participation of developers



Figure

5.2 PRODUCER’s Testing

The testing approach that is followed during the various software development phases dpends on a wide range of issues such as

the time point within the integration procedure and the regularity that the testing will beperformed,

the responsible people for the testing (developers, independent testers),

the kind of pieces that will be tested (samples, everything, nothing),

the level of knowledge about the component under testing (blacking),

the extent to which the testing will be performed (exhaustive testing, no testing).

Apart from all these issues, another factor that plays important role in the definition of the tesing approach is the development approach followed. The PRODUCER’s developmengress continuously in an iterative & incremental way with the different partners integratingregularly their components in several cycles of analysis, development & validation. Thus,automated testing, whenever possible, seems to be necessary durdevelopment phases with adjusted extentstant. For example, the main objective of a demonstrator application is to demonstrate a partialfunctionality and for this reason, testingtime instant. All in all, an appropriate testing methodology according to PRODUCER‘s deveopment approach could be the “agile” or “lean” methodology

5.2.1 PRODUCER’s Agile Testing Levels

There are four (4) different levels of testing in the agile approach [

1. Unit testing: Verifyingindividual component in terms of

2. Integration testing: Testing oftem in combination to assess if they work correctly together.

3. System testing or Developers Acceptance Testing (DAT):tem as a whole.

4. Validation: Evaluation at therequirements fulfilment. In context of PRODUCER, the validation will be done through


Figure 11: Quality in use characteristics

Testing Methodology

The testing approach that is followed during the various software development phases dpends on a wide range of issues such as [6]:

the time point within the integration procedure and the regularity that the testing will be



the level of knowledge about the component under testing (black-box or white

extent to which the testing will be performed (exhaustive testing, no testing).

Apart from all these issues, another factor that plays important role in the definition of the tesing approach is the development approach followed. The PRODUCER’s developmengress continuously in an iterative & incremental way with the different partners integratingregularly their components in several cycles of analysis, development & validation. Thus,

testing, whenever possible, seems to be necessary during the PRODUCER projectdevelopment phases with adjusted extent in relation to the platform’s needs at each time i

For example, the main objective of a demonstrator application is to demonstrate a partialfunctionality and for this reason, testing the final system as a whole is out of the scope for this

an appropriate testing methodology according to PRODUCER‘s deveopment approach could be the “agile” or “lean” methodology [7].

PRODUCER’s Agile Testing Levels

different levels of testing in the agile approach [8]:

Verifying each part of the software by isolating it and thenin terms of fulfilling requirements & the desired functionality.

Testing of the communication between different parts of the sytem in combination to assess if they work correctly together.

Developers Acceptance Testing (DAT): Testing of

Evaluation at the final phases of development and integrationrequirements fulfilment. In context of PRODUCER, the validation will be done through

page 27

The testing approach that is followed during the various software development phases de-

the time point within the integration procedure and the regularity that the testing will be



box or white-box test-

extent to which the testing will be performed (exhaustive testing, no testing).

Apart from all these issues, another factor that plays important role in the definition of the test-ing approach is the development approach followed. The PRODUCER’s development will pro-gress continuously in an iterative & incremental way with the different partners integratingregularly their components in several cycles of analysis, development & validation. Thus,

ing the PRODUCER projectin relation to the platform’s needs at each time in-

For example, the main objective of a demonstrator application is to demonstrate a partialthe final system as a whole is out of the scope for this

an appropriate testing methodology according to PRODUCER‘s devel-

each part of the software by isolating it and then testing eachthe desired functionality.

the communication between different parts of the sys-

Testing of the entire sys-

and integration to ensurerequirements fulfilment. In context of PRODUCER, the validation will be done through



Pilots Acceptance Testing (tors.

In this respect, Figure 8 presents the testing levels of the agiletance of the sequence among the testing levels should be noted.

Software should first be unit tested, integration tests should follow andDAT) should be performed to the whole integrated platform from the developers of the systemFinally, the system will be tested and evaluated during thesimulated environment as they will be described in D4.3proach with two prototyping cycles, there might be interleaving or backtracking of these testingactivities. Unit testing will be performed for each standalone tool of the PRODUCER platformprototype during the ramp-up phase of the project abe described further in this document). System testing and Validation of all the integratedbusiness scenarios and defined KPIs will be performed based on thedescribed in D4.3 (so it will not be further described in this document). In the following sectionthe integration testing approach for PRODUCER is described.

5.2.2 PRODUCER’s Integration Testing

The integration testing plan can be seen in the following table, where the testing activitifrequency of testing and the responsibilities concerning the testing processes areHere it should be noted that the person responsiblesponsible for writing tests and executing themthe system tests.

Table

Level ofTesting

Activities

IntegrationSelect test

casesContinuous I

tegration Infr


cceptance Testing (PAT) during the execution of the PRODUCER demonstr

presents the testing levels of the agile methodology. Here the impotance of the sequence among the testing levels should be noted.

Figure 12: Agile Testing Levels

Software should first be unit tested, integration tests should follow and nextto the whole integrated platform from the developers of the system

Finally, the system will be tested and evaluated during the demos/pilots (PATsimulated environment as they will be described in D4.3. As PRODUCER hasproach with two prototyping cycles, there might be interleaving or backtracking of these testingactivities. Unit testing will be performed for each standalone tool of the PRODUCER platform

up phase of the project and will be dealt with in WP3 (so it will notbe described further in this document). System testing and Validation of all the integratedbusiness scenarios and defined KPIs will be performed based on the demo/

ill not be further described in this document). In the following sectionthe integration testing approach for PRODUCER is described.

PRODUCER’s Integration Testing

The integration testing plan can be seen in the following table, where the testing activitifrequency of testing and the responsibilities concerning the testing processes areHere it should be noted that the person responsible for integration testing (HIT) is not also rsponsible for writing tests and executing them, but is responsible for ensur

Table 6: Software Integration Test Plan

Test environ-ment(s)

Frequency ofTesting

Responsible

Writing testcases

Proviing test

Continuous In-tegration Infra-

Automatedtests run

ComponentProvider

page 28

AT) during the execution of the PRODUCER demonstra-

methodology. Here the impor-

next system testing (orto the whole integrated platform from the developers of the system.

(PAT/Demo) in a user. As PRODUCER has an iterative ap-

proach with two prototyping cycles, there might be interleaving or backtracking of these testingactivities. Unit testing will be performed for each standalone tool of the PRODUCER platform

nd will be dealt with in WP3 (so it will notbe described further in this document). System testing and Validation of all the integrated

demo/pilot testing, to beill not be further described in this document). In the following section

The integration testing plan can be seen in the following table, where the testing activities, thefrequency of testing and the responsibilities concerning the testing processes are summarized.

for integration testing (HIT) is not also re-ensuring the execution of

Responsible

Provid-ing test

data

Runningtests

Inte-gration

IntegrationTeam



Manage unitdependencies

Write auto-mated testcases

Prepare non-automated testcases

structure

5.2.3 Integration testing approach

In the PRODUCER context, an integration test is a test over several worktion tests are grey box tests. This means that a complete workflow will be tested and the rsults will be checked. The workflow structure and implementation is partially known and cosidered.

All integration tests will be executed by Jenbased Continuous Integration server. Continuous Integration is the practice of running tests onnon-developer hardware automatically every time a developer pushes new code into thesource repository (e.g. a Git repository). Jenkins achieves Continuous Integration via plugins,which allow the integration of various DevOps stages. For the integration of a particular tool,the respective plugin needs to be installed, e.g. Git, Maven, etc.

HIT will be responsible for setting up Jenkins where each partner will be able to write and runtheir pipelines/tests for continuous testing their back

The main plan that is proposed for continuous integration and testing, which also conforms tothe typical workflow of Jenkins Continuous Integration server is the following:

1. Define integration tests for individual componentscording to plan for each component to be written as Jenkins pipelines.

2. Create a Jenkins pipeline for each testWhen a step succeeds, the pipeline moves onto the next step. When a step fails toexecute correctly, theeach of the continuous integration stages (Btives which can be defined in a

3. Define an execution environmentand how to execute pipelines (or even subsets of them). Via these directives, fithe steps contained within a pipeline are queued for execution. As soon as an executorbecomes available, the steps will start executing. Second, a workspace is allocatedthat will contain all files checked out from source control, as well as anyworking files for the pipeline. A pipeline is able to use Docker images and containers torun inside. This allows the pipeline to define the environment and tools required withouthaving to configure various system tools and dependencies manuall

4. Record test results and artefactsthe use of a special postures, it is often useful to grab built artefacts, files generated during the epipeline, from Jenkins to local analysis and investigation.Jenkins’s built-in support for storing "artefacts" and is done through thetive.


structure continuouslywhen com-ponents arebuilt on theContinuousIntegrationInfrastructure

Manualtests, at leasteach itera-tion

whosecomponentis callinganothercomponent

testing approach

In the PRODUCER context, an integration test is a test over several worktion tests are grey box tests. This means that a complete workflow will be tested and the rsults will be checked. The workflow structure and implementation is partially known and co

All integration tests will be executed by Jenkins [16] after a successful build. Jenkins is a Javabased Continuous Integration server. Continuous Integration is the practice of running tests on

developer hardware automatically every time a developer pushes new code into theg. a Git repository). Jenkins achieves Continuous Integration via plugins,

which allow the integration of various DevOps stages. For the integration of a particular tool,the respective plugin needs to be installed, e.g. Git, Maven, etc.

sible for setting up Jenkins where each partner will be able to write and runtheir pipelines/tests for continuous testing their back-end.

The main plan that is proposed for continuous integration and testing, which also conforms toJenkins Continuous Integration server is the following:

Define integration tests for individual components: Prepare integration tests acording to plan for each component to be written as Jenkins pipelines.

Create a Jenkins pipeline for each test: In a pipeline, one can define different steps.When a step succeeds, the pipeline moves onto the next step. When a step fails toexecute correctly, the entire pipeline fails. Steps contain the actions to be executed ateach of the continuous integration stages (Build-Test-Deploy), as well as special diretives which can be defined in a Jenkinsfile pipeline.

Define an execution environment: Jenkins uses special directives to know whereand how to execute pipelines (or even subsets of them). Via these directives, fithe steps contained within a pipeline are queued for execution. As soon as an executorbecomes available, the steps will start executing. Second, a workspace is allocatedthat will contain all files checked out from source control, as well as anyworking files for the pipeline. A pipeline is able to use Docker images and containers torun inside. This allows the pipeline to define the environment and tools required withouthaving to configure various system tools and dependencies manuall

Record test results and artefacts: Jenkins makes it easy to store test results throughpost block defined in the pipeline script. When there are test fai

ures, it is often useful to grab built artefacts, files generated during the epipeline, from Jenkins to local analysis and investigation. This is made practical by

in support for storing "artefacts" and is done through the

page 29

Team

In the PRODUCER context, an integration test is a test over several work packages. Integra-tion tests are grey box tests. This means that a complete workflow will be tested and the re-sults will be checked. The workflow structure and implementation is partially known and con-

kins [16] after a successful build. Jenkins is a Java-based Continuous Integration server. Continuous Integration is the practice of running tests on

developer hardware automatically every time a developer pushes new code into theg. a Git repository). Jenkins achieves Continuous Integration via plugins,

which allow the integration of various DevOps stages. For the integration of a particular tool,

sible for setting up Jenkins where each partner will be able to write and run

The main plan that is proposed for continuous integration and testing, which also conforms toJenkins Continuous Integration server is the following:

Prepare integration tests ac-cording to plan for each component to be written as Jenkins pipelines.

peline, one can define different steps.When a step succeeds, the pipeline moves onto the next step. When a step fails to

pipeline fails. Steps contain the actions to be executed atDeploy), as well as special direc-

Jenkins uses special directives to know whereand how to execute pipelines (or even subsets of them). Via these directives, first, allthe steps contained within a pipeline are queued for execution. As soon as an executorbecomes available, the steps will start executing. Second, a workspace is allocatedthat will contain all files checked out from source control, as well as any additionalworking files for the pipeline. A pipeline is able to use Docker images and containers torun inside. This allows the pipeline to define the environment and tools required withouthaving to configure various system tools and dependencies manually.

Jenkins makes it easy to store test results throughblock defined in the pipeline script. When there are test fail-

ures, it is often useful to grab built artefacts, files generated during the execution of theThis is made practical by

in support for storing "artefacts" and is done through the archive direc-



5. Deployment: Jenkins allows for the definition of more than one stage at any of the 3phases of the Continuous Integration delivery. This isexample of multi staging in the deployment phase.

In this example, we’re assuming that whatever "smoke tests" are run by the ./tests script are sufficient to qualify or validate a release to the production environment.happen that a human input is requested before proceeding to the next stage.judge if the application is in a good enough state to "This can be accomplished with thecheck" stage actually blocks for input and won’t proceed without a person confirming the prgress.

As a final note, it is useful to showcase an example where environment variables are set.These can be set either globally, as in the example belowvariables per stage means they will only apply to the stage in which they’re defined.

This approach to defining environments from within thescripts such as a Makefile to configure the build or tests differently to run them inside of Jekins. In the description of the integration plan above, a popular runtime environmentwas mentioned. This kind of pency management, can be used in tandem with Jenkins.

The benefits of using such solutions are numerous:

Packaging dependencies in containers offers portability and predictability during deveopment, testing and deployment

Applications are deployed anywheare also isolated, eliminating conflicts and ensuring security

Enhanced productivity and collaboration between developers and operators. New fetures, as well as fixes are deployed faster


Jenkins allows for the definition of more than one stage at any of the 3phases of the Continuous Integration delivery. This is illustrated inexample of multi staging in the deployment phase.

Figure 13: Multi-staging in Jenkins

In this example, we’re assuming that whatever "smoke tests" are run by the ./script are sufficient to qualify or validate a release to the production environment.

happen that a human input is requested before proceeding to the next stage.judge if the application is in a good enough state to "promote" to the production environment.This can be accomplished with the input step. In the example shown in Figure

lly blocks for input and won’t proceed without a person confirming the pr

As a final note, it is useful to showcase an example where environment variables are set.These can be set either globally, as in the example below, or per stage. Setting envivariables per stage means they will only apply to the stage in which they’re defined.

This approach to defining environments from within the Jenkinsfile is useful for instructingto configure the build or tests differently to run them inside of Je

kins. In the description of the integration plan above, a popular runtime environmentThis kind of platforms offer isolated runtime environments, as well as depen

can be used in tandem with Jenkins.

The benefits of using such solutions are numerous:

Packaging dependencies in containers offers portability and predictability during deveopment, testing and deployment

Applications are deployed anywhere without the need for costly rewrites. Applicationsare also isolated, eliminating conflicts and ensuring security

Enhanced productivity and collaboration between developers and operators. New fetures, as well as fixes are deployed faster

page 30

Jenkins allows for the definition of more than one stage at any of the 3illustrated in Figure 13, with an

In this example, we’re assuming that whatever "smoke tests" are run by the ./run-smoke-script are sufficient to qualify or validate a release to the production environment. It may

happen that a human input is requested before proceeding to the next stage. For example, topromote" to the production environment.

Figure 14, the "Sanitylly blocks for input and won’t proceed without a person confirming the pro-

As a final note, it is useful to showcase an example where environment variables are set.or per stage. Setting environment

variables per stage means they will only apply to the stage in which they’re defined.

is useful for instructingto configure the build or tests differently to run them inside of Jen-

kins. In the description of the integration plan above, a popular runtime environment, Docker,latforms offer isolated runtime environments, as well as depend-

Packaging dependencies in containers offers portability and predictability during devel-

re without the need for costly rewrites. Applications

Enhanced productivity and collaboration between developers and operators. New fea-



Figure 14: Human confirmation of successful test execution

Although Jenkins is certainly not restrictive with respect to the use of such platforms, the initialplan within the PRODUCER project is to use Jenkins for the continuous integration without uing the “Docker” based approach. Although during the integratiocessity of Docker will be re-examined and it will be adopted if it is necessary.

Finally, integration testing can be automated by most popular build tools for the languages thatwill be used for implementing project component

Figure 15

The details of automating integration tests for each component is specific to the build toolused, e.g. Maven uses a plugin called

5.2.4 Manual Testing

Being mainly relevant to Developersgration testing may complementarily needdepending on the level of testing complexity.

Especially for manually managing tests, test scenarios and test reports, the Tarantula testmanagement tool (http://www.testiatarantula.com/free of charge and is adequately supported by the community. Below a brief overview of taratula usage in steps is presented. This allows

To add cases for new features


: Human confirmation of successful test execution

Although Jenkins is certainly not restrictive with respect to the use of such platforms, the initialplan within the PRODUCER project is to use Jenkins for the continuous integration without uing the “Docker” based approach. Although during the integration phases of the project the n

examined and it will be adopted if it is necessary.

Finally, integration testing can be automated by most popular build tools for the languages thatwill be used for implementing project components. E.g. CMake for C++, Maven for Java

15: Setting environment variables in Jenkins

The details of automating integration tests for each component is specific to the build toolused, e.g. Maven uses a plugin called Failsafe to implement integration tests

Developers & Pilots Acceptance Testing (DAT & Pcomplementarily need automated and manual testing

depending on the level of testing complexity.

Especially for manually managing tests, test scenarios and test reports, the Tarantula testhttp://www.testiatarantula.com/) is a good candidate since it is open source,

free of charge and is adequately supported by the community. Below a brief overview of taratula usage in steps is presented. This allows the following:

To add cases for new features.

page 31

: Human confirmation of successful test execution

Although Jenkins is certainly not restrictive with respect to the use of such platforms, the initialplan within the PRODUCER project is to use Jenkins for the continuous integration without us-

n phases of the project the ne-examined and it will be adopted if it is necessary.

Finally, integration testing can be automated by most popular build tools for the languages thats. E.g. CMake for C++, Maven for Java.

The details of automating integration tests for each component is specific to the build toolto implement integration tests

DAT & PAT), unit and inte-manual testing on all testing levels

Especially for manually managing tests, test scenarios and test reports, the Tarantula testis a good candidate since it is open source,

free of charge and is adequately supported by the community. Below a brief overview of taran-



Figure 16: Setting up cases using Tarantula

To define test object.

To perform/run the test

To report the results.

Tarantula allows the user maximum control overup and fine-tuning reports through an easy

6 Integration Process Management Tools

This chapter describes the plan for the integration of the components into the PRODUCERplatform prototype.Starting with an administrative perspective the overall integration and testing timeline is prsented in Section 4. The remainder of the chapter refers to its realization. Sectionscribes the software source and executablegration cycle. Section 6.2 elaborates inspection of code quality.rizes the overall integration strategy for PRODUCER.

6.1 Software Configuration Management

An important part of modern software development is Software Configuration Management.Configuration Management is often considered to have originated in the frame of software dvelopment in recent years and that it merely consists of a tool for versioning of sourcesoftware development, the core of configuration management is made up of a version controlsystem. Source code (or all source documents of the final product, respectively) is considereda system that spans time and space. Files and directories (wform the space, while their evolution during development forms time. A version control systemserves the purpose of moving through this space

Configuration management contains version control, and extends it by providing additionalmethods of project management

Software configuration consists of software configuration items (SCI). The following activitiesconstitute configuration management

identification of SCIs and their versions through unique identifiers

control of changes through developers, management or a control instance

accounting of the state of individual components

auditing of selected versions (which are scheduled for a relteam.


: Setting up cases using Tarantula Figure 17: Define new test object in Tarantula

To perform/run the test.

Tarantula allows the user maximum control over setting test case scenarios, as well as settingtuning reports through an easy-to-use browser-based graphical UI.

Process Management Tools

This chapter describes the plan for the integration of the components into the PRODUCER

Starting with an administrative perspective the overall integration and testing timeline is pr. The remainder of the chapter refers to its realization. Section

and executable code management as part of the continuous intelaborates inspection of code quality. Finally,

rizes the overall integration strategy for PRODUCER.

Configuration Management

t part of modern software development is Software Configuration Management.Configuration Management is often considered to have originated in the frame of software dvelopment in recent years and that it merely consists of a tool for versioning of sourcesoftware development, the core of configuration management is made up of a version controlsystem. Source code (or all source documents of the final product, respectively) is considereda system that spans time and space. Files and directories (which, of course, can contain files)form the space, while their evolution during development forms time. A version control systemserves the purpose of moving through this space [9].

Configuration management contains version control, and extends it by providing additionalmethods of project management [10].

Software configuration consists of software configuration items (SCI). The following activitiesitute configuration management [1]:

identification of SCIs and their versions through unique identifiers,

control of changes through developers, management or a control instance

accounting of the state of individual components,

auditing of selected versions (which are scheduled for a release) by a quality control

page 32

: Define new test object in Tarantula

setting test case scenarios, as well as settingbased graphical UI.

This chapter describes the plan for the integration of the components into the PRODUCER

Starting with an administrative perspective the overall integration and testing timeline is pre-. The remainder of the chapter refers to its realization. Section 6.1 de-

code management as part of the continuous inte-Section 6.3 summa-

t part of modern software development is Software Configuration Management.Configuration Management is often considered to have originated in the frame of software de-velopment in recent years and that it merely consists of a tool for versioning of source files. Insoftware development, the core of configuration management is made up of a version controlsystem. Source code (or all source documents of the final product, respectively) is considered

hich, of course, can contain files)form the space, while their evolution during development forms time. A version control system

Configuration management contains version control, and extends it by providing additional

Software configuration consists of software configuration items (SCI). The following activities

control of changes through developers, management or a control instance,

ease) by a quality control



The Institute of Electrical and Electronics Engineers (IEEE) sees configuration managementas a discipline that uses observation and control on a technical as well as on an administrativelevel. Software configuration management deals with the governing of complex software sytems [11].

In PRODUCER we base the software configuration management on Gitof the problems listed in [12] and

Using a project management and issue tracking toolmanagement tool like Git allows us to tackle the challenges raised by integrating such a dverse and multi-partner project like

6.1.1 Project Management with

Managing a big and challenging project like PRODUCER is not an easy task. Especially whenwe need to deal with thousandsrection, we needed a robust project managinguse and covers most of our needs.

6.1.2 Code Management with

Managing code for such a big and collaborative project likecomponents need to be developed or enhanced and integratneed to be tackled. Within PRODUCER it was decided that awill be followed, respecting individual component specifications as well as integrated platformrequirements. According to this approach

Some components will reside in one same server.

Some components will reside on distinct servers (e.g. in order to address tight peformance requirements that require special hardware such as servers with GPUs)

All components will communicate with theful services.

This hybrid approach was decided to support certainwhich each tool will behave aswhere all or some of the tools will interactfilm/documentary production and promotion.

For those components that will reside in the same serverwill be created to keep track of every part of the code from all the related partners and use it tointegrate all modules into the final prototype. Another requirement is bug tracking and versioncontrol of the code so that we can identify any problems that may aand testing, and update our system code when needed. It is common practice to immediatelycommit every change to a versionhind is that other developers should always work wsource code management a Git repositoryartefacts of the stand-alone tool

Git is a version control system thattasks. As a distributed revision control system it is aimed at speed, data integrity, and supportfor distributed, non-linear workflows, a perfect fit for the code management requirements ofPRODUCER. As with most other distributed version control systems, and unlike most clientserver systems, every Git directory on every computer is a fullplete history and full version-tracking capabilities, independent of network acceserver. It is also free software distributed under the terms of the GNU General Public License.


The Institute of Electrical and Electronics Engineers (IEEE) sees configuration managementas a discipline that uses observation and control on a technical as well as on an administrative

management deals with the governing of complex software sy

we base the software configuration management on Git thatand [1].

Using a project management and issue tracking tool such as JIRA [13]management tool like Git allows us to tackle the challenges raised by integrating such a d

partner project like PRODUCER.

Project Management with JIRA

Managing a big and challenging project like PRODUCER is not an easy task. Especially whenthousands lines of code developed by different people

rection, we needed a robust project managing and issue tracking tool that is easy to setup anduse and covers most of our needs.

Code Management with Git

Managing code for such a big and collaborative project like PRODUCER where many differentcomponents need to be developed or enhanced and integrated has many challenges that

Within PRODUCER it was decided that a hybrid integration approach, respecting individual component specifications as well as integrated platform

requirements. According to this approach:

e components will reside in one same server.

Some components will reside on distinct servers (e.g. in order to address tight peformance requirements that require special hardware such as servers with GPUs)

will communicate with the integrated system’s front end through RES

This hybrid approach was decided to support certain workflows. For instancewhich each tool will behave as a stand-alone tool will be supported, as well as

the tools will interact with each other in order to facilitate theproduction and promotion.

that will reside in the same server a centralized management systemcreated to keep track of every part of the code from all the related partners and use it to

integrate all modules into the final prototype. Another requirement is bug tracking and versioncontrol of the code so that we can identify any problems that may arise during developmentand testing, and update our system code when needed. It is common practice to immediately

version control system, no matter how small it is. The rationale bhind is that other developers should always work with the latest version of the code base. Forsource code management a Git repository will be set up during the ramp

alone tool development process will be stored and organised.

Git is a version control system that is used for software development and other version controltasks. As a distributed revision control system it is aimed at speed, data integrity, and support

linear workflows, a perfect fit for the code management requirements of. As with most other distributed version control systems, and unlike most client

server systems, every Git directory on every computer is a full-fledged repository with cotracking capabilities, independent of network acce

server. It is also free software distributed under the terms of the GNU General Public License.

page 33

The Institute of Electrical and Electronics Engineers (IEEE) sees configuration managementas a discipline that uses observation and control on a technical as well as on an administrative

management deals with the governing of complex software sys-

that addresses many

[13], along with a codemanagement tool like Git allows us to tackle the challenges raised by integrating such a di-

Managing a big and challenging project like PRODUCER is not an easy task. Especially whendeveloped by different people. Moving in that di-and issue tracking tool that is easy to setup and

where many differenthas many challenges that

hybrid integration approach, respecting individual component specifications as well as integrated platform

Some components will reside on distinct servers (e.g. in order to address tight per-formance requirements that require special hardware such as servers with GPUs).

integrated system’s front end through REST-

. For instance workflows in, as well as workflowsorder to facilitate the

a centralized management systemcreated to keep track of every part of the code from all the related partners and use it to

integrate all modules into the final prototype. Another requirement is bug tracking and versionrise during development

and testing, and update our system code when needed. It is common practice to immediatelycontrol system, no matter how small it is. The rationale be-

ith the latest version of the code base. Forthe ramp-up phase where all

development process will be stored and organised.

is used for software development and other version controltasks. As a distributed revision control system it is aimed at speed, data integrity, and support

linear workflows, a perfect fit for the code management requirements of. As with most other distributed version control systems, and unlike most client–

fledged repository with com-tracking capabilities, independent of network access or a central

server. It is also free software distributed under the terms of the GNU General Public License.



Git has many desirable features such as:

Distributed development, with each developer working on a local copy

Non-linear development, with

Cryptographic authentication of history, change or deletion of a commit is marked

Pluggable merge strategies, merge autoof a conflict the developer can manually merge the files

A Git repository server will be setThe development tracking tool will be integrated with JIRA, and code updates will be montored through the JIRA’s interface if necessary.provided with server access rights for code, libraries or executable files submission, aiming atthe integration of all the modules in one central repository.It is important to note that a revision repository should contain all files necessary to build thesoftware system, but should not contain any files that can be derived from other files in anautomated fashion. Such redundancy only pollutes the repository and is considered bad pratice [14].

6.2 Code Analysis & Quality Measurement

There are two main kinds of analytic software quality assurance:

Static analysis

Dynamic analysis

The static analysis of software considers the “static”,do not rely on software execution. Typical forms of static analysis are software metrics, variousinformal methods like code inspections and reviews etc. Software metrics measure differentaspects of source code quality in order to serve as indicators for some quality aspects/qualityissues (e.g. Source Lines of Codetion of analysis rules in order to estimate compliance with coding conventions and best pratices of the underlying programming language. Static analysis may thus reveal potential mafunctions like infinite recursions, dependency loops or indicate issues of the developmentprocess: low test coverage or coding style deviations.

Dynamic analysis is practically represented by various kinds of testing. This runtimeapproach requires the program source code being compiled into executable code and excuted to observe if it is behaving as specified.

6.2.1 Inspection of Code Quality

Since the PRODUCER project is an Innovation Project, the starting poinopment is a high TRL (Technology Readiness Level)structure and the existence of prior SW development. In this respect, traditional inspectionmethods regarding the quality of the code may(formerly “Sonar”) will be utilized in order to keep track of the code quality. This is a webbased, open source quality management platform which supports several progguages and is highly extensible via

SonarQube addresses all so-an academic viewpoint:


Git has many desirable features such as:

Distributed development, with each developer working on a local copy

linear development, with branching and merging.

Cryptographic authentication of history, change or deletion of a commit is marked

Pluggable merge strategies, merge auto-completion model is well defined and in caseof a conflict the developer can manually merge the files.

will be setup and managed by HIT and ICCS.The development tracking tool will be integrated with JIRA, and code updates will be montored through the JIRA’s interface if necessary. Thus, PRODUCER’s partners will be thus,

er access rights for code, libraries or executable files submission, aiming atthe integration of all the modules in one central repository.It is important to note that a revision repository should contain all files necessary to build the

but should not contain any files that can be derived from other files in anautomated fashion. Such redundancy only pollutes the repository and is considered bad pra

Quality Measurement

There are two main kinds of analytic software quality assurance:

The static analysis of software considers the “static”, development-time characteristics whichdo not rely on software execution. Typical forms of static analysis are software metrics, variousinformal methods like code inspections and reviews etc. Software metrics measure different

ty in order to serve as indicators for some quality aspects/qualityissues (e.g. Source Lines of Code - SLOC). Code inspection techniques often involve appliction of analysis rules in order to estimate compliance with coding conventions and best pra

of the underlying programming language. Static analysis may thus reveal potential mafunctions like infinite recursions, dependency loops or indicate issues of the developmentprocess: low test coverage or coding style deviations.

tically represented by various kinds of testing. This runtimeapproach requires the program source code being compiled into executable code and excuted to observe if it is behaving as specified.

Inspection of Code Quality

project is an Innovation Project, the starting point(Technology Readiness Level), which presupposes an existing infr

structure and the existence of prior SW development. In this respect, traditional inspectionhods regarding the quality of the code may be “overkill”. However, if needed, SonarQube

(formerly “Sonar”) will be utilized in order to keep track of the code quality. This is a webbased, open source quality management platform which supports several progguages and is highly extensible via plugin architecture.

-called seven axes of software quality from both a practical and

page 34

Distributed development, with each developer working on a local copy.

Cryptographic authentication of history, change or deletion of a commit is marked.

completion model is well defined and in case

The development tracking tool will be integrated with JIRA, and code updates will be moni-Thus, PRODUCER’s partners will be thus,

er access rights for code, libraries or executable files submission, aiming at

It is important to note that a revision repository should contain all files necessary to build thebut should not contain any files that can be derived from other files in an

automated fashion. Such redundancy only pollutes the repository and is considered bad prac-

time characteristics whichdo not rely on software execution. Typical forms of static analysis are software metrics, variousinformal methods like code inspections and reviews etc. Software metrics measure different

ty in order to serve as indicators for some quality aspects/qualitySLOC). Code inspection techniques often involve applica-

tion of analysis rules in order to estimate compliance with coding conventions and best prac-of the underlying programming language. Static analysis may thus reveal potential mal-

functions like infinite recursions, dependency loops or indicate issues of the development

tically represented by various kinds of testing. This runtime-orientedapproach requires the program source code being compiled into executable code and exe-

for most of its devel-, which presupposes an existing infra-

structure and the existence of prior SW development. In this respect, traditional inspectionoverkill”. However, if needed, SonarQube

(formerly “Sonar”) will be utilized in order to keep track of the code quality. This is a web-based, open source quality management platform which supports several programming lan-

called seven axes of software quality from both a practical and



Figure 18: Software quality dimensions supported by SonarQube

There are also additional powerful plugins to compute advanced metrics like quality index,technical debt and total quality.on coding rules, Style, Complexity and Coverage by unit tests.debt on every component of projects with a breakdown by duplications, documentation, coveage, complexity. Total Qualitycode quality, design, architecture, and unit testing measurements.

6.3 Integration Strategies

All the tools that compose the PRODUCER platformtinuous method that will enhance their interconnection in every step (the final interconnectionof components is shown in Figurecycle that is described in detail incompletion of the development and testing of each separate component beforenected with other components forform prototype. Until the development of fully functional comform prototype will use a number of virtualin place of the actual components.the behaviour of the actual componentcould be a number of test drivers or stubs, dependingfor the testing of the system.the system before the final interconnection of the real components. Able integration strategies are provided

6.4 Integration Process of the PRODUCER Platform

A continuous integration routinein the system incrementally. Such a continuous integration process requires careful and apropriate designing. Usually it is designed to encompass subbuilds, continuous unit testing, continuous deployment, continuous notifications, and continous reporting. It is also of crucial importance that the designing of the integration process


: Software quality dimensions supported by SonarQube

There are also additional powerful plugins to compute advanced metrics like quality index,technical debt and total quality. Quality Index metric calculates a global Quality Index based

Style, Complexity and Coverage by unit tests. Technical debtdebt on every component of projects with a breakdown by duplications, documentation, cove

Total Quality provides an overall measure of the quality of the project.code quality, design, architecture, and unit testing measurements.

Integration Strategies

All the tools that compose the PRODUCER platform prototype will be integrated using a cotinuous method that will enhance their interconnection in every step (the final interconnection

Figure 4). The process involves execution of a continuous sixdescribed in detail in Section 6.4. The first phase of the integration requires the

completion of the development and testing of each separate component beforewith other components for creating the complete and fully functional PRODUCER pla

Until the development of fully functional components, the PRODUCER Plaa number of virtual (placeholder) components that

ponents. A placeholder either delivers constant values or simulatescomponent as realistically as possible. These virtual components

could be a number of test drivers or stubs, depending also on the strategy that will be followeThe use of virtual components is mostly useful for the testing of

the system before the final interconnection of the real components. A rangeprovided in Figure 19.

Figure 19: Integration Strategies

Integration Process of the PRODUCER Platform Prototype

routine will be followed with the different components being integratedin the system incrementally. Such a continuous integration process requires careful and apropriate designing. Usually it is designed to encompass sub-practices such as

ng, continuous deployment, continuous notifications, and continIt is also of crucial importance that the designing of the integration process

page 35

: Software quality dimensions supported by SonarQube

There are also additional powerful plugins to compute advanced metrics like quality index,a global Quality Index based

Technical debt calculates thedebt on every component of projects with a breakdown by duplications, documentation, cover-

provides an overall measure of the quality of the project. It links

integrated using a con-tinuous method that will enhance their interconnection in every step (the final interconnection

process involves execution of a continuous six-stepsfirst phase of the integration requires the

completion of the development and testing of each separate component before it gets con-the complete and fully functional PRODUCER plat-

ponents, the PRODUCER Plat-components that are temporarily used

A placeholder either delivers constant values or simulatesThese virtual components

on the strategy that will be followedis mostly useful for the testing of

range of different possi-

Prototype

with the different components being integratedin the system incrementally. Such a continuous integration process requires careful and ap-

practices such as continuousng, continuous deployment, continuous notifications, and continu-

It is also of crucial importance that the designing of the integration process



should allow the optimized solution ofoccurred. The PRODUCER integration process follow a continuous cycle of steps as depictedin the following figure.

Figure

6.4.1 Code Synchronization

The first practice into the continuoussystem so that the developers can hold working copies of the source codes all through the itegration process. They should regularly synchronize the code files on their local machines.The developers check out a working copy of the source code repository from the mainline (ormaster) of the revision control system and they obtain a copy of the currently integrated sourceonto their local machine. The local copy is branched and can be modified to imfeature required by the overall software system.

6.4.2 Front-end & Back-end

The development is categorized into two levels, the local and the global. The development inthe local level constitutes the development of the frontDUCER tools. The front- and backfunctionalities and refactoring the code to improve its internal consistency and clarity. Refatoring the code usually meanschanges of the source code should get synchronized withchanges in repository as well, the changes should be merged. In case that a developer haschanged something on the system, he shouldintroduce a bug. An automated build oncompile and link the code into an executable program. Automated or manual tests are runfunctional, security, load and performance test

6.4.3 Code Publishing

If the local build is successful, tby committing the code sources to the software revision system. In case there are alreadycommitted changes to the source code in thenized again before it can be p

6.4.4 Global Build

There would be a global integration server, where the code for the integrated system will bebuilt and the automated tests executed. The integration system is notified automatically, whena new revision is made available and committe


should allow the optimized solution of a given problem in terms of time, since the instant that itoccurred. The PRODUCER integration process follow a continuous cycle of steps as depicted

Figure 20: PRODUCER’s Integration Process

Synchronization

The first practice into the continuous integration process is the exploitation of revision controlsystem so that the developers can hold working copies of the source codes all through the itegration process. They should regularly synchronize the code files on their local machines.

ers check out a working copy of the source code repository from the mainline (ormaster) of the revision control system and they obtain a copy of the currently integrated sourceonto their local machine. The local copy is branched and can be modified to imfeature required by the overall software system.

end Development

The development is categorized into two levels, the local and the global. The development inthe local level constitutes the development of the front- and back-end of the different

and back-end developers alternate between addingfunctionalities and refactoring the code to improve its internal consistency and clarity. Refa

ing the code usually means modifying without changing its external behaviourchanges of the source code should get synchronized with the repository and in case there arechanges in repository as well, the changes should be merged. In case that a developer haschanged something on the system, he should ensure that the new feature he added does not

n automated build on his development machine should becompile and link the code into an executable program. Automated or manual tests are rununctional, security, load and performance testing.

If the local build is successful, the developer publishes the local changes of the source codesources to the software revision system. In case there are already

committed changes to the source code in the repository, the source code has to be synchrnized again before it can be published.

There would be a global integration server, where the code for the integrated system will bebuilt and the automated tests executed. The integration system is notified automatically, whena new revision is made available and committed to the repository and the integration server

page 36

problem in terms of time, since the instant that itoccurred. The PRODUCER integration process follow a continuous cycle of steps as depicted

integration process is the exploitation of revision controlsystem so that the developers can hold working copies of the source codes all through the in-tegration process. They should regularly synchronize the code files on their local machines.

ers check out a working copy of the source code repository from the mainline (ormaster) of the revision control system and they obtain a copy of the currently integrated sourceonto their local machine. The local copy is branched and can be modified to implement the

The development is categorized into two levels, the local and the global. The development inend of the different PRO-

end developers alternate between adding new tests andfunctionalities and refactoring the code to improve its internal consistency and clarity. Refac-

modifying without changing its external behaviour. The localthe repository and in case there are

changes in repository as well, the changes should be merged. In case that a developer hasthat the new feature he added does not

should be conducted tocompile and link the code into an executable program. Automated or manual tests are run for

the local changes of the source codesources to the software revision system. In case there are already

, the source code has to be synchro-

There would be a global integration server, where the code for the integrated system will bebuilt and the automated tests executed. The integration system is notified automatically, when

he integration server



performs a check-out of the most recent version of the software system from the repository.The code is built on the integration server and the automated tests areserver can also perform static or dynamic analysis checks that address the test coverage ofthe source code, possible duplication of code and dependencies among classes

6.4.5 Work-flow Adaptation

Apart from the automated tests, the common software platform is tested onof a subset of PRODUCER’sdemos/pilots. Errors and malfunctions regarding the expected behaviour bycollected in order to be sent to the development team.to appropriately adapt to, present and process the data of the workflows defined by the usecases.

6.4.6 Reporting

The developers are notified automatically via emails by the integration server in case the buildfails. In this way, errors are reported back before the programmer forgets what exactly he hasdone. This also enables the prevention of sloppy code checkately become visible to all developers. The integration server will also be able to generate testand code quality reports.

7 Conclusion

This deliverable has presented theplatform skeleton architecturemust evolve along with the platform architecture description in next development phases.The approach and overall plan will however remain the same. The overall integration strategyhas been discussed, and emphasis has been put on the continuous integration model used,chosen tools and solutions for source code management, code quality, build server and artfact repository.


out of the most recent version of the software system from the repository.The code is built on the integration server and the automated tests are

static or dynamic analysis checks that address the test coverage ofthe source code, possible duplication of code and dependencies among classes

flow Adaptation

Apart from the automated tests, the common software platform is tested onof a subset of PRODUCER’s functionalities as defined by the use cases

pilots. Errors and malfunctions regarding the expected behaviour bycollected in order to be sent to the development team. The integration system should be ableto appropriately adapt to, present and process the data of the workflows defined by the use

The developers are notified automatically via emails by the integration server in case the buildrs are reported back before the programmer forgets what exactly he has

done. This also enables the prevention of sloppy code check-ins, because mistakes immedately become visible to all developers. The integration server will also be able to generate test

This deliverable has presented the producer platform prototype integrationplatform skeleton architecture. The plan is based on the current architectural description andmust evolve along with the platform architecture description in next development phases.The approach and overall plan will however remain the same. The overall integration strategy

iscussed, and emphasis has been put on the continuous integration model used,chosen tools and solutions for source code management, code quality, build server and art

page 37

out of the most recent version of the software system from the repository.The code is built on the integration server and the automated tests are run. The integration

static or dynamic analysis checks that address the test coverage ofthe source code, possible duplication of code and dependencies among classes.

Apart from the automated tests, the common software platform is tested on specific workflowsfunctionalities as defined by the use cases of the project’s

pilots. Errors and malfunctions regarding the expected behaviour by the use cases areion system should be able

to appropriately adapt to, present and process the data of the workflows defined by the use

The developers are notified automatically via emails by the integration server in case the buildrs are reported back before the programmer forgets what exactly he has

ins, because mistakes immedi-ately become visible to all developers. The integration server will also be able to generate test

integration plan as well as theThe plan is based on the current architectural description and

must evolve along with the platform architecture description in next development phases.The approach and overall plan will however remain the same. The overall integration strategy

iscussed, and emphasis has been put on the continuous integration model used,chosen tools and solutions for source code management, code quality, build server and arte-



References

[1] Bruegge, B.; Dutoit, A.H. (2000): Objectand Changing Systems. Prentice Hall

[2] Kitchenham, S. L., Pfleeger (1996): Software Quality: The Elusive Target. IEEE Software[3] McCall, JA, Richards, PK, and Walters, GF (1977): Factors in Software Quality. General Ele

tric, Co., Rep. GE-TIS-77 CIS 02[4] Boehm, B. (1989): Software Risk Management. IEEE Computer Society Press, CA[5] Systems and Software Engineering. Systems and software Quality Requirements and Evalu

tion (SQuaRE) -- System and software quality models. Technica25010:2011(E), ISO/IEC

[6] McGregor, J.D., and Sykes, D.A. (2001): A Practical Guide to Testing Objectware, Addison-Wesley

[7] Beck, K. (2000): Extreme Programming Explained: Embrace Change. Addison[8] Beizer, B. (1990): Software[9] Spinellis, D. (2003): Code Reading

ISBN: 0201799405[10] Weischedel, G.; Versteegen, G. (2002): Konfigurationsmanagement.[11] Westfechtel, B.; Conradi, R. (2003): Software Architecture and Software Configuration Ma

agement. Westfechtel, B.; Hoek, A. v. d. (eds.); Software Configuration Management.Springer

[12] Ommering, R. v. (2003): Configuration Management in Component Based Product Popultions. Westfechtel, B. (ed.): Software Configuration Management, Springer

[13] https://www.atlassian.com/software/jira

[14] Richardson, J.; Gwaltney, W.A. (2005): Ship It. A Practical Guide to Successful Software

The Pragmatic Bookshelf

[15] https://www.facebook.com/business/news/topic

[16] https://jenkins.io/


Bruegge, B.; Dutoit, A.H. (2000): Object-Oriented Software Engineering: Conquering Complexand Changing Systems. Prentice HallKitchenham, S. L., Pfleeger (1996): Software Quality: The Elusive Target. IEEE SoftwareMcCall, JA, Richards, PK, and Walters, GF (1977): Factors in Software Quality. General Ele

77 CIS 02Boehm, B. (1989): Software Risk Management. IEEE Computer Society Press, CASystems and Software Engineering. Systems and software Quality Requirements and Evalu

System and software quality models. Technica25010:2011(E), ISO/IECMcGregor, J.D., and Sykes, D.A. (2001): A Practical Guide to Testing Object

Beck, K. (2000): Extreme Programming Explained: Embrace Change. AddisonBeizer, B. (1990): Software Testing Techniques. International Thomson Press, second editionSpinellis, D. (2003): Code Reading – The Open Source Perspective. p. 528, Addison Wesley,

Weischedel, G.; Versteegen, G. (2002): Konfigurationsmanagement. Springerl, B.; Conradi, R. (2003): Software Architecture and Software Configuration Ma

agement. Westfechtel, B.; Hoek, A. v. d. (eds.); Software Configuration Management.

Ommering, R. v. (2003): Configuration Management in Component Based Product Populons. Westfechtel, B. (ed.): Software Configuration Management, Springer

https://www.atlassian.com/software/jira

Richardson, J.; Gwaltney, W.A. (2005): Ship It. A Practical Guide to Successful Software

The Pragmatic Bookshelf

https://www.facebook.com/business/news/topic-data

page 38

Software Engineering: Conquering Complex

Kitchenham, S. L., Pfleeger (1996): Software Quality: The Elusive Target. IEEE SoftwareMcCall, JA, Richards, PK, and Walters, GF (1977): Factors in Software Quality. General Elec-

Boehm, B. (1989): Software Risk Management. IEEE Computer Society Press, CASystems and Software Engineering. Systems and software Quality Requirements and Evalua-

System and software quality models. Technical Report ISO/IEC

McGregor, J.D., and Sykes, D.A. (2001): A Practical Guide to Testing Object-Oriented Soft-

Beck, K. (2000): Extreme Programming Explained: Embrace Change. Addison-WesleyTesting Techniques. International Thomson Press, second edition

The Open Source Perspective. p. 528, Addison Wesley,

Springerl, B.; Conradi, R. (2003): Software Architecture and Software Configuration Man-

agement. Westfechtel, B.; Hoek, A. v. d. (eds.); Software Configuration Management.

Ommering, R. v. (2003): Configuration Management in Component Based Product Popula-ons. Westfechtel, B. (ed.): Software Configuration Management, Springer

Richardson, J.; Gwaltney, W.A. (2005): Ship It. A Practical Guide to Successful Software Projects.

producer d4 1 - platform toolset integration methodology …€¦ · · 2018-02-02cf fokus...

Documents