第2章 IT項目開發流程與UML概述

2.1 項目開發流程

項目開發并不是一個簡單的過程，我們需要遵循一些開發流程。一個項目的開發會被分成很多步驟來實現，每一個步驟都有自己的起點和終點。也正如此，使得開發過程中的每個步驟起點和終點在不同的軟件項目中出現不同難度的“坎”，使其難于達到該步驟開始或終結的條件，開發過程也就不會一帆風順。

不同的開發模式其實就是將步驟的起點和終點重新定義，甚至重新組合排列。雖然任何一個開發模式最終目的都是完成軟件項目的開發，但期間所經歷的過程不一樣，過程步驟之間的起點和終點的定義不同，所帶來的“坎”也就不一樣，項目周期自然各不相同。因此，根據軟件項目的實際情況，選擇一個適合的開發模式能減少開發周期中“坎”的出現次數與難度，可以很大程度地縮短開發周期。

我們首先了解一下傳統瀑布式開發流程，如圖2-1所示。

瀑布模型是由W.W.Royce在1970年首先提出的軟件開發模型，在瀑布模型中，開發被認為是按照需求分析、設計、實現、測試（確認）、集成和維護堅定而順暢地進行的。線性模型太理想化、太單純，以至于很多人認為瀑布模型已不再適合現代的軟件開發模式，幾乎被業界拋棄。

這里向大家推薦的是統一開發流程RUP（Rational Unified Process），它是目前最流行的一套項目開發流程模式，其基本特征是通過多次迭代完成一個項目的開發，每次迭代都會帶來項目整體的遞增，如圖2-2所示。

從縱向來看，項目的生命周期或工作流包括項目需求分析、系統分析和設計、實現、測試和維護。從橫向來看，項目開發可以分為4個階段：起始（Inception）、細化（Elaboration）、建造（Construction）和移交（Transition）。每個階段都包括一次或者多次的迭代，在每次迭代中，根據不同的要求或工作流（如需求、分析和設計等）投入不同的工作量。也就是說，在不同階段的每次迭代中，生命周期的每個步驟是同步進行的，但權重不同。這是與傳統瀑布式開發流程區別最大的地方。

2.1.1 項目生命周期

1.需求分析

需求分析階段的活動包括定義潛在的角色（角色指使用系統的人，以及與系統相互作用的軟、硬件環境）、識別問題域中的對象和關系，以及基于需求規范說明和角色的需要發現用例（Use Case）和詳細描述用例。

2.系統分析和設計

系統分析階段是基于問題和用戶需求的描述，建立現實世界的計算機實現模型。系統設計是結合問題域的知識和目標系統的體系結構（求解域），將目標系統分解為子系統；之后基于分析模型添加細節，完成系統設計。

3.實現

實現又稱編碼或開發階段，也就是將設計轉換為特定的編程語言或硬件，同時保持先進性、靈活性和可擴展性。在這個階段，設計階段的類被轉換為使用面向對象編程語言編制（不推薦使用過程語言）的實際代碼。這一任務可能比較困難，也可能比較容易，主要取決于所使用的編程語言本身的能力。

4.測試和維護

測試用于檢驗系統是否滿足用戶功能需求，以便增加用戶對系統的信心。系統經過測試后，整個開發流程告一段落，進入運行維護或新的功能擴展時期。

2.1.2 項目開發階段

1.起始階段（Inception Phase）

對于新的開發項目來說，起始階段是很重要的。在項目繼續進行前，我們必須處理重要的業務與需求風險。對于那些增強現有系統的項目，起始階段是比較短暫的，但是其目的仍是確定該項目的實施價值及可行性。起始階段有4個重要活動：

● 制定項目的范圍；

● 計劃并準備業務案例；

● 綜合分析，得出備選構架；

● 準備項目環境。

2.細化階段（Elaboration Phase）

細化階段的目標是為系統構架設立基線（Baseline），為在構建階段開展的大量設計與實施工作打下堅實的基礎。構架是通過考慮最重要的需求與評估風險演進而來的，構架的穩定性是通過一個或多個構架原型（Prototype）進行評估的。

3.構建階段（Construction Phase）

構建階段的目標是完成系統開發。構建階段從某種意義上來看是一個制造過程，其中，重點工作就是管理資源、控制操作，以優化成本、日程和質量。因此，在此階段，管理理念應該進行一個轉換，從起始階段和細化階段的知識產品開發轉換到構建和交付階段的部署產品的開發。

構建階段的每次迭代都具有3個關鍵活動。

● 管理資源與控制過程；

● 開發與測試組件；

● 對迭代進行評估。

4.交付階段（Transition Phase）

交付階段的焦點就是確保軟件對于最終用戶是可用的。交付階段包括為發布應用而進行的產品測試，在用戶反饋的基礎上做微小的調整等內容。在生命周期的這個時刻，用戶反饋主要集中在精確調整產品、配置、安裝及可用性等問題上。

交付階段的關鍵活動如下：

● 確定最終用戶支持資料；

● 在用戶的環境中測試可交付的產品；

● 基于用戶反饋精確調整產品；

● 向最終用戶交付最終產品。

最后，作為補充，再簡單介紹一種新的開發流程：敏捷開發和極限編程。

2001年，為了解決許多公司的軟件團隊陷入不斷增長的過程泥潭的問題，一批業界專家一起概括出了一些可以讓軟件開發團隊具有快速工作、響應變化能力的價值觀和原則，他們稱自己為敏捷聯盟。敏捷開發過程的方法有很多，主要有 SCRUM、Crystal、特征驅動軟件開發（Feature Driven Development，FDD）、自適應軟件開發（Adaptive Software Development，ASD），以及最重要的極限編程（eXtreme Programming，XP）。

極限編程是一套能快速開發高質量軟件所需的價值觀、原則和活動的集合，使軟件能以盡可能快的速度開發出來并向客戶提供最高的效益。XP在很多方面都和傳統意義上的軟件工程不同，同時，它也和傳統的管理和項目計劃的方法不同。這些方法在軟件工程和其他管理活動中都有借鑒意義。

XP具有12個過程，只有完全使用12個過程才是真正使用了XP，只是簡單地使用了其中的一個過程并不代表使用了XP。XP的12個過程如下：

● 現場客戶（On-site Customer）

● 計劃博弈（Planning Game）

● 系統隱喻（System Design）

● 簡化設計（Simple Design）

● 集體擁有代碼（Collective Code Ownership）

● 結對編程（Pair Programming）

● 測試驅動（Test-driver）

● 小型發布（Small Release）

● 重構（Refactoring）

● 持續集成（Continous Integration）

● 每周40小時工作制（40-hour Weeks）

● 代碼規范（Coding Standards）

下面是極限編程的有效實踐。

● 完整團隊XP項目的所有參與者（開發人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的墻壁上隨意懸掛著大幅的、顯著的圖表，以及其他一些顯示進度的東西。

● 計劃博弈是持續的、循序漸進的。每2周，開發人員就為下2周估算候選特性的成本，而客戶則根據成本和商務價值來選擇要實現的特性。

● 客戶測試作為選擇每個所期望特性的一部分，客戶可以根據腳本語言來定義出自動驗收測試來表明該特性可以工作。

● 簡單設計團隊保持設計恰好和當前的系統功能相匹配。它通過了所有的測試，不包含任何重復，表達出了編寫者想表達的所有東西，并且包含盡可能少的代碼。

● 結對編程：所有的產品軟件都是由兩個程序員并排坐在一起在同一臺機器上構建的。

● 測試驅動開發：編寫單元測試是一個驗證行為，更是一個設計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數量的反饋循環，尤其是功能驗證方面的反饋循環。程序員以非常短的循環周期工作，他們先增加一個失敗的測試，然后使之通過。

● 改進設計隨時利用重構方法改進已經腐化的代碼，保持代碼盡可能的干凈，具有表達力。

● 持續集成團隊總是使系統完整地被集成。一個人拆入（Check in）后，其他所有人負責代碼集成。

● 集體擁有代碼：任何結對的程序員都可以在任何時候改進任何代碼。沒有程序員對任何一個特定的模塊或技術單獨負責，每個人都可以參與任何其他方面的開發。

● 編碼標準系統中所有的代碼看起來就好像是由一人單獨編寫的。

● 系統隱喻：將整個系統聯系在一起的全局視圖，它是系統的未來影像，使得所有單獨模塊的位置和外觀變得明顯、直觀。如果模塊的外觀與整個隱喻不符，那么就會知道該模塊是錯誤的。

● 可持續的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，保存精力，把項目看作是馬拉松長跑，而不是全速短跑。

極限編程是一組簡單、具體的實踐，這些實踐結合在一起形成了一個敏捷開發過程。極限編程是一種優良的、通用的軟件開發方法，項目團隊可以拿來直接采用，也可以增加一些實踐，或者對其中的一些實踐進行修改后再采用。