Stay focused on executable software

 第三個不可缺少的RUP理論包括幾個方面。首先，你應該盡最大可能的通過衡量你的可執行軟件來衡量你的進展。當然一半以上的用例已經被細化是一件好事，但是這并不意味這相當程度的需求已經完成了。如果你之后發現因為你并沒有恰當的了解用戶需求，進而導致了大多數的主要需求需要重新實現，那么你會怎么做呢？那可能意味著你僅僅完成了實際工作總量的很少一部分。所以如果你想表明你完成了一半的用例，也就相當于你想表明你僅僅實現了一半不到的需求。
最好的衡量進展的方式就是衡量那些可以運行的軟件。它允許你測試，并且基于測試和次品率，估算出真正的進展。當一個典型的開發者陳述說：“我已經完成了90%”，那么你可以問問他，“很好，請演示一下你可以運行的東西。”然后通過演示，獲取一個能夠說明“到底完成了多少”的客觀的結果。你應該總是采用演示-->察看測試覆蓋率和測試結果這樣的過程來估算進展，千萬不要被那些往往和現實不符的文檔所蒙蔽。當然這并不是否定文檔的作用，而只是說明它們對于衡量項目進展情況的時候，只能起到微乎其微的作用。
其次，明確地把精力集中于“可執行”的軟件上，這一點同樣提升了你的團隊的一些正確意識；你不會冒著犯“過渡設計”或者“重理論，輕實踐”這類錯誤的風險，取而代之的是，用實實在在的工作去證明方案“A”和方案“B”的優劣。強迫以可執行軟件作為結束通常是最快的減少風險的途徑。
再次，重視可執行的軟件的第三個特點就是軟件的“副產品”（計劃、配置等管理手段）會去適應軟件的開發，而不是讓軟件的開發去適應這些“副產品”。這些“副產品”是為了讓你開發出更好的軟件。以“可執行的軟件”為出發點，你可以決定是否生產這些“副產品”。通常這些“副產品”是為了讓你的軟件產生更好的效果或者更加容易維護。是的，在一些情況下答案是肯定的，但是這并不是“放之四海而皆準”的。你需要衡量這些副產品所帶來的優劣。通常這些副產品的優勢會隨著你的項目的規模，以及你的產品對于商業的重要程度而增長。在這種情況下，所有的事實都表明：應該產生出盡可能多的“副產品”。但是對于任意一個項目而言，你應該努力的減少這些副產品，進而削減費用。
一個好的方針就是：如果你對于是否生產這些副產品而猶豫不決，干脆就別生產它們。但是不要對那些重要的活動使用此方針，比如記錄需求、進行設計和制定測試計劃的時候就不要這樣做。這些活動所產生的副產品有特定的價值。如果生產副產品的花費超出了回報，忽略它們。
RUP用戶經常犯的一個錯誤就是僅僅因為RUP描述了如何生產那些“副產品”就去生產它們。記住RUP只是大餐前的開胃小菜。

Accommodate change early in the project.
變動是一件好事。實際上變動是一件偉大的事。為什么呢？因為當代大多數的系統正在變得太過復雜以至于你都沒法獲取需求并在第一時間進行設計。變動允許改善你的方案。如果沒有變動，你可能會提交一個有缺陷的方案--這有可能會導致你的應用沒有任何的商業價值。這就是為什么歡迎并且鼓勵變動。并且迭代方法已經被進行了足夠的優化，使它更加適應于變動的情況。
但是變動也有些不良的后果。持久的變動會導致你的項目無窮無止。處在項目后期的一些變動會導致一些工作成為“無用功”，會增加費用，降低質量，甚至會導致拖延--那些都是你想盡辦法要避免的。為了優化你的變動管理策略，你需要了解不同類型變動的代價：
1、商業方案變動的代價。這種變動主要包含需求的重寫或者要面對完全不同的用戶或需求。應該在先啟階段就處理這些變動或適應這些變動，隨著進入“精化”階段，這種變動所帶來的代價會越來越大。
2、框架變動的代價。遵照RUP，在價值較高的精化過程到來之前，你可以進行一些重大的框架變動。在那之后，框架變動的代價會顯著增加。
3、設計和實現的變動代價。因為你的功能更加“模塊化”或者“組件化”，這些變化看上去更加“本地化”一些，因此在構建階段它們的代價相當低。但是當初在正式版本提交階段，代價會顯著增加。
4、邊界變動的代價。裁減邊界，把一些特性放到下一個發布版本中去，對于一個產品來說代價相對較低。項目管理者可以使用這把“利劍”來確保項目的按時提交。
上面有關代價的考慮說明你應該去管理這些變動。你需要：
1、在切當的時期決定是否引入一個變動。
2、評估變動所帶來的壓力。
3、盡可能縮減變動的代價。

   出自The Spirit of the RUP
RUP的那些階段已經優化并最小化了這些變動的花費，同時增長了迎合變動的能力。這就是為什么RUP要求在先啟階段的最后，在所有的視點上達成共識；在精化階段的最后能夠有一個可以作為基線的框架結構；在beta版發布階段不再向產品添加新的特性。使用正確的工具可以為你的變動管理帶來很大的方便，并降低你的代價。