Préambule :

Un panorama rapide des méthodologies utilisées pour le développement d'applications Web est présenté ci-après. Ce résumé est composé essentiellement d'une collection d'extraits de documents variés (source citée) : il n'est donc pas toujours d'un style d'écriture homogène. Il n'est par ailleurs certainement pas exhaustif.

Résumé et plan de l'exposé :

En premier lieu, il est important de différencier les techniques de modélisation de l'application (modèles entité-relation, flux, objet (dont UML)…) et les méthodes de conduite de projet (Merise, RAD, UP…) :

• Modélisation : les nouvelles technologies s'appuient sur le modèle objet. En terme d’analyse et de modélisation objet, UML (Unified Modeling Langage) est aujourd’hui un standard incontournable, stabilisé, industriel.

• Conduite de projet : le cycle de développement utilisé pour les applications Web est le cycle itératif (cf schéma des cycles de vie comparés). Une des premières méthodologies à proposer ce cycle itératif a été la méthode RAD (Rapid Application Development) dans les années 80. Le RAD a été critiqué pour son insuffisance de cadre dans la démarche (par exemple, itérations et affinement successifs des spécifications, sans que le nombre d'itérations soit fixé au départ). Certaines démarches, telle DSDM (Dynamic Software Development Method), s'appuient sur le RAD et le complètent par des principes qui couvrent l'ensemble du développement logiciel.
  UP (Unified Process) est un processus de développement logiciel, basé sur les principes d'UML. Contrairement au RAD, UP définit au départ le nombre d'itérations et les cas d'utilisation choisis dans chaque itération sont traités entièrement dans le cadre de cette itération.
  Actuellement, très orientées nouvelles technologies, apparaissent les méthodes agiles, "méthodes itératives à planification souple qui leur permettent de s'adapter à la fois aux changements de contexte et de spécifications du projet". Ces méthodes se déclinent sous forme de valeurs, de principes et de meilleures pratiques de développement, tel par exemple XP (Extreme Programming).

• En guise de conclusion, quelques bonnes pratiques sont proposées pour définir une méthodologie. Enfin, notons d'autres orientations fortes, à savoir que la construction des systèmes s'appuie fortement sur des modèles ou méta-modèles qu'ils soient d'analyse, de conception, de développement ou technique (au niveau de l'architecture).

• Autres liens utiles.

Le texte qui suit est extrait de [OCTO-architecture-des-SI.pdf].

"Les premiers langages objet sont apparus au milieu des années 80 (SmallTalk,Eiffel) et les premières méthodes d’analyse OO sont quant à elles apparues au début des années 90, époque à laquelle on dénombrait plusieurs dizaines de méthodologies OO. La concentration s’est accélérée vers 1995, par la stabilisation autour de trois méthodes (OOM,OMT,OOSE) puis par la fusion en 1997 de ces méthodes dans un langage unique, UML, sous la coupe de l’OMG.

En terme d’analyse et de modélisation objet, UML est aujourd’hui un standard incontournable, stabilisé, industriel (pris en charge par la plupart des outils de modélisation et de développement). Au delà des maîtrises d’oeuvre, UML est également de plus en plus utilisé par les maîtrises d’ouvrage pour spécifier fonctionnellement les cas d’utilisation d’une application, pour modéliser les processus métier au niveau SI…

A travers les différents cas d’usage possibles, UML reste un langage formel de modélisation (basé sur un méta-modèle,un formalisme rigoureux), mais n’est ni une méthodologie (on peut très bien adopter par exemple une méthodologie OMT en utilisant le formalisme UML), ni un processus de développement qui définit les étapes du processus, les acteurs, la démarche (UP, RUP). En revanche, UML cadre l’analyse en proposant une démarche de modélisation basée sur l’élaboration itérative de modèles .

Principes d'UML :

• La démarche est itérative et incrémentale

• La démarche est piloté par les Use-Cases

• La démarche est centrée sur l'architecture

Quelques sites :

• Site officiel : www.uml.org
• Présentation et cours sur UML en français : http://uml.developpez.com/lp/
• [OCTO Livre blanc sur l'architecture de SI] : OCTO-architecture-des-SI.pdf

Cycles de vie comparés (méthodes de conduite de projet)

Le schéma qui suit est extrait de Rad.fr.

RAD (Rapid Application development)

Né dans les années 80, défini par James Martin, repris et adapté au contexte français par Jean-Pierre Vickoff dès 1989.

Le texte qui suit est extrait du site Rad.fr.

"L'organisation du projet s'appuie sur un principe fondamental : la séparation des rôles et des responsabilités entre maîtrise d'ouvrage (MOA) et maîtrise d'œuvre (MOE). Cette dichotomie renforcée par la présence d’une instance d’animation RAD (Groupe d’Animation et de Rapport (GAR)) implique une véritable réingénierie des méthodes de conduite de projet et impose aux deux maîtrises une redistribution des rôles opérationnels et un apprentissage.

La méthode RAD structure le cycle de vie du projet en 5 phases :

• L’Initialisation définit l’organisation, le périmètre et le plan de communication.
• Le Cadrage définit un espace d’objectifs, de solutions et de moyens.
• Le Design modélise la solution et valide sa cohérence systémique.
• La Construction réalise en prototypage actif (validation permanente).
• La Finalisation est un contrôle final de qualité en site pilote.

RAD 2 : processus d’ingénierie de produit logiciel, générique et adaptable à la typologie du projet comme aux formes de modélisation choisies. Le processus est un répertoire des tâches indispensables. Les fondements du processus RAD2 sont les principes de la méthode RAD. Le processus supporte 3 formes de modélisation : MERISE (version 2, allégée), les FLUX (DFD) et la notation Objet UML."

DSDM (Dynamic Software Development Method)

Cette méthode est apparue en 1994.

Le texte qui suit est extrait du site : http://www.businessprocesspartner.com/methodes/dsdm.html.

"La méthode DSDM propose une approche globale du développement de logiciel dans un environnement de développement rapide (RAD). De nombreuses méthodes de développement de logiciels se concentrent uniquement sur une activité, telle que l’analyse et la conception ou la gestion de projet. DSDM fournit un canevas couvrant l’ensemble du cycle de développement afin d’assurer le succès du projet. Le schéma 1.1 illustre tous les domaines abordés par DSDM. La couche supérieure représente le cycle de développement propre à la méthode DSDM. Les couches inférieures correspondent à toutes les parties du projet de développement qui sont prises en considération par la méthode.

Les principes de base sur lesquels repose la méthode DSDM.

Chacun de ces principes est appliqué, de façon appropriée, au cours des différentes étapes de cette méthode.

• L'implication active des utilisateurs est indispensable.
• Pouvoir de décision des équipes DSDM.
• Livraison fréquente de produits.
• L’adéquation aux besoins est le critère essentiel pour que les produits livrés soient acceptés.
• Il est nécessaire d'utiliser un développement itératif et incrémental pour obtenir une solution adaptée aux besoins.
• Toutes les modifications effectuées au cours du développement sont réversibles.
• Les besoins sont définis à un niveau global.
• Les tests sont intégrés à toutes les étapes du cycle de vie.
• Une approche basée sur la collaboration et la coopération entre toutes les personnes intéressées par le projet est essentielle."

UP (Unified Process)

Le texte qui suit est extrait d'un article de Pascal Roques (http://www.dotnetguru.org/articles/Methodes/AgileDotNet.htm).

"Le Processus Unifié (UP) 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 :

• Itératif et incrémental : le projet est découpé en itérations de courte durée (environ 1 mois) qui permettent de 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.
• 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.

La gestion d’un tel processus est organisée suivant les quatre phases suivantes : initialisation (inception), élaboration, construction et transition.

La phase d’initialisation conduit à définir la " vision " du projet, sa portée, sa faisabilité, son " business case ", afin de pouvoir décider au mieux de sa poursuite ou de son arrêt.

La phase d’élaboration poursuit trois objectifs principaux en parallèle :

• Identifier et décrire la majeure partie des besoins utilisateurs,
• Construire (et pas seulement décrire dans un document !) l’architecture de base du système,
• Lever les risques majeurs du projet.

La phase de construction consiste surtout à concevoir et implémenter l’ensemble des éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus consommatrice en ressources et en effort.

Enfin, la phase de transition permet de faire passer l’application des développeurs aux utilisateurs finaux. Les mots-clés sont : conversion des données, formation utilisateurs, déploiement, béta-tests.

Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). Le résultat de chacune d’elles est un système testé, intégré et exécutable. L’approche itérative est fondée sur la croissance et l'affinement successifs d’un système par le biais d’itérations multiples, feed-back et adaptation cycliques étant les moteurs principaux permettant de converger vers un système satisfaisant. Le système croît avec le temps de façon incrémentale, itération par itération, et c’est pourquoi cette méthode porte également le nom de développement itératif et incrémental. Il s’agit là du principe le plus important du Processus Unifié.

Les activités de développement sont définies par cinq disciplines fondamentales qui décrivent la capture des exigences, l’analyse et la conception, l’implémentation, le test et le déploiement. La modélisation métier est une discipline amont optionnelle et transverse aux projets. Enfin, trois disciplines appelées de support complètent le tableau : gestion de projet, gestion du changement et de la configuration, ainsi que la mise à disposition d’un environnement complet de développement incluant aussi bien des outils informatiques que des documents et des guides méthodologiques.

Contrairement au processus en cascade (souvent appelé cycle en V en France), le Processus Unifié ne considère pas que les disciplines sont purement séquentielles. En fait, une itération comporte une certaine quantité de travail dans la plupart des disciplines. Mais la répartition de l’effort relatif entre celles-ci change avec le temps. Les premières itérations ont tendance à mettre plus l’accent sur les exigences et la conception, les autres moins, à mesure que les besoins et l’architecture se stabilisent grâce au processus de feed-back et d’adaptation.

UP doit donc être compris comme une trame commune des meilleures pratiques de développement, et non comme l’ultime tentative d’élaborer un processus universel."

Le schéma qui suit est extrait de : http://www.jerome.capirossi.org/prj_mgt/cycle_10.htm

Méthodologies dérivées

• Catalysis : méthode de modélisation de l'architecture basée sur UML, orientée composants www.catalysis.org
• Extreme System Analysis : méthodologie qui se place entre le dépouillement d'un petit Extreme Programming et la rigidité d'un gros RUP
• RUP = Rational Unified Process. Le RUP, processus de développement "clé en main", proposé par Rational Software, est lui aussi modélisé (documenté) avec UML. Il offre un cadre méthodologique générique qui repose sur UML et la suite d'outils Rational. Site de Rational : http://www.rational.com/products/rup/index.jsp
• EUP = Enterprise Unified Process, extension du RUP : ajoute deux phases : Production et Retirement.
• 2TUP = 2 Tracks Unified Process. Plus récemment, VALtech propose le 2TUP, un processus unifié (c’est-à-dire construit sur UML, itératif, centré sur l’architecture et conduit par les cas d’utilisation), qui apporte une réponse aux contraintes de changement continuel imposées aux systèmes d’informations des entreprises. L’axiome fondateur du 2TUP a été le constat que toute évolution imposée au système d’information peut se décomposer et se traiter parallèlement, suivant un axe fonctionnel et un axe technique. A l’issue des évolutions du modèle fonctionnel et de l’architecture technique, la réalisation du système consiste à fusionner les résultats de ces deux branches du processus.

Méthodes agiles (AM = Agile Modeling)

"Méthodes itératives à planification souple qui leur permettent de s'adapter à la fois aux changements de contexte et de spécifications du projet".

Le texte qui suit est extrait de [BI-methodes-agiles.pdf : "Extreme programming, Méthodes agiles, Tour d'horizon"].

"Les instigateurs des principales méthodes agiles se sont réunis pour former l'Agile Alliance (http://www.agilealliance.org). Ensemble, ils ont pu dégager des principes fondamentaux sur lesquels s'appuyer pour que le développement puisse se faire rapidement et s'adapter au changement. Leur travail a abouti au "Manifeste pour le développement agile d'applications"… Ce manifeste comporte quatre valeurs principales :

• priorité aux personnes et aux interactions sur les procédures et les outils,
• priorité aux applications fonctionnelles sur une documentation pléthorique,
• priorité de la collaboration avec le client sur la négociation de contrat,
• priorité de l'acceptation du changement sur la planification.

Ces quatre valeurs sont déclinées sur douze principes plus généraux qui caractérisent en détail les méthodes agiles.

Par exemple :

• "Notre priorité est de satisfaire le client en lui livrant très tôt et régulièrement des versions fonctionnelles de l'application source de valeur".

• "La simplicité - art de maximiser la quantité de travail à ne pas faire - est essentielle".

• "Les meilleures architectures, spécifications et conceptions sont le fruit d'équipes qui s'auto organisent".

• …"

Quelques sites :

• Site officiel : http://www.agilemodeling.com/
• Article de Pascal Roques (2TUP) sur la démarche Agile au service du e-business (livre à paraître) : http://www.dotnetguru.org/articles/Methodes/AgileDotNet.htm.
  La démarche présentée se situe à mi-chemin entre UP (Unified Process), un cadre général très complet de processus de développement, et XP (eXtreme Programming), une approche minimaliste à la mode centrée sur le code.

XP (Extreme Programming)

Ensemble de bonnes pratiques de développement qui vise à remettre le développeur au centre du processus de développement. Ses prises de positions originales (et extrêmes) lui ont valu un succès d'estime depuis 4 ou 5 ans, surtout aux Etats-Unis.

Le texte qui suit est extrait du site : http://www.design-up.com/methodes/XP/

"Voici les principaux éléments du fonctionnement de XP :

• Gestion des livraisons : L'équipe fournit des livraisons fréquentes au client. Le contenu de ces livraisons est décidé par le client lui-même, à partir des estimations fournies par les développeurs.
• Gestion des itérations : Les livraisons sont réalisées en une suite d'itérations de 2 semaines environ, au sein desquelles le projet est géré à un niveau de détail plus fin.
• Suivi du projet : L'avancement du projet est mesuré de manière concrète par une batterie de tests de recette automatiques. Le rythme de progression est réévalué à chaque itération, et le plan de développement lui-même est revu fréquemment pour tirer parti de l'expérience acquise au cours du projet.
• Qualité du design et du code : Des pratiques strictes permettent de garder une vitesse de développement élevée tout au long du projet, tout en gardant une ouverture maximale au changement. La conception reste toujours le plus simple possible, le code est nettoyé en permanence et des tests unitaires de non-régression sont écrits pour chaque classe.
• Travail en équipe : L'équipe travaille réellement... en équipe. Le code est partagé par tous, les développeurs travaillent systématiquement en binômes, et l'intégration est quasiment continue."

Quelques sites :

• Site officiel : http://www.extremeprogramming.org/
• UML et XP : http://www.trireme.com/whitepapers/process/xp-uml/paper.htm

En guise de conclusion : propositions pour une méthodologie

Le texte et schémas qui suivent sont extrait de "Processus de développement Objet : Best Practices" (Steve Sfartz - IMPROVE) [IMPROVE-best-practices.pdf]

"Synthèse des processus les plus en vogue dans la communauté Objet et Nouvelles Technologies

Projection de XP et 2TUP sur la matrice du RUP
 

Best Practice

Définir pour chaque phase, le nombre d’itérations et leur contenu précis.

Best Practice

Ne passez pas des mois à définir votre méthodologie de développement.

Prenez connaissance des processus les plus utilisés pour en intégrer un ou plusieurs à votre méthodologie de projet.

Exemple : Dans le cas d’un projet Nouvelles Technologies, on pourra intégrer :

• les valeurs d’XP et quelques règles (communication, simplicité, feedback et énergie)
• les documents types du RUP et leur enchaînement
• la branche technique du 2TUP

Best Practice

Le processus de développement doit faire une place importante à la maîtrise des Nouvelles Technologies.

Sous-estimer cet aspect, c’est résoudre les problèmes techniques au fil des développements, avec des risques importants de remise en cause des réalisations (décalage de planning, démotivation des équipes, …).

Exemple : Faire reposer la phase de réalisation sur un processus en Y, en s’attachant à

• intégrer les risques dès les premières itérations
• isoler les solutions techniques dans des frameworks
• valider l’avancement par des prototypes fonctionnels

Best Practice

En règle générale, on peut être confiant quant à la réussite du projet lorsque le prototype fonctionnel est validé et testé.

En effet, à cette étape, les équipes de développement sont productives (formées sur les frameworks techniques, bibliothèques de composants et règles de développement…). "

Autres orientations fortes

La construction des systèmes s'appuie fortement sur des modèles ou méta-modèles (framework, design patterns) qu'ils soient d'analyse, de conception, de développement ou technique tels que MDA (Model Driven Architecture), MVC (Modèle Vue Controleur), MVC II, Struts, J2EE…

• Site de l'Object Management Group : http://www.omg.org/
• Site de MDA (Model Driven Architecture): http://www.omg.org/mda/
• Site de Struts : http://jakarta.apache.org/struts/
• Modèle MVC : Modèle Vue Controleur : une façon structurée de programmer un frontal Web http://www.limsi.fr/Individu/jacquemi/COURS-FIIFO2-JAVA/graph-MVC2.html
• Architecture en 5 couches autour d'UML : http://elisa.aston.fr/elisaconcepts/

Méthodologies de modélisation des processus métier :

Basées sur des outils BPM ou BPR du marché (MEGA/System architecture, Rational/ROSE, Casewise…), Visio ou Word.
Pas de standard actuellement.
Mais initiatives en cours, par exemple : UMM = Unified Modeling Methodology (UN/CEFACT), avec pour objectif de fournir une méthodologie standard basée sur UML pour la modélisation des processus métier entre une entreprise et ses partenaires.
Des patterns métiers existent dans le domaine des télécommunications, du Supply Chain Management.

Autres liens utiles

• Portail sur les méthodes et processus de développement autour de l'Objet et des Nouvelles Technologies : http://www.improve-technologies.com/pages/index.html (choisir la catégorie "Modélisation et gestion de projet")