TROISIEME CHAPITRE : METHODOLOGIE DE LA
RECHERCHE ET
PRESENTATION DU CHAMP EMPIRIQUE
17
forfait classique) au risque de compromettre
la relation client. De plus il n'est pas rare que certaines
fonctionnalités demandées se révèlent finalement
inutiles à l'usage alors que d'autres, découvertes en cours de
route, auraient pu donner plus de valeur au produit. Ce qui constitue aussi une
raison pour migrer vers la méthode agile.
L'approche Agile propose au contraire de réduire
considérablement voire complètement cet effet tunnel
en donnant d'avantage de visibilité, en impliquant le client du
début à la fin du projet et en adoptant un processus
itératif et incrémental. Elle considère que le
besoin ne peut être figé et proposé au contraire de
s'adapter aux changements de ce dernier.
A.1. HISTORIQUE DES METHODES AGILES
Sans entrer dans les détails, la première chose
à savoir est que l'approche Agile n'est pas un effet de mode né
de la dernière pluie. En effet la première approche de gestion de
projet de développement itératif date de 1986. La première
mise en oeuvre de la méthode Scrum (la méthode
Agile la plus utilisée, documentée et éprouvée
aujourd'hui) date de 1993.
La seconde concerne un événement majeur
rassemblant, en 2001, dix-sept figures éminentes du développement
logiciel pour débattre du thème unificateur de leurs
méthodes respectives. De cet événement est né le
Manifeste Agile rassemblant à la lueur des expériences de chacun
les critères pour définir une nouvelle façon de
développer des logiciels. Le terme "Agile" pour qualifier ce type de
méthode est également né à cette occasion.
Avec agile, l'idée consiste à se fixer un
premier objectif à courts termes et se lancer sur la route sans tarder.
Une fois ce premier objectif atteint, on marque une courte pause et on adapte
son itinéraire en fonction de la situation du moment. Et ainsi de suite
jusqu'à atteindre la destination finale. On parle donc d'une approche
empirique. Dans le cadre d'un projet de développement
logiciel, le client élabore sa vision du produit à
réaliser et liste les fonctionnalités ou exigences de ce dernier.
Il soumet cette liste à l'équipe de
développement, communique directement avec elle qui
estime le coût de chaque élément de la liste. On peut ainsi
se faire une idée approximative du budget global.
A.2. LES VALEURS DES METHODES AGILES
Les méthodologies agiles ont quatre valeurs
fondamentales :
· Communication : Personnes et
interactions plutôt que procédures et outils ;
18
· Simplicité : Applications
fonctionnelles plutôt que documentation complète ;
· Feedback : Collaboration avec le client
plutôt que négociation de contrat ;
· Courage : Acceptation du changement
plutôt que suivi d'un plan. Ces quatre valeurs sont à leur tour
déclinées en douze principes généraux :
1. La première priorité est de satisfaire le
client en livrant tôt et régulièrement des logiciels
utiles.
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.
3. Livrer fréquemment une application fonctionnelle,
toutes les deux semaines à deux mois, avec une tendance pour la
période la plus courte.
4. Le client et les développeurs doivent collaborer
quotidiennement au projet.
5. Bâtir le projet autour de personnes motivées.
Leur donner l'environnement et le soutien dont elles ont besoin, et croire en
leurs capacités à faire le travail.
6. La méthode la plus efficace de transmettre
l'information est une conversation en face à face.
7. Un logiciel fonctionnel est la meilleure unité de
mesure de progression d'un
projet.
9. Les processus agiles incitent à un rythme de
développement soutenable. Sponsors, développeurs et utilisateurs
devraient pouvoir maintenir le rythme indéfiniment.
10. Porter une attention continue à l'excellence
technique et à la qualité de la conception améliore
l'agilité.
11. La simplicité "l'art de maximiser la
quantité de travail à ne pas faire" est
essentiel.
13. Les meilleures architectures, spécifications et
conceptions sont issues d'équipes qui s'auto-organisent.
14. À intervalles réguliers, l'équipe
réfléchit aux moyens de devenir plus efficace, puis accorde et
ajuste son comportement dans ce sens.
Etant donné que l'approche Agile est
considérée comme un angle où nous sommes actuellement, il
nous faut donc un chemin à suivre pour atteindre l'objectif. Et cette
voie étant
Une itération prend en compte un certain nombre de cas
d'utilisation qui, ensemble améliorent l'utilisabilité du produit
à un certain stade de développement.
L'itération traite en priorité les risques
majeurs.
A chaque itération, les développeurs identifient
et spécifient les cas d'utilisations pertinents, créent une
conception en se laissant guider par l'architecture choisie,
implémentent cette conception sous forme de composants et vérifie
que ceux-ci sont conformes aux cas d'utilisation. Dès qu'une
itération répond aux objectifs fixés le
développement passe à l'itération suivante (Di Gallo
Frédéric, 2001).
A) Avantages d'un processus itératif
contrôlé.
1) Permet de limiter les coûts, en termes de risques,
aux strictes dépenses liées à une itération.
2) Permet de limiter les risques de retard de mise sur le
marché du produit développé (identification des
problèmes dès les premiers stades de développement et non
en phase de test comme avec l'approche « classique »).
3) Permet d'accélérer le rythme de
développement grâce à des objectifs clairs et à
facteurs :
court terme.
19
donc méthode, nous avons utilisé la
méthode UP et le langage de modélisation UML ; tous deux qui se
présentent de manière que voici :
B. METHODE PROCESSUS UNIFIE (UP)
Le Processus Unifié (UP, pour Unified Process) est un
processus de développement logiciel itératif et
incrémental, centré sur l'architecture, conduit par les cas
d'utilisation et piloté par les risques. C'est une méthode
générique de développement des logiciels ; ce qui veut
dire qu'il est nécessaire d'adapter UP au contexte du projet, de
l'équipe, du domaine et/ou de l'organisation :
Itératif et incrémental : le
projet est découpé en itérations de courte durée
qui aide à mieux suivre l'avancement global. A la fin de chaque
itération, une partie exécutable du système final est
produite, de façon incrémentale.
Le choix de ce qui doit être implémenté au
cours d'une itération repose sur deux
4)
20
Permet de prendre en compte le fait que les besoins des
utilisateurs et les exigences correspondantes ne peuvent être
intégralement définis à l'avance et se dégagent peu
à peu des itérations successives.
5)
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 ne faut donc pas mésestimer l'un des trois
concepts.
? Centré sur l'architecture : tout
système complexe doit être décomposé en parties
modulaires afin de garantir une maintenance et une évolution
facilitées. Cette architecture (fonctionnelle, logique,
matérielle, etc.) doit être modélisée en UML et pas
seulement documentée en texte.
? Piloté par les risques : les risques
majeurs du projet doivent être identifiés au plus tôt, mais
surtout levés le plus rapidement possible. Les mesures à prendre
dans ce cadre déterminent l'ordre des itérations.
? Conduit par les cas d'utilisation : le
projet est mené en tenant compte des besoins et des exigences des
utilisateurs. Les cas d'utilisation du futur système sont
identifiés, décrits avec précision et priorisés.
B) Le cycle de vie du processus unifié
(UP).
Le processus unifié répète un certain
nombre de fois une série de cycles.
Tout cycle se conclut par la livraison d'une version du
produit aux clients et s'articule en 4 phases : création
(initialisation), élaboration, construction et transition, chacune
d'entre elles se subdivisant à son tour en itérations.
Chaque cycle se traduit par une nouvelle version du
système. Ce produit se compose d'un corps de code source réparti
sur plusieurs composants pouvant être compilés et
exécutés et s'accompagne de manuels et de produits
associés. Pour mener efficacement le cycle, les développeurs ont
besoin de construire toutes les représentations du produit logiciel :
21
Tableau du Cycle de vie du processus
unifié
Modèle des cas d'utilisation Expose les cas
d'utilisation et leurs relations avec les utilisateurs
Détaille les cas d'utilisation et procède
à une première répartition du comportement du
système entre divers objets
Modèle d'analyse
Modèle de conception
Définit la structure statique du système sous
forme de sous-système, classes et interfaces ;
Définit les cas d'utilisation réalisés
sous forme de collaborations entre les sous-systèmes les classes et les
interfaces
Modèle d'implémentation
Intègre les composants (code source) et la
correspondance entre les classes et les composants
Modèle de déploiement
Définit les noeuds physiques des ordinateurs et
l'affectation de ces composants sur ces noeuds.
Modèle de test
Décrit les cas de test vérifiant les cas
d'utilisation
Représentation de l'architecture
Description de l'architecture
Tableau n°2 : Cycle de vie de l'Up source :
Agiliste.fr
| 
