Expression de besoins

Architectures Logicielles Java(2)

Modérateurs : graffion, jmdouin, agoncal, mlebihan

mlebihan
Messages : 114
Inscription : 09 févr. 2007 1:03

Expression de besoins

Message par mlebihan » 16 mars 2010 7:32

Bonjour,


Vous êtes entrain de rédiger une expression de besoins qui comporte probablement dix à vingt cas d'utilisation initiaux. Parfois plus.

En rédigeant l'analyse fonctionnelle, l'étape qui suivra celle-ci, il y en aura certainement d'autres qui vont apparaître.
Admettons qu'à l'issue de cette analyse vous possédez entre vingt et trente cas d'utilisation.

La période des développements sera de quatre mois environ, de Juin à Octobre. Quel est le minimum qu'il vous semble nécessaire de réaliser pour que votre application soit digne d'être présentée lors de la soutenance?
Ces cas là formeront l'ensemble des cas d'utilisation critiques. Que l'un d'entre-eux manque à l'appel, et votre logiciel est compromis. Il perd son sens.

Votre application est un projet professionnel? Vous êtes certainement attendu avec des cas d'utilisations supplémentaires par votre entreprise.
Ce sont les cas d'utilisations très importants. Ce que l'on peut percevoir comme les atouts majeurs de votre application. Sitôt que les cas d'utilisations critiques auront été implémentés et testés, c'est vers ceux-là que vous vous pencherez.

Il y a peut-être des fonctionnalités très sympathiques auxquelles vous avez pensé, que vous essaierez de mettre en place dès que l'occasion se présentera.
Ce sont les cas d'utilisation importants. Il simplifieront le quotidien de ceux qui emploieront votre application, par exemple.

Enfin, restent tous les autres cas qui sont moins essentiels. Ils sont utiles, mais leur mise en œuvre se fera vraisemblablement à une date ultérieure.


Il ne faut pas hésiter à rechercher tous les cas d'utilisation qui viennent à l'esprit, parce que plus on en trouve:
- moins ils sont critiques,
- mieux on perçoit ce que son application fera, finalement.

Par contre, sitôt qu'on en a trouvé des quantités importantes, il faut bien les classer pour se donner un ordre de traitement, et ne pas se sentir envahi.


Si votre application a 25 cas d'utilisation au jour où vous débutez l'implémentation, ses cas d'utilisation seront sans doute répartis ainsi:
12 cas d'utilisation critiques,
6 cas d'utilisation très importants,
3 cas d'utilisation importants,
4 cas d'utilisation utiles.

La répartition et le nombre de cas dans chaque rubrique dépend évidemment de votre projet.


Pour nous, le problème se pose ainsi:
Si un cas d'utilisation n'est pas décrit dans le document d'analyse, il ne le sera pas non plus dans les autres documents. Et nous ignorerons tout ce à quoi vous aurez à faire face. Notre suivi sera plus difficile, moins précis.

Il faut que vous décriviez les cas d'utilisation critiques (le minimum pour la soutenance),
et quelques-uns des cas d'utilisation très importants, pour que nous puissions voir où l'application devrait aller ensuite, et que nous puissions éventuellement changer la priorité d'un cas dans un sens ou dans un autre.

Je vous recommande aussi, cela dans le but de vous aider, de mentionner d'une seule ligne les cas d'utilisations dits "importants" et "utiles"
"L'abonné affiche un historique de ses connexions"
"Le participant à un forum recherche tous les messages d'un autre participant"
"L'utilisateur lance une sauvegarde des données"
etc.

Quelques-fois, il arrive que l'on perde le fil du logiciel que pourtant l'on construit. Et relire ces simples lignes, même s'il n'est pas si urgent de les faire suivre d'effet, aide à en retrouver l'esprit.
Ensuite, cela accroît la capacité d'anticipation. Avoir écrit ces phrases, c'est autant de demandes que l'on pourra vous faire plus tard et qui ne vous surprendront pas. Que vous puissiez y répondre alors ou non restera à voir, mais elles ne vous prendront pas de court.

Donc pour conclure, dans ce document d'analyse plus on décrit de cas
et plus l'on se donne de chances.


Une dernière recommandation: oui, le diagramme des cas d'utilisation présente bien un besoin. Mais il ne faut pas oublier de lui mettre tout de même deux lignes d'un texte introductif qui dit: "Lorsque <tel acteur> se trouve dans <cette situation>, il a besoin d'agir pour obtenir <tel document/objet> ou <débuter ou demander qu'un travail soit fait>.".


Marc Le Bihan.

fabszn
Messages : 23
Inscription : 14 oct. 2005 10:22
Contact :

Re: Expression de besoins

Message par fabszn » 29 mars 2010 14:11

Bonjour,

Concernant le document d'expression des besoins.
J'ai rendu hier une version pas finalisée. Est ce qu'il est possible sera possible de livrer une version plus aboutie?

Merci d'avance pour votre aide,

Cordialement,

graffion
Messages : 651
Inscription : 21 juin 2005 14:05

Re: Expression de besoins

Message par graffion » 29 mars 2010 17:12

Oui dans la mesure où vous avez la chance de faire partie du 2-ième groupe (auditeurs de O à Z) pour lequel la revue aura lieu dans plus d'une semaine.

fabszn
Messages : 23
Inscription : 14 oct. 2005 10:22
Contact :

Re: Expression de besoins

Message par fabszn » 29 mars 2010 17:36

Bonjour,

Merci pour votre retour,

Cordialement,

Répondre

Qui est en ligne ?

Utilisateurs parcourant ce forum : Aucun utilisateur inscrit et 1 invité