{"id":4566,"date":"2019-04-08T12:33:39","date_gmt":"2019-04-08T10:33:39","guid":{"rendered":"https:\/\/dev.wi-lex.de\/index.php\/software-qualitaetsmanagement\/"},"modified":"2022-03-08T18:47:35","modified_gmt":"2022-03-08T17:47:35","slug":"software-qualitaetsmanagement","status":"publish","type":"page","link":"https:\/\/wi-lex.de\/lexikon\/entwicklung-und-management-von-informationssystemen\/systementwicklung\/management-der-systementwicklung\/software-qualitaetsmanagement\/","title":{"rendered":"Software-Qualit\u00e4tsmanagement"},"content":{"rendered":"

Georg Herzwurm<\/a>,\u00a0Martin Mikusz<\/span><\/p>\n

\n

Das Software-Qualit\u00e4tsmanagement befasst sich mit der Planung, Lenkung und Pr\u00fcfung der Qualit\u00e4t von Softwareprodukten und -entwicklungsprozessen. Es beinhaltet sowohl F\u00fchrungsaufgaben zur Festlegung der Qualit\u00e4tspolitik, der Qualit\u00e4tsziele und der Verantwortung f\u00fcr Qualit\u00e4t, wie auch Ma\u00dfnahmen zur Erf\u00fcllung vorgegebener Qualit\u00e4tsanforderungen an Softwareprodukte und -prozesse.<\/em><\/p>\n

Produkt- und prozessorientiertes Software-Qualit\u00e4tsmanagement<\/h2>\n

Die Ausrichtung des Software-Qualit\u00e4tsmanagements h\u00e4ngt wesentlich von dem Qualit\u00e4tsverst\u00e4ndnis einer software-entwickelnden Organisation ab. Selbst in den einschl\u00e4gigen Normenwerken wird der Qualit\u00e4tsbegriff unterschiedlich definiert [Balzert 2008, S. 461]. Eine sehr aufschlussreiche Definition von Qualit\u00e4t findet sich in der DIN 55350:<\/p>\n

\u201eQualit\u00e4t ist die Gesamtheit von Eigenschaften und Merkmalen eines Produkts oder einer T\u00e4tigkeit, die sich auf deren Eignung zur Erf\u00fcllung gegebener Erfordernisse bezieht\u201c [DIN 55350, Teil 11:1995, zitiert nach Balzert 2008, S. 460].<\/p>\n

Dieser Qualit\u00e4tsbegriff spiegelt den produkt- und prozessbezogenen Qualit\u00e4tsansatz wieder. Demnach bezieht sich Qualit\u00e4t als die Gesamtheit von Eigenschaften und Merkmalen zur Erf\u00fcllung gegebener Erfordernisse sowohl auf das Produkt, als auch auf den Prozess der Produktentstehung (\u201eT\u00e4tigkeit\u201c). Entsprechend ist zwischen einem produkt- und prozessorientierten Software-Qualit\u00e4tsmanagement zu unterscheiden.<\/p>\n

W\u00e4hrend Ma\u00dfnahmen des produktorientierten Qualit\u00e4tsmanagements (vgl. Qualit\u00e4tsma\u00dfnahmen<\/a>) direkt an der zu erstellenden Software inklusive deren Zwischenprodukten ansetzen (bspw. Inspektion des Anforderungs- oder Spezifikationsdokuments als direkte \u00dcberpr\u00fcfung auf Einhaltung der vorher festgelegten Qualit\u00e4tsmerkmale), gehen Ma\u00dfnahmen des prozessorientierten Qualit\u00e4tsmanagements einen Schritt weiter.<\/p>\n

Prozessorientiertes Qualit\u00e4tsmanagement bezieht sich auf den Entwicklungsprozess und beinhaltet wiederum die \u00dcberpr\u00fcfung auf Einhaltung der vorher festgelegten Qualit\u00e4tsmerkmale \u2013 nun jedoch der des Prozesses (bspw. in Audits; vgl. Qualit\u00e4tsma\u00dfnahmen<\/a>). Des Weiteren sind hierunter Ma\u00dfnahmen zu verstehen, die a priori sicherstellen, dass der Prozess bestimmte Eigenschaften besitzt (bspw. Anwendung von Checklisten oder Richtlinien zur Testprozessdurchf\u00fchrung).<\/p>\n

Ein qualitativ hochwertiger Prozess im Sinne des prozessorientierten Qualit\u00e4tsmanagements ist ein stabiler und damit wiederholbarer sowie hinsichtlich Kosten, Zeit und Qualit\u00e4t vorhersehbarer, planbarer und steuerbarer Softwareentwicklungsprozess. Nur ein solcher, nicht ausschlie\u00dflich vom Zufall, der Kreativit\u00e4t und Leistungsbereitschaft einzelner Mitarbeiter abh\u00e4ngiger Prozess, kann zu der Erstellung qualitativ hochwertiger Software f\u00fchren [Mellis 2004, S. 327ff.].<\/p>\n

Um diese Ziele zu erreichen sind zahlreiche Prozessstandards und -normen wie bspw. das CMMI <\/a>entwickelt worden(zu einer deutschsprachigen Darstellung des CMMI siehe [Kneuper 2007]). Die Annahmen und die Wirksamkeit der Gestaltungsma\u00dfnahmen des prozessorientierten Qualit\u00e4tsmanagements sind nicht endg\u00fcltig empirisch nachgewiesen [Mellis 2004, S. 353ff.]. Denn die Beziehung zwischen der Prozess- und der Produktqualit\u00e4t ist in der Softwareentwicklung wesentlich komplexer als in der produzierenden Industrie [Sommerville 2012, S. 713].<\/p>\n

Qualit\u00e4tsplanung<\/h2>\n

\u201eAufgabe der Qualit\u00e4tsplanung ist es, die Qualit\u00e4tsanforderungen an den Prozess und das Produkt in \u00fcberpr\u00fcfbarer Form festzulegen\u201c [Balzert 2008, S. 479].<\/p>\n

Bei der Qualit\u00e4tsplanung werden nicht an jedes Softwareprodukt und nicht an jeden Softwareentwicklungsprozess dieselben Anforderungen gestellt. So sind zun\u00e4chst bei der Qualit\u00e4tszielbestimmung Qualit\u00e4tsstufen zu definieren und es ist festzulegen, welche Qualit\u00e4tsstufen erreicht werden sollen [Balzert 2008, S. 471ff.]. Standards in verschiedenen Dom\u00e4nen im Bereich von Embedded Systems k\u00f6nnen in diesem Punkt als Best Practice aufgefasst werden: Sie sehen durchg\u00e4ngig \u00fcber den gesamten Entwicklungsprozess abgestufte Regelungen, in Abh\u00e4ngigkeit von der Qualit\u00e4ts- bzw. Kritikalit\u00e4tstufe vor (bspw. DIN 50128, DIN 61508, RTCA\/DO 178B) [Liggesmeyer 2009, S. 378f. und 388f.].<\/p>\n

Der Geltungsbereich von Qualit\u00e4tsanforderungen kann sich auf eine Software produzierende Einheit, ein Softwareprodukt oder dessen Teile, sowie auch auf den gesamten bzw. auf Teile des Softwareentwicklungsprozesses erstrecken. Abbildung\u00a01 zeigt Aspekte der Qualit\u00e4t, die den verschiedenen Betrachtungseinheiten zugeordnet werden k\u00f6nnen. Eine absolute Notwendigkeit und zugleich eine gro\u00dfe Herausforderung ist dabei die koh\u00e4rente Ausrichtung der Unterziele (bspw. auf Projektebene) auf die \u00fcbergeordneten Qualit\u00e4tsziele bis hin zu den Unternehmenszielen.<\/p>\n

\"abb1\"<\/p>\n

Abb. 1: Betrachtungseinheiten von Qualit\u00e4t [Fr\u00fchauf, Ludewig, Sandmayr 2002, S. 129]<\/p>\n

Mit dem Qualit\u00e4tsmanagement werden grunds\u00e4tzlich wirtschaftliche Ziele verfolgt. Es gilt sowohl im Hinblick auf das Produkt wie auch auf den Prozess das wertorientierte Qualit\u00e4tsverst\u00e4ndnis:<\/p>\n

\u00a0\u201eQualit\u00e4t ist eine Funktion von Kosten und Nutzen. Ein Qualit\u00e4tsprodukt ist ein Erzeugnis, das einen bestimmten Nutzen zu einem akzeptablen Preis erbringt\u201c [Balzert 2008, S. 460].<\/p>\n

Das wirtschaftliche Ziel des Qualit\u00e4tsmanagements liegt im Finden eines Optimums aus den Fehlerkosten (Fehlerfolgekosten und Fehlerbehebungskosten) und den gegenl\u00e4ufigen Fehlerverh\u00fctungskosten (Pr\u00fcfkosten und Kosten von pr\u00e4ventiven Ma\u00dfnahmen). Unter den Begriffen \u201eGood Enough Quality\u201c, Value Based Software Engineering (VBSE) und Ans\u00e4tzen im Umfeld der risikobasierten Softwareentwicklung (bspw. Risikobasiertes Testen) finden sich zahlreiche Ans\u00e4tze, die das wertorientierte Qualit\u00e4tsverst\u00e4ndnis konkret umsetzen.<\/p>\n

Bedauerlicherweise lassen sich in der Softwareentwicklung weder die Fehlerkosten und Fehlerverh\u00fctungskosten exakt angeben, noch lassen sich entsprechende Qualit\u00e4tsanforderungen an den Prozess und an das Produkt ohne Schwierigkeiten quantifizieren. Doch auch wenn es schwierig ist, Softwarequalit\u00e4t zu messen, besteht Konsens dar\u00fcber, dass die \u201eingenieurm\u00e4\u00dfige Qualit\u00e4tssicherung undenkbar ohne die Quantifizierung von Soll- und Istwerten\u201c ist [Rombach 1993, S. 260]. Weiterf\u00fchrende Literatur zu Ma\u00dfen und Metriken in der Softwareentwicklung findet sich bspw. in [Balzert 2008, S. 377ff.; Ludewig, Lichter 2013, S. 295ff.].<\/p>\n

Qualit\u00e4tsplanung des Softwareproduktes<\/h3>\n

Die Qualit\u00e4tsplanung des Softwareproduktes ist ein wesentlicher Bestandteil des Requirements Engineering-Prozesses<\/a>, bei dem die Anforderungen <\/a>des Auftraggebers an das zu entwickelnde Produkt aufgenommen, analysiert, spezifiziert und bewertet werden [bspw. Pohl 2008]. Funktionale Anforderungen beschreiben dabei, \u201ewas\u201c das System tun sollte. Hinzu kommen weitere, sog. Qualit\u00e4tsanforderungen (teilw. auch als nicht funktionale Anforderungen bezeichnet). Sie definieren die gew\u00fcnschten Qualit\u00e4tsmerkmale <\/a>wie bspw. Performanz oder Zuverl\u00e4ssigkeit\u00a0des geplanten Systems, einer Systemkomponente oder einer Funktion [Pohl 2008, S. 15f.].<\/p>\n

Die Ableitung von Qualit\u00e4tsanforderungen aus einem Produktqualit\u00e4tsmodell (bspw. ISO 25010 oder ein unternehmenseigenes Qualit\u00e4tsmodell), die Festlegung der zu erreichenden Qualit\u00e4tsstufen und die Priorisierung der teilweise konflikt\u00e4ren Qualit\u00e4tsanforderungen ist mit die Aufgabe des Qualit\u00e4tsmanagements. Das Ergebnis der Qualit\u00e4tsplanung des Softwareproduktes findet in Form von Qualit\u00e4tsanforderungen Eingang in das\u00a0Lastenheft <\/a>als das fachliche Ergebnisdokument der Planungsphase einer Softwareentwicklung. Im weiteren Verlauf der Softwareentwicklung werden die funktionalen sowie die Qualit\u00e4tsanforderungen weiter verfeinert und in formale Produktmodelle und Spezifikationen \u00fcberf\u00fchrt. Hieraus resultiert das\u00a0Pflichtenheft<\/a>, das wiederum Grundlage f\u00fcr die sp\u00e4tere Ableitung der Softwarearchitektur <\/a>und der Implementierung darstellt [Balzert 2009, S. 443ff.].<\/p>\n

Qualit\u00e4tsplanung des Softwareprozesses<\/h3>\n

Von einer Softwareentwicklung wird mehr erwartet, als dass das resultierende Produkt die funktionalen und die Qualit\u00e4tsanforderungen erreicht. Denn geschieht dies zwar, jedoch nur mit erheblichen Termin- und Kosten\u00fcberschreitungen, so kann nicht von einem qualitativen Entwicklungsprozess gesprochen werden (vgl. Ausf\u00fchrungen zum\u00a0„Teufelsquadrat“ der Softwareentwicklung bspw. in [Balzert 2008, S. 196f.]). Insofern bestimmen sich die Merkmale des Prozesses nicht nur aus den Qualit\u00e4tsanforderungen an das Produkt (bspw. erfordern hohe Anforderungen an die Zuverl\u00e4ssigkeit von sicherheitskritischen Systemen den Einsatz spezieller formaler Methoden der Softwareentwicklung).<\/p>\n

Neben den Qualit\u00e4tsanforderungen an das Produkt sind weitere Anforderungen an den Prozess zu beachten. Dies kann bspw. die Vorgabe der Einhaltung bestimmter zeitlicher bzw. finanzieller Restriktionen und die Notwendigkeit der Einhaltung bestimmter Prozessrichtlinien wie bspw. bei der Entwicklung von milit\u00e4rischen oder medizinischen Systemen sein (vgl. [Mellis 2004, S. 39ff.] zu den Rahmenbedingungen eines Softwareentwicklungsprojektes). Demnach m\u00fcssen auch bei den Anforderungen an den Prozess der Softwareentwicklung eine Aufnahme, (Qualit\u00e4ts-)Zielbestimmung, Priorisierung etc. erfolgen. Im Extremfall sind bestimmte (Qualit\u00e4ts-)Anforderungen an den Prozess als Restriktionen aufzufassen. Abbildung 2 stellt die produkt- und prozessbezogene Qualit\u00e4tszielbestimmung im Zusammenspiel dar.<\/p>\n

\"s-qm<\/p>\n

Abb. 2: Produkt- und prozessbezogene Qualit\u00e4tszielbestimmung [Balzert 2008, S. 473]<\/p>\n

Die Qualit\u00e4tsplanung des Prozesses f\u00fcr ein bestimmtes Softwareentwicklungsvorhaben verl\u00e4uft nach dem Verst\u00e4ndnis des prozessorientierten Qualit\u00e4tsmanagements in erster Linie \u00fcber die Auswahl und Anpassung von Standards f\u00fcr den Entwicklungsprozess (und implizit das Entwicklungsprodukt). Prozessstandards definieren Prozesse (bspw. Richtlinien f\u00fcr die Entwicklung oder die Durchf\u00fchrung von Meilensteinen, Verantwortlichkeiten etc.) und beinhalten Beschreibungen von Dokumenten, die im Zuge der Prozesse erstellt werden m\u00fcssen (bspw. Dokumente f\u00fcr \u00c4nderung von Anforderungen, Protokollierung von Testergebnissen etc.). Agile Methoden verfolgen an dieser Stelle jedoch einen weniger formalen Ansatz, der insbesondere bei kleineren Entwicklungsvorhaben zielf\u00fchrend sein kann [Sommerville 2012, S. 710f.]. Das Endergebnis der Qualit\u00e4tsplanung des Prozesses f\u00fcr ein bestimmtes Entwicklungsvorhaben wird in einem Projektauftrag festgehalten.<\/p>\n

Qualit\u00e4tslenkung und Qualit\u00e4tspr\u00fcfung<\/h2>\n

Die Qualit\u00e4tslenkung setzt die Qualit\u00e4tsplanung um. Sie steuert, \u00fcberwacht und korrigiert den Entwicklungsprozess mit dem Ziel, die vorgegebenen Anforderungen an das Produkt und an den Prozess zu erf\u00fcllen. Werden die vorgegebenen Anforderungen nicht erf\u00fcllt, m\u00fcssen korrektive Ma\u00dfnahmen ergriffen werden. Hier sind die Aufgaben der Qualit\u00e4tslenkung eng mit den Aufgaben des Projektmanagements verkn\u00fcpft [Balzert 2008, S. 480]. Bei den korrektiven Ma\u00dfnahmen geht es neben der Anpassung der konstruktiven und analytischen Ma\u00dfnahmen <\/a>auch um die zeitliche Gestaltung und die Intensit\u00e4t der Qualit\u00e4tslenkung und -pr\u00fcfung [Mellis 2004, S. 181ff.].<\/p>\n

Die Qualit\u00e4tspr\u00fcfung f\u00fchrt die im Rahmen der Qualit\u00e4tsplanung festgelegten analytischen Ma\u00dfnahmen hinsichtlich Produkt und Prozess durch. Die Ist-Werte werden erfasst und es wird \u00fcberwacht, ob die konstruktiven Ma\u00dfnahmen durchgef\u00fchrt worden sind [Balzert 2008, S. 480]. Hierdurch soll auch gew\u00e4hrleistet werden, dass die festgelegten Verfahren und Standards des Qualit\u00e4tsmanagements eingehalten worden sind. In diesem Sinn sind Verfahren und Standards die Basis des Qualit\u00e4tsmanagements. Doch das Bestreben von Qualit\u00e4tsmanagern muss es auch sein, eine Qualit\u00e4tskultur zu entwickeln, bei der sich jeder Beteiligte am Entwicklungsprozess dem Erreichen einer hohen Qualit\u00e4t verpflichtet f\u00fchlt [Sommerville 2012, S. 710f.].<\/p>\n

Eine verz\u00f6gerte Fehlerentdeckung f\u00fchrt zu einem exponentiellen Kostenanstieg. Denn mit zunehmender Verweilzeit eines Fehlers im Produkt steigen seine Behebungskosten aufgrund der Fehlerfortpflanzung exponentiell an. Um das Prinzip der fr\u00fchzeitigen Fehlerentdeckung und -behebung realisieren zu k\u00f6nnen und jederzeit Sichtbarkeit \u00fcber das Qualit\u00e4tsniveau des Produktes und Prozesses zu haben, ist eine durchg\u00e4ngig entwicklungsbegleitende und in den Softwareentwicklungsprozess sowie das Projekt- und Risikomanagement integrierte Qualit\u00e4tslenkung notwendig [Balzert 2008, S. 488]. Nach diesem Verst\u00e4ndnis sind die traditionell getrennt behandelten Aktivit\u00e4ten der Qualit\u00e4tslenkung und -pr\u00fcfung auch nicht mehr sinnvoll trennbar. Abbildung 3 stellt das Prinzip der entwicklungsbegleitenden und integrierten Qualit\u00e4tslenkung dar.<\/p>\n

\"abb3\"<\/p>\n

Abb. 3: Prinzip der entwicklungsbegleitenden\u00a0Qualit\u00e4tslenkung [Balzert 2008, S. 488]<\/p>\n

\n

Literatur<\/h3>\n

Balzert, Helmut: Lehrbuch der Softwaretechnik: Basiskonzepte und Requirements Engineering, 3. Auflage. Heidelberg : Spektrum Akad. Verl., 2009.<\/p>\n

Balzert, Helmut: Lehrbuch der Softwaretechnik, Bd. 2, Softwaremanagement. 2. Auflage. Heidelberg : Spektrum Akad. Verl., 2008.<\/p>\n

Fr\u00fchauf, Karol ; Ludewig, Jochen ; Sandmayr, Helmut: Software-Projektmanagement und \u2013Qualit\u00e4tssicherung. 4. Auflage. Z\u00fcrich : vdf, 2002.<\/p>\n

Kneuper, Ralf: CMMI – Verbesserung von Softwareprozessen mit Capability Maturity Model Integration. 3. Auflage. Heidelberg : dpunkt, 2007.<\/p>\n

Liggesmeyer, Peter: Software-Qualit\u00e4t. 2. Auflage. Heidelberg : Spektrum Akad. Verl., 2009.<\/p>\n

Ludewig, Jochen ; Lichter, Horst: Software-Engineering. 3. Auflage. Heidelberg : dpunkt, 2013.<\/p>\n

Mellis, Werner: Projektmanagement der SW-Entwicklung. Wiesbaden : Vieweg, 2004.<\/p>\n

Pohl, Klaus: Requirements-Engineering. 2. Auflage. Heidelberg : dpunkt, 2008.<\/p>\n

Rombach, Dieter: Software-Qualit\u00e4t und -Qualit\u00e4tssicherung. In: Informatik-Spektrum, 1993, Band 16, Heft 5, S. 267-272.<\/p>\n

Sommerville, Ian: Software Engineering. 9. Auflage. M\u00fcnchen : Pearson, 2012.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Georg Herzwurm,\u00a0Martin Mikusz Das Software-Qualit\u00e4tsmanagement befasst sich mit der Planung, Lenkung und Pr\u00fcfung der Qualit\u00e4t von Softwareprodukten und -entwicklungsprozessen. Es beinhaltet sowohl F\u00fchrungsaufgaben zur Festlegung der Qualit\u00e4tspolitik, der Qualit\u00e4tsziele und der Verantwortung f\u00fcr Qualit\u00e4t, wie auch Ma\u00dfnahmen zur Erf\u00fcllung vorgegebener Read More …<\/a><\/p>\n","protected":false},"author":568,"featured_media":0,"parent":5004,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","meta":{"footnotes":""},"class_list":["post-4566","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/pages\/4566","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/users\/568"}],"replies":[{"embeddable":true,"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/comments?post=4566"}],"version-history":[{"count":12,"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/pages\/4566\/revisions"}],"predecessor-version":[{"id":15924,"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/pages\/4566\/revisions\/15924"}],"up":[{"embeddable":true,"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/pages\/5004"}],"wp:attachment":[{"href":"https:\/\/wi-lex.de\/wp-json\/wp\/v2\/media?parent=4566"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}