建構階段(Construction Phase)之程序工作

1. 建構階段之目標：

此階段的重點放在分析、設計及程式開發的實作部份，並繼續發展 上一階段的基準架構，不斷附加、更新系統功能，使系統達成可以 上線運作的目標。

2. 建構階段之主要工作：

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

z USDP-建構階段早期工作

(1) 分派人員工作(Staffing the Phase; USDP- 15.2.1)：詳述階段已完 成架構基準線，並將子系統及介面進行切割，本工作之重點在於 將子系統分配給明確之開發成員- 「使用個案工程師」(Use-case Engineer)、「元件工程師」(Component Engineer)、「測試工程師」

(Test Engineer)、「系統整合工程師」(System Integrator)、「整合測 試工程師」(Integration Tester)及「系統測試工程師」(System Tester)。

(2) 設定評估條件(Setting the Evaluation Criteria; USDP- 15.2.2)：因 應階段目標，我們通常對以下項目進行評估：

A. 專案產出系統之完整性及成熟度是否足以移交給客戶。

B. 階段之里程碑，一般包含各反覆(Iteration)規劃完成時間，及合 約規範交付文件(User Material)，本階段交付文件包含：

z 系統分析規格書。

z 系統設計規格書。

z 系統測試計劃書。

z 系統測試報告書。

z 原始程式及程式執行檔 z 系統使用手冊。

z 保固維護計劃 z 系統安裝手冊 C. 專案產能。

z USDP-需求了解至測試之核心工作：建構階段之核心工作為不

斷反覆進行需求了解至測試之工作，並整合各次反覆之成果進 行建構可執行之系統。

(3) 了解完整系統需求(Requirements; USDP- 15.4.1)：詳述階段已對 近 80%的重點使用個案進行了解，本工作之重點為對詳述階段 尚未完全了解之使用個案進行了解、詳述及建購，並完成使用者 介面雛型，本工作包含以下五項行動：

A. 完成找尋及辨視所有剩餘的使用個案及主動者(Find Use Cases and Actors)。

B. 進行未完成使用個案之開發順序排列(Prioritize Use Cases)。

C. 詳述所有剩餘的使用個案(Detail a Use Case)。

D. 建構完整的使用個案模型(Structure the Use-Case Model)。

(4) 完整功能分析(Analysis; USDP- 15.4.2)：在詳述階段已經分析了 約 40%的使用個案，本工作之重點為對完成詳述階段尚未完成 之使用個案分析，並更新架構圖，本工作包含以下四項行動：

A. 分析架構-建立完整之包裝架構圖(Architectural Analysis)。

B. 分析所有剩餘的包裝(Analyze a Package)。

C. 分析所有剩餘的使用個案(Analyze a Use Case)。

D. 分析所有剩餘的類別 (Analyze a Class)。

(5) 完整功能設計(Design; USDP- 15.4.3)：在詳述階段已經設計了約 10%的重點使用個案與架構基準線，本工作之重點為對完成詳述 階段尚未完成之使用個案設計，並以不斷增添子系統之內容完成 系統設計，本工作包含以下四項行動：

A. 設計架構-建構完整之架構(Architectural Design)。

B. 設計所有剩餘的使用個案(Design a Use Case)。

C. 設計所有剩餘的類別 (Design a Class)。

D. 設計所有剩餘的子系統(Design a Subsystem)。

(6) 完整功能實作(Implementation; USDP- 15.4.4)：在詳述階段已經 實作了約 10%的重點使用個案，本工作之重點為對完成詳述階 段尚未完成之使用個案實作，並以不斷反覆(Iterative)增添子系統 之方式完成系統實作、單元測試及系統整合，完成實作完整系 統，本工作包含以下四項行動：

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

B. 實作所有剩餘的類別與子系統(Implement a Class and Implement a Subsystem)。

C. 進行單元測試(Perform Unit Testing)。

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

(7) 完整功能測試(Test; USDP- 15.4.5)：在詳述階段已經開始規劃測 試方法及進行少量測試，本工作之重點為以不斷反覆(Iterative) 增添子系統之進度完成系統之測試工作，完成完整系統之測試，

本工作包含以下五項行動：

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

B. 設計系統測試之作法(Design Test)。

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

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

E. 評估測試結果(Evaluation Test)

z USDP-管理商業效益

(8) 管理商業效益(Controlling the Business Case; USDP- 15.5)：在詳 述階段已經藉由建構架構基準線的過程建立了成本基準線，本工 作之重點為由專案經理藉由監控規劃之時程、人力、成本與實際 情況之差異，盡力達成或超越原有規劃，以達成管理商業效益之 目標。

z USDP-評價建構階段工作

(9) 評價建構階段之反覆(Assess the Iterations in the Construction Phase; USDP- 15.6)：本工作之重點為由專案經理及其組成之評 價小組，確認里程碑(反覆及合約交付項目)之達成性及品質程 度，並對測試結果進行檢討，以確保專案產出系統之完整性及成 熟度足以移交給客戶。

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

(10) 建構階段起動會議：由於本階段將大量進行系統之分析、設 計、建置及測試等開發工作，因此大部份之開發人員將在此一階 段才開始參與專案進行，本會議之目的在於對專案團隊階段參與 成員進行專案相關背景情況、目前進度、後續規劃及專案團隊統 一規範說明。

(11) 撰寫系統分析規格書：一般在專案正式展開後的第二個交付項 目為「系統分析規格書」，通常可由系統分析人員於分析後產出，

「系統分析規格書」之重點章節包含「使用個案列表及說明」、「子 系統及介面說明」、「系統架構圖」…等。

(12) 撰寫系統設計規格書：一般在專案正式展開後的第三個交付項 目為「系統設計規格書」，通常可由系統設計人員於設計後產出，

「系統設計規格書」之重點章節包含「使用個案圖及描述」、「系 統流程循序圖及說明」、「系統行動圖」、「類別圖」、「元件圖」…

等。

(13) 撰寫系統測試計劃書：一般在專案正式展開後的第四個交付項 目為「系統測試計劃書」，通常可由測試人員於測試前預先進行 規劃及撰寫，「系統測試計劃書」之重點章節包含「測試範圍及 執行時間」、「測試工具及方法說明」、「測試項目的通過/失敗準 則」、「測試個案」…等。

(14) 撰寫系統測試報告書：一般在專案正式展開後的第五個交付項 目為「系統測試報告書」，通常可由測試人員於測試後進行撰寫，

「系統測試報告書」之重點章節包含「測試個案」、「測試結果」、

「測試問題與處理報告單」、「效能測試結果」…等。

(15) 撰寫系統使用手冊：一般在專案正式展開後的第六個交付項目 為「系統使用手冊」，通常可指定專人進行撰寫，「系統使用手冊」

通常包含「系統簡介」、「系統流程」、「系統角色與對應功能」、「功 能操作畫面及說明」…等。

(16) 撰寫保固維護計劃：一般在專案正式展開後的第七個交付項目 為「保固維護計劃」，通常內容將評估系統之實際開發、測試情 況，擬定保固維護期間之維護方案，「保固維護計劃」通常包含

「保固維護小組之編組」、「保固維護期間之溝通方式」…等。

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

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

3. 建構階段之工作流程：

圖 13 SPDP 建構階段之工作流程

4. 建構階段之主要工作產出：

(1) 分派人員工作：專案分工表。

(2) 設定評估條件：里程碑(含反覆及合約交付項目)之評估條件及足 以移交給客戶之專案產出系統的完整性及成熟度定義。

(3) 了解完整系統需求：專案團隊內部作為需求追溯使用之需求文 件。

(4) 完整功能分析：專案團隊內部維護使用之分析文件。

(5) 完整功能設計：專案團隊內部維護使用之設計文件。

(6) 完整功能實作：「程式碼」、「執行檔」及「完整系統」。

(7) 完整功能測試：「測試範圍及執行時間」、「測試工具及方法說 明」、「測試項目的通過/失敗準則」、「測試個案」、「測試結果」、

「測試問題與處理報告單」、「效能測試結果」。

(8) 管理商業效益：工作計劃與實際進度與工時落差，程式行數。

(9) 評價建構階段之反覆：會議記錄，包含檢討會議之問題列表。

(10) 建構階段起動會議：建構階段起動會議簡報及會議記錄。

(11) 撰寫系統分析規格書：正式交付之「系統分析文件」。

(12) 撰寫系統設計規格書：正式交付之「系統設計文件」。

(13) 撰寫系統測試計劃書：正式交付之「系統測試文件」。

(14) 撰寫系統測試報告書：正式交付之「系統測試文件」。

(15) 撰寫系統使用手冊：「系統使用手冊」。

(16) 撰寫保固維護計劃：「保固維護計劃」。

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

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

5. 建構階段之管理問題分析：

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

(1) 開發進度管理問題：本階段之主要工作是由大量開發人員密集地 從事系統開發工作，然而因為軟體開發的不可視特性、人員之不 可預期突發情況及除錯(Debug)過程可能因思考盲點讓開發進度 長久延遲…等，造成開發進度落後。

(2) 建構管理問題：本階段之主要工作是由大量開發人員密集地從事 系統開發工作，在較大型之專案通常由多組開發人員進行，因此 各組人員開發成果之合併及各反覆之產出版本常常造成相互干 擾，而造成專案時程之延遲，此外，實務上常發生不可預期之問 題，如：開發者電腦中毒、硬碟毀損…等情況，或因開發者擁有 相當多開發版本而產生人為疏失(如：改錯版本)，造成必須重新 重覆開發已完成程式，造成成本浪費，此外，在此一階段，使用 者通常在進行反覆(Iteration)開發的功能確認時會提出功能變更 之需求，這些需求變更如未妥善進行管理時會造成使用者對專案 的滿意度不佳。

(3) 開發環境與正式環境差異問題：本階段之最重要產物為提供一版 可移交予客戶之系統，然而可能因開發環境與正式環境之細微差 異，造成交予客戶之系統存在部份瑕疵或少數功能無法執行。

(4) 工作品質不佳的問題：因本階段開發工作或撰寫文件有瑕疵而未 能及時予以改善、階段進行測試完整性不足，導致後續相關開發 工作品質遭受影響或工作產出之品質不佳。

(5) 階段參與人員之間相互溝通問題：階段參與成員因工作默契不 足，又因本階段可能必須與其它成員開發產品頻頻進行整合，如 無法妥善進行相互溝通之磨合，導致因參與成員間之溝通方式不

(5) 階段參與人員之間相互溝通問題：階段參與成員因工作默契不 足，又因本階段可能必須與其它成員開發產品頻頻進行整合，如 無法妥善進行相互溝通之磨合，導致因參與成員間之溝通方式不