2.3現代模型：基於構件的開發模型、統一過程模型、敏捷開發模型

基於構件的開發模型

例如：動態連結庫（.dll），瀏覽器外掛

概念

近年來得到廣泛應用的軟體過程模型。由於採用構件技術和重用技術，它改變了大型軟體的開發方式，使得軟體開發時考慮的焦點不再是實現，而是整合。通過複用和整合已有的構件來實現軟體開發。

構件

就像一個螺絲，是系統中模組化的、可更換的部分，一個相對獨立的模組，並且能夠被另一個具有相同介面的構件所替換。

功能及特點

構件實現特定的功能，並對實現進行封裝，暴露一組介面，外界不需要知道構件內部實現的細節，只需要通過介面訪問構件提供的服務。構件的例子很多，如瀏覽器外掛

開發模型

基於構件的開發模型包括 2 部分：系統開發

(1)系統開發

1. 需求分析
2. 構件檢索與分析從構件庫中選取符合需求的構件
3. 然後基於需求分析和選取的構件進行體系結構設計
4. 在實現階段複用和整合構件
5. 進行系統測試
6. 系統維護

構件和需求不匹配？

可以有兩種選擇：

1. 修改構件，但是商用構件通常不能修改。
2. 修改需求，而修改需求可能會導致最終產品和使用者要求不完全一致，這時就需要和使用者協商。

(2)構件開發與維護

開發新構件或者購買新構件來擴充和維護構件庫。

構件開發階段

四個階段：

基於構件的開發模型的優缺點

•優點

•軟體複用

•降低開發成本和風險，加快開發進度，提高軟體質量

缺點

•模型複雜

•商業構件不能修改，會導致修改需求，進而導致系統不能完全符合客戶需求

•商業構件通常不能修改，會導致修改需求，也導致了無法完全控制所開發系統的演化

•專案劃分的好壞直接影響專案結果的好壞

適用場合

由於採用複用思想，故適用於系統之間有共性的情況。

統一過程模型

完整且完美的軟體工程方法，廣泛使用，基於面向物件方法學，使用統一建模語言UML（Unified Modeling Language）

描述軟體開發過程

——從3個視角：

動態視角：隨時間變化的各個階段，包括初始階段、精化階段、構建階段和產品化階段，採用迭代方式開發。

靜態視角：各個開發階段所要進行的活動，如業務建模，需求，分析設計，實現，測試等。

實踐視角：開發中可採用的良好實踐建議，這些實踐經過大量實際專案證明，對提高軟體開發效率和質量非常有效。

統一過程的模型圖

橫軸是動態視角，表示軟體開發隨時間變化的各個階段。整個過程是迭代的。分成4個連續階段：

1. 初始階段：進行專案計劃和評估風險；
2. 精化階段：設計系統的體系結構、制定專案計劃、確定資源和需求；
3. 構建階段：開發出所有元件和應用程式，整合並進行詳盡測試；
4. 產品化階段：將產品移交給使用者。

縱軸是靜態視角，表示在每個開發階段所要進行的活動。

1. 初始階段：進行業務建模和需求
2. 精化階段：進行分析設計，以及部分實現，
3. 構建階段：實現和測試
4. 產品化階段：進行部署
5. 專案管理貫穿整個開發週期。

各過程的工作

初始：專案計劃、評估風險；
精化：設計系統的體系結構、制定專案計劃、確定資源需求；
構建：開發出所有元件和應用程式，整合並進行詳盡測試；
產品化：將產品移交給使用者。

統一過程的靜態結構

統一過程的動態結構

則是通過對迭代式軟體開發過程的週期、階段、迭代過程以及里程碑等的描述來進行表示。

6個核心工程工作流：

• 業務建模工作流
• 需求工作流
• 分析設計工作流
• 實現工作流
• 測試工作流
• 部署工作流

3個核心支援工作流：

• 專案管理工作流
• 配置與變更管理工作流
• 環境工作流。

適用場景:

大團隊、大專案

管理實踐

六條最佳實踐，從大量實際專案的開發經驗中總結而來，對實際開發具有指導意義。

1. 迭代式開發

•需求變更不可避免

•每次迭代產生一個可交付版本，使用者反饋，減少風險

•根據客戶的輕重緩急來規劃增量，先開發和交付優先順序最高的增量

2. 管理需求

•採用用例分析來捕獲需求，由用例驅動設計和實現

•對需求及其變更進行管理

3. 基於構件體系結構

•採用基於構件的體系結構

•提高軟體複用率

4. 視覺化建模

•使用統一建模語言（UML）對系統進行視覺化建模

5. 驗證軟體質量

•軟體質量評估貫穿整個開發過程的所有活動

•全員參與

6. 控制軟體變更

•描述如何控制和跟蹤軟體的變更

敏捷開發模型

不同點

別具一格：不要求較複雜的結構，不要求規範的開發，不要求完善的文件。

起源

2001年2月，17位程式設計大師發表敏捷軟體開發宣言

宣言

一、個體和互動勝過過程和工具。軟體開發時，良好的軟體過程和現代的軟體開發工具非常重要，但是參與開發的人和他們之間的互動更加重要。如果開發人員能力很弱或者他們之間交流很少，即使有良好的軟體過程和現代的開發工具也無濟於事。

二、可以工作的軟體勝過面面俱到的文件。我們開發的目的是可以工作的軟體，而非文件。因此我們的開發的重點應該在軟體上，而不是花費大量時間撰寫大量文件，但並不是不寫文件，文件足夠即可。

三、客戶合作勝過合同談判。客戶和開發者之間應該建立一種合作關係，共同努力開發出軟體產品，而不是合同談判的雙方。這樣在出現問題時或者計劃發生變化時，才能更好應對實現雙贏。

四、響應變化勝過遵循計劃。外部環境變化往往導致軟體需求等發生變化，則計劃需要調整，因此軟體開發需要能夠快速響應變化，及時抓住市場和機遇。

強調

敏捷開發強調高效工作、快速響應變化，具有敏捷性。

敏捷開發方法

敏捷開發不是一個方法，它還含有許多不同方法。

例如：

• 極限程式設計，
• 自適應軟體開發
• 並列爭球法
• 動態系統開發方法
• 水晶法
• 特徵驅動開發
• 精益軟體開發

敏捷軟體開發

是基本原理和開發準則的結合

基本原理強調：

• 客戶滿意度和較早的軟體增量交付，軟體開發採用迭代方式，每次迭代產生一個增量，每次交付的週期都很短;
• 團隊小但有激情，團隊中的每一個人能力都很強，且工作非常有激情，這是保證快速開發的前提；
• 採用非正式的開發方法，以可工作的軟體為目標，適當時候進行結構調整和程式優化；
• 每次產生最小的軟體工程產品。每次迭代產生的增量都很小，保證每次迭代時間都很短，並且對變化具有敏捷性，能根據變化及時調整；
• 整體開發過程儘量簡單化。

開發準則強調：

• 分析和設計的交付
• 開發者和客戶之間積極持續的交流，客戶會派工作人員到開發組，作為客戶代表參與開發，使得交流及時和持續，保證敏捷性。

極限程式設計為例子為例（eXtreme Programming）

簡稱XP，意為：“把好的開發實踐運用到極致。”

一次迭代的過程

注：

程式設計之前，需要先寫測試用例，再進行程式設計，以保證開發出的程式能夠順利通過測試。

程式設計時採用結對程式設計，即兩個人使用同一個工作臺進行程式設計，一個程式設計一個看，這樣能及時發現問題，保證較高程式質量。

開發的程式持續整合到系統中並進行測試，當所有任務完成後釋出該版本，然後評估當前版本，進入下一次迭代

極限程式設計的有效實踐

極限程式設計通過一些有效實踐來保證快速敏捷開發。

1. 增量式開發。開發採用迭代方式，每次迭代產生一個增量，這種方式能夠使得軟體及早進入市場，且能夠根據反饋及時調整後續開發；

2. 小版本短週期交付：每次迭代產生的增量都很小，交付的週期也很短；

3. 結對程式設計

4. 程式碼集體所有

5. 開發團隊在開放的工作空間，便於開發人員之間的互動和交流；

6. 可持續的開發速度：<40小時/周，連續加班不超過兩週【會導致效率降低、質量下降】

7. 設計儘量簡單

8. 測試驅動開發，即：先寫測試用例再程式設計，以保證開發出的程式能夠順利整合到軟體中並通過測試。

9. 持續整合，軟體編寫完成隨即進行整合，整合頻率很高，幾天甚至每天都會進行整合；

10. 適時進行程式重構和優化，只改變程式內部結構，不改變其行為。由於編寫程式碼較快，採用的結構未必最優

11. 根據每次迭代的情況，及時調整計劃

12. 客戶派工作人員作為開發團隊成員，以便及時明確客戶需求和反饋

優點

•快速響應變化和不確定性

•在快速的、可持續的開發速度

•適應商業競爭環境下的有限資源和有限時間

缺點

•測試驅動開發可能導致通過測試但非使用者期望

•重構而不降低質量困難

適用場合

適用於需求模糊且經常改變的，能適應商業競爭環境下對專案提出的有限資源和有限開發時間的約束。