軟體開發項目的最佳實務。

引言 大多數軟體項目都是失敗的。事實上，Standish group 的報告顯示 80% 多的項目是不成功的，原因是超出了預算、未能按時完成、遺漏功能或者因為一個項目中同時出現了這些問題中的其中幾個。此外，30% 的軟體項目執行得很糟糕以至於半途而廢。根據我們的經驗，使用現代技術（例如 Java、J2EE、XML 以及 Web 服務）的軟體項目都逃不出這個規則。 本文概述了軟體開發項目的最佳實務。一些業界泰鬥，如 Scott Ambler、Martin Fowler、Steve McConnell 和 Karl Wiegers，已經在網際網路上寫了許多這樣的最佳實務，本文也引用了這些最佳實務。另請參閱本文末尾的相關資訊部分。附帶的文章軟體開發項目實施指南描述了有助於提高項目成功率的十條最重要的因素。 最佳實務項目 1. 開發流程（Development process）－為手頭的項目選擇適當的開發生命週期流程很重要(CMMI三級自訂過程最大的一個裁剪項)，因為其他的所有活動都是從這個流程派生出來的。現代的軟體開發項目多數都是在瀑布式流程的基礎上採用某種螺旋式方法。有幾種方法可供選擇，包括 Rational 統一流程（Rational Unified Process，RUP）、IBM Global Services 方法（IBM Global Services Method）以及極端編程（eXtreme Programming，XP）。(還要改進型的瀑布模型，增量等相關模型可以供選擇)流程當然比根本沒有要好，但在多數情況下流程的執行情況要比使用的是什麼流程更重要。以上列舉的常用方法都包含關於如何執行流程的指南和構件模板。此外，RUP 還有一系列描述使用 RUP 的最佳實務的書  [1][2][3][4]，即便不選用 RUP，這些書也是獲得最佳實務的極好來源。給 RUP 加外掛程式也是可以的。請為基於 WebSphere J2EE 的項目下載  WebSphere 外掛程式。(RUP是很好的一套增量迭代的開發方法，RUP方法論可以更好的應當變化和體現架構設計在開發過程中的主導作用，但真正用好並不容易) 2.需求－收集需求就需求達成一致是項目成功的基礎。這並不一定意味著需要在建立好體繫結構、完成設計和編碼工作之前確定所有的需求，但對於開發小組來說明白需要構建什麼是很重要的。品質需求分兩種：功能性的和非功能性的。一種記錄功能性需求的好方法是使用用例（Use Case）。注意：用例被用於非物件導向的項目。Armour 和 Miller 著有一本關於用例主題的權威著作 [5]。非功能性需求描述應用程式的效能和系統特性。收集非功能性需求很重要，因為他們對應用程式體繫結構、設計以及效能都會產生重要影響。請參閱 ConstruxWeb 網站上的 非功能性需求清單。(非功能性需求和功能性需求一樣重要，對於新產品的非功能性需求的前期收集是具有難度的，更多要借鑒其它產品相關經驗。需求開發可以採用結構化分析方法，也可以採用用例分析方法。架構設計也應該針對系統的功能性需求和非功能性需求分別進行設計) 3.體繫結構 － 為您的應用程式選擇合適的體繫結構是關鍵。有好幾次 ibm 被要求複查出問題的項目，結果發現開發小組沒有應用知名的業界體繫結構最佳實務。與 ibm 聯絡是避免這類問題的好方法。我們的顧問可以與您的開發小組並肩工作以確保項目沿正確的軌道開始。經過實驗證明可靠的實踐稱為模式，有經典的 Gang of Four [6] 模式、Java 模式 [7]，也有 EJB 設計模式 [8]。Sun 公司與此相應的是核心 J2EE 模式（Core J2EE Pattern）目錄 [9]。IBM 也發布過一些最佳實務和參考應用程式體繫結構 [10]。引言中說過許多項目都是失敗的。通過對這些失敗的項目的研究提出了反模式這個概念。這些反模式是很有價值的，因為它們針對哪裡出了問題以及為什麼會出問題提供了有用的資訊。 4. 設計－即使有了好的體繫結構，也可能設計不好。許多應用程式不是設計得過於複雜就是設計得過於簡單。這有兩個基本原則 “盡量簡單”和 資訊隱藏。對於許多項目來說，使用 UML 進行物件導向的分析與設計（Object-Oriented Analysis and Design）很重要。有關 UML 的書有很多，但我們推薦 UML User Guide [11]和 Applying UML and Patterns [12]。重用是物件導向的很有前途的一個方面，重用經常會因為需要額外的工作來建立可重用資產而變得無法實現。代碼重用是重用的一種形式，當然也有其他一些能夠提高效率的重用種類。(Applying UML and Patterns 這本書結合了模式，RUP很多最佳實務和例子在裡面，確實值得推薦) 5. WebSphere 應用程式設計 － ibm 擁有關於 WebSphere 系列產品的最佳實務和設計模式的廣泛知識。每個項目都是不同的，我們的顧問有豐富的經驗來協助您。即使您只聘請我們的顧問很短一段時間，這種投資回報（ROI）也是很大的，因為您可以在以後的項目中節省開銷。我們的專家也發表過大量有關這類知識的文章，包括高效能 Web 網站注意事項和自主計算指南。 6. 代碼的構建－代碼的構建雖然只是整個項目工作的一小部分，但往往是最明顯的部分。其他同樣重要的工作還包括需求、體繫結構、分析、設計以及測試。在沒有開發流程（所謂的“編碼加修正”）的項目中，也會有這些任務，只不過被統稱為“編程”而已。構建代碼的最佳實務包括每日構建和煙霧測試 (Smoke Test)。Martin Fowler 進一步提出了 連續整合（continuous integration），這個概念還整合了單元測試和自測試代碼概念。注意，即使連續整合和單元測試是通過 xp 流行起來的，您也可以在所有類型的項目中使用這些最佳實務。我建議使用標準架構（比如 Ant和 JUnit）使構建和測試自動進行。(煙霧測試 (Smoke Test)的關鍵點就是用最典型的測試案例來測試最典型的可能應用和過程。採用JUnit,NuUnit 等測試架構後可以保證煙霧測試 (Smoke Test)的自動化，持續整合這個概念很重要，持續整合最重要的目的就是儘早的發現和解決問題) 7. 對等審查 － 審查別人的工作很重要。經驗證明這種方法可以及早消除問題，審查和測試一樣有效，甚至比測試還有效。開發流程中任何構件都需要審查，包括：規劃、需求、體繫結構、設計、代碼以及測試案例（test case）。Karl Wiegers 的文章 Seven Deadly Sins of Software Reviews 說明了執行對等審查的正確方法。對等審查有助於以最快的速度提高軟體品質。 8. 測試 － 即使排程再緊也不可以延遲或省去測試。測試是需要計劃的軟體開發的一個必不可少的部分。提前測試也很重要；這意味著要在開始編碼前就安排好測試案例，測試案例的開發與應用程式的設計和編碼同時進行。同樣也有許多現成的測試模式。 9. 效能測試 － 測試通常是用於檢查應用程式缺陷的最後一招。它是勞動密集型工作，通常只檢查編碼缺陷。體繫結構和設計上的缺陷可能會漏掉。一種檢查體繫結構缺陷的方法是在部署應用程式之前對其進行類比負載測試，並在效能問題真正成為問題前就處理它們。(效能測試暴露的問題更多都是由於架構設計在對非功能性需求方面考慮不足) 10. 組態管理 － 進行組態管理涉及到瞭解組成您的系統或項目的所有構件的狀態，管理這些構件的狀態並發布系統的不同版本。組態管理比單獨的原始碼控制系統（比如 Rational Clearcase）管理的內容更多。同樣也有針對組態管理的最佳實務和模式 [13]。 11. 品質和缺陷管理 － 為項目建立品質優先順序和發布標準很重要，這樣就可以制定一個計劃來協助開發小組開發出高品質的軟體。當對項目進行編碼和測試時，缺陷的出現和修正比率有助於測量代碼的成熟程度。使用連結到原始碼控制管理系統的缺陷跟蹤系統也很重要。例如，使用 Rational ClearCase 的項目還可以使用 Rational ClearQuest。使用缺陷跟蹤，就可以在準備發布項目時對項目進行測量（gauge）。(小型項目可以使用一些開源免費的缺陷管理功能，如Bug Tracker等) 12. 部署（Deployment）－ 部署是向使用者發布應用程式的最後階段。如果您的項目進行到了這一步 － 那就恭喜您啦！但仍然會有可能出錯的地方。您要制定部署計劃，並且您可以使用 Construx Web 網站上的部署資訊清單。(硬體環境，軟體環境，部署方法和步驟) 13. 系統操作與支援（System operations and support）－ 沒有操作部門就不能部署和支援新應用程式。支援範圍對於回答和解決使用者問題至關重要。為緩解問題流，應用程式缺陷跟蹤系統中引入了支援問題資料庫。 14. 資料移轉（Data migration）－ 多數應用程式都不是全新的，而是改善或者重寫的現有應用程式。從現有的資料來源遷移資料這本身通常就是一個比較大的項目。這不是初級程式員能做的。它與新應用程式一樣重要。通常新應用程式的商務規則更好，資料品質有可能更高。提高資料品質是一個複雜的主題，已經超出了本文討論的範圍。 15. 專案管理（Project management）－ 專案管理是項目取得成功的關鍵。本文描述的許多其他的最佳實務都和專案管理有關，出色的專案經理已經知道了這些現有的最佳實務。我們推薦項目管理權威著作是 Steve McConnell 編寫的 Rapid Development [14]。如果把專案管理的其他清單和技巧的數目考慮進去，您會感到大吃一驚，居然有那麼多的專案經理不知道這些技巧，並且也沒有從以前的項目中吸取教訓，比如：“如果沒有計劃好，就等於計划著要失敗。”一種管理困難項目的方法是通過使用時間定量（timeboxing）。 16. 衡量是否成功 － 您可以根據卡內基梅隆大學軟體工程學院（Software Engineering Institute at Carnegie Mellon University）的業界標準軟體能力成熟度等級模型（Capability Maturity Model，CMM）來衡量您的開發流程。多數項目處於 1 級（初級）。如果按照上面描述的最佳實務和附帶的文章，軟體開發項目實施指南，中的執行，就可以開發出更加成熟的軟體，使項目取得成功。(軟體能力成熟度等級和項目本身是否成功能否直接劃等號？) 結束語 本文提供了一系列有助於提高軟體開發項目成功率的最佳實務。遵循這些最佳實務，您的項目成功的機會會更大。 注:紅色部分為人月神話新增內容