Der inkrementelle Ansatz verwendet eine festgelegte Anzahl von Schritten und die Entwicklung verläuft von Anfang bis Ende in einem linearen Verlauf.
Die inkrementelle Entwicklung erfolgt in Schritten von Design, Implementierung, Test / Verifikation bis hin zur Wartung. Diese können weiter in Unterschritte unterteilt werden, aber die meisten inkrementellen Modelle folgen demselben Muster. Das Wasserfallmodell ist ein traditioneller inkrementeller Entwicklungsansatz.
Der iterative Ansatz hat keine festgelegte Anzahl von Schritten, vielmehr erfolgt die Entwicklung in Zyklen.
Bei der iterativen Entwicklung geht es weniger darum, den Fortschritt einzelner Features zu verfolgen. Stattdessen liegt der Schwerpunkt darauf, zuerst einen funktionierenden Prototyp zu erstellen und Features in Entwicklungszyklen hinzuzufügen, in denen die Schritte für die inkrementelle Entwicklung für jeden Zyklus ausgeführt werden. Agile Modeling ist ein typischer iterativer Ansatz.
Das inkrementelle Modell wurde ursprünglich entwickelt, um dem in Fabriken verwendeten traditionellen Fließbandmodell zu folgen. Leider haben Softwaredesign und -entwicklung wenig mit der Herstellung physischer Güter zu tun. Code ist die Blaupause, nicht das fertige Produkt der Entwicklung. Gute Designentscheidungen werden häufig während des Entwicklungsprozesses "entdeckt". Das Einschließen der Entwickler in eine Reihe von Annahmen ohne den richtigen Kontext kann im besten Fall zu schlechten Designs oder im schlimmsten Fall zu einer vollständigen Entgleisung der Entwicklung führen.
Der iterative Ansatz ist mittlerweile allgemein üblich, da er besser zum natürlichen Fortschritt in der Softwareentwicklung passt. Anstatt viel Zeit und Mühe in die Suche nach dem „perfekten Design“ zu investieren, geht es beim iterativen Ansatz darum, etwas zu entwickeln, das „gut genug“ ist, um anzufangen und es an die Bedürfnisse des Benutzers anzupassen.
tl; dr - Wenn Sie einen Aufsatz nach dem inkrementellen Modell schreiben würden, würden Sie versuchen, ihn von Anfang an perfekt zu schreiben, um jeweils einen Satz zu beenden. Wenn Sie es unter dem Iterativen Modell schreiben würden, würden Sie schnell einen groben Entwurf erstellen und daran arbeiten, ihn durch eine Reihe von Überarbeitungsphasen zu verbessern.
Aktualisieren:
Ich habe meine Definition für "Incremental Approach" geändert, um sie einem praktischeren Beispiel anzupassen.
Wenn Sie sich jemals mit Vertragsabschlüssen befassen mussten, werden die meisten Verträge (insbesondere für das Militär) nach dem inkrementellen Ansatz ausgeführt. Trotz der vielen subtilen Variationen des typischen "Wasserfallmodells" werden die meisten von ihnen in der Praxis auf die gleiche Weise angewendet.
Die Schritte gehen wie folgt vor sich:
- Auftragsvergabe
- Vorläufige Entwurfsprüfung
- Kritische Designprüfung
- Spezifikation Einfrieren
- Entwicklung
- Fielding / Integration
- Nachprüfung
- Zuverlässigkeitstests
In PDR und CDR wird die Spezifikation erstellt und überarbeitet. Sobald die Spezifikation vollständig ist, sollte sie eingefroren werden, um ein Kriechen des Oszilloskops zu verhindern. Die Integration erfolgt, wenn die Software zur Erweiterung eines vorhandenen Systems verwendet wird. Mit der Überprüfung wird überprüft, ob die Anwendung der Spezifikation entspricht. Die Zuverlässigkeit ist ein Test, um zu beweisen, dass die Anwendung auf lange Sicht zuverlässig ist. Dies kann ähnlich wie bei einer SLA (Service Level Agreement) angegeben werden, bei der das System einen bestimmten Prozentsatz der Betriebszeit aufrechterhalten muss (ex 99% Betriebszeit für 3 Monate) ).
Dieses Modell eignet sich hervorragend für Systeme, die auf Papier einfach zu spezifizieren, aber schwer herzustellen sind. Es ist sehr schwierig, Software auf Papier mit einem nennenswerten Detaillierungsgrad (ex UML) zu spezifizieren. Die meisten Geschäftsarten "verantwortlich für Management / Auftraggeber nicht erkennen , dass - wenn es um Software - Entwicklung kommt - der Code selbst ist die spec. Papierspezifikationen benötigen zum Schreiben oft mindestens so viel Zeit und Mühe wie der Code selbst und erweisen sich in der Praxis normalerweise als unvollständig / minderwertig.
Inkrementelle Ansätze versuchen, die verschwendete Zeit / Ressourcen zu nutzen, indem der Code selbst als Spezifikation behandelt wird. Anstatt die Papierspezifikation durch mehrere Revisionsschritte zu führen, durchläuft der Code selbst mehrere Revisionszyklen.