Discussion :

[hegros]

je suis un programmeur objet, la norme c'est une interface pas une implémentation...la spécification des besoins moderne à la rup et cie me convient largement et la cascade ne me dis rien.

mais si un jour j'ai un peu de temps et que je me souviens de tout les chiffres de la norme on lira probablement un petit bout parce qu'après il faut digérer

[Garulfo]

je suis un programmeur objet, la norme c'est une interface pas une implémentation...la spécification des besoins moderne à la rup et cie me convient largement et la cascade ne me dis rien.

Je comprends mal ce que tu dis... pas compris le truc de norme/interface/implémentation ?

Et il me semble que tu penses que la norme IEEE ne parle que de la méthode en cascade ? C'est un peu plus large que ça Ça parle de tout ce qui touche l'ingénierie (logiciel dans notre cas). La 610.12 (me suis trompé de chiffre -_-) donne les définitions dans le domaine de l'ingénierie logiciel. La 830 est celle du document de spécification logiciel et la 1230 celle du document de spécification système (englobant plus que le logiciel donc).
Voici les deux premières... pour en voir plus tu dois être membre (mais tu l'as dans toute bibliothèque universitaire je suppose).
http://standards.ieee.org/reading/ie...1990_desc.html
http://standards.ieee.org/reading/ie...1998_desc.html


Le terme requirement specification est un terme ultra standard en Amérique du nord et, j'en suis convaincu, complètement compris en Europe.

[souviron34]

pour terminer, j'ajouterais que :

je suis un programmeur objet, la norme c'est une interface pas une implémentation..

Que ce soit objet, procédural, assembleur, ou tartempion, la spécification des besoins en est indépendante, c'est ce qu'on te dit depuis quelques posts

Et ne comprend ni "interface" ni "implémentation"..

Et que tu sois programmeur, analyste, architecte ou chef de projet, ça n'y change rien du tout...

Là-dessus, bonne lecture, car les pointeurs de Garulfo sont essentiels

[el_slapper]

(.../...)
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...

Ben, à l'autre extrémité de l'échelle, mon père qui fait du logiciel/site web pour TPE, parfois il a liberté absolue quand à l'outil, et parfois c'est "faites moi une macro pour excel 2002 en un seul onglet, et qui doit marcher sans rien d'extérieur". Alors qu'il aurait préféré faire ça en windev(j'ai même du le former à VBA à l'occasion, je ne pensais pas avoir l'occasion de lui apprendre quoi que ce soit).

Et moi qui bosse en bancassurance(pas du tout la même echelle), j'ai parfois en plus des exigences sur la manière de coder, d'organiser et de nommer mes livrables, etc.....en bref, des exigences techniques internes. Et ce, à fin de cohérence interne. Il arrive que ça soit aussi important que le besoin fonctionnel du client. Parceque si je me mets à faire du Cobol "objets", ce qui est possible maintenant qu'on est passés à cobol3, et que personne ne peut maintenir mon boulot, je commets une faute professionelle - même si ça tourne impeccablement. Alors que tout le monde ici sait faire de l'impératif(j'ai touvé un moyen, certes tordu, de revenir au sujet ).

[hegros]

Le terme requirement specification est un terme ultra standard en Amérique du nord et, j'en suis convaincu, complètement compris en Europe.

En fait c'est un terme qu'on utilise oui, nous dans des projets en plus avec des américains, cependant je trouve que c'est un abus de langage (en même temps je suis très jeune en GL) requirement me semble suffisant pour savoir de quoi on parle. C'est plus précis aussi parce qu'avec requirement on associe un peu ce qu'on veut comme mot et donner d'autres sens.


Merci pour les 2 liens, je n'y manquerais pas d'aller lire


Euh Souviron oui cela on le savait déja et pour l'afnor je pense que tu te trompes c'est dommage que je n'arrive plus à remettre la main sur leur découpage.


Je rajouterais Souviron aussi que c'est imprécis ce que tu exprimes sur le cahier des charges. En te lisant cela ressemble à un cahier des charges fonctionnel, parce qu'il y a aussi le cdc technique, d'exploitation, maintenance.... J'ai l'impression que pour toi il n'existe qu'un cdc et tu limites l'expression des besoins à du fonctionnel....



Pour la petite blague sur la norme/interface/implémentation () c'est pas drôle en fait. La norme c'est ce qui est reconnu par une assemblée d'expert comme étant la normalité des termes ou façon de procéder. Mais il n'y a rien qui se passe normalement dans un projet les équipes ne partagent pas forcément tout ce vocabulaire en commun et les projets marchent...

[dancom5]

A mon avis, il faudrait plutôt voir le fameux sujet là : http://www.developpez.net/forums/d66...rientee-objet/

Un exemple concret de comparaison serait bien.

un côté le code en procédural et de l'autre ou en dessous, le code en objet. S'il y a des liens, ça m'intéresse.