2.3.4. Priorité des cas
d'utilisation
Afin de faciliter notre travail, il nous semble judicieux de
répartir les cas d'utilisation initiaux en des cas prioritaires et
autres secondaires afin de faciliter notre travail et constituer nos
itérations. Nous avons réduit le nombre de nos itérations
à quatre se référant chacune à un modules de
gestion à implémenter. Nous allons commencer par la gestion
des utilisateurs pour assurer la sécurité lors de
l'accès à notre application. Ensuite la gestion de lancement
de projet pour la création de ce dernier, puis la gestion des
risques et enfin la gestion des plans d'action.
En fait, nous considérons les cas d'utilisation «
Identifier risque », « Analyser risque», « Mitiger un
risque », « Consulter risque » et
« Consulter le top ten risque » les plus prioritaires dans
la gestion de risque, « La saisie de la fiche de lancement de
projet » pour la gestion de lancement de projet et en fin
« L'ajout d'une nouvelle action » pour la gestion des plan
d'action, et enfin « Ajouter un utilisateur » pour la
gestion des utilisateurs. Les autres cas d'utilisation seront secondaires, par
conséquent nous n'allons pas s'attarder à les concevoir. Nous
avons adopté ce choix dans le but de minimiser le risque de la non
maîtrise du langage de programmation et afin d'être conforme,
à la chronologie de la gestion de projet cité auparavant. En
effet, ces cas d'utilisation sont assez simples à concevoir et à
analyser, ce qui nous aidera à découvrir le langage de
programmation petit à petit.
La figure 2.6 résume tout ce que nous venons de dire
à propos des modules de notre application, elle donne une projection sur
la future application à implémenter et sa situation par rapport
à la plateforme du système existant.
Figure 2.6 - Architecture de l'application -
| 
