作業: 準備專案的準則
這項作業說明如何準備專案特有的準則。
目的

這項作業的目的如下:

  • 取得現有的準則或開發新的準則供專案使用。
  • 提供現有的準則給專案成員使用。
  • 與主題專家一起合作,根據消費者的意見來更新這些準則。
關係
角色主要: 其他的: 協助:
輸入強制:
選用: 外部:
輸出
步驟
確認專案的準則需求
目的: 確認專案需要哪些準則。

根據需要產生哪些工作成果及每一項工作成果所需的正式性,確認專案所需的準則。 準備準則是調整專案的流程的一部分工作,流程工程師會投入很多時間與專案經理一起討論,決定應該提供哪幾種準則給團隊使用。

專案特有準則有多種用途,包括:

  • 提供規定的和適當的指引來產生特定的工作成果。
  • 確定工作成果以一致的方式開發且遵循既定的慣例和樣式。
  • 描述專案必須遵守的特定標準。
  • 指派經驗人士來指導職員審查工作成果的品質和完整性。

下表描述軟體專案的一些最常見的準則。RUP 提供相關範例,可做為專案調整的起點。

準則的類型
角色投入
生產者
消費者
商業模型準則
描述如何塑造商業使用案例、商業工作者及事業實體。當專案必須正式塑造企業來建立新系統時,應該考量這些準則。 商業程序重新設計的程度或商業程序的複雜性,決定必須達到的綜合性。

商業流程分析師 商業流程分析師、企業企劃者、技術審查人員
使用案例建模準則
只要使用案例在捕捉系統行為時扮演重要角色,就有需要。應該包含建模慣例,例如使用的關係、文字說明要遵循的樣式。

系統分析師 系統分析師、需求規劃人員、設計師

設計準則
架構定義的成果。描述設計、架構設計及實作時要遵循的準則。

軟體架構師 設計師、實作人員、技術審查人員

程式設計準則
專用於專案選擇的實際實作語言和類別庫。這些準則應該指定如何呈現程式碼版面和註解、如何使用命名慣例及如何利用語言特性。 也應該描述某些語言特性相關的預防措施。

軟體架構師(重要「實作人員」從旁協助) 實作人員、測試人員
使用者介面準則
應該在建立使用者介面方面提供專案特有的規則和建議。通常引用外部書籍,例如 Microsoft® Corporation 出版的 The Windows Interface Guidelines for Software Design。

使用者介面設計師 使用者介面設計師、設計師、實作人員

工具準則
描述專案如何善用選擇的工具集。您可以選擇為每一項工具提供一套準則。工具準則通常包含:

  • 安裝資訊,例如版本、配置參數
  • 功能的限制及專案決定不使用的功能
  • 解決方法
  • 與其他工具的整合,包括要遵循的程序、使用的軟體及套用的原則。
工具專家 工具專家、測試人員、系統管理員、工具使用者
測試準則
用來記錄對特定專案的測試流程執行方式的調整(通常是策略性),並於動態使用測試流程時捕捉專案特有的慣例。 測試完成準則及缺失管理準則即為測試準則的例子。

 
測試設計師 測試設計師、測試人員、測試分析師

附註:您不必草率決定準則。在針對反覆來準備環境時,通常就會發現準則的需求和具體的範例。

準備專案使用的準則
目的: 將找到的準則提供給專案成員使用。

在分析最後找到的準則時,決定「購買或建置」是一項重要的決策。 雖然可能免費取得所需的準則,但您一定要衡量根據專案情況所需的調整成本與針對特定需求來開發準則的成本,或甚至完全放棄這些準則。

子主題:

取得現有的準則 跳至頁面頂端

負責專案特有流程的「流程工程師」會不斷尋找有用的現有準則或範例,以協助專案成員以更高的效率來生產更高品質的軟體。 有些準則可能早已存在公司的資產儲存庫,通常是一套累積「組織特有慣例」。 其他準則歸類為「公認標準」,可以在現有的文獻中發現或透過網際網路取得。

開發新的準則 跳至頁面頂端

大多數準則最初會做成專案工作成果,例如專案內一些微流程的文件, 就像其他很多資產一樣,有些人會從專案範圍以外的觀點來看待準則的價值,並認為可以重複使用。

決定在專案內建立新的準則時,請確定受到適當的重視且視為內部專案工作成果。 這包括分配資源來建立和驗證,並且納入適當的反覆計劃中。

首先,極力建議針對專案的特殊環境來開發準則。有太多案例顯示只為了在未來重複使用,而將全部精力貫注在工作成果一般化,而非針對目前的特定用途來開發,最後導致專案失控。 投入改良組織的流程時,請考慮讓產生的準則可以在未來的專案中重複使用。 將準則或任何工作成果調整為可重複使用的資產時,最好不要一開始就將單一專案的預算納入考量。

專案的生命週期內隨時可能會開發新的準則。通常是「即時」開發,或透過作業的方式來記錄成功方法,以產生其他工作成果。

調整準則 跳至頁面頂端

準則和範例必須符合專案的環境,不然就毫無用處。 流程工程師及一些重要的消費者代表要負責調整準則來符合專案。 尤其,必須花時間調整從其他專案中取得的準則,因為這些準則可能是在稍微不同的環境下開發。

您應該捕捉任何調整決策,因為在未來需要重複使用相同準則的專案中,可能就證明確實有用。

提供準則 跳至頁面頂端

就像調整對於準則的重要性一樣,能否方便地取得準備好的準則也一樣很重要。 消費者必須清楚瞭解在何處可以找到準則或範例,以及應該將使用意見提供給誰。

您可以利用 RUP 外掛程式技術在流程發佈網站上提供準則,而準則可以與相關的工作成果和作業產生關聯。 如需進一步的資訊,請參閱概念:調整 RUP。 

維護準則
目的: 根據消費者的使用經驗來改進準則。

在任何重視重複使用性的組織中,專案必須提供資產使用上的意見,這對於流程改良非常重要。 切記,大多數良好的作法通常會臻於完美,因為以前就用過許多次,且也花過時間來微調和改良。

在發現準則的問題或察覺到可能的改進之處時,專案可以選擇修正準則,或提出變更要求,放在專案之外解決。 採取何種作法通常取決於流程工作在組織內的正式性及爭議的複雜性。 「專案經理」應該考慮在每一次反覆中規定時段,視情況來修訂和進一步開發準則。 最好提供一個簡單好用的討論區,方便團隊成員在發現可能的改進之處時立即記錄下來。

內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊