Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und hier live auf der OOP 2024 in München. Was jetzt folgt ist ein Streitgespräch bei mir zu Gast Alex Lorz und Mike Sperber. Wir sprechen über funktionale Anforderungen und Qualitätsanforderungen an Architekturen und welchen Struggle die Architektursicht damit hat. Viel Spaß bei der Folge. Hallo Mike, hallo Alex, schön, dass ihr da seid. Danke, dass wir da sein können.
Ja, schön, dass wir dabei sind. Ja, finde ich super. Ich habe heute schon ein bisschen was gehört über euren Vortrag, der heute war. Ich habe schon eine, zwei Zuschauer auch interviewt dazu. Also mal kurz gefragt, ob es ihnen gefallen hat. Da waren alle ganz begeistert. Und ja, wir sind ja hier auf der OOP 2024 in München und der dritte Tag vom großen Mittelblock geht dem Ende zu. Ja, und ich freue mich, dass ihr da seid mit einem ganz spannenden Thema, wo wir ein bisschen tiefer
einsteigen. Ich habe einen Abstrakt gelesen und habe gerade beim Kunden so eine Diskussion gehabt, dass ich den gelesen habe. So, was ist eigentlich Qualität und was heißt das eigentlich? Und keiner kann es so richtig fassen. Was heißt gute oder nicht so gute? Und ja, und da kann man auch mal ein bisschen drauf einsteigen. Na ja, warum haben wir das Thema auf die Bühne gebracht?
Also du hast mich auf die Bühne gezerrt. Also Hintergrund ist, wir sind beide ISAQB-Trainer für die Softwarearchitektur Grundausbildung und wir sind auch in der Gruppe, die sich um das Curriculum kümmert, dabei. Und da gibt es so einen Abschnitt zur Qualität, den wir gerade versuchen zu überarbeiten. So kann man glaube ich sagen. Ich bin da so ein bisschen von außen dazu gekommen. Also ich habe vor ein paar Jahren auch angefangen, Softwarearchitektur zu unterrichten,
aber aus einer relativ speziellen Nische, aus der funktionalen Softwarearchitektur. Und unser Marketingchef hat uns irgendwann mal genötigt, auch diese Grundausbildung anzubieten. Und da habe ich so Kopfschmerzen gehabt, mich mit diesem Qualitätsthema auseinanderzusetzen, dass ich mir dann geschworen habe, entweder müssen wir irgendwie ganz grundsätzlich unsere Denkstrukturen ändern, um uns da anzupassen, oder wir müssen den Lehrplan ändern. Und im Moment sind
wir an der Stelle, wo wir den Lehrplan ändern. Oder vielleicht auch beides. Wir sind so im Annäherungsprozess. Also das Schöne, das Belohnende an der Arbeit im ISAQB ist ja, dass man einen Meinungsaustausch hinbekommt, dass man halt auch mal andere Perspektiven sieht. Und was ich an Mike sehr, sehr schätze, ist, dass er halt einfach einen dazu bringt, seine eigenen Perspektiven zu hinterfragen und ein Talent dafür hat, den Finger in offene Wunden zu legen und
manchmal auch mit diesen Wunden nicht sehr zärtlich umzugehen. Und gerade das Thema Qualität ist ein schwieriges in unserem Foundation-Level-Lehrplan. Das merke ich immer wieder, wenn ich Foundation-Level-Trainings gebe. Das ist im Lehrplan halt am Ende angesiedelt, was ein schlechter Platz ist. Das ist, glaube ich, einfach der Tatsache geschuldet, dass wir es zusammen mit Architekturbewertungen so in ein Kapitel gestopft haben. Eigentlich gehört es
am Anfang hin, weil es halt um Anforderungen geht. Und dann sind wir schon wieder bei dem leidigen Thema, was sind eigentlich Qualitätsanforderungen? Worin unterscheiden die sich von anderen Anforderungen, also funktionalen Anforderungen? Wie holt man Menschen mit diesem Thema ab? Was macht, legt, sorgt dafür, dass die mit Anforderungen so umgehen, dass sie später gute
Architekturentscheidungen treffen können? Und ich glaube, der Klassiker, was war denn der Klassiker, der dich so aufgeregt hat, an dem, was wir so machen?
Der Klassiker, der mich so aufgeregt hat, war erst mal, dass man überhaupt eine Unterscheidung trifft, also dass man denkt, dass es aus der architektonischen Sicht eine Unterscheidung gibt zwischen den funktionalen und den Qualitätseigenschaften, die so weit geht in manchen Teilen der Community, wie in dem schönen Buch von Clemens Kersman, die eben sagen, die funktionalen Eigenschaften sind eigentlich gar nicht so architekturrelevant. Und das überhaupt nicht zusammenpasst zu der Art,
wie wir Architektur machen. Ich glaube auch, wie die meisten Leute Architektur machen. Und ich auch nicht sehe, dass es fundamentale Unterschiede gibt, sozusagen in der Behandlung jetzt der funktionalen Anforderungen und der anderen Anforderungen. Aber ich habe inzwischen gelernt, insbesondere von Alex gelernt, dass es da eben andere Erfahrungshintergründe gibt und ich glaube auch andere architektonische Vorgehensweisen, die eben unsere Sichtweise auf dieses Thema prägen.
Ja, der Absatz in dem Kassnern-Buch, auf den sich Maik bezieht, den habe ich immer galant überlesen und habe mir gedacht, na ja, vielleicht haben sie es gar nicht so gemeint, aber Maik war da und meinte, ne, im restlichen Buch ist das genauso. Die sagen im Wesentlichen, halt, funktionale Anforderungen spielen keine große Rolle für den Architekturentwurf,
sondern halt nur Qualitätsanforderungen. Und was mir wichtig ist und vielen anderen Trainern in dieser KUB auch wichtig ist, ist halt auch ein Fokus auf das, was wir Qualitätsanforderungen nennen, zu legen, weil sie halt oft unterschätzt werden. Wir sind von vielen Stakeholdern, die sind einfach nicht auf dem Radar, die können keine Aussagen dazu treffen und aus meiner Erfahrung heraus, für eine Änderung an Qualitätsanforderungen haben wir einen sehr, sehr großen Impact.
Die betreffen sehr, sehr viele Komponenten und wir haben es, glaube ich, geschafft, diese Wahrnehmung von Qualitätsanforderungen ein bisschen zu erhöhen und darauf zu achten. Achtet darauf und dabei ist das Pendel so ein bisschen in die andere Richtung geschwungen. Und es ist auch schwierig, jemandem, der noch nicht viel Erfahrung, nicht viel Projekterfahrung hat, diesen Unterschied einfach zu erklären. Was verstehe ich unter funktionalen Anforderungen?
Was verstehe ich unter Qualitätsanforderungen? Weil diese Abgrenzung auch in der Literatur furchtbar unscharf ist. Also für einige Anforderungen kann man das klar sagen. Server soll Dollar in Euro umrechnen, ist eine Funktion, soll das in 10 Millisekunden tun, ist eine Qualitätseigenschaften dieser Funktion, aber dann solche Anforderungen, wenn das nicht in 10 Millisekunden passiert, dann tut das System irgendwas.
Ist das, da steht wieder eine Funktion dahinter, ist das jetzt eine funktionale Anforderung oder eine Qualitätsanforderung und spielt das überhaupt eine Rolle, darüber zu diskutieren? Ja, also das sind Indiz dafür, dass die Taxonomie als solche ein Problem hat. Und auch die Art, wie wir darüber reden. Ich glaube, wir haben alle die Erfahrung gemacht, dass, wenn wir das unterrichten, also meine Schüler*innen auf jeden Fall, mich immer entgeistert angucken.
Also ich kann das inzwischen in Perspektive setzen und sagen, ich versuche mal eine konsistente Perspektive zu präsentieren. Aber ein Problem ist eben, also ein Problem, an dem wir uns immer wieder stoßen, für Softwarequalität gibt es ja einen Standard mit so einer Standardtaxonomie, der ISO 25010, über den man natürlich auch reden muss in dem Kontext. Und der hat so eine obskure Spalte, die heißt Functional Suitability.
Und Alex ist irgendwie der Meinung, dass Functional Suitability sich nicht auf die funktionalen Anforderungen bezieht, sondern irgendwie was anderes ist. Und knurrt schon. Und ich würde halt immer sagen, also er darf gleich nochmal knurren und nochmal sein Knurren erläutern. Aber also ich würde erst mal anfangen und damit sagen, natürlich gehört die Funktionalität zu den Eigenschaften eines Systems. Es wäre total lächerlich davon zu reden, als wäre es das nicht.
Und wenn wir Qualität als Synonym für das Wort Eigenschaft betrachten, dann ist das erstmal einfach, also ist das naheliegend, das da eben nicht auszunehmen. Und die ISO 25010 hat eine lange Geschichte, die eben zurückgeht auch noch auf den Vorgängerstandard. Und da hieß diese Spalte einfach Functionality.
Ich habe mich auch mal mit jemandem aus dem Normungsgremium unterhalten und berichtet sozusagen, dass Leute sich immer wieder darüber streiten, sind die Funktionalen Anforderungen jetzt unter dieser Spalte angesiedelt oder irgendwie außerhalb. Und der sagte, natürlich sind die Funktionalen Anforderungen darunter angesiedelt. Aber das Wording, was beschreibt, was das ist, ist tatsächlich so verquast, dass man alles Mögliche da reininterpretiert.
Also offensichtlich setzt es Alex in die Lage, da was anderes reinzuinterpretieren als mich. Ja, was ganz deutlich anderes, dass so dieser Reibungspunkt, wo wir dann festgestellt haben, we agreed to disagree. Für Mike gehören die Funktionalen Anforderungen einfach darunter in diesem Kasten unter Functional Suitability.
Und meine Wahrnehmung davon ist einfach nur, die ISO 25010 ist ein Qualitätsmodell, das teilt einfach den Qualitätsbegriff auf in verschiedene Kästchen, wo man Sachen einsortieren kann. Und in dieser Functional Suitability ist halt einsortiert, wie gut passen die Funktionalen Anforderungen zu dem, was andere Stakeholder brauchen. Aber die Funktionalen Anforderungen sind selber nicht darunter. Weil das würde so ein Riesenkasten werden, wo so gefühlt 50 Prozent der Anforderungen drin sind.
Und da ist so eine Schieflage da in diesem Modell. Und für Mike, wenn ich dich richtig verstanden habe, bitte korrigiere mich, für dich ist selbstverständlich, ja klar, die Funktionalen Anforderungen sind in diesem Karton mit drin. Ich sehe da auch keinen Unterschied. Also der, den ich getroffen hatte aus dem ISO-Komitee, ich weiß leider nicht mehr, wie er hieß, kam tatsächlich aus der Testing-Community. Und der sagte eben, dass es natürlich, man im Testen eben natürlich erst mal wert...
Also am einfachsten ist natürlich zu testen, der Input und dann kommt der Output. Und man eben lange vernachlässigt hatte andere Qualitäten, also die schon wichtig sind, selbstverständlich, aber man andere Qualitäten vernachlässigt hat. Und darum, warum man sich eben engagiert hat, dass man eben in die Betrachtungsweise noch andere Sachen aufnimmt. Da ist ja auch nichts verkehrt mit. Nein, überhaupt nicht. Zumal ja... Ja, also da ist grundsätzlich nichts verkehrt mit.
Aber ich sehe eben aus meiner Erfahrung her, weder in der Art, wie das bei den Anforderungen aufschlägt, sehe ich einen wesentlichen Unterschied zwischen funktionalen und nicht-funktionalen Sachen. Also natürlich sieht man den Unterschied zwischen Performance und Usability und da, da, da, da. Aber so diesen pauschalen Unterschied sehe ich nicht. Also ich sehe, dass bei den Funktionalen Anforderungen genauso geschlampt wird wie bei den anderen Sachen, dass man da nicht alles erfährt.
Ich sehe, dass in schlechten Architekturen es natürlich dazu führt, dass kleinere Änderungen an den Funktionalen Anforderungen zu größeren Änderungen führen, genauso wie das eben bei den anderen Sachen auch so ist. Also ich sehe einfach, und genauso wenig sehe ich einen Unterschied in den grundsätzlichen Taktiken. Zumal ja viele Qualitätsanforderungen oder einige Qualitätsanforderungen typischerweise auch durch Funktionalität umgesetzt werden.
Jetzt im Bereich Usability oder Security wären so die Klassiker, dass so ein Passwortdialog erscheint oder dass man einen Screenreader hat. Das sind eben einfach neue Funktionalitäten. Und darum denke ich, also jetzt können wir uns ganz lange darüber streiten, ist das Funktional oder nicht Funktional. Also es hilft ja, Sachen durchaus zu klassifizieren, um da zu gucken, welche Taktiken wir wählen. Aber dafür brauchen wir eh was Feingranulares.
Also es gibt ja jetzt nicht eine Taktik, die zuständig ist nur für, also die pauschal zuständig ist für Qualitätsanforderungen. Das macht irgendwie alles gar keinen Sinn. Wo ich dir 100% zustimmen kann, ist die Tatsache, dass Qualitätsanforderungen irgendwann mal auf funktionale Bausteine runtergebrochen werden oder auf querschnittliche Konzepte runtergebrochen werden, was im Endeffekt ein anderer Name dafür ist. Es gibt einen großen Baustein, der sich darum kümmert und von dem viele abhängen.
Und das je nachdem, aus welcher Industrie Menschen kommen, also so Automotive und Automatisierungstechnik, die sind in aller Regel recht happy mit ihren funktionalen Anforderungen. Die haben in aller Regel auch ziemlich gute Qualitätsanforderungen, weil die da eingeschrunken sind. Die bauen in aller Regel safetyrelevante Systeme. Da ist das vom Kunden ziemlich hart vorgegeben. Da ist das gut ausbalanciert.
Für andere, die halt so Informationssysteme bauen, die reden mit ihren Kunden über Funktion. Die reden mit denen, was macht das System, welche Prozesse unterstützt das System und reden oft zu selten darüber, wie gut das System bestimmte Dinge machen soll, wie gut Entwicklungs- oder Deploymentprozesse sein sollen, Recoverability und dergleichen.
Und aus dieser Perspektive ergibt es Sinn, diese Dinge auseinanderzusortieren, um einfach zu sagen, das sind üblicherweise eure Anforderungen, die ihr gut auf dem Radar habt. Das sind die, die sicherlich möglicherweise unter eurem Radar fliegen, die aber gefährlich sind, weil sie euch später viele Risiken reinbringen, viele Schmerzen bereiten können. Aus dieser Perspektive ist diese Unterscheidung hilfreich. Die hilft mir, Architekturentscheidungen zu treffen.
In der Umsetzung später ist mir das egal, ob da funktional oder qualität oder nicht funktional dran steht. Das sind Anforderungen wie jeder andere auch. Aber das gibt halt die Taxonomie von Anforderungen einfach noch nicht her. Also entspricht überhaupt nicht meiner Erfahrung. Also ich sehe eher das Problem, dass jetzt, also ich muss echt auf, ich habe echt Probleme mit diesem Begriff Qualitätsanforderungen. Ich zucke jedes Mal zusammen, also wer genau hinguckt, sieht das vielleicht auch.
Aber vielleicht können wir mal rausnehmen, die sozusagen quantitativen Qualitäten, die man messen kann, sowas wie Performance, was man jetzt nochmal unterteilen kann und Sachen, an die man typischerweise eben Zahlen dran kleben kann. Jetzt kann ich ja hingehen und sagen, also ich sehe durchaus, dass Leute das auf dem Schirm haben.
Und wenn ich jetzt ja ganz gemein bin, dann sage ich, pass mal auf, du musst durch die gesamte ISO 25010 Taxonomie durchgehen und du musst bitte an jedes Ding irgendwas dran kleben. Und was ich eher sehe, also das sehe ich manchmal, dass Leute eben sagen, okay, wir müssen irgendwie was dran kleben, aber irgendeine Zahl aus dem Hut ziehen. Also man denkt, ja, das System soll irgendwie schnell sein. Was heißt das genau?
Also, oder andersrum gesagt, dass man vielleicht gar nicht eine Zahl aus dem Hut zieht, aber eine Zahl, bei der man überhaupt nicht genau vorhersehen kann, wie sich das nachher einpendeln, wenn es darum geht. Mein System soll vielleicht schnell sein, aber ich weiß noch vorher noch gar nicht, wie viele Benutzer es nachher vielleicht gleichzeitig haben wird oder solche Sachen.
Und dann schreiben Leute Zahlen da dran, die nachher problematisch sind, weil sie möglicherweise eben auch im Konflikt mit anderen Anforderungen oder anderen Randbedingungen eben der Softwareentwicklung laufen. Und man hat sie aber nicht in ihren Kontext gesetzt. Also es ist irgendeine Zahl da.
Man hat sie nicht in den Kontext gesetzt des konkreten Projekts, nicht mit den anderen Randbedingungen abgeglichen, so dass man in Situationen rutscht, das habe ich schon mehrmals erlebt, wo es unmöglich war, die numerischen Anforderungen, also die quantitativen Anforderungen an verschiedene Maße, die da waren, eben zu erfüllen.
Und da, meiner Meinung nach, ist es eher, also hätte ich mir eher gewünscht, dass die Leute, also natürlich einerseits vielleicht dran kleben, hier, ich habe mir irgendeine Zahl ausgedacht. Andererseits ist es ja häufig aber auch sinnvoll, dass man einfach sagt, pass mal auf, ich weiß vielleicht noch gar nicht, was die Zahl ist, aber schneller ist besser. Manchmal ist es ja auch langsamer besser. Das ist halt dieses Fantifizieren, das ist so eingeübt.
Genau, da wir ja eh in der Regel, also bei diesen quantitativen Geschichten, ja nicht wirklich sagen, pass mal auf, wir machen diese, also vorher, nicht sagt, wir machen diese und jene Sachen im Design und dann haben wir 20 Millisekunden Antwortzeit.
So läuft es ja nicht, sondern was wir in der Regel machen, ist, wir wenden so lange Maßnahmen an, bis wir glücklich sind, also entweder ein festes Ziel erreicht ist und dann ist vielleicht gar nicht, also für diesen Prozess wäre es gar nicht notwendig, dass man ganz am Anfang des Prozesses gesagt hat, bei welcher Zahl man hinten rauskommt. Du weißt am Anfang halt nicht, was gut genug ist. Der Kunde hat keine Vorstellung davon und klebt dann halt eine Zahl ran.
Oder manche Ingenieure lehnen sich so weit aus dem Fenster und sagen, ach, wir wollen das ein bisschen sportlich machen und kleben eine Zahl ran, die sie überhaupt nicht erfüllen können in dem Budget, was sie haben, um halt eine Zahl dastehen zu haben, wo gar kein Business Case dahintersteht. Warum reichen mir nicht 200 Millisekunden? Warum brauche ich 20 Millisekunden?
Also gibt es ja natürlich auch, nicht, dass man denkt, so der Airbag, das ist ja auch nicht so, dass wir erst mal in einer Sekunde anfangen und dann so lange... Einige sind halt super hart, einige sind eher soft. Ein Problem, was da eine Rolle spielt, ist halt, einige Qualitäten zu messen, oder den Wert der Erfüllung dieser Qualität zu messen, wo sich die ISO so "degree of which" so ein bisschen rummauscht, darum, wie viel man das messen kann oder soll.
Für einige ist es halt einfach, Responszeit, Anzahl Request pro Sekunde oder so, das ist super einfach. Für einige ist es echt hart, Security, da eine Zahl ranzukleben. Man kann das vielleicht manuell scrollen oder dergleichen, Usability. Usability 5, was heißt das denn? Aber man kann ja sagen, mir ist klar, dem Stakeholder ist Usability sehr, sehr wichtig.
Und das ist auch eine wichtige Information für jemanden, der eine Architektur designed, ohne dass dort eine Zahl drankleben muss, und obwohl es keine Definition of Done gibt, was ein Risiko ist, dann weiß ich, hey, hier habe ich was, wo ich mit dem Kunden noch mal reden muss, wo ich ständig nachfragen muss, ist das gut genug oder nicht, das ist ein Risiko, das kann Geld kosten, das muss dem Kunden auch klar sein, das muss dem Management klar sein.
Auch das ist ein wichtiger Indikator und ist dann immer noch ein wichtiger Treiber für meine Architekturentscheidung, auch wenn es nicht quantifiziert ist.
Das ist spannend, das ist ja euer Blick quasi da drauf, diese 25010 ist ja für uns Tester ja die heilige Bibel, also es war vorher die 9126, jetzt haben wir die, und da gibt es diese Qualitätskriterien, so nennen wir es quasi, also eben, oder Qualitätsmerkmale, also die Qualitätsanforderungen kenne ich jetzt in dem Kontext gar nicht so den Begriff.
Und wenn ich da jetzt auch das IST-Copy, das ja sehr Testern nahe natürlich ist und quasi die Standardzertifizierung für Tester ist, da wird auch immer wieder gesagt, ja, da ist so viel Fokus gelegt auf Funktionalität und diese anderen, ja, die muss man halt auch machen, aber da wenden sich viele davor.
Und dann haben wir oft das Problem in der Praxis, dass da steht halt, es muss schön sein oder es muss schnell sein, und dann will man als Tester natürlich wissen, was heißt denn das jetzt, wie schnell? Und dann gibt es ja zwei Wege, entweder man schreibt irgendwas hin oder man misst es und schaut, ob man damit zufrieden ist. Und das ist ja für uns immer so ein ganz wichtiger Aspekt, mit diesen Kriterien da auch zu spielen.
Genau, aber auch da ist es ja manchmal, also kann man sich ja zumindest vorstellen, ich bin jetzt kein Tester, aber dass es manchmal ausreichend ist zu sehen, dass sich die Dinge in die richtige Richtung bewegen.
Also klassischerweise sieht man das ja beispielsweise in der evolutionären Softwarearchitektur, ist jetzt nicht direkt, aber wo man ja gerade auf bestimmte Eigenschaften der Architektur testet und jetzt auch nicht sagt, ich will jetzt hier auf, also man hat ein willkürliches Maß und man sagt jetzt auch nicht, ich will auf 5, sondern man sagt nur, ich möchte nicht schlechter oder ich möchte idealerweise besser werden. Und dann ist das schon mal gut.
Also ich glaube auch, das merkt man gerade so in letzter Zeit, dass so diese Trendentwicklung total mehr zunimmt. Also was früher so wirklich eine Zahl hätte sein müssen, dass man da ja, dass man sagt, okay, der Test guckt doch drauf, einfach werden die Sachen besser oder bleiben zumindest gleich. Das quantifizieren ist einfach zu teuer.
Der Kunde möchte keine Usability-Studie bezahlen, hatte ich in einem praktischen Projekt tatsächlich, obwohl Usability einer der wichtigsten Treiber für seine Business Cases war. Und das ist ein Aspekt. Der andere Problem, was die Bibel halt hat, bei manchen Qualitätseigenschaften, Qualitätsattributen, gibt es endlose Diskussionen, in welches Kapitel der Bibel die gehören. Also immer bei solchen Sachen wie Antwortzeiten. Das kann ein Usability-Ding sein, kann aber auch ein Performance-Ding sein.
Und dann diskutieren sich die Leute, Köpfe wunden, eine halbe Stunde lang, wo es denn hingehört. Dabei ist die Diskussion völlig sinnlos. Ja, genau. Ihr habt euch ja quasi über den Lehrplan ja da rangehört. Das war ja für euch quasi der Reibungspunkt. Habt ihr das denn im Lehrplan, das jetzt soweit auch für euch? Also wir haben morgen ein Meeting. Wir wollen. Also ich glaube, wir kriegen das hin. Ist das wirklich durch alle Aspekte, also das spielt ja auch eine Rolle, nicht nur im Lehrplan.
Also das ist ja der Grundlagenlehrplan, sondern Prüfungsaufgaben bauen darauf auf und so. Da wird noch einiges folgen müssen. Die Rippeleffekte von dem Lehrplan sind halt so groß. Der Blasredios, da hängen Prüfungsaufgaben dran, es hängen die Foliensätze der verschiedenen Trainingsanbieter mit dran. Es hängen Publikationen dran, worauf verwiesen wird. Deswegen hat sich dem Thema noch keiner so richtig angenommen.
Wie gesagt, Qualität hängt bei uns in einem Kapitel zusammen mit Architekturbewertung, weil halt irgendjemand mal gedacht hat, das passt gut zusammen, das ist eine gute Idee. Und es ist tatsächlich auch in der Umsetzung des Lehrplans, Lehrmaterial in diesem roten Faden, ein echtes Problem. Weil halt viele Trainer lösen das auf die Art und Weise, die packen das dorthin, wo es ihnen passt.
Weil die wissen genau, der Lehrplan ist halt eine Empfehlung, was drin sein soll, eine Inhaltsangabe, quantifiziert so ein bisschen, Lernziele. Aber es gibt auch Trainingsanbieter, die das halt sehr wörtlich nehmen. Das Ding hat vier Kapitel, also haben wir in unserem Projekt vier große Hauptkapitel.
Und ich hatte auch schon Diskussionen mit Trainingsanbietern, die sagen, der Foliensatz, den die Isar-Gubé als Referenz rausgibt, der passt doch gar nicht zum Lehrplan, das ist doch in einer anderen Reihenfolge da drin als im Lehrplan. Leute, da spielt überhaupt keine Rolle die Reihenfolge von dem Lehrplan, sondern die Inhalte, ihr habt einen akkreditierten Foliensatz. Aber wir können das nicht unseren Kunden verkaufen.
Also es gibt operationelle Aspekte, die das Rechtfertigen, diesen Offern vorzunehmen. Das hat bisher keiner gemacht, weil so viele Änderungen hinten kamen. Da hat sich keiner herangetraut. Ja, also das kann ich verstehen. Man macht das im IST-Gubé auch. Wir haben gerade den Foundation Level 4 rausgebracht. Da ist ja auch ganz viel passiert in Richtung Agilität reinzukommen. Und da hängt halt viel dran, die Prüfungsfragen, ein schönes Schwestermodell.
Da finde ich schön, dass andere auch damit zu tun haben. Da ist halt keiner happy mit großen strukturellen Änderungen. So hier mal was von einem in ein anderes Lernziel verlegen, etwas kleines Wording ändern, ist alles okay. Aber eine große strukturelle Änderung bedeutet, viele Referenzen haben zu denen. Also ihr habt ja morgen das Meeting. Wir wissen ja jetzt nicht, was da rauskommt. Aber habt ihr für euch so eine Idee, wie ihr das gefasst bekommt? Ich glaube schon.
Also ich denke, man muss halt, vielleicht das ist jetzt kein geheimes Meeting. Aber es ist ja auch nach diesem Programm, bis der rauskommt. Genau, aber also wen das wirklich inhaltlich interessiert, dann der Lehrplan ist einfach auf GitHub. Nicht nur der Lehrplan selbst ist öffentlich verfügbar, sondern die Entwicklung findet eben auf GitHub statt. Und auch die Sachen, die zur Qualität finden, auch viel Diskussion dazu findet in Form von GitHub. Dafür gibt es einfach nur einen Pull-Request.
Sehr schön. Auch ein Aufruf an die Community. Ihr könnt alle gerne zum Lehrplan beitragen. Aber bitte, wenn ihr sagt, das und das soll noch in den Lehrplan rein, dann sagt uns doch bitte, was wir rausnehmen können. Weil wir haben nur drei Tage für dieses Training. Also wer sich, und das ist auch bei diesem Thema schon passiert, also das war sozusagen, das war ein wesentlicher Teil der Arbeit daran, war eben möglichst breite Teile der Community auch in der Diskussion zu beteiligen.
Also jetzt primär aus dem Verein und sozusagen unmittelbarer Nachbarschaft. Das ISA Kobe, das glaube ich, haben wir jetzt so einigermaßen durch. Also ich glaube wichtig ist es einfach, also vorhin war es schön im Vortrag, dass jemand sagte, ich bin mal zu einem Quality-Storming gegangen. Und dann haben sich alle gefragt, darf ich da jetzt auch über Funktionalität reden? Ja. Und ich glaube, man muss halt den Begriff mindestens kontextualisieren.
Und ich glaube, es ist halt sinnvoll, also wir wissen alle, dass es sinnvoll ist oder sinnvoll sein kann, Sachen einzuordnen, was eben die Eigenschaften und auch die Anforderungen an diese Eigenschaften betrifft. Aber also entweder muss man irgendwie dazu sagen, was man meint. Oder man muss eben sagen, ich habe hier Performance-Eigenschaften und ich habe Usability-Eigenschaften und ich habe Anforderungen an die Usability.
Und da glaube ich, ist der wirkliche Wert zumindest aus der Sicht der Software-Architektur. Also ich habe mich gefragt, also das kann ja für andere Communities anders aussehen. Also der IRAP beispielsweise macht auch diese klare Unterscheidung zwischen den funktionalen und nicht funktionalen Sachen. Ich weiß nicht, ob aus Sicht des Requirements-Engineerings man grundsätzlich andere Methodik anwendet. Aber ich glaube, Fakt ist, wir haben irgendwie Kopfschmerzen.
Also eigentlich mit einer kleinen und blöden Frage verbringen wir viel Zeit, um das zu reden. Die Uhr, die sich die Zeit entschläumt. Das bedeutet halt irgendwie, wir können uns nicht einfach hinstellen und so tun, als wäre alles klar. Und das wäre wichtig, glaube ich, für Leute, die eben darüber reden, dass man eben sagt, pass mal auf.
Also wenn du sagst, ich mache ein Quality-Storming und das ist ja heute ja allen klar, wir reden über die Qualitätsdinger, dann sollte man vielleicht sagen, mit oder ohne Funktionalität. Und genauso eben in vielen anderen Kontexten auch. Wichtig fände ich auch eben diesen Aspekt, da findet sich bei uns auch noch ein paar Prüfungsfragen.
Also gerade diese Sichtweise, dass eben die Qualitätseigenschaften, die nicht die Funktionalität betreffen, ich muss aufpassen, bei Alex darf man nicht nicht-funktionale Anforderungen sagen. Das darfst du gerne, aber viele Leute sagen das. Oder im Verein ist das verbunden. Und dass die eben architektonisch relevanter sind als die anderen. Also dass primär Sachen, die nicht die Funktionalität sind, die Architektur treiben sollten. Also ich glaube, erst mal ist es wirklich einfach Quatsch.
Also wir sollten, also ich denke, fast jede Architektur entsteht erst mal von der zunächst mal, zumindest im ersten Wurf, von der Funktionalität her. Und ich glaube, worauf wir uns halt, also es gibt so zwei Sichtweisen auf Architektur.
Also die eine ist eigentlich geprägt durch David Parnas schon, also vor 50 Jahren, mehr als 50 Jahren jetzt, der eben gesagt hat, pass mal auf, also der so alles, was wir an Grundterminologie im Bereich Softwarearchitektur heute kennen, eben schon damals eben geprägt hat.
Und von dem gibt es eben so ein sehr richtungsweisendes Paper, in dem er sagt, pass mal auf, deine Modularisierung, also das Hauptteil der Architektur, des Architekturentwurfs, sollte so sein, dass jedes Modul eine Entscheidung versteckt. Also sprich, dich in die Lage versetzt, diese Entscheidung später zu ändern. Also das war damals so die Idee von Parnas.
Und wenn man heute vielen Softwarearchitekt*innen und Kurifäen auf diesem Gebiet zuhört, dann sagen die, nee, also Softwarearchitektur ist, die wichtigen Entscheidungen richtig zu treffen. Und dahinter steht die implizite Annahme, dass man sie nicht ändern kann. Und das ist ja so, ich finde, also ich würde sagen, das ist so die kollektive Kapitulation vor dem Problem.
Und jetzt können wir entweder sagen als Software, also ich glaube, vielleicht gibt es einfach zwei verschiedene Sorten von Softwarearchitekt*innen. Die einen, die sagen, wir müssen die wichtigen Entscheidungen richtig treffen. Und die anderen, die sagen, du solltest, wenn möglich, überhaupt gar keine wichtigen Entscheidungen richtig, also unverrückbar treffen. Sondern du solltest halt deine Software so machen, dass du sie später ändern kannst.
Und das sinnvollerweise sollte ja nicht nur betreffen funktionale Eigenschaften. Also wir können jetzt trefflich darüber streiten, ob funktionale Änderungen an den funktionalen Anforderungen typischerweise nur lokale Änderungen nach sich ziehen. Auch das hängt von der Architektur ab.
Und es gibt jede Menge schlechte Architekturen, in denen es, also, in denen mehrere Fachabteilungen und die Datenbankadministrat*innen und was weiß ich dann irgendwie für jedes kleine Fitzelchen Funktionalität irgendwie nochmal durch irgendeinen Reifen springen müssen. Und genau so ist das bei den anderen Sachen auch.
Und wir sollten darauf achten, insbesondere, also ich sehe ein bisschen ein kleines Risiko an dieser Unterscheidung, dass man eben sagt, naja, also das mit der Funktionalität ist ja alles ganz einfach. Und bei den anderen Sachen ist es aber so schwierig, dass wir unsere Softwarearchitektur gar nicht so bauen können, dass wir Änderungen oder überhaupt, dass wir uns gewahr werden bestimmter Anforderungen im nicht-funktionalen Bereich, dass das irgendwie total schwierig ist.
Sondern wir sollten sehen, dass wir über alle Qualitäten, Funktionalität und die anderen Qualitäten, dafür sorgen, dass wir architektonische Konzepte finden, die uns in die Lage versetzen, auf Änderungen in Anforderungen reagieren zu können, indem wir möglichst kleine, möglichst wenig, möglichst schnell, möglichst billige Änderungen eben an unsere Architektur machen. Die entscheidende Frage ist ja, wie wir das ohne Overengineering am Anfang klappen.
Wir wissen halt noch nicht, was unsere wichtigen Entscheidungen sein werden. Da darf ich einmal sagen, dass es vielleicht auch so ein bisschen der Hintergrund ist. Wir kommen ja aus sehr unterschiedlichen, also was auch die Softwarearchitektur bekommt, kommen wir aus unterschiedlichen Communities. Und also ich komme eben aus der funktionalen Architektur und Alex kommt zum Beispiel aus der netorientierten Architektur.
Wir sind sehr hardware-nah aufgewachsen, geprägt worden, dann in die objektorientierte Schiene reingekommen. Und funktionale Architektur ist halt was, was mir unheimlich schwerfällt. Aber das Schöne an der funktionalen Architektur, also ein wesentlicher architektonischer Aspekt eben an funktionaler Architektur ist, dass so der Standardmodus, in dem man sie entwickelt, schon dafür sorgt, dass es sehr wenig Kopplung gibt.
Also ungefähr eine Größenordnung weniger Kopplung macht als typische objektorientierte Architektur. Und das kann man jetzt natürlich ein bisschen auffächern. Warum ist das so? Hat mit Zustand zu tun. Und das führt aber glaube ich dazu, dass die Architekturen, mit denen wir dann zu tun haben, tendenziell flexibler reagieren auf Änderungen in den Anforderungen.
Und es insbesondere eben auch erleichtern, also wenn wir uns vorstellen, also wir hatten das vorhin im Vortrag erwähnt, dass natürlich, also da sind wir vielleicht wieder beieinander häufig. Also auf jeden Fall ist es in vielen Projekten ja so, dass die Funktionalität früh im Fokus ist. Und man danach vielleicht die ersten Strukturentscheidungen trifft dabei.
Und man dann aber, also ich meine viele Taktiken, gerade in Bezug auf diese quantitativen Sachen, ja eben die Form haben, ich nehme ein existierendes System und ich ändere das. Und ich versuche, die entsprechenden Eigenschaften zu verbessern. Und das heißt, alles, was wir tun können, um unsere Software einfacher zu ändern, erst mal sozusagen da besser passt auf diese typische Art, wie eben der Software-Lebenszyklus funktioniert.
Und darum machen wir eben was, was eigentlich total illegal ist, so im Isako-B-Modell. Also wir sind entschieden in dem Camp, dass wir anfangen mit der Funktionalität. Also das beziehungsweise, also geschuldet der Tatsache, dass die typischerweise zuerst im Fokus ist. Und wir versuchen aber, unsere Software so flexibel zu halten, dass wir eben weitere Anforderungen, die dann eben an andere Aspekte der Software kommen, die dann eben kommen könnten, die wir später auch noch befriedigen können.
Dann, wenn sie im Fokus sind. Wobei ich lernen musste, dass es an dieser Änderbarkeit über alles, in Anführungszeichen, halt auch so ein paar gelogenen Sternchen dran gibt. Weil für einige ist das überhaupt nicht wichtig. Halt, A, Wartbarkeit, Änderbarkeit ist in aller Regel ein Tradeoff zu Performance. Wenn ich halt eine hohe Performance oder auch eine hohe Effizienz haben möchte, dann muss ich Sachen enger koppeln, muss ich Sachen komplizierter auf eine bestimmte Hardware koppeln.
Für einige meiner Schulungsteilnehmer spielt Wartbarkeit, Änderbarkeit auch keine Rolle. Die kommen aus einem Safety-Umfeld. Die wollen das Ding nur einmal deployen und dann soll das safe laufen. Das wird nie wieder geändert in den nächsten 10 Jahren. Naja, aber ich fürchte, das ist halt so ein bisschen Stockholmsyndrom und H&I-Problem. Also viele Systeme werden nicht geändert, weil sie schwer zu ändern sind. Oder weil man sie nicht ändern muss.
Aber das ist eine Sache, die sich in Zukunft ändern wird, auch im Embedded-Umfeld, im Safety-relevanten Umfeld. Wenn halt immer, was sind denn Ändernde, was sind denn Treiber von Änderungen? Funktionale Erweiterung wollen die eigentlich nicht machen. Aber sich ändernde Umgebungsbedingungen hatten die bisher nicht, weil ihre Systeme waren isoliert vom Rest der Welt. Die wurden halt irgendwo mal geflasht.
Und wenn sie Glück hatten, musste halt der Fahrzeughersteller keinen Rückruf machen, wenn sie gut genug waren. Aber das wird sich ja auch ändern. Die meisten Geräte werden in Zukunft Internetverbindung haben. Die werden an neuen Angriffssektoren ausgesetzt sein. Und das heißt auch, dort rechne ich damit, dass zumindest ein Umdenken eins ist. Und die Prioritäten sich nicht umkehren, aber etwas verschieben.
Dass sich leichtere Wartbarkeit, leichtere Änderbarkeit, und sei es auch nur um schnellere Produktzyklen oder dergleichen hinzubringen, das ist auch oft ein Treiber für Wartbarkeit, Änderbarkeit, auch in der Welt von Unternehmen, die Safety-relevante Produkte herstellen. Also ich möchte noch mal ganz kurz, wenn ich noch mal darf, widersprechen auf der Tatsache, dass immer eine Performanceverbesserung einhergeht mit einer Verschlechterung der Wartbarkeit oder einer Verschlechterung der Kopplung.
Also in vielen Umfällen ist meine Erfahrung das Gegenteil der Fall. Also klassisches Beispiel wäre eben, wenn ich viel Enterprise-Software, also klassische Enterprise-Software ist wahnsinnig eng an die Datenbank gekoppelt. Und das Phänomen, was man eben typischerweise sieht, ist, man hat das Datenbank-Schema designed für die Anfragen von heute. Und jetzt ändern sich die Anforderungen, funktionale Anforderungen vielleicht. Das wäre so ein schönes Beispiel.
Also jetzt ändern sich die funktionalen Anforderungen und das Schema ist nicht mehr in der Lage, die neuen funktionalen Anforderungen auf eine befriedigende Art zu erfüllen. Und wenn ich da nicht entkoppelt habe von vornherein, also jetzt fährt das alles wieder zurück, dann kann ich es nicht mehr ändern. Also theoretisch wäre es natürlich möglich, ein eng gekoppeltes System zu erzeugen, was meine Anfragen effizient eben beantwortet.
Aber das Problem ist, ich habe ein existierendes System, was das nicht kann und ich kann es nicht ändern. Und darum ist meine Wette, meine persönliche Wette, immer da drauf, dass man sehen sollte, also da Software auch in der Regel länger lebt, als man gerne hätte, dass man dafür sorgt, dass sie geändert werden kann. Also auch wenn das Business sagt, nee, also wir haben ja geschätzte Kollegen, die dann sagen so, good enough architecture, lass mal fünfe gerade sein und so.
Und ich gehöre nicht zu diesem Club. Das ist eine super spannende Diskussion. Ich bin da schon ein bisschen mit der Zeit am Schein, aber ich glaube, wir müssen mal einen zweiten Teil machen. Ich fand jetzt nochmal auch spannend, sich generell mal Gedanken zu machen. Auch so ein Trade-off, gibt es einen? Und wenn ja, wie sieht der aus? Also ich glaube, das macht man sich oft auch gar nicht gewahr, dass es da Abhängigkeiten geben kann. Das fand ich jetzt nochmal ganz spannend.
Und ja, super, vielen lieben Dank für diese Einsichten in eurem Blick auf Qualität aus der Architekturseite. Ich glaube, da können viele aus meiner Tester-Community, wenn ich so mitdenke, da total viel mitnehmen an Idee und Inspiration auch für den Umgang im Team. Das finde ich ganz toll. Ja, vielen Dank, dass ihr da wart. Wir werden sicher mal eine andere Folge machen, das kann ich jetzt schon unterschreiben.
Ich wünsche euch heute noch einen schönen Resttag von der OOP und freue mich aufs nächste Mal. Dankeschön. Ebenfalls. Vielen Dank. Danke. SWR 2021