在這個項目的非常早期的階段，我們能設計一個階段計劃， 作為在我們的軟件開發(fā)計劃里的一個部分，該計劃概括了每階段的長度和及其迭代，并且為每一個迭代階段制定了嚴格的時間計劃，包括應用軟件的發(fā)布。 （在一項RUP項目里的每個階段可以包含多次迭代。) 我們所不知道的是，什么功能將準確地在每一個迭代過程中被交付。

在下一個階段——精化階段，我們將關注在詳細描述需求上，根據(jù)這些需求來開發(fā)軟件，降低由技術、計劃和資源帶來的不確定性。隨著我們的精化過程進行，我們可以在階段計劃中補充一些細節(jié)的東西�；�于在先前一個迭代階段中學到的東西，我們能將需要實現(xiàn)的軟件的功能安排到項目的一個個迭代階段。在精化階段的后，項目中的大多數(shù)不確定（危險）會得到減輕，我們能談判做出確定的關于軟件功能范圍的承諾。 如果我們已經(jīng)采取有規(guī)律的版本式方法來開發(fā)我們的應用程序，功能范圍的協(xié)商會容易得多，因為我們總能在未來某一個版本中完成所要求的功能。

根據(jù)精化階段制定的詳細的程序功能范圍，我們可以進入開發(fā)階段。此時，我們的重點轉(zhuǎn)移到根據(jù)經(jīng)過校訂的關于功能范圍的合約，開發(fā)剩下的功能。現(xiàn)在我們該對我們的能力感到滿意，因為我們能做到根據(jù)在項目先啟階段制定的時間表來完成所需要功能的開發(fā)。
通過協(xié)作改進需求

要成功地使用RUP需要在項目研究團隊和相關利益方之間形成一種新的合作關系。過去，IT界已經(jīng)提出了，向商業(yè)相關利益方正確定義需求存在一定風險，但是還是假設交付軟件的風險取決于這些需求。 IT界會讓用戶簽訂一份文檔，然后來控制這些需求的變化，從而達到管理這些風險的目的。 IT界會由于這些變化向用戶收費，然后根據(jù)這些變化相應增加事先的估計，從而得以修改時間計劃和 超額的支出，從而聲稱項目依然準時而且不超支。這種行為會在相關利益方和IT界之間引發(fā)猜疑，導致彼此感覺不舒服。

另外一種合作的方法會大大優(yōu)于上述的方法。相關利益方和項目研究團隊在事先都清楚認識到，在項目一開始完全正確地定義需求事實上是不可能的。因此讓項目研究團隊按照預算和時間計劃下執(zhí)行任務也是不可能的，因為這個預算和時間計劃本基于不確定的需求、資源和技術。

采用了“RUP精神”的項目中，相關利益方和項目研究團隊成員清楚，隨著他們了解更多，需求可以而且應當變化和改進。在項目研究團隊排除項目中大多數(shù)不確定因素之前做精確的計劃是不明智的。項目管理者必須盡快地說明那些不確定因素，這樣負責實現(xiàn)的團隊能夠根據(jù)需要實現(xiàn)的功能的范圍來確定軟件功能。

團隊經(jīng)常會問：“精化階段應該持續(xù)多久？”答案是，讓這段時間足夠長，從而項目研究組能降低已知的風險，項目管理者可以根據(jù)這個項目的時間安排、支出和功能范圍來做出明確的說明。在一個典型的項目中，這個階段意味著開發(fā)百分之二十的功能，或者足以證明整個框架能夠支持所有的需求。

在精化階段的后，當研究團隊已經(jīng)將和進度、功能、技術和資源相關的大部分不確定性消除之后，他們可以列出需求，同時把將來需求的變化納入正常的變更控制過程中。
將維護人員調(diào)入開發(fā)團隊

很多組織將新程序開發(fā)和現(xiàn)有程序維護區(qū)別對待。通常來說，他們會外請顧問來根據(jù)新的技術建立新的程序，但是一旦這項程序開發(fā)部署完畢，他們會將該程序應用交付給內(nèi)部維護人員支持。這會讓工作人員失去動力。來維護一個別人建立的應用程序，對工作人員來說不會太滿意，尤其是當這些維護人員還很少和新技術接觸的情況下。同樣，在不知道先前的開發(fā)基于何種決策的情況下，要有效地維持一個應用程序也非常困難。如果你應用了這種方法，你必須給維護人員提供足夠的材料，這將會增加系統(tǒng)的開銷。

在迭代化開發(fā)環(huán)境中，將維護人員調(diào)到開發(fā)隊伍中，讓他們同時負責維護現(xiàn)有版本以及為未來的新版本開發(fā)新功能，更有意義了。這促使團隊始終關注系統(tǒng)的商業(yè)目標和特色，使得團隊成員能夠幫助完善這個商業(yè)目標和特色。終，這種方法將帶來一個更高效更愉快的開發(fā)隊伍，同時也會減少文檔負擔。
問合適的問題，并要求增加的功能演示

迭代化開發(fā)方法會如何影響指導委員會管理與項目管理者會晤的方法呢？首先，管理者必須確認委員會了解在整個RUP各個階段中項目會如何變化。只有這樣委員會才能夠問出有意義的問題，在不同階段中調(diào)整提供的資金水平。比如，在精化過程中，他們應該問項目管理者索取定時更新的風險列表，從而能確認這些風險是否在該階段后過程被消除。

在一個項目先啟階段中，應集中關注于降低風險和不確定因素，這是使用RUP優(yōu)于使用其他迭代化方法的重要優(yōu)勢。在開發(fā)軟件的精化階段中，如果使用降低風險的方法，發(fā)現(xiàn)大的不確定性是十分必要的。很多風險與構架關系有關。盡管客戶相關利益方可能會給開發(fā)團隊施加壓力，要求先建立他們所認為的重要的功能，在精化階段還是要根據(jù)結構而不是客戶來設置優(yōu)先級。指導委員會必須知道這些。在精化過程的后，當大的不確定性已經(jīng)被解決，項目也將進入開發(fā)建設階段，這時候優(yōu)先級設置可以多考慮以用戶需求為驅(qū)動。

在有些情況下，先完成主要功能的構建，來降低和需求相關的風險以及工作流中的不確定性，可能是有意義的。然而，如果這種功能是很直接的而且并不和一些很明顯的不確定性相關，開發(fā)團隊可以將該功能的開發(fā)推遲到構建階段進行。記�。何覀兊哪繕耸潜M快完成精化階段，這樣我們能給相關利益方確切的承諾，轉(zhuǎn)入開發(fā)構建階段。

指導委員會應當也需要基于一個已基線化的架構，驗證關鍵用例場景（使用真的可以運行的軟件而不是模型！）。 事實上，他們可能會考慮在他們的會議間放上投影機來使得軟件演示更順暢。這和傳統(tǒng)的瀑布式方法有著根本的不同。指導委員會通常只有在整個應用程序即將投入使用的時候，看到demo版本而不是看到一個功能型的演示版本。另外，他們通常用甘特圖來衡量整個項目的進程，在甘特圖上會顯示已經(jīng)完成了33％尚未完成66％，諸如此類�；蛘�，他們會問管理者是否已經(jīng)簽訂了需求和設計文檔。首先，而且也是重要的是，項目管理者需要教育指導委員會成員，如何來衡量進度：的有效方法是看能夠工作的軟件而不是簽訂的文檔。