Le Processus RUP. H. Kadima. Tester. Analyst. Performance Engineer. Database Administrator. Release Engineer. Project Leader. Designer / Developer

Transcription

1 Le Processus RUP Database Administrator Project Leader H. Kadima Performance Engineer Release Engineer Analyst Designer / Developer Tester

2 Table des matières 1. De l artisanat à l industrialisation de développements de logiciels. 2. Le processus RUP (Rational Unified Process) 4. Comparaison de quelques processus de développement

3 1. De l artisanat à l industrialisation de développements de logiciels Complexité de plus en plus accrue des technologies Nécessité d amélioration de la productivité et de la qualité L industrialisation correspond en général à la refonte du processus d ingénierie système et logiciel de l entreprise

4 Les quatre axes d industrialisation des développements Pratiques et méthodes : de bonnes pratiques, éventuellement organisées en modèles de processus de développement (RUP, XP etc ) Architectures : description, conception, choix technologiques, etc Ressources humaines : formation et évolution Outils : connaissance des outils

5 Analogie avec l industrie classique Toute industrie possède trois caractéristiques essentielles : - optimisation de ses processus en les rationalisant et en travaillant à l amélioration de la qualité de ses produits. - automatisation des processus qui peuvent l être - standardisation des outils et composants qui entrent dans la fabrication de ses produits L industrialisation de développements de logiciels doit suivre cette voie

6 Processus de développement? Un processus définit une séquence d étapes, partiellement ordonnées, qui concourent à l obtention d un système logiciel ou à l évolution d un système existant. L objet d un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles. «Qui fait quoi et quand?»

7 Qu est ce qu un processus? Un processus définit qui fait quoi, quand et comment pour atteindre un objectif donné. Le Processus Unifié de Rational est un processus générique qui utilise UML comme langage de modélisation. Exigences nouvelles ou améliorées Processus d ingénierie logicielle Système nouveau ou amélioré

8 2. Processus Rational Unifié (RUP) 2.1. Caractéristiques générales 2.2. Disciplines et phases RUP 2.3 Outils RUP 2.4. Déploiement de projets RUP 2.5. Exemples de bonnes pratiques

9 RUP est une instance de UP Unified Process Requirement Management() Analysis() Design() Implementation() Test() Deployment() UP Gestion des exigences() Analyse() Conception() Implementation() Test() Déploiement() Rational Unified Process Bus ines s m odeling() Analysis & Design() Project Managem ent() Configuration & Change Managem ent() Environm ent() RUP Mod èli sat ion M éti er() Analy se & Conception() Gestion de Projet() Gestion de Configuration et du Chagnement() Environnement()

10 Caractéristiques générales Le Processus RUP est un processus de développement logiciel «itératif et incrémental, centré sur l architecture, piloté par les cas d utilisation et par les risques»

11 Itératif et incrémental Le projet est découpé en itérations de courte durée (environ un mois) qui aident à 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

12 Intérêts de développement itératif Les risques sont évalués avant Les premières itérations permettent d avoir des retours utilisateur Le test et l intégration sont continus Les jalons permettent de fixer les objectifs Les avancées sont mesurées au fur et à mesure de l implémentation Des maquettes intermédiaires peuvent être déployées

13 RUP est itératif et incrémental Exigences Analyse & conception Planification initiale Gestion Environnement Implémentation Déploiement Planification Tests Chaque itération a pour finalité une version exécutable.

14 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 sous forme textuelle.

15 Le processus RUP est centré architecture Très simplement, on peut dire que l architecture est la structure d un système. La description de l architecture n est pas monolithique, elle est constituée de l agrégation cohérente de différents points de vue. RUP préconise d utiliser le modèle des 4+1 vues ci-contre pour guider l élaboration de l architecture. (Vues de P. Krutchen)

16 Représentation de l architecture : le modèle 4+1 (1) Une vue de l architecture est la description d un système d un point de vue particulier, couvrant certains points et en omettant certains autres. Le Processus Unifié de Rational identifie 4 vues + 1 : La vue logique concerne les exigences fonctionnelles du système. Elle identifie la plupart des paquetages, sous-systèmes et classes. La vue d implémentation décrit l organisation des modules du logiciel.

17 Représentation de l architecture : le modèle 4+1 (2) La vue du processus concerne les aspects concurrents du système à l exécution: taches, threads ou processus, et leur interaction. La vue de déploiement montre comment les différents exécutables sont structurés dans la plate-forme ou les différents nœuds. La vue des cas d utilisation contient les scénarios principaux qui sont utilisés pour faire fonctionner l architecture et pour la valider.

18 Piloté par les risques Les risques majeurs du projet doivent être identifiés au plus tôt, mais surtout levés les plus rapidement possible. Les mesures à prendre dans ce cadre déterminent l ordre des itérations.

19 Piloté 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.

20 RUP est piloté par les cas d utilisation Réalisé Réalisépar par Vérifié Vérifiépar par Implémenté par par Modèle de de conception Modèle d implémentation Modèle de de test test

21 RUP est un cadre de processus RUP décrit qui, quoi, comment et quand faire à l aide d un langage visuel RUP apporte des outils et une méthode d organisation pour l ingénierie participative RUP apporte une vision unifiée sur le processus qui peut être partagée par tous les acteurs

22 RUP permet d appliquer les meilleures pratiques (Best Practices) Le processus Unifié Rational décrit comment appliquer les six directives de l ingénierie logicielle Utiliser le Développement Itératif Analyser les Besoins (Ré)Utiliser Composants Architectures Modeler Visuellement (UML) Contrôler la Qualité Contrôler le Changement

23 Exemple de mise en œuvre de diagrammes UML dans un processus de développement

24 Disciplines et phases RUP Les deux dimensions de RUP Disciplines RUP Phases RUP

25 Les Deux Dimensions du RUP Vision statique (Disciplines) et dynamique (Phases) du processus

26 Disciplines RUP Quatre phases : initialisation, élaboration, construction et transition Chaque phase est elle-même décomposée séquentiellement en itérations limitées dans le temps (entre 2 et 4 semaines). Cinq disciplines fondamentales pour les activités de développement : modélisation métier, capture des exigences, analyse et conception, implémentation, test et déploiement Trois disciplines supports : gestion de projet, gestion de changement et configuration, mise à disposition d un environnement complet de développement.

27 Description des disciplines dans RUP Les disciplines sont des agrégats d activités qui produisent un ensemble déterminé d artefacts. Une discipline est donc définie par : - une liste d activités ; - une liste d artéfacts (produits ou modifiés par la réalisation des activités) - un workflow qui décrit, sous la forme d un diagramme d activité UML, l enchaînement logique des activités. (ci-contre exemple de workflow de la discipline Requirements)

28 Artefacts? Un artefact est un élément d information produit (ou modifié) dans le cadre du processus de développement (document texte, diagramme, compte rendu réunion, code source, modèle base de données ) On distingue deux types d artefacts - ceux qui dépendent de l activité de gestion de projet (comptes rendus divers, planning d activités etc..) - ceux directement issus des activités de fabrication du logiciel (modèles, spécifications, code source etc ) RUP ne prend en charge que le cycle de vie des ces derniers.

29 Rôles dans RUP? Un rôle dans RUP est défini par un ensemble d activités et de responsabilités. Ces dernières peuvent être associées à un ou plusieurs individus. Les rôles sont groupés en quatre ensembles : - les analystes impliqués dans l analyse des exigences - les développeurs impliqués dans la conception et implémentation.- les testeurs testent l application - les managers gèrent le processus - puis les autres

30 Exemple d un Workflow

31 Modèle statique du RUP Projet 9 Discipline (30) Role responsabilité (56) Activité produit (100) Livrable (artefact) (67) (8) (26) Chef de Projet Analyste Système Architecte Document Modèle Elément

32 Enchaînement d activités dans RUP Modélisation du métier Il a pour but de décrire la structure et la dynamique de l'organisation (ou de l équipe participative) de garantir que les clients, les utilisateurs finaux et les développeurs partagent une vision commune de l'organisation de réaliser une base d'information qui contiendra le cahier des charges du produit et la planification des tâches de l organisation.

33 Workflow modélisation métier

34 Artefacts et rôles de la modélisation Métier

35 Artefacts et rôle de la modélisation Métier Concepteur Métier (Business Designer)

36 Enchaînement d activités dans RUP Gestion des exigences Il a pour but de définir une vision du produit, de traduire cette vision en un modèle de cas d'utilisation, (ce modèle, accompagné des spécifications externes, constitue le cahier des charges logicielles), d organiser et de gérer les exigences, de définir et de construire une maquette de l'interface utilisateur.

37 Workflow gestion des exigences

38 Artefacts et rôles gestion des exigences...

39 Enchaînement d activités dans RUP Analyse et conception L'objectif de l'analyse est de comprendre le cahier des charges et d écrire les spécifications internes. L'analyse permet d'obtenir une vue interne du produit La conception a pour but de définir l'architecture du système/produit L'analyse se concentre sur le "quoi faire", la conception se concentre sur le "comment le faire".

40

41 Artéfacts et rôles Analyse & Conception...

42 Analyse & Conception...

43 Enchaînement d activités dans RUP Implémentation L'objectif est de créer les composants : sources, scripts, puis exécutables...

44

45 Artéfacts et rôles Implémentation...

46 Enchaînement d activités dans RUP Test La phase de test a pour objectif d'évaluer le niveau de qualité atteint par le produit et d'en tirer les conclusions. Elle s'appuie sur les cas d'utilisation et définit des cas de test.

47

48 Test...

49 Enchaînement d activités dans RUP Déploiement Le but de l'enchaînement des activités de déploiement est de livrer le produit aux utilisateurs finaux.

50

51 Déploiement...

52 Enchaînement d activités dans RUP Gestion de projet La planification d'un projet itératif La gestion des risques Le contrôle des progrès.

53

54 Gestion de Projet...

55 Enchaînement d activités dans RUP Gestion de la configuration et des changement Le but de la gestion de la configuration et des changements est de garder la trace de tous les éléments tangibles qui participent au développement, et de suivre leur évolution.

56

57 Gestion de Configuration et Changement

58 Enchaînement d activités dans RUP Environnement Il a pour but de fournir un processus de développement adapté au projet des outils de travail qui aident à réaliser les activités et les artefacts du processus.

59

60 Environnement

61 Les phases RUP Démarrage Élaboration Construction Transition temps Le Processus RUP comprend quatre phases : Démarrage - Définit le champ d action du projet Élaboration Le plan du projet, il spécifie les exigences, les bases de l architecture Construction Réalise le produit Transition - Transfère le produit vers les utilisateurs finaux

62 La phase inception Détermination de la vision globale du système à construire Identification des principaux cas d utilisation Identification de l architecture candidate Maîtrise des coûts, des délais et des risques

63 La phase d élaboration Définition des détails des exigences Conception, implémentation et validation de l architecture Tests des scénarios critiques Réduction des risques et estimation des délais et des coûts Affinage du plan de développement

64 La phase de construction Développement itératif du système complet Réalisation et exécution des tests unitaires,et d intégration

65 La phase de transition Exécution des bêtas tests Formation des utilisateurs Déploiement et test de réception

66 Itérations Une phase peut-être divisée en itérations Circuit complet de développement résultant en une livraison (interne ou externe) d un produit exécutable un sous-ensemble du produit final en cours de développement, qui croît incrémentalement d itération en itération pour devenir le système final Chaque itération au sein d une phase aboutit en une livraison exécutable du système

67 Itérations Importance différente de chaque discipline en rapport avec la phase Répartition de la charge de travail dans chaque discipline au cours de la progression d itération en itération suivant chacune des 4 phases

68 Enchaînement des phases et principaux jalons

69 Interface

70 Projet de Déploiement RUP RUP est un modèle standard de processus pour : Grands projets ( > 10 années.homme) Parfait car il détaille tous les rôles du projet Doit être complété par les contraintes de l organisation Petits et Moyens projets ( < 10 années.homme) Doit être fortement simplifié (garder l essentiel) Doit être outillé si le nombre de projets est important

71 Exemples de bonnes pratiques Une petite application support Une application classique de commerce électronique dans laquelle les clients peuvent acheter des ouvrages sur le web en les ajoutant à leur panier électronique. Lorsque les clients souhaitent régler leurs achats, ils valident leur panier. Le prix du panier est alors calculé et le paiement de la commande peut être effectué.

72 Diagramme de cas d utilisation

73 Traçabilité des exigences On devrait maintenir au cours du projet des dépendances de traçabilité entre les besoins des utilisateurs et les artefacts traduisant ces besoins en exigences

74 Quelques dépendances de traçabilité entre les modèles UML dans RUP

75 Mise en œuvre des outils de gestion des exigences Les principaux outils actuels de gestion des exigences sont : DOORS (Telelogic) RequisitePro (IBM Rational) CaliberRM (Borland)

76 Un exemple de matrice de traçabilité entre cas d utilisation et exigences

77 Mise en place d un système de gestion du changement intégré selon RUP La gestion des changements s appuie sur les outils de gestion de configuration qui permettent : - d archiver les différentes versions d un artefact ; - de contrôler les autorisations d accès et de changements sur les artefacts. Ces outils s appuient sur une base de données (project repository) stockant les artefacts et leurs versions, éventuellement associée à des métadonnées.

78 Planification du projet en itérations Afin d identifier et lever les risques majeurs au plus tôt, le chef de projet doit donc prendre en compte de façon combinée la priorité fonctionnelle et l estimation du risque : Si priorité haute et risque haut :planifier le cas d utilisation dans une des toutes premières itérations. Si priorité basse et risque bas : reporter le cas d utilisation aux dernières itérations. Si les deux critères antagonistes : ne faudrait-il pas favoriser le cas d utilisation risqué?

79 3. Comparaison des processus de développement 3.1. Extreme Programming XP 3.2. Le processus en Y 2TUP 3.3. Convergence des processus

80 XP : une méthode strictement itérative Développements selon un système d itérations imbriquées de courtes durées : - des itérations de développement : réalisation progressive des fonctionnalités exprimées par le client. - des itérations de livraison (composées de 2 à 3 itérations de développement) qui produisent une version stabilisée du logiciel.

81 Le jeu de la planification (planning game) Le travail de planification (de livraison ou de développement) est traité comme un jeu qui comprend : - des pièces : les scénarios utilisateurs - un but : implémenter le plus possible de fonctionnalités exprimées par le client ; - des joueurs - des actions

82 Une journée de travail d un programmeur XP Le rôle du programmeur XP cumule les rôles d analyste, de concepteur et d implémenteur (souvent distincts dans les autres processus de développement)

83 Cycle de développement en Y - 2TUP

84

85 RUP : une bonne méthodologie et un outil prêt à l emploi Points forts : - Spécifie le dialogue entre les différents intervenants du projet : les livrables, les plannings, les prototypes.. - Propose des modèles de documents et des canevas pour des projets types Points faibles : - Coûteux à personnaliser - Très axé processus, au détriment du développement.

86 Projection de XP et de 2TUP sur la matrice de RUP Dans le cas d un projet nouvelles technologies, on peut par exemple intégrer : - les valeurs dde XP et quelques règles ( communication, simplicité, feedback ) - les documents types du RUP et leur enchaînement - la branche technique du 2TUP

87 Quelques références bibliographiques 1. P. Kruchten et P. Kroll : Guide pratique du RUP, Campus Press J.L Bénard et al. Gestion de projet Extreme Programming, Eyrolles T. Cros Maîtriser les projets avec l Extreme Programming Pilotage par les tests-clienst, Cépaduès P. Roques «UML2 Modéliser une application web» Les Cahiers du programmeur 3ème édition Eyrolles 2007