Softwarequalität Grundlagen PDF

Softwarequalität ······························································································ 1 Grundlagen Lernziele des Kapitels: Das erste Kapitel dient als Einleitung und soll die Leserinnen an das Thema Soft-...

Softwarequalität ······························································································ 1 Grundlagen Lernziele des Kapitels: Das erste Kapitel dient als Einleitung und soll die Leserinnen an das Thema Soft- Lernziele warequalität heranführen. Wir beginnen mit der Erörterung der Bedeutung von Softwarequalität und warum es sich auszahlt, in diese zu investieren. Daraufhin erkunden wir verschiedene Ansätze zur Definition von Qualität und was diese im Kontext der Softwareentwicklung konkret bedeutet. Zum Abschluss des Kapitels werden mögliche Strategien zur Steigerung der Softwarequalität vorgestellt, wel- che zugleich einen Vorgeschmack auf die vertiefenden Inhalte der nachfolgen- den Kapitel geben. Nach dem Studium der Einleitung entwickeln die Leserinnen also ein erstes Ver- ständnis für:  Mögliche Folgen schlechter Software  Gründe für schlechte Software und schlechte Projekte  Definitionsvorschläge für Qualität und Softwarequalität  Normen und Standards im Kontext von Softwarequalität  Maßnahmen zur Steigerung der Softwarequalität 1.1 Schlechte Software und ihre Folgen Wir alle kennen die größeren und kleineren Ärgernisse im alltäglichen Umgang mit Computertechnik und deren Software. Denn trotz der kritischen Rolle, die Software in unserer modernen Welt spielt – vom Finanz- bis hin zu Ampelsystemen – ist sie oft fehlerhaft, ineffizient und schlecht gestaltet (Mann, 2002). Der Cartoon in Ab- bildung 1 nimmt eine solche ärgerliche Situation humoristisch auf die Schippe. Wer kennt das Gefühl nicht, gerade in den wichtigsten Momenten regelmäßig von der Technik im Stich gelassen zu werden? Pünktlich wenn der Ausdruck besonders wichtig ist, streikt der Drucker. Und es entstehen immer mehr Gelegenheiten für die Begegnung mit fehlerhafter Software. Unsere Umwelt wird zunehmend von Computer-Technologie durchdrungen. Ein modernes Auto beherbergt heute allein ························································································································ 7 Softwarequalität ······························································································ ungefähr 100 Mikrokontroller Systeme 1, um verschiedenste Funktionen zu steuern vom Anti-Blockier- bis hin zum Entertainmentsystem. Abbildung 1: Unser Alltag wird nicht selten von der Auseinandersetzung mit mangelhafter Software geprägt 2. Mit der Verbreitung von Computern steigt auch deren Komplexität. Das lässt sich schön am Linux Betriebssystem beziffern. Allein der Kern – also Schlüsselkompo- nenten wie Prozess- und Speicherverwaltung oder Hardware-Unterstützung – um- fasst in der aktuellen Version rund 40 Millionen Zeilen Programmcode (Wikipedia Beitragende, 2024a). Daher sorgen heute regelmäßige Abstürze des Heimcompu- ters für wenig Verwunderung. Der berüchtigte blaue Bildschirm von Microsoft Windows Rechnern hat als sogenannter „Blue Screen of Death (BSOD)“ zweifelhaf- ten Ruhm und ‚Meme-Status‘ erlangt, denn mit dieser Anzeige signalisiert das 1 https://electronicsera.in/automotive-mcu-empowering-the-entire-operating-life-of-a- car/ 2 Comic von system32comics (https://www.instagram.com/system32comics/?hl=de). Diese Arbeit darf geteilt werden unter Nennung der Autorenschaft ························································································································ 8 Softwarequalität ······························································································ Betriebssystem, dass es zum (nicht seltenen) Totalabsturz gekommen ist. Dieser zeigt verschiedene technische Informationen an, die auf das Problem hinweisen sollen, das den Absturz verursacht hat (u. a. Fehlercode, Fehlerursache, Speicherin- halt zum Zeitpunkt des Absturzes). Da nicht nur Heimcomputer, sondern auch viele Anzeigen im öffentlichen Raum mit Windows betrieben werden, finden sich im In- ternet viele skurrile bis lustige Fotos 3, welche ‚eingefrorene‘ öffentliche Infrastruk- tur zeigen (siehe beispielsweise Abbildung 2). Abbildung 2: Statt des Fahrplans zeigt dieses öffentliche Informations-Display in der U-Bahn nur den berüchtigten „Blue Screen of Death” (eine fatale Fehlermeldung von Windows Betriebssystemen) 4. Dass schlechte Software nicht nur zu Frustration, sondern auch zu weitreichenden Folgen führen kann, ist heute eine Binsenweisheit. Im Laufe der Zeit haben sich viele prominente Vorfälle ereignet, die auf fehlerhafte Programmierung bezie- hungsweise Software zurückzuführen sind. Werfen wir einen Blick auf einige der ‚Klassiker‘: 3 Zum Beispiel wurden an dieser Stelle von einer englischen Zeitung solche Aufnahmen ge- sammelt: https://www.telegraph.co.uk/technology/microsoft/windows/11929017/11- times-the-Windows-blue-screen-of-death-struck-in-public.html 4 Autor: Richard Eriksson / Flickr.com https://creativecommons.org/licenses/by/2.0/ ························································································································ 9 Softwarequalität ······························································································ Der Fehlstart von Ariane 5, Flug 501 (siehe Abbildung 3): Ein Softwarefehler führte zum Scheitern eines europäischen Satellitenstarts, was nicht nur den Verlust der Satelliten selbst bedeutete, sondern auch erhebliche finanzielle Ein- bußen und Rückschläge für die beteiligten Raumfahrtprogramme zur Folge hatte. Solche Fehler können aus inkorrekten Berechnungen, Fehlern in der Steuerungssoftware oder Inkompatibilitäten in der Software verschiedener Systemkomponenten resultieren. Tatsächlich wurde die Software, die den Kursfehler verursachte, direkt und ohne jegliche Systemprüfungen von der vor- herigen Ariane 4-Rakete übernommen. Dies geschah, obwohl die Software nicht für die modifizierte Flugroute der Ariane 5 ausgelegt war (Mann, 2002). Die Verzögerung der Flughafeneröffnung in Denver in den 1990er Jahren: Die Eröffnung des Denver International Airport wurde um rund ein Jahr verzögert, hauptsächlich aufgrund von Problemen mit dem automatisierten Gepäckbeför- derungssystem, das neben Fehlern in der Organisation auch durch Software- fehler stark beeinträchtigt wurde. Diese Verzögerung führte zu erheblichen Kostenüberschreitungen und illustriert, wie stark kritische Infrastrukturpro- jekte durch Softwareabhängigkeiten verwundbar sind (Mann, 2002). Abbildung 3: Explosion der Ariane 5 (Flug 501). Der Moment des Versagens (rechtes Bild) am 4. Juni 1996, verursacht durch einen Softwarefehler. Glücklicherweise war der Flug unbemannt, doch ent- standen Kosten von ca. 290 Millionen Euro 5. Der Ausfall von Rettungsdienstsystemen in London: Softwaredefekte führten 1992 zum Ausfall der Rettungsdienstsysteme in London, was zu Verzögerungen 5 Dieses Bild wird zu Bildungszwecken unter der Fair-Use-Doktrin verwendet, um ein spezi- fisches historisches Ereignis zu illustrieren. Quelle: Wikipedia / https://www- users.cse.umn.edu/~arnold/disasters/ariane.html ······················································································································ 10 Softwarequalität ······························································································ bei der Notfallversorgung und möglicherweise bis zu 45 Todesfällen führte (Mann, 2002). Die Oxford Health Plans (US-amerikanischer Gesundheitsdienstleister) erleb- ten im Jahr 1997 gravierende Probleme mit ihrer neuen Abrechnungssoftware, die nicht mit dem expandierenden Geschäftsbetrieb Schritt halten konnte. Dies führte zu einer enormen Menge an ausstehenden Zahlungen, die nicht einge- zogen werden konnten. Es wurde berichtet, dass ungefähr 400 Millionen US- Dollar an Patientenzahlungen und 650 Millionen US-Dollar, die an Gesundheits- dienstleister gezahlt werden sollten, betroffen waren. Diese Softwarefehler hatten gravierende finanzielle Auswirkungen für das Unternehmen und verur- sachten erhebliche Störungen sowohl für die Patienten als auch für die Anbie- ter von Gesundheitsdienstleistungen (Charette, 2005). Die UK Inland Revenue (Steuerbehörde im Vereinigten Königreich; heute Teil von HM Revenue & Customs) hatte mit einer Reihe von Problemen im Zusam- menhang mit Softwarefehlern zu kämpfen, insbesondere im Jahr 2003, als das Einführen eines neuen IT-Systems zu massiven Problemen bei der Bearbeitung von Steuererklärungen führte. Das System, das von der Beratungsfirma EDS entwickelt wurde, sollte die Verarbeitung von Steuerrückerstattungen und - zahlungen automatisieren und verbessern. Allerdings führten Fehler im System zu erheblichen Verzögerungen bei der Auszahlung von Steuerrückerstattungen und zu falschen Steuercodes für Millionen von Steuerzahlern. Einige der spezi- fischen Probleme umfassten die Auszahlung inkorrekter Beträge, falsche Be- rechnungen und Schwierigkeiten beim Zugriff auf detaillierte Kontoinformatio- nen. Berichten zufolge wurden bis zu 3,45 Milliarden US-Dollar zu viel an Steu- ergutschriften ausgezahlt (Charette, 2005). Im Vergleich zu anderen Ingenieursdisziplinen, wo kontinuierliche Verbesserungen üblich sind, scheint die Softwareentwicklung nicht mit der steigenden Komplexität der Aufgaben Schritt zu halten. Die Probleme reichen von schlechtem Design über unzureichende Planung bis hin zu einem Mangel an ordnungsgemäßer Fehlerbe- handlung (Mann, 2002). ······················································································································ 11 Softwarequalität ······························································································ 1.1.1 Gründe für schlechte Software Die Herausforderungen und Probleme, die bei der Entwicklung und Implementie- rung von Software auftreten, lassen sich nicht immer unmittelbar auf Fehler in der Programmierung beziehungsweise fehlerhaften Code zurückführen. Vielmehr sind sie oft das Ergebnis eines komplexen Geflechts von Ursachen, die bereits in den frühen Phasen der Projektdurchführung wurzeln. Der Prozess der Softwareentwick- lung ist ein multidimensionales Unterfangen, das weit über die reine Codierung hin- ausgeht und eine sorgfältige Planung, Koordination und Kommunikation erfordert. Aus diesem Grund gibt es unterschiedliche Stellschrauben mit welchen die Soft- warequalität gesichert oder gesteigert werden kann. Derlei schauen wir uns in die- sem Skriptum vor allem drei an: organisatorische, analytische und konstruktive Maßnahmen (siehe Abschnitt 1.5). Bereits bei der Konzeption eines Softwareprojekts können entscheidende Weichen gestellt werden, die den späteren Erfolg maßgeblich beeinflussen. Unrealistische Zeitpläne, unklare oder sich ständig ändernde Anforderungen und eine mangel- hafte Definition der Projektziele sind nur einige der Faktoren, die zu Schwierigkei- ten führen können, wie wir schon in der ersten Einheit dieser Lehrveranstaltung gesehen haben. Zusätzlich zur Projektplanung spielt die Kommunikation eine zent- rale Rolle. Eine lückenhafte oder ineffektive Kommunikation zwischen den Stake- holdern, darunter Entwicklerinnen, Kundinnen und Endnutzerinnen, kann zu Miss- verständnissen und Fehlinterpretationen führen, die sich negativ auf die Software auswirken. Dies betrifft sowohl die Auslegung der Anforderungen als auch die Er- wartungen an das Endergebnis (vgl. Skriptum zu Requirements Engineering). Charette (2005, S.45, Übersetzung des Autors) führt in seinem viel beachteten Ar- tikel über Softwareversagen folgende Hauptursachen für das Scheitern von Soft- wareprojekten auf: unrealistische oder unausgesprochene Projektziele unzutreffende Schätzungen der benötigten Ressourcen schlecht definierte Systemanforderungen mangelhafte Berichterstattung über den Projektstatus unkontrollierte Risiken schlechte Kommunikation zwischen Kunden, Entwicklern und Nutzern ······················································································································ 12 Softwarequalität ······························································································ Einsatz unreifer Technologie nachlässige Entwicklungspraktiken schlechtes Projektmanagement Taktieren der Stakeholder geschäftlicher Druck Unfähigkeit, die Komplexität des Projekts zu bewältigen 1.1.1.1 Zur Komplexität von Software Die zunehmende Komplexität von Computerprogrammen hat mit der Zeit zu einem Wandel in der Herangehensweise von Programmierern geführt (siehe auch Kapitel 4 zum Messen von Softwareeigenschaften). Während der Code in den Anfangsta- gen der Computer sorgfältig geplant wurde, haben sich die Entwicklerinnen später zunehmend auf ihre Compiler verlassen, um den Code im Nachhinein zu überprüfen („Code and Fix“). Laut empirischer Untersuchungen sei die Haltung weit verbreitet, schnellen Code zu produzieren und dann zu testen, ob Fehlermeldungen angezeigt werden oder ob das Kompilieren erfolgreich abläuft. Viele nehmen an, dass der Code korrekt sein muss, wenn keine Fehlermeldung erscheint (Mann, 2002). Allerdings zeigte sich dann mit wachsender Größe und Komplexität der Programme die Grenze dieses „Code-and-Fix“-Ansatzes. Professionelle Programmierer machen laut einer Erhebung durchschnittlich 100 bis 150 Fehler pro tausend Zeilen Code. Demnach enthält ein Betriebssystem wie Windows mit seinen 16 Millionen Zeilen Code 6 etwa zwei Millionen Fehler. Die meisten dieser Fehler sind unscheinbar und unauffällig, aber dennoch verbleiben tausende theoretisch ernsthafte Probleme, denen man auch mit ausgiebigen Testen nicht unbedingt auf die Spur kommen muss. Pro Testphase werden üblicherweise weniger als die Hälfte der Fehler ent- deckt. Selbst nach vier Testrunden - ein teures und zeitaufwändiges Verfahren – werden theoretisch maximal 15 von 16 Fehlern gefunden, was zu etwa fünf Fehlern pro tausend Zeilen Code führt. Nach dieser Rechnung enthält ein Betriebssystem wie Windows noch immer etwa 80.000 Fehler (Mann, 2002). 6 Die Rechnung in dem Artikel von Mann (2002) bezieht sich auf Windows NT. Neuere Be- triebssysteme sind folglich noch komplexer (vgl. obige Anmerkungen zum Linux Kernel). ······················································································································ 13 Softwarequalität ······························································································ Software-Ingenieure sind sich bewusst, dass ihr Code oft mit Lücken behaftet ist und suchen seit Langem nach neuen Technologien, um diese zu vermeiden. Umzu- nehmend umfangreiche Projekte zu bewältigen, haben sie eine Vielzahl von Tech- niken entwickelt, wie etwa das komponentenbasierte Design (mehr dazu und zu weiteren konstruktiven Qualitätsmaßnahmen in Kapitel 3 sowie im Exkurs in Ab- schnitt 4.3). Ähnlich wie Häuser mit standardisierten Bauelementen und elektri- schen Anschlüssen hochgezogen werden, bestehen komponentenbasierte Pro- gramme aus modularen, austauschbaren Elementen. Nur mit Hilfe derartiger Tech- niken lässt sich die Qualität von moderner Software gewährleisten (Mann, 2002). Doch was genau verstehen wir eigentlich unter einen guten Softwarequalität? 1.2 Was ist Qualität? Qualität ist ein vielschichtiges und komplexes Konzept. Bei dem Versuch diese zu definieren, merkt man schnell, dass dies gar nicht so leicht ist. An dieser Aufgabe haben sich schon etliche führende Experten abgearbeitet. Diese legten dabei die Grundlagen für spätere Normen, Standards und Modelle. Wallmüller (2011, S. 6) liefert in seinem umfassenden Lehrbuch zu Quality Engineering eine Aufzählung: P.B. Crosby sieht Qualität als die genaue Erfüllung festgelegter Anforderungen beziehungsweise Spezifikationen. Er betont, dass die Verhinderung von Fehlern und das Ziel „Null Fehler“ als Leistungsstandards dienen sollten. A.V. Feigenbaum definiert Qualität durch die Zufriedenstellung der Kunden- wünsche. Er vertritt die Ansicht, dass Qualität eine unternehmensweite Verant- wortung ist und durch das Prinzip der „Total Quality Control“ gewährleistet wird, wobei das Engagement eines jedem im Unternehmen eine Rolle spielt (von der Konzeption des Produktes bis zum Kundendienst). W.A. Shewhart stellt die Kundenzufriedenheit in den Mittelpunkt seiner Quali- tätsdefinition, die er durch messbare Kriterien festlegt, die wiederum die Ent- wicklungssteuerung von Produkten und Dienstleistungen lenken. E.W. Deming, ein Schüler Shewharts, misst statistischen Methoden zur Mes- sung und Analyse von Abweichungen große Bedeutung bei, um Prozessverbes- serungen zu erreichen. Sein Ansatz unterstreicht auch die Rolle der Unterneh- menskultur im kontinuierlichen Streben nach Qualität. J.M. Juran definiert Qualität als die Eignung eines Produkts für den Gebrauch durch den Kunden („Funktionstüchtigkeit“). Für ihn ist jeder ein Kunde, der das ······················································································································ 14 Softwarequalität ······························································································ Produkt nutzt. Qualität entsteht in seinen Augen durch kontinuierliche Verbes- serungsprogramme und die Ausrichtung an den Bedürfnissen der Konsumen- ten. K. Ishikawa vermittelt ein japanisches Verständnis von Qualität, das auf folgen- den Prinzipien beruht: Qualität steht an erster Stelle und wird durch die Unter- nehmensleitung priorisiert, die Anforderungen des Verbrauchers sind maßgeb- lich für die Qualitätsdefinition, und die Einbeziehung aller Unternehmensberei- che und Hierarchieebenen ist für kontinuierliche Verbesserungen notwendig. Zudem schafft ein soziales System für die Mitarbeiter eine Basis für Sinnerfül- lung, Vertrauen und Wohlbefinden. Die DIN ISO 7 8402 normierte die Grundlagen der Qualitätssicherung und des Qualitätsmanagements und definierte: „Qualität ist die Gesamtheit von Merk- malen einer Einheit bezüglich ihrer Eignung, festgelegte und vorausgesetzte Er- fordernisse zu erfüllen“. Die Nachfolgenorm der ISO 8402 – die EN ISO 8 9000:2005 – definiert Qualität als den „Grad, in dem ein Satz inhärenter Merkmale Anforderungen erfüllt“. Einige der genannten Kriterien von Qualität erinnern an die erste Einheit dieses Mo- duls zu Requirements Engineering, welche an vielen Stellen die Wichtigkeit einer systematischen Anforderungsanalyse betonte. Es erscheint auch nicht verwunder- lich, dass einige Expertinnen Qualität durch die Erfüllung der Bedürfnisse zu defi- nieren versuchen. Intuitiv wird man die Qualität eines Produktes als gut beurteilen, welches die Erwartungen daran befriedigt. 7 DIN ISO bezieht sich auf Normen, die von der Internationalen Organisation für Normung (ISO) entwickelt wurden und vom Deutschen Institut für Normung (DIN) für die Anwendung in Deutschland übernommen wurden. Die ISO ist eine unabhängige, internationale Organi- sation, die weltweit anerkannte Standards entwickelt, um die Qualität, Sicherheit und Effi- zienz von Produkten, Dienstleistungen und Systemen zu gewährleisten: https://www.iso.org/ DIN ist das deutsche nationale Normungsorgan und Mitglied der ISO: https://www.din.de/ 8 Die Bezeichnung "EN ISO" bezieht sich auf eine Norm, die sowohl auf europäischer (EN für Europäische Norm) als auch auf internationaler Ebene (ISO für International Organization for Standardization) anerkannt ist. Wenn eine ISO-Norm von den Mitgliedsstaaten des Eu- ropäischen Komitees für Normung (CEN) als europäische Norm (EN) übernommen wird, er- hält sie die Bezeichnung "EN ISO": https://www.cencenelec.eu/ ······················································································································ 15 Softwarequalität ······························································································ Wallmüller (2011, S.8-9) und Westfall (2016, Kapitel 1) führen einen weiteren dif- ferenzierten Ansatz von D.A. Garvin aus, welcher mehrere Facetten von Qualität einzufangen versucht. Garvin zieht die über Dekaden gesammelte Erkenntnis der Qualitätsforschung zusammen und unterscheidet schließlich zwischen fünf ver- schiedenen Sichten auf Qualität beziehungsweise zwischen fünf Ansätzen, um Qua- lität näher zu bestimmen. Der transzendentale Ansatz: Qualität wird als etwas angesehen, das erkenn- bar, aber nicht definierbar ist, ähnlich dem Konzept der „Schönheit“. Wir wis- sen, wenn wir etwas als schön empfinden, können aber nicht an genauen Kri- terien festmachen, warum wir so tun. Das Erlebnis Qualität „übersteigt“ (wenn wir uns an der direkten Wortbedeutung orientieren) also einzelne Aspekte, die als Definitionskriterien vorgeschlagen werden. Das Ganze ist mehr als seine Teile. Somit ist der transzendentale Ansatz aufgrund seines Idealismus für An- wendung in der Praxis allerdings nur bedingt tauglich, denn er gibt wenig direkt Greifbares her, mit dem man arbeiten kann. Der prozessbezogene bzw. herstellerbezogener Ansatz: Diese Sichtweise be- trachtet Qualität als Übereinstimmung mit vorgegebenen Spezifikationen, ähn- lich der Definition von Crosby. Qualität wird durch das korrekte Ausführen der Instruktionen und Tätigkeiten sichergestellt. Entwicklungs- und Produktions- prozesse stehen also im Zentrum. Diese Prozesse werden streng kontrolliert, auditiert und inspiziert. Den Mitarbeitern wird nicht eingeräumt eigenmächtig zu entscheiden, was zum Beispiel für die Stakeholder ihrer Meinung nach am besten zu sein scheint. Eine präzise Spezifikation ist essenziell für die Qualitäts- erzeugung. Auch der Grad der Automatisierung ist entscheidend für die Effizi- enz der Produktionsabläufe. Bei der maschinellen Fertigung ist vor allem der Einsatz von Robotik und maschinellen Systemen zentral, um die Abläufe in der Herstellung möglichst ohne Fehler und Störungen zu gestalten. Im Bereich der Softwareentwicklung heißt das, dass eine sorgfältige Auswahl und spezifische Anpassung der Entwicklungsmethoden sowie die Verwendung von genügend analytischen Qualitätssicherungsverfahren, wie beispielsweise Überprüfungen und Kontrollen, erforderlich sind, um die Einhaltung von Prozess- und Produkt- anforderungen zu gewährleisten. Darüber hinaus ermöglicht der Einsatz von modellbasierten Entwicklungsmethoden und ein hoher Grad an automatisier- ten Tests, wie Modul- oder Regressionstests, eine effektive Durchführung der Prozesse. Selbst in der agilen Entwicklung, wo Anforderungen nicht formell ······················································································································ 16 Softwarequalität ······························································································ festgehalten werden, sind gute User Stories und der Dialog mit den Stakehol- dern unerlässlich, um qualitativ hochwertige Software zu entwickeln. Fehler in der Anforderungsphase führen laut dieser Sicht oft zu einem Großteil der spä- teren Softwarefehler. Der anwenderbezogene Ansatz: Aus dieser Perspektive wird Qualität als etwas gesehen, das von den Endnutzerinnen des Produkts bestimmt wird, basierend auf individuellen Präferenzen und Anforderungen. „Gebrauchstauglichkeit“ ist hier also das passende Kriterium für Qualität. Es gibt Fälle, in denen Software zwar den Spezifikationen entspricht, aber in der praktischen Anwendung Män- gel aufweist. Die Produkte, die die Erwartungen und Bedürfnisse der Benutzer hingegen am effektivsten erfüllen, gelten als die qualitativ besten. Um dies zu gewährleisten könnten beispielsweise bei der Entwicklung eines Finanzportals für ein Unternehmen zuerst die verschiedenen Nutzerrollen (z. B. Senior Ma- nagement, Verantwortlichen für die Kostenstellen, Controller) definiert wer- den. Eine maßgeschneiderte Web-Schnittstelle erlaubt es dann diesen unter- schiedlichen Benutzergruppen, auf spezifische Funktionen zuzugreifen. Das De- sign und die Benutzerfreundlichkeit der Website so können speziell auf die Be- dürfnisse der Nutzer abgestimmt werden, um ihre Arbeitserfahrung zu optimie- ren. Allerdings haben Anwender oft nur eine ungefähre Vorstellung von Quali- tät, was es für Softwareentwickler herausfordernd macht, die genauen Bedürf- nisse im Vorfeld zu identifizieren und zu erfüllen (vgl. Teil 1 dieser Lehrveran- staltung). Das Produkt, das sich am besten verkauft, ist nicht notwendigerweise dasjenige, das die Bedürfnisse der Kunden optimal befriedigt. Bei dieser Be- trachtungsweise wird die eigentliche technische Qualität des Produkts manch- mal vernachlässigt. Der produktbezogene Ansatz: Hier wird Qualität mit den inhärenten Eigen- schaften eines Produkts verbunden. Die dazugehörigen Produktattribute bezie- hungsweise Kriterien enden im Englischen oft auf „-ilities“ und umfassen Merk- male wie Zuverlässigkeit, Benutzbarkeit und Anpassungsfähigkeit (Reliability, Usability, Accessibility, Availability, Flexibility, Maintainability, Portability, In- stallability, Adaptability, usw.). Die ISO/IEC 9 25000 Serie (Vorgängernorm: DIN 9 ISO/IEC steht für die International Organization for Standardization / International Elec- trotechnical Commission. Diese beiden Organisationen arbeiten zusammen, um internatio- nale Standards zu entwickeln, die sich auf die Felder der Elektrotechnik und Informations- technologie konzentrieren. ······················································································································ 17 Softwarequalität ······························································································ ISO 9126; Details in Abschnitt 1.4.2) stellt einen Referenzrahmen für diese Qua- litätsattribute zur Verfügung und unterstützt bei der Spezifizierung und Bewer- tung von Softwarequalität. Die Anhängerinnen dieses Qualitätsansatzes sind der Meinung, dass sich Qualität objektiv bestimmen lässt. Ihrer Auffassung nach lassen sich Qualitätsebenen durch messbare Eigenschaften eines Produkts ausdrücken, die objektiv erfasst und verglichen werden können. Dies ermög- licht es, Produkte innerhalb derselben Kategorie nach Qualität zu ordnen. Die- ses Konzept konzentriert sich ausschließlich auf das fertige Produkt und lässt subjektive Kundenempfindungen außer Acht. Folglich ist ein Kritikpunkt an die- ser Sichtweise, dass sie die Bedürfnisse und die Perspektive der Kundinnen ver- nachlässigt. Oft wurde diese Qualitätsphilosophie von zentralen Einkaufs- und Testabteilungen bevorzugt. In den 1970er Jahren begann die Entwicklung von Bewertungsmethoden für Software, um Angebote und Produkte verschiedener Softwareanbieter besser vergleichen zu können. Der wertbasierte Ansatz: Diese Perspektive sieht Qualität in Relation zu dem Preis, den Kunden bereit sind zu zahlen. Es geht beispielsweise um die Abwä- gung, ob die doppelte Zuverlässigkeit eines Produkts den doppelten Preis recht- fertigt oder ob Kunden mehr für zusätzliche Sicherheitsmerkmale bezahlen würden. Diese Sichtweise kann auf alle Stakeholder ausgedehnt werden. Qua- litative hochwertige Software bietet für diese also ein positives Verhältnis von Nutzen und Kosten. Nun stellt sich die Frage, wie wir mit den verschiedenen Definitionsversuchen und Perspektiven auf das Konzept Qualität umgehen wollen, um damit im Speziellen die „Softwarequalität“ zu unterstützen. Es lassen sich bereits spannende Herausforde- rungen erahnen. Einige Definitionen bauen auf die Erfüllung von Anforderungen. Wenn wir uns jedoch an Teil 1 der Lehrveranstaltung erinnern, dann stellt uns das vor das Problem, dass hunderte bis tausende von Requirements Beachtung finden müssen. Eine weitere Herausforderung könnte darin bestehen, dass Software oft- mals viele unterschiedliche Verwendungszwecke hat. Folglich geht es oftmals nicht um die eine Eignung, sondern wie gut die Software für verschiedene Aufgaben funk- tioniert. ······················································································································ 18 Softwarequalität ······························································································ 1.3 Was ist Softwarequalität? Wie wir gesehen haben, entpuppt sich der Qualitätsbegriff als vielschichtig und nur schwer fassbar. Von daher besteht die Gefahr, dass unterschiedliche Mitglieder des Entwicklungsteams unter Qualität unterschiedliche Dinge verstehen und Missver- ständnisse entstehen können. Folglich besteht der dringende Bedarf, die Kommu- nikation der Software-Entwicklerinnen mit Blick auf die Softwarequalität auf ein si- cheres Fundament zu stellen. Sonst wäre eine qualitativ hochwertige Entwicklung, Betreibung und Wartung des Produktes mehr oder weniger dem Zufall überlassen. Ein bewährter Ansatz ist die Einführung von Normen und Standards (weitere Details zu diesem Thema in Abschnitt 1.4), welche speziell für das Softwareengineering entwickelt wurden, oft unter Bezug auf die unter Abschnitt 1.2 genannten klassi- schen Qualitätsbegriffe. Richten wir zunächst den Blick auf das Glossar für Soft- wareentwicklung der IEEE 10 (IEEE Std 729-1983). Interessanterweise liegt auch hier ein Fokus auf den Anwenderinnen. Wallmüller (2011, S. 10) fasst die wesentlichen Eckpunkte von Softwarequalität laut des IEEE-Glossars zusammen: (1) Die Gesamtheit der Funktionen und Merkmale eines Software-Produkts, das die Fähigkeit besitzt, 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 Soft- ware seinen unterschiedlichen Erwartungen entspricht; (4) Die zusammengesetzten Merkmale der Software, die bestimmen, bis zu welchem Grad die verwendete Software den Erwartungen der Kunden ge- recht wird. (Wallmüller, 2011) 10 Die IEEE (Institute of Electrical and Electronics Engineers) ist eine internationale Organi- sation, die sich der Förderung von Technologie und technischer Exzellenz in den Bereichen Elektrotechnik, Elektronik, Computerwissenschaften und verwandten Disziplinen widmet. Sie veröffentlicht Fachliteratur, organisiert Konferenzen und bietet Bildungsprogramme an. IEEE setzt Standards in verschiedenen technischen Bereichen und unterstützt die berufliche Entwicklung von Ingenieuren und Forschern weltweit. https://www.ieee.org/ ······················································································································ 19 Softwarequalität ······························································································ Die DIN ISO Norm 9126 definiert den Begriff Software-Qualität wie folgt (wir wer- den auf diese Norm und ihren Nachfolger ISO 25000 in Abschnitt 1.4.2 noch ge- nauer eingehen): „Software-Qualität ist die Gesamtheit der Merkmale und Merkmalswerte eines Software-Produkts, die sich auf dessen Eignung beziehen, festgelegte Erfordernisse zu erfüllen.“ In der Zusammenschau formuliert Wallmüller (2011, S. 10) seine eigene Definition für Softwarequalität, welcher auch wir in diesem Skript folgen wollen. Definition Softwarequalität Merksatz Die Summe aller relevanten Eigenschaften eines Software-Produkts, mit denen seine Kunden zufriedengestellt werden, und die Summe der dazu notwendigen Ei- genschaften von Software-Prozessen wie z. B. erreichte Reifegrade, die zur Erstel- lung, zum Betrieb und zur Pflege gefordert werden. (Wallmüller, 2011, S.10) Der Vorteil dieser Definition liegt darin, dass sie einerseits die Wichtigkeit der Pro- duktqualität für die Kunden widerspiegelt und zum anderen die Prozessqualität hervorhebt, über welche eine Firma oder ein Team verfügen muss, um erfolgreich arbeiten und wirtschaften zu können. Somit enthält der Definitionsvorschlag von Wallmüller (2011) sowohl eine äußere Sicht auf das Produkt beziehungsweise auf dessen Qualität – die Perspektive der Anwenderinnen – als auch Referenzen auf innere Vorgänge, die während der Entwicklung gewährleistet werden sollten und die von außen nicht einsehbar sind. Diesen Unterscheidungen zwischen externen und internen Sichtweisen werden wir im Laufe des Skriptums weitere Male begeg- nen, zum Beispiel bereits im nächsten Abschnitt. Zudem baut die Definition von Wallmüller (2011) auf dem Vorhandensein relevanter Eigenschaften auf. Wir haben in diesem Kapitel bereits von mehreren Qualitätstheorien gelesen, für welche be- stimmte Eigenschaften von elementarer Bedeutung sind. Oft werden diese auch als Anforderungen oder Qualitätsaspekte beziehungsweise als Qualitätsmerkmale be- zeichnet. ······················································································································ 20 Softwarequalität ······························································································ 1.3.1 Qualitätsmerkmale Hoffmann (2013) arbeitete an der Übertragbarkeit des Begriffs der Softwarequali- tät in die Praxis. In seinen Überlegungen betont der Autor die Vielschichtigkeit der Softwarequalität und hebt hervor, dass sie von vielen verschiedenen Faktoren be- einflusst wird. Dabei lässt sich die Qualität einer vorliegenden Software nicht an- hand eines einzigen, vor allem nicht eines quantitativen, Maßstabs messen. Statt- dessen umfasst der Begriff eine Vielzahl von komplexen und vielschichtigen Krite- rien oder Qualitätsmerkmalen, die teilweise sogar in Konflikt miteinander stehen können. Abbildung 4 zeigt die verschiedenen Bausteine, die laut dem Autor zusammenwir- ken müssen, um eine gute Qualität zu gewährleisten. Je nach Einsatzbereich und spezifischen Anforderungen kann die Wichtigkeit dieser verschiedenen Kriterien beziehungsweise Qualitätsaspekte stark variieren. Dabei ist es wichtig zu verste- hen, dass die Reihenfolge, in der diese Kriterien aufgeführt werden, nicht deren Wichtigkeit widerspiegelt (Hoffmann, 2013). Abbildung 4: Verschiedene für die Praxis relevante Bausteine beziehungsweise Kriterien von Soft- warequalität, i. A. a. Hoffmann (2013, S. 7) Die Kriterien auf der linken Seite sind nach außen hin sichtbar und stellen zusam- men die Qualitätssicht der Anwenderinnen dar. Die Kriterien in der rechten Spalte sind in der Regel nur für den Hersteller einsehbar. Sie bleiben im Inneren der Pro- duktion verborgen und sind wichtig für einen langfristigen Erfolg des Produktes. Anstelle von Kriterien können wir auch die Bezeichnungen „Eigenschaften“, „Qua- litätsmerkmale“, „Qualitätsaspekte“, „Qualitätsanforderungen“ oder einfach nur ······················································································································ 21 Softwarequalität ······························································································ „Anforderungen“ verwenden (In Abschnitt 4.1 erklären wir diese Begrifflichkeiten genauer). Im Detail beschreiben die Qualitätsmerkmale folgende Eigenschaften, welche zur Beurteilung von Software herangezogen werden können: Funktionalität (Functionality, Capability): Im Bereich der Softwareentwicklung ist die Funktionalität ein zentrales Qualitätsmerkmal, das misst, inwieweit ein System die ihm zugewiesenen Funktionen tatsächlich realisiert. Funktionale Mängel treten in einer Vielzahl von Formen auf und sind oft auf unzureichende oder missverstandene Anforderungsspezifikationen zurückzuführen. Manch- mal werden auch spezifische Eigenschaften eines Programms ganz ausgelassen, wofür es verschiedene Gründe gibt, wie zum Beispiel technische Probleme oder Zeitmangel kurz vor der geplanten Veröffentlichung. Die meisten funktionalen Defizite sind jedoch auf Fehler während der Implementierung zurückzuführen (Software Bugs), die mit geeigneten Qualitätssicherungsverfahren während der Entwicklungsphase identifiziert und vermieden werden könnten. Es ist eine gängige Praxis geworden, die Software-Qualität lediglich anhand der Funktions- fähigkeit zu messen, was eine unangemessene Vereinfachung ist, wie die aus- führliche Liste der Qualitätskriterien, die im Folgenden erörtert werden, zeigt (Hoffmann, 2013, S. 7). Laufzeit (Performance): Die Performance oder Laufzeit eines Software-Systems ist ebenfalls ein entscheidender Faktor, der oft spezifische Anforderungen hat, die möglicherweise nicht immer klar in der Spezifikation angegeben sind. Wäh- rend für einige Typen von Anwendungen die Einhaltung dieser Anforderungen leicht zu bewältigen ist und sich auf interaktive Benutzerschnittstellen be- schränkt, ist die Situation bei Echtzeitsystemen wesentlich komplexer. Dort müssen alle Prozesse strikte zeitliche Vorgaben erfüllen, die je nach Bedarf im Durchschnitt (bei weicher Echtzeit) oder in jedem einzelnen Fall (bei harter Echtzeit) bindend sind. In solchen Umgebungen sind die Laufzeit und Funktio- nalität eng miteinander verknüpft und von gleich hoher Wichtigkeit (Hoffmann, 2013, S. 7). Zuverlässigkeit (Reliability): Im Kontext der Softwareentwicklung nimmt die Zuverlässigkeit eine Schlüsselrolle ein, vor allem in Anwendungsbereichen, in denen Sicherheitsaspekte eine übergeordnete Bedeutung haben. Beispiele hierfür sind die Elektronik in Fahrzeugen, Steuerungssysteme in der Luftfahrt ······················································································································ 22 Softwarequalität ······························································································ oder auch in der medizinischen Robotik. In diesen Sektoren kann ein Versagen der Systeme direkte Konsequenzen für die physische Sicherheit der Menschen haben. Die Verlässlichkeit eines Systems ist dabei nicht isoliert zu betrachten, sondern ist eng mit mehreren anderen Qualitätsfaktoren wie Funktionalität, Benutzbarkeit, Wartbarkeit, Transparenz und Übertragbarkeit verknüpft (siehe unten). Diese Faktoren sind wechselseitig abhängig, da zum Beispiel eine hohe Funktionalität und Benutzbarkeit wenig Wert haben, wenn das System nicht zuverlässig ist. Ebenso ist eine gute Wartbarkeit erforderlich, um die Zuverläs- sigkeit im Laufe der Zeit aufrechtzuerhalten. Transparenz hilft dabei, die Zuver- lässigkeit zu verstehen und zu verbessern, während Übertragbarkeit sicher- stellt, dass die Zuverlässigkeit über verschiedene Systeme und Kontexte hinweg konsistent bleibt. Eine umfassende Systemzuverlässigkeit erfordert dement- sprechend eine Optimierung mehrerer Qualitätsaspekte (Hoffmann, 2013, S. 8). Benutzbarkeit (Usability): Mit dem Terminus Benutzbarkeit beziehungsweise Usability wird die Schnittstelle zwischen Menschen und Maschine charakteri- siert. Ziel ist es, ein gut nutzbares User Interfaces zu gestalten. Aktuell spricht man auch von einer gelungenen User Experience und weitet den Begriff somit noch aus. Die Interaktion mit dem System soll also nicht nur brauchbar sein, sondern ein positives Erlebnis darstellen. Im Gegensatz zu früheren Generatio- nen von Computersystemen, die eine eher minimalistische Schnittstellenge- staltung aufwiesen, bieten heutige Systeme eine breite Palette an benutzerori- entierten und anwendungsspezifischen Interface-Designs. Die Relevanz opti- mierter Benutzerschnittstellen kann jedoch je nach Industriezweig variieren. Während beispielsweise in der Automobilbranche eine hohe Priorität auf der Benutzerschnittstelle liegt, kann die Bedeutung für eine Spezialsoftware, die nur von einer kleinen Gruppe von Experten verwendet wird, wesentlich gerin- ger sein (Hoffmann, 2013, S. 8). Wartbarkeit (Maintainability): Die Fähigkeit, Software auch nach ihrer Einfüh- rung anzupassen, zu verändern und zu erweitern, ist ein entscheidendes Merk- mal für die Lebensdauer von Softwareprodukten. Häufig wird jedoch die Be- deutung der Codepflege unterschätzt, was in der Praxis zu Problemen führt. Oft endet die Projektplanung mit dem Start des Systems, ohne die spätere Fehler- behebung einzuplanen. Zudem werden manchmal Drittanbieter für die Ent- wicklung von Softwarekomponenten herangezogen, ohne die langfristige ······················································································································ 23 Softwarequalität ······························································································ Wartung zu berücksichtigen. Die Instandhaltungsfähigkeit ist jedoch ein kriti- scher Faktor für die Wettbewerbsfähigkeit und das Überdauern am Markt ge- genüber der Konkurrenz.(Hoffmann, 2013, S. 8). Transparenz (Transparency): Die Transparenz in der Softwareentwicklung be- zieht sich darauf, wie nachvollziehbar und verständlich die Implementierung der Funktionen hinter den Kulissen ist, die Nutzer von außen wahrnehmen kön- nen. Es geht darum zu ergründen, ob die Funktionalitäten auf einer klar struk- turierten und logisch aufgebauten Programmierung basieren oder ob dahinter ein kompliziertes Geflecht verborgen liegt, das zwar operativ funktioniert, je- doch bei genauerer Inspektion für Verwirrung sorgen könnte. Mit der Weiter- entwicklung von Software tendiert die Transparenz dazu, abzunehmen, was zu einer zunehmenden Komplexität führt, vergleichbar mit den Prinzipien der zu- nehmenden Entropie in der Thermodynamik. Die daraus resultierende Unord- nung in einem Software-System wird oft als Software-Entropie bezeichnet, was die Herausforderungen in der Softwarepflege hervorhebt (Hoffmann, 2013, S. 8-9). Übertragbarkeit (Portability): Bei der Übertragbarkeit oder Portierbarkeit steht die Frage im Vordergrund, wie problemlos sich bestehende Softwarelö- sungen in unterschiedliche Systemumgebungen integrieren lassen. Die Bedeu- tung dieses abstrakten Konzepts erstreckt sich über eine Vielzahl von Szena- rien, die in der Praxis aufkommen, wie die Anpassung von 32-Bit-Software an 64-Bit-Systemarchitekturen oder die Migration von Desktop-Software auf mo- bile Plattformen. Softwareprodukte auf dem Markt zeigen eine breite Varianz in ihrer Portierbarkeit. Während manche Anwendungen theoretisch ohne Mo- difikationen zwischen Systemen übertragen werden können, erfordern andere erhebliche Investitionen für solche Anpassungen, die bei einer vorausschauen- den Berücksichtigung grundlegender Softwaretechnikprinzipien vermeidbar gewesen wären (Hoffmann, 2013, S. 9). Testbarkeit (Testability): Die Testbarkeit spielt eine wesentliche Rolle bei der Früherkennung von Softwarefehlern und ist eng mit der Wartbarkeit verbun- den, die sich auf die zeitnahe Behebung von Problemen konzentriert. Die Her- ausforderung der Testbarkeit liegt in der Komplexität der Programme, die so umfangreich sein kann, dass eine vollständige Überprüfung aller möglichen Ein- gabe- und Ausgabekombinationen nicht realisierbar ist. Zusätzlich ist das Tes- ten vieler Algorithmen oft nur möglich, wenn interne Zustände und ······················································································································ 24 Softwarequalität ······························································································ Datenstrukturen für externe Zugriffe offenliegen. Der geschlossene Charakter vieler Software-Systeme erfordert daher die Implementierung zusätzlicher Codes, um solche Tests zu ermöglichen. Bei eingebetteten Systemen, die für den Massenmarkt konzipiert sind, erschwert die Reduktion von Debugging- Funktionen aus Kostenüberlegungen spät im Entwicklungsprozess das Aufspü- ren und Beheben von Fehlern erheblich (Hoffmann, 2013, S. 9). Die genannten Qualitätsaspekte kommen vielleicht der ein oder anderen Leserin bekannt vor. Das liegt daran, dass sie in der Softwareentwicklung weite Verbreitung erfahren haben. Wir werden uns in Kapitel 4 erneut mit Qualitätsaspekten bezie- hungsweise Qualitätsmerkmalen beschäftigen, um ein sogenanntes „Qualitätsmo- dell“ für das Messen von Softwareeigenschaften zu erstellen. Außerdem sind Qua- litätsaspekte Gegenstand diverser Normen zur Qualitätssicherung. Im Laufe des Skriptums wurde auf solche Normen bereits kurz verwiesen (zum Beispiel beim „produktbezogenen Ansatz“ oder bei einem Definitionsvorschlag für Softwarequa- lität). Der folgende Abschnitt soll noch einmal explizit Normen, Standards und Mo- dellen gewidmet werden. 1.4 Standards, Normen und Modelle Standards, Normen und Modelle sind wesentliche Bestandteile des Quality Engine- erings, insbesondere auch im Bereich der Softwareentwicklung. Sie bieten Richtli- nien und Vorgaben, um die Qualität von Softwareprodukten sicherzustellen und zu verbessern. Der Unterschied zwischen Standards und Normen kann manchmal sub- til sein, da beide Begriffe oft in ähnlichen Zusammenhängen verwendet werden. Trotz ihrer Ähnlichkeiten gibt es jedoch einige Schlüsselunterschiede: Standards bieten allgemeine Richtlinien oder Anforderungen für bestimmte Verfahren, Produkte, Dienstleistungen oder Managementpraktiken. Sie zielen darauf ab, Qualität, Sicherheit, Effizienz oder Interoperabilität zu fördern. Da- bei haben Standards haben oft einen weniger formalen Charakter (als Normen) und ihre Anwendung ist in der Regel freiwillig, es sei denn, sie werden durch gesetzliche Vorschriften oder in Verträgen spezifisch gefordert. Standards kön- nen von verschiedenen Organisationen entwickelt werden, darunter Industrie- gruppen, Fachverbände oder sogar einzelne Unternehmen. Sie müssen nicht unbedingt von einer offiziellen Normungsorganisation anerkannt oder heraus- gegeben werden. ······················································································································ 25 Softwarequalität ······························································································ Normen dienen dazu, einheitliche und wiederholbare Verfahren, Kriterien, Me- thoden und Prozesse innerhalb bestimmter Bereiche zu etablieren. Sie sollen die Kompatibilität und Austauschbarkeit von Produkten und Dienstleistungen sicherstellen und technische Barrieren im Handel minimieren. Sie können einen verbindlicheren Charakter als Standards haben, besonders wenn sie durch Ge- setze, Verordnungen oder in spezifischen Industrien als Mindestanforderungen anerkannt werden. Ihre Einhaltung kann für die Zertifizierung bestimmter Pro- dukte oder Systeme erforderlich sein. Normen werden typischerweise von na- tionalen, internationalen oder branchenspezifischen Normungsorganisationen erstellt. Beispiele hierfür sind die International Organization for Standardiza- tion (ISO), das Deutsche Institut für Normung (DIN) oder das American National Standards Institute (ANSI). Es lässt sich also festhalten, dass der Hauptunterschied zwischen Standards und Normen in ihrer Herkunft, ihrer Verbindlichkeit und dem Grad ihrer formalen Aner- kennung liegt. Normen sind in der Regel formeller und werden von anerkannten Normungsorganisationen mit dem Ziel herausgegeben, einheitliche Spezifikationen und Verfahren zu schaffen, deren Einhaltung häufig verbindlich ist. Standards hin- gegen können von einer breiteren Palette von Organisationen entwickelt werden und dienen als allgemeine Richtlinien mit einem flexibleren Anwendungsbereich. Im Gegensatz zu Standards und Normen, die also spezifische Richtlinien, Anfor- derungen oder Spezifikationen festlegen, repräsentieren Modelle eher konzep- tionelle Rahmenwerke oder Methodiken. Sie dienen der Beschreibung, Ent- wicklung, Bewertung und Verbesserung von Prozessen und Produkten. In an- deren Worten, Modelle bieten ein strukturiertes System von Prinzipien, Prakti- ken und Kriterien, das darauf abzielt, bestimmte Ziele zu erreichen, wie zum Beispiel die Verbesserung der Softwarequalität oder der Effizienz von Entwick- lungsprozessen. Sie sind nicht nur auf die Einhaltung von Richtlinien ausgerich- tet, sondern darauf, Organisationen zu helfen, ihre Prozesse zu verstehen und systematisch zu verbessern. Dabei sind Modelle oft flexibler und anpassungs- fähiger als Standards oder Normen. Sie können an die spezifischen Bedürfnisse und Ziele einer Organisation angepasst werden. Modelle umfassen häufig eine Sammlung von Best Practices, Werkzeugen und Methoden, die Organisationen bei der Implementierung von Verbesserungen unterstützen. Sie sind darauf ausgelegt, einen ganzheitlichen Ansatz zur Erreichung von Qualitätszielen zu ······················································································································ 26 Softwarequalität ······························································································ bieten, der über die bloße Einhaltung von festgelegten Standards oder Normen hinausgeht. Viele Modelle, wie das Capability Maturity Model Integration (CMMI) oder das Agile Modell, beinhalten Bewertungsmethoden, um den Rei- fegrad oder die Leistungsfähigkeit von Prozessen innerhalb einer Organisation zu messen. Diese Bewertungen helfen Organisationen, Bereiche für Verbesse- rungen zu identifizieren und Fortschritte über die Zeit zu verfolgen. 1.4.1 Zur Anwendung von Standards und Modellen Normen und Standards spielen eine bedeutende Rolle bei der Softwarequalität, ins- besondere aufgrund der häufigen Veränderungen in den Anforderungen und der Terminologie der Kunden. In solchen Situationen sind klare Referenzpunkte und eindeutige Begriffe von entscheidender Bedeutung. Es ist daher ratsam, sich an normierten Begriffen und Definitionen zu orientieren, wenn man die Qualität, zum Beispiel die eines Projektes, fördern möchte (Schneider, 2012). Allerdings gibt es sehr viele Standards und Normen, etc. Die reine Menge erschwert die Sichtung und Auswahl relevanter Vorgaben erheblich. Für ein besseres Ver- ständnis ist es dabei zunächst sinnvoll zwischen zwei Arten von Normen zu unter- scheiden: Produktnormen und Prozessnormen. Das es diesen Unterschied gibt, ist bisher immer Mal implizit im Text angeklungen; hier noch einmal explizit die Unter- schiede: Historisch betrachtet haben sich Normen als Reaktion auf industrielle und techno- logische Fortschritte entwickelt. Ursprünglich lag der Fokus auf Produktnormen, die mit der Industrialisierung im 19. Jahrhundert an Bedeutung gewannen. Diese Normen sollten sicherstellen, dass Produkte bestimmte Qualitäts- und Sicherheits- standards erfüllen, was für Hersteller und Verbraucher gleichermaßen von Vorteil war. Der Hauptvorteil von Produktnormen liegt in der Vereinheitlichung von Pro- duktspezifikationen, was die Kompatibilität und Austauschbarkeit von Komponen- ten erleichtert und somit zur Effizienzsteigerung und Kostenreduktion beiträgt (vgl. oben). Ein möglicher Nachteil ist jedoch, dass die strikte Einhaltung von Produkt- normen die Innovationsfreiheit einschränken kann. Mit der Zeit und der zunehmenden Komplexität von Produktionsprozessen und Dienstleistungen rückten Prozessnormen in den Vordergrund. Diese Entwicklung reflektiert das Bedürfnis, nicht nur das Endprodukt, sondern auch die Art und Weise seiner Entstehung zu optimieren. Prozessnormen, die insbesondere im 20. ······················································································································ 27 Softwarequalität ······························································································ Jahrhundert mit dem Aufkommen von Qualitätsmanagement-Systemen (z. B. ISO 9000) an Bedeutung gewannen, zielen darauf ab, die Effizienz und Qualität von Pro- zessen zu verbessern. Der Vorteil von Prozessnormen liegt in der Förderung von Best Practices und der kontinuierlichen Verbesserung, was zu einer höheren Pro- duktqualität und Kundenzufriedenheit führen kann. Ein Nachteil könnte sein, dass die Implementierung dieser Normen aufwendig und kostenintensiv ist, insbeson- dere für kleinere Unternehmen. Neben den besagten Produkt- und Prozessnormen eignen sich außerdem noch Nor- men, die sich auf Audits oder auf Menschen beziehen, um die Fülle aller Vorschrif- ten und Empfehlungen zu sondieren und einzuteilen (Wallmüller, 2011). Ein Audit ist ein systematischer, unabhängiger und dokumentierter Prozess zur Be- wertung, ob die tatsächlichen Geschäftsprozesse und -ergebnisse den geplanten Arrangements, Anforderungen von Normen oder anderen regulatorischen Vorga- ben entsprechen. Audits können intern (durch die Organisation selbst) oder extern (durch Dritte) durchgeführt werden und sind entscheidend für die kontinuierliche Verbesserung und die Aufrechterhaltung der Konformität mit Standards. Es gibt spezifische Normen, die sich mit den Prinzipien und Anforderungen für die Durch- führung von Audits befassen. Diese Normen legen fest, wie Audits geplant, durch- geführt, dokumentiert und bewertet werden sollen, um ihre Effektivität und Zuver- lässigkeit zu gewährleisten. Ein bekanntes Beispiel ist die ISO 19011. Diese interna- tionale Norm gibt Leitlinien für das Auditieren von Managementsystemen. Sie um- fasst die Prinzipien des Auditierens, die Leitung eines Auditprogramms, die Durch- führung von Managementaudits sowie die Bewertung der Kompetenz von Perso- nen, die am Auditprozess beteiligt sind. ISO 19011 ist anwendbar auf eine Vielzahl von Managementsystemen, einschließlich, aber nicht beschränkt auf, Qualitäts- und Umweltmanagementsysteme. Mitarbeiter beziehen sich auf das Personal oder die Menschen, die in einer Orga- nisation arbeiten. In Normen und Modellen wird oft betont, wie wichtig die Rolle der Mitarbeiter für die Qualitätssicherung ist. Dazu gehören ihre Fähigkeiten, Schu- lungen, Motivation und Engagement. Mitarbeiterorientierte Aspekte umfassen oft Personalmanagement, Kompetenzentwicklung und die Schaffung einer Kultur der kontinuierlichen Verbesserung. ······················································································································ 28 Softwarequalität ······························································································ Die Unterscheidung zwischen diesen Aspekten in Normen, Modellen und Standards zeigt die umfassende Sichtweise des Qualitätsmanagements, das nicht nur die End- produkte, sondern auch die Wege zur Erstellung dieser Produkte, die Überprüfung der Konformität und die Rolle der Mitarbeiter in diesem Prozess berücksichtigt. Die Integration dieser Elemente in ein kohärentes Qualitätsmanagementsystem er- möglicht es Organisationen, ihre Leistung kontinuierlich zu verbessern und die Zu- friedenheit ihrer Kunden zu erhöhen. Die Fülle an Normen kann verwirrend sein, und es wäre einfacher, wenn es weniger, klar definierte Richtlinien gäbe. Das Verständnis für die relevanten Normen ist ein erster Schritt, um die Grundlagen der Softwarequalität zu erlernen (Schneider, 2012). Eine Zusammenstellung besonders relevanter Standards, Normen und Mo- delle wird als nächstes bereitgestellt. 1.4.2 Wichtige Standards und Modelle der Softwarequalität Die ISO 9126 (Produktnorm), eingeführt in den späten 1990er Jahren, war eine der ersten internationalen Normen, die sich auf Softwarequalität kon- zentrierte. Sie definierte ein Modell für Softwarequalität, das sich in sechs Hauptqualitätsmerkmale gliederte: Funktionalität, Zuverlässigkeit, Benutzbar- keit, Effizienz, Wartbarkeit und Portabilität. Jedes dieser Merkmale wurde wei- ter in Unterkriterien unterteilt, um eine umfassende Bewertung der Software- qualität zu ermöglichen. Ziel der ISO 9126 war es, Entwicklerinnen, Käuferinnen und Benutzerinnen von Software ein gemeinsames Verständnis von Qualität zu bieten und eine Basis für die Bewertung und Auswahl von Softwareprodukten zu schaffen. Die ISO/IEC 25000-Reihe, bekannt als SQuaRE (Software Product Quality Requi- rements and Evaluation), bildet die evolutionäre Fortsetzung der ISO/IEC 9126 Standards und bietet einen umfassenden Rahmen für die Bewertung der Soft- warequalität. Diese Normenserie setzt sich zum Ziel, klare Anforderungen für Softwareprodukte zu definieren und Richtlinien für deren Bewertung zu liefern. Dadurch wird sowohl die Entwicklung als auch die Auswahl von Softwarepro- dukten erleichtert. Im Gegensatz zu ihrem Vorgänger ISO/IEC 9126, der sich auf die Definition von Qualitätsmerkmalen und Untermerkmalen konzentrierte, bietet die ISO/IEC 25000-Serie einen erweiterten Rahmen, der sich über den gesamten Lebenszyklus der Softwareentwicklung erstreckt. Sie legt einen be- sonderen Schwerpunkt auf die Messbarkeit der Softwarequalität und gibt ······················································································································ 29 Softwarequalität ······························································································ detaillierte Anleitungen zur Bewertung und Verbesserung von Softwareproduk- ten. Innerhalb dieser Normenserie wird ein Qualitätsmodell vorgestellt, das aus ver- schiedenen Qualitätsmerkmalen wie Funktionalität, Zuverlässigkeit, Benutz- barkeit, Effizienz, Wartbarkeit und Portabilität besteht (mehr zu Qualitätsmo- dellen in Abschnitt 4.1). Diese sind entscheidend, um als Richtschnur für die Entwicklung und Bewertung von Software zu dienen. Ferner liefert die Serie Methoden für die Messung von Softwarequalität, indem sie Metriken für Qua- litätsmerkmale definiert und Anleitungen zur Auswertung der Messergebnisse bietet. Die Bewertung der Softwarequalität umfasst Verfahren zur Analyse von Softwareprodukten und -prozessen und stellt sicher, dass diese den Bedürfnis- sen der Stakeholder entsprechen. Zusätzlich beschäftigt sich die ISO/IEC 25000-Reihe mit Aspekten des Qualitäts- managements. Sie gibt Empfehlungen für die Etablierung, Implementierung, Aufrechterhaltung und kontinuierliche Verbesserung von Qualitätsmanage- mentsystemen, die auf Softwareprodukte ausgerichtet sind. Dadurch wird eine solide Basis für ein hohes Qualitätsniveau in der Softwareentwicklung geschaf- fen, was letztendlich zur Steigerung der Kundenzufriedenheit beiträgt. Die DIN EN ISO 9241-11:2018-11 (Prozessnorm) ist Teil der internationalen Normenreihe ISO 9241, die sich mit der Ergonomie der Mensch-System-Inter- aktion beschäftigt. Diese spezielle Norm (ISO 9241-11) legt Richtlinien und An- forderungen für die Gebrauchstauglichkeit fest, definiert als das Ausmaß, in dem ein Produkt, System oder Dienst von bestimmten Benutzern in einem be- stimmten Nutzungskontext effektiv, effizient und zufriedenstellend genutzt werden kann. Die Hauptziele der Norm sind die Definition, Messung und Pla- nung von Gebrauchstauglichkeit: Sie bietet eine klare Definition von Ge- brauchstauglichkeit und erklärt, wie diese sich auf die Benutzerzufriedenheit, Effizienz und Effektivität der Nutzung eines Produkts oder Systems auswirkt. Sie gibt Anleitungen, wie die Gebrauchstauglichkeit in den verschiedenen Phasen der Produktentwicklung und -bewertung berücksichtigt und integriert werden kann. Die Norm wird in einer Vielzahl von Branchen angewendet, darunter Soft- wareentwicklung, Webdesign, Maschinen- und Anlagenbau sowie in der Pro- duktentwicklung für Konsumgüter. Dabei ist die DIN EN ISO 9241-11:2018-11 primär eine Prozessnorm. Obwohl die Ergebnisse – effiziente, effektive und zu- friedenstellende Produkte oder Systeme – direkt mit Produkten verbunden ······················································································································ 30 Softwarequalität ······························································································ sind, konzentriert sich die Norm selbst auf den Prozess der Gestaltung und Be- wertung der Gebrauchstauglichkeit. Sie bietet also Anleitungen, wie Organisa- tionen und Entwickler die Benutzererfahrung durch methodische Ansätze im Design- und Entwicklungsprozess verbessern können, macht aber keine spezi- fischen Vorgaben für die physischen Eigenschaften eines Produkts selbst. Das V-Modell erläutert detailliert die erforderlichen Schritte und Prozesse in der System- und Softwareentwicklung, wobei es sich als Grundlage für unter- nehmensspezifische Richtlinien etabliert hat. Trotz seiner umfassenden und de- taillierten Vorgaben ist es für die meisten Projekte eine Herausforderung, es in vollem Umfang umzusetzen. Das V-Modell XT, die Weiterentwicklung des Ori- ginals aus dem Jahr 1997, bietet daher verbesserte Anpassungsmöglichkeiten. Im deutschsprachigen Raum gilt es als maßgebliche Methodik für strukturierte Softwareentwicklungsprozesse und bezieht auch Qualitätsaspekte mit ein (Schneider, 2012). Nähere Informationen werden in Abschnitt 2.2.1 präsen- tiert. Das Capability Maturity Model Integration (CMMI) ist ein Rahmenwerk für die Verbesserung der Prozessqualität in Organisationen, insbesondere in der Soft- wareentwicklung, der Systementwicklung und in anderen Bereichen der Infor- mations- und Technologiebranche. CMMI wurde ursprünglich vom Software Engineering Institute (SEI) der Carnegie Mellon University entwickelt und wird nun von dem CMMI Institute verwaltet. Weitere Informationen in Abschnitt 2.3.1 und 2.3.2. Die ISO 9000er-Reihe befasst sich generell mit Qualitätsmanagement und ist nicht auf den technischen oder Softwarebereich beschränkt. Ein spezifischer Leitfaden innerhalb dieser Reihe, ISO 9001-3, bietet detaillierte Anweisungen für die Anwendung der Prinzipien im Softwarekontext (Schneider, 2012). ANSI/IEEE Standard 729-1983 definierte grundlegende Begriffe des Software Engineerings und wurde später durch IEEE 610.12-1990 aktualisiert. Diese und andere Normen spezifizieren verschiedene Aspekte der Softwarequalität noch detaillierter (Schneider, 2012). ······················································································································ 31 Softwarequalität ······························································································ 1.5 Überblick Qualitätsmaßnahmen Schneider (2012) beschreibt drei grundlegende Qualitätssicherungsmaßnahmen. 1) Organisatorische Maßnahmen: Diese beziehen sich auf die Strukturierung und Verwaltung der Prozesse und Res- sourcen, die für die Sicherstellung der Softwarequalität erforderlich sind. Sie um- fassen die Definition von Rollen und Verantwortlichkeiten, die Einrichtung von Qua- litätsmanagementsystemen, die Entwicklung von Qualitätsrichtlinien und -stan- dards sowie die Planung und Steuerung des Qualitätsmanagements innerhalb eines Projekts. Dazu gehört auch die Schulung und Weiterbildung der Mitarbeiter, um das Bewusstsein für Qualitätsthemen zu fördern und die erforderlichen Kompetenzen für die Qualitätsarbeit zu schaffen. Organisatorische Maßnahmen legen somit den Grundstein dafür, dass die folgenden beiden Maßnahmen – Analytische und Kon- struktive – durchführbar sind (Schneider, 2012). 2) Analytische Maßnahmen: Diese Maßnahmen umfassen Aktivitäten zur Bewertung und Überprüfung der Soft- ware und ihrer Komponenten, um Fehler und Mängel zu identifizieren und diese dann später zu beheben. Dazu gehören verschiedene Formen des Tests (wie Unit- Tests, Integrationstests, Systemtests, Akzeptanztests), Code-Reviews, Software-In- spektionen und Walkthroughs. Analytische Maßnahmen sind darauf ausgelegt, das Produkt zu überprüfen und sicherzustellen, dass es den festgelegten Anforderun- gen und Qualitätsstandards entspricht. Es muss also bereits ein fertiger Prüfling vorliegen. Analytische Maßnahmen gehören zu den bekanntesten Maßnahmen für die Sicherstellung von Softwarequalität (Schneider, 2012). 3) Konstruktive Maßnahmen: Diese Maßnahmen zielen darauf ab, Qualität in den Softwareentwicklungsprozess einzubauen, anstatt Fehler im Nachhinein zu finden und zu korrigieren. Sie beinhal- ten den Einsatz von guten Design- und Codierungspraktiken, die Verwendung von standardisierten Entwicklungsprozessen, den Einsatz wiederverwendbarer Soft- warekomponenten und die Implementierung von Tools und Umgebungen, die eine hohe Qualität fördern. Konstruktive Maßnahmen sind präventiv und unterstützen die Erstellung von qualitativ hochwertigem Code von Anfang an. ······················································································································ 32 Softwarequalität ······························································································ Wir werden jeder dieser drei Qualitätsmaßnahmen im weiteren Verlauf des Skrip- tums seinen Platz einräumen und verwenden sie auch zur Strukturierung des ver- bleibenden Textes. Die organisatorischen Maßnahmen werden dabei am wenigsten Beachtung finden, denn der Fokus soll auf der eigentlichen Software-Entwicklung und ‚Arbeit am Code‘ liegen als auf Themen, die auch in Vorlesungen zum Projekt- management und ähnlichen Themen zu finden sind. Das bedeutet, dass wir die meiste Zeit auf konstruktive und analytische Verfahren verwenden werden und we- niger auf Managementprozesse. Abbildung 5 verschafft eine gute Übersicht über die wichtigsten Aspekte und Maß- nahmen zur Softwarequalitätssicherung nach Hoffmann (2013). Dort finden wir auch die Unterteilung in Produkt- und Prozessqualität wieder, die wir schon in Ab- schnitt 1.4 kennengelernt haben. Wenig überraschend ordnet Hoffmann (2013) der Prozessqualität die organisatorischen Maßnahmen unter. Hier verzeichnet er „Ma- nagementprozesse“ und „Software-Infrastruktur“. Auf beide Inhalte werden wir in Kapitel 2 eingehen. Unter „Produktqualität“ finden sich die konstruktiven sowie die analytischen Maßnahmen. Die Darstellung in Abbildung 5 beinhaltet viele wichtige Verfahren und Aspekte und kann somit als eine interessante ‚Landkarte‘ zur Softwarequalität dienen. Einige der genannten (Unter-)Punkte werden wir in den folgenden Kapiteln im Detail an- schauen. ······················································································································ 33 Softwarequalität ······························································································ Abbildung 5: Eine ‚Landkarte‘ zur Verzeichnung der wichtigsten Aspekte und Maßnahmen zur Soft- warequalität, i. A. a. Hoffmann (2013, S. 20) Im vorliegenden Skriptum behandeln wir die konstruktive sowie analytische Quali- tätssicherung ausführlich (siehe „Produktqualität“). Die unter „Prozessqualität“ zu- sammengefassten Punkte werden im Kapitel zu den organisatorischen Qualitäts- maßnahmen kurz gestreift (siehe Kapitel 2). ······················································································································ 34 Softwarequalität ······························································································ 1.6 Hinweise zur Literatur und zur Verwendung dieses Skrip- tums Abschließend zu Kapitel 1 werden einige Hinweise und Leseempfehlungen zu der Literatur, die für dieses Skript herangezogen wurde, bereitgestellt. Grundlagen und Einstieg: Das Skript stützt sich vorrangig auf die Inhalte von Schneider (2012) und Hoffmann (2013). Schneider wird aufgrund seiner zu- gänglichen Schreibweise besonders für Anfänger empfohlen. Das Werk vermit- telt Grundlagen der Softwarequalität und legt das Fundament für weiterfüh- rende Studien. Für eine allgemeine Einführung eignet sich außerdem das Lehr- buch von Krypczyk und Bochkor (2018) zur Softwareentwicklung. Neben Infor- mationen zum Testen und Softwarequalität können dort auch Inhalte zu Requi- rements Engineering (Unit 1) wiederholt werden. Technische Vertiefung: Hoffmanns Ansatz ist stellenweise technischer und geht in die Tiefe der Materie. Sein Buch ist gut geeignet für fortgeschrittene Leser, die ein technisches Verständnis von Software-Qualitätssicherung entwickeln möchten. Erweiterter Fokus: Wallmüller (2011) ergänzt das Skript mit einem breiten Blick auf Qualitätsmanagement. Er bezieht sich nicht nur auf Softwareprodukte, son- dern auch detailliert auf Prozesse und Organisationsstrukturen. Seine Ausfüh- rungen sind hilfreich, um ein holistisches Verständnis von Qualität in der Soft- wareentwicklung zu erlangen. Internationale Perspektiven: Für Leserinnen mit einem Interesse an englisch- sprachiger Fachliteratur ist Westfall (2016) eine gute Ergänzung. Sie bietet ver- gleichbare Inhalte zu Wallmüller, jedoch aus einer internationalen Perspektive. ······················································································································ 35 Softwarequalität ······························································································ 1.7 Kontrollfragen Welche Aspekte sind entscheidend, um die Qualität in der Softwareentwicklung Übung zu sichern oder zu steigern? Multiple-Choice-Fragen: A) ausschließliche Konzentration auf die Codierung B) ausgiebiges Testen nach dem „Code-and-Fix“-Ansatz C) Implementierung von organisatorischen, analytischen und konstruktiven Maß- nahmen D) Verlass auf Fehlermeldungen der Compiler als Hauptqualitätssicherungsme- thode Welcher der folgenden Ansätze beschreibt Qualität als Übereinstimmung mit vor- gegebenen Spezifikationen und betont die Bedeutung von strengen Kontrollen sowie die präzise Ausführung von Entwicklungs- und Produktionsprozessen? Multiple-Choice-Fragen: A) der transzendentale Ansatz B) der prozessbezogene bzw. herstellerbezogene Ansatz C) der anwenderinnenbezogene Ansatz D) der produktbezogene Ansatz Welcher Aspekt spielt eine wesentliche Rolle für die langfristige Lebensdauer und Marktpräsenz von Softwareprodukten? Multiple-Choice-Fragen: A) Die Endkontrolle und Fehlerprüfung unmittelbar vor der Markteinführung eines Software-Produkts. B) Die kontinuierliche Aktualisierung und Verbesserung der Benutzerschnittstellen nach dem neuesten Design-Trend. C) Die anfängliche Geschwindigkeit und Performance der Software bei der Markteinführung. D) Die Möglichkeit, Software nach der Markteinführung zu korrigieren, zu modifi- zieren und zu erweitern, also ihre Wartbarkeit. ······················································································································ 36 Softwarequalität ······························································································ Was ist der Hauptunterschied zwischen Standards und Normen im Kontext von Quality Engineering? Multiple-Choice-Fragen: A) Standards sind formeller und von anerkannten Normungsorganisationen, wäh- rend Normen von einer breiteren Palette von Organisationen entwickelt werden. B) Normen haben oft einen weniger formalen Charakter als Standards und ihre An- wendung ist in der Regel freiwillig. C) Standards sind konzeptionelle Rahmenwerke, die zur Beschreibung, Entwicklung und Verbesserung von Prozessen dienen. D) Normen sind in der Regel formeller und werden von anerkannten Normungsor- ganisationen herausgegeben, deren Einhaltung häufig verbindlich ist. Was ist der Hauptzweck von Prozessnormen im Qualitätsmanagement? Multiple-Choice-Fragen: A) Die Sicherstellung, dass Produkte bestimmte Qualitäts- und Sicherheitsstandards erfüllen. B) Die Vereinheitlichung von Produktspezifikationen zur Förderung von Effizienz- steigerung und Kostenreduktion. C) Die Optimierung der Art und Weise, wie ein Endprodukt entsteht, um die Effizi- enz und Qualität von Prozessen zu verbessern. D) Die Definition von Gebrauchstauglichkeit und die Messung der Benutzerzufrie- denheit, Effizienz und Effektivität. Welcher Standard bietet einen umfassenden Rahmen für die Bewertung der Soft- warequalität, der sich über den gesamten Lebenszyklus der Softwareentwicklung erstreckt? Multiple-Choice-Fragen: A) DIN EN ISO 9241-11:2018-11 B) ISO 9126 C) ISO/IEC 25000-Reihe D) ANSI/IEEE Standard 729-1983 ······················································································································ 37