Cours Projet Fédéré 2ISI
Projet Fédéré - Méthodes Agiles
Introduction - Agilité & Processus Unifié
1.1 Les défis du développement logiciel
Problématique : Pourquoi tant de projets échouent-ils ?
1.1.1 Étude de cas : Le projet Denver Airport (1995)
- Objectif initial : Système de gestion automatisée des bagages
- Budget : 186 millions de dollars → Dépense finale : 560 millions
- Délai initial : 2 ans → Livraison : 16 mois de retard
- Causes identifiées :
- Spécifications figées dès le début
- Changements non anticipés
- Manque de tests intermédiaires
- Absence de prototypes
1.1.2 Sta s ques et tendances
Résultats mondiaux des projets logiciels :
✓ Projets réussis : 31% (dans les délais, budget et fonctionnalités)
✗ Projets échoués : 19% (abandonnés avant livraison)
⚠ Projets en difficulté : 50% (dépassements, fonctionnalités réduites)
1.1.3 Facteurs Cri ques de Succès
1. Implication utilisateur : La participation continue des utilisateurs finaux tout au long du projet est le facteur
le plus déterminant car elle garantit que le produit répond réellement aux besoins métier et réduit drastiquement
les coûteuses corrections de dernière minute.
2. Compétences techniques : La maîtrise des technologies, des méthodes et des outils par l'équipe de
développement détermine sa capacité à livrer un produit de qualité dans les délais, particulièrement face aux
défis techniques complexes.
H. Zorgati 1 2025/2026
Cours Projet Fédéré 2ISI
3. Approche agile : L'adoption de pratiques itératives et adaptatives permet de répondre rapidement aux
changements de besoins, de livrer de la valeur plus fréquemment et de réduire les risques d'échec par des
feedbacks précoces et continus.
1.2 Évolu on historique des méthodologies
1.2.1 Modèle en Cascade (Waterfall - 1970)
Avantages :
- Planification claire
- Documentation complète
- Contrôle budgétaire
Limites :
- Changements coûteux (coût ×100 entre phase 1 et 5)
- Livraison tardive des anomalies
- Risque d'obsolescence des besoins
1.2.2 Appari on des modèles itéra fs (années 80-90)
- Prototypage rapide : Technique de conception itérative où l'on progresse du maquettage papier vers des
écrans interactifs puis vers le code final, permettant de valider les besoins utilisateurs très tôt avec un
investissement minimal.
- Modèle en Spirale (Boehm, 1988) : Approche cyclique qui intègre la gestion explicite des risques à chaque
boucle (détermination des objectifs, évaluation des risques, développement, planification du cycle suivant),
contrairement aux modèles séquentiels qui les ignorent jusqu'aux phases tardives.
- RAD (Développement Rapide d'Applications) : Méthodologie fondée sur des ateliers collaboratifs intensifs
avec les utilisateurs, combinés à du prototypage et des outils de génération automatique, pour livrer des
applications fonctionnelles en quelques mois plutôt qu'en années.
1.3 Le Processus Unifié (UP/RUP)
H. Zorgati 2 2025/2026
Cours Projet Fédéré 2ISI
1.3.1 Défini on et caractéris ques
UP (Unified Process) est un framework de processus de développement logiciel itératif et incrémental, centré
sur l'architecture et piloté par les cas d'utilisation. RUP (Rational Unified Process) est l'implémentation
commerciale de cette méthode par Rational Software (racheté par IBM), qui ajoute des outils, des templates et
des guides détaillés pour appliquer UP en entreprise.
Les caractéristiques fondamentales :
Les 4 phases :
- Début (Inception) : On établit la vision du projet, on valide sa faisabilité économique et on délimite son
périmètre pour décider s'il mérite d'être poursuivi.
- Élaboration (Elaboration) : On conçoit l'architecture de base, on analyse les besoins en détail et on traite les
risques techniques majeurs pour stabiliser le plan du projet.
- Construction (Construction) : On développe le produit de manière itérative en ajoutant progressivement les
fonctionnalités jusqu'à obtenir un système complet et testé.
- Transition (Transition) : On déploie le produit chez l'utilisateur final, on assure sa formation et on gère le
passage en environnement réel de production.
Relation avec UML :
RUP utilise UML comme langage de modélisation standard pour tous ses artefacts (diagrammes de cas
d'utilisation, de classes, de séquence, etc.).
H. Zorgati 3 2025/2026
Cours Projet Fédéré 2ISI
1.3.2 Architecture à deux dimensions
Le schéma suivant représente la structure à deux dimensions caractéristique du Processus Unifié (UP/RUP) :
Dimension Temporelle (horizontale)
Représente le déroulement du projet dans le temps avec ses 4 phases séquentielles :
Chaque phase produit un jalon décisionnel (ou milestone) est un point de contrôle formel à la fin de
chaque phase("go/no-go"))
On progresse linéairement de l'idée initiale (Inception) jusqu'à la livraison finale (Transition)
Dimension Disciplinaire (verticale)
Représente les activités techniques et de gestion qui sont réalisées tout au long du projet :
Contrairement au cycle en cascade, on ne fait pas "toute l'analyse puis toute la conception"
L'effort consacré à chaque discipline varie selon la phase (ex: beaucoup d'analyse en
Inception/Élaboration, beaucoup d'implémentation en Construction)
C'est la combinaison de ces deux dimensions qui fait l'originalité d'UP : à chaque itération (découpage
temporel), on traverse plusieurs disciplines (analyse, conception, test...) pour produire un incrément
fonctionnel.
1.3.3 Itéra vité dans le Processus Unifié
Une Itération = Mini-projet avec toutes les activités
Durée : 2 à 6 semaines
Produit : Incrément exécutable et testé
Cycle de vie :
H. Zorgati 4 2025/2026
Cours Projet Fédéré 2ISI
1.3.4 Rela on avec UML
UML (Unified Modeling Language) est un langage graphique normalisé par l'OMG (Object Management
Group) qui permet de visualiser, spécifier, construire et documenter les artefacts d'un système logiciel grâce à
différents diagrammes aux sémantiques précises.
Dans le Processus Unifié, UML sert de langage commun pour documenter toutes les productions du projet à
travers quatre vues complémentaires :
la vue logique (diagrammes de classes/séquences pour la structure interne)
la vue physique (diagrammes de déploiement pour l'infrastructure)
la vue des cas d'utilisation (besoins fonctionnels)
la vue des processus (aspects dynamiques et concurrents : diagramme d'activités, diagramme d'états-
transitions, diagramme de séquence).
1.4 Introduc on à l'agilité et présenta on du projet fil rouge
1.4.1 Manifeste Agile (2001)
Le Manifeste Agile (2001) établit quatre valeurs fondamentales qui privilégient l'humain et l'adaptabilité sur les
processus rigides :
1. Individus et interactions vs Processus et outils : Une équipe motivée et qui communique bien est plus
productive que des processus parfaits appliqués par des individus démotivés.
2. Logiciel qui fonctionne vs Documentation exhaustive : Un logiciel opérationnel qui apporte de la
valeur au client est préférable à une documentation parfaite mais un produit qui n'existe pas ou ne
fonctionne pas.
3. Collaboration client vs Négociation contractuelle : Travailler main dans la main avec le client tout au
long du projet est plus efficace que de figer les besoins dans un contrat et de gérer des litiges ensuite.
4. Adaptation au changement vs Suivi d'un plan : Accepter et intégrer les changements de besoins
(même tardifs) est préférable à s'obstiner à suivre un plan devenu inadapté.
H. Zorgati 5 2025/2026
Cours Projet Fédéré 2ISI
Note importante : Les éléments de droite (processus, documentation, contrat, plan) ont de la valeur, mais les
éléments de gauche en ont encore plus.
1.4.2 Présenta on du projet fil rouge : "LibraGes on"
Contexte : Une bibliothèque universitaire souhaite moderniser son système.
Acteurs principaux :
1. Étudiant : Consulter, réserver, emprunter
2. Bibliothécaire : Gérer exemplaires, prêts, retours
3. Administrateur : Gérer utilisateurs, rapports
Fonctionnalités initiales :
- Recherche multicritère
- Réservation en ligne
- Gestion des prêts/retours
- Système de recommandations
- Tableau de bord statistique
Délivrables attendus :
- Product Backlog priorisé
- Modèles UML complets
- Prototype fonctionnel
- Dossier de conception
H. Zorgati 6 2025/2026