Software-Wartung

Software-Wartung in Softwareentwicklung ist die Änderung eines Softwareprodukts nach der Lieferung, um Fehler zu korrigieren, die Leistung oder andere Attribute zu verbessern.[1][2]

Eine häufige Wahrnehmung der Wartung besteht darin, dass sie lediglich die Fixierung beinhaltet Mängel. Eine Studie zeigte jedoch, dass über 80% der Wartungsaufwand für nicht korrekte Aktionen verwendet werden.[3] Diese Wahrnehmung wird von Benutzern verewigt, die Problemberichte einreichen, die in der Realität Funktionen des Systems sind. Neuere Studien bringen den Bug-Fixing-Anteil näher an 21%.[4]

Geschichte

Software -Wartung und Evolution von Systemen wurde zuerst von angesprochen von Meir M. Lehman 1969 führte seine Forschung über einen Zeitraum von zwanzig Jahren zur Formulierung von Lehmans Gesetze (Lehman 1997). Die wichtigsten Ergebnisse seiner Forschungsergebnisse kommen zu dem Schluss, dass die Wartung wirklich evolutionäre Entwicklung ist und dass Wartungsentscheidungen durch das Verständnis beigetragen werden, was mit Systemen (und Software) im Laufe der Zeit passiert. Lehman zeigte, dass sich die Systeme im Laufe der Zeit weiterentwickeln. Wenn sie sich weiterentwickeln, werden sie komplexer, es sei denn einige Aktionen wie z. Code Refactoring wird genommen, um die Komplexität zu verringern. In den späten 1970er Jahren enthüllte eine berühmte und weithin zitierte Umfrage -Studie von Lientz und Swanson den sehr hohen Anteil von Lebenszykluskosten die für die Wartung aufgewendet wurden.

Die Umfrage ergab, dass rund 75% der Wartungsaufwand auf den ersten beiden Arten waren und die Fehlerkorrektur etwa 21% verbrauchte. Viele nachfolgende Studien deuten auf eine ähnliche Problemgröße hin. Studien zeigen, dass der Beitrag von Endbenutzern während der neuen Erfassung und Analyse der neuen Anforderungen entscheidend ist. Dies ist die Hauptursache für ein Problem bei der Softwareentwicklung und -wartung. Die Wartung der Software ist wichtig, da sie einen großen Teil der gesamten Lebenszykluskosten konsumiert und auch die Unfähigkeit, die Software schnell und zuverlässig zu ändern, bedeutet, dass Geschäftsmöglichkeiten verloren gehen.[5] [6] [7]

Wichtigkeit der Softwarewartung

Die wichtigsten Probleme mit der Wartung der Software sind sowohl im Management als auch technisch. Schlüsselmanagementprobleme sind: Übereinstimmung mit Kundenprioritäten, Personal, welche Organisation Wartung durchführt, die Kosten schätzt. Wichtige technische Probleme sind: begrenztes Verständnis, Einflussanalyse, Tests, Wartbarkeitsmessung.

Die Software -Wartung ist eine sehr breite Aktivität, die Fehlerkorrektur, Verbesserungen der Funktionen, die Löschung der veralteten Funktionen und die Optimierung umfasst. Da Veränderung unvermeidlich ist, müssen Mechanismen zur Bewertung, Kontrolle und Vorstellung von Änderungen entwickelt werden.

So wird alle Arbeiten zur Änderung der Software nach dem Betrieb als Wartungsarbeiten angesehen. Ziel ist es, den Wert der Software im Laufe der Zeit zu bewahren. Der Wert kann durch Erweiterung des Kundenstamms, die Erfüllung zusätzlicher Anforderungen, die Nutzung, effizienter und neuere Technologie erhöht werden. Die Wartung kann sich über 20 Jahre erstrecken, während die Entwicklung 1–2 Jahre betragen kann.

Software -Wartungsplanung

Ein integraler Bestandteil der Software ist die Wartung, für die ein genauer Wartungsplan während der Softwareentwicklung erstellt werden muss. Es sollte angeben, wie Benutzer Änderungen anfordern oder Probleme melden. Das Budget sollte Ressourcen- und Kostenschätzungen umfassen, und eine neue Entscheidung sollte für die Entwicklung jedes neuen Systemfunktion und seiner Qualitätsziele behandelt werden. Die Software -Wartung, die nach dem Entwicklungsprozess mehr als 5 Jahre (oder sogar Jahrzehnte) dauern kann Bereitstellung von Wartung und Schätzung der Lebenszykluskosten.

Software -Wartungsprozesse

Dieser Abschnitt beschreibt die sechs Software -Wartungsprozesse als:

  1. Der Implementierungsprozess enthält Softwarevorbereitungs- und Übergangsaktivitäten wie die Konzeption und Erstellung des Wartungsplans. die Vorbereitung auf den Umgang mit Problemen während der Entwicklung; und das Follow-up zum Produktkonfigurationsmanagement.
  2. Das Problem- und Änderungsanalyseprozess, der ausgeführt wird, sobald die Anwendung in der Verantwortung der Wartungsgruppe geworden ist. Der Wartungsprogrammierer muss jede Anfrage analysieren, diese bestätigen (durch Reproduktion der Situation) und ihre Gültigkeit überprüfen, sie untersuchen und eine Lösung vorschlagen, die Anfrage und den Lösungsvorschlag dokumentieren und schließlich alle erforderlichen Genehmigungen zur Anwendung der Änderungen erhalten.
  3. Der Prozess unter Berücksichtigung der Implementierung der Änderung selbst.
  4. Die Prozessakzeptanz der Änderung durch Bestätigung der geänderten Arbeit mit der Person, die die Anfrage eingereicht hat, um sicherzustellen, dass die Änderung eine Lösung darstellt.
  5. Der Migrationsprozess (Plattformmigrationzum Beispiel) ist außergewöhnlich und nicht Teil der täglichen Wartungsaufgaben. Wenn die Software ohne Änderung der Funktionalität auf eine andere Plattform portiert werden muss, wird dieser Prozess verwendet und ein Wartungsprojektteam wird dieser Aufgabe wahrscheinlich zugewiesen.
  6. Schließlich ist der letzte Wartungsprozess, auch ein Ereignis, das täglich nicht auftritt, der Rücktritt einer Software.

Es gibt eine Reihe von Prozessen, Aktivitäten und Praktiken, die beispielsweise für die Betreuer einzigartig sind:

  • Übergang: Eine kontrollierte und koordinierte Abfolge von Aktivitäten, bei denen ein System zunehmend vom Entwickler auf den Betreuer übertragen wird. Im Idealfall sollte es einen Wissenstransfer (KT) enthalten, der während eines typischen Handverkehrs auftritt.
  • Service Level Agreements (SLA) und spezialisierte (domänenspezifische) Wartungsverträge, die von den Betreuern ausgehandelt wurden
  • Änderungsanforderung und Help-Schreibtisch von Problemberichten: Ein Problem der Problemhandlung, der von den Betreuern zur Priorisierung, Dokumentation und Routung der von ihnen erhaltenen Anfragen verwendet wird

Kategorien der Softwarewartung

E.B. Swanson identifizierte zunächst drei Kategorien der Wartung: Korrektur, adaptiv und perfektiver.[8] Das IEEE 1219 Standard wurde im Juni 2010 von abgelöst von P14764.[9] Diese wurden seitdem aktualisiert und ISO/IEC 14764 präsentiert:

  • Korrekturwartung: Reaktive Änderung eines Softwareprodukts, das nach der Lieferung durchgeführt wurde, um entdeckte Probleme zu korrigieren. Korrekturwartung kann automatisiert werden mit Automatische Fehlerbehebung.
  • Adaptive Wartung: Änderung eines Softwareprodukts, das nach der Lieferung durchgeführt wird, um ein Softwareprodukt in einer veränderten oder sich ändernden Umgebung verwendbar zu halten.
  • Perfektive Wartung: Änderung eines Softwareprodukts nach der Lieferung zur Verbesserung der Leistung oder Wartbarkeit.
  • Vorbeugende Wartung: Änderung eines Softwareprodukts nach Lieferung, um latente Fehler im Softwareprodukt zu erkennen und zu korrigieren, bevor es zu effektiven Fehlern wird.

Es gibt auch einen Vorstellung von Vorablieferung/Vorabwartung, was alles Gute für die Gesamtbesitzkosten für die Software zu senken ist. Dinge wie die Einhaltung der Codierungsstandards, die Software -Wartbarkeitsziele enthalten. Die Verwaltung der Kopplung und Kohäsion der Software. Das Erreichen von Software -Supportability -Zielen (zum Beispiel SAE JA1004, JA1005 und JA1006). Einige akademische Institutionen[wer?] Führen Sie Forschungsarbeiten zur Quantifizierung der Kosten für die laufende Software-Wartung durch, da keine Ressourcen wie Entwurfsdokumente und System-/Softwareverständnisschulungen und Ressourcen (multiplizieren Sie die Kosten mit ca. 1.5-2.0, bei denen keine Designdaten verfügbar sind).

Wartungsfaktoren

Auswirkungen der wichtigsten Anpassungsfaktoren auf die Wartung (sortiert in der Reihenfolge der maximalen positiven Auswirkungen)

Wartungsfaktoren Plus Range
Wartungsspezialisten 35%
Hohe Personalerfahrung 34%
Tabelletriebene Variablen und Daten 33%
Geringe Komplexität des Basiscode 32%
Y2K und spezielle Suchmaschinen 30%
Tools zur Umstrukturierung von Code 29%
Wiedergutmachungsinstrumente 27%
Programmiersprachen auf hoher Ebene 25%
Reverse Engineering Tools 23%
Komplexitätsanalysewerkzeuge 20%
Defekt -Tracking -Tools 20%
Y2K "Mass Update" Spezialisten 20%
Automatisierte Änderungssteuerungswerkzeuge 18%
Unbezahlte Überstunden 18%
Qualitätsmessungen 16%
Formale Basiscode -Inspektionen 15%
Regressionstestbibliotheken 15%
Ausgezeichnete Reaktionszeit 12%
Jährliche Ausbildung von> 10 Tagen 12%
Hochmanagement -Erfahrung 12%
Helpdesk -Automatisierung 12%
Keine fehleranfälligen Module 10%
Online-Defektberichterstattung 10%
Produktivitätsmessungen 8%
Hervorragende Benutzerfreundlichkeit 7%
Benutzerzufriedenheitsmessungen 5%
Hohe Teammoral 5%
Summe 503%

Nicht nur fehleranfällige Module sind problematisch, sondern viele andere Faktoren können auch die Leistung beeinträchtigen. Zum Beispiel sehr komplex Spaghetti -Code ist ziemlich schwer sicher zu pflegen. Eine sehr häufige Situation, die die Leistung häufig beeinträchtigt, ist das Fehlen geeigneter Wartungstools wie Defektverfolgungssoftware, Change Management -Software und Testbibliothekssoftware. Beschreiben Sie unten einige der Faktoren und die Auswirkung der Auswirkungen auf die Software -Wartung.

Auswirkungen der wichtigsten Anpassungsfaktoren auf die Wartung (sortiert in der Reihenfolge maximaler negativer Auswirkungen)

Wartungsfaktoren Minus Reichweite
Fehleranfällige Module -50%
Eingebettete Variablen und Daten -45%
Mitarbeiter Unerfahrenheit -40%
Hohe Codekomplexität -30%
Kein Y2K von speziellen Suchmaschinen -28%
Manuelle Änderungssteuerungsmethoden -27%
Programmiersprachen auf niedriger Ebene -25%
Keine Defekt -Tracking -Tools -24%
Kein Y2K -Spezialisten für Massen -Update -22%
Schlechte Benutzerfreundlichkeit -18%
Keine Qualitätsmessungen -18%
Keine Wartungsspezialisten -18%
Schlechte Reaktionszeit -16%
Keine Codeinspektionen -15%
Keine Regressionstestbibliotheken -15%
Keine Helpdesk -Automatisierung -15%
Keine Online-Defektberichterstattung -12%
Management Unerfahrenheit -15%
Keine Tools zur Umstrukturierung von Code -10%
Keine jährliche Ausbildung -10%
Keine Neugineering -Werkzeuge -10%
Keine umgekehrten Tools -10%
Keine Komplexitätsanalyse -Tools -10%
Keine Produktivitätsmessungen -7%
Schlechte Teammoral -6%
Keine Benutzerzufriedenheitsmessungen -4%
Keine unbezahlte Überstunden 0%
Summe -500%

[10]

Wartungsverschuldung

In einem Papier für die 27. Internationale Konferenz zum Software -Qualitätsmanagement im Jahr 2019,[11] John Estdale führte den Begriff „Wartungsverschuldung“ für die Wartungsanforderungen ein, die durch die Abhängigkeit einer Implementierung von externen IT -Faktoren wie Bibliotheken, Plattformen und Tools erzeugt wurden, die veraltet geworden sind.[12] Die Anwendung wird weiterhin ausgeführt, und die IT -Abteilung vergisst diese theoretische Haftung und konzentriert sich auf dringendere Anforderungen und Probleme an anderer Stelle. Solche Schulden sammeln sich im Laufe der Zeit an und essen stillschweigend auf den Wert des Software -Vermögenswerts. Schließlich passiert etwas, das Systemänderung unvermeidlich macht.

Der Eigentümer kann dann feststellen, dass das System nicht mehr geändert werden kann - es ist buchstäblich unbetentbar. Weniger dramatisch, kann es zu lange dauern oder zu viel kosten, um die Wartung zu lösen, um das Geschäftsproblem zu lösen, und eine alternative Lösung muss gefunden werden. Die Software ist plötzlich auf £ 0 abgestürzt.

Estdale definiert "Wartungsverschuldung"[12] AS: Die Lücke zwischen dem aktuellen Implementierungszustand einer Anwendung und dem Ideal, wobei nur die Funktionalität externer Komponenten verwendet wird, die vollständig gepflegt und unterstützt werden. Diese Schulden sind oft versteckt oder nicht anerkannt. Die allgemeine Wartbarkeit einer Anwendung hängt von der fortgesetzten Erhaltung von Komponenten aller Art von anderen Lieferanten ab, einschließlich:

  • Entwicklungswerkzeuge: Quellbearbeitung, Konfigurationsverwaltung, Kompilierung und Build
  • Testwerkzeuge: Testauswahl, Ausführung/Überprüfung/Berichterstattung
  • Plattformen zum Ausführen der oben genannten: Hardware, Betriebssystem und andere Dienste
  • Produktionsumgebung und alle Standby-/Disaster Recovery-Einrichtungen, einschließlich der Laufzeit-Support-Umgebung der Quellcode-Sprache sowie des breiteren Ökosystems für die Planung von Jobs, Dateiübertragung, replizierter Speicher, Backup und Archiv, Einzelanmeldung usw. usw.
  • Getrennte erworbene Pakete, z. B. DBMs, Grafiken, Comms, Middleware
  • Gekauft in Quellcode, Objektcode-Bibliotheken und anderen invortlosen Diensten
  • Alle Anforderungen, die sich aus anderen Anwendungen ergeben, die die Produktionsumgebung teilen oder mit der betreffenden Anwendung zusammenarbeiten

und natürlich

  • Die Verfügbarkeit relevanter Fähigkeiten, intern oder auf dem Markt.

Das vollständige Verschwinden einer Komponente könnte die Anwendung nicht wieder aufgebuild oder unbegrenzt machen.

Siehe auch

Verweise

[13]

  1. ^ "ISO/IEC 14764: 2006 Software Engineering - Software -Lebenszyklusprozesse - Wartung". ISO.org. 2011-12-17. Abgerufen 2013-12-02.
  2. ^ Soleimani Neysiani, Behzad; Babamir, Seyed Morteza; Aritsugi, Masayoshi (2020-10-01). "Effizientes Merkmalextraktionsmodell für die Verbesserung der Validierungsleistung der Erkennung doppelter Fehlerbericht in Software -Fehler -Triage -Systemen". Informations- und Softwaretechnologie. 126: 106344. doi:10.1016/j.infsof.2020.106344. S2CID 219733047.
  3. ^ Pigoski, Thomas M., 1997: Praktische Software -Wartung: Best Practices für die Verwaltung Ihrer Softwareinvestition. Wiley Computer Pub. (New York)
  4. ^ Eick, S., Graves, T., Karr, A., Marron, J. und Mockus, A. 2001. Verfällt Code? Bewertung von Erkenntnissen aus Änderungsmanagementdaten. IEEE -Transaktionen zum Software -Engineering. 27 (1) 1-12.
  5. ^ Lientz B., Swanson E., 1980: Software -Wartungsmanagement. Addison Wesley, Reading, MA
  6. ^ Lehman M. M., 1980: Programm, Lebenszyklen und die Gesetze der Softwareentwicklung. In Proceedings of IEEE, 68, 9.1060-1076
  7. ^ Penny Grubb, Armstrong A. Takang, 2003: Software -Wartung: Konzepte und Praxis. World Scientific Publishing Company
  8. ^ Lientz, B. P.; Swanson, E. B.; Tompkins, G. E. (Juni 1978). "E. Burt Swanson, Die Dimensionen der Wartung. Proceedings der 2. Internationalen Konferenz für Software -Engineering, San Francisco, 1976, S. 492 - 497". Kommunikation der ACM. Portal.acm.org. 21 (6): 466–471. doi:10.1145/359511.359522. S2CID 14950091. Abgerufen 2013-12-02.
  9. ^ Status von 1219-1998 nach IEEE -Standards
  10. ^ "Die Ökonomie der Software -Wartung im zwanzig ersten Jahrhundert" (PDF). Archiviert von das Original (PDF) Am 2015-03-19. Abgerufen 2013-12-02.
  11. ^ Khan, o; Marchbank, P; Georgiadou, e; Linecar, p; Ross, M; Staples, G (2019). Proc of Software Quality Management XXVII: Internationale Erfahrungen und Initiativen im IT -Qualitätsmanagement. Southampton: Solent University. ISBN 978-1-9996549-2-4.
  12. ^ a b Estdale, John. Die Verzögerung der Wartung kann sich als tödlich erweisen. in [11]. S. 95–106.
  13. ^ Pigoski, Thomas. "Kapitel 6: Software -Wartung" (PDF). Swebok. IEEE. Abgerufen 5. November 2012.

Weitere Lektüre

  • ISO/IEC 14764 IEEE STD 14764-2006 Software Engineering-Software-Lebenszyklusprozesse-Wartung. 2006. doi:10.1109/IEEESTD.2006.235774. ISBN 0-7381-4960-8.
  • Pigoski, Thomas M. (1996). Praktische Software -Wartung. New York: John Wiley & Sons. ISBN 978-0-471-17001-3.
  • Pigoski, Thomas M. Beschreibung für Softwareentwicklung und Wartung (Version 0.5). Swebok -Wissensbereich.
  • April, Alain; Abran, Alain (2008). Software -Wartungsmanagement. New York: Wiley-ieee. ISBN 978-0-470-14707-8.
  • Gopalaswamy Ramesh; Ramesh Bhattiprolu (2006). Software -Wartung: Effektive Praktiken für geografisch verteilte Umgebungen. Neu-Delhi: Tata McGraw-Hill. ISBN 978-0-07-048345-3.
  • Grubb, Penny; Takang, Armstrong (2003). Software-Wartung. New Jersey: World Scientific Publishing. ISBN 978-981-238-425-6.
  • Lehman, M.M.; Belady, L. A. (1985). Programmentwicklung: Prozesse der Softwareänderung. London: Academic Press Inc. ISBN 0-12-442441-4.
  • Page-Jones, Meilir (1980). Der praktische Leitfaden für strukturierte Systeme Design. New York: YourDon Press. ISBN 0-917072-17-0.

Externe Links