作業: 建立變更控制流程
這項作業定義如何建立「變更控制流程」。
目的

採用標準、書面變更控制流程的目的是為了確保在專案內以一致的方式做變更, 且適當的關係人可以掌握產品的狀態、狀態的變更,以及這些變更對於成本和排程的影響。

關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
建立變更要求流程
目的:「變更控制」程序可確保以一致、受管制的方式來評估和套用提出的系統變更。 
子步驟
工具輔助
詳細資訊:概念:變更要求管理 

下列活動圖顯示處理變更要求的一般程序。(在圖中請按任意處來顯示概念:變更要求管理的完整說明)

管理 CR 的作業範例 頁面頂端

概念:變更要求管理 提出者、CCB、指派工作者及測試人員之間的 CR 流程。

完成變更要求表單 頁面頂端

「變更要求表單」是一項正式提出的構件,旨在用來追蹤所有要求(包括新增特性、加強功能要求、問題、需求變更等等)。應該包括整個專案生命週期的相關狀態資訊。 所有變更歷程都會隨著 CR 保留下來,這包括所有狀態變更,以及變更的日期和原因。這項資訊可用於任何複審及最終結案。工作成果:變更要求有提供「變更要求表單」範例。

下列狀態圖顯示「變更要求」可能經歷的典型狀態。(在圖中請按任意處來顯示概念:變更要求管理的完整說明)

CR 的狀態和轉換範例 頁面頂端

概念:變更要求管理 新 CR 的處理流程。可能的狀態包括「提出」、「擱置」、「未決」、「拒絕」、「指派」、「解決」及「驗證」。

分析變更要求 頁面頂端

提出「變更要求」之後會經過分析來確定真的有效,且適當的技術和管理人員會開始審查「變更要求」來評估有效性。 「變更要求」必須在開發團隊內以各種層次進行審查。 小組負責人通常會審查和核准任何成員提出的「變更要求」。 不過,如果變更範圍超出團隊的責任,則提升進入下一個審查層次。 如果變更的影響擴及數個不同的開發團隊,則由「變更控制委員會」審查。 在 Rational Unified Process 中,以「變更控制經理」角色來代表「變更控制委員會 (CCB)」的角色。

偶爾,報告的系統故障很可能是由於使用情況,與系統實作無關。 也可能是已報告「問題」且正在解決。

根據在目前專案願景或授權下是無效、重複或「超出範圍」,分析步驟的結果可能會接受「變更要求」或拒絕。

評估變更要求的成本 頁面頂端

對於有效的變更,下一步是根據對整體系統造成的影響及實作的難易度來評定和估計變更的成本。

成本估計步驟的結果由 CCB 進行評估。CCB 會從策略、組織及技術觀點來審查「變更要求」及影響。 CCB 必須裁定「變更要求」是否值得推動。

套用變更要求 頁面頂端

「變更要求」一經核准之後即可套用至軟體。修訂後的軟體接著進入品質保證檢查,確定變更符合專案採用的慣例,且對現有軟體的其他部分無不良影響。

完成變更之後,新版的軟體會放入產品的測試建構版本中驗證,接著納入整體軟體的「發行」版本中進行驗證。

維護變更歷程 頁面頂端

隨著軟體不斷變更,必須將所有變更情形記錄下來。

在每一個軟體元件的開頭和在變更要求之內維護變更歷程是一項很有效的作法。

在元件標頭中維護的變更資料類型可能包括:

修改歷程

版本 修改者 日期 變更 原因

1.1 Bruce Bogtrotter 98.05.01 測試範圍 CR#232

1.2 Maria Mussolini 98.06.02 需求 CR#454

成立變更控制委員會
目的 成立「變更控制委員會 (CCB)」來核准基準配置項目的所有變更。 這個小組的職責是確定所有提出的變更都有適當的技術分析和審查,且形成文件供追蹤和審核。 
子步驟

CCB 會視情況定期召開會議。

CCB 的基本工作是宣佈產品基準線,並審查基準線的變更及核准、反對或延遲實作。

選取成員 頁面頂端

此步驟的目的是成立 CCB,由同儕之間具有實權的「正確人士」組成,且有足夠的專業知識可以阻止愚蠢或不划算的變更提案。 CCB 必須由所有受影響的組織或關係人的代表組成,例如:

  • 使用者
  • 開發人員
  • 測試群組
  • 專案管理

任命 CCB 主席 頁面頂端

CCB 主席必須來自「專案管理」部門。主席要有能力明確地解決團隊的衝突,貫徹小組在專案上的決議。

CCB 的決策一定要達成共識。團體互動會反映開發專案的合作性質。 主席的角色是培養這項合作願景,必要的話,採取片面行動。

開會評估變更提案 頁面頂端

CCB 必須視情況定期開會,確保適時地審查和處理「變更提案」。 開發團隊必須將此小組視為可信賴的團體,將可能令專案陷於停頓的問題交由此團體解決。

定義變更審查通知通訊協定
目的 變更審查通知通訊協定的用途是確定在提出「變更要求」時會通知適當的幕僚成員。
決定誰應該審查各項工作成果。 
工具輔助:  使用 Rational ClearQuest 定義變更和審查通知

此步驟的輸入是專案期間要開發的工作成果清單。

幕僚成員必須審查產品相關的工作成果,判斷是否達到規定的專案品質標準,以決定是否進入下一個開發階段。 如果產品未通過審查,則必須經過重做、變更及複審。

為了讓審查「發揮功用」,必須由瞭解變更或強化提案的範圍和影響的正確人士來評估產品。 再者,審查也必須「符合成本效益」,以免主要實作人員和整合人員的工作時間浪費在生產「低衝擊力」的缺失。

需要參與審查的幕僚成員是「產品」生產者、接收者及管理三方的代表。 對於在產品品質上有既得利益的所有關係人,這可確保由關係人決定產品是否可以進入下一個開發層次。

在團隊環境中,整個專案會分解為活動。活動分配給負責人來實作和整合。 例如,整個系統分割為子系統,再分割為個別套件。 負責實作套件的團隊成員必須確定所做的變更由子系統內的同事來審查,也由其他子系統中受變更影響的其他人來審查。

審查和變更通知原則是為了傳達給同事和小組負責人,以及提議變更的接收者,讓他們有機會審查和評論提案。

如需這個主題的進一步指引,請參閱概念:變更要求管理


 

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