Ich begrüße Sie zur letzten Veranstaltung in dieser Woche.
Nicht? 16 bis 18 geht's weiter. Respekt. Dann werden Sie
schneller fertig. Ja, mein Name ist Guido Grützern.
Für mich ist das die letzte Veranstaltung in dieser Woche.
Ich komme vom Department Informatik, genauer gesagt,
dort vom Arbeitsbereich Softwaretechnik, so wie meine Kollegen Heinz Züllighofen,
Axel Schmolitzki und Carola Lilienthal auch,
die sie so im Rahmen der Lehrveranstaltung SE2, OPM,
STE bereits schon kennengelernt haben.
Ich werde Ihnen heute und nächsten Freitag im Rahmen dieser Veranstaltung,
etwas zu diesem Thema da oben versuchen zu erzählen, Vorgehensmodelle der Softwareentwicklung.
Der Grundgedanke dieser beiden Vorlesungen wird sein, warum ist das eigentlich alles so schwierig?
Warum und warum wird es auch nicht besser?
Warum gibt es keine Chance, dass es besser wird?
Wir können nur versuchen, uns im Rahmen der uns gegebenen Möglichkeiten
zu bemühen und ich werde ihn spätestens in der nächsten Woche,
werde ich Ihnen ein paar Möglichkeiten aufzeigen,
wie wir das grundsätzliche Problem lösen können.
Ich gehe dabei davon aus, Sie sind junge Menschen,
sie haben alle noch nicht allzu viele Erfahrungen im Umgang mit der Konstruktion, großer Software-Systeme.
Ich biete Ihnen also möglicherweise eine Lösung für ein Problem an,
das Sie noch nicht kennen.
Erstmal muss ich versuchen, Ihnen ein Problem zu verkaufen,
dass Sie als solches möglicherweise noch gar nicht auf dem Schirm haben.
Während ich das tue, sind Sie herzlich eingeladen,
sich bemerkbar zu machen, Fragen zu stellen,
falls ich irgendwas erzähle, was Sie nicht verstehen.
Falls ich irgendwas erzähle, was Sie nicht interessiert,
brauchen Sie sich nicht zu melden,
dann gehen Sie einfach
Eine Abstimmung mit den Füßen, die hier stattfinden kann.
So, kurz der Fahrplan für,
das ist der Fahrplan für die beiden Vorlesungen,
die jetzt, also diesen Freitag, nächsten Freitag stattfinden.
Ich werde also, wie angekündigt,
was über das zugrunde liegende Problem bei Vorgehensmodellen, der Softwareentwicklung,
wozu ist es eigentlich gut?
Ein bisschen was erzählen. Ich werde über sogenannte Wasserfallmodelle Ihnen etwas versuchen,
nahe zu bringen, eine frühe Form von Vorgehensmodellen,
die heutzutage in der Industrie
immer noch ziemlich beliebt ist
Ja, und dann geht es so weiter.
Wir bewegen uns so im Zeitstrahl. Wir fangen so irgendwann,
das machen wir jetzt gleich auch,
also so Mitte der 60er Jahre fangen wir an.
Also die 60er Jahre des letzten Jahrhunderts und wir sind
dann nächste Woche Freitag so gegen 15.30 Uhr,
sind wir wahrscheinlich so im Jahre 2008, 9 angekommen.
Und dann werfen wir noch einen kleinen Blick in die Zukunft,
aber der wird eher kurz ausfallen.
So, in diesem Sinne,
was machen wir
Also sie beschäftigen sich ja so im Rahmen ihres,
jetzt hatte ich fast auf der Zunge ihres Grundstudiums,
ist es ja gar nicht.
Also im Rahmen ihres Bachelorstudiums beschäftigen sie sich mit verschiedenen Ausprägungen
oder mit verschiedenen Blickwinkeln auf so den Qualitätsbegriff.
Das geht es einmal um technische Qualität. Also das,
was sie so bei der konstruktiven, auf der konstruktiven Seite der Softwareentwicklung lernen,
wie kann ich qualitativ hochwertige, bezogen auf die inneren Produktmerkmale,
hochwertige Software schreiben.
Es geht später vielleicht auch mal um Gebrauchsqualität,
also was sind so, was machten die äußeren Qualitätsmerkmale eines Stücks Software aus
Das streifen wir. Das sind, wie viele MCIlerinnen sind
denn eigentlich hier? Doch, so viele. Ja,
das sind die, die sich wählen. Viel,
viel einen guten Teil ihres Studiums mit, also Gebrauchsqualität,
ob sie auch psychologischen Fragestellungen beschäftigen. Und wir beschäftigen uns heute mit,
also heute und nächste Woche dann mit so dem, mit Prozessqualität.
Prozessqualität ist also die Frage, wie muss ein Entwicklungsprozess aussehen,
damit man hohe Gebrauchsqualität produzieren kann.
Wie muss ein Entwicklungsprozess aussehen, der sowohl qualitativ hochwertige Software
ermöglicht zu bauen als auch so in Kostenfragen irgendwie beherrschbar wird?
Weil Softwareentwicklung kostet ja auch Geld. Wie viele Wirtschaftsinformatiker sind
denn hier? Brav, brav. Sie sind ja sogar
die Mehrheit dann. Das ist gut gut.
Also Sie wissen ja, also das kostet alles Geld.
Ich hoffe, dieses Bewusstsein ist auch bei den Informatikern,
wie viele Informatiker sind denn hier
Sie sitzen irgendwie so ein bisschen geklumpt. Findet hier schon.
So, dann frage ich noch die letzte Gruppe ab,
die ich hier erwarte, so auf SSElerinnen.
Fehlanzeige. Softwaresystem gibt es nicht. Brauchen die nicht?
Okay, das überrascht mich jetzt, aber ich bin Diplominformatiker.
Ich verstehe da sowieso von diesen ganzen neuen Studiengängen.
So, also, wir werfen einen Blick zurück ins
letzte Jahrhundert
50 erste Rechner für Anwendungen verfügbar. Das ist jetzt,
was ich jetzt sage, ist ganz schön gemein,
kann aber ruhig so aufgenommen werden. Das wurde dann,
also der Chef eines großen Computerherstellers, gefragt,
was glauben Sie denn, wie viele Rechner werden denn insgesamt mal
so in der Welt gebraucht werden und er hat dann sowas gesagt,
naja, so vier, fünf Stück, so Großrechner.
Und dann hat man alles ausgerechnet und dann ist gut.
Das ist jetzt wirklich gemein, also sich sowas hervorzukramen,
was für eine gigantische Fehlprognose das gewesen ist.
Also es hat sich ziemlich schnell herausgestellt,
dass es also doch einen erheblich höheren Bedarf gibt,
offensichtlich Sachen auszurechnen, auszurechnen zu wollen.
Und das ist dann So, die ersten Rechner wurden dann mit Assembler programmiert.
Das lernen sie, glaube ich, auch noch,
so an irgendeinem Winkel ihres Studiums, also eine maschinennahe Sprache.
Und dann wurden also die ersten sogenannten höheren Sprachen entwickelt,
höher. Also die heißen höhere Sprachen, weil sie eine
etwas größere Abstraktion von der zugrunde liegenden Maschinerie ermöglichen.
Vertreter dieser Sprachen sehen sie da oben. Kobol, Fortran,
Allgäu, einige der bekannteren Vertreter sollen mit der Verbreitung von Rechnern,
mussten sich natürlich dann auch, analog dazu,
haben sich dann eben auch Programmierer,
die haben sich nicht die einzelnen Programmierer verbreitet,
aber sie haben sich vermehrt.
Jetzt auch nicht im biologischen Sinne, aber es wurden halt mehr Programmierer gebraucht.
Dann hat man also so in den 60er Jahren,
also was sich da, was sich da so ergeben hat,
hier steht es so etwas so verbrämt, zahlreiche Problemfelder werden erschlossen.
Sie können davon ausgehen,
wenn sie heutzutage in eine typische Versicherung oder Bank oder Sparkasse reingehen,
da werden sie mit an Sicherheit grenzender Wahrscheinlichkeit Anwendungen vorfinden,
die so den Jahren geschrieben wurden,
als ihre Eltern in ihrem Alter waren.
So ungefähr jedenfalls. Also so in den 60er Jahren,
die laufen immer noch. Und die laufen stabil und das Problem,
nicht das Problem, könnte man ja sagen, ist ja wunderbar.
Es läuft immer noch. Das Zeug. Es hat aber,
das ist ungefähr vergleichbar so mit den gotischen Kathedralen.
Man sieht jetzt nur noch die, die nicht zusammengebrochen sind.
Nun kann man sich jetzt, also kann schon mal der Illusion,
also Anheim fallen, dass also diejenigen,
die die gotischen Kathedralen gebaut haben,
ganz hervorragende Baumeister gewesen sind
Die, die die Kathedralen gebaut haben,
die stehen geblieben sind, für die trifft es auch zu.
Bloß also die Mehrzahl der Kathedralen ist halt eingestürzt.
Die sehen sie jetzt nicht mehr.
Und so ähnlich verhält es sich auch mit diesen klassischen Anwendungen.
Also die Mehrzahl, also ist dann von uns gegangen.
Und ein paar von denen laufen noch. Bis die mal
so weit waren, dass sie auch heutzutage noch laufen.
Also ist das passiert, was da so jetzt in Flammenschrift steht.
Die sogenannte Softwarekrise ist irgendwann mal programmiert worden.
Ja, das auch. Also was ich sagen wollte,
ist, sie ist plamiert worden. Das ist ungefähr so,
wie wenn jemand sagt, so, ab jetzt nennen wir es Finanzkrise,
haben sie damals, also so in den 60er Jahren gesagt,
so, jetzt haben wir Softwarekrise.
Und wodurch war diese Softwarekrise damals, als sie dann festgestellt worden ist,
als sie ausgerufen worden ist, gekennzeichnet. Man hat also,
da steht jetzt Software wahr, Vergangenheitsform, fehlerhaft,
nicht wartbar, wurde nicht termingerechtfertigt, hat nicht den Anforderungen entsprochen,
also die ursprünglich mal an sie gestellt worden sind.
Und wenn ich jetzt sage, war, also das ist eigentlich,
so könnte man sagen, Die Softwarekrise gibt es wohl immer noch, oder?
Weil also das, man könnte das jetzt auch mit einem isst,
könnte man das jetzt auch da stehen lassen.
Ich habe noch vor einigen Monaten, habe ich noch eine Computerzeitung,
das heißt das offizielle Organ der Gesellschaft für Informatik,
das ist mittlerweile eingestellt, hat andere Gründe.
Die haben auf der Titelseite, haben die also auf einen Artikel,
auf Seite vier oder fünf hingewiesen.
Und der Teaser hieß Softwareentwicklungsprojekte müssen nicht zwangsläufig scheitern
Das fand ich hoffnungsvoll. Es gibt doch Mut. Also
muss nicht zwangsläufig. Also es gibt Hoffnung. Jetzt ist natürlich
die Frage, also according to your definition of scheitern.
Was meinen die denn jetzt eigentlich? Was bedeutet es,
dass ein Softwareentwicklungsprojekt scheitert? Dass es zu spät ist,
dass die Software fehlerhaft ist, dass sie nicht wartbar ist,
was bedeutet überhaupt Wartbarkeit im Zusammenhang mit Software.
Software wird doch nicht alt, oder? Mein Auto wird alt.
Dann muss ich ihn halt häufiger in die Wartung geben.
Aber Software wird nicht alt. Was bedeutet das eigentlich
mit diesem Begriff über Software
zu reden
Um es kurz zu machen, die Situation, die
als unbefriedigend empfunden wurde. Damals war ein Auftraggeber sagt,
ach, ich stelle mir das so schön vor,
wenn wir ein Stück Software haben, das folgendes Problem löst.
Und dann sagt jemand, ich löse dir dieses Problem in
dem Zeitraum für das Geld.
Und das stellt sich als unzutreffend heraus. So, was
ist da los? Wie kann man diese Situation verbessern?
Ja, das war eine gute Frage damals. Es gab damals,
also war es irgendwo im Wesentlichen eine gute Frage,
weil es eben so, wie das da steht,
es gab keine Programmiermethodik
30 Jahre später, 40 Jahre später, haben wir mittlerweile Programmiermethodik.
Gliederung der Softwareentwicklung, also wie können die Entwicklungsprozesse aufgeteilt werden?
Wusste man ja gar nicht. Man hatte dieses Gerät,
das konnte was rechnen. Ja, und jetzt,
so ich habe mal so aus den 60er Jahren,
da wurden ja dann auch sogenannte Rechenzentralen gegründet,
also so Dienstleister für Banken, Versicherungen,
also Finanzdienstleistungen sind ganz so früh auch schon mit vielen Rechenleistungen ausgestattet worden.
Und so im Jahre 2000 habe ich mal also ein Band,
also eine Festschrift in die Hand bekommen von so einer Rechenzentrale.
Und die war gewidmet,
was sehe ich denn doch
Ich sehe auch drei weibliche Zuhörer. Hallo, herzlich willkommen.
Diese Festschrift war gewidmet, den Männern der ersten Stunde.
Das war das Selbstverständnis damals. Ein Rechner, ein Mann und so
eine Ölkanne und dann schauen wir mal. Das war also die,
ist jetzt ein bisschen pointiert dargestellt,
aber es war also das vom Selbstverständlich, Selbstverständnis her,
also Computer zu bedienen, Computer zum Laufen zu bringen,
ist nicht etwas, das also mit Ingenieur wissenschaftlichen Grundlagen oder Kenntnissen geschieht,
sondern das ist eine Kunst.
Das ist so große Magie,
großes Kino,
was wir hier betreiben
Hier, so, das hat sich heutzutage geändert und die Frage,
Sie sehen Sie, wie sie da steht,
ist die Software, so, wir haben das jetzt zwar alles,
aber ist die Softwarekrise überwunden, tja, also,
ja, ich werde diese Frage jetzt für Sie nicht beantworten.
Sie sind nächste Woche Freitag um 15.45 Uhr, also werde
ich Sie das mal fragen. Und dann können Sie mir sagen,
und wir treffen uns dann im Jahre 2030 zu Ihrem Alumni-Treffen
und dann hole ich diese Folie nochmal hervor,
stellen wir uns diese Frage nochmal 2030,
ja,
das könnte ungefähr hinkommen
So, Management-Light-Fragen für Vorgehens-Modell. Freue ich mich ja,
dass du viele Wirtschaftsinformatiker hier sind, also zukünftige Top-Manager,
CIOs, was sie alles so werden wollen,
beziehungsweise werden können, wenn sie das wollen.
Was sie wissen wollen, möglicherweise ist, vielleicht wollen sie
es auch nicht wissen, wie kann Softwareentwicklung zeitlich gegliedert werden?
Also was sind da so eigentlich,
also wie kann man diesen Entwicklungsprozess, wie kann man den gestalten,
wie kann man so Zwischenergebnisse möglicherweise auch festhalten, sodass also erfahrbar wird,
da sitzt also diese Menge Informatiker im abgedunkelten Raum sagen immer,
oh, es dauert noch.
Wie weit seid ihr denn? 95 Prozent fertig. Super.
So, und dann seid ihr fertig, nächste Woche.
Und nächste Woche wieder. Wie weit seid ihr? Hast
du noch ein Problem aufgetreten? 96, 97 Prozent.
Sicher. Chef. Wir schaffen das. Und so geht
das weiter. Ja. Will man das? Nein,
das will man nicht. Das will man überhaupt nicht haben
. Welche Teilaufgaben Arbeitspakete kann man in der Softwareentwicklung unterscheiden?
Ist es so, ich sage zu ihnen, oh,
ich habe dieses Problem gelöst haben.
Setzen Sie sich dann hin an den Rechner und sagen,
ich löse das mal über Nacht, um dann nachts um drei festzustellen,
nee,
heute Nacht wird es nichts
Also vielleicht sollte ich noch mal was fragen.
Also was kann man da überhaupt an Arbeitsschritten unterscheiden?
Ich weiß nicht, wie sie ihre Übungsaufgaben lösen. Ich meine,
das sind ja jetzt nicht gerade so die Sachen,
die die Welt dann sich in die andere Richtung drehen lassen,
aber so kann man ja auch mal drüber nachdenken.
Also gibt es ein sinnvolle Arbeitsteilung,
abgesehen von einer macht es, die anderen kopieren es.
Das ist auch nicht, das hat man in der Wirtschaft
auch nicht viel Verständnis für.
Braucht man da nicht. Zuverlässige Zwischenergebnisse. Ja,
das ist so die Frage.
Also ich finde diese Frage interessant
Und ich werde versuchen, ihnen auch zu vermitteln,
warum ich das interessant finde, in der Hoffnung,
dass sie das danach auch interessant finden. Wie kann man überhaupt kontrollieren,
ob sich jemand auf dem richtigen ein Projektteam,
auf dem richtigen Weg befindet, ohne dass jetzt also,
weil man nicht haben möchte,
dass so ein 18 Monate laufendes Projekt nach,
dass man so nach 17,9 Monaten feststellt, das war es irgendwie nicht.
Das war es überhaupt nicht. Das will man nicht.
Man möchte zum frühestmöglichen Zeitpunkt feststellen,
was ist da los, sind die auf,
bauen die das Richtige,
bauen die
das Richtige richtig
Wenn man das erkannt hat, wie lässt sich der richtige Weg einhalten?
Also jetzt, das ist schon von Einhalten ist da schon die Rede.
Also wie lässt sich der richtige Weg überhaupt finden?
Gibt es so etwas wie einen richtigen Weg?
Eieiei. Wie wird frühzeitig Qualität gesichert? Ja, sie haben
diese verschiedene, so die Ausprägung des Qualitätsbegriffs haben sie gesehen.
Also wie kann man das also zum frühestmöglichen Zeitpunkt,
also wie kann man das in den Entwicklungsprozess,
wie kann man da Qualität hineinbekommen?
So nach dem Motto, alles, was ich nicht vorne hineingesteckt habe,
kann ich hinten auch nicht rausbekommen. Das ist also,
das sind so diese Fragen und ich hoffe,
dass sie so bei den verschiedenen Vorgehensmodellen,
die wir jetzt hier diskutieren werde,
die ich Ihnen vorstellen werde,
das ist so diese Fragen so ein bisschen im Hinterkopf haben
Dass man auch diese Modelle daran messen kann. Wie ging das
also damals los? Die nahe, die sogenannten Gründungskonferenzen 68,
69, so im Wesentlichen kofinanziert von der NATO,
weil das also unter anderem, aber auch wie das halt so ist,
ganz besonders die Militärs haben ein Interesse daran, dass Software zuverlässig funktioniert.
Es ist ja, habe ich auch erst jetzt vor kurzem erfahren,
doch so, Gott sei Dank sind wir das ein oder
andere Mal noch ziemlich knapp am Dritten Weltkrieg vorbeigeschlittert,
also obwohl Softwaresysteme gesagt haben, der Russky kommt und umgekehrt.
Also der Amerikaner schießt. Das haben so Software-Systeme, haben das
so mal gemeldet. Also Gott sei Dank hat immer noch jemand gesagt,
das glaube ich nicht und hat darauf verzichtet.
Also seinerseits auf den Knopf zu drücken. So,
was haben die, also da bei diesen NATO-Gründungskonferenzen unter anderem in Garmisch-Partenkirchen.
Was haben die da, also was haben die da gemacht?
Die haben also zunächst mal, also das,
was ich jetzt hier in der ersten Viertelstunde versucht habe,
so zu problematisieren, haben die festgestellt.
Die haben das erst mal gesagt, das ist jetzt Fakt.
Wir müssen uns mal darum kümmern
Und die haben dann so auch diesen Terminus-Software-Engineering,
so damals erfunden oder sagen wir lieber geprägt.
Und zwar genau in dem Sinne, in dem das da steht.
Das ist eine Art von Provokation, weil sie genau wussten,
also Software wird nicht nach Ingenieurwissenschaftlichen Kriterien gebaut.
Und damit wurde dann sozusagen auch das Leitbild,
also jetzt unter anderem für ihre Ausbildung wurde damals geschaffen.
Also wir wollen, dass Software mit Ingenieurwissenschaft nach Ingenieurwissenschaftlichen Kriterien entwickelt werden kann.
Und das ist die Aufgabe, die vornehmste Pflicht des Softwareingenieurs,
insbesondere an der Hochschule, solche ingenieurwissenschaftlichen Grundlagen zu schaffen,
sich zu überlegen, was es denn nun eigentlich bedeutet.
So Software eben nicht nur so nach dem Motto,
das Programm fängt Zeile 1 an und hört Zeile 8000
auf und dazwischen liegen wohl so ungefähr 7.998 andere Zeilen.
Das ist so viel rechnen muss schon sein. Also ein
bisschen mehr Struktur kann man den Sachen geben und insbesondere,
und das ist ja jetzt das Thema hier dieser beiden Vorlesungen,
also wir fangen,
wie fangen wir Softwareprojekte an,
dass sie beherrschbar werden und zu einem definierten und
hoffentlich dann auch befriedigenden Ergebnis kommen
So, was haben wir da also, was steht da,
bumm, bumm, ist wegen Provocative, genau,
needs, need for the types of the erotical foundations.
Also ja, theoretische Grundlagen, was machen wir hier eigentlich?
Was ist Softwareentwicklung eigentlich? Kann man sich ja,
wir sind hier schließlich an einer Universität,
so kann man sich diese Frage auch mal stellen.
Also ist das denn überhaupt vergleichbar? Also jetzt so mit Brückenbau oder an dem,
was andere Ingenieurwissenschaften, sowas, womit die sich so beschäftigen,
lasse ich jetzt auch erstmal so im Raum verhallen,
Practical Disciplins, ja,
ja,
establish branches of engineering
Gibt es. Erstmal für Mitte der 60er Jahre ist es wunderbar,
als Arbeitsgrundlage, so wie die anderen,
also ihre Projekte nicht hinbekommen, so wollen wir auch werden.
Nur mal so, die so viel besser sind,
die anderen nun auch wieder nicht, wenn es darum geht,
also irgendetwas das erste Mal zu bauen.
Das geht auch regelmäßig, also ja, schief scheitert das.
Nee, irgendwann haut es schon hin,
bloß es dauert länger und es kostet mehr.
Also in diesem Sinne sind wir genauso ingenieurwissenschaftlich wie alle anderen auch,
weil bei unseren Projekten geht es immer darum,
ein Einzelstück herzustellen.
Unser Problem ist nicht,
Autos zu bauen
Wenn man die einmal gebaut hat, weiß man, wie lange das geht.
Und es ist wunderbar. Das ist einfach nicht unser Problem.
Insofern müssen wir uns auch mit anderen Formen des Vorgehens beschäftigen,
als, also sagen wir mal, mit sowas wie einer,
mit seiner Warnidee, wie also der Softwarefabrik,
so Forschungslinien, ja, ja, Konzepte, Methoden,
Werkzeuge, Organisationsform, Software soll produziert werden.
Gut, was denn sonst, fragt man sich da.
Und das nach Ingenieurwissenschaftlichen Kriterien.
Oh, okay, na, okay
So, das ist dann so, dann hat man sich,
also gedacht, so wir müssen das,
was da jetzt tatsächlich in der Praxis passiert,
das müssen wir mal systematisieren.
Und deswegen ist also dann zuerst auch mal nicht die Diskussion,
sondern man hat also, das ist ja eine gute wissenschaftliche Praxis,
was man getan hat, wie arbeiten diejenigen, die Software erfolgreich entwickeln.
Und das gucken wir jetzt mal ab und dann bringen wir
das mal auf einen Begriff, auf ein Konzept.
Und dieses Konzept heißt Vorgehensmodelle. So, Englisch,
Lifecycle Models. Und die sind also die Diese Vorgehensmodell-Diskussion,
die findet heutzutage immer noch statt, hat sich natürlich,
also wen wundert das, innerhalb von 40 Jahren so ein kleines bisschen weiterentwickelt.
Ein wesentlicher Vertreter von Vorgehensmodellen sind sogenannte Phasenmodelle. Ein Phasenmodell ist ein Vorgehensmodell,
jetzt, Achtung, wer hätte das gedacht,
dass aus Phasen besteht und in denen so die wesentlichen Projektaktivitäten
zu einem vordefinierten Ergebnis oder Zwischenergebnis führen sollen
Und ich werde Ihnen jetzt gleich mal so die
ersten Phasenmodelle zeigen, die heutzutage auch noch aktuell sind.
Welche Aktivitäten es denn überhaupt gibt, die, wie hier steht,
üblicherweise sequenziell zeitlich eine auf die andere folgend so organisiert sind.
Bevor ich das tue, dieses Gesicht sollten Sie dann mal gesehen haben,
Barry Beam, steht da, warum der so berühmt ist,
Urheberbekannter Vorgehensmodelle.
Der hat also dann so in den 70er Jahren,
hat der also viel in diesem Bereich veröffentlicht
Und mit seinem Namen sind so verschiedene, also klassische,
mittlerweile Klassiker der Software-Engineering-Literatur verbunden und die haben wir unter anderem,
also ihm zu verdanken.
Und wenn man hier sieht, so wo der überall gearbeitet hat,
das ist also auch nicht unbedingt reinste Friedensforschung.
Dapa, das ist auch so eine vom Department of Defense,
so finanzierte Organisation, die haben ja auch das Internet erfunden.
Oh, so ein TRW, ich glaube, die arbeiten auch also fürs,
die bauen auch so Nicht so das friedlichste Zeug auf der Welt.
Und General Dynamics, ich glaube, die auch nicht.
Naja. Ja, das ist halt so.
So ist das. So, Fass, Vorgehensmodelle, klassisch.
Das Wasserfallmodell. Wieso heißen diese Modelle so? Also die Grundidee ist,
Leute, wir brauchen irgendeine Art von Vorstellung,
so dass sich die an einem Projekt beteiligten.
Also so organisieren können, dass sie jeweils wissen,
was machen wir jetzt und was machen wir als nächstes
Und dann musst du also so ein gemeinsames Grundverständnis drüber herrschen.
Das ist wie beim Hausbau, dass also die Klempner wissen,
also das ist meine Aufgabe und der, was weiß ich,
der Tischler, der hat halt eine andere Aufgabe.
Und nicht jeder macht alles und jeder ist für irgendwas zuständig,
sondern es gibt eine Art von Arbeitsteilung und es gibt auch eine Reihenfolge.
Wir kümmern uns um die Konstruktion des Daches, wenn das Fundament gelegt ist.
Vorher nicht, sage ich jetzt mal so,
ohne dass ich irgendeine Ahnung davon habe,
in welcher Reihenfolge Häuser gebaut werden.
So, aber das ist die Leitidee für
diese Art von Vorgehensmodell
Und die Grundidee ist, nun, bevor wir anfangen,
also mit irgendetwas zu implementieren,
das sehen Sie hier so in der Mitte, ups.
Ja, ich bin auch ein Freund der Clean Desk Policy.
Das bedeutet, jeden Abend wird der Schreibtisch aufgeräumt.
Heute ist schon viel passiert. So,
jetzt höre ich mal auf mit der Maus rumzuturnen
Also das Projekt fängt nicht damit an,
dass Menschen etwas implementieren, sondern das Projekt fängt damit an,
dass sie das Problem analysieren und das Problem erst mal als solches feststellen.
Das Problem, das sie dann bearbeiten wollen.
Und was dabei rauskommt aus dieser Phase,
denen das gleich auch noch an einem anderen Phasenmodell zeigen,
das nennt man dann zum Beispiel ein Pflichtenheft oder ein Lastenheft.
Das ist ein Gegenstand, über den sich jetzt
also Auftraggeber und potenzielle Auftragnehmer erst mal verständigen können.
Ist es das, was wir gemeinsam als Problem feststellen?
Das ist doch mal was. Hat doch keiner also Software
entwickelt zu dem Zeitpunkt. Der nächste, die nächste Phase,
die dann in so einem klassischen Vorgehensmodell folgen soll,
das ist der Entwurf. Man entwirft das System von außen.
Was soll das Ding? Also wie soll es ausschauen?
Und von innen. Das heißt also, welche Konstruktionsprinzipien kommen
eigentlich zum Tragen? Und erst wenn man,
wenn einem das so im Großen und Ganzen vollständig gelungen ist,
dann wird man in die Implementierung übergeben.
Das heißt, jetzt kommen also die Informatiker ins Spiel
oder die Software-Systementwickler
Sagen, jo, das, was jemand anders,
möglicherweise jemand anders analysiert und definiert hat,
was jemand Drittes entworfen hat, das implementieren wir jetzt.
Und wenn uns das gelungen ist, dann wird alles getestet.
Ist ja auch klar. Wir müssen, bevor die Software
zum Kunden ausgeliefert wird, müssen wir die testen.
Wer will das bestreiten? Und wenn die im Test ist,
also wenn die den Test überlebt hat,
dann kann man sie einsetzen und später warten.
Das ist die Idee von Wasserfallmodellen oder das Vorgehensmodell aller Wasserfallmodell.
Und das heißt Wasserfallmodell, weil so im Großen und Ganzen
hat man sich vorgestellt oder ist die Vorstellung mit dieser Art von Vorgehensmodell,
man fängt halt einmal an und dann geht geht es immer weiter.
Also wenn ich beim Implementieren bin,
brauche ich auch insbesondere nichts mehr zu analysieren,
weil das ist ja alles schon alles analysiert worden.
Und wenn ich beim Testen bin, dann teste ich halt
nur noch das, was implementiert worden ist.
Weil was anderes brauche ich ja jetzt nicht mehr zu machen.
Ich brauche insbesondere, wenn ich beim Testen feststelle,
das Ding kann gar nicht drucken. Man kann es eben nicht
drucken. Das hätte ja mal jemand vorher drauf kommen können,
dass das also drucken können soll, oder?
Jetzt hat man bloß so ein kleines Problem. Also möglicherweise
Wo wollte der Auftraggeber, dass das Ding drucken kann?
Ja, dann hat wohl der Software, der Projektleiter einen Fehler gemacht.
Weil er hat ihn ja nicht nachgefragt. Na,
wieso sagt der Projektleiter? Hat er mir nicht gesagt?
Das ist er drucken, der ist ja wohl selbstverständlich.
Dass das Ding drucken können soll. So,
ich komme jetzt schon langsam in die Diskussion,
was so ein Wasserfallmodell so von der Idealvorstellung her,
das ist so ein bisschen schwierig ist,
weil man ist ständig, wenn man dieses Wasserfallmodell wirklich lebt,
dann ist man ja ständig schuldig,
dass man
irgendwas vergessen hat
Was einem erst sehr viel später auffällt,
dass man es vergessen hat und dann muss man Rückschritte machen
und die sind im Modell eigentlich nicht vorgesehen.
Also, machen Sie das nicht nochmal. Ihr Fehler,
was das wieder an Geld kostet, jetzt noch das Drucken einzubauen.
Warum das nur zu menschlich ist, ich komme darauf gleich noch zurück.
Ups, ui, ui, ui, ui.
Boah, da hat sich aber jemand Mühe gegeben.
Und es ist mein Fehler,
diesen Vortrag noch nie in diesem Modus vorher.
Oh Gott, es wird ja immer schlimmer.
So. Ja, eine Definition von Wasserfall oder der Dokumentenmodell.
Ich habe das Werk extra in seiner neuesten Auflage auch mal mitgebracht.
Software Engineering, Ludeweg Lichter, 42,90 Euro.
Ich verdiene da nichts dran.
Ein gutes Buch
Zu. Also wenn Sie das kaufen oder der Bibliothek sagen,
die soll dann noch ein paar von bestellen, ich werde das unterstützen. Nee,
da kann man also viele, diese, ich zeige das jetzt deswegen,
weil also die Definition von Wasserfall oder Dokumentenmodell ist halt hier aus Ludewig Lichter,
so Folge von Aktivitäten, die durch Teilerergebnisse,
sprich die Dokumente gekoppelt sind, gleichzeitig,
teilweise können sie gleichzeitig oder iterativ ausgeführt werden.
Abgesehen, davon, abgesehen ist die Reihenfolge fest definiert,
so in dem Sinne,
in dem
ich das gerade gesagt habe
Das ist, also das ist so die Grundlage,
also von allen Vorgehensmodellen, die jetzt, also in der Softwareentwicklung diskutiert werden.
So, das kann jetzt dauern. Das heißt also nicht
nur Wasserfallmodell, sondern auch Einbahnstraßenmodell, eine weitere Metapher,
die ihnen klarmachen soll, worum geht es hier?
Also es geht immer nur den Berg runter in einer Einbahnstraße.
Und sie sehen jetzt also für diese Aktivitäten,
die ich gerade genannt habe, also zum Beispiel Anforderungsermittlung,
das Ergebnis ist eben eine Anforderungsdefinition
Die dabei rauskommen soll. Darüber kann man reden.
Zwischenergebnisse waren ja so Management-Leitfragen nicht. Systemspezifikation, Entwurf,
Systemspezifikation, wie sieht das Ding von außen aus?
Entwurf, wer sieht es von innen aus? Welche Komponenten
soll es haben? Also wie kann ein Entwurf in,
also verschiedene Komponenten aufgeteilt werden? Also das integrierte Programmsystem,
das dann getestet und installiert werden kann und dann wird es eingesetzt.
Das ist die Modellvorstellung, die so,
ich weiß nicht, wie viel psychisches Leid diese Modellvorstellung
schon erzeugt hat
Ich sage Ihnen jetzt, Sie nehmen die jetzt zur Kenntnis,
diese Modellvorstellung und Sie sollte in Ihrem Repertoire von Methodenkonzepten sollte,
die einfach enthalten sein. Dafür werden Sie hier ausgebildet,
dass Sie halt so in einer Situation später mal in Ihrer Praxis draußen,
wenn Sie Geld verdienen,
sagen und in jemand gibt,
in einen Auftrag für ein Projekt,
dann sollte in Ihrem Schrankwand von Methoden und Konzepten
sollten unter anderem die Wasserfallmodelle drin sein und Sie entscheiden dann,
ist dieses Vorgehensmodell adäquat für diese Projektsituation
Und ich werde Ihnen jetzt noch ein paar Kriterien nennen,
im Laufe dieser Vorlesung, wann das geeignet ist und wann das nicht geeignet ist.
Die Autoren dieses Buches Ludewig Lichter haben da eine ziemlich pointierte
Meinung zu. Nachdem sie das sachlich dargestellt haben,
also haben sie so ein kleines bisschen,
äußern sie auch ihre Meinung über Vorgehensmodelle, insbesondere Wasserfallmodelle und das,
was wir noch kennenlernen werden, sogenannte agile Entwicklungsmodelle.
So, also das Wasserfallmodell, als es dann Böhm,
6 Barry Beam, 76 veröffentlicht hat,
das war der, das war wie die Offenbarung.
Junge, wir brauchen nicht mehr mit hochgekrempelten Ärmeln Software entwickeln.
Wir können systematisch Software entwickeln. Wir haben ein Vorgehensmodell und wir haben etwas,
das sagt, erst tu dies und dein Tujenes.
Genau das, was Ingenieure gerne produzieren.
Es gibt jetzt ein erkennbaren, also Produktionsweg für Software.
Die ein paar von den Punkten, die jetzt hier genannt sind,
also die, die das Vorgehen nach Wasserfallmodellen charakterisiert.
Tja, was machen wir denn damit?
Also Rückgriffe werden als Fehler und Unzulänglichkeiten betrachtet,
die bei optimalen Projektverlauf nicht nötig wären und
damit minimiert werden sollen
Denn jetzt aber, ich sage jetzt mal,
eine Zahl, die ich empirisch nicht belegen kann.
Wenn jetzt 90 Prozent der Softwareentwickler sagen, ich habe es schon wieder verzockt.
Im nächsten Projekt, ich habe wieder was vergessen.
Ich bin schuldig, ich bin ein schlechter Softwareentwickler.
Ich werde jetzt Apfelbaumpflanzer. Möglicherweise ist das die richtige Entscheidung.
Möglicherweise kann man sich auch fragen, ist die Modellvorstellung adäquat,
nach der ich arbeiten soll? Wenn alle Leute es,
also die meisten Leute es, die meiste Zeit nicht hinbekommen,
sagt diesem Modell zu arbeiten, Vielleicht brauchen wir ein anderes Modell, nachdem wir arbeiten können.
Also kein Modell hat nicht geklappt, dass das die Softwarekrise verursacht. Jetzt haben wir ein Modell und gut,
das ist also, wir haben schon ein paar,
also es hat ein paar erkennbare Fortschritte gegeben,
aber also viele Leute sind dann doch viel unglücklich mit dieser Art von,
mit dieser Art von Modellvorstellung, weil es ihnen trotz,
also größten Bemühen nicht gelingen will, sich immer nach diesem,
sich immer korrekt im Sinne dieser Modellvorstellung zu verhalten.
Ein Problem, kommen gleich noch auf viele andere Probleme,
die mit dieser Modellvorstellung verbunden sind,
so den ein oder anderen Exkurs gönne ich uns dazu.
Ein Problem ist das, was hier steht,
als zugrunde liegende Annahme. Das durch die Software,
die wir erst noch bauen wollen, also zu lösende Problemen,
lässt sich vollständig vor der Implementation spezifizieren.
Und das ist eine Annahme, die kann man nur treffen,
also wenn man noch nicht so viel Erfahrung mit so Softwareproduktionen hat,
beziehungsweise wenn man nur eine bestimmte Klasse von Problemen
versucht mit Software
Zu lösen. So, die Überlegung,
zu der ich sie jetzt nur kurz in diesem Zusammenhang einladen möchte,
es ist ja dann doch so, dass wir zu dem Zeitpunkt,
zu dem wir am allerwenigsten über das Projekt wissen,
nämlich an Projektbeginn, wenn diese Analysephase da ist,
schon das Problem,
das zu lösende Problem vollständig spezifizieren müssen.
Und das ist schwierig, um nicht zu sagen,
für größere Problemstellungen, also fast ein Ding der Unmöglichkeit.
Man sollte so in so eine Modellvorstellung,
sollte man schon einbauen, das Softwareentwickler,
während sie ein Problem lösen,
etwas über die Natur des Problems lernen
Das muss jetzt nicht für, sagen wir mal,
eine Problemstellung, ich möchte die Fibu Nacci zahlen.
Also gerade mal jetzt ausrechnen. Also für diese Klasse von Problemen geht es nicht.
Kommen wir auch noch zu. Welche Klassen von Hundproblemen gilt es?
Gibt es denn eigentlich? Aber wenn es darum geht,
mal so einen Kundeninformationssystem für eine große Organisation zu bauen,
das ist dann von einer anderen Problemklasse.
Und wir werden diese Problemklassen jetzt,
also ich nenne die jetzt erstmal nur so beispielhaft, extensional.
Ich werde das auch noch intentional, also von der Struktur her,
versuchen klarzumachen. Jetzt kommen wir mal zu ein paar Problemen,
die mit also dieser Art von Vorgehensmodellen verbunden ist.
Was Sie sehen, ist also Studiert sich von Ihnen jemand im Nebenfach Mathe?
Na gut, das ist schon mal nicht schlecht,
dass keiner von denen hier ist,
aber also das bringt jeden Mathematiker oder jeden,
der also ein Freund von, also Funktionen ist,
also bringt es also doch echt jetzt wahrscheinlich so die Stirn zum Runzeln.
Das ist mehr so intuitiv gemeint, was da steht.
Das hat nicht den Anspruch, dass man da irgendwas mal ausgerechnet hat.
Also was steht denn da jetzt eigentlich? Also Sie sehen auf der,
auf der horizontalen verläuft die Zeit und legen nein, so vertikal wird die Kundenzufriedenheit.
Wird da gemessen oder sagen wir lieber bewertet. Also,
was diese Verlaufs, was dieser Verlauf ihnen sagt,
am Anfang des Wassers,
also wenn ein Projekt nach dem Wasserfallmodell durchgeführt wird,
dann ist die Kundenzufriedenheit am Anfang, steigt die ziemlich steil.
Das ist dann die Zeit, in der Auftraggeber und Auftragnehmer
miteinander sprechen. Und sich darüber unterhalten,
was das zu lösende Problem ist und der Auftragnehmer sagt,
kein Problem
Wir machen das. Super. So will man das hören.
Der Auftraggeber beauftragt das Projekt. Dann ist ja auch völlig klar,
dass also in der Zeit, wo jetzt da steht,
kein weiterer Kontakt,
wo nämlich die Softwareentwickler für sich sind und mit ihren geheimen Künsten,
also die Rechner versuchen zu bezwingen, also dass die sich da nicht melden.
Die machen das schon und die machen das für mich
und in meinem Auftrag und das, was ich will.
Also ist meine Zufriedenheit immer noch groß.
Es kommt jetzt zu den ersten Terminverzögerungen
Nun gut. Kann passieren. Wir sind alle nicht perfekt
. Habe ich Verständnis für. Ist ja auch schwierig,
was die da machen. Ich könnte das nicht,
aber die können das. Das sind Profis. So,
dann, und das ist jetzt also mit dem Wasserfallmodell ziemlich,
also untrennbar verbunden, die heißt auch so,
das ist die Big Bang Programmeinführung.
Und manchmal landet dann diese Software in einer Organisation auch wirklich
wie ein Big Bang.
Alle sind überrascht
Über das, was da abgeliefert wurde. Viele sind überrascht,
wenn wir das, was da abgeliefert wurde.
Und sie können das also jetzt, was da steht,
ist also die Kundenzufriedenheit sinkt etwas. Kein Mensch weiß,
warum die jetzt ausgerechnet da aufhört zu sinken oder warum,
aber es soll ihnen klar machen,
dass nach dieser Programmeinführung nach dieser langen Zeit,
also die da dieses Modell, den Kundenkontakt in diesen Phasen nicht vorsieht,
dass dann Überraschungen nicht unüberraschend sind, sondern eher die Regeln sind.
Dass dann also was passiert, ja. Und jetzt,
das ist jetzt alles Spekulation, ob also die,
na, wo ist meine Maus? Da,
dass hier die Kundenzufriedenheit, also gegen Null sinkt oder,
also dass sie dann wieder ansteigt,
also die Leute raufen sich halt irgendwie,
manchmal raufen sie sich wieder zusammen und es wird besser und sie reden wieder miteinander in der Wartung,
also sprich also eigentlich in der Weiterentwicklung der Software.
Und manchmal trennt man sich auch voneinander und sieht sich vor dem Rechtsanwalt.
Nicht vor dem Rechtsanwalt, also vor Gericht mit dem Rechtsanwalt.
Also das ist immanent für, also Wasserfall und dann nicht,
also jetzt diese Art von Verlauf,
also das mit der Kundenzufriedenheit, die ursprünglichen Fassungen von Wasserfallmodellen,
von Vorgehensmodellen haben nicht vorgesehen,
dass man also während des Projektes noch weiter miteinander spricht.
Und das ist ein zu beobachtender Effekt. Machen Sie sich
das einfach klar an dem Drucken, das passiert also ständig sowas.
Man macht sich gar keine Vorstellung davon,
was man sich alles gar nicht vorstellen kann
Ja. Hier an der Folie möchte ich jetzt bloß,
also einen Punkt rausgreifen. Dokumente sind keine zuverlässigen Zwischenergebnisse.
Wenn dieses Video dann der Herr Professor Ludewick mal sehen wird,
also der Autor dieses Buches, also Gott sei Dank wird
er es im Internet gucken oder ich bin nicht da,
aber da steht jetzt Dokumente,
sind keine Zuverlässigen zwischen Ergebnisse.
Dann wird er mich fragen, Herr Gritzel,
was meinen Sie denn mit zuverlässig?
Haben Sie Ihren Studenten gar nicht erklärt?
Was soll denn das? Was meinen Sie denn mit Zwischenergebnis
? Wie kommen Sie dazu,
solche Behauptungen aufzustellen
Tja, wissen Sie, was ich damit meine, ist,
man kann jetzt eine Entwurfsspezifikation oder ein Anforderungs-, eine Anforderungsspezifikation.
Da kann man jetzt eine Qualitätssicherung drauf anlegen. Das machen
die Leute heutzutage auch. Sogenannte Quality Gates kann man da
zum Beispiel durchschreiten lassen. Das heißt, ich prüfe ein Dokument,
zum Beispiel darauf, ob es in sich widersprüchlich ist.
Oder ob es also vollständig ist, vollständig im Sinne von,
Ich habe alles das, was ich irgendwann mal protokolliert habe,
habe ich auch ins Dokument übertragen.
In diesem Sinne kann man natürlich jede Menge Qualitätssicherungsmaßnahmen an solchen Dokumenten,
also durchführen. Was einem aber nicht wirklich gelingt, ist,
der Anwender hatte eine bestimmte Vorstellung im Kopf. Und ob das,
was er gesagt hat, das, was er gemeint hat,
ob das so miteinander übereinstimmt und ob das,
was ich verstanden habe und aufgeschrieben habe, das ausdrückt,
was der mir sagen wollte,
diese Art von Test werde ich mit einem Dokument
nicht durchführen können
Sind die einfach nicht geeignet. Das ist das,
nur das meine ich, nur das. Nicht mehr. Für alles andere,
ich bin nicht der Ansicht, man sollte nicht dokumentieren.
Viele Informatiker sind der Ansicht, das ist Dokumentation,
etwas ist für, tja, jedenfalls nicht für sie,
weil gute Programme dokumentieren sich schließlich selbst.
So, Sprüche, so Kriegswahlenfantasien dieser Art der Meinung
bin ich deutlich nicht. So. Der Lernprozess der Beteiligten wird
nicht berücksichtigt,
das hatte ich gesagt
Ja, die anderen Punkte war ich eigentlich auch schon ein
bisschen drauf eingegangen. So. Oh Gott. Also ich verspreche
Ihnen vornächsten Freitag gehe ich das durch und ich werde es,
soweit mir das möglich ist, ausbauen.
Was ist mit Projektplanung und Phasenmodellen? Die Folie mache ich noch
, dann machen wir, wer von Ihnen raucht noch?
Sie sollten damit aufhören. Wir machen gleich eine Pause,
in der sie, die ist ungefähr so lang,
dass sie eine Zigarette rauchen können.
Nein, nein, danken Sie mir nicht
Kommunikation mit dem Kunden nur am Anfang. Ja. So,
das hier, den Begriff, sollten Sie vielleicht auch noch,
also den sollte ich mindestens einmal gesagt haben, Meilensteine.
Das ist ja auch die Welt der Softwareentwicklung ist ja voll,
also wenn ich jetzt sage, gepflastert mit Metaphern,
dann ist der Meilenstein ist eine der so beliebtesten Metaphern.
Weil der Meilenstein sagt ja,
ich bin auf meinem Weg doch jetzt schon wieder
eine Meile weitergekommen
Und er suggeriert, dass also das,
was ich hier als Meilenstein-Dokument gerade abgeliefert und so qualitätsgesichert und abgezeichnet vom Kunden bekommen habe,
dass das mich einen wirklichen Schritt auf dem Weg zum Ziel weitergebracht hat.
Und das ist leider Gottes mitunter ein Irrglaube. Und um
in fünf Minuten, ich stelle mir mal den Timer,
wo ich also die ganze Zeit gegen IT hier argumentiere,
ein Nutzer bin ich ja dann doch schon.
Also um 15.09 Uhr rede ich weiter und hoffentlich mit ihnen.
Bis gleich
Es geht weiter. Immer weiter. Immer weiter.
Unklar, ob Projekt fortschrittlich, Projektfortschritt tatsächlich relevant ist.
Ja, so ist das mit den Zwischenergebnissen auf Dokumentbasis.
Und jetzt kommt ein kleiner Exkurs. Ja, von Ihnen
kennt Slavoy Gijak. Also den sollten Sie sich mal,
den gibt es auf YouTube, also unter der Adresse.
Sie haben das in ihren Unterlagen
Nicht jetzt. Das... Heute Abend. Schön. So,
der, der ist ein Psychoanalytiker,
der sich so ziemlich viele Gedanken gemacht hat,
die er dann unter anderem in einem Tech-Talk bei Google,
also der war mal auf Einladung von Google,
da in deren zentralen Vortrag gehalten.
Das haben die dankenswerterweise mitgeschnitten. Und ich fand das schon
faszinierend, was der da so ausgebreitet hat.
Und ich habe mal versucht, das eben auf Softwareentwicklung anzuwenden
Das, was sie in solchen Dokumenten wie in einem Anforderungsdokument,
was sie da reinschreiben können, ist das,
was hier so in hellgrün steht, unter anderem.
Also bekanntes Wissen. Etwas, wovon sie wissen,
dass sie es wissen. Darüber können sie sprechen.
Das ist gut. Was sie auch noch möglicherweise in so
ein Dokument reinschreiben können, ist so bekanntes Unwissen.
Ich weiß, dass ich etwas nicht weiß,
weiß man ja. Da habe ich eine Lücke,
kann ich also, muss ich mich noch einarbeiten.
Das ist auch noch grün. Das ist deswegen grün,
weil ich weiß das ja,
dass ich da eine Lücke habe,
ich kann daran arbeiten,
um diese Lücke zu schließen
Was schon echt schwierig ist und also eigentlich ein Ding der Unmöglichkeit,
darüber sich so ein expliziten Gedanken zu machen ist,
diese Kategorie von Unbekanntem Wissen.
Ich weiß nicht, dass ich etwas weiß.
Du denkst, hä? Wie soll das denn funktionieren?
Das ist so die Kategorie von Wissen,
dass sie die haben, merken sie immer erst,
wenn etwas nicht mehr da ist zum Beispiel.
Wenn ich jetzt also wenn Sie mich fragen,
also woraus besteht eine Arbeitsumgebung, dann fällt mir,
fallen mir so drei Sachen ein und möglicherweise fallen mir genau die Sachen ein.
Also die mich gestern geärgert haben, weil die sind auch so hochgepoppt.
Aber jetzt, sagen wir mal, Strom,
also zu meiner Arbeitsumgebung gehört, also darauf werde ich nicht kommen.
Das ist unbekanntes Vision. Das ist so selbstverständlich,
dass ich nicht mehr in der Lage bin, also darüber zu sprechen.
Erst wenn irgendwas nicht mehr da ist, dann,
also oder nicht so ist,
wie ich das eigentlich annehme, ungefähr hier annehme.
Also dann weiß ich,
dass ich da etwas weiß
Und dann kommt es wieder so in die Sphären hier, bekanntes Wissen.
So, und ganz besonders eklig, unbekanntes Unwissen.
Ich weiß noch nicht mals, dass ich etwas nicht weiß.
Das ist das typische Schicksal von, also jungen,
dynamischen Bachelorstudenten, die dann Unternehmensberater werden. Gehen irgendwo hin,
denken, sie haben so einen Koffer voll,
Methodenwissen und jetzt, also werde ich mal so richtig,
was hier rumorganisieren und haben keine Ahnung davon,
wie viel Unbekanntes Unwissen.
Also sie, ja, nicht mit sich herumschleppen,
weil sie haben es ja nicht
Und jetzt lassen Sie so jemanden mal,
also jetzt nehmen wir mal eine Gesprächssituation an.
Derjenige von Ihnen, der also im Wesentlichen von unbekannten Unwissen unbehelligt ist.
Also der trifft auf so einen typischen norddeutschen Auftraggeber.
Also jemand, der also kaum die Kiemen zum Moin Moin auseinanderkriegt.
Und im Wesentlichen also durch unbekanntes Wissen geprägt ist.
Wenn die beiden sich darüber unterhalten, wie ein Stück Software
aussehen soll.
Was soll dabei rauskommen
Das wird schwierig. Big Bang ist ja wahrscheinlich, also das ist vorprogrammiert,
um den Metaphorik mal in die andere Richtung jetzt zu verwenden.
So, das ist etwas, da werden wir bei der Diskussion über Vorgehensmodelle,
werden wir darauf noch zurückkommen. Wie kriegen wir das hin,
dass etwas wie, also diese verschiedenen Wissensarten,
ich will jetzt nicht behaupten, dass die existieren,
aber wir müssen uns mit diesem Phänomen herumschlagen und eine Herausforderung für Vorgehensmodelle ist,
gerade so in den Bereichen des unbekannten Wissens und des unbekannten Unwissens,
also dass wir mitbekommen, zum frühestmöglichen Zeitpunkt,
dass diese Lücken existieren.
Weil wenn wir diese Existenz feststellen,
dann können wir daran arbeiten, dann können wir damit umgehen.
Und ich sage Ihnen, gucken Sie sich diesen Jijak mal an.
Das ist schon faszinierend. So, das können Sie sich
nachher dann mal durchlesen. Nur, dass Sie sehen,
dass diese Art von Diskussion, also die ist erstens in
der Softwaretechnik, ist sie angekommen.
Das ist eben so hier einer unserer großen, oh,
sind das wieder los? Einer unserer großen Altforderungen,
Peter Danning, also im American Scientist, also darüber geschrieben hat,
Blindheit beim Entwurf intelligenter Systeme.
Der spricht nämlich auch von dieser Unterteilung und im Englischen hört sich das also
Die haben halt dieses eine Wort dafür vom No-Known zum Unknown, Unknown.
Also die können das also ziemlich, also das ist in
der wissenschaftlichen Literatur auch verbreitet. Und nicht nur dort,
schauen Sie mal auf YouTube dann, ein Politiker Donald Drumsfeld,
der ist zwar nicht wirklich als Softwaretechniker bekannt geworden,
argumentiert aber auch, also mit diesen,
in diesen Kategorien.
So, wir kommen zurück zur Kundschaft.
Wir wollen also ein Stück Software bauen
Wir haben das Phasenmodell, haben sie im Kopf
und sie wissen, sie wissen, was sie wissen.
Sie wissen nicht, was sie nicht wissen.
Sie schreiben also diese Leistungsanforderungen auf und diese Leistungsanforderungen,
das ist wieder hier so eine Kurve,
wie sie jedem Mathematiker graue Haare wachsen lässt.
Also sie schreiben in ein Dokument, schreiben sie so ihre Leistungsanforderungen rein.
Und diese Leistungsanforderungen sind also, kann man so charakterisieren,
spezifiziert, ausgesprochen bewusst. Also wir können darüber reden.
Und die Idee ist, Je höher der Grad der Anforderungserfüllung ist,
desto höher ist auch der Grad der Kundenzufriedenheit.
Das ist die Idee von Wasserfallmodellen. So, jetzt wissen
Sie ja schon mehr. Sie wissen ja auch etwas über
unbekanntes Wissen und Unbekanntes Unwissen. Was wir nämlich mit Anforderungsmodellierung
auf Dokumentbasis nicht gefasst bekommen, sind die sogenannten Basisanforderungen.
Und diese Basisanforderungen, die sind jetzt so schwungvoll unterhalb der
Wasseroberfläche, sehen Sie die. Wenn Sie die erfüllen,
dann können Sie so sagen wir es mal so,
keinen Blumentopf gewinnen, wenn sie die nicht erfüllen,
haben sie sofort maximale Kundenunzufriedenheit.
Also diese Selbstverständlichkeiten, die nicht ausgesprochen sind und fast nicht
, beziehungsweise nicht bewusst sind. Typischer Beruf, der ist
im Wesentlichen mit Basisanforderungen zu tun hat, ist Systemadministrator.
Versuchen Sie sich mal für, wer von Ihnen arbeitet als
studentische Hilfskraft, mögt als System-Administrator keiner Doch, ja,
sollte jetzt dann vielleicht so widersprechen sie mir oder hoffentlich,
also stimmen sie mir zu.
Ihr Berufsalltag ist jedenfalls das, was ich mir vorstelle,
sie werden im Großen und Ganzen ignoriert, aber wehe,
einmal funktioniert was nicht, haben sie sofort maximales Geschrei.
Warum funktioniert das schon wieder nicht? Nie funktioniert das.
Immer ist irgendwas kaputt. So sind halt, so sind
wir halt, wir Anwender. So, und das aber so,
dass man darüber spricht, dass also solche Basisanforderungen zum Katalog,
der zu erfüllenden Anforderungen gehört, Wegen unbekanntem Unwissen,
unbekanntem Wissen, da muss man also, muss man methodisch rangehen.
So weit könnte man ja sagen, ist also,
dass das Leben des Informatikers oder überhaupt der Softwareentwicklers ist eher traurig.
Eine Regel kriegt der Ärger, wenn er irgendwas nicht macht.
Aber Hobbs ist ein falsches. Es gibt auch noch die
hier, die sogenannten Begeisterungsanforderungen. Und da ist das,
wo, also das Informatikerherz hochschlägt. Also wir können jetzt mit dem,
was wir an technologischem Know-how haben,
können wir jetzt auch Arbeitsweisen unterstützen, die vorher noch gar nicht,
also bei den zukünftigen Anwendern, also die,
die durchschaut haben, eben weil sie kein technologisches Know-how haben.
So nach dem Motto, oh, das geht jetzt also auch.
Ach, das ist ja interessant. Das finde ich jetzt aber gut.
Also typische Begeisterung, also Anforderungen, die können eben,
weil da jedem Out-of-Scope des Anwenders sind, nicht erwartet.
Ja, und sie sind also dann eben auch nicht ausgesprochen,
können gar nicht bewusst sein,
dass also irgendetwas also besser sein könnte,
wenn ich eben in meiner Höhle lebe
Weiß ich ja gar nicht, also wie das so ist mit dem Sonnenuntergang,
wenn sie den jetzt auch noch sehen können, ob prächtig.
So, das dazu. Jetzt sind wir gleich so weit,
dass wir die Diskussion über die Wasserfallmodelle abschließen und ich hoffe,
ich bin der Erste, der ihnen sowas hier zeigt.
Also die Witze über Wasserfallmodelle sind Legion. Das fand ich
mal eine etwas besonders hübsche Ausprägung. Insbesondere um klarzubekommen,
also wie vielfältig, also die Möglichkeiten des sind, also sich misszuverstehen.
Wobei, das fängt schon hier an, ja,
das fängt schon so, oh, das fängt schon hier an,
dass das, was aus meinem Mund kommt,
nicht das ist, was ich sagen möchte.
Das ist, also es ist, es ist,
praktisch ist es ein Wunder, dass überhaupt irgendwas mal zum Laufen kommt.
Wenn man jetzt noch, also so, und das hier,
wenn man jetzt, und jetzt wird ja gerade noch,
also so diese neueren Entwicklungen, also auch der Globalisierung,
also gehen ja auch in die Richtung, Also Softwareentwicklung,
also dann so arbeitsteilig, ist ja auch ein Thema.
Softwareentwicklung arbeitsteilig, sowohl hier als auch im Näheshore-Bereich,
sprich also so alles, was so in Osteuropa ist,
beziehungsweise im Offshore-Bereich, also in Indien, China,
solche Formen der Arbeitsteilung durchzuführen, was das Leben auch nicht einfacher macht.
Also wo wir schon, also von, sagen wir mal,
zwischen hier und Bad Segeberg, also gibt es schon genug Möglichkeiten,
sich misszuverstehen und dann auch noch unterschiedliche kulturelle Zusammenhänge mit also berücksichtigen zu wollen,
die Aufgaben werden nicht einfacher.
So aus ihrer Reaktion schließlich, sie haben
noch nicht allzu viel Variationen dieser Art von Cartoon gesehen.
Ja. So, um das abzuschließen, Phasenmodelle,
das ist unausgesprochene Leitbild, also der Phasenmodelle ist,
könnte man so nennen, ist der Fenstersturz.
Das ist jetzt ein bisschen narzialisch ausgedrückt. Stellen Sie sich,
also Phasenmodelle heißt ja dann die Wasserfallmodelle,
hört sich an Wasserfall, könnte man überleben.
Der Fenstersturz scheint mir insofern, also tragt auch ein tragfähiger Vergleich zu sein.
Es ist so, Sie springen aus dem zehnten Stock
Und sie segeln so am achten Stock vorbei und am sechsten Stock
vorbei und dann denken sie sich, ach, bis jetzt geht's eigentlich, oder?
So, das ist so die Art von Qualitätssicherung,
die sie auf den unterschiedlichen Dokumenten machen können,
wenn ihnen nicht wirklich klar ist,
also das kann man halt machen, wenn einem völlig klar ist,
also wie das Endergebnis aussieht, dann kann man so arbeiten.
Wenn einem das nicht klar ist,
also muss man weitere Techniken einführen, um sicherzustellen,
dass man das Richtige baut und nicht nur etwas richtig baut.
Das ist die Herausforderung, vor der wir stehen,
der wir uns jetzt stellen werden
Dazu erstmal noch, also für welche Art von Programmen gilt
denn das jetzt eigentlich? Spezifikationsprogramme, das ist jetzt,
also sie lernen heute verschiedene Namen kennen von Menschen,
von denen ich hoffe, dass sie sie dann auch mal mindestens,
also nachgoogeln werden.
Also Money, Meyer, Lehmann ist einer einer wirklich in einer ganz großen Altforderung.
Dem haben wir die Einteilung von Programmen in SP und E-Programme
zu verdanken. Also Essprogramme, das ist so mit
das Einfachste
Sogenannte Elmarlow, sage ich das Einfachste. Damit fangen wir
mal an. Spezifikationsprogramme, so wie Sie das da sehen.
Essprogramme besitzen eine vollständige und formale Spezifikation und man kann ihre Korrektheit dadurch beweisen,
dass man Spezifikation und Implementation miteinander vergleichen kann.
Das Charakteristikum von Essprogrammen ist, dass sie keine Rückwirkung auf unseren Alltag,
auf unsere Realität haben. Also die Berechnung der Fibonacci-Zahlen,
wir haben von einem realen Problem abstrahiert,
wir haben es spezifiziert und dann haben wir eine Lösung dafür implementiert.
Diese Implementation schafft aber kein neues Problem,
sondern sie hat einfach ein Problem gelöst
Bingo, könnte man sagen. So, das sind S-Programme
. Eine Stufe komplexer ist die Herstellung von P-Programmen.
Dann nehmen wir mal, P steht für Play.
Das sind, weil Spielprogramme sind ein hervorragender Vertreter.
Also dieser Gattung von Programmen. Spielprogramme sind dadurch gekennzeichnet.
Bleibt mal bei diesem Schachprogramm. Sie können jetzt zwar einen,
also ich könnte jetzt, ich ganz persönlich,
kommt noch auf die Programmiersprache an.
Ich könnte ein Programm schreiben, mit dem sie
Schach spielen können
Das wäre das grottigste Schachprogramm, das sie je also benutzt haben.
Was ich sicherstellen kann, ist, dass mein Schachprogramm syntaktisch korrekte Züge vollzieht.
Das kann ich formal spezifizieren. Was ich nicht mehr
spezifizieren kann, ist, ist es ein gutes Schachprogramm.
Das braucht Erfahrung, da muss sich jemand auskennen.
Ich kann aber nicht mehr als die Regeln, wie sich
jetzt ein Bauer und wie diese anderen Geschichten sich da bewegen müssen.
Insofern hat also dieses, gibt es eine Rückkopplung zwischen dem
Programm und dem Problem, das es vorgibt, zu lösen.
Das heißt, ich trete in so einen Rückkopplungszyklus ein.
Und dieser Rückkopplungszyklus, also wird in sogenannten E-Programmen,
wird er auf die Spitze getrieben.
Sollte ich vielleicht noch zu den P-Programmen sagen,
sie verändern das zu lösende Problem aber nicht.
Die S-Programme, gar keine Rückkopplung. P-Programme, ich brauche Rückkopplung,
um einschätzen zu können, ist eine Lösung angemessen für ein Problem.
Das Problem will aber selbst nicht verändert. Und jetzt kommt die Klasse von Problemen,
mit denen wir uns im Alltag beschäftigen, mit denen sie
sich in Zukunft mit dem Alltag im Alltag beschäftigen werden.
Das sind Programme, die durch ihre Bloße Einführung,
das zugrunde liegende Probleme ändern
Was ist ein Arbeitsbeschaffungsprogramm sozusagen? Jemand sagt,
ich möchte eine Lösung für ein Problem haben und durch die Lösung
des Problems wird in der Regel ein neues Problem geschaffen.
Das sind eingebettete Programme. Wenn man erstmal in dieser Art und Weise über Software nachdenkt,
dann kann man sich auch, also jetzt bin ich ja dabei,
also den Wasserfallmodellen, also so ein klein wenig zu sagen,
wir müssen da nochmal etwas weiter drüber nachdenken.
Wenn man in dieser Art und Weise über SP&E-Programme, wenn man weiß,
Es gibt diese Unterscheidung und die ist auch durch nichts aus der Welt zu schaffen,
weil es eine ziemlich tragfähige Klassifikation ist, dann sind,
wenn E-Programme das ist, womit sie später ihr Geld verdienen wollen,
dann brauchen wir eine tragfähigere Modellvorstellung als Wasserfallmodelle,
um erfolgreich in der Welt agieren zu können,
um angemessen in der Welt agieren zu können.
Und das hat Money Meyer Lehmann, Mann, Mann,
Mann, das hat der, also die Details können sie sich angucken,
zu den SP&E-Programmen. Das hat der als allererster,
hat er das veröffentlicht und das war schon, das war schon interessant.
Also als Informatiker so interessant finden, aber das hat einen schon gesagt,
aha, es gibt ein zugrunde liegendes Problem, das wir lösen müssen.
Und da kommen wir mit so einfachen Modellen,
kommen wir nicht hin. So in frühen Jahren,
nächster Name, also damit sie auf ihren Partys demnächst,
also beim Name-Dropping mitspielen können, Peter Nauer,
müssen sie auch fallen lassen können.
Der alte Däne
Der hat also sich ziemlich früh nur mit der Fragestellung beschäftigt,
ist diese Sichtweise, wie sie verkörpert wird durch Vorgehensmodelle,
wie das Phasenmodell, ist diese Sichtweise adäquat. Und das ist also eine Frage,
also der hat sich schon ziemlich früh gestellt,
also so, ich weiß gar nicht,
wann er also mit dieser Kritik angefangen hat,
aber ich glaube, das war auch schon Ende der 60er,
Anfang der 70er Jahre,
dass der sich also einen großen Namen damit gemacht hat und dafür hat er dann letztendlich auch den Turing Award so bekommen,
also das Äquivalent, die Alternative des Informatikers für den Nobelpreis,
den Thuring Award.
Den hat er dafür auch gekriegt,
weil er eben so grundlegende Arbeiten darüber gemacht hat.
Also wie kann man anders auf Softwareentwicklung schauen,
außer als in der Produktionssicht, als die Produktionssicht das hergibt.
So, bla bla bla. Sound, basic principles.
So, die grundsätzliche Idee, der Autor Kritikerzyklus.
Diese Folie wird jetzt also Alle von ihnen, jeden Einzelnen von ihnen nervös machen.
Und sie merken das nicht, dass es sie nervös macht.
Und deswegen werden sie jetzt übellaunig. Sie können auch aus anderen Gründen
übellaunig werden, aber diese Folie macht die Menschen typischerweise übellaunig.
Und sie macht sie übellaunig, weil die Pfeile gegen
den Uhrzeiger sind, sind. Nur einfach ist,
dass sie gucken, da draufkriegen, schlechte Laune wissen nicht,
warum, schieben es mir in die Schuhe,
aber das bin ich nicht.
Das sind die Pfeile, die sie jetzt gerade übellaunig machen.
Das ist so tief in unserer Kultur und ich schaffe das
seit 20 Jahren nicht,
die Folie zu ändern,
ist mir auch egal
Die andere, der andere Grund, warum mindestens die Wirtschaftsinformatiker
bei Ihnen unter Ihnen jetzt also anfangen nervös zu werden ist.
Wenn man mal aus einer Kostenperspektive auf das Phasenmodell schaut,
dann ist das ja für den Entscheider,
ist das ja eine klare Angelegenheit.
Es gibt einen Anfang des Projektes und dann sagt jemand,
in neun Monaten kriegst du dieses Ergebnis und es kostet
X und der Entscheider kann sagen,
ja oder nein
So, und dann geht es eben los. Aber der Entscheider ist erstmal,
also hat er das getan, wofür er bezahlt wird.
Er hat eine Entscheidung getroffen. Und er kann sagen,
auf welcher Grundlage er eine Entscheidung trifft.
Dass da die Grundvorstellung, also der Abkehr vom Phasenmodell,
wird unseren Entscheider nervös machen.
Das hat nämlich kein Ende. Wann hört das auf?
Was machen die denn da? Ach so, der guckt,
die erarbeiten eine Zielvorstellung. Ja, okay. Also Situationsbestimmung
, also wo sind wir jetzt
Und dann wird modelliert und konstruiert. Und dann erarbeiten sie
eine neue Zielvorstellung. Hallo, hört das irgendwann auf?
Nein. Erfolgreiche Softwareentwicklung hört nicht auf. Das wäre ja auch blöd,
wenn Microsoft jetzt sagen würde, wir hören mit Word auf, oder?
Das hört nie auf. Vielleicht hört es irgendwann auf.
Aber das sagt dann wiederum andere Gründe. Insofern ist das,
was ich Ihnen jetzt hier als,
also die grundsätzliche Idee zeige, dürfen Sie jetzt nicht gleich,
also betriebswirtschaftlich, hat sich wieder irgendein Informatiker was ausgedacht.
Das klappt vorne, wird zwar klappen, ist aber nicht finanzierbar,
das ist nicht die Idee. Die Idee ist einfach,
Wir wollen Softwareentwicklung als ein Autor-Kritikerzyklus begreifen. Und jetzt,
wenn wir das also in diesem Kreislauf oder in diesem Kreislauf lieber,
wenn wir das einmal so verstanden haben,
es gibt keine Alternative dazu, Softwareentwicklung als Lern- und Kommunikationsprozess zu begreifen,
dann müssten wir uns so die nächste Frage stellen,
wie kriegen wir das, also betriebswirtschaftlich sauber auf die Spur gebracht.
Aber das verspreche ich Ihnen, ist eine lösbare Aufgabenstellung.
Das ist eine lösbare Frage. Zunächst mal möchte ich Sie davon,
also damit möchte ich Sie jetzt eigentlich auch schon gehen lassen,
Weil das ist jetzt ein ganz, ist jetzt ein ganz so,
das ist ein wirklich hübscher Cut, den man jetzt hier machen kann.
Ich habe jetzt also in den vergangenen, also 75 Minuten,
habe ich rechnen kann er auch nicht.
Also jetzt so seit Viertel nach zwei jedenfalls, habe ich mich bemüht,
ihnen mal so, so das Problem fällt aufzuspannen,
das so mit Entwicklung von großen Softwaresystemen,
wie sie jetzt sagen können,
von E-Programmen.
Also welches Problem da eigentlich zu bearbeiten ist
Und ich möchte nicht, dass sie also in die Welt gehen,
also nach dann ihren sechs oder sieben Semestern,
die sie hier möglicherweise nur verbringen und denken,
gebt mir eine Spezifikation und ich löse dieses Problem,
in dem ich es implementiere und alles wird gut sein.
Das ist zwar die Wahrheit, aber es ist nicht die ganze Wahrheit.
Es wird ihnen niemand eine große Spezifikation geben und ihnen auf den Hinterkopf tätscheln,
wenn sie die drei Monate später implementiert haben.
Ich halte das für extrem unwahrscheinlich, dass das ihren beruflichen
Alltag ausmachen wird. Und sie haben jetzt erstmal mitgenommen,
also wir haben diese, Es gibt eine Modellvorstellung namens Phasenmodell,
die hat Stärken, die hat Schwächen.
Es gibt eine Klassifikation von Programmen und es gibt Hoffnung.
Es gibt Hoffnung, weil es gibt zyklische Vorgehensmodelle,
mit denen können wir die Schwachstellen, die Schwachstellen von linearen Vorgehensmodellen lösen.
Und dann hoffe ich, sie nächsten Freitag, oh Gott,
das ist der Freitag nach dem Donnerstag nächste Woche.
Gut, also dann hoffe ich,
dass ich dich nächste Woche Freitag sehe.
Ich lade sie natürlich auch herzlich gerne ein
Tja, und ich, die letzte Hoffnung, die ich habe,
dass sie diese Vorlesung nicht unter dem Motto verbuchen.
Ich weiß jetzt etwas, von dem ich noch
gar nicht wusste, dass ich es nicht wissen will.
Also wir sehen uns am Freitag oder auch nicht.