Méthodologies de développement de logiciel

Présentation au sujet: "Méthodologies de développement de logiciel"— Transcription de la présentation:

1 Méthodologies de développement de logiciel
OUAHRANI Atika , BENKHELIFA Imane , BOUSSOUALIM Nacera PG 2009 Méthodologies de développement de logiciel Proposé par : Prof. Mohamed AHMED NACER

2 Plan Introduction aux méthodologies de développement
Méthodes AGILE : RAD, RUP et XP Clean Room Open Source Develeppment Conclusion

3 Problématique Obtenir une solution informatique qui corresponde réellement à ses besoins dans le délai prévu et dans l’enveloppe budgétée. Ce souhait, en apparence raisonnable, combien de décideurs engageant un projet informatique l’ont vu se réaliser!?

4 Constatations Nombre d’études montrent une proportion étonnante d’ 1/3 de projets n’aboutissant jamais. Et sur les 2/3 restant représente des projets menant a conflit, à l’insatisfaction!?

5 D’autres constats ! plus un projet est grand, moins les exigences sont stables ! Plus un projet est long, moins il a de chance de succès 20% seulement des fonctions développées sont utilisées Face à ce constat, les sociétés de développement logiciel ont tenté de trouver des solutions dans l’ élaboration et le suivi de processus de développement, ainsi plusieurs démarche méthodologiques ont été proposés

6 C’est quoi une méthode ? Une méthode:
propose une démarche conforme à un ensemble de principes théoriques s’appuie sur une somme d’expériences et de réflexions recourt à un ensemble de modèles pour décrire les éléments pertinents de la réalité est généralement portée par des outils informatiques peuvent faciliter l’application d’une méthode (CASE/AGL) Méthode Principe Démarche Modèles Outils

7 Méthodes Agiles réaction aux méthodes traditionnelles (lourdeur)
Née à travers un manifeste signé par dix-sept personnalités, créateurs de méthodes ou dirigeants de sociétés 2001. réaction aux méthodes traditionnelles (lourdeur) regroupées par l’Agile Alliance (

8 Qu'est-ce que "le développement agile" ?
"un style de développement logiciel itératif centré sur les personnes et qui met l'accent sur la satisfaction du client à travers les release continue d'un logiciel entièrement fonctionnel".  Le développement agile, aussi appelé "développement adaptatif", peut être considéré comme

9 Les valeurs des méthodologies agiles
Communication : Personnes et interactions plutôt que procédures et outils. 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 fondamentales de l’agilité sont déclinées en douze principes généraux communs à toutes les méthodes agiles :

10 Les 12 principes d’AGILE Satisfaire le client
Considérer comme naturel les changements d’exigences Livrer fréquemment une application fonctionnelle Fonctionnels et développeurs travaillent ensemble Bâtissez le projet autour de personnes motivées L’échange d’information le plus efficace est en face à face Un logiciel fonctionnel est la meilleure façon de mesurer l’avancement du projet Le rythme de développement doit être soutenable indéfiniment Simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle Architectures, spécifications et conceptions issues d'équipes auto-organisées Vérifier en continue l’excellence des pratiques et techniques Régulièrement, réflexion de l’équipe pour être plus efficace

11 RAD (Rapid Application Develepment)
La méthode RAD implique : Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, Construction et l’absolu respect d’une dimension temporelle (90 jours optimum, 120 jours maximum) Une architecture de communication engageant des groupes de travail de structure et de composition variable est une méthode de développement de logiciels où le cycle de développement est plus court que celui des méthodes Cascades. La méthode RAD fut initialement développée par James Martin pendant les années 1980. L'objectif de la méthode RAD restant d'obtenir un applicatif adéquat à partir d'un prototypage impliquant l'utilisateur final.

12 RAD (Rapid Application Develepment)
Des méthodes, techniques et outils permettant de définir et d’appliquer des choix portant sur 4 objectifs: budget, délais, qualité technique, qualité fonctionnelle Une architecture de conception s’appuyant sur les techniques de l'objet et particulièrement sur celles qui permettent une conception " en vue de modifications " Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales

13 RAD (Rapid Application Develepment)
La méthode RAD propose de remplacer le cycle de vie classique par un autre découpage temporel. Le déroulement est d’abord linéaire, puis il suit le modèle de la spirale. Les étapes sont au nombre de cinq : 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.

14 RAD (Rapid Application Develepment)
Les différent acteurs Le binôme chef de projet L’utilisateur décideur L’expert RAD Prototypeur  Le propriétaire  Chef Projet Utilisateur (CPU) Chef Projet Informatique (CPI) Bonne connaissance du système de gestion préparer les sessions animer les sessions soutien méthodologique Les acteurs d’un projet RAD RAD propose une organisation du projet, basée sur une répartition précise du travail entre les différents acteurs. La responsabilité de chacun dépend du rôle qu’il joue. La méthode distingue cinq types de rôles : Evite la coupure traditionnelle entre concepteur et développeur Directeur de l’application Finance le projet

15 RUP (Rational Unified Process)
développé par la société Rational Software (racheté par IBM). basé sur une approche disciplinée : bien maîtriser l'assignation des tâches et responsabilisation des différents acteurs participant Objectif principal : de faire appliquer les bonnes pratiques de développement aux entreprises

16 RUP (Rational Unified Process)
La méthode RUP repose sur 6 pratiques éprouvées du développement logiciel: Développement itératif Gérer les exigences (requirements) Utiliser des architectures de composants Modéliser visuellement (UML) Vérifier la qualité en continu (tests) Gérer les changements

17 RUP (Rational Unified Process)
4 Phases de projet pour le pilotage RUP (Rational Unified Process) 9 Disciplines Dans une itération, toutes les Disciplines sont impliquées Inception – L’idée du projet est exprimée. L’équipe de développement décide si le projet doit être poursuivi et quelles sont les ressources qui doivent y être affectées. Elaboration – L’architecture du projet et les ressources nécessaires sont évaluées plus en détails. Les développeurs analysent les cas d’utilisation de l’application et évaluent les coûts de développement. Construction – Le projet est réalisé et complété. Le programme est conçu, écrit et testé. Transition – Le programme est mis à disposition du public. Des changements mineurs sont apportés et des corrections sont faites sur la base des expériences des utilisatuers finaux. Chaque phase se subdivise en Itérations

18 XP (Extreme Programming)
La méthodologie agile la plus connue Regroupe un ensemble de bonnes pratiques de développement découlant des principes de l’agilité et les poussent à l’extrême Applicable pour des équipes de petite taille de l’ordre d’une douzaine de personnes Repose sur les quatre principes du développement agile : la communication, le feedback, la simplicité et le courage

19 XP (Extreme Programming)
Whole Team: Client sur le site  assistance d’1 personne Planning Game: Séance de planification client définit les scénarios utilisateurs dev discutentdev définissent les tachesestiment ces taches  client choisit Pair programming : le code est écrit par 2 dev Coding Standard : unifier le code  partage du code travailler en duo Sustainable Pace:Rythme soutenable : l’équipe ne doit pas faire des heures supplémentaires en 2 semaines succéssives Small Releases : livraisons courte : le rythme de livraison doit être très court  satisfaction su client  motivation de dev

20 XP (Extreme Programming)
Cycle de développement 1 à 4 semaines -Exploration : Client exprime ses besoins à l’aide des User strories qui décrivent les fctnnalités demandées sur des fiches 1 projet peut contenir 100aine de user stories -Planning : estimation du coût de dev de chaque user story client choisit la meilleure en termes de « cout », « vélocité », « priorité » Dans 7 période le client définit les tests d’acceptation -Itération : permet l’implémentation d’1 user story binômes sont crées les tests sont codésle code est réorganisé pr intégrer les fct..alité de la user story c la partie itérative & incrémentale principale de XP Exploration Planning Itération

21 Avantages XP Méthodologie Agile (tous les avantages de ce type de méthodologie). Relativement simple à mettre en œuvre. Fait une large place aux aspects techniques : prototypes, règles de développement, tests, Innovante: programmation en duo, kick-off matinal debout Très bonne pour le travail en équipe (motivation).

22 Inconvénients XP Dépenser l’énergie à faire et défaire de la phase d’analyse. 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. Adapté uniquement aux petites équipes.

23 Clean Room Buts : Produire des logiciels de qualité, fiables
Réduire les coûts de développement. Propriétés : 80% Conception et Modélisation 20% Code Pas de phase de tests

24 Fonctionnement Cleanroom
Petites équipes  Développement incrémental sous contrôle qualité statistique  Développement logiciel basé sur des principes mathématiques Tests logiciels basés sur des principes statistiques

25 Fonctionnement Cleanroom
Etapes et tests Spécification d’utilisation Correction du code Modèle d’utilisation Invocation Termination Main Menu 1-définit l’utilisateur, l’usage et l’environnemt 2-vérification du code : est ce que 7 boucle se termine? 3-représenter les cas d’utilisations (evenements) Display

26 Fonctionnement Cleanroom
Tests statistiques  Fiabilité  Estimation Méthode de Markov Processus de contrôle et d’amélioration de la performance  Les outils de support Cleanroom Chaîne de Markov associée Invocation Main Menu Display Termination 1 0.9 0.1 Tests: génération automatique commençant par l’état initial et parcourt aléatoirement le modèle jusqu’au état final

27 Avantages CleanRoom Privilégie la prévention des erreurs plutôt que leur correction Se base sur des théories mathématiques pour le développement du logiciel, statistiques pour les tests. Réduire les cycles de développement Obtenir des produits de durée de vie importante.  Les équipes de conception utilisent des techniques qui produisent des systèmes presque sans défauts avant même de commencer les tests. Les équipes de test certifient ensuite la qualité du système pour ses utilisateurs. Inconvéneients : Liste pré-établie de performances standards pr le contrôle Contrôle effectué à chaque phase du processus Cleanroom

28 Open Source Développent
Redistribution du programme libre et gratuite, Livraison du code source avec le programme, Distribution des travaux dérivés dans les mêmes termes que la licence d'origine, Préservation de l'intégrité du code source de l'auteur, Absence de discrimination envers des personnes ou des groupes,

29 Open Source (suite) Absence de discrimination envers des domaines d'activité, Pas besoin de se conformer à des termes de licences complémentaires, Pas de licence spécifique à un produit, Pas de licence imposant des restrictions sur d'autres logiciels, Neutralité vis-à-vis de la technologie utilisée.

30 Développement itératif de OSD

31 Avantages de OSD Qualité : techniques et révision de bugs
Réactivité : mises à jour et corrections fréquentes Pérennité : garantie par une communauté de développeurs grande et actives Coût : cout d’acquisition souvent gratuit et réduit Liberté : Indépendance des choix stratégiques de sociétés commerciales Concurrence : Prévient l’apparition des monopoles basés sur la fermeture de code source Réutilisabilité : Echange et réutilisation des composants

32 Inconvénients de OSD Finition : Interfaces moins finies
Risque de divergence : projet qui se scinde en plusieurs projets Image de marque : pas sérieux, de bidouilleurs Manque d’interlocuteur unique Copyleft

33 Conclusion Difficulté de choisir une bonne méthode
Chaque méthode présente des avantages et des inconvénients Choix de la méthode dépend du projet Majorité des méthodes : incrémentales et itératives

34 Question