Donnerstag Abend, eine typische Studentenparty in Essen (oder wahlweise mal wieder eine Kneipentour durch den SOL Square in Christchurch, NZ). Die übliche Frage: „Und, was studierst Du?“ – „Englisch und Sport auf Lehramt, und Du?“ – „Systems Engineering.“ – „Ah…“ [Verständnisloser Blick]
Aber ich dachte, der Hanno studiert irgendwas mit Computern?
Ich hab jetzt schon ein paar mal das Wort „Systemingenieur“ ,verwendet. Denn so sehe ich mich. Ich bin (oder „werde, wenn ich mal groß bin“) kein Informatiker, sondern ein Ingenieur. Was ist ein Ingenieur? Ein Ingenieur löst Probleme. Nicht ganz so wie Mr. Wolf („Ich bin Mr Wolf. Ich löse Probleme.“). Es ist ein bisschen wie das bekannte Zitat von Ashleigh Brilliant: „I don’t have any solution, but I certainly admire the problem “:. „Bewundern“ bedeutet allerdings: Erstmal schaut man sich das Problem sehr genau an, und versucht, es zu verstehen. Warum existiert es, WER hat überhaupt ein Problem. Ein klassisches Problem für einen „klassischen“ Ingenieur ist eine Schlucht. An sich erstmal kein Problem. Aber wenn jemand rüber will, ists halt schon eins. Naja, dann bauen wir halt ne Brücke rüber, klare Sache. Aber bevor irgend ein Bauingenieur anfängt, eine Brücke zu konstruieren, muss er erstmal jede Menge Fragen stellen und das Problem verstehen: Wer will rüber? Wie oft? Was will er alles mitnehmen? Und nicht ganz unwichtig ist auch: Wie tief ist die Schlucht, wie breit, und wie ist der Untergrund auf den beiden Seiten? Besonders unterschiedlich davon ist die Situation bei einem Computersystem eigentlich nicht. Ein neuer Geldautomat? Na klar! Für drinnen oder draußen? Nur EC-Karten oder auch Kreditkarten? Quittungsdrucker? Mehrsprachige Benutzerführung? Vielleicht akustische Benutzerführung für Blinde? Diese Phase bezeichnet der erfahrene Systemingenieur als Requirements Engineering: Anforderungserhebung.
<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } A:link { so-language: zxx } –>Jetzt ist man in einem so großen Projekt wie beim Brückenbau selten allein. Die Anforderungen müssen also auch noch niedergelegt werden. Am besten so, dass man hinterher noch was damit anfangen kann, und nicht nur man selbst, sondern auch die anderen Beteiligten. Weitere Stolperfalle: Anforderungen bleiben seltenst die ganze Zeit über gleich, sie müssen während der gesamten Projektlaufzeit gut beobachtet und „gemanaged“ werden. Vielleicht soll auf einmal auch eine Bahnlinie über die Brücke verlaufen, zusätzlich zu den Autos? Oder die Sicherheitslage verschärft sich und die Brücke muss stabil genug für Kampfpanzer werden. Oder der Geldautomat soll nach China exportiert werden können und daher Schrift von rechts nach links darzustellen in der Lage sein.
Der nächste Schritt ist dann die Konstruktion. Man kann natürlich einfach anfangen, ein paar Stahlträger zusammenzuschweißen und sich langsam in die Schlucht hineinzutasten. Wird schon irgendwie klappen. Deutlich geschickter ist es aber doch, erstmal ein paar Sachen durchzurechnen, ein Modell zu bauen, es im Windkanal zu testen, einen recht genauen Plan aufzustellen, den dann zu überprüfen und zu verfeinern und ihn DANN umzusetzen. Same goes with Programmen: Es gibt die verschiedensten Möglichkeiten, ein Programm zu konstruieren, ohne es direkt zu programmieren. Für fast jeden (un)denkbaren Aspekt gibt es Modellierungsarten und Diagrammformen. Vom Entity-Relationship-Modell für Datenstrukturen, über Datenflussdiagramme, Ereignisgesteuerte Prozessketten, Komponentendiagramme, Petri-Netze, Endliche Zustandsautomaten bis hin zu UML-Nachrichtendiagrammen oder UML-Klassendiagrammen. Einen großen Unterschied zwischen Programmen und Brücken gibt es aber schon: Während es bei Brücken schwierig bis unmöglich ist, das Ergebnis eines einmal realisierten Plans automatisch zu verändern wenn sich der Plan ändert, geht das bei Programmen schon. Zumindest theoretisch. Es kommt ganz darauf an, wie man die gemachten Pläne nutzt. Man kann schön gezeichnete UML-Diagramme ausdrucken und einem Programmierer in die Hand drücken, der setzt sie dann in Code um, ganz so wie der Stahlarbeiter die Brücke nach den Blaupausen zusammenschweißt. Man könnte aber auch aus den Diagrammen automatisch Quellcode generieren lassen, den groben Rahmen und die Struktur des Programms, und diese dann von Programmieren mit sinnvollen Erweiterungen anreichern lassen. Dingen, die man in einem Diagramm nicht darstellen kann, Aspekte, die beim Modellieren der Abstraktion zum Opfer gefallen sind. Und wenn alles so funktionieren würde, wie es sollte, dann könnten einige dieser Änderungen sich auch wieder automatisch in den Diagrammen wiederfinden. Jedenfalls könnte man bei den vorher angesprochenen Änderungen in den Anforderungen einfach das Modell ändern und die Änderungen dann in den Programmcode einfließen lassen. Klingt das nur für mich günstiger und schneller, als alles von vornherein in kryptischen Code zu gießen, den man nur umständlich ändern kann? Tatsächlich ist einiges hiervon nicht ganz so einfach umzusetzen, wie es klingt und die Toolunterstützung (also die Hilfe durch Programme, die helfen sollen, Programme zu bauen) hinkt an vielen Stellen den Visionären Ideen des Software Engineering hinterher.
Zwei weitere Vorteile haben Diagramme und Modelle: Man kann sie besser überprüfen und Testen als fertige Programme, bei denen alle möglichen Eventualitäten ausprobiert werden müssen. Das ist nämlich der nächste Schritt nach der Umsetzung der Pläne, also der Programmierung, das Testing. Bei Brücken ist das nicht ganz so offensichtlich, wird aber sicherlich auch betrieben. Schon während des Baus werden immer wieder Messungen durchgeführt, um festzustellen, ob das, was da gebaut wird, auch dem entspricht, was man sich vorher überlegt hat. In diesem Punkte sind die „klassischen“ Bauingenieure einen Schritt voraus. Testing dieser Art wird nämlich bei der Programmentwicklung heutzutage immer noch häufig sträflich vernachlässigt.
Der zweite Vorteil ist die Dokumentation. Selten entwickelt man ein Programm nur für sich selbt. Häufig sollen Schaaren von Menschen hinterher damit arbeiten, und sei es nur, um zu überprüfen, ob auch alles richtig funktioniert. Ein Bild sagt häufig mehr als tausend Worte, und so sind die Konstruktionsmodelle ein guter Ausgangspunkt für die Programmdokumentation und Hilfedateien, die den Benutzern den Umgang und die Funktionsweise erklären sollen.
Ich habe während dieser Ausführungen den Eindruck erweckt, als ob all die Punkte einzelne Schritte sind die, hintereinandergereiht, zum gewünschten Ergebnis führen. Doch hier ist noch ein Unterschied zum Brückenbau: Man kann alles gleichzeitig machen! Nachdem die ersten Anforderungen erhoben worden sind, kann die Konstruktion des Modells beginnen und vielleicht sogar schon ein erster kleiner Prototyp programmiert werden, der auf die gewünschten Funktionalitäten getestet wird. Währenddessen können aber weitere Anforderungen erhoben werden und in die Konstruktion und die Umsetzung einfließen. Wenn alles so läuft wie es sollte, dann „… Isse Kreislauf!“. Daher kommt auch die manchmal gebrauchte Bezeichnung Lifecycle Management.
Bei all dem muss man immer auch berücksichtigen, dass das entwickelte System eigentlich niemals für sich alleine steht, sondern fast immer mit anderen Systemen zusammenarbeitet. Passender Spruch hier: „Every System is someone’s subsystem“. Die Verbindungen mit diesen anderen Systemen, die sogenannten Interfaces, müssen daher auch genau festgelegt, gebaut, beachtet und getestet werden. Dann kann man das entwickelte System auch Jahre später noch nutzen oder weiterentwickeln, anstatt ständig wieder von vorne anfangen zu müssen.
Es ist jetzt keineswegs so, dass sich das alles auf die Entwicklung reiner Software beschränkt. Zunächst mal steckt „soft“ware heutzutage fast überall, in Autos, Geldautomaten, nem Herd, Spielzeug, Handy, der Jalousiesteuerung oder dem bekannten PC. Praktisch immer muss auch jemand damit arbeiten, nämlich ein Mensch! Dieser spielt daher beim Systems Engineering eine wichtige Rolle. Die Arbeitsabläufe, in denen das neue System teilhaben soll, müssen gut verstanden sein, sonst ist es am Ende im besten Fall überflüssig, im schlechtesten Fall eine Mehrbelastung, statt eine Erleichterung und Hilfe. Hinzu kommen noch die rein physikalisch-technischen Aspekte auf der Hardware-Seite. Aber die überlass ich gerne den Maschinenbau- oder Elektroingenieuren. Während die auf ihr Gebiet spezialisiert sind, sind wir sozusagen Spezialisten fürs Ganze (nicht etwa „für Alles“), die Zusammenarbeit der Einzelteile und nach Außen.
So, zu den ganzen Methoden und Modellen werfe man nun noch eine geballte Ladung theoretisches Hintergrundwissen (die tatsächliche „Informatik“: Zustandsautomaten, Markov-Ketten, Turing-Maschinen, blabla), ein bisschen aufgeblasene BWL (sieht nach viel aus, fällt aber in sich Zusammen wie Zuckerwatte. Nur nicht ganz so süß), sperrige Mathematik (hat man dran zu knabbern und liegt schwer im Magen), eine Priese Projektmanagement, einen Hauch (nur nicht zu viel, sonst verschluckt man sich dran!) von praktischem Projekt und wissenschaftlicher Arbeit sowie in meinem Fall zum aufpeppen noch jede Menge nahrhafte und abgefahrene Netzwerkkurse, rühre um und fertig ist der frischgebackene Bachelor Of Science Angewandte Informatik – Systems Engineering.
Aber versuch mal, das alles nach 2-3 Bier auf ner Party zur erklären, während im Hintergrund Lady Gaga quäkt und der Mob tobt.
Nein, lass es lieber. Hat eh keinen Zweck. Also die schnelle Methode:
„Der Studiengang heißt komplett ‚Angewandte Informatik – Systems Engineering’…“ – „Ah, Informatik, alles klar!“. Zack, Stempel drauf, ab in die Klischee-Schublade. Herzlichen Glückwunsch.
Jetzt ist man in einem so großen Projekt wie beim Brückenbau selten allein. Die Anforderungen müssen also auch noch niedergelegt werden. Am besten so, dass man hinterher noch was damit anfangen kann, und nicht nur man selbst, sondern auch die anderen Beteiligten. Weitere Stolperfalle: Anforderungen bleiben seltenst die ganze Zeit über gleich, sie müssen während der gesamten Projektlaufzeit gut beobachtet und „gemanaged“ werden. Vielleicht soll auf einmal auch eine Bahnlinie über die Brücke verlaufen, zusätzlich zu den Autos? Oder die Sicherheitslage verschärft sich und die Brücke muss stabil genug für Kampfpanzer werden. Oder der Geldautomat soll nach China exportiert werden können und daher Schrift von rechts nach links darzustellen in der Lage sein.
Der nächste Schritt ist dann die Konstruktion. Man kann natürlich einfach anfangen, ein paar Stahlträger zusammenzuschweißen und sich langsam in die Schlucht hineinzutasten. Wird schon irgendwie klappen. Deutlich geschickter ist es aber doch, erstmal ein paar Sachen durchzurechnen, ein Modell zu bauen, es im Windkanal zu testen, einen recht genauen Plan aufzustellen, den dann zu überprüfen und zu verfeinern und ihn DANN umzusetzen. Same goes with Programmen: Es gibt die verschiedensten Möglichkeiten, ein Programm zu konstruieren, ohne es direkt zu programmieren. Für fast jeden (un)denkbaren Aspekt gibt es Modellierungsarten und Diagrammformen. Vom Entity-Relationship-Modell für Datenstrukturen, über Datenflussdiagramme, Ereignisgesteuerte Prozessketten, Komponentendiagramme, Petri-Netze, Endliche Zustandsautomaten bis hin zu UML-Nachrichtendiagrammen oder UML-Klassendiagrammen. Einen großen Unterschied zwischen Programmen und Brücken gibt es aber schon: Während es bei Brücken schwierig bis unmöglich ist, das Ergebnis eines einmal realisierten Plans automatisch zu verändern wenn sich der Plan ändert, geht das bei Programmen schon. Zumindest theoretisch. Es kommt ganz darauf an, wie man die gemachten Pläne nutzt. Man kann schön gezeichnete UML-Diagramme ausdrucken und einem Programmierer in die Hand drücken, der setzt sie dann in Code um, ganz so wie der Stahlarbeiter die Brücke nach den Blaupausen zusammenschweißt. Man könnte aber auch aus den Diagrammen automatisch Quellcode generieren lassen, den groben Rahmen und die Struktur des Programms, und diese dann von Programmieren mit sinnvollen Erweiterungen anreichern lassen. Dingen, die man in einem Diagramm nicht darstellen kann, Aspekte, die beim Modellieren der Abstraktion zum Opfer gefallen sind. Und wenn alles so funktionieren würde, wie es sollte, dann könnten einige dieser Änderungen sich auch wieder automatisch in den Diagrammen wiederfinden. Jedenfalls könnte man bei den vorher angesprochenen Änderungen in den Anforderungen einfach das Modell ändern und die Änderungen dann in den Programmcode einfließen lassen. Klingt das nur für mich günstiger und schneller, als alles von vornherein in kryptischen Code zu gießen, den man nur umständlich ändern kann? Tatsächlich ist einiges hiervon nicht ganz so einfach umzusetzen, wie es klingt und die Toolunterstützung (also die Hilfe durch Programme, die helfen sollen, Programme zu bauen) hinkt an vielen Stellen den Visionären Ideen des Software Engineering hinterher.
Zwei weitere Vorteile haben Diagramme und Modelle: Man kann sie besser überprüfen und Testen als fertige Programme, bei denen alle möglichen Eventualitäten ausprobiert werden müssen. Das ist nämlich der nächste Schritt nach der Umsetzung der Pläne, also der Programmierung, das Testing. Bei Brücken ist das nicht ganz so offensichtlich, wird aber sicherlich auch betrieben. Schon während des Baus werden immer wieder Messungen durchgeführt, um festzustellen, ob das, was da gebaut wird, auch dem entspricht, was man sich vorher überlegt hat. In diesem Punkte sind die „klassischen“ Bauingenieure einen Schritt voraus. Testing dieser Art wird nämlich bei der Programmentwicklung heutzutage immer noch häufig sträflich vernachlässigt.
Der zweite Vorteil ist die Dokumentation. Selten entwickelt man ein Programm nur für sich selbt. Häufig sollen Schaaren von Menschen hinterher damit arbeiten, und sei es nur, um zu überprüfen, ob auch alles richtig funktioniert. Ein Bild sagt häufig mehr als tausend Worte, und so sind die Konstruktionsmodelle ein guter Ausgangspunkt für die Programmdokumentation und Hilfedateien, die den Benutzern den Umgang und die Funktionsweise erklären sollen.
Ich habe während dieser Ausführungen den Eindruck erweckt, als ob all die Punkte einzelne Schritte sind die, hintereinandergereiht, zum gewünschten Ergebnis führen. Doch hier ist noch ein Unterschied zum Brückenbau: Man kann alles gleichzeitig machen! Nachdem die ersten Anforderungen erhoben worden sind, kann die Konstruktion des Modells beginnen und vielleicht sogar schon ein erster kleiner Prototyp programmiert werden, der auf die gewünschten Funktionalitäten getestet wird. Währenddessen können aber weitere Anforderungen erhoben werden und in die Konstruktion und die Umsetzung einfließen. Wenn alles so läuft wie es sollte, dann „… Isse Kreislauf!“. Daher kommt auch die manchmal gebrauchte Bezeichnung Lifecycle Management.
Bei all dem muss man immer auch berücksichtigen, dass das entwickelte System eigentlich niemals für sich alleine steht, sondern fast immer mit anderen Systemen zusammenarbeitet. Passender Spruch hier: „Every System is someone’s subsystem“. Die Verbindungen mit diesen anderen Systemen, die sogenannten Interfaces, müssen daher auch genau festgelegt, gebaut, beachtet und getestet werden. Dann kann man das entwickelte System auch Jahre später noch nutzen oder weiterentwickeln, anstatt ständig wieder von vorne anfangen zu müssen.
Es ist jetzt keineswegs so, dass sich das alles auf die Entwicklung reiner Software beschränkt. Zunächst mal steckt „soft“ware heutzutage fast überall, in Autos, Geldautomaten, nem Herd, Spielzeug, Handy, der Jalousiesteuerung oder dem bekannten PC. Praktisch immer muss auch jemand damit arbeiten, nämlich ein Mensch! Dieser spielt daher beim Systems Engineering eine wichtige Rolle. Die Arbeitsabläufe, in denen das neue System teilhaben soll, müssen gut verstanden sein, sonst ist es am Ende im besten Fall überflüssig, im schlechtesten Fall eine Mehrbelastung, statt eine Erleichterung und Hilfe. Hinzu kommen noch die rein physikalisch-technischen Aspekte auf der Hardware-Seite. Aber die überlass ich gerne den Maschinenbau- oder Elektroingenieuren. Während die auf ihr Gebiet spezialisiert sind, sind wir sozusagen Spezialisten fürs Ganze (nicht etwa „für Alles“), die Zusammenarbeit der Einzelteile und nach Außen.
So, zu den ganzen Methoden und Modellen werfe man nun noch eine geballte Ladung theoretisches Hintergrundwissen (die tatsächliche „Informatik“: Zustandsautomaten, Markov-Ketten, Turing-Maschinen, blabla), ein bisschen aufgeblasene BWL (sieht nach viel aus, fällt aber in sich Zusammen wie Zuckerwatte. Nur nicht ganz so süß), sperrige Mathematik (hat man dran zu knabbern und liegt schwer im Magen), eine Priese Projektmanagement, einen Hauch (nur nicht zu viel, sonst verschluckt man sich dran!) von praktischem Projekt und wissenschaftlicher Arbeit sowie in meinem Fall zum aufpeppen noch jede Menge nahrhafte und abgefahrene Netzwerkkurse, rühre um und fertig ist der frischgebackene Bachelor Of Science Angewandte Informatik – Systems Engineering.
Aber versuch mal, das alles nach 2-3 Bier auf ner Party zur erklären, während im Hintergrund Lady Gaga quäkt und der Mob tobt.
Nein, lass es lieber. Hat eh keinen Zweck. Also die schnelle Methode:
„Der Studiengang heißt komplett ‚Angewandte Informatik – Systems Engineering’…“ – „Ah, Informatik, alles klar!“. Zack, Stempel drauf, ab in die Klischee-Schublade. Herzlichen Glückwunsch.
Filed under: Allgemein, Fiehlohsoh-Fisch-Ess on Mai 17th, 2010 | No Comments »
