méthodologie d’ingénierie logicielle adaptée à une...

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


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.


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


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.


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


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.


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.


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


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


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].


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.


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.


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.


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.


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


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


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


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


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)


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]


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]


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]


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.


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.


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.


52 / 149

3.5.2 Extreme Programming (XP)


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.


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.


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.


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


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


• 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.


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.


57 / 149

3.5.3 Scrum


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.


58 / 149


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.


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.


60 / 149

3.5.4 MSF Agile


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].


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 :


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


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é).


62 / 149


• 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


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.


• 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.


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


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



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


Figure 27 Rapport d’avancement qualitatif MSF Agile


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.


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,


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


• 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.


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.


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.


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.


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.


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


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).


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.


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


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.


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.


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′′=

⋅⋅⋅⋅+


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


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


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


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.


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


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


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.


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


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


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.


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

99 / 149

Figure 41 Schéma de la base de données

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


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


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


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.


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


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.


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


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.


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


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


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


YT


YT


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

CD

147 / 149

Le contenu du cd est le suivant :

Figure 55 l'arborescence du CD

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

Page web

149 / 149

Une page web a été créée pour ce projet à l’adresse suivante :

http://diuf.unifr.ch/people/fuhrer/studproj/thiessoz/index.html

Cette page rassemble les informations suivantes :

• Le résumé de ce projet

• Ce rapport au format PDF.

Figure 56 Site web du projet

méthodologie d’ingénierie logicielle adaptée à une...

Documents