|
ユーザー機能駆動開発ユーザー機能駆動開発（ユーザーきのうくどうかいはつ、英: Feature Driven Development, FDD）は、反復的ソフトウェア開発工程の一種。アジャイルソフトウェア開発手法の1つでもある。FDD は業界におけるいくつかのベストプラクティスを混合したものである。それらは全て、顧客にとっての機能価値（feature）という観点で駆動される。その主な目的は、実際に動作するソフトウェアを繰り返し、適切な間隔で提供することである。 歴史FDDは、ジェフ デ・ルーカが1997年、シンガポールの大きな銀行向けのソフトウェア開発プロジェクト（50人で15か月）での必要性に応じて生み出したものであった。ジェフ デ・ルーカは、開発をカバーする5つのプロセスを設定した。それらは、全体モデルの開発と、機能のリストアップ、計画、設計、構築である。最初のプロセスは、ピーター・コードのオブジェクトモデル技法に大きな影響を受けている。2番目のプロセスは、機能的要求仕様と開発作業を管理するためのピーター・コード の機能リストの考え方を取り入れている。他のプロセスと全体としてのプロセスの統一性は、ジェフ デ・ルーカの経験に基づいている。シンガポールでのプロジェクトが成功して以来、FDDはいくつかのプロジェクトで使用されている。 FDDが世界的に知られるようになったのは、ピーター・コード、エリック・レイフェイブル、ジェフ デ・ルーカの1999年の著書Java Modeling in Color with UML(日本語訳『Javaエンタープライズ・コンポーネント—カラーUMLによるJavaモデリング』) [1] の第6章で紹介されたのが最初である。スティーブン・パルマーとマック・フェルシングの2002年の著書 A Practical Guide to Feature-Driven Development (日本語訳『アジャイル開発手法FDD—ユーザ機能駆動によるアジャイル開発』) [2] では、さらに詳しく Java とは切り離した手法として FDD が解説されている。 オリジナルと最近のFDDプロセスについては、ジェフ デ・ルーカ のウェブサイト[※ 1]の Article 配下にある。FDD に関するコミュニティ]のウェブサイト[※ 2]もある。 概要FDD は、5つの基本活動からなるモデル駆動型の短期反復方式の開発工程である。ソフトウェア開発プロジェクトの正確な状態報告と監視のために、各 feature についての進捗を示すマイルストーンが定義されている。以下ではそれら活動について概要を解説する。 活動FDD では、ソフトウェア開発工程を構成する5つの基本活動が存在する。最初の3つの逐次的な活動によって、全体モデルの形が決まる。その後の2つの活動は feature 毎に反復的に実施される。 全体モデル開発プロジェクトは、システムの範囲とその内容についての高レベルなウォークスルーから開始される。次に、部門毎の詳細なウォークスルーが、各モデリング分野ごとに行われる。各部門のサポートを受けて、複数のウォークスルーモデルが少人数で制作され、査読と議論のたたき台とされる。提案されたモデルのうちの1つまたは複数をまとめたものが、その特定の分野のモデルとして選択される。分野ごとのモデルが結合されて全体モデルとなり、全体モデルとしてその後調整が行われる。 feature リスト構築初期のモデリングで収集された知識は機能（feature）のリストアップに使われる。このとき、領域を顧客が重要と考えている点ごとに分類する。この分類された各点にはそれぞれ何らかのビジネス活動が含まれ、各ビジネス活動内のステップ群に feature リストが対応する。この観点での feature とは、顧客にとっての価値を生む小規模な機能単位であり、<action> <result> <object> という形式になっている。例えば、「売り上げの合計を計算する」(Calculate the total of a sale) あるいは「ユーザーのパスワードを検査する」(Validate the password of a user) などである。完成に2週間以上かかると予想される feature は、さらに分割すべきである。 feature 毎の計画feature リストが完成すると、次はその開発計画を立案する。feature をクラスに割り当て、各クラスに関して責任を持つプログラマ（オーナー）を決め、分担させる。 feature 毎の設計各 feature ごとの設計パッケージを作る。オーナーは2週間で開発すべき feature 群を選択する。関連するクラスのオーナーと共同で、feature ごとの詳細なシーケンス図を作成し、全体モデルを更新する。次に、クラスとメソッドのプロローグを書き、最後に設計インスペクションを行う。 feature 毎の構築feature ごとの設計インスペクションが完了したら、feature を実現するコードを書く。単体テストとコードインスペクションが完了したら、その feature はメインのビルド環境に入れられる。 マイルストーンfeature は小さいので、feature を1つ完成させるのは小さな作業である。ソフトウェア開発プロジェクトとしての進捗状況を監視して報告するには、それぞれの feature の進捗状況を全て把握する必要がある。そこで、FDD では feature ごとに6つのマイルストーンを定義し、それらが順次完了していく状況を監視する。最初の3つのマイルストーンはfeature 毎の設計活動のもので、残る3つはfeature 毎の構築活動のものである。進捗を把握する補助として、各マイルストーンに進捗率が設定されている。次の表にそれらマイルストーン（と進捗率）を示す。これによると、コード作成中の feature の進捗率は 44%（ドメイン・ウォークスルーが 1%、設計が 40%、設計インスペクションが 3% で、合計で 44%）である。
ベストプラクティスユーザー機能駆動開発は、ソフトウェア工学に基づいたベストプラクティスを中心として構築されている。それらプラクティスは、顧客にとっての機能価値（feature）の観点で駆動される。FDD が注目されるのは、それらプラクティスと技法の結合にある。FDD を構成するベストプラクティスを以下に簡単に列挙する。
ツール注釈出典
関連項目外部リンク
|
Portal di Ensiklopedia Dunia
