Übersicht über die Softwarewartung

Die Softwarewartung ist heutzutage ein weit verbreiteter Bestandteil von SDLC. Es steht für alle Änderungen und Aktualisierungen, die nach der Lieferung des Softwareprodukts vorgenommen wurden. Es gibt eine Reihe von Gründen, warum Änderungen erforderlich sind. Einige davon werden im Folgenden kurz erwähnt:

  • Market Conditions - Richtlinien, die sich im Laufe der Zeit ändern, wie z. B. Steuern und neu eingeführte Einschränkungen wie die Aufrechterhaltung der Buchhaltung, können Änderungen erforderlich machen.

  • Client Requirements - Im Laufe der Zeit kann der Kunde nach neuen Merkmalen oder Funktionen in der Software fragen.

  • Host Modifications - Wenn sich die Hardware und / oder Plattform (z. B. das Betriebssystem) des Zielhosts ändert, sind Softwareänderungen erforderlich, um die Anpassungsfähigkeit aufrechtzuerhalten.

  • Organization Changes - Wenn sich auf Kundenebene Änderungen auf Unternehmensebene ergeben, z. B. eine Verringerung der Organisationsstärke, die Übernahme eines anderen Unternehmens oder die Neugründung von Organisationen in die neue Software, kann eine Änderung der ursprünglichen Software erforderlich sein.

Arten der Wartung

Während einer Software-Lebensdauer kann die Art der Wartung je nach Art variieren. Es kann sich lediglich um routinemäßige Wartungsaufgaben handeln, da ein Fehler von einem Benutzer entdeckt wurde, oder es kann sich um ein großes Ereignis handeln, das auf der Größe oder Art der Wartung basiert. Im Folgenden sind einige Arten der Wartung aufgeführt, die auf ihren Eigenschaften basieren:

  • Corrective Maintenance - Dies schließt Änderungen und Aktualisierungen ein, die vorgenommen wurden, um Probleme zu beheben oder zu beheben, die entweder vom Benutzer entdeckt oder durch Benutzerfehlerberichte abgeschlossen wurden.

  • Adaptive Maintenance - Dies umfasst Änderungen und Aktualisierungen, die vorgenommen werden, um das Softwareprodukt auf dem neuesten Stand zu halten und auf die sich ständig ändernde Welt der Technologie und des Geschäftsumfelds abzustimmen.

  • Perfective Maintenance- Dies schließt Änderungen und Aktualisierungen ein, die vorgenommen werden, um die Software über einen langen Zeitraum nutzbar zu machen. Es enthält neue Funktionen, neue Benutzeranforderungen für die Verbesserung der Software und die Verbesserung ihrer Zuverlässigkeit und Leistung.

  • Preventive Maintenance- Dies beinhaltet Änderungen und Aktualisierungen, um zukünftige Probleme der Software zu vermeiden. Ziel ist es, Probleme zu lösen, die derzeit nicht von Bedeutung sind, aber in Zukunft schwerwiegende Probleme verursachen können.

Wartungskosten

Berichten zufolge sind die Wartungskosten hoch. Eine Studie zur Schätzung der Softwarewartung ergab, dass die Wartungskosten bis zu 67% der Kosten des gesamten Softwareprozesszyklus betragen.

Im Durchschnitt betragen die Kosten für die Softwarewartung mehr als 50% aller SDLC-Phasen. Es gibt verschiedene Faktoren, die hohe Wartungskosten auslösen, wie z.

Reale Faktoren, die die Wartungskosten beeinflussen

  • Das Standardalter einer Software beträgt 10 bis 15 Jahre.
  • Ältere Software, die auf langsamen Computern mit weniger Speicher und Speicherkapazität funktionieren sollte, kann sich nicht gegen neu entwickelte erweiterte Software auf moderner Hardware behaupten.
  • Mit fortschreitender Technologie wird die Wartung alter Software kostspielig.
  • Die meisten Wartungstechniker sind Neulinge und verwenden die Trial-and-Error-Methode, um das Problem zu beheben.
  • Oft können vorgenommene Änderungen die ursprüngliche Struktur der Software leicht beschädigen, was spätere Änderungen erschwert.
  • Änderungen werden häufig nicht dokumentiert, was in Zukunft zu weiteren Konflikten führen kann.

Software-Endfaktoren, die die Wartungskosten beeinflussen

  • Struktur des Softwareprogramms
  • Programmiersprache
  • Abhängigkeit von der äußeren Umgebung
  • Zuverlässigkeit und Verfügbarkeit des Personals

Wartungsaktivitäten

IEEE bietet einen Rahmen für sequentielle Wartungsprozessaktivitäten. Es kann iterativ verwendet und erweitert werden, sodass benutzerdefinierte Elemente und Prozesse einbezogen werden können.

Diese Aktivitäten gehen Hand in Hand mit jeder der folgenden Phasen:

  • Identification & Tracing- Es handelt sich um Aktivitäten zur Identifizierung des Änderungs- oder Wartungsbedarfs. Es wird vom Benutzer generiert oder das System kann selbst über Protokolle oder Fehlermeldungen berichten. Hier wird auch der Wartungstyp klassifiziert.

  • Analysis- Die Änderung wird auf ihre Auswirkungen auf das System einschließlich der Auswirkungen auf die Sicherheit analysiert. Wenn die wahrscheinlichen Auswirkungen schwerwiegend sind, wird nach einer alternativen Lösung gesucht. Eine Reihe erforderlicher Änderungen wird dann in Anforderungsspezifikationen umgesetzt. Die Kosten für Änderungen / Wartung werden analysiert und die Schätzung abgeschlossen.

  • Design- Neue Module, die ersetzt oder geändert werden müssen, werden anhand der in der vorherigen Stufe festgelegten Anforderungsspezifikationen entwickelt. Testfälle werden zur Validierung und Verifizierung erstellt.

  • Implementation - Die neuen Module werden mit Hilfe des im Entwurfsschritt erstellten strukturierten Entwurfs codiert. Von jedem Programmierer wird erwartet, dass er parallel Unit-Tests durchführt.

  • System Testing- Integrationstests werden für neu erstellte Module durchgeführt. Integrationstests werden auch zwischen neuen Modulen und dem System durchgeführt. Schließlich wird das System nach regressiven Testverfahren als Ganzes getestet.

  • Acceptance Testing- Nach dem internen Testen des Systems wird es mit Hilfe der Benutzer auf Akzeptanz geprüft. In diesem Zustand beschwert sich der Benutzer über einige Probleme, die in der nächsten Iteration behoben oder behoben werden sollen.

  • Delivery- Nach dem Abnahmetest wird das System im gesamten Unternehmen entweder durch ein kleines Update-Paket oder durch eine Neuinstallation des Systems bereitgestellt. Der endgültige Test findet am Client-Ende nach Auslieferung der Software statt.

    Bei Bedarf wird zusätzlich zum Ausdruck des Benutzerhandbuchs eine Schulungseinrichtung bereitgestellt.

  • Maintenance management- Das Konfigurationsmanagement ist ein wesentlicher Bestandteil der Systemwartung. Es wird mit Tools zur Versionskontrolle unterstützt, um Versionen, Halbversionen oder Patch-Management zu steuern.

Software-Re-Engineering

Wenn wir die Software aktualisieren müssen, um sie auf dem aktuellen Markt zu halten, ohne ihre Funktionalität zu beeinträchtigen, spricht man von Software-Re-Engineering. Es ist ein gründlicher Prozess, bei dem das Design von Software geändert und Programme neu geschrieben werden.

Legacy-Software kann nicht mit der neuesten auf dem Markt verfügbaren Technologie Schritt halten. Wenn die Hardware veraltet ist, bereitet das Aktualisieren der Software Kopfschmerzen. Selbst wenn Software mit der Zeit alt wird, funktioniert ihre Funktionalität nicht.

Beispielsweise wurde Unix ursprünglich in Assemblersprache entwickelt. Als Sprache C ins Leben gerufen wurde, wurde Unix in C überarbeitet, da die Arbeit in Assemblersprache schwierig war.

Abgesehen davon bemerken Programmierer manchmal, dass nur wenige Teile der Software mehr Wartung benötigen als andere, und sie müssen auch neu entwickelt werden.

Re-Engineering-Prozess

  • Decidewas neu zu konstruieren. Ist es ganze Software oder ein Teil davon?
  • Perform Reverse Engineering, um Spezifikationen der vorhandenen Software zu erhalten.
  • Restructure ProgramFalls erforderlich. Zum Beispiel funktionsorientierte Programme in objektorientierte Programme ändern.
  • Re-structure data nach Bedarf.
  • Apply Forward engineering Konzepte, um überarbeitete Software zu erhalten.

Es gibt nur wenige wichtige Begriffe, die beim Software-Re-Engineering verwendet werden

Reverse Engineering

Es ist ein Prozess, um die Systemspezifikation durch gründliche Analyse und Verständnis des vorhandenen Systems zu erreichen. Dieser Prozess kann als umgekehrtes SDLC-Modell angesehen werden, dh wir versuchen, eine höhere Abstraktionsebene zu erreichen, indem wir niedrigere Abstraktionsebenen analysieren.

Ein bestehendes System ist zuvor Design implementiert, über das wir nichts wissen. Designer führen dann ein Reverse Engineering durch, indem sie sich den Code ansehen und versuchen, das Design zu erhalten. Mit dem Design in der Hand versuchen sie, die Spezifikationen abzuschließen. Umgekehrt vom Code zur Systemspezifikation.

Programmumstrukturierung

Es ist ein Prozess, um die vorhandene Software neu zu strukturieren und neu zu konstruieren. Es geht darum, den Quellcode entweder in derselben Programmiersprache oder von einer Programmiersprache in eine andere neu anzuordnen. Die Umstrukturierung kann entweder eine Quellcode-Umstrukturierung und eine Datenumstrukturierung oder beides umfassen.

Eine Umstrukturierung wirkt sich nicht auf die Funktionalität der Software aus, verbessert jedoch die Zuverlässigkeit und Wartbarkeit. Programmkomponenten, die sehr häufig Fehler verursachen, können geändert oder durch Umstrukturierung aktualisiert werden.

Die Zuverlässigkeit von Software auf veralteten Hardwareplattformen kann durch Umstrukturierung beseitigt werden.

Forward Engineering

Forward Engineering ist ein Prozess zum Erhalten der gewünschten Software aus den vorliegenden Spezifikationen, die durch Reverse Engineering heruntergefahren wurden. Es wird davon ausgegangen, dass bereits in der Vergangenheit Software-Engineering durchgeführt wurde.

Forward Engineering ist mit nur einem Unterschied dasselbe wie Software Engineering-Prozess - es wird immer nach Reverse Engineering durchgeführt.

Wiederverwendbarkeit von Komponenten

Eine Komponente ist Teil des Softwareprogrammcodes, der eine unabhängige Aufgabe im System ausführt. Es kann sich um ein kleines Modul oder ein Subsystem handeln.

Beispiel

Die im Web verwendeten Anmeldeverfahren können als Komponenten betrachtet werden, das Drucksystem in der Software kann als Komponente der Software angesehen werden.

Komponenten haben eine hohe Kohäsion der Funktionalität und eine geringere Kopplungsrate, dh sie arbeiten unabhängig voneinander und können Aufgaben ausführen, ohne von anderen Modulen abhängig zu sein.

In OOP sind die entworfenen Objekte sehr spezifisch für ihr Anliegen und haben weniger Chancen, in einer anderen Software verwendet zu werden.

Bei der modularen Programmierung sind die Module so codiert, dass sie bestimmte Aufgaben ausführen, die für eine Reihe anderer Softwareprogramme verwendet werden können.

Es gibt eine völlig neue Branche, die auf der Wiederverwendung von Softwarekomponenten basiert und als Component Based Software Engineering (CBSE) bekannt ist.

Die Wiederverwendung kann auf verschiedenen Ebenen erfolgen

  • Application level - Wenn eine gesamte Anwendung als Teilsystem neuer Software verwendet wird.

  • Component level - Wenn das Subsystem einer Anwendung verwendet wird.

  • Modules level - Wo Funktionsmodule wiederverwendet werden.

    Softwarekomponenten bieten Schnittstellen, über die die Kommunikation zwischen verschiedenen Komponenten hergestellt werden kann.

Wiederverwendungsprozess

Es gibt zwei Arten von Methoden: entweder indem die Anforderungen gleich bleiben und die Komponenten angepasst werden oder indem die Komponenten gleich bleiben und die Anforderungen geändert werden.

  • Requirement Specification - Es werden die funktionalen und nicht funktionalen Anforderungen festgelegt, die ein Softwareprodukt mithilfe eines vorhandenen Systems, Benutzereingaben oder beidem erfüllen muss.

  • Design- Dies ist auch ein Standard-SDLC-Prozessschritt, in dem Anforderungen in Bezug auf die Softwaresprache definiert werden. Die Grundarchitektur des Gesamtsystems und seiner Subsysteme wird erstellt.

  • Specify Components - Durch das Studium des Software-Designs trennen die Designer das gesamte System in kleinere Komponenten oder Subsysteme. Aus einem vollständigen Software-Design wird eine Sammlung einer Vielzahl von Komponenten, die zusammenarbeiten.

  • Search Suitable Components - Das Software-Komponenten-Repository wird von Designern zur Suche nach der passenden Komponente auf der Grundlage der Funktionalität und der beabsichtigten Softwareanforderungen verwiesen.

  • Incorporate Components - Alle aufeinander abgestimmten Komponenten werden zusammengepackt, um sie als vollständige Software zu formen.