Can you summarize the following document?
        
  RUP為專案成員定義了在一個產品生命週期中如下指導方針和模板。

  給定的時間內,開發一個大型的複雜的軟體系統,定義問題並構建解決方案是不可能一蹴而就的。在專案的開發過程中,由於體系結構方面的約束,客戶的需要或對原始問題更精確的理解,需求會經常地變更。迭代式開發允許通過後續的細化產生對專案更好的理解,並在每個迭代的階段,把專案的最高風險的事項作為最高優先順序的任務集中精力解決。理想的,每一次迭代都以一個可執行的釋出為結束,這樣可以減少一個專案風險,更多地允許客戶的互動並幫助開發人員集中精力。

  對於任何大型專案來說,一個文件框架是必不可少的;因此RUP描述瞭如何描述功能性,約束,設計決定和業務需求。  用例和場景是過程規定的製品的例子,在貫穿系統整個開發和部署的過程中,用例和場景在捕捉功能需求和提供一致的線索上是非常有效的。

  基於構件的體系架構(CBA)創造了容易擴充套件的系統,並提升了軟體的重用性和可讀性。一個構件經常與物件導向程式設計中的一個物件有關。  RUP提供了構建這種系統的一個系統化的方法,關注於在把所有資源投入到一個專案之前,開發出一個早期的可執行的體系架構。  這些構件通過一些基礎平臺,如CORBA和COM組裝在一起。

  將你的程式設計從程式碼上抽象出來,並用圖形化構件塊展現出來是得到解決方案的全面意象的一種有效方法。這對於專案的技術人員來說,一方面,能夠更容易地勾畫出如何最好的實現一個給定邏輯集合的輪廓,另一方面,能夠更容易地構造在業務過程和實現業務過程的實際程式碼之間的中間物。  統一建模語言(UML)是表示專案的產業標準方法,因此經常被RUP使用。

  品質評估是所有軟體專案中最經常的失敗所在,因為通常這樣專案的僅僅在專案總結中進行質量評估和甚至由另外的團隊來進行品質評估。 RUP在規劃品質控制和評估方面有所幫助,並把品質控制和評估包括在每個專案成員都參與的整個過程中。

  在所有的軟體專案中,變更是不可避免的,RUP定義了控制和監控變更的方法。一個表面上很小的變更可能以完全不可預計的方式對應用程式產生影響,這一點對一個成功專案至關重要。RUP同時定義了"安全的操作環境",保證一個程式設計師對另一個系統的修改將不會對他系統地修改。這一點與基於構件的體系架構有很大的關係。  迄今為止,這些指導方針是通用的,可以在一個專案的生命週期中遵守。為了把握一個專案的時間尺度,RUP把一個專案分為四個不同的階段:
統一軟體開發過程(英語:Rational Unified Process,縮寫為RUP)是一種軟體工程方法,為迭代式軟體開發流程。最早由Rational Software公司開發,因此冠上公司名稱。Rational Software公司後來被IBM併購,成為IBM之下的一個部門,因此又稱IBM-Rational Unified Process。