Discussion :

[Algo D.DN]

Oui, la qualité ça a un coût, et tout le monde n'est pas prêt à payer.

C'est comme dans toutes les industries (pas juste en informatique), il faut savoir : Quelle est la qualité recherchée ? Combien vous êtes prêts à payer pour cela ? De combien de temps on dispose ?

Si on te répond : "on veut 0 défaut, sans que ça nous coûte un centime de plus, et pour demain", il faut leur dire d'aller voir ailleurs (et par "ailleurs" je veux dire "au pays des Bisounours...").

Hi all,

Je suis de cet avis, et c'est effectivement valable quel que soit le domaine d'activité, on sait pertinemment que la qualité a un coût et si on veut grignoter sur le coût ben il faut s'attendre à une dégradation de la qualité.

Il n'y a pas de secret, un processus de qualité nécessite des ressources et du temps qui ont un coût, c'est amha, valable dans tous les processus nécessitant discernement et matière grise, dans le cas contraire on doit se contenter de composer avec approximation et médiocrité...

[Saverok]

Il n'y a pas de secret, un processus de qualité nécessite des ressources et du temps qui ont un coût, c'est amha, valable dans tous les processus nécessitant discernement et matière grise, dans le cas contraire on doit se contenter de composer avec approximation et médiocrité...

Il y a un juste milieu qui peut facilement être trouvé tout de même
Mettre en place un checkstyle ou un analyseur de code (Sonar par exemple) sont des choses très simples, qui ne coûtent pas grand chose (voir rien du tout car l'offre open source est là et que le paramétrage par défaut répond assez bien à la plupart des besoins) et qui permettent de se prémunir de pas mal de chose
L'agilité permet également de bien améliorer la qualité d'une application en recentrant les efforts sur les fonctions essentielles (par expérience, en conception, on imagine souvent des fonctionnalités qui ne correspondent pas aux besoins réels et l'agile permet de corriger le tir par les démo régulières qui mêlent la recette à la conception et au dev)


Bref, il est possible de faire quelque chose de relativement qualitatif sans exploser ni le budget ni le calendrier
C'est le plus souvent, juste une question de volonté
Par contre, produire de la merde, comme dans l'industrie avec l'obsolescence programmée, ça arrange pas mal de monde qui peut facturer de la TMA, de l'audit, des évolutions, etc, etc.

[Algo D.DN]

Il y a un juste milieu qui peut facilement être trouvé tout de même...
il est possible de faire quelque chose de relativement qualitatif sans exploser ni le budget ni le calendrier

Oui, on peut tout à fait dégager un processus (de) qualité en restant dans une sobriété budgétaire, à condition de ne pas se retrouver face à un existant (antécédents) empilée de couches ficelées telles quelles pour finir just-in-time.

C'est le plus souvent, juste une question de volonté
Par contre, produire de la merde, comme dans l'industrie avec l'obsolescence programmée, ça arrange pas mal de monde qui peut facturer de la TMA, de l'audit, des évolutions, etc, etc.

+ +

[pascalCH]

On me dit dans l'oreillette que certains domaines qui utilisent des fournisseurs informatiques, exigent un processus qualité mieux cerné. Armée, NASA, médical, les systèmes internes des banques. Ok, chouette, mais c'est pas là-dedans que je bosse.

Effectivement, j'ai peut-être la chance de travailler dans des contextes plus confortables que la majorité du marché; je confirme, armée, aviation, médical, jeux d'argent, pour ne citer qu'eux, arrivent avec des exigences très fortes mais également des méthodes et des moyens à la hauteur des enjeux, ce qui n'empêche pas cependant des clashs à la hauteur si j'osais ... je citerai les noms ...

[DonQuiche]

1- Les spécifications des clients sont fiables et claires. Elles sont déjà prévues pour s’inscrire dans un processus d’évolution cohérent de leur besoins, au fil de l’évolution et d’accompagnement sur le futur, pour le « produit ».

Tu commences par exiger que le client soit capable de prédire l'avenir, ça commence mal. Il ne le peut pas, tout comme nous ne pouvons pas éviter les erreurs de conception et de programmation ni les retours en arrière. C'est pour cela qu'on a inventé les méthodes agiles.

2- Il y a un budget temps pour le dossier d’analyse, il représente le double de celui du développement, il est rédigé par la personne qui encadrera l’équipe de dev, lesquels sont associés et « sensibilisé » régulièrement lors de réunions informatives lors de sa rédaction.

D'une part tu réclames donc que les deux tiers du budget temps soient concentrés sur une personne, ce qui va quand même beaucoup ralentir le projet, d'autre part tu penses que cette personne peut tout analyser a priori, seule et sans faire d'erreurs ? Là aussi je trouve ça dangereusement irréaliste et malsain pour les individus.

4- Le code développé regorge de commentaires, écrits dans une langue accessible.

Personnellement je déteste lire ce genre de code. J'apprécie que le code soit majoritairement auto-documenté, seulement ponctué de rares commentaires locaux pertinents et d'une courte doc en en-tête d'un fichier (brève explication de la solution et pourquoi celle-ci plutôt qu'une autre). Le tout doit en revanche être accompagné d'une doc technique séparée expliquant quels sont les problèmes que doit traiter le programme et pourquoi, avec quelques schémas "stratégiques" (de haut niveau et sans rentrer dans les détails).

[SuperBidi]

Je suis vraiment surpris de lire dans ce sujet des personnes qui travaillent dans des sociétés où on leur demande de ne pas tout couvrir en TU.

Ca dépend énormément de ce que tu as à coder.
Perso, je bosse sur des technos serveur. Pour valider un serveur, je balance plusieurs milliards de requêtes pseudos-aléatoires. Ca me paraît assez dur avec des tests unitaires.
De plus, pour la partie sécurité, les tests unitaires peuvent rien faire, vu qu'il faut déjà connaître la faille pour faire le test. Or, la difficulté, c'est bien de connaître les failles.

Donc, j'irai pas dire que les tests unitaires servent à rien, mais faut quand même voir les limitations de la technique (et j'inclus pas le fait de bien les écrire, vu qu'une erreur dans les tests unitaires peut camoufler des erreurs dans l'application).

[abel.cain]

Vous connaissez Coq ? :p

C'est un langage de programmation qui permet de vérifier des théorèmes sur des fonctions, et les fonctions en question peuvent être exportées en OCaml/Haskell.

On est sûr à 100% que les théorèmes prouvés sur ces fonctions sont vérifiés dans les codes OCaml/Haskell correspondants (autrement dit, pas de bug)

sûr à 100%, sauf s'il y a un bug.