September 2, 2012 0

Qualität von Software

By in Programmieren, Projektmanagement

Als Anwender lässt man sich schnell zu einem eindimensionalen Urteil über die Qualität einer Software hinreißen: Ein Programm oder eine App ist entweder “gut” oder “schlecht”. Lässt man einmal den Image-Aspekt bei Seite (Es scheint gradezu zum guten Ton zu gehören, sich über MS Office aufzuregen und es zu verdammen), so bleibt im Kern die Frage: Was macht eine Software zu einem guten bzw. schlechten Produkt.
Aus Entwicklersicht stellt sich die selbe Frage aus einer anderen Perspektive: Wie kann ich (konkret) die Qualität meiner Software verbessern.

Bei der Suche nach einer geeigneten Metrik zur Beurteilung von Softwarequalität bin ich über den ISO-Standard ISO/IEC 9126 gestolpert. Dieser sieht folgende Dimensionen für die Beurteilung der Qualität einer Software oder eines Informationssystems vor:

  • Funktionalität
    • Angemessenheit
    • Richtigkeit
    • Interoperabilität
    • Sicherheit
    • Ordnungsmäßigkeit
  • Zuverlässigkeit
    • Reife
    • Fehlertoleranz
    • Wiederherstellbarkeit
    • Konformität
  • Benutzbarkeit
    • Verständlichkeit
    • Erlernbarkeit
    • Bedienbarkeit
    • Attraktivität
    • Konformität
  • Effizienz
    • Zeitverhalten
    • Verbrauchsverhalten
    • Konformität
  • Wartbarkeit/Änderbarkeit
    • Analysierbarkeit
    • Modifizierbarkeit
    • Stabilität
    • Testbarkeit
    • Konformität
  • Übertragbarkeit
    • Anpassbarkeit
    • Installierbarkeit
    • Koexistenz
    • Austauschbarkeit
    • Konformität

Eine detaillierte Erklärung finden Sie auf der Wikipedia-Seite zum genannten ISO-Standard. Das würde hier den Rahmen sprengen und vom Punkt, den ich gerne machen würde ablenken.

Nun ist es leider nicht so ohne weiteres möglich qualitative Merkmale wie z.B. die Anpassbarkeit in eine Zahl oder sogar eine Prozentzahl zu überführen. Vom Ziel, die Qualität einer Software genau beziffern zu können muss also (leider) Abstand genommen werden. Nichts desto trotz kann man auf der Basis der vorgestellten Qualitätsmerkmale zwei Anwendungen mit einander vergleichen.

Softwarequalität und Projektmanagement

Mir kam ein weiterer Anwendungsfall der obigen Liste von Qualitätsmerkmalen in den Sinn: Könnte es nicht sinnvoll sein, jeder Änderung, die an einer Software vorgenommen wird – sei es in der Entwicklungsphase oder im Livebetrieb – ein oder mehrere Qualitätsmerkmale zuzuweisen? Ein Beispiel: Ich habe grade ein neues Modul programmiert, dass den Datendurchsatz maßgeblich erhöht und die Software gleichzeitig unanfälliger gegenüber Fehlern macht. Ich habe damit die Qualität der Software in zwei Richtungen verbessert:

  • Zeitverhalten
  • Fehlertoleranz

Sagen wir, die Arbeit an dem besagten Modul hat einen Arbeitstag gedauert und somit Kosten verursacht. Der Projektmanager kann nun genau sehen, welche Ausgaben und welche Resourcen für welche Qualitätsaspekte beansprucht wurden.

Die Dokumentierung: Revision Control und Ticket Systeme

In der Praxis ist es üblich, dass (größere) Entwicklungsprojekte über ein System der Versionskontrolle (Revision Control) abgewickelt werden. Ebenso obligatorisch ist der Einsatz eines Ticket Systems/Bugtracker, in das Entwickler, Verantwortliche und Kunden (bzw. der Kundensupport) Bugs und Änderungswünsche festhalten. Diese werden dann genau spezifiziert und als Aufgaben den Softwareentwicklern zu gewiesen.
Hat ein Entwickler nun einen Bug gefixt oder ein neues Feature implementiert, hält er dies für gewöhnlich dadurch fest, dass er die interne Ticket-ID bei der Übertragung seiner Änderungen ins Versionskontrollsystem (z.B. GutHub, Subversion oder TortoiseSVN ) mit angibt.

Mein Vorschlag wäre nun, diese etablierte Vorgehensweise dadurch zu erweitern, dass bereits im Ticketsystem durch einen Verantwortlichen (gegebenenfalls den Projektmanager selbst) jedem Ticket/Bug/Feature-Requst ein oder mehrere der obigen Qualitätskriterien zugeordnet werden. Das hätte folgende Vorteile:

  • Der Projektmanager hat einen besseren Überblick über die Kosten und den Einsatz der Entwickler
  • Qualitätsdefizite einer Software werden im Live-Betrieb sichtbarer: Wenn viele Tickets eingehen, die Probleme mit der Bedienbarkeit atestieren, sollte ev. über eine komplette Neugestaltung des Userinterfaces nachgedacht werden.
  • Unnötiger Resourcen-Einsatz kann vermieden werden: Oft besteht eine Diskrepanz zwischen den Entwicklungsbemühungen und den tatsächlichen geäußerten Verbesserungswünschen. Ev. ist es gar nicht nötig z.B. die Effizienz der Software weiter zu verbessern. Dieser “blinde” Ehrgeiz verursacht wirtschaftlich gesehen nur unnötige Kosten.
  • Dem Kunden kann eine neue Version oder eine Erweiterung der Anwendung näher gebracht werden, indem genau gesagt werden kann, in welcher Hinsicht das Produkt qualitativ verbessert wurde.

Ich bin gespannt über Ihre Meinung zu diesem Beitrag und freue mich über Mails und Kommentare.

Leave a Reply