Faire des spécifications que l'on donne à un développeur... C'est avec ce beau principe que l'on arrive à faire des grosses bouses si on croit que c'est suffisant. Il y a quelques années tout le monde croyait au cycle de développement en "V". Maintenant, on apprend que ça ne fonctionne pas. Je vais m'en expliquer.
Qui fait les spécifications ? Un comptable ou un informaticien ? Selon le cas, les spécifications seront une vue que la personne aura du problème mais ne sera jamais le problème. Si c'est une personne qui utilise un logiciel de comptabilité, elle spécifiera en fonction de ce logiciel. Elle risque de demander des fonctions qu'elle croit faciles sans se rendre compte de leur difficulté de réalisation alors qu'elle n'ose pas demander d'autres fonctions qui seraient bien plus utiles et beaucoup plus faciles à réaliser. Il arrive aussi que le demandeur soit incapable d'imaginer la bonne solution.
Il m'est par exemple arrivé de modifier une base de données pour répondre à un besoin alors que l'on me demandait une imprimante !
On peut admettre qu'une boite noire ayant des entrées et des sorties puisse être entièrement spécifiée. ce n'est plus le cas lorsque des humains interviennent dans le processus.
Plus il y a intervention humaine, moins on peut affirmer que les spécifications correspondent au problème. Dans ce cas, vérifier que le logiciel est conforme aux spécifications perd parfois tout son sens.
Alors quelle solution ? L'idéal serait un comptable expert en informatique qui aurait besoin du logiciel. Ce n'est hélas pas trop la peine de croire à des chimères :-) Alors, il faut mettre ensemble un comptable qui devienne un peu informaticien et un informaticien qui devienne un peu comptable. Si chacun reste confiné dans son domaine de compétences, c'est l'échec assuré.
Il leur faut un grand sens de l'ergonomie et des cobayes pour tester les IHM.
Il est bon de faire un cahier des charges succint fixant les objectifs avec leurs priorités plutôt que de se lancer dans l'écriture de spécifications complètes.
Chaque fois que je suis allé voir travailler ceux qui utilisaient mes logiciels, j'ai appris quelque chose. Pourtant, j'avais la double compétence...
[^] # Re: gnuCash dans une situation difficile
Posté par Pierre Jarillon (site web personnel) . En réponse à la dépêche gnuCash dans une situation difficile. Évalué à 10.
Qui fait les spécifications ? Un comptable ou un informaticien ? Selon le cas, les spécifications seront une vue que la personne aura du problème mais ne sera jamais le problème. Si c'est une personne qui utilise un logiciel de comptabilité, elle spécifiera en fonction de ce logiciel. Elle risque de demander des fonctions qu'elle croit faciles sans se rendre compte de leur difficulté de réalisation alors qu'elle n'ose pas demander d'autres fonctions qui seraient bien plus utiles et beaucoup plus faciles à réaliser. Il arrive aussi que le demandeur soit incapable d'imaginer la bonne solution.
Il m'est par exemple arrivé de modifier une base de données pour répondre à un besoin alors que l'on me demandait une imprimante !
On peut admettre qu'une boite noire ayant des entrées et des sorties puisse être entièrement spécifiée. ce n'est plus le cas lorsque des humains interviennent dans le processus.
Plus il y a intervention humaine, moins on peut affirmer que les spécifications correspondent au problème. Dans ce cas, vérifier que le logiciel est conforme aux spécifications perd parfois tout son sens.
Alors quelle solution ? L'idéal serait un comptable expert en informatique qui aurait besoin du logiciel. Ce n'est hélas pas trop la peine de croire à des chimères :-) Alors, il faut mettre ensemble un comptable qui devienne un peu informaticien et un informaticien qui devienne un peu comptable. Si chacun reste confiné dans son domaine de compétences, c'est l'échec assuré.
Il leur faut un grand sens de l'ergonomie et des cobayes pour tester les IHM.
Il est bon de faire un cahier des charges succint fixant les objectifs avec leurs priorités plutôt que de se lancer dans l'écriture de spécifications complètes.
Chaque fois que je suis allé voir travailler ceux qui utilisaient mes logiciels, j'ai appris quelque chose. Pourtant, j'avais la double compétence...