Konzept

Der Begriff der Softwarequalität selbst ist nicht operabel, d. h. in der Praxis nicht direkt anwendbar. Deshalb existieren Qualitätsmodelle, die den Begriff konkretisieren und durch eine weitere Detaillierung operationalisieren. Dadurch entsteht ein Baum (oder ein Netz) von Begriffen und Unterbegriffen.

Die Qualitätsmerkmale tragen im Englischen die Bezeichnung factor, ein Qualitätsteilmerkmal heißt criterion und die Qualitätsindikatoren metrics. Deswegen erscheinen derartige Qualitätsmodelle in der Literatur auch als „FCM-Modelle“ (z. B. FURPS, Boehm u. a. 1978, DGQ-Modell 1986, McCall u. a. 1977.) Bei den Blattknoten im Baum des Qualitätmodells, den Qualitätsindikatoren, sollte es sich um beobachtbare oder messbare Sachverhalte handeln. Hier können beispielsweise Softwaremetriken zum Einsatz kommen.

Beispiel ISO/IEC 9126

Qualitätsmodelle existieren zum Beispiel in der Form des ISO-Standards ISO/IEC 9126. Diese Norm definiert die in der nebenstehenden Grafik dargestellten Qualitätskriterien für Software in zweistufiger Struktur. Danach wird deutlich, dass unter Softwarequalität mehr als nur Fehlerfreiheit (die im Wesentlichen dem Kriterium Funktionalität zuordenbar ist) verstanden wird.

Die Qualitätsmerkmale benennen unterschiedliche Eigenschaften, die die Software aufweisen soll. Dies sind auf oberster Ebene:

• funktionale Eigenschaften, „die grundlegenden Eigenschaften zu den Funktionen der Software“ (was sie funktional leisten soll und wie),
• nicht-funktionale Eigenschaften, die „das Betriebsverhalten des Softwareprodukts im täglichen Einsatz kennzeichnen.“

Während bei den nicht-funktionalen Eigenschaften zur Zuverlässigkeit, Benutzbarkeit (Usability) und Effizienz die Anforderungen einzuordnen sind, die das Softwareprodukt bei seinem Betrieb erfüllen soll, sind die Qualitätskriterien zu Änderbarkeit (Wartbarkeit) und Übertragbarkeit auf die interne Beschaffenheit der Software (i. W. des Quelltextes) ausgerichtet, die ggf. erforderliche Anpassungsmaßnahmen ermöglichen/vereinfachen soll.

Diese Kriterien stellen einen Rahmen dar, der für einzelne Softwareprodukte in individuellen Spezifikationen konkretisiert werden kann, um in der Softwareentwicklung berücksichtigt zu werden.

Modelle und Methoden

Einige Modelle:

• Organisatorische Qualitätsmodelle, zum Beispiel das Capability Maturity Model (CMM) oder Automotive SPICE
• Prozessmodelle, wie zum Beispiel
  • Capability Maturity Model Integration
  • der Rational Unified Process (RUP)
  • das V-Modell
  • das V²-Modell, auch W-Modell genannt
  • Hardware in the Loop (HIL)

Zur Bewertung der Umsetzung von Unternehmensprozessen gibt es den ISO/IEC 15504 (auch SPICE genannt) bzw. domänenspezifische Varianten davon (wie z. B. Automotive SPICE für Entwicklungsprozesse von Steuergerätelieferanten)

Einige Methoden:

• iterative Softwareentwicklung
• Spiralmodell
• Refactoring
• Testgetriebene Entwicklung
• unterschiedliche Testarten und Methoden bei Softwaretests

Die Modelle lassen sich teils, die Methoden größtenteils miteinander kombinieren. Interessant sind die Modelle der agilen Prozesse wie das Extreme Programming insbesondere deshalb, weil sie Synergieeffekte des gleichzeitigen Einsatzes verschiedener Methoden nutzen.

QS-Schwerpunkt Softwaretest

Das Testen ist ein für die Softwarequalität bedeutender Abschnitt bei der Entwicklung von Software. Dabei wird die Qualität der erstellten oder geänderten/weiterentwickelten Software mit unterschiedlichen Verfahren (z. B. Keyword-Driven Testing, risk based Testing, data driven Testing, …), Vorgehensmodellen, Testarten, Teststufen usw. vor der Übergabe zur tatsächlichen Nutzung überprüft. Die Literatur (hier) nennt dies „Vertrauen in die Qualität der Software schaffen“ und erläutert: „Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche; Qualität kann nicht 'eingetestet' werden.“.

Demnach wird bezüglich der Maßnahmen zur Qualitätssicherung unterschieden zwischen konstruktiven und analytischen Maßnahmen (siehe Grafik).

• Zu den konstruktiven Maßnahmen gehören zum Beispiel Disziplinen wie eine systematische Projektdefinition und Projektzieledefinition sowie eine detaillierte (und von den Projekt-Auftraggebern verbindlich verabschiedete) Anforderungsanalyse, die Benutzung etablierter bzw. festgelegter Programmierstandards usw.
• Die analytischen Maßnahmen lassen sich unterteilen in
  • statische Maßnahmen (siehe statische Code-Analyse wie Code Reviews), in denen der Code der erzeugten Anwendung überprüft wird, ohne dass die Anwendung tatsächlich ausgeführt wird. Je nach Art der Maßnahme erfolgt die Überprüfung zu unterschiedlichen Zeitpunkten, z. B. unmittelbar bei der Code-Entwicklung (siehe Paarprogrammierung) oder erst vor der Freigabe für Benutzertests.
  • dynamische Tests, in denen die erzeugte Anwendung unter unterschiedlichsten Konstellationen (siehe auch Testfall) tatsächlich ausgeführt wird und die erzeugten Ergebnisse überprüft werden.

Die Qualität der Software befindet sich somit zu unterschiedlichen Zeitpunkten ihrer Entwicklung in unterschiedlichen Zuständen und soll bei ihrer tatsächlichen produktiven Verwendung allen definierten Anforderungen/Kriterien entsprechen.

Standardsoftware

Für Software dieses Typs kommt, um bei unterschiedlichen Anwendern einsetzbar zu sein, insbesondere dem Kriterium Übertragbarkeit (Anpassbarkeit) eine wesentliche Bedeutung zu. Der Funktionsumfang der Standardsoftware kann damit (durch Parametrisierung) an den vom Unternehmen benötigten Funktionsumfang angepasst werden.

Systemsoftware

Kriterien zur Effizienz (Verbrauchsverhalten, Zeitverhalten) können für diesen Softwaretyp besonders wichtig sein; ebenso die Wiederverwendbarkeit und die Kompatibilität, (= Lauffähigkeit in unterschiedlichen Systemumgebungen).

Spielesoftware

Hier kommt der Effizienz besondere Bedeutung zu, beispielsweise bei der optimalen Nutzung von Grafikkarten („ruckelfreie“ Bildbewegungen). Auch gelten hier besondere Anforderungen bezüglich der Bedienbarkeit (wie Einheitlichkeit, Einfachheit).

Software für mobile Geräte

Funktionalität

Zum Teilkriterium Sicherheit: Im Vergleich zu Anwendungen auf stationären Rechnern fallen als sensitive Daten zusätzlich Bewegungsprofile des Nutzers an.

Effizienz

Im Einzelkriterium Verbrauchsverhalten kommt der Beanspruchung der Prozessorleistung, des Arbeitsspeichers und des online-Datenvolumens besondere Bedeutung zu. Geringer Akku-Verbrauch kann eine möglichst lange Laufzeit gewährleisten.

Änderbarkeit

Wesentlicher Unterschied zu Arbeitsplatzrechnern ist die Vielfalt der Plattformen und deren schnellere Fortentwicklung, die einfaches/schnelles Ändern der Software erfordert.

Erreicht werden kann diese Flexibilität durch den Einsatz von Frameworks (wie PhoneGap und Xamarin) auf unterschiedliche Betriebssystemen und -Umgebungen eingesetzt und einfach installiert (Installierbarkeit) werden können. Eine andere Option, um Plattformunabhängigkeit zu erreichen, sind sogenannte Web-Apps, also Applikationen, die in einem Webbrowser angezeigt und bedient werden.

Übertragbarkeit

Merkmal mobiler Geräte sind unterschiedlich kleine Anzeigeflächen (von 1 bis 10 Zoll). Anwendungen müssen auf kleinen Anzeigen bedienbar sein und größere Anzeigen sinnvoll nutzen können. Der Wechsel zwischen Hoch- und Querformat ist auf mobilen Plattformen häufig, auf Arbeitsplatzrechnern die Ausnahme.

Meist ist keine echte Tastatur verfügbar, die Tastatureingabe ist langsamer, es sind weniger Tasten und Tastenkombinationen sind unüblich. Andererseits sind oft alternative Eingabemöglichkeiten vorhanden, die mit Funktionen hinterlegt sein wollen.

Konformität

Zu diesem Qualitätskriterium – das in allen o. g. Kriteriengruppen zutrifft – stellen für das Beispiel Benutzbarkeit/Bedienbarkeit die von Herstellern mobiler Systeme bereitgestellten Designrichtlinien/Vorgaben für einen Großteil von Anwendungen eine gute Basis für das Design dar. Beispiele siehe Google, Apple und Microsoft