Dies ist nun der inhaltliche Stadt der Lehrveranstaltung, der Vorlesung,
Softwareentwicklung 2, das wird jeweils so stattfinden,
dass von meiner Seite die konzeptionellen Dinge kommen,
Detlef Litterst wird etwas Praktisches machen,
wir nennen das Hands-on-Teil und beides zusammen,
er sollte hoffentlich für sie gut anschaulich gut verständlich sein und wir bitten Sie,
sammeln Sie Ihre Fragen,
bereits während dieses Wertes Anschauen des Videos,
damit Sie die Fragen dann in der Fragerunde zur Mittwochs
jeweils 15,
15 stellen können
Sie können die Fragen natürlich vorher auch schon einstellen oder im Forum stellen,
aber diese Zeit ist dann die, dort werden wir weiter die Fragen beantworten.
Wir starten jeweils und wir führen,
organisieren die Veranstaltung jeweils entlang solcher Fragen,
die Fragen zur Prüfungsvorbereitung sind auch sozusagen, wenn sie wollen,
Musterklausur fragen, die sich über die Jahre gesammelt haben,
sodass sie also hier schon ein Beispiel bekommen,
was von ihnen in der Prüfung verantwortlich verlangt wird.
Hier sehen Sie schon, dass wir uns hier,
das sind die Fragen 1 bis 5, dass wir uns heute mit Komplexität beschäftigen
Und fragen sechs bis acht mit Modellierung. Wir knüpfen jeweils
an SE1 an. Das heißt, die Themen,
diese Themenbereiche, die sie in SE1 kennengelernt haben,
die werden wir hier, an die werden wir anknüpfen.
Zunächst möchte ich anfangen, damit etwas zu Komplexität zu sagen.
Kleine Systeme und große Systeme gegenüber zu stellen. Kleine Systeme ist etwas,
zum Beispiel hier einen kleinen Konvertor für irgendetwas,
was sie auf dem Smartphone gerne hätten.
Ja, das können sie vielleicht selbst entwickeln.
Hoffen wir, dass sie das können. Ja,
man braucht nicht irgendwie ein Zertifikat, einen Abschluss,
Gerade von der Uni, man muss keinen Meisterbrief dafür haben.
Und sie sind selbst der Nutzer. Also würden sie auch
nicht nur sich nicht beschweren, sondern sie haben auch direkte Kommunikationswege, wenn was nicht funktioniert.
Große Systeme, damit meine ich sowas wie Amazon,
Facebook, Google, Twitter, diese wirklich großen Systeme,
die erfordern, dass große Teams zusammenarbeiten.
Aber nicht nur viele Leute, sondern wir brauchen auch Spezialisten.
Spezialisten für verschiedene Themengebiete, die das Ganze dann beherrschen in seiner Größe.
Also solche Sachen wie, ich brauche für die Administration der Datenbank,
das kann nicht jeder. Für Verschlüsselung sollte nicht jeder Informatiker
dran sich vergreifen, er macht immer die gleichen Fehler.
Parallelität, Nebenläufigkeit ist ein wichtiges Thema. Wie sorge ich
für Auflag? Ausfallsicherheit oder einfach nur Verteilung auf tausende verschiedene Plattformen
. Das ist eine Herausforderung. Für manche Systeme brauche ich
auch eine berufliche Qualifikation, die eine Zertifizierung erfordert.
Ja, also zum Beispiel für die,
alles was mit Sicherheit zu tun hat.
Oder ich und, nicht unten, nicht, oder?
Ich brauche auf jeden Fall
eine Menge an Erfahrung und ich brauche ein strukturiertes Vorgehen
Vorgehensweisen, die in denen Erfahrung steckt. Technologiewissen und ich brauche auch Planung.
Ich möchte drei kleine Sachen vorstellen hier aus jüngere und aus älterer Zeit,
wo mal so etwas schief gegangen ist,
wo die Komplexität nicht beherrscht werden kann.
Hier habe ich etwas mitgebracht, eine Bundesagentur für Arbeit.
Es ist eine große Behörde im öffentlichen Dienst,
jeder oder ganz viele Menschen, hoffentlich nicht.
Jeder ist dort in irgendeiner Form damit in Kontakt,
insbesondere wenn man Weiterbildungsmaßnahmen hat,
wenn man Arbeit sucht,
wenn man arbeitslos ist
Die haben einen großen, ich sag mal, Zoo an IT-Systemen,
die im Laufe der Zeit für die verschiedenen Aufgaben gewachsen sind.
Und es war gedacht, dass man
das Ganze zusammenführt unter einer Oberfläche, nicht verschiedene Systeme.
Gerade, dass es Datenübergang ist. Ich muss die Daten
nicht dreimal eingeben. Oder ich kann querbeet was prüfen.
Was ist denn da mit der Person dort los unter Deto,
was gibt es ja für Förderungen? Also diese ganzen Sachen,
jeder graue Kasten steht hier für ein System,
das wollte man integrieren, 14 Systeme insgesamt.
Es wurde davon gesprochen, dass 60 Millionen Euro Kosten geplant sind.
Es sollte sieben Jahre dauern, also den Kosten kann man ungefähr rechnen,
dass 500 Personen Jahre, 500 Personen,
ein Jahr lang oder durch sieben halt ungefähr 70 Personen,
die sieben Jahre lang dran arbeiten sollen.
Also wirklich schon ein großes Projekt.
Aber das ist jetzt mittlerweile schon drei Jahre her.
Die Software hat das, hat diese Erwartung nicht erfüllt.
Das Projekt musste gestoppt werden. Ja, es ließen sich,
es waren Fehler drin, die man erst zu spät gesehen hat.
Und am Ende kam es vor der Pilotphase zum Abbruch.
Ja, Pilotphase bedeutet, die Software war eigentlich fertig.
Sie sollte erst mal bei einer kleinen Gruppe eingeführt,
zum Beispiel wenigen Arbeitsämtern oder wenigen Abteilungen
eingeführt werden
Man Erfahrung sammelt und dann macht man es überall.
Ja, also eigentlich war die Software fertig.
Und es waren aber nicht irgendwie nur Programmierfehler, ja,
sondern man hat es einfach nicht beherrscht, so viele Anforderungen,
so viele Randbedingungen aus diesen ganzen Systemen hier zusammenzufassen.
Und gleichzeitig passieren ganz viele Änderungen. Die gesetzlichen Rahmenbedingungen ändern sich ganz häufig,
manchmal optimiert man auch Abläufe und man hat nicht diese
sieben Jahre Dauer unbeeinflusster Arbeitszeit, sondern auch alles,
was in diesen sieben Jahren passiert,
muss eingebaut werden
So, dieses Projekt wurde gestoppt,
es war einfach nicht beherrscht worden auf der Grund der Komplexität.
Ich möchte, ich sage das, um zu sagen,
worum Komplexität besteht. Ein anderes Beispiel, schon ein kleines bisschen,
ja, auch ungefähr im Juli 2018 gestoppt.
Lidl wollte einen wahren Wirtschaftssystem einführen. Waren Wirtschaft,
da geht es um Aufträge, Bestellungen, Lagerbestand,
so etwas. Es gab vorher ein eigenes Warenwirtschaftssystem,
was etwa 30 Jahre schon seit der Entwicklung im Betrieb war.
Gupta war, das ist ein Datenbanksystem, war die Basis
davon und man hat versucht, SAP Retail einzusetzen.
Ja, man hat das 2011 gestartet, bis 2018. Hier
wird es also gestoppt. Und man soll, wollte alles darüber abwickeln.
Sie wissen, Lidl ist nicht nur in Deutschland tätig,
sondern weltweit oder in ganz vielen Ländern jedenfalls.
10.000 Filialen, 100, 140 Logistikzentren und ganz viele IT-Systeme,
zu denen man Schnittstellen haben möchte.
Es ging insgesamt um Einkauf, Steuerung der Filialen.
Also wer bekommt was, was läuft wo.
Und Transport, also welcher LKW hat was mitzunehmen.
Und auch, wie sieht das mit den Angeboten aus
Das Problem war, es gibt ganz viele Besonderheiten,
Besonderheiten im Unternehmen, Lidl, Besonderheiten in den Abläufen,
vielleicht auch Besonderheiten der Filialen, so ganz genau weiß ich das nicht.
Und man musste dann sagen, es gibt Stoßzeiten.
Diese Stoßzeiten sind kurz vor Weihnachten über Feiertage, Ostern ist ein gutes Beispiel.
Und der Entwicklungsaufwand um diese ganzen Besundheiten umzusetzen,
der war sehr hoch und es war abzusehen, dass die Performance nicht reicht.
Nun ist das nicht ein Problem, allein dieses SAP Ritel,
SAP, die Waldorfer Softwarefirma, die namhafte IT-Firma aus Deutschland,
die auch weltweit eine Bedeutung hat, die kennen Sie auf jeden Fall.
Daran liegt es nicht allein, weil SAP-Ritel bei Aldi Nord
zum Beispiel erfolgreich im Einsatz ist. Man hat dieses Projekt gestoppt,
man hat 500 Millionen Euro einfach nur so verbucht, als wir haben eine Erfahrung gewonnen.
Also Komplexität hier im Sinne von ganz viele Besonderheiten und gleichzeitig noch große Lastforderungen,
wenn Sie sich vorstellen, welche Mengen von Daten hier dahinterstehen.
Ein weiterer Punkt, der schon ein bisschen älter ist,
Es geht hier um ein Bestrahlungsgerät, ja,
ein Bestrahlungsgerät mit starkem Elektronenstrahlbestrahlung, kennen Sie aus der Krebsbehandlung,
die Bestrahlung stört das kranke Behebgewebe mehr,
als das Gesunde, weil halt da schneller Zellteilung stattfinden.
Und man hat hier ein System entwickelt, das ging also
um die 80er Jahre hier, wo ein Computer zur Steuerung eingesetzt wurde.
Schon das voragende Modell war durch Computersteuerung, war gekennzeichnet. Ja,
also hier ist ein Bild davon, man hat einen,
wenn Sie so wollen, einen Bunker,
der die Strahlung abschirmt, dass keine Strahlung entweicht.
Da gibt es ein Gerät, wo der Mensch drauf liegt
und die Strahlenkanone dann irgendwie auf den Körper gerichtet wird.
Das war mit einem PDP11, es ist schon ein mittelgroßer Rechner,
gesteuert und das war in der Semplersprache damals programmiert,
also sehr maschinennah.
C ist im Vergleich dessen schon eine Hochsprache, also nicht mehr so Maschinen.
Diese Computersteuerung war aber auch vorher ohne Sicherheitsfunktion. Es war eine Konsolenbedienung,
das heißt, man hat zum Beispiel keine Maus gehabt,
keinen grafischen Bildschirm,
sondern Zeicheneingabe
Das war dadurch gekennzeichnet, dass es viele Fehlermeldungen gab,
die man dann in irgendeiner Form im Handbuch nachschlagen musste,
aber gleichzeitig war das Handbuch nicht so richtig toll.
Und es kam dazu, dass durch Überdosierung Todesfälle aufgetreten sind.
Die Ursache waren aber nicht einfach pure Programmierfehler,
sondern die waren im Zusammenwirken zwischen, die Menschen müssen das System verstehen,
das System muss steuerbar sein, die Steuerung muss das darstellen,
was das System gerade für einen Zustand hat.
Und da kam es eben zu Bedienfehlern und gleichzeitig auch zu Fehlern Softwareablauf,
gerade zum Beispiel war hier die Programmierung mit globalen Variablen und
dann wurde das überschrieben und man hat diese Fehler beim Test nicht wirklich gefunden.
Und Ursache war unter anderem, dass von der ganzen,
vom ganzen Aufbau der Software das für sicherheitskritische Anwendung nicht vorbereitet war.
Man hat es einfach nur erweitert und weitere Funktionen,
aber die kritischen Softwareteile wurden nicht stärker geprüft und sie waren
gar nicht so stark getrennt. Und ein letztes Beispiel,
1993 gab es einen Absturz eines oder einen Unfall mit einem Flugzeug in Warschau
Hier geht es auch wieder darum,
es ist nicht reiner Programmierer, ein breiner Programmierfehler,
sondern eigentlich das komplexe Zusammenwirken eines Systems bei vielen Zusammenhängen.
Es geht hier um Schubumkehr, hier ist mein Foto gezeigt,
wo so eine Schubumkehr passiert, wenn sie hier drin sitzen,
können sie sowas beim Landen beobachten.
Da gehen solche Klappen an den Turbinen auf. Und dadurch
wird der Luftstrom, der sonst nach hinten Schub erzeugt,
wird nach vorn gelenkt und erzeugt einen Bremsmoment.
Das Bremsen darf natürlich nicht immer passieren,
solange man in der Luft ist,
weil sonst das Flugzeug zu einem Stein wird und nicht mehr
vom Vogel bleibt
Und deswegen muss man dafür unbedingt sorgen, dass das nicht in der Luft passiert.
So, und man macht das, man macht das eigentlich davon,
vom Boden kontaktabhängig. Also wenn das Buch Flugzeug aufsetzt,
das sind ja viele Tonnen, das Rad meldet, ja,
da gab es einen Bodenkontakt, erst dann Schuhumkehr freigegeben.
Ja, so, und jetzt war,
und da gibt es eine Computersteuerung dafür, separat von anderen Sachen,
das ist ein sehr kritisch sicherheitskritisches System.
Ja, und jetzt war eine besondere Situation bei diesem,
an diesem Tag, in diesem Flug bei dieser Landung in Warschau.
Es war sehr wechselhafter Wind und die Informationen über diese schwierigen Windverhältnisse
also Böhnen sozusagen, waren da nicht so bekannt.
Das Flugzeug hat, weil der Pilot das nicht wusste, seitlich aufgesetzt.
Und seitlich bedeutet es erstmal nur ein Rad drauf, nicht beide.
Und das wurde diese Meldung Bodenkontakt vermutlich nicht gemacht.
Und dadurch kam es erst zu spät zum Bremsen.
Und das Flugzeug ist über die Landebahn hinaus geschossen.
Es ist auf einen Erdwahl aufgeprallt. Es brach ein Feuer
aus. Wir können von Glück reden. In dieser Situation
, es konnte noch erfolgreich eine Evakuum durchgeführt werden.
Und es gab nur zwei Todesopfer, obwohl das Ding gebrannt hat.
Die Ursache sind nicht reine Softwarefehler, dass man sagen könnte,
okay, nicht ordentlich getestet oder so
Das Ganze, die Anleitung war irgendwie nicht so ganz eindeutig.
Es war nicht vorgesehen, dass der Mensch sagt,
ich will jetzt aber stoppen, stopp, stopp, jetzt,
ja, war nicht möglich, weil die Steuerung gesagt hat,
nein, das sind noch nicht beide Räder aufgesetzt,
hier passiert nichts.
Und diese Informationen, die Windverhältnisse, wenn der Piloti gehabt hätte,
wäre das vielleicht nicht aufgetreten, da wäre anders gelandet.
Ja, so, also das sind Ursachen, die aus Komplexität realisieren.
Das Ganze war das Vorgespann dafür, um zu sagen,
es gibt Softwareentwicklung, Großen, Softwareentwicklungen klein und was Komplexität bedeutet.
Komplexität bedeutet für uns, es gibt viele Anforderungen,
viele Randbedingungen
Es gibt viele Beteiligten. Wir brauchen diese mehreren Disziplinen.
Wir hatten vorhin von Spezialisten gesprochen. Manchmal gibt es viele beteiligte Systeme.
Die sind unterschiedlich entwickelt auf unterschiedlichen Plattformen mit unterschiedlichen Philosophien auch entwickelt.
Wir haben Schnittstellen zu solchen externen Systemen und Schnittstellen zur Umgebung.
Das ist die eine Seite, die das Ganze kompliziert macht.
Speziell oder bei dem Arbeitsamtbeispiel und bei dem Lidl-Beispiel spielt auch Veränderung eine große Rolle.
Veränderungen im Sinne von, wir ändern die Anforderungen. Das,
was der Kunde am Ende braucht, was die Firma braucht,
das ändert sich. Zum Beispiel, weil man Workflows umstellt,
weil der Markt sich ändert oder manchmal auch sich Gesetze ändern.
Also Randbedingungen oder die Organisation ändert sich. Eine Firma wird
gekauft von einer anderen oder man macht ein Mörture oder man
organisiert das um als wirtschaftlichen Gründen in einzelne GmbHs,
die sich dann wechselweise Rechnungen stellen.
Und natürlich nicht zu vergessen, die Technik entwickelt sich auch weiter.
Irgendwann gab es den Wechsel von Windows XP zu Windows 7
und dann irgendwann die Abkündigung von Windows 7 zu Windows 10
und da muss man mitmachen.
Man kann nicht bei der alten Version bleiben. Das macht es
schwierig. Und diese Dieser Effekt wurde als Softwarekrise bezeichnet.
Diese Bezeichnung ist schon ziemlich alt. Ja, und man
hat dann gesagt, okay, was ist denn Softwarekrise?
Ja, Termin und Budget wird nicht eingehalten.
Und die Ursache hat man darin gesehen,
dass Aktivitäten und Prozesse so schlecht planbar sind.
Das Ergebnis erfüllt nicht die Erwartungen der Auftraggeber.
Offensichtlich ist das nicht so klar und nicht gut nachverfolgbar,
was da gebraucht wird. Es werden Dinge immer wieder entwickelt,
weil es zu wenig Wiederverwendung gibt.
Man fängt, man fängt mit halbwertigen Ständen an,
ja,
man geht nicht systematisch vor
Es gibt häufig Missverständnisse zwischen diesen vielen Beteiligten.
Sie wissen das alle, da gibt es dieses Spiel,
die stille Post, das, was man sagt,
ist nicht unbedingt das, was man versteht.
Und die Integration ist sehr schwierig und natürlich Dokumentation ist ein Dauerproblem.
Häufig auch dadurch geprägt, dass zu viel Zeitdruck herrscht und
zu wenig Geld bezahlt werden will.
Ja, also die Prozesse und der Markt,
das passt nicht so richtig zusammen.
Wie man damit umgehen möchte, ist als Lösung, Ingenieur gemäße Entwicklung.
Also man sagt, die Ingenieurdisziplin, die schaffen das ja auch.
Auf dem Bau, bei Maschinen konstruieren,
sind auch viele Gewerke beteiligt,
viele Spezialisten
Man schafft es, sichere Systeme zu bauen. Bei Surfwareentwicklung muss das auch
so sein. Wir wollen diese verschiedenen Punkte kurz durchgehen gemeinsam.
Fangen wir mit dem ersten an, Qualitätssicherung und Entwicklung sollte verwoben sein.
Manche von manchen Leuten hört man manchmal in Projekten, ja,
wir programmieren das mal und später testen wir, sofern noch Zeit ist.
Das geht nicht. Man kann nachträglich nicht Qualität hinzuzufügen,
was man vorher falsch gemacht hat,
kann man nachher nicht mehr verbessern, nicht in dem Umfang.
Oder man sagt, ja,
für die Testen sollen die Entwickler das selbst machen.
Nein, das ist eine Aufgabe des gesamten Teams der
gesamten Projektorganisation
Und also ja, und man muss natürlich das Ganze auch aufbewahren,
weil in Tests steckt eine Menge auf einen drin.
Und dann kann man die wiederverwenden. Und Test First,
das ist das, was sie bei uns sind,
SE1 sind, SE2 immer hören.
Zuerst entwickelt der Test und dann entwickeln der Software zu diesem Test.
Es kostet nicht mehr Aufwand, ich muss es ja sowieso machen.
Aber genaue Testfälle liefern erstmal genaue Informationen. Ich fange nicht irgendwie an,
also gerade eine genaue Verhaltensbeschreibung bekommt aus dem Test raus,
welche Sonderfälle, welche Ausnahmefälle.
Und das hilft uns
Der nächste Punkt von dieser Liste der Ingenieurgemäßen Tätigkeiten war systematisches und methodisches Vorgehen.
Systematisch heißt, wir machen es immer wieder genauso.
In der Anfangszeit der Programmierung wollte man den Entwicklern völlig freie Handel,
so quasi wir sind die Designer, wir sind die Künstler.
Es zeigt sich, dass man für das Wiederverwenden von Erfahrungswissen,
sollte man auch die vorgezeichneten Wege, die Wege,
wo man erfolgreich geht, nutzen.
Ja, also Vorschriften machen, Fehler vermeiden, dadurch,
dass man eine Vorgehensweise vorgibt und auch diszipliniert diese Vorgehensweise folgt
Und auch Arbeitsteilung erfordert, dass man das gut organisiert,
dass man es gut ab miteinander abspricht.
Manche sagen, ja, Bürokratie. Tatsächlich wird die Flexibilität geringer,
wenn wir solche Vorgehensweisen einführen, wenn wir genaue Absprachen treffen.
Aber wir können das auch durch agile Prozesse verbessern.
Agile Prozesse sind auch basierend auf Erfahrungen. Wie kann ich
flexibel reagieren und trotzdem das gut machen? Oder man sagt,
ja, jedes Projekt ist irgendwie einzeln und man kann Lösungen nicht wiederverwenden.
Nein, es gibt bestimmte Bestandteile von Lösungen,
die kann man sehr wohl wieder verwenden. Erfahrungswissen sammeln,
das ist gerade das Wesentliche von Ingenieurdisziplin und durch Verbessern eben weiternutzen.
Zum Beispiel, wie Sie eben schon gesagt, Testfälle,
ich zeichne die Testfälle auf, kommt ein neuer Bug hinzu,
kann ich beim nächsten Mal diesen Bug hinzugefügt,
die Tests umfangreicher gestalten.
Planung als wichtigen Punkt. Ach, es gibt so viel Unbekanntes,
ich kann das nicht planen. Doch, Aufeinschätzung kann man
schon tun. Und je genauer man eine Aufentschätzung machen kann,
desto weniger sind im Projekt ein Hektik oder Geldmangel,
dass man die Sachen auch ordentlich machen kann
Oder wir können nicht so richtig gut planen.
Deswegen können wir kein korrenzfähiges Angebot machen. Und dann machen wir
dann entweder Dumping-Angebote oder zu teureren kriegen den Auftrag nicht.
Je mehr wir wiederholbare Prozessschritte machen, gerade die Systematik von der vorhangigen Innenfolie,
desto besser ist es und desto genauer können wir schätzen.
Wir wollen standardisieren, wir wollen modularisieren, wir wollen wiederverwenden.
Ja, es gibt leider viele Entwickler, die sagen,
ach nein, wer weiß, was das ist,
ich baue das lieber selbst.
Es ist immer besser, etwas zu verwenden,
was schon reif ist
Was schon entwickelt, was schon sein,
wo schon viel Erfahrung in die Verbesserung geflossen ist,
auch wenn man zu Anfang vielleicht nicht kennt.
Man kann, dass Sachen gut für Wiederverwendung entwickeln,
muss sich aber im Klaren sein, dass es dafür,
wenn etwas für Wiederverwendung entwickelt, den Höreraufwand braucht.
Hören Aufwand für höhere Qualität, hören Aufwand für Hörer, Allgemeingültigkeit.
Also durchaus Faktor 3 ist durchaus realistisch. Andere sagen,
ja, super, Code-Generierung,
gerade der Manager lassen sich gerne von Tool-Versprechungen ködern und sagen,
ja, super,
Generierung,
ich drücke nur auf den Knopf
und alles ist fertig
Oder Programmierer sehen, dass so ein Gegenteil die sagen,
ach, es ist so eine Qual, mit dem Generator zu arbeiten.
Ich habe da meine Protected Regions und wer weiß,
was da beim nächsten Generatorlauf rauskommt und der Generator hat auch noch ein paar Wachs.
Ja, Workarounds um die Fehler des Generators herum kosten so viel Aufwand.
Ja, beide Seiten sind richtig. Einerseits steigert das die Produktivität,
andererseits ist das teilweise wirklich schwierig,
aber wenn wir schematische Kurzteile haben,
wo jeder Abschnitt sich nur durch geringe Unterschiede unterscheidet,
ist es gut möglich,
auch einen Generator einzusetzen
Wissen sammeln, akkumulieren, zusammen sammeln von Wissen, von Erfahrungen.
Das ist eine ganz wichtige Weisheit der Ingenieurdisziplin. Im Maschinenbau
würde man auch nicht alles neu entwickeln. Und es gibt
eben der Informatik auch Bereiche, wo man Wissen gut sammeln kann.
Sie alle haben schon von Design Patterns gehört,
wir haben diese Veranstaltung auch noch ein paar mehr, Heururistiken,
also Erkenntnisprozesse, die man in irgendeiner Form gut strukturiert,
Architekturstile, so was wie Patterns auf höherer Ebene, Refactorings,
Wege, wie ich etwas wiederholt oder nach Folgen von systematischen Schritten verbessern kann,
Frameworks, Bausteine von Zusammengehörenden, Sachen mit gutem, auf Einsatzwahrscheinlichkeit.
Und Arbeitsteilung ist ein ganz wichtiger Punkt. Manch einer denkt,
ach, ich das jemandem erklärt habe,
mache ich es lieber selbst oder die Manager denken,
ja, super, gebe ich nach Indien,
gebe ich in die tschechische Republik, da ist es billiger.
Beides hat seine Vor- und Nachteile,
wir müssen einfach sehen, Arbeitsteilung müssen wir unbedingt machen,
weil sonst kriegen wir große Systeme nicht hin,
Spezialisierung müssen wir unbedingt machen, aber Arbeitsteilung erfordert mehr Absprachen,
erfordert mehr systematisches Vorgehen, Vor allem nicht die Flexibilität.
Ja, soweit zu den Ingenieurmäßigen Sachen. Damit haben wir
die Fragen eins bis sechs beantwortet, die Herausforderungen haben sie gemerkt.
Wir hatten diese Merkmale von Softwaresystemen, die die Komplexität zeigen
, dargestellt. Ich springe mal schnell dahin. Das war
, glaube ich, irgendwo hier. Genau, was ist
die Komplexität? Wodurch ist die gekennzeichnet
Die nächste Frage wird auch auf dieser Folie beantwortet.
Was sind, wo kommen Veränderungen her? Das ist auch hier,
also Veränderungen kommen einerseits von aus diesen drei Quellen,
aus geänderten Anforderungen, aus Änderungen von Randbedingungen,
aus Änderungen, Weiterentwicklung der technischen Plattformen.
Und diese Kennzeichen der ingenieurgemäßen Entwicklung, das war das,
was wir jetzt, was wir jetzt gerade hatten,
nein, noch eins weiter,
diese sechs Punkte sind wir gerade einzeln durchgegangen.
Das nächste Teil kommt in einem separaten Abschnitt