Herzlich Willkommen zu dieser Vorlesung für den Dienstagsteil in diesem Semester.
Ich begrüße Sie ganz herzlich, jetzt geht es richtig los. Ich möchte Ihnen kurz vorstellen,
was ich hier mitbringe und dann steigen wir ein ins Kapitel
1. Wir haben neben dem in dem Material,
was Sie finden, die Vorlesung, die Fullin,
die Sie vielleicht schon heruntergeladen haben, finden Sie,
werden Sie Stellen finden, wo die nicht ganz vollständig sind.
Also natürlich gibt es einerseits die Aufzeichnung als Video,
das, was Sie sich gehört anschauen,
aber es gibt die ganze Vorlesung lebt von Ihren Mitschriften
Ich habe diese Mitschriften für extra diese Online-Situation etwas verringert.
Normalerweise würden wir viel mehr an der Tafel arbeiten.
Vollständig sind die Vorlesungen, sind die Materialien aber
nur für Definitionen, für viel Text oder umfangreiche Bilder.
Aber ich habe über die Jahre bemerkt,
es bleibt mehr hängen, wenn man selbst etwas tut.
Dieses Selbst etwas tun ist ein ganz wichtiger Punkt,
dass man andere Bereiche seines Gehirns beansprucht,
dass man das besser verarbeitet, Wissen strukturiert.
Es wird am Ende so sein, dass ihre,
die Mitschriften mit Fuldigen gemeinsam am Ende mehr zu ihnen spricht,
bei der Prüfungsvorbereitung und vielleicht werden sie später auch nochmal reinschauen.
Deswegen machen sie sich Notizen, schreiben sie sich so etwas mit,
so wie wir es sonst vielleicht in der Tafel hätten.
Mein Vorschlag, drucken sie sich die Folien aus,
schreiben sie, dass sie Platz haben, etwas dran zu schreiben,
also zum Beispiel zwei Follien auf eine Seite,
ist ein gutes Format.
Und behalten sie das gemeinsam mit ihren Notizen?
Das Handschriftliche ist das, was ihnen später auch was bringt,
weil sie sehr selbst ein das Gehörte besser erinnern
Selber die Gedanken besser verinnerlicht haben. Vielleicht kennen sie den Effekt vom Spielzettel,
wenn sie das Wissen selbst gut strukturiert haben,
brauchen sie den Spickzettel am Ende gar nicht mehr,
weil sie es in ihrem Langzeitgedächtnis haben.
Es geht hier bei Softwaretechnik um Wissen, was sie für ihren Beruf brauchen,
was sie in ganz verschiedenen Bereichen des beruflichen Alltags brauchen.
Auch wenn es vielleicht für den einen oder anderen noch weit weg ist,
andere wiederum von ihnen arbeiten bereits als Informatiker und wissen vielleicht,
umso mehr zu schätzen, dass man im beruflichen Alltag solche, welches Wissen braucht.
Hier bieten wir ihnen in dieser Veranstaltung Berufsqualifizierendes Wissen,
das sollten sie für lange Zeit aufrechterhalten und deswegen diese Sache mit dem handschriftlichen ergänzt.
Als Bücher empfehle ich Ihnen neben den Sachen,
die wir schon genannt haben, für die gesamte Veranstaltung,
vor allen Dingen, schaffen Sie sich ein UML-Buch an.
Damit mit anschaffen meine ich, dass Sie es wirklich besitzen, und zwar als Hardcopy. Mein Vorschlag ist,
das darf durchaus ein Gebrauchtes sein,
also auch ältere Auflagen sind geeignet, solange UML 2 draufsteht,
die ganz alten, wo nur UML draufsteht,
dass das nicht geeignet, mein Favorit ist UML2,
klar, ist klar, davon standen auch einige der Bilder,
die ich hier zeige,
aber es gibt noch weitere Bücher,
die sehr gut geeignet sind
Meistens sind die UML-Bücher sorge, dass ein Teil Anwendungsbeispiel sind ein Teil der Modelle.
Wir werden relativ viel mit UML machen in dieser Veranstaltung.
UML ist Industriestandard, sie sollten sich sowas,
das sollte man selber als Arbeitsmaterial haben.
Und wenn sie es selbst besitzen, können sie auch was reinschreiben,
können sie sich ein buntes Fähnchen dran machen.
Ach, hier fängt das Aktivitätsdiagramm der UML an.
Und dort habe ich das Anwendungsbeispiel zum Aktivitätsdiagramm. Und da
auf diese Weise erschließen sie sich nach und nach mehr Inhalt.
Ich werde gelegentlich darauf zurückkommen
Die Gliederung der Folie, der Vorlesung ist im Wesentlichen vier Teile,
diese vier Teile finden sie so auch im Mullmuddel und für jeden
dieser vier Teile gibt es eine Datei mit Folien an PDF,
was sie sich herunterladen können.
Wir haben jeweils untersetzen das durch ganz viele andere Dinge.
So, nun steigen wir ein in den Abschnitt 1,
Anforderungsbeschreibung mit UML. Dieser Abschnitt wird uns über die nächsten
Wochen begleiten und wir haben hier in diesem Video zunächst erstmal
den ersten Abschnitt 1.1,
die frühen Phasen
Ich möchte das motivieren, indem ich mit Ihnen
gemeinsam durchgehen möchte, womit, was brauchen wir eigentlich?
Zusätzlich gibt es zu jedem dieser Abschnitte solche Fragen.
Sie können das als Altklausur fragen, durchaus sehen. Das sind Fragen,
an die Ihnen schon einen Überblick über den Inhalt geben.
Hier also zum Beispiel für den ersten Abschnitt ist diese Frage eins gedacht.
Die sind Beispiele für Prüfungsfragen, die sind aber auch
gut zur Wiederholung geeignet und für die eigene Wissenskontrolle.
Können Sie das, was hier gefragt wird?
Gut erklären. Es könnte durchaus passieren,
dass die eine oder andere Frage wirklich in der Klausur vorkommt.
Aber ich versuche sie eigentlich ein bisschen abzuwandeln
So, lassen Sie uns damit starten, was wir eigentlich brauchen.
Und zwar, was brauchen wir über Programmierung hinaus?
Programmierung haben Sie bei SE1 und SE2 gelernt.
Sie haben das Umgehen mit der Programmiersprache gelernt,
beziehungsweise die Zessler in Ihrer Programmiervereinsprache, Nährveranstaltung.
Und da war die Programmiersprache im Fokus. Doch wir brauchen
noch weiteres. Und das ist hier der kritische Punkt.
Was brauchen wir dafür? Industrielle Projekte brauchen ein professionelles Vorgehen.
Und das ist genau das, was je nach dem Begriff Softwaretechnik steht,
der nahm in dieser Lehrveranstaltung, auf Englisch heißt das Software Engineering.
Und zwar geht es uns um die Herausforderungen für industrielle Softwareentwicklung.
Wir haben im Wesentlichen mehrere große Punkte, die im Wesentlichen
dazu beitragen, daher kommen, dass die Projekte groß sind.
Ja, also wir fangen mal damit an.
Also ich wechsle jetzt in den Handschriftmodus, es wäre gut,
wenn sie auch was zu schreiben haben,
dass sie das nach und nach mitmachen,
wenn sie nur das Foto vom letzten Bild vor dem Weiterschalten behalten,
ist das nicht das Gleiche
wie in sich selbst mitgespielt
Und schreiben sie sich durchaus mehr mit, als ich hier aufschreibe.
Ansonsten, ich bemühe mich um eine leserliche Handschrift.
Dieser Schriftstift funktioniert relativ gut, dass sie ein klares Bild sehen.
Und wenn sie das immerhin schaffen, mitzuschreiben,
was ich aufschreibe, dann sollten sie auch mit der Geschwindigkeit mitkommen,
wenn sie mehr aufnotieren von meinen Sachen, die ich sage,
wäre das natürlich für sie durchaus in manchen Situationen hilfreich.
Also zunächst haben wir, ist der industrielle Alltag davon gekennzeichnet,
dass wir große Projekte haben und große Projekte erfordern Mitarbeit von
mehr,
von vielen Personen
Und diese vielen Personen müssen natürlich Arbeitsteilung miteinander machen,
das war falsch, das können wir hier wieder machen, so.
Und diese Personen müssen miteinander kommunizieren.
Gleichzeitig haben wir komplexe Projekte,
komplexe Situationen
Komplex meine ich nicht nur, dass es viele verschiedene Sachen gibt,
die in so einem Projekt zu betrachten sind,
sondern zum Beispiel auch sowas wie, dass wir ganz verschiedene Technologien haben.
Also wir haben eine Datenbank mit Replikationen,
wir haben ein Verschlüsselungssystem, wir haben eine verteilte Umgebung,
wir haben Maßnahmen für Ausfallsicherheit, wir bedienen mehrere Plattformen.
Ja, das ist vielleicht noch ein weiterer Punkt der Komplexität.
Heterogene Plattformen Und dann verschiedene Aufgabenstellungen, die hohe Qualitätsanforderungen erfüllen.
Und diese komplexe Situation erfordert, dass wir Spezialisten einsetzen.
Nicht nur viele Personen brauchen wir, Größe der Projekte, sondern wir brauchen Spezialisten.
Und hier haben wir wieder das Gleiche. Diese Spezialisten,
mit denen müssen wir kommunizieren, die haben teilweise unterschiedliche Begriffswelten.
Ja, also auch hier haben wir Arbeitsteilung.
Jeder ist für seinen Bereich zuständig und wir brauchen Kommunikation.
Vielleicht haben Sie schon den Spruch gehört, 30 Prozent von Softwareentwicklung ist Kommunikation.
Das trifft auf Software Engineering ganz besonders zu. Ja,
und diese Personen, die für vielen Personen haben teilweise eine unterschiedliche Wahrnehmung,
Natürlich teilweise unterschiedliche Sichtweisen, schreiben wir mal, unterschiedliche Begriffswelten.
Und da kommt es darauf an,
dass man
gemeinsame Konzepte entwickelt
Und ein gleichartiges Verständnis erreicht. Diese Herausforderung sind im Wesentlichen dadurch gekennzeichnet,
dass wir eine lange, zum Beispiel eine lange Nutzungsdauer haben.
Bei ganz vielen Projekten, die gerade die komplex sind und
groß sind, das sind eine Menge Investitionen reingeflossen.
Schon deswegen möchte man sie über lange Zeit benutzen.
Außerdem sind Arbeitsweisen von Menschen im Kern
sehr stabil
Ich sag mal, das Wesen von Versicherungen
hat sich seit dem Mittelalter nicht groß verändert.
Viele riesigen Bündeln und einzelne Kunden verkaufen. Oder Handel,
große Mengen einkaufen, irgendwie zwischenlagern, einen Einzelkunden verkaufen.
Diese Prinzipien bleiben eigentlich die gleichen. Und Menschen ändern auch
nicht gern ihre Handlungsweisen. Das ist auch ein anderer Punkt
. Also im Kern bleiben Geschäftsprozesse sehr stabil.
Und deswegen müssen auch die Systeme stabil sein.
Das ist für die langen Nutzungsdauer wichtig
Also ein Punkt dazu ist, dass der hohe Aufwand erfordert Ermotisation.
Und deswegen eine lange Nutzungsdauer und das Zweite,
wir wollen Wissen über lange Zeit erhalten.
Wissen über das Systemwissen um Veränderungen weitermachen zu können.
Veränderungen ist auch gleich der zweite Punkt hier
Die Flexibilität brauchen wir, um Veränderungen zu ermöglichen. Veränderungen deswegen,
weil sich die Welt ständig ändert und die Welt insbesondere um
die Softwaresysteme herum oder die von den Software-Systemen unterstützt werden muss.
Solche Beispiele für solche Änderungen
sind gesetzliche Änderungen
Wer etwas mit Sozialgesetzgebung zu tun hat, irgendwelche Arbeitgeberzuschüsse,
Sozialversicherungsbeiträge, da gibt es jedes Jahr Änderungen.
Ja, und wenn man ein System hat, was damit
zu tun hat, muss das System daran angepasst werden.
Dann gibt es organisatorische Änderungen in Unternehmen. Organisationsänderungen. Da wird etwas hinzugekauft,
da muss der Einkauf gemeinsam die Wandwirtschaft zusammengelegt werden.
Man entscheidet sich aus Gründerprofitabilität oder um Wettbewerbsnachteile oder Wettbewerbsbeschränkungen
zu umgehen, dass man etwas ausgliedert in eine GmbH.
Ja, diese Unternehmensteile, die waren vorher eins,
die müssen sich dann Rechnungen schreiben und müssen gegen die Trennte Verwaltung haben,
getrennte Leitungsprozesse.
Und dazu brauchen, braucht die Software Änderungen.
Ja, dann werden Geschäftsprozesse optimiert.
Optimierung von Geschäftsprozessen
Das macht man deswegen, weil der Konkurrenzdruck so hoch ist,
wenn wir irgendwo was sparen können oder wenn wir Geschäftsregeln ändern können,
wie versenden wir was, mit welchem Forstsanddienst,
wie wickeln wir das ab.
Ach ja, wir machen jetzt unseren eigenen Versand oder sowas.
Dann sind das jedes Mal Änderungen der Software,
die da notwendig sind, damit das unterstützt wird.
Natürlich ist es auch so, dass Kundenanforderungen sich ändern. Etwas,
was ich heute möchte,
ja vor ein paar Jahren hat noch keiner gedacht,
dass wir so eine Touch-Oberfläche haben,
wo man mit Fingerberührung was ziehen oder dass man im Supermarkt
den Warenbestand mit dem Handheld erfüllt
Fast. Ja, also das sind alles Dinge,
wo man neues, neue Ideen hat, wo neue Dinge aufkommen.
Also Kundenanforderungen ändern sich. Und nicht zuletzt ändern sich natürlich auch technische Plattformen. Ja,
da gibt es ihr Datenbanksystem, braucht ein Update,
die Middleware unterstützt, wird jetzt abgedichtet gegen irgendwelche Sicherheitslücken und
wir brauchen eine neue Version oder das Betriebssystem ändert sich.
Der Update von Windows 7 auf Windows 10 ist eine Forderung.
Es gibt noch ein paar Systeme,
die heute es noch nicht geschafft haben von Windows XP wegzukommen.
Ja, also die technische Plattform erfordert auch Änderungen der Software,
die darauf aufsetzt. So, und diese Zusammenhänge,
Flexibilität einerseits, lange Nutzungsnauer, andererseits sind,
ist schon eine ganz schöne Herausforderung, aber das reicht noch nicht.
Wir haben noch eine Nummer drei, ja,
eins haben wir immer noch, und zwar die qualitativen Anforderungen.
Ruhe, qualitative Anforderungen. Was meine ich damit?
Damit meine ich solche Anforderungen nicht nur an Performance,
Also wir wollen schnelle Antwortzeiten haben, sondern auch an die Skalierbarkeit.
Also etwas soll nicht nur für zehn Prozesse pro Sekunde funktionieren,
sondern vielleicht auch für 100.000 pro Sekunde.
Oder nicht nur für zehn Filialen, sondern für 10.000 Filialen
weltweit, wenn unser Unternehmen wächst.
Oder wenn das Anwenderunternehmen wächst, dann bekommen noch solche Sachen
dazu,
wie Zuverlässigkeit
Damit ist die Ausfallsicherheit gemeint, wir wollen,
dass das System am besten 24 Stunden sieben Tage
die Woche und rund ums Jahr ohne Ausfall arbeitet,
also auch keine Zeiten für irgendwelche Fehlerbehebungen, hat,
geschweige denn dafür, dass sie durch Fehler beeinträchtigt wird.
Oder die Frage der Sicherheit spielt eine große Rolle,
je komplexer die IT-Welt wird, je mehr Angriffe so möglich sind,
desto mehr Angriffe gibt es auch.
Das sind ganz wichtige, wichtige Punkte.
Damit wir das machen können,
brauchen wir Risikominimierung
Und wir brauchen frühzeitige Prüfung. Wenn Sie in drei Jahren laufendes Projekt haben für ein großes Warnwirtschaftssystem für ein,
sag mal, weltweiten Handelskonzern, dann reicht es nicht,
diese Frage Skalierbarkeit,
reicht es denn für Stoßzeiten wie Weihnachten und Ostergeschäft,
dass das System dann noch gut leistungsfähig ist,
das können wir nicht erst nach dem drei Jahren Entwicklungszeit mal am laufenden System ausprobieren und dann stellen wir fest,
oh,
schade,
es ist zu langsam
Und das müssen wir frühzeitig prüfen,
wenn wir die Entscheidungen zum Beispiel über die technische Plattform treffen.
Dazu sind die Konzepte notwendig, die wir wiederverwenden können und
das ist ein kritischer Punkt, das brauchen wir für Software-Technik.
Und das ist unter anderem Inhalt dieser Lehrvereinstellung,
das ist Inhalt dieses Abschnitts dieses ersten Abschnittses.
Von den Vorgehensweisen, für die Vorgehensweisen starten wir,
wir starten mit der Überschrift dieses Abschnitts,
war frühe Phasen,
dazu möchte ich
etwas überhaupt zu den Phasen sagen
Hier haben wir vielleicht, blicken wir mal hier auf die nächste Folie,
die stellt ein Bild, was von dem Rechner Unified Process kommt.
Dieser Rechner Unified Process. Davon haben Sie vielleicht noch nichts gehört,
aber das gehört zur UML. UML Unified Modeling Language ist
eine Beschreibungssprache. Aber wie komme ich zu diesen Beschreibungen hin?
Das sagt die UML nicht, sondern das sagt der Unified Process.
Stammt von den gleichen Autoren, bietet die UML ML
sich ausgedacht haben und etabliert haben. Und dieses,
das habe ich ja als Beispiel mal mitgebracht für ein Vorgehen,
um zu erklären, wie generell wir in Phasen arbeiten,
was ich mit frühen Phrasen meine.
Wir haben ja in der Vorlesung von Dr. Kritzan noch viel
mehr zu Vorgehensmodellen. Iterativ, inkrementell heißt eigentlich ja,
dass wir die Aufgaben zerlegen in Teile und diese Zeile tragen dazu bei,
zum Beispiel das, was wir auf der vorgehenden Folie hier hatten,
dass wir mit geringem Risiko arbeiten.
Ja, das kann man natürlich viel besser machen,
indem man erstmal was Kleines macht,
das ausprobiert und dann macht man es erst in groß
Doch ich möchte Anhalt dieses Bildes kurz mit ihnen Iterationen besprechen. Wir wissen,
ich denke, jetzt haben Sie schon ganz häufig gehört,
das Wasserfallmodelle, die Welt nicht richtig abbilden.
Wasserfallmodell ist im Prinzip so, dass man sagt,
die eine Tätigkeit ist der erste, dann ist abgeschlossen,
dann kommt die nächste.
Wir finden diesen Schwerpunkt von Tätigkeiten hier durchaus auch. Ja,
also dieses Bild zeigt uns, wir haben hier unten
die Zeitachse, ja, von links nach rechts.
Und wir haben hier auf den Zeitenachse jeweils verschiedene Tätigkeitsfelder.
Und tatsächlich sind die Tätigkeitsfelder jedenfalls hier die ersten in
der Reihenfolge abgegeben
Wie sie sind. Und wenn wir uns die Schwerpunkte ankamen,
ist es durchaus, wie man es auch erwartet.
Ja, also ein Projekt beginnt mit dem Gedanken darüber,
was eigentlich der Geschäftsprozess sein soll.
Wie soll das System im Großen laufen?
Ja, der nächste Schwerpunkt wäre hier Requirement.
Sie schreibe detailliert auf welche Anforderungen denn umgesetzt werden sollen.
Wie soll das System arbeiten? Dann mache ich mir Gedanken,
das ist der nächste Schwerpunkt hier. Wie soll das System
gebaut sein? Welche Struktur soll es haben?
Und dann habe ich den nächsten Schwerpunkt mit Implementation.
Das sind auch wichtig
Ja, und dann irgendwann wird es,
hier gibt es Tests, gibt es immer wieder,
dann wird es irgendwie eingeführt in der Praxis und dann ist es fertig hier,
das Untere sind unterstützende Prozesse.
Im, soweit entspricht es dem Wasserfallmodell,
aber beim Wasserfallmodell wäre es das so,
dass das Erste erst abgeschlossen wird, komplett,
alles wird geprüft, eingefroren und dann beginnt das Zweite.
Und dann beginnt das Dritte. Hier sehen wir, es gibt ein Nebeneinander.
Dieses hier nebeneinander wird hier in diesem Modell in Phasen gegliedert,
also es gibt hier Inception Elebration Construction Transition und jeweils hier
verschiedene Phasen davon
Verschiedene Iterationen und die Höhe der einzelnen Kurven, die Menge der Farbe hier,
zeigt, wie viel Arbeitskraft in jeweils investiert wird.
Wie viele Leute sind dort gleichzeitig tätig? Ja,
und tatsächlich, wenn wir uns hier vorne das anschauen,
vielleicht ziehen wir mal eine Achse hier drüber,
irgendwie ziemlich zu Beginn des Projekts, das Projekt wird aufgesetzt,
wie erwartet ist denn die meisten Leute tätig beim Modellieren des Geschäfts,
des Geschäftsprozesses beim Aufdenken, was soll da eigentlich passieren?
Beim Analysieren gemeinsam mit dem Kunden, beim Erdenken der Funktion
des Systems. Aber es gibt hier schon ganz viel,
wo Anforderungen detailliert aufgeschrieben werden, genauer als dasselben Geschäftsprozess wäre.
Und tatsächlich, man beginnt sich ja auch Gedanken zu machen,
wie soll denn das System strukturiert sein?
Man trifft erste Entscheidungen zum Beispiel über die technische Plattform, die getroffen sein muss.
Wenn wir uns ein bisschen später das anschauen, ja, zum Beispiel,
nehmen wir mal hier sowas kurz hinter dieser ersten schwarzen Linie,
dann würde das bedeuten, ja, wir sind tatsächlich,
ganz viel wird an Anforderungen gearbeitet.
Diese Antwortungen werden erfasst, wenn analysiert mit allen Leuten wird gesprochen,
die da etwas dazu zu sagen haben, die etwas wissen,
wie soll das System im Detail gebaut sein,
aber man ist weiterhin damit tätig,
den Geschäftsprozess zu modellieren und man macht schon ganz viel Richtung
Gestaltung der Architektur
Hat zur Folge, oder ist notwendig,
weil man diese Antwortung prüfen muss, sind die überhaupt realisierbar?
Weil man ein Angebot machen muss, wie teuer darf denn das werden?
Wie viel Geld und Zeit wollen wir denn investieren?
Und tatsächlich macht man auch schon ein bisschen eine Implementation.
Die werden sich fragen, wieso denn?
Es ist doch noch gar nicht alles klar bei den Anforderungen.
Aber tatsächlich muss man hier schon vielleicht einen kleinen Prototyp bauen und sehen,
ob das denn schnell genug ist, ob es denn überhaupt funktioniert.
So etwas wird man hier schon machen. Und vielleicht
wird man das mal auf einer Testplattform auch schon installieren.
Das ist jetzt hier Das geht hier unten vielleicht schon los
mit dem ersten Deployment eines Prototypen.
Und man prüft hier, steht jetzt Test,
man prüft tatsächlich auch die Anforderungen, ob sie denn gut sind.
Wenn wir doch ein bisschen weiter später schauen,
vielleicht mal hier, schauen wir uns mal hinter der zweiten Linie,
so einen Zeitpunkt mal an.
Ja, wie wir erwarten, ist dort der Schwerpunkt der Implementierung.
Alle Entwickler sind am Start, da wird ganz viel Quellcode geschrieben.
Ja, aber es werden tatsächlich noch Entscheidungen hier für die
Architektur, für die Struktur getroffen.
Sie werden sich fragen, wieso sind die da noch nicht fertig?
Ja, im Prinzip ist schon vieles getroffen,
aber manches muss noch weiter verfeinert werden
Vielleicht funktioniert auch manches nicht so ganz, wie man sich das so anfangen dachte.
Und man muss das noch mal anpassen oder man muss nachbessern.
Ja, es werden weiterhin Entscheidungen von den Anforderungen erfasst,
zum Beispiel, wie sieht das in diesem und jedem Sonderfall aus.
Das war anfangs nicht aufgeschrieben. Das wird noch, wird
noch erfragt für den Auftraggebern. Und man macht durchaus,
es gibt auch noch Änderungen hier im Geschäftsprozess, die auch noch einfließen sollen,
weil es sich ja seit dem Anfang schon eine ganze Menge Zeit vergangen.
So, also ich möchte damit demonstrieren,
wir gehen iterativ, aber wir gehen durch diese Phasen.
Und das, was wir jetzt in diesem Abschnitt 1.1 haben,
mit früher frühen Phasen bezieht sich auf Business-Modeling und Requirements Anforderungsanalyse zu Deutsch.
Das ist der Punkt, auf den ich besonders dessen bedeute,
ich hier besonders hervorheben möchte. Die Bedeutung, um die Bedeutung darzustellen,
haben wir hier so ein kleines nettes Tiagramm und auf der Y-Achse
habe ich hier das Gewicht einer Entscheidung aufgetragen und hier unten diese Phasen.
Die sind jetzt hier auf Deutsch,
also die Idee oder der Geschäftsprozess, wie sie wollen,
ist das Erste, dann beschreiben wir die Anforderungen.
Das war eben Requirements,
Analyse, Analyse und Design
hieß das eben
Entwurf genannt, sie können auch Architekturmilder dran schreiben,
sie wollen die Implementation, Integration und Installation,
also Deployment auf Deutsch, in Betriebnahme,
ist noch eine separate Phase und der Betrieb,
das beides war eben nicht so klar dabei,
nur so um den Begriff zu erklären, in Betriebnahme heißt zum Beispiel,
ich muss die Daten aus dem alten System übernehmen,
ich muss die Benutzerschulen, ich muss ein Konzept haben,
wie schrittweise von dem alten System zum neuen Systemwechsel,
es ist ja nicht nur einfach mit Einschalten getan,
gerade wenn dort viele Beteiligte sind, wenn wir viele Daten haben,
wenn sie was Kleines nur auf ihrem eigenen PC installieren,
dann ist das natürlich mit Installieren und Übernehmen gedacht,
aber wenn Sie schon, wenn Sie den PC wechseln,
müssen Sie dafür sorgen, dass alles widerspielt.
Ja, und bei einem großen System ist die Inbetriebnahme tatsächlich
eine ernsthafte Aufgabe. So, wir schauen uns an,
wie die Bedeutung solcher der frühen Phasen oder wie sieht überhaupt
das Gewicht eine Entscheidung aus. Natürlich trifft jede Entscheidung,
bei der es um die Idee gibt, hat ein sehr hohes Gewicht.
Ich mache mal hier ein Sternchen hin. Ja,
also wenn wir hier eine Idee verändern, dann hat das
einen großen Einfluss auf das System, was vorher, was gebaut wird.
Wenn wir das, was wir hier an Ideen sammeln,
wird dann verfeinert durch Anforderungen, dabei werden noch ganz viele Entscheidungen getroffen,
die auch ein hohes Gewicht haben,
aber dieses Gewicht ist schon deutlich niedriger,
als das in der ersten, in der allerersten Phase,
weil wir hier schon uns im Rahmen der Ideen bewegen.
Wenn die Anforderungen aufgeschrieben sind, sind vielleicht ein Vertrag geworden,
wir erfüllen diese Anforderungen und bauen dann ein System daraus,
dann treffen wir immer noch viele Entscheidungen über die Struktur oder Software,
über die Architektur und jede dieser Entscheidungen hat eine große Bedeutung für Performance-Sicherheitsskalierbarkeit,
aber sie bleibt verhaltensmäßig im Rahmen dessen, was beschrieben wird.
Also hier haben wir schon ein geringeres Gewicht und würden
das Kreuzchen vielleicht in dieser Höhe setzen
Wenn wir das, wenn wir die Architektur entschieden haben und die Programmierer setzen das um,
haben sie einen großen Einfluss darauf, wie das System sich tatsächlich verhält.
Nicht noch nicht ein Fehler es hat, sondern auch,
wie es sich unter Last verhält,
wie es bezüglich Sicherheit verhält, wie ergonomisch ist es.
Also auch deren Entscheidung haben ein relativ großes Gewicht,
aber im Rahmen der vorgetroffenen Entscheidungen. Und selbst beim Zusammenbau bei
der Installation des Systems auf der Zielplattform haben wir noch Einflüsse darauf,
wie viel Speicherbereich auf was für eine Maschine ist das,
wie viele Netzwerkressourcen werden dort verfügbar sein.
Und auch bei der Inbetriebnahme, insbesondere bei der Benutzerschulung,
haben wir einen Einfluss drauf. Und selbst während des Betriebs
können wir durch Änderungen von Parametern durch Änderungen von Vorgehensweisen
noch dazu beitragen, dass wir Änderungen haben.
Diese Kurve, die wir hier sehen, können wir hier
verbinden und wir haben vielleicht so ungefähr so eine Kurve entsteht.
Ich habe das aufgezeichnet, um ihn zu verdeutlichen, wie wichtig die ersten Phasen sind.
Wir haben leider in der Industrie durchaus manchmal Zeitgenossen,
die vor allen Dingen sich auf die Implementierung konzentrieren, weil das ihr Tagesgeschäft ist.
Das ist das, was sie können, die Programmiersprache.
Und das ist das, was sie auch alle vorher schon mal gelernt haben.
Und ich möchte ja verdeutlichen, Das ist das, was vor der Inbetriebnahme,
vor der Programmierung bekommt und auch selbst vor dem Design der Software,
dass das einen sehr großen Einfluss hat,
weil die Entscheidung so ein hohes Gewicht haben.
Und das ist ein Punkt, den wollen wir hier herausarbeiten.
Wir haben hier dazu die Fragen, die wir,
das ist die Frage 1, die wir hier haben,
nein, wo war sie hier,
worin besteht die Bedeutung der frühen Phasen der Softwareentwicklung und das
wollen wir uns kurz hier noch notieren.
Eine Grund, warum das Gewicht so hoch ist,
ist das falsch verstandene Anforderungen zu einem falschen System führen
Wir schreiben uns das hin. Warum? Ist das Gewicht
so hoch? Falsch verstandene Anforderungen führen zu falschem System.
Das ist der erste Punkt. Dann müssen wir sagen,
dass die Entscheidung, die wir hier ganz am Anfang treffen,
dass das sehr grundlegende Entscheidungen sind
Als, das soll heißen. Grundlegende grundlegende Entscheidungen,
die haben hohe Auswirkungen auf nachfolgende Arbeiten
Und Änderungen sind dadurch,
sind später sehr viel mit schwerem Aufwand nur nötig.
Spätere Änderungen nur mit oben Aufwand, möglich. So,
und dann, was wir auch noch sagen müssen,
Fehler in diesen frühen Phasen
haben auch entsprechend
höheres Gewicht
Mit Fehlern ist nicht nur gemeint, dass wir was falsch verstanden haben.
Auch Inkonsistenzen, oder nennen wir es auf Deutsch, Widersprüche.
Und Unvollständigkeit müssen erfordern, hohen Aufwand zur Behebung
Weil Folgetätigkeiten alle darauf aufbauen. Wir werden später nochmal im
Abschnitt Qualitätssicherung auf diesen Effekt der Fortpflanzung von Fehlern und des
höheren Aufwands besprechen können. Also das sind alles Punkte,
die wir hier besprechen müssen und das ist auch
gleichzeitig Antwort auf Frage
Bevor wir weitermachen mit der Anforderungsanalyse,
möchte ich einfach nochmal verdeutlichen, dass diese frühen Phasen,
die wir hier haben, das Aufschreiben der Ideen,
das, was wir im nächsten Abschnitt mit UML machen,
dass das für die Praxis eine enorm große Bedeutung hat.
So groß, die Bedeutung ist so groß,
dass dieses Requirements Engineering, habe ich es, Anforderungsbeschreibung genannt,
dass das sogar ein separates Gebiet der Informatik ist und sie sollten durchaus drüber nachdenken,
ob das so an der Schnittstelle zwischen Mensch und Technik,
Leute verstehen technische Vorschläge machen, sie sind derjenige,
der die Technik kennt, da muss man nicht programmieren,
man gestaltet
Also jede Entscheidung, die hier vorne ist,
hat großen Einfluss darauf, wie das System gestaltet ist.
Und das ist ein sehr interessantes Berufsfeld. Ich möchte sie durchaus animieren,
darüber nachzudenken, ob das vielleicht nicht später ein Berufsfeld ist,
in dem sie tätig sein wollen.
An der Schnittstelle zu den fachlichen, fachlich kompetenten Dingen,
die da eine Rolle spielen, wo wir Ideen aufnehmen.
So, damit schließen wir diesen ersten Abschnitt.
Wir machen weiter mit der Anforderungsbeschreibung mit den Mitteln der UML