Dieser Gastartikel ist ein Beitrag zum ScienceBlogs Blog-Schreibwettbewerb. Alle eingereichten Beiträge werden im Lauf des Septembers hier im Blog vorgestellt. Danach werden sie von einer Jury bewertet. Aber auch alle Leserinnen und Leser können mitmachen. Wie ihr eure Wertung abgeben könnt, erfahrt ihr hier.
Dieser Beitrag wurde von Markus eingereicht.
———————————————————————————————————————–
Wenn jemand erfährt, dass ich im Fachbereich Softwaretechnik
(oder im Englischen "Software Engineering") meine Doktorarbeit
geschrieben habe, dann wird das meistens mit einem "Aha." und einem freundlichen
Lächeln quittiert. Ich vermute, dass die betreffende Person das dann abheftet
unter "Hat was mit Computern zu tun" und sich gegebenenfalls vornimmt
auf mich zurück zu kommen, wenn der eigene Rechner mal wieder streikt. Im
Zusammenhang mit dieser Wahrnehmung soll der berühmte Informatiker Edsger W.
Dijkstra mal gesagt haben "Computer Science is no more about computers
than astronomy is about telescopes". (Die Informatik hat mit Computern nur
so viel zu tun wie Astronomie mit Teleskopen.) Unabhängig davon ob diese
Zuschreibung nun stimmt oder Folklore ist, verdeutlicht der Satz ein Problem,
das vermutlich viele Berufe haben: Die Allgemeinheit hat ein eher vages Bild
davon, was jemand, der diesen Beruf ausübt eigentlich so macht. Florian hat in
den vergangen Jahren hier viel, viel geschrieben, durch das ich eine Menge über
Astronomie lernen konnte. Und es hat sich dabei eher selten explizit um
Teleskope gedreht. Nun möchte ich für die Softwaretechnik einmal versuchen,
einen kleinen Einblick in diese Disziplin zu geben. Und dabei wird es praktisch
gar nicht um Computer gehen…
Womit beschäftigt sich die Softwaretechnik eigentlich?
Kurz gesagt beschäftigt sich Softwaretechnik mit der
ingenieursmäßigen Entwicklung von Software. (Mit dieser Definition ist man auch
ganz nah dran an der englischen Bezeichnung Software Engineering.) Das ist ganz
ähnlich wie bei anderen Ingenieursberufen. Maschinenbauingenieure beschäftigen
sich mit dem Entwurf und der Konstruktion von Maschinen und industriellen
Anlagen. Bauingenieure kümmern sich um die Planung und den Bau von Gebäuden.
Und Softwaretechniker oder Softwareingenieure entwerfen und entwickeln
Software. Nun ist bei industriellen Anlagen oder Hochhäusern für jeden
einsichtig, dass man Experten benötigt um sowas zu konstruieren. Seinen
Gartenschuppen zimmert vielleicht noch ein jeder auf eigene Faust zusammen.
Aber bei größeren Projekten lässt man das lieber die Profis machen. Um zu
verstehen, warum es sinnvoll und sogar notwendig ist, das bei Software genauso zu
handhaben, muss man zunächst ein wenig über Software und deren Entwicklung im
Allgemeinen wissen.
Warum ist das sinnvoll?
Software steckt längt nicht nur dort, wo es offensichtlich
ist, also in Desktop-Rechnern, Tablet-Computern, Spielkonsolen, Handys, usw.
Mittlerweile steckt in fast jedem Gerät, das einen elektronischen Anteil hat
auch ein Stückchen Software: Kaffeemaschinen, Kühlschränke, Ampelanlagen,
Armbanduhren, Klimaanlagen, und so weiter. Das gilt auch und vor allem für
Autos und für Flugzeuge. Seit Ende der Achtziger Jahre haben Passagiermaschinen
in den meisten Fällen kein mechanisches Notfallsystem für die Steuerung mehr an
Bord. Das heißt die Steuerklappen sind nicht mehr über Stahlseile, Schubstangen
oder Ähnliches mit dem Steuerknüppel im Cockpit verbunden. Alles funktioniert
rein elektronisch mit der Hilfe von Software. Und in modernen Autos stecken
hunderte von eingebetteten „Controllern“. Kleinstrechnern, die bestimmte
Funktionen steuern: Elektrische Fensterheber, Bremsen, Airbags, ESP… Wenn man
sich das vor Augen führt, dann wird schnell klar, dass die Software, die in
diesen Geräten läuft besser gut funktionieren sollte. Damit stellt sich
automatisch die nächste Frage: Ist es eigentlich schwierig korrekt
funktionierende Software zu entwickeln? Und wenn ja, warum?
Warum ist Softwareentwicklung schwierig?
Software wird in den allermeisten Fällen geschrieben. Man
schreibt ein Programm, das der Computer dann ausführen kann. Das hat
Ähnlichkeit mit einem Kochrezept. Zum Beispiel „Öffne Datei X. Suche darin Wert
Y. Zeige Y zusammen mit Ausgabe Z auf dem Bildschirm an.“ Das klingt erstmal
recht simpel, aber es gibt viele Faktoren, die das Schreiben solcher Rezepte
erschweren. Zum Beispiel Interaktivität, Komplexität und Größe:
Interaktivität
Allerdings braucht man schon noch ein bisschen mehr
Flexibilität als bei Kochrezepten, denn Software ist meist darauf ausgelegt,
dass sie interaktiv ist, dass sie also auf Eingaben des Benutzers reagieren
kann. Daher ist es notwendig Verzweigungen in das Programm einzubauen. „Wenn
der Benutzer hier klickt, dann mache dies. Wenn er dort klickt, dann mache
das.“ Und auch Wiederholungen, Schleifen genannt, sind notwendig. Schließlich
soll der Benutzer auch mehrmals klicken dürfen. Da man vorher nicht weiß, wie der
Benutzer genau mit dem Programm interagiert, muss man sich vorher genau
Gedanken machen, was das Programm alles ermöglichen, erlauben, und verbieten
soll. Das kann manchmal eine ganze Menge sein. Allein wenn man sich die
Iconleisten von gängigen Schreibprogrammen ansieht, dann kann der Benutzer zu
jedem beliebigen Zeitpunkt alles Mögliche anstellen. Und die Software muss in
jedem Fall damit umgehen können.
Komplexität
In eingebetteten Systemen wie Autos wird das Ganze noch
komplizierter: Die Klimaanlage muss geregelt werden, das Navigationssystem muss
ständig überprüfen, ob der Fahrer sich auf der geplanten Route befindet, das
Entertainmentsystem läuft nebenbei und dann kommt plötzlich eine Vollbremsung!
In so einem Moment möchte niemand, dass der Airbag zu spät aufgeht, weil das
Navigationssystem vorher noch eine neue Route berechnen musste. Diese ganzen
Vorgänge müssen also aufeinander abgestimmt sein. Und das ohne das man vorher
weiß, welche Situationen genau auftreten werden.
Größe
Ein kompliziertes Kochrezept erstreckt sich über ein bis zwei Seiten im
Kochbuch und besteht damit aus 50 bis 100 Zeilen Text. Komplexe Software kommt
allerdings schnell auf mehrere Millionen Zeilen Programmcode. Das entspricht
eher einer Zahl von 100000 Seiten Text. Bei diesen Zahlen wird schnell klar,
dass niemand sich ein Programm einfach komplett durchlesen kann um zu
überprüfen was es tut oder ob es fehlerfrei ist. (Abgesehen davon ist
Programmcode kein Prosatext, denn man einfach „runterlesen“ kann.) Dazu kommt
noch das Problem, dass so ein ausgedrucktes Programm linear ist. Es fängt auf
Seite 1 oben an und endet unten auf Seite 1000000. Das kann man (mit viel Zeit)
zwar durchlesen, wird damit dem Ablauf der Software aber nicht gerecht. Die
oben erwähnten Schleifen müsste man mehrmals lesen, bei Verzweigungen („Wenn
dies passiert, dann tue das, sonst mach etwas anderes.“) müsste man wild im
Dokument hin und her springen. Und dadurch würde man blitzschnell die Übersicht
verlieren, was man schon gelesen hat, und was nicht.
Was kann man dagegen tun?
Es ist also nicht so leicht eine funktionierende,
komplexe Software zu entwickeln. Deswegen versucht die Softwaretechnikforschung
Werkzeuge und Methoden zu finden, die die Entwicklung von Software erleichtern.
Die Ansätze dazu kann man grob in konstruktive und analytische Verfahren
unterteilen. Konstruktive Ansätze beschäftigen sich damit, wie man Software
leichter entwickeln kann, so dass sie von Anfang an möglichst korrekt
funktioniert. Dabei geht es darum Mittel und Wege zu finden, die die oben
angesprochenen Probleme wie Größe, Komplexität und Interaktivität abschwächen
und sie damit möglichst gar nicht erst zu Problemen werden lassen. Analytische
Verfahren hingegen konzentrieren sich darauf, Fehler und Probleme in bereits entwickelter
Software zu entdecken.
Konstruktive Verfahren
Wenn der Mensch vor einer schwierigen Aufgabe steht, dann
tendiert er, sich Werkzeuge zu schaffen, die die Aufgabe erleichtern. Das ist
in der Softwaretechnik nicht anders. Software wird nicht in einem einfachen
Texteditor oder in einem Textverarbeitungsprogramm geschrieben, sondern
mithilfe einer Entwicklungsumgebung. Die enthält zwar auch einen Editor, aber
zusätzlich jede Menge Hilfsmittel. Sie prüft den Programmcode auf
offensichtliche Fehler (z.B. falsch geschriebene Wörter), bietet eine Übersicht
über die Struktur des kompletten Programms und hat Funktionen zur
nachträglichen Anpassung und Veränderung der Software. Die Konzipierung,
Entwicklung und Erweiterung solcher Entwicklungsumgebungen ist ein Teil der
konstruktiven Softwaretechnik.
Es gibt auch Werkzeuge, mit denen man erst einmal die
grobe Struktur oder das Verhalten seiner Software in einem Diagramm modellieren
kann. Dadurch behält man einen besseren Überblick und muss nicht zunächst nicht
um die Details kümmern. Es gibt auch Standards, die vorschreiben, wie so ein
Diagramm auszusehen hat. Dadurch haben Softwaretechniker eine gemeinsame
„Sprache“ zur Verfügung mit der sie sich über Ideen und Konzepte für eine
Software austauschen können. Und im Idealfall kann man den Programmcode aus
diesen Diagrammen zumindest teilweise generieren lassen. Das erspart einerseits
viel Arbeit und vermeidet andererseits auch viele Fehler, die man sonst beim
Selberschreiben machen würde.
Analytische Verfahren
Die einfachste Möglichkeit zur Überprüfung einer Software
ist das Testen. Man startet einfach das Programm und probiert aus, ob es das
tut, was man erwartet. Allerdings kann man sich leicht klarmachen, dass man
niemals ein Programm vollständig testen kann. Wenn ich beispielsweise eine
einfaches Taschenrechnerprogramm schreibe, wie es bei vielen Betriebssystemen
mitgeliefert wird, dann kann ich nicht alle möglichen Rechnungen
durchprobieren, um zu überprüfen, dass die Ergebnisse immer stimmen. Dazu gibt
es einfach zu viele Möglichkeiten. (Im streng mathematischen Sinne sind es
sogar unendlich viele. Warum das hier nicht ganz zutrifft, ist ein anderes
Thema) Ich könnte aber jede Funktion (Addition, Subtraktion, Multiplikation,
Division, Potenz, Wurzel, usw.) jeweils einmal ausprobieren und zumindest dafür
sicherstellen, dass alle Ergebnisse stimmen. Über die Entwicklung und Umsetzung
von solchen Teststrategien gibt es ganze Tagungsreihen.
Man kann an das Problem auch etwas mathematischer
herangehen. Zu jedem beliebigen Zeitpunkt seiner Ausführung hat ein Programm
einen „Zustand“. Der ist charakterisiert durch die aktuell gespeicherten Werte
(beim Taschenrechner z.B. die eingegebenen Zahlen und die ausgewählte
Operation) und den Punkt an dem das Programm gerade angekommen ist (z.B. kurz
bevor der Benutzer auf die „=“-Taste drückt. Jetzt kann man versuchen sich alle
diese Zustände zu überlegen und für jeden Zustand zu prüfen, was als nächstes
passieren kann. Wenn z.B. die gewählte Operation die Division ist und die zweite
Zahl eine Null, dann sollte das Programm danach den Teil ausführen wollen, der
dem Benutzer einen Fehler anzeigt. Wenn es das nicht tut, dann erreicht das
Programm einen unerwünschten Zustand und man hat ein Problem gefunden. Diese
theoretische Betrachtungsweise wird Verifikation genannt. Im Vergleich zum
Testen kann man mit ihr beweisen, dass ein Programm fehlerfrei ist (das es also
nicht in einen unerwünschten Zustand gerät). Aber dafür ist das Verfahren auch
so kompliziert, dass man es nicht für komplette, komplexe Programme durchführen
kann, sondern allenfalls für kleinere Teile.
Und weiter?
Das ist er also, mein erster Blogeintrag. Ich habe versucht
einen kleinen Einblick in die weite Welt der Softwaretechnik zu geben. Mir ist
bewusst, dass ich viele Themen nur sehr oberflächlich gestreift habe und vieles
ausgelassen oder sehr vereinfacht dargestellt habe. Ich habe keine Ahnung, ob das Thema von
Interesse ist, ob ich einen guten Abstraktionsgrad erwischt habe und ob
irgendjemand bis zu diesem Punkt lesen wird. Daher brauche ich euer Feedback: Was
hat euch gefallen und was nicht? Würdet ihr gerne mehr lesen? Zu welchen
Themen? Ich bin sehr gespannt auf eure Kommentare, Anregungen und Fragen.
Hallo Markus,
ein schöner Artikel, da ich selbst Informatiker bin lässt sich das mit dem Abstraktionsgrad leider nur schwer einschätzen, aber ich glaube er war genau richtig. Keine übertriebenen Vereinfachungen, aber trotzdem alles anschaulich erklärt. Dazu: flüssiger Schreibstil, es lässt sich sehr schön und leicht lesen.
Ein kleiner Kritikpunkt: Der Artikel hat keinen richtigen Schlussteil, du springst direkt von Testverfahren / Verifikation zu „Das war also mein erster Artikel…“. Mir hätte da jetzt nochmal eine thematische Zusammenfassung gefehlt, oder das Wiederaufgreifen eines Beispiels von oben, um den Artikel abzurunden.
Markus, davon würde ich sehr gerne mehr lesen!
Ich habe eine Frage. Inwiefern unterscheidet sich Softwaretechnik von Softwarearchtiktur? Hab grad einen Knopf im Hirn 😉
Schön schreiben Ursula! Softwarearchitektur…
Leider hat Till inhaltlich genau das geschrieben, was ich auch anmerken wollte.
Inhaltlich finde ich als Informatikerin und der praktischen Softwaretechnik nahestehende das Thema sehr interessant, klar. Aber ich weiß auch, dass die meisten Nicht-Informatiker (nicht einmal It-Techniker) viel über den Prozess und die Werkzeuge etc. der Softwareentwicklung wissen, daher ist das ein guter Überblick.
Ich denke, für die durchschnittlichen Blogleser *hier* ist die Abstrahierung grade richtig – meiner Meinung nach allgemeinverständlich, aber doch nicht zu vereinfachend.
Aber auch für mich kommt das Ende zu plötzlich. Es liest sich, als hättest du mittendrin abgebrochen hättest, weil das Telefon klingelte oder so… 😉
Schön geschriebener Text, gefällt mir, nicht nur weil ich selber ein wenig „Ahnung“ von dem Bereich habe (Softwaretechnik 1 und 2…) 😉
„Ich vermute, dass die betreffende Person das dann abheftet unter „Hat was mit Computern zu tun“ und sich gegebenenfalls vornimmt auf mich zurück zu kommen, wenn der eigene Rechner mal wieder streikt.“
Wie oft muss ich mir anhören „Ah, dann kannst du ja demnächst xy (setze etwas ein dass einen Stecker hat) reparieren“ wenn jemand hört dass ich Elektrotechnik studiert habe. Erwähne ich dann noch dass ich auch Informationstechnik studiert habe, hängt man mir noch abenteuerlichere Sachen an und ist pikiert wenn ich erwähne dass ich all das nicht gelernt habe. „Aber du hast das doch studiert!?!?“
„Da man vorher nicht weiß, wie der Benutzer genau mit dem Programm interagiert, muss man sich vorher genau Gedanken machen, was das Programm alles ermöglichen, erlauben, und verbieten soll.“
Und wenn man das erste Mal während der Entwicklungsphase einen unvoreingenommenen Benutzer vor das Programm setzt entdeckt man auf welch faszinierende Art derjenige seine Aktionen und Eingaben kombiniert und dass man all das nicht vorher gesehen hat.
> Und in modernen Autos stecken hunderte von eingebetteten „Controllern“. Kleinstrechnern, die bestimmte Funktionen steuern: Elektrische Fensterheber, Bremsen, Airbags, ESP… Wenn man sich das vor Augen führt, dann wird schnell klar, dass die Software, die in diesen Geräten läuft besser gut funktionieren sollte.
Bei so viel Software, die in einem Auto steckt sollte es eine Selbstverständlickeit sein, dass das mit einen jeden Neuwagen ausgelieferte Handbuch auch genau das ausgelieferte Modell beschreibt.
Doch letzte Woche habe wieder eine ziemlich dicke Schwarte erhalten, in der alles Mögliche drinnen steht. Was jetzt für mein Auto zutrifft darf ich mir selbst zusammen suchen.
Schande über die Software Ingenieure!
Entweder hab ich die Ironie überlesen oder was genau hat jetzt der Softwareingenieur (oder auch jeder andere Entwickler) damit zu tun dass die Hersteller allgemeine Handbücher rausgeben?
Gut gefallen haben mir die Kapiteleinleitungen mit Fragen, das macht Laune weiterzulesen. Für mich verwirrend war dann dein Schwenk auf eine zweite Hierarchieebene im hinteren Teil. Bei so kurzen Texten würde ich den Stil nicht ändern.
Sonst sehr gute Zusammenfassung der Thematik. Man merkt du hast dir darüber ‚echt‘ Gedanken gemacht, hättest den Doktor also gar nicht erwähnen müssen 🙂
Das hab selbst ich als simple EDV-Trainerin für Senioren – mit einem ziemlich niederschwelligen Angebot – erfahren.
„Ich hab nur eine kleine Frage…“ war ein üblicher Gesprächsanfang, der mich mit der Zeit innerlich regelmäßig zusammenzucken ließ.
@Karl Mistelberger
Bei einer Führung durch das Mercedes-Benz-Werk wurde einem Bekannten meiner Schwiegereltern erzählt, dass nur jeder dreihunderttausendste Wagen dem anderen in allen Merkmalen gleicht, weil man heute so viele verschiedene Merkmale zu- oder abwählen kann.
Kannst Du Dir vorstellen, wie komplex es wird, wenn jedem Fahrzeug genau das Handbuch beigelegt wird, das exakt sein Auto beschreibt? Als Computerausdruck oder PDF wäre so was ohne weiteres machbar, aber die Handbücher werden ja nicht einzeln, sondern in den üblichen Verfahren des Massendrucks (Offset etc.) hergestellt und maschinell sortiert und gebunden, und die sind halt nur dann handhabbar und bezahlbar, wenn man eine große Menge des gleichen Handbuchs druckt.
Dafür können also die (Software-)Ingenieure eigentlich am wenigsten.
@Markus
An sich (sprachlich, flüssig, verständlich) schön geschrieben, aber eigentlich ist das Thema viel zu komplex für einen kurzen Blogartikel, man kann die wichtigsten Begriffe gerade mal streifen (das Wort „objektorientiert“ kommt z.B. gar nicht vor). Ich weiß nicht, ob da viel Information zum Leser fließen kann, oder ob das Thema am Ende sehr vage bleibt.
Ich hatte mich mal daran gesetzt, einen Artikel für Florian zum Thema „Mein erstes Teleskop“ zu schreiben, und der wurde dann immer länger und länger, weil es da einfach zu viel zu sagen gibt über die verschiedenen Teleskope, ihre Vor- und Nachteile, Montierungen, Zubehör etc., bis ich das Vorhaben abbrach. Man hätte mindestens 4 oder 5 Artikel daraus machen müssen, und ich kann Florians Blog ja nicht derart vereinnahmen.
@Alderamin: „Man hätte mindestens 4 oder 5 Artikel daraus machen müssen, und ich kann Florians Blog ja nicht derart vereinnahmen.“
WIe wärs mit nem eigenen Blog?
Bzw. könnte sowas schon mal als Gastartikel-Serie erscheinen. Da ich selbst eher wenig Ahnung von Instrumenten habe, wäre das ne schöne Ergänzung.
So auf die Schnelle fällt mir kaum ein Thema ein für das dies nicht gelten kann. Ich bin immer dankbar, wenn wer trotz des Verkürzungsproblems schreibt.
@Florian
Für einen eigenen Blog hab‘ ich nicht wirklich die Zeit (bei mir stapeln sich im Moment die Bücher, die ich gerne lesen würde, und noch die Sky&Telescopes der letzten drei Monate).
Aber den Artikel kann ich gerne zu Ende schreiben, wenn Du den bringen möchtest, das wäre vielleicht was für die Zeit vor Weihnachten.
@Alderamin: Gerne!
@Ursula
Wenn man das Thema hinreichend einschränkt, dann geht fast alles. Z.B. könnte ich mir vorstellen, dass man die Grundidee der Objektorientierung durchaus in einem kurzen Blogartikel unterbringen kann. In dem Artikel gestern nachmittag war ja auch nur speziell von Rost beim Stahlbetonbau die Rede, das passte gut in einen kurzen Artikel. Ein Artikel über Bauingenieurwesen schlechthin wäre hingegen vermutlich zu oberflächlich gewesen.
Na ja, vielleicht sehe ich das auch nur so, weil ich selbst Informatiker bin, und dann empfinde ich es halt als „nur das Thema streifend“ weil ich zu viel darüber weiß.
@Alderamin & Markus: Gerne (mehr) Artikel von Euch!
Gegenwärtig entwickel ich auch wieder mit einer Entwicklungsumgebung (IDE; sonst meist nur vi(m)). Man kann meinen Widerwillen in puncto IDEs rauslesen, denn ihre Komplexität erschlägt mich. Daher interessiert mich der Standpunkt der Softwaretechniker zum Aspekt Komplexität durch den Versuch Komplexität zu reduzieren (nicht nur in Bezug auf IDEs) besonders. Es wäre schön das mal fachkundig erörtert zu sehen.
#10, Alderamin, 11. September 2014
> Kannst Du Dir vorstellen, wie komplex es wird, wenn jedem Fahrzeug genau das Handbuch beigelegt wird, das exakt sein Auto beschreibt?
Das Handbuch muß ja nicht komplexer sein als das Auto selbst. Da kann man ohne wesentlichen zusätzlichen Aufwand auch ein PDF dazu erstellen. Für die neue Versicherung habe ich vor ein paar Minuten die gefühlt 77-stellige Nummer des Altvertrags in den Browser eingegeben.
Ich würde nicht davor zurück schrecken, die Fahrgestellnummer einzugeben, um eine Papierkopie des Handbuchs für das Handschuhfach zugeschickt zu bekommen. Wenn ich nicht gerade unterwegs bin und was nachschlagen will mache ich das lieber am Bildschirm als in der finsteren Garage.
Ein Handbuch für einen modernen Verkehrsjet umfasst viele Millionen Seiten. Wenn die Leute bei Airbus oder Boeing nachschlagen, haben sie doch auch einen Browser, wo sie exakt das Modell beschrieben finden, das sie gerade in den Fingern haben.
Hallo Markus,
danke für den interessanten Artikel. Ich fand es als Nichtfachmann einen spannenden Einblick und gut verständlich.
Als Grafiker habe ich mir allenfalls immer mal einige kleine Skripte gebaut (AppleScript), und fand das immer wahnsinnig spannend. Ich erinner mich gut an die Aufregung und die unglaubliche Freude, wenn das Skript endlich machte was ich wollte (dann hallte ein lautes YESS!!! durchs Büro und die Kollegen fragten, ob alles in Ordnung wäre mit mir ; )
Diese Erfolgserlebnisse waren schon was ganz besonderes und ich konnte zumindest ansatzweise verstehen, was einen Hacker umtreibt.
Ich merkte aber auch, dass ich schnell an meine Grenzen stieß – obwohl ich eine Ahnung hatte, wie das Programm logischerweise funktionieren müsste, habe ich die Umsetzung etwas komplexerer Vorgänge nicht hinbekommen und musste dann doch auf manuelle Fleißarbeit zurückgreifen.
Jedenfalls habe ich Hacker und Programmierer immer beneidet und wünschte manchmal, ich hätte selbst sowas gelernt, aber dafür war ich leider nie gut genug in Mathe bzw. mathematisch/logischem Denken.
Der Artikel hätte meinetwegen noch ausführlicher sein können (dann wäre es aber wohl auf eine kleine Artikelserie hinausgelaufen). Und es ist als Autor sicher schwer, abzuschätzen wo man den Leser abholt und wie komplex/abstrakt es werden darf. Ich finde, du hast das gut gelöst, aber das Ende kam dann auch für mich etwas überraschend, und ich hätte gern noch etwas mehr erfahren.
Kleine Anekdoten finde ich auch immer gut, so wie zB. die von Pippilotta:
Eine Frage noch, Markus: ist diese ursprüngliche Lust am Programmieren/Hacken immer noch vorhanden, wenn man das zum Beruf macht? (Ich könnte mir vorstellen, dass es auch sehr ermüdende Tätigkeiten in dem Rahmen gibt). Programmierst du auch privat aus Spaß an der Sache?
viele Grüße
Dampier
@ Alderamin
Ja klar, sind viele Artikel „nur das Thema streifend“, kann aber – wenn gut geschrieben – für den Leser Gusto auf mehr machen. So bin ich z. B. durch einen sehr allgemein gehaltenen Artikel über Astronomie auf Astrodicticum-Simplex gestoßen, und lese schon Jahre begeistert mit. Ich weiß aber aus eigener Erfahrung
wie schwer die Überlegung ist „verflixt nochmal, was kann ich weg lassen?“ Klar, wenn man selbst vom Fach ist, desto kritischer wird man als Leser. Geht mir nicht anders.
Interessanter und gut geschriebener Artikel! Gut verständlich, hätte aber gerne noch etwas länger sein können – wobei zu lange Blogartikel vielleicht dann doch wiederum abschreckend wirken könnten?
Ich habe mal einige Zeit in einem kleineren Unternehmen an der Schnittstelle zwischen der Entwicklungs- und der Produktivabteilung gearbeitet und da eine Menge lustige Sachen erlebt…
Ich musste einerseits die Bedürfnisse der Leute, die mit der neuen Software arbeiten sollten den Softwareentwicklern vermitteln und andererseits die neue Software und ihre Funktionen testen und den zukünftigen Anwendern erklären.
Bei diesen Tests sind dann Sachen passiert, auf die man vorher unmöglich gekommen wäre, unfassbare „Fehlbedienungen“. Speziell ein Mitarbeiter war für diese Tests echt Gold wert. Er war unser DAU, nach einiger Zeit nannte er sich dann selbstironisch auch so und machte seinem Namen wirklich alle Ehre. Niemand konnte ein Programm mit solcher Sicherheit zum Absturz bringen wie er 😉 .
Toller Artikel! Du formulierst sehr klar und verständlich. Das gefällt mir sehr gut!
Jetzt weiss ich auch ungefähr, was Software Ingenieure so machen. 🙂
Würde gern mehr davon lesen!
Ich fand den Artikel auch gut – zumindest hat er es geschafft, dass ich ihn bis zum Ende gelesen habe und das hatte ich mir bei diesem Thema nicht gedacht. Der Text war aber immer interessant. Ich hätte aber vermutlich probiert, das ganze Konzept anhand eines konkreten und tatsächlich existierenden Beispielprogramms zu erklären.
Bevor da was falsch hängen bleibt: ich fand ja auch, dass er gut geschrieben ist.
Da ich ja mal wieder zu langsam gelesen habe, und alles Lob schon verteilt wurde — wie wäre es denn mit Folgeartikeln?
(Ja, macht den Autoren Arbeit, und ist eigentlich nicht der Sinn dieses Blogs – aaaaber … ?)
Eigentlich würde ich zu allen bisher erschienen Wettbewerbsartikeln gern eine Fortsetzung lesen.
@ tina
Grins, schöne Geschichte über „deinen“ DAU. Es gibt sie wirklich diese speziellen Spezialisten. 🙂
Hui, ich bin gerade etwas sprachlos. Der Artikel ist gerade heute morgen live gegangen und schon so viele Kommentare. Und noch dazu so viel Zuspruch. Vielen Dank! (Und gerne mehr davon ;-)) Ich habe mal versucht, die einzelnen aufgekommenen Fragen angemessen zu beantworten.
@Ursula: Softwarearchitektur würde ich als einen Teilbereich der Softwaretechnik beschreiben, nämlich den Teilbereich, bei dem es um den groben Aufbau der Software geht. Vergleichbar ist das vielleicht mit dem Grundriss eines Hauses. Da sieht man auch, wo die Zimmer sind, zum Teil auch welche Funktion sie haben (Eingangsbereich, Küche, Bad…). Aber das reicht noch nicht, um das Haus zu bauen. Eine Softwarearchitektur beschreibt aus welchen groben Komponenten die Software besteht (Grafische Oberfläche, Datenbankanbindung, Komponente zur Berechnung der Ergebnisse…). Aber die Details fehlen noch. Welche Algorithmen braucht man? Wie soll die Benutzeroberfläche gestaltet werden? Die Architektur ist wichtig für die Planung und um einen Überblick zu bekommen. Aber sie ist nur ein Schritt auf dem Weg zum Ziel.
@Karl Mistelberger: Stimmt, die Software in einem Auto sollte besser funktionieren. Und wenn sie das tut, dann muss darüber auch gar nichts im Handbuch stehen. Da sollte vielleicht stehen, was der Airbag ist, wann er auslöst und wie man ihn ggf. abschaltet. Aber welche Software das übernimmt ist für den Fahrer eigentlich irrelevant. Vermutlich stammt auch die Dokumentation des Wagens gar nicht von den Ingenieuren selber. Ich wüsste allerdings auch gerade nicht, welches Berufsbild für das Erstellen technischer Dokumentationen zuständig ist… Softwaretechniker machen das jedenfalls meines Wissens nicht.
@Alderamin: Ja, so ähnlich ging es mir auch. Der Text wurde immer länger, ganze Unterkapitel sind wieder rausgeflogen, weil ich mich irgendwo „verquatscht“ habe. Und natürlich wird man der Komplexität des Themas in so einem kurzen Artikel nicht gerecht. Objektorientierung wäre bestimmt ein prima Thema für einen eigenen Artikel. Aber ich wollte schon irgendwie „vorne“ anfangen. Daher ja auch meine Abschlussfrage, ob irgendjemand Interesse hätte, mehr davon zu lesen. 🙂
@CM: Ein interessanter Vorschlag. Ich bin eher ein Nutzer von IDEs, kenne aber die Entwicklung im „reinen“ Editor wie vi nur flüchtig. Da könnte man fast ein „Streitgespräch“-Artikel draus machen…
@Dampier: Die von dir beschriebene Freude kann ich gut nachzuvollziehen. Wenn das Programm endlich das macht, was man sich vorgestellt hat, dann ist das schon ein tolles Gefühl. Ermüdend oder frustrierend finde ich persönlich die Phasen, die davor liegen. Wenn es einfach nicht laufen will, weil man etwas noch nicht richtig verstanden hat oder irgendwelche Fehler eingebaut hat. Wenn man da längere Zeit dransitzt, dann muss man schon manchmal einen langen Atem haben. Der Durchbruch ist dafür dann umso schöner. 🙂
@Florian: Wow, das Lob freut mich sehr! Das konkrete Beispiel ging mir auch im Kopf rum, aber irgendwie hat es nie so ganz gepasst und dann hab ich es aus Zeitgründen weggelassen. Für eine Version 2.0 wäre das aber ein klarer Wunschkandidat.
@Theres: Abwarten… Vielleicht ergibt sich ja etwas. Zumindest nachdenken darüber werde ich bei all dem netten Feedback mal.
Was ciele auch nicht verstehen: Der Software-Entwicklungsprozeß ist von der verwendeten Sprache völlig unabhängig.
Ob das Programm in Assembler oder JAVA geschrieben ist, spielt keine Rolle.
Und dann gibt es noch die Phasen Konzeptionierung, Architektur, Realisierung und Wartung, für die man jeweils eigene Spezialisten braucht.
Ich z.B. bin in der Wartung tätig. Meine Spezialität ist das Einarbeiten in fremden Code, das Nachstellen von Fehlern, das Debugging und das Bereitstellen eines Software-Updates.
Dafür braucht man ganz andere Talente und Kenntnisse als z.B. ein SW-Architekt.
@Uli: Stimmt genau. Programmiersprachen (Gemeinsamkeiten, Unterschiede, Warum zum Henker braucht man eigentlich mehr als eine?) und die Phasen des Softwareentwurfs (+ die verschiedenen Modelle wie Wasserfall, RUP, Agile, usw.) könnte man eigentlich auch wieder mit eigenen Artikeln würdigen.
Dabei war ich anfangs skeptisch, ob das Thema überhaupt für einen einzigen Beitrag reicht. 😉
Kleiner Nachtag: Für SW-Entwickler wie mich gibt es nichts Langweiligeres, als ein Programm, das fehlerlos funktioniert… 😉
@Uli/Markus
Ich würde sagen „jein“. Bei UML und OO wird doch schon im Design etwas anders vorgegangen als bei klassischen iterativen Sprachen. Der Grundansatz, Wasserfall-Modell, Rapid Prototyping o.ä. gilt natürlich in beiden Fällen.
@Markus: Ab und zu wurde ich gefragt, warum es eigentlich vier lange Jahre dauert, bis man mit so einem Informatikstudium fertig ist.
Dabei hat man in vier Jahren gerade mal die Zeit, sich in zwei Spezialgebieten etwas zu vertiefen. Die GANZE Informatik in allen Bereichen 100% drauf zu haben, ist völlig unmöglich.
Es fällt einem nur im Laufe der Jahre immer mehr auf, wie wenig Ahnung von Computern die ganzen Nicht-Informatiker haben. Insbesondere, wenn sie als Programmierer arbeiten…
@Markus: Ein Flamewar war nicht meine Intention! Davon gibt es genug …
vi hat für mich schlicht Berechtigung – manchmal aber auch nicht. Es ist ein komplexer Editor und an sich schon eine Hürde für Newbies. Mental ist diese Hürde für viele bei IDEs geringer (Graphische Benutzeroberfläche), aber die Komplexität ist (nicht selten) so groß, dass sie ebenfalls eine Hürde darstellt – dann aber kann sie Entwicklung beschleunigen. Diesen Komplexitätstradeoff finde ich irgendwie interessant zu beleuchten.
@CM: Die Sache mit dem „Streitgespräch“ war im positiven Sinne gemeint. Ich will genauso wenig einen Flamewar anzetteln. Aber ein Beitrag, in dem beide Seiten ihre Sichtweisen darlegen, wäre doch interessant.
In Programmen, die ich bislang so geschrieben habe, waren über 99% der Schleifen nicht nötig, damit der Benutzer mehrmals klicken kann und in über 99% der Fälle, in denen ermöglicht wurde, dass der User mehrfach irgendwo klicken kann musste ich dafür keine Schleife schreiben. Allerdings hat dann jmd. anderes die Schleife schon geschrieben gehabt und ich habe den Event-Dispatching-Thread der JVM benutzt, der die Wiederholung organisierte.
Sehr viel häufiger sieht die Verwendung von Schleifen so aus, dass man, um eine Operation durchzuführen, diese in sehr viele ähnliche, kleinere Operationen zu zerlegt – diese nacheinander abzuspulen dient die Schleife. Beispiel: Man möchte alle Bilder eines Verzeichnisses schrumpfen. Also iteriert man über alle Bilder und ruft für jedes einzelne den Befehl auf, der es verkleinert.
Oder man will einen Absatz fetten. Das Programm nimmt also jedes Zeichen des Absatzes und fettet jedes einzeln ein.
@Stefan Wagner: Stimmt. An der Stelle hinkt der Vergleich mit dem Klicken. Ich hatte wohl genau solche Event-Dispatcher im Hinterkopf, als ich über die Schleifen schrieb. Aber das ist natürlich konzeptionell schon wieder ganz schön speziell für so eine Übersicht. Deine Erklärung ist da auf jeden Fall besser.
> #17, CM, 11. September 2014
> Gegenwärtig entwickel ich auch wieder mit einer Entwicklungsumgebung (IDE; sonst meist nur vi(m)). Man kann meinen Widerwillen in puncto IDEs rauslesen, denn ihre Komplexität erschlägt mich. Daher interessiert mich der Standpunkt der Softwaretechniker zum Aspekt Komplexität durch den Versuch Komplexität zu reduzieren (nicht nur in Bezug auf IDEs) besonders. Es wäre schön das mal fachkundig erörtert zu sehen.
IDE ist Glückssache. Nicht alles, was sich IDE schimpft ist auch im Kontext eine solche.
Die Erfahrung war trotz fortgeschrittenen Alters (50+) perfekt, denn Ericcson hat eine konzernweite Lösung basierend auf ClearCase/ClearCase Multisite. Man öffnet z.B. unter Windows ein Fenster irgendwo in einem Entwicklungszentrum auf der Welt und kann sofort loslegen, ohne sich technischen Kram merken zu müssen, Hauptsache, man weiss, welches Handy oder sonstiges Gerät man befummeln will.
Die Erstellung der Firmware ist dann nur ein Knopfdruck und wenn alles geklappt hat lädt ein weiterer Knopfdruck die Firmware über einen Lauterbach auf das Handy und man kann die Änderungen sofort am Gerät ausprobieren. Einfacher geht es nicht.
Entscheidend war die konzerninterne Entwicklung einer eigenen auf ClearCase basierenden Applikation, denn ohne eine solche ist ClearCase das ideale Tool für Experten, um sich ins Knie zu schiessen. 🙂
> #27, Markus, 11. September 2014
> Stimmt, die Software in einem Auto sollte besser funktionieren. Und wenn sie das tut, dann muss darüber auch gar nichts im Handbuch stehen.
Nur zur Verdeutlichung: Ich will gar nichts über die Software wissen. Ich habe nur den bescheidenen Wunsch geäußert, dass das Handbuch genau das Auto beschreibt, wie es in meiner Garage steht und sonst nichts. Software-Menschen ist dieser einfache Wunsch offensichtlich gar nicht so einfach zu vermitteln.
Um noch deutlicher zu werden: Es sollen nicht tausend Komponenten beschrieben werden, die in meinem Auto gar nicht vorhanden sind sondern ausschließlich das Zeugs, das auch tatsächlich eingebaut ist.
@Karl Mistelberger: OK, vielleicht habe ich Sie missverstanden. Das Erzeugen eines „passgenauen“ Handbuchs für ein spezifisches Fahrzeug auf Basis der Seriennummer des Wagens ist natürlich prinzipiell vorstellbar. Und das per Software zu erreichen ist auch gar nicht mal so komplex. Ich vermute allerdings, dass die Hersteller nicht auf eine Druckversion des Handbuch verzichten wollen (oder können, evtl. gibt es da Vorschriften?). Und das Drucken und Beilegen der individualisierten Handbücher dürfte dann wohl zu teuer sein.
Wie man an den Kommentaren von Karl Mistelberger sieht, und ich auch regelmäßig selbst feststelle, wenn ich Fachfremden erzähle, was ich als Software-Engineer mache, denke ich, dass es für die meisten interessanter ist folgende Punkte zu beleuchten: Warum funktioniert Software gerade meistens dann nicht korrekt, wenn ich sie dringend brauche? Warum wird Software nie rechtzeitig fertiggestellt? Warum ist Software nie so dass man sie intuitiv benutzen kann? Warum sind die Anleitungen so unverständlich?
Ich meine damit nicht die Software in einem Flugzeug oder einem Satelitten. Sondern die Software mit der jeder täglich zu kämpfen hat: Das krude Enterprise Tool das man gezwungen ist auf Arbeit zu nutzen. Die Mikrowelle im Aufwnthaltsraum, dessen Bedienung Glückspiel ist, der digitale Videorekorder der genau dann abstürzt, wenn er was wichtiges aufnehmen soll.
Da muss ich mir oft die Frage stellen lassen warum das so ist. Und zurecht. Das hat aber wenig mit Engineering zu tun. Software-Engineering ist genauso Engineering wie Brücken bauen nur mit deutlich weniger Erfahrung. Die Tools die wir benutzen sind da wenig interessant für Fachfremde. Viel interessanter ist da der Faktor Menach, die Psychologie, das Management. Leider ist das bei den Software-Engineers selber noch nicht überall angekommen. Das merkt man bspw. daran, wenn versucht wird oben genannte Probleme mit mehr Tools oder mehr Spezifikationen zu lösen.
@Weltraumschaf
Ach, Du meinst den hier:
https://www.uidesign.at/wp-content/uploads/2007/05/treeswing_enlarged.gif
Mein täglich Brot. Spezifikationen mit „etc.“ drin. Um „etc.“ gibt es nachher die endlosen Diskussionen. Kann teuer werden und lange dauern.
@Weltraumschaf
Ich glaube, da lappt es schon ins Philosophische …
Das könnte man auch unter „Tücke des Objekts“ einordnen, sprich, das betrifft ja nicht nur Software, sondern auch Geräte und Vorgänge aller Art. Es ist auch eine Sache der Wahrnehmung: Warum kommt der Bus jedesmal vorbei, wenn ich zum Gemüsehändler gehe, aber nie, wenn ich auf ihn warte? etc. …
Ich denke, das trifft auf Großprojekte aller Art zu, auch hier passt der Vergleich mit Architektur, siehe BER, Elbphilharmonie etc. Ich denke, dass es daran liegt, dass die Vorab-Einschätzung des Aufwands grundsätzlich zu optimistisch ist. Das mag unter anderem mit der Gestaltung von Ausschreibungen zu tun haben, wer da zu realistisch rangeht, wird den Job nie bekommen. Außerdem werden Deadlines nach meiner Erfahrung sehr willkürlich gesetzt, und das gleich zu Anfang. Statt zu sagen: wir gehen das an, und wenn ein Ende abzusehen ist, legen wir den Termin für den Rollout fest, wird der Endtermin ganz am Anfang festgelegt. Nachher muss er dann mehrfach verschoben werden und ist trotzdem nur mit wahnwitzigen Nachtschichten zu schaffen (die natürlich auch die Qualität des Endprodukts beeinträchtigen – nichts ist frustrierender als ein Projekt aus Zeitmangel suboptimal abschließen zu müssen, obwohl man weiß, wo noch der Wurm drin ist). Ich denke, das ist häufig auch einfach Wichtigtuerei auf Seiten des Auftraggebers.
Da habe ich andere Erfahrungen gemacht, zumindest das „nie“ ist mir zu kategorisch. Es gibt duchaus programme, die ich mir spielerisch selbst beigebracht habe (in meinem Fall Grafikprogramme, z.B. der gute alte FreeHand, Gott hab ihn selig), und andere, wie Illustrator (das heute leider alleiniger Standard ist) mit dem ich nach Jahren immer noch auf Kriegsfuss stehe. Interessanterweise ging es anderen genau umgekehrt, also liegt es vielleicht daran, dass die Intuition jedes einzelnen etwas anders ist und man den Begriff ‚intuitiv‘ nicht verallgemeinern oder gar standardisieren kann.
Seit ich selbst Anleitungen schreibe (ich baue Grafik-Templates, die andere grafiker benutzen sollen, um z.B. verschiedene Werbemittel zu erstellen), kann ich das schon sehr gut nachvollziehen. Ich weiß oft gar nicht, wer da am ‚anderen ende‘ sitzt, also für wen ich die Anleitung genau schreibe, was hat der für ein Vorwissen, wo muss ich den abholen? Soll ich bei Adam und Eva anfangen? Dann fühlt sich der Profi möglicherweise verarscht. Soll ich es kurz und knapp machen? Dann kommen viele überhaupt nicht mehr mit …
Das kann man sicher in gewisser Weise standardisieren, aber je weiter gefasst die Zielgruppe ist, desto schwieriger wird es, alle mitzunehmen.
Mich würde noch die Frage interessieren: Warum haben neue Versionen einer Software oft zig neue Features, die keiner braucht (bzw. ich nicht ;), aber Kinderkrankheiten wie dieser eine völlig unlogische Menüeintrag (der genau das Gegenteil von dem macht, was da steht) zieht sich durch alle Versionen und wird ums verrecken nicht repariert? Das frustriert manchmal unheimlich, da bekomme ich schon Fantasien manchmal, dass ich gern alle verantwortlichen Softwarearchitekten kidnappen und einkerkern würde, bis sie mir das schlüssig erklärt und versrochen haben, es sofort zu verbessern!
*g*
grz
Dampier
Was ich als ebenfalls promovierter Informatiker einwerfen möchte: Gerade die Softwaretechnik krankt an mangelnder Wissenschaftlichkeit. Gerade wenn es in den Bereich der kommerziellen „General-Purpose“ Softwareentwicklung geht, dann gibt es nur selten brauchbare Theorien (d.h. solche, die Vorhersagen machen) und noch seltener Empirie. Das geht dann oft schon ins esoterische, weil man sich auf anekdotische Erfahrungen stützt (ich tue mich selbst schwer mich davon zu lösen). Beispiele sind Entwurfsmuster, Entwicklungsprozesse, Programmiersprachen, Umgebungen, Architekturen…
@Christoph: Du hast da nicht ganz Unrecht. Allerdings finde ich den pauschalen Vorwurf der mangelnden Wissenschaftlichkeit ein wenig übertrieben. Viele analytische Methoden (z.B. Verifikationsverfahren) sind sehr wohl wissenschaftlich fundiert und liefern zuverlässige und überprüfbare Ergebnisse.
Es ist aber auf jeden Fall richtig, dass vernünftige kontrollierte Experimente und Studien lange Zeit kaum durchgeführt wurden. Meiner Ansicht nach hat sich hier in den letzten 5 bis 10 Jahren aber einiges getan. Spontan fällt mir hier zum Beispiel die Forschung von Lutz Prechelt ein. Es ist mittlerweile auch deutlich schwieriger Konferenzbeiträge akzeptiert zu bekommen, wenn keine vernünftige Evaluierung durchgeführt wurde.
@Markus
Danke für die anschauliche Erklärung Softwaretechnik – Softwarearchitektur!
„In so einem Moment möchte niemand, dass der Airbag zu spät aufgeht, weil das Navigationssystem vorher noch eine neue Route berechnen musste.“
„Einen Moment bitte … der Airbag wird gestartet … “ (Fortschrittsbalken hängt bei 99% ..)
🙂
Schöner, gut geschriebener Text, der für meiner Einer sogar durchaus etwas länger hätte sein dürfen.
Ich mag allerdings generell auch gerne längere, in die Tiefe gehende Blogartikel – aber das ist wohl Geschmackssache …
> #41, Dampier, 11. September 2014
>> Warum sind die Anleitungen so unverständlich?
> Seit ich selbst Anleitungen schreibe (ich baue Grafik-Templates, die andere Grafiker benutzen sollen, um z.B. verschiedene Werbemittel zu erstellen), kann ich das schon sehr gut nachvollziehen.
Ein lieber Kollege hat das so beschrieben („Mike’s Gesetz“): In Handbüchern steht genau das drinnen, was man sich auch ohne es denken kann. Wenn man etwas Bestimmtes wissen will, sucht man es vergeblich.
Ein konkretes Beispiel ist das Handbuch zum GPS-Gerät eTrex 30. Das enthält eine minutiöse Beschreibung aller Menüs. Die braucht es aber gar nicht, denn die Menüs kann man ja auf dem Bildschirm sehen und mehr steht auch im Handbuch nicht drinnen.
Wie das Ding verwendet werden kann steht aber nirgends. Das muß man selber heraus finden. Für meine Zwecke tun es folgende Handgriffe:
Beim Loslaufen: Einschalten > Trackmanager > aktuellen Track löschen
Am Ziel: Trackmanager > Aktuellen Track speichern > Ausschalten
Gelegentlich: In ausgeschaltetem Zustand an einen USB-Anschluss des PC anstecken und den Track-Ordner synchronisieren, Batterien aufladen
Einen entsprechenden Hinweis sucht man im ganzen Handbuch vergeblich. Trotz der einfachen Vorgehensweise geht das ganze nicht ohne Bug. Immer wieder kommt es vor, dass ein Track einen unsinnigen Punkt enthält, der nur mit Handarbeit am PC wieder gelöscht werden kann: Wenn das Gerät beim Löschen des aktuellen Tracks noch nicht die aktuelle Position ermittelt hat, konstruiert es klammheimlich einen Punkt bestehend aus dem neuen Zeitpunkt und den alten Koordinaten.
Auf diese Weise habe ich schon zu Fuß die phänomenale Geschwindigkeit von 45825 km/h erreicht. Das reicht locker um bis zum Mond zu fliegen. 🙂
@Karl
Mein aktuelles Navi hatte ich noch keine zwei Tage, da hatte ich schon zwei fette Bugs gefunden.
1. Beim Einschalten war die Orientierung vorne/hinten immer falsch, was mich zu einigen sinnlosen Wendemanövern brachte, bis ich mich daran gewöhnte.
2. Nach dem Auswählen der Hauptroute bekommt man (wegen Baustellen etc) ab und zu noch eine Auswahl an Ausweichrouten angezeigt. Leider kann man von den Alternativen dann keine auswählen, sondern nur die Hauptroute.
Navigon.
Und die Karten waren gefühlt drei Jahre alt, Update kostete extra. Nie wieder!
@Karl Mistelberger: Die von Ihnen beschriebenen Anleitungen kenne ich auch. Sie haben völlig recht, die helfen kein Stück weiter. Und sie zu schreiben macht auch überhaupt keinen Spaß. Die Ursache dafür ist m.E. einerseits, dass Dokumentation immer zum Schluss des Projekts gemacht wird, wenn eh keine Zeit mehr ist. Und andererseits liegt dass daran, dass sich die Autoren nicht in die Lage des späteren Anwenders versetzen, sondern einfach stumpf die Funktionalität runterschreiben. Dann stehen da Sätze drin wie „Um die Konfiguration anzulegen, klicken Sie auf Anlegen. Um die Konfiguration zu löschen, klicken Sie auf Löschen.“ |-(
@Markus: Stimmt, es gibt wissenschaftliche Bereiche (Formale Methoden, statische Analyse) – die siedle ich jedoch nicht wirklich in der Softwaretechnik an. Diese Abgrenzung deckt sich auch mit den Standardlehrbüchern wie Ludewig/Lichter oder Somerville.
In Deutschland ist das auch nicht, was an den Lehrstühlen für Softwaretechnik geforscht wird – Ausnahmen die mir einfallen sind Podelski und Zeller, zum Teil auch Prechelt.
Die Empirische Informatik konzentriert sich auf wenige Gruppen (Tichy in Karlsruhe – da ist auch der Prechelt her, Fraunhofer IESE, University of Maryland), daneben noch
ein paar einzelne Gruppen + DARPA und in der Vergangenheit IBM. Auch Google und Microsoft haben in letzter Zeit einiges veröffentlicht.
Mehr als Ansätze zur „aktiven“ Empirie (das gezielte Durchführen von Experimenten) sind das jedoch meist nicht: Die Untersuchungen z.B. zum Pair Programming in der Arbeitsgruppe Tichy waren alle extrem klein und wurde mit Studenten durchgeführt. Es stimmt, bei der Auswertung von Daten die ohnehin Anfallen (Issue Tracker, Source Control) gibt es spannende Wissenschaft (z.B. https://research.microsoft.com/pubs/70232/tr-2005-149.pdf). Aber das ist eben noch ein sehr kleiner Bereich.
@Markus
Ich denke, dass es den Anwender eben nicht gibt bzw. man ihn nicht kennt. Das ‚Reinversetzen‘ würde dann schon einen mittleren soziologischen Forschungsauftrag bedeuten.
Dazu kommt ein sprachlliches Problem: man soll zB. den Anwender nicht persönlich ansprechen in einer Anleitung („machen Sie das und das“). Allein dadurch muss man zum Teil wahnwitzige Satzkonstruktionen verwenden, um das zu umgehen, was der Verständlichkeit oft nicht gut tut. Meine ersten Anleitungen wurden denn auch von einem Texter nochmal in fürchterliches Werbedeutsch übersetzt, weil ich es gewagt hatte, relativ locker zu formulieren (von Profi zu Profi sozusagen). Das Endprodukt war dann ziemlich ernüchternd …
Hier können Blogs auch sehr hilfreich sein, oft habe ich von Bloggern weitaus bessere Anleitungen gelesen als vom Hersteller, da fragte ich mich oft, warum nicht gleich so?
Ich habe einen Kaminofen, ein wunderbares Gerät, aber die Anleitung ist grauenhaft und ich habe einen halben Winter gebraucht, bis ich das Ding richtig bedienen konnte. Da habe ich tatsächlich überlegt, mal selbst eine Anleitung für zu schreiben und online zu stellen.
grz
Dampier
> #48, Markus, 12. September 2014
> Die von Ihnen beschriebenen Anleitungen kenne ich auch. …
Dieses Mal gibt es offensichtlich keine Verständnisprobleme. 🙂
Dokumentation ist natürlich entscheidend, wenn es um mehr geht als den Weg nach Hause zu finden.
Ein positives Beispiel für Programmentwicklung geben die Leute vom LANL. Besonders das Team von MCNP fällt da äußerst angenehm auf.
Vor dem 11. September 2001 war alles im Web verfügbar. Heute schaut man sich die Leute schon an, bevor man das Programm weitergibt. Das verbliebene Material gibt trotzdem einen guten Einblick in die Programmentwicklung.
@Christoph: Ich finde die Abgrenzung, was zur Softwaretechnik gehört und was nicht, extrem schwierig. Vielleicht würde man intuitiv die Entwicklung von Verifikationsverfahren eher der theoretischen Informatik zuordnen. Aber wenn ich diese Verfahren dann in einen Model Checker gieße und zur Programmanalyse und -verifikation benutze, dann ist das in meinen Augen schon Softwaretechnik. Genauso kann man debattieren wo die Entwicklung von Programmier- und Modellierungssprachen noch Softwaretechnik ist und wann das eher zur Mensch-Maschine-Interaktion gehört. Die Klassifizierung und Benennung der Bereiche ist sowieso von Hochschule zu Hochschule unterschiedlich. Das ist wahrscheinlich zu großen Teilen auch Ansichtssache und nicht eindeutig klärbar. Ich würde aber die Anwendung von formalen Methoden keinesfalls als „Nicht zur Softwaretechnik gehörig“ bewerten.
Zur Anwendung von „aktiver Empirie“: Vielleicht braucht es noch ein wenig bis sich dieser Zweig richtig in der Softwaretechnik entwickelt. In der Medizin ist es selbstverständlich, dass kontrollierte Studien „der“ Goldstandard sind. In der Softwaretechnik gibt es dieses Bewusstsein m.E. nicht. Einerseits liegt das glaube ich an der Entwicklung der Informatik aus der Mathematik. Dort macht man keine Studien, weil man Theorien eben mathematisch beweisen oder widerlegen kann. Das gleiche gilt für die theoretische Informatik. Die Softwaretechnik als relativ junge Disziplin (der Ausdruck wurde erst 1968 geprägt, das renommierte SEI an der Carnegie Mellon existiert seit 1984) hat anscheinend noch nicht verinnerlicht, dass diese MIttel zur Bewertung ihrer Erkenntnisse ungeeignet sind.
Als zweiten Grund kann ich mir die andere Prägung der Disziplin die Ingenieurswissenschaften denken. Bei einem Bauprojekt kommt niemand darauf, das gleiche Gebäude zweimal nach unterschiedlichen Verfahren zu beurteilen, um danach zu bewerten, welches besser geeignet ist. Aufwand und Kosten werden hier als inakzeptabel angesehen. Für die Entwicklung von Software gilt das genauso. Niemand baut die gleiche Software mit zwei Teams unter kontrollierten Voraussetzungen zweimal um unterschiedliche Methoden zu vergleichen. Das wäre natürlich ein methodisch sauberer Weg, aber er wird (noch?) nicht als praktikabel angesehen. Das ist in der Medizin beispielsweise anders.
@Markus: Ich stimme Dir darin zu: In letzter Konsequenz könnte die Softwaretechnik auf die gesamte Informatik ausweiten – schliesslich gehts um Techniken und Methoden Software zu entwickeln. Ich gebe zu, dass meine Abgrenzung wahrscheintlich die engstmögliche ist und zum Teil auch sehr Deutsche ist: In den USA gibt es vielfach ja gar keine Professoren für „Softwaretechnik“. Dort werden die Softwareengineering-Vorlesungen oft von Leuten aus dem eher Formalen Umfeld (Programmiersprachen, Formale Methoden) gehalte: George Necula in Berkeley, Alex Aiken in Stanford, Michael Ernst in Washington etc. Vielfach existiert dort an den Hochschulen das Forschungsfeld so explizit auch nicht – was ich auch in Deutschland befürworten würde.
Das Problem die Informatik als Ganzes als Ingenieurwissenschaften zu begreifen scheitert meiner Ansicht nach: Die klassischen Ingenieurwissenschaften fussen auf soliden naturwissenschaftlichen Grundlagen. Die Entwurfsmethoden z.B. für eine Brücke kann ich auf der Basis dieser Grundlagen gegenüber anderen Entwurfsmethoden vergleichen.
Der Entwurf von Antennen hat solide Grundlagen in der Elektrodynamik. Teile der Informatik haben solche Grundlagen in der Mathematik. Dort sind die Grundlagen auch stärker als in der theoretischen Physik, weil wir ja keine Naturwissenschaft sind – dort sind wir die die Mathematik eine Strukturwissenschaft: Komplexitätsaussagen sind und bleiben richtig egal was da kommt.
Die Softwaretechnik im Allgemeinen (kleine Teilbereiche ja, da sind wir uns einig sind eine Ausnahme) taugt da aber nicht als Ingenieurwissenschaft auf der Basis dieses theoretischen Fundaments. Schlage ich ein Lehrbuch zur Softwaretechnik auf, dann finde so gut wie keine Bezüge zu den „soliden“ Grundlagen der Informatik. Schlage ich ein Lehrbuch zur Baustatik auf, dann ist das angewandte, klassische Mechanik (gut, der Bereich Bauprojektmanagement hat das gleiche Problem).
Ich denke die Disziplin Softwaretechnik scheitert schon daran, dass sie viel zu viele Bereiche abdecken will, die zu unterschiedlich sind:
– Projektmanagement, Entwicklungsprozesse, Entwicklungsmethoden: Das wäre im Grunde BWL mit etwas Soziologie. Und wir scheitern: Gestern war V-Modell und RUP, heute sind wir alle Agil. Bringt es irgendwas? Wir wissen es nicht. Das geht aber anderen Disziplinen wie Bau oder Maschinenbau nicht besser. Daher hat der Bereich imho auch in der Informatik selbst nichts zu suchen.
– Softwarearchitekturen, technische QS: Das wäre vom Anspruch her der ingenieurwissenschaftliche Teil, der aber wie gesagt an fehlenden Grundlagen und der fehlenden Empirie scheitert. Wie vorher argumentiert: Software Design Patterns haben keine Grundlagen, das statische und dynamische Verhalten einer Schrägseilbrücke (als ein Design/Architektur-pattern zur Konstruktion einer Brücke) kann ich berechnen. Auch viel Material ich benötige. Softwaredesignpatterns scheitern daran.
– Anforderungsmanagement + deren QS: Wahrscheinlich ein Querschnitt zwischen den ersten Beiden. Da gibt es auch jede Menge formalere Ansätze, die aber alle an der Industrie-Realität scheitern.
Ja, ich gebe zu ich mache es mir bequem: Meine Bereiche sind Programmiersprachen, Formale Methoden und Datenbanken/Informationesysteme. Ich habe zu einem theoretischen Datenbankthema promoviert (Ausdrucksstärke und Komplexität von Anfragesprachen). Natürlich könnte man sich auf den Standpunkt stellen, dass die Programmierspracheng-Community Forschung darüber betreiben soll, mit welcher Sprache die Programmierer effizienter sind. Aber dort beschäftigen wir uns halt lieber mit Typtheorie. Ich schiebe das halt bequem auf das Gebiet des „Softwaretechnik“ ab. Das mag gemein sein, trifft aber meiner Erfahrung nach das Selbstverständnis der Disziplin SE zumindest in Deutschland.
> #53, Christoph, 12. September 2014
> Und wir scheitern: Gestern war V-Modell und RUP, heute sind wir alle Agil. Bringt es irgendwas? Wir wissen es nicht.
Ob die einen jetzt den Rational Unified Process oder andere Disciplined Agile Delivery verwenden ist immer eine Frage der äußeren Umstände.
Ich kann jetzt nur zu einem Teil, dem Source Code Management etwas sagen. Bei Ericsson ist wie oben bereits erwähnt ClearCase/MultiSite sehr effizient implementiert. Ein leistungsfähiges ist eine der Voraussetzungen für die entscheidende Rolle von Ericsson auf dem Weltmarkt (40%).
Trotzdem beobachtet man die Entwicklung sehr genau: https://www.open.collab.net/media/pdfs/ClearCase-and-the-journey-to-Git.pdf
ClearCase deswegen als gescheitert zu betrachten wäre nicht zutreffend. Es hat sehr lange gute Dienste geleistet und hat etwas gebracht. Dass das „nebenher“ von Torvalds entworfene Git eine bedeutende Rolle in der Entwicklung spielt ist kein Zufall sondern liegt an den veränderten Randbedingungen.
Dass neue Prozesse und Werkzeuge vorwiegend industrienah und nicht an Universitäten entworfen werden liegt in der Natur der Sache. Es muss kontinuierlich produziert und geliefert werden. Wer da ins Stolpern gerät ist weg vom Fenster.
Ideen spielen aber dennoch einen große Rolle. Microsoft hatte große Erfolge auf dem Desktop und erreichte praktisch 100% Marktanteil. Bei den Smartphones sind es allerdings nur 2,5%: https://futurezone.at/b2b/marktanteile-android-gewinnt-apple-und-windows-verlieren/84.585.467
Android/Linux dagegen schlägt sich hervorragend und erschließt auch neue Märkte: https://futurezone.at/produkte/google-will-mit-billig-smartphones-aermere-laender-erobern/72.559.148
Offene Software hat einen wesentlichen Anteil daran. Wir alle profitieren von dem Trend, da nicht länger ein Monopolist sagt, wo es lang geht, sondern alle zu annähernd fairen Bedingungen mitmachen können.
Wir brauchen eine Wissenschaft vom Wünschen!
Letztlich geht es doch darum, sich über ein Bedürfnis ein solches Maß an Klarheit zu verschaffen, das das laute Aussprechen der Zauberformel den Wunsch erfüllt.
Der Volksmund sagt: „Leichter Gesagt als Getan“, aber stimmt das in diesem Fall wirklich?
@Uli
>>Es fällt einem nur im Laufe der Jahre immer mehr auf, wie wenig Ahnung von Computern die >>ganzen Nicht-Informatiker haben. Insbesondere, wenn sie als Programmierer arbeiten…
Ich gehe mal davon aus, dass du mit Nicht-Informatiker jetzt nicht einen Gärtner oder Schreiner meinst, sondern IT-Personal die kein Studium an einer FH oder Uni gemacht haben. Diese von „oben herab“ Aussagen kann ich nicht leiden.
Was ist den Ahnung von Computern? Du schreibst selbst, dass das Gebiet sehr groß ist und für jeden Teil spezielle Fähigkeiten und Talente notwendig sind.
Aber klar, der Programmierer ohne Studium der keinen Exchange konfigurieren kann hat halt nichts drauf. Der „richtige“ programmierende Informatiker kann es auch nicht, aber der hat sich halt spezialisiert und muss es auch nicht können. Oder gehört ein Exchange jetzt nicht zu „Ahnung von Computern“ :-).
Der Artikel hat mir nicht so gut gefallen.
@KeinDoktor @Uli: Ich finde die Aussage, dass jemand „Keine Ahnung von Computern“ hat zu undifferenziert. Damit kann alles Mögliche gemeint sein, vom Wissen über das Gerät an sich (die Hardware und ihre Funktionsweise) über das Wissen über bestimmte Programme (z.B. Exchange) bis hin zum Methodenwissen (z.B. Softwareentwicklung). Ein Studium vermittelt hauptsächlich Methodenwissen und beispielhaft Wissen über Werkzeuge zur Anwendung der Methoden. Daher kann es gut sein, dass ein studierter (oder wie du es ausdrückst „richtiger“) Informatiker weiß, wie ein bestimmter Algorithmus funktioniert, aber ihn nicht in C++ hinschreiben kann, weil er die Sprache nie gelernt hat. Hat der jetzt „keine Ahnung von Computern“?
Es ist wohl unmöglich Wissen über alle Werkzeuge, Methoden, Lösungen, Architekturen, usw. zu haben. Da hilft nur Spezialisierung. Idealerweise sollte man aber im Studium die Fähigkeit erworben haben, sich die speziellen Werkzeuge, die man in einer gegebenen Situation braucht, selber aneignen zu können.
Das heißt übrigens nicht, dass das eine Fähigkeit ist, die man nur durch ein Studium erwerben kann. Das kann m.E. jeder, der sich für ein bestimmtes Thema ausreichend interessiert. Das gilt doch auch für jeden Fachbereich. Ich habe z.B. nicht Astrophysik studiert, aber durch Florians Blog eine Menge über das Thema gelernt. Hätte ich genügend Interesse und Zeit, dann könnte ich mich weiter in das Thema einlesen und eine Menge Wissen erwerben, ohne Astrophysik zu studieren. An einem gewissen Punkt könnte ich dann auch behaupten „Ahnung“ von dem Thema zu haben. Und das hätte dann nicht damit zu tun, ob ich ein bestimmtes Teleskop richtig bedienen kann.
@KeinDoktor: Schade, dass dir der Artikel nicht gefallen hat. Könntest du das ein bisschen präzisieren? Was hat dir nicht gefallen? Was hättest du lieber gelesen?
Das ist ein sehr schön geschriebener Text über das Programmieren. Ich würde mir einen ganzen Blog wünschen, der ziemlich genau auf diese Weise regelmäßig das Programmieren erklärt.