當這項作業開始時,已交付實作子系統來滿足工作成果:整合建置計劃中所說明的下一(「目標」)建構版本之需求,回想整合建置計劃可能會定義反覆中的若干建構版本之需求。依將整合之子系統的複雜度和數目而定,產生目標建構版本比較有效的方式是分幾個步驟來進行,在每個步驟中加入其他子系統,產生一系列的中間「迷你」建構版本,在這個方式之下,針對反覆所規劃的每個建構版本又可能會有它自己的臨時中間建構版本序列。這些都要接受最低限度的整合測試(通常是整合建置計劃所說明的這個目標建構版本的一小組測試),以確定新增內容相容於系統整合工作區中已存在的內容。利用這個方法來隔離和診斷問題應該會比較簡單。
整合者在解決任何合併衝突的過程中,漸進地接受交付的子系統,將它們加入系統整合工作區中。建議您關聯於分層結構,由下而上完成這項作業,確定子系統的各個版本一致,同時將匯入納入考量。
子系統的漸進式會編譯和鏈結到中間的建構版本中,之後,這個建構版本便交給測試人員執行最低限度的系統整合測試。
這個圖顯示三次漸進式所產生的建構版本。部分子系統只是用來作為 Stub,以便編譯及鏈結其他子系統,以及提供最低限度的執行時期行為。
序列中的最後一次漸進式會依照整合建置計劃所規劃來產生目標建構版本。在進行最低限度的測試之後,便是建立這個建構版本的起始或臨時基準線 - 呼叫「配置管理」規範中的 作業:建立基準線。這時會將建構版本提供給測試人員來進行完整的系統測試。這項測試的本質和深度將依照整合建置計劃來規劃,最終反覆建構版本必須遵循反覆測試計劃中所定義的所有測試。
|