Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
De quel architecture parles-tu celle de ton système ? architecture externe ? Si c'est l'interne, je ne suis pas d'accord. Si tu parles des choix externes, nous sommes bien entendu d'accord… on fait le choix avec de l'écrire dans la spécification. Ceci ne revient en rien sur le fait que l'explicitation des besoins est bien un élément séparé de la spécification externe n'est-ce pas ?Envoyé par hegros
Sinon tu ne réponds qu'à un morceau, serais-tu donc d'accord sur tout le reste ?
Peux-tu rattacher ton propos avec ceci ? Ou détailler ce que tu entends par l'expression des besoins.
Dans le lien que tu donnes, c'est la partie spécification des besoins (ce qu'ici je nommais donc requirement specification) et qu'on retrouve sous ce nom dans IEEE620.12-1990. La spécification définie dans ce même document est ce qui correspond à la spécification fonctionnelle et la spécification non-fonctionnelle. En général, quand on utilise que « spécification » c'est le couple de ces deux éléments dont on parle. Sur ce lien de l'Université de Genève, le terme qui serait équivalant est donc plus cahier des charges. Par contre, de plus en plus de formalisation sur cette partie. S'il n'est pas faux donc, comme indiqué, que la majorité se fait en langage naturel par une liste numéroté, on tend vers des éléments précisés à l'aide de partie formelle pour éviter tout quiproquo ou de syndrome du oui mais. C'est loin d'être généralisé comme habitude hélas.Ça viendra ^_^
C'est un très bon lien selon moi. Bien qu'il passe un peu vite la phase d'élicitation/forage. Mais peut-être n'était-ce pas l'objectif de ce document. En tout cas, l'ingénierie des besoins s'arrête à peu près là; commence alors la phase de conception interne. Ce que la plupart des personnes nomment conception en général.
S'il y a bien un point sur lequel Hegros a raison c'est le fait que les termes sont très malléables et, donc, dangereux à l'utilisation dans le domaine de l'informatique et du GL en particulier. Si c'était la seule chose à retenir de cette discussion se serait déjà bien
C'est un terme générique, ne trouvant plus la main sur le document pour donner plus de précision, il y a déjà bien entendu l'architecture externe pas interne mais aussi du choix des technologies, matériel, langages ou autre progiciel ou composant.
Si tu précises externe je suis d'accord sinon c'est trop généraliste pour moi et on pourrait facilement les confondre.Ceci ne revient en rien sur le fait que l'explicitation des besoins est bien un élément séparé de la spécification externe n'est-ce pas ?
Bon bin ce n'était donc bien qu'une mésentente dans les termes semblent-il.
et justement c'est là que les points de vue divergent...
tout ce que tu énumères ici ne fait pas partie de la spécification des besoins..
Euh ... t'es sûr de toi là ?
oui en tout cas il y a une époque pourquoi qu'est-ce qui ne va pas ?
souviron je n'ai jamais dis cela c'est un aperçu de ce que se cache derrière architecture chez sdms. Spécification des besoins ce n'est pas un terme qu'on utilise partout c'est tout c'est une généralité et très imprécis de plus ce n'est pas le seul que l'on utilise pour désigner la même chose, il y a toute une famille de même terme pour cela.
En plus je distingue fortement expression des besoins ou spécification des besoins avec les spécficiations externes ou l'architecture
Bah si, ça s'utilise à peu près partout...
oui enfin sans sortir la norme 80% des développeurs te donneront des visions différentes de la chose donc cela reste que du théorique, et on ne fait que s'éloigner du sujet donc essaie de ne pas renchérir.
La technologie, le langage ou l'écosystème peuvent être exprimés par un client, cela arrive fréquemment. Si cela ne se traduit pas dans une spec de besoins par un ensemble d'exigences, dans quel document cela doit-il apparaître ? Et comment garantir la couverture ?
Parce que, à mon sens, c'est plutôt une méthode "maison" à base principalement de RUP, avec une notation UML et dans un cadre de certification CMMi3 qui est utilisée chez BNPP ...
je suppose que tu fais référence à des "clients" informatiques..
Mais quand ton réel client est un médecin, un guichetier de banque, un releveur de compteur d'EDF, une téléphoniste du 112, un pilote d'avion, un musicien, un cinéaste, un architecte, une caissière de chez Mammouth, ou à peu près n'importe quel client ordinaire, il n'a aucune idée de ce que signifie :
et il s'en contrefiche... Et il a bien raison..l'architecture externe pas interne mais aussi du choix des technologies, matériel, langages ou autre progiciel ou composant.
Mais par conséquent, la specification des besoins n'a rien à voir avec tout ça...
Pas du tout, l'architecte peut te demander de te coupler à son modeleur 3D pour la génération d'états, le banquier te demander de t'adapter à l'infrastructure réseau existante et le médecin de développer un outil pour son mac.
Quoi qu'il en soit, ce n'est pas toi qui décide de ce qu'exprime un client ou pas. La question est : doit-on écarter l'expression de ce besoin ?
A ton sens ? Je faisais référence à un document de projet type sdms dans lequel c'est la bnp qui en est l'utilisateur dans un projet réel... A mon sens aussi RUP, UML et Cmmi3 s'utiliserait bien dans une organisation de la sorte...
non souviron il ne s'en contrefiche pas à moins d'avoir un client jmenfoutiste en tout cas pour tout ce que j'ai cité ce n'est pas nécessaire sur tout les projets forcément comme le choix du langage par exemple mais pour les réseaux et d'autres choses cela me semble viable parce que le client a bien besoin de réseau, matériel etc...
A priori, l'architecte ne fera que ça te dire "je veux que vous soyez couplés avec le modeleur 3D xxx". Il ne dira rien d'autre. Donc je ne vois pas qu''est-ce qu'on peut en déduire sur le matériel l'architecture, ou quoi que ce soit de technique..
Pour le banquier, c'est kif-kif. Il te dira "nous avons un réseau maison. Il faut être compatible. Maintenant définissons nos besoins en termes de fonctionalités". Il n'a aucune idée de quel protocole est utilisé dans sa boîte, sur quel OS, etc etc...
Et le médecin te dira juste : "j'ai un mac. Je veux un outil qui fasse ceci et cela". Point final. Que ce soit sur un PC avec Linux à côté, il s'en contrefiche.. Si la communication est transparente et le prix correct.
Je ne sais pas.. Je n'ai sans doute pas travaillé sur les mêmes cahiers des charges et projets que toi (si je comprend bien tu es dans le domaine bancaire). Mais dans tous les domaines où j'ai travaillé pas une seule fois je n'ai rencontré un client qui ait une idée quelconque du matériel ou de l'architecture, ou même des termes informatiques autres que "le Web" et "l'informatique" et "la machine". Les spécifications de temps sont "dans un délai raisonnable", et quand tu demandes d'expliciter, on te dit : "ben, quand je bouge la souris, je veux que ça bouge en même temps"..
Alors peut-être que tes utilisateurs/clients sont particulièrement pointus, mais dans la généralité ce n'est pas le cas, et une spécification des besoins a un sens relativement précis, comme l'a dit Garulfo, et ne comprend pas quoi que ce soit qui serait de la "spécification de système", c'est à dire ni du matériel (bas niveau, autre que "un mac"), ni d'une architecture, ni quoi que ce soit de technque..
Je peux te référer à des documents officiels (par exemple Cahier des Charges de l'Assistance Publique pour appels d'offres pour le Dossier Médical Informatisé, document de 500 pages) qui ne comportent pas une seule référence à quelque chose de technique. C'est au contraire à la boîte/pesonne répondant d'expliciter/justifier ses choix techniques.
Pire, je peux te citer le projet sur lequel j'ai travaillé l'hiver dernier, et c'est pas des clients jemenfoutistes, c'est la FAA (Fédération Américaine de l'Aviation), pour équiper tous les aéroports américains de systèmes d'entraînements pour les contrôleurs aériens.. Dans le cahier des charges, il n'est pas fait une seule fois mention d'un terme informatique autre que "système", "reconnaissance de la parole", "synthèses vocale" "historique", "affichage", et "fonctionalité". Tout le reste est exprimé en termes des contrôleurs aériens et des réglements internationaux et nationaux de vol et de procédures utilisateurs... De matériel, d'architecture, de langage, etc etc, aucune mention...
Même chose en médecine, en service clientèle d'un équivalent EDF, en specs pour central téléphonique équivalent 112, etc etc...
Alors peut-être que l'informatique bancaire détourne l'usage des termes, mais alors c'est un cas particulier et non un cas général. Le cas général est représenté par ce que disait Garulfo.
c'est sdms qui fonctionne comme cela(même si leur phase d'architecture système est très élaboré de même que leur phase de définition des besoins) je ne suis ni cascadeur ni dans le domaine bancaire.
le terme me parait encore plus ambigu maintenant que tu le cites Souviron. Est-ce que tu fais une différence entre expression du besoin, définition du besoin et spécification du besoin ?
RUP mets dans la phase d'expression des besoins : ecran, cas d'utilisation et diagramme de classe du domaine.
Donc le cas général de Garulfo s'éloigne aussi de RUP puisque j'ai cru comprendre qu'il disait que les uc ne faisait pas partie de la spécification des besoins. Il s'éloigne aussi de l'afnor qui n'a qu'une phase d'étude préalable mélangeant analyse de l'existant, diagnostic et proposition de solution ensuite c'est de la conception donc...
En fait ce cas général ne me semble pas l'etre plus que cela.
Je me demande bien à quel livrable vous pouvez penser pour 'spécification des besoins'
Y'a 10 ans peut-être. Aujourd'hui, la démocratisation de l'outil est tel, que les clients ont entendu parler du web 2.0, des réseaux sociaux, contributifs, ils savent ce qu'est le p2p et comment s'en servir. Ils savent ce qu'est linux ou mac os. Ils connaissent également quelques notions d'éléments d'archi réseau, comme le bluetooth, le wifi, ou l'adsl, à quoi sert un pare-feu, ce qu'est un serveur et un partage de fichier. Ils savent ce qu'est une résolution écran. Ils ont aussi des notions d'espace disque et mémoire.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
C'est d'autant plus flagrant que le client est jeune (30/40 ans). C'est pas le seul domaine démystifié, le médical l'a été dans les mêmes proportions. Le nombre de patients qui diagnostiquent via doctissimo et vont voir un médecin avec la solution en poche...
Donc, faire parler un client, dans le processus de recueil du besoin, et dans la mesure ou tu ne le cadre pas de manière dirigée, peut très bien découler à l'expression d'un besoin portant sur des éléments qui ne sont pas purement fonctionnels. La question reste toujours, que fais-tu de ces exigences ?
Aucune de fond... (voir plus bas)
Encore une fois, je ne mettrais pas "diagramme de classe". Informatique. N'a rien à voir avec les besoins.
Et je suis d'accord avec lui (voir ci-dessus).
Non désolé, l'Afnor, comme la norme DoD, sépare bien ce qui fait partie de la définition du Cahier des Charges (qui en général est fait par le client et spumis à plusieurs prestataires), des études préalables, puis de la proposition de solutions (qui sont le fait de chaque prestataire .. Ce sont des devis) (qui est au niveau global de toute façons à cette étape-là), et enfin de la conception, qui commence à rentrer dans le "comment on fait" (et qui est uniquement à faire par le prestataire choisi, et non pas par l'ensemble de ceux auxquels on a demandé un devis).
Comme on l'a dit plus haut : un Cahier des Charges recensant sous forme de document structuré et en arborescence les fonctionalités attendues, exprimées uniquement dans les termes des utilisateurs, avec éventuellement des contraintes techniques mais pas obligatoirement (du style soit de ce que j'ai mentionné ci-dessus ("déplacement à la vitesse de la souris", "temps raisonnable") soit dans un cas particulier ("doit fonctionner sur tel type de machine").. Accompagné éventuellement d'un document présentant des schémas d'écrans si le client a suivi une démarche ergonomique et a fait faire au préalable une étude ergonomique des besoins.
Sans plus.
Primo, je ne suis pas d'accord avec toi, mais je ne vais pas me battre là-dessus. Je pense qu'au contraire c'est un signe de plus du non-avancement (et même du recul) de l'informatique, malgré toutes les nouvelles méthodes etc etc, que de continuer à "forcer" la main techniquement aux utilisateurs, au lieu de laisser le libre cours à l'expression du besoin indépendamment de la technologie. Et d'assumer que parce que "la technologie est dans nos vies", cela a plus de signification qu'il y a 10 ans pour quelqu'un qui n'est pas du métier... Même moi, tu me demandes entre Web 2.0 et 1.5, ben , je sais rien...
Si ce sont vraiment des exigences, alors il faut s'y conformer. Mais pas avant d'avoir tellement mis la pression pour ébranler les convictions que l'on est absolument certain que ce sont des exigences réelles, et non pas fantasmatiques..
Maintenant, tout ce débat, au demeurant fort intéressant, est totalement HS...
C'est un terme extrêmement utilisé en Amérique du Nord puisqu'il est clairement définie par IEEE620.12-1990 qui est une norme très répandue ici. J'ai souvent parlé avec des Européens qui savaient très bien ce que cela représentait notamment dans les conf' de GL.
Je t'encourage à aller lire cette norme
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager