RUP 統一軟體開發過程(Rational Unified Process,RUP)

UML associated process.

Brings together aspects of the above generic models

●  A dynamic perspective that shows phases over time ;

以動態角度來看顯示階段會隨著時間推移。

●  A static perspective that shows process activities;

以靜態來看顯示整個流程活動。

●  A practive perspective that suggests good practice.

以實踐角度來看提出好的做法。

 

Phases :

●  起始Inception(建立Business Case)

●  細述Elaboration(了解問題領域和系統架構)

●  建構Contraction(系統設計、實作和測試)

●  轉換Transition(開發環境至操作環境)

 

Workflow :

1. 商業塑模(Business Modeling) :

商業建模工作流描述了如何為新的目標組織開發一個構想,並基於這個構想在商業用例模型和商業對像模型中定義組織的過程,角色和責任。

 

2. 需求(Requirements) : 

目標是描述系統應該做什麼,並使開發人員和用戶就這一描述達成共識。為了達到該目標,要對需要的功能和約束進行提取、組織、文檔化;最重要的是理解系統所解決問題的定義和範圍。

 

3. 分析和設計(Analysis & Design) : 

將需求轉化成未來系統的設計,為系統開發一個健壯的結構並調整設計使其與實現環境相匹配,優化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽像,由設計類和一些描述組成。設計類被組織成具有良好接口的設計包(Package)和設計子系統(Subsystem),而描述則體現了類的對象如何協同工作實現用例的功能。

設計活動以體系結構設計為中心,體系結構由若干結構視圖來表達,結構視圖是整個設計的抽像和簡化,該視圖中省略了一些細節,使重要的特點體現得更加清晰。體系結構不僅僅是良好設計模型的承載媒介,而且在系統的開發中能提高被創建模型的質量。          

                                   

4. 實作(Implementation) :

目的包括以層次化的子系統形式定義代碼的組織結構;以組件的形式(源文件、二進制文件、可執行文件)實現類和對像;將開發出的組件作為單元進行測試以及集成由單個開發者(或小組)所產生的結果,使其成為可執行的系統。

 

5. 測試(Test) : 

要驗證對像間的交互作用,驗證軟件中所有組件的正確集成,檢驗所有的需求已被正確的實現, 識別並確認缺陷在軟件部署之前被提出並處理。RUP提出了迭代的方法,意味著在整個項目中進行測試,從而盡可能早地發現缺陷,從根本上降低了修改缺陷的成本。測試類似於三維模型,分別從可靠性、功能性和系統性能來進行。   

                                                                            

6. 部署(Deployment)  : 

部署工作流的目的是成功的生成版本並將軟件分發給最終用戶。部署工作流描述了那些與確保軟件產品對最終用戶具有可用性相關的活動,包括:軟件打包、生成軟件本身以外的產品、安裝軟件、為用戶提供幫助。在有些情況下,還可能包括計劃和進行beta測試版、移植現有的軟件和數據以及正式驗收。

7. 配置和變更管理(Configuration & Change Management)  :  

描繪了如何在多個成員組成的項目中控制大量的產物。配置和變更管理工作流提供了準則來管理演化系統中的多個變體,跟蹤軟件創建過程中的版本。工作流描述了如何管理並行開發、分佈式開發、如何自動化創建工程。同時也闡述了對產品修改原因、時間、人員保持審計記錄。

 

8. 專案管理(Project Management)  : 

管理平衡各種可能產生衝突的目標,管理風險,克服各種約束並成功交付使用戶滿意的產品。其目標包括:為項目的管理提供框架,為計劃、人員配備、執行和監控項目提供實用的準則,為管理風險提供框架等。

 

9. 環境(Environment) :

 目的是向軟件開發組織提供軟件開發環境,包括過程和工具。環境工作流集中於配置項目過程中所需要的活動,同樣也支持開發項目規範的活動,提供了逐步的指導手冊並介紹了如何在組織中實現過程。

 

優點:

●  該程序方法論結合了眾多成功的方法論,提供完整的軟體開發流程。

●  結合採用反覆式(Iterative)開發流程失敗,可降低開發的風險。

●  UML作為其視覺化軟體分析與設計語言,使軟體開發人員之間的溝通與資訊的交換無礙。

●  以UML中的使用者案例(Use-Case)作為整個Rational Unified Process的核心。

●  受到工具的支援:程序經過良好的支援,且受到好的工具支援。例如, Rational Rose、Rational Unified Process。

●  對於軟體開發各階段中所參與之角色皆定義每其應有之責任與活動。

 

 

缺點:

●  學習困難:為了無所不包,相對使得該程序變的非常巨大,不論是學習或管理都很困難。

●  花費很多時間:各專案使用該方法論,會花上許多的時間。

●  工具受限:支援工具相對受限於Rational自己的產品。


Innovations :

RUP打破了“需求-設計-編碼-測試”這樣傳統的瀑布模組模式,而是讓這些工作一直進行,只是在不同的時間裡有不同的比例。這個思想與敏捷開發非常相近,也非常符合實際的狀況。

 

資料參考 : MBA智庫





arrow
arrow

    橘子亂說話 發表在 痞客邦 留言(0) 人氣()