Directorate B : Immigration, Asylum and Borders Unit B3 ... · Currently, DG JLS is in charge of...

______________________________________________________________________________________________________ Call for Tender JLS-B3-2007-05, Tender Specifications, Part 2 – Technical Specifications 071116

COMMISSION OF THE EUROPEAN COMMUNITIES DIRECTORATE-GENERAL JUSTICE, FREEDOM AND SECURITY Directorate B : Immigration, Asylum and Borders Unit B3 : Large-scale IT systems

Call for Tender

(Article 91 (1) (b) Financial Regulation, Article 122 (2) paragraph 2 Implementation Rules)

JLS-B3-2007-05

“Quality Assurance”

Tender Specifications

Part 2 – Technical Specifications

______________________________________________________________________________________________________ Call for Tender JLS-B3-2007-05, Tender Specifications, Part 2 – Technical Specifications - 2 -

Table of Contents

1. Introduction.......................................................................................................................5

1.1. Context ......................................................................................................................5 1.1.1. Schengen Information System ...........................................................................5 1.1.2. Visa Information System ...................................................................................6 1.1.3. Eurodac ..............................................................................................................7 1.1.4. Eurodac Plus ......................................................................................................8 1.1.5. Biometric Matching System BMS-1: BMS-VIS ...............................................8 1.1.6. Biometric Matching System BMS-2: BMS-SIS II ............................................8 1.1.7. Biometric Matching System BMS-3: Eurodac II...............................................8 1.1.8. Biometric Matching System BMS-4: CCAFIS .................................................9 1.1.9. Interconnection SIS II-VIS ................................................................................9 1.1.10. Replacement of SISNET..................................................................................10 1.1.11. Entry-exit system - Registered traveller programme .......................................10 1.1.12. European Register of Convicted Persons (ERCP) ...........................................11

1.2. Contractual context ...............................................................................................12 1.2.1. SIS II -VIS development contract....................................................................12 1.2.2. BMS development contract..............................................................................12 1.2.3. Network development contract ........................................................................12 1.2.4. Project Support Office contract .......................................................................13

2. Project Development working methods..........................................................................13

2.1. Project development methodologies.....................................................................13

2.2. Architecture of JLS projects.................................................................................15

2.3. Data content............................................................................................................15

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

3. Assignment of Deliverables ............................................................................................18

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

4. Acceptance of Main Development Services ...................................................................23

4.1. Synoptic overview of Support Deliverables.........................................................23

5. Support Service Deliverables ..........................................................................................24

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

5.2. A-services Project Phase 1: Detailed design Deliverables ..................................25 5.2.1. Master Project Plan Acceptance Report ..........................................................25 5.2.2. Master Project Schedule Acceptance Report...................................................25 5.2.3. Draft Acceptance Plan Acceptance Report......................................................25 5.2.4. Risk Management Plan Acceptance Report.....................................................26


5.2.5. Quality Assurance Plan Acceptance Report ....................................................26 5.2.6. Risk Analysis Acceptance Report....................................................................26 5.2.7. Protection Profile Acceptance Report..............................................................27 5.2.8. Security Target Acceptance Report .................................................................27 5.2.9. System-Specific Security Requirement Statement (SSRS) Report .................27 5.2.10. Security Plan Acceptance Report.....................................................................28 5.2.11. Change Management Plan Acceptance Report................................................28 5.2.12. Configuration Management Plan Acceptance Report......................................28 5.2.13. Helpdesk Plan and Helpdesk SLA Acceptance Report ...................................29 5.2.14. Business Continuity Acceptance Report, Supervision of Training and Testing,

and Acceptance Report of Testing Report .......................................................29 5.2.15. Support Plan Acceptance Report .....................................................................29 5.2.16. Training Plan Acceptance Report ....................................................................30 5.2.17. Interface Control Document Acceptance Report .............................................30 5.2.18. Detailed Specifications Acceptance Report.....................................................30 5.2.19. Migration Plan Acceptance Report..................................................................31 5.2.20. Test Plan Acceptance Report ...........................................................................31 5.2.21. Integration Plan Acceptance Report ................................................................31

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

5.3.1. Updated Master Project Plan Acceptance Report............................................32 5.3.2. Updated Quality Assurance Plan Acceptance Report......................................32 5.3.3. Updated Interface Control Document Acceptance Report ..............................32 5.3.4. Updated Technical Detailed Technical Specifications Acceptance Report.....33 5.3.5. Updated Functional Detailed Technical Specifications Acceptance Report ...33 5.3.6. Hardware Acceptance Report ..........................................................................33 5.3.7. Acceptance Report on Hardware Documentation, Commercial Software

Documentation and Configuration and Installation Documents......................35 5.3.8. Network Installation Quality Assurance..........................................................35 5.3.9. Functional Technical Design Description Acceptance Report ........................35 5.3.10. Non-functional Technical Design Description Acceptance Report.................36 5.3.11. Build Report, Code Review Report and Factory Acceptance Test Report

Acceptance Report ...........................................................................................36 5.3.12. System Development until System Solution Tests Acceptance Report...........37 5.3.13. Software Installation and Configuration Acceptance Report ..........................38 5.3.14. Environment Set-up Acceptance Report..........................................................38 5.3.15. Business Continuity Planning Acceptance Report ..........................................39 5.3.16. Supervision of Execution of System Solution Tests........................................40 5.3.17. User Compliance Tests Acceptance Report.....................................................40 5.3.18. Site Acceptance Test Report on Test Components, Acceptance Report on

Documentation and Acceptance Report on Factory Testing Report ...............40 5.3.19. Supervision of Execution of Operational System Tests ..................................41 5.3.20. Supervision of Execution of Provisional System Acceptance Tests ...............42 5.3.21. Commercial Software Documentation Acceptance Report .............................42 5.3.22. Custom-built Software Documentation Acceptance Report............................43 5.3.23. Central Domain Documentation Acceptance Report.......................................43

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

5.4.1. IT Services Management Plan Acceptance Report..........................................44 5.4.2. Migration Manual Acceptance Report.............................................................44 5.4.3. Migration Completion Acceptance Report ......................................................44 5.4.4. Final System Acceptance Report .....................................................................45


5.5. B-Service deliverables............................................................................................45 5.5.1. Deliverables .....................................................................................................45 5.5.2. Preparation of operational management of new systems.................................46

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


1. INTRODUCTION

Unit B3 of the Directorate-General Justice, Freedom and Security of the European Commission (DG JLS) is in charge of large-scale IT systems in the field of European Justice, Freedom and Security. In the past DG JLS 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 JLS 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 JLS 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 JLS. 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.

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 VIS is planned to be available in the first half of 2009.

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.

1.1.4. Eurodac Plus

Until the development of Eurodac II, hardware upgrades are foreseen to increase the system capacity and to allow for the increased use of the system. This upgrade project is named “Eurodac Plus”. It is likely that the deliverables for Eurodac Plus will involve only B-services.

In 2008 a call for tender for the operational management in Luxembourg and Brussels until 2012 is also foreseen.

1.1.5. 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 to be implemented and as such will implement the generic BMS infrastructure on which the other scenarios could build their applications specific. The BMS/VIS is a back-end to the VIS system and does not have any direct communication with users. The Interface, between Central VIS (C-VIS) and National VIS (N-VIS), Control Document (VIS ICD) will be re-drafted by the VIS Main Development Contractor. In addition, the BMS-VIS project team needs to finalise or update a number of deliverables. These updates need to be integrated into the VIS project deliverables to constitute one single set of specifications. This project started in Dec. 2006 and will finish when VIS goes live.

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

The SIS II system without automatic biometric identification functionalities has to be operational by end 2008 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 has not yet started. It is expected to start mid-2009.

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

This project started in Dec. 2006 but was suspended. It will be re-started around 2009, once the new legislation has been adopted.

1.1.8. Biometric Matching System BMS-4: CCAFIS

The CCAFIS (Central Criminal Automated Fingerprint Identification System) intends to develop and implement the biometric matching transactions, infrastructure and application logic for a criminal matching engine capable of using ‘latents’ (partial fingerprint images, left at a crime scene). This project has not yet started. It is likely to start end-2008 with a limited number of Member States as a pilot project, without a backup central unit.

1.1.9. Interconnection SIS II-VIS

To be able to check a visa in the VIS, computer terminals (typically at the border) must be connected to the Central VIS. In most Member States, terminals at the border are already connected with the national SIS system via a national SIS communication network. For the further transmission of messages between this SIS network and the central VIS there are two possible routes:

(1) Transmission via a national connection: the national SIS communication network needs to be connected to the national VIS network. A message would go e.g. from the border via the SIS and VIS national networks to the VIS national system, to arrive in the central VIS;

(2) Transmission via a central connection: the central SIS II needs to be connected with the central VIS. In this case a message would go e.g. from the border via the national SIS network to the central SIS II and from there to the central VIS.

A similar routing choice exists for Member States which plan to carry out the check on the alert for the purpose of refusing entry in the central SIS from their national VIS system.

Currently, only the transmission via a national connection exists. However, the Council’s Article 36 Committee concluded in October 2005 that connectivity between the SIS II and VIS should be established centrally after the systems become operational.

It should be noted that there are legal bases mandating the Commission to develop both the VIS and the SIS II. However, a connection between VIS and


SIS II is not foreseen in the legal instruments and therefore amendments to the legal bases are required.

1.1.10. Replacement of SISNET

The SIS 1+, SIRENE and VISION systems operate at present on the SISNET communications network. The current contract for the SISNET network services is managed on behalf of the Member States by the Deputy Secretary-General of the Council and is funded jointly by the Member States (in accordance with the Schengen Convention and a Council Decision establishing a regulation for this purpose). This SISNET contract is due to expire on 13 November 2008.

The Council Secretariat General has indicated that the only means of continuing to use the current SISNET is to launch a call for tender for a new contract as it is not possible to further prolong the existing contract. Therefore, action must be taken to guarantee a network service for the SIS 1+ and VISION between 13 November 2008 and the date of the SIS II that will replace SIS 1+, becoming operational (17 December 2008).

Arising from the agreement at the JHA Council on 15 February 2007, the Council has decided that the Deputy Secretary-General of the Council should again act on behalf of the relevant Member States to issue a call for tenders to conclude a new SISNET contract in order to ensure that the service will be available after November 2008.

However, given the Council’s analysis of the risks associated with a procurement process, the Council has decided that it must have available an alternative network solution for SIS and related SIRENE exchange. The preferred solution of the Member States for an alternative is the s-TESTA network. The Council has, therefore, invited the Commission to make proposals as soon as possible to provide for the possibility of migrating the SIS 1+ onto the s-TESTA network.

At the latest in December 2007, the Council will assess progress made on the basis of reports of the General Secretariat of the Council and the Commission.

1.1.11. 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. 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 will identify and develop 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, to be launched once the interim report of the preliminary study is accepted, is 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.

October 2007 is scheduled for the final report of the preliminary study. The technical feasibility study is expected to conclude in November 2007 so that the Commission’s impact assessment can be prepared and presented to Member States by the end of 2007.

1.1.12. European Register of Convicted Persons (ERCP)

The ERCP is a project that intends to interconnect national criminal records within EU. It is one of the actions foreseen by the Criminal Justice Programme, adopted by Council Decision N° 2007/126/JHA on 12 February 2007, which includes the promotion of judicial cooperation, the promotion of compatibility rules applicable in the Member States and improvement to the exchange of information.

The exchange of information on convictions in the EU will be facilitated in particular through the creation of a computerised system of information. Co-funding will be available for improvements to national criminal records systems so that they can successfully exchange information electronically with criminal records of other Member States.

Several feasibility studies have been carried out in recent years, including an analysis of the state-of-play in Member States with regard to their national criminal records systems. In that respect, a 2007 Call for proposals for interconnection of criminal records has been adopted by the Commission on 10


April 2007 to implement Council Decision 2007/126/JHA. Update and Member State proposals are due on 2 July 2007.

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 Support Office contract

In order to improve communication and the follow-up of the delivery process, the Project Support Office (PSO) assists the Commission to improve the organisation and the development monitoring of the projects. To this end the Project Support Office (PSO) 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 to actions and active risk and issue-management.

In this framework, the PSO 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 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's 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's 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.

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_busm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_busm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_req.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_req.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_and.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_and.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_impl.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_impl.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_test.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_test.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_dep.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_dep.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_cm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_cm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_mgm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_mgm.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_env.htm

http://www.cc.cec/CITnet/methodo/process/workflow/ovu_env.htm

http://www.cc.cec/CITnet/methodo/process/itrwkfls/iwf_lit.htm

http://www.cc.cec/CITnet/methodo/process/itrwkfls/iwf_iii.htm

http://www.cc.cec/CITnet/methodo/process/itrwkfls/iwf_iie.htm

http://www.cc.cec/CITnet/methodo/process/itrwkfls/iwf_lic.htm

http://www.cc.cec/CITnet/methodo/process/workflow/manageme/co_phase.htm


2.2. Architecture of JLS projects

The basic architecture of most JLS 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 Project Management Board (PMB). The role of the PMB 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 PMB. PMB 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 PMB.

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 – System Development 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 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

The Commission will assign the A-Services using Specific Contracts. Details are laid down in the Tender Specifications, Part 4 - Contract. 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.

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 the Tender Specifications, Part 3 - Profiles and requirements for IT personnel. 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 JLS/B/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 progress report. Tracking of resources used, costs and time will be included in the progress report. Indications on deviations from the original planning must also be presented in the progress reports. The report submitted in preparation to these meetings should arrive two working days before the agreed meeting date.

Monthly progress report

At least once a month a project status report will be presented and discussed at the Commission premises in Brussels.

The monthly progress report on the execution of the A- and B-Services must be sent to the Commission five working days prior to the meeting date and must deal with the following:

(1) The tasks originally planned during the reported month;

(2) Progress during the month: for each task mentioned in the list of planned tasks, a short description of input to progress is given:

• Description of activities carried out; • Description of results achieved; • Comments on ongoing tasks when appropriate; • Justification of any deviation from the originally planned task.

(3) The Deliverable Tracking Matrix showing the:

• Planned delivery dates; • Foreseen delivery dates; • Actual delivery dates for review and for acceptance; • Justification of any differences between planned and actual dates.

(4) Problem and issues: problems and/or issues met during execution. Overruns of tasks and/or difficulties for meeting agreed target end-dates must be explained here.

(5) Task planned for the next month: an extract of the project time plan, listing all the tasks that are planned to start or to be continued during next month.

(6) Request for action: the requests for action must be listed with their reference number and title, to which short comments can be added as relevant.

(7) Updated Risk Management procedures.

(8) Quality management: report on foreseen quality assurance procedures, how effectively they were applied and the benefits or results achieved.

(9) Overview of decisions taken during the reported month.


4. ACCEPTANCE OF MAIN DEVELOPMENT SERVICES

4.1. Synoptic overview of Support Deliverables

Each deliverable produced by the Main Development Contractor goes through an acceptance procedure, which varies depending on the type of deliverable.

The final schedule for system development is defined by the Project Master Plan which is the first deliverable after signature of the contract. The Support Contractor has to adapt its planning for the delivery of the A-Services to the planning of the MDC. The MDC will inform the Commission at least 10 working days in advance of the availability of a deliverable to be assessed. The Commission will forward this information to the Support Contractor. If the deliverable is a document, the Commission will send it to the Support Contractor. For Hardware and Installation acceptance and Software Acceptance (developed or standard), the Commission will inform the Support Contractor of the location where the acceptance will occur. For monitoring of service delivery, acceptance can happen either at the place where the services are designed or at the place where the services are carried out.

The Support Contractor 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 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 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. In such a case, the Support Contractor will have to re-assess the Deliverable and produce another acceptance report. In principle, the assessment of a revised Deliverable will be repeated until the Deliverable is acceptable in terms of the acceptance rules laid down in the main development contract.

Thus, the Support Contractor, when submitting the tender, will have to take into account the risk of multiple assessment of a (revised) Deliverable and all additional costs related to a proactive assessment approach. The fixed price offered per Support Deliverable has to cover both aspects irrevocably.

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, Part 4 – 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, Part 4 – Framework Contract, Annex 3 - Draft Specific Contract.


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

5.2.1. Master Project Plan Acceptance Report

Define and apply acceptance process for 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.2.1.1. Master Project Plan

Provides an overall description of the project, including project team, project planning and delivery schedule, methodology and all applicable procedures. Delivery dates and starting dates refer to the project master schedule.

5.2.2. Master Project Schedule Acceptance Report

Define and apply acceptance process for Master Project Schedule. 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" and one person with the profile "Senior Quality Consultant".

5.2.2.1. Master Project Schedule

The summary schedule for the project, depicting overall project phasing and all major interfaces, contractual milestones, and project elements.

5.2.3. Draft Acceptance Plan Acceptance Report

Define and apply acceptance process for Draft Acceptance 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, the Support Contractor shall provide at least one person with the profile "Senior Quality Consultant", one person with the profile "Senior IT Lawyer" and one person with the profile "Technical Consultant".

5.2.3.1. Draft Acceptance Plan

Validation specifications and procedures for all deliverables. The Acceptance Plan describes how the customer will evaluate the deliverable artifacts from a project to determine if they meet a predefined set of acceptance criteria. It details these acceptance criteria, and identifies the product acceptance tasks (including identification of the test cases that need to be developed) that will be carried out, and


assigned responsibilities and required resources. On a smaller scale project, this plan may be embedded within the Software Development Plan.

5.2.4. Risk Management Plan Acceptance Report

Define and apply acceptance process for Risk Management 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 Analyst", one person with the profile "Security Specialist" and one person with the profile "Quality Consultant".

5.2.4.1. Risk management plan

Identifies all known risks, assess their probability of occurrence and possible impact on the project. The Risk Management Plan details how to manage the risks associated with a project. It details the risk management tasks that will be carried out, assigned responsibilities, and any additional resources required for the risk management activity. On a smaller scale project, this plan may be embedded within the Software Development Plan.

5.2.5. Quality Assurance Plan Acceptance Report

Define and apply acceptance process for 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.2.5.1. Quality Assurance Plan

The Quality Assurance Plan is an artefact that provides a clear view of how product, artefact, and process quality are to be assured. It contains the Review and Audit Plan, and references a number of other artifacts developed during the Inception phase. It is maintained throughout the project. It documents the project’s approach to planning and managing every aspect of quality throughout the project lifecycle.

5.2.6. Risk Analysis Acceptance Report

Define and apply acceptance process for Risk Analysis. 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 "Security Specialist" and one person with the profile "Quality Consultant".


5.2.6.1. Risk analysis

A risk analysis (using a recognised standard method like BSI IT BPM) about confidentiality, Integrity, availability etc must be performed. The result must include a document in a recognised standard format like a protection profile as described in the ISO 15408 and called hereafter “Protection Profile” to facilitate the reading.

5.2.7. 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.7.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.8. 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.8.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.9. System-Specific Security Requirement Statement (SSRS) Report

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



5.2.9.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.10. 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.10.1. Security Plan

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

5.2.11. Change Management Plan Acceptance Report

Define and apply acceptance process for Change Management 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", one person with the profile "Senior IT Lawyer" and one person with the profile "Quality Consultant".

5.2.11.1. Change Management Plan

Describes the exact procedure to follow in the case of changes to the project. Change Management is the process for handling the action items, issues and requested changes related to the solution delivery process.

5.2.12. Configuration Management Plan Acceptance Report

Define and apply acceptance process for Configuration Management 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 "Technical Consultant" and one person with the profile "Quality Consultant".


5.2.12.1. Configuration Management Plan

The Configuration Management (CM) Plan describes all Configuration and Change Control Management (CCM) activities the MDC will perform during the course of the product or project lifecycle. It details the schedule of activities, the assigned responsibilities, and the required resources, including staff, tools, and computer facilities.

5.2.13. Helpdesk Plan and Helpdesk SLA Acceptance Report

Define and apply acceptance process for Helpdesk Plan and Helpdesk SLA. Ensure fit to purpose, completeness, and 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 "Information System End User Support Specialist" and one person with the profile "Quality Consultant".

5.2.13.1. Helpdesk Plan & Helpdesk SLA

Comprehensive plan for helpdesk, including: high level SLA, resources, time-schedule and procedures.

5.2.14. Business Continuity Acceptance Report, Supervision of Training and Testing, and Acceptance Report of Testing Report

Quality Assurance activities involved in setting up BCP for the Business Continuity Activities.

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 "Security Specialist", one person with the profile "Senior Analyst" and one person with the profile "Quality Consultant".

5.2.14.1. Business Continuity Planning – Operational

• BCP, including set-up of continuity procedures • Training • Testing • Testing report

Delivery of a comprehensive set of plans, according to the agreed methodology, to ensure that the system can be organised and operated in such a way that the required level of service is met. Includes the Contingency Plan.

5.2.15. Support Plan Acceptance Report

Define and apply acceptance process for Support 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, the Support Contractor shall provide at least one person with the profile "Senior Analyst", one person with the profile "Information Systems End User Support Specialist", one person with the profile "Information Systems Trainer" and one person with the profile "Quality Consultant".

5.2.15.1. Support Plan

Comprehensive plan for support activities, including resources, time-schedule and procedures.

5.2.16. Training Plan Acceptance Report

Define and apply acceptance process for Training 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, the Support Contractor shall provide at least one person with the profile "Senior Analyst", one person with the profile "Information Systems End User Support Specialist", one person with the profile "Information Systems Trainer" and one person with the profile "Quality Consultant".

5.2.16.1. Training Plan

Comprehensive plan for training, including resources, time-schedule and procedures.

5.2.17. Interface Control Document Acceptance Report

Define and apply acceptance process for 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 "Analyst Programmer", one person with the profile "Security Specialist", one person with the profile "User Requirements Analyst" and one person with the profile "Quality Consultant".

5.2.17.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.2.18. Detailed Specifications Acceptance Report

Define and apply acceptance process for Detailed Specifications. Ensure coherence with purpose, completeness, and 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 "Analyst Programmer", one person with the profile "Security Specialist", one person with the profile "User Requirements Analyst" and one person with the profile "Quality Consultant".

5.2.18.1. Detailed specifications (DTS)

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

5.2.19. Migration Plan Acceptance Report

Define and apply acceptance process for Migration 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, 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 Telecommunication" and one person with the profile "Technical Consultant Biometrics".

5.2.19.1. Migration plan

Comprehensive plan for User migration, including procedures.

5.2.20. Test Plan Acceptance Report

Define and apply acceptance process for Test 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 Biometrics", one person with the profile "Technical Consultant Telecommunication", one person with the profile "Senior Analyst", one person with the profile "User Requirements Analyst" and one person with the profile "Senior Quality Consultant".

5.2.20.1. Test plan

Comprehensive test plan, which includes a test strategy, test plans and validation specifications for all components of the architecture.

5.2.21. 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".


5.2.21.1. Integration Plan

Comprehensive plan for User integration specifications, including procedures.

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. 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. 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. 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.6.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.7. 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.7.1. Hardware Documentation

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

5.3.8. 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.8.1. MS network roll-out

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

5.3.9. Functional Technical 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.9.1. Functional Technical Design Description

Document describing the Functional Technical Design.

5.3.10. Non-functional Technical 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.10.1. Non-functional Technical Design Description

Document describing the Non- functional Technical Design.

5.3.11. Build Report, Code Review Report and Factory Acceptance Test Report Acceptance Report

• Acceptance report on the build-report on progress of the development activities (frequency in accordance with the build cycles)

• Code review report after every successful build • Review and Acceptance report on the intermediate test reports after every successful

build • Acceptance report on the test report on the FAT

The acceptance procedure for deployed software is envisaged as follows:

Factory Acceptance Test (FAT). This is a series of tests (to be agreed upon beforehand) on a system that does not necessarily have the same characteristics as the final production system. The purpose of these tests is to ascertain that the required and specified functionalities are present, and that they function as specified. It is understood that such tests will be executed following a previously agreed upon test plan produced by MDC, and will be evaluated against pre-determined criteria for success and failure. The typical setting for the factory test would be against simulated client systems, and/or against a benchmark system. The factory acceptance tests will be carried out by the MDC under the supervision of the Commission assisted by the Support Contractor.

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 "Quality Consultant", one person with the profile "Senior Analyst" and one person with the profile "Analyst Programmer".


5.3.11.1. System development until FAT

A build-report on progress of the development activities (frequency in accordance with the build cycles).

The provision of the necessary software components (including 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).

After every successful build make the code that is ready for code-reviews available to the COM at contractor premises, 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, amend the code that was found not to be compliant to the QAP guidelines.

The software components are to be delivered as ready for the FAT.

The Factory Acceptance Tests (FAT) to test the developed software in factory before its installation on site and demonstrate that the developed software covers the major required functionalities correctly and completely and that it shows a sufficient functional stability at factory site before submitting the software to System Solution Testing (SST).

A test report on the FAT will to be provided, stating the results of the FAT.

5.3.12. System development until System Solution Tests Acceptance Report

Define and apply acceptance process for the System Development until SST. 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 "Analyst Programmer".

5.3.12.1. System development until System Solution Tests

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

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 "Software 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 System Solution Tests

• 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 SST 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. System Solution Tests

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 • Acceptance report on the Factory Testing report (limited to non-COTS components)

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. Supervision of execution of Operational System Tests

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.19.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.20. 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.20.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.21. 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.21.1. Commercial Software Documentation

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


5.3.22. 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.22.1. Custom-built Software Documentation

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

5.3.23. 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.23.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 Project Officer will decide to submit or not the updated deliverable to the Support Contractor for formal acceptance. In practice this will be asked 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 2 deliverable. In case a deliverable is updated several times, the additional acceptance reports will be ordered on the basis of the estimate provided.


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

Define and apply acceptance process for Migration 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.2.1. Migration manual

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

5.4.3. Migration Completion Acceptance Report

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.3.1. Migration

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


5.4.4. 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.4.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 Justice, Freedom and Security. • 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): 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 the Tender Specifications, Part 4 – 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.

Directorate B : Immigration, Asylum and Borders Unit B3 ... · Currently, DG JLS is in charge of...

Documents

Transcript of Directorate B : Immigration, Asylum and Borders Unit B3 ... · Currently, DG JLS is in charge of...