ZA220 - Was ist Dein System? Erkennen, was ist drinnen und was ist draußen

25.06.2024 25 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten geht es um die Bedeutung einer klaren Systemabgrenzung zu Beginn eines Projekts. Ich erläutere, warum es wichtig ist, mit einer klaren Systemabgrenzung zu starten und wie du dabei vorgehen kannst, um eine akzeptierte Darstellung deines Systems zu erhalten.

Eine Systemabgrenzung hilft dir, Einblicke in die Einbettung deines Systems zu gewinnen und Informationen über externe und interne Systemelemente zu erhalten. Durch die Diskussion über diese Elemente und die Identifizierung von Akteuren, die das System nutzen oder bedienen, könnt ihr im Projektteam ein gemeinsames Verständnis aufbauen und Missverständnisse frühzeitig klären.

Durch die Systemabgrenzung kannst du auch eine Stakeholderliste erstellen und Anwendungsfälle identifizieren, die das System unterstützen soll. Darüber hinaus können vorhandene interne Elemente überprüft werden, ob sie für das aktuelle Projekt wiederverwendet werden können, was Zeit und Ressourcen spart.

Die erlangten Informationen aus der Systemabgrenzung können auch für das Schnittstellenmanagement genutzt werden. Ein gut verwaltetes Schnittstellenmanagement hilft dabei, Probleme bei der Integration des Systems in die reale Umgebung zu vermeiden und die Kommunikation mit externen Systemen zu erleichtern.

Für die Umsetzung einer Systemabgrenzung empfehle ich, leichtgewichtig mit einem Flipchart oder einem Whiteboard zu beginnen und später digitale Tools wie PowerPoint oder Visio zu nutzen. Die kontinuierliche Pflege des Systemkontexts hilft dabei, langfristig einen Mehrwert aus der Arbeit zu generieren.

Zum Abschluss gebe ich drei Tipps: Beginne leichtgewichtig, sorge für ein einheitliches Verständnis im Team und pflege den Systemkontext kontinuierlich. Falls du an Systemkontext-Plakaten interessiert bist, kannst du diese auf meiner Webseite erwerben. Ich danke dir fürs Zuhören und wünsche dir einen hohen Wirkungsgrad bei deinen Projekten. Tschüss und bis zum nächsten Mal beim Zukunftsarchitekten, dem Systems Engineering Podcast.

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

SysML der OMG: https://www.omgsysml.org/

Buch zur Methode CONSENS und ein Anwendungsbeispiel: https://www.systemsengineeringmastermind.de/portfolio-item/einfache-modellierung-der-systemarchitektur-mit-consens/

System-Footprint: https://www.systemsengineeringmastermind.de/portfolio-item/system-footprint/

Systemabgrenzung Plakat: https://www.digistore24.com/product/558269 mit dem Rabatt-Code ZAP220.

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre

ZA219 - Der heimliche Treiber moderner Software-Architekturen

23.04.2024 32 Minuten



Zusammenfassung

In Episode 219 des Podcasts „Zukunftsarchitekten“ spricht Björn Schorre, ein erfahrener Systemingenieur, über die Bedeutung von Software-Architektur, besonders in Bezug auf Embedded Software. Der Gast der Episode, Alexander Eisenhut, der seit fast drei Jahrzehnten im Bereich Embedded Software Engineering tätig ist und in den letzten zehn Jahren als Softwarearchitekt gearbeitet hat, diskutiert die treibenden Faktoren hinter der Entwicklung von Softwarearchitekturen. Sie beleuchten die Wichtigkeit nicht-funktionaler Anforderungen und Qualitätsziele in der Softwareentwicklung und wie diese durch Standards wie die ISO 25010 und das neuere Modell Q42 adressiert werden. Während Q42 einen stakeholder-zentrierten Ansatz verfolgt, bietet es einen detaillierteren Einblick in die Verbindungen zwischen verschiedenen Qualitätsaspekten. Alexander betont, wie kritisch es ist, Qualitätsanforderungen frühzeitig im Projekt zu identifizieren und in der Softwarearchitektur zu berücksichtigen, um eine nachhaltige und wartbare Software zu entwickeln. Das Gespräch hebt auch die Rolle des Softwarearchitekten im agilen Entwicklungsprozess hervor, einschließlich der Bedeutung von Entwurfsarbeit, Reviews und der kontinuierlichen Einbindung des Teams.

Links:
Q42 Qualitätsmodell
https://quality.arc42.org/
1:1 Mentoring
https://eisenhuth-se.de/

Embedded Software Architektur Kochstudio
https://eisenhuth-se.de/blog

Direkte Links zu Alexander Eisenhuth:

LinkedIn: https://www.linkedin.com/in/alexander-eisenhuth/

Email: ae@eisenhuth-se.de

 

############
Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

##################
Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

##################
P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition (https://shop.tredition.com/booktitle/Erfolgreich_Lastenhefte_schreiben/W-337-928-077?utm_source=zukunftsarchitekten-podcast.de&utm_medium=podcast&utm_campaign=generic)

On Air in dieser Episode

avatar
Björn Schorre
avatar
Alexander Eisenhuth

ZA211 - Wie werden Anforderungen in Subsysteme zerlegt?

31.10.2023 28 Minuten



Zusammenfassung

In dieser Episode des Zukunftsarchitekten-Podcasts geht es darum, wie du Anforderungen in Subsysteme aufteilen kannst und welche Vorteile dies für dein Projektmanagement hat. Du wirst verstehen, dass es wichtig ist, die Anforderungen von Kunden und dem Markt zu kennen, um erfolgreich Produkte verkaufen zu können. Neben den Systemanforderungen gibt es auch auf Unternehmensebene spezifische Anforderungen an Software, Elektronik, Elektrik und andere Bereiche. Du musst diese Anforderungen aufteilen, um die Umsetzung durch die entsprechenden Teams zu ermöglichen und Arbeitspakete zu bilden.

Teile die Anforderungen in funktionale Elemente auf, um ihnen bestimmte Funktionen zuzuweisen. Dadurch kannst du die Anforderungen genauer planen und die entsprechenden Attribute und Metadaten festlegen. Eine bewährte Methode ist die Dreiteilung, bei der du die Anforderungen grob und auf einer High-Level-Ebene aufschreibst, dann die Funktionen bestimmst, die mit diesen Anforderungen erfüllt werden müssen, und schließlich eine logische Aufteilung des Systems vornimmst. Nutze den morphologischen Kasten, um verschiedene Möglichkeiten zur Erfüllung der Funktionen zu betrachten und Varianten zu bilden, die später bewertet werden können. Dadurch kannst du die Anforderungen strukturiert aufteilen und besser verfolgen, welche bereits umgesetzt sind und welche noch bewertet werden müssen.

Bei der Architekturbewertung kannst du verschiedene Kriterien wie Preis oder Entwicklungsgeschwindigkeit betrachten. Nachdem du deine Auswahl aus dem morphologischen Kasten getroffen hast, überführst du deine funktionale Architektur in eine logische Architektur und weist dort die einzelnen Elemente zu. Es kann sein, dass beim Einbau der Elemente in das Produkt weitere Anforderungen auftauchen, die zuvor nicht berücksichtigt wurden. Diese Anforderungen werden ebenfalls dokumentiert und den logischen Elementen zugewiesen.

Auf der physikalischen Ebene betrachtest du die mechanischen Bauteile, Elektronik und Software, die auf dem System läuft. Auch Software betrachtest du als physikalisches Element, da sie auf dieser Ebene besser einzuordnen ist und oft ein eigenes Software-Team vorhanden ist. Bei den physikalischen Elementen schaust du zunächst, welche bereits im Unternehmen vorhanden sind und wiederverwendet werden können. Falls dies nicht der Fall ist, guckst du, was mit kleinen Änderungen wiederverwendet werden kann. Im schlimmsten Fall entsteht ein neues Teilprodukt oder eine Bausteinvariante. Im besten Fall kann ein Baustein sowohl im alten als auch im neuen System verwendet werden. Es spart Zeit, vorhandene Bausteine wiederverwendet, solange die Änderungen akzeptabel sind. Es besteht auch die Möglichkeit, Zukaufteile wie Widerstände oder Embedded-Systeme wie Arduino oder Raspberry Pi zu verwenden. Diese müssen jedoch auch Industrie-Tauglichkeit, EMV, etc. erfüllen. Du kannst sie entweder direkt zukaufen oder bei der eigenen Entwicklung oder einem externen Entwicklungsunternehmen beauftragen.

Es entstehen weitere Anforderungen, wenn du physikalische Elemente gestaltest, die deinen logischen und funktionalen Architekturen entsprechen. Zum Beispiel benötigst du für die Erhitzung eines Gartengrills einen Brenner. Die Implementierung eines solchen Brenners erfordert spezifische Schnittstellen wie ein Ventil zum Regulieren des Gaseinlasses. Hier musst du dir überlegen, welche Anforderungen sich aus dem Einsatz dieses Ventils ergeben, wie beispielsweise der Durchmesser und die Anschlussgeometrie. Auch die Luftzufuhr und der Abgasschutz müssen berücksichtigt werden. Indem du dein System dekomponierst und Entscheidungen triffst, kannst du die erforderlichen Anforderungen filtern und ihnen Traceability und Informationen zuordnen.

 

 

###############

Meine Mailadresse: feedback@zukunftsarchitekten-podcast.de

###############

Brauchst Du Unterstützung bei der Erstellung eines Lastenheftes oder hast eine Frage dazu, dann findest Du meine Email in den Shownotes. Klicke darauf oder kopiere sie in Dein Emailprogramm und schicke mir eine Mail und wir sprechen darüber.

Dann kannst Du Dir in meinem Online-Kalender auch gerne direkt einen Termin buchen: https://kalender.bjoernschorre.de

###############

P.S.: Mein Buch zum Thema Lastenhefte ist da. Du findest es auf der Verlagsseite von tredition

On Air in dieser Episode

avatar
Björn Schorre