Vous êtes sur la page 1sur 42

Introduction aux mthodologies de dveloppement

Cours HEI 2009-2010

ALTRAN Nord TI

Reproduction interdite

Sommaire

Les Mthodologies de dveloppement


(Conduite de Projet Informatique )
1. Introduction : le projet
2. Le cycle de vie dun projet
3. Mthodes de dveloppement
4. Versionning

Reproduction interdite

1- Introduction
Gense du projet

Ide
Besoin
Opportunit

PROJET

Innovation

Reproduction interdite

1- Introduction
Dfinition
L'Afitep-Afnor (X 50-105) dfinit le projet comme :
" une dmarche spcifique qui permet de structurer mthodiquement et
progressivement une ralit venir...:
un projet est dfini et mis en uvre pour rpondre au besoin d'un client (...)
et implique un objectif et des besoins entreprendre avec des ressources
donnes".

Composantes
Quoi
Objectifs, Fonctionnalits
Temps
Dlais, chances
Moyens disponibles
Humains et Techniques
Financiers (cot)
Qualit
Selon le domaine dactivits

Reproduction interdite

2- Cycles de vie dun projet :


1. Dfinition dun cycle de vie
2. Mthodes

Reproduction interdite

2.1- Dfinition du cycle de vie


Le cycle de vie dun logiciel est la priode situe entre le dbut de la
conception et larrt de lexploitation de ce logiciel.
Le cycle de vie regroupe un ensemble dactivits suivant les normes
AFNOR Z 67 150. Il est envisag un instant donn et va comprendre les
progrs technologiques et les contraintes organisationnelles (A. Carlier,
1994)
Le cycle de vie dun logiciel correspond lidentification des tats
successifs dune application ou dun produit dtermin. Il est
essentiellement dynamique, volutif et presque toujours progressif (A.
Carlier, 1994)

Reproduction interdite

2.2- Principales mthodes de conduite de projet


Squentielle

Itratives

Cascade

Evolutive

Objet

Principe de dcouper le projet en


phases distinctes sur le principe
du non-retour. Dveloppe dans
les annes 1970 par W. ROYCE

Principe bas sur la polyvalence


et une approche pluridisciplinaire,
qui tendent minimiser l'impact
de l'volution des besoins en
cours de projets

Principe bas sur la sparation


de ltude darchitecture de celle
de ltude fonctionnelle afin de
parallliser au maximum les
tches. Procde par itration
comme pour lvolutive.

Avantage: proposer au fur et


mesure une dmarche de
rduction des risques, en
minimisant au fur et mesure
l'impact des incertitudes.

Avantage : permettent de se
rapprocher davantage des
utilisateurs, et ainsi favorisent
l'assurance qualit

Avantage : Permet de prendre en


compte les problmes
darchitecture ds le dbut du
projet. Conforme lapproche
objet dont la dynamique est plutt
ascendante en matire de
composants darchitecture.

Inconvnient : exclusion de
l'utilisateur ds la phase de
conception car trop technique. Le
contrle qualit significatif
survient seulement en fin de
projet.

Inconvnient : le produit, rsultat


d'volutions permanentes, peut
devenir complexe et difficilement
maintenable

Inconvnient : Tout repose sur


lexpertise de lquipe projet

Risque : refus de recette


utilisateur

Risque : Maintenance difficile

Risque : Maintenance difficile


Reproduction interdite

2.2- Mthodes

Exemples de mthodes de conduite de projet :


Dynamiques en cascade :
Modle en b
Modle de loti
Modle parallle
Modle en V
Dynamiques volutives (ou dites Agile ) :
Spirale
RAD
DSDM (Dynamic System Development Management)
RUP (Rational Unified Process)
SCRUM (sprint)
Extreme Programming

Reproduction interdite

3- Mthodes de conduite de projet :


1. Le modle en cascade
2. Modle en V
3. Autres modles
4. Les tapes dun projet

Reproduction interdite

3.1- Modle de dveloppement en cascade


Projets de petite taille,
Projets de Back-Office

Expression
des besoins

Dmarche base sur la spcialisation des


tches qui tendent contenir les risques et
les cots, dans un enchanement de
phases qui reste simple et intuitif

Spcifications
Conception

Dveloppement
Tests
Maintenance
Reproduction interdite

3.2- Modle en V (variante du modle en cascade)


L'assurance qualit est le processus qui permet de vrifier en continu la qualit
du produit fur et mesure de sa fabrication.
Le modle en V met l'accent sur ce processus. Il confronte les diffrents niveaux
de test avec les phases de projet de mme niveau. Ceci permet chaque tape de
dfinir non seulement les fonctions, mais galement les critres de validation.
La cohrence entre les deux lments permet de vrifier en continu que le projet
progresse vers un produit rpondant aux besoins initiaux.
Ce modle est adapt aux projets de taille et de complexit moyenne. C'est une
amlioration du modle en cascade traditionnel. Il permet d'identifier et
d'anticiper les ventuelles volutions des besoins.
C'est aussi un moyen de vrifier la maturit des utilisateurs, car s'il en tait
autrement, ils se trouveraient dans l'incapacit de fournir des tests de recette ds
la phase de spcification.
C'est un modle avantageux pour une matrise d'uvre et rassurant pour une
matrise d'ouvrage, qui doit cependant s'engager significativement.
Reproduction interdite

3.3- Le modle en V

Expression
des besoins

Exploitation

Recette

Spcifications

Conception

Dveloppement

Tests dintgration

Tests unitaires

Reproduction interdite

3.4- Autres modles

Principe du modle itratif


Nouveau besoin
(documentation, code, test)
Elaboration

Faisabilit

Fabrication

Transition

Exploitation ou tests
par les utilisateurs

Reproduction interdite

3.4- Autres modles

Modle en B
Similaire au modle en cascade, il met l'accent sur le processus de maintenance
qui est valu 70% du cycle complet.
Ce modle rutilise les scnarios de tests btis pendant la phase de
dveloppement, notamment pour les tests de non-rgression, ainsi que les
procdures de mise en exploitation.

Ce modle se projette plus loin que le traditionnel cycle en cascade.


Il peut servir de base une matrise d'ouvrage pour btir un projet complet de
dveloppement et de maintenance d'une grosse application de back office.
Son intrt est de prvoir lors de chaque phase projet la rutilisation des tests et
des procdures de mise en exploitation.

Reproduction interdite

3.4- Autres modles

Modle en B
Expression du
besoin

Spcifications

Conception

t
en
em
pp
lo
ve
D

Conception
Dveloppement

Spcifications

Dveloppement

Maintenance

Expression du
besoin

Tests
valuation
Exploitation
Reproduction interdite

3.4- Autres modles


Modle Incrmental ou en lots
Le modle incrmental ou loti permet de grer les projets de dveloppement de grands
systmes. Il dcoupe le systme en domaines qui sont traits individuellement sur le
modle en cascade. Une des ides du modle incrmental est de grer la complexit.
C'est un modle adapt aux projets de grande envergure. Nanmoins, l'architecture du
systme doit permettre de dfinir des domaines suffisamment dcoupls. Dans le cas
contraire, certains incrments doivent attendre que les incrments avec lesquels ils
sont lis, soient suffisamment dvelopps. Lorsqu'on leur propose un dveloppement
par lot, les matrises d'ouvrage doivent vrifier le couplage des domaines.

Modle parallle
Le modle parallle est un modle incrmental coupl soit par le temps (les diffrents
domaines doivent tre mise en production au mme moment), soit par les composants
(certains composants du systme sont troitement lis).
Bien qu'il rduise la complexit, comme le modle incrmental, il ne parvient pas
supprimer les risques de dlai. Il suppose des montes en charge rapides, avec des
quipes relativement fournies.
Adopter ce modle suppose que les autres facteurs du projet ne prsentent pas de
risques significatifs. Nanmoins, la matrise d'ouvrage devra tre attentive la
composition de l'quipe projet et son mode de management.
Reproduction interdite

3.4- Autres modles

Modle en spirale
Principe :
Identifier les risques, leur affecter une priorit
Dvelopper des prototypes pour rduire les risques, en commenant par le
plus grand risque
Utiliser un modle en V ou en cascade pour implmenter chaque cycle de
dveloppement
Contrler :
si un cycle concernant un risque est achev avec succs,
valuer le rsultat du cycle, planifier le cycle suivant
si le risque est non rsolu, interrompre le projet

Reproduction interdite

3.4- Autres modles

4 phases dans le droulement du cycle en spirale (dfini par Barry Boehm en 1988) :
1.
2.
3.
4.

dtermination des objectifs, des alternatives et des contraintes ;


analyse des risques, valuation des alternatives ;
dveloppement et vrification de la solution retenue ;
revue des rsultats et vrification du cycle suivant.

Reproduction interdite

3.4- Autres modles

Modle de type Prototype


Un prototype est la premire version d'un produit qui vient d'tre ralis afin
d'tre mis au point . Autrement il faut parler de maquette, qui recouvre la
ralisation petite chelle de tout ou partie d'un produit raliser. Par abus de
langage, nous nommerons prototype les maquettes rutilisables.
Les prototypes peuvent tre construits suivant un axe horizontal ou vertical.
Horizontaux, ils couvrent une couche technique du systme sur l'ensemble des
fonctions dvelopper. Verticaux, ils couvrent un chantillon de fonctions sur
l'ensemble des couches techniques. Gnralement les prototypes raliss sont
des 2 types.
Les prototypes peuvent tre rutilisables, comme lors d'un cycle de vie itratif qui
toffe chaque itration le prototype initial jusqu'au produit fini. Ils peuvent tre
galement jetables des fins de vrification fonctionnelle ou technique
(faisabilit).
Sur les projets techniques, mens par de petites quipes, l'intrt est de gagner
en flexibilit, et de se librer des contraintes d'une mthodologie plus large. Pour
des projets o les utilisateurs sont largement impliqus, on prfrera toujours un
cycle de vie RAD.
Reproduction interdite

3.4- Autres modles

Modle du cycle itratif RAD

Structure d une phase dans le cycle RAD

Le cycle de vie RAD (Rapid Application


Development) est employ lorsque une
implication forte de l'utilisateur est
ncessaire.
Il permet de construire le systme avec
l'utilisateur, et participe ainsi l'assurance
qualit.
Nanmoins la condition sine qua non pour
mettre en uvre un cycle RAD est de
s'appuyer sur un solide AGL (atelier de
gnie logiciel) qui seul peut garantir un
passage rapide du concept la mise en
uvre.
L'quipe projet doit ncessairement
matriser l'AGL employ, c'est le risque
principal des projets RAD.

Cycles de prototypage

Reproduction interdite

3.4- Autres modles


DSDM
"Dynamic System Development Management" (DSDM) met en uvre de manire
structure la plupart des principes des modles volutifs afin de les rendre
efficaces dans le cadre de grands projets.
L'objectif initial de DSDM tait de pallier le manque de formalisation du concept RAD
en proposant une mthode structure pour le mettre en uvre.
DSDM est une mthode base sur une dmarche volutive et incrmentale, c'est
dire que non seulement le systme est produit au cours d'itrations, mais en plus
il est divis en lots, et livr de manire progressive.
DSDM est compos de 5 phases :
1. La faisabilit (expression du besoin, cots/bnfices, valuation
des risques) ;
2. Ltude business (spcification des fonctions et hirarchisation) ;
3. Le modle fonctionnel (prototypes horizontaux et tests) ;
4. La conception et la ralisation (prototypes verticaux et tests) ;
5. La mise en uvre (optimisation et mise en production).
DSDM doit tre l'objet des mmes attentions que le modle RAD.

Reproduction interdite

3.4- Autres modles


RUP
"Rationale Unified Process" est une mthode dveloppement proprit de la
socit Rational et bas sur l'utilisation de l'atelier Rational.
Elle est vendue sous la forme d'une documentation hypertexte et d'outils
incorporables chaque composant de l'AGL de Rational.
C'est une mthode volutive, qui met en uvre les mmes principes que le RAD
ou le dveloppement en spirale.
Elle compose de 4 phases :
1. Linception (initial "use case", cot/bnfice, risques, planification) ;
2. Llaboration ("use case" 80% termins, architecture logicielle, prototype) ;
3. La construction (dveloppement) ;
4. La transition (tests, conversion et dploiement).
RUP utilise le niveau lev d'automatisation que lui procure l'AGL Rational.
Il permet d'une part de planifier des itrations l'intrieur de chaque phase, de
parallliser les processus au maximum : ainsi la dfinition d'architecture peut
commencer tandis que les spcifications ne sont pas termines.
Reproduction interdite

3.5- Les tapes dun projet


(Extrait dune proposition commerciale)

Linitialisation du projet
Ltude darchitecture
La conception fonctionnelle et technique
La Ralisation
Les tests
La recette interne
La recette fonctionnelle
Lintgration
La conversion et la reprise des donnes
Le site pilote
Le dploiement technique
La formation
Documentations

Reproduction interdite

3.5- Les tapes dun projet

Linitialisation du projet
Cette phase permettra aux quipes de la matrise duvre de :
1.
2.
3.
4.

Intgrer le dtail des enjeux, objectifs et contraintes du projet,


Intgrer lenvironnement fonctionnel et technique du projet,
Constituer / intgrer les groupes de travail du projet,
Dfinir un macro planning et confirmer lventuel lotissement
fonctionnel,
5. Dfinir finement lensemble des livrables du projet,

Reproduction interdite

3.5- Les tapes dun projet


Ltude darchitecture
Cette tude aura pour principaux objectifs :
1. De dfinir larchitecture applicative, notamment sur la reprise des composants existants,
et la conception des composants techniques et fonctionnels propres au domaine,
2. De dfinir larchitecture technique et de valider dfinitivement les outils de
dveloppement,
3. Damender, le cas chant, le primtre fonctionnel du projet,
4. De finaliser le lotissement dfini par la matrise douvrage au regard des contraintes
architecturales identifies,
5. De dfinir larchitecture des donnes : localisation, rpartition, modle, rplication,
sauvegardes,
6. Initialiser les tableaux de suivi des risques,
7. Davancer dans le degr de dtail du planning,
8. Dinitialiser un squelette dapplication qui permettra deffectuer une exprimentation
ayant pour finalit de valider les principes de lIHM, larchitecture technique, et la
cartographie fonctionnelle,
Reproduction interdite

3.5- Les tapes dun projet

La conception fonctionnelle et technique


Cette phase concerne llaboration des lments suivants :
1.
2.
3.
4.
5.
6.

Architecture applicative (impact issu du dcoupage fonctionnel),


Spcifications techniques,
Spcifications fonctionnelles dtailles,
Interfaces homme machine (maquettage statique et / ou dynamique),
Construction du modle de donnes MCD et du MPD,
Rdaction des jeux et des plans de tests dassemblage,

Reproduction interdite

3.5- Les tapes dun projet

La Ralisation
Pour certains projets, il est parfois recommand de raliser une maquette
oprationnelle ne comportant que quelques dveloppements.
Cette tape aura pour objectif principal de recetter le socle technique et
en particulier de vrifier la monte en charge, ainsi que la conformit
des travaux en fonction des attentes du client.
Elle permettra larchitecte systme et aux quipes systmes du client de
valider et / ou damender les lments darchitecture ainsi
quventuellement quelques consignes de dveloppement.
En outre, elle permettra de dfinir larchitecture rseau ncessaire tant en
terme de dbit que de temps de rponse.
Le lotissement du projet sera dfini au cours de la phase dInitialisation.

Reproduction interdite

3.5- Les tapes dun projet


Les tests
Cette tape consiste concevoir et excuter un plan de tests.
Dans la pratique, il convient dintgrer les dveloppements unitaires au sein de
larchitecture technique cible, tout en testant la cohrence fonctionnelle et
technique globale de lapplication, avant livraison et installation sur le site du client.
Les tests raliss seront :

Un test spcifique du Framework aprs dveloppement sur la base de la conception dfinie au dbut de
la conception fonctionnelle et technique,

Un test de rception des composants achets pour le projet,

Les tests unitaires des fonctions dveloppes,

Les tests dassemblage sur les plates-formes de dveloppement avec donnes relles permettant entre
autres le test des procdures de reprise,

Pour la maquette oprationnelle, un test de charge initialement prvu sera ralis,

Les test dintgration sur les plates-formes,

Les tests de charge sur chacun des lots sachant que pour une architecture 3 tiers, cette partie
ncessite plutt un monitorat dtaill des composants serveurs et rseau lors de linstallation. Si
ncessaire, un test sur automate pourra tre prvu,
Reproduction interdite

3.5- Les tapes dun projet

Tests des composants externes


Lobjectif de cette tape est de sassurer que lensemble des composants
externes lapplication sont conformes sur les plans fonctionnel et
mtier aux spcifications prvues dans les phases de conception.
Sur un plan technique, il sagit de sassurer que le composant technique
ne cre aucune interaction non-souhaite (ou interfrence) de par son
installation, registration, instanciation,
Les composants externes sont par exemple et suivant les technologies
employes des composants OCX, VBX, DLL, EJB ,.
La qualification technique pourra avoir t ralise dans le cadre dun
projet antrieur

Reproduction interdite

3.5- Les tapes dun projet


Tests Unitaires
Ces tests sont raliss au fil de leau par lquipe de dveloppement.
Chaque personne de cette quipe consigne que le dveloppement de la
fonction X a t ralis par lui et aprs excution en environnement de
dveloppement ou sur simulateur.
Il sagit de confirmer que cette fonction est conforme aux spcifications
fonctionnelles et techniques dcrites.

Tests dassemblage
Ces tests sont raliss par le chef de projet ou sous son autorit par une
personne de lquipe de dveloppement dtache sur cette mission.
Cette phase permet de sassurer que lensemble des composants
techniques dvelopps ou acquis sinterfacent correctement :
lapplication fonctionne sans dfaillance, les rsultats attendus sont
conformes sur les axes rgles de calcul et rgles de gestion.
Cette phase seffectue sur le jeu dessai de dveloppement.
Reproduction interdite

3.5- Les tapes dun projet

Tests dintgration
Cette phase de test seffectue sur une plate-forme dintgration dclare
conforme par le client lenvironnement de production.
Cela concerne tant les aspects techniques (OS serveur, base, client) que
les interfaces (entrantes notamment), ainsi que le jeu de donnes.

Tests de charge
Lobjectif de cette phase est deffectuer une monte en charge des
donnes entrantes et existantes dans lapplication.
La base de donnes sera charge avec une volumtrie quivalente au
fonctionnement nominal de lapplication.
Les transactions devront seffectuer dans les temps de rponses prvues
lors de llaboration du cahier de charge.
A dfaut de temps de rponse dcrit, lapplication devra prouver quelle
fournit les rponses attendues avec la volumtrie nominale.
Reproduction interdite

3.5- Les tapes dun projet

Test de stress
Cette tape permet de simuler lintgralit des accs (TP et Batch)
effectus simultanment sur lapplication sur une priode de
rfrence, gnralement une priode de pointe pour lapplication.
Ces tests sont gnralement raliss laide dun automate qui enchane
des scnarios de tests dfinis au pralable.
Les tests de stress peuvent galement servir au remplissage de la base ;
Les tests de charges seront alors effectus lissue des tests de stress.

Reproduction interdite

3.5- Les tapes dun projet


La recette interne
Il sagit dune validation interne, effectue par la direction projet, des
livrables avant fourniture au client du lot ralis.
La recette interne assure que le chef de projet en charge du projet suit le
droulement des actions de la contractualisation la mise en uvre
du rsultat prvu.

La recette fonctionnelle
La recette fonctionnelle est effectue par le client et plus spcifiquement
par le Chef de Projet Utilisateur du Client.
Elle est usuellement effectue sur la plate-forme de dveloppement ou la
plate-forme dintgration.
Les complments et/ou volutions dtectes lors de la recette
fonctionnelle peuvent donner lieu ltablissement davenant(s) au
contrat

Reproduction interdite

3.5- Les tapes dun projet


Lintgration
Cette opration sera place sous la responsabilit du chef de projet client
accompagn par lArchitecte Systme notamment pendant les phases
dinstallation et de dmarrage de la plate-forme.
La correction des dysfonctionnements doit tre assure de manire
ractive.
Le client pourra tre assist sur les diffrents dans la ralisation des tests
de recette du systme, et dans la mise au point globale du systme.
La conversion et la reprise des donnes
Dans le cas dune migration de systme avec reprise des donnes
existantes, la phase de conversion et reprise est considre comme
un sous-projet du projet de ralisation.
La reprise des donnes donne lieu llaboration de spcifications,
dveloppement et tests identifis. Les rgles que doivent respecter les
donnes en entre ainsi que leur structure sont fournies par le client.
Un taux de rejet peut tre admis en production. Il devra tre fix au plus
tard au dmarrage de cette phase.
Reproduction interdite

3.5- Les tapes dun projet

Le site pilote
Dans le cas dun site pilote : pour chacun des lots produits et des
volutions en garantie, un site pilote sera ralis.
Le site pilote pourra tre install aprs la validation du Procs Verbal (PV)
de recette dintgration.
Cette tape permet de vrifier le fonctionnement rel du projet.
Ce mode de fonctionnement saccompagne dune exploitation sous
contrle.
Le dploiement technique
Ces tapes sont places sous la responsabilit du client, plus
prcisment les quipes Installations pour le dploiement technique,
et des quipes dploiements / Formation.

Reproduction interdite

3.5- Les tapes dun projet


La formation
La formation peut prendre plusieurs formes.
Elle peut viser les utilisateurs mais aussi les quipes techniques (exemple : les quipes de
maintenance).
Diffrentes dclinaisons sont envisageables en fonction du contexte projet considr :
Les sessions de formation : elles sappuient sur lalternance dun enseignement thorique et des
mises en pratiques immdiates (TP).
Les sessions de formation doivent imprativement tre intgres ds le dbut dans le plan
projet : pour quelles soient optimales, les formations doivent tre synchronises avec le
dploiement sur sites ou le passage en maintenance (formation des quipes techniques).
Elle ncessite galement la mise en place dune infrastructure ddie (logistique : salle de
formation quipe, organisationnelle : disponibilit complte des stagiaires, technique :
disponibilit de plates formes ddies).
Le transfert de comptences : il est principalement ddi aux quipes techniques dexploitation
ou de maintenance. Lobjectif est de traiter sur la fin du projet lensemble des points
critiques du projet en parfaite transparence.
Laccompagnement en production : il se met en place lorsque la monte en charge et/ou le
dploiement reprsente(nt) un enjeu majeur et critique du projet. Ainsi, lensemble des
anomalies pouvant survenir sont traites en collaboration directe avec lquipe projet.
Reproduction interdite

3.5- Les tapes dun projet

Documentations
Dossier de Conceptions Fonctionnelles et Techniques
Ce dossier dcrit lensemble des transactions, ditions, traitements batch
de lapplication cible.
Le dossier de conception fonctionnelle et technique dcrit galement
lensemble des rgles de gestion, de calcul, denchanement et
dergonomie raliser.
Il constitue la rfrence pour la recette.
Dossier de recette
Le dossier de recette consigne lensemble des remarques (bloquantes,
mineures, volutions) identifies lors de la recette fonctionnelle.
Il reprend ou fait rfrence aux rgles de gestion dcrites dans le dossier
de Conceptions Fonctionnelles et Techniques.

Reproduction interdite

3.5- Les tapes dun projet


Documentations
Cahier du dveloppeur
Le cahier du dveloppeur prcise larchitecture gnrale du code de lapplication, les
composants techniques utiliss, les options de dveloppement (option du projet, de
compilation, versions de shells, composants, ) ainsi que les rgles particulires
utilises.
Son principal objectif est de permettre un dveloppeur reprenant le projet de
dmarrer dans les meilleures conditions.
Prconisations techniques
Ce document reprend lensemble des prconisations ncessaires au bon
fonctionnement de lapplication dans lenvironnement de production.
Procdures dinstallation
Sont dcrits dans ces documents lensemble des procdures ncessaires
linstallation de lapplication ainsi que des composants ncessaires linstallation.
Dans le cas dune installation automatise, elle dcrit le chemin de la routine
dinstallation lancer, les principaux crans et le rsultat attendu in fine.
Reproduction interdite

3.5- Les tapes dun projet


Documentations
Guide de dpannage
Ce guide reprend ou dcrit les principales oprations permettant de dbloquer une
situation dincident quil soit technique ou issu dun blocage fonctionnel.
Exemple : procdure de compactage / rparation de base, d fragmentation de base,
reconstruction dindex, rinstallation de composant et/ou doutil, dverrouillage ou
modification dindicateur en base,
Cahier dexploitation
Ce cahier doit contenir lensemble des procdures assurant lexploitation normale de
lapplication et sa disponibilit prvue pour les utilisateurs.
On y trouvera notamment :
les procdures spcifiques de sauvegarde spcifiques si elles ne sont pas prises en
charge par le systme,
les procdures de compactage, de r-indexation,
les procdures de purge,
les procdures de reprise en cas dindicent,
les procdures de relance dune procdure normalement automatique

Reproduction interdite

3.5- Les tapes dun projet

Documentations
Support de formation utilisateurs
Ce document permet la formation des utilisateurs aux outils.
Sauf stipulation particulire, il ne comporte pas de volet mtier.
Support de formation technique
Ce document permet la formation des acteurs techniques en vue de la
reprise du projet par une autre quipe.
Son contenu est dtaill au dmarrage du projet, notamment dans le
cadre dun transfert de comptences intgrs ds le dbut au
primtre du projet.

Reproduction interdite

4- Outils de versionning
Logiciels de gestion de version :
CVS (Concurrent Versions System),
Bitkeeper,
SourceSafe
Logiciels de gestion de configuration
Par rapport aux prcdents, apportent des outils permettant :
1. de grer les demandes de modification du systme faire voluer.
2. de mettre en correspondance les demandes de modifications avec les
changements apports au systme
Exemples : Synergy (Telelogic), PVCS, Perforce ou ClearCase

Reproduction interdite

ALTRAN Nord TI

Altran Nord / Adventec


Parvis de Rotterdam
1606 Tour Lilleurope
Tl. : +33 (0)3 28 36 22 30
Fax. : +33 (0)3 28 36
22 45 interdite
Reproduction