作者：徐建祥（ netpirate@gmail.com ）

時間： 2006/09/22

來自： http://www.anymobile.org

?

1、軟件過程

?

?????? 隨著軟件系統的規模和復雜性的增加，其開發成本和風險隨之增加，軟件的質量問題已成為制約軟件發展的關鍵因素之一。

?????? 所謂軟件過程，即軟件項目的開發過程，是指軟件生命周期中，用于開發和維護軟件產品的一系列過程，它與團隊的組織管理以及開發技能相輔相成，全面提升軟件產品的質量。

?????? 近年來，軟件過程日益得到重視，國際軟件界的敏捷、統一熱也在持續升溫。 與傳統的開發過程相比，敏捷過程更強調快速靈活反應，主動迎接和適應變化，主張更緊密的客戶與開發商協作，以人為本的可持續發展，典型的有 XP （極限編程）、 FDD （特征驅動開發）等；統一軟件過程以 RUP 為代表，采用 OO 技術對軟件開發過程本身進行業務建模，集成了迭代開發、用例驅動、 UML 可視化建模、 OOAD 、架構設計、項目管理等許多主流先進的當代軟件工藝。

?????? 在軟件項目開發過程中，應該能夠識別、分析不同軟件項目的特點，采用相對適合的開發實踐來適應軟件開發過程，保證對軟件開發的有效支持，如 RUP 與 XP 的融合。

?

2、 XP ，極限編程

?

極限編程（ eXtreme Propgramming ， XP ）是由 Kent Beck 在 1996 年開創，是一種演進式的原型化方法，以最大化發揮人的能量為核心目標，以“小步快走”的邏輯指導開發，具有溝通高效、設計簡單、反饋迅速等特點，是一種輕量級、敏捷的過程方法。

極限編程基于四個價值目標：溝通（ communication ）、簡化 (simplicity) 、反饋 (feedback) 和勇氣 (courage) ，由 12 個最佳實踐為這四個價值提供支持。

極限編程的生命周期包括 4 個基本活動：編碼 (coding) 、測試 (testing) 、聆聽 (listening) 、設計 (designing) 。

2.1 4 個價值目標

?????? 溝通：讓開發人員集體負責所有代碼并結隊工作，鼓勵與客戶及團隊內部保持溝通。

簡化：鼓勵只開發當前的功能，避免過多的文檔，專注于最小化解決方案，做好為為新特性改變設計，在系統隱喻和代碼規范下不斷重構的準備。

反饋：通過單元測試和功能測試獲得快速反饋。

勇氣：提倡積極面對現實和處理問題的勇氣，擁抱變化。

2.2 12 個最佳實踐

?
（圖片1 XP最佳實踐）

????????????? 有計劃的開發：通過結合使用優先級“故事”和技術估算，確定下一版本的功能。

小型發布：以小的增量版本經常向客戶發布軟件。

系統隱喻：隱喻是一個高層次的系統構想；需要不斷的細化架構，來指導全部開發。

簡單設計：通過保持代碼簡單從而保證設計簡單。不斷的在代碼中尋找復雜點并且立刻進行移除。

測試驅動：“先測試，后編碼”。用戶編寫測試內容以對 " 故事 " 進行測試。程序員編寫測試內容來發現代碼中的任何問題。在編寫代碼前先編寫測試內容。

重構：這是一項簡化技術，用來移除代碼中的重復內容和復雜之處。

結對編程：團隊中的兩個成員使用同一臺計算機開發所有的代碼。一個人編寫代碼或者驅動，另一個人同時審查代碼的正確性和可理解性。

集體代碼所有權：任何人都擁有所有的代碼。提高代碼透明度，增強團隊合作精神。

持續集成：每天按任務多次創建和集成系統，隨著需求變化，進行不斷的回歸測試。

每周 40 小時工作制：程序員在疲勞時無法保證最高效率。連續兩周加班是絕對不允許的，否則會影響工作效率。

現場客戶：至少有一名真實的客戶全天候工作于開發環境中，幫助定義系統、編寫測試內容并回答問題。

編碼規范：程序員采用統一的編碼規范。

總體來說， XP 部分滿足了 CMM2~3 級關鍵過程域 (KPA) 的要求， XP 側重與過程和技術， CMM 更注重組織和管理。

?

3、 ? FDD ，特征驅動開發

特征驅動開發（ Feature Drive Develop ， FDD ）， Together 創始人 Peter Coad 所創。通過特征來制定開發計劃，以每日構建為核心，強調按特征分步開發和交付。一個特征就是一個小的、具有客戶價值的功能，通常表示為 <action><result><object> 。

?

4、 ? RUP ， Rational 統一過程

?

迭代軟件開發的發展背景：軟件的不確定和高風險等特性，使得傳統的瀑布式開發力不從心；迭代有助于盡快發現和解決風險；迭代有助于控制項目的節奏，加快反饋，增強項目的控制力度，實現過程的有序化；迭代符合人們對事物的認識逐步加深，解決問題的能力隨經驗逐步提高。

?????? Rational 統一過程（ Rational Unified Process ， RUP ），是用例驅動、以體系結構為中心，迭代、增量的軟件開發過程。適合大、中型項目。

RUP 強調采用現代軟件開發的一些最佳實踐，作為一種降低開發新軟件所帶來的內在風險的方式。這些最佳實踐包括：

1) 迭代開發；

2) 管理需求；

3) 使用基于組件的構架；

4) 可視建模；

5) 持續的質量驗證；

6) 控制變更。

RUP 是一個迭代過程，確定了任何軟件開發項目的四個階段：初始階段、精化階段、構建階段和交付階段。每個階段包括一次或多次迭代；每一次迭代都會生成更加接近最終產品的可執行版本。?

a 、初始階段：識別和規避項目的主要風險，建立用例模型框架，并制定里程碑日期的階段計劃；

b 、精化階段：分析問題領域，建立健全的體系結構基礎，編制項目計劃，淘汰項目中最高風險的元素，完成部分優先級最高的用例開發；

c 、構建階段：分為多個迭代，逐步完成不同優先級的用例開發，核心 Case-> 高風險 Case-> 次核心 Case-> 其它 Case ；

d 、交付階段：進行各種功能、性能測試，進行產品化、部署，完成整個系統的開發工作。

（圖片2 RUP概述圖）

RUP 迭代開發過程：

a 、第一次迭代

1)?? 捕獲需求

2) ? 建立初始的領域模型

3)?? 建立用例模型框架

4)?? 制定開發計劃

b 、第二次迭代

1)?? 關鍵用例的 Robustness 分析與交互建模

2)?? 體系結構設計

3)?? 建立類模型

4)?? 關鍵用例的開發與測試

5)?? 完善用例模型

c 、第 n 次迭代

完成所有用例的分析、設計與開發。

d 、最后的迭代

1)?? 整體測試：進行各種功能、性能和壓力測試。

2)?? 部署與安裝：生成相應的部署圖。

3)?? 產品化：進行一些產品化的包裝。

注：每一次迭代之后，都應該交付一個可以運行的中間版本。

（圖片3 RUP迭代流）

5、? SPP ，精簡并行過程

精簡并行過程（ Simplified Parallel Process ， SPP ），對 CMMI 3 級以內各過程域的內容和要求作了“精簡”處理，包括 19 個過程域、 40 余個規程和近 60 個文檔模板 。強調在產品生命周期之內，項目管理過程、項目研發過程和機構支撐過程“并行”開展。

（圖片4 SPP）

軟件過程改進解決方案（ SPIS ）――林銳發明。

核心組成部分

1) 軟件過程改進咨詢服務；

2) 軟件工程與項目管理培訓；

3) 基于 Web 的集成化項目管理工具， Future 。

Future 采用 CMMI 和 SPP 為參考標準。主要功能包括項目規劃、項目監控、質量管理、配置管理、需求管理、日常工作管理等。

網站： http://www.chinaspis.com