presentation

1. Rationaliser la conception participative

2. Logiciel
Logiciel
Logiciel
Logiciel
Logiciel
Logiciel
Croissance en nombre
Logiciel Croissance en taille
Croissance en
complexité

3. Rational Unified Process
Rational Unified Process (RUP) : est un
processus de conception/développement de logiciel
défini par Rational Software.
http://www.rational.com/

4. Organisation séquentielle
Le risque est au début
R
I
S
Q
U
E
TEMPS
Tests unitaires
Test système
Développement
Conception
Prérequis
• Les décideurs prennent le risque
• Les concepteurs assument…
• Les développeurs suivent…

5. Organisation participative
Le risque est partagé
Transition
Risque
Inception
Conception
Construction
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition
Iteration
Post-
deployment
Temps
Equipe

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

7. Accroître la productivité en
conception/développement
Tous les membres partagent
• Des bases de connaissance
• Une même méthode
• Une organisation du travail
• Un langage
Designer /
Developer
Analyst Tester
Database
Administrator
Performance
Engineer
Release
Engineer
Project
Leader

8. Guide
Amplifient Utilisent
Oriente
Automatisent
Se focalise
Fédèrent
Instrumentent Accélèrent
Outils
Travailleur
Services
Le langage RUP : un modèle visuel
Activité

9. Quatre éléments de modélisation dans RUP
• Membre est le qui : Chef de projet, Analyste, Testeur,
Utilisateur, etc.
• Artéfact est le quoi : Document de l’architecture,
Modèle des cas d’utilisation, Fichier exécutable, etc.
• Activité est le comment : Analyse de cas
d’utilisation, Conception de cas d’utilisation, etc.
• Enchaînement d’activités est le quand :
Modélisation de métier, implémentation, test, etc.

10. Décrit un rôle
dans le
processus
Membre
Use-Case
Specifier
Notations
Activité
Décrit une partie du
travail
Décrit une connaissance
ou une donnée
Artéfact
Use-Case
Package
Use Case
Responsable de

11. Concepteur Analyse de cas
d ’utilisation
Conception de
cas d ’utilisation
Réalisation de cas d ’utilisation
est responsable de
Exemple : rôles du concepteur
activité1
Connaissance
Document
produit
activité2

12. Planification des RH
Re s o urc e Wo rke r Ac tivitie s
Paul
Mary
Joe
Sylvia
Stefan
Designer
Use-Case Specifier
Use-Case Designer
Design Reviewer
Architect
Define Operations
...
Describe a Use Case
...
Distribute Behavior
...
Review Use-Case Model
...
Define Use-Case View
Define Logical Viiew
...
Chaque membre est
considéré comme un
acteur

13. Exemple d’un Workflow

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

15. Architecture bidirectionnelle
du RUP

16. Enchaînement d’activités dans RUP
6 enchaînements
d'activités essentielles
• Modélisation du métier
• Gestion des exigences
• Analyse et Conception
• Implémentation
• Test
• Déploiement
3 enchaînements
d'activités de soutien
• Gestion de Projet
• Gestion de la configuration
et des changements
• Environnement

17. Enchaînement d’activités dans RUP
Modélisation du métier
• 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.
Il a pour but

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

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

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

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

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

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

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

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

26. Phases dans RUP
Inception Conception Construction Transition
Temps
Jalon :
objectifs et
cycle de vie
Jalon :
architecture du
système
Jalon :
prototype
Jalon :
livraison du
produit

27. Inception
• Il s’agit de décrire quelle vision on a du
produit final et où on veut aller, de réaliser
une étude de rentabilité et de définir le
projet.
• La phase Inception se termine par le jalon
« objectifs et cycle de vie »

28. Conception
• Il s’agit de
¤ planifier les activités et les ressources
nécessaires à la réalisation du projet
¤ spécifier les fonctionnalités
¤ concevoir l’architecture
• La phase de conception se termine par
le jalon « architecture du système »

29. Construction
• Il s’agit de construire le système et de faire
évoluer la vision, l ’architecture et les plans de
développement jusqu’à l ’obtention d’un
produit prêt à être testé.
• La phase construction se termine par le jalon
« prototype »

30. Transition
• Il s’agit de soumettre le produit aux
utilisateurs (béta-test),
• La phase transition se termine par le
jalon « livraison du produit » ou par une
nouvelle itération

31. Ambition de RUP
• Faire face aux changements en
cours du projet qui restent les causes
principales de l’échec du projet.
• Par exemple :
¤ Les utilisateurs changent leurs exigences
¤ L’équipe de développement modifie
l’architecture du logiciel

32. Changement des exigences
• Au départ, les utilisateurs ne savent pas
quelles sont leurs exigences et comment
les spécifier de façon précise.
• Ils changent leurs exigences quand ils
voient les livrables
Effet: IKIWISI
I Know It When I See It - Je le saurai quand je l ’aurai vu
Bary Boehm - Université de Californie du Sud

33. Changements de l’architecture
• Les membres de l’équipe :
¤ n’ont peut-être pas bien compris le système
exigé
¤ n’ont peut-être pas partagé une même
compréhension du système

34. RUP est centré sur l’architecture
Vue logique
Vue pratique
Vue déploiement
Vue d'implémentation
Vue des processus
Programmeurs
Gestion du logiciel
Utilisateur final
Fonctionnalité
Analystes/Testeurs
Comportement
Intégrateurs
système
Performance
Capacité à grandir
Débit d'information
Ingénieurs Système
Topologie du système
Livraison, installation
Communication
Vue des cas
d'utilisation

35. Briques d’organisation
Contrôle des changements
Management
Composants
logiciels
Processus
itératif
Modèle visuel Qualité

36. RUP : tracer les changements
• RUP définit un enchaînement d’activités de
soutien : gestion des configurations et des
changements
• RUP est piloté par les cas d ’utilisation

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

38. Avantages
• RUP améliore la qualité du produit
• RUP augmente le taux de succès du projet
• RUP est supporté par les outils du Rational
Software

39. RUP améliore la qualité du produit
• RUP améliore la compréhension du système
¤ RUP est itératif
¤ RUP reste centré sur l’architecture
¤ RUP utilise UML pour modéliser le logiciel

40. RUP améliore la qualité du produit
• RUP contrôle et trace le processus de
transformation de la compréhension du
système en produit
¤ RUP est piloté par les cas d’utilisation
¤ RUP contrôle l’avancement de travail à l ’aide des
livrables fournis dans les jalons

41. RUP augmente le taux de succès
du projet
RUP permet d’anticiper et de limiter les
risques. On peut mieux les traiter quand ils
sont petits...

42. RUP est intégré par les outils du Rational
Software
Rose
TeamTest
RequisitePro
SoDA ClearCase
ClearQuest
Purify
Quantify
PureCoverage
Visual Studio
Apex

43. Interface

44. Présentation des rôles

45. Présentation des scénarios

46. Diagramme de la collaboration

47. Présentation des classes (UML)

48. Diagramme des états de transition

49. Diagramme des composants

51. Points faibles de RUP
• RUP ne supporte pas les multi-projets
• RUP exige des experts
• RUP est propriété de Rational Software

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