Software-Qualität (Teil 3)

„Software Is Eating the World“, schrieb Marc Andreessen in einem 2011 im Wall Street Journal veröffentlichten Artikel (zu dt. „Warum Software die Welt verschlingt) und heute ist es tatsächlich so, dass wir von Software vollkommen abhängig sind. Mit den Jahren wurde sie für jedes Produkt und jede Dienstleistung immer wichtiger, hat Unternehmen aus allen Branchen verändert und „Software-Firmen“ aus ihnen gemacht. Diese Veränderungen bringen ganze Märkte durcheinander und bieten neue Chancen. Gleichzeitig werden viele marktführende Unternehmen in Frage gestellt, diese haben oft große Mühe mit der Entwicklung Schritt zu halten, so dass ihre Existenz in Bedrängnis gebracht wird. 

Software ist für Unternehmen immer mehr zu einem strategischen Asset geworden, unabhängig ihrer Größe oder ihres Zielmarktes. Die eigentliche Herausforderung dabei ist das Wissen um den wahren Wert und die damit einhergehenden Kosten (z.B. für Wartung, Weiterentwicklung usw.). Dies ist keine leichte Aufgabe und erfordert besondere Fähigkeiten, die über die eines Entwicklers oder Project Managers hinausgehen. Diese Vorgänge sind schwer zu vereinheitlichen und eng mit der Softwarequalitätsforschung verbunden, die von den großen Softwareunternehmen (wie beispielsweise IBM, Microsoft oder Google) sowie von Forschungseinrichtungen in aller Welt vorangebracht wird. Einige Anwendungsbereiche sind:

• die Bewertung des Preis-Leistungs-Verhältnisses von Systemen, die von einem externen Anbieter erworben werden;
• die Bewertung des Preis-Leistungs-Verhältnisses von Systemen, die intern entwickelt werden;
• Entscheidungshilfe bei der Frage, ob interne oder externe Entwicklungen zu bevorzugen sind; 
• Unterstützung bei der Kostenschätzung für die Wartung eines Produkts (sei es intern oder extern entwickelt worden);
• Kundennachweis zur Qualität der verkauften Systeme;
• …   

Die Bewertung ist nicht allein eine technische Analyse eines Softwaresystems, sondern beinhaltet unter anderem auch eine mehr oder weniger detaillierte Untersuchung des Kontextes, in dem dieses System entwickelt wurde, die damit einhergehenden technischen und geschäftlichen Entscheidungen, die Unternehmensstrategie, wie auch die zeitliche Weiterentwicklung des Systems. All diese Aspekte ergeben ein umfassenderes Bild, als es durch die alleinige Softwareanalyse möglich wäre.

Wie diese Art von Analyse durchgeführt wird, erklären wir anhand des Beispiels von Microtec GmbH, einem Unternehmen mit Sitz in Brixen, das weltweit Marktführer in der Entwicklung von Systemen für die Automatisierung von Sägewerken ist und sowohl die Maschinen als auch die zugehörigen Softwaresysteme selbst entwickelt. Das Unternehmen hatte es sich zum Ziel gemacht, das Qualitätsniveau seines Softwaresystems so zu verbessern, dass die verkauften Softwaresysteme einerseits immer gewartet, aber auch weiterentwickelt werden konnten. Um diese Zielvorgabe zu erreichen, war es notwendig ein umfassenderes Bild des Betriebes zu erhalten. Hierfür wurden der Produktionsprozess und die Software selbst analysiert, wobei verschiedene Fachleute des Unternehmens mit Unterstützung der Geschäftsleitung einbezogen wurden:

• Management: CEO, CTO, Project Manager
• Entwicklungsteam: Teamleiter, Entwickler

Die direkte Beteiligung des CEO am Projekt hat dazu beigetragen die Ziele auf hoher Ebene, die Produkte und die zu berücksichtigenden Qualitätskriterien eindeutig ermitteln zu können. Insbesondere wurde beschlossen, den Schwerpunkt der Analyse auf die Wartbarkeit der Systeme zu legen, sowohl im Hinblick auf die Fähigkeit, gegebenenfalls auftretende Fehler im System auszumerzen als auch auf die Möglichkeit, in Zukunft weitere Funktionen zu integrieren.

Nachdem dieser erste Teil definiert war, wurden gemeinsam mit dem CTO technischere Aspekte im Detail untersucht, darunter die Organisation der Entwicklungsteams auf Unternehmensebene, die Organisation der Programmierung, die verwendeten Instrumente, die Kommunikation und die Entscheidungsprozesse, an denen mehrere Teams beteiligt waren. Darüber hinaus wurden die charakteristischen Aspekte der Entwicklungsteams an den verschiedenen Standorten des Unternehmens in der ganzen Welt und deren Verwaltung analysiert. In dieser Phase konnten einerseits die Kriterien des Produktionsprozesses der Software, andererseits die allgemeine Organisation und insbesondere die Entwicklung des Programmiercodes über verschiedene Anwendungen hinweg unter die Lupe genommen werden.

Anschließend wurden die Product Manager, die sich um die Verwaltung der verschiedenen Produkte kümmern, berücksichtigt. Die vom Unternehmen entwickelten Systeme sind sehr komplex und werden in Geräte und Systeme integriert, die bei Kunden bereits in Betrieb sind. Um das System an die spezifischen Eigenschaften von Anlagen (z.B. die bearbeiteten Holzsorten, die verschiedenen Maschinenfunktionen, usw.) anzupassen, ist eine vorbereitende Phase zur Integration und Konfiguration erforderlich. Anlagenspezifische Integrationen und Anpassungen müssen unter Berücksichtigung der allgemeinen Entwicklung der Produkte des Unternehmens implementiert werden, um die Kompatibilität mit zukünftigen Versionen und Aktualisierungen zu gewährleisten. Die Integrationen und die spezifischen Personalisierungen müssen in jede einzelne Anlage implementiert werden, wobei die allgemeine Erweiterbarkeit der Firmenprodukte zu berücksichtigen ist, damit die Systeme mit künftigen Versionen kompatibel sind und jederzeit aktualisiert werden können. Wie mit möglichen Konflikten bei spezifischen Änderungen und jenen des Produkts selbst umgegangen wird, ist für die Wartbarkeit der einzelnen Anlagen und der Produkte entscheidend. Aus diesem Grund wurden die Aspekte des Anforderungsmanagement und des Kundenfeedbacks mit den einzelnen Project Managern untersucht.

Auf Führungsebene hingegen wurden Aspekte des angewandten Entwicklungsprozesses, des Anforderungsmanagements, der Anpassungsverwaltung und des Personalmanagements (insbesondere in Bezug auf die Weiterbildung neuer Teammitglieder) analysiert. Außerdem wurde die Systemarchitektur auf hoher Ebene sowie die vorhandene Dokumentation samt Verwaltungstätigkeiten auf den Prüfstand gestellt.

Schließlich wurden die Entwickler eingebunden und die Analyse auf die Organisation der Programmierung, die Systemarchitektur und die angewandten Entwicklungsmethoden konzentriert. Des Weiteren wurden Fragen rund um das Schreiben von Quellcodes bzw. der Programmiersprache mit anschließender Diagnose (Debug) und Testung miteinbezogen.

Nachdem alle Informationen zusammengetragen waren, wurde die Phase der Angleichung eingeleitet, um zu prüfen, ob die von den verschiedenen Mitarbeitern als relevant eingestuften Qualitätsparameter einheitlich waren. In der Praxis wird geprüft, ob und wie die von den Entwicklungsteams täglich durchgeführten Aktivitäten in die von der Unternehmensleitung vorgegebene Richtung gehen und ob die Qualitätswahrnehmung tatsächlich dieselbe ist. Bei dieser Angleichung müssen auch die Prioritäten berücksichtigt werden, die den verschiedenen Qualitätsparametern von den verschiedenen Unternehmensvertretern zugewiesen werden. Eine perfekte Übereinstimmung ermöglicht es dem Unternehmen, seine Ziele effektiv zu verfolgen und im Falle von Problemen rasch Korrekturmaßnahmen einzuleiten. Abweichungen hingegen erfordern eine sorgfältige Analyse der Ursachen, die in der Regel auf Schwierigkeiten in der internen Kommunikation zurückzuführen sind, welche sich dann in der Software widerspiegeln und nicht mit den Vorgaben der Unternehmensleitung übereinstimmen. 

In unserem Beispiel waren die verschiedenen Abteilungen im Unternehmen aufeinander abgestimmt, aber aufgrund technischer Grenzen, die sich auftaten, weil hohe Rechenleistungen erforderlich waren, wurde ein anderer Weg eingeschlagen. Dies geschah, weil die Optimierungen, die erforderlich waren, um die gewünschte Leistung zu erreichen, eine sehr komplexe Strukturierung des Quellcodes bzw. der Programmiersprache erforderten, was seine Lesbarkeit und Wartbarkeit beeinträchtigten. Das Bewusstsein für die unumgänglichen Kompromisse, die beim Ausgleich der Anforderungen und der verschiedenen Qualitätsparameter mit den technischen Voraussetzungen zu erreichen sind, ist ein grundlegender Aspekt bei der Bewertung eines Softwaresystems und der Fähigkeiten des Unternehmens, dessen Weiterentwicklung zu unterstützen.

Nachdem dieser erste Teil der Analyse beendet war, konnte mit der eigentlichen Programmierung begonnen werden. Die Analyse hat sich über die gesamte Evolution der Produkte erstreckt, soweit es die Datenlage zuließ. Tatsächlich ist die zeitliche Evolution von Quellcodes bzw. der Programmiersprache in der Lage, ein klares Bild des Zustandes einer Software zu zeichnen. Zudem kann man erkennen, ob ein Unternehmen mit  der Komplexität, welche im Laufe der Zeit aufgrund neu eingeführter Funktionen steigt, umzugehen kann. Diese Analyse stützt sich auf drei Aspekte:

1. Komplexität
2. Verständlichkeit
3. Wartbarkeit

Mit mehreren Messinstrumenten wurde eine große Anzahl von Daten erhoben, die zur Bewertung der drei ermittelten Aspekte herangezogen wurden. In diesem Fall wurde festgestellt, dass einige Produkte im Laufe der Jahre verschiedene betriebsinterne Umstrukturierungen erfahren hatten, mit denen der Qualitätsverlust trotz des Anstiegs an Funktionen und der Dimension der Programmierung aufgehalten werden konnte. Dank dieser Umstrukturierungsmaßnahmen konnte das Unternehmen seine Anstrengungen auf die Weiterentwicklung des Produkts konzentrieren und ohne Ausfallzeiten in der Entwicklung weitere Funktionen hinzufügen.

Mit der Analyse der Weiterentwicklung konnten die kritischen Module ausfindig gemacht werden und Verbesserungen auf ein spezifisches Programmierungssegment beschränkt werden, was den Nutzen maximieren und die zugehörigen Kosten senken konnte. Darüber hinaus war es möglich, die Entwicklung verschiedener Produkte zu vergleichen, um zu verstehen, ob verschiedene Teams Produkte unterschiedlich behandelten. Diese Analyse diente insbesondere dazu, die von den übernommenen Unternehmen entwickelten Systeme mit den in der Muttergesellschaft entwickelten Systemen zu vergleichen.

Schließlich wurden alle gesammelten Daten zusammengelegt, um zu sehen, inwieweit die vom Management gesetzten hohen Qualitätsziele die Software und ihre Entwicklung beeinflusst haben. Diese Art von Analyse hat dazu beigetragen, ein detailliertes Bild des Softwareentwicklungsstatus der betroffenen Produkte zu erstellen und die verbesserungswürdigen Bereiche auf verschiedenen Ebenen zu ermitteln: Quellcode bzw. Programmiersprache, Architektur, Project Management und Interaktion zwischen den Teams.

Aufgrund der erhaltenen Ergebnisse konnte ein operativer Plan erstellt werden, um die Verbesserungen in den ermittelten Bereichen einzuführen. Im Anschluss daran wurden einige dieser Analysen regelmäßig (alle 6-12 Monate) durchgeführt, um die eingeführten Verbesserungen zu überprüfen.

Dieses Beispiel beschreibt einen der komplexeren Fälle von Qualitätsanalysen bei Software, das uns einen detaillierten Blick auf den Status der Software und die Fähigkeiten eines Unternehmens dargestellt hat. Nicht immer ist eine derart hohe Präzisierung notwendig, vielmehr müssen die Analysen an die gesetzten Ziele angepasst werden.

BIO

Alberto Sillitti ist Mitbegründer und CEO des Centre for Applied Software Engineering GmbH, ein innovatives KMU mit Sitz in Bozen und Genua, das sich mit digitaler Transformation und der Analyse von Softwarequalität befasst. Dazu entwickelt es Bewertungssysteme und bietet Beratung, Audits sowie Schulungen in diesem Sektor an. Bis 2022 war er ordentlicher Professor an der Innopolis University im Fachbereich Informatik und Ingenieurswesen (Russische Föderation), wo er die Forschungstätigkeiten im Bereich Qualitätsevaluierung von Industriesoftware in Zusammenarbeit mit verschiedenen internationalen Konzernen, KMUs und Startups geleitet hat.