Migration du RPG en format fixe et frontière du format libre

Le RPG en format fixe et le RPG en format libre peuvent être compilés sur la même partition IBM i, utiliser les mêmes fichiers physiques et porter le même vocabulaire métier. Ce sont pourtant deux migrations différentes. Réduire cette distinction à une question de mise en forme produit une estimation bien présentée qui s'effondre dès que l'équipe rencontre des indicateurs, des spécifications d'entrée ou un programme dont le flux de contrôle se trouve en partie dans le cycle généré par le compilateur.

Une estimation crédible commence par une question: où le comportement est-il codé? Dans un programme procédural en format libre, une grande partie apparaît dans des instructions qu'un ingénieur moderne peut suivre. Dans l'ancien code en format fixe, les colonnes, l'ordre des spécifications, les indicateurs d'identification d'enregistrement, les ruptures de niveau et les conditions de sortie peuvent tous porter du sens. La migration doit retrouver ce sens avant que quiconque puisse chiffrer sérieusement la réécriture.

Les colonnes font partie du programme

En RPG au format fixe, la position horizontale appartient à la syntaxe. Un outil de migration ne peut donc pas normaliser les espaces avant d'avoir compris la source. La référence ILE RPG d'IBM précise que le type de spécification occupe la position 6 dans une source limitée par colonnes: H pour le contrôle, F pour les fichiers, D pour les définitions, I pour les entrées, C pour les calculs, O pour les sorties et P pour les procédures. D'autres champs occupent aussi des positions imposées. Un caractère décalé dans la mauvaise colonne peut modifier une opération, une condition d'indicateur ou la décision même du compilateur de lire la ligne.

Cette règle change l'ingestion. Un analyseur doit conserver la largeur d'enregistrement d'origine, les champs de séquence, les tabulations, le CCSID du membre source et les limites des membres copiés. Exporter un membre source par un chemin qui développe les tabulations ou supprime les espaces de fin peut détruire les preuves avant l'analyse. Il faut traiter l'enregistrement source brut comme un artefact et en dériver une version d'affichage, jamais l'inverse.

Un contrôle d'entrée utile consigne à la fois la ligne brute et une règle de colonnes. Par exemple, un rapport d'inventaire devrait rendre visible la sortie suivante, même si l'extraction réelle s'exécute sur IBM i:

member=ORDRPT line=184 bytes=80 spec=C cond_1=03 cond_2=N04 opcode=EXCPT
000001  C   03N04             EXCPT    ORDTOTAL
         1         2         3         4         5         6         7         8
12345678901234567890123456789012345678901234567890123456789012345678901234567890

Le format du rapport n'est pas le sujet. Il faut capturer 03, N04, EXCPT et ORDTOTAL comme des champs distincts avec leur position d'origine. Un analyseur de texte générique voit des jetons. Un analyseur conscient du RPG voit un calcul conditionné par un indicateur actif et un autre inactif, suivi d'une opération de sortie d'exception dont la définition peut se trouver beaucoup plus bas dans le membre.

Le RPG en format libre supprime l'essentiel de cette dépendance aux positions. Dans une source entièrement libre, **FREE apparaît en colonne 1 de la première ligne et les instructions suivantes peuvent dépasser l'ancienne zone limitée. Des instructions comme ctl-opt, dcl-f, dcl-s et dcl-proc annoncent leur rôle par un mot-clé et se terminent par un point-virgule. L'analyse est plus simple, mais cela ne prouve ni que le programme est procédural ni qu'il ne contient plus de constructions anciennes. La syntaxe donne la première classification, pas la dernière.

Les indicateurs forment un réseau de contrôle caché

Les indicateurs numérotés condensent état, conditions et effets de bord en deux caractères. Un calcul fixe peut tester des indicateurs dans ses colonnes de condition et définir, dans d'autres colonnes, des indicateurs de résultat supérieur, inférieur ou égal. Les spécifications d'entrée peuvent définir des indicateurs d'identification d'enregistrement, de niveau de contrôle et de champ. Les opérations sur fichiers peuvent définir des indicateurs d'erreur ou de fin de fichier. Les spécifications de sortie peuvent utiliser ces états pour décider d'émettre un enregistrement ou une ligne imprimée.

C'est pourquoi remplacer *IN03 par un booléen nommé indicator03 relève de la translittération, pas de la modernisation. Le nom conserve l'emplacement de stockage mais perd sa raison d'être. La migration doit construire un graphe de définition et d'usage: chaque endroit qui peut définir l'indicateur, chaque opération qu'il conditionne, chaque remise à zéro et chaque frontière au-delà de laquelle il reste actif. Alors seulement l'équipe peut décider s'il signifie customerChanged, writeTotals, recordFound, validationFailed ou plusieurs choses sans rapport réutilisées à des moments différents.

La réutilisation d'un indicateur est le cas gênant que le nombre de lignes masque. Un indicateur peut avoir un sens dans les calculs détaillés, être effacé, puis prendre un tout autre sens dans une sous-routine. Une recherche globale signale deux groupes, sans pouvoir prouver leur indépendance. L'analyste doit inclure l'ordre des appels, la phase du cycle et les effets des opérations sur fichiers. Si une valeur franchit une limite EXSR ou reste active jusqu'aux calculs de total, un renommage rapide peut fusionner des états que l'original séparait dans le temps.

IBM documente *IN comme un tableau couvrant les indicateurs numérotés et avertit que des valeurs autres que zéro, un, *OFF ou *ON rendent les tests ultérieurs imprévisibles. Ce détail compte pendant la conversion, car certains programmes manipulent des tranches du tableau d'indicateurs comme des données. Une cible moderne ne devrait pas reproduire un tableau magique de 99 booléens, sauf si une frontière l'exige pour la compatibilité. Elle doit décoder les écritures dans le tableau, nommer les états voulus et fixer les comportements ambigus par des tests avant de supprimer l'ancienne représentation.

L'artefact pratique est un registre des indicateurs, pas un simple total:

| Indicateur | Défini par | Lu par | Phase du cycle | Sens possible | Confiance | | | | | | | | | 03 | type d'enregistrement sur I-spec | C-spec conditionnelle | détail | enregistrement de commande choisi | élevée | | 04 | résultat de CHAIN | condition EXCPT | détail | client absent | moyenne | | L1 | changement de champ de contrôle | calculs de total | total | rupture de compte | élevée | | LR | fin du fichier principal | totaux et arrêt | dernier cycle | finalisation | élevée |

Ce registre fournit aux relecteurs des affirmations réfutables. Il montre aussi où l'estimation demande encore une enquête. Dix indicateurs bien nommés et dédiés à un seul usage peuvent coûter moins cher que trois indicateurs dont le sens change selon la phase du cycle.

Le cycle RPG contrôle un flux invisible

Un programme piloté par le cycle délègue l'enchaînement à une logique générée par le compilateur. Lire les spécifications de calcul de haut en bas ne révèle donc pas l'ordre d'exécution. La documentation d'IBM sur la programmation cyclique décrit une séquence répétée: lire un enregistrement, définir les indicateurs d'enregistrement et de niveau de contrôle, exécuter le travail de total lors d'une rupture, produire la sortie de total, tester la condition de dernier enregistrement, déplacer les champs d'entrée, puis exécuter les calculs détaillés. Le premier et le dernier passages ont un comportement propre.

Cet ordre surprend les ingénieurs qui attendent une boucle explicite. Les totaux du groupe qui vient de se terminer peuvent s'exécuter après que l'enregistrement suivant a été lu assez loin pour établir une rupture de contrôle, mais avant que ses champs d'entrée deviennent les données détaillées courantes. Des sorties d'en-tête ou de détail peuvent aussi intervenir à des moments définis par le cycle. Une réécriture qui place read() en tête d'une boucle classique et les totaux à la fin peut être raisonnable, lisible et fausse.

Les fichiers principaux et secondaires ajoutent d'autres comportements implicites. Le programme peut ne jamais exécuter la lecture qui avance le fichier principal, puisque le cycle s'en charge. La logique des enregistrements concordants, les champs de contrôle, les enregistrements d'entrée et les spécifications de sortie coopèrent par les règles du compilateur. L'indicateur LR peut être déclenché implicitement après le dernier enregistrement principal ou secondaire. IBM précise que l'activation de LR active aussi les indicateurs de niveau de contrôle pour le traitement final des totaux. C'est une sémantique d'exécution, pas un simple marqueur de fin désuet.

Une conversion sûre rend la machine à états cachée explicite avant de changer son architecture. Elle représente des phases comme l'initialisation, la sélection d'entrée, la détection de rupture de contrôle, les totaux du groupe précédent, le traitement détaillé et les totaux finaux. Elle consigne, dans chaque phase, les champs qui contiennent l'enregistrement précédent, le nouvel enregistrement sélectionné et les données en cours de traitement. La cible procédurale peut ensuite être écrite selon ce modèle.

Une trace comportementale minimale peut prendre cette forme:

seq=411 phase=read       account=170 record=invoice
seq=412 phase=break      level=L1 old_account=160 new_account=170
seq=413 phase=total      account=160 amount=9284.15 output=ACCT_TOTAL
seq=414 phase=detail     account=170 invoice=88412 amount=73.20
seq=415 phase=final      lr=on output=REPORT_TOTAL

Si l'ancien système ne peut pas produire cette trace sans risque, il faut déduire les événements attendus des entrées enregistrées et des sorties observables. L'ordre constitue le test essentiel. Des totaux finaux identiques ne suffisent pas si la cible écrit un enregistrement aval, met un solde à jour ou appelle un autre programme dans la mauvaise phase.

Le format libre ne désigne pas un modèle unique

Le RPG en format libre couvre plusieurs styles, dont certains seulement ressemblent à du code procédural ordinaire. Un membre peut contenir des calculs libres entre /FREE et /END-FREE tout en conservant des spécifications F, I ou O fixes. Un membre plus récent peut employer des déclarations libres, mais dépendre encore d'une procédure principale cyclique. Un module entièrement libre peut utiliser ctl-opt nomain, des procédures, des lectures explicites, des structures de données qualifiées et des prototypes. Appeler les trois «format libre» détruit le signal le plus utile de l'estimation.

La documentation IBM trace clairement les limites techniques. Une source entièrement libre place **FREE sur la première ligne. Les instructions fixes dont cette source a encore besoin, comme d'anciennes spécifications d'entrée ou de sortie, doivent résider dans un fichier copié. Les règles des spécifications RPG IV indiquent aussi que MAIN ou NOMAIN empêche une procédure principale cyclique, alors qu'un module dépourvu de ces mots-clés peut encore en contenir une. **FREE ne suffit donc pas à déterminer si le cycle existe.

Je classe les membres selon des axes indépendants:

• mode source: fixe, mixte limité par colonnes ou entièrement libre
• modèle d'exécution: principal cyclique, principal linéaire ou procédures MAIN/NOMAIN
• accès aux données: fichiers pilotés par cycle, E/S native explicite, SQL intégré ou mélange
• modèle d'état: indicateurs numériques, indicateurs nommés, variables explicites ou mélange
• forme externe: appels de programme et zones de données, procédures de service, files d'attente, fichiers ou commandes de job

Cette classification évite un échec classique du chiffrage. Deux membres entièrement libres peuvent être radicalement différents si l'un est une procédure mince avec du SQL explicite, tandis que l'autre récupère d'anciennes O-specs par /COPY, bascule des indicateurs numérotés et se termine par *INLR. À l'inverse, un membre au format fixe peut être mécaniquement régulier et bien couvert par des règles répétables. Le format influe sur la difficulté, mais le comportement la détermine.

Le niveau de compilation compte aussi. La syntaxe d'un membre source montre ce qu'il utilise, pas toutes les contraintes du compilateur ou de l'exécution en production. Il faut inventorier les versions cibles, les groupes d'activation, les répertoires de liaison, les fichiers décrits en externe, les copybooks, les programmes de service et les commandes de compilation. Un plan qui ignore le graphe de construction découvrira du «code manquant» qui était en réalité injecté ou résolu à la compilation.

La modernisation commence par un modèle comportemental

La cible doit exprimer l'intention métier et maintenir la compatibilité à des frontières nommées. Pour un rapport cyclique, cela signifie souvent un lecteur qui fournit des enregistrements typés, un composant qui détecte les ruptures de contrôle, un calculateur pour les détails et les totaux, et un adaptateur de sortie qui reproduit les enregistrements externes requis. Pour un programme interactif, il peut s'agir de séparer l'état d'affichage, la validation, l'accès aux fichiers et l'appel de commandes. La forme suit le comportement, pas les lettres des spécifications.

Convertir chaque C-spec en instruction et chaque indicateur en booléen, puis appeler le résultat Go ou TypeScript, n'est pas une modernisation. Cette approche plaît parce qu'elle se mesure: chaque ligne source reçoit une ligne cible, les rapports de différence automatisés paraissent actifs et les relecteurs retrouvent des étiquettes familières. Elle est mauvaise car elle conserve une structure accidentelle et rend les règles implicites d'exécution plus difficiles à reconnaître. La cible devient de l'ancienne sémantique RPG dans un langage dont les mainteneurs ne connaissent pas RPG.

Une bonne représentation intermédiaire conserve des faits que la conception finale abandonnera volontairement. Elle garde la position source, le type de spécification, l'opération, les facteurs, le résultat, les indicateurs de condition et de résultat, les références de fichier et de format d'enregistrement, les arêtes de sous-routine, les appels de procédure, l'origine du membre copié et la phase du cycle. Elle distingue aussi une arête déduite par le compilateur d'une arête écrite dans la source. Sans cette distinction, la migration ne peut pas expliquer pourquoi une branche cible existe.

La décision d'architecture dépend aussi de la frontière du système. Si les appelants dépendent de la liste de paramètres d'un programme RPG, de messages de file de données, de formats d'enregistrement décrits en externe, du contrôle des validations ou d'un état au niveau du job, il faut d'abord conserver ce contrat. Les composants internes changent derrière un adaptateur. Repenser en même temps tous les contrats voisins transforme une migration de langage en projet sans limite sur le modèle d'exploitation.

Certains comportements ne doivent pas survivre. L'aliasing d'indicateurs, les champs globaux modifiables, les ouvertures implicites et le minutage du cycle ne méritent pas une place permanente dans la cible. Il faut préserver leurs conséquences observables, prouver la parité, puis retirer l'échafaudage. Cet ordre sépare «même comportement» et «même implémentation», une distinction que les programmes de modernisation brouillent souvent.

La découverte doit examiner tout le système exécutable

Une estimation fondée sur le nombre de lignes des membres RPG exclut une grande partie du programme. Le système exécutable comprend les membres copiés, les fichiers d'écran et d'impression, les définitions de base de données, les enveloppes CL, les commandes, les descriptions de job, les répertoires de liaison, les programmes de service, les zones de données, les files de données, les fichiers de messages, les objets SQL et le processus de compilation. Un membre de 300 lignes peut se trouver au centre d'une surface comportementale bien plus vaste.

Il faut commencer par un inventaire reproductible dont chaque ligne remonte à une preuve. Il doit au moins relever l'identité de l'objet ou du membre, le type de source, les métadonnées de dernière compilation quand elles existent, les références directes, les appelants entrants, les dépendances de copie, le mode d'accès aux fichiers, le nombre d'indicateurs par rôle, l'usage du cycle, les sous-routines et procédures, le SQL intégré, les appels de programmes externes et les sources indisponibles. Les sources générées et les variantes dupliquées sont marquées plutôt que dédupliquées en silence.

La question gênante consiste à savoir si toute la source de production existe. Sur IBM i, un objet exécutable ne garantit pas la disponibilité de la source exacte ni des options de compilation. Les équipes trouvent souvent dans une bibliothèque un membre qui semble plus récent, alors que la production exécute un objet compilé depuis une autre révision. Il faut comparer les métadonnées des objets, les listes de bibliothèques, les informations de liaison et le comportement déployé. Si la provenance reste incertaine, son prix doit apparaître explicitement au lieu de supposer que le dépôt fait foi.

L'échantillonnage doit suivre le risque, pas le confort. Lire le programme de service en format libre le plus propre apprend peu sur un rapport de facturation piloté par cycle. Les échantillons doivent couvrir chaque mode source, modèle d'exécution, style d'E/S, motif d'indicateurs, type d'objet et parcours métier. Il faut inclure le membre que tout le monde évite, celui qui contient des O-specs copiées et le programme exécuté uniquement à la clôture. C'est là que l'estimation doit tenir.

Un résultat de découverte sépare les faits connus, déduits et non vérifiés. «Le programme A appelle le programme B» peut être connu grâce à un graphe d'appels résolu. «L'indicateur 42 signifie réessayer» peut être déduit des opérations et messages. «Cette branche est morte» reste non vérifié tant que des preuves de production ou un test contrôlé ne l'étayent pas. Des niveaux de confiance différents exigent des marges différentes; les réduire à un score de complexité unique masque le travail.

La parité exige des preuves proches de la production

Une compilation réussie prouve la syntaxe, et les tests unitaires prouvent certaines fonctions. Ni l'une ni les autres ne prouvent qu'un système RPG réécrit se comporte comme en production. Les tests de parité doivent comparer l'ancien et le nouveau avec des entrées qui ressemblent au travail réel, y compris l'ordre des enregistrements, les valeurs vides et nulles, les limites des décimaux condensés, les codes d'état, les ruptures de contrôle, les enregistrements absents, les clés en double, la fin de fichier et le contexte du job.

L'unité de comparaison doit correspondre au contrat. Pour un rapport, on compare le contenu spool normalisé, les limites de page et de total, ainsi que les enregistrements produits en effet de bord. Pour une mise à jour par lots, on compare les changements en base, messages, appels, limites de validation et état de reprise. Pour un flux interactif, on compare les transitions d'écran, messages de validation, touches de fonction et écritures qui en résultent. Les horodatages, identifiants générés et ordres non déterministes demandent des règles de normalisation déclarées, pas des exclusions improvisées après un écart.

Chaque rejeu doit avoir un manifeste:

{"case":"account-break-final-record","input_set":"sha256:...","old_build":"LIBA/ORDRPT:...","new_build":"git:...","normalizers":["run_timestamp"],"expected_events":417}

Le banc d'essai doit conserver l'identité de l'entrée, celle des deux versions, les sorties normalisées, les sorties brutes si la politique le permet, et le premier événement divergent. «Les fichiers diffèrent» déclenche une enquête. «À l'événement 413, l'ancien code a émis ACCT_TOTAL avant de traiter le compte 170, le nouveau après» identifie le mauvais modèle de rupture de contrôle.

Le trafic de production enregistré est particulièrement utile, car il contient des combinaisons oubliées par les concepteurs de tests. Il exige tout de même des règles: masquer ou tokeniser les champs sensibles de façon cohérente, préserver l'égalité relationnelle, capturer les attributs de job nécessaires et empêcher les rejeux d'appeler des systèmes externes réels. Si le trafic ne peut pas quitter le périmètre du client, la comparaison s'exécute sur place. CodeHero utilise ce modèle: la plateforme lit l'arborescence entière, réécrit l'architecture et vérifie le comportement avec un banc de parité sur le trafic de production enregistré.

La parité ne demande pas de conserver chaque accident pour toujours. Il faut d'abord classer chaque différence comme comportement requis, défaut toléré, bruit d'environnement ou changement approuvé. La décision devient ensuite vérifiable. «Corriger» discrètement un calcul pendant la migration peut être plus dangereux que de le conserver temporairement, car des fichiers en aval ou des procédures de rapprochement peuvent dépendre de l'ancien résultat.

Les estimations du fixe et du libre ont des unités différentes

Une migration procédurale en format libre peut souvent être estimée avec des unités explicites: procédures, instructions SQL, contrats de fichiers, appels externes, écrans et tests. Le code cyclique en format fixe exige des unités supplémentaires pour la sémantique retrouvée: groupes d'indicateurs, réseaux de spécifications d'entrée et de sortie, niveaux de contrôle, fichiers pilotés par le cycle, chemins de sortie d'exception, état des sous-routines et reconstruction de source. Ces unités mesurent l'analyse et la vérification, pas la frappe.

L'estimation doit séparer quatre postes: inventaire et provenance, récupération sémantique, implémentation cible et preuves de parité. Le code procédural en format libre peut consacrer une plus grande part du budget à l'implémentation. Le code cyclique fixe déplace généralement l'effort vers la récupération sémantique et la conception des rejeux. Appliquer un tarif unique par ligne aux deux rend le travail difficile invisible et récompense la mesure la moins informative.

La complexité augmente lorsque les interactions se multiplient. Un indicateur de rupture de niveau avec une ligne de total reste borné. Plusieurs niveaux de contrôle combinés à des enregistrements concordants, des indicateurs partagés, une sortie d'exception et des spécifications copiées produisent des combinaisons d'états. Il ne faut pas ajouter un forfait par fonction en prétendant que les effets sont indépendants. Il faut chiffrer les parcours comportementaux combinés à comprendre et à tester.

Utilisez des fourchettes tant que la découverte n'a pas fermé certaines inconnues. Une estimation utile associe une base et une condition de sortie à chaque fourchette: «sémantique du cycle, confiance moyenne, fourchette resserrée après deux traces représentatives» est défendable. «Conversion RPG, 500 lignes par jour» ne l'est pas. La fourchette diminue quand l'équipe résout la provenance des sources, produit le registre d'indicateurs, valide le graphe d'appels et rejoue des cas représentatifs.

L'estimation doit aussi préciser ses exclusions. Nettoyage des données, changement des règles métier, remplacement de l'ordonnancement amont, nouvelle conception des écrans ou fusion d'applications en double peuvent être judicieux, mais ne font pas automatiquement partie d'une réécriture de langage. Si les parties prenantes les veulent, ces travaux reçoivent leurs propres décisions, preuves et prix. Sinon, chaque changement souhaitable sera imputé à la «difficulté du RPG», sans que personne apprenne le coût réel de la migration.

Soumettez les deux styles à la même feuille d'estimation et la différence devient concrète. Pour un service procédural en format libre, l'analyste peut généralement identifier une procédure d'entrée, suivre les lectures explicites ou le SQL, dresser la liste des appels, cartographier les valeurs retournées et compter les contrats qui demandent un adaptateur. Des inconnues subsistent, notamment autour de l'état du job et des objets externes, mais chacune se rattache à une opération ou une frontière visible. L'estimation passe rapidement de l'inventaire à la conception cible, car le programme indique quand le travail se produit.

Pour un rapport cyclique en format fixe, la première feuille commence plus tôt. L'analyste doit déterminer quel fichier le cycle contrôle, quelles spécifications d'entrée identifient les enregistrements, quels champs provoquent les ruptures de niveau, quand les totaux s'exécutent, quelles lignes O-spec ils conditionnent et ce que LR déclenche. Vient ensuite le registre des indicateurs, y compris les valeurs définies implicitement par les opérations sur fichiers. Alors seulement la cible peut exposer la même séquence avec un lecteur, une logique de regroupement, des calculs et des adaptateurs de sortie. Compter les deux comme un «membre RPG» efface une couche entière de livrables.

Les critères d'acceptation diffèrent de la même manière. Le service procédural peut être couvert par des cas de requête et réponse, des effets en base et des chemins d'erreur explicites. Le rapport cyclique exige des cas ordonnés autour du premier enregistrement, de chaque niveau de contrôle, des enregistrements qui changent plusieurs niveaux à la fois, d'une entrée vide ou absente si elle est pertinente, et du dernier enregistrement. Si la logique d'enregistrements concordants ou la sortie d'exception existe, la matrice s'étend autour de ces interactions. Ces tests ne compensent pas une mauvaise conversion. Ils prouvent que le nouveau flux explicite correspond à l'ancien flux implicite.

Les compétences de revue appartiennent aussi à l'estimation. Un ingénieur Go peut juger la structure cible sans remarquer qu'un calcul de total lit des champs d'une autre phase du cycle. Un praticien RPG peut retrouver ce comportement tout en acceptant une architecture littérale parce qu'elle lui semble familière. Associez les deux revues jusqu'à ce que les traces de parité et la représentation intermédiaire rendent le raisonnement visible. Le passage de relais doit reposer sur les preuves: un relecteur doit pouvoir relier une branche cible à une règle RPG, une condition source ou une nouvelle conception approuvée.

Estimez la reprise séparément de l'implémentation prévue. Une règle de conversion connue qui s'applique à des centaines de calculs réguliers relève de l'implémentation. Un indicateur non résolu qui contrôle cinq formats de sortie constitue un risque de découverte, et le deviner produit de la reprise plutôt que du progrès. Pour chaque risque, consignez le responsable, la preuve nécessaire et l'échéance de décision. La marge devient explicable et l'incertitude de quelques membres fixes ne gonfle pas le prix du code procédural propre.

Les nombres obtenus peuvent toujours être regroupés dans une proposition commerciale, mais celle-ci doit conserver les classes internes. La livraison peut alors avancer les composants procéduraux peu incertains pendant que le travail sémantique ferme les chemins cycliques risqués, sans prétendre que le débit sera uniforme. Si une dépendance commune bloque les deux classes, montrez-la une fois au niveau du portefeuille. Si seule la récupération du cycle en dépend, gardez son coût dans cette classe. Un prix de projet reste ainsi honnête sans imposer une même estimation à deux types de travail.

Cette séparation clarifie aussi le contrôle des changements: lorsqu'une nouvelle règle du cycle modifie l'estimation, les parties prenantes voient quelle classe change et pourquoi la prévision procédurale reste stable.

Un chiffre mélangé produit un mauvais plan

La même estimation ne peut pas couvrir du code cyclique en format fixe et du RPG procédural en format libre, car le travail ne commence pas avec le même degré de certitude. Dans le cas procédural, l'équipe voit souvent le flux de contrôle et consacre son temps à reconstruire proprement les contrats. Dans le cas du cycle fixe, elle doit d'abord reconstituer le contrôle à partir des colonnes, spécifications, indicateurs, règles du compilateur et preuves d'exécution. Les deux se migrent, mais ils n'entrent pas dans l'atelier par la même porte.

Cela ne justifie pas une archéologie sans fin. La découverte doit être limitée dans le temps autour de catégories de risques représentatives et produire des livrables concrets: recensement des modes source, classification des modèles d'exécution, graphe de construction résolu, registres d'indicateurs pour les membres risqués, traces de cycle, inventaire des contrats et cas de parité. Si une tâche de découverte ne peut pas dire quelle incertitude de l'estimation elle réduit, il faut la supprimer.

Pour un portefeuille, établissez des fourchettes séparées au minimum pour le code fixe ou mixte piloté par cycle, le code fixe ou mixte procédural, et le code procédural entièrement libre. Ajustez ensuite pour les sources manquantes, le nombre d'objets externes, la sensibilité des contrats de données et les preuves de test. Gardez la classification visible dans le plan de livraison, car elle détermine aussi les compétences de relecture et l'ordre de déplacement des composants.

CodeHero s'engage à achever chaque réécriture en moins de 30 jours, y compris pour les systèmes de plus d'un million de lignes. Notre prise en charge doit donc établir ces distinctions immédiatement au lieu de les cacher dans un tarif mélangé. Que vous nous choisissiez ou non, demandez à tout prestataire de migration de montrer comment son estimation traite les phases du cycle, la réutilisation des indicateurs, les spécifications copiées, la provenance de production et la parité aux ruptures de contrôle. Si la réponse revient au nombre de lignes, l'estimation n'a pas décrit le travail.