前言

產品整合的目的，在於將產品組件組合為產品、確保已整合的產品適當地運作及交付產品。產品整合流程領域所談論的是將產品組件整合成更複雜的產品組件或完整的產品。

產品整合流程領域的特定目標及特定執行方法摘要(Specific Goal-SG and Practice-SP Summary)， 在CMMI-DEV V1.3 中的內容如下:

SG 1 準備產品整合
　SP 1.1 建立整合策略
　SP 1.2 建立產品整合環境
　SP 1.3 建立產品整合程序與準則

SG 2 確保介面相容性
　SP 2.1 審查介面說明的完整性
　SP 2.2 管理介面

SG 3 組合產品組件並交付產品
　SP 3.1 確定欲整合的產品組件已準備就緒
　SP 3.2 組合產品組件
　SP 3.3 評估已組合的產品組件
　SP 3.4 包裝並交付產品或產品組件

其內容與 CMMI-DEV V1.2 大致相同， 但是其中的 SP1.1 則由原本的 “決定整合順序 (Determine Integration Sequence)” 修改成為 “建立整合策略 (Establish and Integration Strategy)”。

本文的目的即是探討 CMMI-DEV V1.2 SP1.1 “決定整合順” 與CMMI-DEV V1.3 SP1.1 “建立整合策略” 的內容變化以及提供“整合計畫”範本供參考。

CMMI-DEV V1.2&V1.3 在”產品整合流程領域(Product Integration – PI)”“簡介 (Introductory Notes)”章節的異同

CMMI-DEV V1.2

此領域的範圍，是依據既定的整合順序與程序，逐漸地在一個階段或漸進的階段組合產品組件，以達成完整的產品整合。整個流程領域中，產品及產品組件的意涵也包括服務及其組件。 (The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration sequence and procedures. Throughout the process areas, where we use the terms product and product component, their intended meanings also encompass services and their components.)

CMMI-DEV V1.3

此領域的範圍，是依據既定的整合策略與程序，逐漸地在一個階段或漸進的階段組合產品組件，以達成完整的產品整合。整個流程領域中，產品及產品組件的意涵也包括服務，服務系統及其組件。 (The scope of this process area is to achieve complete product integration through progressive assembly of product components, in one stage or in incremental stages, according to a defined integration strategy and procedures. Throughout the process areas, where the terms "product" and "product component" are used, their intended meanings also encompass services, service systems, and their components.) 新增下列內容: 對於生產線而言，產品依照產品線生產計畫進行整合. 產品線生產計畫內容說明組裝程序，包括採用的核心資產(assets)以及依照核心資產(assets)衍伸出之各生產線主要差異。 在敏捷式開發環境(Agile environments)，產品整合是頻繁的，經常是每天要進行的活動。例如，對於軟體而言，可以運作的程式碼是連續的在名為"持續整合(continuous integration)"的流程活動中加入程式碼庫之中。除了提到"持續整合"，產品整合策略也可以說明如何加入供應商提供的元件，以及如何依照功能進行建置(build)(in layers vs. -vertical slices), 以及何時重組 (refactor) 。 產品整合策略應及早於專案進行中建立，並依照待整合的元件介面、外部輸入、資料交換、應用程式介面的衍生或變化進行因應及調整 。

特定執行方法SP1.1 “建立整合策略”在 CMMI-DEV V1.3 中的主要內容

CMMI 對於重要的工作產出物，在標明“建立(establish)”之後， 都會再強調 “維護(maintain)”的重要性. 以強調因環境或條件改變時， 工作產品內容也要隨之進行調整。所以在“建立整合策略”的主要標題下， 同樣的加上“建立及維護產品整合策略”的輔助標題。並說明:"產品整合策略” 敘述接收，組裝，評估產品組件及產品的方法。"

"產品整合策略” 內容舉例如下:

• 完成待整合的產品元件 (e.g. 以何種順序)


• 以單一建置(single build) 或是以循序漸增的方式進行建置(progression of incremental builds) 進行組裝及評估。


• 在採用迭代反覆式開發環境(iterative development)時， 在每一次的迭代中加入測試專案。


• 管理介面。


• 採用模式(models)， 雛型(prototypes)， 模擬(simulations) 等方式的協助， 來評估介面及整合的結果。


• 建立產品整合的環境。


• 定義程序及準則。


• 準備適當的測試工具及設備，在需要的時候可以取用。


• 管理產品的層次，架構及複雜。


• 記錄結果並進行評估。


• 處理例外狀況(Handling exceptions)。

整合計畫範本 (Integration Plan Template)

本文件的目的

專案的整合及驗證策略與系統及其如何分解到子系統的架構設計關係密切. 雖然每一項專案的目標都不相同，但是整合計畫都是要將元件整合成子系統，再將子系統整合成為完整的系統，整合活動進行的方式也要配合部屬策略，這是整合計畫的第一個目的。

第二個目的是描述每一項整合步驟的參與者及待辦事項。每一項整合步驟必須組合不同的資源成為適當的整合團隊。整合計畫中必須指出所需要的資源，以及需要的時間及地點。

依專案特質對此文件進行調適

整合計畫並非一定要寫成一份分別獨立的文件的。須依照系統及開發工作的複雜性，以及最後佈署階段的繁複程度來決定整合計畫的內容。

例如佈署策略須要在多數地點進行安裝,整合活動的順序複雜性就會升高許多。通常在子系統由不同團隊進行開發時，其整合的複雜性相對較高。尤其是各個子系統的開發團隊分屬於不同的下包商承攬完成的時候，複雜度及難度是必然會提昇的。在這種情況下，相較於同一團隊從事被整合兩端的工作已經清楚相關的溝通及介面重點，他們需要得到比他們需要完成的子系統任務更多的資訊來進行相關的整合工作。同樣的複雜性也發生在外部系統隸屬於不同單位或是同單位但是不同部門的情況時。

如果沒有必要另立整合計畫，可以在專案計畫(Project Plan)，軟體工程管理計畫(SEMP)，驗證計畫(Verification Plan)或是開發團隊的軟體開發計畫(Software Development Plan)中包含相關的整合計畫內容。

檢查清單:重要的訊息

　整合計畫是否包括專案中所有元件及子系統 (不論自行開發或是外購)的整合?
　整合計畫是否說明將納入整合的外部系統 [例如 通訊網路, 現場設備, 由其他單位持有的完整系統
　　等等…]?
　整合計畫是否完全配合佈署策略? 例如，子系統及系統將於何時及何地進行佈署?
　整合計畫中定義的整合步驟是否與驗證計畫中的驗證活動一致?
　對於每一項整合步驟，須進行整合的元件或是子系統是否都有定義清楚?
　對於每一項整合步驟，所有參與人員的角色及權責是否都在整合計畫中載明?
　整合計畫是否包括每一項整合步驟的順序及時程?
　合計畫是否有指出整合時遇到的問題須如何記錄下來並與以解決?

整合計畫範本 (含整合策略)

章節	內容
標題頁	標題頁應遵循程序及格式指引。至少應包含下列資訊： [填入專案名稱] 整合計畫 合約編號 文件正式核准日期 文件負責單位 內部文件編號(如果有) 版本編號及發行日期
1.0 目的	簡短說明本文件的目的即是對驗證(verification)前所進行之專案元件及子系統的整合活動計畫。
2.0 專案範圍	本節簡短的介紹所計畫的專案和待建的系統。特別要強調的是該專案的部署複雜性和挑戰。本章節可能參考專案中其它較先完成的文件。重要的部分是在這份文件中首次提到的利益相關者[stakeholders]。
3.0 整合策略	本章節告訴讀者什麼是整合的高階計畫(high level plan)。最重要的是，為什麼整合計畫採用這樣的結構。由於整合的過程中有時會遇到一些衝突，整合計畫須顧及這些限制情況。而且是建置(build)、整合(integrate)、驗證(verify)以及佈署(deploy)整個大範圍流程活的的一個環節。 這項策略必須與專案的策略同步一致。所以，即使是一般中等性複雜的專案，整合策略也須在此依照清楚且簡潔的專案目標進行高階且完整的敘述，也可能需要進一步分析多項不同的策略以及何以選定某些策略的原因。 建置計畫(the Build Plan)、驗證計畫(the Verification Plan)以及佈署計畫(the Deployment Plan) 採用相同的策略基礎。所以可能只需要在專案計畫或是軟體工程管理計畫中一起對於策略的正確性進行解釋即可。本章結包含了整合過程中的每一個步驟。也須大致說明每一項整合步驟相關的操作性功能(需求)是哪些? 以及要納入整合的元件是哪些等等。這部分與先前提到目標及目的(goals and objectives)連結，以使得利益相關者[stakeholders]能夠瞭解每一個整合步驟的原由。這項彙整層次的策略內容也說明了所有整合工作的期程。
4.0 Phase 1 Integration 第一階段整合	本章節及後續章節，對於整合流程的每一步驟進行定義及說明，其主要的作用是確認所有需要的參與者是哪些人以及他們應該完成哪些事。一般來說，每一項整合步驟應指出： 活動的地點。 專案開發的儀器設備以及需要進行初次整合的軟體產出物，本項內容剛開始時只是初步(高階)的清單，但是逐漸的這項清單必須正確而完整的顯示組件號及數量。 此次整合步驟所需的任何支援性設備[特別的軟體，測試用的硬體，特定軟體功能程式，用來模擬將要被整合的軟體元件的驅動程式，外部系統…等等].這些支援性設備也很可能在後續的驗證步驟中用到。 安裝後所需要進行的所有的整合步驟，包括與安裝現場的系統及其他地點的外部系統進行整合。 簡要說明在整合步驟後要進行的驗證活動[與驗證計畫內容一致]。 每一次整合步驟的負責單位。 每一次整合步驟的期程。
5.0 多重階段(phase)的整合步驟 [1 或 N 步驟]	可以依照第3.0 章節的格式， 依需要加入所需的整合內容。

參考資料

1.SEI. CMMI For Development Version 1.2, CMMI-DEV V1.2, 2007

2.SEI. CMMI For Development Version 1.2, CMMI-DEV V1.3, Nov 2010

3.U.S. Department of transportation – Federal Highway Admistration – System Engineering Guidebook for ITS(Intelligent Transportation Systems).