Zitat Zitat von camouflage Beitrag anzeigen
"Never shoot a running horse" - mach mal einem CEO klar er soll seine Anwendung modernisieren, ohne gleich einen sichtbaren Erfolg zu haben. Da ist doch ein Big-Bang mit einer sexy Java-Schiessmichtot-Lösung gleich viel attraktiver und für's Renommée ist auch noch was getan.

Diese Diskussionen kennt glaube ich jeder IBMi Shop, wenn es um Code-Redesign geht.
... da hat der CEO ja sogar recht.

Redesign muss in Einzelschritten vollzogen werden und sich in messbaren Vorteilen in überschaubaren Zeiträumen nachweisen lassen können (wobei äußerlich aufhübschen für mich noch kein Redesign ist, aber Luft verschaffen kann).
Ansatzpunkte sind für mich dabei Wartungskosten, Stabilität, Wartbarkeit und Änderbarkeit der Software. Altanwendungen sind nicht schlecht, weil sie mit "unmodernen" Methoden erstellt sind, das interessiert einen Anwender grundsätzlich garnicht! (Selbst Programmierern ist es egal, dass Windows grausame C Programme enthält).
Altanwendungen haben zumeist unzählige, mit heißer Nadel erstellte Änderungen, die die Qualität der Software in einem langen Prozess minimiert haben. Die Auswirkungen auf den Wartungsaufwand sind zumeist unbekannt, weil dieser nur unzureichend oder nicht erfasst wird. Voraussetzung für Redesing ist immer zuerst ein geordneter Software Erstellungsprozess mit messbaren Aufwands Metriken auf Einzelobjekt Ebene.
Erste Folge davon ist, dass Programme mit hohem Änderungsaufwand als wirtschaftlicher Totalschaden erkannt und neu geschrieben werden. Hierbei kann man dann auch bessere Methoden, Werkzeuge und erweitertes Wissen einsetzen, so man denn hat - nur so bekommt man umfassenden Vorteil.
Sieht man bei allen verbleibenden Änderungen einen festen Prozentsatz des Aufwandes für Redesign vor (Beseitigung toter Code, Verbesserung Lesbarkeit durch rename kryptischer Bezeichner, Verbesserung Modularisierung, Verbesserung Dokumentation...), geht der Aufwand zunächst um diesen Prozentsatz hoch, sinkt aber mittelfristig relativ schnell durch die verbesserte Wartbarkeit häufig geänderter Komponenten.
Freigewordene Kapazitäten werden dann in Baustellen investiert, die sich erst in längeren Zeiträumen sichtbar auswirken (hierzu gehören Restrukturierungsmaßnahmen im Bereich der Datenbank.
Wichtig ist in diesem Prozess, dass klare Zieldefinitionen vorliegen müssen, damit nicht aus Unkenntnis neue Altlasten produziert werden.

D*B