目的:「變更控制」程序可確保以一致、受管制的方式來評估和套用提出的系統變更。
|
子步驟
|
工具輔助
|
詳細資訊:概念:變更要求管理
|
下列活動圖顯示處理變更要求的一般程序。(在圖中請按任意處來顯示概念:變更要求管理的完整說明)
「變更要求表單」是一項正式提出的構件,旨在用來追蹤所有要求(包括新增特性、加強功能要求、問題、需求變更等等)。應該包括整個專案生命週期的相關狀態資訊。 所有變更歷程都會隨著 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
|