Softwaredokumentation und Softwarewartung

Transkript

1 Studienmaterial Verfahren und Systeme der Softwaredokumentation Softwaredokumentation und Softwarewartung MIP403 Prof. Dr. Dieter Friedrich

2 1 Verfahren und Systeme der Softwaredokumentation Softwaredokumentation und Softwarewartung Einleitung und Lernziele 4 1 Grundlagen und Begriffe Software Softwarewartung Softwarelebenszyklus Entstehungs- und Entwicklungsphase Evolutionsphase Erhaltungsphase Entsorgungsphase Softwareproduktmanagement Prototypmanagement Produktmanagement Projektmanagement Prozessmanagement 13 2 Arten, Aufwand und Risiken der Softwarewartung Softwareprodukttypen Wegwerfsysteme (specifyable-type) Statische Systeme (problem-solving-type) Dynamische Systeme (embedded-type) Alterung von Software Lack of movement Ignorant surgery Wachsende Entropie Legacy-Systeme Gesetze der Softwareevolution Wartungsarten und Wartungsprozesse Korrektive Wartung Präventive Wartung Adaptive Wartung Perfektionierende Wartung Reaktive und proaktive Wartung Aufwand für Wartung und Pflege Aufwandschätzung im Softwarelebenszyklus Fehlerarten und Wartungsaufwand Aufwandschätzung für Wartungsprozesse Aufwandschätzung für Wartung oder Systemablösung Risiken und Grundsätze der Wartung 28 Inhaltsverzeichnis

3 2 3 Organisation der Softwarewartung Aufbau einer Produktbetreuungsorganisation Prozessmanagement der Wartungsphase Organisation von Wartungsprozessen Organisation von Supportprozessen Rollen und Funktionen im Wartungsprozess Aufbau- und Prozessorganisation versus Projektorganisation Wartungsorganisation Supportorganisation Entwicklungsorganisation 44 4 Management der Softwarewartung Konfigurationsmanagement Aufgaben des Konfigurationsmanagements Elemente des Konfigurationsmanagements Änderungsmanagement Versions- und Release-Management Qualitätsmanagement in der Wartung Nutzungs- und Wartungsqualität Maßnahmen zur Qualitätssicherung 55 Copyright AKAD Bildungsgesellschaft mbh Ein Unternehmen der Cornelsen-Gruppe. Telefon: (07 11) Internet: Alle Rechte vorbehalten. Jede Verwertung außerhalb der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung der AKAD unzulässig und strafbar. Das gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Bearbeitung in elektronischen Systemen. 5 Softwaredokumentation Arten und Grundsätze der Dokumentation Arten der Dokumentation Grundsätze und Leitlinien der Dokumentation Codierrichtlinien und Style-Guides für Programmcode Zielsetzung, Inhalt und Adressaten der Dokumentation Ablage und Speicherung der Dokumentation Software-Artefakt-Management (SAM) Softwareprodukt-Repository 65 6 Testen in der Softwarewartung Grundlagen des Testens Modultests (Unit- bzw. Komponententests) Integrationstests (Interaktionstests) Systemtests Abnahmetests (Verfahrenstests, Akzeptanztests) Prüfverfahren und Testmethoden Statische Test- und Prüfverfahren Dynamische Testverfahren Testplanung in der Wartung 76 7 Metriken der Softwarewartung Arten und Zielsetzungen von Metriken Produktmetriken Volumenmetriken Struktur- und Komplexitätsmetriken Wartungsindex 84 Inhaltsverzeichnis

4 Metriken der objektorientierten Programmierung Prozessmetriken Metriken zur Messung der Zuverlässigkeit Metriken zur Aufwandsmessung 88 8 Werkzeuge zur Unterstützung der Softwarewartung Versionsverwaltungssysteme Testwerkzeuge Bug-Tracking-Systeme Aufgaben Nutzung und Beteiligte Beispiele für Open-Source-Bugtracker 95 Zusammenfassung 99 Antworten zu den Kontrollfragen 105 Abkürzungsverzeichnis 112 Literaturverzeichnis 114 Stichwortverzeichnis 117 Inhaltsverzeichnis

5 4 Einleitung und Lernziele Nach ihrer Einführung und Nutzung müssen sich Systeme unausweichlich verändern, wenn sie einsatzfähig bleiben sollen. Schon bald nach Inbetriebnahme einer Software ergeben sich neue Anforderungen und bestehende ändern sich. Geschäftliche Veränderungen ziehen oft neue Anforderungen an Bestandssoftware nach sich. Vielleicht müssen Teile der Software geändert werden, um während des Betriebs festgestellte Fehler zu korrigieren, sie an eine neue Plattform anzupassen oder ihre Leistung oder andere nicht funktionale Eigenschaften zu verbessern. Die Softwareentwicklung hört daher mit der Auslieferung eines Systems nicht auf, sondern setzt sich über die gesamte Lebensdauer des Systems fort. Die Erhaltung bestehender Software ist wichtig, da Organisationen inzwischen völlig von ihren Softwaresystemen abhängig sind und Millionen in diese Systeme investiert haben. Ihre Systeme gehören zum entscheidenden Betriebsvermögen, und sie müssen in Systemänderungen investieren, um den Wert dieses Betriebsvermögens zu erhalten. Der Hauptanteil des Softwarebudgets wird in großen Unternehmen daher für die Wartung bestehender Systeme eingesetzt. Zudem ist ein (erfolgreiches) Softwaresystem im größten Teil seiner Existenzdauer in Wartung. Softwarewartung hat also eine große Bedeutung. Wie Sie im Verlauf dieses Studienbriefs sehen werden, gehören zur Wartung im Vergleich zu den normalen Abläufen der Softwareentwicklung noch weitere Prozessaktivitäten, wie z. B. das Verstehen von Programmen. An dieser Stelle kommt die Dokumentation ins Spiel. Dokumente dienen zum Retten und Bewahren des Wissens über Programme, auf das schon während der Entwicklung zurückgegriffen werden kann. Besonders wertvoll sind die Dokumente jedoch für diejenigen, die die Software weiterentwickeln und warten müssen. Dies ist ein wesentliches Ziel der Dokumentation, und deshalb beschäftigen wir uns in diesem Modul nicht nur mit der Softwarewartung, sondern auch mit der Softwaredokumentation. Im ersten Teil behandeln wir die Grundlagen der Softwarewartung und geben Ihnen einen Überblick über die Grundlagen und die im Zusammenhang mit der Softwarewartung relevanten Begriffe. Sie erhalten eine Einführung in die Ursachen, Risiken und die verschiedenen Arten der Softwarewartung. Der zweite Teil beschäftigt sich mit der Organisation und den Managementthemen der Softwarewartung. Hier werden Wartungsprozesse beschrieben und es wird insbesondere das Konfigurations- und Qualitätsmanagement behandelt. Im dritten Teil folgt ein Kapitel, in dem Anforderungen und Probleme der Dokumentation erörtert werden. In weiteren Kapiteln werden Testverfahren und Metriken vorgestellt, die den Prozess der Softwarewartung unterstützen. Schließlich stellen wir im vierten Teil Werkzeuge zur Unterstützung der Softwarewartung vor. Am Beispiel von Trouble-Ticket-Systemen wird u. a. demonstriert, welche Anforderungen an eine Managementsoftware bestehen, die den Support-Prozess unterstützt. Einleitung/Lernziele

6 5 Nach Abschluss dieses Studienbriefs kennen Sie die wesentlichen Begriffe und Kategorien der Softwarewartung, können Sie erläutern, warum Softwarewartung wichtig im Produktlebenszyklus eines Softwaresystems ist, können Sie den Wartungsprozess und die Organisation der Softwarewartung skizzieren, kennen Sie die wesentlichen Elemente und Funktionen des Produkt- und Konfigurationsmanagements, können Sie erläutern, was eine gute Softwarewartungsdokumentation ausmacht, kennen Sie spezielle Aspekte und Techniken der Softwarewartung und wissen Sie, welche Funktionen Trouble-Ticket- und Bug-Tracking-Systeme beim Support und in der Wartung übernehmen. Über die Autoren dieses Studienbriefs Prof. Dr. DIETER FRIEDRICH unterrichtet als Dozent an den AKAD-Privathochschulen auf dem Gebiet der Wirtschaftsinformatik und lehrte am Institut für Wirtschaftsinformatik und Quantitative Methoden der TU Berlin. MATTHIAS KUPTZ ist Diplom-Informatiker. Er studierte Anwendungsorientierte Informatik (Ingenieursysteme) an der Universität Stuttgart. Er betreute bis 2008 für die AKAD-Hochschulen im Bereich Entwicklung und Produktdesign das Fachgebiet Wirtschaftsinformatik. Herr Kuptz verfügt über langjährige (z. T. internationale) Erfahrung im Informationsmanagement sowie in Softwareentwicklungs- und Standardsoftwareeinführungsprojekten in der Industrie wechselte er zur Daimler AG Stuttgart. Einleitung/Lernziele

7 6 1 Grundlagen und Begriffe Softwarewartung ist nach SOMMERVILLE 1 der Prozess der Softwareänderung nach der Auslieferung. Das klingt sehr abstrakt. Was ist Softwarewartung überhaupt? Ziehen wir einen Vergleich aus dem Betrieb von Eisenbahnen: Die Wartung von Gleisanlagen ist planbar; durch Berechnungen oder aus Erfahrung ist bekannt, dass die Gleise nach einer gewissen Zeit abgenutzt sind und sich ihre Eigenschaften (z. B. die Belastbarkeit) verändert haben. Sie werden deshalb periodisch geprüft und zum Teil ersetzt. Diese Wartungsarbeiten erfolgen aufgrund des Verschleißes der Gleise. Dagegen ist die Reparatur der Gleise nach einem Bahnunglück, etwa wenn eine Bahn entgleist ist, nicht planbar. Man kann zwar, da es Statistiken über solche Unfälle gibt, ein Budget für Reparaturen vorsehen, doch der einzelne, konkrete Unfall kommt immer überraschend. Die Arbeiten können nicht langfristig, bereits in der Entwicklung der Gleisanlagen geplant werden. Wir können also festhalten, dass Wartung im engeren Sinne (d. h. zur Kompensation der Abnutzung) präzise geplant werden kann. Dagegen werden Reparaturen überraschend notwendig und lassen sich nicht im Einzelnen planen. Da sich Software nicht abnutzt, gibt es für eine Wartung im engeren Sinne keinen Bedarf, wohl aber für Reparaturen und Änderungen. Natürlich sind Korrekturen notwendig, vor allem kurz nach der Auslieferung, wenn sich im Gebrauch Mängel zeigen. Aber die Korrektur ist nicht der einzige Grund für die Arbeiten an einer Software, die bereits im Einsatz ist. Eine Software, die intensiv genutzt wird, erzeugt neue Wünsche und Bedürfnisse. Je breiter der Einsatzbereich ist, desto größer ist die Zahl der Anforderungen, die sich ändern. Das bedeutet: Je erfolgreicher die Software ist, desto mehr Anpassungen und Erweiterungen braucht sie. Daraus erklärt sich der scheinbar paradoxe Zusammenhang zwischen Qualität und Wartungskosten: Je besser eine Software ist, desto höher sind ihre Wartungskosten, weil bessere Software länger und von mehr Menschen genutzt wird und darum häufiger neue Anforderungen auslöst. Sie sehen, Softwarewartung kann aus verschiedenen Gründen notwendig werden, z. B. um neue Funktionalität in die Software einzubauen, Fehler zu beheben, das Systemdesign zu verbessern oder den Ressourcenverbrauch zu senken. Insgesamt gibt es jedoch verschiedene Auffassungen darüber, was Softwarewartung ist, wie dieser Begriff abzugrenzen ist, wann sie beginnt und welche Teilaufgaben dazugehören. Unbestritten ist lediglich ihre große Bedeutung als längste und in vielen Fällen mit dem höchsten Aufwand verbundene Aktivität im Softwarelebenszyklus. 1.1 Software Der Begriff Software (SW) umfasst nicht nur die Programme, sondern auch die Verfahren, die zugehörige Dokumentation und die Daten, die bei der Entwicklung einer SW erzeugt werden und den Betrieb eines Computersystems unterstützen. 1 SOMMERVILLE, 2007, S Kapitel 1

8 7 Software besteht somit nicht nur aus dem Programmcode, zur Software gehören auch zahlreiche Dokumente, Unterlagen und Arbeitsmaterialien, die man manchmal auch als Artefakte bezeichnet. Zu den Artefakten zählen wir alle Produkte, die im Zusammenhang mit einer Systementwicklung erstellt werden, wie beispielsweise Anforderungsdefinitionen, Geschäftsprozessdarstellungen, Entwurfsdiagramme, Dokumentationen für Entwicklung, Benutzung, Betrieb und Wartung, Review-Berichte, Testumgebungen, Testdaten, Testprotokolle usw. P Bei der Beschreibung der Eigenschaften von Software wird in der Regel hervorgehoben: Software unterliegt keiner Abnutzung und keinem Verschleiß. Trotzdem unterliegt Software einem Alterungsprozess und muss gewartet werden. Software ist ein immaterielles technisches Produkt. Fehler sind daher nicht offensichtlich erkennbar. Selbst kleine Änderungen können massive Auswirkungen auf das Gesamtsystem und das Systemverhalten haben. Software gilt, im Gegensatz zu anderen (physischen) technischen Produkten, als leicht änderbar. Diese Änderbarkeit bezieht sich nur auf die formale Möglichkeit, den Quellcode der Software operativ einfach zu verändern. Unter dem Aspekt der Softwarewartung erfordert eine zielgerichtete (korrekte) Änderung von Software, mit der ein gewünschtes Ergebnis und nur dieses erreicht werden soll, in den meisten Fällen einen aufwendigen und komplizierten Eingriff in ein Softwaresystem. Die inhaltlich korrekte Änderung von Software ist daher in den meisten Fällen ein schwieriger Prozess. Schnelle, unbedachte, unsystematische Änderungen (quick fixes) einer funktionierenden Software können sich längerfristig als verhängnisvolle Fehler entpuppen. Zur Software gehören nicht nur der Programmcode, sondern auch zahlreiche Artefakte in Form von Dokumentationsunterlagen, Verfahren, Arbeitsunterlagen und Daten. Im Gegensatz zu anderen (physischen) Produkten hat Software besondere Eigenschaften: sie ist immateriell, unterliegt keiner Abnutzung und ist (formal) leicht änderbar, inhaltlich korrekte Änderungen sind hingegen meist schwierig. 1.2 Softwarewartung Der Begriff Softwarewartung wird häufig mit den Begriffen Fehlerbeseitigung und Softwarereparatur assoziiert. Der Begriff Softwarewartung hat jedoch mit dem geläufigen Begriff der technischen Wartung wenig gemeinsam. Aufgrund ihres immateriellen Charakters beinhaltet Software keine Verschleißteile und unterliegt somit keiner Form von Abnutzung. Im Unterschied zur technischen Wartung erfolgt bei der Softwarewartung nicht die Herstellung des ursprünglichen Zustands, sondern eine Veränderung der Software. Softwarewartung als Übersetzung des Begriffs software maintenance ist weiter zu fassen und sollte im Sinne von Softwareerhaltung, -instandhaltung oder -pflege interpretiert werden. Sie umfasst die Anpassung, Veränderung, Verbesserung, aber auch Reparatur von Software. BOMMER übernimmt bei der Klärung des Begriffs Softwarewartung die IEEE-Definition. Diese Definition der Wartung führt allerdings zu Widersprüchen: Auf der einen Seite gibt es bereits während der Entwicklung Probleme, die behoben werden müssen; Kapitel 1

9 8 diese Maßnahmen unterscheiden sich nur dadurch von der Wartung, wie sie in IEEE definiert wurde, dass das System noch nicht beim Kunden läuft. Auf der anderen Seite findet Softwareentwicklung oft inkrementell statt, und das System wird nach der Auslieferung planmäßig erweitert und ausgebaut. Das ist Entwicklung, keine Wartung. Offenbar spielt die Frage, ob es sich um geplante oder um ungeplante Arbeiten handelt, eine wichtige Rolle. Ludewig berücksichtigt in seiner Definition die Nichtvorhersehbarkeit der Softwarewartung 1 : Softwarewartung ist jede Arbeit an einem bestehenden Softwaresystem, die nicht von Beginn der Entwicklung an geplant war oder hätte geplant werden können und die unmittelbare Auswirkungen auf den Benutzer der Software hat. Diese Definition schließt Softwarereengineering aus, das die internen Eigenschaften, also die Wartungsqualität der Software, verbessert. Auch die Komposition bestehender Komponenten zu einem System wird nicht zur Wartung gezählt; die Komponenten sind ja für diesen Zweck entwickelt worden. Ludewig fasst Wartung und Reengineering unter dem Oberbegriff Softwarepflege zusammen. Unter dem Begriff Softwarewartung versteht man die nachträgliche Veränderung eines Softwareproduktes nach dessen Einführung (Auslieferung, Übergabe, Inbetriebnahme). Sie umfasst nicht nur die Softwarereparatur, die Änderungen der Software erfordert, um aufgetretene Fehler zu korrigieren. Im Rahmen der Wartung und Pflege einer Software können Änderungen auch durchgeführt werden, um die Performanz zu erhöhen, Artefakte zu verbessern oder die Software an veränderte Rahmenbedingungen anzupassen. Der englische Begriff software maintenance (Erhaltung, Instandhaltung) ist etwas weiter gefasst. Er umfasst alle Erhaltungsmaßnahmen, zu denen Korrektur, Reparatur, Support, Anpassung, Verbesserung und Weiterentwicklung von Software gehören. Er beschreibt die Anlässe zur Pflege und Veränderung von Softwareprodukten umfassender als der Begriff Softwarewartung, den wir aus Gründen der sprachlichen Vereinfachung im Folgenden weiter verwenden. Ferner sollte beachtet werden, dass der Begriff Softwarewartung in der Praxis in dreifachem Sinne verwendet wird. Er bezeichnet die Tätigkeit der Programmierer, die eine Änderung an einem Softwaresystem nach dessen Auslieferung vornehmen, als (Geschäfts-)Prozess die Schritte, die in einem Wartungsfall sequenziell durchgeführt werden, im Lebenszyklus die Phase der Veränderungen eines Softwaresystems nach dessen Erstellung bis zur Ablösung oder Stilllegung. Softwarewartung kann als Tätigkeit, als Geschäftsprozess oder als Phase des Softwarelebenszyklus aufgefasst werden. Der englische Begriff software maintenance beschreibt die Erhaltung und Instandhaltung nach der Auslieferung an den Kunden oder Benutzer. Manche Autoren nehmen den Support und die Weiterentwicklung der Software von der Wartung aus. 1 LUDEWIG, Kapitel 1

10 9 1.3 Softwarelebenszyklus Ausgangspunkt der Überlegungen zur Softwareentwicklung, Softwarewartung und Softwarenutzung ist der Softwarelebenszyklus. Problemstellung, (Vorbereitung, Projektstart) Anforderungsanalyse (Requirement Analysis) Spezifikation Entstehungsphase Abbildung 1: Hierbei unterscheidet man die Phasen: Lebenszyklus der Softwareentwicklung, Softwarewartung und Softwarenutzung Design Programmierung, Implementierung Test (Modul-, Integrations- Abnahmetest) Entwicklungsphase Einführung (Auslieferung, Übergabe, Installation) Betrieb Verbesserung, Erweiterung, Sanierung, Migration Evolutionsphase Maintenance (Wartung, Pflege) Erhaltungsphase Stilllegung, Entsorgung, Ablösung Entsorgungsphase Es wird der gesamte Lebenslauf eines Softwareprodukts von der Problemstellung und Initialisierung der Entwicklung bis zur Ablösung oder Stilllegung (EOL: end of life) dargestellt. Die linke Seite des Diagramms unterscheidet die verschiedenen Entwicklungsphasen, die Sie schon im Zusammenhang mit dem Wasserfallmodell kennengelernt haben. Die rechte Säule zeigt das 5-E-Modell des Softwarelebenszyklus, bei dem die folgenden fünf Phasen unterschieden werden: 1. Entstehung 2. Entwicklung 3. Evolution 4. Erhaltung 5. Entsorgung Kapitel 1

11 Entstehungs- und Entwicklungsphase Der Fokus des Softwareengineering richtet sich traditionell auf die Planung und die Neuentwicklung von Software, also auf die Entstehungs- und Entwicklungsphase des Lebenszyklus. Hierfür wurden zahlreiche Vorgehens- und Entwicklungsmodelle konzipiert. Hier begegnen uns neben dem klassischen Wasserfallmodell u. a. das Spiralmodell, das V- Modell, Prototyping, das iterative Modell (Jacobson), der Rational Unified Process (RUP von IBM) und die agile SW-Entwicklung als mögliche Vorgehensmodelle der Softwareentwicklung Evolutionsphase Nach der Übergabe (Freigabe) oder Auslieferung eines SW-Produkts beginnt die Phase des Betriebes, der Wartung und der Instandhaltung. Die Auslieferung bzw. Übergabe (Abnahme) eines Softwareprodukts stellt im Lebenszyklus eine Zäsur dar. Fehler, die nach diesem Zeitpunkt auftreten, müssen im Rahmen der Wartung behoben werden. Sie verursachen nicht nur hohe Wartungskosten, sie haben in der Regel auch erhebliche Konsequenzen für Haftungsansprüche und verursachen unter Umständen hohe Ausfallkosten. In dieser Phase entsteht Korrektur- und Änderungsbedarf, der je nach Softwarequalität erheblich sein kann. Der Korrektur- oder Änderungsbedarf nach Auslieferung führt dazu, dass die Phasen Spezifikation, Design, Implementierung und Test während der Betriebsphase wiederholt durchlaufen werden (müssen), sodass der Lebenslauf einer Software nicht als geradliniger Lebenslauf, sondern als Zyklus aufgefasst wird, so wie er durch das oben dargestellte Lebenszyklusmodell charakterisiert wird. Da eingebettete Systeme (definitionsgemäß) in eine Organisation eingebettet sind, erfordern diese Prozesse laufende, evtl. zeitraubende Rückkopplungen (feed-backs) der Kommunikation und der Konsultation, nicht nur zwischen verschiedenen Ebenen der Aufbauorganisation (z. B. Management, betroffene Anwender, Benutzer, SW-Entwickler, Personalvertretung), sondern evtl. auch mit Kunden und Lieferanten. Die Evolutionsphase bietet insbesondere zahlreiche Möglichkeiten, die Software zu perfektionieren und zu verbessern. Hierzu gehören nicht nur die Korrektur der Restfehler, die erst beim Betrieb entdeckt werden, sondern auch vielfältige Möglichkeiten des Software Reengineering. Unter dem Begriff SW-Reengineering werden zahlreiche Maßnahmen zusammengefasst, die in der Literatur ausführlich erörtert werden. Hierzu gehören u. a. die Restrukturierung, Refaktorierung (Refactoring), Bereinigung, Kapselung oder Konvertierung von Software. Bei der Refaktorierung wird das bestehende Design eines Softwaresystems verändert. Es werden keine zusätzlichen Funktionen hinzugefügt oder verändert, sondern es wird nur das interne Design des Softwarecodes verbessert. In diesem Zusammenhang sollte erwähnt werden, dass im Gegensatz zu der umfangreichen Literatur, die zum Thema Reengineering existiert, umfassende Reengineering Maßnahmen in der Praxis eher selten durchgeführt werden. Die wichtigsten Maßnahmen der Evolutionsphase sind Projekte zu laufenden Anpassungen, Korrekturen und Fortschreibungen des Fachkonzepts aufgrund veränderter wirtschaftlicher und technischer Rahmenbedingungen (vgl. E-Typ-Systeme im folgenden Kapitel 1

12 11 Kapitel). Ähnlich wie bei der Entwicklungsphase, werden auch hier die verschiedenen Entwicklungsschritte so wie am Prototyp des Wasserfallmodells dargestellt zyklisch durchlaufen. Wichtig ist in diesem Zusammenhang die Fortschreibung und Implementierung des weiterentwickelten Fachkonzepts, solange dies mit vertretbarem Aufwand möglich ist Erhaltungsphase In dieser Phase findet nur noch eine Instandhaltung mit geringen Nachbesserungen statt. Mit geringem Aufwand wird versucht, das System am Leben zu erhalten. Das setzt voraus, dass die technische Umgebung für den Betrieb unterstützt wird und Mitarbeiter zur Verfügung stehen, die bereit (und befähigt) sind, das alternde System zu pflegen. Anwender neigen dazu, nicht zuletzt auch aufgrund von Wirtschaftlichkeitsüberlegungen bei Reinvestitionsmaßnahmen, an technologisch und softwaretechnisch veralteten Systemen möglichst lange festzuhalten (vgl. Legacy-Systeme). Ferner macht es die Reengineering- Technik der Kapselung (wrapping) möglich, solche Systeme in einer modernen Softwareumgebung mit Web-Architektur weiter zu betreiben und zu nutzen. Damit kann man die Lebensdauer solcher Systeme nochmals verlängern. Der Betrieb von Legacy-Systemen sowie Reengineering-Aktivitäten tragen dazu bei, dass die Lebensdauer von Softwaresystemen, die bei Beginn der Systementwicklung nur schwer abschätzbar ist, häufig unterschätzt wird. Ist die tatsächliche Lebensdauer länger als geplant, hat dies zur Folge, dass auch der hierbei anfallende Aufwand für Wartung und Pflege, der das 3- bis 4-fache des ursprünglichen Entwicklungsaufwands betragen kann, in der Gesamtsumme höher ausfällt und daher ebenfalls unterschätzt wird Entsorgungsphase In den meisten Fällen trägt das Auftreten externer technischer, wirtschaftlicher oder organisatorischer Ereignisse (z. B. Wechsel der Systemumgebung, Beschaffung integrierter Softwaresysteme, Datumswende im Jahr 2000, EURO-Einführung usw.) dazu bei, eine veraltete Software herunterfahren, ablösen und entsorgen zu müssen. Auch in der Phase des EOL sind zahlreiche Aktivitäten erforderlich. Hierzu gehören die Kommunikation mit den Benutzern, die Datensicherung, die Deinstallation und die Dokumentation der Archivierung. In manchen Fällen muss das alte System während einer Übergangsphase im Hintergrund noch verfügbar oder reaktivierbar sein. Eine Reaktivierung kann beispielsweise zur Beweissicherung bei rechtlichen Auseinandersetzungen, sowie bei Aktivitäten der Innenrevision, der Wirtschaftsprüfung oder der finanzamtlichen Betriebsprüfung erforderlich sein. Zur Archivierung von alten Releases gehören der Quellcode, die Werkzeuge, das Betriebssystem, die Compiler, die Build-Skripte (zur Systemgenerierung des Maschinencodes), die Dokumentation und in Ausnahmefällen sogar Teile der Hardware. Der ISO/IEC Standard schlägt für die Abkündigung und die Außerbetriebnahme einer Software folgende Maßnahmen vor: Außerbetriebnahmeplan für Zeiträume des vollen oder teilweisen Supports, Archivierung der Software (inkl. Dokumentation), Kapitel 1

13 12 Verantwortung für künftige Supportanfragen, evtl. Übergang zu einem neuen System, Zugriffe auf die archivierte Software, Absichtserklärung, Abkündigung, Außerbetriebnahme der Software, Archivierung der Baseline. Die Betrachtung der Wartung unter dem Aspekt des Lebenszyklus einer Software macht den zyklischen Prozess der Entstehung, der Entwicklung, der Evolution, der Erhaltung und der Entsorgung deutlich, bei dem die Bedeutung der Evolution und der Erhaltung (d. h. der Maintenance bzw. der Wartung im weiteren Sinne) meist unterschätzt wird. 1.4 Softwareproduktmanagement Sinn und Zweck der Softwareentwicklung kann es nicht sein, laufend neue Anwendungssysteme zu entwickeln, bloß weil sich die technischen und wirtschaftlichen Rahmenbedingungen laufend ändern. In vielen Fällen ist es vernünftiger, die genutzten Systeme zu erhalten, zu pflegen und weiterzuentwickeln, so wie es im Modell des Softwarelebenszyklus beschrieben wird. Dies ändert auch die Anforderungen an das Softwaremanagement. Softwarewicklungsprojekte sind für einmalige, befristete und eindeutig abgrenzbare Vorhaben mit bekannter vorgegebener Zielsetzung konzipiert. Aus dem SW-Projektmanagement entwickelt sich im Verlauf der Softwareevolution eine Daueraufgabe. Das SW-Projektmanagement mutiert zum permanenten Lebenszyklusmanagement eines Softwareprodukts, dem sog. Softwareproduktmanagement. Das Produktmanagement muss während des Lebenszyklus auch das Management der laufenden Erhaltungsmaßnahmen, der Weiterentwicklung und der Weiterentwicklungsprojekte übernehmen. In dieser permanenten Rolle ist das Produktmanagement auch für das Management von SW-Folgeprojekten verantwortlich und fungiert als Projekt der Projekte. Zur Unterstützung der Lebenszyklen der Softwareevolution muss das Produktmanagement auch das Konfigurationsmanagement übernehmen, das im Folgenden noch ausführlicher erörtert wird. Bei der Entwicklung und Wartung kommerzieller, am Markt angebotener Anwendungssoftware wird dem Produktmanagement in der Regel auch die Verantwortung für den Vertrieb, das Marketing und die Kundenbetreuung übertragen. Software Produktmanagement ist ohne Softwareengineering nicht denkbar. Aufgrund der Vielzahl von Koordinationsaufgaben, Funktionen und Verantwortlichkeiten, die das Produktmanagement während der Lebensdauer einer Software übernehmen muss, ist ein umfassendes Softwareengineering erforderlich. SNEED bezeichnet dies als Softwareengineering im großen Stil (vgl. SNEED, H. M. et al. 2005, S. 7), dessen zentrale Rolle sich mit den vier P-Begriffen Kapitel 1

14 13 Prototyp, Produkt, Projekt, Prozess einprägsam charakterisieren lässt Prototypmanagement Das Prototypmanagement konzipiert, steuert und überwacht die Neuentwicklung (Erstentwicklung) von Softwareprodukten, die als SW-Prototypen aufgefasst werden können Produktmanagement Das Produktmanagement ist verantwortlich für das gesamte Softwareprodukt, das nicht nur aus Programmen besteht, sondern zu dem auch zahlreiche Artefakte wie Dokumente, Daten, Testfälle usw. gehören Projektmanagement Das Projektmanagement übernimmt die Verantwortung für alle während der Softwareevolution anfallenden Projekte. Es sind dies insbesondere folgende Projekttypen: Entwicklungsprojekte, Weiterentwicklungsprojekte, Systemerhaltungsprojekte Prozessmanagement Im Mittelpunk des Softwareengineering, des Software Reengineering und der Softwarewartung stehen nicht nur Projekte, sondern auch Routineabläufe, die als Geschäftsprozesse der Wartungsphase definiert werden können. Das Produktmanagement übernimmt hierbei die Verantwortung für das gesamte Prozessmanagement, also für die Gestaltung und das Controlling der Wartungsprozesse. Kapitel 1

15 14 Oft ist es wirtschaftlicher, nicht laufend neue Systeme zu entwickeln, sondern die vorhandene Software möglichst lange zu erhalten und zu pflegen. Der Aufwand für Evolution und Erhaltung erhält bei der Beachtung des Lebenszyklus eine größere wirtschaftliche Bedeutung. Die Methoden und das Management der Softwareentwicklung verlagern sich auf die methodische Unterstützung und das Management des gesamten Lebenszyklus und damit auf das sog. Produktmanagement. Die erweiterten Aufgaben des Produktmanagements, das auch das Management der Wartung umfasst, lassen sich mit den vier P-Begriffen charakterisieren: Management von Prototyp, Produkt, Projekt und Prozess. K [1] Wie unterscheidet sich Software von anderen, materiellen Produkten? K [2] Erläutern Sie im Zusammenhang mit der Softwareentwicklung und -wartung den Begriff Artefakt. K [3] Nennen Sie die fünf E-Begriffe, mit denen sich der Lebenszyklus von Softwaresystemen kurz charakterisieren lässt. K [4] Was versteht man unter der Refaktorierung (Refactoring) von Software? K [5] Beschreiben Sie den Unterschied zwischen den Aufgaben des Managements bei der Softwareentwicklung und beim Softwareproduktmanagement. K [6] Nennen Sie einige der notwendigen Maßnahmen, wenn Sie am Ende des Lebenszyklus (EOL) eine Software stilllegen und entsorgen wollen. K [7] Welchen Phasen des Softwarelebenszyklus lassen sich die Begriffe Softwareengineering und Software Reengineering am besten zuordnen? Kapitel 1

16 90 8 Werkzeuge zur Unterstützung der Softwarewartung Softwaresysteme, die den kompletten Wartungsprozess abdecken, sind rar und Gegenstand von Forschungsprojekten. Im Einsatz befinden sich vorwiegend Einzelsysteme zur Versionsverwaltung, Testwerkzeuge zur Unterstützung oder Automatisierung der Programmtests sowie Bug-Tracking bzw. Trouble-Ticket-Systeme, die nicht nur den Wartungsprozess begleiten und dokumentieren, sondern schon im Vorfeld der Wartungsmaßnahmen den Support unterstützen. Diese Werkzeuge wollen wir in den folgenden Abschnitten etwas näher betrachten. 8.1 Versionsverwaltungssysteme Für die Verwaltung der Artefakte der Softwareentwicklung und Softwarewartung sollte ein Versionsverwaltungssystem (Version Control System, VCS) zur Verfügung stehen. Dieses wird zur Erfassung der Erstellung und Änderung von Dokumenten oder Dateien eingesetzt. Alle Versionen eines Dokuments werden in einem Archiv (Repository) mit einem Zeitstempel und einer Benutzerkennung abgelegt, sodass Änderungen später wieder rekonstruiert werden können (Traceability). Die Systeme arbeiten hierbei inkrementell, d. h., es werden jeweils nur die Änderungen und nicht die gesamten versionierten Dokumente neu gespeichert. Versionsverwaltungssysteme werden nicht nur zur Verwaltung von Softwareprodukten und Artefakten, sondern auch bei Büroanwendungen und Content Management Systemen eingesetzt (vgl. z. B. Wikipedia). Sie müssen, falls sie im Unternehmen in dieser Verwendung schon vorhanden sind, für die Softwarewartung nicht gesondert beschafft werden. Grundsätzlich sollten bei Verwendung eines VCS zur Unterstützung der Softwarewartung alle Dateien (Artefakte), aber auch alle Informationselemente unterhalb der Dateiebene unter eine Versionskontrolle gestellt werden. Dies gilt beispielsweise für Konzepte, Entwurfsdokumentationen, Testfälle, Test- und Steuerdaten, Build-Produkte, Datendefinitionen der Datenbanken. Zu den wichtigsten Funktionen eines Version Control System (VCS) gehören die Protokollierung der Änderungen, Wiederherstellung von alten Ständen einzelner Dateien, Archivierung der einzelnen Stände eines Projektes, Koordinierung des gemeinsamen Zugriffs mehrerer Entwickler auf eine Datei, gleichzeitige Entwicklung mehrerer Entwicklungszweige (Branches) eines Projektes. Kapitel 8

17 91 Vorteilhaft ist die Verwaltung hierarchischer Beziehungen (Use-Beziehungen), um Zusammenhänge zwischen den Dokumenten herzustellen und Hierarchien zu erkennen. Ferner muss die Möglichkeit der Identifikation der Autoren (audit trail) geboten werden. Die Dokumentbezeichnungen sollten auch für Zweige der Weiterentwicklung frei wählbar sein und die Möglichkeit besitzen, Produktvarianten abzubilden. Den Vorgang, bei dem ein Dokument als Arbeitsdatei zur Bearbeitung aus dem Repository kopiert wird, bezeichnet man als Check-out, den umgekehrten Vorgang als Check-in. Zur Steuerung dieser Vorgänge gibt es unterschiedliche Organisationsprinzipien für die Versionsverwaltung, für die üblicherweise Datenbanksysteme genutzt werden. Lokale Versionsverwaltung Die Dokumente werden lokal gespeichert und es wird, wie bei Büroanwendungen üblich, jeweils nur eine lokal verfügbare Datei versioniert. Zentrale Versionsverwaltung Diese Verwaltung ist als Client-Server-System aufgebaut. Zugriffe auf das Repository können auch über das Netz erfolgen. Die Versionsgeschichte ist hierbei im Repository auf dem Server hinterlegt. Eine Rechteverwaltung sorgt dafür, dass nur berechtigte Personen neue Versionen im Archiv abholen und ablegen können. Verteilte Versionsverwaltung Die verteilte Versionsverwaltung verwendet kein zentrales Repository. Jeder, der an dem verwalteten Projekt arbeitet, hat ein eigenes Repository und kann dieses mit jedem beliebigen anderen Repository abgleichen. Die Versionsgeschichte ist dadurch verteilt. Änderungen können lokal verfolgt werden, ohne eine Verbindung zu einem Server aufbauen zu müssen. Im Gegensatz zur zentralen Versionsverwaltung kommt es nicht zu einem Konflikt, wenn mehrere Benutzer dieselbe Version einer Datei bearbeiten und ändern. Die sich widersprechenden Versionen existieren zunächst parallel und können weiter geändert werden. Sie können später automatisch oder manuell durch einen Integrator in einer neuen Version zusammengeführt werden. Bei der Nutzung zentraler oder verteilter Versionssysteme stehen zwei alternative Arbeitsweisen zur Verfügung: Lock Modify Write und Lock Modify Merge. Lock Modify Write Eine dieser Arbeitsweisen bezeichnet man als Lock Modify Unlock oder Lock Modify Write. Zu benutzende Dateien müssen vor einer Änderung durch den Benutzer gesperrt und nach Abschluss der Änderung zurückgeschrieben und/oder wieder freigegeben werden. Während sie gesperrt sind, verhindert das System Änderungen durch andere Benutzer. Der Vorteil dieses Konzeptes liegt darin, dass kein Zusammenführen von Versionen erforderlich ist, da immer nur ein Entwickler die Datei exklusiv bearbeiten kann. Nachteilig kann sein, dass bei zahlreichen Benutzern längere Wartezeiten entstehen, wenn Dokumente durch Bearbeiter längere Zeit gesperrt werden. Kapitel 8

18 92 Lock Modify Merge Ein Versionssystem, das nach diese Arbeitsweise arbeitet, lässt an einer Datei gleichzeitige Änderungen durch mehrere Benutzer zu. Anschließend werden diese Änderungen automatisch oder manuell durch einen Integrator zusammengeführt (Merge). Die Arbeit der Entwickler wird wesentlich erleichtert. Änderungen müssen nicht im Voraus angekündigt werden, Dateien werden nicht blockiert. Es können mehrere Entwickler auch räumlich getrennt effizient zusammenarbeiten, wie es beispielsweise bei Open-Source-Projekten häufig der Fall ist. Ein direkter Kontakt zwischen den Entwicklern ist nicht erforderlich. Bei zahlreichen Änderungen kann automatisches Zusammenführen problematisch sein, wenn von einer Ausgangsversion synchron zwei Tochterversionen erzeugt wurden. Für Quellcode-Dateien wurden Strategien entwickelt, die man als Syntactic Merge und als Semantic Merge bezeichnet. Im ersten Fall werden syntaktische Fehler angezeigt. Im zweiten Fall werden Situationen erkannt, in denen das Verhalten des Ergebnisses in Widerspruch zu dem Verhalten der Ausgangsversion steht. Für die zentrale und verteilte Administration von Versionsnummern gibt es zahlreiche Open-Source- und proprietäre SW-Werkzeuge. Für die zentrale Verwaltung stehen beispielsweise zur Verfügung: Open-Source-Software wie RCS (Revision Control System), CVS (Current Versions System), Apache Subversion (SVN) Verwaltung oder TortoiseSVN (unter Windows). Als proprietäre Systeme stehen beispielsweise IBM Rational Synergy oder IBM Rational Clear Case zur Verfügung. Für die verteilte Verwaltung werden u. a. das System Git (d. h. Blödmann) zur Versionsverwaltung des Linux-Kernels oder das proprietäre Werkzeug BitKeeper angeboten. Bei den proprietären Lösungen wird meist versucht, das Versionsmanagement mit dem Konfigurationsmanagement zu kombinieren oder in ein solches System zu integrieren. Die wichtigsten Werkzeuge zur Unterstützung der Wartung sind Testwerkzeuge, Systeme zur Versionsverwaltung und Bug-Tracking bzw. Trouble-Ticket-Systeme. Versionsverwaltungssysteme unterstützen die Verwaltung von Versionen aller Artefakte der Softwareentwicklung. Versionsverwaltungen übernehmen insbesondere Funktionen wie die Protokollierung und Wiederherstellung bei Änderungen, die Archivierung sowie die Koordination der Zugriffe bei gemeinsamer Nutzung. Mit der lokalen, der zentralen und der verteilten Versionsverwaltung gibt es drei verschieden Arbeitsweisen dieser Systeme, wobei die verteilte Verwaltung hinsichtlich der Kooperation mehrerer Entwickler die größte Flexibilität bietet und heute in vielen Open-Source-Projekten der Softwareentwicklung genutzt wird. 8.2 Testwerkzeuge Keine Aktivität der Softwarewartung ist mehr von Werkzeugen abhängig als das Testen. Innerhalb der möglichen Test- und Prüfverfahren sind Testwerkzeuge, insbesondere bei der Durchführung von Regressionstests, unentbehrlich. Bei häufiger Wiederholung der Tests ist eine manuelle Vorbereitung, Durchführung und Auswertung der Testergebnisse nicht mehr zu bewältigen, sodass man bei Regressionstests den größten Nutzen mit dem Einsatz von Testwerkzeugen und einer Testautomatisierung erzielen Kapitel 8

19 93 kann. Häufig sind umfangreiche Regressionstests erst mit dem Einsatz von Werkzeugen praktisch sinnvoll durchführbar. Prinzipiell sind folgende Aktivitäten, durch Werkzeuge unterstützt, automatisierbar: P Testfallerstellung mit Testdatenerstellung und Testskripterstellung, P Testdurchführung, P Testauswertung, P Testdokumentation, P Testadministration. Der kritische Punkt einer Automatisierung ist die Erstellung eines Testskripts. Hierbei muss die in einer höhersprachigen Beschreibung formulierte Spezifikation des Testfalls programmiert werden, z. B. mit hierfür geeigneten Skriptsprachen (Tcl, Perl, Phyton), mit imperativen Sprachen oder mit objektorientierten Ansätzen (JUnit). Für die (automatisierte) Durchführung von Regressionstests werden beispielsweise folgende Testwerkzeuge benötigt: Testplaneditor: In der Regel ein XML-fähiger Editor. Testfalleditor: Für die Bearbeitung von XSL- und XML-Dokumenten. Testfalldatenbank: Zur Aufbewahrung der Testfälle, der Codes, der Dokumentation und anderer Artefakte. Die Datenbank sollte die Verwaltung komplexer XML-Dokumente ermöglichen. Testdateneditor: Für die Verwaltung und Generierung komplexer Datensätze. Testtreiber: Um Klassen und Komponenten über ihre interne Systemschnittstelle oder um bei Dialogsystemen mit Systemtreibern über externe Schnittstellen die Benutzerschnittstellen (Benutzeroberflächen) zu testen. Werkzeuge für die Datenprüfung: Um Veränderungen und Abweichungen der Testdaten von den Sollwerten zu prüfen. Dynamische Analysatoren: Um die Codeüberdeckung zu messen oder Testfälle durch den Code zu verfolgen. Statische Analysatoren: Um Codeanalysen durchzuführen, Testfälle zu ermitteln und Komplexitätsmetriken zu ermitteln. Auf dem Softwaremarkt werden zahlreiche Testwerkzeuge angeboten. Gute Marktübersichten mit Bewertungen finden Sie beispielsweise unter: und Man sollte jedoch beachten, dass viele Tests sich nicht automatisieren lassen und in zeitraubender Arbeit manuell durchgeführt und überprüft werden müssen. Darüber hinaus sollte man in Erinnerung behalten, dass die Nutzung von Testwerkzeugen auch die hierfür entsprechende Qualifikation und Erfahrung des Anwenders erfordert, um damit die gewünschten Ergebnisse zu erzielen. Gerade in diesem komplexen Bereich des Softwareengineering gilt der bekannte Spruch: "A fool with a tool is still a fool." (Grady Booch, Entwickler der UML). Kapitel 8

20 94 Testwerkzeuge sollten alle Aktivitäten des Testens unterstützen, insbesondere die Testfallerstellung, die Testdurchführung, die Auswertung, die Dokumentation und die Testadministration. Alle heute eingesetzten Editor-Werkzeuge sollten in der Lage sein, XML- und XSL-Dokumente zu verwalten und die Automatisierung bei der Codeanalyse sowie bei der Erstellung und Auswertung der Tests, insbesondere der Regressionstests, zu ermöglichen. 8.3 Bug-Tracking-Systeme Aufgaben Bug-Tracking-Systeme, oder kurz Bugtracker, dienen der Verfolgung von Fehlern, Störungen und Problemen in Softwaresystemen. Es handelt sich hierbei um Fallbearbeitungssysteme (Trouble-Ticket-Systeme) für die Softwareentwicklung, die als Werkzeug eingesetzt werden, um Programmfehler zu erfassen und zu dokumentieren. Mit ihnen werden oft interaktiv und im Intranet über ein Unternehmensportal auch Zustands- oder Feature-Berichte geschrieben. Das zentrale Element dieser Systeme sind Trouble-Tickets (TT), die genau einen Störfall beschreiben. Aufgabe eines Trouble-Tickets ist es, den Lebenszyklus einer Störung von der Entdeckung über die Eingrenzung bis hin zur Lösung oder Beseitigung zu dokumentieren und zu Auswertungszwecken zur Verfügung zu stellen. Die Bezeichnung Trouble-Ticket (TT) kann als Sammelbegriff für Software Problem Report (SPR) und Modification Request (MR) verwendet werden. Neben Programmfehlern können Bugtracker auch andere Verbesserungsvorschläge und Wünsche der Nutzer oder allgemeine Vorgänge aufnehmen. Man spricht in diesem Fall von Issues (Angelegenheiten, Vorgänge) und von Issue-Tracking-Systemen, da sich dieser Ausdruck nicht nur auf Programmfehler beschränkt. In der Regel werden die Berichte elektronisch erfasst. In der Praxis geschieht dies meist mittels sog. User-Helpdesk-Systeme (UHD). Diese bieten spezielle Funktionen, die die Kommunikation und Problemlösung zwischen Anwendern und der Supportorganisation erleichtern, beispielsweise die Bereitstellung eines Web-Frontends, das Suchen ähnlicher Probleme und Lösungen sowie den Informationsaustausch und Benachrichtigungen per Nutzung und Beteiligte Bug-Tracking-Systeme dienen der Kommunikation und können von Benutzern, Testern, Entwicklern und dem Management genutzt werden. Benutzern kann dabei entweder allein lesender Zugriff auf die Bug-Tracking-Datenbank gegeben werden, sodass sie nur feststellen können, ob ein bestimmtes Fehlerverhalten bereits bekannt ist und wie weit dessen Behebung fortgeschritten ist, oder auch Kapitel 8