Kompe­tenz

Quali­täts­merk­male

Für die Beur­teilung der Quali­tät von Soft­ware gibt es Quali­täts­merk­male. Die Quali­täts­manage­ment­norm ISO 25010 macht Vor­schläge für die Kate­gori­sie­rung von Quali­täts­merk­malen. Eine voll­stän­dige und kor­rekte Pro­dukt­doku­men­tation ist bereits ein nicht zu unter­schätzen­des Quali­täts­merk­mal einer Soft­ware in Bezug auf die Kate­gorie Wart­bar­keit. Mit anderen Worten unter­stützt ein Wiki mit Bau­steinen der Methode cards+ die Erfüllung von Quali­täts­merk­malen der Kate­gorien Funktio­nali­tät und Wart­bar­keit.

Mit dem Bau­stein Decision begrün­det der Pro­dukt­verant­wort­liche oder Ver­tre­ter des Teams eine wichtige Ent­schei­dungen, die große Aus­wir­kung auf die Soft­ware hat oder den Lösungs­raum ein­schränkt. Jede Ent­schei­dung wird min­destens einem Quali­täts­merk­mal zuge­ordnet, mit einer Begrün­dung, die erklärt, warum sie für dieses Quali­täts­merk­mal rele­vant ist. In der Pro­dukt­doku­men­tation gibt es zu jedem Quali­täts­merk­mal mindes­tens eine Ent­scheidung oder ein Kon­zept mit einer Aus­sage, wie und in welchem Umfang das Quali­täts­merk­mal in der Soft­ware umge­setzt wurde.

Mit dem Bau­stein Spec doku­men­tieren Ent­wickler über­grei­fende oder wieder­holt einge­setzte Kon­zepte, die u.a. sicher­stellen, dass eine Soft­ware bestimmte Quali­täts­merk­male auf­weist.

Bitte hier Klicken, um das Fallbeispiel anzuzeigen

Wartbarkeit

Analysierbarkeit

Die Decision Begriffe der Domäne im Code sorgt dafür, dass sich eine gemein­same Sprache aus den Begriffen der Domäne ent­wickeln kann. Les­barer Code ist das Ziel.

Die Decision Pro­gram­mier­sprache für Indi­vidual­entwick­lung legt eine Stan­dard­pro­grammier­sprache fest. Eine Abwei­chung muss gut begrün­det sein und darf nicht aus einer “Laune heraus passieren”.

Gemäß Spec Event-basierte Mess­punkte kann jeder Dienst zur Lauf­zeit soge­nannte Mess­punkte in beson­dere Situa­tionen erzeu­gen. Ein Mess­punkt ist ein­deutig identi­fizier­bar, doku­men­tiert Zeit­punkt und Zuord­nung zu einem Dienst, beschreibt die Situa­tion (z.B. ein Daten­satz kann nicht ver­arbei­tet werden) und ent­hält alle Daten, die für eine spätere die Ana­lyse not­wendig sind.

Modularität

Der gewählte Archi­tektur­stil pipes and filters basiert auf folgenden Grund­kon­zepten für Dienste:

Es gibt zwei Lösungs­ansätze für Schnitt­stel­len von Diensten:

Modifizierbarkeit

Die Decision Ver­sions­ver­wal­tung in Git legt eine nach­voll­zieh­bare Stra­tegie für die Versio­nierung der Code-Basis fest.

Die Decision Continuous Inte­gration mit Git legt den Grund­stein für hohe Code-Quali­tät.

Prüfbarkeit

Die Decision Werk­zeug für Android-UI-Tests legt den Grund­stein für auto­mati­sier­bare Test­aus­füh­rung für die Android-App.

Die Decision Werk­zeug für Schnitt­stel­len­tests legt den Grund­stein für auto­mati­sier­bare Test­aus­füh­rung für Dienste.

Die Decision Werk­zeug für Sys­tem­tests legt den Grund­stein für auto­mati­sier­bare Test­aus­füh­rung für das IT-System.

Stabilität

Apache Kafka ist eine Platt­form für ein sehr gut skalier­bares ver­teil­tes IT-Systems mit einer event-basier­ten Daten­ver­arbei­tung nahezu in Echt­zeit. Der Einsatz von Apache Kafka als Platt­form für messaging hat sich im Labor­ver­such bewährt.

Apache Cassandra ist ein Ver­tre­ter der spalte­norien­tier­ten Daten­banken, der sich bei gro­ßen Daten­mengen mit hoher Skalier­bar­keit anbie­tet. Der Einsatz von Apache Cassandra als ver­teilte Daten­bank hat sich im Labor­ver­such bewährt.

Der Ein­satz von Spring Boot als Grund­gerüst für jeden Dienst sorgt für ein ein­heit­liches und nach­voll­zieh­bares Ver­halten bei der Daten­ver­arbeitung.

Der Ein­satz von Apache Kafka Streams ermög­licht eine leicht­gewichtige Lösung für streaming ohne Abhängig­keiten zu anderen Diensten.

Mit diesem Vor­gehen kehrt der Pro­dukt­verant­wort­liche die weit ver­breitete Praxis um, nicht funk­tionale Aspekte wie Fähig­keiten anzu­for­dern. Quali­täts­merk­male werden nicht ein­fach program­miert. Sie sind Eigen­schaf­ten einer Soft­ware, die durch die Wahl des Archi­tektur­stils, durch den Ein­satz bestimm­ter Infra­struk­tur oder Anwen­dung bestimm­ter Entwurfs­muster ent­stehen. Quali­täts­merk­male beein­flussen sich gegen­seitig. Häufig »zerren« sie von zwei Seiten, d.h. stärkt man ein Quali­täts­merk­mal, schwächt man ein anderes. In einem verteilten IT-System kann bei­spiels­weise die Opti­mierung des Zeit­ver­hal­tens bei der Daten­ver­arbeitung die Ana­lysier­bar­keit bein­trächti­gen. Das CAP-Theo­rem ist ein weiteres Bei­spiel für dieses Dilemma.

Das CAP-Theo­rem oder Brewers Theo­rem besagt, dass es in einem ver­teil­ten System unmög­lich ist, gleich­zeitig die drei Eigen­schaf­ten Konsis­tenz (engl. consistency), Verfüg­bar­keit (engl. availability) und Aus­fall­tole­ranz (engl. partition tolerance) zu garan­tieren.

Ein weiterer nicht zu unter­schätzen­der Vor­teil ist der Über­blick zu jedem einzel­nen Quali­täts­merk­mal, der sich aus der Verknüpfung der Bau­steine Decision und Spec mit dem Quali­täts­merk­mal ableiten läßt. Diese kom­pakte Zusammen­stellung von Ent­scheidungen und Kon­zepten zu einem Thema zeigt Abhängig­keiten, die sonst nicht so leicht erkenn­bar sind.


Defi­nition

Welche Kate­gorien von Quali­täts­merk­malen gibt es?

Benutz­bar­keit

Benutz­bar­keit (engl. usabi­lity) ist die Fähig­keit der Soft­ware, Standards, Konven­tionen, Stil­vorg­aben (engl. style guides) oder Vor­schrif­ten bezo­gen auf die Benutz­bar­keit einzu­halten. Benutz­bar­keit ist eng verwandt mit dem Begriff Ge­brauchs­taug­lich­keit, der Eig­nung eines Pro­duk­tes, die von Nutzern ange­streb­ten Ziele effek­tiv, effi­zient und zufrie­den­stellend zu errei­chen.

Effi­zienz

Effi­zienz (engl. efficiency, performance) ist das Ver­hält­nis zwischen dem Leistungs­niveau der Soft­ware und dem Umfang der einge­setzten Betriebs­mittel unter fest­geleg­ten Bedingun­gen. Effi­zienz wird in der Praxis oft­mals verein­facht als Leistungs­fähig­keit (engl. perfor­mance) bezeich­net, mit den Aspek­ten Verar­bei­tungs­geschwin­dig­keit, Ant­wort­zeit, Durch­satz, Speicher­bedarf oder Mengen­gerüste.

Funktio­nali­tät

Funktio­nali­tät (engl. functio­nality, func­tional suita­bility) ist das Vor­handen­sein von Funk­tionen mit ange­forder­ten Eigen­schaften. Funktio­nale Soft­ware besitzt einen ange­messe­nen Umfang und ist ord­nungs­gemäß reali­siert. Da aber ein Soft­ware-Test nur die Anwesen­heit, aber nicht die voll­stän­dige Abwesen­heit von Fehlern zeigen kann, ist eine fehler­freie Soft­ware eher als nie erreich­bares Ziel zu sehen.

Kompa­tibili­tät

Kompa­tibili­tät (engl. compati­bility), auch Inter­opera­bili­tät, kenn­zeich­net die Fähig­keit der Soft­ware von min­destens zwei IT-Systemen, Daten unter­ein­ander auszu­tau­schen, diese Daten kor­rekt zu inter­pre­tieren und zu verar­bei­ten. Bei Kompa­tibili­tät im Sinne von Ko­exis­tenz geht es vor allem darum, dass die Soft­ware nur jene Ressour­cen ver­braucht, die ihr zuge­wiesen werden.

Porta­bili­tät

Porta­bili­tät (engl. porta­bility) ist die Eig­nung der Soft­ware, von der Umge­bung in eine andere über­tragen werden zu können. Daraus lei­tet sich der Anspruch ab, dass Soft­ware leicht instal­lier­bar und Kompo­nenten der Soft­ware leicht aus­tausch­bar sind. Porta­bili­tät ist eine Voraus­setzung für die Auto­ati­sierung der Instal­lation von Soft­ware.

Sicher­heit

Sicher­heit (engl. secu­rity) ist ein Sammel­begriff für alle Fähig­keiten einer Soft­ware, die not­wendig sind, um Daten und das IT-System so zu schützen, dass beab­sich­tigte Zugriffe erkannt und uner­laubte Zugriffe abge­wehrt werden. Das bein­haltet den Nach­weis von manu­ellen Ein­griffen (engl. auditing).

Wart­bar­keit

Wart­bar­keit (engl. main­taina­bility) ist ein Sammel­begriff für Ände­rungen mit dem Ziel, Korrek­turen, Ver­besse­rungen oder Anpassun­gen an der Soft­ware für neue Anfor­derungen oder geän­der­ten Quali­täts­merk­malen durchzu­füh­ren. Eine Soft­ware gilt als wart­bar bzw. gut änder­bar, wenn der Auf­wand für die Durch­führung von Ände­rungen gering ist.

Zuver­lässig­keit

Zuver­lässig­keit (engl. relia­bility) ist die Fähig­keit der Soft­ware, ihr Leistungs­niveau unter fest­geleg­ten Bedingun­gen über einen fest­geleg­ten Zeit­raum zu bewah­ren. Über Ver­füg­bar­keit erfolgt die Fest­legung, inwie­weit eine Anwen­dung rund um die Uhr ver­füg­bar ist. Weitere Merk­male sind die Wieder­her­stell­bar­keit und die Fehler­toleranz eines IT-Systems.


Diszi­plin

Quali­täts­manage­ment

Steuerungs­maß­nahmen für den Ent­wicklungs­prozess, wie sie in der Quali­täts­manage­ment­norm ISO 9001 von einer Organi­sation gefordert werden, sind nur mit genauer Kennt­nis der Ent­wick­lungs­erge­bnisse mög­lich. Der Ein­satz von cards+ und dem damit ver­bundenen Vor­haben, eine ange­messene und mit der ent­wickel­ten Soft­ware wachsende Pro­dukt­doku­men­tation zu erstel­len und zu pflegen, eröff­net eine Reihe von Mög­lich­keiten zur Veri­fizierung der Ent­wicklungs­ergeb­nisse. Eine wesent­liche Eigen­schaft von cards+ ist die fixe Struk­tur im Wiki, mit Bau­steinen, Prinzi­pien und Prak­tiken, die opti­mal auf­einander abge­stimmt sind.

Der Bau­stein Topic hilft, den Umfang (engl. scope) eines IT-Systems fest­zule­gen und klare Gren­zen für die Ent­wick­lung zu zie­hen. Alle Topics zusammen beschrei­ben den Pro­jekt­auf­trag, über­setzt in die Sprache des Pro­duk­tes.

Der Bau­stein Case wird ver­wendet, um eine Fähi­gkeit des IT-Systems zu beschrei­ben. Mit dem Bau­stein Epic werden eng ver­wandte Fähig­keiten zu einer kom­pletten Funktio­nali­tät zusam­men­gefasst. In der Sprache der Norm sind das die Ent­wicklungs­ein­gaben. Eine Soft­ware, die »fertig« ist, hat für jeden Case eine Lösung oder eine Begrün­dung, warum eine Lösung nicht mög­lich oder not­wendig ist. Auf dieser Grund­lage kann der Pro­dukt­verant­wort­liche sehr gut beur­teilen, ob alle Ent­wick­lungs­einga­ben bei der Reali­sierung vom Team berück­sich­tigt wurden.

Das Testen einer Soft­ware hat nicht die voll­stän­dige Prüfung aller Fähig­keiten zum Ziel. Das wird in der IT-Branche heut­zutage als unmög­liches Vor­haben einge­schätzt. Eine Metrik wie die Test­abdeckung durch Modul-, Schnitt­stellen- und System­tests ver­setzt den Pro­dukt­verant­wort­lichen in die Lage, Quali­täts­ziele für die Ent­wick­lung zu defi­nie­ren. Der Ein­satz von cards+ lässt ihn auch beim System­test eine Quali­täts­ziel defi­nieren. Jeder Case in der System­beschrei­bung mit einer Lösung muss durch mindes­tens einen Test­fall im System­test abge­sichert werden. So ist der Beweis erbracht, dass die Soft­ware min­destens alle in der Pro­dukt­doku­men­tation erfassten Fähig­keiten besitzt.