作業: 量身訂作專案的開發流程
這項作業用來自訂開發流程,以符合專案的特定需求。
規範: 環境
目的

這項作業的目的如下:

  • 根據專案的特定需求來產生大小正確的軟體開發流程。
  • 提供足夠的相關流程指引,供專案成員以可接受的品質來有效執行他們的工作。
  • 提供相關而可存取的流程說明給專案成員。
關係
角色主要執行者: 其他執行者:
輸入強制: 選用:
輸出
流程用法
步驟
分析專案
目的:  感受將面對的問題及專案所能使用的資源。

對專案的順利完成而言,交付流程與手邊的專案及專案的大小和形式需求相關,這一點很重要。流程過多比較容易得到有效、高效且具創造性的方式。流程太少則可能造成混亂的環境,通常會引起個別專案成員做本端決策,從而產生無效、不一致和無法預期的結果。

定義量身訂作的工作範圍
目的:  定義特定專案專用流程將涵蓋的流程區域。

利用類似的軟體開發專案來分析專案資源及其經驗,結果會有助於識別量身訂作的工作範圍。特定專案專用的流程不需要包括 RUP 中的所有規範,也應該不需要涵蓋 RUP 中所定義的所有角色。請記住,RUP 是適用於大範圍專案類型的流程架構,因此,對於單一特定專案而言,它必須遵循的東西會太多。您選擇要涵蓋在專案流程中的區域,會隨著專案成員現有的技術及手邊專案的本質而大不相同。以下是在定義量身訂作的工作範圍時,一些典型的考量。

  • 專案成員已有通行工作方式的區域,不需要引進新的流程和工具。比方說,如果他們知道如何測試,也許最好不要引進 RUP 的測試規範,以便限制新因素的數量。您可以將焦點放在 RUP 的某些部分,以便更正它們現有流程中的問題。請參閱概念:實作專案中的流程的「改進程序和工具」一節,以取得詳細資料。 
  • 因為沒有現有的工作方式,因而專案必須引進新流程和工具的區域(規範)。在某些情況下,並沒有現成流程和工具可依靠,這時必須引進 RUP 的大部分內容及支援的工具。請參閱概念:實作專案中的流程的「變更所有項目」一節,以取得詳細資料。 
  • 現有流程中的問題。請將焦點放在改進組織曾有問題的區域。
  • 要使用哪些工具? 如果專案決定使用特定工具,開發流程通常應該涵蓋對應的 URP 區域。
  • 專案的變更能力。當查看組織的問題時,通常會傾向於嘗試一次修正所有問題,特別是因為許多這些問題都會同時出現。但這往往是一個嚴重的陷阱。組織也如同個人,可以容受變更,但只能在有限範圍內。如果變更的能力很低,速度就必須放慢,在第一個專案中,可能只是引進 RUP 的一兩項規範。
  • 專案成員欠缺知識或很薄弱的區域。請讓開發流程涵蓋這些區域。請確定在 RUP 中很容易找到正確的資訊。

如需定義量身訂作工作範圍的相關資訊,請參閱準則:RUP 量身訂作。 

如需影響專案流程自訂方式之因素的說明,請參閱準則:流程區別

識別的改進區域不一定是在相同專案中第一次引進。請減少不明因素的數量,查看開發組織過去有過最痛苦體驗的區域。我們建議您依照概念:實作專案中的流程中所說明來反覆實作 RUP。如果是小型專案,範例:小型專案採用 RUP 中也有指引。

雖然在若干規範內可能會發現需要改進之處,但請考慮選擇在若干專案的過程中反覆引進它們,而不要致力於一次改變所有項目的方法。如果先前的專案艱難地處理了不清晰和/或不充足的需求,或使用者的主要抱怨在於交付的產品不符合他們的需求,在使用案例中引進需求及延遲引進新的 CM 流程,便是這類取捨的範例之一。

所進行的取捨與產生的範圍應該在流程中產生文件,以便與外部關係人溝通設定範圍的決策。

開發特定專案專用的內容
目的:  在 RUP 流程架構的涵蓋面被認為是對專案不足的區域中,建立其他「流程技術」。

RUP 方法架構表現在利用 UML 型 Meta 模型來定義的流程模型中。RUP 方法架構是以所謂 Unified Method Architecture (UMA) 的 Meta 模型為基礎。UMA 基礎的說明在 概念:Unified Method Architecture (UMA) 的主要功能中。 

您可以新增角色作業和/或工作成果來延伸 RUP 架構,也可以新增特定專案專用的準則 到現有的 RUP 架構中。  

在特定專案專用的流程中,應該有一組專為了提供特定說明和參考資料來產生專案構件而量身訂作的可用資源。這類資源的範例如下:

  • 如何產生特定構件的一般準則。
  • 專為了跨專案使用而自訂的範本。這些都將利用專案資訊來局部建立實例。
  • 與專案已定義的一組交付項目和所選技術相關的構件範例。
  • 可重複使用的資產,如設計型樣和程式碼庫。

在專案開始時,專案管理人員通常會協同流程工程師來選取一組適當的資源,以及在特定專案專用的流程中將它們提供給專案成員。在每次反覆開始時,都要重訪對於其他資源的需求。

配置流程
目的:  產生大小正確的流程來支援確切的專案需求。

配置流程包括選取要併入流程的方法內容(工作成果、作業、角色等)。如需每項規範要併入哪些方法元素的特定建議,請參閱針對每項 RUP 規範而提供的「<discipline name> 中的重要決策」。選取給定專案的一組正確方法內容,並一項非無關緊要的作業。為了要有效,這個流程的各個不同維度必須相關且大小正確,如專案大小(資源和行事曆時間)、形式、技術平台、領域等等。

如需個別工作成果的重要性及是否將使用它們之文件說明的分類架構相關資訊,請參閱準則:分類工作成果

定義專案的生命週期模型
目的:  定義專案的生命週期模型。

決定專案需要遵循的生命週期模型是量身訂作專案流程的一個重要部分,其中包括將流程分解成幾個階段和反覆。對這部分的量身訂作工作而言,流程工程師應該與專案管理人員密切合作,因為所選的生命週期模型會形成專案規劃流程的基礎。依專案的本質而定,您有可能需要調整 RUP 生命週期,才能比較符合特定需求。例如,相較於維護專案,開發新部署策略通常會需要較多初始階段的工作。因此,您應該根據專案的本質來調整生命週期的說明。請參閱概念:反覆,以取得各類生命週期模型的討論。

除了選取整體生命週期模型之外,決定如何執行量身訂作工作所包含的各項規範的相關工作流程,以及決定在這個專案生命週期的何時引進各部分的規範工作流程,也很重要。決定如何執行工作流程,包括決定要依照什麼順序來執行哪些工作。決定何時執行工作流程的各個部分,包括決定在生命流程的哪裡(如哪個階段)引進所選的活動。如需如何量身訂作各個 RUP 規範之工作流程的相關資訊,請參閱專為了每項 RUP 規範而提供之參照工作流程的用法附註。

這時您會想指定的其他資訊還有生命週期各個點的工作成果計時需求和形式需求。例如,在哪些階段建立和/或更新工作成果,以及工作成果需要哪種形式(例如,客戶是否需要登出)。

將流程提供給專案成員
目的:  將特定專案專用流程提供給專案成員。

在起始量身訂作工作完成之後,便可以用適當的格式,將產生的流程提供給專案小組。

利用網站來提供流程是可能性之一,網站可以放在組織網路的 Web 伺服器上,也可以安裝在各小組成員電腦之上。如果專案成員大部分時間都連著網路,這時最好部署到 Web 伺服器,以避免在專案生命週期中之流程更新所帶來的任何額外負荷。

維護流程

雖然量身訂作工作的主體是在專案初期完成,但它應該隨時保持最新,因為專案小組會在流程中發現障礙和其他問題。當流程展開時,流程本身就會帶來學習,流程工程師會參考這些學習帶來的回饋來改進流程。專案期間所進行的評量也是用來改進流程的重要輸入。

次要調整通常都由專案來處理,特定專案專用流程的更新,則是在為了即將來臨的反覆準備開發環境時進行。這些流程改進類型通常會導致更新特定流程專用的流程(如修正工作成果範本和準則)。當變更流程要求時,會產生更複雜的問題。 

反覆式開發的主要好處之一,是專案小組可以逐步改進軟體的開發方式。我們建議您每個專案都包括由下列步驟組成的流程工程微週期:

  • 定義流程
  • 根據定義的流程來執行專案工作
  • 評量您的工作
  • 修正流程


圖例
主要考量

不管執行哪個層次的量身訂作,擷取量身訂作的工作結果(可能還有基本理由)都非常重要。另外,如果量身訂作的流程想要重新量身訂作(例如,正在量身訂作的流程是針對整個組織,產生的組織流程又想要針對每個專案來量身訂作),開發已量身訂作的開發流程如何再量身訂作的準則也很重要。這類量身訂作的決策和建議可以擷取在個別文件中,也可以作為開發流程的一個整合部分。如需量身訂作層次的相關資訊,請參閱概念:量身訂作 RUP

軟體開發計劃和組織對於開發流程會有主要的影響,反之亦然。流程的量身訂作必須協同專案計劃的開發來進行。比方說,如果專案決定使用一組不同於 Rational Unified Process (RUP) 的階段,這便是量身訂作的開發流程中所應擷取的內容。 另外,量身訂作開發流程之後,必須在可執行的專案計劃中建立它的實例。如需專案規劃的相關資訊,請參閱作業:規劃階段和反覆作業:開發反覆計劃


當量身訂作流程時,我們建議您不要一次量身訂作整個流程。相反地,請將焦點放在專案接著要套用的規範上。如需流程實作之反覆方法的相關資訊,請參閱概念:實作專案中的流程。 

替代方案
RUP 可以使用許多不同的量身訂作層次。如需相關資訊,請參閱概念:量身訂作 RUP
詳細資訊