Ref. Ares(2020)5717754 - 21/10/2020
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
0. Cover
Tender Specifications - PART C – TECHNICAL ANNEX
Invitation to tender TAXUD/2020/OP/0001
Specification, development, maintenance and support
of customs and taxation IT systems
(SOFT-DEV)
Page 1 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
[Blank for duplex printing]
Page 2 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
Typographic conventions
The following typographic conventions are used in this document:
Draws attention to important conditions
Indicates definitions or reference information
Indicates that this requirement must be clearly addressed in the tender
Page 3 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
TABLE OF CONTENTS
0.
COVER ............................................................................................................................................ 1
0.1.
0.2.
0.3.
0.4.
1.
TABLE OF FIGURES................................................................................................................... 8
PURPOSE .................................................................................................................................. 9
ACRONYMS AND DEFINITIONS ................................................................................................. 9
REFERENCE DOCUMENTS ......................................................................................................... 9
SCOPE OF THIS INVITATION TO TENDER ........................................................................ 10
1.1 TAKE OVER ................................................................................................................................ 11
1.2 HAND OVER................................................................................................................................ 11
1.3 THE SOFT-DEV MAIN SERVICE BLOCKS .................................................................................... 12
1.3.1
Management Services ....................................................................................................... 12
1.3.2
Architecture and Strategy services ................................................................................... 12
1.3.3
Business Analysis, Modelling and Data integration and harmonisation services ............ 12
1.3.4
IT system and application development services .............................................................. 12
1.3.5
Support services................................................................................................................ 12
1.4 ITSM ACTIVITIES LINKED TO THE SOFT-DEV FRAMEWORK CONTRACT ................................... 13
1.5 IFPUG FSM AND SNAP METHODS ............................................................................................ 13
1.6 AGILE SOFTWARE DEVELOPMENT METHODOLOGIES ................................................................... 14
2.
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED ............................. 15
2.1 OVERVIEW OF THE WORK PACKAGES ......................................................................................... 15
2.2 SPECIFICATIONS OF THE WORK PACKAGES .................................................................................. 17
2.2.1
WP.0 Management ........................................................................................................... 17
2.2.2
WP.2 Take over ................................................................................................................ 28
2.2.3
WP.3 Hand Over .............................................................................................................. 32
2.2.4
WP.4 Architecture and Strategy ....................................................................................... 35
2.2.5
WP.5 Business Analysis, Modelling and Data Integration and Harmonisation ............... 40
2.2.6
WP.6 IT analysis and design ............................................................................................ 46
2.2.7
WP.7 IT Build, integrate and test ..................................................................................... 50
2.2.8
WP.8 Support Services ..................................................................................................... 55
2.2.9
WP.10 Other deliverables and services on request in the scope of the Framework ......... 71
3.
CONTRACT MANAGEMENT AND EXECUTION ................................................................ 72
3.1 TYPES OF ORDER MODES ............................................................................................................. 72
3.1.1
Fixed Price (FP) provision ............................................................................................... 72
3.1.2
On-Demand Services (OD) provision ............................................................................... 72
3.2 PLANNING MECHANISM .............................................................................................................. 74
3.3 DELIVERY MECHANISM ............................................................................................................... 75
3.4 ACCEPTANCE MECHANISM .......................................................................................................... 75
3.4.1
Acceptance of deliverables ............................................................................................... 75
3.4.2
Acceptance of services ...................................................................................................... 78
3.4.3
Acceptance of consumed quantities .................................................................................. 78
3.4.4
Acceptance of Monthly Progress Report (MPR) and the Bileteral Monthly Meeting
(BMM) minutes ............................................................................................................................... 79
3.4.5
Acceptance of FQP, Take-over and Hamd-over ............................................................... 80
3.4.6
Acceptance of software ..................................................................................................... 80
3.4.7
Acceptance of Specifications Involving National Administrations ................................... 81
4.
SERVICE & DELIVERABLE CATALOGUE .......................................................................... 82
4.1
5.
LIST OF THE PRE-DEFINED DELIVERABLES AND SERVICES ........................................................... 84
PRICE LIST REQUIREMENTS .............................................................................................. 115
5.1 IT PROJECTS AND SUPPORT ....................................................................................................... 116
5.1.1
Software development categories ................................................................................... 116
Page 4 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
5.1.2
New IT projects costing structure ................................................................................... 118
5.1.3
IT maintenance projects costing structure...................................................................... 119
5.1.4
IT maintenance interventions costing structure.............................................................. 119
5.1.5
IT support costing structure ........................................................................................... 120
5.1.6
Agile change scenarios ................................................................................................... 120
5.2 PRICE LIST ELEMENTS ............................................................................................................... 120
5.2.1
PE1 - Production of all the initial deliverables .............................................................. 121
5.2.2
PE2 – Overall Management ........................................................................................... 122
5.2.3
PE3 - PE4 - Take-over ................................................................................................... 122
5.2.4
PE5 - PE6 - PE7 - Hand-over ........................................................................................ 122
5.2.5
PE8 - Architecture and strategy ..................................................................................... 123
5.2.6
PE9 - Business Analysis, Modelling and Data Integration and Harmonisation ............ 123
5.2.7
PE10 – IT new projects .................................................................................................. 123
5.2.8
PE11 – IT maintenance, architecture support and integration management ................. 124
5.2.9
PE12 - IT analysis and modelling .................................................................................. 124
5.2.10
PE13 - IT build, integrate and test based on man-day profile prices ........................ 124
5.2.11
PE14 - IT maintenance projects based on FSP prices ............................................... 124
5.2.12
Support services ......................................................................................................... 125
5.2.13
PE43 – Provision of the development environment ................................................... 128
5.2.14
PE44 - Other deliverables and services in the scope of the framework contract ...... 128
5.2.15
Price element block “Reserves” ................................................................................ 128
6.
STAFF REQUIREMENTS ........................................................................................................ 130
6.1 TEAM STRUCTURE .................................................................................................................... 130
6.1.1
Overall management ...................................................................................................... 130
6.1.2
Quality ............................................................................................................................ 131
6.1.3
Security ........................................................................................................................... 131
6.1.4
Business Analysis, Modelling and data integration and harmonisation......................... 131
6.1.5
Architecture and Strategy ............................................................................................... 131
6.1.6
IT Projects and Support.................................................................................................. 132
6.2 STAFF PROFILES........................................................................................................................ 143
6.2.1
Strategy Consultant: ....................................................................................................... 146
6.2.2
Programme Manager ..................................................................................................... 147
6.2.3
Service Manager ............................................................................................................. 147
6.2.4
Quality Manager ............................................................................................................ 148
6.2.5
Quality Controller .......................................................................................................... 149
6.2.6
Security Manager ........................................................................................................... 149
6.2.7
Business Consultant........................................................................................................ 150
6.2.8
Business Analyst Modeller.............................................................................................. 151
6.2.9
Enterprise Architect ........................................................................................................ 151
6.2.10
Solution Architect ...................................................................................................... 152
6.2.11
IT Manager ................................................................................................................ 154
6.2.12
IT Category Owner .................................................................................................... 155
6.2.13
IT Project Manager ................................................................................................... 155
6.2.14
IT Analyst ................................................................................................................... 156
6.2.15
IT User Interface Designer ........................................................................................ 157
6.2.16
IT Designer ................................................................................................................ 157
6.2.17
IT Developer .............................................................................................................. 158
6.2.18
Integration Developer ................................................................................................ 159
6.2.19
Test Manager ............................................................................................................. 160
6.2.20
Test Designer ............................................................................................................. 160
6.2.21
Tester ......................................................................................................................... 161
6.2.22
Integration Expert ...................................................................................................... 162
6.2.23
Data Scientist ............................................................................................................. 163
6.2.24
Data Engineer............................................................................................................ 164
6.2.25
Data Integration and Harmonisation Modeller ......................................................... 165
7.
QUALITY REQUIREMENTS .................................................................................................. 167
7.1
METHODOLOGY ........................................................................................................................ 167
Page 5 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
7.2 STANDARDS AND BEST PRACTICES ............................................................................................ 167
7.3 THE QUALITY FRAMEWORK OF THE SOFT-DEV CONTRACT ..................................................... 167
7.3.1
Contractual Operation Level Agreement (OLA) ............................................................ 167
7.3.2
Framework Quality Plan (FQP) ..................................................................................... 168
7.3.3
TEMPO ........................................................................................................................... 168
7.3.4
Service Level Agreement (SLA) ...................................................................................... 168
7.4 IT DEVELOPMENT EXCELLENCE ............................................................................................... 168
7.5 CONTINUOUS SERVICE IMPROVEMENT PROGRAMME (CSIP) .................................................... 169
7.6 THE PERFORMANCE AND QUALITY INDICATORS....................................................................... 169
7.6.1
Overview of the KPIs ...................................................................................................... 170
7.6.2
Overview of the SQIs ...................................................................................................... 171
7.6.3
Overview of the PIs ........................................................................................................ 172
7.7 DATA SOURCE FOR SERVICE LEVEL CALCULATIONS .................................................................. 173
7.8 INTERNAL QUALITY SYSTEM OF THE CONTRACTOR ................................................................... 173
7.9 AUDITS ..................................................................................................................................... 174
7.10
CRITICAL QUALITY SUCCESS FACTORS ................................................................................. 174
8.
INFRASTRUCTURE AND TOOL REQUIREMENTS ......................................................... 175
8.1 DATA CENTRES......................................................................................................................... 175
8.1.1
TAXUD environments ..................................................................................................... 176
8.2 FUTURE EVOLUTIONS ............................................................................................................... 177
8.2.1
Platforms evolutions ....................................................................................................... 177
8.2.2
Infrastructure as a Service ............................................................................................. 179
8.2.3
Containers and container orchestrators ......................................................................... 179
8.3 INFRASTRUCTURE AT SOFT-DEV’S PREMISES ......................................................................... 179
8.4 HARDWARE/SOFTWARE/MAINTENANCE ACQUISITION CHANNEL ............................................ 180
8.5 TOOLS ....................................................................................................................................... 180
8.5.1
Application Lifecycle Management platform .................................................................. 181
8.5.2
Monitoring tools ............................................................................................................. 181
8.5.3
Service support and issue tracking tools ........................................................................ 181
8.5.4
Integrated Development Environment (IDE) tools ......................................................... 181
8.5.5
Modelling Tools .............................................................................................................. 181
8.5.6
Planning Tools ............................................................................................................... 182
8.5.7
Document Repository Tools............................................................................................ 182
8.5.8
Knowledge Management tools........................................................................................ 182
8.5.9
Testing tools ................................................................................................................... 182
8.5.10
Automatic deployment tools ....................................................................................... 183
8.5.11
TAXUD technology roadmap..................................................................................... 183
8.6 OFFICE AUTOMATION TOOLS .................................................................................................... 183
9.
SYNERGIA PROGRAMME ..................................................................................................... 184
9.1 PARTICIPATION IN THE SYNERGIA PROGRAMME ....................................................................... 184
9.2 AS-IS ....................................................................................................................................... 184
9.2.1
Service Support Operations ............................................................................................ 185
9.2.2
Service Transition ........................................................................................................... 187
9.2.3
Service design ................................................................................................................. 189
9.2.4
Other services provided by ITSM3 Operations contractor ............................................. 190
9.3 TO-BE ...................................................................................................................................... 190
9.3.1
Service Support Operations ............................................................................................ 190
9.3.2
Service Transition ........................................................................................................... 190
10.
IT TRANSFORMATIONS ........................................................................................................ 192
10.1
10.2
NEW PROJECT MANAGEMENT, DEVELOPMENT AND TESTING METHODS ................................ 192
PARTICIPATE TO THE MODERNISATION TOWARDS NEW TRANSITION METHODS .................... 193
11.
SECURITY REQUIREMENTS ................................................................................................ 194
12.
GENERAL REQUIREMENTS ................................................................................................. 196
12.1
12.2
INTERACTION MODEL WITH STAKEHOLDERS ....................................................................... 196
CONTRACTOR AVAILABILITY ............................................................................................... 197
Page 6 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
12.3
12.4
12.5
12.6
12.7
12.8
13.
PLACE OF WORK .................................................................................................................. 198
LANGUAGES ......................................................................................................................... 199
DELIVERABLES .................................................................................................................... 199
IMPLICIT NON-FUNCTIONAL REQUIREMENTS ...................................................................... 199
KNOWLEDGE BASE .............................................................................................................. 200
OWNERSHIP.......................................................................................................................... 200
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS ........................... 201
13.1
INTRODUCTION .................................................................................................................... 201
13.2
THE KEY PERFORMANCE INDICATORS (KPI) ....................................................................... 201
13.2.1
Key Performance Indicators (KPI) definitions .......................................................... 202
13.3
THE SQI / GQI APPROACH ................................................................................................... 232
13.3.1
Calculation of the SQI ............................................................................................... 233
13.3.2
Liquidated damages within GQI calculations ........................................................... 236
13.3.3
Specific Quality Indicators (SQI) definitions ............................................................. 238
13.4
PERFORMANCE INDICATORS ................................................................................................ 243
Page 7 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
0.1. TABLE OF FIGURES
Figure 1 – Team structure ...................................................................................................................... 130
Figure 2 - Distribution and location of DG TAXUD’s ICT infrastructure (subject to change) .............. 175
Figure 3 - Profiled SQIprof .................................................................................................................... 235
Figure 4 Liquidated damages application ............................................................................................... 237
Page 8 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
COVER
0.2.
PURPOSE
This document provides the scope and the specifications of the work packages linked to the framework
contract resulting from the present Invitation To Tender including the related services and deliverables.
It also provides a description of the requirements (e.g. quality requirements and general requirements)
and details about the pricing model of this framework contract.
0.3. ACRONYMS AND DEFINITIONS
Please refer to Annex 11 – List of abbreviations and definitions for a list of all abbreviations and
definitions used in this Invitation To Tender.
0.4. REFERENCE DOCUMENTS
Please refer to Annex 9 - List of Reference Documents for a list of all reference documents
applicable to this Invitation To Tender and that can be consulted from Annex 12 – Baseline.
The SOFT-DEV contractor needs to take into account that the baseline reflects the situation
applicable at the time of publication of this Invitation To Tender and that it will evolve.
The baseline contains all relevant specifications, documentation and process specific information.
In case of a conflict between the applicable documents, the following order of decreasing
precedence shall prevail, unless otherwise stated:
 The SOFT-DEV Invitation To Tender (of which this document is part);
 TEMPO & the SDLC;
 International standards and best practices;
 All documents in the Invitation To Tender baseline.
The latest Release of TEMPO is to be used by the SOFT-DEV tenderer. The list of TEMPO
documents referred to in this document is only added in order to make the reading easier. They are
neither exhaustive nor legally binding; they are only provided as additional information.
References to DG TAXUD are based on its organizational structure at the time of writing the
Invitation To Tender and that is subject to possible changes.
Page 9 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SCOPE OF THIS INVITATION TO TENDER
1. Scope of this invitation to tender
This Invitation to Tender is to award a framework contract to cover the provision of architecture,
analysis, specification, development, maintenance and support of customs and taxation IT systems.
The following provides a general description of the main service blocks to be delivered by the SOFTDEV contractor.
 Management services:
 Overall programme and contract management including risk management
 Programme and Project Management Office services
 Quality Assurance services
 Quality Control services
 Demand management and planning services
 Service Level management services
 Security management services
 Business Continuity management services
 Knowledge management services
 Take-over and hand-over services:

Perform all required services to take over the services from the incumbent contractors

Perform all required services to hand over the services to the Commission or to a designated
third party at the end of the contract, including “after hand-over” support
 Architecture and strategy services:

Produce, and maintain all relevant artefacts and provide support in the domain of architecture
and IT strategy services such as enterprise architecture, reference architecture(s) and
application architecture
 Business analysis, modelling and data integration and harmonisation services:

Produce and maintain all relevant artefacts in the domain of business analysis, modelling, data
integration and harmonisation
 IT system and application development services:

The contractor will deliver all required services to maintain the existing customs and taxation
IT applications and systems and to build new ones:

Produce and maintain all required IT specifications

Build, test and integrate all required IT services
 Support services:
 Deliver all required services to guarantee the continuity of the IT systems and applications:

Manage incidents, problems, change requests, corrective maintenance and releases in
function of business and IT criticality

Apply consistent Change Release and Configuration management across the different
application and artefacts

Provide support for deployment of IT systems and applications as required
 Set-up, operate and maintain the required IT and Telecom infrastructure to support all required
services
Page 10 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SCOPE OF THIS INVITATION TO TENDER
 Participate to and support the customs and taxation business perspective: liaison with
theCommission services, the National Administrators and other contractors
1.1
Take Over
The takeover activity is normally part of the first Specific Contract to be signed and should take between
6 and 9 months. The future SOFT-DEV contractor will take over all activities and their associated
artefacts from the Commission, or from incumbent contractors. The takeover must be synchronised with
the end of the services of the incumbent contractors. To ensure the service continuity, absolute priority
will be given to start providing the taken-over services on the imposed date and maintaining at least the
same quality levels as the incumbent contractors.
The takover will take place in 2 phases, aligned with the end dates of the respective incumbent
contractors.
The future contractor must ensure that, by the end of the takeover period, his staff has acquired all
knowledge, his structure is entirely set, the IT development infrastructure, the existing support services
and the required links with the other contractors (ITSM3 OPS, TES, INT and QA4), are operational.
1.2
Hand Over
At the end of the contractual period, the SOFT-DEV contractor will provide the appropriate trainings to
the new contractor(s) and make available the totality of the knowledge acquired during the contract to
DG TAXUD, or to any specified third parties on its behalf.
In accordance with instructions to be given by DG TAXUD, the SOFT-DEV contractor will hand over:

All SOFT-DEV services/deliverables in their entirety;

Information supporting the services/deliverables;

Any hardware and software COTS (including the related maintenance contracts) used by
SOFT-DEV but of which the Commission is the owner;

The latest versions of all software, tools and specifications developed or maintained by the
SOFT-DEV contractor for which DG TAXUD is the owner, free of any rights, unless otherwise
agreed with DG TAXUD.
The handover period represents the period, during the contract, when the incumbent contractor is
required to transfer the project information and knowledge to DG TAXUD, or any specified third parties
on its behalf. It is considered that this period should last between 6 and 9 months.
The SOFT-DEV contractor must commit to:

Propose a draft Handover/Takeover plan, which will be published in the future ITT to provide
similar services.

Provide a playground consisting of the appropriate hardware/software (financed and/or
provided by DG TAXUD) allowing DG TAXUD, or any specified third parties on its behalf to
freely practice after each training session on a representative development/testing environment
(including representative test data).

Train the new contractor(s) using both physical and virtual classrooms (at least two sessions of
the same training are to be foreseen at different dates) that are not relying on the playground for
all transferred knowledge organised into topics such as:
o
Functional and technical descriptions of each application;
o
Interactions/interfaces between applications;
o
How to build a new version of each application;
o
How to package each application;
o
Coding guidelines and naming conventions;
o
Specificities of the development tools;
Page 11 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SCOPE OF THIS INVITATION TO TENDER
o
Specificities of the used technical frameworks;
o
Application of IFP and SNAP counting.

Provide DG TAXUD, or any specified third parties on its behalf, with a comprehensive
knowledge base at the start of the handover/takeover period.

Provide the shadowing on representative subset of applications covering all technologies /
difficulties and applications complexities.

Be flexible in order to facilitate the alignment of the handover plan with the takeover plan(s) of
DG TAXUD, or any specified third parties on its behalf.
For the duration of the handover, the SOFT-DEV contractor must ensure the availability of its
experienced staff members to fully support all handover activities.
1.3
The SOFT-DEV main service blocks
As from the take-over, the SOFT-DEV contractor must be in a position to ensure the continuous
provision of the services as defined in this Technical Annex.
The following describes the main service blocks, which are developed in detail, later on, in this
Technical Annex in terms of work packages and its deliverables, price elements requirements, staff
requirements, quality requirements, infrastructure and tools requirements, information on the Synergia
programme and more general requirements.
Refer to section 6.1 for more information on the team structure requirements for the respective service
blocks.
1.3.1
Management Services
This main service block is critical for the overall delivered quality. The various management and
governance dimensions are further developed in WP.0.
1.3.2
Architecture and Strategy services
The architecture and strategy services mainly support the development of the customs and taxation
enterprise architecture, the application and service architectures and various reference architectures and
provide consultancy to IT development services and support to resolve important IT problems.
1.3.3
Business Analysis, Modelling and Data integration and
harmonisation services
The business analysis, modelling and Data integration and harmonisation services mainly support the
development and maintenance of the customs and taxation business processes. Those processes are to be
implemented by IT processes and services.
1.3.4
IT system and application development services
These services are to be applied to build new IT systems and applications and to maintain them in terms
of business/functional and technical evolutions.
1.3.5
Support services
These services are to be provided to

Support and use effective IT service support processes

Support Business perspective activities

Provide IT infrastructure and tools services

Support important IT transformations

Provide provisions for required services outside working hours.
Page 12 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SCOPE OF THIS INVITATION TO TENDER
1.4
ITSM activities linked to the SOFT-DEV Framework
Contract
The ITSM contractors will have important interactions with the SOFT-DEV contractor. Please refer to
the documents:

Tender Specifications - Part B (Terms of Reference) section 2.5 The IT Value Chain, for an
overview of the interactions between all contractors

[R09] ITSM3 Operations – Technology roadmap

[R10] ITSMT3 Integration - Infrastructure Requirements for Applications

[R11] ITSM3-INT Technical Annex for the list of services provided by the “IT service
management for IT systems integration of the Directorate-General for Taxation and Customs
Union” contractor, in short ‘ITSM3 Integration’ or ITSM3-INT.

[R13] ITSM3-TES Technical Annex and [R14] ITSM3-TES Terms of Reference, for the list of
services provided by the “IT service management for trans-European IT systems of the
Directorate-General for Taxation and Customs Union” contractor, in short ‘ITSM3 TransEuropean’ or ITSM3-TES.

[R15] ITSM3-OPS Technical Annex and [R16] ITSM3-OPS Terms of Reference, for the list of
services provided by the “Provision of IT Service Management for IT systems & Infrastructure
operation” contractor, in short ‘ITSM3 Operations or ITSM3-OPS.

[R18] ITSM3 Integration - Application System Requirements, for the list of the Application
Operations Requirements and Constraints that apply to the new generation of applications and
services.

[R20] ITSMT3 Integration - Infrastructure Requirements for Applications - Compliance
Standards and Controls

[R44] CUST-DEV3 Framework Quality Plan

[R45] FITS-DEV3 Framework Quality Plan
Furthermore, refer to section 9 for more specific information on the Synergia programme and more
details on the required interaction between the ITSM and the SOFT-DEV contractor.
1.5
IFPUG FSM and SNAP methods
The SOFT-DEV contractor will apply the International Function Point Users Group Functional Size
Measurement (IFPUG FSM) method in order to determine the functional size of IT projects when
possible. Please refer to heading 2.6 (IFPUG FSM and SNAP methods) of Tender Specifications – Part
B (Terms of Reference). The standard to apply will be ISO/IEC 20926:2009 – Software and Systems
Engineering – M1 II Function Point Analysis – Counting Practices Manual, which specifies the set of
definitions, rules and steps for applying the IFPUG FSM method.
The SOFT-DEV contractor will also apply the SNAP (Software Non-functional Assessment Process)
method to measure the non-functional requirements. The SNAP sizing method complements ISO/IEC
20926:2009. SNAP is also a product of the International Function Point Users Group (IFPUG). The
SNAP methodology applies the IEEE standard IEEE2430-2019.
DG TAXUD has adopted the IFPUG methodology and documented a number of interpretations of
how the method is to be applied in its technical environment. See in particular the IFPUG at DG
TAXUD Guidelines for performing function point and SNAP counting of DG TAXUD
applications [R40], this takes precedence over the IFPUG standard. It takes into account also some
specific elements of non-functional counting, expressed in SNAP points.
A subset of TAXUD applications [R49] has been recounted for IFPUG and counted for SNAP points
based on the IFPUG at DG TAXUD Guidelines [R40]. For historical reasons the previous IFPUG
Page 13 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SCOPE OF THIS INVITATION TO TENDER
counting based on the DG TAXUD IFPUG Technique [R39] can be found in the baseline documents
referred to in Annex 12.
The resulting number of function and SNAP points shall be the basis to determine the overall cost of a
given IT project under the contract. The Commission shall validate the resulting number of function
points and SNAP points determined by the Contractor. In case of disagreement on the determined
number of function and SNAP points, a third party, designated by the Commission, shall re-determine
the definitive number of function and SNAP points which shall be the basis to determine the overall cost
of a given IT project. The Contractor shall accept this definitive number of function and SNAP points
and shall adapt his offer accordingly.
The referred third party must be certified for the IFPUG FSM and SNAP methods and shall act as
auditor or quality controller.
In line with the contractual and administrative background of DG TAXUD, the third party can be the
DG TAXUD quality assurance contractor, the ITSM benchmarking contractor (or his successor), or any
other contractor appointed by the Commission and in charge of carrying out a benchmarking exercise.
For ease of reference, the total number of Function Points and SNAP points for a given application shall
be referred to as the number of FSP (Function and SNAP points). In financial terms, Function and
SNAP points shall be considered of the same cost.
1.6
Agile Software development methodologies
The development of complete systems and applications will be carried out by default using the Agile
methodology described in section 3.3 of the Tender Specifications - Part B (Terms of Reference).
Technical System Specifications development and maintenance for Trans-European Systems follow the
collaborative iterative Agile method defined in section 3.3 of the Tender Specifications - Part B (Terms
of Reference).
Page 14 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
2. Work packages, deliverables and planning
required
2.1
Overview of the Work Packages
The following table describes the work packages covered by the Framework Contract (FWC).
Work Package
1
WP.0
Management
WP.0.1
Setup and Maintain the FQP
WP.0.2
N/A for this contract
WP.0.3
N/A for this contract
WP.0.4
Produce Proposals for Specific Contracts (SC) and Request for Actions (RfA) and
produce RfA Acceptance Reports
WP.0.5
Internal activities: Quality Assurance (QA), Quality Control (QC), Risk Management
(RM), Self-Assessment (SA), Internal Auditing (IA), Team Organisation and
Management
WP.0.6
Interaction and Co-ordination with the Commission
WP.0.7
Contract reporting
WP.0.8
Demand management and planning
WP.0.9
Co-operate with the Commission during Quality Process and Security Audits
WP.0.10
Baselines
WP.0.11
Benchmarking and Pricing Update Mechanism
WP.0.12
CSIP
WP.0.13
Service Level Management
WP.0.14
Security Management
WP.0.15
Business Continuity Management
WP.0.16
Knowledge Management
WP.1
N/A
WP.2
Take Over
WP.2.1
Takeover activities
WP.2.2
Takeover of the IT Central Applications
WP.3
Hand over
WP.3.1
Handover Activities
WP.3.2
Handover of the IT central applications
WP.3.3
“After handover” support
WP.4
Architecture and Strategy
1
Any gap in the numbering sequence of WP or DLV is intentional and reserved for activities outside the
scope of this ITT or for future use
Page 15 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Package
WP.4.1
Support on IT Strategy definition and implementation
WP.4.2
IT Portfolio and Master Plan definition and maintenance
WP.4.3
Architecture Framework Support: Vision, Methods and Evolution
WP.4.4
Enterprise Architecture development and maintenance
WP.4.5
Application and Service Architecture development and maintenance
WP.4.6
Application & Service Architecture management and support
WP.4.7
Support on ARIS and Architecture tools
WP.5
Business Analysis, Modelling and Data Integration and Harmonisation
WP.5.1
Feasibility study
WP.5.2
Business analysis
WP.5.3
Production and maintenance of Business & System Process Modelling (Levels 1, 2 and
3)
WP.5.4
Production and maintenance of Business requirements
WP.5.5
Production and maintenance of Detailed Level 4 BPM (Business or Functional
Specifications)
WP.5.6
Business Acceptance Criteria document (BAC)
WP.5.7
System Scope Management
WP.5.8
Production and publication of Data Integration and Harmonisation artefacts
WP.5.9
Integration of Partner Competent Authority (PCA) certificates in EU Customs Single
Window Certificates Exchange (EU CSW-CERTEX)
WP.5.10
Business Request for Change (RfC)
WP.5.11
Business Proof-of-Concept (PoC)
WP.6
IT Analysis and Design
WP.6.1
Feasibility Studies or any activity linked to IT inception work
WP.6.2
IT Requirements
WP.6.3
IT System/Application system modelling
WP.6.4
IT Analysis
WP.6.5
IT Design
WP.6.6
IT Testing
WP.6.7
IT Implementation and Migration
WP.6.8
Technical System Specifications development and maintenance
Systems
WP.7
Build, integrate and Test
WP.7.1
IT Detailed Design
WP.7.2
Develop and Document Programs or Software Components
WP.7.3
Produce Supporting Manuals
WP.7.4
Test Design Specifications (TDS) – Test cases
WP.7.5
Execute Test Plans
WP.7.6
Code quality monitoring and technical debt prevention
WP.8
Support Services
WP.8.1
Business/operations support
Page 16 of 244
for Trans-European
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Package
WP.8.2
Configuration Management
WP.8.3
Release Management and software service transition
WP.8.4
ICT Infrastructure and Tools Management
WP.8.5
Specific support services
WP.8.6
The Business Perspective: Liaison with NAs, the Contractors and the Commission
services
WP.8.7
Implement major IT transformations
WP.8.8
Support outside Working Hours
WP.8.9
Upgrade of COTS
WP.9
N/A
WP.10
Deliverables And Services on Request In The Scope Of The Framework Contract
Table 1- List of the Work Packages
2.2
Specifications of the work packages
The following tables give a description of the work packages covered by the Framework Contract.
2.2.1
WP.0 Management
Work Packages
WP.0 Management
WP.0.1
This work package covers all the activities needed to ensure the effective management of the
Framework Contract and of the related Specific Contracts.
It mainly relates to the management of the SOFT-DEV contractor’s activities, its internal team
organisation and the co-ordination with the Commission. This work package also covers the
management of all administrative procedures related to s/w procurement, monitoring of consumed
quantities and budget per SC accounting and invoicing of all services/artefacts covered by the
Framework Contract.
Setup and Maintain the FQP
To setup and maintain the Framework Quality Plan (FQP), ensuring that activities described in this
technical annex are organised according to quality requirements. The FQP specifies this in terms of
processes, tools and organisational aspects.
The governance used (including methodologies, standards, tools, communication, decision, escalation
and information processes) in this context will be described in the FQP linked to this Framework
Contract. The FQP contains among other topics:
 A Work Breakdown Structure (WBS) of the activities,
 The structure of the overall Monthly Progress Report (MPR) and the Monthly Service Report
(MSR); see section 3.4.1.4 for a MPR model,
 A description of a Deliverable Tracking Matrix (DTM),
 All relevant support processes (incident management, problem management, change
management, configuration management, etc.), the internal processes in application for the
contract, including team organisation and composition, Quality Assurance and Control
procedures, the escalation process and rules,
 The SOFT-DEV contact list and organisational chart,
 The “interaction model” between Commission and contractor (see section 12.1 for
information on the interaction model with the stakeholders),
 The Continuous Service Improvement Programme (CSIP),
 The contractual Operational Level Agreement(s) (OLA) which defines service quality
requirements, quality of services, quality targets, objective metrics to measure performance
Page 17 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
achieved and monitoring means for all services to be provided (refer to section 7.3.1. for more
details on the OLA requirements). It can refer to the SLAs of DG TAXUD towards its
customers, contractual OLAs between the Commission and its partners and Terms of
Collaboration between the National Administrations (NAs) and the Commission. Each and
every Specific Contract will have its contractual OLA which will become by default an annex
to the FQP,
 The rules and procedures that the contractor will apply to ensure the confidentiality and the
security of all the information relevant to the creation and the maintenance of the Framework
Contract,
 The external processes (aligned with the ITSM external processes document and based on all
specific interfaces) and including the external reporting measures (e.g. reporting deliverables,
meetings schedule, etc. ).
During the take-over, the SOFT-DEV contractor will use the FQP of the incumbent CUSTDEV3 and FITS-DEV3 contractors and compile a consolidated FQP with the one of CUST-DEV3 as
the basis. The SOFT-DEV contractor will only document how it will be implemented and list the
major deviations, if any. This information will be included as annex to the Take-over FAT report.
The SOFT-DEV contractor will need to deliver the ‘Sent for Review’ version of the adapted FQP three
(3) months after the end of the take-over. This implies that the FQP is not a deliverable due at the end
of the takeover.
The FQP will need revisions, reflecting the evolution of the programme and the quality procedures. All
changes to the FQP and its related documents must be managed via Change management by the
contractor. At each major event, but at least once per year, the FQP will be revised and updated at
no extra cost by the SOFT-DEV contractor. The SOFT-DEV contractor must deliver an up-to-date
FQP at the start of the hand-over activities towards a new contractor. The FQP and its related
documents are subject to a review involving DG TAXUD and stakeholders nominated by DG
TAXUD.
The FQP and contractual OLA template are available from TEMPO.
WP.0.2
N/A for this contract
WP.0.3
N/A for this contract
WP.0.4
Produce Proposals for Specific Contracts (SC) and Request for Actions (RfA) and produce “End of
Action reports”
In the context of demand management2, the contractor has to produce proposals/offers on request from
the Commission for Specific Contracts (SC) and for Requests to provide services and/or deliverables in
the context of this FWC. Furthermore, once the services are to be accepted the contractor will produce
on the basis of the foreseen invoices in each order (SC and/or RfA) one or more “End of Action
reports” .
The Commission will request proposals for SCs via the Request for Offer (RFO) form, and proposals
for the provision of IT services such as specifications, development, etc. via the Request for Estimation
(RfE) form respectively.
The quotes must be expressed in quantities of service units, and associated unit prices, with reference
to the price schedule of the framework contract and the budget provision.
The quality of the proposals made for SCs and services provision will be monitored by means of the
time required to receive an acceptable offer/estimate, as well as by the timeliness of the planning
2
Demand management covers the follow-up of available quantities in the context of quantified services
ordered in a SC versus future and the follow-up of budget concerning ordering via the
RfE/Offer/RfA mechanism.
Page 18 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
proposed for the actions within the offer. The contractor must propose a planning that respects a
minimal productivity rate defined as follows:
While drafting an offer for an RfE the SOFT-DEV contractor must ensure a minimal
productivity rate of 100 estimated function points for each calendar month for a particular software
delivery. This shall be calculated as the value of the estimated SFP (IFP and SNAP points) divided by
the number of elapsed calendar months proposed in SOFT-DEVs offer(s) for both the elaboration and
the construction phases. It shall be verified by the final count of the function points at the end of the
construction phase and the count of the actual calendar months spent by the contractor between the T0
date and the last deliverable associated with the above mentioned software delivery. The above shall be
applicable for any other activity that can be measured in function points.
With regards to the amounts lower than one calendar months, they should be treated by analogy
proportionally by week and by day. The above shall be calculated irrespective of whether the
elaboration and construction are ordered in one or multiple RfAs. However should there be multiple
RfAs the calendar months above-mentioned shall be calculated between the T0 of each RfA and the
last software deliverable of that particular RfA, which shall be summed up for all the RfAs that have
been signed for the elaboration and construction phases.
In the Agile methodology, both elaboration and contruction phases are combined into a single Agile
iteration phase.
One calendar month shall be equal to 20 working days.
Each proposal/offer will go through an internal review cycle (T1/T2/T3) which will be defined by DG
TAXUD in the RfO or RfE. The timely reception of an accepted proposal/offer will be measured by a
Key Performance Indicator (KPI91 in particular). The planned delivery date starting the T1 review
period and the proposed duration of T1/T2/T3 are defined in the RfO/RfE. (refer to section 13.2 for
more information on KPIs).
If applicable, the amount of effort proposed to perform the work will be justified by using the FSP
methodology and applying the productivity rate specified in the price list.
When the services ordered via the RfE/Offer/RFA mechanism are completed, the contractor has to
deliver to DG TAXUD for acceptance and priot to invoicing the “End of Action report”. In cases
where only one payment is foreseen in the order, only one final “End of Action report” will be
delivered. In cases of multiple payments, an intermediary “End of Action report” will be deliverd for
acceptance per payment.
In each of the “End of Action reports”, the contractor states:
 Deliverables data (i.e. deliverable ID/name, contractual/actual SfR/SfA dates together with
the Ares registration reference communicated by DG TAXUD, deliverable delivery delays
expressed in days, applicable KPIs/SQIs and references to verification report issued by QA
contractor).
 Impact, if any, due to a delay in the submission of a deliverable for example,
 Factual justification (i.e. e-mail, a note, etc.) for delays charged by the contractor to DG
TAXUD. In cases where delays charged to DG TAXUD are not factually justified they will
be charged to the contractor ),
 KPI, GQI values applicable in the RFA.
Once all interims and/or the final “End of Action report” is acknowledged, a reply registered in Ares
will be compiled, signed by a person delegated in the operational unit/sector and communicated via
Ares to the contractor. During invoicing, the contractor has to provide all relevant acknowledged “End
of Action Reports” as part of the supporting documentation to the invoice.
Page 19 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
WP.0.5
Internal activities: Quality Assurance (QA), Quality Control (QC), Risk Management (RM), SelfAssessment (SA), Internal Auditing (IA), Team Organisation and Management
To manage internal activities
WP.0.5.1
Internal QA and QC
To check the compliance of the activities and deliverables with the quality objectives, and with the
contract standards and procedures.
Quality inspections will be performed by the contractor’s Quality manager. The main goal is to check
the compliance of the activities and deliverables with the quality objectives, with the contract standards
and procedures. The contractor also has to ensure the enforcement of the contractual OLA (refer to
section 7.3.1 for more details on the OLA requirements) and has to trigger actions in case of
deviations.
The contractor must also ensure that if quality issues are detected that the necessary corrective
measures are taken. The quality officer(s) must provide supervision and guidance to the contractor for
the implementation of the quality throughout the whole project.
The contractor must keep in mind that TEMPO is the mandatory methodology for all projects of DG
TAXUD.
The contractor is requested to maintain minutes of all internal meeting held on quality assurance &
quality control matters, so that they are available on site in case of an audit by the Commission (see
WP.0.9).
The quality staff must act independently from the SOFT-DEV management.
WP.0.5.2
Risk Management
The contractor has to perform the Risk Management and report on this to the Commission via the
Monthly Progress Report (MPR), including continuous risk analysis and mitigation. Risk management
must be integrated into all main project management related activities and meetings and escalated
when needed.
The contractor must keep its internal risk analysis records available on request of the Commission.
The risk management activities must adhere to the TEMPO Risk Management Technique
The risk register must be available to DG TAXUD via the agreed toolset (cf. section 8.5).
WP.0.5.3
Self-Assessment & Internal Audit: Control Compliance
The contractor has to perform self-assessment and internal audits periodically, at minimum twice per
year, for all service processes of the contract, report outcome/findings to the Commission and
introduce the necessary improvements in line with the proposed Continuous Service Improvement
Programme (CSIP) (as described in the FQP) and /or corrective actions.
The contractor must follow-up the implementation of the actions agreed with the Commission and/or
those resulting from the quality audit process.
An audit could be of contractual, procedural or technical nature within the scope of the contract.
The self-assessment and internal audit activities must ensure that


This Technical Annex, the FQP and related contractual OLA (refer to section 7.3.1 for more
details on the OLA requirements) are adhered to and implemented consistently across all
activities,
Any corrective measures are taken in case of deviation.
Self-Assessment will be conducted by the contractor staff responsible for delivering the activities.
Internal Audits will be performed by an authorised contractor’s Quality Officer external to the team to
ensure independence and objectivity.
Page 20 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
Furthermore, DG TAXUD has the right to request the contractor to conduct an internal audit on a
specific project at any point in time. As for the other internal audits, this must be performed by an
authorised contractor’s Quality Auditor external to the team. In such a case the report of the internal
audit must be available no later than 3 weeks after the formal request made by DG TAXUD.
The contractor is requested to keep all self-assessment and internal audit reports available on site in
case of audit (see WP.0.9).
WP.0.5.4
Internal Team Organisation and Management
The contractor has to set up an internal team that



Provides all required services;
Functions as one team internally and externally
Guarantees a uniform approach in terms of methodology and technical implementation.
The team composition must ensure
 The presence of an hierarchical structure in function of the size of the overall team and the
different activities;
 A correct balance of concentration and distribution of the acquired knowledge (the overall
knowledge must be shared on the one hand by several persons responsible for sub-domains in
order to reduce the risk of dependency on particular staff members but on the other hand not
too fragmented amongst too many staff members such that the overall picture is lost);
 The availability of expert knowledge on the fundamental horizontal elements (architecture,
delivery, etc.);
 The existence of a stable core team to guarantee continuity.
Refer to chapter 6 for more information on the staff requirements.
The contractor must ensure that the staff will be fully aware of the quality system, the TEMPO
quality methodology, the security requirements and the goal, the context, the planning and the political
importance of the contract.
The contractor must ensure that all team members have the experience requested for their job
and that they get the necessary induction and training as needed as soon as they join the team. In order
to ensure a correct transfer of knowledge, a handover and takeover period must be organized with the
staff leaving and the people replacing them without additional costs for the Commission.
WP.0.6
Interaction and Co-ordination with the Commission and its contractors
The contractor must put in place an organisational structure that supports the “interaction model” as
specified in section 12.1.
The contractor has to co-ordinate efforts with the Commission from a management and operational
viewpoint. The contractor must prepare, hold and minute all meetings (including the virtual ones) with
the Commission.
The availability of the contractor for the overall governance and management of the Framework
Contract activities must be as follows:



Bilateral Monthly Meetings (BMM) are planned in advance. The monthly meeting is
organised to synchronise planning and to address any issues/risks linked to the different
activities of the contract,
BMM follow-up meeting usually at the day of the BMM or within maximally one working
week at Commission Head of Unit level to handle all escalations raised during the BMM,
Multilateral meetings (e.g. all sectors of TAXUD and all TAXUD contractors) usually
planned monthly in advance but could be called upon request at a mutual agreed date and
Page 21 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
time;
 Steering Committee meetings, typically on a quarterly basis, chaired by the Commission and
focusing on the strategic aspects of the contract and risk management. Steering Committee
meetings may also address in an ad hoc manner specific escalation issues;
 Ad hoc meetings, called on request, at a mutually agreed date and time.
The person of the contractor in charge of the quality team needs to participate in the Bilateral Monthly
Meetings (BMM) in order to note & discuss quality-related concerns and issues.
In
addition
to
the
above-mentioned
meetings,
bilateral
business,
functional/analytical/operational/technical-oriented meetings and ad hoc meetings with the
Commission and/or its contractors will take place, which steer the provision of the services (important
to note that this list is indicative and not exhaustive):
 Meetings with the responsible DG TAXUD operational sector in the context of project,
contract and supply management. These meetings can be organised on a bi-weekly basis in
between two BMM meetings. These meetings concentrate on planning, budget, issues, and
risks.
 Agile meetings (iteration planning meetings, iteration reviews, iteration retrospectives and if
necessary daily sprint meetings) as described in section 3.3 of the Tender Specifications Part B (Terms of Reference).
 Alternatively, project progress meetings on a weekly basis (could also take place in the
context of an RFA). These will be organised on at least a weekly basis. It must be noted that
all relevant staff of the contractor can be called to attend these meetings depending on the ongoing project activities: project management specific aspects, functional aspects, IT technical
aspects, IT architectural aspects;
 Working sessions for the different new or on-going activities attended by the relevant
Commission and SOFT-DEV contractor staff. It should be noted that the contractor’s staff
must be competent to contribute to the subject, meaning staff that has operational duties and
responsibilities (e.g. business consultant, business analysts, IT analyst, IT designer, IT User
Interface Designer, Test Designer, etc.);
 Meetings with TAXUD/LISO related to security aspects,
 Meetings with the responsible Commission operational sector related to the hosting of the
systems/applications/components in the TAXUD datacentre.
 Ad hoc meetings, called on request, at a mutually agreed date and time.
The contractor will produce the agenda, briefing material and the minutes for all meetings
mentioned above. In case of conflict between the minutes and the contractual documents, the latter
takes precedence. Resulting project information, such as planning, tasks, requests, scope, risk, quality,
deliverables will be made available in the respective project areas in the Application Lifecycle
Management platform (refer to section 8.5.1). Depending on their audience, meeting content such as
agenda, materials or minutes will be tool-based rather than provided as documents.
Most meetings, especially the frequent Agile meetings will occur through audio- or videoconferencing
and make use of online collaborative platform for sharing content.
The contractor produces and maintains action lists tracking at least the actions assigned to the
SOFT-DEV contractor during meetings. The action lists must reflect the status of the action
implementation at any time. The action lists must be available to DG TAXUD via the agreed toolset.
All meetings foreseen above are not subject of an extra/additional cost for the Commission.
Tenderers need to include these costs as part of the project management quotation. Technical meetings
which are called by third-party entities that need the presence/attendance of the SOFT-DEV contractor
are considered as workshops and are subject to charging.
WP.0.7
Contract reporting
To report to the Commission on a monthly basis via the Monthly Progress Report (MPR) and the
Page 22 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
included Monthly Service Report (MSR).
The contractor has to report to the Commission on a monthly basis via the Monthly Progress Report
(MPR) about (list indicative and not exhaustive):

The contractual situation, including the status of the activities (RFAs) and the consumption of
the ordered On-Demand Services,

Progress realised for the main activities (mainly those ordered via RFA),

Deliverables progress, status and deadlines,

Issues, problems and risks identified/updated during the reporting period,

Resource allocation,

Future plans,

List of actions with deadline, status and responsible actor(s),

List of all deliverables to be accepted through the MPR,

List of RFAs to be accepted,

Cost allocation per system/application and project,

Invoicing plan,

List and status of change requests and related releases and
 Quality management achievements, findings and concerns.
Moreover, a series of annexes with detailed information are also delivered with the MPR like (list
indicative, not exhaustive): Asset inventory, if applicable, SQI/KPI related data, Quantity and budget
status report, DTM, Master Project Plan, Risk register, Complaint Register, action lists, etc..
Furthermore, the monthly progress report will include the Monthly Service Report (MSR).
The contractor must propose an efficient structure of the MSR so that different blocks can easily
be reviewed by the responsible TAXUD teams.
The Monthly Service Report will include a Service Level Report which describes all the Service
Quality Indicators (SQI) and Key Performance Indicators (KPI) for the month, and the raw data for
their computations.
The Monthly Service Report will also include a summary on consumption of all consumed services, a
summary of all service type calls (incidents, problems, RfI, RfCs, etc.) and detailed statistics on service
calls per system/application. Also, it will include a graphical evolution of all service calls through time
and a Service Level Report which describes all the Service Quality Indicators (SQI) and Key
Performance Indicators (KPI) for the month, and the raw data for their computations. A thorough
narrative explanation about any notable trends/peaks (if any) observed during the reporting period and
their root causes (for instance a peak in software defects or incidents) must be provided.
In cases where more than one SC run in parallel, the contractor may be requested to provide in a single
bundle one MPR per SC.
The FQP will define the structure of the Monthly Progress Report, as well as the content of the overall
Monthly Progress Report based on the indicative model given in section 3.4.1.4 of this Technical
Annex.
The contractor has also to report to Commission on a weekly basis on all consumption types of the
on-going Specific Contracts (SCs).
The DTM linked to the on-going SCs will be annexed to the MPR and will be delivered to DG
TAXUD on a weekly basis.
All contractual information (incl. the information constituting the MPR and MSR) must be
available to DG TAXUD via the agreed toolset.
WP.0.8
Demand management and planning
To provide all relevant stakeholders with a view of the planned activities on a short, medium and longterm basis.
Page 23 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
The Commission is governing its activities based on management plans which are of a yearly (and in
the future bi-yearly) and multi-annual level. The actual activities are derived from these plans and
refined in terms of contents.
The contractor is responsible to maintain

The contractual planning. This is currently expressed by a DTM containing all contractual
dates and related information;

A forecast planning in line with the management plans of DG TAXUD. This forecast
planning must contain a resource capacity estimate which is not contractually binding but
must allow the contractor and DG TAXUD to anticipate as much as possible resource
fluctuations in the future and budget needs;

A master planning for ordered activities and for activities ‘near to ordering’ allowing a dayto-day follow-up of those activities;

Agile release planning;

An operational planning providing information for all involved stakeholders. This planning is
important as date changes for some activities can have an impact on other involved
stakeholders, such as DG TAXUD staff, the QA and ITSM contractors, etc.

Specific planning(s) for new projects which have a level of detail making it difficult to
integrate these into the master and operational planning(s). In this case the master and
operational planning(s) will contain only the relevant activities and milestones of the
project(s).
The planning(s) must contain any dependencies from other project contributors such as the National
Administrations, ITSM contractors, etc. The planning(s) will be maintained on the one hand with the
support of a project management tool compatible with the one used at the Commission (currently MS
Project) and on the other hand with the support of a Deliverables Tracking Matrix (DTM) tool as
described in the FQP. Project and release planning will be made available in or produced from the
respective project areas in the Application Lifecycle Management platform (refer to section 8.5.1).
The contractor must analyse regularly the above plans including the comparison to the baseline
planning. Any deviation, risks and other results from this analysis must be reported to DG TAXUD.
The contractor can be asked to review operational plans from other contractors such as ITSM, QA, etc.
such to guarantee an overall consistency of planning aspects between all stakeholders.
The planning schedules will be annexed to the MPR (WP.0.7) and will be delivered to DG
TAXUD on a weekly basis. The contractor must also keep the planning available for DG TAXUD via
the agreed toolset (cf. section 8.5).
WP.0.9
Co-operate with the Commission during Quality Process and Security Audits
To co-operate with the Commission or any specified third parties on its behalf on requests for one
audit per year (on average) in the contractor’s premises.
It is expected that the Commission will conduct on average one quality process and one security audit
per year in the contractor’s premises but reserves its right to conduct more. The audit will be conducted
by the Commission and/or a third party nominated by the Commission. The number and timing of
these audits are determined by the Commission. The Commission will notify the contractor in advance
of the timing for the audit.
The contractor has to cooperate with and support the audit team during its entire mission.
After the audit report is released, the contractor will issue his position regarding the points raised in the
audit report. These will be discussed between the Commission and the contractor. Follow-up of the
decisions, agreed between both parties, will be implemented via the MPRs, or if necessary, by
conducting another verification audit in the contractors’ premises.
Note that audit reports are kept confidential.
WP.0.10
Baselines
To re-deliver to Commission all artefacts to an electronic repository of the Commission in general
infrastructure.
Page 24 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
WP.0.10.1
Delivery of the full baseline
To re-deliver to Commission, upon request but mainly once a year, all artefacts linked to the
Framework Contract to an electronic repository of the Commission in general infrastructure.
Apart from the scheduled delivery of artefacts, the contractor has to re-deliver free-of-charge to DG
TAXUD upon request but generally once a year also a full baseline with the latest version of all
deliverables since the start date of the framework contract (even if they were not changed yet during
the running of the framework contract, including the deliverables taken-over from the CUST-DEV3
and FITS-DEV3 contractors) as well as all the files that would be needed for a handover (e.g. export
of all operational data, list of all contacts, etc.).
The specific procedure together with more explicit criteria (e.g. what versions of some types of
artefact to select) must be specified in the FQP.
All artefacts must be anonymized so that names of individuals do not appear in one of the
artefacts and any sensitive information such as IP addresses deleted (refer to the relevant instructions
in TEMPO for more details).
Note that anonymizing is a standing requirement for delivery of project related artefacts
(documentation and software), such that the production of the baseline does not require additional
activities in this respect.
The only artefacts where anonymization is not applicable is for the team composition and assignment
of persons to roles.
WP.0.11
Benchmarking and Pricing Update Mechanism
To co-operate with the Commission or any specified third parties on its behalf on requests for one
benchmark per year (on average) related to the costs of effort quoted by the contractor for its activities.
The Commission may undertake a Benchmarking exercise on the levels and the charges of the services
and supplies provided under this Framework Contract by comparison with similar services and
supplies provided by outsourcing vendors and/or in-house IT service providers and suppliers.
The Commission will notify the contractor in advance of the timing for the benchmarking exercise.
The tenderers have to be aware of the obligation to provide the possibility of regular
benchmarking according to Annex 7, Draft Framework Contract, Articles 1.1 and 2.10 of Part III –
General Terms and Conditions for Information Technologies Contracts.
WP.0.12
CSIP
To define and run a Continuous Service Improvement Process (CSIP) linked to all services of the
Framework Contract.
The contractor has to define and run a Continuous Service Improvement Process (CSIP) so that
findings on quality aspects resulting from either WP.0.5.1, WP.0.5.3, WP.0.9 or collected via any other
means are taken into account and improvements are identified, agreed with the Commission,
implemented, applied and followed-up.
In this context, the contractor must perform yearly a global risk analysis exercise resulting in proposals
of improvements to be validated by DG TAXUD. Furthermore, the contractor shall cooperate with
other contractors and stakeholders for the identification of improvement linked to the interaction
between them. These proposals must be duly documented with a business case and integrated in DLV0.12-2.
These improvements can be linked to the processes as well as the tools used to provide all services
linked to the framework contract.
The CSIP process covers :

The overall CSIP process follow up,
Page 25 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
 Improvement identification and selection,
 The management of the major transformation projects,
 The change management of Service Improvement Projects.
CSIP is considered as an inherent function performed by the management of the SOFT-DEV
contractor. Implementation is measured by outputs that are directly linked to the improvement of the
services.
Reporting on CSIP related activities is provided to DG TAXUD on regular intervals (included via
WP.0.7).
CSIP proposals will be submitted to DG TAXUD for further analysis and comments. DG TAXUD
reserves the right to reject implementation proposals. CSIP progress and new proposals need to be
documented in the MPR.
WP.0.13
Service Level Management
Only Service Level Management is applicable in this Framework contract. The other Service Delivery 3
processes linked to the SAT/CONF testing and production environment are performed by the ITSM
contractor.
WP.0.13.1
Service Level Management
Maintain, monitor and report on the contractual OLA
Besides the SQIs that are contractually binding a set of Key Performance Indicators (KPIs) will be
defined in the Framework Contract/Specific Contract(s). The KPIs will be used to continuously
monitor the successful execution of the Framework Contract. During the lifecycle of the Framework
Contract, the Commission can update the list of KPIs linked to the Framework Contract. These
changes will be applicable from the next Specific Contract onwards. The SOFT-DEV contractor will
have to report on all the SQI’s and KPIs in the MSR/MPR (WP.0.7).
The contractor must ensure that the agreed contractual OLA (refer to section 7.3.1 for more
details on the OLA requirements) plus the process and tools linked to the Service Level Management
are implemented before he starts the actual provision of the taken over services.
The contractor will produce and maintain its service catalogue. The service catalogue will contain all
services against which a Service Request can be issued via the ITSM service desk tool set (refer to
WP.8.1.1.3 for the management of Service Requests).
The contractor will have to perform minimum once a year a user satisfaction survey. The list of
questions and the user population will have to be agreed with DG TAXUD (By default all registered
users). The outcome of this survey must be documented in a report and follow up actions must be
managed by CSIP (See WP.0.12).
3
Except for the development and FAT environments for which the contractor is responsible for all
service support and service delivery processes.
Page 26 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
WP.0.14
Security Management
The contractor will perform the activities compliant with TEMPO security management and EC
standards and Guidelines ([R42]). In particular in the case of information system development
(system supplier), the contractor will apply the TEMPO “Security Software Development
Lifecycle” reference manual and the EC “Secure Systems Development” standard ([R42]). As such,
it will deliver a Security Plan to the Commission.
Other specific EC standards to consider especially during the development of information systems are
the following: “Controls against malicious code”, “Cryptography and public key infrastructure”, “IT
Vulnerability and Remediation Management”, “Mobile Code”, “Information Systems Security Incident
Management”,”Web Application Security Standard”, “Transport Layer Security (TLS)”,
“Passwords” and “Logging and Monitoring”.
The security staff must act independently from the SOFT-DEV management.
WP.0.14.1
Produce and maintain a Security Plan
The contractor must produce and maintain a Security Plan covering all SCs in effect which is
describing the infrastructure of the contractor and the security measures the contractor will take to
secure this infrastructure from accesses from outside the SOFT-DEV zone and to assure the delivery of
its contractual services.
Regarding organisational security control, the contractor must at least, without prejudice to the
implementation of other security controls as required by TAXUD:
 Nominate a security manager that will coordinate security management activities and directly
liaise with TAXUD LISO for all these security related activities,
 Define an internal security organisation appropriate to the contractual activities,
 Provide security trainings and awareness sessions to its personnel,
 Manage and report security incidents,
 Implement security controls to monitor its compliance with its security obligations.
Business continuity measures and a disaster recovery plan must be annexed to the security plan.
The contractor has to report his security-related activities and recommendations to the Commission
through the Monthly Progress Report.
WP.0.14.2
Integrate Security Requirements
The contractor must integrate the security requirements from the TAXUD and EC security policies in
the execution of all Work Packages. The contractor must make sure that all security requirements are
known by all SOFT-DEV teams for implementation. It is part of the overall Quality Control activities
to validate if the security requirements are implemented correctly.
TAXUD and EC policies may be supplemented by good practices e.g. from ISO standards on areas
where no TAXUD policy is available. The baseline for security requirements should cover at least:








Requirements for security controls must be identified during specification phase,
Input data validation against threats (e.g. SQL injection, cross site scripting, oversized
input…),
Internal processing control (e.g. protection against buffer overflow, appropriate logging, …),
Cryptographic control (e.g. proper key management, traffic encryption requirements, …),
Least privilege principle for installation (e.g. application should not require root privilege to
be installed), execution (application should not be run using root privilege or with privilege
that allows modification of the installed application: application should run on a hardened
system) or data access (access to database should not be done with a user that allows full
control or full view of the information),
Protection of source code,
Compatibility with reference configuration (e.g. TAXUD desktop standard configuration,
DIGIT servers configuration, …),
Protection of test data (e.g. sanitisation, protection in a similar way to production systems,
protection of data during exchange, …)
Page 27 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Work Packages
 Antivirus protection for all files exchanged through the system,
 Documented patch process, including application patch procedures, procedures for patching
of underlying OS or middleware,
 Documented logging functions of the application, that ensure full user traceability of all
actions, error logging, security logging,
 Integration of security best practices (e.g. as OWASP, …) or common security functions (e.g.
as logging, virus checking, input validation,…) into the central application configuration
baseline).
Detailed explanations on the contractor role in the definition, implementation and testing the of the
security requirements during all the activities pertaining to the development lifecycle can be found in
TEMPO “Security Software Development Lifecycle” reference manual and EC “Secure Systems
Development” standard ([R42]).
WP.0.15
Business Continuity Management
This work package covers all activities to support DG TAXUD in their business continuity process
execution.
DG TAXUD performs on a regular basis business continuity process tests such to assure that all
processes and procedures are set up in case of a real discontinuity.
The SOFT-DEV contractor will be requested to provide contact details of management staff which can
be contacted for business continuity reasons. The list should be in cascade of management roles.
The persons to contact must be in a position to take initiatives to support DG TAXUD in actions
where the SOFT-DEV contractor is competent.
WP.0.16
Knowledge Management
This work package covers all activities to be performed by the SOFT-DEV contractor to build an
efficient knowledge management covering all the services of the SOFT-DEV contractor. The work
package covers mainly 2 types of activities:


WP.0.16.1
Produce and maintain a knowledge base for all stakeholders;
Knowledge transfer within the SOFT-DEV organisation.
Produce and maintain a knowledge base for all stakeholders
This work package is covering the required activities for the knowledge base elaboration and
dissemination. All knowledge related to SOFT-DEV services shall be captured and maintained live
through appropriate processes.
It must allow all stakeholders (internal and external to the SOFT-DEV contractor) to post and obtain
relevant information improving the overall knowledge about all SOFT-DEV services using ‘non
document’ techniques.
WP.0.16.2
Knowledge transfer within the SOFT-DEV organisation
This work package covers specific knowledge transfer activities within the SOFT-DEV internal
organisation. A specific example of such an activity could be the transfer of all relevant knowledge
when a new system/application is near to the end of its initial project lifecycle and goes into
maintenance and support lifecycles.
These activities must be traced by reports which must be available on-site and provided to the
Commission within 3 working days upon request.
2.2.2
WP.2 Take over
WP.2 Take-over
The takeover will not be organised as a ‘big bang’ but will be performed in phases, especially for the
takeover of the customs and taxation systems and applications. At the end of each and every phase, the
SOFT-DEV contractor will, following a successful FAT execution, become fully responsible for the
taken over systems and applications and be ready for operational support and maintenance activities.
Page 28 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
The key objectives of the takeover are to:
 Ensure continuity of the existing processes in place and for which DG TAXUD is responsible;
 Be ready to deliver all required services;
 Establish clear communication channels in the context of all involved systems and
applications;
 Ensure that proper coordination and collaboration strategies are put in place with all involved
stakeholders; if needed, meetings will be organised to meet the key actors of other entities and
to confirm the coordination processes;
 Formalise the transfer of responsibility from the incumbent contractors to SOFT-DEV and
define a clear reference baseline on the status of the specifications, software and related
documentation;
 Take over the security procedures and enforce them within the team.
The takeover must not affect the quality of service delivered, regardless of the situation in which the
system or application will be at the time. SOFT-DEV is responsible for taking all steps required in
order to achieve a rapid induction and a seamless takeover of all activities so that any scheduling
requirements or deadlines of DG TAXUD can be met.
The following describes all takeover activities to be performed. WP.2.2 describes the execution of the
takeover of the IT Central Applications and WP.2.1 describes the execution of the other take-over
activities.
Produce the Take-over Plan
The first key activity at the start of the takeover will be to define a detailed takeover plan in accordance
with the offer. The plan should consider resources, scheduling, deliverables and acceptance of all
deliverables.
The take-over plan should be based on the following assumptions:





The incumbent contractors will supply the required services until the end of the contract using
its existing infrastructure. This implies that the new contractor will have to set up a parallel
infrastructure to perform the take-over activities for the specifications and software of all
customs and taxation systems and applications. This infrastructure will be provided by DG
TAXUD as described in chapter 8 and the SOFT-DEV contractor will be expected to plan and
carry out the necessary software installations and maintenance;
The take-over activities should be planned in phases, allowing an item-by-item validation of
the readiness of the contractor in order to reduce the risk of interruptions. All activities must
be included in the takeover plan;
The take-over plan must guarantee the smooth transition of all specification, development,
maintenance and support activities without any discontinuity of services;
The take-over will be planned according to the end date of the existing contract with the
incumbent contractors and as such must be synchronised with the end of the services of the
incumbent contractors;
At the end of each take-over phase, all responsibility will have completely switched to the
new contractor.
The take-over plan must be aligned with the handover plan of the incumbent contractors and must
include (but is not limited to) at least the following points:







A description of the take-over methodology, including a change management approach
especially for the IT systems and applications which are subject to patches during the takeover activities;
An inventory of items in the scope of the take-over;
A description of all activities in the scope of the take-over;
A detailed schedule of the activities;
A strategy for the take-over FATs;
A knowledge transfer strategy in terms of the management approach, activities and planning;
A risk management strategy in terms of the management approach, activities and planning
(the minimum requirement is a risk analysis with mitigation and a fall back plan);
Page 29 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED

A detailed schedule of activities involving required stakeholders.
Set up Team
The SOFT-DEV contractor’s team(s) must be staffed as proposed in the SOFT-DEV tendering
documents and agreed with DG TAXUD, allocated to the activity and must remain allocated as of the
signature of the first Specific Contract and the takeover activities. When leaving the framework
contract, staff linked to key profiles (refer to section 6.2) must ensure the complete handover of all
acquired knowledge according to the knowledge management strategy outlined in the takeover plan
and FQP.
The SOFT-DEV contractor’s takeover team must be sufficiently sized and of the highest professional
standards to be able to manage the DG TAXUD IT environment, IT and administrative/contractual
processes and organisational complexity. The takeover team must be able to start its duties as of the
date of signature of the Specific Contract that will include the takeover duties. Any delay in
composing/staffing the team places risk on the overall takeover.
The SOFT-DEV contractor will be expected to cooperate with DG TAXUD (and possibly other
Commission departments like DIGIT), the incumbent contractors, the ITSM contractors, and other
third parties nominated by DG TAXUD.
Attend Training Sessions
DG TAXUD, mainly via the incumbent contractors, will provide trainings, at no cost to the SOFTDEV contractor. Trainings will be provided concerning the applications, the global architecture,
CCN/CSI, CCN2, TEMPO and any other relevant domain that is deemed necessary. The SOFT-DEV
contractor must ensure that the maximum number of staff (at least all staff linked key profiles (refer to
section 6.2) without exception) will be available to attend these training sessions. The training will be
provided with the purpose to “train the trainer”, so that the participants who followed the training
sessions can later provide the same training sessions for all SOFT-DEV teams. DG TAXUD will only
finance the takeover training once and it is then within the responsibilities of the SOFT-DEV
contractor to keep the knowledge internally regardless of any potential staff turnover. Such knowledge
will be registered as per WP.0.16.1. Attendance to training sessions should not be accounted via WP.8
(all inclusive WP) and should be described and scheduled in the takeover plan.
Validate the Baseline
The SOFT-DEV contractor must re-assess the status of the baseline to be taken over at the time of the
takeover to ensure that all deviations between the baseline at the time of the preparation of the
Invitation To Tender and the start of the takeover are taken into account.
Setup Office and IT Infrastructure
Refer to WP.8.4 and chapter 8 for more details on the tasks to be performed.
Validate Success Criteria
The following (non-exhaustive) list of takeover success criteria will be used to measure the readiness
of the SOFT-DEV contractor to start the services linked to this Framework Contract:
1. SOFT-DEV’s team is available, organised, trained and knowledge is kept and shared;
2.
The contract organisation (cf. All WP.0 sub activities) is in place and functioning, including
all aspects for the correct functioning of the Programme Management Office;
3.
The office and development environment at the SOFT-DEV contractor’s premises is
available, including all supporting tools needed;
4.
The FAT and Sandbox environments at the DG TAXUD data centre have been set up and are
available, including all supporting tools needed;
5.
The SOFT-DEV contractor has gained a profound knowledge of all services, specifications
and software to be taken over;
6.
Supporting and service management tools are available and have been adapted (where
needed) to provide automated services and the SOFT-DEV contractor’s team is ready to use
them (e.g. automated test tools, SMT, DML etc.);
Page 30 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
7.
The SOFT-DEV contractor can demonstrate its readiness to take-over the services, e.g.:


Ready to provide corrective and evolutive maintenance activities for the taken-over IT
systems and applications and related bespoke software;
Ready to deliver 3rd level support on all specifications, software and related
documentation which have been taken over.
The following aspects (non-exhaustive list) will be checked in order to validate the success criteria:











Production of all contractual reporting and its availability via the Application Lifecycle
Management platform;
Correct handling of demands from DG TAXUD;
Correct handling of 3rd level incidents assigned by the ITSM Service desk;
Correct handling of problem management;
Correct handling of change requests (evolutive maintenance);
Performance of corrective maintenance (i.e. defect/bug fixing under WP.8.1.4) for the taken
over applications/components;
Successful installation of each application/component on the test environment at DG TAXUD
data centre;
Performance of testing up to FAT of new releases according to the test plans;
Correct packaging of new releases including related operational documentation and delivery
to DG TAXUD as per procedure and updated in the DML;
Production of an updated version of the specification documentation and delivery to DG
TAXUD as per procedure and updated in the DML;
Provision of service transition support to ITSM.
Produce FAT Report
A FAT report should be produced after each and every phase whereby services have been taken over.
Produce the Final Take-over Report
Once all of the takeover activities in WP.2.1 and WP.2.2 have been completed, an overall take-over
report should be produced and should include a section on lessons learned.
Update the FQP
The SOFT-DEV contractor will take over the CUST-DEV3 and FITS-DEV3 Framework Quality Plans
(FQP) as the production of a new SOFT-DEV FQP is not foreseen during the takeover (please refer to
WP.0.1 for more details on the FQP). Consequently, all processes are to be performed as specified and
are only subject to change in the context of the CSIP. The same principle applies to the tools. The
takeover activities should contribute to optimising the definition of the quality framework of the
contract and proposals for modifications to the FQP can be gathered during the takeover period. An
updated FQP should be delivered no later than 3 months after the takeover has been completed.
WP.2.1
Take-over Activities
This work package describes the execution of all activities required for all take-overs with the
exception of the execution of the takeover of the IT Central Applications, which is covered by WP.2.2.
Execute Take-over
According to the schedule and strategy of the takeover plan, the SOFT-DEV contractor will take over:
 The maintenance and operation of the development-related IT equipment (hardware and
software) in the DG TAXUD data centre (see WP.8.4 for more details);
 All the items and the artefacts of the business and analysis domain as delivered in the baseline
at the time of takeover;
 All items and artefacts of the architecture and strategy domain as delivered in the baseline at
the time of takeover;
 All ARIS customisation artefacts: scripts, filters, reports, etc. at the time of takeover;
 All items and artefacts of the IT systems and applications in the customs and taxation
domains, at the time of takeover;
Page 31 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED


All items and artefacts of the SPEED2 business flows, at the time of takeover;
All items and artefacts of any horizontal nature which are of importance or interest to the new
contractor as delivered in the baseline at the time of the takeover.
The takeover should be organised using a phased approach and after each phase all responsibility will
have completely switched to the SOFT-DEV contractor who must be ready to:
 Provide corrective and evolutive maintenance activities for the taken over items and artefacts;
 Deliver support for all specifications, software and related documentation which have been
taken over.
WP.2.2
Takeover of the IT Central Applications
This work package concerns the execution of the takeover of all IT central applications. The
scheduling of all IT central application takeover activities should be defined in the takeover plan (see
WP.2.1). For each application, the following activities must be completed:
 Setup of the team, ensuring the availability of designated resources with application-specific
knowledge;
 Attendance to training sessions;
 Set up of development, integration, Sandbox and FAT environments for the takeover;
 Definition of FAT scope in the Acceptance Test Plan (ATP);
 Takeover of all items and artefacts of the IT central application as delivered in the baseline at
the start of the takeover; this implies activities such as installation, assuring that all items are
under configuration management, perform all required activities to master the specifications
and the software;
 Takeover of patches which have been produced by the incumbent contractors during the
takeover period and not delivered on the baseline at the time of the start of the takeover;
 Execution of the takeover FAT as specified in the ATP;
 Production of the FAT report.
Furthermore, for each IT central application, the SOFT-DEV contractor must produce an analysis
report counting the FSP (IFP and SNAP) points. At the end of each and every IT central application
takeover, the SOFT-DEV contractor must be able to start the applicable maintenance and support
activities for that IT central application.
2.2.3
WP.3 Hand Over
WP.3 Hand Over
To hand over part or whole of its activities to the Commission, or any specified third parties on its
behalf, at the end of the contractor’s framework contract, or earlier on request from the Commission.
The Commission may request the contractor to take specific steps to hand over part or whole of its
activities to the Commission, or to a third party, at the end of the implementation period of the
framework contract, or earlier on request from the Commission.
If requested by DG TAXUD, SOFT-DEV will be responsible for the physical move of the IT
infrastructure to the DG TAXUD Data Centres, the new contractor, or to any third party nominated by
the Commission.
WP.3.1
Handover Activities
The SOFT-DEV contractor must prepare all activities required for a successful handover to DG
TAXUD, or to any specified third parties on its behalf. All activities should be described and
scheduled in a handover plan. The handover plan must be synchronised with the new contractor’s
takeover plan.
During the handover period, the SOFT-DEV contractor will transfer the totality of the knowledge
acquired during the contract to DG TAXUD, or to any specified third parties on its behalf. This
includes (but is not limited to) all tools, all documentation, all deliverables, including source codes and
Page 32 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
scripts, and all other internal procedures, tools and packages.
The SOFT-DEV contractor will provide appropriate training and coaching to allow the new contractor
to takeover, whilst assuring continuity during this period.
The handover process includes the following phases:




Planning: to set up the list of all activities, resources, deliverables and milestones required to
successfully perform the handover to the Commission or any designated third party. This plan
will be proposed by the tenderer in his answer to this Invitation To Tender.
Preparation: to identify, collect and store all deliverables required to allow a smooth and
complete transfer of knowledge from the incumbent contractors to DG TAXUD, or to any
specified third parties on its behalf; to prepare, when required, training sessions for the project
team of DG TAXUD or to any specified third parties on its behalf;
Implementation: to effectively perform the transfer of the project knowledge (using planned
training and ad-hoc technical meetings) and deliverables (documents, software, hardware)
from the incumbent contractors to DG TAXUD, or to any specified third parties on its behalf;
Follow-up: to provide assistance to DG TAXUD or to any specified third parties on its behalf
during the handover process. All support activities related to the transfer of knowledge (adhoc technical meetings) from the SOFT-DEV contractor to DG TAXUD or to any specified
third parties on its behalf must be included. The SOFT-DEV contractor may not ask DG
TAXUD or any specified third parties to pay (within a bi-lateral contract) for support during
the handover due to the fact, amongst others, that intellectual property generated during the
current Framework Contract belongs to the Commission.
Failure to pass on the information and knowledge to the Commission or to a designated third party will
result in non-payment of the services of the SOFT-DEV contractor during the handover period.
This work package covers the handover of all artefacts, tools and related documentation except for
those related to the IT central applications which are handed over as part of WP.3.2.
The contractor must ensure (besides the deliverables via WP.0.10) that all security sensitive
information and personal data (such as personal names, telephone numbers, company names, etc.) is
removed from all deliverables and source code before the handover.
Once all of the handover activities in WP3.1 and 3.2 have been completed, a handover report should be
produced including a section on lessons learned.
Handover SAT
A Handover SAT plan will be submitted for review one month after the start of the handover.
The activities and services to be conducted towards the end of the hand over period – shall consist, as a
minimum, of the following checks (this list may change – by common agreement – half-way through
the hand-over period) :








The services, infrastructure owned by the Commission and hosted at the incumbent
contractors premises, the whole of the live and historical data and tools;
Software licenses have been fully transferred including the third party maintenance contracts.
The SOFT-DEV contractor must ensure on time the actions required for the transfer of
maintenance;
Proof of decommissioned items as agreed upon during handover planning has been provided;
The exhaustive list of project deliverables (including provided during the HO preparation and
execution) required to allow a smooth and complete transfer of knowledge that has been
handed over to the new contractor(s);
The full inventory of HW/SW assets, if any, with maintenance status (type and coverage, end
date, etc.) has been handed over;
All connections with the Commission-owned infrastructure have been closed down;
An administrative statement of intent assuring that existing users have been fully
disconnected is issued to DG TAXUD;
The remote connection tokens have been returned to DIGIT and all logins and passwords and
other credentials wherever required; including the ones used for accessing BIOS, OS,
middleware, websites, and third-party support tools have been handed over;
Page 33 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED





All keys and other access control devices granting access to computer units, racks, etc. have
been handed over;
All training sessions for the new contractor(s) have been performed;
All hand-over meetings with the new contractor(s) during the handover/takeover period have
been minuted and all agreed actions have been implemented;
A list of potential “remaining” risks to be handled should be provided;
All RfAs have been completed and all incidents assigned to the SOFT-DEV contractor have
been addressed, and their current status and next steps required for their resolution registered
in the SMT answered.
A Handover SAT reporting, listing the results of the execution of the Handover SAT plan will be
submitted for review 5 working days after the end of the handover period.
WP.3.2
Handover of the IT central applications
This work package consists of handing over all the activities related to the IT central applications
including (but not limited to) all tools, all documentation, all deliverables, including source codes and
scripts, and all other internal procedures, tools and packages.
The scheduling of all activities and deliverables required for the IT Central Application handovers
should be defined in the handover plan (see WP.3.1) and should include the following:
 Final outstanding defect list to be handed over;
 Final baseline of application source code and related documentation;
This work package also covers training sessions which must include:


Training sessions concerning the applicable architectural solutions;
Training sessions focused on each specific central application;
The contractor must ensure (besides the deliverables via WP.0.10) that all security sensitive
information (such as logins, passwords, IP addresses, etc.) and personal data (such as personal names,
telephone numbers, company names, etc.) is removed from all deliverables and source code before the
handover.
WP.3.3
“After handover” support
The SOFT-DEV contractor must provide a support service of 3 months to the takeover party as from
the successful handover.
At the end of the successful handover/takeover period, the SOFT-DEV contractor will continue to
offer “after handover support” for a duration of 3 months. This “after handover support” will consist in
offering stand-by (on-call) support for the new contractor(s). This support should be provided by the
SOFT-DEV contractor subject matter experts and cover all services provided in the scope of the
framework contract; particular care should be given to ensure availability of subject matter expertise
with all in-flight projects at that particular period of time. The handover plan shall document how this
service will be implemented; as a minimum it should document the profiles on stand-by during the
after handover support period.
The SOFT-DEV contractor must commit to start the intervention (a person with the appropriate level
of expertise is effectively working on the request) within:




2 Working-hours for Critical (Priority=1) incidents:
Half a Working-day for High (Priority=2) incidents;
One and a half Working-day for Medium (Priority=3) incidents;
Two and a half Working-days for Low (Priority=4) incidents.
During the “After handover support” period, a weekly reporting will be submitted by email, to DG
TAXUD. This will cover all activities performed during the week and will be submitted on the first
working day of the following week.
At the end of the “After handover support” period, the handover report produced in WP.3.1 will be
updated with a section describing the activities and the final status of all activities performed during
the “After handover support” period. The report will be resubmitted to DG TAXUD for review and
Page 34 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
acceptance (SfR + SfA).
2.2.4
WP.4 Architecture and Strategy
WP.4 Architecture and Strategy
The contractor will provide the following services and their associated deliverables:








Support to define, maintain and assess the IT Strategy for the customs and taxation domains,
the follow-up of its implementation and its impact on the various IT and Business objectives.
Produce and/or maintain an IT Portfolio and Master Plan laying out the projects portfolio for
the following 5 to 10 years and their high level planning of implementation according to the
IT Strategy and the business priorities and objectives.
Contribute to the development and maintenance of the IT Enterprise Architecture of DG
TAXUD, which is coherent with the European Interoperability Framework (EIF) and
Corporate IT Enterprise Architecture Framework (CEAF), managed by DG DIGIT. This
activity is driven by Unit B2 in DG TAXUD, supported by its contractors. SOFT-DEV is
consulted on its evolution.
Development of the evolution and maintenance of the Application and Service Architectures
for TAXUD systems design and build and for the EU Customs and taxation systems
integration. This must be in line with the infrastructure components (e.g. UUM&DS, CCN,
CCN2, SPEED2ng), as managed by Unit B2, and that of the systems linking with Member
States and third parties for data exchange and service management. Proposals for evolution of
the Application and Service Architecture must be agreed and aligned between all units in
Directorate B, supported by the contractors.
The architecture evolution shall take into account the ITSM3 OPS Technology roadmap [R
09] and the Infrastructure requirements for developers [R10].
Support the different layers of implementation of the application and service architecture into
the applications and services.
Support on the use and maintenance of architecture and modelling tools in general and on the
ARIS tools specifically.
The architecture work shall fully take into consideration the security requirements.
Whatever the scope and context of any request within WP.4, the delivery must by all means assess the
impact, alignment and coherence with any item related to WP.4 activities either developed or taken
over in the context of this contract or maintained by other related actor. Examples of these items are
the Multiannual Strategic Plans (MASP-C and MASP-T), TAXUD IT Strategy, EU Customs and
taxation Policy, TATAFng or TEMPO methodology.
Architecture and Strategy support shall be assured as a continuous service under which the proper
coherence and evolution of the architecture layers is ensured, measured and reported.
The contractor shall provide expertise to develop enterprise architecture in line with defined strategy;
to define, assess and coordinate architecture projects, to design architecture building blocks; to design
and coordinate architecture implementation; to align and integrate multiple architectures, layers and
perspectives; to advice on architecture frameworks and methods; to define and measure architecture
indicators (maturity, implementation, etc.); to ensure interoperability; to identify potential reuse; to
perform cost-benefit analyses; to design Service.
Oriented Architecture; to design and assess Identity and Access Management and Master Data
Management solutions; to coordinate the technical implementation; to perform Business Analysis and
contribute to the Functional, Technical, Security and Testing Specifications.
The contractor shall have the capacity to assess innovative technologies and tools that become
available on the market in view of their potential integration into the customs and taxation IT
architecture. If a new technology and related tooling set is selected for implementing a system or
application, the contractor must be capable of acquiring expert knowledge in complement to training
Page 35 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
its existing staff, such as to ensure the timeliness of adopting the innovation and ensuring the quality of
the artefacts produced using this.
WP.4.1
Support on IT Strategy definition and implementation
The contractor will provide support for the definition of a coherent IT Strategy for Customs and
Taxation and advice for its implementation. This includes identifying IT Strategy alternatives in line
with the organisational and business strategy and objectives and assess their impact for Commission,
Member States, Economic Operators, Traders and other stakeholders on key aspects as for example:









Costs and effort
Time to market
Projects Portfolio and IT Master Plans
Technical implementations
IT and Business capacity
Business processes and operations
Development and support methods
Organisation structure and responsibilities
Related legal, commercial or procurement matters
The above and any other aspect impacted either positively or negatively by the IT Strategy alternatives
must be assessed and measured using traceable and contrastable methods and indicators with values
solidly based on available information or on rational assumptions. These assessments will probably
require high qualified expertise not only on IT matters but also on legal, commercial, business,
financial or other matters directly or indirectly related to the Customs and taxation business and the
related Information Technology domain.
The above will be provided in the form of specific studies and will include frequent bilateral or
multilateral consultations with Member States (MS) either in Brussels or in MS territory. It will also
require participation in workshops and seminars where the contractor will explain the results to the MS
and or TAXUD.
WP.4.2
IT Portfolio and Master Plan definition and maintenance
The contractor will produce and/or maintain an IT Master Plan as an independent document or as part
of the Multi Annual Strategic Plans (MASP-C and MASP-T).
The IT Portfolio consists of a document or a series of documents and architectural descriptions listing
and describing the IT portfolios, projects and activities to be realised by the stakeholders in the field of
Customs and Taxation (EU institutions, MS administrations and economic Operators) in the upcoming
5 to 10 years.
The IT Master Plan consist on a high level work plan laying out in time the portfolios projects and
activities to be realised by the stakeholders in the field of Customs and Taxation (EU institutions, MS
administrations and economic Operators) in the upcoming 5 to 10 years.
The IT Portfolio and Master Plan lay down the IT Strategy according to the business objectives and
taking into consideration any constraints or factors temporal or structural, internal or external that may
impact the execution of such plan for any of the stakeholders.
The contractor will be responsible for the evolutive maintenance of the IT Portfolio & Master Plan
with one major and two minor revisions every year. A major revision includes:



The review of the whole IT Portfolio and Master Plan to assure its validity with the IT
Strategy and with the Business objectives
The evaluation and report on the Master Plan realisation in the past year including its
reassessment to better implement the IT Strategy or to minimise the risk of non-realisation of
business objectives
The revision of assumptions, indicators and assessment methods in order to better reflect
Page 36 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
reality both of the portfolios structure and the time plan on whatever form they are laid out
Corrective maintenance of the IT Portfolio or the IT Master Plan require minor revisions covering the
adjustment of the time plan, additions or removal of projects or modifications on their descriptions
according to change in business requirements.
WP.4.3
Architecture Framework Support: Vision, Methods and Evolution
The contractor must develop and maintain the Architecture Framework and methods for the EU
Customs and Taxation IT systems, in line with the overall Enterprise Architecture and Infrastructure as
managed by Unit B2.
The Architecture Framework and methods are the model and methodology to build and maintain the
architectural instruments that support the IT Strategy and the fulfilments of the Business Objectives.
They must comply with or follow internationally recognised Architecture Frameworks and with the
corporate Enterprise Architecture frameworks, including CEAF and EIF.
The Architecture Framework may cover at least the following aspects:



WP.4.4
Architecture Vision and Strategy serving as a business case for the use of Architecture
methods and instruments, explaining which ones, how and why to best use them in the
context of EU Customs and taxation, how they must be governed and evolved and how their
benefits must be measured using indicators.
Architecture Methods and Conventions providing the methodological base for the
development and maintenance of architectural items and models. They explain the structure
of the different architectures and the guidelines and conventions within each one.
Architecture development method: guiding the development, governance and evolution of
each of the different architectures as a unique and coherent body.
Enterprise Architecture development and maintenance
SOFT-DEV must contribute to the development and maintenance of a coherent Enterprise
Architecture, as managed by Unit B2. It means specifically that the infrastructure and the platform
domains level Enterprise Architecture activities are managed by the Enterprise Architecture Sector
(EAS) within the Unit B2 of DG TAXUD and that SOFT-DEV will be requested to contribute to these
activities. Whereas for the Application layers of the Enterprise Architecture, SOFT-DEV with Units
B3 & B4 will manage said Application Architecture layers of the Enterprise Architecture with
contribution of the the Enterprise Architecture Sector (EAS) within the Unit B2.
The Enterprise Architecture is between and above all existing architectures encircling and associating
them, assuring their alignment and providing an overall context to place them within the Business and
IT Strategies and goals in the fields of Customs and Taxation. It hence consists on a series of models
and documents describing the overall context and assuring or facilitating the alignment of the different
architectural perspectives (business, data, service, technical architectures, national architectures etc.).
Among these the key goal of the Enterprise Architecture is the Business to IT alignment in all possible
aspects.
The activity consists firstly on the development and maintenance of an enterprise architecture
framework and the provision of studies or development of architecture elements (models and
documents) within the above context.
The Enterprise Architecture also targets the facilitation of interoperability via convergence and
harmonisation among the various IT systems and provides the instruments not only to measure these
aspects but also to improve them by enabling collaboration, sharing or standardisation. The Enterprise
Architecture includes reference architecture that establishes the common understanding necessary to
fulfil those objectives.
Enterprise Architecture is above all a communication activity using architectural perspectives and
instruments as means to develop a common understanding of an organisation, assuring alignment and
coordination of the different stakeholders and activities making the right decisions towards the
Page 37 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
common goals. The Customs and Taxation domains are very complex and therefore require specially
intensive and continuous effort on communication among the stakeholders in order to create and
maintain a common language, in particular for those Member States that collaborate in view of the
creation of common services and solutions.
The contractor will be required to actively participate in workshops, seminars, bilateral and multilateral
meetings with TAXUD services and its contractors, visits to Member States Administrations and/or
Trade representatives to promote the Enterprise Architecture.
WP.4.5
Application and Service Architecture development and maintenance
Development and maintenance of the Application and Service Architectures for TAXUD systems and
for the IT systems integration.
The contractor will develop and maintain Application and Service Architectures in order to define the
most appropriate solutions for maximising the efficiency of:



The deployment, maintenance and governance of IT applications and/or IT Services at EU
level in general and at TAXUD in particular;
The integration, sharing and reusability of application functionalities, services and data
among applications and services and of these with external systems at EU level in general and
at TAXUD in particular;
The design methods and solution patterns that increase development efficiency and reliability
of National and TAXUD systems.
For the above all possible architectural layers must be considered in their current status providing input
for their improvement and their expected evolutions so as to influence them towards the most efficient
solutions. The efficiency of the proposed solutions shall be measured considering technical,
organisational, cost and other practical factors or constraints and make use of clear and explicit
assumptions.
Any architectural evolution shall be depicted in the form of a target architecture fixing the objective
and transition architectures for the gradual implementation from the as is architecture and based on an
impact assessment. The measurement of the evolution and positive or negative impact shall be done
via the use of clear and concrete indicators.
The architectural work could trigger the launch of specific projects for the implementation of tools or
services required for the correct implementation of the target architecture (e.g. development of utility
services, implementation of common data services, introduction of tools or repositories, etc.). These
projects will be realised within the scope of the corresponding Work Packages and managed by the IT
projects and support team.
The architectural layers to be considered include those under the responsibility of other services as
infrastructure components (e.g. UUM&DS, CCN, CCN2, SPEED2) in which case the contractor shall
be able to work in coordination with them and find together the best solutions under the existing
constraints. Other more ambitious endeavours, such as the creation of a private Customs and/or
taxation cloud, are not excluded.
The contractor, depending on the context, will either be requested to partially or completely develop
one or several Application and Service Architecture layers in collaboration with a number of Member
States experts.
The Application and Service architecture shall cover:


Global Customs / Taxation Application and Service Architecture to be considered as a
reference for the integration of IT systems which will focus on systems integration, data
sharing and reusability and serve as support collaboration initiatives among Member States.
DG TAXUD Application and Service architecture aligned with the above but much more
concrete for those applications and services developed under the responsibility of DG
Page 38 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED

TAXUD.
The integration with the IT Enterprise Architecture and Infrastructure components as
managed by Unit B2.
The DG TAXUD Application and Service architecture aspect shall be the most important and concrete
objective of the activity and will have as starting point in the Customs domain the TATAFng
framework but shall evolve in consideration of TAXUD IT Strategy and business requirements and in
adaptation to new technologies and methods (e.g. MDM, SOA, data analytics, microservices) and
evolution of the available platforms (SPEED2ng, CCN2ng), or the design of new ones, in a cloud
delivery mode.
The contractor shall provide on request the necessary support to TAXUD and the Member States in the
form of studies, market prospections, functional and/or technical analysis, consultancy, training,
workshops, etc. that help manage the change towards a coherent Application and Service architecture
for the Customs and Taxation systems in general and for DG TAXUD in particular.
WP.4.6
Application & Service Architecture management and support
To manage and support the different layers of implementation of the application and service
architecture into the applications and services
1.1.1.
The following layers have to be considered:



WP.4.6.1
Architecture development management and support
To provide application and service support to the development team(s) (list indicative and not
exhaustive). Based on a solid knowledge of the TAXUD application architectures and frameworks:




WP.4.6.2
The development layer requires architectural management and support to elaborate a correct
IT design for a given IT system/application or service;
The implementation layer requires architectural management and support to guarantee a
correct transition into production;
The transition and operations layer requires potential support to resolve problems during the
service transition activities and during the production lifecycle, to ease deployment,
monitoring, fault identification, and to resolve problems.
Provide Architecture guidance for the IT design activities;
Provide insights and leading practices derived from the applicable application and service
architecture and framework;
Provide SOA expert advice taking into account the overall enterprise architecture of the
customs and taxation systems and applications;
Provide design patterns to enhance the quality of the solution; or to resolve problems related
to the constraints inherent to application development at DG TAXUD (e.g. manage high data
volumes).
Architecture implementation management and support
To provide application and service support to prepare the transition and production of the IT
system/application and services (list indicative and not exhaustive):




WP.4.6.3
Provide subject matter expertise with ad-hoc involvement of experts contributing with their
experience on domains like Oracle, Java
Provide technical expertise to mitigate on potential risks or even solve with identified
technology issues e.g. SPEED2 MQ implementation
Check about the overall consistency of all architecture tasks and deliverables and propose to
DG TAXUD possible options and recommendations for implementation.
Simulate Member States integration on test environment to anticipate any potential
showstoppers.
Architecture transition and operational support
To provide application and service support during the transition and production phases (list indicative
Page 39 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
and not exhaustive):


WP.4.6.4
Acquire and consolidate the knowledge of the different transition and production
environments;
Provide subject matter expertise with ad-hoc involvement of experts contributing with their
experience on domains like Oracle, Java, and data analytics.
Architecture Continuous Improvement
To improve and guarantee the architecture excellence (list indicative and not exhaustive):




WP.4.7
Conduct regularly controls of the quality of code produced, quality of installation procedure,
automated tests, monitoring, and other ancillary artefacts through project independent code
reviews;
Liaise with the development and support teams on architecture aspects;
Propose changes for the framework and various artefacts of Application and service
architecture;
Follow up of architectural standard and provide regular updates to DG TAXUD architecture
team.
Support on ARIS and Architecture tools
This work package covers the support on the use and customisation of tools used for architecture work.
The support is to be provided in the form of:






Audits on the correct usage of the tool and on consistency of their content;
Web publication and/or merging of data bases within the tool (when automatically allowed by
the tool);
Maintenance of the user guidelines and modelling conventions for the use within TAXUD, in
particular to take into account the CoRA methodology (refer to Tender Specifications - Part B
(Terms of Reference) section 8.3.2);
Guidance and support on the use of the tool by TAXUD staff and other contractors;
Customisation or configuration of the tool for the use within TAXUD, including realisation of
report scripts;
Advice on the use of alternative tools for specific modelling or architecture uses.
DG TAXUD makes extensive use of the ARIS tool for Business Process Management and architecture
purposes, however this WP relates specifically but not exclusively to the ARIS tool.
2.2.5
WP.5 Business Analysis, Modelling and Data Integration and
Harmonisation
WP.5 Business Analysis, Modelling and Data Integration and Harmonisation
This work package covers the activities undertaken to produce and maintain the Business Process
Models, Business specifications and Data Integration and Harmonisation (DIH) activities for Customs
and Taxation and Taxation European Information Systems. In the Customs domain, it covers in
particular the preparation and maintenance of the EU Customs Data Model (EU CDM) and Single
Window certificates data mapping activities.
A Customs or Taxation EIS require the existence of business documentation which will guarantee that
business requirements are achieved and that the different systems interact in the correct way and will
act as one single system.
The work package covers in general terms:



The production and maintenance of Business Process Models;
The production and maintenance of business (functional) system specifications;
The production of Feasibility Studies and planning documents;
Page 40 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED



The production of business proof-of-concepts;
In the Customs domain, the preparation of the EU CDM and its maintenance;
The preparation of data mappings for certificates in the EU Single Window environment for
customs programme.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of delivering
WP.5 deliverables are considered as part of the delivery work.
Training/workshops required in support of production of BPM and specifications and DIH activities
will be accounted under WP.8.
The production and maintenance of BPM and specifications will be supported by a specific software
selected by the Commission and a dedicated specification infrastructure (e.g. ARIS tool).
The data integration and harmonisation activities will be supported by a specific software selected by
the Commission and a dedicated specification infrastructure (e.g. GEFEG.FX software).
The specifications must be placed under strict Configuration Management in order to support their
iterative, incremental production and their further maintenance.
Maintenance can be of the following nature:


Evolutive maintenance will always be triggered on request by the Commission;
Corrective maintenance is triggered by incidents resulting in error recording and subsequent
correction. The incident can be initiated by the users via the service desk (managed by the IT
Service Management contract). The contractor is encouraged within this task to apply
preventive maintenance in order to limit the possibility of further errors.
All new BPMs, specifications and DIH artefacts are produced and maintained in EN. Some of them
might need to be translated into DE and FR (cf. WP.8.5.5).
WP.5.1
WP.5.2
WP.5.3
WP.5.4
Feasibility Study
This work package covers the production of a feasibility study.
A feasibility study aims at giving enough information to decision makers to enable them to decide on
the activation of subsequent project phases for a given EIS.
The feasibility study document can cover various items following the request of the Commission.
Some examples of these are: a problem statement, high-level requirements, business cases, business
solutions, impact assessment, etc. The document will always contain a costing plan and a time
schedule.
Work can include as well the maintenance or update of earlier produced feasibility studies
Business Analysis
This work package covers the analysis and support to the production of Business Documentation and
Business Cases.
It is necessary that this work is performed by an expert in Customs and / or Taxation Legislations and
Procedures.
Production and maintenance of Business & System Process Modelling (Levels 1, 2 and 3)
This work package covers the production and the maintenance of a Business Process Model (BPM) for
a system in compliance with norms and standards indicated by the Commission and will serve the
purpose of creating or maintaining Customs and Taxation European Information Systems.
The BPM depicts and describes the business processes and flows of information for a given business
domain. The Business Process Modelling Notation (BPMN) is used as the graphical syntax notation.
Although the production of requirements is specified in the next work package, it can be the case that
the two disciplines are applied within the same phase and the results combined within the same
deliverable. This is especially the case for system requirements.
The model can be complemented with an animation implementation in order to clarify the timing and
condition elements of the model. This animation will be driven by scenarios and can be used for
validation and training purposes.
Production and maintenance of Business Requirements
This work package covers the production, maintenance and support of business requirements.
Requirement specifications determine in detail the expectations for the the user or stakeholder to get to
Page 41 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.5.5
the functional requirements and non-functional requirements.
Non-functional requirements are requirements such as operational requirements (capacity, monitoring,
availability, statistics, etc.), technical requirements (architecture, performance, etc.), testing
requirements, training requirements, security requirements, etc.
Production and maintenance of Detailed Level 4 BPM (Business or Functional Specifications)
This work package covers the production and the maintenance of Level 4 Business Process Models.
These models describe in detail the processes, the rules, the conditions, the data elements etc.
The specifications must take into account the functional and non-functional requirements.
Based on the BPM Levelling Guidelines, the Detailed BPM Methodology and the overall
Methodology Document, ‘Level 3’ User Requirement BPM will be developed into ‘Level 4’ Detailed
BPM. These Level 4 Detailed BPM are developed from a system point of view, where it will be
necessary to fully analyse the business process to identify the parts which will be automated and which
are manual.
It is expected that Level 3 User Requirement BPM (prepared under WP.5.3) may be changed based on
small business updates and evolutions. In addition, there will be changes to add grouping around tasks
in order to link from Level 3 to Level 4 models.
WP.5.6
Regular working sessions will be held with the stakeholders in order to decide on how to model the
detailed BPMs in the best way. Additionally any decisions regarding documentation on what will be
covered by a system versus what is manual will be agreed upon during the execution of this task.
Business Acceptance Criteria document (BAC)
This activity includes:




WP.5.7
The BAC document will indicate how business specifications will be taken into account for
acceptance testing of a Customs or Taxation EIS to support sign-off by the System Owner of
the development deliverables;
The BAC will describe the Business acceptance criteria in a way that they can be directly
used for the creation of acceptance test scenarios for the Customs or Taxation EIS;
For this purpose production of the business acceptance criteria should be done with a view of
developing acceptance test scenarios and facilitating the evaluation of test results against the
business acceptance criteria;
This tool should be used to capture the business acceptance criteria in relation to the BPM and
requirements.
System Scope Management
It is common practice that large and complex systems are introduced in phases.
The scope management will facilitate keeping track of the partial implementation of the functionality
of the Customs or Taxation EIS in clearly defined phases.
The Scope management will enable to identify which part of the business process and system
documentation is related to each of the defined phases. It cannot be excluded that a specific tool could
be used for this purpose.
This work package will cover the setting up of scope management ant its maintenance for given
systems introduced in phases.
WP.5.8
4
Production and publication of Data Integration and Harmonisation artefacts
This work package covers the production and the maintenance of the EU Customs Data Model and
Taxation Data Model4 and as well of any data mapping activity.
At the time or writing, there is no Taxation Data Model as each Taxation EIS as its own.
Page 42 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Regular working sessions will be held with the stakeholders in order to decide on how to model the EU
CDM and data mappings in the best way.
The artefacts for the EU CDM and data mappings should be produced in HTML and as well
GEFEG.FX formats in the GEFEG repository.
This Work Package covers as well :










WP.5.9
Evolution of the EU CDM based on various inputs;
Preparation of a new version of the EU CDM resulting from changes in the legislation or on
request by the Commission;
Preparation of Data Maintenance Requests (DMRs) to the World Customs Organisation
(WCO) following from a new version of the EU CDM;
Preparation of information and training materials on the use and features of EU CDM (after
every new release of EU CDM);
Webinars on the use of EU CDM (for general, international audience, including MS customs
and worldwide customs partners representatives, and as well DG TAXUD officials);
Remote support via WebEx (or other remote meeting tool) on data mapping
Follow-up of changes in WCO Data Model;
Hosting GEFEG.FX repositories for DG TAXUD and providing user management for the
hosted repositories;
Enabling the collection of visitor statistics of the EU CDM publication and provide regular
access to visitor statistics.
Analysis of the EU CDM and tax data models with a view to aligning them.
Integration of Partner Competent Authority (PCA) certificates in EU Customs Single Window
Certificates Exchange (EU CSW-CERTEX)
This work package covers the integration of partner competent authority (PCA) certificate domains in
the EU CSW-CERTEX, categorised as (1) Complex PCA domain, (2) Medium complexity PCA
certificate domain and (3) Simple complexity PCA certificate domain.
(1) Complex PCA certificate domain:
The domain can be classified as complex if three out of four below indicators below are met.
Benchmark is for instance the CHED domain (CHED-PP, CHED-D, CHED-A, CHED-P).
Indicators to define this level of complexity:
1. The domain involves mapping to all three types of customs procedures (i.e. import, export and
transit)
2. The domain involves at least three TARIC document codes.
3. The domain involves mapping to EU CDM and WCO (where EU CDM mapping is not possible).
4. The domain involves mapping of more than 300 data elements.
(2) Medium complexity PCA certificate domain:
The domain can be classified as medium complex if three out of four indicators below are met, but the
domain does not qualify as Complex.
Benchmark is for instance ODS domain (ODS Import and ODS Export).
Indicators to define this level of complexity:
1. The domain involves mapping to at least two out of three types of customs procedures (i.e. import,
export and transit)
2. The domain involves at least two TARIC document codes.
3. The domain involves mapping to EU CDM and WCO (where EU CDM mapping is not possible).
4. The domain involves mapping of more than 100 data elements.
(3) Simple complexity PCA certificate domain:
All domains that cannot be classified as complex or medium complex will be classifies as simple. As a
Page 43 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
benchmark, the FLEGT domain can be taken as an example.
Indicators to define this level of complexity:
1. The domain involves mapping to at least one out of three types of customs procedures (i.e. import,
export and transit)
2. The domain involves at least one TARIC document code.
3. The domain involves mapping at least to EU CDM.
The deliverables for each PCA certificate domain are:
 Set-up the mapping environment in GEFEG.FX for the certificate domain (with report about
set-up);
 BPM release (Level 1 to 4) in ARIS (incorporation of new domain into EU CSW-CERTEX
BPM);
 Data mapping in Excel and GEFEG.FX formats;
 Guidelines release in Word and Excel (incorporation of a new domain into EU CSWCERTEX overall guidelines document);
 BAC document release in Word and Excel (incorporation of new domain into EU CSWCERTEX overall BAC document);
 Quantity management paper in Word per PCA certificate domain.
Page 44 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.5.10
Business Request for Change (RfC)
This work package includes the preparation of RfCs as per RFC form with detailed analysis and
impact assessment of different BPM Levels (BPM L2-L3 and BPM L4), any required revisions of
RfCs or further analysis following DG TAXUD discussions/review and also revisions after CAB.
In addition, this WP covers the role of “request tracking system” manager meaning to:
 Register all proposed received changes in the request tracking system. This might include
preliminary analysis to identify whether the change request concerns more than one domain.
If yes, this will require the creation of one RfC per domain.
 Follow up and maintain all registered RfCs in the tracking system. This includes an update of
the RfC status based on decisions and as per agreed change management procedure until its
implementation and subsequently closure from the acceptance of a release implementing this
RfC.
The RfCs are categorised into “Simple”, “Medium” and “Complex”.
Complexity
Description
Simple
BPM:


Cosmetic change in one model (BPM L1-L2-L3)
Changes requiring updates to one attribute (e.g. name, legal
reference or description) of one ARIS object in L2-L3
BPMs (e.g. task, event, pool, assumption)
Data:

Medium
Naming, format changes
BPM:


Cosmetic change in multiple models (BPM L1-L2-L3);
Modelling changes in one model without the need for
discussion with DG TAXUD (BPM L1-L2-L3);

For BPM L2-L3: Changes in FADs
Requirements:

Data:

Complex
Changes to business requirements
Changes to High-Level Data (e.g. eERM Diagram)
BPM:



Modelling changes in one model, requiring discussion with
DG TAXUD (BPM L1-L2-L3);
Modelling changes in multiple models (BPM L1-L2-L3);
Changes affecting both BPM L2-L3 and BPM L4.
Data:

WP.5.11
Changes impacting data at more than one level (conceptual,
logical, functional, physical) (e.g. Message Allocation
Diagram)
Business Proof-of-Concept (PoC)
In order to scope a given business activity, a PoC could be required and this Work Package is about
the preparation of business PoCs which should be done in iterative or agile manners.
Page 45 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
2.2.6
WP.6 IT analysis and design
WP.6 IT analysis and design
This Work Package covers all activities to produce and maintain all relevant IT specification artefacts
for the IT systems and applications.
DG TAXUD develops its IT systems and applications according to the TEMPO methodology, which at
the time of writing is being updated to integrate the Agile methodology described in section 3.3 of the
Tender Specifications - Part B (Terms of Reference). As any other methodology this is subject to
legacy and evolution. The contractor will have to manage systems and applications developed at
different times, applying different terminologies than the ones which have been developed more
recently. A large section of the portfolio was developed using SDLC (based on RUP).
WP.6 and WP.7 apply to all new developments and functional/technical evolutions and will apply by
default the Agile methodology described in section 3.3 of the Tender Specifications - Part B (Terms of
Reference). The methodology is based on continuous analysis, carried out in the release Agile Iteration
Phase, resulting in specifications and other release artefacts being built incrementally along with the
software release increment in the same or a near iteration.
All corrective activities required to come to a successful roll-out into conformance/production are an
integral part of the ordered IT analysis and design activities and not subject to additional cost. All
detected IT specification defects must be registered and traced in the agreed toolset which is used for
the business and operations support (refer to section 8.5). During the iterative process, by default, bugs
or defects of any kind, including technical debt and critical source code quality issues, detected during
an iteration must be fixed during that iteration or the next iteration, without significantly impacting the
release planning. If detected during the last iteration of the Agile phase, they must be fixed by the end
of the Transition Sprint.
Possible Requests for Change which are applicable to the ordered IT analysis and design activities
have as well to be registered and traced in the agreed toolset which is used for the business and
operations support (refer to section 8.5).



All items produced under this Work Package must be placed under strict Configuration
Management (refer to WP.8.2) in order to support their iterative, incremental production and
their future maintenance. To this purpose the contractor must ensure that the CMDB, DML,
Infrastructure baseline and document repositories used in the context of the framework
contract are continuously kept up to date. This Work Package covers the iterative and
incremental delivery of the items produced, for information, iteration review and work item
acceptance purposes.
Corrective maintenance for IT specifications (also for IT systems and applications taken over
from the incumbent contractors under WP.8.1.4.1) is triggered by incidents resulting in defect
recording and subsequent correction.
Wherever beneficial, DG TAXUD wants to move away from document-based IT
specifications towards tool-based specifications. Specifications increments delivered during
the Agile iterative process will by default be provided on a tool such as a collaborative
platform, ideally the Application Lifecycle Management platform (refer to section 8.5.1),
rather than via documents, and their formal consolidation possibly into documents will be
achieved during the Transition Sprint. Refer to chapter 8 for tool requirements.
All specifications are produced and maintained in EN.
All activities under WP.6 are by default subject to be covered by the FSP (IFP and SNAP) price
elements.
WP.6.1
Feasibility Studies or any activity linked to IT inception work
To produce feasibility studies and IT inception artefacts which cover various requests by the
Commission such as vision documents, proof of concepts, technical business cases, impact
assessments, technical solutions, prototypes, etc.
This work package covers the production of feasibility studies or any deliverable linked to IT
Page 46 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
inception work. This results in the provision of strategic advice for the technology direction and more
long term vision.
The feasibility study document can cover various items following the request of the Commission.
Some examples of these are (list indicative and not exhaustive):







A problem statement, high-level requirements,
Impact assessment covering impact analysis on other related systems/components,
Description of technical solutions,
Prototypes,
Assessment of the advantages and disadvantages of each option so they can be ranked,
Cost and cost/benefit analysis,
Resource and planning aspects.
A Feasibility Study aims at giving enough information to decision makers to enable them to decide on
the activation of subsequent development phases for a given system or application.
WP.6.2
IT Requirements
This work package covers all activities associated with the definition and assessment of requirements
that are further used to determine IT analysis and design.
Requirements can be registered in different ways and for different parts of a given system/applications
(non-exhaustive):
 If existing, the business process models define the functions to be implemented with the
required external interfaces.
 Data related artefacts, such as the Conceptual Data Model.
 User interface components require specific requirement determination. This can be done by
applying techniques such as use case analysis or other.
 Agile user stories.
 Non-functional Requirements are more IT operational requirements (performance, operations,
capacity, monitoring, availability, statistics, etc.), requirements for installation, monitoring,
testing, training, security, etc.
 Alignment with Enterprise architecture, infrastructure, technical roadmap.
This work package covers the drafting and maintenance of the user stories and other work items
included in an Agile product backlog and the preparation of their acceptance criteria (the “Definition
of Done”), as defined by the Agile methodology.
WP.6.3
IT System/Application system modelling
To conceptualise and construct IT solutions.
This work package covers the production and maintenance of architectural solutions for the IT
systems/applications.
The architectural solutions of a given system or application map onto portfolio conceptual
architectures and frameworks. In fact, they describe an implementation of the architecture defined at
portfolio level.
The specification of the architectural solutions must enable the relevant stakeholders (e.g. DG TAXUD
architects, ITSM architects, SOFT-DEV development team(s), etc.) to understand how a given IT
system/application will work from a technical viewpoint. The solutions could be presented in different
types of architecture models: structural view, logical view, physical view, conceptual/development
view, process view, execution view, etc.

WP.6.4
These IT system/application models must also include the interfaces with the other systems
(internal as well as external) and must be compliant with DG TAXUD’s enterprise
architecture.
IT Analysis
This Work Package covers all activities to produce or maintain all required artefacts which specify all
elements in terms of what needs to be implemented for a given IT system/application.
Page 47 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
The produced artefacts are mainly of a functional/processing, input, output and user interface nature.
Some of these artefacts are used as a basis for the further development of a central application, some
other as destined for external stakeholders, such as Member States or Partner Countries, and to be used
as a basis for local implementations.
The analysis activities must take into account the functional and non-functional requirements.
WP.6.5
IT Design
This Work Package covers all activities related to the technical design of a system or application and
produces or maintains all required artefacts which specify how the required processes, functionality
and data will be implemented; This must be aligned with the IT system/application system model and
the IT non-functional requirements.
Design specifications define how the functional specifications and the IT non-functional requirements
will be implemented and consist in general terms of technical artefacts defining (indicative list) the
message exchange protocols, process implementation specifications, database schemes, etc. This is the
basis for the required development activities covered under WP.7.

If a system/application foresees the implementation of a system-to-system interface by one or
more Member States or by other external stakeholders the artefact(s) to produce and to
maintain for that purpose are of crucial importance as they are the blueprint for the technical
interoperability.
Non-functional requirements such as performance, operations, availability, capacity, continuity,
security, etc. must be part of the design considerations.
WP.6.6
IT Testing
This Work Package covers testing activities which are to be performed in parallel with the IT analysis
and design activities. It consists mainly in the production or maintenance of the Master Test Plan and
the production or the maintenance of the required test scenarios.
Note that testing covers not only functional and non-functional testing for the given IT
system/application in isolation, but also (automated) integration testing with other applications
developed and maintained by SOFT-DEV, as well as integration with the underlying infrastructure
(CCN, CCN2ng, SPEED2ng, UUM&DS, …). The SOFT-DEV contractor is responsible for ensuring
that all integration inter-dependencies are covered in its testing activities.
WP.6.6.1
Master Test Plan (MTP)
The Master Test Plan spans all test activities for a given IT system/application. It is the first artefact of
a given testing lifecycle.
WP.6.6.2
Test Design Specifications (TDS) – Test Scenarios
During the testing lifecycle various test artefacts are produced at different points in time. All these
artefacts are grouped under the terminology ‘Test Design Specifications’. This Work Package covers
the production and the maintenance of the test scenarios.
Test scenarios are grouped according to their scope (e.g. functional, performance, etc.) and get their
own acronym under the TDS umbrella. They are not considered as executable test cases but express
what scenarios have to be performed in a positive or negative way to test a given function or
requirement (can be non-functional). Examples of these are business user scenarios, functional test
scenarios, conformance test scenarios, performance test scenarios, etc. The test scenarios will/can be
later transformed into test cases (refer to WP.7).
The scenarios must be tagged and associated with the relevant requirement/function in order to allow
cross-reference checking and impact analysis in case of changes.
WP.6.7
IT Implementation and Migration
This Work Package covers the required activities to produce or maintain specifications required to
support the IT implementation of a given IT system/application and possible migration activities.
The following are some examples (non-exhaustive) of such specifications.
Scope Document
The Scope Document defines the functional and technical framework of the concerned system or
Page 48 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
application or phase of this system or application: it defines which functions and messages are either
mandatory or optional to implement, for all involved parties, along with any restriction. Moreover, it
details the request to the Commission to develop the common components/services.
Migration Strategy Document
The Migration Strategy document defines the strategy, approach and related migration scenarios and
the planning linked to the required migration from one system situation to a future one. It covers all
involved components and/or data for all involved parties, along with any restriction.
One of the primary goals to consider during a migration is to minimize the impact on the involved
stakeholders.
Transition / Deployment Plan
The purpose of a Transition (PM2 terminology) / Deployment Plan is to specify and plan the
deployment of a given IT system/application or a specific phase of it.
It specifies into the required level of detail all activities to be performed by a given role within a given
roadmap/planning. It covers internal DG TAXUD milestones, milestones assigned to contractors and
possibly international milestones5 that need to be met.
WP.6.8
Technical System Specifications development and maintenance for Trans-European Systems
For each of the Trans-European Systems, the contractor must create, take over, maintain, improve,
service (as per chapter 3 below) the following key deliverables, each to be considered as a
Configuration Item for the Service Management. Refer to section 5.5.2 of the Tender Specifications Part B (Terms of Reference) for further info on these deliverables.
All the deliverables specified below (with few exceptions: the low-level specifications or
automatically generated ones) are created, maintained and improved using the collaborative iterative
agile method defined in the Tender Specifications - Part B (Terms of Reference) section 5.5.1. Refer
also to section 5.5.4 of the Terms of Reference for the corporate tools for Trans-European Systems
referenced.
The governance deliverables:
Business Cases, Feasibility Studies, Vision Documents to support the inception of the projects in the
TAXUD and EU Customs governance.
The TES architecture deliverables:
AES-P1/NCTS-P5 Architecture overview document provides an overview of the TES architecture to
meet the needs of various stakeholders in the design, deployment and operation of the TES and their
national and central components.
The Technical System Specifications:
DDNA is the KEY specifications package for TES. It specifies the protocol in all its details:




5
The scope of the TES;
The TES scenarios, the Time Sequence Diagrams (TSD) and State Transition Diagrams
(STD);
The Common Domain Protocol Policy2 defines the Common Data Structure for all
Common/National/External Domain IEs, all Rules, Conditions, TRTs, BRTs, Guidelines,
Sequence Rules, Code Lists and their orchestration;
The External Domain messages;
The dates agreed in common with MS or CC concerning the start of operations of a specific system
phase
Page 49 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED

The mapping between the “Legacy” and “To Be” states and states transition, supported by a
comprehensive gap analysis of the “Legacy” & “To Be” processes.
The DDNA is maintained with the CSE tool, is delivered as a document and as its CSE DB, in parallel
of the DDNA.
The transition deliverables:
The Transition document defines the transition policy of a TES from its “Legacy” state to its “To Be”
state as to ensure a seamless transition for the traders and the National Administrations with minimal
risk on the Business continuity, leaving significant leeway to the National Administrations to define
their transition Policy as they so see fit :





Sequencing of the time windows through which each NA has to pass to fare at minimal risk
through the transition, as to minimize the risk on business continuity;
Migration of movements across the transition;
The collection of the national transition strategies and planning;
The high-level specifications for the National Systems to go through the transition;
The Coordination Programme, and in particular the reporting of key KPIs using the Planned
Value/Earned Value method to track the rate of progress in deploying the TES.
The ieCA use Case: defining by example the protocol between a National System and the central ieCA
conversion service during the transition, illustrating with TSDs the transition Use Cases that the
National Administrations will face according their national transition policy;
The “Legacy” - “To Be” conversion deliverables:



DMP (Data Mapping Package, Data & State Mapping) provide the data mapping between the
“Legacy” and “To Be” data structure, including not only data structure (DG/DI, format,
optionality, cardinality) but as well the code list, rules and conditions;
The CT (Conversion Technical Specification) will provide the XSLT for the conversion of the
Common Domain messages between the “Legacy” and transition “To Be” data structure; it
will be the main specifications for ieCA as well as for the National Convertors for those NA
opting for their own implementation;
The CRP (Conversion Reference Package) provides the configuration files for the ieCA
conversion service from the DDNA CSE DB.
The conformance Test deliverables
The ACS (Acceptance and Certification Specification) & CTP (Conformance Test Protocol) and other
ancillary documents will define the Conformance Testing for testing the Technical System
Specifications compliance of NA “To Be” systems with the Common Data Structure. They will cover
from strategy of the Conformance Test to the specification of its test scenarios.



The ACS contain the Conformance Test Policy and the list of all test Scenarios, Test Cases
and Data Sets;
The CTP defined the “test scripts” and is produced using the SpecMgr. The CTP is delivered
as a document and as an hypertext in the form of the CTPviewer, generated by the SpecMgr;
The TRP (Test Reference Package) is compiled from the CTP by the SpecMgr. It is the
configuration file for the CTA, the Conformance Test application to be used by the NA during
their Conformance Test.
The Code lists values and their mapping
2.2.7
WP.7 IT Build, integrate and test
WP.7 IT Build, integrate and test
This Work Package covers all activities to produce and to maintain all relevant software, Test Design
Specifications and supporting artefacts. Furthermore, it covers all relevant integration and testing
Page 50 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
activities.
The contractor will provide deliverables and services to build the applications/services in compliance
with the TEMPO methodology, currently being updated according to the Agile methodology described
in section 3.3 of the Tender Specifications - Part B (Terms of Reference). Furthermore it will have to
provide artefacts and services to support the testing lifecycle of the systems and applications.
The Work Package covers in general terms:




The development and testing of programmes or software components, including all corporate
tools e.g. CTA, Specs.Manager, CSE, ieCA,
The production of supporting artefacts (e.g. installation manuals, administration manuals,
update or creation of infrastructure requirement Operational Model, etc.),
The activities covering the testing lifecycle (e.g. production of Test Design Specifications,
development of automated tests, execute the tests),
The integration of the working software increments in the Sandbox environment, for testing,
iteration review and work item acceptance purposes.
The acceptance of the software consists of a formal FAT process and subsequent service transition
activities as described in TEMPO and the FQP.
It is considered of major importance that the software is made available for end-user for
testing/demonstration as soon as possible in the development lifecycle (no later than before start of any
integration-testing executed on the developer’s side). The Sandbox environment is the most adequate
environment for that purpose. Occasionally, DG TAXUD could request the use of the demonstration
environment should the Sandbox not be available (refer to section 8).
WP.6 and WP.7 apply to all new developments and functional/technical evolutions and apply by
default the Agile methodology described in section 3.3 of the Tender Specifications - Part B (Terms of
Reference). The methodology is based on the iterative and incremental production of a software
release, its (largely automated) test cases and related artefacts (e.g. user manuals), through tested,
working and documented software increments to be made available in the Sandbox environment and
on a documentation acceptance platform. Artefacts to be produced include automated test cases and
deployment automation in support of agility. Deployment tools currently envisaged include Urban
Code Deploy, docker containers.
All corrective activities to come to a successful roll-out into conformance/production are an integral
part of the ordered IT build, integrate and test activities and no subject to additional cost. All detected
IT build, integrate and test defects must be registered and traced in the agreed toolset (refer to section
8.5) which is used for the business and operations support. During the iterative process, by default,
bugs or defects of any kind, including technical debt and critical source code quality issues, detected
during an iteration must be fixed during that iteration or the next iteration, without significantly
impacting the release planning. If detected during the last iteration of the Agile Iteration Phase, they
must be fixed by the end of the Transition Sprint.
Possible Requests for Change which are applicable to the ordered IT build, integrate and test activities
have as well to be registered and traced in the agreed toolset which is used for the business and
operations support (refer to section 8.5).



All items produced under this Work Package must be placed under strict Configuration
Management (refer to WP.8.2) in order to support their iterative, incremental production and
their future maintenance. To this purpose the contractor must ensure that the CMDB, DML,
Infrastructure baseline and document repositories used in the context of the framework
contract are continuously kept up to date.
Corrective maintenance for IT build, integrate and test software and related artefacts
applicable during (2) years to IT systems and applications taken over from the incumbent
contractors and which are in conformance/production is triggered by incidents resulting in
defect recording and subsequent correction. This type of maintenance is performed by
activities under WP.8.1.4.2
Wherever beneficial, DG TAXUD intends to move away from document-based specifications
(including and especially Test Design Specifications) towards tool-based specifications.
Documentation increments (e.g. user manuals) delivered during the Agile iterative process
will by default be provided on a tool such as a collaborative platform, ideally the Application
Lifecycle Management platform (refer to section 8.5.1), rather than via documents, and their
Page 51 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
formal consolidation possibly into documents will be achieved during the Transition Sprint.
Refer to chapter 8 for tool requirements.
The document deliverables and software parts which have linguistic dependencies are produced and
maintained in EN.
All activities under WP.7 are by default subject to be covered by the FSP (IFP and SNAP) price
elements.
WP.7.1
IT Detailed Design
This Work Package is not of a mandatory nature and can be applied when the contractor deems this
necessary according to his internal working and development methods. Nevertheless, this must not
substitute the TEMPO methodology but be complementary by nature.
In general, these activities can be applied to provide more explicit information to the programmers.
There will be no specific budget allocated to these activities as they must be part of the activities
covered by the FSP (IFP and SNAP) price element.
Although DG TAXUD is not allocating specific budget for these activities the contractor must deliver
the related artefacts, if produced by the contractor, to DG TAXUD although there will not be an
official acceptance process linked to this.
WP.7.2
Develop and Document Programs or Software Components
This Work Package covers the programming of the different programming units, its documentation and
its integration into more coarse-grained programming units if required.
WP.7.3
Produce Supporting Manuals
This Work Package consists in producing material facilitating the use of the software from the
viewpoint of (without being exhaustive)



WP.7.4
The user: user guides and on-line help text facilities,
The developer,
Operations: administrator and operator guidelines, installation manual.
Test Design Specifications (TDS) – Test cases
The test scenarios produced under WP.6.6.2 must be implemented by means of test cases which can be
executed automatically or manually. This Work Package covers the production and the maintenance of
these test cases.
Test cases are grouped according to their scope (e.g. user interface, performance, etc.) and get their
own acronym under the TDS umbrella.
The test cases must be tagged and associated to the relevant test scenario in order to allow crossreference checking and impact analysis in case of changes.
Software development must include the development of automated tests, continuous integration and
continuous deployment of the working solution in the Sandbox environment and continuous quality
and security rule checks. Refer to Tender Specifications - Part B (Terms of Reference) section 3.3 on
Agile software development methodology.
WP.7.4.1
Produce the Test Design Specifications (TDS) – Test cases for acceptance testing
Depending on the system and application the contents of this part of the TDS can vary.
This part of the TDS must provide all the test cases to enable the test team to test the functional and
non-functional aspects of the application.
In addition to functional and non-functional testing for the given IT system/application in isolation,
also (automated) integration testing with other applications developed and maintained by SOFT-DEV,
as well as integration with the underlying infrastructure (CCN, CCN2ng, SPEED2ng, UUM&DS, …)
must be foreseen. The SOFT-DEV contractor is responsible for ensuring that all integration interdependencies are covered in its testing activities.
The TDS must include test cases which are demonstrating that the system/applications is functioning in
fully integrated environment (‘end-to-end’). The latter means that all external interfaces must be part
of the end-to-end testing together with a correct simulation of the connectivity which will be used in
Page 52 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
the production environment (e.g. getting or sending a message over CCN/CCN2ng to/from a given
Member State, test the user interface over a CCN/CCN2ng connection, verify access via UUMDS
/EULogin etc.).
All tests performed during acceptance testing can be repeated as part of the service transition activities
in environments preceding a deployment in the conformance and production environments.
Consequently, all TDS artefacts must be designed such that they can be executed in the service
transition environments of DG TAXUD.
Test tools which can automate the execution part of the TDS are part of the DG TAXUD testing
strategy.
WP.7.4.2
Produce the Test Design Specifications (TDS) – test cases for Conformance Testing
Depending on the system and application the contents of this part of the TDS can vary.
This part of the TDS must provide all the test cases to enable the Commission and the external
stakeholders (mainly the Member States) to test the compliance of the agreed interfaces in all aspects
(functional and non-functional).
Specific test tools and applications can be used which can automate (part of) the execution part of the
TDS.
For Trans-European systems, the conformance testing is fully automated.
WP.7.4.3
Produce the Acceptance Test Plan (ATP) for the Acceptance Testing
To produce the procedural manual to be used for testing (organisational aspects of the testing, test
scenario description, etc.).
The Acceptance Test Plan is the procedural manual to be used for testing; it details the specific
approach and scope per test phase. It focuses on the practical steps to be taken by all parties involved.
It describes the organisational aspects of the testing and includes a description of the test scenarios to
be executed during the FAT.
WP.7.4.4
Produce the Acceptance Test Plan (ATP) for the Qualification Testing (QT)
To produce the procedural manual to be used for testing (organisational aspects of the testing, test
scenario description, etc.).
The Acceptance Test Plan is the procedural manual to be used for testing; it details the specific
approach and scope per test phase. It focuses on the practical steps to be taken by all parties involved.
It describes the organisational aspects of the testing and includes a description of the test scenarios to
be executed during the Qualification.
Page 53 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.7.5
Execute Test Plans
To execute the test cases as defined in the relevant part of the TDS.
Testing must be automated at least for all repetitive tests by test tools and support the iteration review
and work item acceptance process. Automation should be done in the most optimal way which will
limit future maintenance costs. Log files generated by these test tools can then be included as annexes
to the test reports.
This work package covers also the production and maintenance of all test data and test scripts and the
analysis of the test results.
All exceptions and errors detected during the execution of the tests are to be registered in the agreed
toolset. This toolset will be the same as for the management of incidents, problems, changes and
releases (refer to WP.8 and chapter 8 infrastructure and tool requirements) or integrated with it. The
detected errors and issues are to be assessed by the development team followed by the plan of a new
internal release if required. Exceptions and errors detected during the iterative process must be fixed
during the iteration or the next one and certainly no later than before the start of FAT tests.
The outcome of the test must be reported in the test reports applicable to the test phase concerned.
The contractor is reminded that all tests will be re-executed until they meet the quality criteria defined
in the FQP to move to the next stage with all test results recorded.
During the tests performance tuning enhancements (e.g. parameterization and configuration aspects)
will be implemented to optimise the performance before starting the service transition activities.
WP.7.5.1
Unit Testing
This work package covers unit testing of the programmes or software components.
The contractor must keep a record of the unit testing. Coverage of the functionality should not be lower
than 80%. All units tests must be executed automatically and the execution records must be available
on-site and provided to the Commission within 3 working days upon request.
WP.7.5.2
Integration, User Interface and Web Service Testing
To give confidence that all functions and components work together and with other systems as
designed.
Automated integration, user interface, business rule and web service testing will support the
development of release and ease the iteration review and work item acceptance process. A significant
part of the test cases will be automated. As a minimum rule, the majority of critical requests, “Must
do” work items or high-priority requests, will be supported by automated tests.
Integration testing is the final step before FAT testing and should give confidence that all application
components work together as designed.
Integration testing can also occur during an iteration or its review meeting in support to the work item
acceptance process.
The contractor must keep a record of the integration testing. These records must be available on-site
and provided to the Commission within 3 working days upon request.
WP.7.5.3
Factory Acceptance Testing (FAT)
To ensure the quality of the deliverables.
This work package covers the activities to:
 Execute the required tests in fully integrated environment,
 Collect and process the test results,
 Produce the FAT report.
The contractor has to assure independence between the FAT team and the development team.
The Commission and/or a party nominated by the Commission will validate on-site the FAT execution.
The contractor must consider the correct result of the FAT as a pre-requisite for the delivery of the
software to the Commission.
Performance and stress tests must be always executed during the FAT and the outcome of the tests
must be included in the FAT report. The Commission could also request to perform the performance
Page 54 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
and stress tests on a different/specific environment.
It is the responsibility of the contractor to have all environments in place and fit for purpose of the
applicable tests to be executed. Refer to ICT infrastructure management under WP.8 for the relevant
services.
WP.7.5.4
Qualification Testing (QT)
To ensure quality before delivering a patch, hotfix or a service-pack to the Commission.
Qualification Testing is applied before delivering a patch or a service pack to the Commission. This
work package covers the activities to



WP.7.6
Execute the required tests,
Collect and process the test results,
Produce the Delivery Qualification Report (DQR).
Code quality monitoring and technical debt prevention
The work package covers the continuous monitoring of the quality of the source code and the technical
debt and the resulting quality gap remediation measures.
The process will be supported by the execution of measurement of code quality rules as defined by
industry standards and matching the programming languages in use. The quality indicators are related
to attributes such as reliability, security, efficiency, maintainability and size, are produced or made
available on the Application Lifecycle Management platform (refer to section 8.5.1) and will be
updated following the technical evolutions in terms of measurement and technical debt prevention
practices, which can occur with new programming languages, frameworks or paradigms.
The SOFT-DEV contractor will implement remediation measures, through code improvement or
refactoring, when a quality indicator exceeds an accepted threshold, defined by industry standards, by
European Commission guidelines or after assessment by an expert third-party, or when an increase of
technical debt is detected during the development process.
2.2.8
WP.8 Support Services
WP.8 Support Services
The Work Package covers all required support services.
They can be put into the following main categories:

All required services mainly linked to business/operations support and which are of a
continuous nature,
 All required services which are of a horizontal and continuous nature such as infrastructure
and tools management, configuration and release management,
 Specific support services which can be triggered by DG TAXUD when required,
 Services linked to the business perspective such as trainings, demonstrations, participation to
committee meetings, etc.
The totality of the services is oriented towards all the parties involved in the programme (among
which NAs and MSs, trader federations, economic operators, the contractors and the Commission
services).
Page 55 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.1
Business/operations support
This work package covers the services to be provided to the business users and operations. This
consists of:



Acting as 3rd level support for the IT systems/applications in conformance and production
(incidents and problems);
Change management for the IT systems/applications in conformance and production;
Repair defects identified for the IT systems/applications in conformance and production.
A Service Desk service is not to be delivered by the SOFT-DEV contractor. Refer to chapter 9 for
more details on the ITSM Service Desk.
WP.8.1.1
Incident Management
This work package consists of all required activities to support and use an effective incident
management.
The incident management process is triggered by the ITSM Service Desk and will handle the lifecycle
of incidents and more specifically the following categories: specifications and software incidents,
requests for information (RfI) and requests for service (RfS).
The activities to be undertaken by the SOFT-DEV contractor will mainly cover 3rd level support.
All incidents/requests linked to the business users/operations will be managed through the Synergia
SMT tool. The SOFT-DEV contractor will have access to this toolset to manage the incidents assigned
to him. User assignment, reporting and SQI calculation for incidents handled by the SOFT-DEV
contractor will be configured and provided by ITSM.
Requests from traders may be forwarded by National Administrations, who act as a 1st level support
for their traders, to Synergia.
The contractor must set up and/or maintain the incident management process

To facilitate discussions at team and overall SOFT-DEV level if required regarding the
incident tracking, the root cause analysis and incident resolution
 To create coherency with the configuration and release management processes in case of
specifications or software incidents. This must allow the contractor, the Commission and
other involved parties to create the link ‘incident’ - ‘problem’ – ‘configuration item’ –
‘change’ – ‘release in which the incident has been resolved’.
The contractor will deliver to the Commission on a daily, weekly, or monthly basis reports on incidents
management based on the input he has provided in the Synergia tools (refer to chapter 9 for more
details on the Synergia programme). Additionally, the Commission may request the contractor to
produce additional ad-hoc reports on specific systems and for a specific period. The contractor must
provide these reports on-line via the agreed toolset and in electronic format.
The provided service quality must comply with the contractual OLA (refer to section 7.3.1 for more
details on the OLA requirements).
WP.8.1.1.1
Specifications and Software Incidents
To handle specifications and software incidents.
Incidents which are related to specifications and/or software require root cause analysis. Dependent on
the criticality/priority and the business impact of the incident a workaround can/must be provided.
A blocking software incident for which the root cause defect has been identified requires the delivery
of an emergency fix (alias hotfix). Defects will be escalated into corrective changes handled via
WP.8.1.4.
WP.8.1.1.2
Requests for Information
To handle/answer the Requests for Information (RfI).
This work package covers support activities to handle/ answer the Requests for Information (RfI) in
the scope of this framework contract. The request is dispatched to the accurate activity owner and an
answer is provided annexing an Information Request Form. The Requests for Information can contain
the following type of requests (list indicative and not exhaustive): general information requests, ‘how
to’ requests, requests on a given status of a given object, request to clarify a system/application
function, request to clarify a technical mechanism, request to provide an opinion on a given situation,
Page 56 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
etc.
WP.8.1.1.3
Requests for Service
To handle/answer the Requests for Service (RfS).
This work package covers the handling of the Requests for Service (RfS) in the scope of this
framework contract. The request is dispatched to the accurate activity owner.
A Request for Service can refer to any service which is part of the SOFT-DEV service catalogue.
Please note that this is mainly an administrative activity and does not link to the real execution of the
requested service.
WP.8.1.2
Problem Management
This work package consists of all required activities to support and use an effective problem
management.
A problem can be assigned to the SOFT-DEV contractor as the result of


An incident for which the root cause has not been determined or
Any other activity such as preventive maintenance.
It is to be understood that the number of problems are not that many in number but most of the time
critical for the correct functioning of a given IT system or application in production or conformance.
Problems such as performance issues, wrong results of complex functions, errors in data extraction to
Member State systems, etc. can be given as possible examples.
The responsivess of the contractor is important, especially for services provided 24 x 7 involving
traders.
Problem management performed by the SOFT-DEV contractor can result in the creation of one or
more defects once the root cause(s) are known. Upon request by DG TAXUD, defects will be escalated
into corrective changes handled via WP.8.1.4.
The contractor must set up and/or maintain the problem management process

To facilitate discussions at team and overall SOFT-DEV level if required regarding the
problem tracking, the root cause analysis and problem resolution
 To create coherency with the configuration and release management processes. This must
allow the contractor, the Commission and other involved parties to create the link ‘incident’ ‘problem’ – ‘configuration item’ – ‘change’ – ‘release in which the problem has been
resolved’.
The problem management process is triggered by the ITSM Service Desk and will handle the lifecycle
of problems.
The activities to be undertaken by the SOFT-DEV contractor will mainly cover 3rd level support.
All problems linked to the business users/operations will be managed through the Synergia SMT tool.
The SOFT-DEV contractor will have access to this toolset to manage the problems assigned to him.
User assignment, reporting and KPI calculation for problems handled by the SOFT-DEV contractor
will be configured and provided by ITSM.
The contractor will deliver to the Commission on a daily, weekly, or monthly basis reports on
problems management. Additionally, the Commission may request the contractor to produce additional
ad-hoc reports on specific systems and for a specific period. The contractor must provide these reports
on-line via the agreed toolset and in electronic format.
The provided service quality must comply with the contractual OLA (refer to section 7.3.1 for more
details on the OLA requirements).
WP.8.1.3
Change Management
This work package consists of activities to support a change management process and participate in
Change Advisory Board (CAB) meetings.
The IT systems and applications are subject to corrective, functional and/or technical changes. This
Work Package consists of activities to support a change management process.
Page 57 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.1.3.1
Change Management Process
This work package consists of all required activities to support and use an effective change
management.
The contractor must use the change management process with the following objectives:
 To manage efficiently, promptly and in a structured way the changes by registering the
request, drafting the impact using the TEMPO Impact Analysis Report template, and
participating to its review cycle.
 To define the formal and documented change management procedures and the related
approval levels necessary to manage, document and authorize changes according to best
practices. It is highly recommended to maintain synchronisation with Synergia.
 To perform the impact assessment and cost estimates (which are not binding to the contractor)
linked to changes of CI’s managed under this framework contract. This activity must cover all
aspects e.g. documentation, specification, software components, hardware, COTS, etc.
 To record the change (proposed or implemented) and maintain coherency with the
configuration and release management processes. This must allow the contractor, the
Commission and other involved parties to create the link ‘change request’ – ‘configuration
item’ – ‘release in which the change request is implemented’.
 To be able to produce for each and every configuration item the list of recorded change
requests with their status and related (expected) release.
All Requests For Change related information (incl. impact assessments and reports) must be made
available or produced from the Application Lifecycle Management platform (refer to section 8.5.1)
and accessible via the agreed toolset to all stakeholders involved.
The provided service quality must comply with the contractual OLA (refer to section 7.3.1 for more
details on the OLA requirements).
WP.8.1.3.2
Change Advisory Board (CAB) Meetings
The contractor will be asked to participate to CAB meetings. In the context of its participation, the
contractor has to produce/document the Requests for Changes (RfC) subject to discussion in the CAB,
provide its position with regard to change/impact, and record the CAB decisions on the concerned
RfCs.
The CAB meetings can be organised at the following levels:
 DG TAXUD business unit/system owner level. This level is always applicable and can be the
only required level. The latter applies if there is no agreement required from other
stakeholders. To prepare this CAB, the SOFT-DEV contractor could be invited to participate
to meetings in order to clarify some impact analysis;

National Administration level. Dependent on the governance in place, the relevant committee
is to be considered as the CAB for the Requests for Change having an impact on the National
Administrations.
In general terms, the participants of these meetings are the different stakeholders for one or a group of
configurations items.
These meetings can be organised on an ad-hoc basis or on a more regular, periodic basis.
WP.8.1.4
Repair defects
This WP covers the workload to repair IT system or application failures or anything that might cause
the application not to function as designed. The contractor is responsible to perform all relevant IT
activities associated with this repair.
Corrective maintenance is triggered by incidents resulting in problem recording and subsequent change
request(s). The incident can be initiated e.g. by:
 The service desk (managed by the IT Service Management contract) or the Central Project
Team;
 The end users, either Commission and/or National Administrations and/or traders;
 Testing activity performed by any of the contractors leading to the detection of a defect for an
application in production.
 The Quality of Service to be maintained will be specified in the contractual OLA (refer to
section 7.3.1 for more details on the OLA requirements).
Page 58 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
Only the taken-over artefacts (specifications, software releases, etc.) are subject to corrective
maintenance under this work package during the first two (2) years following the completion of the
take-over. In other words, all artefacts and updates (specs, s/w, etc) produced by the SOFT-DEV
contractor have to be corrected free-of-charge by the SOFT-DEV contractor over the course of the
Framework Contract.
The urgency of repair(s) is determined according to the contractual OLA (refer to section 7.3.1
for more details on the OLA requirements). All defects which are not to be repaired urgently by
delivering emergency fixes will be corrected and delivered according to an agreed planning with DG
TAXUD. Corrective maintenance deliveries are justified if either urgent problems are discovered, or if
a number of problems have been accumulated. Corrective releases can be combined with evolutive
releases or can be requested to be delivered separately at the discretion of DG TAXUD,
WP.8.1.4.1
Repair defects of the IT Specifications
The corrective maintenance covers the correction and resolution of the recorded errors of all
specifications.
The contractor has an end-to-end responsibility for dependant deliverables. Defects in IT
specificatons may have a cascade effect on other deliverables, e.g. documentation, test artefacts,
software.
WP.8.1.4.2
Repair defects of the Build and Test Software and Documents
This Work Package covers the corrective maintenance activities of the build and test software and
documents.
WP.8.1.5
Repair defects due to upgrade of Commercial off-the-shelf (COTS)
This work package shall be used only if the upgrade of the COTS has been done by the ITSM
contractor and that issues require corrective changes in the source code, configuration or any other
corrective change in the SOFT-DEV contractor’s deliverables.
This work package shall not be used to correct defects as a result of the SOFT-DEV contractor
undergoing work under WP.8.9 Upgrade of COTS.
This work package shall imply the correction of one defect in one CI in all occurrences of that CI.
The SOFT-DEV contractor shall deliver to the Commission the necessary corrective changes within
10 working days.
By COTS it shall be understood any commercial off-the-shelf product such as operating systems e.g.
RedHat, database systems e.g. Oragle, middleware systems, application servers e.g. WebLogic,
container systems e.g. Dockers, etc.
WP.8.2
Configuration Management
To set up a configuration management process that maintains and plans evolutions of the
configuration baseline.
The contractor must set up and/or maintain a configuration management process for all required
artefacts with the following objectives:
 To support the maintenance of the Configuration Management System (Baseline and CMDB)
managed by ITSM in order to provide accurate information on assets such as configuration
items, components, and their documentation to control their evolution, protect their integrity,
perform and/or assist audits and therefore minimize issues caused by improper configuration.
 In other words, it means supporting all Service Management processes,
 To create coherency with the incident, problem, change and release processes
 To update the CMDB and the Definitive Media Library (DML) according to the change of the
configuration items (CIs)
 To be able to look-up the CMDB for a specific CI; audit changes and provide inventory lists
and reports on the status of CIs and the status of planned changes.
Page 59 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
The CMDB must reuse features, link with or integrate the tools chosen as Application Lifecycle
Management platform (refer to section 8.5.1) supporting the software release management process and
the delivery of the related project artefacts.
The contractor must setup a Definitive Media Library (DML) containing all definitive and authorised
versions of all software components and related specifications/documentation created under this
Framework Contract is securely stored. Access to this information to the stakeholders involved must
be managed via the agreed toolset. The content is to be provided by the contractor and approved by
DG TAXUD before dissemination. Please refer to chapter 8 for more information on infrastructure and
tools.
If applicable, all acquired infrastructure and tools must also be maintained in the CMDB under
this work package. This also covers the maintenance contracts and the scheduled procurements.
WP.8.3
Release Management and software service transition
To apply the release management process.
The contractor must apply the release management process with the following objectives:
 To ensure that every requested change is managed during the release and deployment
activities. That means that the deployment packages and their components are tracked and
followed to from request to installation.
 To create a coherency with the incident, problem, configuration and change management
process.
 To deliver high-quality software releases which are updated in the CMDB and stored in the
Definitive Media Library which is available via the agreed toolset, maintaining therefore the
integrity of release package according the Configuration Management System.
 To maintain clear and comprehensive deployment plans grouping changes in releases as much
as possible to improve efficiency and stability of the environment.
 To ensure compatibility of assets included in given release packages.
 To record and manage risks, deviations, issues on new/changed services and take action
 To ensure knowledge transfer is properly performed on delivery by the development and
testing teams to the ITSM contractors.
 The term ‘release’ in this work package covers release terminology such as ‘release’, ‘full
release’, ‘patch’, ‘hotfix’.
WP.8.3.1
Delivery of software
To assemble and package a software release.
This work package covers the activities to be undertaken to



Assemble a software release in order to be able to deploy and test it (e.g. testing or in
production environment),
Package the software release along with its related documentation necessary for delivery,
deployments and test,
Preparation of its automated integration and deployment.
Each release must also contain its related release note describing all problems fixed, changes and
enhancements, known defects covered in this new release or pointing to the relevant parts of the
service management tools where the relevant information is stored and accessible by the operational
staff.
DG TAXUD is striving towards a maximum level of automation in the domain of software service
transition from development into production. Automated testing and automated deployment artefacts
that must be provided, maintained and serviced. Chapter 9 on the Synergia programme is providing
more information on the subject.
To this purpose the contractor must ensure that the CMDB, DML, Infrastructure baseline and
document repositories used in the context of the framework contract are continuously kept up to date.
Page 60 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.3.2
Support to service transition services
To guarantee a quick and successful transition.
This work package covers all support activities to be provided by the SOFT-DEV contractor to the
ITSM contractors during all activities performed by the latter during the service transition period. All
encountered issues must be registered, if not yet done by the ITSM contractors, using the agreed
toolset to manage the IT system/application support services. The support activities can vary from
performing the installation in a Site Acceptance Test environment and providing the proof that the
application is functioning correctly (this can be due to major issues detected by the ITSM contractor
during the initial installation or due to a repetition of issues observed for subsequent releases) to
‘standard’ (such as clarifications, provide additional information, provide advice, etc.) support
activities.
This transition process includes the deployment of the new release into the various test and
conformance/production environments managed by the ITSM contractor. Especially the installation
and tests in the phase of Site Acceptance tests are to be fully supported by the SOFT-DEV contractor
so that the planned test and deployment activities do not suffer from delays and lack of quality of the
delivered software and related procedures/documents.
The contractor will provide its expertise to support the installation, deployment, configuration in the
production environment of its apps or entry in operation of the National Administrations. It will
continue to do so during the after-care period for its apps Configuration Items deployed in production.
The contractor will deliver a final report Deployment to production Report. This report will be
provided at the end of the deployment in the Production environment. It will include any findings and
issues identified during this process and the actions taken for their resolution from the application side.
The SOFT-DEV contractor must participate to any relevant meeting organised by the ITSM
contractor(s) on the subject such as Change Advisory Board meetings to agree on new production
parameters, etc. These CAB meetings are typically organised on a weekly basis.
WP.8.3.3
Knowledge transfer between the SOFT-DEV and the ITSM contractors
This work package covers all activities to be performed by the SOFT-DEV contractor in order to
transfer all the required knowledge to the ITSM contractors such that the latter can perform


The service transition into conformance/production without explicit support from the SOFTDEV contractor. This implies (list indicative and not exhaustive) a full knowledge of
o Required changes at infrastructure level;
o The functional scope of the release and/or the defects that have been repaired;
o The installation procedure(s) of the various application software and testing
components;
Their activities effectively, especially these at 1st and 2nd level support.
The above is having its largest scope when a complete new system/application has to be deployed. The
knowledge transfer activities must be a mix of face-to-face clarifications, shadowing the SOFT-DEV
activities by the ITSM contractors, using the artefacts build by the SOFT-DEV contractor knowledge
management process, etc.
WP.8.4
ICT Infrastructure and Tools Management
This work package concerns the activities related to the management, operation and maintenance of
the ICT Infrastructure and tools to be used by the SOFT-DEV contractor in the Sandbox and FAT
environments. It is expected that all required infrastructure will be procured by DG TAXUD and
housed by DG TAXUD, e.g. in the DG TAXUD data centre. Evolution to cloud-based infrastructure is
envisaged.
It is the intention of TAXUD to provide the housing of the development environment in the context of
the SOFT-DEV contract. This may not be possible from the start of the contract therefore the
possibility must exist for the development environment to be housed at the SOFT-DEV contractor’s
own environments as described in section 8.3. Any development infrastructure installed at the
contractor premises is under the responsibility of the supplier and part of his standard infrastructure.
Page 61 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.4.1
Set up, Install, Operate and Maintain the IT Infrastructure and Tools provided by DG TAXUD
Infrastructure and its housing in the Sandbox and FAT environments will be provided by DG TAXUD
(see chapter 8). The initial operating system and backup agent will be installed. The SOFT-DEV
contractor will be responsible for the automated installation and maintenance of all other COTS and all
system management tasks in line with DG TAXUD technology roadmap, including:









WP.8.4.1.1
Maintaining and upgrading (when needed) the OS;
Installing and maintaining all COTS (Weblogic, Oracle, service management tools, etc.);
User and rights management;
Backup/restore follow up (the backup infrastructure being provided by DG TAXUD);
All non-hardware monitoring and alerting activities;
CCN/CCN2 communications configuration and maintenance;
Some aspects of the integration with other systems managed outside SOFT-DEV contract
(e.g. UUMDS, CCN2 etc.) will be resolved in cooperation with DG TAXUD.
Capacity management (see 8.4.1.1);
Compliance with, and execution of, all necessary processes (ensuring alignment with DG
TAXUD processes and TEMPO) to ensure the correct management of all software
components in terms of security, capacity, continuity and the related management of events,
incidents, problems, releases and deployments.
Support to configuration of CTA, ieCA, SpecMgr, CS/MIS2:
The contractor will update the configuration files for the various TES applications under its
scope as per the applicable management plans, control their quality and, depending the
arrangements at the time, either upload them in the applications in production or provide
support to other contractors to do so. The contractor must be ready to respond swiftly to any
incident putting at risk the conformance test and business continuity.
ICT Infrastructure and Tools Capacity Management
The infrastructure and tools configuration baseline is a resource that provides visibility concerning the
infrastructure needed for the development and test environment, in a line of sight of minimum 24
months. This baseline needs to be produced and maintained in close relationship with the evolution of
the various types of architecture in place (e.g. application architecture, service architecture,
technological architecture).
It will contain:


The requirements in terms of software, hardware and COTS needs,
A strategic plan, pointing at planned needs (and their evolution) for the project in terms of IT
infrastructure,
 The commercial planning of COTS releases, and their planned support or end of support,
 Phase-out of older version of COTS to be replaced by new ones, with as little disruptive effect
on operation as possible,
 The recommendations of the Directorate General for Informatics of the Commission
regarding the COTS and their support,
 The impact of the above on the existing IT systems/applications and associated planning of
actions.
This baseline will be maintained and kept up to date. The procedure of maintenance of the central
applications infrastructure baseline is to be specified in the FQP.
WP.8.4.1.2
Provision of the development environment
The SOFT-DEV contractor will be expected to provide, set up and maintain the development
environment until such time as TAXUD provides the housing of the development environment. See
section 8.1.1 for the description of the development environment.
WP.8.4.2
Set up, install, operate and maintain the FAT and Sandbox environments provided by DG TAXUD
The SOFT-DEV contractor will be expected to set up the necessary environments in order to test the
application releases, make demonstrations and support the iteration review and work item acceptance
process. This work package covers the activities required for the creation and maintenance of each new
environment. Installation procedures must be automated. For example, this could include the
Page 62 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
following:







Assigning a database instance/schema including parameterisation/fine tuning;
Setting-up an application server;
Configuring connectivity parameters (CCN / CCN2, UUM&DS, queues, other connectors);
Configuring remote access for users;
Configuring any other needed components (e.g. service bus, BPMN engine);
Configuring any other services/parameters to ensure the correct operation of the environment
(e.g. DNS, LDAP, proxy, load balancer, replication/high availability technologies such as
Oracle RAC);
Decommissioning the environment and releasing all associated resources;
The SOFT-DEV contractor is expected to manage the creation of environments in such a way as to
ensure flexibility and scalability, paying particular consideration to the available capacity and load of
the infrastructure, i.e. it is assumed that the provision of a permanent environment per application is
neither necessary nor optimal.
WP.8.4.3
Hardware and COTS acquisitions required to support SOFT-DEV services
The purpose of this work package is to bring the following benefits to DG TAXUD:





Simple contract administration and management, through a single source channel for
purchases including licence acquisitions, maintenance and related services;
An efficient way to acquire IT related items via a reseller’s product list (catalogue);
An acquisition channel that permits the choice/purchase of “best-of-breed” IT related items in
a highly dynamic IT market;
Comprehensive licence management services covering the complete software lifecycle
(quotation, ordering and order tracking, delivery, licence inventory, licence compliance,
reporting);
Comprehensive maintenance management services for both hardware and software.
It covers the following supplies and services:






The supply (licence quotation, ordering and delivery) of computer hardware and software
products with associated maintenance, consisting of periodic maintenance, corrective
maintenance upgrades and updates to new versions and releases. This also includes the supply
of associated maintenance for hardware/software artefacts already in the inventory. Finally,
the supply also includes provision of complementary services, such as urgent delivery
services;
If needed, the takeover of the on-going maintenance and support agreements for all
hardware/software products under maintenance via the previous software acquisition
channels, to ensure transparency and continuity of service;
The integration of any existing specific volume licence agreements into the Framework
Contract;
The provision of informatics services which should cover any required support for the
acquired hardware or COTS, for example, liaising with the suppliers to resolve issues;
The maintenance of a comprehensive inventory of all hardware and COTS acquired via this
channel. This should be in the form of an online service enabling secure access to catalogue(s)
and licence pricing information (via an online product catalogue), order tracking information
(via an order tracking tool), licence inventory information, and provision of regular
consumption follow-up reports, as well as other types of reports, linked to Service Level
Agreement (SLA) requirements;
It must be possible to trace any order back to its originating entity. It is up to DG TAXUD to
decide which of these services will effectively be used in the course of the contract, and to
which extent.
In exceptional cases where the contractor cannot procure on behalf of the Commission (DG TAXUD
in particular) a specific S/W product such as a licence, it has to be able to acquire it on its name and
Page 63 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
deliver the product-related services to DG TAXUD for a specified time-period (annually for instance).
In these exceptional cases, the contractor has to mention in his offer for the Request for Action, the
service(s) type, the time-period for which the service(s) is(are) to be rendered (i.e. annually) as well as
the pertinent cost per month/year. The up-lift percentage is not applicable in this case. The ordering of
this service will be made through the Offer-RFA mechanism out of the budget provisionally reserved
in the Specific Contract. Service provision of that type will be reported in the pertinent MPR. The RFA
will be formally and on its totality accepted via the MPR soon after the service provision is concluded.
Invoicing of the services to DG TAXUD will be made on a quarterly basis and may be partial or at the
end of the service provision.
Please refer to section 5.2.15.1 for a description of the price element ‘Uplift on COTS, HW,
Maintenance, Decommissioning’ that applies to this service.
Please note that the SOFT-DEV acquisition channel is only an option to procure the required
HW/SW. Although DIGIT is the default procurement channel, DG TAXUD reserves the right to buy
them from alternative sources.
WP.8.5
Specific support services
These services are to be delivered when triggered by DG TAXUD and will be expressed as resource
quantities to be used. The contractor will produce a report for each and every support activity.
WP.8.5.1
Service Transition and operational support
This work package covers support activities explicitly triggered by DG TAXUD. These activities are
activated when (list indicative and not exhaustive)



The continuous services provided under WP.8.3 do not deliver the expected result in terms of
a successful transition;
The continuous services provided under WP.8.1.1 and WP.8.1.2 do not deliver the expected
result in terms of the correct resolution of an issue in the conformance or production
environment. This can be the case when the root cause of the incident or problem is not the
responsibility of the SOFT-DEV contractor but they are nevertheless requested to provide
support for the solution;
Explicit after care support is requested by DG TAXUD when important deployments took
place in conformance and/or in production.
The contractor will report on each and every support activity in the Monthly Progress Report (MPR)
including amongst other, a comparison between actual KPI with their targets.
The contractor must report daily or weekly to TAXUD on critical operation activities which expose
TAXUD to delay or reputational risks. The contractor must keep informed TAXUD on progress on all
its operational services activities on a weekly basis.
The support services can be performed on-site and/or off-site.
WP.8.5.1.1
BCP and Crisis response
The contractor is responsible to stay ready to reply to any BCP (Business Continuity Plan) and/or crisis
notification according the related management plans and KPIs. The contractor will:


6
Define procedures to respond to major incidents (= as per ITIL v3, high impact and high
urgency), which may arise e.g. in the content 24x7 services provided;
Participate to the ‘war rooms6’ with all the required stakeholders, including sharing sessions
War room is a space where key people get together to solve a difficult problem. War room has a goal of
solving a difficult or specific problem via clear communication and improved workflows.
Page 64 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED




with other contractors, in order to optimise the coordination. The contractor will provide its
best expertise to resolve the crisis;
Participate to the bi-annual Disaster Recovery (DR) tests in coordination with the ITSM
and/or other stakeholders during non-standard working days/hours;
Provide on an yearly basis the updated BC plan in reference with the systems delivered;
Resolve 24x7 incident in collaboration with other contractors. E.g. ICS2 and ieCA will
require 24x7 support, as incidents will tend to have high impact.
And other activities as per their BCP and crisis management plan.
DG TAXUD will conduct periodic BCP and crisis exercises as to verify the capacity of the contractor
to deliver according expectations and gather lessons to improve the arrangements. DG TAXUD
expects that the contractor will demonstrate its delivery capacity and performance against set KPIs and
its ability to organise and deliver its services in crisis situations.
WP.8.5.2
Conformance Testing support
This work package covers support activities for the conformance testing campaigns with National
Administrations or any other stakeholder connecting to the EU customs or taxation systems or
applications. These support activities are planned in advance, triggered by DG TAXUD and cover the
following activities (list indicative and not exhaustive):


Provide support to the ITSM contractors conducting the conformance test campaigns with the
relevant stakeholder;
Provide faster replies to incidents and problems compared to the service levels defined in the
FQP and contractual OLA (refer to section 7.3.1 for more details on the OLA requirements).
This can result in the delivery of emergency fixes or fast track releases for the software
components participating in the conformance tests falling under the responsibility of DG
TAXUD. The contractor is responsible to run a rapid change and release management during
the CT and ensure that its change and release capacity are fully operative according
expectation.
The contractor will provide its expertise of TES specifications and applications to support the smooth
execution of the pre-CT and CT by the National Administrations. The contractor must provide
assistance to the National Administrations to execute their tests, to diagnose them. The contractor must
address all incidents raised during the pre-CT and CT and resolve them so that the National
Administrations are not slowed down in progressing to their conformance tests. It is essential that the
National Administrations are not blocked by problems in the TES specifications and applications in the
scope of the contractor. The contractor is responsible to take all steps to prevent this fromoccuring and
if it does to resolve the incidents with the appropriate level of priority.
The Conformance Testing for TES requires the creation and maintenance of CT Policy, NA
certification, ATP, National deviations, automation of test scenarios
The support offer will be expressed by the contractor as resource quantities to be used. The contractor
will produce a report for each and every support activity.
The support services can be performed on-site and/or off-site.
WP.8.5.3
Support to the National Administrations
This work package covers support services for the activities of the National Administrations of the
Member States. However, the provision of the support services can also be extended to the EU
candidate countries, to the EFTA countries, to the EU neighbouring countries (e.g. Ukraine), and to the
3rd countries such as (but not limited to) Russia and China.
The scope of these support activities can be of variable nature (list indicative and not exhaustive):



Provide support to the set-up of customs business processes,
Provide support to the set-up of customs IT processes,
Provide specific expert expertise.
The support offer will be expressed by the contractor as resource quantities to be used. The contractor
will produce a report for each and every support activity.
Page 65 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
The support services can be performed on-site and/or off-site.
WP.8.5.4
Technical Review of the Deliverables of Other Contractors
The Commission can ask the contractor to contribute to the verification of the technical conformance 7
of the deliverables of the other contractors with the specifications. This encompasses the following
activities:



List and log of all comments related to a deliverable under review,
Attendance at meetings or conference calls with all reviewers and authors, for clarification of
the issues and author positions,
Warnings to the Commission in case of severe defect in the technical conformance of the
deliverable.
The review cycle will be performed as described in section 3.4.
The Commission reserves its right to decide which of the review comments will be implemented
amongst those submitted. The contractor has no right to limit its overall responsibility on the grounds
that the Commission would have implemented only a subset of the comments issued.
WP.8.5.5
Delivery and Management of Translations
The Commission can ask the contractor to manage and deliver translation from EN into any official
EU language and from FR into EN and/or DE and from DE into EN and/or FR. The source can be
plain text or more technical items such as screen labels, error messages, etc.
WP.8.5.6
Specific support on ARIS and/or other modelling tools
This work package covers support tasks on the use and customisation of tools used for architecture
work in addition and irrespective to the necessary support provided by the contractor on these tools
under other WPs.
The support is to be provided in the form of:

Consultancy or coaching to final users on the usage or management of the tool.
DG TAXUD makes extensive use of the ARIS tool for Business Process Management and architecture
purposes, however this WP relates specifically but not exclusively to the ARIS tool.
This also includes the corporate tools CTA, Specs.Manager, CSE, ieCA.
WP.8.5.7
Corporate tools for Trans-European systems maintained under the current contract
The contractor maintains and uses these tools to produce some of the TES specifications identified in
W.6.8, and to produce configuration files for some of the NA facing TES applications. The contractor
will be both the user and the provider of the applications, an ‘incestuous’ situation which is prone to
risk. The contractor has to take steps to ensure a strict segregation between these two roles and that all
service management is strictly enforced, as to avoid short cuts and quality defect.
These applications are in use for over a decade, being used currently for the AES-P1, NCTS-P5 and
EMCS TES. The application will be hosted in the TAXUD data centre as from 2021, while at the time
of writing they are operated in the incumbent contractors' premises.
7
To avoid any confusion on the activities covered by the expression “Quality Control”, the description
text uses the wording “technical conformance”, which means that the reviewer is asked to comment
on the quality of the deliverable at the level of the “technical conformance”, as opposed to the
“Quality Control” comments, which concentrate on problems of conformance with the Quality
Procedures or Quality Assurance systems put in place. The latter will be performed by the QA
contractor. In practice though, the comments concerning “technical conformance” and those
concerning “quality control” will be gathered in a single database of comments, for the sake of
author’s facility.
Page 66 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
See Tender Specifications - Part B (Terms of Reference) for more details on these applications.


CSE:
The CSE application is used to produce and maintained the DDNA, it is the starting point of
the automated chain of the TES specification. The CSE DB is a KEY deliverable for some of
the National Administrations. The application faces a peak of Change request at the time of
peak activity on the DDNA.
SpecMgr and CTPviewer:
The SpecMgr codifies the Test scenarios for the Conformance Test. It produces the CTP as a
document deliverable, the TRP as configuration file for the CTA and the CTPviewer, a
browsable hyper-document version of the CTP to ease the reading of the CTP by the National
Administrations.
The contractor must guarantee their implementation plan, capacity and readiness for current and future
DDNA delivery in a proactive manner.
WP.8.5.8
TES management plans
In the context of Trans-European Systems service management, a number of management plans are to
be delivered and maintained, such as to formalize agreements with NAs
WP.8.5.8.1
Service Management Plan OLA
The contractor must define, maintain, improve, support the Service Management Plan, alias
Operational Level Agreement with DG TAXUD (OLA), regrouping the policies, processes and KPI
for all the services that it will deliver for its TES Configuration Items. It refers to other policies and
plans that it is responsible to maintain to address their specific niches and avoid redundancies. The
contractor must define an overall Service Management Plan according the TAXUD Service Policy as
defined in ToC, SLA for TES and relevant sections and KPIs for Service of this Technical Annex.
WP.8.5.8.2
BCP management plan
The contractor must maintain its BCP management plan to contribute to the ITSM3Ops and TES BCP,
defining policies, processes, KPI, external interfaces. The plan must take into account periodic
exercise to verify the fitness of the policy, processes and plan. This plan MUST be compatible with
the ITSM3Ops and TES plan and serve it! It must include:



WP.8.5.8.3
A risk analysis that the Configuration Item in the scope of the contractor induce on the
business continuity of the ITSM3Ops and TES and prepare adequate responses in case these
risks would materialize;
The policy and plan to address any risk on the ITSM3Ops and TES business continuity which
would require the expertise of the contractor to be mitigated or addressed should they
materialize.
Responses to various scenarios of risks on the ITSM3Ops and TES business continuity, as
defined in the ITSM3Ops and TES BCP.
Crisis management plan for the TES crisis plan
The contractor must create/take over, maintain, improve, support a Crisis Management Plan for its
critical systems and services. This crisis management plan must be compatible with the TES crisis
plan and describe the internal policy, process, external interfaces and plans that the contractor intends
to apply for its continuous readiness to cope and address a crisis should It occurs. The plan must take
into account the periodic exercises to verify the fitness of the policy, processes and plans.
The plan must be updated with the outcome of simulated or real crisis events. It must address
questions such as:






Triggering of the crisis, criteria, who? Who is the crisis empowered manager?
Define who to call in the war room;
Run the war room;
How to close the crisis;
Define the communication arrangement with the involved stakeholders;
Define the OLA provision to include crisis support in every contract and SLA: availability,
expertise, decision empowerment, response time, priority on other tasks;
Page 67 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED


Activate immediate access to the operational environment to investigate (app and sys log…),
as well as to a shadow ops environment to test the solution before to be applied in production;
Any recovery operation is performed by ITSM3Ops with support of SOFT-DEV.
Of particular interest will be the 24x7 support of the critical applications, such as central ieCA
conversion service, until the end of its life or due to a change of its criticality level taken via a
TAXUD decision.
WP.8.6
The Business Perspective: Liaison with NAs, the Contractors and the Commission services
Considering the high number of parties involved, there is a continuous need for working group
meetings, trainings, workshops, demonstrations, missions, support activities, service meetings,
technical meetings, and review and translations activities.
The training material can be composed of all kind of items going from classical documents to multimedia facilities imbedded in an E-learning module.
WP.8.6.1
National Administrations Working Group Meetings and their Related Sub-groups
WP.8.6.1.1
Performance
Active technical contribution to the meetings in Brussels.
The contribution covers:


WP.8.6.1.2
Preparation of performance material.
Performance during the meeting: presentation, answer to questions from attendance.
Attendance
Attendance at the Working Group Meetings and their Sub groups.
WP.8.6.2
Training, Workshop, Demonstration
Considering the high number of parties involved, there is a continuous need for demonstration,
workshops and training sessions on the specifications, development and testing, products and services
that the Central Project Team delivers.
The training material can be composed of all kind of items going from classical documents to multimedia facilities imbedded in an E-learning module.
This work package does not cover the interactions and online meetings to be held on a regular basis
with various stakeholders to support the continuous analysis activities covered by WP.6.
WP.8.6.2.1
Performance
Active contribution to training/workshops/demonstration (preparation and performance) in Brussels, in
a National Administration or at the contractor’s premises, upon request from the Commission.
The contractor is requested to cover:





Preparation of training/workshop/demonstration material
Performance during the training/workshop/demonstration.
The preparation of a training/demonstration includes:
Content specification of the training/demonstration,
Ad-hoc material, software development, if needed.
The trainings/workshops/demonstrations will be held in English, French or German.
WP.8.6.2.2
Attendance
Attendance at training sessions, workshops, demonstrations in Brussels or in a National
Administration. In cases where a technical meeting called by a third-part entity and the presence of the
SOFT-DEV contractor is required, this meeting is considered as a workshop and fits in the scope of
this WP.
A short report or minutes will be produced.
WP.8.6.2.3
Hosting Facilities and Infrastructure
To cover infrastructure and associated operation needs (like material move, set up) for hosting
Page 68 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
demonstration, training and workshops, and providing facilities required. This includes, amongst
others, meeting rooms (up to 40 persons), training rooms, PCs (minimum one per two participants
when applicable), and beamer.
The hosting facilities must be located in Brussels and must be easily reachable by public transport.
It also includes the copies of training/workshop/demonstration material for the participants.
WP.8.6.2.4
Reporting
The contractor has to provide:
 Briefing with agenda
 Detailed minutes of the training/workshop/demonstration and mission reports
 Evaluation of the training/workshop/demonstration
WP.8.6.3
Missions
The Commission can invite the contractor to participate in official co-ordination missions to National
Administrations or to any 3rd party as required. The duration of the mission is limited to ‘days’ in
terms of elapsed time and covers the following activities (list indicative and not exhaustive):
 Stock-taking of a given situation in a National Administration on a given customs business or
IT subject;
 Underpinning activities for on-going feasibility studies, customs business or IT strategies, etc.
 Coordinate the national planning elements which have an impact on the overall EU planning.
It covers:



Preparation of agenda, briefing,
Preparation of mission material,
Performance during the mission.
The contractor will produce a mission report that the Commission will submit for the review and
approval of the visited party.
For visits to geographical Europe, a fixed price per day per person is defined in PE34. For exceptional
cases where a visit might be requested to a 3rd party outside geographical Europe, the actually incurred
prices for travel and subsistence will be reimbursed, subject to prior approval by TAXUD.
In the context of this WP, ‘Geographical Europe’ aims to cover at least the MS, UK, candidate
countries, EFTA countries, CTC countries, neighbouring European countries with whom some UCC
projects can materialise. Where applicable, oversees territories are excluded, i.e. exceptional visits to
oversees territories would fall under the 3rd party arrangement. The list of candidate countries and
candidate CTC countries may evolve, so we come to the following list:
Albania; Andorra; Armenia; Austria; Azerbaijan, European part; Belarus; Belgium; Bosnia and
Herzegovina; Bulgaria; Croatia; Cyprus; Czechia; Denmark, excluding Faroe Islands and Greenland;
Estonia; Finland; France, excluding the overseas departments; Georgia, European part; Germany;
Greece; Hungary; Iceland; Ireland; Italy; Kazakhstan, European part West of Ural River; Kosovo;
Latvia; Liechtenstein; Lithuania; Luxembourg; Malta; Moldova; Monaco; Montenegro; Netherlands,
excluding Caribbean Netherlands, Aruba, Curaçao and Sint Maarten; North Macedonia; Norway,
excluding Svalbard and Jan Mayen; Poland; Portugal; Romania; Russia, European part; San Marino;
Serbia; Slovakia; Slovenia; Spain, excluding the Canary Islands, Ceuta and Melilla; Sweden;
Switzerland; Turkey, European part ; Ukraine; United Kingdom, excluding British Overseas
Territories; Vatican City.
WP.8.7
Implement major IT transformations
It is impossible to predict in specific terms what the impact could be of major IT evolutions that could
be decided during the lifecycle of the SOFT-DEV framework contract. This work package will
support all required activities which need to be performed to support such a transformation.
This work package is not to be confused with the Continuous Service Improvement Process (CSIP,
WP.0.12) which is the underpinning process to improve the level of quality of the required services as
a continuous service.
Page 69 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.8
Support outside Working Hours
The ‘Working Hours’ scope is defined in section 12.2. This work package defines the services to be
provided by the contractor outside the working hours.
WP.8.8.1
Call availability outside Working Hours
DG TAXUD will determine the list of IT critical systems/applications which are subject to support 7
days per week and 24 hours per day on all calendar days.
This operational requirement implies that specific SOFT-DEV staff must be on call outside working
hours and which are able to assess a given operational situation such that they can take the appropriate
action. This action can result in mobilising other staff needed to resolve the operational issue(s) (see
WP.8.8.2).
This work package covers only the availability service of a given person for a given IT
system/application.
WP.8.8.2
Extended time coverage
As a result of WP.8.8.1 or at explicit request of the Commission, the contractor will provide ad hoc
services outside the SOFT-DEV working hours.
These services are to be performed according to an agreed scope and time schedule. The activities to
be performed can be of a variable nature: an on-site activity performance, producing an emergency fix,
etc.
On site presence can be as well at the contractor’s premises, DG TAXUD or any other party assigned
by DG TAXUD.
The contractor will have to produce a report for each and every “ad-hoc” extended time coverage
support activity.
Page 70 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
WORK PACKAGES, DELIVERABLES AND PLANNING REQUIRED
WP.8.9
COTS Upgrade
This activity ensures that the DG TAXUD applications in terms of software, hardware and COTS
needs are aligned to the evolution of the configuration baseline requirements as defined by the
Commission. This encompasses porting, migration, phasing out of software/COTS/hardware, to
guarantee that DG TAXUD applications are never in a situation of lack of support/end of support from
software/COTS/hardware vendors. A typical activity under this work package is the alignment of the
applications to a newer version of a COTS (same product/family range) for which the end of support
has been notified (eg. upgrade). These activities will have to be carefully planned in order to have the
minimum disruptive effect on operations. Alignment of the DG TAXUD applications which requires
migration, porting from one COTS family to another one, or from one hardware platform to a different
one, will be kept outside of this WP.
By COTS it shall be understood any commercial off the shelf product such as operating systems e.g.
RedHat, database systems e.g. Oragle, middleware systems, application servers e.g. WebLogic,
container systems e.g. Dockers.
All 8.9 sub-workpackages shall be carried out by the SOFT-DEV contractor in all FAT environemts
for the particular application and for one COTS that is being upgraded.
WP.8.9.1
This work package shall include the upgrade of the COTS from one major version to another major
version e.g. from Oracle 11 to Oracle 12. It shall also include all the necessary changes, including code
change, configuration changes or any other adaptation of the application to ensure the full
compatibility of one DG TAXUD application with the new version of the COTS.
WP.8.9.2
This work package shall include the upgrade of the COTS from one minor version to another minor
version within the same minor e.g. from Oracle 11.1 to Oracle 11.2. This work package shall include
all the necessary changes including code change, configuration changes or any other adaptation of the
application to ensure full compatibility of one application of DG TAXUD with the new version of the
COTS.
WP.8.9.3
This work package shall include the upgrade of the COTS from one minor version to another minor
version within the same minor e.g. from Oracle 11.1 to Oracle 11.2. This work package shall not
include any changes in the source code or the configuration of the application.
WP.8.9.4
This work package shall include the upgrade of the COTS at patch level thus within the same minor
version. This work package shall not include any changes in the source code or the configuration of the
application. In the rare cases that the COTS versioning does not distinguish properly between minor
and patch versions the upgrade shall be considered as one for a patch version, unless the SOFT-DEV
contractor can clearly demonstrate that the respective version is actually a minor and not a patch.
2.2.9
WP.10
WP.10 Other deliverables and services on request in the scope of the
Framework
Other deliverables and services in the scope of the Framework Contracts
This work package is intended to cover all unforeseen activities in the scope of the Framework
Contracts. The ordering method is On-Demand and the price may be based on any of the man-day
profile prices or deliverable/unit prices.
Page 71 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
3. Contract management and execution
Services are delivered through the implementation of the above-described work package activities. The
following sections provide further information about the various elements related to the service
deliverables. The services are qualified by their deliverables and planning if applicable,
request/order/delivery & acceptance mechanism and their Key Performance Indicators (KPI) and
Specific Quality Indicators (SQI).
DG TAXUD reserves the right to mutually agree with the SOFT-DEV contractor in the Specific
Contract or the Request for Action (and record in the DTM) a review cycle different from the one
originally agreed upon.
3.1
Types of order modes
There are two (2) types of Order Mode (alias budget provisions) that can apply to the various SOFTDEV Specific Contracts, namely the:

Fixed Price (FP) provision,

On-Demand (OD) provision.
3.1.1
Fixed Price (FP) provision
Activities under Fixed-Price provision may start as soon as the SC has been signed according to the
agreed planning. Normally, this budget provision concerns services that are very crucial for the overall
correct functioning of the IT services for which DG TAXUD is responsible for.
There are two (2) particular cases to commit FP budget defined in the SC as a provision, namely:
Case 1:
Continuous services (CS) which are actually price-unit related services targeting to
acquire a certain capacity from the contractor to provide the service of the day-to-day
activities whilst being able to level out peak activities. Please refer to section 5.2.12.1
for information on the price elements of “continuous services”. Certain activities
under CS are launched by the Commission using a trigger. However, triggers have no
financial impact since budget is already committed.
Case 2:
Continuous monthly services such as overall management, IT management & support,
etc.
The Commission determines the provision for FP budget provisions in the SC.
3.1.2
On-Demand Services (OD) provision
Activities under On-Demand provision may start soon after the SC has been signed and after the explicit
ordering/authorisation by DG TAXUD. This provision comprises activities/services/deliverables whose
required quantities and execution time is uncertain at the time of the signing of the Specific Contract and
for which a unit price is contractually fixed in the FWC. Furthermore, it comprises resource-based
and/or Function Points based IT assignments and H/W & S/W procurement services on behalf of DG
TAXUD and whose the cost is contractually fixed and agreed in an offer.
The Commission determines the provision for OD budget and the activities covered under it in the SC.
There are three (3) particular cases to commit OD budget defined in the SC as a provision, namely:
Case 1:
Budget is to be committed via the use of the RfE/Offer/RfA mechanism. The
RfE is always to be used prior to issuing an RfA for a specific assignment,
since the RFA sub-tasks have to be defined prior to their ordering. By
definition, an RfA under “OD” budget has always a financial impact.
Page 72 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
Normally, the RFA mechanism is issued for ordering effort-related services
(that is, services such as s/w development, maintenance, etc. quoted in Mandays or Function/SNAP Points) and for the ordering of H/W or S/W items
such as licences, etc. The RfE, when applicable, contains a Technical Annex
with the description of the requirements and it invites the contractor to
submit an offer. The contractor submits an offer that describes the technical
solution, the deliverables and the price (expressed in price elements (service
price units or profiles) available for the given Specific Contract).
Commission evaluates the offer and, if it is acceptable, it issues the Request
for Action (RfA). The RfA refers to the offer and confirms the order,
specifying the price, deliverables, quality indicators and payment/invoicing
terms and conditions (e.g. 20% advance payment following the RFA
signature, 40% following the delivery of artefacts and 40% following the
closure of the RfA). The services ordered via the RFA are accepted via a
final “End of Action report” or via multiple interim “End of Action reports”,
if more than one invoices/payments are foreseen in the RfA. Each final or
intermediary submitted report needs to be validated by the Commission. The
validation result will be electronically communicated to contractor via a
registered e-mail in order the last to be able to invoice.
Case 2:
Budget is to be committed for OD services and for Continuous Services, if
the last ordered under FP provision have been consumed. Please refer to
section 5.2.12.1 and 5.2.12.2 for information on the price elements of the
Continuous and On Demand services. Budget commitment is made via the
use of the RfA mechanism or via the electronic approval of the “Quantities
Release Request” submitted by the contractor. Either mechanism makes units
of services available for consumption/use by the contractor. For some of the
released servives, an explicit “trigger” is required by the Commission to start
the activity (for example: attendance at a given training activity, performance
of a mission, travelling). In general, the Commission may use triggers to
launch the start of an action whenever applicable. The consumed services
along with their related deliverables are reported and accepted via the MPR.
Triggers, where applicable,
have financial impact. The mechanism
concerning the release of quantities via the electronic approval of the
“Quantities Release Request” is described in section 2.2.2 of the document
“Ordering Process Guide” found in the Baseline.
Case 3:
The OD budget is to be committed via the use of the RfA mechanism or via
the electronic approval by DG TAXUD of the submitted offer/proposal for
short IT assignments quoted in man-days and not exceeding the 10K in
budget or the 10 w-days in duration per activity/service. In case 3 (this case),
there is no need for DG TAXUD to issue a Request for Estimation (RfE) like
in case 1 above. More specifically, the contractor in response to a need
expressed by DG TAXUD for something quick and urgent will submit a
short offer with the related effort expressed in Man-days per profile. In turn,
DG TAXUD, after a positive assessment of the offer, will issue either an RfA
for ordering the work or a registered e-mail for confirming the acceptance of
the offer. The detailed process concerning the acceptance of the offer via a
registered e-mail and not via an RfA is described in section 3 of the
document “Ordering Process Guide” which is provided with the Baseline.
The services and their related deliverables are accepted via the MPR. In cases
where the cost for resource-based services exceeds the 10K in budget or the
10 w-days in duration, the ordering has to be made through the
RfE/Offer/RFA mechanism described in Case 1.
Normally, continuous support services under the FP provision and/or OD services under the OD
provision constitute the integral part of the Horizontal Specific Contract. Normally, this contract is of a
Page 73 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
yearly duration and not necessarily shared among all directory B units). If necessary, its duration may be
extended for budgetary reasons, following a mutual agreement between the parties.
Once the provisions for resource-based and Function Points services have been made, they go to the OnDemand Services budget of a new Specific Contract; normally, each directory B unit will use its own
Specific Contract.
For the “Quantities Release Request” submitted by the SOFT-DEV contractor for the release of
quantities such as trainings, missions, incidents, etc., no RfE is needed.
For the procurement of H/W and/or S/W items such as licences, no RfE is needed. In addition, note
that he default procurement channel for DG TAXUD is DIGIT.
The SOFT-DEV contractor needs to continuously monitor the availability for consumption of the
continuous support and OD services. No unit consumption is allowed, when pertinent units are not
available for consumption and/or without the prior approval by the Commission.
3.2
Planning Mechanism
The planning information will relate:

For a service: to start, end or change of the service, as a service is considered to be
continuous by nature;

For a deliverable: to its submission for information, for review and/or for acceptance.
The planning of the services and activities will be agreed in the Specific Contract and or in the RfA, in
compliance with this technical annex, using the following mechanisms, in order of decreasing
precedence:

In the SC, with a planning schedule specified in reference to T0, the starting date of
the activity of the SC, and/or possibly to other internal/external dependencies. When
applicable, the planning specifies for a deliverable if the date is for submission for
review or for acceptance;

In an RfA within an SC;

In the FQP;

Mutual agreement (MA) between the Commission and the contractor during the
course of the SC, each planning agreement being recorded in the MPR of the month
when the agreement took place;

In a Trigger (operational way to indicate to the contractor to start an activity which has
already been ordered and for which the quantities to be consumed are well-defined
(trigger has no financial impact). The trigger may be sent to the contractor either by
paper mail or by a registered e-mail to the contractor);
No higher planning mechanism may be over-ruled by a lower one. However, a lower one may include
provisions not considered in the higher one, which do not contradict its text.
All the agreed planned dates, foreseen date, actual date of delivery are reported in the Monthly Progress
Report.
Page 74 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
3.3
Delivery mechanism
The delivery mechanism is applicable to all artefacts which are a potential outcome of an ordered
service. This is not applicable for the service as such as the service reporting is systematically made in
the Monthly Service Report to report the QoS metrics of the service.
3.4
Acceptance mechanism
3.4.1
Acceptance of deliverables
The acceptance procedures applicable to the deliverables and services are specified hereafter. The FQP
may specify further the acceptance process details of the deliverables, but in case of conflict between
these documents, the Specific Contract and this Technical Annex the following decreasing precedence
will prevail: SC, Technical Annex, FQP.
No formal acceptance applies for deliverables for which neither this Technical Annex nor the SC nor the
RfA defines an acceptance procedure.
The acceptance procedure describes the procedure for verification of the deliverable by the
Commission.
The formal acceptance of deliverables does not absolve the contractor from responsibility related
to hidden defects in the deliverables. The contractor remains responsible for the deliverables
being ‘fit for purpose’ and must ensure their corrective maintenance, should hidden defects
appear. This includes an end-to-end responsibility for dependant deliverables or several releases
of a given software.
All deliverables will be subject to a formal T1/T2/T3 review cycle (also referred to as SfR/SfA cycle):
T1 period:

The contractor Submits for Review (SfR) its deliverable to the Commission, and any
nominated party8, at the agreed date, starting T1;

The Commission reviews the SfR deliverable and returns its comments to the
contractor at the end of T1;

The Commission reserves its right to reject the review in case the deliverable SfR is
not fit for review, ending T1.

T2 starts with the reception by the contractor of the review comments from
Commission9;

The contractor submits his author positions for each of the comments submitted by the
Commission;

The contractor10 may call a review meeting to resolve outstanding review issues.
T2 period:
8
The Commission may use the support of the QA contractor for the management of the review cycles
of submitted deliverables.
9
The Commission may request other parties involved in the business threads (like the business
owners, the ITSM contractors, the QA contractor) to review deliverables submitted by the SOFTDEV contractor. The comments from the Commission will include the comments of these 3 rd parties.
Page 75 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION

The review meeting decisions are submitted by
o
The contractor in case of minor or medium size review;
o
The Commission (or any other 3rd party designated by it, such as the QA contractor) in case of
major size review.

The contractor Submits for Acceptance (SfA) his deliverable before the end of the T2
delay, closing temporarily the T2 period, the final closure of T2 being subject to the
approval of the deliverable (the time stamp of the delivery of the accepted version
constitutes the final closure of T2);

T3 starts with the reception of the SfA deliverable by the Commission;

The Commission, typically delegating this to the QA contractor, will then verify the
SfA deliverable and inform the contractor of any deviation of the SfA deliverable
from the author positions and meeting decisions, within a pre-agreed period T3;

In case of deviation, the T2 period is re-opened, up to the time that the contractor
submits the version of the deliverable that the Commission will accept.
T3 period:
The FQP defines some of those pre-agreed periods (review cycles), while the Specific Contracts and the
Requests for Action will define additional periods if required and will set the pre-agreed dates for
delivery.
Once accepted, all deliverables become the property of the Contracting Authority, which is then the only
party that can authorise their further use and distribution.
The FQP defines some of those pre-agreed periods (review cycles), while the Specific Contracts and the
Requests for Action will define additional periods if required and will set the pre-agreed dates for
delivery.
The Contracting Authority draws the attention of the contractor to the fact that:

The T1/T2/T3 review cycle is tightly related to the contractual planning. Indeed, a contractual
date qualified for acceptance implies that the T1/T2 part of the cycle must be completed for
the deliverable by that date, while a date qualified for review implies that the T1/T2/T3 cycle
for the deliverable starts at that date;

The T1/T2/T3 review cycle constitutes an integral part of the production of the deliverables.
In particular, the contractor shall not claim any additional costs to manage the T1/T2/T3
review cycle;
The prerequisites for a deliverable (software release, document, etc.) built in increments following the
Agile methodology to be submitted for review are the following:

10
Its underlying work items are marked as “done”, i.e. all criteria of their “Definitions of
Done” have been accepted by the Product Owner. The increments themselves are not
submitted to the above SfR/SfA cycle.
The contractor is responsible for ensuring that author positions meet with the agreement of the
Commission. The Commission may also call for a review meeting, or delegate this to the quality
contractor.
Page 76 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION

All bugs, issues, defects, critical source code quality issues, etc. detected during the
iteration and transition phases have been fixed.
Verification notification
When there are no further verification comments on the deliverable, the Contracting Authority sends
electronically a 'positive' deliverable verification notification to the contractor. This ends the review
cycle.
Rejection of a deliverable
A deliverable may be rejected:


At any point during its review (T1 period) if:
o
It is out of scope;
o
It is of low quality (including spelling or grammar errors);
o
An abnormally high number of comments are being produced;
At any point during its verification (T3 period) if:
o
The review comments have not been implemented;
o
The review comments have not been implemented in a correct or consistent manner
throughout the document;
o
Other changes have been made to the document without prior agreement by the
Contracting Authority and without being reported in the implementation information
of a relevant review comment in the review database.
The Contracting Authority reserves the right to decide whether the non-implementation or inconsistent
implementation of review comments or the other changes to the document are of major or minor
importance.
If a deliverable is rejected during its review (T1 period) or its verification (T3 period), the review
process is stopped and a new review cycle is defined.
If rejected during T1, this new review cycle will include a new analysis phase, a new SfR date, and a
new SfA date.
If rejected during T3, in most cases, this new review cycle will only include a new SfA date based on
Contracting Authority's judgement.
In any case (unless not officially agreed otherwise) and for the purposes of SQI/KPI calculation, the
initially planned SfR and SfA dates will remain the target dates against which SQI/KPIs are calculated,
where the following dates are taken into account to define the actual SfR and SfA dates:

For the calculation of SfR-related SQI/KPIs: the date of submission of the last SfR-version of the
deliverable that led eventually to an SfA.

For the calculation of SfA-related SQI/KPIs: the date of submission of the last SfA-version of the
deliverable that was eventually accepted by the Contracting Authority.
Please also refer to TEMPO
(https://webgate.ec.europa.eu/fpfis/wikis/display/TEMPO/Deliverable+acceptance+procedure)
more details on the acceptance of deliverables.
for
Deliverables, RfAs, Quantities & short IT assignments accepted via the Monthly Progress Report
(MPR)
The deliverables specified with an acceptance mechanism “to be accepted via the Monthly Progress
Report”, are formally accepted through the formal acceptance of the MPR in which they are proposed
for acceptance. Normally, these deliverables are the ones generated in the context of small IT
assignments ordered under Case 3 of section 3.1.2 above. Furthermore, RFAs issued to the contractor
Page 77 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
for releasing quantities and/or ordering small IT assignment under case 2 and case 3 of section 3.1.2 are
reported and accepted via the MPR. At end, services quantities which have neen releaed for
consumption via RfAs or via the “Quantities Release Request” mechanism are reported and accepted via
the MPR.
Deliverables accepted via the “End of Action Report”
After the end of the work ordered via RfE/Offer/RfA mechanism, the SOFT-DEV contractor provides to
the concerned operational unit/sector and Resource & Governance sector of Unit B4 (alias B4/R&G 11)
the “End of Action report” (please refer to BL for the “End of Action report” template) along with the
necessary supporting documentation (i.e. e-mails for proving delivery of deliverables sent for
acceptance, verification reports by QA, etc.). However, in cases where multiple payments are foreseen
in the RfA (i.e. payment 1 after delivery of X and payment 2 after the conclusion of the overall work),
the SOFT-DEV contractor has to provide additional interim “End of Action reports”, that is, one “End
of Action report” per payment.
Each submitted “End of Action report” is validated by the concerned operational unit/sector in DG
TAXUD. The validation result is finally communicated to the SOFT-DEV contractor via a registered email. Finally, DG TAXUD may request the assistance of the QA contractor for the validation of the
“End of Action report”.
3.4.2
Acceptance of services
All continuous and OD support services provided by the SOFT-DEV contractor will be accepted via the
Monthly Service Report (MSR) and in line with the Quality of Service (QoS) defined he contractual
OLA and the FQP, which itself may refer to other applicable SLAs/OLAs.
The MSR must report the actual QoS of all the provided services and justify any deviation from
target(s). The SQI/KPI is compiled from the target and actual QoS to quantify the deviation of reality
from target and is also recorded in the Monthly Service Report.
The correctness of the reported QoS and SQI/KPI is accepted by the acceptance of the Monthly Service
Report.
Note that it is the factual correctness (alias integrity) of the reported QoS and associated SQI/KPI which
are subject to acceptance via the MSR and not the service itself. The accepted QoS and SQIs/KPIs
become then the indisputable bases for computing the liquidated damages, where applicable.
More specifically, the actual number of service units consumed in the context of each approved
“Quantities Release Request” or RFA will be reported and accepted via the MPR. The same applies for
the acceptance of Man-days consumed via the simplified offer mechanism (case 3 in section 3.1.2
above).
3.4.3
Acceptance of consumed quantities
The actual number of services consumed under continuous support and/or OD services will be reported
and accepted via the MPR/MSR. The same applies for the acceptance of Man-days consumed via the
simplified offer mechanism (case 3 in section 3.1.2 above).
11
The Resource & Governance Sector in Unit B4 interacts with the contractor in activities related to
TEMPO methodology, knowledge management and in the context of contract and supply
management.
Page 78 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
3.4.4
Acceptance of Monthly Progress Report (MPR) and the Bileteral
Monthly Meeting (BMM) minutes
The Commission, after following the foreseen review cycle described in section 3.4.1, will formally
accept on a monthly basis and via an “Acceptance Letter” the bundle made of one or more Monthly
Progress Reports (MPR), with some of them to include in addition Monthly Service Reports (MSRs)
and the minutes of the Bilateral Monthly Meeting (BMM). Actually, for each Specific Contract (SC)
under the Framework Contract (FWC), there is one Monthly Progress Report (MPR) to be generated and
delivered to DG TAXUD.
The acceptance of the bundle will trigger the acceptance by default of the deliverables and services
presented for acceptance in the accepted MPR/MSR.
In case of conflict between the MPR and the BMM minutes (even when accepted by the Commission)
on the one hand and the contractual documents and FQP on the other hand, the latter will always take
precedence.
The FQP defines precisely the structure of the Monthly Progress Report whose some indicative sections
are listed below:
1)
Introduction: Normally, this section defines the period covered by this report.
2)
Highlights: This section describes in brief the key achievements of the reporting period, the key
issues identified or reported during the reporting period, deviations from the plan, and lists the
deliverables subject to acceptance with this report.
3)
Progress: This section describes in brief and in a structured manner the progress achieved
within the context of the planned tasks. For each task, a short description of the contribution to
the progress is given:

Description of the activities carried out;

Description of the results achieved;

Comments on on-going tasks, where appropriate;

Justification of the deviations from Section 1.
4)
Tasks planned for next month: This section defines all tasks planned for execution for the next
month.
5)
Requests for Actions: The Requests for Actions status should be listed with their reference
number and title, to which a short comment could be added, when useful.
6)
Deliverables/services subject to acceptance: This section lists all deliverables accepted in the
reporting month;
7)
Accepted resource-based quantities for simplified offers: This section lists the accepted
resource-based orders and orders during the reporting month;
8)
Annexes:
(1) The Deliverable Tracking Matrix showing the:
(2)

Planned delivery dates: contractually agreed, FQP agreed, RfA actions agreed or
mutually agreed in advance in a previous accepted MPR; It should be noted that DTM
is updated weekly by the contractor and delivered to DG TAXUD for information;

Foreseen delivery dates;

Actual delivery dates for review and for acceptance;

Deliverable delays (for review and acceptance);

List of reviewers;

Etc.
Planning: This annex includes the latest planning in place;
Page 79 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
(3)
Consumption: This annex reports on the monthly consumption of all unit-price related services
as well as on all resource-based (man-days) services/assignments ordered via the Specific
Contract or via the simplified offer mechanism. It should be noted that consumption annex is
updated weekly by the contractor and delivered to DG TAXUD for information;
(4)
Computation of GQI/KPIs/SQIs: This annex includes the detailed calculation of the GQI at the
level of the Specific Contract and at the level of the RFAs, if concluded. In addition, it includes
all KPI calculation data applicable in the concerned SC;
(5)
Risks: This annex includes a registry of all identified risks together with their status and
mitigation actions. The contractor will pay attention to, and report on, the following topics:






Risk Identification,
Risk Analysis,
Risk Planning,
Risk Tracking,
Risk Control,
Risk Communication
(6)
Complaints: This register includes a registry of all complaints formally communicated to
contractor.
(7)
Invoicing plan: This annex includes an invoicing plan so that the financial services of the
Commission can fine-tune payment schedules accordingly. Template for the invoicing plan is
part of the Baseline.
(8)
Monthly Service Report (MSR): This annex reports on the service units consumed and on
GQI/KPI/SQI measurements and evolution.
3.4.5
Acceptance of FQP, Take-over and Hamd-over
The acceptance of the FQP12 and the Takeover will be subject to a FAT the aim of which is to verify the
integrity between the FQP and Takeover reports with the setup of the contractor.
The acceptance of the Handover will be subject to a FAT performed in the premises of the contractor.
3.4.6
Acceptance of software
Acceptance of new applications or extensions of existing applications is performed according to a FAT/
SAT and CT stage, as detailed in the FQP, unless the Commission decides to go through a simple
qualification.
The FAT tests (WP.7.5.3) are the first stage of the acceptance process. During FAT stage the SOFTDEV contractor contractor is required to proof that the developed product meets the functional and nonfunctional requirements. This stage of tests, still executed in the environment fully controlled by SOFTDEV contractor (FAT environment), should be executed before formal delivery of product to DG
TAXUD. The scope of tests for this stage is defined in the Acceptance Test Plan (ATP) document
(WP.7.4.3).
The prerequisites for a software release built in increments following the Agile methodology to be
submitted to the FAT stage are the following:

12
Its underlying work items are marked as “done”, i.e. all criteria of their “Definitions of
Done” have been accepted by the Product Owner. The latter acceptance is done in the
Please refer to WP.0.1 for more details on the FQP used during the take over and the first months of service and
the final FQP (to be delivered for SFR 3 months after the take over).
Page 80 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
CONTRACT MANAGEMENT AND EXECUTION
Sandbox environment during the Iteration Reviews (refer to section section 3.3.3 of
the Tender Specifications - Part B (Terms of Reference)).

All bugs, issues, defects, critical source code quality issues, etc. detected during the
iteration and transition phases have been fixed.
The second step of the acceptance process is a SAT stage where contractor responsible for maintenance
of the applications during PROD lifecycle will repeat the FAT tests in the environment fully controlled
by him (SAT environment). If necessary, the scope of tests during this stage will be extended by the
contractor to guarantee the trouble-free operation later in the PROD environment.
The main purpose of the CT stage (3rd stage of the acceptance process) is to validate the business logic
and technical integration of the developed product with the involvmenet of Business Users and with the
National Administrations. The tests are managed by the maintenance contractor but the scope of tests is
documented in the CT documents (WP.8.5.2) and can vary dependently on the application type (TransEuropean or centralized).
During every stage of the acceptance process DG TAXUD requires as much as possible automation of
the testing process.
For the testing stage required during acceptance process (FAT/SAT/CT) it is expected that all tests are
executed in an integrated manner with the existing external applications / components, i.e. calling other
applications according to the interfaces in place. Only in case of integration with the applications under
development the usage of the mock ups emulating the functionality not yet existing can be exceptionally
justified. Each such deviations from this standard approach must be approved in advance by DG
TAXUD.
The need will arise for conducting testing on several applications in parallel, whilst respecting the need
to conduct tests in an integrated manner between applications/components. This must be possible
without multiplication of environments. The test cases must be designed to allow such parallel testing
notably by using logical data segregation.
3.4.7
Acceptance of Specifications Involving National Administrations
The life cycle of a specification involving the National Administrations of the Member States and/or
Candidate Countries or the administrations of other 3rd countries comprises three consecutive steps:

production of the specification in order to have it accepted by the Commission,

review for subsequent acceptance by the involved NAs,

maintenance and support.
The Commission will call a review workshop with the NAs, the outcome of which is a “workshop
decision” on each of the received comments.
The contractor will deliver the minutes of the workshop also according to an SfR/SfA cycle.
The Commission will then submit the bundle made of the documents as accepted by the Commission,
and of the “workshop decision” for the approval of the National Administrations.
Once the NAs accept the bundle, the contractor will consolidate the “workshop decision” into the
deliverables and deliver the final version of the specification, again according to an SfR/SfA cycle. This
final version becomes part of the documentation baseline of the project.
All deliverables produced by the contractor under this step will be in EN only.
The timing of the consecutive SfR/SfA cycles can be defined in the FQP, Specific Contracts and the
Requests for Action.
Page 81 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
4. Service & Deliverable catalogue
The table below lists all the services and deliverables linked to the Work Packages specified in section 2.2 and contains the following information for each service &
deliverable, where applicable:

Identification of the work package: WP.w.x.y.z;

Identification of the service or deliverable: DLV/SE-w.x.y.z;

DLV: a deliverable to be delivered to the Commission at a given date for review or acceptance;

SE: a service to be rendered to the Commission, the QoS of which must be reported in the monthly service report included in the Monthly Progress Report.

Plain text description of the deliverable or of the service;

Order Mechanism, coded as follows:



SC: Specific Contract,

RfA: Request for Action.
Request Mechanism, coded as follows:

SC: Specific Contract,

RfA: Request for Action,

RfE: Request for Estimate,

RfO: Request for Offer,

OR: On Request,

TR: Trigger.
Planning, coded as follows:

Planning specified in reference to T0, the starting date of the activity of the SC, and/or possibly in reference to other internal/external dependencies. When
applicable, the planning specifies if the date is for submission for review or for acceptance;

SC: Planning defined in the Specific Contract

FQP: Planning to be defined in the FQP,
Page 82 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE

RfA: Planning defined in the RfA,

Trigger: Planning will be defined in the Trigger,

MA: Planning mutually agreed and recorded in the MPR,

AN: As Needed meaning that the contractor must take the initiative to produce the deliverable whenever an external event triggers the need for it (mainly an
incident/request),

Continuous: self-explanatory, applicable for service,

Reference to another service or deliverable, which means it follows the same planning,

Plain text.
All references made under this section to “month” and “quarter” periods, to “monthly” and “quarterly” periodicity are relative to T0, the starting date of an SC,
unless explicitly stated otherwise.
 Delivery mechanism, coded as follows:
Not shown for services, as the service reporting is systematically made in the Monthly Service Report to report the QoS metrics of the service.
In case of a deliverable,


ID: Individual Delivery: the deliverable is delivered on its own,

SC: Specific Contract: no decision is taken at the level of this Technical Annex if the delivery will take place as ID or in the context of the MPR. The decision
will be taken at SC or RfA level;

RfA: Request for Action: no decision is taken at the level of this Technical Annex if the delivery will take place as ID or in the context of the MPR. The
decision will be taken at SC or RfA level;

TR: Trigger,

MPR: Monthly Progress Report,

FQP: Framework Quality Plan.
Acceptance mechanism, coded as follows:
"MPR" shown for service, as the correctness of the reported QoS and SQI is accepted via the acceptance of the MSR, as a part of the MPR. Note that it is the factual
correctness (alias integrity) of the reported Quality of Service (QoS) which is subject to acceptance in the monthly progress report and not the service itself.
Page 83 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
In case of a deliverable:


NO: No formal acceptance required,

End of Action Report: Electronic acceptance (registered e-mail signed by HoU) of the intereim and/or final “End of Action” report submitted electronically
by the contractor (for more info on the “End of Action “ report see section 3.4.1 of this annex);

SC: Specific Contract: no decision is taken at the level of this Technical Annex, if the acceptance will take place via the “End of Action” report or at MPR
level (MPR). This is directly linked with the applicable delivery mechanism;

RfA: Request for Action: no decision is taken at the level of this Technical Annex, if the acceptance will take place via the “End of Action” report or at MPR
level (MPR). This is directly linked with the applicable delivery mechanism;

DLV.0.7 (MPR): Monthly Progress Report: the acceptance by default of the deliverable by the acceptance of the Monthly progress report in which the
deliverable is proposed for acceptance. The non-acceptance of the deliverable would need to be notified as a specific qualification in the letter of (non)
acceptance of the MPR;

Reference to another deliverable, which means it has the same acceptance mechanism.
SQI/KPI:
4.1

Either a reference to an applicable SQI/KPI defined in appendix 1,

Or a reference to another deliverable/service, the SQI/KPI of which is applicable;

Or "SC", "RfA" or "Trigger", which means that the SQIs/KPIs will be defined in the Specific Contract or Request for Action.
List of the pre-defined deliverables and services
The following list is provided for information only, it is neither exhaustive nor binding as it constantly evolves and does not take into account the future transformations
that will occur during the lifetime of the SOFT-DEV contract. The present list is provided to give an indication to the Tenderer of the level of deliverables expected. This list
may be further specified by DG TAXUD at each Specific Contract or Request for Action.
For all deliverables mentioned below, the following information will be completed in the first delivery of the FQP: review cycle, publication (CIRCABC, email, online), etc.
The structure of the main deliverables will be in line with the one provided by the incumbent contractors and if needed will be updated in the first delivery of the FQP.
Page 84 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
The delivery format of all deliverables mentioned below will have to be agreed with DG TAXUD and described in the first delivery of the FQP. By default, it will be a MSOffice (or compatible) deliverable uploaded on CIRCABC but DG TAXUD may agree to change to format of some deliverables e.g. extracts from the SMT or CMDB data
available on the Application Lifecycle Management platform or log files of test tools. Furthermore, some deliverables will have to be continuously updated and on-line via the
agreed toolset (see deliverables table for details).
Also, the contractor has to re-deliver the artefacts upon request of the Commission and at least once a year (see WP.10) to an electronic repository of the Commission
(CIRCABC for example). However, the Commission may request the contractor to redeliver them, e.g. on a DVD-ROM media or an FTP server instead.
All written artefacts are to be produced in English, unless stated otherwise.
Please note that KPI93, KPI94 (complaints related) and KPI95 (user satisfaction) are applicable to all services and/or deliverables of the contractor and is for readability
reasons not added in all entries of the table below.
The “SQI/KPI” references are “indicative” meaning that they could be completed and/or updated at each Specific Contract or RfO/RfE/RfA and during the lifetime of the
SOFT-DEV contract.
Work
Package
WP.0.1
WP.0.1
Deliverable
DLV-0.1-1
DLV-0.1-2
Deliverable Title
Order
Request Planning
mechanism mechanism
FQP, including its annexes
Updated version of FQP (at each major
event or at least per year), including its
annexes and the internal working
procedures
Page 85 of 244
SC
SC
SC
SC
Delivery Acceptance
Mechanism Mechanism
SfR 3 months after the end of the
take over
ID
as per SC
ID
MPR
SQI
KPI
(indicative)
SQI02
KPI02
MPR
SQI02
KPI02
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.0.4
DLV-0.4-1
SC offer in response to RFO
SC
RfO
WP.0.4
DLV-0.4-2
Proposal/Offer in response to RfE
WP.0.4
DLV-0.4-3
WP.0.5.1
RFA
RfE
End of Action report
SC
SC
Upon completion of the RFA or
order/assignment
SE-0.5.1-1
Internal QA and QC
SC
SC
Continuous
WP.0.5.1
DLV-0.5.1-2
SC
OR
max 5 wdays upon request from the
Commission
WP.0.5.2
SE-0.5.2-1
Quality records (minutes of internal
meetings), filed in contractor’s
premises
Risk Management
SC
SC
Continuous
WP.0.5.2
DLV-0.5.2-2
SC
OR
max 5 wdays upon request from the
Commission
WP.0.5.3
DLV-0.5.3-1
Risk analysis records
contractor’s premises)
Self-Assessment reports
SC
OR
(filed
in
As specified in the RFO
The response time along with the
T1/T2/T3 review cycle for a
proposal/offer will be defined by the
Commission in the RfE.
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
ID
As specified
in the RFO
KPI91
ID
Order (RFA
or trigger)
made on the
basis of the
offer/propos
al
KPI91
ID
MPR
-
-
MPR
-
ID
no
-
-
MPR
-
ID
no
-
ID
no
KPI31
ID
no
-
MPR
At least twice per year
WP.0.5.3
DLV-0.5.3-2
Internal Audit reports
WP.0.5.4
SE-0.5.4-1
Internal Team
Management
Organisation
Page 86 of 244
and
SC
OR
SC
SC
Continuous
KPI41
KPI42
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.0.5.4
DLV-0.5.4-2
Provide number of staff,
location, qualifications, etc.
WP.0.6
SE-0.6-1
Preparation of and attendance
monthly meetings (BMM)
WP.0.6
SE-0.6-2
Attendance
meetings
WP.0.6
SE-0.6-3
WP.0.6
SQI
KPI
(indicative)
SC
SC or OR
As part of MPR or specific upon
request
-
MPR
-
at
SC
SC
as per FQP and in exceptional case,
MA
-
MPR
-
follow-up
SC
OR
Day after BMM or MA
-
MPR
-
Attendance at multilateral meetings
SC
OR
Monthly or on request
-
MPR
-
SE.0-6-4
Attendance at the Steering Committee
meetings
SC
SC
MA, on average once per quarter
WP.0.6
SE-0.6-5
Attendance at ad hoc meetings
SC
OR
on 4 hours’ notice
-
MPR
-
WP.0.6
SE-0.6-6
Attendance at project, contract and
supply mgmt. meetings with DG
TAXUD sector(s)
SC
OR
Bi-weekly or according to the
iteration calendar defined in the
Agile release planning
-
MPR
-
WP.0.6
SE-0.6-7
Attendance at meetings
category owners
IT
SC
OR
Monthly
-
MPR
-
WP.0.6
SE-0.6-8
Attendance at meetings with DG
TAXUD/LISO related to security
aspects
SC
OR
MA
-
MPR
-
at
BMM
names,
Delivery Acceptance
Mechanism Mechanism
with
Page 87 of 244
Joining the meeting on
time and prepared to
discuss strategic reports,
plans and risks.
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.0.6
SE-0.6-9
Attendance
at
meetings
with
responsible Commission sector related
to
the
hosting
of
systems/applications/components in the
DG TAXUD Data Centre
SC
OR
MA
WP.0.6
DLV-0.6-10
Agenda of Bilateral Monthly Meeting
SC
SC
1 w-day before the meeting
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
-
MPR
-
ID
MPR
SQI02
KPI02
WP.0.6
DLV-0.6-11
Minutes of the Bilateral Monthly
Meeting bundled with MPR
SC
SC
Date of BMM + 10 wdays for
acceptance
ID
End of
Action report
bundled with
MPR
-
WP.0.6
DLV-0.6-z-12
Meeting documents (agenda, briefing
material, minutes and action lists) (z=
all the meetings)
SC
SC
Date of the meeting +5 wdays for
acceptance9
ID
MPR
SQI04
Monthly Progress Reports, which
includes Monthly Service Reports,
Service Level Reports and annexes
SC
Daily, weekly and quarterly reports, as
documented in the FQP
SC
WP.0.7
WP.0.7
DLV-0.7-1
DLV-0.7-2
Page 88 of 244
KPI04
Date of the Agile meeting + 1 wday
for acceptance.
SC
SC
Max (end of the reporting period + 5
wdays, Date of BMM – 5 wdays) for
review
Max (Date of BMM +5 wdays) for
acceptance
ID
As per FQP
ID
End of
Action
Report
SQI02
End of
Action report
SQI04
KPI02
KPI04
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.0.8
DLV-0.8-1
Weekly update of the planning of
contractors’ activities, services and
deliverables
SC
SC
as per MPR
WP.0.9
SE.0-9-1
Co-operation with the Commission (and
any third party nominated by it) during
quality, process and security audit
SC
SC
Average duration of 5 wdays, date as
per request if requested date is more
than 2 weeks from date of request,
otherwise MA;
WP.0.9
DLV-0.-9-2
Position of the audited contractor on
the audit report
SC
SC
20 wdays after reception of the audit
report, for acceptance
WP.0.9
DLV-0.-9-3
Confirmation that the agreed actions by
the contractor are implemented
SC
SC
According to the agreed timetable
WP.0.10
DLV-0.10-1
Re-delivery of all artefacts from the
past year to an electronic repository of
the Commission (Commission may also
request re-delivery on DVD-ROM, if
necessary) and according to the
anonymization principles
SC
SC
As per SC (or as per RFA in case of
special requests
Co-operation with the Commission (and
any third party nominated by it) during
benchmarking related to the costs of
effort quoted by the contractor for its
activities
SC
WP.0.11
SE.0-11-1
Page 89 of 244
OR
MA
Delivery Acceptance
Mechanism Mechanism
MPR
MPR
Positive feedback from
the auditors regarding the
co-operation of the
contractor during audit.
ID
SQI
KPI
(indicative)
-
-
End of
Action report
SQI02
All actions performed by
the contractor according to
expectations
KPI92
ID
MPR
KPI02
SQI02
KPI02
Positive feedback from
the third party regarding
the co-operation of the
contractor during the
benchmark.
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.0.12
SE-0.12-1
Definition and running of a CSIP
linked to all services of the FWC
SC
SC
As per SC
WP.0.12
DLV-0.12-2
CSIP improvement proposals
SC
SC
Minimum once a year
WP.0.12
DLV-0.12-3
Reports on CSIP related activities
SC
SC
Following undertaken activities
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
-
MPR
ID
End of
Action report
SQI04
MPR
SQI04
ID
KPI04
KPI04
WP.0.13
SE-0.13-1
Maintenance and monitoring of the
contractual OLA and the service
catalogue
WP.0.13
DLV-0.13-2
Service catalogue
SC, RFA
SC, RFA
SC
SC
WP.0.13
SE-0.13-3
Performance of user satisfaction survey
SC, RFA
SC, RFA
WP.0.13
DLV-0.13-4
Report on outcome of user satisfaction
survey
SC
SC
WP.0.14.1
SE-0.14.1-1
Maintenance of the security plan
WP.0.14.1
DLV-0.14.1-2
Security plan
Page 90 of 244
SC, RFA
SC, RFA
SC
SC
As per SC or RFA
Minimum once a year
Once a year
As per SC or RFA
Minimum once a year
-
MPR
-
ID
End of
Action report
SQI04
-
MPR
-
ID
End of
Action report
SQI04
-
MPR
-
ID
End of
Action report
SQI02
KPI04
KPI04
KPI02
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
WP.0.14.2
SE-0.14.2-1
Integration of security requirements
SC, RFA
SC, RFA
As per SC or RFA
-
MPR
-
WP.0.15
SE-0.15-1
Management of business continuity
SC, RFA
SC, RFA
As per SC or RFA
-
MPR
-
WP.0.16.1
SE-0.16.1-1
Maintenance of a knowledge base for
all stakeholders
SC, RFA
SC, RFA
As per SC or RFA
-
MPR
-
WP.0.16.1
DLV-0.16.1-2
Knowledge base
SC
SC
ID
End of
Action report
SQI04
-
MPR
-
ID
End of
Action report
SQI04
WP.0.16.2
SE-0.16.2-1
Management of knowledge transfer
WP.0.16.2
DLV-0.16.2-2
Reports on knowledge transfer
SC
SC
SC, RfA
SC, RfA
Minimum once a year
As per SC
Must be available on site and
provided to the Commission within
3wd upon request
KPI04
KPI04
WP.2
SE-2-1
Takeover activities
SC
SC
Continuous during the takeover No regression/no incident
period
after takeover, no
complaint from 3rd parties
during takeover, no
deviation according to
plan
KPI81
WP.2
DLV-2-2
Detailed takeover plan
SC
SC
Submitted for acceptance as per SC
End of
Action report
SQI02
End of
Action report
SQI01
WP.2
DLV-2-3
Takeover FAT report (for every phase)
Page 91 of 244
SC
SC
Submitted for acceptance as per SC
ID
ID
KPI02
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.2
WP.2
WP.2.2
WP.2.2
WP.2.2
Deliverable
DLV-2-4
DLV-2-5
DLV-2.2-z-1
DLV-2.2-z-2
DLV-2.2-z-3
Deliverable Title
Order
Request Planning
mechanism mechanism
Final takeover report
Updated FQP
SC
SC
ATP (definition of FAT scope) (z= all
applications)
SC
FAT report (z= all applications)
SC
Analysis report counting the FSP (IFP
and SNAP) points (z= all applications)
SC
SC
SC
SC
SC
SC
Submitted for acceptance as per SC
Submitted for acceptance as per SC
Submitted for acceptance as per SC
Submitted for acceptance as per SC
Submitted for acceptance as per SC
WP.3
SE-3-1
Handover activities
SC, RFA
SC, RFA
Continuous during the handover
period
WP.3.1
DLV-3.1-1
Detailed handover plan
SC, RFA
SC, RFA
Submitted for acceptance as per
SC/RFA
Page 92 of 244
Delivery Acceptance
Mechanism Mechanism
ID
ID
ID
ID
ID
KPI
(indicative)
End of
Action report
SQI01
End of
Action report
SQI01
End of
Action report
SQI04
End of
Action report
SQI01
End of
Action report
SQI01
Failure to pass the
information and
knowledge to the future
new contractor will result
in non-payment of the
services of the contractor
during the hand-over
period
ID
SQI
End of
Action report
KPI01
KPI01
KPI04
KPI01
KPI01
-
SQI02
KPI02
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.3.1
WP.3.1
WP.3.1
WP.3.1
WP.3.2
Deliverable
DLV-3.1-2
DLV-3.1-3
DLV-3.1-4
DLV-3.1-z-5
DLV-3.2-z-1
Deliverable Title
Order
Request Planning
mechanism mechanism
Handover report (incl. lessons learned)
Handover SAT plan
Handover SAT report
SC, RFA
SC, RFA
SC, RFA
Handover of all artefacts, tools and
related documentation (except for those
related to the central IT applications)
(z= all components)
SC, RFA
Handover of all documentation, source
code and reports related to the central
IT applications (incl. final outstanding
defect list and final baseline) (z= all
applications)
SC, RFA
SC, RFA
SC, RFA
SC, RFA
SC, RFA
SC, RFA
Submitted for acceptance as per
SC/RFA
ID
Submitted for acceptance as per
SC/RFA
ID
Submitted for acceptance as per
SC/RFA
ID
Submitted for acceptance as per
SC/RFA
ID
Submitted for acceptance as per
SC/RFA
ID
WP.3.3
SE-3.3-1
Support/training to the new contractor
during the handover process
SC, RFA
SC, RFA
During 3 months
WP.3.3
DLV-3.3-2
After-handover support weekly report
SC, RFA
SC, RFA
Submitted for acceptance as per SC
Page 93 of 244
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
End of
Action report
SQI04
End of
Action report
SQI01
End of
Action report
SQI01
End of
Action report
SQI04
End of
Action report
SQI04
-
MPR
-
ID
End of
Action report
SQI01
KPI04
KPI01
KPI01
KPI04
KPI04
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.3.3
Deliverable
DLV-3.3-3
Deliverable Title
Order
Request Planning
mechanism mechanism
Updated version of handover report
(incl. after handover support period)
SC, RFA
SC, RFA
Submitted for acceptance as per SC
WP.4.1
SE-4.1-1
Support on IT strategy definition and
implementation
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.4.1
DLV-4.1-z-2
Strategy studies
alternatives)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
(z=
all
strategy
Delivery Acceptance
Mechanism Mechanism
and
WP.4.2
SE-4.2-1
Definition and maintenance of IT
Portfolio and Master Plan
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.4.2
DLV-4.2-2
IT Master Plan
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
and
Submitted
for
review
acceptance as per SC or RfA
and
WP.4.2
DLV-4.2-z-3
IT Portfolio (z= all components)
SC, RfA
SC, RfA
WP.4.3
SE-4.3-1
Support on Architecture framework
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.4.3
DLV-4.3-z-2
Architecture framework and methods
documents (z= all components)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Support on
development
SC, RFA
WP.4.4
SE-4.4-1
enterprise
architecture
Page 94 of 244
SC, RFA
Continuous during SC or RFA
and
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
ID
-
KPI01
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.4.4
Deliverable
DLV-4.4-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
Enterprise architecture framework and
methods
documents
(z=
all
components)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Delivery Acceptance
Mechanism Mechanism
and
WP.4.5
SE-4.5-1
Support on application and service
architecture support
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.4.5
DLV-4.5-z-2
Global EU Customs Application and
Service Architecture documents (z= all
components)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
and
TAXUD EU Customs Application and
Service Architecture documents (z= all
components)
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
and
WP.4.5
DLV-4.5-z-3
SC, RfA
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
End of
Action report
SQI01
ID
KPI01
KPI01
KPI01
WP.4.6.1
SE-4.6.1-1
Architecture development support
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.4.6.2
SE-4.6.2-1
Architecture implementation support
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.4.6.3
SE-4.6.3-1
Architecture transition and operational
support
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.4.6.4
SE-4.6.4-1
Architecture continuous improvement
support
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.4.7
SE-4.7-1
Support on ARIS and Architecture
tools
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
Page 95 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.4.7
WP.4.7
WP.5
Deliverable
DLV-4.7-z-2
DLV-4.7-3
DLV-5-z-1
Deliverable Title
Order
Request Planning
mechanism mechanism
Updated version of the user guidelines
and modelling conventions (z= all
components)
SC, RfA
Updated version of the ARIS or
architecture
tool
(customisation
/configuration)
SC, RfA
BPM or specification documents
translated into DE or FR (z= all
systems)
SC, RfA
of
SC, RFA
SC, RFA
Continuous during SC or RFA
all
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.5.1
SE-5.1-1
Production and
Feasibility Studies
WP.5.1
DLV-5.1-z-2
Feasibility
systems)
maintenance
Studies
(FS)
(z=
SC, RfA
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
and
Submitted
for
review
acceptance as per SC or RfA
and
Submitted
for
review
acceptance as per SC or RfA
and
WP.5.2
SE-5.2-1
Production and maintenance of the
Business Analysis documents
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.2
DLV-5.2-z-2
Business Analysis documents (z= all
systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Production and maintenance of the
BPMs (levels 1-2-3)
SC, RFA
WP.5.3
SE-5.3-1
Page 96 of 244
SC, RFA
Delivery Acceptance
Mechanism Mechanism
Continuous during SC or RFA
and
and
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
End of
Action report
SQI01
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
ID
ID
-
KPI01
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.5.3
Deliverable
DLV-5.3-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
BPM (levels 1-2-3) documents (z= all
systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.5.4
SE-5.4-1
Production and maintenance
Business Requirements
of
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.4
DLV-5.4-z-2
Business Requirements documents (z=
all systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.5.5
SE-5.5-1
Production and maintenance of detailed
level 4 BPMs
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.5
DLV-5.5-z-2
Detailed level 4 BPM documents (z=
all systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.5.6
SE-5.6-1
Maintenance of Business Acceptance
Criteria documents
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.6
DLV-5.6-z-2
Business
Acceptance
documents (z= all systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.5.7
SE-5.7-1
System scope management
WP.5.7
DLV-5.7-z-2
System scope
systems)
documents
Page 97 of 244
Criteria
(z=
all
SC, RFA
SC, RFA
Continuous during SC or RFA
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Delivery Acceptance
Mechanism Mechanism
and
and
and
and
and
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
KPI01
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
WP.5.8
SE-5.8-1
Hosting GEFEG.FX repositories for
DG TAXUD and providing user
management for the hosted repositories
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.5.8
SE-5.8-2
Production and publication of Data
Integration and Harmonisation artefacts
SC, RFA
SC, RFA
Continuous during SC or RFA
-
MPR
-
WP.5.8
DLV-5.8-3-z
Production and publication of Data
Integration and Harmonisation artefacts
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
ID
End of
Action report
SQI01
z = 1 : Preparation of information and
training materials on the use and
features of EU CDM (after every new
release of EU CDM)
z = 2 : Webinar on the use of EU CDM
(for general, international audience,
including MS customs and worldwide
customs partners representatives, as
well as to DG TAXUD officials)
z = 3 : Provide visitor statistics of the
EU CDM publications on a monthly
basis
z = 4 : 2 hours remote support via
WebEx (or other remote meeting tool)
on data mapping (with a report on the
session)
Page 98 of 244
and
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.5.9
Deliverable
SE-5.9-1
Deliverable Title
Order
Request Planning
mechanism mechanism
Integration of PCA certificates in EU
Customs Single Window Certificates
Exchange (EU CSW-CERTEX)
Page 99 of 244
SC, RFA
SC, RFA
Continuous during SC or RFA
Delivery Acceptance
Mechanism Mechanism
-
MPR
SQI
KPI
(indicative)
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.5.9
Deliverable
DLV-5.9-2-z.x
Deliverable Title
Order
Request Planning
mechanism mechanism
Integration of PCA certificates in EU
Customs Single Window Certificates
Exchange (EU CSW-CERTEX)
z = 1 : Complex PCA certificate
domain
z = 2 : Medium complexity PCA
certificate domain
z = 3 : Simple complexity PCA
certificate domain
x = 1 : Set-up
the
mapping
environment in GEFEG.FX for one
certificate domain (with report about
set-up)
x = 2 : BPM release (Level 1 to 4) in
ARIS (incorporation of new domain
into EU CSW-CERTEX BPM)
x = 3 : Data mapping in Excel and
GEFEG.FX formats
x = 4 : Guidelines release in Word and
Excel (incorporation of a new domain
into EU CSW-CERTEX overall
guidelines document)
x = 5 : BAC document release in Word
and Excel (incorporation of new
domain into EU CSW-CERTEX
overall BAC document)
x = 6 : Quantity management paper in
Word per PCA certificate domain
Page 100 of 244
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Delivery Acceptance
Mechanism Mechanism
and
ID
End of
Action report
SQI
KPI
(indicative)
SQI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.5.10
SE-5.10-1
System scope management
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.10
DLV-5.10-2-z
Business Request for Change (RfC)
preparation and registration in the
request tracking system
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Delivery Acceptance
Mechanism Mechanism
and
SQI
KPI
(indicative)
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
KPI01
z = 1 : simple complexity RfC
z = 2 : medium complexity RfC
z = 1 : Complex RfC
WP.5.11
SE-5.11-1
Business Proof-of-Concept (PoC)
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.5.11
DLV-5.11-z-2
Business Proof-of-Concept (PoC) (z=
all systems)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.6.1
SE-6.1-1
Production and maintenance of
feasibility studies and IT inception
artefacts
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.1
DLV-6.1-z-2
Feasibility Studies and IT inception
artefacts (z= all applications)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.6.2
SE-6.2-1
Production and maintenance of IT
requirements
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.2
DLV-6.2-z-2
IT requirements documents (z= all
applications)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Page 101 of 244
and
and
and
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.6.3
SE-6.3-1
Production and maintenance of
architectural solutions for the Customs
IT systems/applications
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.3
DLV-6.3-z-2
Architectural
applications)
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
WP.6.4
SE-6.4-1
IT analysis
WP.6.4
DLV-6.4-z-2
IT analysis
applications)
WP.6.5
SE-6.5-1
IT design
WP.6.5
DLV-6.5-z-2
IT design
applications)
documents
documents
documents
(z=
(z=
(z=
all
all
all
SC, RFA
SC, RFA
Continuous during SC or RFA
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
SC, RFA
SC, RFA
Continuous during SC or RFA
SC, RfA
SC, RfA
Submitted
for
review
acceptance as per SC or RfA
Delivery Acceptance
Mechanism Mechanism
and
and
and
WP.6.6.1
SE-6.6.1-1
Production and maintenance of the
Master Test Plan
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.6.1
DLV-6.6.1-z-2
MTP (Master Test Plan) (z= all
applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
Production and maintenance of the Test
Design Specification
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.6.2
SE-6.6.2-1
Page 102 of 244
SQI
KPI
(indicative)
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
-
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.6.6.2
Deliverable
DLV-6.6.2-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
TDS (Test Design Specification) (z= all
applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
WP.6.7
SE-6.7-1
Production and maintenance of the
specifications required to support the
IT implementation of a given IT
system/application
and
possible
migration activities.
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.7
DLV-6.7-z-2
IT implementation and migration
documents (z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
Delivery Acceptance
Mechanism Mechanism
ID
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
End of
Action report
SQI01
End of
Action report
SQI01
MPR
-
SE-6.8-1
Production and maintenance of the
Technical System Specifications for
Trans-European Systems
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.6.8
DLV-6.8-z-2
Technical
System
Specifications
documents (z= all applications)
SC, RFA
SC, RFA,
Trigger
Submitted as per SC or RfA or
Trigger
ID
IT Detailed Design documents (z= all
applications)
SC, RFA
SC, RFA,
Trigger
Submitted as per SC or RfA or
Trigger
ID
Development and documenting
Programs or Software components
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.2
DLV-7.1-z-1
SE-7.2-1
Page 103 of 244
of
KPI
(indicative)
End of
Action report
WP.6.8
WP.7.1
SQI
-
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.7.2
WP.7.2
Deliverable
DLV-7.2-z-2
DLV-7.2-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
Documentation of Programs
Software
components
(z=
applications)
and
all
SC, RfA
Programs and Software Components
(subject to FAT and SAT) (z= all
applications)
SC, RfA
SC, RfA
SC, RfA
Delivery Acceptance
Mechanism Mechanism
Submitted
for
review
acceptance as per SC or RfA
and
Submitted
for
review
acceptance as per SC or RfA
and
ID
ID
SQI
KPI
(indicative)
End of
Action report
SQI02
End of
Action report
SQI01
SQI07
KPI02
KPI01
WP.7.3
SE-7.3-1
Production and maintenance
Supporting Manuals
of
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.3
DLV-7.3-z-2
Supporting
applications)
all
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
manuals
(z=
WP.7.4.1
SE-7.4.1-1
Production and maintenance of Test
Design Specifications (TDS) and test
cases for FAT
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.4.1
DLV-7.4.1-z-2
Test Design Specifications (TDS) and
test cases for FAT (z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
Production and maintenance of Test
Design Specifications (TDS) and test
cases for CT
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.4.2
SE-7.4.2-1
Page 104 of 244
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
-
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.7.4.2
Deliverable
DLV-7.4.2-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
Test Design Specifications (TDS) and
test cases for CT (z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
WP.7.4.3
SE-7.4.3-1
Production and maintenance of the
Acceptance Test Plan (ATP) for FAT
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.4.3
DLV-7.4.3-z-2
Acceptance Test Plan (ATP) for FAT
(z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
WP.7.4.4
SE-7.4.4-1
Production and maintenance of the
Acceptance Test Plan (ATP) for QT
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.4.4
DLV-7.4.4-z-2
Acceptance Test Plan (ATP) for QT
(z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
SC, RFA
SC, RFA
Continuous during SC or RFA
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
SC, RFA
Continuous during SC or RFA
WP.7.5.1
SE-7.5.1-1
Unit testing
WP.7.5.1
DLV-7.5.1-z-2
Records of
applications)
WP.7.5.2
SE-7.5.2-1
unit
testing
(z=
all
Integration, user interface and web
service testing
Page 105 of 244
SC, RFA
Delivery Acceptance
Mechanism Mechanism
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
-
KPI01
KPI01
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.7.5.2
Deliverable
DLV-7.5.2-z-2
Deliverable Title
Order
Request Planning
mechanism mechanism
Records of integration, user interface
and web service testing (z= all
applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
WP.7.5.3
SE-7.5.3-1
Factory Acceptance Testing (FAT)
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.5.3
DLV-7.5.3-z-2
FAT report (z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
WP.7.5.4
SE-7.5.4-1
Qualification Testing (QT)
SC, RFA
SC, RFA
Continuous during SC or RFA
WP.7.5.4
DLV-7.5.4-z-2
Delivery Qualification Report (DQR)
(z= all applications)
SC, RfA
SC, RfA,
Trigger
Submitted
for
review
and
acceptance as per SC or RfA or
Trigger
Delivery Acceptance
Mechanism Mechanism
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
KPI01
KPI01
KPI01
WP.7.6
SE-7.6-1
Code quality monitoring and technical
debt prevention
SC, RfA
SC, RfA
Continuous during RFA
-
MPR
-
WP.7.6
DLV-7.6-2
Code quality
indicators.
debt
SC, RfA
SC, RfA
Continuous during RFA
ID
End of
Action
Report
-
WP.8.1.1.1
SE-.8.1.1.1-1
Handling of specification and software
incidents as per contractual OLA and
FQP
SC, RFA
SC, RFA
Continuous as from the allocation of According to expectations
the call
set in the contractual
OLA.
and
technical
Page 106 of 244
KPI11
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.8.1.1.2
WP.8.1.2
WP.8.1.2
WP.8.1.2
Deliverable
SE-.8.1.1.2-1
SE-.8.1.2-1
DLV-8.1.2-2
DLV-8.1.2-z-3
Deliverable Title
Order
Request Planning
mechanism mechanism
Handling of Requests for Information
(RfI) as per contractual OLA and FQP
SC, RFA
Problem
management
contractual OLA and FQP
SC, RFA
as
per
Problem management reports
SC, RfA
System specific problem management
reports (z= all systems)
SC, RfA
SC, RFA
SC, RFA
Delivery Acceptance
Mechanism Mechanism
Continuous as from the allocation of According to expectations
the call
set in the contractual
OLA.
Continuous as from the allocation of According to expectations
the call
set in the contractual
OLA.
SC, RfA,
Trigger
On a daily/weekly/monthly basis
SC, RfA,
Trigger
On request
ID
MPR
SQI
KPI
(indicative)
KPI14
KPI12
SQI04
KPI04
ID
MPR
SQI04
KPI04
WP.8.1.3.1
SE-.8.1.3.1-1
Change management as per contractual
OLA and FQP
SC, RFA
SC, RFA,
Trigger
Continuous as from the registration According to expectations
set in the contractual
of the Request for Change
OLA.
-
WP.8.1.3.2
DLV-8.1.3.2-1
Requests For Change
discussion at CAB
SC, RfA
SC, RfA,
Trigger
Following the schedule of the CABs
ID
MPR
-
WP.8.1.3.2
DLV-8.1.3.2-2
Record of CAB decisions
SC, RfA
SC, RfA,
Trigger
Following the schedule of the CABs
ID
MPR
-
WP.8.1.4.1
SE-.8.1.4.1-1
Reparation of defects of
Specifications
SC, RFA
SC, RFA,
Trigger
Continuous as from the registration According to expectations
of the defects
set in the contractual
OLA.
ready
Page 107 of 244
the
for
IT
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
Delivery Acceptance
Mechanism Mechanism
WP.8.1.4.2
SE-.8.1.4.2-1
Reparation of defects of the Build and
Test software and documents
SC, RFA
SC, RFA,
Trigger
Continuous as from the registration According to expectations
of the defects
set in the contractual
OLA.
WP.8.1.4.1
DLV-8.1.4.1
Corrected IT Specifications
SC, RfA
SC, RfA,
Trigger
Submitted as per SC, RFA, On
request
WP.8.1.4.2
DLV-8.1.4.2-1
Emergency fix (hotfix)
SC, RfA
SC, RfA,
Trigger
Submitted as per SC, RFA, On
request
WP.8.1.5
SE-8.1.5-1
Reparation of defects due to upgrade of
COTS
SC, RfA
SC, RfA,
Trigger
Continuous as from the registration According to expectations
of the defects
set in the contractual
OLA.
WP.8.1.5
DLV-8.1.5-1
Hotfix to repair COTS software defects
SC, RfA
SC, RfA,
Trigger
Submitted as per SC, RFA, On
request
WP.8.2
SE-.8.2-1
Configuration management according
to the contractual OLA and FQP
SC, RFA
SC, RFA
Continuous
WP.8.3.1
SE.8.3.1-1
Delivery of software
SC, RFA
SC, RFA,
Trigger
Continuous
WP.8.3.1
DLV.8.3.1-1
Software release
SC, RFA
SC, RFA,
Trigger
Submitted as per SC, RFA, Trigger
WP.8.3.2
SE.8.3.1-2
Support to service transition services
SC, RFA
SC, RFA
Continuous
Page 108 of 244
ID
MPR
SQI
KPI
(indicative)
KPI21
KPI21
ID
MPR
KPI21
-
MPR
-
-
MPR
-
ID
End of
Action report
or MPR
As per SC,
RFA
-
MPR
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
WP.8.3.3
SE.8.3.1-3
WP.8.3.3
DLV.8.3.1-4
WP.8.4.1
SE.8.4.1-1
WP.8.4.1.1
SE.8.4.1.1-1
WP.8.4.1.1
DLV.8.4.1.1-2
WP.8.4.1.2
SE.8.4.1.2-1
WP.8.4.1.2
DLV.8.4.1.2-2
WP.8.4.2
SE.8.4.2-1
WP.8.4.3
SE.8.4.3-1
WP.8.5.1
SE.8.5.1-1
WP.8.5.2
WP.8.5.3
Deliverable Title
Order
Request Planning
mechanism mechanism
Knowledge transfer between the SOFTDEV and the ITSM contractors
Training and knowledge material for
ITSM contractors
Set up, Install, Operate and Maintain the
IT infrastructure and Tools at the DG
TAXUD Data Centre
ICT Infrastructure and Tools Capacity
Management
The infrastructure and tools
configuration baseline
Provision of the development
environment
Development environment baseline
SC, RFA
SC, RFA
Continuous
SC, RFA
SC, RFA
Continuous
SC
SC
Continuous
SC
SC
Continuous
SC
SC
Submitted as per FQP
SC, RFA
SC, RFA
Continuous
SC, RFA
SC, RFA
Submitted as per FQP
Set up, install, operate and maintain the
FAT and Sandbox environments
provided by DG TAXUD
Hardware and COTS acquisitions
required to support SOFT-DEV services
Service Transition and operational
support
SC, RFA
SC, RFA,
Trigger
Continuous
SC, RFA
SC, RFA
MA
SC, RFA
SC, RFA,
Trigger
Trigger
SE.8.5.2-1
Conformance Testing support
SC, RFA
SC, RFA,
Trigger
Trigger
SE.8.5.3-1
Support to the National Administrations
SC, RFA
SC, RFA,
Trigger
Trigger
Page 109 of 244
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.8.5.4
SE.8.5.4-1
Technical Review of the Deliverables of
Other Contractors
SC, RFA
SC, RFA,
Trigger
Trigger
WP.8.5.5
SE.8.5.5-1
Delivery and Management of
Translations
SC, RFA
SC, RFA,
Trigger
Trigger
WP.8.5.6
SE.8.5.6-1
Specific support on ARIS and/or other
modelling tools
SC, RFA
SC, RFA,
Trigger
Trigger
WP.8.5.7
SE.8.5.7-1
Maintenance of the Corporate tools for
Trans-European systems
SC, RFA
SC, RFA,
Trigger
WP.8.5.8.1
SE-8.5.8.1-1
Production and maintenance of Service
Management Plan OLA for TES
SC, RfA
WP.8.5.8.1
DLV-8.5.8.1-1
Service Management Plan OLA for
TES
SC, RfA
-
-
MPR
-
-
MPR
-
Trigger
-
MPR
-
SC, RFA,
Trigger
Continuous during SC or RFA
-
MPR
-
SC, RFA,
Trigger
Submitted for review and
acceptance as per SC or RfA
ID
End of
Action report
SQI01
-
MPR
-
ID
End of
Action report
SQI01
MPR
-
Production and maintenance of BCP
Management Plan for TES
SC, RfA
SC, RFA,
Trigger
Continuous during SC or RFA
WP.8.5.8.2
DLV-8.5.8.2-1
BCP Management Plan for TES
SC, RfA
SC, RFA,
Trigger
Submitted for review and
acceptance as per SC or RfA
SC, RFA,
Trigger
Continuous during SC or RFA
Production and maintenance of Crisis
Management for TES
Page 110 of 244
SC, RfA
KPI
(indicative)
MPR
SE-8.5.8.2-1
SE-8.5.8.3-1
SQI
-
WP.8.5.8.2
WP.8.5.8.3
Delivery Acceptance
Mechanism Mechanism
-
KPI01
KPI01
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
WP.8.5.8.3
DLV-8.5.8.3-1
WP.8.6.1.1
DLV-8.6.1.1-1
Deliverable Title
Order
Request Planning
mechanism mechanism
Crisis Management Plan for TES
SC, RfA
Working Group Meeting – Preparation
of material
SC, RfA
SC, RFA,
Trigger
Delivery Acceptance
Mechanism Mechanism
Submitted for review and
acceptance as per SC or RfA
ID
RfA,
Trigger
meeting date – 10 wdays for review,
- 5 wdays for acceptance
ID
SQI
KPI
(indicative)
End of
Action report
SQI01
MPR
SQI03
KPI01
KPI03
WP. 8.6.1.1
SE-8.6.1.1-2
Working Group Meeting- Performance
SC, RfA
RfA,
Trigger
date as per request
-
MPR
-
WP.8.6.1.2
SE-8.6.1.2-1
Working Group Meeting – Attendance
SC, RfA
RfA,
Trigger
date as per request
-
MPR
-
WP.8.6.2.1
DLV-8.6.2.1-1
Training/workshop/demo – Preparation
material
SC, RfA
RfA,
Trigger
Date of the
Training/Workshop/Demo – 5
wdays, for review
Date of the
Training/Workshop/Demo – 2
wdays, for acceptance
ID
End of
Action report
SQI02
–
SC, RfA
RfA,
Trigger
date as per request if requested date
is more than 3 weeks from date of
request, otherwise MA;
-
MPR
-
SC, RfA
RfA,
Trigger
date as per request if requested date
is more than 3 weeks from date of
request, otherwise MA;
-
MPR
-
WP. 8.6.2.1
SE-8.6.2.1-2
Training/workshop/demo
Performance
WP. 8.6.2.2
SE-8.6.2.2-1
Training/workshop/demo – Attendance
Page 111 of 244
KPI02
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP. 8.6.2.2
Deliverable
DLV-8.6.2.2-2
Deliverable Title
Order
Request Planning
mechanism mechanism
Training/workshop/demo – Attendance
Report
SC, RfA
Delivery Acceptance
Mechanism Mechanism
RfA,
Trigger
Date of Training/workshop/demo +
5 wdays for review
Date of Training/workshop/demo +
10 wdays for acceptance
ID
MPR
SQI
KPI
(indicative)
SQI02
KPI02
WP. 8.6.2.3
SE-8.6.2.3-1
Training/workshop/demo – Hosting
Facilities and infrastructure: Meeting
room up to 40 persons in contractor’s
premises
SC, RfA
RfA,
Trigger
date as per request if requested date
is more than 3 weeks from date of
request otherwise MA;
-
MPR
-
WP. 8.6.2.4
DLV-8.6.2.4-1
Training/workshop/demo – Agenda
SC, RfA
RfA,
Trigger
Date of the
Training/workshop/demo – 8 wdays,
for review
ID
no
SQI02
RfA,
Trigger
Date of the
Training/workshop/demo – 5 wdays,
for review
ID
RfA,
Trigger
Date
of
Training/workshop/demo
wdays, for acceptance
ID
RfA,
Trigger
Date of the mission – 15 wdays, for
review, if mission date is more than
3 weeks from date of request,
otherwise MA.
ID
RfA,
Trigger
Date of the mission – 5 wdays, for
review
ID
WP. 8.6.2.4
WP. 8.6.2.4
WP.8.6.3
WP.8.6.3
DLV-8.6.2.4-2
DLV-8.6.2.4-3
DLV-8.6.3.-1
DLV-8.6.3.-2
Training/workshop/demo – Briefing
Training/workshop/demo
minutes and evaluation
– Detailed
Mission – Preparation of agenda
Mission – Briefing
Page 112 of 244
SC, RfA
SC, RfA
SC, RfA
SC, RfA
+
the
10
KPI02
no
SQI02
KPI02
MPR
SQI02
KPI02
no
SQI03
KPI03
no
SQI03
KPI03
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
WP.8.6.3
Deliverable
DLV-8.6.3.-3
Deliverable Title
Order
Request Planning
mechanism mechanism
Mission – Preparation of material
SC, RfA
RfA,
Trigger
Date of the mission – 5 wdays, for
review
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
ID
no
-
Date of the mission – 2 wdays, for
acceptance
WP.8.6.3
SE-8.6.3-4
Mission – Performance
SC, RfA
RfA,
Trigger
Average duration of 2 wdays, date
as per request if requested date is
more than 2 weeks from date of
request, otherwise MA;
-
MPR
-
WP.8.6.3
DLV-8.6.3-5
Mission – Report
SC, RfA
RfA,
Trigger
Date of the mission + 10 wdays, for
acceptance
ID
MPR
SQI03
WP.8.8.1
SE-8.8.1-1
Call availability outside working hours
SC, RFA
SC, RFA
WP.8.8.2
SE-8.8.2-1
Extended time coverage
SC, RFA
RFA,
Trigger
WP.8.9.1
SE-8.9.1-1
Major upgrade of the COTS including
adaptation of the application
SC, RFA
SC, RFA,
Trigger
Continuous
WP.8.9.2
SE-8.9.2-1
Minor upgrade of the COTS including
adaptation of the application
SC, RFA
SC, RFA,
Trigger
Continuous
WP.8.9.3
SE-8.9.3-1
Minor upgrade of the COTS excluding
adaptation of the application
SC, RFA
SC, RFA,
Trigger
Continuous
Page 113 of 244
Continuous
Trigger or MA
KPI03
-
-
-
ID
MPR
-
-
MPR
-
-
MPR
-
-
MPR
-
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SERVICE & DELIVERABLE CATALOGUE
Work
Package
Deliverable
Deliverable Title
Order
Request Planning
mechanism mechanism
WP.8.9.4
SE-8.9.4-1
Upgrade of the COTS patches
excluding adaptation of the application
SC, RFA
SC, RFA,
Trigger
Continuous
WP.8.9.1
DLV-8.9.1-1
Upgraded FAT environments COTS
and Software release
SC, RFA
SC, RFA,
Trigger
Submitted as per SC, RFA, Trigger
WP.8.9.2
DLV-8.9.2-1
Upgraded FAT environments COTS
and Software release
SC, RFA
SC, RFA,
Trigger
Submitted as per SC, RFA, Trigger
WP.8.9.3
DLV-8.9.3-1
Upgraded FAT environments
SC, RFA
SC, RFA,
Trigger
Submitted as per SC, RFA, Trigger
WP.8.9.4
DLV-8.9.4-1
Upgraded FAT environments
SC, RFA
SC, RFA,
Trigger
Submitted as per SC, RFA, Trigger
WP.10
DLV/SE.10.x
Other services and deliverables in the
scope of the contract.
SC, RfA
SC, RfA
As per SC or RfA
Table 2 – Services & Deliverables
Page 114 of 244
Delivery Acceptance
Mechanism Mechanism
SQI
KPI
(indicative)
-
MPR
-
ID
End of
Action report
or MPR
End of
Action report
or MPR
End of
Action report
or MPR
End of
Action report
or MPR
SC, RfA
As per SC,
RFA
ID
ID
ID
SC, RfA
As per SC,
RFA
As per SC,
RFA
As per SC,
RFA
As per SC,
RfA
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5. Price list Requirements
The various price elements have to be determined by the contractor such that they guarantee a correct
team capacity and quality result. The overall team size is by nature variable to some extent and will
require a solid demand and capacity management at contractor level. The information in this chapter has
to be considered together with the staff requirements as expressed in chapter 6.
The following types of price elements are to be considered in this context:

Fixed Price elements must cover the correct resource capacity for the covered
service(s). An example is the correct size of the overall management team making
sure that all required roles are staffed sufficiently;

Price elements per man-day per profile will be used for the services which cannot be
ordered by means of service specific quantities. These price elements are mainly
applicable to services which cannot be defined in advance in terms of duration of the
required activities. Examples are the production of artefacts for the inception phase of
a new IT Project and building the Agile product backlog of a new release during the
Release Inception Sprint. As these proposals are subject to a more subjective
assessment, mechanisms will be put in place to measure the contractor’s productivity
for these types of service complemented with benchmarking;

Service specific quantity price elements are used wherever possible to reflect as
closely as possible the nature of the service to be provided. It is the responsibility of
the contractor to determine the price in function of the expected productivity for a
given period in time. Examples of these price elements are incidents to resolve,
defects to repair, requests for change to assess, releases to manage, etc.

Fixed-Price elements per person and day of travel.
The different price elements must cover the cost of the following:

All meetings with the Commission and its stakeholders; no specific provision will be
made for meetings;

The indirect costs resulting from the internal team organisation unless this is explicitly
covered by a price element of this Technical Annex. This covers the hierarchical
structure in function of the size of the overall and specific teams to setup and to
maintain;

The indirect costs due to the interaction model with the stakeholders (refer to
interaction model as explained in section 12.16.2.23) unless this is covered explicitly
by a price element of this Technical Annex;

The specific internal QC activities related to complete the possible review cycles of a
deliverable:
o
Provide the author’s position on technical and quality review comments, given by the
Commission and/or any other party involved in the project, on deliverables submitted
for review to the Commission,
o
Participate in the review meeting(s) to clarify the author’s position on review
comments and reach agreement on implementation of the review comments (either in
the Commission’s premises or by conference call), and implement the review meeting
decisions in the relevant deliverable.
o
The following services must be made available at no additional cost as they are
considered being part of the standard available services of the tenderer (please refer to
chapter 8 for more information on infrastructure and tools):
Page 115 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.1

Office infrastructure;

Development labs at the contractor premises;

Knowledge management tools.
IT projects and support
DG TAXUD is managing IT projects which are of different nature and which have a different cost
structure:

New IT projects consist of building new IT systems or applications. These projects
can be subject to software development or not. The latter is the case when the Member
States are fully responsible for the software development, its deployment and
operation follow-up. Existing IT systems such as NCTS, ECS and ICS can be taken as
examples. For these kinds of projects DG TAXUD is responsible to produce the
required common specifications, including conformance test specifications. These
services will be ordered based on the estimates of the contractor and by using the manday prices of the applicable staff profiles. The OD budget provision is the most
commonly used budget provision for these kinds of activities;

IT maintenance projects consist of the implementation of functional or technical
evolutions of the existing IT systems and applications.
IT maintenance interventions are not considered as planned projects but as maintenance activities
triggered by unplanned functional, technical or operational needs.
Furthermore, the IT projects and support team will have to manage the support services. The activities to
manage are of a different nature than managing IT projects but require a solid knowledge of the various
IT aspects to support an operational excellence, to guarantee a fluid transition and to support the internal
team in an effective way.
The above is elaborated into more detail in the following section by describing the ‘Software
development categories’ mechanism which will be applicable to all IT projects and the different
applicable costing structures. These costing structures are split into:

“New IT projects” costing structure;

“IT management and architects” costing structure;

“IT maintenance projects” costing structure;

“IT maintenance interventions” costing structure;

“IT support” costing structure.
5.1.1
Software development categories
The prices applied in the software development are mostly based on IFP and SNAP points. Prices for
new development and for maintenance are to be distinguished. For new developments, the complexity of
developing high available information systems can be factored in. For maintenance activities, an
increase of productivity is expected over the duration of the contract. Man-day pricing is limited to some
activities that do not fit into IFP and SNAP pricing.
5.1.1.1
High availability DG TAXUD operational capabilities
DG TAXUD has defined in MASP-C rev. 2019 its project for provisioning high availability
infrastructure capabilities for the hosting of EU Customs systems components and IT services. See
project fiche 4.7 in [REF DOC MASP-C]. This work is currenty being performed for the Taxation
systems.
In a nutshell, the main objective is to establish standardised high availability (HA) capabilities that can
be mapped to predefined service levels. As a result all hosted applications can be assigned according to
Page 116 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
their criticality classification, appropriate HA characteristics. Three distinct HA service levels are
defined: Bronze, Silver and Gold. A fourth category namely ‘best effort’ is defined for unclassified
applications or information systems. This category applies by default in case the Bronze, Silver and
Gold service levels are not agreed upon for the particular hosted application.
A modernisation program is ongoing that will enable the provision of further improvements that will
drastically improve HA.
The following table shows the objectives for each individual Information System in terms of HA
according to the planned availability levels (Bronze/Silver/Gold) until 2022. The last column, Q3 2022,
is conditional to funding availability in Q1 2021:
Service name
Best effort
Bronze
Silver
Gold
4th Q 2015
4th Q 2017
3rd Q 2022
Service start
N/A
99.4%
99.6%
99.8%
High Availability
objective
N/A
13 h
9h
4h 30m
Max. downtime
(per 3 months)
The realisation of the respective availability levels are not solely the responsibility of the SOFT-DEV
contractor. They depend on infrastructure investments, and organisational procedures that span the
SOFT-DEV and ITSM contractors. Nonetheless, it is the responsibility of SOFT-DEV to ensure an
appropriate design of the information systems concerned, to develop and test the systems such as to
ensure that the HA requirements are met.
Experience has shown that there is a correlation between the effort of the software provider and the HA
target of the application.
DG TAXUD sees this correlation as an indicator of additional effort, and foresees that the contractor can
apply a corresponding cost increase on the development activities for the concerned information
systems. It should be noted that the cost increase applies to those components of the information system
for which the HA requirements apply, in those cases where the HA requirement only applies for part of
the system. E.g. an information system may have a data collection component and a data analysis
component, the former component having a higher HA requirement than the latter.
5.1.1.1
Initial sizing and availability category.
The list of existing IT applications and the association to its availability category is established for its
initial application by DG TAXUD (refer to Tender Specifications - Part B (Terms of Reference), section
6.1 Portfolio Overview’). During the takeover, the contractor will calculate the functional size of the
application. The SOFT-DEV contractor must produce an analysis report counting the FSP (IFP and
SNAP) points, which will be reviewed by TAXUD. TAXUD determines the availability category.
5.1.1.2
Change of availability category
At each Specific Contract, the list of existing IT applications and the association to its high availability
category is established.
The agreed list will be applicable for the complete duration of the Specific Contract in which the
applicable services are to be performed.
A given IT application may change from availability category as determined by DG TAXUD. DG
TAXUD will determine as of which date such change applies.
5.1.1.3
Increase of productivity for IT maintenance project activities
The tenderer must propose in its offer an evolution of the productivity rate related to the FSP (IFP and
SNAP) price applicable to IT maintenance projects activities. This must be the consequence of
maintaining a stable team with an increased experience and knowledge of the IT applications resulting
in an increased productivity during the contract lifecycle for each category. The tenderer will provide
productivity rates per year to demonstrate this.
5.1.1.4
Man-day pricing
Exceptionally, some projects do not fit well into the Function point and SNAP based model that is the
norm. For some new IT projects or IT maintenance projects, software development is not applicable,
Page 117 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
typically this is the case for the elaboration of distributed systems without a central component (other
than supporting applications). Some projects may relate to infrastructure components, which are
atypical. For these IT projects or IT maintenance projects the activities will be ordered based on the
estimates and by using the man-day prices of the applicable staff profiles (refer to PE12 and PE13).
At the time of writing this Invitation To Tender all the Taxation CIs and the following existing Customs
CIs are developed using man-days:
 New Computerised transit System (NCTS)
 Export Control System (ECS)
 Import Control System (ICS)
 Standard SPEED Test Application (SSTA)
 HTTP Bridge (software component of the TATAF framework)
 SPEED2 platform
 CSI Bridge
 Surveillance 3
 ICS2 Analytics
5.1.2
New IT projects costing structure
The contents and size of all activities to be performed for a new IT project are per definition not known
at the start.
The inception phase of a new project and Release Inception Sprints will be managed based on the
estimates and by using the man-day prices of the applicable staff profiles (refer to PE12 and PE13). The
result of the inception phase must provide enough information to ‘’determine the FSP (IFP and SNAP)
size, or exceptionally to determine if (part of) the application will be developed under man-day pricing.
5.1.2.1
New IT projects based on FSP (IFP and SNAP)
This is the default way of developing software. The following approach is followed:

As a result of the inception phase, the estimated number of FSP (IFP and SNAP) will
be calculated, and the High Availability requirements are determined by the
Commission.

After the inception phase, the subsequent activities will be ordered according to the
applicable methodology. At the time of writing this Invitation To Tender new IT
projects are developed according to processes and procedures as described in the
current version of the TEMPO methodology, being updated for the Agile
methodology described in section 3.3 of the Tender Specifications - Part B (Terms of
Reference). The provisional global project price will be used to cover the cost of the
ordered activities.

Once all information is available to determine the definitive number of FSP, the exact
project price is determined. For the remaining activities to be ordered, including the
last payment based on the acceptance of the delivered software, the exact project price
will be used to cover the cost of the ordered activities.

Note that, by common agreement, it is also possible to use the estimated number of
FSP for a fixed project price for the initial development. In such case, the definitive
number of FSP will still need to be determined, in view of further maintenance
activities.
Page 118 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
The following project productivity table is part of the sheet “new IT projects” of the price table and must
be filled out by the tenderer.
IT project lifecycle main activity
Productivity rate expressed in percentage
per main activity
Overall management (PE.2)
IT analysis and design (WP.6)
IT build, integration and test (WP.7)
Total IT project scope
100
The basis of the total project price calculation is the FSP productivity rate (expressed in man-days)
which is to be provided by the tenderer in the price table, sheet “new IT projects”. The number of FSP
counted will be converted to man-days according to this productivity rate and will cover the overall
management, IT analysis and design, and IT build, integration and test activities.
Each and every result in man-days will then be multiplied with the average daily price per project main
activity which is to be provided by the tenderer in the price table.
The percentages of the project productivity table can be subject to changes due to an IT transformation
(refer to chapter 10) or important changes in the applicable methodology. Once approved by DG
TAXUD, the updated percentages will be fixed in the framework contract by means of an amendment to
the contract.
5.1.2.2
New IT projects based on man-days
In case (part of) the new IT project is to be based on man-days, as decided by the Commission, all
required related activities as described in WP.6 and WP.7 are to be delivered based on the estimates and
by using the man-day prices of the applicable staff profiles (refer to PE12 and PE13).
The services can be ordered according to the FP or OD budget provisions.
5.1.3
IT maintenance projects costing structure
IT maintenance projects are triggered by the approval of a set of Change Requests by the competent
Change Advisory Board(s). These projects must be managed by the IT Competence Centre (see chapter
6) and more specifically by the IT manager and the category owners (see above). The required activities
can be covered by (1) FSP prices or (2) based on the estimates and by using the man-day prices of the
applicable staff profiles (refer to PE12 and PE13) or (3) a combination of (1) and (2).
The IT maintenance project activities are covered by the relevant FSP prices according to the
productivity rate described in section 5.4.1.3 and the required changes can be counted in FSP.
The required activities can be ordered according to the FP or OD budget Type provisions.
5.1.4
IT maintenance interventions costing structure
IT maintenance interventions are not considered as projects but can be triggered due to (list indicative
and non-exhaustive)



A minor but urgent functional enhancement;
An urgent data requirement implying a data patch for the database;
An urgent change of a functional or technical mechanism determined as the root cause
of a problem, etc.
Page 119 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
As indicated in the list above most of the ordered maintenance interventions will be of the nature
‘urgent’ and are by definition not planned well in advance.
The On Demand (OD) budget Type will be used to cover the required activities applying the man-day
prices of the applicable staff profiles (refer to PE12 and PE13).
5.1.5
IT support costing structure
The IT support services are of a Continuous or On Demand nature. Please refer to 5.2.12.1 (Continuous
support services) and section 5.2.12.2 (On Demand support services) for more details on the specific
price elements.
Although the support services can be delivered by staff of the different sub-teams, the IT Competence
Centre team and IT integration team will be the main contributors for these services. The following
specifies what price elements are applicable to these teams.
IT Competence centre team
The IT Competence Centre team will manage mainly continuous support services which will be covered
in terms of cost by the following elements. These PEs are quantity based with a guaranteed volume for a
given Specific Contract.






PE15 will cover specifications and software incident management;
PE16 will cover Requests for Information management;
PE17 will cover problem management;
PE18 will cover change management;
PE19 will cover the repair of specifications defects;
PE20 will cover the repair of software defects.
IT integration team
The IT integration team is performing other continuous support activities which will be covered in terms
of cost by the following elements:



PE21 will cover configuration management with a monthly Fixed Price;
PE22 will cover release management with a price per software release to manage;
PE23 will cover the set up, installation, operation and maintenance of the IT
Infrastructure and Tools at the DG TAXUD Data Centre with a monthly Fixed Price.
Furthermore, the applicable staff can be requested to deliver On Demand support services such as
specific service transition and operational support (refer to PE24).
5.1.6
Agile change scenarios
In the change scenarios no 2 and 3 described in section 3.3.5 “Work item priorities and change process”
of the Tender Specifications - Part B (Terms of Reference), new Work Items, unknown at Release
Inception Sprint time, are added to the release. The price of these Work Items are computed based on
their resulting FSP (IFP and SNAP) points. In order to cover the change management and inception
activities resulting from their addition, the points counted for these Work Items are multiplied by a 1.2
mark-up factor (20% increase).
5.2
Price list elements
The Annex III - Price table consists of 6 sheets. They contain price fields to be filled in by the tenderer
(blue colour), fields that are calculated by a formula based on other price information in the Price Table
(yellow colour) and fields for which the values (provisions or quantities) are fixed by DG TAXUD
(orange colour). The sheets are:
Page 120 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS

“SOFT-DEV services” is the main sheet listing all the services foreseen in the scope of this
Invitation To Tender.

The “Profiles” sheet has to be filled out by the tenderer with the proposed man-day prices for
each profile as defined in this Invitation To Tender (See section 6.2 for details on the staff
profiles). The man-day prices proposed in this sheet will be used for evaluation of the price
calculations on the “SOFT-DEV services” sheet according to the indicated coefficients. The
tenderer is requested to provide a daily rate for the staff profiles that could be requested to
work normally from the SOFT-DEV contractor’s own premises (see section 12.3 Place of
Work). Work performed during extended working hours as described in WP.8.8.2 will be
charged taking into account the multiplying factor linked to the daily rate of the profiles
concerned as defined in the pricing model.

The “FSP prices for IT maintenance” sheet has to be filled out by the tenderer with the
proposed average man-day price and the proposed productivity rate for each and every year of
the Framework Contract. The product of (average man-day rate * productivity rate) in this
sheet will be used for evaluation of the price calculations on the “SOFT-DEV services” sheet
according to the indicated number of FSP units. The High Availability coefficient will apply.

The “new IT projects” sheet has to be filled out by the tenderer with
o
Note that the average daily rate per software development category is derived from the
profiles sheet;
o
A productivity rate applicable to all three IT project lifecycle main activities,
expressed in number of man-days per FSP per software development category. Please
note that this productivity rate can be different than those filled out for the “FSP prices
for IT maintenance” sheet;
o
For each IT project lifecycle main activity the productivity rate expressed in
percentage (a number between 0 and 1) per main activity per software development
category. The sum of the three activities must be 1.
The tenderer is requested to fill in the pricing model with unit prices. For the evaluation of the offers,
the unit prices are multiplied with the coefficients indicated in the pricing model. The tenderers’
attention is drawn to the fact that these coefficients are applied only and solely during the financial
evaluation of the tenders. These figures – however they are based on the estimation of the expected
workload – do not constitute any commitment or limitation from the part of the Commission regarding
budgeted or ordered quantities of the units of the respective pricing elements. Information about
volumetric data can be found in Tender Specifications - Part B (Terms of Reference), chapter 10 IT
statistics.
The price list follows an all-inclusive approach regarding the services included in the price. The
proposed prices are to cover all activities that are related to the given (sub) Work Package, unless they
are specifically excluded by the Commission.
All price elements are linked to Work Packages. It is to be understood that the price proposed for each
pricing element contains not only the price of the activities described in the referenced Work Packages
but also the activities described in all sub-Work Packages and the delivery of all the Deliverables and
the provision of all Services linked to the given (sub) Work Package, unless it is described differently in
the price element descriptions below. These Deliverables and Services are listed in section Error!
Reference source not found..
5.2.1
PE1 - Production of all the initial deliverables
This price element covers the price for the production of the FQP (DLV.0.1-1) - including its annexes as
the External Processes, the Service catalogue (DLV.0.13-2), the Security plan (DLV.0.14.1-2), and the
infrastructure and tools baseline (DLV.8.4.1-2). The contractor will have to take over the existing FQP,
adapt it to the new requirements and to generate the SOFT-DEV specific version from the original allinclusive version as described in WP.0.1.
The related Work Packages are: WP.0.1; WP.0.13.1; WP.0.14.1; WP.8.4.1.1.
Page 121 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.2.2
PE2 – Overall Management
This price element is a monthly Fixed Price and covers the costs of the overall management services to
be delivered and the maintenance of the associated deliverables for the WP covered, as per the price list
(Annex 6). This part of the overall team is delivering services which are crucial to the correct
functioning of all staff and to the quality delivery of all requested services.
The governance used (including methodologies, standards, tools, communication, decision, escalation
and information processes) in this context will be described in the FQP linked to this Framework
Contract (See WP.0.1).
Refer to section 6.1 for more information on the team structure requirements.
The weighting used for the average calculation is only indicative. The actual composition of the profiles
ordered during the implementation of the contract may be different.
5.2.3
PE3 - PE4 - Take-over
The take-over price is composed of 2 price elements:
1.
Price Element 3 - overall take-over
This price element is a one-off Fixed Price and covers all take-over activities (refer to WP.2 and
WP.2.1) except the take-over of the IT central applications which is covered by PE4.
2.
Price Element 4 – take-over of IT central applications
This price element is a one-off Fixed Price and covers all activities to take over all IT central
applications (refer to WP.2.2).
The tenderer is reminded that the training sessions to be attended and to be given by DG TAXUD
or by a stakeholder representing DG TAXUD (the incumbent contractors, the QA contractor, the ITSM
contractors, etc.) are included in the take-over price.
The tenderer is reminded that failure to take over on time is linked to KPI81.
5.2.4
PE5 - PE6 - PE7 - Hand-over
The hand-over price is composed of 3 price elements:
1.
Price Element 5 - overall hand-over
This price element is a one-off Fixed Price and covers all hand-over activities (refer to WP.3.1)
except the hand-over of the IT central applications which is covered by PE6.
2.
Price Element 6 - hand-over of IT central applications
This price element is a one-off Fixed Price and covers all activities to hand over all IT central
applications (refer to WP.3.2). .
3.
Price Element 7 – after hand-over support
This price element covers all services/deliverables as described in Work Package WP.3.3. The
average of all profile prices is calculated to be taken into account for the evaluation of the tenders.
The activities will be ordered based on the estimate and by using the man-day prices of the
“Profiles” sheet of the Price table. The weighting used for the average calculation is only indicative.
The actual composition of the profiles ordered during the implementation of the contract may be
different
The tenderer is reminded that the training sessions to be given is included in the hand-over price.
The tenderer is reminded that failure to pass on the information and knowledge to the future new
contractor will result in non-payment of the services of the contractor during the Hand-over period.
Page 122 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.2.5
PE8 - Architecture and strategy
This price element covers all services/deliverables described under WP.4.1, WP.4.2, WP.4.3, WP.4.4,
WP.4.5 and WP.4.7
The required services are to be delivered based on the estimates and by using the man-day prices of the
applicable staff profiles.
The weighted average of the applicable profile prices is specified in the “Profiles” sheet of the Annex 6 Price table and used accordingly in the calculation of the overall price to be taken into account for the
evaluation of the tenders. The weighting used for the average calculation is only indicative. The actual
composition of the profiles ordered during the implementation of the contract may be different.
The activities will be ordered based on the estimate and by using the man-day prices of the “Profiles”
sheet of the Price table.
The required services as described in WP.4.1, WP.4.2, WP.4.3, WP.4.4 and WP.4.7 can be ordered by
DG TAXUD according to the following budget provisions: FP or OD.
The required services as described in WP.4.5 will be ordered according to the OD budget provision.
Note: The staff required to deliver the services as described in WP.4.6 are integrated in the IT projects
and support team (refer to section 6.1.6). Refer to section 5.1.2.2 for the related costing structure.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of
delivering WP.4 deliverables are considered as part of the delivery work included in this price element.
5.2.6
PE9 - Business Analysis, Modelling and Data Integration and
Harmonisation
This price element covers all services/deliverables described under WP.5.
The required services as described in WP.5 are to be delivered based on the estimates and by using the
man-day prices of the applicable staff profiles). The services can be ordered according to the FP and OD
budget provisions.
The weighted average of the applicable profile prices is specified in the “Profiles” sheet of the Annex6 Price table and used accordingly in the calculation of the overall price to be taken into account for the
evaluation of the tenders. The weighting used for the average calculation is only indicative. The actual
composition of the profiles ordered during the implementation of the contract may be different.
For the deliverables and services marked as to be ordered via the Fixed Price mechanism in the Price
table, the Fixed Price mechanism will be the preferred mode of ordering. Nevertheless, TAXUD
reserves the right to order all activities under PE9 based on the estimate and by using the man-day prices
of the “Profiles” sheet of the Price table.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of
delivering WP.5 deliverables are considered as part of the delivery work.
5.2.7
PE10 – IT new projects
This price element is all-inclusive for all services/deliverables described in WP.6 and WP.7 covering
only the activities which can be counted in FSP.
This price element is a Fixed Price element which is determined in 2 steps:
1.
After the inception phase of a new project, the Commission will be provided by the SOFTDEV contractor with all information to be able to determine an estimated number of FSP. The
Commission will determine the High Availability category. This will result in a provisional
project price;
Page 123 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
2.
The exact project price is established when the definitive FSP points are determined.
Note that, by common agreement, it is also possible to use the estimated number of FSP for a fixed
project price for the initial development. In such case, the definitive number of FSP will still need to
be determined, in view of further maintenance activities.
5.2.8
PE11 – IT maintenance, architecture support and integration
management
This price element is a monthly Fixed Price and covers the costs of the activities for IT maintenance,
architecture support and integration management. The cost will be based on the daily prices of the
applicable staff profiles
The IT management staff is managing activities as described under WP.6, WP.7 and WP.8. The support
architects are managing the activities as described under WP.4.6.
Refer section 6.1.6.2 for more information on the team structure requirements and activities covered for
IT maintenance, architecture support and integration management.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of
delivering these services are considered as part of the delivery work.
5.2.9
PE12 - IT analysis and modelling
This price element covers all services/deliverables described under WP.6.
The weighted average of the applicable profile prices is specified in the “Profiles” sheet of the Annex 6 Price table and used accordingly in the calculation of the overall price to be taken into account for the
evaluation of the tenders. The weighting used for the average calculation is only indicative. The actual
composition of the profiles ordered during the implementation of the contract may be different.
The activities will be ordered based on the estimate and by using the man-day prices of the “Profiles”
sheet of the Price table.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of
delivering WP.6 deliverables are considered as part of the delivery work.
5.2.10 PE13 - IT build, integrate and test based on man-day profile prices
This price element covers all services/deliverables described in WP.7 but covers only the activities
which cannot be counted in FSP.
The weighted average of the applicable profile prices is specified in the “Profiles” sheet of the Annex 6 Price table and used accordingly in the calculation of the overall price to be taken into account for the
evaluation of the tenders. The weighting used for the average calculation is only indicative. The actual
composition of the profiles ordered during the implementation of the contract may be different.
The activities will be ordered based on the estimate and by using the man-day prices of the “Profiles”
sheet of the Price table.
All meetings held by the SOFT-DEV contractor with the Commission for the purpose of
delivering WP.7 deliverables are considered as part of the delivery work.
5.2.11 PE14 - IT maintenance projects based on FSP prices
Release Inception Sprints for Agile projects or equivalent release inception activities for non-Agile
projects will be managed based on the estimates and by using the man-day prices of the applicable staff
profiles.
The FSP price element is all-inclusive for all services/deliverables described in WP.6 and WP.7 but
covers only the activities which can be counted in FSP. This means that the price per FSP will not only
cover the programming and testing activities (WP.7) but as well the update of all existing specifications,
Page 124 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
automated tests, corrections, code and design quality control and remediation measures and Transition
Sprint activities (WP.6 and WP.7). All-inclusive means as well that all activities must be covered to
produce the new release to be delivered, including all tests which are needed to guarantee the required
quality, even if this means the full execution of the existing test plans.
The tenderer will provide a fixed price per FSP, based on an average productivity in man-days per FSP
and an average man-day rate (mix of the rates of the staff that is necessary to deliver the required
services). All WP.6 and WP.7 activities subject to FSP counting will be automatically linked to its
related FSP price (meaning all-inclusive price element).
5.2.12 Support services
The support services are covering a wide range of services and will be ordered via one or several
Specific Contracts. These services are to be setup such that they can be ordered by DG TAXUD to
provide the services in a “continuous” mode or “on demand”.
5.2.12.1 Continuous support services
These services must be always available and are crucial to the overall correct functioning of the IT
services for which DG TAXUD is responsible for.
Price elements under “Continuous services” target to acquire a certain capacity from the contractor to
provide the service of the day-to-day activities whilst being able to level out peak activities.
The Commission will estimate, at each Specific Contract for continuous services, the volume of price
elements PE15, PE16, PE17, PE18, PE19, PE20, PE22 (i.e. the number of quantities of the related price
elements) to include in the yearly Specific Contracts. The resulting fixed price is due by the
Commission even if the ordered quantities are under-consumed The resulting fixed price is due by the
Commission even if the ordered quantities are over-consumed up to 10%. Should however an overconsumption of a price element of more than 10% occur, DG TAXUD will issue an RfA covering the
additional quantity over 100% of this price element anticipated until the end of the current continuous
services’ Specific Contract. In this case, only the additional quantity effectively consumed at the end of
the related continuous services’ Specific Contract, will be paid on top of the initial fixed price amount
included in the Specific Contract.
The consumption of price elements is to be monitored by the SOFT-DEV contractor and to be reported
on a regular basis (see WP.0.7 on weekly and monthly reporting). The consumption of the quantities is
therefore subject to revision and consequently acceptance or rejection by the Commission. Only the
consumption accepted by the Commission is considered as actual consumption. The reporting also
allows assessing the volume of continuous services needed for subsequent continuous services Specific
Contracts.
The other price elements being part of the continuous support services are PE21, PE23 and PE35 which
are monthly Fixed Price elements.
5.2.12.1.1
PE15 – Specifications and software Incident management
This price element covers all services/deliverables described under WP.8.1.1.1. and is based on a price
per incident.
5.2.12.1.2
PE16 – Requests for Information management
This price element covers all services/deliverables described under WP.8.1.1.2. and is based on a price
per Request for Information.
5.2.12.1.3
PE17 – Problem management
This price element covers all services/deliverables described under WP.8.1.2. and is based on a price per
problem.
5.2.12.1.4
PE18 – Change management
This price element covers all services/deliverables described under WP.8.1.3. and is based on a price per
Request for Change.
Page 125 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.2.12.1.5
PE19 – Repair specifications defects
This price element covers all services/deliverables described under WP.8.1.4.1. and is based on a price
per specification defect.
All artefacts (specs, s/w, etc) produced by the SOFT-DEV contractor have to be maintained freeof-charge by the SOFT-DEV contractor until the end of the Framework Contract. Only the taken-over
artefacts are subject to corrective maintenance payment for the first two (2) years following the
completion of the take-over and all the artefacts, after those 2 years, with the scope outside the
guarantee period.
.
Tenderers are reminded of the guarantee period as defined in the model Framework Contract (Article
5.3.4, part III of the contract) during which corrective maintenance (repair) – free of charge for the
Contracting Authority - will be applicable for the specifications (WP.6) as well as the build and test
(WP.7) including qualification testing (WP.7.5.4.).
5.2.12.1.6
PE20 – Repair software defects
This price element covers all services/deliverables described under WP.8.1.4.2. and WP.7.5.4 and is
based on a price per software defect.
All artefacts (specs, s/w, etc) produced by the SOFT-DEV contractor have to be maintained freeof-charge by the SOFT-DEV contractor until the end of the Framework Contract. Only the taken-over
artefacts are subject to corrective maintenance payment for the first two (2) years following the
completion of the take-over and all the artefacts, after those 2 years, with the scope outside the
guarantee period.
Tenderers are reminded of the guarantee period as defined in the model Framework Contract (Article
5.3.4, part III of the contract) during which corrective maintenance (repair) – free of charge for the
Contracting Authority - will be applicable for the specifications (WP.6) as well as build and test (WP.7)
including qualification testing (WP.7.5.4.).
5.2.12.1.7
PE21 – configuration management
This price element covers all services/deliverables described under WP.8.2.
5.2.12.1.8
PE22 – Manage a given release
This price element covers all services/deliverables described under WP.8.3 and WP.8.4.1.
5.2.12.1.9
PE23 – setup, install, operate and maintain the IT Infrastructure
and Tools at the DG TAXUD Data Centre
This price element covers all services/deliverables described under WP.8.4.1.
5.2.12.1.10 PE35 – call availability outside working hours
This price element is to cover the services described under WP.8.8.1. It covers the availability of
assigned staff for a given critical IT system/application to be on call outside working hours.
5.2.12.2 On Demand support services
These support services will be triggered by DG TAXUD whenever required.
5.2.12.2.1
PE24 – Service transition and operational support
This price element covers all services/deliverables described under WP.8.5.1.
Page 126 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.2.12.2.2
PE25 – Conformance testing support
This price element covers all services/deliverables described under WP.8.5.2.
5.2.12.2.3
PE26 – Support to the National Administrations
This price element covers all services/deliverables described under WP.8.5.3.
5.2.12.2.4
PE27 – Technical review of the deliverables of other contractors
This price element covers all services/deliverables described under WP.8.5.4.
5.2.12.2.5
PE28 – Translations
This price element covers all services/deliverables as described in Work Package WP.8.5.5. The unit
price is the human translation of 1000 characters without spaces.
5.2.12.2.6
PE29 - Specific support on ARIS and/other modelling tools
This price element covers all services/deliverables as described in Work Package 8.5.6. The unit price is
½ day/person.
5.2.12.2.7
PE30 – National Administrations working group meetings and
their related subgroups – performance
This price element covers the preparation and performance of a presentation for a working group
meeting. The smallest unit covers a one day working group meeting. The related Work Package is
WP.8.6.1.1.
5.2.12.2.8
PE31 – Training, workshop, demonstration – performance
This element covers the preparation, organisation and performance of a training, workshop or
demonstration, including reporting and related planning. The smallest unit that can be ordered is ½ day
by topic, person of trainer, audience. The related Work Packages are WP.8.6.2.1 and WP.8.6.2.4.
Repetitive performance of the same material(s) does not trigger multiple payments. Two training
materials are considered to be identical if the difference between the substantial part of the two materials
is not more than 20%.
5.2.12.2.9
PE32 – Training, workshop, demonstration – attendance
This price element covers the attendance of a training, workshop or demonstration, including reporting.
The smallest unit that can be ordered is ½ day/person. The related Work Package is WP.8.6.2.2.
5.2.12.2.10 PE33 – Training, workshop, demonstration – hosting facilities
and Infrastructure
This price element covers all services/deliverables as described in Work Package WP.8.6.2.3. The
smallest unit that can be ordered is ½ day.
5.2.12.2.11 PE34 – Missions within geographical Europe
This price element covers all services/deliverables as described in Work Package WP.8.6.3. The price is
fixed according to the proposal, regardless of the actual profile attending the mission. Missions have to
be ordered and approved by the Commission, organised by the SOFT-DEV contractor. The smallest unit
that can be ordered is 1 day/person. Only the days on site for performing the visit are counted.
For visits to any of the destinations listed under ‘Geographical Europe’ as defined in WP.8.6.3., a fixed
price per day per person is defined, covering all travel, lodging, per diem costs.
For exceptional cases where a visit might be requested to a 3 rd party outside those destinations, the
actually incurred prices for travel, lodging and meals will be reimbursed, subject to prior approval by the
Commission. These exceptional cases will be covered by reserve R3.
Page 127 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
5.2.12.2.12 PE36 – Extended time coverage – ad hoc
This price element covers all services/deliverables as described in Work Package WP.8.8.2. The
weighted average of all profile prices modified by the multiplication factor is to be taken into account
for the evaluation of the tenders. The activities will be ordered by using the man-day prices of the
“Profiles” sheet of the Price table, taking into account the proposed multiplication factor for activities
outside normal working hours. The weighting used for the average calculation is only indicative. The
actual composition of the profiles ordered during the implementation of the contract may be different.
5.2.12.2.13 PE37 – Shipping of hardware equipment
This price element covers the shipping of hardware purchased under Work Package WP.8.4.3. The cost
for shipping the IT equipment using a specialised IT transporter offering full Insurance will be covered
by RfA. The shipping costs are to be expressed by the tenderer as a matrix of prices in sheet “Shipping
costs” of the Price table. Prices are to be defined based on insured value and weight for a shipment to
the DG TAXUD datacentre.
The average of these prices will be used in the evaluation of the tenders. The actual price of ordering the
service will be based on the value and the weight of the package as it is indicated in the “Shipping costs”
sheet of the Price table.
5.2.12.2.14 PE38 - Repair COTS software defects
This price element covers all services/deliverables described under WP.8.1.5. and WP.7.5.4 and is based
on a price per software defect due to an upgrade of the COTS.
5.2.12.2.15 PE39 - Upgrade a major version of a COTS and adapt the
application
This price element covers the upgrade of a major verion of a COTS as well as the adaptation of one
application to fully support it as defined in WP.8.9.1. This price element also includes WP.7.5.4
5.2.12.2.16 PE40 - Upgrade a minor version of a COTS and adapt the
application
This price element covers the upgrade of a minor verion of a COTS as well as the adaptation of one
application to fully support it as defined in WP.8.9.2. This price element also includes WP.7.5.4
5.2.12.2.17 PE41 - Upgrade a minor version of a COTS without adapting the
application
This price element covers the upgrade of a minor verion of a COTS without adaptating an application,
as defined in WP.8.9.3.
5.2.12.2.18 PE42 - Upgrade a patch version of a COTS without adapting the
application
This price element covers the upgrade of a patch verion of a COTS without adaptating an application, as
defined in WP.8.9.4.
5.2.13 PE43 – Provision of the development environment
The price element covers all services/deliverables as described in Work Package WP.8.4.1.2.
5.2.14 PE44 - Other deliverables and services in the scope of the framework
contract
The price element covers all services/deliverables as described in Work Package WP.10. The value is
automatically calculated as 10% of the subtotal of all other price elements listed above.
5.2.15 Price element block “Reserves”
The price elements in this block are defined by DG TAXUD as provisions and they are present in the
price list in order to provide the tenderers with information about the overall volume. It must be noted
Page 128 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
PRICE LIST REQUIREMENTS
that these figures cannot be considered as a commitment of DG TAXUD to engage these provisions at a
given point in time.
5.2.15.1 R1 – Reserve set by the Commission for hardware and COTS
software acquisitions for development and test environments
This reserve is expressed in 2 parts:
1.
The budgetary provision set by the Commission;
2.
The uplift percentage to be applied to the budgetary provision. This is to be filled out by the
tenderer. The uplift represents the margin the contractor applies to its purchase prices covering
all internal expenses linked to the purchase which are described under WP.8.4.3. These
purchase prices are to be proven by invoices from the vendors. DG TAXUD reserves the right
to verify/audit these purchase prices, proof of purchases.
Development equipment delivered initially to the SOFT-DEV premises is expected to be moved, at a
certain point in time, to the TAXUD datacentre - the price of the move is not included in this price
element.
5.2.15.2 R2 – Reserve set by the Commission to cover important IT
transformations
This price element covers all services/deliverables described under WP.8.7.
5.2.15.3 R3 – Reserve set by the Commission for travel and subsistence
costs for missions outside the geographical Europe
All meetings/activities at the Commission’s premises (Brussels and Luxembourg) and/or at any other
contractor’s premises within a distance of ≤ 50 km of the Commission’s premises are to be included in
the quoted prices for services, including the travel and subsistence costs.
All “out of premises” activities of the contractor, other than those addressed in the previous paragraph,
will be covered by applying the proposed price per day and per person (see PE34) for missions to
geographical Europe.
When an event implies travel and subsistence costs within geographical Europe, the SOFT-DEV
contractor must communicate to the Commission the location, the number of persons concerned and the
duration of the activity e.g. Mission) and request its approval prior to the foreseen travel.
In the exceptional case where a mission to a 3rd party outside geographical Europe would be requested,
the mission order must in addition provide a cost estimate, and detailed expenses of travel and
subsistence must be included with the invoice.
The Commission will allocate the budget to cover the travel and subsistence costs for missions outside
the geographical Europe.
5.2.15.4 R4 – Reserve set by the Commission for overall contingency
This price element of 20% of the overall contract cost covers price indexation and unforeseen needs.
Page 129 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
6. Staff Requirements
6.1
Team Structure
The contractor has the responsibility to set up an adequate team organisation in order to:
-
-
Perform the activities and deliver the products and services in full compliance with the quality
requirements;
Function as one team internally and externally; in case of a consortium delivering services, by no
means its internal organisation shall be exposed operationally to DG TAXUD/the Commission, its
contractors and users of the services during the implementation of the framework contract.
Guarantee a uniform approach in terms of methodology and technical implementation. This is in
particular of importance should the contractor consist of a consortium of companies. All consortium
partners must act as one entity.
The team composition must ensure:
-
The presence of an hierarchical structure in function of the size of the overall team and the different
activities;
A correct balance of concentration and distribution of the acquired knowledge;
The availability of expert knowledge on the fundamental horizontal elements (architecture,
delivery, etc.);
The existence of a stable core team for continuous services.
The team structure in the figure below is not imposing an organisation into the lowest level of detail but
does define the expected high level structure.
Overall Management
Quality
PMO
- administration/contracts/planning
- Service Level Management
Business Analysis,
Modelling and Data
Integration and
Harmonisation
Architecture and
Strategy
Security
IT Projects and Support
IT Competence Centre
IT Maintenance,
Architecture Support and
Integration Management
IT new Projects
Data Analytics
Agile Team Coordinator
and Proxy Product Owner
IT Testing
Figure 1 – Team structure
6.1.1
Overall management
This team component is the horizontal management layer and performs the following functions (list
indicative and not exhaustive):
-
Overall programme and contract management. The overall management team will take the
responsibility for all services to be delivered by this framework contract. The team will set up a
strong internal team which acts as a team internally and towards DG TAXUD and its
stakeholders for this framework contract. It will furthermore apply effective risk management
and improve the overall working of the team with continuous improvement proposals;
Page 130 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
-
Programme Management Office. The involved staff will manage all contractual, planning and
Service Level activities. This part of the management team will manage all the ‘input’ of the
framework contract and all indicators required to follow up productivity and quality. It will act
pro-actively in having day-to-day contacts with all parts of the overall team for all related
aspects;
-
Risk Management considering all services of the Framework Contract;
-
Continuous Service Improvement linked to all services of the Framework Contract;
-
Knowledge management. The involved staff must collect all important information for the
framework contract and organize the activities in the different teams such that this is done at all
levels. The agreed tools, such as the Application Lifecycle Management platform (refer to
section 8.5.1) for project knowledge management, will be used in order for the gathered
knowledge to be available to the SOFT-DEV internal team, DG TAXUD and its stakeholders
for this framework contract and possible successors.
6.1.2
Quality
The quality staff must act independently from the SOFT-DEV management. This team component
performs the following functions (list indicative and not exhaustive):
-
Quality assurance. The involved staff will maintain the FQP and the contractual OLA (refer to
section 7.3.1 for more details on the OLA requirements) as the main quality specifications for
this framework contract. It will furthermore setup internal required QA processes to guarantee
an overall quality result;
-
Quality Control. The involved staff will control at horizontal level if all quality processes,
procedures and requirements are correctly implemented. For instance, it must be ensured that
final technical and financial offers reach an optimal quality level in order to avoid any delay in
the preparation of the related RfAs/SCs.
6.1.3
Security
The security staff must act independently from the SOFT-DEV management. This team component
performs the following functions (list indicative and not exhaustive):
-
Security management. The involved staff must produce the required security plans, implement
the security requirements and control that these are correctly followed by all teams.
6.1.4
Business Analysis, Modelling and data integration and harmonisation
This team component is supporting the DG TAXUD unit responsible for the customs and taxation
processes and is at the forefront of the IT projects.
The involved staff will support DG TAXUD to prepare customs and taxation business cases, the
business process models and data integration and harmonization in different levels of detail and validate
its correct implementation in the related IT systems and applications.
Furthermore, the business consultants, business analyst modellers and data integration and
harmonization modellers can act as consultants for the IT project teams in order to facilitate the correct
preparation of the IT specifications on the basis of Business Specifications.
6.1.5
Architecture and Strategy
The different architecture activities which are described in WP.4 will be performed by different staff
profiles and different teams.
The architecture and strategy team component will perform mainly the activities which are of customs
and taxation enterprise level and strategic nature. These activities are mainly linked to (but not
exclusively) the IT strategy for EU Customs, the IT Portfolio and Master Plan, the architecture
Page 131 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
framework and related methods, the enterprise architecture for EU Customs, the use of ARIS and other
architectural tools.
The application and service architectures to be implemented can be designed from a conceptual
viewpoint in this team but, once approved for implementation, will be further managed as a project
under the responsibility of the IT project and support team.
An Enterprise Architect and several solution architects which will manage the different layers of
implementation of the application and service architectures are part of the “IT Maintenance,
Architecture Support and Integration Management” team within the IT project and support team.
6.1.6
IT Projects and Support
This team component must include all staff functions and roles required to deliver IT artefacts on time
and according to the required quality and to provide the required support services based on a solid
knowledge.
The team is managed by the IT manager who is responsible for all IT development and support
activities.
6.1.6.1
IT Competence Centre
The involved staff of this team component must have the required knowledge on all existing IT systems
and applications and they are the main actors to implement all functional and technical evolutions and to
support the business and operations services.
The staff must be organized according to a logical split of the total IT systems and applications
portfolio. This split must result in the role of IT category owners with a further drill down to CI owners
at the level of each and every IT system and application.
The team must have an in-depth knowledge of the IT applications from a functional and technical
viewpoint, including the software source code.
The team organization must allow for reacting in a dynamic way to a variable workload. This means that
if no evolutions are planned or no specific issues are outstanding for a given IT system or application the
team must be organized such that the available staff can temporarily be switched to another part of the
portfolio.
The team will ensure the follow-up of the incidents and the problems for the IT systems and applications
in conformance and production according to the required level of criticality and priority. It will manage
all Requests for Change, mainly by producing impact assessments and assisting DG TAXUD in all
CABs to be organized.
The team will repair all defects for the IT systems and applications in conformance and production
according to the required level of criticality and priority.
The IT category owners will act as IT project managers for all functional and technical evolutions of the
existing IT systems and applications. They manage the development and testing lifecycle of these
evolutions. The IT staff implementing functional and technical evolutions of the existing IT systems and
applications will work under the responsibility of the category owners.
The relevant staff of the team can assist the Programme Management Office in producing proposals for
Requests for Action.
6.1.6.2
IT maintenance, architecture support and integration
management
Coordination of IT maintenance and support activities, of overall architecture (in the sense of WP.4.6)
coordination and integration management activities are deemed to require specific organization and
assigned staff. Sets of systems and/or applications will be grouped in categories to ensure their close
coordination.
IT manager
The IT manager has the overall responsibility of all IT project and support activities.
Page 132 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
More in particular, he/she performs the following management activities (non-exhaustive):





Act as the overall Single Point Of Contact for the 'IT maintenance, architecture
support and integration management' team;
Manage the daily team activities;
Apply effective risk, issue and change management for IT maintenance activities;
Manage all SOFT-DEV infrastructure;
Provide correct reporting on the maintenance team activities (status, progress, next
activities to perform, risks, issues, changes) via the Monthly Progress reports and the
applicable steering committees.
IT category owner
The IT category owner is managing part of the IT systems and applications portfolio and is responsible
for the IT maintenance and support activities of the category assigned to him.
The IT category owners will act as IT project managers for all functional and technical evolutions of the
existing IT systems and applications. They manage the development and testing lifecycle of these
evolutions. The IT staff implementing functional and technical evolutions of the existing IT systems and
applications will work under the responsibility of the category owners.
The assigned IT category owner will sign-off all deliverables for each and every release delivered to DG
TAXUD. At the time of writing of the Invitation To Tender the following IT categories are applicable
for Customs:







Movement systems and supporting applications
Internal applications
Risk analysis and control applications
Internet applications
Economic Operators applications
Tariff and classification applications
Special Procedures
Refer to the Tender Specifications - Part B (Terms of Reference) for the complete list of CIs which are
part of each and every category. Please note that the ‘TATAFng’ category is to be managed by the
support architects.
For the future Taxation portfolio, it may be envisaged to have three categories, containing respectively



Indirect Taxation (VAT) and Recovery systems and applications
Excise systems and applications
Direct Taxation and all other systems and applications.
The Commission will determine, at each and every Specific Contract for IT management, integration
management and support architects, the IT categories’ constitution and therefor the number of IT
category owners that will constitute the monthly Fixed Price based on the daily price of the applicable
staff profile. As a rule of thumb, a category will cover no less than 12.5% of the project portfolio in
financial terms.
Support architect role
The support architects, typically one (1) Enterprise Architect and a number of Solution Architects, being
part of the IT projects and support team will deliver the services as described in WP.4.6. Amongst other
activities, they will act as category owner of the TATAFng framework and its successor(s). This
framework is the foundation of most of the existing IT applications. These architects will act as the
guardians and the experts of the architectural solutions for the customs IT systems/applications.
Page 133 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
The architects will have a perfect knowledge of the application and service architectures to be applied
for the IT systems/applications. Furthermore, they will make sure that the IT systems/ applications will
function according to the performance and operational requirements.
Generally speaking, the architects act as consultants to the design and development staff and provide
support in case of issues.
The Commission will determine, at each and every Specific Contract for IT management and support
architects, the number of architects that will constitute the monthly Fixed Price based on the daily price
of the applicable staff profile.
Indicatively, they perform the following activities (non-exhaustive list):









Represent SOFT-DEV in the Architecture Board;
Define horizontal Architecture (principles, requirements, decisions);
Are consulted by project teams during project inception, elaboration and construction;
Ensure the proposed architecture is aligned with TATAFng and more generally with
horizontal Architecture, by performing reviews of projects architecture deliverables;
Ensure consistency of various projects architecture overviews and application models;
Perform compliance audit and follow up of project architecture, documented in audit
reports;
Category Owner of TATAF and TATAFng; these frameworks are the foundation of
most of the existing IT applications.
Are consulted for the IT Architecture artefact maintained by the Integration services
(see below).
Provide application and service architecture support and assessment upon TAXUD
request.
The assigned architect(s) will sign-off all deliverables which are of an IT technical nature for each and
every release of the existing customs IT systems/applications and for the new customs IT projects.
Integration Services
The SOA model on which the more recent applications are built imply an important inter-connectivity
and inter-dependency between applications. Particular emphasis must therefore be given to all aspects of
inter-connectivity and integration between the applications.
Integration services will be the foundation on which to build the SOA governance. It aims to exercise
control on IT services delivered to DG TAXUD.
IT integration is the glue for all IT systems and applications development and support activities.
The involved staff supports all development and testing lifecycles by managing the SOFT-DEV
development infrastructure and all test environments to be used by the SOFT-DEV contractor. It
manages the installation of all required tools. It will support especially the setup of an effective
configuration management and train all relevant staff in using the tool(s) and related processes.
The team will manage all releases starting from integration testing at SOFT-DEV level up to a correct
service transition to the ITSM contractors. As such it will act as a central component between three
stakeholders: the SOFT-DEV development team(s), the SOFT-DEV test team(s) and the ITSM
contractors.
The staff will have a deep knowledge of all technical aspects of the IT systems and applications such
that they can provide an effective support to the service transition. They are as well the first candidates
to provide specific support for service transition and operations major issues.
The team is coordinated by an Integration Services Manager, working under the overall responsibility of
the IT manager.
Page 134 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Integration Services Manager role
One (1) IT manager profile is assigned to the person responsible for the management of integration
services. In particular, he/she performs the following management activities (non-exhaustive list):





Perform overall control and coordination of the Integration Services to ensure that
integration aspects are covered in all software development/maintenance activities;
Act as Single Point of Contact for the integration service management;
Apply effective integration risk, issue and change management;
Resolve conflicts and prioritise issues;
Manage the overall compliance and IT coherence of all SOFT-DEV deliveries &
services.
Integrated Planning Manager role
One (1) IT project manager profile is assigned to the person responsible for the management of the
planning of all software deliverables. More in particular, he/she performs the following activities (nonexhaustive list):




Gather and consolidate the individual project plans created by project teams, into one
master plan for all software deliverables; the master plan will include high level
software release dependencies and serve as input for the ITOP produced by ITSM;
Identify and monitor cross-project activities and dependencies;
Review the ITOP produced by ITSM;
Act as Single Point of Contact for cross project planning.
As output, a weekly planning will be delivered to DG TAXUD and ITSM.
Integration Expert
One (1) Integration Expert profile who perform the following activities (non-exhaustive list):



Maintain the IT components dependency matrix;
Coordinate with external parties for external components (e.g. CCN2ng, UUM&DS,
T-REX, etc.);
Act as Single Point of Contact for all matters related to dependencies between SOFTDEV IT components.
As output, a monthly IT components dependency matrix will be delivered to DG TAXUD and ITSM.
Integration Testing Manager role
One (1) Test Manager profile who will perform the following activities (non-exhaustive list):





Ensure consistency of SOFT-DEV Integration and Regression Test Plans, which are
prepared by the project teams;
Plan SOFT-DEV Integration and Regression testing activities that will be included in
the master plan maintained by the Integrated Planning Manager;
Coordinate installations of software in SOFT-DEV environments for the purpose of
integration or regression testing;
Coordinate SOFT-DEV integration testing activities by project teams;
Act as Single Point of Contact for SOFT-DEV Integration and Regression testing.
As output, regression testing reports will be delivered ad-hoc to DG TAXUD and ITSM.
Integration Tester role
One (1) Test designer profile who will perform the following activities:
Page 135 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS

Perform automated regression testing in SOFT-DEV environments when there is such
a need, and report on any findings.
Note that automated tests are to be developed for each application that cover integration with other
applications maintained by SOFT-DEV as well as integration with the underlying infrastructure (CCN,
CCN2ng, SPEED2ng, UUM&DS, etc.). The specification and development of these tests is part of the
WP.6 and WP.7 activities of the applications.
6.1.6.3
Agile Team Coordinator and Proxy Product Owner
The IT project teams should be organised in a way to provide the responsiveness expected from an
Agile environment. Agile teams will have two specific roles defined as interfaces with TAXUD: the
Team Coordinator and the Proxy Product Owner.
The Team Coordinator is the technical facilitator, key contributor in planning and estimation, and
technical contact point with TAXUD. Depending on the nature of the project, it can be fulfilled by an IT
Project Manager, a Solution Architect or an Expert Developer profile.
The Proxy Product Owner is the business contact point of the project team, familiar with Customs
and/or Taxation policies and processes, facilitating the analysis work and supporting TAXUD’s Product
Owner in the identification of priorities in the product backlog. Depending on the nature of the project,
the role can be fulfilled by a Business Consultant or an IT Analyst profile. The Proxy Product Owner
will attend the National Administration Working Group or Sub-Group meetings to which the contractor
is invited.
The attendance of both the Team Coordinator and the Proxy Product Owner to the Agile “ceremonies”
is mandatory.
6.1.6.4
IT new projects
Specific IT project teams are to be set-up for entirely new IT projects with a specific IT project manager
and relevant team structure. According to the phase the project is in, the team will be staffed with the
appropriate profiles fit for purpose for the services to be delivered. The team is working under the
overall responsibility of the IT manager.
At the end of the project, the SOFT-DEV contractor must ensure that

Part of the team will continue the required maintenance activities for the first 6 months after
production date;

An effective hand-over takes place to the IT Competence Centre team such that further support
and maintenance activities are integrated into the standard processes.
6.1.6.5
IT testing
The IT test team(s) can be setup on a permanent or temporary basis. The latter can be applicable for
complete new IT projects. According to the phase the project is in, the team will be staffed with the
appropriate profiles fit for purpose for the test services to be delivered.
The test team(s) must act independently from the development team(s), including for the activities
involving the development of automated tests. Especially for the FAT execution of a full release or a
patch for which they have to make an independent assessment of the quality of the software to be
delivered to DG TAXUD.
The team(s) is/are working under the overall responsibility of the IT manager.
Page 136 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
6.1.6.6
6.1.6.6.1
Data analytics
The domains of Data Analytics and Data-Intensive Applications
Information Systems have the purpose of collecting, processing, storing and distributing data in order to
execute a transaction, provide an information for decision-making, or act as a system of record about
specific events. These goals are not necessarily mutually exclusive.
The data dimension of information systems has gained more and more importance, for two main
reasons:


Digital transformation of business processes lead to an important increase of data
volumes managed by information systems, which become data-intensive applications;
Data is no longer seen as a simple element of a business process but an asset itself,
and as such has to be managed accordingly and exploited through data analytics.
These two trends drive new areas of knowledge, which IT professionals need to know about and even
create new IT and Data roles.
6.1.6.6.1.1
Data-Intensive Applications
Data-Intensive applications need to cope reliably with a high volume of transactions, aiming for
scalability and maintainability. These are some of the technical innovations required to design, develop
and maintain data-intensive applications:




New types of data models, not only relational data models, but also document-based
models and graph models, supported by so-called NoSQL databases;
New types of data structures to retrieve data more efficiently, of data schemas to
facilitate data analytics work and new data storage approaches to aggregate data more
efficiently;
New frameworks to store and process data in a distributed architecture to cope with
big volumes of data. These frameworks establish how data replication and data
partition are done, failures at different levels of the system are dealt with, and
transactions remain consistent;
New ways to derive (process) data in batch and stream mode.
6.1.6.6.1.2
Data Analytics
Data Analytics is a vast domain that comes with many labels in the market and literature. Check the
following terminology to understand what data analytics means in the scope of this tender:




Data Mining and Data Science – While it can be argued that these terms are not
equivalent, they are considered as such, with both covering the full process of going
from raw data to a final data product (described below). Data mining was a more
popular term than data science until around 2013, when the Harvard Business Review
published the article “Data Scientist: The Sexiest Job of the 21st Century” (compare
the two terms in google trends to visualize this inversion of popularity).
Artificial Intelligence – AI aims to build systems that are able to execute behaviours
that resemble as being intelligent from an human point of view (e.g. an old example is
characters recognition, and a more modern one is driving vehicles). The data products
produced by the process of data mining and data science can have an AI component;
for instance, a dashboard is not an AI example, but a fraud detection model can be
considered as it emulates the work being done by a fraud investigator.
Machine Learning – ML is one of several domains that constitute the building blocks
of AI. ML encompasses all the families of algorithms used to learn from data
automatically. The data analytics process (see below) established by data mining and
data science uses these algorithms.
Deep Learning – DL is one type of ML algorithms, consisting of neural networks of
different architectures, but all with many layers of so-called artificial neurons (hence
Page 137 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS


the term “deep”). When big volumes of data are available, DL algorithms have proven
very useful in varied types of learning problems.
Business Intelligence – BI is a term that exists for longer and encompasses the efforts
done by Companies and other entities to organize their data and extract meaningful
information to support business decisions. Data warehouses, reporting and dashboards
are common areas of activity under this label;
Big Data – BD is a term that encompasses all the required computing frameworks to
manage data that due to its huge volumes, variety (text, image, sound, documents,
etc.) or speed (streaming data), traditional computing frameworks cannot manage.
Business Intelligence, Data Science and Artificial Intelligence are over big data
technologies, if the underlying data requires, but are also done without the need to use
big data technologies, if traditional technology can cope with the data requirements.
Data Analytics is a broad label that, for the purpose of this tender, encompasses all the areas mentioned
above:





Data repositories (data warehouses) to support BI and data science work;
NoSQL repositories to perform BI and data science on big data contexts;
BI reports and dashboards;
Data Science analysis, such as predictive modelling, clustering, graph models,
simulations, forecasting, text mining, etc.;
It is also possible that some AI solutions could be required, for instance, to automate
the processing of text documents.
6.1.6.6.1.2.1
The Data Analytics Process
The data analytics process, whether it refers to business intelligence, data science or artificial
intelligence activities, roughly follows similar steps:
Business Understanding
A business question, challenge or opportunity, must be the grounding of every analytical exercise. This
business link guides the work in the rest of the process.
Data Understanding
When the business experts and the data analysts have framed the business issue, it is possible to identify,
collect and explore the data relevant for the task.
Data Preparation
At this stage, the analyst controls the data and the link between the business issue and the data available
is well established (i.e. the data becomes a good representation of the real world that matters for the
business issue). The work now can proceed with data cleaning (e.g. treatment of missing and extreme
values), creation (e.g. aggregates and composed variables) and shaping (e.g. de-normalization,
transposition).
Data Analysis & Modelling
At this step, the analyst can analyse and model the data in some way to extract value from it. Data
Analysis & Modelling can have several meanings at this stage: dashboard, reporting, statistical outcome,
predictive model, AI feature, etc.
Validation
The business expert and the analyst must validate the outcome of the previous step from a technical and
business perspective. The IT engineer can deploy the outcome only once it is sure there are no flaws.
Deployment & Monitoring
Depending of the outcome, deployment can take several shapes of different levels of sophistication:
Page 138 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS




A report indicator or a statistical outcome that needs to be shared through an office
document (e.g. Excel, PowerPoint);
A standard report or dashboard that needs to be operationalized to be available online
at any time and updated at a certain frequency;
A clustering model that needs to run periodically on a database to identify certain
atypical behaviours (e.g. on international trade);
A scoring model that has to run real-time on new transactions and provide the score to
a business process (e.g. risk model on safe and security).
Those outcomes that require operationalization need a monitoring process to identify any changes in the
underlying conditions that can turn the analytics outcome or model outdated.
DG TAXUD should deploy some of these outcomes in the context of a data-intensive application due to
the huge volumes, variety or speed of data involved.
DG TAXUD has business needs related to all deployment scenarios described above, whether for
internal needs of the service, or in respect to Member States and Third Countries.
6.1.6.6.2
The new roles to deliver data jobs
As described in the previous section, the domains of data analytics and data-intensive applications
require the upgrade and acquisition of new skills by existing IT roles and the creation of new roles.
There are two distinctive data jobs to consider that lead to different data teams’ composition:


Data analytics jobs that don’t require operationalization of outcomes, i.e. one shot
exercises to reach a specific analytical outcome (e.g. impact assessment for some
policy proposal)
Data analytics jobs that require operationalization of outcomes, which can mean a
simple automation of a business process or the development of a data-intensive
application involving rich set of features for end users
It is important to distinguish among these two type of jobs because the IT component is clearly weaker
in the first than in the second type of job, which obviously has implications in the team to put into place.
The delivery model is another factor to define the team roles. The traditional waterfall model for the
development of information systems is not fit for purpose for data analytics jobs: the requirements are
usually more ill-defined in the beginning, less stable in time and the analytical approaches to provide a
solution aren’t always available out-of-the-box. Data analytics jobs require some component of research,
additional to development. The delivery of data analytics jobs should be iterative, interactive, and
explorative.
6.1.6.6.2.1
The roles and organization for one-shot data analytics jobs
TAXUD prescribes the following roles to deliver one-shot data analytics jobs:
TAXUD
SOFT-DEV
Business
Agile Team Coordinator (optional)
Business Experts (e.g. policy officer, legal
Officer, customs Analyst Officer)
Data Scientist
Data Engineer
Data Analyst Officer
IT
Data Engineer
Page 139 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
The one-shot data analytics jobs are not IT projects but constitute a type of service that can happen on a
continuous basis. One-shot data analytics can emerge at any time.
Since one-shot data analytics exercises are not projects, they shouldn’t require a project manager or
Agile Team Coordinator. The team should be able to plan its way through the exercise. For some more
complex exercises, an Agile Team Coordinator may facilitate the work progression.
There needs to exist a product owner, which is the role from the business side that makes sure the right
requirements are collected and stakeholders are involved. Typically, the policy officer performs the role
of product owner.
A one-shot data analytics exercise is normally an internal exercise without involvement of external
resources to TAXUD. It is possible that some exercises require external data scientists and external data
engineers to support or fill the gap for lack of internal resources.
6.1.6.6.2.2
The roles and organization for operationalized data analytics
jobs
TAXUD prescribes the following roles to deliver operationalized data analytics jobs:
TAXUD
SOFT-DEV
Business
Agile Team Coordinator
Business Experts (e.g. policy officer, legal
Officer, customs Analyst Officer)
Data Scientist
Data Engineer
Data Analyst Officer
Solution Architect
IT
Application Developer
IT project manager
Systems Engineer
Data Engineer
… and other specific roles, depending of
specific needs of the job (e.g. Data
Visualization expert, Reports Designer and
Builder)
Enterprise Data Architect
Quality Assurance
Compared to one-shot exercises, there are more IT profiles involved from TAXUD side and more
profiles from CUST-DEV3. These are required to perform the operationalization of the outcome and, if
necessary, create the data-driven application. The roles may vary depending of the application
specificities.
6.1.6.6.2.3
The collaboration of roles in data analytics jobs
The role and collaboration of these roles is succinctly described here-under through each step of an
analytics process and through the development cycle of a data-intensive application. Each role is
described in more detail on the next chapter.
Data Analytics Process
Key Roles
Business Understanding
Business Experts: business roles responsible for expressing the
business problem and provide domain expertise.
Data Analyst Officer, Data Scientist: data analytics roles
responsible for framing the business problem and devise the
Page 140 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
analytics approach.
Data Understanding
Business Experts: business roles responsible for supporting the
business interpretation of data.
Data Engineer: data management profile responsible for the
collection of data sources, first cleaning treatments and storage to
make them available for further exploration.
Data Analyst Officer, Data Scientist: data analytics roles
responsible for exploring the data and validating its quality and
business coherence.
Data Preparation
Data Engineer: data management profile responsible for
implementing non-trivial data manipulations (e.g. integration,
modelling, aggregation to create a data warehouse) if deemed
necessary.
Data Analyst Officer, Data Scientist: data analytics roles
responsible for determining and implementing data manipulations
specific to enhance the value of data for analytics (e.g. treatment of
missing values, feature engineering).
Data Analysis & Modelling
Data Analyst Officer, Data Scientist: data analytics roles
responsible for implementing the analysis required to address the
business question.
Business Experts: business roles responsible for providing the first
inputs about the data analysis developments.
Evaluation
Data Analyst Officer, Data Scientist: data analytics roles
responsible for implementing the evaluation protocol to validate
technically the analytics outcomes.
Business Experts: business roles responsible for providing the final
business validation of the analytics outcomes.
Deployment & Monitoring
Data Engineer: data management profile responsible for converting
the implementation of the data pipelines and analytics model into
production-proof code.
Data Analyst Officer, Data Scientist: data analytics roles
responsible for assisting the data engineer in the deployment of
analytics outcomes.
Data-intensive applications are more than just data. They can be composed of different layers, such as:





Infrastructure layer: stand-alone servers; distributed cluster; virtualization; containers;
Ingestion layer: batch and stream ingestion; message brokers;
Storage layer: RDBMS; HDFS; NoSQL Database; Data Warehouse;
Processing layer: distributed computing; integration and consolidation processes;
caches to speed up reads; data virtualization;
Application layer: user interfaces; API;
The analytics process supports the prototyping and development of the analytical assets deployed within
a data-intensive application. The development of the application itself requires more IT work typically
Page 141 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
organized through different phases. For identifying the key roles and collaboration, the following phases
are considered:




Define: this stands for the work of requirements definition;
Design: this stands for the work of architecture design;
Develop: this stands for the work of code development;
Deploy: this stands for the work of putting the code into production;
The role of Enterprise Data Architect has an Enterprise view of data management. It ensures that the
management of data assets within the organization follows an architecture that promotes:






Data interoperability
Metadata consistency
Data security
Data quality
Data search ability and accessibility
Platform scalability
As such, this role is not project specific, but transversal to all the organization and its initiatives.
The development of data-intensive applications should be compliant with this Enterprise Data
Architecture when it exists.
Data-Intensive Applications
Development
1.
Key Roles

Define
Solutions Architect: product management role responsible for the
requirements analysis.
This role interacts with:
‒ Business roles to collect and analyse end user requirements
‒ Data analytics roles to collect and analyse technical requirements;
2.

Design
Solutions Architect: product management role responsible for the
specification of the application architecture.
This role interacts with:
‒ Technical roles (application developer, systems engineer, data engineer,
enterprise data architect) to determine the architecture building blocks and
come up with a final design.
‒ Business and data analytics roles to gain buy-in for technological choices.
3.

Develop

Application Developer, Systems Engineer: technical roles responsible for
developing the custom development parts of the app and integrate with
acquired components.
The application developer role interacts with:
‒

4.
Deploy
Data management role (data engineer) and data analytics roles to make sure
the application code integrates well the data pipelines and analytical
outcomes.
Note: the application developer is focused on code development while the systems
engineer is focused on infrastructure and software configuration.

Application Developer, Systems Engineer: technical roles responsible for
putting the solution into production;
Note: it is good practice that the one who develops, should be responsible for
Page 142 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
putting the software into production (“if you develop crap, you will have to support
that crap!”)
In summary:
1.
The business profiles express the needs: business experts;
2.
The data analytics profiles map the needs to data and exploit the data: data analyst, data scientist;
3.
The data management profile makes sure the data is available and easy to use: data engineer;
4.
The product management profile sets the solution architecture: solutions architect;
5.
The technical profiles develop the solution: applications developer, systems engineer;
The enterprise data architect keeps a coherent view across the enterprise of how data is collected, stored
and made available for usage.
6.2
Staff Profiles
The contractor is responsible for providing the staff in order to perform the activities and deliver the
products and services defined in full compliance with the quality requirements in the current Technical
Specifications.
Due to the dimension and complexity of the tasks, the team required will be composed of qualified
personnel covering the following possible staff profiles:
#
Profile
Key Profile
Profile Code
Relevant Experience
1
Strategy Consultant
X
STC
10 years or more
2
Programme Manager
X
PM
10 years or more
3
Service Manager
X
SM
5 years or more
4
Quality Manager
X
QM
8 years or more
5
Quality Controller
QC
5 years or more
6
Security Manager
SECM
5 years or more
7
Business Consultant
8
Business Analyst Modeller
X
BAM
9
Enterprise Architect
X
EA
10 years or more
SA
5 years or more
X
BC
10 years or more
5 years or more
10
Solution Architect
11
IT Manager
X
ITM
10 years or more
12
IT Category Owner
X
ITCO
5 years or more
13
IT Project Manager
X
ITPM
5 years or more
14
IT Analyst
ITAN
5 years or more
15
IT User Interface Designer
ITUID
5 years or more
16
IT Designer
ITDS
5 years or more
17
IT Developer
ITDEV
3 years or more
18
Integration Developer
INTDEV
5 years or more
Page 143 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
19
Test Manager
20
X
TSTM
8 years or more
Test Designer
TSTDS
5 years or more
21
Tester
TST
3 years or more
22
Integration Expert
INTE
5 years or more
23
Data Scientist
DS
10 years or more
24
Data engineer
DE
10 years or more
25
Data Integration and
Harmonisation Modeller
X
X
DIHM
5 years or more
Table 3: List of Staff Profiles
These profiles will also be used in the price list of this Invitation To Tender. Any additional profiles
proposed by the tenderer will have to be mapped to the profiles listed above to support the proposed
pricing model.
The contractor must ensure that, in addition to the above mentioned criteria for each profile, the
contractor's staff remains up to date with the new technology evolutions within the respective profiles.
The contractor must ensure that the above profiles are (and will be) able to support the current and
future market technologies.
The contractor will have to staff according to the above-defined staff profiles and respecting the team
structure described in section 6.1.
The contractor must include sufficient seniority in the team that will ensure the quality delivery of the
services. This seniority is not only expressed in (number of years of) experience but also, above all, in
terms of skills and capacity to lead the teams and to keep a broad knowledge and overview of all
activities undertaken by the contractor.
The contractor will keep up to date a list of CVs and qualifications of the assigned staff, available for
on-line consultation to DG TAXUD. DG TAXUD reserves the right to verify minimal expertise
requirement defined by profile, e.g. by interviewing the staff concerned. DG TAXUD reserves the right
to request replacements of staff not in line with the present resource requirements.
By submitting an offer in response to this call for tenders, the contractor commits to ensure full
transparency towards DG TAXUD regarding its staffing. The number of staff, names, location, CVs,
qualifications, etc. must be available to DG TAXUD on-line. A staff member can be assigned to several
profiles. The relevant qualifications justifying the assignment of each staff member to a given profile
must be documented. Any change in staff (addition or removal of staff, changes in assignment of staff to
profiles) must be kept up to date with indication of start and end dates of all assignments. DG TAXUD
will fully respect the provision regarding data protection.
The contractor shall demonstrate for each person proposed in the team that his/her CV meets the
specification(s) of the profile. For every profile for which CVs are submitted, a minimum professional
experience13 is required for the area linked to his profile as indicated in table 5 above.
13
Professional experience means the number of years of relevant professional experience after the studies
(secondary school and professional studies).
Page 144 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
This means, e.g., that the IT Project Managers for whom a CV is submitted must have at least 5 years of
experience as project manager, even if they started their career as developers or in any other function.
The same rule applies to the other profiles.
For all profiles, the contractor will ensure that all staff holds the relevant technical certification,
corresponding to the assignment and to the required level of experience.
All profiles must have (or acquire within the first 8 weeks of their assignment) knowledge of TEMPO,
ITIL, Agile, SDLC and RUP.
The contractor must ensure that technical expertise that is in line with DG TAXUD’s technical
development/operations environment is sufficiently available. Expertise with all OS and COTS used by
DG TAXUD and the minimal requirements specified in the profile tables below is a must and shall be
identified clearly in the proposed CVs.
In case of staff replacement of key profiles (refer to the list of staff profiles), the contractor will
inform the Commission at least two (2) months before hand and communicate the details of the new
staff and evidence of his/her compliance with the profile for which (s)he is proposed.
In case of staff replacement, it must be noted that the tenderer is required to provide a thorough
Hand-over, at no extra cost for the Commission. Typically this could be done by providing a 10 working
days unpaid overlap between the old and new resource. The team induction and team management is to
be described in the FQP.
The contractor must ensure that his staff is fully aware of the Commission’s and contractor’s
quality system, of the quality system of the project, of the contractual OLA in place (refer to section
7.3.1 for more details on the OLA requirements), of the security requirements of the project as well as of
the goal, the context, the planning and the political importance of the service.
The artefacts delivered by the contractor shall not contain any personal data (company name,
names of individuals, functions, etc.). For all artefacts not respecting this rule, the contractor shall
provide, upon request of the Commission, an anonymized version free of charge.
Profile Description
For each of the profiles the following information regarding requirements is provided:
Profile :
<<Profile Name>> (<<Profile Acronym>>)
Overview
Overview description of the profile.
Nature of tasks
These are examples of the tasks that will be expected of a person
proposed with the required profile . This list is not exhaustive and is
to be regarded as a good indication.
Knowledge and skills
A list of the minimal knowledge and skills that a person with this
profile is expected to possess
Experience
This indicates the minimum years of experience that is required for
the area of expertise.
The tasks defined in the profile descriptions are applicable to all components and associated
systems plus all services and deliverables covered by this Framework Contract.
Page 145 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
6.2.1
Strategy Consultant:
Profile :
Strategy Consultant (STC)
Overview
Person able to define overall IT strategy, migration strategies and related
strategic plans, provide strategic advice on product and service portfolio.
Nature of tasks
Provide overall IT strategies, policies and technical advice.
Provide strategic advice on overall architecture solutions, taking into account
the current market trends, client needs or business policy goals and shaping
them into project deliverables. This task is done in close collaboration with the
System, Infrastructure and Security architects and with the business
stakeholders.
Provide the expertise and leadership necessary to help the Commission to
achieve demonstrable improvements in the development and management of
strategies related to the systems and services described in this Technical Annex.
Provide IT strategy support to the Commission through Enterprise Architecture
and portfolio management and policy and guidance analysis.
Provide the Commission with extensive strategic advice, guidance and
leadership for the successful selection, design, integration and deployment of
new systems and services.
Develop Business Cases (incl. Return on Investment and Cost/Benefit
Analyses) to support strategic recommendations.
Coordinate with all stakeholders involved in developments and deployments to
plan, document and manage strategic phases of projects.
Knowledge and skills
Strong experience with developing strategic documents.
Strong experience in the development of enterprise architecture and extensive
knowledge and experience in the practical implementation of internationally
recognised architecture frameworks and methods.
Specific knowledge of the Customs and logistics management systems is
necessary.
Experience managing systems and development projects that cover big transnational networks with string interoperability needs and strict security
requirements.
Ability to assess and document business processes and needs: including
systems; work flows; staffing; and the economic, organisational or technical
impact of each.
Excellent interpersonal, verbal and written communication skills.
Fundamental project planning and project management skills.
Strong technical, analytical and business skills.
Experience with gathering IT requirements for big trans-European projects.
Strong knowledge of current technology innovations, including SOA, Cloud
Computing, Master Data Management …
Capability of working in an international/multicultural environment, rapid selfstarting capability and experience in team working, understanding the needs,
objectives and constraints of those in other disciplines and functions.
Experience
10 years or more is required for the area of expertise
Page 146 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
6.2.2
Programme Manager
Profile :
Programme Manager (PM)
Overview
Person able to manage an overall programme such as SOFT-DEV.
Nature of tasks
Understand and implement correctly the contract requirements. This implies a
capacity to absorb in a short period a vast amount of information and to create
quickly an overall picture allowing to set-up an efficient management plan.
Create, based on the contract requirements, an efficient and effective internal
team. Make sure that the required staffs are compliant to the staff profiles and
fit for purpose.
Organise an effective resource capacity demand planning taking into account at
least a forecast of 6 months.
Create awareness of the business importance of the services to deliver
throughout the whole internal organisation.
Create and manage the required communication channels, internally and with
the relevant stakeholders.
Setup and manage an efficient PMO taking care of all planning, service level
and administrative tasks.
Validate, refine and improve the organisation and related aspects at regular
intervals. Apply effective risk management at the levels of all services and take
a pro-active attitude concerning important activities and milestones.
Manage the services at the required level by applying efficient and effective
service level monitoring.
Knowledge and skills
Leadership. The programme manager must demonstrate his competence,
provide solutions and determine the way forward for the overall team.
Communication and team building are key for the successful role of the
programme manager.
Personal and professional skills. He must have strong communication and
relationship skills. He must have a solid IT background in the domain of
complex information systems.
He must be able to build a vision for the future based on his knowledge of
similar programmes.
Methodology and technology. He must have a good overall knowledge of
business process management, enterprise architecture and IT project
development and support.
Ability to chair meetings and to give presentations.
Ability to participate in multi-lingual meetings, good communication skills.
Knowledge of customs processes and logistic chain processes in general are
considered as an asset.
Capability of working in an international/multicultural environment.
Experience
6.2.3
10 years or more is required for the area of expertise
Service Manager
Profile :
Service Manager (SM)
Overview
Person able to ensure that the required services are delivered according to
the quality plan (FQP) and according to quality levels agreed in the
contractual Operation Level Agreement (OLA).
Page 147 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Nature of tasks
Manage all services subject to service levels with activities such as statistical
reporting, alerts, trend analysis, …
Overall quality follow-up and escalation towards the Commission of all service
related activities and their related quality indicators.
Coordination with all involved stakeholders for all service related activities.
Coordination with the quality manager and quality controller for the contractual
Operation Level Agreement (OLA) aspects linked to this Framework contract
and reporting.
Knowledge and skills
Assistance and coordination with the other contractors for all delivery,
transition and operational aspects.
Ability to participate in meetings, good communicator.
Good knowledge of the applicable quality plan and contractual OLAs.
Proven experience in carrying out similar services.
Proven experience in the usage of Service Management related tools
Proven experience of all ITIL Service Support/Service Delivery related
activities (including ITILV3 certification)
Proven experience with quality procedures.
Capability of working in an international/multicultural environment.
Experience
6.2.4
5 years or more is required for the area of expertise
Quality Manager
Profile :
Quality Manager (QM)
Overview
Person responsible for promoting awareness within the team with regard to
quality procedures and methodologies in place, set-up, maintenance and
assessment of them through internal audits, and improvement of them
through the development and implementation of continuous improvement
programmes.
Nature of tasks
Ensure that the delivery of services and/or products meets or exceeds customer
expectations by ensuring that the required quality processes and procedures are
in place and known by the all staff.
Build and maintain the quality plans for building and maintenance of all
systems, services and deliverables covered by this framework contract.
Development and management of the CSIP process related to this Framework
Contract.
Responsible for the regular internal assessment and internal audits of all services
provided by this Framework contract.
Responsible to ensure alignment of all operational processes linked to this
framework contract with the corresponding and related processes of the other
contractors.
Knowledge and skills
High-level qualified person with relevant experience responsible for promoting
awareness within the team with regard to quality procedures and methodologies
in place, set up, maintenance and assessment of them through internal audits, and
improvement of them through the development and implementation of
continuous improvement programmes as well as the to provide assistance and
support on service level agreements or other quality documents associated to the
project.
Page 148 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Quality assurance of ICT projects and capability of applying formal quality
standards (ISO standards, guidelines and references of other organisations such
as COBIT…).
Proven experience in quality assurance and related methodologies such as PM
(PMBOK, Prince2, RUP, ITIL, COBIT).
Proven experience with quality procedures.
Capability of working in an international/multicultural environment, rapid selfstarting capability and experience in team working, understanding the needs,
objectives and constraints of those in other disciplines and functions.
Experience
6.2.5
8 years or more is required for the area of expertise
Quality Controller
Profile :
Quality Controller (QC)
Overview
Person responsible to control the correct implementation and execution of
the quality processes and procedures.
Nature of tasks
Assistance and support on the contractual OLA’s or other quality procedures
or documents associated with the systems and services in this Technical
Annex.
Assist quality manager during the regular internal assessment and internal
audits of all services provided by this Framework contract.
Knowledge and skills
Quality assurance of ICT projects and capability of applying formal quality
standards (ISO standards, guidelines and references of other organisations
such as COBIT…).
Experience in quality assurance and related methodologies such as PM
(PMBOK, Prince2, RUP, ITIL, and COBIT).
Good knowledge of all quality procedures and quality plans linked to the
Framework Contract.
Experience
6.2.6
5 years or more is required for the area of expertise
Security Manager
Profile :
Security Manager (SECM)
Overview
Person responsible for promoting security within the team with regard to
security procedures and methodologies in place, set-up, maintenance and
assessment of them through internal audits, and improvement of them
through the development and implementation of continuous improvement
programmes. The mission is to ensure that products integrate security
requirements and that project-related information is managed securely. To
comply with this mission it is required an in-depth knowledge of technical
topics such as Network security, Identity and Access Management, web
application security, web services security, Open Standard security, and an
ability to validate the design of the related security components.
Nature of tasks
Provide high level security expertise regarding all security aspects related to the
systems and services in this Technical Annex.
Co-ordinate all security aspects related to the systems and services in this
Technical Annex.
Create, implement, maintain and continuously improve the required security
plans.
Page 149 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Integrate the security requirements from the TAXUD security policies in the
execution of all applicable activities.
Knowledge and skills
Proven experience with Security standards (ISO/IEC 27001 & and 27005)
Proven experience with Identity and Access Management, web application
security, web services security and Open Standard security
Good knowledge in securing information systems and prevent attacks.
Good knowledge of the security aspects of services (authentication,
authorization, …)
Good knowledge of Communication protocols, firewalls, network security
policies implementation and other security and antivirus tools.
Good knowledge of tasks related to national security accreditation and security
clearance.
Good knowledge of TEMPO’s security related documents
Ability to give presentations and security related trainings to the internal team.
Capability of working in an international/multicultural environment.
Experience
6.2.7
5 years or more is required for the area of expertise
Business Consultant
Profile :
Business Consultant (BC)
Overview
High level qualified consultant for analysis of business policy and needs
and design of Business architecture, definition of Business Services, impact
analysis of policy initiatives, process design and Business Process
Management advisor.
Nature of tasks
Assist on the development of business architecture, design of business
processes and assessment of their organisational or economic impact.
Liaise with the enterprise and system architects to propose business – IT
aligned solutions strategy and planning.
Support on realisation of a semantic data model and data dictionaries, assess on
alignment with International customs standards.
Assess MS process divergences and analyse and propose solutions with
minimal or acceptable impact.
When fulfilling the role of Proxy Product Owner, act as the Single Point Of
Contact with the relevant stakeholders of the Commission and other
contractors, on business matters.
Design strategy for process and data harmonisation
Knowledge and skills
Strong knowledge and experience in EU Customs processes and business
operations.
Specific customs business and customs legislation and procedures knowledge.
Strong experience in Business Process Management and assessment.
Good experience in data modelling. Knowledge of the WCO data model.
Page 150 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Experience
6.2.8
10 years or more is required for the area of expertise
Business Analyst Modeller
Profile :
Business Analyst Modeller (BAM)
Overview
Consultant with experience in the use of modelling or design tools.
Nature of tasks
Design and introduce models in a modelling tool based on predefined
requirements or drafts.
Provide input on low level detail design issues and patterns.
Propose improvements on modelling methods and styles to improve readability
and efficiency.
Knowledge and skills
Strong experience in the use of modelling and design tools in Business or IT
projects (ARIS, EA, etc.).
Extensive knowledge and experience in UML.
Large experience in Business and/or IT system analysis.
Knowledge and experience with customs processes and/or systems.
Experience
6.2.9
5 years or more is required for the area of expertise
Enterprise Architect
Profile :
Enterprise Architect (EA)
Overview
High-level qualified person able to develop enterprise architecture in line
with defined strategy; define, assess and coordinate architecture projects,
design architecture building blocks; design and coordinate architecture
implementation; align and integrate multiple architectures, layers and
perspectives; advice on architecture frameworks and methods; define and
measure architecture indicators (maturity, implementation, etc.); ensure
interoperability; identify potential reuse; perform cost-benefit analyses;
design Service Oriented Architecture; design and assess Identity and
Access Management and Master Data Management solutions; coordinate
the technical implementation; perform Business Analysis and contribute
to the Functional, Technical, Security and Testing Specifications.
Nature of tasks
Responsible for the enterprise architecture linked to the systems and services
defined in the Technical annex.
Review of the multiple architectures of the EU Customs and advice on
organisational and technical actions towards their integration and coherence.
Review of architecture of existing systems, design of component architecture
and building blocks.
Lead the definition, initiation and coordination of architecture projects and
assess and measure their added value, including innovation projects using new
solutions.
Provide architectural advice on any activity or project
Analysis of the integration of different information Systems and ensuring
Page 151 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
interoperability.
Follow up and contribute to the data analysis, data modelling and advise on
Master Data Management solutions (pivot models).
Follow up and contribute to the Business Process analysis and management and
advice on process implementation and automation solutions.
Coordination of the design of the technical architectures and guide on the
design and implementation of the SOA, MDM or other architecture methods.
Interface between EU Customs (Member States and TAXUD) architects.
Production of architecture documents. Contributes to the Business cases and
Vision documents.
Participation in bilateral meeting with Member States, technical working
groups, progress meetings and meetings with the stakeholders and users.
Contribution to the IT Strategy, portfolio management and master planning
and its incorporation in the Enterprise Architecture.
Knowledge and skills
Understands and apply security policy, measures, current standards, practices,
& technology.
Top notch knowledge of the architectural aspects of EU Customs related
systems, processes and services.
Excellent overall awareness of architecture solutions available on the market.
Capacity to analyse their potential added value for the use in the IT
architecture of DG TAXUD and to define and to lead projects for innovation.
High-level qualified person with practical experience in the design of
processes or systems covered in this Technical Annex.
Deep knowledge and experience of architecture frameworks and methods and
their practical implementation.
In depth knowledge of interoperability frameworks, patterns and technologies.
Capacity to define, integrate and document high level architecture artefacts on
any architectural domain and their alignment with policy or strategy principles
or objectives.
Ability to chair and participate in multi-lingual meetings, excellent
communication skills.
Excellent capacity in writing and presenting documents.
In depth knowledge of architecture design and modelling tools.
Ability to apply high quality standards.
Capability of working in an international/multicultural environment, rapid selfstarting capability and experience in team working, understanding the needs,
objectives and constraints of those in other disciplines and functions.
Experience
10 years or more is required for the area of expertise
6.2.10 Solution Architect
Profile :
Solution Architect (SA)
Overview
High-level qualified person responsible for architectural design and
documentation at portfolio, system or subsystem level. The solution
architect focuses on IT solutions.
Page 152 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Nature of tasks
Understand and interpret requirements. The architect participates in the
discovery and the documentation of the business processes that are driving the
solution. The architect is responsible for these requirements understanding and
embodies that requirements understanding in the architecture solutions and
specification(s).
Perform the tasks linked to the roles of a technology, data or
applications/services architect. It is to be understood that all these sub-roles are
not necessarily attributed to the same person.
Implement the definition, initiation and coordination of architecture projects
including innovation projects using new solutions.
Determine the correct architecture solutions and create the required architecture
model(s). Take the requirements and develop well-formulated models of the
components of the solution. Show multiple views through models to
communicate the proposals effectively. The architect also ensures leverage
opportunities are identified, using building blocks, and is a liaison between the
business and IT groups to ensure that the leverage opportunities are realised.
The provided solutions and models must provide a framework for
understanding the domain(s) of development work, guiding what should be
done within the applicable project(s).
Validate, refine and expand the solutions and the models. During the lifecycle
of the architecture solutions and models it is required to verify assumptions,
bring in subject matter experts, etc. in order to improve the models and to
further define them, adding as necessary new technology evolutions and
integrate expected requirements. All this is to be managed under change and
configuration management.
Act as a consultant to the project team staff. Provide the required information
and specifications such that correct IT design is performed for the functional
and non-functional requirements to implement.
Provide support to the transition and operational services. Ensure effective
support for clarification of implemented IT solutions and resolution of
problems during the development, testing and operational activities.
Knowledge and skills
Capacity to acquire the knowledge of the existing architecture solutions in place
for the customs and taxation IT systems/applications managed by DG TAXUD
and the EU customs and taxation architecture in general.
Capacity to acquire the knowledge of new architecture solutions to be
implemented in the DG TAXUD IT systems/application.
Good knowledge of architecture solutions design and modelling and project
management.
Being able to perform at least one of the following sub-roles: technology
architect, data architect, applications/services architect.
As a technology architect being expert in the following technical IT skills:
security, system and network management, transaction processing, location and
directory, user interface, international operations, data interchange, data
management, graphics and image, operating system services, network services,
communications infrastructure; have a good knowledge of software engineering.
As a data architect being expert in software engineering, location and directory,
user interface, data interchange, data management; have a good knowledge of
security, system and network management, transaction processing, international
operations, graphics and image, operating system services, network services,
communications infrastructure.
As an applications/services architect being expert in software engineering,
security, transaction processing, user interface; have a good knowledge in system
and network management, location and directory, international operations, data
Page 153 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
interchange, data management, graphics and image, operating system services,
network services, communications infrastructure.
Capacity in writing and presenting documents. Ability to apply high quality
standards.
Good communication skills.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.11 IT Manager
Profile :
IT Manager (ITM)
Overview
Manager of the IT project and support team. The IT manager will act as
the delivery manager for all applicable IT services and related artefacts.
Nature of tasks
Manage the different project and support teams such that they act as one team.
Manage the required IT infrastructure and tools such that all activities are
performed in optimal conditions. Capacity management is a key activity to
avoid major issues in this domain.
Work in close relationship with the programme manager to allocate the best
possible IT staff to the required roles.
Manage the IT project plans for the existing IT systems/applications and the
new ones to build.
Apply effective risk management especially in the context of the IT projects to
conduct. Be pro-active to resolve issues from a resource capacity and project
deliverables viewpoint.
Make sure that the staff is trained according to the applicable methodology and
to the quality and contractual processes.
Monitor the progress of the activities to be performed and act as an escalation
point for major issues.
Knowledge and skills
Leadership. The IT manager must demonstrate his competence, provide
solutions and determine the way forward for the IT project and support team.
Communication and team building are key for the successful role of the IT
manager.
Personal and professional skills. He must have strong communication and
relationship skills. He must have a solid IT background in the domain of
complex information systems.
He must be able to build a vision for the future based on his knowledge of
similar programmes.
Methodology and technology. He must have a good overall knowledge of
business process management, enterprise architecture and must be an expert in
IT project management and development methodologies.
He must have a good knowledge of the IT technology to be applied for the
customs IT systems/applications. He must follow the trends such to provide
advice to his team(s) and to the stakeholders.
Ability to chair meetings and to give presentations.
Ability to participate in multi-lingual meetings, good communication skills.
Knowledge of customs processes and logistic chain processes in general are
Page 154 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
considered as an asset.
Capability of working in an international/multicultural environment.
Experience
10 years or more is required for the area of expertise
6.2.12 IT Category Owner
Profile :
IT Category Owner (ITCO)
Overview
Person responsible for managing several IT systems/applications grouped
into a category of the portfolio. He is responsible for managing the team,
work plan, and all the project management procedures.
Nature of tasks
Acts as the IT project manager for the IT maintenance projects for the IT
systems/applications he/she is responsible for.
Assign and monitor the various support activities applicable to the IT
systems/applications he/she is responsible for.
Acts as the Single Point Of Contact with the relevant stakeholders of the
Commission and other contractors.
Apply correctly the quality processes and procedures.
Provide correct reporting.
Provide input to the PMO concerning proposals for the Request for Actions.
Knowledge and skills
Good project and contract management knowledge.
In depth knowledge of the IT systems/applications he/she is responsible for.
Excellent knowledge of project management standards and methodologies.
Usage of project management tools and methodologies as specified by the
Commission.
Good technical knowledge on the projects aspects.
Good reporting methods.
Ability to chair meetings and to give presentations.
Ability to participate in multi-lingual meetings, good communication skills.
Ability to plan and forecast.
Capability of working in an international/multicultural environment.
Experience
5 years or more as an IT project manager is required for the area of expertise
6.2.13 IT Project Manager
Profile :
IT Project Manager (ITPM)
Overview
Person responsible for managing one project. He/she is responsible for
managing the team, work plan, and all the project management
procedures.
Nature of tasks
Acts as the IT project manager for a given IT project.
Acts as the Single Point Of Contact with the relevant stakeholders of the
Commission and other contractors, on technical and planning matters.
Apply correctly the quality processes and procedures.
Provide correct reporting on the project.
Provide input to the PMO concerning proposals for the applicable Request for
Actions.
Page 155 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Knowledge and skills
Good project and contract management knowledge.
Excellent knowledge of project management standards and methodologies.
Usage of project management tools and methodologies and their evolutions, as
specified by the Commission.
Good technical knowledge on the projects aspects.
Good reporting methods.
Ability to chair meetings and to give presentations.
Ability to participate in multi-lingual meetings, good communication skills.
Ability to plan and forecast.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.14 IT Analyst
Profile :
IT Analyst (ITAN)
Overview
Qualified person able to perform IT analysis activities such as IT
requirements analysis and IT functional analysis.
Nature of tasks
Analysis of the IT functional and non-functional requirements. This is to be
done according to the applicable methodology and toolset to be used.
Produce or maintain all required artefacts which specify all elements in terms
of what needs to be implemented for a the different functional and nonfunctional IT requirements of given IT system/application. Apply the relevant
methodological steps and produce the required models.
Analyse & define specifications linked to the integration with other
applications and/or technological components.
Assist with training the administrators and users of the systems.
Assist with evaluating and testing products delivered by other teams to ensure
that they conform to the Commission requirements and methodology.
Participation in meetings with the Commission.
When fulfilling the role of Proxy Product Owner, act as the Single Point Of
Contact with the relevant stakeholders of the Commission and other
contractors, on business matters.
Knowledge and skills
Excellent written and verbal communication skills.
In depth knowledge of application development environments.
Have familiarity with software design/development processes, and the ability
to communicate effectively with development team.
Have IT analysis skills and the ability to translate IT requirements.
Have the ability to apply architectural principles to functional solutions.
Experience using model-based representations that can be adjusted as required
to collect, aggregate or disaggregate complex and conflicting information
about the business.
Acquire in a fast way the knowledge of the required methodologies to be applied
and prescribed by the Commission (TEMPO, Agile, RUP@EC and any
Page 156 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
successors of these methodologies). An evolution towards applying SOA from
an analysis viewpoint will be required.
Ability to cope with fast changing technologies used in information systems
developments.
Working knowledge of Java development techniques and technologies.
Ability to participate in multi-lingual meetings, ease of communication.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.15 IT User Interface Designer
Profile :
IT User Interface Designer (ITUID)
Overview
High-level qualified person able to design high quality user interfaces
Nature of tasks
Understand and analyse the requirements concerning the user interface(s) to be
implemented.
Create user interface specifications including user interface workflow
diagrams, wireframes and visual design compositions for all digital platforms
including website, mobile website and mobile/tablet apps.
Develop prototypes if required to support the design specifications such to
validate the requirements expressed by the users. Develop automated user
interface and business rule tests.
Knowledge and skills
Excellent written and verbal communication skills.
Keen interest on quality and intense attention to detail.
In depth knowledge of user interface technology.
Have familiarity with software design/development processes, and the ability
to communicate effectively with development team.
Have IT analysis skills and the ability to translate IT requirements.
Acquire in a fast way the knowledge of the required methodologies to be applied
and prescribed by the Commission (TEMPO, Agile, RUP@EC and any
successors of these methodologies). An evolution towards applying SOA from
an analysis viewpoint will be required.
Ability to cope with fast changing technologies used in information systems
developments.
Ability to participate in multi-lingual meetings.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.16 IT Designer
Profile :
IT Designer (ITDS)
Overview
High-level qualified person able to perform IT Design activities.
Nature of tasks
Produce or maintain all required artefacts which specify how the required
processes, functionality and data will be implemented. This is the
implementation of and aligned with the IT architecture solutions and the IT
Page 157 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
non-functional requirements.
Apply the relevant methodological steps and produce the required models.
Design the integration with other applications and/or technological
components.
Assist with training the administrators and users of the systems.
Assist with evaluating and testing products delivered by other teams to ensure
that they conform to the Commission requirements and methodology.
Participation in meetings with the Commission.
Knowledge and skills
Good written and verbal communication skills.
In depth knowledge of application development environments.
Being expert with software design/development processes and tools, and the
ability to communicate effectively with development team.
Have the capacity to understand IT architecture solutions in general and IT
architecture models specifically.
In depth knowledge of the SQL as the database access language in a given
DBMS implementation (currently Oracle at the Commission level).
Acquire in a fast way the knowledge of the required methodologies to be applied
and prescribed by the Commission (TEMPO, Agile, RUP@EC and any
successors of these methodologies). An evolution towards applying SOA from
an analysis viewpoint will be required.
Ability to cope with fast changing technologies used in information systems
developments.
Working knowledge of Java development techniques and technologies.
Ability to participate in multi-lingual meetings, ease of communication.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.17 IT Developer
Profile :
Developer (ITDEV)
Overview
Person who is able to program software components and to assemble
them into a working unit. The required programming expertise is
considered to be mainstream for the IT projects to which the IT developer
is assigned to.
Nature of tasks
Development, configuration, maintenance and documentation of software
components based on the applicable design specifications. These software
components can be user interface components or back office components.
Development of unit test specifications and perform these using the applicable
toolset and infrastructure environment. Development of automated user
interface, business rule, web service, performance and integration tests.
Assemble the software components into coarse grained components which can
be executed in software execution containers.
Participate in incident and problem management and more specifically in the
root cause analysis part exploring the source code of a given IT
Page 158 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
system/application.
Assist in the preparation / maintenance of installation and operation manuals.
Production of technical documentation for components during their
development.
Knowledge and skills
Ability to understand the IT design models and specifications to be used as a
basis for the programming.
In depth knowledge of the applicable programming environment considered as
being mainstream for the IT project to which the IT developer is assigned to.
In depth knowledge of the SQL as the database access language in a given
DBMS implementation (currently Oracle at the Commission level).
Good knowledge of the development of web and multi-tiers Internet
applications.
Good knowledge of the web services stack used in the selected technology.
Ability to cope with fast changing technologies used in application
developments
Capability of integration in an international/multicultural environment.
Experience
3 years or more is required for the area of expertise
6.2.18 Integration Developer
Profile :
Integration Developer (INTDEV)
Overview
Person who is able to program software components and to assemble
them into a working unit. The required programming expertise is going
beyond the mainstream expertise for the IT projects to which the IT
developer is assigned.
Nature of tasks
Development, configuration, maintenance and documentation of software
components based on the applicable design specifications. These software
components can be of any nature.
Development of unit test specifications if applicable and perform these using
the applicable toolset and infrastructure environment. Development of
automated user interface, business rule, web service, performance and
integration tests.
Assemble the software components if applicable into coarse grained
components which can be executed in software execution containers.
Participate in incident and problem management and more specifically in the
root cause analysis part exploring the source code of a given IT
system/application.
Assist in the preparation / maintenance of installation and operation manuals.
Production of technical documentation for components during their
development.
Knowledge and skills
Ability to understand the IT design models and specifications to be used as a
basis for the programming.
In depth knowledge of the applicable development environment which is going
beyond the mainstream development expertise for the IT project to which the IT
developer is assigned to. Examples of this (indicative and non-exhaustive) can
be: programming of complex IT architecture solutions which are the foundation
of implementing business functionality (e.g. TATAF components), integration
of web services in an ESB infrastructure, implementation of services in a BPMS
Page 159 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
infrastructure, etc.
Ability to cope with fast changing technologies used in application
developments
Capability of integration in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.19 Test Manager
Profile :
Test Manager (TSTM)
Overview
Person responsible for all testing activities. He/she is responsible for
managing the test team(s), work plan, and all the testing lifecycles.
Nature of tasks
Responsible for the planning and execution of the test activities assigned to
him/her.
Act independent from the development team for the execution of the tests.
Act as an adviser to the internal team and the Commission to evolve the testing
working methods and tools.
Correct reporting concerning the progress and the results of the tests.
Continuous risk management concerning the progress and results of the testing
activities.
Participate to the test management meetings such as ‘end of FAT’ and ‘end of
SAT’ meetings.
Provide input to the PMO concerning proposals for the applicable Request for
Actions.
Knowledge and skills
IT testing expert. Excellent knowledge of the testing lifecycle and the landscape
of the tools to automate the test cases to perform.
Good project and contract management knowledge.
Good knowledge of testing standards and methodologies.
Usage of project management tools and methodologies as specified by the
Commission.
Ability to plan and forecast.
Good reporting methods.
Ability to chair meetings and give presentations.
Ability to apply high quality standards to all tasks
Ability to participate in multi-lingual meetings, good communication skills.
Capability of working in an international/multicultural environment.
Experience
8 years or more is required for the area of expertise
6.2.20 Test Designer
Profile :
Test Designer (TSTDS)
Overview
Qualified person able to perform testing design activities and to produce
test specifications.
Nature of tasks
This role does not imply the execution of the test cases but all activities related
to automated test design and to produce the master test plan(s) and the test
design specifications – test scenarios.
Page 160 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Manage and evolve the applicable framework(s) for the automated test tools.
This implies the design, development and management of all required
specifications, documentation and software components constituting the test
suite.
Acquire a good knowledge of the IT system/application from a
functional/technical viewpoint such to design the correct and relevant test
scenarios.
Make sure that for a given IT system/application all requirements and
functional specifications are covered by the designed scenarios and adequate
test data (representative samples, randomised or anonymised data, positive and
negative test support).
Assist the tester in the execution of the test cases in terms of the analysis of the
result(s).
Assist with evaluating of testing products to ensure that they conform to the
Commission requirements and methodology.
Participation in meetings with the Commission.
Knowledge and skills
Expert knowledge of the testing methods, techniques and tools.
Ability to understand the functional and technical design of a given IT
system/application.
Ability to communicate effectively with development team.
Ability to participate in multi-lingual meetings, ease of communication.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.21 Tester
Profile :
Tester (TST)
Overview
Person who is able to produce the test design specifications – test cases,
the applicable Acceptance Test Plans and to execute the test plans.
Nature of tasks
Produce and maintain the required test design specifications – test cases.
These can be paper-based (legacy or test cases which cannot be automated) or
be integrated in a given tool. The latter determines the format and language
applicable to the test cases: XML, Excel format, etc.
Produce the Acceptance Test Plan (ATP) for formal test runs such as FAT
runs and formal qualifications.
Execute the required test cases and analyse the result(s).
Report on the test result(s).
Knowledge and skills
Proven experience with testing technologies and tools (e.g. IBM Rational
Functional/performance tester).
Keen interest on quality and intense attention to detail.
Ability to analyse results of testing correctly and to report on them efficiently.
Capability of integration in an international/multicultural environment.
Experience
3 years or more is required for the area of expertise
Page 161 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
6.2.22 Integration Expert
Profile :
Integration Expert (INTE)
Overview
This staff profile combines several roles. The tasks can be executed by one
or more persons. The profile requires good knowledge of the specification
and software development life-cycle, will provide assistance in the
deployment related activities and provide 3rd level support linked to the
deployment and operations of configuration items linked to the systems
and services in this Technical Annex. Furthermore good knowledge of
security, telecommunication and infrastructure aspects linked to the
systems and services in this Technical Annex are mandatory.
Person that is responsible for configuration management, release
management, infrastructure and tools management and technical
support.
Person able to prepare the applications for packaging, support the release
management process, perform application deployment related testing
(installation, removal, and re-installation) and produce the installation
scripts, procedures and guidelines.
Nature of tasks
Prepare, deploy and operate all ICT infrastructure (HW and OS and COTS)
required by the contractor to perform its contractual obligations.
Set up and maintain an enterprise type configuration management
environment to be used by all staff producing and maintaining IT artefacts.
Provide training and guidance how to use the implied processes and tools and
apply quality control on the usage.
Maintain all the required test, demonstration and Sandbox environments to be
used by the internal teams(s), the business users and the Commission.
Production and maintenances of all technical application and system
documentation and technical support in the production and maintenance of all
deliverables linked to the Framework Contract.
Prepare the packaging of components of the systems and services in this
Technical Annex, including the installation scripts, procedures and related
installation and operational guides.
Provide consultancy to the IT project team in terms of the development, test
and operational environments. Participate in the production and maintenance
of the infrastructure requirements for the new IT projects and the major
releases of the existing IT systems and applications.
Act as one of the main participants in important migration projects such as the
migration to a new DBMS version or to a new application server version.
Provide support to the ITSM contractor for all deployment & administration
related activities. This implies possible pro-active training on new features and
on-site support in case of major issues during the transition or operational
phase.
Provision of technical advice and assistance in any area associated with the
procurement, provision, delivery, maintenance, deployment, hosting, effective
use of information systems, communication systems and their environments.
Knowledge and skills
3rd level call resolution, problem analysis and resolution and technical support
in all service support & service delivery processes.
Good knowledge and proven experience of usage of automated build, test,
integration and deployment tools.
Good communication and coordination skills.
Page 162 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
Outstanding reasoning, analytical, design, and troubleshooting skills.
Rapid self-starting capability and experience in team working, understanding
the needs, objectives and constraints of those in other disciplines and functions.
Good knowledge of the architecture related to the systems and services in this
Technical Annex and all technical aspects of its components.
Expert knowledge of information systems, components (including OS, DBMS,
application servers, etc.) and network communication matters.
Good knowledge of security implementation mechanisms such as the usage of
firewalls, security protocols implying integration activities such as PKI
implementations, encryption mechanisms, etc.
Expert knowledge to set-up and maintain an enterprise type configuration
management environment.
Ability to cope with the fast changing technologies.
Ability to participate in multi-lingual meetings, excellent communicator.
Capability of working in an international/multicultural environment.
Experience
5 years or more is required for the area of expertise
6.2.23 Data Scientist
Profile :
Data Scientist (DS)
Overview
A data scientist’s main mission is to collaborate with the business
(business experts) to answer business questions by using data
management and data analytics techniques, including data modelling,
pattern detection, graph analysis or statistical analysis. These questions
can be as diverse as “How can I identify the same economic operator
across different databases?” “How to locate the data that can provide the
best estimations for indicators in an impact assessment?” or “How can I
simulate the impact of different conditions for a new policy?”
The data scientist brings the technical leadership and works with the data
analyst, the data engineer, and application developer to perform a
successful delivery.
The data scientist collaborates with the solutions architect to analyse the
analytical requirements for a data-intensive application.
The data scientist collaborates with the application developer to integrate
the code related to analytical outcomes into the data-intensive application.
Nature of tasks
The data scientist job profile contributes to all the steps of the data analytics
process:
- business understanding: communicates with business stakeholders to frame
the problem to be addressed; translates the business problem in data needs and
possible analytical approaches; defines the outcomes that can satisfy business
stakeholders;
- data understanding: helps locating the relevant data for the job; defines an
action plan to explore the data for identification of quality issues, and
validation of business assumptions;
- data preparation: decides on the different techniques for data cleaning,
feature engineering (creation of new indicators relevant for the task at hand)
and data manipulations to reduce the different data sources into analytical data
sets that can be used for the analytics work;
Page 163 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
- data analysis & modelling: advices on analytics approaches, choosing the
right algorithms, parameterizing, and presenting the outcomes (e.g. through
visualization and interpretation);
- validation: devises the best evaluation protocol to validate the outcomes from
a technical perspective;
- deployment and monitoring: advises on technical specifications for the
integration of outcomes for deployment and specifies the most adequate
indicators to monitor the deployed outcomes.
Knowledge and skills
The data scientist job profile requires a diversified set of quantitative,
programming, business, communication, and visualization skills:
- quantitative: has a reasonable knowledge in all quantitative data analytics
domains and excels in at least some of them, namely, statistics, machine
learning, natural language processing, graph analytics, optimization and
simulation; has a knowledge not only about the purpose and usage of
algorithms but is also familiarized with the underlying mathematics;
- programming: has a good computer science background, to support software
engineering activities, database management and systems integration; has
extensive practice on typical technologies used in the data ecosystem, such as
SQL, R, Python, Scala, Spark or No-Sql databases;
- business: has some business acumen and thinking flexibility to go into new
business domains rather quick; can make parallelisms between different
domains to adapt and apply successful approaches in similar problems;
- communication: can engage in communication with a different set of
stakeholders, from technical staff to senior management; uses effectively data
visualization approaches to convey quantitative and complex information;
presents complex jobs and outcomes in a logical and structured way
articulating, hypothesis, findings, conclusions and recommendations; adapts
the structure to the needs of the audience (e.g. focus on the how the work was
done VS focus on the recommendations);
- visualization: masters the principles of data visualization; can develop
compelling data visualization stories; masters some programmatic based
visualization technologies like the visualization packages in R or Python; has
experience in designing dashboards for different proposes and is proficient in
using technologies to develop custom made visualizations (e.g. D3.js).
Experience
The data scientist profile is a very senior and mixed profile, to which evolve
professionals from different backgrounds. They can be computer scientists,
physics, astronomers, chemists or even sociologists with strong quantitative
backgrounds. The data scientist presents deep experience in computer science,
data quantitative analysis, communication and business domains due to a
diversified career working in different industries and carrying different
technical roles with exposition to the business. Typically, the data scientist
holds a PhD but that is not mandatory.
There is no specific time length of experience to become a data scientist but it
is unusual to find good data scientists with less than 10 years of experience.
6.2.24 Data Engineer
Profile :
Data Engineer (DE)
Overview
A data engineer’s main mission is to collect, integrate and consolidate the
different data sources available to facilitate the work of the data scientist
and the data analyst. The data engineer work follows the guidance
provided by the blueprint prepared by the enterprise data architect to
Page 164 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
manage data within the organization.
The data engineer collaborates with the solutions architect to analyse the
data flow requirements for a data-intensive application.
The data engineer collaborates with the application developer to integrate
the code related to data flows and analytical outcomes into the dataintensive application.
Nature of tasks
The data engineer job profile contributes mainly to the steps of data
understanding, data preparation, deployment & monitoring in the data
analytics process:
- data understanding: implements the required data pipelines to collect,
transform and store the data required for a job;
- data preparation: integrates and consolidates the data sources in a data model
more user friendly for analytics;
- deployment & monitoring: reviews the code of data pipelines and analytics
assets to make them production-proof.
Knowledge and skills
The data scientist job profile requires a diversified set of quantitative,
programming languages and software engineering, database modelling and
administration, communication, and visualization skills:
- Programming languages and software engineering: SQL, ETL tools, python,
Java/Scala, computing algorithms, data structures, distributed computing, code
versioning, continuous integration.
- Databases modelling and administration: RDBMS, NoSQL, OLTP, OLAP,
DW, query optimisation, data normalization, de-normalized schemas.
- Backend development: APIs, ETL, Pipelines automation and scheduling
- Big Data computing frameworks: e.g. Hadoop, Spark, Kafka, Airflow, Hive
- Cloud technologies: Amazon, Google, Microsoft.
Experience
The data engineer has typically a strong IT background, from either software
engineering, database management or network management. They are eager to
build systems with production in mind: resilient, scalable and easy to
maintain. The data engineer uses DevOps best practices and is proficient with
building up on data architecture blueprints. This means that the data engineer
understands the building blocks of a data architecture and can take sound
decisions or provide advice on the technologies to achieve the goals of the
solution.
A data engineer requires typically at least 10 years of experience to acquire a
solid knowledge in building systems ready for production.
6.2.25 Data Integration and Harmonisation Modeller
Profile :
Data Integration and Harmonisation Modeller (DIHM)
Overview
The Data Integration and Harmonisation Modeller is a qualified profile
able to perform customs data integration and harmonisation
requirements analysis within the context of the evolution of the UCC
Annexes on data and of the preparation and evolution of the EU Customs
Data Model (EU CDM). The DIHM understands the links between the
WCO Data Model and the EU CDM and masters the data mappings
between different data models such as the UN/CEFACT data model, the
WCO Data Model and the EU CDM. The analyst can interpret customs
legal requirements (as referred to in Article 5(2) of the UCC) or other
legislation such as the Regulation on the EU Single Window environment
Page 165 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
STAFF REQUIREMENTS
for customs into data requirements.
Nature of tasks
Analysis of WCO Data Model evolutions impact on the EU CDM and vice
versa – including the creation of draft Data Maintenance Request(s) to WCO
Data Model whenever need arises as a result of EU legislation change(s).
Produce and/or maintain all required artefacts for data mappings in
GEFEG.FX tool.
Set-up the GEFEG.FX environment for data mappings and EU CDM
preparation and evolution.
Prepare data mappings for integration of certificates into the EU Customs
Single Window Certificates exchange.
Train diverse stakeholders on EU CDM and data mappings from / to customs
data models to non-customs data models.
Provide training and webinars on the use of EU CDM (for general,
international audience, including MS customs and worldwide customs
partners’ representatives, and as well DG TAXUD officials)
Analysis of the EU CDM and tax data models with a view to aligning them.
Participation in meetings with the Commission.
Knowledge and skills
Excellent written and verbal communication skills in English.
Knowledge of Customs data modelling techniques.
Mastery of the WCO Data Model and the EU CDM.
Knowledge of non-customs data models in other policy domains such as
phytosanitary, transport, and environment.
Capable of working in an international/multicultural environment.
Experience
5 years or more is required in customs data modelling.
Page 166 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
7. Quality requirements
7.1
Methodology
TEMPO is the applicable methodology for the SOFT-DEV contractor and for other contractors which
will interact with the SOFT-DEV contractor. The contractor will need to adapt to the evolution of
TEMPO which is subject to a continuous improvement programme.
All changes linked to TEMPO are discussed and approved every month during the external Quality
Managers Meeting (eQMM) and are rolled out as soon as they are available.
7.2
Standards and best practices
The contractor has to deliver the requested services in line with the ITIL V3 or V414 or higher best
practices, ISO Standards and TEMPO methodology.
TEMPO is the overall reference for all quality elements which are explicitly defined in the contractual
OLA and FQP. Refer to Tender Specifications - Part B (Terms of Reference), section 5.10 for more
information on TEMPO.
In addition, the contractor will use ISO/IEC 20926:2009 (IFPUG FSM) to quantify the size of the
software development, including pertinent documentation. See section 1.5 on IFPUG FSM method on
its application at DG TAXUD.
7.3
The quality framework of the SOFT-DEV contract
Considering the important operational responsibilities of DG TAXUD, expressed by SLAs and OLAs,
in the domain of the customs IT systems and applications, the delivered quality by the SOFT-DEV
contractor is of the highest importance for DG TAXUD.
The hierarchy and the applicability order among the different parts of the quality framework of the
SOFT-DEV contract is the following:
1.
The contractual OLA is applicable at the level of the Specific Contract. It mainly contains an
extract of the SQIs/KPIs as defined in this Technical Annex;
2.
The Framework Quality Plan (FQP) is applicable at the level of the Framework Contract and is
the main reference for the SOFT-DEV contract concerning this domain;
3.
TEMPO acts on the level applicable to all systems and projects managed by DG TAXUD.
7.3.1
Contractual Operation Level Agreement (OLA)
The levels of service to be provided by the contractor will be agreed with the Commission in the
contractual Operational Level Agreement (OLA), which will constitute an integral part of a given
Specific Contract. The contractual OLA defines mainly the SQIs/PKIs to be respected and monitored.
These quality indicators will be extracted from this Technical Annex.
Newly required SQIs/PKIs or changes to existing ones will require a change of the relevant part of this
14
The transition of ITIL versions is to be coordinated with the Contracting Authority as it has an impact
on the FQP and its related procedures, the related tools and the coordination with other of the
Contracting Authority’s contractors. This upgrade will have to be managed through CSIP at no extra
cost for the Contracting Authority (in other words: as part of the Continuous Services).
Page 167 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
Technical Annex. This will imply a formal amendment of the Framework Contract, after a mutual
agreement is reached between the contracting parties on the new SQIs/KPIs proposed by DG TAXUD.
Newly required PIs or changes to existing ones can be implemented at the level of the contractual OLA
without changing this Technical Annex.
All contractual OLAs will be become an annex to the FQP.
7.3.2
Framework Quality Plan (FQP)
The FQP describes all organisational aspects, the required process implementations and the tools to be
used which are leading to the best possible quality outcome of the ordered services.
Refer to the baseline for the FQPs applicable to the incumbent contractors and to TEMPO for more
generic information concerning FQPs.
7.3.3
TEMPO
TEMPO is the overall reference for all quality elements which are explicitly defined in the contractual
OLA and FQP. Refer to Tender Specifications - Part B (Terms of Reference), section 5.10 for more
information on TEMPO.
7.3.4
Service Level Agreement (SLA)
The Service Level Agreements (SLA) are set-up between the Contracting Authority and the customers
of its services. They define the minimum level of service expected from the Contracting Authority. It
provides a mutual understanding of service level expectation and their measurement methods. The
following categories of users are currently identified:

The National Administrations (NAs);

The users within the Commission, including also the other Directorates General.
The SLAs are maintained by the ITSM3 contractors which are also ensuring the required reporting on
these SLAs.
The SLAs are as such not contractually binding for the SOFT-DEV contractor, but act as a reference in
the OLAs and the FQP.
7.4
IT Development Excellence
DG TAXUD has important IT operational responsibilities. Operational excellence is required to provide
the services according to the expected quality. This operational excellence for the services linked to the
IT systems and applications is not possible without IT development excellence.
The contractor must demonstrate throughout the different phases of the development lifecycle and the
applicable support services that all measures are taken to deliver software to DG TAXUD which can be
deployed in conformance/production according to the expected business date and quality.
During the development lifecycle the following objectives must be achieved (list indicative and not
exhaustive):

The IT functional requirements and specifications must fit with the business analysis and
modelling specifications. The result must guarantee that the IT design and the software to
develop will correspond to the business user expectations. This is not only applicable to the
business functionality but as well to the user interfaces, etc.

The IT system/application system model must provide the required IT views which are needed
to produce the correct IT design specifications;

The IT design specifications or artefacts must be the basis for efficient programming;

The coding must be of good quality;
Page 168 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS

The testing lifecycle is closely linked with the development lifecycle. All required tests which
can be performed to validate the functionality and the non-functional requirements must be
performed as soon as possible.
Several IT systems/applications or parts of it have to be implemented by the National Administrations
based on agreed common interfaces. The quality of the specifications produced by the contractor and
delivered to the National Administrations by DG TAXUD is critical for the correct overall development
lifecycle at EU level. As the national development lifecycles are dependent on the correct delivery of
common EU specifications, the planning is in all cases to be respected;
The correct implementation of the interaction with the ITSM contractor is an important condition
towards operational excellence. Refer to chapter 9 for more information on the Synergia programme
which is to be taken into account in this objective. The contractor must involve the ITSM contractor in
all phases of the development lifecycle such that:

On-going knowledge transfer to the ITSM contractor is guaranteed concerning all aspects that
could have operational importance;

The architecture solutions and major IT design solutions are in harmony with the
conformance/production environments. All implementation aspects have to be checked such to
avoid any misunderstandings later in the service transition and operational phases. This is
applicable to database sizing and configuration, application server mechanisms and services,
etc.
An important step in the overall lifecycle of an IT project or software release to deliver is the formal
‘handshaking’ step between the SOFT-DEV contractor and the ITSM3 contractor. This is currently
realised with the delivery of the software release and all related artefacts followed with the execution of
a software delivery validation activity during which the operational contractor must confirm that all
conditions are fulfilled to start effective Site Acceptance Tests.
7.5
Continuous Service Improvement Programme
(CSIP)
The transformation objectives of the contract will be pursued by managing a constant service
improvement programme (CSIP) that the contractor will maintain by taking advantage of the lessons
learned, proposals for improvement, opportunities and targeting the maturity and compliance objectives
of the contract.
The CSIP will be the key central instrument to steer the required transformation in a consistent and coordinated way across all work packages of the contract. It will be of particular importance for the
development of applications and the continuous improvement of the service quality.
The CSIP will be delivered to the Commission as part of the FQP (see WP.0.12).
7.6
The Performance and Quality Indicators
Three (3) types of indicators will be used to assess the performance and/or quality of the services
delivered by the SOFT-DEV contractor, regardless of the method used for ordering these services (SC
or RFA) and/or of the type of budget provision used (FP or OD).
The indicators are:

Key Performance Indicators (KPI): These indicators will be used to measure quality for
Continuous and On Demand services ordered under FP and/or OD provision. A KPI itself may
measure the quality of a particular ordered service and may lead to direct Liquidated Damages,
when the performance and/or quality of the services delivered by the contractor is not
satisfactory. The KPIs may be applied directly on deliverables/services ordered via an SC or
via an RFA. The basic principle behind the KPI is summarised as follows:
Page 169 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
o
The Contracting Authority orders deliverables/services (e.g. a Feasibility Study,
workshop attendance) under FP and/or OD provision by using any one of the ordering
mechanism (that is, SC or RFA);
o
The Contracting Authority defines the KPIs for measuring service levels for the
ordered services in an SC or RFA;
o
The evaluation of the service levels for these KPIs will be performed on a monthly
basis, in case the service ordered via an SC or at closure of the RfA, if ordered via an
RfA.

Specific Quality Indicators (SQI) and General Quality Indicator (GQI): Specific Quality
Indicators (SQI) will be used to measure quality of a particular service (or part of it) ordered in
the context of a Specific Contract (SC) or Request for Action (RfA). The General Quality
Indicator (GQI), on the other hand, is an aggregation of SQIs which measures a more general
quality of ordered services. Normally, the GQI is used for measuring performance at the level
of a Specific Contract or Request for Action (RfA) and may lead to Liquidated Damages,
when the performance and/or quality of the services delivered by the contractor is not
satisfactory or below target.

Performance Indicators (PI): These indicators give information about the services in general,
and are of informative nature and are not contractually binding.
A given performance for a deliverable or service can be measured either with a KPI or SQI, but not
with both in order to avoid double counting. For example, the timely delivery of a major deliverable can
be measured either with KPI01 or with SQI01, but not with both. However, for the same deliverable /
service, a combination of KPI and SQI may be used, provided that KPI and SQI measure different
performances or qualities. For example, the timely delivery of a software component in the context of an
RFA can be measured using KPI01, while the quality of that software itself can be measured by using
SQI07. The total liquidated damages due, if any, is the sum of the liquidated damage due for KPI01 and
the liquidated damages, if any, due for the GQI of the RFA.
Refer to Appendix 1, section 13, for the formal definition of the KPIs, PIs and of the SQI/GQI models
and the way to calculate them from the QoS measurements, along with general indications on their use.
For clarity reasons, any reference to the terms “deliverable” or “document” in appendix 1 or elsewhere
in this document might be read as any “artefact” or “service” part of this Framework Contract.
7.6.1
Overview of the KPIs
The table below list the contractual Key Performance Indicators (KPI):
SQI #
KPI01
KPI02
KPI03
KPI04
KPI05
KPI06
KPI11
KPI12
KPI13
KPI14
KPI21
KPI22
Name
Measure the respect of the deadline of deliverables whose delay would have a major impact (SfA)
Measure the respect of the deadline of a deliverable whose delay would have a high impact (SfA)
Measure the respect of the deadline of a deliverable whose delay would have a medium impact
(SfA)
Measure the respect of the deadline of a deliverable whose delay would have a low impact (SfA)
Measure the number of bugs or defects detected during an Agile iteration which are not corrected
at the end of the following iteration
Measure the respect of the Agile iteration calendar
Measure the Incident Resolution Time
Measure the Problem Resolution Time
Measure the Change Impact Assessment resolution time
Measure the Requests for Service (RFS) and Requests for Information (RFI) resolution time
Measure the corrective issue resolution – hotfix delay
Measure the Delay in delivering a patch during a SAT session
Page 170 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
KPI23
KPI31
KPI32
KPI41
KPI42
KPI43
KPI51
KPI81
KPI82
KPI91
KPI92
KPI93
Measure the number of SAT and/or Qualification iterations per software release.
Measure the process compliance as assessed by self-assessment, internal and external audits and
audits by the Contracting Authority
Measure the conformance to security controls (number of critical findings during security audits)
Measure if the initial value of the “Total number of months experience in each key profile 15 that
will be assigned full time to the project” remains at an acceptable level defined by the KPI Limit
below.
Measure that the contractor team in charge of providing fixed-price services, is staffed with the key
profiles16 as proposed in the contractor’s bid and that they are allocated and remain staffed to the
activity as of the signature of the first Specific Contract.
Measure the availability of the staff, per profile, as proposed in the contractor technical offer as a
response to the Call for Tender.
Measure the Training/workshop appraisal for all trainings/workshops provided by the contractors,
except if explicitly excluded by the Contracting Authority.
Measure the delay in completing the Take-Over within the foreseen Take-Over period.
Measure any discrepancy (non-compliance) in the contract implementation compliance versus the
submitted tender or the Technical Annex
Measure the delay to deliver a technically and financially acceptable offer/proposal
Measure that the actions agreed with DG TAXUD have been implemented within the given
timeframe
Measure the deadlines in processing non-compliance notification or complaints for any of the
services provided by the contractor.
Any deviation from the specified services not captured by any other explicit KPI is the subject to
this KPI.
KPI94
Measure the number of re-occurring Non-compliance notifications or Complaints received and
confirmed by the Contracting Authority over a sliding window period of 6 months
KPI95
KPI96
Measure the satisfaction of the users with the services provided by the contractor
Measure the respect of the minimal productivity rate of 100 Function and SNAP Points / calendar
month
Table 4 : KPI List
7.6.2
Overview of the SQIs
The table below in this section defines the default Specific Quality Indicators (SQI) which may be used
to measure the service quality.
SQI #
SQI01
SQI02
Name
Measure the respect of the deadline of a deliverable whose delay would have a major17 impact
(SfA)
Measure the respect of the deadline of a deliverable whose delay would have a high impact (SfA)
15
Key profiles as defined in section Error! Reference source not found.
16
Key profiles as defined in section Error! Reference source not found.
17
Whether the impact of a deliverable is major, high, medium or low is decided by DG TAXUD at the time the
Request for Estimate is issued.
Page 171 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
SQI #
SQI03
SQI04
SQI05
SQI06
SQI07
SQI08
Name
Measure the respect of the deadline of a deliverable whose delay would have a medium impact
(SfA)
Measure the respect of the deadline of a deliverable whose delay would have a low impact (SfA)
Measure the number of bugs or defects detected during an Agile iteration which are not corrected at
the end of the following iteration.
Measure the respect of the Agile iteration calendar.
Measure the number of times a testing cycle (SAT / CONF) must be restarted per software release.
A testing cycle must be restarted each time the delivery of a patch resulting from a defect that
would have prevented to put the software in production is performed.
Measure the number of complaints18 received and accepted by the Commission.
Table 5 : SQI List
Please refer to section 13.2 for the definitions and details on the method of computation of the
KPIs/SQIs.
7.6.3
Overview of the PIs
The contractor may be asked to report on a Monthly basis (normaly in MSR) on about 10 to 20
Performance Indicators (PIs). This PI reporting does not replace the usual Monthly KPIs and/or SQI
reporting in the Monthly Service report. The exact list of PI’s to report on will be defined in the Specific
Contract. Further Performance Indicators may be defined by the Contracting Authority in the course
of the contract as deemed adequate for reporting purposes.
The exact calculation method of these PIs will be documented in the Contractual OLA 19 between DG
TAXUD and the SOFT-DEV contractor.
Examples are provided below. Targets are not necessarily set, and Direct Liquidated Damages do not
apply to a PI individually.
PII #
PI21
Measure the quality of a deliverable (SfR)
PI22
PI23
Measure the quality of a deliverable (SfA)
Measure the amount of documentation defects created from not implemented comments
PI24
PI25
PI26
Measure the time elapsed between the creation of a (documentation) defect and the provision of the
analysis
Measure the amount of low reaction time on assigned calls
Measure the number of calls reassigned to the contractor during the reporting
PI27
Measure the number of late deliveries for which the Contracting Authority was not notified
PI28
Measure the number of defects reported during SAT/QT
PI29
Measure the number of bugs reported per CI (platforms/systems/application/component) per
reporting period
18
19
Name
Complaints received from project stakeholders (i.e. DG TAXUD, member states) and delivered to the contractor via a
registered e-mail or letter entitled 'Official Complaint'. Commission officials will provide copies of the accepted complaints to
those fulfilling the roles at the next escalation level in the Escalation Procedure defined in the FQP. The exact procedure, in
line with the escalation process is to be detailed in the FQP.
Being one of the annexes of the FQP
Page 172 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
PI30
Measure the number of changes reported per CI (platforms /systems/application/component) per
reporting period
PI31
Measure the number of patches delivered per CI (systems/application/component) per reporting
period
PI32
Measure the number of releases delivered per CI (systems/application/component) per reporting
period
PI33
Measure the number of the contractor’s documents for which more than one comment per page was
raised
Table 6 : PI List
Please refer to section 13.4 for the definitions of the Performance Indicators (PIs).
The choice of the KPI for the application of a direct liquidated damage and the SQIs contributing to the
GQI calculation and their respective weights will be defined in the Specific Contracts (SC) or directly in
RfAs. The Contracting Authority reserves the right to change the SQI combination and weights in the
GQI for each SC or in an RFA, as an instrument to enforce the non-regression and continuous
improvement of the quality of service.
7.7
Data source for service level calculations
By submitting an offer in response to this Call for Tenders, the tenderer accepts to use for the
calculations of the indicators the data provided by Synergia SMT, the request tracking system or any
other component of the Application Lifecycle Management platform (refer to section 8.5.1) or any other
future DG TAXUD applicable Service Management Tool for the SQIs/KPIs/PIs that can be measured
(partly20) with the tools.
The SOFT-DEV contractors will facilitate audit and quality check exercises by providing all
necessary elements (interview with personnel, documents, logs, and reply on the audit findings). The
Contracting Authority may quality check and audit the usage of the tools, data quality, process
compliance, etc... These activities may be tasked to a third party, if the Contracting Authority decides so
(see also WP.0.9).
Any contractor may set quality and compliance requirements, in agreement with the Contracting
Authority, for a task, an object or a delivery package that will be (re-)assigned by other parties. Any
contractor has the right to refuse task assignments, if the criteria are not met and this would render the
correct service provision unduly difficult. This must be done by assigning the task back to the sender,
including a justification. In case of dispute, the Contracting Authority will decide based on the
justification entered within the tools and may use justification provided directly by the contractor(s)
through other channels.
7.8
Internal quality system of the contractor
The contractor must operate an effective internal quality system in order to deliver according to
expectations and minimise risks raised around its services and increase the resilience of them. The
contractor will run internal QA, QC and risk analysis processes of which it will keep the internal quality
records available to the Commission on request.
20
Meaning that in agreement with and after approval from the Contracting Authority some manual post processing
and/or exception handling would be allowed.
Page 173 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
QUALITY REQUIREMENTS
The contractor will proceed periodically to self-assessment and internal audit. The internal audit will be
conducted by internal auditors of the contractor offering reasonable assurance of segregation of
reporting with the delivering team of the contractor.
The contractor must appreciate that any defect in its quality system will result in a quality burden
shifting to the Commission and in a decrease of quality of service for the users.
7.9
Audits
The Contracting Authority reserves the right to perform quality and security audits in the contractor’s
premises for assessing the performance and the quality of the delivered services. The Contracting
Authority may elect to contract a third party to perform these audits, and the contractor commits himself
to co-operate fully with the Commission and the duly apppoited third party during these audits (refer to
WP.0.9).
7.10 Critical quality success factors
The Commission regards the following as critical quality success factors for the delivery of the contract:













Execution of the contract in compliance the Technical Annex (this document), FQP, Specific
Contracts and their technical annexes;
Service performance and achievements in relation to targets set forth in the contractual OLA;
Responsible, proactive, and customer driven project and quality management;
High user satisfaction levels;
High quality level of deliverables submitted for review to the Contracting Authority;
Proactive behaviour in all situations, in the best interest of the Contracting Authority;
Continuous improvement by recycling all lessons learned and full implementation of CSIP;
Predictable behaviour and quality;
Transparent, accountable and service oriented relationship between all involved parties (NAs, other
contractors, DIGIT/DC);
Functional and technical knowledge of the applications and systems under the responsibility of the
contractor;
Rapid and visible progress in the transformation;
High quality and on-time 3rd level call resolution;
Highly competent and qualified staff assigned to the project.
Page 174 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
8. Infrastructure and tool requirements
8.1 Data Centres
At the time of writing, the infrastructure, on which the central Information Systems (IS) of DG TAXUD
are running, is provided by three different entities: DIGIT’s Data Centre, located in Luxembourg, the
ITSM3 OPS contractor and the CCN2-DEV contractor.

DG DIGIT is operating its data centre activities from Luxembourg, where it hosts several computer
rooms distributed over multiple locations for contingency. It interconnects all buildings of the
Commission via its private network (SNET) and provides controlled and secured access to external
networks via its Telecom centres (one in Belgium, the other in Luxembourg).

The ITSM and the CCN contractors are hosting a number of DG TAXUD’s central systems in two
redundant Tier IV level data centres located in two distinct locations in Luxembourg. It is also using
a Telecom centre to interconnect the Internet access used by the different teams located in several
countries of the Union.
All data centres have an interconnection with the CCN/CSI private network and the contractors must
request the configuration of their own development and test environments (for example, in terms of
queues) on these CCN gateways that are managed by the ITSM contractor.
Figure 2 - Distribution and location of DG TAXUD’s ICT infrastructure (subject to change)
Figure 2 illustrates a global picture of the infrastructure in terms of its complexity. This infrastructure is
needed to be able to guarantee high availability and resilience to the Member States and other IT
stakeholders.
DIGIT and/or the ITSM3 OPS contractor will provide the following services to the SOFT-DEV
contractor in the context of the SOFT-DEV development area within the DG TAXUD-hosted
environments:
Page 175 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS

Housing covering the unpacking of infrastructure delivery at arrival, installation of
infrastructure in DG TAXUD’s data centre racks, providing electricity and network
connectivity;

Installation of the initial operating system – its maintenance and subsequent upgrades will be
the responsibility of the SOFT-DEV contractor;

Configuration of the virtual environments (e.g. VMWare);

Storage;

Connectivity;

Technical and availability monitoring;

Backup and restore functions.
The SOFT-DEV contractor will be able to recommend and request updates to this configuration after the
takeover period.
The SOFT-DEV contractor is expected to provide all other services related to the infrastructure as
defined in WP.8.4.1 and WP.8.4.2.
The SOFT-DEV contractor will be responsible for capacity management in terms of defining its
infrastructure requirements for the implementation period of the Framework Contract. The SOFT-DEV
contractor must ensure that any required requests for updates to the infrastructure (e.g. storage capacity)
are made in a timely manner so as not to put project timelines at risk.
The SOFT-DEV contractor is expected to use the infrastructure outlined above for all activities related
to integration, iteration review, testing and delivery. The Sandbox and FAT (Factory Acceptance Test)
environments, provided by DG TAXUD, will be used to test the installation procedure and the
functionality of the application releases and patches according to the test documentation
(MTP/TDS/ATP), including non-functional testing such as performance, stress, security and integration
testing.
Activities preceding the actions executed in the Sandbox and FAT environments (i.e. programming and
unit testing) will be carried out on the development environment. It is the intention of TAXUD to
provide its housing in the context of the SOFT-DEV contract. This may not be possible from the start of
the contract therefore the possibility must exist for the development environment to be housed at the
SOFT-DEV contractor’s own environments as described in section 8.3.
8.1.1
TAXUD environments
The environments used by DG TAXUD are the following:
-
Development (DEV) environment: provided by SOFT-DEV contractor and maintained by
SOFT-DEV contractors. Used for development purpose. The SOFT-DEV contractor will be
expected to set up and maintain the development environment until such time as TAXUD
provides the housing of this environment.
-
Demonstration environment: provided by SOFT-DEV contractor and maintained by SOFTDEV contractor. An environment remotely accessible by DG TAXUD and other stakeholders.
It may be used on an occasional basis for training, workshops, meeting support, demonstration
of GUI elements to external parties, etc.
-
Sandbox environment: fully integrated environment provided by DG TAXUD but maintained
by SOFT-DEV contractor. An environment remotely accessible by DG TAXUD and other
stakeholders. The environment is primarily used for work item acceptance purposes, to support
Agile increment integration, functional and non-function testing and formal validation during
Iteration Reviews (refer to Tender Specifications - Part B (Terms of Reference) section 3.3.3)
and other formal demonstrations of deliverables.
-
Factory Acceptance Test (FAT) environment: fully integrated environment, provided by DG
TAXUD but managed by SOFT-DEV contractor. An environment remotely accessible by DG
TAXUD and other stakeholders. Dedicate to execute the FAT tests (Factory Acceptance Tests -
Page 176 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
WP.7.5.3) which prove expected quality of software developed by SOFT-DEV contractor. This
is the last test environment before official delivery of software to DG TAXUD.
-
Site Acceptance Tests (SAT) environment fully integrated environment, provided by DG
TAXUD and managed by ITSM3OPS contractor. Dedicated environment to execute SAT (Site
Acceptance Tests) tests. This is the first environment when the software developed by SOFTDEV contractor is deployed and tested by ITSM3OPS contractor and DG TAXUD.
-
Performance environment: fully integrated environment, provided by DG TAXUD and
managed by ITSM3OPS contractor. Dedicated environment where performance tests are
executed by ITSM3OPS contractor and DG TAXUD.
-
Conformance (CONF) environment: fully integrated environment provided by DG TAXUD
and maintained by ITSM3OPS contractor. Dedicated to execute CONF (Conformance) tests.
These type of tests are understood as business validation tests and are executed by both DG
TAXUD business users and/or Member States business users.
-
Production (PROD) environment: fully integrated environment provided by DG TAXUD and
maintained by ITSM3OPS contractor where all DG TAXUD applications are deployed to be
used by DG TAXUD and Member States business users for production purpose.
Not all test environments may be used in the scope of each IT project. Any deviations from the list of
environments used during project must be agreed by DG TAXUD. DG TAXUD may decide to change
the name or purpose of the test environments.
8.2
Future Evolutions
The SOFT-DEV contractor is expected to take over all infrastructure and tools in their current “as-is”
state. The infrastructure and tool requirements will evolve in line with new technological opportunities
and the phase out of existing and legacy components. DG TAXUD cannot forecast all possible
evolutions at the beginning of the Framework Contract and has, therefore, provisioned a reserve for
important IT transformations (refer to 5.2.15.1 and 5.2.15.2).
The following sub-sections outline known projects that are already in their inception phases and which
may have a future impact on the infrastructure to be used by the SOFT-DEV contractor.
8.2.1
Platforms evolutions
DG TAXUD is providing a set of platforms which will facilitate the application’s service operation,
among which the Shared Services and CDCO (Centrally Developed Centrally Operated) are its newest
additions. Further evolutive changes to the other platforms, such as CCN2ng, SPEED2ng and UUMDS
are also to be expected.
Page 177 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
Figure 4 – TAXUD’s platforms
8.2.1.1
Shared Services
Shared Services is a platform that provides the capabilities of common services that are required
to deliver a global overview of all DG TAXUD platforms from one location.
The already available Shared Services are and the future will be, to every extent possible, compliant to
the principles of the Circles of Trust and the reuse of common building blocks, including cross-cutting
services that can be designed and used in a common way for multiple platforms but implemented
separately to avoid redundancy, to supply a wide range of functional and non-functional requirements,
such as: monitoring (technical and functional), audit and log processing, archiving and reporting.
8.2.1.2
CDCO
CDCO is an evolution of the existing TSOAP platform. The evolution is comprised of moving several
capabilities to the SPEED2ng platform and the scope will be altered in order to accommodate the basic
principles of circles of trust.
The architecture of the CDCO system keeps the same approach as its predecessor which is based on
the Service Orientation paradigm which allows heterogeneous systems and platforms to communicate
with CDCO while maintaining their own architecture. Moving forward, CDCO will remain to have the
capability to host applications for system-to-system interaction, as well as the ability to hold user
interfaces for internal and trusted users. Other user-to-system capabilities, i.e. those used by untrusted
parties, will be moved elsewhere.
Page 178 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
8.2.2
Infrastructure as a Service
Studies and pilots are currently being executed to evaluate the feasibility to have the infrastructure
available as cloud services. Depending on the outcome of these actions a move to such an infrastructure
will be carried out either during the execution of the contract or before it starts.
8.2.3
Containers and container orchestrators
Studies and pilots are currently being executed to evaluate the feasibility to introduce containerisation
technology at DG TAXUD. The SOFT-DEV contractor must provide expertise and competences to
support DG TAXUD in this modernisation.
Depending on the work progress before start of the contract the SOFT-DEV contractor must be ready to
migrate existing containerised components or support DG TAXUD in the adaptation of the
containerisation technology.
8.3
Infrastructure at SOFT-DEV’s premises
For the successful execution of all work packages, it is expected that the SOFT-DEV contractor will
ensure the availability of a certain infrastructure at its premises. This standard infrastructure for daily
activities should be supplied by the SOFT-DEV contractor at no additional cost to DG TAXUD.
The SOFT-DEV contractor must specify, size, provide, host, install, configure, stage in, fine tune,
operate, monitor and administer any necessary office, ICT, videoconferencing and telecoms
infrastructure. Minimum requirements for the office, development and network infrastructures are
described below.
The contractor should also put in place the necessary insurance to cover all infrastructure against the
usual risks (e.g. fire, flood, thefts).
Office Infrastructure
The basic office infrastructure should cover at least (indicative list and not exhaustive):
 An adequate office environment, including telephone, fax and photocopying facilities;
 Conference call facilities;
 Access to the Internet;
 One industry standard workstation for each person that is configured to fit their specific role (e.g.
a developer and a manager would require different set-ups and software); tools compatible with
the Commission Office automation environment (refer to section 8.6); suitable printing and file
server facilities;
 Individual e-mail addresses and Web access for each person;
 Functional e-mail addresses as appropriate;
 A dedicated meeting room for up to 12 people (with teleconference access) available for
meetings with the Commission and/or other contractors;
 A training room with at least 32 PCs;
Access to the office infrastructure must be restricted to pre-defined authorised persons (contractor’s
team members, the Commission’s representatives and occasional accompanied visitors, such as staff
members of the other contractors).
Development Infrastructure
For the development work, it is recommended that a configuration (“development lab”) is containing,
but not limited to, the following facilities:

Application servers;

Database servers;

Email servers;
Page 179 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS

File servers;

FTP servers;
It is the intention of TAXUD to house the development environment (excluding office infrastructure as
described above) during the lifetime of the contract. The contractor is to provide the housing at the start
of the contract, should this housing not be available by the start of the contract.
Demonstration environment
As defined in section 8.1.1, the demonstration environment provided by the SOFT-DEV contractor is
remotely accessible by DG TAXUD and other stakeholders. It may be used on an occasional basis for
training, workshops, meeting support, demonstration of GUI elements to external parties, etc.
Network services
 TAXUD will provide network connection possibilities to the DG TAXUD data centres upon
request according to the required services to perform (development, testing, transition and
operational support services). These requests must be compliant with the applicable security
requirements and should be done in a timely manner;
 Facilities for Internet meetings/conferencing/learning/collaborative environment/online training
courses possibly for a large audience.
8.4
Hardware/Software/Maintenance Acquisition
Channel
If, for some reason, DG TAXUD is unable to procure necessary hardware or software, the SOFT-DEV
contractor may be requested to make such procurements on behalf of DG TAXUD. For example, this
might include the procurement of a licence for usage at within the DG TAXUD datacentres or cloud, or
hardware or software to be used at the SOFT-DEV contractor’s own site. This procedure is described in
work package WP.8.4.3.
8.5
Tools
DG TAXUD will specify the tools used to automate the processes as much as possible for the services
to be performed in the context of the Framework Contract. This also includes tools for supporting the
management of and reporting on the provision of those services.
The acquisition, deployment and operation of these tools will either be part of the unit price linked to the
provided service or be covered by WP.8.4.3.
DG TAXUD will also provide an Application Lifecycle Management platform, described below, to
cover the main project and related knowledge management needs.
The contractor will also have to support DG TAXUD to interface with third party developed
applications or Service Management related tools.
During the Framework Contract, improvements to the proposed tools or new tools could be introduced
via the CSIP programme (see WP0.12) or on DG TAXUD request. DG TAXUD could also provide new
tools to the contractor to replace the tools already in place. The migration to these tools will be planned
and managed through an on demand activity.
DG TAXUD will provide the SOFT-DEV contractor with some service management related tools which
will be maintained and operated by DG TAXUD in collaboration with the operational contractor,
ITSM3Ops. More information concerning the Synergia Programme can be found in chapter 9.
Page 180 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
DG TAXUD and other parties identified by DG TAXUD must have, at least, read-only access to
all the tools, COTS and their related data that will be set-up and used in the context of the Framework
Contract.
8.5.1
Application Lifecycle Management platform
DG TAXUD will provide an Application Lifecycle Management platform from the start of the
framework contract to cover the main project and related knowledge management needs. The
components of the platform will be:

A request, issue and task management and tracking tool, including Agile product backlog
management, release planning, roadmap and portfolio overview. The issue tracker will be
linked to the incident tracking tool used by the ITSM contractor's Service Desk in order to
avoid manual copy-paste of overlapping content. (Atlassian Jira)

A set of collaborative tools for project knowledge management, wiki-like rich content
documentation, risk management, planning, specifications and deliverable provision. The
platform will support software analysis, mockup and prototyping activities and will be
integrated with the issue tracker. (Atlassian Confluence)

A code quality monitoring tool. (SonarQube)

A software artefact repository. (Nexus)

Source code version control system, integrated with the issue tracker. (Git)

Connections with other automations, for example linked to the development environment, test
management, continuous integration and continuous deployment tools. (Atlassian Bamboo,
Urban CodeDeploy)
Please note that the tools indicated in parenthesis are the ones considered at the time of writing. There
might be some changes, but the latter will not affect the targeted functionalities and levels of tool
integration.
8.5.2
Monitoring tools
The contractor will take over the existing setup or propose new setups such as to be able to integrate to
the monitoring tools in alignment with platforms and infrastructure provided by the ITSM3 Operations
contractor.
8.5.3
Service support and issue tracking tools
Service support and issue tracking tools will be specified and provided by DG TAXUD. If this is not
possible from the start of the contract, the contractor will have to provide the appropriate infrastructure.
DG TAXUD will have full and continuous access to the corresponding tools and platforms.
The SOFT-DEV contractor will be required to use Synergia SM provided by DG TAXUD for some of
the support services (Please refer to section 9.2.1).
8.5.4
Integrated Development Environment (IDE) tools
The SOFT-DEV contractor is free to choose IDE and related development tools, however, those IDEs
must be compatible with DG TAXUD’s Application Lifecycle Management platform.
8.5.5
Modelling Tools
DG TAXUD makes use of the ARIS tool for modelling and design of the Business Specifications
(including BPMs) and IT Architecture artefacts. The tenderer will ensure the necessary expertise and
Page 181 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
capacity to provide support in terms of the usage, administration and customisation of the tool in the
most efficient and effective manner.
At present DG TAXUD makes use of the ARIS modelling platform, the ARIS Business Publisher and
the Business Simulator but other components of the tool might be incorporated in the future. The
tenderer should also be able to advice DG TAXUD on the use of other modelling or architecture tools as
alternative or interfacing with the ARIS tool for specific use.
8.5.6
Planning Tools
DG TAXUD currently uses MS Project and Atlassian Confluence as main planning tools. Any
planning tool used by SOFT-DEV, in combination to the Application Lifecycle Management platform,
must have the capability to manage the planning activities defined in WP.0.8, the DTM and any other
planning related deliverables linked to this Framework Contract. The planning tool might be subject to
change during the execution of the framework contract. This will be communicated in a timely manner.
8.5.7
Document Repository Tools
DG TAXUD is currently mainly using CIRCABC® as a document repository tool for various activities
such as documentation reviews and the publication of information to the Member States. For document
deliverables, the standard procedure is for contractors to email documents (or FTP large documents) to
the QAC contractor who organises the review cycle by creating a review task and uploading the
submitted document to CIRCABC®. After DG TAXUD has accepted the document deliverable, the
QAC contractor uploads the accepted version to CIRCABC®. Deliverable increments, including
documents, will be produced or made available on the Application Lifecycle Management platform, in
support to the Agile methodology. During the lifecycle of the Framework Contract, DG TAXUD may
decide to upgrade to a successor of CIRCABC® or an alternative tool for final deliverable provision.
This would be handled via WP.0.12. Any resulting changes to the FQP should also be completed during
this activity.
At the time of writing the Call for Tenders, the Commission is testing via a pilot phase a corporate tool
called AMARANT. This is actually a registration and archiving tool to support/facilitate administrative
and contract management related activities such as delivery/registration of project deliverables (Docs &
S/W), filing, etc. When testing is successfully concluded, the SOFT-DEV contractor will be invited to
start using this tool.
8.5.8
Knowledge Management tools
The contractor should contribute to building the knowledge base according to DG TAXUD
requirements.
8.5.9
Testing tools
8.5.9.1
Security testing tools
Security testing tools will be specified and provided by DG TAXUD. If this is not possible from the
start of the contract, the contractor will have to provide the appropriate infrastructure. DG TAXUD will
have at least read-only and continuous access to the corresponding tools and platforms.
8.5.9.2
UI testing tools
UI testing tools will be specified and provided by DG TAXUD. Currently, Selenium is used.
8.5.9.3
Performance testing tools
Performance testing tools will be specified and provided by DG TAXUD. Currently, LoadUI is used.
8.5.9.4
Regression test automation tools
Regression test automation tools will be specified and provided by DG TAXUD. Currently, SoapUI and
Junit via Maven are used.
Page 182 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
INFRASTRUCTURE AND TOOL REQUIREMENTS
8.5.10 Automatic deployment tools
Application deployments must be fully automated. For automated deployments either UrbanCode
Deploy and/or container orchestration tools (specified by DG TAXUD) must be used.
8.5.11 TAXUD technology roadmap
Specific contracts and/or RfAs must be written in such a way that the development contractor must
follow DG TAXUD technology roadmap for each project, application or environment.
The same conditions are applicable during subsequent releases of the applications. In case that there are
no other releases planned before a dependent technology is phased out, the development contractor must
certify their application against the new COTS versions.
8.6
Office automation Tools
The SOFT-DEV contractor must have an office automation environment which is compatible and interoperable with that of DG TAXUD. At the time of writing the Invitation to Tender, the office automation
environment was as follows:

Windows 10

Office 2016– deployed with the platform

Modern web browsers e.g. Edge, Chrome and Firefox
DG TAXUD started a pilot project for the evaluation of the use of Microsoft Office 365 and Microsoft
Teams, which shall be extensively used in the future.
Page 183 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
9. Synergia Programme
9.1
Participation in the Synergia programme
DG TAXUD has set up the Synergia programme to further build on ever better working relationship
between DG TAXUD IT, the Stakeholders, the Suppliers and Users (refer to ‘Synergia services offer
(by ITSM)-contractors’ obligations [R23]). The programme strives towards a shared coherent set of
processes supported by automated workflows and excellent Service Management Tools. The Synergia
programme will imply transformations to improve efficiency and to achieve operational excellence.
The SOFT-DEV contractor is concerned where he interfaces with the operations contractor and delivers
services within IT operations (meaning production and conformance), IT service support processes,
testing (SAT) and release delivery. Services not concerned by the Synergia programme are services
linked to:

IT software development: the SOFT-DEV contractor may use the most appropriate software
development best practices, tools and factories it considers required for building the software it
is contracted for;

ICT Infrastructure management linked to the provision of the SOFT-DEV Data Centre services.
Typical Synergia projects are for example Deployment of IBM® Rational Team Concert® (RTC) or any
other similar tool, Knowledge Management, Event Management, CMDB, Service Request Management
and Service Fulfilment, Service Catalogue, Self Help and Knowledge bases, Automated Deployment,
Planning tools and Planning services, etc.
The following describes mainly the interfaces with the operations contractor:

The “As is” section describes the interfaces to the ITSM contractor at the time of writing of this
Invitation To Tender;

The “To be” section describes the expected changes to the existing interfaces and must be taken
into account by the tenderer.
9.2
AS-IS
The AS-IS describes the interfaces to the ITSM contractor at the time of writing of this Invitation To
Tender;
The ITSM contractor works according to the DG TAXUD TEMPO methodology and ITIL V3 best
practices. The actual implementation of ITIL is described by the ITSM contractor through the ITSM
FQP and related documents and has put all the relevant processes in place.
The incumbent contractors work according to the TEMPO application development methodology and
has put processes in place to handle 3rd level service support which are described in the FQP of the
incumbent contractors and related documents. The SOFT-DEV contractor will take over the services,
interfaces and tools from the incumbent contractors as they will be at the time of takeover (refer to
WP.2.2). This “As Is” situation is in line with the service descriptions in the relevant work packages
specified in chapter 2.
The SOFT-DEV contractor may request services to ITSM Operations contractor related to the tools
setup, configured, customized and operated by ITSM. Those services are related to information
provision, training, technical support service, etc. At the time of writing this Invitation To Tender, those
tools are ITSM Portal, Synergia Service Manager, SAP Business Objects reporting and the ITSM LDAP
for user management.
Other services may be defined, setup and provided if the SOFT-DEV contractor justifies the need and
DG TAXUD agrees.
Synergia SM is defined with a 7d-24h Service Window (“Normal” Quality of Service availability target
value of: 99.6% and a limit value of 99.3%– All days of the year including Public Holidays, 24 hours a
day).
Page 184 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
It is up to DG TAXUD’s decision to change this classification.
9.2.1
Service Support Operations
9.2.1.1
Service Desk
The ITSM contractor maintains a Service Desk according to ITIL, who acts as a Single Point of Contact
(SPOC) for all the users, stakeholders and authorised 3rd parties of DG TAXUD IT community. The
ITSM Service Desk is the central point of dispatching for all calls and requests between DG TAXUD,
stakeholders, service providers and call issuers.
The SOFT-DEV contractor should maintain a Central Help Desk, who interfaces to the ITSM
contractor’s Service Desk.
No direct interaction with end-users shall be established by SOFT-DEV. The ITSM Service Desk will
create interactions/incidents/requests for services/information where necessary for the SOFT-DEV
contractor. The Service Desk of ITSM contractor acts as a proxy for feedback of entities that reply
outside of the tool. The ITSM Service Desk will update the data objects according to this feedback, and
inform the SOFT-DEV contractor of this change through the Synergia SM.
It is expected that the SOFT-DEV contractor will support the ITSM3 3rd level escalations in a consistent
and auditable manner, by employing a modern issue tracking system. DG TAXUD will provide this
functionality through the Application Lifecycle Management Platform. If this is not possible from the
start of the contract, the contractor will have to provide an appropriate issue tracking system alternative,
such as Rational ClearQuest, JIRA, etc..
For the simplicity of the text, all the further references to the term “Application Lifecycle Management
Platform” in the chapter 9 refer to an IT system or platform where the SOFT-DEV contractor can
provide his customer services, despite the implemented solution underneath.Actions issued by DG
TAXUD inside the context of operations must be logged in Synergia Service Manager by the ITSM
Service Desk.
By submitting an offer in response to this call for tenders, the tenderer commits to monitor
ticket queues within the Synergia Service Manager proactively. The tenderer commits to issue
new tickets uniquely through the Synergia official tools, such as Employee Self Service,the
Synergia web services or the Service Manager Full Client. Direct e-mail exchange between
assignment groups does not constitute a valid way of communication about the progress of a
ticket.
9.2.1.2
Incident management
The ITSM contractor is working with Synergia Service Manager, based on MicroFocus SM 9.41,
installed at the ITSM Data Centre.
All incidents must be registered via the ITSM Service Desk.
The ITSM Service Desk registers, classifies, prioritises and manages incidents in the Synergia Service
Manager and takes over all communication towards the incident issuer. Incidents include also requests
for information and request for services. This Service Desk is also responsible for the incidents created
during the CT campaigns.
The SOFT-DEV contractor will get incidents assigned by ITSM contractor within Synergia SM in order
to provide third level support, solutions, workarounds, and to identify problem candidates, within its
area of responsibility.
With the information provided in the Synergia Service Manager, the incumbent contractors Central Help
Desk registers the issues in the Application Lifecycle Management Platform with a link to the Synergia
ticket number. The incumbent development contractors’ Central Help Desk dispatches the call to
internal teams that work on issues in the Application Lifecycle Management Platform only.
The SOFT-DEV will ensure that all progress on incidents will be documented in the Synergia Service
Manager, and that the content of the incident, status of resolution and assignment information is up to
date at all times. This must be done by having the SOFT-DEV teams dealing with issue resolution
working directly within Synergia Service Manager or the ITSM Portal. Subsequent objects related to
Page 185 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
these incidents, remain registered as defects and change requests in Application Lifecycle Management
Platform.
ITSM closes the incident with the respective information to the call after getting a closure feedback
from the issuer. When the incident contains a confirmation of a defect, ITSM creates a problem with
related known errors and workaround information if applicable. The incumbent contractors are not
involved in the management of those objects.
For some incidents, concerning mainly issues related to the components of systems that are under the
responsibility National Administrations, DG TAXUD reviews the resolution provided before it is
communicated to the issuer.
The tickets status between Synergia Service Manager and SOFT-DEV contractor’s
Lifecycle Management Platform is not necessarily synchronised.
Application
By providing a bid to the present invitation to tender, the tenderer commits to remove
unnecessary and redundant actions that only serve to synchronize information over tool
boundaries, by at the latest at the end of the take-over.
The tenderer accepts that the prioritisation of incidents in the Synergia Service Manager is
performed exclusively by the ITSM contractor, based on the rules and procedures defined by
DG TAXUD. The tenderer accepts that the ITSM Service Desk may change the priority of an incident
during the course of the resolution if new information is available.
The SOFT-DEV contractor may request to change the priority of an incident to the ITSM contractor
with a reason and accepts that this priority change will be communicated to the user by the ITSM
Service Desk.
9.2.1.3
Problem management
ITSM Operations Problem Management captures and collects information about possible problems from
several reporters and via multiple channels:

by e-mail on a dedicated ITSM functional mailbox,

by contacting the ITSM Project Managers,

or using the Service Manager, from the recorded incidents reports.
The ITSM contractor problem management processes are following the ITIL V3 best practices.
Within the ITSM problem management process the SOFT-DEV contractor will be requested to provide
feedback (or flag) which incidents may be problem candidates.
The SOFT-DEV contractor acknowledges that based on the feedback it has delivered within the incident
record, the ITSM contractor creates problems in Synergia Service Manager with root cause analysis and
workaround information.
Information provisioned shall allow the ITSM contractor to apply workarounds to incidents, perform 1 st
level call resolution and to link similar future incidents to an existing problem. A Known Error (KE)
record will be created from an early stage for the Problem records created based on an incident (or many
incidents) and for which the root cause analysis has to be done. The goal is to provide visibility to DG
TAXUD via ITSM Portal for the problems under investigation.
In case the information in the incident does not allow the ITSM contractor to reuse the information in
the context of operations, the problem may be assigned to the SOFT-DEV contractor in order to provide
clearer information.
The outcome is communicated to ITSM which is updating the relevant information in the Synergia
Service Manager.
9.2.1.4
Change management
The ITSM contractor is performing change management for operations with Synergia Service Manager.
The incumbent contractors are performing change management for application development within the
developer’s Application Lifecycle Management Platform .
Page 186 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
If the Application Lifecycle Management Platform is not accessible by the National Administrations,
part of the change management for SOFT-DEV delivered IT systems is performed through the Synergia
Service Manager, by assigning requests for information (impact assessment and request for position).
Those requests are to be linked to the equivalent objects within the Application Lifecycle Management
Platform used by SOFT-DEV.
9.2.2
Service Transition
9.2.2.1
Testing lifecycle
The incumbent contractors develop most of the test artefacts. These are a mix of plans, test
documentation, test scenarios and test cases. Although many IT systems and applications use test
automation tools and techniques this is not yet the case for all of them.
The incumbent contractors perform unit, integration and FAT testing based on those artefacts. The
artefacts are delivered to the ITSM contractor and to be used to prepare different testing stages
environments and perform the testing qualifications, according to the TEMPO methodology. It is
possible that DG TAXUD decides that the full or partial qualification testing cycle is performed by DG
TAXUD itself, or through another designated contractor, such as ITSM TES or Quality
Assurance.Testing documentation is exchanged through the Document Repository systems, such as
CIRCABC. The ITSM contractor can comment on the documentation through the TEMPO deliverables
review process. The TEMPO deliverables review process ensures that comments on those files are
implemented according to the decision taken by DG TAXUD in a comments and author’s position
review meeting.
During test execution, the ITSM contractor can produce an addendum to the Test Design Specifications.
This addendum contains test cases that are considered to be missing and that are related to additional
operational tests needed. This addendum is to be forwarded by the ITSM contractor to the incumbent
contractors such to guarantee a synchronisation of the Test Design Specifications.
When available, automated testing is typically performed for:
(1) System-to-system test cases, available for most of the IT central applications, and which allow to
test the implemented validation rules at server level. These tests are to guarantee the consistency of
the implemented rules independent from any client interface.
(2) User Interface test cases which are executed through an User Interface Testing Tool (e.g. Selenium
IDE, Rational Functional Tester).
(3) Performance test cases,executed through a performance testing tool (e.g. LoadUI, SoapUI, Rational
Performance Tester).
Test reporting by ITSM is shared with SOFT-DEV contractor on multiple communication channels,
such as through emails, conference callsm, wiki pages. Issues found by ITSM during testing are logged
as such in Service Manager and via the SOFT-DEV helpdesk, into the Application Management
Lifecycle Platform.The incumbent contractors provide a position to each test result.
At the end of a test cycle, overall testing report is produced by ITSM and made available via the
Documentation repository, in a common standard office document format.
9.2.2.2
Release and Deployment Management
The incumbent contractors provide and maintain a set of necessary document that describes the
functional, non-functional and technical specifications, such as the Infrastructure Requirements
Document (IRD), Administration Manual (AMN), Operational Model (OM), Installation Procedure
(IPR) or the Release Notes (RNO). This is to be provided to ITSM Operations contractor as early as
possible in the development lifecycle and contains all required elements to anticipate to new or changed
requirements. It is recommended to start this activity early in the process, even if the required
documents could be in draft versions at that time. As soon as the final versions are ready, they will be
made available to the ITSM contractor.
The Infrastructure Requirements Document describes the infrastructure that is needed for the current
release and it will be applicable to all the environments, typically grouped in 2 sections: production and
non-production environments. The Operational Model is the referece point regarding the deployment of
Page 187 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
the application. It describes the Application’s views (Logical, Deployment, Process), together with the
systems’ interfaces, communication and access requirements, licensing and installation details. The IRD
and OM must be submitted for review to DG TAXUD a defined time in advance of the SAT, in order to
assure the time for provisioning of the environments, under so called 9-6-3 rule (depending on the
complexity of the infrastructural changes, it signifies that the lead time before SAT can vary between 3
to 9 months).
The Administration Manual and the Installation Procedure will include detailed information about
administration procedures, jobs / batch jobs to be planned in, what to do in case of job failure, regular
housekeeping tasks, and operations best practises as long as they are specific to the application. The
administration manual will also identify candidates for operational standard changes and will as well
provide specific instructions, procedures and documentation related to services that have specific
security and confidentiality requirements.
The release note contains all information needed for ITSM to correctly perform deployment and release
management.
The release note does not contain impact assessment, CMDB information and identifiers related to
resolved known errors that allow the ITSM contractor to close service management records that
should/need to be closed in Synergia.
The incumbent contractors use Rational ClearCase for Software Version and Build Management or an
equivalent tool, to which ITSM has read access to it.
The contractor delivers releases and release notes to the ITSM Ops contractor following the approval of
DG TAXUD and a successful FAT or qualification execution performed by the SOFT-DEV or ITSM
TES contractor.
Once the ITSM configuration management allows doing so, the contractor delivers the release directly
into the DML of the ITSM Operations contractor.
Release bundles include at least:

Binaries, scripts, configuration instructions, SQL statements, etc.

Updated documentation (linked to system development and system strategy, design, operation
and transition),

Release note, Installation / deployment information,

Links to all (declared) fixed defects, all new defects and all (declared) implemented changes
including those ones raised in Application Lifecycle Management Platform,

Acceptance test plan and reference data.
When delivering a release or a patch, the contractor provides information which “known errors” are
resolved by the release, including their identifiers in Synergia Service Manager.
The incumbent contractors deliver releases and release documentation to ITSM for deployment and
installation purposes through FTP file server exchange. At the time of writing the Call for Tenders, the
DG TAXUD is actively working on establishing new alternatives of improving the release management
process, especially aiming to adopt modern repositories solutions and to support the Agile methodology
and DevOps best practices.
Release versioning between the ITSM contractor and the incumbent contractors is not necessarily
aligned. The SOFT-DEV contractor may use the release versioning that the ITSM Operations contractor
defines, but may keep an internal release numbering in the release note.
No releases are deployed into production without prior approval by DG TAXUD.
Page 188 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
9.2.2.3
Release documentation maintenance
The incumbent contractors create and maintain all the release documents required by the the ITSM
contractor.
The contractor is expected to improve the quality of the release documentation (administration and
installation manuals, release notes) by adding links to standard software documentation and standard
best practises, as well as specifics to the implementation at hand, regular tasks, etc..
The administration manual will as well provide specific instructions, procedures and documentation
related to services that have specific security and confidentiality requirements.
9.2.2.4
Planning Management
The incumbent contract and the ITSM contract maintain at each side operational plannings. DG
TAXUD is coordinating both plannings.
Changes in release delivery to the ITSM contractor require re-planning for testing and deployment and
cause often strain on the ITSM contractor from a timing and resource point of view.
9.2.2.5
Knowledge exchange
There is no formal end-to-end knowledge exchange process in place between the incumbent contractors
and the ITSM contractor.
Elements that allow for knowledge are desk study or release note and other documents delivered during
the TEMPO document review cycle, when and where possible. During testing, the SOFT-DEV
contractor provides support during SAT and answers to questions issued by the ITSM contractor.
On an ad-hoc basis and for a given elapsed period, mainly in the context of major deployments or proof
of concepts projects executed by DG TAXUD via any of its IT contractors more permanent crosscontractor working groups have been established to mitigate the risk of major operational issues.
9.2.3
Service design
9.2.3.1
Specifications and requirements management
The TEMPO document review cycle and CIRCABC is used to allow the ITSM contractor to comment
upon specifications and design of applications.
9.2.3.2
IT architecture, analysis and design
The contractor must involve the ITSM contractors in a dynamic way such that all non-functional
requirements are known, correctly designed, implemented and tested ready for deployment.
The contractor will inform the ITSM contractor timely in case new technology is used or major releases
and new systems require operations specifics that will be new to the ITSM contractor.
For new systems and new technology, the tenderer will hand over knowledge to the operations
contractor through knowledge transfer techniques, e.g. coaching and shadowing sessions, and possibly
playground installations. Handing over of documentation will not be accepted as only means of
knowledge transfer for new systems and technologies.
The ITSM contractor will ensure staff is skilled to the level that could be expected from expertise
available freely on the market, i.e. non-TAXUD application specific knowledge. This knowledge does
not need to be handed over by the tenderer.
9.2.3.3
Configuration Management
The incumbent contractors does not maintain a CMDB in the operational ITIL sense, but a software
versioning repository in Rational ClearCase.
The ITSM contractor maintains as operational CMDB the Synergia CMDB. The objective of the
Synergia CMDB is to keep an overview over the IT infrastructure and landscape and the applications
Page 189 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
and systems deployed on top of it. The CMDB includes relationships between the elements within the
CMDB.
Maintenance is based on information provided by the incumbent contractors for example through
release notes, but maintenance is restricted to the ITSM contractors’ area of responsibility. The network
and infrastructure part that is responsibility of the CCN/TC in not contained in the Synergia CMDB
There is no formal communication process or review process established yet between incumbent
contractors and the ITSM related to the maintenance of the Synergia CMDB.
9.2.4
Other services provided by ITSM3 Operations contractor
The incumbert contractor may request services to ITSM Operations related to the tools setup,
configured, customized and operated by ITSM contractor. Those services are related to information
provision, training, technical support service, etc. At the time of writing this Invitation To Tender, those
tools are ITSM Portal, Synergia Service Manager, the ITSM LDAP for user management, SAP Business
Objects and QuartzDesk Server. A project is on-going to actively improve Synergia Reporting based on
Business Objects.
Other services may be defined, setup and provided if the SOFT-DEV contractor justifies the need and
DG TAXUD agrees.
9.3
TO-BE
The contractor will take over the services, interfaces and tools from the incumbent contractors as they
will be at the time of takeover (refer to WP.2). The following specifies the view of DG TAXUD how the
current situation will evolve towards the “To Be” situation. This “To Be” situation is in line with the
service descriptions in the relevant work packages specified in chapter 2.
DG TAXUD has adopted the ITIL V3 best practices and is envisioning to adopt the ITIL 4 practices in
the future. The contractor commits to work according to ITIL (at least V3) recommendations,
throughout the service management lifecycle within its responsibilities concerning operations support.
9.3.1
Service Support Operations
In the future, the systems being developed under the Agile/DEVOPS methods and aiming for a
continuous integration, delivery and deployment approach, will required significant changes on all the
present Service Support Operations.
It is expected that SOFT-DEV will work in close collaboration with DG TAXUD and its other
contractors to review and contribute towards the updates of all the Service Support functions and
processes (Service Desk, Incident Management, Change Management, etc.).
9.3.2
Service Transition
9.3.2.1
Continual service transition
The ITIL V3’s Service Transition is widely considered as a phase in a sequantial model for the Service
lifecycle management, where the checks on the service readiness help improving the service before it is
released.
In a continuous delivery development model, however, this is model needs to be adapted towards a
continual service transition, through a continous assessment of the service readiness and operability of
the freshly introduced changes flowing towards production. ITIL 4 provides a way to address the
problem of the phased approach where the key activities performed during the Service Transition will
now need to happen continuously during other ITIL phases (the feedback from the change of the Service
in Operation will influence the next IT system change being developed).
It will be expected that SOFT-DEV contractor is providing a close collaboration and support to other
TAXUD contractors during this Service Transition development towards ITIL 4 best practices.
Page 190 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SYNERGIA PROGRAMME
9.3.2.2
Testing lifecycle
It is the objective of DG TAXUD to apply automated testing wherever possible in order to improve the
overall deployment time, to reduce the risks of regression and to create the possibility to move towards a
“continuous” testing strategy.
Furthermore, the testing conditions must be as close as possible to the conformance/production
conditions. Performance tests, end-to-end test are only some examples which are to be performed in
order to avoid major issues when deploying a new release in conformance/production.
The required adaptations will be part of the CSIP (WP.0.12) and will be implemented in the context of
the relevant work package(s).
9.3.2.3
Release and Deployment Management under continuous delivery
and continuous deployment
The ITSM Operantions contractor in concertation with the ITSM Integration contractor are currently
under the process to provision the infrastructure needed to support the continuous delivery and
deployments pipelines. But once the supporting infrastructure will be in place, it is expected that SOFTDEV will have to collaborate closer with the other DG TAXUD contractors, ensuring a high level of
communication and feedback, being tightly coupled with the updated Change Management process.
Page 191 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
IT TRANSFORMATIONS
10.
IT Transformations
DG TAXUD can decide to perform IT transformations during the lifecycle of the SOFT-DEV
framework contract. These transformations may be introduced by DG TAXUD as major improvements
to the current development, transition and operational processes and toolsets in order to fully benefit
from new possibilities offered by the IT market and other opportunities such as the development of the
new CCN2 network.
DG TAXUD may request the SOFT-DEV contractor to participate to those transformations and make
available skilled and knowledgeable resources by triggering on-demand activities.
For this purpose, DG TAXUD has allocated a provision to their financing. The cost of acquiring
hardware and software is excluded from this allocation and will be funded from the general
hardware/software/maintenance provision.
It should be noted that the SOFT-DEV contractor is expected, as a professional IT development expert,
to follow the evolution of market methodologies and tools. The contractor will be expected to have the
capacity to adopt those methodologies and tools that become mainstream in the software development
industry. The adoption of new methodologies and tools may be implemented, with or without invoking
the transformation budget provision foreseen, depending on the nature and scale of the adoption of the
new methodology or tool.
The new methodology or tool can be adopted without fundamentally affecting the contractual
productivity of the contractor (no improvement of the FPS pricing). In this case, the Commission is not
bound to invest from the transformation budget.
If howeverthe contractor proposes that an improved contractual productivity (improved FPS pricing) can
be obtained by the transformation, then he can make an offer describing the transformation project,
which would typically be supported by an initial investments provided by the Commission, and leading
to an improved productivity. If the Commission accepts such an offer, the contract can be amended.
The following describes

The possible transformation of the current project management, development and
testing lifecycle methods;

The possible participation of the SOFT-DEV contractor in a transformation project
jointly with the ITSM contractor of the current transition process of a given IT
system/application.
The tenderer is requested to provide in his answer to the Invitation To Tender (refer to ‘Annex 08 –
Template for technical offer, section 2.6’) his proposal of such a transformation with the following
elements:

Description of the new methods and tools with a clear indication what the tenderer
considers as main improvements compared to the existing applicable methods;

A description of how the tenderer intends to use container technology to support
automating the deployment of applications;

The roadmap and timetable to implement the IT transformation.

All measures proposed to avoid a disruption or degradation of service during the
transformation.
10.1 New project management, development and
testing methods
Currently, the Customs and Taxation IT projects, systems and applications are managed, developed and
tested according to processes and procedures described in the current version of the TEMPO
methodology. For a description of the current applicable methods refer to the relevant TEMPO
Page 192 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
IT TRANSFORMATIONS
documents through the URL specified in the Tender Specifications - Part B (Terms of Reference)
‘section 0.5 References’ and more specifically to:

The project management part with the project management reference manual (TMPREF-PM) as the main document;

The Trans-European system management with the Trans-European Systems Reference
Manual (TMP-REF-TES) as the main document;

The application development part with the application development reference manual
(TMP-REF-ADP) as the main document;

The test part. Refer to Central Information Systems (CIS) testing for the testing of the
central applications with the testing reference manual (TMP-REF-TST) as the main
document. Refer to conformance testing for the conformance tests conducted with the
National Administrations with the conformance testing procedure (TMP-PRC-CT) as
the main document.

The Software Development Lifecycle (SDLC) reference manual.
The main IT transformation that DG TAXUD considers in this domain of activities is to further extend
the initiatives taken to move towards project management, development and testing lifecycle methods
which are tool-based and Agile. Refer also to the Tender Specifications - Part B (Terms of Reference),
chapter 8 future perspectives. Specific emphasis must be put on the design methods, the automation of
all test activities and quality monitoring, and an effective and efficient interface between IT
development and IT operations contractors over all phases of the IT systems/application lifecycle. The
extension of agility beyond the SOFT-DEV contractor’s domain is considered, for example in the codevelopment of full software releases or modules with National Administrations, external stakeholders
and partner Commission entities other than DG TAXUD. The current Agile methodology, aiming at
building solutions “ready for Site Acceptance Test”, could be extended to build solutions “ready for
Production”, therefore explicitly involving contractors in other Framework Contracts (ITSM and QA
contracts).
The main objective of this transformation is to further reduce the overall time to develop, to improve the
applicable productivity rates at the contractor(s) and the Commission level while keeping the required
level of quality.
10.2 Participate to the modernisation towards new
transition methods
The lead for this possible IT transformation will be DG TAXUD supported by the ITSM contractors.
The main objective of this transformation is to reduce the time to deploy new releases and to improve
the applicable productivity rates and scalability. This will be achieved mainly by

Automating the deployment processes;

Infrastructure as a Service (IaaS);

Containers and container orchestrators;

Further automating the testing activities.
The SOFT-DEV contractor will be possibly requested to adapt existing processes and methods such that
there is an alignment with the new methods and tools from a development delivery viewpoint. This
transformation is not necessarily linked to the one for project management, development and testing as
described in section 10.1.
Page 193 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SECURITY REQUIREMENTS
11.
Security Requirements
All the requirements in this chapter have to be integrated into the Information Security Management
System put in place as execution of WP.0.14 Security Management.
As part of its project operation and management, the contractor must ensure that the following
requirements are met:

Keep the Contracting Authority informed of the composition of the contractor’s team and
provide the CVs for each staff member,

Restrict and control the access by his staff to the service resources on a “need to know/access”
basis,

Take the necessary security protection to avoid divulgation of service resources to external
parties, including a strong protection (e.g. by encryption or strong access control) of all project
related sensitive information when it leaves the contractor premises. Special attention shall be
paid to e-mail exchanges and mobile equipment as e.g. laptops, CDs/DVDs or USB memory
keys,

Be able to exchange encrypted and/or signed emails via the S-MIME protocol internally, with
TAXUD and with other contractors if required,

Escalate any security incident to the Contracting Authority,

Provide security recommendations (e.g. deployment of security patches …) to the Contracting
Authority when required.

Restrict, monitor and control the access to all of the SOFT-DEV working environments;

Restrict, monitor and control the physical access to any servers, firewalls, routers and other
physical components used to manage the information flow within the environment,

Restrict, monitor and control the access to the connection towards the CCN network should it
be via the Commission CCN GW or via the CCN IP network, by protecting the CCN connected
LAN segment using dedicated cabling and equipment and a firewall to isolate it from the other
segments of the operational infrastructure;

Ensure compliance with the Confidentiality/ Integrity/ Availability requirements applicable to
the information, information systems and processes;

Protect all workstations and servers used in the frame of the contract by a login/password
mechanism, with an anti-virus package, which is updated automatically. This anti-virus
solution must control files received from mail, Internet and media or stored locally.
Ensure logical or physical separation between the IT environments related to development, test,
training & demos.
The contractor will describe the security system that it applies in a security plan delivered to the
Commission (see WP.0.14.1).
The Commission’s information systems security policy is defined in Commission Decision (EU,
Euratom) 2017/46 of 10 January 2017 on the security of communication and information systems in the
European Commission [R32], its implementing rules [R31] and corresponding security standards for
further implementation. At Directorate General-level, DG TAXUD has issued and continuously updates
the TEMPO security management documents which define the DG information systems security policy
compliant with the EC security policy.
Page 194 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
SECURITY REQUIREMENTS
The Contracting authority reserves the right to impose additional specific physical and logical security
rules in the future, should the need arise.
The Contracting authority reserves the right to perform security audits of the service organisation in the
contractor’s premises. The Commission may appoint a third party to perform these audits. The
contractor commits to co-operate fully with the Commission and, if applicable, such third party during
the audits (refer to work package WP.0.5). In particular, the contractor commits

To authorise the access to the whole of the service information located at his premises no later
than two weeks after the request of the Contracting authority,

To answer the questions from the Contracting authority during those audits (or its elected thirdparty contractor and

To provide the evidences required during those audits.
Access to the Commission internal network and computer environment is ruled by a security convention
which must be signed by the contractor, IRM, DIGIT and the Security Directorate before a connection
may be made. See ‘Procedure for the creation and amendment of a Security Convention [R30]’ as well
as ‘Guidelines for the preparation of Security Convention for remote access [R29]’.
Each staff member assigned by the contractor must sign a declaration of confidentiality in compliance
with article III.2.2. of the general terms and conditions for IT contracts, with art 12 of the Commission
Decision (EU, Euratom) 2017/46 of 10 January 2017 on the security of communication and information
systems in the European Commission and with art.29 and art.30 of Regulation (EU) 2018/1725 of the
European Parliament and of the Council of 23 October 2018 on the protection of natural persons with
regard to the processing of personal data by the Union institutions, bodies, offices and agencies and on
the free movement of such data.
The contractual confidentiality clauses apply to all team members of the contractor.
The Commission may require, if the need arises, that key staff get a security clearance from a Member
State national security authority.
Page 195 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
GENERAL REQUIREMENTS
12.
General Requirements
12.1 Interaction Model with Stakeholders
The contractor will perform the activities under the authority and close control of the Commission, in
function of the organisation in place at the Commission, and in full compliance with the existing
Framework Quality Plan (FQP). The instruments of this control shall include all the deliverables
specified in the WP.0 Management Work Package.
In terms of inter-relationship between DG TAXUD contractors, the contractor reports to the
Commission only. In some specific circumstances, the Commission may authorise the establishment of
direct working technical relationships between DG TAXUD contractors in order to improve the overall
efficiency.
However, the Commission will always retain the full control over, and require full traceability of the
information exchanged between the contractors. It is important to recognise that delays incurred by one
contractor will ripple down to the other parties downstream, implying that all contractors must take
adequate steps to address this risk.
In terms of interaction with the Commission, the contractor has to set up an organizational structure that
can effectively interact with the one in place in the Commission. This interaction has to fit with the team
structure requirements as specified in section 6.1 and the Agile methodology specified in section 3.3 of
the Tender Specifications - Part B (Terms of Reference), especially its “ceremonies”.
For information on the internal DG TAXUD service organisation and for the contractual aspects of DG
TAXUD, refer to Tender Specifications - Part B (Terms of Reference), chapter 2’.
The specification and implementation of a pragmatic and effective interaction model between the
contractor and the Commission is a key activity for the SOFT-DEV contractor to perform following the
kick-off of the contract.
The key objective of this interaction model is to establish a structured and effective communication and
collaboration framework between the two parties (DG TAXUD and contractor) – which will be
supported and driven by Single Points Of Contacts (SPOCs) nominated by each of the two parties at
contractual and technical level. Each nominated SPOC will be clearly reflected in the organisational
structure and it will be responsible for coordinating activities within its own domain.
In the context of the SOFT-DEV contract, the contractor will interact mainly with units B1, B2, B3 and
B4 of DG TAXUD, and in particular with the sectors, which are, at the time of writing:

The “Customs Code and Project Management” sector of Unit B1 (alias B1/CCPM), and

The “eCustoms” sector of Unit B1 (alias B1/EC), and

The ‘Data integration and harmonisation’ sector of Unit B1 (alias B1/DIH), and

The “Resources and Governance” sector of Unit B4 (alias B4/R&G), and

The “Enterprise IT architecture and Strategy” sector of Unit B2 (alias B2/EAS), and

The “Infrastructure and IT Service Delivery” sector of Unit B2 (alias B2/ISD), and

The “Customs Information Systems” sector of Unit B3 (alias B3/CIS). and

The “Special IT Development projects” sector of Unit B3 (alias B3/ICS2), and

The "Taxation Information Systems" sector of Unit B4 (alias B4/TIS).
For security-related activities and issues, the contractor will need to interact with the “B2/LISO” sector.
For each of the above sectors, SPOCs will be nominated by the Commission for managing and
coordinating effort and activities with the SPOCs nominated by the SOFT-DEV contractor.
The implementation of the interaction model will be specified in the FQP.
A brief description of the interactions between the contractor and the Commission’s SPOCs identified
above is as follows:
Page 196 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
GENERAL REQUIREMENTS

Interactions between B1/CCPM sector and contractor
The contractor will interact with the B1/CCPM sector in the context of all actions related
to the UCC electronic systems and to the Business processing and modelling methodology.

Interactions between B1/EC sector and contractor
The contractor will interact with the B1/EC sector in the context of all actions mainly
related to business aspects of the eCustoms systems, in particular to the developments of
the EU Single Window environment for customs.

Interactions between B1/DIH sector and contractor
The contractor will interact with the B1/DIH sector in the context of all actions mainly
related to data integration and harmonisation aspects of the UCC and eCustoms systems.

Interactions between B2/EAS sector and contractor
The contractor will interact with the B2/EAS sector in the context of all actions mainly
related to enterprise architecture, strategy and the SPEED2 platform.

Interactions between B3/CIS sector and contractor
The contractor will interact with the B3/CIS sector mainly for IT development and support
services for the customs IT systems and applications.

Interactions between B2/ISD sector and contractor
The contractor will interact with B2/ISD sector in the context of all ITSM related activities
and the TAXUD Data Centre hosting aspects.

Interactions between B2/LISO sector and contractor
The B4/LISO sector interacts with the contractor in activities related to security.

Interactions between B4/R&G sector and contractor
The B4/R&G sector interacts with the contractor in activities related to TEMPO
methodology, knowledge management and in the context of contract and supply
management.
It must be noted that several horizontal services to be delivered span the different sectors and will
require additional coordination.
In addition to the interactions with the units/sectors (as described above), the SOFT-DEV contractor will
also interact with other DG TAXUD contractors.
In the context of the SOFT-DEV contract, the contractor will interface with the Quality Assurance and
Control contractor in the context of deliverables review/acceptance process and in the context of
quality audits. The Commission will identify to the SOFT-DEV contractor the SPOC for the QA & QC
contractor.
In the context of the SOFT-DEV contract, the contractor will interact with the ITSM operations and
ITSM TES contractors in the context of knowledge sharing, service transitions and operational aspects
of the systems and services in this Technical Annex. Furthermore, the contractor can be involved in the
context of benchmarking and assessment, advice and control and integration of the services offered by al
DG TAXUD contractors and the ITSM integration contractor.
The contractor can also have other contacts with e.g. other units of DG TAXUD, other DGs of the
Commission and the National Administrations.
The above is not meant to be exhaustive and can be subject to changes during the contract.
12.2 Contractor availability
The SOFT-DEV working days are all days from Mondays to Fridays idenpendantly of any Public or
Commission holidays (for example if 1 January falls on Wednesday, this day will be considered as a
working day). This applies to all activities/services/WPs linked to the framework contract except
WP.8.8.1 and WP.8.8.2.
Page 197 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
GENERAL REQUIREMENTS
The SOFT-DEV working hours are from 7 a.m. to 8 p.m. on SOFT-DEV working days for the
following activities/services/WPs linked to the framework contract:

WP.8.1.1 (Incident management) and WP.8.1.2 (Problem Management). If an incident has
been assigned to the SOFT-DEV contractor with ‘critical’ priority, the contractor will
continue working until the incident is resolved even if this requires the staff to continue
working outside these working hours. A ‘critical’ incident for which a software bug has
been identified as the root cause may imply the delivery of an emergency fix (alias hotfix)
in order to resolve the incident. As for the incident resolution, the SOFT-DEV contractor
must continue to work outside working hours to deliver such an emergency fix by
repairing the defect (WP.8.1.4), performing qualification testing (WP.7.5.4), delivering the
software (WP.8.3.1) and delivering the support to service transition services (WP.8.3.2) if
applicable.
The SOFT-DEV “call availability outside working hours” services are linked to WP.8.8.1 and are to
be performed from 8 p.m. to 7 a.m. on the SOFT-DEV working days and for 24 hours on the SOFTDEV non-working days.
The SOFT-DEV “extended time – ad hoc” services are linked to all activities/services/WPs described
under WP.8.8.2 and can be performed, in exceptional cases or, on request of the Commission, from 8
p.m. to 7 a.m. on the SOFT-DEV working days and for 24 hours on the SOFT-DEV non-working days.
This could be the case for, e.g.:


Off Site support outside working hours in case of a business continuity crisis’s or for 3 rd
level support, build and test and package patches and support to the operational teams for
deploying the patches,
On Site presence if needed for urgent and operational needs mainly linked to the
deployment of new systems/components.
12.3 Place of Work
The activities and services covered by this Framework Contract will be performed primarily at the
contractor’s premises (extra-muros) situated in the territory of one or more of the EU Member
States, EXCLUDING ANY services provided from contractor locations outside the EU territory.
The contractor may also be requested to perform missions (refer to WP.8.6.3).
Meetings with the Commission services are generally held in the premises of DG TAXUD. Some
meetings may also be held at the premises of another contractor involved in the service or at the
premises of the National Administrations.
Trainings, workshops and demonstrations with National Administrations are generally held at the
Contractor’s premises.
However, the Commission can request as well the Contractor to execute some specific activities/services
from the Commission’s or a national administration’s premises (intra-muros).
The intra-muros vs. extra-muros ratio must not exceed 10%:90%. The contractor must take note that this
is a provision and not a commitment from the Commission; the services being normally executed extramuros.
All meetings/activities (e.g. mission) at the Contracting Authority’s premises (Brussels and
Luxembourg) and/or at any other contractor’s premises within a distance of ≤ 50 km of the Contracting
Authority’s premises are to be included in the quoted prices for services, including the travel and
subsistence costs. The contractor is responsible for including in his offer human resources required to
attend meetings in the Contracting Authority’s premises.
Please note that no Travel and Subsistence fees will be paid for the trainings/workshops/
demos/meetings/missions during the whole Take-Over period. These Travel and Subsistence fees
must be included in the overall Take-Over price PE3 and PE4 as proposed by the tenderer in their offer.
Page 198 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
GENERAL REQUIREMENTS
For all required and contracted “out of contractor’s premises” activities, other than those addressed
above in 4.5, travel and subsistence costs will be covered by price element PE34. This includes e.g.
missions.
12.4 Languages
The required services must be provided at least in English. All deliverables must be delivered in UK
English unless otherwise specified. During meetings (bilateral, workshops, steering Committee, etc.),
either French or English will be spoken subject to agreement of all participants of the meeting.
At request of DG TAXUD, the contractor may have to translate certain deliverables (in particular the
ones destined to the Member States, e.g. some key project deliverables, communication leaflets,
newsletters, news alerts etc.). Deliveries in any other language will be handled via translations (See
WP.8.5.5).
12.5 Deliverables
The contractor must deliver the produced artefacts electronically, on paper only if requested, using the
Commission office automation tools and according to the procedures defined in the FQP. The
Commission may request the contractor to redeliver the deliverables on a DVD-ROM media. All written
artefacts are to be produced in English, unless stated otherwise. Some documents may need translation
into EN, DE or FR.
All artefacts must be anonymized.
12.6 Implicit Non-Functional Requirements
Despite any explicit non-functional requirements expressed for the application and in complement to
them under development the contractor shall in all cases consider and document the application of the
following non-functional requirements and the level to which they apply to the system both from the
design and the operations perspectives:

Performance: be it in response times, throughput or both depending of the type of
interface and that across each interface of the system input output and internal
interfaces).

Scalability: either horizontal or vertical scalability for each independent element
(service, repository, interface, etc.) measured according to the relevant application
volumetric metrics (i.e. concurrent users, number of messages, service requests…).

Robustness: the capacity of the system to continue functioning even if in a degraded
mode after a failure in a middleware or infrastructure dependent component (e.g. fail
or restart of a managed server, fail of a Database connections, etc.).

User Friendliness: the explicit user interface implementations that seek facilitate the
use of the application to the user; as for example reducing the number of actions to
full fill a task and to avoid repetitive actions. The eUI and ECL frameworks apply for
web applications.

Security: all measures taken to ensure that the security measures defined by TAXUD
policy are respected and that no security weakness arise due to the specific design or
implementation of the application (including the use of COTS or open source
components or libraries).
The documentation of the system must explicitly describe in the architecture documents (Architecture
Overview and Application Models) and in the operational documents (Operational Model and
Administration Model) all measure taken in relation to each of the above items. This applies even if the
measures are in the negative (e.g. no horizontal or vertical scalability specific design applied). In all
Page 199 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
GENERAL REQUIREMENTS
cases the documentation describes what measures are taken at application level and which ones rely on
platform or infrastructure and how it does so.
In case of COTS or open source components being integral part of the system the above still applies
though the contractor can rely on the COTS or open source provider documentation.
Any measure taken at application level must be taken into account in the test plan scenarios.
12.7 Knowledge Base
The tenderer is reminded to detail the way that the knowledge base is deployed, fed and maintained up
to date.
Currently, DG TAXUD has set up an internal Knowledge base built on Confluence. All knowledge
gathered across DG TAXUD’s activities is stored and shared with all the stakeholders in order to ensure
the coherence, consistence, and integrity across all the sectors. The information is maintained up-to-date
and continuously improved to maximize its outcome for DG TAXUD.
DG TAXUD’s contractors can introduce the information in the knowledge base either by uploading it or
by providing a link to other repositories. Any additional relevant gathered knowledge is encoded by the
contractor in the form of original wiki pages or contributions to existing wiki pages. The overall
knowledge base of applications and IT systems should be secured in order to be used e.g. at time of
take-over / change-over between contractors.
12.8 Ownership
All deliverables become the property of the Commission once accepted. The Commission is then the
only party that can authorise their further use and distribution. All deliverables of the contract are free of
IPR from 3rd parties (unless otherwise accepted by the Commission), and in particular the processes, the
procedures, the tools, the knowledge/information/data repository, the bespoke software, configuration
and scripts and other artefacts produced by the contractor to support his service delivery to the
Commission.
None of the deliveries may refer to documentation or other artefacts owned by the contractor which
would not be publicly and freely available.
The Intellectual property rights will be implemented as defined in art. I.10. of the Framework contract.
Page 200 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
13.
Appendix 1 - Detailed information on SQIs,
KPIs and PIs
13.1 Introduction
The reporting of the applicable KPIs, SQIs and GQI applicable in a SC (i.e. Horizontal one covering
Continuous Services) or in RfAs will be performed and reported in the MPR/MSR on a monthly basis.
The evaluation of the GQI, SQIs and KPIs applicable at SC level will be performed on a monthly basis.
However, the final measurement of the GQI will be performed at the closure time of the SC.
The evaluation/measurement of the KPIs, SQIs and GQI applicable at RFA level will be performed at
the closure time of the RFA.
Liquidated Damages
The Liquidated Damages (LD) may be applied by the Contracting Authority, when the measured
performance of the contractor in the context of an SC and/or RFA does not reach the required Service
Levels. In general, Liquidated Damagaes may be applied by DG TAXUD at SC level and/or at RfA
level.
The maximum amount of Liquidated Damages (LD) that may be applied at SC level (e.g. Horizontal
SC), when only the GQI is used for measuring quality/performance of services, is capped to 20% of the
FP provision defined in the SC. However, if KPIs are also used for measuring quality/performance of
specific services on top of the GQI, the amount of LDs may reach at maximum the 50% of the FP
provision defined in the SC. Any amount of LD will be combined with the acceptance and invoicing of
the MPRs and must be deducted by the contractor from the relevant invoice. Please refer to section
13.3.2 below for the calculation of LD at SC level.
The maximum amount of due Liquidated Damages (LD) that may be applied at RfA level is capped to
20% of the RFA’s total value, when only the GQI is used for measuring performance/quality of services.
However, the amount of LDs may reach at maximum the 50% of the RfA’s total value, if KPIs are also
used in the RfA to measure quality/performance on top of the GQI applied in the RfA. Any amount of
LD will be combined with the closure and acceptance of the RFA and must be deducted by the
contractor from the relevant invoice. Please refer to section 13.3.2 below for the calculation of LD at
RfA level.
The Contracting Authority will solely decide, when ordering a service via an SC or RfA, which KPIs
and/or SQIs will be used for measuring contractor’s performance and/or quality of services.
By submitting an offer in response to this this Call for Tenders, the tenderer accepts without
reserve the content of section 13 of this document, including the fact that the Contracting Authority
solely decides on the use of KPI and / or SQI on the services ordered.
13.2 The Key Performance indicators (KPI)
The amount of Liquidated Damages is expressed in Liquidated Damages Units (LDUs). The amount of
1 LDU is defined in “Annex 6 – Price Table”.
We want to draw the attention to the fact that the notion of KPI Limit is different than the notion
of SQI Limit, namely Liquidated damages apply for KPIs above the KPI limit value while for SQIs at
the SQI Limit value liquidated damages are already applicable.
Page 201 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
The Key Performance indicators are described with the following table:
KPI Attribute
KPI Attribute description
KPI Name
A name, which allows to fully identify the KPI.
KPI Description
A complete description of the KPI.
Unit of Measurement of the KPI
Defines the Unit of Measurement of the KPI. For
example, a KPI aiming to evaluate duration or delays
can be expressed in working hours or working days.
KPI Target
Target, which sets the level of the measurement that, if
reached, would demonstrate good QoS.
KPI Limit
Together with the Target, the Limit defines the “grace
window” “, within which although the QoS is below
target, the KPI is still immunised from negative impact.
Reporting Period
Monthly
Minimum
number
Measurements
of
Minimum number of measurements or set of
measurements necessary for a KPI to be computable.
KPI calculation
Defines the calculation method of the KPI
Liquidated Damages
Defines the calculation method of the liquidated
Damages for the applicable KPI
13.2.1 Key Performance Indicators (KPI) definitions
13.2.1.1 Deadlines of deliverables, corrections and iterations
KPI01
KPI Attribute
KPI Attribute description
KPI Name
KPI01
KPI Description
Measure the respect of the deadline of deliverables whose delay would
have a major impact (SfA)
Unit of Measurement of the KPI
Working Days
KPI Target
“0 delay” for acceptance
KPI Limit
1 Working Day
Reporting period
Monthly
Minimum number of Measurements
1 deliverable
KPI Calculation
The Actual Delivery Date (ADD) is the date the deliverable is
uploaded on the agreed deliverable provision tool (e.g. CIRCABC or
Application Lifecycle Management platform described in section
Page 202 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
8.5.1). When the deliverable must be uploaded several times on the
latter tool for acceptance, the Actual Delivery Date is the date of the
last upload for acceptance.
For each re-SfA, the number of days to be considered in the
calculation of this KPI will be the number of days between the
moment the contractor received the IVE_NOK (or request for re-SfA
from DG TAXUD) and the moment the new version of the deliverable
has been uploaded.
The Planned Delivery Date (PDD) of the deliverable is defined in the
last approved version of the DTM for all deliverables.
The Correction Delay (COD) of the deliverable is a number of
working days to neutralize from the KPI calculation based on a
justification provided by the contractor and subject to acceptance by
the Contracting Authority. By default, the COD has a value of 0
Working Days.
N is the total number of all accepted deliverables having their Actual
Delivery Date (ADD) within the reporting period.
The KPI is calculated as follows:
For every deliverable x the Measured Delay (MED) expressed in
Working Days is calculated as follows:


If ADDx ≤ PDDx  MEDx = 0
If ADDx > PDDx  MEDx = (ADDx - PDDx) - CODx ,
should the resulting value be negative because of the
Correction Delay CODx, then MEDx = 0
The KPI value expressed in Working Days is the sum of the Measured
Delays :
𝑁
𝐾𝑃𝐼 = ∑ 𝑀𝐸𝐷𝑛
𝑛=1
Liquidated Damages
8 LDU per Working Day of delay strictly above the limit
Deliverable 1 : delivered 3 Working Days late without valid
justification:
ADD1 = 29/07/2019; PDD1 = 24/07/2019; COD1 = 0
MED1 = (29/07/2019 – 24/07/2019) – 0 = 3 (days late)
Example
Deliverable 2 : delivered 2 Working Days early
ADD2 = 22/07/2019; PDD2 = 24/07/2019; COD2 = 0
MED2 = 0 because ADD2 ≤ PDD2
(Note: an early deliverable does not compensate for other late
Page 203 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
deliverables)
Deliverable 3 : delivered 3 Working Days late with valid justification
for 2 Working Days of delay
ADD3 = 29/07/2019; PDD3 = 24/07/2019; COD3 = 2
MED3 = (29/07/2019 – 24/07/2019) – 2 = 1 (day late)
KPI = MED1 + MED2 + MED3 = 3 + 0 + 1 = 4
The KPI Value being 3 Working Days above the Limit (of 1 working
day), Liquidated Damages amounting to 3 x 8 LDU = 24 LDU may be
applied
KPI02
The information given for KPI01 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI02
KPI Description
Measure the respect of the deadline of deliverables whose delay would
have a high impact (SfA)
KPI Target
“0 delay” for acceptance
KPI Limit
5 Working Days
Liquidated Damages
4 LDU per Working Day of delay strictly above the limit
KPI03
The information given for KPI01 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI03
KPI Description
Measure the respect of the deadline of deliverables whose delay would
have a medium impact (SfA)
KPI Target
“0 delay” for acceptance
KPI Limit
10 Working Days
Liquidated Damages
2 LDU per Working Day of delay strictly above the limit
Page 204 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI04
The information given for KPI01 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI04
KPI Description
Measure the respect of the deadline of deliverables whose delay would
have a low impact (SfA)
Unit of Measurement of the KPI
Working Days
KPI Target
“0 delay” for acceptance
KPI Limit
15 Working Days
Liquidated Damages
1 LDU per Working Day of delay strictly above the limit
KPI05
KPI Attribute
KPI Attribute description
KPI Name
KPI05
KPI Description
Measure the number of bugs or defects detected during an Agile
iteration which are not corrected at the end of the following iteration.
Unit of Measurement of the KPI
Number of bugs or defects
KPI Target
“0 delay” for acceptance
KPI Limit
1 bug or defect unfixed by 25 points of the RfA's final IFPUG and
SNAP count. For example, for a software release sized at 600 points
(IFP and SNAP), the limit is equal to 24 units of bugs or defects, for a
release sized at 300 points, the limit is equal to 12 units.
Reporting period
Monthly
Minimum number of Measurements
1 bug or defect
Bugs or defects, including critical source code quality issues, detected
during an iteration must be fixed by the end of the following iteration.
An iteration ends when its iteration review is completed. Bugs,
defects, etc. detected during the last iteration must be fixed before the
SfR date of their corresponding deliverables.
KPI Calculation
A bug or defect left unfixed at the end of an iteration counts as one
measurement. The KPI measures their cumulative count. As an
example, a bug detected during the review meeting of iteration N, not
fixed during iteration N+1, still not fixed during iteration N+2 and
finally fixed during iteration N+3 therefore counts as 2 units.
The KPI will be calculated after the final count of IFP and SNAP
Page 205 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
points for the release.
Liquidated Damages
4 LDU per unit strictly above the limit, measured as the difference
between the cumulative count and the value of the limit.
Example
A release counted as 300 points will have a limit value of 12 units. If
the cumulative count of measurements is 15, the number of units
strictly above the limit is 3, leading to 3x4=12 LDU.
KPI06
KPI Attribute
KPI Attribute description
KPI Name
KPI06
KPI Description
Measure the respect of the Agile iteration calendar
Unit of Measurement of the KPI
Working days
KPI Target
0 delay
KPI Limit
1 working day per 3 iterations in the Agile iteration phase covered by
the RfA, computed as the number of iterations in the Agile iteration
phase divided by 3 and rounded down. For RfA having less than 3
iterations, the limit is equal to 1 working day.
Example: 13 iterations will lead to a limit of 4 working days
Minimum number of Measurements
1 deliverable
The KPI will be calculated at the end of the iteration phase.
For each iteration i:
ADi is the actual date of the review meeting,
KPI Calculation
PDi is the planned date of that meeting according to the release
planning.
The measured delay MDi is
MDi = ADi-PDi if ADi>PDi; MDi=0 otherwise.
The KPI value expressed in working days is the sum of the measured
delays for the N iterations of the in Agile iteration phase:
Page 206 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
𝑁
𝐾𝑃𝐼 = ∑ 𝑀𝐷𝑛
𝑛=1
A measured delay can be neutralised by DG TAXUD if justified.
Liquidated Damages
8 LDU per working day of delay strictly above the limit
13.2.1.2 Service Levels
KPI11
KPI Attribute
KPI Attribute description
KPI Name
KPI11
KPI Description
Measure incidents resolution time
Unit of Measurement of the KPI
%
KPI Target
95% “0 delay”
KPI Limit
90%
Reporting Period
Monthly
Minimum number of Measurements
1 incident ticket
Incident priority will be set by the ITSM3-OPS contractor for 3rd level
incidents according to the rules defined in ITSM FQP (Ref: FQP of the
incumbent ITSM contractor: [R52]) or by the SOFT-DEV contractors
for calls opened directly by the SOFT-DEV contractors according to
the rules defined in its FQP.
Incident priority is calculated based on impact and urgency when
creating the call according to the following table:
KPI Calculation
Impact\Urgency
Low
Medium
High
Low
4
3
2
Medium
3
2
1
High
2
1
1
The Contracting Authority may request to override the
impact/urgency values at any time to a value of its choosing. Such a
change will not result in a resolution time reset.
The maximum resolution time is, depending on the priority of the
Page 207 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
incident:
P1 – Critical  4 Working Hours
P2 – High  1 Working Day
P3 – Normal  2 Working Days
P4 – Low  4 Working Days
An incident is resolved when IT service operation is restored in its
normal state (without reduction of quality of service).
The Total of Incidents of Priority Pn (TOTn) is the total number of
incidents tickets of priority Pn resolved by the contractor for which all
interactions are closed during the reporting period
The Resolved In Contractual OLA21 Incidents of Priority Pn (RISn)
is the total number of incidents tickets of priority Pn resolved by the
contractor for which all interactions are closed during the reporting
period, where the resolution time is lower than or equal to the
maximum resolution time as defined for the Priority P n.
For each priority Pn a Relative Weight (RWn) is assigned as follows:
P1 – Critical  RW1 = 16
P2 – High  RW2 = 4
P3 – Normal  RW3 = 2
P4 – Low  RW4 = 1
The KPI expressed as a percentage is calculated as follows :
𝐾𝑃𝐼 =
21
∑4𝑛=1(𝑅𝐼𝑆𝑛 𝑋 𝑅𝑊𝑛 )
∑4𝑛=1(𝑇𝑂𝑇𝑛 𝑋 𝑅𝑊𝑛 )
In the absence of Contractual OLA, the definitions of the KPIs and SQIs of this Techical Annex are
fully applicable.
Page 208 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
When the KPI is below the Limit, for each Incident not resolved within
the appropriate resolution time the following Liquidated Damages will
be applied:
P1 – Critical  LD1 = 16 LDU per P1 ticket not in
Contractual OLA
P2 – High  LD2 = 4 LDU per P2 ticket not in Contractual
OLA
P3 – Normal  LD3 = 2 LDU per P3 ticket not in
Contractual OLA
Liquidated Damages
P4 – Low  LD4 = 1 LDU per P4 ticket not in Contractual
OLA
Thereby the Total Liquidated Damages applicable for the reporting
period will be represented by the following formula:
4
𝐿𝐷 = ∑(𝑇𝑂𝑇𝑛 − 𝑅𝐼𝑆𝑛 ) 𝑋 𝐿𝐷𝑛
𝑛=1
For the reporting period, these were the incidents figures
Out
In
Example
Contrac
tual
OLA
of
Contrac
tual
OLA
Tickets
(RIS)
Tickets
(TOT - Relative
RIS)
Weights
LDU
per
Ticket
not in
Priority
Total
Tickets
(TOT)
P1
1
0
1
16
16
P2
2
1
1
4
4
P3
11
9
2
2
2
P4
1
1
0
1
1
Contrac
tual
OLA
Thereby the KPI is calculated as follows:
KPI = (0x16 + 1x4 + 9x2 + 1x1) / (1x16 + 2x4 + 11x2 + 1x1) = 48,9%
Consequently as the KPI is under the Limit, Liquidated Damages are
calculated as follows :
LD = (1x16 + 1x4 + 2x2 + 0x1) = 24 LDU
In this example Liquidated Damages amounting to 24 LDU may be
applied
Page 209 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI12
KPI Attribute
KPI Attribute description
KPI Name
KPI12
KPI Description
Measure the problem resolution time
Unit of Measurement of the KPI
%
KPI Target
95% “0 delay”
KPI Limit
90%
Reporting Period
Monthly
Minimum number of Measurements
1 problem ticket
Problem priority will be set by the ITSM3-OPS contractor for 3rd level
calls according to the rules defined in ITSM FQP (Ref: FQP of the
incumbent ITSM contractor: [R52]) or by the SOFT-DEV contractors
for calls opened directly by the SOFT-DEV contractors according to
the rules defined in its FQP.
Problem priority is calculated based on impact and urgency when
creating the call according to the following table:
Impact\Urgency
KPI Calculation
Low
Medium
High
Low
4
3
2
Medium
3
2
1
High
2
1
1
The Contracting Authority may request to override the
impact/urgency values at any time to a value of its choosing. Such a
change will not result in a resolution time reset.
The maximum resolution time is, depending on the priority of the
problem:
P1 – Critical  1 Working Hours
P2 – High  3 Working Day
P3 – Normal  5 Working Days
P4 – Low  10 Working Days
A problem is resolved when Root Cause Analysis is performed and
the root causes linked to this problem/event are detected. The Closure
Request is triggered by the sending to the SfR of the problem report.
The Total of Problems of Priority Pn (TOTn) is the total number of
problem tickets of priority Pn resolved by the contractor for which all
Page 210 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
interactions are closed during the reporting period
The Resolved In Contractual OLA Problems of Priority Pn (RISn)
is the total number of problem tickets of priority Pn resolved by the
contractor for which all interactions are closed during the reporting
period, where the resolution time is lower than or equal to the
maximum resolution time as defined for the Priority P n.
For each priority Pn a Relative Weight (RWn) is assigned as follows:
P1 – Critical  RW1 = 16
P2 – High  RW2 = 4
P3 – Normal  RW3 = 2
P4 – Low  RW4 = 1
The KPI expressed as a percentage is calculated as follows :
𝐾𝑃𝐼 =
∑4𝑛=1(𝑅𝐼𝑆𝑛 𝑋 𝑅𝑊𝑛 )
∑4𝑛=1(𝑇𝑂𝑇𝑛 𝑋 𝑅𝑊𝑛 )
When the KPI is below the Limit, for each Problem not resolved within
the appropriate resolution time the following Liquidated Damages will
be applied:
P1 – Critical  LD1 = 16 LDU per P1 ticket not in
Contractual OLA
P2 – High  LD2 = 4 LDU per P2 ticket not in Contractual
OLA
Liquidated Damages
P3 – Normal  LD3 = 2 LDU per P3 ticket not in
Contractual OLA
P4 – Low  LD4 = 1 LDU per P4 ticket not in Contractual
OLA
Thereby the Total Liquidated Damages applicable for the reporting
period will be represented by the following formula:
4
𝐿𝐷 = ∑(𝑇𝑂𝑇𝑛 − 𝑅𝐼𝑆𝑛 ) 𝑋 𝐿𝐷𝑛
𝑛=1
Page 211 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
For the reporting period, these were the problems figures
Out
In
Example
Contrac
tual
OLA
of
Contrac
tual
OLA
Tickets
(RIS)
Tickets
(TOT - Relative
RIS)
Weights
LDU
per
Ticket
not in
Priority
Total
Tickets
(TOT)
P1
0
0
0
16
16
P2
3
2
1
4
4
P3
9
3
6
2
2
P4
1
0
1
1
1
Contrac
tual
OLA
Thereby the KPI is calculated as follows:
KPI = (0x16 + 2x4 + 3x2 + 0x1) / (0x16 + 3x4 + 9x2 + 1x1) = 45,2%
Consequently as the KPI is under the Limit, Liquidated Damages are
calculated as follows :
LD = (0x16 + 1x4 + 6x2 + 1x1) = 17 LDU
In this example Liquidated Damages amounting to 17 LDU may be
applied
KPI13
KPI Attribute
KPI Attribute description
KPI Name
KPI13
KPI Description
Measure the Change Impact Assessment resolution time
Unit of Measurement of the KPI
%
KPI Target
95% “0 delay”
KPI Limit
90%
Reporting Period
Monthly
Minimum number of Measurements
1 change
KPI Calculation
The change type will be set by the SOFT-DEV contractor in line with
Page 212 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
the priority of the related incident/problem/defect and according to the
rules defined according to the rules defined in its FQP.
The Contracting Authority may request to override the type of
the change at any time. Such a change will not result in a resolution
time reset.
The maximum resolution time is, depending on the type of the
change:
Type 1 - Emergency  2 Working Days
Type 2 - Corrective  10 Working Day
Type 3 - Evolutive  15 Working Days
A change is assessed when the Impact Assessment is performed and
the related Impact Assessment document linked to this change is
available. The Closure Request is triggered by the sending to the SfR of
the Impact Assessment document and uploading it in the request
tracking system.
The Total of Changes of Type Tn (TOTn) is the total number of
changes of type Tn assessed by the contractor during the reporting
period
The Resolved In Contractual OLA Changes of Type Tn (RISn) is the
total number of changes of type Tn assessed by the contractor during
the reporting period, where the resolution time is lower than or equal to
the maximum resolution time as defined for the Type T n.
For each priority Pn a Relative Weight (RWn) is assigned as follows:
Type 1 - Emergency  RW1 = 16
Type 2 - Corrective  RW2 = 4
Type 3 - Evolutive  RW3 = 2
The KPI expressed as a percentage is calculated as follows :
𝐾𝑃𝐼 =
Page 213 of 244
∑3𝑛=1(𝑅𝐼𝑆𝑛 𝑋 𝑅𝑊𝑛 )
∑3𝑛=1(𝑇𝑂𝑇𝑛 𝑋 𝑅𝑊𝑛 )
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
When the KPI is below the Limit, for each Ticket not resolved within
the appropriate resolution time the following Liquidated Damages will
be applied:
Type 1 - Emergency  LD1 = 16 LDU per Emergency
change not in Contractual OLA
Type 2 - Corrective  LD2 = 4 LDU per Corrective change
not in Contractual OLA
Liquidated Damages
Type 3 - Evolutive  LD3 = 2 LDU per Evolutive change not
in Contractual OLA
Thereby the Total Liquidated Damages applicable for the reporting
period will be represented by the following formula:
3
𝐿𝐷 = ∑(𝑇𝑂𝑇𝑛 − 𝑅𝐼𝑆𝑛 ) 𝑋 𝐿𝐷𝑛
𝑛=1
For the reporting period, these were the changes figures
Out
In
Example
Contrac
tual
OLA
of
Contrac
tual
OLA
Tickets
(RIS)
Tickets
(TOT - Relative
RIS)
Weights
LDU
per
Ticket
not in
Type
Total
Tickets
(TOT)
Critical
1
0
1
16
16
Correcti
ve
3
3
0
4
4
Evoluti
ve
2
1
1
2
2
Contrac
tual
OLA
Thereby the KPI is calculated as follows:
KPI = (0x16 + 3x4 + 1x2) / (1x16 + 3x4 + 2x2) = 43,8%
Consequently as the KPI is under the Limit, Liquidated Damages are
calculated as follows :
LD = (1x16 + 0x4 + 1x2) = 18 LDU
In this example Liquidated Damages amounting to 18 LDU may be
applied
Page 214 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI14
The information given for KPI11 applies with the following changes and replacing “Incident” by
“RFS/RFI”:
KPI Attribute
KPI Attribute description
KPI Name
KPI14
KPI Description
Measure the Requests for Service (RFS) and Requests for Information
(RFI) resolution time
Unit of Measurement of the KPI
%
KPI Target
95% “0 delay”
KPI Limit
90%
Reporting Period
Monthly
Minimum number of Measurements
1 RFS or RFI ticket
KPI Calculation
The maximum resolution time is 5 working days.
Liquidated Damages
When the KPI is below the Limit, for each RFS/RFI not resolved
within the appropriate resolution time the following Liquidated
Damages will be applied:
LD = 2 LDU per ticket not in Contractual OLA
13.2.1.3 Software releases, hotfixes and patches
KPI21
KPI Attribute
KPI Attribute description
KPI Name
KPI21
KPI Description
Measure the corrective issue resolution – hotfix delay
Unit of Measurement of the KPI
Working Days
KPI Target
0 Working Day
KPI Limit
1 Working Day
Reporting period
Monthly
Minimum number of Measurements
1 hotfix to be delivered
KPI Calculation
The Actual Delivery Date (ADD) is the date when the hotfix (fixing
the Root Cause of the problem) is delivered to the ITSM3OPS
contractor for deployment (incl. testing).
Depending on the priority, unless a different date is agreed with DG
TAXUD in writing, the Planned Delivery Date (PDD) of the hotfix is
Page 215 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
defined respectively to the related problem resolution time as:
P1 – Critical  1 Working Day
P2 – High  3 Working Days
P3 – Normal  5 Working Days
P4 – Low  Next release (as agreed with TAXUD)
P5 – COTS  10 Working Days (to be used for WP 8.1.5)
The Correction Delay (COD) of the hotfix is a number of working
days to neutralize from the KPI calculation based on a justification
provided by the contractor and subject to acceptance by the
Contracting Authority. By default, the COD has a value of 0 Working
Days.
N is the total number of hotfixes having their Actual Delivery Date
(ADD) within the reporting period.
The KPI is calculated as follows:
For every hotfix x the Measured Delay (MED) expressed in Working
Days is calculated as follows:


If ADDx ≤ PDDx  MEDx = 0
If ADDx > PDDx  MEDx = (ADDx - PDDx) - CODx ,
should the resulting value be negative because of the
Correction Delay CODx, then MEDx = 0
The KPI value expressed in Working Days is the sum of the Measured
Delays :
𝑁
𝐾𝑃𝐼 = ∑ 𝑀𝐸𝐷𝑛
𝑛=1
When the KPI is above the Limit, for each hotfix not delivered within
the appropriate Planned Delivery Date the following Liquidated
Damages will be applied per hotfix priority:
P1 – Critical  LD1 = 8 LDU per Working Day of delay
Liquidated Damages
P2 – High  LD2 = 4 LDU per Working Day of delay
P3 – Normal  LD3 = 2 LDU per Working Day of delay
P4 – Low  LD4 = 1 LDU per Working Day of delay
P5 – COTS  LD5 = 2 LDU per Working Day of delay
Example
Hotfix 1 - Critical : delivered 3 Working Days late without valid
Page 216 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
justification
ADD1 = 29/07/2019; PDD1 = 24/07/2019; COD1 = 0
MED1 = (29/07/2019 – 24/07/2019) – 0 = 3
Hotfix 2 - High: delivered 2 Working Days early
ADD2 = 22/07/2019; PDD2 = 24/07/2019; COD2 = 0
MED2 = 0 because ADD2 ≤ PDD2
Hotfix 3 - Low: delivered 3 Working Days late with valid justification
for 2 Working Days of delay
ADD3 = 29/07/2019; PDD3 = 24/07/2019; COD3 = 2
MED3 = (29/07/2019 – 24/07/2019) – 2 = 1
Hotfix 4 – Stemming from a COTS upgrade following WP 8.1.5
delivered 3 Working Days late without valid justification
ADD4 = 29/07/2019; PDD3 = 24/07/2019; COD3 = 0
MED4 = (29/07/2019 – 24/07/2019) – 0 = 3
KPI = MED1 + MED2 + MED3 + MED4= 3 + 0 + 1 + 3 = 4
The KPI Value being 3 Working Days above the Limit, Liquidated
Damages amounting to 3 x 8 LDU + 0 x 4 LDU + 1 x 1 LDU + 3 x 2
LDU= 31 LDU may be applied
KPI22
The information given for KPI21 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI22
KPI Description
Measure the Delay in delivering a patch during a SAT session
KPI Target
0 Working Day
KPI Limit
1 Working Day
Reporting period
Monthly
Minimum number of Measurements
1 patch to be delivered
KPI Calculation
The Actual Delivery Date (ADD) is the date when the patch is
delivered to the ITSM3OPS contractor for installation.
Page 217 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
Unless a different date is agreed with DG TAXUD in writing, the
Planned Delivery Date (PDD) of the patch is 1 Working Day after the
contractor is notified.
Liquidated Damages
8 LDU per Working Day of delay above the limit
KPI23
KPI Attribute
KPI Attribute description
KPI Name
KPI23
KPI Description
Measure the number of SAT and/or Qualification iterations per
software release.
Unit of Measurement of the KPI
Number of SAT and/or Qualification iterations per software release.
KPI Target
1 SAT and/or Qualification iteration per software release
KPI Limit
1 SAT and/or Qualification iteration per software release
Reporting period
Monthly
Minimum number of Measurements
1 iteration
KPI Calculation
Count SAT and/or Qualification iterations per software release during
reporting period
Liquidated Damages
10 LDU per SAT and/or Qualification iteration above the limit per
software release.
13.2.1.4 Audits
KPI31
KPI Attribute
KPI Attribute description
KPI Name
KPI31
KPI Description
Measure the process compliance as assessed by self-assessment,
internal and external audits and audits by the Contracting Authority
Unit of Measurement of the KPI
Number of equivalent critical audit recommendations opened
KPI Target
Maximum 1 equivalent critical audit recommendations opened
KPI Limit
Maximum 3 equivalent critical audit recommendations opened
Reporting period
Monthly
Minimum number of Measurements
1 audit/assessment
Page 218 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
Count the total numbers of critical or significant audit
recommendations opened per assessment or audit during the reporting
period.
CRIT = total number of critical recommendations
KPI Calculation
SIGN = total number of significant recommendations
The KPI is calculated as follows :
𝐾𝑃𝐼 = 𝐶𝑅𝐼𝑇 + 0,25 ∗ 𝑆𝐼𝐺𝑁
Liquidated Damages
8 LDU per equivalent critical audit recommendations count above the
limit
During the reporting period, 2 Critical and 14 Significant
recommendations were opened.
The KPI is calculated as follows :
Example
KPI = 2 + 0,25 * 14 = 5,5
The KPI Value being 2,5 equivalent critical audit recommendations
above the Limit, Liquidated Damages amounting to 2,5 x 8 LDU = 20
LDU may be applied
KPI32
The information given for KPI31 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI32
KPI Description
Measure the conformance to security controls (number of critical
findings during security audits)
Unit of Measurement of the KPI
Number of equivalent critical security findings
KPI Target
0 equivalent critical findings opened
KPI Limit
Maximum 1 equivalent critical finding opened
Reporting period
Monthly
Minimum number of Measurements
1 security audit
Count the total numbers of critical or significant security findings
opened by security audits during the reporting period.
KPI Calculation
CRIT = total number of critical security findings
SIGN = total number of significant security findings
Page 219 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
The KPI is calculated as follows :
𝐾𝑃𝐼 = 𝐶𝑅𝐼𝑇 + 0,25 ∗ 𝑆𝐼𝐺𝑁
Liquidated Damages
8 LDU per equivalent critical security finding above the limit
During the reporting period, 1 Critical and 2 Significant security
findings were opened.
The KPI is calculated as follows :
Example
KPI = 1 + 0,25 * 2= 1,5
The KPI Value being 0,5 equivalent critical security findings above
the Limit, Liquidated Damages amounting to 0,5 x 8 LDU = 4 LDU
may be applied
13.2.1.5 Staffing
KPI41
KPI Attribute
KPI Attribute description
KPI Name
KPI41
KPI Description
Measure if the initial value of the “Total number of months experience
in each key profile22 that will be assigned full time to the project”
remains at an acceptable level defined by the KPI Limit below.
Unit of Measurement of the KPI
%
KPI Target
95%
KPI Limit
85%
Reporting period
Monthly
Minimum number of Measurements
1
During the reporting period following values will be calculated
KPI Calculation
EXPPERIOD = Total months of professional experience in key profiles
assigned full time to the contractor team.
EXPBID = Total months of professional experience in key profiles
proposed in the contractor bid.
22
Key profiles as defined in section Error! Reference source not found.
Page 220 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
The KPI is then calculated as :
𝐾𝑃𝐼 =
Liquidated Damages
𝐸𝑋𝑃𝑃𝐸𝑅𝐼𝑂𝐷
𝐸𝑋𝑃𝐵𝐼𝐷
When the KPI is below the limit for the reporting period,
liquidated damage of 10 times the daily rate of each person and profile
concerned per month may be applied.
KPI42
KPI Attribute
KPI Attribute description
KPI Name
KPI42
KPI Description
Measure that the contractor team in charge of providing fixed-price
and Continuous services, is staffed with the key profiles 23 as proposed
in the contractor bid and that they are allocated and remain staffed to
the activity as of the signature of the first Specific Contract.
This KPI will measure the occurrence of one of the following events:
1.
The key profiles of the Take-Over team are not staffed by full
time staff 1 month after the start of the first Specific Contract;
2.
The key profiles have a turnover of more than 2 persons over
a 12 months sliding window.
Unit of Measurement of the KPI
KPI Target
0 occurrences
KPI Limit
0 occurrences
Reporting period
Monthly
Minimum number of Measurements
1
KPI Calculation
The full staff sheet will be provided as an annex to the MPR; any
movements to key personal will be clearly indicated.
Liquidated Damages
For situation (1) above (except for “force majeure”), the
liquidated damage will represent 20% of the total Take-Over costs per
month where the situation occurs.
For situation (2) above (except for “force majeure”), the
23
Key profiles as defined in section Error! Reference source not found.
Page 221 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
liquidated damage will represent 20% of the total costs of the
Continuous Services of the applicable Specific Contract for each
month where the situation occurs.
KPI43
KPI Attribute
KPI Attribute description
KPI Name
KPI43
KPI Description
Measure the availability of the staff, per profile, as proposed in the
contractor technical offer as a response to the call for tender.
Unit of Measurement of the KPI
Percentage
KPI Target
100%
KPI Limit
80% during the first 12 months after end of take-over, 60% during the
following 12 months and 40% during the 12 following months.
Reporting period
Monthly
Minimum
Measurements
number
of
1
The KPI is calculated per profile and for the totality of the 50 CVs
proposed. It ensures that at least 80% (respectively 60% and 40%) of the
50 CVs proposed in the technical offer are staff members and the latter
CVs are represented in all profiles. We should then have as staff members
at all time during the time the KPI is enforced (3 periods of 12 months):
KPI Calculation

at least one of the two CVs proposed per profile, and

40, respectively 30 and 20 of all CVs proposed.
If the above condition is not met, the liquidated damages are calculated as
follow:

Ndays = number of days during which the condition was not met

Npersons = number of persons whose CV was proposed who are
missing in the team
LDprofile = Ndays * Npersons
The total liquidated damages for the period is the sum of the liquidated
damages per profile and the liquidated damages resulting from the
application of the 80% rule (60% and 40% respectively).
Liquidated Damages
Example
1 LDU per working day and unavailable person which led to the KPI
going below the limit
During the month 15 after the end of take-over, which has 20 working
days, 30 CVs should be available, as well as at least one of the two CVs
Page 222 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
proposed per profile.
Example 1
The SOFT-DEV team has 31 of the 50 CVs proposed, and at least one of
the two CVs proposed per profile.
There are no liquidated damages.
Example 2
The SOFT-DEV team has 31 of the 50 CVs proposed, and at least one of
the two CVs proposed per profile, except for one profile.
The liquidated damages equal:
1 LDU x 1 person x 20 working days = 20 LDU
Example 3
The SOFT-DEV team has 29 of the 50 CVs proposed, and at least one of
the two CVs proposed per profile, except for three profiles.
The liquidated damages equal:
As the total of CVs is not met:
1 LDU x 1 person x 20 working days = 20 LDUs
As staff is missing for three profiles:
1 LDU x 3 persons x 20 working days = 60 LDUs
or a total of 80 LDUs.
Example 4
The SOFT-DEV team has 30 of the 50 CVs proposed, and at least one of
the two CVs proposed per profile. However, one person leaves the team 5
working days before the end of the month. The other CV of the same
profile was not in the team and is not available.
The liquidated damages equal:
As the total of CVs is not met:
1 LDU x 1 person x 5 working days = 5 LDUs
As staff is missing for one profile:
1 LDU x 1 person x 5 working days = 5 LDUs
or a total of 10 LDUs.
Example 5
The SOFT-DEV team has 30 of the 50 CVs proposed, and at least one of
the two CVs proposed per profile. However, one person leaves the team 5
working days before the end of the month. The other CV of the same
profile was not in the team. Yet this other person steps in and replaces the
departure immediately.
There are no liquidated damages.
Page 223 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
13.2.1.6 Training appraisals
KPI51
KPI Attribute
KPI Attribute description
KPI Name
KPI51
KPI Description
Measure the Training/workshop appraisal for all trainings/workshops
provided by the contractors, except if explicitly excluded by the
Contracting Authority.
Unit of Measurement of the KPI
%
KPI Target
95%
KPI Limit
80%
Reporting period
Monthly
Minimum number of Measurements
1 training/workshop
During the reporting period for every Training/Workshop n the
attendees will appraise the Training/Workshop on a scale of 10 (10 =
Outstanding, 0 = Extremely bad) and the following value will be
calculated in percent
𝑇𝑛 =
KPI Calculation
𝑁𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑡𝑡𝑒𝑛𝑑𝑒𝑒𝑠 𝑤𝑖𝑡ℎ 𝑎𝑝𝑝𝑟𝑎𝑖𝑠𝑎𝑙 ≥ 8
𝑇𝑜𝑡𝑎𝑙 𝑛𝑢𝑚𝑏𝑒𝑟 𝑜𝑓 𝑎𝑡𝑡𝑒𝑛𝑑𝑒𝑒𝑠
N is the total number of trainings/workshops appraised within the
reporting period.
The KPI is calculated as :
𝐾𝑃𝐼 =
∑𝑁
𝑛=1 𝑇𝑛
𝑁
NB: It is the responsibility of the contractor to ensure that participants
complete the appraisal forms.
When the KPI is below the limit, the Total Liquidated Damages
applicable for the reporting period will be represented by the
following formula:
Liquidated Damages
𝐿𝐷 = (𝐾𝑃𝐼𝐿𝐼𝑀𝐼𝑇 − 𝐾𝑃𝐼) ∗ 100 𝐿𝐷𝑈
Note: The KPI is expressed as a percentage, therefore one multiplies
the percentage with 100 LDU to obtain the LD.
During the reporting period, 3 trainings/workshops were completed
and appraised in the reporting period with the following scores:
Example
Training 1 : 12 out of a total of 16 attendees appraised the training
with a score of 8 or higher  T1 = 12/16 = 75% (lower than the limit)
Training 2 : 10 out of a total of 12 attendees appraised the training
Page 224 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
with a score of 8 or higher  T2 = 10/12 = 83,3% (above the limit)
Training 3 : 8 out of a total of 11 attendees appraised the training with
a score of 8 or higher  T3 = 8/11 = 72,7% (lower than the limit)
The KPI is the average of the training sessions: (75% + 83,3% +
72,7%) / 3 = 77%
The KPI Value being below the Limit, Liquidated Damages
amounting to (80% – 77%) * 100 LDU = 3 LDU may be applied
13.2.1.7 Take-Over
KPI81
KPI Attribute
KPI Attribute description
KPI Name
KPI81
KPI Description
Measure the delay in completing the Take-Over within the foreseen
Take-Over period.
This KPI will measure the delay in completing the Take-Over
activities:
Unit of Measurement of the KPI
Each started month of delay will be counted as a full month delay (e.g.
1 day of delay will trigger the same Liquidated Damages as 20 days of
delay).
KPI Target
0 occurrences
KPI Limit
0 occurrences
Reporting period
Monthly until completion of Take-Over
Minimum number of Measurements
1
KPI Calculation
The planning will be provided as an annex to the MPR; any risks will
be clearly indicated.
Liquidated Damages
Each month of delay will induce 100.000 € of liquidated
damage up to a maximum of 6 months (600.000 €) at which time the
contract is terminated by the Contracting Authority.
KPI82
KPI Attribute
KPI Attribute description
KPI Name
KPI82
KPI Description
Measure any discrepancy (non-compliance) in the contract
implementation compliance versus the submitted tender or the
Technical Annex (“Tender Specifications - Part 3 - Technical
Page 225 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
Annex”).
Unit of Measurement of the KPI
Occurrence of non-compliance
KPI Target
0 occurrences
KPI Limit
0 occurrences
Reporting period
Monthly until completion of Take-Over
Minimum number of Measurements
1
KPI Calculation
The contract implementation will be continuously assessed during the
Take-Over against the contractor bid and the Technical Annex
(“Tender Specifications - Part 3 - Technical Annex”).
Liquidated Damages
10 LDU per Working Day of delay after the foreseen Take-Over
period until the full compliance is achieved
13.2.1.8 Contract management
KPI91
The information given for KPI01 applies with the following changes:
KPI Attribute
KPI Attribute description
KPI Name
KPI91
KPI Description
Measure the delay to deliver an acceptable offer/proposal
Unit of Measurement of the KPI
Working Days
KPI Target
“0 delay” for acceptance
KPI Limit
1 Working Day
Reporting period
Monthly
Minimum number of Measurements
1 offer/proposal
The Actual Delivery Date (ADD) is the date when the offer/proposal
is submitted to the Contracting Authority for acceptance via e-mail to
the requested address. If the offer/proposal must be submitted several
times for acceptance the Actual Delivery Date is the date of the last
submission for acceptance.
KPI Calculation
The Planned Delivery Date (PDD) is defined in the RFO/RFE; the
default review cycle for an offer is (T1/T2/T3) 5/5/5.
The Correction Delay (COD) of the offer/proposal is a number of
working days to neutralize from the KPI calculation based on a
justification provided by the contractor and subject to acceptance by
the Contracting Authority. By default, the COD has a value of 0
Page 226 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
Working Days.
Liquidated Damages
8 LDU per Working Day of delay above the limit
KPI92
KPI Attribute
KPI Attribute description
KPI Name
KPI92
Measure that the actions agreed with DG TAXUD have been
implemented within the given timeframe
KPI Description
The actual date for the action’s end is the date when the contractor
finishes the implementation (resolution) of the action. The decision to
close or not an action is taken by DG TAXUD (by mail or during the
meeting following the resolution of the action.
Unit of Measurement of the KPI
Working Days
KPI Target
“0 delay” for acceptance
KPI Limit
1 Working Day
Reporting period
Monthly
Minimum number of Measurements
1 action
Liquidated Damages
5 LDU per Working Day of delay above the limit
KPI93
KPI Attribute
KPI Attribute description
KPI Name
KPI93
Measure the deadlines in processing non-compliance notification or
complaints for any of the services provided by the contractor.
KPI Description
Any deviation from the specified services not captured by any other
explicit KPI is the subject to this KPI.
Unit of Measurement of the KPI
Working Days
KPI Target
Less than 10 Working Days
KPI Limit
10 Working Days
Reporting period
Monthly
Minimum number of Measurements
1 non-compliance/complaint
KPI Calculation
The contract execution will be continuously monitored against the
contractor bid, the Technical Annex (“Tender Specifications - Part 3 Page 227 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
Technical Annex”) and the Tendering Specifications (including all the
annexes thereto).
All Non-compliance notification or Complaints will be collected via
the Contracting Authority.
All confirmed Non-compliance notification or Complaints will be
forwarded by the Contracting Authority to the contractor for inclusion
in the MPR, detailed analysis and follow up.
The contractor must record all received Non-compliance notification
or Complaints in the MPR.
The contractor must provide within the KPI Limit a written response
with a detailed analysis report of each Non-compliance notification or
Complaint following the agreed and documented procedure.
Liquidated Damages
5 LDU per Working Day of delay above the limit
KPI94
KPI Attribute
KPI Attribute description
KPI Name
KPI94
KPI Description
Measure the number of re-occurring Non-compliance notifications or
Complaints received and confirmed by the Contracting Authority over
a sliding window period of 6 months
Unit of Measurement of the KPI
Number of re-occurring Non-compliance notifications or Complaints
over a sliding window of 6 months
KPI Target
No re-occurring Non-compliance notification or Complaint over a
sliding window of 6 months
KPI Limit
No re-occurring Non-compliance notification or Complaint over a
sliding window of 6 months
Reporting period
Monthly
Minimum number of Measurements
1 re-occurring Non-compliance notification or Complaint
KPI Calculation
The number of re-occurring Non-compliance notifications or
Complaints to be counted for this KPI is the number of reported in the
MPRs over a sliding window of 6 months.
Liquidated Damages
100 LDU per re-occurring Non-compliance notifications or Complaint
above the Limit.
Page 228 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI95
KPI Attribute
KPI Attribute description
KPI Name
KPI95
KPI Description
Measure the satisfaction of the users with the services provided by the
contractor
Satisfaction scale:
Unit of Measurement of the KPI

Very satisfied (Value=5)

Somewhat satisfied (Value=4)

Neither satisfied nor dissatisfied (Value=3)

Somewhat dissatisfied (Value=2)

Very dissatisfied (Value=0)
KPI Target
Very satisfied (Value=5)
KPI Limit
Somewhat satisfied (Value=4)
Reporting period
Monthly
Minimum number of Measurements
5 answers
The satisfaction will be measured when requested by the Contracting
Authority, but at least once a year.
KPI Calculation
It will be measured by a survey based on an agreed set of questions
and sent to a user population defined by the Contracting Authority.
Each answer will be collected and assigned its associated value.
One occurrence of the two extreme values of the answer set will be
removed and the remaining values averaged.
When the KPI is below the limit, the Total Liquidated Damages
applicable for the reporting period will be represented by the
following formula:
Liquidated Damages
𝐿𝐷 = (𝐾𝑃𝐼𝐿𝐼𝑀𝐼𝑇 − 𝐾𝑃𝐼) ∗ 100 𝐿𝐷𝑈
During the reporting period, the satisfaction level measured by the
survey was survey had the following value : KPI = 3,56
Example
The KPI Value being below the Limit, Liquidated Damages
amounting to (4 – 3,56) * 100 LDU = 44 LDU may be applied
Page 229 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI96
KPI Attribute
KPI Attribute description
KPI Name
KPI96
KPI Description
Measure the respect of the minimal productivity rate of 100 Function
and SNAP Points (FSP) / calendar month
Unit of Measurement of the KPI
Number of FSPs/calendar month
KPI Target
“0 FP lower than the minimal productivity rate” for acceptance
KPI Limit
5 FPs
Reporting period
Monthly
Minimum number of Measurements
One (1) Number of FSPs/calendar month
Upon agreeing an RfA for the elaboration phase the contractor must
provide an estimated number of FSPs. Upon delivering a software
release together with its corresponding documentation an actual count
of the FSPs will take place. This KPI shall measure the number of
actual function FSPs delivered and not the estimated ones.
For the elaboration phase the Actual Delivery Date (ADD) of a
particular RfA is the date when the last deliverable that was requested
in that particular RfA was successfully made available to the
Commission e.g. uploaded on the agreed deliverable provision tool
(e.g. CIRCABC or the Application Lifecycle Management platform
described in section 8.5.1).
KPI Calculation
For the construction phase the Actual Delivery Date (ADD) is the date
when the software release or any other deployment deliverable e.g.
complementary scripts, migration scripts, installation manual,
configuration manual etc. that was requested in the construction RfA,
whichever deliverable comes last, was successfully made available to
the Commission e.g. uploaded on the agreed deliverable provision tool
(e.g. CIRCABC or Application Lifecycle Management platform).
When a deliverable must be uploaded several times on the latter tool
for acceptance, the Actual Delivery Date is the date of the last upload
for acceptance.
For each re-SfA or any complementary redelivery due to the fault of
the contractor e.g. hot-fix, new corrective release of the whole
software or any dependent artefacts e.g. scripts, the ADD shall be
considered the moment the new version of the software delivery or
any associated deliverable has been uploaded.
For each further corrective delivery or redelivery after the initial one
due to the fault of the contractor e.g. hot-fix, new corrective release of
the whole software or any dependent artefacts e.g. scripts, for which
the Commission requests a dedicated urgent corrective delivery that
the Commission deems cannot wait for the next planned release, and
an urgent fix is needed, the ADD shall be extended by adding the
Page 230 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
difference in working days between the moment the Commission
request the redelivery and the moment the new version of the
corrective software delivery or any associated deliverable has been
uploaded. The above shall remain valid regardless of the moment
when the defect is found e.g. immediately, or after a new evolutive
release was delivered as long as the defect pertains to the scope of the
RfA for which the ADD is being calculated.
The number of calendar months for a software delivery shall be
defined as the sum of all RfAs under the elaboration and construction
phases. In the Agile methodology, both elaboration and contruction
phases are combined into a single Agile Iteration Phase. For a
particular RfA the number of calendar months shall be defined as the
difference in working days between the ADD and the date of the
signature of the RfA by the Commission divided by 20. The number of
calendar months shall be calculated up to two decimals and rounded
down on the third decimal.
This KPI shall be recalculated every time the Commission request the
urgent correction of a defect.
The productivity rate shall be defined as the number of function points
(FSP) divided by the number of calendar months, and shall be
calculated up to two decimals and rounded down on the third decimal
Liquidated Damages
7,5 x LDU per one unit of productivity rate strictly below the limit x
number of months. This shall be applied proportionally for any
subdivision of one unit of productivity rate below the limit.
Example 1:
Elaboration phase: one RfA has been signed by the Commission on
the 20/04/2020. The last deliverable has been submitted to the
Commission on the 20/07/2020.
Calendar days elaboration = number of working days between 20/07/2020
and 20/04/2020 = 58 working days
Example
A defect was found after the normal review cycle of a deliverable of
this RfA on the 10/06/2020. The Commission asked for an urgent
correction on the 11/06/2020. The contractor delivered the correction
on the 20/06/2020. Since 20/06/2020 is less than 20/07/2020, the date
of the last deliverable, there shall be no additional working days
counted for the calculation of the calendar months.
Construction phase: one RfA has been signed by the Commission on
the 06/07/2020. The last deliverable has been submitted to the
Commission on the 20/09/2020.
Calendar days construction = number of working days between 05/07/2020
and 20/09/2020 = 53 working days
A defect was found after the software delivery of this RfA on the
09/10/2020. The Commission asked for an urgent correction on the
Page 231 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
KPI Attribute
KPI Attribute description
12/10/2020. The contractor delivered the correction on the
25/10/2020.
Calendar days construction = 53 working days + number of working days
between 11/10/2020 and 25/10/2020 = 53 wdays + 8 wdays = 61
wdays
Calendar days elaboration + construction = 58 + 61 wdays = 119 wdays
Calendar months elaboration + construction = 119 wdays / 20 = 5,95
The IFPUG report as accepted by the Commission counted 570 FSP.
The productivity rate = 570 FSP / 5,95 calendar months = 95,80 FSP /
month
Liquidated damages = 0 EUR (this is because the productivity rate /
month is above the limit of 95 FP
Example 2:
Same as Example 1, except that the IFPUG report as accepted by the
Commission counted 550 FSP
The productivity rate = 550 FSP / 5.95 calendar months = 92,43 FSP /
month
Liquidated damages = 7,5 * (95-92,43) * 5.95 LDU = 114,67 LDU
13.3 The SQI / GQI approach
The SQIs allow, once aggregated, defining a General Quality Indicator (GQI) which measures the
quality of the delivered service in the frame of a given contract (Specific Contract or RfA). These
indicators also point out whether liquidated damages are applicable and, if so, their amounts. The SQIs,
their limit value and their relative weight can be defined at framework contract, specific contract or RfA
level. Those defined at RfA level take precedence on those defined at specific contract level which in
turn have precedence on those defined at framework contract level. The Contracting Authority solely
decides on the use of SQIs, their limit value as well as their respective weight.
This approach provides:

A normalised way to quantify the quality of service and a weighted approach in
combining all the service quality indicators into a single general quality indicator
(GQI);

A mechanism to determine the liquidated damages;

A grace window in case the quality of service is below target but within a certain
limit.
The following sections describe the method of computation of all the SQIs and the GQI.
Page 232 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
13.3.1 Calculation of the SQI
Some or all of the following parameters define a Specific Quality Indicator.
SQI Attribute
SQI Attribute description
SQI Name
A name, which allows to fully identify the SQI.
SQI Description
A complete description of the SQI.
Measurement of the QoS (M)
Specifies the measurement of the QoS (or combination of set
of measurements) for the SQI.
Unit of Measurement of the QoS
Defines the Unit of Measurement of the QoS. For example, a
SQI aiming to evaluate duration or delays can be expressed
in hours or days.
Application period
Specifies the overall period over which the SQI is calculated;
Target
Target, which sets the level of the measurement that, if
reached, would demonstrate good QoS.
Limit
Together with the Target, the Limit defines the “grace
window”, within which although the QoS is below target, the
SQI is still immunised from negative impact. Attaining the
Limit value (or worse) implies a penalty.
Normalised Measurement (Mnorm)
A normalised Measurement is the result of the
transformation of a measure (see formula below), which
renders a number independent of the unit of measure of the
QoS.
SQI Profiled (SQIprof)
A profiled SQI is the result of a profiling function applied to
a normalised SQI (see function f below).
Applicable services/deliverables
Defines the set of services and deliverables, to which the
SQI will apply.
Minimum number of Measurements
Minimum number of measurements or set of measurements
necessary for an SQI to be computable.
SQIs are calculated using the following steps in sequence:
Collect Measurement of QoS (M)
The Measurement M (or set of measurements) of QoS has to be collected from the start of the
corresponding contract until the end of the reporting period, and possibly combined according to the
definition of the Measurement of the QoS.
If the minimum number of measurements required over the applicable period to make the SQI
computable is not attained, then the Measurement (hence SQI) has no applicable value for that
application period.
Once activated however, the SQI will remain computable until the end of the corresponding contract
(SC or RfA), the minimum number of measurements being cumulative throughout the length of the
contract.
Normalise the Measurement (Mnorm)
For a given Measurement M, the related normalised Measurement MNorm is obtained by applying the
following formula:
Page 233 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
M Norm 
M  Target
Target  Limit
Where the M, Target and Limit are values expressed in the same unit and are part of the SQI definition.
SQIprof as a result of the Profiling function
Once the Measurement has been normalised to MNorm, it is profiled (using the f function) to a SQIprof,
which has the following effects:



It limits the SQIprof upwards, versus irrelevant over-performance of QoS above target;
It defines linear proportionality between the SQI prof and the under-performance of QoS below
Limit;
It sets a grace period (interval defined by the Target and the Limit) which is setting the SQIprof
to a neutral level, immunising the SQI from any positive or negative factor.
The profiling function (f) is applied on all occurrences of the normalised Measurements. Those
calculations are provided in detail in the SQI report attached to the Monthly Project Report.
The profiling function f is defined as follows:

If
M Norm  0  SQI prof  f (M Norm)  1
i.e. the QoS leads to a Measurement above
Target

If
1  MNorm  0  SQIprof  f (MNorm)  0
i.e. the QoS leads to a Measurement between
Target and Limit – neutral grace window

If
MNorm  1  SQIprof  f (MNorm)  1
i.e. the QoS leads to a Measurement on Limit

If
M norm  1  SQI prof  f (M norm )  M norm
i.e. the QoS leads to a Measurement below the
Limit
This profiling function is plotted in the figure below.
Page 234 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
Profiling Model "linear penalties w/ a neutral grace window"
2
1
Profiled SQI
0
-5
-4
-3
-2
-1
0
1
2
3
4
5
-1
-2
-3
At limit
At target
-4
-5
Normalised Measurement
Figure 3 - Profiled SQIprof
Averaged profiled SQI
When a single SQIprof is used to measure the QoS of multiple occurrences of services/delivery of the
same nature, it is called an “averaged SQI”, which is made of the average of all multiple-SQIi according
to the following formula, where n is the number of occurrences of the given SQIprof during the
applicable contract:
n
SQI prof 
 SQI
i
n
n
prof i

 f (M
i
norm i
)
n
13.3.1.1 The General Quality Indicator
In order to measure the general quality of contractual activities, General Quality Indicators (GQI) will
be defined during the implementation of the Framework Contract. The GQIs are established as a
composition of the (some of the) SQIs listed above.
GQIs can be measured either at Specific Contract level (in the case of Specific Contracts for continuous
services or continuous monthly Services, as defined in section 3.1.1) or at RfA level (in case of
Specific Contracts for On-demand Services).
The GQI is the weighted average of so called contractual SQIs24 as a subset of all the SQIs. It allows a
global assessment of the QoS for all services and deliverables.
To each contractual SQI, a normalised weight factor25 (w) has to be associated.
24
For sake of clarity, as of now, profiled SQI will be simply called “SQI”.
25
“Normalised weight” means that the sum of all the weights for all SQI participating in a GQI is equal to 1.
Page 235 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
In formula, the General Quality Indicator is defined as:
GQI   (SQIi  wi )
i
The weights of the activated SQIs within a GQI will be defined by the Contracting Authority at SC or
RfA level. In case one or several contractual SQIs cannot be calculated because of an insufficient
number of measurements to reach the set “minimum number of measurements”, then their contributions
to the GQI are removed and the weights of the remaining contractual SQIs are proportionally rescaled to
bring their sum (sum of the weights) back to one.
In the case of Specific Contracts for continuous services the GQI is calculated monthly for informative
purposes only. The final GQI is calculated from the average of the monthly values of the individual
SQIs with the respective weighting.
13.3.2 Liquidated damages within GQI calculations
The liquidated damages related to deficient Quality of Service (QoS) are derived directly from the GQI
calculation. The GQI and the liquidated damages will be calculated at the end of the service provision of
a Specific Contract or RFA. Liquidated damages may be applied to the SOFT-DEV contractor in the
framework of the Contractual OLA.
From GQI to liquidated damages calculation:
The amount of liquidated damages at the end of the Specific Contract or RfA is calculated according to
the following “P” function:
If
GQI  1

Liquidated damages = 20 % * value of the SC or RfA
If
 1  GQI  0

Liquidated damages = 20 % * value of the SC or RfA *
abs(GQI);
If
GQI  0

Liquidated damages = 0
abs means absolute-value.
The main idea behind the “P” function is to:

Have no liquidated damages when the GQI is positive, indicating overall positive QoS for the
duration of the SC or RfA.

Have liquidated damages linearly proportional to all amounts that have been ordered in the SC
or RfA, when GQI is negative.

And limit the maximum amount of liquidated damages to 20% of all amounts that have been
ordered in the SC or RfA when GQI gets equal or below -1, indicating that the global QoS
during the SC or RfA has been very negative.
Page 236 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
Liquidated damages
20% of the SC or RfA value
GQI
1
0
-5
-4
-3
-2
0
-1
1
2
3
4
5
-1
-
Liquidated damages function
Figure 4 Liquidated damages application
Liquidated damages are calculated at the end of each Specific Contract or RfA and applied on the last
payment related to the Specific Contract or RfA, when applicable.
The liquidated damage will take the form of an amount to be deducted from the last invoice for the
Specific Contract or RfA.
Page 237 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
13.3.3 Specific Quality Indicators (SQI) definitions
SQI01
SQI Attribute
SQI Attribute description
SQI Name
SQI01
SQI Description
Measure the respect of the deadline of a deliverable whose delay
would have a major impact (SfA)
Unit of Measurement of the SQI
working days
SQI Target
“0 delay” for acceptance
SQI Limit
1 working day
The actual delivery date is the date the deliverable is uploaded on the
agreed deliverable provision tool (e.g. CIRCABC or the Application
Lifecycle Management platform described in section 8.5.1).
If the deliverable must be uploaded several times on the latter tool for
acceptance:


The actual delivery date is the date of the last upload for
acceptance.
For each re-SfA, the number of days to be considered in the
calculation of this SQI will be the number of days between
the moment the contractor received the IVE_NOK (or the
request for re-SfA from the Contracting Authority) and the
moment the new version of the document has been uploaded.
The planned delivery date is defined in the last approved version of
the DTM for all deliverables.
SQI Calculation
The SQI will be calculated for every reporting period.
The SQI equals to the average of the normalised and profiled value of
the individual values of (AD-PD).
where:
AD is the actual delivery date of each deliverable, which has been
tagged as having a delay impact defined in the SQI Description above,
which was actually delivered for Final acceptance during the reporting
period
And
PD is the planned delivery date of the deliverable
Note: if AD < PD then the delay is to be considered as zero.
The average of each occurrence of this SQI will constitute the value to
be used in the GQI calculation.
Page 238 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
SQI Attribute
SQI Attribute description
Applicable services/deliverables
Please refer to “Table 3: Services & Deliverables”
Minimum number of Measurements
1 deliverable
SQI02
The information given for SQI01 above applies with the following changes regarding its decription and
limit:
SQI Attribute
SQI Attribute description
SQI Name
SQI02
SQI Description
Measure the respect of the deadline of a deliverable whose delay
would have a high impact (SfA)
SQI Limit
5 working days
SQI03
The information given for SQI01 above applies with the following changes regarding its decription and
limit:
SQI Attribute
SQI Attribute description
SQI Name
SQI03
SQI Description
Measure the respect of the deadline of a deliverable whose delay
would have a medium impact (SfA)
SQI Limit
10 working days
SQI04
The information given for SQI01 above applies with the following changes regarding its decription and
limit:
SQI Attribute
SQI Attribute description
SQI Name
SQI04
SQI Description
Measure the respect of the deadline of a deliverable whose delay
would have a low impact (SfA)
SQI Limit
15 working days
SQI05
SQI Attribute
SQI Attribute description
SQI Name
SQI05
Page 239 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
SQI Attribute
SQI Attribute description
SQI Description
Measure the number of bugs or defects detected during an Agile
iteration which are not corrected at the end of the following iteration.
Unit of Measurement of the SQI
Number of bugs or defects
SQI Target
0 bug or defect unfixed.
SQI Limit
1 bug or defect unfixed by 25 points of the RfA's final IFP and SNAP
count. For example, for a software release sized at 600 points (IFP and
SNAP), the limit is equal to 24 units of bugs or defects, for a release
sized at 300 points, the limit is equal to 12 units.
Bugs or defects, including critical source code quality issues, detected
during an iteration must be fixed by the end of the following iteration.
An iteration ends when its iteration review is completed. Bugs,
defects, etc. detected during the last iteration must be fixed before the
SfR date of their corresponding deliverables.
SQI Calculation
A bug or defect left unfixed at the end of an iteration counts as one
measurement. The SQI measures their cumulative count. As an
example, a bug detected during the review meeting of iteration N, not
fixed during iteration N+1, still not fixed during iteration N+2 and
finally fixed during iteration N+3 therefore counts as 2 units.
The SQI will be calculated after the final count of IFP and SNAP
points for the release.
Applicable services/deliverables
WP.6 and WP.7.
Minimum number of Measurements
1
SQI06
SQI Attribute
SQI Attribute description
SQI Name
SQI06
SQI Description
Measure the respect of the Agile iteration calendar.
Unit of Measurement of the SQI
working days
SQI Target
0 delay
SQI Limit
1 working day per 3 iterations in the Agile iteration phase covered by
the RfA, computed as the number of iterations in the Agile iteration
phase divided by 3 and rounded down. For RfA having less than 3
iterations, the limit is equal to 1 working day.
Example: 13 iterations will lead to a limit of 4 working days.
The SQI will be calculated at the end of the iteration phase.
SQI Calculation
For each iteration i:
Page 240 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
SQI Attribute
SQI Attribute description
ADi is the actual date of the review meeting,
PDi is the planned date of that meeting according to the release
planning.
The measured delay MDi is
MDi = ADi-PDi if ADi>PDi; MDi=0 otherwise.
The SQI value expressed in working days is the sum of the measured
delays for the N iterations of the in Agile iteration phase:
𝑁
𝑆𝑄𝐼 = ∑ 𝑀𝐷𝑛
𝑛=1
A measured delay can be neutralised by DG TAXUD if justified.
Applicable services/deliverables
WP.6 and WP.7.
Minimum number of Measurements
1 iteration
SQI07
SQI Attribute
SQI Attribute description
SQI Name
SQI07
SQI Description
Measure the number of iterations during a testing cycle (in(p)SAT or
CONF environment) per software release. An iteration consists in the
delivery of a patch resulting from a defect that would have prevented
to put the software in production.
Unit of Measurement of the SQI
Number of testing cycle and/or Qualification iterations
SQI Target
1 testing cycle and/or Qualification iteration
SQI Limit
2 testing cycles and/or Qualification iterations
SQI Calculation
Count the number of testing cycle(s) and/or Qualification iteration(s)
required for the software release.
Applicable services/deliverables
All
Minimum number of Measurements
1
When SQI07 is selected, one or more delay-based KPIs (e.g. KPI22) or SQIs (SQI01 for instance)
must be automatically selected jointly for the related software delivery, so that any delay in the latter can
lead to liquidated damages.
SQI08
Page 241 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
SQI Attribute
SQI Attribute description
SQI Name
Unit of Measurement of the SQI
SQI Target
SQI Limit
SQI08
Measure the number of complaints received and confirmed by DG
TAXUD
Number of occurrences
0
2
SQI Calculation
All complaints submitted/expressed by the stakeholders will be
collected via the Commission. All confirmed complaints will be
forwarded by the Commission to the contractor for inclusion in the
MPR, detailed analysis and follow-up. The contractor must record all
received complaints in the MPR. Furthermore, they will be discussed
during the BMM.
SQI Description
DG TAXUD, following the discussion in BMM and after a careful
assessment accepts or rejects a complaint. For those rejected, the
contractor must provide a detailed and convincing explanation. The
number of complaints to be counted for this SQI is the number of
complaints accepted by DG TAXUD.
Applicable services/deliverables
Minimum number of Measurements
All
1
Page 242 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
13.4 Performance Indicators
The Contracting Authority may request the SOFT-DEV contractors to report each month on a
number (up to 20) of Performance Indicators (PI). Examples are provided below. Targets are not
necessarily set, and Direct Liquidated Damages do not apply to a PI individually.
PI21 - Measure the quality of a deliverable (SfR)
The value to be reported is the ratio between the number of documents rejected and not rejected at SfR
during the reporting period and having to be resubmitted for review.
PI22 - Measure the quality of a deliverable (SfA)
The value to be reported is the ratio between the number of documents rejected at SfA and the total
number of documents submitted for acceptance during the reporting period and having to be resubmitted
for review
PI23 - Measure the amount of documentation defects created from not implemented comments
The value to be reported is the number of documentation defects created after the Contracting Authority
notifies the acceptance of an IVE not OK. The data should be reported per review cycle and per
Configuration Item.
PI24 – Measure the time elapsed between the creation of a (documentation) defect and the
provision of the analysis
The value to be reported is the measure of the average time elapsed between a (documentation) defect
creation and the provision of its analysis. The value is to be detailed per documentation defect and
defect and per Configuration Item. The data reported should also include the time elapsed between the
creation of the ticket and the reporting date in case no analysis is made available at reporting time.
PI25 - Measure the amount of low reaction time on assigned calls
The value to be reported is the number of Incidents and Problems which remained not analysed for at
least half of the resolution time allowed by the corresponding Contractual OLA . The value is to be
detailed per Incident and Problem and per Configuration Item.
PI26 - Measure the number of calls reassigned to the contractor during the reporting
The value to be reported is the number of tickets (incidents, RfIs, RfSes, and problem tasks) that were
reassigned for the second (or more) time(s) to the contractor during the reporting period. The values are
to be detailed by Service Call category and per Configuration Item, and should list the Synergia tickets
considered in the calculation.
PI27 - Measure the number of late deliveries for which the Contracting Authority was not notified
The values to be reported are the number of deliverables that were delivered after their contractual (SfR)
delivery date without upfront notification towards the Contracting Authority. The values are to be
detailed per deliverable type per reporting period.
PI28 - Measure the number of defects reported during SAT/QT
The value to be reported is the number of defects detected and reported by the operational contractor
during SAT/QT activities during the reporting period. The values are to be detailed by CI.
PI29 - Measure the number of bugs reported per CI (systems/application/component) per
reporting period
The values to be reported are the number of defects detected and reported by the operational contractor
during the reporting period in the production environment. The values are to be detailed by CI.
Page 243 of 244
INVITATION TO TENDER
REF: TAXUD/2020/OP/0001 – SOFT-DEV
TENDER SPECIFICATIONS - PART C - TECHNICAL ANNEX
APPENDIX 1 - DETAILED INFORMATION ON SQIS, KPIS AND PIS
PI30 - Measure the number of changes reported per CI (systems/application/component) per
reporting period
The values to be reported are the number of new changes registered per reporting period. The values are
to be detailed by CI and split between corrective/evolutionary changes.
PI31 - Measure the number of patches delivered per CI (systems/application/component) per
reporting period
The value to be reported is the number of new patches/hotfixes delivered during the reporting period.
The value is to be detailed by CI.
PI32 - Measure the number of releases delivered per CI (systems/application/component) per
reporting period
The value to be reported is the number of new releases delivered during the reporting period. The value
is to be detailed by CI.
PI33 - Measure the number of the contractor’s documents for which more than one comment per
page was raised
The value to be reported is the number of documents for which more than one comment per page was
raised.
Page 244 of 244