Episode 219 Der heimliche Treiber moderner Software-Architekturen, Herzlich willkommen beim Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Am Mikrofon ist wieder Björn Schorre. Als Systemingenieur gebe ich dir Tipps und Impulse, damit du dein Projekt zum Erfolg führen kannst. Music. So wirst du in der Episode heute erfahren, warum braucht es für Embedded Software eine Software-Architektur?
Und ich gehe darauf ein, was sind die Treiber für die Entwicklung einer Architektur? Herzlich willkommen hier bei mir im Podcast. Ich habe heute einen besonderen Gast da, der im Rahmen der Softwareentwicklung unterwegs ist und das seit fast 30 Jahren und zwar für Embedded Software Engineering, sagt er, ist er tätig. Seit den letzten zehn Jahren dann halt als Softwarearchitekt, wirft da die Software und die Strukturen, die notwendig sind und das macht er vorwiegend in agilen Projekten.
Von Anfang an ist er selbstständig und ja, in diesem Sinne herzlich willkommen hier bei mir im Podcast, Alexander Eisenhut. Hallo. Hallo Björn, vielen Dank für die Einladung. Ich freue mich hier zu sein. Ja, du, wir haben uns getroffen, wir haben uns ausgetauscht über so eine Gruppe von Selbstständigen. Und ja, weil du dann gesagt hast, du machst Softwarearchitektur, habe ich gesagt, komm doch zu mir in den Podcast.
Weil ich nämlich dieses Thema Softwarearchitektur natürlich auch bei mir in den Teams, die Systeme entwickeln, immer wieder antreffe. Du machst also Software-Architektur und wir haben uns ein bisschen darüber ausgetauscht, wozu braucht es überhaupt eine Software-Architektur? Was wäre da so deine Aussage? Also du brauchst die Software-Architektur, damit du die Qualitäten in der Software und auch im System bekommst.
Und jetzt, was sind Qualitäten? Ich glaube, das kannst du im Rahmen deines Systemengineering sehr gut sagen, sind eben diese nicht funktionellen Anforderungen. In der Software wird das auch gerne als Qualitätsziele genannt. Oder wie heißt das in deinem Wording? Ja, also wir sprechen von nicht-funktionalen Anforderungen oder auch Qualitätsanforderungen. Das ist so die Begriffswelt, die auch vom IREP, dem International Requirements Engineering Board, vorgeschlagen wird, vorgegeben wird.
Ja, und diese Qualitäten oder Qualitätsziele, die werden ja an verschiedenen Stellen umgekehrt niedergeschrieben. So diese DIN ISO 25010 gibt da ja einfach einen schönen Überblick. In der Bahntechnik heißen sie einfach RAMs. Das ist Reliability, Availability, Maintainability und Safety. Und heutzutage haben sich auch noch andere Qualitätsmodelle herausgebildet, sage ich mal. Da ist Q42 ganz neu bestattet, dass das ein bisschen in einem weiteren Kontext darstellt, nämlich das involvierte.
Die Stakeholder auch, was die für verschiedene... Qualitätsanforderungen an das System haben und darum kümmert sich die Software-Architektur. Okay, jetzt hast du ja gerade schon zwei Standards, also Q42, das müsstest du mir noch ein bisschen erklären. Aber die ISO 25010, die hat natürlich so Aspekte da drin wie Übertragbarkeit, wie Wartbarkeit eines Systems, die Beschreibung von Effizienzen und Zuverlässigkeit. Das sind so Themen, die in der ISO 25010 aufgegriffen werden.
Worin unterscheidet sich da jetzt das Q42? Q42 kommt aus der Ecke, wo auch ARC 42, das Dokumentationsmodell für Softwarearchitektur, herkommt. Ist also von stark initiiert und greift natürlich die gleichen qualitätsziele wie diese 25 nur zehn auf haben dann ein bisschen anderen namen und ein bisschen anderen zugang nämlich eine stakeholder. Zentrierten zugang und was man aus 25 nur zehn als die wartbarkeit beziffert ist dort die flexibilität für den Stakeholder der Entwickler.
Also ein Entwickler möchte ein flexibles System haben, also ein wartbares System. Und das Schöne an diesem Qualitätsmodell ist, dass es eben zu jedem dieser Qualitätsattribute so einen eigenen Zugang hat und auch dann Qualitätsszenarien so als Beispiele dann noch beschreibt.
Und wenn man da mal einsteigt in dieses Modell, erkennt man dann so quasi eine große Wolke von Qualitätsszenarien und Qualitätsattributen und wie diese Dinge, miteinander zusammenhängen, auch aus dem Aspekt der verschiedenen Stakeholder.
Verstehe ich dich dann richtig, dass du nicht nur diese einzelnen Aspekte da zeigst, wie sie bei der ISO 25010 in so einer Mindmap gezeigt werden, sondern du hast sogar noch irgendwelche Verbindungen zwischen verschiedenen Qualitätsaspekten, die aufgezeigt werden. Das ist zum einen drin, ja. aber Flexibilität bedeutet aus Sicht jedes Stakeholders ein bisschen was anderes.
Das Produktmanagement versteht unter Flexibilität eben, dass sein System flexibel an verschiedene Hardwaren vielleicht angepasst werden kann oder in verschiedenen Umgebungen eingesetzt wird. Und leicht erweiterbar ist. Ja, genau. Das ist auch natürlich super interessant, weil das fällt, glaube ich, bei der ISO 25010 definitiv so ein bisschen hinten runter. Da muss man sich das dann selber erarbeiten, was das denn bedeutet für den jeweiligen Einsatzzweck.
Und das Schöne an Q42 ist, dass es Open Source ist. Das heißt, man kann auch seine eigenen Erfahrungen in dem Modell ablegen und in dieser Verlinkung mit einfügen. Okay. Ja, jetzt haben wir so ein bisschen über die Standards gesprochen und so ein bisschen vielleicht herausgearbeitet, was sind nicht funktionale Anforderungen oder halt Qualitätsanforderungen. Was machen die mit unserer Software und, wie kriegst du diese Qualitätsanforderungen umgesetzt? Was braucht es dafür?
Also ich komme ja aus der agilen Ecke und bei einem Greenfield Projekt, wenn ich eben vor dem großen Berg stehe, ich habe meine Anforderungen mehr oder weniger detailliert und jetzt muss ich eben an irgendeine Struktur der Software kommen. Da hat sich so was wie eine Architekturvision einfach etabliert, die adressiert aber auch schon verschiedene Ebenen. Zum einen so, wie teile ich so meine gesamte Softwarefunktionalität schon in einzelne logische Blöcke auf.
Das ist so der erste Schritt, den man auch Dekomposition nimmt, wenn man eine Softwarearchitektur entwirft. Aber gleichzeitig ist ja immer die Frage, wie bekomme ich jetzt eine Qualität in der Software? Und es ist ja nicht immer in Blöcke abgebildet, sondern es sind so querschnittliche Aspekte.
Wenn ich zum Beispiel eine gute Analysierbarkeit haben möchte von meiner Software, weil mir das wichtig ist, wenn ich im Feld einfach ein Feedback haben möchte, dann brauche ich zum Beispiel ein Logging oder ein Error-Konzept. Und das ist dann querschnittlich in allen Komponenten verteilt Und solche Dinge sollten von Anfang an schon irgendwie mitgedacht werden, damit sie bei der Entstehung der Software dann eben auch verankert werden.
Und in dieser Architekturvision hat man dann eben auch diesen ersten Durchstich durch die Software mitgedacht. Und Durchstich meine ich von oben, von der System-Schnittstelle bis unten an die Hardware von Embedded-Systemen, sodass ich mal so ein Gerüst habe. Und das ist eigentlich so das erste Ziel, die erste Software, die man hat, dass man so einen Durchstich bekommt auf dem Embedded-System.
Okay, das heißt also, du machst erstmal, ist dir wichtig, dass du überhaupt erstmal diese Qualitätsanforderungen hast und kennst. Also du weißt, in deinem Beispiel hast du jetzt gesagt, wird dir gesagt, wir müssen das im Feld auch analysieren können und dann wirst du dir irgendwas überlegen, wie es denn funktionieren kann, damit ich aus allen.
Baustein, Komponenten, wie auch immer, also wie deine Software zusammengesetzt wird, die Informationen so zusammentragen kann, dass man auch analysieren kann, wo vielleicht ein Fehler oder eine Fehlkonfiguration aufgetreten ist. Ja, was ich da noch sagen möchte, ist eben, dass eben aus dieser ersten oder aus dieser Analysephase, bevor ich mit dem System starte, eben die wichtigen und die kritischen Qualitätsziele einfach adressiert sind, damit man sich auf diese fokussieren kann.
Und das liegt ja außerhalb des Problembereichs des Software-Architekten, außer dass er darauf gucken soll, dass es klar ist, in welche Richtung es geht. Und da würde ich dann eher so mal den Ball zu dir zurückspielen. Björn, wie geht denn das Systemingenieur vor, um diese Qualitätsziele zu kennen oder zu haben?
Wie ist da deine Erfahrung aus der Praxis? Ja, das ist eine ganz interessante Frage, weil auf Systemebene, und gerade wenn, wir sprechen ja beide von Embedded Systemen ganz gerne, da spielt ja die Elektronik und die Mechanik rundherum auch eine Rolle. Da muss ich halt mit ganz vielen Stakeholdern sprechen, die mit dem System zu tun haben.
Der Kunde will natürlich erstmal irgendwie einen bestimmten Nutzen haben, also der adressiert üblicherweise irgendwelche Funktionen, die implementiert werden müssen. Aber wenn wir jetzt auf die Wartbarkeit gehen, du hast auch irgendwo mal einen Servicetechniker, der vielleicht rausfährt und irgendwas untersuchen muss.
Und der sagt dir dann, ich möchte ganz gerne die Fehler nicht als Fehlercode ausgelesen haben oder generell möchte ich erstmal Fehler auslesen können und dann möchte ich sie nicht als Fehlercode ausgelesen haben, weil dann muss ich immerhin so eine Tabelle nachgucken, sondern ich möchte relativ schnell Klartext angezeigt bekommen, was denn da mit dem System jetzt nicht so ganz in Ordnung ist.
Und schon bin ich in dieser Situation, dass ich diese Qualitätsanforderungen gefunden habe und dann mir überlegen muss, auf Systemebene, wie kriegen wir das denn jetzt umgesetzt. Und dann ist es natürlich ein wichtiger Baustein, dass wir diese Qualitätsanforderungen auch an die Software weiterleiten, weil vieles davon ist ja softwarebasiert, zumindest auch schon mal dieses Überarbeiten der Nummer in einen Klartext.
Aber vielleicht möchte ich auch irgendwelche Hardware-Komponenten mit einbinden, die Probleme melden können. Kurzschluss hier, Kurzschluss da, Überstrom, was auch immer. Also auch sowas könnte sein, dass das dann dort mit eingebunden wird. Also da nehmen wir diese nicht-funktionalen Anforderungen auf, teilen die auf, auf die einzelnen Komponenten.
So, und dann stehen dir diese Anforderungen quasi zur Verfügung und wir müssen dann erwarten, dass das dann von der Software auch entsprechend umgesetzt wird. Ja, Björn, da kann ich nur sagen, das wäre ein Träumchen, wenn ich mit meinen Softwareprojekten sowas vorgefunden hätte. Okay, ja, kurzen Spoiler, ich könnte sowas anbieten, Lastenhefte. Sowas erstelle ich ja und da werden genau diese Stakeholder auch alle befragt und die Anforderungen aufgenommen.
Aber darum soll es hier jetzt gar nicht so im Detail gehen, sondern wir wollen ja weiter auf die Software eingehen und auf die Softwarearchitektur vor allem. Und was wir jetzt so ein bisschen herausgefunden haben, es geht um die Qualitätsanforderungen. Also diese Qualitätsanforderungen, wie du es ja gerade gesagt hast, das sind die Themen, die wir relativ früh im Projekt auch kennen müssen, damit wir dieses Fehlermanagement oder Logging oder was auch immer auch konzeptionell aufsetzen können.
Weil diese, wenn kommen diese Anforderungen erst spät im Projekt, dann ist ja schon vieles gebaut, vieles entwickelt und du kriegst diese Konzepte gar nicht mehr alle untergebracht. Genau. Ich mache da nochmal ein Beispiel. Ich werfe da nochmal was rein. Wenn du nicht von Anfang an das Software-Update mitdenkst, dann kommst du zum Schluss, wenn deine Software im Feld ist, eben an den Punkt, wo ein Software-Update gemacht werden muss.
Und wenn ich da nicht durchdacht habe, dass das auch fehlerfrei funktioniert hat, dann hast du ein Problem. Ja, super Beispiel. Ich hatte das gerade von einem Sportkollegen. Der hatte mir davon erzählt, dass er ein Update von seinem Radcomputer machen sollte. Er hatte die App runtergeladen, die App hat gesagt, ja, mach mal ein Update von deinem Radcomputer. Ja, dann hat er damit angefangen und irgendwo mittendrin ist, glaube ich, die Internetverbindung abgerissen.
Ja, und dann hat er ja ein halb neu geflashtes System, also ein halb neu geflashtes Radcomputer. Und wenn man jetzt böse ist, sagt man, das war nur noch ein Briefbeschwerer, weil das konnte gar nichts mehr. Ja, und wenn der den Systemarchitekt an die Karre gekriegt hätte, der den redundanten Speicher für das Update dann nicht mit eingedacht hat, na dann würde er ihm was erzählen, oder? Ja, genau, so ist das.
Also da hätte man sich da auch nur ein Konzept überleben können, was dann entsprechend funktioniert, genau. Ja, genau, und ich nenne das dann eben diese technischen Konzepte. Das heißt, wie kommt diese Qualität in die Software? Welche Ecken muss ich da beachten? welche Komponenten sind zu integrieren und so weiter und so fort. Und das ist eben eines der Dinge, die ich unter Architekturarbeit verstehe, technische Konzepte aufzustellen.
Das heißt also, du sitzt dann da und machst die Entwürfe von den Software-Teilen, die dort implementiert werden sollen. Genau, also das sind ja diese logischen Komponenten, aber auch wenn ich ein Update-Konzept habe, dann fange ich ja nicht an, alles from the scratch selber zu entwickeln, sondern da werden Open-Source-Komponenten eingesetzt und dieses Zusammensetzen und auch das, was im System dann notwendig ist, das liegt dann entweder bei mir oder bei dem Systemingenieur.
Und ja, das ist Teil meiner Arbeit, aber das ist ja eben nur die eine Hälfte, weil der Software-Architekt, so ist mein Credo, muss auch eigentlich nahe am Team agieren, weil sonst wird es nichts mit dieser Software-Architektur.
Sonst überlegt er sich Dinge, die er vielleicht noch schön zeichnen kann und die er dokumentieren kann, aber die nicht so umgesetzt sind und deswegen nicht so als agiler Architekt eigentlich immer nah beim Team Und meist kommt auch vom Team, ich habe ja oft auch langjähriges Know-how, kommt auch ganz guter Input. Das heißt, ich versuche diese Entwurfsarbeit jetzt zum Beispiel im Rahmen des technischen Konzeptes zusammen mit dem Team zu machen.
Und das ist mir ganz wichtig als Architekt. Okay, das heißt also, du machst erste Entwürfe, stimmst das dann nochmal mit deinem Team ab, nimmst Feedbacks auf und passt dann da deine Software-Architektur nochmal entsprechend an.
Genau, das ist auch so ein bisschen ein iterativer Vorgang. Es geht ja zuerst mal darum, man muss in so einem agilen Entwicklungsprozess, der geht ja inkrementell, immer kommen neue Anforderungen rein und da muss man dann einfach auch erkennen, okay, hier brauchen wir ein Konzept für irgendwas, nimmt es auf, identifiziert es und muss es natürlich in einer Iteration vor der Umsetzung dann schon bearbeiten.
Und in dieser Iteration, wenn Softwarearchitektur entsteht, da involviere ich das Team ganz stark. Ah, okay. Ja, das ist vielleicht auch eine Frage bei agiler Softwarearchitektur. Du hast das gerade schon mal so im Nebensatz ein bisschen angerissen. Du bist also, also ihr seid in einem Sprint unterwegs, also agil, wie auch immer, also in kleinen Iterationen, Zeiteinheiten. Und du mit der Software-Architektur, du bist quasi immer einen Sprint voraus. Habe ich das gerade richtig verstanden?
Exakt. Das hast du richtig verstanden. Damit Architektur entsteht, ist ja nicht, dass man sich ein Stück Papier vornimmt und ein technisches Konzept darunter tippt, sondern. Das hat ja auch sehr viel damit zu tun, dass es vielleicht doch nicht ganz so klar ist, was das denn alles beinhalten soll und man fängt dann erst mit so einem ersten Konzept an und diskutiert das dann eben auch mit den anderen Stakeholdern nach draußen.
Also dieser Wartungsingenieur, der draußen rumläuft, der hat vielleicht noch mehr Input und dann kann man sich da auch so ein Qualitätsszenario überlegen, was so sein typisches Herangehen ist in solchen Situationen. Und dann kommt noch das Feine raus und das auch oft Wertvolle. Dann geht es eben darum, dieses Konzept, diese Architekturarbeit vor der Umsetzung zu entwerfen, im besten Fall zu dokumentieren noch und Review machen lassen von dem Team.
Und dann während der Umsetzung bin ich aber auch als begleitender Architekt dann mit dabei und mache dann auch noch reviews also quellcode reviews wasser auch immer ganz wichtig ist und so warum, ist das jetzt wichtig dass du dann noch quellcode reviews machst erzähl erklär das mal ja das hat also wenn ich mit quellcode geschrieben wird müssen einige architektonische konzepte unter umständen beachtet werden kann auch immer ein logging und fehlerkonzept so wie man das vorher.
Genannt haben den vorkommenden implementierung und das einfach der schulterschluss getan ist von architektur spezifikation und realisierung dass da das gleiche entsteht da ist es eben wichtig dass der architekt noch mal mit drauf guckt ja genau okay ich habe mir das schon gedacht dass es genau diesen hintergrund hat ich finde es jetzt aber noch mal wichtig dass dass du das selber noch mal so erwähnt hast.
Weil ich glaube, das ist nicht allen immer ganz klar, dass dieser, wie du sagst, der Schulterschluss dann auch passiert zum Schluss. Weil sonst kommst du eben vielleicht in die Situation, dass du nur einen Papiertiger hast, dass du zwar eine Architektur schön irgendwo beschrieben hast, aber dass sie dann nicht die Realität widerspiegelt. Ja, genau. Das heißt also, du kannst dann noch mal überprüfen, ob denn auch wirklich dieses Logging...
Durch alle Komponenten eingebaut worden ist, ob vielleicht irgendwo Fehler korrekt erfasst und gemeldet worden sind. Ja, ich finde es immer ganz interessant, als jemand, der Software umsetzt, denkt man völlig anders, als wenn man als Architekt drauf schaut. Als jemand, der es umsetzt, hat es immer technische Aspekte vor Augen. Der sagt dann Variablen, Zähler X ist irgendein Wert.
Und ich denke mir dann in dieser log nachricht fehlt einfach der fachliche kontext und dann mache ich das beim review übersetzt das noch mal sagen hier müssen wir dann noch mal nacharbeiten also das ist doch nicht die variable sondern das ist was auch immer für fachliche begriffe es ist und das ist immer dann bereichern wenn man so zusammenarbeitet weil dann wächst auch das team mit, der Architektur denke mit und dann wird es beim nächsten Log-Eintrag dann eben
das, diese Information, die man benötigt, mit drin sein. Ja, genau. Was auch immer. Das finde ich super. Was habe ich mich früher, als ich noch in der Embedded Software. Tätig war und dann auch, ja, wie du es eben gesagt hast, Open Source Komponenten eingesetzt habe, was habe ich mich da manchmal geärgert, wenn da irgendwo, wie du es gerade gesagt hast, X gleich sowieso als Log-Ausgabe kam.
Man wusste halt nicht, was es ist und dann musste man in der Software selber nochmal suchen, wo ist denn dieser Log-Auftrag erstellt worden und was bedeutet in diesem Fall dann das X? Genau, dieser fachliche Kontext, dieser Zusammenhang, warum schreibt da jetzt jemand ein X gleich irgendwas in das Log? Genau. Sehr gut, dass du das machst. Wirklich Hut ab und vielen Dank, dass du dich dafür einsetzt schon mal. Genau.
Jetzt haben wir ja die ganze Zeit darüber gesprochen, dass wir vielleicht auf der grünen Wies unterwegs sind. Also du hast ein Projekt angefangen, wo du frei entscheiden konntest, welche Logging-Mechanismen setzen wir ein. Du konntest Abwägungen treffen und so weiter. Und es wurde auch, sag ich jetzt mal, von Scratch an entwickelt.
Jetzt gibt es ja aber auch die andere Seite. Im Systems Engineering sprechen wir vom Brownfield, also mit Altlasten und die Software ist schon entwickelt und die Komponenten sind auch schon alle da. Ja, irgendeine Architektur ist halt auch entstanden. Wie gehst du denn damit um? Welches Problem hat die Software? Ist die überhaupt wartbar, stelle ich mir dann die Frage. Also klar, wenn die Software eingesetzt wird und sie läuft und sie erfüllt die Funktionen des Kunden, okay.
Okay, aber heutzutage wachsen ja auch die Anforderungen und dann muss ich nochmal ran an diese Software und da vielleicht Überarbeitungen reinbringen. Okay, dann möchte ich mal die Software jetzt von der Warte betrachten, dass sie schon zehn Jahre im Einsatz ist und jetzt soll sie auf eine neue Hardware gebracht werden. Und schnell merkt man, dass diese Abhängigkeiten, die Hardwareabhängigkeiten vielleicht ganz ungünstig sind und in mehreren Stellen vorkommen.
Sagen wir mal, wir nennen das einfach Big Ball of Mud. So wird das gerne in der Software beschrieben. Ich habe so eine unwartbare Software. Ich ziehe an einem Fädchen und es hat Auswirkungen in alle anderen Komponenten. Das heißt, ich muss eine Qualität wieder reinbringen und dazu habe ich jetzt kein Patentrezept, aber es ist wie immer, man muss sich hier die Schnittstellen und das Design anschauen und muss die Abstraktion der Hardware auf die richtige Ebene bringen.
Also vielleicht waren verschiedene Software-Schichten, die direkten Hardware-Zugriff hatten, Dann muss man sich eben überlegen, was kann die Hardware, was für ein Feature bietet diese Hardware für meine Software und abstrahiert es nach unten als Interface und dahinter kann ich dann eben verschiedene Hardwaren abbilden. Also sprich, ich kann verschiedene Chips, die für irgendeine Funktionalität verantwortlich sind, dahinter verstecken.
Und da musst du einfach wissen, was das Problem ist, nämlich jetzt hier Variabilität der Hardware und musst die entsprechenden Schnittstellen schaffen, abstrahieren und dann die Realisierung für die alte Hardware und die neue Hardware reinmachen. Naja, okay. Ja, das hört sich ja dann nach einigen an Arbeit an, was du dann da reinstecken musst. Aber du sagst, es ist dann auch machbar oder es ist in diesem Fall dann halt auch notwendig, damit man nicht alles neu machen muss.
Auf jeden fall also software ich sage immer software die geschrieben ist die hat ja schon einen zweck und jeder der sich damit also der die software umgesetzt hat hat ja irgendeinen grund gehabt es so zu machen der hat seinen ganz spezifischen blick darauf gehabt und deswegen kann man als software architekt oder so sagen wir als entwickler mittel mit großer erfahrung das ist Das ist vielleicht die Vorstufe zum Software-Architekt.
Oder vielleicht haben, gibt es ja nicht überall auch einen dedizierten Architekten, sondern es ist einfach derjenige, der das größte Wissen über die Software hat, kann dann eben diese Funktionalität bergen und kann sie dann eben technisch richtig verpackt wiederverwerten. Ja, wunderbar. Wiederverwerten von der Software, die da schon mehrere Jahre im Einsatz ist.
Finde ich gut. Alexander, ich glaube, wir haben ganz viel rund um das Thema Software-Architektur, Qualitätsanforderungen und Greenfield und Brownfield-Entwicklung gesprochen. Haben wir eventuell noch irgendwas vergessen, was dir wichtig ist, was für Embedded-Software-Entwicklung wichtig ist? Dann wäre jetzt die Möglichkeit, das noch anzubringen. Ich kann nur sagen, baut euer Continuous Integration System so gut auf, dass ihr kontinuierlich die Qualität eurer Software messen könnt.
Das bedeutet, wenn ich Embedded Systeme habe, dann muss ich einfach immer durch Regression sicherstellen, dass die wichtigsten Funktionalitäten immer jederzeit gewährleistet sind, weil das ist der kern einer agilen entwicklung dass ich jederzeit eigentlich release ich kenne das schon auch dass im bett system kann man nicht alles wirklich automatisiert testen aber. Man kann schon viel abdecken und muss dann vielleicht noch weniger manuelle tests dann bei den Releases machen.
Aber das finde ich ein ganz wichtiges Ding, kontinuierlich ein CI-System zu haben, das auf verschiedenen Unit-Test-Ebene und auch die Software-Hardware-Integration testet mit Systemen, die im CI-System integriert sind. Genau, stimmt. Das ist auch ein wichtiger Punkt. Das hatten wir damals auch bei meiner vorletzten Firma, immer wo ich noch angestellt war, hat man das auch aufgebaut.
Das war wunderbar, weil da nach und nach die Qualität der Software immer weiter erhöht worden ist, durch halt diese automatischen Tests. Also du konntest dann nachts auch die alten... Funktionen nochmal durchtesten, ob das denn noch funktioniert. Genau. Ja, wunderbar. Alexander, es hat mich gefreut, dass du hier bei mir im Podcast warst.
Definitiv ein interessantes Thema, weil es natürlich auch die Systementwicklung immer wieder betrifft und weil heutzutage ja immer mehr auch an Embedded-Systemen gebaut werden und deswegen umso interessanter, dass die natürlich auch auf. Auf Konzepte und Architekturen angewiesen sind. Vielen Dank, dass du hier warst. Vielen Dank, Björn. Es war mir eine große Freude. Alexander, wenn jemand mit dir Kontakt aufnehmen will und vielleicht deine Dienste nutzen möchte, wo findet er dich im Netz?
Ja, ich werde dort meinen Internetauftritt verlinken und auch auf mein 1-zu-1-Mentoring für Softwarearchitekten hinweisen und man findet mich natürlich im Suchen nach Alexander Eisenhut, Eisenhut mit TH oder www.eisenhut-se.de www.eisenhut-se.de Okay, wunderbar. Wie gesagt, ich stecke es auch noch in die Shownotes. Vielen Dank, dass du da warst. Vielen Dank, Björn. Wenn die Episode dir wertvollen Input geliefert hat, dann würde ich mich freuen, wenn du diese Episode weiterempfehlen würdest.
Außerdem freue ich mich auch über eine Bewertung und einen Kommentar bei iTunes, Apple Podcast oder Podcast Addict. Das ist für dich sehr einfach, in deiner Podcast-App möglich und motiviert mich, weitere tolle Episoden für dich aufzunehmen. Du möchtest dich über weitere Themen zum Systems Engineering informieren? Dann besuch meine Online-Bibliothek unter systemsengineeringmastermind.de. Dort findest du kostenfreie Webinare, die ich gehalten habe und noch halten werde.
Melde dich an und du bekommst die Webinar-Einladung direkt in deinen Posteingang. Das war die heutige Episode des Zukunftsarchitekten, der Systems Engineering Podcast für Machende und Entscheidende. Mein Name ist Björn Schorre und ich danke dir fürs Zuhören. Hab Spaß an dem, was du machst und vor allem wünsche ich dir einen hohen Wirkungsgrad. Tschüss und bis zum nächsten Mal. Music.