Non, les temps sont longs surtout quand il n'y a pas de budget (car pas de rentrée d'argent liée au développement). Les grosses entreprises prennent un temps fou pour bouger et cela ne prend pas en compte le fait qu'ils font très souvent appel à de la sous-traitance pour développer certains équipements.
S'ils étaient rigoureux, il faudrait modifier la documentation d'entrée (spécifications), la documentation du code et le code, écrire des tests, dérouler les tests. Si les tests sont partiels, il faut prouver que seuls les tests rejoués sont nécessaires. Les tests unitaires sont rapides et ne sont pas en cause ici, c'est les tests fonctionnels qui prennent du temps. Il faut tester fonctionnellement l'équipement seul, puis l'équipement dans une environnement simulé puis l'équipement dans un environnement réel. Tout cela en gardant à l'esprit que :
Sur les 261 logiciels embarqués dans les trains MI09, 223 ont été analysés. Parmi eux, 38 sont confirmés comme porteurs du bug. Mais aucun n’est catégorisé comme « non impacté » avec la mention « approuvé » ou « preuve fournie », souligne le jugement. Une analyse exhaustive reste donc nécessaire.
Et là, on parle d'un type de train. Il faudrait donc faire tous les trains de la flotte dans le temps imparti sachant que :
Le tribunal a donné cinq ans à Alstom pour résoudre le problème, avec un calendrier précis assorti d’astreintes financières.
Pour donner un ordre d'idée de l'échelle de temps, j'ai pu travailler avec le systémier dont il est question dans l'article. Il y avait deux lignes à modifier dans une spécification d'interface (documentation), le contenu des lignes était connu. Temps de mise à jour du document : 2 mois.
Mon pronostric : il y aura des trains à l'arrêt le 19 janvier 2038.
Ah, et je n'ai pas parlé du temps de mise à jour de la flotte avec, pendant un certain temps, des trains en configuration hybride (tous les logiciels ne sont pas à jour). Cela implique beaucoup de choses supplémentaires (tests de compabilité, validations, autorisations...).
[^] # Re: Difficulté de la mise à jour
Posté par nico4nicolas . En réponse au lien Des lignes de métro, tramway et RER de la RATP concernées par le bogue de 2038. Évalué à 3.
Non, les temps sont longs surtout quand il n'y a pas de budget (car pas de rentrée d'argent liée au développement). Les grosses entreprises prennent un temps fou pour bouger et cela ne prend pas en compte le fait qu'ils font très souvent appel à de la sous-traitance pour développer certains équipements.
S'ils étaient rigoureux, il faudrait modifier la documentation d'entrée (spécifications), la documentation du code et le code, écrire des tests, dérouler les tests. Si les tests sont partiels, il faut prouver que seuls les tests rejoués sont nécessaires. Les tests unitaires sont rapides et ne sont pas en cause ici, c'est les tests fonctionnels qui prennent du temps. Il faut tester fonctionnellement l'équipement seul, puis l'équipement dans une environnement simulé puis l'équipement dans un environnement réel. Tout cela en gardant à l'esprit que :
Et là, on parle d'un type de train. Il faudrait donc faire tous les trains de la flotte dans le temps imparti sachant que :
Pour donner un ordre d'idée de l'échelle de temps, j'ai pu travailler avec le systémier dont il est question dans l'article. Il y avait deux lignes à modifier dans une spécification d'interface (documentation), le contenu des lignes était connu. Temps de mise à jour du document : 2 mois.
Mon pronostric : il y aura des trains à l'arrêt le 19 janvier 2038.
Ah, et je n'ai pas parlé du temps de mise à jour de la flotte avec, pendant un certain temps, des trains en configuration hybride (tous les logiciels ne sont pas à jour). Cela implique beaucoup de choses supplémentaires (tests de compabilité, validations, autorisations...).