Softwarewartung und -entwicklung

Inevitable Evolution

Inevitable Evolution: Das erste Gesetz besagt, dass die Wartung des Systems ein unvermeidbarer Prozess ist. Da sich die Systemumgebung ändert und neue Anforderungen entstehen, muss das System geändert werden. Wenn das modifizierte System wieder in die Umgebung eingebracht wird, treten Veränderungen in der Umgebung auf und somit startet der Zyklus den Prozess der Evolution.

Abbau der Struktur

Abbau der Struktur: Das zweite Gesetz besagt, dass, wenn das System geändert wird, seine Struktur abgebaut wird. Der einzige Weg, dies zu vermeiden, ist die vorbeugende Instandhaltung, bei der Stunden in die Verbesserung der Struktur der Software investiert werden, ohne neue Funktionen hinzuzufügen. Offensichtlich würde dies zusätzliche Kosten verursachen, die über die Kosten für die Implementierung der Änderungen am System hinausgehen.

Lehmans drittes Gesetz: Dynamik

Dynamik: Das dritte Gesetz von Lehman schlägt vor, dass große Systeme in den frühen Phasen des Entwicklungsprozesses ihre eigene Dynamik definieren. Dies bestimmt die Trends, die das System schwer zu warten machen, und begrenzt die Anzahl der möglichen Änderungen. Lehman und Belady legen nahe, dass dieses Gesetz eine Folge der strukturellen Faktoren ist, die Einfluss auf die Änderungen am System haben und diese einschränken, sowie der organisatorischen Faktoren, die die Entwicklung des Systems beeinflussen.

Arten der Wartung

Wartung:

• Korrektiv
• Evolutionär
• Adaptiv (Personal, Vertragsfähigkeit, Laufzeit)

Wartung zur Reparatur von Softwarefehlern (Korrektive Wartung)

Die Korrektur von Codierungsfehlern ist in der Regel billig, Designfehler sind teurer, es kann notwendig sein, das bestehende System neu zu gestalten.

Wartung zur Anpassung der Software an eine andere Betriebsumgebung (Adaptive Wartung)

Diese Art der Wartung ist erforderlich, wenn sich einige Aspekte der Systemumgebung ändern, wie z. B. Hardware, Betriebssystemplattform oder andere Support-Software. Die Anwendung muss geändert werden, um mit diesen Veränderungen der Umgebung umzugehen.

Wartung, um die Funktionalität zum System hinzuzufügen oder zu modifizieren (Evolutionäre Wartung)

Diese Art der Wartung ist erforderlich, wenn sich die Systemanforderungen als Reaktion auf organisatorische oder geschäftliche Veränderungen ändern. Das Ausmaß der für die Software erforderlichen Änderungen ist viel höher als bei anderen Arten von Wartungsarbeiten.

Prognose für Änderungsanträge

Manager hassen Überraschungen, besonders wenn sie zu unerwartet hohen Kosten führen.

Prognosen beziehen sich auf:

• Wenn eine Änderung des Systems akzeptiert werden sollte, hängt dies in gewissem Maße davon ab, die Wartung der Systemkomponenten, die von dieser Änderung betroffen sind, zu erleichtern.
• Die Umsetzung des Systems ändert seine Struktur und neigt dazu, sich zu zersetzen, wodurch die einfache Wartung erschwert wird.
• Die Wartungskosten hängen von der Anzahl der Änderungen ab, und die Kosten für die Durchführung von Änderungen hängen von der Wartbarkeit der Systemkomponenten ab.

Die Vorhersage der Anzahl von Änderungsanträgen für ein System erfordert ein Verständnis der Beziehung zwischen dem System und seiner Umgebung. Zu diesem Zweck müssen bewertet werden:

• Die Anzahl und Komplexität der Systemschnittstellen. Je größer die Anzahl der Schnittstellen und je komplexer sie sind, desto wahrscheinlicher sind Änderungsanträge.
• Die Zahl der von Natur aus flüchtigen Systemanforderungen. Anforderungen, die organisatorische Maßnahmen und Verfahren widerspiegeln, sind wahrscheinlich volatiler als Anforderungen, die auf stabilen Eigenschaften des Gebiets basieren.
• Geschäftsprozesse, in denen das System eingesetzt wird. Wenn sich Geschäftsprozesse weiterentwickeln, generieren sie Änderungsanträge. Je mehr Geschäftsprozesse über das System laufen, desto mehr Änderungsanträge treten auf.

Beispiele für Prozessmetriken

Beispiele für Prozessmetriken, mit denen die Wartungsfreundlichkeit bewertet werden kann, sind:

• Zahl der Anträge für korrektive Wartung. Eine Erhöhung der Anzahl der Fehlerberichte kann darauf hindeuten, dass während des Wartungsprozesses mehr Fehler in das Programm eingeführt als behoben wurden. Sie können auf einen Rückgang der Wartbarkeit hindeuten.
• Durchschnittliche Zeit für die Analyse der Auswirkungen. Dies spiegelt die Anzahl der Komponenten wider, die von der Änderung betroffen sind. Wenn diese Zeit ansteigt, sind immer mehr Komponenten betroffen und die Wartbarkeit sinkt.
• Durchschnittliche Zeit, um einen Änderungsantrag zu implementieren. Sie ist nicht gleich der Zeit für die Analyse der Auswirkungen, obwohl es eine Korrelation gibt. Diese Zeit wird benötigt, um das System und seine Dokumentation tatsächlich zu ändern, nachdem eingeschätzt wurde, welche Komponenten betroffen sind. Eine Erhöhung der Zeit, die für die Implementierung einer Änderung benötigt wird, bedeutet einen Rückgang der Wartbarkeit.
• Anzahl der ausstehenden Änderungsanträge. Eine Erhöhung dieser Zahl im Laufe der Zeit kann einen Rückgang der Wartbarkeit anzeigen.

Dringende Änderungsanträge

Anträge auf Änderungen beziehen sich oft auf Systemprobleme, die dringend angegangen werden müssen. Diese dringenden Änderungen können aus drei Gründen entstehen:

• Es wurde ein schwerwiegender Mangel des Systems festgestellt, der repariert werden muss, um den normalen Betrieb weiterhin zu ermöglichen.
• Auswirkungen von unerwarteten Veränderungen in der Betriebssystemumgebung, die den normalen Betrieb unterbrechen, sind aufgetreten; unvorhergesehene Veränderungen in der Gesellschaft, die mit dem System verbunden sind, wie z. B. Notfälle durch neue Wettbewerber oder die Einführung neuer Gesetze.

Reengineering

Reengineering (Risiko, Kosten) => Entwicklung des Codes, Modularisierung, Datenmodell-Evolution.

Die Umsetzung des Reengineerings eines Softwaresystems hat zwei entscheidende Vorteile gegenüber den radikaleren Ansätzen der Systementwicklung.

• Risikoreduziert. Es besteht ein hohes Risiko bei der Sanierung einer geschäftskritischen Software. Fehler können in den Spezifikationen des Systems begangen werden oder es können Entwicklungsprobleme auftreten. Verzögerungen bei der Einführung der neuen Software können den Verlust von Geschäftsmöglichkeiten und Mehrkosten verursachen.
• Geringere Kosten. Die Kosten für Reengineering sind deutlich geringer als die Kosten für die Entwicklung neuer Software.

Aktivitäten im Reengineering-Prozess

Die Aktivitäten in diesem Prozess Re-Engineering sind:

• Quellcode konvertieren. Das Programm wird von einer alten Programmiersprache in eine modernere Version derselben Sprache oder in eine andere Sprache umgewandelt.
• Reverse-Engineering. Das Programm wird analysiert und die Informationen daraus extrahiert. Dies hilft, Ihre Organisation und Funktionalität zu dokumentieren.
• Verbesserte Programmstruktur. Die Steuerungsstruktur des Programms wird analysiert und modifiziert, um das Lesen und Verstehen zu erleichtern.
• Modularisierung des Programms. Die Teile des Programms werden gruppiert und gegebenenfalls werden Entlassungen entfernt. In einigen Fällen kann diese Phase Transformationen der Architektur beinhalten, bei der eine zentrale Struktur, die für einen einzelnen Computer geplant ist, modifiziert wird, um auf einer verteilten Plattform zu arbeiten.
• Reengineering-Daten. Die verarbeiteten Daten werden geändert, um Programmänderungen widerzuspiegeln.

Kostenfaktoren für Reengineering

Unabhängig von dem Umfang des Reengineerings, sind die wichtigsten Faktoren, die die Kosten beeinflussen:

• Die Qualität der Software. Je niedriger die Qualität der Software und der zugehörigen Dokumentation (sofern vorhanden), desto höher die Kosten für das Reengineering.
• Die Werkzeuge zur Unterstützung des Reengineerings. Es ist in der Regel nicht ausreichend, in Bezug auf die Kosten, ein Softwaresystem zu reengineeren, es sei denn, Sie verwenden CASE-Tools, um die meisten Änderungen zu automatisieren.
• Umfang der Datenkonvertierung. Wenn das Reengineering die Konvertierung großer Datenmengen erfordert, erhöhen sich die Prozesskosten erheblich.
• Die Verfügbarkeit von qualifiziertem Personal. Wenn die Mitarbeiter, die für die Wartung des Systems zuständig sind, nicht in den Prozess des Reengineerings einbezogen werden können, erhöhen sich die Kosten, da die Systemingenieure, die für das Reengineering zuständig sind, viel Zeit benötigen, um das System zu verstehen.

Der größte Nachteil des Software-Reengineerings ist, dass es praktische Einschränkungen hinsichtlich des Ausmaßes gibt, in dem ein System verbessert werden kann.

Legacy-Systeme

Legacy-Systeme: Ein neues System, "einfrieren", korrektive Wartung, Entwicklung, Zuverlässigkeit.

Organisationen mit einem begrenzten Budget zur Erhaltung und Aktualisierung ihrer Legacy-Systeme müssen entscheiden, wie sie die beste Rendite erzielen können. Es gibt vier Strategieoptionen:

• Das System komplett verwerfen. Diese Option sollte gewählt werden, wenn das System nicht mehr effektiv zu den Geschäftsprozessen beiträgt.
• Das System unverändert lassen und mit der regelmäßigen Wartung fortfahren. Diese Option sollte gewählt werden, wenn das System noch benötigt wird, aber sehr stabil ist und die Benutzer des Systems relativ wenige Änderungsanträge haben.
• Re-Engineering des Systems, um die Wartbarkeit zu verbessern. Diese Option sollte gewählt werden, wenn die Qualität des Systems durch regelmäßige Änderungen beeinträchtigt wurde und diese Änderungen weiterhin benötigt werden.
• Ersetzen aller oder eines Teils des Systems durch ein neues System. Diese Option sollte gewählt werden, wenn andere Faktoren, wie z. B. neue Hardware, es unmöglich machen, dass das alte System weiter betrieben werden kann, oder wenn kommerzielle Systeme es ermöglichen, ein neues System zu einem vernünftigen Preis zu entwickeln.

Bewertung von Legacy-Systemen

Aggregierte Systeme:

• Niedrige Qualität, niedriger Geschäftswert. Die Wartung dieser Systeme wird teuer sein und die Rendite für das Unternehmen wird sehr gering sein. Diese Systeme müssen entsorgt werden.
• Niedrige Qualität, hoher Geschäftswert. Diese Systeme tragen wesentlich zur Gesellschaft bei und können nicht verworfen werden. Die niedrige Qualität bedeutet jedoch, dass es teuer ist, sie zu warten. Diese Systeme müssen einem Reengineering unterzogen werden, um die Qualität zu verbessern, oder ersetzt werden, wenn ein geeignetes kommerzielles System verfügbar ist.
• Hohe Qualität und niedriger Geschäftswert. Dies sind Systeme, die nicht zur Gesellschaft beitragen, aber ihre Wartung ist nicht teuer. Es lohnt sich nicht, sie zu ersetzen, so dass die normale Wartung fortgesetzt werden kann, wenn keine teuren Hardwareänderungen erforderlich sind und das System betriebsbereit ist. Wenn kostspielige Veränderungen notwendig sind, sollten die Systeme entsorgt werden.
• Hohe Qualität, hoher Geschäftswert. Diese Systeme müssen in Betrieb gehalten werden, aber ihre Qualität bedeutet, dass Sie nicht in Reengineering oder Austausch investieren müssen. Der normale Austausch sollte stattfinden.

Beurteilung des Geschäftswerts

Zur Beurteilung des Geschäftswerts eines Systems sollten Sie die Stakeholder des Systems als Endbenutzer und deren Manager identifizieren und eine Reihe von Fragen über das System formulieren. Es gibt vier grundlegende Fragen, die diskutiert werden sollten:

• Die Systemnutzung. Wenn die Systeme gelegentlich oder von einer kleinen Anzahl von Personen genutzt werden, können sie einen geringen Geschäftswert haben. Ein Legacy-System kann entwickelt worden sein, um Bedürfnisse des Unternehmens zu erfüllen, die sich geändert haben oder die nun effizienter auf andere Weise erfüllt werden können.
• Prozessunterstützung. Wenn ein System eingeführt wird, können Prozesse entwickelt werden, um dieses System zu nutzen. Allerdings können Änderungen an diesen Prozessen nicht möglich sein, weil das alte System nicht angepasst werden kann. Daher kann ein System einen geringen Geschäftswert haben, weil es die Einführung neuer Prozesse verhindert.
• Systemzuverlässigkeit. Die Zuverlässigkeit des Systems ist nicht nur ein technisches Problem, sondern auch ein geschäftliches Problem. Wenn ein System unzuverlässig ist und Probleme direkt Kunden oder Personen betreffen, die von ihren Aufgaben abgelenkt werden, um diese Probleme zu lösen, hat das System einen geringen Geschäftswert.
• Die Ausgaben des Systems. Die grundlegende Frage ist hier die Bedeutung der Ausgaben des Systems für den erfolgreichen Betrieb des Unternehmens. Wenn das Unternehmen auf diese Ausgaben angewiesen ist, hat das System einen hohen Geschäftswert. Wenn diese Ausgaben jedoch leicht auf andere Weise erzeugt werden können oder wenn das System selten verwendete Ausgaben generiert, kann sein Geschäftswert gering sein.

Beurteilung der technischen Qualität

Zur Beurteilung der technischen Qualität eines Anwendungssystems sollten Sie mehrere Faktoren berücksichtigen, die vor allem mit der Zuverlässigkeit des Systems, der Schwierigkeit der Systemwartung und der Dokumentation zusammenhängen. Sie können auch quantitative Daten sammeln, die helfen, die Qualität des Systems zu beurteilen. Beispiele für quantitative Daten, die gesammelt werden können, sind:

• Die Anzahl der Änderungsanträge am System. Die Veränderungen neigen dazu, die Systemstruktur zu beschädigen und zukünftige Veränderungen zu erschweren. Je höher dieser Wert, desto geringer die Qualität des Systems.
• Die Anzahl der Benutzerschnittstellen. Dies ist ein wichtiger Faktor in Systemen, die auf Formularen basieren, jede Form kann als eine separate Schnittstelle mit dem Benutzer betrachtet werden. Je mehr Schnittstellen, desto größer ist die Wahrscheinlichkeit von Inkonsistenzen und Redundanzen.
• Das Volumen der vom System verwendeten Daten. Je größer das Datenvolumen (Anzahl der Dateien, Größe der Datenbank usw.), desto komplexer wird das System.

Obwohl diese Daten oft nützlich sind, kann ihre Erhebung sehr teuer und daher nicht praktikabel sein. Darüber hinaus gibt es keine absoluten Werte, die verwendet werden können. Das Alter und die Größe des Systems müssen bei der Beurteilung der Qualität anhand dieser Messungen berücksichtigt werden.