audit du système
Audit de code legacy : la carte du système, les risques et le plan chiffré
Un accès en lecture au dépôt, quelques heures avec les gens qui le connaissent encore, et notre plateforme sur tout le code, quel qu'il soit : COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#. En retour : une carte des modules, une liste mesurée du code mort, un registre de risques classés et un plan par phases avec les prix. Trois à cinq jours, et le document est à vous que vous réécriviez ou non.
3 à 5 jours entre l'accès et le rapport fini
Tout ce qui est à droite est un document qui vous reste, y compris la version où la recommandation est de laisser le système tranquille.
Inconnu
Une arborescence de taille inconnue, des jobs que personne n'a documentés, aucun test.
- source treeunknown size
- nobody left who wrote itrisk
- undocumented jobscron · JCL
- no testscoverage 0
Cartographié
Carte des modules, code mort mesuré, risques classés, un plan avec phases et prix.
- module mapgraph
- dead code listmeasured
- risk registerranked
- migration planphased · costed
3 à 5 jours entre l'accès et le rapport fini
Comment le travail se déroule
- 01jour 1
Accès et entretiens
Accès en lecture aux dépôts, instructions de build, plannings des jobs, et deux ou trois heures avec chacune des personnes qui le maintiennent. Un accès bloqué au juridique est la première cause de retard ici.
- 02jours 1–3
Passe machine
La plateforme analyse tout : graphe d'appels, frontières de modules, interfaces externes, usage de la base, atteignabilité. La taille est rarement le problème. Le module écrit dans un dialecte que plus personne ne supporte, si.
- 03jours 3–4
Passe humaine
Un ingénieur reprend ce que la machine a signalé et ce qu'elle n'a pas su lire, puis confronte les conclusions à ce qu'ont dit vos gens. Ces deux récits coïncident rarement du premier coup.
- 04jours 4–5
Conclusions et plan
Un rapport écrit et une séance de travail : ce qui est mort, ce qui est dangereux, ce que coûte une réécriture par phases, et ce que nous ferions en premier si c'était notre système.
Ce que fait la plateforme, ce que fait un humain
| Ce que fait la plateforme, ce que fait un humain | Qui fait quoi | Notes |
|---|---|---|
| Analyser et mettre le code en graphe | Plateforme | Tous les langages de l'arborescence, y compris les deux que vous aviez oubliés. |
| Mesurer le code mort | Plateforme | Atteignabilité statique, plus les traces ou logs de production quand vous pouvez nous en donner une période. |
| Les entretiens | Ingénieur | Ce qui n'a jamais été écrit n'existe qu'en conversation, et cela part avec les gens qui le détiennent. |
| Classer les risques | Les deux | La plateforme trouve les arêtes vives. Les classer demande de savoir quel système vous coûte de l'argent un vendredi. |
| Estimer les phases | Ingénieur | À partir de tailles de modules mesurées et du couplage, en fourchettes avec les hypothèses écrites à côté. |
| La recommandation | Ingénieur | Y compris « laissez ça tranquille et réparez votre processus de livraison » quand c'est ce que dit le constat. |
Qui lit votre code
Des ingénieurs avec plus de dix ans sur des systèmes legacy et des dizaines de migrations derrière eux, plus une plateforme qui analyse COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#, Fortran, ABAP et une poignée de dialectes qui n'existent que dans une seule société. À eux deux, il ne reste plus grand-chose dans une arborescence qui les surprenne.
L'audit est un travail borné à prix fixe et le document vous reste dans tous les cas. Apprendre à la fin d'une réécriture ce qu'un audit de cinq jours vous aurait dit, c'est la version chère de la même information.
Questions que nous posent les ingénieurs
- Sommes-nous obligés de vous embaucher ensuite ?
- Non, et le plan est écrit pour que votre propre équipe ou un autre prestataire puisse l'exécuter. Les phases sont décrites en modules et en interfaces plutôt qu'en outils à nous, ce qui est aussi la seule façon de comparer des devis.
- De quel accès avez-vous vraiment besoin ?
- Un accès en lecture aux dépôts et les instructions pour compiler la chose. Si vous pouvez ajouter les plannings de jobs et une période de logs de production, le code mort cesse d'être une estimation et devient une mesure.
- Et les parties dont nous n'avons pas les sources ?
- Elles sont listées pour ce qu'elles sont : un binaire sans source, ses interfaces, et ce que coûterait de le reproduire ou de le remplacer. Les laisser hors de la carte est la façon dont les migrations explosent leur budget dans les tout derniers jours.
- Combien de temps pour un gros système ?
- Trois à cinq jours couvrent l'essentiel de ce que nous voyons. Au-delà d'environ deux millions de lignes, ou avec plus de quelques langages dans l'arborescence, nous découpons et chiffrons la première partie séparément.
- Signerez-vous un NDA avant que nous envoyions quoi que ce soit ?
- Oui, avant l'accès, systématiquement. La plupart de nos missions commencent sous NDA.
Demandez la carte de votre système
Dites-nous ce qu'est le système, à peu près sa taille, et ce qui pose la question maintenant. Nous répondons avec le périmètre pour un système de cette taille, une durée et un prix.
Un ingénieur répond, et le premier message contient en général trois questions sur les accès.