B. Identification et
présentation des besoins
1. Présentation du projet à
réaliser
a) Résultats attendus
Notre souhait est que l'application se déroule
convenablement, de conserver ces fonctionnalités dans l'application, et
d'améliorer s'il est possible les performances du système ainsi
que les bases des données existantes.
b) Architecture de l'application
Dans les phases préliminaires du développement
d'une application ou de la refonte d'un système d'information, la
définition de l'architecture technique consiste à faire les choix
de technologies et d'organisation de composants logiciels les plus
adaptés aux besoins et aux contraintes de l'organisation d'octroi
d'immatriculation.
c) Présentation de l'architecture à 2
niveaux
L'architecture à deux niveaux (aussi appelée
architecture 2-tiers, tiers signifiant étages en anglais)
caractérise les systèmes clients/serveurs dans lesquels le client
demande une ressource et le serveur la lui fournit directement. Cela signifie
que le serveur ne fait pas appel à une autre application afin de fournir
le service.
d) Présentation de l'architecture à 3
niveaux
Dans l'architecture à 3 niveaux (appelées
architecture 3-tiers), il existe un niveau intermédiaire,
c'est-à-dire que l'on a généralement une architecture
partagée entre:
1. Le client: le demandeur de ressources
2. Le serveur d'application (appelé aussi
middleware): le serveur chargé de fournir la ressource
mais faisant appel à un autre serveur
e)Le serveur secondaire
(généralement un serveur de base de données), fournissant
un service au premier serveur.
Tout système d'information nécessite la
réalisation de trois groupes de fonctions: le stockage des
données, la logique applicative et la présentation. Ces trois
parties sont indépendantes les unes des autres: on peut ainsi vouloir
modifier la présentation sans modifier la logique applicative. La
conception de chaque partie doit également être
indépendante, toutefois la conception de la couche la plus basse est
utilisée dans la couche d'au-dessus. Ainsi la conception de la logique
applicative se base sur le modèle de données, alors que la
conception de la présentation dépend de la logique applicative.
2. Recensement des besoins
|
Id
|
Etant que
|
Priorité
|
Poids d'estimation
|
Couleur
|
|
1
|
Cellule d'immatriculation ; je dois ajouter un
propriétaire
|
S
|
10
|
Grise
|
|
2
|
Je dois affecter un ou plusieurs véhicules à un
propriétaire
|
M
|
15
|
Bleu
|
|
3
|
Identifier tous les véhicules sur le territoire
national
|
S
|
10
|
Grise
|
|
4
|
Je dois rechercher, modifier, supprimer les informations
|
C
|
25
|
Bleu
|
|
5
|
Supprimer un numéro d'immatriculation qui n'est pas en
circulation
|
W
|
10
|
Bleu
|
|
6
|
Bureau informatique, je dois revoir l'historique d'octroi
d'immatriculation
|
S
|
5
|
Bleu
|
|
7
|
Je dois ajouter, modifier, supprimer, annuler et rechercher les
immatriculations
|
C
|
10
|
Grise
|
|
8
|
Propriétaire, je dois avoir l'immatriculation de mon
véhicule
|
W
|
5
|
Bleu
|
|
9
|
m'aider à la recherche du véhicule au cas où
ce dernier est volé
|
S
|
10
|
Bleu
|
Le tableau de Recensement des besoins des acteurs est dit
aussi tableau d'avancement d'un projet, il permet à tous les acteurs du
projet d'exprimer leur besoins pour la future application qui sera
conçu.
La colonne priorité représente l'importance du
besoin par rapport aux attentes des utilisateurs. Les fortes priorités
doivent être développées en première position ;
mais la priorité peut changer. Pour prioriser les besoins des
mutilateurs, il y a une méthode de priorisation appelée MSCW.
· M : master hase
this: sont des besoins qui doivent être fait (les besoins
vital de l'organisation).
· S : schould hase at all
possible: les besoins qui devraient être fait dans la mesure du
possible (besoins essentiels).
· C : could hase this if it does not
affect anything else : les besoins qui pourraient être
fait dans la mesure où cela n'a pas d'impact sur les autres taches
(confort).
· W : won't hase this time but wald
ikein the feature : les besoins qui ne seront pas fait cette
fois mais seront fait plus tard.
Le poids représente la charge d'un travail ou la
concertation que doit faire les agents pour terminer une tache. Mais celui qui
a une forte priorité n'a pas toujours un grand poids.
Chaque acteur donne aussi son point de vue sur la couleur
des formulaires de l'application et cela en tenant compte de l'agronomie ou les
comportements de l'application face à l'utilisateur.
D. Identification des acteurs
Un acteur représente un rôle joué par une
personne qui interagit avec le système.
Par définition, les acteurs sont à
l'extérieur du système.Les acteurs se recrutent parmi les
utilisateurs du système et aussi parmi les responsables de sa
configuration et de sa maintenance. D'où, les acteurs potentiels qui
risquent d'interagir avec l'application sont :
· Le propriétaire : c'est la personne qui est
en possession d'un véhicule, qui veut qu'on l'octroie un numéro
matricule ;
· Division informatique : c'est un service
chargé d'imprimer le numéro d'immatriculation en accord avec la
cellule d'immatriculation ;
· Cellule d'immatriculation : il est chargé
de coordonner, percevoir le frais et de livrer le numéro
d'immatriculation.
E. Figure 2 :
Identification des acteurs
F. Figure 3 :
Identification des cas d'utilisation métier
G. Diagramme de cas d'utilisation
Montre les interactions fonctionnelles entre les acteurs et le
système à l'étude
Acteur : rôle joué par un
utilisateur humain ou un autre système qui interagit directement avec le
système étudié. Un acteur participe à au moins un
cas d'utilisation.
Cas d'utilisation (use case) : ensemble de
séquences d'actions réalisées par le système
produisant un résultat observable intéressant pour un acteur
particulier. Collection de scénarios reliés par un objectif
utilisateur commun.
Association : utilisée dans ce type de
diagramme pour relier les acteurs et les cas d'utilisation par une relation qui
signifie simplement « participe à ».
Inclusion : le cas d'utilisation de base en
incorpore explicitement un autre, de façon obligatoire, à un
endroit spécifié dans ses enchaînements.
Extension : le cas d'utilisation de base en
incorpore implicitement un autre, de façon optionnelle, à un
endroit spécifié indirectement dans celui qui procède
à l'extension
Généralisation : les cas
d'utilisation descendants héritent de la description de leur parent
commun. Chacun d'entre eux peut néanmoins comprendre des relations
spécifiques supplémentaires avec d'autres acteurs ou cas
d'utilisation.
 Figure 4 : Diagramme de cas
d'utilisation
| 
