元培科大計畫活動管理系統開發

元培科技大學

資訊管理系畢業專題

元 培 科 大 計 畫 活 動 管 理 系 統 開 發

組別:A18

指導老師: 劉雯瑜老師

組 員: 劉得彥(0981408063)

彭莉鈞(0981408078)

李俊慶(0981408080)

陳偉皓(0981408081)

張育勛(0981408084)

摘 要

目前計畫活動管理證照普及率越來越高，根據美國專案管理學會所提供的數 據，在 2005 年 12 月 31 日時，全台灣只有 499 位有 PMP 證照，直到 2006 年 12 月 31 日時，有 PMP 證照暴增到 2104 人，可見對企業的重要性(周龍鴻,2007)。 目前我們學校沒有導入活動計劃管理系統，因此所做的計畫案會有點不完 整，為了改善學校內各專案的完整性，所以本組打算建置一套專案管理系統，來 幫助學校解決專案管理的問題，以提升學校辦事效率及確實管控各專案。 其製作的主要方向為:做出整個專案流程系統，以提供學校有規律性的專案 開發，而不再像以前一樣，每個專案都沒按時完成，導致沒辦法執行，造成學校 做事效率減半，進而影響大多數人的權益，所以我們建置這套系統，來監督學校 專案，這樣就能按時繳交以及達成專案的正確性，來服務更多的學生以及老師。 關鍵字：專案管理、專案管理系統。

目 錄

摘 要………i 目 錄………ii 表目錄………iii 圖目錄………iv 第一章 緒論………1 1.1 背景與動機………..………1 1.2 目的………..………1 1.3 限制………..………1 1.4 關鍵名詞定義………..………2 第二章 文獻探討………..3 2 . 1 何 謂 專 案 管 理 … … … 3 2.1.1 專案管理控制項目 ………..………..4 2.1.2 專案管理成功評價……….5 2.1.3 專案管理流程圖……….6 第三章 專題設計與規劃……….7 3.1 系統開發方法………7 3.2 需求分析………8 3.3 系統藍圖描述………11 3.4 專題設備………13 3.5 專題時程規劃………..…..14 3.6 專題分工………..…..15 第四章 專題成果………16 4.1 系統分析報告書……….…16 4.2 系統循序圖……….34 4.3 系統成果簡介……….35 第五章 結論與建議………..40 參考文獻………..41 附 錄………42

表目錄

圖目錄

圖 2.1 專案管理流程圖……….…….…6 圖 3.1 開發方法模型圖……….…7 圖 3.3.1 Use Case 圖……….…..…11 圖 3.4 系統架構圖………..……12 圖 3.5 硬體架構圖………..…13 圖 3.6 甘特圖………..…..……..14 圖 4.2.1 循序圖……….34 圖 4.3.1 最初首頁圖……….35 圖 4.3.2 最終首頁圖……….35 圖 4.3.3 首頁圖……….36 圖 4.3.4 建立專案預算圖……….36 圖 4.3.5 建立專案圖……….37 圖 4.3.6 查詢專案圖……….37 圖 4.3.7 上傳檔案圖……….38 圖 4.3.8 修改經費慨算圖……….38 圖 4.3.9 刪除專案圖……….39

第一章 緒論

本章節共包含 4 小節，第一節介紹背景與動機;第二節介紹目的;第三節介紹 限制;第四節介紹關鍵名詞定義。

1.1 背景與動機

目前專案管理證照普及率越來越高，根據美國專案管理學會所提供的數據， 在 2005 年 12 月 31 日時，全台灣只有 499 位有 PMP 證照，直到 2006 年 12 月 31 日時，有 PMP 證照暴增到 2104 人，可見專案管理對企業的重要性(周龍鴻，2007)。 目前專案管理系統越來越多企業導入或自行開發，本來從早期的 IBM、HP， 到現在的台積電、中鋼等等相關企業，都使用了這套軟體，未來一定會越來越多 公司來做跟進的。 目前我們學校沒有導入專案管理系統，因此所做的計畫案容易發生專案進度 追蹤不易、經費支用狀況不明、專案未準時完工等缺點，為了改善學校內各專案 的完整性，所以本組打算建置一套專案管理系統，來幫助學校解決專案管理的問 題，以提升學校辦事效率及確實管控各專案。 另一方面，也因為本組組員發現本身的程式開發技能還不夠堅實，程式語言 的自學能力也還不足，因此，挑選此一具有挑戰性的專題題目，希望能夠透過專 題製作的過程，把過去三年在程式語言、資料庫、系統分析與設計等課程裡所學 的技能重新做複習並整合運用出來，並練習自己學習 JSP 軟體，以強化組員們的 資訊實力，提升就業力。

1.2 目的

1. 釐清學校計畫專案的管理流程。 2. 開發計畫案的專案管理系統。 3. 協助計畫管理者做好專案管理工作。 4. 訓練好本組組員的程式開發技能。

1.3 限制

本專案開發完後，在使用系統的過程中，有下列限制: 1.作業系統要 Windows 或 FreeBSD、Linux、MacOSX 。 2.資料庫要 Access。 3.程式要 JavaScript 。

1.4 關鍵名詞定義

本專題計用到下列幾個重要的名詞，茲分別定義如下: 1. 專案管理:專案管理是指那些專案管理團隊所負責的工作，而非那些在工作分 包中負責技術產出之小組成員的工作(賴志宏,2011)。 2. 專案管理系統:提供務實的管理方法與工具，完善的專案運作活化組織，增進 管理效率(劉昱村,2008)。

第二章 文獻探討

2.1 何謂專案管理

1. 『專案』根據美國專案管理學會(PMI)的定義：「是指一項暫時性的任務、 配置，以開創某獨特性的產品或服務。」 2. 『專案管理』根據美國專案管理學會(PMI)的定義：「應用知識、技能、工具與 技術來規劃活動，以達成專案的需求。」 3. 專案管理是藝術也是科學。藝術構面與人際構面有緊密結合也就是領導眾人 的事務，科學構面包括對流程工具與技巧的掌握。 每一個專案都有其執行的時間而在這個時間內專案有其生命週期約略分為： 1. 起始階段：定義出專案的需求，並釐清與描述對此需求的適當回應。 2. 規劃階段：盡可能的詳細發展專案的解決之道。 3. 執行階段：持續監控進度，同時在實際狀況與原訂計畫有所出入時，適當地 進行調整與記錄。 4. 結案階段：驗證該專案是否滿足原本的需求。 組成專案進行管理必有其目的，希望透過組織內不同單位人員的臨時性編組來達 成「追求資源效率的極大化」，亦即： 1. 如期達成或縮短時程達成。 2. 在預算成本內或更少成本達成該專案或更少。 3. 產出物性能達到預期目標或比預期更高。 4. 產出物的品質達到預期目標或比預期目標更好。

2.1.1 專案管理控制項目

1.專案時程管理控制 為了掌控整個專案進度的執行狀況，讓專案如期的達成，並且依執行狀況適度調 整執行進度。 a. 甘特圖 b. Microsoft Project c. Gantt Project(免費軟體) d. Micro Outlook 裡的工作項目 e. 利用 EXECL 軟體記錄時程進度 管理時程掌控不佳造成進度的延遲外，若是有關商品的退出甚至會影響到企業的 營收，時程掌控非常重要的。 2.專案預算 專案的成立的起始階段即需編列該專案的預算，以預估此專案的花費成本，而其 實施原則有如下幾點： a.效率化原則。 b.質量管理原則。 c.彈性管理原則。 而其預算管理可採用如下之方式進行管控： a.月度別管理。

專案預算管理工具： a.專案預算管理報告表。 b.專案報告表。

2.1.2 專案管理成功評價：

1. 是否達成所設定的成本、時程與績效目標？ 2. 該專案的管理模式是否有效？ 3. 是否達成所想要的結果，同時讓顧客感到滿意？ 4. 組織是否有所收穫，並藉助經驗讓未來的專案做的更好？

第三章 專題規劃

本章包含六節，第一節介紹系統開發方法；第二節介紹需求分析；第三節進 行系統藍圖描述；第四節說明專題設備；第五節說明專題時程規劃；第六節進行 專題分工。

3.1 系統開發方法

本專題採用的系統開發方法是雛型，進行過程是先了解客戶的需求，依據需 求定義來進行快速設計，依據設計結果來快速建立雛形版本，然後將雛型的結果 交給客戶評估，並且收集客戶的意見與建議，再來依據客戶的意見與建議來更新 雛型，待顧客滿意後，才正式開發真正的系統，完成系統實作。 圖 3.1 開發方法模型圖

3.2 需求分析

專案管理系統 組別:A18 元培科技大學 版本:0.1 需求分析報告

壹. 功能需求(Functional Requirement)

1. 教資助理可以利用此系統建立專案。 2. 教資助理透過登入可以上傳核准簽呈和查詢自己建立的專案。 3. 主持人透過登入填寫專案預算所有內容和活動申請與預算表讓系統儲存你的 資料。 4. 主持人上傳專案計畫書和活動成果報告和核准後之活動核銷簽讓系統儲存你 所上傳的資料。 5. 主持人可以查詢你個人所控管的專案有無任何問題。

貳. 功能需求描述

 教資助理和主持人登入此系統  教資助理建立專案  教資助理上傳核准簽呈  教資助理查詢專案  主持人填寫專案預算的內容  主持人填寫活動申請與預算表  主持人上傳專案計畫  主持人上傳活動成果報告  主持人上傳核准後之活動核銷簽  主持人查詢個人控管的專案  系統發出活動即將到期通知  系統發出活動已過期尚未舉辦通知  系統發出預算支用未達預定比率通知

專案管理系統 組別:A18 元培科技大學 版本:0.1 需求分析報告

參. 整理事件表

事件 觸發器 來源 活動 回應 目的地 助理或主持人 登入系統 登入帳號密碼 助理或主持人 確認基本資料 系統首頁 助理或主持人 助理建立專案 建立專案 助理 產生建立專案 明細 建立成功或失 敗 主持人 助理查詢專案 查詢專案 助理 跑出查詢頁面 有無資料顯示 助理 助理上傳核准 簽呈 上傳 助理 跑出上傳頁面 有無上傳成功 助理 主持人填寫專 案預算 填寫專案預算 主持人 跑出專案預算 頁面 有無填寫成功 主持人 主持人填寫活 動申請與預算 表 填寫活動申請 與預算表 主持人 跑出填寫活動 申請與預算表 頁面 有無填寫成功 主持人 主持人上傳專 案計畫書 上傳專案計畫 書 主持人 跑出上傳專案 計畫書頁面 有無上傳成功 主持人 主持人上傳活 動成果報告 上傳活動成果 報告 主持人 跑出上傳活動 成果報告 有無上傳成功 主持人 主持人上傳核准 之活動核銷簽 上傳核准後之 活動核銷簽 主持人 跑出上傳核准後 之活動核銷簽 有無上傳成功 主持人 主持人查詢個 人管控專案 查詢個人管控 專案 主持人 跑出查詢個人 管控的資料 有無資料顯示 主持人

專案管理系統 組別:A18 元培科技大學 版本:0.1 需求分析報告

肆. 詞彙表(Glossary)

詞彙 解釋 附註 登入系統 帳號、密碼 簽呈 專案的資料 專案預算 專案使用金額 活動申請 舉辦活動時需要做申請資料的動作 預算表 填寫各種活動的預算金額 專案計畫書 這個專案的詳細內容 活動成果報告 舉辦活動成果的詳細記錄 核准活動核銷簽 核准這場活動的核銷簽

貳.非功能的需求(Non-functional Requirement)

一、Usability  此系統對於初學者和使用者在 20 分鐘以內學會使用及操作。  系統的設計手冊一定要有詳細的說明，並且使用者在 20 分鐘內看 懂以及會操作。  系統使用者必須對系統感到 8 成的滿意度。 二、Reliability  系統當機次數必須小於 2 次/每年。  系統資料備份必須大於 3 次/每月。  系統資料更新必須大於 10 次/每日。 三、Performance  系統登入時的驗證必須少於 5 秒內完成。  系統同時處理那麼多筆資料時，不能造成系統 70%以上嚴重負荷。

3.3 系統藍圖描述

本節介紹本專題之軟硬體結構，在軟體方面，分別以 Use Case 圖、系統架 構圖來表達;在硬體方面，則以硬體架構圖來表達。

1.Use Case 圖

2.系統架構圖

3.硬體架構圖 圖 3.5 硬體架構圖

3.4 專題設備

本專題開發所需使用之軟硬體有： (1) 軟體方面 1. Access 2. Windows 3. JavaScript 4. Java 程式語言 5. JSP 6. Apache Tomcat (2) 硬體方面: 1. 電腦主機一部

3.5 專題時程規劃

本專案由開始規劃至系統完成，預計會有下列幾項工作 (1) 需求定義與收集 (2) 設計 (3) 雛型建立與修改 (4) 評估 (5) 雛型更新 (6) 系統實作 茲將本專案進行流程的甘特圖繪製如下： 階段 一月 二月 三月 四月 五月 六月 七月 八月 九月 十月 十一月 需求定義 與收集    設計     雛型建立 與修改     評估    雛型更 新   系統實 作  圖 3.6 甘特圖

3.6 專題分工

本專案組員的分工如下表所示： 表 3-1 專案分工表 工作 彭莉鈞 陳偉皓 劉得彥 李俊慶 張育勛 1. 需求定義與收集   2. 設計   3. 雛型建立與修改   1. 評估   2. 雛型更新   3. 系統實作  

第四章 專題成果

本章共有兩小節，第一小節介紹本專題系統的系統分析報告書；第二小節進 行本專題系統成果的簡介。

4.1 系統分析報告書 4.1.1 Use Case 圖

專案管理系統 組別:A18

使用案例:建立專案 版本:0.1

編號:UC-001

4.1.2 使用案例描述

Use Case Specification:建立專案

1. 名稱(Name) 建立專案。 1.1 簡述(Brief Description) 建立專案的過程。 2. 參與者(Actors) 教資中心助理。 3. 前提(Pre-Conditions) 助理已經登入此系統。 4. 成功條件(Successful Post-Conditions) 建立專案成功。 5. 失敗條件(Unsuccessful Post-Conditions) 建立專案失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:客戶提交建立專案的訊息 2.系統接收並傳送給上級看 3.客戶去查看有沒有通過 4. TUCEW:系統送出訊息給客戶 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 助理提交新的建立專案訊息 步驟 1.如果助理提交新的建立專案訊息，那麼系統就會再傳一次給上級單位。 6.2.2 助理提交的專案沒有完整 步驟 1.助理傳到一半有可能斷線之類的。 6.2.3 系統傳給上級時，沒有完整 步驟 2.可能當時網路斷線等等之類的。 7. 詞彙表(Glossary) 詞彙 解釋 附註 專案資料 名稱、主持人、金額、編號、助理、起始日期

專案管理系統 組別:A18

使用案例:查詢專案 版本:0.1

編號:UC-002

Use Case Specification:查詢專案

1. 名稱(Name) 查詢專案。 1.1 簡述(Brief Description) 查詢整個專案的資料。 2. 參與者(Actors) 教資中心助理。 3. 前提(Pre-Conditions) 助理已登入此系統。 4. 成功條件(Successful Post-Conditions) 顯示資料。 5. 失敗條件(Unsuccessful Post-Conditions) 斷線或系統發生問題。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:助理按查詢鈕 2.系統顯示查詢頁面 3.助理輸入資料 3. TUCEW:系統去找資料並顯示在網頁上 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 助理查詢失敗 步驟 1.可能系統發生問題。 6.2.2 沒有顯示任何資料 步驟 2.可能資料庫沒存到或此專案未申請。

專案管理系統 組別:A18

使用案例:上傳核准簽呈 版本:0.1

編號:UC-003

Use Case Specification:上傳核准簽呈

1. 名稱(Name) 上傳核准簽呈。 1.1 簡述(Brief Description) 這個使用案例描述客戶上傳核准簽呈的過程。 2. 參與者(Actors) 教資中心助理。 3. 前提(Pre-Conditions) 簽呈已完成。 4. 成功條件(Successful Post-Conditions) 上傳核准簽呈成功。 5. 失敗條件(Unsuccessful Post-Conditions) 上傳核准簽呈失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:助理上傳核准簽呈 2.系統接收到並存放在一個空間裡 3.主持人可以去下載使用 4. TUCEW:系統把資料傳送給主持人 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 助理沒有上傳資料 步驟 1.可能助理選擇不上傳資料改天再來。 6.2.2 系統沒有接收到資料 步驟 2.可能上傳途中被中斷。 6.2.3 主持人下載資料不完整 步驟 3.可能下載途中資料有跑走之類的。 7. 詞彙表(Glossary) 詞彙 解釋 附註 核可簽呈 這項活動已核准可舉辦

專案管理系統 組別:A18

使用案例:登入 版本:0.1

編號:UC-004

Use Case Specification:登入

1. 名稱(Name) 登入。 1.1 簡述(Brief Description) 使用此系統必須先登入才能使用。 2. 參與者(Actors) 教資助理或主持人。 3. 前提(Pre-Conditions) 系統發帳號。 4. 成功條件(Successful Post-Conditions) 登入成功。 5. 失敗條件(Unsuccessful Post-Conditions) 登入失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:助理或主持人按了登入鈕 2.系統顯示請輸入帳號密碼 3.助理或主持人輸入帳號密碼 4.系統驗證帳號密碼正不正確 5. TUCEW:顯示登入成功或失敗 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 助理或主持人沒有按登入鈕 步驟 1.可能助理或主持人現在不想登入。 6.2.2 系統沒有跳出輸入帳號密碼的畫面 步驟 2.可能系統發生錯誤而沒有跳出畫面。 6.2.3 帳號密碼錯誤太多次而跳出畫面 步驟 3.你輸入帳號密碼錯誤太多次，而系統會自動跳出畫面。

專案管理系統 組別:A18

使用案例:註冊 版本:0.1

編號:UC-005

Use Case Specification:註冊

1. 名稱(Name) 註冊。 1.1 簡述(Brief Description) 描述使用者註冊的過程。 2. 參與者(Actors) 教資中心助理或主持人。 3. 前提(Pre-Conditions) 按建註冊的鈕。 4. 成功條件(Successful Post-Conditions) 註冊成功。 5. 失敗條件(Unsuccessful Post-Conditions) 註冊失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:助理或主持人按了註冊的鈕 2.系統跑出註冊頁面 3.客戶填寫基本資料 5. TUCEW:顯示註冊成功或失敗 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 助理或主持人沒有按註冊的鈕 步驟 1.可能助理或主持人現在不想註冊。 6.2.2 系統沒有跳出註冊的頁面 步驟 2.可能系統發生錯誤而沒有跳出畫面。 6.2.3 註冊失敗會跳出視窗 步驟 5.註冊失敗會跳到填資料的頁面，再叫你重填一次。 7. 詞彙表(Glossary) 詞彙 解釋 附註 註冊 姓名、性別、密碼、地址、e-maill

專案管理系統 組別:A18

使用案例:發出活動即將到期通知 版本:0.1

編號:UC-006

Use Case Specification:發出活動即將到期通知

1. 名稱(Name) 發出活動即將到期通知。 1.1 簡述(Brief Description) 這個使用案例描述活動即將到期通知的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 活動已經申請完畢。 4. 成功條件(Successful Post-Conditions) 活動通知成功。 5. 失敗條件(Unsuccessful Post-Conditions) 活動通知失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人活動申請完畢 2.系統會檢查活動的日期 3. TUCEW:日期即將到期系統會發出通知給 客戶 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人活動沒有申請成功 步驟 1.可能活動資料不完整或錯誤。 6.2.2 系統沒有去檢查日期 步驟 2.可能程式出現了問題。 6.2.3 系統沒有成功發送通知給主持人 步驟 3.可能在發送的途中被中斷了。

專案管理系統 組別:A18

使用案例:發出活動已過期尚未舉辦通知 版本:0.1

編號:UC-007

Use Case Specification:

發出活動已過期尚未舉辦通知

1. 名稱(Name) 發出活動已過期尚未舉辦通知。 1.1 簡述(Brief Description) 這個使用案例描述活動已過期尚未舉辦通知的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 活動已經申請完畢。 4. 成功條件(Successful Post-Conditions) 活動通知成功。 5. 失敗條件(Unsuccessful Post-Conditions) 活動通知失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人活動申請完畢 2.系統會檢查日期 3. TUCEW:日期超過卻還未舉辦活動，系統 會發出通知給客戶 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人活動沒有申請成功 步驟 1.可能活動資料不完整或錯誤。 6.2.2 系統沒有去檢查日期 步驟 2.可能程式出現了問題。 6.2.3 系統沒有成功發送通知給主持人 步驟 3.可能在發送的途中被中斷了。 7. 詞彙表(Glossary) 詞彙 解釋 附註 超過時間卻未舉辦通知 活動時間超過未舉辦，系統就會通知客戶

專案管理系統 組別:A18

使用案例:發出預算支用未達預定比率通知 版本:0.1

編號:UC-008

Use Case Specification:

發出預算支用未達預定比率通知

1. 名稱(Name) 發出預算支用未達預定比率通知。 1.1 簡述(Brief Description) 這個使用案例描述預算支用未達預定比率通知的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 活動已經申請完畢。 4. 成功條件(Successful Post-Conditions) 預算支用未達預定比率通知成功。 5. 失敗條件(Unsuccessful Post-Conditions) 預算支用未達預定比率通知失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人活動申請完畢 2.系統會檢查預算支用有沒有達到一定比率 3. TUCEW:預算支用未達到一定比率，系統 會發出通知給客戶 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人活動沒有申請成功 步驟 1.可能活動資料不完整或錯誤。 6.2.2 系統沒有去檢查預算 步驟 2.可能程式出現了問題。 6.2.3 系統沒有成功發送通知給主持人 步驟 3.可能在發送的途中被中斷了。

專案管理系統 組別:A18

使用案例:填寫專案預算 版本:0.1

編號:UC-009

Use Case Specification:

填寫專案預算

1. 名稱(Name) 填寫專案預算。 1.1 簡述(Brief Description) 這個使用案例描述填寫專案預算的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 要申請活動時。 4. 成功條件(Successful Post-Conditions) 填寫專案預算成功。 5. 失敗條件(Unsuccessful Post-Conditions) 填寫專案預算失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人填寫預算送出 2.系統把資料儲存在資料庫裡 3. TUCEW:系統會顯示存儲成功或失敗 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有把預算送出 步驟 1.可能中途按離開而沒有送出。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統顯示填寫失敗 步驟 3.填寫失敗，系統提示失敗訊息。 7. 詞彙表(Glossary) 詞彙 解釋 附註 專案預算 這專案可以使用多少錢

專案管理系統 組別:A18

使用案例:填寫活動申請與預算表 版本:0.1

編號:UC-010

Use Case Specification:

填寫活動申請與預算表

1. 名稱(Name) 填寫活動申請與預算表。 1.1 簡述(Brief Description) 這個使用案例描述填寫活動申請與預算表的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 按填寫活動申請與預算表的鈕。 4. 成功條件(Successful Post-Conditions) 填寫活動與預算表申請完成。 5. 失敗條件(Unsuccessful Post-Conditions) 填寫活動與預算表申請沒完成。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人填寫活動與預算表送出 2.系統把資料儲存在資料庫裡 3.系統送給教資中心助理看 4. TUCEW:系統送出給客戶有沒有申請成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有送出 步驟 1.可能主持人選擇離開沒有把活動申請與預算表送出。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統傳送給上級失敗 步驟 3.可能在傳送的過程中斷或傳錯地方。

專案管理系統 組別:A18

使用案例:上傳專案計畫書 版本:0.1

編號:UC-011

Use Case Specification:

上傳專案計畫書

1. 名稱(Name) 上傳專案計畫書。 1.1 簡述(Brief Description) 這個使用案例描述上傳專案計畫書的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 專案已完成。 4. 成功條件(Successful Post-Conditions) 上傳專案計畫書完成。 5. 失敗條件(Unsuccessful Post-Conditions) 上傳專案計畫書失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人按上傳專案計畫書的鈕 2.系統儲存專案計畫書 3. TUCEW:系統顯示上傳成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有按上傳計畫書的鈕 步驟 1.主持人選擇離開，還沒有上傳計畫書的打算。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統顯示上傳失敗 步驟 3.可能上傳的途中被中斷，而提出失敗的訊息。 7. 詞彙表(Glossary) 詞彙 解釋 附註 專案計畫書 說明整個專案內容細節的文件

專案管理系統 組別:A18

使用案例:上傳活動成果報告 版本:0.1

編號:UC-012

Use Case Specification:

上傳活動成果報告

1. 名稱(Name) 上傳活動成果報告。 1.1 簡述(Brief Description) 這個使用案例描述上傳活動成果報告的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 活動已舉辦了。 4. 成功條件(Successful Post-Conditions) 上傳活動成果報告完成。 5. 失敗條件(Unsuccessful Post-Conditions) 上傳活動成果報告失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人按上傳活動成果報告的鈕 2.系統儲存活動成果報告 3. TUCEW:系統顯示上傳成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有按上傳活動成果報告的鈕 步驟 1.主持人選擇離開，還沒有上傳活動成果報告的打算。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統顯示上傳失敗 步驟 3.可能上傳的途中被中斷，而提出失敗的訊息。

專案管理系統 組別:A18

使用案例:上傳核准後之核銷簽 版本:0.1

編號:UC-013

Use Case Specification:

上傳核准後之核銷簽

1. 名稱(Name) 上傳核准後之核銷簽。 1.1 簡述(Brief Description) 這個使用案例描述上傳核准後之核銷簽的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 專案已經批准完。 4. 成功條件(Successful Post-Conditions) 上傳核准後之核銷簽完成。 5. 失敗條件(Unsuccessful Post-Conditions) 上傳核准後之核銷簽失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人按上傳核准後之核銷簽的 鈕 2.系統儲存上傳的核銷簽 3. TUCEW:系統顯示上傳成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有按上傳核准之核銷簽的鈕 步驟 1.主持人選擇離開，還沒有上傳核准之核銷簽的打算。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統顯示核銷失敗 步驟 3.可能核銷的內容不實，而提出失敗的訊息。 7. 詞彙表(Glossary) 詞彙 解釋 附註 核銷簽 活動完需要做核銷的動作，以防範不實

專案管理系統 組別:A18

使用案例:填寫工作項目與預定完成時間 版本:0.1

編號:UC-014

Use Case Specification:

填寫工作項目與預定完成時間

1. 名稱(Name) 填寫工作項目與預定完成時間。 1.1 簡述(Brief Description) 這個使用案例描述填寫工作項目與預定完成時間的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 要填寫專案時。 4. 成功條件(Successful Post-Conditions) 填寫工作項目與預定完成時間成功。 5. 失敗條件(Unsuccessful Post-Conditions) 填寫工作項目與預定完成時間失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人填寫工作項目和預定完成時 間 2.系統儲存工作項目和時間 3. TUCEW:系統顯示存儲成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有填寫資料 步驟 1.主持人選擇離開，還沒有要填寫資料的打算。 6.2.2 系統沒有把資料存進去 步驟 2.可能空間不夠而沒有辦法儲存。 6.2.3 系統顯示儲存失敗 步驟 3.可能在儲存的過程中發生錯誤，而提出失敗的訊息。

專案管理系統 組別:A18

使用案例:修改專案資料 版本:0.1

編號:UC-015

Use Case Specification:

修改專案資料

1. 名稱(Name) 修改專案資料。 1.1 簡述(Brief Description) 這個使用案例描述修改專案資料的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 按修改資料的按鈕。 4. 成功條件(Successful Post-Conditions) 修改資料成功。 5. 失敗條件(Unsuccessful Post-Conditions) 修改資料失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人按修改專案資料的按鈕 2.跳出修改資料的頁面 3.主持人填寫要修改的資料 4. TUCEW:顯示修改成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有要修改專案資料 步驟 1.主持人選擇離開，還沒有要修改專案資料的打算。 6.2.2 系統沒有接收到修改的資料 步驟 2.可能在傳來的過程發生中斷。 6.2.3 系統顯示修改失敗 步驟 3.可能系統連接橋梁或資料庫有問題，而提出失敗的訊息。 7. 詞彙表(Glossary) 詞彙 解釋 附註 修改資料 把想要變更的資料作修改的動作

專案管理系統 組別:A18

使用案例:刪除專案資料 版本:0.1

編號:UC-016

Use Case Specification:

刪除專案資料

1. 名稱(Name) 刪除專案資料。 1.1 簡述(Brief Description) 這個使用案例描述刪除專案資料的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 按刪除的按鈕。 4. 成功條件(Successful Post-Conditions) 刪除成功。 5. 失敗條件(Unsuccessful Post-Conditions) 刪除失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人點選刪除專案資料按鈕 2.系統在資料庫裡刪除這筆資料 3. TUCEW:系統顯示刪除資料成功 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有要點選刪除專案資料的按鈕 步驟 1.主持人選擇離開，可能沒有要刪除資料的打算。 6.2.2 系統在資料庫裡刪除失敗 步驟 2.可能程式有 bug 或系統出問題。 6.2.3 網頁顯示失敗 步驟 3.可能系統沒有連接好資料庫或連接過程中斷掉了，而提出失敗的訊息。

專案管理系統 組別:A18

使用案例:查詢個人控管專案 版本:0.1

編號:UC-017

Use Case Specification:

查詢個人控管專案

1. 名稱(Name) 查詢個人控管專案。 1.1 簡述(Brief Description) 這個使用案例描述查詢個人控管專案的過程。 2. 參與者(Actors) 主持人。 3. 前提(Pre-Conditions) 按查詢個人控管專案的按鈕。 4. 成功條件(Successful Post-Conditions) 查詢成功。 5. 失敗條件(Unsuccessful Post-Conditions) 查詢失敗。 6. 事件路徑(Flow of Events)

6.1 基本路徑(Typical Course of Events)

Actor 動作 系統回應 1.TUCBW:主持人點選查詢個人控管專案按鈕 2.系統跳到查詢個人控管專案頁面 3.主持人填要查詢的資料 3. TUCEW:有資料系統就顯示出來 6.2 其他/例外路徑(alternative/exceptional course) 6.2.1 主持人沒有要點選查詢個人控管專案的按鈕 步驟 1.主持人選擇離開，還沒有要看個人管控專案資料的打算。 6.2.2 系統在資料庫裡查詢失敗 步驟 2.可能程式有 bug 或系統出問題。 6.2.3 網頁沒顯示任何資料 步驟 3.可能資料庫沒任何資料或是自己還沒把資料存進系統裡。 7. 詞彙表(Glossary) 詞彙 解釋 附註 查詢個人管控專案 主持人查詢自己所屬的專案資料

4.3 系統成果簡介

1.系統首頁 本組專題的系統，一開始先建立雛型，下圖為我們所見之雛型的首頁截圖， 但後來經過使用者與本組全組組員的討論之後，覺得這樣的版面太過可愛，較沒 有專案管理的嚴謹感，因此，遂進行首頁畫面的修改。 圖 4.3.1 最初首頁圖 修改過後的首頁畫面如下，感覺比較穩重、嚴謹，讓使用系統的人可以一進 到系統就嚴謹戒慎操作，不要太過輕鬆或散漫。 圖 4.3.2 最終首頁圖

2.系統功能介紹

(1)登入後所進入的首頁

圖 4.3.3 首頁圖

(3)助理建立專案時所顯示的畫面

圖 4.3.5 建立專案圖

(4)主持人查詢專案經費時所顯示的畫面

(5)助理或主持人上傳各個檔案時所顯示的畫面

圖 4.3.7 上傳檔案圖

(6)主持人修改經費概算表所顯示的畫面

(7)主持人刪除專案所顯示的畫面

第五章 結論與建議

本章共分為兩節，第一節介紹本組專題的結論與組員的收穫；第二節則提出 具體的後續發展建議。

5.1 結論

基於本專題的研究目的，本專題組員結合網頁製作、使用者訪談等方法，進 行程式設計，並將成果呈現於專題系統中。讓這套系統使用者更加有效率管理各 項專案以及當中各種活動;本專題組員藉此機會也提升了自身程式設計能力以及 資料蒐集能力。

5.2 建議

1. 加強使用密碼保護功能系統。 2. 以製作連結方式增加網頁內容及更詳盡的資訊。 3. 開發出可以利用手機平台來使用本系統的 APP。

參考文獻

1.王懿慧，博碩士論文，「專案管理工程契約知識管理系統之建立」，2012 年 5 月 26 日擷取。 2. 賴志宏，Kris 專案管理學院， http://www.krispmschool.com/pmsystemmodel/pmdef/19pmdiff.php，2012 年 5 月 17 日 擷取。 3.賴志宏，Kris 專案管理流程圖， http://www.krispmschool.com/pmsystemmodel/krispmframework.php，2012 年 5 月 17 日擷取。 4.Harold Kerzner，專案管理，五南圖書出版股份有限公司，台北。 5.周龍鴻，專案管理趨勢， http://www.pmsuccess.net/rogersnotes_V2.asp?Eid=111，2012 年 5 月 26 日擷取。 6.專案管理系統簡介， http://tw.knowledge.yahoo.com/question/question?qid=1004121300753 ，2012 年 5 月 26 日擷取。

附 錄

會議紀錄表

專題名稱 活動計劃管理系統 時間 2012/8/28 地點 實驗室 主席 張育勛 記錄 李俊慶 出席者 劉得彥、陳偉皓、彭莉鈞 內容 1.收集活動計劃管理資料 2.收集製作整個網頁的素材 3.學習如何製作整個網頁的架構 4.架設上傳以及下載功能 5.學習 Access 的使用 6.學習 Apache 的使用 7.學習 JavaBean 的應用 8.規劃整個網頁的流程 決議 1.規劃整個網頁的架構 2.收集活動計劃管理的資料 3.學習需要用到的各種程式語言 老師建議 1.上網查或去圖書館找資料 2.要開始實作系統

元培科技大學學生畢業專題電子檔典藏授權書

本授權書所授權之畢業專題為授權人於元培科技大學 系(所) 學年 度第____學期修習專題製作課程之報告。 題 目：________________________________________________________________ 指導教師：_____________________ □ 同意授權全文 (請打勾) 本人茲將本著作，以非專屬、無償授權元培科技大學圖書館；基於推動讀者間「資 源共享、互惠合作」之理念，與回饋社會與學術研究之目的，元培科技大學圖書 館得不限地域、時間與次數，以紙本、光碟或數位化等各種方法收錄、重製與利 用；於著作權法合理使用範圍內，讀者得進行線上檢索、閱覽、下載或列印。 指導教師：__________________(請親筆正楷簽名) 授 權 人 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名) 班級： 學號：_______________ 學生姓名：___________(請親筆正楷簽名)

中 華 民 國

年

月

日

組員心得

張育勛： 從這次的專題中，讓我們了解一個專案不是隨便草草了事，而要經過規劃和 審查、評估等等的過程，才能完成專案，如果你的專案沒有經過一道道關卡的話， 完成出來的專案一定會有很多錯誤，並且漏洞百出，而照成公司方向錯誤，進而 導致損失，所以專案一定要有很多的手續來完成，這樣成能完成正確無誤的專案。 李俊慶： 感覺這個專題非常具有挑戰性，一方面可以訓練寫程式的能力，一方面則可 以學習系統設計的概念，要學的東西很難也很雜，希望自己能堅持下去。 劉得彥： 專題真的會讓人成長,從被動到主動的學習、從無到有,真的讓我學到非常得 多。我們的專題需要用到程式與 UML 在學習的過程中,也屢屢遇到困難但只能找 出解決的辦法,克服它，相信且覺得是唯一的道路。雖然遇到的困難與挫折,也跟 成長一樣多,期望到時候專題結束時,能感覺自己的蛻變。 陳偉皓： 這次的專題是我所未見過的，具有很大的挑戰性，在學習程式語言中，我們 與到了許多的瓶頸，但我們也將它一一的破解開來，在這次的專案中，我的組員 們變得很有參與感，雖然在這過程中，我們曾一度的想放棄過，但人因夢想而前 進，我希望將來可以成為程式設計師，這夢想使我們更加團結，期望我們可以在 這專題中學習到更多的技術與知識。 彭莉鈞： 專題是所有人的必經之過程，就好像 18 歲轉大人一樣，在這專題中，遇上 了我從未見過的程式語言，以往大家的認知，在上班族程式設計師中，都以男性 居多，但在經濟壓抑下，許多的女性也開始紛紛加入程式設計方面，男女平等， 已不再是只有男性才可以寫程式了，不論往後是否參與程式方面這塊，還是希望 可以和組員們一起努力，不管再怎麼艱難，團結才是力量。

101 元 培 科 技 大 學 資 訊 管 理 系 畢 業 專 題 專 案 管 理 系 統 計 畫 書 陳 偉 皓 彭 莉 鈞 李 俊 慶 劉 得 彥 張 育 勛