StartseiteAstrodicticum Simplex

Was ist Softwaretechnik?

Von / 11. September 2014 / 58 Kommentare / Seite 3 von 3 / Auf einer Seite lesen
Mehr

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.

1 / 2 / 3
Stichworte: ,
Mehr

Kommentare (58)

  1. #1 Till
    11. September 2014

    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.

  2. #2 Ursula
    11. September 2014

    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 😉

  3. #3 Ursula
    11. September 2014

    Schön schreiben Ursula! Softwarearchitektur…

  4. #4 simop
    11. September 2014

    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… 😉

  5. #5 Pippi Lotta Viktualia
    11. September 2014

    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.

  6. #6 Karl Mistelberger
    11. September 2014

    > 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!

  7. #7 Pippi Lotta Viktualia
    11. September 2014

    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?

  8. #8 Franz
    11. September 2014

    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 🙂

  9. #9 Ursula
    11. September 2014

    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.

    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ß.

  10. #10 Alderamin
    11. September 2014

    @Karl Mistelberger

    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.

    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.

  11. #11 Alderamin
    11. September 2014

    @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.

  12. #12 Florian Freistetter
    11. September 2014

    @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.

  13. #13 Ursula
    11. September 2014

    aber eigentlich ist das Thema viel zu komplex für einen kurzen Blogartikel,…

    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.

  14. #14 Alderamin
    11. September 2014

    @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.

  15. #15 Alderamin
    11. September 2014

    @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ß.

  16. #16 Florian Freistetter
    11. September 2014

    @Alderamin: Gerne!

  17. #17 CM
    11. September 2014

    @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.

  18. #18 Karl Mistelberger
    11. September 2014

    #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.

  19. #19 Dampier
    11. September 2014

    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:

    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.

    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

  20. #20 Ursula
    11. September 2014

    @ 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.

  21. #21 tina
    11. September 2014

    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?

    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.

    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 😉 .

  22. #22 eos
    11. September 2014

    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!

  23. #23 Florian Freistetter
    11. September 2014

    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.

  24. #24 Alderamin
    11. September 2014

    Bevor da was falsch hängen bleibt: ich fand ja auch, dass er gut geschrieben ist.

  25. #25 Theres
    11. September 2014

    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.

  26. #26 Ursula
    11. September 2014

    @ tina
    Grins, schöne Geschichte über “deinen” DAU. Es gibt sie wirklich diese speziellen Spezialisten. 🙂

  27. #27 Markus
    11. September 2014

    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.

  28. #28 Uli
    11. September 2014

    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.

  29. #29 Uli
    11. September 2014

    Kleiner Nachtag: Für SW-Entwickler wie mich gibt es nichts Langweiligeres, als ein Programm, das fehlerlos funktioniert… 😉

  30. #30 Markus
    11. September 2014

    @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. 😉

  31. #31 Alderamin
    11. September 2014

    @Uli/Markus

    Der Software-Entwicklungsprozeß ist von der verwendeten Sprache völlig unabhängig.

    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.

  32. #32 Uli
    11. September 2014

    @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…

  33. #33 CM
    11. September 2014

    @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.

  34. #34 Stefan Wagner
    https://demystifikation.wordpress.com/2014/09/10/barte-gestern-und-heute/
    11. September 2014

    Und auch Wiederholungen, Schleifen genannt, sind notwendig. Schließlich soll der Benutzer auch mehrmals klicken dürfen.

    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.

  35. #35 Markus
    11. September 2014

    @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.

  36. #36 Markus
    11. September 2014

    @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.

  37. #37 Karl Mistelberger
    11. September 2014

    > #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.

  38. #38 Markus
    11. September 2014

    @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.

  39. #39 Weltraumschaf
    11. September 2014

    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.

  40. #40 Alderamin
    11. September 2014

    @Weltraumschaf

    Software-Engineering ist genauso Engineering wie Brücken bauen nur mit deutlich weniger Erfahrung.

    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.

  41. #41 Dampier
    11. September 2014

    @Weltraumschaf

    Ich glaube, da lappt es schon ins Philosophische …

    Warum funktioniert Software gerade meistens dann nicht korrekt, wenn ich sie dringend brauche?

    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. …

    Warum wird Software nie rechtzeitig fertiggestellt?

    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.

    Warum ist Software nie so dass man sie intuitiv benutzen kann?

    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.

    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. 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

  42. #42 Christoph
    11. September 2014

    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…

  43. #43 Markus
    11. September 2014

    @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.

  44. #44 Ursula
    11. September 2014

    @Markus
    Danke für die anschauliche Erklärung Softwaretechnik – Softwarearchitektur!

  45. #45 PDP10
    11. September 2014

    “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 …

  46. #46 Karl Mistelberger
    12. September 2014

    > #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. 🙂

  47. #47 Uli
    12. September 2014

    @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!

  48. #48 Markus
    12. September 2014

    @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.” |-(

  49. #49 Christoph
    12. September 2014

    @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.

  50. #50 Dampier
    12. September 2014

    @Markus

    dass sich die Autoren nicht in die Lage des späteren Anwenders versetzen

    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

  51. #51 Karl Mistelberger
    12. September 2014

    > #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.

  52. #52 Markus
    12. September 2014

    @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.

  53. #53 Christoph
    12. September 2014

    @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.

  54. #54 Karl Mistelberger
    13. September 2014

    > #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.

  55. #55 HF
    13. September 2014

    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?

  56. #56 KeinDoktor
    13. September 2014

    @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.

  57. #57 Markus
    15. September 2014

    @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?

  58. #58 Definition
    15. September 2014

    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.