Benutzer:Jorgejordi/Buch

Handbuchinhalt

Für wen haben wir dieses Buch geschrieben? {2 Seiten}

Dieses Buch haben wir für Systemingenieure und Systemingenieurinnen geschrieben, die neu in diesem Aufgabengebiet unterwegs sind. Wenn Sie also aus einer technischen Disziplin kommen, wie beispielsweise dem Maschinenbau, der Elektrotechnik, der Informatik, dem Test oder einem anderen Fachgebiet und bisher für die Entwicklung einzelne Komponenten zuständig waren, Ihr neues Aufgabengebiet aber ein umfassenderes und komplexeres Teilsystem betrifft, dann finden Sie in diesem Buch konkrete Hinweise zum Vorgehen.

Hinter dem „wir“ im vorigen Absatz steht die xyz, die xyz e.V. Die xyz verfolgt das Ziel, Systems Engineering als Fachdisziplin zu etablieren, Methoden und Prozesse weiterzuentwickeln und den fachlichen Austausch von Systems Engineers zu fördern. Näheres zur xyz finden Sie unter www.xyz.de. Literatur zum Systems Engineering gibt es mittlerweile meterweise. Was hat uns veranlasst, ein weiteres Buch hinzuzufügen? Wir haben uns in einen Neueinsteiger in dieses Aufgabengebiet hineinversetzt und uns auch erinnert, wie es für uns selbst war, als wir neu mit komplexen und technisch vielschichtigen Aufgaben konfrontiert wurden. Wir hätten uns damals eine solche geeignet aufbereitete Darstellung des Systems Engineerings gewünscht. Bis heute war ein solches Buch nicht verfügbar, so dass wir den Beschluss fassten, es endlich selbst zu schreiben. Die geforderten Kompetenzen eines Systemingenieurs sind vielfältig. Sie reichen von persönlichen bis zu zahlreichen fachlichen Fähigkeiten. Eine einzelne Person könnte niemals in allen diesen tangierten Fachgebieten einen fundierten wissenschaftlichen Hintergrund mitbringen. Im Verein der xyz sind jedoch zu allen relevanten Gebieten Fachleute versammelt, die ihre Expertise in dieses Werk eingebracht haben.

An diesem Handbuch haben zahlreiche Mitglieder der xyz mitgearbeitet, die fundierte Kenntnisse und langjährige Erfahrung auf diesem Gebiet besitzen. Dieses Handbuch richtet sich zwar an Einsteiger im Systems Engineering, es wurde aber von Experten verfasst. Die hier aufgeführten Eigenschaften und Kompetenzen eines Systemingenieurs sind sorgfältig ausgewählt, auf Relevanz geprüft und didaktisch aufbereitet. Neben der einführenden Darstellung des Systems Engineerings verweisen wir auf weiterführende Literatur, so dass Sie sich anhand dieser Verweise tiefer in das Thema einarbeiten können. Dieses Handbuch ist daher auch für Profis interessant, die einen Überblick über die aktuelle Literatur gewinnen möchten.

Kommentar

Aufbau des Buchs {2 Seiten}

Zunächst möchten wir Orientierung geben. Das Aufgabengebiet des Systems Engineering ist vielfältig, da verliert man schnell den Überblick. Wir stellen Ihnen dieses Aufgabengebiet vor und erklären die wesentlichen Begriffe. Hierdurch wird dann auch deutlich, dass es sich beim Systems Engineering nicht um eine weitere Einzeldisziplin, sondern um eine Meta-Disziplin handelt. Wir erläutern die Vor- und Nachteile und stellen alternative und verwandte Ansätze vor. Danach positionieren wir den Systems Engineer im Entwicklungsprojekt. Das Zusammenspiel von Projektmanagement und Systems Engineering ist für den Projekterfolg ganz entscheidend. Mit seiner Fachkompetenz nimmt er neben der technischen Koordination auch Einfluss auf organisatorische und kaufmännische Entscheidungen.

Im Weiteren gehen wir auf die Tugenden – die persönlichen Eigenschaften – des Systems Engineers ein. Hierzu zählen vor allem das Systemdenken und die Offenheit für die interdisziplinäre Zusammenarbeit. Gute kommunikative Fähigkeiten und der konstruktive Umgang mit Konflikten gehören ebenso zum persönlichen Repertoire wie eine ausgeprägte Integrationsfähigkeit und ein Projektbewusstsein.

Kern dieses Buchs ist die Vermittlung von Kompetenzen zur erfolgreichen Entwicklung komplexer Systeme. Hierbei treten bestimmte Grundmuster wiederkehrend auf, die sich Systems Engineers zu Eigen machen sollten. Wir erläutern die wesentlichen Prozesse, Methoden und stellen die gängigen Modellierungssprachen vor.

Praktische Beispiele zeigen die Anwendung des Systems Engineering auf konkrete Entwicklungsaufgaben und zeigen auch typische Problemfälle auf.

Orientierung {40 Seiten}

Begriffsbestimmungen

In den Begriffsapparat des Systems Engineering sind Begriffe aus unterschiedlichen Disziplinen eingeflossen. Das gleiche Wort kann in diesen einzelnen Fachgebieten aber unterschiedliche Bedeutungen haben. In diesem Kapitel wird das Bewusstsein für diese unterschiedliche Begriffsverwendung geschärft und für mehrdeutige Bezeichnungen werden eindeutige Definitionen vorgenommen.

Das Radaktionsteam schlägt für dieses Kapitel im Vorfeld eine "Begriffs-Sammlung" vor, um aus den Fachdisziplinen typische Begriffe mit Definitionsbedarf zusammenzutragen.

Aufgabenbereiche

Systems Engineering besteht aus den Teilbereichen 'SE-Management' und 'SE-Technische Prozesse', es erstreckt sich über organisatorische und technische Inhalte und ist daher äußerst breit angelegt. Dieses Kapitel soll den Leser langsam an das komplexe Aufgabengebiet heranführen, indem zunächst die Teilbereiche und dann die einzelnen Aufgaben beschrieben werden.

Summe der Teile und das Ganze

'Das Ganze ist mehr, als die Summe seiner Teile', dieses Aristoteles zugeschriebene Zitat könnte man als Mantra des Systems Engineering bezeichnen. Es betont die Bedeutung der Beziehungen zwischen den Teilen als wesentlich für die Funktion von Systemen. Die Beziehungen unterscheiden eine Systemarchitektur von einer Stückliste. Dieses Kapitel beschreibt den Mehrwert einer Systemarchitektur gegenüber einer Stücklisten-Darstellung und welche Aktivitäten im Entwicklungsprojekt auf Grundlage der Architektur durchgeführt werden können.

SE in a nutshell

Ausgehend von den Bedürfnissen eines Kunden führt dieses Kapitel den Leser durch den Prozess einer Systementwicklung: Anforderungen und ihre Überprüfung, Funktionen und ihre Zuordnung zu Komponenten, Beauftragung der Fachabteilungen mit der Erstellung der Komponenten, Montage bzw. Integration der Komponenten, Test und Übergabe an den Kunden. Ausgehend von einer sehr allgemeinverständlichen Darstellung sollen hier die oben definierten Begriffe in den Kontext eingeführt werden.

Sichtweisen

Die Sicht auf ein Entwicklungsprojekt kann je nach fachlicher Heimat des Betrachters sehr unterschiedlich ausfallen. Zunächst kann der Blick auf das zu entwickelnde Produkt oder auf den Entwicklungsprozess gerichtet werden. Blickt man auf das Produkt, so kann hier die konkrete Geometrie, die physikalischen Wechselwirkungen oder die Logik der Funktionen im Vordergrund stehen. Diese Betrachtung kann anhand realer Objekte in Form von Modellen, Mustern und Prototypen oder anhand von virtuellen Darstellungen durch ein 3D-Rendering, ein mathematisches Gleichungssystem oder ein SysML-Modell erfolgen. Blickt man auf den Prozess, so können hier die einzelnen Aufgaben und Arbeitsschritte, die Kosten oder die Organisation der beteiligten Personen mit ihren Rechten und Rollen im Fokus stehen.

Vor- / Nachteile des SE-Einsatzes im Projekt

Die Vorteile des Systems Engineering ergeben sich aus einer geordneten und besser planbaren System-, bzw. Produktentwicklung. Hieraus resultieren Entwicklungsprojekte, die innerhalb des budgetierten Zeit- und Kostenrahmens erfolgreich abgeschlossen werden. Die Zuständigkeiten in den Projekten sind eindeutig geklärt und es besteht ein deutlich besserer Überblick über die erreichten Ergebnisse, den Abstimmungsbedarf mit Nachbarabteilungen und externen Zulieferern, Kunden und anderen Beteiligten sowie über die Aufgaben, die noch in der Zukunft liegen. Diese Vorteile sollen in diesem Kapitel ausgeführt werden.

Die Nachteile des Systems Engineering liegen in einem etwas höheren Aufwand für die Vorbereitung des Projekts sowie in einem größeren Aufwand in der Anfangsphase. Dieser vermeintliche Nachteil wird aber im laufe des Projekts wieder wett gemacht und somit in einen Vorteil verwandelt. Viele Ingengieure/innen tun sich anfangs schwer mit der Erstellung einer abstrakten Produktarchitektur. Diese Nachteile und wie man sie überwindet, soll dieses Kapitel beschreiben.

Alternative / verwandte Ansätze

Nahe Verwandte des Systems Engineering sind das Projektmanagement und die Entwicklungsmethoden wie Software Engineering, methodisches Konstruieren oder die Integrierte Produktentwicklung nach Ehrlenspiel. Auch Prozessorientierte Ansätze wie SCRUM, Agile-Development oder Extreme Programming sind derzeit im Gespräch. Dieses Kapitel benennt diese Ansätze und grenzt diese gegen das Systems Engineering ab.

Positionierung {30 Seiten}

Stellung des SE im Projekt

Während die Gesamtverantwortung für ein Projekt beim Projektleiter liegt, ist der Systems Engineer für die technische Funktionsfähigkeit und die Erfüllung der zugesagten Anforderungen zuständig. Diese Arbeitsteilung mit den entsprechenden Entscheidungskompetenzen sowie die Repräsentation des Projekts nach innen und außen sind sorgfältig abzustimmen. In diesem Kapitel soll der Zuschnitt der Verantwortungsbereiche und worauf hierbei zu achten ist, erläutert werden.

Zusammenarbeit mit anderen Projektbeteiligten

Je nach Umfang eines Entwicklungsvorhabens, sieht die Projektorganisation Personen mit spezifischen Zuständigkeiten vor. Neben dem obligatorischen Projektmanagement können dies Verantwortliche für Software-Engineering, Konstruktion, Elektrotechnik, Test, Einkauf, Logistik, Produktion, Inbetriebnahme, Wartung etc. oder für spezielle Technologien sein. Da in diesen Bereichen unterschiedliche Fachkulturen und Vorgehensweisen bestehen und die Änderungsgeschwindigkeiten von Anforderungen und deren Umsetzung sehr verschieden ist, gilt es hier im Projekt für Kohärenz und Synchronisation zu sorgen.

Argumentationshilfe gegenüber Dritten im Projekt

Vordergründig betrachtet erhöht Systems Engineering die Entwicklungskosten und verzögert das Projekt. Zahlreiche Analysen zeigen jedoch, dass sich diese Investition in die frühen Projektphasen lohnt und das Projekt insgesamt eine deutlich größere Budget- und Plantreue aufweist. In diesem Kapitel sollen diese Evidenzen präsentiert und mit Verweisen auf die Originalliteratur belegt werden.

Abgrenzung / Verhältnis zu Projektmanagement

In diesem Kapitel sollen die Methoden des Systems Engineerings und des Projektmanagements gegenübergestellt werden. Während das Projektmanagement vorwiegend außen-gerichtete organisatorische Fragen gegenüber dem Auftraggeber sowie nach den erforderlichen Ressourcen behandelt, wendet sich das Systems Engineering den inhaltlichen Fragen des zu entwickelnden Produkts sowie den Projektbeteiligten zu. Neben der Abgrenzung sollen aber auch die Gemeinsamkeiten und die Wechselbeziehungen zwischen diesen beiden Themengebieten zur Sprache kommen.

Neue Wege der Organisation im Komplexitätszeitalter

Kommentar

Für Außenstehende trägt Systems Engineering noch immer den Nimbus einer schwergewichtigen Methodik wie sie im Apollo-Programm praktiziert wurde. Tatsächlich hat Systems Engineering neben der Modell-orientierten Vorgehensweise auch Prinzipien aus der Agile-Bewegung, wie SCRUM oder Extreme-Programming aufgenommen. In diesem Kapitel sollen diese neuen Ansätze vorgestellt und deren Vor- und Nachteile erläutert werden.

SE – Tugenden {80 Seiten}

Systemdenken

Dieses Kapitel soll die wesentlichen Aspekte der Systemtheorie erläutern und den hieraus folgenden Mindset von Systems Engineers charakterisieren. Dieses Kapitel steht unter der Überschrift SE-Tugenden an oberster Stelle, daher soll der Einfluss des Systemdenkens auf die Weltsicht im Allgemeinen und das Agieren im Projekt im Speziellen hier beschrieben werden.

Interdisziplinäres Zusammenarbeiten

Die Bereitschaft und Offenheit für das Hineindenken in Aufgaben, Konzepte und Lösungen fremder Fachdisziplinen, ist Voraussetzung für die technische Leitung von komplexen Entwicklungsprojekten. Systems Engineers kommen klassischerweise aus einer Ingenieurdisziplin und sind von dieser fachlichen Heimat geprägt. Es stellt sich daher die Frage, welche Kenntnisse über andere Disziplinen benötigt ein Systems Engineer? Diese Frage ist schwierig zu beantworten, da die Entwicklungsprojekte ganz unterschiedlich gelagert sein können. Dennoch wollen wir dieser Frage nicht ausweichen und einen groben Anhaltswert über das erforderliche Wissen aus den Nachbardisziplinen geben.

• • Welches Informatik-Wissen braucht ein Systems Engineer?
  • Welches Elektronik- / Elektrotechnik-Wissen braucht ein Systems Engineer?
  • Welches Maschinenbau-Wissen braucht ein Systems Engineer?
  • Welche disziplinübergreifend Wissen braucht ein Systems Engineer?

Integrationsfähigkeit

Ein gemeinsames Verständnis der zu lösenden Aufgabe und die Einigung auf ein gemeinsames Vorgehen erfordert eine ausgeprägte Integrationsfähigkeit unterschiedlicher Fachkulturen und Persönlichkeiten. Voraussetzung hierfür ist eine vermittelnde und moderierende Art der Kommunikation sowie ein Verständnis der in den einzelnen Fachkulturen vorherrschenden semantischen und methodischen Unterschiedlichkeiten.

Kommunikation

Äußerungen besitzen immer mehrere Dimensionen; eine im Ingenieurbereich oft gehörte Forderung nach rein sachbezogener Kommunkation greift daher zu kurz. Da es um Kommunikation zwischen Menschen geht, muss auch im Entwicklungsprojekt der ganze Mensch mit all seinen Eigenschaften und Bedürfnissen berücksichtigt werden. Nach einem modellhaften Ansatz des Psychologen Friedemann Schulz von Thun sind Systems Engineers 'integrale Führungskräfte' mit einem sog. 'inneren Team', so dass widerstreitende Interessen und Bedürfnisse antizipiert, nachvollzogen und kommunikativ vermittelt werden können.

Konfliktmanagement

Anforderungen an komplexe Systeme enthalten stets konfliktäre Ziele. Hinzu kommt eine Vielzahl alternativer Lösungswege, widersprüchliche Randbedingungen und unzureichende Ressourcen. Jedes erfolgreich realisierte System stellt daher eine große Leistung des Konfliktmanagements dar. Dieses Kapitel soll hierfür ein Bewusstsein schaffen und Möglichkeiten des Konfliktmanagements aufzeigen.

Projektbewusstsein

Technische Entscheidungen haben neben technischen Auswirkungen in vielen Fällen auch Folgen für das Entwicklungsprojekt. So wird mit der Auswahl einer spezifischen Systemkomponente das Budget belastet, die Lieferzeit überschreitet möglicherweise ein gesetztes Zeitlimit und es kommt ein zusätzlicher Lieferant und Kommunikationspartner ins Spiel. Für diese Komponenten sind ggf. auch spezielle Testmethoden und Techniken zur Konfiguration und Wartung sowie Schulung des Personals vorzusehen. Dieses Kapitel zeigt, wie Systems Engineers bei technischen Entscheidungen die Projektprozesse (ISO/IEC 15288), sowie die kaufmännischen und logistischen Konsequenzen im Blick behalten.

Technical Leadership

Die erfolgreiche Systementwicklung ist eine Team-Leistung. Doch wie führt man ein Team zu solchen Höchstleistungen? Dieses Kapitel erläutert die Faktoren der technischen Führung, bzw. Leitung. (es bleibt zu überlegen, ob diese englische Überschrift beibehalten wird.)

Dokumentationsdisziplin

Dokumentation von Entscheidungen und deren Begründungen wird bei Entwicklern oft als lästige Bürokratie empfunden. Die Präsentation des Projektstands wird als "Powerpoint-Engineering" verhöhnt. Diese Geringschätzung der Kommunikation und der Ergebnissicherung zeigt ein gering verbreitetes Verständnis für organisatorische Zusammenhänge und nachfolgende Prozesse. Dieses Kapitel schafft das Bewusstsein für die Bedeutung der Dokumentation und vermittelt Methoden, wie Aufwand und Nutzen in ein gesundes Verhältnis gebracht werden können.

Kompetenz gewinnen {150 Seiten}

Grundmuster kennen und anwenden

Im Systems Engineering werden auf den unterschiedlichen Aggregationsebenen, wie bspw. Gesamtsystem, Teilsystem, Baugruppe, Bauteil) immer wieder die gleichen elementaren Schritte ausgeführt. So gilt es immer, zunächst die Anforderungen einer Aufgabe zu klären. Um diese Anforderungen möglichst vollständig zu erheben, sind im Vorfeld die Stakeholder, bzw. Anspruchsgruppen zu identifizieren. Im Weiteren sind dann aus den Anforderungen Funktionen und Eigenschaften abzuleiten. Den Funktionen werden dann Funktionsträger, bzw. Lösungselemente zugeordnet. Diese Funktionsträger gehen dann in den Projekt- und Kostenplan ein. Dieses elementare Grundmuster: Anforderungen - Funktionen - Lösungselemente soll in diesem Kapitel vorgestellt und die Universalität demonstriert werden. Dabei soll auch gesagt werden, dass Systems Engineering natürlich deutlich umfangreicher ist, als dieses Grundmuster.

Gängige Artefakte

Aus dem oben beschriebenen elementaren Grundmuster des Systems Engineerings resultieren die gängigen Artefakte, bzw. Arbeitsergebnisse, wie Anforderungslisten, Funktionsstrukturen und Produktarchitekturen. In diesem Kapitel sollen aber noch weitere Ergebnisse wie Spezifikationen, Verifizierungsanforderungen, Test-Prozeduren, Projektpläne, Stücklisten etc. vorgestellt werden.

Modelle und Modellierungssprachen

Zentrales Element des modellbasierten Systems Engineerings sind Modelle und die hierfür verwendeten Modellierungssprachen. Neben eine groben Unterscheidung nach statischen und dynamische Modellen, sollen in diesem Kapitel zunächst die gängigsten Modelltypen vorgestellt werden: Hierarchien, Block-Diagramme, Use-Case-Diagramme (Anwendungsfall-Diagramme), Zustands-Modelle.

Abstimmung von Prozess und Modellierung

Kommentar

Der Übergang von einer Dokumenten-orientierten zu einer Modell-basierten Vorgehensweise eröffnet neue Möglichkeiten der Prozessgestaltung. So sind simultane und verteilte Arbeitsweisen oder agile Prozesse nur auf Grundlage eines Modells realisierbar, das Teilergebnisse aufnimmt und miteinander in Beziehung setzt.

Modell-gestützte Kommunikation im Projekt

Kommentar

Die oben aufgeführten Prozesse bestimmen ganz wesentlich die Art der Zusammenarbeit der Projektbeteiligten und damit auch die Art der Kommunikation. Auf der Grundlage eines Architekturmodells wird die Relevanz von Einzelentscheidungen für angrenzende Baugruppen deutlich. Hierdurch wird klar, wer mit wem und wann über was zu sprechen hat. Damit sich diese Kommunikation nicht im Kreise dreht, sind Zwischenstände, sog. Baselines, verbindlich festzuschreiben.

Kleiner Grundwortschatz der Modellierung

Kommentar

Im Zusammenhang mit der Modell-gestützten Systementwicklung wird meist auch die Systems Modelling Language (SysML) genannt. Die Möglichkeiten der SysML sind vielversprechend und Neueinsteiger sind schnell von den Vorteilen überzeugt. Bei der Auseinandersetzung mit der Modellierungssprache macht sich dann aber schnell Resignation breit, denn der Umfang an Modell-Konstrukten und Diagrammen überfordert viele. Dieses Kapitel soll den Leser zur Modellierung hinführen, ohne ihn gleich mit der ganzen Komplexität von SysML zu konfrontieren. Einfache Struktur- und Verhaltensmodelle sollten für dieses Kapitel genügen.

Weiterführende Modell-Elemente und Diagramme

Kommentar

Die im vorausgehenden Kapitel geschaffenen Grundlagen sollen hier weiter vertieft und ergänzt werden. Der Leser soll in die Lage versetzt werden, einfache Systeme in den wichtigsten Aspekten abzubilden. Für eine erschöpfende Behandlung der Modellierung soll auf die einschlägige Literatur verwiesen werden.

Modellierung am Beispiel (MBSE)

Kommentar

Prozesse und Normen

In regulierten Märkten, wie der Luft- und Raumfahrt oder der Medizintechnik gelten auch für die Entwicklungsprozesse verbindliche Normen, die bspw. die Art der Dokumentation, den Nachweis von Testergebnisssen oder die Durchführung von Änderungen regeln. Im Jahr 2002 wurde die internationale Norm ISO/IEC 15288 eingeführt, die Prozesse für die Entwicklung technischer Systeme und Dienstleistungen mit einem breiten Anwendungsspektrum definiert. In diesem Kapitel sollen nur die wesentlichen Normen angesprochen und die ISO/IEC 15288 vorgestellt werden.

Systems Engineering Methoden

In den folgenden Kapiteln soll der "kleine Katechismus" des Systems Engineerings vorgestellt werden.

Anforderungsanalyse

Anforderungen sind das A und O der Systementwicklung: sie stehen ganz am Anfang und bestimmen den Enwurf und sie stehen auch am Ende, wo sie zur Verifizierung und Validierung herangezogen werden und damit dem Beleg der Eignung des Systems dienen - sofern diese Prüfungen gelingen. Dieses Kapitel soll diese Schlüsselrolle der Anforderungen erläutern und ein Bewusstsein schaffen für deren gültige und klare Formulierung.

Funktionaler Entwurf

Funktionen eröffnen für die gestellten Anforderungen einen Lösungsraum. Dabei halten Sie die konkrete Realisierung dieser Funktionen noch weitgehend offen. Damit umreißen die Funktionen einen Raum, den Fachingenieure und Systemarchitekten kreativ ausgestalten können. Der Schritt der Funktions-Modellierung wird gerne übersprungen oder abgekürzt, da er oft als unnötige Bremse und Zeitverschwendung empfunden wird. In diesem Kapitel sollen daher der Mehrwert dieses Schrittes verdeutlicht und die Vorgehensweise und Modellkonstrukte vorgestellt werden.

Architektur-Entwicklung

Durch die Zuweisung von Funktionsträgern zu den Funktionen und die Gliederung dieser Komponenten nach Aggregationsebenen entsteht die Produktarchitektur. Die Input- und Output-Beziehungen zwischen den Funktionen bilden sich auf Schnittstellen und Verbindungselemente zwischen den Komponenten der Produktarchitektur ab. Dieses Kapitel zeigt, wie die Produktarchitektur erstellt und wie sie für die Koordination der Zusammenarbeit bei Entwicklung, Integration und Test genutzt wird.

Risikomanagement

Anforderungslisten sind geduldig und enthalten oft Forderungen, deren Machbarkeit aufgrund des begrenzten Budgets oder physikalisch fraglich ist. Die Aufgabe des Systems Engineers im Entwicklungsprojekt besteht im Erkennen und Aufzeigen dieser Risiken zum frühestmöglichen Zeitpunkt. Die hierbei eingesetzten Methoden und Vorgehensweisen sind Gegenstand dieses Kapitels.

Agilität im SE

Kommentar

Tailoring

Kommentar