call for tender home/sivi/2010/fw-a/c203 “external ... · call for tender...

______________________________________________________________________________________________________ Call for Tender HOME/SIVI/2010/FW-A/C203, Annex 11 - Part 1: Technical Specifications

EUROPEAN COMMISSION DIRECTORATE-GENERAL HOME AFFAIRS Directorate C: Migration and Borders Unit C.2: IT projects: Infrastructure and legal issues Unit C.3: Large scale IT systems and Biometrics

Call for Tender

HOME/SIVI/2010/FW-A/C203

“External assistance for project management, consultancy and quality assurance to European large-scale IT system projects in Home Affairs

matters”

Annex 11 – Part 1: Technical Specifications

______________________________________________________________________________________________________ Call for Tender HOME/2010/SIVI/FW-A/C203 Annex 11 – Part 1: Technical Specifications - 2 -

Table of Contents

1. Introduction ....................................................................................................................4

1.1. Context....................................................................................................................4 1.1.1. Schengen Information System..........................................................................4 1.1.2. Visa Information System..................................................................................6 1.1.3. Eurodac ............................................................................................................7 1.1.4. Biometric Matching System BMS-1: BMS-VIS ..............................................7 1.1.5. Biometric Matching System BMS-2: BMS-SIS II ...........................................8 1.1.6. Biometric Matching System BMS-3: Eurodac II..............................................8 1.1.7. Entry-exit system - Registered traveller programme ........................................8

1.2. Contractual context ...............................................................................................9 1.2.1. SIS II -VIS development contract ....................................................................9 1.2.2. BMS development contract ............................................................................10 1.2.3. Network development contract.......................................................................10 1.2.4. Project Advice and Support Office contract ...................................................10

2. Project Development working methods ........................................................................11

2.1. Project development methodologies ...................................................................11

2.2. Architecture of HOME projects .........................................................................12

2.3. Data content .........................................................................................................13

2.4. Project management ............................................................................................13 2.4.1. Project Phases ................................................................................................13 2.4.2. Work packages (WP) .....................................................................................15

3. Assignment of Deliverables...........................................................................................16

3.1. Assignment of Services ........................................................................................16 3.1.1. Assignment of A-Services..............................................................................16 3.1.2. Assignment of B-Services..............................................................................17 3.1.3. Language........................................................................................................17 3.1.4. Support Contractor’s Project Management.....................................................18 3.1.5. Formal project management procedure ..........................................................18

4. Acceptance of Main Development Services..................................................................20

5. Support Service Deliverables ........................................................................................21

5.1. Acceptance procedures (Review cycle) ...............................................................21

5.2. A-Services Project Phase 1: Detailed design Deliverables.................................21 5.2.1. Protection Profile Acceptance Report ............................................................21 5.2.2. Security Target Acceptance Report................................................................22 5.2.3. System-Specific Security Requirement Statement (SSRS) Report .................22 5.2.4. Security Plan Acceptance Report ...................................................................23

5.3. A-services Project Phase 2: System Development and Deployment Deliverables 23

5.3.1. Updated Master Project Plan Acceptance Report ...........................................23 5.3.2. Updated Quality Assurance Plan Acceptance Report.....................................23 5.3.3. Updated Interface Control Document Acceptance Report..............................24 5.3.4. Updated Technical Detailed Technical Specifications Acceptance Report.....24


5.3.5. Updated Functional Detailed Technical Specifications Acceptance Report ...25 5.3.6. Updated Integration Plan Acceptance Report.................................................25 5.3.7. Hardware Acceptance Report.........................................................................25 5.3.8. Acceptance Report on Hardware Documentation, Commercial Software Documentation and Configuration and Installation Documents.....................................26 5.3.9. Network Installation Quality Assurance.........................................................27 5.3.10. Functional Test Design Description Acceptance Report ................................27 5.3.11. Non-functional Test Design Description Acceptance Report .........................27 5.3.12. System development until Technical Tests without Member States (SIS II) ..28 5.3.13. Software Installation and Configuration Acceptance Report..........................28 5.3.14. Environment set-up Acceptance Report .........................................................29 5.3.15. Business Continuity Planning Acceptance Report..........................................29 5.3.16. Supervision of execution of Technical Test Without MS (SIS II) ..................30 Define and apply acceptance process for Hardware, Standard Software and Custom-built Software. Ensure completion of the acceptance tests. Ensure compliance to specifications. Complete Acceptance Report. ................................................................30 5.3.17. User Compliance Tests Acceptance Report....................................................30 5.3.18. Site Acceptance Test Report on Test Components, Acceptance Report on Documentation and Acceptance Report on Factory Testing Report...............................31 5.3.19. Member States Interactive and Performance Acceptance Tests (SIS II).........31 5.3.20. Supervision of execution of Operational System Tests (VIS) ........................32 5.3.21. Supervision of execution of Provisional System Acceptance Test .................32 5.3.22. Commercial Software Documentation Acceptance Report ............................33 5.3.23. Custom-built Software Documentation Acceptance Report ...........................33 5.3.24. Central Domain Documentation Acceptance Report......................................34

5.4. A-Services Project Phase 3: Deliverables related to Migration, Integration and Support.............................................................................................................................34

5.4.1. IT Services Management Plan Acceptance Report.........................................34 5.4.2. Migration Manual Acceptance Report (SIS II)...............................................35 5.4.3. Integration Manual Acceptance Report (VIS) ................................................35 5.4.4. Migration Completion Acceptance Report (SIS II) ........................................35 5.4.5. Integration Completion Acceptance Report (VIS)..........................................35 5.4.6. Final System Acceptance Report....................................................................36

5.5. B-Service Deliverables .........................................................................................36 5.5.1. Deliverables ...................................................................................................36 5.5.2. Preparation of operational management of new systems ................................37

6. Evaluation of the Support Contractor's performance..................................................38 6.1.1. Continuous evaluation of the Support Contractor’s performance...................38


1. INTRODUCTION

Units C2 and C3 of the Directorate-General Home Affairs of the European Commission (DG HOME) is in charge of large-scale IT systems in the field of Home Affairs matters. In the past DG HOME developed a European automated fingerprint identification system (EURODAC) aiming at assisting in determining the Member State, which is responsible pursuant to the Dublin Convention for examining an application for asylum lodged in a Member State. Currently, DG HOME is in charge of developing several large-scale IT systems: a new Schengen Information System (SIS II), a Visa Information System and an upgrade of EURODAC (EURODAC PLUS). Further large-scale IT systems are envisaged to be developed in the future.

1.1. Context

DG HOME does not develop large scale IT systems in-house, but contracts the development and roll out of a system to a contractor (“main development contractor” or MDC).

The quality assurance activities of the Deliverables of the main development contractor are performed by a Support Contractor, to be contracted within the scope of this call for tender.

For some projects (e.g. SIS II and VIS) an external Project Support Office (PSO) is used. The Project Support Office for the project is primarily aimed at providing the project management groups with the project support structure and services required for both projects to ensure time and quality delivery. The PSO does not carry out quality assurance activities on deliverables, but assists the Commission in controlling the development process.

The Support Contractor is required to work in close collaboration with all current and future contractors. The Support Contract will be required to carry out A-Services. Moreover, the Support Contractor may have to carry out B-Services. These services relate to the current projects and/or other new large-scale IT projects of the Commission.

Against this background, the Support Contractor needs to be aware of the current state of play of the projects in DG HOME. From a legal point of view, the following overview of future projects is purely an indication, as the decision for projects to be executed lies with the European Legislator. Therefore this overview does by no means commit the Commission, nor oblige the Commission to assign any Services.

1.1.1. Schengen Information System

The Schengen Information System (SIS) is a joint information system that enables administrative authorities, by means of an automated search procedure, to have access to Alerts on persons and property for the purposes of border checks and other police and customs checks carried out within the countries, and, to a certain limit, for the purpose of issuing visa and residence permits.


On 29 May 2001 the Council decided that the development of the second generation Schengen Information System (SIS II) would be charged to the budget of the European Community as opposed to the inter-governmental financial arrangements in which each Member State pays a proportion of the annual costs which prevailed previously. A Council Regulation and a Council Decision on the development of SIS II were adopted on 6 December 2001, conferring to the Commission the responsibility for the development of SIS II. A Committee composed of representatives from the Member States assists the Commission.

The new system, SIS II, will benefit from the latest developments in the field of information technology and will serve an increased number of participating countries and other users in the near future and provide them with additional functionalities.

The SIS II project will develop and deploy a Europe-wide large-scale information system to replace the current technical implementation of the Schengen Information System (SIS). SIS II responds to the need to service an increasing number of Users, from 15 countries participating in the current SIS to more than 30 Users in the near future. Therefore the Users will have to be closely associated with the project. Since the enlargement in 2007 30 countries participate in the SIS II and VIS projects: the 27 Member States of the European Union and Norway, Iceland and Switzerland. The United Kingdom and Ireland participate in SIS II and VIS, even though they are not members of the Schengen area.

Each country participating in SIS is represented in the “SIS II Committee”, which is a forum that allows for the expression of Member State opinions.

SIS II will provide the potential for additional functionalities, such as new categories of data and the use and storage of images and Biometrics. Both the volume of queries and the size of the database are expected to grow significantly in the foreseeable future and SIS II must be able to handle that growth.

Call for tender JAI-C3-2003-01 covered the provision of services and supplies related to the development and roll-out of SIS II, including the provision of support and other services to Member States for the migration from the current system to SIS II no later than December 2008.

In 2009, an analysis and repair period for SIS II was conducted between January and April 2009. This process was triggered by a failure of the main development contractor to pass the Operational Systems Test (OST) in December 2008. During the analysis and repair period a large number of known issues and bugs were repaired and an in-depth technical architecture review was performed. Solutions were either designed or implemented, leaving nonetheless a few issues pending.

Based on the SISII report, the Council concluded on 4-5 June 2009 that the development of SIS II will continue on the basis of the current SIS II project. The Council also agreed to two project milestones. The aim of these milestones is to prove the stability, reliability and performance of the central SIS II and the proper functioning of vital core functionalities.


The milestone 1 test re-run took place between 2 and 5 March 2010. A majority of Member States (13 out of 16 in the relevant expert bodies) concluded that the re-run test was "passed".

Accordingly, the JHA Council on 23 April 2010 decided that the development of SIS II will continue on the basis of the current SIS II project and invited the Commission to present a comprehensive global schedule for the entry into operation of SIS II to the Council at its meeting on 3-4 June 2010. According to this schedule, the SIS II is planned to be available in the first quarter of 2013.

1.1.2. Visa Information System

The Visa Information System (VIS) is a European information system to be set up for the exchange of Visa information between EU Member States. The objective of VIS is to facilitate the fight against fraud, to contribute to the prevention of “Visa shopping”, to improve visa consultation, to facilitate checks and the application of the EC Regulation N° 343/2003 (Dublin II Regulation), to assist a return policy and contribute towards improving the administration of the common visa policy, as well as towards internal security and the combating of terrorism.

The Commission submitted the results of a feasibility study on technical and financial aspects of the VIS to the Council in May 2003.

The Council of 5-6 June 2003 confirmed the objectives of the Visa Information System (VIS) and invited the Commission to continue its preparatory work on the development of the VIS in cooperation with Member States. With a view to not delaying the implementation of the VIS system, the Council decided to include a part of the requirements of the Visa system in a common call for tender with the SIS II, while at the same time, reserving the right not to implement such a system.

On 8 June 2004, the Council gave the mandate to the Commission to develop the VIS and constituted the required legal for the development of VIS and the execution of that part of the budget, including preparatory measures necessary for biometric features to be incorporated at a later stage in accordance with the Council Conclusions of 19 February 2004.

The same Call for tender as for SIS II, JAI-C3-2003-01, covered the provision of services and supplies related to the development and roll-out of VIS. The VIS development and roll-out project is ongoing.

The Factory Acceptance Test took place in autumn 2009 and the subsequent System Solution Tests were completed in July 2010. The Operational System Tests with 7 Member States are expected for the autumn 2010 and the Provisional System Tests are scheduled for the first half 2011.

The VIS is planned to be fully tested and available for a Production phase with Member States at the end of the first half of 2011.


1.1.3. Eurodac

The Eurodac system enables Member States to identify asylum applicants and persons who have been apprehended while unlawfully crossing an external frontier of the Community. By comparing fingerprints, Member States can determine whether an asylum applicant or a foreign national found illegally present within a Member State has previously claimed asylum in another Member State or whether an asylum applicant entered the Union territory unlawfully.

Eurodac consists of a Central Unit within the Commission equipped with a computerized central database for comparing the fingerprints of asylum applicants and a system for electronic data transmission between Member States and the database.

In addition to fingerprints, data sent by Member States include in particular the Member State of origin, the place and date of the asylum application if applicable, sex and reference number. Data are collected for anyone over 14 years of age and are entered directly into the database by the Central Unit.

In the case of asylum applicants, data are kept for ten years unless the individual obtains the citizenship of one of the Member States, in which case their particulars must be immediately erased. Data relating to foreign nationals apprehended when attempting to cross an external border unlawfully are kept for two years from the date on which the fingerprints were taken. Data are immediately erased before the end of the two years if:

• the foreign national receives a residence permit, or

• has left the territory of the Member States.

In the case of foreign nationals found illegally present within a Member State, Eurodac makes it possible to check their fingerprints against those in the central database to determine whether the individual had previously lodged an asylum application in another Member State. After the fingerprints have been transmitted for comparison purposes they are not stored by Eurodac.

Until the development of Eurodac II, hardware upgrades have been foreseen to increase the system capacity and performance to allow for the increased use of the system. This upgrade project has been named “Eurodac Plus”. The deliverables for Eurodac Plus will involve both A-Services and B-Services.

1.1.4. Biometric Matching System BMS-1: BMS-VIS

BMS-VIS aims to develop and implement the biometric matching transactions and infrastructure for the Visa Information System. Under the BMS framework contract, this is the first scenario implemented, and as such the generic BMS infrastructure on which the other scenarios could build their specific applications. The BMS-VIS is a subsidiary system to the VIS system and does not have any direct communication with users. The BMS is now in Provisional System Acceptance phase after having been fully connected to the VIS; final integration is foreseen as a VIS Main Development Contractor task. The BMS-VIS project team may need to finalise or update a number of deliverables. This project started in December 2006 and will finish when VIS goes live.


1.1.5. Biometric Matching System BMS-2: BMS-SIS II

The SIS II system without automatic biometric identification functionalities has to be operational by 2013 at the latest. BMS-SIS II aims to develop and implement the biometric matching transactions and infrastructure for the Schengen Information System II. These specification transactions will be implemented using the generic BMS infrastructure already put in place by BMS/VIS. This back-end will only receive transactions from SIS II, no direct user interaction. This project will also need to update a number of deliverables that have been produced in the SIS II project. This project start date is unknown.

1.1.6. Biometric Matching System BMS-3: Eurodac II

Eurodac II aims to develop and implement the biometric matching transactions, infrastructure and application logic for Eurodac. This project will completely replace the Eurodac Plus system and does have direct user interaction with all MS. The back-end (biometric engine) would again use the generic BMS infrastructure.

In its conclusions of 12-13 June 2007, the JHA Council invites the Commission to present "as soon as possible" a proposal based on Title IV of the Treaty establishing the European Community, designated to amend Council Regulation (EC) No. 2725/2000 of 11 December 2000 concerning the establishment of "Eurodac". The amendment aims at enabling Member States' police and other law enforcement authorities as well as Europol to have under certain conditions access to Eurodac for the purpose of consultation in the course of their duties in relation to the prevention, detection and investigation of terrorist offences and other serious criminal offences.

The project is unlikely to start in the near future as Eurodac II would replace the by then outdated Eurodac Plus, which has not yet become operational (Eurodac Plus will replace Eurodac soon).

1.1.7. Entry-exit system - Registered traveller programme

An automated entry-exit system, as well as the setting up of a Registered Traveller programme have been included in the Commission Communication to the Council and European Parliament on improved effectiveness, enhanced interoperability and synergies among European databases in the area of Justice, Freedom and Security (hereinafter “Synergies Communication”), as one of the possible scenarios for future developments in the area. Both are two of the three strategic objectives of the Directorate-General Home Affairs in 2011. The idea of an entry-exit system was also taken on board and further developed in the Communication on Policy Priorities in the fight against illegal immigration of third-country nationals, adopted by the Commission on 19 July 2006. The Policy Plan on Legal Migration, furthermore, considers it as a component of a possible future EU scheme for the admission of seasonal workers. Thus, due to the complexity of the issue, as well as its political dimension, it is important to make an impact assessment of the various policy options linked to the establishment of the above automated systems well in advance, so as to allow the Commission to make the right policy choice.


The setting up of the systems mentioned above would address the following issues/challenges:

• on the one hand, strengthen border control procedures related to third-country nationals so as to help better manage migration flows, prevent illegal immigration and any possible threats to the security of the EU;

• on the other hand, facilitate border crossing (both on arrival and on departure from the EU) to both EU citizens and third-country national bona fide travellers, thus allowing border control resources to be focused on “risky” categories of persons.

Therefore, a study was launched in early 2007 to carry out a preliminary and integrated assessment of the direct and indirect social, economic and environmental impacts of the creation of an automated entry/exit tracking system for third country nationals at the external borders of the Member States of the European Union and of the introduction of a border crossing facilitation scheme for bona fide travellers (“Registered Traveller programme”). This preliminary study identified and developed options available and feed into further, more technical work on the feasibility of the option(s) proposed.

The objective of the subsequent technical feasibility study that was launched once the interim report of the preliminary study was accepted was to carry out an integrated technical assessment of one or more validated options for creating an automated entry-exit tracking system for third country nationals at the external borders of the Member States of the European Union and of the introduction of a border crossing facilitation scheme for bona fide travellers (“Registered Traveller programme”). Any such development for such system(s) would require a legal basis.

The final report of the preliminary study was accepted in late 2007 and the technical feasibility study finished in early 2008. A cost study on the options was completed in early 2010. The impact assessments have been prepared and will be presented to the Impact Assessment Board in late 2010. The two draft legal instruments are scheduled to be adopted by the Commission in June 2011.

1.2. Contractual context

1.2.1. SIS II -VIS development contract

The decision was taken to combine the development and implementation of SIS II and VIS. Although both projects are conducted separately, there is close co-operation between them. From a technical point of view SIS II and VIS benefit from the use of common elements possibly with different capacities, i.e. identical hardware and software, thus creating synergy effects.

DG JLS signed a contract for the development and roll-out of SIS II and VIS (Call for tender JLS-C3-2003-01). This contract covers:

• The provision of all services and supplies related to the development and roll-out of SIS II, and the provision of support and other services to Member States for the migration from the current system to SIS II.


• The provision of all services and supplies related to the development and roll-out of VIS and the provision of technical support and other services to Member States.

Both systems are being developed and rolled out by one contractor. The development of biometric functionalities for identification and verification is not within the scope of this contract. The development of the BMS is covered by a separate contract.

1.2.2. BMS development contract

The BMS framework contract was signed in December 2006 for a maximum duration of 7 years. This framework contract covered the development of four possible scenarios: BMS-VIS, BMS-SIS II, Eurodac II and a provisional scenario for a Central Criminal AFIS (CCAFIS). All scenarios are fixed price projects on the basis of detailed specifications (with the exception of scenario 4, which was largely hypothetical at the time). The BMS system would be implemented as a ‘Service Oriented Architecture’ (SOA) that would be able to service a number of different applications.

1.2.3. Network development contract

In the framework of Framework Contract ENTR/2006/024, the s-TESTA contract's objective is to deliver the infrastructure and associated services for a secured reliable and managed Trans European communication platform. These services will be available to all national administrations, European institutions and European Agencies and will allow the exchange of information up to the level of “Restricted EU”.

The third s-TESTA specific contract concerns the provision of the infrastructure and professional services required for the implementation, management, operation and support, especially covering the central unit (CU)-backup central unit (BCU) connection.

The fourth s-TESTA specific contract concerns the provision of the infrastructure and professional services required for the implementation, management, operation and the support, especially covering the Member States’ connections.

1.2.4. Project Advice and Support Office contract

In order to improve communication and the follow-up of the delivery process, the Project Advice Support Office (PASO) assists the Commission to improve the organisation and the development monitoring of the projects. To this end the Project Advice and Support Office (PASO) will assist the Commission in enforcing its project organisation. This effort will be directed to all the involved parties, including Member States and the Main Development Contractor. It includes also follow-up of agreed actions, active risk and issue-management and taking minutes of technical meetings, if requested.

In this framework, the PASO reports to the Commission on:


� The progress made on the project in general; � Encountered issues accompanied by envisaged actions, to recover from

the issue; � Identified risks and associated mitigation plans; � Status of agreed actions and action results.

2. PROJECT DEVELOPMENT WORKING METHODS

2.1. Project development methodologies

State-of-the-art IT project methodologies must be used in all project areas, e.g. project management, documentation, solution analysis and design and security.

Since the beginning of 2007 DG JLS and later DG HOME as well uses RUP@EC for its IT-developments. RUP@EC is a customised version of the RUP® (IBM Rational Unified Process®) methodology for use within the Commission.

The Rational Unified Process® product is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget.

The Rational Unified Process is a flexible software development process platform. Through its configurable architecture, RUP enables to select and deploy only the process components (including roles, activities, templates, guidelines and tool mentors) needed for each stage of the project. With industry-proven software engineering best practices at its core, the RUP platform includes tools for configuring RUP for project's specific needs, tools for developing internal knowledge into process components, powerful and customizable web-based deployment tools, and an online community for exchanging best practices with peers and industry leaders. By using a proven methodology and sharing a single comprehensive process, the team will be able to communicate more effectively and work more efficiently.

The first version of this methodology consists of customised methodology disciplines, Eurolook templates, etc. and fully embeds the provisions laid down in the IT Governance communication, the Information System Security Policy, the Commission Enterprise Architecture Framework and includes guidelines for Data Protection.

The overall architecture of the RUP, which has two dimensions:


The horizontal axis represents time and shows the lifecycle aspects of the process as it unfolds. This first dimension illustrates the dynamic aspect of the process as it is enacted and is expressed in terms of phases, iterations, and milestones.

The vertical axis represents disciplines that logically group activities by nature. This second dimension portrays the static aspect of the process - how it is described in terms of process components, disciplines, activities, workflows, artifacts, and roles.

A simplified methodology is available for low risk projects. RUP@EC provides a lightweight development case for low risk projects based on the development case used at DG AGRI. The development case for low risk projects limits the number of artefacts to be produced, but remains compatible with Commission-wide frameworks such as the IT Governance communication, the Information System Security Policy and the Commission Enterprise Architecture Framework.

2.2. Architecture of HOME projects

The basic architecture of most HOME projects for system development is identical. Normally, a system will consist of:

• A Central System (CS) based on two distinct geographical sites, referred to as Central Unit (CU) and the Back-up Central Unit (BCU) hosting the data and the associated search engines with 99.7- 99.99% availability.

• At least one Access to the Central System Domain via a National Interface for each User with a 99.7-99.9% availability. In order to meet the operational requirements, a second Access point may be required for some Member States.

The Deliverables required for the development of the systems consist of all hardware, software and services to be provided in relation to the Central Domain.

Systems will share their technical infrastructures as much as possible, i.e. run on identical hardware platforms (possibly with different capacities), use the same operating systems, the same software applications and share common concepts.

The projects for the development and the roll-out of the systems will therefore be conducted separately but in close cooperation.


The SIS II and VIS CU and BCU systems will be hosted near Strasbourg (France) and Salzburg (Austria). Eurodac is currently hosted in Luxembourg.

2.3. Data content

In terms of data content the systems will provide one or more of the following functionalities:

• Storage, search and delivery of alphanumeric data,

• Storage, search and delivery of fingerprints,

• Storage and delivery of images (e.g. photographs, scanned documents).

In the future, additional types of search engines may be integrated into the systems (e.g. image search engines) and other types of data may be stored and searched (DNA, facial recognition, iris images / templates etc).

2.4. Project management

For the project development, both the MDC and the Commission have set up project management teams. The Commission team is composed of a programme officer, deputy programme officer and project officers for each project. The development contractor’s team is composed of a programme manager, project manager and deputy project manager for each project. All of them are involved in the Global Project Management Board (GPMB). The role of the GPMB is to give advice on any and all issues concerning the implementation of the projects. A representative number of Member States also participate in the GPMB. GPMB meetings are held monthly, or at any other frequency deemed appropriate for the successful completion of the projects.

The Support Contractor – to be contracted under this contract – also participates in the GPMB.

In addition, project meetings will be held that deal with the day-to-day implementation of the systems. Other meetings will be held as often as required, at least once a week.

The meetings will be conducted in English and will normally be held in Brussels.

The Support Contractor is expected to regularly assist the Commission during these meetings if deemed necessary by the Commission Services.

2.4.1. Project Phases

Given that large scale project runs over several years, projects are divided into several phases. Most projects are divided into three phases:

• Project Phase 1 - Detailed Design, resulting in full system specifications and a full set of interface specifications defining the communication processes between National System and Central System, via the National Interface.

• Project Phase 2 - Development, testing and deployment of the systems (Core System simulator, National Systems simulator, Central Unit, Back-up


Central Unit, National Interface, Back-up National Interface, development/pre-production/production environments).

• Project Phase 3 – Migration and Integration of Member States for the connection of their National Systems to the National Interface.

As regards the project phases the following needs to be understood:

Project Phase 1 - Detailed Design

Starting from the business processes and the architecture the development contractor will perform an analysis of the problem domain. This will produce the detailed specifications of the system. This deliverable will form the basis of the solution design, which in turn consists in particular of the functional and technical design documents and the Interface Control Document.

The design of the solution will resolve any open issues concerning implementation of the architecture and interoperability. The development contractor will also describe in detail the approach for the future expansion of the system (notably the inclusion of Biometrics). The design will contain integration specifications that can be used by the Member States to implement the National Systems.

The design will include a detailed description of the hardware to be installed at the central locations as well as the hardware needed to set up National Interface. The National System simulator and the Central Domain simulator are part of the design.

The development contractor will draw up a comprehensive test plan, which must be accepted by the Commission assisted by the Support Contractor. As the system is largely a back-end application, some work will need to be done to create test-applications to enable verification and validation of the Central Domain. This plan will consist of a test strategy, test plans and validations specifications for all components of the architecture.

At the end of Project Phase 1 the development contractor must be ready to start development, and the Member States must receive the Interface Control Document to allow them to make their own preparations and system updates or replacements.

Project Phase 2 – Development, testing and deployment

The development of the system will be based on the technical design, taking into account the project management techniques of the contractor. At all times, configuration and change management procedures will be applied.

The hardware for the central location will be delivered and installed by the development contractor. In order to ensure connectivity on the network to be used, the development contractor will co-ordinate the activities with the concerned services (Member States, Commission, network contractor). Installation of the hardware will include installation of system software such as operating system and specific applications that the system will use (database, application server etc.).


The Central System will be delivered at the designated locations. It will be connected to the communication infrastructure, and integrated into the Central Domain. A number of conclusive tests will be run to ensure that the integration has been successful. Given the differing timelines of Central Domain and Member States, it is to be expected that elements of the integration scenario will be tested later.

The system can be considered as delivered when all the accepted tests have been run successfully (within the agreed testing procedures), and when the system is effectively ready for production.

Project Phase 3 – Migration and Integration

The development contractor will provide a SISII Converter that will be able to transfer and accommodate the data from SIS1+ to SISII. Moreover the contractor will be in charge of defining all the procedure and document to accomplish the SISII Migration.

The development contractor will optionally provide training for the appropriate staff, for example: the system administrators, the DBAs, and for the technical personnel of the Member States.

Moreover, throughout the project and to a certain extent, Member States may request the development contractor to provide additional support which will be dealt with on a case-by-case basis and through a specific request.

2.4.2. Work packages (WP)

For monitoring purposes, most development contracts are divided into work packages. The work packages have a number of common characteristics, such as:

• Objectives

• Participants

• Starting conditions

• Organisational activities

• Development activities

• Verification activities

• Customer involvement

• Output products

• End conditions

The general structure of elements that make up a description of a WP is:

• scope of the WP (refers to the objective)

• management of the WP (refers to organisational activities)

• deliverables and milestones of the WP (development activities and output products)

• quality indicators for the WP (relates to verification activities)


• closing criteria of the WP (relates to the inherent quality objectives and criteria)

Optional:

• involved resources and COM contact points (refers to participants and customer involvement)

• communication structure (relates to organizational activities)

3. ASSIGNMENT OF DELIVERABLES

The deliverables to be delivered by the Support Contractor are A-Services and B-Services. As regards the formal execution of these services, differing procedures apply.

3.1. Assignment of Services

3.1.1. Assignment of A-Services

As regards A-Services, the following has to be understood. The Deliverables as submitted by the Main Development Contractor (MDC) go through an acceptance procedure, which varies depending on the type of the deliverable.

When accepting a Deliverable as submitted by the MDC, the Commission mostly relies on the analysis of its external contractor and decides later as to whether endorse or not the recommendation as put forward by the external contractor.

The Deliverables of MDC, as to be reviewed by the future Support Contractors, are defined as A-Services (either original reviews or updates). The Commission will decide, at its sole discretion whether it requests the Support Contractor to assist in the analysis of the Deliverable of the MDC.

The Commission, following the analysis of the content and the nature of the change made to the given Deliverable, reserves the right to define whether it needs a full review cycle (ie. original review cycle) or an update. For instance, if a new version of the Deliverable becomes necessary due to project event changes, it is up to the Commission to decide if it orders an update – defining how many versions the update should cover – or an original review.

During the original and the update review cycles, the Support Contractors will have a fixed time-span defined at the moment the acceptance of a Deliverable is requested, to perform the corresponding acceptance review and report to the Commission. The Support Contractor is required to adopt a proactive approach when carrying out the services. Support Contractor's tasks go beyond the mere delivery of an accurate acceptance report on the Deliverable produced by the MDC. The Support Contractor must produce tangible results (Support Deliverables) and collaborate with the MDC in a proactive manner. If the Support Contractor, when setting up the (update) acceptance report, comes to the conclusion that the Deliverable does not meet the requirements and therefore cannot be accepted, the MDC must be in a position to understand easily and thereafter adapt, change or modify the Deliverable in line with the


recommendations, instructions and guidelines laid down in the acceptance report. The revised Deliverable will then be re-submitted for acceptance.

The Commission will assign the A-Services using Specific Contracts. Details are laid down in Annex 12 –Framework Contract and Annex 13 – Service Level Requirements. From a legal point of view, the Commission is not obliged to assign any A-Services to the Support Contractor.

3.1.2. Assignment of B-Services

Once the B-Services to be carried out have been identified, the Commission Services may decide to assign the B-Services. B-Services will be assigned via a Specific Contract. Details are laid down in Annex 12 –Framework Contract and Annex 13 – Service Level Requirements.

If the Support Contractor and the Commission services cannot agree on the volume of the respective B-Service, the following procedure will apply:

• The Commission services and Support Contractor each designate two persons within or outside their respective organisation, who will estimate the workload of a given assignment (the “estimators”);

• The Commission project officer who is in charge of the assignment, explains to the “estimators” the objectives and scope of the requested assignment and provides any information relevant for estimation;

• Each estimator quantifies the amount of workload, individually and without help of another estimator, to professionally execute the assignment and documents his assumptions;

• The Commission project officer requires the assumptions of the four “estimators” and validates the ones that are the most likely. The estimators are asked to modify their estimates according to these validated assumptions;

• The Commission project officer receives the four estimates on the same day and eliminates the one with the highest and the lowest workload. S/he calculates the arithmetic average of the two remaining estimates. This workload is then accepted as the workload that settles the discussion.

• Preferably, this procedure should be carried out within two working days.

3.1.3. Language

The written and spoken working language for all A- and B-Service-related tasks is English.

The SIS II/VIS MDC, when designing and developing SIS II is required to consult documents in French regarding the current SIS located in Strasbourg. The Support Contractor when carrying out A-Services related to SIS II/VIS Deliverables may have to consult these documents also. If the Support Contractor does not have sufficient passive knowledge of French, any translation of the documents that may become necessary will be done by the Support Contractor and cannot be reimbursed.


3.1.4. Support Contractor’s Project Management

For the duration of the Framework Contract the Support Contactor is expected to appoint a Project Manager and a Deputy Project Manager who coordinate and manage the overall provision of all A-Services and B-Services by the Support Contractor. The Project Manager and Deputy Project Manager must meet the minimum requirements as laid down in item 4.1 "Project Manager/Deputy Project Manager" of Annex 11 – Part 2: Profile Description. The Project Manager and Deputy Project Manager replace one another to ensure continuity and a permanent availability of a Support Contractor's contact and management point for every Commission working day throughout the duration of the Framework Contract (e.g. also during vacation periods), unless otherwise agreed in writing.

For the execution of A-Services and B-Services, the Support Contractor must deploy the staff exactly as proposed in the technical offer (for A-Services) and as agreed in the specific contracts (for B-Services).

Replacement of the Project Manager and Deputy Project Manager as well as any member of the Support Contractor's staff involved in the execution of A-Services and B-Services is subject to the replacement provisions as set forth in the Framework Contract.

3.1.5. Formal project management procedure

The Project Manager will manage the execution of A- and B-Services according to the following formal project management procedure:

3.1.5.1. Quality Plan and Project Schedule for A-Services

Within 15 working days after the first A-Service has been assigned, the Support Contractor will submit a Quality Plan which defines precisely how the services will be delivered.

The Quality Plan must describe:

• The scope and its underlying assumptions;

• The project deliverables;

• The phases and activities that allow to produce these deliverables;

• The Support Contractor’s team organisation;

• The project schedule for A-Services showing the alignment with the MDC tasks;

• The reporting mechanism towards the Commission;

• The approval process of the deliverables;

• At least the following set of procedures: Quality assurance procedures, Risk Management procedures and Scope Control Procedures.

Operationally, the Quality Plan should be the reference document for the project and should be based on the (1) the proposed contract, (2) the present call for tender, (3) the Support Contractor’s proposal. The Quality Plan adds to these


legally binding documents the information on how the obligations and expectations contained in these documents are going to be fulfilled.

3.1.5.2. Quality Plan and Project Schedule for B-Services

Within fifteen working days after the first assignment of a B-Service, the Support Contractor will set up and submit a general Quality Plan that defines precisely how the B-Services will be delivered.

The general Quality Plan for B-Services documents:

• The processes for requesting and ordering services;

• The scope definition and scope management of individual assignments;

• The Support Contractor’s team organisation for managing B-Services;

• The reporting mechanism towards the Commission;

• The approval process of the deliverables;

• At least the following set of procedures: Quality assurance procedures, Risk Management procedures and Scope Control Procedures.

Before the start on an individual assignment, the general Quality Plan will be updated with the following complementary information related to the assignment:

• The project deliverables of the assignment;

• The phases and activities to produce these deliverables;

• The agreed budget and workload;

• The project schedule for the specific assignment;

• The team organisation and team members assigned to the project.

3.1.5.3. Quality Assurance Procedures

Quality Assurance procedures describe the approach to planning and managing every aspect of quality throughout the project lifecycle.

The Support Contractor is required to define a pragmatic and effective approach to ensure the quality of its work for A-Services and for the on-going assignments of B-Services, and to ensure that all foreseen activities are duly executed.

3.1.5.4. Risk Management Procedures

The Support Contractor is required to define and maintain risk management procedures for A- and B-Services, which identify the possible issues that could threaten the successful completion of the assignment – including not meeting acceptance criteria or missing deadlines.

Risk management procedures must indicate strategies to manage risks in terms of prevention and mitigation.


3.1.5.5. Scope Control Procedures

The Support Contractor must:

(1) provide and maintain a Scope Control Procedure which describes the exact procedure to follow in case of changes to the work related to A- and B-Services;

(2) log the changes that were approved to the definition of A-and B-Services, in order to be able to trace changes to Deliverables.

3.1.5.6. Meetings and Progress Reports

Follow-up meetings and reports

Follow-up and reporting of the completion of A- and B-Services, must be adjusted in accordance with the volume and complexity of on-going activities. Regular contacts with HOME.C2 and C.3 Project Management Teams need to be foreseen in order to ensure work progress, identify issues and risks. Following this regular contact there will be an update and agreement on the monthly report. Tracking of resources used, costs and time will be included in the monthly report. Indications on deviations from the original planning must also be presented in the progress reports

Monthly report (MR)

The Support Contractor shall submit monthly reports in the layout and within the time limit as given in Annex 13 – Service Level Requirements to the Commission. At least once a month the monthly report will be presented and discussed at the Commission premises in Brussels.

4. ACCEPTANCE OF MAIN DEVELOPMENT SERVICES

Acceptance of Main Development Deliverables

Deliverables developed by the MDC should be evaluated with regard to the following criteria:

• “Coherence with requirements”: does the Deliverable correspond to the development Tender Specifications and the Member States’ requirements;

• “Coherence with purpose”: does the proposed Deliverable meet the objective and purpose for which it was created;

• Completeness: Deliverable must address all the points that it is required to cover;

• Acceptability by Member States: the Deliverable must correspond to the expectations and issues of the participating Member States;

• Level of detail: the Deliverable must address all points with the required level of detail appropriate to the project phase;

• Consistency with the proposed architecture: the content of the Deliverable must be consistent with the principles and objectives at the basis of the system;


• Formal aspects: the Deliverable or its Documentation must be well written, understandable and exempt of language, drafting or typographical mistakes.

Monitoring of Main Development Service Delivery

The Support Contractor will monitor services delivered by the MDC to the Commission in comparison to the agreed service and quality levels. Evaluation of services delivered should be carried out with regard to:

• “Coherence with purpose”: Do the services meet the objective and purpose for which they were intended?

• “Responsiveness”: Is an answer to service requests provided according to the agreed processes and within an acceptable delay?

• “Professionalism”: Are the services delivered by personnel sufficiently experienced in their domain?

• “Formal aspects”: Are the services delivered in a formally correct and comprehensible way?

5. SUPPORT SERVICE DELIVERABLES

The Support Deliverables are described below, stating for A-Services first the Support Service and following the corresponding MDC Deliverable. For each Deliverable the Tenderer is expected to submit an offer matching at least the required profiles.

Not all deliverables will be required for all projects.

5.1. Acceptance procedures (Review cycle)

In line with the provisions of the Tender Specifications, Annex 12 – Framework Contract, the A- and B-Services [Support Deliverables] have to be accepted by the Commission. The acceptance of the A- and B-Services [Support Deliverables] is subject to the formal and legally binding review cycle, described in the Tender Specifications, Annex 12 – Framework Contract.

5.2. A-Services Project Phase 1: Detailed design Deliverables

5.2.1. Protection Profile Acceptance Report

Define and apply acceptance process for Protection Profile. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant Biometrics", one person with the profile "Security Specialist" and one person with the profile "Quality Consultant".


5.2.1.1. Protection Profile

A Profile defined according to a recognised standard like ISO 15408 specifications, to allow the systems to achieve a security level compliant with the requirements. All actors (especially the Member States) must validate this profile.

The Protection Profile describes an implementation-independent set of security functional and assurance requirements for a category of IT products that meet specific consumer needs. It is used in the context of evaluating systems security by using the Common Criteria – ISO-15408.

5.2.2. Security Target Acceptance Report

Support Contractor's activities regarding the security target. Define and apply acceptance process for Security Target. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects.


5.2.2.1. Security Target

A specification of the security required (both functionality and assurance) of a Target of Evaluation (TOE), used as a baseline for evaluation under the Common Criteria – ISO-15408. The security target will specify the security enforcing functions of the TOE. It will also specify the security objectives, the threats to those objectives, and any specific security mechanisms that will be employed.

5.2.3. System-Specific Security Requirement Statement (SSRS) Report

Support Contractor's activities on the System-specific security requirement statement.


5.2.3.1. System-specific security requirement statement (SSRS)

A 'System Specific Security Requirement Statement’ (SSRS) is a complete and explicit statement of the security principles to be observed and of the detailed security requirements to be met. It is based on security policy and risk assessment, or imposed by parameters covering the operational environment, the lowest level of personnel security clearance, the highest classification of information handled, the security mode of operation or user requirements. The SSRS is an integral part of project documentation submitted to the appropriate authorities for technical, budgetary and security approval purposes. In its final form, the SSRS constitutes a complete statement of what it means for the system to be secure.


5.2.4. Security Plan Acceptance Report

Define and apply acceptance process for Security Plan. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.


5.2.4.1. Security Plan

A document that refers to all security related activities associated with a specific information system.

5.3. A-services Project Phase 2: System Development and Deployment Deliverables

The development deliverables of phase 1 may have to be updated during phase 2 and/or phase 3. In that case, the Project Officer will decide whether to submit the updated deliverable to the Support Contractor to trigger the formal acceptance procedures. In practice this is required when the updates are of a substantial nature. The Support Contractor is asked to provide an estimate for the acceptance of one updated version for each phase 1 deliverable. In case a deliverable is updated several times, the additional acceptance reports will be re-ordered on the same basis.

5.3.1. Updated Master Project Plan Acceptance Report

Define and apply acceptance process for Updated Master Project Plan. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant" and one person with the profile "Quality Consultant".

5.3.1.1. Updated Master Project Plan

Updated version of the Master Project Plan.

5.3.2. Updated Quality Assurance Plan Acceptance Report

Define and apply acceptance process for Updated Quality Assurance Plan. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant".


5.3.2.1. Updated Quality Assurance Plan

Updated version of the Quality Assurance Plan.

5.3.3. Updated Interface Control Document Acceptance Report

Define and apply acceptance process for Updated ICD. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics" one person with the profile "Senior Analyst", one person with the profile "Security Specialist", one person with the profile "Quality Consultant", one person with the profile "User Requirements Analyst" and one person with the profile "Analyst Programmer".

5.3.3.1. Interface Control Document (ICD)

The ICD describes in detail the exchange of information between the National Systems and the Central System via the National Interface. This includes e.g. messages structures, security, protocols and communications and will act as the external specifications for the system upon which the Users will develop their National Systems.

5.3.3.2. Updated Interface Control Document

Updated ICD, including the change log.

5.3.4. Updated Technical Detailed Technical Specifications Acceptance Report

Define and apply acceptance process for Updated Technical DTS. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics" one person with the profile "Senior Analyst", one person with the profile "Security Specialist", one person with the profile "Quality Consultant", one person with the profile "User Requirements Analyst" and one person with the profile "Analyst Programmer".

5.3.4.1. Detailed specifications (DTS)

All detailed specifications needed for the development and the set-up of the systems.

5.3.4.2. Updated Technical Detailed Technical Specifications

Updated technical part of the DTS, including the change log.


5.3.5. Updated Functional Detailed Technical Specifications Acceptance Report

Define and apply acceptance process for Updated Functional DTS. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Security Specialist", one person with the profile "Quality Consultant", one person with the profile "User Requirements Analyst" and one person with the profile "Analyst Programmer".

5.3.5.1. Updated Functional Detailed Technical Specifications

Updated functional part of the DTS, including the change log

5.3.6. Updated Integration Plan Acceptance Report

Define and apply acceptance process for Integration Plan. Ensure fit to purpose, completeness, and adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable that Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Telecommunication", one person with the profile "Senior Analyst" and one person with the profile "Senior Quality Consultant".

1.1.1.1.Integration Plan

Comprehensive plan for User integration specifications, including procedures.

5.3.7. Hardware Acceptance Report

The acceptance procedure for hardware is comprised of the following elements.

(1) Acceptance of delivery. Upon delivery of the systems on the designated premises, the Commission assisted by the Support Contractor, will check if the delivery conforms to the order. Any discrepancies will be noted on the delivery note, and will need to be justified by the MDC and accepted by the Commission assisted by the Support Contractor.

(2) Installation acceptance. The Commission assisted by the Support Contractor will verify that the configuration is compliant with the specifications. The MDC will provide all information necessary to make this verification possible (this also comprises an installation plan, to be made prior to installation. This plan describes all installation and configuration tasks required).

(3) Production acceptance. The final acceptance for hardware will be part of the formal acceptance of the Main Development Project. The Support


Contractor will apply the system acceptance procedures and verify whether the system meets performance criteria under normal load and in stress load.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Technical Consultant Telecommunication", one person with the profile "Security Specialist", one person with the profile "Quality Consultant" and one person with the profile "System Administrator".

5.3.7.1. Hardware

The provision of the hardware components as foreseen in the contract.

• Delivery of all hardware • Installation of all hardware according to floor plans and rack lay-out • Configuration of all HW and SW components according to detailed design • Provision of standard hardware, COTS-, installation and configuration

documentation

Installing the hardware, installing the necessary COTS components on the hardware and configuring these components. This also includes the provision of the contractual networking components that are needed to connect the hardware systems to the Commission-provided network infrastructure. It also includes the hardware needed to perform monitoring of the production and pre-production systems, on the CU and BCU. At completion all components (hardware and software) must be brought under configuration management.

The hardware components must support the following systems:

• Production system CU • Production system BCU • Test system • Training system • Pre-production system • Development system • Monitoring system

5.3.8. Acceptance Report on Hardware Documentation, Commercial Software Documentation and Configuration and Installation Documents

Review and acceptance report on the standard hardware, COTS-, installation and configuration documentation.

Define and apply acceptance process for Hardware Documentation. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.


For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the "Quality Consultant", one person with the profile "Analyst Programmer", one person with the profile "System Administrator" and one person with the profile "IT Operations Manager".

5.3.8.1. Hardware Documentation

Full hardware description and specifications, with instructions for set-up, configuration, operation and troubleshooting.

5.3.9. Network Installation Quality Assurance

Define and apply acceptance process for MS network roll-out.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant Telecommunication" and one person with the profile "Quality Consultant".

5.3.9.1. MS network roll-out

The implementation, management, operation and the support, especially covering the Member States’ connections.

5.3.10. Functional Test Design Description Acceptance Report

Define and apply acceptance process for Functional TDD. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Analyst", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.3.10.1. Functional Test Design Description

Document describing the Functional Test Design.

5.3.11. Non-functional Test Design Description Acceptance Report

Define and apply acceptance process for Non-functional TDD. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.


For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.3.11.1. Non-functional Test Design Description

Document describing the Non- functional Test Design.

5.3.12. System development until Technical Tests without Member States (SIS II)

A build-report on progress of the development activities, including the reporting on the software quality indicators of the software components that are indicated is “finished” (frequency in accordance with the build cycles).

The provision of the necessary software components (including the components needed for monitoring of the system) needed for the implementation. Development of the software components as described in the DTS (technical part), according to and following the specifications as described in the DTS (Functional).

Contractor will make the code that is ready for review available at contractor premises for code-reviews after every successful build by the COM to verify that the code is conform the guidelines in the QAP. The result of the review will be reported to the MDC within five working days.

Following the code review report, contractor will take the necessary actions to amend the code that was found not to be compliant to the QAP guidelines.

The developed software components are to be delivered as ready for the Technical tests without MS.

5.3.13. Software Installation and Configuration Acceptance Report

Provision of the Support Contractor's services and deliverables during the deployment of the software on the sites, resulting in the delivery of an acceptance report on the Installation and Configuration report, containing a list of all installed components and their versions.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Security Specialist", one person with the profile "Analyst Programmer" and one person with the profile "Systems Administrator".

5.3.13.1. Software deployment on sites

Delivery, installation and configuration of the software.

Installation and configuration report, containing the list of all installed components and their versions (per system).

Installing the custom built software on the hardware, including the monitoring components. At completion all software components must be brought under configuration management.


The installation and set-up activities for the developed software components, on the following systems: • Production system (CU and BCU) • Test system (CU) • Training system (CU) • Pre-production system (CU and BCU) • Development system (CU) • Monitoring system (CU)

5.3.14. Environment set-up Acceptance Report

Provision of the Support Contractor's services and deliverables during the installation of the additional testing environments, resulting in the delivery of an Acceptance report on the Environment Set-up report, containing the list of all installed components and their versions (per environment).

Additional testing environment installation • Set up of environment • Environment setup report, containing the list of all installed components and

their versions (per environment)

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Security Specialist" and one person with the profile "System Administrator".

5.3.14.1. Environment set-up

Making a number of the existing environments available, those allow the MS to run informal tests.

Ensure that environments fit for running informal tests are set up on specific hardware platforms. In case of compliance testing two instances of the Central System will be made available on separate hardware platforms, to allow the MS to perform informal tests and compliance tests. The first instance (used for informal tests) will allow for up to 8 MS to run tests in parallel; the second instance (compliance testing) will allow for a maximum of 3 MS to run tests in parallel.

5.3.15. Business Continuity Planning Acceptance Report

Support Contractor's activities during the delivery of the Business Continuity Planning, Disaster Recovery Plan Acceptance report, Disaster Recovery Plan Test Report Acceptance report and supervision of activities.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Security Specialist" and one person with the profile "Senior Analyst".


5.3.15.1. Business Continuity Planning

• Disaster Recovery Plan • Disaster Recovery Plan Test Report

The Disaster Recovery Plan is required to ensure the availability and continuity of the central system in case of failure.

The Business Continuity planning shall be tested, executed and fine-tuned.

The execution of the DRP activities must be done by the organisation responsible for the system management at the time of execution of the activities.

COM is supervising and controlling the testing and execution of the activities within the scope. Contractor will perform the activities as described in the Business Continuity Planning.

5.3.16. Supervision of execution of Technical Test Without MS (SIS II)

• Supervision during verification of the corrections against the tests that originally failed

• Supervision of regression testing • Review of test report after every test run • Acceptance report on final Technical Test report.

Define and apply acceptance process for Hardware, Standard Software and Custom-built Software. Ensure completion of the acceptance tests. Ensure compliance to specifications. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Senior Analyst", one person with the profile "Analyst Programmer" and one person with the profile "Test Manager".

5.3.16.1. Technical Test Without MS

The scope of these tests is to test the central system (CS-SIS) in its production domain (the target environment), against all functional and non-functional specifications laid down in the reference version of the Detailed Technical Specification and in the Interface Control Document. The tests are carried out without national systems (N.SIS II) by HPS under supervision of the Commission on the sites in Strasbourg and St Johann im Pongau).

5.3.17. User Compliance Tests Acceptance Report

Define and apply acceptance process for User Compliance Tests. Ensure coherence with purpose, completeness, adequate level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical


Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.3.17.1. User Compliance Tests

Before a central system moves into production, each user must pass a number of tests to ensure compliancy of their implementation. Implementation may require these tests to be altered in some way or new individual tests added to the existing tests. The scope of the Compliance Testing Phase is to verify the compliance of the National Systems with reference version of the Interface Control Document and the Detailed Technical Specification.

5.3.18. Site Acceptance Test Report on Test Components, Acceptance Report on Documentation and Acceptance Report on Factory Testing Report

• Site Acceptance Test Report on the developed test-components (non-COTS) • Acceptance report on the relevant documentation accompanying the testing tools

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Senior Quality Consultant", one person with the profile "Quality Consultant", one person with the profile "System Administrator", one person with the profile "Analyst Programmer" and one person with the profile "Test Manager".

5.3.18.1. Tools necessary for testing

Set of tools used during development and testing of the CS, including their configuration, in the version that has been used during development and testing. They are considered as COTS insofar they are not developed in-house by the MDC. These tools allow testing the system, including after its deployment in production. All defined tests must be re-executable, in appropriate environments, after deployment of the system (including the period after the development contract is finished).

• Developed test-components (non-COTS) ready for factory test • Relevant documentation • The factory test for the tools, described in a TDD (self-built only) • A factory testing report on the tests and their results • Delivery of testing tools

5.3.19. Member States Interactive and Performance Acceptance Tests (SIS II)

Define and apply acceptance at system level. Ensure completion of the acceptance tests. Complete Acceptance Report. Supervision during verification of the corrections against the tests that originally failed. The successful outcome of the Interactive and Performance Acceptance Tests shall be confirmed through:

• Supervision of regression testing


• Review of test report (html) after every test run • Acceptance report on final OST/IPAT report

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.3.19.1. MS Interactive and Performance Acceptance Tests (SIS II)

The scope of the MS Interactive and Performance Acceptance Tests (IPAT) includes testing the Central System against functional specifications impacted by the interaction of different N(ational).SIS II during the alert life cycle and non-functional specifications related to the use of connected N.SIS II. The IPAT will test the Central System with a set of at least six connected national systems.

5.3.20. Supervision of execution of Operational System Tests (VIS)

Define and apply acceptance at system level. Ensure completion of the acceptance tests. Complete Acceptance Report. Supervision during verification of the corrections against the tests that originally failed. The successful outcome of the Operational System Tests shall be confirmed through:

• Supervision of regression testing • Review of test report (html) after every test run • Acceptance report on final OST report

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.3.20.1. Operational System Tests

The scope of the Operational System Tests (OST) includes testing the Central System against functional specifications impacted by the interaction of different N(ational).SIS II during the alert life cycle and non-functional specifications related to the use of connected N.SIS II. The OST will test the Central System with a set of at least six connected national systems.

5.3.21. Supervision of execution of Provisional System Acceptance Test

• Supervision during verification of the corrections against the tests that originally failed

• Supervision of regression testing • Review of test report (html) after every test run • Acceptance report on final PSAT report


Define and apply acceptance at system level. Ensure completion of the acceptance tests. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Quality Consultant", one person with the profile Senior Analyst and one person with the profile "Test Manager".

5.3.21.1. Provisional System Acceptance test

The objective of PSAT is to test whether the central system meets the expected performance requirements. The scope of the PSAT includes testing the connectivity and the response time for queries under nominal and peak load of the Central System with the traffic load generated by thirty N.SIS II, of which fifteen should be connected N.SIS II.

5.3.22. Commercial Software Documentation Acceptance Report

The acceptance procedure for standard software (COTS) is equal to the one for hardware. If the standard software does not need to be parameterised, the second acceptance can be omitted, but if configuration or parameterisation needs to be done, this acceptance is mandatory as well.

Define and apply acceptance process for Commercial Software Documentation. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant", one person with the profile "Analyst Programmer", one person with the profile "System Administrator" and one person with the profile "IT Operations Manager".

5.3.22.1. Commercial Software Documentation

Full functional and technical description of the software, with instructions for set-up configuration, operation and troubleshooting.

5.3.23. Custom-built Software Documentation Acceptance Report

Define and apply acceptance process for Custom-built Software Documentation. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant", one person with the profile "Analyst Programmer", one person


with the profile "System Administrator" and one person with the profile "IT Operations Manager".

5.3.23.1. Custom-built Software Documentation

Full functional and technical description of the software, with instructions for set-up, configuration, operation and troubleshooting.

5.3.24. Central Domain Documentation Acceptance Report

Define and apply acceptance process for Central Domain Documentation. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Technical Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Quality Consultant", one person with the profile "Quality Consultant", one person with the profile "Senior Analyst", one person with the profile "Analyst Programmer", one person with the profile "System Administrator", one person with the profile "Senior IT Lawyer" and one person with the profile "IT Operations Manager".

5.3.24.1. User, Installation, Operational, Maintenance, System and Management Documentation

Complete set of Documentation of the Central domain.

5.4. A-Services Project Phase 3: Deliverables related to Migration, Integration and Support

The development deliverables of phase 2 may have to be updated during phase 3. In that case the general rules as set out in Section 3.1.1 "Assignment of A-Services apply.

5.4.1. IT Services Management Plan Acceptance Report

Define and apply acceptance process for IT Services Management Plan. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Technical Consultant", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant", one person with the profile "Information Systems End User Support Specialist", one person with the profile "Senior IT Lawyer" and one person with the profile "IT Operations Manager".


5.4.1.1. IT Services Management Plan

The successful contractor must provide a plan for the IT Service Management after the operational launch.

5.4.2. Migration Manual Acceptance Report (SIS II)

5.4.2.1. Migration manual (SIS II)

Describing the detailed approach for the migration, the transfer of existing Users from an existing system to the new system.

5.4.3. Integration Manual Acceptance Report (VIS)

Define and apply acceptance process for Migration Manual and Integration Manual. Ensure coherence with purpose, completeness, adequacy of level of detail, consistency and formal aspects. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Technical Consultant Biometrics", one person with the profile "Senior Analyst", one person with the profile "Quality Consultant" and one person with the profile "Test Manager".

5.4.3.1. Integration manual (VIS)

Describing the detailed approach for the integration of existing Users from an existing system to the new system.

5.4.4. Migration Completion Acceptance Report (SIS II)

Define and apply process for service monitoring. Ensure proper completion of migration and integration. Complete service delivery evaluation.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Senior Analyst", one person with the profile "Senior IT Lawyer" and one person with the profile "Test Manager".

5.4.4.1. Migration

Transfer of existing Users from an existing system to the new system.

5.4.5. Integration Completion Acceptance Report (VIS)

Define and apply process for service monitoring. Ensure proper completion of migration and integration. Complete service delivery evaluation.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile


"Technical Consultant", one person with the profile "Quality Consultant", one person with the profile "Senior Analyst", one person with the profile "Senior IT Lawyer" and one person with the profile "Test Manager".

5.4.5.1. Integration

Integration of existing Users from an existing system to the new system.

5.4.6. Final System Acceptance Report

Define and apply acceptance at system level. Ensure completion of the acceptance tests. Complete Acceptance Report.

For the execution of this Support Deliverable, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Technical Consultant", one person with the profile "Senior Analyst", one person with the profile "Technical Consultant Biometrics", one person with the profile "Quality Consultant" and one person with the profile "Senior IT Lawyer".

5.4.6.1. Final System Acceptance

Final delivery of all environments and all NIs. Delivery and deployment (including build & installation scripts) of complete Central Unit and Back-up Central Unit (including all environments) on their respective sites and delivery and deployment of all National Interface and Back-up National Interface (as relevant) in all Users premises.

Final System Acceptance shall only be given one each System has been operational vis-à-vis all Relevant Users without Issues arising for a period of four consecutive months after Provisional System Acceptance.

5.5. B-Service Deliverables

5.5.1. Deliverables

B-Services are any services other than A-Services, which the Support Contractor has to carry out in relation to the development and/or operation of large-scale systems such as the development projects or other systems. Since the B-Services will be ordered on a case-by-case basis in response to concrete needs of the Commission services at a given moment, the subject of these deliverables cannot yet be defined. However, as an example, the subject of B-Services could include (non-exhaustive list):

• Drafting of project planning and budgetary planning;

• Feasibility studies (e.g. on additional functionalities or the impact of planned change requests);

• Technical evaluation of system elements;


• Assessment of functionalities of operational systems in the Member States;

• Pilot projects (e.g. to test policy ideas in a specific field);

• Presentations, workshops, documentation.

• Expert advice on defining tasks and profiles, and advising on market prices for these items.

• Legal support, including legal expertise in national application of EU legislation in the field of Home Affairs.

• Training services

• Supply of Technical Support personnel

• Supply and support of user software kits.

• Verifying the competency transfer.

5.5.2. Preparation of operational management of new systems

As set out in the SIS II and VIS legal basis, the SIS II and VIS will be operated in Strasbourg/France (CU) and in Sankt Johann im Pongau/Austria (BCU). For the smooth transition from the development phase to the operational mode the operational management of the systems should be planned in detail. This transition will include a competency transfer (comprising training, on-the-job training, shadowing and coaching) to be delivered by the SIS II and VIS MDC to the SMO/SOO. The BMS will be integrated in the first instance to the VIS and is being developed by a separate main development contractor to that for SIS II and VIS.

The Support Contractor will be required to provide the following services for operational management:

Gap Analysis assessment and recommendations

The Support Contractor will be required to assess preparations made prior to the date of contract signature, identifying any gaps that could hamper a smooth transition to effective and efficient operational management. The Support Contractor will be required to carry out a gap analysis identifying operational management issues arising from the separate MDCs and making recommendations where appropriate.

Operational Management Structure

Concerning the flexibility of the operational management structure with regard to the addition of new systems the Support Contractor will be required to analyse the structures proposed for operational management and to make recommendations that take into account the need to maximise flexibility and adaptability.

Gap Analysis assessment of the existing operation system

The Support Contractor will be required to analyse the operation and propose recommendations where appropriate.

Preparation of handover of operational management to Agency


By 2012 at the latest a management authority in the form of an agency will be established to manage SIS II and VIS, and possibly other large-scale IT systems such as EURODAC II. The Support Contractor may be required to provide expert advice and recommendations covering all aspects of transfer of operational management to an agency.

As preparation of operational management is ongoing at the time of writing, these services will be delivered based on separate specific contracts, based on the list of profiles and person/day rates provided by the tenderer.

6. EVALUATION OF THE SUPPORT CONTRACTOR'S PERFORMANCE

6.1.1. Continuous evaluation of the Support Contractor’s performance

Continuous evaluation aims at providing an objective basis for the Commission to express satisfaction (or dissatisfaction) with the services provided by the Support Contractor, namely but not exclusively in view of the Commission’s discretion to provide for a renewal of the Contract.

During periods of one year each, the Support Contractor’s performance will be continuously assessed by the application of defined performance criteria and giving a performance score (maximum 100 points/year). The result of the overall score will have an impact on the Commission’s discretionary decision to ask the Support Contractor for certain improvement measures and/or to provide for a renewal of the Contract.

6.1.1.1. Performance Criteria

The Support Contractor’s performance regarding the Support Deliverables will be evaluated by the Commission services on three criteria:

• Timeliness (maximum 20 points): Were the Support Deliverables produced by the agreed deadline?

• Project execution (maximum 20 points): Did the Support Contractor follow a clear and transparent management process for completion of the Deliverables? This refers to: ease of communication with the Support Contractor, reliability of the Support Contractor’s team members, structure and quality of the progress reports.

• Quality and demonstrated competence (maximum 60 points): Did the Support Contractor carry out quality assurance function to measure if the MDC's Deliverable is appropriate? Did the Support Contractor proactively contribute to identify potential problems and solutions? Could the Support Deliverable be accepted at an early step of the Review Cycle?


6.1.1.2. Performance score

Using those three dimensions, the Support Contractor’s performance on an individual deliverable will be marked using the following scale:

• Unsatisfactory: Performance score below 45 out of 100 points. Support Contractor does not deliver the expected support. There is frequent misunderstanding on what needs to be done or how.

• Satisfactory: Performance score comprised between 46 and 65 out of 100 points. Support Contractor ensures minimum compliance with its contractual obligations. Support Contractor needs however to be regularly reminded about the required proactive approach.

• Good: Performance score comprised between 66 and 85 out of 100 points. Support Contractor meets requirements and does not need to be reminded of them.

• Outstanding: Performance score exceeds 85 out of 100 points. Quality of the results produced exceeds requirements.

6.1.1.3. Measures and Rewards

Performance score below 45 points: The Support Contractor will be required to apply urgent improvement measures. If nonetheless the Support Contractor’s performance remains unsatisfactory, the Commission can apply the measures and instruments as laid down in Annex 12: Framework Contract.

If the performance scores are not higher than satisfactory, the Support Contractor will be required to apply improvement measures where necessary.

A good or even outstanding performance score will have a (very) positive impact on the Commission’s discretionary decision as to whether to proceed to a renewal the Contract for the following year.