詳述階段(Elaboration Phase)之程序工作

1. 詳述階段之目標：

此階段的主要工作包含以下四項：

(1) 獲得大多數的剩餘需求，並將功能性需求以使用個案(Use Cases) 進行表示。

(2) 建立基準架構，用以規範「建構階段」及「移交階段」之工作產 出。

(3) 持續監控殘餘關鍵風險，並對重大風險進行辨視、評估對商業效 益的衝擊。

(4) 「專案執行計劃書」之撰寫、通過審查並正式完成交付。

2. 詳述階段之主要工作：

本階段之重點著重於獲得及精煉多數的需求、發展專案之基準架 構，將「統一軟體開發流程」(USDP)所述之主要工作，配合專案管 理知識體系的精神，將本階段工作調整如下：

z USDP-詳述階段早期工作

(1) 規劃詳述階段(Planning the Elaboration Phase; USDP- 14.2.1)：由 於專案建議書審查過程中可能承諾一些專案附加條款，故簽約後 應即刻召集工程與業務部門進行工作內容確認，並規劃本專案之 各項工作內容及完成日期，以確認專案之複雜度變化，由於起動 階段之評估時間短暫且因附加條款之追加，所以專案時間及預算 必須在詳述階段重新檢視、調整或重新規劃，以因應實際專案情 況。

(2) 組建專案團隊(Build the Team; USDP- 14.2.2)：起動階段之專案團 隊一般為臨時依需求組成之暫時編組，詳述階段之專案團隊一般 將持續至後續建構階段，且建構階段需要大量人力，故必須一併 考量；專案編組為依專案需求調配人力時間的「功能性組織」

(Functional Organization)，尤需注重編制於其它部門之專案參與 人員，需要將其時間進行妥善預訂。此外，對高技術風險的議題 (如：建議書提出專案團隊不熟悉之外購套裝軟體之適用性)，應 即刻安排人員著手進行解決。

(3) 制定開發環境(Modify the Development Environment; USDP-

14.2.3)：階段之工作重點為確認採購專案所需軟硬體並建立專案 之開發環境，並對專案成員進行技能確認，必要時應施以教育訓 練，以確保完成專案之人員能力及環境之充份準備。

(4) 設定評估條件(Setting the Evaluation Criteria; USDP- 14.2.4)：因 應階段目標，詳細列出下列項目之詳細內容：

A. 需求是否已經展開(Extend the Requirements)。

B. 基準架構是否已完成制定(Establish Baseline Architecture)。

C. 重大風險是否已有明確的因應方案(Mitigate the Significant Risks)。

D. 專案效益評估是否已經完成(Judge the Worth of the Initial Business Case)。

z USDP-執行需求訪談至測試之核心工作：詳述階段之核心工作 為獲得完整之系統需求，並對剩餘技術風險進行分析、設計、

實作與測試，以完成風險之澄清，此外，必須對主要功能(核心 功能)進行分析及設計，以確認系統架構並建立架構基準線。

(5) 獲得完整系統需求(Capture the Requirements; USDP- 14.4.1)：本 工作之重點為找尋、排列、詳述及建構使用個案，其主要有以下 五項行動：：

A. 構建 100%之業務模型(Business Model)。

B. 依使用個案之重要性及優先性找尋及辨視 80%以上之使用個案 及 100%主動者(Find Use Cases and Actors)。

C. 以技術風險高者及功能優先性進行使用個案之後續工作順序排 列(Prioritize Use Cases)。

D. 詳述 40%~80%重要或把握程度較低的使用個案(Detail a Use Case)。

E. 視專案需求製作使用者介面雛型(Prototype User-Interface)。

(6) 架構基準線分析(Analysis; USDP- 14.4.2)：在起動階段已經建立 了一個初略的分析模型，在本階段的分析工作除將進行子系統架 構分析及確認，並將技術風險高或與架構有密切關係之子系統進 行細部分析，以進行分析模型之精煉，本工作包含以下四項行動：

A. 分析架構-確認子系統架構(Architectural Analysis)。

B. 分析 20%~40%技術風險高或與架構有密切關係的包裝(Analyze a Package)。

C. 分析 20%~40%技術風險高或與架構有密切關係的使用個案 (Analyze a Use Case)。

D. 分析 20%~40%技術風險高或與架構有密切關係的類別 (Analyze a Class)。

(7) 架構基準線設計(Design; USDP- 14.4.3)：本階段通常僅設計及實 作少於 10%的重要使用個案，這些被設計的使用個案、類別與 子系統僅限於技術風險高或與架構有重大相關者，以完成系統架 構基準線，本工作包含以下四項行動：

A. 設計架構-確認架構設計(Architectural Design)，包含定義系統軟 硬體架構、中繼軟體(Middleware)及資料庫類型。

B. 設計小於 10%技術風險高或與架構有密切關係的使用個案 (Design a Use Case)。

C. 設計小於 10%技術風險高或與架構有密切關係的類別 (Design a Class)。

D. 設計小於 10%技術風險高或與架構有密切關係的子系統(Design a Subsystem)。

(8) 少數功能實作(Implementation; USDP- 14.4.4)：本階段僅實作極 少數技術風險高之功能，通常實作的數量將少於 10%的重要使 用個案，本工作包含以下四項行動：

A. 架構性建置(Architectural Implementation)。

B. 實作小於 10%技術風險最高的類別與子系統(Implement a Class and Implement a Subsystem)。

C. 不斷將各反覆之產出整合為系統(Integrate System)。

(9) 少數功能測試(Test; USDP- 14.4.5)：本工作聚焦於確認基準架構 各子系統與其相互介面間作業之可行性，包含以下四項行動：

A. 進行測試計劃之規劃(Plan Test)。

B. 設計專案測試之作法(Design Test)。

C. 對上述實作之系統執行整合測試(Perform Integration Test)。

D. 執行系統效能測試(Perform System Performance Test)。

z USDP-樹立商業效益

(10) 調整成本預估基準(Prepare the Business Bid; USDP- 14.5.1)：起 動階段預估之採購軟硬體項目及軟體開發成本是根據軟體規模 及過往開發經驗作為成本預估基準進行估計，在前述工作進行技 術風險澄清後將可確定專案採購之軟硬體，本工作將實際進行軟 硬體採購之議價，以取得精確之採購成本，此外由於後續「建構 階段」將大幅進行軟體開發，在本階段之主要目標為建構架構基

準線，為了使專案之成本以最節約方式進行，故必須依專案團隊 架構基準線之實際執行情況進行成本預估基準調整，以建立最節 約之成本規劃及預估。

(11) 更新投資報酬率(Update Return on Investment; USDP-

14.5.2)：根據上述調整後之成本預估基準，進行專案預期獲利計 算，以建立接近真實情況之獲利預估，考量本程序定位，本工作 名稱應調整為「更新專案預期效益」。

z USDP-評價詳述階段工作

(12) 評價詳述階段(Assess the Iterations in the Elaboration Phase;

USDP- 14.6)：本工作之重點為評價此階段提出架構基準線之適 切性，一般以召開會議對內部提出說明，並在專案團隊內部確認 專案之主要技術風險皆已獲得排除。

z USDP-規劃建構階段工作

(13) 規劃建構階段(Planning the Construction Phase; USDP- 14.7)：

依據制定之基準架構進行系統之分析、設計、建置及測試等開發 工作之安排，因此本工作之重點置於上述開發工作之安排。

z SPDP-因應本程序為軟體公司承接業主之軟體標案進行系統開 發而須完成之工作

(14) 專案簽約：於專案議價及議約工作完成後，專案之價格及內容 即完成確認，在業主與公司完成用印後，專案即正式展開。

(15) 撰寫專案執行計劃書：一般在專案正式展開後的第一個交付項 目為「專案執行計劃書」，「專案執行計劃書」將進行整個專案執 行過程的規劃，通常包含「專案組織」、「專案工作分解結構」、「專 案風險及回應說明」…等。

(16) 專案啟動會議：一般於「專案執行計劃書」完成後會邀集主要 之專案利害關係人進行「專案啟動會議」，進行「專案執行計劃」

摘要、架構與需求確認、專案風險及回應，及需請業主配合之工 作項目說明(如：不包含網路線路佈建之專案，須請業主配合完 成網路線路佈建之時程)，並正式授權專案委由專案團隊進行專 案執行任務。

(17) 交付項目修訂：將「專案執行計劃書」交付業主後，一般業主

將於一定期間回覆審查意見，並由專案團隊進行交付項目之修 訂，以符合業主需求而獲接受。

(18) 進行階段驗收：在業主正式接受專案團隊交付之「專案執行計 劃書」後，一般會以驗收會議方式進行正式檢收，如為付款階段 則於正式驗收後依合約所訂條件進行階段請款程序。

3. 詳述階段之工作流程：

圖 10 SPDP 詳述階段之工作流程

4. 詳述階段之主要工作產出：

詳述階段之主要交付項目(Artifact)包含「專案執行計劃書」將於詳述

階段之各項工作中陸續產出，各項工作之產出如下：

(1) 規劃詳述階段：詳述階段之工作計劃。

(2) 組建專案團隊：專案後續階段(包含詳述、建構及移交階段)參與 人員名單，包含參與時機及所需技能。

(3) 制定開發環境：專案開發環境之說明及應舉辦或接受技能訓練課 程及人員。

(4) 設定評估條件：階段評估條件。

(5) 獲得完整系統需求：完整的「業務模型」及大部「使用個案模型」

文件內容。

(6) 架構基準線分析：系統的「分析模型」包裝圖(Package Diagram) 及架構關鍵性「類別」(Class)。

(7) 架構基準線設計：系統的軟、硬體架構及系統的「設計模型」包 裝圖(Package Diagram)。

(8) 少數功能實作：高技術風險功能的實作程式。

(9) 少數功能測試：高技術風險功能的測試文件。

(10) 調整成本預估基準：「成本預算表」。

(11) 更新專案預期效益：「專案預估獲利表」。

(12) 評價詳述階段：「詳述階段評價會議」，高技術風險項目因應情 況及專案團隊內部確認之架構基準線。

(13) 規劃建構階段：建構階段人力及時程規劃。

(14) 專案簽約：簽訂之「專案合約」。

(15) 撰寫專案執行計劃書：「專案執行計劃書」。

(16) 專案啟動會議：啟動會議簡報及會議記錄。

(17) 交付項目修訂：交付項目的正式版本。

(18) 進行階段驗收：「詳述階段驗收合約」。

5. 詳述階段之管理問題分析：

考量本階段限制及特性，彙整實務常見之管理問題如下：

(1) 高技術風險掌握及回應問題：部份技術風險在起動階段尚無法完 全澄清，如本階段仍未完成辦識及客觀評價、尚未提出適當之因 應計劃並有效管理，可能導致難以結案。

(2) 專案規劃採購項目風險：專案規劃之採購項目，包含：套裝軟體 版權及硬體…等，可能因採購不及或交貨期間因素，造成擔誤後 續工作之進行。

(3) 專案成員之技能訓練問題：因專案成員之組成人員可能不完全具 備擔任安排專案角色所需技能，因而造成專案之產品品質不佳或 開發進度不如預期。

(4) 客戶負責工作延遲影響專案團隊工作問題：專案部份工作須由客 戶與專案團隊合作進行(如：由客戶準備網路佈線)，此工作如未 及時完成將影響專案工作時程之如期執行(如：將系統主機部署 至客戶端)。

(5) 評估後續成本精準度問題：起動階段因評估時間短暫，故開發人 力成本之預估客觀性不佳，如果仍依起動階段之採購成本及人力 成本預估，導致實際專案執行無法以最節約之成本進行。

(6) 人員工作先後順序安排問題：本後續階段牽涉客戶或跨單位之配 合事項與大量開發工作安排，如：在規模較大之專案，通常需要

(6) 人員工作先後順序安排問題：本後續階段牽涉客戶或跨單位之配 合事項與大量開發工作安排，如：在規模較大之專案，通常需要