起動階段(Inception Phase)之程序工作

1. 起動階段之目標：

在招標性軟體開發專案的起動階段，由業主進行招標公告開始，至 專案進行開標，確認是否得標為止，軟體公司在本階段必須完成以 下重要工作項目：

z 確認專案的可行性。

z 提出專案架構的適用性。

z 辨識專案的風險。

z 預估專案之工作時程。

z 評估專案之工作成本。

z 提出專案建議書。

最後開標時若雀屏中選，則贏得軟體開發專案之合約。

2. 起動階段之主要工作：

依「統一軟體開發流程」(USDP)所述之主要工作，配合專案管理知 識體系的精神，定義本階段工作如下：

z USDP-起動階段早期工作

(1) 起動階段前置工作(Before the Inception Phase Begins; USDP- 13.2.1)：在業主公告招標後，專案業務人員於獲得招標資訊後進 行領標工作，以取得各項招標文件，如：「招標須知」、「徵求需 求說明書」、「招標投標及契約文件」…等，經業務及工程評估負 責人詳閱後粗略評估公司參與該標案之可行性後，並考量公司策 略，完成「第一階段可行性評估報告表」，以決定是否放棄投標 或繼續進行後續工作，考量本程序定位，本工作名稱應調整為「

招標文件取得與評估」。

(2) 規劃起動階段(Planning the Inception Phase; USDP- 13.2.2)：若決 定進行投標，則進行專案工作團隊成員工作分派及時程安排，通 常由業務及研發主管共同協商，而後以開會方式向團隊成員說

明，並分發相關資料，即刻進行相關工作。

(3) 延伸系統願景(Expanding the System Vision; USDP- 13.2.3)：本工 作之主要作法通常包含以下步驟：

(4) 可行性評估(Setting the Evaluation Criteria; USDP- 13.2.4)：當專 案經理取得足夠之專案資訊後，會設定階段評估條件來進行可行 性評估，一般常見之評估條件如下：

A. 確認系統範疇之了解程度(Resolve System Scope)。

B. 階段中模糊的需求之澄清程度(Resolve Ambiguities in the Requirements Needed in this Phase)。

C. 候選架構資訊是否明確(Establish a Candidate Architecture)。

D. 關鍵風險是否有明確的因應方案(Mitigate the Critical Risks)。

E. 初期的商業效益判斷是否已經完成(Judge the Worth of the Initial Business Case)。

在對上述條件進行初步評估後，進行「第二階段可行性評估報 告表」撰寫，決定是否放棄投標或繼續進行後續工作。

z USDP-執行需求訪談至設計之核心工作

(5) 獲得大部份系統需求(Capture the Requirements; USDP- 13.4.1)：

本工作為本階段之重點項目，主要目的為獲知系統需求，其工作 主要包含四項行動(Activities)如下：

A. 表列候選需求(List Candidate Requirements)。

B. 了解系統內涵(Understanding the System Context)。

C. 獲得功能性需求(Capture Functional Requirements)。

D. 獲得非功能性需求(Capture Nonfunctional Requirements)。

(6) 候選架構分析(Analysis; USDP- 13.4.2)：本工作為將需求用物件 模型(Object Model)作精確表達，產出粗略的分析模型(Analysis 作為規範候選架構之用，在業主未規範需進行雛型展示的案子 中，只有少數把握度低及風險性高(約 10%)的需求將在本階段優 先進行分析、精煉詳述完成，其它把握度高之需求則可跳過「分 析」、「設計」、「實作」與「測試工作」，直接進行成本分析，本 工作主要包含三項行動：

A. 架構分析 (Architectural Analysis)。

B. 分析使用個案(Analyze a Use Case)。

C. 類別與包裝設計(Analyze a Class and Analyze a Package)。

(7) 候選架構設計(Design; USDP- 13.4.3)：本工作為將分析工作產出 轉換為設計模型(Design Model)的候選架構(Candidate

Architecture)， 在業主未規範需進行雛型展示的案子中，只對極 少數把握度不足的使用者介面或演算法(約 5%)可使用快速開發 技術來進行雛型設計，利用雛型展示使專案關係人(Stakeholders) 相信專案團隊可達成專案的需求，並證實專案過程中不致因極少 數把握度不足的使用者介面或演算法而失敗，本工作主要包含三 項行動：

A. 架構設計 (Architectural Design)，包括硬體架構及軟體架構之初 步設計。

B. 設計使用個案(Design a Use Case)。

C. 設計類別與子系統(Design a Class and Design a Subsystem)。

(8) 概念驗證實作(Implementation; USDP- 13.4.4)：專案經理可決對 是否對以上極少數把握度不足的使用者介面或演算法進行雛型 實作，以證實候選架構的可行性，如果考量資源有限性及把握度 夠高，也可只產出候選架構描述即結束本階段，不需進行實作。

(9) 概念驗證測試(Test; USDP- 13.4.5)：由於雛型展示之雛型有別於 正在運作之系統，故有請測試工程師對實作之雛型進行測試之需 求，並嚐試撰寫部份探索性之測試計劃。

z USDP-樹立初期的商業效益

(10) 描述評估成本(Outline Business Bid; USDP- 13.5.1)：對本專案 進行成本估價，包含硬體、套裝軟體授權費用…等等外購項目之

詢價，人力成本則依軟體候選架構進行每一個子系統之人力預估 後，加總各子系統之需求人日作為開發此系統所需人力，再乘以 每人日之成本作為開發該子系統所需成本，此外也可利用本專案 與過往之基準專案進行比較來決定商業價格，考量本程序定位，

本工作名稱應調整為「進行成本分析」。

(11) 預估投資報酬率(Estimate Return on Investment; USDP-

13.5.2)：預估本專案開發軟體完成後，業主可從導入本專案開發

(12) 評價起始階段(Assess the Iterations in the Inception Phase;

USDP- 13.6)：利用評估條件，對起始階段之成果進行評價，以 確保階段目標已經完成，常見之評價條件如下：

業主規定完成投標建議書介紹，以進行投標建議書評審、議價等 動作。

(15) 建議書簡報：在完成投標及通過資格審查後，則會由業主召開 建議書簡報會議，專案團隊將對評審進行建議書內容之簡報說明 及必要之雛型展示。

(16) 接獲開標結果：由業主正式公佈評審結果及得標廠商，如果結 果為得標，則進行議價、簽約，否則本專案即召開投標檢討會，

檢討本次開標結果失敗原因供後續投標參考，並宣佈專案團隊本 專案宣告終止。

(17) 議價及議約：在接獲開標結果後即展開議價之價格策略制定及 專案合約審訂，並於議價及議約後進入後續詳述階段(Elaboration Phase)。

3. 起動階段之工作流程：

將上述之各項工作之優先順序確認後，「專案管理知識體系」之五 大程序之工作類型進行歸納、排列為本起動階段之工作流程如下：

圖 9 SPDP 起動階段之工作流程

4. 起動階段之主要工作產出：

起動階段之主要交付項目(Artifact)為「投標建議書」及「建議書簡 報」，除專案共通性章節，如：「公司簡介」、「專案管理方法」、「建 構管理方法」…等可依專案團隊之現有專案執行方式進行撰寫，其 它專案特定性章節將於前述起動階段之各項工作中陸續產出，起動 階段各項工作之產出如下：

(1) 招標文件取得與評估：業主提供之各項招標文件，如：「招標須 知」、「徵求需求說明書」、「招標投標及契約文件」…等，團隊內 部產出則為「第一階段可行性評估報告表」。

(2) 規劃起動階段：起動階段之工作計劃。

(3) 延伸系統願景：專案之「願景」、「範疇」、「需求重點」及「可能 競爭者」…等資訊及「業務模型」，後續據以分析提出「投標建 議書」中之「解決方案建議」。

(4) 可行性評估：「階段評估條件列表」，用以確保達成階段之主要目 標，團隊內部產出則為「第二階段可行性評估報告表」。

(5) 獲得大部份系統需求：使用案例排序後之列表，此產出為「投標 建議書」中「候選需求列表」、「系統內涵描述」、「功能性需求描 述」、「非功能性需求描述」之主要內容。

(6) 候選架構分析：定義之「子系統」及「分析模型」，後續據以分 析提出「投標建議書」中之「解決方案建議」。

(7) 候選架構設計(架構設計)：候選架構之「架構圖」，此產出為「投 標建議書」中「系統架構建議」之重要項目。

(8) 概念驗證實作：「使用者介面雛型」及「演算法雛型」，此產出為

「建議書簡報」中「雛型展示」之主要內容。

(9) 概念驗證測試：「雛型測試結果」與「測試計劃之樣本」，「測試 計劃之樣本」為「投標建議書」中「測試方法說明」之主要內容。

(10) 進行成本分析：「專案成本分析表」及「專案成本分析圖」，此 產出為「投標建議書」中「專案成本分析」之內容。

(11) 分析專案預期效益：「專案預期效益說明」，此產出為「投標建 議書」中「投標價格」及「專案預期效益」之內容，團隊內部產 出則為「第三階段可行性評估報告表」。

(12) 評價起始階段：起始階段之工作內容及成果是否完成，且符合 專案目標。

(13) 撰寫投標建議書：「投標建議書」及「建議書簡報檔」，供「進 行投標」及「建議書簡報」之用。

(14) 進行投標：收文憑據/押標金收據。

(15) 建議書簡報：進行建議書簡報及回答評審詢問之問題。

(16) 接獲開標結果：是否得標之正式結果通知，如為得標，則通知 議價及簽約時間。

(17) 議價及議約：專案之正式合約內容。

5. 起動階段之管理問題分析：

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

(1) 階段參與人員整合問題：各項工作此階段之時程緊迫，不確定因 素多，且經由不同人負責，工作順序及成果又必須緊密整合，如 無有效管理方式，可能因牽一髮而動全身，影響整體階段成果。

(2) 階段範疇認知不當問題：階段評估之專案範疇廣泛且時間有限，

如無有效管理方法，可能無法依範疇之掌握度而進行適切之深度 評估，而導致部份重要專案範疇認知不當，小則影響開標結果，

大則得標後因範疇認不當，而造成無法結案。

(3) 階段時間短暫問題：本階段時程相當短暫，各項工作如無有效工 作時間分配安排及管理方法，可能到本階段末期，才發現仍有許 多工作尚未完成。

(4) 階段評估專案成本客觀性問題：因成本評估人員之經驗或疏失而 造成專案成本低估或部份成本項目漏估，導致實際專案執行成本 大幅超出預期，甚至不符成本。

(5) 對把握度不足專案投入之階段費用損耗問題：每個專案的投標成 本相當高(投入各項工作之人力、建議書與簡報檔大量印製…

等)，如果無論是否把握度如何皆進行投標將產生大量成本耗費。

(6) 建議書提出架構無法滿足專案效能需求問題：由於本階段時間短 暫，無論就時間或以成本考量都難以對建議書提出架構進行完整 建置及效能驗證，因此可能提出之架構將無法滿足專案效能需 求，造成專案驗收之困難。

(7) 階段參與人員之工作調配問題：因本階段部份參與之技術人員可 能非專職進行本階段，因此可能因投入程度不足而無法產出完整

(7) 階段參與人員之工作調配問題：因本階段部份參與之技術人員可 能非專職進行本階段，因此可能因投入程度不足而無法產出完整