機能駆動開発

フィーチャー駆動開発（FDD）は、反復的かつ増分的なソフトウェア開発プロセスです。これは、軽量またはアジャイルなソフトウェア開発手法です。FDDは、複数のベストプラクティスを統合的に統合します。これらのプラクティスは、クライアントが重視する機能（フィーチャ）を提供するという観点から推進されます。 [ 1 ]その主な目的は、アジャイル宣言の原則に従って、実体のある動作するソフトウェアをタイムリーに繰り返し提供することです。[ 2 ]

歴史

FDDは、1997年にジェフ・デ・ルカ氏によって、シンガポールの大手銀行で15ヶ月間、50名規模のソフトウェア開発プロジェクトに特有のニーズを満たすために考案されました。その結果、全体モデルの開発、機能のリスト化、計画、設計、構築をカバーする5つのプロセスが生まれました。最初のプロセスは、ピーター・コード氏のオブジェクトモデリングへのアプローチに大きく影響を受けています。2番目のプロセスは、機能要件と開発タスクを管理するために機能リストを使用するというコード氏のアイデアを取り入れています。その他のプロセスは、ジェフ・デ・ルカ氏の経験に基づいています。シンガポールのプロジェクトで成功を収めて以来、FDDはいくつかの実装が行われてきました。

FDDの説明は、1999年にピーター・コード、エリック・ルフェーブル、ジェフ・デ・ルカの共著『 Java modelling in Color with UML』[1]の第6章で初めて世界に紹介されました。その後、スティーブン・パーマーとマック・フェルシングの共著『A Practical Guide to Feature-Driven Development』[2]（2002年出版）で、Javaモデリングから切り離された、より一般的なFDDの説明が示されました。

概要

FDDは、5つの基本アクティビティで構成される、モデル駆動型の短期反復プロセスです。ソフトウェア開発プロジェクトの正確な状態報告と進捗状況の追跡のために、各機能の進捗を示すマイルストーンが定義されます。このセクションでは、各アクティビティの概要を説明します。右の図は、これらのアクティビティのメタプロセスモデルを示しています。最初の2つの連続アクティビティで、全体的なモデル形状が確立されます。最後の3つのアクティビティは、各機能ごとに 反復されます。

FDDのプロセスモデル

全体モデルの開発

FDDプロジェクトは、システムの範囲とそのコンテキストを概観することから始まります。次に、各モデリング領域について、小グループが詳細なドメインモデルを作成し、ピアレビューに提出します。提案されたモデルの中から1つまたは複数のモデルが選定され、各ドメイン領域のモデルとなります。ドメイン領域のモデルは、段階的に全体モデルに統合されます。

ビルド機能リスト

初期モデリングで得られた知識は、ドメインを機能的にサブジェクトエリアに分解することで、機能リストを特定するために活用されます。各サブジェクトエリアにはビジネスアクティビティが含まれており、各ビジネスアクティビティ内のステップが分類された機能リストの基礎となります。ここでいう機能とは、クライアントにとって価値のある機能の小さな構成要素であり、「<アクション> <結果> <オブジェクト>」の形式で表現されます。例えば、「売上合計を計算する」や「ユーザーのパスワードを検証する」といった具合です。機能の完成には2週間以上かかるべきではなく、それ以上かかる場合はさらに小さな構成要素に分割する必要があります。

機能別に計画する

機能リストが完成したら、次のステップは開発計画を作成し、機能 (または機能セット) の所有権をクラスとしてプログラマーに割り当てることです。

機能別デザイン

各機能ごとに設計パッケージが作成されます。チーフプログラマーは、2週間以内に開発する機能の小グループを選択します。チーフプログラマーは、対応するクラスオーナーと協力して、各機能の詳細なシーケンス図を作成し、全体的なモデルを洗練させます。次に、クラスとメソッドのプロローグが記述され、最後に設計検査が行われます。

機能別に構築

機能を作成するための各アクティビティの設計検査が計画通りに完了すると、クラスオーナーは担当クラスのコードを開発します。ユニットテストとコード検査が合格すると、完成した機能はメインビルドに昇格されます。

マイルストーン

機能は小さいため、1つの機能を完了するのは比較的小規模なタスクです。ソフトウェア開発プロジェクトの正確な状態報告と追跡のためには、各機能の進捗状況を記録することが重要です。そのため、FDDでは、機能ごとに6つのマイルストーンを定義し、それらを順番に完了させます。最初の3つのマイルストーンは「機能別設計」アクティビティで完了し、最後の3つのマイルストーンは「機能別構築」アクティビティで完了します。進捗状況を追跡するために、各マイルストーンには完了率が割り当てられています。下の表に、マイルストーンとその完了率を示します。コーディング開始時点で、機能は既に44%完了しています（ドメインウォークスルー1%、設計40%、設計検査3% = 44%）。

表1: マイルストーン
ドメインウォークスルー デザイン 設計検査 コード コード検査 ビルドに昇格
1% 40% 3% 45% 10% 1%

ベストプラクティス

機能主導型開発は、クライアントが重視する機能の観点を目的とした ソフトウェア エンジニアリングのベストプラクティスの中核セットに基づいて構築されます。

  • ドメインオブジェクトモデリング。ドメインオブジェクトモデリングは、解決すべき問題のドメインを探索し、説明することから成ります。結果として得られるドメインオブジェクトモデルは、機能を追加するための全体的な枠組みを提供します。
  • 機能ごとに開発する。2週間以内に実装するには複雑すぎる機能は、さらに小さな機能に分解され、それぞれのサブ問題が機能と呼べるほど小さくなるまで細分化されます。これにより、正しい機能を提供し、システムを拡張または変更することが容易になります。
  • 個別クラス所有権（コード所有権）。個別クラス所有権とは、個別のコード部分またはコードグループが単一の所有者に割り当てられることを意味します。所有者は、クラスの一貫性、パフォーマンス、および概念的な整合性に責任を負います。
  • フィーチャーチーム。フィーチャーチームは、小規模でダイナミックに編成されたチームであり、小規模な活動を展開します。各設計上の決定には常に複数の視点が反映され、複数の設計オプションが評価された上で、最終的に1つが選択されます。
  • 検査。検査は、主に欠陥の検出によって、設計とコードの品質を保証するために実行されます。
  • 構成管理。構成管理は、現在までに完了したすべての機能のソース コードを識別し、機能チームがクラスを強化する際にクラスへの変更履歴を維持するのに役立ちます。
  • 定期的なビルド。定期的なビルドにより、常に最新のシステムがクライアントに提示され、機能のソースコードの統合エラーを早期に発見できるようになります。
  • 進捗と結果の可視性。マネージャーは、完了した作業に基づいて、プロジェクト内外のすべてのレベルから頻繁かつ適切で正確な進捗レポートを使用してプロジェクトを指揮します。

メタモデル（メタモデリング）

FDDのプロセスデータモデル

メタモデリングは、メソッドのプロセスとデータの両方を視覚化するのに役立ちます。これにより、メソッドの比較が可能になり、メソッドエンジニアリングプロセスにおけるメソッドの断片を容易に再利用できるようになります。この手法の使用は、UML標準に準拠しています。

メタデータモデルの左側には、FDDを用いたソフトウェア開発プロジェクトに含まれる5つの基本アクティビティが示されています。これらのアクティビティはすべて、FDDプロセス記述のサブアクティビティに対応するサブアクティビティを含んでいます。モデルの右側には、関連する概念が示されています。これらの概念は、図の左側に示されたアクティビティから派生しています。

参照

参考文献

  1. ^ Cadle, James; Ahmed, Tahir; BCS, The Chartered Institute for IT 編 (2014). 『情報システムの開発：ITプロフェッショナルのための実践的ガイダンス』ロンドン: BCS, The Chartered Institute for IT. p. 99. ISBN 978-1-78017-245-3。
  2. ^ 「アジャイル宣言の背後にある原則」 2019年6月11日。
「 https://en.wikipedia.org/w/index.php?title=Feature-driven_development&oldid=1316374257」より取得