二、 軟體專案開發與管理相關技術探討
2.2 管理技術「專案管理知識體系」簡介
3.2.4. 移交階段(Transition Phase)之程序工作
1. 移交階段之目標：
在詳述階段完成後，專案已經產出符合專案目標的初始版本系統，
此階段的重點放在確保系統已達到足夠的品質水準，並符合軟體需 求為目標、修正錯誤、訓練終端使用者、調整系統並加入缺少的必 要功能，造出最終的軟體產品。
2. 移交階段之主要工作
依「統一軟體開發流程」(USDP)所述之主要工作，配合專案管理知 識體系的精神，定義本階段工作如下：
z USDP-移交階段早期工作
(1) 規劃移交階段(Planning the Transition Phase; USDP- 16.2.1)：規劃 階段之重要任務之一為將建構階段產出之產品進行微調，以產出 符合專案目標的初始版本系統，因此階段之工作規劃包括客戶訓 練、驗收測試、維護階段等工作之安排。
(2) 分派移交階段任務(Staffing the Transition Phase; USDP- 16.2.2)：
移交階段重點之一為調整建構階段產出之產品，因此部份的人力 分派與建構階段有很大的相關及吻合性，然而為確保專案最後階 段之達成性，此一階段任務分派之考量將以開發導向
(Development Oriented)轉換為服務導向(Service Oriented)，此 外，必須安排進行使用者教育訓練…等工作，確保系統移交之過 程順暢性。
(3) 設定評估條件(Setting the Evaluation Criteria; USDP- 16.2.3)：移 交階段一般必須評估以下五項評估條件：
A. 產出之系統是否涵蓋使用者需求之關鍵功能。
B. 產出之系統是否通過合約規範之驗收測試。
C. 交付文件的品質是否可被使用者接受。
D. 教育訓練、教材及相關文件是否已備妥，隨時可加以運用。
E. 客戶及使用者是否滿意專案之產品。
z USDP-移交階段工作
(4) 確認客戶環境(Getting Beta Release Out; USDP- 16.4.1 之一)：為 使「客戶驗收測試版本」於「客戶驗收測試環境」運作無誤，故 於完成客戶驗收測試版本前，必須進行客戶使用環境之確認。
(5) 完成客戶驗收測試版本(Getting Beta Release Out; USDP- 16.4.1 之二)：開發團隊依確認後之客戶環境，完成「客戶驗收測試版 本」系統並進行伺服端(Server)系統安裝，包含本版本之「安裝 步驟」。
(6) 新舊系統資料轉換(Installing Beta Release; USDP-16.4.2 之一)：
使用者進行驗收測試時可能必須比對新舊系統的結果以確認系 統之正確性，故必須先進行新舊系統之資料轉換。
(7) 客戶系統安裝及操作訓練(Installing Beta Release; USDP-16.4.2 之二) ：進行教育訓練教導客戶安裝及操作「客戶驗收測試版本」
系統，以確保使用者可順利安裝及操作新系統進行驗收測試，在 訓練後，即可開始進行驗收測試；由於此時客戶尚未完成確認新 系統的適用性，故此一階段可能採新舊系統並行方式進行作業。
(8) 協助客戶使用系統(Installing Beta Release; USDP-16.4.2 之三)：
在客戶進行驗收測試時，可能有操作或系統相關問題，此時除輔 導客戶進行系統操作外，另外進行客戶反應問題之記錄，以確保 客戶反應問題皆已確實掌握。
(9) 回應客戶驗收測試結果(Responding Test Results; USDP-16.4.3)：
收集並分析客戶驗收測試結果，並針對其中測試失敗項目制定回 應計劃。
(10) 使用者環境差異之因應(Adapting Product to Varied User
Environment; USDP-16.4.4)：專案產出系統可能於同類業務性質 之客戶皆有潛在需求，故此階段可將系統發展為多種版本(如：
發展免費資料庫方案之版本)，以利專案產出系統之再利用。
(11) 完成專案交付項目(Completing Artifacts; USDP-16.4.5)：彙總專 案各階段產出之專案交付項目，完成專案合約之交付項目。
z USDP-完成商業效益評估
(12) 管理進度(Controlling Progress; USDP- 16.5.1)：本工作之重點
為監控本階段工作排定之時程、成本與實際執行之落差，並定期 進行檢討，以確保專案得以如預期進行驗收。
(13) 檢討商業效益(Review of the Business Plan; USDP- 16.5.1)：本 作之重點為總結專案成本，以計算本專案之實際商業效益，並作 成記錄以供後續專案執行參考之用。
z USDP-評價移交階段工作
(14) 評價移交階段之反覆(Assess the Iterations in the Transition Phase; USDP- 16.6.1)：本工作之重點為控制階段反覆在專案時程 及預算內完成，並進行本階段「設定評估條件」工作所設定之工 作評估。
(15) 專案回顧檢討(Postmortem of the Project; USDP- 16.6.2)：為使 後續專案之執行可以更有效率及更成功，本工作之重點為檢討及 記錄專案之重要資訊如下：
A. 專案採用之設計及專案中進行評估但不獲採用設計之原因。
B. 專案過程中可以進行檢討改進的工作，以有助於後續專案進行改 進。
C. 可再利用項目之後續發展。
z USDP-評價移交階段工作
(16) 準備下一個世代專案(Planning the Next Release or Generation;
USDP- 16.7)：本階段之主要是進行專案範疇內之系統調整，使 用者在本階段通常會提出一些專案範疇外之系統需求，這些需求 雖然不會在本階段被滿足，但是這些需求將是下一個世代專案參 考之重要資訊。
z SPDP-因應本程序為軟體公司承接業主之軟體標案進行系統開 發而須完成之工作
(17) 撰寫系統安裝手冊：一般在專案正式展開後的第八個交付項目 為「系統安裝手冊」，通常於系統於「完成客戶驗收測試版本」
工作後，依安裝步驟進行編寫，「系統安裝手冊」通常包含「安 裝步驟」、「常見安裝問題與解決建議說明」…等。
(18) 撰寫驗收報告：因應專案之驗收，本工作之重點為彙整專案之 執行狀況，以證明符合專案合約之規範，並準備專案之正式驗收 合約，以供後續「專案正式驗收」工作之用。
(19) 專案正式驗收：專案之正式驗收通常會由業主邀集專案利益關 係人(Stakeholders)進行驗收會議，進行驗收報告之審查，並簽訂 專案驗收合約。
3. 移交階段之工作流程：
圖 14 SPDP 移交階段之工作流程
4. 移交階段之主要工作產出
(1) 規劃移交階段：移交階段人力及時程規劃。
(2) 分派移交階段任務：移交階段人員分工表。
(3) 設定評估條件：移交階段評估條件。
(4) 確認客戶環境：客戶環境清單。
(5) 完成客戶驗收測試版本：「客戶驗收測試版本」及伺服端系統。
(6) 新舊系統資料轉換：「資料轉換說明書」及包含資料之伺服端系 統。
(7) 客戶系統安裝及操作訓練：「安裝及操作訓練」。
(8) 協助客戶使用系統：客戶反應問題記錄。
(9) 回應客戶驗收測試結果：客戶反應問題處理情況。
(10) 使用者環境差異之因應：適用其它環境之系統版本。
(11) 完成專案交付項目：專案交付項目。
(12) 管理進度：工作計劃與實際進度與工時落差，程式行數。
(13) 檢討商業效益：專案商業效益總結報告。
(14) 評價移交階段之反覆：會議記錄，包含檢討會議之問題列表。
(15) 專案回顧檢討：「專案回顧報告」。
(16) 準備下一個世代專案：專案潛在需求。
(17) 撰寫系統安裝手冊：「系統安裝手冊」。
(18) 撰寫驗收報告：「專案驗收報告」。
(19) 專案正式驗收：「專案驗收合約」。
5. 移交階段之管理問題分析
考量本階段工作特性，彙整實務常見之管理問題如下：
(1) 使用者驗收的問題不斷導致遲遲無法驗收問題：使用者通常在進 行驗收測試時會提出一些系統之實務問題，如果這些問題未被以 有效率之方式進行管理並解決，將導致使用者不斷發掘並提出新 問題，使專案團隊頻頻面對新問題而疲於奔命，導致驗收遙遙無 期。
(2) 最後階段才發覺交付項目缺漏而延誤驗收問題：實務上常見在最 後階段才發現交付項目有缺漏或品質不佳，然而要完成這些交付 項目往往需要花費一段時間，因而延誤原本預定之驗收時程。
(3) 不同使用者重覆詢問相同問題：部份顯見之系統問題往往在使用 者進行驗收測試時，不停地被不同的使用者重覆提出，這些常見 問題往往耗費專案團隊大量人力進行說明，而造成專案成本增 加。
(4) 專案經驗無法有效累積至下一個專案問題：專案經驗如無法以有 效方式進行收集，並提供公司之相關專案人員進行參考，將造成 專案經驗無法有效被利用，而導致專案成本無法有效降低。
6. 移交階段管理問題之解決方案及管理表單樣本：
(1) 使用者驗收的問題不斷導致遲遲無法驗收問題：品質管理 (Quality Management)問題。
(2) 最後階段才發覺交付項目缺漏而延誤驗收問題：風險管理(Risk Management)問題。
(3) 不同使用者重覆詢問相同問題：成本管理(Cost Management)問 題。
(4) 專案經驗無法有效累積至下一個專案問題：成本管理(Cost Management)問題。
上述各項問題可以參考「專案管理知識體系」之「九大知識領域」， 在階段各項工作提出解決方案及管理表單如下：
(1) 使用者驗收的問題不斷導致遲遲無法驗收問題：藉由制定「協助
填寫實際完成日期。
專案名稱： 階段工作負責人：
專案名稱： 階段工作負責人：
四、 「軟體專案開發程序」之成效評估及優缺點
4.1 「軟體專案開發程序」之成效評估
4.1.1 「軟體專案開發程序」之成效評估目的
為確認本論文制訂之「軟體專案開發程序」於實務專案運用之可行 性，故於本公司承接之專案前進行導入，並於專案進行過程予以運 用，以評估實際執行成效。
4.1.2 「軟體專案開發程序」之成效評估作法
1. 成效評估作法說明
為量化評價「軟體專案開發程序」之執行成效，區分為以下五個步 驟進行評估：
(1) 專案遴選：
因「軟體專案開發程序」著重於軟體開發專案，故遴選之專案 以資訊軟體勞務委外服務類為主。
(2) 成本預估：
於本專案由三位專案經理分別精確預估專案所需人月數後及預 估之專案毛利率，並取最低值作為本專案之預估基準。
(3) 專案執行：
由成本預估最低之專案經理，經一週之密集訓練後，依「軟體 專案開發程序」執行專案，直到完成專案及驗收。
(4) 效果確認：
於專案開發完成驗收、系統上線後繼續觀察半年之維護情況，
以確保軟體品質不會因採用新程序而降低。
(5) 成效評估：
於專案完成保固六個月後對專案經理及專案成員進行優缺點調 查及進行成本計算，包含保固期間所花費之成本後，計算實際 執行之專案毛利率。
2. 專案背景資訊說明
總計 $1,629,000
4 教育訓練
B. 專案成員：
總計 $1,475,020
2 系統開發
員對程序之熟悉程度尚未純熟已可達成如此成效，相信如在後 續專案繼續運用必可達成更顯著之成效。
4.2 「軟體專案開發程序」之優缺點檢討
4.2.1 「軟體專案開發程序」的優點
1. 經驗較少的專案經理人得以省去冗長的學習及摸索過程，迅速套用
1. 經驗較少的專案經理人得以省去冗長的學習及摸索過程，迅速套用