Omar EL BEGGAR

Enseignant Chercheur FSTM

Filière ILISI

1
[1] Philippe Kruchten, 1999 , Introduction au Rational Unified Process, Editions
Eyrolles.
[2] Henocque Esil, Info 2006 ,Processus Unifie Rational
[3] Pierre Gérard,2008,Processus de Développement Logiciel
[4] http://www.rational.com/
[5] documents templates:
http://sce.uhcl.edu/helm/RationalUnifiedProcess/process/templates.htm

2
• Comparer le développement linéaire et itératif
• Définir un processus de génie logiciel
• Décrire le processus unifié de Rational
• Expliquer les phases du processus unifié de Rational et les
différentes activités associées
• 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
• Introduire les outils logiciels de Rational 3
Les phases du développement linéaire se suivent dans
l'ordre et sans retour en arrière.
Problèmes des cycles linéaires
• Risques élevés et non contrôlés
• Identification tardive des problèmes
• Preuve tardive de bon fonctionnement

Cycle en cascade
4
Améliorations : construction itérative du système
 Les risques sont évalués avant
• Chaque itération produit un nouvel incrément
• Chaque nouvel incrément a pour objectif la maîtrise d'une
partie des risques et apporte une preuve tangible de
faisabilité ou d'adéquation
• Enrichissement d'une série de prototypes Les versions livrées
correspondent à des étapes de la chaîne des prototypes
• Le test et l’intégration sont continus

• Production itérative d'incréments:

• Itérations 0 1 2 3 4 5 6 7
• A chaque itération, on refait:
1. Spécification
2. Conception
3. Implémentation
4. Test

5
 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é.

Processus ou Méthode = Démarche + Langage

Exemple : La méthode MERISE fournit un langage de modélisation graphique

(MCD, MPD, MOT, MCT...) ET Une démarche à adopter pour le développent d’un
logiciel.
UML n'est qu'un langage
Méthodes s'appuyant sur UML:
• RUP (Rational Unified Process) - par les auteurs d'UML
• XP (eXtreme Programming) - pouvant s'appuyer sur UML
6
Dans la construction d’un système, un langage ne suffit pas.

S’appuie

RUP
• Chef de projet • Langage de
• Analyste
Équipe du projetmodélisation
• Designer
• Processus orienté objet
• Infographiste
• … Equipe du
UML
projet

adopte
Langage de
RUP c’est un guide d’utilisation d’UML.
Modélisation RUPpermet de mettre en
OO Ce processus
œuvre le langage UML.
7
• 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
 State
State
Diagrams
Diagrammes
Diagrams
Use-Case De Classe
Use-Case
Diagrammes
Diagrams State
Use-Case Diagrams
de cas State
Diagrams
Use-Case Diagrammes
Diagrams
Diagrams
Diagrammes d’utilisation D’objet
Diagrams
D’activité

Scenario State
Scenario
Diagrams State
Diagrams
Diagrammes
Diagrams Diagrammes
Diagrams
De séquences Modèles D’états

Scenario Component
Scenario
Diagrams
Component
Diagrams
Diagrammes
Diagrammes
Diagrams Diagrammes Diagrams
De collaboration De déploiement De composants

9
 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 Processus d’ingénierie Système nouveau

ou améliorées Logicielle en avant ou amélioré

10
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

• 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

11
 Facilité de mise en œuvre : grâce aux six meilleures pratiques de
Rational, le processus est facile à mettre en œuvre:
1. Développement itérative du logiciel
2. Gestion des exigences
3. Utiliser une architecture basé sur les composants
4. Modélisation visuelle du logiciel
5. Vérifier la qualité logiciel
6. Contrôler les changements du logiciel

 Il dicte au développeur comment implémenter en utilisant les

outils standards de développement.

12
 Rational Unified Process ou Processus unifié de Rational (RUP)
est une démarche de développement qui est souvent utilisée
conjointement au langage UML.

 RUP utilise les éléments de base suivants:

• QuiTravailleur ou Responsable (Worker)
• QuoiArtefacts
• CommentActivité
• Quand Enchaînement d’activités (Workflow)

 Rational Unified Process est:

• Piloté par les cas d'utilisation
• Centré sur l'architecture
• Itératif et incrémental

13
RUP est itératif et incrémental:
• Chaque itération prend en compte un certain nombre de cas
d'utilisation
•Les risques majeurs sont traités en priorité
•Chaque itération donne lieu à un incrément et produit une
nouvelle version exécutable

RUP est piloté par les cas d'utilisation:

• La principale qualité d'un logiciel est son utilité
(Adéquation du service rendu par le logiciel avec les
besoins des utilisateurs)
• Le développement d'un logiciel doit être centré sur l'utilisateur
• Les cas d'utilisation permettent d'exprimer ces besoins
(Détection et description des besoins fonctionnels)
(Organisation des besoins fonctionnels)

14
RUP est centré sur l'architecture:

• Modélisation de différentes perspectives indépendantes et

complémentaires

• Architecture en couches et vues de Krutchen (modèle 4+1)

15
 Exigences Analyse & conception

Implémentation
Gestion
Environnement
Planification initiale

Déploiement
Planification
Tests

Chaque itération a pour finalité une version exécutable.

16
 2003
1997 Intégré avec IBM
Rational Method
Composer
1995 Rational Unified
Process
UP et Rational Objectory
Process (V1 à 3.8)
1987
Objectory Process
initié par Ericson

Implémentation conforme au processus unifié ou Unified Process

(UP) comme d’autres (XUP, AUP, EUP, 2TUP, EssUP).
RUP propose des calendriers et plans de réalisation, des templates
de documents et gestion et affectation des équipes.
17
 RUP est un processus commercial. C’est un produit développé et
maintenu par Rational Software (IBM) qui est parfaitement
intégré à l'ensemble des outils de développement logiciel
proposés par la société.

 Il est disponible sur CD-R ou via l'Internet. Il utilise la technologie

du web, de sorte qu'il est littéralement à portée de tous les
membres du projet. Il contient :
• Un manuel d’introduction
• Des guides d'utilisation d'outils
• Des canevas (templates) pour tous les artefacts importants du processus
• …

 Le Rational Unified Process est aussi un framework de processus

que l'on peut adapter et étendre pour tenir compte des besoins
de l’organisation qui l'adopte. 18
19
Processus Unifié Rational

Un processus centré sur

l'architecture et la vue 4+1

20

Client Acheter des produits
Consulter catalogue
Cas d’utilisation pour une
application e-business
Un acteur est un rôle joué
par une personne, un
système ou autre chose qui
interagit avec le logiciel
Un Cas d’utilisation est une
unité cohérente d’actions
exécutées de bout en bout
afin de retourner un résultat
observable à un certain
acteur
21
• 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.
22
Exemple : flot d’évènements dans le cas d’un retrait d’argent
1. Le “cas d’utilisation” commence quand le porteur de la carte
insère sa carte de payement. Le système vérifie 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 porteur de la carte quelle opération il
veut exécuter. Le porteur de la carte choisi “Retrait d’argent”
4. Le système demande le montant. Le client entre le montant.
5. Le système communique avec le système interbancaire . . …

23
• 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
– …

24
• 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

25
• 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.

26
 Vue Vue
logique d’implémentation

Analystes/ Fonctionnalités
Concepteurs Programmeurs
Structure pour l’utilisateur Génie logiciel
Cas
final
d’utilisation
Vue des Vue de
composants déploiement
Intégrateurs systèmes System Engineering
Performance Topologie du système
Échelles de mesure Livraison, installation
Capacité de traitement communication

27
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 (description des algorithmes, code source).

28
•La vue des composants : Description de l'architecture
logicielle (concerne les aspects concurrents du système à
l’exécution: taches, threads ou processus, et leur interaction).
•La vue de déploiement: Description de l'architecture
matérielle du système (montrer 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.

29
• 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

30
Processus Unifié Rational

Le processus dans le temps

31
 Inception Élaboration Construction Transition

temps

Le Processus Unifié de Rational comprend 4 phases :

– Inception- 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

32
 Phases du Processus – Inception
• Phase d'initialisation : Objectifs
• Définition du cadre du projet, son concept, et inventaire du contenu
• Elaboration des cas d'utilisation critiques ayant le plus d'influence sur l'architecture et
la conception
• Réalisation d'un ou de plusieurs prototypes démontrant les fonctionnalités décrites
par les cas d'utilisation principaux
• Estimation détaillée de la charge de travail, du coût et du planning général ainsi que
de la phase suivante d'élaboration
• Estimation des risques

• Phase d'initialisation : Activités

• Formulation du cadre du projet, des besoins, des contraintes et des critères
d'acceptation
• Planification et préparation de la justification économique du projet et évaluation des
alternatives en termes de gestion des risques, ressources, planification
• Synthèse des architectures candidates, évaluation des coûts

33
 Phases du Processus – Inception
• Phase d'initialisation : Livrables
• Un document de vision présentant les besoins de base, les contraintes et
fonctionnalités principales
• Une première version du modèle de cas d'utilisation (10% à 20% complète).
• Un glossaire de projet
• Un document de justification économique (Business case) incluant le contexte
général de réalisation, les facteurs de succès et la prévision financière
• Une évaluation des risques
• Un plan de projet présentant phases et itérations
• Un ou plusieurs prototypes

• Phase d'initialisation : Critères d'évaluation

• Un consensus sur la planification, les coûts
• la définition de l'ensemble des projets des parties concernées
• La compréhension commune des besoins

34
 Phases du Processus – Elaboration
• Phase d’élaboration: Objectifs
• Définir, valider et arrêter l'architecture
• Démontrer l'eefficacité de cette architecture à répondre à notre besoin
• Planifier la phase de construction

• Phase d’élaboration: Activités

• Elaboration de la vision générale du système, les cas d'utilisation principaux
sont compris et validés
• Le processus de projet, l'infrastructure, les outils et l'environnement de
développement sont établis et mis en place
• Elaboration de l'architecture et sélection des composants

35
 Phases du Processus – Elaboration
• Phase d’élaboration: Livrables
• Le modèle de cas d'utilisation est produit au moins à 80 %
• La liste des exigences et contraintes non fonctionnelles identifiées
• Une description de l'architecture
• Un exécutable permettant de valider l'architecture du logiciel à travers
certaines fonctionnalités complexes
• La liste des risques revue et la mise à jour de la justification économique du
projet
• Le plan de réalisation, y compris un plan de développement présentant les
phases, les itérations et les critères d'évaluation

• Phase d’élaboration: Critères d'évaluation

• La stabilité de la vision du produit final
• La stabilité de l'architecture
• La prise en charge des risques principaux est adressée par le(s) prototype(s)
• La définition et le détail du plan de projet pour la phase de construction
• Un consensus, par toutes les parties prenantes, sur la réactualisation de la
planification, des coûts et de la définition de projet

36
 Phases du Processus – Construction
• Phase de construction: Objectifs
• La minimisation des coûts de développement par l'optimisation des
ressources
• La minimisation des travaux non nécessaires
• Le maintien de la qualité
• Réalisation des versions exécutables
• Phase de construction: Activités
• La gestion et le contrôle des ressources et l'optimisation du processus de
projet
• Evaluation des versions produites en regard des critères d'acceptation définis

37
 Phases du Processus – Construction
• Phase de construction: Livrables
• Les versions exécutables du logiciel correspondant à l'enrichissement
itération par itération des fonctionnalités
• Les manuels d'utilisation réalisés en parallèle à la livraison incrémentale des
exécutables
• Une description des versions produites

• Phase de construction: Critères d'évaluation

• La stabilité et la qualité des exécutables
• La préparation des parties prenantes
• La situation financière du projet en regard du budget initial

38
 Phases du Processus – Transition
• Phase de transition: Objectifs
• Le déploiement du logiciel dans l'environnement d'exploitation des
utilisateurs
• La prise en charge des problèmes liés à la transition
• Atteindre un niveau de stabilité tel que l'utilisateur est indépendant
• Atteindre un niveau de stabilité et qualité tel que les parties prenantes
considèrent le projet comme terminé

 Phase de transition: Activités

• Activités de « packaging » du logiciel pour le mettre à disposition des
utilisateurs et de l'équipe d'exploitation
• Correction des erreurs résiduelles et amélioration de la performance et du
champ d'utilisation
• Formation des utilisateurs
• Evaluation du produit final en regard des critères d'acceptation définis

39
 Phases du Processus – Transition
• Phase de transition: Livrables
• La version finale du logiciel
• Les manuels d'utilisation

• Phase de transition: Critères d'évaluation

• La satisfaction des utilisateurs (Recette)
• La situation financière du projet en regard du budget initial

40
 Démarrage Élaboration Construction Transition

temps
Évaluation des Évaluation Évaluation Validation
objectifs de l’architecture du produit du produit

41
• Chaque phase peut elle-même comporter des
([0..N]) jalons. Entre deux jalons, on parle
d’itérations.
• Une itération 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

42
Processus Unifié Rational

Rôles et Activités

43
• Chaque phase comprend plusieurs itérations
• Pour chacune des itérations, on se livre à plusieurs activités:
1. Modélisation métier
2. Expression des besoins
3. Analyse
4. Conception
5. Implémentation
6. Test
7. Déploiement.

 Les activités sont des étapes dans le développement d'un

logiciel, mais à un niveau de granularité beaucoup plus fin
que les phases
 Chaque activité est répétée autant de fois qu'il y a
d'itérations
44
 Les 2 Visions Rassemblées: Le Modèle Itératif
Phases
Flux (workflow) du processus Démarrage Élaboration Construction Transition

Modélisation métier
Modélisation des
besoins
Activités

Analyse et
conception
Implémentation
Tests
Déploiement
Flux de gestion
Gestion de
Configuration et des
Evolutions
Gestion de projet
Environnement 45
Iter. Iter. Iter. Iter. Iter. Iter. Iter.
#1 #2 #n #n+1 #n+2 #m #m+1
6 enchaînements d'activités de
base
Modélisation du métier 3 enchaînements d'activités
de soutien
Gestion des exigences
Gestion de Projet
Analyse et Conception
Gestion de la configuration et
Implémentation
des changements
Test
Environnement
Déploiement

46
• Artéfact : Élément d’information, produit ou utilisé lors d’une
activité de développement logiciel (modèle, document, code
source, exécutable...)

• Activité : Une unité de travail, exprimée souvent en terme de

créer ou modifier un artéfact. Et elle est spécifié à un
travailleur(worker).

• Rôle : Comportement et responsabilités d’un ensemble de

personnes.

47
 Rôle
Activité

Analyste Décrire un cas

Cas d’utilisation d’utilisation

Responsable de
Artéfact

paquetage des
Cas d’utilisation
cas d’utilisation

48
Ressource Rôle Activités

Paul Concepteur Définir Opérations

Marie Rédacteur. D.Utilisation Détailler le D. Utilisation
Joseph Analyste Système Trouver Acteurs et Cas Util.
Sylvia Développeur. Réaliser les tests des unités.
Stefanie Architecte Concevoir.

Chaque individu est

associé
à un ou plusieurs rôles.

49
• 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.

50
 Trouver les
Analyste de la Lister le acteurs et les Finaliser les
modélisation cas d’utilisation Vérificateur
vocabulaire cas
métier commun d’utilisation Modèle
métier

Détailler Revoir les

les cas modèles métier
d’utilisation Détailler les des cas
d’utilisation
acteurs métier
Concepteur
métier Trouver les
entités et Revoir les
les acteurs Détailler les modèles métier
métier entités métier des objets

51
• 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.

52
 Développer Vision Définir les besoins
pour les jalons
Trouver les Structurer le Responsable
acteurs et cas modèle cas
Analyste Validation
Coordonner les Lister le vocabulaire d’utilisation d’utilisation
système
dépendances commun
besoins

Détailler les cas

d’utilisation
Analyste Cas d’utilisation Vérifier les
besoins

Définir IHM Prototyper IHM

Concepteur IHM

Hiérarchiser les cas d’utilisation 53

Architecte
 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…

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

55
 Analyse et Conception- workflow

Analyser
l’architecture
Concevoir Définir la Définir le
Architecte Planifier la Responsable
l’architecture concurrence déploiement vérification vérification
architecture architecture

Concevoir les
sous systèmes
Analyser les cas
d’utilisation Concevoir les Planifier la Responsable
cas d’utilisation vérification vérification
Concepteur Concevoir les
conception conception
classes

Concevoir la
Concepteur Base base de données
de données
56
• 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

57
• 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.

58
Implémentation - workflow

Structurer le
Modèle d’implémentation
Architecte

Responsable
intégration Planifier l’intégration Intégrer
du système Système
système

Planifier Intégrer les

L’intégration des Implémenter sous systèmes
Sous-systèmes les Classes
Développeur
Tester
les unités
Fixer les solutions

Responsable vérification
Code
Vérifier le Code 59
 Implémentation : Artéfacts

• Le modèle d’implémentation qui définit les

composants.
• Les composants.
• Le plan d’intégration des composants.

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

61
 Tests-workflow

Concepteur Planifier Concevoir Tester

Evaluer
des tests Tests Tests implémentation Test

Testeur de Tests d'Intégration

l’intégration

Tests Système
Testeur système

Testeur Tests de Performance

performances

Concevoir les classes de Test

Concepteur et Packages

Implémenter le sous système de tests

développeur
62
 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.

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

64
Gestion de projet- workflow

Exécuter
Mener une l’itération
étude de cas
métier
Identifier
Les Risques Vérifier
Planifier l’itération
Développer
l’itération
plan de
gestion de
projet

Chef de projet Réunir

Équipe
Réviser la liste des risques

65
 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

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

67
 Déploiement - workflow

Définir les processus Définir les besoins des

de changement de report et préservation des
Chef de projet produit statuts

Structurer le modèle de
déploiement
Architecte

Responsable Rédiger le plan Définir le modèle Délimiter les

Livrer les sous-
de gestion de de déploiement espaces de Documenter le Fonder le produit
gestion du systèmes
changement travail défaut
changement

Tout membre Créer un espace de travail Vérifier les S’attacher aux points
personnel sensibles de la
de l’équipe artéfacts d’E/S configuration

Créer un espace de travail Construire le produit

Intégrateur pour l’intégration

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

69
Processus Unifié Rational

Outils

70
 Rational SoDA: aide à automatiser la documentation du logiciel
RequisitePro: collecte et gestion des besoins
Adobe FrameMaker: création des IHM
Rational Rose: Modélisation visuelle
ClearCase pour la gestion de configuration du système
Microsoft Word: édition de la plupart des documents classiques ;
Microsoft Project : la planification du processus
Microsoft FrontPage: étendre le RUP lui même.
Activités de base
Modèle métier Requisite Pro, Rose, SoDA

Besoins Requisite Pro, Rose, SoDA

Analyse et conception Rose, SoDA, Apex

Implémentation Rose, Apex, SoDA, Purify, ...

Test SQA TeamTest, Quantify, PerformanceStudio,...

Déploiement SoDA, ClearCase, ...

Activités de support
ClearCase, ClearQuest
Config. & Changement
Unified Process, Microsoft® Project, ...
Gestion de projet
71
Environnement Unified Process, Rational Tools