摘 要 本文從軟件生命周期出發(fā)，介紹統(tǒng)一過程的各階段、特點、優(yōu)缺點及適用范圍。

關(guān)鍵詞統(tǒng)一過程，軟件生命周期

中圖分類號TP3 文獻標識碼A文章編號1673-9671-(2009)121-0009-01

1統(tǒng)一過程

軟件開發(fā)過程圍繞著五個工作流構(gòu)建:需求流、分析流(規(guī)格說明)、設(shè)計流、實現(xiàn)流和測試流。統(tǒng)一過程是一個階段化了的模型，識別出軟件過程當中的四個獨立階段RUP中的階段是緊密關(guān)聯(lián)于業(yè)務的，而不是關(guān)聯(lián)于技術(shù)層面。統(tǒng)一過程中的階段如圖1所示。

1)開始階段。開始階段的目標是建立系統(tǒng)的一個業(yè)務案例。要識別出所有與系統(tǒng)交互的外部實體(人和系統(tǒng))并定義這些交互。然后使用這個信息來評估系統(tǒng)對業(yè)務的貢獻。如果這個貢獻是微小的，那么項目就要在此階段結(jié)束時取消了。2)細化階段。細化階段的目標是增進對問題域的理解，建立系統(tǒng)的體系框架，給出項目計劃并識別關(guān)鍵項目風險。在這個階段完成時，可以得到系統(tǒng)的需求模型(描述了UML用例)，這是軟件的一個體系結(jié)構(gòu)描述和開發(fā)計劃。3)構(gòu)建階段。構(gòu)建階段主要關(guān)心的是系統(tǒng)設(shè)計、編程和測試。系統(tǒng)的各個部分在并行開發(fā)，再集成在一起。在這個階段完成時，可以得到一個能運行的軟件系統(tǒng)，還有能交付給用戶的相關(guān)文檔。4)轉(zhuǎn)換階段。統(tǒng)一過程的最后階段，關(guān)注如何將系統(tǒng)從開發(fā)單位轉(zhuǎn)移到用戶單位，并使之在真實環(huán)境中工作。這是被絕大多數(shù)軟件過程模型所忽視的一個階段，而這個階段事實上是一個代價很高且有時問題很大的活動。在此階段完成時，可以得到一個在操作環(huán)境下能正常工作的軟件系統(tǒng)及其文檔。

2統(tǒng)一過程的實施步驟

統(tǒng)一過程的一個基本的規(guī)則是:在各種工作流的活動中，工作是以一種迭代的方式進行和測試工作流。在構(gòu)建階段可應用的工作流有需求工作流、分析工作流、設(shè)計工作流、實現(xiàn)工作流和測試工作流。

1)需求工作流。需求工作流的目標是讓軟件開發(fā)組織確定客戶的需求。開發(fā)小組的第一個任務是對應用領(lǐng)域即將要運行目標軟件的特定的環(huán)境獲得一個基本的了解。在過程的任何階段，只要用戶不再相信該軟件產(chǎn)品的代價是合理的，開發(fā)就會立即停止。因此，進行軟件開發(fā)的一個關(guān)鍵就是商業(yè)模型，它是一個目標產(chǎn)品代價合理的文檔。

2)分析工作流。分析工作流的目標是分析和提取需求，以獲得正確開發(fā)一個軟件產(chǎn)品和易于維護它所必需的需求。其關(guān)鍵是需求流的輸出必須能夠完全被客戶所理解，即需求流的制品必須用用戶的語言表達。當使用統(tǒng)一過程的時候，沒有通常意義上的規(guī)格說明文檔，而是向用戶展示一組UML制品，這些UML圖標及其描述能夠避免許多傳統(tǒng)規(guī)格說明文檔的問題。

當用戶批準規(guī)格說明文檔之后，就可以開始準備制訂軟件項目管理計劃。該計劃的主要組成部分有可交付的東西、交付的時間以及預算，計劃盡可能詳細地描述了整個軟件過程。計劃應該包括要使用的生命周期模型，開發(fā)組織的組織結(jié)構(gòu)，項目職責，管理目標和優(yōu)先權(quán)，使用的技術(shù)和CASE工具，以及詳細時間表、預算和資源分配。整個計劃的實質(zhì)是對開發(fā)周期和成本的估計。

3)設(shè)計工作流。設(shè)計流的目標是細化分析流的制品，直至材料處于程序員可實現(xiàn)的形式。在傳統(tǒng)設(shè)計階段，設(shè)計小組確定產(chǎn)品的內(nèi)部結(jié)構(gòu)。設(shè)計人員將產(chǎn)品分解成模塊，詳細定義每個模塊的接口。設(shè)計小組完成模塊化分解后，開始實施詳細設(shè)計，為每個模塊選擇相應的算法和數(shù)據(jù)結(jié)構(gòu)。如果是面向?qū)ο蠓椒?，其基礎(chǔ)是類，把類看作是一類特殊類型的模塊，在分析流期間提取類，在設(shè)計流期間設(shè)計類。

4)實現(xiàn)工作流。實現(xiàn)工作流的目標是用選擇的實現(xiàn)語言實現(xiàn)目標軟件產(chǎn)品。小型軟件產(chǎn)品有時由設(shè)計者實現(xiàn)，而大型軟件產(chǎn)品被劃分成較小的子系統(tǒng)由多個編碼小組并行實現(xiàn)，子系統(tǒng)由組件或代碼制品組成，分別由單個程序員實現(xiàn)。

5)測試工作流。在統(tǒng)一過程中，測試從始至終是與其他工作流并行進行。對于測試，軟件人員要對開發(fā)或維護的每個軟件制品進行測試或再測試，一旦軟件人員確認一個制品是正確的就將它交給軟件質(zhì)量保證小組進行獨立測試。每個組件在實現(xiàn)的同時應該對它進行測試，并在實現(xiàn)之后要對它運行測試用例和代碼評審。之后必須將它與其它編碼后的組件結(jié)合起來，以便能夠確定該部分產(chǎn)品整體上功能是否正確。當全部組件都編碼和集成完畢，進行產(chǎn)品測試。依照規(guī)格說明對產(chǎn)品功能進行整體測試，特別是要對規(guī)格說明中列出的約束條件進行測試。不僅必須測試產(chǎn)品的正確性，還需要測試產(chǎn)品的健壯性。集成測試的最后一方面測試時驗收測試。軟件交付給用戶之前，客戶使用與測試數(shù)據(jù)不同的真實數(shù)據(jù)，在實際的硬件上對產(chǎn)品進行測試。

為了確保過程改進的質(zhì)量，不論采用何種改進模式，都需要遵循以下原則:(1)改進的基礎(chǔ):軟件過程改進是建立在過程評價和過程度量的結(jié)果基礎(chǔ)之上的;(2)過程評價:產(chǎn)生當前過程能力的結(jié)果，用于同軟件企業(yè)的需求和業(yè)務目標進行比較，應適當?shù)刂貜蛙浖^程評價活動，以便確認所作的改進是否達到了預定的目標;(3)過程度量:用于對改進過程進行監(jiān)控，以便及時對改進活動做必要的調(diào)整，幫助識別和優(yōu)化改進活動，以支持軟件企業(yè)滿足業(yè)務目標的要求;(4)改進是一個持續(xù)的過程:預先制定的每一個改進目標都應當與企業(yè)統(tǒng)一制定的過程改進規(guī)劃相一致，并且不斷按照計劃實加扎監(jiān)控效果這樣的周期進行;(5)重視每個改進活動:將改進活動本身當作一個過程改進項目來完成;(6)降低風險:慎重考慮因改進活動的不完備和改進目標的不適合而帶來的風險。

不是所有軟件都可采用統(tǒng)一過程進行開發(fā)的，統(tǒng)一過程要求所適用的軟件項目具有如下特點:在項目開發(fā)早期需求可能有所變化;分析設(shè)計人員對應用領(lǐng)域很熟悉;高風險項目;用戶可不同程度地參與整個項目的開發(fā)過程;使用面向?qū)ο蟮恼Z言或UML;使用CASE工具，如Rose;具有高素質(zhì)的項目管理者和軟件研發(fā)團隊。統(tǒng)一過程要求的條件非?？量痰模鯇W者不要隨便使用。該模型一般用在中小型應用軟件的開發(fā)上，系統(tǒng)軟件的開發(fā)很少采用統(tǒng)一過程模型。

參考文獻

[1]張海藩.軟件工程導論[M].北京:清華大學出版社，2005.

[2]梁穎紅.軟件工程理論與實踐[M].哈爾濱:哈爾濱工業(yè)大學出版社，2008.

[3]齊治昌，譚慶平，寧洪.軟件工程[M].北京:高等教育出版社，2001，