Je suis à peut prêt sûr du contraire. Je ne pense pas qu'il faille faire une réécriture from scratch, mais aller dans une direction où :
on fait évoluer le code vers des standards actuels ;
on se donne les moyens de faire plus que juste résoudre une fonction f (fiche impôt) → montant de l'impôt.
Ferrait gagner de l'argent à tout le monde (État et contribuable).
Faire un choix qui 20 ans plus tard ne paraît pas très pertinent ce n'est pas grave. Ce qui est grave c'est de ne pas éponger sa dette et éponger une dette ça ne consiste pas à la siphonner en 3 mois en refaisant un projet from scratch à 4 millions d'euros.
Utiliser les techniques actuelles de lien de suivi des exigences. Ça demande pas de changer de techno, juste de changer sa façon de fonctionner et ça permet d'utiliser ensuite toutes les techniques de qualité actuelles. Ça crée la possibilité d'avoir un découplage entre la manière dont tu t'assure que le logiciel fais ce que tu veux et la techno de ton logiciel. Bref c'est un travail préparatoire à un changement de technologie au final. C'est pas une question de prix ou de risque, juste de volonté et de gestion.
Ce code est pourri dans le sens où il est inutilisable. Je n'ai pas l'impression que ce code puisse servir à faire des simulations simples par exemple (histoire de pouvoir tester des lois).
Bref personnellement je me fou de savoir qu'ils sont parti au début sur M, lisp ou Fortran, si leur choix ne paraît pas judicieux aujourd'hui et si le coût et si élevé c'est de la faute d'un architecte et/ou de la gestion du projet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Sur M
Posté par barmic . En réponse à la dépêche L'Insee et la Drees ouvrent le code source du modèle Ines. Évalué à 3.
Je suis à peut prêt sûr du contraire. Je ne pense pas qu'il faille faire une réécriture from scratch, mais aller dans une direction où :
f (fiche impôt) → montant de l'impôt.Ferrait gagner de l'argent à tout le monde (État et contribuable).
Faire un choix qui 20 ans plus tard ne paraît pas très pertinent ce n'est pas grave. Ce qui est grave c'est de ne pas éponger sa dette et éponger une dette ça ne consiste pas à la siphonner en 3 mois en refaisant un projet from scratch à 4 millions d'euros.
Utiliser les techniques actuelles de lien de suivi des exigences. Ça demande pas de changer de techno, juste de changer sa façon de fonctionner et ça permet d'utiliser ensuite toutes les techniques de qualité actuelles. Ça crée la possibilité d'avoir un découplage entre la manière dont tu t'assure que le logiciel fais ce que tu veux et la techno de ton logiciel. Bref c'est un travail préparatoire à un changement de technologie au final. C'est pas une question de prix ou de risque, juste de volonté et de gestion.
Ce code est pourri dans le sens où il est inutilisable. Je n'ai pas l'impression que ce code puisse servir à faire des simulations simples par exemple (histoire de pouvoir tester des lois).
Bref personnellement je me fou de savoir qu'ils sont parti au début sur M, lisp ou Fortran, si leur choix ne paraît pas judicieux aujourd'hui et si le coût et si élevé c'est de la faute d'un architecte et/ou de la gestion du projet.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)