新產品研發專案警訊管理系統模式建構-以A公司為例

國

立

交

通

大

學

工業工程與管理學系

碩

士

論

文

新產品研發專案警訊管理系統之建構

—以 A 公司為例

A New Product Development Project Alarms Management

System for Case Company

研 究 生：劉軒榮

指導教授：許錫美 教授

新產品研發專案警訊管理系統模式建構-以 A 公司為例

研究生: 劉軒榮 指導教授: 許錫美 博士 國立交通大學管理學院(工業工程與管理學系)碩士班 摘要 新產品研發專案的專案管理人員，在專案進行的過程中，需隨時監控專案的 進度和成本，異常發生時能及時採取行動，以期待新產品研發專案能如期完成。 本論文以某一個案公司為例，實做一專案警訊管理系統，其功能如下：專案 規劃、人力資源規劃與專案警訊功能。專案規劃，主要記錄專案的相關基本資料， 方便專案管理者將專案資料輸入系統並做日後維護。人力資源規劃，人力資源為 專案重要資源之一，此功能提供管理者指派人力，並可設定人力負荷上限，以便 系統判斷人員是否超過負荷。專案警訊管理功能，針對成本與研發時程進行管 控，提供使用者為重點專案或是任務設定警訊準則，在專案異常之初發出警訊， 並紀錄相關歷史警訊紀錄、時程更改記錄與負責人更改記錄。該系統使用折線 圖、PACT圖以及甘特圖，以圖形化的方式表達專案的進行狀況，讓使用者能夠 更迅速的瞭解專案的進行狀況。 關鍵字：新產品研發，專案管理，專案警訊，PACT

A New Product Development Project Alarms Management

System for Case Company

Student: Hsuan-Jung Liu Advisor: Dr. Hsi-Mei Hsu Department of Master Program of Industrial Engineering and Management

National Chiao Tung University

Abstract

To compose a project could be finished in time, project managers ought to monitor the progress and the cost of project during the proceeding of project.

This study made a case study of a certain company. Actually constructed a project alarms management system. Its functions are as following: project

programming function, human resource allocation and project alarm function. Project programming function: Its main function is recording relative data of project. It helps project managers to input data into system and maintain these data. Human resources allocation: human resources are significant resources of project. As a result, this function provides managers to allocate human resources. Nevertheless, managers could set the upper bound for the loading of worker .Therefore, the system will determine whether the loading of worker exceed upper bound or not. Project alarm function: This function monitors cost and progress. It provides users to set alarm criteria for projects or tasks. While there is any unusual situation, the system will result alarms and record relative alarm records, change records of schedule and change records of person in charge. The system uses line chart, PACT chart and Gantt chart to express the situation of project in a graphic way. It allows users to realize the situation of project immediately.

誌謝

在兩年的研究所生涯中首先要感謝的人為我的論文指導教授-許錫美博士， 這些日子裡多虧了許老師的耐心教導以及指引論文的方向，在我論文陷入膠著時 老師總是能夠適時地給予實質上的幫助，老師的研究態度也成為我日後的典範。 此外李曉娟學姐的協助也給予我很大的幫助，從學姐的建議裡我獲得了許多 寶貴的經驗，使得論文的進度更加順利，在此必須特別感謝學姐在繁忙中抽空給 予協助。 在這不算短的研究生生涯中我學到了許多人生寶貴的經驗，也讓我的人生磨 練增加不少，在交大兩年中所認識的同學雖然未來未必會再有交集，但人生的回 憶中卻多了一塊不可抹滅的區塊，也許幾年後我會忘記交大餐廳難吃食物的味 道，但這些在研究所遇到的摯友們所帶給我的回憶還是會一樣深刻。 研究室的伙伴們：秉爺、小黑、艾苓和東森，有你們的陪伴實在是很幸運， 我不會忘記大家一起 Meeting 的回憶，希望大家未來的發展都能一帆風順。此外 要感謝佳噥，在有妳的日子裡壓力總是不翼而飛，妳的支持和體諒讓我的研究生 活很不一樣。 最後要感謝我的爸媽，父母的支持是我撰寫論文的重要支柱，不管是物質上 或是精神上的支持，在我繁忙之際，父母總是能夠體諒並且鼓勵我，使我有繼續 前進的動力。 劉軒榮 于丁亥年仲夏

目錄

中文摘要………i 英文摘要………ii 誌謝………...iii 目錄………...iv 圖目錄………...vi 表目錄………...ix 第一章 緒論...1 1.1 研究背景與動機...1 1.2 研究目的 ...1 1.3 研究範圍與限制 ...2 1.4 研究流程 ...3 1.5 論文架構 ...5 第二章 文獻回顧...6 2.1 新產品研發流程 ...6 2.2 新產品研發專案 ...9 2.3 專案進度與成本管控之相關文獻 ...10

2.4 Microsoft Project 及盈餘分析（Earned Value Analysis）簡介 ...15

2.4.1 Microsoft Project 簡介 ...15

2.4.2 盈餘分析簡介 ...15

2.5 統一塑模語言（UML, Unified Modeling Language） ...18

2.5.1 UML 在軟體塑模中所扮演的角色是什麼？...18 2.5.2 UML 與物件導向方法之關係...18 2.5.3 UML 的重要性...19 2.5.4 UML 模式圖簡介...19 2.5.5 物件導向塑模與塑模工具 ...20 第三章 個案公司專案警訊管理系統模式建構...23 3.1 個案公司簡介 ...23 3.2 需求分析 ...23 3.2.1 個案公司問題描述 ...23 3.2.2 系統目標 ...24 3.2.3 需求架構及流程圖 ...25 3.3 需求塑模 ...28 3.3.1 建構使用者個案圖 ...28 3.3.2 建構活動圖 ...31 3.4 物件資料結構塑模 ...35 3.5 物件互動行為塑模 ...39

3.5.1 專案規劃之物件互動行為塑模 ...39 3.5.2 人力資源規劃之物件互動行為塑模 ...42 3.5.3 專案警訊之物件互動行為塑模 ...45 第四章 系統環境與內容說明...51 4.1 系統實作 ...51 4.2 系統環境 ...51 4.3 相關軟體 ...51 4.4 系統介面與操作說明 ...52 4.4.1 使用者權限 ...52 4.4.2 專案規劃功能 ...52 4.4.2.1 建立新專案 ...53 4.4.2.2 專案資料維護 ...57 4.4.2.3 專案成本維護 ...60 4.4.2.4 專案歷史資料紀錄 ...63 4.4.3 人力資源規劃功能 ...64 4.4.3.1 部門/人員資料維護 ...64 4.4.3.2 人力資源管理 ...67 4.4.4 專案警訊功能 ...69 4.4.4.1 警訊準則設定 ...70 4.4.4.2 任務檢核點設定 ...71 4.4.4.3 警訊列表 ...71 4.4.4.4 PACT 圖表...79 4.5 系統成效與探討 ...81 第五章 結論與未來研究方向...82 5.1 結論 ...82 5.2 未來研究方向 ...82 參考文獻...84

圖目錄

圖 1.1 研究方法與步驟流程圖………5 圖 2.1 Cooper 所修改的階段–關卡流程………...7 圖 2.2 新產品開發過程的各時期階段、相對應之評估關卡及重要指標…….……8 圖 2.3 設計驗證測試（DVT）計畫……….………..10 圖 2.4 設計成熟測試（DMT）計畫……….……….10 圖 2.5 PACT………...……….……….…….12 圖 2.6 專案控管甘特圖………17 圖 2.7 物件導向塑模活動與塑模工具………..22 圖 3.1 系統架構圖………..26 圖 3.2 系統基本結構流程………..27 圖 3.3 專案規劃使用者個案圖………..28 圖 3.4 人力資源規劃使用者個案圖………..29 圖 3.5 專案警訊使用者個案圖………..30 圖 3.6 專案規劃活動圖………..32 圖 3.7 人力資源規劃活動圖………..33 圖 3.8 專案警訊活動圖………..34 圖 3.9 專案規劃類別圖………..35 圖 3.10 人力資源規劃類別圖………36 圖 3.11 專案警訊類別圖……….37 圖 3.12 專案規劃循序圖（新增/修改/刪除專案資料）………40 圖 3.13 專案規劃循序圖（查詢專案資料或圖表）……….41 圖 3.14 人力資源規劃循序圖（設定人員資料）……….42 圖 3.15 人力資源規劃循序圖（指派任務）……….…….43 圖 3.16 人力資源規劃循序圖（查詢人力資源分配狀況）………44 圖 3.17 人力資源規劃循序圖（查詢人力負荷狀況）………..44 圖 3.18 專案警訊循序圖（專案資料更新）………..45 圖 3.19 專案警訊循序圖（設定專案/任務判斷準則）……….……46 圖 3.20 專案警訊循序圖（異常處理）……….………48 圖 3.21 專案警訊循序圖（填寫/查詢專案(任務)警訊表單）………49 圖 3.22 專案警訊循序圖（專案圖表查詢）……….………50 圖 4.1 三層式架構示意圖………..51 圖 4.2 專案規劃功能畫面………..52 圖 4.3 建立新專案畫面………..53 圖 4.4 輸入專案基本資料畫面………..53 圖 4.5 輸入專案產品規格畫面………..54 圖 4.6 輸入任務基本資料畫面………..55

圖 4.7 輸入子任務基本資料畫面………..55 圖 4.8 設定前置任務畫面………..56 圖 4.9 設定前置子任務畫面………..56 圖 4.10 專案資料維護畫面………57 圖 4.11 任務資料修改畫面……….57 圖 4.12 專案資料維護子功能畫面………58 圖 4.13 專案甘特圖查詢畫面………59 圖 4.14 任務進度開始/完成確認畫面………...59 圖 4.15 檢核點確認畫面………...…….60 圖 4.16 檢核點項目確認畫面………60 圖 4.17 專案成本維護畫面……..……….…….…61 圖 4.18 專案成本折線圖畫面………..………..………61 圖 4.19 專案成本維護子功能畫面…...……….………62 圖 4.20 新增專案預計成本畫面………62 圖 4.21 專案歷史資料紀錄功能畫面………63 圖 4.22 任務預計時程更改記錄畫面………63 圖 4.23 任務負責人更改記錄畫面……….………...63 圖 4.24 負責人警訊記錄畫面………64 圖 4.25 部門人員資料維護畫面………64 圖 4.26 公司資料畫面………65 圖 4.27 部門資料畫面………65 圖 4.28 主管資料畫面………66 圖 4.29 員工資料畫面………66 圖 4.30 專案管理員資料畫面………66 圖 4.31 專案相關人員組織畫面………66 圖 4.32 設定人員負荷畫面………67 圖 4.33 指派任務負責人畫面………67 圖 4.34 指派專案相關人員畫面………68 圖 4.35 顯示人員負荷畫面…………...……….68 圖 4.36 設定任務參與人員畫面…...……….69 圖 4.37 專案警訊功能畫面………69 圖 4.38 專案準則（容忍度）設定畫面………70 圖 4.39 任務準則（容忍度）設定畫面………70 圖 4.40 設定任務檢核點畫面………71 圖 4.41 設定檢核項目………....71 圖 4.42 進度警訊列表畫面 1………..72 圖 4.43 進度警訊列表畫面 2………..………72 圖 4.44 進度警訊表單畫面………73

圖 4.45 進度警訊電子郵件內容畫面………73 圖 4.46 發送郵件給專案相關人員畫面………74 圖 4.47 發送郵件給其他人員畫面………74 圖 4.48 通知後續任務負責人畫面………75 圖 4.49 任務檢核點警訊表單………76 圖 4.50 延後檢核點延誤項目………76 圖 4.51 成本警訊列表畫面 1…….………77 圖 4.52 成本警訊列表畫面 2……….77 圖 4.53 成本警訊表單畫面………78 圖 4.54 成本警訊電子郵件內容畫面………79 圖 4.55 PACT 圖畫面 1………80 圖 4.56 PACT 圖畫面 2………80

表目錄

表 2.1 不同的專案控管技術之比較………..14 表 4.1 系統成效探討………..81

第一章 緒論

1.1 研究背景與動機

電子資訊相關產品的生命週期日益縮短，新產品的上市時間對該新產品的市 場佔有率及收益有很大的影響。新產品的研發通常以專案方式進行，速度和成本 是兩項決定此研發專案成功與否的主要因素。一個公司通常有許多專案同時進 行，研發工程師需參與多項專案的研發活動。當某一專案的某項研發活動發生延 誤時，常造成後續研發活動的工程師無法按原排程工作，研發專案的延誤使得產 品失去競爭力，進而造成公司的重大損失。 在訪談台灣電子資訊相關公司的專案部門後，發現僅有少數的專案管理人 員，且因研發活動常面臨許多不確定因素，研發活動的延誤及研發成本的超出， 是公司常見及不可避免的現象。專案管理人員希望當延誤發生時能即早得知，以 便採取應變措施，規劃相關資源。因此一個輔助專案管理人員控管專案進度和成 本，提供專案基本資料、專案目前和過去的進度和成本等相關資料，對於專案的 異常發出警訊，並且對系統所發出的警訊加以處理的專案管理系統有其必要性。

1.2 研究目的

在新產品研發專案的控管中，專案管理員往往沒辦法即時彙整相關資訊，以 幫助相關決策。雖然市面上已存在許多專案管理的套裝軟體，但卻無法提供即時 警訊的功能，使得專案管理員無法在專案異常的第一時間做出應變措施，因而導 致專案嚴重偏差。因此本研究主要目的在於發展出適用於新產品研發專案的警訊 系統。 本系統是以專案管理者（project manager）的觀點來設計，主要功能如下： 1. 專案的管理與規劃

A. 藉由網路和資料庫的技術，將專案的相關資料存放在資料庫，系統的使 用者可以藉由網路瀏覽器輸入專案相關資訊、專案所包含的任務資訊、 任務之間的關連性、時程進度和成本等資料。 B. 在查詢專案資料方面，使用者可以藉由網頁瀏覽器快速的獲取到專案相 關資訊，並且可以對現存的資料加以修改。 2. 專案的異常警訊控管 針對需求為專案設定進度或成本的警訊準則，一旦專案達成警訊條件，系統 便產生警訊資料至系統的警訊列表，藉由專案會議的開會結果，由專案管理 員填寫警訊處理表單，對警訊異常現象加以說明，並輸入異常原因及因應對 策，通知相關人員，追蹤因應對策的執行狀況。 3. 專案的人力資源分配 針對專案的人力資源分配部分，本系統紀錄目前各人員的負荷，使專案主管 可以清楚得知目前公司內部的人力資源使用狀況。 本研究期望藉由此系統紀錄相關資訊，使專案相關人員之間的溝通更加有效 率，此系統的警訊功能提供了專案即時控管的功能，以控管專案的進度與成本。

1.3 研究範圍與限制

研究範圍與限制如下： 1. 本研究的目標是建構一個具有警訊功能的專案管理系統，但其專案種類限定 為新產品研發專案，由於專案的控管形式和內容會因產業而異，因此該研究 以一案例公司為設計對象。 2. 本研究以專案管理者的角度來設計專案管理系統，因此系統的功能以因應專 案管理者的需求為主。 3. 本研究所開發的系統定義兩種使用者：專案管理者和任務負責人，前者擁有

關權責人員。

1.4 研究流程

本論文的研究流程如圖 1.1。

1.5 論文架構

本論文的章節如下： 1. 第一章：緒論 說明現今的企業環境以及專案管理環境，對研究的背景及動機加以闡述，並 確認研究目的，指出研究的範圍與限制，最後規劃出基本的研究流程。 2. 第二章：文獻回顧 主要探討新產品研發以及專案控管的相關文獻，主要分為下列四個部分： 2.1 新產品研發流程 2.2 新產品研發專案 2.3 專案進度與成本管控之相關文獻 2.4 統一塑模語言（UML）之相關介紹 3. 第三章：專案警訊管理系統模式建構 先對個案公司做介紹，緊接著開始進行系統塑模建構工作，程序的先後順序 如下： 3.1 個案公司簡介 3.2 需求分析 3.3 需求塑模 3.4 物件資料結構塑模

3.6 系統建構技術與環境 4. 第四章：系統實作與功能說明 4.1 系統實作 4.2 系統環境 4.3 相關軟體 4.4 系統介面與操作說明 4.5 系統成效與探討 5. 第五章：結論與建議 5.1 結論 5.2 未來研究方向

第二章 文獻回顧

本章主要探討新產品研發以及專案控管的相關文獻。主要分為四個部分：（1）

新產品研發流程（2）新產品研發專案（3）專案進度與成本管控之相關文獻（4）

Microsoft Project 及盈餘分析（Earned Value Analysis）簡介（5）統一塑模語言之

相關介紹。

2.1 新產品研發流程

為了快速且有效率地研發新產品，企業組織通常會依循一定的流程來進行新 產品的研發，目前最受企業組織所廣泛使用的新產品開發流程中各階段管控關卡 為 Cooper【4】所提出的階段–關卡流程，階段–關卡流程監控整個產品從構想產 生到產品上市期間的各種事項，流程分為數個階段，並且設立了許多的關卡，藉 由檢驗表來評估專案是否符合標準來決定過關或者淘汰，關卡的評估會影響到產 品專案的投資組合。Cooper 在 2002 年提出了改良後的階段–關卡流程，和 Cooper 在 1995 年所提出的架構大致上相同，最大差異在於流程新增了「構想發現」階 段，取代了原來的構想產生，如圖 2.1。

初步評估 細部調查 產品發展 產品與流程驗證 產品上市 初步評估 上市前決策 決定產品市產性 發展後檢核 二次檢核 構想發現 圖 2.1 Cooper 所修改的階段–關卡流程【7】 此後新產品研發過程被更細分為三個時期、六個階段，並歸納出各個評估關 卡所對應的評量指標【5】，如圖 2.2 所示。主要分為三個時期，分別為開始時期、 執行時期和結束/轉移時期（close-out phase）。 1. 開始時期 主要可分為構想產生、概念發展及商業計畫三個階段。這幾個階段所包含的 評估關卡有構想篩選、概念測試和商業分析，並依照策略制訂專案活動之計 畫與目標。

2. 執行時期 主要內容為產品發展，包括了技術、零件或者完整產品之開發。此時期的評 估關卡為產品功能測試。執行時期的績效評量指標包含了產品效能、產品品 質、技術可行性、成本和進度。 3. 結束/轉移時期 包括了市場測試和發行兩個階段，其目的是要將研究發展之成果轉移至市場 或者其他部門。此時的評估關卡為市場測試分析和發行後評估。因此常見的 活動為市場測試和追蹤、資料文件之建檔等。 圖 2.2 新產品開發過程的各時期階段、相對應之評估關卡及重要指標【5】

2.2 新產品研發專案

專案管理的範圍廣泛，本研究的內容是針對新產品研發類型的專案，新產品 研發專案與一般專案的內容不盡相同，新產品研發專案的使命是在有限的時間與 預算內，發展出符合規格說明的產品。而產品設計驗證的目的則是確認產品符合 產品規格說明【2】。 一般而言，這類測試有三種： 1. 設計驗證測試（DVT）： 這類測試通常由品質認證工程師來進行，目的在於確認產品設計是否準備好 可以生產。DVT 要包括功能性、非功能性與環境測試。多數企業會在大量

生產之前，用不低於平均故障間隔時間（mean time between failure, MTBF）

三分之一的時間來測試產品。這是產品開始大量生產的重大決策，應該被納 入整體專案計畫中（見圖 2.3）。 2. 設計成熟測試（DMT）： 這類測試也是由品質認證工程師來進行，目的在於確認產品設計定案、準備 好可以生產。這通常是專案進入結案階段之前的最後一個步驟。就像 DVT 一樣，DMT 也應該成為整體專案計畫的一部分（見圖 2.4）。 3. 持續的可靠性測試（reliability tests）: 產品一旦進入生產，就要持續透過定期可靠性（環境）測試，來評估產品品 質與可靠性。這通常是生產測試的一部分，和專案無關。

圖 2.3 設計驗證測試（DVT）計畫【2】

圖 2.4 設計成熟測試（DMT）計畫【2】

2.3 專案進度與成本管控之相關文獻

進度和成本一直是專案管理所有管控的兩大重點，而在新產品專案管理中，

在新產品研發專案管理中，監控專案時主要會牽涉到三個維度：進度、成本 和時間。此外還牽涉到預計和實際的績效表現，以下將對新產品研發專案時要監 控的內容做介紹： 1. 實際和預計的成本差異： 在專案管理時經常會在專案中各個子活動的預計結束時間設置檢核點 （check point），並且在檢核點檢視實際和預計的成本差異，以了解實際的 成本是否超出預算，避免發生嚴重超支的情況發生。 2. 實際和預計的進度差異： 控管成本之外，進度是另一項控管重點，在到達檢核點時必須檢查各專案的 實際完成進度，並且和預計的進度作比較，若進度發生落後的狀況則必須採 取應對措施，避免落後的程度擴大。 3. 同時考慮進度和成本，比較實際和預計之間的差異： 在新產品研發專案中常常需要同時考量進度和成本此兩項目，之所以要同時 考量進度和成本，主要是因為在新產品研發專案中，單一考慮進度或是成本 時，往往會忽略調許多訊息。當專案在檢核點檢查其進度是否達成時，若沒 考慮到成本是否超出，則既使進度達到預期的需求而成本超出，也會造成專 案的異常；當專案進度落後時，實際成本若遠小餘預期成本，專案決策者有 可能會接受此種狀況發生。同樣的，在檢核點只考慮成本時也會發生類似的 狀況。因此最好的方法是決策者事先訂出在進度和成本之間的平衡點，同時 考量進度和成本。 我們通常藉助圖形化的管理工具來管理專案，在專案開始進行之前，我們可 將預計的專案進行狀況透過三個維度：進度、成本和時間，使用座標點描繪出來。 當專案開始進行後，可在座標上描繪座標點來表示專案實際的進行狀況，即可了 解預計和實際狀況的偏差，再針對這些偏差來採取相對應的行動，使專案不偏離 預計的目標。 上述的圖形化管制工具可以提供專案狀態和偏差的數據以及圖形化結果，目

前已經存在許多類似的管理工具，像是甘特圖、CPM、PERT-TIME、PERT-COST、

DCPM、GERT、VERT、RPD、Slip Chart、SSD Graph，但是上述的工具皆沒有

辦法提供整合觀點的進度和成本的歷史紀錄。

現今市面上已有許多專案管理軟體，其中 Microsoft 公司所發行的 Project 軟

體的功能齊全且最受到企業所廣泛使用，Microsoft Project 提供了盈餘分析

（Earned Value Analysis）的功能，而盈餘分析也是目前最常用的一種績效評估方

法，雖然盈餘分析將進度透過轉換為成本的方式表現出來，但盈餘分析主要著重

於成本分析，而且將進度轉為成本的結果可能和實際狀況有誤差，尤其是在新產

品研發專案。

在專案進度及資金管控方面，A.S. Pillai 和 K.S. Rao【3】提出一名為 PACT

的專案計畫控管工具，如圖 2.4 所示，為專案的表現狀況提供了更佳的觀點。其

主要用來規劃專案之時程進度及成本，並於專案執行期間比較實際與規劃目標的

PACT 是一個由四個象限所組成的圖形，除了包含時間、成本和進度三個維 度，還包括了預計和實際的績效表現曲線。其中第一象限為成本 vs.時間的表現； 第三象限為進度 vs.時間的表現；第二象限是由第一和第三象限相對應的座標點 所轉換而來（如圖 2.5 的虛線所示），為成本 vs.進度曲線，由成本 vs.進度曲線我 們可以得到成本和進度之間的偏差，以下將以圖 2.5 為例，介紹可以從 PACT 中 可以得到的實際與預計之差異資訊： A. 由第三象限： 1. 在第 57 個月結束時，在沒有考慮資源耗費的情況下，存在著-16%的進 度偏差。 2. 依照專案進度的趨勢，專案的行程將會落後 14 個月。 B. 由第一象限： 在第 57 個月結束時，在沒有考慮進度的情況下，存在著$20 百萬元的成本 差異。 C. 由第二象限： 1. 在相同資源耗費的情況下，存在著-9%的進度差異。 2. 在相同進度的情況下，存在著$+6 百萬元的偏差。 3. 區域（A）表示在花費較多成本的情況下達到較少的進度，需要採取及 時的修正行動。區域（B）表示在花費較少成本的情況下達到較多的進 度。在第 57 個月結束時，座標點落在區域（A），因此需要採取相對應 的修正行動。

甘特圖 PERT/CPM 和

PERT-COST RPD GERT VERT Slip chart SSD graph

Earned value analysis PACT 最適用於專 案的何種階 段 規劃和監控 規劃和監控 主要為規劃 主要為規劃 主要為規劃 主要為規劃 規劃和監控 規劃和監控 規劃和監控 著重的參數 時間 時間和成本 時間為主 時間和成本 時間、成本 和進度 時間 時間和成本 以成本的形 式表示時進 度&成本 整合的圖形視 覺方式表示時 間、成本和進 度 準備需求和 操作成本 少 中等 中等 多 多 少 少 少 中等 管理新產品 研發專案的 能力 無 中等 極佳 佳 極佳 佳 無 佳 極佳（進度直 接和里程碑的 完成連結而不 是和工作的績 效連結） 時間、成本和 進度 是否有提供 決策和規劃 的時間、成本 和進度的歷 史資料 無 無 無 只有時間和 成本 時間、成本 和進度 只有時間 只有時間 以成本的形 式表示進度 &成本 表 2.1【3】 不同的專案控管技術之比較

2.4 Microsoft Project 及盈餘分析（Earned Value Analysis）簡介

在章節 2.3 中提到了 Microsoft 公司所發行的 Project 專案管理軟體以及

Project 用來同時控管成本和進度的盈餘分析（Earned Value Analysis），在此將對

Project 的主要功能以及盈餘分析方法做簡單的敘述，以利未接觸過 Project 的讀 者瞭解其管控專案的方式。

2.4.1 Microsoft Project 簡介

現今的公司企業中中有大約 80%的專案控管人員使用 Microsoft 公司所發行 的 Project 軟體來進行專案控管工作。Project 軟體主要利用甘特圖來進行，只要 在甘特圖加入不同顏色的長條圖便能表達預計與實際的專案完成狀況，如圖 2.5 所示。 根據圖 2.5 可以觀察到淺黃色地帶為週末時間，而進度長條圖卻橫跨這些地 帶。由於這些區域用黃色表示，因此可以得知週末未排定任何工作。如果週末排 定工作，這些區域將會用不同顏色標示。 在圖 2.5 中我們假設現在日期為 9 月 24 日，此時可以觀察到任務 C 已經完 成、任務 A 進度落後一天、任務 D 進度超前一天、任務 E 已達成目標。整體看 來，這項任務執行狀況良好【2】。

2.4.2 盈餘分析簡介

Microsoft 的 Project 軟體使用盈餘分析（Earned Value Analysis）來同時追蹤

管控專案的進度和成本資料，而盈餘分析也是目前常用的一種專案績效評估方

法，以下將介紹盈餘分析，並說明盈餘分析和 PACT 圖對於進度資料表達方式的

在說明盈餘分析之前先解釋盈餘分析所使用到的三個指標：（1）專案預計進

度之預計成本（the budgeted cost of work scheduled, BCWS），（2）專案實際進度

之實際成本（the actual cost of work performed, ACWP），（3）專案實際進度之預

計成本（the budgeted cost of work performed, BCWP）。

在此藉由一簡單的例子來說明盈餘分析：有一造橋工程等待進行，總工程預 計花費十天的時間建造 100 公尺的橋樑，預計橋樑興建的總成本是 10000 元，因 此每公尺的橋樑花費 1000 元。假設今天為工程進行的第四天，已完成 50 公尺， 並花費 6000 元（假設每天預定進度為 10 公尺），透過盈餘分析我們可以先求得 BCWP 為 5000 元的價值(目前已完成 50 公尺)，BCWS 為 4000 元 (第四天預計 完成 40 公尺)，ACWP 為 6000 元(實際花費花了六千元)，因此進度差異為：BCWP - BCWS =5000 - 4000 = 1000 元，代表超過預訂 1000 元的價值，成本差異為： BCWP -ACWP =5000 - 6000 = -1000 元，代表預算超支 1000 元。 盈餘分析將進度透過轉換為成本的方式表現出來，但盈餘分析主要著重於成 本分析，而 PACT 圖以百分比來表達進度我們可以直接透過圖形觀察到進度百分 比的差異，不需再將進度資料轉換成成本資料，避免轉換所造成的誤差。

2.5 統一塑模語言（UML, Unified Modeling Language）

統一塑模語言（Unified Modeling Language）是 Rational 公司整合 Booch、

Rumbaugh 和 Jacobson 三種方法而提出的物件導向塑模工具。統一塑模語言是一 種視覺化（Visualizing）、文件化（Documenting）及規格化（Specifying）的軟體 塑模語言，共有使用個案圖、類別圖、物件圖、循序圖、合作圖、狀態圖、活動 圖、元件圖與部屬圖等九個模式圖【6】。

2.5.1 UML 在軟體塑模中所扮演的角色是什麼？

軟體發展之方法論中包含了程序（Process）及表示法（Notation）兩個部份， 其中程序指的是系統開發的流程，例：瀑布模式、漸增模式、擴展模式、雛型模 式、螺旋模式等；表示法指的是建構軟體模型中所會用到之符號及規則。

UML 所涵蓋的內容是表示法而非程序，UML 是與程序無關的（Process

Independent），也就是說，無論以任何程序來開發軟體系統，都可以使用 UML 來建構軟體模型。

2.5.2 UML 與物件導向方法之關係

UML 之訂定與物件導向方法有非常密切之關係。UML 中的各種符號及規則 與物件導向語言（Java，C+ +）之結構有完整對應。但是，UML 絕對不僅限用 在物件導向軟體開發，UML 中有些概念與圖形甚至可說是與物件導向無關 例：

Use Case Diagram 及 State Diagram，因此軟體開發時無論是否採用物件導向方

2.5.3 UML 的重要性

UML 是 OMG（Object Management Group）公佈的官方標準，現今 UML 已

為全世界軟體業者所廣泛採用，各大軟體公司（Microsoft、IBM、Oracle 等）， 在其產品中均支援 UML。此外 UML 的應用領域也越來越廣泛（資料庫設計、 韌體設計、資訊管理等）。

2.5.4 UML 模式圖簡介

UML 共有使用個案圖、類別圖、物件圖、循序圖、合作圖、狀態圖、活動 圖、元件圖與部屬圖等九個模式圖。這些模式圖的主要功能簡介如下：

1. 使用個案圖（Use Case Diagram）

使用者個案圖主要的功用是以使用者的觀點描述系統的行為者與系統間之互 動行為與關係。從內部觀點來看，使用者個案圖可描述系統做什麼（What）。 從外部觀點來看，可描述行為者與系統如何互動（How）。 2. 類別圖（Class Diagram） 類別圖主要用以表示系統存在之物件型態（或稱類別）及各物件型態間的靜 態資料結構與邏輯關係，也表達類別之屬性、操作與類別間連結之限制。 3. 物件圖（Object Diagram） 物件圖是用來描述系統於某個時間點的靜態資料結構，由一群相關之物件及 其連結所組成，在某個時間點的一個例子，而非系統的定義，可用來表達一 個系統之複雜的資料結構。 4. 循序圖（Sequence Diagram） 主要用以描述系統運作時物件間的互動行為，且著重以時間之先後順序為主 軸，以表達物件間的訊息傳遞與處理程序。一個循序圖會有一個與之對應的 合作圖，但表達的重點與方式不同。

5. 合作圖（Collaboration Diagram） 主要描述系統運作時物件間的互動行為，且該圖著重表達相關物件間之連結 結構，並能同時展現物件間的訊息傳遞的活動。 6. 狀態圖（State Diagram） 狀態圖用以表達物件在生命週期中的狀態變化，以微觀物件為主，細分物件 所發生的各項事件，並表達物件生命週期之狀態轉變及活動結果。 7. 活動圖（Activity Diagram） 可用於表達執行某一作業行為中之活動、轉換與條件。一個活動圖描述一群 循序與同步的活動，一個活動可表示一個工作流程步驟或一個運算的執行動 作。 8. 元件圖（Component Diagram） 用以說明系統設計過程各類別與物件的配置，以及敘述軟體元件間的組織架 構和關係。元件是開發和執行過程之實際物件的類別，可將分解的實際基本 單位模組化，這些基本單位包括模組（Module），並用有特性和明確定義的 介面。 9. 部屬圖（Deployment Diagram） 用來說明系統各軟硬體（例如處理器、處理元件）元件的配置、關連，以及 同一處理器內執行處理的時程安排。

2.5.5 物件導向塑模與塑模工具

Booch 等人（1999）從概念面提出五個連鎖觀點的軟體系統結構：

1. 使用個案觀點（Use Case View）

2. 設計觀點（Design View）

5. 部屬觀點（Deployment View）。 從系統實作面來說，上述五個觀點配合物件導向的分析與設計（包括需求分 析、系統分析與設計）之活動，可具體地將之分成六種塑模： 1. 使用者個案塑模（或稱需求塑模） 2. 物件資料結構塑模：包含處理設計觀點靜態面之工作 3. 物件互動行為塑模：包含處理各觀點動態面之工作 4. 作業行為塑模：包含處理各觀點動態面之工作 5. 使用者介面塑模 6. 系統元件與結構塑模：包含實施觀點與部屬觀點之靜態工作 上述六種塑模可整合成下列三個階段： 第一階段：使用者個案塑模（需求塑模） 第二階段：物件資料結構塑模、物件互動行為塑模、作業行為塑模或使用者介面 塑模。 第三階段：系統元件與結構塑模或使用者介面塑模。 這些塑模活動並沒有一定的進行順序，也就是說任何一種塑模活動均可視需 要而先進行，第一階段開始後就可執行第二階段，不用等到第一階段結束。同樣 的，第二階段開始以後亦可執行第三階段，不用等到第二階段結束。上述之關係 如圖 2.7 所示：

使用者與 企業需求 使用者個案圖 活動圖 藍圖 資料詞彙 需求擷取 需求轉換 需求塑模 類別圖 物件圖 循序圖 合作圖 活動圖 狀態圖 介面結構圖 介面藍圖與介面詞彙 循序圖與狀態圖 元件圖 部屬圖 物件資料結構塑模 物件互動行為塑模 作業行為塑模 使用者介面塑模 系統元件與結構塑 模 使用者介面設 計 程式設計 資料庫設計 圖 2.7 物件導向塑模活動與塑模工具【6】

第三章 個案公司專案警訊管理系統模式建構

本章先對個案公司（以下稱 A 公司）做介紹，接著開始進行系統塑模建構 工作，程序的先後順序為：需求分析、需求塑模、物件資料結構塑模和物件互動 行為塑模。

3.1 個案公司簡介

A 公司具備高超微機電(MEMS)技術與量產 Know-how 切入無線通訊產業。 以客戶服務為導向，專業解決客戶問題提高其競爭力。A 公司致力開發應用於寬 頻、無線通訊的關鍵零組件/模組，包括：藍芽模組(Bluetooth Module)、無線區

域網路功率放大及開關模組(WLAN PA+SW Module)、薄膜體型聲波共振式濾波

元件(FBAR)等。

3.2 需求分析

本小節將進行 A 公司的需求分析，需求分析階段主要包括：問題描述和系 統目標，最後本小節會將需求整合，列出系統架構和系統流程圖。

3.2.1 個案公司問題描述

本研究藉由訪談來了解 A 公司實際的需求以及所面臨的問題。根據訪談 A 公司專案管理人員的結果得知 A 公司目前最主要的需求是一個能夠協助公司規 劃以及控管專案的系統，目前在進行新產品研發專案時最常遇到的問題就是專案 的進度延遲，由於同時進行的專案通常不只一項，專案底下亦包括許多任務需要

監控，因此在一段期間內往往會出現許多的專案或任務異常狀況，在面對這些異 常狀況時，公司並沒有一套具有整合性且有規劃的系統來幫助紀錄這些異常狀 況，因而造成處理延後或是遺漏了這些異常狀況，進而造成整體專案的進度落 後。雖然公司使用過現有的專案管理軟體來幫助專案管理，但不夠客制化，無法 針對專案主管本身的需求來選擇需要的警訊類型，並且無法指定需要發出警訊的 任務，造成發出過多的警訊，因此造成專案的處理效率低落。 在進行新產品研發專案時，專案主管需要同時顧及到專案的進度和成本資 訊，兩者之間的關係不能偏離預期，一旦偏離預期狀況就必須發出警訊並採取應 對措施，使專案人員可以同時監控到進度和成本這兩項資訊之間的關係，而 A 公司過去所使用的專案管理軟體並無法達到這個需求，關於同時監控進度與成本 的詳細說明及文獻可參考本論文章節 2.3。 另外 A 公司表示，在進行新產品研發專案時，人力是一項非常重要的資源， 但數個專案同時進行時，專案管理者往往沒辦法清楚且快速地得知任務負責人的 任務負荷狀況以及其相關資訊。

3.2.2 系統目標

本研究針對公司所提及的許多問題，經過整理後，歸納成幾個主要的改善目 標或功能： 1. 專案進度與成本管控： 建立各專案的各項任務的進度、成本、日期及負責人員等相關資料。 2. 合適的警訊機制： 讓系統在進行專案管理時可以提供警訊資訊來幫助專案管理和異常的後續 處理動作。避免警訊過多，僅管控重要的任務。由專案管理者決定需要監控 之專案或任務。 3. 檢視人員負荷： 以關連式資料庫為工具，可以檢視工程師所負責的所有任務及其負荷。 4. 維護的方便性： 可以視情況對專案相關資料加以修改。

系統在輸入專案相關資料後可以藉由甘特圖表示出專案的進行狀況、任務間 的前後順序和工期等資訊，方便專案管理者觀看。此外，利用 PACT 圖的概 念，提供專案管理者圖形化的輸出，使管理者可藉由圖形觀察專案的進行狀 況。在人力資源部分，藉由甘特圖來顯示人力負荷。

3.2.3 需求架構及流程圖

進行完需求確認以及系統目標訂定之後，開始進行建立系統架構的工作，系 統架構圖如圖 3.1 所示。 系統主要分為三個部分：專案規劃、人力資源規劃和專案警訊，其主要功能如下： 1. 專案規劃 A. 新增/修改/刪除專案資料：輸入專案及任務的相關資料，必要時加以修改 或刪除。在此需要輸入的資料包括：專案基本資料、專案規格資料、任 務相關資料和測試階段等資料。 B. 查詢專案資料或圖表：查詢專案詳細資料、專案甘特圖概況 C. 客戶需求資料管理。 2. 人力資源規劃 A. 設定人員資料：設定人員的名稱和所屬部門。 B. 指派任務：為專案的任務指派負責人員。 C. 查詢人力負荷狀況：以甘特圖表示負責人目前的任務負荷。 3. 專案警訊 A. 專案資料更新：更新專案實際成本，並確認任務的進度狀況。 B. 設定專案/任務的警訊判斷準則：為專案和任務設定需要的準則，並設定 準則的容忍度。 C. 異常處理機制：系統藉由警訊準則對專案實際和預計資料加以比對，若 違反準則並超過容忍度則產生警訊表單。 D. 填寫/查詢專案警訊：專案主管在警訊表單產生後在專案會議後加以填 寫，評估警訊的可能發生原因。提供電子郵件通知功能，將警訊訊息以

電子郵件發送給相關負責人，以利相關負責人進行處理。

此專案管理系統的基本流程以基本結構流程圖(圖 3.2)表示，流程內容提供

了系統基本的動態行為和流程，並包括上述的專案規劃、人力資源規劃和專案警

訊三個部分。

3.3 需求塑模

在完成需求分析之後，得到了系統的基本需求便可以開始進行系統的需求塑 模，本小節主要是描述使用者與需求分析階段的巨觀需求，包括兩個部分：使用 者個案圖以及活動圖。由於系統架構主要分專案規劃、人力資源規劃和專案警訊 三個部分，因此在規劃時將個別建立專案規劃、人力資源規劃和專案警訊的相關 圖表。使用者個案描述是從使用者觀點，描述使用者欲達成某目標的作業行為。

3.3.1 建構使用者個案圖

根據需求分析的描述並且依照 A 公司的需求，使用者個案圖中的行為者有 專案主管，而使用者個案主要有新增/修改/刪除專案資料與查詢專案資料或圖 表。其中專案主管(專案管理者)和所有的使用者個案皆有關連。專案規劃使用者 個案圖如圖 3.3 所示： 輸入專案基本資料 輸入任務基本資料 輸入測試階段資料 輸入規格資料(SPEC) 新增專案資料 修改專案資料 刪除專案資料 專案主管 _{查詢專案資料或圖表} 客戶需求 圖 3.3 專案規劃使用者個案圖 人力資源規劃部分的使用者個案圖如圖 3.4 所示，行為者為專案主管，使用

其中異常處理使用者個案在某些情況下會需要修改專案資料，此使用者個案 屬於專案規劃部分。 在專案警訊部分的行為者有專案主管與任務負責人，所牽涉的使用者個案較 多，包括：專案資料更新、設定專案/任務警訊判斷準則、異常處理、填寫/查詢 專案警訊列表和專案圖表查詢。其中任務負責人僅和異常處理和查詢專案警訊列 表有關連，不需要負責專案資料更新和設定專案/任務警訊判斷準則。 況，其中專案主管和所有使用者個案皆有關連。 設定人員資料與任務負荷 指派任務 圖 3.4 人力資源規劃使用者個案圖 專案主管 查詢人力負荷狀況 查詢人力資源分配狀況

設定容忍度 工作完成確認 修改專案資料 更新專案成本資料 任務負責人 異常控制 專案資料更新 設定任務警訊判斷準則 設定專案警訊判斷準則 填寫/查詢專案(任務)警訊列表 專案圖表查詢 專案主管 圖 3.5 專案警訊使用者個案圖

3.3.2 建構活動圖

在完成使用者個案圖的建構之後便可以開始進行活動圖的建構，依據使用者 個案圖裡面的使用者個案的性質，可以瞭解有哪些活動、轉換和執行程序等。 活動圖主要用於表達行為者、一個物件、一個使用者個案、許多使用者個案間或 一個系統在其生命週期中之循序或同步的操作（Operation）、作業流程（Workflow） 或行為，例如在其生命週期中的所有活動及其轉換關係。 專案規劃部分的活動圖如圖 3.6 所示，在專案規劃之初先由專案主管登入系 統，並且開始新增專案資料，或者對現有的專案資料加以修改，在新增專案時依 照一定的流程輸入專案規劃所需的相關資料，從專案基本資料到設定完預定的專 案成本，最後將資料加以儲存在資料庫。在使用圖表分析的功能時，圖表資料由 系統從資料庫擷取相關資料，經過處理後呈現給使用者觀看。 人力資源規劃部分的活動圖如圖 3.7 所示，首先由專案主管設定部門、人員 資料與人力負荷，接著進行任務指派，之後便可以進行查詢人力資源分配狀況和 人力負荷狀況。 專案警訊部分的活動圖如圖 3.8 所示，在專案警訊部分中，使用者可以進行 的活動主要有四種： 1. 資料更新：由專案主管進入資料更新頁面，接著選擇專案，此時可以選擇更 新專案成本資料或是進行任務完成確認。 2. 警訊準則設定：專案主管進入設定專案準則頁面，選擇為專案或是任務設定 準則，接著選擇準則，並且選擇此項準則的容忍度。 3. 觀看警訊列表：專案主管或是任務負責人皆可進行此活動，但任務負責人僅 能進行查詢動作，無法填寫異常處理表單。專案主管可發送藉由系統發送警 訊訊息給任務負責人，任務負責人可透過電子郵件內附之網路連結觀看警訊 表單。 專案圖表查詢：專案主管進入查詢頁面後，先選擇欲查詢之專案，接著選擇

欲查詢的種類，可選擇觀看 PACT 圖或是觀察專案甘特圖。 新增專案 修改/刪除專案 輸入規格資料 輸入任務時程等 相關資料 輸入專案基本資 料 修改或新增專案 選擇專案 選擇專案 使用者登入 資料儲存 1.專案基本資料 2.任務基本資料 3.專案甘特圖 圖表資料 設定子任務 設定前置任務 設定預定專案成 本 圖 3.6 專案規劃活動圖

設定部門人員資料 與人力負荷 選擇任務 選擇專案 否 為任務指派負責 人員 是否繼續指派 1.人力資源分配結果 2.人員目前負荷狀況 圖表分析 資料儲存 人員超出負荷 是否強制指派 是 否 是 否 圖 3.7 人力資源規劃活動圖 是 是否設定完畢

查詢警訊列 表 進入設定警 訊準則頁面 選擇專案 設定專案或任 務的警訊準則 選擇警訊準 則 選擇功能 使用者登入 選擇任務 設定容忍度 是 否 是否繼續 設定 進入專案圖 表查詢頁面 專案主管觀看 警訊表單內容 填寫警訊原因與現 象說明 任務完成確 認 進入資料更新 頁面 更新成本資 料 選擇專案 發送警訊電子郵 件給對策負責人 是 是否繼續 觀看列表 否 是 是否有新 的警訊 否 是否更新其他 專案資料 選擇專案 觀看PACT圖 是否觀看其 他專案圖表 觀看專案甘 特圖 是 否 否 圖 3.8 專案警訊活動圖

3.4 物件資料結構塑模

需求塑模的後續工作便是物件資料結構塑模，物件資料結構塑模主要以類別 圖表達系統之物件靜態的資料結構。類別圖主要是用來描述系統中物件的類型、 類型間以及與子類型間之靜態關係，此外，類別圖還需表示類別的內部屬性、操 作及物件連結所應遵守的限制。 TaskFrontRelation ID : Integer 任務ID : Integer 前置任務 : Integer Project Cost 成本記錄ID : Integer 日期 : Date 專案ID : String 研發用材料 : Currency 研發用材料_實際 : Currency Test_Board : Currency Test_Board_實際 : Currency PCB : Currency PCB_實際 : Currency SMT : Currency SMT_實際 : Currency 產品認證 : Currency 產品認證_實際 : Currency 外包 : Currency 外包_實際 : Currency 模具 : Currency 模具_實際 : Currency Mask : Currency Mask_實際 : Currency Fab_Process : Currency FabProcess_實際 : Currency 其他費用 : Currency 其他費用_實際 : Currency 其他費用註解 : Text 預計總成本 : Currency 實際總成本 : Currency 累計總成本 : Currency 累計總成本_實際 : Currency Create() Modify() Delete() Display() Get() SPEC SPEC_ID : Integer Proj_ID : String SPEC : Text Create() Modify() Delete() Status Status_ID : Integer 專案ID : String EVT預計開始日期 : Date EVT預計完成日期 : Date EVT_EVB : Integer EVT_Sample : Integer DVT預計開始日期 : Date DVT預計完成日期 : Date DVT_EVB : Integer DVT_Sample : Integer MVT預計開始日期 : Date MVT預計完成日期 : Date MVT_Qty : Integer Create() Modify() Get() CustRequest ID : Integer 專案ID : Integer 客戶ID : Integer EVB數量_客戶 : Integer EVB日期_客戶 : Date EVB備註_客戶 : String Module數量_客戶 : Integer Module日期_客戶 : Date Module備註_客戶 : String EVB數量_達交 : Integer EVB日期_達交 : Date EVB備註_達交 : String Module數量_達交 : Integer Module日期_達交 : Date Module備註_達交 : String Create() Modify() Delete() Customer 客戶ID : Integer 客戶名稱 : String Create() Modify() Delete() * 1 * 1 Project 專案ID : String 專案名稱 : String 專案計畫主持人ID : Integer 專案主管ID : Integer 專案描述 : String 專案Status : String 專案預計開始日期 : Date 專案預計完成日期 : Date 專案實際開始日期 : Date 專案實際完成日期 : Date Create() Modify() Delete() Display() Get() 1 * 1 * 1 1 1 1 1 * 1 * * * * * StatusContent ID : Integer Status : String Status描述 : string Create() Modify() Delete() 1 1 Task 任務ID : Integer 任務名稱 : String 任務負責人ID : String 任務所屬專案ID : String 任務Status : String 前置任務ID : Integer 任務預計開始時間 : Date 任務預計結束時間 : Date 任務實際開始時間 : Date 任務實際結束時間 : Date 母任務ID : Integer Create() Modify() Delete() Display() Get() 1 * 1 * 1 * 1 * 1 * 1 * ₁ 1 1 1 1 1 圖 3.9 專案規劃類別圖

圖 3.10 為人力資源規劃部分的類別圖，包括專案（Project）、任務（Task）、

部門（Department）、主管（Manager）、員工（Worker）和專案主管（PM）類別。 圖 3.9 為專案規劃部分的類別圖，包括專案（Project）、專案成本（Project Cost）、任務（Task）、任務前置關係(TaskFrontRelation)、專案規格（SPEC）、專 案測試階段（Status）、測試階段資料(StatusContent)、客戶需求（CustRequest） 和客戶（Customer）類別。 Manager ID : Integer 中文姓名 : String 英文姓名 : String 電子郵件 : String 分機 : String 部門ID : Integer PM ID : Integer 中文姓名 : String 英文姓名 : String 電子郵件 : String 分機 : String Department 部門ID : Integer 部門名稱 : String 1 * 1 * Project_ 專案ID : String 專案名稱 : String 專案計畫主持人ID : Integer 專案主管ID : Integer 專案描述 : String 專案Status : String 專案預計開始日期 : Date 專案預計完成日期 : Date 專案實際開始日期 : Date 專案實際完成日期 : Date Create() Modify() Delete() Display() Get() 1 * 1 * * 1 * 1 Worker ID : Integer 中文姓名 : String 英文姓名 : String 電子郵件 : String 分機 : String 部門ID : Integer 任務負荷 : Integer Create() Modify() Delete() Display() Get() * 1 * 1 圖 3.10 人力資源規劃類別圖 Task_ 任務ID : Integer 任務名稱 : String 任務負責人ID : String 任務所屬專案ID : String 任務Status : String 前置任務ID : Integer 任務預計開始時間 : Date 任務預計結束時間 : Date 任務實際開始時間 : Date 任務實際結束時間 : Date 母任務ID : Integer Create() Modify() Delete() Display() Get() * 1 * 1 1 * 1 *

Tas kCriteria ID : Integer 名稱 : String 描述 : String Create() Modify() Delete() Dis play()

Tas kAlarm Form _RelativeAct ID : Integer 表單ID : Integer 告知相關人員 : String 告知相關人員時間 : Date Create() Delete() Dis play() Tas kAlarm Form _Em ailAct

ID : Integer 表單ID : Integer 接受Em ail人員 : String 接受Em ail時間 : Date Create()

Delete()

Dis play() _{ID : Integer}Tas kAlarm Form _OtherAct 表單ID : Integer 其他行動 : String 其他行動時間 : Date Create() Delete() Dis play() Tas k Alarm Form Rec

ID : Integer 任務時程記錄ID : Integer 警訊產生時間 : Date 專案ID : String 任務ID : Integer 準則ID : Integer 異常描述 : String 警訊狀態 : String 現象說明 : String 原因探討 : String 警訊類型 : String Modify() Delete() Dis play() Tas k Alarm Form Rec_As ign

ID : Integer 任務時程記錄ID : Integer 警訊產生時間 : Date 專案ID : String 任務ID : Integer 準則ID : Integer 異常描述 : String 警訊狀態 : String 現象說明 : String 原因探討 : String 警訊類型 : String Modify() Delete() Dis play() ProjCriteria ID : Integer 名稱 : String 描述 : String Create() Modify() Delete() Dis play() Tas kCriteriaSetting ID : Integer 準則ID : Integer 任務ID : Integer 容忍度 : Integer Create() Modify() Delete() Dis play() 1 1 1 1

Tas k Alarm Form ID : Integer 警訊產生時間 : Date 專案ID : String 任務ID : Integer 準則ID : Integer 異常描述 : String 警訊狀態 : String 現象說明 : String 原因探討 : String 警訊類型 : String Modify() Delete() Dis play() * 1 * 1 1 * 1 * * 1 * 1 Tas kScheRec ID : Integer 任務ID : Integer 任務負責人ID : Integer 任務預計開始時間 : Date 任務預計結束時間 : Date 任務實際開始時間 : Date 任務實際結束時間 : Date 更改次序 : Integer 更改時間 : Date 更改原因 : String Delete() Dis play() * 1 * 1 Tas kAs ignRec

ID : Integer 任務ID : Integer 任務負責人ID : Integer 任務預計開始時間 : Date 任務預計結束時間 : Date 任務實際開始時間 : Date 任務實際結束時間 : Date 更改次序 : Integer 更改時間 : Date 更改原因 : String Delete() Dis play() 1 * 1 * ProjCriteriaSettings ID : Integer 準則ID : Integer 專案ID : String 容忍度 : Integer Create() Modify() Delete() Dis play() 1 1 1 1 Tas k 任務ID : Integer 任務名稱 : String 任務負責人ID : String 任務所屬專案ID : String 任務Status : String 前置任務ID : Integer 任務預計開始時間 : Date 任務預計結束時間 : Date 任務實際開始時間 : Date 任務實際結束時間 : Date 母任務ID : Integer Create() Modify() Delete() Dis play() * 1 * 1 * 1 * 1 1 * 1 * 1 * 1 * Project 專案ID : String 專案名稱 : String 專案計畫主持人ID : Integer 專案主管ID : Integer 專案描述 : String 專案Status : String 專案預計開始日期 : Date 專案預計完成日期 : Date 專案實際開始日期 : Date 專案實際完成日期 : Date Create() Modify() Delete() Dis play() * 1 * 1 1 * 1 *

ProjAlarm Form _OtherAct ID : Integer 表單ID : Integer 其他行動 : String 其他行動時間 : Date Create() Delete() Dis play() ProjAlarm Form _Em ailAct

ID : Integer 表單ID : Integer 接受Em ail人員 : String 接受Em ail時間 : Date Create() Delete() Dis play() ProjAlarm Form ID : Integer 警訊產生時間 : Date 成本警訊月份 : Date 專案ID : String 準則ID : Integer 異常描述 : String 警訊狀態 : String 現象說明 : String 原因探討 : String 警訊類型 : String Modify() Delete() Dis play() 1 * 1 * 1 * 1 * 1 * 1 *

ProjAlarm Form _RelativeAct ID : Integer 表單ID : Integer 告知相關人員 : String 告知相關人員時間 : Date Create() Delete() Dis play() 1 * 1 * 圖 3.11 專案警訊類別圖

圖 3.11 為專案警訊部分的類別圖，包括專案(Project）、任務(Task）、專案準 則(ProjCriteria)、任務準則(TaskCriteria)、專案準則設定(ProjCriteriaSettings)、任 務準則設定(TaskCriteriaSettings)、專案警訊異常表單(ProjAlarmForm)、任務警訊 異常表單(TaskAlarmForm)、專案警訊後續行動-電子郵件發送 (ProjAlarmForm_EmailAct)、專案警訊後續行動-相關行動 (ProjAlarmForm_RelariveAct)、專案警訊後續行動-其他行動 (ProjAlarmForm_OtherAct)、任務警訊後續行動-電子郵件發送 (TaskAlarmForm_EmailAct)、任務警訊後續行動-相關行動 (TaskAlarmForm_RelariveAct)、任務警訊後續行動-其他行動 (TaskAlarmForm_OtherAct)、任務時程更改記錄(TaskScheRec)、任務負責人更改 記錄(TaskAsignRec)、任務時程更改歷史警訊記錄(TaskAlarmFormRec)與任務負 責人更改歷史警訊記錄(TaskAlarmFormRec_Asign)。

3.5 物件互動行為塑模

在物件導向系統發展過程中，完成需求塑模後便可以繼續進行物件資料結構 塑模和物件互動行為塑模活動，物件資料結構塑模主要以類別圖來表達物件間的 靜態資料結構；而物件互動行為塑模主要以互動圖來表達物件之間動態之互動行 為。互動圖包含循序圖和合作圖，其中循序圖著重以時間的先後順序來描述物件 之間的訊息傳遞情況；而合作圖是著重物件之間的連結結構。但基本上循序圖和 活動圖所表達的內容是類似的，因此在此僅描述系統的循序圖。此外，本系統的 專案主管參與全部的活動，任務負責人僅參與部分活動，因此本小節的循序圖的 行為者皆以專案主管表示。

3.5.1 專案規劃之物件互動行為塑模

在專案規劃部分中包含了數項物件之間的互動行為，包括新增/修改/刪除專 案資料、查詢專案資料或圖表等行為，如圖 3.12 和圖 3.13 所示。 圖 3.12 為專案規劃循序圖（新增/修改/刪除專案資料），由於新增/修改/刪除 不同資料的行為皆相同，因此圖 3.12 僅顯示新增/修改/刪除專案（Project）類別 的資料的部分。使用者藉由使用者介面顯示資料的細部項目，並且進行新增、修 改和刪除的動作。

: 專案主管 使用者介面 專案 : Project 規格 : SPEC 任務 : Task 測試階段 : Status 專案成本 : Project Cost 前置任務 : TaskFrontRelation 修改專案資料 Display( ) 專案資料 Modify( ) 刪除專案資料 _{Display( )} 專案資料 Delete( ) 新增專案資料 Create( ) 圖 3.12 專案規劃循序圖（新增/修改/刪除專案資料）

圖 3.13 為專案規劃循序圖（查詢專案資料或圖表），圖中的控制類別負責接 收來自專案主管傳至使用者介面的命令，並將命令傳送給實體類別（例如，專案 類別）執行。專案主管藉由使用者介面向查詢專案資料或圖表控制類別發出查詢 的命令，再藉由此控制類別向專案、任務、專案測試階段類別擷取專案名稱、任 務名稱、子任務名成、專案預計開始和完成日期、負責人和專案測試階段等資料， 最後由控制類別回傳資料到使用者介面提供專案主管觀看。 查詢專案資料或圖表控制 類別 : 專案主管 使用者介面 專案 : Project 任務 : Task 專案測試階 段 : Status 規格 : SPEC 專案成本 : Project Cost 前置任務 : TaskFrontRelation 查詢專案資料或圖表 查詢 Get( ) 專案資料 Get( ) 任務資料 Get( ) 測試階段資料 需求資料 Get() 規格資料 Get() 專案成本資料 Get() 前置任務資料 圖 3.13 專案規劃循序圖（查詢專案資料或圖表）

3.5.2 人力資源規劃之物件互動行為塑模

在人力資源規劃部分所包括的互動行為有：設定人員資料、指派任務、查詢 人力負荷狀況和查詢人力資源分配狀況。 圖 3.14 為人力資源規劃循序圖（設定員工、主管、部門與專案主管資料）， 由於設定不同資料的行為皆相同，因此圖 3.14 僅顯示設定員工（Worker）類別 的資料的部分，專案主管透過使用者介面進行新增、修改和刪除員工資料的動 作，並且藉由使用者介面發出顯示資料明細的命令，再由員工資料類別回傳至使 用者介面。 : 專案主管 使用者介面 員工資料 : Worker 主管資料 : Manager 部門資料 : Department 專案主管資料 : PM 新增人員資料 Create( ) 修改人員資料 _{Display( )} 人員資料 刪除人員資料 _{Display( )} 人員資料 Modify( ) Delete( ) 圖 3.14 人力資源規劃循序圖（設定人員資料） 圖 3.15 為人力資源規劃循序圖（指派任務），專案主管藉由使用者介面向控 制類別發出指派的命令，控制類別向相關類別擷取任務 ID 和人員 ID 等資料，接 著新增指派資料並將指派資料回傳至任務資料類別。

: 專案主管 使用者介面 任務資料 : Task 員工資料 : Worker 指派任務控 制類別 指派任務 Get( ) 任務ID Get( ) 人員ID 人員負荷上限 圖 3.15 人力資源規劃循序圖（指派任務） 圖 3.16 人力資源規劃循序圖（查詢人力資源分配狀況），藉由控制類別向員 工資料和任務資料類別擷取員工資料和任務資料，最後由控制類別將這些資料傳 至使用者介面。 圖 3.17 為人力資源規劃循序圖（查詢人力負荷狀況），藉由控制類別向員工 資料類別選取欲查詢的人員資料，並且向任務類別擷取相關的任務資料，將這些 資料收集後，以人力負荷甘特圖的形式傳送至使用者介面。

: 專案主管 使用者介面 查詢人力資源分配 狀況控制類別 員工資料 : Worker 任務資料 : Task 查詢人力資源分配狀況 Get( ) 人員資料 分配資料 Get( ) 負責人員ID 圖 3.16 人力資源規劃循序圖（查詢人力資源分配狀況） : 專案主管 使用者介面 查詢人力分配狀 況控制類別 員工資料 : Worker 任務資料 : Task 查詢分配狀況 Get( ) 任務資料 Get( ) 選擇的人員資料 產生人力負荷甘特圖 圖 3.17 人力資源規劃循序圖（查詢人力負荷狀況）

圖 3.18 為專案警訊循序圖（專案資料更新），此循序圖的行為主要有兩項： （1）專案成本資料更新：藉由控制類別向專案資料擷取欲更新的專案 ID，將此 資料回傳給控制類別，新增或修改專案成本資料，將結果回傳至使用者介面。（2） 任務開始/完成確認：藉由控制類別向專案資料擷取欲確認的任務所屬的專案 ID，將此資料回傳給控制類別，向任務資料類別擷取欲確認的任務 ID，將此資 料回傳給控制類別，之後對任務資料修改以進行確認，將結果回傳至使用者介面。 在專案警訊部分所包括的互動行為有：專案資料更新、設定專案/任務判斷 準則、異常控制、查詢專案警訊表單與專案圖表查詢等五項。

3.5.3 專案警訊之物件互動行為塑模

: 專案主管 使用者介面 專案資料 : Project 專案成本 : Project Cost 任務資料 : Task 專案資料更新控 制類別 專案成本資料更新 任務完成確認 Get( ) 專案資料 Create( ) or Modify( ) 專案成本資料 Get( ) Get( ) 任務資料 Modify( ) 圖 3.18 專案警訊循序圖（專案資料更新） 專案資料 顯示確認完成

設定判斷準則控 制類別 : 專案主管 使用者介面 專案資料 : Projects 專案警訊判斷準則 : ProjCriteria 專案準則設定 : ProjCriteriaSettings 任務資料 : Tasks 任務警訊判斷準則 : TaskCriteria 任務準則設定 : TaskCriteriaSetting 設定專案警訊判斷準則 Get( ) 專案資料 Get( ) 設定任務警訊判斷準則 Get( ) 任務資料 Get( ) 專案準則資料 Create( ) or Modify( ) 任務準則資料 Create( ) or Modify( ) 圖 3.19 專案警訊循序圖（設定專案/任務判斷準則）

圖 3.19 為專案警訊循序圖（設定專案/任務判斷準則），主要有兩種行為，（1） 設定專案警訊判斷準則：藉由控制類別向專案資料類別擷取欲設定的專案 ID， 再向專案警訊準則類別擷取欲設定的專案準則 ID，新增或修改專案準則設定。 （2）設定任務警訊判斷準則：行為模式和設定專案警訊準則類似。 圖 3.20 為專案警訊循序圖（異常控制），主要有兩種行為：（1）專案異常控 制：由控制類別將專案異常控制的指令傳送至專案警訊準則類別，專案警訊準則 類別對資料進行異常判斷後將結果傳至控制類別，若有必要，控制類別會進行產 生警訊表單的動作。（2）任務異常控制：行為模式和專案異常控制類似。

異常處理控 制類別 專案警訊準則 : ProjCriteria 專案成本資料 : Project Cost 專案警訊表單 : ProjAlarmForm 任務警訊準則 : TaskCriteria 任務資料 : Task 任務警訊表單 : Task Alarm Form

Check_Cost( ) 產生警訊表單 專案異常控制 Check_Progress( ) 任務異常控制 產生警訊表單 Get( ) 專案成本資料 Get( ) 任務時程資料 Update( ) Update( ) 圖 3.20 專案警訊循序圖（異常控制）

圖 3.21 為專案警訊循序圖（查詢/填寫專案(任務)警訊表單），填寫/查詢任務 警訊表單的處理方式與專案警訊表單相同，在此不加累述。控制類別發出顯示細 部內容的命令給專案警訊列表類別，再由專案警訊列表類別回傳專案警訊資料給 使用者介面，專案主管藉由使用者介面觀看警訊列表資料後，將填寫的資料藉由 控制類別寫入並且儲存在專案警訊列表類別中，傳送郵件的命令由控制類別發 出，系統發送警訊郵件給相關負責人。 圖 3.22 為專案警訊循序圖（專案圖表查詢），主要的行為有兩種，（1）PACT 圖查詢：經由控制類別向專案資料類別擷取專案 ID 資料並回傳給控制類別，接 著控制類別向專案成本類別擷取專案成本資料和日期等資料並回傳給控制類 別，之後再向任務類別擷取任務完成資料和日期等資料並回傳給控制類別，控制 類別蒐集資料完畢後，由控制類別將資料傳送至使用者介面並且產生相對應的 PACT 圖。（2）專案甘特圖查詢：藉由控制類別向專案資料類別擷取欲查詢之專 案 ID 資料並回傳給控制類別，接著向任務資料類別發出擷取任務資料的命令並 回傳給控制類別，控制類別蒐集資料完畢後進行資料處理，將結果回傳至使用者 介面。 : 專案主管 使用者介面 專案警訊列表 : ProjAlarmForm 填寫/查詢專案警 訊列表控制類別 查詢/填寫專案警訊表單 Display( ) 專案警訊列表 Modify( ) MailTo( ) 圖 3.21 專案警訊循序圖（填寫/查詢專案(任務)警訊表單）

: 專案主管 使用者介面 專案圖表查 詢控制類別 專案資料 : Projects 專案成本 : Project Cost 任務資料 : Tasks PACT圖查詢 Get( ) 專案資料 Get( ) 專案成本資料 Get( ) 任務進度資料 PACT圖 專案甘特圖查詢 Get( ) 任務資料 甘特圖 Get( ) 專案資料 圖 3.22 專案警訊循序圖（專案圖表查詢）

第四章 系統環境與內容說明

本章節的內容主要說明新產品研發專案警訊系統的環境和實作結果，並且描 述系統的介面與細部功能，以供使用者瞭解系統詳細的功能及操作方式，最後將 針對系統的成效做探討。

4.1 系統實作

本章依據第三章的系統模式概念建構新產品研發專案警訊系統，將本系統利 用相關資訊技術建構完成，並將完成的系統提供給個案公司進行測試，以確保系 統符合個案公司的需求，確認系統有無缺失或漏洞並加以改善。

4.2 系統環境

本系統建構的環境如下所示： 1. 作業系統：Microsoft Windows 2. 網路伺服器：Microsoft IIS 網路伺服器 3. 資料庫系統：Microsoft SQL Server 2000 系統建構的模式採用三層式架構，以下為三層式架構示意圖： 圖 4.1 三層式架構示意圖

4.3 相關軟體

本系統使用的相關軟體如下所示： 1. 互動式網頁撰寫程式：ASP.NET

程，為現今市面上功能較齊全的軟體塑模 CASE 工具。

4.4 系統介面與操作說明

本新產品研發專案警訊系統的主要功能為專案警訊功能，除此之外仍包括了 專案管理系統所必需的基本功能，系統的功能主要可分為三大類：專案規劃功 能、人力資源規劃功能與專案警訊功能。

4.4.1 使用者權限

系統之使用者為專案管理者(專案主管)與任務負責人。專案管理者為系統之 主要使用者，因此擁有使用系統所有功能之權限，包括專案規劃功能、人力資源 管理與專案警訊功能。任務負責人為系統之次要使用者，僅有在接收到電子郵件 警訊通知時，透過信件內容之網路連結瀏覽警訊表單的權限(相關內容請參考章 節 4.4.4.2)。

4.4.2 專案規劃功能

專案管理員在進行控管專案之前必須輸入專案相關資料，藉由資料庫將這些 資料儲存，日後系統藉由這些資料來控管專案，提供專案管理者專案的進行狀況 或查詢相關資訊。專案規劃功能可分為：建立新專案、專案資料維護、專案成本 維護與專案歷史資料紀錄等四項子功能，如圖 4.2 所示。 圖 4.2 專案規劃功能畫面

4.4.2.1 建立新專案

系統在使用之初並不會存在任何專案相關資料，因此在使用系統之前需要由 使用者輸入專案的相關資料，本系統的專案相關資料大致上分為六項，如圖 4.3 左方功能表所示： 圖 4.3 建立新專案畫面 1. 輸入專案基本資料 在專案基本資料的輸入頁面，使用者必須輸入專案代號、專案名稱、專 案主管、專案計畫主持人、專案描述、專案預計開始日期與專案預計完成日 期等資料，如圖 4.4 所示。 圖 4.4 輸入專案基本資料畫面