軟件過程(Software Process)是人們建立、維護和進化軟件產品整個過程中所有技術活動和管理活動的集合 [1]。目前，軟件過程技術是一個非�；钴S的研究領域，吸引了大批來自學術界和工業界的專家和學者。從1984年起每年有軟件過程國際研討會(ISPW)，從1991年起開始召開軟件過程國際會議(ICSP)，每個國家幾乎都有自己的軟件過程改進網絡(SPN)。軟件過程技術的研究主要有三個方向：
(1)軟件過程分析和建模。軟件過程建模方法是軟件過程技術的起點，其中形式化半形式化建模方法有基于規則的，基于過程程序的等等。過程分析和過程建模對于保證過程定義的質量、建立全面和靈活的過程體系具有重要的作用。
(2)軟件過程支持。軟件過程支持主要是指研究和開發支持軟件過程活動的CASE工具，過程支撐工具作為一種技術基礎設施能夠很好地支持、管理并規范化軟件過程。軟件過程支持工具主要包括軟件過程流程工具、過程文擋工具、評審工具和人員管理工具。
(3)軟件過程評估和改進。軟件過程改進對生產高質量軟件產品和提高軟件生產率的重要性已被越來越多的軟件開發組織所認同。由美國卡耐基·梅隆大學軟件工程研究所(CMU/SEI)提出的軟件能力成熟度模型(SW-CMM)除了用于軟件過程評估外，還向軟件組織提供了指導其進行軟件過程管理和軟件過程改進的框架。
Rational Unified Process(RUP)是Rational軟件公司的一個軟件過程產品，是由Objectory過程演化而來的，其初始版本為5。0，先后經歷了5。1、5。1。1、5。5等版本直到最新的Rational Unified Process 2000版本。RUP將項目管理、商業建模、分析與設計等統一起來，貫穿整個開發過程。RUP采用Internet技術，可以增強團隊的開發效率，并為所有成員提供最佳的軟件實現方案，它使團隊中每個開發人員的見解和思想得到統一，使開發小組成員的溝通更為容易，而這正是任何項目要取得成功的關鍵因素;它可以增強開發人員對軟件的預見性，最終的好處就是提高了軟件質量，并有效縮短了軟件從開發到投放市場的時間。RUP過程為軟件開發提供了規范性的指南、模板和范例，可用來開發所有類型的應用。
本文的第2節討論基于RUP的軟件過程，第3節給出一個應用實例，第4節是本文的結論。
2 基于RUP的軟件過程
RUP中的軟件過程在時間上被分解為四個順序的階段，分別是初始階段(Inception)、細化階段(Elaboration)、構建階段(Construction)和交付階段(Transition) [2]。每個階段結束時都要安排一次技術評審，以確定這個階段的目標是否已經滿足。如果評審結果令人滿意，就可以允許項目進入下一個階段�；赗UP的軟件過程模型如圖1所示。
圖1 基于RUP的軟件過程
從圖1中可以看出，基于RUP的軟件過程是一個迭代過程。通過初始、細化、構建和提交四個階段就是一個開發周期，每次經過這四個階段就會產生一代軟件。除非產品退役，否則通過重復同樣的四個階段，產品將進化為下一代產品，但每一次的側重點都將放在不同的階段上。這些隨后的過程稱為進化過程。
用戶需求的變化、運行環境的變更、基礎技術方面的變更等都會引發進化過程。通常情況下，進化過程的初始階段和細化階段都比較簡單，因為基本產品定義和體系結構在前面的開發過程就已經決定。但也有例外情況，例如對軟件體系結構(Software Architecture)進行重新定義的進化過程。
2.1 初始階段
初始階段的任務是為系統建立業務模型并確定項目的邊界。在初始階段，必須識別所有與系統交互的外部實體，定義系統與外部實體交互的特性。在這個階段中所關注的是整個項目的業務和需求方面的主要風險。對于建立在原有系統基礎上的開發項目來說，初始階段可能很短。初始階段的實現過程如圖2所示。
圖2 初始階段子過程
(1)明確項目規模
建立項目的軟件規模和邊界條件，包括驗收標準;了解環境及重要的需求和約束，識別系統的關鍵用例(Use Case)。
(2)評估項目風險
軟件過程主要關心的是軟件開發的已知方面，只能準確描述、計劃、分配和評審那些已經知道將要完成的事情。風險管理則主要關心未知方面。在基于RUP的迭代式軟件過程中，很多決策要受風險決定。要達到這個目的，開發者需要詳細了解項目所面臨的風險，并對如何降低或處理風險有明確的策略。
(3)制訂項目計劃
估計整個項目的總體成本、進度和人員配備。綜合考慮備選體系結構，評估設計和自制/外購/重用方面的方案，從而估算出成本、進度和資源。在這個過程中，要通過對一些概念的證實來證明可行性，該證明可采用可模擬需求的模型形式或用于探索高風險區的初始原型。初始階段的原型設計工作應該限制在確信解決方案可行就可以了，具體實現留到細化階段和構建階段。
(4)階段技術評審
初始階段結束時要進行一次技術評審，檢查初始階段的目標是否完成，并決定繼續進行項目還是取消項目。在評審過程中，需要考慮項目的規模定義、成本和進度估算是否適中，估算根據是否可靠?需求是否正確，開發方和用戶方對軟件需求的理解是否達成一致?是否已經確定所有風險，并且有針對每個風險的規避策略等問題。
2.2 細化階段
細化階段的任務是分析問題領域，建立健全的體系結構基礎，淘汰項目中最高風險的元素。在細化階段，必須在理解整個系統的基礎上，對體系結構做出決策，包括其范圍、主要功能和諸如性能等非功能需求，同時為項目建立支持環境。細化階段的實現過程如圖3所示。
圖3 細化階段子過程
(1)確定體系結構
確保體系結構、需求和計劃足夠穩定，充分減少風險，從而能夠有預見性地確定開發所需的成本和開發進度。通過處理體系結構方面重要的場景(Scene)，建立一個已確定基線的體系結構。證明已建立基線的體系結構將在適當時間、以合理的成本支持系統需求。
(2)制訂構建階段計劃
為構建階段制訂詳細的過程計劃并為其建立基線。
(3)建立支持環境
建立支持環境，包括開發環境、開發流程、支持構建團隊所需的工具和自動化/半自動化支持。
(4)選擇構件
評估現有的(構件庫)和潛在構件，充分了解自制/外購/重用決策，以便有把握地確定構建階段的成本和進度。集成所選構件，并按主要場景進行評估。
(5)階段技術評審
評審時，需要檢驗詳細的系統目標和范圍、體系結構的選擇以及主要風險的解決方案。在技術評審中，需要考慮的問題有：
(1)產品需求是否穩定，體系結構是否是穩定的?
(2)可執行原型是否表明已經找到了主要的風險元素，并且得到妥善解決?
(3)構建階段的迭代計劃是否足夠詳細和真實， 是否有可靠的估算支持，可以保證工作繼續進行?
(4)所有與項目有關的人員是否一致認為，如果在當前體系結構環境中執行當前計劃來開發完整的系統，則當前的需求可以實現?
(5)實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受?
2.3 構建階段
在構建階段，要開發所有剩余的構件和應用程序功能，把這些構件集成為產品，并進行詳細測試。從某種意義上說，構建階段是一個制造過程，其重點放在管理資源及控制操作，以優化成本、進度和質量。
構建階段的主要任務是通過優化資源和避免不必要的報廢和返工，使開發成本降到最低;完成所有所需功能的分析、開發和測試，快速完成可用的版本;確定軟件、場地和用戶是否已經為部署軟件作好準備。
在構件階段，開發團隊的工作可以實現某種程度的并行。即使是較小的項目，也通常包括可以相互獨立開發的構件，從而使各團隊之間實現并行開發。這種并行性在較大幅度地加速開發進度的同時，也增加了資源管理和工作流程同步的復雜程度。
構建階段結束時也要進行技術評審，評審產品是否可以在β測試環境中進行安裝和運行。在評審中，需要考慮的問題有:
(1)該產品發布版是否足夠穩定和成熟，可安裝和運行在用戶的實際環境中?
(2)所有與項目有關的人員是否已準備好將產品發布給用戶?
(3)實際的資源耗費與計劃的耗費相比是否有偏差，該偏差是否可以接受?
2.4 交付階段
當基線已經足夠完善，可以安裝到最終用戶實際環境中時，則進入交付階段。交付階段的重點是確保軟件對最終用戶是可用的。
交付階段的主要任務是進行β測試，制作產品發布版本;對最終用戶支持文檔定稿;按用戶的需求確認新系統;培訓用戶和維護人員;獲得用戶對當前版本的反饋，基于反饋調整產品，如進行調試、性能或可用性的增強等。
根據產品的種類，交付階段可能非常簡單，也可能非常復雜。例如，發布現有桌面產品的新發布版可能十分簡單，而替換一個國家的航空交通管制系統可能就非常復雜。
交付階段結束時也要進行技術評審，評審目標是否實現，是否應該開始進化過程，用戶對交付的產品是否滿意等。
2.5 技術評審
在每個階段結束時都要進行一次技術評審，以確定在完成該階段的最終迭代后是否應該讓項目進入下一階段。 技術評審要考慮的主要問題應該主要與項目管理有關，因為主要的技術問題應該已經在該階段的最終迭代以及隨后的活動中得到解決。技術評審的步驟如圖4所示。
圖4 技術評審的步驟
(1)安排評審會議日程
技術評審會議的參加者必須包括外部人員(用戶代表和領域專家)、項目的管理團隊(項目經理以及項目團隊各功能區域的團隊負責人)和項目評審委員會。
與會者一旦確定，就應安排會議的召開日期和時間，以便為與會者留出充足的準備時間，讓他們能夠評審有關材料。
(2)分發會議材料
在會議召開之前，應當將技術評審材料分發給評審人員。要在會議召開之前及早地將這些材料分發出去，讓評審人員有充足的時間對其進行審閱。
(3)召開評審會議
在會議期間， 評審人員主要關注狀態評估。在會議結束時，評審人員應作出是否批準的決定。 技術評審會議可能會得到以下結果之一：
(Ⅰ)階段被接受：評審委員會認為項目實現了該階段的預期目標，可以進入下一階段。
(Ⅱ)有條件接受：評審委員會同意項目可以進入下一階段，但必須先完成指定的糾正操作。如果發現的問題很少并且不是很重要，則客戶可能決定在項目團隊執行某些糾正操作的同時有條件地接受該產品。在這種情況下， 項目經理需要根據問題的重要性，或選擇開始新的迭代，以處理所出現的問題，或只是通過延長最終迭代來處理問題，二者的差異在于所需的計劃工作量。
(Ⅲ)階段不被接受：項目沒有實現該階段的預期目標，項目經理就可能必須開始另一次迭代，甚至項目經理無法決定對問題的解決方案，而需要由有關人員根據合同重新確定項目規�；蚪K止項目。
(4)記錄會議決定
在會議結束時應完成評審記錄，其中包括重要的討論或活動以及評審的結果。如果結果是"階段不被接受"，則應暫時安排一次后續復審。
3 應用實例
在為某水電廠開發的綜合信息管理系統中，我們全面采用了基于RUP的軟件過程。水電廠綜合管理信息系統是一個大型信息管理系統，其中包含運行管理、設備管理、安全管理、圖形開票、生產技術管理、行政管理、人事管理、技術臺帳管理、班組建設、學習培訓、系統維護等十多個模塊。不僅如此，系統還要與現有的某些監控設備接口，從中獲取數據。系統能對水電廠實行全面的運行管理，能及時對系統的信息作統計分析處理，能給管理者提供及時準確的數據，對水電廠的運行決策提供必要的依據。
在項目的初始階段，我們主要建立項目的軟件規模和邊界條件，明確用戶的需求，形成規格說明書，作為驗收標準。同時，估計了整個項目的總體成本和進度，評估了潛在的風險，作出了具有20%資源預留的項目計劃。最后，根據客戶要求，我們選擇了Rational Rose 2000作為分析和建模工具、Project 2000作為項目管理工具。系統開發工具采用Visual Studio 6。0，后臺數據庫管理系統采用MS SQL Server 7。0。
在項目的細化階段，我們根據實際需求，選擇了B/S和C/S混合的異構軟件體系結構。對一些關鍵性的算法，制作了探索型的原型。并在此基礎上，為構建階段制訂了詳細的迭代計劃。在構件的選擇方面，我們決定主要采用已有構件(我們曾經開發過變電站綜合管理信息系統)，對構件庫中沒有的構件，則重新開發。
在項目的構建階段，我們的主要任務是完成新構件的開發和測試，集成所有構件，進行集成測試。在這一階段，我們采用并行開發方式，大大地提高了開發效率。
在項目的交付階段，我們把經過集成測試的軟件制作安裝盤，安裝在水電廠，接受實際環境的測試。然后對有關用戶和維護人員進行培訓和指導。
在以上各階段結束時，我們都進行了階段技術評審。在評審中，我們不但按要求邀請了客戶代表，還邀請了第三方專家參與評審。
由于全面采用了基于RUP的軟件過程，規范了管理和開發流程，有效地控制了資源，該項目在沒有使用預留資源的情況下順利完成。在系統運行期間，根據水電廠的要求和我單位的商業戰略，我們又對該軟件進行了三次進化過程，最終由軟件項目過渡到一個產品�，F在，該軟件產品已經在全國的多個水電站使用，用戶反映良好。
4 結論
RUP在迭代的開發過程、需求管理、基于構件的體系結構、可視化軟件建模、驗證軟件質量及控制軟件變更等方面，針對所有關鍵的開發活動為每個開發成員提供了必要的準則、模板和工具指導。它建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。
本文討論了基于RUP的軟件過程，并把該過程應用于水電廠綜合管理信息系統的開發。與傳統的軟件過程相比較，基于RUP的軟件過程可以降低產品風險，規范管理和開發流程，有效地控制資源，提高開發效率。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
