私はソフトウェア開発方法論を含む小さな研究論文を書いています。私は利用可能なすべての方法論を調べていましたが、すべての方法論から、他の方法の基礎を提供しているものはあるのでしょうか。
例として、
アジャイル、プロトタイピング、クリーンルーム、反復、RAD、RUP、スパイラル、ウォーターフォール、XP、リーン、スクラム、Vモデル、TDDの方法論を見てみましょう。
私たちはそれを言うことができます：
プロトタイピング、反復、スパイラル、ウォーターフォールは他のものの「基礎」です？
それとも「基礎」などはなく、それぞれの方法論には独自の歴史がありますか？
もちろん、私は自分の論文ですべての方法論について説明したいと思いますが、それを行う時間がないので、どの方法論を代表として見ることができるかを知りたいのです。
回答:
リストの名前はすべての方法論ではなく、さまざまなレベルでスケーリングされます。
基礎となる識別は難しい仕事です。あなたは明らかに歴史的な線を引くことができますが、方法論が別のものに直接基づいていることはほとんどありません。それらはむしろ重なり合い、互いに借用し、時々互いに応答します...明確に定義された分類を見ることができませんが、おそらくいくつかの大家族の概要を説明できます。
それを見る別の方法は、世代の観点からです。エンタープライズソフトウェアに関しては、2世代の方法論が知られていると思います。最初のものは、ウォーターフォールとVモデルの中で、ソフトウェアに適用された他のエンジニアリング分野からの既存のプロセスがほとんどでした。第2世代（アジャイルと呼ぶこともできますが、アジャイルという用語が生み出されるずっと前に始まりました）は、第1世代のプロセスの重さに対応して開始され、人々はソフトウェアがまったく異なる動物であり、基準が良いソフトウェアとこれらの基準を確実にすることができるステップは本当に具体的であり、まだ調査されなければなりませんでした。
最後に、ソフトウェアでは他の分野よりも多分、方法論は、物事を機能させるために適用できるレシピではないことに注意してください。ソフトウェア開発には、技術的な側面と同じくらい多くの人間的な側面があり、チームまたはマネージャーが特効薬の方法論と、やみくもに適用するもののチェックリストを考え出すことは、いくつかの驚きを期待できます。Chaos Reportのようなソフトウェアプロジェクトの成功率に関する研究を毎年見るだけで、ソフトウェアの方法論の歴史は、一連の失敗した試行とは、確固たる科学的に確立された反復可能なプロセスのルールよりも関係があることがわかります。
3つあります：
残りはこれらのバリアントと組み合わせです
ウォーターフォールからのアーティファクト（開始、要件、機能仕様、設計仕様、テスト仕様、品質管理仕様など）はすべて、プロジェクトにとって重要な事項をカバーしていることに注意してください。非常に異なる方法。たとえば、TDDでは、機能、ユーザーストーリー、およびテストの説明は、ウォーターフォールの要件、機能仕様、およびテスト仕様をカバーしています。RUPではさらに多くのアーティファクトが追加され、ウォーターフォール仕様の一部（たとえば、利害関係者のドキュメントは開始ドキュメントの一部）を壊しますが、らせん状に進行します
完了したら、結果へのリンクを公開してください。興味深い論文のようです。
たぶん、次のようなアンティークの方法論（「方法論」ではなく）に言及したいと思うかもしれません。
バッチ処理：カードのデッキを送信して、翌日に出力を取得します。欠点：提出の間隔が長すぎる。デバッグのために、コアダンプを調べます。
cliメソッド-viまたはemacsを使用してコンパイルします。コマンドラインからのすべては、今日までLinuxシェルで行われているのと同じです。欠点：デバッグするのが難しい（gdb？冗談でしょう？）、40年前のシェルコマンドがわかりにくい。
ちょっとした考え。
プロトタイピング、スパイラル、ウォーターフォールという3つの基本的なアプローチに言及できます。リーン、TDD、またはクリーンルームを方法論と見なすのではなく、方法論の一部となるプロセスを検討します。