http://www.huihoo.com/development/fdd.html

功能驅動開發模式FDD

FDD（Feature-Driven Development）是由Peter Coad、Jeff de Luca 、Eric Lefebvre共同開發的一套針對中小型軟件開發項目的開發模式。

FDD是一個模型驅動的快速迭代開發過程，它強調的是簡化、實用、 易于被開發團隊接受，適用于需求經常變動的項目。簡單地說，FDD“是一個以Architecture為中心的，采用短迭代期，目期驅動的開發過程。它首先對整個項目建立起一個整體的模型，然后通過兩周一次‘設計功能-實現功能’的迭代完成項目開發”。此處的“功能”是指“用戶眼中最小的有用的功能”，它是可理解的、可度量的，并且可以在有限的時間內（兩周）實現。在開發過程中，開發計劃的制定、報告的生成、開發進度的跟蹤均是以上述“功能”為單位進行的。在FDD中，它認為：只有良好定義的并且簡單的過程才能被很好地執行。另外，由于在FDD中采用了短周期的迭代，最小化的功能劃分法，所以可以對項目的開發進程進行精確及時地監控。

FDD的使用需要有相應工具的支持，Peter Coad等人開發出了一套擴展的UML（FDD UML Extensions），并在Together中實現有關的功能，詳細內容可參見后文。

在FDD中，存在“主要功能集”、“功能集”、“功能”等概念，它們之間的關系及示例如下所示：

主要功能集 = 功能集1 + 功能集2 + …

功能集 = 功能1 + 功能2 + …

其中，主要功能集是在初始階段根據用戶的需求所制定出來的比較粗的，有待于細化的對開發項目所需要功能的描述；功能是在開發過程細化的結果，在每個迭代期中需要實現若一干個功能，這些功能的集合被稱之為功能集。

在FDD中，它將開發過程劃分為如下五個階段：

l         制定整體的模型

l         根據優先級列出功能的詳細列表

l         依據功能制定計劃

l         依據功能進行設計

l         實現功能

每個階段的定義又是通過被稱之為：ETVX的方法從下面四個方面加以描述的：

l         Entry：Specify clear and well defined entry criteria for the process；

l         Task：列出所有要實現的任務列表，名稱，是否需要實現，任務描述；

l         Verification：；制定對過程結果的評批標準；

l         eXit：過程結束時所需的結果；

FDD過程示意圖

在FDD中主要存在三類人員：主要開發人員、類的所有者、功能團隊，它們各自的含義如下：

l         主要開發人員：用于領導其它開發人員進行DBF/BBF的開發，對開發工作進行監督（例如對設計及代碼進行審查）。主要開發人員的數量由項目整體的大小所決定，如果需要加快開發進度則可以再培養新的主要開發人員。與其它開發人員相比，主要開發人員具有更高的開發效率。Fred Brooks在幾十年前就提出了：增加開發人員數量只會降低開發效率。但對于小型的，以用戶功能驅動的輕量及的開發過程此原則并不適用。在此過程中采用增加人員的方法可以提高開發的并行效率。

l         類的所有者：一個類有且只有一個所有者，即一個類只能由一名開發人員進行設計及編碼。采用這種方式是十分有效的，因為開發人員會感覺他擁有了部分屬于自已的代碼，他會以此為榮；此外，它還可以保證相關代碼的一致性。如果此類中包含有復雜的算法，那么可以再增加一名專門負責算法的開發人員。雖然FDD是面向用戶功能的，而不是面向類的，但用戶最終關心的是那些他們需的功能，而并不關心在開發時采用何種框架模式，所以在此以類為單位進行人員分配與開發的宗旨并不矛盾。

l         功能團隊：開發時功能會被分配給主要開發人員，再由主要開發人員根據實現此功能所需類的所有關系找到有關的開發人員從而構成一個臨時的（最多兩周）的團隊。一名開發人員可以同時負責多個類的開發工作，即他可以在同一時刻處于多個功能團隊中。因此在每個DBF/BBF中功能團隊的人員均可能發生變化。在此團隊中主要開發人員處于核心地位，團隊內部的交流也是經及為中心的。采用這種方法可以加速開發進度，并且主要開發人員還可以對過程進行必要的監控，保證設計與實現的一致性。從更高的角度來看，主要的系統設計師又負責監控各功能團隊中的主要開發人員。

采用FDD方式進行開發時，各階段時間的分配關系大致如下所示：

l         Develop an overall model                     10% initial, 4% on-going

l         Build a features list                             4% initial, 1% on-going

l         Plan by feature                                          2% initial, 2% on-going

l         Design by feature, build by feature              77%（兩周一個迭代期）

DBF/BBF中各階段時間分配關系：

l         DBF

2        Walk through the domain              1%

2        Design                                40%

2        Inspect the design                3%

l         BBF

2        Code/test                             45%

2        Inspect the code                   10%

2        Promote to build                   1%

需要注意的是：上述Coding的過程中還包含有單元測試的內容。此外單從DBF/BBF的過程來看，設計所有的時間要比編碼的時間長（40% : 45%），但考慮到FDD的整個實施過程（包括前期的建模過程），設計的時間還是比編碼的時間要長的（45% : 35%）。

在FDD中另一個重要的，并且也是十分有特色的部分就是它的報告功能。每周Release經理要召開一次會議，會議一般限定于30分鐘以內，在會上每個主要的開發人員全面地介紹其所做的工作，并標識出相應的項目狀態圖。通過這種口頭上的交流，可以確保各主要開發人員能對項目的其它部分有一個充分的了解。會后，Release經理還要根據有關內容更新數據庫中的信息并生成相應的報告，這個報告將發送給項目團隊、用戶以及主要的管理人員。

為跟蹤項目開發狀態需要使用數據庫對有關內容加以保存，在數據庫中應保存如下信息：

l         類型（問題域、人的交互活動、系統交互活動）

l         標識（功能集前綴+序列號）

l         狀態（正在處理、不再需要、正常）

l         主要功能集

l         功能集

l         文檔引用信息

l         活動事件

l         主要開發人員

l         問題域分析時的計劃日期，實際日期

l         設計時的計劃日期，實際日期

l         設計復查時的計劃日期，實際日期

l         編碼時的計劃日期，實際日期

l         編碼復查時的計劃日期，實際日期

l         提交構造時的計劃日期，實際日期

l         備注

項目計劃表

功能詳細列表

另外，有關類及類的所有者的信息保存在其它的表中。根據數據庫可自動生成有關報告。

項目已完成功能統計表

FDD中擴展的UML

FDD 過程 #1: 開發總體模型

Entry Criteria:

客戶已準備好建立一個系統。他已經有采用某種形式保存的需求列表。此時用戶可能還不能完全分清楚什么是他“必面要的”，什么是他“想要的，最好有的”，但這沒有關系。

Tasks:

Verification:

Exit:

結束過程時，團隊必須提交如下內容，并且這些內容已經過開發經理以及系統設計師的審閱及批準：

-          類圖，包括：類、類間關系、類的函數以及屬性。類及類間關系建立起了模型的大致輪廓。根據最初的功能有列表以及非正式的序列圖而來的函數展現出系統的功能，并且是后續開發過程中建立詳細功能列表的前提。此外還應有非正式的序列圖。

-          非正式的功能列表。

-          其它可供選擇的模型信息。

FDD 過程 #2: 創建功能列表

在此階段，團隊標識出所有的功能，對其加以分組，為其設定優先級，并設置相應的權重。

在下面的活動中，小組工作的重點在于功能，因此領域專家可以不再需要。

Entry Criteria:

建模團隊已成功地完成了FDD第一階段的工作，開發出了系統的整體模型。

Tasks:

Verification:

Exit Criteria:

    本階段結束時，詳細的功能列表必需已經產生了，并且將功能進行分組形成主功能集以及功能集，此外這些內容已經過開發經理以及系統設計師的審閱及批準。

FDD 過程 #3: 根據功能制定計劃

根據已制定的層次化的、具有優先級以及權重的功能列表，項目經理、開發經理以及主要開發人員一起制定出DBF/BBF階段的里程碑。

Entry Criteria:

功能列表團隊已成功地完成了FDD第二階段的工作，并已形成詳細的功能列表。

Tasks:

Verification:

Exit Criteria:

本階段結束時，開發計劃已經產生了，并且這些內容已經過開發經理以及主要設計師的審閱及批準。計劃中應包括以下內容：

-          一個整體的開發日期

-          針對每個主要功能集、功能集、功能指定有關負責人（CP）以及完成時間

-          針對每個類，指定負責其完成的開發人

注意：

    為便于為功能設置優先級，可以創建一個稱之為FFB（待實現功能板）。

FDD 過程 #4: 根據功能進行設計（DBF）

根據已制定的層次化的、具有優先級以及權重的功能列表，項目經理、開發經理以及主要開發人員一起制定出DBF/BBF階段的里程碑。

Entry Criteria:

計劃制定團隊已成功地完成了FDD第三階段的工作。

Tasks:

Verification:

Exit Criteria:

本階段結束時，應已完成如下工作，并且這些工作已經過主要設計師的審閱及批準。計劃中應包括以下內容：

-          功能及其相關參考資料（如果有的話）

-          詳細的序列圖

-          更新后的類圖

-          更新后的類及其方法原型

-          開發團隊認為有價值的其它實現方案

FDD 過程 #5: 根據功能進行設計（BBF）

在DBF工作的基礎上，每個類的實現者完成類的各個方法。此外他還需完善基于類的測試方案并實現類一級的單元測試。根據主要開發人員的意見，功能實現團隊可能還需在進行單元測試之前先進行源代碼檢查。當代碼編寫并檢查后開發人員就將其放入配置管理系統中。在所有的類均已完成并Check-In之后，主要開發人員將代碼提升以便進行構造。

Entry Criteria:

功能實現團隊已成功地完成了FDD第四階段的工作。

Tasks:

Verification:

Exit Criteria:

本階段結束時，應已完成如下工作，并且這些工作已經過主要設計師的審閱及批準。計劃中應包括以下內容：

-          實現了類的方法并對代碼進行了檢查和單元測試

-          按順序針對每個類的方法的單元測試記錄

-          類已被開發人員Check-In，主要開發人員已提升代碼進行構造并同步更新功能狀態。