Welche Softwareentwicklungsmethoden können als Grundlage angesehen werden?

Ich schreibe eine kleine Forschungsarbeit, die Methoden zur Softwareentwicklung beinhaltet. Ich habe mir alle verfügbaren Methoden angesehen und mich gefragt, ob es von allen Methoden irgendwelche gibt, die die Grundlagen für die anderen geschaffen haben.

Betrachten Sie als Beispiel die folgenden Methoden:
Agil, Prototyping, Reinraum, Iterativ, RAD, RUP, Spirale, Wasserfall, XP, Lean, Scrum, V-Modell, TDD.

Können wir das sagen:
Prototyping, Iterative, Spirale und Wasserfall sind die "Grundlage" für die anderen?

Oder gibt es keine "Grundlagen" und hat jede Methodik ihre eigene Geschichte?

Ich würde natürlich gerne alle Methoden in meinem Forschungsbericht beschreiben, aber ich habe einfach nicht die Zeit dazu und deshalb möchte ich wissen, welche Methoden als Vertreter angesehen werden können.

Die Namen in Ihrer Liste sind nicht alle Methoden und werden auf verschiedenen Ebenen skaliert:

• Iterativ ist ein Merkmal, ein Merkmal, das von verschiedenen Methoden und Techniken geteilt wird. Scrum ist eine iterative Methode, TDD ist eine iterative Technik.
• Ich sehe Agile als eine Methodik-Obermenge, die auf einer konzeptuellen / philosophischen Ebene bleibt. In der objektorientierten Programmierung könnte man es als abstrakt beschreiben - es ist eine Reihe von Werten und Prinzipien, die nicht instanziiert werden können und abgeleitet und implementiert werden müssen. Genau das machen Scrum und XP.
• Reinraum, RAD, RUP, Spirale, Wasserfall, XP, Lean, Scrum, V-Modell sind geeignete Methoden, dh Softwareentwicklungsprozesse (obwohl Scrum behauptet, ein leichtes "Framework" im Gegensatz zu einem schweren Prozess zu sein).
• Prototyping und TDD sind Techniken, Aktivitäten. TDD ist eine XP-Praxis.

Zu unterscheiden, welches die Grundlage ist, ist eine schwierige Aufgabe. Sie können natürlich eine historische Linie ziehen, aber eine Methodik basiert selten direkt auf einer anderen. Sie überschneiden sich eher, leihen sich gegenseitig aus, reagieren manchmal aufeinander ... Ich sehe keine klar definierte Klassifizierung, obwohl Sie wahrscheinlich einige große Familien skizzieren könnten.

Eine andere Sichtweise ist aus der Perspektive der Generation. In Bezug auf Unternehmenssoftware würde ich sagen, dass wir zwei Generationen von Methoden kennen. Die ersten, darunter Waterfall und V-Model, waren größtenteils bereits vorhandene Prozesse aus anderen technischen Disziplinen, die auf Software angewendet wurden. Die zweite Generation (man kann es Agile nennen, aber sie begann lange bevor der Begriff Agile geprägt wurde) wurde als Reaktion auf die Schwere der Prozesse der ersten Generation initiiert, als die Menschen erkannten, dass Software ein völlig anderes Tier ist und dass die Kriterien gut sind Software und die Schritte, mit denen diese Kriterien sichergestellt werden können, waren wirklich spezifisch und mussten noch untersucht werden.

Schließlich sollten Sie jedoch beachten, dass Methoden in Software möglicherweise sogar mehr als in anderen Disziplinen keine Rezepte sind, die Sie einfach anwenden können, damit die Dinge funktionieren. Die Softwareentwicklung hat so viele menschliche Aspekte wie technische Aspekte, und ein Team oder ein Manager, der eine Silver Bullet-Methode und eine Checkliste mit Dingen entwickelt, die blind angewendet werden müssen, kann einige Überraschungen erwarten. Wenn Sie sich Jahr für Jahr Studien zu Erfolgsraten von Softwareprojekten wie dem Chaos Report ansehen, können Sie feststellen, dass die Geschichte der Softwaremethoden mehr mit einer Reihe fehlgeschlagener Versuche zu tun hat als mit der Regel solider, wissenschaftlich etablierter, wiederholbarer Prozesse.

Dort sind drei:

1. keine (auch bekannt als Cowboy-Codierung)
2. Wasserfall
3. schnelle Anwendungsentwicklung (RAD oder Spirale)

der Rest sind Varianten und Kombinationen davon

Beachten Sie, dass die Artefakte aus dem Wasserfall (Beginn, Anforderungen, Funktionsspezifikation, Konstruktionsspezifikation, Testspezifikation, Qualitätskontrollspezifikation usw.) alle Dinge abdecken, die für das Projekt wichtig sind, von denen die meisten, wenn nicht alle, von anderen Methoden abgedeckt werden, aber in ganz andere Wege. In TDD decken beispielsweise die Funktionen, User Stories und Testbeschreibungen die Anforderungen, Funktionsspezifikationen und Testspezifikationen von Wasserfällen ab. In RUP werden noch mehr Artefakte hinzugefügt, die einen Teil der Wasserfallspezifikationen abbrechen (das Stakeholder-Dokument ist beispielsweise ein Teil des Inception-Dokuments), aber spiralförmig ablaufen

Bitte veröffentlichen Sie einen Link zu Ihren Ergebnissen, wenn Sie fertig sind. Es klingt nach einem interessanten Artikel!

Vielleicht möchten Sie nur antike Methoden (nicht Methoden) erwähnen wie:

1. Stapelverarbeitung: Senden Sie ein Kartenspiel und erhalten Sie die Ausgabe am nächsten Tag zurück. Nachteile: zu viel Zeit zwischen den Einreichungen; Studieren Sie zum Debuggen einen Core-Dump.

2. cli-Methoden - benutze vi oder emacs und kompiliere dann; Alles von der Kommandozeile aus, so wie es bis heute in einer Linux-Shell gemacht wird. Nachteile: schwer zu debuggen (gdb? Willst du mich veräppeln?), Undurchsichtige 40 Jahre alte Shell-Befehle.

Nur ein Gedanke.

Sie können drei grundlegende Ansätze erwähnen: Prototyping, Spirale und Wasserfall. Ich würde Lean, TDD oder Cleanroom nicht als Methodik betrachten, sondern als Prozess, der Teil der Methodik sein kann.