V.3.2.4. Le processus unifié est itératif et
incrémental
Le développement d'un produit logiciel destiné
à la commercialisation est une vaste entreprise qui peut
s'étendre sur plusieurs mois. On ne va pas tout développer d'un
coup. Nous pouvons découper le travail en plusieurs parties qui sont
autant de mini projets. Chacun d'entre eux représentant une
itération qui donne lieu à un incrément. Une
itération désigne la succession des étapes de
72
l'enchaînement d'activités, tandis qu'un
incrément correspond à une avancée dans les
différents stades de développement.
V.3.3. Avantages d'un processus itératif
contrôlé
Le processus Unifié permet de limiter les coûts,
en termes de risques, aux strictes dépenses liées à une
itération. Permet de limiter les risques de retard de mise sur le
marché du produit développé (identification des
problèmes dès les premiers stades de développement et non
en phase de test comme avec l'approche « classique»).
Permet d'accélérer le rythme de
développement grâce à des objectifs clairs et à
court terme. Permet de prendre en compte le fait que les besoins des
utilisateurs et les exigences correspondantes ne peuvent être
intégralement définis à l'avance et se dégagent peu
à peu des itérations successives L'architecture fournit la
structure qui servira de cadre au travail effectué au cours des
itérations, tandis que les cas d'utilisation définissent les
objectifs et orientent le travail de chaque itération. Il ne faut donc
pas mésestimer l'un des trois concepts.
Processus Unifié
Diagramme de séquence système
Cas d'utilisation
Diagramme de classes participante
Figure 19:Représentation de Diagramme du Processus
Unifié
Diagramme de classes de conception
Code en PHP
Diagramme d'interaction
Diagramme de navigation
73
V.4.Modèle conceptuel et d'analyse
Notre mémoire est basé à la conception
d'une application Mercuriale de Construction qui aide les architectes dit
Maitre de l'oeuvre et les clients dites Maitre de l'ouvrage (cas d'un Devis
Mercuriale.) qui pourra être déployée sur un environnement
v client/serveur.
La réalisation de ce système passe par plusieurs
étapes dont la spécification, la conception, la
modélisation, l'implémentation, et enfin le déploiement.
Cette démarche part de la réponse au cahier de charge
jusqu'à la rédaction des documents spécification. Le cas
que nous exposons ci-dessous dans le cahier de charge est incomplet et
insuffisant, il sera enrichi par des phrases et des commentaires tout au long
de cette spécification.
V.4.1.Cahier de charge: Présentation du projet
IV.4.1.1Expression capitale des besoins
a) Conception du projet
Etude de cas : Recueil des besoins fonctionnels et non
fonctionnels
b) Exigences fonctionnelles
Notre application mercuriale de gros oeuvre devra ressembler
toutes les fonctionnalités requises pour bien manipuler les
données : réinitialiser les données, sauvegardes,
correction, validité, suppression.
c) Exigences non fonctionnelles 1°. Exigences de
qualité
Pour souscrire aux informations d'un devis sur notre
application et ensuite le fidéliser, il est important de répondre
aux exigences de qualité suivantes :
74
? Ergonomie sobre et efficace
Enregistrer un devis dans l'application ne doit pas prendre
beaucoup de temps ! La mise en page de l'application facilitera au maximum la
démarche à l'aide d'une présentation claire et
intuitive.
? Formulaire d'enregistrement simple
L'accès facile pas d'informations plus
complexe à introduire compréhension facile même chez le non
informaticiens La conception et la présentation de celui-ci seront donc
particulièrement soignées pour ne pas rebuter l'utilisateur.
2°. Exigences de performance
d) Spécification des exigences d'après le cas
d'utilisation
1°. Identification des acteurs
Les acteurs humains pour notre application sont les suivants
:
? Maitre de l'oeuvre ;
? Maitre de l'ouvrage ;
Nous allons également prendre en compte le
système informatique connectés à l'application Web,
à savoir le système de sauvegarde qui copie les données du
système à la base. Cette source externe sera automatiquement
chargée dans la base de données de façon
immédiate.
Figure 20: Différents Acteurs de l'application
Mercuriale
Figure 23:Cas d'utilisation de
l'administrateur
75
Figure 21:Représentation du maitre de
l'ouvrage
Figure 22:Représentation du maitre de
l'oeuvre
Quels sont les cas d'utilisation de l'administrateur ?
D'après la section précédente, nous identifions :
V' Créer un login et pass word
V' Il peut sauvegarder les données du système
Nous allons représenter le diagramme de séquence
système d'un scénario représentatif de chacun des cas
d'utilisation décrits précédemment.
76
2° Devis
V' Acteur principale : Maitre de l'oeuvre
V' Objectif : afficher un devis moyennant une superficie
V' Scénario nominal : l'utilisateur accède avec
son login et le password, saisit les informations personnelles, saisit la
superficie souhaitée, la base des données calcul, valide les
données et affiche le devis
V' Le système nous présente un formulaire de
souscription détaillé d'utilisateurs. Nous y trouverons de champs
suivant :
+ Nom
+ prénom
+ Numéro de téléphone
+ Prénom
+ Adresse
+ Superficie
a. Diagrammes de séquences systèmes
Les diagrammes de séquences mettent en valeur les
échanges de messages (déclenchant des événements)
entre acteurs et objets (ou entre objets et objets) de manière
chronologique, l'évolution du temps se lisant de haut en bas.
Chaque colonne correspond à un objet (décrit
dans le diagramme des classes),ou éventuellement à un acteur,
introduit dans le diagramme des cas. La ligne de vie de l'objet
représente la durée de son interaction avec les autres objets du
diagramme. Un diagramme de séquences est un moyen semi-formel de
capturer le comportement de tous les objets et acteurs impliqués dans un
cas d'utilisation.
77
1°. Accouplage Maitre de l'oeuvre, maitre de
l'ouvrage et le monde Réel
univers
? Contrant d'élaboration du plan
d'architecture
Possède un terrain
Maitre de l'oeuvre Terrain Maitre de l'ouvrage
Consulte un architecte
Lui donne le programme
Prélève la superficie du terrain
Élabore le Projet
L'architecte donne son Accord
Lui présente le terrain
Lui demande le programme du
projet
Lui présente le projet
Figure 24:présentation du Diagramme de
séquence système de gros oeuvre
Figure 25:Représentation du 2ème Diagramme
de séquence système de gros oeuvre
78
Système
Maitre de l'ouvrage
2° Maitre de l'ouvrage, Maitre de l'oeuvre et le
système - Contrat d?élaboration du devis de
construction
Maitre de l'oeuvre
Consulte l'architecte pour l'élaboration du projet
L'architecte donne son Accord
L'architecte utilise le logiciel pour élaborer le Devis
Lui présente le devis en dur
En possession du devis
Vérifier le devis avec le logiciel
Contrat conclu pour le devis
79
3° Utilisateur (Maitre de l'oeuvre ou Maitre de
l'ouvrage) et le Système ? Accès au système
général conforme à la
superficie
Figure 26: diagramme de séquence d'accès au
système de gros oeuvre
|
Ouverture de l'interface système
Login
|
|
Authentification : login + pass Word
Présente le devis complet et le
total
Deuxième interface de séquence du système
Introduction de différentes informations Personnelles
Saisir la superficie concernée
Le système
Vérifie les champs et la superficie renvoi le
donnée a chaque rubrique et calcul le sous total et le total
général du devis
Sauvegarde des données
Validation des données
Figure.
Impression du Dévis
Il serait également possible pour nous de commencer
à définir des interfaces pour découper l'ensemble des
opérations en groupe cohérents.
80
| 
