Solution Guide for Migrating UNIX Build Environments

第 2 章 - 構想建置遷移專案

本页内容

簡介與目標
成立建置遷移小組
定義專案結構
定義業務目標
評估目前的情況
建立願景和定義專案範圍
定義高階需求和使用者設定檔
開發解決方案概念
評估專案風險
摘要

簡介與目標

本章會提供完成 UNIX 建置系統遷移專案的第一階段需要的背景和技術資訊。「構想」階段是規劃的早期形式，其主要目標是建立專案目標和限制的高階觀點，以供業務及 IT 兩方面達成協議。雖然 IT 專案可以源自於 IT 組織或其服務的業務單位，但是遷移專案的原動力很可能來自於業務方面。一項符合業務需求的解決方案，會由確立業務機會或是解決方案預期解決的問題開始。下一個步驟，是描述客戶環境的未來構想。這些描述 (願景) 可以由專案小組仔細策畫，或是由業務單位傳達需求，並且視需要進行協商，最後記錄於願景/範圍文件中。業務和 IT 兩方面必須針對願景/範圍文件達成協議，專案才能繼續進行。基本上，願景是小組想要達成的目標，而範圍則會將專案限制在這個專案可以達成的範圍內。

在這個專案階段中，會指派「專案經理」(PM) 負責管理專案並且組織核心專案小組。參與專案的每位成員協助詳細瞭解問題，並且明確表達出專案的願景。專案成員定義業務需求、確定使用者需求 (按照組織內部將使用技術的各種角色加以判定)，並且針對所考慮的技術來評估業務目前的狀況。

專案小組運用這項詳細資訊來開發解決方案概念，這是解決方案將如何解決業務問題的高階描述。解決方案概念描述建置及履行解決方案所需的做法，並且還記載了業務和設計目標、功能、假設及限制。解決方案概念還定義專案的成功準則，協同小組建立範圍；現行工作將達成的願景部分。解決方案概念及範圍都會併入願景/範圍文件中。

例如，可能需要完整的 Visual Studio 建置系統 — 就是願景 — 但是第一交付日期的時間太倉促而無法達成；解決方案的概念將會超出範圍。 make 遷移可能較為迅速，所以範圍會改變解決方案的概念。但是，仍然必須規則完整的 Windows 建置系統，以便日後發行。所有的資訊都將會記錄於願景/範圍文件中。

最後，專案小組進行初步風險評估，企圖確立並且證實專案所面臨的各種風險。專案小組會將這些風險記載於風險評估文件中。

專案的第一個階段結束於「願景/範圍已核准」階段性目標。若要達成這項階段性目標，客戶 (企業贊助者)、關鍵參與者 (stakeholder) 及專案小組成員都必須接受願景/範圍文件的內容 (通常在正式的會議中)，認定此文件是提議的解決方案及解決業務問題的規畫書。達成此階段性目標，也表示已經組成專案小組同時已對風險進行了評估。在「構想」階段結束時，業務和 IT 都應該要明確瞭解專案目標，同時專案小組可以開啟制定達成目標的特定計劃。如需有關如何組織專案小組及工作職責的特定指導，例如，撰寫願景/範圍文件、建置解決方案概念以及判定專案風險，請參閱《UNIX 遷移專案指南》(英文)。

如同＜簡介＞章節的內容所述，就適用於 UNIX 遷移專案的軟體建置系統而論，「構想」階段包含一項關鍵性的決定：是否要從 UNIX 遷移指令行 make 架構建置系統，還是要在 Windows 上建立新的 GUI 架構建置系統。這項決策將會影響整個遷移的過程。

表 2.1 可以用來作為檢查清單，檢查達成「構想」階段目標所需的主要工作。本章中的技術資訊，是達成 UNIX 建置遷移專案工作所需的相關資訊。

表 2.1 主要工作檢查清單

工作
成立建置遷移小組 — 小組成員的職責？
定義專案結構 — 小組成員的工作方式？
定義業務目標 — 排定優先順序？
評估目前的情況 — 確立開發基礎結構目前及期望的技術及業務狀態。
建立願景和定義專案範圍 — 專案的期望結果，以及可能會限制結果的事項？
定義高階需求和使用者設定檔 — 遷移的必要項目以及使用新系統的人員？
開發解決方案概念 — 專案小組採用的遷移策略？
評估專案風險 — 會發生錯誤的事項，以及專案小組成員應採取的行動？

以下各節資訊會詳細說明每項工作。

還會說明低處理程序、低工作量的替代方案。

成立建置遷移小組

第一步驟是指派建置遷移的責任，包括建立建置遷移小組。小組可能是擁有所屬成員資格的明確實體，或者可能是應用程式遷移內的虛擬小組。這兩種情況下的遷移技術細節極為相似。而這兩種案例的差異在於基礎結構，包括專案管理、測試、文件記錄及部署。

在「明確實體」案例中，遷移是 IT 部門的責任；在「虛擬小組」案例中，遷移是應用程式開發人員的責任。當然可以實行這些案例的某種組合，但是說明整個遷移範圍的這兩個部分是為了協助您決定如何指派建置遷移的責任。

這兩項案例之間的差異可以反映出組織處理應用程式的方式：一個群組可能負責建置及管理所有應用程式，或者每個小組可以處理所屬的應用程式。以下各節將討論這兩種基礎結構模型之間的差異，以及這些差異如何影響建置遷移。

將責任授予單一群組 (明確實體案例)

對於擁有許多不同群組或部門皆建置所屬工具及應用程式的大型企業，通常會採用這項做法。一個群組 (通常是 IT 部門) 負責決定適合組織應用程式的最佳遷移策略，並且負責提供一致的方法及工具集，而且還負責所有應用程式遷移的系統支援。群組也會提供遷移建置建構程序所需的工具。

在下列情況下，由其他小組負責遷移建構程序是最佳的做法：

• 多個小組正在遷移多個應用程式。

• 組織要求所有小組採用一致的處理程序。

• 一個群組控制建構程序。

• 各小組之間已細分遷移的各種層面 (將程式庫分派給某小組，將應用程式分派給另一小組等)。

• 已經決定適用於多個專案或群組的遷移策略。

將責任分派給多位開發人員 (虛擬小組案例)

在這個案例中，涉及 UNIX 應用程式遷移的部門極少，所以每個群組都要遷移所屬的應用程式及建置程序。

這項案例的優點包括：第一，建置/建構程序的開發人員是使用者也是客戶；第二，很容易明白應用程式與建置系統的相互依存性。缺點是，如果有一組以上群組正在進行遷移，就會重複工作。

在下列情況下，虛擬小組案例是適合的選擇：

• 僅遷移一個應用程式或一個來源樹狀結構。

• 遷移專案的規模較小。

• 群組間的建置程序不需要一致，或是小組已經以一致的一組 makefile 著手開始進行。

• 應用程式開發及建構小組分佈各地 (多個地點)

定義建置程序的建置人員

任何開發專案都具有已執行的數項功能，例如，排程、開發、測試、使用者支持以及在專案結束時發行產品。可以由個人、小型群組或大型小組負責執行這些功能。

如果將開發建置程序的責任指派給個別群組 (明確實體案例)，則會以類似個別專案的方式來處理建置遷移，同時建置遷移小組會指定負責這些功能的人員。

如果將開發建置程序的責任指派給負責應用程式遷移的開發人員 (虛擬小組案例)，則已經獲派這些功能及負責應用程式遷移專案的部分或所有人員，將會同時負責建置遷移小組與應用程式遷移專案之責任。

這些功能會被組織為專案小組的角色。角色是一種針對專案中必須完成的事項來分派責任的方式，確保專案能成功完成。在下列專案角色清單中，會依據所需的不同技術設定來分派工作。 這份清單會說明應用程式遷移與建置遷移小組之間的成員資料可能會部分重疊的情形。因為某些角色原本就有所衝突，所以建議小組的成員不要少於三個人。然而，非常小型的專案會僅指派一人或兩人負責所有角色。接受指派的人員，應該要注意必須讓不同角色的目標達到平衡。

產品管理角色 (滿足客戶需求)

這是服務客戶的角色，通常是由應用程式遷移中負責服務客戶的同一位人員擔任。這個角色的一項挑戰，在於建置系統的客戶不是應用程式的客戶：建置系統的客戶滿意度表示必須滿足建置應用程式的開發人員需求，而不是滿足使用者的需求。

程式管理角色 (在專案限制範圍內履行解決方案)

這個角色負責管理專案及解決方案架構功能，因此需要極佳的組織能力及軟體開發知識。獲派這個角色的人員，應該與應用程式遷移專案所派定的產品管理角色人員密切配合，共同協調專案計劃及排程 (如果專案是小型專案或發生在虛擬小組案例的情況，則可能由同一人員擔任這兩個小組的產品管理角色)。這個角色必須面對的挑戰，是建構遷移的期限應該在應用程式遷移的期限之前，這是因為如果無法建置遷移的應用程式，就無法進行測試及發行。在大型遷移方面，必須將完成建置系統遷移定義為階段性目標之一。

開發角色 (按照詳細計劃進行建置)

這個角色負責的事項，是遷移及開發建置程序。開發人員必須瞭解軟體建構的技術細節，例如，編譯器詳細資訊、連結器詳細資訊以及應用程式對外部程式庫的依存性。開發人員必須熟諳軟體程式設計概念 (例如，多執行緒)，並且還必須具備 Windows 架構和 Windows 程式建構的專門知識。其中的關鍵，是一或多位開發人員必須瞭解目前的建置系統以及可行的 Windows 解決方案運作方式。

測試角色 (唯有在確認並解決所有解決方案品質的問題之後，才能核准發行)

這個角色負責產生實際可行的應用程式建置案例，測試遷移的建置建構工具的有效性。測試建置系統是一項艱難的任務，必須要有建置基準，同時需要密切留意變更對於最終成果的影響。就某些意義而言，應用程式本身就是建置系統的最終測試成果。一般來說，測試小組必須確認個別工具、提供給這些工具的指示以及工具互動等的有效性。

可以擴大測試建置系統的構想，納入效能衡量及易用性等問題。在任何遷移過程中，都可能出現效能上的問題。

發行管理角色 (達成順利部署及持續運作)

這個角色負責的事項，是對開發人員及組織內部群組發行建置系統。建置系統的部署作業，通常比應用程式部署容易一些。如前文所述，建置系統發行的交付日期會早於軟體建構程序的交付日期。

使用者體驗角色 (增加使用者效率)

這個角色代表的是使用者的需求；對於建置系統遷移而言，使用者是使用建置系統的開發人員。這個角色會負責撰寫文件，解說建置程序對使用者的影響。文件中絕大篇幅會用來敘述如何在 Windows 環境下完成建置。使用者體驗角色可能是由開發人員擔任，但並不是建置系統本身的開發人員 (任何系統的開發人員會設計出符合自己需求的系統，但未必符合使用者的需求；由其他人員擔任「使用者體驗角色」是對決策的品質檢查)。在虛擬小組案例中，可以接受將這個角色指派給正在遷移作業系統的開發人員，但是指派給另外的人員才是最佳的做法。

定義專案結構

可以按照《UNIX 遷移專案指南》中的指引，定出專案的結構。代表「產品管理角色」及「程式管理角色」的小組成員，應該協議建置系統遷移究竟算是個別的專案，還是屬於應用程式遷移的一部分。

對於小型 (一人或兩人) 小組而言，只要宣告專案將遵照組織標準就可以著手進行了。大型的小組則需要明確的指導方針。

建置系統的文件撰寫標準，需要遵守內部的文件撰寫指導原則。這些文件標準可以 (但非必要) 不同於應用程式遷移中適用於組織外部使用者的某些標準設定。

建議建置遷移的來源內容應做變更並且控制來源。因為建置資訊控制了產品形式及利用來源建立產品的方式，所以屬於最終產品的重要部分。變更及來源控制原則應該要與應用程式遷移專案相同。

另外，也建議您在建置程序遷移期間，使用問題追蹤及工作流程等工具。這些工具應該要符合應用程式遷移專案使用的工具和程序。

定義業務目標

建置系統的業務目標通常與應用程式的業務目標密切重疊，但是有些是建置遷移特有的目標，這些目標甚至會與應用程式目標衝突。雖然目標似乎相當明顯，但是闡明並記載目標是相當好的做法，如此能夠調解衝突並且建立優先順序，進而在專案的現在與未來期間，引導您做出任何有關取捨的決策。

建置系統可能包含下列部分或所有業務目標：

• 致力於縮短建置時間

• 致力於減輕開發人員的遷移工作負荷

• 緩和開發人員所需面對的轉變

• 使用現有的開發員工和技術，而不需要重新訓練

• 致力於減少系統變更，使風險降至最低程度，且使系統更穩定

• 致力於提高檔案重複使用

• 維持多平台可攜性

• 致力於降低遷移成本

• 減少因人員異動，造成組織無法使用軟體建構程序的風險

• 減少軟體建置中使用的協力廠商應用程式數量，簡化 IT 維護合約的複雜度

• 整合應用程式遷移專案 (亦即使用相同的環境)

• 維護 UNIX 建置程序回溯相容性

• 使用更強穩的處理程序來取代舊版建構程序

為了降低工作量，從上述重點中選擇三項最重要事項，並且排定優先順序。「程式管理角色」必須同意這項優先順序。

評估目前的情況

評估目前的情況是必須先執行的重要步驟，之後您才能嘗試建立專案願景及範圍。

假定建置系統僅僅是較大型應用程式遷移專案的一部分，在此情況下，因為建置系統遷移與應用程式部署通常共有類似的需求，而且選擇項目通常會互相影響，所以同時評估建置系統遷移及應用程式部署遷移專案極為重要。

您對建置系統的評估，有助於建立建置系統遷移專案的範圍和願景。具體而言，評估目標是決定您應採用的建置遷移策略：依據 make 公用程式和 makefile 進行遷移；或依據最適合預期使用的 Windows 工具的新設計，重新建立建置系統。

評估項目不僅要鎖定技術問題和需求，而且還要鎖定業務問題和需求。您必須分析預期的組織基礎結構變更，這些是從 UNIX 遷移至 Windows 直接相關的變更。任何問題或任何變更結果都是決定您應採用的策略的依據。

其中一種評估涉及評鑑目前的系統可用性及功能。藉由徵求開發人員及生產員工的意見就可完成這項工作。應收集意見並且排定優點順序，以擬定解決方案的需求清單。這項評估是當做目前系統的主觀價值判斷。顯而易見的是，如果使用者認為建置系統容易發生錯誤、容易損害且需要過度維護，則遷移這個建置系統就不是個好主意。

另一種類型的評估，涉及概略檢查建置系統、產生高階概觀並且決定建置系統的部分基本需求。您會想要知道誰是建置系統的使用者、使用者使用建置系統的方式以及建置系統所建立的應用程式。這種類型的評估可以用來作為目前建置系統的目標分析。下列清單列出您在檢查期間應該回答的特定問題：

• 最高層級的驅動因素是什麼 (makefile、Shell 指令檔或其他應用程式)？

• 可以建置的最終應用程式變化版本是什麼？例如，是否有偵錯版本、零售版本或展示產品版本？

• 應用程式和建置工具原始程式碼的組織方式為何，包括目錄階層架構？

• 如何在整個目錄之中散佈 makefile？是否有使用 include 指示詞或遞迴 make 叫用的單一 makefile？

• 建置系統是否處理原始程式碼版本？

• 建置系統是否處理產品及應用程式版本？

• 如果開發人員覆寫了標準建置系統中的功能，開發人員如何執行這些動作？

• 當開發人員需要變更現有的 makefile 及建置資訊時，會如何進行修改及控制？

• 當叫用系統時，是否設定了環境變數？

• 建置系統的規模為何？是否包含許多檔案或僅包含少數檔案？是否很複雜？

您不僅應該深入評估目前的建置系統，而且還應該視情況按技術需求評估目前的建置系統，以利於有系統地規劃願景並且定義範圍。現有或擱置中的業務及應用程式開發決策會指示出特定的解決方案，或者至少指示出看似較佳的解決方案，所以可能會影響評估工作量。例如，也許現有的建置系統目前不符合要求或不適用，需要進行新的設計。在這種情況下，此時就不需要進行建置系統技術評估。另外，也許尚有某些未解決的應用程式開發評估問題，因此對建置系統縮小範圍集中調查就可以提供答案；或許必須徹底分析建置系統，才能完成許多應用程式開發決策，此時，將會需要完善的技術建置系統評估。

第 3 章的＜評估現有的建置系統＞章節中，會詳細論述深度技術建置系統評估的細節。當您決定最適合的遷移策略後，通常會執行深度技術評估，並且可以開始計劃遷移的細節。然而，根據您準備建立專案願景和範圍過程中詢問自己的問題類型，有時候您必須在計劃階段之前先執行部分或所有深度技術評估。某些需要些許深度分析的簡單問題包括：

• 您是否要保留 make 架構系統？

  如果系統目前運作效率極佳且能符合要求，您會回答「是」。如果開發人員不滿意系統，或是您需要花許多時間和精力來維護系統持續運作，您會回答「否」。

• 目前的 make 架構系統是否適用於應用程式開發專案的範圍及願景？

  如果 Windows 開發環境類似於 UNIX 開發環境，您應該會回答「是」。如果 Windows 開發環境與 UNIX 開發環境之間的差異極大 (例如，如果 UNIX 環境係以指令行為基礎，而未來的 Windows 解決方案則是屬於 IDE 架構)，您應該會回答「可能」或「否」。

另一方面，您會想要估算並且比較每項策略的成本。 在此情況下，您應該回答下列需要更深度分析的問題：

• 現有 make 架構系統遷移至 Windows 的簡易程度？

  請依據建置系統使用的功能，以及是否可以找到適用的 Windows 環境可以提供相同的功能，決定這個問題的答案。您需要深度調查建置系統及 Windows 可以提供的適用環境，才能回答這個問題。

建立願景和定義專案範圍

評估現行建置系統之後的結果，再配合業務目標及技術需求加以考量之後，您就可以建立一份想要的特點和功能清單，描繪出 Windows 環境下的理想建置系統。通常，您需要和應用程式遷移小組合作完成這項程序。

面臨各種業務及技術限制時，您難免必須作出某些取捨，才能取得適合現行業務狀況的解決方案。您可以使用一些取捨標準，針對以下三種分類排定優先順序： 期望的功能、期望的排程以及將投入專案的資源。例如，如果排程是相當重大的要求，則可能必須放棄某些功能，才能加速遷移的步調。如果某些功能是絕對的需求，就必須做出會影響矩陣中其他元素的決定，才能納入這些功能。

評斷出您構想的建置系統中無法調整的事項、重要事項以及可以變更的事項。運用這些決策，定義出理想建置系統中超出範圍、同時不會完成的各個層面。UMPG 中提供有關運用取捨標準的詳細資訊。

在建立此階段主要成果的願景/範圍文件過程中，第一步驟是，用簡短的陳述來記載構想，並且具體指定您已決定的範圍限制。前面曾經提過，建置遷移的願景必須與應用程式遷移的願景相一致。整體而言，建置遷移專案的範圍顯然比應用程式遷移的範圍更小。

定義高階需求和使用者設定檔

必須具體指出高階需求 (關鍵參與者、贊助者及使用者之需求)，確保達成願景的解決方案有考慮到這些需求。就建置系統遷移而言，主要的關鍵參與者是指將會成為建置系統之使用者的開發人員及建置經理。應用程式遷移的高階需求可能會限定某些需求。

下列需求通常對於建置系統極為重要，可以作為您的清單理想的起點。請記住，雖然類似於早先定義的業務目標，但是這些需求會將焦點擴及建置系統的使用者。需求可能會包括下列幾個要素：

• 建置系統在大部分應用程式開發階段的穩定性

• 應用程式遷移工具及做法的整合

• 跨平台可攜性

• UNIX 建置系統回溯相容性

• 緩和開發人員所需面對的轉變

• 迅速遷移

• 利用單一來源來產生某些數量的版本的能力

• 原始程式碼控制和變更管理工具的整合

• 將版本處理及設定資訊併入建置系統中

在完成清單之後，專案小組會針對清單精選出基本的需求。某些需求可能無法同時存在。例如，回溯相容性與應用程式遷移專案的整合，可能無法共存。在這些情況下，專案小組必須在這些需求中作出選擇。

建置遷移的「使用者體驗角色」及「產品管理角色」可以定義使用案例，呈現出可能會被忽略的使用者需求，協助小組排定需求優先順序。應用程式遷移小組的開發人員將成為主要的使用者，但是應用程式遷移小組的「發行管理角色」及「測試角色」也會使用建置系統，或是會受到重大影響。使用案例包括使用建置系統來建置偵測版本、特殊發行版本、用戶端特有的應用程式發行版本，以及建置用於部署及安裝已遷移之應用程式的安裝程式封裝。例如，在 UNIX 環境中，通常會以 tar 檔案來交付應用程式，建立的部署封裝是單一的 tar 命令；在 Windows 環境中，通常會使用另一組命令集 (可能是指令碼) 來建立部署封裝，並且可能是或不是可以從命令列叫用的程式。很顯然的，在任何情況下，使用建置系統的指令都將顯著不同，而且新的使用者剛開始可能不熟悉建置系統。建立使用案例，將有助於預見並避免潛在的問題。

開發解決方案概念

為了開發解決方案概念，小組的重點放在明確表達出業務和設計目標以及解決方案的限制。換言之，在專案開發的這個時刻，小組著手進行的解決方案變得更加精簡。如同前面章節內容所述，最主要的決策是選擇遷移現有 makefile 的方式，在 Windows 環境中使用 UNIX 可攜性環境；或者使用替代 Windows 工具 (例如，類似 Visual Studio 的 IDE) 來建立新的建置程序。下列內容中提供的資訊，將有助於您更加精簡且明確表達出決策及含意。

策略選擇是所有遷移小組必須分擔的決策，包括應用程式遷移小組及建置遷移小組。擁有多個應用程式遷移的組織應將兩種遷移工作 (應用程式及建置系統) 的單一策略標準化，即使應用程式遷移小組也正在遷移建置系統。這是為了使整個組織的建置系統保持一致，並且更容易調動不同小組的開發人員。採購、授權及維護軟體工具和協力廠商程式庫的後勤單位也能因而獲益。

建置遷移小組可以選擇不同於應用程式遷移小組的解決方案，但是此種狀況並不常發生。當遷移工作之間存在無法調解的因素時，才可能會發生此狀況。 事實上這種情況產生的機率相當低，因為遷移作業彼此之間極可能有許多共同點，同時因為選擇不同的解決方案會增加整體部署的複雜性及不相容的風險。

傾向於在 Windows 環境中建立新建置系統的需求及因素包括：

• 負責應用程式遷移的開發人員是不熟悉命令列的 Windows 開發人員。

• 應用程式遷移專案可以大幅重新建構及重新撰寫原始程式碼，所以現有 makefile 中擷取的所有資訊不足採信。

• 應用程式遷移使用的開發環境工具 (例如，編譯器、Shell 及編輯器) 完全不同於 UNIX 版本。

另一方面，促使您遷移 make 架構建置系統的需求及因素包括：

• 開發人員熟悉 UNIX 命令列環境。

• 實作的速度相當重要；複雜的建置系統通常比較容易移植，而重新撰寫則較為困難。

• 應用程式遷移小組正在使用 UNIX 可攜性環境 (例如，MKS Toolkit、Interix 或 Cygwin)，或使用特定 Windows 版本的 UNIX 工具 (例如，gcc)。在這些情況下，就經濟成本而言，建置遷移採用與應用程式遷移相同的做法較為明智。

• 目前的建置系統大規模使用 UNIX 工具集和功能，而且建置系統相當穩固。

• 初步解決方案的範圍會限制首次發行的 make 架構遷移，即使最終願景是傾向於全新的 Windows 工具架構建置系統。

實際上，最重要的因素是有時間執行遷移的員工。熟悉度及知識通常是迅速實作的最佳指導。如果開發人員熟悉 make 及 UNIX 系統，那麼他們通常會有遷移建置系統的理由；如果開發人員熟悉 Visual Studio 但不熟悉 make，則通常會有開發新建置系統的理由。

注意 如果您決定要重新撰寫建置系統，而不是遷移建置系統，則本份文件中的技術資訊有助於您分析現行的建置系統。但是，並未提供關於實作新建置系統的指導方針。

評估專案風險

在繼續著手開發具體專案計劃之前，「構想」階段的最終步驟是認清建置遷移專案承受的風險。專案小組確認風險、使用 UMPG 中描述的方法來建立初步風險評估文件，以及排定風險的優先順序。接著全力管理排名最高的風險。

下列建置遷移特有的風險清單可以補充任何遷移專案的 UMPG 常見風險清單。

• 新的建構機制尚不熟悉，並且需要多於預期的工作才能穩定。

• 對舊型建置系統瞭解並不充分且舊型建置系統容易受損，而遷移會使建置系統中止。

• 不完善的評估會造成範圍不斷擴大，工作量增加高於預估的工作量。

• 建置系統未留存所有必要的建構資訊，導致需要額外的設計工作。

• 如果應用程式開發人員本身正在進行建置系統遷移，您可能沒有明確定義的測試，並且您執行建置系統的風險幾乎會不自覺地從範例應用程式轉移至生產環境。這種方法可能帶來的危險，是系統會將未記錄的變更不斷累加到指令碼環境中。

• 選擇輕量型處理方式來進行建置程序遷移專案，但是由於分析及檢閱不足導致做出不切實際的選擇；結果，花費更多的精力回頭從開發的「困境」重新開始。

Microsoft Solutions Framework 的宗旨之一，是在整個專案期間，專案小組可以持續重新評估及管理專案風險，所以能夠顯著提高專案成功的機會。每個小組成員都負責讓其他小組成員獲知新的風險，以及已知風險可能性的任何變化。當專案進行到另一階段時，某些風險可能不復存在，但是會發現到新的風險。每位小組成員還需負責減輕及防止可能的風險。專案經理必須經常檢閱清單，並且主動修改清單。

摘要

這個階段結束後，應該已完成下列事項：

• 已確立核心小組成員。

• 您的小組已經決定解決方案概念，換言之，是否要重新建立適用於 Windows 的建置系統，還是將現有的 makefile 遷移至 Windows。

• 具有現行建置程序的詳細記錄。

• 小組已擬定初步的風險清單。

• 已獲得「構想」階段主要成果的專案小組、客戶及關鍵參與者同意，包括願景/範圍文件、解決方案概念及風險評估。