debat development of east based access tools project...

DEBAT – Development of EAST Based Access Tools

DEBAT Development of EAST Based Access ToolsProject Management Plan

Contract : 16562/02/I-LGReference : SS/DEBAT/PMPIssue : 1.1Date : 31/10/2002

Prepared by :

Carlos GuerreiroDate :

Checked by :

Jean-Yves SouillardDate :

Approved by :

Alain RousselDate :

DEBAT Project Management Plan

Reference : SS/DEBAT/PMP Issue : 1.1 Date : 31/10/2002 Page : i


Document Status Sheet

Document Title DEBAT Project Management PlanDocument Reference Number SS/DEBAT/PMPIssue Revision Date Reason for change

1 0 15/10/2002 First issue of the PMP for Phase 1 of the project1 1 31/10/2002 Integration of comments from ESA


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 Page : ii


Document Change Records

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

Page Paragraph Reason for changeAll First issue

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

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


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 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 .................................................................................................. 52.5 ORGANISATIONAL ROLES AND RESPONSIBILITIES......................................................................... 7

2.5.1 The Project Director ............................................................................................................ 72.5.2 The Project Manager ........................................................................................................... 72.5.3 The technical manager......................................................................................................... 82.5.4 The Experts.......................................................................................................................... 82.5.5 The Development Team ....................................................................................................... 8

2.6 ORGANISATIONAL BOUNDARIES AND INTERFACES ....................................................................... 82.6.1 Communications with ESRIN............................................................................................... 82.6.2 Relation to CNES EAST project .......................................................................................... 9

3. MONITORING AND CONTROL............................................................................................. 10

3.1 MEETING AND REPORTING......................................................................................................... 103.1.1 Meetings ............................................................................................................................. 103.1.2 Reporting............................................................................................................................ 10

3.2 SCHEDULE REPORTING AND CONTROL....................................................................................... 113.3 RISK MANAGEMENT AND REGISTER ........................................................................................... 11

4. LICENSES ISSUES ..................................................................................................................... 12

4.1 PRINCIPLES OF THE DEBAT DEVELOPMENT AND LICENSE........................................................ 124.2 TERMS OF THE PROPOSED LICENSE............................................................................................. 13

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


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 Page : iv


5.1 OBJECTIVES ............................................................................................................................... 145.2 WORK BREAKDOWN STRUCTURE............................................................................................... 155.3 DEVELOPMENT PLAN, WORK LOGIC AND ACTIVITIES ................................................................. 16

5.3.1 Requirements collection and technical analysis ................................................................ 185.3.2 Implementations................................................................................................................. 215.3.3 DEBAT definition ............................................................................................................... 215.3.4 Support to user group ........................................................................................................ 225.3.5 Promotion .......................................................................................................................... 23

5.4 SCHEDULE, MEETINGS AND DELIVERIES..................................................................................... 255.4.1 Schedule ............................................................................................................................. 255.4.2 Meetings ............................................................................................................................. 255.4.3 CS Deliveries and Customer Furnished Items................................................................... 26

5.5 WORK PACKAGES DESCRIPTION................................................................................................ 27

6. PHASE 2 - IMPLEMENTATION PHASE............................................................................... 61

6.1 OBJECTIVES ............................................................................................................................... 616.2 WORK BREAKDOWN STRUCTURE............................................................................................... 616.3 WORK LOGIC AND ACTIVITIES.................................................................................................... 616.4 DEVELOPMENT METHODOLOGY AND TOOLS .............................................................................. 616.5 SCHEDULE AND DELIVERIES....................................................................................................... 616.6 WORK PACKAGES DESCRIPTIONS .............................................................................................. 61

7. WARRANTY PHASE................................................................................................................. 62

7.1 WARRANTY PRINCIPLES............................................................................................................. 627.2 WARRANTY ACTIVITIES ............................................................................................................. 62

8. PRODUCT TREE........................................................................................................................ 63

9. DOCUMENTATION TREE....................................................................................................... 64

10. PROJECT HISTORY DOCUMENT....................................................................................... 65

11. ANNEX: DEBAT SOFTWARE LICENSE (ENGLISH)....................................................... 66

12. ANNEX: DEBAT SOFTWARE LICENSE (FRENCH)........................................................ 67


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 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 ................................................................................ 15Figure 5-2 Analysis and studies phase ( phase 1).............................................................................. 16Figure 5-3 Requirements collection and technical analysis work logic ............................................ 18Figure 5-4 Phase 1 interviews methodology...................................................................................... 19Figure 5-5 DEBAT definition work logic.......................................................................................... 21Figure 5-6 Detailed schedule of DEBAT Phase 1 ............................................................................. 25


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 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.1 Date : 31/10/2002 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 ToolOSAT 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.1 Date : 31/10/2002 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 EngineeringStandards – Software

ECSS-E-40B

AD6 ECSS - Space EngineeringStandards - Software ProductAssurance

ECSS-Q-80B


Reference : SS/DEBAT/PMP Issue. : 1.1 Date : 31/10/2002 Page : ix


Reference Documents

Title Issue Date ReferenceRD1 DEBAT Product Assurance Plan 1.0 14/10/2002 SS/DEBAT/PAP


Reference : SS/DEBAT/PMP Issue : 1.1 Date : 31/10/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 ofenhanced tools built upon EAST technologies to provide engineers, scientists and end-users withpowerful 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 potentialuser community (existing fields of application or new ones) by making them aware of theavailability and advantages of these enhanced tools (DEBAT workshop, Web site, demonstrationkit,…).

The underlying philosophy is to build on the knowledge and capitalised experience gained duringprevious developments (CNES, CS and ESA) being carried out for several years, to take advantageof the lessons learned from current/past EAST user projects (limitations, expectations), and to takeinto 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-knowndomains where the degree of confidence is high due to past experience. The final results ofthese developments are expected to be high quality software: reliable, well engineered, userfriendly, properly documented and flexible.

• TM/TC fields of application: this covers the application of EAST technologies to TM/TCprocessing which is a new and critical domain that requires in depth analysis. The mainobjective 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 theTM/TC arena.

1.2 Objectives of the document

This Project Management Plan is intended to define, organise, monitor and control all the activitiesto 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.1 Date : 31/10/2002 Page : 2


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

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 withthe 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, togetherwith 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: Product treeThis chapter gives the breakdown of the DEBAT software in its main units.

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

Chapter 10: Project History DocumentThis section describes the contents of the project history document.

Annexes 11 & 12: DEBAT software licenseGives the licenses of the DEBAT software (in English and in French).

1.4 Evolution of the Project Management Plan

This Project Management Plan will be updated as necessary throughout the project, and at least forthe 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 andranking of the limitations of the current tools set and expected enhancements for fulfillingthe expressed requirements, the identification of other areas of work that might becomecandidates for future work, and the production of an overall implementation and diffusionplan.

• "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 12months . A negotiation period is foreseen between the two phases in order to consolidate the priceof phase 2 (an Authorisation To Proceed - ATP - is required to proceed with Phase 2). The expectedtotal duration of the project is 18 months .

A warranty period of 6 months is foreseen at the end of the project. This warranty period beginsafter a check-out period of 3 months (the check-out period beginning at the Acceptance Review ofthe 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 meeting




M11 - 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 theactivities to be performed at his premises and by ESRIN for activities to be performed at ESRINfacilities (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

The following diagram presents the 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 Jean-Yves SOUILLARD.

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 projectwith 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 theperson

Function withinthe project

Competence fields Amount of timededicated to the

project (%)AlainROUSSEL

Project Director 19 years experience onproject management.

Support to ProjectManagement

CarlosGUERREIRO

Project Manager Architectures,JAVA/CORBA: he’scurrently in charge of theSpace Studies Direction ofProjects.

Project Management

LaurentCOHEN

TechnicalManager andResponsible forAdvancedTechnologies

Advanced technologies(Java, Web Services)

100%

FrédéricBERRIRI

Responsible forEAST/OASIScore technologies

EAST/OASIS: he iscurrently the EAST projectmanager (CNESmaintenance contract)

75% DEBAT project25 % EAST

Maintenance Contract(CNES)

OlivierQUEYRUT

Responsible forTM/TC activities

TM/TC, SCOS-2000. 100%




ClairePELLIZZARI

EAST expert EAST/OASIS: she has morethan 8 years experience ofEAST.

50% DEBAT project50% EAST


JérômeFERREIRA

Design/Development team

EAST/OASIS: he has beenworking on EAST/OASISsince 09/2001(EAST/OASIS CNESmaintenance contract).

75% DEBAT project25% EAST


JérômeCANDAT

Design/Development team

XML/JAVA 100%

LucMAISONOBE

Freeware expert Specialist of thefreeware/open source issues.

1 day per month

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 andproviding assistance. He delegates management of the project to the project head and supervises theoperation 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 withinthe team assigned to the project, defines responsibilities and rules on possible conflicts. He submitsall decisions which are his responsibility to Customer and ensures that they are then carried out. Theproject head plays a significant part in technical development so that he grasps the whole projectperfectly:

• he ensures that the project consistently complies with the design specifications and also withthe 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 fromthe 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 forchoosing the ways in which to produce different system components. This involves:

• providing technical support to team members during prototyping, design and productionphases,

• 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 thetechnologies involved. She is aimed at giving his expertise to assist the development team in thedifferent phases of the project from the requirement analysis to the design choices andimplementation.

2.5.5 The Development Team

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

• designing and implementing software elements, then participating in testing, integrating andvalidating 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] )Carlos Guerreiro([email protected] )

Administrative, financialmatters

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, EASTInterpreter and Generator and OASIS. CNES has a maintenance contract for EAST technology (atthe 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 orderto ensure that CNES EAST technology corrections and evolutions (issued from the maintenancecontract) and DEBAT EAST evolutions (issued from DEBAT project) will be compatible (the ideais to provide an unique EAST core version at the end of DEBAT, i.e. maintaining compatibilitybetween DEBAT EAST developments and CNES EAST developments, and notably backwardcompatibility).

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 thatCNES 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 (sourcescode, documentation, installation procedures, etc.) for technical analyses/studies.

• Another delivery of EAST technology is expected at ATP (start of phase 2) including thecorrections/modifications issued from the CNES EAST maintenance contract.

• Other possible deliveries could be considered depending on the corrections/evolutionsissued from the maintenance contract. For instance, at ATP+4 and FAR-1 (one month beforeFAR).

• Some internal meeting (between CS DEBAT team and CS EAST team) will be held in orderto 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 aboutthe orientations of DEBAT.




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, CStakes 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 themeeting, at least 5 days before the latter takes place. The documentation required to supportdecisions to be discussed in the course of the meeting are made available to the ESA technicalofficer 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 andacceptance, and the preparation of the milestone report. If applicable, the review is held by slidesand 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 andcontrol 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 followingelements:

• 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 forthe 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 andmonthly reported to ESRIN. Monthly Progress Reports will include the updated schedule accordingto 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 theexpected deliveries.

3.3 Risk management and register

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

Identifier Description Probability Impact Possible action

R1 Availability of informationDEBAT project is strongly based uponefficient collection of information fromseveral sources: interviews (users group,selected people for interviews,…),documentation (selected set ofmissions/projects, TM/TC arena, otheroutcome,…), etc.The access to the related information isconsidered as critical.

Low High The informationshould be madeavailable to CS assoon as possible tobe taken intoaccount (at thebeginning of theproject for theavailabledocumentation).

R2 Tight scheduleThere is a risk associated to the shortness ofthe schedule (the duration of first phase isonly 5 months of the total 18 monthsproject). This can be a too short period toperform all the required work.

High Medium Pragmatic workingprinciples shouldallow to focus onessential work Theexact scopes of thestudies shall beclearly defined.




4. Licenses issuesThis section presents, in its first part, principles for the DEBAT development and license, takinginto account the CNES property on the EAST/OASIS software, which constitutes an importantbasis 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 forthe DEBAT developments. It is ready to authorise the improvements of EAST/OASIS codein order to integrate DEBAT requirements. This point is to be formalised in a licensecontract between CS and CNES in the early stages of the project. This license contract willbe 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 useor redistribute the EAST/OASIS software in its binary form (without any fee), but themodification 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 bya 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 notmodified for DEBATproject

EAST/OASIS filesmodified forDEBAT project

Files specificallydeveloped for DEBATproject

Property CNES CNES CS SI

Applicablelicense

EAST/OASIS freewarebinary form

EAST/OASISfreeware binaryform

CS freeware binaryform

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




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

4.2 Terms of the proposed license

The following lines are intended to summarise briefly the DEBAT license.

The licenses of the various parts of the product are attached to this proposal (see chapter 11 andchapter 12), they are the ultimate references. As a summary, we can say that the DEBAT “freeware-in-binary-form” license (composed of EAST/OASIS license and CS licence) basically allowsanybody to use or redistribute the binaries. Modification is not allowed (the source code is notprovided).




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 limitationsof the current EAST tools and the potential evolutions and enhancements able to respondadequately 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 ofexisting functionalities versus a set of selected projects/missions, taking into account therequirements 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 potentialadded-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-1 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-2 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 newusers.

• Within current domains of application of EAST technology ( “EAST existing tools familyWP-122000), the research for new requirements and limitations is achieved byimplementing EAST format descriptions of the following data formats and by analysing thework done and the results obtained in order to identify the limitations and requiredenhancements:§ CryoSat,§ Envisat (MERIS, SCIAMACHY),§ AMS2,§ CDDP (CNES).




• Within the new TM/TC domain (“EAST for TM/TC processing” WP-123000), theresearch 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 SystemRequirements 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/TCactivities.

• DEBAT framework MMI mock-ups: these mock-ups allows to get early users feedback onthe future DEBAT MMI.

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

• A first step allows to define the more relevant implementation subset (to be agreed by ESAduring negotiation phase),

• The second step covers the preparation of the second phase by providing an overallimplementation/diffusion plan and identifying interesting areas of future work (beyond thescope 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 technicalcontents 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 collectionand technical analysis” activity. For each activity, it shows the inputs as well as the outputs of thetasks to be done.

Figure 5-3 Requirements collection and technical analysis work logic




5.3.1.1 Interviews stageThe main activities to be carried out during the interview stage are sketched hereafter:

Figure 5-4 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 formis defined by CS and is approved by ESA before diffusion. This interview form shall at leasttake 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/designfactors (modularity, flexibility, openness, reliability, user-friendliness, …) as well assoftware quality factors (quality of documentation, …),

§ a market-perspective point of view including cost-efficiency analysis, gainedproductivity against other solutions (in-house or commercial products), etc.,

§ a free opinion column to leave enough freedom to people for expressing less-formalisedfeedback,

This activity will also permit to select the people to be interviewed. The list of the foreseenpeople is to be defined in the early stages of the project. The interviewed people list wouldpreferably 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 byphone or email). Furthermore, a mission to ESRIN is foreseen in the frame of the proposalin 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 rawcollected forms in order to extract and rationalise the main expressed limitations of EASTtechnology and the main expected requirements of DEBAT.

5.3.1.2 Identification and technical analysis of required enhancements andlimitations

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

• In the current fields of application of EAST technology, the research for limitations and newrequirements is achieved by implementing data descriptions of some selected data formatsas 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 attentionto SCOS-2000), the research for limitations and new requirements is achieved byimplementing the EAST descriptions of the generic PUS Service 11 and byimplementing/specialising this generic description for CryoSat Service 11.

• Results coming from other related projects (CNES, ESA, ASTRIUM, others) such asAriane, Helios, ATV, … using (or potentially interested) shall be considered if available inthe early stages of the project.

• CS EAST team will be involved in this process so as to optimise it. Our team keeps constantinteraction with end users and therefore has a good knowledge of limitations andrequirements from both a technical and an user point of view.

The results obtained from the implementations of EAST data descriptions done during theseactivities are gathered in a Technical Note (TN-1 in the diagram Figure 5-3 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 alsodetailing the methodology used for the requirements collection and technical analysis.

5.3.1.3 Compilation of wish listThis task is aimed at compiling with an adequate methodology (abstraction, synthesis, rationalisingprocess, selection process) all the results gathered during the previous tasks in a set of “userrequirements” that, if implemented, would be a suitable response to the needs of the projects takenas input.The outputs of this tasks are:

• an User Requirements Document (URD) detailing the features that satisfy the identifiedneeds.

• a Technical Note (TN-2 in the diagram Figure 5-3 Requirements collection and technicalanalysis work logic ) describing the methodology used to compile the wish list (abstractionmethodology, 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, sharingdata types between several data descriptions, function that is not available in the currentEAST tools).

• DEBAT framework MMI mock-ups: the DEBAT framework MMI is aiming at providingusers with a single entry point (highly customisable and very user-friendly) to all theDEBAT 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 technicalanalysis” task.

Figure 5-5 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 welldefined (potentially with priority levels assigned to them), the evaluation of each item in thewish list can be done according to the criteria table, in order to find the “added-value” ofeach item in the list. This evaluation shall take into account the outcomes from the DEBATworkshop and shall be carried out with close interactions with the users group. The cost ofeach item has also to be defined.

• A “Trade-off” between cost and potential added-value is the logical next step in order tochoose among the evaluated items.

• The “Constitution of implementation subset” allows the selection of the most costeffective and relevant subset for the implementation. This task also includes theconsolidation of external requirements, such as any constraints, validation and verificationrequirements 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 andValidation Plan (IDVP) that gives the suggested logical plan of developments. This planshall also contain an outline plan for the completion of the data format description analysedduring the “Requirements collection and technical analysis” phase, as well as an outline planfor “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 usersgroup is intended to provide from an end-user point of view:

• its appraisal and assessment of the orientations given to the DEBAT tools (envisagedchanges, critical choices),

• some suggestions, needs or expected enhancements to be taken into account in the frame ofDEBAT 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 efficientcontacts with the users group, the following is envisaged:

• the documents produced in the course of the project are diffused to the users group in orderto get its appraisal and early feedback (when possible the draft versions of the documentswill be made available to the users group in order to get its early comments),

• periodic reports gathering major information (orientations, choices, design,…) are sent tothe 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 usersgroup and the DEBAT team: these exchanges could be published in a private area on theDEBAT Web site in order to allow an easy access for the users group.

5.3.5 Promotion

5.3.5.1 Support to workshopA workshop at ESTEC is foreseen around the end of phase 1 to make the interested communityaware of EAST tools and DEBAT enhancements derived from this project.CS will contribute to this workshop providing presentations about the outcome of the requirementsinvestigations and the foreseen developments, and collecting some early user feedback, as well asproviding some technical support (publication of collected presentation on the Web and possiblyshort demonstrations).

5.3.5.2 Project Web pagesA Web site for ensuring the promotion of EAST/DEBAT technology has to published on an ESAserver in order to illustrate the objectives and context of DEBAT project, as well as the progress andoutputs 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.

5.3.5.2.1 Phase 1




A small set of pages will be published on an ESA Web server following the ESA guidelines andtemplates. 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 theproject. These pages will be made available (published) for the end of October. These pages willpoint to the CNES EAST site allowing to get more detailed information about the current EASTtools.

A more detailed set of pages will also be set-up. These pages will be published on a CS Web serveras soon as it will be available (probably, at the beginning of year 2003). Until this server isavailable, these pages will be published on a temporary ESA Web server, and will be then moved tothe 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 ofthese pages is expected for the SRR review.

5.3.5.2.2 Phase 2

The Web pages produced during phase 1 will be updated during the second phase of the project, tohighlight the progress/outputs of the project.Updates to the project pages are justified by the following events:

• Reviews,• New publications,• Availability of new tools,• Other project events.

This clause will be completed for Phase 2.




5.4 Schedule, meetings and deliveries

5.4.1 Schedule

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

Figure 5-6 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 thelocation and the duration of each meeting.

Meeting Purpose Duration(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" tobe 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 CryoSatService 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 forinterviews at ESRIN.

M2 ProgressProgress Report

M3 SRR (System RequirementsReview)“Requirements CollectionTechnical Note”Preliminary EAST descriptionsproduced during technicalanalysis (if any)URD“Selection Process MethodologyTechnical Note”Milestone reportProduct Assurance Report

M4 Workshop at ESTECCS PresentationsDemonstrations (if any)

The organisation of the workshop is done byESA/CNES.

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




Meeting CS deliveries ESRIN deliveries

Web pagesMilestone reportProduct Assurance Report

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

Document Requirement SRR End ofP1

PDR CDR ARCustomerapprovalon file

PackageFile

URD User RequirementsDocument

X URD

SRD Functions and performancerequirements of the system

X SRD RB

SRDDesign constraints and

verification and validationrequirements

XSRD RB

SRD Interface requirements X SRD RB

5.5 Work Packages Description

In the following pages, the contents of each work-package are described in a Work PackageDescription sheet so as to detail the work to be performed for each activity.




WORK PACKAGE DESCRIPTION form no. pss-a-20

PROJECT: DEBAT PHASE: 1 WP: 110000

WP TITLE: Project Management Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KOFINISH EVENT: End of Phase 1 Planned finish

date:KO + 5,5

WP MANAGER: C. GuerreiroEFFORT:Items Required to Start the WP:

• DEBAT SOW and DEBAT CS Proposal• Documentation/samples of data for: CryoSat, Envisat (MERIS, SCIAMACHY),

AMS2, CDDP.• Documentation for PUS Service 11 and CryoSat Service 11.• Initial list of target people for interviews (ESRIN/CS/CNES)• Initial list of members for users group• ESA web pages templates or guidelines• EAST/OASIS product release from CNES (including sources)• Outcomes from related projects (if available)

Tasks Description:• Project Management• Progress reports• Progress meetings preparation and attendance

Outputs:• Project Management Plan (first issued at TO+1, and updated all the project long)• Progress Reports• Minutes of Meetings






WP TITLE: Requirements collection & Technicalanalysis

Sheet 1 of 1

MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KOFINISH EVENT: SRR Planned finish

date:KO + 4

WP MANAGER: L. CohenEFFORT:Items Required to Start the WP:

• Documentation/samples of data for: CryoSat, Envisat (MERIS, SCIAMACHY),AMS2, CDDP.

• Documentation for PUS Service 11 and CryoSat Service 11.• List of people to be interviewed

Tasks Description:• Interviews§ Research for limitations and requirement by interviewing current/new users

• EAST existing tools family analysis§ Research for limitations and requirements by implementing EAST data descriptions

for the following data: CryoSat, Envisat, AMS2, CDDP§ Analysis of work done and results

• EAST for TM/TC processing§ Research for limitations and requirements by implementing a generic EAST

description of PUS Service 11 and by instantiating this generic description forCryoSat Service 11.

§ Analysis of work done and results

• Compilation of wish listOutputs:

• “Requirements Collection Technical Note” (containing problems used as inputs, list ofdifficulties, shortcomings, etc.… encountered in the use of EAST formalism an of therelated tools).

• EAST descriptions produced during the WP• URD (User Requirements Document)• “Selection Process Methodology Technical Note” (explaining which methodology has

been used to produce the users requirements)






WP TITLE: Interviews Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO+4


• List of target people for interviews (ESRIN/CS/CNES):§ People from user group,§ People from current project using EAST§ People from interested community§ People from CS EAST team

Tasks Description:• Prepare the interviews: define an interview form to be approved by ESA• Execute the interviews: meet the people to be interviewed (or phone)• Exploit the interviews: analyse and perform a synthesis of the raw collected form to

extract and rationalise the expressed limitations and requirementsOutputs:

• Expressed limitations and requirements to be included in the “Requirements CollectionTechnical Note” and in the URD.






WP TITLE: Interviews preparation Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO+1

WP MANAGER: L. CohenEFFORT:

Items Required to Start the WP:

Tasks Description:• Prepare the interview form (to be approved by ESA) containing at least:§ User point of view: expression in term of functionalities, limitations and needs§ Technical point of view: known problems, performances, architectural design

factors, …§ Market perspective point of view: costs, productivity, competitors…§ Free opinion column

Outputs:• Interview form






WP TITLE: Interviews execution Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KO+1FINISH EVENT: SRR Planned finish

date:KO+3


• Availability of people to be interviewed• Interview form approved by ESA

Tasks Description:• Diffuse/perform the interviews by meeting (preferably) the persons to be interviewed

(or by phone/mail if meeting is not possible)• Perform a mission to ESRIN in order to meet current and potential interested users of

EAST technologyOutputs:

• Filled forms collection






WP TITLE: Interviews exploitation Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KO+3FINISH EVENT: SRR Planned finish

date:KO+4


• Raw filled forms collection

Tasks Description:• Analysis and synthesis of the raw collected form in order to extract and rationalise the

main expressed limitations and requirements

Outputs:• Expressed limitations and requirements to be included in the “Requirements Collection

Technical Note” and in the URD ”wish list”• Technical analysis of the limitations/ required enhancements to be included in the

“Requirements Collection Technical Note”






WP TITLE: EAST existing tools family Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 4

WP MANAGER: F. BerririEFFORT:Items Required to Start the WP:

• Documentation / samples of data for: CryoSat, Envisat (MERIS, SCIAMACHY),AMS2, CDDP.

• OASIS modeller tool

Tasks Description:• Implement the EAST data descriptions of the following data: CryoSat, Envisat

(MERIS, SCIAMACHY), AMS2, CDDP.• Analyse the work done and results to highlight limitations and new requirements

Outputs:• EAST data descriptions of selected data• Encountered limitations and new requirements to be included in the “Requirements

Collection Technical Note” and in the URD ”wish list”• Technical analysis of the limitations/ required enhancements to be included in the







WP TITLE: Implementation of selected datadescriptions (CryoSat, Envisat, AMS2,CDDP)

Sheet 1 of 1

MAJORCONSTITUENT:

Issue 1


date:KO + 3


• Documentation/samples of data for: CryoSat, Envisat (MERIS, SCIAMACHY),AMS2, CDDP.

• OASIS modeller tool

Tasks Description:• Perform the implementation of EAST data descriptions for the following data with

OASIS tool:§ CryoSat,§ Envisat (MERIS, SCIAMACHY)§ AMS2§ CDDP

Outputs:• EAST data descriptions of data






WP TITLE: Analysis of work done and results,Identification of limitations/requiredenhancements

Sheet 1 of 1

MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KO + 3FINISH EVENT: SRR Planned finish

date:KO + 4


• Work done in WP 122100• EAST data descriptions produced in WP 122100

Tasks Description:• Analyse the work done in WP 121100 and the results obtained• Identify the limitations and required enhancements• Perform the technical analysis of limitations/new requirements

Outputs:• Encountered limitations and new requirements to be included in the “Requirements








WP TITLE: EAST for TM/TC processing Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 4

WP MANAGER: O. QueyrutEFFORT:Items Required to Start the WP:

• Documentation for PUS Service 11 and CryoSat Service 11.• OASIS modeller tool

Tasks Description:• Model the generic PUS Service 11 with EAST• Model the CryoSat Service 11• Analyse the work done and results to highlight limitations and new requirements

Outputs:• EAST data descriptions of PUS Service 11 and CryoSat Service 11• Encountered limitations and new requirements to be included in the “Requirements


Requirements Collection Technical Note”






WP TITLE: PUS Service 11 modelling Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 1,5


• Documentation for PUS Service 11• OASIS modeller tool

Tasks Description:• Implement the EAST generic description of PUS Service 11 (directly from the book)

with OASIS tool

Outputs:• EAST implementation of PUS Service 11






WP TITLE: CryoSat Service 11 modelling Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KO + 1,5FINISH EVENT: SRR Planned finish

date:KO + 3


• EAST generic implementation of PUS Service 11 produced in WP 123100• Documentation for CryoSat Service 11• OASIS modeller tool

Tasks Description:• Perform the implementation of CryoSat Service 11 starting from the generic

description of PUS Service 11.

Outputs:• EAST implementation of CryoSat Service 11






WP TITLE: Analysis of work done and results,Identification of limitations/requiredenhancements

Sheet 1 of 1

MAJORCONSTITUENT:

Issue 1


date:KO + 4


• Work done in WP 123100 and WP 123200• EAST data descriptions produced in WP 123100 and WP 123200

Tasks Description:• Analyse the work done in WP 123100 and WP 123300 and the results obtained• Identify the limitations and required enhancements• Perform the technical analysis of limitations/new requirements

Outputs:• Encountered limitations and new requirements to be included in the “Requirements








WP TITLE: Compilation of wish list Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 4


• Outputs from WP 121000, WP 122000, WP 123000

Tasks Description:• Compile with an adequate methodology (abstraction, synthesis, rationalising process,

selection process) all the results gathered during WP 121000, WP 122000, WP 123000in a set of “user requirements”.

Outputs:• “Requirements Collection Technical Note” (containing problems used as inputs, list of

difficulties, shortcomings, etc.… encountered in the use of EAST formalism an of therelated tools).

• URD (User Requirements Document)• “Selection Process Methodology Technical Note” (explaining which methodology has

been used to produce the users requirements)






WP TITLE: Implementations Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• Current OASIS modeller tool (with sources)

Tasks Description:• Implementation of OASIS type library concept• Implementation of DEBAT framework MMI mock-ups

Outputs:• OASIS tool enhanced with types libraries• Mock-ups of DEBAT framework MMI






WP TITLE: Framework MMI mock-ups Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: SRR Planned start date: KO + 4FINISH EVENT: End of Phase 1 Planned finish

date:KO + 5,5

WP MANAGER: J. FerreiraEFFORT:Items Required to Start the WP:

Tasks Description:• Specify and design DEBAT framework (partially)• Implement DEBAT framework MMI mock-ups• Test, validate and diffuse to users and users group to get early feedback.

Outputs:• Mock-ups of DEBAT framework MMI• Collected feedback from users group






WP TITLE: OASIS types library Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 4


Tasks Description:• Specify and design the OASIS type library concept• Implement the OASIS type library concept• Test and validate

Outputs:• OASIS tool enhanced with types libraries






WP TITLE: Acceptance tests Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 23/09/2002

START EVENT: M5 (end of P1meeting)

Planned start date: KO + 5

FINISH EVENT: M5 (end of P1meeting)

Planned finishdate:

KO + 5


• OASIS modified to implement the type library concept

Tasks Description:• Perform the acceptance tests of the developments of OASIS type library concept

Outputs:• OASIS enhanced with type libraries






WP TITLE: DEBAT definition Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• URD (User Requirements Document) from WP124000• Technical Notes produced from previous WP’s

Tasks Description:• Selection of implementation subset§ Evaluation of each requirement§ Trade-off for the implementation§ Constitution of the implementation subset

• Preparation of Phase 2§ Implementation / validation / diffusion plan§ Identification of areas of future work

Outputs:• SRD (System Requirements Document)• “Implementation Plan” (including also an outline plan for the completion of the data

format description with EAST and an outline plan for the TM/TC prototypingactivities).






WP TITLE: Selection of implementation subset Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5


• User Requirements Document produced in WP 124000• Technical Notes produced from previous WP’s

Tasks Description:• Select the implementation subset for phase 2 by evaluating each requirement collected

from previous work (interviews, EAST descriptions, EAST for TM/TC processing), byperforming a trade-off between cost and added-value, and by constituting the mostcoherent and relevant subset to implement.

Outputs:• Implementation subset list to be included in “Implementation Plan”






WP TITLE: Evaluation of each requirements Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5


• User Requirements Document

Tasks Description:• Define a criteria table to evaluate each requirement (to be approved by ESA)• Evaluate each requirement according to the criteria table• Rank each requirement added-value and cost of implementation

Outputs:• Criteria table for evaluation• List of ranked requirements






WP TITLE: Trade-off for the implementation Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5


• List of ranked requirements

Tasks Description:• Perform a trade-off between cost and added value for each requirement in order to

chose among theme the most relevant and cost-effective ones.

Outputs:






WP TITLE: Constitution of the implementation subset Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5


• Outputs from previous WP (WP 141200, WP 141100)

Tasks Description:• select the most cost effective and relevant subset for implementation taking into

account the evaluation of each requirement and the trade-off between cost and added-value.

• Consolidate the external requirements such as any constraints, validation andverification requirements, interface requirements,…

Outputs:• Implementation subset list to be included in “Implementation Plan”• “Design Constraints and Verification Requirements” and Interface Requirements to be

included in SRD






WP TITLE: Preparation of Phase 2 proposal Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: SRR Planned start date: KO + 4,5FINISH EVENT: End of Phase 1 Planned finish

date:KO + 5,5


• Implementation subset from WP 141000

Tasks Description:• Produce an implementation, diffusion and validation plan that gives the suggested

logical plan of developments for Phase 2 including an outline plan for TM/TCactivities in Phase 2. This implementation plan is subject to ESA approval and will benegotiated between ESA and CS.

• Identify areas of future wok that will not be covered in the frame of DEBAT project

Outputs:• “Implementation Plan”• Areas of future work






WP TITLE: Implementation / Validation / DiffusionPlan

Sheet 1 of 1

MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: SRR Planned start date: KO + 4,5FINISH EVENT: End of Phase 1 Planned finish

date:KO + 5,5


• Implementation subset from WP 141000• Negotiation/approval from ESA

Tasks Description:• Produce an implementation, diffusion and validation plan that gives the suggested

logical plan of developments for Phase 2.

Outputs:• “Implementation Plan” including also an outline plan for the completion of some other

data format description with EAST (for demonstration purposes) and an outline planfor the TM/TC prototyping activities.






WP TITLE: Identification of areas of future work Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• Implementation subset from WP 141000• Requirements not selected for implementation in Phase 2

Tasks Description:• Identify the areas of future work that will not be covered in the frame of DEBAT

project

Outputs:• Areas that might become candidate for future work






WP TITLE: Support to User Group Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• List of members of users group

Tasks Description:• Report to the group :§ periodically inform the group about the status of the project (changes, orientations,

choices, design, …)• Analysis of inputs from the group:§ collect suggestions, needs, expected enhancements and appraisal/assessment of the

status and orientations of the project§ collect its evaluation of final tools and results

• Set-up a mailing-list/publishing mechanism in order to track the exchanges between theusers group and the DEBAT team

Outputs:• Reports to the group (documents produced, periodic reports)• Collected and analysed inputs coming from the group.• Mailing-list and publishing mechanism to support the interactions with user group






WP TITLE: Report to the group Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• List of members of users group

Tasks Description:• Report to the group:§ diffuse the documents produced in the course of the project to the users group in

order to get its appraisal and early feedback (when possible the draft versions of thedocuments will be made available to the users group in order to get its earlycomments),

§ diffuse periodic reports gathering major information (orientations, choices,design,…) to the group,

Outputs:• DEBAT documents• Periodic reports.






WP TITLE: Analysis of inputs from the group Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• Finalised list of members of users group

Tasks Description:• Analysis of inputs from the group:§ collect suggestions, needs, expected enhancements and appraisal/assessment of the

status and orientations of the project§ collect its evaluation of final tools and results§ invite the user group to the major milestones§ set-up a mailing-list mechanism in order to track the exchanges between the users

group and the DEBAT team: these exchanges could be published in a private areaon the DEBAT web site in order to allow an easy access for the users group

Outputs:• Collected and analysed inputs coming from the group.• Exchanges tracked and published in a private area of DEBAT web site• Mailing-list and publishing mechanism to support the interactions with user group






WP TITLE: Promotion Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5


• ESA web pages templates and guidelines• Access to an ESA web server• ESTEC workshop organisation by ESA/CNES

Tasks Description:• Support to workshop• Project Web pages

Outputs:• Collected presentations, converted to a form suitable for publication on the Web• Plan for content and update schedule of the Project Web pages (included in PMP)• Published Web pages






WP TITLE: Support to workshop Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KO + 4,5FINISH EVENT: End of Phase 1 Planned finish

date:KO + 5


• ESTEC workshop organisation by ESA/CNES

Tasks Description:• Support to workshop§ Produce presentations of the outcome of the requirements investigation§ Produce presentations/demonstrations of the foreseen developments§ Collect some early feedback during the workshop§ Provide technical support (publish the collected presentation on DEBAT web site)

Outputs:• Presentations/demonstrations for the workshop• Collected presentations, converted to a form suitable for publication on the Web






WP TITLE: Project Web Pages Sheet 1 of 1MAJORCONSTITUENT:

Issue 1

CONTRACTOR: CS Date 16/06/2002START EVENT: KO Planned start date: KOFINISH EVENT: End of Phase 1

meetingPlanned finishdate:

KO + 5,5


• ESA web pages templates and guidelines• Access to an ESA web server

Tasks Description:• Project Web pages:§ Promote the use of DEBAT technology§ Illustrate the objectives and context of DEBAT project§ Give indication of status/progress and outputs of the activities performed§ Allow readers to express desirable requirements by the means of a simple form

Outputs:• Plan for content and update schedule of the Project Web pages (included in PMP)• Published Web pages






WP TITLE: Product Quality Assurance Sheet 1 of 1MAJORCONSTITUENT:

Issue 1


date:KO + 5,5

WP MANAGER: J.Y. SouillardEFFORT:Items Required to Start the WP:

• DEBAT project SOW• DEBAT project CS Proposal• CS generic PAP

Tasks Description:• Quality Assurance Management• Quality Assurance Controls

Outputs:• Product Assurance Plan (first issued at TO+1, and updated if needed)• Product Assurance Reports for SRR and “End of Phase 1 meeting” .




6. Phase 2 - Implementation phaseThe following will be completed for phase 2.

6.1 Objectives

6.2 Work breakdown structure

6.3 Work logic and activities

6.4 Development methodology and tools

6.5 Schedule and deliveries

6.6 Work Packages Descriptions




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 ofCNES are not covered by this warranty, as CNES has a maintenance contract on EAST/OASISproducts.

If for any reasons, the CNES maintenance contract for EAST/OASIS was not continued, we assumethat CNES will make EAST/OASIS source code available to the public domain: in this case, aspecific maintenance contract should be negotiated for also ensuring the maintenance ofEAST/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 relateddocumentation and tests.

The warranty phase is aiming at ensuring the correction of the software problems that may ariseafter 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 anelectronic patch delivered electronically).

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




8. Product treeThis section gives a decomposition of the DEBAT software in its main units.

This section will be completed during the second phase of the project.




9. Documentation treeThe following picture depicts the organisation of the documentation produced in the frame of theproject.A document repository has been set-up on an ESA server in order to gather all the documentsproduced in the frame of the project : this document repository is host on styx.esrin.esa.it.

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

Kick-off Minutes /CRR/SS/DEBAT/001

Monthly Progress Reports / Milestone ReportSS/DEBAT/MPR/001 14/10/2002

DEBAT user group Progress ReportsSS/DEBAT/PR/001 10/10/2002

Product Assurance Reports

Delivery NotesSS/DEBAT/DN/001 15/10/2002

TechnicalInterviews Form SS/DEBAT/IF 1.0 15/10/2002Interviews Technical Note SS/DEBAT/I_TNEAST for TM/TC Technical Note SS/DEBAT/TMTC_TNEAST current applications Technical Note SS/DEBAT/EAST_TNRequirements Collection Technical Note SS/DEBAT/RC_TNSelection Process Methodology Technical Note SS/DEBAT/SPM_TNUser Requirements Document SS/DEBAT/URDSoftware Requirements Document SS/DEBAT/SRDImplementation, Diffusion and Validation Plan SS/DEBAT/IDVP




10. Project History DocumentThis clause will be completed all the project long.




11. Annex: DEBAT software license (English)This section will be completed as soon as the licenses are available.




12. Annex: DEBAT software license (French)This section will be completed as soon as the licenses are available.