利用類似的軟體開發專案來分析專案資源及其經驗,結果會有助於識別量身訂作的工作範圍。特定專案專用的流程不需要包括 RUP 中的所有規範,也應該不需要涵蓋 RUP 中所定義的所有角色。請記住,RUP
是適用於大範圍專案類型的流程架構,因此,對於單一特定專案而言,它必須遵循的東西會太多。您選擇要涵蓋在專案流程中的區域,會隨著專案成員現有的技術及手邊專案的本質而大不相同。以下是在定義量身訂作的工作範圍時,一些典型的考量。
-
專案成員已有通行工作方式的區域,不需要引進新的流程和工具。比方說,如果他們知道如何測試,也許最好不要引進 RUP 的測試規範,以便限制新因素的數量。您可以將焦點放在 RUP
的某些部分,以便更正它們現有流程中的問題。請參閱概念:實作專案中的流程的「改進程序和工具」一節,以取得詳細資料。
-
因為沒有現有的工作方式,因而專案必須引進新流程和工具的區域(規範)。在某些情況下,並沒有現成流程和工具可依靠,這時必須引進 RUP 的大部分內容及支援的工具。請參閱概念:實作專案中的流程的「變更所有項目」一節,以取得詳細資料。
-
現有流程中的問題。請將焦點放在改進組織曾有問題的區域。
-
要使用哪些工具? 如果專案決定使用特定工具,開發流程通常應該涵蓋對應的 URP 區域。
-
專案的變更能力。當查看組織的問題時,通常會傾向於嘗試一次修正所有問題,特別是因為許多這些問題都會同時出現。但這往往是一個嚴重的陷阱。組織也如同個人,可以容受變更,但只能在有限範圍內。如果變更的能力很低,速度就必須放慢,在第一個專案中,可能只是引進
RUP 的一兩項規範。
-
專案成員欠缺知識或很薄弱的區域。請讓開發流程涵蓋這些區域。請確定在 RUP 中很容易找到正確的資訊。
如需定義量身訂作工作範圍的相關資訊,請參閱準則:RUP
量身訂作。
如需影響專案流程自訂方式之因素的說明,請參閱準則:流程區別。
識別的改進區域不一定是在相同專案中第一次引進。請減少不明因素的數量,查看開發組織過去有過最痛苦體驗的區域。我們建議您依照概念:實作專案中的流程中所說明來反覆實作 RUP。如果是小型專案,範例:小型專案採用 RUP 中也有指引。
雖然在若干規範內可能會發現需要改進之處,但請考慮選擇在若干專案的過程中反覆引進它們,而不要致力於一次改變所有項目的方法。如果先前的專案艱難地處理了不清晰和/或不充足的需求,或使用者的主要抱怨在於交付的產品不符合他們的需求,在使用案例中引進需求及延遲引進新的
CM 流程,便是這類取捨的範例之一。
所進行的取捨與產生的範圍應該在流程中產生文件,以便與外部關係人溝通設定範圍的決策。