EUROPEAN COMMISSION DIRECTORATE-GENERAL INFORMATICS Information systems Directorate European Commission Immigration Portal Development Case Date: 08/06/2007 Version: 1.0 Authors: Revised by: Approved by: Public: Reference Number: Commission européenne, B-1049 Bruxelles / Europese Commissie, B-1049 Brussel - Belgium. Telephone: (32-2) 299 11 11. Office: IMCO 05/21. Telephone: direct line (32-2) 298.65.32. Fax: (32-2) 296.76.70. Commission européenne, L-2920 Luxembourg. Telephone: (352) 43 01-1.
TABLE OF CONTENTS 1. INTRODUCTION... 4 1.1. Scope... 4 1.2. Overview... 4 2. DEVELOPMENT CASE IMPLEMENTATION GUIDE... 4 3. IMMIGRATION PORTAL DEVELOPMENT CASE... 4 3.1. Standards / Guidelines... 4 3.2. Tags... 4 3.3. Artefact status / Formal deliveries... 7 3.4. Lifecycle Model / Lifecycle Objectives Milestones... 7 3.5. Reports... 7 3.5.1. Status Reports... 7 3.5.2. Lifecycle Milestone Review Records... 7 4. IMMIGRATION PORTAL MAINTENANCE CASE... 8 4.1. Maintenance Development Case Explanation... 10 RUP@EC Development Case - Page 2 / 10
Document History Tender specifications JLS/B4/2007/03 Annex 5 Version Date Comment Modified Pages 1.000 08-06-07 Creation of document RUP@EC Development Case - Page 3 / 10
1. INTRODUCTION 1.1. Scope This document describes the Immigration Portal development case. This development case can only be applied in connection with RUP@EC methodology (explicitly or implicitly). All references to a methodology appearing in this document refer to the RUP@EC methodology. 1.2. Overview Chapter 2 gives some advice in connection with the application of the development case, chapter 3 documents the standard development case and important topics in relation to this, chapter 4 documents a development case for small low risk development projects, and chapter 5 documents an alternative development case for maintenance projects. 2. DEVELOPMENT CASE IMPLEMENTATION GUIDE This development case in RUP@EC serves as a main input to the project manager when planning the project. It suggests the minimum set of artefacts that should be produced by the project, and gives an indication of the timing of the artefact production efforts in the project lifecycle. This development case does not give any suggestions as to how many iterations to put in each phase. 3. IMMIGRATION PORTAL DEVELOPMENT CASE The artefacts to be produced for the immigration project are shown in Table 1. The artefacts are listed in the phase where they should be completed, reviewed and baselined according to the principles laid down in the Quality Assurance Plan and the Configuration Management Plan. 3.1. Standards / Guidelines The first column to the left of the phases, labelled 'Standards/Guides', lists the artefacts provided by either the Commission Enterprise Architecture Framework (CEAF) or as a part of the methodology. These standards and guides therefore are not necessary to be produced by the project, but should nevertheless be considered part of the project (documentation/legal/statutory) framework. 3.2. Tags The development case tables use the following tags: [initial]: An exception to this is when the tag [initial] has been added to the artefact. In these cases the artefact must be produced in the phase, but not to a completed state. The artefact is produced in order to elicit or uncover potential problems and risks to the project, as well as being important input to the project planning especially the iteration-planning. [revised]: RUP@EC Development Case - Page 4 / 10
If the tag [revised] has been added to the artefact the artefact is most likely to undergo a change compared to the baselined version of the artefact from the previous phase. This will be subject to change control. Depending on the formality of the project and other conditions (e.g. fixed price, critical deadlines, etc.) the freedom to revise the documents in question based on experiences gained in the iterative approach may be restricted. RUP@EC Development Case - Page 5 / 10
Standards / Guides Inception Elaboration Construction Transition Business Modelling Requirements Business Glossary Process Glossary Requirements Management Plan Description of the methodology to collect, select, retrieve and update the content of the Site [initial] Vision (incl. Immigration Portal Glossary) Use Case Model [initial] Description of the methodology to collect, select, retrieve and update the content of the Site [Revised] Vision [Revised] Use Case Model [revised] Supplementary Specification Analysis & Design Reference Architecture Software Architecture Document for low risk projects [Initial] Specification of the layout, structure and navigation map of the Web Site [Initial] Use Case Model [revised] Software Architecture Document for low risk projects [Revised] Specification of the layout, structure and navigation map of the Web Site [Initial] Implementation Prototype User Interface Prototype Test Test Management Plan Test Environment Configuration Deployment Data Centre Hosting Guidelines Deployment Model Promotion Strategy, including a logo and name for the Web Site Prototype Implementation elements Developer test Test Evaluation Summaries Deployment Plan Product End User Support Material Implementation elements Release Notes End User Support Material [revised] Configuration & Change Management Configuration Management Plan Project Repository Deployment Unit Project Management Quality Assurance Plan Risk Management Plan Product Acceptance Plan Problem Resolution Plan Business Case Risk List Iteration Assessment Risk List [revised] [revised] Iteration Assessment(s) Risk List [revised] [revised] Iteration Assessment(s) Iteration Assessment(s) Environment Development Case Standard Tools (dev, test, prod) [revised] (dev, test, prod) [revised] (test, prod) [revised] (test, prod) Lifecycle Milestone Reviews Table 1 Development Case overview RUP@EC Development Case - Page 6 / 10
3.3. Artefact status / Formal deliveries Some of the artefacts in the development case serve as means to control the expectations of the project stakeholders and to formalise agreements on what must be produced by the project. Other artefacts are internally oriented and serve as tools to assure quality and to optimise the development process. In the development case table the artefacts that are used to formalise the agreements on what must be produced by the project (i.e. the formal deliveries) have been marked in bold. 3.4. Lifecycle Model / Lifecycle Objectives Milestones At the end of each phase a lifecycle milestone review is conducted as described in the methodology. The artefacts that have been produced in the phase are subject to this review. The lifecycle milestone review serves as a control gate, at which it will be decided by the steering committee to continue the project or in extreme cases to terminate further activities on the project. 3.5. Reports In addition to the artefacts listed in the development case, some reports will be produced by the project as well. Reports reflect the status of the project or extract information about one or more artefacts at a given time. Unlike regular artefacts, reports are not subject to version control; however they may be baselined to provide a historic audit trail of the project over time. As a minimum the project will produce the following reports. 3.5.1. Status Reports Status Reports provide a mechanism for addressing, communicating, and resolving management issues, technical issues, and project risks. Continuous open communication with objective data derived directly from ongoing activities and the evolving product configurations are mandatory in any project. These project snapshots provide the basis for management's attention. While the period may vary, the forcing function needs to capture the project history. The Status Report will be produced at the end of each iteration; it will include the iteration assessment. 3.5.2. Lifecycle Milestone Review Records The Steering Committee will chair a Lifecycle Milestone Review at the conclusion of each phase to determine, following the completion of the final iteration of the phase, whether the project should be allowed to proceed to the next phase. This review marks a point at which management and technical expectations should be resynchronized, but the issues to be considered should relate mainly to the management of the project - major technical issues should have been resolved with the final iteration (of the phase), and in the subsequent Activity: Prepare for Phase Close-Out. A review is held at each of the major milestones: the Lifecycle Objectives Milestone at the end of the Inception Phase the Lifecycle Architecture Milestone at the end of the Elaboration Phase the Initial Operational Capability Milestone at the end of the Construction Phase the Product Release Milestone at the end of the Transition Phase RUP@EC Development Case - Page 7 / 10
4. IMMIGRATION PORTAL MAINTENANCE CASE The objective of the maintenance phase is not to build an entire new information system but rather to extend the existing information system with detailed and controlled changes or to address a specific business need (e.g. a new regulation) in light of the existing information system portfolio. A typical maintenance phase should be performed within a fairly short time frame (between 1 and 3 calendar months). Table shows the development case for maintenance projects that facilitate the required speed, and that takes into account the special circumstances of the maintenance situation. RUP@EC Development Case - Page 8 / 10
Business Modelling Requirements Standards / Guides Inception (< 1 week) Elaboration (1-2 weeks) Construction (3-6 weeks) Transition (< 1 w.) Business Glossary Process Glossary Requirements Management Plan Vision Analysis & Design Reference Architecture Software Architecture Document Use Case Model [revised] Design Model Implementation User Interface Prototype Build Implementation Model Implementation elements Developer test Test Test Management Plan Test Evaluation Summaries Deployment Data Centre Hosting Deployment Model Deployment Plan Guidelines Product Configuration & Change Management Project Management Environment Lifecycle Milestone Reviews Configuration Management Plan Quality Assurance Plan Risk Management Plan Product Acceptance Plan Problem Resolution Plan Development Case Standard Tools Table 2 Maintenance Case overview Project Repository Deployment Unit GovIS Business Case Risk List Iteration Plan Iteration Assessment (dev, test, prod) GovIS [revised] Risk List [revised] [revised] Iteration Assessment(s) [revised] (dev, test, prod) Development Infrastructure Test Infrastructure GovIS [revised] Risk List [revised] [revised] Iteration Assessment(s) [revised] (dev, test, prod) Release Notes End User Support Material GovIS [revised] Iteration Plan Iteration Assessment [revised] (dev, test, prod) Production Infrastructure RUP@EC Development Case - Page 9 / 10
4.1. Maintenance Case Explanation The legend and annotation in Table are the same as for the standard development case. The Standards and Guides are all available to the maintenance development projects as they are for the full scale development projects, so this part of the development case is not affected by the project type. As the business model and system use is presumed to be very well understood in the case of maintenance projects, the activities within business modelling are limited and do not result in any separate artefacts. The results of the business modelling performed will be documented in the vision document only. Even for very short projects, the inception phase should be used to document (i) what is to be produced in the vision document, (ii) the financial impact in the business case (and GovIS) and (iii) how it is to be made in the software development plan whilst giving a thought to (iv) what can go wrong (the risk list). As a general rule, the ambition of the artefacts should be adjusted to the project scope and size. The maintenance type projects will still run in an iterative approach with iteration assessments to collect the lessons learned, and to control a changing base-line. For phases that consist of only one iteration, the iteration assessment can be merged with the lifecycle milestone review. The result of which would be documented in a status report. RUP@EC Development Case - Page 10 / 10