Nun kommen wir zu den inneren Qualitätsmerkmalen,
zwei von den acht sind noch übrig geblieben,
für den acht aus der Norm 25.000.
Und das ist zunächst erstmal die Wartbarkeit Maintainability. Maintainability ist
ein ganz wesentliches Kriterium, was besonders im Fokus des Software-Engineering steht.
Bei Software-Engineering geht es immer darum, dass wir Veränderungen brauchen.
Und diese Veränderungen spielen hier eine ganz wichtige Rolle,
nämlich es geht hier um das Multifizieren.
Also dieses to be modified,
das spielt hier eine
ganz große Rolle
Und deswegen ist es wichtig, mal zu überlegen,
welche, was kann sich denn da alles ändern?
Und das sind drei große Gruppen von Änderungen, die wir hier haben.
Ich schreibe die hier oben mal mit dran. Das hatten
wir ganz zu Anfang in dieser Lehrveranstaltung schon mal besprochen.
Das sind vor allen Dingen Corrections. Dann Improvements. Und
das dritte passt nur hier daneben Adaptations
Also es geht darum, Fehler zu korrigieren. Es geht
darum, Verbesserungen zum Beispiel von Qualitätseigenschaften wie Performance oder sowas
zu machen und Anpassungen angeänderte Bedingungen.
Alle drei Kategorien kann man so ganz grob ungefähr erwarten,
dass sie im gleichen Umfang passieren.
Also keinesfalls irgendwie nur besonders viele Fehlerbehebungen oder so.
Die besonderen Merkmale, die eine Software aufweisen soll,
für Wartbarkeit für den geringeren Aufwand, für Veränderungen.
Also hier steht nochmal das dabei, mit dem Aufwand,
das ist bei Efficiency dabei.
Ja, also hier Aufwand Nutzenverhältnis, das schreiben wir uns
vielleicht auch nochmal mit dran
Es geht um das Aufwand Nutzenverhältnis hier und bei Effektivenes,
dass ich es überhaupt machen kann.
Tatsächlich gibt es Situationen, wo eine bestimmte Änderung nicht durchführbar ist.
Und zwar nicht etwa, weil ich den Code nicht eingeben kann.
Das sind ja nur Zeichen. Nein,
weil ich die Änderung nicht stabil bekomme, gerade bei alten Systemen,
wo wir dann ganz häufig Fehler haben,
die dann Folgefehler sind und das ganze System ist so stabil
So wird so instabil, dass sich die Änderungen nicht mehr
umsetzen kann, obwohl ich es eigentlich müsste.
Ja, also solche, gerade so Adaptations, Anpassungen angesetzt,
geänderte, gesetzliche Rahmenbedingungen sind ja ein ganz wichtiger Punkt.
Lassen Sie uns die Untermerkmale durchgehen. Zunächst erstmal steht hier
in der Norm Modularität. Das war in der vorgehenden Norm nicht der Fall,
aber das ist ein wichtiges Gründe, wichtige Grundvoraussetzung,
dass der Aufwand gering bleibt, weil wir wollen,
dass eine Veränderung sich nicht auswirkt.
Also hier geht es um diesen Impact
Also wir wollen lose Kopplung erreichen. Das ist das,
was dieses Merkmal fordert. Lose Kopplung ist ein Qualitätsmerkmal,
was Wartbarkeit verbessert. Der nächste Punkt Wiederverwendbarkeit,
dass es einen Wert darstellt, dass wir eine einmal getroffene,
gemachte Leistung mehrfach einsetzen können. Das hilft uns auch immer,
wenn wir Korrekturen haben, die eine Korrektur zum Beispiel,
wir haben ein Sicherheitsproblem mit einer Software und wir setzen die drei Male ein,
dann brauchen wir es nicht dreimal zu beheben,
wenn es wiederverwendet worden ist,
sondern brauchen es nur einmal zu machen
Analysierbarkeit, da steckt jetzt das erste Mal dieser Aufwand drin,
nämlich Impact, Assess the Impact of a Change und so weiter.
Da echnos defficiencies, courses of failors,
identify parts of to be modified.
Das würde ich mal sagen, hier der Aufwand für das Erkennen.
Modifieability ist dann der Aufwand für das Ändern
Also für das Durchführen von einer Änderung und Testbarkeit
ist der Aufwand für das Testen.
Während das Ganze eben hier dann der Aufwand für eine Änderung
Und der Aufwand für die Änderung setzt sich zusammen aus den Teilaufwänden.
Ich muss erst mal erkennen und verstehen, worum es geht.
Ich muss die Änderung tatsächlich durchführen und ich muss die Änderung auch durch den Test absichern.
Ja, nur noch mal, das sind tatsächlich unterschiedliche Ziele,
in denen ich für dich unterschiedliche Maßnahmen machen kann.
Zum Beispiel eine klare Struktur, einfache Struktur. Das hilft mir
beim Erkennen und Verstehen, wo die Ursache eines Problems liegt.
Wenn wir lose Kopplungen haben und kleine Elemente und Information Hiding,
dann werden sie Änderungen nicht überhin ausbreiten.
Wir müssen nur wenige Sachen ändern. Das wäre fürs Durchführen. Ja,
und wenn der Test unterstützt wird, dadurch,
dass wir kleine Module haben, ohne große Abhängigkeiten, ohne Abhängigkeiten zu externen Sachen.
Ich muss nicht für einen Test aus einer Datenbank aufsetzen oder sowas,
dann ist der Aufwand für das Testen geringer.
Das ist eines der acht Qualitätskriterien und das,
worum sich Software-Engineering, Softwaretechnik am meisten kümmert.
Wir haben als letztes Kriterium in dieser Reihe das achte noch eins,
was ist sehr ähnlich zu dem vorgehenden Portierbarkeit, Übertragbarkeit.
Hier geht es darum, dass wir etwas übertragen können,
Ken Be Transfert, from One Hardware, to another environment.
Es geht immer um die Umgebung. Also wenn wir ein,
wer etwas haben, das läuft mit der und der Klassenbibliothek,
wir müssen aber aus irgendwelchen Gründen wechseln in eine andere.
Wie hoch ist denn der Aufwand dafür? Oder wie hoch ist der Aufwand,
eine App, die ich einmal geschrieben habe,
in eine andere Umgebung zu bringen,
zum Beispiel zur nächsten Version dieses Betriebssystems der App oder gar zu einer konkurrierenden,
also sie wollen etwas von iOS,
was für ein Mac geschrieben, für Apple geschrieben ist,
auf Antroid bringen.
Das wäre eine solche Veränderung. Die Maßnahmen, die wir
machen, es ist ja auch eine Änderung von Software.
Insofern ist es sehr ähnlich zu dem, was wir vorgehen,
Voragenten, auf der vorgehenden Seite hatten.
Hier geht es drum und den Aufwand für das Anpassen an anderer oder sich weiterentwickelnde Hardware,
Software, um das tatsächliche Installieren, also ich will es da draufbringen,
ins Tor oder ein Installed und etwas austauschen,
wenn ich eins wieder entferne durch etwas anderes ersetze,
was für einen Aufwand ist dafür notwendig.
Diese, das sind jetzt die acht Qualitätskriterien, die in der Norm stehen.
Ich springe mal zurück zu der Seite, als wo die ganzen Normen standen.
Also das, was wir bis jetzt hatten,
diese acht Sachen, das ist alles die Produktqualität.
Merkmale der Produktqualität, die Definitionen, das ist das,
was wir hier gerade haben. Sie sollen in der Lage
sein, das auch anwenden zu können und das anwenden.
Dann werden wir später nochmal haben, wenn wir Checklisten aufstellen
für Reviews, Inspektionen, später in diesem Kapitel
Und wir wollen es jetzt auch mal dafür wenden,
dass wir gemeinsam mal überlegen,
für welche Art von Systemen sind denn, welche Qualitätsmerkmale besonders wichtig?
Das könnte man im Prinzip für jedes machen.
Ich habe hier mal für diese vier das gemacht.
Wir machen jetzt so eine Art kleine Tabelle zusammen.
Ich fange mal an mit Benutzbarkeit. Für welche Systeme sind es denn
für die Benutzbarkeit wichtiger, ein wichtigeres Kriterium sind als andere Kriterien?
Das wären zum Beispiel Systeme, die in öffentlicher Nutzung sind.
Ich schreibe mal drüber, Kategorie von Systemen,
wo eine hohe Priorität besteht für dieses Merkmal und machen wir
hinten noch eine Spalte, Beispiel für ein System oder Produkt
Ja, also bei Nutzbarkeit wären, es ist zum Beispiel
besonders wichtig bei Systemen, die in der öffentlichen Nutzung stehen.
Systeme für öffentliche Nutzung durch jedermann. Also wenn wir am Bahnhof ein System haben zur,
wo man Last-Minute noch gucken kann,
ob in diesem Urlaubsort ein Zimmer frei ist,
dann muss das bitte so bedienbar sein,
dass das wirklich 95 Prozent der Bevölkerung auch bedienen können.
Und Sie können nicht da ein 500-seitiges Handbuch noch daneben eine
Kette hängen oder ich muss immer dazu auf die Hilfefunktion gehen,
um rauszuwissen, wie kann ich das, nein,
das soll bitte intuitiv bedienbar sein.
Ein weiteres Beispiel ist hier,
ich mache das mal hier mit grün,
wäre etwas,
wo ich ein Ticket kaufen soll,
Die Automaten der Deutschen Bahn waren jahrelang sprichwörtliches Beispiel für schlechte Benutzbarkeit.
Ja, oder an meiner früheren Universität war das Bibliothekssystem schlecht benutzbar.
Hier ist das zum Glück etwas besser. Ja,
soweit zu einem Beispiel für Benutzbarkeit. Wir machen mal
hier oben eine Linie, dass man hier besser sieht,
dass es sich um eine Tabelle handelt.
Und hier und hier auch noch. Und jetzt kommt die
nächste Kategorie. Wird das so langsam in der Tabelle hier.
Korrektheit, Funktionalität, Funktionalereignung. Das ist besonders wichtig
bei Systemen, die ein hohes Risiko tragen
Systeme mit oben, Risiko, bei, nein,
das war hier schon falsch, bei Fehlverhalten.
Ja, zum Beispiel Gefahr für Menschenleben Gesundheit oder so etwas.
Hier möchte ich nehmen, zum Beispiel,
dass wir so ein Bordcomputer der Steuerungsfunktion hat im Flugzeug nehmen.
Ich wechsle ja wieder auf grün. Wortcomputer im Flugzeug
wäre ein Beispiel oder eine automatische Bremsvorrichtung
Bei der Bahn könnt ihr hier noch etwas sein. Ja,
für Performance ist alles das wichtig, wo wir Systeme haben mit hohen Verantwortungen an Daten, Verarbeitung.
Zum Beispiel mit Massendatenverarbeitung Oder auch Systeme, wo Ressourcen, besonders knapp sind. Wenn wir etwas haben,
was über viele Jahre ohne Stromversorgung funktionieren soll,
und das kriegt deswegen eine Solararantrieb, Solarzelle als Energielieferant,
weil es irgendwo ganz einzeln steht an der Straße,
mit dem Verkehr zu zählen oder irgendwas anderes,
dann müssen wir besonders darauf achten,
dass es mit den knappen Ressourcen gut umgeht.
Und das wäre hier auch gleich mal ein Beispiel. Ein autonomer Sensor,
zum Beispiel für Wetter oder für Verkehr oder irgend sowas,
der irgendwo in der Landschaft ist, ohne Energieversorgung,
da relativ wenig hat oder etwas haben, wenn wir etwas haben,
wo wir zum Beispiel was im Weltraum schicken oder sowas,
wo es nur wenig Batterieleistung gibt.
Massendatenverarbeitung wäre natürlich auch was, wenn wir irgendwie was haben,
was im Weihnachtsverkehr den Postversand da steuern soll, unterstützen sollte.
Wenn wir richtig ganz viel haben, zehnmal sehen,
viel, viel unnundermal zu viele Ereignisse wie sonst.
Ja, und als letztes Beispiel,
als letztes Beispiel möchte ich etwas zu Wartbarkeit sagen.
Da geht es ja um Veränderungen.
Das sind also besonders für Systeme mit häufigen Änderungen
Und sowas wäre zum Beispiel etwas, was mit Gesetze
sich häufig ändert und gesetzlichen Bedingungen zu tun hat.
Da nehme ich mal ein System zur Berechnung von Sozialabgaben.
Die Regelung für die Sozialversicherung, die ändern sich scheinbar jedes Jahr,
an da hat man immer zu tun,
dass man fürs nächste Jahr die Änderungen noch reinkriegt und solche Systeme sind sehr darauf vorbereitet,
dass man das immer gut machen kann.
Das ist ein Beispiel und Und das zweite, was mir auch noch angeben müssten,
wären Systeme, wo wir eine lange Nutzungsdauer erwarten müssen.
Man könnte das Wort Lebenserwartung noch mit dran schreiben.
Ich mache das auch mal in Anführungszeichen, weil die Software natürlich nicht lebt.
Und das wäre so ein System, was ein Kerngeschäftsprozessumfeld Ja,
also geschäftskritische Systeme sind häufig so, dass sie relativ lange, lange leben.
So, soweit haben wir ein paar Beispiele für Systeme,
für Klassen von Systemen, Kategorien von Systemen, wo einzelne Merkmale besonders wichtig sind. Wichtig ist auch,
dass es uns gelingt, vom Auftraggeber die Prioritäten kennenzulernen,
weil wenn wir nur erst fragen, welche von den Qualitätszielen ist denn wichtig,
dann wird er zunächst, dass wir sagen, ja,
alle, aber es sind doch wenn wir dann sagen,
ja, mit dem,
worauf willst du denn das Geld dann ausgeben?
Alle kostet einen auch entsprechend mehr, dann wird schon klar,
dass es einige Merkmale wichtiger sind als andere.
So, damit sind wir soweit erstmal durch als nächsten Abschnitt
, kommen wir zur Produktqualität