méthodologie d’ingénierie logicielle adaptée à une...
Post on 13-Sep-2018
236 Views
Preview:
TRANSCRIPT
Méthodologie d’ingénierie
logicielle adaptée à une PME
Auteur : Thiessoz Yannick
Responsable InfoTeam : Beat Ackermann
Responsables UNIFR : Jean Hennebert et Patrik Fuhrer
Type : Travail de master de l’université de Fribourg
Document principal : -
Début : 12.03.2007
Fin : 07.09.2007
Manifesto for Agile Software Development
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas
© 2001, the above authors
this declaration may be freely copied in any form, but only in its entirety through this notice.
Résumé
Résumé
Ce projet est le fruit d’une collaboration entre les groupes Génie logiciel et DIVA1 du
département d’informatique de l’université de Fribourg et une PME Fribourgeoise, InfoTeam.
Le Sujet du présent travail a été proposé par InfoTeam, car cette entreprise, qui utilise à
l’heure actuelle plusieurs méthodologies de développement, est désireuse de connaître leurs
évolutions afin de permettre à leurs clients de disposer des concepts les plus novateurs et les
mieux adaptés à chaque situation.
En effet, la conception de logiciels est un domaine de plus en plus complexe. Il s’avère
actuellement nécessaire, voir même indispensable pour une entreprise active dans le
développement logiciel, de suivre une ou plusieurs méthodologies de développement. Il existe
une multitude de méthodologies et de techniques de développement qui ont toutes leurs
qualités et leurs défauts, mais aucune d’entre elles n’est universellement applicable à tout type
de projets/entreprises. Le cadre de ce travail est donc l’étude des méthodologies existantes
pour en déterminer une qui soit adaptée à une PME comme InfoTeam.
Le préambule de cette étude des méthodologies de développement consiste en l’analyse de
l’usine à logiciels (Microsoft Visual Studio Team System). Cela afin de fournir à InfoTeam un
outil capable de supporter la méthodologie définie.
Le processus de tests est une des parties essentielles des méthodologies de développement
logiciel. C’est pour cette raison que les processus de tests ont été approfondis dans le cadre de
ce projet.
La finalité de ce travail est la mise en place et le développement d’un projet interne à
InfoTeam afin de valider la méthodologie défini dans ce travail.
Mots clés :
Méthodologie de développement logiciel, agilité, Scrum, Extreme Programming, gestion de
projet, suivi de projet, test, usine à logiciels, Microsoft Visual Studio Team System,
InfoTeam.
1 Document, Image and Voice Analysis : http://diuf.unifr.ch/diva/web/
Remerciements
Remerciements
Cette partie vise à exprimer mes remerciements envers toutes les personnes qui ont contribué à
ce travail de master. En espérant n’avoir omis personne, j’espère que vous avez apprécié la
lecture de ce document et que celle-ci vous a été profitable.
Jean Hennbert : Pour ses recommandations avisées, ses remarques toujours constructives, ses
connaissances des méthodologies agiles dont il m’a fait profiter et son enthousiasme constant
pour mon travail.
Patrik Fuhrer : Pour ses relectures approfondies de mon travail, ses conseils toujours
judicieux, son encadrement idéal et l’intérêt qu’il a sans cesse exprimé pour mon travail.
Beat Ackermann : Pour l’accueil qu’il m’a fait au sein d’InfoTeam, son soutien, son
expérience ainsi que l’intérêt qu’il a porté vis-à-vis de mon travail.
Olivier Neuhaus : Pour sa collaboration au projet SuiviStreamX et surtout pour son jugement
de la méthodologie définie.
Romain Roy : Pour l’apport qu’il m’a fourni lors du développement de l’application web de
SuiviStreamX et plus particulièrement de la partie CSS ou il a pu apporter sa grande
expérience.
Mario Ramalho et Fredy Martuccio : Pour toute l’aide qu’ils ont pu m’apporter lors de la
réalisation de projet SuiviStreamX.
L’équipe d’InfoTeam : Pour l’accueil qu’ils m’ont fait au sein de leur entreprise et pour
l’ambiance de travail qui a été toujours très agréable.
Rachel Thiessoz-Barras et Fanchette Oberson : Pour leurs relectures attentives de mon
travail de master ainsi que celles des divers documents annexés. Sans elles et leurs remarques
détaillées et pertinentes ce document ne serait pas ce qu’il est.
Je tiens aussi à remercier ma famille et mes amis pour leur aide et leur soutien tout au long de
la réalisation de ce projet.
Table des matières
6 / 149
Table des matières
1. INTRODUCTION...........................................................................................................................................11 1.1 CONTEXTE D’ENTREPRISE.........................................................................................................................12 1.2 CONTEXTE DU DEVELOPPEMENT DE LOGICIELS........................................................................................13 1.3 CAHIER DES CHARGES..............................................................................................................................14
2. USINE À LOGICIELS ...................................................................................................................................15 2.1 FONCTIONNALITES DE CES OUTILS............................................................................................................16 2.2 M ICROSOFT V ISUAL STUDIO TEAM SYSTEM ............................................................................................17
2.2.1 Introduction à MVSTS ..................................................................................................................17 2.2.2 Fonctionnement de MVSTS ..........................................................................................................17 2.2.3 Les fonctions de MVSTS ...............................................................................................................19 2.2.4 Conclusions ..................................................................................................................................22
2.3 ALTERNATIVES.........................................................................................................................................23 2.4 CONCLUSIONS..........................................................................................................................................25
3. DÉFINITION D’UNE MÉTHODOLOGIE DE DÉVELOPPEMENT ..... .................................................27 3.1 INTRODUCTION.........................................................................................................................................28 3.2 ETAT DE L’ART DES METHODOLOGIES DE DEVELOPPEMENT.....................................................................29
3.2.1 Cycles de développement logiciel. ................................................................................................29 3.2.2 Constat actuel de l’état et des problématiques du développement logiciel ..................................35 3.2.3 Méthodologie de développement agile .........................................................................................36
3.3 M ISE EN EVIDENCE DES METHODOLOGIES UTILES A UNE PME .................................................................42 3.4 CHOIX D’UNE METHODOLOGIE.................................................................................................................43 3.5 QUELQUES METHODOLOGIES AGILES........................................................................................................46
3.5.1 Unified Process (UP) and Rational Unified Process (RUP) ........................................................48 3.5.2 Extreme Programming (XP).........................................................................................................52 3.5.3 Scrum............................................................................................................................................57 3.5.4 MSF Agile.....................................................................................................................................60
3.6 COMPARAISON DES METHODES VUES.......................................................................................................67 3.7 METHODOLOGIE DEFINIE POUR INFOTEAM...............................................................................................68
3.7.1 Introduction..................................................................................................................................68 3.7.2 Quelle méthodologie agile............................................................................................................69 3.7.3 Fonctionnement de base ...............................................................................................................69 3.7.4 Apports au fonctionnement de base..............................................................................................71 3.7.5 Conclusion....................................................................................................................................74
4. DEFINITION DE LA PROCEDURE DE TEST..........................................................................................75 4.1 INTRODUCTION.........................................................................................................................................76 4.2 ETAT DE L’ART DES PROCÉDURES DE TEST...............................................................................................78
4.2.1 Vérification versus validation.......................................................................................................79 4.2.2 Tests « boîte blanche » vs tests « boîte noire ».............................................................................80 4.2.3 Analyse statique vs analyse dynamique........................................................................................81 4.2.4 Les niveaux et types de tests logiciels...........................................................................................82 4.2.5 Cycle de test d’un développement logiciel....................................................................................85
4.3 PROCESSUS UTILES À UNE PME................................................................................................................88 4.3.1 Tester avant de développer...........................................................................................................88 4.3.2 Tester que si nécessaire................................................................................................................88 4.3.3 Pertinences des tests.....................................................................................................................88 4.3.4 Tests de non régression ................................................................................................................89
Table des matières
7 / 149
5. PROJET PILOTE...........................................................................................................................................91
5.1 INTRODUCTION.........................................................................................................................................92 5.2 DESCRIPTION DU PROJET..........................................................................................................................92 5.3 LES OBJECTIFS..........................................................................................................................................93 5.4 M ISE EN PLACE DE L’ENVIRONNEMENT DE DEVELOPPEMENT...................................................................94 5.5 M ISE EN PLACE DE LA METHODOLOGIE PROPOSEE....................................................................................95
5.5.1 Création de l’équipe.....................................................................................................................95 5.5.2 Cahier des charges.......................................................................................................................95 5.5.3 Nombre de Sprints ........................................................................................................................96 5.5.4 Phase de planification ..................................................................................................................96 5.5.5 Déroulement des Sprints...............................................................................................................97 5.5.6 Scrum Meeting............................................................................................................................105 5.5.7 Graphiques d’avancement..........................................................................................................105 5.5.8 Pratiques de développements .....................................................................................................106
5.6 APPLICATION FINALE .............................................................................................................................107 5.6.1 Accès au site ...............................................................................................................................107 5.6.2 Interface principale ....................................................................................................................108
5.7 RESULTATS.............................................................................................................................................111 5.7.1 Points positifs .............................................................................................................................111 5.7.2 Points négatifs ............................................................................................................................112
5.8 CONCLUSION..........................................................................................................................................113 6. CONCLUSIONS............................................................................................................................................115 REFERENCES ...................................................................................................................................................117
BIBLIOGRAPHIE...............................................................................................................................................118 WEBOGRAPHIE................................................................................................................................................118
A CAHIER DES CHARGES ...........................................................................................................................127 A.1 DESCRIPTION DU PROJET........................................................................................................................128 A.2 LES OBJECTIFS........................................................................................................................................128 A.3 ACTIVITES ..............................................................................................................................................129 A.4 PLANNING ..............................................................................................................................................131 A.5 ACCEPTATION DU CAHIER DES CHARGES................................................................................................132
B PLANNING FINAL ......................................................................................................................................134 C JOURNAL DE BORD...................................................................................................................................136 D NDA ................................................................................................................................................................141 E CD...................................................................................................................................................................141 F PAGE WEB ...................................................................................................................................................141
Table des figures
8 / 149
Table des figures
FIGURE 1 ARCHITECTURE DE M ICROSOFT V ISUAL STUDIO TEAM SYSTEM.............................................................18 FIGURE 2 VISION DE L'USINE A LOGICIELS DE BORLAND .........................................................................................24 FIGURE 3 MODELE EN CASCADE..............................................................................................................................30 FIGURE 4 MODELE EN V..........................................................................................................................................31 FIGURE 5 MODELE PAR INCREMENTS......................................................................................................................32 FIGURE 6 MODELE ITERATIF ...................................................................................................................................33 FIGURE 7 MODELE ITERATIF ...................................................................................................................................34 FIGURE 8 MODELE UTILISE EN PRATIQUE...............................................................................................................35 FIGURE 9 METHODOLOGIES AGILES VS METHODOLOGIES CLASSIQUES.................................................................37 FIGURE 10 ANALYSE DU COUT D'UN CHANGEMENT EN FONCTION DE SON MOMENT D'APPARITION.........................41 FIGURE 11 METHODOLOGIES AGILES EN FONCTION DE LA TAILLE DU PROJET TIREE DE [W73] ...............................46 FIGURE 12 METHODOLOGIES AGILES EN FONCTION DES CONTRAINTES TIREE DE [W73].........................................47 FIGURE 13 METHODOLOGIES AGILES EN FONCTION DES CONTRAINTES TIREE DE [W57].........................................47 FIGURE 14 UTILISATION DES METHODOLOGIES AGILES TIREE DE [W52] .................................................................48 FIGURE 15 HISTORIQUE DE RUP TIREE DE [W83] ...................................................................................................48 FIGURE 16 UTILISATION DES METHODOLOGIES AGILES...........................................................................................50 FIGURE 17 LES PRATIQUES D’XP TIREE DE [W91] ..................................................................................................52 FIGURE 18 ETAPES DU CYCLE DE DEVELOPPEMENT XP...........................................................................................54 FIGURE 19 INTERACTION ET APPRENTISSAGE EN XP ...............................................................................................55 FIGURE 20 FONCTIONNEMENT DE SCRUM ...............................................................................................................58 FIGURE 21 ETAT TRANSITION D’UN SENARIO MSF AGILE ......................................................................................61 FIGURE 22 ETAT TRANSITION D’UN IMPERATIF DE QUALITE MSF AGILE................................................................61 FIGURE 23 ETAT TRANSITION D’UNE TACHE MSF AGILE .......................................................................................62 FIGURE 24 ETAT TRANSITION D’UN BUG MSF AGILE.............................................................................................63 FIGURE 25 ETAT TRANSITION D’UN RISQUE MSF AGILE ........................................................................................63 FIGURE 26 RAPPORT D’AVANCEMENT QUANTITATIF MSF AGILE ..........................................................................64 FIGURE 27 RAPPORT D’AVANCEMENT QUALITATIF MSF AGILE.............................................................................64 FIGURE 28 FONCTIONNEMENT DE SCRUM [W104] ..................................................................................................69 FIGURE 29 COUT D'UN CHANGEMENT EN FONCTION DU TEMPS...............................................................................78 FIGURE 30 PROCESSUS DE VERIFICATION - VALIDATION ........................................................................................79 FIGURE 31 BOITE NOIRE VS BOITE BLANCHE...........................................................................................................80 FIGURE 32 EXEMPLE COUVERTURE DE CODE SOUS MICROSOFT V ISUAL STUDIO TEAM SYSTEM............................81 FIGURE 33 RESULTAT DE L'EXECUTION DES TESTS UNITAIRES................................................................................83 FIGURE 34 EXEMPLE DU PROFILER DE CODE SOUS M ICROSOFT V ISUAL STUDIO TEAM SYSTEM.............................84 FIGURE 35 CYCLE DE TEST......................................................................................................................................85 FIGURE 36 PLANIFICATION DES TESTS.....................................................................................................................86 FIGURE 37 TABLEAU DES TACHES...........................................................................................................................94 FIGURE 38 SPRINT 1 CUMULATIVE FLOW DIAGRAM ...............................................................................................97 FIGURE 39 SPRINT 1 BURDOWN CHART ..................................................................................................................98 FIGURE 40 MAQUETTE DE L’ INTERFACE GRAPHIQUE GENERALE.............................................................................98 FIGURE 41 SCHEMA DE LA BASE DE DONNEES.........................................................................................................99 FIGURE 42 SPRINT 2 CUMULTIVE FLOW DIAGRAM ...............................................................................................101 FIGURE 43 SPRINT 2 BURDOWN CHART ................................................................................................................101
Table des tableaux
9 / 149
FIGURE 44 SPRINT 3 BURDOWN CHART ................................................................................................................103 FIGURE 45 SPRINT 4 CUMULATIVE FLOW CHART..................................................................................................105 FIGURE 46 SPRINT 3 BURDOWN CHART ................................................................................................................105 FIGURE 47 PRODUCT BACKLOG BURDOWN CHART...............................................................................................106 FIGURE 48 SUIVISTREAMX : FENETRE DE LOGIN..................................................................................................107 FIGURE 49 SUIVISTREAMX : INFORMATION DE LOCALISATION D'UN POSTE..........................................................108 FIGURE 50 SUIVISTREAMX : INFORMATION SUR LES LOGICIELS INSTALLES..........................................................108 FIGURE 51 SUIVISTREAMX : INFORMATION SUR L’ INSTALLATION DU POSTE........................................................109 FIGURE 52 SUIVISTREAMX : SUPPRESSION D’UN POSTE........................................................................................109 FIGURE 53 SUIVISTREAMX : GESTION DES CLIENTS..............................................................................................110 FIGURE 54 SUIVISTREAMX : RECHERCHE PREDEFINIE MODULES STREAMX.........................................................110 FIGURE 55 L'ARBORESCENCE DU CD.....................................................................................................................141 FIGURE 56 SITE WEB DU PROJET............................................................................................................................141
Table des tableaux
TABLEAU 1 TAUX D 'ECHEC DES DEVELOPPEMENTS DE LOGICIELS...........................................................................13 TABLEAU 2 COMPARATIF BATIMENT ET LOGICIEL...................................................................................................42 TABLEAU 3 FAIRE LE CHOIX ENTRE LES MODELES ADAPTATIF ET PREDICTIF...........................................................43 TABLEAU 4 TYPES DE METHODOLOGIES ET EXEMPLES...........................................................................................45 TABLEAU 5 COMPARAISON AGILE VS CASCADE (WATERFALL) ...............................................................................45 TABLEAU 6 COMPARATIF DE XP, RUP, MSF AGILE ET SCRUM..............................................................................67 TABLEAU 7 EXEMPLE DE TEST UNITAIRE SOUS M ICROSOFT V ISUAL STUDIO TEAM SYSTEM ..................................83 TABLEAU 8 PRODUCT BACKLOG AFTER CLIENT ESTIMATION..................................................................................95 TABLEAU 9 PRODUCT BACKLOG ESTIME PAR L'EQUIPE...........................................................................................96 TABLEAU 10 PRODUCT BACKLOG DU SPRINT 1.......................................................................................................97 TABLEAU 11 AVANCEMENT DU SPRINT 1 (DU 2 JUILLET AU 6 JUILLET)...................................................................97 TABLEAU 12 SPRINT BACKLOG DU SPRINT 2.........................................................................................................100 TABLEAU 13 AVANCEMENT DU SPRINT 2 (DU 9 JUILLET AU 13 JUILLET)...............................................................100 TABLEAU 14 SPRINT BACKLOG DU SPRINT 3.........................................................................................................102 TABLEAU 15 AVANCEMENT DU SPRINT 3 (DU 16 JUILLET AU 20 JUILLET).............................................................103 TABLEAU 16 SPRINT BACKLOG DU SPRINT 4.........................................................................................................104 TABLEAU 17 AVANCEMENT DU SPRINT 4 (DU 23 JUILLET AU 27 JUILLET).............................................................104
Introduction
11 / 149
1. Introduction
“Poor management can increase software costs more rapidly than any other factor.”
Barry Boehm
Introduction
12 / 149
1.1 Contexte d’entreprise
Le contexte de ce travail de master est un peu particulier car il est réalisé d’entente entre
l’Université de Fribourg et la société informatique InfoTeam.
L’entreprise InfoTeam est basée à Villars-sur-Glâne dans le canton de Fribourg. Elle compte,
à l’heure actuelle, une vingtaine d’employés. Elle est active dans de nombreux domaines et
est divisée en quatre Teams:
Automatisation et Génie logicielle : Qui met en place des systèmes de supervision
et contrôle d’application industriel. Par exemple, la supervision de la
chaîne de production de l’usine d’incinération Saidef.
Web : Qui met en place des projets web techniques pour des communes, mais
aussi la mise en œuvre de plateformes web tel que le site de l’aéroport
de Genève.
Energie : Qui développe et maintient un système de contrôle de commande pour
poste de haute tension dans le domaine de la distribution énergétique.
IT : Qui s’occupe de toute l’informatique technique pour les PME.
Récemment, ils ont mis en place le réseau informatique et bureautique
des nouveaux bains de la Gruyère.
Cette société est principalement en contact avec des clients du monde industriel ou
institutionnel. Elle est reconnue pour ses compétences et son expérience dans le
développement, l’utilisation et la mise en place de solution Microsoft.
Ce contexte est très intéressant, car il me permet de me familiariser plus amplement avec le
monde professionnel. De plus, le sujet de mon travail de master ainsi que la collaboration avec
une entreprise me permettra d’avoir non seulement une vision théorique de ce domaine mais
aussi une vision pratique des solutions qui sont réellement mises en œuvre et utiles pour une
entreprise.
Ce contexte amène entre autre à la problématique de la confidentialité. En effet, certains
documents ([B7], [B8], [B9], [B10]) créés durant mon travail de master ainsi que leurs
annexes sont soumis aux conditions du NDA (cf. annexe D NDA). Ces documents contiennent
les informations supplémentaires listées ci-dessous:
i. Une description plus détaillée des fonctionnalités de MVSTS, de son utilisabilité par
une PME et des valeurs ajoutées/Pertes découlant de son utilisation.
ii. Une description détaillée du fonctionnement de la méthodologie, des conseils
d’utilisation ainsi que le descriptif des besoins qu’elle couvre.
Introduction
13 / 149
1.2 Contexte du développement de logiciels
Le développement de l’informatique s’accélérant de manière exponentielle, la complexité des
solutions techniques et logicielles ne cesse de croître. De part le fait de cette complexité, la
manière dont les solutions logicielles sont conçues évolue. Tout a commencé avec la méthode
« code and debug » pour aboutir à des méthodes intégrant plus de conception, de tests et
surtout d’adaptabilité aux changements. Cette évolution a été nécessaire non seulement pour
faire face à l’augmentation de la complexité mais aussi à la réduction du temps de
développement ainsi qu’à la demande croissante en matière de qualité.
Toutes ces problématiques auxquelles doivent faire face les entreprises, obligent celles-ci à
mettre en place des méthodes et principes de développement rigoureux pour minimiser le
risque d’échec. Ces méthodes et principes sont regroupés sous le terme Méthodologie de
développement logiciel.
Une des exigences principales du client vis-à-vis d’un développement logiciel, outre les
impératifs de prix et de temps de développement, est imputée à la qualité du logiciel
développé. Cette demande de qualité s’intensifiant, le meilleur moyen de garantir la qualité
d’un programme est de le tester ardemment à l’aide de processus de tests bien définis.
La mise en place de méthodologies et de processus de tests au sein d’une entreprise est un bon
procédé mais faut-il encore pouvoir permettre leurs exploitations à l’aide d’outils. Ces outils
permettant le développement de logiciels, la gestion de projet et le suivi de méthodologies et
de processus de tests sont connus sous le terme Usine à logiciels.
Aujourd’hui, la maîtrise des développements logiciels reste largement aléatoire selon les
différents rapports chaos du Standish Group [W54]. Le succès des projets informatiques se
résume ainsi :
Années Succès Mitigés Echec 1994 16% 53% 31% 2000 28% 49% 23% 2004 29% 53% 18%
Tableau 1 Taux d'échec des développements de logiciels
Un projet étant considéré comme Succès s’il est livré à temps, à l’intérieur du budget et des
spécifications originales. Il est considéré comme Mitigé s’il est livré et opérationnel, mais
qu’il contient moins de fonction que prévu et/ou qu’il dépasse les budgets et/ou les
échéanciers. Pour finir il est considéré comme Echec s’il est abandonné.
Introduction
14 / 149
Ce constat montre aux entreprises qu’il faut dans la mesure du possible limiter le risque
d’échec ou de résultat mitigé. Pour cela, la mise en place et le suivi de méthodologies de
développement et de processus de test est impérative. C’est en partant de cette constation que
ce travail de Master a vu le jour.
Ce travail de master consiste donc en l’étude de l’état de l’art des méthodologies de
développement logiciel et des processus de tests. Cela dans le but de déterminer une ou
plusieurs méthodologies et processus adaptés à l’entreprise InfoTeam. De plus, une étude des
outils existants permettant la mise en place de ces méthodologie/processus devra être réalisée
en mettant plus particulièrement l’accent sur la solution Microsoft Visual Studio Team System
[W9] (solution envisagée par InfoTeam).
1.3 Cahier des charges
Voici les objectifs finaux tels que décris plus spécifiquement dans le cahier des charges de ce
travail de Master (cf. annexe A Cahier des charges).
Ils peuvent être divisés en trois grandes parties :
• Evaluation du logiciel de Microsoft «Microsoft Visual Studio Team System »
o Déterminer son utilisabilité par une PME.
o Déterminer les valeurs ajoutées qui découleraient de l’utilisation de ce logiciel.
• Définition de deux processus de développement.
o Adaptés à la taille du projet (un processus pour les projets de petite taille et un pour ceux de plus grande envergure).
o Orientés qualité.
o Prenant en compte l’intégration constante du client.
o S’appuyant sur le fait que le début du projet peut se produire à un état d’avancement arbitraire.
o Basés sur des approches existantes.
• Définition d’une procédure de tests prenant en compte :
o Les approches existantes.
o La diversité des unités de l’entreprise et de ses champs d’activité.
o L’hétérogénéité des technologies et des produits utilisés au sein d’InfoTeam.
Usine à logiciels
15 / 149
2. Usine à logiciels
“How does a project get to be a year late? One day at a time.”
Frederick P. Brooks
Usine à logiciels
16 / 149
Commençons par une petite définition de l’usine logicielle tirée du site [W30] :
Usine à logiciels : Une usine logicielle peut être définie comme l'ensemble des outils mis en
oeuvre dans le cadre d'un développement logiciel, ainsi que les
démarches associées à l'utilisation de ces outils. Cela ne se limite pas à la
production du code source, mais à tous les éléments qui participent à la
bonne réalisation du projet (tests, documents, suivis, versions, ...).
Avec la complexité croissante du développement applicatif, la mise en place d’usines à
logiciels devient un impératif. En effet, un grand nombre de projets ne respectent pas les
délais, le budget, la spécification ou encore la qualité. Pour palier à ces problèmes, de grands
éditeurs tels qu’IBM, Microsoft ou Borland ont prévu de mettre en place des suites de
développement logiciel intégrant des outils de collaboration et de gestion de projet. Ces suites
de développement aussi appelées usine logicielle devrait permettre d’orchestrer le travail
d’équipe ainsi que la couverture de tout le cycle de vie d’un projet de l'analyse du besoin
jusqu’à la mise en production.
2.1 Fonctionnalités de ces outils
L’introduction des usines à logiciels cache une révolution du développement. En effet, elles
regroupent les fonctionnalités suivantes :
• La gestion de projet
• Le suivi de projet ainsi que la génération de rapports d’avancement
• L’usage des bonnes pratiques
• La mise en place de processus et méthodologies
• La modélisation d’architecture
• L’intégration continue
• Les tests dès la phase de conception
• Une collaboration accrue
• Une automatisation des tâches rébarbatives
• Un déploiement contrôlé.
Usine à logiciels
17 / 149
2.2 Microsoft Visual Studio Team System
Dans ce chapitre nous allons passer en revue la suite logicielle Microsoft Visual Studio Team
System (MVSTS dans la suite de ce document). Cette usine à logiciel a été étudiée plus en
profondeur car l’entreprise InfoTeam envisage son utilisation. Le document [B7] offre un plus
grand complément d’information sur ce produit.
2.2.1 Introduction à MVSTS
Pour la première fois, Microsoft crée une gamme d’outils de développement permettant de
gérer tout le cycle de vie d’un logiciel « Microsoft Visual Studio Team System ». MVSTS
découle de l’intégration de plusieurs composants de gestion de cycle de développement de
logiciels au sein de l’IDE Visual Studio. Cette gamme de produit est centrée sur les individus
et leurs rôles au sein du team de création de logiciels. Elle prend en charge la gestion des
sources, des tests, de l’architecture, du déploiement, le contrôle de la qualité ainsi que le suivi
de méthodologie. Microsoft a développé cet outil pour répondre aux besoins suivants :
• Améliorer la qualité
• Faciliter la collaboration entre les différents rôles
• Piloter le projet : connaître l’avancement du projet, être capable d’anticiper.
2.2.2 Fonctionnement de MVSTS
MVSTS est constitué de deux blocs : une partie cliente et la partie serveur « Team foundation
server » (TSF dans la suite de ce document).
La partie cliente est actuellement disponible en quatre éditions spécifiques aux différents rôles
des acteurs de l’équipe de développement (Software Architects, Software Developers,
Software Testers, Database Professionals). Il existe aussi une version cliente Team Suite qui
regroupe ces quatre éditions. Les parties clientes sont totalement intégrées dans l’IDE de
développement Visual Studio et proposent des outils destinés à chaque rôle.
La partie TFS héberge les aspects de cycle de vie, tels que le contrôle des versions, le suivi des
éléments de travail, Team Build, le portail d’équipe et le magasin de données qui contient les
documents relatifs aux projets.
Cette gamme de produit est donc basée sur le rôle des utilisateurs au sein du cycle de
développement d’un logiciel. Cela est clairement visible dans la Figure 1 tirée du site [W9]:
Usine à logiciels
18 / 149
Figure 1 Architecture de Microsoft Visual Studio Team System
Cette figure nous permet de voir les composants de MVSTS à savoir les quatre éditions
clientes (en haut) et le TFS (en bas). Chaque type d’édition contient des outils spécifiques au
rôle de l’utilisateur. Par exemple l’"Analyse dynamique de code" pour l’édition « for software
Developers ». Chaque type d’édition possède aussi des outils communs à toutes les éditions
comme le "Concepteur de classe" ou "Visual studio 2005 Professional".
La gestion de projet de MVSTS est basée sur un suivi des éléments de travail (work item)
représentant des tâches élémentaires. MVSTS fait l’hypothèse que chaque tâche présente dans
le processus de développement d’un logiciel peut et doit être exprimée en tant qu’élément de
travail. Contrairement à la gestion réalisée habituellement avec Excel ou de Project, où la
plupart du temps seule la création des tâches est effectuée, MVSTS permet le suivi de ces
tâches (qui fait quoi, quand et pourquoi). C’est ce qui permet au chef de projet de collecter des
données relatives au projet afin d’en générer des rapports d’avancement ou de qualité. Ces
rapports lui permettront d’informer le client de manière simple et compréhensible.
Usine à logiciels
19 / 149
2.2.3 Les fonctions de MVSTS
Ce chapitre donne une brève description des fonctionnalités offertes MVSTS. Plus de détails
sur le fonctionnement de chaque option sont fournis dans le document [B7] selon les
conditions du NDA (cf. annexe D NDA).
2.2.3.1 Partie Cliente
Concepteur d’application (Application Designer)
Ce type de diagramme est très similaire à la notion de diagramme de composant d’UML.
Le concepteur d’application permet de visualiser :
• Les applications, les services et les bases de données utilisées.
• Les points (interfaces) par lesquels ces applications communiquent.
• Les connexions entre les points de communication qui mettent en évidence les
interdépendances entre ces applications.
Il offre aussi la possibilité de générer du code et de mettre à jour automatiquement les
modifications effectuées dans le code ou dans le concepteur.
Concepteur d’infrastructure (Logical Datacenter Designer)
Ce concepteur permet de modéliser une infrastructure logique de déploiement en incluant les
réseaux (zones), les serveurs logiques, les protocoles de communication et les contraintes de
sécurité.
Concepteur de déploiement (Deployment Designer & System Designer)
Il permet de regrouper les parties définies sur des diagrammes d’application en unités de
déploiement (System diagram). Puis le concepteur de déploiement permet d’évaluer le
déploiement de ces unités au sein d’une infrastructure (logical Datacenter Design).
Analyse statique du code
Cet outil permet d’analyser le code à la compilation pour assurer le respect des conventions de
codage : règles de nommage, règles d’architecture, failles de sécurité potentielles.
Analyse dynamique du code et Profiler de code
Cet outil permet aux développeurs de mesurer, d’évaluer et de cibler les problèmes de
performance de leur code.
Usine à logiciels
20 / 149
Test web et test fonctionnel
Permet d’enregistrer une session d’activités réalisées sur une page web (série de requêtes
http). Après création, il est possible de modifier ces tests (par exemple de les piloter par les
données) ou alors de les assembler dans des tests de charge.
Test de montée en charge
Ces tests sont composés d’une série de tests web ou de tests unitaires pour simuler une
utilisation en production.
Test manuel
Ce type de test permet de définir les étapes qu’un être humain doit suivre pour réaliser un test
qui ne peut pas être automatisé.
Test générique
Ce type de test permet d’encapsuler un test (programme ou outil tiers) qui peut être exécuté en
ligne de commande et qui retourne une valeur réussite ou échec.
Test ordonné
Permet de regrouper et de séquencer un certain nombre d’autres tests au sein d’un test
ordonné.
Tests unitaires
Cette fonction est disponible pour les éditions Developers, Testers et Database Professionals.
Cette fonction permet de générer des tests unitaires (basés sur les assertions) qui invoquent des
méthodes et vérifient leurs valeurs de retour. Peut être appliqué à des classes mais aussi à des
pages web ou encore à des procédures stockées.
Couverture de code
Cet outil permet donc de distinguer rapidement les lignes de code qui ont été parcourues au
moins une fois pendant les tests de celles qui n’ont jamais été balayées.
Gestion des campagnes de test
Organise les tests pour déterminer lesquels sont exécutés dans quel ordre et à quel moment.
Usine à logiciels
21 / 149
Comparaison de schémas et de données
Permet la comparaison entre les différentes versions des schémas de développement et de
production. Permet de générer les scripts T-SQL pour appliquer les différences.
Gestion des déploiements
Lorsqu’une version de développement stable est finalisée, on peut générer les scripts de
déploiement/mise à jour ou déployer directement la base en sélectionnant le serveur cible
(souvent en local pendant le développement).
Génération de jeux d’essais
Permet de populer les tables de la base de données en respectant la structure et les types de
données, ainsi que la répartition de la volumétrie. Cette génération peut se faire à l’aide de
séquences, d’expressions régulières, de binding.
Concepteur de classes
Le concepteur de classe permet de visualiser sous forme graphique le code à la manière des
diagrammes de classe UML. Ces diagrammes permettent la génération du code et sont en
permanence synchronisés avec le code.
2.2.3.2 Partie serveur
Modèles de projet (MSF Agile et CMMI)
MSF Agile et CMMI sont des modèles de projet fournissant des exemples de méthodologies
utilisables depuis MVSTS.
Gestion de configuration et de version
Le contrôle des sources est effectué avec Team Foundation Version Control (TFS-VC). TFS-
VC stocke toutes les modifications (diagramme, fichiers de configuration, source,
documentation, ..) dans une base de données SQL Server 2005 et non pas seulement le code
source.
Gestion du changement
L’objectif de cette partie est de permettre le suivi de l’état du projet. MVSTS utilise des work
items (tâche élémentaire) pour gérer le travail devant être effectué au cours du cycle de vie
d’un produit (cf. 2.2.2 Fonctionnement de MVSTS). Ces work items permettent de réaliser
des listes représentant le "reste à faire". Il est possible d’associer ces work items à des actions
sur le code (check-in, correction d’un bug, découverte d’un problème d’intégration,…), sur les
Usine à logiciels
22 / 149
builds et les tests. Ce qui permet la traçabilité du processus de développement et la génération
de rapports répondant à la question “qui a fait quoi et pourquoi”.
Serveur d’intégration (Build)
Team Foundation Build permet à l'équipe de créer et de gérer régulièrement des builds de
produit.
Rapports d’avancement
Les rapports permettent de suivre l’avancement qualitatif et quantitatif du projet au travers
d’indicateurs (bugs actifs ou corrigés, évolution du nombre de tests unitaires, évolution du
taux de couverture et de réussite des tests, temps moyen de résolution d’un bug, …).
Portail projet
Chaque projet d’équipe est associé à un portail de projet de type SharePoint Services. Il
permet le partage de documents et d’informations (agendas, discussions, actualités) entre les
membres de l’équipe projet.
Gestion de projet
Les éléments de travail son stockés dans une base de donnée sur TFS. Toutefois, pour faciliter
la gestion de projet, il est possible de les importer dans Project ou Excel.
2.2.4 Conclusions
Dans MVSTS, Microsoft intègre à son IDE de développement Visual Studio un ensemble de
fonctionnalités très intéressantes.
L’évolution du développement logiciel va clairement en direction des usines à logiciels
lesquelles représentent l'ensemble des outils mis en œuvre dans le cadre d'un développement
logiciel. Cela ne se limite pas à la production du code source, mais à tous les éléments qui
participent à la bonne réalisation du projet (tests, documents, suivis, versions, ...).
De grandes entreprises comme IBM, Microsoft ou Borland ont compris cet état de fait et sont
en train de mettre en place des solutions dans ce domaine.
Le monde open source s’intéresse aussi à ce domaine. Mais la mise en place de tels systèmes
étant très complexe, il va être difficile de rivaliser avec des solutions proposées par IBM,
Microsoft ou Borland qui n’ont clairement pas les mêmes moyens. A l’heure actuelle, le
monde open source offre ses fonctionnalités mais à l’aide de différents produits qui ne sont
pas tous intégrés dans une usine à logiciels. Ce qui pose certains problèmes comme la
Usine à logiciels
23 / 149
sélection/intégration de différents outils ou encore la centralisation des données et des
métriques du projet.
L’avantage principal de MVSTS est l’intégration de tous les outils nécessaires au
développement logiciel dans Visual Studio. Ce qui en fait, dans le cadre d’un développement
.net, la plateforme de référence. De plus, l’ouverture de TFS permet l’utilisation de ces outils
de gestion de projet avec d’autres plateformes de développement. Il est par exemple
intéressant pour une entreprise de pouvoir se diversifier tout en travaillant de la même manière
sur toutes les technologies.
En ce qui concerne la problématique du prix, il est à déterminer si les avantages découlant de
l’utilisation de MVSTS (temps de développement réduit, qualité améliorée, …) peuvent
combler ce problème. Dans tous les cas, Microsoft offre une version d’évaluation valable six
mois. Cela peut être une bonne solution pour mettre en place et tester MVSTS.
Enfin, s’il faut retenir quelque chose sur MVSTS ce serait l’amélioration qu’il peut apporter
dans les domaines suivants :
• Qualité logicielle (tests, analyse de code, profiler, intégration continue)
• Collaboration (work item, portail)
• Pilotage des projets (work item, rapport, project excel)
2.3 Alternatives
2.3.1 Jazz Eclipse
Le projet Jazz initié par Rational et IBM tend à être le future de l’IDE d’Eclipse. En effet, Jazz
vise à étendre l’IDE d’Eclipse à une plateforme de collaboration. Cette plateforme de
collaboration serait en faite une Usine à logiciels comme décrite au début du chapitre 2 Usine
à logiciels. Elle est très similaire à MVSTS, elle est composée d’une partie serveur et d’une
partie cliente, elle intègre un gestionnaire des sources, la création de rapports,… Elle est basée
sur des méthodologies agiles.
Elle est désignée pour être utilisable depuis un autre IDE que’Eclipse comme par exemple
Visual Studio. Mais, actuellement, elle est en cours de développement et sa sortie ne sera
sûrement pas annoncée avant 2008 [W3].
Usine à logiciels
24 / 149
2.3.2 TeamCity
TeamCity est indépendant de L’IDE et peut aussi bien fonctionner sur IntelliJ (JAVA) que sur
Visual Studio2005 (.NET). TeamCity est cependant moins abouti que MVSTS est s’avère être
plus un moteur d’intégration continue qu’une réelle usine à logiciels. En effet, il n’intègre pas
les options suivantes : suivi de méthodologies, rapport d’avancement, diagrammes de
conception, analyse du code, plusieurs types de tests et gestion du changement (workitem). De
plus, presque toutes les fonctions sont limitées vis-à-vis de MVSTS à l’exception du principe
de Build. Son principal avantage reste le prix et l’utilisabilité aussi bien depuis java que .net.
2.3.3 Borland
Borland se lance aussi dans la vision d’usine à logiciels. Mais sa vision de l’usine à logiciels
est constituée de rassemblements de plusieurs produits et de la tentative de les faire collaborer
par un certain nombre d’engrenages visibles dans la Figure 2 tirée du site [W8].
Figure 2 Vision de l'usine à logiciels de Borland
Cette vision intègre les produits suivants :
Borland Tempo (Plan), Borland Caliber DefineIT (Define), Borland CaliberRM (Define),
Borland Together Technologies (Design, Develop/Configure), Borland Gauntlet (Test),
Borland SilkCentral Test Manager (Test), Borland SilkTest (Test), Borland SilkPerformer
(Test), Borland StarTeam (Manage).
Malgré l’intégration de plusieurs produits pouvant amener aux mêmes résultats que MVSTS,
la suite de Borland n’est pas une alternative directe car elle est spécifique au monde java.
Usine à logiciels
25 / 149
2.3.4 IBM
Tout comme Borland, IBM offre une suite de produits permettant de gérer tous le cycle de
développement logiciel. Cette suite de produits est identifiée sous la gamme rational qui vient
se greffer sur la plate-forme "Open-source" Eclipse. Mais la vision future d’IBM semble
tournée vers Jazz.
2.4 Conclusions
Vu la tournure que prend actuellement le développement logiciel ainsi que les apports qui
découlent de l’utilisation d’un tel produit, les PME vont se tourner vers des usines à logiciel.
Et en termes d’usine à logiciels, MVSTS est actuellement la plus performante si ce n’est la
seule pour le monde .NET. Les autres systèmes disponibles ne couvrent pas tous les besoins et
les outils isolés communiquent mal entre eux.
Personnellement, je conseillerais l’utilisation de MVSTS ou tout du moins la prise en compte
et le test de cette usine par une PME. La seule problématique autre que le prix devrait venir de
l’acceptation de ce produit par les utilisateurs (développeurs). En effet, il est toujours difficile
de changer ses habitudes, même si le produit proposé est plus intéressant que les produits
utilisés actuellement, le changement est toujours problématique. Mais je le rappelle, à terme se
changement risque d’être inéluctable. Donc, à mon sens, il est préférable d’anticiper et prendre
les devants.
Définition d’une méthodologie de développement
27 / 149
3. Définition d’une
méthodologie de
développement
“Agile methods derive much of their agility by relying on the tacit knowledge embodied in
the team, rather than writing the knowleadge down in plans.”
Kent Beck
Définition d’une méthodologie de développement
28 / 149
3.1 Introduction
Tout d’abord commençons par une petite définition [B5]:
MÉTHODOLOGIE n. f. XIXe siècle. Composé à l'aide de méthode et de -logie, tiré du
grec logos, « discours, traité ». Étude des méthodes de recherche et
d'analyse propres à une science, à une discipline.
Dans le cas plus concret du développement logiciel, les méthodologies sont une sous partie du
génie logiciel qui vise à rassembler l’ensemble des méthodes, des techniques et des outils
servant à la production d’un logiciel.
Une méthodologie de développement logiciel doit tenir compte de la création du logiciel à
proprement parler mais aussi de tous les composants relatifs au cycle de vie d’un logiciel. Le
cycle de vie d’un logiciel commence à la définition des objectifs et dure jusqu’à la fin de son
exploitation. De part ce fait, les méthodologies de développement logiciel et la gestion du
cycle de vie du développement logiciel sont deux notions très liées si ce n’est équivalentes.
Les méthodologies de développement logiciel peuvent donc être vues comme l’assemblage de
techniques et de méthodes permettant la gestion de toutes les phases du cycle de
développement logiciel.
Une méthodologie de développement logiciel doit être couplée à un outil permettant son suivi.
En effet, certains outils de développement supportent des méthodologies mais ces deux
notions forment un tout. L’utilisation d’un outil ne garantit pas le suivi d’une méthodologie
mais l’outil peut rendre possible ce suivi.
Enfin, une méthodologie doit regrouper un certain nombre de bonnes pratiques du
développement logiciel qui ont été éprouvées. Cela peut aller de pratiques sur la gestion de
projet (planification) ou l’organisation des équipes de développement (pair programming),
mais aussi les motifs de conception (design patterns) pour la modélisation du code.
La notion de méthodologie de développement logiciel devient omniprésente dans un domaine
où seulement un tiers des projets peuvent être considérés comme des succès [W54]. Un projet
est réussi s’il est en adéquation avec les trois concepts suivants ; il est livré à temps, à
l’intérieur du budget et des spécifications originales tout en correspondant aux besoins du
client.
Les méthodologies sont donc une alternative au développement dit « chaotique » où la
caractéristique principale est «coder et deboguer ». Elles imposent un processus discipliné
permettant de rendre le développement logiciel plus prévisible et plus efficace.
Définition d’une méthodologie de développement
29 / 149
3.2 Etat de l’art des méthodologies de développemen t
En guise d’introduction à l’état de l’art des méthodologies de développement logiciel, il est
nécessaire de les distinguer de la modélisation logicielle. En effet, on fait souvent l’erreur de
penser que la méthodologie se résume à la modélisation, ce qui est totalement erroné. En ce
qui concerne la modélisation, l’état de l’art s’appuie sur le modèle objet et le standard
incontournable qu’est UML. Les méthodologies quant à elles couvrent bien évidemment la
modélisation mais aussi tout le cycle de développement de logiciel. C’est pour cette raison que
nous allons commencer l’état de l’art par un aperçu des types de cycles existants.
3.2.1 Cycles de développement logiciel.
Le cycle de développement d’un logiciel ne se résume pas à la seule phase de codage mais
peut être considéré comme toute la période partant de la définition des besoins et allant
jusqu’à l’arrêt de l’exploitation du logiciel. Mais dans tous les cas de figure, certaines phases
sont inévitables :
1. Expression des besoins : Description informelle des besoins exprimés par l’utilisateur.
Cela permet de définir le cahier des charges.
2. Spécification : Description formelle du problème par l’équipe de développement.
Cela permet de définir le quoi en fonction du cahier des charges.
3. Analyse et conception : Recherche de solutions tenant compte de l’architecture technique.
Cela permet de définir le comment. La conception est souvent
découpée en deux phases : la conception générale et la conception
détaillée. La conception détaillée représente la conception du
système global, composant par composant.
4. Développement : Production du code en se référant à l’analyse et la conception
mais sans avoir besoin de remettre ceux-ci en question. Permet
aussi la mise en place des tests unitaires (cf. 4.2.4.1).
5. Test/recette Validation par le client des fonctionnalités du système.
6. Déploiement/maintenance.
Souvent certaines de ces activités sont regroupées, mais elles sont toujours présentes et se
déroulent presque toujours dans l’ordre précité. L’ordre est souvent respecté mais cela
n’empêche pas d’organiser le déroulement de ces phases de nombreuses manières. Les deux
grandes familles d’organisation sont les cycles séquentiels et les cycles itératifs. Ces cycles
seront détaillés dans les chapitres suivants.
Il est intéressant de noter que selon certains chiffres la phase de conception devrait représenter
35% de l’effort total de développement, la phase de test 30%, tandis que la phase de
Définition d’une méthodologie de développement
30 / 149
développement pourrait être réduite à 20%. Bien évidement ces données sont très variables en
fonction des projets et des processus de développement mis en place. Mais elles illustrent que
la phase de développement (codage) n’est pas forcément la phase la plus gourmande en effort
de travail.
3.2.1.1 Modèle en cascade (séquentiel)
C’est l’un des premiers modèles apparu en 1966 et formalisé aux alentours de 1970 par W.
Royce. Il est issu de la construction du bâtiment où les fondations sont construites avant les
reste de la maison. Les activités y sont exécutées les unes après les autres de manière
totalement successive. Dans sa version de base ce modèle était basé sur le principe de non-
retour (il n’y a donc pas de remise en cause d’une phase précédente). Dans la version actuelle,
la fin de chaque phase a lieu à une date prédéterminée et s’achève par la production d’un
certain nombre de documents ou logiciels. Ces livrables sont produits pour réaliser la
Vérification/Validation (cf. 4.2.1 Vérification versus validation) qui permet d’approuver le
passage à la phase suivante ou la correction de l’étape précédente. Il est très bien adapté aux
petits projets simples avec peu d’incertitude et où les besoins sont clairement identifiés et
stables.
Figure 3 Modèle en cascade
Avantages : • Modèle simple
• Tests entre chaque phase
• Gestion des phases en temps et ressources
• Définition des tâches et des livrables
Inconvénients : • Effet tunnel (identification tardive des problèmes, preuve tardive du
bon fonctionnement).
• Difficulté de cerner les besoins dès le début, refus de tout changement.
• Frustration de l’attente de la première version (lenteur).
• Les projets informatiques sont rarement séquentiels.
Définition d’une méthodologie de développement
31 / 149
3.2.1.2 Modèle en V (séquentiel)
Mc Dermid et Ripkin proposèrent ce modèle en 1984. Il découle d’une amélioration du
modèle en cascade où chaque phase du projet a une phase de test qui lui est associée. Cette
association découle de l’idée que chaque phase en amont du développement doit préparer une
phase correspondante de vérification en aval de la production du logiciel. Par exemple, la
description d’un composant est accompagnée des tests qui permettront de s’assurer qu’il
correspond à sa description. Il a été mis en place pour améliorer le problème lié au manque de
réactivité du modèle en cascade (on ne s’aperçoit que lors de la phase de test que cette
propriété ne peut pas être vérifiée objectivement). Elle est basée sur les deux approches (Top-
Down et Bottom-Up). Dans les premières phases descendantes, on décompose le projet pour
faciliter la partie développement (Top-Down). Tandis que dans les secondes phases, on
recompose l’ensemble du logiciel en le testant du détail vers l’ensemble (Bottom-Up).
Figure 4 Modèle en V
Avantages : • Réactivité accrue vis-à-vis du modèle en cascade (évite d’énoncer une
propriété non vérifiable objectivement une fois le logiciel réalisé)
• Modèle industriel classique éprouvé
• Validation systématique de chaque étape avec retour en arrière possible
• La mise en place de la vérification lors de la conception oblige à une
réflexion supplémentaire très utile.
Inconvénients : • Pas de prototypage (code/validation tardive) � risque d’effet tunnel
• Prise en compte des modifications du cahier des charges difficile
• Obligation de définir la totalité des besoins au départ
• Projet rarement séquentiel
Définition d’une méthodologie de développement
32 / 149
3.2.1.3 Modèle par incréments
Le principe de base du modèle par incréments est de découper l’expression des besoins en
sous-parties (lots ou incréments). Chaque lot sera réalisé successivement ou en se chevauchant
selon un modèle en cascade ou en V.
Figure 5 Modèle par incréments
Avantages : • Diminution de la durée d’un cycle et donc de l’effet tunnel
• Diminution de la complexité (vision uniquement d’un incrément)
• Les intégrations sont progressives.
Inconvénients : • Difficulté de l’intégration
• Difficulté de la conception globale
• Inadapté aux besoins d’évolution en cours de projet, problème en cas
de remise en cause du noyau.
Définition d’une méthodologie de développement
33 / 149
3.2.1.4 Modèle en spirale (itératif)
Ce modèle a été proposé par Barry W. Boehm en 1988. Il reprend les différentes étapes du
cycle en V. Il est basé sur des itérations. Par l'implémentation de versions successives (une
version par cycle), le cycle recommence en proposant un produit de plus en plus complet.
Chaque nouvelle phase permet d’ajuster ce qui a déjà été réalisé durant le cycle précédent et
d’ajouter de nouvelles fonctionnalités. Il est grandement basé sur une analyse des risques
pouvant à tout moment remettre en cause le développement.
Figure 6 Modèle Itératif
Avantages : • Retour plus tôt sur l’avancée du projet donc meilleure estimation des
budgets
• Gestion du changement (les besoins sont affinés à chaque cycle)
• Mise en œuvre d’une analyse des risques.
Inconvénient : • Les cycles peuvent être indépendants les uns des autres ce qui peut
provoquer un big-bang lors de l’intégration.
Définition d’une méthodologie de développement
34 / 149
3.2.1.5 Modèle itératifs
Le principe de base du modèle itératif est assez simple, à chaque nouveau besoin un cycle de
type « roue de Deming [W55]» est appliqué. La roue de Deming représente le principe
« Plan Do Check Ack » (PDCA). Ce cycle est effectué de manière itérative où à chaque
itération (mini-cascade) sont présents : l’étude de la faisabilité, l’élaboration, la fabrication et
la livraison. L’idée principale étant de pouvoir livrer au plus tôt une version qui puisse être
testée par le client. Donc les itérations se doivent d’être les plus courtes possibles. Puis à
chaque nouvelle itération les nouveaux besoins sont examinés et les erreurs de l’itération
précédente sont corrigées. Cela signifie que la version livrée au client n’est pas une version
finale et qu’il peut manquer beaucoup de fonctionnalités mais il a au moins la possibilité de
vérifier et de valider rapidement.
Figure 7 Modèle Itératif
Avantages : • Adaptation au changement (retour plus rapide)
• Prototype (plus simple de voir que de lire de la documentation)
• Plus forte intégration du client (meilleure expression des besoins)
• Motivation de l’équipe par des objectifs proches
Inconvénient : • Difficulté de traiter les gros projets � possibilité d’erreur dans la
conception et refactoring difficile
Définition d’une méthodologie de développement
35 / 149
3.2.1.6 Evolution
La description des différents types de cycles de développement logiciel qui a été réalisée dans
les parties précédentes suit l’évolution de ces cycles. En effet, tout au début il n’y avait pas
vraiment de cycle de développement logiciel, la méthode « code and debug » était utilisée.
Puis on s’est rendu compte que cette méthode n’était pas adaptée à l’évolution des projets
informatiques. Les projets devenant de plus en plus grands, un certain nombre de phases ont
été mis en évidence (cf. 3.2.1 Cycles de développement logiciel.). Puis le premier type de
cycle de développement (cf. 3.2.1.1 Modèle en cascade (séquentiel)) a été déterminé. Cela
fut une vraie amélioration de la gestion de projets informatiques toutefois ce modèle était
limité car il produisait un grand effet tunnel. Afin de minimiser ce problème le modèle en V a
été développé, mais ce modèle, tout comme son prédécesseur, ne fournissait une version à
valider que tardivement. Le modèle par incrément a donc été mis en place. Mais une grande
problématique du développement logiciel est l’évolution constante des besoins des
utilisateurs. Comme cette problématique du changement n’étant pas prise en compte dans le
modèle par incrément, le modèle en spirale a été pensé. Le cycle du modèle de spirale étant
indépendant, un problème d’effet big-bang subsistait durant l’intégration. Le modèle itératif,
qui consiste à la mise en place successive d’une version de l’application à laquelle de
nouvelles fonctionnalités sont ajoutées durant les itérations suivantes, a donc été mis en place.
La prise en compte de l’évolution incessante des besoins dans le développement informatique
aboutit, à l’heure actuelle, à un développement itératif reflétant l’état de l’art.
3.2.2 Constat actuel de l’état et des problématique s du
développement logiciel
Ces différents cycles de développement logiciel sont purement théoriques. Dans la pratique, la
situation la plus fréquente est la suivante :
Figure 8 Modèle utilisé en pratique
La plupart du temps il n’y a aucune distinction entre l’expression des besoins et les
spécifications. De plus, la conception est souvent réalisée par les développeurs en même
temps que le développement.
Une autre variable du constat actuel vient du fait que les clients ont de grandes difficultés à
exprimer leurs besoins sous une forme exploitable par les équipes de développement. Dans
Définition d’une méthodologie de développement
36 / 149
les premiers modèles de cycle de vie tout comme dans le modèle utilisé en pratique, la plupart
des décisions (expression des besoins, mise en place de la spécification, conception) sont
concentrées en début de projet dans le but de donner des garanties aux clients sur ce qu’ils
obtiendront. Cette démarche part d’une bonne intention mais elle ne tient pas compte du fait
que les besoins des utilisateurs changent et que leurs stratégies évoluent. Cela implique qu’une
bonne méthodologie de développement logiciel doit être réactive aux besoins changeants du
client. A l’inverse, il ne faut pas tomber dans un chaos du changement permanent, mais il
faudra donc nécessairement adapter la granularité des changements.
Enfin, les méthodologies de développement logiciel dites classiques (cycle en cascade, V,…)
sont grandement basées sur des livrables (documentation) qui sont fournis entre chaque étape
du cycle afin de permettre un meilleur suivi du projet. Cela les rend peu populaires car très
bureaucratiques. En effet, le surplus de travail à effectuer pour suivre la méthodologie ne fait
que ralentir le développement. De plus, dans la pratique tous ces documents ne sont que très
rarement lus et quasiment jamais mis à jour. Ce qui remet en question leurs intérêt.
3.2.3 Méthodologie de développement agile
Ce type de méthodologie constitue l’état de l’art actuel des méthodologies de développement
logiciel. Cela signifie qu’elle représente ce qui se fait de mieux en matière de développement
logiciel, toutefois cela ne signifie pas qu’elles sont les méthodologies les plus utilisées. Elles
ont vu le jour suite aux problèmes posés dans le constat actuel. Ces méthodes sont issues d’un
mélange entre le modèle en incrément et le modèle itératif visant à réduire le cycle de
développement logiciel (donc à accélérer le développement). Elles sont très bien adaptées à la
problématique d’avancement d’un projet pour lequel les spécifications ne sont pas stables
grâce à leur implication constante du client. De plus, elles sont très pragmatiques et visent la
réelle satisfaction du client et non pas celle d’un contrat établi préalablement. Pour y parvenir,
elles nécessitent d'impliquer d'avantage le client et d'être à son écoute afin d'être le plus proche
possible de ses demandes. Elles se distinguent des méthodes classiques sur plusieurs niveaux
qui sont exprimés dans la Figure 9 tirée du site [W80].
Définition d’une méthodologie de développement
37 / 149
Figure 9 Méthodologies Agiles VS Méthodologies Classiques
La notion de méthode agile est née à travers un manifeste [W68] signé par dix-sept
personnalités (parmi lesquelles Ward Cunningham, l'inventeur du Wiki), créateurs de
méthodes ou dirigeants de sociétés.
3.2.3.1 Les valeurs des méthodologies agiles
Les méthodologies agiles prônent quatre valeurs fondamentales :
• Communication : Personnes et interactions plutôt que procédures et outils.
La gestion de projet a longtemps établi la « méthode/procédure » comme le vecteur
essentiel de succès d’un projet. Alors que dans les faits, la meilleure garantie de
succès sont les personnes. Même une bonne méthode ne sauvera pas un projet de
l’échec si l’équipe n’est pas constituée de personnes adéquates et impliquées dans le
projet. Il est préférable d’avoir une équipe soudée de développeurs moyens qui
communiquent et collaborent plutôt qu’une équipe composée d’individualistes même
brillants.
Définition d’une méthodologie de développement
38 / 149
• Simplicité : Applications fonctionnelles plutôt que documentation complète.
Il est vital d’avoir une application finale fonctionnelle (c’est finalement le but du
client). Le reste (documentation,…) est secondaire, bien qu’une documentation
succincte et précise est utile comme moyen de communication. De plus, l’écriture et la
mise à jour de documents sont extrêmement consommatrices de ressources. Un
document qui n’est pas mis régulièrement à jour peut devenir inutile ou même
trompeur. Il est préférable de bien commenter le code qui est l’élément clé de la
documentation. Il est aussi plus simple de demander un feedback à un client sur un
produit fonctionnel que sur une documentation. Par ailleurs, il faut toujours
développer la façon la plus simple car la plus compliquée ne sera sûrement pas
utilisée.
• Feedback : Collaboration avec le client plutôt que négociation de contrat.
Les changements sont inévitables au sein d’un projet informatique. De part ce fait, il
est utopique de penser que les exigences, le planning et le coût peuvent être spécifiés à
l’avance et qu’ils ne changeront pas. En partant de ce principe, la manière la plus juste
de répondre effectivement aux besoins du client est de travailler en étroite
collaboration avec celui-ci. Cela permet de répondre directement aux changements de
besoins du client et donc d’obtenir sa satisfaction. Cela reste néanmoins difficile à
mettre en œuvre car cela implique une grande confiance réciproque.
• Courage : Acceptation du changement plutôt que suivi d’un plan.
La qualité d’un projet pour le client est souvent étroitement liée à la capacité
d’adaptation de l’équipe de développement aux exigences de celui-ci. Ses exigences
vont certainement changer en cours de projet et il est indispensable d’avoir un
planning flexible et adaptable à ces changements. Cette problématique demande au
client le courage de donner des priorités à ses besoins et d’accepter que certains
besoins ne soient finalement pas très clairs. Elle demande au responsable le courage
d’entamer un projet avant que tout ne soit clairement précisé dans un document.
Définition d’une méthodologie de développement
39 / 149
Ces quatre valeurs fondamentales de l’agilité sont déclinées en douze principes généraux
communs à toutes les méthodes agiles :
1. « Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des
logiciels utiles ».
Les méthodes agiles recommandent de livrer très tôt une version rudimentaire puis de
livrer souvent des versions auxquelles s’ajoute les fonctionnalités progressivement. Cela
permet un feedback rapide du client et donc une prise en compte immédiate du
changement de ses exigences. Ainsi qu’un bon suivi des risques.
2. « Le changement est bienvenu, même tardivement dans le développement. Les processus
agiles exploitent le changement comme avantage compétitif pour le client ».
Les changements d’exigences doivent être pris comme une bonne chose car ils signifient
que l’équipe a compris et appris comment satisfaire le client encore mieux. Les systèmes
développés avec des méthodologies agiles se veulent flexibles et évolutifs car ils doivent
minimiser l’impact d’un changement.
3. « Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux
mois, avec une tendance pour la période la plus courte ».
Contrairement à la livraison de document décrivant l’application, la livraison la plus
fréquemment possible d’une application fonctionnelle offre au client une meilleure vision
du produit et un feedback plus rapide.
4. « Le client et les développeurs doivent collaborer quotidiennement au projet ».
L’interaction entre le client et les développeurs doit être permanente pour guider
continuellement le projet.
5. « Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le
soutien dont elles ont besoin, et croyez en leurs capacités à faire le travail ».
Avec les méthodologies agiles, les personnes sont le facteur clé de la réussite d’un projet.
Tout le reste, processus, environnement, technologie peuvent être changés s’ils entravent
le bon fonctionnement de l’équipe.
6. « La méthode la plus efficace de transmettre l'information est une conversation en face à
face ».
Les méthodologies agiles partent du principe que la meilleure manière de communiquer
n’est pas la production de documents pour tout ce qui est dit (cela étant impossible), mais
belle et bien une discussion ouverte entre les membres de l’équipe.
Définition d’une méthodologie de développement
40 / 149
7. « Un logiciel fonctionnel est la meilleure unité de mesure de progression d’un projet ».
Le client n’a finalement que faire de savoir dans quelle phase du projet se trouve l’équipe,
quels documents ont été réalisés… Le client veut un produit fini qui répond aux exigences
qu’il a fixées. Le meilleur moyen pour mesurer cette progression est tout simplement de
voir effectivement quel pourcentage des fonctionnalités sont implémentées.
8. « Les processus agiles incitent à un rythme de développement soutenable. Sponsors,
développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment ».
Les méthodologies agiles veulent supprimer le stress post déploiement. Pour qu’un
développement soit de bonne qualité, il faut qu’il le soit tout le temps. Il est donc logique
de penser que le travail ne peut se faire en sprints successifs mais plutôt en une course
régulière comme dans un marathon.
9. « Porter une attention continue à l'excellence technique et à la qualité de la conception
améliore l'agilité ».
Le code source de l’application doit toujours rester propre pour améliorer la rapidité et la
qualité du développement. Les membres de l’équipe doivent donc porter une attention
continue à la qualité et la clarté du code qu’ils produisent en effectuant de la
refactorisation (refactoring).
10. « La simplicité "l'art de maximiser la quantité de travail à ne pas faire" est essentielle».
Comme le disait à juste titre Einstein « Les choses devraient être faites aussi simples que
possible, mais pas plus simples. ». Cela s’applique très bien au développement logiciel.
En effet, il est préférable de ne pas anticiper les besoins du client et de rendre le système
le plus simple possible, répondant aux besoins actuels pour que ceux-ci soient facilement
adaptables si nécessaire dans le futur.
11. « Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui
s'auto-organisent »
Qui mieux que l’équipe elle-même peut déterminer qui est le plus à même d’effectuer une
tâche au sein d’une équipe ?
12. « À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis
accorde et ajuste son comportement dans ce sens ».
Le principe même de l’agilité est d’être réactif aux changements qui sont inévitables. Il est
donc clair que, aussi bien pensée qu’elle soit, une méthodologie de développement agile
est soumise à des modifications. Les méthodologies de développement agile définissent
des développements qui sont agiles mais elles doivent l’être elles-mêmes.
Définition d’une méthodologie de développement
41 / 149
3.2.3.2 Conclusion
La conclusion est simple, contrairement aux méthodes classiques, les méthodologies agiles
sont très intéressantes pour le développement logiciel pour plusieurs raisons :
• Elles intègrent le client pour être plus proches de ses besoins.
• Elles sont adaptives plutôt que prédictives.
• Elles sont orientées vers l’humain, plutôt que vers les processus et outils.
Ces quelques points sont un avantage certain des méthodes agiles vis-à-vis des méthodes
classiques.
En règle générale, elles permettent aussi de minimiser le coût d’un changement au travers du
temps contrairement à une méthodologie classique. En effet, dans les méthodologies
classiques, plus un changement est découvert tardivement, plus le coût lié à ce changement
augmente. Tandis que ce coût a tendance à se stabiliser dans une méthodologie agile telle que
extreme programming (cf. 3.5.1) comme le montre la Figure 10 tirée du site [W100]:
Figure 10 Analyse du coût d'un changement en fonction de son moment d'apparition
Définition d’une méthodologie de développement
42 / 149
3.3 Mise en évidence des méthodologies utiles à une
PME
Nous avons vu dans la partie 3.2.2 Constat actuel de l’état et des problématiques du
développement logiciel que les méthodologies classiques ne sont pas bien adaptées au
développement logiciel. Cela peut s’expliquer par le fait qu’elles sont issues d’autres
domaines de l’ingénierie comme le génie civil. Ces domaines étant très différents, un modèle
applicable pour le génie civil ne l’est pas forcément pour l’ingénierie du logiciel. Faisons la
comparaison entre le développement d’un logiciel et la construction d’un bâtiment :
Bâtiment Logiciel Des dessins décrivent de manière précise la construction du bâtiment
Des schémas spécifient le logiciel de manière globale
Il est assuré que le processus de construction suivra les dessins
Le processus de construction va remettre en question les dessins (erreurs de conception inévitables)
Les besoins du client sont clairement définis
Les besoins du client évoluent
Le coût se situe au niveau de la construction
Le coût se situe partout sauf au niveau de la construction
… …
Tableau 2 Comparatif bâtiment et logiciel
Ces quelques points montrent que le développement logiciel est une activité différente. Cela
implique donc que le développement logiciel demande une méthodologie différente. Et les
méthodologies qui, à l’heure actuelle, semblent les plus indiquées pour répondre aux besoins
du développement logiciel d’une PME sont les méthodologies agiles.
Ces méthodes sont utiles car les développements que réalisent les PME se situent souvent dans
un contexte de besoins changeants. Et même si les besoins sont stables, une méthode agile doit
pouvoir s’adapter à ces besoins fixes.
Un autre point utile pour une PME est que ces méthodologies placent l’humain comme le
facteur principal dans le succès des projets et ne le voient pas comme un composant
remplaçable. En effet, la notion des individus en tant que ressource est profondément incrustée
dans la pensée industrielle. Et si cette notion de remplacement est applicable pour une usine
[W56] elle ne l’est clairement pas pour un travail autrement créatif et professionnel qu’est le
développement de logiciel d’une PME. Cette mise en avant des individus est une source de
motivation pour les développeurs. Et cette motivation a un impact direct sur la productivité.
Ce qu’il ne faut surtout pas perdre de vue vis-à-vis de l’utilisabilité d’une méthodologie par
une PME est qu’elles ne doivent pas être des contraintes pour les gens qui les utilisent mais
Définition d’une méthodologie de développement
43 / 149
plutôt des supports. Cela découle d’une acceptation de la méthodologie par les utilisateurs
plutôt que l’imposition de celle-ci. Et il est plus facile de faire accepter une méthodologie de
développement agile qui prend en compte les utilisateurs et qui est simple à mettre en œuvre
qu’une méthodologie lourde, compliquée et bureaucratique.
En règle générale, les problèmes du développement logiciel peuvent être qualifiés selon les
trois critères suivant :
• Dépassements de délais
• Dépassements de budget
• Fonctionnalités inadéquates
Les méthodologies agiles s’attaquent principalement au dernier critère. En intégrant le client
et en appliquant ses demandes de modification cette problématique disparaît. En contrepartie
comme les besoins ne sont pas entièrement connus à l’avance, il est difficile d’établir un
temps et un budget fixes. C’est une problématique importante car cela demande une confiance
réciproque entre le client et l’entreprise ainsi qu’une adaptation des délais et du budget en
fonction des modifications. Mais il est clair que pour un client si les besoins peuvent changer
il est plus risqué pour lui d’utiliser un processus prédictif.
Enfin voici un tableau comparatif qui peut aider à choisir entre une méthodologie agile ou une
méthodologie prédictive :
Adaptatif Prédictif Besoins incertains et volatiles Equipe de plus de 50 personnes Prix et délais fixes mais pas la portée Prix, délais et portée fixés dans un contrat Développeurs responsables et motivés Utilisateurs qui comprennent et s’impliquent
Tableau 3 Faire le choix entre les modèles adaptatif et prédictif
3.4 Choix d’une méthodologie
Comme l’ont démontré les chapitres précédents, les méthodologies les mieux adaptées au
développement logiciel pour une PME sont de type agile. D’une part parce que les
méthodologies classiques concentrent la partie décisionnelle au début du projet pour donner au
client des garanties sur ce qu’il obtiendra en fin de projet sans tenir compte de la variabilité
des besoins du client. D’autre part parce que ces méthodologies visent à rendre les choses le
plus simple possible mais pas plus simples. Ce qui diminue la documentation et permet aux
développeurs de se concentrer sur des tâches à plus haute valeur ajoutée. Enfin, elles sont
basées sur deux points essentiels : l’intégration du client pour répondre à ses besoins réels et
Qualité
Coût Délais
Définition d’une méthodologie de développement
44 / 149
une vision basée sur les individus et non pas sur les processus ce qui améliore les
performances de développement en conservant la motivation de l’équipe.
Tous ces points amènent donc à faire le choix d’une méthodologie agile.
Toutefois, le choix d’une méthodologie n’est pas une chose aisée. Elle dépend de beaucoup de
facteurs de l’entreprise. Il faut garder à tout moment en tête que la méthodologie choisie ne
doit pas être une contrainte pour ces utilisateurs mais plutôt un support à leur capacité de
développement.
D’une autre manière il faut aussi éviter d’utiliser une méthodologie pour utiliser une
méthodologie. Aucune méthodologie ne peut garantir le succès d’un projet. En se focalisant
sur le respect aveugle d’une méthodologie, le but principal qui est finalement la réussite du
projet risque bien d’être perdu de vue. En définitive, la bonne méthodologie est celle qui
permet le succès du projet. De plus, la méthodologie idéale serait celle qui serait tellement en
osmose avec l’équipe que celle-ci ne se rendrait plus compte du poids de la méthodologie
utilisée. Il faut donc que la méthodologie soit le moins intrusive possible et le plus facile à
prendre en main.
Bien évidemment la mise en place d’une méthodologie par une équipe n’est pas aisée, elle doit
être mise en place par le support d’outils. Mais il ne faut pas surcharger les équipes avec un
grand nombre d’outils difficiles à mettre en œuvre, il y a déjà bien d’autres problèmes que
doivent régler les équipes sans rajouter celui-là. C’est plutôt à la méthodologie de se diffuser
dans les outils du quotidien. Ce qui peut être réalisé avec "Microsoft Visual Studio Team
System"[B7].
Finalement, il est inutile de passer des mois à réfléchir sur la mise en place d’une nouvelle
méthodologie pour la PME. Il est plus utile d’étudier les méthodologies existantes qui ont été
réfléchies et qui ont mûri. Puis suite à cette étude, il est alors possible de concocter une
méthodologie tenant compte des spécificités de la PME.
En conclusion, le choix d’une méthodologie utile à une PME se fait selon les critères
suivants :
• Réactivité au changement
• Simplicité, facilité à prendre en main et à utiliser. Elle doit éviter les contraintes voir,
si possible, elle doit les rend invisibles pour l’équipe
• Intégrabilité du client
• Basée sur les individus et non pas sur le processus ou les outils
• Prise en charge par les outils du quotidien
• Adaptabilité à l’entreprise
Définition d’une méthodologie de développement
45 / 149
Si une méthodologie répond parfaitement à ces critères, elle est tout simplement la plus à
même pour permettre à l’équipe de développement d’atteindre le succès d’un projet.
Le Tableau 4 tiré du site [W137] fait un comparatif des méthodologies de développement :
Type Cascade Semi-itératif Itératif
Explication
Approche totalement cascade
Approche en cascade dans le première partie. Puis approche itérative-incrémentale pour la gestion des besoins
Totalement itérative-incrémentale avec une préphase d’exploration
Exemple Merise, SDM/S
RAD, RUP, DSDM XP, FDD, Crystal
Tableau 4 Types de Méthodologies et exemples
Le Tableau 5 tiré du site [W81] fait un comparatif des méthodologies agiles et du modèle en
cascade :
Cascade (WaterFall) Développement agile Orienté planification Orienté apprentissage/expérience Communications client épisodiques Communications client continues Livraison unique (“Big bang”), en général au bout de 9 à 12 mois
Cycle de livraison rapide et orienté métier le plus souvent possible
Définition initiale et unique des exigences Exigences “juste à temps” Développement multiphase (avec livraisons “papier” intermédiaires)
Développement et livraison de code opérationnel par itérations courtes
Développement multicouche : présentation, persistance, métier, etc.
Développement par tranches fonctionnelles complètes
Programmation = Construction Programmation = Conception Intégration des couches à l’issue de la phase de construction
Intégration continue du code (“builds” horaires)
Isolation des tests (essentiellement fonctionnels) en fin de projet
Tests automatisés et continus (fonctionnels et unitaires)
Coûts de modification prohibitifs Coûts de modification réduits
Tableau 5 Comparaison agile vs cascade (Waterfall)
Définition d’une méthodologie de développement
46 / 149
3.5 Quelques méthodologies agiles
Ce chapitre permet de mettre en évidence quatre méthodologies agiles. La première, eXtreme
Programming (XP), a été choisie car elle est tout simplement la méthodologie agile la plus
connue. Quant à la méthodologie Unified Process (UP), elle est certainement la plus utilisée.
MSF Agile est une méthodologie fournie avec l’usine à logiciel de Microsoft. Et pour finir,
Scrum est actuellement la méthodologie agile qui monte. Il existe bien évidemment un grand
nombre d’autres méthodologies agiles qui ne seront pas traitées ici . En effet, le but n’étant pas
d’être exhaustif et de parler de toutes ces méthodologies mais plutôt de mettre en évidence
celles qui sont les mieux adaptées ou les plus utilisées par les PME. Cependant les
méthodologies suivantes méritent d’être citée ; Rapid Application Development (RAD)
[W122] qui est un précurseur des méthodologies agiles, Dynamic Software Development
Method (DSDM) [W123], Feature-Driven Development (FDD) [W124], Crystal ou encore
Adaptive Software Development (ASD) [W125].
Ce chapitre n’a pas pour but de définir dans les détails toutes ces méthodologies mais plutôt de
donner un aperçu global de leurs fonctionnements.
La Figure 11, la Figure 12 et la Figure 13 permettent de situer ces méthodologies les unes par
rapport aux autres.
Figure 11 Méthodologies agiles en fonction de la taille du projet tirée de [W73]
Définition d’une méthodologie de développement
47 / 149
Figure 12 Méthodologies agiles en fonction des contraintes tirée de [W73]
Figure 13 Méthodologies agiles en fonction des contraintes tirée de [W57]
Définition d’une méthodologie de développement
48 / 149
3.5.1 Unified Process (UP) and Rational Unified Pro cess (RUP)
RUP est l’une des plus célèbres implémentations de la méthode UP. Cette introduction sera
donc plus spécifique à RUP. De plus, d’après une étude effectuée en 2005, RUP est à l’heure
actuelle la méthodologie de développement la plus utilisée (cf. Figure 14).
Figure 14 Utilisation des méthodologies agiles tirée de [W52]
3.5.1.1 Introduction
RUP est une méthodologie de développement logiciel orienté objets qui est apparue en 1998 et
peut être considérée comme un avatar de UP. Elle spécifie les activités à mener pour
transformer les besoins d’un utilisateur en système logiciel. Elle utilise UML (Unified
Modeling Language) pour la création de différents diagrammes (plan de construction du
système logiciel). Elle peut être considérée comme une méthodologie agile car elle est
itérative et incrémentale et qu’elle s’adapte au changement. La Figure 15 retrace un petit
historique de RUP.
Figure 15 Historique de RUP tirée de [W83]
Définition d’une méthodologie de développement
49 / 149
RUP répond aux exigences fondamentales préconisées pas les créateurs d’UML vis-à-vis
d’une méthodologie de développement logiciel :
• Guidée par les besoins des utilisateurs.
• Centrée sur l’architecture.
• Itérative et incrémentale.
RUP est conforme à UP et présente donc les caractéristiques suivantes, permettant de
transformer les besoins utilisateurs en logiciel :
• UP est à base de composants.
• UP utilise UML.
• UP est piloté par les cas d’utilisation.
• UP est centré sur l’architecture.
• UP est itératif et incrémental.
3.5.1.2 Fonctionnement
Le principe de RUP présenté en introduction définit grandement son fonctionnement.
RUP est piloté par les cas d’utilisation : Chaque besoin fonctionnel du client est exprimé par
le développeur sous forme de diagrammes de cas d’utilisation. Un cas d’utilisation est une
fonctionnalité du système produisant un résultat satisfaisant pour l’utilisateur. L’ensemble des
diagrammes de cas d’utilisation représente les fonctionnalités finales du système, ils sont la
réponse à la question « Qu’est censé faire le système ? ». C’est à partir de ces cas d’utilisation
que va être guidé tout le reste du processus afin de garantir la cohérence avec les besoins des
utilisateurs.
RUP est centré sur l’architecture : l’architecture propose une vue globale de la conception
faisant ressortir les caractéristiques essentielles en laissant de coté les détails secondaires.
Tous les problèmes complexes sont réduis en systèmes plus petits, plus simples et modulaires
(les composants) afin de garantir une maintenance et une évolution facilitées. L’architecture
complète du système est représentée par les différents diagrammes UML réalisés.
RUP est itératif et incrémental : Comme les projets peuvent être grands, il est souvent
intéressant de les découper en plusieurs parties qui sont autant de mini-projets. Chaque mini-
projet représente une itération et produit un incrément (partie exécutable du système final).
Chaque mini-projet est vu comme une itération car il regroupe toutes les principales étapes
(cas d’utilisation, analyse, conception, implémentation, tests). Ces itérations permettent de
converger vers un système satisfaisant grâce au concept de feedback et d’évolution des
besoins défini par les méthodes agiles.
Définition d’une méthodologie de développement
50 / 149
Ces trois parties sont d’égale importance. L’architecture fournit la structure qui servira de
cadre au travail effectué au cours des itérations, tandis que les cas d’utilisation définissent
les objectifs et orientent le travail de chaque itération . Il est possible d’y ajouter une
quatrième partie qui serait la conduite par les risques. En effet, dans RUP il est important
d’identifier les risques au plus tôt et surtout de les lever le plus rapidement possible. Les
risques ont donc un impact direct sur l’ordre des itérations.
Les points précédents ont déterminé les parties principales de RUP. Son cycle de
développement, allant de la naissance à la mort du logiciel, est découpé en cycles (versions du
logiciel). Chaque cycle fait intervenir les trois phases suivantes : Elaboration, Construction, et
Transition, la phase d’Inspection étant réalisée préalablement. Chaque cycle est aussi découpé
en itération comme précédemment décrit. La Figure 16 tirée du site [W89] montre
approximativement l’importance des différentes activités durant chaque phase.
Figure 16 Utilisation des méthodologies agiles
Inception : L’inspection (initialisation) détermine en quelque sorte la « vision » du projet afin
de décider de sa poursuite ou de son arrêt. Permet de déterminer en substance ce que va faire
le système pour les utilisateurs (modèle simplifié des cas d’utilisation), à quoi peut bien
ressembler l’architecture d’un tel système ainsi qu’une étude de rentabilité. Cette phase
permet d’identifier les risques majeurs, de planifier la phase d’élaboration et d’estimer
approximativement le projet dans son ensemble.
Elaboration : Description plus détaillé et complète des cas d’utilisation et de l’architecture du
système (premier squelette ou prototype). A l’issue de cette phase le projet dans son ensemble
est estimé plus justement et les risques majeurs sont levés.
Définition d’une méthodologie de développement
51 / 149
Construction : Cette phase vise à développer le logiciel, à métamorphoser l’architecture en un
système complet en concevant, en implémentant et en testant l’ensemble des éléments.
Transition : Cette phase permet le passage de l’application des mains des développeurs aux
utilisateurs finaux en mettant en place la formation des utilisateurs, le déploiement ainsi que
les béta-tests.
3.5.1.3 Evaluation
Avantages
• Méthodologie Agile (tous les avantages de ce type de méthodologie).
• Spécifie le dialogue entre les différents intervenants du projet : les livrables, les
plannings, les prototypes…
• Propose des modèles de documents et des canevas pour des projets types.
• Gestion des risques dans le projet (risque financier et de retard limité).
Inconvénients
• Lourd, bureautique (mise à jour des schémas), rigoureux et couteux.
• Très axé processus, au détriment du développement : peu de place pour le code et la
technologie.
• Vision non évidente ni immédiate.
• Projet de plus de dix personnes.
3.5.1.4 Conclusion
RUP peut être considérée comme une méthodologie de développement agile car elle est
itérative et incrémentale, qu’elle se base sur les besoins des clients et qu’elle est adaptive au
changement. En revanche, RUP est une méthode nettement basée sur les processus et la
documentation UML, ce qui a tendance à l’alourdir. Cette méthode peut être intéressante pour
de gros projets car elle spécifie absolument tout. Par contre, pour de petits projets, la rigueur et
la documentation à outrance qu’impose cette méthodologie n’est pas adaptée.
Définition d’une méthodologie de développement
52 / 149
3.5.2 Extreme Programming (XP)
3.5.2.1 Introduction
Extreme Programming est une méthodologie proposée par Kent Beck dans les années 1990,
avec l’aide de Ward Cunningham et de Ron Jeffries. Elle est la méthodologie agile la plus
connue. Elle regroupe un ensemble de bonnes pratiques de développement découlant des
principes de l’agilité et les poussent à l’extrême. Elle vise en premier lieu à remettre le
développeur et le client au centre du processus de développement. Elle est applicable pour des
équipes de petite taille de l’ordre d’une douzaine de personnes. Elle semble de prime abord
simple d’utilisation mais elle réclame beaucoup de discipline et de communication.
3.5.2.2 Fonctionnement
Elle repose sur les quatre principes du développement agile à savoir : la communication, le
feedback, la simplicité et le courage. Il s’agit dès lors d’appliquer à l’extrême les 12-13 (les
tests sont souvent regroupés sous une seule pratique) bonnes pratiques suivantes (découlant
aussi des pratiques agiles) :
Figure 17 Les pratiques d’XP tirée de [W91]
Les pratiques XP
1. Client sur le Site (Whole Team) : Les développeurs sont assistés par une personne
dédiée qui est chargée de déterminer les besoins, fixer les priorités, rédiger les cahiers
de recette et répondre aux questions des programmeurs. Cette personne dédiée doit se
trouver sur le même site que les développeurs.
2. Séance de Planification (Planning Game) : Le client définit les scénarios
utilisateurs. Les développeurs discutent le contenu de ces scénarios, définissent les
tâches techniques sous-jacentes, estiment ces tâches (temps/effort) et y souscrivent.
Définition d’une méthodologie de développement
53 / 149
Le client choisi les scénarios prioritaires de façon à se focaliser uniquement sur les
buts principaux à atteindre et différer les objectifs secondaires d’une itération.
3. Intégration Continue (Continuous Integration) : Le système n’est pas vu comme un
bloc mais comme un système simple auquel s’ajouteront de petits modules. Ces
modules sont intégralement assemblés et testés une à plusieurs fois par jour. Ce qui
rend le système stable et opérationnel plus rapidement.
4. Livraisons Fréquentes (Small Releases) : Le rythme des livraisons doit être le plus
court possible ce qui permettra d’accélérer le feedback du client en lui fournissant
rapidement des fonctionnalités utilisables. Cette accélération du feedback va réduire
au minimum les mésententes entre le client et les développeurs. Cela aura plusieurs
effets positifs : accélération du développement, satisfaction du client car ses besoins
sont enfin compris et augmentation de la motivation des développeurs.
5. Rythme Soutenable (Sustainable Pace) : L'équipe ne fait pas d'heures
supplémentaires deux semaines de suite. Car un programmeur fatigué fait plus
d’erreurs.
6. Tests de Recette (Customer Tests) : Retours d'informations rapides sur le système,
en général automatisé, constitué à partir de critères de tests définis par le client.
7. Basé sur les tests (Test-Driven Development) : Les tests sont écrits avant le code. En
effet, ceci accélère le développement car cela force la concentration sur les interfaces,
réduit les défauts et évite la régression (ensemble de tests unitaires).
8. Conception Simple (Simple Design) : L’attention doit être mise sur les besoins
actuels du client ni plus ni moins. Un acronyme anglais célèbre résume très bien cela
« You Arent Gonna Need It (YAGNI)» qui signifie « tu ne vas pas en avoir besoin ».
Un travail propre, simple et minimal aujourd’hui est facile à améliorer par la suite.
Cette philosophie s’applique aussi à la documentation.
9. Métaphore (Metaphor) : La métaphore est utilisée pour modéliser conceptuellement
le système en cours de développement afin de clarifier les fonctionnalités à atteindre à
l’aide du vocabulaire du client.
10. Remaniement Continu de Codage (Refractoring): Le code étant en constante
modification et n’ayant pas de conception en amont, il doit être remanié constamment
pour être propre sans modifier son comportement (Tests de non régression).
11. Convention de Code (Coding Standard) : Le code doit suivre une convention de
nommage et de présentation afin d'être lisible par tous les membres de l'équipe. Cela
dans le but de permettre le codage par paire et le partage de code.
Définition d’une méthodologie de développement
54 / 149
12. Programmation En Binôme (Pair Programming) : Le code est toujours écrit par
deux développeurs. Cela permet d’avoir une relecture de code permanente et donc plus
de qualité et de robustesse. Mais cela permet aussi une dynamique de projet, une
motivation des développeurs accrue ainsi qu’un partage et un transfert des
connaissances. Les binômes changent au cours du projet.
13. Propriété Collective du Code (Collective Ownership) : Chaque développeur peut
modifier chaque partie du code si le besoin s'en fait sentir.
Les principes fondamentaux du fonctionnement de la méthodologie XP ayant été parcourus, la
partie suivante montrera le cycle idéal d’un développement utilisant XP.
Le cycle de développement XP
Les étapes principales du cycle de développement de la méthodologie XP peuvent être
représentées par la figure suivante (un cycle plus détaillé est présent sur le site [W92]) :
Figure 18 Etapes du cycle de développement XP
• Exploration : Cette phase permet au client d’exprimer ses besoins à l’aide de User
Stories. Les User Stories sont de petites histoires simples, écrites dans le langage du
client (Métaphore) et décrivant les fonctionnalités demandées sur des fiches. Un
projet peut compter une centaine de User Stories.
• Planning : Dans cette phase, les développeurs estiment le coût de développement de
chaque User Storie en utilisant un système de points. Puis le client choisit les User
Stories qui seront développées pendant la prochaine itération en fonction du coût des
User Stories, de la vélocité (nombre de points réalisables durant une itération) ainsi
que de la valeur (priorité ) qu’attribue le client à chaque User Storie. Si une User
Storie ne peut pas être estimée un Spike est créé. Ce Spike permet de définir plus
clairement une User Storie. Une User Storie trop longue sera découpée. C’est aussi
durant cette période que le client définit les tests d’acceptances.
• L’itération : permet d’implémenter les User Stories. D’abord les binômes sont créés,
puis les tests sont codés, le code est réorganisé pour intégrer les fonctionnalités issues
des User Stories puis les fonctionnalités sont codées. C’est la partie itérative et
incrémentale principale de la méthodologie XP. A chaque itération, le processus de
Définition d’une méthodologie de développement
55 / 149
l’étape planning est recommencé en tenant compte des informations retournées par
l’itération précédente.
La Figure 19 montre les interactions entre les acteurs du développement XP ainsi que ce qu’ils
acquièrent durant le cycle de développement:
Programmer
Customer
Customer
Programmer
Build value Define value
Estimate valueChose value
report
coordinate
communicate
facilitate Manager
learn
learn
Figure 19 Interaction et apprentissage en XP
3.5.2.3 Evaluation
Avantages
• Méthodologie Agile (tous les avantages de ce type de méthodologie).
• Relativement simple à mettre en œuvre.
• Fait une large place aux aspects techniques : prototypes, règles de développement,
tests, …
• Innovant: programmation en duo, kick-off matinal debout, …
• Très bon pour le travail en équipe (motivation).
Inconvénients
• Élude la phase d’analyse, si bien qu’on peut dépenser son énergie à faire et défaire.
• Acceptation difficile par les clients externes.
• Mise en œuvre assez dure (changement de mentalité, adaptation).
• Le refactoring est loin d’être une technique simple.
• Difficile de fixer les prix et délais à l’avance pour des fonctionnalités car elles ne sont
pas disponibles directement.
• Adapté uniquement aux petites équipes.
Définition d’une méthodologie de développement
56 / 149
3.5.2.4 Conclusion
Cette méthodologie peut paraître simple à mettre en place, mais elle nécessite la plupart du
temps un changement de mentalité et une acceptation par l’ensemble de l’équipe impliquée
(client compris). Elle n’est pas évidente à appliquer et à maîtriser car elle réclame beaucoup de
discipline et de communication. Mais elle est, dès que le processus est bien accepté et
maîtrisé, une méthodologie très appréciée par l’ensemble de l’équipe pour la productivité
accrue, la dynamique et la motivation qu’elle apporte aux équipes. Elle reste la méthode agile
la plus radicale (extrême). Mais elle permet la mise en place de projets de qualité grâce aux
tests systématiques, en plus elle permet d’être certain de coller aux besoins du client.
Définition d’une méthodologie de développement
57 / 149
3.5.3 Scrum
3.5.3.1 Introduction
Scrum est une méthodologie de développement logiciel mise au point dans les années 1990
par Ken Schwaber (un des créateurs de l’agilemanifesto [W68]). Elle est principalement basée
sur la gestion des ressources humaines et peut être adaptée à d’autres contextes où il existe un
besoin de travailler en équipe. Le terme Scrum signifie « mêlée » en anglais et vient du rugby,
au moment où toute l’équipe doit se souder pour atteindre un but (avancer avec le ballon).
Scrum est une méthodologie de développement logiciel itérative et incrémentale, mais elle est
plus basée pratique de management et n’impose aucune pratique de développement comme le
fait RUP. Scrum peut donc être vue comme le cadre de développement venant par exemple
appuyer des pratiques XP.
Pour mieux appréhender les notions de Scrum, voici un peu de vocabulaire :
Product backlog : Liste regroupant les exigences du client. Ce référentiel évolue au cours
du développement pour prendre en charge au mieux les besoins du client.
Chaque exigence du client possède une priorité et un coût de
développement qui permet de produire le Product burndown chart.
Sprint backlog: Liste des tâches à effectuer pendant un Sprint. Les items du product
backlog affectés au sprint sont divisés en tâches appelées les Sprint item.
Sprint : Itération de trente jours (en théorie et deux à quatre semaines en pratique)
durant laquelle l’équipe développe le Sprint backlog.
Scrum: Réunion quotidienne de quinze minutes. Le but étant de faire le point sur
ce qui a été fait, ce qu’il reste à faire et les problèmes rencontrés.
Scrum Master : Facilitateur de projet Scrum. C’est un membre de l’équipe comme un
autre (pas de hiérarchie) qui doit protéger l’équipe des perturbations
extérieures. Il doit permettre à l’équipe de travailler de façon autonome et
en s’améliorant constamment. Mais il doit aussi veiller à ce que les
valeurs de Scrum soient appliquées.
Product owner : C’est le propriétaire du produit ou le client. Responsable de définir et de
maintenir à jour le product backlog. Il détermine les priorités et prend les
décisions concernant l’orientation du projet.
Scrum Team : Représente tous les membres de l’équipe sans distinction de fonction
(développeur, architecte, …). L’équipe est autonome et s’autogère.
Burndown chart : Représente graphiquement le travail restant à faire au fur et à mesure des
Sprint ou au sein d’un Sprint.
Définition d’une méthodologie de développement
58 / 149
3.5.3.2 Fonctionnement
La Figure 20 tirée du site [W102] représente le fonctionnement de Scrum :
Figure 20 Fonctionnement de Scrum
Le principe de base de Scrum est de focaliser l’équipe sur un ensemble de fonctionnalités à
réaliser durant une itération appelée Sprint durant théoriquement trente jours mais dans la
pratique plutôt deux à quatre semaines.
Tout d’abord, durant une phase de planification débutant le Sprint, le Product Owner ordonne
en fonction de leurs priorités les exigences représentées par des items dans le Product backlog.
Ensuite, toujours dans la phase de planification, la Scrum Team estime ces exigences en points
et détermine quels sont les exigences qui feront partie du Sprint. La première phase de
planification est ainsi achevée et elle a permis au Product Owner et à la Scrum Team de
définir le périmètre du Sprint. Une deuxième phase de planification permettra à la Scrum
Team de décomposer les items choisis en tâches formant la Sprint backlog.
La phase de planification du Sprint étant finie il est temps de passer à l’exécution du Sprint.
Durant cette exécution, une Scrum (réunion) à lieu quotidiennement pour contrôler le bon
déroulement. La Scrum Team développe le logiciel, sans que la méthodologie Scrum ne lui
impose aucun processus. Il est par exemple possible ici d’y intégrer les bonnes pratiques de
XP. Durant le Sprint, le client est entièrement intégré et peut en tout temps modifier le product
backlog mais il ne peut pas modifier ce qui est en cours de développement (Sprint backlog).
Un membre de l’équipe appelé le Scrum master s’assure que durant un Sprint l’équipe de
développement ne soit pas touchée par les perturbations extérieures. De plus, il détermine
grâce au Scrum quotidien l’avancement du Sprint et l’ajuste (modifie le Backlog de Sprint
avec l’accord du Product Owner) pour assurer le succès du Sprint.
Pour finir, un Sprint aboutit toujours à la livraison d’une version fonctionnelle du produit
potentiellement utilisable. Une revue de Sprint a lieu la fin de celui-ci afin de montrer au
Product Owner le produit réalisé. Suite à cette revue de Sprint la Scrum Team effectue une
rétrospéctive pour faire un bilan du sprint qui se termine.
Définition d’une méthodologie de développement
59 / 149
3.5.3.3 Evaluation
Avantages
• Avantage des méthodes agiles (itération, changement, équipe, …).
• Vision rugby (chaque match est différent et chaque logiciel développé également).
• Pas de distinction des rôles au sein du Scrum Team. Ce qui est souvent le cas dans une
PME.
• Indépendant des activités d’ingénierie (on peut par exemple utiliser XP).
• Faire confiance à l’équipe en l’isolant durant le Sprint et en la rendant autogérée.
• Equipes soudées. Les règles de Scrum favorisent l’esprit d’équipe.
• Réunion journalière (état d’avancement, partage du savoir, …).
Inconvénients
• Une préphase de création du Product backlog doit être mise en place.
• Le temps d’un Sprint doit être proportionnel au projet et non pas figé à trente jours,
mais fixe pour un projet donné.
• Il faut un système d’intégration des éléments perturbateurs. Prise en compte au sein du
Sprint de modifications urgentes.
3.5.3.4 Conclusion
L’avantage de Scrum par rapport aux autres méthodologies de développement logiciel est
qu’elle s’intéresse plutôt à l’organisation du projet qu’aux aspects techniques. Elle peut donc
être couplée avec une méthodologie telle que XP pour prendre en compte tous les aspects. De
plus, sa vision rugby est bien adaptée au développement logiciel où l’équipe doit avancer
ensemble vers un but commun. Certains aspects doivent néanmoins être adaptés et non pas
simplement pris à la lettre pour rendre Scrum utilisable. Principalement le temps d’un Sprint
ne doit pas être d’exactement un mois mais il doit être adapté au projet.
Définition d’une méthodologie de développement
60 / 149
3.5.4 MSF Agile
3.5.4.1 Introduction
Microsoft offre par défaut deux méthodologies de développement logiciel dans Microsoft
Visual Studio Team System. L’une d’entre elles est MSF Agile. Ces méthodologies sont
issues du Microsoft Solutions Framework (MSF) qui est un regroupement de principes, de
modèles, de concepts et de lignes directrices pour la conception d'applications [W114].
3.5.4.2 Fonctionnement
La méthodologie MSF Agile est basée sur trois concepts principaux : les workItems, les rôles
et les itérations.
workItems
Les workItems représentent toute opération élémentaire induite au projet. Ils permettent un
suivi de l’assignation et de l’état du projet. Les workItems définis par la méthodologie MSF
Agile sont de cinq type différents :
Scénarios : Permet de décrire le déroulement d’une interaction entre l’utilisateur et le
système. Son cycle de vie est composé des trois états (actif, résolu, fermé). Il est
actif lors de sa création par l’analyste métier ainsi que pendant le
développement. Le responsable du développement le passe à l’état résolu dans
les cas suivants :
• Son développement est terminé et il est alors affecté à un testeur.
• On doit le fractionner car il est trop volumineux.
• On doit le différer à l’itération suivante.
• Il est supprimé car cette fonctionnalité n’est plus utile.
Le scénario peut alors passer de résolu à fermé lorsque le testeur indique que les
tests ont été correctement passés. Si les tests ne sont pas correctement passés, il
repasse dans l’état Actif. Ces différentes transitions sont définies dans le schéma
suivant :
Définition d’une méthodologie de développement
61 / 149
Figure 21 Etat Transition d’un sénario MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Qualité : Les impératifs de qualité de service documentent les caractéristiques impératives
des qualités du système telles que les performances, la charge, la disponibilité,
les contraintes, l’accessibilité ou encore la facilité de maintenance. Ils prennent
généralement la forme de contrainte sur la manière dont le système doit
fonctionner. Son cycle de vie est composé des trois mêmes états que le cycle
d’un scénario. De plus, les transitions sont les mêmes hormis le fait qu’il n’est
pas possible de fractionner un impératif de qualité. Voici le schéma des
transitions entre les états:
Figure 22 Etat Transition d’un impératif de qualité MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Tâches : Détermine un travail à effectuer. Elle peut donc représenter beaucoup de choses
comme par exemple une tâche de développement pour assigner à un développeur
un travail découlant d’un scénario, une tâche de test pour l’écriture et l’exécution
d’un test par le testeur… Son cycle de vie est composé des deux états (actif,
fermé). Elle est active lors de sa création ainsi que pendant sa réalisation. Elle
passe à l’état fermée dans les cas suivants :
• Lorsqu’il n’y a plus de travail à effectuer (Terminé).
Définition d’une méthodologie de développement
62 / 149
• On doit le différer à l’itération suivante.
• Lorsque le travail effectué pour cette tâche devient obsolète pour le
produit global.
• Il est supprimé car cette fonctionnalité n’est plus utile.
Une tâche peut être réactivée suite à une modification de ses fonctionnalités.
Voici le schéma des transitions entre les états:
Figure 23 Etat Transition d’une tâche MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Bug : Permet de définir un problème découvert dans le système. Son cycle de vie est
composé des trois états (actif, résolut, fermé). Il est actif lors de sa découverte
ainsi que durant son traitement. Il passe à l’état fermé dans les cas suivants :
• Lorsque celui-ci est corrigé.
• Si ce n’est pas un bug et que cela correspond aux spécifications.
• On doit le différer à l’itération suivante.
• Lorsque ce bug est la duplication d’un bug existant.
• Si le problème n’est plus applicable au produit (obsolète).
• S’il est impossible à reproduire.
Un Bug peut repasser de l’état résolu à l’état actif dans les conditions suivantes:
• La résolution n’est pas acceptable.
• Le bug n’est pas corrigé.
• Un test prouve que le bug existe toujours.
Il passe néanmoins de l’état résolu à l’état fermé dans les conditions suivantes:
• La résolution est en place dans un build (corrigé).
• L’auteur reconnaît que le bug décrit quelque chose de prévu dans la
conception.
• Si l’auteur accepte que le bug soit différé ou qu’il est obsolète, dupliqué
ou encore impossible à reproduire.
Définition d’une méthodologie de développement
63 / 149
Un bug peut être réactivé s’il y a eu un problème de régression du système (un
test indique que le bug existe à nouveau). Voici le schéma des transitions entre
les états:
Figure 24 Etat Transition d’un Bug MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Risque : Un risque représente n’importe quel élément susceptible d’avoir un impact
négatif sur le projet. Son cycle de vie est composé des deux états (actif, fermé).
Il est actif dès son identification. Il passe à l’état fermé dans les cas suivants :
• Lorsque sa survenue ou que son impact a été atténué à un niveau
acceptable.
• Lorsque sa probabilité d’apparition est négligeable (inactif).
• Lorsque le risque a été transféré (par exemple à un consultant externe).
• Lorsque le risque ne peut pas être annulé mais qu’il est accepté.
• Lorsque le risque a été évité.
Un risque peut néanmoins être réactivé dans une itération suivante. Voici le
schéma des transitions entre les états:
Figure 25 Etat Transition d’un Risque MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Définition d’une méthodologie de développement
64 / 149
Grâce à ces workItems, il est possible de générer des rapports répondant aux questions
relatives à l’état du projet. Pour que ces rapports soient pertinents, il faut bien comprendre et
gérer les différents types de workItems. Il est par exemple possible de générer des rapports de
qualité ou des rapports quantitatifs comme ceux-ci :
Figure 26 Rapport d’avancement quantitatif MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Figure 27 Rapport d’avancement qualitatif MSF Agile
Cette figure est tirée du « Process Guidance » de Team System.
Rôles
La méthodologie MSF Agile met l’accent sur les membres de l’équipe de développement. Elle
définit pour cela six groupes d’utilisateurs qui ont chacun leurs propres responsabilités mais
ont tous la même importance.
Définition d’une méthodologie de développement
65 / 149
Analyste métier : Il a pour but principal de définir les scénarios et les impératifs de qualité
de l’application en accord avec la vision du client. Il représente
l’expérience de l’utilisateur et défend les intérêts des commanditaires du
projet.
Chef de projet : Il a pour but de superviser la création d’une application ayant une valeur
commerciale en respectant l’agenda et le budget convenus. Il établit les
tâches, planifie les scénarios présents dans les itérations, contrôle
l’avancement du projet.
Architecte : Il doit garantir le succès en concevant les fondations de l’application. Son
but est de réduire la complexité en divisant le système en sous-systèmes
simples. Il doit entre autre déterminer les interfaces, créer un prototype
architectural,…
Développeur : Il doit implémenter l’application en respectant les délais. Il doit aussi
estimer le temps et l’effort nécessaire à la réalisation de chaque
fonctionnalité.
Testeur : Il doit déterminer les problèmes pouvant avoir un impact négatif sur la
valeur du produit. Il doit découvrir et signaler les bugs, il est en quelque
sorte le garant de la qualité du produit.
Livreur : Le responsable de la livraison doit gérer la livraison et le déploiement du
produit.
Itérations
MSF Agile est une méthodologie de développement itérative et incrémentale. Elle définit un
certain nombre de cycles au sein desquels les phases de définition des besoins, de
développement et de test sont réalisées :
Lors de l’utilisation de la méthodologie MSF Agile au sein de Team System, la première
itération contient déjà un certain nombre de tâches d’administration (choix de l’équipe, mail
aux utilisateurs, énoncé de vision, description de projet, déterminer la durée d’itération,
Définition d’une méthodologie de développement
66 / 149
explorer et classer par priorité la liste des scénarios et des impératifs de qualité, créer la
structure du projet, créer un plan d’itération). Par la suite, un certain nombre de flux de travail
définis dans le document de Processus Guidance sont suivis. Typiquement l’analyste métier va
suivre le flux de travail « Extraire la vision du projet » tandis que le chef de projet suivra le
flux de travail « Planifier la première itération ». Ces flux de travail en entraîneront d’autres et
le projet sera alors commencé.
3.5.4.3 Evaluation
Avantages
• Méthodologie Agile (tous les avantages de ce type de méthodologie).
• Son intégration dans Team System.
• Sa bonne documentation dans Team System.
Inconvénients
• Sa compréhension qui n’est pas vraiment évidente.
• A priori, toute la marche à suivre est décrite. Cependant, le cycle de développement
n’est pas clair.
3.5.4.4 Conclusion
MSF Agile est la méthodologie de développement agile présente par défaut dans Team
System. Elle est assez simple à prendre en main dès que les principes de rôle et de workItems
ont été assimilés. Elle est bien détaillée dans le document de Process Guidance et permettra à
chaque intervenant du projet de rapidement se mettre en place. Elle définit un certain nombre
de flux de travail pour chaque rôle, ces flux sont divisés en activités qui sont décrites dans le
Process Guidance. Le Process Guidance décrit aussi les éléments de travail, les produits de
travail (diagramme et documentation) ainsi que les différents rapports et requêtes accessibles.
Cette méthodologie semble être un bon début à l’agilité avec Team System.
Définition d’une méthodologie de développement
67 / 149
3.6 Comparaison des méthodes vues
Toutes les méthodologies de développement agile vues dans le chapitre 3.5 Quelques
méthodologies agiles ont comme valeur commune l’agilité. Cela signifie que toutes ces
méthodologies intègrent les douze principes généraux de l’agilité (cf. chapitre 3.2.3
Méthodologie de développement agile). Mais elles ont quand même des différences qui
poussent à choisir une méthodologie plutôt qu’un autre. Tout d’abord elles ont une complexité
de compréhension et de mise en œuvre très variée. Allant de la méthode la plus difficile RUP
à la méthode la plus simple Scrum. Elles ont aussi des niveaux de spécification variés. RUP
vise à tout définir, le cycle de développement mais aussi les documents créés (UML) ; ce qui
devient assez rapidement lourd et donc pousse les utilisateurs à ne plus suivre la
méthodologie. Il y aussi MSF Agile qui définit très clairement le processus, mais cette
méthodologie est tout de même un peu excessive. Le niveau d’implication dans le
développement est aussi différent, RUP s’implique à la fois dans la partie management (cycle,
phase, itération, …) et dans la partie pratique de développement (modélisation, conception,
développement, test), tandis que XP est plus basée sur la pratique de développement et que
Scrum s’oriente vers le management.
Tout cela nous amène à dire qu’il est difficile de faire un choix entre ces méthodologies. Il n’y
a à l’heure actuelle, et il n’y aura sûrement jamais, une bonne méthodologie. Elles ont toutes
leurs avantages et leurs inconvénients. Néanmoins, le choix d’une méthodologie pour une
PME doit se référer à un certain nombre de critères mis en évidence dans le Tableau 3 Faire
le choix entre les modèles adaptatif et prédictif. Le Tableau 6 représente un comparatif des
méthodologies étudiées en fonction des critères du Tableau 3.
RUP XP Scrum MSF Agile Réactivité au changement. Bon Bon Moyen Bon Simple et facile à prendre en main et à utiliser. Evite les contraintes voir si possible invisible pour l’équipe.
Mauvais Moyen Bon Moyen
Intégration du client Bon Bon Bon Bon Basée sur les individus et non pas sur le processus ou les outils
Moyen Bon Bon Moyen/Bon
Les outils quotidiens doivent prendre en charge la méthodologie (MVSTS)
Bon Moyen Bon Bon
Adaptable à l’entreprise Moyen Moyen/Bon Bon Moyen
Tableau 6 Comparatif de XP, RUP, MSF Agile et Scrum
Ce tableau est bien évidemment très subjectif et découle d’une impression personnelle vis-à-
vis de ces méthodologies.
Définition d’une méthodologie de développement
68 / 149
3.7 Méthodologie définie pour InfoTeam
3.7.1 Introduction
Suite à l’état de l’art décris dans les chapitres précédents, il est clair que la méthodologie de
développement logiciel la mieux adaptée à une PME se doit d’être agile. InfoTeam utilise
actuellement plusieurs méthodologies, mais cette entreprise est désireuse de connaître leurs
évolutions afin d’intégrer les concepts les mieux adaptés à son domaine.
Les attentes d’InfoTeam envers une méthodologie sont basées sur les points suivants :
Simplicité/souplesse : La méthodologie définie doit être simple et souple. Elle doit être
simple pour garantir son utilisation sachant qu’une méthodologie
compliquée et rigide ne sera sûrement pas appliquée. Elle doit être
souple pour s’adapter aux habitues de l’entreprise mais aussi des
clients (la taille des projets, les unités d’InfoTeam,…).
Suivi de l’avancement : Elle doit permettre une visualisation de l’avancement technique
du projet. Afin d’être plus à même de gérer les dépassements de
délai, ou tout du moins de faciliter leurs détection. Tout cela sans
avoir à rajouter une importante charge de travail aux membres de
l’équipe. Si possible une interaction avec la BD de gestion
d’affaire existante serait intéressante.
Contrat de type forfaitaire : La méthodologie doit être en accord avec le type des contrats de
rémunération d’InfoTeam qui veut que dans plus de 90% des cas,
les projets d’InfoTeam utilisent le système à forfait.
Prise en compte des tests : La méthodologie doit mettre l’accent sur la mise en place d’un
processus de test clairement défini.
Adapté aux habitudes : C’est à la méthodologie à s’adapter aux habitudes de
développement de l’entreprise et non pas l’inverse.
Orienté besoins du client : La méthodologie doit orienter le travail vers un résultat conforme
aux demandes du client plutôt que de la documentation, des
études de cas, … qui seront, dans la plupart des cas, inutiles pour
le client.
Orienté qualité : La méthodologie doit permettre la création de logiciel de qualité.
Les attentes d’InfoTeam ne sont de loin pas en contradiction avec les fondements de l’agilité,
elles regroupent même les principes fondamentaux de l’agilité. Il reste néanmoins à trouver
une méthodologie agile qui accepte les contrats de type forfaitaire.
Définition d’une méthodologie de développement
69 / 149
3.7.2 Quelle méthodologie agile
Il est possible de partir de rien pour réaliser la méthodologie qui sera la mieux adaptée à
InfoTeam. Cependant, il semble plus judicieux de s’inspirer de l’existant. D’une part car il
n’est quasiment jamais judicieux de réinventer la roue. Et d’autre part, les méthodes existantes
bien que relativement modernes ont été suffisamment éprouvées pour être plus satisfaisantes.
A partir des connaissances acquises suite à l’état de l’art des méthodologies de développement
logiciel (cf. 3.2 Etat de l’art des méthodologies de développement), la méthodologie qui me
semble la plus à même de répondre aux besoins d’InfoTeam résulte d’un mélange entre Scrum
(cf. 3.5.3 Scrum) et eXtreme Programming (cf. 3.5.2 Extreme Programming (XP))
Scrum sera utilisé comme cadre général pour la méthodologie dédiée à InfoTeam. Le choix de
Scrum est en partie dû à sa simplicité qui en fait une méthodologie facile à comprendre et peu
contraignante. De plus, Scrum offre une excellente vision sur le management de projet.
XP sera utilisé comme cœur de la méthodologie plus basée sur les techniques de
développement pures. En effet, Scrum étant un cadre général de management de projet, il est
intéressant de lui appliquer les bonnes pratiques de développement définies dans XP. La
méthodologie définie pour InfoTeam n’appliquera pas XP à la lettre car cela serait trop
contraignant. Par contre, elle utilisera un sous ensemble des bonnes pratiques décrites dans XP
sans les pousser à l’extrême. Cette utilisation des pratiques d’XP sera à adapter à la taille du
projet, la taille de l’équipe, le domaine de développement, ainsi qu’aux contraintes et
exigences du client.
3.7.3 Fonctionnement de base
La Figure 28 représente le fonctionnement de Scrum:
Figure 28 Fonctionnement de Scrum [W104]
Tous les composants de Scrum ainsi que les avantages de son utilisation seront introduits
dans les chapitres suivants.
Définition d’une méthodologie de développement
70 / 149
Le « Product Backlog » correspond aux besoins du client (fonctionnels et non-fonctionnels).
Il n’est déterminé qu’après avoir réalisé toutes les étapes précédant le chapitre «Validation de
la prise en main d’un mandat» décrit dans le Manuel qualité d’InfoTeam [B17]. Il faut donc
avoir déjà réalisé une offre, reçu une commande, avoir initialisé le mandat et avoir mis en
place le cahier des charges. Ce cahier des charges devra être aussi précis que possible pour
éviter d’avoir des malentendus avec le client sur les fonctionnalités, les délais et le coût. La
première version du « Product Backlog » sera déterminée en prenant les exigences décrites
dans le cahier des charges.
Le principe de base de Scrum est de focaliser l’équipe sur un ensemble de tâches à réaliser
« Sprint Backlog » durant une itération appelée « Sprint » durant théoriquement 30 jours.
Dans la pratique ces itérations ont une durée de l’ordre de 2 à 4 semaines. Pour déterminer la
durée d’un « Sprint » des critères tels que la taille de l’équipe et celle du projet seront pris en
compte. Dès que la durée du « Sprint » est déterminée, elle reste inchangée pour toute la
durée du projet. Ce qui permet d’avoir des dates d’échéance précises et stables.
Comme dans la plupart des cas, il y aura plusieurs itérations, seulement un certain nombre
d’items du « Product Backlog » seront considérés durant une itération. Ces items du
« Product Backlog » choisi pour le « Sprint » seront découpés en tâches. Ces tâches devront
être assez simplifiées pour être réalisables en quelques heures. Cela permettra d’améliorer
empiriquement les estimations. L’expérience a montré qu’une tâche nécessitant plus de deux
jours de travail n’est que très rarement estimée correctement. Le regroupement de ces tâches
représente le « Sprint Backlog » de la Figure 28.
Le « Sprint » aboutit à un « produit partiellement utilisable ». Cela signifie que toutes les
parties de la réalisation, des tests et de la documentation doivent être réalisées durant le
« Sprint ». Toutes ces parties doivent donc se retrouver dans le « Sprint Backlog » introduit
précédemment.
Pour garantir une bonne communication au sein de l’équipe, une petite réunion quotidienne la
« Scrum Meeting » sera réalisée. Cette réunion d’une quinzaine de minutes permettra
d’informer l’ensemble de l’équipe de l’avancement global du projet ainsi que des problèmes
rencontrés.
Le « produit partiellement utilisable » sera évalué à la fin du « Sprint » par une
démonstration au client et éventuellement une livraison à quelques clients.
Ces étapes (définition du « Sprint Backlog », réalisation du « Sprint » et de la
démonstration) sont réitérées jusqu’à l’obtention de la satisfaction du client qui, en règle
générale, coïncidera avec un « Product Backlog » vide.
Définition d’une méthodologie de développement
71 / 149
3.7.4 Apports au fonctionnement de base
Le fonctionnement de base de la méthodologie proposée et très similaire à Scrum. Néanmoins
un certain nombre d’améliorations et d’adaptations ont été réalisés pour rendre cette
méthodologie applicable par InfoTeam. En effet, le descriptif détaillé fournit à InfoTeam
comprend pas moins de 24 conseils d’utilisation et 14 compléments d’informations sur les
besoins que cette méthodologie couvre.
Pour ne pas être en conflit avec le NDA (Non-disclosure agreement) signé entre l’université
de Fribourg et l’entreprise InfoTeam, il ne m’est pas possible de citer toutes les adaptations
réalisées. Cependant je vais tout de même en présenter trois.
3.7.4.1 Planning Poker
La première adaptation est relative à la planification du projet. La planification du projet est
souvent la phase critique d’un projet. En effet, durant cette phase l’estimation du temps et des
ressources nécessaires à l’élaboration du projet est réalisée. Cette estimation est ensuite
présentée au client sous forme d’offre. Le point critique de cette phase est clairement le fait
que l’estimation n’est pas toujours exacte. Si elle était trop petite, les frais de dépassement
seront à la charge de l’entreprise et le client sera mécontent d’attendre une solution qui lui
avait été promise en un temps plus court. Le cas de figure inverse, à savoir une estimation trop
grande, n’engendre aucun problème. Malheureusement ce cas de figure n’arrive quasiment
jamais. En effet, on essaie dans la pratique de faire au plus juste pour ne pas se faire prendre le
contrat par un concurrent.
L’estimation est donc une tâche difficile et qui demande de l’expérience. Pour réduire les
risques d’une mauvaise estimation une pratique dite de planning poker a été proposée. Cette
pratique part du principe selon lequel la personne qui va réaliser le projet est la plus à même
d’estimer le temps que cela lui prendra. De plus, cette pratique part du principe que plus il y a
d’avis plus l’estimation sera juste. Mais il ne faut pas non plus tomber dans l’extrême et
perdre du temps en faisant les estimations. Une estimation n’est bonne uniquement si elle n’a
pas fait perdre de temps à l’équipe et qu’elle est le plus proche possible de la réalité.
Le déroulement du planning poker est le suivant. L’ensemble de l’équipe se réuni pour réaliser
un petit jeu d’estimation. Chaque membre de l’équipe dispose d’une main de carte
représentant les valeurs possibles pour l’estimation des items du Product Backlog. Le Scrum
Master explique l’item du Product Backlog (une des exigences du client). Une petite
discussion a lieu si le besoin n’est pas compris. Chaque membre de l’équipe dépose face
cachée sur la table la carte représentant son estimation de l’exigence. Ensuite toutes les cartes
sont retournées en même temps. S’il n’y a pas un compromis immédiat, la personne dont
l’estimation est la plus faible et à la personne dont l’estimation est la plus forte expriment
Définition d’une méthodologie de développement
72 / 149
leurs points de vue. Si un compromis est rapidement trouvé, la valeur issue de celui-ci est
utilisée sinon la valeur la plus grande est prise en compte.
Pour faciliter ces estimations, un compromis est réalisé sur une exigence du client de taille
moyenne. Afin de parfaire la technique de planning poker, une estimation par analogie y sera
intégrée. A la fin de l’estimation d’une exigence, celle-ci sera collée sur un tableau dans la
colonne correspondante à son estimation. Cela permettra aux membres de l’équipe d’estimer
par analogie les exigences suivantes.
3.7.4.2 Prise en compte d’un bug
Souvent lors du développement d’une solution s’étalant sur plusieurs versions, les versions
suivantes prennent en compte des améliorations et des ajouts. Mais comme dans la plupart des
produits informatiques, leurs utilisations quotidiennes mettent en évidence certains défauts
non détectés durant le développement. Ces défauts couramment appelés bugs doivent la
plupart du temps être résolus le plus rapidement possible. En effet, dès qu’un problème mineur
est décelé par un utilisateur il devient subitement son centre d’intérêt et celui-ci n’est donc
plus à même d’utiliser les autres fonctionnalités du système.
Pour palier à ce problème et dans le but de répondre le plus rapidement possible aux exigences
des clients, il est fréquent de voir dans les planifications une marge réservée à la correction
des bugs de la version précédente. Cette marge part d’une bonne intention mais elle pose deux
problèmes majeurs.
Le premier vient lorsque cette marge n’est pas assez importante car un grand nombre de
défauts son découverts. A ce moment là, il n’est pas possible de les corriger tous, ce qui
entraîne inévitablement la non-satisfaction du client. Ou alors des ressources supplémentaires
sont engagées pour la correction de ces bugs ce qui provoquera inévitablement des coûts
supplémentaires.
Le deuxième problème intervient dans la situation inverse. A savoir la surestimation de cette
marge. Cela ne semble pas poser de problème, mais en regardant de plus près on s’apercevra
que lorsque cette marge est surestimée, le temps prévu pour la correction des bugs est gaspillé
en travail inutile ou encore pire pour l’employeur en inactivité.
Pour prendre en compte ces bugs dans la méthodologie aucune marge ne sera définie afin
d’éviter les problèmes précédemment cités. Mais lorsque un bug est découvert les étapes
suivantes devront être réalisées :
1. Le Scrum Master réunit l’équipe pour estimer la prise en compte du bug. Cette
estimation est réalisée de la même manière identique à l’estimation d’un item du
Product Backlog (Planning Poker).
Définition d’une méthodologie de développement
73 / 149
2. Le Scrum Master communique ces informations au Product Owner.
3. Si le Product Owner veut que l’équipe prenne en compte le bug durant le Sprint, il retire
des items non commencés du Sprint Backlog pour un nombre de points équivalent à
l’estimation du bug. Sinon le bug ne sera pris en compte que lors d’un Sprint suivant.
Cette technique apporte plusieurs avantages. Le premier incombe au fait que les estimations
sont les plus proches possible de la réalité et n’intègrent pas des marges aléatoires. Les
problèmes précédemment cités n’ont plus lieu d’être. Et pour finir, le client ne se focalise plus
sur des petits détails fonctionnels mais réellement sur les aspects qui ont un véritable intérêt
pour lui.
Cette opération doit néanmoins être réalisée uniquement pour des bugs urgents, car elle aura
indéniablement une répercussion négative sur la vélocité de l’équipe et donc sur les
fonctionnalités livrées à la fin du Sprint.
3.7.4.3 Scrum meeting
La pratique de Scrum étant à mon sens la plus importante est le Scrum Meeting. Il s’agit d’une
petite réunion quotidienne avec tous les membres du projet afin de contrôler le bon
déroulement de celui-ci. Cela permet à tous les membres d’avoir une vision globale du projet
et d’exprimer leurs travails et leurs problèmes. Ce qui a indéniablement un effet positif sur
l’esprit d’équipe et sur la motivation du projet. Pourtant cette pratique n’est pas facile à mettre
en œuvre, car pour être optimale cette réunion doit se dérouler tous les jours avec tous les
membres de l’équipe et en peu de temps. Afin de faciliter cette pratique quelques petits
conseils ont été introduits à Scrum. Tout d’abord, le Scrum Master fait office d’animateur de
la séance. Il aura comme rôle de poser les trois questions suivantes à chaque membre de
l’équipe :
1. Qu’as-tu fait depuis la dernière fois ?
2. Que prévois-tu de faire jusqu’à la prochaine réunion ?
3. Qu’est-ce qui pourrait t’empêcher d’y arriver ?
Il devra dès lors éviter que la réponse à ces questions ne parte en débat. En effet, lors d’un
Scrum meeting uniquement la personne à laquelle le Scrum Master a posé les questions est
autorisée à parler. Afin de faciliter cette approche, l’utilisation d’une mascotte a été proposée.
Cette mascotte est passée d’un membre de l’équipe à l’autre au fur et à mesure de
l’avancement de la réunion. Cette pratique assez ludique tend à améliorer l’ambiance au sein
de l’équipe.
Définition d’une méthodologie de développement
74 / 149
Une autre pratique proposée afin de faciliter le déroulement de ce meeting est l’utilisation
d’un tableau. Ce tableau servant d’appui visuel sur lequel toutes les tâches du Sprint sont
réparties en différentes catégories.
Lors de son tour de parole, le membre de l’équipe déplace les post-it représentant les tâches
pour lesquels il est en train de réaliser du travail. Cela est assez intéressent car cela permet de
faire remarquer que lors de l’utilisation de cette méthodologie les tâches ne sont pas forcément
imposées aux membres de l’équipe mais ceux-ci les choisissent pendant le Scrum Meeting.
3.7.5 Conclusion
Comme précisé précédemment il reste encore 11 autres conseils d’utilisation qui ont été
prescris dans la méthodologie de développement proposée à InfoTeam.
De plus, InfoTeam peut tirer les avantages suivants de l’utilisation de cette méthodologie :
• Adaptée aux exigences : Les exigences du client sont réellement prises en compte
et le prototype développé répond effectivement à ces
exigences.
• Motivation : La méthodologie est agile et donc basée sur les individus
plus que sur le processus lui-même ce qui a comme
conséquence directe un accroissement de la motivation de
l’équipe. De plus, un certain nombre de concepts tels que
le planning poker sont bien adaptés à renforcer l’attrait de
la méthodologie et donc l’envie de l’équipe.
• Qualité : L’introduction de concepts tels que les tests unitaires,
l’intégration continue, le refractoring aide à améliorer la
qualité des solutions développées.
• Risques : Le développement incrémental ainsi que les graphiques de
suivi d’avancement permettent la réduction des risques.
Enfin, la méthodologie réalisée pour InfoTeam répond à tous les besoins cités dans le point
d’introduction.
Définition de la procédure de test
75 / 149
4. Définition de la procédure
de test
“A test that reveals a bug has succeeded, not failed.”
Boris Beizer
Définition de la procédure de test
76 / 149
4.1 Introduction
Tout d’abord commençons par une petite définition [B6]:
Test n. m. (Anglicisme). 3. Épreuve, expérience qui permet de se faire une opinion sur
quelqu’un, sur quelque chose.
Dans le cas plus concret du développement logiciel, les tests sont l’étape du cycle de
développement logiciel qui permet d’atteindre un certain niveau de qualité.
Voici quelques définitions spécifiques au domaine du logiciel :
« Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des
moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou
identifier les différences entre les résultats attendus et les résultats obtenus. » [B13]
« Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou
des défauts. » [B14]
« Testing can reveal the presence of errors but never their absence. » [B11]
« Le processus de test consiste en une collection d’activités qui visent à démontrer la
conformité d’un programme par rapport à sa spécification. Ces activités se basent sur
une sélection systématique des cas de test et l’exécution des segments et des chemins
du programme. » [B15]
« L’objectif du processus de test est limité à la détection d’éventuelles erreurs d’un
programme. Tous les efforts de localisation et de correction d’erreurs sont classés
comme des tâches de débogage. Ces tâches dépassent l’objectif des tests. Le processus
de test est donc une activité de détection d’erreurs, tandis que le débogage est une
activité plus difficile consistant en la localisation et la correction des erreurs
détectées. » [B16]
Il n’existe pas réellement de processus de test clairement défini en tant que tel. Le plus
souvent, le processus du test n’est rien d’autre qu’une sous-partie de la méthodologie de
développement logiciel. Par exemple, la méthodologie Rational Unified Process
(RUP)[W148] définit un certain nombre de documents pour les tests. D’autres méthodologies
telles que Extreme Programming (XP)[W149] sont grandement basées sur les tests. En effet,
la méthodologie XP introduit le concept de Test-Diven Development (TDD)[W151]. Le TDD
consiste en l’écriture des tests avant de réaliser le code lui-même.
En conséquence, les processus de test ne sont rien d’autre qu’un principe découlant du cycle
de développement logiciel. De plus, ils sont spécifiques à la méthodologie utilisée. Ils doivent
être vus comme un processus d’investigation plutôt que le suivi d’une procédure.
Définition de la procédure de test
77 / 149
Cependant, indépendamment de la méthodologie de développement utilisée, le concept de
Validation/Vérification (V&V) revient sans cesse dans le domaine des tests logiciel. D’autres
concepts sont aussi souvent cités tels que les tests unitaires, les tests d’intégration, les tests du
système, les analyses statiques, les analyses dynamiques, les tests boîtes noires, les tests boîtes
blanches,… Les tests étant sans conteste une partie primordiale du développement logiciel, ces
concepts seront approfondis dans les chapitres suivants.
Les tests peuvent avoir deux intérêts distincts ; la mise en évidence d’un problème ou
l’information vis-à-vis d’une des métriques suivantes :
• Utilisabilité : Aptitude du logiciel à être compris, appris, utilisé et attrayant
par/pour les utilisateurs.
• Compatibilité : Aptitude du logiciel à pouvoir être combiné à d’autres logiciels.
• Maintenabilité : Aptitude du logiciel à être facilement modifié.
• Portabilité : Facilité d’un logiciel à être porté sur de nouveaux environnements
matériels et/ou logiciels.
• Efficacité : Aptitude du logiciel à bien utiliser les ressources matérielles
(mémoire, CPU, devices).
• Robustesse : Aptitude du logiciel à rester fonctionnel même dans des conditions
anormales extrêmes.
• Fonctionnalité : Aptitude du logiciel à fournir des fonctions qui répondent à des
besoins explicites ou implicites.
• Réutilisabilité : Aptitude du logiciel et de ses composants à être réutilisés pour de
nouvelles applications.
Un test est donc réussi, s’il découvre une erreur ou s’il informe sur une des métriques
précédemment citées. Souvent lors du développement logiciel uniquement une sous partie de
ces métriques est prise en compte.
Finalement, les tests permettent de mettre à jour des erreurs, mais malheureusement ils ne
permettent pas d’affirmer qu’il n’y a pas d’erreur. De plus, ils ne localisent et ne résolvent pas
non plus les problèmes découverts, cela étant fait dans une étape de débogage.
Définition de la procédure de test
78 / 149
4.2 Etat de l’art des procédures de test
Comme introduit précédemment, les processus de tests sont souvent dépendants de la
méthodologie de développement logiciel. Ce document ne produira donc pas un descriptif des
processus de tests mais plutôt des principes qui sont inclus ou issus de ces processus.
Il est aussi nécessaire de préciser que les processus de tests mis en œuvre lors d’un
développement logiciel ne servent qu’à déterminer d’éventuelles erreurs. En aucun cas, le
processus de test ne corrigera l’erreur. De plus, le test d’un programme permet de mettre en
évidence un éventuel bug, mais il ne permet pas de prouver l’absence de bug. En effet, il est
pratiquement impossible de vérifier tous les cas d’utilisation d’un système complexe
(problématique des chemins). Tout comme il est impossible de tester toutes les valeurs
d’entrée (ex. fonction d’addition de 2 Int de 32 bits à raison de 1000 tests par seconde)2.
D’autres constats sont à faire vis-à vis des tests, notamment la tendance visant à repousser la
réalisation des tests le plus tard possible par manque de temps. Ce qui est en contradiction
avec la règle qui veut que le coût d’un changement évolue en fonction du temps [W100].
Figure 29 Coût d'un changement en fonction du temps
Les tests devraient donc être réalisés le plus rapidement possible.
2 années 000000558 25,3652460601000
2 3232′′=
⋅⋅⋅⋅+
Définition de la procédure de test
79 / 149
4.2.1 Vérification versus validation
La vérification et la validation incluent toutes les activités permettant de s’assurer au mieux
que le logiciel créé corresponde aux spécifications et que les spécifications répondent aux
besoins du client. Même si ces mots sont très proches phonétiquement, leurs sens diffèrent
grandement. Boehm leur donna une interprétation simple en 1979 :
Validation : Construisons-nous le bon produit ?
Vérification : Le construisons nous bien ?
La partie vérification contrôle donc la conformité entre le logiciel créé et ses spécifications.
Tandis que la validation permet au client de confirmer que le logiciel correspond à ses
attentes.
Ce processus de vérification/validation avait lieu tout à la fin avec les méthodologies de
développement logiciel suivant le modèle en cascade. Cependant avec l’arrivée des
méthodologies de développement agile, ce processus est appliqué tout au long du
développement.
Figure 30 Processus de Vérification - Validation
Définition de la procédure de test
80 / 149
4.2.2 Tests « boîte blanche » vs tests « boîte noir e »
Les tests « boîte noire » considèrent le système à tester comme une boîte dont les seules
informations connues sont les entrées et les sorties. Le fonctionnement interne de la boîte est
totalement inconnu. La seule chose qui est alors testable est le fait que le résultat obtenu pour
une entrée donnée est conforme à notre attente. Il n’est donc en aucun cas possible de tester la
façon dont le résultat est obtenu. De plus, les entrées doivent être choisies pour être les plus
représentatives possibles du domaine. Car il ne sera pas possible d’être exhaustif.
Les tests « boîte blanche » testent un système dont la totalité du fonctionnement interne est
connue. Cela permet au développeur de réaliser les tests en étant conscient de la structure
interne du programme. En connaissant la structure interne d’un programme il est possible de
déterminer les chemins possibles (cela devient difficile pour des programmes complexes) au
travers de ce programme et de les tester. Ces tests ne visent donc pas les fonctionnalités du
système, mais l’aspect structurel (le détail de l’implémentation « Structure du programme »).
Finalement, les tests « boîte noire » vérifient ce qu’est censé faire le programme tandis que les
tests « boîte blanche » vérifient ce qu’il fait réellement.
Souvent les tests « boîte noire » sont aussi nommés « Test fonctionnel » car ils ne testent que
le fonctionnement du logiciel. Les tests « boîte blanche » se nomment « Test structurel » car
ils permettent un accès direct à la structure du code.
Figure 31 Boîte noire vs Boîte blanche
Définition de la procédure de test
81 / 149
4.2.3 Analyse statique vs analyse dynamique
Deux types d’analyse sont principalement effectués durant la phase de vérification.
Les analyses statiques de code permettent d’étudier le logiciel sans l’exécuter. Elles sont
utilisées en particulier pour assurer une normalisation du code produit, une revue de code, …
Les analyses dynamiques de code requièrent quand à elles l’exécution du logiciel. Elles sont
utilisées en particulier pour l’analyse des performances dans le but de déterminer les parties du
programme qui doivent être optimisées.
En outre, l’analyse dynamique peut permettre de faire une corrélation entre les tests « boîte
noire » et les tests « boîte blanche ». En effet, il est possible d’effectuer les Tests fonctionnels
(boîte noire) puis avec une analyse dynamique appelée « couverture de code » de contrôler la
partie structurelle (boîte blanche) et ainsi d’adapter les tests en conséquence.
La couverture de code met en évidence les lignes de code qui ont été parcourues durant les
tests.
Figure 32 Exemple couverture de code sous Microsoft Visual Studio Team System
Définition de la procédure de test
82 / 149
4.2.4 Les niveaux et types de tests logiciels
Dans la grande majorité des cas, les tests sont structurés de manière ascendante. En partant des
tests de petits modules (tests de composant) puis les tests des sous-systèmes (tests
d’intégration) jusqu’aux tests du système global (tests systèmes). Ce sont les principaux
niveaux d’un processus de test logiciel. Néanmoins il existe un certain nombre d’autres tests,
tels que des tests de performance qui peuvent être réalisés durant les différents niveaux
précédemment cités. Les tests de validation ou tests de recette, qui permettent à l’utilisateur
final de contrôler que le logiciel corresponde à ses attentes, peuvent aussi être inclus. Ces tests
de validation et de recette sont propres à la partie validation tandis que les autres tests font
partie de la vérification du chapitre 4.2.1.
D’autres types de tests souvent cités sont les tests de non-régression. Selon moi, il n’existe pas
de type de test de non-régression. En effet, c’est en fait l’exécution de tous les tests
précédemment définis sur une nouvelle version d’un logiciel qui contribue à la non-régression
de celui-ci. Ces tests de non-régression permettent de s’assurer qu’une modification ou qu’un
changement d’environnement n’a pas introduit de nouveaux défauts. Tous les types de tests
peuvent donc être assimilés à des tests de non régression si ceux-ci sont effectués lors d’une
nouvelle version du système.
Dans les sous chapitres suivants un descriptif de ces différents types de test est réalisé.
4.2.4.1 Tests unitaires (Tests de composant)
Ces tests sont les tests du niveau le plus bas, ils permettent de tester chaque module ou
composant de l’application séparément. Ils sont réalisés par le développeur lui-même ce qui
les oriente fortement en tests boîte blanche. Dans la programmation orientée objet, ils
permettent de contrôler le bon fonctionnement des méthodes d’une classe une à une. Ils sont la
plupart du temps basés sur le principe d’assertion. Le principe d’assertion permet de contrôler
que l’invocation d’une méthode nous donne le résultat escompté en fonction des paramètres
passés. Cette technique est relativement simple car la complexité globale est supprimée en
focalisant notre attention sur un composant. De plus, en utilisant cette méthode, les erreurs
deviennent plus faciles à cibler. Néanmoins ce type de test est plus complexe lorsqu’il y a un
couplage fort entre les composants.
Définition de la procédure de test
83 / 149
using System; using System.Collections.Generic; using System.Text; namespace BankAccountDemo.Business { public class BankAccount { // Properties private float _currentBalance; public float CurrentBalance { get { return _currentBalance; } } // Constructors public BankAccount(float initialBalance) { this._currentBalance = initialBalance; } // Methods public void DepositMoney(float depositAmount) { this._currentBalance += depositAmount; } public void MakePayment(float paymentAmount) { this._currentBalance -= paymentAmount; } } }
using BankAccountDemo.Business; using Microsoft.VisualStudio.QualityTools.UnitTesting.Framework; namespace BankAccountDemo.Business.Tests { [TestClass()] public class BankAccountTest { [TestInitialize()] public void Initialize() { } [TestCleanup()] public void Cleanup() { } [TestMethod()] public void ConstructorTest() { float currentBalance = 500; BankAccount target = new BankAccount(currentBalance); Assert.AreEqual(currentBalance, target.CurrentBalance, "Balances are not equal upon creation"); } [TestMethod()] public void DepositMoneyTest() { float currentBalance = 500; BankAccount target = new BankAccount(currentBalance); float depositAmount = 10; target.DepositMoney(depositAmount); Assert.IsTrue( (currentBalance + depositAmount) > target.CurrentBalance, "Deposit not applied correctly"); } [TestMethod()] public void MakePaymentTest() { float currentBalance = 500; BankAccount target = new BankAccount(currentBalance); float paymentAmount = 250; target.MakePayment(paymentAmount); Assert.IsTrue(currentBalance - paymentAmount == target.CurrentBalance, "Payment not applied correctly"); } } }
Tableau 7 Exemple de test unitaire sous Microsoft Visual Studio Team System
Figure 33 Résultat de l'exécution des tests unitaires
Définition de la procédure de test
84 / 149
4.2.4.2 Tests d’intégration
Ce type de test est effectué au niveau supérieur des tests unitaires. En effet, ces tests visent à
contrôler les interactions entre différents modules ou composants de l’application en les
intégrant au sein d’un sous-système. Ces tests ne sont plus vraiment des tests en boîte blanche
la structure interne de chaque composant n’est pas nécessairement connue, néanmoins, la
connaissance de la structure modulaire et des interfaces des composants est nécessaire. Le
terme test en boîte grise est alors utilisé.
4.2.4.3 Tests du système
A ce stade, les tests sur les composants (tests unitaires) ont été réalisés, puis ces composants
ont été assemblés en sous-systèmes qui ont été testés (tests d’intégration). Dès lors, il ne reste
plus qu’à tester le système dans sa globalité à l’aide des tests du système. Ces tests sont de
type boîte noire et visent à assurer l’acceptation de l’application développée par les
utilisateurs.
4.2.4.4 Tests de performance
Ce genre de test n’est réellement utile que pour certains types de logiciels en particulier les
systèmes travaillant en temps réel. Toutefois, si un niveau de performance est requis, il est
possible d’effectuer des tests de performance dans tous les niveaux précédemment décrits. Un
certain nombre d’outils tels que des profiler de code permettent de mettre en évidence quelles
méthodes ont été appelées, ainsi que le temps d’exécution de ces méthodes durant les tests ou
la quantité de mémoire utilisée. Cela permet de cibler les problèmes de performance et donc
d’optimiser les composants spécifiés.
Figure 34 Exemple du Profiler de code sous Microsoft Visual Studio Team System
Définition de la procédure de test
85 / 149
4.2.4.5 Tests de validation (tests de l’usager, re cette)
Ces tests sont, en principe, la dernière phase de test. En effet, ce stade n’est atteint uniquement
lorsque tous les niveaux de tests précédents ont été passés. Les tests des niveaux précédents
ayant été effectués sans le client, ils ont établis que le logiciel est fonctionnel et qu’il répond
aux spécifications. Maintenant les tests de validation vont permettre d’avoir la vision de
l’utilisateur final qui est, malheureusement, souvent différente de la vision du développeur. Ils
mettront en évidence certains points de spécification qui n’étaient pas compris de la même
manière par l’utilisateur et le développeur. C’est pour ces raisons qu’ils doivent être effectués
le plus tôt possible. Finalement, ils valideront le logiciel par rapport aux besoins de
l’utilisateur. Ce qui aboutira sur l’acceptation, l’acceptation conditionnelle ou le refus du
produit.
4.2.5 Cycle de test d’un développement logiciel
Le cycle se décompose principalement en quatre :
• Planification des tests.
• Exécution de tests pertinents sur le programme et observation de son comportement.
• Comparaison du comportement observé (Résultats effectifs) avec le comportement
attendu (résultats attendus définis lors de la planification).
• Déboguer (localisation et correction de l’erreur).
Ce cycle est montré dans la Figure 35:
Figure 35 Cycle de test
Ces parties sont de même priorité et ne sont valides que si les autres parties sont réalisées.
Définition de la procédure de test
86 / 149
4.2.5.1 Planification
La planification des tests doit intervenir à tous les stades du développement. Selon les
méthodologies de développement logiciel agiles, les tests sont extrêmement importants. Des
méthodologies sont même conçues uniquement sur la notion de test « Test Drivent
Development (TDD) », d’autres intègrent les tests comme une bonne pratique de
développement « Extreme Programming (XP) ». Néanmoins, dans toutes ces méthodologies
un principe est toujours présent « Le développement des tests doit avoir lieu avant le
développement de l’application ». Ce principe peut sembler étrange de prime abord, mais la
pratique montre qu’il s’avère fort efficace. En effet, la pré création des tests permet de se
pencher plus en détail sur les aspects d’interfaçage et d’abstraction ce qui garanti une
meilleure approche lors de la création de la logique métier. Dans la planification, il faut donc
tenir compte du fait que les tests doivent, dans la mesure du possible, être développés avant le
code. Un autre avantage non négligeable de cette pratique vient du fait que souvent, dans la
pratique si les tests ne sont pas créés avant le code, ils sont omis faute de temps.
La planification des tests permet de spécifier qui effectuera le test à quel moment et ce qui doit
être testé. Cette planification dépend aussi du type de test (voir Figure 36) :
• Tests unitaires : Ce type de test est planifié par le développeur et doit être
incorporé dans le temps de développement d’un composant.
• Tests d’intégration : Là aussi le test est effectué par les développeurs et sa création
doit être intégrée dans le développement des composants.
• Tests du système : Les tests du système doivent refléter le fonctionnement des
exigences. Ils sont aussi réalisés par les développeurs mais les
conditions d’acceptation sont définies par le client.
• Tests de performance : Ils sont aussi définis par le client et réalisés par les
développeurs.
• Tests de recette : Ces tests sont décrits et réalisés par le client.
Figure 36 Planification des tests
Définition de la procédure de test
87 / 149
4.2.5.2 Exécution
L’exécution des tests doit être aussi automatisée que possible pour ne pas entraver le travail du
développeur.
Il est totalement insensé de créer une multitude de tests inutiles. Un test ne sera nécessaire que
s’il teste une nouvelle partie du programme. Si dix tests sont exécutés mais qu’ils ne testent
qu’une seule partie du logiciel, un seul test aurait été nécessaire.
L’exécution des tests demande l’utilisation de données d’entrée. Il est donc important de
réaliser les tests avec des données d’entrée pertinentes. Pour cela le principe dit de
partitionnement qui vise à catégoriser les entrées (une catégorie groupe des valeurs d’entrée
censées produire le même comportement) est utilisé. Par exemple le test d’un composant
stipulant que les données d’entrée sont des entiers à cinq chiffres, le partitionnement pourrait
regrouper les trois classes suivantes ; c1="n<10000", c2="10000<=n<=99999", c3="n>99999".
Il suffit ensuite de tester un seul cas par classe. Une autre optique d’optimisation de la
pertinence des tests est l’introduction de la notion de test aux bornes. Le plus grand nombre
d’erreurs se trouvent dans les valeurs limites d’entrée. Il est alors intéressant d’effectuer un
certain nombre de tests ayant des valeurs d’entrée entourant les limites du système. Pour
l’exemple précédent les valeurs d’entrées limites seraient (i1=9999, i2=10000, i3=99999,
i4=100000). Cela permet de tester le bon fonctionnement du programme (avec des valeurs
incluses limites) ainsi que la robustesse de celui-ci (avec les valeurs d’entrée invalides).
4.2.5.3 Comparaison
La partie comparaison permet de dépouiller les résultats de l’exécution pour définir le succès
ou l’échec des tests. Comme défini dans la partie planification, les conditions d’acceptation
sont définies par les développeurs (tests unitaires, tests d’intégration) et par le client (tests du
système, tests de performance, tests de recette). En partant de ces conditions d’acceptation, les
résultats d’exécution prévus doivent être définis afin de les comparer avec les résultats
obtenus.
Il faut aussi faire la nuance entre tests réussi et échecs. Tout étant assez relatif, un test réussi
peut-être soit un test qui met en évidence le bon fonctionnement d’un composant soit un test
qui met en évidence un bug. Car le but d’un test étant d’atteindre une certaine qualité, la mise
en évidence d’un bug permet sa résolution et donc l’augmentation de la qualité du programme.
4.2.5.4 Déboguer
Cette phase ne fait pas, à proprement parler, partie des tests. En effet, les tests sont là pour
mettre en évidence un défaut du système ou pour donner un renseignement sur une métrique
Définition de la procédure de test
88 / 149
de qualité. Suite à la mise en évidence d’un défaut dans le système, il serait sûrement
intéressant de pouvoir prendre en compte ce défaut dans l’optique de le corriger. La phase
déboguer consiste en la prise en compte du défaut. Elle est composée d’une phase de
localisation du défaut et d’une phase de correction de l’application pour corriger ce défaut.
4.3 Processus utiles à une PME
Il est difficile de mettre en place un processus adapté pour une entreprise. En effet, le
processus de test est extrêmement dépendant du projet. Néanmoins certaines valeurs
fondamentales ont été recommandées pour InfoTeam :
4.3.1 Tester avant de développer
La réalisation des tests avant de développer un composant ou un module est certainement la
meilleure pratique de développement incluse dans les méthodologies agiles. Elle améliore la
qualité des composants créés et elle garanti la mise en place des tests.
4.3.2 Tester que si nécessaire
L’un des principes essentiels du développement agile est la simplicité. Ce principe peut être
dispensé dans les processus de test. En effet, il ne sert à rien d’effectuer un grand nombre de
tests si ceux-ci n’apportent pas une plus-value. De plus, tout ne doit pas être forcément testé.
Par exemple, un test unitaire d’une classe ne doit pas être forcement exhaustif en testant toutes
les méthodes. Certaines méthodes n’ont pas besoin d’être testées soit parce qu’elles ne
correspondent pas à une fonction métier ou qu’elles sont peu complexes (p. ex. getter/setter).
4.3.3 Pertinences des tests
Un test n’est utile que s’il est pertinent. Il faut donc bien réfléchir sur les données soumises en
input aux tests (partitionnement des données [W139]) ainsi qu’au différents cas de tests à
prévoir. Il n’est pas rare de constater qu’un certain nombre de cas de test sont omis. Par
exemple, « the art of software testing » [B14] met en évidence le développement d’un
programme qui détermine le type d’un triangle (scalène, isocèle ou équilatéral) en fonction des
longueurs de ses trois cotés. Ce programme ne parait pas forcément compliqué pourtant 14 cas
de tests ont pu être définis en se référant aux problèmes constatés dans des implémentations
réalisées par des développeurs expérimentés. En moyenne 7.8 cas de tests ont été passés par
les implémentations réalisées. Cela montre la complexité des tests mais aussi qu’une réflexion
pertinente sur les entrées de tests permet de mettre en lumière un plus grand nombre de
défauts.
Définition de la procédure de test
89 / 149
4.3.4 Tests de non régression
Pour les projets s’étalant sur plusieurs versions, il est nécessaire de mettre en place un système
de tests de non-régression. Les tests de non-régression sont l’activation de tous les types de
tests précédemment discutés (unitaire, intégration, système,…) lors de la modification du code
source. Ces tests permettent de s’assurer qu’une modification du programme ne crée pas de
défauts dans le système déjà testé.
Projet pilote
91 / 149
5. Projet pilote
“Good customer relations double productivity.”
Larry Bernstein
Projet pilote
92 / 149
5.1 Introduction
Suite à la définition d’une méthodologie de développement pour InfoTeam, il semble naturel
de la mettre à l’épreuve sur un projet concret. Cette mise à l’épreuve permettra de contrôler si
la méthodologie définie est bien adaptée au contexte d’InfoTeam et si un certain nombre de
modifications doivent encore y être apportées pour garantir son utilisabilité.
Le projet proposé est interne à l’entreprise InfoTeam et plus précisément à l’unité Energie. Ce
projet était prévu depuis un certain temps, mais il n’avait jusqu’à présent pas pu être effectué
faute de temps et de ressources. Ce projet s’adapte bien à la situation car il peut être développé
par un petit groupe en un laps de temps réduit.
Les chapitres suivants permettront d’introduire le projet réalisé, puis de décrire les différentes
étapes de la méthodologie mise en œuvre.
5.2 Description du projet
Après avoir développé un produit de contrôle-commande de poste haute tension, la société
InfoTeam SA a la charge d’assurer la maintenance et le suivi de ce produit dans les différents
postes dans lesquels il est installé. Pour effectuer cette tâche de manière efficace, InfoTeam
SA propose de développer une application web liée à une base de données contenant toutes les
informations relatives à chaque poste.
Cette application devra aussi bien gérer le suivi des versions installées dans chaque poste que
les données techniques du hardware, les données administratives liées à l’installation, les
données géographiques ou les personnes responsables du site.
Une interface conviviale permettra de visualiser les données poste par poste ou d’effectuer des
recherches selon des critères prédéfinis et d’afficher les données de manière à avoir une vue
d’ensemble de tous les postes.
Projet pilote
93 / 149
5.3 Les objectifs
Voici une liste un peu plus étoffée des attentes découlant de ce projet :
• Mise en place d’une application de suivi de la maintenance du produit StreamX présent sur des postes à haute tension.
o Accessible par le web.
o Informations stockées et gérées par une base de données.
• Cette application de gestion de la maintenance devra permettre de :
o L’affichage de la liste des postes.
o La recherche d’un poste selon un certain nombre de filtres :
� Recherches prédéfinies.
� Recherches personnalisables.
o L’affichage des données détaillées pour un poste spécifique :
� Nom – Numéro d’affaire – commentaire.
� Informations sur l’accès au poste.
� Informations sur la personne de contact (Choix du client et choix de la personne de contact [liste déroulante]).
� Informations sur l’installation (StreamX et autres logiciels).
� Suivi de la maintenance pour un poste donné (interventions [date, type, participants]).
� Informations sur un certain nombre de données commerciales relatives au poste.
� Informations sur le matériel du poste à haute tension.
� Description de l’installation du poste (+ schéma de principe).
� Adresses IP et nom des différents éléments de l’installation + nom d’utilisateur et mot de passe d’authentification sur les éléments.
o L’ajout d’un poste.
o La suppression d’un poste.
o La modification des données d’un poste.
o La modification des données communes à plusieurs postes (ex : données sur le responsable de maintenance).
Projet pilote
94 / 149
5.4 Mise en place de l’environnement de développeme nt
Afin d’évoluer dans un environnement propice à l’application de la méthodologie proposée,
certains aménagements ont dû être réalisés. Tout d’abord un tableau de bord permettant de
suivre des tâches à effectuer au fil des jours a été mis en place.
Figure 37 Tableau des tâches
Afin de faciliter le planning poker, un jeu de carte avec les valeurs : 5, 10, 15, 20, 30 a été
conçu pour tous les membres de l’équipe.
Un serveur virtuel a été installé avec la partie Serveur de Microsoft Visual Studio Team
System, à savoir Team Foundation Server. De plus, Microsoft Sql Server 2005 et Microsoft
Sharepoint Services y ont aussi été installés. Le plugin de Scrum pour Team System a
également été mis en place sur ce serveur. Toute la description de cette installation est
présente dans les annexes du document [B10].
Un ordinateur portable a été mis à disposition pour réaliser le développement. La version
cliente de Microsoft Visual Studio Team System y a été installée.
Les contraintes posées m’ont amené à faire une légère remise à niveau de mes connaissances
de certaines technologies (C#, ASP.Net et SQL).
Projet pilote
95 / 149
5.5 Mise en place de la méthodologie proposée
5.5.1 Création de l’équipe
Pour ne pas se limiter à réaliser un projet pour réaliser un projet, une équipe de travail devait
être mise en place. En effet, il aurait été inutile que je sois le seul à appliquer la méthodologie
et donc à l’évaluer.
L’équipe de développement mise en place est formée de deux membres, Olivier Neuhaus et
moi-même. J’ai fait office de Scrum master et de membre de l’équipe de développement,
tandis qu’Olivier était membre de l’équipe de développement. Bien que la taille de l’équipe ne
soit pas optimale, le fait d’intégrer un collaborateur lui a permis de se familiariser avec la
méthodologie et de donner son avis sur celle-ci.
Le client était représenté par des collaborateurs d’InfoTeam à savoir Jérôme Page et en
seconde partie de projet Denis Muller.
5.5.2 Cahier des charges
Un petit cahier des charges relatif au projet a été mis en place. Ce cahier des charges est très
sommaire et avait pour but, uniquement la découverte et la rédaction des exigences du client
(il correspond en fait à la liste étoffée en 5.3). Effectivement, la mise en place d’un cahier des
charges concret et très précis n’était pas nécessaire ici car le but de ce projet n’est pas d’avoir
un produit totalement opérationnel mais de valider ou non la méthodologie préconisée.
L’élaboration de ce cahier des charges a néanmoins permis d’aboutir à un Product Backlog
regroupant les vingt exigences du client ordonnées selon leur importance.
Relative Value Backlog Item Name 1 Création de la base de données 2 Ajout d'un poste 2 Création de l'interface graphique générale 3 Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) 4 Affichage de la liste des postes 5 Affichage des données générales d'un poste 6 Affichage des modules du produit StreamX installés sur un poste 6 Affichage de la localisation d'un poste 7 Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 8 Affichage des informations sur l'installation logicielle d'un poste 9 Affichage du suivi de maintenance d'un poste donné 10 Affichage des informations d'accès à un poste 11 Recherches prédéfinies 12 Recherches spécifiques 13 Affichage des personnes de contact pour un poste 14 Affichage de la description de l'installation d'un poste 15 Affichage du matériel d'un poste 16 Affichage des données commerciales sur un poste 17 Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes ex: Personnes de contact) 18 Suppression d'un poste
Tableau 8 Product Backlog after client estimation
Projet pilote
96 / 149
5.5.3 Nombre de Sprints
Comme le temps de développement de cette petite application était limité à 3-4 semaines et
qu’une bonne évaluation de la méthodologie exigeait d’avoir plusieurs itérations, nous avons
décidé de fixer le nombre de Sprints à quatre. Soit un Sprint par semaine de travail.
5.5.4 Phase de planification
Les exigences du client ayant été établies et ordrées selon ses priorités, il a été possible de
passer à l’estimation de leur envergure par les membres de l’équipe. Pour cela la technique
d’estimation par analogie associée au planning poker a été mise en œuvre.
Une réunion de planification a donc eu lieu. Durant cette réunion, j’ai présenté les différentes
exigences à Olivier. Puis nous avons utilisé la méthode préconisée pour estimer ces exigences
en points. Nous avons procédé de la manière suivante :
o Une exigence de taille moyenne a été choisie comme référentielle.
o Les autres exigences ont été estimées à l’aide du planning poker et de la méthode
d’estimation par analogie.
L’estimation des exigences n’a pas posé de problème et la méthode utilisée nous a permis de
réaliser ces estimations en un temps raisonnable. De plus, le coté ludique de cette méthode
d’estimation lui a permis d’être facilement adoptée.
L’estimation des exigences a permis d’aboutir à une version complète du Product Backlog.
Relative Value Backlog Item Name Estimated Effort 1 Création de la base de données 10 2 Ajout d'un poste 5 2 Création de l''interface graphique générale 20 3 Sauvegarde des modifications de données simples (données dépendantes du poste) 15 4 Affichage de la liste des postes 5 5 Affichage des données générales d'un poste 5 6 Affichage des modules du produit StreamX installés sur un poste 5 6 Affichage de la localisation d'un poste 10 7 Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 5 8 Affichage des Informations sur l'installation logicielle d'un poste 5 9 Affichage du suivi de maintenance d'un poste donné 5 10 Affichage des informations d'accès à un poste 5 11 Recherches prédéfinies 10 12 Recherches spécifiques 20 13 Affichage des personnes de contact pour un poste 5 14 Affichage de la description de l'installation d'un poste 5 15 Affichage du matériel d'un poste 5 16 Affichage des données commerciales sur un poste 10 17 Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes) 30 18 Suppression d'un poste 15
Tableau 9 Product Backlog estimé par l'équipe
Comme le nombre de points total est d’environ 200 et que nous avons prévu de faire 4 Sprints,
la vélocité a été fixée à 50 points par Sprint.
Projet pilote
97 / 149
5.5.5 Déroulement des Sprints
5.5.5.1 Sprint 1
Les items suivants ont été choisis pour le premier Sprint :
Relative Value Backlog Item Name Estimated Effort 1 Création de la base de données 10 2 Création de l''interface graphique générale 20 3 Sauvegarde des modifications de données simples (données dépendantes du poste) 15
Tableau 10 Product Backlog du Sprint 1
En début de sprint une réunion a été mise en place pour subdiviser ces items du Product
Backlog en Sprint Backlog (qui représente un raffinement des exigences en tâches de quelques
heures). Le Tableau 11 représente le Sprint et son avancement au fil des jours de la semaine :
Sprint Backlog Id, Name and Owned By 2/7 3/7 4/7 5/7 6/7 000096 Définition de la structure des tables (Yannick Thiessoz) 3 3 0 000097 Création des tables (Yannick Thiessoz) 2 2 0 000098 Création de la hiérarchie d'objets (Yannick Thiessoz) 3 3 0 000099 Classe d'accès à la base de données (Yannick Thiessoz) 1 1 0 000100 Fenêtre de base (Yannick Thiessoz) 3 3 3 3 0 000101 Arborescence "vide" liste des postes (Yannick Thiessoz) 1 1 1 1 0 000102 Fenêtre de login "accès au site" (Yannick Thiessoz) 1 1 3 3 0 000103 Création des éléments de chaque onglet (Yannick Thiessoz) 2 2 2 2 0 000104 Préparation des onglets (Yannick Thiessoz) 2 2 2 2 0 000105 Lien entre sélection dans l'arborescence et l'élément à afficher (Yannick Thiessoz) 1 1 1 1 1 000106 sauvegardes des données générales (Yannick Thiessoz) 1 1 1 1 1 000107 sauvegarde données d'accès "sans image" (Yannick Thiessoz) 1 1 1 1 1 000108 sauvegardes des données commerciales (Yannick Thiessoz) 1 1 1 1 1 000109 sauvegarde des informations matérielles (Yannick Thiessoz) 1 1 1 1 1 000110 sauvegarde information sur le suivi (Yannick Thiessoz) 1 1 1 1 1 000111 sauvegarde info sur les adresses IP (Yannick Thiessoz) 1 1 1 1 1 000112 sauvegarde info sur les contacts (Yannick Thiessoz) 1 1 1 1 1 000113 sauvegarde version streamX (Yannick Thiessoz) 1 1 1 1 1
Tableau 11 Avancement du Sprint 1 (du 2 juillet au 6 juillet)
Le Tableau 11 montre que ce Sprint a pris plus de temps que prévu et que les items du Product
Backlog de sauvegarde des modifications de données simples n’ont pas pu être achevés.
Les deux graphiques proposés par Scrum for Team System nous ont permis de rapidement
nous apercevoir que la totalité des items du Sprint ne pourraient pas être pris en compte.
Figure 38 Sprint 1 Cumulative Flow Diagram
Projet pilote
98 / 149
Liste des postes
Liste des postes Onglets d’un poste Sauvegarde
Figure 39 Sprint 1 Burdown Chart
Il aurait été judicieux (comme le décrit d’ailleurs la méthodologie) de modifier le contenu du
Sprint le mercredi afin de l’adapter à la vélocité réelle de l’équipe. Le premier Sprint n’a pas
eu la vélocité attendue et cela principalement pour deux raisons. La première étant la non prise
en compte du fait qu’une journée de travail avait été dédiée à la mise en place de la
méthodologie (installation des postes, création de Product Backlog, …). La seconde étant la
mauvaise estimation de la mise en place de la base de données et de la réalisation de
l’interface graphique de base.
Ce Sprint a été conclu par une petite rétrospective mais n’a pas fait l’objet d’une revue avec
démonstration au client. Il n’était en effet pas possible à la fin du premier Sprint de réaliser
une démonstration convaincante pour le client. Néanmoins, la maquette de l’interface
graphique a été présentée au client ainsi que le schéma de la base de données crée.
Figure 40 Maquette de l’interface graphique générale
Contenu d’un poste
Projet pilote
100 / 149
5.5.5.2 Sprint 2
La composition du Sprint 2 est la suivante (Sprint Backlog et le Product Backlog) :
Sprint Name
Product Backlog Item Name Sprint Backlog Item Name Effort
Sprint 2 Affichage de la liste des postes 5 IHM - Affichage de la liste des postes Logique métier - Affichage de la liste des postes Affichage des données générales d'un poste IHM - Affichage des données générales d'un poste Logique métier - Affichage des données générales d'un poste Affichage des Informations sur l'installation logicielle d'un poste 5 IHM - Affichage des Informations sur l'installation logicielle d'un poste Logique métier- Affichage des Informations sur l'installation logicielle d'un poste Affichage des modules du produit StreamX installés sur un poste IHM Affichage des modules du produit StreamX installés sur un poste Logique Métier - Affichage des modules du produit StreamX installés sur un poste Affichage d'informations sur les adresses IP des éléments d'un poste + nom et mot de passe 5 IHM - Affichage d'informations sur les adresses IP des éléments + nom et mot de passe Logique métier - Affichage d'informations sur les adresses IP des éléments + nom et mot de passe Affichage du suivi de maintenance d'un poste donné IHM - Affichage du suivi de maintenance d'un poste donné logique métier - Affichage du suivi de maintenance d'un poste donné Ajout d'un poste 5 IHM - Ajout d'un poste logique métier - Ajout d'un poste gestion exception - Ajout d'un poste redirection page principale du poste - Ajout d'un poste Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) sur un poste 15 sauvegarde des données générales sauvegarde données d'accès "sans image" sauvegarde des informations matérielles sauvegarde informations sur le suivi sauvegarde info sur les adresses ip sauvegardes des informations d'identification sauvegardes des informations d'installation sauvegardes des logiciels
Tableau 12 Sprint Backlog du Sprint 2
Ce Sprint Backlog est issu de la réunion de début de sprint. On peut voir que les items réalisés
durant le Sprint précédant ne sont plus présents et que la sauvegarde des modifications de
données simples qui n’avait pas pu être effectuée dans le Sprint précédant est reprise ici.
Le Tableau 13 représente le Sprint et son avancement au fil des jours de la semaine :
Sprint Backlog Id, Name and Owned By 9/7 10/7 11/7 12/7 13/7 000106 sauvegarde des données générales (Yannick Thiessoz) 1 1 1 0 000107 sauvegarde données d'accès "sans image" (Yannick Thiessoz) 1 1 1 1 0 000108 sauvegardes des données commerciales (Yannick Thiessoz) 1 1 1 1 1 000109 sauvegarde des informations matérielles (Yannick Thiessoz) 1 1 1 1 0 000110 sauvegarde information sur le suivi (Yannick Thiessoz) 1 1 1 1 0 000111 sauvegarde info sur les adresses IP (Yannick Thiessoz) 1 1 1 1 0 000112 sauvegarde info sur les contacts (Yannick Thiessoz) 1 1 1 1 1 000113 sauvegarde version StreamX (Yannick Thiessoz) 1 1 1 1 1 000115 IHM Affichage des modules du produit StreamX installés sur un poste (Yannick Thiessoz) 1 1 1 0 000116 Logique Métier - Affichage des modules du produit StreamX installés sur un poste 1 1 1 0 000125 IHM - Affichage du suivi de maintenance d'un poste donné (Yannick Thiessoz) 1 0 000126 logique métier - Affichage du suivi de maintenance d'un poste donné (Yannick Thiessoz) 1 0 000127 IHM - Ajout d'un poste (Yannick Thiessoz) 1 0 000128 logique métier - Ajout d'un poste (Yannick Thiessoz) 1 0 000129 gestions exception - Ajout d'un poste (Yannick Thiessoz) 1 0 000130 redirections page principale du poste - Ajout d'un poste (Yannick Thiessoz) 1 0
Tableau 13 Avancement du Sprint 2 (du 9 juillet au 13 juillet)
Projet pilote
101 / 149
Comme le montre le Tableau 13 ce Sprint s’est clairement mieux déroulé que le premier. En
effet, presque toutes les tâches définies ont pu être accomplies et l’avancement a été régulier.
Cependant ce Sprint nous a permis de nous pencher sur la problématique des estimations pour
chaque item du Backlog de Sprint. En effet, nous n’avions jusqu’alors pas fait de
rapprochement entre les estimations des items du Product Backlog et les items du Sprint
BackLog. De plus, nos estimations des items du Product Backlog ont été réalisées en nombre
de points mais Scrum for Team System travaille uniquement en heures. Il fallait donc à ce
stade faire une mise au point.
En ce qui concerne l’estimation des items du Product Backlog, il n’y a pas de réelle
problématique dans notre situation. En effet, nous avions prédit une vélocité de 50 points.
Comme Scrum for Team System travaille en heures, cela n’a pas posé de problème particulier
nous avons donc admis qu’un point équivalait à une heure de travail et que les semaines
contenaient 50 heures de travail.
Pour l’estimation des tâches nous avions été un peu plus souples et nous estimions les tâches
en heures. Malheureusement la somme de ces heures n’était pas toujours équivalente aux 50
heures prévues (nous n’avons pas adapté l’estimation des tâches du Sprint Backlog aux
estimations des exigences du Product Backlog), ce qui ne garantissait pas de bons graphiques.
En effet, les graphiques commençaient avec le nombre d’heures estimés (par exemple pour le
Sprint deux le total des heures est de 16h alors qu’il devrait être de 50h).
Les deux graphiques proposés par Scrum for Team System ont néanmoins permis de
remarquer que l’avancement était bon.
Figure 42 Sprint 2 Cumultive Flow Diagram
Figure 43 Sprint 2 Burdown Chart
Projet pilote
102 / 149
Contrairement au Sprint précédant, il était plus difficile ici de déterminer si une partie des
tâches prévues durant le Sprint ne serait pas réalisées. Comme le montre la Figure 43,
l’avancement du premier jour laissait présumer une fin prématurée et donc une possibilité
d’accroître le périmètre du Sprint. Malheureusement quelques problèmes rencontrés durant la
deuxième journée ont rendu l’avancement moins rapide. Il était donc difficile d’adapter le
périmètre du Sprint.
Finalement à l’aide de la Figure 42, il est facile de remarque que la majorité du travail a pu
être réalisée et qu’une minorité n’a pas pu être conclue à temps. Cette minorité sera reportée
au Sprint suivant.
Ce Sprint a abouti à une version plus élaborée qui a pu être démontrée avec succès auprès du
client.
C’est à ce moment qu’un autre client a été désigné pour suivre la suite de l’avancement du
projet.
5.5.5.3 Sprint 3
La composition du Sprint 3 est la suivante :
Sprint Name
Product Backlog Item Name Sprint Backlog Item Name
Sprint 3 Affichage de la description de l'installation d'un poste Logique métier - Affichage description d'installation d'un poste IHM - Affichage description d'installation d'un poste Affichage des données commerciales sur un poste Logique métier - Affichage données commerciales d'un poste IHM - Affichage données commerciales d'un poste Affichage des informations d'accès à un poste IHM localisation d'un poste Logique métier localisation d'un poste Affichage des personnes de contact pour un poste Logique métier - Affichage personnes de contact d'un poste IHM - Affichage personnes de contact d'un poste Affichage du matériel d'un poste Logique métier - Affichage matériel d'un poste IHM - Affichage matériel d'un poste Sauvegarde des modifications de données simples (données dépendantes du poste ex: Nom du poste) sur un poste sauvegardes des données commerciales sauvegarde info sur les contacts sauvegarde version streamX Sauvegarde des modifications de données complexes (données utilisées par plusieurs postes ex: Personnes de contact) gestion client gestion image gestion responsable accès bd propre ajout commande suppression commande ajout responsable Maintenance suppression responsable maintenance ajout garanti suppression garanti Suppression d'un poste Suppression d'un poste
Tableau 14 Sprint Backlog du Sprint 3
Projet pilote
103 / 149
Ce Sprint Backlog est issu de la réunion de début de sprint. Les trois tâches encore non
réalisées pour la sauvegarde des modifications de données simples qui n’avaient pas pu être
achevées durant le Sprint suivant ont été reportées pour ce Sprint.
Le Tableau 15 représente le Sprint et son avancement au fil des jours de la semaine :
Sprint Backlog Id, Name and Owned By 16/7 17/7 18/7 19/7 20/7 000112 sauvegarde info sur les contacts (Yannick Thiessoz) 3 0 000134 Logique métier - Affichage données commerciales d'un poste (Yannick Thiessoz) 1 0 000135 IHM - Affichage données commerciales d'un poste (Yannick Thiessoz) 1 0 000136 Logique métier - Affichage personnes de contact d'un poste (Yannick Thiessoz) 1 1 0 000137 IHM - Affichage personnes de contact d'un poste (Yannick Thiessoz) 1 1 0 000138 Logique métier - Affichage localisation d'un poste (Yannick Thiessoz) 1 1 1 1 0 000139 IHM - Affichage localisation d'un poste (Yannick Thiessoz) 1 1 1 1 0 000140 Ajout responsable de maintenance (Yannick Thiessoz) 3 3 3 3 0 000141 Suppression responsable maintenance (Yannick Thiessoz) 3 3 3 3 0 000142 Accès Bd propre (Yannick Thiessoz) 5 5 5 0 000143 gestion responsable (Yannick Thiessoz) 4 4 4 0 000144 gestion client (Yannick Thiessoz) 6 6 0 000145 gestion image (Yannick Thiessoz) 5 0 000146 Ajout garantie (Yannick Thiessoz) 2 2 2 2 0 000147 suppression garantie (Yannick Thiessoz) 1 1 1 1 0 000148 ajout commande (Yannick Thiessoz) 2 2 2 2 0 000149 suppression commande (Yannick Thiessoz) 1 1 1 1 0 000150 Logique métier - Affichage materiel d'un poste (Yannick Thiessoz) 1 0 000151 IHM - Affichage materiel d'un poste (Yannick Thiessoz) 1 0 000152 Logique métier - Affichage description d'installation d'un poste (Yannick Thiessoz) 1 0 000153 IHM - Affichage description d'installation d'un poste (Yannick Thiessoz) 1 0 000154 Suppression d'un poste (Yannick Thiessoz) 3 0
Tableau 15 Avancement du Sprint 3 (du 16 juillet au 20 juillet)
Comme le montre le Tableau 15 ainsi que la Figure 44 ce Sprint a avancé plus rapidement que
prévu. Ce qui nous a même permis de rajouter un item du Product Backlog à savoir la
suppression d’un poste. Ce fut donc le premier Sprint achevé avec un Sprint Backlog vide. Et
qui plus est en ajoutant un item du Product Backlog. Cela peut s’expliquer par le fait que les
estimations ont été plus précises. En effet, le Tableau 15 amène à constater que durant la
première journée, des tâches pour une équivalence de 14h de travail on été réalisées, pour la
deuxième journée, nous sommes à 8h de travail, pour la troisième à 9h et 17h pour les deux
dernières. Une autre explication pourrait venir de l’avancement du projet. En effet, le projet
étant à un stade avancé, les membres de l’équipe commencent à prendre des automatismes et
le projet avance plus vite.
Figure 44 Sprint 3 Burdown Chart
Projet pilote
104 / 149
Ce Sprint a lui aussi abouti à une version opérationnelle qui a pu être démontrée avec succès
auprès du client. La version développée jusque là offre les mêmes possibilités que la solution
existante et en plus gère une centralisation des données, ce qui était la motivation principale de
mise en place de ce projet pour le client.
5.5.5.4 Sprint 4
La composition du Sprint 4 est la suivante :
Sprint Name Product Backlog Item Name Sprint Backlog Item Name Sprint 4 Recherches prédéfinies Recherche de la liste des postes en fonction d'une date de setup Recherche de la liste des modules pour tous les postes Recherche de la liste des Ips pour tous les postes Recherche des versions et des dates de setup pour tous les postes Recherches spécifiques logique de recherche spécifique Affichage général filtre d'affichage Affichage général filtre de recherche Affichage général pour les résultats d'une recherche spécifique complexe Création d'onglets de recherche spécifique Affichage général des résultats de recherche spécifique simple
Tableau 16 Sprint Backlog du Sprint 4
Ce Sprint Backlog est issu de la réunion de début de sprint. Ces items issus du Product
Backlog sont les derniers. Cela signifie que si ces items sont correctement réalisés pour la fin
du Sprint les exigences du client seront entièrement satisfaites. De plus, l’application réalisée
jusqu’à présent reprend déjà toutes les fonctionnalités de la solution que le client utilisait tout
en y ajoutant certaines fonctionnalités. La finalisation de ce Sprint permettra donc au client de
disposer d’une version plus évoluée du système de Suivi de maintenance de StreamX.
Le Tableau 17 représente le Sprint et son avancement au fil des jours de la semaine :
Sprint Backlog Id, Name and Owned By 23/7 24/7 25/7 26/7 27/7 000166 Recherche de la liste des postes en fonction d'une date de setup (Yannick Thiessoz) 3 0 000167 Recherche de la liste des modules pour tous les postes (Yannick Thiessoz) 3 0 000170 Logiques de recherche spécifique (Yannick Thiessoz) 3 2 0 000171 Affichage général filtre d'affichage (Yannick Thiessoz) 2 2 2 0 000172 Affichage général filtre de recherche (Yannick Thiessoz) 3 0 000173 Affichage général pour les résultats d'une recherche spécifique complexe 6 6 6 0 000174 Création d'onglets de recherche spécifique (Yannick Thiessoz) 2 0 000175 Affichage général des résultats de recherche spécifique simple (Yannick Thiessoz) 4 4 4 0
Tableau 17 Avancement du Sprint 4 (du 23 juillet au 27 juillet)
Comme le montrent le Tableau 17 ainsi que la Figure 45 et la Figure 46 ce Sprint a avancé
plus rapidement que le rythme escompté. Il a dès lors été possible de consacrer le vendredi à
des tests pour s’assurer que l’application développée était conforme aux attentes du client.
Projet pilote
105 / 149
Figure 45 Sprint 4 Cumulative Flow Chart
Figure 46 Sprint 3 Burdown Chart
Ce Sprint a abouti à la version finale du produit SuiviStreamX qui est totalement
opérationnelle et qui a pu être démontrée avec succès auprès du client.
5.5.6 Scrum Meeting
Chaque jour une réunion de Scrum Meeting a été réalisée en présence des deux membres de
l’équipe. Cette réunion s’est déroulée selon les prescriptions de la méthodologie et a permis
aux deux membres d’avoir une vision précise de l’avancement du projet et des problèmes
rencontrés. Elle a été, bien qu’à prime abord contraignante du fait de son application
journalière, très bien acceptée par l’équipe et a contribué pour beaucoup à la réussite du projet.
5.5.7 Graphiques d’avancement
Mis à part les graphiques exposés dans les chapitres montrant l’avancement d’un Sprint, la
méthodologie Scrum définit aussi un graphique appelé Product Backlog Burdown. Ce
graphique permet d’avoir une vision de l’avancement global du projet. Après le premier
Sprint, l’avancement n’était pas conséquent mais les Sprint 2 et 3 ont fortement rattrapé le
retard accumulé durant le premier Sprint.
Projet pilote
106 / 149
Figure 47 Product Backlog Burdown Chart
Les graphiques nous ont permis de suivre correctement l’avancement du projet. Il nous ont
même permis dans le Sprint 3 de rajouter du travail.
5.5.8 Pratiques de développements
Certaines pratiques ont été entièrement mises en place et d’autres uniquement partiellement.
En effet, la mise en place des pratiques de développement issues de la méthodologie Extreme
Programming est très variable d’un projet à l’autre. Pour ce projet, les pratiques suivantes ont
été totalement intégrées : « Simple Design », « Refractoring » et « Coding Standard ». Tandis
que les pratiques « Customer Test » et « Test-Driven Development » n’ont été que
partiellement mises en œuvre car l’application développée ne requérait pas de tests poussés.
Une autre pratique « Sustainable Pace » n’a pas été mise en œuvre, car le projet demandait
plus d’heures de travail que le temps à disposition.
Projet pilote
107 / 149
5.6 Application Finale
Comme décrit précédemment, ce projet a abouti à une version fonctionnelle de l’application
SuiviStreamX. Cette application est constituée d’une interface web qui communique avec une
base de données. L’installation de cette application ainsi que son utilisation sont décrit dans
les annexes du document [B10] qui est protégé par le NDA (cf. annexe D NDA). Néanmoins
ce chapitre permet d’exposer un aperçu des fonctionnalités disponibles. Les fonctionnalités
citées ici ne sont qu’une partie des toutes les possibilités offertes par cette application web. Le
but de cette présentation n’est donc pas de les citer toutes mais plutôt de faire un rapide tour
d’horizon afin de montrer que l’application développée en suivant la méthodologie a une
certaine complexité.
5.6.1 Accès au site
L’accès au site se fait par l’intermédiaire d’une fenêtre de login comme le montre la Figure
48. Deux types d’utilisateurs sont définis et ont des droits différents. Un dispositif de gestion
de session a été mis en place afin d’améliorer les possibilités de sauvegarde.
Figure 48 SuiviStreamX : Fenêtre de login
Projet pilote
108 / 149
5.6.2 Interface principale
L’interface principale permet de visualiser et de modifier les informations sur le suivi de
maintenance d’un poste où le logiciel StreamX est installé. Un principe d’onglet permet de
naviguer au sein des informations du poste sélectionné. Des boutons de sauvegarde et
d’annulation permettent à l’utilisateur de valider ou non les modifications apportées au poste.
Figure 49 SuiviStreamX : Information de localisation d'un poste
Figure 50 SuiviStreamX : Information sur les logiciels installés
Projet pilote
109 / 149
Figure 51 SuiviStreamX : Information sur l’installa tion du poste
Il est entre autre possible d’ajouter et de supprimer des postes.
Figure 52 SuiviStreamX : Suppression d’un poste
Projet pilote
110 / 149
Mis à part la gestion des informations spécifiques à un poste, la gestion d’information relative
à plusieurs postes tels que la gestion des clients a été mise en place.
Figure 53 SuiviStreamX : Gestion des clients
Cette interface web permet aussi de réaliser des recherches. Il est par exemple possible de
connaître la configuration exacte de tous les modules StreamX installés sur tous les postes.
Figure 54 SuiviStreamX : Recherche prédéfinie modules StreamX
Projet pilote
111 / 149
5.7 Résultats
Les résultats de la mise en place de la méthodologie sont très positifs. En effet, la
méthodologie a été bien acceptée par le collaborateur d’InfoTeam. Elle a entre autre amené le
projet à une version fonctionnelle qui répond aux exigences du client et qui plus est dans une
ambiance de travail très positive. Cependant certains points ont été plus positifs et d’autres
moins. Ces points sont traités dans les sous-chapitres suivants.
5.7.1 Points positifs
5.7.1.1 Scrum meeting et graphique d’avancement
Un des principes de la méthodologie qui a été le plus profitable est les Scrum Meeting. Ces
petites séances journalières, ont amené une vision du projet commune entre tous les membres
de l’équipe. De plus, l’association de ces séances aux différents graphiques proposés par
Scrum permet d’avoir une vision globale et régulière de l’avancement du projet.
5.7.1.2 Flexibilité de la méthodologie
La flexibilité de la méthodologie a particulièrement été appréciée car elle permet d’adapter le
périmètre d’une itération si l’avancement n’est pas conforme aux estimations réalisées. Cela à
d’ailleurs été le cas dans le Sprint 3, où suite à une avancée du développement plus rapide que
prévue, il a été possible d’ajouter une exigence. A l’inverse, il aurait été possible de supprimer
une exigence du Sprint 1. En effet, les graphiques proposés par Scrum nous ont permis de
constater rapidement que la totalité des exigences ne serait pas réalisée pour la fin du Sprint.
Dès lors, il aurait été judicieux de supprimer les items du Sprint Backlog relatifs à une
exigence.
5.7.1.3 Ambiance au sein de l’équipe
Les principes de la méthodologie ont contribué fortement à la bonne ambiance au sein de
l’équipe. En particulier les principes tels que le planning poker et le Scrum Meeting. Ces
principes ont permis de gagner du temps, de conforter la vision globale du projet mais aussi et
surtout, de souder l’équipe.
Projet pilote
112 / 149
5.7.2 Points négatifs
5.7.2.1 Intégration du client
L’intégration du client était dans son ensemble convenable. Mais le premier Sprint n’ayant pas
abouti à un produit fonctionnel, il a été difficile de montrer l’avancement durant la revue de
celui-ci. De plus, durant la revue des Sprints 3 et 4 des démonstrations ont bien eu lieu, mais il
aurait été préférable de mettre à disposition du client une version fonctionnelle sur un serveur
dédié pour qu’il puisse lui-même tester le produit. En effet, malgré de bonnes démonstrations
où tout semblait convenir au client, deux jours de travail supplémentaires ont été nécessaires
pour effectuer les modifications que le client demandait après avoir utilisé lui-même le
produit.
Ce point négatif n’est donc pas une critique vis-à-vis de la méthodologie, mais plutôt une
remarque à l’encontre de son application. Dans une prochaine application de cette
méthodologie il serait préférable de mettre un peu plus l’accent sur cette problématique.
5.7.2.2 Modification du cahier des charges initial
Toute la partie de gestion du changement inclue dans la méthodologie n’a pas pu être
réellement exploitée car les besoins du client n’ont pas évolué. En effet, les exigences du
client ont été très claires au début et n’ont pas changé durant le projet. Il aurait été intéressant
de voir si la méthodologie s’adaptait bien à des changements d’exigence.
5.7.2.3 Estimation des exigences
Comme il a été expliqué dans les chapitres exposant le travail réalisé durant les Sprints,
quelques petits problèmes d’estimation ont été réalisés. Ces problèmes venant d’une mauvaise
estimation de la difficulté de certaines tâches et de l’estimation en heures faite dans le plugin
de Team System à contrario de l’estimation en points prescris dans la méthodologie. Là aussi,
ce n’est pas une critique vis-à-vis de la méthodologie mais plutôt de son application.
Dans un projet de plus grande ampleur, il est possible que le planning poker doive être
légèrement adapté. En effet il est réaliste de penser que tous les membres de l’équipe ne soient
pas concernés par toutes les exigences. Il est donc préférable de laisser l’estimation des
exigences aux membres spécialement concernés, afin d’avoir une estimation plus juste. Cela
ne remet cependant pas en question la présence des autres membres de l’équipe durant cette
estimation, car le regroupement de tous les membres permet d’avoir une vision plus générale.
Projet pilote
113 / 149
Dans notre estimation nous n’avons pas fixé de règles en ce qui concerne la valeur d’un point
et la vélocité de l’équipe. Dans le cas d’un projet plus réaliste et de plus grande ampleur, il est
peut être préférable de baser l’estimation en points sur le principe suivant :
• 10 points = 1 jour idéal (8h de travail effectif)
• La vélocité est de 50% à savoir 5 points par jour et par personne
5.7.2.4 Taille du Sprint et graphiques d’avancement
Les graphiques d’avancement sont sans conteste l’un des apports majeurs de la méthodologie
définie. Malheureusement, la taille de nos Sprints ne permettait pas d’en tirer plein profit. En
effet, sur un graphique d’une semaine, il est difficile voire impossible de prendre en compte
les courbes de tendance et cela pour plusieurs raisons :
• La courbe évolue rapidement durant les 3-4 premiers jours, tandis qu’elle aura
tendance à se stabiliser par la suite.
• Si l’on omet d’entrer les informations de l’avancement durant l’un des cinq jours du
Sprint, cela aura une implication plus forte sur la courbe de tendance que si le Sprint
durerait 30 jours.
5.7.2.5 Vocabulaire de la méthodologie
Le vocabulaire de la méthodologie est composé d’une dizaine de termes, mais la
compréhension et l’apprentissage de ces termes n’est pas aisé. Il faut donc s’assurer que leurs
sens sont compris de tous les membres de l’équipe dès le début du projet.
5.8 Conclusion
La méthodologie a très bien fonctionné sur ce projet. Elle a permis l’aboutissement d’une
version fonctionnelle du produit, répondant à toutes les exigences du client et cela dans les
temps impartis. De plus, le collaborateur d’InfoTeam ayant participé au projet a trouvé la
méthodologie très intéressante en particulier certains principes tels que les Scrum Meeting.
Ces Scrum Meeting ont même provoqué une petite jalousie chez les collaborateurs qui n’y
participaient pas. Maintenant, la prochaine étape consistera à mettre en place cette
méthodologie pour un projet plus conséquent (Projet réel, client externe, équipe plus grande,
projet plus long, …).
Ce projet a été un premier pas dans l’acceptation de la méthodologie par l’entreprise
InfoTeam. Il faut maintenant que des automatismes se créent pour utiliser Scrum dans tous les
projets d’InfoTeam.
Conclusions
115 / 149
6. Conclusions
“Walking on water and developing software from a specification are easy if both are frozen.”
Edward V. Berard
Conclusions
116 / 149
Ce travail de master a permis de tirer le meilleur de l’état de l’art des méthodologies de
développement logiciel afin de concocter une méthodologie adaptée à l’entreprise InfoTeam.
La méthodologie ainsi définie a pu être mise à l’épreuve sur un petit projet interne en faisant
intervenir quelques collaborateurs d’InfoTeam. Comme ces collaborateurs ont été satisfaits
des apports que leur procurait la méthodologie, celle-ci sera intégrée au manuel qualité
d’InfoTeam et mise en œuvre sur divers projets.
L’étude des usines à logiciels a quant à elle, mis en évidence la nécessité d’intégration d’un tel
système pour une entreprise active dans le développement de logiciels. Les atouts en la
matière de Microsoft Visual Studio Team System ne sont plus à démontrer. Néanmoins, son
prix reste à l’heure actuelle un frein considérable à son intégration au sein d’une PME telle
qu’InfoTeam.
La définition d’un processus de test adapté à une PME diffère de la version prévue
initialement. En effet, il est inconcevable de penser qu’un processus de test unique puisse être
appliqué à toutes les situations rencontrées par une entreprise. En effet, les tests sont une
problématique qui varie extrêmement d’un projet à l’autre. Il se peut que certaines pratiques
soient très bien adaptées à un projet et totalement inutiles pour un autre. Il n’est donc pas
réaliste de définir un processus global de test. Toutefois, un état de l’art ainsi qu’une mise en
évidence des concepts de tests utiles à une PME tel qu’InfoTeam ont été réalisés.
En conséquent, les objectifs fixés au début de ce travail de master ont été pleinement atteints.
Sur un plan plus personnel, ce travail m’a été très profitable. En effet, son accomplissement au
sein d’une entreprise m’a initié au monde professionnel et m’a permis d’avoir une vision plus
concrète d’un sujet très théorique. De plus, l’approfondissement d’une matière aussi
importante actuellement, m’a permis d’acquérir des connaissances essentielles. Il est à mon
sens évident que les enseignements que j’ai tirés de la réalisation de ce travail de master seront
un atout pour mon avenir professionnel.
Fribourg, le 21 août 2007
Thiessoz Yannick
Références
117 / 149
Références
“Optimism is an occupational hazard of programming: feedback is the treament.”
Kent Beck
Références
118 / 149
Bibliographie
[B1] David Jean-Luc et al. Professional Visual Studio 2005 Team System, Wiley publishing, ISBN-10 :0-7645-8436-7, (2006)
[B2] Guckenheimer Sam; Perez Juan J. Software Engeneering with Microsoft Visual Studio Team System, Addison-Wesley, ISBN :0-321-27872-0, (2006)
[B3] Programmez ! Magazine du développement : Supplément du numéro 93, (2007)
[B4] Programmez ! Magazine du développement : Numéro spécial, (mars/avril 2006)
[B5] Dictionnaire de l'Académie française, neuvième édition
[B6] Hachette. Dictionnaire encyclopédique, ISBN 2.01.28.0475.6
[B7] Thiessoz, Yannick. Évaluation du logiciel Microsoft Visual Studio Team System, InfoTeam SA, (2007)
[B8] Thiessoz, Yannick. Définition d’une procédure de tests adaptée à une PME, InfoTeam SA, (2007)
[B9] Thiessoz, Yannick. Méthodologie de développement adaptée à InfoTeam, InfoTeam SA, (2007)
[B10] Thiessoz, Yannick. Projet SuiviStreamX, InfoTeam SA, (2007)
[B11] Dijkstra, E. W. Notes on structured programming, Academic Press, (1972)
[B12] Watkins, J. Test logiciel en pratique, Vuibert informatique, (2002)
[B13] IEEE. Standard Glossary of Software Engineering Terminology, Institute of Electrical & Electronics Enginee, (1991)
[B14] Myers, Glenford J. The Art of Software Testing, 1ère edition, John Wiley & Sons, (1979)
[B15] Wasserman, A. “On the Meaning of Discipline in Software Design and Development” In Software Engineering Techniques, Infotech State of the Art Report, (1977)
[B16] White, C. H. System Reliability and Integrity, Infotech, (1978)
[B17] InfoTeam. Manuel qualité d’InfoTeam, InfoTeam, (1997)
Webographie
Microsoft Visual Studio Team System et les Usines l ogicielles
[W1] Développement vers l’usine logicielle http://www.01net.com/article/259731.html (02.04.2007)
[W2] Eclipse Jazz interview http://www.theserverside.com/tt/talks/videos/ErichGammaText/interview.tss (10.04.2007)
[W3] Eclipse Jazz view by IBM http://www.alphaworks.ibm.com/contentnr/cdejazz/ (10.04.2007)
[W4] Jazz presentation ftp://ftp.software.ibm.com/software/fr/event/tla/pm_14h15_15h30_le_futur_avec_jazz.pdf (10.04.2007)
[W5] Eclipse Magazine : IBM to Jazz Up Eclipse http://www.eclipsemag.net/ecm/ecmnews/psecom,id,435,nodeid,2.html?PHPSESSID=6bd8e54ee67dafbbd9536419e4d42fc3 (10.04.2007)
[W6] TeamCity web site http://www.jetbrains.com/teamcity/ (10.04.2007)
[W7] IBM : Rational v7.0 ftp://ftp.software.ibm.com/software/fr/event/tla/am_9h30_11h_baltic_plateformede_gouvernance.pdf (10.04.2007)
[W8] Vision de l’usine logicielle chez Borland http://www.borland.com/us/products/index.html (10.04.2007)
[W9] Site officiel Team System en anglais: http://msdn2.microsoft.com/en-us/teamsystem/default.aspx (04.06.2007)
Références
119 / 149
[W10] Création d’une politique d'archivage (check-in) pour Team Foundation Server: http://www.microsoft.com/france/msdn/vstudio/teamsystem/centrescompetences/winwise/checkinTFS.mspx (26.03.2007)
[W11] MSDN : Documentation Visual Studio Team System: http://msdn2.microsoft.com/fr-fr/library/fda2bad5(VS.80).aspx (26.03.2007)
[W12] Évaluation du succès des fabriques de logiciels et Visual Studio Team System http://www.microsoft.com/france/msdn/vstudio/teamsystem/evaluer-le-succes-avec-les-usines-de-conception-de-logiciels-et-Visual-Studio-Team-System.mspx (26.03.2007)
[W13] MSDN Article : Visual Studio Team System: http://msdn2.microsoft.com/en-us/library/ms391945(VS.80).aspx (26.03.2007) http://msdn2.microsoft.com/en-us/library/ms364075(VS.80).aspx (26.03.2007)
[W14] Webcasts : Journée de l’industrialisation du développement logiciel 2006 http://www.jidl2006.com/ (26.03.2007)
[W15] La gestion des tests dans Visual Studio 2005 http://www.microsoft.com/france/msdn/vstudio/teamsystem/couzy_gestion_test.mspx (26.03.2007)
[W16] Licence des produits de la gamme : http://forums.microsoft.com/MSDN-FR/ShowPost.aspx?PostID=1073926&SiteID=12 (26.03.2007)
[W17] Webcasts : Microsoft TeachDays 2007 : http://www.microsoft.com/france/vision/List.aspx?Qry=team+system+Techdays (26.03.2007)
[W18] Publication des résultats de test : http://www.microsoft.com/france/msdn/vstudio/teamsystem/publication_resultats_tests.mspx (26.03.2007)
[W19] Tests unitaires et génération de code source pour des infrastructures de tests unitaires avec Visual Studio 2005 Team System :
http://www.microsoft.com/france/msdn/vstudio/teamsystem/UTFwVS05TmSys.mspx (26.03.2007)
[W20] Tous vos développements avec Visual Studio 2005 Team System : http://www.microsoft.com/france/msdn/vstudio/teamsystem/Get_All_Your_Devs_In_A_Row.mspx (26.03.2007)
[W21] Tutoriel : Team System for Database: http://www.microsoft.com/france/msdn/vstudio/teamsystem/centrescompetences/winwise/Tutoriel-DBAPro.mspx (26.03.2007)
[W22] Un plugin Eclipse pour Team System : http://www.microsoft.com/france/msdn/vstudio/teamsystem/centrescompetences/winwise/PluginEclipse.mspx (26.03.2007)
[W23] Coach Team System : http://www.microsoft.com/france/msdn/vstudio/teamsystem/evaluez/formezvous.mspx (26.03.2007)
[W24] Site officiel Microsoft France : http://www.microsoft.com/france/msdn/vstudio/teamsystem/default.mspx (26.03.2007)
[W25] Blog de Monsieur Antoine Driard : http://blogs.msdn.com/antoined/default.aspx (26.03.2007)
[W26] Blog de Monsieur Florent Santin : http://blogs.developpeur.org/azra/ (26.03.2007)
[W27] Webcast : Gérer le cycle de vie des bases de données avec Visual Studio Team Edition for Database Professionals :
https://msevents.microsoft.com/cui/WebCastRegistrationConfirmation.aspx?culture=fr-FR&RegistrationID=1289213050&Validate=false (26.03.2007)
[W28] Team System for Database Professionals : http://www.microsoft.com/france/msdn/vstudio/teamsystem/centrescompetences/winwise/Pres-DBAPro.mspx (26.03.2007)
[W29] Forum Visual Studio Team System : http://forums.microsoft.com/msdn-fr/ShowPost.aspx?PostID=1057822&SiteID=12 (26.03.2007)
[W30] Développement Agile avec Team System et SCRUM : http://www.valtech.fr/fr/index/it/smart_architecture/developpement_agile.html (26.03.2007)
Références
120 / 149
[W31] 10 things you should know about Visual Studio 2005 Team System : http://articles.techrepublic.com.com/5100-3513-5967075.html (26.03.2007)
[W32] Microsoft Team System : une offre très prometteuse : http://www.tendances.it/index.php?post/2007/01/19/Microsoft-Team-System-%3A-une-offre-tres-prometteuse (26.03.2007)
[W33] Les outils Open Source pour industrialiser les développements en environnements .NET: http://valtech.developpez.com/articles/dotnet/integration-continue/ (26.03.2007)
[W34] Tester des applications Web utilisant Ajax: http://www.microsoft.com/france/msdn/vstudio/teamsystem/centrescompetences/winwise/WebAjaxTesters.mspx (26.03.2007)
[W35] Team System Widgets: http://accentient.com/widgets.aspx (26.03.2007)
[W36] Etude sur l’industrialisation du développement logiciel: http://www.01net.com/clubs/etude_industrialisation_dev.pdf (26.03.2007)
[W37] Borland et Microsoft Visula Studio Team System: http://www.borland.com/fr/company/news/press_releases/2005/11_07_05_borland_delivers_integrated_requirements_management_system.html (29.03.2007)
[W38] Méthodologie de développement Agile Scrum pour MVSTS: http://www.scrumforteamsystem.com/en/default.aspx (29.03.2007)
[W39] Suivi modification: http://msdn.microsoft.com/msdnmag/issues/07/04/TeamSystem/default.aspx?loc=fr/&fig=true#fig3 (29.03.2007)
[W40] Team System : Version d’évaluation: http://www.microsoft.com/france/msdn/vstudio/teamsystem/evaluez.mspx (29.03.2007)
[W41] Tony Loton, Introdution to the Visual Studio 2005 Application Designer Part 1, MSDN 2005 http://msdn2.microsoft.com/en-us/library/ms379582(VS.80).aspx (04.06.2007)
[W42] Mickey Williams, Introdution to Logical Datacenter Designer Part 2, MSDN 2005 http://msdn2.microsoft.com/en-us/library/ms379568(VS.80).aspx (04.06.2007)
Méthodologie de développement logiciel
Général [W43] Génie logiciel -Introduction
http://www.commentcamarche.net/genie-logiciel/genie-logiciel.php3 (02.04.2007)
[W44] Introduction au génie logiciel C. Dubois ENSIIE http://www3.ensiie.fr/~dubois/GL1A_debut.pdf (17.04.2007)
[W45] Introduction à l’ingénierie des systèmes et du logiciel N. Trèves CMSL http://www.ece.fr:8000/~allard/IntroGLSv1.0-270905.pdf (17.04.2007)
[W46] Cycle de vie du logiciel et bonnes pratiques de développment Sylvie Vignes cours Brique : Gestion de projet logiciel ENST
http://www.infres.enst.fr/~hugues/data/cours/gpl/GPL_cycle_logiciel.pdf (17.04.2007)
[W47] Cours de génie logiciel Pierre Parrend Sciences-U Lyon http://www.rzo.free.fr/docs_genielog/genielog_projet_slides.pdf (17.04.2007)
[W48] Introduction au génie logiciel http://supinfo-projects.com/fr/2006/genie_logiciel/2/ (17.04.2007)
[W49] Processus de développement http://www.infeig.unige.ch/support/se/lect/gl/models/web.html (17.04.2007)
[W50] Introduction au génie logiciel http://www.pstmartin.ouba.com/gestioncontenu/perso/download/pdf/Cycles_developpement_logiciel.pdf (29.05.2007)
[W51] Le besoin en méthode agile http://www.pilotsystems.net/actus/besoin_methode_agile/fr (29.05.2007)
[W52] Comparaison des méthodologies en hollande en 2005 http://www.cs.uu.nl/research/techreps/repo/CS-2005/2005-059.pdf (29.05.2007)
[W53] Introduction aux méthodologies http://dept-info.labri.fr/~counilh/systeme-d-information/SI_0201.pdf (29.05.2007)
Références
121 / 149
[W54] Etude du standishgroup http://www.standishgroup.com (29.05.2007)
[W55] Roue de Deming http://fr.wikipedia.org/wiki/Roue_de_Deming (29.05.2007)
[W56] Introduction au Taylorisme http://fr.wikipedia.org/wiki/Taylorisme (29.05.2007)
[W57] Méthodologie by forumlogiciel.com http://www.forumlogiciel.net/PDF/flavril02.pdf (31.05.2007)
Cycle de développement [W58] Aurélien Pelletier : Méthodologies
http://blogpro.toutantic.net/2006/05/04/methodologies/ (17.04.2007)
[W59] Wikipedia http://fr.wikipedia.org/wiki/Cycle_de_d%C3%A9veloppement (17.04.2007)
[W60] Comment ca marche http://www.commentcamarche.net/genie-logiciel/cycle-de-vie.php3 (17.04.2007)
[W61] Cours Système d’information Marie-Christine Counilh Université de bordeaux-1 http://dept-info.labri.fr/~counilh/systeme-d-information/SI_0202.pdf (17.04.2007)
[W62] Cours Méthodologies de Développement Logiciel R. Moussa Université de Carthage http://rim.moussa.googlepages.com/MSE_modeles.pdf (17.04.2007)
[W63] Cours NFE108 Thierry Brouard Université de Tours http://tbrouard.univ-tours.fr/t/IMG/pdf/3-CycleVie.pdf (17.04.2007)
[W64] Modèle de cycle de développement http://www.laboiteaprog.com/article-modele_de_cycle_de_developpement-47-4 (17.04.2007)
[W65] Activités et Modèles de développement en Génie Logiciel http://www.lsis.org/~dea/M6optionD/Exp-GL2-ModAct.pdf (17.04.2007)
[W66] Modèle itératif vs cascade http://strategic.mit.edu/PDF_archive/theses/SM_malaga_2004.pdf (29.05.2007)
[W67] Processus de développement Objet : Best Pratices http://www.application-servers.com/articles/pdf/a19s.ProcessusDeDeveloppement.pdf (29.05.2007)
Méthode agile [W68] Le manifeste qui régit le développement agile
www.agilemanifesto.org/ (31.05.2007)
[W69] Les fondements du développement agile http://www.dotnetguru.org/articles/dossiers/devagile/DevelopperAgile.htm (29.05.2007)
[W70] Introduction au manifest agile http://www.garance.fr/fr/methode-agile.html (29.05.2007)
[W71] Introduction au manifest agile http://rim.moussa.googlepages.com/MSE_manifesto.pdf (29.05.2007)
[W72] Introduction aux méthodes agiles http://tbrouard.univ-tours.fr/t/IMG/pdf/dX.pdf (29.05.2007)
[W73] Méthodes agiles by club-java.com http://www.club-java.com/Public/slides/xp/methodeagiles-clubjava.pdf (29.05.2007)
[W74] Xp et autres méthodes by club-java.com http://www.club-java.com/Public/slides/xp/XPetAutresMethodes.ppt (29.05.2007)
[W75] Laurant Chartrain article d’introduction au génie logiciel 2006 http://supinfo-projects.com/fr/2006/genie_logiciel/4/ (29.05.2007)
[W76] Méthodes agiles by wikipedia http://fr.wikipedia.org/wiki/M%C3%A9thode_agile (29.05.2007)
[W77] Méthodes agiles by commentCaMarche.net http://www.commentcamarche.net/genie-logiciel/methodes-agiles.php3 (29.05.2007)
[W78] Les Séminaires Capgemini Institut, Comprendre les tendances de l’informatique http://faboulus.free.fr/images/support_tendancesinfo0906.pdf page 130 (29.05.2007)
Références
122 / 149
[W79] Méthodes agiles by rad.fr http://www.rad.fr/agiles06.pdf (29.05.2007)
[W80] Présentation des méthodologies agiles faite par le CNRS http://www.dsi.cnrs.fr/bureau_qualite/developpement-web/methodologie/BI-methodes-agiles.pdf (03.05.2007)
[W81] Borland, Des méthodes agiles pour des budgets fragiles… http://www.borland.com/resources/fr/pdf/solutions/boardbriefing_agility.pdf (03.05.2007)
[W82] Sylvain Niclot, Alternativve à RUP :dX, 2005 http://tbrouard.univ-tours.fr/t/IMG/pdf/dX.pdf (03.05.2007)
Différentes méthodologies
RUP et UP
[W83] An Introduction to the Rational Unified Process by Philippe Kruchten http://www.awprofessional.com/articles/article.asp?p=169549&rl=1 (31.05.2007)
[W84] F—Y. Villemin, CNAM, Méthodologies Orientées-Objet 2006-2007 http://deptinfo.cnam.fr/Enseignement/CycleSpecialisation/MAI/Methodologie07.pdf (29.05.2007)
[W85] F. Golay et J.-L. Miserez, LaSIG, Méthodes de conceptions de systèmes 2007 http://lasig.epfl.ch/enseignement/cours/SIG/SIG_C11_Methodes_RUP.pdf (29.05.2007)
[W86] Présentation de RUP et UP http://www.gsulinux.org/~fenix/gl/RUP_cemsit.pdf (29.05.2007)
[W87] Hafedh Mili, UQÀM, Le Processus Rational Unified Process, 2004 http://www.labunix.uqam.ca/~mili/Enseignement/MGL7361-aut04/NotesDeCours/RUP/RUP.pdf (29.05.2007)
[W88] R. Moussa, ISIL-ESTI, Unified Software Development Process, 2007 http://rim.moussa.googlepages.com/MSE_UP.pdf (29.05.2007)
[W89] Mapping Borland Tools to the RUP by Yuri Marx http://dn.codegear.com/article/33319 (31.05.2007)
[W90] Unified Process by wikipedia http://fr.wikipedia.org/wiki/Unified_Process (29.05.2007)
Extreme programming
[W91] Site de Ron Jeffries sur Extreme programming http://www.xprogramming.com/ (31.05.2007)
[W92] Sûrement le site le plus complet sur Extreme programming http://www.extremeprogramming.org/ (31.05.2007)
[W93] Extreme programming http://www.design-up.com/articles/extreme-programming/dossierxp/index.html (29.05.2007)
[W94] Fondements de l’extreme programming by extremeprogramming.free.fr http://extremeprogramming.free.fr/page.php?page=fondements#6 (29.05.2007)
[W95] XP en bref by xp-France.net http://xp-france.net/index.php?option=com_content&task=view&id=15 (29.05.2007)
[W96] William Herman Morkel Theunissen, University of Pretoriy, A case-study based assessment of Agile software development, 2003
http://upetd.up.ac.za/thesis/available/etd-07152004-084708/unrestricted/00dissertation.pdf (29.05.2007)
[W97] Régis Medina, Design Up, L’extreme Programming en deux pages, 2003 http://www.design-up.com/data/resumexp.pdf (29.05.2007)
[W98] Etreme Programming by pyxis-tech.com http://www.pyxis-tech.com/agilemontreal/docs/ExtremeProgramming.pdf (29.05.2007)
[W99] Stéphane Carré, Optima Consulting, Extreme Programming: une méthodologie de développement logiciel ouverte au changement, 2005
http://www.spiral.lu/SI/Article.nsf/0/f17c2ede4bf74ea1c125708b00291615/$FILE/Extreme%20Programming%20Presentation.pdf (29.05.2007)
Références
123 / 149
[W100] Extreme programming par le site developpez.com http://lagace.developpez.com/extreme-programming/#LI-A (29.05.2007)
[W101] R. Moussa, ISIL-ESTI, Extreme programming, 2007 http://rim.moussa.googlepages.com/MSE_XP.pdf (29.05.2007)
Scrum
[W102] Blog français regroupent les plus d’informations sur Scrum http://scrum.aubryconseil.com/ (29.05.2007)
[W103] Site de Ken Schwaber sur Scrum http://www.controlchaos.com/ (29.05.2007)
[W104] Site de Mike Cohn un des gourous de Scrum www.MountainGoatSoftware.com/scrum (29.05.2007)
[W105] Blog de l’entreprise conchango parlent de Scrum http://blogs.conchango.com/howardvanrooijen/archive/2005/10/27/2311.aspx (29.05.2007)
[W106] Webcast de Claude Aubry sur scrum http://storage02.brainsonic.com/customers/valtech/ValtechDays2006/AG04/part1/files/index_popup.html aussi part2 (29.05.2007)
[W107] Document de Claude Aubry présentant Scrum http://www.aubryconseil.com/docs/AG04_Article.pdf (29.05.2007)
[W108] Scrum in five Minutes de la société softhouse http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf (29.05.2007)
[W109] R. Moussa, ISIL-ESTI, cours sur Scrum, 2007 http://rim.moussa.googlepages.com/MSE_Scrum.pdf (29.05.2007)
[W110] Scrum by wikipedia http://fr.wikipedia.org/wiki/Scrum (29.05.2007)
[W111] Scrum by wikipedia (anglais) http://en.wikipedia.org/wiki/Scrum_%28development%29 (29.05.2007)
[W112] Plugin de Scrum for Microsoft Visual Studio Team System http://www.scrumforteamsystem.com/en/default.aspx (29.05.2007)
[W113] Kane Mar et Ken Schwaber, Scrum with XP, 2002 http://www.phptr.com/articles/article.asp?p=26057&seqNum=1&rl=1 (29.05.2007)
MSF
[W114] Définition de MSF by wikipedia http://fr.wikipedia.org/wiki/Microsoft_Solutions_Framework (31.05.2007)
[W115] Frédéric Wickert, ExpertEase, Comment gérer un projet avec la méthodologie Microsoft Solution Framework
http://download.microsoft.com/download/2/0/2/20210749-cb6e-42df-a077-67dc8203c207/methodologie_msf.ppt (29.05.2007)
[W116] Blog de Frédéric Doillon où il parle de MSF http://frederic.typepad.fr/web/2007/02/quelle_mthodolo.html (29.05.2007)
[W117] Présentation de Team System au Teach Day 2007 de Genève http://www.00001001.ch/Download/TechDays_07/Geneva/Developer/D311_VSTS.pdf (29.05.2007)
[W118] Article de magazine Programmez de janvier 2007 http://www.octo.com/com/pdf/programmez0107.pdf (29.05.2007)
[W119] Eric Le Loc'h, La traçabilité au sein de Team System http://www.microsoft.com/france/msdn/vstudio/teamsystem/tracabiliteTeamSystem.mspx (29.05.2007)
[W120] Sanjay Narang, Méthodologies de développement logiciel et Visual Studio Team System, 2006
http://www.microsoft.com/france/msdn/vstudio/teamsystem/planifiez-le-succes-de-votre-logiciel-avec-visual-studio-team-system.mspx (29.05.2007)
[W121] Visual Studio 2005 Team System : Microsoft Solutions Framework http://msdn2.microsoft.com/en-us/library/aa302179.aspx (29.05.2007)
Références
124 / 149
Autres
[W122] Rapid Application Development (RAD) by wikipedia http://en.wikipedia.org/wiki/Rapid_application_development (31.05.2007)
[W123] Dynamic Software Development Method (DSDM) by wikipedia http://en.wikipedia.org/wiki/DSDM (31.05.2007)
[W124] Feature-Driven Development (FDD) by wikipedia http://en.wikipedia.org/wiki/Feature_Driven_Development (31.05.2007)
[W125] Adaptive Software Development (ASD) by wikipedia http://en.wikipedia.org/wiki/Adaptive_Software_Development (31.05.2007)
Etat de l’art [W126] La Guerre des Méthodologies
http://afterthebubble.blogspot.com/2006/04/la-guerre-des-methodologies.html (29.05.2007)
[W127] Processus de développement unige http://www.infeig.unige.ch/support/se/lect/gl/models/ (29.05.2007)
[W128] L’approche du génie logiciel de SoftFluent http://www.softfluent.com/docs/CodeFluent_WhitePaper_FR.pdf (29.05.2007)
[W129] La nouvelle méthodologie http://jmvanel.free.fr/xp/frNewMethodology.html (29.05.2007)
[W130] L’art de bricoler sa méthodologie http://agilitateur.azeau.com/index.php?itemid=25 (29.05.2007)
[W131] Recueille de site sur le développement logiciel en général http://www.pstmartin.ouba.com/gestioncontenu/plan.php (29.05.2007)
[W132] Méthodologies de développement logiciel et Visual Studio Team System http://www.microsoft.com/france/msdn/vstudio/teamsystem/Planifiez-le-succes-de-votre-logiciel-avec-Visual-Studio-Team-System.mspx (29.05.2007)
[W133] Mettre en application une méthodologie http://fr.articlesbase.com/article_62279.html (29.05.2007)
[W134] Cours de génie logiciel http://rim.moussa.googlepages.com/methodo.html (29.05.2007)
[W135] Les choix informatiques à faire pour développer un modèle http://zongo.toulouse.inra.fr/~nathalie/public/misesEnLigneModelia/050705_formationIntroModelisationLaRochelleJuin2005/supportsDesInterventions/RousseNcomment_050622_planchesMethode.pdf (29.05.2007)
[W136] Comprendre les tendances de l’informatique http://faboulus.free.fr/images/support_tendancesinfo0906.pdf (29.05.2007)
[W137] Méthodes comparée http://ourworld.compuserve.com/homepages/vickoff/metcomp1.htm (29.05.2007)
Processus de test
Général [W138] UniGe : Stratégies de test
http://www.infeig.unige.ch/support/se/lect/prg/tst/web.html (12.06.2007)
[W139] Bruno Legeard, cours test de logiciels, Lab. d’info. De l’université de Franche-Comté http://master-info.univ-fcomte.fr/m2.pro/cours/coursTestBL.pdf (12.06.2007)
[W140] Lionel Seinturier, Tests, université des Sciences et Technologies de Lille http://www2.lifl.fr/~seinturi/middleware/tests.pdf (12.06.2007)
[W141] C. Bourhfir, Génération automatique de cas de test pour les systèmes modélisés par des machines à états finis communicantes, Université de Montréal, 1999 http://www.iro.umontreal.ca/~aboulham/pdfs_sources/Bourhfirthese.pdf (26.06.2007)
[W142] Test (Informatique) by wikipedia http://fr.wikipedia.org/wiki/Test_(informatique) (26.07.2007)
Références
125 / 149
[W143] Le test de logiciel à objects http://ditwww.epfl.ch/SIC/SA/publications/FI97/fi-4-97/4-97-page3.html (26.07.2007)
[W144] Assurance et contrôle qualité du logiciel http://www.crsc.uqam.ca/fr/hajjem/ProjetMaitrise.pdf (26.07.2007)
[W145] Test des applications web : modélisation et génération de séquences de test basées sur le contrôle http://dmi.uqtr.ca/actrecherche/maitrises/memoires/151.pdf (26.07.2007)
[W146] Glossaire CFTL/ISTQB des termes utilisés en tests de logiciels http://www.cftl.net/cms/files/Dokumente/frGlossaire%20des%20tests%20de%20logiciel%20-%20ISTQB.pdf (26.07.2007)
[W147] Couverture de code et tests de non-régression http://en.wikipedia.org/wiki/Rational_Unified_Process (08.05.2007)
Méthodologies de développement logiciel et cycles d e tests [W148] Rational Unified Process by wikipedia
http://en.wikipedia.org/wiki/Rational_Unified_Process (08.05.2007)
[W149] Extreme programming by wikipedia http://fr.wikipedia.org/wiki/Extreme_programming (26.07.2007)
[W150] Extreme programming par le site developpez.com http://lagace.developpez.com/extreme-programming/#LI-A (29.05.2007)
[W151] Test-driven development by wikipedia http://en.wikipedia.org/wiki/Test-driven_development (08.05.2007)
[W152] Optimisation des systèmes d’information : La demarche de test http://www.experts-bto.com/index2.php?option=com_content&do_pdf=1&id=14 (08.05.2007)
Cahier des charges
127 / 149
A Cahier des charges
“Successful software always gets changed.”
Frederick P. Brooks
Cahier des charges
128 / 149
A.1 Description du projet
La conception de logiciel est un domaine de plus en plus complexe. Il s’avère actuellement
nécessaire voir même indispensable pour une entreprise active dans le développement logiciel
de suivre une ou plusieurs méthodologies de développement. Il existe une multitude de
méthodologies et de techniques de développement qui ont toutes leurs qualités et leurs défauts,
mais aucune d’entre elles n’est universellement applicable à tout type de projets/Entreprises.
Le cadre de ce travail est donc l’étude des méthodologies existantes pour en déterminer une
qui soit adaptée à une PME comme InfoTeam. Pour l’instant, InfoTeam utilise des procédures
de développement qui sont en grande partie dédiées à un projet, un client, un groupe de
travail. Ce projet vise donc à globaliser les approches actuellement utilisées, dans le but de
pouvoir en proposer une nouvelle adaptée à la taille du projet et à la diversité des groupes de
compétences dont dispose InfoTeam.
A.2 Les objectifs
Les objectifs finaux du projet peuvent être divisés en trois grandes parties :
• Evaluation du logiciel de Microsoft «Microsoft Visual Studio Team System (MVSTS) »
o Déterminer son utilisabilité par une PME.
o Déterminer les valeurs ajoutées qui découleraient de l’utilisation de ce logiciel.
• Définition de deux processus de développement.
o Adaptés à la taille du projet (un processus pour les projets de petite taille et un pour ceux de plus grande envergure).
o Orientés qualité.
o Prenant en compte l’intégration constante du client.
o S’appuyant sur le fait que le début du projet peut se produire à un état d’avancement arbitraire.
o Basés sur des approches existantes.
• Définition d’une procédure de tests prenant en compte :
o Les approches existantes.
o La diversité des unités de l’entreprise et de ses champs d’activité.
o L’hétérogénéité des technologies et des produits utilisés au sein d’InfoTeam.
Cahier des charges
129 / 149
A.3 Activités
Pour atteindre les objectifs de ce projet, les activités suivantes devront être réalisées :
A.3.1 Etude de Microsoft Visual Studio Team System
L’entreprise InfoTeam est en grande partie spécialisée dans le développement Microsoft. Elle
utilise actuellement différents produits Microsoft pour les différentes étapes de
développement (Visual Studio 2005, SharePoint, SQL Server, Visual SourceSafe, Visio,
Project,…). Dans le produit Visual Studio Team System, Microsoft a intégré à son IDE de
développement un ensemble de composants permettant de manager le cycle de vie d’un projet
(modélisation, développement, test, maintenance, gestion de projet). Le but est maintenant de
savoir si ce logiciel peut avoir un attrait important pour l’entreprise. Pour cela, dans un
premier temps un certain nombre d’ouvrages sur ce logiciel devront être parcourus pour
permettre de synthétiser les fonctionnalités offertes. Cette lecture permettra la mise en place
d’un document visant à reconnaître ou non les avantages de MVSTS pour une entreprise de la
dimension d’InfoTeam. Ce document doit mettre en avant l’utilisabilité du MVSTS ainsi que
les valeurs ajoutées ou les pertes qui découlent de son utilisation dans les points suivants :
• Intégration du client. • Réalisation de l’architecture. • Supervision du processus de développement (gestion des ressources humaines et matériels). • Gestion des tests. • Management de projet (de la spécification jusqu’à la maintenance).
Pour pouvoir tester les différentes fonctionnalités fournies par ce logiciel, un environnement
d’utilisation de MVSTS sera mis à disposition par InfoTeam.
A.3.2 Définition de méthodologies de développement
Pour permettre la mise en place de ces deux méthodologies de développement, une première
étape sera la réalisation d’un document relatant « l’état de l’art » des méthodologies de
développement de logiciel. Cet « état de l’art » doit intégrer entre autre des concepts tels que :
• Extreme programming • Processus unifié • CMMI • MSF Agile
Cet « état de l’art » permettra par la suite de mettre en évidence les méthodologies qui sont ou
non adaptées à une PME. Tout en gardant à l’esprit que les processus de développements
proposés doivent être orientés qualité, permettre l’intégration du client, être souples en ce qui
concerne le démarrage du projet à un état d’avancement arbitraire, être réutilisables, être le
Cahier des charges
130 / 149
plus modulaires possible en définissant des étapes obligatoires et un certain nombre d’étapes
facultatives, tout en gardant une ligne directrice globale à tous les projets.
Au final, nous aboutirons à un document spécifiant clairement les méthodologies à mettre en
place pour un projet de développement, la façon de les utiliser et les bénéfices que celles-ci
apporteront au projet et à l’entreprise.
A.3.3 Définition de la procédure de test
Il est certain que les méthodologies étudiées au point 3.2 intègrent déjà un certain nombre de
procédures de test. Cette partie va donc être légèrement dépendante de la partie précédente.
Elle commencera tout de même par un « état de l’art » des procédures de test pour permettre
de déterminer si de nouvelles procédures seraient intéressantes à intégrer aux méthodologies
proposées au point précédant. Cette partie intégrera les différents tests suivants :
• Les tests unitaires • Les tests d’intégration • Les tests de non régression • Les tests statiques • Les tests dynamiques.
Cette partie devra aussi identifier les produits qui permettent de mettre en place ces
procédures de tests. Là aussi cette partie débouchera sur la mise en place d’un document
relatant les procédures de tests définies pour l’entreprise InfoTeam.
A.3.4 Réalisation d’un développement se basant sur les
objectifs du projet.
Durant le projet il serait intéressant de pouvoir appliquer les méthodologies définies à un cas
concret. Cela dans le but de confirmer leurs avantages et aussi de mettre en évidence la
faisabilité de l’application de ces méthodologies. Pour cela un projet au sein même de
l’entreprise InfoTeam sera mis en place. Il va de soi que la réalisation de ce projet permettra
d’adapter les méthodologies de développement et de tests réalisés.
A.3.5 Rédaction de la documentation
La rédaction de la documentation du projet permettra un suivi des différentes étapes réalisées
et facilitera ainsi la compréhension du travail effectué. Cette activité sera réalisée
parallèlement aux autres activités. Elle permettra ainsi à l’entreprise InfoTeam d’avoir un
rapport leur permettant de profiter pleinement des approches réalisées durant ce travail. Et ce
rapport permettra à l’université de pouvoir évaluer ce travail et de pouvoir profiter des « états
de l’art » réalisés durant ce projet.
Cahier des charges
131 / 149
A.4 Planning
Projet: Méthodologie d’ingénierie logicielle adaptée à une PMEACTIVITES (semaines)
(jours ) L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V
Prise en main du projet
Rédaction du cahier des charges
Étude de MVSTS (~4 semaines)
- Étude du fonctionnement de MVSTS
- Étude des fonction de MVSTS
- Utilisabilité par InfoTeam
- Valeurs ajoutées
- Présentation MVSTS
Méthodologie de développement (~5semaines)
- État de l'art
- Mise en place des méthodologies InfoTeam
- Présentation des méthodologies
Procédures de tests (~5 semaines)
- État de l'art
- Mise en place de la procédure InfoTeam
- Présentaiton de la procédure de tests
Réalisation (~3 semaines)
- Cahier des charges
- Réalisation selon les méthodologies
- Tests selon la procédure
Mise à jour des méthodologies
Mise à jour des tests
Rédaction de la documentation
Réserve
Préparation de la présentation Finale
Rendu du rapport
Présentation Finale
Responsable InfoTeam TP : Temps prévu SA : Sous-assistanat UNIFR
Responsables Unifr Jean Hennebert et Patrik Fuhrer TP TE DI SA A TE : Temps effectif A : Absence
Team Member Thiessoz Yannick DI : Dates importantesS
ous-
assi
stan
at U
NIF
R
13.août.07
Ass
ompt
ion
30.juil.07 06.août.07
Fêt
e na
tiona
le
16.juil.07 23.juil.07
Sou
s-as
sist
anat
UN
IFR
02.juil.07 09.juil.0704.juin.07 11.juin.07 18.juin.07 25.juin.0723.avr.07 28.mai.0730.avr.07 07.mai.07 14.mai.07 21.mai.0702.avr.07 09.avr.07 16.avr.07
Sou
s-as
sist
anat
UN
IFR
Ven
dred
i Sai
ntLu
ndi d
e P
âque
s
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
12.mars.07 19.mars.07 26.mars.07
Sou
s-as
sist
anat
UN
IFR
Fêt
e-D
ieu
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Luni
d de
Pen
tecô
te
Bud
apes
t
Asc
ensi
onB
udap
est
Beat Ackermann
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Tec
hday
s ge
nève
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Cahier des charges
132 / 149
A.5 Acceptation du cahier des charges
Les soussignés acceptent les termes du cahier des charges :
Nom du projet : Méthodologie d’ingénierie logicielle adaptée à une PME
Lieu et Date : ____________________ Responsables UNIFR : Rolf Ingold Jean Hennebert Patrik Fuhrer
____________________ ____________________ ____________________
Responsable InfoTeam : Beat Ackermann
____________________
Étudiant : Yannick Thiessoz
____________________
Planning final
134 / 149
B Planning final
“In programming, the hard part isn't solving problems, but deciding what problems to solve.”
Paul Graham
Planning final
135 / 149
Projet: Méthodologie d’ingénierie logicielle adaptée à une PMEACTIVITES (semaines)
(jours ) L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V L M M J V
Prise en main du projet
Rédaction du cahier des charges
Étude de MVSTS (~4 semaines)
- Étude du fonctionnement de MVSTS
- Étude des fonction de MVSTS
- Utilisabilité par InfoTeam
- Valeurs ajoutées
- Présentation MVSTS
Méthodologie de développement (~5semaines)
- État de l'art
- Mise en place des méthodologies InfoTeam
- Présentation des méthodologies
Procédures de tests (~5 semaines)
- État de l'art
- Mise en place de la procédure InfoTeam
- Présentaiton de la procédure de tests
Réalisation (~3 semaines)
- Cahier des charges
- Réalisation selon les méthodologies
- Tests selon la procédure
Mise à jour des méthodologies
Mise à jour des tests
Rédaction de la documentation
Réserve
Préparation de la présentation Finale
Rendu du rapport
Présentation Finale
Responsable InfoTeam TP : Temps prévu SA : Sous-assistanat UNIFR
Responsables Unifr Jean Hennebert et Patrik Fuhrer TP TE DI SA A TE : Temps effectif A : Absence
Team Member Thiessoz Yannick DI : Dates importantes
Beat Ackermann
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Tec
hday
s ge
nève
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Fêt
e-D
ieu
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
Luni
d de
Pen
tecô
te
Bud
apes
t
Asc
ensi
onB
udap
est
12.mars.07 19.mars.07 26.mars.07 02.avr.07 09.avr.07 16.avr.07
Sou
s-as
sist
anat
UN
IFR
Ven
dred
i Sai
ntLu
ndi d
e P
âque
s
Sou
s-as
sist
anat
UN
IFR
Sou
s-as
sist
anat
UN
IFR
23.avr.07 28.mai.0730.avr.07 07.mai.07 14.mai.07 21.mai.07 04.juin.07 11.juin.07 18.juin.07 25.juin.07
Sou
s-as
sist
anat
UN
IFR
03.sept.0730.juil.07 06.août.07
Fêt
e na
tiona
le
16.juil.07 23.juil.07
Sou
s-as
sist
anat
UN
IFR
02.juil.07 09.juil.07
Journal de bord
136 / 149
C Journal de bord
“You can't manage what you can't control, and you can't control what you don't measure.”
Tom DeMarco
Journal de bord
137 / 149
Réf. Date Activités Resp. 1 12.03.2007 Introduction à l’entreprise
Présentation Team "Développement" Mise en place du poste de travail Recherche de documentation du MVSTS Discussion sur le cahier des charges Première lecture sur MVSTS
YT
2 13.03.2007 Lecture documents sur MVSTS Travail à l’université de Fribourg (Sous assistanat)
YT
3 14.03.2007 Travail à l’université de Fribourg (Sous assistanat) YT 4 15.03.2007 Mise en place des différents documents (CDC, Rapport, jdb)
Fin du premier draft du CDC Lecture de documents sur MVSTS et synthèse
YT
5 16.03.2007 Travail à l’université de Fribourg (Sous assistanat) YT 6 19.03.2007 Envoi mail pour CDC
Début document VSTS Lecture d’articles Lecture du livre 1 pages 1-78
YT
7 20.03.2007 Séance Beat Mail Unifr Modification du CDC et mise en place des autres documents (3 pour InfoTeam et le rapport pour Unifr) Lecture du livre 1 pages 79-115
YT
8 21.03.2007 Travail à l’université de Fribourg (Sous assistanat) Discussion avec Patrik sur le cahier des charges et le travail en général
YT
9 22.03.2007 Mise en place du document sur MVSTS (lecture de livres, site magazine, consultation de blog et webcasts). Rédaction du document MVSTS
YT
10 23.03.2007 Mise en place du document sur MVSTS (lecture de livres, site magazine, consultation de blog et webcasts). Rédaction du document MVSTS
YT
11 26.03.2007 Mise en place du document sur MVSTS (lecture de livres, site magazine, consultation de blog et webcasts). Rédaction du document MVSTS
YT
12 27.03.2007 Mise en place du document sur MVSTS (lecture de livres, site magazine, consultation de blog et webcasts). Rédaction du document MVSTS
YT
13 28.03.2007 Techdays Genève YT 14 29.03.2007 Mise en place du document sur MVSTS (lecture de livres, sites
magazines, consultation de blogs et webcasts). Rédaction du document MVSTS
YT
15 30.03.2007 Présentation de l’évolution du document à Jean Hennebert. Travail à l’université de Fribourg (Sous assistanat)
YT
16 02.04.2007 Discussion sur les prix de MVSTS Finitions sur le document MVSTS pour InfoTeam
YT
Journal de bord
138 / 149
Mise en place de cette partie dans le rapport Unifr Mise en place de la présentation PowerPoint.
17 03.04.2007 Interview portail et énergie Mise en place du NDA Finitions de la présentation
YT
18 04.04.2007 Travail à l’université de Fribourg (Sous assistanat) YT 19 05.04.2007 Finitions présentation
Recherche méthodologies YT
20 06.04.2007 Vendredi Saint YT 21 09.04.2007 Lundi de Pâques YT 22 10.04.2007 Recherches sur les méthodologies
Finitions de document pour l’université Mise en place de la présentation
YT
23 11.04.2007 Travail à l’université de Fribourg (Sous assistanat) Recherches sur les méthodologies Achèvement du document pour l’université Mise en place de la présentation
YT
24 12.04.2007 Méthodologie Présentation
YT
25 13.04.2007 Réinstallation poste YT 26 16.04.2007 Présentation
Méthodologie YT
27 17.04.2007 Début état de l’art méthodologie YT 28 18.04.2007 Travail à l’université de Fribourg (Sous assistanat) YT 29 19.04.2007 Mail d’avancement à l’université
Mise à jour des documents de l’université Suite de méthodologies (cycle de vie d’un développement) Introduction + contexte document pour l’université
YT
30 20.04.2007 Relecture du document méthodologie Fin des cycles Fin de l’intro
YT
31 23.04.2007 Méthodologie constat actuel Méthodologies agiles Mise en évidence des méthodologies utiles à une PME
YT
32 24.04.2007 Mise en place de la partie choix d’une méthodologie Etude des méthodologies existantes. (XP)
YT
33 25.04.2007 Travail à l’université de Fribourg (Sous assistanat) YT 34 26.04.2007 Etude des méthodologies existantes. (XP)
Mise à jour du document selon remarques de la séance uni + cours XP de Jean. Etude des méthodologies existantes. (UP)
YT
35 27.04.2007 Présentation intermédiaire Unifr YT 36 30.04.2007 Etude des méthodologies existantes. (UP)
Etude des méthodologies existantes. (MSF Agile) YT
37 01.05.2007 Etude des méthodologies existantes. (Scrum) Etude des méthodologies existantes. (MSF Agile)
YT
38 02.05.2007 Travail à l’université de Fribourg (Sous assistanat) YT 39 03.05.2007 Relecture de l’état de l’art YT
Journal de bord
139 / 149
Discussion pour les attentes d’une méthodologie chez InfoTeam Préparation présentation pour team Dev. de MVSTS
40 04.05.2007 Présentation Unité Automatisation et Ingénierie Logicielle. Finitions état de l’art méthodologie. Et mise en place séances de définitions pour la méthodologie d’InfoTeam
YT
41 07.05.2007 Recherche sur les méthodologies/processus de test YT 42 08.05.2007 Recherche sur les méthodologies/processus de test YT 43 09.05.2007 Travail à l’université de Fribourg (Sous assistanat) YT 44 10.05.2007 Recherche sur les méthodologies/processus de test YT 45 11.05.2007 Recherche sur les méthodologies/processus de test YT 46 14.05.2007 Discussion sur la méthodologie adaptée à Infoteam
PV discussion, début de la mise en place de la méthodologie InfoTeam Appels pour demandes d’offre MVSTS
YT
47 15.05.2007 Mise en place méthodologie développement InfoTeam YT 48 16.05.2007 Travail à l’université de Fribourg (Sous assistanat) YT 49 17.05.2007 Ascension YT 50 18.05.2007 Budapest YT 51 21.05.2007 Budapest YT 52 22.05.2007 Matinée absent
Mise en place méthodologie développement InfoTeam YT
53 23.05.2007 Travail à l’université de Fribourg (Sous assistanat) YT 54 24.05.2007 Mise en place méthodologie développement InfoTeam YT 55 25.05.2007 Mise en place méthodologie développement InfoTeam YT 56 28.05.2007 Lundi de Pentecôte YT 57 29.05.2007 Mise en place méthodologie développement
Mise à jour des ressources de chaque document YT
58 30.05.2007 Travail à l’université de Fribourg (Sous assistanat) YT 59 31.05.2007 Mise en place méthodologie modification en fonction des
remarques de Patrik YT
60 01.06.2007 Mise à jour document état de l’art+ Début présentation méthodologie
YT
61 04.06.2007 Présentation méthodologie Mise à jour des documents pour respecter la forme voulue pour les références vers des images.
YT
62 05.06.2007 Intégration remarques Beat + tests YT 63 06.06.2007 Travail à l’université de Fribourg (Sous assistanat) YT 64 07.06.2007 Fête-Dieu YT 65 08.06.2007 Envoie à tout le monde méthodologie + test YT 66 11.06.2007 Procédure de test YT 67 12.06.2007 Méthodologies de développement YT 68 13.06.2007 Travail à l’université de Fribourg (Sous assistanat) YT 69 14.06.2007 Présentation méthodologie + installer MVSTS client YT 70 15.06.2007 Discussions méthodologie YT 71 18.06.2007 Mise en place résumé méthodologie + rajout chapitre cahier des
charges + procédure de test YT
72 19.06.2007 Installation Team system serveur + procédure de tests + donner YT
Journal de bord
140 / 149
résumé et doc méthodologie pour validation à Beat. 73 20.06.2007 Travail à l’université de Fribourg (Sous assistanat) YT 74 21.06.2007 Atelier MVSTS 2-3-4 YT 75 22.06.2007 Atelier MVSTS 5-6 + présentation méthodologie agile de Tony YT 76 25.06.2007 Séance début projet + fin atelier 6 7 8 9 + transmission du
document d’intro à la méthodologie à Jean-Luc YT
77 26.06.2007 Fin test YT 78 27.06.2007 Travail à l’université de Fribourg (Sous assistanat) YT 79 28.06.2007 Fin tests + mise à jour de sharepoint + création du document cahier
des charges pour le projet + mise à niveau sur ASP.NET + réflexion sur le projet
YT
80 29.06.2007 Mise à jour des documents (rapport uni…) + préparation de la 2ème présentation intermédiaire pour l’université
YT
81 02.07.2007 Séance de planification et d’explication du projet à Olivier Mise en place du projet sur le serveur Configuration de l’accès au projet Définition des exigences du cahier des charges Création du Backlog de produit Définitions des priorités par le client Définitions des estimations par l’équipe Choix des exigences pour le Sprint Découpage en tâches
YT
82 03.07.2007 Début de l’implémentation (BD) Page de login
YT
83 04.07.2007 Création des tables Création de la hiérarchie d’objets Classe d’accès à la base
YT
84 05.07.2007 Fenêtre de base Liste des postes Login Eléments de chaque onglet Préparation des onglets
YT
85 06.07.2007 Lien entre sélection dans l'arborescence et élément à afficher Début sauvegarde des données générales Début sauvegarde des données d'accès "sans image" Début sauvegarde des données commerciales Début sauvegarde des informations matérielles Début sauvegarde des informations sur le suivi Début sauvegarde des informations sur les adresses ip Début sauvegarde des informations sur les contacts Début sauvegarde de la version StreamX
YT
86 09.07.2007 IHM - Affichage du suivi de maintenance d'un poste donné Logique métier - Affichage du suivi de maintenance d'un poste donné IHM - Ajout d'un poste Logique métier - Ajout d'un poste Gestion exception - Ajout d'un poste Redirection page principale du poste - Ajout d'un poste
YT
Journal de bord
141 / 149
87 10.07.2007 Début IHM Affichage des modules du produit StreamX installés sur un poste Début Logique Métier - Affichage des modules du produit StreamX installés sur un poste Début sauvegarde des données générales
YT
88 11.07.2007 IHM Affichage des modules du produit StreamX installés sur un poste Logique Métier - Affichage des modules du produit StreamX installés sur un poste Sauvegarde des données générales
YT
89 12.07.2007 Sauvegarde des données d'accès "sans image" Sauvegarde des informations matérielles Sauvegarde information sur le suivi Sauvegarde info sur les adresses ip
YT
90 13.07.2007 Sauvegardes des données commerciales Sauvegarde des informations sur les contacts Sauvegarde de la version StreamX
YT
91 16.07.2007 Sauvegarde des informations sur les contacts Logique métier - Affichage des données commerciales d'un poste IHM - Affichage des données commerciales d'un poste gestion image
YT
92 17.07.2007 Logique métier - Affichage des personnes de contact d'un poste IHM - Affichage des personnes de contact d'un poste Logique métier – Affichage de la localisation d'un poste IHM – Affichage de la localisation d'un poste gestion client
YT
93 18.07.2007 Ajout d’un responsable de maintenance Suppression d’un responsable de maintenance gestion responsable Ajout commande Suppression commande
YT
94 19.07.2007 Décision d’ajout de la suppression du poste dans le sprint Accès Bd propre Ajout garantie Suppression garantie
YT
95 20.07.2007 Suppression poste YT 96 23.07.2007 Recherche de la liste des postes en fonction d'une date de setup
Recherche de la liste des modules pour tous les postes Affichage général filtre de recherche Création d'onglets de recherche spécifique
YT
97 24.07.2007 Logique de recherche spécifique Affichage général des résultats de recherche spécifique simple
YT
98 25.07.2007 Affichage général filtre d'affichage Affichage général pour les résultats d'une recherche spécifique complexe
YT
99 26.07.2007 Tests YT 100 27.07.2007 Tests YT 101 30.07.2007 Modification pour le client YT
Journal de bord
142 / 149
102 31.07.2007 Modification pour le client Mise à jour des documents
YT
103 01.08.2007 Fête Nationale YT 104 02.08.2007 Documentation pour la petite application
Documentation pour le suivi de la méthodologie YT
105 03.08.2007 Documentation pour la petite application Documentation pour le suivi de la méthodologie
YT
106 06.08.2007 Rédaction du rapport YT 107 07.08.2007 Rédaction du rapport YT 108 08.08.2007 Relecture du rapport YT 109 09.08.2007 Correction des erreurs YT 110 10.08.2007 Rendu du rapport YT
NDA
144 / 149
D NDA
“I like to remind my team that ultimately we ship products, not specs and design documents,
so we need to remember the end game.”
Ron Soukup
NDA
145 / 149
ACCORD DE CONFIDENTIALITE Entre
(Ci-après « Communiquant »)
Et
(Ci-après « Recevant »)
EXPOSE Afin de permettre les relations d’affaires entre le communiquant et le recevant, il est nécessaire que le communiquant transmette au recevant des informations confidentielles (ci–après “information confidentielle”). Dans le cadre de cet accord “information confidentielle” comprend toute information désignée comme telle par le Communiquant lors de ou avant sa transmission au Recevant. En outre toute information transmise au Recevant par le communiquant et concernant
Le document « Évaluation du logiciel Microsoft Visual Studio Team System » ainsi que ses annexes
Le document « Définition d’une procédure de test adaptée à une PME » ainsi que ses annexes
Le document « Méthodologies de développement adaptée à une InfoTeam » ainsi que ses annexes
Le document « Projet SuiviStreamX » ainsi que ses annexes
sera aussi partie de l’«information confidentielle».
Les parties ont donc convenu ce qui suit :
CONVENTION Le Recevant convient de traiter l’information confidentielle comme telle et de la maintenir confidentielle pour le bénéfice exclusif du Communiquant. Le Recevant s’engage à limiter l’accès à l’information confidentielle aux employés, fournisseurs, étudiants et tiers dans les limites du raisonnable et s’engage à faire signer à toute personne ayant accès à l’information confidentielle des accords de confidentialité au moins aussi restrictifs que le présent accord. Le Recevant s’engage, sauf accord écrit préalable du Communiquant, à ne pas utiliser pour son propre avantage, copier, publier ou divulguer d’une manière quelconque l’information confidentielle, et il ne permettra pas à des tiers d’utiliser l’information confidentielle à leur propre avantage ou au détriment du Communiquant. Le Recevant retournera ou détruira immédiatement tout le matériel concernant l’information confidentielle en sa possession au Communiquant sur requête écrite de ce dernier.
Les obligations du Recevant dans le cadre de cet accord ne concernent pas des informations qui : (a) appartiennent au domaine public au moment de leur transmission, ou sont successivement connues par le public sans faute du Recevant; (b) ont été découvertes ou créées par le Recevant avant la transmission du Communiquant; (c) ont été obtenues par le Recevant par des moyens légitimes d’autres sources que le Communiquant ou les représentants du Communiquant; (d) sont divulguées par le Recevant avec l’approbation écrite du Communiquant.
Le Recevant admet que Le Communiquant est le propriétaires exclusif de l’information confidentielle et de tout brevets, marques, copyright ou titres de propriété intellectuelle qui pourraient en découler. Aucune licence en faveur du Recevant et concernant lesdits titres n’est impliquée par cet accord.
Cet Accord constitue la totalité des accords passés entre les parties au regard de la communication faite par le Communiquant et remplace tout accord précédant éventuel. Il ne peut pas être modifié sans l’accord écrit des deux parties.
Le présent Accord est régi par et soumis au droit Suisse et tout différend ou litige à propos du présent Accord sera porté exclusivement devant le for de Fribourg.
Le présent Accord est valable 3 ans si aucune date de fin n’est mentionnée.
Le présent Accord lie les successeurs et éventuels ayants droit des parties. Chaque partie a signé cet Accord par un représentant autorisé
CD
146 / 149
E CD
“The principle objective of software testing is to give confidence in the software.”
P.D. Coward
Page web
148 / 149
F Page web
“Gives you this sense of keeping just one ball in the air at once, so you can concentrate on that
ball properly and do a really good job with it.”
Martin Fowler
top related