2.3 信息系統開發模型

從軟件工程的角度來說，信息系統開發模型是指信息系統軟件開發全部過程、活動和任務的結構框架。軟件開發包括需求、設計、編碼和測試等階段，有時也包括維護階段。開發模型能清晰、直觀地描述軟件開發全過程，明確規定了要完成的主要活動和任務，是信息系統項目管理工作的基礎。

典型的開發模型有：瀑布模型、螺旋模型、增量模型、噴泉模型和原型模型等。

2.3.1 瀑布模型

1970年溫斯頓·羅伊斯（Winston Royce）提出了著名的“瀑布模型”，直到20世紀80年代早期，它一直是唯一被廣泛采用的軟件開發模型。

瀑布模型將軟件生命周期劃分為制訂計劃、需求分析、軟件設計、程序編寫、軟件測試和運行維護6個基本活動，并且規定了它們自上而下、相互銜接的固定次序，如同瀑布流水，逐級下落。從本質來講，它是一個軟件開發架構，開發過程是通過一系列階段順序展開的，從系統需求分析開始直到產品發布和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好“返回”上一個階段并進行適當的修改，開發進程從一個階段“流動”到下一個階段，這也是瀑布開發名稱的由來。

瀑布模型是最早出現的軟件開發模型，在軟件工程中占有重要的地位，它提供了軟件開發的基本框架。在瀑布模型中，軟件開發的各項活動嚴格按照線性方式進行，當前活動接收上一項活動的工作結果，利用這一輸入實施該項活動應完成的內容，給出該項活動的工作成果，并作為輸出傳給下一項活動。同時評審該項活動的實施，若確認，則繼續下一項活動；否則返回前面，甚至更前面的活動。對于經常變化的項目而言，瀑布模型毫無價值。

瀑布模型強調文檔的作用，并要求每個階段都要仔細驗證。采用瀑布模型的信息系統軟件開發過程，如圖2.2所示。

瀑布模型有以下優點。

（1）為項目提供了按階段劃分的檢查點。

（2）當前一階段完成后，只需要去關注后續階段。

（3）可在迭代模型中應用瀑布模型。

瀑布模型有以下缺點。

（1）在項目各個階段之間極少有反饋。

（2）只有在項目生命周期的后期才能看到結果。

（3）通過過多的強制完成日期和里程碑來跟蹤各個項目階段。

2.3.2 螺旋模型

1988年，Barry Boehm正式發表了軟件系統開發的“螺旋模型”，它將瀑布模型和快速原型模型結合起來，強調了其他模型所忽視的風險分析，特別適合于大型復雜的系統。

螺旋模型采用一種周期性的方法來進行系統開發，這會導致開發出眾多的中間版本。使用它，項目經理在早期就能夠為客戶實證某些概念。該模型是快速原型法，以進化的開發方式為中心，在每個項目階段使用瀑布模型法。這種模型的每個周期都包括需求定義、風險分析、工程實現和評審4個階段，由這4個階段進行迭代。軟件開發過程每迭代一次，軟件開發又前進一個層次，如圖2.3所示，圖中的4個象限代表了以下活動。

（1）制訂計劃：確定軟件目標，選定實施方案，弄清項目開發的限制條件。

（2）風險分析：分析評估所選方案，考慮如何識別和消除風險。

（3）實施工程：實施軟件開發和驗證。

（4）客戶評估：評價開發工作，提出修正建議，制訂下一步計劃。

沿螺線自內向外每旋轉一圈便開發出更為完善的一個新的軟件版本。例如，在第一圈，確定了初步的目標、方案和限制條件以后，轉入右上象限，對風險進行識別和分析。如果風險分析表明，需求具有不確定性，那么在右下的工程象限內，所建的原型會幫助開發人員和客戶，考慮其他開發模型，并把需求做進一步修正。客戶對工程成果做出評價后，給出修正建議。在此基礎上需再次計劃，并進行風險分析。在每圈螺線上，風險分析的終點做出是否繼續下去的判斷。假如風險過大，開發者和用戶無法承受，項目有可能終止。多數情況下沿螺線的活動會繼續下去，自內向外逐步延伸，最終得到所期望的系統。如果對所開發項目的需求已有了較好的理解或較大的把握，無需開發原型，便可采用普通的瀑布模型。這在螺旋模型中可認為是單圈螺線。與此相反，如果對所開發項目的需求理解較差，需要開發原型，甚至需要不止一個原型的幫助，那就要經歷多圈螺線。

螺旋模型由風險驅動，強調可選方案和約束條件從而支持軟件的重用，有助于將軟件質量作為特殊目標融入產品開發之中。螺旋模型基本做法是在“瀑布模型”的每個開發階段前引入一個非常嚴格的風險識別、風險分析和風險控制，它把軟件項目分解成一個個小項目。每個小項目都標志一個或多個主要風險，直到所有的主要風險因素都被確定。

螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險有所了解，繼而做出應有的反應，因此特別適用于龐大、復雜并具有高風險的系統。對于這類系統，風險是軟件開發不可忽視且潛在的不利因素，它可能在不同程度上影響軟件開發過程和軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別及分析，決定采取何種對策，進而消除或減少風險的損害。

與瀑布模型相比，螺旋模型支持用戶需求的動態變化，為用戶參與軟件開發的所有關鍵決策提供了方便，有助于提高目標軟件的適應能力。同時為項目管理人員及時調整管理決策提供了便利，從而降低了軟件開發風險。

螺旋模型有以下優點。

（1）設計上的靈活性，可以在項目的各個階段進行變更。

（2）以小的分段來構建大型系統，使成本計算變得簡單容易。

（3）客戶始終參與每個階段的開發，保證了項目不偏離正確方向及項目的可控性。

（4）隨著項目推進，客戶始終掌握項目的最新信息，從而他或她能夠和管理層有效地交互。

（5）客戶認可這種公司內部的開發方式帶來的良好的溝通和高質量的產品。

螺旋模型有以下缺點。

（1）采用螺旋模型需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時識別風險，則勢必造成重大損失。

（2）過多的迭代次數會增加開發成本，延遲提交時間。

2.3.3 增量模型

增量模型融合了瀑布模型的基本成分（重復應用）和原型實現的迭代特征，該模型采用隨著日程時間的進展而交錯的線性序列，每個線性序列產生軟件的一個可發布的“增量”。使用增量模型開發軟件時，把軟件產品作為一系列的增量構件來設計、編碼、集成和測試。每個構件由多個相互作用的模塊構成，并且能夠完成特定的功能。使用增量模型時，第一個增量構件往往實現軟件的基本需求，提供最核心的功能。例如，使用增量模型開發字處理軟件時，第一個增量構件提供基本的文件管理、編輯和文檔生成功能；第二個增量構件提供更完善的編輯和文檔生成功能；第三個增量構件實現拼寫和語法檢查功能；第四個增量構件完成高級的頁面排版功能。把軟件產品分解成增量構件時，應該使構件的規模適中，規模過大或過小都不好。最佳分解方法因軟件產品特點和開發人員的習慣而異。分解時唯一必須遵守的約束條件是，當把新構件集成到現有軟件中時，所形成的產品必須是可測試的。增量模型強調每個增量均發布一個可操作的產品。采用增量模型的軟件開發過程，如圖2.4所示。

采用瀑布模型或快速原型模型開發軟件時，目標都是一次就把一個滿足所有需求的產品提交給用戶。增量模型則與之相反，它分批地逐步向用戶提交產品，每次提交一個滿足用戶需求子集的可運行的產品。整個軟件產品被分解成許多個增量構件，開發人員一個構件接一個構件地向用戶提交產品。每次用戶都得到一個滿足部分需求的可運行的產品，直到最后一次得到滿足全部需求的完整產品。

增量模型描述了為系統需求排定優先級然后分組實現的過程，每個后續版本都為先前版本增加了新功能。在生命周期的早期階段（計劃、分析、設計），需要建立一個考慮整個系統的架構，這個架構應該是具有強的可集成性的，后續的構件方式開發，都是建立在這個架構之上的。剩下的生命周期階段（編碼、測試、交付），來實現每個增量。首先創建的應該是一組核心的功能，或者對于項目至關重要的最高優先級的系統，或者是能夠降低風險的系統。隨后基于核心功能反復擴展，逐步增加功能以提高性能。

采用增量模型的優點是人員分配靈活，剛開始不用投入大量人力資源。如果核心產品很受歡迎，則可增加人力實現下一個增量。當配備的人員不能在設定的期限內完成產品時，它提供了一種先推出核心產品的途徑。這樣即可先發布部分功能給客戶，對客戶起到鎮靜劑的作用。此外，增量能夠有計劃地管理技術風險。增量模型的缺點是如果增量構件之間存在相交的情況且未很好處理，則必須做全盤系統分析。

2.3.4 噴泉模型

噴泉模型是一種以用戶需求為動力，以對象為驅動的模型，主要用于描述面向對象的軟件開發過程。噴泉模型認為軟件自下而上周期的各階段是相互重疊和多次反復的，就像水噴上去可以落下來，既可以落在中間，也可以落在底部，類似一個噴泉。各個開發階段是沒有特定的次序要求的，并且是可以交互進行的，可以在某個開發階段中隨時補充其他任何開發階段中的遺漏。采用噴泉模型的軟件開發過程，如圖2.5所示。

該模型認為軟件開發過程自下而上周期的各階段是相互迭代和無間隙的。軟件的某個部分常常被重復工作多次，相關對象在每次迭代中隨之加入漸進的軟件成分。無間隙指在各項活動之間無明顯邊界，如分析和設計活動之間沒有明顯的界限，由于對象概念的引入，表達分析、設計、實現等活動只用對象類和關系，從而可以較為容易地實現活動的迭代和無間隙，使其開發自然地包括復用。

噴泉模型不像瀑布模型那樣，需要分析活動結束后才開始設計活動，設計活動結束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發人員可以同步進行開發。其優點是可以提高軟件項目開發效率，節省開發時間，適應于面向對象的軟件開發過程。由于噴泉模型在各個開發階段是重疊的，因此在開發過程中需要大量的開發人員，所以不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。

2.3.5 快速原型模型

快速原型模型又稱原型模型。原型本是工程設計中的概念，指的是試制品或樣品。軟件開發中的原型是軟件的一個早期可運行的版本，它反映了最終系統的重要特征，包括系統的功能特征、輸入/輸出特征和目標約束條件。快速原型是利用原型輔助軟件開發的一種思想。經過簡單快速分析，快速實現一個系統原型，用戶與開發者在試用原型過程中加強通信與反饋，通過反復評價和改進原型，減少誤解，彌補漏洞，適應變化，最終得到高質量的軟件。

由于在需求分析階段很難得到完全、一致、準確、合理的需求說明，在獲得一組基本需求說明后，就快速地使其“實現”，通過原型反饋，加深對系統的理解，并滿足用戶基本要求，使用戶在試用過程中受到啟發，對需求說明進行補充和精確化，消除不協調的系統需求，逐步確定各種需求，從而獲得合理、協調一致、無歧義的、完整的、現實可行的需求說明。同時把快速原型思想用到軟件開發的其他階段，向軟件開發的全過程擴展，即先用相對少的成本和較短的周期開發一個簡單的、但可以運行的系統原型向用戶演示或讓用戶試用，以便及早澄清并檢驗一些主要設計策略，在此基礎上再開發出實際的軟件系統。

原型模型的開發步驟如下。

1）確認基本需求

在分析員和用戶的緊密配合下，快速確定軟件系統的基本要求。例如，對系統功能、性能的基本要求，實現這些要求的數據規范、輸出報表、統計要求等。這一階段與生命周期模型的系統分析階段相似，但這里強調對最基本、最重要的用戶需求進行分析和說明，并非對全部需求進行詳細分析。

2）開發一個可運行的系統原型

在第一階段的基礎上，開發一個初始的系統原型，這個原型能完成系統的主要功能，具有系統的輸入/輸出特征，能反映出系統的目標和約束條件。可忽略最終系統在某些細節上的要求，如安全性、健壯性、異常處理等。主要考慮原型系統應充分反映待評價的特性，暫時忽略一切次要的內容。為使開發出來的原型能工作，還必須建立裝有實驗數據的樣本庫。為了快速地建立系統原型，并且適應后階段對原型的頻繁修改，需要有高效率的研制工具的支持，例如，采用非常高級的語言實現原型，引入以數據庫為核心的開發工具等。

3）試用原型

這是發現問題、消除誤解、開發者與系統用戶充分協調的一個步驟。開發人員向用戶演示原型后，讓用戶親自試用，進一步發現問題和不足，通過交流和討論，確定需要修改變動的部分，這樣第一階段確定的基本需求就得到進一步明晰和精確。它必須通過所有相關人員的檢查、評價和測試。

由于原型忽略了許多內容，它集中反映了要評價的特性，外觀看起來可能會有些殘缺不全。用戶要在開發者的指導下試用原型，在試用的過程中考核評價原型的特性，分析其運行結果是否滿足規格說明的要求，以及規格說明的描述是否滿足用戶的愿望。糾正過去交互中的誤解和分析中的錯誤，增補新的要求，并為滿足因環境變化或用戶的新設想而引起系統需求的變動而提出全面的修改意見。

4）修改原型

根據修改意見對原型進行修改與完善，即舍棄不符合要求的部分，增加所需的功能，滿足用戶提出的新要求，使原型逐步完善。

在修改原型的過程中會產生各種各樣積極的或消極的影響，為了控制這些影響，應當有一個詞典，用以定義應用的數據流，以及各個系統成分之間的關系。另外，在用戶積極參與的情況下，保留改進前后的兩個原型，一旦用戶需要時可以退回，而且貫穿地演示兩個可供選擇的對象，有助于決策。

5）重復3）、4）階段

修改過的原型給用戶再度使用和評價，提出意見，再修改，如此反復，直至達到參與者一致認可，則原型開發的迭代過程可以結束。

6）完善原型與重建系統

針對5）階段產生的原型，有兩種不同的處理方式。

（1）進一步完善原型使其成為最終產品。雖然此時的原型能夠正確地反映用戶需求，完成系統功能，但有可能還存在一些被忽略的問題，例如，還需加入系統安全可靠性的控制，數據完整性和一致性的控制，通過模塊結構和算法的優化來進一步提高系統運行效益，增強系統的容錯性與糾錯能力，提高系統的可讀性和可維護性等，這樣原型才能成為真正實用的系統。

（2）重建系統。第一種方式通過完善原型得到最終產品，有開發速度快的優點，但原型模型的增量開發方式使系統結構不理想，可維護性差。對較大的系統采用重建系統方式，把獲得原型的過程當做生命周期模型的系統分析階段，所做的工作只是為系統設計提供經過驗證的需求分析，接下來按照生命周期模型繼續進行系統設計、編碼和測試等開發階段，重建一個結構更為合理的系統，而將原型丟棄不用。因此，原型系統的內部結構并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。

同生命周期模型相比較而言，原型模型具有如下特點。

（1）用戶參與了系統開發的所有階段，從而使用戶的需求可以及時地、較好地得到滿足，系統的實用性強。而在生命周期模型中，用戶只介入了需求分析階段，其他階段只是開發人員“單干”，因此有可能造成最終系統問題很多，不能投入實際使用。

（2）采用原型模型，用戶可以及早接觸和使用未來系統的原型，有利于今后的使用和維護，而生命周期模型往往需要經過幾個月甚至幾年的開發時間，用戶才能見到最終系統。

（3）原型模型開發軟件，其周期大為縮短，開發費用較少，而生命周期模型的特點是周期長、費用高。

2.3.6 基于構件的開發模型

基于構件的開發模型是利用模塊化方法將整個軟件系統模塊化，并在一定構件模型的支持下復用構件庫中的一個或多個軟件構件，通過組合手段高效率、高質量地構造應用軟件系統的過程。基于構件的開發模型融合了螺旋模型的許多特征，本質上是演化形成的，開發過程是迭代的。

基于構件的開發模型由軟件的需求分析和定義、體系結構設計、構件庫建立、應用軟件構建，以及測試和發布5個階段組成，采用這種開發模型的軟件開發過程，如圖2.6所示。

構件作為重要的軟件技術和工具得到極大的發展，這些新技術和工具有Microsoft的DCOM、Sun的EJB，以及OMG的CORBA等。基于構件的開發活動從標志候選構件開始，通過搜查已有構件庫，確認所需要的構件是否已經存在。如果已經存在，則從構件庫中提取出來復用；否則采用面向對象方法開發它。之后利用提取出來的構件通過語法和語義檢查后將這些構件通過膠合代碼組裝到一起實現系統，這個過程是迭代的。

基于構件的開發方法使得軟件開發不再一切從頭開發，開發的過程就是構件組裝的過程，維護的過程就是構件升級、替換和擴充的過程。其優點是構件組裝模型導致了軟件的復用，提高了軟件開發的效率。構件可由一方定義其規格說明，被另一方實現。然后供給第三方使用，構件組裝模型允許多個項目同時開發，降低了費用，提高了可維護性，可實現分步提交軟件產品。

由于采用自定義的組裝結構標準，缺乏通用的組裝結構標準，所以引入了較大的風險。可重用性和軟件高效性不易協調，需要精干的有經驗的分析和開發人員，一般開發人員不介入。客戶的滿意度低，并且由于過分依賴于構件，所以構件庫的質量影響著產品質量。

2.3.7 基于體系結構的開發模型

基于體系結構的開發模型是以軟件系統的體系結構為核心，以基于構件的開發方法為基礎，然后采用迭代增量方式進行分析和設計，將功能設計空間映射到結構設計空間，再由結構設計空間映射到系統設計空間的過程。該開發模型把軟件生命周期分為軟件定義、需求分析和定義、體系結構設計、軟件系統設計和軟件實現5個階段，采用這種開發模型的軟件開發過程，如圖2.7所示。

在基于體系結構的開發過程中，首先進行基于體系結構的需求獲取和分析，將軟件體系結構的概念引入到需求空間，從而為分析階段到設計階段的過渡提供更好的支持。在需求分析結果的基礎上，進行體系結構的設計。考慮系統的總體結構及系統的構成元素，根據構成元素的語法和語義在已確定的構件庫中尋找匹配的構件。當不存在符合要求的構件時，則根據具體情況組裝合成新構件或購買新構件或根據需要開發新構件而得到滿足需求的構件。在經過語法和語義檢查后，將這些構件通過膠合代碼組裝到一起實現整個軟件系統。在實踐中，整個開發過程呈現多次迭代性。

在傳統的軟件生命周期中，軟件需求分析和定義完成后是軟件系統的設計和實現。在這種傳統的開發方法中，如果軟件需求不斷變化，最終軟件產品可能與初始原型相差很大。而基于體系結構的開發模型有嚴格的理論基礎和工程原則，是以體系結構為核心的。體系結構為軟件需求與軟件設計架起了一座橋梁，解決了軟件系統從需求到實現的平緩過渡，提高了軟件分析設計的質量和效率。

基于體系結構的開發模型的優點是通過對體系結構的設計，使得軟件系統結構框架更清晰，有利于系統的設計、開發和維護，并且軟件復用從代碼級的復用提升到構件和體系結構級的復用。

基于體系結構的開發模型和基于構件的開發模型都是在體系結構的基礎上進行構件的組裝而得到軟件系統，前者主要關注運行級構件及其之間的互操作性，提供了一種自底向上且基于預先定制好的構件來構造應用系統的途徑；后者局限在構件的規范上，缺少系統化的指導開發過程的方法學。基于體系結構的開發方法從系統的總體結構入手，將一個系統的體系結構顯示化，以在高抽象層次處理如全局組織和控制結構、功能到計算元素的分配、計算元素間的高層交互等設計問題。

2.3.8 RUP

RUP（Rational Unified Process）是Rational公司推出的軟件過程模型，它是一個面向對象軟件工程的通用業務流程。RUP描述了一系列相關的軟件工程流程，它們具有相同的結構，即相同的流程構架。RUP是軟件業界迄今為止商品化最成功的軟件過程模型。

RUP可以用二維坐標來描述，如圖2.8所示。橫軸通過時間組織，是過程展開的生命周期特征，體現開發過程的動態結構，用來描述它的術語主要有周期（Cycle）、階段（Phase）、迭代（Iteration）和里程碑（Milestone）；縱軸以內容組織自然的邏輯活動，體現開發過程的靜態結構，用來描述它的術語主要有活動（Activity）、產物（Artifact）、工作者（Worker）和工作流（Workflow）。在時間軸上，RUP劃分了4 個階段：初始階段（Inception）、細化階段（Elaboration）、構造階段（Construction）和交付階段（Transition）。每個階段結束于一個主要的里程碑（Major Milestones）；每個階段本質上是兩個里程碑之間的時間跨度。在每個階段的結尾執行一次評估以確定這個階段的目標是否已經滿足。如果評估結果令人滿意，則可以允許項目進入下一個階段。每個階段都使用了迭代的概念。在工作流軸上，RUP設計了6個核心過程工作流和3個核心支持工作流。核心過程工作流包括：業務建模工作流、需求工作流、分析和設計工作流、實現工作流、測試工作流和發布工作流。核心支持工作流包括：環境工作流、項目管理工作流及配置和變更管理工作流。

初始階段：定義最終產品視圖、業務模型并確定系統范圍。

細化階段：設計及確定系統的體系結構，制訂工作計劃及資源要求。

構造階段：構造產品并繼續演進需求、體系結構、計劃直至產品提交。

交付階段：把產品提交給用戶使用。

初始階段結束時是第一個重要的里程碑：生命周期目標（Lifecycle Objective）里程碑。生命周期目標里程碑評價項目基本的生存能力。細化階段結束是第二個重要的里程碑：生命周期結構（Lifecycle Architecture）里程碑。生命周期結構里程碑為系統的結構建立了管理基準并使項目小組能夠在構建階段中進行衡量。此時，要檢驗詳細的系統目標和范圍、結構的選擇及主要風險的解決方案。構造階段結束時是第三個重要的里程碑：初始功能（Initial Operational）里程碑。初始功能里程碑決定了產品是否可以在測試環境中進行發布。此時，要確定軟件、環境、用戶是否可以開始系統的運作。此時的產品版本也常被稱為“beta”版。在交付階段的終點是第四個里程碑：產品發布（Product Release）里程碑。此時，要確定目標是否實現，是否應該開始另一個開發周期。在一些情況下這個里程碑可能與下一個周期的初始階段的結束重合。

9個核心工作流在項目中輪流被使用，在每次迭代中以不同的重點和強度重復。工作流的目的簡單描述如下。

業務建模（Business Modeling）：理解待開發系統的組織結構及其商業運作，確保所有參與人員對待開發系統有共同的認識。

需求（Requirements）：定義系統功能及用戶界面，使客戶知道系統的功能，開發人員知道系統的需求，為項目預算及計劃提供基礎。

分析和設計（Analysis and Design）：把需求分析的結果轉化為實現規格。

實現（Implementation）：定義代碼的組織結構、實現代碼、單元測試和系統集成。

測試（Test）：校驗各自子系統的交互與集成。確保所有的需求被正確實現并在系統發布前發現錯誤。

發布（Deployment）：打包、分發、安裝軟件，升級舊系統；培訓用戶及銷售人員，并提供技術支持；制定并實施beta測試。

配置和交更管理（Configuration and Change Management）：跟蹤并維護系統所有產品的完整性和一致性。

項目管理（Project Management）：為計劃、執行和監控軟件開發項目提供可行性的指導；為風險管理提供框架。

環境（Environment）：為組織提供過程管理和工具的支持。

RUP中的每個階段可以進一步分解為迭代。一個迭代是一個完整的開發循環，產生一個可執行的產品版本，是最終產品的一個子集，它增量式地發展，從一個迭代過程到另一個迭代過程直到成為最終的系統。傳統上的項目組織是順序通過每個工作流，每個工作流只有一次，也就是人們熟悉的瀑布生命周期。這樣做的結果是，到實現末期產品完成并開始測試，在分析、設計和實現階段所遺留的隱藏問題會大量出現，項目可能要停止并開始一個漫長的錯誤修正周期。

一種更靈活、風險更小的方法是多次通過不同的開發工作流，這樣可以更好地理解需求，構造一個健壯的體系結構，并最終交付一系列逐步完成的版本。這稱為一個迭代生命周期。在工作流中的每次順序的通過稱為一次迭代。軟件生命周期是迭代的連續，通過它，軟件是增量的開發。一次迭代包括了生成一個可執行版本的開發活動，還有使用這個版本所必需的其他輔助成分，如版本描述、用戶文檔等。因此一個開發迭代在某種意義上是在所有工作流中的一次完整的經過，這些工作流至少包括：需求工作流、分析和設計工作流和實現工作流和測試工作流。其本身就如同一個小型的瀑布項目（見圖2.9）。

RUP有以下優點。

（1）RUP是建立在非常優秀的軟件工程原則基礎上的，如迭代、需求驅動、基于結構化的過程開發。

（2）RUP提供了幾種方法，如每次迭代產生一個工作原型，在每個階段的結束決定項目是否繼續，這些方法提供了對開發過程非常直觀的管理。

（3）Rational公司已經并將繼續對RUP進行開發，使這個基于HTML的軟件工程能夠被裁減以適合組織的實際需要。

RUP有以下缺點。

（1）RUP僅僅包含了開發過程。它沒有完全覆蓋軟件過程，從圖2.9中能夠明顯看出，它丟失了維護和技術支持這兩個重要的階段。

（2）RUP不支持組織內的多項目開發，導致組織內的大范圍的重用無法實現。

（3）RUP缺少開發商的支持。

（4）RUP在度量管理，重用管理，人員管理和測試方面尚存在缺陷。