Gestion des projets
Cycle de développement
Les principes de découpage
Un projet comporte trois aspects représentés dans le triangle projet : la production, les ressources
et le temps. Une des premières responsabilités du chef de projet est de découper le projet pour
pouvoir répartir dans le temps la production et les ressources.
Le découpage doit s’appuyer à la fois sur l’approche cartésienne de réduction de la difficulté et
sur l’approche systémique de prise en compte des liens entre les éléments.
Découper un projet consiste ainsi à identifier les sous ensembles quasi autonomes présentant les
caractéristiques suivantes :
Chaque sous ensemble du projet donne lieu à un résultat bien identifié ;
La charge propre à chacun peut être évaluée
Les contraintes d’enchainement entre les sous ensembles sont repérables
Le découpage est fait à des mailles différentes, un sous ensemble étant souvent à son tour
décomposé.
On utilise deux critères non exclusifs pour découper un projet : l’un temporel et l’autre
structurel.
Le découpage temporel, utilisé dans la plus part des projets, permet de répartir le travail dans le
temps : la décomposition fait apparaître une succession d’étapes et de phases ; à chacun on
précise la date de début prévue et la date de fin visée.
Un projet se compose d’étapes ; chaque étape comporte un certains nombre de phases ; une
phase est définie par une ou plusieurs tâches à effectuer. A chaque élément de décomposition on
attache un résultat à atteindre, appelé livrable, qui peut faire l’objet d’un engagement contractuel.
La décomposition temporelle poursuit deux objectifs : il balise et guide ; chaque date représente
un jalon permettant de marquer les points de décision du parcours. De plus la distribution dans le
temps reflète un cheminement intellectuel. La plupart des méthodes de conception de systèmes
d’information proposent un tel cheminement, souvent appelé cycle de développement.
Le découpage temporel est souvent de type descendant, c'est-à-dire qu’il favorise :
La visibilité croissante, car les résultats sont de plus en plus précis et la maille d’étude de
plus en plus fine
Une progression réelle des travaux, dans la mesure où les résultats consolidés en fin
d’une étape ne sont pas remis en question dans les étapes suivantes.
Dans tous les cas, le cheminement intellectuel permet de converger ; il doit être économique
évitant de faire et refaire. Le client et le chef ont tous intérêt à découper le projet dans le temps,
car ainsi :
Le client peut valider et orienter le projet
Le chef de projet peut baliser le déroulement du projet
Le découpage structurel permet d’organiser le travail en se basant sur la structure du produit
final : la décomposition fait apparaitre les différents modules qu’il faut obtenir. L’utilisation de
ce critère requière une visibilité suffisante sur le résultat à produire.
Le découpage structurel présente plusieurs avantages :
Maitriser le projet
14
Gestion des projets
Répartir les responsabilités
Réduire les délais planifiés
Avoir un développement incrémental
Les découpages normalisés
Les normes internationales proposent trois découpages : PBS, WBS et OBS.
Le découpage PBS, Pruduct Breakdown Structure correspond au découpage structurel : ce sont
les différents composants du produit final. Le PBS est parfois appelé « structure du produit »,
« arborescence produit » ou « représentation des liens de composition entre les divers
constituants d’un produit ».
Exemple de décomposition PBS :
Le découpage WBS, Work Breakdown Structure représente la façon de parvenir au résultat tel
qu’il est décrit dans le PBS. Il s’appuie, en général, à la fois sur le critère structurel et sur le
critère temporel. Le WBS est parfois appelé « Organigramme des tâches» ou « OT ». Il apporte
une réponse aux deux questions : «Que doit-on faire ? Comment doit-on s’y prendre ?»
Exemples de décomposition WBS :?
15
Gestion des projets
L’OBS, Organisation Breakdown Structure reprend le WBS et fait apparaître les noms des
personnes responsables de la production des différents éléments. L’OBS est parfois appelé
« organigramme fonctionnel» ou « OF » ; il représente « la structure des différents niveaux de
responsabilité de réalisation de l’ensemble des los de travaux d’un même organigramme des
tâches ».
Exemples de décomposition OBS
16
Gestion des projets
Le découpage structurel
Le découpage structurel repose sur la possibilité de découper le domaine en sous-ensembles
quasi indépendants. Il peut être à plusieurs niveaux.
Un premier niveau est celui du découpage d’un système d’information en domaine. Un domaine
pouvant être défini comme un sous-système du système d’information global, qui possède en
propre des informations et des processus.
Un second niveau de découpage est celui qui identifie des modules ; chaque module peut à son
tour être découpé en sous-modules. Ce découpage en module peut être approché par la vision
statique ou par la vision dynamique.
Le découpage par vision statique s’appuie sur une macro modélisation des entités, à l’aide d’un
model Entité Relation ou un diagramme de Classes UML. A chaque entité principale correspond
un module.
Le découpage par la vision dynamique s’appuie sur une identification des principaux processus
du domaine. A chaque processus correspond un domaine.
Exemple
Le découpage temporel standard
Contenu du découpage standard
Le découpage temporel des projets industriels relevant d’une production unitaire est la référence
initiale ; ce découpage type est le suivant :
• Etude de faisabilité
• Définition des solutions
• Conception détaillée
• Réalisation
L’étude de faisabilité comprend les travaux d’analyse, des travaux de recherche, des études de
terrain. Il s’agit de vérifier si le projet est techniquement réalisable. Par exemple pour construire
un immeuble il faut vérifier que le terrain et le sous-sol le permettent, à un coût acceptable.
La définition des solutions donne une représentation précise de l’objectif à atteindre. Les
solutions possibles sont étudiées de façon détaillée. Pour cela on utilise différents moyens, par
exemple faire des essais, élaborer des maquettes, construire un prototype. Au terme de cette
étape, une solution est alors choisie et l’on dispose de spécifications exactes.
La conception détaillée sert à préparer les contrats de réalisation. Ces contrats contiennent des
cahiers de charge pour les sous-traitants. Les spécifications techniques décrivent la mission et les
moyens pour la réaliser. Aucune ambigüité ne doit subsister Les fournitures livrées à l’étape
suivante sont acceptées sur la base de son contenu.
La réalisation est l’exécution des contrats par les sous-traitants, conformément aux cahiers des
charges. Cette étape se termine en général par une procédure d’acceptation officielle.
Dans ce découpage de référence, la réalisation du projet passe par une définition complète,
précise et détaillée de l’objectif. Les trois premières étapes représentent généralement 10% des
17
Gestion des projets
efforts et des dépenses. Le management de projet (planification, organisation, suivi) porte
essentiellement sur la phase de réalisation.
Problèmes posés par le découpage standard
Le découpage temporel standard ne peut guère être utilisé tel quel dans un aspect système
d’information. D’abord la notion de cahier de charges y est déclinée à plusieurs moments. En
effet, la plupart des étapes du cycle de développement peuvent conduire à un cahier de charge
qui oriente le travail de l’étape ultérieur. On parle alors d’un cahier de charge d’analyse ou d’un
cahier des charges de conception ou encore d’un cahier des charges de réalisation.
Ensuite dans le découpage temporel standard, on postule la possibilité pour le client d’établir une
description complète de ce qu’il attend. Or dans le domaine des systèmes d’information,
l’élaboration des spécifications est un problème majeur. Il y’a souvent une construction
progressive, qui s’appuie sur les allers-retours entre une solution de gestion des possibilités
techniques. Les besoins ne préexistent pas, ils émergent. Pour le chef de projet, les étapes
d’analyse et de conception sont risquées. Une part non négligeable du budget y est consacrée
sans toujours atteindre la qualité espérée. Par conséquent la gestion de projet commence dès le
début du projet.
De plus, l’élaboration d’un cahier des charges de réalisation est un travail coûteux. En effet
l’écriture des spécifications souffre de l’absence de composants réutilisables.
Dans les projets systèmes d’information, le problème de faisabilité se pose aussi de façon
particulière. Dans un sens, on peut toujours faire quelque chose, dans la mesure où les
contraintes ne sont en général pas d’ordres physiques, mais techniques, financiers ou
organisationnels.
Le découpage classique
Durant ces dernières années, les méthodes de développement de système d’information on
proposé un découpage temporel de référence, parfois appelé cycle classique.
Nous présentons ci-dessous ce découpage avec des correspondances entre le vocabulaire de la
méthode MERISE et celui issus de la norme AFNOR Z67-101.
NORME AFNOR MERISE
Schéma directeur
Etude préalable Etude préalable
• Exploration • Observation
• Conception • Conception/Organisation
• Appréciation • Appréciation
Conception détaillée Etude détaillée
Réalisation Etude technique
Réalisation
Mise en œuvre Mise en œuvre
18
Gestion des projets
Evaluation Qualification
Figure : Découpage temporel classique des méthodes de conception
• Schéma directeur : l’objectif du schéma directeur est de définir le scénario d’évolution
du patrimoine informatique d’une entreprise, sous l’un ou l’autre de ces trois angles :
o Evolution de l’architecture technique (matériel, réseaux)
o Evolution de l’architecture applicative (données communes, identification des
domaines, évaluation des applications) ;
o Evolution de la fonction informatique (méthodes, normes, outils)
• Etude préalable : l’objectif de cette étude est double. D’une part, il s’agit de faire des
choix structurant pour la future application. Evaluer l’adéquation de la solution aux
objectifs, choisir éventuellement entre plusieurs solutions, évaluer l’investissement
(budget, temps), ajuster la solution à l’enveloppe si nécessaire. D’autre part, il s’agit de
fournir une base de référence pour la suite du projet : le rapport d’étude préalable peut
donc être considéré comme un cahier des charges pour l’étude détaillée. Une étude
préalable comporte trois phases : observation, conception-organisation et appréciation.
• Etude détaillée : l’objectif de l’étude détaillée est de concevoir et décrire de façon
exhaustive la solution sur le champ de l’étude. Elle sera complétée par l’étude technique.
Les spécifications ainsi obtenues doivent faire l’objet d’un consensus entre futurs
utilisateurs et informaticiens. Elle représente le cahier des charges pour la réalisation. Le
résultat comprend toute la vision externe du système : l’interface homme-machine, la
description des traitements à une maille suffisamment fine pour qu’il n’y ait plus
d’ambigüité fonctionnelle, ainsi que les sorties. On y ajoute souvent l’organisation à
mettre en place et le planning détaillé.
• Etude technique : l’objectif de cette phase qui ne concerne que les informaticiens, est
d’organiser les structures physiques de données et de construire les traitements (dossier
programmes) en essayant de préparer la réutilisation du code. Le résultat comprend des
normes techniques, des dossiers de programmes et la structure des données. Il complète
le cahier des charges de réalisation.
• La réalisation (développement): l’objectif est de produire un logiciel testé. Cette étape
comprend donc les tâches d’élaboration de jeu d’essai, de programmation et de test. Elle
se termine par une procédure d’acceptation officielle appelée recette : le client fourni un
jeu d’essai et vérifie avec le fournisseur la conformité du logiciel à ce qu’il avait
demandé
• La mise en œuvre : l’objectif est de préparer le démarrage effectif de la nouvelle
application. Cette étape comprend notamment le paramétrage, la reprise ou l’alimentation
des données, le développement d’interface, la formation des utilisateurs, l’installation
d’environnement d’exploitation, la gestion du changement.
• La qualification : l’objectif est de réaliser des tests dans l’environnement opérationnel et
de tirer un bilan du système d’information installé, selon les différents critères qualité.
Les modèles de développement (autres découpages)
On considère aujourd’hui qu’on ne peut plus avoir une démarche unique, mais qu’il faut
construire le découpage temporel en fonction des caractéristiques de l’entreprise et du projet. On
s’appuie pour cela sur des découpages temporels génériques, appelés modèles de développement.
Les principaux modèles sont :
19
Gestion des projets
• Le modèle du code-and-fix ;
• Le modèle de la transformation automatique
• Le modèle en cascade
• Le modèle en V
• Le modèle en W
• Le modèle de décomposition évolutif
• Le modèle de la spirale
Le modèle du code-and-fix
Ce modèle repose sur la possibilité d’une détermination facile des besoins. Après une étape
brève de compréhension de l’objectif, l’application est développée. Ensuite plusieurs cycles de
mise au point en collaboration avec l’utilisateur du futur système permettent d’atteindre le
résultat visé.
20
Gestion des projets
Compréhension du problème
Programmation
Mise au point (amélioration)
Si non satisfait Fin
Figure : modèle code-and-fix
Le modèle de la transformation automatique
Le modèle de transformation automatique est basé sur la possibilité de transformer
automatiquement des spécifications en programme. L’essentiel de l’effort va donc porter sur une
description exhaustive des spécifications. Celles-ci devront être complètement validées. Une
succession de cycles de spécification/validation s’achève par la génération de code.
Spécification
Spécification
Validation
Transformation
Figure : modèle de transformation automatique
Le modèle en cascade
21
Gestion des projets
Le modèle en cascade est totalement opposé au modèle code-and-fix. Il a comme objectif majeur
de jalonner rigoureusement le processus de développement et de définir de façon précise les
rôles respectifs du fournisseur et du client.
Le découpage temporel se présente donc comme une succession d’étapes correspondant à une
approche descendante. Chaque étape donne lieu à une validation officielle : on ne passe à l’étape
suivante que si le résultat du contrôle est satisfaisant. Sinon, on modifie le livrable pour qu’il
devienne acceptable. En revanche, il n’ya pas de retour possible sur les options validées à l’issue
d’étapes antérieures.
Etude de faisabilité
Validation
Définition des besoins
Validation
Conception générale
Validation
Conception détaillée
Validation
Codage
Test unitaire
Intégration
Test intégration
Implémentation
Recette
Figure : modèle en cascade
Le modèle en V
Ce modèle est une amélioration du modèle en cascade. Il vise d’une certaine façon, à réduire ce
que l’on a appelé effet tunnel.
Dans ce modèle, on va s’attacher dans chacune des étapes de la première branche du V à
expliquer les critères d’appréciation et d’acceptation du système aux étapes correspondantes de
la deuxième branche du V.
22
Gestion des projets
Dans des projets importants, il est recommandé de décomposer le système en sous ensemble
(découpage structurel) : l’étape de définition fonctionnelle du besoin conduit à un découpage en
composants, donnant lieu à études, réalisations, tests et recettes séparés, avant l’intégration.
Etude d’opportunité Bilan du projet
Etude de faisabilité Bilan généralisation
Def. fonctionnelle des besoins Bilan site pilote
Etude détaillée Recette fonctionnelle
Etude technique Test d’intégration
Réalisation
Figure : modèle en V
23
Gestion des projets
Le modèle en W
Ce modèle enrichie le modèle en V dans le même esprit d’anticipation sur le livrable final. La
première partie du W vise à dégager avec le client des orientations solides pour la composition
ou bien à explorer les possibilités d’une nouvelle technique. Le développement de maquette ou
prototype permet une validation plus concrète, voire une expérimentation.
Etude des Orientation pour les
besoins bruts spécifications
Conception de Maquettes ou prototypes
haut niveau
Vérification des flux logiques
Figure : modèle en W
24
Gestion des projets
Le modèle de décomposition évolutif
L’objectif du modèle de développement évolutif est de construire progressivement le système de
façon participative. Il repose sur l’idée que les besoins ne peuvent s’exprimer qu’après une
expérimentation même sur le système rudimentaire ou incomplet. Chaque cycle aboutit à une
nouvelle version du système : on arrête lorsque le client juge le système satisfaisant.
Détermination des besoins
Programmation
Expérimentation
Version n
Figure : modèle de développement évolutif
Le modèle de la spirale
Le modèle de la spirale repose sur le même principe que le modèle évolutif, mais il s’inscrit dans
une relation contractuelle entre le client et le fournisseur. De ce fait les engagements et
validations présentent un caractère formalisé.
Chaque cycle donne lieu à une contractualisation préalable, s’appuyant sur les besoins exprimés
lors du cycle précédent. Un cycle peut être considéré comme une étape, qui comporte les six
phases suivantes :
1. Analyse du risque
2. Développement d’un prototype
3. Simulation et essais du prototype
4. Détermination des besoins à partir des résultats des essais
5. Validation des besoins par un comité de pilotage
6. Planification du cycle suivant.
Les découpages spécifiques
Certains découpages sont liés soit à une méthode, soit à un type de projet bien particulier. Nous
en proposons quelques uns :
Le cycle RAD
25
Gestion des projets
Ce découpage est lié à la méthode RAD de développement rapide d’application. L’objectif est
d’obtenir dans des délais réduits une application de qualité : pour ce faire, une participation
organisée et contrôlée des utilisateurs est mise en place. En ce qui concerne le découpage
temporel, cela conduit à introduire systématiquement une session participative entre le groupe de
travail et le groupe utilisateurs au milieu de chaque phase.
Travaux préparatoires
Session participative
Travaux de conclusion
Figure : la structure d’une phase dans le cycle RAD
Au niveau ci-dessus, le découpage en étapes est conjugué entre modèle en cascade et modèle en
spirale. L’étape construction se compose d’un nombre variable de cycles de prototypage, mais
elle est strictement contenue dans une enveloppe temps à ne pas dépasser, ce qui limite le
nombre de cycles.
Initialisation
Expression des besoins
Conception
Construction
N fois
Mise en œuvre
Figure : le cycle RAD 26
Gestion des projets
Le cycle ERP
La mise en place d’un progiciel de gestion intégré, souvent appelé ERP s’appuie sur un
découpage spécifique.
Il s’agit de construire, en tirant le meilleur parti du progiciel, un système améliorant la
performance de l’entreprise.
Deux étapes doivent donc être menées en parallèle : Description des processus et Formation au
progiciel.
Ensuite il y a autant de cycles d’analyse- paramétrage-prototypage qu’il y a de processus. La
validation par le Comité de pilotage permet une simulation en grandeur réelle. Il faut alors
prendre en compte ce qui est resté en dehors du champ couvert parle progiciel.
Initialisation
Description des processus Formation au progiciel
Analyse processus/progiciel
Paramétrage processus/progiciel
Prototypage processus/progiciel
Simulation grandeur réelle
Fermeture des trous fonctionnels
Figure : cycle ERP
27
Gestion des projets
Exercices :
Proposition de modèle de découpage pour les sites web avec les CMS Joomla (site
institutionnels, vente en ligne).
Différence entre les modèles code and fix et évolutif.
28
