現代軟體過程概述

作者：徐建祥（ 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