II.2 Risques critiques
Avant de se lancer dans la conception, il faut
déterminer les principaux risques, mettant en danger la
réalisation du projet, afin de les atténuer le maximum possible.
La détermination de ces risques est très importante, par exemple
elle peut influencer la définition de l'ordre de priorité des cas
d'utilisation. En effet, si le langage de programmation présente un
risque, nous aurons intérêt à commencer par le cas
d'utilisation le plus simple. Nous faisons face à deux types de risques
:
Risques non techniques :
> Délai de livraison : En effet, nous sommes
contrariés par le délai de dépôt du mémoire,
fixé à trois mois du début de 2éme semestre, et par
l'ampleur de notre projet.
> Difficulté de l'extraction des informations :
L'extraction de la bonne information nous semble une tâche assez
délicate.
Risques techniques :
> Le non maîtrise du langage de programmation :
L'implémentation avec un langage que nous ne maîtrisons pas, est
un risque technique critique, surtout que le délai de livraison est
relativement court.
> L'ambiguïté du processus unifié : En
effet, le point fort du processus unifié réside dans son
ambiguïté car s'il est adaptable à divers types de projets,
c'est parce que sa
démarche est générique. Pour cela, nous
sommes amenés à bien adapter le processus à notre
projet.
II.3 Diagrammes de cas d'utilisation
i) Diagramme de cas d'utilisation global
Ce diagramme représente tout les cas d'utilisation
relative à notre système.
ADMINISTRATEUR
gestiondes forfaits
gestion des salles
gestion des employés
gestion des fiches
medicales
des
patients
gestion des comptes des
d'utilis ateurs
Gestion des rendez-vous
gestion des séances
gestion des prestations
gestion des machines
gestion des paiements
«extend»
Authentification
secrétaire
Informaticien
Figure 3 : diagramme des cas d'utilisation global
ii) Diagrammes des cas d'utilisation
détaillés
a. Diagramme des cas d'utilisation relatif à
l'administrateur :
Ce diagramme (voir figure 4) représente tous les cas
d'utilisations relatives au premier acteur qui est l'administrateur.
ADMINISTRATEUR
authentification
gestion des employés
gestion des prestations
gestion des
paiem ents
gestion des forfaits
gestion des machines
gestion des salles
Figure 4 : Diagramme des cas d'utilisations relatif
à l'aministrateur b. Diagrammes des cas d'utilisations relatif à
la secrétaire :
Le diagramme de la figure 5 représente tous les cas
d'utilisations relatifs au deuxième acteur qui est la secrétaire
du centre de kiné.
secrétaire
authentification
gestion des rendez-vous
gestion des paiements
«include»
gestion de la disponibilté
des
machines
gestion des fiches médicales
des
patients
«include»
«include»
gestion de la disponibilité
des
employés
«include»
gestion des occupation des
salles
gestion des séances
Figure 5 : Diagramme des cas d'utilisation relatif
à la secrétaire c. Diagramme des cas d'utilisation relatif
à l'informaticien
Ce diagramme (voir figure 6) représente tous les cas
d'utilisations relatifs au troisième acteur qui est l'informaticien.
informaticien
gestion des comptes des utilisateurs
Authentification
Figure 6 : Diagramme des cas d'utilisation relatif
à l'informaticien Ayant réalisé cette phase, nous
avons réussi à répondre aux questions suivantes :
- Le projet vaut-il la peine d'être entrepris ?
- Quels sont les principaux utilisateurs de notre futur
système ?
- Quelles fonctionnalités notre futur système
doit-il offrir pour satisfaire les besoins des différents acteurs ?
Ceci nous a permet de passer à la phase
d'élaboration, dans laquelle nous entamerons la l'analyse des cas
d'utilisation. Ci-dessous, nous présentons les diagrammes de
séquence associés aux cas d'utilisation.
| 
