IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

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

Qualité Discussion :

[Qualite]Conception de spécifications techniques


Sujet :

Qualité

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    7
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 7
    Points : 6
    Points
    6
    Par défaut [Qualite]Conception de spécifications techniques
    bonjour à tous,
    Dans le cadre de mon stage je dois rédiger des spécifications techniques.
    J'ai déjà rédigé le cahier des charges mais je me demande si les specs doivent reprendre les points du cahier des charges avec en plus tout ce qui se rapporte à la conception (UML, MCD ...) mais aussi des pistes de solutions techniques ou alors faut il se baser sur un tout autre plan que celui du cahier des charges fonctionnel ?
    Je précise que ces specs sont pour un site intranet qui sera développé en asp.net (code vb.net behind).
    De plus si quelqu'un a quelques tutos sur la rédaction de specs mais aussi documentation utilisateurs je suis preneur ...

    D'avance merci.

  2. #2
    Membre actif Avatar de LineLe
    Inscrit en
    Septembre 2003
    Messages
    285
    Détails du profil
    Informations personnelles :
    Âge : 41

    Informations forums :
    Inscription : Septembre 2003
    Messages : 285
    Points : 246
    Points
    246
    Par défaut
    Bonjour,

    Je ne suis pas experte, mais à mon sens il faut bien différencier la spécification fonctionnelle et la spécification technique.

    Dans la spécification fonctionnelle tu vas répondre à ce qui a été décrit dans le cahier des charges avec, comme tu dis, tout ce qui se rapporte à la conception. Mais en aucun cas dans les specs fonctionnelles tu ne donnes de solutions techniques.

    Citation Envoyé par Wikipedia
    La spécification fonctionnelle est la description des fonctions d'un logiciel, en vue de sa réalisation.

    Une spécification fonctionnelle est indépendante de la façon dont sera réalisé le logiciel en question.

    Il existe deux sortes de spécifications fonctionnelles :

    * Les spécifications fonctionnelles générales (SFG), qui décrivent le modèle métier, élaborées par la maîtrise d'ouvrage,
    * Les spécifications fonctionnelles détaillées (SFD), qui sont élaborées par la maîtrise d'œuvre.
    Maintenant pour moi, les spécifications techniques, ce serait plutôt pour décrire d'une part les contraintes et exigences techniques, et d'autre part éventuellement comme tu dis des pistes de solutions techniques, mais je dirais de l'ordre général.
    Pour le plan je pense que ça dépend vraiment du projet... Ce qui peut être transparent d'un point de vue utilisateur, peut être une véritable usine à gaz derrière (flux etc...)

    mais là je ne suis pas sûre de vraiment répondre à ta question

  3. #3
    Membre averti Avatar de Sacha999
    Inscrit en
    Mars 2007
    Messages
    294
    Détails du profil
    Informations personnelles :
    Âge : 44

    Informations forums :
    Inscription : Mars 2007
    Messages : 294
    Points : 350
    Points
    350
    Par défaut
    Pour moi,
    - spécification fonctionnelle: ca doit faire quoi.
    - spécification technique: ca doit etre fait comment.

    Dedans tu notes tout ce qui aidera le developpeur pour son developpement:
    - Norme de nommage
    - Technologie utilisé
    - Processus
    - Mecanisme
    Le forum c'est trop génial

  4. #4
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    +1 pour Sacha999

    Le fonctionnel doit répondre à la question : qui doit faire quoi comment

    * Qui : description du role de chaque utilisateur
    * doit faire quoi : descriptions des permissions de chaque rôle
    * comment : description du workflow (cliquer ici, aller dans le menu tel, charger tel plugin etc.)

    Le technique doit répondre à la question comment uniquement.

    Le comment du technique et le comment du fonctionnel sont différents. Dans le fonctionnel, on réponds à la question comment est-ce que c'est sensé marcher. Dans le technique, on réponds à la question comment est-ce que ça sera implémenté, avec autant de détails jugés nécessaires. C'est usuellement quelques workflow, quelques flowcharts, quelques diagrammes UML, et un MCD ou plusieurs MCD/MDD. Le plus important reste la rédaction qui doit être didactique et formelle.

  5. #5
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    J'ajouterais que l'effort fournit pour écrire ces spécifications, souvent jugées (à tort) non nécessaires, est récompensé par la rapidité d'implémentation qui viens derrière et le faible nombres de bugs dues à une mauvaise conception.

    En effet, si on commence à coder avant d'avoir une vision *complète* de tout le projet, le code risque d'être partiellement utile (c'est le verre à moitié plein ou à moitié vide, c'est selon l'observateur). Par exemple, on commence à coder la fonctionnalité A, puis, on s'apperçoit que la fonctionnalité B qui dépends de A ne peut pas être implémenté dans l'état actuel de A, car A n'a pas été conçu pour supporter B. De plus, si A a été perfectionné jusqu'à un certain stade (bugs résolus, réécritures multiples etc.), cet effort aura été vain si A doit encore être reconçu. C'est un peu comme si vous écriviez un document dans Word, et que vous mettez tout de suite en forme votre texte. Si le contenu doit être revu (insertion de tableau, paragraphes déplacés etc.), toute la mise en page fou le camp et tout le temps que vous y avez déjà passé avec : c'est une perte de temps. Au contraire, la bonne démarche serait d'abord de mettre tout votre contenu à plat, et une fois la version définitive de votre texte déterminée, vous mettez en forme.

  6. #6
    Membre émérite
    Avatar de Mickael_Istria
    Homme Profil pro
    Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Inscrit en
    Juillet 2008
    Messages
    1 468
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur Expert Eclipse IDE/RCP, pour Red Hat
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Juillet 2008
    Messages : 1 468
    Points : 2 996
    Points
    2 996
    Par défaut
    Certes, mais souvent, ce sont les spécifications elles-memes qui changent...
    Pour du HTML, CSS, JavaScript, TypeScript, JSon, Yaml, Node... dans Eclipse IDE, installe Eclipse Wild Web Developer
    Pour du Rust dans Eclipse IDE, installe Eclipse Corrosion
    Follow me on twitter

  7. #7
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    Les spécifications qui changent peuvent être la conséquence d'une mauvaise phase d'analyse et de récolte des besoins, ce que je vis en ce moment même. Le projet sur lequel je travail a été conçu sans spécifications et sans une réelle récolte des besoins utilisateurs ce qui risque de donner à la fin un produit qui ne répondra pas aux attentes.

    Mettre l'utilisateur au centre du système est très important. C'est ce qui a permis à l'astronomie d'avancer grandement : mettre le soleil (et non la terre) au centre du l'univers (la notion de système solaire n'existait pas avant). Avant cela, les calculs théoriques basés sur la géometrie et les résultats d'observation ne correspondaient pas. Il y a une certaine similarité avec un système informatique : le logiciel une fois fini (avec comme "théorie" ses mauvaises spécifications techniques) ne corresponds pas à la fin avec les observations sur le terrain (attentes des utilisateurs).

  8. #8
    Membre expérimenté

    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    1 377
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 377
    Points : 1 628
    Points
    1 628
    Par défaut
    Citation Envoyé par yacinechaouche Voir le message
    Les spécifications qui changent peuvent être la conséquence d'une mauvaise phase d'analyse et de récolte des besoins...
    Ou pas ... Les spécifications changent, souvent parce que le besoin évolue, car on peut pas forcément tout prévoir et voir dés la première phase d'analyse. Dans l'informatique le besoin évolue, rien de plus normal alors que d'adapter le logiciel avec les nouveaux besoins ;-) soyons agile... Et pour le coup je suis absolument d'accord avec ton affirmation "Mettre l'utilisateur au centre du système".
    Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.

    Twitter Blog Mon site

    Mon article sur l'agilité

  9. #9
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    Oui c'est vrai, et c'est peut être plus difficile d'y remédier dans ces cas là. J'ai vu ton blog où tu propose d'exposer ton retour d'expérience sur les méthodes agiles. J'imagine que tu as déjà rencontré cette situation (changements de specs dues aux changements de besoins). Quelle est l'apport des méthodes agile pour répondre à ce changement ?

  10. #10
    Membre expérimenté
    Profil pro
    Inscrit en
    Juillet 2006
    Messages
    1 103
    Détails du profil
    Informations personnelles :
    Âge : 46
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 103
    Points : 1 561
    Points
    1 561
    Par défaut
    imagine quand le client n'est pas fichu de se fixer sur son besoin...

    si tu compte sur le client pour avoir un cahier des charges fonctionnel fixé et rigide dès le début du projet pour faire l'analyse et la spécification technique... tu va en avoir des déconvenues...

    je peux le dire, je suis en train de le vivre, j'en suis à la sixième révision, et il n'y a rien à faire... à chaque réunion... les clients en ressorte une couche, oui mais en fait c'est trop restrictif, blablabla... à noter tout de même que si c'était trop restrictif, c'était leurs spécifications fonctionnelles de départ, et heureusement qu'on est pas resté figé, comme tu le suggèrerais un peu trop, sinon le produit ne servirait strictement à rien...
    c'est d'autant plus vrai pour un développement spécifique, et surtout quand celui ci inaugure pour le client, un changement de procédures et de fonctionnement interne, une restructuration des process et des workflow...
    (et s'ils n'y n'en avaient pas avant, et que c'était un peu à la vas y que je te pousse, ce qui est très souvent le cas dans toutes les structures publiques... c'est encore pire)

    c'est bien simple, vu que j'ai toujours pas de spécification finale immuable, j'ai pris le partie de développer le socle invariant, avant d'avoir achevé l'analyse, car sinon les délais ne seront jamais respectés...

  11. #11
    Membre expérimenté

    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    1 377
    Détails du profil
    Informations personnelles :
    Âge : 39
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 377
    Points : 1 628
    Points
    1 628
    Par défaut
    J'allais partir sur un long exposé mais je vais essayer d'être pas trop long

    Disant que comme le souligne "cinemania" c'est après l'utilisation du produit qu'on se rend compte qu'il y a des ajustements à faire... Alors les méthodes agiles avec leurs modes itératifs et incrémentales, permettent de proposer régulièrement des versions fonctionnels du produit.
    En plus le client est mis au centre des débats dans les méthodes agiles, il est souvent conseillé d'avoir un représentant du client intégré dans l'équipe (à plein temps ou au pire partiellement), les spécifications ne sont pas figées dans le temps elles évoluent (à l'oubliette la notion de cahier des charges) on préfère l'échange et le test (ceci n'est pas synonyme d'absence de documentation), donc on récolte continuellement le besoin, on traite d'abord les éléments les plus prioritaires et on valide continuellement que le produit répond aux besoins utilisateurs.

    Ceci se matérialise en Scrum par exemple (une des méthodes agiles la plus en vogue) dans un backlog de produit (c'est une liste priorisée des fonctionnalités), le représentant client autrement dis le Product Owner le mets continuellement à jour et gère les priorités... Chaque fonctionnalité peut être représentée en une User Story (on peut faire le parallèle avec les Use Case dans une approche classique) ou plusieurs, ensuite elles peuvent être enrichi à travers des critères d'acceptations qui sont des scénarios du fonctionnement attendu (ces scénarios sont une source pour les tests fonctionnels automatisées). Ce fonctionnement permet de proposer régulièrement les éléments les plus prioritaires dans une version fini du produit tout en répondant au mieux au besoin initial...
    Échouer, c'est avoir la possibilité de recommencer de manière plus intelligente.

    Twitter Blog Mon site

    Mon article sur l'agilité

  12. #12
    Nouveau Candidat au Club
    Homme Profil pro
    Chef de projet MOA
    Inscrit en
    Septembre 2011
    Messages
    1
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Chef de projet MOA

    Informations forums :
    Inscription : Septembre 2011
    Messages : 1
    Points : 1
    Points
    1
    Par défaut
    Le comment du fonctionnel c'est ce que l'on appelle la spécification fonctionnelle détaillée non (un seul responsable, côté Maitre d’œuvre) ?

    Citation Envoyé par yacinechaouche Voir le message
    +1 pour Sacha999

    Le fonctionnel doit répondre à la question : qui doit faire quoi comment

    * Qui : description du role de chaque utilisateur
    * doit faire quoi : descriptions des permissions de chaque rôle
    * comment : description du workflow (cliquer ici, aller dans le menu tel, charger tel plugin etc.)

    Le technique doit répondre à la question comment uniquement.

    Le comment du technique et le comment du fonctionnel sont différents. Dans le fonctionnel, on réponds à la question comment est-ce que c'est sensé marcher. Dans le technique, on réponds à la question comment est-ce que ça sera implémenté, avec autant de détails jugés nécessaires. C'est usuellement quelques workflow, quelques flowcharts, quelques diagrammes UML, et un MCD ou plusieurs MCD/MDD. Le plus important reste la rédaction qui doit être didactique et formelle.

  13. #13
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    Pour moi, l'entreprise porteuse du besoin le spécifie soit dans un cahier des charges soit dans des spécifications fonctionnelles (fonction de la taille du projet et de l'expertise interne). Elle n'a généralement pas l'expertise nécessaire d'écrire des spécs fonctionnelles détaillées et peut demander assistance à une maîtrise d'oeuvre tierce (est-ce que la maîtrise d'oeuvre peut également être le fournisseur du service ?) pour les écrire.

    Dans la majorité des petits ou moyens projets (< 3 mois), un cahier des charges suffit.

    En ce qui concerne les spécifications techniques je pense qu'il faut toujours les exiger quelque soit la taille du projet. C'est une élément de documentation précieux quand on sait que les codeurs en général n'aiment pas documenter leurs travaux.

  14. #14
    Membre habitué
    Homme Profil pro
    Retraité MO
    Inscrit en
    Mai 2008
    Messages
    75
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 75
    Localisation : France, Côtes d'Armor (Bretagne)

    Informations professionnelles :
    Activité : Retraité MO
    Secteur : Finance

    Informations forums :
    Inscription : Mai 2008
    Messages : 75
    Points : 136
    Points
    136
    Par défaut
    Cas vécu :

    A la livraison au client, pour validation finale, commentaires : "mais alors, on pourrait se servir du même programme pour calculer le... et puis ..."

    Ben pourquoi pas !
    Et le café aussi ?
    Ce qu'on appellerait "le cahier des (sur)charges".

    .db.
    R.BASILE, 1971 : "Il y a mille et un procédés pour accélérer des particules. Le seul véritablement fondamental restant...le carnet de chèques."

  15. #15
    Membre averti
    Profil pro
    Développeur informatique
    Inscrit en
    Janvier 2003
    Messages
    302
    Détails du profil
    Informations personnelles :
    Localisation : Algérie

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Distribution

    Informations forums :
    Inscription : Janvier 2003
    Messages : 302
    Points : 316
    Points
    316
    Par défaut
    Ce n'est pas un problème s' ils sont d'accord pour payer les dévs. supplémentaire et revoir la date de livraison.

Discussions similaires

  1. Question : spécification technique = conception ?
    Par Invité dans le forum Gestion de projet
    Réponses: 1
    Dernier message: 13/04/2011, 16h54
  2. Qualité de son et technique
    Par Trancer dans le forum Multimédia
    Réponses: 0
    Dernier message: 11/02/2010, 17h52
  3. Réponses: 5
    Dernier message: 27/03/2007, 13h55
  4. [Qualité]Dossier de spécification
    Par Le Pharaon dans le forum Qualité
    Réponses: 7
    Dernier message: 07/02/2005, 18h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo