UNIVERSITÉ DE MONTRÉAL ÉCOLE

UNIVERSITÉ DE MONTRÉAL ÉCOLE
UNIVERSITÉ DE MONTRÉAL
ÉCOLE POLYTECHNIQUE DE MONTRÉAL
Ce mémoire intitulé:
ANALYSE COMPARATIVE DE LA RÉPARTITION DE L’EFFORT DANS LE
CADRE DE PROCESSUS LOGICIELS
présenté par: GERMAIN Éric
en vue de l’obtention du diplôme de: Maı̂trise ès sciences appliquées
a été dûment accepté par le jury d’examen constitué de:
M. BOUDREAULT Yves, M.Sc., président
M. ROBILLARD Pierre N., Ph.D., membre et directeur de recherche
M. DESMARAIS Michel, Ph.D., membre
UNIVERSITÉ DE MONTRÉAL
ANALYSE COMPARATIVE DE LA RÉPARTITION DE L’EFFORT DANS LE
CADRE DE PROCESSUS LOGICIELS
ÉRIC GERMAIN
DÉPARTEMENT DE GÉNIE INFORMATIQUE
ÉCOLE POLYTECHNIQUE DE MONTRÉAL
MÉMOIRE PRÉSENTÉ EN VUE DE L’OBTENTION
DU DIPLÔME DE MAÎTRISE ÈS SCIENCES APPLIQUÉES
(GÉNIE INFORMATIQUE)
AVRIL 2004
c Éric Germain, 2004.
iv
Aux deux femmes de ma vie
Hughette, ma mère
Marie, ma douce
v
REMERCIEMENTS
J’aimerais d’abord remercier mon directeur de recherche, Pierre N. Robillard,
dont la vision, les conseils, les critiques et les encouragements ont fortement teinté
l’ensemble de ma démarche de recherche et de production de ce mémoire.
Je tiens à remercier tout particulièrement Mihaela Dulipovici pour son soutien
dans le contexte du cours-projet “Atelier de génie logiciel” et notamment pour son
travail méticuleux de validation des jetons d’effort. J’aimerais également remercier Sébastien Cherry, Alexandre Moı̈se, Christian Robidoux, Martin Robillard et
Houcine Skalli pour leurs contributions respectives au succès des Ateliers. Aussi,
ce travail de recherche n’aurait pu être possible sans la collaboration des étudiants
qui ont participé aux Ateliers.
J’aimerais également remercier :
– Les membres du jury pour leurs commentaires constructifs suite au dépôt
initial de ce mémoire ;
– Les réviseurs anonymes pour leurs commentaires pertinents lors de la soumission du premier des deux articles qui constituent le mémoire ;
– Thérèse Gauthier, Shannon Miko et Cynthia Orman pour leurs précieux
conseils lors de la révision du mémoire ;
– Sylvie Nadeau pour ses précieux conseils sur le métier d’étudiant aux cycles
supérieurs ;
vi
– Robert Roy pour m’avoir incité à me dépasser et pour avoir mis LATEX sur
ma route ;
– mes beaux-parents et mes amis pour leurs encouragements ; et
– les membres de ma famille ainsi que Marc Rochette pour leurs encouragements
et leur soutien tout au long de mes études universitaires.
Finalement, un merci tout spécial à ma douce moitié, Marie Brassard, pour ses
encouragements, ses conseils, sa patience, sa patience (encore), son soutien de tous
les jours et pour avoir révisé le document final. Je t’aime.
vii
RÉSUMÉ
Le domaine des processus de développement de logiciels ne saura être considéré
comme mature que lorsque l’élaboration de tels processus pourra être fondée sur
une compréhension détaillée et quantitative du comportement des ingénieurs du logiciel. Or, cette vision demeure utopique pour l’instant, car la fondation théorique
nécessaire à son accomplissement n’est pas bien ancrée à l’heure actuelle, et beaucoup de travail sera nécessaire avant d’y parvenir. Un des symptômes de la pauvreté
relative des connaissances générales dans le domaine est l’absence de consensus face
à l’émergence d’approches qui tranchent radicalement avec les enseignements de ce
que nous appellerons l’école classique du développement de logiciels. Cette situation découle largement du faible nombre d’études comparant dans leur globalité les
différentes approches proposées.
Une des difficultés auxquelles le chercheur risque de faire face dans sa quête
d’une vue comparative valable a trait à la mise en place d’un contexte permettant
d’effectuer des comparaisons valides. Il est très difficile d’appliquer des processus
logiciels divers sur un même ensemble de spécifications sans que des facteurs liés aux
projets ne risquent d’interférer avec l’analyse. Cette situation constitue un carcan
duquel il faut sortir si l’on veut éventuellement procéder à des études comparatives
à grande échelle en milieu industriel. Une façon possible de remédier à ce problème
est de cerner les caractéristiques invariables du comportement des ingénieurs du
viii
logiciel par rapport aux conditions de projet, ce qui permettrait éventuellement de
procéder à certaines analyses valides dans le contexte de projets variables.
La présente recherche vise à approfondir l’état des connaissances sur la relation
entre les caractéristiques des processus et projets de développement de logiciels,
définis ou réels, et l’effort déployé par les individus qui développent des systèmes
logiciels. Elle a été réalisée en utilisant trois éditions successives d’un cours-projet
intitulé « Atelier de génie logiciel », offert chaque année aux étudiants finissants du
baccalauréat en génie informatique, concentration génie logiciel, à l’École Polytechnique de Montréal. Deux études distinctes réalisées dans ce cadre sont présentées.
Une première étude, qui a porté sur l’édition 2002 de l’Atelier, a permis de
comparer les activités cognitives réalisées par des étudiants lors de travaux de
développement de systèmes logiciels réalisés suivant un même ensemble de spécifications, mais selon deux approches distinctes. Elle a nécessité la définition d’une
catégorisation originale de ces activités cognitives. Trois des équipes ont utilisé
un modèle de processus très fortement inspiré du Unified Process for Education
(UPEDU), modèle de processus dérivé du Rational Unified Process (RUP). Les
trois autres équipes ont utilisé un processus construit autour de la méthodologie de
programmation extrême (Extreme Programming ou « XP »). Selon les observations
effectuées, le choix d’une approche particulière a un impact limité sur les activités
cognitives réalisées par les équipes étudiées. Cet impact, mesuré en termes relatifs,
se manifeste surtout à l’égard des activités d’inspection et de révision des travaux
ix
réalisés.
Une seconde étude, qui a porté sur les éditions 2001, 2002 et 2003, a permis
d’analyser les caractéristiques de l’effort déployé par les membres de huit équipes
ayant travaillé à partir de trois ensembles de spécifications différents, mais suivant
des modèles de processus très fortement inspirés du UPEDU. L’objectif visé par
cette étude consistait à repérer des patrons au sein des diagrammes de répartition
de l’effort relatif en disciplines à travers le cycle complet de développement d’un
système logiciel. Les spécifications soumises, les durées de cycle de développement,
les technologies utilisées et les mécanismes de cueillette de l’effort déployé variaient
à divers degrés d’une édition à l’autre. Le nombre de participants différait également
d’une équipe à l’autre. Une catégorisation en trois disciplines des activités réalisées a
été définie de manière à permettre une ségrégation substantielle des activités tout en
minimisant l’influence des facteurs liés à l’édition ou à la taille de l’équipe. L’analyse
réalisée montre une convergence modérée des proportions d’activités réalisées par
chaque équipe sur l’ensemble du cycle de développement. La majorité des projets
soumis affichent toutefois une évolution très similaire du type d’activités réalisées
au fil du temps. Ainsi, l’effort réalisé suit une progression qui débute par une
première phase, où les activités liées à l’ingénierie sont prédominantes. Le poids de
ces activités diminue progressivement, ce qui amène une seconde phase d’équilibre
entre les activités de programmation et celles de validation et de vérification. Cet
équilibre est rompu peu avant la fin du projet en faveur des activités de validation
x
et de vérification, quoique de manière peu marquée.
En montrant l’indépendance relative du comportement des ingénieurs du logiciel par rapport aux conditions de processus et de projet, le travail de recherche
ouvre la voie pour l’application éventuelle des analyses de patrons d’effort vers
le milieu industriel. Sur le plan théorique, de telles analyses pourront permettre
d’approfondir davantage notre compréhension du comportement des praticiens du
développement de logiciels. Sur le plan pratique, elles pourraient constituer un outil
puissant d’estimation et de contrôle à la disposition des gestionnaires de projets et
des ingénieurs de processus.
xi
ABSTRACT
xv
TABLE DES MATIÈRES
DÉDICACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iv
REMERCIEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v
RÉSUMÉ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
vii
ABSTRACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
TABLE DES MATIÈRES . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
LISTE DES FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
LISTE DES SIGLES ET ABBRÉVIATIONS . . . . . . . . . . . . . . . . . xxi
LISTE DES TABLEAUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiii
LISTE DES ANNEXES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxiv
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
6
1.1 Processus logiciels . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.1.1
Évolution du domaine . . . . . . . . . . . . . . . . . . . . .
7
1.1.2
Revue des principaux modèles de processus . . . . . . . . . .
11
1.2 Méthodologies agiles de développement de logiciels
. . . . . . . . .
18
xvi
1.2.1
Survol des méthodologies agiles . . . . . . . . . . . . . . . .
18
1.2.2
La programmation extrême . . . . . . . . . . . . . . . . . .
20
1.2.3
Les processus d’ingénierie par opposition aux méthodologies
agiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
1.3 La mesure des processus logiciels . . . . . . . . . . . . . . . . . . .
26
1.3.1
L’estimation de l’effort . . . . . . . . . . . . . . . . . . . . .
26
1.3.2
La mesure de l’effort . . . . . . . . . . . . . . . . . . . . . .
29
1.4 Le contrôle des processus . . . . . . . . . . . . . . . . . . . . . . . .
31
ORGANISATION GÉNÉRALE DU TRAVAIL . . . . . .
ENGINEERING-BASED
PROCESSES
AND
34
AGILE
38
39
43
50
53
3.4.1
Raw-data analysis . . . . . . . . . . . . . . . . . . . . . . . .
53
3.4.2
Aggregate analysis . . . . . . . . . . . . . . . . . . . . . . .
56
3.4.3
58
60
xvii
3.5.1
60
3.5.2
63
3.5.3
65
3.5.4
66
MEASURING
RELATIVE
EFFORT
PROGRESSION
68
68
72
73
75
76
4.5.1
78
4.5.2
83
4.5.3
84
85
4.7 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.7.1
4.7.2
4.7.3
90
ent progressions . . . . . . . . . . . . . . . . . . . . . . . . .
90
92
xviii
4.7.4
Study limitations . . . . . . . . . . . . . . . . . . . . . . . .
93
4.7.5
Effort distribution: does it make sense? . . . . . . . . . . . .
94
94
DISCUSSION GÉNÉRALE . . . . . . . . . . . . . . . . .
97
5.1 Calibration des charges de travail . . . . . . . . . . . . . . . . . . .
97
5.2 La classification en disciplines . . . . . . . . . . . . . . . . . . . . .
98
CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
BIBLIOGRAPHIE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
xix
LISTE DES FIGURES
1.1 Modèle conceptuel fondamental du RUP (traduit de Robillard, Kruchten et d’Astous 2003)
. . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2 Modèle bidimensionnel de processus et de cycle de vie du UPEDU
(traduit de École Polytechnique de Montréal 2002) . . . . . . . . .
14
1.3 Définition des jalons au cours du cycle de développement (traduit
de École Polytechnique de Montréal 2002) . . . . . . . . . . . . . .
16
1.4 Évolution comparée des coûts du changement au fil du cycle de développement, selon les idées de Beck (1999)
. . . . . . . . . . . . .
21
1.5 Modèle simplifié du cycle de développement et de maintenance en
programmation extrême . . . . . . . . . . . . . . . . . . . . . . . .
23
45
46
54
56
57
58
. . . . . . . . . . . . . . . . . . . . . . .
60
74
76
77
79
79
80
80
81
81
82
82
86
87
89
xxi
LISTE DES SIGLES ET ABBRÉVIATIONS
2D
Bi-dimensional
Cn
Itération de construction n
CMM
En
Itération d’élaboration n
EQ
Modèle équivalent
EQM
Modèle équivalent, itération de maintenance
EQn
Modèle équivalent, itération n
IEEE
It.
Itération
NSERC
OPEN
PAI
PSEE
PSP
RUP
SLIM
SPCC
xxii
Tn
Itération de transition n
TSP
UP
UPM
Unified Process for Education, itération de maintenance
UPn
Unified Process for Education, équipe n (si n = A, B ou
C), ou itération n (si n est numérique)
UPEDU
V&V
XP
Extreme Programming
XPM
Extreme Programming, itération de maintenance
XPn
Extreme Programming, équipe n (si n = A, B ou C), ou
itération n (si n est numérique)
xxiii
LISTE DES TABLEAUX
51
5.1 Un exemple de classification en disciplines, basée sur les disciplines
originales du UPEDU . . . . . . . . . . . . . . . . . . . . . . . . . . 102
xxiv
LISTE DES ANNEXES
Annexe I :
Annexe II :
Contenu du support CD fourni . . . . . . . . . . . . . . . 122
1
INTRODUCTION
In software engineering there is no theory. (. . . ) It’s all arm flapping and
intuition. I believe that a theory of software evolution could eventually
translate into a theory of software engineering. Either that or it will
come very close. It will lay the foundation for a wider theory of software
evolution.(Manny Lehman, cité dans Williams 2002)
La capacité de définir de manière détaillée et en des termes quantitatifs le
comportement des développeurs de logiciels serait susceptible d’ouvrir la porte à
l’avènement de méthodes de développement automatisé, via l’implantation d’environnements de génie logiciel centrés sur les processus (Process-centered Software
Engineering Environments ou PSEE) (Cugola et Ghezzi 1998). Toutefois, cette vision demeure utopique pour l’instant, car la fondation théorique nécessaire à son
accomplissement n’est pas bien ancrée à l’heure actuelle. Ainsi, les connaissances
sur les déterminants des caractéristiques d’un processus logiciel réel, c’est-à-dire tel
qu’appliqué, sont limitées. Or, le développement de modèles valables, qu’ils soient
simples ou complexes, ne peut être réalisé avec assurance qu’avec une fondation
théorique minimale.
Un des symptômes de la pauvreté relative des connaissances générales dans le
domaine est l’absence de consensus face à l’émergence d’approches qui tranchent
radicalement avec les enseignements de ce que nous appellerons l’école classique
2
du développement de logiciels. Ainsi, les dernières années ont été marquées par
l’émergence de méthodologies dites agiles (Cockburn 2002) et, notamment, de la
programmation extrême (Extreme Programming ou XP) (Beck 1999). Cette dernière prône essentiellement le relâchement des efforts spécifiques en matière de
planification, d’analyse et de conception, à la faveur d’une stratégie de réduction
des coûts du changement et de retardement des décisions principales en matière
de requis et de conception. Les processus traditionnels (voir par exemple Kruchten
2000), au contraire, préconisent l’application rigoureuse de pratiques d’ingénierie et
de gestion, ainsi que la production de plusieurs artéfacts. Il est intéressant de noter
que, malgré le débat sur la question (voir par exemple Antón 2003; Wells 2003),
les arguments soulevés des deux côtés ramènent souvent soit à des aspects théoriques non vérifiés, soit à des expériences personnelles difficilement généralisables.
En outre, les études comparatives documentées entre les deux approches sont rares.
Par ailleurs, le chercheur désireux de comparer deux ou plusieurs approches doit
mettre en place un contexte permettant de rendre de telles comparaisons valides.
Or, il est très difficile d’appliquer des processus logiciels distincts sur un même
ensemble de spécifications sans que des facteurs liés aux projets ne risquent d’interférer avec l’analyse. Cette situation constitue un carcan duquel il faut sortir si
l’on veut éventuellement procéder à des études comparatives à grande échelle en
milieu industriel. Une façon possible de remédier à ce problème est de cerner les
caractéristiques invariables du comportement des ingénieurs du logiciel par rapport
3
aux conditions de projet, ce qui permettrait éventuellement de procéder à certaines
analyses valides dans le contexte de projets variables.
Le département de génie informatique de l’École Polytechnique de Montréal utilise depuis plusieurs années une plate-forme académique afin d’approfondir l’état
des connaissances sur les processus logiciels. Le cours-projet « Atelier de génie logiciel », offert principalement aux étudiants finissants du baccalauréat en génie
informatique, concentration « génie logiciel », constitue non seulement une opportunité de formation pratique mais également un environnement de recherche permettant d’observer et d’analyser des processus réels de développement appliqués à
la réalisation de systèmes complets par les étudiants. L’Atelier a servi de base à la
réalisation de quelques études empiriques (Germain, Dulipovici et Robillard 2002a;
Germain, Robillard et Dulipovici 2002b; Slavich 2000) couvrant une seule édition
à la fois et portant principalement sur la comparaison de l’effort déployé par des
équipes devant produire des implantations distinctes, conformes à des spécifications
communes.
La recherche présentée dans le cadre de ce mémoire a été entreprise dans le but
d’approfondir l’état des connaissances sur la relation entre les caractéristiques des
processus et projets de développement de logiciels, définis ou réels, et le comportement des individus qui développent des systèmes logiciels. Elle est exploratoire et
repose sur les questions suivantes :
– Quel est l’impact du choix d’une approche de développement sur le compor-
4
tement des ingénieurs du logiciel ?
– Existe-t-il des invariants ou des patrons d’effort qui caractérisent le comportement type des ingénieurs du logiciel ?
– Ces invariants et patrons d’effort transcendent-ils les caractéristiques de projets et de processus ?
Le travail présenté a été réalisé en utilisant trois éditions successives de l’Atelier
décrit précédemment. Deux études distinctes réalisées dans ce cadre sont présentées :
– Une première étude, qui a porté sur l’édition 2002 de l’Atelier, a permis de
comparer les activités cognitives réalisées par des étudiants sur un même
ensemble de spécifications mais selon deux approches distinctes de développement.
– Une seconde étude, qui a porté sur les éditions 2001, 2002 et 2003, a permis
d’analyser les caractéristiques de l’effort déployé par les membres de huit
équipes ayant travaillé à partir de trois ensembles de spécifications différents
mais suivant des modèles de processus à peu près identiques.
Le premier chapitre présente une revue de la littérature pertinente au domaine
des processus et méthodologies de développement de logiciels, qui constitue l’objet principal du présent travail de recherche. Suit une discussion sur la mesure des
processus, afin de sensibiliser le lecteur aux problématiques liées à la détection d’informations pertinentes au sein d’un processus logiciel réel. Finalement, on effleure
5
le domaine du contrôle des processus, susceptible de bénéficier des résultats du
présent travail.
Le chapitre 2 aborde l’organisation du présent travail. Le chapitre 3 reproduit
le premier des deux articles présentés dans le cadre du mémoire, alors que le second
article est présenté au chapitre 4. Enfin, le chapitre 5 présente une discussion globale
de la recherche, complémentaire aux conclusions énoncées à l’intérieur des articles.
6
1.1
Processus logiciels
Le présent chapitre constitue une revue critique de la littérature pertinente aux
nombreux aspects touchés par ce travail de recherche. Les deux premières sections
du chapitre traiteront de l’objet d’étude principal de ce travail, soit les processus
et méthodologies de développement de logiciels. Dans la première section, l’état du
domaine des processus logiciels sera d’abord décrit, puis trois modèles de processus
courants seront présentés. La seconde section traitera des méthodologies de développement de logiciels et, en particulier, de la méthodologie dite de programmation
extrême. Par la suite, la mesure des processus logiciels et de l’effort sera abordée
dans la perspective où tout travail d’analyse empirique comme celui-ci doit tenir
compte du contexte de mesure. Finalement, le domaine du contrôle des processus
et de l’estimation en cours de projet sera effleuré. Bien que ces derniers concepts
ne soient pas couverts dans le cadre des travaux réalisés, ils constituent une avenue
de choix pour l’exploration des conclusions de la recherche effectuée.
7
1.1.1
Évolution du domaine
Fugetta (2000) offre une perspective historique de l’évolution des processus logiciels. La période écoulée entre les années 1960 et 1980 a été marquée par le
développement parallèle de langages de programmation structurée, de méthodes et
principes de conception, ainsi que de cycles de développement de logiciels (aussi appelés « cycles de vie », bien que cette appellation puisse porter à confusion comme
nous le verrons plus loin). Le cycle de développement constitue une notion clé dans
la définition globale des tâches menant à la réalisation d’un système logiciel de
qualité ; il définit les diverses étapes de l’évolution d’un produit logiciel, ainsi que
les principes directeurs de l’exécution de ces étapes.
Toutefois, le cycle de développement ne saurait prescrire le détail des activités, structures organisationnelles, outils, procédures, politiques et contraintes. Ces
éléments font plutôt partie du processus logiciel, ou processus de développement logiciel. Un processus logiciel peut être défini comme étant l’ensemble des politiques,
structures organisationnelles, technologies, procédures et artéfacts nécessaires à la
conception, au développement, au déploiement et à la maintenance d’un produit
logiciel (Fugetta 2000).
Notons au passage que la distinction entre processus et cycle de développement
n’est pas toujours claire, particulièrement lorsqu’il est question de ce qui fut connu
plus tard sous le nom de modèle de cycle de vie en cascade, introduit par Royce
(1970) ; ce modèle, le premier du genre, prévoit implicitement la juxtaposition pure
8
et simple des deux concepts.
Osterweil et Lehman ont, par l’opposition de leurs vues sur le sujet, lancé une
nouvelle ère en matière de recherche sur les processus logiciels. Ainsi, Osterweil
(1987) considère qu’un des problèmes principaux empêchant l’assimilation de la
notion de processus logiciel à l’application de procédures ou recettes pour la fabrication d’avions ou d’automobiles est l’absence de gabarits à partir desquels un
processus logiciel appliqué à une situation spécifique pourrait être « instancié ».
L’approche d’Osterweil consiste à définir de tels gabarits de la manière la plus
rigoureuse possible, soit à travers la rédaction de « programmes » de processus utilisant des langages aussi formels que les langages de programmation informatique.
Cette approche met de l’avant une recherche axée vers la création d’un langage de
programmation de processus et d’un système de compilation et d’interprétation des
programmes rédigés.
Cugola et Ghezzi (1998), quant à eux, croient que le concept d’environnement
de génie logiciel centré sur les processus (PSEE), qui découle naturellement des
théories d’Osterweil, constitue la voie privilégiée de la recherche sur les processus du génie logiciel et ce, en dépit de l’impact très faible sur le terrain jusqu’ici
de ces environnements et des langages de modélisation associés. Les auteurs prétendent notamment que cette situation défavorable découle du peu de flexibilité
des environnements développés jusqu’ici, et non de problèmes structurels. Ainsi,
les environnements développés dans le futur auront un bien meilleur impact s’ils
9
tolèrent, par exemple, la déviation explicite du processus par les développeurs.
À l’inverse, Lehman (1987) prétend que la programmation de processus telle
que définie par Osterweil ne peut que détourner la collectivité du génie logiciel des
problèmes réels auxquels la discipline est confrontée, plutôt que de contribuer à
la résolution de ceux-ci. Pis encore, au lieu de contribuer à clarifier la nature des
processus réels, elle crée plutôt l’illusion du progrès. Ainsi, quoique les programmes
de processus soient théoriquement utiles pour l’expression formelle des processus, ils
ne sont d’aucune utilité pour l’amélioration de notre compréhension des dynamiques
obscures qui composent, encore aujourd’hui, la plus grande partie de la discipline.
Du même souffle, Lehman mentionne :
For applications (commonly termed “programming-in-the-large”), which
provide the real challenge for software engineering as distinct from programming methodology, models of the application as a whole or of many
of its parts do not, in general, exist; there is no theory of program development, there is no global and formalisable development procedure,
at best there is only an abstract process model.
Dix ans plus tard, il déclare : « Eventually it may be possible to develop generic
models but that lies in the distant future (Lehman 1997). »
Les vues de Lehman trouvent écho dans le développement récent de la pratique
du génie logiciel. Ainsi, Robillard, Kruchten et d’Astous (2003, p. 41) mentionnent
que le développement de logiciels comporte une forte composante opportuniste,
10
c’est-à-dire qu’une démarche exploratoire non planifiée est très souvent utilisée afin
d’identifier les éléments d’information manquants qui auraient permis d’appliquer
une démarche plus systématique. De plus, une progression d’un mode de développement systématique vers un mode opportuniste est généralement observée au fil de
l’évolution d’un projet. La présence d’activités opportunistes semble difficilement
compatible avec le concept de programmation de processus d’Osterweil. D’une manière similaire, Brooks trouve dans le processus de construction de logiciels une
dimension créative cruciale : « Great designs come from great designers. Software
construction is a creative 1 process. Sound methodology can empower and liberate
the creative mind ; it cannot inflame or inspire the drudge (Brooks 1987). »
Dans un tel contexte, nous sommes en droit de nous demander comment la
programmation de processus réussirait à compenser pour la faiblesse possible, voire
même probable, des capacités de design d’une équipe de développement, dans le
contexte de l’absence de compréhension des facteurs qui, justement, font qu’un
concepteur sera meilleur qu’un autre.
Le présent travail repose explicitement sur l’hypothèse selon laquelle la recherche
sur les processus du génie logiciel doit viser un objectif d’élaboration de modèles
permettant de mieux comprendre les facteurs qui les régissent, notamment les facteurs humains. Nous croyons que cette recherche contribue à faire progresser l’état
des connaissances dans les domaines décrits par Lehman.
1
En italique dans le texte
11
1.1.2
Revue des principaux modèles de processus
En l’absence de modèles quantitatifs formels du développement de logiciels,
modèles qui auraient permis de développer un ou plusieurs modèles quantitatifs
génériques de processus logiciels, certains intervenants des milieux académiques et
industriels ont établi divers modèles de processus qui reposent à la fois sur certains
principes issus de la recherche actuelle ou passée et sur des heuristiques découlant d’années d’expérience individuelle ou collective en matière de développement
de logiciels. Nous survolerons ici, de manière non exhaustive, quelques-uns de ces
modèles.
Il incombe cependant, avant de réaliser ce survol, de faire la distinction entre
les types de modèles de processus suivants :
– les modèles prédictifs, qui ont pour fonction de soutenir une démarche de
prédiction ou d’estimation ;
– les modèles explicatifs, qui ont pour fonction d’expliquer le comportement
réel des participants au processus ; et
– les modèles prescriptifs qui, à l’inverse des modèles explicatifs notamment,
visent à indiquer aux participants les activités qui doivent être réalisées dans
le cadre de leurs fonctions.
La présente recherche s’intéresse avant tout aux modèles utilisés généralement en
milieu industriel, qui sont généralement prescriptifs. Par conséquent, nous ne tiendrons pas compte ici des autres types de modèles.
12
1.1.2.1
Le Rational Unified Process (RUP) (Kruchten 2000) a été conçu par Rational
Software Corporation (acquise depuis par IBM). Il s’agit d’un modèle de processus
itératif et incrémental2 , centré sur l’architecture du logiciel plutôt que sur le code
(Kruchten 2000). Kruchten définit le RUP comme étant un « produit-processus »
(process product). Le RUP se présente sous la forme d’un système logiciel comprenant essentiellement un site Web interactif ainsi que divers outils comme des
mentors, des gabarits et des exemples d’artéfacts. La figure 1.1 illustre le modèle
conceptuel fondamental du RUP. Le RUP est constitué de trois éléments fondamentaux : le rôle, l’artéfact et l’activité. Un rôle constitue une définition des diverses
responsabilités pouvant être attribuées à un membre d’une équipe de développement (Robillard, Kruchten et d’Astous 2003). Ainsi, chacune des activités peut être
réalisée par un et un seul rôle, et chacun des artéfacts est sous la responsabilité
d’un seul rôle. Une activité consomme un certain nombre d’artéfacts intrants et
produit également un certain nombre d’artéfacts extrants. Un artéfact peut être
consommé ou produit par un nombre indéterminé d’activités.
Le modèle conceptuel fondamental constitue en réalité un composant du métamodèle d’ingénierie de processus logiciel du Object Management Group (2002)
et se situe ainsi au niveau M2 de la hiérarchie des niveaux de modélisation de
2
L’évolution du concept de développement itératif et incrémental est décrite dans Larman et
Basili (2003)
13
1
Rôle
EstResponsableDe
0..*
1
Artéfact
0..*
0..*
intrant
Produit
Consomme
Réalise
0..*
0..*
0..*
Activité
Figure 1.1 – Modèle conceptuel fondamental du RUP (traduit de Robillard, Kruchten et d’Astous 2003)
cette organisation. Il peut s’appliquer à d’autres modèles de processus que le RUP.
Il est donc important de noter que l’indétermination des multiplicités du modèle
(nombre d’artéfacts intrants et extrants par activité, nombre d’activités consommatrices et productrices par artéfact, nombre d’activités et d’artéfacts par rôle)
existe uniquement sur le plan du métamodèle. En pratique, le modèle de processus
définit exactement les rôles, activités et artéfacts proposés ainsi que les relations
entre ceux-ci.
14
Figure 1.2 – Modèle bidimensionnel de processus et de cycle de vie du UPEDU
(traduit de École Polytechnique de Montréal 2002)
1.1.2.2
Le UPEDU (École Polytechnique de Montréal 2002) est un modèle de processus
dérivé du Rational Unified Process. Il a été mis sur pied par l’École Polytechnique
en collaboration avec Rational Software Corporation. Il a été décrit en détail dans
Robillard, Kruchten et d’Astous (2001, 2003). Les caractéristiques du RUP telles
que mentionnées à la section précédente s’appliquent également au UPEDU, sauf
mention contraire. La figure 1.2 illustre le modèle bidimensionnel de processus et de
cycle de vie du UPEDU, qui constitue un sous-ensemble du modèle correspondant
15
à l’intérieur du Rational Software Process. En abscisse figurent les quatre phases
qui composent le cycle de vie ; ces phases sont les mêmes que pour le RUP. Chacune
des phases peut être subdivisée en un certain nombre d’itérations, suivant le détail
du processus retenu ou à la discrétion du gestionnaire de projet.
– La phase de commencement (inception) a pour but de permettre à tous les
intervenants de s’entendre sur les objectifs du cycle de vie du logiciel. Elle est
plus importante pour les projets de développement de nouveaux logiciels que
pour les projets de maintenance.
– La phase d’élaboration vise à établir les requis du système à développer et à
établir en détail l’architecture de celui-ci.
– La phase de construction vise à revoir les aspects perfectibles des requis et à
produire le système selon l’architecture retenue.
– La phase de transition comprend la réalisation des tests de validation et des
derniers ajustements ainsi que la mise en disponibilité du logiciel aux usagers.
En ordonnée de la figure 1.2 figurent les six disciplines qui composent le modèle. Chaque discipline constitue un regroupement des activités susceptibles d’être
réalisées afin de produire un ensemble spécifique d’artéfacts (École Polytechnique
de Montréal 2002). Une activité constitue la plus petite unité de travail mesurable
effectuée par un membre de l’équipe de développement, alors qu’un artéfact est
défini comme étant un élément d’information produit dans le cadre de l’exécution
du processus logiciel (Robillard, Kruchten et d’Astous 2003). Les six courbes de la
16
Figure 1.3 – Définition des jalons au cours du cycle de développement (traduit de
École Polytechnique de Montréal 2002)
figure 1.2 illustrent l’effort déployé au sein de chaque discipline au fil d’un projet.
La distribution de l’effort telle qu’illustrée est purement arbitraire et ne présuppose
aucunement de l’allure des efforts déployés au cours d’un projet réel.
La figure 1.3 illustre les jalons associés à chacune des phases du cycle de développement. L’atteinte d’un jalon entraı̂ne l’évaluation de l’atteinte des objectifs
de la phase correspondante. La phase subséquente peut être entreprise uniquement
dans le cas où ces objectifs sont atteints.
– Le jalon d’objectifs du cycle de développement vise à évaluer les objectifs du
projet entrepris.
– Le jalon d’architecture du cycle de développement touche l’évaluation de la
portée et des objectifs détaillés du système, de l’architecture choisie et des
risques principaux.
17
– Le jalon initial de capacité opérationnelle vise à s’assurer que toutes les fonctionnalités ont été développées, que tous les tests « alpha » ont été réalisés,
qu’un manuel d’utilisation a été préparé et qu’une description de la livraison
sous étude a été rédigée.
– Le jalon de livraison du produit correspond à la réalisation réussie de la revue
d’acceptation de projet.
Le Object-oriented Process, Environment and Notation (OPEN) (Open Consortium 2002; Henderson-Sellers 2000) est un modèle de processus du domaine public
qui, comme le RUP, est itératif, incrémental et basé sur le paradigme orienté-objet.
Ce modèle de processus a été conçu de manière à pouvoir soutenir de multiples
modèles de cycles de développement, comme le modèle en cascade ou encore le
modèle en spirale (Boehm 1988). Le concept de phase n’a pas été inclus dans ce
modèle. On y définit plutôt les termes suivants :
– Une activité est un ensemble de tâches qui se succèdent au moyen de transitions formelles (pré-conditions et post-conditions) et qui, collectivement,
mènent à la réalisation d’un objectif à long terme et débouchent sur un ensemble de produits de travail.
– Une tâche constitue la plus petite unité de travail pouvant être évaluée.
– Une technique englobe l’ensemble du savoir-faire requis pour la réalisation
des tâches, la relation entre tâches et techniques étant définie par le biais
d’une matrice d’adaptation.
18
– La notion de produit de travail (work product) correspond approximativement
à la notion d’artéfact du RUP.
Henderson-Sellers (2000) prétend que « The beauty of the OPEN framework is that
it does not lay down the law on what you shall and shan’t do. » et qu’il peut, et doit,
être adapté aux organismes et projets visés. Quant au RUP, même s’il a été conçu
de manière à pouvoir être appliqué intégralement, on pourrait l’adapter également
(Kruchten 2000). Il est par conséquent difficile d’établir une comparaison entre les
deux modèles en présence sur cette base, comparaison qui déborde du cadre de cet
ouvrage.
1.2
Méthodologies agiles de développement de logiciels
L’un des deux articles intégrés dans le présent ouvrage touche directement l’uti-
lisation de la méthodologie de programmation extrême (extreme programming ou
XP). Cette méthodologie fait partie de la grande famille dite des méthodologies
agiles. Nous présenterons d’abord les caractéristiques générales de cette famille
puis nous présenterons plus en détail la méthodologie elle-même.
1.2.1
Survol des méthodologies agiles
Les méthodologies dites agiles ont pour but de soutenir le développement de
logiciels d’une manière moins rigide que par l’utilisation de processus formels. Le
Manifeste du développement agile (Agile Alliance 2003) mentionne les valeurs vé-
19
hiculées par cette philosophie du développement de logiciels :
– priorité des individus et des interactions sur les processus et les outils ;
– priorité du logiciel fonctionnel sur l’exhaustivité de la documentation ;
– priorité de la collaboration client-fournisseur sur la négociation contractuelle ;
– priorité de la réponse au changement sur le suivi de plans bien définis.
Bien que le Manifeste ait été rédigé principalement en réaction aux tendances
contemporaines en matière de processus logiciels, il n’en demeure pas moins que
la nomenclature « processus » et « méthodologies agiles » ne constitue pas une
dichotomie comme telle. Ainsi, Glass (2001) énumère les forces et les faiblesses
respectives des deux approches et plaide pour la combinaison pure et simple des
meilleures idées. Kruchten (2001), quant à lui, prétend que la structure du RUP
permet l’intégration des caractéristiques de flexibilité recherchées.
Les méthodologies agiles sont avant tout des méthodologies indépendantes qui
existaient déjà pour la plupart au moment de la rédaction du Manifeste, plutôt
qu’une famille de méthodologies dérivées d’une philosophie originelle. Pour cette
raison, nous considérons qu’il convient de passer directement à l’étude de la méthodologie dont il est question dans ce travail de recherche, soit la méthodologie de
programmation extrême.
20
1.2.2
La programmation extrême
La programmation extrême ne constitue pas un modèle de processus à proprement parler mais plutôt une méthodologie reposant sur un ensemble de treize
pratiques. Cette méthodologie, décrite en détail dans Beck (1999, 2000), repose sur
le rejet du postulat de l’augmentation exponentielle du coût des modifications à
un logiciel au fur et à mesure qu’elles se déroulent tard dans le cycle de développement (Pressman 2000). L’application des pratiques de la programmation extrême,
et en particulier l’application d’un cycle incrémental de développement suivant des
itérations extrêmement courtes, ponctuées de livraisons intermédiaires obligatoires,
se veut le mode d’emploi vers l’obtention d’une courbe croissante mais plafonnée
des coûts de modification du logiciel en fonction du moment où elles sont amenées
(voir figure 1.4). La relation entre les courbes de coûts pour chaque cas peut s’exprimer mathématiquement comme suit. Soient t le temps écoulé depuis le début de
la réalisation d’un projet ; c le coût d’un changement réalisé au temps t ; et n une
constante quelconque. Pour n, t, c ∈
; n > 1; t ≥ 0 :
– Processus conventionnel :
c(t) = tn
(1.1)
c(t) = t1/n
(1.2)
– Programmation extrême :
21
Coût en $ (c)
Processus
conventionnel
XP
Figure 1.4 – Évolution comparée des coûts du changement au fil du cycle de développement, selon les idées de Beck (1999)
Les conséquences sur la stratégie de développement découlant de l’utilisation de
l’une ou l’autre de ces courbes sont cruciales. L’équation 1.1 mène directement à
une stratégie visant à minimiser les coûts du changement par la prise des décisions
de fond le plus tôt possible dans le projet, notamment sur les volets des requis et de
l’architecture, et par le gel de celles-ci. De manière contrastée, dans le contexte de
l’équation 1.2, le retardement de la prise des décisions de fond comporte un impact
beaucoup moindre sur la profitabilité du projet. Il s’ensuit que, selon la théorie de
la programmation extrême (Beck 1999), le gestionnaire de projet doit se rabattre,
22
dans sa quête d’une plus grande économie dans la réalisation du projet, sur les
méthodes classiques de la maximisation de la valeur économique des projets (Lutz
1992). Une telle approche passe par l’application de la méthodologie de planification
des travaux suivante.
– Il s’agit d’abord de percevoir le projet non pas comme une entité unique mais
plutôt comme une succession de mini-projets appelés « livraisons », fondés
successivement les uns sur les autres. Ainsi, la version la plus récente du
système logiciel est livrée au client à la fin de chaque mini-projet.
– Il faut ensuite procéder à l’ordonnancement des travaux au niveau macroscopique, ainsi qu’à la planification de la première livraison afin de maximiser
la valeur de celle-ci dans la perspective du client. Les caractéristiques qui ne
contribuent pas à cet objectif sont exclues de la livraison.
– Une fois la livraison effectuée, il s’agit d’en facturer immédiatement le contenu
et de passer à la livraison suivante.
Cette approche par livraisons fréquentes doit permettre de maximiser la valeur du
projet par l’application des trois tactiques suivantes :
– Les dépenses surviennent plus tard car l’implantation des caractéristiques
non essentielles à la qualité d’une livraison est constamment retardée. Ce
retardement contribue à réduire le coût net du projet. Pour cette même raison,
les caractéristiques initialement souhaitées, mais pour lesquelles l’intérêt du
client diminue au fil du projet, finissent par ne jamais être implantées, ce qui
23
Développement / Maintenance
Déploiement
It. #n
…
It. #2
It. #1
Exploration
Itérations
Figure 1.5 – Modèle simplifié du cycle de développement et de maintenance en
programmation extrême
a des effets directs sur le coût du projet.
– L’obtention de revenus est plus rapide, étant donné la facturation à chaque
livraison, ce qui diminue le risque financier associé au projet, allège les besoins
en liquidités et augmente la valeur nette du projet.
– Le risque d’échec est réduit grâce à la validation constante de la valeur du
projet par le client.
La figure 1.5 illustre un modèle simplifié du cycle de développement et de maintenance en programmation extrême, basé sur Ambler (2002); Beck (2000). Le cycle
de développement ou de maintenance constitue le cœur du modèle. Il englobe les
phases de planification, de développement itératif et de déploiement. Chaque exécu-
24
tion du cycle mène à une livraison du logiciel. Le cycle assurant la livraison initiale
est appelé « cycle de développement », alors que ceux débouchant sur les livraisons
suivantes sont appelés « cycles de maintenance ».
La phase d’exploration amorce le projet et permet à l’équipe de développement
de s’entendre avec le client sur le contenu souhaité du logiciel et d’évaluer avec
suffisamment de précision les coûts et délais associés à l’envergure de ce contenu.
Sa portée peut s’étendre à l’ensemble de la durée du projet (Ambler 2002) ou
simplement à la livraison à venir (Beck 2000).
La phase de planification est réalisée strictement dans la perspective de la livraison à laquelle elle se rattache. Elle permet à l’équipe de développement de
s’entendre avec le client sur le contenu de la première livraison ainsi que sur une
date de livraison.
La phase de développement itératif est conforme aux principes du développement incrémental (Mills 1980). Ainsi, le logiciel est développé graduellement au
cours des diverses itérations planifiées au début de la phase. Chaque itération est
d’une durée d’une à quatre semaines. Elle débouche non seulement sur du code de
production mais également sur un ensemble de cas de tests fonctionnels couvrant
l’ensemble des mini-scénarios ou « histoires » qui la définissent. En outre, tous
les composants de tests unitaires et d’intégration pertinents à l’itération auront
été produits préalablement à la création du code de production, et tous devront
pouvoir être exécutés sans faute avant que l’itération ne puisse être conclue.
25
Notons que l’itération initiale d’un cycle de développement ou de maintenance
doit permettre de statuer sur les caractéristiques de l’architecture du logiciel à
construire ou à modifier. Les principes de croissance du logiciel sur son squelette,
préconisés par Beck (2000), sont semblables à ceux proposés par Robillard, Kruchten et d’Astous (2003) dans le cadre du UPEDU.
La phase de déploiement (productionizing) (Ambler 2002) constitue une extension de la phase de développement incrémental au cours de laquelle on procède aux
divers tests fonctionnels sur le système et effectue les modifications découlant de
ceux-ci.
1.2.3
Les processus d’ingénierie par opposition aux méthodologies agiles
La guerre de clochers que se livrent avec plus ou moins de passion les partisans
des processus d’ingénierie et ceux des méthodes agiles repose sur fort peu de matériel empirique pertinent. Bien que de nombreuses études portent sur la comparaison
de certains aspects précis des méthodologies agiles par rapport à leur conception
traditionnelle (voir par exemple Williams, Kessler, Cunningham et Jeffries 2000,
qui traite de la programmation par paires), les études comparatives entre les deux
approches prises globalement (voir par exemple Noll et Atkinson 2003) sont encore
rares. Une analyse appropriée du comportement réel des ingénieurs du logiciel permettrait d’éclairer grandement notre compréhension des forces et des faiblesses des
méthodologies ou des processus appliqués.
26
1.3
La mesure des processus logiciels
La mesure des processus logiciels, considérée au sens large, fait partie des tâches
reconnues par l’école classique du génie logiciel comme étant nécessaires à la production de systèmes logiciels de qualité. À titre d’exemple, le niveau 4 du Capability
Maturity Model (CMM) (Paulk, Curtis, Chrissis et Weber 1993) du Software Engineering Institute est entièrement axé sur la gestion quantitative de la qualité des
produits et processus logiciels. Ce niveau comprend un secteur clé intitulé « Gestion
quantitative du processus », qui traite du contrôle quantitatif de la performance
d’une instance de processus. L’accent est mis sur la recherche des causes spéciales
de variation à l’intérieur d’un processus stable, ainsi que sur la correction de ces
causes. Bien entendu, une telle démarche repose sur la capacité des intervenants à
effectuer une mesure adéquate du processus. De même, le Personal Software Process (PSP) (Humphrey 1997), également du Software Engineering Institute, intègre
la mesure du processus à tous les échelons de celui-ci. La mesure de processus prescrite couvre plus particulièrement la mesure de l’effort, des coûts et de la taille
du logiciel, mais également celle des défauts produits, des taux d’élimination des
défauts, de la productivité ainsi que de la qualité du processus au sens large.
1.3.1
L’estimation de l’effort
La mesure des processus logiciels a traditionnellement été régie par le besoin
d’obtenir des estimations précises de l’effort déployé. L’évaluation des coûts d’un
27
projet d’ingénierie est requise afin de permettre la prise de diverses décisions ou
l’évaluation de certaines informations : accord pour le démarrage ou la poursuite
du projet ; construction ou achat ; détermination du prix de vente ; calcul du rendement des investissements ; allocations budgétaires (Ostwald 1992). Le génie logiciel,
discipline qui constitue ni plus ni moins que l’application de l’ingénierie au logiciel
(Standards Coordinating Committee of the Computer Society of the IEEE 1990),
ne fait pas exception à la règle. Il faut noter toutefois que, comme les coûts de
main-d’œuvre constituent généralement une très forte proportion des coûts globaux de développement et de maintenance d’un logiciel (Fenton et Pfleeger 1997;
Florac et Carleton 1999), l’évaluation de l’effort requis dans le cadre d’un projet
s’avère souvent le déterminant le plus important du coût prévisible de celui-ci.
Or, la qualité générale des estimations de coûts et d’échéanciers en génie logiciel
est d’une faiblesse notoire (Fenton et Pfleeger 1997). Le Standish Group (2001) diffuse les statistiques suivantes portant sur l’état de l’industrie américaine du logiciel
au cours de l’année 2000 :
– 28 % des projets sont terminés à temps et à l’intérieur des estimations initiales.
– 49 % des projets sont annulés avant leur achèvement ou ne sont jamais mis
en œuvre.
– Les dépassements de coûts équivalent en moyenne à 45 % des estimations
initiales.
28
– En moyenne, les logiciels livrés répondent à 67 % des besoins spécifiés.
Les statistiques laissent entrevoir non seulement une difficulté généralisée à maı̂triser les paramètres qui contrôlent l’envergure d’un projet de développement, mais
également un manque généralisé de contrôle du processus logiciel. C’est pourtant
le processus logiciel qui permet de transformer les besoins des usagers en produits
logiciels (Standards Coordinating Committee of the Computer Society of the IEEE
1990). L’incapacité de combler l’ensemble des besoins formels exprimés dans le
cadre d’un projet de développement constitue clairement un échec du processus
logiciel. À l’inverse, l’application adéquate d’un processus logiciel approprié doit
permettre non seulement de livrer les caractéristiques fonctionnelles et non fonctionnelles prévues, mais d’y parvenir sous des conditions prévisibles de coûts et
de délai de livraison et de réduire ainsi la fréquence des problèmes mentionnées
précédemment.
Notons que les modèles de coût et d’effort les plus courants n’intègrent pas les
caractéristiques du modèle de processus utilisé. Bien sûr, certains modèles de coûts
et d’effort, comme c’est le cas du COCOMO II (Boehm, Clark, Horowitz, Westland, Madachy et Selby 1995), tiennent compte des méthodes de développement en
place, de la maturité du processus logiciel ou de l’influence de facteurs purement
locaux. Toutefois, l’absence de lien direct entre le modèle de coûts et le modèle de
processus constitue un inconvénient notable dans le contexte de la boı̂te à outils
du gestionnaire de projets ou de l’ingénieur de processus logiciel. Morisio (1999)
29
constate que, même si une attention croissante est portée à la modélisation des
processus logiciels, l’établissement d’un couplage strict entre celle-ci et la mesure
de processus en est à ses premiers balbutiements.
1.3.2
La mesure de l’effort
Dans le cadre d’un travail d’analyse des discussions lors de réunions d’inspection,
Seaman et Basili (1998) exposent la distinction entre les méthodes de recherche qualitatives et quantitatives. Selon ces auteurs, les méthodes qualitatives permettent
d’analyser des données comme des mots ou des images et sont surtout utilisées afin
de générer des hypothèses, plutôt que les mettre à l’essai. Les méthodes quantitatives touchent l’analyse de données numériques et sont souvent utilisées aux fins de
confirmation ou de tests d’hypothèses déjà émises.
Dans le cas de la présente étude, la nature exploratoire des travaux amène
naturellement à considérer les aspects qualitatifs d’une démarche de recherche.
Toutefois, l’étude, bien qu’exploratoire, a été réalisée dans le contexte de méthodologies et modèles existants et bien définis. Elle a pour thème central l’effort déployé
par les développeurs, entité qui s’analyse le plus souvent de manière quantitative.
Pour ces raisons, et de la même manière que Seaman et Basili, nous optons pour
l’utilisation d’une approche hybride qualitative-quantitative.
Selon Robillard, Kruchten et d’Astous (2003, chap. 12), deux facteurs font de
la mesure de l’effort une entreprise ardue et susceptible d’engendrer des données
30
difficiles à interpréter. D’abord, la mesure de l’effort nécessite un minimum d’interactions avec les individus, ce qui oblige la prise en compte de nombreux aspects
sociaux et psychologiques. Ensuite, les systèmes courants de mesure de l’effort
présupposent l’existence d’une relation un-à-un entre les activités mesurées et les
tâches selon lesquelles l’effort est enregistré. En pratique, rien n’assure une telle
adéquation. Les auteurs énumèrent quatre menaces distinctes à la validité des données d’effort, soit : la validité des mesures proprement dites, la non-uniformité des
intervalles de temps, la non-uniformité de l’utilisation des jetons et l’ambiguı̈té des
jetons. Germain, Dulipovici et Robillard (2002a) ont montré que, même en utilisant
un système de mesure basé sur la classification des activités du UPEDU et sur le
découpage du temps en quantas bien définis, les données recueillies montraient des
signes notables d’ambiguı̈té et de confusion.
La littérature est pauvre en ce qui a trait aux principes de mesure de l’effort dans
des contextes nécessitant la séparation détaillée de l’effort en activités. La mesure
des activités cognitives effectuée par les ingénieurs du logiciel, quant à elle, est
relativement récente (Robillard 1998) et a notamment été utilisée dans le contexte
de l’analyse fine des échanges entre les membres d’une équipe de développement
(d’Astous 1999; Seaman et Basili 1998). Cette situation peut s’expliquer en partie
par le degré de difficulté associé à la mesure des processus en général. Seaman (1999)
explique que les aspects d’un processus de développement de logiciels qui s’offrent
à l’observation sont limités. Une partie importante du travail de développement de
31
logiciels s’effectue à l’intérieur de la tête des développeurs et est, par conséquent,
plus difficile à observer.
1.4
Le contrôle des processus
Une des applications les plus intéressantes de l’approche préconisée au chapitre 4
touche le développement d’approches de contrôle de processus et d’estimation en
cours de projet. La présente section offre un survol rapide de ces domaines. Un
exposé détaillé des concepts et approches en la matière peut être trouvé dans Münch
et Heidrich (2004). Bien que ces concepts ne se situent pas dans l’axe de la recherche
effectuée et sont, somme toute, encore peu utilisés en milieu industriel, ils pourraient
redevenir d’actualité suite aux travaux présentés dans le cadre de ce mémoire, ou
dans le cadre de recherches similaires.
Un centre de contrôle de projet logiciel (Software Project Control Center ou
SPCC, tel que défini par Münch et Heidrich 2004) est un outil assimilable à un
système de contrôle de trafic aérien, servant de colonne vertébrale à la démarche
de mesure, d’interprétation et de visualisation des métriques issues d’un processus
logiciel. Le SPCC utilise un ensemble de métriques recueillies dans le cadre d’un
projet en cours ainsi qu’une banque de métriques issues de projets antérieurs, et
génère une vue contextualisée de ces données aux fins de leur utilisation par, notamment, les gestionnaires de projets ainsi que le personnel d’assurance-qualité.
Un SPCC est formé des éléments suivants :
32
– un ensemble de techniques et de méthodes de contrôle de projet ;
– un ensemble de règles touchant l’utilisation des techniques et méthodes ;
– une architecture logique permettant l’interfaçage du SPCC avec son environnement ;
– un outil mettant en œuvre l’architecture logique.
Münch et Heidrich présentent également quatre techniques et méthodes pouvant
être utilisées aux fins de contrôle d’un projet, soit :
– l’analyse par arbre de classification ;
– les variables dynamiques ;
– l’analyse par grappe (Cluster analysis) ;
– la détection des changements de tendance.
L’une de ces approches, l’analyse par grappe, peut s’avérer particulièrement utile
pour l’analyse des patrons d’effort déployés au cours d’un projet. Les métriques
de projet recueillies, touchant l’effort ou toute autre variable de processus, sont
représentées par un vecteur multidimensionnel composé de valeurs mesurées à autant de périodes distinctes. La technique d’analyse par grappe permet de cerner
des ensembles de données qui affichent le même comportement et ce, afin de répertorier des groupes de patrons similaires. Le calcul de la distance euclidienne entre
les vecteurs permet la catégorisation des grappes. Li et Zelkowitz (1993) ont utilisé
des vecteurs à 15 dimensions ainsi qu’un échantillon de 24 projets afin de relever les
patrons émergeant de huit indicateurs distincts, dont l’effort total employé. La seg-
33
mentation de l’échelle temporelle a été réalisée en subdivisant chacune des quatre
phases des projets en un nombre variable de portions. L’application de la technique
sur les projets existants a permis d’illustrer, selon les auteurs, le pouvoir prédictif
d’une telle approche. Ce constat amène naturellement à envisager l’utilisation des
données empiriques recueillies en cours de projet pour la réestimation en ligne dudit projet. Le chapitre 4 décrit brièvement les travaux de MacDonell et Shepperd
(2003) sur une telle approche.
34
ORGANISATION GÉNÉRALE DU TRAVAIL
Ce mémoire présente le fruit d’un travail de recherche approfondi qui a porté sur
trois éditions successives du cours « Atelier de génie logiciel » (voir Robillard 1996)
ainsi que sur deux approches distinctes de développement de systèmes logiciels. Les
travaux réalisés ainsi que leurs conclusions sont rapportées dans les trois chapitres
qui suivent.
Le chapitre 3 introduit le premier des deux articles qui constituent le corps
du présent travail. L’article, intitulé « Engineering-Based Processes and Agile Methodologies for Software Development : A Comparative Case Study », par Éric
Germain et Pierre N. Robillard, a été accepté pour publication par la revue The
Journal of Systems and Software. L’étude de cas présentée couvre l’application
de deux approches distinctes de développement de logiciels dans le cadre de l’implantation de versions multiples d’une même spécification de requis logiciels. Elle a
nécessité la définition d’une catégorisation originale des activités cognitives réalisées
par les sujets de l’étude, qui étaient des étudiants inscrits à l’édition 2002 de l’Atelier. Trois des équipes ont utilisé un modèle de processus très fortement inspiré du
Unified Process for Education (UPEDU), modèle de processus dérivé du Rational
Unified Process (RUP). Les trois autres équipes ont utilisé un processus construit
35
autour de la méthodologie de programmation extrême (Extreme Programming ou
« XP »).
Le chapitre 4 constitue le second des deux articles qui forment le corps de
ce travail. L’article, intitulé « Measuring Relative Effort Progression Paths in the
Discipline Space of the Software Engineering Process », également par Éric Germain
et Pierre N. Robillard, a été soumis pour publication à la revue IEEE Transactions
on Software Engineering. L’analyse présentée vise à cerner des patrons au sein
des diagrammes de répartition de l’effort relatif en disciplines à travers le cycle
complet de développement d’un système logiciel. Huit équipes d’étudiants, issues
de trois éditions différentes de l’Atelier (2001, 2002 et 2003), ont utilisé un modèle
de processus très fortement inspiré du UPEDU afin de développer des systèmes
logiciels distincts. Les spécifications soumises, les durées de cycle de développement,
les technologies utilisées et les mécanismes de cueillette de l’effort déployé variaient
à divers degrés d’une édition à l’autre. Le nombre de participants différait également
d’une équipe à l’autre. Une catégorisation en trois disciplines des activités réalisées
a été définie de manière à permettre une ségrégation substantielle des activités
tout en minimisant l’influence des facteurs liés à l’édition ou à la taille de l’équipe.
L’article comporte une annexe, dont le texte est présenté à l’annexe I du mémoire.
Le choix et l’ordonnancement des articles intégrés dans ce mémoire sont justifiés
par la nécessité de clarifier successivement les diverses sources d’influence pouvant
s’exercer sur l’effort déployé. Avant la réalisation du présent travail de recherche, les
36
limites de la valeur potentielle de l’Atelier comme plate-forme de recherche n’étaient
pas clairement établies. L’Atelier de génie logiciel constitue certes une plate-forme
très intéressante pour l’étude du comportement des développeurs ; toutefois, un inconvénient notable du concept est le faible nombre d’équipes participantes lorsque
chaque édition est considérée séparément. Cet inconvénient empêche l’utilisation
des outils statistiques conventionnels aux fins d’une analyse formelle de la convergence des comportements d’une équipe à l’autre. Il importait donc de clarifier les
limites réelles découlant de ces contraintes.
Le premier article permettait d’identifier l’influence du modèle de processus
sur l’effort déployé par les participants au niveau d’agrégation choisi. Une influence
indue du modèle de processus sur le comportement cognitif des développeurs aurait
grandement limité la capacité de généralisation de l’analyse au milieu industriel.
Par ailleurs, l’étude visait également à établir le degré approprié de granularité des
disciplines utilisées aux fins de l’analyse de la répartition de l’effort. En ce sens, le
premier article a permis d’ouvrir la voie à l’approfondissement de la question des
patrons d’effort dans la perspective du degré d’avancement d’un projet.
Quant au second article, il vise à ouvrir une fenêtre permettant de sortir du
carcan de l’analyse en mode mono-édition, en montrant que certains patrons d’effort
transcendent les caractéristiques de projet et d’équipe. Cette démarche est cruciale
pour l’application éventuelle des analyses de patrons vers le milieu industriel, où la
présence de projets similaires réalisés en parallèle par des équipes de développement
37
distinctes constitue l’exception plutôt que la règle.
En somme, le choix et la séquence des articles intégrés dans ce mémoire reflètent une progression séquentielle naturelle des travaux vers la réalisation future
d’analyses de patrons d’effort en milieu industriel.
Par ailleurs, trois articles de conférence auxquels l’auteur a contribué ont été
inclus sur un disque compact qui accompagne ce mémoire. Le contenu du disque
est présenté brièvement à l’annexe II. Les deux premiers articles (Germain, Dulipovici et Robillard 2002a; Germain, Robillard et Dulipovici 2002b) portent sur
l’édition 2001 de l’Atelier et illustrent de façon préliminaire la faisabilité de l’approche entreprise dans la présente recherche. Ils illustrent également les difficultés
inhérentes à la démarche, notamment en soulevant la question de l’ambiguı̈té et
de la confusion de la classification en activités de processus. Le troisième article
(Germain et Robillard 2003) constitue une version préliminaire du chapitre 3 du
présent mémoire.
38
3.1
43
3.2
45
46
UP
UP 1
EQ
UP 2
XP
EQ1
EQ2
XP 1
5
10
UP 3
15
20
XP 2
EQ3
XP 3
25
30
XP 4
35
XP 5
40
UP M
EQM
XP M
45
50
55
60
3.3
51
3.4
3.4.1
Raw-data analysis
54
Control
Reflexive
100%
80%
70%
60%
Implementation
50%
40%
30%
20%
10%
0%
XPA
XPB
XPC
UPA
UPB
UPC
56
6%
Reflexive
3%
29%
4%
8%
4%
11%
21%
4%
5%
3.4.2
Aggregate analysis
57
100%
90%
Reflexive
80%
70%
A
c
t
i
v
e
60%
50%
40%
30%
20%
10%
0%
XP
UPEDU
58
2
1,5
1
XP
UPEDU
0,5
0
-0,5
-1
"!
# PAI = ln(EU P /EXP )
60
1
0,8
0,6
0,4
0,2
0
-0,2
3.5.1
Study limitations
3.5.2
65
3.5.3
3.5.4
68
4.1
4.2
4.3
74
800
700
600
500
400
300
200
100
0
2003C
2002B
2003B
2002A
2003A
2001B
2001C
2001A
75
4.4
76
100%
80%
60%
Engineering
V&V
Coding
40%
20%
0%
2003C 2002B 2003B 2002A 2003A 2001B 2001C 2001A
4.5
77
Pure Coding
Pure V&V
2001B
2002B
2003B
2003A
0,0
2001C
2002A
2003C
y'
2001A
-0,5
-1,0
Pure Engineering
-0,5
0,0
x'
0,5
4.5.1
79
Pure Coding
Pure V&V
0,0
100%
y'
80%
60%
-0,5
40%
20%
Pure Engineering
-1,0
-0,5
0,0
0,5
x'
Pure Coding
Pure V&V
0,0
100%
80%
y'
60%
40%
-0,5
-1,0
20%
0,0
x'
0,5
80
Pure Coding
Pure V&V
100%
0,0
80%
y'
60%
40%
20%
-0,5
-1,0
-0,5
0,0
0,5
x'
Pure Coding
Pure V&V
100%
80%
60%
0,0
y'
40%
-0,5
-1,0
20%
0,0
x'
0,5
81
Pure Coding
Pure V&V
100%
0,0
80%
y'
60%
40%
-1,0
-0,5
0,0
0,5
x'
Pure Coding
Pure V&V
100%
80%
0,0
60%
y'
40%
20%
-0,5
-1,0
0,0
x'
0,5
82
Pure V&V
Pure Coding
0,0
100%
y'
20%
60%
-0,5
-1,0
80%
-0,5
0,0
x'
0,5
Pure Coding
Pure V&V
60%
80%
40%
100%
0,0
y'
20%
-0,5
-1,0
0,0
x'
0,5
4.5.2
4.5.3
4.6
86
100%
80%
60%
Finalization
40%
20%
Coding-2001A
Coding-2001C
100%
Coding-2002B
Coding-2003A
80%
Coding-Avg
60%
40%
V&V-2001A
V&V-2001C
V&V
V&V-2002B
V&V-2003A
20%
V&V-Avg
100%
Engineering-2001A
80%
Engineering-2002B
Engineering-2001C
Engineering-2003A
60%
Engineering-Avg
40%
20%
Engineering
0 --> 20%
20% --> 40%
40% --> 60%
60% --> 80%
80% --> 100%
87
20%
Coding-2001B
100%
Coding-2003B
80%
Coding-Avg
60%
V&V
V&V-2001B
40%
V&V-2003B
20%
V&V-Avg
100%
Engineering-2001B
80%
Engineering-2003B
60%
Engineering-Avg
Engineering
40%
20%
0 --> 20%
20% --> 40%
40% --> 60%
60% --> 80%
80% --> 100%
89
100%
80%
60%
40%
Coding
20%
Coding-2002A
100%
80%
Coding-2003C
60%
V&V-2002A
V&V
40%
V&V-2003C
20%
100%
Engineering-2002A
80%
60%
Engineering-2003C
Engineering
40%
20%
0 --> 20%
20% --> 40%
40% --> 60%
60% --> 80%
80% --> 100%
90
4.7
Analysis
4.7.1
4.7.2
92
4.7.3
4.7.4
Study limitations
4.7.5
Effort distribution: does it make sense?
4.8
97
DISCUSSION GÉNÉRALE
De nombreux éléments de discussion ont été présentés à l’intérieur des deux
chapitres précédents. La présente section vient enrichir ces éléments par quelques
considérations d’ordre général.
5.1
Calibration des charges de travail
Le contenu des spécifications émises a été calibré de manière à refléter une
charge de travail compatible avec un cours de trois crédits, soit l’équivalent de
135 heures par étudiant. En l’absence de données à long terme qui auraient pu
alimenter un modèle d’estimation en bonne et due forme, cette calibration a été
effectuée sur la base du jugement des enseignants. Selon la recherche effectuée, on
pose l’hypothèse que la charge de travail attribuée aux équipes était raisonnable
compte tenu des ressources et du temps alloués pour la réalisation des projets.
À titre d’illustration, deux modèles souvent utilisés pour fins d’estimation, soit le
COCOMO II et le modèle SLIM de Putnam, tiennent pour acquis que la relation
entre la durée optimale de réalisation D, typiquement en mois, et l’effort requis
E, typiquement en personnes-mois, n’est pas linéaire (Fenton et Pfleeger 1997),
98
suivant généralement une courbe de la forme
D = aE b
où a et b sont des constantes et 0 < b < 1. Dans University of Southern California
(1998), il est mentionné que :
“(. . . ) Accelerated schedules tend to produce more effort in the later
phases of development because more issues are left to be determined due
to lack of time to resolve them earlier. (. . . ) A stretch-out of a schedule
produces more effort in the earlier phases of development where there
is more time for thorough planning, specification and validation.”
En pratique, la convergence remarquable des patrons d’effort présentés au chapitre 4 peut porter à croire que la présence éventuelle de tels phénomènes a eu peu
d’impact sur la qualité des observations. Incidemment, la mesure de l’avancement
des projets a été réalisée en utilisant la proportion de l’effort total réalisé à un
instant donné, plutôt que les dates indiquées sur les jetons d’effort. Ce choix avait
justement pour but de minimiser l’impact de ces phénomènes.
5.2
La classification en disciplines
La classification des activités cognitives ou de processus en catégories ou dis-
ciplines a été réalisée en fonction des contraintes inhérentes aux processus et aux
99
approches de mesure de l’effort utilisés. Bien qu’ayant permis la réalisation d’observations intéressantes, les classifications réalisées sont exploratoires et devront être
raffinées. La réalisation de classifications pertinentes est essentielle pour l’obtention
de patrons significatifs et, partant, pour le développement de mécanismes viables en
matière de contrôle de processus et d’estimation en cours de projet. Les principales
caractéristiques de qualité d’une classification en disciplines sont les suivantes :
– La classification doit pouvoir s’arrimer naturellement avec la ou les classifications de bas niveau des activités cognitives ou de processus utilisées dans
le cadre de la prise de mesures. Idéalement, chaque activité doit pouvoir être
rattachée clairement à l’une ou l’autre des disciplines, sans qu’il soit nécessaire d’étudier le contexte du jeton avant de pouvoir prendre une décision à
cet effet.
– La classification doit permettre une discrimination claire entre les courbes
d’effort issues de chaque discipline.
– Elle doit pouvoir absorber des variations raisonnables sur le plan de facteurs
tels que le processus utilisé, la nature ou la taille des projets, ou encore la taille
des équipes, sans que ces variations ne se reflètent de manière significative
dans les courbes d’effort. Le caractère raisonnable des variations acceptées
dépend du contexte de la mesure et de l’utilisation prévue des résultats.
– La classification doit comporter un nombre optimal de disciplines et ce, afin
d’équilibrer les deux contraintes suivantes :
100
– Elle doit permettre l’élimination des effets découlant de la substitution
mutuelle possible des activités enregistrées par les participants. De telles
substitutions peuvent survenir notamment pour des raisons d’ambiguı̈té
de la classification de bas niveau des activités, ou encore pour des raisons
de choix de méthodes de travail non couvertes par la classification de bas
niveau des activités.
– Elle doit comporter un nombre suffisant de catégories afin d’offrir une perspective fine lors de l’analyse des patrons d’effort. Un nombre élevé de patrons significatifs est suceptible d’engendrer une meilleure précision d’analyse.
Le principal avantage de la classification par état employée au chapitre 3, relativement à la génération de patrons d’effort, est la stabilité montrée par rapport
au modèle de processus utilisé. En pratique, toutefois, l’utilité de cette caractéristique peut varier considérablement selon le contexte. Une organisation désireuse de
pratiquer le contrôle de processus et disposant d’un modèle générique de processus
qu’elle réussit à appliquer avec peu de modifications à la plupart de ses projets
risque peu d’en bénéficier. De façon générale, une classification sera plus utile si
elle réussit à soutenir des conditions de projets diversifiées plutôt que des processus
très différents. De toute manière, des conditions de projets variables devraient normalement entraı̂ner des variations correspondantes dans les modèles de processus
utilisés. La classification par état comporte par ailleurs l’inconvénient d’être diffici-
101
lement utilisable à l’extérieur d’un contexte où les données d’effort sont recueillies
selon les activités cognitives réalisées. En effet, une activité de processus est susceptible d’incorporer à la fois des activités cognitives liées à la réflexion, à l’action et
à l’interaction. Ces éléments ne doivent toutefois pas occulter l’utilité remarquable
de cette classification à des fins d’analyse empirique, ainsi que les conclusions du
chapitre 3 le laissent entrevoir.
La classification par étape possède une structure similaire à la classification en
trois disciplines présentée au chapitre 4. Les deux classifications séparent également les activités réalisées selon leur position par rapport à un noyau central, à
savoir l’implantation des composants logiciels. Les activités en aval de ce noyau
sont placées dans une catégorie ; celles en aval sont placées dans une autre, et les
activités d’implantation sont placées dans une troisième. Les différences dans la
répartition des activités au sein de chacune des catégories tiennent avant tout au
rôle des classifications dans leur étude respective. La classification originale par
étape avait notamment été conçue avec l’idée d’isoler spécifiquement les activités
de préparation et de contrôle, supposément davantage exécutées en mode UPEDU
qu’en mode XP (ce qui a été confirmé dans un seul des deux cas). Bien que cet
objectif s’appliquait dans une moindre mesure à la classification du chapitre 4, la
préoccupation de base dans ce dernier cas était plutôt de cerner trois pôles d’activités représentant des modes de fonctionnement enclenchés successivement dans
l’exécution d’un projet typique. Nonobstant ces différences, la structure commune
102
Tab. 5.1 – Un exemple de classification en disciplines, basée sur les disciplines
originales du UPEDU
Préparation
Implantation
Contrôle
Requis,
Implantation
Revues
analyse
(planif. technique
(Requis,
Ingénierie
et conception
de l’intégration
analyse et
et de l’implantation)
conception)
(sauf les revues)
Programmation
Revues
Programmation
de programmation
Implantation
(débogage,
Validation et
tests unitaires
vérification
et intégration)
(V&V)
Tests
aux deux classifications rend possible l’étude d’une classification plus fine basée
sur la juxtaposition des deux classifications présentées. Le tableau 5.1 montre un
exemple de classification en sept catégories suivant ce modèle, basée sur les disciplines du UPEDU. Bien entendu, une telle classification reste à valider dans le
cadre d’une démarche empirique, tel que discuté ci-après.
103
Ce travail de recherche a permis d’approfondir notre compréhension des relations entre les caractéristiques des processus et des projets de développement de
logiciels et le comportement des individus qui participent à ces projets. Au-delà
de la rhétorique ambiante sur la valeur comparée des multiples approches de développement, il ressort que le choix d’une approche particulière a un impact limité
sur les activités cognitives réalisées par les équipes étudiées. Cet impact, mesuré
en termes relatifs, se manifeste surtout au niveau des activités d’inspection et de
révision des travaux réalisés.
L’analyse des activités réalisées par chaque équipe étudiée montre une convergence modérée des proportions d’activités réalisées sur l’ensemble du cycle de développement. Toutefois, l’observation la plus notable demeure que la majorité des
projets soumis affichent une évolution très similaire du type d’activités réalisées
au fil du temps. Ainsi, l’effort réalisé suit une progression qui débute par une première phase, où les activités liées à l’ingénierie sont prédominantes. Le poids de
ces activités diminue progressivement, ce qui amène une seconde phase d’équilibre
entre les activités de programmation et celles de validation et de vérification. Cet
équilibre est rompu peu avant la fin du projet, en faveur des activités de validation et de vérification, quoique de manière peu marquée. Bien que l’ensemble de
ces observations soit en accord avec notre compréhension théorique des cycles de
104
développement, l’étude réalisée permet à la fois de confirmer la forte convergence
des patrons d’effort affichés et de les quantifier en termes relatifs à l’effort total
déployé pour chaque projet.
Un des apports principaux de ce travail de recherche est une méthode permettant de pallier à la problématique soulevée par MacDonell et Shepperd (2003), qui
n’ont pu relever clairement de « proportions normalisées » d’effort pour chacune
des phases du cycle de développement. Notre approche montre que de telles proportions peuvent apparaı̂tre, à condition de considérer deux dimensions d’analyse
(les disciplines ainsi que l’avancement des projets) plutôt qu’une seule (la notion de
phase). Les observations effectuées montrent également que l’utilisation de conditions multiples de projets peut permettre de cerner des patrons d’effort pertinents.
Selon Tichy (2000), « The reality of even the most rigorous approach to empirical work is that experiments normally constitute only a small step forward. ».
Cette déclaration s’applique tout à fait au présent travail, d’autant plus qu’il s’agit
ici d’une recherche exploratoire et non d’une expérimentation. En ce sens, seule la
recherche future fondée sur ce travail permettra de le faire fructifier. Ainsi, nous
décelons un certain nombre de voies à suivre pour valider nos observations dans le
cadre d’une démarche expérimentale formelle et vérifier leur applicabilité aux fins
de la planification, de l’estimation et du contrôle des projets et des processus de
développement de logiciels. À cet égard, les recommandations suivantes devraient
être prises en considération.
105
Sur le plan pratique, la validation de l’approche présentée dans le cadre d’une
étude portant sur un nombre élevé de projets industriels se pose comme une perspective de recherche immédiate. Elle peut être réalisée en transposant l’approche en
milieu industriel, ou encore en mesurant directement la viabilité de la classification
en trois pôles dans un contexte d’estimation en cours de projet, comme ce fut le cas
dans l’étude de MacDonell et Shepperd en ce qui concerne leur modèle d’analyse
par phase du cycle de développement.
Dans une perspective plus théorique, les trois catégorisations présentées ont été
analysées à la lumière d’un nombre restreint d’observations. Les caractéristiques
observées, notamment l’équivalence de l’effort de la catégorie « Active » pour les
deux modèles de processus observés, pourraient faire l’objet d’une tentative de
validation dans un contexte plus général.
Une autre avenue de recherche pertinente consiste à tenter de raffiner notre
classification en subdivisant les activités en un nombre plus élevé de disciplines.
Les trois classifications présentées comportent chacune trois disciplines. Bien que
les choix effectués permettent d’obtenir des résultats intéressants sur le plan théorique, l’élaboration de méthodologies d’estimation et de contrôle en cours de projet
risque de nécessiter une granularité plus fine des disciplines. D’autres approches de
segmentation, comme celle présentée au chapitre 5, pourraient être proposées et
vérifiées.
Par ailleurs, l’utilisation de boucles de rétroaction en matière d’estimation et
106
contrôle de projets ne passe pas uniquement par une catégorisation précise en disciplines. Les algorithmes et heuristiques de contrôle des processus à partir des
informations générées en ligne sont susceptibles d’avoir un impact important sur
la stabilité du processus ainsi que sur la qualité et la convergence des estimations.
L’obtention de catégorisations valables ouvre donc la voie à une démarche d’améliorations mutuelles et continues des méthodologies touchant l’analyse de l’effort et
de celles touchant la rétroaction à apporter.
Une limitation notable de notre approche est l’utilisation de mesures normalisées de l’effort. L’effort normalisé constitue sans aucun doute une approche valable
pour l’utilisation de modèles à des fins de contrôle de processus, étant donné l’impossibilité de tenir compte à l’avance des facteurs d’échelle liés à la taille du système
à développer. Toutefois, l’analyse de l’effort absolu par des outils statistiques appropriés serait susceptible de faire ressortir la présence de tendances non détectées
par notre approche principalement observationnelle. Une telle analyse nécessiterait
l’utilisation d’un échantillonnage beaucoup plus important que celui présenté ici.
Finalement, les dernières recommandations ont trait à la méthodologie de mesure proprement dite. D’abord, le contexte de saisie de l’effort (outil, modalités
d’utilisation, subdivision des activités, approche par activités cognitives ou par
activités de processus, etc.) peut avoir une influence significative sur les données
d’effort enregistrées par les participants. Une avenue de recherche pertinente consisterait à déterminer le niveau d’objectivité d’une approche de mesure donnée et à
107
relever les altérations potentielles apportées aux informations enregistrées ainsi que
leurs causes. Le processus de validation des jetons d’effort devrait également constituer l’objet d’une recherche approfondie. Bien que des critères objectifs existants
permettent de guider le travail de la personne responsable de la validation, il existe
un besoin pour l’établissement d’un processus de validation formel, assujetti aux
mêmes critères de qualité que les processus de développement de logiciels dont nous
avons traité.
108
BIBLIOGRAPHIE
AGILE ALLIANCE.
2003.
«Agile alliance web site».
[En ligne].
2002.
2001.
110
D’ASTOUS, Patrick. 1999. Approche de mesure et d’analyse des activités coopératives lors de réunions de révision technique du processus de génie logiciel . 219
p. Thèse de doctorat en génie électrique, École Polytechnique de Montréal.
DAVIS, Noopur, MULLANEY, Julia.
2003.
2002b.
MANAGEMENT
GROUP.
2002.
«Meta
object
faci-
logy/documents/formal/mof.htm (Page consultée le 21 mars 2004).
OPEN CONSORTIUM. 2002. «OPEN : Object-oriented process, environment
and notation». [En ligne]. http ://www.open.org.au (Page consultée le 21 mars
2004).
2002.
[En ligne]. http ://www.salon.com/tech/feature/ 2002/04/08/lehman/index.html
(Page consultée le 21 mars 2004).
119
Annexe I
o
3
~
E
h i
B
=










x 

y
z







:
x+y+z−1=0
(I.1)
~ı0
B




√ 

=
 −1/ 2 



0



(I.2)
120
h i
~0
B
k~0
h i
=
√
 1/ 6 











√ 
1/ 6 

=
B

(I.3)



√
−2/ 6
√
 1/ 3 











√ 
1/ 3 


(I.4)



√
1/ 3
√
1/ 6
√
 1/ 2


P =







√
−1/ 2
0
o
√
1/ 3 


√ 
1/ 3 

√
1/ 6

√
√
−2/ 6 1/ 3
(I.5)



~
E
B0
=









0

x 

y
0
z0







h i
~
= P −1 E
B
121

=









√
(x − y)/ 2
√
(x + y − 2z)/ 6
√
(x + y + z)/ 3











=









√
(x − y)/ 2
√
(x + y − 2z)/ 6
√
1/ 3





.




(I.6)
122
Annexe II
Contenu du support CD fourni
Le disque compact qui accompagne ce mémoire contient trois articles de conférence auquel l’auteur a contribué. Les trois articles sont en format PDF et peuvent
r
r
, version 6,0.
Reader
être visualisés notamment à l’aide du logiciel Adobe
Les articles contenus sont les suivants : Germain, Dulipovici et Robillard (2002a);
Germain, Robillard et Dulipovici (2002b); Germain et Robillard (2003). Les noms
des fichiers correspondent aux identificateurs apparaissant à la bibliographie.
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising

Dans d’autres langues

Seules les pages du document en Français ont été affichées