統一過程
特點
- 統一過程是用例驅動的
-
用戶（User）：軟件系統是爲了解決用戶的需求的，因此對於一個系統必須首先確定它的用戶，即參與者。這個User不僅僅指人，也可以是其他系統。即用戶是與系統進行交互的事物。
-
用例（User Case）：是用戶對系統的業務需求，即用例是能夠向用戶提供有價值結果的系統中的一種功能。
所有的用戶和用例組合在一起就是用例模型，它描述了系統的全部功能。用例促使我們從系統對用戶的價值方面來考慮問題，是站在用戶的角度出發，以人爲本。並且用例不僅能確定用戶的需求，還可以驅動系統設計、實現和測試的進行，也就是說用例可以驅動開發過程。用例驅動表明開發過程是沿着一個流——一系列從用例得到的工作流前進的：用例被確定、用例被設計、最後用例又稱爲測試人員構造測試用例的基礎。
- 統一過程是以構架爲中心的
-
什麼是軟件構架？
軟件構架的作用與建築構架所起的作用類似。軟件系統的構架是從不同的角度描述即將構造的系統。
注意：軟件架構（Software Architecture），是一系列相關的抽象模式，用於指導大型軟件系統各個方面的設計。軟件架構是一個系統的草圖。它描述的對象是直接構成系統的抽象組件，各個組件之間的連接明確和相對細緻地描述組件之間的通訊。在實現階段，這些抽象組件被細化爲實際的組件，在面向對象領域中，組件之間的連接通常用接口來實現。
軟件構架包含了系統中最重要的靜態和動態特徵。構架刻畫了系統的整體設計，去掉了細節部分，突出了系統的重要特性，然而“究竟什麼是重要的”部分依賴於判斷，而判斷又來自於經驗，所以構架的價值也就依賴於執行該任務的人的素質，在構架的過程中可以幫助構架師確定正確的目標。 -
用例和架構之間是什麼關係？
每一種產品都具有功能和表現形式兩個方面，其中功能與用例相對應，表現形式與構架相對應。因此用例在實現時必須適應於構架，然而隨着系統的發展，用例也在不斷的進化，所以構架必須設計得使系統能夠進化，不僅要考慮系統的初始開發，而且要考慮將來的發展。爲了能夠找到這樣的一種表現形式（構架），構架師必須從全面瞭解系統的主要功能（即主要用例）入手，這些主要的用例構成了系統的核心功能。
-
構架應該遵循什麼步驟？
首先，從不是專門針對用例的那部分架構開始，如平臺，創建一個粗略的構架輪廓。
其次，着手處理已經確定重要的用例子集，這些用例代表着即將開發系統的主要功能，詳細描述每一個用例，並通過子系統、類和構件來實現。隨着用例的描述趨於完善，構架的更多部分便會顯現出來，從而也使更多的用例趨於完善。最後，迭代這個工程直到確信得到一個穩定的構架爲止。
-
統一過程是迭代和增量的過程
迭代即工作流中的步驟；增量即產品中增加的部分。軟件開發是一項複雜的過程，因此可以將這些項目劃分爲切實可行並能夠產生一個增量的迭代過程。爲了獲得最佳的效果，迭代過程必須是受控的（Controlled），也就是說必須按照計劃好的步驟有選擇地執行。
那麼如何確定迭代過程中要實現的目標呢？
首先迭代過程就是用來處理一組用例的，這些用例組合起來就能夠擴展所開發產品的可用性。
其次迭代過程要解決最突出的風險問題。只有這樣後續的迭代過程才能建立在前一次迭代過程的基礎上。
統一軟件開發過程的每個階段可以進一步被分解爲迭代過程。迭代過程是導致可執行產品版本（內部和外部）的完整開發循環，是最終產品的一個子集，從一個迭代過程到另一個迭代過程遞增式增長形成最終的系統。
迭代過程具有的優點
- 減小了風險
- 更容易對變更進行控制
- 高度的重用性
- 項目小組可以在開發中學習
- 較佳的總體質量
統一過程的軟件生命週期
（1） 統一過程的軟件生命週期就是從軟件的產生到消亡期間進行的一次次迭代，每次迭代都會產生一個產品版本，並且本次迭代是基於上次迭代的。產品就是軟件系統的一個構件，但是隻有這些是僅僅不夠的，因爲環境（操作系統、數據庫系統）在變化，此外隨着更好的理解任務，需求本身也在變化。因此統一開發過程中每次迭代要依據一些模型來產生產品。
用例模型： 包含用例與用戶之間的關係
分析模型： 更詳細的提煉用例，將系統的行爲初步分配給提供行爲的一組對象
設計模型： 將系統靜態結構定義爲子系統、類和接口，並定義由子系統、類和接口之間的協作所實現的用例。
實現模型： 包括構件（表現爲源代碼）和類到構件的映射。
實施模型： 定義計算機的物理節點和構件到這些節點的映射。
測試模型： 描述用於驗證用例的測試用例。
業務模型： 描述系統業務預警的領域模型。
所有的這些模型都是相關的，它們合起來表示整個系統。由圖1從上往下看，下面的模型對上面的模型有跟蹤依賴關係。這有利於系統的理解和修改。
（2）迭代階段
每次迭代分爲四個階段：初始、細化、構造和移交 ；在每個階段，管理人員或開發人員又可以將本階段的工作進一步劃分爲多次迭代過程以及每次迭代過程所產生的增量。每個階段都以一個里程碑作爲結束標記，並可以獲得一組可用的製品來定義每個里程碑。迭代的每個階段通常又進一步細分爲多次迭代過程，一次典型的迭代階段（初始、細化、構造、移交）都要經歷多種工作流：需求、分析、設計、實現和測試。
初始階段：這個階段最主要的是確定項目的風險及其優先次序，並對細化階段進行詳細規劃和對整個項目進行粗略計算。
細化階段：根據主要的用例描述設計出詳細的系統構架。構架包括了用例模型、分析模型、設計模型、實現模型（包含一些構件）和實施模型的視圖。
這個階段主要是解決用例、構架和計劃是否足夠穩定可靠，風險釋放得到充分控制，以便能夠按照合同的規定完成整個開發任務。
構造階段：將構造出最終產品。
移交階段：包括產品進入beta版後的整個階段。開發人員改正用戶報告產品的缺陷和不足。
敏捷過程
何爲敏捷開發過程？
敏捷開發是一種以人爲核心，以迭代方式循序漸進開發的方法，其軟件開發的過程稱爲“敏捷過程”。
在這一過程中，軟件項目的構建被切分成多個子項目，各個子項目的成功都經過測試，具備集成和可運行的特徵。
在2001年年初，一些業界專家成立了敏捷聯盟，起草了敏捷軟件開發宣言。該宣言針對一些企業的現狀，提出了讓軟件開發團隊具有快速工作、快速應變能力的若干價值觀和原則，其中包括4個簡單的價值觀以及敏捷開發方法應遵循的12條原則。
敏捷開發過程，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。
敏捷過程的4個價值觀
（1）個人和交互勝過過程和工具。
（2）可以運行的軟件勝過面面俱到的文檔。
（3）客戶合作勝過合同談判。
（4）響應變化勝過遵循計劃。
敏捷開發應遵循的12條原則
（1） 通過儘早的、不斷地提交有價值的軟件來使客戶滿意。
（2） 即使到了開發的後期，也歡迎改變需求。敏捷過程利用變化來爲客戶創造競爭優勢。
（3） 以從幾個星期到幾個月爲週期，儘快、不斷地提交可運行的軟件。
（4） 在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
（5） 以積極向上的員工爲中心，建立項目組，給他們提供所需的環境和支持，並對他們的工作予以充分的信任。
（6） 在團隊內部，最有效、效率最高的傳遞信息的方法，就是面對面的交流。
（7） 測量項目進展的首要依據是可運行軟件。
（8） 敏捷過程提倡可持續的開發，責任人、開發者和用戶應該爲能夠保持一個長期的、恆定的開發速度而努力。
（9） 時刻關注技術上的精益求精和好的設計，以增強敏捷能力。
（10） 簡單是最根本的。
（11） 最好的構架、需求和設計出於自組織的團隊。
（12） 每隔一定時間，團隊要反省如何才能更有效地工作，然後相應地調整自己的行爲。