4 Méthodologie adopté
Une méthodologie de développement logiciel,
composée d'un formalisme et un processus, est une démarche
à suivre afin de créer des classes avec leurs attributs, leurs
méthodes et les relations entre celles-ci pour réaliser une
application spécifique. Elle permet d'augmenter grandement la
productivité, d'estimer le temps de développement et de
créer des applications plus robustes.
Un processus est une démarche méthodologique,
qui 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. Plus simplement, un processus doit
permettre de répondre à la question fondamentale : " Qui fait
quoi et quand ? ".
|
|
|
Chapitre I : Présentation
générale
|
4.1 Processus adopté
Rational Unified Process (RUP) à plusieurs atouts :
· Le changement est mieux géré, car il est
possible de recadrer le projet après une itération.
· Meilleur niveau de portabilité grace à
l'utilisation de l'UML (Unified Modelling Language).
· Vérification constante de la qualité.
RUP est une démarche de développement qui est
souvent utilisé conjointement au langage UML
Rational Unified Process est basé sur trois principes
:
· Piloté par les cas d'utilisation
o La principale qualité d'un logiciel est son
utilité
· Adéquation du service rendu par le logiciel avec
les besoins des utilisateurs
o Le développement d'un logiciel doit être
centré sur l'utilisateur
o Les cas d'utilisation permettent d'exprimer ces besoins
· Détection et description des besoins
fonctionnels
· Organisation des besoins fonctionnels
· Centré sur l'architecture
o Modélisation de différentes perspectives
indépendantes et complémentaires o Architecture en couches et
vues
Vue logique
Vue cas
d'utilisation
Vue déploiement
Vue composants
Vue
implémentation
Figure 2: Les vues en RUP
|
|
Chapitre I : Présentation
générale
|
|
· Vue du système
- Vue cas d'utilisation
Description du système comme un ensemble de transactions
du point de vue de l'utilisateur
· Vue logique
- Créée lors de la phase d'élaboration et
raffinée lors de la phase de construction
- Utilisation de diagrammes de classes, de
séquences...
· Vue composants
- Description de l'architecture logicielle
· Vue déploiement
- Description de l'architecture matérielle du
système
· Vue implémentation
- Description des algorithmes, code source
· Itératif et incrémental
o Chaque itération prend en compte un certain nombre de
cas d'utilisation.
o Chaque itération donne lieu à un
incrément et produit une nouvelle version.
Rational Unified Process organise le développement en
phases
· Phase de création « Incubation »
Traduit une idée en vision de produit fini et
présente une étude de rentabilité pour ce produit
Que va faire le système pour les utilisateurs ?
A quoi peut ressembler l'architecture d'un tel système
?
Quels sont l'organisation et les coüts du
développement de ce produit ? On fait apparaître les principaux
cas d'utilisation.
L'architecture est provisoire, identification des risques
majeurs et planification de la phase d'élaboration.
· Phase d'élaboration
Permet de préciser la plupart des cas d'utilisation et
de concevoir l'architecture du système. L'architecture doit être
exprimée sous forme de vue de chacun des modèles. A l'issue de
cette phase, on doit être en mesure de prévoir les
activités et d'estimer les ressources nécessaires à
l'achèvement du projet.
|
|
Chapitre I : Présentation
générale
|
|
? Phase de construction
Moment où l'on construit le produit. L'architecture de
référence se métamorphose en produit complet, elle est
maintenant stable. Le produit contient tous les cas d'utilisation qui ont
été décidé de mettre au point pour cette version.
Celle-ci doit encore avoir des anomalies qui peuvent être en partie
résolue lors de la phase de transition.
? Phase de transition
Le produit est en version beta. Un groupe d'utilisateurs
essaye le produit et détecte les anomalies et défauts. Cette
phase suppose des activités comme la fabrication, la formation des
utilisateurs clients, la mise en oeuvre d'un service d'assistance et la
correction des anomalies constatées. (Où le report de leur
correction à la version suivante).
| 
