Présente Par Haddaoui Omar Larbi Walid &

L'institut supérieur d'informatique Présente Par Haddaoui Omar Larbi Walid & Hagui Safa

Plan Généralités L’architecture du Rup Le Rup est un processus Framework Le RUP rassemble les meilleures méthodes de développement Conclusion Bibliographie 1

Plan Généralités L’architecture du Rup Le Rup est un processus Framework Le Rup rassemble les meilleures méthode du développement Conclusion Bibliographie 2

Généralités A l’instar de UML, le RUP (Rational Unified Process)s’affirme aujourd’hui comme une référence en termes de processus de développement. Le RUP décrit les acteurs du développement logiciel, leurs activités et leurs enchaînements, les produits associés et leurs critères qualité. • RUP est l’une des plus célèbres implémentations de la méthode PU (Processus Unifié) L’ensemble des activités de modélisation du système développé s’appuie sur UML. 3

Généralités Il est livré en ligne en utilisant la technologie WEB, ainsi il est réellement disponible à tout moment par les utilisateurs Des mises à niveau régulières de logiciel sont délivrées par Rational Software environ deux fois par an. Ainsi le processus n'est jamais désuet, et ses utilisateurs tirent bénéfice du dernier développement. Tous les membres d'équipe accèdent à la même version du processus. . 5

Généralités A l’instar de UML, le RUP (Rational Unified Process)s’affirme aujourd’hui comme une référence en termes de processus de développement. Le RUP décrit les acteurs du développement logiciel, leurs activités et leurs enchaînements, les produits associés et leurs critères qualité. RUP est l’une des plus célèbres implémentations de la méthode PU (Processus Unifié) Puisqu'il est modulaire et sous forme informatique, il peut être travaillé et configuré pour convenir aux besoins spécifiques de développement. Il est intégré avec les nombreux outils de développement de logiciel dans les Rational Suites, ainsi les développeurs peuvent accéder à des conseils sur le RUP dans les outils qu'ils utilisent. 6

Plan Généralités L’architecture du RUP Le Rup est un processus Framework Le Rup rassemble les meilleures méthode du développement Conclusion Bibliographie 7

L’architecture du RUP Le cycle de vie 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, é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 : 8

L’architecture du RUP Détaille les cas d’utilisation et procède à une première répartition du comportement du système entre divers objets. 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 Expose les cas d’utilisation et leurs relation avec les utilisateurs. Modèle des cas d’utilisation Modèle de conception Modèle d’analyse 9

L’architecture du RUP Définit les nœuds physiques des ordinateurs et l’affectation de ces composants sur ces nœuds. Décrit les cas de test vérifiant les cas d’utilisation. Intègre les composants(code source) et la correspondance entre les classes et les composants. Modèle d’implémentation Modèle de déploiement Modèle de test 10

Étude de l’existant Tous ces modèles sont liés. Ensemble, ils représentent le système comme un tout. Les éléments de chacun des modèles présentent des dépendances de traçabilité ; ce qui facilite la compréhension et les modifications ultérieures. 11

Étude de l’existant Description etenchaînement d’activités Traduit une idée en vision de produit fini et présente une étude de rentabilité pour ce produit. *Que va faire le système pour les utilisateurs? *A quoi peut ressembles l’architecture d’un tel système? *Quelles sont l’organisation et les coûts du développement de ce produit? On fait apparaître les principaux cas d’utilisation. L’architecture est provisoire,identification des risques majeurs et planification de la phase d’élaboration. Moment ou l’on construit le produit. L’architecture de référence se métamorphose en produit complet,elle est maintenant stable. Le produit contient tout les cas d’utilisation que les chefs de projet en accord avec les cas d’utilisations que les chefs de projet en accord avec les utilisateurs ont décide de mettre au point pour cette version. Celle-ci doit encore avoir des anomalies qui peuvent être en partie résolue lors de la phase de transition Permet de préciser la plupart des cas d’utilisation et de concevoir l’architecture du système L’architecture doit être exprimée sous forme de vue de chacun des modules. Émergence d’une architecture de référence. A l’issue de cette phase,le chef de projet doit être en mesure de prévoir les activités et d’estimer les ressources nécessaires a l’architecture du projet Le produit est en version bêta. Un groupe d’utilisateurs essaye le produit et détecte les anomalies et les défauts. Cette phase suppose d’activités comme la fabrication,la formation des utilisateurs clients,la mise en œuvre d’un service d’assistance et la correction des anomalies constates(on le rapport de la correction a version suivante) Phase deconstruction Phase de transition Phase d’élaboration Phase decréation 8 12

Étude de l’existant La structure du processus : Le processus lui-même a été conçu en utilisant des techniques semblables à ceux de la conception logicielle. On retrouve ainsi un modèle orienté objet en utilisant UML. Le schéma montre l'architecture globale du RUP. Le processus a deux structures ou deux dimensions 9 13

1 2 2 Étude de l’existant La dimension horizontal La dimension vertical Représente les workflows qui regroupent logiquement les activités technologiques en fonction de leur nature. Représente l'aspect statique du processus décrit en termes de composants : activités, disciplines, artefacts et rôles. Représente le temps et montre les aspects de cycle de vie du processus. Représente l'aspect dynamique du processus exprimé en termes de cycles, phases, itérations, et étapes importantes. Dans le RUP. La dimension horizontal 9 14

Généralités L’architecture du RUP Le Rup est un processus Framework Plan Le RUP rassemble les meilleures méthodes du développement Conclusion Bibliographie 15

Le RUP rassemble les meilleures méthodes du développement Le RUP est également un cadre de processus (Process Framework) qui peut être adapté pour correspondre aux besoins d'une entreprise. Cette méthode est générale et assez complète pour être employé telle quelle par beaucoup de structures de développement de logiciel de petite taille, particulièrement celles qui n'ont pas une culture des processus très forte. Mais il est également possible de modifier, ajuster, et augmenter le RUP pour l'adapter aux besoins, aux caractéristiques, aux contraintes, et à l'histoire spécifiques de ses,utilisateurs. Un processus ne devrait pas être suivi aveuglément, produisant du travail inutile et des artefacts sans réels valeurs ajoutées. Au lieu de cela, le processus doit être rendu aussi simple que possible tout en accomplissant toujours sa mission : produire un logiciel fiable de haute qualité. 16

Le RUP rassemble les meilleures méthodes du développement Le processus unifié raisonnable rassemble plusieurs des meilleures méthodes en matière du développement moderne de logiciel sous une forme appropriée à un large éventail de projets et d'entreprises : Développement itératif des logiciels. Contrôle total sur les modifications de logiciel Vérification continue de la qualité logicielle. Visualisation de l’organisation logicielle. Management des conditions et des exigences. Qualité de processus En particulier dans un développement itératif, beaucoup de produits sont modifiés. En permettant la flexibilité dans la planification et l'exécution, le développement itératif souligne les questions essentielles de maintien des changements et s'assurant que tout le monde est synchronisé. Concentrée sur les besoins de l'organisation de développement, la gestion de changement est une approche systématique aux changements de gestion des exigences. Le développement itératif *fournit au management des moyens de faire évoluer le produit(exemple:pour concurrencer les produit existants) *il vous permet de fournir rapidement un produit avec des fonctionnalistes réduites pour parer un concurrent Management des conditions et des exigences. Degré d'implémentation du processus dans la fabrication du produit. De plus, la qualité de processus est concernée par la qualité des artefacts (tels que les plans d'itération, les plans de tests, les réalisations des use cases, le modèle de conception) produits à l'appui du produit principal. Visualisation de l’organisation logicielle. La gestion des exigences est une approche qui doit être systématique afin d’obtenir,d’organiser,de communiquer,et de contrôler les exigences changeantes d’un système ou d’une application logicielle Les modèles sont des simplifications de la réalité. Qualité de produit Vérification continue de la qualité logicielle. Ils aident à comprendre un problème et trouver sa solution Qualité du produit principal (le logiciel ou le système) et de tous éléments qu'il comporte (par exemple, composants, sous-ensembles, architecture, et ainsi de suite). Qualité Contrôle total sur les modifications de logiciel Ils facilitent la compréhension des grands systèmes complexes Qualité de processus 17

Conclusion Le RUPnous donne: Les risques sont atténués des le début du projet Le changement est mieux géré Meilleur niveau e rentabilité grâce a l’utilisation de UML 19

Conclusion En résume, le processus unifie est adaptable,et s’applique sous divers formes selon le projet et l’organisation :de l’extrême programme réduisant au maximum les activités de planification et de contrôle,évaluation,jusqu’à des projets de plusieurs centaines de développeurs et a multiples pôle de développement demandant un processus strict et rigide. 20

Bibliographie • http://thieum22.free.fr/Quest_RUP.htm • http://www.qlabs.fr/data/formations/processus_rup.pdf • http://www.telecom-lille1.eu/people/rénaux/page0/page5/page5.html • http://translate.google.com/translate?hl=fr&langpair=en|fr&u=http://www.agilemodeling.com/essays/agileModelingRUP.htm 22

Merci pour votre attention Question?!!

Présente Par Haddaoui Omar Larbi Walid &