1 Einleitung
Die Technik entwickelt sich vom Primitiven über das Komplizierte zum Einfachen. (Antoine de Saint-Exupéry)
1.1 Vorweg
»Früher war alles besser!«
»Früher war alles viel einfacher. Da konnte man noch mit einer Handvoll Leute etwas auf die Beine stellen. Heute sind es schnell hundert Leute, die man braucht, um ein ordentliches System zu entwickeln. Und die kriegen dann meist nichts auf die Reihe ... Denk doch nur mal an das Projekt P08/15. Dabei sind dort Experten aus allen Bereichen vertreten ...«
Wechselstimmung
Solche oder ähnliche Feierabendmonologe höre ich immer häufiger. Als Geschäftsführer eines Beratungsunternehmens treffe ich viele Personen aus den unterschiedlichsten Branchen. Der Tenor ist aber gleich. Woran liegt das? Ganz einfach: am Fortschritt.
Wir sind an einem Punkt angekommen, an dem komplexe und verteilte Systeme gefordert werden, die von komplexen und verteilten Organisationen entwickelt werden. Die herkömmlichen Entwicklungsmethoden sind aber noch nicht bereit, diese ausreichend schnell und in einem akzeptablen Kostenrahmen zur Verfügung zu stellen.
»Fortschritt ist unaufhaltsam.«
Wir können nicht erwarten, immer fortschrittlichere, größere, bessere Systeme zu entwickeln und dabei weiterhin dieselben Werkzeuge einzusetzen. Die Vorgehensweisen, Modellierungssprachen, Entwicklungsumgebungen und Rollen wie der Systems Engineer müssen an dem Fortschritt teilhaben und sich ebenfalls weiterentwickeln.
Von Bits zu Objekten
In der Softwareentwicklung ist dieser Weg an einem Beispiel deutlich zu sehen. Angefangen bei Lochkarten über Assembler, prozedurale Programmiersprachen bis hin zu den objektorientierten Sprachen kennen die Entwicklungswerkzeuge immer größere Bausteine (von Bits bis Klassen/Objekte). Sie erleichtern so die Beschreibung komplexer Systeme. Der Weg zur nächsten Generation ist bereits eingeschlagen: Die grafische Unified Modeling Language (UML™) oder domänenspezifische Sprachen (DSL) werden zunehmend verwendet, um Softwaresysteme zu entwickeln, und mit diesen Sprachen werden immer mehr Aufgaben gelöst, die vorher mit herkömmlichen Programmiersprachen erledigt wurden (Abb. 1.1).
Abbildung 1.1 Steigende Abstraktion der Programmiersprachen
1+1=3
Das Gesamtsystem ist mehr als die Summe seiner Bausteine. Die Wechselwirkungen zwischen den Elementen können komplex und schwer kontrollierbar sein. Das führt dazu, dass Vorgehensmodelle und Notationen benötigt werden, um effektiv diese Systeme entwickeln zu können. Ansonsten werden die Kosten der Entwicklung in naher Zukunft in keinem Verhältnis zum akzeptablen Preis der Produkte stehen.
Systems Engineering
Das Systems Engineering (Systementwicklung1) setzt sich schon länger mit dieser Problematik auseinander. Die Entwicklung großer Systeme, bei der viele unterschiedliche Disziplinen beteiligt sind, erfordert ganzheitliche Sichtweisen. Also losgelöst vom spezifischem Detailwissen werden die Anforderungen und Strukturen des Systems betrachtet, der gesamte Lebenszyklus von der Idee bis zur Entsorgung geplant, um insgesamt ein System zu entwickeln, das den Wünschen aller Beteiligten entspricht.
Modellbasiertes Systems Engineering (MBSE)
Im Systems Engineering fordert der Fortschritt einen Paradigmenwechsel: vom dokumentenzentrierten zum modellbasierten Systems Engineering (MBSE). Das Modell wird zur Quelle aller relevanten Informationen. Um gleich einem gängigen Missverständnis vorzugreifen: Die Dokumente sollen nicht verschwinden. Nur sind sie nicht mehr die Quelle der Informationen, sondern eine Sicht auf das Modell, beispielsweise automatisch erzeugt von einem Modellierungswerkzeug. Die Modellierungssprachen OMG Systems Modeling Language (OMG SysML™) und UML spielen in diesem Szenario natürlich eine wichtige Rolle.
Voneinander lernen
UML ⇒ S. 201
SysML ⇒ S. 309
INCOSE ⇒ S. 19
Die Softwareentwicklung kann viel vom Systems Engineering lernen. Zum Nehmen gehört aber auch ein Geben. Umgekehrt kann das Systems Engineering auch von der Softwareentwicklung lernen. Werkzeuge und Methoden zur Modellierung sind hier schon sehr weit entwickelt. Die UML ist eine Modellierungssprache aus diesem Umfeld. Sie hat sich als weltweiter Standard etabliert. Dem Systems Engineering fehlte bisher eine standardisierte Modellierungssprache. Das wird sich durch die neue SysML2 ändern. Sie basiert auf der UML und wird von führenden Unternehmen aus der Systems-Engineering-Branche einschließlich des International Council on Systems Engineering (INCOSE) unterstützt.
1.1.1 Passt das Buch zu mir?
Dieses Buch wird Sie interessieren und für Sie sehr hilfreich sein, wenn Sie ...
- die Modellierungssprache SysML lernen wollen,
- Systeme beschreiben, spezifizieren und entwickeln,
- mit komplexen Systemen arbeiten,
- Systems Engineering mit SysML durchführen wollen,
- Systeme mit gemischten Disziplinen – beispielsweise Software und Hardware – entwickeln,
- ein ganzheitliches Modell erstellen wollen, in dem Elemente nachvollziehbar zusammenhängen (Traceability),
- einen durchgängigen Weg von der Systemidee zum Systemdesign kennenlernen wollen.
Wenn Sie sich nicht in den obigen Punkten wiederfinden, fragen Sie mich, ob das Buch für Sie wertvoll sein könnte. Ich freue mich über eine E-Mail von Ihnen:
[email protected]. Werkzeugkasten SYSMOD
Sie lernen in diesem Buch einen Werkzeugkasten kennen, mit dessen Hilfe Sie einen Weg von der Idee eines Systems zur Architektur finden. Die Ergebnisse halten wir in detaillierten und aussagekräftigen Modellen fest. Die Modellierungssprache ist SysML. Der Werkzeugkasten heißt SYSMOD – abgeleitet von Systemmodellierungsprozess bzw. Systems Modeling Process.
1.1.2 Was bietet mir das Buch?
In diesem Buch finden Sie:
- den Werkzeugkasten SYSMOD zur Systementwicklung von der Systemidee zur Systemarchitektur,
- Steckbriefe zu den Werkzeugen, die Sie individuell zu einem Gesamtvorgehen zusammensetzen können – das Buch gibt Ihnen einen Standardweg vor,
- eine Beschreibung der SysML und UML,
- eine Einführung in das Systems Engineering,
- Randnotizen beispielsweise über Variantenmanagement, funktionale Architekturen, Simulation, Testen und Modellierungsmuster,
- Best Practices zu SysML und SYSMOD.
1.1.3 Wie ist das Buch entstanden? Und danke!
UML ohne Software
Die Idee zu diesem Buch hatte ich im Jahr 2003 bekommen. Zu dieser Zeit hatte ich viele Seminare und Beratungseinsätze zum Thema Analyse und Design mit der UML. Der Teilnehmerkreis konzentrierte sich auf Softwareentwickler – vom Programmierer bis zum Projektleiter. In einem Seminar hatte sich allerdings ein außergewöhnlicher Teilnehmerkreis zusammengefunden: Ingenieure, z. B. Nachrichtentechniker, aber kein einziger Softwareentwickler. Sie planten ein großes Projekt, das Software, aber auch bauliche Maßnahmen, Hardware und andere Disziplinen beinhaltete. In der Schulung habe ich den Softwareaspekt reduziert und die Analyse- und Designtechniken allgemeiner erläutert. Für die Teilnehmer hat sich hieraus eine hervorragende Vorgehensweise für ihr Projekt ergeben.
Diese Teilnehmerkonstellation war ab dann kein Einzelfall mehr. Es folgten weitere Seminare, Workshops und Beratungsaufträge, in denen keine Softwareentwickler, sondern Ingenieure aus anderen Disziplinen teilnahmen, die Analyse und Design mit der UML für ihre Arbeit kennenlernen wollten. In mir keimten zunehmend Fragestellungen, Ideen und weiterführende Überlegungen auf: Wie viel Software enthält eigentlich die UML? Wie beschreibe ich Anforderungen mit der UML? Wie gehe ich mit hybriden Systemen um? Mir wurde langsam bewusst, dass die Sprache UML und die Vorgehensweise in vielen Bereichen unabhängig von Software eingesetzt werden kann.
Systems Engineering und SysML
OMG ⇒...