Allgemeine Herangehensweise bei Übernahme

[IH]

Hi!

Ich muss auf der Arbeit einen kompletten Bereich eines alten Cobol-Programms in Java neu schreiben.
Bedingung ist, dass der Workflow an der Oberflläche und die DB gleich bleibt. Alles andere im Hintergrund kann ich mehr oder weniger nach Belieben ändern.
Jetzt ist es so, dass die Person, die damals diesen Bereich programmiert hat, das ganze extreeeeeem kompliziert aufgebaut hat. Ich weiß nicht so richtig wie ich das jetzt machen soll.
Das Problem ist auch, dass es zu der ganzen Sache kaum ne vernünftige Doku gibt, bzw. die Sachen so kompliziert sind, dass man die in Textform garnicht versteht, sondern erst, wenn man sie sich in Bildform aufgemalt hat.
Ich habe aber echt keine Lust jeden einzelnen Sachverhalt einmal in Bildform nachzustellen weil es total viele sind.
Und jetzt hab ich echt keine Ahnung womit ich anfangen soll =(((.
Soll ich einfach alles übernehmen wie das war und versuchen es nachzubauen? Oder soll ich mir die Mühe machen was neues zu entwerfen?

 

[hdi]

Was sollen wir jetzt dazu sagen? Du musst selbst wissen wie du das angehen willst.

Das Problem ist auch, dass es zu der ganzen Sache kaum ne vernünftige Doku gibt, bzw. die Sachen so kompliziert sind, dass man die in Textform garnicht versteht, sondern erst, wenn man sie sich in Bildform aufgemalt hat.
Ich habe aber echt keine Lust jeden einzelnen Sachverhalt einmal in Bildform nachzustellen weil es total viele sind.

Das ist schlecht Ich meine natürlich solltest du das ganze erstmal verstehen. Aber helfen können wir dabei nicht, du hast ja nix konkretes gegeben.

Soll ich einfach alles übernehmen wie das war und versuchen es nachzubauen? Oder soll ich mir die Mühe machen was neues zu entwerfen?

Erstmal verstehen! Ob du es Blockweise portierst oder gleich ganz neu aufziehst wirst du entscheiden können, wenn du verstanden hast wie die Software intern funktioniert. Aber wenn du schon daran scheiterst sie zu verstehen dann hast du dir die Antwort ja selbst gegeben.

 

[bygones]

wegschmeissen und neu machen. Das andere hat zu grosses Frustpotential, man bleibt im engen Gedankenkreis des bestehenden und denkt nicht ueber den Tellerrand hinaus. Man programmiert nur nach, was man denkt verstanden zu haben etc etct.

also weg und neu

 

[schmitzi9000]

Klingt ziemlich hardcore. Mit "nach außen hin soll alles gleich bleiben wie davor" macht es sich dein Arbeitgeber zu leicht, was du brauchst ist eine vollständige Anforderungsliste mit allen Features, die das Programm unterstützen soll. Gerade bei Legacy Code sind oft viele Programmteile dabei, die gar nicht mehr benötigt werden oder zu Debuggingzwecken eingebaut und vergessen wurden. Da du ohnehin keine alten Codeteile übernehmen kannst, wäre es am geschicktesten es komplett neu zu schreiben.
Bestehe aber darauf, dass eine Anforderungsanalyse gemacht wird, idealerweise unter Beteiligung von jemand, der das Programm später nutzen wird und sich auch mit den Details auskennt. Ja, das bedeutet einen gewissen Aufwand - anders kannst du die Software aber kaum professionell portieren.

 

[nillehammer]

Bei Integration von Fremdcode (egal ob java oder ganz anders) definier ich mir immer Interfaces, die mir die Methoden zur Verfügung stellen, die ich mir wünschen würde. Davon mache ich zunächst Dummy-Implementierungen und programmiere meinen Kram damit. Dann stelle ich diese dann mit zunehmendem Wissen über den Fremdcode auf echte Implementierungen um. Ich glaube, das ist sogar ein Pattern und heißt Facade. Vielleicht hilf diese Vorgehensweise Dir ja, Teil für Teil aus dem Altcode zu ersetzen.

 

[fastjack]

Ich würde das wie bygones halten, aber nicht wegschmeissen Willst Du etwas verbrennen, verbrenne es mit Benzin

Also neu machen, Workflow genau aufmalen oder aufschreiben, Funktionsweise uns so, und wenn es länger dauert? Na und, dann hätte der Vorgänger wohl etwas mehr dokumentieren sollen! Danach TDD machen, also für die jeweiligen Komponenten Tests schreiben, wie sie funktionieren sollen und dann umsetzen.

Wenn es geht, würde ich auf jeden Fall für die alte Sache erstmal Akzeptanztests ansetzen, die so viel wie möglich an Funktionen kapseln. Diese Tests kannst Du dann mit etwas Interpretierung auf die neue Implementierung loslassen.

 

[ThreadPool]

wegschmeissen und neu machen.[...]

Was Unsinn ist da du weder weisst welche Anforderungen und spezifisches Wissen in der Software verbaut wurden noch wie groß der Teil ist. Wenn man etwas nachbaut muss sichergestellt werden das es mindestens den Funktionsumfang der alten Software hat und den bekommt man nur heraus in dem man die alte Software auseinandernimmt, alte Dokumentationen durchforstet und bestenfalls noch die "Wissensquellen" zur Hand hat die damals verwendet wurden. Und ja da ist auch oft try-error dabei wenn man etwas überhaupt nicht durchschaut.

@IH

Wenn du es richtig machen möchtest heisst das für dich in mühevoller Arbeit die ganzen Use-Cases/Szenarien und spezifisches Domänenwissen die in dem Programm verbaut sind sind zu extrahieren, vernünftig zu dokumentieren und dann den Teil in Java neuschreiben. Nur so kannst du sicherstellen das du mindestens dasselbe Verhalten abbildest was im Regelfall auch gefordert ist. Ich rede hier auch erst mal nur von den Anforderungen, die Umsetzung in ein entsprechendes Modell mit Entwicklung in Java ist ein anderes Thema.

 

[bygones]

Was Unsinn ist da du weder weisst welche Anforderungen und spezifisches Wissen in der Software verbaut wurden noch wie groß der Teil ist.

kein Unsinn. Was die Software macht und welche Szenarien abgedeckt werden bzw werden sollen wird bekannt sein. Sich dann an vorhandenen schlechten Code zu orientieren, um zu sehen wie das umgesetzt wirde ist unsinnig, da man dann 1:1 das ganze umsetzt und nicht ueber andere und sinnigere Loesungen nachdenkt.
Wegschmeissen heisst nicht blind loszulegen, aber gewiss sollte man keinen Blick in den Code werfen um "Ideen" zu bekommen.

Und ja da ist auch oft try-error dabei wenn man etwas überhaupt nicht durchschaut

und genau das ist der unsinnige punkt. Man programmiert durch try-error und frustet sich durch Unverstaendnis des bestehenden codes - hola, das wird Spass machen und ein gutes Programm resultiert daraus...

Also neu machen, Workflow genau aufmalen oder aufschreiben, Funktionsweise uns so, und wenn es länger dauert? Na und, dann hätte der Vorgänger wohl etwas mehr dokumentieren sollen! Danach TDD machen, also für die jeweiligen Komponenten Tests schreiben, wie sie funktionieren sollen und dann umsetzen.

so isses

 

[ThreadPool]

kein Unsinn. Was die Software macht und welche Szenarien abgedeckt werden bzw werden sollen wird bekannt sein. Sich dann an vorhandenen schlechten Code zu orientieren, um zu sehen wie das umgesetzt wirde ist unsinnig, da man dann 1:1 das ganze umsetzt und nicht ueber andere und sinnigere Loesungen nachdenkt.
Wegschmeissen heisst nicht blind loszulegen, aber gewiss sollte man keinen Blick in den Code werfen um "Ideen" zu bekommen.

und genau das ist der unsinnige punkt. Man programmiert durch try-error und frustet sich durch Unverstaendnis des bestehenden codes - hola, das wird Spass machen und ein gutes Programm resultiert daraus...


so isses

Sry das ich vll. etwas rüde rüberkam, das war so nicht gewollt. Leider ist es oft eben nicht so das bekannt ist welche Szenarien abgedeckt werden es ist eben so das nur die Spitze des Eisbergs wahrgenommen wird, z.B. die Interaktion durch den Nutzer mit der GUI oder anderen Systemen und die ganzen internen Szenarien was getan wird, wie es getan wird schlecht oder gar nicht dokumentiert sind.
Ich wollte nur ausdrücken das man nicht einfach sagen kann, hey wir werfen das jetzt weg sondern das man das ganze Wissen irgendwie extrahieren muss damit man später auch prüfen kann das die "Neuentwicklung" korrekt und valide ist im Sinne das man mindestens den Funktionsumfang bereitstellt den der alte Teil hatte.

Und diese Wissensbeschaffung kann unglaublich aufwendig und somit teuer werden, es kommt dabei natürlich auch auf die Wichtigkeit der Software an. Und je nach Kosten gibts da manchmal nicht viel, dann kann es sein das vll. noch ein Entwickler der das System und Sprache kennt eine Schnittstelle nach aussen bastelt, damit später ein Layer in einer neuen Sprache drübergezogen werden kann, der dann zwischen neu und alt übersetzt. Oder wenn es unglaublich s*****e kommt und man vll. auch keine saubere Codebasis mehr hat, weil das seit 10 Jahren unverändert läuft und vll. hier und da was im Nirvana verschwunden ist man das Wissen per Reverse Engineering aus den Binärdateien kratzen muss, was wohl die teuerste aller Varianten ist.

Des Weiteren sprach ich nicht davon sich am "schlechteren Code" zu orientieren, da ich erstens nicht weiß ob der Code wirklich schlecht ist oder der Bearbeiter es wg. mangelnder Erfahrung nicht versteht und zweitens (hier) COBOL gänzlich anders aussieht und mit Java nicht zu vergleichen ist.

 

[schalentier]

Die Frage is viel zu schwammig, als das man eine sinnvolle Antwort geben koennte. Allerdings, die zentrale Frage die ich stellen wuerde (dem oder den Verantwortlichen): Warum?

Funktioniert die aktuelle Implementation nicht? Ist die langsam? Versteht sie keiner mehr? Wird sie produktiv eingesetzt? Oder "nur" Firmenintern?

Einfach aus Spass an der Freude oder purer Langeweile oder weils einfach fetzt, stellt man keine Legacy Anwendung mal eben von COBOL auf Java um.

Was wir mal in einer aehnlichen Situation gemacht haben: Das war eine Oracle Forms Anwendung, d.h. die komplette Businesslogik war in PL/SQL geschrieben, die Oberflaeche mit Oracle Forms. Neu geschrieben haben wir (nach laenglicher Analyse des bestehenden Codes) nur die Oberflaeche (mit GWT). Den eigentlich Kern haben wir nahezu unveraendert gelassen. Natuerlich ist das alle andere als eine Idealloesung, aber immerhin laeuft das Ding inzwischen (ueber den Sinn koennte man jetzt diskutieren).

Auch sollte man den extremen Aufwand einer Neuentwicklung niemals unterschaetzen. Man kann die Anforderungen, Usecases oder Pflichtenheft einer Anwendung (voellig egal womit und in welcher Qualitaet entwickelt), die mehrere Jahrzehnte alt ist, nicht mal eben aufschreiben. Das ist im allgemeinen viel zu aufwendig, weil da viel (Business-) Wissen drin steckt. Oder ein nicht dokumentiertes Feature, was sich mal ein einzelner Mensch gewuenscht hat. Oder mal mehrere Tausend krude Codezeilen, die niemand versteht (verstehen kann), die aber funktionieren. Vielleicht auch nur durch Zufall, weil sich zwei Bugs da drin gegenseitig aufheben.

 

[Gregorrr]

Hast du eigentlich eine COBOL Vergangenheit, oder wieso sollst ausgerechnet du den COBOL-Code ändern?

Du kommst gar nicht rum, etwas neues zu entwerfen, da Java OO ist und COBOL prozedural... Es macht gar keinen Sinn, den Spaghetti-Code, der womöglich entstanden ist genauso in Java abzubilden - sonst schaffst du erneut Legacy Code.

>>>
1. COBOLUnit benutzen, um den benötigten Code in eine Test-Umgebung zu packen. Dabei versuchen die Struktur so gut es möglich ist zu verstehen und alle Möglichkeiten zu testen, die entstehen können.

2. Nachdem du das Wesentliche verstanden hast, ein Objekt-Modell erstellen.

3. Und genau die Tests von oben als Tests in Java abbilden.
>>>

Natürlich ist das nur eine high-level Sicht, die Probleme stecken natürlich im Detail. Und sind total abhängig WAS das eigentlich ist, was du da ändern musst.

 

[IH]

Danke erstmal an alle für eure Tips =) wäre ich registriert hättet ihr jetz auch ein "Danke" bekommen..

@schmitz9000

Bestehe aber darauf, dass eine Anforderungsanalyse gemacht wird,

würde ich ja gerne aber das ist ausgeschlossen...es gibt lediglich eine textmäßige beschreibung des Cobolprogrammierers aber die ist so viele Seiten lang und geht so ins technische Cobol-Detail dass es keinen Sinn macht die komplett zu lesen. Ich habs schon gemacht, versteh aber nichmal die Hälfte da es auch extrem kompliziert formuliert ist und wie gesagt es keine Übersichten gibt

@fastjack @Threadpool

Also neu machen, Workflow genau aufmalen oder aufschreiben, Funktionsweise uns so, und wenn es länger dauert? Na und, dann hätte der Vorgänger wohl etwas mehr dokumentieren sollen! Danach TDD machen, also für die jeweiligen Komponenten Tests schreiben, wie sie funktionieren sollen und dann umsetzen.

Wenn du es richtig machen möchtest heisst das für dich in mühevoller Arbeit die ganzen Use-Cases/Szenarien und spezifisches Domänenwissen die in dem Programm verbaut sind sind zu extrahieren, vernünftig zu dokumentieren und dann den Teil in Java neuschreiben. Nur so kannst du sicherstellen das du mindestens dasselbe Verhalten abbildest was im Regelfall auch gefordert ist

so versuche ich es jetzt...vielleicht ist das auch gut wenn ich ne ordentliche Doku hab..dann kann ich das Programm immer abgeben mit der Begründung dass jeder es schnell versteht weils ordentlich dokumentiert ist =)

@bygones

Wegschmeissen heisst nicht blind loszulegen, aber gewiss sollte man keinen Blick in den Code werfen um "Ideen" zu bekommen.

und genau das ist der unsinnige punkt. Man programmiert durch try-error und frustet sich durch Unverstaendnis des bestehenden codes - hola, das wird Spass machen und ein gutes Programm resultiert daraus...

stimmt ich bin jetz schon total frustriert =// ich einfach keine Lust das alles so zu übernehmen wie das in Cobol war, bin eigentlich auch eher der kreative Typ aber sobald ich mir das alte zeug angucke kann ich mich schlecht davon lösen...

@schalentier

Warum?

Funktioniert die aktuelle Implementation nicht? Ist die langsam? Versteht sie keiner mehr? Wird sie produktiv eingesetzt? Oder "nur" Firmenintern?

Einfach aus Spass an der Freude oder purer Langeweile oder weils einfach fetzt, stellt man keine Legacy Anwendung mal eben von COBOL auf Java um.

sorry da kann ich leider nicht so viel zu sagen
tatsache ist aber dass das unbedingt zwingend gemacht werden muss. es gibt kein dran vorbeikommen

 

[Spacerat]

Tja, wenn es unbedingt gemacht werden muss und das vllt. auch noch möglichst schnell, da hat nillehammer schon die korrekte Antwort gegeben. In deinem Fall würde ich aber eher von einer kompletten Konvertierung als nur von einer Integration sprechen. Für mich hat das was von reverse Engineering und das ist gleichbedeutend damit, dass man sich mit der Originalsprache und der Zielsprache auseinandersetzen muss (wie hdi schon sagte... "du musst es verstehen"). Mit "keine Lust" ist dir zumindest keinesfalls gedient und für bygones Vorschlag, alles neu zu machen, könnte dir in der Anwendung bereits vorhandenes Know-How - mit unter sogar essentielles - verloren gehen und dessen Nachbildung würde ewig dauern.
[EDIT]Wenn du statt COBOL eher Assembler oder Binärcode vorziehst, schnapp dir die Anwendung und jag sämtliche EXE und DLL-Dateien durch IDA Pro (das ist Hardcore ). Wenn eh' wenig bis gar keine Dokumentation vorhanden ist, benötigst du diese ja ohnehin nicht aber wenigstens bekommst du dadurch schon mal ein Flussdiagramm.[/EDIT]

 

[schalentier]

1. Beim Wort "Konvertierung" ist bei mir im Kopf immer die erste Assoziation: Kann man das automatisch machen?

Vielleicht waere es einen kleinen und zeitlich begrenzten Versuch wert, mal zu recherieren, ob und was fuer Tools es zum automatischen Konvertieren von COBOL nach Java gibt. Z.B.

RES - An Open Cobol To Java Translator | Free Development software downloads at SourceForge.net

Vielleicht laeuft das ja gluecklicherweise durch oder kann gewaltsam dazu gebracht werden (OpenSource) -> das Ergebnis kann dann mit der vollen Java ToolChain bearbeitet werden (UML, Restructure 101, Refactoring Support deiner IDE, ...). Wahrscheinlich wuerde ich dann das Ergebnis trotzdem wegwerfen und neu entwickeln, aber evtl. ist sowas fuer die Analyse hilfreich.

2. Ich kenn COBOL ueberhaupt nicht (ausser halt Wikipedia und so), aber haben COBOL Programme ueberhaupt ne GUI? Hat deines eine GUI? Oder is das eher: Input als Textfile/Datenbank rein, Output als Textfile raus? Dann zumindest koennte man wirklich super einfach Testfaelle bauen (Input-File -> erwarteter Output). Oder kommt am Ende ne Art Server/Client irgendwie raus? Dann brauchste ja JEE...

Vielleicht reicht es ja aber auch, ne Art API in Java bereitzustellen, und die COBOL Binaries per JNI anzubinden? Geht das ueberhaupt? Kommen da *.exe Dateien oder *.so oder so raus?

Allerdings was ich ueberhaupt nicht verstehe, wenn du keinen Bock darauf hast, wieso musst du es dann machen? Man kann doch echt orakeln, wenn jemand (womit auch immer) zu etwas gezwungen wird, worauf er keinen Bock hat, kann am Ende nur Murks rauskommen.

 

[California]

Such Dir erstmal die Anwender und lass Dir von denen erklären, was das Mopped macht.
Bleistift und Papier sind eine grosse Hilfe.
Screenshots vom alten Programm auch.
Kopiere Dir die betroffenen Daten vor und nach dem Programm und vergleiche sie.

Wichtig:
aus COBOL- RPG- Programmen und ähnlichem Schrott keine Businesslogik (wörtlich) übernehmen, sondern nur ableiten, was das Programm getan hat.
Diese Programme arbeiten viel zu oft satzorientiert, d.h. es wird immer eine Datei (=alt für Tabelle) aus der DB von Anfang bis Ende durchgelesen und pro Satz irgendwas gemacht.
Heute arbeitest Du mengenorientiert (= selektierst möglichst intelligent mit SQL vor) und im Speicher (= Du lädst die passenden und benötigten Daten in Speicherobjekte (Lists, Maps) und liest bei Bedarf).

Konverter- die den alten Sch... in Möchtegern- Java oder sonstwas übersetzen, sind kein Weg, siehe oben. Das Ergebnis ist nicht modern, sondern genauso alt wie die Vorlage, und als besondere Zugabe kann's keine Sau lesen oder gar verstehen.

Um den harten Weg- siehe oben Papier und Bleistift- kommst Du nicht herum.

2. Ich kenn COBOL ueberhaupt nicht (ausser halt Wikipedia und so), aber haben COBOL Programme ueberhaupt ne GUI? Hat deines eine GUI? Oder is das eher: Input als Textfile/Datenbank rein, Output als Textfile raus? Dann zumindest koennte man wirklich super einfach Testfaelle bauen (Input-File -> erwarteter Output). Oder kommt am Ende ne Art Server/Client irgendwie raus? Dann brauchste ja JEE...

Cobol hat kein GUI- aber sehr wohl ein UI. Heisst da Screen Section. Client/Server eigentlich nicht, nur DB Zugriffe, also reicht JPA völlig hin. Und den von Dir beschriebenen Unterschied nannte man damals Dialog <-> Batch. Gibt's ja eigentlich heute noch.

 

[knoppers]

Ich hab mir jetzt mal den ganzen Thread durch gelesen, mir würde jetzt erst mal anderen Fragen auftun.

- In was für einer Zeit sollte der COBOL Stand nach Java kommen.
- Wieviele Personen sind dafür zuständig (wahrscheinlich nur du alleine).
Bsp.: Umsetzung von ERP Application, Businessapplication wie z.B. Lexware Buchhalter (Eingesetzt in Kleinbetrieben, min LoC > 1 Mio) nach Java = 5 Mann 2 Jahre (ohne Tests). Test für Echteinsatz noch einmal 1 Jahr. Kosten denke ich mal min. 100.000 € Aufwärts (ohne Personalkosten).

- Vergleich, Kosten Nutzen Analyse.
- Warum gerade COBOL nach Java und nicht z.B. COBOL -> C# oder C++. Was macht mehr Sinn. Die meisten Firmen sagen, wir Programmieren nur in Java. Wenn man diese Fragt wieso, kommt die Antwort, Java ist das beste und dies ist keine Antwort, sondern Sinnlos (auch wenn ich Java selber bevorzuge).

- Für beide Richtungen gibt es recht gute xcompiler, bzw. Cross Compiler. Hier würde ich persönlich auch nur tendieren für eine Code Analyse, aber nicht für eine Migration von COBOL -> Java Produktiv-System.

- Werden den wirklich alle Programme überhaupt noch benötigt, oder kann man hier nicht wirklich das ein oder andere Programmmodul weglassen.

Kleiner Tipp aus eigener Erfahrung:
- 50% solcher Projekte gehen schief.
- 30% solcher Projekte funktionieren, sind aber nach der Umsetzung meistens schlechter wie vorher (Performance, etc.).
- Keiner gibt solche Zahlen wirklich zu, die meisten sind da sehr naiv.


Bitte nicht alles Schlecht reden was alt ist. RPG, COBOL sind alt (haben sich auch bewährt), laufen aber noch sehr oft. Problem ist hier nur das es fast keiner mehr kann und auch nicht mehr Ausgebildet wird, bzw. Bücher gibt. Hier hat IBM gepennt.

 

[California]

Hallo Knoppers,

ich will nicht RPG oder COBOL schlecht reden...
Es sind nur veraltete Sprachen, die sich immer wieder mit künstlicher Beatmung aus dem Grab erheben.
C ist auch alt, aber gut. Alle "modernen" Sprachen gehen letztendlich auf ALGOL zurück, und das ist eine der ersten höheren Sprachen überhaupt.
Zu RPG habe ich meine eigene Meinung, da ich bereits 3 Systeme aus RGP in Java übernommen habe.
Das erste mit abgeschriebener Businesslogik- war leider Vorgabe, daher mein Verdikt gegen das Abschreiben alter Businesslogik und damit auch gegen Konverter. Dieses System werde ich neu machen müssen.
Das Zweite und Dritte System habe ich so wie oben beschrieben gemacht- Bestandsaufnahme, Konferenz und enger Kontakt mit den Anwendern (=nicht mit den Schlipsträgern), Funktionalität nachgebaut, nicht kopiert, Teile ganz neu entworfen. Beide sind schneller, flexibler und - ohne angeben zu wollen- besser als die Vorgänger. Nummer eins ist zwar nicht schneller und besser als sein Vorgänger, aber genauso gut (oder schlecht).
Also kann ich Deine 80% schief oder schlecht nicht unterschreiben.
Und ich mache RPG nicht schlecht- ich will nur immer schreiend aus dem Fenster springen, wenn ich eine RPG- Quelle analysieren muss (ich sag nur Bezugszahlen...)

 

[IH]

Na toll...ihr macht einem ja Mut...
nein ich bin nicht alleine für das ganze Programm zuständig. Nur für meinen Programmteil.
Und es ist auch nicht so dass ich absolut keine Lust hätte. Ich programmiere sehr gerne (in Java) und designen tu ich noch lieber. Ich hab halt nur nicht so viel Erfahrung (knappes Jahr) und wusste einfach nicht wie ich das ganze anfangen soll.
Und am liebsten würde ich halt was komplett selbst designen und dann machen aber man kann sich ja nicht alles aussuchen...

Ich würde zu gerne mit euch über den Sinn oder Unsinn dessen diskutieren aber das kann ich nicht...

achja die ehemalige Oberfläche ist mit VB gemacht =)

 

[California]

Sollst Du auch die Oberfläche neu machen oder nur das, was darunter liegt?
Auf welchem System läuft das Programm, also das COBOL, nicht das UI (anderer PC, selber PC, AS400, sonstiger Midrangehobel, Mainframe...)
Wie wird es aufgerufen?
Wenn die Oberfläche gleich bleiben soll, darf dein neues Programm nur minimale Änderungen am UI erfordern...
Wenn Du das UI mit neu machen sollst, wird es an der Stelle einfacher.

 

[Spacerat]

- Keiner gibt solche Zahlen wirklich zu, die meisten sind da sehr naiv.

Naiv ist was anderes... Keine Fa. gibt zu, dass sie das ein oder andere vllt. sogar Fremd-Programm zwecks RE analysiert. Naiv ist eine Fa. wenn sie eine eigene Entwicklung nicht ausreichend dokumentiert und diese deswegen - wie z.B. in diesem Fall - selbst analysieren darf, wenn man auf neue Technologien mehr oder weniger angewiesen ist, weil man das Gefühl hat, dass die alte schlicht vom "Aussterben" bedroht ist. Da muss man die alte Technologie auch nicht schlecht reden.
Die Fa. die nun selbst analysieren darf, ist fortan hoffentlich von ihrer Naivität geheilt und dokumentiert nun wenigstens die Analyse und deren Umsetzung.
Damit wären wir beim simplen Crosscompiling... tolle Idee... äusserst kostengünstig... aber löst sie in Zukunft auch das Problem mit der Dokumentation? Eher nicht. Stattdessen geht man davon aus bzw. ist so naiv, zu glauben, dass es, wenn es einmal klappt, auch in Zukunft immer klappt. Crosscompiling ist also in Wirklichkeit ebenso naiv, als wenn man seine Entwicklungen nicht dokumentiert.
Wenn ich wissen will, wie eine Software funktioniert, greife ich selbst deswegen immer zu oben besagtem IDA Pro - hat mich noch nie enttäuscht. Diese Software scheint ausschlieslich für RE-Zwecke entwickelt worden zu sein und wurde dabei hoffentlich auch dokumentiert. Könnt's euch ja mal anschauen.
[EDIT]Im übrigen muss man sich bei IDA nicht mehr unbedingt mit der eigentlichen Sprache befassen, in welcher die zu analysierende Anwendung einst geschrieben wurde. Assemblerkenntnisse reichen in den meisten Fällen aus.[/EDIT]