ユーザー機能駆動開発(FDD)とは
ユーザー機能駆動開発(Feature Driven Development, FDD)は、
アジャイルソフトウェア開発手法の一つであり、反復型の開発プロセスを採用しています。顧客にとっての機能価値(feature)を開発の軸とし、業界の
ベストプラクティスを組み合わせた手法です。主な目的は、実際に動作する
ソフトウェアを適切な間隔で繰り返し提供することにあります。
歴史
FDDは、1997年にジェフ・デ・ルーカが
シンガポールの銀行向け
ソフトウェア開発プロジェクトにおいて、50人規模の開発チームで15ヶ月間のプロジェクトを成功させるために必要に迫られて考案されました。ジェフ・デ・ルーカは、開発プロセスを5つの段階に分け、全体モデルの開発、機能リストの作成、計画、設計、構築という手順を設定しました。最初のプロセスは、ピーター・コードのオブジェクトモデリング技法の影響を大きく受けています。2番目のプロセスでは、ピーター・コードの機能リストの考え方を採用し、機能要件仕様と開発作業の管理に役立てています。
FDDが世界的に知られるようになったのは、1999年に出版されたピーター・コード、エリック・レイフェイブル、ジェフ・デ・ルーカの共著「Java Modeling in Color with UML」で紹介されたのが最初です。その後、2002年にスティーブン・パルマーとマック・フェルシングによって出版された「A Practical Guide to Feature-Driven Development」では、Javaから切り離された手法としてFDDがより詳しく解説されています。
ジェフ・デ・ルーカの
ウェブサイトには、オリジナルのFDDプロセスに関する記事や、FDDコミュニティの
ウェブサイトへのリンクがあります。
概要
FDDは、モデル駆動型の短期反復型開発プロセスであり、5つの基本的な活動から構成されています。
ソフトウェア開発プロジェクトの正確な状況報告と監視のために、各機能(feature)の進捗状況を示すマイルストーンが定義されています。
FDDの5つの活動
FDDの
ソフトウェア開発プロセスは、以下の5つの基本活動で構成されています。最初の3つの活動は、全体モデルを形成するためのもので、残りの2つの活動は、機能ごとに反復的に実施されます。
1.
全体モデル開発: プロジェクトは、システムの範囲と内容に関するハイレベルなウォークスルーから開始されます。次に、各モデリング分野で詳細なウォークスルーが行われます。これらのウォークスルーによって作成された複数のモデルから、最適なモデルを選び、全体モデルとして結合し、調整を行います。
2.
機能リスト構築: 初期モデリングで得られた知識を基に、機能(feature)のリストを作成します。このリストは、顧客が重要と考える領域ごとに分類され、各ビジネス活動に対応するステップ群が含まれます。機能(feature)は、顧客にとって価値を生む最小の機能単位であり、「<アクション> <結果> <オブジェクト>」の形式で表現されます。例えば、「売り上げの合計を計算する」や「ユーザーのパスワードを検証する」などです。2週間以上かかる機能は、さらに分割する必要があります。
3.
機能ごとの計画: 機能リストが完成したら、次に開発計画を立てます。各機能をクラスに割り当て、そのクラスを担当する
プログラマー(オーナー)を決定します。
4.
機能ごとの設計: 各機能の設計パッケージを作成します。オーナーは、2週間以内に開発すべき機能を選択し、関連するクラスのオーナーと共同で、機能の詳細なシーケンス図を作成し、全体モデルを更新します。次に、クラスとメソッドのプロローグを記述し、設計インスペクションを行います。
5.
機能ごとの構築: 設計インスペクションが完了したら、機能を実現するコードを記述します。単体テストとコードインスペクションが完了すると、その機能はメインのビルド環境に追加されます。
マイルストーン
FDDでは、各機能の進捗状況を把握するために、6つのマイルストーンが定義されています。最初の3つのマイルストーンは、機能ごとの設計活動に対応し、残りの3つは機能ごとの構築活動に対応しています。各マイルストーンには進捗率が設定されており、プロジェクトの進捗を監視するのに役立ちます。
マイルストーン | 進捗率 | 説明 |
---|
:------- | : | :---------------- |
ドメイン・ウォークスルー | 1% | 高レベルな機能の概要を把握し、システムの境界を定義する。 |
設計 | 40% | 各機能の詳細な設計を行い、クラスやインターフェースの設計を定義する。 |
設計インスペクション | 3% | 設計のレビューを行い、潜在的な問題点や改善点を見つける。 |
コード作成 | 44% | 設計に基づいて、実際にコードを作成する。 |
単体テスト | 10% | 作成したコードの単体テストを行い、各機能が正しく動作することを保証する。 |
コードインスペクション | 2% | 作成したコードのレビューを行い、コードの品質を保証する。 |
FDDは、
ソフトウェア工学の
ベストプラクティスに基づいています。これらのプラクティスは、顧客にとっての機能価値を中心に展開されます。以下は、FDDを構成する主な
ベストプラクティスです。
ドメイン・オブジェクト・モデリング: 解決すべき問題領域を詳細に分析し、機能を追加していくためのフレームワークを作成します。
機能ごとの開発: 2週間以内に実装できない機能は、より小さな部分機能に分割し、最終的に「feature」と呼ばれる小さな機能単位として扱います。これにより、バグの少ない実装が可能となり、システムの拡張や改善が容易になります。
クラスごとのオーナーシップ: 各クラスにはオーナーが設定され、クラスの一貫性、パフォーマンス、概念的な完全性に責任を持ちます。
機能チーム: 小規模で動的に編成されるチームで作業することで、個人や固定チームにありがちな独善的な開発を防ぎます。
インスペクション: 設計とコードの品質を保証するために、バグを早期に発見するためのインスペクションを行います。
構成管理: すべての機能のソースコードを管理し、変更履歴を維持します。
定期ビルド: 顧客に常に最新のシステムをデモンストレーションできるように、定期的なビルドを行います。
目に見える進捗と成果: プロジェクト内外に正確で頻繁な進捗報告を行うことで、プロジェクトの適切な管理を支援します。
ツール
FDDをサポートするためのツールとして、以下のようなものがあります。
FDD Project Manager Application
FDD Tools
FDD Viewer
注釈
詳細は、以下の出典をご参照ください。
関連項目
ソフトウェア工学
ソフトウェアアーキテクチャ
ソフトウェア開発プロセス
アジャイルソフトウェア開発
外部リンク
Feature Driven Development Community
Open Directory: Programming: Methodologies: Agile: Feature_Driven_Development
Nebulon FDD Page - ジェフ・デ・ルーカのコンサルティング会社
Successful Web Development Methodologies - FDDのウェブ開発プロジェクトでの利用
Delivering Real Business Value using Feature Driven Development - FDDの概要
FDD and Agile Modeling
Better Software Faster - Andy Carmichael and Dan Haywood, ISBN 0-13-008752-1