___

Démarche
de développement

Ce chapitre présente deux principaux processus (méthodes) de développement

orientés objet qui utilisent l’UML comme langage de modélisation:
1. UP (Unified Process)
2. et de RUP (Rational Unified Process)

GACEB 1

I. Processus UP
1. Pourquoi UP ?
2. Définition
3. Activités et phases
4. Modèles mis en place

1
 ___

1. Pourquoi UP ?
• Les notions de base acquises sur la notation UML, facilitent la
compréhension et l’adoption d’une méthodologie OO du
développement logiciel qui s’appuie :
– sur la modélisation des objets du monde réel,
– puis sur l’utilisation du modèle pour bâtir une conception indépendante des
langages de programmation, organisée autour de ces objets.
• Les bonnes méthodes d’analyse et de conception doivent aider à
concevoir des logiciels de qualité.
• UML n’est pas une méthode (i.e. une description normative des étapes
de la modélisation).
• C’est un langage graphique qui permet de représenter (modéliser) et
de communiquer les divers aspects d’un système d’information.

1. Pourquoi UP ?
• Principaux concepts d’UP
• Le processus unifié décrit qui fait quoi, comment et quand les travaux sont réalisés tout au
long du cycle de vie du projet. Quatre concepts d’UP répondent à ces questions :
• Rôle (qui ?)
• Activité (comment ?)
• Artefact (quoi ?)
• Workflow (quand ?)

• Rôle : Définit le comportement et les responsabilités d’une ressource ou d’un groupe de

ressources travaillant en équipe. Le rôle doit être considéré en termes de « casquette » qu’une
ressource peut revêtir sur le projet. Une ressource peut jouer plusieurs rôles sur le projet. Par
exemple sur un projet, une personne peut être à la fois chef de projet et architecte. Elle
représente deux rôles au sens d’UP.
• Activité : Les rôles ont des activités qui définissent le travail qu’ils effectuent. Une activité
est une unité de travail qu’une ressource, dans un rôle bien précis, peut effectuer et qui
produit un résultat dans le cadre du projet. L’activité a un but clairement établi, généralement
exprimée en termes de création ou de mise à jour d’artefacts, comme un modèle, une classe
ou un planning. Les ressources sont affectées aux activités selon leurs compétences et leur
disponibilité. Par exemple, les activités « planifier une itération » et « anticiper les risques »
sont attribuées au rôle de chef de projet. 4

2
 ___

1. Pourquoi UP ?
• Artefacts : Un artefact est un ensemble d’informations qui est produit, modifié ou
utilisé par le processus. Les artefacts sont les produits effectifs du projet. Les
artefacts sont utilisés comme input par les ressources pour effectuer une activité et
sont le résultat d’output d’activités du processus. Un exemple d’artefacts rencontrés
au cours du projet est un planning d’une itération ou un diagramme produit dans une
activité.

• Workflows : Une énumération de tous les rôles, activités et artefacts ne constitue

pas un processus. En effet, il est nécessaire d’avoir une façon de décrire des
séquences d’activités mesurables qui produisent un résultat de qualité et montre
l’interaction entre les ressources. Le workflow est une séquence d’activités qui
produit un résultat mesurable. En UML, il peut être exprimé par un diagramme de
séquence, un diagramme de communication ou un diagramme d’activité.

1. Pourquoi UP ?
Les concepteurs orientent leurs modélisations selon trois axes sur lesquels ils
répartissent les diagrammes :
1. L’axe fonctionnel : utilisé pour décrire ce que fait le système à réaliser,
– Diagramme de Use Cases
– Diagramme d’activités
– Diagramme de séquences

2. L’axe structurel et statique : relatif à la structure du système,

– Diagramme de classes
– Diagramme d’objets
– Diagramme de packages
– Diagramme de composants
– Diagramme de déploiement

3. L’axe dynamique : relatif à la construction des fonctionnalités du système.

– Diagramme de séquences
– Diagramme d’activités
– Diagramme de collaboration
6
– Diagramme d’états/transitions

3
 ___

Modèle Statique (ce que le système EST)

Dynamique
(comment le système
EVOLUE)
• diagramme de séquence
• diagramme de collaboration
• diagramme d’états-
transitions
• diagramme d’activités
• diagramme de classes
• diagramme d’objets
• diagramme de composants
• diagramme de déploiement
Fonctionnel
(ce que le système FAIT)
• diagramme de cas d’utilisation
• diagramme de collaboration
7

1. Pourquoi UP ?
Si UML permet de modéliser un système, il ne
définit pas le processus d’élaboration des modèles.

– Dans quel ordre doit-on utiliser les différents

diagrammes?
– A quel moment de la conception d’un système doivent-ils
intervenir?

Seul un processus de développement peut

répondre à ces questions !
8

4
 ___

1. Pourquoi UP ?
Le processus de développement régit les activités de production du
logiciel selon deux aspects.

1. L’aspect statique qui représente le processus en terme de tâches à

réaliser. Il définit:
– Le « qui ». Les intervenants
– Le « comment ». Les activités à réaliser
– Le « quoi ». Les résultats d’une activité

2. L’aspect dynamique qui représente la dimension temporelle du

processus. Il représente :
– Le nom et le nombre de phases du cycle de vie du processus
– L’organisation et l’ordre de réalisation des activités de développement
9

1. Pourquoi UP ?
Un processus gère généralement les activités suivantes:
1. L’expression des besoins : consiste pour le client à élaborer un
cahier des charges décrivant:
– Les fonctionnalités du système à étudier.
– La façon d’utiliser le système
2. La spécification des besoins : permet aux utilisateurs, experts et aux
informaticiens de finaliser le cahier des charges en levant les
ambiguïtés et en éliminant les redondances
3. L’analyse des besoins : vise à faire définir, par les experts et les
utilisateurs, les entités métier concernées par le système
indépendamment de toutes considérations:
– techniques et informatiques
4. La conception : concerne les experts en informatiques. On y
détermine la manière de résoudre techniquement le problème posé.
Comment réaliser les fonctionnalités attendues. 10

5
 ___

1. Pourquoi UP ?
5. L’implémentation consiste :
– A construire les programmes dans un langage de programmation donné.
– A organiser logiquement les programmes en fonction de l’architecture logique choisie.
– A distribuer les programmes sur le système informatique selon l’architecture physique
retenue.
6. Les tests fonctionnels et techniques
– Fonctionnels. Ils vérifient que le système implémente bien les fonctionnalités
attendues.
– Techniques. Ils vérifient que l’implémentation des fonctionnalités est techniquement
correcte.
7. La maintenance

11

1. Pourquoi UP ?
UML et les activités de développement :
• La maîtrise des processus de développement implique une
organisation et un suivi des activités
• A ceci s’attachent les différentes méthodes qui s’appuient sur
l’utilisation du langage UML pour modéliser un système
d’information.
• L’utilisation d’UML insistent sur les caractéristiques suivantes qui
sont essentielles pour un processus de développement :
1 Piloté par les cas d’utilisation
2 Centré sur l’architecture
3 Itératif et incrémental

12

6
 ___

1. Pourquoi UP ?
UP (Unified Process) répond bien à ces exigences.
• C’est un processus de développement moderne, itératif, efficace sur des projets
informatiques de toutes tailles.
• Très complet, il couvre l’ensemble des activités, depuis la conception du projet
jusqu’à la livraison de la solution.
• Intègre une bonne organisation de projet, une méthodologie utilisant UML et un
ensemble de bonnes pratiques cohérentes entre elles,
• il permet de s’adapter aux problèmes récurrents que rencontrent nombre de
réalisations :
– dérive des coûts et des délais, qualité insuffisante, réponse incomplète aux attentes des utilisateurs.
• Un point d’excellence de cette démarche est son adaptabilité : UP peut se décliner
en fonction de l’ampleur d’un projet, de l’expérience de l’équipe qui l’assume, de la
nature de la solution à construire.

• UP est une méthode générique de développement de logiciel.

13

2. Définitions
Processus de développement logiciel :
• Un processus définit une séquence d’étapes permettant l’obtention
d’un nouveau 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.
• Des techniques d’analyse et de conception permettant de bien prendre
en charge les critères de qualité sont indispensables.
• En conséquence, le processus peut se décomposer suivant deux axes
de contrôle sur le développement :
– L’axe de développement technique, qui se concentre principalement sur la qualité de la
production ;
– L’axe de gestion du développement, qui permet la mesure et la prévision des coûts et des
délais.
14

7
 ___

2. Définitions
• Processus Unifié : (Unified Process)
Le processus unifié est un processus de développement logiciel
construit sur UML qui regroupe les activités à mener pour
transformer les besoins d’un utilisateur en système logiciel.

• Caractéristiques essentielles du processus unifié :

– Basé sur les composants,
– utilise le langage UML (ensemble d'outils et de diagrammes),
– piloté par des cas d'utilisation
– centré sur l'architecture,
– itératif et incrémental,
– orienté vers la diminution des risques.

15

2. Définitions
• Il peut être adaptée
– à une large classe de systèmes logiciels,
– à différents domaines d'application,
– à différents types d'entreprises,
– à différents niveaux de compétences
– et à différentes tailles de l'entreprise.

• Les adaptations de UP les plus connues sont :

– RUP : Rational Unified Process
– 2TUP : Two Tracks Unified Process
– XP : eXtreme Programming

16

8
 ___

• Le PU est piloté par les cas utilisation :

– L’objectif principal d’un système logiciel est de rendre service à ses utilisateurs ; il
faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs.
– Création d'une succession de modèles sur la base du diagramme de cas
d'utilisation
• spécification : modèle d'analyse
• réalisation : modèle de conception
• vérification : modèle de tests

• Centré sur l’architecture :

– L’architecture regroupe les différentes vues du système qui doit être construit.
– Elle doit prévoir la réalisation de tous les cas d’utilisation.
– Recherche de la forme générale du système dès le début
– Approche systématique pour trouver une« bonne » architecture qui soit :
• support des cas d'utilisation
• adaptable aux changements
• exploite la réutilisation
• compréhensible intuitivement
– plusieurs façons de voir le système
17

Vue logique Vue CU Vue de Réalisation

Vue déploiement
Vue Processus

18

9
 ___

• Vue Logique
– Abstraction et encapsulation,
– Modélisation des éléments et mécanismes principaux du système,
– Expression des aspects statiques et dynamiques
– Utilisation : diagrammes d'objets et de classes ; diagrammes de collaborations interactions, paquetages «
catégories »...
• Vue réalisation
– Identification des modules qui réalisent les classes de la vue logique,
– Organisation des modules dans l'environnement de développement
– Éléments manipulés : modules, sous-programmes, tâches (en tant qu'unités de programme), paquetage « sous-
systèmes »
• Vue Processus
– Importante dans les environnements multi-tâches,
– Décomposition en flots d'exécution et synchronisation entre ces flots,
– Éléments manipulés :tâches, threads, processus,interactions.
• Vue déploiement
– Importante dans les environnements distribués,
– Ressources matérielles et l'implantation (distribution) du logiciel dans ces ressources,
– Éléments manipulés : nœuds, modules, programmes principaux.
• Vue use case
– Besoins des utilisateurs, justification de l'architecture,
– Colle entre les autres vues
– Éléments manipulés :acteurs, cas d'utilisation, classes, diagrammes de collaboration.

19

Itérative et incrémentale …
• Le développement procède par des itérations qui conduisent à des
livraisons incrémentales du système.

• Les cycles d’évolutions se décomposent en 4 phases :

– Création, Élaboration, Construction et Transition

• Les 4 phases se décomposent en activités :

1. Expression des besoins
2. Analyse
3. Conception
4. Implémentation
5. Test

10
 ___

L'architecture bidirectionnelle

21

22

11
 ___

II. Processus RUP

23

Le Rational Unified Process (RUP)

• RUP développé par IBM est une famille de processus UP.
• Processus itératif incrémental,
• centrés sur le modèle à objets et sur UML
• Les validations de chaque phase s’appuient sur des cas d’utilisation.
• Le système est décrit comme la somme de multiples vues
– 5 vues voir les diapos 15 et 16 : logique, réalisation, processus, déploiement, cas
utilisation)
• Son architecture est le soucis permanent
– le RUP préconise le développement préliminaire d’une architecture exécutable,
– c’est-à-dire une version du système avec un nombre très limité de fonctionnalités mais
dont le “squelette” est fixé.

NB: Unified Process (UP) est la version la plus documentée du RUP

C’est une version générique adaptable aux besoins particuliers. 24

12
 ___

La structure logique du Processus RUP

• Structure 2D (4 phases et 6 activités), certains structures peuvent atteindre 9
activités

25

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

Utiliser le Développement Itératif

(Ré)Utiliser Modeler
Analyser Composants Visuellement Contrôler
les Besoins Architectures (UML) la Qualité

Contrôler le
Changement

13
 ___

Les 4 phases, les itérations (#n) et les jalons

• Jalon= événement important, étape d’évaluation de la phase terminée, et de lancement de la
phase suivante

27

Itérations: deux types

1 ) Micro-itération : chaque phase peut être itérée plusieurs fois avant

de passer à la phase suivante

2) Macro-itération: l’ensemble de phases est typiquement itéré plusieurs

fois, comme dans tous les modèle itératifs

28

14
 ___

Les principales activités

du processus

29

1)Modélisation métier
• Compréhension de la structure et la dynamique de l’organisation
• Comprendre les problèmes posés dans le contexte de l ’organisation
• Conception d ’un glossaire

2) Recueil et expression des besoins

• Auprès des clients et parties prenantes du projet ; Ce que le système doit faire
• Expression des besoins dans les cas d’utilisation (exigences fonctionnelles)
• Spécification des cas d’utilisation en scénarios
• Limites fonctionnelles du projet et exigences non fonctionnelles (utilisabilité,
fiabilité, performances)
• Planification et prévision de coût
• Ebauche de l ’IHM (prototypage et validation par l’utilisateur)

30

15
 ___

3) Analyse et conception
• Transformation des besoins utilisateurs en modèles UML
• UML(pas une méthode mais un langage )
• Modèle d’analyse et modèle de conception,
(éventuellement modèle de données)
• Étape importante :
– de l’analyse à la conception :
assigner des responsabilités aux classes Les patrons (GRASP)

4) Implémentation
• Développement incrémental
• Découpage en couches
• Composants d’architecture
• Retouche des modèles et des besoins
• Unités indépendantes, équipes différentes

31

5) Tests
• Etapes (unitaire, d’intégration, système, acceptation)
• Types :
– De « benchmark » (comparaison)
– De configuration (différentes config matérielles et logicielles)
– De fonctionnement (vérification des CU)
– D’installation
– D’intégrité (fiabilité, robustesse, résistance)
– De charge (conditions opérationnelles plus lourdes = nb utilisateurs, transactions,…)
– De performance (en modifiant les configurations)
– De stress (conditions anormales opérationnelles)

32

16
 ___

6) Gestion de projet

• La gestion de projet = mise en œuvre de :

• Connaissances
• Ressources
• Compétences
• Outils
• Techniques
Permettant le lancement, la planification, la réalisation, le pilotage et la
clôture d’un projet dans un cadre temporel et budgétaire, pour atteindre
des objectifs précis. »

• Objectifs
– Planifier/évaluer un projet itératif
– Gérer les risques
– Contrôler les progrès (délais, coûts, qualité, efforts, satisfaction client, productivité, etc.)

33

Les phases (Le processus dans le temps)

Les enchaînements d’itération

34

17
 ___

1) Phase de lancement (inception ou pré-étude )

Cette phase correspond à l’étude de faisabilité

• Comprendre le système à construire (vision générale et limites du projet)

• Recueillir les besoins utilisateurs
• Spécifier les principaux cas d’utilisation et scénarios
• Définir une architecture candidate
• Evaluer les coûts et planning
• Les principaux risques
• Comprendre les objectifs et la portée du projet
• Objectifs :
1) Comprendre le système à construire
2) Identifier la fonctionnalité principale du système
3) Déterminer au moins une solution possible
4) Comprendre les coûts, les délais et les risques
5) Décider du processus à appliquer et des outils à utiliser
• Revue de projet : Jalon fin de lancement
– Les différents intervenants valident: le périmètre du projet, coûts et délais, la liste des exigences
– Les risques initiaux sont identifiés et il existe une stratégie de réduction pour chacun d’eux
– L’ensemble des artefacts produit est complet, à jour et cohérent

Nb : - en général une seule itération, sauf pour projets importants, innovants, ou très risqués
-elle peut amener à l’abandon du projet
35
(donc il est plus intense vers le début du projet, pour minimiser les risques)

2) Phase d’élaboration (Axée sur l’analyse de besoins)

• Modèle des cas d’utilisation complet
– Usage intensif des CU (et donc de scénarios)
– pour raffiner la compréhension du problème posé
– et expliciter les spécificités du domaine.
• Exigences supplémentaires
– (non fonctionnelles et celles qui ne sont pas associées à des c.u.)
• Raffiner l ’architecture logicielle
• Des prototypes exécutables
– sont développés pour évaluer concrètement des points techniques risqués.
• Un manuel utilisateur préliminaire
• Construction d’un squelette d’architecture n intégrant les risques majeurs et affiner les plans
de projet

• Objectifs :
1) Comprendre en détail les exigences
2) Concevoir, implémenter, valider l’architecture
3) Réduire les risques essentiels et estimer plus exactement le budget
4) Affiner le plan de développement
• Revue de projet : jalon fin d’élaboration
– Évaluer : Stabilité de vision , d’exigences et d’architecture et Crédibilité du plan d’itération
– En cas de doute : refaire une itération
36

18
 ___

3) Phase de construction
Concentrée sur la conception, le développement et le test

• Gestion des ressources matérielles

– installation sur plateformes choisies
• Optimisation du processus
– pour réduire les coûts de développement
• Améliorer la qualité
• Compléter les modèles suivant les besoins d ’implémentation
• Produit : le logiciel installé sur les plate-formes choisies, les manuels d’utilisation,
description de la version mise en place
• Elle est répète plusieurs fois pour une progression incrémentale
– aboutissant à diverses versions du système, résolvant les problèmes techniques à hauts risques en priorité.

• Objectifs :
1) Minimiser les coûts de développement et obtenir un certain degré de parallélisme
2) Développer de façon itérative un logiciel prêt à la transition vers les utilisateurs
3) même pour de petits projets, il faut plusieurs itérations (entre 2 et 4)
• Revue de projet : le jalon fin de Construction
Évaluation :
– Version du logiciel est elle stable ?
– Tous les intervenants sont prêts ?
– Dépenses réelles/prévisionnelles acceptab les ? 37

4) Phase de transition
Correspond à l’activité de déploiement et marque le début de la maintenance du logiciel
• Déployer ,
• Tester
• Valider
– réponse aux attentes des utilisateurs
• Accompagner l’utilisateur final
– packaging, documentation, formations, manuels …

• Objectifs :
1)  Exécuter les tests bêta
2) Former les utilisateurs
3) Préparer le site de déploiement
4) Préparer le lancement
5) Obtenir l’accord des intervenants
6) Améliorer les performances futures

• Revue de projet : le jalon fin de Transition

Évaluation :
– Satisfaction des utilisateurs
– Bilan sur les ressources réellement consommées
38

19