ソフトウェア開発方法論（; SDM）は、ソフトウェア開発に用いられる一連のルール・ガイドライン、またそれを扱うソフトウェア工学の一分野である。システム開発方法論（）とも。

 概要 
ソフトウェア・情報システムは目的を達成するために開発される。開発を1つのプロセス（ソフトウェア開発工程）として捉えると、開発スタイルにより様々な構造・制約（ルール）・原則が見いだされる。一連のルール・ガイドラインからなる1つの開発スタイルがソフトウェア開発方法論である。また様々なスタイルに共通するあるいは特有なルールを研究するソフトウェア工学の分野もソフトウェア開発方法論と呼ばれる。

 歴史 
ソフトウェア開発方法論 (SDM) のフレームワークが生まれたのは1960年代のことである。Elliott によれば、情報システム構築のための最古の定式化された方法論フレームワークはシステム開発ライフサイクル (SDLC) だという。SDLCの根幹をなすのは、情報システムを計画的に構造化された整然とした形で開発するには、アイデアの誕生から最終的なシステムの配備まで、適用するフレームワークの文脈の中で開発工程の各段階を着実に逐次的に実行しなければならないという考え方である。1960年代におけるこの方法論フレームワークの主な対象は、巨大企業の大規模ビジネスシステム開発だった。当時の情報システムは多大なデータ処理と数値処理を中心としたものだった。

 フレームワークとしてのSDM 
ソフトウェア開発方法論は、情報システムの開発工程を構造化し計画し制御するためのフレームワークであり、プロジェクトチームがアプリケーションの開発や保守のために作成・構築する成果物の事前定義なども含まれる。

そうしたフレームワークは長年の間に様々なものが考案されてきており、それぞれに長所と短所がある。あるソフトウェア開発方法論フレームワークは、すべてのプロジェクトに適しているわけではない。技術的・組織的などの面を考慮すると、それぞれの方法論フレームワークにはそれぞれ適した種類のプロジェクトがある。

そうしたソフトウェア開発フレームワークには、それをさらに発展させ、使用をサポートし、その方法論フレームワークの普及に努める組織が存在する。方法論フレームワークは、ある種の公式な文書で定義されることが多い。ソフトウェア開発方法論フレームワークの具体例としては、以下のものがある。

 ラショナル統一プロセス (RUP, IBM) - 1998年から
 (AUP) - 2005年、が構築

 個々のSDM 
SDMフレームワークを個々の組織やプロジェクトに適用する場合、具体的なソフトウェア開発方法論が使われる。年代順に次のようなものがある。

1970年代
 構造化プログラミング - 1969年から
 Cap Gemini SDM - オランダのPANDATAという企業で生まれた。英語圏にもたらされたのは1974年。この場合のSDMは System Development Methodology の略である。
1980年代
 SSADM (Structured systems analysis and design method) - 1980年から
 
1990年代
 オブジェクト指向プログラミング (OOP) - 1960年代初めからあったが、1990年代中ごろに主役に躍り出た。
 RAD - 1991年から
 (Dynamic systems development method) - 1994年から
 スクラム - 1995年から
 - 1998年から
 エクストリーム・プログラミング - 1999年から

 具体例 
どのソフトウェア開発方法論も特定のフレームワークをソフトウェアの開発・保守に適用する際の基盤となる。情報技術の生まれたころから、いくつかのソフトウェア開発手法が使われてきた。主なものを以下に挙げる。

 ウォーターフォール - 直線的なフレームワーク
 プロトタイピング - 反復的なフレームワーク
 インクリメンタル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
 スパイラル - 直線的な要素と反復的な要素を組み合わせたフレームワーク
 RAD - 反復的なフレームワーク
 エクストリームプログラミング

 ウォーターフォール 
ウォーターフォール・モデルは逐次的な開発手法であり、要求分析・設計・実装・テスト（評価）・統合・保守と、水が低いところに流れていくように上流工程から下流工程へと順次移行していく。この手法を最初に定式化したのはの1970年の論文とされているが、ロイス自身は「ウォーターフォール」という用語をこの論文で使ってはいない。

基本原則は次の通り。
 プロジェクトは逐次的な工程に分けられ、工程間の若干の重なりと戻りは許容される。
 計画、スケジュール、日程、予算などを重視し、システム全体を一度に実装することを特徴とする。
 様々な文書を作成し、公式なレビューを行い、ある工程から次の工程へ移行する際にはユーザーまたはIT管理者による承認を必要とする。

ウォーターフォール・モデルは従来からの工学的手法をソフトウェア工学にそのまま適用したものである。大規模なプロジェクトで採用され、予算超過、納期遅延、要求仕様を満たさないものを生み出すなどして非難されてきた。契約条件にされた場合を除き、ウォーターフォール・モデルよりも柔軟な手法を採用することが多くなっている。

 プロトタイピング 
ソフトウェアプロトタイピングは、開発すべきソフトウェアの不完全なバージョンであるプロトタイプを（何度か）開発中に作成する開発手法である。

基本原則は次の通り。
 単独で使える完備した開発方法論ではなく、他の開発方法論に加えて使用される。
 大型プロジェクトにつきもののリスクを低減させるため、プロジェクトを小さな部分に分割し、開発中の修正を容易にする手段を提供する。
 プロトタイプはユーザーに提示するものであり、ユーザーが開発プロセスに長期的に関与することになる。そのため、最終的な実装をユーザーが受容しやすくなる。
 プロトタイプに反復的に修正を加えていき、ユーザーの要求を満たすようにしていく。
 プロトタイプは最終的に捨てられることが多いが、最終的なシステムがプロトタイプを発展させることで作られることもある。
 プロトタイピングにより、開発者とユーザー間の根本的な誤解を早期に解決することができる。

 反復型 
反復型開発はプロジェクトを小さな部分に分割し、開発工程中の修正を容易にし、プロジェクトのリスクを低減させる。

基本原則は次の通り。
 ウォーターフォールを小規模に何度も繰り返す。一回のウォーターフォールはシステム内の小さな部分を完成させるものである。
 全体の要求仕様は反復を行う前に定義される。

 スパイラル 

スパイラルモデルはトップダウン設計とボトムアップ設計のそれぞれの利点を生かしたもので、設計とプロトタイピングの工程を繰り返す手法である。これは一種のメタモデルで、他のモデルが利用することができる。

基本原則は次の通り。
 プロジェクトのリスクを最小化することを主眼としており、小さな部分に分割して開発工程での修正を容易にし、リスクの再評価の機会を提供し、プロジェクト継続の検討を可能にする。
 各サイクルは同じ一連の工程からなり、製品全体の概念を個々のプログラムのコーディングにまで落とし込み、一回のサイクルで1つの部分を完成させたり、全体の改良を施したりする。
 1つのサイクルは、 その反復の目的・選択肢・制約の決定、 選択肢の評価、リスクの識別と解決、 具体的な開発とそのサイクルの成果物の評価、 次の反復の計画立案、という4つに分けられる。
 各サイクルは利害関係者と彼らの勝利条件の識別で始まり、レビューとコミットメントで終わる。

 RAD 
RAD (Rapid Application Development) は、プロトタイプを反復的に開発・構築していくソフトウェア開発方法論である。本来は、1991年にが提唱したソフトウェア開発工程を指した言葉である。

基本原則は次の通り。
 高品質なシステムを相対的に低いコストで素早く開発することを目標とする。
 プロジェクトにつきもののリスクを低減させるため、小さい部分に分割し、開発中の修正を容易にする。
 高品質なシステムを素早く生み出すため、反復的プロトタイピングを行い、ユーザーに活発に関与させ、高度な開発ツールを利用する。ツールとしては例えば、GUIビルダー、CASEツール、データベース、第四世代言語 (4GL)、コードジェネレータ、オブジェクト指向のテクニックなどを活用する。
 ビジネスのニーズを満たすことに主眼を置き、技術的に洗練されているかはあまり重視しない（自動生成したコードは一般に洗練されていない）。
 開発すべき機能群を優先順位付けし、いくつかの機能ごとに納期を定める。プロジェクトが遅延してきたら、納期は順延させず、実装する機能を減らす。
 一般に JAD を含む。JADはユーザーがシステム設計に積極的に関与する手法であり、ユーザーの要望を反映させやすい。
 プロトタイプを捨てることはなく、製品を反復的に改良していくと考える。
 将来の開発や保守で役立つ文書を作成する。
 標準的なシステム分析・設計技法をこのフレームワークに導入可能である。