一、六大經(jīng)驗(yàn)
迭代式開發(fā)。在軟件開發(fā)的早期階段就想完全、準(zhǔn)確的捕獲用戶的需求幾乎是不可能的。實(shí)際上,我們經(jīng)常遇到的問題是需求在整個軟件開發(fā)工程中經(jīng)常會改變。迭代式開發(fā)允許在每次迭代過程中需求可能有變化,通過不斷細(xì)化來加深對問題的理解。迭代式開發(fā)不僅可以降低項目的風(fēng)險,而且每個迭代過程以可以執(zhí)行版本結(jié)束,可以鼓舞開發(fā)人員。
管理需求。確定系統(tǒng)的需求是一個連續(xù)的過程,開發(fā)人員在開發(fā)系統(tǒng)之前不可能完全詳細(xì)的說明一個系統(tǒng)的真正需求。RUP描述了如何提取、組織系統(tǒng)的功能和約束條件并將其文檔化,用例和腳本的使用以被證明是捕獲功能性需求的有效方法。
基于組件的體系結(jié)構(gòu)。組件使重用成為可能,系統(tǒng)可以由組件組成?;讵?dú)立的、可替換的、模塊化組件的體系結(jié)構(gòu)有助于管理復(fù)雜性,提高重用率。RUP描述了如何設(shè)計一個有彈性的、能適應(yīng)變化的、易于理解的、有助于重用的軟件體系結(jié)構(gòu)。
可視化建模。RUP往往和UML聯(lián)系在一起,對軟件系統(tǒng)建立可視化模型幫助人們提供管理軟件復(fù)雜性的能力。RUP告訴我們?nèi)绾慰梢暬膶浖到y(tǒng)建模,獲取有關(guān)體系結(jié)構(gòu)于組件的結(jié)構(gòu)和行為信息。
驗(yàn)證軟件質(zhì)量。在RUP中軟件質(zhì)量評估不再是事后進(jìn)行或單獨(dú)小組進(jìn)行的分離活動,而是內(nèi)建于過程中的所有活動,這樣可以及早發(fā)現(xiàn)軟件中的缺陷。
控制軟件變更。迭代式開發(fā)中如果沒有嚴(yán)格的控制和協(xié)調(diào),整個軟件開發(fā)過程很快就陷入混亂之中,RUP描述了如何控制、跟蹤、監(jiān)控、修改以確保成功的迭代開發(fā)。RUP通過軟件開發(fā)過程中的制品,隔離來自其他工作空間的變更,以此為每個開發(fā)人員建立安全的工作空間。
二、統(tǒng)一軟件開發(fā)過程RUP的二維開發(fā)模型
RUP軟件開發(fā)生命周期是一個二維的軟件開發(fā)模型。橫軸通過時間組織,是過程展開的生命周期特征,體現(xiàn)開發(fā)過程的動態(tài)結(jié)構(gòu),用來描述它的術(shù)語主要包括周期(Cycle)、階段(Phase)、迭代(Iteration)和里程碑(Milestone);縱軸以內(nèi)容來組織為自然的邏輯活動,體現(xiàn)開發(fā)過程的靜態(tài)結(jié)構(gòu),用來描述它的術(shù)語主要包括活動(Activity)、產(chǎn)物(Artifact)、工作者(Worker)和工作流(Workflow)。如圖1:
三、統(tǒng)一軟件開發(fā)過程RUP核心概念
RUP中定義了一些核心概念,如下圖:
角色:描述某個人或者一個小組的行為與職責(zé)。RUP預(yù)先定義了很多角色。
活動:是一個有明確目的的獨(dú)立工作單元。
工件:是活動生成、創(chuàng)建或修改的一段信息。
四、統(tǒng)一軟件開發(fā)過程RUP裁剪
RUP是一個通用的過程模板,包含了很多開發(fā)指南、制品、開發(fā)過程所涉及到的角色說明,由于它非常龐大所以對具體的開發(fā)機(jī)構(gòu)和項目,用RUP時還要做裁剪,也就是要對RUP進(jìn)行配置。RUP就像一個元過程,通過對RUP進(jìn)行裁剪可以得到很多不同的開發(fā)過程,這些軟件開發(fā)過程可以看作RUP的具體實(shí)例。RUP裁剪可以分為以下幾步:
1) 確定本項目需要哪些工作流。RUP的9個核心工作流并不總是需要的,可以取舍。
2) 確定每個工作流需要哪些制品。
3) 確定4個階段之間如何演進(jìn)。確定階段間演進(jìn)要以風(fēng)險控制為原則,決定每個階段要那些工作流,每個工作流執(zhí)行到什么程度,制品有那些,每個制品完成到什么程度。
4) 確定每個階段內(nèi)的迭代計劃。規(guī)劃RUP的4個階段中每次迭代開發(fā)的內(nèi)容。
5) 規(guī)劃工作流內(nèi)部結(jié)構(gòu)。工作流涉及角色、活動及制品,他的復(fù)雜程度與項目規(guī)模即角色多少有關(guān)。最后規(guī)劃工作流的內(nèi)部結(jié)構(gòu),通常用活動圖的形式給出。
五、開發(fā)過程中的各個階段和里程碑
RUP中的軟件生命周期在時間上被分解為四個順序的階段,分別是:初始階段(Inception)、細(xì)化階段(Elaboration)、構(gòu)造階段(Construction)和交付階段(Transition)。每個階段結(jié)束于一個主要的里程碑(Major Milestones);每個階段本質(zhì)上是兩個里程碑之間的時間跨度。在每個階段的結(jié)尾執(zhí)行一次評估以確定這個階段的目標(biāo)是否已經(jīng)滿足。如果評估結(jié)果令人滿意的話,可以允許項目進(jìn)入下一個階段。
1. 初始階段
初始階段的目標(biāo)是為系統(tǒng)建立商業(yè)案例并確定項目的邊界。為了達(dá)到該目的必須識別所有與系統(tǒng)交互的外部實(shí)體,在較高層次上定義交互的特性。本階段具有非常重要的意義,在這個階段中所關(guān)注的是整個項目進(jìn)行中的業(yè)務(wù)和需求方面的主要風(fēng)險。對于建立在原有系統(tǒng)基礎(chǔ)上的開發(fā)項目來講,初始階段可能很短。 初始階段結(jié)束時是第一個重要的里程碑:生命周期目標(biāo)(Lifecycle Objective)里程碑。生命周期目標(biāo)里程碑評價項目基本的生存能力。
2. 細(xì)化階段
細(xì)化階段的目標(biāo)是分析問題領(lǐng)域,建立健全的體系結(jié)構(gòu)基礎(chǔ),編制項目計劃,淘汰項目中最高風(fēng)險的元素。為了達(dá)到該目的,必須在理解整個系統(tǒng)的基礎(chǔ)上,對體系結(jié)構(gòu)作出決策,包括其范圍、主要功能和諸如性能等非功能需求。同時為項目建立支持環(huán)境,包括創(chuàng)建開發(fā)案例,創(chuàng)建模板、準(zhǔn)則并準(zhǔn)備工具。 細(xì)化階段結(jié)束時第二個重要的里程碑:生命周期結(jié)構(gòu)(Lifecycle Architecture)里程碑。生命周期結(jié)構(gòu)里程碑為系統(tǒng)的結(jié)構(gòu)建立了管理基準(zhǔn)并使項目小組能夠在構(gòu)建階段中進(jìn)行衡量。此刻,要檢驗(yàn)詳細(xì)的系統(tǒng)目標(biāo)和范圍、結(jié)構(gòu)的選擇以及主要風(fēng)險的解決方案。
3. 構(gòu)造階段
在構(gòu)建階段,所有剩余的構(gòu)件和應(yīng)用程序功能被開發(fā)并集成為產(chǎn)品,所有的功能被詳細(xì)測試。從某種意義上說,構(gòu)建階段是一個制造過程,其重點(diǎn)放在管理資源及控制運(yùn)作以優(yōu)化成本、進(jìn)度和質(zhì)量。 構(gòu)建階段結(jié)束時是第三個重要的里程碑:初始功能(Initial Operational)里程碑。初始功能里程碑決定了產(chǎn)品是否可以在測試環(huán)境中進(jìn)行部署。此刻,要確定軟件、環(huán)境、用戶是否可以開始系統(tǒng)的運(yùn)作。此時的產(chǎn)品版本也常被稱為“beta”版。
4. 交付階段
交付階段的重點(diǎn)是確保軟件對最終用戶是可用的。交付階段可以跨越幾次迭代,包括為發(fā)布做準(zhǔn)備的產(chǎn)品測試,基于用戶反饋的少量的調(diào)整。在生命周期的這一點(diǎn)上,用戶反饋應(yīng)主要集中在產(chǎn)品調(diào)整,設(shè)置、安裝和可用性問題,所有主要的結(jié)構(gòu)問題應(yīng)該已經(jīng)在項目生命周期的早期階段解決了。 在交付階段的終點(diǎn)是第四個里程碑:產(chǎn)品發(fā)布(Product Release)里程碑。此時,要確定目標(biāo)是否實(shí)現(xiàn),是否應(yīng)該開始另一個開發(fā)周期。在一些情況下這個里程碑可能與下一個周期的初始階段的結(jié)束重合。
六、統(tǒng)一軟件開發(fā)過程RUP的核心工作流(Core Workflows)
RUP中有9個核心工作流,分為6個核心過程工作流(Core Process Workflows)和3個核心支持工作流(Core Supporting Workflows)。盡管6個核心過程工作流可能使人想起傳統(tǒng)瀑布模型中的幾個階段,但應(yīng)注意迭代過程中的階段是完全不同的,這些工作流在整個生命周期中一次又一次被訪問。9個核心工作流在項目中輪流被使用,在每一次迭代中以不同的重點(diǎn)和強(qiáng)度重復(fù)。
1. 商業(yè)建模(Business Modeling)
商業(yè)建模工作流描述了如何為新的目標(biāo)組織開發(fā)一個構(gòu)想,并基于這個構(gòu)想在商業(yè)用例模型和商業(yè)對象模型中定義組織的過程,角色和責(zé)任。
2. 需求(Requirements)
需求工作流的目標(biāo)是描述系統(tǒng)應(yīng)該做什么,并使開發(fā)人員和用戶就這一描述達(dá)成共識。為了達(dá)到該目標(biāo),要對需要的功能和約束進(jìn)行提取、組織、文檔化;最重要的是理解系統(tǒng)所解決問題的定義和范圍。
3. 分析和設(shè)計(Analysis & Design)
分析和設(shè)計工作流將需求轉(zhuǎn)化成未來系統(tǒng)的設(shè)計,為系統(tǒng)開發(fā)一個健壯的結(jié)構(gòu)并調(diào)整設(shè)計使其與實(shí)現(xiàn)環(huán)境相匹配,優(yōu)化其性能。分析設(shè)計的結(jié)果是一個設(shè)計模型和一個可選的分析模型。設(shè)計模型是源代碼的抽象,由設(shè)計類和一些描述組成。設(shè)計類被組織成具有良好接口的設(shè)計包(Package)和設(shè)計子系統(tǒng)(Subsystem),而描述則體現(xiàn)了類的對象如何協(xié)同工作實(shí)現(xiàn)用例的功能。 設(shè)計活動以體系結(jié)構(gòu)設(shè)計為中心,體系結(jié)構(gòu)由若干結(jié)構(gòu)視圖來表達(dá),結(jié)構(gòu)視圖是整個設(shè)計的抽象和簡化,該視圖中省略了一些細(xì)節(jié),使重要的特點(diǎn)體現(xiàn)得更加清晰。體系結(jié)構(gòu)不僅僅是良好設(shè)計模型的承載媒介,而且在系統(tǒng)的開發(fā)中能提高被創(chuàng)建模型的質(zhì)量。
4. 實(shí)現(xiàn)(Implementation)
實(shí)現(xiàn)工作流的目的包括以層次化的子系統(tǒng)形式定義代碼的組織結(jié)構(gòu);以組件的形式(源文件、二進(jìn)制文件、可執(zhí)行文件)實(shí)現(xiàn)類和對象;將開發(fā)出的組件作為單元進(jìn)行測試以及集成由單個開發(fā)者(或小組)所產(chǎn)生的結(jié)果,使其成為可執(zhí)行的系統(tǒng)。
5. 測試(Test)
測試工作流要驗(yàn)證對象間的交互作用,驗(yàn)證軟件中所有組件的正確集成,檢驗(yàn)所有的需求已被正確的實(shí)現(xiàn), 識別并確 認(rèn)缺陷在軟件部署之前被提出并處理。RUP提出了迭代的方法,意味著在整個項目中進(jìn)行測試,從而盡可能早地發(fā)現(xiàn)缺陷,從根本上降低了修改缺陷的成本。測試類似于三維模型,分別從可靠性、功能性和系統(tǒng)性能來進(jìn)行。
6. 部署(Deployment)
部署工作流的目的是成功的生成版本并將軟件分發(fā)給最終用戶。部署工作流描述了那些與確保軟件產(chǎn)品對最終用戶具有可用性相關(guān)的活動,包括:軟件打包、生成軟件本身以外的產(chǎn)品、安裝軟件、為用戶提供幫助。在有些情況下,還可能包括計劃和進(jìn)行beta測試版、移植現(xiàn)有的軟件和數(shù)據(jù)以及正式驗(yàn)收。
7. 配置和變更管理(Configuration & Change Management)
配置和變更管理工作流描繪了如何在多個成員組成的項目中控制大量的產(chǎn)物。配置和變更管理工作流提供了準(zhǔn)則來管理演化系統(tǒng)中的多個變體,跟蹤軟件創(chuàng)建過程中的版本。工作流描述了如何管理并行開發(fā)、分布式開發(fā)、如何自動化創(chuàng)建工程。同時也闡述了對產(chǎn)品修改原因、時間、人員保持審計記錄。
8. 項目管理(Project Management)
軟件項目管理平衡各種可能產(chǎn)生沖突的目標(biāo),管理風(fēng)險,克服各種約束并成功交付使用戶滿意的產(chǎn)品。其目標(biāo)包括:為項目的管理提供框架,為計劃、人員配備、執(zhí)行和監(jiān)控項目提供實(shí)用的準(zhǔn)則,為管理風(fēng)險提供框架等。
9. 環(huán)境(Environment)
環(huán)境工作流的目的是向軟件開發(fā)組織提供軟件開發(fā)環(huán)境,包括過程和工具。環(huán)境工作流集中于配置項目過程中所需要的活動,同樣也支持開發(fā)項目規(guī)范的活動,提供了逐步的指導(dǎo)手冊并介紹了如何在組織中實(shí)現(xiàn)過程。
七、RUP的迭代開發(fā)模式
RUP中的每個階段可以進(jìn)一步分解為迭代。一個迭代是一個完整的開發(fā)循環(huán),產(chǎn)生一個可執(zhí)行的產(chǎn)品版本,是最終產(chǎn)品的一個子集,它增量式地發(fā)展,從一個迭代過程到另一個迭代過程到成為最終的系統(tǒng)。 傳統(tǒng)上的項目組織是順序通過每個工作流,每個工作流只有一次,也就是我們熟悉的瀑布生命周期(見圖2)。這樣做的結(jié)果是到實(shí)現(xiàn)末期產(chǎn)品完成并開始測試,在分析、設(shè)計和實(shí)現(xiàn)階段所遺留的隱藏問題會大量出現(xiàn),項目可能要停止并開始一個漫長的錯誤修正周期。
一種更靈活,風(fēng)險更小的方法是多次通過不同的開發(fā)工作流,這樣可以更好的理解需求,構(gòu)造一個健壯的體系結(jié)構(gòu),并最終交付一系列逐步完成的版本。這叫做一個迭代生命周期。在工作流中的每一次順序的通過稱為一次迭代。軟件生命周期是迭代的連續(xù),通過它,軟件是增量的開發(fā)。一次迭代包括了生成一個可執(zhí)行版本的開發(fā)活動,還有使用這個版本所必需的其他輔助成分,如版本描述、用戶文檔等。因此一個開發(fā)迭代在某種意義上是在所有工作流中的一次完整的經(jīng)過,這些工作流至少包括:需求工作流、分析和設(shè)計工作流、實(shí)現(xiàn)工作流、測試工作流。其本身就像一個小型的瀑布項目(見圖3)。
圖3 RUP的迭代模型
與傳統(tǒng)的瀑布模型相比較,迭代過程具有以下優(yōu)點(diǎn):
降低了在一個增量上的開支風(fēng)險。如果開發(fā)人員重復(fù)某個迭代,那么損失只是這一個開發(fā)有誤的迭代的花費(fèi)。
降低了產(chǎn)品無法按照既定進(jìn)度進(jìn)入市場的風(fēng)險。通過在開發(fā)早期就確定風(fēng)險,可以盡早來解決而不至于在開發(fā)后期匆匆忙忙。
加快了整個開發(fā)工作的進(jìn)度。因?yàn)殚_發(fā)人員清楚問題的焦點(diǎn)所在,他們的工作會更有效率。
由于用戶的需求并不能在一開始就作出完全的界定,它們通常是在后續(xù)階段中不斷細(xì)化的。因此,迭代過程這種模式使適應(yīng)需求的變化會更容易些。
八、統(tǒng)一軟件開發(fā)過程RUP的十大要素
1. 開發(fā)前景
2. 達(dá)成計劃
3. 標(biāo)識和減小風(fēng)險
4. 分配和跟蹤任務(wù)。。
5. 檢查商業(yè)理由
6. 設(shè)計組件構(gòu)架
7. 對產(chǎn)品進(jìn)行增量式的構(gòu)建和測試
8. 驗(yàn)證和評價結(jié)果
9. 管理和控制變化
10. 提供用戶支持
讓我們逐一的審視這些要素,看一看它們什么地方適合RUP,找出它們能夠成為十大要素的理由。
1. 開發(fā)一個前景
有一個清晰的前景是開發(fā)一個滿足涉眾真正需求的產(chǎn)品的關(guān)鍵。 前景抓住了RUP需求流程的要點(diǎn):分析問題,理解涉眾需求,定義系統(tǒng),當(dāng)需求變化時管理需求。 前景給更詳細(xì)的技術(shù)需求提供了一個高層的、有時候是合同式的基礎(chǔ)。正像這個術(shù)語隱含的那樣,它是軟件項目的一個清晰的、通常是高層的視圖,能被過程中任何決策者或者實(shí)施者借用。它捕獲了非常高層的需求和設(shè)計約束,讓前景的讀者能理解將要開發(fā)的系統(tǒng)。它還提供了項目審批流程的輸入,因此就與商業(yè)理由密切相關(guān)。最后,由于前景構(gòu)成了“項目是什么?”和“為什么要進(jìn)行這個項目?”,所以可以把前景作為驗(yàn)證將來決策的方式之一。 對前景的陳述應(yīng)該能回答以下問題,需要的話這些問題還可以分成更小、更詳細(xì)的問題: ? 關(guān)鍵術(shù)語是什么?(詞匯表) ? 我們嘗試解決的問題是什么?(問題陳述) ? 涉眾是誰?用戶是誰?他們各自的需求是什么? ? 產(chǎn)品的特性是什么? ? 功能性需求是什么?(Use Cases) ? 非功能性需求是什么? ? 設(shè)計約束是什么?
2. 達(dá)成計劃
“產(chǎn)品的質(zhì)量只會和產(chǎn)品的計劃一樣好。” (2) 在RUP中,軟件開發(fā)計劃(SDP)綜合了管理項目所需的各種信息,也許會包括一些在先啟階段開發(fā)的單獨(dú)的內(nèi)容。SDP必須在整個項目中被維護(hù)和更新。 SDP定義了項目時間表(包括項目計劃和迭代計劃)和資源需求(資源和工具),可以根據(jù)項目進(jìn)度表來跟蹤項目進(jìn)展。同時也指導(dǎo)了其他過程內(nèi)容(原文:process components)的計劃:項目組織、需求管理計劃、配置管理計劃、問題解決計劃、QA計劃、測試計劃、評估計劃以及產(chǎn)品驗(yàn)收計劃。
在較簡單的項目中,對這些計劃的陳述可能只有一兩句話。比如,配置管理計劃可以簡單的這樣陳述:每天結(jié)束時,項目目錄的內(nèi)容將會被壓縮成ZIP包,拷貝到一個ZIP磁盤中,加上日期和版本標(biāo)簽,放到中央檔案柜中。 軟件開發(fā)計劃的格式遠(yuǎn)遠(yuǎn)沒有計劃活動本身以及驅(qū)動這些活動的思想重要。正如Dwight D.Eisenhower所說:“plan什么也不是,planning才是一切。” “達(dá)成計劃”—和列表中第3、4、5、8條一起—抓住了RUP中項目管理流程的要點(diǎn)。項目管理流程包括以下活動:構(gòu)思項目、評估項目規(guī)模和風(fēng)險、監(jiān)測與控制項目、計劃和評估每個迭代和階段。
3. 標(biāo)識和減小風(fēng)險
RUP的要點(diǎn)之一是在項目早期就標(biāo)識并處理最大的風(fēng)險。項目組標(biāo)識的每一個風(fēng)險都應(yīng)該有一個相應(yīng)的緩解或解決計劃。風(fēng)險列表應(yīng)該既作為項目活動的計劃工具,又作為確定迭代的基礎(chǔ)。
4. 分配和跟蹤任務(wù)
有一點(diǎn)在任何項目中都是重要的,即連續(xù)的分析來源于正在進(jìn)行的活動和進(jìn)化的產(chǎn)品的客觀數(shù)據(jù)。在RUP中,定期的項目狀態(tài)評估提供了講述、交流和解決管理問題、技術(shù)問題以及項目風(fēng)險的機(jī)制。團(tuán)隊一旦發(fā)現(xiàn)了這些障礙物(籬笆),他們就把所有這些問題都指定一個負(fù)責(zé)人,并指定解決日期。進(jìn)度應(yīng)該定期跟蹤,如有必要,更新應(yīng)該被發(fā)布。(原文:updates should be issued as necessary。) 這些項目“快照”突出了需要引起管理注意的問題。隨著時間的變化/雖然周期可能會變化(原文:While the period may vary。),定期的評估使經(jīng)理能捕獲項目的歷史,并且消除任何限制進(jìn)度的障礙或瓶頸。
5. 檢查商業(yè)理由
商業(yè)理由從商業(yè)的角度提供了必要的信息,以決定一個項目是否值得投資。商業(yè)理由還可以幫助開發(fā)一個實(shí)現(xiàn)項目前景所需的經(jīng)濟(jì)計劃。它提供了進(jìn)行項目的理由,并建立經(jīng)濟(jì)約束。當(dāng)項目繼續(xù)時,分析人員用商業(yè)理由來正確的估算投資回報率(ROI,即return on investment)。 商業(yè)理由應(yīng)該給項目創(chuàng)建一個簡短但是引人注目的理由,而不是深入研究問題的細(xì)節(jié),以使所有項目成員容易理解和記住它。在關(guān)鍵里程碑處,經(jīng)理應(yīng)該回顧商業(yè)理由,計算實(shí)際的花費(fèi)、預(yù)計的回報,決定項目是否繼續(xù)進(jìn)行。
6. 設(shè)計組件構(gòu)架
在RUP中,件系統(tǒng)的構(gòu)架是指一個系統(tǒng)關(guān)鍵部件的組織或結(jié)構(gòu),部件之間通過接口交互,而部件是由一些更小的部件和接口組成的。即主要的部分是什么?他們又是怎樣結(jié)合在一起的? RUP提供了一種設(shè)計、開發(fā)、驗(yàn)證構(gòu)架的很系統(tǒng)的方法。在分析和設(shè)計流程中包括以下步驟:定義候選構(gòu)架、精化構(gòu)架、分析行為(用例分析)、設(shè)計組件。 要陳述和討論軟件構(gòu)架,你必須先創(chuàng)建一個構(gòu)架表示方式,以便描述構(gòu)架的重要方面。在RUP中,構(gòu)架表示由軟件構(gòu)架文檔捕獲,它給構(gòu)架提供了多個視圖。每個視圖都描述了某一組涉眾所關(guān)心的正在進(jìn)行的系統(tǒng)的某個方面。涉眾有最終用戶、設(shè)計人員、經(jīng)理、系統(tǒng)工程師、系統(tǒng)管理員,等等。這個文檔使系統(tǒng)構(gòu)架師和其他項目組成員能就與構(gòu)架相關(guān)的重大決策進(jìn)行有效的交流。
7. 對產(chǎn)品進(jìn)行增量式的構(gòu)建和測試
在RUP中實(shí)現(xiàn)和測試流程的要點(diǎn)是在整個項目生命周期中增量的編碼、構(gòu)建、測試系統(tǒng)組件,在先啟之后每個迭代結(jié)束時生成可執(zhí)行版本。在精化階段后期,已經(jīng)有了一個可用于評估的構(gòu)架原型;如有必 要,它可以包括一個用戶界面原型。然后,在構(gòu)建階段的每次迭代中,組件不斷的被集成到可執(zhí)行、經(jīng)過測試的版本中,不斷地向最終產(chǎn)品進(jìn)化。動態(tài)及時的配置管理和復(fù)審活動也是這個基本過程元素(原文:essential process element)的關(guān)鍵。
8. 驗(yàn)證和評價結(jié)果
顧名思義,RUP的迭代評估捕獲了迭代的結(jié)果。評估決定了迭代滿足評價標(biāo)準(zhǔn)的程度,還包括學(xué)到的教訓(xùn)和實(shí)施的過程改進(jìn)。 根據(jù)項目的規(guī)模和風(fēng)險以及迭代的特點(diǎn),評估可以是對演示及其結(jié)果的一條簡單的紀(jì)錄,也可能是一個完整的、正式的測試復(fù)審記錄。 這兒的關(guān)鍵是既關(guān)注過程問題又關(guān)注產(chǎn)品問題。越早發(fā)現(xiàn)問題,就越?jīng)]有問題。(原文:The sooner you fall behind, the more time you will have to catch up.)
9. 管理和控制變化
RUP的配置和變更管理流程的要點(diǎn)是當(dāng)變化發(fā)生時管理和控制項目的規(guī)模,并且貫穿整個生命周期。其目的是考慮所有的涉眾需求,盡可能的滿足,同時仍能及時的交付合格的產(chǎn)品。 用戶拿到產(chǎn)品的第一個原型后(往往在這之前就會要求變更),他們會要求變更。重要的是,變更的提出和管理過程始終保持一致。 在RUP中,變更請求通常用于記錄和跟蹤缺陷和增強(qiáng)功能的要求,或者對產(chǎn)品提出的任何其他類型的變更請求。變更請求提供了相應(yīng)的手段來評估一個變更的潛在影響,同時記錄就這些變更所作出的決策。他們也幫助確保所有的項目組成員都能理解變更的潛在影響。
10. 提供用戶支持
在RUP中,部署流程的要點(diǎn)是包裝和交付產(chǎn)品,同時交付有助于最終用戶學(xué)習(xí)、使用和維護(hù)產(chǎn)品的任何必要的材料。 項目組至少要給用戶提供一個用戶指南(也許是通過聯(lián)機(jī)幫助的方式提供),可能還有一個安裝指南和版本發(fā)布說明。 根據(jù)產(chǎn)品的復(fù)雜度,用戶也許還需要相應(yīng)的培訓(xùn)材料。最后,通過一個材料清單(BOM表,即Bill of Materials)清楚地記錄應(yīng)該和產(chǎn)品一起交付哪些材料。 關(guān)于需求 有人看了我的要素清單后,可能會非常不同意我的選擇。例如,他會問,需求在哪兒呢?他們不重要嗎?我會告訴他我為什么沒有把它們包括進(jìn)來。有時,我會問一個項目組(特別是內(nèi)部項目的項目組):“你們的需求是什么?”,而得到的回答卻是:“我們的確沒有什么需求。” 剛開始我對此非常驚訝(我有軍方的宇航開發(fā)背景)。他們怎么會沒有需求呢?當(dāng)我進(jìn)一步詢問時,我發(fā)現(xiàn),對他們來說,需求意味著一套外部提出的強(qiáng)制性的陳述,要求他們必須怎么樣,否則項目驗(yàn)收就不能通過。但是他們的確沒有得到這樣的陳述。尤其是當(dāng)項目組陷入了邊研究邊開發(fā)的境地時,產(chǎn)品需求從頭到尾都在演化。 因此,我接著問他們另外一個問題:“好的,那么你們的產(chǎn)品的前景是什么呢?”。這時他們的眼睛亮了起來。然后,我們非常順利的就第一個要素(“開發(fā)一個前景”)中列出的問題進(jìn)行了溝通,需求也自然而然的流動著(原文:and the requirements just flow naturally.)。 也許只有對于按照有明確需求的合同工作的項目組,在要素列表中加入“滿足需求”才是有用的。請記住,我的清單僅僅意味著進(jìn)行進(jìn)一步討論的一個起點(diǎn)。
九、總結(jié)
RUP具有很多長處:提高了團(tuán)隊生產(chǎn)力,在迭代的開發(fā)過程、需求管理、基于組件的體系結(jié)構(gòu)、可視化軟件建模、驗(yàn)證軟件質(zhì)量及控制軟件變更等方面,針對所有關(guān)鍵的開發(fā)活動為每個開發(fā)成員提供了必要的準(zhǔn)則、模板和工具指導(dǎo),并確保全體成員共享相同的知識基礎(chǔ)。它建立了簡潔和清晰的過程結(jié)構(gòu),為開發(fā)過程提供較大的通用性。但同時它也存在一些不足: RUP只是一個開發(fā)過程,并沒有涵蓋軟件過程的全部內(nèi)容,例如它缺少關(guān)于軟件運(yùn)行和支持等方面的內(nèi)容;此外,它沒有支持多項目的開發(fā)結(jié)構(gòu),這在一定程度上降低了在開發(fā)組織內(nèi)大范圍實(shí)現(xiàn)重用的可能性??梢哉fRUP是一個非常好的開端,但并不完美,在實(shí)際的應(yīng)用中可以根據(jù)需要對其進(jìn)行改進(jìn)并可以用OPEN和OOSP等其他軟件過程的相關(guān)內(nèi)容對RUP進(jìn)行補(bǔ)充和完善。
聯(lián)系客服