當前，軟件的趨勢是朝著更大更復雜的系統發展。這部分地是因為計算機的處理能力每年都在增大，
導致用戶對它的期望更多。同時，這種趨勢也受到為交流各種信息（從純文本到格式化文本到圖像到圖表再到多媒體）而不斷擴大互聯網的使用的影響。在產品版本的不斷升級過程中，我們了解到產品是如何被改進的，因此我們對越來越復雜的軟件的胃口也就越來越大。我們需要更符合我們的需要的軟件，但是，這種需要反過來又使得軟件越來越復雜?？傊?，我們需要更多。我們希望軟件運行得越來越快捷。推向市場的時間是另一個重要的推動因素 。
然而，要達到這個目的是困難的。我們對強大、復雜軟件的需要與軟件開發的當前狀況并不一致。今
天，大多數人還在使用25 年前使用的舊方法來開發軟件。這就是癥結所在。除非我們革新我們的方法，否則，我們無法達到開發當前所需的復雜軟件的目標 。
我們可以把這個軟件問題歸結為軟件開發人員面臨的將一個大型軟件項目的眾多線索綜合在一起的困
難。軟件開發界需要一種受控的工作方式。它需要一個過程來集成軟件開發的許多方面。它需要一種通用方法 ，該方法能 ：
ω 提供應如何對整個開發團隊的開發活動進行組織的指導 ；
ω 綜合指導單個開發人員和開發團隊 ；
ω 規定開發成果是什么 ；
ω 提供監控和衡量一個項目中的產品和活動的標準 。
一個定義良好且管理良好的過程是區別成效卓著的項目和不成功項目之間的重要指標?！敖y一軟件開
發過程”正是我們在軟件開發上面臨的難題的解決之道。

“統一過程”概述

第一點也是最重要的一點是，這個“統一過程”是軟件開發過程。軟件開發過程是將用戶的需求轉化
為一個軟件系統的一系列活動的總稱。然而，“統一過程”不僅僅是一個過程。它是一個通用過程框架，可以應付種類廣泛的軟件系統、不同的應用領域、不同的組織類型、不同的性能水平和不同的項
目規模。
“統一過程”是基于組件的，這意味著利用它開發的軟件系統是由組件構成的，組件之間通過定義良
好的接口相互聯系 。
在準備軟件系統的所有藍圖的時候，“統一過程”使用的是“統一建模語言（Unified Modeling
Language ）”。事實上，UML 是“統一過程”的有機組成部分——它們是被同步開發的 。
然而，真正使“統一過程”與眾不同的方面可以用三個句話來表達：它是用例驅動的、以基本架構為
中心的、迭代式和增量性的。正是這些特征使得“統一過程”卓爾不群。
“統一過程”是用例驅動的“統一過程”是用例驅動的“統一過程”是用例驅動的“統一過程”是用例驅動的開發軟件系統的目的是要為該軟件系統的用戶服務。因此，要創建一個成功的軟件系統，我們必須明白其潛在用戶需要什么 。
“用戶”這個術語所指并不僅僅局限于人類用戶，還包括其他系統。在這種意義上，“用戶”這個術語代表與利用“統一過程”開發出來的系統發生交互的某個人或者某件東西（例如在所要開發的系統之外的另一個系統）。交互的一個例子是使用自動取款機的一個人。他/ 她插入塑料磁卡，回答機器顯示器上提出的問題，然后就得到了一筆現金。在響應用戶的磁卡和回答時，系統完成一系列的動作，這個動作序列為用戶提供了一個有意義的結果，也就是提取了現金。
這個交互就是一個“用例”。一個用例就是系統中向用戶提供一個有價值的結果的某項功能。用例捕捉
的是功能性需求。所有用例結合起來就構成了“用例模型”，該模型描述系統的全部功能。這個模型取代了系統的傳統的功能規范說明。一個功能規范說明可以描述成對這個問題的回答：需要該系統做什么？而用例戰略則可以通過在該問題中添加幾個字來描述：需要該系統為每個用戶做什么？這幾個字有著重大意義。
它們迫使我們從用戶的利益角度出發進行考慮，而不僅僅是考慮系統應當具有哪些良好功能 。
然而，用例并不僅僅是定義一個系統的需求的一個工具。它們還驅動系統的設計、實現和測試。也就
是說，它們驅動整個開發過程?；谟美Ｐ?，軟件開發人員創建一系列的設計和實現模型來實現各種用例。開發人員審查每個后續模型，以確保它們符合用例模型。測試人員將測試軟件系統的實現，以確保實現模型中的組件正確實現了用例。這樣，用例不僅啟動了開發過程，而且與開發過程結合在一起?！坝美寗印币庵搁_發過程將遵循一個流程：它將按照一系列由用例驅動的工作流程來進行。首先是定義用例，然后是設計用例，最后, 用例是測試人員構建測試案例的來源。
盡管確實是用例在驅動整個開發過程，但是我們并不能孤立地選擇用例。它們必須與系統架構協同開
發。也就是說，用例驅動系統架構而系統架構反過來又影響用例的選擇。因此，隨著生命期的繼續，系統架構和用例都逐漸成熟。
“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的軟件架構的作用在本質上與基本架構在建筑物結構中所起的作用是一樣的。我們從不同的角度來觀察建筑物：結構、服務、供熱裝置、水管裝置、電力等。這樣，在開始建設之前，建設人員就可以對建筑物有一個完整的把握。同樣地，軟件系統的基本架構也被描述成要創建的系統的各種不同視圖 。
軟件基本架構這個概念體現了系統最為靜態和動態的方面?；炯軜嫺鶕髽I的需求來設計，而這種
需求則是由用戶和其他利益關聯人所感知，并反映在用例之中。然而，它還受其他許多因素的影響：軟件運行的平臺（例如計算機基本結構、操作系統、數據庫管理系統和網絡通信協議等）、可得到的可再用構件（比如圖形用戶界面框架）、配置方面的考慮、已有系統和非功能性需求（比如性能和可靠性）等?；炯軜嬍且粋€關于整體設計的視圖，在這個視圖中，省略了一些細節，以使軟件的更為重要的特征體現得更為明顯。由于什么東西是重要的部分取決于主觀判斷，而這種判斷又來自于經驗，因此，基本架構的價值取決于被指派完成這一任務的人員。然而，過程有助于架構設計師集中精力于正確的目標，比如可理解性、順應未來變化的靈活性和可再用性。
用例和基本架構之間的關系如何呢？每個產品都是功能和形式的有機統一。僅僅只有其中之一，都是
不完整的。只有平衡把握這兩個方面才能得到一個成功的產品。在這種情況下，功能應與用例相對應，而形式應當與基本架構相對應。用例和基本架構之間必定是相互影響的，這幾乎就是一個“雞和蛋”的問題。
一方面，我們實現的用例必須與基本架構相適應。而另一方面，基本架構必須留有實現現在和未來需要的所有用例的空間。在實踐中，基本架構和用例必須平行開發 。
因此，架構設計師將軟件系統構筑在一個形式當中。正是這個形式即基本架構必須被設計成讓系統不
僅在初始開發期間, 而且在未來的版本進化過程中能不斷發展。要找到這樣的一個形式，架構設計師必須對系統的關鍵功能也就是系統的關鍵用例有一個總體性把握。這些關鍵用例只占用例總數的5-10%，但是它們卻是最重要的，因為它們將構成整個系統的核心功能。下面是這個過程的簡單描述：
ω 架構設計師首先從不與特定的用例相關的部分（比如平臺）著手來創建基本架構的大致輪廓。盡管
基本架構的這部分是用例無關的，但是，在建立基本架構的輪廓之前，架構設計師必須對用例有一個總體把握。
ω 其次，設計人員應當從已經確認的用例子集著手開始工作，這些用例是指那些代表待開發系統的關
鍵功能的用例。每個選定的用例都應當被詳細描述，并在子系統、類和組件層次上實現。
ω 隨著用例已經被定義并且逐漸成熟，基本架構就越來越成形了。而這種狀況，反過來又導致更多用
例的成熟。
這個過程會不斷持續下去，直至基本架構被認定為穩定了為止。

統一開發過程是迭代式的和增量的統一開發過程

開發一個商業軟件產品是一項可能持續幾個月、一年甚至更長時間的工作。因此，將此種工作分解成
若干更小的部分或若干小項目是切合實際的 。
每個小項目是指能導致一個增量的一次迭代。迭代指的是工作流中的步驟，而增量指的是產品的成長。
為了更加高效，迭代必須受到控制；也就是說，必須對它們進行選擇并有計劃地實現它們。這就是為什么它們是小項目的原因 。
開發人員根據兩個因素來選擇在一次迭代中要實現什么。首先，迭代與一組用例相關，這些用例共同
擴展了到目前為止所開發的產品的可用性。其次，迭代涉及最為重要的風險。后續迭代是建立在先前的迭代完成后的開發成果之上的。它是一個小項目，因此，從用例開始，它還是必須經過下列開發工作：分析、設計、實現和測試，這樣，就以可執行代碼的形式在迭代中實現了用例。當然，一項增量并不一定就是添加性的。特別是在生命期的早期階段，開發人員可能會用一個更為詳盡或者復雜的設計來取代那種較為簡單的設計。在后期，增量通常都是添加性的 。
在每次迭代中，開發人員識認并詳細定義相關用例，利用已選定的基本架構作為指導來建立一個設計，
以組件形式來實現該設計，并驗證這些組件滿足了用例。如果一次迭代達到了它的目標（通常如此），那么開發過程就進入下一次迭代的開發了。當一次迭代沒有滿足它的目標時，開發人員必須重新審查先前的決定，試行一個新方法 。
為了在開發過程中實現經濟效益最大化，項目組必將試圖選擇為達到項目目標所需要的迭代。它應當
以邏輯順序排列相關迭代。一個成功的項目所經歷的過程通常都只與開發人員當初所計劃的有細微的偏差。
當然，考慮到出現不可預見的問題需要額外的迭代或者改變迭代的順序的影響，開發過程可能需要更多的時間和精力。使不可預見的問題減小到最低限度，也是風險控制的一個目標之一 。
一個受控制的迭代過程的好處有很多 ：
ω 受控制的迭代降低了在一個增量上的開支風險。如果開發人員需要重復該迭代，整個開發團隊損失
的只是一個開發有誤的迭代的花費而已，而不是整個產品的價值。
ω 受控制的迭代降低了產品無法按照既定進度表進入市場的風險。通過在開發早期就確定風險，人們
就會在開發早期花時間來解決它們，而在這時，人們通常都不會像他們在開發后期那樣匆匆忙忙。在“傳統”方法中，困難的問題往往是在系統測試階段才發現的，而解決這些問題所需求的時間通常又比開發進度中剩下的時間要多，因此，產品的延遲發布幾乎是必然的 。

原文轉自：http://www.kjueaiud.com