作業: 在建構版本中驗證變更
這項作業定義如何驗證「變更要求」已完成。
目的
  • 這項作業會確認「變更要求」已完成,通常是在一或多個建構版本上進行一部分測試。
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
步驟
解決變更要求

指派的角色會執行交付流程在適當區段內所定義的作業, 例如需求、分析與設計、實作、產生使用者支援資料及設計測試。 這些作業包含正常交付流程內所描述的所有正常的審查和單元測試作業。 然後,CR 會標示為已解決。表示此 CR 已完全解決,現在可以準備驗證。

在測試版本中驗證變更

當變更由指派的角色解決之後(分析師、開發人員、測試人員、技術編寫人員等), 變更即進入測試佇列,等待指派給測試人員,並在產品的測試建構版本中驗證。 在測試建構版本中已驗證的 CR,可以納入發行版本中。 在測試或發建構版本中未通過測試的 CR,將進入測試失敗狀態。 擁有者會自動轉換成解決 CR 的角色。

在發行版本中驗證變更

當已解決的變更在產品的測試建構版本中已驗證之後,CR 會進入發行佇列中,等待在產品的發行建構版本上驗證、 產生版本注意事項等,然後結束 CR。

已結束的 CR 不必再注意。這是可指定給 CR 的最終狀態。只有 CCB 審查管理員有權限結束 CR。 當 CR 已結束之後,提出者會收到電子郵件通知,說明 CR 的最後處置情形。 下列情況可能會結束 CR:1) 驗證的解決方案在發行建構版本中驗證之後, 2) 已確認拒絕狀態,或 3) 已確認現有的 CR 為重複。 在後面的情況下,將向提出者通知 CR 重複,並加入此 CR 中以利於未來繼續通知 (如需詳細資訊,請參閱拒絕重複狀態的定義)。 如果提出者希望爭取結案,CR 必須更新並重新提出給 CCB 審查。

變更要求管理中會顯示變更要求可能經歷的一般狀態。

評估及驗證結果
目的:  驗證作業已適當完成,並且產生可接受的工作成果。 

現在您已經完成工作了,這時最好驗證該項工作確實具有足夠的價值,而不只是花費在大量紙上作業。您應該評估您的工作是否具有適當的品質,並且該工作的完成狀態可以讓團隊的其他成員用作他們的後續工作之輸入。請盡可能使用 RUP 提供的檢查清單,來驗證品質和完成狀態都「夠好」。

請邀請執行下游作業而必須以您的工作成果作為輸入的人參與審查您的暫時性工作。請在您仍有時間採取動作來處理他們關心的問題時執行這個動作。您同時也應該將您的工作和關鍵的輸入工作成果做評估,以確定您已經正確且適當地重新呈現那些工作成果。 在這個基礎上,邀請輸入工作成果的作者審查您的工作,會有助於您評估您的工作成果。

請記得 RUP 是一項反覆式的交付程序,在許多情況下,工作成果都會隨著時間而演進。因此,通常並不需要(通常是缺乏生產力)對只會在緊跟在後的後續工作中用到一部分,或甚至於完全用不到的工作,做出完整的工作成果。這是因為和工作成果相關的狀況極可能會變動,因此在建立工作成果所做的假設狀況就變成不正確,導致浪費許多人力物力以及成本高昂的重做。同時也要避免浪費太多時間在呈現方式上,而導致損害內容本身的價值。在呈現方式佔極大的重要性,並且可以提交專案就具有商業價值的專案環境中,您可以考慮將呈現工作交給管理資源來做。



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