Zum Inhalt springen
CodeHero

Systemanalyse

Legacy-Code-Analyse: Karte des Systems, sortierte Risiken, Plan mit Preis

Lesezugriff auf das Repository, ein paar Stunden mit den Leuten, die es noch kennen, und unsere Plattform über die gesamte Codebasis, worin auch immer sie geschrieben ist: COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#. Zurück kommen eine Modulkarte, eine gemessene Liste toten Codes, ein sortiertes Risikoregister und ein Plan in Phasen mit Preisen. Drei bis fünf Tage, und das Dokument gehört Ihnen, ob Sie danach etwas neu schreiben oder nicht.

Angebot anfordernFünf Felder, keine Telefonnummer nötig. Zurück kommen Umfang, Preis und ein Termin.

3–5 Tage vom Zugang bis zum fertigen Bericht

Alles auf der rechten Seite ist ein Dokument, das Sie behalten, auch die Fassung, in der wir raten, das System in Ruhe zu lassen.

Unbekannt

Ein Quellbaum unbekannter Größe, Jobs ohne Dokumentation, keine Tests.

  • source treeunknown size
  • nobody left who wrote itrisk
  • undocumented jobscron · JCL
  • no testscoverage 0

Kartiert

Modulkarte, gemessener toter Code, sortierte Risiken, ein Plan mit Phasen und Preisen.

  • module mapgraph
  • dead code listmeasured
  • risk registerranked
  • migration planphased · costed

3–5 Tage vom Zugang bis zum fertigen Bericht

Alles auf der rechten Seite ist ein Dokument, das Sie behalten, auch die Fassung, in der wir raten, das System in Ruhe zu lassen.

Wie die Arbeit läuft

Zwei Durchgänge über dasselbe System, einer maschinell und einer von einem Menschen, danach eine Sitzung, in der die Befunde bestritten werden.
  1. 01Tag 1

    Zugang und Gespräche

    Lesezugriff auf die Repositories, Build-Anleitungen, Job-Pläne und zwei bis drei Stunden mit jedem, der es pflegt. Ein Zugang, der in der Rechtsabteilung hängt, ist der häufigste Grund, warum das rutscht.

  2. 02Tag 1–3

    Maschineller Durchgang

    Die Plattform parst alles: Aufrufgraph, Modulgrenzen, externe Schnittstellen, Datenbanknutzung, Erreichbarkeit. Die Größe ist selten das Problem. Das Modul in einem Dialekt, den niemand unterstützt, schon.

  3. 03Tag 3–4

    Menschlicher Durchgang

    Ein Entwickler arbeitet durch, was die Maschine markiert hat und was sie nicht lesen konnte, und gleicht die Befunde mit dem ab, was Ihre Leute gesagt haben. Diese beiden Darstellungen stimmen im ersten Durchgang selten überein.

  4. 04Tag 4–5

    Befunde und Plan

    Ein schriftlicher Bericht und eine Arbeitssitzung: was tot ist, was gefährlich ist, was ein Neuschreiben in Phasen kostet und womit wir anfangen würden, wenn es unser System wäre.

Was die Plattform macht, was ein Mensch macht

Die Maschine liest jede Zeile und übersieht den Zusammenhang. Die Gespräche liefern den Zusammenhang und übersehen den halben Code. Der Bericht ist das, was herauskommt, wenn beides gelaufen ist.
Der Bericht ist zuerst für Ihre Entwickler geschrieben. Wenn er nur als Vorlage für ein Gremium funktioniert, hat er versagt.
Was die Plattform macht, was ein Mensch machtWer macht wasAnmerkungen
Die Codebasis parsen und als Graph abbildenPlattformJede Sprache im Baum, auch die zwei, die Sie vergessen hatten.
Toten Code messenPlattformStatische Erreichbarkeit, dazu Produktiv-Traces oder Logs, wenn Sie uns einen Zeitraum davon geben können.
GesprächeEntwicklerWas nie aufgeschrieben wurde, existiert nur im Gespräch, und es geht mit den Leuten, die es haben.
Die Risiken sortierenGemeinsamDie Plattform findet die scharfen Kanten. Für die Sortierung muss man wissen, welches System Sie an einem Freitag Geld kostet.
Die Phasen schätzenEntwicklerAus gemessenen Modulgrößen und Kopplung, als Spannen, mit den Annahmen daneben.
Die EmpfehlungEntwicklerAuch „lassen Sie das in Ruhe und reparieren Sie Ihren Release-Prozess“, wenn die Befunde das sagen.

Wer Ihren Code liest

Entwickler mit über zehn Jahren an Legacy-Systemen und Dutzenden Migrationen hinter sich, dazu eine Plattform, die COBOL, RPG, VB6, Delphi, ColdFusion, PHP, Perl, PL/SQL, Java, C#, Fortran, ABAP und eine Handvoll Dialekte parst, die es jeweils nur in einer einzigen Firma gibt. Zusammen überrascht die beiden in einem Quellbaum sehr wenig.

Die Analyse ist abgegrenzte Arbeit zum Festpreis, und das Dokument gehört Ihnen so oder so. Kurz vor Schluss eines Neuschreibens zu erfahren, was fünf Tage Analyse gesagt hätten, ist die teure Variante davon.

Fragen, die Entwickler uns stellen

Müssen wir Sie danach beauftragen?
Nein, und der Plan ist so geschrieben, dass Ihr eigenes Team oder ein anderer Anbieter ihn ausführen kann. Phasen sind in Modulen und Schnittstellen beschrieben statt in unserem Werkzeug, und nur so können Sie Angebote überhaupt vergleichen.
Wie viel Zugang brauchen Sie wirklich?
Lesezugriff auf die Repositories und eine Anleitung, wie das Ding gebaut wird. Wenn Sie Job-Pläne und einen Zeitraum Produktiv-Logs dazulegen, ist toter Code keine Schätzung mehr, sondern eine Messung.
Was ist mit den Teilen, für die wir keinen Quelltext haben?
Die werden genau so aufgeführt: eine Binärdatei ohne Quelltext, ihre Schnittstellen und was ein Nachbau oder Ersatz kosten würde. Sie aus der Karte zu lassen ist der Weg, auf dem Migrationen kurz vor Schluss ihr Budget sprengen.
Wie lange für ein großes System?
Drei bis fünf Tage decken das meiste ab, was uns begegnet. Oberhalb von etwa zwei Millionen Zeilen, oder bei mehr als einer Handvoll Sprachen im Baum, teilen wir es und bepreisen den ersten Teil für sich.
Unterschreiben Sie eine NDA, bevor wir etwas schicken?
Ja, vor dem Zugang, als Selbstverständlichkeit. Die meiste Arbeit bei uns beginnt unter einer.

Fordern Sie die Karte Ihres Systems an

Sagen Sie uns, was das System ist, wie groß ungefähr und was die Frage gerade auslöst. Wir antworten mit dem Umfang für ein System dieser Größe, einer Dauer und einem Preis.

Angebot anfordern

Ein Entwickler antwortet, und die erste Nachricht enthält meist drei Fragen zum Zugang.