動的システム開発手法
動的システム開発手法（DSDM）は、技術ではなくビジネスの視点で考える人たちによって1990年代の後半に英国で開発されました。DSDMは今ではDSDMコンソーシアムによって管理されており、おそらく英国で実施されている最も人気の高いアジャイル開発技法でしょう。DSDMは技術的にはフレームワークと見なされます。このフレームワークのバージョン管理（およびリリースの管理）はコンソーシアムによって行われています。
DSDMは重量級のアジャイルアプローチの1つです。もともとは高速アプリケーション開発（Rapid Application Development：RAD）の拡張として開発されたもので、ビジネス指向の創始者のベストプラクティスを組み入れています。
DSDMプロジェクトは3つのフェーズから成ります（図3も参照）。
- プリプロジェクト ― プロジェクトの開始前に行われるべきものです。
- プロジェクトライフサイクル ― 実際のプロジェクトが行われます。このフェーズは5つのステージに分けられます。
- 実現可能性調査
- ビジネス調査
- 機能モデルイテレーション
- 設計と構築イテレーション
- 実装
- ポストプロジェクトフェーズ ― プロジェクトの終了後に行われるべきものです。
DSDMには次のような9つの原則があります。
- 積極的なユーザー関与が絶対に必要である。
- チームに引き渡しの権限が与えられなければならない。
- 頻繁な引き渡しが鍵である。
- 受け入れの主たる条件は現在のビジネスニーズを満たす機能の引き渡しである。
- 反復的で漸増的な引き渡しが不可欠である。
- プロジェクトライフサイクル中に行われた変更はすべて元に戻せる。
- 要件は高いレベルで基準化される。
- プロジェクトライフサイクル全体で統合されたテストが期待される。
- すべての利害関係者間の協力が不可欠である。
DSDMのルーツはビジネスにあるため、DSDMが予算内で期日どおりに機能を引き渡すことを重視しても不思議はないでしょう。これを達成するため、各プロジェクトがいくつかのチャンクに分割され、それぞれのチャンクには、ある決まった数の機能と予算と時間が割り当てられます。時間と予算は両方とも固定されているので、プロジェクトが時間または予算をオーバーしそうになった場合は、最も重要性の低い機能が削られ、将来のプロジェクトに先送りされます。機能（要件）の優先度は次のルールによって決められます。
- 必ず実現しなければならない要件（MUST）
- 可能な限り実現すべき要件（SHOULD）
- 引き渡しに大きな影響が出なければ実現した方が良い要件（COULD）
- 十分な時間が残っていれば実現したい要件（WOULD）
MUST、SHOULD、COULD、WOULDは一般にMoSCoWという頭字語で表されます。
DSDMでは、要件に対するユーザーフィードバックは非常に重要で、プロジェクトフェーズの早期に作成されるプロトタイプで大きな意味を持つとされています。これらは要件を精緻化し、すべての利害関係者の期待を明確化するために使われます。
DSDMはプロジェクトチームが使用すべきテストアプローチを指定しませんが、プロジェクトライフサイクルフェーズ全体にわたってテストを実行するように求めています。ライフサイクルのすべての面にテスト担当者が関与して、テストの機会が最大化されるようにしなければなりません。
プロジェクトの要件と機能について議論するためのフォーラムを利害関係者に提供するため、ワークショップが使用されます。こうしたワークショップは必要に応じて何度でも実施できます。モデリングはワークショップに似ていますが、システムの技術的な部分や、ビジネスドメインのようなビジュアルモデルが効果的な他の部分を生み出したり伝達したりするために、技術チームメンバによって実施されます。
DSDMでは固定的なコントロールを行うため、プロジェクトのさまざまな面を制御するコンフィグレーション管理システムが必要になります。
DSDMはプロジェクト規模の上限を、それぞれが6人のメンバから成る6つのチームに設定しているように見えます。チームの人数がもっと多い場合もあるかもしれませんが、そうした事例を裏付けるようなドキュメントを見つけることはできませんでした。DSDMはビジネス的なベストプラクティスの上に築かれたので、生命維持装置、有毒廃棄物管理、原子炉といった、安全が重視されるシステムに使用するのは望ましくありません。この点には注意すべきです。
