debat project management plan.doc

DEBAT Development of EAST Based Access ToolsProject Management Plan

Contract: 16562/02/I-LGReference: SS/DEBAT/PMPIssue: 1.3Date: 13/11/2003

Prepared by:

Laurent CohenDate:

Checked by:

Josiane DenailhacDate:

Approved by:

Alain LapeyreDate:

DEBAT – Development of EAST Based Access Tools

DEBAT Project Management Plan

Reference : SS/DEBAT/PMP Issue : 1.3 Date : 13/11/2002 Page : i

Document Status Sheet

Document Title DEBAT Project Management PlanDocument Reference Number SS/DEBAT/PMP

Issue Revision Date Reason for change1 3 13/11/2003 Updated with project team changes and CDR deliveries1 2 08/07/2003 Updated for Phase 21 1 31/10/2002 Integration of comments from ESA1 0 15/10/2002 First issue of the PMP for Phase 1 of the project



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : ii

Document Change Records

Document Title DEBAT Project Management PlanDocument Reference Number SS/DEBAT/PMPDocument Issue/Revision Number 1.3

Page Paragraph Reason for change7-9 The project team has changed (paragraph 2.4.2)

44-45 Adding of the new documents delivered during the CDR and the new version updated after the CDR comments


Page Paragraph Reason for change6 The Quality Engineer is now M. Granet27 Removal of Work-Package descriptions sheets to reduce the document size

(only a reference to CS proposal is kept)28-38 Completion of chapters dedicated to Phase 240-41 Update of the documentation tree


Page Paragraph Reason for change64 Mention of the documentation repository set-up on an ESA server.64 Some typo fixed for documents references64 Added: issues 1.1 of the PMP and PAP


Page Paragraph Reason for changeAll First issue



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : iii

Table of contents

DOCUMENT STATUS SHEET........................................................................................................I

DOCUMENT CHANGE RECORDS..............................................................................................II

TABLE OF CONTENTS................................................................................................................III

TABLE OF FIGURES......................................................................................................................V

ACRONYMS AND ABBREVIATIONS........................................................................................VI

APPLICABLE DOCUMENTS....................................................................................................VIII

REFERENCE DOCUMENTS........................................................................................................IX

1. INTRODUCTION..........................................................................................................................1

1.1 PROJECT OVERVIEW.....................................................................................................................11.2 OBJECTIVES OF THE DOCUMENT..................................................................................................11.3 STRUCTURE OF THE DOCUMENT..................................................................................................11.4 EVOLUTION OF THE PROJECT MANAGEMENT PLAN....................................................................2

2. PROJECT ORGANISATION.......................................................................................................3

2.1 PROCESS MODEL..........................................................................................................................32.2 OVERALL PROJECT SCHEDULE AND MILESTONES........................................................................32.3 FACILITIES AND RESOURCES........................................................................................................52.4 PROJECT ORGANISATION CHART..................................................................................................5

2.4.1 First project organisation chart...........................................................................................52.4.2 Second project organisation chart........................................................................................7

2.5 ORGANISATIONAL ROLES AND RESPONSIBILITIES.......................................................................92.5.1 The Project Director.............................................................................................................92.5.2 The Project Manager............................................................................................................92.5.3 The technical manager.......................................................................................................102.5.4 The Experts.........................................................................................................................102.5.5 The Development Team......................................................................................................10

2.6 ORGANISATIONAL BOUNDARIES AND INTERFACES....................................................................112.6.1 Communications with ESRIN.............................................................................................112.6.2 Relation to CNES EAST project.........................................................................................11

3. MONITORING AND CONTROL..............................................................................................13

3.1 MEETING AND REPORTING.........................................................................................................133.1.1 Meetings..............................................................................................................................133.1.2 Reporting............................................................................................................................13

3.2 SCHEDULE REPORTING AND CONTROL......................................................................................143.3 RISK MANAGEMENT AND REGISTER..........................................................................................14

4. LICENSES ISSUES.....................................................................................................................15

4.1 PRINCIPLES OF THE DEBAT DEVELOPMENT AND LICENSE.......................................................15



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : iv

4.2 TERMS OF THE PROPOSED LICENSE............................................................................................16

5. PHASE 1 - ANALYSIS AND STUDIES PHASE......................................................................17

5.1 OBJECTIVES...............................................................................................................................175.2 WORK BREAKDOWN STRUCTURE...............................................................................................185.3 DEVELOPMENT PLAN, WORK LOGIC AND ACTIVITIES................................................................19

5.3.1 Requirements collection and technical analysis.................................................................215.3.2 Implementations..................................................................................................................245.3.3 DEBAT definition................................................................................................................245.3.4 Support to user group.........................................................................................................255.3.5 Promotion...........................................................................................................................26

5.4 SCHEDULE, MEETINGS AND DELIVERIES....................................................................................285.4.1 Schedule..............................................................................................................................285.4.2 Meetings..............................................................................................................................285.4.3 CS Deliveries and Customer Furnished Items....................................................................29

5.5 WORK PACKAGES DESCRIPTION...............................................................................................30

6. PHASE 2 - IMPLEMENTATION PHASE................................................................................31

6.1 OBJECTIVES...............................................................................................................................316.2 WORK BREAKDOWN STRUCTURE...............................................................................................326.3 WORK LOGIC AND ACTIVITIES...................................................................................................33

6.3.1 Software specifications and architectural design...............................................................336.3.2 Implementation, integration and acceptance tests.............................................................356.3.3 Promotion...........................................................................................................................366.3.4 Concept Validation.............................................................................................................376.3.5 Proposals for CCSDS standards updates...........................................................................376.3.6 Demonstration....................................................................................................................376.3.7 Support to user group.........................................................................................................376.3.8 Final presentation...............................................................................................................37

6.4 SCHEDULE, MEETINGS AND DELIVERIES....................................................................................386.4.1 Schedule..............................................................................................................................386.4.2 Meetings..............................................................................................................................386.4.3 CS Deliveries and Customer Furnished Items....................................................................39

6.5 WORK PACKAGES DESCRIPTIONS..............................................................................................41

7. WARRANTY PHASE..................................................................................................................42

7.1 WARRANTY PRINCIPLES............................................................................................................427.2 WARRANTY ACTIVITIES.............................................................................................................42

8. Documentation tree........................................................................................................................43



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : v

Table of figuresFigure 2-1 Major milestones................................................................................................................3Figure 2-2 Overall project schedule and milestones............................................................................4Figure 2-3 Project Organisation chart..................................................................................................5Figure 5-1 Phase 1 Work Breakdown Structure.................................................................................18Figure 5-2 Analysis and studies phase ( phase 1)..............................................................................19Figure 5-3 Requirements collection and technical analysis work logic.............................................21Figure 5-4 Phase 1 interviews methodology......................................................................................22Figure 5-5 DEBAT definition work logic..........................................................................................24Figure 5-6 Detailed schedule of DEBAT Phase 1..............................................................................28Figure 6-1 Outputs of DEBAT phase 1..............................................................................................31Figure 6-2 Phase 2 WBS....................................................................................................................32Figure 6-3 Implementation plan for phase 2......................................................................................33Figure 6-4: Software Specifications & Architectural Design work logic..........................................34Figure 6-5: Implementation, integration & acceptance tests work logic...........................................35Figure 6-6: Detailed design work logic..............................................................................................36



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : vi

Acronyms and abbreviations

ADD Architectural Design DocumentAMS Archive Management SystemAPI Application Program InterfaceAR Acceptance ReviewATP Authorisation To ProceedCA Control AuthorityCAID Control Authority IdentifierCAO Control Authority OfficeCAOS Control Authority Office SystemCDF Common Data FormatCDR Critical Design ReviewCEOS Committee on Earth Observation ScienceCFI Customer Furnished ItemCNES Centre National D’Etudes Spatiales (French Space Agency)COTS Commercial Off The ShelfCCSDS Consultative Committee for Space Data SystemsDEAL Display EAST Access ListDEBAT Development of EAST Based Access ToolsDEBAT-DM DEBAT Data ModellerDEBAT-DPE DEBAT Data Producer & EditorDEBAT-DEQ DEBAT Data Extractor & QueryingDEBAT-PPT DEBAT Post Processing ToolsDEBAT-UT DEBAT UtilitiesDDR Data Description RecordDDU Data Description UnitDDF Design Definition FileDED Data Entity DictionaryDEDSL Data Entity Description Specification LanguageDEW Data Extractor WizardDIP Dissemination Information PackageDJF Design Justification FileDUW Data Update WizardDW DEBAT WorkshopEAST Enhanced ADA Sub SeTECSS European Cooperation for Space StandardizationEO Earth ObservationESA European Space AgencyESRIN European Space Research INstituteERS European Remote Sensing satelliteESA European Space AgencyEVA ESA Virtual ArchiveFA Final AcceptanceFAQ Frequently Asked QuestionFAR Factory Acceptance ReviewFAT Factory Acceptance Tests



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : vii

FDIR Fault Detection, Isolation and RecoveryFP Final PresentationFPA Final Presentation and AcceptanceGUI Graphical User InterfaceHDF Hierarchical Data FormatHTML Hyper Text Mark-up LanguageHTTP Hyper Text Transfer ProtocolHW HardwareICD Interface Control DocumentIDVP Implementation, Diffusion and Validation PlanIR Interface RequirementsITT Invitation To TenderJSP Java Server PagesKOM Kick Off MeetingMACAO Member Agency Control Authority OfficeMMI Man-Machine InterfaceNAS Network Attached StorageOAIS Open Archival Information SystemOASIS Space Data Modelling Help Tool OSAT On Site installation and Acceptance TestsPAP Product Assurance PlanPDR Preliminary Design ReviewPMP Project Management PlanPUS Packet Utilisation StandardPVL Parameter Value LanguageRB Requirements BaselineRID Review Item DiscrepancyRTD Research and Technology DevelopmentSCMP Software Configuration Management PlanSIP Submission Information PackageSOAP Simple Object Access ProtocolSOW Statement of WorkSPMP Software Project Management PlanSRR System Requirements ReviewSVG Scalable Vector GraphicTM/TC Telemetry / TelecommandTS Technical SpecificationsUDDI Universal Description Discovery and IntegrationURD User Requirements DocumentWSDL Web Service Description LanguageWWW World Wide WebXML eXtensible Mark-up LanguageXSL eXtensible Stylesheet LanguageXSLT eXtensible Stylesheet Language Transformation



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : viii

Applicable Documents

Title Issue Date ReferenceAD1 ESRIN SOW “Development of

EAST Based Access Tools”1.1 18/03/2002 GSPS-RTDA-EOAD-SW-02-0001

AD2 Fax received from ESA 07/06/2002 IMT-CR/9021/02/I-LG

AD3 CS Proposal "DEBAT" 21/06/2002 CSSI/111-1/CG/LM/2/453-1

AD4 Minutes of Kick-off Meeting 17/09/2002 /CRR/SS/DEBAT/001

AD5 ECSS – Space Engineering Standards – Software

ECSS-E-40B

AD6 ECSS - Space Engineering Standards - Software Product Assurance

ECSS-Q-80B

AD7 CS SI Proposal for Phase 2 March 2003 CSSI/111-1/CG/PKV/3/140

AD8 Minutes of Phase 2 Kick-off meeting (Authorisation To Proceed)

30/04/2003 /CRR/SS/DEBAT/006



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : ix

Reference Documents

Title Issue Date ReferenceRD1 DEBAT Product Assurance Plan 1.2 08/07/2003 SS/DEBAT/PAP

RD2 Interviews Technical Note 1.0 14/01/2003 SS/DEBAT/I_TN

RD3 EAST for TM/TC processing Technical Note

1.0 14/01/2003 SS/DEBAT/TMTC_TN

RD4 EAST current applications Technical Note

1.0 14/01/2003 SS/DEBAT/EAST_TN

RD5 Requirements Collection Technical Note

1.0 14/01/2003 SS/DEBAT/RC_TN

RD6 User Requirements Document 1.2 10/03/2003 SS/DEBAT/URD

RD7 Software Requirements Document 1.1 10/03/2003 SS/DEBAT/SRD

RD8 Selection Process Methodology Technical Note

1.2 10/03/2003 SS/DEBAT/SPM_TN

RD9 Implementation, Diffusion and Validation Plan

1.1 10/03/2003 SS/DEBAT/IDVP



Reference : SS/DEBAT/PMP Issue : 1.3 Date : 13/11/2002 Page : 1

1. Introduction

1.1 Project overview

The main objective of “Development of EAST Based Access Tools” project is to build a set of enhanced tools upon EAST technologies to provide engineers, scientists and end-users with powerful tools covering the entire data life cycle (modelling/definition, production/generation, editing, accessing, checking, processing, extracting, querying, post-processing…).

Another objective is to promote and diffuse DEBAT tools family and concepts to the potential user community (existing fields of application or new ones) by making them aware of the availability and advantages of these enhanced tools (DEBAT workshop, Web site, demonstration kit…).

The underlying philosophy is to build on the knowledge and capitalised experience gained during previous developments (CNES, CS and ESA) being carried out for several years, to take advantage of the lessons learned from current/past EAST user projects (limitations, expectations), and to take into account new requirements (coming from the analysis of a range of selected projects/missions) and forthcoming requirements.

There are two major identified axes of work:

Improvements (or new developments) to existing tools within current fields of application: this covers the extensions and enhancements of EAST language and tools for well-known domains where the degree of confidence is high due to past experience. The final results of these developments are expected to be high quality software: reliable, well engineered, user friendly, properly documented and flexible.

TM/TC fields of application: this covers the application of EAST technologies to TM/TC processing which is a new and critical domain that requires in depth analysis. The main objective for this new field of application is to provide the “proof of concept”, i.e. to analyse (and potentially demonstrate) the feasibility and advantages gained from applying EAST in the TM/TC arena.

1.2 Objectives of the document

This Project Management Plan is intended to define, organise, monitor and control all the activities to be carried out in the frame of the DEBAT project.

1.3 Structure of the document

This document is organised as follows:

Chapter 1: IntroductionThe current chapter gives an overview of the project and its objectives.



Reference : SS/DEBAT/PMP Issue. : 1.3 Date : 13/11/2003 Page : 2

Chapter 2: Project organisationThis chapter details the project organisation: the organisation chart and the organisational roles and responsibilities.

Chapter 3: Monitoring and controlThis chapter describes the monitoring and control processes set up for the project.

Chapter 4: Licenses issuesThis chapter deals with the licenses issues of the DEBAT software.

Chapter 5: Phase 1 - Analysis and studies phaseThis chapter describes the work to be performed during the first phase of the project, together with the development plan, the schedule, meetings and deliveries.

Chapter 6: Phase 1 - Implementation phaseThis chapter describes the work to be performed during the second phase of the project, together with the development plan, the schedule, meetings and deliveries.

Chapter 7: Warranty phaseThis chapter details the principles and the work to be performed during the warranty phase.

Chapter 8: Documentation treeThis chapter gives the structure of the documentation produced in the frame of the project

1.4 Evolution of the Project Management Plan

This Project Management Plan will be updated as necessary throughout the project, and at least for the beginning of the second phase of DEBAT.




2. Project organisation

2.1 Process model

The project has a phased approach. There are two phases:

"Analysis and studies phase": this first phase covers mainly the identification, analysis and ranking of the limitations of the current tools set and expected enhancements for fulfilling the expressed requirements, the identification of other areas of work that might become candidates for future work, and the production of an overall implementation and diffusion plan. "Implementation phase": this second phase covers mainly the design, implementation, validation and demonstration of the developments carried out during DEBAT project.

2.2 Overall project schedule and milestones

The duration of the first phase is about 5 months, and the duration of the second phase is about 12 months. A negotiation period is foreseen between the two phases in order to consolidate the price of phase 2 (an Authorisation To Proceed - ATP - is required to proceed with Phase 2). The expected total duration of the project is 18 months.

A warranty period of 6 months is foreseen at the end of the project. This warranty period begins after a check-out period of 3 months (the check-out period beginning at the Acceptance Review of the software by the Agency).

Figure 2-1 Major milestones

The following figure gives the project overall schedule:




Figure 2-2 Overall project schedule and milestones

The following table gives the major milestones of the project.

Meeting Purpose

M0 - T0 KOM - Kick Off MeetingM1 - T0+1 Interviews at ESRINM2 - T0+2 Progress meetingM3 - T0+4 SRR - System Requirements ReviewM4 - T0+5 DEBAT WorkshopM5 - T0+5.5 End of phase 1 meeting

M6 - T0+6 ATP - Authorisation To ProceedM7 - T0+8 PDR - Preliminary Design ReviewM8 - T0+10 CDR - Critical Design ReviewM9 - T0+12 Progress meetingM10 - T0+14 Progress meetingM11 - T0+16 FAR - Factory Acceptance ReviewM12 - T0+17 AR - Acceptance Review (provisional acceptance)




M13 - T0+18 FP - Final Presentation (end of project)M14 - T0+20 Final Acceptance (end of check-out period) - start of

warranty of 6 months.

2.3 Facilities and resources

All the work described in this contract will be carried out at CS premises.

All hardware and software resources (i.e. machines, tools, etc.) will be provided by CS for the activities to be performed at his premises and by ESRIN for activities to be performed at ESRIN facilities (installation at ESRIN and on-site acceptance tests).

The hardware and software used for the project are described in the Product Assurance Plan [RD1].

2.4 Project organisation chart

2.4.1 First project organisation chart

The following diagram presents the first project organisation chart:

Figure 2-3 Project Organisation chart




The key personnel is the following:

The Project Director is Alain ROUSSEL. The Project Manager is Carlos GUERREIRO. The Technical Manager is Laurent COHEN. The Project Quality Manager is Maud Granet.

Three axes of work have been identified. A responsible has been nominated for each one: EAST/OASIS core technologies: Frédéric BERRIRI Advanced technologies (Java, Web Services) : Laurent COHEN TM/TC activities: Olivier QUEYRUT

Furthermore, several experts will be involved all the project long in order to support the project with their thorough technological knowledge:

EAST expert : Claire PELLIZZARI (she has been working on EAST for more than 8 years) Freeware and Open source expert: Luc MAISONOBE The development team will also include J. FERREIRA and J. CANDAT.

The following matrix defines the list of the key personnel in a synthetic way:

Name of the person

Function within the project

Competence fields Amount of time dedicated to the

project (%)Alain ROUSSEL

Project Director 19 years experience on project management.

Support to Project Management

Carlos GUERREIRO

Project Manager Architectures, JAVA/CORBA: he’s currently in charge of the Space Studies Direction of Projects.

Project Management

Laurent COHEN

Technical Manager and Responsible for Advanced Technologies

Advanced technologies (Java, Web Services)

100%

Frédéric BERRIRI

Responsible for EAST/OASIS core technologies

EAST/OASIS: he is currently the EAST project manager (CNES maintenance contract)

75% DEBAT project25 % EAST

Maintenance Contract (CNES)

Olivier QUEYRUT

Responsible for TM/TC activities

TM/TC, SCOS-2000. 100%




Claire PELLIZZARI

EAST expert EAST/OASIS: she has more than 8 years experience of EAST.

50% DEBAT project50% EAST


Jérôme FERREIRA

Design/Development team

EAST/OASIS: he has been working on EAST/OASIS since 09/2001 (EAST/OASIS CNES maintenance contract).



Jérôme CANDAT

Design/Development team

XML/JAVA 100%

Luc MAISONOBE

Freeware expert Specialist of the freeware/open source issues.

1 day per month

2.4.2 Second project organisation chart

Three main changes have been done into the project organisation during the month of September of 2003:

Alain Roussel, the Project Director of the project has changed his responsibilities into the company. The Project Director is now Alain Lapeyre. He is an experimented Project Manager, he has 12 years experience.

Carlos Guerreiro, the project manager has left CS during this month. This departure has some impacts on the organisation of the DEBAT project. Laurent Cohen, previously the Technical Manager of the project is now the Project Manager, and Olivier Queyrut became the Technical Manager.

Jean-Yves Souillard is now replaced by Josiane Denailhac, she is now the new project quality manager.

The following diagram presents the second project organisation chart:




Figure 2-4 Project Organisation chart

The key personnel is the following:

The Project Director is Alain LAPEYRE. The Project Manager is Laurent COHEN. The Technical Manager is Olivier QUEYRUT. The Project Quality Manager is Josiane DENAILHAC.

Two axes of work have been identified. A responsible has been nominated for each one: EAST/OASIS core technologies: Frédéric BERRIRI Advanced technologies (Java, Web Services) : Olivier QUEYRUT TM/TC activities: suspended

Furthermore, several experts will be involved all the project long in order to support the project with their thorough technological knowledge:

EAST expert : Claire PELLIZZARI (she has been working on EAST for more than 8 years) Freeware and Open source expert: Luc MAISONOBE




The following matrix defines the list of the key personnel in a synthetic way:

Name of the person

Function within the project

Competence fields Amount of time dedicated to the

project (%)Alain LAPEYRE Project Director 12 years experience on

project management.Support to Project

Management

Laurent COHEN Project Manager Advanced technologies (Java, Web Services). He has experience in project management

Project Management

Olivier QUEYRUT Technical Manager and Responsible for Advanced Technologies

Advanced technologies (Java, Web Services)

100%

Frédéric BERRIRI Responsible for EAST/OASIS core technologies

EAST/OASIS: he is currently the EAST project manager (CNES maintenance contract)

75% DEBAT project25 % EAST


Claire PELLIZZARI EAST expert EAST/OASIS: she has more than 8 years experience of EAST.



2.5 Organisational roles and responsibilities

2.5.1 The Project Director

He is responsible for marketing, administrative and financial follow-up as well as control and providing assistance. He delegates management of the project to the project head and supervises the operation by means of periodical co-ordination meetings.

2.5.2 The Project Manager

He is responsible for satisfactory completion of the project.

He represents CS in relation to Customer for performing the contract. He distributes the tasks within the team assigned to the project, defines responsibilities and rules on possible conflicts. He submits all decisions which are his responsibility to Customer and ensures that they are then carried out. The project head plays a significant part in technical development so that he grasps the whole project perfectly:




he ensures that the project consistently complies with the design specifications and also with the standards and practices defined in the product assurance plan,

he manages and co-ordinates the members of the team responsible for the work, he is Customer's main contact, he chairs technical and progress meetings, he follows up progress of each of the tasks as well as monitoring deadlines, at the beginning of each phase, he plans development with the different members of the

team as well as the cross-checking controls to be performed, he ensures that these are carried out, he checks that the documentation produced has been correctly filled out and that it complies

with standards, he closes cross-checking controls and follow-up and authorises delivery, he alone is responsible for approving any request for internal technical modification from

the CS project team, before submitting it to the Customer manager.

2.5.3 The technical manager

The technical manager is the project manager assistant. He is responsible for design choices and for choosing the ways in which to produce different system components. This involves:

providing technical support to team members during prototyping, design and production phases,

federating the team members' design and production choices, providing technical follow-up for performance of each of the tasks while sending progress

reports to the project head, participating in cross-checking controls, participating in design, production and testing of components, participating in system acceptance reviews, defining and maintaining a critical item list.

2.5.4 The Experts

The EAST expert is devoted to support the project through his thorough knowledge of the technologies involved. She is aimed at giving his expertise to assist the development team in the different phases of the project from the requirement analysis to the design choices and implementation.

2.5.5 The Development Team

The members of the development team perform the tasks assigned to them by the CS project manager and report on the progress to the technical manager. This involves:

designing and implementing software elements, then participating in testing, integrating and validating them, writing the corresponding documentation, performing scheduled technical and quality cross-checking controls at the beginning of each phase by means of check-lists made by top management.




2.6 Organisational boundaries and interfaces

2.6.1 Communications with ESRIN

Within the project, the responsible persons are the following:

ESRIN CSTechnical matters Alessandro Ciarlo

([email protected])Laurent Cohen ([email protected])

Administrative, financial matters

Luc Govaert ([email protected])

Alain Roux ([email protected])

2.6.2 Relation to CNES EAST project

The DEBAT project is based on EAST existing technologies and mainly on EAST core, EAST Interpreter and Generator and OASIS. CNES has a maintenance contract for EAST technology (at the time being, CS is in charge of this contract).

The main contact at CNES concerning EAST technologies is Denis Minguillon ([email protected]).

As a matter of fact, some “connection points” are to be foreseen in the course of the project in order to ensure that CNES EAST technology corrections and evolutions (issued from the maintenance contract) and DEBAT EAST evolutions (issued from DEBAT project) will be compatible (the idea is to provide an unique EAST core version at the end of DEBAT, i.e. maintaining compatibility between DEBAT EAST developments and CNES EAST developments, and notably backward compatibility).

CNES is ready to deliver the source code of EAST technology to CS (as DEBAT ESA contractor) and to authorise the improvements of this code (as long as it remains an unique core version that CNES would recover at the end of DEBAT).

The following approach is proposed:

A delivery of EAST technology is expected at the beginning of the project KOM (sources code, documentation, installation procedures, etc.) for technical analyses/studies. Another delivery of EAST technology is expected at ATP (start of phase 2) including the corrections/modifications issued from the CNES EAST maintenance contract. Other possible deliveries could be considered depending on the corrections/evolutions issued from the maintenance contract. For instance, at ATP+4 and FAR-1 (one month before FAR). Some internal meeting (between CS DEBAT team and CS EAST team) will be held in order to ensure proper and compatible work between the two teams. As CNES will be involved in the users group, it will also be able to give its appraisal about the orientations of DEBAT.


mailto:[email protected]






3. Monitoring and control

3.1 Meeting and reporting

3.1.1 Meetings

Project management is based on regular internal and external meetings.

External meetings: any meeting taking place with CS and the Customer. During these meeting, CS takes the minutes of the proceedings. These are co-signed by both parties and contain at least:

date and place of meeting, list of attendees, agenda of the meeting, main conclusions of the meeting, statements of the actions agreed, due dates and responsible, date and place of the next meeting.

The potential attendees receives notice of the meeting as well as the agenda in order to prepare the meeting, at least 5 days before the latter takes place. The documentation required to support decisions to be discussed in the course of the meeting are made available to the ESA technical officer at least five days before the meeting.

The frequency of such meeting is between six weeks to two months.

Review meetings require in addition the preparation of the documents that are subject to review and acceptance, and the preparation of the milestone report. If applicable, the review is held by slides and demonstrations.

Internal meetings: these are the meetings held at CS premises with CS employees.The objective of these meetings is to discuss technical problems and solutions, to monitor and control the progress status, and to plan the work to be achieved.

3.1.2 Reporting

CS delivers at the end of each month a Monthly Progress Report containing at least the following elements:

Management information, Technical status, Progress since last report, Delays identified or foreseen, Corrective actions, Encountered / anticipated problems, Updated schedule, Risk register, Actions Items List




Delivery and invoicing status

A Milestone Report is to be delivered at each review meeting giving in addition a general plan for the work to be performed in the next stage of the project.

3.2 Schedule reporting and control

The schedule (Gantt chart provided by Microsoft Project) will be updated on a regular basis and monthly reported to ESRIN. Monthly Progress Reports will include the updated schedule according to the current progress status of the tasks to be carried out.At any schedule update, an impact analysis will be performed showing notably the impact on the expected deliveries.

3.3 Risk management and register

Risks are an inherent element of projects and need continuous attention throughout a project life cycle in order to manage schedule, technical performance and cost. The purpose of risk management is to identify risks as early as possible, adjust the development and integration strategy to mitigate those risks, and develop and implement a risk management process as an integral part of the DEBAT project.The project manager will be in charge of the risk register all the project long. The risk register will be included in the monthly progress reports.Risks are identified during the proposition and will be refined throughout the project and in particular during the specification phase.The following risk register is gathering the risks that have been identified directly from the proposal.

Identifier Description Probability Impact Possible action

R1 Availability of informationDEBAT project is strongly based upon efficient collection of information from several sources: interviews (users group, selected people for interviews,…), documentation (selected set of missions/projects, TM/TC arena, other outcome,…), etc.The access to the related information is considered as critical.

Low High The information should be made available to CS as soon as possible to be taken into account (at the beginning of the project for the available documentation).

R2 Tight schedule There is a risk associated to the shortness of the schedule (the duration of first phase is only 5 months of the total 18 months project). This can be a too short period to perform all the required work.

High Medium Pragmatic working principles should allow to focus on essential work The exact scopes of the studies shall be clearly defined.




4. Licenses issuesThis section presents, in its first part, principles for the DEBAT development and license, taking into account the CNES property on the EAST/OASIS software, which constitutes an important basis for the DEBAT software.

In the second part, this section presents the terms of the proposed license for DEBAT.

4.1 Principles of the DEBAT development and license

Hypothesis

The CNES is ready to deliver to CS the source code of EAST/OASIS which is the basis for the DEBAT developments. It is ready to authorise the improvements of EAST/OASIS code in order to integrate DEBAT requirements. This point is to be formalised in a license contract between CS and CNES in the early stages of the project. This license contract will be attached to this Project Management Plan as soon as available. EAST/OASIS are governed by a license “freeware in binary form”: i.e. that anybody can use or redistribute the EAST/OASIS software in its binary form (without any fee), but the modification of this software is not allowed (the source code is not provided). The new developments performed in the framework of DEBAT by CS, will be governed by a license “freeware in binary form” (same philosophy as EAST/OASIS current license).

Proposal

Each source file specifically developed for DEBAT project is the property of CS. Each unmodified source file coming from EAST/OASIS is the property of CNES. For each source file coming from EAST/OASIS which has been modified in the framework of DEBAT, they become the property of CNES.

Consequently, the property rights and the applicable license can be summarised as follows:

Type of fileEAST/OASIS files not modified for DEBAT project

EAST/OASIS files modified for DEBAT project

Files specifically developed for DEBAT project

Property CNES CNES CS SI

Applicable license

EAST/OASIS freeware binary form

EAST/OASIS freeware binary form

CS freeware binary form

The exhaustive list of the files governed by each license will be made available at the end of DEBAT project.It’s also important to mention that there are no runtime fees associated to the global DEBAT product (freeware approach and no COTS used).




At the end of the project, ESA, CNES and CS will be allowed to diffuse the entire DEBAT software for free in a binary form.CS will provide ESA with a non-exclusive, transferable license of DEBAT (for the code which is property of CS). This license will be extended to CNES.Furthermore, CS commits itself to license subsequent (performed outside the scope of DEBAT contract) versions of DEBAT for free to ESA, ESA’s users and CNES (same conditions as for the initial DEBAT software).

4.2 Terms of the proposed license

As a summary, we can say that the DEBAT “freeware-in-binary-form” license (composed of EAST/OASIS license and CS licence) basically allows anybody to use or redistribute the binaries. Modification is not allowed (the source code is not provided).




5. Phase 1 - Analysis and studies phase

5.1 Objectives

The main objective of this phase is to identify (through several studies and analysis) the limitations of the current EAST tools and the potential evolutions and enhancements able to respond adequately to the users (current users or new users) requirements.

A number of analyses/studies are to be carried out in this first phase:

Requirements collection and technical analysis:

analysing the current EAST limitations and the requirements (interviews, comparison of existing functionalities versus a set of selected projects/missions, taking into account the requirements coming from TM/TC domains), identifying the enhancements needed and performing their technical analysis, compiling the expressed limitations and requirements into a wish list of “user requirements”.

DEBAT definition:

performing a trade-off between each ranked expressed “user requirement” (its potential added-value) and its cost, selecting and constituting the more relevant implementation subset, proposing an implementation plan for phase 2.

Support to users group:

maintaining close contacts with an users group set-up at the beginning of the project, reporting to it the orientations, choices, encountered problems, and, analysing its inputs (suggestions, assessments, …).

Promotion:

supporting a CNES/ESA DEBAT workshop, and, publishing a Web site for promotion and diffusion purposes.

Some implementations are also foreseen:

Implementation of OASIS type library concept, Development of the DEBAT framework MMI.




5.2 Work breakdown structure

The work breakdown structure of DEBAT phase one is depicted below:

Figure 5-5 Phase 1 Work Breakdown Structure




5.3 Development plan, work logic and activities

The work logic for phase 1 is depicted in the following figure.

Figure 5-6 Analysis and studies phase ( phase 1)

The project starts with the “Requirements collections and technical analysis” task (WP-120000).

This task includes: Interviews stage (WP-121000): the interview activities allows to gather users feedback and to get the expected enhancements or limitations expressed by current users or potential new users. Within current domains of application of EAST technology ( “EAST existing tools family WP-122000), the research for new requirements and limitations is achieved by implementing EAST format descriptions of the following data formats and by analysing the work done and the results obtained in order to identify the limitations and required enhancements:

CryoSat, Envisat (MERIS, SCIAMACHY), AMS2, CDDP (CNES).




Within the new TM/TC domain (“EAST for TM/TC processing” WP-123000), the research for new requirements and limitations is achieved by:

modelling the generic PUS Service 11 with EAST (directly from the book) modelling the CryoSat Service 11 starting from the generic description, and by analysing the work done and results obtained in order to identify the limitations and required enhancements.

The compiled wish list issued from previous activities is reviewed and approved in the System Requirements Review - SRR.

Some implementations are also to be performed during phase 1 (“Implementations” WP-130000): Implementation of OASIS types library concept: this new feature appears to be often required by users. Moreover, this function is also of aid in performing the work on TM/TC activities. DEBAT framework MMI mock-ups: these mock-ups allows to get early users feedback on the future DEBAT MMI.

The next step is the “DEBAT definition” task (WP-140000), i.e. the definition of DEBAT implementation subset. The definition process is performed as follows:

A first step allows to define the more relevant implementation subset (to be agreed by ESA during negotiation phase), The second step covers the preparation of the second phase by providing an overall implementation/diffusion plan and identifying interesting areas of future work (beyond the scope of DEBAT, for instance evolution requirements excluded from the implementation).

The “DEBAT definition” task is followed by a negotiation period to agree with ESA the technical contents of the implementation phase. ESA is to provide an Authorisation To Proceed (ATP) before the start of the implementation phase.




5.3.1 Requirements collection and technical analysis

The following figure describes the activities to be carried out during the “Requirements collection and technical analysis” activity. For each activity, it shows the inputs as well as the outputs of the tasks to be done.

Figure 5-7 Requirements collection and technical analysis work logic




5.3.1.1 Interviews stage

The main activities to be carried out during the interview stage are sketched hereafter:

Figure 5-8 Phase 1 interviews methodology The interview preparation allows to define an interview form permitting to express the users feelings and appraisal about EAST technology and its potential evolutions. This form is defined by CS and is approved by ESA before diffusion. This interview form shall at least take into account:

an user-oriented point of view: expression in term of functionalities, limitations and needs including also topics like support, training, promotion, etc., a technical point of view (known problems, performance needs, functionalities that could be implemented better, lack of some functions,…) including architectural/design factors (modularity, flexibility, openness, reliability, user-friendliness, …) as well as software quality factors (quality of documentation, …), a market-perspective point of view including cost-efficiency analysis, gained productivity against other solutions (in-house or commercial products), etc., a free opinion column to leave enough freedom to people for expressing less-formalised feedback,

This activity will also permit to select the people to be interviewed. The list of the foreseen people is to be defined in the early stages of the project. The interviewed people list would preferably be composed of:

people from the users group, people from current projects using EAST technology, people from potentially interested projects (EO projects, TM/TC projects, SCOS-2000, …),




people from CS EAST team with a strong experience in the technology. The interview performance allows to diffuse and perform the interviews. The preferred way to perform the interview is by meeting the people to be interviewed (or eventually by phone or email). Furthermore, a mission to ESRIN is foreseen in the frame of the proposal in order to meet the current and potential interested users of EAST technology to facilitate (and potentially speed-up) the interview process. The interview exploitation includes the abstraction, analysis and synthesis of the raw collected forms in order to extract and rationalise the main expressed limitations of EAST technology and the main expected requirements of DEBAT.

5.3.1.2 Identification and technical analysis of required enhancements and limitations

This activity shall allow to identify the limitations of existing tools and the required enhancements to be taken into account in the future DEBAT software. The sources of information used as inputs are the following:

In the current fields of application of EAST technology, the research for limitations and new requirements is achieved by implementing data descriptions of some selected data formats as stated in [AD04]. The range of selected projects/missions is the following: CryoSat, Envisat (MERIS, SCIAMACHY), AMS2, CDDP (CNES). In the fields of possible applications of EAST for TM/TC processing (with peculiar attention to SCOS-2000), the research for limitations and new requirements is achieved by implementing the EAST descriptions of the generic PUS Service 11 and by implementing/specialising this generic description for CryoSat Service 11. Results coming from other related projects (CNES, ESA, ASTRIUM, others) such as Ariane, Helios, ATV, … using (or potentially interested) shall be considered if available in the early stages of the project. CS EAST team will be involved in this process so as to optimise it. Our team keeps constant interaction with end users and therefore has a good knowledge of limitations and requirements from both a technical and an user point of view.

The results obtained from the implementations of EAST data descriptions done during these activities are gathered in a Technical Note (TN-1 in the diagram Figure 5-7 Requirements collectionand technical analysis work logic) covering the technical aspects (theoretical feasibility analyses, preliminary solutions identifying unclear issues or expected problems, critical issues, etc.) and also detailing the methodology used for the requirements collection and technical analysis.

5.3.1.3 Compilation of wish list

This task is aimed at compiling with an adequate methodology (abstraction, synthesis, rationalising process, selection process) all the results gathered during the previous tasks in a set of “user requirements” that, if implemented, would be a suitable response to the needs of the projects taken as input.The outputs of this tasks are:

an User Requirements Document (URD) detailing the features that satisfy the identified needs. a Technical Note (TN-2 in the diagram Figure 5-7 Requirements collection andtechnical analysis work logic) describing the methodology used to compile the wish list (abstraction methodology, selection criteria tables, …).




5.3.2 Implementations

Some implementations are foreseen in the frame of DEBAT Phase 1: Implementation of OASIS types library concept: the types library concept is aiming at helping users to manage and share common parts of data descriptions (and notably, sharing data types between several data descriptions, function that is not available in the current EAST tools). DEBAT framework MMI mock-ups: the DEBAT framework MMI is aiming at providing users with a single entry point (highly customisable and very user-friendly) to all the DEBAT tools.

5.3.3 DEBAT definition

The following diagram details the main activities and the methodology used for DEBAT definition. This task takes as input the wish list issued from the “Requirements collection and technical analysis” task.

Figure 5-9 DEBAT definition work logic




The methodology used for the definition process covers the following steps: The “Evaluation of wish items” activity starts with the definition of a criteria table for evaluating the added value of each wish item. This criteria table is to be defined in co-operation with the users group and is to be approved by ESA. Once all the criteria are well defined (potentially with priority levels assigned to them), the evaluation of each item in the wish list can be done according to the criteria table, in order to find the “added-value” of each item in the list. This evaluation shall take into account the outcomes from the DEBAT workshop and shall be carried out with close interactions with the users group. The cost of each item has also to be defined. A “Trade-off” between cost and potential added-value is the logical next step in order to choose among the evaluated items. The “Constitution of implementation subset” allows the selection of the most cost effective and relevant subset for the implementation. This task also includes the consolidation of external requirements, such as any constraints, validation and verification requirements and interface requirements. Tow outputs are to be produced: DC&V/VR (Design Constraints and Verification Requirements) and IR (Interface Requirements). The “Preparation of phase 2” covers the production of an Implementation, Diffusion and Validation Plan (IDVP) that gives the suggested logical plan of developments. This plan shall also contain an outline plan for the completion of the data format description analysed during the “Requirements collection and technical analysis” phase, as well as an outline plan for “proof of concepts” activities for the TM/TC application of EAST technology.

5.3.4 Support to user group

A small users group made in co-operation with ESA and CNES will follow the project. This users group is intended to provide from an end-user point of view:

its appraisal and assessment of the orientations given to the DEBAT tools (envisaged changes, critical choices), some suggestions, needs or expected enhancements to be taken into account in the frame of DEBAT or in future areas of work, its evaluation of the final tools and results.

The user group is composed of the following persons:

Name Email Affiliation

MembersNestor Peccia [email protected] ESAGian Maria Pinna [email protected] ESAEric Monjoux [email protected] ESAMichel Nonon-Latapie [email protected] CNESFrançoise Schiavon [email protected] CNESThierry Guinle [email protected] CNES

EAST expert

Denis Minguillon [email protected] CNES











Co-ordinators

Alessandro Ciarlo [email protected] ESACarlos Guerreiro [email protected] CS

A constant interaction between the users group and CS is required all the project long so as to: keep the group well informed of the status of the project (changes, choices, design,…), to actively involve the group when crucial decisions are to be taken (and peculiarly during phase 1 for the requirements collection), and to efficiently collect and process inputs coming from the group.

The users group is assumed to communicate by email. In order to establish and maintain efficient contacts with the users group, the following is envisaged:

the documents produced in the course of the project are diffused to the users group in order to get its appraisal and early feedback (when possible the draft versions of the documents will be made available to the users group in order to get its early comments), periodic reports gathering major information (orientations, choices, design,…) are sent to the group (frequency is about one month), the users group is invited to attend the major milestones reviews (e.g. SRR, PRD, CDR, …) in order to be actively involved in the project, a mailing-list mechanism can be set-up in order to track the exchanges between the users group and the DEBAT team: these exchanges could be published in a private area on the DEBAT Web site in order to allow an easy access for the users group.

5.3.5 Promotion

5.3.5.1 Support to workshop

A workshop at ESTEC is foreseen around the end of phase 1 to make the interested community aware of EAST tools and DEBAT enhancements derived from this project.CS will contribute to this workshop providing presentations about the outcome of the requirements investigations and the foreseen developments, and collecting some early user feedback, as well as providing some technical support (publication of collected presentation on the Web and possibly short demonstrations).

5.3.5.2 Project Web pages

A Web site for ensuring the promotion of EAST/DEBAT technology has to published on an ESA server in order to illustrate the objectives and context of DEBAT project, as well as the progress and outputs of the activities.

The DEBAT Web site will be updated all the project long as necessary.

The plan for content and update schedule of the project Web pages is described here below. A small set of pages will be published on an ESA Web server following the ESA guidelines and templates. These pages will contain at least the following sections:






Objectives : describing briefly the objectives of DEBAT, Context : presenting the context of the project (EAST technology and history), User Group : presenting the user group, its role and responsibilities, How it works : describing the working principles of EAST / DEBAT tools, Documentation : pointing to the general documentation needed to understand the project and the technologies involved.

These pages will remain on the ESA Web server: they describe introductory information about the project. These pages will be made available (published) for the end of October. These pages will point to the CNES EAST site allowing to get more detailed information about the current EAST tools.

A more detailed set of pages will also be set-up. These pages will be published on a CS Web server as soon as it will be available (probably, at the beginning of year 2003). Until this server is available, these pages will be published on a temporary ESA Web server, and will be then moved to the CS Web server. These pages will contain the following sections:

News : giving the latest news of the project, Context : giving the context of the project and its organisation, Expression of requirements: to let the users express their requirements about the DEBAT software, Publications : giving access to the documents relative to the project, Downloads : to download the DEBAT tools and associated documentation, the demonstration kit, … Tools on line : on-line demonstrations of the DEBAT tools suite, FAQ Site Map Help and contacts

A first version of these pages will be published for the M2 milestone. A consolidated version of these pages is expected for the SRR review.




5.4 Schedule, meetings and deliveries

5.4.1 Schedule

The following picture details the schedule of Phase 1 (this schedule is generated with Microsoft Project):

Figure 5-10 Detailed schedule of DEBAT Phase 1

5.4.2 Meetings

The following table details the meetings in the first phase of the project. It also indicates the location and the duration of each meeting.

Meeting PurposeDuration

(days)Date & Location

M0 KOM Kick Off Meeting 1 TO (ESRIN) 17/09/2002M1 Interviews at ESRIN 3 TO+1 (ESRIN) 17/10/2002M2 Progress meeting 1 TO+2 (CS)13/11/2002M3 SRR - System Requirements Review 1 TO+4 (CS) 07/01/2003




M4 DEBAT Workshop 3 TO+5 (ESTEC) 29-31/01/2003M5 End of phase 1 meeting 1 TO+5,5 (CS)14/02/2003

5.4.3 CS Deliveries and Customer Furnished Items

The table below details the deliveries to be produced by CS and the "customer furnished items" to be made available to CS.

Meeting CS deliveries ESRIN deliveries

M0 KOMPMP (first issue at TO+1)PAP (first issue at TO+1)

Documentation/samples of data for: CryoSat, Envisat (MERIS, SCIAMACHY), AMS2, CDDP.Documentation for PUS Service 11 and CryoSat Service 11.Initial list of members for users groupInitial list of target people for interviews (ESRIN)ESA web pages templates or guidelinesOutcomes from related projects (if available)

M1 Interviews at ESRINPMP first issuePAP first issue

Availability of selected target people for interviews at ESRIN.

M2 ProgressProgress Report

M3 SRR (System Requirements Review)“Requirements Collection Technical Note”Preliminary EAST descriptions produced during technical analysis (if any)URD“Selection Process Methodology Technical Note”Milestone reportProduct Assurance Report

M4 Workshop at ESTECCS PresentationsDemonstrations (if any)

The organisation of the workshop is done by ESA/CNES.

M5 End of P1 meetingOASIS software enhanced with the type library conceptDEBAT framework MMI mock-upsSRDImplementation Plan





Web pagesMilestone reportProduct Assurance Report

The contents of each deliverable document is given in the table below for each review. The contents of the documents have been tailored according to ESRIN Statement of Work [AD1] from the ECSS-E-40-B standards [AD5].

Document Requirement SRREnd of P1

PDR CDR ARCustomer approval on file

Package File

URDUser Requirements

DocumentX

URD

SRDFunctions and performance requirements of the system

XSRD RB

SRDDesign constraints and

verification and validation requirements

XSRD RB

SRD Interface requirements X SRD RB

5.5 Work Packages Description

The work-packages for Phase 1 are fully described in the CS proposal for Phase 1 [AD3]..




6. Phase 2 - Implementation phase

6.1 Objectives

The phase 2 of the DEBAT project is the implementation phase: it covers the design, implementation, validation and demonstration of the developments carried out during the whole DEBAT project.

The following schema presents how the phase 2 is integrated in the whole DEBAT project and in particular, it shows the previous activities. These activities allowed to identify the subset of user requirements to be implemented during the phase 2 and to define the implementation, validation and diffusion plans for the DEBAT software.

Figure 6-11 Outputs of DEBAT phase 1

The research for the requirements had three sources:

Interviews stage [RD2]: the interview activities allow to gather users feedback and to get the expected enhancements or limitations expressed by current users or potential new users. EAST for TM/TC processing study [RD3]: the research for requirements is achieved by modelling the generic PUS Service 11 and the CryoSat Service 11, and by analysing the work done and results obtained. A focus is also done on the SCOS-2000 Mission Control Centre in order to identify the requirements related to the potential use of DEBAT within SCOS-2000. EAST current applications study [RD4]: the research for requirements is achieved by modelling some data products (CryoSat, Envisat, AMS2) and by analysing the work done and the results obtained.

The “Requirements Collection Technical Note” [RD5] gathers all requirements identified in the previous stages.

Then, the following documents describing the DEBAT software requirements and implementation have been produced:

The User Requirements Document [RD6] details the technical objectives of the DEBAT software by defining the user requirements as a preliminary phase to the software




development life cycle. The user requirements are both extracted from the functionalities of the existing EAST tools suite and from the previous phases and are intended to define the ideal DEBAT software from the user viewpoint. The Software Requirements Document [RD7] and the Selection Process Methodology Technical Note [RD8]. The goal of the selection process is to define a coherent and relevant subset of requirements to implement. This selection mainly results from a trade-off between cost and added value. It then gives the list of the requirements chosen for implementation in the future DEBAT product. Once the subset of requirements is defined, the Implementation, Diffusion and Validation Plans [RD9] have been described. This document is used as the baseline for the phase 2. The implementation plan describes the logical plan for the development of the functional subset chosen in the previous phases. The validation plan defines how the concepts developed in DEBAT will be validated from an end-user viewpoint while the diffusion plan defines how the DEBAT product will be diffused to the user community to facilitate its adoption.

6.2 Work breakdown structure

The following figure describes the work breakdown structure of the project for the phase 2.

Figure 6-12 Phase 2 WBS




6.3 Work logic and activities

The work logic for phase 2 is depicted in the following figure that shows the major tasks.

Figure 6-13 Implementation plan for phase 2

6.3.1 Software specifications and architectural design

The “Software specifications and architectural design” task is the first step of the design of the DEBAT software. During this task, all the specifications of DEBAT – including software and external interface specifications – are compiled. The DEBAT architectural design follows, is reviewed and eventually approved in the Preliminary Design Review (PDR).




Figure 6-14: Software Specifications & Architectural Design work logic

The work package WP-2210000 comprises two activities: The external interfaces specification that is intended to clearly establish the input/output communication between the DEBAT software and all other external items. The external interface specification is compiled in the Interface Control Document – ICD. The specification of each DEBAT component. The specification includes both the component software specification and the specification of the internal DEBAT interfaces.

Once the DEBAT software components have been specified, the “High-level Architectural Design” task begins. This task allows to define the overall DEBAT design including architectural concepts and technical solutions.

Two outputs are provided: The preliminary version of the Architectural Design Document – ADD which will be updated during the next steps of DEBAT phase 2,




The preliminary version of the Software Validation and Verification Plan – SVVP which contains the description of the methods and tools used to validate and verify the DEBAT software.

Finally, the Preliminary Design Review – PDR concludes the “Software Specification and Architecture Design” task.

6.3.2 Implementation, integration and acceptance tests

Upon approval of the PDR, the Implementation, Integration and Acceptance Tests task starts.

Figure 6-15: Implementation, integration & acceptance tests work logic

The first step is the Detailed Design, which is concluded by the Critical Design Review (CDR). Several documents are produced:

The updated version of the Architectural Design Document – ADD. The updated version of the Software Validation and Verification Plan – SVVP with the description of the organisation and the activities to be carried out for the software validation. The initial version of the Detailed Design Document – DDD. The preliminary version of the Software User Manual – SUM. The Software Transfer Document – STD that contains the acceptance test plan.

Moreover, several prototypes will be created so that the graphical interfaces of the following tools will be validated with ESA in the early stages of phase 2:

Integrated environment: it comprises the prototype of the framework GUI and the project management GUI, DEBAT Data Modeller

The prototypes are proposed and eventually approved by ESA during the Critical Design Review – CDR.

The following figure details the “Detailed design” work package:




Figure 6-16: Detailed design work logic

The coding and unit-testing task follows immediately. CS proposes a two-steps integration, comprising the integration and test at CS facilities (Factory Acceptance Tests, FAT) and then the integration at ESRIN facilities (On Site Acceptance Tests, OSAT). The deliveries of these two activities are the following:

The updated version of the Software User Manual – SUM. The Software Validation and Verification Plan – SVVP updated with the validation testing report. The updated version of the Software Transfer Document – STD. If needed, the updated version of the Detailed Design Document – DDD.

This phase ends with the Acceptance Review (AR).

6.3.3 Promotion

This activity is intended to provide means to diffuse the DEBAT product to the user community in order to both promote the technology and to facilitate its adoption.There are four foreseen ways to distribute the DEBAT technology. The first consists in developing a DEBAT Web site that will promote the DEBAT technologies (this task is the continuation of the Project Web pages of Phase 1). The second stands as a CD-ROM that will contain the whole DEBAT environment. The third stands as a demonstration kit that is intended to explain the environment to users. The last stands as a brochure promoting the DEBAT features and capabilities.




6.3.4 Concept Validation

This task is the continuation of the implementation of format descriptions made during Phase 1. The purpose of this activity is the completion of some other data descriptions selected as the most representative and relevant cases in phase 1. These data descriptions test cases will be then used during the demonstration and final presentation activities.

6.3.5 Proposals for CCSDS standards updates

In the course of the project, some enhancements or extensions to the current tools might require an evolution/upgrade of the EAST language CCSDS standards (these are to be first identified in phase 1, and possibly implemented in phase 2) in order to perfectly fulfil the requirements expressed by the DEBAT current or future users. The objective of this activity is to provide CCSDS with a set of document to submit the enhanced EAST language to CCSDS for updating.

6.3.6 Demonstration

This task uses as inputs the work performed during the "Concept Validation" work-package and is supported by all the work having been done in the course of the project. This activity covers the verification and validation of the correctness of the developments carried out in the course of the project by some short and meaningful demonstrations so as to demonstrate the objectives and results that have been reached. The demonstration is to be focused on a number of relevant real test cases and real use scenarios. This one will take place at ESRIN before the final presentation.

6.3.7 Support to user group

A users group has been set-up in co-operation with ESA and CNES in the early stages of the DEBAT phase 1. This users group will continue the work performed during the phase 1 and in particular will provide from a end-user point of view its evaluation of the final tools and results.A constant interaction between the users groups and CS SI is required all the DEBAT phase 2 long. The same process as the one used during phase 1 will be established:

the documents produced in the course of the project will be diffused to the group, monthly progress reports gathering major information will be sent to the group, the users group can participate to the major milestones reviews (e.g. PDR, CDR, …) in order to be actively involved in the project.

6.3.8 Final presentation

The project ends with a Final Presentation (FP). The final presentation will take place at ESRIN after the demonstration task (WP-2400000) and particularly it will highlight the descriptions of the objectives, achievements, suggestions, lessons learned from the project and future perspectives of the technology.




6.4 Schedule, meetings and deliveries

6.4.1 Schedule

The following picture details the schedule of Phase 2 (this schedule is generated with Microsoft Project):

6.4.2 Meetings

The table below details the proposed progress meetings and their locations. The meeting dates may be a little adjusted according to ESRIN and CS availability.

MeetingPurpose Duration Date & Location

M6 ATP 1 TO (ESRIN) 30/04/03M7 Preliminary Design Review 1 T0+2 (CS) 08/07/03M8 Critical Design Review 1 TO+4 (CS) 10/09/03M9 Progress meeting 1 TO+6 (CS) 05/11/03M10 Progress meeting 1 TO+8 (CS) 07/01/04




M11 Factory Acceptance Review 10 TO+10 (CS) 03/03/04M12 Acceptance Review (provisional

acceptance)4 TO+11((ESRIN) 07/04/04

M13 Final Presentation (end of project) 3 TO+12 (ESRIN) 05/05/04

M14 Final Acceptance (end of check-out period)

1 TO+14 (ESRIN) 01/07/04

M15 Warranty Progress meeting 1 TBD (ESRIN)M16 Warranty Progress meeting 1 TBD (ESRIN)

6.4.3 CS Deliveries and Customer Furnished Items

The table below details the deliveries to be produced by CS and the "customer furnished items" to be made available to CS.


M6 ATP (Authorisation To Proceed)Updated PMPUpdated PAP

Agreement on implementation plan

M7 PDR (Preliminary Design Review)ADDICDSVVPMilestone reportProduct Assurance Report

M8 CDR (Critical Design Review)ADDDDDSUMSVVPSTDMilestone reportProduct Assurance ReportGUI Prototypes



M11 FAR (Factory Acceptance Review)SUM





SVVPSTD“TM/TC activities Technical Note”Milestone reportProduct Assurance Report

M12 AR (Acceptance Review)DEBAT Software DeliveryDDD (if needed)SVVP (if needed)STDSUM (if needed)Milestone reportProduct Assurance Report

Availability of required configuration for DEBAT installation at ESRIN

M13 FP (Final Presentation)Final report (including Final Presentation and Executive Summary)Web pagesDemonstration kit“Demonstration kit Technical Note”Distribution package“CCSDS EAST standard update proposal”

Availability of required configuration for DEBAT demonstration at ESRIN




The contents of each deliverable document is given in the table below for each review:

Document Requirement PDR CDR ARCustomer

approval on file

Package File

ADDTechnical specification of the software

X U CDR RB

ADDPerformance specifications, including hardware characteristics

X TS

ADD Software logical model X TS

ICD Interface Control Document X TS

SUM Operations manual X U AR TS

ADD Top-level design trade-offs X DJF

ADDTop-level architectural design to requirements traceability matrices

X DJF

SVVPSoftware validation plan – methods and tools

X DJF

SVVPSoftware validation plan – organisation and activities

X DJF

SVVP Validation testing report X DJF

STD Acceptance test plan X DJF

STD Acceptance test report X DJF

STD Traceability of Acceptance tests to Requirements Baseline

X AR DJF

ADD Top-level architectural design X DDF

ADD Software architectural design X DDF

DDDSoftware components design documents

X DDF

DDD System configuration items data list X U DDF

RB = Requirements BaselineTS = Technical SpecificationsDJF = Design Justification FileDD = Design Definition File

6.5 Work Packages Descriptions

The work-packages for Phase 2 are fully described in the updated CS proposal for Phase 2 [AD7].




7. Warranty phase

7.1 Warranty principles

The six months warranty proposed in the DEBAT project explicitly only covers the DEBAT code (i.e. the source files specifically developed for DEBAT). Whatever they have been modified or not, the files coming from EAST/OASIS are the property of CNES are not covered by this warranty, as CNES has a maintenance contract on EAST/OASIS products.

If for any reasons, the CNES maintenance contract for EAST/OASIS was not continued, we assume that CNES will make EAST/OASIS source code available to the public domain: in this case, a specific maintenance contract should be negotiated for also ensuring the maintenance of EAST/OASIS code.

The warranty period will begin at the end of a three months check-out period and lasts 6 months.This check-out period will start at the provisional acceptance review.

7.2 Warranty activities

The inputs of the warranty activities are the DEBAT software to be maintained and its related documentation and tests.

The warranty phase is aiming at ensuring the correction of the software problems that may arise after the completion of the developments. It includes:

Taking into account, within working hours, notification of Problems Reports from ESA, A diagnosis within 2 working days after notification, A correction or patch solution within 5 working days for critical problems, Two formal deliveries (e.g. at "start of warranty + 3 months" and "end of warranty") through two travels to ESRIN (Note: the urgent corrections will be treated through an electronic patch delivered electronically).

The project management and the quality assurance actions performed during the warranty phase are the same as the ones performed during the development phase.




8. Documentation treeThe following picture depicts the organisation of the documentation produced in the frame of the project.

Phase 1Management and Quality Assurance

Project Management Plan SS/DEBAT/PMP 1.0 15/10/2002Project Management Plan SS/DEBAT/PMP 1.1 31/10/2002Product Assurance Plan SS/DEBAT/PAP 1.0 14/10/2002Product Assurance Plan SS/DEBAT/PAP 1.1 31/10/2002Meeting Minutes

/CRR/SS/DEBAT/001 /CRR/SS/DEBAT/002 /CRR/SS/DEBAT/003 /CRR/SS/DEBAT/004 /CRR/SS/DEBAT/005

Monthly Progress Reports / Milestone ReportSS/DEBAT/MPR/001 14/10/2002SS/DEBAT/MPR/002 15/11/2002SS/DEBAT/MPR/003 17/12/2002SS/DEBAT/MPR/004 14/01/2003SS/DEBAT/MPR/005 28/02/2003

DEBAT user group Progress ReportsSS/DEBAT/PR/001 21/10/2002SS/DEBAT/PR/002 21/11/2002SS/DEBAT/PR/003 19/12/2002SS/DEBAT/PR/004 29/01/2003SS/DEBAT/PR/005 10/03/2003

Product Assurance ReportsSS/DEBAT/QR/001 21/10/2002SS/DEBAT/QR/002 28/02/2003

Delivery NotesSS/DEBAT/DN/001 15/10/2002SS/DEBAT/DN/002 19/11/2002SS/DEBAT/DN/003 14/01/2003SS/DEBAT/DN/004 04/03/2003SS/DEBAT/DN/005 17/03/2003

TechnicalInterviews Form SS/DEBAT/IF 1.0 15/10/2002Interviews Technical Note SS/DEBAT/I_TN 1.0 14/01/2003EAST for TM/TC Technical Note SS/DEBAT/TMTC_TN 1.0 14/01/2003EAST current applications Technical Note SS/DEBAT/EAST_TN 1.0 14/01/2003Requirements Collection Technical Note SS/DEBAT/RC_TN 1.0 14/01/2003Selection Process Methodology Technical Note SS/DEBAT/SPM_TN 1.0 14/01/2003Selection Process Methodology Technical Note SS/DEBAT/SPM_TN 1.1 04/03/2003




Selection Process Methodology Technical Note SS/DEBAT/SPM_TN 1.2 10/03/2003User Requirements Document SS/DEBAT/URD 1.0 14/01/2003User Requirements Document SS/DEBAT/URD 1.1 04/03/2003User Requirements Document SS/DEBAT/URD 1.2 10/03/2003Software Requirements Document SS/DEBAT/SRD 1.0 04/03/2003Software Requirements Document SS/DEBAT/SRD 1.1 10/03/2003Implementation, Diffusion and Validation Plan SS/DEBAT/IDVP 1.0 04/03/2003Implementation, Diffusion and Validation Plan SS/DEBAT/IDVP 1.1 10/03/2003OASIS Type Library Design 1.0 04/03/2003OASIS Type Library Software Verification and Validation Plan 1.0 04/03/2003

Phase 2Management and Quality Assurance

Project Management Plan SS/DEBAT/PMP 1.2 08/07/2003Project Management Plan SS/DEBAT/PMP 1.3 13/11/2003Product Assurance Plan SS/DEBAT/PAP 1.2 08/07/2003Meeting Minutes

/CRR/SS/DEBAT/006

Monthly Progress Reports / Milestone ReportSS/DEBAT/MPR/006 04/06/2003SS/DEBAT/MPR/007 07/07/2003SS/DEBAT/MPR/008 22/09/2003SS/DEBAT/MPR/009 13/10/2003SS/DEBAT/MPR/010 13/11/2003

DEBAT user group Progress ReportsSS/DEBAT/PR/006 05/06/2003SS/DEBAT/PR/007 10/10/2003

Product Assurance ReportsSS/DEBAT/QR/003

Delivery NotesSS/DEBAT/DN/006 08/07/2003SS/DEBAT/DN/007 13/10/2003

TechnicalArchitectural Design Document SS/DEBAT/ADD 1.0 08/07/2003Architectural Design Document SS/DEBAT/ADD 1.1 14/10/2003Architectural Design Document SS/DEBAT/ADD 2.0 03/11/2003Interface Control Document SS/DEBAT/ICD 1.0 08/07/2003Interface Control Document SS/DEBAT/ICD 1.1 10/10/2003Interface Control Document SS/DEBAT/ICD 2.0 03/11/2003Software Verification and Validation Plan SS/DEBAT/SVVP 1.0 08/07/2003Software Verification and Validation Plan SS/DEBAT/SVVP 1.1 14/10/2003Software Verification and Validation Plan SS/DEBAT/SVVP 2.0 15/11/2003Acceptance Test Plan SS/DEBAT/ATP 1.0 15/11/2003




Detailed Design Document SS/DEBAT/DDD 1.0 14/10/2003Detailed Design Document SS/DEBAT/DDD 1.1 17/11/2003Design Technical Note SS-DEBAT-DD_TN 1.0 14/10/2003EAST Language Changes SS-DEBAT-ELC 1.0 14/10/2003EAST Language Changes SS-DEBAT-ELC 1.1 17/11/2003
