Ungefähr zwei Drittel aller Software werden in Entwicklungsabteilungen der Anwenderindustrien entwickelt. Nur ungefähr ein Drittel entwickeln spezialisierte Softwarehäuser. Die Nachfrage nach Software wächst dabei immer noch exponentiell, und eine zunehmende Anzahl von Produkten und Dienstleistungen in allen Branchen sind massgeblich von Software beeinflusst. Dabei ist Software sowohl bei der Datenerfassung, -bearbeitung, -archivierung sowie -manipulation bei der Unterstützung von Geschäftsprozessen im Einsatz als auch als Teil von Produkten in der Industrie und in den Haushalten. Die steigende Nachfrage und die steigende Durchdringung aller Lebensbereiche führen zu einer zunehmenden Abhängigkeit. Software hat ihre Rolle in den letzten Jahren von einer rein unterstützenden zu einer entscheidenden, primären entwickelt.
Trotz steigender Nachfrage, steigender Abhängigkeit und zunehmend entscheidender Rolle der Software verhält sich die Softwareentwicklung laut verschiedenen Studien in einer unvorhersagbaren Weise. Dadurch wird es für das Management geradezu unmöglich, den Entwicklungsstand einer Software zu erkennen. Dies wiederum verunmöglicht jede geschäftliche Entscheidung über den Einsatz, die Weiterentwicklung, den Austausch, die Auslagerung – Investitionsentscheide werden zu einem Ratespiel. Kann der Zeitplan für das nächste Release eingehalten werden?
Welche Qualitätsziele sind akzeptabel bei einem Outsourcing-Entscheid? Sind bei einem lokalen Outsourcing die gleichen Faktoren wichtig wie im Offshoring? Kann die Software an künftige Anforderungen angepasst werden? Und wenn ja, gelingt dies ohne exponentiell steigende Kosten? Sollte die Software einer Renovation unterzogen werden, oder ist die Migration auf eine neue Plattform und Technologie möglich? Graham Booch, Chief Scientist bei
IBM, schätzt die Menge an Legacy Code weltweit auf 800 Milliarden Code-Zeilen, meistens in Cobol geschrieben. Die Wartungskosten übersteigen 80 Prozent der gesamten Softwareentwicklungskosten.
Dazu ein Beispiel: Bei der Freigabe einer neuen Softwareversion muss der Hersteller entscheiden zwischen einer frühen Freigabe oder einer späten. Je früher er die Software freigibt, desto höher ist sein Gewinn durch die Markteinführung. Je später er sie freigibt, desto besser können die Funktionalität und die Qualität sein. Wenn die Testphase zu früh gestoppt wird, steigt sein Risiko, dass eine fehlerhafte Software ausgeliefert wird und die spätere Fehlerbehebung sehr teuer werden kann.
Zu einem bestimmten Zeitpunkt während der Entwicklung werden also unweigerlich zwei Fragen auftauchen: Wie lang wird die Software laufen, bevor substantielle Fehler auftreten? Wie teuer wird es sein, diese Fehler zu beseitigen? Antworten auf diese Fragen sind nur möglich aufgrund von Informationen über Zuverlässigkeit und Wartbarkeit einer Software. Der erreichte Grad an Zuverlässigkeit bestimmt, wie lange getestet und verbessert werden sollte, bevor das Produkt stabil genug ist. Der Grad an Wartbarkeit dagegen zeigt, wie einfach die substantiellen Fehler im Fall ihres Auftretens behoben werden können und wie einfach die Software an zukünftige Anforderungen angepasst werden kann.
Software Risk Assessment
Softwaresysteme bergen Risiken bezüglich der heutigen und zukünftigen Cash-Inflows (Business-Value einer Software) und Cash-Outflows (Kosten). Diese Risiken zu identifizieren und Strategien zur Minderung derselben zu finden, ist von entscheidender Bedeutung für eine Organisation, die den Wert ihres Portfolios maximieren will. Deshalb ist das regelmässige Assessment einer kritischen Software kein Luxus, sondern eine Notwendigkeit. Betrachtet werden dabei die folgenden Aspekte:
- Technische Architektur: Die Architektur beeinflusst den Lebenszyklus eines Systems. Gute Architekturen bilden eine solide Basis für Weiterentwicklungen und verlängern so den Lifecycle.
- Modularität: Eine geeignete Modularisierung hat positive Auswirkungen auf die Wartbarkeit, weil neue Funktionen einfacher implementiert werden können.
- Technische Komplexität: Je komplexer ein System, desto teuer ist sein Unterhalt. Die Komplexität wirkt sich negativ auf die Fehlerbehebung und auf die Weiterentwicklung aus. Kann die Komplexität reduziert werden, hat dies mehrfach positive Auswirkungen auf den Geschäftswert einer Software: Sie kann schneller und einfacher verändert werden und ist weniger anfällig auf Fehler.
- Grösse: Grosse Systeme sind teurer als kleine. Die technische Grösse muss in gesundem Mass zur Funktionalität stehen.
- Testing: Eine gut implementierte Teststrategie erhöht die Wahrscheinlichkeit, dass entscheidende Fehler und Defekte entdeckt werden. Dies führt zu geringeren Gesamtkosten. Wiederholte, automatisierte Tests ermöglichen Messungen, um Verbesserungen im System sichtbar zu machen.
- Performance: Probleme der Leistungsfähigkeit können sich dramatisch auf die Verfügbarkeit eines Systems auswirken. Der effiziente Einsatz von Zeit und Ressourcen ist entscheidend.
- Dokumentation: Eine aktuelle und vollständige Dokumentation verlängert das Leben eines Systems und vereinfacht den Transfer von einem zum anderen Entwickler. Eine unvollständige und falsche Dokumentation wirkt sich kontraproduktiv aus. Allerdings ist es sehr kostspielig, ein System ständig korrekt zu dokumentieren.
- Prozess: Das Management und der Unterhalt von Systemen erfordern nachvollziehbare und dokumentierte Prozesse, damit die entscheidenden Aufgaben sicher erledigt werden.
Wenn es als sinnvoll erscheint, können mit dem Software Risk Assessment mehrere Alternativen betrachtet werden. Diese Alternativen können geschäftliche Szenarien abbilden. Als Resultat wird sichtbar, welche Kosten und Nutzen die unterschiedlichen Szenarien verursachen. Kosten und Nutzen werden in standardisierten betriebswirtschaftlichen Grössen gemessen.
Die vier Schritte des Software Risk Assessment
Schritte eines Software Risk Assessment
Ein Software Risk Assessment wird jeweils auf eines oder mehrere Softwaresysteme angewandt. Es beinhaltet eine vollständige Code-Analyse, die im Durchschnitt Hunderttausende bis Millionen von Code-Zeilen in Cobol, PL/1, Java, C oder anderen Programmiersprachen umfasst. Der Source Code eines Systems, der auch aus einer Kombination von Programmiersprachen bestehen kann, ist die primäre Informationsquelle und bietet zuverlässigste Daten über die Qualität der Software. Sie beinhaltet unter anderem Informationen über Abhängigkeiten zwischen den Komponenten, über die Schnittstellen zwischen Konfigurationen und Software-Packages oder über die Organisation der Information in Datenmodellen.
Zusätzlich zum Source Code werden auch andere Informationen verwendet wie die bestehende Dokumentation zur Beschreibung der Funktionalitäten, der Architektur, der Prozesse und der Logik im System. Oftmals ist aber auch das Wissen verschiedener Menschen wichtig, um ein System vollständig zu begreifen, weshalb auch Workshops mit den Entwicklern und Architekten sowie mit dem Management durchgeführt werden.
Der erste Workshop dient dazu, die Ziele des Assessment genau festzulegen. In weiteren Workshops werden die Architektur, spezielle Konfigurationen, plattformspezifische Komponenten etc. besprochen. Typischerweise sind die folgenden Stakeholder involviert:
- Sponsor: Personen, die das System finanzieren
- Anwendervertreter: Personen, die das System anwenden
- Projektmanager: Projektverantwortlicher, kümmert sich täglich um das zu analysierende System
- Architekten: Personen, die für die Architektur des Systems verantwortlich sind
- Entwicklungsleiter: führt das Entwicklerteam
- Testleiter: führt das Testing-Team
- IT-Auditor: interner oder externer Auditor, verantwortlich für die Qualität
- Spezialisten: beispielsweise Datenbank-, Performance-, Netzwerk-Spezialisten, abhängig vom System, das analysiert wird.
Im nächsten Schritt können die Workshops benutzt werden, um die ersten Resultate zu besprechen und fehlende Informationen zu sammeln. Als besonders wichtig erscheint es, den Sponsor des Projekts einzubeziehen, um die langfristige Absicht zu verstehen. Was ist der erwartete Lebenszeitraum für das System? Welchen geschäftlichen Wert stiftet es, welcher Wert wird erwartet? Mit welchen Kosten wird gerechnet? Welche Entscheidungen stehen an?
Nachdem die Informationen durch die automatisierte Code-Analyse und durch die Workshops und Interviews gesammelt wurden, analysiert ein Team von Experten die Resultate. Mit dieser Experten-Analyse werden die wichtigsten Risiken identifiziert. Daraus wiederum werden die Schlussfolgerungen und Empfehlungen (Strategien zur Minderung der Risiken) hergeleitet.
In der letzten Phase des Software Risk Assessment werden die Resultate schriftlich dokumentiert und dem Kunden rapportiert. Sehr oft ergibt sich während der Präsentation der Resultate eine Diskussion zwischen dem Assessment-Team und dem Projektteam über die nächsten Schritte.
Tools zur automatischen Code-Analyse
Ein wichtiges Element des Software Risk Assessment ist die Code-Analyse. Dazu wurde das Software-Analyse-Toolkit (SAT) entwickelt. Dieses Framework ermöglicht die automatisierte Code-Analyse und liefert verschiedene grafische Resultate. SAT hat eine Vielzahl von Funktionen, beispielsweise, um sich verschiedene Teile der Analyse genauer anzuschauen. Ein anderes Beispiel ist die grafische Darstellung von Abhängigkeiten zwischen verschiedenen Modulen (vgl. Screenshot). Die Struktur des Systems ist als Website abgebildet, mit Links zwischen den verschiedenen Ansichten und direkten Verknüpfungen zwischen den grafischen Elementen und den Kennzahlen der Qualität. Dies hilft bei der Analyse der entdeckten Risiken auch jenen Personen, die sich nicht mit den technischen Spezifikationen der Software befassen möchten.
SAT besteht aus mehreren Tools und Techniken, die wir zusammen als Generic Language Technology bezeichnen. Es ist eine Sammlung von Techniken und Reverse-Engineering-Tools, die geeignet sind, um Software zu analysieren und die technische Qualität zu messen, unabhängig von der Programmiersprache und der Plattform. SAT unterstützt sowohl prozedurale Sprachen wie Cobol, Sprachen der vierten Generation wie Uniface oder Powerbuilder sowie auch objektorientierte Sprachen wie Java und C++. Alle Resultate der automatisierten Analyse werden in einer Datenbank gespeichert.
Die Generic Language Technology erlaubt die Berechnung von Werten und Metriken in standardisierten und individuellen Verfahren. Während des Assessment werden die als wichtig befundenen Werte ausgewählt und grafisch in Beziehung zueinander gesetzt, was die Entdeckung von Extremen erlaubt. Diese Metriken sind wichtig während der Wartungsphase. Sie beeinflussen die Kosten für korrektive Eingriffe und für Erweiterungen. Zudem kann mit dem Assessment auch «toter Code» entdeckt werden sowie duplizierter und geklonter Code. «Toter Code» kann in den meisten Fällen gelöscht werden, was eine einfache, schnelle und kostengünstige Art ist, die Wartungskosten eines Systems zu senken. Duplizierter und geklonter Code ist kostspielig in der Wartung und deshalb Kandidat für ein Re-Engineering.
Benchmarking
Die Resultate jedes Software Risk Assessment werden archiviert, was die Durchführung von Benchmarkings ermöglicht. Die Resultate aus der Analyse des einen Systems können also verglichen werden mit Resultaten anderer Analysen. Die Standard-Metriken für das Benchmarking sind die Anzahl Module eines Systems sowie die Anzahl Code-Zeilen (unterschieden nach Programmiersprachen).
Mit diesem systematischen Vorgehen lässt sich die Qualität einer Software präsentieren. Das Management kann dadurch mit Fakten unterstützt werden bei seinen Entscheidungen bezüglich der Zukunft einer Software. Dies ist nützlich vor und während einer Neuentwicklung und während des Betriebs eines Systems. Das Software Risk Assessment schützt das Management vor teuren Fehlentscheidungen, die ansonsten eher auf Intuition und Erfahrung als auf Fakten basieren. Voraussetzungen für die erfolgreiche Anwendung der hier präsentierten Methode sind Faktoren wie:
- Engagement aller Stakeholders
- Source-Code-Analyse mit reifen, systemübergreifenden Tools
- Verständliche Darstellung der Resultate (je nach Zielgruppe anders, aber immer auf der Basis der gleichen Fakten)
- Vergleich mit anderen Situationen zur Erhöhung der Urteilsfähigkeit (Benchmarking)
- Interpretation der Resultate durch Experten.
Die beschriebene Methode kann durch ein Projektteam im Unternehmen durchgeführt werden, oder diese Aufgabe kann an ein externes Team übergeben werden. Sie sorgt für Transparenz und hilft, eine mögliche Vendor-Lock-Situation zu verhindern. Schliesslich kann das Software Risk Assessment auch substantiellen Input für den IT-Governance-Prozess leisten.
Der Autor
Dr. Hans Sassenburg ist Geschäftsführer der Software Improvement Group (www.sig-ag.ch). Sie erreichen ihn unter h.sassenburg@sig.eu.
