Unternehmen stehen immer wieder vor der Aufgabe, die Qualität von Software-Systemen zu bewerten – und zwar sowohl bei der Auswahl neuer Systeme als auch bei der Re-Evaluierung bereits vorhandener Systeme. Bei dieser Bewertung spielt üblicherweise die fachliche Perspektive eine besonders große Rolle – und damit Aspekte wie der Funktionsumfang und die Benutzerfreundlichkeit des betrachteten Systems. Weitere Aspekte wie Performance, Portabilität, Code-Qualität, Technologiestack, Anpassbarkeit usw. werden oft vernachlässigt – vermutlich deshalb, weil sie den handelnden Personen nicht bekannt oder aber schwierig greifbar und bewertbar sind. Im schlechtesten Fall führt das dazu, dass ein Software-System falsch bewertet wird, was bei der zunehmenden Relevanz von Software sehr teuer oder sogar unternehmenskritisch sein kann. Mit diesem Beitrag wollen wir deshalb die verschiedenen Aspekte von Software-Qualität beleuchten und damit eine Grundlage für eine umfassendere und objektivere Bewertung von Software-Systemen schaffen.

Ein umfassender Blick auf das Thema Software-Qualität lohnt sich insbesondere deshalb, weil dadurch viele spätere Probleme vermieden und Nutzenpotentiale ausgeschöpft werden können. Der Nutzen hoher Software-Qualität besteht in einer hohen Akzeptanz der Benutzer (und damit einem intensiven Einsatz der Software), in geringen Ausfallzeiten und Wartungskosten und damit letztendlich in einer optimalen Unterstützung der damit verbundenen Business-Ziele.

Unsere Definition von "Software-Qualität”

Werden verschiedene Personengruppen dazu befragt, was sie unter Software-Qualität verstehen, geben diese sehr unterschiedliche Antworten. Ein Software-Entwickler beim Hersteller legt Wert auf gute Möglichkeiten, die Software hürdenfrei, kontinuierlich und fehlerfrei weiterzuentwickeln. Ein Software-Entwickler beim System-Integrator dagegen schätzt es, das Standardverhalten des Systems ohne intensive Schulung und möglichst einfach anpassen, also das Customizing vornehmen zu können. Die IT-Kollegen im Rechenzentrumsbetrieb legen den Fokus auf gute Installierbarkeit, Updatefähigkeit und Schonung von Ressourcen. Die Anwender der Software möchten eine fehlerfreie und einfach zu bedienende Software, die tut, was sie erwarten. Und das Business möchte gerne, dass mit derselben Software die gesteckten Business-Ziele erreicht werden.

Alle Stakeholder haben ihren persönlichen Schwerpunkt, was für sie denn genau Software-Qualität bedeutet. Das macht es so schwer, eine einheitliche Sprache und dasselbe Verständnis von Software-Qualität über alle Stakeholdergruppen hinweg zu definieren.

In unserer Business-Welt hat Software niemals einen Selbstzweck, sondern dient – im Sinne eines Werkzeugs – immer einem Business-Ziel. Jeder Aspekt von Software-Qualität muss sich daher diesem Business-Ziel unterordnen. Ebenso wird die Software immer für Anwender geschrieben. Menschen also, die mit Hilfe dieser Software einen Job erledigen, der ebenfalls dem Business-Ziel untergeordnet ist. Daher ist es folgerichtig, die Kriterien für Software-Qualität anhand der Business-Ziele auszurichten. Business-Ziele entsprechen klar formulierten Erwartungen. Deshalb sagen wir:

Je weniger unerwartet sich eine Software verhält, desto größer ist deren Qualität.

In diesem Zusammenhang bevorzugen wir übrigens den Begriff unerwartetes Verhalten oder Software-Anomalie statt des gängigen Wortes Bug. Dadurch wird viel besser ausgedrückt, dass Anwender ein bestimmtes Verhalten erwarten, die Software sich aber anders verhält. Der Blickwinkel ändert sich damit von einem technisch-orientierten hin zu einem anwendungs-orientierten. Weiterhin wird schon sprachlich ein zwar technisch korrektes, aber vom Anwender unerwünschtes oder unerwartetes Verhalten als fehlerhaft klassifiziert.

Ein Beispiel: Es hat sich eingebürgert, dass die abweisende Option eines Dialogs immer links ist: ABBRECHEN links, OK rechts. Rein technisch spricht nichts dagegen, diese beiden Buttons zu vertauschen. Die Anwender würden dies allerdings größtenteils als unerwartet bewerten und somit als einen Fehler. Bis sie sich daran gewöhnt haben, wird die Bediener-Fehlerquote steigen und die Arbeitsgeschwindigkeit sinken. Und somit wird dieses unerwartete Verhalten den Business-Zielen entgegenlaufen. Denn die Software-Qualität wurde auf diese Weise verringert.

Jegliches unerwartetes Verhalten reduziert demzufolge die Software-Qualität.

Die verschiedenen Aspekte von Software-Qualität

Im Folgenden gehen wir auf die verschiedenen Aspekte von Software-Qualität näher ein. Im Endeffekt definiert sich die Software-Qualität durch die Summe dieser (individuell gewichteten) Aspekte.

(1) Funktionsumfang

Der naheliegendste Aspekt ist für die meisten sicher der Funktionsumfang einer Software. Lange Zeit hat man darunter meist den maximal möglichen Funktionsumfang verstanden – dementsprechend waren auch die Auswahlverfahren durch Maximal-Listen geprägt. Zwischenzeitlich hat sich mehr und mehr die Erkenntnis durchgesetzt, dass die “eierlegende Wollmilchsau” nie benötigt wird und ein unnötig hoher Funktionsumfang sich außerdem negativ auf weitere Aspekte der Software-Qualität (wie z.B. Usability, Performance und Wartbarkeit) auswirken kann. Wesentlich sinnvoller ist es deshalb, auf der Grundlage von relevanten Anwendungsfällen die heute und in absehbarer Zukunft tatsächlich benötigten Funktionalitäten zu ermitteln und diese entsprechend ihrer jeweiligen Relevanz zu gewichten. Damit hat man eine gute Grundlage, um den Funktionsumfang einer Software konkret zu bewerten.

(2) Performance

Fast schon selbstverständlich – aber trotzdem wichtig zu erwähnen – ist der Aspekt der Performance. Kein Anwender wartet gerne; insofern sollte die Software so performant sein, dass sie die üblichen Aufgaben schnell genug ausführt, um keine Wartezeiten zu erzeugen. Die Performance sollte sowohl beim aktuellen Mengengerüst als auch hinsichtlich eines möglichen Wachstumspfades betrachtet werden. Wichtig dabei ist, dass die gewünschte Performance mit vertretbaren Ressourcen realisiert werden kann und keinen (teuren) Ausbau der benötigten Hardware erfordert.

Jakob Nielsen sagte bereits 2010, dass die Reaktionszeiten von Websites nicht länger als 1 Sekunde sein dürfen. Heutzutage dürfen wir erwarten, dass Programme innerhalb von 200ms oder weniger reagieren. Eine längere Reaktionszeit ist im wahrsten Sinne des Wortes uner-”wartet”.

(3) Benutzerfreundlichkeit

Ein zunehmend wichtiger Aspekt ist die Benutzerfreundlichkeit einer Software – vor allem dann, wenn diese Software nicht nur von einigen wenigen Experten genutzt wird, sondern auch von sogenannten Gelegenheits-Usern, die die Software nur selten oder auch nur für einen eingeschränkten Anwendungsfall benötigen. Wenn die Software keine intuitive Nutzung ermöglicht, ist die Hürde für diesen (zunehmend großen) Anwenderkreis häufig zu hoch. Um eine intuitive Nutzung zu ermöglichen, sollte es deshalb möglich sein, die Oberfläche an den jeweiligen Bedarf bzw. Anwendungsfall anzupassen, um keine unnötigen Funktionalitäten anzubieten. Außerdem ist es hilfreich, wenn bei der Gestaltung der Oberflächen allgemein übliche Design-Kriterien zugrunde gelegt und keine “Design-Experimente” gemacht werden. Damit entspricht die Software der Erwartung, die die Anwender aufgrund gängiger Design-Kriterien haben, und vermeidet somit unerwartetes Verhalten.

(4) Portabilität

Die Portabilität einer Software bezieht sich auf ihre Fähigkeit, problemlos von einer Umgebung zur anderen zu wechseln. Eine portierbare Software kann reibungslos auf verschiedenen Systemen oder Plattformen laufen, sei es auf unterschiedlichen Betriebssystemen, Hardwarekonfigurationen oder Cloud-Diensten. Dieses Qualitätsmerkmal ermöglicht es, Kosten und Aufwand für Anpassungen an verschiedene Umgebungen zu reduzieren.

Eine gut portierbare Software ist flexibel und unabhängig von spezifischen technologischen Einschränkungen. Sie erleichtert eine reibungslose Einführung und Wartung, was die Agilität des Unternehmens steigert und die langfristige Anpassungsfähigkeit der Software gewährleistet.

Falls zur Debatte steht, die Software auf verschiedenen Plattformen zu betreiben, dann sollte sie sich auf keiner der Plattformen unerwartet, also anders als auf anderen, verhalten.

(5) Code-Qualität

Die Qualität des Programmcodes wirkt sich in hohem Maße auf die Qualität und den Lebenszyklus der Software aus. Mit der Code-Qualität wird das Fundament für Fehlerfreiheit, Testbarkeit und Wartbarkeit gelegt.

Der typische Lebenszyklus einer Software sieht folgendermaßen aus: Sie wird einmalig in der Implementierungsphase erstellt oder entworfen und dann über viele, viele Jahre kontinuierlich gewartet, weiterentwickelt, mit neuen Features versehen, mit Daten befüllt, bis sie schließlich außer Betrieb genommen oder durch eine andere Software ersetzt wird. In der gesamten Lebensspanne der Software wird demzufolge viel mehr Aufwand in Wartung und Weiterentwicklung gesteckt als in die erstmalige Erstellung.

Software-Hersteller tun also gut daran, darauf zu achten, dass diese Weiterentwicklung unter guten Voraussetzungen und risikoarm erfolgen kann.

Regressionsfehler

Wenn durch die Weiterentwicklung von Software Fehler in bereits existierendem Code produziert werden, sprechen wir von "Regressionsfehlern". Regressionsfehler sind Fehler, die nach einer Änderung des Codes auftreten, obwohl sie zuvor nicht aufgetreten sind. Sie treten typischerweise an Stellen auf, die von der Anpassung des Codes nicht direkt betroffen sind.

Ein fiktives Beispiel: In einer Software wird ein neues Feld in einen Dialog eingefügt. Dafür werden die zugrunde liegenden Datenstrukturen angepasst. Andere Teile der Software können jedoch nicht mit den angepassten Datenstrukturen umgehen und verhalten sich nun plötzlich unerwartet.

Um solche Fehler zu vermeiden, ist es wichtig, Regressionstests durchzuführen. Dadurch kann sichergestellt werden, dass die bestehenden Funktionen des Systems auch nach der Weiterentwicklung weiterhin wie erwartet funktionieren.

Streng genommen muss bei jeder Weiterentwicklung oder Änderung auch nur einer Code-Zeile die gesamte Software jedes Mal erneut getestet werden. Nur so kann sichergestellt werden, dass sich keine Regressionsfehler eingeschlichen haben.

In der Praxis wird dies oft vernachlässigt. Denn es ist viel zu aufwändig und teuer, bei jeder kleinen Änderung die gesamte Software manuell zu testen. In der Regel werden nur Stellen getestet, die von der Anpassung direkt betroffen sind, im günstigsten Fall auch benachbarte Bereiche.

Automatisierte Tests

Der Aufwand, um Regressionsfehler zu vermeiden, steigt exponentiell mit der Anzahl der Features und Funktionen der Software. Der Testaufwand für Software, die über lange Zeit weiterentwickelt wird, steigt daher immens an.

Mittel- und langfristig kann dieser Testaufwand nur mit automatisierten Softwaretests reduziert werden. Menschliches Testen muss auf ein Minimum reduziert werden.

Damit Software überhaupt automatisiert getestet werden kann, müssen die Komponenten weitestgehend entkoppelt und isoliert sein. Es muss festgelegt sein, wie die Komponenten miteinander kommunizieren, und durch regelmäßiges Refactoring sollte der Code aktuell gehalten werden.

Entkopplung und Kapselung

Software besteht im Inneren aus vielen einzelnen Komponenten, die unabhängig voneinander arbeitsfähig sein sollten. Sie sollten voneinander entkoppelt und in sich gekapselt sein.

Sind sie das nicht, so wird der Einfluss der Komponenten aufeinander um so größer, je stärker die Komponenten vernetzt und verzahnt sind. Damit steigt die Wahrscheinlichkeit, dass bei einer Änderung einer Komponente eine andere Komponente in Mitleidenschaft gezogen wird.

Hier gilt: Code, der für die Ausführung im Auftrag von mehreren Akteuren geschrieben wird, verletzt das Prinzip für eindeutige Verantwortlichkeit. Wird dieses Prinzip verletzt, dann wird der Code über die Zeit degenerieren und zu einer großen Matschkugel werden.

Was zunächst spaßig klingt, hat einen ernsten Hintergrund. Code wie dieser ist nicht mehr wartbar. Jegliche Weiterentwicklung, wie z.B. das Hinzufügen von neuen Features, wird fast immer unerwünschte Nebeneffekte haben. Damit entstehen mit jedem neuen Feature auch Defekte. Meist entstehen diese an Stellen, die keine direkten Nachbarn des angepassten Codes sind.

Hat man keine oder lediglich manuelle Softwaretests, dann bleiben diese Defekte unentdeckt, die Software wird fehlerhaft ausgeliefert und die Defekte werden erst durch die Kunden entdeckt. Die Software wird somit zur Bananensoftware – sie reift beim Kunden.

Softwarehersteller tun also gut daran, kontinuierlich und penibel darauf zu achten, die Innereien der Software sauber voneinander zu trennen und durchgängig automatisiert zu testen.

Anders ausgedrückt: Einzelne Komponenten sollten Ihr Verhalten beibehalten, auch wenn sie in einem größeren Kontext eingesetzt werden. Sie sollten ihr Verhalten nicht unerwartet verändern.

Refactoring

Als Refactoring bezeichnen wir die Veränderung des Quelltextes von Programmen, ohne das beobachtbare Verhalten der Software zu beeinflussen.

Warum bloß sollte etwas Funktionierendes verändert werden, ohne dass sich etwas ändert?

Die Frage ist in etwa ähnlich zur Frage: Warum sollte ich meine Wohnungen putzen? Vor dem Putzen ist sie meine Wohnung, hinterher ist sie meine Wohnung. Sie ist hinterher nur sauberer als vorher. Die Funktion bleibt exakt dieselbe.

Die Frage nach dem Sinn des Putzens stellt sich normalerweise nicht. Es erscheint logisch, dass wir unser Eigentum von Zeit zu Zeit auf einen aktuellen Stand bringen und ab und an sogar noch renovieren. Auch unsere Fahrzeuge werden regelmäßig gewartet und Verschleißteile ausgetauscht.

Das tun wir, um auch zukünftig Freude daran zu haben und Ausfälle zu vermeiden.

Auch das ist eine Form von “Refactoring”: Wir verbessern den aktuellen Zustand der Gegenstände, ohne deren Funktion zu verändern.

Für Software ist die Sachlage ganz ähnlich: Aufgrund von Weiterentwicklungen der Software altern andere Teile der Software im Vergleich zu den Weiterentwicklungen. Dies verlangt nach einer Renovierung, einem Herausputzen dieser alten Software-Stellen – einem Refactoring.

Das Gefährliche: Zunächst macht es keinen großen Unterschied, ob ein Refactoring stattfindet oder nicht. Je länger das Refactoring hinausgezögert wird, desto größer werden die technischen Schulden. Desto länger dauern Funktionserweiterungen. Und desto fehleranfälliger wird die kommende Weiterentwicklung.

Je komplexer die Software geworden ist, desto aufwändiger werden die Tests. Gibt es keine automatisierten Tests, so wird das Refactoring oft bis ins Unendliche aufgeschoben. Getreu des Mottos "Never change a running system” wird es nur dann erfolgen, wenn es überhaupt nicht mehr anders geht.

Die Folge: Die Software wird immer schwieriger anzupassen und bleibt irgendwann im Status Quo stecken. An dieser Stelle angekommen hilft oft nur noch die komplette Neuerstellung (Rewrite).

Vorhandene und regelmäßig ausgeführte Tests und regelmäßiges Refactoring sind demzufolge wichtige Kriterien für eine gute und kontinuierliche Software-Qualität.

(6) Technologiestack

Unter Umständen kann es sinnvoll sein, dass ein weit verbreiteter Technologiestack zum Einsatz kommt; das hat zumindest den Vorteil, dass es eine große Zahl von Fachleuten gibt, die damit umgehen können, so dass man nicht von einigen wenigen abhängig ist. Wenn ein Kunde darüber hinaus beabsichtigt, Anpassungen und/oder Erweiterungen der Software selbst vorzunehmen, dann wird er darüber hinaus auch Wert darauf legen, dass der Technologiestack zum Know How der eigenen Fachleute passt.

(7) Anpassbarkeit

Für die Auswahl und den Einsatz von Software ist ein maßgebliches Qualitätskriterium, wie gut, schnell, komfortabel und günstig sich diese Software an den eigenen Business-Case anpassen lässt. Noch wichtiger: Wie gut lässt sich die Software auch an die laufenden Veränderungen des eigenen Business-Cases anpassen?

In der heutigen Zeit wird guter Kundenservice zum Wettbewerbsvorteil, weil die Kundenerwartungen entsprechend hoch sind. Wenn Unternehmen auf die Verbesserung des Kundenservices verzichten müssen, weil die Anpassung der dafür notwendigen Software zu aufwändig oder teuer ist, werden diese Unternehmen ins Hintertreffen geraten. Denn der Mittbewerb ist möglicherweise in der Lage, die kundenbezogenen Prozesse anzupassen und damit einen Wettbewerbsvorteil herauszuarbeiten.

In der heutigen VUCA-Welt wird es überdies immer schwieriger vorherzusehen, welche Maßnahmen von den Anwendern der Software oder den Kunden angenommen werden. Das bedeutet: Es muss möglich sein, Anpassungen und Maßnahmen auszuprobieren, um zu sehen, wie sie ankommen und ob die Zielgruppe diese Maßnahmen honoriert. Auch dafür ist eine schnelle und kostengünstige Anpassung der benutzten Software essenziell.

Aus diesem Grund ist die Anpassung der Software notwendig, ohne dafür Spezial- oder Expertenwissen zu benötigen. Nur so kann eine angemessene Anzahl von Personen schnell und günstig Änderungen vornehmen.

Und wie kann man Software-Qualität prüfen?

Die angelegte Qualitäts-Messlatte liegt um so höher, je geringer die Bereitschaft ist, den Risikofall zu tragen. Sind die Kosten eines möglichen Risikos hoch oder gibt es andere Gründe, die Wahrscheinlichkeit für ein unerwartetes Verhalten zu reduzieren, dann lohnt das Investment in eine höhere Qualität.

Das Interessante dabei: Nicht die Hersteller entscheiden, wie viel Qualität es sein darf. Ausschließlich die Anwender, der Anwendungszweck und die Konsequenzen von unerwartetem Verhalten entscheiden, wie hoch die Qualitäts-Messlatte liegen muss.

(1) Unerwartetes Verhalten

Wir fassen Software-Qualität als Funktion von unerwartetem Verhalten auf. Anders formuliert: Je öfter sich die Software unerwartet verhält, desto schlechter ist die Software-Qualität. Demzufolge ist die Anzahl der unerwarteten Verhalten ein mögliches Messkriterium der Software. Damit sich dieses Messkriterium nicht verschlechtert, wenn sie öfters eingesetzt wird oder länger läuft, macht es Sinn, dieses Kriterium zu normalisieren (also z.B. “Unerwartetes Verhalten pro User” oder ”Unerwartete Verhalten pro Laufzeitstunde”).

Erfahrungsgemäß werden Softwarehersteller diese Zahlen nicht ermitteln. Sofern sie es doch tun, werden potentielle Interessenten sie mit hoher Wahrscheinlichkeit nicht erfahren. Dennoch: Fragen im Rahmen der Softwareauswahl kosten nichts.

Darüber hinaus gibt es einige weitere indirekte Indikatoren, die Rückschlüsse auf die Software-Qualität erlauben.

(2) Releases

Wie schnell könnte ein neues Release bereitgestellt werden?

Dass ein Release technisch bereit steht und wann bzw. ob sie veröffentlicht wird, das sind zwei unterschiedliche Ereignisse, die nicht gekoppelt sein müssen.

Die Frage, in welcher minimalen Zeit ein Release produziert werden könnte, ist ein mögliches Indiz für die Software-Qualität. Liegt die Zeit im Bereich von Minuten oder Stunden, spricht dies für einen hohen Automatisierungsgrad beim Testen und Bau der Software.

Reden wir von Tagen, Wochen oder mehr, spricht dies für viele manuelle Schritte.

Schnelle Bereitstellung ist insbesondere für sicherheitsrelevante Korrekturen notwendig.

Ein weiterer Indikator für eine gute Software-Qualität: Ist es wenig aufwändig, ein neues Release einzuspielen? Kann das, wie in modernen Smartphones, innerhalb von Sekunden oder Minuten und “auf Knopfdruck” geschehen? Oder braucht es aufwändige Arbeiten, möglicherweise sogar von Integrationspartnern? Je leichter Updates vonstatten gehen können, desto besser ist es.

(3) Support

Wie viele Kunden betreuen Support-Mitarbeitende im Durchschnitt?

Die Größe des Support-Teams in Relation zur Kundenbasis ist ein weiteres Indiz für die Software-Qualität. Generell gilt: Je minderer die Qualität, desto mehr Support wird benötigt. Bei einem zu großen Support-Team ist Skepsis angebracht.

(4) Mitarbeiter-Fluktuation

Wie groß ist die Mitarbeiter Fluktuation beim Software-Hersteller?

Je öfter Mitarbeiter wechseln, desto geringer ist das Know-How über die Software im Unternehmen. Das Wissenslevel nimmt ab und erhöht damit die Quote von möglichen Fehlern in der Programmierung.

Portale wie Kununu oder Glassdoor könnten hier nützliche Hinweise oder Warn-Indikatoren liefern.

(5) Self-Service

Gibt es einen Support-Self-Service Bereich? Ein guter Self-Service-Bereich entlastet nicht nur die Mitarbeitenden im Support, sondern kann auch als Indikator für die Einfachheit der Software herangezogen werden. Je komplizierter die Software zu bedienen, warten oder anzupassen ist, desto schwieriger wird es, einen Self-Service-Bereich aufzubauen, der den Anwendern ausreichend Hilfestellung bei unerwartetem Verhalten gibt.

Je weniger unerwartet sich die Software verhält, desto größer wird die Community und desto größer ist die Hilfestellung der Anwender untereinander. Der Support wird also entlastet.

(6) Plug-Ins

Plug-Ins sind zusätzliche Module, die nahtlos in die bestehende Software integriert werden können, um spezifische Funktionen oder Erweiterungen hinzuzufügen. Diese Erweiterungen ermöglichen es,die Grundfunktionalität Ihrer Software nach Bedarf anzupassen, ohne die Kernstruktur zu verändern. Somit kann eine flexible Anpassung an geschäftliche Anforderungen gewährleistet werden.

Die Kunst eines guten Modularisierungskonzeptes ist es, Anpassungen der Software zu erlauben, ohne dass diese Updates behindern. Gleichzeitig muss die Software auf alle erforderlichen Business-Cases angepasst werden können.

Wenn Hersteller beides positiv bescheinigen, ist dies ein starkes Indiz für gute Software-Qualität.

(7) API

Gibt es eine API und wie vollständig ist diese und die zugehörige Dokumentation?

In der heutigen Welt werden Software-Inseln immer seltener. Daten müssen zwischen den Systemen ausgetauscht, verarbeitet, veredelt, weitergeleitet und zurückgespielt werden. APIs sind dazu das Mittel der Wahl. Bildet die API nicht alle Funktionalitäten der Software ab oder hat die Dokumentation Lücken, ist dies ein starkes Indiz für eine veraltete Software.

Ist die API-Dokumentation mittels Standards wie z.B. swagger automatisch erzeugt, ist dies ein Indiz für moderne Software in guter Qualität. Auch die Ausrichtung nach den MACH-Prinzipien (Microservices, API-first, Cloud-native, Headless) spricht eher für eine moderne, hochqualitative, skalierbare und gut wartbare Software.

Die Quintessenz

Es gibt eine ganze Reihe von Aspekten, die die Qualität einer Software beeinflussen. Und da die Software-Qualität einen hohen Einfluss sowohl auf die Folgekosten als auch auf den erzielbaren Nutzen hat, ist eine umfassende Betrachtung dieser Aspekte in Verbindung mit der Bewertung von Software-Systemen dringend zu empfehlen.

Dabei muss jedes Unternehmen – abhängig von den jeweiligen Rahmenbedingungen – bei der Software-Bewertung selbst festlegen, welches Gewicht die einzelnen Aspekte haben.