Softwarequalität zum Anfassen: Gibt es so etwas?

Transkript

1 Softwarequalität zum Afasse: Gibt es so etwas? Softwarequalität zum Afasse: Gibt es so etwas? Softwarequalität ist ei sehr schwer greifbarer, abstrakter Begriff. Das ist so, trotz (oder gerade wege?) der Vielzahl a Qualitätsmodelle i der IT. Um Softwarequalität fassbar zu mache, bräuchte ma zum eie ei gazheitliches, ituitiv verstädliches Qualitätsmodell ud zum adere eie Qualitätssicherugsprozess, der die Idee aus dem Qualitätsmodell im Projektalltag ud im Softwareprodukt spürbar werde lässt. Aber was ist Softwarequalität eigetlich? Wer bestimmt, was Qualität ist? Wie ka sie gesteuert werde? Gibt es ei ituitiv verstädliches Qualitätsmodell? Diese ud weitere Frage geht der Artikel ach. Softwarequalität wird häufig a eier Liste vo sogeate icht-fuktioale Eigeschafte festgemacht, die gute Software habe sollte. Diese Eigeschafte, dere Name meistes auf...keit oder...heit ede, sid i der Regel eigeteilt i Haupteigeschafte ud Eigeschafte, die zu eier bestimmte Haupteigeschaft gehöre. Diese Eiteilug ka ma da Modell oder Norm ee. Die Zahl dieser Modelle ud Norme scheit ählich groß zu sei wie die Zahl der dari ethaltee keite ud heite. Auf der Suche ach Softwarequalität verliert ma sich also icht ur leicht i der Vielzahl vo Softwareeigeschafte, soder auch i der Vielzahl der Modelle ud Norme (siehe Abbildug 1). Was ist Softwarequalität? Defiitio 1 i Kaste 1 macht deutlich, dass Softwarequalität vo explizite (bewusste) ud implizite (ubewusste) Bedürfisse abhägt. Nebe dem Aweder ud dem Kude der Software gibt es och zahlreiche adere Akteure, die im Lebeszyklus der Software eie Stakeholder darstelle, ud alle habe ihre jeweils eigee Bedürfisse ud Erwartuge (siehe Abbildug 2). Jeder dieser Stadpukte hat seie Berechtigug ud ka seie Beitrag zur Softwarequalität leiste. Bei eutraler, traszedeter Betrachtug lässt sich feststelle, dass trotz aller Maßahme für Softwarequalität letztlich immer die subjektive Zufriedeheit der Akteure (vor allem die des Geldgebers bzw. Kude) ausschlaggebed ist. Es gibt Verfahre ud Maßahme zum Erreiche vo Softwarequalität, die allerdigs viel Erfahrug beötige ud gegebeefalls eie Kompromiss zwische sich widersprechede Bedürfisse ud Erwartuge der Akteure erforderlich mache. I Defiitio 2 i Kaste 1 kommt zum Ausdruck, dass Software zwei verschiedee Aspekte beihaltet: das Softwareprodukt de Softwareetwicklugsprozess Defiitio 1 Softwarequalität ist die Gesamtheit vo Fuktioe ud Merkmale eies Softwareprodukts, das die Fähigkeit besitzt, agegebee oder implizite Bedürfisse zu befriedige (vgl. [Wik-a]). Defiitio 2 Softwarequalität ist die Summe aller relevate Eigeschafte eies Softwareprodukts, mit dee seie Kude zufriedegestellt werde, ud die Summe der dazu otwedige Eigeschafte vo Softwareprozesse, die zur Erstellug, zum Betrieb ud zur Pflege gefordert werde (vgl. [Wal11]). Defiitio 3 Softwarequalität ist eie Auszeichug vo Software für folgede drei maßgebliche Aspekte: Korrektheit: Das Produkt wird seie fuktioale ud icht-fuktioale Aforderuge gerecht (vgl. [Wes12]). Produktioseffiziez: Die Herstellugskoste der Software etspreche de gegebee Rahmebediguge (vgl. [Wes13-b]). Evolvierbarkeit: Der Etwicklugsprozess stellt ei otwediges Maß a Wartbarkeit der Software sicher (vgl. [Wes13-a]). Kaste 1: Defiitioe vo Softwarequalität. Abb. 1: Eie Übersicht existiereder Modelle ud Norme i der IT (aus [Wal11], S. 30). Die existierede Erwartuge ud Bedürfisse der Akteure richte sich a beide Aspekte. Der Aspekt Softwareprodukt 54

2 Abb. 2: Es gibt sehr uterschiedliche Sichte auf die Software(-qualität), die sich alle aus de Rolle der jeweilige Akteure ergebe. stellt eher die Kudebedürfisse dar, der Aspekt Softwareetwicklugsprozess eher die Bedürfisse der Etwickler. Defiitio 3 i Kaste 1 erweitert Defiitio 2 um de Aspekt der Etwicklugskoste (b). Produktqualität (a) ud Prozessqualität (c) sid gleich gewichtet. Diese drei Aspekte mache zusamme das aus, was wir uter Softwarequalität verstehe (vgl. auch [CCC-a]). Wartbarkeit ist ei Aspekt, der selte explizit, aber meistes implizit gefordert wird. Im Kao-Modell (vgl. [CCC-i]) stellt die Wartbarkeit eie Basisfaktor dar, der we sie icht ausreiched ist als großes Qualitätsdefizit wahrgeomme wird. Alle drei Defiitioe habe das gleiche Problem: Sie beschreibe ur sehr abstrakt, was Softwarequalität sei soll. Kokret wird aber icht deutlich, was das für die Software, d. h. das Projekt ud das Produkt, bedeutet ud wie ma sie erreicht. Abhilfe schafft hier ei Qualitätsmodell. Aspekte vo Softwarequalität müsste dari ethalte sei. Außerdem müsste die keite ud heite so zu strukturiere sei, dass eie ituitiv verstädliche Ordug etsteht. Das würde es dem Nutzer des Qualitätsmodells erlaube, die Vielzahl a Qualitätsmerkmale leichter zu überschaue, eigee Prioritäte/Schwerpukte zu setze ud eie persöliche oder projektspezifische Checkliste zu formuliere, dere Abarbeitug verhidert, dass wichtige Qualitätsziele übersehe werde. Eie solche ituitiv verstädliche Ordug müsste sich aus der Natur, aus dem Wese vo Software, ableite lasse. Defiitio 2 i Kaste 1 uterscheidet zwische Produktqualität ud Prozessqualität. Diese Uterscheidug ist tatsächlich vo grudlegeder Bedeutug (vgl. auch [CCC-b]). Betrachtet ma das Produkt, lasse sich die beide Teilaspekte Awedug ud Betrieb uterscheide. Betrachtet ma de Prozess, lasse sich die drei Teilaspekte Auslieferug, Etwicklug ud Aforderug uterscheide. Diese Eiteilug stellt die Keraussage des i Abbildug 3 gezeigte Qualitätsmodells dar. Nach diesem Modell gibt es sechs Teilaspekte vo Software, die i Tabelle 1 erläutert werde. Diese Teilaspekte lasse sich sehr schö auf das Eisberg-Modell projiziere. Im Eisberg-Modell werde die Bedeutug ud der fließede Übergag vo ierer (versteckter) ach äußerer (sichtbarer) Qualität achvollziehbar visualisiert (vgl. [CCC-c]). Die Eisberg-Metapher macht deutlich, dass die iere Qualitätsmerkmale die äußere Ei (be-)greifbares Qualitätsmodell Aus Sicht des Nutzers eies Softwarequalitätsmodells ist der praktische Eisatz im Etwickleralltag vo großer Bedeutug. Zu diesem Zweck wäre eie gazheitliche Awedbarkeit wichtig, d.h. alle wesetliche Abb. 3: Ei gazheitliches Modell für Softwarequalität mit eier Hierarchie vo Merkmale ud Merkmalsgruppe, das sich aus de uterschiedliche Aspekte der Software ableite lässt (siehe Defitio 3 i Kaste 1). 06/

3 Softwarequalität zum Afasse: Gibt es so etwas? trage müsse, asoste ka die aus dem Wasser ragede Eisbergspitze (das Softwareprodukt) icht die erforderliche Höhe ud Form erreiche. Das Qualitätsmodell i Abbildug 3 ka als gazheitlich betrachtet werde, da es alle Aforderuge aus dem ApplikatiosLebeszyklus a die Software umfasst vo der Aforderugsaalyse (RequiremetsEgieerig) über Etwicklug ud Betrieb bis hi zur Edawedug (vgl. [CCC-d]). Die Beeug ud Eiteilug der Qualitätsmerkmale i de utere Ebee (rechts im liegede Baum) ist icht immer eideutig (z.b. die Wiederherstellbarkeit) ud teilweise subjektiv. Etscheided sid hier aber die sechs Teilaspekte vo Software, die i Tabelle 1 äher erläutert werde. Sie zeige die große Bedeutugsbreite vo Softwarequalität. Die drei i Abbildug 3 weiß geschriebee Merkmale werde im Folgede geauer betrachtet. Tabelle 1: Beschreibug der sechs Teilaspekte vo Software aus Abbildug 3. Wartbarkeit, Koformität ud Rückverfolgbarkeit Für die Softwarequalität habe die Qualitätsmerkmale Wartbarkeit, Koformität ud Rückverfolgbarkeit (siehe Abbildug 3) eie herausragede Bedeutug. Koformität ist der Grad, i dem ei Produkt oder ei Prozess vereibarte Norme oder Vereibaruge erfüllt. Die Koformität ka als eie Art Querschittsmerkmal betrachtet werde. Koformität i alle Merkmale steigert die Effiziez durch Wiedererkeug ud verrigerter Fehlerwahrscheilichkeit. Das gilt für jede Akteur i seier jeweilige Rolle, sei es der User bei der Awedug der Software (z. B. GUI-Kompoete zeige eiheitliches Verhalte), der Admiistrator im Betrieb (z. B. Istallatiosskripte habe immer de gleiche Aufbau ud verwede dieselbe Techologie), der Etwickler bei der Implemetierug (z. B. Stadards im Desig der Software oder eiheitliche Verwedug vo Tools) oder der Fachexperte bzw. der Aforderugsmaager (gleicher Aufbau vo Use-Cases). Der Nutze, de die Koformität bietet, etfaltet sich allerdigs ur, we sich die betroffee Akteure auf eie eiheitliche Vorgehesweise eie Stadard eiige ud diese bewusst ud kosequet a- 56 Tabelle 2: Typische Maßahme, um gewüschte Qualitätsmerkmale zu realisiere.

4 schwerpukt Tipp 4: Abahmetests sollte immer grü sei Zero Bug Policy. Iteratio kapp wird. Das führt zu eiem beziehe. Test werk zeuge sid hierzu icht Auch we das Release och ei paar Woche gefährliche Trugschluss: We es akzeptabel i der Lage. Aus userer Sicht ist ei voll- etfert sei mag, ist es sehr wichtig, Testfälle ist, mauelle Tests im Notfall wegzustädig automatisierter UAT auch i der icht läger als otwedig fehlschlage zu lasse lasse, sid sie scheibar icht wichtig. agile Welt icht seriös durchführbar ausgeomme auch we ma die vermutliche Ursache ket. Auch i der agile Welt ist es der Zweck automatisierte Smoke-Tests, die Ei fehlschlageder Testfall ka durchaus vo Tests, Fehler i der Software zu fide. die Vollstädigkeit der Fuk tio alität oberflächlich Probleme verdecke, die erst ach Behebug der We automatisierte Tests dazu ur prüfe. Gele getlich werde auto- offesichtliche Ursache zu Tage trete. Ziel des bedigt i der Lage sid, gibt es lediglich matisierte GUI-Tests (Graphi cal-user- Teams muss es sei, die Testfälle auch währed eie Alterative: mauelles beziehugsweise exploratives Teste, bei dem die sid fuktioale Tests uter Eibeziehug Iterface) als UAT bezeichet. Diese Tests Tabelle der Etwicklug 3: Die grü Beseitigug zu halte. Grü vo bezieht Fehler, sich die im Requiremets-Egieerig gemacht, aber erst ach dem Release der Software bemerkt werde, hier auf die ka Sigalfarbe, um de die Faktor traditioell 100 i Build- teurer werde (Quelle [Wik-c]). Tester ihre Kreativität ud Spotaität eisetze, eier Oberfläche ud köe zum Beispiel Umgebuge eigesetzt werde. um Fehler zu fide. Ei weset- im Regressiostest eie wertvolle Beitrag licher Nutze maueller Tests besoders leiste. Sie sid aber kei Er satz für die bei eue Features ist die kotextbezogee Eibeziehug des Mesche als Tester. Perspektive auf die zu prüfede gehesweise, we die Erweiterug durch Fuktioalität. De im Gegesatz zu wede. Das ist ur bei guter Kommuikatio zwische de Akteure möglich, die Wartbarkeit, Koformität ud Rückverhe, bietet Tipp das 6: Zeitaher Team Clea UAT. Codig eie Bedeutug der Kommuikatio diese bewusst ud zielgerichtet zu vollzie- Umpriorisierug doch icht stattfidet ud automatisierte Tests ket der mauelle die Tests weiterhi mauell durchgeführt Tester dere aktuelle Kotext. Wildwuchs verhidert. folgbarkeit habe eies gemeisam: Sie Reihe vo Währed Best Practices der UAT i a der (vgl. klassische [CCC-h]). werde müsse. We es Kude ud Budget zulasse, Die Wartbarkeit ist ei Art Super-Merkmal, mache deutlich, dass die Kommuikatio Projektwelt eie abgeschlossee Phase Aus userer Erfahrug loht sich eie plae wir am Ede eier Iteratio für alle das mehrere Teilaspekte vo Software umfasst. Sie wird typischerweise auf de Quellprozess spielt. Gute Kommuikatio ist ei Aforderugsahe eie fudametale Rolle im Etwicklugs- darstellt, bietet es sich i agile Projekte sprechede, achvollziehbare Zuordug Etwickler eie Tag ei, desse Fokus auf a, umittelbar ach dem Abschluss eier vo Aforderuge (User-Storys) ud maueller Testdurchführug liegt. Ziel dieses Tages ist es, die Software zerbreche zu le. Will der Etwickler i Folge des Fuktioalität Nutzer-Feedback eizuhocode bezoge, fägt aber scho viel früher etscheideder Schlüssel zur Softwarequalität. Aweder, Fachexperte, Aforde- Die Qualität vo Prozesse, mit dee A- Softwarequalitätsmerkmale Akzeptaztests. Wird eie Aforderug im Prozess a ud reicht im Prozess och verädert oder erweitert, fließt der Auf - lasse. Geligt es, de Code durch Beut - Feedbacks Äderuge vorehme, ist bis i de Betrieb hiei. Wartbarkeit begit mit der Erhebug der Aforderuge Admiistratore gehöre zu eier Kommulität vo Dokumete, welche die Aforderugsmaager, Etwickler, Architekte ud forderuge ermittelt werde, ud die Qua- wad für eie otwedige Apassug zer eigabe oder Datekostellatioe zu seie Arbeit effektiver als ach eiem besteheder Akzeptaztests mit i die zerbreche, wird für die Situatio, die dazu UAT-Feedback mehrere Woche. bei de Fachexperte, geht weiter mit der ikatioskette. ruge beschreibe, ist ei großes Thema Schätzug ei. Gibt es außerhalb des geführt hat, ei automatisierter Test Qualität des Aforderugsmaagemets Typische Schwachstelle i dieser Kette (vgl. [Wik-b]). I Qualitätsmodelle der Etwicklugsteams Iteressete für die geschriebe. Aschließed wird der Ma - bis hi zur Etwicklug, beihaltet aber sid die Schittstelle zwische Aforderugsmaagemet ud Etwicklug sowie pekt vo Software üblicherweise icht, weil Softwareetwickler fidet ma diese As- Akzeptaztest-Kriterie, erhalte diese gel ach voll ziehbar behobe ud mit dem Ei Fokus des UAT liegt auf der Istal - auch die Admiistratio im Betrieb ud wertvolles Feedback zu de Auswirkuge automatisierte Test dafür gesorgt, dass die lierbarkeit der Software. Diese lässt sich reicht schließlich bis zur Produktiosreife zwische Etwicklug ud Betrieb. Erstere solche Modelle eher das Softwareprodukt der Äderug. Köe Aforderuge ud so ge woee höhere Robustheit erhalte leicht i Kombiatio mit der obe der Software. Ist ei Glied i dieser Kette liegt begrüdet i eier Kommuikatiosbarriere zwische de fachliche ud de prozess i seier gaze Breite. Allerdigs fokussiere ud weiger de Etwicklugs- Akzeptaztests eiader icht zugeordet bleibt. beschriebee automatisierte Prüfug auf zu schwach, ka die fehlede Wartbarkeit werde, kommt das böse Erwache bei der Vollstädigkeit awede: We dieser zum Problem werde. Um Wartbarkeit zu techische Gedakewelte der Akteure wirkt sich magelde Qualität im Requiremets-Egieerig massiv auf das Produkt Etwicklug: Die Äderuge dauer füf Plädoyer für Nicht- Smoke-Test erfolgreich war, ließ sich die gewährleiste, muss also jeder Akteur zum (vgl. [CCC-g]). Letztere ist häufig ei orgaisatorisches Problem durch die Treug ud desse Qualität aus. Das wird deutlich, Miute, das Apasse der fehlgeschlagee alte Akzeptaztests zwei Tage. We die geforderte Fuktioalität imple- Ziel des UAT ist es, die Beutzbarkeit eier Automatisierug Software offebar erfolgreich istalliere. eie für sich alleie seie Keraufgabe effiziet ausführe köe, zum adere vo Etwicklug ud Betrieb i verschiedee Abteiluge. Dieses Problems hat sich vergleicht, die i verschiedee Phase der we ma die Behebugskoste für Fehler metiert wurde, also sämtliche automatisierte Tests durchgeführt ud um evetuell wisse wir, dass für eie erfolgreiche UAT Software zu prüfe. Aus eigeer Erfahrug muss aber auch die Kommuikatio zu de Mauelle Tests jeweilige Kommuikatiosparter reibugsarm fuktioiere. [Hüt12]), die sich für cross-fuktioale ter etdeckt wurde (siehe Tabelle 3). die DevOps-Bewegug ageomme (vgl. Etwicklug gemacht ud früher oder spä- Mauelle Tests sid auch i agile Pro - otwedige mauelle Tests der eue i alle Teststufe gewissehaft gearbeitet jekte wichtig. Sie schließe die Lücke zwische automatisierte Tests ud aufwädig weitere mauelle Stufe a. Schlimmeres als eie UAT, der vo de Features ergäzt wurde, schließt sich eie werde muss. Für Et wickler gibt ichts Die Rückverfolgbarkeit (Traceability) wird Teams eisetzt, d.h. Mixed Teams, die icht Beseitigugskoste vo Fehler im Requiremets-Egieerig köe leicht so hoch typischerweise auf Aforderuge ud ur aus Etwickler bestehe, soder oder gar icht automatisiert prüfbare Der User-Acceptace-Test (UAT) diet Tester oder vom Kude ach weige auf ihre Dokumetatio bezoge. Um Aforderuge effiziet zu verwalte, ist es (Operators) ud Aforderugsspezialiste beseitigt ud eie techische Schuld ud auch aus Admiistratore aus dem Betrieb werde, dass ma de Fehler gar icht mehr Aforderuge. Dabei köe mauelle dazu, eie Software uter reale Bedi gu - Miute abgebroche wird, weil viele offesichtliche Fehler i de vorherige Teststufe Tests zeitaufwädig ud fehlerafällig sei. ge zu teste ud zu prüfe, ob eie wichtig, die chroologische Äderug eier aus dem Requiremets-Egieerig. ihre Folgekoste i Kauf immt, die aber Auch i der agile Welt eige Projekt - Software effiziet ud effektiv geutzt werde ka. Software, die für Edaweder magelde Qualität bescheiigt wird. icht etdeckt wurde ud der Software Aforderug (vertikale Traceability) ud Ierhalb eies Teams ist eie gute Zusammearbeit icht automatisch gegebe. der Software wiederum höher werde kö- da währed eier lage Lebesdauer teams dazu, mauelle Tests zu verachlässige, we die Zeit am Ede eier gedacht ist, muss bei dieser Testart vom de Zusammehag zu adere Aforderuge im Kotext (horizotale Traceability) trasparet zu habe. Diese Quali- Teambildug ist ei komplexer Prozess. Um e als die Rückzahlug der Schuld. Soft- Beutzer selbst geprüft werde. Dazu ist es Last ud Performace-Tests otwedig, de fachliche Kotext der zu Die Teststufe Last- ud Performace-Tests tätseigeschaft Tipp 5: Pair-Testig lässt sich auf im UAT. de gesamte prüfede Soft ware zu kee ud eizu- diet im Wesetliche dazu, drei icht- Applikatios-Lebeszyklus User-Acceptace-Tests sollte dabei ausdehe, ie d.h. welche durch die Aforderug Softwareetwickler steht mit durchgeführt welche werde. UAT mit mittels welche Pair-Testig Tests, hat mit Codeabschitte, welcher sich Kompoete, dagege bewährt. mit Hier welcher führt ei Auslieferug, OBJEKTspektrum ist eie Fachpublikatio des Verlags: Beutzer mit welchem de UAT durch, Release-Kadidate der Etwickler SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf ud mit sitzt welcher daebe Fuktioalität ud bekommt direkt i wertvolles der Awedug Tel.: / Fax: / i Feedback Verbidug. zur Beutzbarkeit Fehleraalyse seier ifo@sigs-datacom.de ud -behebuge Arbeit. Im Idealfall werde ist dieser durch Tester diese der breite ud tiefe Form der Rückverfolgbarkeit Kude selbst oder ei Mitarbeiter mit tiefem fachliche Wisse, aber keie weitere Ketisse über de deutlich eifacher. Quellcode. 406/2015 /

5 Softwarequalität zum Afasse: Gibt es so etwas? ud bewusst durchgeführt werde. Dafür sid Qualitätstreiber otwedig. Auf der Suche ach Qualitätstreiber ladet ma schell beim Qualitätsmaagemet. Aber was sid Qualitätsmaager? Wer beauftragt sie? Ud woher wisse sie, was Qualität ist? Priorisierug ud Kokretisierug vo Qualitätsaspekte Abb. 4: Schrittweise Kokretisierug der Softwarequalität durch die Uterehmesleitug (blau), das Qualitätsmaagemet (grü) ud die Akteure der Umsetzug (gelb). Letztere sid typischerweise Aforderugsaalyste, Etwickler, Tester ud Admiistratore. warequalität begit also scho mit dem Begi des Applikatios-Lebeszyklusmaagemets ud damit weit vor der erste Implemetierug (vgl. auch [CCC-d]). I eiem gazheitliche Qualitätsmodell für Software, wie i Abbildug 3 gezeigt, darf dieser Teilaspekt vo Software deshalb icht fehle. jedoch icht aus, um Softwarequalität im Projekt ud Produkt spürbar werde zu lasse. QS muss zielgerichtet, koordiiert Äußere Rahmebediguge für die Qualitätspolitik eies Uterehmes bilde die Marktische, i der ei Uterehme agesiedelt ist. Durch eie sivolle Qualitätspolitik werde ierhalb dieses Rahmes strategische Qualitätsziele zur Leitliie aller Softwareetwicklug im Uterehme. Durch die Besetzug der Qualitätsmaagerrolle mit eier kokrete Perso wird der Qualitätsrahme weiter kokretisiert. Währed der Plaug, Lekug ud Umsetzug werde immer weitere Qualitätsetscheiduge getroffe (siehe Abbildug 4). Wie das Gaze kokret aussehe ka, zeigt Tabelle 4. Drei kokrete Uterehme aus verschiedee Marktische köte die i der Tabelle dargestellte Schritte wie beschriebe vollzoge habe. Adere Uterehme i diese Brache köte adere Prioritäte setze ud adere Kokretisierugswege gehe, z.b. i Qualitätssicherug ud -bewusstsei Uter Qualitätssicherug (QS) versteht ma oftmals so etwas wie eie Testabteilug. I diesem Artikel wird daruter die Summe sämtlicher Maßahme verstade, die zur Erreichug vo Softwarequalität beitrage. QS betreibt jeder veratwortugsvolle Akteur i seier jeweilige Rolle, der ei Qualitätsbewusstsei für seie Aufgabe hat. Das Zusammespiel aller dieser Maßahme ist da effektiv, we das Qualitätsbewusstsei aller Akteure sich a deselbe Rahmebediguge ausrichtet ud es eie Qualitätstreiber gibt, der die QS koordiiert ud Softwarequalität eifordert. Ei eiheitliches ud ituitiv verstädliches Qualitätsmodell stellt dabei eie wesetliche Grudlage dar, i dem alle Akteure ihr Qualitätsbewusstsei abbilde köe (siehe Abbildug 2 ud 3). Ei solches Qualitätsmodell allei selbst we es alle Akteure bewusst ist reicht 58 Tabelle 4: Beispiele, wie die schrittweise Kokretisierug vo Softwarequalität praktisch aussehe ka.

6 Qualitätsplaug ist jeer Teil des Qualitätsmaagemets, der auf das Festlege der Qualitätsziele ud der otwedige Ausführugsprozesse sowie der zugehörige Ressource zum Erreiche der Qualitätsziele gerichtet ist. Qualitätslekug ist jeer Teil des Qualitätsmaagemets, der auf die Erfüllug der Qualitätsaforderuge ausgerichtet ist [ ]. Er umfasst dabei Arbeitstechike ud Tätigkeite sowohl zur Überwachug eies Prozesses als auch zur Beseitigug vo Ursache icht zufriedestelleder Ergebisse. Qualitätsprüfug ist jeer Teil des Qualitätsmaagemets, der eie Koformitätsbewertug durch Beobachte, Beurteile, Messe ud Vergleiche vorimmt. Qualitätsdarlegug ist jeer Teil des Qualitätsmaagemets, der alle geplate ud systematische Tätigkeite des Qualitätsmaagemetsystems dokumetiert ud etsprechede Nachweise über ausgeführte Tätigkeite ud erzielte Ergebisse bereitstellt. Kaste 2: Defiitioe der Teilaspekte (Veratwortlichkeite, Aufgabe) vo Qualitätsmaagemet für Diestleistuge ach [Bru13]. Brache ud eiem spezielle Marktsektor mit eier bestimmte Absicht. Dieser Ivestitioskotext bildet de große Rahme für die Softwarequalität (siehe Abbildug 4). I diesem Rahme sid mit de Ivestitioe auch bestimmte strategische Ziele eier Orgaisatio/eies Uterehmes verbude, die de Qualitätsrahme weiter eischräke. Iitial liegt die Veratwortug, für Softwarequalität zu sorge, bei dem Kapitalveratwortliche, d. h. bei der Geschäftsführug eies Uterehmes, das die Software herstellt oder die Herstellug beauftragt. Diese iitiale Aufgabe besteht dari, sowohl allgemeie Qualitätsziele zu formuliere, die für de Erfolg des Uterehmes ud seier Ivestitioe als maßgeblich agesehe werde, als auch das Qualitätsmaagemet zu beauftrage, das da die Veratwortug als Qualitätstreiber überimmt. Mit der Auswahl der Qualitätsmaager ud mit ihre persöliche Präfereze schräkt sich der Rahme der Softwarequalität weiter ei (siehe Abbildug 4 ud Tabelle 3). Qualitätsmaagemet ud -steuerug Qualitätsmaagemet ist ei Regelkreis, ei Zyklus vo Veratwortlichkeite, der zu eiem Prozess stetiger Verbesserug führt. Im eifachste Fall besteht der Zyklus aus de drei Veratwortlichkeite/ Phase: Plaug, Umsetzug ud Kotrolle. Im Qualitätsmaagemet werde diese Qualitätsplaug, Qualitätslekug ud Qualitätsprüfug geat (siehe Abbildug 5 ud Kaste 2). Die Abgrezug der Teilaspekte ist icht immer eideutig, vor allem zwische Qualitätslekug ud Qualitätsprüfug. Durch wiederholte Prüfuge, überarbeitete Plauge ud achjustierte Lekug werde der Prozess des Qualitätsmaagemets selbst ud das Produkt, das dabei etsteht, immer weiter optimiert: Qualität wird geschaffe. Durch die Wahl ihrer Mittel treffe Qualitätsmaager Etscheiduge, setze Schwerpukte ud mache Vorgabe, die de Qualitätsrahme weiter eischräke ud kokretisiere (siehe Abbildug 4). Die Qualitätsmaager beauftrage da die Akteure der eigetliche Umsetzug ud gebe diese de erarbeitete Qualitätsrahme mit. We dieser Optimierugszyklus bewusst agewadt wird, ka die Qualität gezielt gesteuert werde. Steuerug heißt dabei icht, dass de Akteure der Umsetzug Vorgabe bis is kleiste Detail gemacht werde. Es geht darum, Akzete zu setze ud de Qualitätsrahme so eizuschräke, dass bei der Umsetzug eie Richtug eigeschlage wird, die zu de gesteckte Schritt 3 adere Veratwortliche beauftrage, die adere Schwerpukte setze, oder mehrere Qualitätsbeauftragte wie eie Projekt- ud eie Produktmaager eisetze. Veratwortug ka auch eiem gaze Team avertraut werde. Im Umfeld vo Agile ud DevOps wird dies durch die Schlagwörter cross-fuktioales Team, Team-based, Whole-Team oder Oe- Team-Approach deutlich. Qualitätsziele ud -treiber Ei Aspekt vo Qualität sid die dafür ötige Koste (siehe Defiitio 3 i Kaste 1 ud Abbildug 3). Derjeige, der das größte Iteresse a Qualität habe sollte, ist der Auftraggeber, der Geldgeber oder derjeige, der das ivestierte Kapital verwaltet ud dafür veratwortlich ist. Alle Ivestitioe werde i eiem bestimmte Kotext getätigt, d.h. i eier spezielle Abb. 5: Qualitätsmaagemet ist ei kotiuierlicher Verbesserugszyklus, mit dem die Uterehmesleitug ud die Akteure der Umsetzug regelmäßig iteragiere (siehe Kaste 2). 06/

7 Softwarequalität zum Afasse: Gibt es so etwas? Literatur & Liks [Bru13] M. Bruh, Qualitätsmaagemet für Diestleistuge, Spriger, 2013 [CCC-a] Clea Codig Cosmos, Was ist Softwarequalität?, siehe: [CCC-b] Clea Codig Cosmos, Produktqualität vs. Prozessqualität, siehe: [CCC-c] Clea Codig Cosmos, Iere ud äußere Qualität, siehe: [CCC-d] Clea Codig Cosmos, Das Applicatio Life Cycle Maagemet (ALM), siehe [CCC-e] Clea Codig Cosmos, siehe: Saubere Tests, siehe: [CCC-f] Clea Codig Cosmos, Sauberer Code, siehe: [CCC-g] Clea Codig Cosmos, Die Akteure im ALM, siehe: [CCC-h] Clea Codig Cosmos, Team Clea Codig, siehe: [CCC-i] Clea Codig Cosmos, Kudezufriedeheit, siehe: [Git] GitHub, Chaos Mokey, siehe: [Hüt12] M. Hütterma, DevOps für Developer, Apress, 2012 [Obe13] R. Oberrath, J. Vollmer, Clea Codig Cosmos: Teil 1 Kosmologie für Softwareetwickler, i: OBJEKTspektrum 6/2013, Kaste 4 [Obe14] R. Oberrath, J. Vollmer, Clea Codig Cosmos: Teil 3 Kosmische Effiziez durch Team Clea Codig, i: OBJEKTspektrum 2/2014, Kaste 4 [Wal11] E. Wallmüller, Software Quality Egieerig, Haser, 2011 [Wes12] R. Westphal, Clea Code Developer: Korrektheit als Wert, i: OBJEKTspektrum 5/2012 [Wes13-a] R. Westphal, Clea Code Developer: Teil 4 Produktioseffiziez als Wert, i: OBJEKTspektrum 2/2013 [Wes13-b] R. Westphal, Clea Code Developer: Teil 4 Produktioseffiziez als Wert, i: OBJEKTspektrum 2/2013 [Wik-a] Wikipedia, Softwarequalität, siehe: [Wik-b] Wikipedia, Aforderugsaalyse (Iformatik), siehe: [Wik-c] Wikipedia, Software testig, siehe: [Wik-d] Wikipedia, Behavior Drive Developmet, siehe: Ziele führt. Viele Details sid oftmals uötig oder es ist gar icht möglich, sie vorzugebe, weil sie zu techisch sid. Wie viele Details sivoll sid, müsse die Beteiligte im Eizelfall kläre. Je mehr Details vom Qualitätsmaagemet vorgegebe werde, desto größer ist das Risiko, dass Koflikte zwische Qualitätsmaagemet ud Akteure etstehe. Jeder erfahree Akteur hat i lagjähriger Arbeit Überzeuguge gewoe, die mit de Vorgabe des Qualitätsmaagemets kollidiere köe. Nicht erkate oder igorierte Koflikte stelle eie große Gefahr für die Softwarequalität dar. Effiziet ist das Qualitätsmaagemet da, we diese Art vo Koflikte klei gehalte wird sei es durch die Vermeidug vo Detailreichtum oder durch gute Kommuikatio ud Überzeugug. Qualitätsumsetzug ud -details Im Qualitätsrahme, de das Qualitätsmaagemet vorgibt, realisiere die Akteure der Umsetzug (Aforderugsaalyste, Etwickler, Architekte, Admiistratore, Tester) ihre Aufgabe. Sie erstelle Aforderuge, schreibe Quellcode, stelle Softwareistallatioe zur Verfügug ud teste diese. Bei diese Aufgabe müsse im Detail viele eizele Etscheiduge getroffe werde, die alle zusamme zur Softwarequalität beitrage (siehe Abbildug 5 ud Kaste 2). Qualitätsaspekte, die das Qualitätsmaagemet icht berücksichtigt habe, setze egagierte Akteure im Rahme ihres Spielraumes um. Ist der Spielraum dafür zu klei, köe sie dem Qualitätsmaagemet etsprechede Qualitätsziele vortrage ud Ressource dafür afrage. Qualitätsforderug ud Trasparez Das Qualitätsmaagemet ist die Middleware zwische Uterehmesleitug ud de Akteure der Umsetzug. Letztere stelle de Qualitätsmaager alle ötige Iformatioe zur Verfügug, damit die bisher erreichte Qualität ud die vorgeommee Maßahme im Rahme der Qualitätsprüfug (siehe Abbildug 5) beurteilt werde köe. Je höher der vorgegebee Detailierugsgrad des Qualitätsrahmes ist, desto schwieriger ka die Prüfug für die Qualitätsmaager werde ud desto uageehmer für die Akteure der Umsetzug, die sich dadurch überwacht fühle köe. Die Qualitätsmaager müsse im Rahme der Qualitätsdarlegug (siehe Abbildug 5) ihrerseits bei der Uterehmesleitug Recheschaft ablege. Dari lege sie de Erfolg ihrer Arbeit dar ud beötige dafür Iformatioe vo de Akteure der Umsetzug. Auf diese Weise werde die Auswirkuge aller Maßahme für die QS trasparet. Qualitätskoste oder -ivestitioe Qualität ist ichts, was automatisch oder eifach ebebei etsteht. Qualität kostet ud zwar i alle geate Ebee: 60

8 Die Akteure der Umsetzug müsse die Bedeutug vo techische Details für die Softwarequalität erkee lere ud ausreiched Zeit habe, sorgfältig zu arbeite. Außerdem beötige sie eie geeigete Ifrastruktur für ihre Arbeit (Hardware, Software, Räumlichkeite). Das Qualitätsmaagemet muss diese Ifrastruktur vo der Uterehmesleitug eiforder. Außerdem stellt die Arbeit der Qualitätsmaager selbst eie Qualitätsivestitio dar, die fiaziert werde muss. Ud schließlich kostet es die Uterehmesleitug Zeit ud Gedake, eie erfolgreiche Uterehmesstrategie auszuarbeite ud bewusste Qualitätsziele für das Qualitätsmaagemet zu formuliere. Was ist die Alterative zu diese Qualitätskoste? Etweder ei icht steuerbarer Wildwuchs a QS-Maßahme oder aber der Versuch, Software im Blidflug zu etwickel. Das Ergebis ist bei beide Alterative gleich: Es bleibt dem Zufall überlasse, ob, welche ud wie viel Qualität geschaffe wird. Tabelle 3 zeigt außerdem, dass we zu spät begoe wird, die Qualität zu kotrolliere ud zu verbesser die Koste uötig ud massiv ach obe getriebe werde köe. Vor diesem Hitergrud erscheit es sivoll, frühzeitig ud bewusst i Qualität zu ivestiere ud de dafür ötige Aufwad icht eifach als Koste, soder als Ivestitioe i lagfristige Qualität ud Erfolg zu betrachte. Schwergewichtigkeit ud Skalierbarkeit Abbildug 5 formalisiert de Prozess des Qualitätsmaagemets. Dadurch ka der Eidruck etstehe, dass Qualitätsmaagemet ei schwergewichtiges Bürokratiemoster sei muss, das viel Overhead erzeugt. Bei sehr große Projekte ist es bestimmt otwedig, diese Prozess mit eiem strege Formalismus durchzuführe. Der Grad dieses Formalismus ka sich aber a der Projektgröße orietiere. I Projekte mit ur sehr weige Akteure ka ei erfahrees Teammitglied, z.b. ei Seior Developer, Architekt oder Projektleiter die Aufgabe des Qualitätsmaagemets mit gewöhliche Stadard- Tools wahrehme. Diese Aufgabe kostet ih vielleicht 25 oder 50 Prozet seier gesamte Arbeitszeit. Bei größere Projekte muss eie Perso gefude werde, die überwieged als Qualitätsmaager arbeitet. I och größere Projekte muss etspreched mehr Mapower i das Qualitätsmaagemet ivestiert werde, bis sich vielleicht eie gaze Qualitätsabteilug mit spezialisierte Tools dieser Aufgabe widmet. Qualitätsmaagemet ka also durchaus auch leichtgewichtig durchgeführt ud skaliert werde. Fazit Zwei Dige mache Softwarequalität im Projektalltag (be-)greifbar: Erstes ei ituitiv verstädliches, gazheitliches Qualitätsmodell, das alle wesetliche Eigeschafte vo Software achvollziehbar strukturiert, sodass aus eier Flut vo Qualitätsmerkmale eie praxisahe Übersicht ud hilfreiche Checkliste etsteht. Zweites ei gezielter, eiheitlicher Qualitätssicherugsprozess, der alle Akteure miteischließt. Dieser Prozess begit bei der Uterehmesleitug mit der Formulierug strategischer Qualitätsziele, führt über das Qualitätsmaagemet (dem Zyklus vo kotiuierlicher Verbesserug) ud edet bei de Qualitätsdetails, die die ausführede Akteure realisiere. Bei diesem Qualitätssicherugsprozess hilft die Verwedug eies gazeiheitliche Qualitätsmodells. Es ermöglicht, alle Akteure i diesem Prozess azuspreche ud so zu eiem eiheitliche Qualitätsverstädis zu komme. Auf diese Weise wird Softwarequalität steuerbar ud dieser abstrakte, diffuse Begriff wird zu etwas, das sich im Projekt ud im Produkt afasse ud begreife lässt. Der Autor Dr. Reik Oberrath (R.Oberrath@iks-gmbh.com) ist als IT-Berater bei der IKS Gesellschaft für Iformatios- ud Kommuikatiossysteme tätig. I der Softwareetwicklug legt er große Wert auf Automatio, Kommuikatio sowie Verstädlichkeit vo Code ud Prozesse. Er ist Mitbegrüder der Kowledge Base Clea Codig Cosmos. 06/