概念: 在專案中實作流程
這個概念頁面說明實作流程的整體藍圖,以及其在軟體開發專案中的支援工具。
關係
相關元素
主要說明

簡介

這些準則說明如何在軟體開發專案中,透過執行「環境規範」中指出的活動,來實作流程和工具。其中也會討論「專案管理」規範,用來處理規劃專案、識別風險以及管理、監視與評估專案等事情。  

這裡需要瞭解一件重要事情,亦即如「實作流程與工具的方式」一節的說明,有許多不同的方式可以實作流程和工具。您要選擇的方法,是視專案的現行狀態及其周邊組織而定,因此,請針對專案的現行狀態及其周邊組織做評估(請參閱 工作成果:開發組織評估)。 

這些準則說明可用來在專案中實作流程的一些可行方法。此外,概念:環境情境作法 中也會說明一些適合用來實作軟體專案環境的基本作法。如需有關修改流程實作的各個層面之詳細資訊,請參閱修改 RUP

一般規劃準則

這些一般準則適用於大部分的專案: 

  • 在專案開始之前:在專案實際開始進行之前,身為流程工程師、工具專家以及專案管理人員的所有人員,都必須接受 Rational Unified Process (RUP) 訓練。這對專案的成功與否極為重要。如果專案成員不知道應該要做什麼,他們很可能就不會順利做該做的事。
  • 初始階段:在此階段期間,您通常會專注於瞭解如何改進管理需求(「需求」規範),以及如何管理專案(「專案管理」規範)的方式。 
  • 詳述階段:到「詳述」階段尾聲時,所有流程和工具都已就位。此階段的最重要部分通常是在執行配置及變更管理,因為在「建構」階段中,工作會由開發小組平行進行。
  • 建構階段:在此階段不會引進新的流程或工具。這個階段的重點是產生產品,因此開發環境必須維持穩定狀態。在「建構」階段中,主要的動機是要使專案的所有新進人員趕快進入情況。
  • 轉換階段:不會引進新的流程或工具。在「轉換」階段中,重點會從改善專案相關的流程,移到專案後置審查、收集現行專案得到的經驗、加以彙總歸納,然後封裝成可供未來專案使用的形式。這裡收集到的這些經驗,會變成開發產品的下一個新版本時,作為改善流程和工具的投入要素。 

實作流程與工具的方法

流程形式在不同的開發組織中,會有很大的差異存在。有些組織的流程很成熟,並且具有專門的流程處理小組來負責監督全組織的流程定義與改進之道。有些組織則只注重與專案相關的修改作業。

用來修改專案流程的方法,會受組織的流程形式,以及其他多項因素的左右。例如: 

  • 開發組織的流程成熟度。
  • 專案在時間和開發資源方面的規模。
  • 專案成員先前已參與過類似的流程。
  • 專案所要求的正式程度。

如需有關會影響流程實作的各種因素資訊,請參閱準則:流程區別元件

以下是在軟體開發專案中實作流程及工具的一些基本方法: 

  • 全部更換」。這表示專案會採用完整的 RUP 以及一整套新工具。 
  • 改進流程及工具」。這表示專案決定要採用部分的 RUP 及支援工具,來改進流程和工具的某些部分。 

您要採用多少 RUP,以及要在特定的專案中實作多少新工具,是視一些因素而定。這些因素都在準則:流程區別元件 中說明。這些因素通常是在評估專案及其周圍組織時找出。這項資訊會在 工作成果:開發組織評估中擷取。

全部更換」(返回「方法...」

專案可以依據下列一或多個原因,來決定是否要採用完整的 RUP 並開始使用一套新的工具: 

  • 尚未有流程或工具存在,並且專案需要所有東西:完整的流程和所有工具。 
  • 所有或大部分的成員都是剛剛聘用的,因此沒有工作共識存在。 
  • 專案會轉移到組織的新技術,這表示現有的流程和工具都會被淘汰。 

如果您決定要在您的專案中引進完整的 RUP 和工具,則務必要以漸進形式來實作流程和工具。以逐步形式實作流程和工具時,較容易管理風險,同時專案的成員也比較不會感覺同時進行許多變更的壓力。下圖顯示在專案的生命週期中,所會開發的不同「環境」工作成果。 

 圖解說明詳見隨附的文字。

在「全新」專案中,其「環境」工作成果的演進。

計劃註解:
  • 整體:完全略過「商業模型」規範。  
  • 初始階段:旨在引進「需求」與「專案管理」規範。以減少新的因素數目,並且不會引進「需求」的使用者介面部分。專案管理人員決定要採用「專案管理人員」規範的哪些部分。 
  • 詳述反覆 E-1:「分析和設計」及「架構」是「詳述」階段最重要的工作。 「自動化測試」以及「配置與變更管理」在專案的這個階段並不是那麼重要,因為這時的專案成員人數較少。因此這可以在專案的稍後階段引進。 
  • 詳述反覆 E-2:引進測試工具和流程進行自動化測試。會引進 Rational RequisitePro 來管理變更需求。
  • 詳述反覆 E-3:在「建構」階段中,工作會由開發小組平行進行。因此,在「詳述」階段尾聲時,一定要擬定好「配置及變更管理」規範。部署管理人員會決定如何執行「部署」規範中的規範。 
  • 建構階段:不會引進任何新東西。從「環境」的角度來看,在「建構」階段的重點是要使專案的所有新進人員趕快進入情況。
  • 轉換階段:不會引進任何新東西。會視需要修正流程與工具。

改進流程及工具」(返回「方法...」

在備妥流程與工具的專案組織人員,可以開始開發系統。這些人員會有共同的工作共識,因為這是已詳細記載的工作流程。  

長期目標可能是採用完整的 RUP 以及一整套新工具。不過,短期目標則是改進流程和工具支援的一或數個區域。這些應該是具有很大改善空間的區域。 

下圖顯示一個範例,指出一個專案決定採用「需求」規範以及諸如 RequisitePro 和 Rational Rose 等工具,來改進需求的管理方式。此專案也決定要引進「分析和設計」規範。 

圖解說明詳見隨附的文字。

改進「需求」及「分析與設計」時,其「環境」工作成果的演進。 

這裡需要注意的一件重要事情是上述圖解只是一個範例。您決定要進行改善的流程部分,會因為不同的專案而有差異,這完全視各特定專案的問題和需求而定。您必須評估專案及其週圍組織,來找出您要改善的流程部分,或要引進哪些工具。

初始階段反覆範例

以下是在「初始階段」階段的反覆作業中,引進「需求」規範的一個範例。在甘特圖中的每一個項目,會在圖表之後詳細說明。 

專案管理 規畫下一個反覆作業 評估專案範圍及風險 規畫專案 管理反覆作業 監視及控制專案 構思新專案 評估專案範圍及風險 需求 測試 環境 反覆作業期間的支援環境 準備專案環境 準備反覆作業環境 流程輔助 50% 指導 RMUC RUPF 訓練 需求輔助 50% 按一下任何主題以取得詳細說明

在「初始階段」階段的反覆作業範例

對「標準 RUP 初始階段」的基本工作流程說明,亦適用於這些變體和延伸。

專案管理

使專案從剛開始的一個好點子,帶到可以決定要繼續推行或放棄的推論決策。主要的結果是初步的工作成果:商業案例工作成果:軟體開發計劃以及工作成果:風險清單草擬。

識別專案的風險,這包括與實作新的流程與工具相關聯的風險在內。其結果是產生工作成果:風險清單

規劃各個階段。其主要結果是軟體開發計劃中,標題為「專案計劃」的區段。這會包括您會在其中找到主要里程碑及其成就準則,以及「環境」規範準則的「階段計劃」。   
注意:修改過的開發流程會對軟體開發計劃具有重大影響,反之亦然。因此,專案計劃的開發作業,必須和流程修改作業維持協調一致。 

詳細規劃反覆作業,包括「環境」規範以及所有其他規範在內。其主要結果是工作成果:反覆計劃,其中具有「環境」規範的所有活動詳細資料與作業,以及所有其他流程規範。

使用流程和工具是被視為評估反覆作業的一部分。 其結果為:

專案管理人員會監視包括流程和工具在內的每日例行工作。

在反覆作業尾聲時,會重新評估風險,這包括與流程和工具相關聯的風險在內。有些風險會在反覆作業期間舒緩,並且也可能會發現新的風險。其主要結果是產生更新的工作成果:風險清單。 

需求

沒有特定變更。 

測試

定義工作成果:測試策略的某些底層機制層面,提供測試作業的起始資源推論。

測試設計師和一小組測試人員會驗證測試方法的主要元素,可對照工作成果:概念實證架構來執行,並且會驗證協力廠商元件選擇也適於進行測試。

環境

評估組織的現行狀態,並決定在第一次反覆作業中,要專注於流程的哪些部分和哪些工具。在此情況下,專案會依據評估結果,開始實作流程和工具。 
附註軟體開發計劃會對修改過的開發流程具有重大影響,反之亦然。因此,流程的修改作業,必須和專案計劃的開發作業維持協調一致。 

其結果為:

準備「需求」規範的流程與工具以及支援工具,使專案的成員可以開始使用 (當然,也可以準備其他規範)。請參閱作業:調整專案的「開發流程」

確定專案的成員知道如何使用開發流程、使用案例模型準則和工具等。除了標準的訓練課程外,我們建議您要安排一個一天的研討會,讓專案成員獲得實際經驗。請參閱作業:啟動開發流程

這項活動的執行結果如下:

系統管理員在反覆作業期間,支援開發人員。 

訓練

  • 專案的所有成員都應該參加 RUP 的概觀課程,以瞭解專案的生命週期概觀。
  • 負責訂定 RUP 規範,但未被包含在內的人員,則應該參加一個課程,以瞭解規範的詳細資料。 

指導

指導是順利實作流程的關鍵。一般而言,會需要下列輔助: 

  • 流程輔助 50%。扮演流程工程師角色的人, 支援專案管理人員以及專案中的其他人來使用和配置流程。
  • <規範特定的> 輔助 50%。 促使規範的特定工作能夠順利運作的人,其帶領研討會、審查結果以及回應特定的問題。 
如需有關指導的其餘資訊,請參閱概念:指導