統一軟件開發過程
<Translater>環球互動www.globalempower.com</Translater>
<Date> 2000/6</Date>
當前，軟件的趨勢是朝著更大更復雜的系統發展。這部分地是因為計算機的處理能力每年都在增大，
導致用戶對它的期望更多。同時，這種趨勢也受到為交流各種信息（從純文本到格式化文本到圖像到圖表再到多媒體）而不斷擴大互聯網的使用的影響。在產品版本的不斷升級過程中，我們了解到產品是如何被改進的，因此我們對越來越復雜的軟件的胃口也就越來越大。我們需要更符合我們的需要的軟件，但是，這種需要反過來又使得軟件越來越復雜�？傊�，我們需要更多。我們希望軟件運行得越來越快捷。推向市場的時間是另一個重要的推動因素 。
然而，要達到這個目的是困難的。我們對強大、復雜軟件的需要與軟件開發的當前狀況并不一致。今
天，大多數人還在使用25 年前使用的舊方法來開發軟件。這就是癥結所在。除非我們革新我們的方法，否則，我們無法達到開發當前所需的復雜軟件的目標 。
我們可以把這個軟件問題歸結為軟件開發人員面臨的將一個大型軟件項目的眾多線索綜合在一起的困
難。軟件開發界需要一種受控的工作方式。它需要一個過程來集成軟件開發的許多方面。它需要一種通用方法 ，該方法能 ：
ω 提供應如何對整個開發團隊的開發活動進行組織的指導 ；
ω 綜合指導單個開發人員和開發團隊 ；
ω 規定開發成果是什么 ；
ω 提供監控和衡量一個項目中的產品和活動的標準 。
一個定義良好且管理良好的過程是區別成效卓著的項目和不成功項目之間的重要指標�！敖y一軟件開
發過程”正是我們在軟件開發上面臨的難題的解決之道。
“統一過程”概述
第一點也是最重要的一點是，這個“統一過程”是軟件開發過程。軟件開發過程是將用戶的需求轉化
為一個軟件系統的一系列活動的總稱。然而，“統一過程”不僅僅是一個過程。它是一個通用過程框架，可以應付種類廣泛的軟件系統、不同的應用領域、不同的組織類型、不同的性能水平和不同的項
目規模。
“統一過程”是基于組件的，這意味著利用它開發的軟件系統是由組件構成的，組件之間通過定義良
好的接口相互聯系 。
在準備軟件系統的所有藍圖的時候，“統一過程”使用的是“統一建模語言（Unified Modeling
Language ）”。事實上，UML 是“統一過程”的有機組成部分——它們是被同步開發的 。
然而，真正使“統一過程”與眾不同的方面可以用三個句話來表達：它是用例驅動的、以基本架構為
中心的、迭代式和增量性的。正是這些特征使得“統一過程”卓爾不群。
“統一過程”是用例驅動的“統一過程”是用例驅動的“統一過程”是用例驅動的“統一過程”是用例驅動的開發軟件系統的目的是要為該軟件系統的用戶服務。因此，要創建一個成功的軟件系統，我們必須明白其潛在用戶需要什么 。
“用戶”這個術語所指并不僅僅局限于人類用戶，還包括其他系統。在這種意義上，“用戶”這個術語代表與利用“統一過程”開發出來的系統發生交互的某個人或者某件東西（例如在所要開發的系統之外的另一個系統）。交互的一個例子是使用自動取款機的一個人。他/ 她插入塑料磁卡，回答機器顯示器上提出的問題，然后就得到了一筆現金。在響應用戶的磁卡和回答時，系統完成一系列的動作，這個動作序列為用戶提供了一個有意義的結果，也就是提取了現金。
這個交互就是一個“用例”。一個用例就是系統中向用戶提供一個有價值的結果的某項功能。用例捕捉
的是功能性需求。所有用例結合起來就構成了“用例模型”，該模型描述系統的全部功能。這個模型取代了系統的傳統的功能規范說明。一個功能規范說明可以描述成對這個問題的回答：需要該系統做什么？而用例戰略則可以通過在該問題中添加幾個字來描述：需要該系統為每個用戶做什么？這幾個字有著重大意義。
它們迫使我們從用戶的利益角度出發進行考慮，而不僅僅是考慮系統應當具有哪些良好功能 。
然而，用例并不僅僅是定義一個系統的需求的一個工具。它們還驅動系統的設計、實現和測試。也就
是說，它們驅動整個開發過程�；谟美Ｐ�，軟件開發人員創建一系列的設計和實現模型來實現各種用例。開發人員審查每個后續模型，以確保它們符合用例模型。測試人員將測試軟件系統的實現，以確保實現模型中的組件正確實現了用例。這樣，用例不僅啟動了開發過程，而且與開發過程結合在一起�！坝美寗印币庵搁_發過程將遵循一個流程：它將按照一系列由用例驅動的工作流程來進行。首先是定義用例，然后是設計用例，最后, 用例是測試人員構建測試案例的來源。
盡管確實是用例在驅動整個開發過程，但是我們并不能孤立地選擇用例。它們必須與系統架構協同開
發。也就是說，用例驅動系統架構而系統架構反過來又影響用例的選擇。因此，隨著生命期的繼續，系統架構和用例都逐漸成熟。
“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的“統一過程”是以基本架構為中心的軟件架構的作用在本質上與基本架構在建筑物結構中所起的作用是一樣的。我們從不同的角度來觀察建筑物：結構、服務、供熱裝置、水管裝置、電力等。這樣，在開始建設之前，建設人員就可以對建筑物有一個完整的把握。同樣地，軟件系統的基本架構也被描述成要創建的系統的各種不同視圖 。
軟件基本架構這個概念體現了系統最為靜態和動態的方面�；炯軜嫺鶕髽I的需求來設計，而這種
需求則是由用戶和其他利益關聯人所感知，并反映在用例之中。然而，它還受其他許多因素的影響：軟件運行的平臺（例如計算機基本結構、操作系統、數據庫管理系統和網絡通信協議等）、可得到的可再用構件（比如圖形用戶界面框架）、配置方面的考慮、已有系統和非功能性需求（比如性能和可靠性）等�；炯軜嬍且粋�關于整體設計的視圖，在這個視圖中，省略了一些細節，以使軟件的更為重要的特征體現得更為明顯。由于什么東西是重要的部分取決于主觀判斷，而這種判斷又來自于經驗，因此，基本架構的價值取決于被指派完成這一任務的人員。然而，過程有助于架構設計師集中精力于正確的目標，比如可理解性、順應未來變化的靈活性和可再用性。
用例和基本架構之間的關系如何呢？每個產品都是功能和形式的有機統一。僅僅只有其中之一，都是
不完整的。只有平衡把握這兩個方面才能得到一個成功的產品。在這種情況下，功能應與用例相對應，而形式應當與基本架構相對應。用例和基本架構之間必定是相互影響的，這幾乎就是一個“雞和蛋”的問題。
一方面，我們實現的用例必須與基本架構相適應。而另一方面，基本架構必須留有實現現在和未來需要的所有用例的空間。在實踐中，基本架構和用例必須平行開發 。
因此，架構設計師將軟件系統構筑在一個形式當中。正是這個形式即基本架構必須被設計成讓系統不
僅在初始開發期間, 而且在未來的版本進化過程中能不斷發展。要找到這樣的一個形式，架構設計師必須對系統的關鍵功能也就是系統的關鍵用例有一個總體性把握。這些關鍵用例只占用例總數的5-10%，但是它們卻是最重要的，因為它們將構成整個系統的核心功能。下面是這個過程的簡單描述：
ω 架構設計師首先從不與特定的用例相關的部分（比如平臺）著手來創建基本架構的大致輪廓。盡管
基本架構的這部分是用例無關的，但是，在建立基本架構的輪廓之前，架構設計師必須對用例有一個總體把握。
ω 其次，設計人員應當從已經確認的用例子集著手開始工作，這些用例是指那些代表待開發系統的關
鍵功能的用例。每個選定的用例都應當被詳細描述，并在子系統、類和組件層次上實現。
ω 隨著用例已經被定義并且逐漸成熟，基本架構就越來越成形了。而這種狀況，反過來又導致更多用
例的成熟。
這個過程會不斷持續下去，直至基本架構被認定為穩定了為止。
統一開發過程是迭代式的和增量的統一開發過程
開發一個商業軟件產品是一項可能持續幾個月、一年甚至更長時間的工作。因此，將此種工作分解成
若干更小的部分或若干小項目是切合實際的 。
每個小項目是指能導致一個增量的一次迭代。迭代指的是工作流中的步驟，而增量指的是產品的成長。
為了更加高效，迭代必須受到控制；也就是說，必須對它們進行選擇并有計劃地實現它們。這就是為什么它們是小項目的原因 。
開發人員根據兩個因素來選擇在一次迭代中要實現什么。首先，迭代與一組用例相關，這些用例共同
擴展了到目前為止所開發的產品的可用性。其次，迭代涉及最為重要的風險。后續迭代是建立在先前的迭代完成后的開發成果之上的。它是一個小項目，因此，從用例開始，它還是必須經過下列開發工作：分析、設計、實現和測試，這樣，就以可執行代碼的形式在迭代中實現了用例。當然，一項增量并不一定就是添加性的。特別是在生命期的早期階段，開發人員可能會用一個更為詳盡或者復雜的設計來取代那種較為簡單的設計。在后期，增量通常都是添加性的 。
在每次迭代中，開發人員識認并詳細定義相關用例，利用已選定的基本架構作為指導來建立一個設計，
以組件形式來實現該設計，并驗證這些組件滿足了用例。如果一次迭代達到了它的目標（通常如此），那么開發過程就進入下一次迭代的開發了。當一次迭代沒有滿足它的目標時，開發人員必須重新審查先前的決定，試行一個新方法 。
為了在開發過程中實現經濟效益最大化，項目組必將試圖選擇為達到項目目標所需要的迭代。它應當
以邏輯順序排列相關迭代。一個成功的項目所經歷的過程通常都只與開發人員當初所計劃的有細微的偏差。
當然，考慮到出現不可預見的問題需要額外的迭代或者改變迭代的順序的影響，開發過程可能需要更多的時間和精力。使不可預見的問題減小到最低限度，也是風險控制的一個目標之一 。
一個受控制的迭代過程的好處有很多 ：
ω 受控制的迭代降低了在一個增量上的開支風險。如果開發人員需要重復該迭代，整個開發團隊損失
的只是一個開發有誤的迭代的花費而已，而不是整個產品的價值。
ω 受控制的迭代降低了產品無法按照既定進度表進入市場的風險。通過在開發早期就確定風險，人們
就會在開發早期花時間來解決它們，而在這時，人們通常都不會像他們在開發后期那樣匆匆忙忙。在“傳統”方法中，困難的問題往往是在系統測試階段才發現的，而解決這些問題所需求的時間通常又比開發進度中剩下的時間要多，因此，產品的延遲發布幾乎是必然的 。
ω 受控制的迭代加快了整個開發工作的進度，這是因為開發人員很清楚焦點所在，而不是在一個漫長
而不斷變化的進度安排下工作，因此, 他們的工作會更有效率。
ω 受控制的迭代承認了通常都被忽略的一個事實：用戶的需要和相應的需求并不能在一開始就作出完
全的界定。它們通常都是在后續迭代中不斷被細化的。此種作業模式使得適應需求的變化更為容易。
這些概念即用例驅動的、以基本架構中心的、迭代式和增量性的開發是同等重要的�；炯軜嬏峁┝�
指導迭代中的工作的結構，而用例則確定了開發目標并推動每次迭代工作。缺乏這三個概念中的任何一個，都將嚴重降低“統一過程”的價值。這就好像一個三腳凳一樣，一旦缺了任何一條腿，凳子都會翻倒。
以上我們已經介紹了三個主要概念，現在讓我們來看看整個過程、它的生命期、成果、工作流程、階
段和迭代。
“統一過程”的生命期
“統一過程”將重復一系列生命期，這些生命期構成了一個系統的壽命。每個生命期都以向客戶推出
一個產品版本而結束。
每個周期包括四個階段：開始階段、確立階段、構建階段和移交階段。正如上文已經討論的，每個階段可以進一步劃分為多次迭代。
產品每個生命期都產生系統的一個新版本，而每個版本是一個能立即推向市場的產品。它包括體現在組件中的可被編譯和執行的源代碼，還有說明手冊及其他可交付的相關產品。然而，最終產品也必須符合相關需要，此種需要并不僅僅是指用戶的需要，而且指所有利益關聯人的需要，也就是指那些將利用該產品來進行工作的所有人。軟件產品應當不僅僅只是可執行的機器代碼。
最終產品包括需求、用例、功能性需求和測試案例。它包括基本架構和可視模型( 由統一建模語言構摸
的產物) 。事實上，它包括我們正在這里討論的所有元素，因為它正是所有利益關聯人（包括客戶、用戶、分析人員、設計人員、實現人員、測試人員和管理人員）要詳細定義、設計、實現、測試和使用一個系統所需要的東西。此外，正是這些東西，才使得利益關聯人能使用并逐代修改系統 。
即使在用戶看來，可執行組件是最重要的產物，但是，僅僅有這些產物是不夠的。這是因為環境會不
斷發生變化。操作系統、數據庫系統和作為系統基礎的機器在不斷發展。隨著任務被更好地理解，需求本身也會發生變化。事實上，需求不斷發生變化是軟件開發領域里的諸常量之一。這樣，開發人員就必須開始一個新的開發生命期，管理人員則必須為之提供資金。為了有效地實施下一個生命期，開發人員需要該軟件產品的所有表現形式
ω 用例模型，這個模型表明了所有用例和這些用例與用戶之間的關系
ω 分析模型，該模型有兩個目的：更加詳盡地細化用例，以及將系統的行為初步分配給一組提供這些
行為的對象。
ω 設計模型，該模型（a ）以子系統、類和接口的形式定義系統的靜態結構，（b ）以子系統、類和接口
之間的協作來定義用例的實現。
ω 實現模型，該模型包括組件（代表源代碼）和類向組件的映射。
ω 配置模型，該模型定義計算機的物理節點和組件向這些節點的映射。
ω 測試模型，該模型描述那些用來驗證用例的測試實例。
ω 還包括基本架構的表示。
系統還應當有一個域模型或業務模型來描述系統的業務上下文。
所有這些模型都是彼此相關的。它們一起表達了整個系統。在一個模型中的元素可向前或向后追溯到
其它模型中。例如，（用例模型中的）一個用例可以被追溯到（設計模型中的）一項用例實現，再追溯到（測試模型中的）一個測試案例�？勺粉櫺杂欣诶斫夂吞幚碜兓� 。
一個生命期中的諸階段一個生命期中的諸階段一個生命期中的諸階段一個生命期中的諸階 段
每個生命期都持續一段時間。這段時間反過來又可以分成四個階段（見下圖 ）。通過一系列的模型，利益相關人可以直觀地看到這些階段的進展狀況。在每個階段中，經理人員或開發人員還可能進一步對工作進行細分：分成多次迭代并確保增量。每個階段都結束于一個里程碑。我們以一組獲得的成果來定義每個里程碑。亦即特定的模型或者文檔已經達到了預定的狀態。
里程碑用于許多目的。最重要的是，在工作進入下一個階段之前，管理人員必須作出某些關鍵決策。
里程碑還能幫助管理人員以及開發人員在開發工作經過這四個關鍵點時監控工作進度。最后，通過對每個階段上花費的時間和精力進行追蹤，我們還能獲得一組數據。這些數據在評估其他項目需要多少時間和人員、計劃項目期間內需要的項目人員和根據這個計劃來控制工作進度上是非常有用的 。
下圖左邊一欄列出了工作流程——需求、分析、設計、實現和測試。曲線大致（不能認為此種曲線就完全代表了實際情況）表示了每個階段中工作流程被執行的內容。注意，每個階段通常都被分解為迭代或稱小項目。如圖中的確立階段所示，一次典型的迭代要經歷全部五個工作流程。
在開始階段，一個好的理念被開發成對最終產品的設想，并且該產品應用的業務用例被提出來。最重要的是，這個階段回答了如下問題 ：
ω 這個系統將為其每個主要用戶做些什么？
ω 該系統的基本架構應是什么樣子 ？
ω 開發這個產品的計劃是什么，費用是多少？
包括最關鍵的用例的一個簡化的用例模型回答了第一個問題。在這個階段，基本架構還是試驗性的，
通常它只是一個包括關鍵子系統的輪廓而已。在這個階段，最重要的風險被確認，并按優先次序進行了排列；對確立階段進行詳細的計劃；對整個系統進行粗略的評估。
在確立階段，產品中的大部分用例被詳細地定義下來，系統基本架構也被設計出來。系統的基本架構
和系統本身之間的關系是極為重要的。簡單地說，基本架構就像一個裹著皮膚但是肌肉很少的骨架：
只有一些能讓該骨架作一些基本運動的必要的肌肉。而系統則是由骨架、皮膚和肌肉組成的有機整體 。
因此，基本架構被表示為系統中所有模型的視圖，這些視圖共同表達了整個系統。這意味著，存在用
例模型、分析模型、設計模型、實現模型和配置模型的基本架構視圖。實現模型的視圖包括能證明基本架構是可執行的組件。在這個開發階段，在確立階段確定的最關鍵的用例被實現。這個階段的成果是基本架構基線 。
在確立階段的末期，項目經理要計劃活動并估算完成該項目需要的資源。在這里，關鍵的問題是，用
例、基本架構和計劃是否足夠穩定，風險是否已經處在有效控制之下，從而能夠提交合同中規定的整個開發工作？
在構建階段，產品被建構——肌肉（即完工的軟件）被添加到骨架（即基本架構）上。在這個階段，
基本架構基線已經成長為一個羽翼豐滿的系統。最初對產品的設想已經演化成了準備交付給用戶的一個產品。在這個開發階段，項目所需求的大部分資源被使用。盡管系統的基本架構是穩定的，但是，由于開發人員可能發現結構化系統的更好的方式，因此，他們可能會建議架構設計師對基本架構進行一些小修小補。
在這個階段的最后，產品已經包括了管理人員和客戶同意為這個產品開發的所有用例。然而，它可能不是完全沒有缺陷的。在移交階段，會發現并修正更多的缺陷。這個里程碑的問題是，該產品是否有效地滿足了客戶的需求，可以向某些客戶提前交付該產品？
移交階段是指產品發布測試版的階段。在測試版中，由少數有經驗的用戶來使用該產品，并報告他們
發現的缺陷和不足。開發人員則更正這些缺陷和不足，并將有些改進建議融入到向更大的用戶群發布的一般產品中。移交階段涉及諸如制造、培訓客戶人員、提供熱線幫助和修正產品發布后發現的缺陷等活動。
維護隊伍通常將這些缺陷劃分為兩類：那些對后續的正式版本的正常操作有一定的缺陷，和那些可以在下一個正式版本中更正的缺陷。
“統一過程”是基于組件的。它利用了新的可視建模標準UML ，并依賴于三個關鍵觀點：用例、基本
架構、迭代和增量開發。要使這些觀點可用，需求一個多層面的過程，該過程應當考慮到生命期、階段、工作流程、風險緩和、質量控制、項目管理和配置控制等�！敖y一過程”確立了一個集成了所有這些因素的框架。這個框架就像一把雨傘，在它下面，工具提供商和開發者可以構建工具來支持該過程的自動化、支持各個工作流程、構建所有不同的模型，并在整個生命期和所有的模型中集成這些工作 。
Date Jun 2000
環球互動www.globalempower.com
文章來源于領測軟件測試網 http://www.kjueaiud.com/
