nach oben
Meine Merkliste
Ihre Merklisteneinträge speichern
Wenn Sie weitere Inhalte zu Ihrer Merkliste hinzufügen möchten, melden Sie sich bitte an. Wenn Sie noch kein Benutzerkonto haben, registrieren Sie sich bitte im Hanser Kundencenter.

» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.
Ihre Merklisten
Wenn Sie Ihre Merklisten bei Ihrem nächsten Besuch wieder verwenden möchten, melden Sie sich bitte an oder registrieren Sie sich im Hanser Kundencenter.
» Sie haben schon ein Benutzerkonto? Melden Sie sich bitte hier an.
» Noch kein Benutzerkonto? Registrieren Sie sich bitte hier.

« Zurück

Ihre Vorteile im Überblick

  • Ein Login für alle Hanser Fachportale
  • Individuelle Startseite und damit schneller Zugriff auf bevorzugte Inhalte
  • Exklusiver Zugriff auf ausgewählte Inhalte
  • Persönliche Merklisten über alle Hanser Fachportale
  • Zentrale Verwaltung Ihrer persönlichen Daten und Newsletter-Abonnements

Jetzt registrieren
Merken Gemerkt
Software-Qualität - Software-Qualität

Was ist Software-Qualität?

Auszug aus
Ernest Wallmüller

Software Quality Engineering

07/2011, 426 Seiten, € 31,99
ISBN: 978-3-446-43019-8
S. 7-11

Grundlegende Arbeiten zu dieser Frage hat D. A. Garvin von der Harvard-Universität geliefert [Garv84]. Er unterscheidet aufgrund von empirischen Untersuchungen fünf Ansätze, um zu einer Qualitätsvorstellung zu kommen.

1 - Der „transzendente“ Ansatz

Danach ist Qualität universell erkennbar und ein Synonym für kompromisslos hohe Standards und Ansprüche an die Funktionsweise eines Produkts. Die Vertreter dieses Ansatzes glauben allerdings, dass sich Qualität in diesem Sinne nicht präzise definieren oder messen lässt. Ebenso meinen sie, dass Qualität nur durch Erfahrung bewertet werden kann. Der Begriff der Qualität kann genauso wenig implizit definiert werden wie z. B. jener der Schönheit. Vertreter dieses Ansatzes meinen, es genüge, ein Software-Produkt am Bildschirm durch seine Handhabung zu erleben.

2 - Der produktbezogene Ansatz

Die Vertreter dieses Ansatzes glauben, dass die Qualität präzise messbar ist. Danach spiegeln Qualitätsdifferenzen Unterschiede in der vorhandenen, beobachtbaren Quantität bestimmter Eigenschaftsausprägungen wider, die in einem Produkt festgestellt werden können. Dieser Ansatz erlaubt es im Prinzip, eine Rangordnung von verschiedenen Software-Produkten der gleichen Kategorie anzugeben. In den 70er Jahren des letzten Jahrhunderts haben amerikanische Auftraggeber von Großprojekten begonnen, Software-Bewertungsmethoden zu entwickeln, um bei der Beschaffung und Entwicklung unterschiedliche Produkte von Software-Lieferanten besser beurteilen zu können. Es wurden Merkmalsmodelle wie z. B. jenes von McCall [McCa77] und Bewertungsverfahren entwickelt, die es erlauben, Produkte qualitativ zu evaluieren und zu klassifizieren.

3 - Der anwenderbezogene Ansatz

Hierbei liegt die Auffassung vor, dass die Qualität durch den Produktbenutzer festgelegt wird und weniger durch das Produkt selbst. Danach haben verschiedene Produktbenutzer unterschiedliche Wünsche und Bedürfnisse, und diejenigen Produkte, die diese Bedürfnisse am besten befriedigen, werden als qualitativ hochstehend angesehen. Beispielsweise werden bei der Einführung des Portals im Finanzbereich eines Unternehmens zunächst die Rollen (z. B. Senior Management, Kostenstellenverantwortliche, Controller, etc.) definiert. Durch eine Web-Oberfläche wird den unterschiedlichen Benutzerrollen der Zugriff auf Funktionen ermöglicht. Das „Look and Feel“ der Webseiten kann rollen-, unternehmens- und branchenspezifisch den Anforderungen der Nutzer an ihren Arbeitsplatz angepasst werden.

4 - Der prozessbezogene Ansatz

Nach diesem Ansatz ist Qualität gleichzusetzen mit der Einhaltung von Spezifikationen, mit der Idealvorstellung, eine Tätigkeit zur Produkterstellung gleich das erste Mal richtig auszuführen. Diese Vorstellung von Qualität ist auf die heutige Wirtschaft und Industrie ausgerichtet. Im Mittelpunkt steht der Entwicklungs- bzw. Produktionsprozess, der rigoros kontrolliert, auditiert und inspiziert wird, um die Ausschuss- und Nachbearbeitungskosten (Rework-Anteil) zu verringern. Dabei spielt der Automatisierungsgrad eine große Rolle. Insbesondere Roboter und Automaten sollen gewährleisten, dass Produktionsprozesse soweit als möglich mängelfrei und reibungslos abgewickelt werden. Für Software-Projekte bedeutet dies, dass durch geeignete Auswahl und Anpassung (Tailoring) von Prozess-/Vorgehensmodellen und durch ausreichenden Einsatz prüfender (analytischer) Qualitätsmaßnahmen wie z. B. durch Reviews und Audits sichergestellt ist, dass Prozess- und Produktspezifikationen erfüllt werden. Weiters kann durch modellgetriebene Software-Entwicklungsverfahren bzw. einen hohen Automatisierungsgrad beim Testen (z. B. bei Modultests, Regressionstests) der Prozess wirksam ausgeführt werden. Der Vorteil dieses Ansatzes ist, dass durch Prozesskostenrechnung, Quality Function Deployment (QFD) und Kundenorientierung auch die Eigenschaften der Ansätze von 2, 3 und 5 erfüllt werden können.

5 - Der Preis-Nutzen-bezogene Ansatz

Bei diesem Ansatz wird ein Bezug zwischen Kosten, Nutzen und Qualität hergestellt. Ein Qualitätsprodukt ist in dieser Denkweise ein Erzeugnis, das einen bestimmten Nutzen zu einem akzeptablen Preis oder eine Übereinstimmung mit Spezifikationen zu akzeptablen Kosten erbringt. Beispielsweise möchte der Finanzvorstand eines Energieversorgungsunternehmens mit einer neuen Informatik-/Software-Lösung für das Rechnungswesen eine jährliche Einsparung von ca. 1,5 Millionen Euro realisieren. Die neue Lösung kostet ca. 6 Millionen Euro, und er rechnet mit einer Amortisierung dieser Investition nach 4 Jahren.

Neben diesen Ansätzen, die versuchen, den Begriff Qualität durch Umschreibung zu verdeutlichen, gibt es auch eine Reihe von Versuchen, den Begriff Qualität zu definieren. Je nach Präferenz und individueller Auffassung des Einzelnen werden dabei verschiedene Akzente gesetzt. Im Folgenden werden verschiedene Qualitätsbegriffe diskutiert und ihre Anwendbarkeit für Software-Produkte geprüft.

In der Norm ISO 8402 heißt es:

„Qualität ist die Gesamtheit von Merkmalen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Erfordernisse zu erfüllen.“

Diese Definition geht von einem strengen Kunden-/Lieferantenverhältnis aus. Es lassen sich aus dieser Definition zwei wesentliche Schlussfolgerungen ziehen:

  • Die Eignung ein und derselben Sache kann für verschiedene Verwendungen unterschiedlich sein. Beispielsweise ist ein komplexes, alles an Funktionalität bietendes Konfigurationsmanagement-Tool für kleine Software-Projekte (Aufwand < 6 Personenmonate) schlechter geeignet als ein einfacheres Tool, das weniger an Funktionalität bietet.
  • Die Erfordernisse ergeben sich aus dem Verwendungszweck des Software-Produkts. Ein Air-Traffic-Control-System hat ca. 6000 Anforderungen. Zur Verwaltung und Prüfung dieser Anforderungen wird beispielsweise ein Anforderungsdatenbanksystem eingesetzt. Mit diesen Werkzeugen ist eine ausreichende Prüf- und Verfolgbarkeit der Anforderungen möglich.

Die ISO 8402-Definition für Qualität wurde durch die Definition der Norm EN ISO 9000:2005 (die Norm zum Thema Qualitätsmanagement) abgelöst. Qualität wird hier als „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“ definiert. Die Qualität gibt somit an, in welchem Maße ein Produkt (Ware oder Dienstleistung) den bestehenden Anforderungen entspricht. Die Benennung Qualität kann zusammen mit Adjektiven wie schlecht, gut oder ausgezeichnet verwendet werden. Inhärent bedeutet (im Gegensatz zu „zugeordnet“) „einer Einheit innewohnend“, insbesondere als ständiges Merkmal. Damit sind objektiv messbare Merkmale wie z. B. Code-Länge oder Code-Komplexität gemeint. Nicht inhärent sind subjektiv zugeordnete Beschreibungen wie „schön“ oder auch der Preis, weil diese eben nicht objektiv messbar sind. Der Preis oder ein persönliches Urteil sind also nicht Bestandteil der Qualität. Durch die Definition einer Zielgruppe und Meinungsumfragen kann das subjektive Empfinden dieser Zielgruppe ermittelt, ein inhärentes Merkmal definiert und damit „messbar“ und Bestandteil der Qualität werden.

Vereinbarungen über Qualitätsanforderungen, aber auch eine einfache und klare Kommunikation für die Software-Ingenieure, was eigentlich die Qualität eines Software-Produkts ausmacht, erfordern, dass viele Aspekte von Qualität formal definiert und diskutiert werden müssen. Ein Software-Ingenieur sollte die Bedeutung der Qualitätskonzepte und Merkmale und ihren Wert für die Entwicklung, den Betrieb und die Wartung ausreichend kennen.

Die IEEE-Norm für Software-Qualität (IEEE Std 729-1983) hebt die Erwartungen der Kunden hervor:

(1) die Gesamtheit der Funktionen und Merkmale für ein Software-Produkt, das die Fähigkeit hat, gegebene Bedürfnisse zu befriedigen, zum Beispiel, indem es den Spezifikationen entspricht;
(2) das Ausmaß der gewünschten Kombination von Eigenschaften, über das die Software verfügt;
(3) das Ausmaß, in dem ein Kunde oder Anwender erkennt, dass die Software seinen unterschiedlichen Erwartungen entspricht;
(4) die zusammengesetzten Merkmale der Software, die bestimmen, bis zu welchem Grad die verwendete Software den Erwartungen der Kunden gerecht wird.

Diese Definition enthält die Garvin-Ansätze A2 und A3. Der prozessorientierte Ansatz A4 ist nicht zu erkennen. Wir definieren daher Software-Qualität als

„die Summe aller relevanten Eigenschaften eines Software-Produkts, mit denen seine Kunden zufriedengestellt werden, und die Summe der dazu notwendigen Eigenschaften von Software-Prozessen wie z. B. erreichte Reifegrade, die zur Erstellung, zum Betrieb und zur Pflege gefordert werden“.

Milberg und Schuh [Milb02] sehen in dieser Definition die Vorteile darin, dass mit Produktqualität die Kunden begeistert werden sollen und mit der Prozessqualität der Gewinn des Unternehmens gesichert wird.

Diese Definition umfasst sowohl die Produkt- als auch die Prozessseite. Eine weitere Ergänzung dieser Definition umfasst explizite Repräsentationen des Wissens über bestimmte Qualitätsaspekte und deren Manipulation.

Wenn wir uns nicht nur mit der Bewertung von fertigen Software-Produkten zufrieden geben, sondern Qualität auch konstruktiv realisieren wollen, müssen wir einen Bewertungsansatz für den Entwicklungs- und Pflegeprozess aufstellen. Das bedeutet, dass wir Merkmale und Bewertungsmaßstäbe auch für Zwischen-/Endprodukte und für deren Entwicklungsaktivitäten in allen Phasen des Prozesses benötigen, was durch den Einsatz von prozessorientierten Best-Practice-Modellen wie CMMI-DEV, CMMI-SVC oder ISO 15504 oder anderer Modelle erfolgt.

Gleichzeitig sollte uns bewusst sein, dass Qualität nichts Absolutes ist, sondern immer relativ zu gegebenen Erfordernissen gesehen werden muss. Daraus leiten wir ab, dass eine Qualitätsbewertung immer einen Vergleich beinhaltet zwischen den aus den gegebenen Erfordernissen abgeleiteten Qualitätsvorgaben (Soll-Werte) und den tatsächlich erreichten Ausprägungen der Merkmale (Ist-Werte).

Eine Voraussetzung für einen qualitätsbewussten Umgang mit Software ist, diese als Produkt zu sehen. Wir meinen damit, dass eine aktuelle und ausreichende Dokumentation, in der neben Programmen auch die Daten beschrieben werden, existiert, um überhaupt von einem Produkt sprechen zu können. Ein Software-Produkt (siehe IEEE Std 729, Glossar der Software-Engineering-Terminologie) besteht aus den Teilen Sourcecode, Objektcode und Dokumentation.

Auszug aus
Ernest Wallmüller

Software Quality Engineering

07/2011, 426 Seiten, € 31,99
ISBN: 978-3-446-43019-8
S. 7-11
Literaturhinweis

[Asam86] Asam R., Drenkard N., Maier H.-H.: Qualitätsprüfung von Softwareprodukten; Siemens AG 1986.

[Azum85] Azuma M., Sunazuka T., Yamagishi N.: Software Quality Assessment Technology; Proc. of 8th Int. Conf. on Software Engineering, London, 1985, pp. 142–148.

[Boeh76] Boehm B., Brown J. R., Lipow M.: Quantitative Evaluation of Software Quality; Proc. of 2nd Int. Conf. on Software Engineering, 1976, pp. 592–605.

[Boeh78] Boehm B.: Characteristics of Software Quality; North-Holland 1978.

[Garv84] Garvin D. A.: What does Product Quality Really Mean?; Sloan Management Review, Fall 1984, pp. 25–43.

[McCa77] McCall J. A., Richards P. K.,Walters G. F.: Factors in Software-Quality,Vol. I-III; Rome Air Development Center 1977.

[Wall87] Wallmüller E.: Aufbau einer Software-Qualitätssicherung in einer industriellen Umgebung; Informationstechnik 2, 1987, pp. 103–107.

[Will85] Willmer H.: Systematische Software-Qualitätssicherung anhand von Qualitäts- und Produktmodellen; Springer 1985.

[Zopf88] Zopf S.: Praktisches Vorgehen zur Sicherung definierter Software-Qualitätsziele; Tagungsband zur 3. Softwaretest-Fachtagung 1988.

zusätzliche Links

Weitere Informationen zum Thema Softwareentwicklung finden Sie auch im IT-Blog Hanser Update .

DIN EN ISO 9001:2015

Zum ISO 9001:2015 Special

Prozesswelt

Serie zum Thema Prozesse, veröffentlicht von QM-Experten deutscher Unternehmen gemeinsam mit der N5 GmbH und der Fachzeitschrift QZ

Zur Prozesswelt