機能駆動開発

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

機能駆動開発FDD)は、反復型の増分 ソフトウェア開発プロセスです。軽量です誰によると?]またはソフトウェアを開発するためのアジャイル手法FDDは、業界で認められている多くの[誰によると?]まとまりのある全体へのベストプラクティス。これらのプラクティスは、クライアントが重視する機能(機能)の観点から推進されています[説明が必要]その主な目的[誰によると?] アジャイルマニフェストの背後にある原則に従って、具体的で機能するソフトウェアをタイムリーに繰り返し提供することです。[1]

歴史

FDDは当初、1997年にシンガポールの大手銀行で行われた15か月の50人のソフトウェア開発プロジェクトの特定のニーズを満たすためにJeff De Lucaによって考案されました。これにより、モデル全体の開発をカバーする5つのプロセスのセットが作成されました。機能のリスト、計画、設計、および構築。最初のプロセスは、 PeterCoadのオブジェクトモデリングへのアプローチに大きく影響されます2番目のプロセスには、機能リストを使用して機能要件と開発タスクを管理するというCoadのアイデアが組み込まれています。他のプロセスは、JeffDeLucaの経験の結果です。シンガポールプロジェクトでのFDDの使用が成功して以来、FDDの実装はいくつかあります。

FDDの説明は、1999年にPeter Coad、Eric Lefebvre 、およびJeffDeLucaによって著書「JavamodelinginColor with UML [1]」の第6章で最初に世界に紹介されました。その後、StephenPalmerとMacFelsingの本で紹介されました。機能駆動開発の実用ガイド[2](2002年に発行)では、FDDのより一般的な説明がJavaモデリングから切り離されて提供されました。

概要

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

FDDのプロセスモデル

全体的なモデルを開発する

FDDプロジェクトは、システムのスコープとそのコンテキストの高レベルのウォークスルーから始まります。次に、詳細なドメインモデルが小グループによってモデリング領域ごとに作成され、ピアレビューのために提示されます。提案されたモデルの1つ以上が、各ドメイン領域のモデルになるように選択されます。ドメインエリアモデルは、モデル全体に​​段階的に統合されます。

機能リストの作成

初期モデリング中に収集された知識は、ドメインをサブジェクト領域に機能的に分解することにより、機能のリストを識別するために使用されます。サブジェクトエリアにはそれぞれビジネスアクティビティが含まれ、各ビジネスアクティビティ内のステップは、分類された機能リストの基礎を形成します。この点での機能は、「<action> <result> <object>」の形式で表されるクライアント値関数の小さな断片です。たとえば、「販売の合計を計算する」または「ユーザーのパスワードを検証する」です。機能が完了するまでに2週間以上かかることはありません。そうでない場合は、機能を細かく分割する必要があります。

機能ごとに計画する

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

機能別のデザイン

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

機能ごとに構築

機能を作成するための各アクティビティの設計検査が成功するように計画された後、クラスの所有者はクラスのコードを開発します。単体テストとコード検査の成功、完成した機能はメインビルドにプロモートされます。

マイルストーン

機能が小さいため、機能を完了するのは比較的小さな作業です。正確な状態レポートを作成し、ソフトウェア開発プロジェクトを追跡するには、各機能の進捗状況をマークすることが重要です。したがって、FDDは、順次完了する機能ごとに6つのマイルストーンを定義します。最初の3つのマイルストーンは、機能別の設計アクティビティ中に完了し、最後の3つのマイルストーンは、機能別のビルドアクティビティ中に完了します。進捗状況を追跡するために、完了率が各マイルストーンに割り当てられます。以下の表に、マイルストーンとその完了率を示します。コーディングが開始された時点で、機能はすでに44%完了しています(ドメインウォークスルー1%、設計40%、設計検査3%= 44%)。

表1:マイルストーン
ドメインウォークスルー デザイン 設計検査 コード コード検査 構築を促進する
1% 40% 3% 45% 10% 1%

ベストプラクティス

機能駆動開発は、クライアント価値のある機能の観点を目的とした ソフトウェアエンジニアリング のベストプラクティスのコアセットに基づいて構築されています。

  • ドメインオブジェクトモデリングドメインオブジェクトモデリングは、解決すべき問題のドメインを調査して説明することで構成されます。結果として得られるドメインオブジェクトモデルは、機能を追加するための全体的なフレームワークを提供します。
  • 機能による開発複雑すぎて2週間以内に実装できない関数は、各サブ問題が機能と呼ばれるほど小さくなるまで、さらに小さな関数に分解されます。これにより、正しい機能を提供し、システムを拡張または変更することが容易になります。
  • 個々のクラス(コード)の所有権個々のクラスの所有権とは、コードの個別の部分またはグループが単一の所有者に割り当てられることを意味します。所有者は、クラスの一貫性、パフォーマンス、および概念の整合性に責任があります。
  • 機能チーム機能チームは、小さなアクティビティを開発する、動的に形成された小さなチームです。各設計決定には常に複数の考え方が適用され、1つが選択される前に複数の設計オプションが評価されます。
  • 検査検査は、主に欠陥の検出によって、高品質の設計とコードを保証するために実行されます。
  • 構成管理構成管理は、これまでに完了したすべての機能のソースコードを識別し、機能チームがクラスを強化するときにクラスへの変更の履歴を維持するのに役立ちます。
  • 通常のビルド定期的なビルドにより、クライアントにデモンストレーションできる最新のシステムが常に存在し、機能のソースコードの統合エラーを早期に明らかにするのに役立ちます。
  • 進捗状況と結果の可視性管理者は、完了した作業に基づいて、プロジェクト内外のすべてのレベルからの頻繁で適切かつ正確な進捗レポートを使用してプロジェクトを操縦します。

メタモデル(メタモデリング)

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

メタモデリングは、メソッドのプロセスとデータの両方を視覚化するのに役立ちますこれにより、メソッドを比較でき、メソッドエンジニアリングプロセスのメソッドフラグメントを簡単に再利用できます。この手法の使用法は、 UML標準 と一致しています。

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

も参照してください

参照

  1. ^ 「アジャイルマニフェストの背後にある原則」2019-06-11。
  • 1. ^ Coad、P.Lefebvre、E.De Luca、J.(1999)UMLを使用したカラーのJavaモデリング:エンタープライズコンポーネントとプロセスプレンティスホールインターナショナル。ISBN 0-13-011510-X 
  • 2. ^ Palmer、SR、およびFelsing、JM(2002)。機能駆動開発の実用ガイドプレンティスホール。ISBN 0-13-067615-2 

外部リンク