Wartung oder Umstellung alter Programme
-
@Zeus: Es ging im vorherigen Thread - nicht von mir - um tausende COBOL-Programme bei schweizer Banken. Was macht man sinvoll damit, wenn die noch im Einsatz sind und wenn es dafür keine brauchbaren Dokumentionen mehr gibt? Dahinter steckt bereits investiertes oder neu erfordliches Geld.
-
berniebutt schrieb:
@Zeus: Es ging im vorherigen Thread - nicht von mir - um tausende COBOL-Programme bei schweizer Banken. Was macht man sinvoll damit, wenn die noch im Einsatz sind und wenn es dafür keine brauchbaren Dokumentionen mehr gibt? Dahinter steckt bereits investiertes oder neu erfordliches Geld.
Wo ist der Unterschied um was es geht?
Es ist eine einfache Kostenrechnung:
was kostet die Wartung und was kostet die Neuentwicklung.Die Wartung von alter Software kostet ja auch etwas, und wenn die Sprache aus der Mode gekommen ist, dann kosten die Entwickler immer mehr und mehr. Irgendwann ist der Punkt wo es billiger ist eine Neuentwicklung anzufangen...
Meistens ist eine laufende Umstellung am sinnvollen, dann explodieren die Kosten nicht. Natuerlich lohnt sich das nur wenn die Wartung anfaengt zu teuer zu werden...
Meistens wird aber nichts gemacht, denn hohe laufende Kosten sind besser fuers Budget als einmal krass das Budget zu ueberschreiten.
-
Aus meiner Erfahrung (also, muß nicht allgemeingültig sein):
Systeme, die zB 10 Jahre produktiv laufen haben sehr viele Änderungen, Anpassungen,
Korrekturen und Spezialitäten - das häuft sich einfach im Lauf der Zeit an. Irgendwann
kann dann mal der Zeitpunkt kommen wo man sich überlegt, jetzt ziehe ich das mal neu auf
(weil keine Sau mehr durchblickt, neuer BWLer als Chef oder so).Das kann bei einem 1-Mann-Projekt funktionieren, nicht aber bei einer über Jahre
gewachsenen Bankensoftware die (vermutlich) mehrere Teams entwickelt haben. Ich
wüßte gar nicht wie man so etwas testen soll. Meist mußte es irgendwie laufen, die
Manpower ist in die Entwicklung und nicht in die Doku gelaufen.Eine Umstellung auf ein komplett neues System wird dann ziemlich riskant ...
-
Es ging im vorherigen Thread 'Welche Programmiersprache ..?' um investiertes Geld in Mrd CHF. Da wollte jemand deswegen COBOL neu lernen.
-
berniebutt schrieb:
Es ging im vorherigen Thread 'Welche Programmiersprache ..?' um investiertes Geld in Mrd CHF. Da wollte jemand deswegen COBOL neu lernen.
Warum auch nicht. Auch solche "Altlasten" müssen gepflegt und am Leben
gehalten werden. Den Job, das neu zu machen, würde ich nur gegen Vorkasse
übernehmen
(ich bezweifele, daß das funktionieren würde).
-
Scheppertreiber schrieb:
Warum auch nicht. Auch solche "Altlasten" müssen gepflegt und am Leben gehalten werden. ....
Schön, hoffentlich kann der aus der Schweiz mit dieser Aussage etwas anfangen.
Aber wie gesagt, 'Altlasten' sind auch nicht mein primäres Anliegen. Ich wollte nur ein falsch plaziertes Thema neu aufstellen. Auch ich möchte das nur ungern machen. Aber wenn es um Geld geht, vielleicht um viel Geld?
-
Da geht es mit Sicherheit um viel Geld (hehe, ist ja 'ne Schweizer Bank).
Stelle Dir alleine mal den Aufwand vor, ein Pflichtenheft zu erstellen.
Da können die Interviewer flächendeckend ausschwärmen.
-
Shade Of Mine schrieb:
Es ist eine einfache Kostenrechnung:
was kostet die Wartung und was kostet die Neuentwicklung.Die Rechnung ansich ist natürlich einfach, aber wie kommst du zu den einzelnen Kosten? Die Wartungskosten kannst du noch recht gut schätzen, aber die Kosten für die Neuentwicklung? Bei einem u.U. kaum dokumentierten Projekt? Wo die ganzen ursprünglichen Entwickler nicht mehr verfügbar sind? Da wird alleine schon die grundlegende Spezifikation zu einem Tanz...
-
Scheppertreiber schrieb:
Da geht es mit Sicherheit um viel Geld (hehe, ist ja 'ne Schweizer Bank).
Stelle Dir alleine mal den Aufwand vor, ein Pflichtenheft zu erstellen.
Da können die Interviewer flächendeckend ausschwärmen.Kann ich mir alles gut vorstellen und deswegen finde ich die Aufgabe als solche interessant! Hast du was gegen Schweizer Banken? Sollen die doch sehen, wie sie das lösen wollen. Ich habe dieses Thema nur neu anstossen wollen. Es war ja schon gefraqt - mehr nicht!
-
Tim schrieb:
Shade Of Mine schrieb:
Es ist eine einfache Kostenrechnung:
was kostet die Wartung und was kostet die Neuentwicklung.Die Rechnung ansich ist natürlich einfach, aber wie kommst du zu den einzelnen Kosten? Die Wartungskosten kannst du noch recht gut schätzen, aber die Kosten für die Neuentwicklung? Bei einem u.U. kaum dokumentierten Projekt? Wo die ganzen ursprünglichen Entwickler nicht mehr verfügbar sind? Da wird alleine schon die grundlegende Spezifikation zu einem Tanz...
Das Problem scheitert doch sowieso am Budget. Denn wer ueberzieht sein Budget schon nur um die laufenden Kosten zu reduzieren? Niemand und daran scheitert es halt...
Geld ist eh erst dann wenn das System steht
-
berniebutt schrieb:
Es ging im vorherigen Thread 'Welche Programmiersprache ..?' um investiertes Geld in Mrd CHF. Da wollte jemand deswegen COBOL neu lernen.
Nur eine kleine Korrektur: Da wollte jemand unteranderem deswegen COBOL (nicht ganz neu, Grundlagen sind schon bekannt) lernen.
Tim schrieb:
Shade Of Mine schrieb:
Es ist eine einfache Kostenrechnung:
was kostet die Wartung und was kostet die Neuentwicklung.Die Rechnung ansich ist natürlich einfach, aber wie kommst du zu den einzelnen Kosten? Die Wartungskosten kannst du noch recht gut schätzen, aber die Kosten für die Neuentwicklung? Bei einem u.U. kaum dokumentierten Projekt? Wo die ganzen ursprünglichen Entwickler nicht mehr verfügbar sind? Da wird alleine schon die grundlegende Spezifikation zu einem Tanz...
Wäre es aber nicht langsam an der Zeit sowas zu tun? Auch wenn man die Software nicht vor hat umzustellen, könnte ich mir vorstellen, dass es extrem angenehm wäre, wenn man es endlich mal sinnvoll dokumentieren würde. Würde meiner Meinung nach auch das Risiko minimieren, dass etwas mal schief läuft. Wenn dann einmal die Dokumentation vorhanden ist, kann man dann allenfalls weiterführende Gedanken anstellen.
Shade Of Mine schrieb:
Das Problem scheitert doch sowieso am Budget. Denn wer ueberzieht sein Budget schon nur um die laufenden Kosten zu reduzieren? Niemand und daran scheitert es halt...
Wahr, mir nur immer wieder ein absolutes Rätsel. Es wird oft sogar mehr Geld ausgegeben, nur damit man das Budget schöner aussehen lassen kann. Man die Kosten anderswo verbuchen kann, dass sie dadurch aber im Endeffekt höher sind, stört irgendwie niemand. Wirtschaft ist die Kunst, ein paar Blätter Papier schön aussehen zu lassen
Grüssli
-
Dravere schrieb:
Wäre es aber nicht langsam an der Zeit sowas zu tun? Auch wenn man die Software nicht vor hat umzustellen, könnte ich mir vorstellen, dass es extrem angenehm wäre, wenn man es endlich mal sinnvoll dokumentieren würde. Würde meiner Meinung nach auch das Risiko minimieren, dass etwas mal schief läuft. Wenn dann einmal die Dokumentation vorhanden ist, kann man dann allenfalls weiterführende Gedanken anstellen.
Wahr, mir nur immer wieder ein absolutes Rätsel. Es wird oft sogar mehr Geld ausgegeben, nur damit man das Budget schöner aussehen lassen kann. Man die Kosten anderswo verbuchen kann, dass sie dadurch aber im Endeffekt höher sind, stört irgendwie niemand. Wirtschaft ist die Kunst, ein paar Blätter Papier schön aussehen zu lassen
Grüssli
Draverse: Wäre = Konjunktiv (Möglichkeitsform). Natürlich ist es an der Zeit ... , so etwas anzugehen. Allein deshalb dieser neue Thread hier! Kommen wir jetzt weiter in dieser hochbrisanten Frage? Ich möchte mich nicht allein dazu äussern wollen und freue mich auf weitere Antworten. Du sicher auch!
-
Nochmal zum Theam Banken und hauseigene Software:
In der Firma verarbeiten wir Daten größerer Kunden, darunter auch Banken
mit hauseigener Software. Mir fehlen da die Ansprechpartner, sie haben alle
die IT als "Kostenfaktor" entweder outgesourcet oder auf Helfer reduziert.
Das Know-How für eine Neuentwicklung oder Dokumentation ist schlicht nicht
mehr vorhanden. Hauptsache, der Kram läuft, halt irgendwie.Oder andere habenn ein aktuelles SAP, dort ist die Sachlage ähnlich.
Änderungen in der laufenden Software sind nicht möglich weil keine
ausreichende Doku da ist, eine Doku wird nicht erstellt weil niemandem
die Notwendigkeit klar ist und es einen Haufen Geld kosten würde. "Wenn's
nix kosten würde, kann das ja einer nebenher machen".Es kontrolliert auch keiner mehr. Beispiel: Ein Kunde, eine Bank, hat
monatelang Kontendrucke ausgedruckt und die Stapel im Keller verschafft.
Durch einen Fehler fing jede Seite mit 1011 Einsern an. Das ist erst
beim elektronischen Archivieren aufgefallen weil wir es geprüft hatten
-
Tim schrieb:
Shade Of Mine schrieb:
Es ist eine einfache Kostenrechnung:
was kostet die Wartung und was kostet die Neuentwicklung.Die Rechnung ansich ist natürlich einfach, aber wie kommst du zu den einzelnen Kosten? Die Wartungskosten kannst du noch recht gut schätzen, aber die Kosten für die Neuentwicklung? Bei einem u.U. kaum dokumentierten Projekt? Wo die ganzen ursprünglichen Entwickler nicht mehr verfügbar sind? Da wird alleine schon die grundlegende Spezifikation zu einem Tanz...
Wenn ich eine Bankensoftware neu entwickeln muss, würde mich die Dokumentation der alten Software nicht interessieren. Die ganzen alten Hacks will man sowieso nicht mehr, sondern man plant die Anforderungen die die SW erfüllen muss neu und so, dass man sie auch in der Zukunft besser erweitern kann. Das ganze wird dann wahrscheinlich sowieso mit einer moderneren Architektur gemcht, so dass mich das alte Zeug nicht interessiert. Das einzige was von der alten SW interessant ist, sind die Daten. Da wäre es nett, wenn das ordentlich dokumentiert wäre, aber eigentlich würde ich der Doku nicht vertrauen, sondern die Datenbanken und den Code dazu anschauen. Somit kannst du die Kosten genauso wie bei jeder anderen Neuentwicklung abschätzen und die sind dann, wie wohl fast immer, anfangs zu niedrig, aber die neuen Features werden groß angekündigt, dass es für die Entscheider schön aussieht.
-
Falsch.
Die Alte Software sollte man sich deswegen anschauen, damit man sieht, welche Designentscheidungen falsch waren und man nicht den gleichen Fehler noch einmal macht.
-
Affenzahn schrieb:
Falsch.
Die Alte Software sollte man sich deswegen anschauen, damit man sieht, welche Designentscheidungen falsch waren und man nicht den gleichen Fehler noch einmal macht.Wer Designt heute denn noch ein neues System wie vor 15 Jahren? Und die Designentscheidungen die die alte SW unbauchbar machen sind sowieso relativ offensichtlich, wenn schon jeder merkt, dass man eine neue braucht.
-
isklar schrieb:
Affenzahn schrieb:
Falsch.
Die Alte Software sollte man sich deswegen anschauen, damit man sieht, welche Designentscheidungen falsch waren und man nicht den gleichen Fehler noch einmal macht.Wer Designt heute denn noch ein neues System wie vor 15 Jahren? Und die Designentscheidungen die die alte SW unbauchbar machen sind sowieso relativ offensichtlich, wenn schon jeder merkt, dass man eine neue braucht.
Wenn die Entscheidung, es neu zu machen, aus Designfehlern rührt.
Wenn es notwendig wird, weil kein Mensch mehr durch den undokumentierten
und -zig mal gefrickelten Code mehr durchblickt wird es eklig.
-
mrwonderfulgewünschte schrieb:
Wenn ich eine Bankensoftware neu entwickeln muss, würde mich die Dokumentation der alten Software nicht interessieren. Die ganzen alten Hacks will man sowieso nicht mehr[...]
Und genau das sit falsch. Du bist sehr wohl an den Hacks interessiert. Dass eine Software von Grundauf neu designt und als ganzes in betrieb genommen wird, kann man bei einem so großen projekt nicht erwarten. Eher ist es so, dass man mit einer Komponente anfängt und wnen die läuft, sich nacheinander durchhangelt und die gewachsenen Strukturen nach und nach ersetzt. Und hier stößt du auf ein Problem:
Die alte Software war nie fehlerfrei. Das ist erstmal nicht so schlimm könnte man meinen, dann macht man diese Fehler eben nicht. Nur darfst du nicht vergessen, dass deine Software nicht alleine steht - in einer gewachsenen Struktur wird der Bug vielleicht vorher schon aufgefallen sein. Und da man den dank fehlender Dokumentation schon damals nicht anständig fixen konnte, wurde drum herum gehackt. Oder Code geschrieben der die Daten nachträglich korrigiert. Was passiert dann wohl, wenn der Bug auf einmal nicht mehr da ist? richtig, das ganze System funktioniert nicht mehr, bis du all die kleinen Workarounds aus allen Komponenten entfernt hast - oder bis du in deiner Software das Verhalten selbst simulierst(was du natürlich per define wieder ausschalten kannst wenn die späteren Komponenten fertig sind).Ein anderer Punkt ist, dass neben der fehlenden Code-Dokumentation wahrscheinlich auch niemand mehr weiß, was die Lastenhefte der einzelnen Komponenten waren. Bei 30 Jahre alten Programmen die einfach funktionieren gerät sowas schonmal in Vergessenheit, wenn die Zuständigen Programmierer langsam aber sicher in Rente gehen.
-
otze schrieb:
mrwonderfulgewünschte schrieb:
Wenn ich eine Bankensoftware neu entwickeln muss, würde mich die Dokumentation der alten Software nicht interessieren. Die ganzen alten Hacks will man sowieso nicht mehr[...]
Und genau das sit falsch. Du bist sehr wohl an den Hacks interessiert. Dass eine Software von Grundauf neu designt und als ganzes in betrieb genommen wird, kann man bei einem so großen projekt nicht erwarten. Eher ist es so, dass man mit einer Komponente anfängt und wnen die läuft, sich nacheinander durchhangelt und die gewachsenen Strukturen nach und nach ersetzt. Und hier stößt du auf ein Problem:
Die alte Software war nie fehlerfrei. Das ist erstmal nicht so schlimm könnte man meinen, dann macht man diese Fehler eben nicht. Nur darfst du nicht vergessen, dass deine Software nicht alleine steht - in einer gewachsenen Struktur wird der Bug vielleicht vorher schon aufgefallen sein. Und da man den dank fehlender Dokumentation schon damals nicht anständig fixen konnte, wurde drum herum gehackt. Oder Code geschrieben der die Daten nachträglich korrigiert. Was passiert dann wohl, wenn der Bug auf einmal nicht mehr da ist? richtig, das ganze System funktioniert nicht mehr, bis du all die kleinen Workarounds aus allen Komponenten entfernt hast - oder bis du in deiner Software das Verhalten selbst simulierst(was du natürlich per define wieder ausschalten kannst wenn die späteren Komponenten fertig sind).Hast du sowas schon mal gemacht?
Und sowas würde ich nicht als neu Entwicklung, sondern als größeres Refactoring bezeichnen.
-
Man muss sich den Kostenunterschied für den besonderen Fall einfach mal sorgfältig ausrechnen, da kann man von außen schlecht was spezielles zu sagen.
Allgemein betrachtet ist im Fluss der Weiterentwicklung immer beides zusammen sinnvoll und notwendig gewesen. Also Altpflege und Neuentwicklung.
Und die Neuentwicklungen haben Emulatoren gebracht.
