Introduction à la conduite de projets informatiques reposant sur un

Introduction à la conduite de projets
informatiques reposant sur un langage orienté
objets
Olivier Sigaud
Edition 2005-2006
Table des matières
1 Vocation de ce document
2
2 La méthodologie : pour quoi faire ?
2
3 Aspects techniques de la conduite de projets
3.1 Le cycle de vie d’un projet informatique . . . . .
3.1.1 Les grandes activités du cycle de vie . . .
3.1.2 Modèles de cycles de vie . . . . . . . . .
3.2 Analyse et conception . . . . . . . . . . . . . . .
3.2.1 Analyse . . . . . . . . . . . . . . . . . .
3.2.2 Conception . . . . . . . . . . . . . . . .
3.3 Mise en œuvre de l’analyse . . . . . . . . . . . .
3.3.1 Introduction . . . . . . . . . . . . . . . .
3.3.2 Cas d’utilisation et diagramme des cas . .
3.3.3 Le diagramme de classes d’analyse . . .
3.3.4 Les diagrammes de séquences d’analyse .
3.4 Mise en œuvre de la conception . . . . . . . . .
3.4.1 Introduction . . . . . . . . . . . . . . . .
3.4.2 Le diagramme de classes de conception .
3.4.3 Le diagramme de séquence de conception
3.4.4 Les diagrammes états-transitions . . . . .
3.4.5 Conception avancée . . . . . . . . . . .
3.4.6 Implémentation et intégration . . . . . .
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
4
7
8
9
9
10
10
10
12
13
14
14
15
16
16
17
18
3.5
.
.
.
.
.
.
19
19
20
20
20
21
4 Aspects organisationnels et humains de la conduite de projets
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Quelques causes classiques de dysfonctionnement . . . . . . . . . . .
4.3 Quelques lignes sur le rôle de chef de projet . . . . . . . . . . . . . .
22
22
22
23
5 Conclusion générale
24
6 NETographie (dernière mise à jour : 2001-2002)
6.1 Programmation objets et UML . . . . . . . . . . . . . . . . . . . . .
6.2 Les design patterns (ou patrons de conception) . . . . . . . . . . . .
25
25
25
3.6
Outils du génie logiciel . . . . . . . . . . . . . . . . .
3.5.1 Génération de squelettes . . . . . . . . . . . .
3.5.2 Reverse engineering . . . . . . . . . . . . . .
Conventions de notation et codage propre d’une classe
3.6.1 Conventions de notation . . . . . . . . . . . .
3.6.2 Commentaires . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1 Vocation de ce document
Ce document s’adresse à de futurs ingénieurs qui seront confrontés dans leur vie
professionnelle au développement d’applications informatiques de taille variable reposant sur des langages orientés objets. Il est destiné à présenter quelques connaissances
de base sur la conduite de projets informatiques mettant en œuvre une méthodologie orientée objets et, en particulier, utilisant le langage UML. En outre, il développe
quelques conseils et réflexions plus directement applicables à la conduite du projet
autour duquel est construit le cours in204.
Les concepts de base de la programmation orientée objets ainsi que les éléments
du langage UML et les diagrammes correspondants sont supposés connus. Le lecteur
est invité à se référer aux polycopiés de JAVA ([Sig05b]) et UML ([Sig05a]) pour une
présentation de ces aspects préliminaires.
2 La méthodologie : pour quoi faire ?
Il y a un monde entre l’activité d’un développeur passionné qui réalise son logiciel
dans son coin et le développement industriel d’une application de grande taille qui peut
rassembler quelques centaines de développeurs sur plusieurs années.
2
Dans le premier cas, la méthodologie est affaire d’habitudes personnelles et se
constitue au fil de l’expérience. A chacun de trouver ses propres recettes pour développer vite et bien. Le développeur isolé se constitue son propre style de programmation, son répertoire d’astuces pour résoudre des problèmes de codage qui reviennent
souvent, l’ensemble des comportements qui lui permettent de limiter au maximum la
fastidieuse chasse aux bugs.
Dans l’industrie, les soucis d’efficacité, de réutilisation de solutions connues, ou de
programmation sans erreur sont bien sûr pris en charge, mais les défis supplémentaires
que pose le partage du travail viennent s’y ajouter. Au fil du temps, les projets informatiques sont devenus de plus en plus complexes et ce phénomène n’a fait que s’accentuer avec l’apparition et la propagation des langages orientés objets. Les équipes de
conception deviennent donc de plus en plus importantes, entraînant un besoin croissant
de communication entre les divers spécialistes.
D’une part, le besoin exprimé par le client – souvent incompétent dans le domaine
de la conception informatique – est généralement flou et incomplet. Réciproquement,
le concepteur est étranger au monde du client. Il s’agit donc de trouver un langage
commun entre ces deux mondes pour instaurer un dialogue et identifier les clauses
contractuelles de manière satisfaisante pour les deux parties. Il résulte de ce constat
que – malgré tous les efforts déployés – l’évolution du cahier des charges au cours du
développement est quasiment inévitable.
D’autre part, le développement lui-même est effectué à plusieurs, les différentes
parties d’un logiciel sont toujours plus ou moins interdépendantes, si bien qu’à tout
moment du cycle de vie d’un projet, de la spécification à la validation finale, les développeurs et concepteurs doivent se mettre d’accord sur les fonctionnalités en interagissant au quotidien.
Le problème du génie logiciel est donc de :
– limiter l’évolution du cahier des charges et réduire le risque de malentendu entre
clients et concepteurs ainsi qu’entre équipes de concepteurs en s’appuyant sur
un langage de modélisation standard et non ambigu ;
– répondre le plus rapidement possible à une évolution du cahier des charges en
réduisant le temps du cycle élémentaire qui sépare les spécifications de la réalisation ;
– limiter au maximum les répercussions d’une modification dans une phase du
développement sur les autres phases ;
– fournir des moyens de communication et de structuration du travail collectif les
plus efficaces possible pour permettre une collaboration distribuée ;
– à terme, automatiser le passage de la spécification à l’implémentation.
Afin de présenter les solutions du génie logiciel à ces problèmes, nous adoptons le
3
plan suivant.
Dans une première partie, nous nous focalisons sur les aspects techniques liés à la
mise en œuvre d’UML. Nous commençons par présenter les différentes activités correspondant au développement d’un logiciel complexe en équipes, puis nous énumérons
différentes façon d’organiser ces activités dans le temps.
Cette présentation nous conduit à expliciter la différence fondamentale entre les
activités qui relèvent de l’analyse et celles qui relèvent de la conception. Sur cette
base, nous donnons quelques indications sur la façon dont les différents diagrammes
proposés par UML doivent être utilisés dans le cadre de l’analyse et de la conception.
En particulier, nous faisons ressortir l’objectif ultime qui consiste à formaliser clairement les interactions entre les codes développés par différentes équipes et à se reposer sur un outil de génération automatique de squelettes de code pour entériner cette
formalisation.
Dans une seconde partie, nous abordons les aspects humains et organisationnels de
la conduite de projets en équipe. Nous nous bornons à mettre en évidence quelques
difficultés couramment rencontrées et à suggérer des pistes de réflexion pour affronter
ces difficultés le moins naïvement possible.
3 Aspects techniques de la conduite de projets
3.1 Le cycle de vie d’un projet informatique
3.1.1 Les grandes activités du cycle de vie
On peut identifier différentes activités dans toute méthodologie de réalisation de
logiciels. Si le nom des activités et les découpages entre activités varient parfois, c’est
surtout la façon dont on les enchaîne plus ou moins séquentiellement qui change d’une
méthodologie à l’autre. Classiquement, on retrouve les activités suivantes :
Expression des besoins Cette première activité est toujours informelle, souvent peu
précise. Elle émane du client, aidé par des gens capables de confirmer que le travail est
techniquement réalisable. Elle produit le cahier des charges. Cette première activité se
focalise sur les fonctionnalités externes du logiciel : ce qu’il doit faire et surtout sur la
façon de l’utiliser. Le cahier des charges peut être une base pour lancer un contrat.
Spécification/Analyse Le cahier des charges résultant de l’activité précédente est
trop imprécis pour servir de base à la conception. On a besoin d’un document qui soit
à la fois le plus rigoureux possible pour servir de point d’entrée aux concepteurs, tout
4
en restant totalement compréhensible par le client. Ce document est appelé « spécification » et fait généralement l’objet d’une pré-étude contractuelle.
La nécessité d’être compréhensible par le client et la nécessité d’être précis techniquement pour orienter suffisamment les choix du concepteur sont antagonistes. Ce
dilemme conduit à divers raffinements de cette activité en documents de spécification
intermédiaires, réalisant un plus ou moins bon compromis.
Ainsi, on peut établir des cahiers des charges structurés qui formalisent le besoin,
des cahiers de recueil des exigences qui ré-expriment techniquement ces besoins, ou
encore distinguer des spécifications générales, plutôt à l’usage du client, et des spécifications détaillées, plutôt à l’usage du concepteur. Dans ce cas, établir les spécifications
détaillées revient à entamer l’activité de conception.
Face au flou terminologique et méthodologique qui entoure ces différentes activités,
on préférera les regrouper en une activité, l’analyse, et s’en tenir à la distinction entre
analyse et conception qui sera présentée dans la section 3.2, à la page 8.
Conception Cette activité consiste à trouver pour chaque besoin exprimé une solution informatique compatible avec l’ensemble des autres besoins. On détaillera davantage cette activité dans la section 3.2.2, à la page 9.
Implémentation L’implémentation consiste à réaliser le programme conformément
aux critères définis dans les phases précédentes. Cette activité reste couramment celle
qui prend le plus de temps, surtout si on a négligé les activités précédentes. En particulier, le coût d’une erreur (en temps et en main d’œuvre ...) est d’autant plus important
qu’elle a lieu dans les phases amont d’un projet.
Tests et vérification Cette activité permet de détecter les erreurs de programmation
et de vérifier que l’application fonctionne (l’application fait quelque chose, apparemment dans le respect des spécifications).
En partie simplifiée par la rigueur et le typage des langages de programmation
modernes, cette activité reste indispensable, surtout en ce qui concerne les fonctionnements dit d’exception.
Chaque ligne de code devrait être exécutée au moins une fois pendant ces tests.
Pour un maximum de garantie, cette opération doit être relancée à chaque modification
et gagne grandement à être automatisée. Il existe des outils permettant d’automatiser
les tests de l’utilisateur en simulant son comportement devant l’écran.
Validation La validation correspond à la recette du logiciel. Elle est réalisée par le
client pour s’assurer que l’application correspond bien au besoin qu’il a initialement
5
exprimé. Le cahier de recette effectué par ses soins s’appuie sur les spécifications.
C’est lors de cette activité que le client indique si, en fin de compte, il est satisfait ou
non. Si ce n’est pas le cas, il faut identifier l’insuffisance et remonter jusqu’à l’activité
en cause. Si c’est le besoin initial qui a été mal exprimé, il faut tout recommencer.
Bien que réalisée par le client lorsque le produit est terminé, le concepteur gagne à
inclure cette activité dans le cycle de conception lui-même. Ceci évite les surprises de
dernière minute. Cependant, l’aspect généralement interactif de cette activité la rend
pénible quand elle est répétée trop fréquemment.
Documentation, maintenance et archivage Différents types de documentation sont
généralement demandés par le client : un manuel destiné à l’utilisateur (manuels d’utilisation et de référence), et une documentation de réalisation. Cette activité, qui peut
passer pour une corvée, est non seulement nécessaire pour satisfaire la demande du
client, mais elle est également vitale pour le concepteur lui-même qui pourra l’exploiter pendant la conception. De plus, une documentation commencée (et maintenue) le
plus tôt possible permet d’assurer sa cohérence avec le produit qu’elle décrit.
De même, les problèmes de maintenance sont de plus en plus pris en compte dès
la phase de spécification car celle-ci influe lourdement sur la conception même (mise
en place de tests intégrés ou autres fonctionnalités spécialisées...).
Quant à l’archivage, les problèmes ne sont pas les mêmes suivant que le système à
développer est destiné au grand public et risque alors d’être totalement périmé au bout
de deux ans (programme de commande d’un magnétoscope) ; ou bien s’il est destiné à
être intégré à une centrale nucléaire ou à un sous-marin. Dans ce cas, la durée de vie
du système global est de l’ordre de 30 ans, et malgré (ou à cause de) l’évolution technologique il faut être capable d’apporter des modifications pendant de longues années.
Il peut alors être nécessaire d’archiver non seulement les sources des programmes développés mais également les compilateurs et autres outils utilisés, voire les stations de
travail munies de leur environnement d’exploitation sous lesquels fonctionnaient ces
outils. En général, il est moins coûteux de redévelopper le produit à partir des spécifications d’origine (d’où l’importance de la documentation). Malheureusement, pour les
très vieux projets, elles sont parfois inexistantes ou trop imprécises. Il est alors nécessaire de faire appel aux techniques de Reverse engineering (voir paragraphe 3.5.2 à
la page 20).
Une autre fonction de l’archivage est de mémoriser la compétence de l’entreprise.
Dans ce cas, ce n’est pas le produit réalisé qui est intéressant, mais les tours de main et
autres secrets de fabrication qui ont été nécessaires pour parvenir au résultat.
6
3.1.2 Modèles de cycles de vie
L’enchaînement des différentes activités précédentes peut se faire selon différents
modèles de cycle de vie, qui enchaînent ces activités en phases plus ou moins successives.
Le cycle de vie linéaire
Dans le principe, chaque phase est conçue pour être indépendante de celles qui
lui succèdent. Dans ce modèle, on s’efforce de s’en tenir à ce principe, si bien
qu’on ne commence une phase que lorsque la précédente est terminée. Ce style
d’enchaînement apparaît toutefois difficile à planifier et peu flexible. Une erreur de spécification ou d’analyse coûte très cher car elle est vue tardivement et
entraîne une lourde perte de temps. En pratique, il s’avère que la réalisation des
phases en aval conduit systématiquement à des retours sur les phases plus amont.
Le cycle en V
Expression des besoins
Recette
Spécification générale
Validation
Spécification détaillée
Test
Implémentation
F IG . 1 – Le cycle en V : le client se situe tout en haut, le développeur tout en bas.
Ce modèle a longtemps été le plus utilisé. Comme l’illustre la figure 1, il consiste
à concevoir progressivement et de plus en plus profondément l’application, puis
à remonter depuis le test des composants élémentaires (dès qu’ils sont terminés)
jusqu’à l’intégration et la validation finale des besoins. Il se distingue du modèle
linéaire par le fait qu’on peut commencer une activité avant d’avoir terminé la
précédente. Malgré l’amélioration par rapport au modèle précédent, l’inconvénient de ce modèle reste que le client ne voit le produit que lorsque celui-ci est
terminé, avec tous les risques que cela comporte.
Le modèle en spirale
L’idée du modèle en spirale est de fournir le plus rapidement possible un prototype permettant de valider les concepts, et parfois de répondre à un appel d’offre
avec un prototype de type « illustratif ». Le principe est alors de fournir régulièrement une nouvelle version de l’application en se rapprochant progressivement
7
de l’application finale.
Un des avantages de ce modèle est de garantir – en cas de glissement des délais –
une application qui tourne, bien que ne présentant pas toutes les fonctionnalités.
Par son aspect itératif, ce modèle nécessite un cycle de développement le plus
court possible de la spécification à la réalisation des prototypes. La programmation orientée objets se prête bien à la mise en œuvre de ce type d’approches,
car des versions non spécialisées de classe peuvent naturellement servir d’implémentation grossière mais rapidement opérationnelle. Il est toutefois rare que les
premiers prototypes ne soient pas profondément bouleversés par les itérations
successives.
Avec UML : un processus itératif Le cœur de la démarche d’emploi d’UML consiste
à tirer parti de la complémentarité des différentes vues proposées par le langage
et des redondances que cette complémentarité implique. Plutôt que de constituer
les vues les unes après les autres, il est avantageux de les constituer en parallèle,
le travail dans une vue appelant des modifications dans les autres vues. L’analyse
et la conception évoluent ainsi rapidement, puis finissent par se stabiliser lorsque
les vues convergent. L’analyste et le concepteur doivent donc se laisser guider
par un souci de cohérence entre les vues vis-à-vis du problème modélisé. D’une
façon générale, pour une partie donnée d’un logiciel, on suite l’ordre analyseconception-implémentation mais, compte tenu de la diversité des applications,
à un niveau plus global le processus de développement suit un ordonnancement
différent à chaque fois en fonction des contraintes qui pèsent sur chacune des
équipes de développement. La planification du déroulement d’un projet logiciel
est un métier à part entière, pour lequel existent des outils dédiés de gestion
des plannings. Nous allons tout de même pointer dans la suite un certain nombre
d’interdépendances induites par UML et qui ont une influence sur le déroulement
de tous les processus.
3.2 Analyse et conception
Une bonne méthodologie de réalisation de logiciels suppose une bonne maîtrise de
la distinction entre l’analyse et la conception. Nous allons voir que le respect d’une
distinction entre des phases d’analyse et de conception rigoureusement indépendantes
n’est pas tenable, mais il est important d’avoir en tête la différence lorsqu’on s’apprête
à réaliser un logiciel. Encore une fois, il est important de garder à l’esprit qu’UML
n’offre pas une méthodologie pour l’analyse et la conception, mais un langage qui
permet d’exprimer le résultat de ces phases.
8
3.2.1 Analyse
L’analyse répond à la question « que faut-il faire ? ». Cette activité a pour but de
se doter d’une vision clairement formalisée du problème posé et du système à réaliser
en déterminant les éléments concernés et leurs interactions. Son résultat est un modèle
représentant le problème et les principaux éléments du système à réaliser. Elle regroupe
les phases d’expressions des besoins et de spécification des méthodologies classiques.
Il est important d’insister sur les caractéristiques suivantes de l’analyse :
– elle nécessite de comprendre en détail les problèmes et concepts de l’utilisateur,
– elle doit être (en principe) indépendante des aspects techniques,
– les choix portant sur les modèles résultants doivent être justifiés (simplification
du modèle, explicitation des hypothèses, etc.).
Les documents produits dans le cadre de l’analyse vont permettre aux auteurs de la
spécification de s’assurer que l’équipe chargée du développement a bien compris le
problème qui lui est posé et qu’aucun aspect pertinent n’a été oublié. La conception
peut alors démarrer sur des bases saines.
3.2.2 Conception
La conception, menée à la suite de l’analyse, répond à la question « comment faire
ce qu’il faut faire ? ». Le processus de conception a pour but de figer les choix techniques (langages de programmation, algorithmes, bibliothèques, architectures matérielles, etc.). Il fixe les performances (si elles ne font pas déjà partie du cahier des
charges, par exemple quand le contexte opérationnel l’impose), et définit la stratégie
de programmation :
– choix des structures de données (et de leur persistance),
– choix des algorithmes à utiliser,
– choix des langages,
– etc.
La phase la plus amont de la conception consiste généralement à identifier une « approche » du problème à résoudre qui va induire un style de conception plus ou moins
adapté à ce problème. Le résultat de la conception est une ébauche d’implémentation,
décrite par un modèle précis du système à réaliser. Nous allons voir que des ateliers de
génie logiciel permettent un passage très naturel de la conception à l’implémentation.
9
3.3 Mise en œuvre de l’analyse
3.3.1 Introduction
Les éléments d’un système informatique peuvent être décrits selon trois points de
vue plus ou moins dépendants les uns des autres :
– la vue fonctionnelle, qui indique ce que doivent faire les objets du programme.
Cette vue est réalisé à l’aide des cas d’utilisation.
– la vue structurelle (ou statique), qui fait apparaître la composition hiérarchique
des objets et de leurs relations. Cette vue est réalisé à l’aide des diagrammes
de classes.
– la vue dynamique, qui prend en compte le déroulement du fonctionnement de
l’application. En analyse, cette vue est réalisée à l’aide des diagrammes de
séquence.
Ces points de vue peuvent s’appliquer de manière récursive à chacun des composants
d’une application.
Dans le cadre de l’analyse, il est fréquent de commencer par identifier les cas d’utilisation pour partager le travail, puis on construit en parallèle les diagrammes de classes
et de séquence correspondant à chacun des cas. Nous verrons cependant que le recours
aux cas d’utilisation n’est pas universel. Nous allons nous pencher sur ces activités
dans les sections qui suivent.
3.3.2 Cas d’utilisation et diagramme des cas
Le diagramme des cas est une vue synthétique. Son rôle essentiel est d’inciter les
analystes et concepteurs à représenter le problème du point de vue du client dès la
phase initiale du projet. Commencer par établir le diagramme des cas permet de mener
un développement orienté utilisateur et de découper le système global en grandes tâches
qui pourront être réparties entre les équipes de développement.
Il permet en outre de s’assurer d’un seul coup d’œil que l’ensemble des exigences
fonctionnelles du système ont bien été prises en compte. Pour le dessiner, on s’attache
dans un premier temps à identifier les principales familles d’acteurs, en fonction de leur
rôle vis-à-vis du système.
Reconnaître un acteur Un acteur est un agent (humain ou logiciel) externe au système en cours de développement. Il faut, même dans ce second cas, que le système
soit actif – voire qu’il initialise le contact – sinon il peut être résumé en une donnée.
Par exemple, si l’on fait appel à une horloge externe pour mettre à jour l’horaire, cette
horloge ne peut être considérée comme un acteur. Un logiciel de guidage de véhicule
embarqué, par contre, qui doit interroger par satellite une base de données lui indiquant
10
le trafic, peut considérer le logiciel exploitant la base de données comme un acteur lui
communiquant les bouchons.
Reconnaître un cas d’utilisation Les cas d’utilisation s’obtiennent en identifiant les
actions ou événements discrets demandés ou réalisés par les acteurs autour du système.
On distingue dans la pratique deux familles de cas :
– les cas correspondant à des objectifs de l’utilisateur ;
– les cas d’interaction proprement dit, qui peuvent n’être que des moyens servant
un objectif.
La première famille est particulièrement importante, puisqu’elle spécifie les besoins
des acteurs. Réaliser séparément chacun des cas d’utilisation permet de s’assurer que
l’on répond bien au besoin de chaque classe d’utilisateurs.
Décrire un cas d’utilisation La description textuelle des cas d’utilisation est particulièrement utile dans le cas (fréquent) où une société de service en informatique non
spécialiste du domaine d’application (ou toute équipe remplissant ce rôle) est chargée
d’informatiser un processus réalisé par des humains. Le premier travail de conceptualisation consiste à interviewer les différents acteurs pour comprendre les processus, si
bien que la description textuelle se trouve adaptée au recueil et à la mise en forme
des résultats de ces interviews. Toute la difficulté consiste à s’arrêter au bon niveau
de détail pour ne pas trop empiéter sur le travail associé aux autres vues. Par ailleurs,
la description textuelle est l’un des documents les plus adaptés à la discussion avec
le client au moment où l’on s’assure que l’on a correctement capturé l’ensemble des
exigences fonctionnelles du système à réaliser.
Affiner les liens entre cas d’utilisation Pour faire la distinction entre des liens de
type extend ou de type include 1 , il suffit de considérer qu’un cas utilisé résulte d’une
décomposition effectuée à des fins de factorisation. Il en va différemment du cas étendu
qui ajoute des fonctionnalités à un cas existant mais englobe ce cas. En général, le cas
normal est utilisé par une famille d’acteurs, le cas qui l’étend est destiné à une autre
famille d’acteurs.
Un cas d’utilisation doit être décomposé en plusieurs sous-cas uniquement si un
besoin exprès de l’utilisateur est exprimé tôt dans le processus d’analyse et de spécification. Sinon, un premier diagramme se contentera des cas d’utilisation standards et
d’autres diagrammes, lors d’itérations postérieures, mentionneront les cas particuliers
qu’il est nécessaire d’étendre.
1 Voir
le polycopié [Sig05a] pour une définition.
11
Conseils pratiques Pour construire la vue fonctionnelle, il peut être avantageux de
commencer par une première ébauche de diagramme des cas visant l’exhaustivité,
ébauche qui se raffinera lors de la description fine des différents cas.
La description textuelle des cas donne les premiers éléments pour l’identification
des classes, opérations et attributs. Elle constitue donc un bon préalable à l’écriture
des diagrammes de classes. En effet, repérer les mots et les verbes importants dans
ces descriptions textuelles permet d’extraire les objets et les méthodes pertinentes pour
l’analyse.
Prise de recul Tous les aspects méthodologiques portant sur les cas d’utilisation et
le diagramme des cas sont particulièrement utiles dans le cadre des systèmes de traitement de l’information faisant apparaître de nombreux acteurs et de nombreuses fonctionnalités. Dans de tels contextes, ils constituent un excellent guide pour le découpage
de l’application en fonctionnalités plus ou moins indépendantes, donc un partage du
travail au sein de l’équipe de projet.
Mais ce contexte n’est pas universel. Dans un projet de type recherche mettant au
prise un utilisateur unique avec un système complexe, un tel découpage peut s’avérer
relativement inopérant. Il faut donc réfléchir avant d’avoir recours à une telle approche.
L’idée générale à retenir est qu’un bon partage du travail dans le cadre de l’analyse
consiste en général à séparer dans la mesure du possible des parties du projet concernées par des fonctionnalités indépendantes.
3.3.3 Le diagramme de classes d’analyse
Chauffeur
Age
Nom
effectue
0..*
1
Trajet
1..*
comprend
1
conduit
2..*
0..*
Bus
dessert
1..*
2..*
Station
F IG . 2 – Un diagramme de classes d’analyse
Les diagrammes de classes d’analyse servent à identifier les principaux objets du
domaine modélisé par le système, à établir leurs relations, et à les regrouper en entités
plus vastes donnant des vues partielles sur le système.
12
Découpage en packages pour l’analyse En règle générale, on aura tendance à effectuer un regroupement en packages qui suit plus ou moins le découpage en cas
d’utilisations. Mais certaines classes plus centrales que d’autres seront présentes dans
de nombreux cas d’utilisations. On cherche alors à identifier et regrouper des ensembles
de classes qui ont une forte connectivité.
Une fois le découpage en cas obtenu, on réalise un diagramme des objets participants au cas, ce qui se traduit par un diagramme de classes pour chaque cas. Cela
peut conduire à identifier un package par cas mais, dans la pratique, le découpage
en packages suit rarement cette logique. En particulier, de nombreuses classes interviennent dans plusieurs cas, les classes qui apparaissent dans le maximum de cas sont
les plus centrales, on effectue souvent le regroupement en packages en se fondant sur
cette notion de centralité.
Choix des objets représentés Dans des diagrammes de classe d’analyse, on ne fait
en général apparaître que des objets du domaine modélisés, souvent appelés « objets
métier ». En effet, on décrit le monde dans lequel on va travailler et non pas le logiciel
que l’on va réaliser, donc tous les objets qui n’ont de sens que pour le fonctionnement
du logiciel sont à exclure.
On peut éventuellement agrémenter les objets choisis de quelques attributs ou opérations, mais à condition que ces éléments soient pertinents dans le domaine et non pas
dans l’application à développer. L’essentiel est de s’efforcer à ce stade de ne pas faire
des choix qui relèvent de la conception.
3.3.4 Les diagrammes de séquences d’analyse
Traditionnellement, dans les méthodologies orientées objets, ou dans les développements classiques, les concepteurs utilisent des scénarios typiques d’utilisation du
logiciel, pour mieux comprendre et identifier les besoins du client. Les diagrammes de
séquences permettent de formaliser le déroulement de ces scénarios. Ils ont pour objet
de décrire des scénarios particuliers de comportement des acteurs vis-à-vis du système.
Un diagramme de séquences d’analyse permet de vérifier que tous les acteurs,
les classes, les associations et les opérations ont bien été identifiés dans les diagrammes
de cas et de classes. Par ailleurs, il constitue une spécification utile pour la conception
des algorithmes ou des automates.
Construire un diagramme de séquences peut amener à raffiner la description
des use cases, à identifier de nouveaux objets qu’il va falloir ajouter aux diagrammes
de classes, ou à revoir un découpage en packages lorsque deux objets apparaissent
fortement corrélés.
13
Jean:Personne
:Ascenseur
1
0
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
1
0
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
250 ms
Appel (2ième étage)
Allumage bouton d’appel
Ouverture porte(2ième étage)
Ouverture porte(3ième étage)
Jacques:Personne
Appel (RdC)
Allumage bouton d’appel
Ouverture porte(RdC)
Choix Etage 3
Allumage voyant 3
Ouverture porte(3ième étage)
1
0
0
1
0
1
0
1
0
1
0
1
0
1
250 ms
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
0
1
F IG . 3 – Un diagramme de séquences d’analyse
À noter que déterminer l’ensemble des diagrammes de séquences qui permet
de couvrir tous les modes de fonctionnement pertinents pour une application est une
question difficile.
3.4 Mise en œuvre de la conception
3.4.1 Introduction
La conception est la phase qui permet de passer de la description claire d’un problème, dégagée par l’analyse, à la réalisation informatique de sa solution, lors de l’implémentation. Il s’agit d’une activité qui peut être extrêmement complexe et qui requiert
un niveau d’expertise très élevé.
Là où un novice risque de concevoir des solutions médiocres, lourdes, maladroites,
difficilement modifiables et réutilisables, un chef de projet expérimenté peut au contraire
trouver immédiatement une solution simple, claire, élégante à un même problème de
conception.
Face à cette situation où le niveau d’(in)expérience est un facteur crucial pour la
qualité du résultat, la tendance du génie logiciel est de préconiser des méthodes robustes et efficaces, bien éprouvées, qui permettent, si on les suit rigoureusement, d’arriver à un niveau de qualité honorable quel que soit le niveau d’expertise du concepteur
concerné.
14
La démarche que nous proposons ici est fondée sur les mécanismes suivants :
– une transformation progressive des diagrammes de classes et de séquence d’analyse en diagrammes de conception, par ajout de classes, enrichissement des informations portées par les classes et formalisation des messages impliqués dans
les diagrammes de séquence ;
– le recours à des outils de génération automatique de squelettes de code pour figer
un contrat entre équipe permettant le passage de la conception à l’implémentation.
L’idée centrale est que formaliser totalement les méthodes de communication entre les
équipes permet par la suite aux différentes équipes de coder indépendamment les unes
des autres, en ayant des garanties sur les méthodes offertes par les classes développées
ailleurs. En outre, disposer d’un squelette de code complet peut contribuer à résoudre
des problèmes de compilation locale à une équipe, quand cette compilation fait appel à
des classes développées ailleurs.
3.4.2 Le diagramme de classes de conception
De l’analyse à la conception Nous avons dit que, dans le cadre de l’analyse, seuls
les noms des attributs et les principales méthodes publiques de la classe doivent être
mentionnées. Dans le cadre d’une conception au contraire, la description des classes
doit être exhaustive. En effet, si l’on a recours à un outil de génération de squelette de
code avant de passer à l’implémentation, il faut que ce squelette soit complet dès la
conception, pour ne pas engendrer des aller-retours. Cette opération suppose de déterminer un type pour toutes les données manipulées par l’application, ce qui ne va pas
de soi. Pour certains éléments simples comme une date, par exemple, choisir entre les
représenter à l’aide d’une classe ou bien d’un type de base – une chaîne de caractère –
est un choix non trivial qui peut demander de l’expérience.
Mais les différences entre un diagramme de classes d’analyse et un diagramme de
classes de conception ne se limitent pas au seul niveau de description. Les diagrammes
de classes d’analyse ne font généralement apparaître que des classes métiers. De nombreuses classes spécifiques du logiciel réalisé seront ajoutées lorsque l’on passe de
l’analyse à la conception.
Si, en pratique, passer à la conception revient à enrichir considérablement les diagrammes de classes d’analyse, il faut garder à l’esprit le fait que cet enrichissement
résulte d’un profond changement de point de vue sur le projet et non d’un simple
affinement de la vision précédente.
Découpage en packages pour la conception Du point de vue de la conception, le
souci majeur auquel répond le découpage en packages est un souci de compilation.
15
Il faut assurer une indépendance maximale entre les packages et, surtout, éviter les
phénomènes de dépendances croisées.
Quand on passe à la conception, de nombreuses classes outils plus ou moins génériques apparaissent et, alors que les découpages précédents insistaient en général sur
la séparation d’entités fonctionnelles indépendantes, on cherche plutôt à stratifier l’application en couches, chaque package reposant sur des packages de plus bas niveau.
Les couches les plus basses sont en général les plus stables et les plus réutilisables, on
a intérêt à les réaliser en premier car les couches suivantes en dépendront.
Le découpage en packages est sans doute un des processus le plus délicat de la
gestion d’un projet, dans la mesure où il faut le faire rapidement pour partager efficacement le travail entre les équipes, mais l’élaboration des différentes vues peut amener
à le réamenager souvent.
C’est l’ensemble de ces contraintes qu’il faut avoir en tête lorsque l’on effectue
le découpage de l’application en packages. Seule l’expérience pratique permet de
déterminer des méthodes conduisant à des bons découpages.
3.4.3 Le diagramme de séquence de conception
Le passage des diagrammes de séquence d’analyse aux diagrammes de séquence
de conception peut se résumer à un impératif simple : tout échange d’information entre
deux objets formalisé par un envoi de message en analyse doit se traduire en conception
par un certain nombre d’appels de méthodes.
Évidemment, puisqu’on ajoute des classes intermédiaires, à un même message peut
correspondre le déclenchement d’un nombre plus ou moins importants de méthodes.
Un travail important de la conception consiste d’une part à attribuer les bonnes méthodes aux bonnes classes et, d’autre part, à déterminer précisément la signature de
chacune des méthodes. Il ne va pas de soi, en effet, de déterminer quels sont les paramètres dont une méthode aura réellement besoin avant de l’avoir codée.
Il faut noter que la plupart des ateliers de génie logiciel offrent une fonctionnalité
bien pratique : au fur et à mesure qu’on ajoute des méthodes dans un diagramme de
séquence, ces méthodes s’ajoutent automatiquement dans la description des classes
sur les diagrammes de classes. Cela permet de passer à l’étape de génération de code
rapidement une fois que tous les diagrammes de séquence pertinents ont été dessinés.
3.4.4 Les diagrammes états-transitions
Le diagramme états-transitions est sans doute la plus complexe des vues proposées par UML. Sa mise au point demande un effort qui ne vaut la peine que pour
certains objets, dont le comportement dynamique est trop complexe pour être appré-
16
hendé par quelques diagrammes de séquence. Il est donc important de se demander,
lorsqu’on modélise une application, quels sont les objets pour lesquels il faut réaliser
ce diagramme.
Par ailleurs, lorsque l’automate associé à un objet devient trop complexe, il est nécessaire de se demander s’il ne faut pas décomposer en plusieurs objets, ce qui conduit
au moins à revoir les diagrammes de classes.
3.4.5 Conception avancée
Il n’est pas question dans un polycopié adressé à des débutants de présenter dans
le détail toutes les méthodes de conception les plus avancées, mais il est bon que le
lecteur connaisse au moins l’existence des éléments qui suivent.
Les frameworks Un framework est un logiciel constitué essentiellement de classes
génériques et dans lequel les traitements génériques qui font intervenir ces classes sont
fournis.
Si le framework est bien conçu, l’équipe de développement qui veut l’utiliser n’a
plus qu’à dériver certaines classes correspondant aux cas particuliers qu’elle veut traiter
et définir les traitements spécifiques de ces classes, ce qui permet de réaliser diverses
applications spécialisées similaires en évitant de redévelopper à chaque fois les parties
communes.
Les framework font un usage intensif des interfaces et de l’héritage. Le recours aux
interfaces permet d’imposer aux programmeurs qui veulent utiliser un framework la
liste des méthodes spécialisées qu’ils doivent développer pour intégrer leurs propres
classes.
Dans ce cadre, le lecteur trouvera dans [GHJV96] un ensemble de considération sur
la réutilisabilité des modèles de conception expliquant pourquoi il ne faut pas abuser
de l’héritage en programmation orientée objets.
Les composants Les architectures de composants constituent une approche de la
réutilisation orthogonale à la précédente. Un composant est un module logiciel autonome, qui peut être compilé séparément et qui offre des fonctionnalités bien définies
au travers d’une interface bien spécifiée. Une architecture de composants est en général
constituée d’une bibliothèque de composants, d’une infrastructure qui permet d’assurer
la communication entre les composants et des mécanismes qui permettent de construire
un logiciel particulier en faisant appel à une partie des composants présents dans la bibliothèque.
Vis-à-vis d’une bibliothèque de classes, une architecture de composants se distingue surtout par deux aspects :
17
– il n’est pas nécessaire de recompiler les composants lorsqu’on construit un logiciel qui y fait appel ;
– la communication entre les composants peut se faire par appel direct des méthodes, mais aussi via des communications par le réseau, ce qui permet de distribuer une application sur plusieurs machines de façon totalement transparente.
Les deux principaux exemples d’architectures de composants sont CORBA, dans
lequel les composants ne peuvent communiquer que par des appels au réseau, même
s’ils sont sur la même machine, et COM, qui ne fonctionne que dans les environnement
d’exploitation de Microsoft.
Une architecture de composants offre des garanties d’indépendance maximale entre
les différents modules d’une application, à tel point qu’ils peuvent souvent être développés dans des langages de programmation différents.
Les design patterns Face à la récurrence en analyse de problèmes qui se ressemblent
tous d’une application à l’autre, des modèles standards de conception sont apparus peu
à peu. Ce sont les design patterns, présentés dans l’ouvrage de référence [GHJV96]
ainsi que sur le site [url1].
Le terme « pattern » est traduit par « patron » dans le sens d’un modèle utilisé par
un couturier pour s’adapter à différents contextes.
C’est une entité réellement réutilisable en informatique car un patron est très abstrait vis-à-vis des langages de programmation qui permettent de le réaliser. C’est une
aide pour trouver une solution à un problème précis dans un contexte bien défini. Leur
usage systématique conduit à une standardisation de la conception et favorise la compréhension de programmes écrits par d’autres.
3.4.6 Implémentation et intégration
Développer une application en équipes séparées pose des problèmes au moment de
l’implémentation. Même en supposant que l’on connaisse précisément les signatures
de toutes les méthodes offertes par les autres équipes, il se pose un problème de compilation. En effet, la partie développée par une équipe ne pourra pas être compilée si elle
fait appel à des classes et des méthodes fournies par d’autres équipes, mais absentes au
moment de la compilation. Or il est important de pouvoir compiler et tester sa partie
avant l’intégration pour éviter d’avoir à rechercher tous les bugs seulement une fois le
logiciel assemblé.
Une solution classique à ce problème consiste à développer des classes « bouchons » quasiment vides et qui ne sont là que pour la compilation. Mais ces développements sont une perte de temps.
18
L’approche que nous préconisons consiste à mener la totalité de la conception avec
un atelier de génie logiciel et de générer un squelette complet du code avant de passer
à l’implémentation.
Avec cette approche, chaque équipe pourra développer exclusivement le code des
méthodes dont elle a la charge et compiler le tout, en respectant scrupuleusement la
contrainte de ne toucher à la signature d’aucune méthode.
Par ailleurs, à des fins de test des parties séparées, il ne suffit pas que le code puisse
être compilé, il est parfois nécessaire de disposer de méthodes externes fonctionnelles
pour valider un comportement interne. Pour atténuer la portée de ce problème, plutôt que d’attendre d’avoir réalisé l’intégration complète avant d’effectuer des tests, il
est préférable de se doter d’un outil de gestion de versions qui permette à plusieurs
équipes de travailler en parallèle sur le même code et d’intégrer leurs développements
successifs dans une version commune que chacun récupère à intervalles réguliers.
Des outils tels que CVS ou S UBVERSION sont conçus spécifiquement pour assurer
le bon fonctionnement de cette méthode de travail. Une contrainte méthodologique
évidente qui va avec l’emploi de tels outils consiste à n’intégrer son travail à la version
commune qu’une fois que le code correspondant compile correctement.
3.5 Outils du génie logiciel
3.5.1 Génération de squelettes
À partir d’un diagramme de classes suffisamment détaillé, il est facile de générer
automatiquement des éléments de code dans un langage de programmation orienté objets. Les générateurs peuvent décrire les classes, les attributs, les accesseurs associés
à chacun de ces attributs, les signatures des méthodes décrites par le concepteur. Ces
outils génèrent donc le squelette d’une application et font gagner du temps aux développeurs en leur épargnant les phases fastidieuses et répétitives (en particulier, l’écriture
de tous les accesseurs).
Il faut noter toutefois que, les différents langage de programmation orienté objets
ayant chacun leurs particularité, il est difficile d’assurer à la fois une indépendance
totale de la conception vis-à-vis du langage de programmation cible et la possibilité de
générer le code dans un langage de programmation plutôt qu’un autre à partir de cette
conception « générique ».
S’il est assez facile d’engendrer des squelettes donnant la signature de toutes les
méthodes, il est beaucoup plus difficile, par contre, d’automatiser l’écriture de code
algorithmique à partir de la description du comportement des opérations, donc de la
dynamique de l’application. De telles générations automatiques de code sont encore du
domaine de la recherche.
19
Usage des cardinalités (ou multiplicités) L’emploi des cardinalités dans les diagrammes de classes est délicat dès lors que l’on a recours à une outil de génération
automatique de squelettes.
En effet, selon ce que recouvre le lien sémantique représenté par l’association, les
cardinalités peuvent différer subtilement entre deux classes pourtant identiques. Ainsi,
sur la figure 2, si l’on indique qu’un bus a toujours un et un seul chauffeur, on présuppose qu’on ne s’intéresse qu’aux bus en train de rouler. Mais le jour où l’on veut
augmenter les fonctionnalités de l’application et gérer aussi les dépôts de bus, alors il
faut pouvoir traiter le cas des bus auxquels aucun chauffeur n’est affecté. Par ailleurs,
il faut décider si l’on veut dire ou non que c’est toujours le même chauffeur qui est
affecté à un bus donné.
Or le code généré peut différer largement selon la cardinalité que l’on a indiquée
car les générateurs de squelettes de code se fondent sur les cardinalités pour choisir les
structures de données. Si on a employé une cardinalité de type simple (0 ou 1), l’objet
relié sera un attribut simple. Au contraire, si on a employé une cardinalité multiple,
l’attribut engendré sera un conteneur d’objets du type de l’objet relié. Un changement
de cardinalité peut donc amener à des remises en question importantes dans le code
généré.
3.5.2 Reverse engineering
Certains De plus en plus d’outils permettent d’automatiser la résolution du problème dit de Reverse engineering. Le but est de reconstruire des diagrammes de
modélisation (bas niveau) à partir des sources de programmes anciens et mal documentés, en vue de le réimplémenter. En pratique, les outils de Reverse engineering
sont surtout capables de reconstituer des diagrammes de classes.
Un programme étant une solution particulière à un problème donné (les spécifications), le Reverse engineering peut effectivement aider à retrouver et à structurer
l’organisation de ce programme (domaine de solution), mais il ne faut pas espérer qu’il
reformule le besoin lui-même (domaine de problème).
3.6 Conventions de notation et codage propre d’une classe
3.6.1 Conventions de notation
En général, une équipe de développement se dote de conventions de notations précises pour tout le code d’un même projet. Il est impératif de respecter ces conventions
de notation pour faciliter la lecture du code par des développeurs d’autres équipes. Le
respect de conventions de notation au sein d’un projet facilite la collaboration entre
20
équipes si tout le monde adopte les mêmes conventions. De plus, c’est un aspect important de la propreté du logiciel.
Peu à peu, des conventions de notation standards s’imposent, en particulier grâce
aux outils qui génèrent automatiquement des squelettes de code à partir de vues UML
(voir la section 3.5.1). Par exemple, en JAVA, les noms de toutes les méthodes commenceront par un verbe et une minuscule, suivi du complément d’objet avec une majuscule par mot. En C++, les noms des attributs commencent souvent par un « underscore ( _ ) » suivi d’une majuscule, tandis qu’en JAVA on les note de la même façon que
les méthodes.
Une bonne habitude consiste à rendre tous les attributs privés et à proposer des
méthodes spécifiques pour y accéder ou les modifier. On appelle ces méthodes spécifiques des accesseurs et modifieurs. Il est conseillé de leur donner des noms adaptés
comme getDate() ou setDate(date), pour faciliter la lisibilité.
L’emploi de l’anglais pour le nommage s’impose peu à peu aux dépends du français, l’important étant de s’efforcer d’être cohérent sur ce point au sein d’un même
projet.
3.6.2 Commentaires
La réalisation documentée d’une analyse et d’une conception avec UML ne dispense pas de commenter les méthodes développées lors du codage.
La première chose à commenter est le rôle de chaque classe au sein de l’application.
On y joint en général le nom de son auteur et les dates de modification. On commente
ensuite les méthodes. En général, les commentaires comprennent pour chaque méthode
une description du rôle de la méthode dans l’application, (c’est-à-dire ce à quoi elle sert
et non pas ce qu’elle fait, ce qui doit être évident pour le lecteur si le code est écrit avec
clarté...), ainsi que la liste des paramètres d’entrée et la valeur de retour.
Les commentaires à l’intérieur des méthodes sont en général dévolus à la signification des variables intermédiaires ou à l’explication des algorithmes trop complexes
pour être compris d’un coup d’œil.
Avec un langage comme JAVA, il existe une forme standard pour les commentaires
d’en-tête de méthodes, ce qui permet à l’outil javadoc d’insérer ces commentaires dans
une documentation qu’il génère automatiquement dans des fichiers HTML. On dispose
ainsi pour chaque classe de la description de l’ensemble de ses attributs et de la liste
des méthodes avec leurs commentaires.
Certains langages permettent enfin l’usage d’éléments de contrôle de la propreté
du code, qui donnent lieu à des vérifications lors de la compilation. C’est le cas du
mot-clef « const » en C++ (ou final en JAVA), qui indique qu’une donnée ne peut
pas être modifiée. Le compilateur vérifie alors que toute méthode qui est censée ne
21
pas modifier cette donnée ne fait appel qu’à des méthodes qui ont la même propriété.
Certains compilateurs sont plus permissifs que d’autres sur ces aspects.
4 Aspects organisationnels et humains de la conduite
de projets
4.1 Introduction
La réussite d’un projet informatique réalisé en équipe suppose que soient correctement gérées trois dimensions indissociables :
– la dimension technique ;
– la dimension organisationnelle ;
– la dimension relationnelle ;
Si l’usage veut qu’en école d’ingénieur l’enseignement soit focalisé sur la dimension technique, il faut avoir à l’esprit le fait que, dans un contexte industriel, l’expérience montre que ce sont surtout les facteurs humains (organisationnel et relationnel)
qui déterminent le plus souvent le succès ou l’échec d’un projet.
L’objectif des quelques lignes qui suivent est de sensibiliser le lecteurs à ces aspects
importants et trop souvent passés sous silence. Cependant, il n’est pas question de
donner des recettes toutes faites dans ce domaine délicat où le savoir-faire est avant
tout une question de personnalité et d’expérience, chacun ayant à se forger la sienne.
4.2 Quelques causes classiques de dysfonctionnement
La liste ci-dessous n’est pas exhaustive, elle s’appuie sur un ouvrage de C. Bénard
([Bén92]).
La divergence d’intérêts un ou plusieurs membres du projet ont des objectifs éloignés ou non cohérents avec ceux du reste de l’équipe.
L’instabilité des objectifs l’équipe est soumise à des changements d’objectifs, de
ressources, de chef de projet.
L’ambiguïté des rôles les fonctions de chacun au sein du groupe sont floues, se chevauchent ou entrent en conflit les unes avec les autres.
La bataille des chefs plusieurs membres de l’équipe tentent de diriger le projet, chacun dans sa direction.
22
Le manque de crédibilité du chef de projet les compétences techniques, organisationnelles ou relationnelles du chef de projet ne sont pas reconnues par les membres de
l’équipe.
Le manque de soutien de la hiérarchie les décisions ne sont pas prises lorsqu’elles
sont nécessaire, les membres de l’équipe ont l’impression que leur projet ne sert à rien.
L’inadéquation des compétences les membres du projet se trouvent assignés à des
tâches pour lesquelles ils n’ont pas la compétence requise.
Le manque de motivation plus un personne se sent dans l’insécurité ou la tension,
plus elle a tendance à reporter son énergie sur autre chose que le projet.
Le manque de communication les décisions sont prises de façon locale et non coordonnée, les équipes ne disposent pas des informations nécessaires pour mener à bien
leur travail.
4.3 Quelques lignes sur le rôle de chef de projet
Un bon chef de projet doit savoir :
gérer l’action en anticipant en se tenant en permanence au courant des difficultés
rencontrées et en orientant les travaux en fonction de l’état d’avancement collectif.
maîtriser le temps en estimant correctement les durées, en planifiant afin d’éviter les
retards et les chamboulements mais en remettant à jour les plannings quand cela paraît
nécessaire.
déléguer à bon escient en sachant écouter les interventions justifiées, en attribuant
les bonnes tâches aux bonnes personnes et en manifestant sa confiance dans la bonne
conduite des tâches déléguées. Cet aspect est l’une des clefs de la motivation individuelle.
assurer le bon climat relationnel en adaptant l’organisation de façon à tirer le meilleur
parti des ententes et à éviter les sources de conflit, en anticipant les situation menant
aux conflits, et en assurant la motivation et la cohésion de l’équipe de projet.
éviter le culte de la personnalité en se croyant indispensable et infaillible et en
faisant que le projet tourne exclusivement autour de soi.
23
ne pas confondre moyens et objectifs en introduisant des outils dont l’utilité est
contestable dans le cadre d’un projet donné et en faisant passer plus de temps aux
membres de l’équipe en activité organisationnelles (réunions, etc.) qu’en travail effectif.
5 Conclusion générale
La conduite d’un projet logiciel de grande envergure est une activité complexe, qui
nécessite des outils, de la méthode et de l’expérience. Dans ce document, nous avons
proposé des éléments de démarche visant à résoudre des problèmes de coordination du
travail collectif.
Nous avons vu que les trois principales phases de la réalisation proprement dite
d’un logiciel sont les suivantes :
1. analyse (et affinement des spécifications),
2. conception (générale et détaillée),
3. implémentation.
Nous avons mentionné que pour chacune de ces phases les éléments du système
complet peuvent être décrits de façon récursive selon trois points de vue indépendants :
la vue fonctionnelle, la vue structurelle et la vue dynamique. Généralement les grosses
applications doivent être décrites conjointement sous ces trois vues, mais certaines applications peuvent privilégier une vue particulière.
Par exemple, une application temps réel faisant intervenir peu d’objets et dépourvue d’interface graphique aura un aspect dynamique bien plus important (protocoles,
synchronisations, ...) que les aspects structurel et fonctionnel. À l’opposé, la vue structurelle d’une application d’interfaces utilisateur dans laquelle toutes les fonctionnalités
sont disponibles en librairie sera prépondérante par rapport aux autres vues ; il en est
de même pour les applications utilisant principalement les bases de données.
Pour conclure, disons que les méthodologies reposant sur UML (dont nous n’avons
vu qu’une petite partie) sont conçues comme un moyen générique pour décrire des
applications orientées objets, et de la même façon qu’il n’est pas judicieux de tenter
d’utiliser tous les éléments de la langue française pour écrire un article, vous n’êtes pas
non plus obligé d’utiliser tous les concepts d’ UML dans vos projets pour en tirer profit.
C’est à chaque utilisateur d’UML d’exploiter la partie qui l’intéresse pour résoudre son
problème.
24
6 NETographie (dernière mise à jour : 2001-2002)
6.1 Programmation objets et UML
url1 - http ://www.csioo.com/cetusfr/software.html : carrefour
Cetus : Orienté Objets ; excellent, plus de 8000 liens.
url2 - http ://www.cyber-espace.com/ronald/ : espace objet francophone.
url3 - http ://www.rational.com/UML/resources.html : site de R A TIONAL
(principal acteur de UML)
url4 - http ://www.omg.org : Object Management Group
url5 - http ://www.lurpa.ens-cachan.fr/grafcet/grafcet_fr.html :
Tout sur le Grafcet
url6 - http ://www.ensta.fr/ osigaud/in204/index.html : Le site
web du cours
6.2 Les design patterns (ou patrons de conception)
– http ://www.csioo.com/cetusfr/oo_patterns.html : liste de références concernant les patterns (ou patrons)
– http ://st-www.cs.uiuc.edu/users/patterns/patterns.html :
page d’entrée principale pour les patterns
Références
[Ben95]
E. Bennatan. Management des projets informatiques : manuel du chef de
projet. AFNOR, 1995.
[Boo94]
G. Booch. Object-Oriented Software Analysis and Design with Applications. Benjamin Cummings, 1994.
[Bén92]
C. Bénard. Les neufs points clefs de la conduite d’un projet informatique.
Editions d’organisation, 1992.
[GHJV96] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns : catalogue de modèles de conception réutilisables. ITP, France, 1996.
[Har87]
D. Harel. Statecharts : A visual formalism for complex systems. Science
of Computer Programming, 8, 1987.
[JBR97a] I. Jacobson, G. Booch, and J. Rumbaugh. The Objectory Software Development Process. Addison Wesley, 1997.
25
[JBR97b] I. Jacobson, G. Booch, and J. Rumbaugh. Unified Modeling Language
Reference Manual. Addison Wesley, 1997.
[JBR97c] I. Jacobson, G. Booch, and J. Rumbaugh. Unified Modeling Language User
Guide. Addison Wesley, 1997.
[JCJO92] I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented
Software Engineering : A Use case Driven Approach. Addison Wesley,
1992.
[Lor97]
M. Lorenz. Object-Oriented Software Development. Prentice Hall, 1997.
[Mey97]
B. Meyer. Object-Oriented Software Construction. Prentice Hall, 1997.
[Rum96]
J. Rumbaugh.
France, 1996.
[Sig05a]
O. Sigaud. Introduction à la modélisation orientée objets avec UML.
support du cours « Génie logiciel et programmation orientée objets » de
l’ENSTA, 2005.
[Sig05b]
O. Sigaud. Introduction à la programmation orientée objets avec Java.
support du cours « Génie logiciel et programmation orientée objets » de
l’ENSTA, 2005.
Modélisation et conception orientées objets.
26
Masson,