Seit vielen Jahren übernehmen wir Kundenprojekte im Bereich der Softwareentwicklung. Was sind unsere Vorteile? Wir bieten qualitativ hochwertige Softwareentwicklung, stehen unseren Kunden mit unternehmerischem Denken und über 100 Projekten fachlich zur Seite und schätzen effektive Kommunikation. Allerdings haben wir seit langem ein Problem: die Anforderungsspezifikation. Die Herausforderungen, die die Routine mit sich bringt…

Seit vielen Jahren übernehmen wir Kundenprojekte im Bereich der Softwareentwicklung. Was sind unsere Vorteile? Wir bieten qualitativ hochwertige Softwareentwicklung, stehen unseren Kunden mit unternehmerischem Denken und über 100 Projekten mit Expertise zur Seite und schätzen effektive Kommunikation. Seit längerer Zeit stoßen wir jedoch auf ein Problem: die Anforderungsspezifikation.

Was ist die Lösung? Scrum-basierte agile Software-Entwicklung

Daraufhin haben wir uns weitergebildet und die sogenannte Scrum-Technik entdeckt. Scrum ist eine agile Softwareentwicklungsmethode, die mehr Flexibilität als die Wasserfallmethode ermöglicht – ein Vorteil, der nicht nur uns, sondern auch unseren Kunden zugute kommt.

Softwareentwicklung Wasserfallmodell : DAS  WASSERFALLMODELL VERSUS AGIL

Vor dem Aufkommen der agilen Softwareentwicklung war das Wasserfall-Paradigma der De-facto-Standard für das Management von IT-Projekten. In diesem Fall wurden Produkte oder große traditionelle Programme nach dem Projekt als eine einzige massive Anwendung bereitgestellt, komplett mit Front-End, Back-End, DNS-Routen und anderen erforderlichen Diensten. Monolithische Anwendungen sind große, nicht-modulare Anwendungen.

Die Besonderheit bestand darin, dass man mit dem Problem eines einzigen Fehlerpunkts konfrontiert wurde. Wenn Änderungen an dieser Anwendung erforderlich waren, wurden Dienste oder Anwendungen während der Wartungszeit abgeschaltet (wodurch diese Dienste für die Außenwelt unzugänglich wurden), um die Einbindung dieser neuen Funktionen oder Änderungen in das Produktionssystem zu ermöglichen.

Ein weiteres Problem war der häufige Wechsel der Kundenbedürfnisse, der ebenfalls in wesentlich kürzeren Abständen stattfand. Das erforderte neue Methoden!

Bei der agilen Softwareentwicklung wurde der Kunde in den Entwicklungsprozess integriert und maßgeblich beteiligt. Die modulare Entwicklung ermöglicht nun den Nachweis von Teilerfolgen und die Fähigkeit, flexibel auf veränderte Bedürfnisse zu reagieren.

Nota bene: Agile Methoden schließen die Entwicklung von monolithischen Anwendungen nicht aus. Das Beispiel sollte die Bedürfnisse des Kunden verdeutlichen und zeigen, warum agile Vorgehensweisen unerlässlich sind.

Mehrere Begründungen für agile Softwareentwicklung

Innerhalb weniger Jahre hat die Mehrheit der Unternehmen agile Methoden eingeführt. Auch wir haben uns bewusst dafür entschieden, um unsere Interaktion mit den Kunden zu verbessern, die Effizienz unserer Arbeit zu steigern und bessere Ergebnisse zu erzielen. Wir haben die Vorteile der agilen Softwareentwicklung, die wir und unsere Kunden genießen, im Folgenden zusammengefasst.

Softwareentwicklung Wasserfallmodell: DIE VIER LEITPRINZIPIEN DER AGILEN ENTWICKLUNG

Die Leitprinzipien sind Ideale, die im Manifest als Alternativen zu traditionellen Methoden definiert sind.

1. Menschen und ihre Beziehungen sind wichtiger als Verfahren und Ausrüstung 2. Eine funktionierende Software ist wichtiger als eine gründliche Dokumentation. 3. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen 4. Die Anpassung an Veränderungen ist wichtiger als das Festhalten an einem Plan Was bedeutet das nicht?

Natürlich bedeutet die Präferenzverbindung “ist/sind wichtiger” nicht, dass Verfahren, Werkzeuge oder Dokumentation irrelevant sind. Vielmehr lauten die vier Leitbegriffe wie folgt:

6. EIN KURZER ÜBERBLICK ÜBER AGILE METHODEN.

Agile Methoden bieten einen Rahmen für das Management erfolgreicher IT-Projekte. Dieser Rahmen beinhaltet agile Methoden und damit auch die Ideen und Werte des Manifests. Die grundlegende Struktur der Methoden ermöglicht die Planung von Prozessen und die effektive Arbeit von agilen Teams. Scrum ist eine bekannte Technik, die sich nicht nur in der Softwareentwicklung durchgesetzt hat.

Jeder, der sich in seinem Berufsleben mit Projektmanagement beschäftigt hat, ist höchstwahrscheinlich schon einmal auf den Begriff Technicus Scrum oder eine Variante davon gestoßen oder hat ihn verwendet. In jedem Fall ist es nicht einfach, eine Liste der Unterscheidungen zwischen den Techniken zu erstellen – viele Methoden sind Varianten von anderen, mit fließenden Übergängen. Neben Scrum haben sich weitere agile Methoden im Bereich des informationstechnischen Projektmanagements etabliert:

Softwareentwicklung Wasserfallmodell: Komplexe Projekte erfordern den Einsatz zeitgemäßer, anpassungsfähiger Techniken.

Für komplizierte Projekte, die von Natur aus anfällig für viele Änderungen sind, werden iterative Techniken dringend empfohlen. Natürlich sind wir nicht die einzigen, die sich für die iterative Softwareentwicklung einsetzen; zu den bekannten und anerkannten Befürwortern gehören Harlan Mills. Brooks, Frederick Boehm, Barry Martin, James DeMarco, Tom Ed Yourdon, um nur einige zu nennen. Craig Larman, der eine Reihe prominenter Softwareentwickler vertritt, kommt angesichts der obigen und vergleichbarer Studienergebnisse zu einem klaren Schluss:

Haben Sie noch Fragen zur agilen Entwicklung? Stehen Sie vor einem Softwareentwicklungsprojekt oder brauchen Sie Hilfe bei einem bestehenden Projekt? Wir sind Spezialisten für iterative Entwicklung mit langjähriger Erfahrung in der Umsetzung von Scrum und XP.

Vorteile und Nachteile

Der Hauptvorteil des Wasserfallmodells liegt ganz klar in seiner einfachen Struktur und Idee. Durch die zu Beginn durchgeführte gründliche Recherche und das daraus resultierende Design werden mögliche Probleme bereits vor Projektbeginn erkannt. So können Lösungswege parallel zur Projektplanung entwickelt werden.

Gleichzeitig ist diese Struktur aber leider auch ihre Achillesferse. Da mögliche Fehler oft erst in der Testphase nach der Realisierung entdeckt werden, sind Änderungen nur schwer oder nur mit großem Aufwand möglich. Tritt ein Fehler schon vorher auf, lässt die starre Abfolge der Schritte nur selten eine Korrektur zu. In den meisten Fällen besteht die einzige Alternative darin, zur Entwurfsphase zurückzukehren und den Implementierungsprozess von Grund auf neu zu beginnen – ein teurer und zeitaufwändiger Vorgang.

Royce hat dieses Problem in seinem Artikel erkannt und die folgende optimierte Variante vorgeschlagen: So werden in das erweiterte Wasserfallmodell Rückwärtsschritte eingebaut, um Probleme durch Feedback frühzeitig zu erkennen und zu korrigieren.

Gerade in der Umsetzungsphase (III) werden oft Fehler deutlich, die in der Entwurfsphase (II) nicht erkannt wurden – das Pendeln zwischen den beiden Phasen ermöglicht eine frühzeitige Reparatur und Verbesserung des Projekts.

Softwareentwicklung Wasserfallmodell: Die Phasen des Wasserfallmodells

Das Wasserfallmodell ordnet die Phasen eines Entwicklungsprozesses kaskadenförmig an. Jeder Schritt endet mit einem Zwischenergebnis (Meilenstein), z. B. einem Anforderungskatalog in Form eines Pflichtenhefts, einer Software-Architekturspezifikation oder einer Alpha- oder Beta-Version einer Anwendung. Der neue Wasserfall Modell oder auch V Modell gennant, hat noch sehr viel Zeit vor sich

Die Bewertung des Wasserfallmodells

Das Wasserfallmodell gibt einen klaren organisatorischen Rahmen für Entwicklungsprojekte vor, indem es die verschiedenen Projektphasen klar abgrenzt. Der Entwicklungsprozess ist einfach zu verfolgen, da jeder Schritt mit einem Meilenstein endet. Das Hauptziel des Modells ist die Erfassung der Prozessschritte. Die gewonnenen Erkenntnisse werden in Anforderungs- oder Designpapieren dokumentiert.

Grundsätzlich soll der Wasserfallansatz eine schnelle und kostengünstige Projektdurchführung fördern, indem er eine akribische Vorbereitung im Vorfeld erfordert. Der praktische Nutzen des Wasserfallmodells ist jedoch umstritten. Einerseits haben Softwareentwicklungsprojekte nur selten klar definierte Phasen. Vor allem bei großen Softwareprojekten sind die Entwickler häufig mit der Tatsache konfrontiert, dass sich die vielen Komponenten einer Anwendung gleichzeitig in unterschiedlichen Entwicklungsphasen befinden. Andererseits entspricht der lineare Ablauf des Wasserfallmodells nur selten den realen Gegebenheiten. Die einzelnen Phasen des Projektes, und die ganzen Beiträge bilden größere Systeme.

Anpassungen während des gesamten Projektverlaufs sind bei der Wasserfallmethode streng genommen nicht vorgesehen. Ein Softwareprojekt, bei dem alle Aspekte der Entwicklung von Anfang an festgelegt sind, kann nur dann effektiv abgeschlossen werden, wenn zu Beginn viel Zeit und Ressourcen in die Analyse und Konzeptionierung investiert werden. Außerdem können große Softwareprojekte viele Jahre in Anspruch nehmen und würden ohne ständige Anpassung an aktuelle Fortschritte Ergebnisse hervorbringen, die zum Zeitpunkt ihrer Einführung bereits veraltet sind.

Softwareentwicklung Wasserfallmodell: Verifizierung am Ende jeder Projektphase

Royce zufolge sollten die Ergebnisse jeder Projektphase umgehend überprüft und anhand der zuvor erstellten Dokumentation validiert werden. So müsse beispielsweise unbedingt überprüft werden, ob ein Modul die zuvor festgelegten Kriterien erfüllt, sobald es erstellt wurde, und nicht erst am Ende.

Mindestens zwei Iterationen

Royce zufolge sollte der Wasserfallansatz mindestens zweimal verfolgt werden: einmal für das Prototyping und einmal für die Entwicklung des endgültigen Softwareprodukts.

Softwareentwicklung Wasserfallmodell: Tests, an denen der Endbenutzer beteiligt ist

Als dritte Erweiterung des Wasserfallmodells plädierte Royce in seinem Artikel für eine Technik, die inzwischen in der Produktentwicklung üblich geworden ist: die Einbeziehung des Endbenutzers in den Herstellungsprozess. Royce empfiehlt, den Benutzer zu drei Zeitpunkten in den Softwareentwicklungsprozess einzubeziehen: während der Planungsphase als Teil der Analysephase, zwischen der Softwaredesign- und der Implementierungsphase und während der Testphase vor der Freigabe des Programms.