Méthodologies de développement de logiciel

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

4. Constatations

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

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)

7. Méthodes Agiles • 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 (Www.Agilealliance.Org)

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

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.

10. Les 12 principes d’AGILE

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

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)

14. RAD (Rapid Application Develepment) Chef Projet Utilisateur (CPU) Chef Projet Informatique (CPI) Les différent acteurs • Le binôme chef de projet • L’utilisateur décideur • L’expert RAD • Prototypeur • Le propriétaire  Bonne connaissance du système de gestion préparer les sessions animer les sessions soutien méthodologique 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. 4 Phases de projet pourle pilotage RUP (Rational Unified Process) 9 Disciplines Dans une itération, toutes les Disciplines sont impliquées Chaque phase sesubdivise en Itérations

18. XP (ExtremeProgramming) 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 (ExtremeProgramming)

20. XP (ExtremeProgramming) • Cycle de développement 1 à 4 semaines 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 Display

26. Fonctionnement Cleanroom Chaîne de Markov associée • Tests statistiques  • Fiabilité  • Estimation • Méthode de Markov • Processus de contrôle et d’amélioration de la performance  • Les outils de support Cleanroom

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.

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