Inhaltsverzeichnis

1. Was ist das V-Modell?

Wie sich direkt erkennen lässt, ist das V-Modell wieder in einzelne Phasen unterteilt. Jeder blaue Kasten repräsentiert dabei eine Phase im Entwicklungsprozess. Das erinnert stark an das Wasserfallmodell, das wir im vorherigen Beitrag kennengelernt haben.

2. Wie funktioniert das V-Modell?

Genau wie beim Wasserfallmodell muss man auch beim V-Modell eine Phase vollständig abschließen, bevor man zur nächsten übergehen kann.

Auch hier gibt es also wieder eine sequenzielle Abfolge, was bedeutet, dass alles der Reihe nach durchlaufen wird. Beim Wasserfallmodell zuvor hatten wir so gesehen nur die linke Seite des Prozesses, was den Wasserfall-Effekt erzeugt hat, da die Phasen nacheinander wie eine Kaskade nach unten abliefen.

Im Gegensatz zum Wasserfallmodell, das nur die Phasen auf der linken Seite zeigt, verläuft das V-Modell auf beiden Seiten. Das V-Modell verdankt seinen Namen der markanten V-Form, die sich auch in der Grafik erkennen lässt. 

Auf der linken Seite verlaufen die Phasen nach unten, während sie auf der rechten Seite wieder nach oben führen. So entsteht die typische V-Form.

Sieht man sich das Modell genauer an, könnte man die linke Seite als die Entwurfsseite bezeichnen, denn dort sind all die Phasen aufgeführt, die für den Entwurf verantwortlich sind. 

In der Mitte, am unteren Punkt des "V" befindet sich die Programmierung, also die Implementierung des gesamten Entwurfs.

Auf der rechten Seite folgen dann die Testphasen. Damit lässt sich zusammenfassen, dass die linke Seite für den Entwurf und die Konstruktion steht, während die rechte Seite für das Testen der entwickelten Software verantwortlich ist.

Beim V-Modell ist wichtig zu verstehen, dass jeder Konstruktions- bzw. Entwurfsphase eine entsprechende Testphase direkt gegenübersteht. 

Was das genau bedeutet, werden wir uns gleich noch genauer ansehen.

3. Die Phasen des V-Modells

Genau wie beim Wasserfallmodell nimmt der Detailierungsgrad nach unten hin zu. Je weiter man sich also nach unten bewegt, desto ausführlicher werden die Phasen.

Das bedeutet, dass man oben mit einer groben fachlichen Spezifikation beginnt, die nach unten hin immer detaillierter wird und am Ende den gesamten Entwurf in Programmcode umsetzt.

In der Spitze des "V" findet die Implementierung statt und auf der rechten Seite folgen die entsprechenden Testphasen. Da jeder Konstruktions- bzw. Entwurfsphase direkt eine Testphase gegenübersteht, sorgt dieses Modell für eine sehr hohe Testabdeckung.

Dadurch wird sichergestellt, dass alle Aspekte der Software gründlich geprüft werden. 

3.1 Phase 1: Die Anforderungsanalyse

Wie bereits erwähnt, liegt der Startpunkt des V-Modells bei der Anforderungsanalyse, die sich links oben befindet. In dieser Phase werden zunächst die Anforderungen an das System festgelegt. Daraufhin folgt die Phase des funktionalen Systementwurfs.

3.2 Phase 2: Der funktionale Systementwurf

In dieser Phase dreht sich alles um die Systemanforderungen. Aus der sogenannten Blackbox-Sicht wird beschrieben, wie das System die zuvor festgelegten Anforderungen umsetzen soll. Dabei ist es wichtig, das Ganze aus einer übergeordneten Perspektive zu betrachten und sich grob zu überlegen, wie das System ablaufen soll.

Das bedeutet, dass in dieser Phase noch nicht die technische Umsetzung des Systems festgelegt wird, da der Fokus hier ausschließlich auf der Blackbox-Sicht liegt. Es geht also darum, das System von oben zu betrachten, ohne sich in technischen Details zu verlieren.

3.3 Phase 3: Der technische Systementwurf

Nach der funktionalen Phase folgt der technische Systementwurf. Hier dreht sich alles um die konkrete Systemarchitektur. Es geht dabei darum, zu entscheiden, wie das System technisch umgesetzt wird. In dieser Phase werden alle wichtigen Designentscheidungen getroffen, damit sich die Entwickler bei der späteren Implementierung an diesen Entwurf halten können, ohne selbst noch über das Design nachdenken zu müssen.

Das bedeutet, dass von Anfang an alles strukturiert durchgeplant wird und wenn es dann an die tatsächliche Umsetzung geht, der gesamte Plan bereits feststeht. Die Entwickler können sich also darauf verlassen und das Projekt Schritt für Schritt umsetzen, ohne weitere grundlegende Entscheidungen treffen zu müssen.

3.4 Phase 4: Die Komponentenspezifikation

Nach Abschluss der technischen Systementwurfsphase folgt die Komponentenspezifikation. Hier geht es um eine noch detailliertere Beschreibung der einzelnen Systemkomponenten. Sobald diese spezifiziert sind, geht es in die nächste Phase: die Programmierung bzw. Implementierung.

3.5 Phase 5: Die Implementierung

Die Entwickler orientieren sich nun am zuvor erstellten Konstruktionsplan und setzen das gesamte System um.

Im V-Modell endet der Prozess allerdings nicht mit der Implementierung, sondern stattdessen beginnt nun der Aufstieg auf der rechten Seite des "V" mit den Testphasen.

3.6 Phase 6: Die Komponententests

Die erste Testphase, die ansteht, sind die Komponententests. Hier zeigt sich wieder das Prinzip, dass der Detailierungsgrad von oben nach unten immer feiner wird. 

Bei den Tests läuft es jedoch genau umgekehrt ab: Man geht von fein nach grob vor. Zuerst werden die einzelnen Komponenten getestet, was als Komponententests oder auch Unit-Tests bezeichnet wird.

In einem späteren Teil dieser Tutorialreihe werden wir uns diese Testarten und ihre Bedeutung noch genauer ansehen. Hier reicht erst einmal eine grobe Übersicht, damit du verstehst, wie das Modell funktioniert. 

3.7 Phase 7: Die Integrationstests

Nach den Komponententests folgen die Integrationstests, in welchen man prüft und validiert, ob der technische Systementwurf korrekt umgesetzt wurde.

Die Phase, in der die Integrationstests stattfinden, steht im V-Modell genau gegenüber der technischen Systementwurfsphase. 

3.8 Phase 8: Die Systemtests

Danach folgen die Systemtests, die den funktionalen Systementwurf validieren. Auch diese Phase steht im Modell direkt der entsprechenden Entwurfsphase gegenüber.

3.9 Phase 9: Die Abnahmetests

Am Ende folgen die Abnahmetests, die überprüfen, ob die Software den ursprünglichen Anforderungen entspricht. Hier wird validiert, ob alles so umgesetzt wurde, wie es in der Anforderungsanalyse festgelegt war.

4. Zusammenfassung

Das ist im Wesentlichen das V-Modell. Links befindet sich die Konstruktionsseite, rechts die Testseite. Für jede Konstruktionsphase gibt es demnach auf der gegenüberliegenden Seite eine entsprechende Testphase.

Das bedeutet: die Anforderungsanalyse wird durch die Abnahmetests validiert, während der funktionale Systementwurf durch die Systemtests überprüft wird und auch jede andere Entwurfsphase steht einer passenden Testphase gegenüber, um sicherzustellen, dass das System den Anforderungen entspricht.

5. Der wichtigste Vorteil des V-Modells

Wie bereits zu Beginn erwähnt, liegt ein wichtiger Vorteil bei diesem Modell in der hohen Testabdeckung. Schon während der Anforderungsanalyse denkt man über die späteren Abnahmetests nach. Das bedeutet, dass man bereits in jeder Konstruktionsphase die entsprechenden Tests einplant und damit sicherstellt, dass die Realisierbarkeit von Anfang an im Fokus steht.

Setzt man das Ganze nicht von Beginn an auf diese Weise um, kann es leicht passieren, dass wichtige Aspekte übersehen werden. Erst während der Tests stellt man dann fest, dass etwas gar nicht so realisierbar ist wie gedacht. Aus diesem Grund ist das Vorgehen besonders nützlich. 

Inhaltsverzeichnis

1. Was wirst du in diesem Beitrag lernen?

2. Was ist das Wasserfallmodell?

Im vorherigen Beitrag haben wir bereits den Software-Lebenszyklus kennengelernt. Dabei haben wir gesehen, dass sich dieser aus den folgenden 6 Phasen zusammensetzt, die in der Softwareentwicklung stets berücksichtigt werden müssen: 

1  Anforderungsanalyse
2  Design und Entwurf
3  Implementierung
4  Testphase
5  Abnahme und Einführung
6  Wartungsphase

Das Wasserfallmodell ist ein Vorgehensmodell, das zeigt, wie man diese Phasen nacheinander durchlaufen kann. 

Um das Ganze zu veranschaulichen, werfen wir an dieser Stelle einen Blick auf die folgende Grafik. Du wirst feststellen, dass sie im Grunde fast genauso aussieht wie die Grafik aus dem letzten Beitrag, mit dem Unterschied, dass sich hier zwischen den Phasen Stufen befinden.

Das Wasserfallmodell ist ein lineares Modell, was bedeutet, dass die Phasen zeitlich aufeinanderfolgen.

Anders gesagt: Es ist nicht möglich, mehrere Phasen parallel laufen zu lassen. Beispielsweise kann die Anforderungsanalyse nicht gleichzeitig mit der Testphase stattfinden. In diesem Vorgehensmodell durchläuft man die Phasen nacheinander, weshalb es als linear bezeichnet wird.

3. Die Phasen des Wasserfallmodells

4. Die Vorteile des Wasserfallmodells

Alles läuft dabei strikt zeitlich hintereinander ab – also sequenziell, ohne dass Phasen parallel verlaufen. Das bringt einige Vorteile mit sich. Zum einen sind die Phasen klar voneinander abgegrenzt, was es ermöglicht, für jede Phase individuelle Ziele festzulegen. Durch diese klare Trennung können in jeder Phase viele Meilensteine definiert werden, wodurch der Fortschritt gut kontrollierbar ist.

Ein weiterer großer Vorteil des Wasserfallmodells ist die frühe Klarheit über die Kosten und die voraussichtliche Dauer des Projekts. Sobald alles einmal geplant ist, lassen sich diese Faktoren gut abschätzen. Da man für jede Phase klare Ziele und Meilensteine definiert, kann man von Anfang an genau berechnen, welche Kosten anfallen und wie lange jede Phase dauern wird. Durch die strukturierte und sequenzielle Vorgehensweise hat man von Beginn an also einen genauen Überblick über den Projektverlauf.

5. Die Nachteile am Wasserfallmodell

Jetzt kommen wir allerdings zum großen „Aber“, denn das Wasserfallmodell bringt auch einige Nachteile mit sich. Sehen wir uns die Kritikpunkte nun also mal genauer an.

5.1 Es gibt kein Zurück mehr

Der erste Punkt ist, dass es in der Praxis oft schwierig ist, wenn nicht sogar unmöglich, die Phasen klar voneinander abzugrenzen.

Stell dir vor, wir befinden uns nach der Implementierungsphase in der Testphase und in dieser Phase werden jetzt Fehler entdeckt, wodurch an mehreren Stellen nachgebessert werden muss. 

Eigentlich müssten wir diese Probleme beheben. Doch wenn man streng nach dem Wasserfallmodell arbeitet, ist die Implementierungsphase bereits abgeschlossen und ein Rücksprung zu einer vorherigen Phase ist laut diesem Modell nicht vorgesehen.

Das bedeutet, dass man nichts mehr programmieren dürfte, wenn man sich strikt an das Modell halten würde. Hier zeigt sich bereits, dass es kaum möglich ist, die Phasen so klar voneinander zu trennen.

In realen Softwareprojekten ist es oft notwendig, mehrere Phasen erneut zu durchlaufen, um am Ende ein gutes Ergebnis zu erzielen. Das steht jedoch im Widerspruch zum Wasserfallmodell.

5.2 Keine Flexibilität

Ein weiterer Kritikpunkt ist der Verlust der notwendigen Flexibilität. Stell dir vor, du stehst vor der Aufgabe, ein System zu programmieren und es gibt von Anfang an zwei oder drei kritische Stellen, bei denen unklar ist, ob sie so umgesetzt werden können wie geplant. 

In der Praxis beginnt man oft mit den kritischsten Aspekten eines Systems, denn wenn diese nicht funktionieren, lohnt sich die restliche Arbeit nicht. Das Wasserfallmodell steht allerdings auch im Widerspruch zu diesem Ansatz, da man streng den Phasen folgen muss. 

Ich hatte vorhin bei den Vorteilen erwähnt, dass die Kosten und die voraussichtliche Dauer des Projekts von Beginn an festgelegt werden. Das gilt jedoch nur, wenn die Anforderungen an das zu entwickelnde System während des gesamten Prozesses stabil bleiben. Das bedeutet, dass sich während der gesamten Entwicklungs- und Projektlaufzeit nichts an den Anforderungen ändert. 

Auch danach, in der Wartungsphase, sind Änderungen kaum möglich, da ein Rücksprung zu früheren Phasen im Wasserfallmodell nicht vorgesehen ist.

Wenn sich am Ende des Projekts eine Anforderung ändert – sei es durch neue Technologien, veränderte Geschäftsmodelle oder Konkurrenz durch innovative Start-ups – muss man entsprechend reagieren und das System anpassen. Dazu wären Rückschritte nötig, um neue Anforderungen zu definieren und das System entsprechend umzubauen. 

6. Warum das Wasserfallmodell kaum noch anwendbar ist

In der Praxis sind Anforderungen also nie wirklich stabil. Genau deshalb ist das Wasserfallmodell in modernen und oft komplexen Softwareprojekten kaum noch anwendbar. Dennoch ist es ein grundlegendes Modell, das man kennen sollte. In der heutigen Softwareentwicklung wird es allerdings nur noch selten eingesetzt.

Wir werden in den kommenden Beiträgen selbstverständlich noch andere Vorgehensmodelle kennenlernen, die heute weit verbreitet und sehr relevant sind. 

Inhaltsverzeichnis

1. Was ist der Software Lebenszyklus?

2. Die 6 Phasen des Software Lebenszyklus

In der folgenden Grafik sind die sechs Phasen des Software-Lebenszyklus übersichtlich dargestellt:

Im Internet findet man natürlich zahlreiche Videos, Blogartikel und Bücher zu diesem Thema, worin der Software-Lebenszyklus jeweils etwas anders dargestellt wird.

Im Grunde geht es aber immer um das Gleiche. Ob eine Quelle von sieben Phasen spricht, eine andere von acht oder wieder eine andere nur von fünf – oft sind diese Phasen einfach anders zusammengefasst.

Ich habe mich hier entschieden, den Lebenszyklus in sechs Phasen zu unterteilen.

3. Die Anforderungsanalyse

4. Die Design- oder Entwurfsphase

Als Nächstes geht es in die Design- oder Entwurfsphase. In dieser Phase plant man die gesamte Software im Detail. Hier legen wir fest, wie das Layout der Software aussehen soll und welche Programmiersprachen zum Einsatz kommen. Wird die Software beispielsweise in C# oder Java entwickelt? Sollen wir ein bestimmtes Framework verwenden, wie zum Beispiel Spring für Java?

Außerdem definieren wir den Aufbau der Businesslogik, ob und mit welchen Datenbanken wir arbeiten und wie die Softwarearchitektur insgesamt gestaltet sein soll.

Am Ende entsteht ein umfassender Entwurf, der alle wichtigen Entscheidungen enthält. Dieser Entwurf dient dann als Grundlage für die nächste Phase, in der die eigentliche Implementierung stattfindet.

In der Design- und Entwurfsphase kommen viele verschiedene Diagrammtypen zum Einsatz, die wir noch kennenlernen werden. Diese helfen uns dabei, das gesamte Softwarekonzept sauber zu planen. Sobald der Entwurf fertig ist, geben wir ihn an die nächste Phase weiter – die Implementierungsphase.

5. Die Implementierungsphase

In der Implementierungsphase beginnt dann die eigentliche Programmierarbeit. Hier wird erstmals produktiv Code geschrieben. Alles, was davor passiert ist, diente im Grunde der Planung und Vorbereitung.

Du siehst also, dass bei einem typischen Softwareprojekt ein großer Teil der Zeit in die richtige Planung investiert wird.

Es ist enorm wichtig, sich in der Planungsphase ausreichend Zeit zu nehmen. Man kann gut und gerne ein Drittel der Gesamtzeit für die Planung einrechnen, um eine solide Grundlage zu schaffen, die alle Aspekte berücksichtigt. 

Einfach drauflos zu programmieren, bringt in den meisten Fällen wenig. Wenn man nur fünf Prozent der Zeit in die Planung steckt und dann denkt: „Super, jetzt kann ich 90 Prozent der Zeit programmieren“, wird man oft am Ende feststellen, dass die Systeme nicht sinnvoll zusammenspielen oder die Software unnötig komplex geworden ist – wie in unserem Beispiel aus dem Einleitungsbeitrag.

Deshalb ist es so wichtig, die Planung gründlich und gewissenhaft durchzuführen, bevor man mit der Implementierung beginnt.

6. Die Testphase

Sobald die Implementierung abgeschlossen ist, kommt die vierte Phase: die Testphase. Diese ist von großer Bedeutung, denn man sollte nie davon ausgehen, dass alles, was programmiert wurde, fehlerfrei funktioniert.

Selbst wenn man die einzelnen Programmteile getestet hat, kann es zu Problemen kommen, sobald die verschiedenen Teile zusammengeführt werden. In einem Team arbeiten oft mehrere Entwickler, und wenn deren Arbeit vereint wird, können unerwartete Fehler auftreten, die vorher nicht sichtbar waren.

Deshalb ist es absolut notwendig, die Software vor der Übergabe an den Kunden gründlich zu testen – und zwar immer wieder.

Stell dir nun mal vor, wir würden die Workshop-Management-Software ohne gründliche Tests an den Kunden ausliefern. Tausende von Menschen melden sich zu den Workshops an, aber im Hintergrund gibt es einen unentdeckten Fehler, der beispielsweise die Anzahl der Anmeldungen nicht korrekt mitzählt.

Das Ergebnis? Am Tag des Workshops stehen plötzlich 200 Teilnehmer vor dem Seminarraum, allerdings gibt es nur Platz für 20.

Das wäre natürlich eine Katastrophe, die sich jedoch leicht verhindern lässt, indem man die Software gründlich testet und sicherstellt, dass sie wie geplant funktioniert.

So vermeidet man im Nachhinein zusätzliche Kosten, etwa durch Entschädigungen für Teilnehmer, die umsonst angereist sind. Darüber hinaus könnte das Unternehmen durch solche Fehler an Ansehen verlieren und für große Unzufriedenheit bei den Kunden sorgen. All das lässt sich durch eine sorgfältige Testphase vermeiden.

7. Die Abnahme und Einführung

Nach Abschluss der Testphase folgt die nächste wichtige Phase: die Abnahme und Einführung. Bei der Abnahme geht es darum, dass der Kunde das entwickelte Softwaresystem überprüft und offiziell freigibt. 

In dieser Phase wird die Software auf das Zielsystem übertragen, installiert und in den Betrieb eingeführt. Dieser Prozess der Verteilung und Installation wird oft als „Rollout“ oder „Deployment“ bezeichnet.

Der Kunde prüft anschließend, ob alles wie erwartet funktioniert und wenn er zufrieden ist, wird die Software offiziell in Betrieb genommen und im Alltag genutzt.

8. Die Wartungsphase

Zum Schluss gelangt die Software in die letzte Phase des Lebenszyklus: die Wartungsphase. In dieser Phase wird die Software kontinuierlich gepflegt und weiterentwickelt, wobei verschiedene Gründe dafür eine Rolle spielen können.

Es kann zum Beispiel sein, dass Bugs erst im laufenden Betrieb entdeckt werden, die der Kunde meldet. Diese müssen wir natürlich beheben. Ein anderer Grund könnte sein, dass das Unternehmen, das die Workshops anbietet, stark wächst und der Traffic auf die Anwendung deutlich zunimmt.

Falls die Software ursprünglich nur für eine bestimmte Anzahl an Nutzern ausgelegt war, könnten Performance-Probleme auftreten, weil die Server überlastet sind. In diesem Fall müssten wir die Software nachträglich optimieren und anpassen, damit sie auch mit dem höheren Traffic reibungslos funktionieren kann.

All diese Dinge erledigt man in der Wartung.

9. Fazit

Das war nun ein grober Überblick über den Software Lebenszyklus. In den kommenden Beiträgen werden wir darauf aufbauen und uns verschiedene Vorgehensmodelle ansehen. Du kannst dir sicher vorstellen, dass es verschiedene Ansätze gibt, um diese Phasen in der Entwicklung zu durchlaufen.

Was meine ich damit? Ein klassischer Ansatz der Softwareentwicklung wäre, alle Phasen von 1 bis 6 der Reihe nach abzuarbeiten. Allerdings gibt es auch andere Ansätze.

Ein Beispiel für einen alternativen Ansatz besteht darin, im ersten Schritt nur das Nötigste zu entwickeln, also ein MVP (Minimal Viable Product). Dieses MVP enthält nur die grundlegendsten Funktionen, um zu testen, ob die Software so funktioniert, wie wir es uns vorstellen, und um dem Kunden eine erste Version zu präsentieren. So kann der Kunde entscheiden, ob er die Software in dieser Form überhaupt benötigt.

Anschließend kann man aus dem Feedback des Kunden lernen und nach und nach weitere Funktionen ergänzen. Dieser iterative Prozess wiederholt sich immer wieder, um die Software stetig zu verbessern.

Es gibt verschiedene Vorgehensmodelle, die diesen Ansatz unterstützen und genau darauf werden wir in den folgenden Beiträgen noch einen genaueren Blick werfen.

Inhaltsverzeichnis

1. Warum ist das Thema Software Engineering so wichtig?

2. Was wirst du in diesem Beitrag lernen?

Zunächst werden wir die grundlegende Frage beantworten, was Software Engineering eigentlich ist. Dabei werde ich den Begriff ausführlich erklären, damit du eine klare Vorstellung davon erhältst.

Im Anschluss sehen wir uns die Ziele an, die wir mit Software Engineering verfolgen  und warum sie in der Praxis so wichtig sind.

Anhand eines Beispiels werde ich dir dann aufzeigen, wie Fehler im Software Engineering zu erheblichen Problemen und Schäden führen können.

Abschließend gebe ich dir einen Ausblick auf die Inhalte des gesamten Crashkurses, damit du entscheiden kannst, ob dieses Thema für dich interessant ist.

Lass uns also direkt mit der ersten Frage starten:

3. Was ist Software Engineering?

4. Die Ziele von Software Engineering

Ein zentrales Ziel des Software Engineering ist die Erstellung von Qualitätssoftware. Doch was bedeutet Qualität in diesem Kontext? Qualität umfasst verschiedene Aspekte, wie beispielsweise die Frage, ob die Software die von den Nutzern erwarteten Funktionen erfüllt. Hier spielt auch die Wirtschaftlichkeit eine Rolle: Wenn die Software die gewünschten Funktionen nicht bereitstellt, wird ein Nutzer sie wahrscheinlich nicht lange verwenden.

Wird der Zweck nicht erfüllt, so macht die Nutzung keinen Sinn und das Projekt ist damit unwirtschaftlich.

Zusätzlich sind weitere Kriterien wichtig: Ist die Software zuverlässig? Funktioniert sie effizient? Ist sie benutzerfreundlich? Lässt sie sich gut warten und pflegen, auch nach der Entwicklungsphase? All diese Punkte sind entscheidend für die Qualität einer Software. Das Ziel des Software Engineering ist es daher, Software von höchster Qualität zu entwickeln.

Ein weiteres Ziel des Software Engineering ist es, Fehler zu vermeiden. Das bedeutet allerdings nicht, dass man Fehler völlig ausschließen sollte. Im Gegenteil: Aus Fehlern lernt man und sie können wertvolle Erkenntnisse liefern. 

Wichtig ist, Fehler nicht ständig zu wiederholen. Wenn man bereits weiß, dass etwas nicht funktioniert, ist es ineffizient, diese Erfahrung erneut zu machen. Stattdessen sollte man auch aus den Fehlern anderer lernen, um sie selbst zu vermeiden.

Software Engineering unterstützt diesen Lernprozess effektiv.

4.3 Aufwände minimieren

Darüber hinaus zielt es darauf ab, Aufwände zu minimieren. Das steht in engem Zusammenhang mit der Vermeidung von Fehlern.

4.4 Den Kundennutzen maximieren

Ein anderes wichtiges Ziel des Software Engineering ist es, den Kundennutzen zu maximieren. Dabei wird deutlich, wie wichtig es ist, den Kunden stets im Fokus zu behalten und zu überlegen: „Was möchte der Kunde oder die Kundin überhaupt?“

Es spielt keine Rolle, ob der Kunde ein Unternehmen ist, das dich beauftragt hat, eine Software zu entwickeln, eine Nutzerin einer Webanwendung, die du erstellt hast, oder ein Spieler eines Spiels, das du programmiert hast – all diese Personen fallen unter den Begriff „Kunden“.

5. Mehr als nur Programmieren

Die Vielzahl der Ziele, die im Software Engineering verfolgt werden, deutet schon darauf hin, dass dieses Feld ziemlich umfangreich ist. Bei der Erstellung von Software geht es nicht nur um das Programmieren, was viele fälschlicherweise annehmen.

Programmieren ist lediglich ein Teil des gesamten Prozesses.

Es gibt viele Aspekte, die man beim Software Engineering berücksichtigen muss und ein wesentlicher Teil davon ist das Projektmanagement. Dabei ist es entscheidend, einen klaren Plan zu haben, der festlegt, wer der Kunde ist, was wann programmiert wird und wer in einem Team für welche Aufgaben verantwortlich ist. 

Besonders im Spielebereich sollte man auch die Zielgruppe genau definieren und psychologische Aspekte berücksichtigen, um sicherzustellen, dass das Spiel langfristig gespielt wird.

Ein strukturierter Plan ist unerlässlich, ebenso wie kontinuierliche Tests, um zu überprüfen, ob die bisherigen Entwicklungen funktionieren. Sobald die Software in Betrieb genommen wird, ist es wichtig, sie zu übergeben, wenn sie für einen Kunden entwickelt wurde und sie anschließend regelmäßig zu warten.

Zusammenfassend lässt sich also sagen, dass Software Engineering von enormer Bedeutung ist und ein umfangreiches Feld darstellt.

6. Warum Software Engineering auch für Anfänger wertvoll ist

Unser Ziel ist es, dir mit diesem Crashkurs einen umfassenden Überblick über das Thema zu geben und dir zu zeigen, wie man diese Konzepte in der täglichen Praxis der Softwareentwicklung anwendet.

Egal, ob es sich um große oder kleine Projekte handelt, Software Engineering ist grundsätzlich für alle Entwicklungsprozesse entscheidend. Besonders wichtig ist es, zu verstehen, dass diese Prinzipien nicht nur für erfahrene Entwickler relevant sind. 

Selbst wenn du gerade erst in die Programmierung eingestiegen bist und das Gefühl hast, dass große Projekte noch in weiter Ferne liegen, möchte ich dir ans Herz legen, diese Serie durchzulesen. Sie vermittelt grundlegende Konzepte und Strukturen, die du von Anfang an richtig umsetzen kannst.

Auf diese Weise vermeidest du die Situation, in der du monatelang an etwas arbeitest, nur um später festzustellen, dass das Projekt nicht funktioniert. Genau dafür ist Software Engineering da – um dir dabei zu helfen, Projekte von Anfang an auf den richtigen Weg zu bringen.

7. Negativbeispiel aus der Praxis: Ein Fehler kostete 60 Millionen Euro

Um noch einmal zu verdeutlichen, warum dieses Thema so wichtig ist, möchte ich einen Bericht von Heise.de heranziehen. Dieser stammt zwar vom 16. Februar 2017, ist aber immer noch sehr relevant. Die Schlagzeile lautete damals: „60 Millionen Euro versenkt: Bundesagentur für Arbeit stoppt IT-Projekt ROBASO“.

In dem Artikel wird beschrieben, wie die Bundesagentur für Arbeit 14 verschiedene interne Anwendungen nutzt, damit ihre Mitarbeiter ihre täglichen Aufgaben erledigen können. Das Ziel war es, eine zentrale Softwareplattform zu entwickeln, auf der alle diese Anwendungen zusammengeführt werden, um einen einheitlichen Zugangspunkt für die Mitarbeiter zu schaffen.

Die Idee klang zunächst logisch: Man hatte einen klaren Zweck definiert und wollte eine Software entwickeln, die all diese Anforderungen erfüllt. So startete das Projekt, wenn ich mich richtig erinnere, im Jahr 2010. Über mehrere Jahre hinweg wurde daran gearbeitet, und die Software wuchs zu einem extrem komplexen System heran. Nach einigen Jahren führte man dann einen Pilottest durch – und das Ergebnis war ernüchternd: Die Software erwies sich als viel zu unflexibel für den täglichen Einsatz.

7.1 Der Grund für den Fehler

Doch was bedeutet, dass die Software „unflexibel“ war? Im Bericht gab es ein Beispiel: Wollte man etwa die Kontonummer eines Kunden ändern, war dies zwar technisch möglich, aber die Mitarbeiter mussten anschließend zahlreiche weitere Daten manuell eingeben, obwohl nur eine kleine Änderung notwendig war.

Die Software war derart komplex, dass am Ende kaum jemand damit arbeiten konnte.

Letztlich stellte man fest, dass das gesamte Projekt gescheitert war – und das zu einem Preis von 60 Millionen Euro, die somit verloren waren.

Ein Blick in den Artikel zeigt eine entscheidende Stelle, in der es heißt: „Erst bei der Pilotierung im Februar 2016 wurde festgestellt, dass es kein standardisiertes Systemgeschäft gibt und die komplexen und vielfältigen Fallgruppen der Kundenanliegen einer sehr differenzierten Arbeitspraxis bedürfen.“

Man stellte also fest, dass das Vorhaben nicht so umsetzbar war, wie ursprünglich gedacht. Obwohl man in diesem Projekt Methoden des Software Engineering angewandt hatte, wurde in einer entscheidenden Phase ein Fehler gemacht.  

Man hat nicht ausreichend analysiert, ob das Konzept überhaupt realisierbar ist. Stattdessen investierte man weiter, zahlte Entwickler, Projektmanager und steckte immer mehr Geld in die Entwicklung – nur um am Ende festzustellen, dass das gesamte Budget von 60 Millionen Euro verschwendet worden war und kein brauchbares Ergebnis dabei herauskam.

8. Warum Softwareprojekte scheitern

Warum zeige ich dir dieses Beispiel? Ich möchte dir damit verdeutlichen, wie viel auf dem Spiel steht, insbesondere bei Entwicklungsprojekten dieser Größenordnung. 60 Millionen Euro klingen nach einer unglaublichen Summe – und genau das soll dir zeigen, wie gravierend Fehler im Prozess sein können. Schon kleine Versäumnisse können dazu führen, dass ein ganzes Projekt scheitert.

Interessanterweise scheitern die meisten Softwareprojekte nicht an technischen Problemen, sondern an Aspekten wie schlechtem Projektmanagement oder einer unzureichenden Auseinandersetzung mit der Zielgruppe. Dadurch wird etwas entwickelt, das am eigentlichen Bedarf vorbeigeht.

Solche Probleme treten häufiger auf, als dass technische Aspekte nicht realisierbar sind. Auch wenn Großprojekte für dich als Programmieranfänger vielleicht noch weit entfernt erscheinen, möchte ich dir damit zeigen, was passieren kann, wenn man sich nicht an grundlegende Prinzipien hält oder kleine Fehler im Prozess macht.

9. Wann Software Engineering für kleine Entwickler sinnvoll ist

Das gilt auch für kleine Entwickler. Wenn du beispielsweise nur ein Skript schreibst, das Dateinamen umbenennt, brauchst du dafür natürlich keine große Planung – das kannst du einfach und schnell umsetzen. Genauso bei kleinen Anwendungen: In manchen Fällen kannst du ohne großen Plan direkt starten.

Sobald ein Projekt allerdings etwas größer wird, wirst du rasch merken, dass es nicht sinnvoll ist, sich einfach hinzusetzen und beispielsweise in Java mit Eclipse oder IntelliJ, ohne Plan Klassen zu erstellen und drauflos zu programmieren. 

Du wirst feststellen, dass dir nach ein paar Stunden immer wieder neue Dinge einfallen, die du noch berücksichtigen musst. Deshalb ist es wichtig, sich im Vorfeld wirklich Gedanken zu machen.

Software Engineering bietet hier ein strukturiertes Vorgehen, das dir Schritt für Schritt zeigt, wie du dein Projekt mit bewährten Methoden („Best Practices“) umsetzen kannst. 

Deshalb ist es auch für dich als Programmiereinsteiger wichtig, diese Tutorialreihe zu lesen oder im Videoformat anzusehen. Du wirst dabei viele wertvolle Dinge lernen, die dir in deiner weiteren Entwicklung enorm helfen werden. Selbst wenn du bereits etwas Programmiererfahrung hast, aber bisher noch nicht mit Software Engineering in Berührung gekommen bist, lege ich dir diese Serie ans Herz.

Wir haben uns nun ein Beispiel angesehen, das verdeutlicht, welche Folgen kleine Fehler in einem Projekt haben können – auch in finanzieller Hinsicht.

Zum Abschluss möchte ich dir noch einen Ausblick darauf geben, was dich im weiteren Verlauf dieses Crashkurses erwartet.

10. Was wirst du in diesem Crashkurs noch lernen?

Wir werden uns unter anderem verschiedene Vorgehensmodelle ansehen. Diese Modelle zeigen unterschiedliche Ansätze, wie wir von A bis Z eine Software entwickeln können. Es gibt davon zahlreiche Varianten.

Zum Beispiel das Wasserfallmodell oder agile Methoden wie Scrum. Dabei werden wir einige dieser Vorgehensmodelle kennenlernen, damit du mit ihnen vertraut wirst und ein grundlegendes Verständnis dafür entwickelst.

Als Nächstes werden wir uns mit Diagrammen befassen, die dazu dienen, Software zu beschreiben. Wenn du einen Plan für die Entwicklung erstellst, musst du klar kommunizieren, was du bauen möchtest. Besonders in einem Team ist es wichtig, dass jeder den Plan versteht.

Es gibt eine Vielzahl von Diagrammen, die du nutzen kannst, um anderen zu verdeutlichen, was du programmieren möchtest. Wir werden verschiedene Diagramme betrachten, die jeweils für unterschiedliche Einsatzzwecke geeignet sind.

Anschließend werden wir uns mit der Implementierung beschäftigen. Ich werde dir einige Kniffe und Prinzipien vorstellen, wie du deine Programme so designen kannst, dass der Code sauber und wartbar bleibt.

Außerdem werden wir verschiedene Testarten kennenlernen, uns mit der Abnahme und Inbetriebnahme auseinandersetzen und auch über die Wartung von Software sprechen. Dabei werden wir die Gründe erörtern, warum Software regelmäßig gewartet werden muss.

Das ist natürlich nur ein kleiner Ausblick auf das, was auf dich zukommen wird. Es gibt noch viele weitere Themen, die auf uns warten.