Universit PARIS XII Val de Marne

Anne 2007-2008

MASTER 2 - ISIDIS
Projet de Synthse

****

MOTEUR DE CALCUL DISTRIBUE

Contrle du projet : A. BRENNER - G. GIRAUD

I.

PRAMBULE..................................................................................................................................................................

II.

OBJECTIFS.................................................................................................................................................................

III.

SUJET...........................................................................................................................................................................

1.
2.
3.
IV.
1.
2.
3.
4.
5.

V.

PRSENTATION...............................................................................................................................................................
RFLEXION FONCTIONNELLE.........................................................................................................................................
CONTRAINTES TECHNIQUES...........................................................................................................................................
CADRE METHODOLOGIQUE................................................................................................................................
MTHODE 2TUP............................................................................................................................................................
EXECUTION DU PROJET..................................................................................................................................................
GESTION DU PROJET......................................................................................................................................................
PROCESSUS ITRATIF & PLANIFICATION........................................................................................................................
LIVRABLES.....................................................................................................................................................................
LIVRABLE............................................................................................................................................................
Prcisions sur les livrables techniques :............................................................................................................................
ORGANISATION ET RSPONSABILITS............................................................................................................

1.
2.
3.
4.
5.
6.

EQUIPES PROJET............................................................................................................................................................
RESPONSABILITS DES EQUIPES.....................................................................................................................................
MODE DE COMMUNICATION...........................................................................................................................................
COMITS DE PILOTAGE, DMONSTRATION & SOUTENANCE..........................................................................................
SYSTME DE NOTATION..................................................................................................................................................
PLANNING / GESTION DU TEMPS....................................................................................................................................

1. PRAMBULE
Ce sujet est propos dans le cadre du projet de synthse.
Les responsables pdagogiques du module sont Alexandre BRENNER
(intervenant en conduite de projet en ISIDIS et ISIAD), Gilles GIRAUD
(intervenant en architectures distribues en ISIDIS)

2. OBJECTIFS
Donner au travers de la matire, la vision dun projet men depuis la faisabilit
jusquau dploiement en passant par les tapes de conception, de ralisation
et de tests. Le projet permet lutilisation de faon transverse de la plupart des
matires enseignes dans le master.

3. SUJET
1.

PRSENTATION
Le calcul rparti est en plein essor. La plupart des grands projets de dcodage
et de recherche ncessitant dnormes puissances de calculs ont eu recours au
calcul distribu (SETI, le gnom humain, etc.)
Les groupes linitiative de ces projets ont souvent une alternative. Celle
dimplementer eux-mmes les algorithmes de rpatition des calculs et de
raliser par leurs propres moyens les programmes de communication et de
centralisation des rsultats, en plus des fonctions de calculs lies au domaine
scientifique.
La seconde possibilit est dutiliser une solution logicielle qui permet :

De grer le projet de calcul

De dfinir le calcul global (i.e. En fonction de lensemble des rsultats obtenir)
De definir le calcul lmentaire associ un ou plusieurs rsultats (i.e. Un
calcul possde des paramtres. Ces paramtres incluent des rsultats dj obtenus.
Ils peuvent tre distants s ils sont accessibles sur une ressource rpartie disponible)
De dfinir les calculs transactionnels impliquant plusieurs calculs
lmentaires eux-mmes rpartis, associs un ou plusieurs rsultats (les
calculs transactionnels impliquent donc plusieurs ressources reparties disponibles)
De dfinir des niveaux de rsultats et des rsultats intermdiaires
(ordonnancer les calculs et les rsultats).
De dfinir des temps limits pour certains calculs (par consquent
ncessitant plusieurs ressources disponibles en parrallle pour obtenir un
rsulat attendu)
De grer la disponibilit des ressources de calcul disponibles de faon
dynamique
De paramtrer les ressources pour tre disponibles que sur certains critres
(dheures, doccupation CPU, doccupation de la bande passante, etc. )

Ressource
distribue

Ressource
distribue

Ressource
distribue

Ressource
distribue

Gestion centrale
du projet de calcul rparti
Instance 1

Gestion centrale
du projet de calcul rparti
Instance 2

Gestion centrale
du projet de calcul rparti
Instance 3

Gesion centrale du projet de calcul

CLUSTER

Ressource
distribue

Ressource
distribue

Ressource
distribue

Ressource
distribue

Le calcul est lopration couteuse qui ne peut tre ralise que sur un seul
ordinateur (ressource de calcul) Pour raliser un tel calcul, on le divise en
calculs lmentaires rpartis sur plusieurs ressources rparties sur un
rseau (internet par exemple) Les calculs transactionnels sont un ensemble
de calculs raliser dans une transaction distribue dont le rsultat est celui
du calcul transactionnel. Chaque calcul lmentaire de la transaction doit tre
rparti sur plusieurs ressources rparties.
Les ressources effectuent les calculs. Elles sont disponibles selon plusieurs
critres. Soit dans une plage horaire donne, soit sur des critres de
disponibilit CPU, et bande passante.

Ressource
distribue

Ressource
distribue

Ressource
distribue

Ressource
distribue

Ressources
impliques dans
une transaction
Calculs transactionnels

Gestion centrale
du projet de calcul rparti
Instance 1

Gestion centrale
du projet de calcul rparti
Instance 2

Gestion centrale
du projet de calcul rparti
Instance 3

Gesion centrale du projet de calcul

CLUSTER

Calculs
Calculs

Ressource
distribue

Ressource
distribue

Ressource
distribue

Ressource
distribue

Les rsultats sont une abstraction. Le type de rsultat doit tre dfini lors du
paramtrage du projet de calcul. Type de rsultat : fichier texte, fichier XML,
flux doctets structur etc.
Le calcul est aussi une abstraction. En principe, le calcul est lopration
implmente par linstigateur du projet. Toutefois, le logiciel prvoit de grer
lexcution dun calcul. Le calcul peut tre implment de la faon suivante :
Un excutable, une librairie dynamique avec des points dentre dfinis, une
interface programmative implmenter, un composant distribu selon un
protocole choisi, etc.
Quelques exemples :
Dfinition dun projet de calcul :
Calcul de la trajection dune comte. Le domaine est lastrophysique.
Dfinition des calculs :
On value la trajectoire rectiligne de la trajectoire. Ceci fait partie du mtier de
lastrophysicien de le dfinir. La comte passe proximit de plantes qui
modifie sa trajectoire cause de leur gravit. Plusieurs plantes peuvent
modifier la trajectoire de la comte en mme temps, mme si la sphre
dinfluence nest pas la mme.
Premier calcul : valuation de la densit dune plante
Paramtre : circonphrence de la plante
Second calcul : valuation de la gravit de la plante
Paramtre : densit de la plante
Troisime calcul : valuation de la sphre gravitationnelle (champ
gravitationnel) dune plante.
Il faut ensuite dfinir lensemble des zones traverses par la comte. Ce sont
dans ces zones quvoluent les plantes. Une plante peut se trouver dans
plusieurs zones ou traverser des plusieurs zones en mme temps que la
comte.
Premier calcul : quation de dplacement dune plante
Seconde calcul : tunnel dinfluence gravitationnel dune plante dans une zone.
Par consquent, le calcul de la nouvelle trajectoire de la comte dans une zone
est un calcul transactionnel ncessitant plusieurs rsultats issus de calculs
pralables.
Vous dveloppez le socle logiciel (API + les programmes) de ce moteur de
calcul distribu :

Les services logiciels associs au moteur de calcul central,

Attention, le moteur est lui-mme distribu. Vous implmentez le
moteur afin quil soit peru comme une entit unique. Cependant, le
moteur doit tre implment et dploy comme un cluster logiciel o les
principes darchitecture distribue sappliquent :
-

Parralllisme transparent
Tolrance aux pannes accrue
Scalabilit logicielle
Localisation semi-automatique ou automatique des instances du cluster.

Les modules logiciels (peers) installs et excuts sur la ressource,

Les librairies de routines de communications rseau reposant sur un protocole
dinvocation,
Les objets logiciels vhiculs sur le rseau et rendus persistant.
Les interfaces gnriques permettant aux responsables du mtier (du
domaine) dimplmentez les spcificits des calculs, des rsultats, des
transactions.
Le monitorage de lensemble des activits.
Tous les autres programmes que vous jugez ncessaire dimplementer.

Vous spcifiez
permettant de :

2.

et

implmentez

une

interface

de

configuration

Crer des projets mters :

Votre solution est gnrique. Elle fonctionne quel que soit le mtier. Gardez bien
lesprit que votre logiciel est ddi au calcul rparti pour les domaines mtiers qui en
auraient recours.

Dclarer des ressources et les paramtrer :

Les ressources sont essentiellement des ordinateurs. On ne prcise pas la nature des
systmes dexploitation. Les ressources sont connectes un rseau. Le plus souvent,
ces ressources sont disponibles au travers dun rseau tendu (Internet).

Dfinir le type des calculs et des rsultats :

Prvoir dont des types suffisament gnriques de faon pouvoir assurer la gestion de
tout type de rsultats. Les rsultats sont, la plupart du temps, reprsents de manire
informatique (types primitifs, fichiers XML structurs, flux doctets, images, etc.)
Les calculs sont implments par les personnes du mtier. Plusieurs possibilits sont
envisageables. Soit les calculs sont implments avec vos dfinitions dinterface, soit
directement intgres via des librairies dynamiques ou excutables.

De monitorer un projet, les calculs en cours.

Votre logiciel trace toutes les activits en cours et passes. Ces traces sont consultables
en temps rel. Des actions sont possibles sur les activits en cours.

RFLEXION

FONCTIONNELLE

Vous devez mener une rflexion fonctionnelle afin de fixer le primtre de

votre solution et dtablir le cahier des charges fonctionnel. Les axes de
rflexion sont :

La dfinition dun calcul :

Cest dire imaginer la spcification du type calcul dans votre application de faon ce
quelle couvre les plus de champ possible.

La dfinition dun rsultat :

Cest dire imaginer la spcification du type rsultat dans votre application de faon
ce quelle couvre les plus de champ possible.

La structure de lAPI :
Cest dire lensemble des types et des interfaces publiques publie aux personnes du
domaine pour limplmentation dun calcul.

La nature des programmes livrs

Le module de la ressource est de quel type ? Excutable ?

La type de ressource
La forme de lapplication de configuration et de monitoring :
Sans oublier de spcifier lensemble des fonctionnalits que ces applications offrent.

Vous pouvez vous inspirer de la solution libre

existante BOINC
ARCHITECTURE

LOGICIELLE

Il faut privilgier les clients lgers (appli. Web 2.0) - Pas de clients
lourds. Les architectures logicielles de vos applications client
reposeront sur le modle darchitecture 3-tiers. L'implmentation
reposera sur le patron de conception MVC.
Vous utiliserez au maximum les design pattern. Cela devra
figurer dans vos schmas UML. On privilgiera pour les traitements
automatiques limplmentation sous forme de services (dmons). Si
vous utilisez des SGBD-R, vous devez rendre indpendante votre
application en utilisant des librairies de mapping objet/relationnel.
La solution logicielle que vous concevez repose sur une
architecture base de composants distribus. Les protocoles de
communications logiciels sont des protocoles dinvocation. Ces
choix se refltent tant sur larchitecture physique que sur la
partie
logicielle.
Elle
impacte
aussi
fortement
votre
implmentation.
Vos choix seront dcrits dans les diffrents livrables.
3.

CONTRAINTES

TECHNIQUES

Lensemble du dveloppement doit tre rgi par le logiciel libre. Tous les outils
utiliss seront issus du logiciel libre. La plate-forme Microsoft est toutefois
tolre. Les langages de dveloppement prconiss sont :

Php, Java (JSP/Servlet), CGI ou FastCGI.

C/C++, Java.
Les serveurs dapplication libres
Les protocoles recommands : SOAP, XMLRPC, RPC, CORBA, RMI, etc.
Les langages de scripting sont aussi conseills : Python, Perl, Ruby, Shell, etc.
Les bases de donnes : PostGresSQL, MySQL et tous les autres SGBD libres.
Les librairies utilises doivent tre issues du logiciel libre.
De mme pour les outils de dveloppement.

Aucun piratage ne sera tolr.

Tous les choix devront systmatiquement tre prcisment expliqus.
Techniquement, laccent doit tre mis sur :

La performance
Lergonomie
La facilit dadministration
Les temps daccs au systme de fichiers
Lempreinte mmoire
Les accs simultans matriss
Le monitorage des connexions actives
La performance et la pertinence des outils utiliss.
Le nombre de ressources (processus) utilises
Le nombre de programmes et librairies dpendants

Louverture de votre solution

4. CADRE METHODOLOGIQUE
MTHODE 2TUP
Le projet sera men selon les principes mthodologiques du processus de dveloppement de
systme dinformation 2TUP , dont on peut donner la reprsentation schmatique simplifie
suivante :

Ce processus permet dans une large mesure de traiter paralllement les aspects fonctionnels et
techniques du projet. Les quipes projet seront donc organises dans cet esprit.

EXECUTION

DU PROJET

Parmi les diffrentes activits dexcution du projet on distingue en particulier :

Le recueil du besoin fonctionnel : il est traduit dans le cahier des charges fonctionnel
(CdCF) dont la partie essentielle dcrit les fonctions attendues du systme raliser.
Dans le cas prsent, ce document restera succinct, il devra cependant contenir les
lments essentiels une comprhension complte du problme.
Le systme ntant pas destin des utilisateurs internes votre entreprise, le recueil du
besoin ne pourra seffectuer auprs deux. La matrise douvrage devra donc valuer les
attentes de la clientle potentielle partir de sa propre rflexion fonctionnelle (Cf. section
III.2 de ce document) et de toute source dinformation externe quelle jugera pertinente

Lanalyse, la conception, la ralisation : ils porteront sur la solution complte et tiendront

compte des contraintes techniques et des impratifs annoncs par le sujet.
- Lanalyse et la conception seront bases sur des modlisations UML ralises avec un
AGL (Rational Rose par exemple).
On pourra utiliser une modlisation agile ou tout autre mthode compatible avec
les processus unifis.
Afin de bien prsenter la dmarche suivie, les diffrents modles devront clairement
apparatre :

modles de use cases

modles danalyse

modles de conception prliminaire

modles de conception dtaille

- Larchitecture sera galement dcrite en UML au moyen

correspondants (diagrammes de composants et de dploiement).

des

diagrammes

- Le code sera si possible obtenu partir des modlisations, via le gnrateur

automatique de lAGL. Sinon il sera issu dune transposition des modles.

La recette : Elle doit tre effectue par la MOA mais aussi, pour garantir lobjectivit, par
une personne externe lquipe projet. Charge la MOA didentifier la ressource
susceptible de jouer ce rle.

Le dploiement : Lapplication devra tre dploye la Miage au cours de la premire

semaine davril. Les conditions de ce dploiement seront prcises ultrieurement.
A ce stade lapplication ne sera peut-tre pas finalise, la clture du projet nintervenant
pas avant le 18 avril. On dploiera donc une version partielle de lapplication, qui devra
pouvoir tre excutable et faire lobjet dune dmonstration.
Un second dploiement, portant cette fois sur le produit complet, pourra tre demand
par la suite.

GESTION

DU

PROJET

Les activits de gestion de projet prendront en compte au minimum les aspects suivants :

Analyse des risques

Estimation des charges
Planification
Suivi des consommations par tableau de Bord

Les livrables correspondants seront mis jour frquemment. Ils seront envoys lquipe
pdagogique et prsents au dbut de chaque comit de pilotage.

PROCESSUS

ITRATIF

& PLANIFICATION

Les principes de base dun processus unifi (dveloppement itratif et incrmental use case
driven approach) devront tre soigneusement respects.
Consquemment on sappliquera identifier trs tt le noyau de lapplication et on fera en sorte
de spcifier et dvelopper celui-ci en priorit.
Le planning devra clairement faire ressortir :

les itrations successives

leur milestone

les incrments successifs ( travers les lots et/ou les use cases concerns)

LIVRABLES
On fournira au minimum les livrables suivants :
LIVRABLE

TAILLE MAXIMALE

DATE de REMISE

Un cahier des charges fonctionnel

25 pages

30/11/2007

Un plan de management/dveloppement complet (ou Software

Development Plan )

20 pages

30/11/2007

Un planning gnral puis dtaill (dont dfinition des itrations)

30/11/2007

Un benchmarking des solutions techniques existantes

10 pages

30/11/2007

Une maquette incluant une bauche darchitecture logicielle

Lors du premier comit de

pilotage

Un dossier de spcifications fonctionnelles

25 pages

18/01/2008 (Noyau*)

Un dossier de conception (spcifications techniques)

15 pages

18/01/2008 (Noyau*)

Un dossier technique complet (Cf. plus bas)

15 pages

11/04/2008

Produit Final

16/04/2008

* cette date les specifications porteront uniquement sur le noyau de l'application ; le livrable sera enrichi au cours des itrations
ultrieures

Dautres livrables pourront sajouter cette liste. Ils devront tre dfinis dans le Software
Development Plan avec leur date prvisionnelle de remise.
La forme des documents crits respectera un standard dcriture (charte graphique entre autre).
Les dates de remises indiques dans le tableau ci-dessus sont des dates limite. Elles ne
correspondent pas forcment la date optimale laquelle lquipe projet doit les finaliser pour
respecter une bonne vitesse davancement.
Certains de ces livrables seront fournis initialement dans une version intermdiaire (qui sera
prsente lors des comits de pilotage). Ces documents pourront voluer au cours du projet, la
version dfinitive de chaque livrable devant tre remise une semaine avant la soutenance du
projet de synthse.

Prcisions sur les livrables techniques :

Benchmarking des solutions techniques.

Cf. annexe pds - annexe - benchmarking.pdf

Maquette incluant une bauche darchitecture logicielle

La maquette que vous prsentez lors du premier comit de pilotage pourra tre trs
limite mais devra donner une ide de la future architecture logicielle.
En parallle vous pourrez prsenter un schma dcrivant votre architecture logicielle cible
de faon plus aboutie.

Dossier de conception. Il comprend :

-

L'architecture physique (machines, rseaux, interconnexions, etc. ) et toutes les

configurations physiques possibles.
L'architecture logicielle (executables, librairies, API, serveurs d'applications etc.)
Le diagramme de dploiement est obligatoire.
Les diagrammes UML utiles du modle statiques (spcifications dtailles limites aux
diagrammes et parties juges essentielles) utiles pour passer la phase
d'implmentation, pour tous les programmes implments dcrits ci-dessus
dans l'architecture logicielle.
Les diagrammes UML utiles du modle dynamique illustrant les scnarios les plus
pertinents pour la comprhension de la solution.

Dossier technique complet. Il comprend :

-

Une documentation technique dadministration de lapplication.

Un dossier permettant le dploiement de lapplication de bout en bout.
Un dossier de programmation lattention des programmeurs repreneurs.

ATTENTION : Le dpassement du nombre de pages impos entrane immdiatement le retrait dun quart de
point par page supplmentaire sur la note associe au livrable.

5. ORGANISATION

ET

RSPONSABILITS

EQUIPES PROJET
Vous devrez constituer vous-mmes les quipes projet.
Compte tenu des effectifs officiels au 19/10/2007 la rpartition des tudiants dans les diffrents
groupes se fera selon les rgles suivantes :
ISIDIS 2/3 : 3 groupes (26 tudiants)

Groupe 1 : 5 tudiants FA + 4 tudiants FI

Groupe 2 : 5 tudiants FA + 4 tudiants FI

Groupe 3 : 4 tudiants FA + 4 tudiants FI

ISIDIS BI : 3 groupes (22 tudiants)

Groupe 1 : 5 tudiants FA + 3 tudiants FI

Groupe 2 : 4 tudiants FA + 3 tudiants FI

Groupe 3 : 4 tudiants FA + 3 tudiants FI

Si de nouveaux tudiants devaient rejoindre les effectifs de lune ou lautre promotion aprs le
19/10/2007, ils seraient placs dans un groupe par les professeurs eux-mmes.
Ces rgles sont bien entendu non ngociables.
Chaque quipe dsignera un Chef de Projet (CP) qui se chargera notamment de dfinir le rle de
chacun au sein de lquipe.
Chaque CP devra communiquer lquipe pdagogique (professeurs) la liste des tudiants
constituant son groupe et le nom choisi pour le groupe, et ce au plus tard le 25 Octobre (par
mail).
Si cette date les groupes ntaient pas encore constitus conformment aux rgles nonces cidessus, lquipe pdagogique se chargerait elle-mme de cette tche.

RESPONSABILITS

DES EQUIPES

Chaque quipe est entirement responsable du travail quelle accomplit et de lorganisation

quelle met en place pour mener bien le projet Les problmes dordre humain sont de votre
responsabilit comme dans le monde de lentreprise; les ventuels conflits entre membres de
lquipe doivent tre grs conformment aux mthodes enseignes en cours de Conduite de
Projets.
Les problmes personnels (sauf cas de force majeure) doivent tre grs entre vous. La gestion
du projet est aussi de votre ressort.
Lquipe pdagogique vous donne les orientations suivre dans le cadre du projet (conduite de
projet, choix et blocages technologiques). Les choix techniques peuvent tre divers. Si vous
dcidez de vous orienter vers une technologie inconnue ou mal matrise, cest un risque que
vous devez assumer.

MODE

DE COMMUNICATION

Le CP de chaque groupe, et lui seul, assure la communication avec lquipe pdagogique. Il devra
imprativement fournir une adresse e-mail permettant dchanger rapidement des informations.
Tous les courriers devront tre adresss lensemble de lquipe pdagogique (mme si le sujet
semble concerner un professeur en particulier), dont voici les adresses lectroniques :

alexandre.brenner@wanadoo.fr
ggiraud@ggiraud.net

Les livrables seront remis par e-mail au plus tard la date limite prvue pour chacun deux.
Aucun document sous forme papier ne sera fourni sauf demande express.
Des questions ponctuelles pourront galement tre traites par e-mail si lquipe pdagogique
juge que la question est pertinente et ne trouve pas de faon vidente sa rponse dans les
diffrents enseignements reus au cours du Master.
Des informations, accessibles tous, pourront galement tre changes de faon ponctuelle sur
un board Internet (ladresse vous sera communique ultrieurement). Celui-ci pourra tre mis
jour occasionnellement, vous de le consulter rgulirement.

COMITS

DE PILOTAGE,

DMONSTRATION & SOUTENANCE

Les comits de pilotage (3 x 1 heure Cf. planning plus loin) constitueront des revues de
projet au cours desquelles chaque quipe rendra compte de son tat davancement, fera
remonter les problmes et questions ventuelles, et prsentera ses travaux principaux.
Lanimation sera confie au CP, qui assurera lintroduction et la conclusion. Chaque membre
de lquipe devra participer significativement la prsentation.
Lquipe pdagogique commentera ces travaux si besoin et rorientera ventuellement les
tudiants.

Une dmonstration de lapplication vous sera demande peu aprs votre dploiement (1re
semaine davril) : elle se fera auprs dun enseignant de la miage ; Le nom de cet enseignant
et la date de la dmonstration vous seront indiqus ultrieurement.

La soutenance sera individuelle : chaque tudiant fera une brve prsentation (5 minutes) du
projet en insistant sur sa participation personnelle puis rpondra une srie de questions
pouvant porter sur cette participation ou sur lensemble du projet.

SYSTME

DE NOTATION

On rappelle que le projet de synthse constitue un module part entire. Une note infrieure la
moyenne entrane une deuxime session. Ne pas russir dans ce module signifie la non obtention
du MASTER.
Chaque projet fait lobjet dune note globale de groupe.
En parallle chaque tudiant se verra attribuer une note individuelle qui sera notamment
dtermine en fonction de la qualit de sa soutenance.
La note finale sera la moyenne de la note de groupe et de la note individuelle.
Le projet est not en fonction de nombreux critres prcis. Chaque critre fait lobjet dune note
et dun coefficient de pondration, la somme des notes pondres donnant la note globale. Pour
information les macro critres retenus sont les suivants :

Respect de la Dmarche mthodologique

Qualit des Livrables Fonctionnels
Qualit du produit final et des Livrables Techniques
Performance lors des comits de pilotage
Apprciation de lenseignant dsign pour assister la dmonstration

Les livrables remis en retard ne seront pas lus; la note associe sera zro.
Tout comme en entreprise, le non respect des engagements entrane une sanction (ici non
financire mais portant sur la note).

Parmi les divers critres de notation du projet, certains permettent en particulier dvaluer le
produit final (application ralise). Cette valuation ne constitue donc quune sous-note de la note
globale et les cas de figure suivants peuvent parfaitement se prsenter :

une quipe ayant ralis un produit final de grande qualit nobtient quune note globale
moyenne car dautres aspects du projet sont mdiocres (livrables crits, performance
orale, etc).
une quipe suit une bonne dmarche mthodologique, fournit des documents crits de
grande qualit, etc et obtient donc une bonne note globale mais son produit final est
infrieur celui dautres groupes.

PLANNING / GESTION

DU TEMPS

Le planning des rencontres est le suivant :

ISIDIS
BI

2/3

19/10/2007
de 13h 14h

Lancement du Projet
Comit de Pilotage n1

7/12/2007

7/12/2007

aprs-midi

matin

Comit de Pilotage n2

25/01/2008

25/01/2008

aprs-midi

matin

Comit de Pilotage n3

7/03/2008

7/03/2008

aprs-midi

matin

Soutenance

17/04/2008

17/04/2008

13h30-19h

matin

ATTENTION : Ces dates sont susceptibles dtre modifies. Vous en serez bien entendu informs
temps

Les quipes organiseront elles-mmes leur ordre de passage au sein de la journe ou journe
dfinie.
Le travail demand sur ce projet est trs important et le temps imparti relativement limit. Vous
devrez donc faire en sorte, pour obtenir un travail de qualit, davoir un esprit synthtique, daller
l'essentiel, de vous concentrer sur les priorits, dtre raliste, de travailler en temps et en
heure, et daccepter si besoin est de diminuer la quantit pour plus de qualit.