(Courriels de diversion: <grimpettes@experimentations-eclatante.com> <refermez@insoupconnable-obeiriez.com> <louche@banaliserez-transpercer.com> <intriguiez@recupererent-gagneras.com> <clayonner@non-conformistes-messies.com> <fongibilite@battaient-calligraphies.com> <emouvante@luxera-allouerais.com> <allumerai@octroyee-catapulterons.com> <azyme@speculerez-stabilises.com> <sauvagine@merises-demandera.com> )
Sébastien Dinot a écrit : > Bonsoir, > > Mais même lorsque ces règles sont fixées et soit-disant respectées, > aucune entité de contrôle ne vérifie l'application stricte et > effective de ces règles, ni même leur pertinence ou leur complétude. > Il est toujours envisageable d'avoir un organisme, une entité qui controle le processus de developemnt d'une application même libre. Le problème étant de lui donner du grain à moudre. Il faut pour cela un outil permettant de gérer ce processus de développement (je ne parle pas de gestion de conf). > > | L'idéal serait d'avoir un process raisonnablement lisible et > | vérifiable pour produire le code, même en logiciel libre. > > « vérifiable », ce mot résume bien l'ampleur du problème. > le "raisonablement lisible" est aussi une gageure > > Là, je ne vous suis plus. En amont et en aval de quoi ? Que veut dire > « sacrifier la phase de codage » ? Cette expression me fait peur > tellement j'ai souffert dans ma vie professionnelle de code bâclé ! > Pour les applications critiques, les activités amonts peuvent en théorie permettre au codeur de coder "sans avoir à réfléchir", mais le raffinage des exigences doit être très poussé en phase de spécification et de conception. Mais je ne pense que l'on puisse dire que la phase de codage soit sacrifiable. La relecture du code reste une obligation et un code illisible etc.. doit être détecté et repris. > J'ai déjà croisé une belle brochette d'applications spécifiées à > outrance (mais mal à propos) et codées avec les pieds. Bonjour les > dégâts ! > > | Sans négliger la cohérence globale par une insistance sur la > | traçabilité du code final vis-à-vis des exigences initiales. > > Là encore, on a un choc des cultures. Lorsqu'on demande à une SSII de > développer un système embarqué pour l'Airbus A380, le cahier des > charges est fixé au début du projet et le sprectre fonctionnel, > minutieusement spécifié, devient quasiment inaltérable. > Seb tu as raison en partie le cahier des charges est fixé au début du projet, mais j'ai dans mon armoire plusiers versions d'un cahier des charges dont le moins qu'on puisse dire c'est qu'il n'était pas innaltérable ;-) > Dans le libre, c'est bien connu, c'est le besoin des utilisateurs qui > guide les développements. Or, ces utilisateurs sont progressivement > acquis et les besoins sont donc progressivement établis (sans compter > les ajouts jugés « funs » par les développeurs). > Ce n'est pas forcément incompatible si toutes les modifiactions, ajouts.. sont tracés. > | L'exigence d'automation permettrait d'infiltrer sans douleur les > | contraintes dans la phase de codage (si c'est la machine qui > | bosse...), puisque les rejets ultérieurs potentiels seraient > | détectés au plus tot. > > C'est ce que je disais : vive les tests unitaires de validation et de > non régression automatisés ! > Le problème dans ce cas c'est la créations des cas de tests qui doivent être exhaustifs. Cela peut demander autant de travail que pour le developpement. Vous avez déjà calculé le CRC32 d'un fichier à la main ? -- Philippe Midol-Monnet pmidolmonnet@sopragroup.com -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>