Qualität hat Ihren Preis?!

Softwarequalität – so misst und verbessert man Software
Kommentare

Alle reden über Qualität. Das gilt auch für Software. Je nach Betrachtungsweise wird der Begriff in einem anderen Zusammenhang gebraucht. Fehler in einer Anwendung zeugen von minderer Qualität. „Qualität habe eben ihren Preis“, so ein gern gebrauchtes Sprichwort. Bevor man über etwas Fehlendes diskutiert, muss man es zunächst definieren. Dieser Artikel beschäftigt sich mit der Qualität von Software, insbesondere deren Messung.

Bevor man bestimmen kann, ob ein Produkt – ein einzelnes Programm oder ein gesamtes Anwendungssystem – qualitativ hochwertig ist, muss man Qualität definieren. Und an dieser Stelle beginnen die Probleme: Kann man Qualität messen bzw. kann man feststellen, in welchem Maß ein Qualitätsanspruch erfüllt ist? Das Thema ist nicht neu. Bevor man sich der aktuellen Diskussion um Softwarequalität zuwendet, lohnt sowohl ein Blick in die Historie als auch ein Streifzug durch allgemeine Qualitätsansätze. Letztere gelten für alle Güter und Dienstleistungen. Es ist zu prüfen, inwieweit diese Ansätze für Software – mit oder ohne Anpassungen – übernommen werden können. Jeder Entwickler verfolgt ohne Zweifel das Ziel, qualitativ hochwertige Anwendungen zu erstellen. Zur Beurteilung, ob dieses Ziel erreicht wurde, müssen Maßstäbe zur Durchführung einer Soll-Ist-Analyse existieren. Ziel dieses Artikels ist es, unterschiedliche Ansätze des Themas Softwarequalität zu beleuchten und möglichst zeit- und wertneutrale Kriterien herauszustellen. Sind diese Zusammenhänge klar, dann können daraus auch Maßnahmen zur Verbesserung der Qualität abgeleitet werden. Die Bestimmung der Qualität wird in der Literatur u. a. unter dem Stichwort Softwaremessung diskutiert (Kasten: „Softwaremessung – Eine Einführung in drei „Akten“).

Softwaremessung – Eine Einführung in drei „Akten“
Das Thema Softwaremessung ist umfangreich in Theorie und Praxis. Für das Ableiten von Handlungsvorschlägen muss man sich mit einigen konzeptionellen Ansätzen beschäftigen.
Teil 1: Im Artikel „Softwaremessung – Wie man Entwicklungsprozesse analysiert und verbessert“ geht um die Ziele und Gegenstände der Softwaremessung. Je nach Messobjekt und Entwicklungsphase sind unterschiedliche Verfahren notwendig. Es werden Ansätze zur Messung der Softwarequantität besprochen.
Teil 2: Im Mittelpunkt von Teil 2 steht die Frage: „Was ist Softwarequalität“. Wenn man es definieren kann, kann man es vielleicht auch messen und objektivieren?
Teil 3
: Produktionsprozesse sollen möglichst effektiv sein. Softwareentwicklung ist jedoch eine Disziplin im Grenzbereich zwischen ingenieurmäßigen Vorgehen und künstlerischer Arbeit. Lässt sich dennoch die Produktivität bestimmen und kann Verbesserungspotenzial abgleitet werden? Der Artikel „Softwaremessung: Wie misst man die Produktivität von Softwareprojekten?“ verrät es.

Softwarequalität im Fokus zwischen Nutzen und Kosten

Die Qualitätsdiskussion wird nicht zum Selbstzweck geführt. Vielmehr muss diese einer wirtschaftlichen Diskussion aus Nutzen und Kosten zugänglich sein. Die Kosten der Qualität lassen sich wie folgt einteilen:

• Fehlerverhütungskosten: Kosten der Qualitätsplanung, -lenkung, -management, -audits usw.
• Fehlerkosten: durch Abweichungen, Vertragsstrafen, Auftragsverlust an Konkurrenz.

Die gesamten Qualitätskosten bewegen sich erfahrungsgemäß zwischen zehn und dreißig Prozent des Umsatzes (variabel je nach Projekt) und können damit durchaus den Gewinn eines Unternehmens übersteigen. Mit so genannten vorbeugenden Maßnahmen – wie eine präventive Qualitätspolitik – können trotz steigender Fehlerverhütungskosten die gesamten Qualitätskosten sinken. In diesem Sinne kann man ein optimales Qualitätsniveau bestimmen, hier ist die Summe aus Fehlerverhütungskosten (Kosten der Qualität) und Fehlerkosten (Kosten der Nichtqualität) minimal (Abb. 1).

Abb. 1: Wirtschaftlichkeit der Qualitätskosten

Damit wird auch deutlich, dass für Softwaresysteme aus rein ökonomischen Zwängen ein bestimmtes Maß an Fehlern auch bei einer umfassenden Qualitätssicherung hingenommen werden muss. Diese Fehlerrate liegt im Allgemeinen höher, als die technisch erreichbare Qualität. Nur für Software in einem sehr kritischen Umfeld (Medizintechnik, Flugsicherung, …) ist es gerechtfertigt, mit sehr umfangreichen Maßnahmen der Qualitätssicherung die Fehlerrate nahe an den Nullpunkt zu bringen. Hier führt auch die Existenz von wenigen Fehlern oft zu immensen Kosten bzw. nicht akzeptablen Folgen. Der Nutzen bzw. Wert von Softwarequalität lässt sich benennen. Aus Nutzersicht bzw. Kundensicht ist dieses:

• Erhöhung der Zufriedenheit
• Steigerung der Zuverlässigkeit
• Keine Störungen im Betrieb
• Kundenwünsche können zuverlässiger erfüllt werden
• Bessere Erfüllung der Anforderungen
• Arbeitsprozesse können effektiver gestaltet werden.

Dem Kunden ist – unter Berücksichtigung der steigenden strategischen Bedeutung der eingesetzten Software – auch klar zu machen, dass Softwarequalität zu einer Steuergröße geworden ist, die ein verantwortungs- und kostenbewusstes Management erfordert. Oder kurz: „Qualität kosten eben!“ Die schlimmste Folge einer fehlenden Qualitätssicherung ist, dass eine gewisse Willkür bei der Umsetzung der Lösungen herrscht. Beispielsweise definiert dann jeder Entwickler seine eigenen Richtlinien und seine eigene Art, den Quellcode zu dokumentieren. Diese Freiheit ist nicht positiv und kann langfristig als der sicherste „Übergang in den Untergang“ bezeichnet werden [2].

Ein Blick in die Historie

Zunächst kann man unter Qualität die Erfüllung der Anforderungen verstehen, die ein Kunde an ein Produkt bzw. eine Dienstleistung hat. Auch die Eignung des Produkts für den (vorgesehenen) Zweck kann als Maßstab für die Qualität herangezogen werden. Die Deutsche Gesellschaft für Qualität versteht darunter die Gesamtheit der Merkmale, die eine Ware oder Dienstleistung zur Erfüllung vorgegebener Forderungen geeignet macht. Diese Definition geht von einem positiven Blickwinkel aus. Aus anderer Sichtweise wird dann Qualität unterstellt, wenn das Produkt – in diesem Fall die Anwendung – frei von Fehlern ist. Nun ist man sich nach heutigem Stand der Erkenntnisse recht einig, dass es nicht möglich ist, eine vollständig fehlerfreie Software zu erstellen. Die zuletzt genannte Definition müsste man daher auch bereits wieder einschränken und den grundsätzlichen Ausschluss von Fehlern zugunsten einer weitgehenden Fehlerfreiheit abändern. Es würde also genügen, wenn die Anwendung die benötigten Funktionen zur Erfüllung des Verwendungszwecks bereitstellt und man als Benutzer bei der Arbeit nicht durch Fehler beeinträchtigt wird. Ob diese Argumentation bereits den Kern einer qualitativ hochwertigen Software trifft, darf zumindest angezweifelt werden. Zu dieser Diskussion passt die Frage danach, welche Erwartungen ein Kunde an das Programm hat. Bei Software gibt es noch ein weiteres Problem: Viele Anwender benutzen Programme, die sie nicht bewusst ausgesucht haben. Auf ihrem PC war bereits ein Betriebssystem installiert, und im Büro ist die Office-Suite ebenfalls unabänderlich vorgegeben. Programmmodifikationen und -erweiterungen werden im Regelfall über Updates akzeptiert. Es wird sogar dazu im Sinne der Sicherheit geraten. Man stellt also fest: Qualität im Sinne einer Erfüllung der Anforderungen zu definieren, ist nicht immer ganz einfach. Die Anforderungen unterliegen Trends, einem zeitlichen Verschleiß und anderen wenig spezifizierbaren Entwicklungen. Zum Beispiel spielt der technische Fortschritt im Bereich der Software eine immense Rolle. Programme, die vor fünfzehn Jahren auf den Markt kamen, unterlagen vollständig anderen Bedingungen und Ansprüchen ihrer Anwender als heutigen Anwendungen. Damit lässt sich feststellen, dass Qualität auch zeit- und ortgebunden ist. Die externen Rahmenbedingungen bestimmen somit im Wesentlichen, welche Maßstäbe aktuell zur Beurteilung herangezogen werden. Das Thema Softwarequalität hat aus heutiger Sicht noch nicht den Stellenwert erfahren, dem es eigentlich gebührt. Man kennt die Zahlen über gescheiterte oder nicht den Anforderungen der künftigen Nutzer entsprechenden Projekte. Auch wenn deren empirische Aussagekraft nicht immer belegt ist, sind auf jeden Fall die Erwartungshaltungen der Nutzer in den letzten Jahren nach qualitativ hochwertiger Software gestiegen. Nicht alle Produkte können diese hohen Anforderungen erfüllen. Nachfolgend werden einige Ansätze zur Definition von Softwarequalität vorgestellt. Dabei fällt auf, dass diese teilweise schon vor einigen Jahren entwickelt wurden, an Aktualität jedoch nichts eingebüßt haben:

• Qualitätseigenschaften nach Boehm: Der Ansatz stammt bereits aus dem Jahr 1978. Bemerkenswert: Die identifizierten Eigenschaften zur Bestimmung der Qualität sind heute noch hoch aktuell. Boehm hat Qualität anhand der in (Abb. 2) dargestellten Eigenschaften bestimmt. Konkretisierungen finden sich in Tabelle 1.

Abb. 2: Qualitätseigenschaften nach Boehm, Darstellung nach

Eigenschaft zur Messung der Qualität Erläuterungen
Verständlichkeit des Quellcodes Parameter sind zum Beispiel die Verschachtelungstiefe der Entscheidungslogik oder die Namensgebung der Variablen und Bezeichner.
Vollständigkeit Sind die Funktionen vollständig im Vergleich zu den definierten Anforderungen (Lasten- und Pflichtenheft) umgesetzt?
Portabilität Betrifft die Möglichkeiten der Übertragung der Software in eine andere Systemumgebung.
Änderbarkeit Die Anwendung muss an mögliche Änderungen schnell, fehlerfrei und unkompliziert anpassbar sein. Dazu dürfen zum Beispiel keine Datenwerte als Zahlenkonstanten mehrfach im Quellcode verwendet werden. Zum Beispiel ist der Mehrwertsteuersatz änderbar zu implementieren.
Testbarkeit Der Quellcode (Struktur, Programmablauf) sollte einer einfachen Testung zugänglich sein.
Benutzbarkeit Adaptiert man die damaligen Aussagen an die heutigen Anforderungen, so versteht darunter zum Beispiel die Benutzerfreundlichkeit der Oberfläche u. a. durch eine durchdachte Gestaltung der Dialogfelder.
Zuverlässigkeit Hierunter wird eine fehlerfreie Lauffähigkeit der Software verstanden.
Effizienz Die Effizient bezieht sich auf die Nutzung der verfügbaren Systemressourcen. Mit Blick auf die Entwicklung mobiler Anwendungen ein hoch aktuelles Thema, denn dort sind die Kapazitäten weiterhin in jeder Hinsicht (Speicherplatz, Netzwerkkapazität, Prozessorleistung, Energieressourcen, …) beschränkt.

Tabelle 1: Qualitätseigenschaften nach Boehm, zusammengestellt nach

• Ansatz zur Quantifizierung der Qualität nach Gilb: Auch hierbei handelt sich um einen sehr frühen Ansatz (1976) zur Messung der Softwarequalität. Dabei soll die Erfüllung der Erwartungen an eine Anwendung mithilfe von Zahlen bzw. Verhältniswerten ausgedrückt werden (Tabelle 2). Nach diesem Ansatz muss eine Qualitätseigenschaft mit einem Zahlenwert bzw. mit der Aussage (ja/nein) messbar bzw. feststellbar sein. Dieser Ansatz der Bestimmung der Qualität steht also in direkten Zusammenhang mit der Messung von Softwaregrößen. Qualität wird also über die Bestimmung einzelner Parameter einer Messung zugänglich gemacht.

Erwartung des Benutzers Erläuterungen
Erfüllung der Anforderungen Die Realisierung der Istfunktionalität wird in das Verhältnis zur Sollfunktionalität gesetzt.
Performance Gemessen wird die Systemreaktionszeit. Sofern ein maximaler Sollwert definiert ist, wird der Istwert mit diesem verglichen.
Reliabilität Bestimmt wird, ob das System korrekte Ergebnisse liefert.
Security Der Wert bezog sich auf die Sicherung der Daten der Anwendung. Trotz heutiger anderer Konzepte der Datensicherheit ist der Punkt aktuell, d. h. Anwendungen sollen keine (externen) Daten ohne Rückfrage ändern oder löschen.
Efficiency Die Effizienz eines Systems misst dessen Umfang mit den Systemressourcen (Speicher, Rechenleistung, …).
Availability Bestimmt wird die Verfügbarkeit des Systems. Dazu werden die verfügbaren Zeiten den Ausfallzeiten gegenübergestellt. Beispielsweise wird bei Serversystemen oft eine Verfügbarkeit von 0,99 vereinbart. Fällt das System innerhalb eines Testzeitraums von 24 Stunden auch nur 0,5 Stunden aus, so ist die Bedingung verletzt (23,5 / 24 = 0,979 < 0,99).
Maintainability Die Software sollte leicht anpassbar sein, d. h. künftige Änderungen der Anforderungen sollten auch leicht in die Anwendung zu integrieren sein. Der damalige Ansatz konnte noch keine quantifizierbaren Größen für die Messung dieser Eigenschaft präsentieren.
Portability Das System sollte ohne größeren Aufwand auf eine andere Plattform übertragbar sein.

Tabelle 2: Messung der Quantität nach Gilb, zusammengestellt nach

Beide Ansätze sind sich also in vielen Punkten ähnlich und auch aus heutiger Sichtweise relevant. Die Ergebnisse der Normierungsbestrebungen von IEEE und ISO weichen von diesen Definitionsversuchen für Softwarequalität kaum ab, wie der kommende Abschnitt zeigt.

IEEE- und ISO-Standards zur Messung der Softwarequalität

Gemäß IEEE-Standard 610 gibt es folgende Definitionen zur Messung der Softwarequalität:

1. Softwarequalität ist der Grad, in dem das System die gestellten Anforderungen erfüllt.
2. Softwarequalität ist der Grad, zu dem ein Softwaresystem die Bedürfnisse und Erwartungen der Benutzer erfüllt (IEEE99).

Problematisch ist zum einen, dass die Benutzer keine homogene Gruppe sind und zum anderen die Bedürfnisse und Erwartungen an das System oft nicht klar sind. Mit der Bestimmung der Bedürfnisse beschäftigt sich die Anforderungsanalyse, deren Komplexität und die daraus resultierenden Schwierigkeiten sind vielerorts nachlesbar. Der ISO-Standard 9126 definiert ein weitestgehend allgemeingültiges Qualitätsmodell. Dessen Hauptziele sind inhaltlich knapp in Tabelle 3 dargestellt. Im konkreten Einzelfall, d. h. für die Messung der Softwarequalität sind diese Kriterien nicht ausreichend. Vielmehr sind es nur Anhaltspunkte, woraus konkrete Standards – zum Beispiel für eine Produktkategorie – abzuleiten sind. Dabei muss man anderseits natürlich aufpassen, dass die Definition der Standards im Sinne von Sollvorgaben nicht zu individuell bzw. jedes Mal neu durchgeführt wird. Dann würde das Ziel einer möglichst objektiven Messung verfehlt. Qualitätssicherung brauch eine Normvorgabe.

Qualitätsziel nach ISO Erläuterung
Funktionalität Grad, in dem die Software die erwartete Funktionalität abdeckt. Sofern diese nicht genau spezifiziert ist, kann man ggf. auch auf bereichsspezifische Normen zurückgreifen (hilfsweise).
Zuverlässigkeit Dieser Parameter bezieht sich auf die Anzahl der Fehler bzw. besser ausgedrückt auf die Abwesenheit von Fehlern. Je weniger ein Produkt Fehler beinhaltet, desto zuverlässiger ist es.
Benutzbarkeit Die Anwender sollen die Software unmittelbar verstehen und mit Leichtigkeit bedienen können. In einem gewissen Umfang bleibt dieses Kriterium subjektiv.
Effizienz Es geht um die Bestimmung physikalischer Größen, wie Antwortzeiten, Durchlaufzeiten, Anzahl der maximal möglichen parallel zu verarbeitenden Transaktionen, … Auch ein Soll-Ist-Vergleich kann an dieser Stelle angebracht sein.
Wartbarkeit Betrachtet den erforderlichen Erhaltungsaufwand für das System, um dieses weiterzuentwickeln. Anhaltspunkte sind die Gründlichkeit der Dokumentation, die Änderbarkeit der Architektur und die Sauberkeit des Quellcodes.
Portabilität Es geht um die Übertragung der Anwendung in eine andere Umgebung. Die Frage ist, wie viel Aufwand macht das? Java-Bytecode lässt sich beispielsweise in einer anderen Systemumgebung relativ problemlos ausführen. Die nächste Stufe ist die Notwendigkeit einer Neukompilierung. Im schlimmsten Fall muss der gesamte Quellcode ersetzt (angepasst) werden. Die Portabilität lässt sich auf einer Skala von 0 bis 100 Prozent messen.

Tabelle 3: Parameter zur Bestimmung der Qualität nach ISO 9126, siehe auch

Übergreifende Qualitätsansätze

Die Ansätze zur Softwarequalitätssicherung sind meist aus den allgemeinen bzw. übergreifenden Qualitätssicherungskonzepten des Industrie und/oder Dienstleistungssektors abgeleitet. Stichpunktartig folgen dazu einige Anmerkungen, denn ohne ein grobes Gesamtverständnis kann Softwarequalität nur schwerlich verstanden und gemessen werden. Für eine weitere Vertiefung (zum Beispiel als Qualitätsbeauftragter) ist das Studium von Fachliteratur unerlässlich:

• Qualitätsmanagementsystem (QMS): Ein QMS ist laut ISO 9000 ein Managementsystem zum Leiten und Lenken einer Organisation bezüglich der Qualität. ISO 9001 nennt die Grundanforderungen, dass man überhaupt von einem QM-System sprechen kann (branchenneutral); ISO 9000-3 spezifiziert dieses für Software.
• European Foundation for Quality Management (EFQM): wurde primär als Referenzmodell für Selbstbewertungen eingeführt. Hier werden auch die Ergebnisse bewertet, d. h. mit Verlusten kann man nicht exzellent sein.
Capability Maturity Model Integration (CMMI): Es handelt sich um ein wirkungsvolles Instrument, das hilft, die Effektivität und die Effizienz von Entwicklungsorganisationen zu verbessern. Eine Organisation, die ihre CMMI-Fähigkeit offiziell nachweisen kann, erhält ein anerkanntes Reifezeugnis.
• PDCA-Zyklus: Der PDCA-Zyklus besteht aus den Phasen Plan – Maßnahmen zur Qualitätsverbesserung entwickeln; Do – die geplanten Maßnahmen werden im Unternehmen umgesetzt; Check – die Maßnahmen werden hinsichtlich ihrer Zielwirksamkeit kontrolliert und bewertet und Act – auf Grundlage des Check-Ergebnisses werden eventuelle Korrekturmaßnahmen eingeleitet. Danach wird der Zyklus erneut durchlaufen (Prinzip der kontinuierlichen Verbesserung).

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Goal Question Metric

Für die Messung von Softwarequalität ist auf jeden Fall die Goal Question Metric (GQM) zu erwähnen. Es handelt sich um ein Hilfsmittel zum Aufbau und zur Durchführung zielorientierter Messungen. Ausgehend von den Messzielen und den gewünschten Informationen werden die für die Messung benötigen Ziele abgeleitet (Abb. 3). Das Verfahren basiert auf den folgenden Schritten:

1. Problemstellung charakterisieren: zum Beispiel die Qualität der Software wird vom Kunden ständig bemängelt.
2. Identifikation der GQM-Ziele/-Pläne: Es wird das übergreifende Geschäftsziel vorgegeben (z. B. Verbesserung der Kundenzufriedenheit). Daraus werden die GQM-Ziele der Messung abgeleitet (z. B. Reduzierung der Fehlerrate um 10 Prozent). Ein GQM-Plan enthält dann das Messziel (Goal), die Maße und Fragen (Question) und die Beschreibung, wie später die Messdaten zu interpretieren sind (Metric).
3. Messplan erstellen/Datenerhebung festlegen.
4. Daten erheben und validieren.
5. Analyse und Interpretation der Daten.
6. Ergebnisse sichern.

Abb. 3: Phasen des GQM-Ansatzes

Der Vorteil dieses Verfahrens liegt darin, dass nur das gemessen wird, was dazu beiträgt, die gesetzten Ziele zu erreichen. Außerdem wird die Interpretation der ausgewählten Metriken festgelegt, d. h. man wird nach den Messungen nicht mit schlecht interpretierbaren Zahlen konfrontiert.

Ein pragmatischer Ansatz zur Qualitätsbeurteilung

Welche Empfehlungen kann man aus diesen theoretischen Ansätzen für die Sicherstellung, Messung und Beurteilung der Qualität für das eigene Entwicklungsprojekt ableiten? Dazu einige Ausführungen am Beispiel der Gestaltung von Benutzeroberflächen. Das User Interface bestimmt im erheblichen Maße die Akzeptanz der künftigen Benutzer und damit auch wesentlich das Ausmaß der Erfüllung der Funktionalität. Um die Qualität der Benutzeroberfläche zu messen und letztendlich auch sicherzustellen, existieren eine Reihe von Anhaltspunkten:

1. Identifikation der Zielgruppe: Allgemeine Vorschriften, wie eine Benutzerschnittstelle zu gestalten ist, können nicht zielführend sein. Zur Verdeutlichung zwei Beispiele: Im Consumer-Bereich werden an das User Interface andere Anforderungen gestellt, als im professionellen Arbeitsumfeld. Eine CAD-Anwendung für die Konstruktion von Spezialteilen sollte mit einer neutralen – der Professionalität angemessenen – Oberfläche daherkommen. Die Kombination aus klassischem Menü und konfigurierbaren Symbolleisten ist einer Ribbon-Menüleiste durchaus vorzuziehen. Den Anwendern kann eine gewisse Komplexität und der damit einhergehende Einarbeitungsaufwand durchaus zugemutet werden. Anders verhält es sich bei einer Grafikanwendung (zum Beispiel zur Bildbearbeitung) für den anonymen Verbrauchermarkt. Komplexität ist auf jeden Fall weitestgehend, ggf. auch zu Lasten einiger „Sonderfunktionen“, zu vermeiden. Um seine Zielgruppe besser kennenzulernen, hat sich das so genannte Persona-Konzept etabliert (Kasten: „Das Persona-Konzept: Der Zielgruppe ein Gesicht geben“).

Das Persona-Konzept: Der Zielgruppe ein Gesicht geben
Personas sind typische Nutzer, die die Zielgruppen Ihres Produkts oder Ihrer Anwendung repräsentieren. Sie geben dem oft unbekannten Nutzer im Entwicklungsprozess einer Anwendung von Anfang an ein Gesicht und damit dem Entwicklungsteam klare Vorstellungen darüber, was ihre späteren Nutzer auszeichnet. Personas erleichtern eine nutzerzentrierte Entwicklung und eignen sich daher besonders in der frühen Konzeptions- und Designphase von Software. Falls man auf Informationen und Daten aus früheren Projekten zurückgreifen kann, empfiehlt es sich, diese zunächst im Sinne einer Sekundäranalyse auszuwerten. Dieses Vorgehen ist nicht so kostenintensiv, wie die Neuerhebung von Daten (Primäranalyse). Ebenfalls bekommt man schnell einen ersten Überblick über die relevanten Zielgruppen. Liegen keine oder keine ausreichenden Daten über die künftigen (typischen!) Nutzer vor, so sind die neu zu erheben. Es bieten sich die Verfahren der qualitativen Datenerhebung, wie Gruppendiskussionen, Onlineforen oder auch Einzelinterviews an. Nach der Datenerhebung kommt der anspruchsvolle Vorgang, die Informationen zu sichten, zu sortieren und Cluster im Sinne von typischen Nutzergruppen zu bilden. Die Konzeption von Personas verläuft sehr konkret, d. h. dem Nutzer aus einem Cluster werden ein Name, ein Alter, ein Aussehen und meist auch Wünsche, Fähigkeiten, Meinungen und Hobbies zugeordnet. Ein Bild (zum Beispiel ein Cartoon) visualisiert die Personas und gibt Ihren Nutzern ein Aussehen (Abb. 4). Personas machen es für die Beteiligten einfacher, sich während der Entwicklung in die Perspektive der User hineinzuversetzen. Das Ziel ist es, die Zielgruppe genauer kennenzulernen, damit die Bedürfnisse an die Software herauszuarbeiten und diese Erkenntnisse in konkrete Anforderungen zu übertragen.
Abb. 4: Personas geben den typischen Nutzergruppen ein Bild

2. Benutzerfeedback: Eine Rückmeldung der (künftigen) Benutzer ist einer der wichtigen Maßstäbe, um zu beurteilen, ob die Anforderungen umfassend berücksichtigt wurden. Dazu ist die Auslieferung früher(!) Prototypen ein probates Mittel. Derartige Prototypen müssen nicht mit dem vollen Funktionsumfang der kommenden Version ausgestattet sein. Zu Beginn des Entwicklungsprozesses genügt es vielmehr, wenn die Bedienphilosophie zu erkennen ist. Das frühe Prototyping ist direkt in den Entwicklungsprozess einzubinden (Kasten: „Prototyping“).

Prototyping
Schnelles Prototyping ist ein gutes Hilfsmittel der Anforderungsdefinition. Dabei gibt es verschiedene Ansätze, die parallel und/oder nacheinander eingesetzt werden können. Empfehlenswert ist es, sich mit einigen Tools vertraut zu machen, um diese im Bedarfsfall zur Verfügung zu haben. Zum Anfang bietet sich sicherlich eine Präsentation zu einem Grobentwurf der Benutzeroberfläche an; mit weiterem Fortschritt im Projekt kann diese gegen lauffähige Prototypen ersetzt werden. Der Vorgang der Protypenerstellung ist in den Prozess der Softwareentwicklung (Software Lifecycle) zu integrieren. Verschiedene Arten von Prototypen kommen dabei in unterschiedlichen Phasen zur Anwendung. Zum Beispiel zeigt Abbildung 5 die Integration des Prototyping in den iterativen Softwareentwicklungsprozess. Es gilt auf jeden Fall: Lieber einen Prototyp zu viel erstellt und entsprechendes Feedback eingeholt, als den Bedarf des Kunden bzw. des Auftraggebers nicht umfassend zu berücksichtigen.
Abb. 5: Integration des Prototyping in den iterativen Softwareentwicklungsprozess

3. The State of the Art: Ohne dass dieses schriftlich irgendwo fixiert ist, gibt es einen Quasistandard, was die Gestaltung von Benutzeroberflächen anbelangt. Keine Frage, gute Software kann durchaus zehn Jahre benutzt und auch akzeptabel in der Bedienung sein. Dennoch sind aktuelle Programmversionen bereits klar am Design gegenüber früheren Versionen zu unterscheiden. Ein Beispiel: Ein aktueller Trend für Desktopanwendungen ist eine Orientierung am Flat-Design, abgleitet aus der Kacheloptik von Apps. Dieser Trend umfasst u. a. eine Reduktion der Bedienelemente auf das absolute Minimum, um genügend Platz für den Inhalt auf der Oberfläche zu bieten und eine zurückhaltende Farbgestaltung. Betrachtet man zum Beispiel die aktuelle Version von Microsoft Office 2013 und im Vergleich dazu die Versionen 2003. Daraus ist abzuleiten: Ein Programm, das auf den Markt gebracht wird, sollte die zum Zeitpunkt aktuellen Trends unbedingt berücksichtigen. Damit kann man sicherstellen, dass die Software sich auch nach ein paar Jahren nicht als „Fremdkörper“ anfühlt.

4. Einhaltung von Richtlinien: Die Hersteller der Betriebssysteme haben eine klare Vorstellung davon, mit welchem Look and Feel sich die Anwendungen präsentieren sollen. In so genannten Designrichtlinien geben sie Hinweise zur Gestaltung der Benutzeroberfläche, zur Anordnung der Steuerelemente usw. Es ist empfehlenswert, diese Richtlinien vor dem Entwurf des User Interface zu studieren und diese weitgehend einzuhalten. Die Orientierung an Designstandards erleichtert es dem Benutzer, schneller mit der Anwendung zurechtzukommen. Dies ist einer der Hauptfaktoren für die Akzeptanz und damit für das Bestehen am Markt.

5. Allgemeine Qualitätskriterien: Über die Empfehlungen der vorangegangenen Punkte hinaus sollte man die Ergebnisse der eigenen Entwicklung auf die Einhaltung der oben beschriebenen allgemeinen Qualitätsstandards prüfen. Allgemeine Qualitätskriterien für die Benutzeroberfläche sind zum Beispiel, dass Dialogfelder gegen Fehleingaben gut abgesichert werden oder das mit der Vorgabe von sinnvollen Standardwerten die Arbeit des Nutzers erleichtert wird.

6. Technische Qualität: Zunehmend muss auch auf die technische Qualität geachtet werden. Das Stichwort ist die Entkopplung von den anderen Schichten. Dazu müssen moderne Methoden der Datenbindung, zum Beispiel die strikte Verwendung des Model View ViewModel (MVVM) Pattern, angewendet werden. Unter Windows wird dieses Konzept sehr gut vom Framework Windows Presentation Foundation (WPF) unterstützt. Andere Systeme gehen ähnliche Wege. Ein weiterer Aspekt zur Sicherung der technischen Qualität ist die Durchführung automatisierter Tests. Damit dies möglich ist, muss der technische Aufbau des User Interface bestimmten Forderungen genügen.

Fazit und Ausblick

Die Definition und Messung von Qualität ist und bleibt ein schwieriges Feld. Überraschenderweise haben die Kriterien der frühen Ansätze nach wie vor eine weitgehende Gültigkeit. Das zeichnet allgemeingültige Konzepte aus. In allen Konzepten finden sich bestimmte Basiskriterien (wie der Grad der Anforderungserfüllung, die Zuverlässigkeit und eine weitgehende Fehlerfreiheit). Somit wird auch bei diesem Thema deutlich, dass eine systematische Erhebung der Anforderungen und eine gute Dokumentation die Voraussetzung für eine qualitativ hochwertige Software sind. Nur wenn man die Sollkriterien kennt, kann man auch den Grad der Zielerreichung – nach welcher Methode auch immer – bestimmen. Trotz der großen Unsicherheiten, die die Messung von Softwarequalität mit sich bringt, sollte man als Entwickler das Thema unter keinen Umständen ignorieren. Allein die Beschäftigung mit Qualitätsaspekten und die Suche nach Kriterien führen dazu, dass man die eigene Qualität kritisch hinterfragt. In der kommenden Ausgabe beschäftigen wir uns mit den eigentlichen Prozessen der Softwareentwicklung. Wir fragen danach, ob man die Effektivität des Entwicklungsprozesses – trotz aller Individualität – messen kann. Eine interessante Fragestellung, insbesondere für die Leitung von Entwicklungsteams, um mögliche Wirtschaftlichkeitsreserven zu identifizieren.

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Aufmacherbild: Advertising concept: computer keyboard with word Quality via Shutterstock / Urheberrecht: Maksim Kabakou

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -