Le Processus Unifié de Rational Laurent Henocque Enseignant Chercheur ESIL/INFO France

Présentation au sujet: "Le Processus Unifié de Rational Laurent Henocque Enseignant Chercheur ESIL/INFO France"— Transcription de la présentation:

1 Le Processus Unifié de Rational Laurent Henocque http://laurent.henocque.free.fr/ Enseignant Chercheur ESIL/INFO France http://laurent.henocque.perso.esil.univmed.fr/ mis à jour en Novembre 2006

2 Licence Creative Commons Cette création est mise à disposition selon le Contrat Paternité-Partage des Conditions Initiales à l'Identique 2.0 France disponible en ligne http://creativecommons.org/licenses/by-sa/2.0/fr/ ou par courrier postal à Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

3 Références Le site Wikipedia: http://en.wikipedia.org/wiki/Rational_Unified_Process et les références associées

4 Objectif de ce document : présenter le Processus Unifié de Rational Définir ce qu’est un processus de développement logiciel Décrire le processus unifié de Rational Expliquer les 4 phases du processus unifié de Rational et leurs jalons associés Définir les itérations et leurs relations Expliquer les relations entre : –Les modèles et les enchaînements d’activités –Les phases, itérations, et enchaînements d’activités Définir artéfacts, rôles, activités Evaluer l’importance des outils logiciels

5 A quoi sert un processus logiciel ? Un processus logiciel fournit une approche pour assigner des tâches et des responsabilités à l’intérieur d’une organisation. Un processus permet la production d’un logiciel de haute qualité avec un temps et un budget limité.

6 Dans la construction d’un système, un langage ne suffit pas. Langage de Modélisati on Processus unifié Équipe de développement UML n’est pas un standard pour les processus de développement logiciel.

7 Qu’est ce que UML ? Le Langage unifié de Modélisation (UML) est un langage pour Spécifier Visualiser Construire Documenter Le choix d’un modèle a une profonde influence sur la façon dont un problème est traité et dont la solution est conçue.

8 Histoire d’ UML 1994 : OMT, Booch 1995 : Unified Method 0.8 (Dr. Ivar Jacobson) 1996 : UML 0.9 (Use-Case) 1997 : UML 1.0 (Microsoft, Oracle, IBM, HP) 1997 : UML 1.1 2004 : UML 2.0

9 UML est aujourd’hui le langage standard industriel de modélisation. Son développement à été lancé par trois leaders dans l’industrie de l’approche objet : Grady Booch Ivar Jacobson Jim Rumbaugh. UML est en développement depuis 1990. Histoire d’UML

10 Les contributions à UML Fusion La description des opérations, Le nombre de messages Meye r Conception par contrat - invariants Hare l Diagrammes à état Wirfs- Brock Les responsabilités Emble y Les classes singletons, Odell Les classification Shlaer - Mellor Les cycles de vie Gamma, et.al Frameworks, patterns, notes Booch Jacobson Rumbaugh

11 Le développement d’UML à été fait par un large échantillon de l’industrie : HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI Systemhouse, Microsoft, ObjectTime, Oracle, Platnium, Technology, Ptech, Reich Technologies, Softeam, Sterling Software, Taskon, et Unisys. Les contributions à UML

12 UML fournit des diagrammes standardisés Diagramme s De déploie ment Diagramme s De déploie ment Use-Case Diagrams Use-Case Diagrams Use-Case Diagrams Use-Case Diagrams Diagrammes de cas d’utilisation Diagrammes de cas d’utilisation Scenario Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Diagramme s De séquenc es Diagramme s De séquenc es State Diagrams State Diagrams State Diagrams State Diagrams Diagramme s D’états Diagramme s D’états Component Diagrams Component Diagrams Component Diagrams Component Diagrams Diagrammes De compos ants Diagrammes De compos ants Modèles State Diagrams State Diagrams State Diagrams State Diagrams Diagramme s D’objet Diagramme s D’objet Scenario Diagrams Scenario Diagrams Scenario Diagrams Scenario Diagrams Diagramme s De collabor ation Diagramme s De collabor ation Use-Case Diagrams Use-Case Diagrams Use-Case Diagrams Use-Case Diagrams Diagrammes D’activité Diagrammes D’activité State Diagrams State Diagrams State Diagrams State Diagrams Diagramme s De Classe Diagramme s De Classe

13 Représentation sous différents angles de vue d’un système Les diagrammes de cas d’utilisation pour illustrer les interactions des utilisateurs avec le système Les diagrammes de classes pour illustrer la structure logique Les diagrammes d’objets pour illustrer les objets et les liens Les diagrammes d’états pour illustrer leur déroulement Les diagrammes de composant pour illustrer les structures physiques du logiciel Les diagrammes de déploiement pour montrer la répartition du logiciel pour les configurations hardware Les diagrammes d’interactions (i.e., les diagrammes de collaboration et de séquence) pour illustrer leur comportement Les diagrammes d’activité pour illustrer le déroulement des activités dans un cas d'utilisation.

14 Un diagramme représentatif d’UML : Cas d’utilisation Un système d’enregistrement aux cours dans une université Le professeur Choix de cours à enseigner l’étudiant Catalogue de cours Enregistrement aux cours Mise à jour des informations des étudiants Mise à jour des informations des professeurs Dir. Etudes Système de paie Arrêt des enregistrements

15 Les diagrammes d’utilisation sont utilisés pour montrer l’existence de cas d’utilisation. Un acteur est une entité extérieure au système qui à une interface avec le système, tel qu'un utilisateur. Un cas d’utilisation modélise un dialogue entre les acteurs et le système. Il est initialisé par un acteur. Diagrammes de cas d’utilisation

16 Un système d’enregistrement aux cours dans une université Ecra n // gérerUnEmploiDuTemps() > Ecran Gestion Edt + // ouvrir() + // choisir 4 cours obligatoires et 2 facultatifs > 1 0.. 1 1 CatalogueCour s liste des cours() > 10.. * ControlleurEnregistremen t ajout de cours() lire la liste des cours() > 1 1 Plannin g créer un cours() > 1 0.. 1 Un diagramme de classes

17 Les diagrammes sont les artefacts clés Acteur A Use-Case 1 Use-Case 2 Acteur B Documen t FileManage r GraphicFil e Fil e Repository DocumentLis t FileLis t Customer name addr withdraw() fetch() send() receive() > Forward Engineering(Code Generation) and Reverse Engineering Programme exécutable Définition d’une interface utilisateur Expert du Domaine Use-Case 3 Codage, compilation, debugage, édition de lien Diagramme de cas d’utilisation Diagramme de classe Diagramme de Collaboration Diagramme de séquence Diagramme de composant Diagramme d’état transition Diagramme de paquetage Diagramme de déploiement Classe

18 UML fournit un langage unique et commun de modélisation utilisable à travers plusieurs méthodes, Il définit le lien entre les coûts, les exigences et l’analyse, le design, l’implémentation, et les tests. UML facilite la communication entre tous les membres de l’équipe de développement. Les diagrammes sont les artefacts clés

19 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 Système nouveau ou amélioré Processus d’ingénierie logicielle

20 Un Processus Efficace… Fournit les lignes directrices pour un développement efficace d’un logiciel de qualité Réduit les risques et améliore les prévisions Décrit les meilleures méthodes de travail pour –apprendre des expériences précédentes –l’amélioration du support de formation Établit une vision et une culture commune L’objectif d’un processus est de produire un logiciel de haute qualité en respectant des contraintes de délai, de coûts et de performance

21 Facilité de mise en œuvre : grâce aux six meilleures pratiques de Rational, le processus est facile à mettre en oeuvre. Il dicte au développeur comment implémenter en utilisant les outils standards de développement. Un Processus Efficace…

22 Le Processus Unifié de Rational permet les Meilleures Pratiques (Best Practices) Le processus Unifié Rational décrit comment appliquer les six directives de l’ingénierie logicielle Contrôler le Changement Contrôler le Changement Utiliser le Développement Itératif (Ré)Utiliser Composants Architecture s Analyser les Besoins Mode ler Visue lleme nt (UML ) Contrôler la Qualité

23 Les six meilleures pratiques fournissent les bases pour le Processus Unifié de Rational. Cependant, cette application nécessite des instructions étapes par étapes. Ces instructions sont fournies dans le Processus Unifié de Rational, qui comprend toutes les activités devant être appliquées pour construire un logiciel Le Processus Unifié de Rational permet les Meilleures Pratiques (Best Practices)

24 Processus Unifié Rational Un processus centré sur l'architecture et la vue 4+1

25 Processus Unifié de Rational dans un “cas d’utilisation” Encaissement Clien t Un acteur est une entité hors du système qui interagit avec le système Un Cas d’utilisation est une séquence d’actions que le système exécute qui retourne un résultat à un certain acteur Contrôle de la balance Cas d’utilisation pour une caisse

26 Le processus Unifié de Rational gère les besoins via les diagrammes de Cas d’utilisation. Ils sont utilisés à travers le cycle de développement pour beaucoup d’activités, et fournissent de l’information à travers plusieurs modèles. Un acteur peut-être un être humain ou un autre système ou un appareil; tout ce qui est extérieur au système et interagissant avec lui. Les cas d’utilisation représentent toutes les façons possibles d’utiliser le système. Processus Unifié de Rational dans un “cas d’utilisation”

27 Les “Cas d’utilisation” incluent les Flots d’évènements Exemple : flot d’évènements dans le cas d’un retrait d’argent 1. Le “cas d’utilisation” commence quand le client insère sa carte de payement. Le système lit et valide les informations sur la carte. 2. Le système lit le code PIN. Le système valide le code PIN. 3. Le système demande au client quelle opération il veut exécuter. Le client choisi “Retrait d’argent” 4. Le système demande le montant. Le client entre le montant. 5. Le système demande le type de compte. Le client choisi “vérifier et enregistrer”. 6. Le système communique avec le réseau ATM...

28 Les apports des “Cas d’utilisation” Les “Cas d’utilisation” sont concis, simples, et compréhensibles par une large gamme de participants –Utilisateurs finaux, développeurs et acquéreur comprennent les exigences fonctionnelles du système Les “Cas d’utilisation” permettent bon nombre d’activités dans le processus : –La création et la validation de la conception du modèle –La définition de cas de test et de procédures du modèle de test –Le planning des itérations –La création de documentation utilisateur –Le déploiement du système Les “Cas d’utilisation” permettent de synchroniser le contenu de plusieurs modèles

29 Le processus Unifié de Rational est Architecture-Centré L'architecture est le point traité pendant les premières itérations –Construire, valider, et fonder l’architecture constituent le premier objectif de l’élaboration Le Prototype Architectural valide l’architecture et sert de base pour le reste du développement Le document de l’architecture logicielle est le premier artefact qui décrit l’architecture choisie D’autres artéfacts dérivent de l’architecture : –Documents de conception qui comprennent l’utilisation de patterns et d’idiomes –La structure du produit –La structure de l'équipe

30 Le processus Unifié de Rational est Architecture-Centré L’architecture est utilisée dans le Processus Unifié de Rational comme un artefact primaire pour conceptualiser, construire, gérer, et élaborer le système en développement. Le Processus Unifié de Rational considère le développement et la validation d’une architecture logicielle comme le concept primordial. Il définit 2 artefacts primaires : –la description de l’architecture logicielle qui décrit l’architecture du projet –le prototype de l’architecture.

31 Représentation de l’architecture : Le Modèle 4+1 Vue du processus Vue de déploiement Vue logique Vue d’implémentation Programmeurs Génie logiciel Performance Échelles de mesure Capacité de traitement Intégrateurs systèmes Topologie du système Livraison, installation communication System Engineering Cas d’utilisation Structure Analystes/ Concepteurs pour l’utilisateur final Fonctionnalités

32 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. Représentation de l’architecture : Le Modèle 4+1

33 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. Représentation de l’architecture : Le Modèle 4+1

34 Les bénéfices d’un processus Architecture-Centré Gagner et conserver un contrôle intellectuel sur le projet, contrôler sa complexité, et maintenir l’intégrité du système. Fournir une méthode pour une réutilisation à grande échelle Fournir des bases pour la gestion de projet Faciliter le développement par composant –Un composant remplit une fonction définie dans le contexte d’une architecture bien définie –Un composant fournit la réalisation physique d’une série d’interfaces –Les composants existent dans une architecture donnée

35 Processus Unifié Rational Le processus dans le temps

36 Démarrag e Élaboratio n Constructio n Transition Architecture du Processus – Les Cycles de vie Le Processus Unifié de Rational comprend 4 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 temp s

37 Durant l’étude d’opportunité (démarrage), nous définissons l’objectif du projet. –en identifiant tous les acteurs et les cas d’utilisation, et en dessinant les cas d’utilisation essentiels (20% du modèle). –Un plan de gestion de projet est fait pour déterminer les ressources nécessaires pour le projet. Durant l’élaboration, on se concentre sur deux choses : –avoir une bonne connaissance des besoins (90%) et –établir une base de l’architecture. Ainsi, on peut éliminer beaucoup de risques, avoir une bonne idée de ce qui doit être fait, et une bonne estimation des ressources et des coûts. Architecture du Processus – Les Cycles de vie

38 Durant la Construction, on développe le produit en plusieurs itérations pour une version bêta. Durant la Transition, on prépare le produit pour l’utilisateur final et la formation, l’installation, le support. Pour un projet très complexe l’élaboration peut inclure jusqu’à 3-5 itérations. Architecture du Processus – Les Cycles de vie

39 Le Processus Unifié De Rational : Vision temporelle DémarrageÉlaboration ConstructionTransition Évaluation des objectifs Évaluation de l’architecture Évaluation du produit Validation du produit temp s

40 RUP et Vision Temporelle: phase de démarrage Première analyse des fonctionnalités (diagramme d’utilisation) Évaluer les risques (coût, concurrence) Critères d’évaluation : Concurrence Première validation des besoins Évaluation des coûts, priorités, risques, du processus de développement, des frais réels par rapport aux frais prédits.

41 RUP et Vision Temporelle: phase d’élaboration Planifier les activités nécessaires et les ressources requises. Définir précisément les fonctionnalités de l’application. Concevoir l’architecture. Critères d’évaluation : Stabilité du produit et de la conception. Résolution des problèmes critiques. Évaluation des coûts, du planning. Validation du produit.

42 RUP et Vision Temporelle: Phase de Construction Construire le produit comme une série d’itérations incrémentales. Critères d’évaluation : Stabilité et maturité des réalisations (en vue du déploiement) Capacité de mettre en œuvre la transition. Coûts acceptables.

43 RUP et Vision Temporelle: Phase de Transition Fournir le produit aux utilisateurs 1.Fabrication 2.Livraison 3.Formation Critères d’évaluation : Validation des besoins (Recette)

44 RUP et Vision Temporelle: Jalons d’Évaluation Après chacune des quatre phases on évalue les activités grâce à des critères spécifiques: Évaluation Coût/risque réaliste. Validation du produit. Architecture valide et réalisable. …

45 RUP Et Vision Temporelle: Sous Jalons D’évaluation et Itérations Chaque phase peut elle-même comporter des ([0..N]) jalons. Entre deux jalons, on parle d’itérations. Une itération est est une séquence d’activités planifiées et pouvant être vérifiées grâce à un critère d’évaluation. But : vérifier les activités au fur et à mesure. Deux types : –Internes : au sein de l’équipe de développement. –Externes: avec le client et idéalement les utilisateurs finaux

46 Processus Unifié Rational Rôles et Activités

47 RUP et vision par activités 1.La modélisation métier : possibilités du système et besoins des utilisateurs. 2.La modélisation des besoins : vision du système et besoins détaillés des utilisateurs. 3.L’analyse et la conception : manière dont sera réalisé le projet au cours de la phase 4. 4.L’implémentation : production et acquisition des composants du système et des exécutables. 5.Les tests : vérification du système dans son ensemble. 6.Le déploiement : livraison du système et formation des utilisateurs.

48 Les 2 Visions Rassemblées: Le Modèle Itératif Modélisation métier Gestion de projet Environnement Modélisation des besoins Analyse et conception Implémentation Tests Déploiement Gestion de Configuration et des Evolutions Flux de gestion Flux (workflow) du processus Iter. #1 Iter. #2 DémarrageÉlaborationConstructionTransition Iter. #n Iter. #n+ 1 Iter. #n+ 2 Iter. #m Iter. #m+ 1

49 RUP : Définitions et Notations(1/2) Artéfact : Élément d’information, produit ou utilisé lors d’une activité de développement logiciel (modèle, source...) Activité : Opération exécutée au sein d’un état. Une activité peut être interrompue. Rôle : Comportement et responsabilités d’un ensemble de personnes.

50 RUP : Définitions Et Notations(2/2) paquetage des cas d’utilisation Cas d’utilisation Responsable de Analyste Cas d’utilisation Décrire un cas d’utilisation

51 Les Rôles Dans La Planification Des Ressources Ressource Paul Marie Joseph Sylvia Stefanie Chaque individu est associé à un ou plusieurs rôles. Rôle Concepteur Rédacteur. D.Utilisation Analyste Système Développeur. Architecte Activités Définir Opérations Détailler le D. Utilisation Trouver Acteurs et Cas Util. Réaliser les tests des unités. Concevoir.

52 Modélisation Métier Pour comprendre la dynamique et la structure de l’organisation. Pour vérifier que les clients, les utilisateurs finaux, et l’équipe ont une vision commune exacte de l’organisation. Pour vérifier la concordance entre les besoins et l’organisation.

53 La modélisation métier Analyste de la modélisation métier Lister le vocabulaire commun Trouver les acteurs et les cas d’utilisation Finaliser les cas d’utilisation Concepteur métier Détailler les cas d’utilisation Trouver les entités et les acteurs métier Détailler les acteurs métier Détailler les entités métier Vérificateur Modèle métier Revoir les modèles métier des cas d’utilisation Revoir les modèles métier des objets

54 Modélisation Des Besoins Valider les fonctionnalités du système avec le client et les utilisateurs. Donner à l’équipe de développement une idée des besoins auxquels le système doit répondre. Définir les limites du système. Définir une base pour planifier les activités associées à chaque itération. Définir une IHM du système.

55 Modélisation Des Besoins Analyste système Analyste Cas d’utilisation Concepteur IHM Architecte Responsable Validation besoins Développer Vision Coordonner les dépendances Définir les besoins pour les jalons Lister le vocabulaire commun Trouver les acteurs et cas d’utilisation Structurer le modèle cas d’utilisation Détailler les cas d’utilisation Définir IHM Hiérarchiser les cas d’utilisation Prototyper IHM Vérifier les besoins

56 Modélisation Des Besoins : Artefacts Un document de vision. Un document listant les besoins de chaque jalon. Un document sur les cas d’utilisation Un document de spécification supplémentaire : ce que va faire précisément le système. Glossaire Story-board des cas d’utilisation. Une charte graphique…

57 Analyse et Conception Passer des besoins à une architecture concrète. Concevoir une architecture robuste pour le système Permettre que le système soit adapté à son environnement.

58 Analyse et Conception Architecte Concepteur Base de données Concepteur Responsable vérification architecture Responsable vérification conception Analyser l’architecture Analyser les cas d’utilisation Concevoir les sous systèmes Concevoir les classes Concevoir les cas d’utilisation Planifier la vérification conception Concevoir la base de données Planifier la vérification architecture Concevoir l’architectureDéfinir la concurrence Définir le déploiement

59 Analyse et Conception : artéfacts Le modèle de conception Les descriptions de cas d’utilisation Les descriptions de classes L’organisation en sous système Les documents sur l’architecture logicielle Le modèle de données

60 Implémentation Définir l’organisation des modules et des sous systèmes implémentés. Implémenter les composants (classes et objets). Tester les composants un par un. Utiliser les composants produits par différentes personnes pour construire le système.

61 Implémentation Intégrer Système Architect e Responsabl e intégration système Développeu r Responsable vérification Code Implémenter les Classes Tester les unités Structurer le Modèle d’implémentation Intégrer les sous systèmes Vérifier le Code Fixer les solutions Planifier l’intégration du système Planifier L’intégration des Sous-systèmes

62 Implémentation : Artéfacts Le modèle d’implémentation qui définit les composants. Les composants. Le plan d’intégration des composants.

63 Tests Vérifier les interactions entre les composants. Vérifier l’intégration des composants logiciels. Vérifier que tous les besoins ont été correctement implémentés. Identifier les défauts et les signaler au déploiement.

64 Tests Concevoir Tests Tester implémentation Concepteur des tests Evaluer Tes t Tests d'Intégration Tests Système Concevoir les classes de Test et Packages Implémenter le sous système de tests Planifier Tests Tests de Performance Testeur de l’intégration Testeur système Testeur performances Concepteur développeur

65 Tests : Artéfacts Modèle de test : définition et procédures. Planification des tests. Revue de défauts. Tests des paquetages, classes, sous systèmes, et composants.

66 Gestion de projet Définir un environnement de travail pour la gestion de projet. Fournir des documents à propos de la planification, de la répartition des tâches, de l’exécution et de la vérification des projets. Définir un environnement de travail pour la gestion des risques.

67 Gestion de projet Mener une étude de cas métier Chef de projet Développer plan de gestion de projet Réviser la liste des risques Identifier Les Risques Planifier l’itération Exécuter l’itération Vérifier l’itération Réunir Équipe

68 Gestion De Projet : artéfacts La procédure de développement logiciel (Liste des risques, plan de projet et procédure d’actions) Les cas d’utilisation métier La planification des itérations L’estimation des itérations L’estimation des statuts

69 Déploiement Permet de faire évoluer correctement (Erreurs, spécifications…) les systèmes logiciels au cours de leurs différentes versions. Lister les différentes versions des composants utilisés au cours des différentes versions du logiciel.

70 Déploiement Architecte Chef de projet Responsable gestion du changement Tout membre de l’équipe Intégrateur Définir les processus de changement de produit Définir les besoins des report et préservation des statutsStructurer le modèle de déploiementConstruire le produit Créer un espace de travail pour l’intégration Créer un espace de travail personnelVérifier les artéfacts d’E/S S’attacher aux points sensibles de la configuration Rédiger le plan de gestion de changement Définir le modèle de déploiement Délimiter les espaces de travail Documenter le défaut Fonder le produit Livrer les sous-systèmes

71 Déploiement : avantages Encourager les bonnes méthodes de développement. Maintenir l’intégrité du produit. S’assurer de la complétude et de la correction du produit déployé. Fournir un environnement de développement stable. Limiter les changements des artéfacts dus aux règles internes (policy) du projet. Permettre de suivre les changements des artéfacts.

72 Processus Unifié Rational Points de vue extérieurs

73 Point de vue sur le Workflow Déployer les processus. Améliorer les processus. Sélectionner les bons outils et les maîtriser. Développer des outils. Aider le développement. S’entraîner.

74 Règles, Tutoriaux et Modèles Les règles sont les obligations, recommandations, les heuristiques qui aident l’exécution des activités. ex: règles de codage Les tutoriels aident à l’apprentissage des outils utilisés lors des activités. ex : Tutoriels de Rationnal Rose ou Poseidon Les modèles (formulaires) sont des artéfacts prédéfinis. Ex : Un document ayant déjà une structure à remplir. Leur but est de rendre l’exécution des activités plus facile et que les processus soient correctement menés à bien.

75 Liste d'Outils D’aide Au Développement. Activités de base Modèle métier Besoins Analyse et conception ImplémentationTestDéploiement Config. & Changement Gestion de projet Environnement Environnement Requisite Pro, Rose, SoDA Rose, Apex, SoDA, Purify,... SQA TeamTest, Quantify, PerformanceStudio,... ClearCase, ClearQuest Rose, SoDA, Apex Unified Process, Rational Tools SoDA, ClearCase,... Activités de support Requisite Pro, Rose, SoDA Unified Process, Microsoft® Project,...

76 Suivre Un Processus Il faut adapter et exécuter le processus. Adapter suivant les besoins et les contraintes de l’organisation. Cela fournit un document avec le contexte, les limites, une évaluation de la proportion des changements par rapport au processus initial… Exécuter en faisant les changements nécessaires dans le processus.

77 RUP : Résumé(1/3) UML est un langage de spécification, visualisation, construction, et documentation des artéfacts d’un système à composante logicielle. Un processus de développement logiciel répond aux questions qui, quoi quand et comment.

78 RUP : Résumé(2/3) Le RUP a quatre phases : démarrage, élaboration, construction et transition. Chaque fin de phase est ponctuée par un jalon principal et la fin d’une ou plusieurs itérations. Une itération est une suite de diverses activités qui ont été planifiées, ayant des critères d’évaluation, et pouvant être exécutées.

79 RUP : Résumé(3/3) Chaque enchaînement d’activité dure une itération et s’inscrit dans un modèle incrémental. Artéfact : Élément d’information, produit ou utilisé lors d’une activité de développement logiciel(modèle) Activité : Opération exécutée au sein d’un état. Une activité peut être interrompue. Rôle : Comportement et responsabilités d’un ensemble de personnes