期末 - 智慧型系統實驗室.doc

1 軟體專案管理軟體專案管理 期末報告期末報告 校園E化系統開發案 組別組別 第四組第四組 組員組員 A9315003A9315003 詹程傑詹程傑 A9315012A9315012 劉博睿劉博睿 A9315018A9315018 羅銘福羅銘福 A9315028A9315028 簡仲毅簡仲毅 A9315048A9315048 黃彥博黃彥博 2 軟體專案計畫書軟體專案計畫書 1 專題摘要專題摘要 4 1 1專案名稱 4 1 2專案目的 4 1 3專案交付範圍 4 1 4專案交付項目 5 1 5專案期程與預算摘要 5 2 專案組織專案組織 6 2 1內部架構 6 3 管理流程規劃管理流程規劃 7 3 1專案啟動規劃 7 3 1 1預估計劃 7 3 1 2人力規劃 8 3 1 3資源獲得規劃 9 3 1 4專案人員訓練規劃 9 3 2工作規劃 10 3 2 1工作項目 12 3 2 2時程規劃 13 3 2 3資源規劃 14 3 2 4預算規劃 15 4 技術流程規劃技術流程規劃 16 4 1流程模式 16 4 2方法工具與技術 17 4 3基礎建設規劃 17 3 4 4產品接收規劃 17 5 支援流程規劃支援流程規劃 18 5 1風險管理規劃 18 5 2確認與驗證規劃 27 5 3文件製作規劃 28 5 4品質保證規劃 29 5 5審查與稽核規劃 29 5 6問題解決規劃 29 5 7承包商管理規劃 29 5 8流程改善規劃 30 6 附帶事項規劃附帶事項規劃 31 6 1保固與服務 31 6 2會議記錄 33 4 軟體專案計畫書 1 專案摘要 1 1 專案名稱 校園E化系統開發案 1 1 1 專案目的 校園內設置E化系統 使校園能夠達到E化的成果 利用網頁 手機 儲值系統等 讓學生與老師們能夠更容易的取得校內資源 善加利用 幫助學生學習 提供公平性的選課也提供各位老師們多元的教學方式 提升 學校的行政效率和服務品質 進而提升學校競爭力 1 1 2 專案交付範圍 主要工作項目 1 網頁導覽 2 電子消費系統 3 校園訊息管理系統 4 儲值系統 5 系統整合 6 認證系統 1 1 3 專案交付項目 交付項目綱要設備軟體 導覽系統利用手機上網聯結資料庫 將已經建 立學校的地圖 校園各角落的相簿集 教室的圖檔 經由手機導覽整個校園 的各處室所在地 掛失系統的建立 學生證遺失時 可手機線上掛失 網頁 包含 選課 地 圖 相簿 圖檔集 PHP 學生身 分資料 庫 電子消費系統目前推出的3G手機擁有很多功能 在 加上現在人手一機 我們就可以把手 機點餐運在此 可以想像每天排隊點 餐所浪費的時間 當我們還在走路的 途中可以按下手機鍵 可以再手機介 面上點選店家 選點要吃的食物 也 不用花時間再排隊上 伺服器 手機 JAVA 校園訊息管理系統校內各級公文公告均統一以電子檔發 送 減少紙張的秏費和人工作業 藉 由網際網路即可隨時隨地的收發核對 相較於紙本公文的傳遞 電子公文更 電子看版 網際網路 可連接網 路之PC或 跨平臺 OS 校 園資訊 專用資 5 具有即時性 提升訊息流通的速度 透過專用資料庫更可達到立即查閱 統一管理 也能透過手機和電子公佈 欄取得學校公佈事項和校園各項活動 等相關消息 行動運算 裝置 料庫 JAVA 儲值系統學生可以是先向學校購買點數 學校 給予一組辨別碼 然後透過手機連結 學校的系統儲值 在第一次使用此系 統時 學生必須設置一組私人密碼 往後在登錄時 要同時輸入辨別碼及 私人密碼 才能夠使用其服務項目 配合其他系統 如點餐系統 購書系 統 儲值系統必須包含產生辨別碼 身分認證 餘額管理 資料保密 無無 1 1 4 專案期程與預算摘要 本專案共分三階段並於三百六十日曆天完成本專案之全部工作 第一階段 於本專案簽約次日起三十日曆天交付專案期初計畫書 第二階段 於本專案簽約次日起六十日曆天交付系統分析報告 系統設計報告 第三階段 於本專案簽約次日起三百六十日曆天交付系統管理手冊 整合測試 報告 教育訓練成果 網頁相關檔案 資料庫程式原始碼及執行碼 並完成基本資料建構 預算金額 新台幣壹千貳佰萬元整 6 2 專案組織 2 1 內部架構 專案經理專案經理 系統整合部門系統整合部門 系統測試部門系統測試部門 訓練教育部門訓練教育部門 系統建置維護系統建置維護 軟體開發部門軟體開發部門 硬體部門硬體部門 外包外包 程式分析工程師程式分析工程師 程式設計工程師程式設計工程師 美工設計人員美工設計人員 系系 統統 整整 合合 人人 員員 系統測試人員系統測試人員 教教 育育 訓訓 練練 人人 員員 系系 統統 建建 置置 人人 員員 系系 統統 維維 護護 人人 員員 7 3 管理流程規劃 3 1 專案啟動規劃 3 1 1 預估規劃 於360天內完成所有工作項目 1 1 第一階段 於本專案簽約次日起三十日曆天交付專案期初計畫書 第一階段 於本專案簽約次日起三十日曆天交付專案期初計畫書 先於校園內評估架設機房 統計資料庫所應建立資料內容與數量 來計畫 往後需要多少時間來完成資料庫的建立 2 2 第二階段 於本專案簽約次日起六十日曆天交付系統分析報告 系統設計第二階段 於本專案簽約次日起六十日曆天交付系統分析報告 系統設計 報告 報告 統計完所需要的資料數量 開始規劃相對應的硬體設備 如硬體需要多少 空間容量 硬體資料庫機房建立所需要的空間 手機於校園內的普遍度 各餐廳的配合意願等 3 3 第三階段 於本專案簽約次日起三百六十日曆天交付系統管理手冊 整合第三階段 於本專案簽約次日起三百六十日曆天交付系統管理手冊 整合 測試報告 教育訓練成果 網頁相關檔案 資料庫程式原始碼及執行碼 測試報告 教育訓練成果 網頁相關檔案 資料庫程式原始碼及執行碼 並完成基本資料建構 並完成基本資料建構 依此順序進行工作 預估開發雛型預估開發雛型 需求分析 需求分析 建立雛型 使用者驗證 程式撰寫 是否符 合需求 測試 維護 意見回饋與 需求修改 需求分析 需求分析 建立雛型 使用者驗證 程式撰寫 是否符 合需求 測試 維護 意見回饋與 需求修改 雛型開發方法程序圖 8 3 1 2 人力規劃 部門職責投入人力 軟體開發部門網頁導覽開發 電子消費系統開發 校園訊息管理系統開發 儲值系統開發 認證系統開發 系統平臺建立 13 人 系統整合部門將各系統整合至同一平臺 確保整個系統的完整性和運作性 5 人 系統測試部門進行黑箱測試 進行白箱測試 檢查是否有系統 Bug 7 人 系統建置維護系統平臺安裝 保固維護 7 人 教育訓練部門基礎教育訓練 運用系統操作訓練 2 人 人員雇用和訓練 職稱人數工作人月備註 專案經理1 人 12 專案全程 程式分析師3 人 9 每人以 3 月計 程式設計工程師8 人 32 每人以 4 月計 美工設計人員2 人 4 每人以 2 月計 系統整合人員5 人 25 每人以 5 月計 系統測試7 人 14 每人以 2 月計 系統安裝3 人 3 每人以 1 月計 系統架設4 人 8 每人以 2 月計 教育訓練2 人 2 每人以 1 月計 總計 35109 9 3 1 3 資源獲得規劃 硬體設備 手機 由使用者自備 伺服器 外包廠商 軟體設備 開發工具 JAVA 軟體工程師自行提供 應用軟體 軟體工程師撰寫 伺服器認證 軟體工程師撰寫 校園資料庫 校方提供資料 工程師建立 介面外觀設計 美工人員 預算取得 使用者付費 3 1 4 專案人員訓練規劃 硬體 外包 軟體 導覽系統 在校園各處所拍照 建立詳細的地圖集 與簡略的地圖系統 兩者互相連 結 所需時間 14 天 消費系統 聘請校內各個消費部門的廠商 向其工程師說明其營業項目 以及學生和 老師的消費型態 所需時間 14 天 儲值系統 聘請專業銀行員 向其說明銀行之存款運作方式 所需時間 14 天 公文系統 聘請校內各行政部門代表 向其說明學校公文發送項目 並提供所需簽名 之公文形式 所需時間 14 天 認證系統 參訪各大網站之認證方式 並聘請學校之個人登錄系統設計人員 向其說 明登錄認證方式 與以統一 所需時間 14 天 10 3 2 工作規劃 系統工作規劃 WBS 校園 E 化 2 0 平臺 5 0 整合 3 0 服務 4 0 資料庫 1 0 特 別要求 2 1 軟體 2 2 硬體 2 3 網路 2 1 1 規劃 5 1 測試 2 1 2 撰寫 2 1 3 除錯 2 1 4 修正 2 2 1 外包 2 2 2 架設 2 3 1 伺服器 5 2 相容 5 3 認證 5 4 品質 5 2 1 分析 5 3 1 分析 5 3 2 比對 5 4 1 管控 5 4 2 監督 3 1 導覽 3 2 消費 3 3 儲值 3 4 公文 3 1 1 下載 3 1 2 認證 3 3 1 建立 3 3 2 確認 4 1 收集 4 3 建立 4 1 1 學生 4 1 2 老師 4 1 3 地圖 3 5 特別需求 4 2 核對 4 1 4 店家 5 4 3 美工 11 專案工作規劃 專案生命週期表 階段區分 系統需 求分析 系統設 計 程式製 作 軟體使 用手冊 撰寫 系統整 合測試 系統壓 力測試 輸出說明項目 輸入出事項 工作產品 輸 入 輸 出 輸 入 輸 出 輸 入 輸 出 輸 入 輸 出 輸 入 輸 出 輸 入 輸 出 測試 或 審查 輸出 通過 準則 訪談紀錄 審查審查確認 軟體需求規 格書 審查審查確認 軟體設計規 格書 審查審查確認 軟體程式原 始碼 測試 符合本案軟 體設計規格 書 軟體使用手 冊 審查 符合本案軟 體設計規格 書 軟體測試報 告 審查審查確認 12 3 2 1 工作項目 負負 責責 工工 作作工工 作作 項項 目目時時 程程 本公司學校 1 專案會議 每一 兩週舉行專 案檢討會議 專案進度檢討 專題討論 依雙方約定時 間進行 專案主持人及相關人 員須參加 準備會議資料 記錄會議記錄 專案承辦人及相關人員須 參加 準備會議室 確認會議記錄內容 2 需求訪談 依據需求進行 訪談 提供訪談問卷 執行訪談 製作訪談記錄 依需求進行訪談 提供受訪人員名單 訪談記錄確認 3 軟體需求分析 分析軟體功能 需求 執行分析 製作需求分析記錄 分析記錄確認 4 軟體撰寫 依據合約規定 執行 提供進度確認單 依照軟體開發流程 進行軟體撰寫 依交付清冊進行審查 5 單元測試 依據合約規定 執行 依合約書所定時程及 單元測試準則 審合驗收確認單 6 系統整合 依據本計畫書 規定 依合約書所定時程執 行整合 審核整合記錄單 7 系統架設 依據本計畫書 規定 依合約書所定時程進 行系統架設 審核系統架設確認單 8 驗收測試 依據本計畫書 規定 依專案時程執行測試 及產品驗收準則完成 產品交付 提供交付清冊 進行產品驗收 配合硬體及整體環境進行 測試 審核測試單 8 安裝及技術指導 依據本計畫書 規定 安裝前備妥硬體 確 認安裝地點及環境 安裝及設施 提供軟體系統技術指 導 審核安裝記錄單 13 工工 作作 項項 目目時時 程程負負 責責 工工 作作 本公司學校 9 需求變更 專案期間 填寫需求變更申請單 確認需求變更申請單 及工時 費用與時 程之調整 執行必要之變更作業 評估影響層面 回覆需求變更申請單 確認需求變更後結果 3 2 2 時程規劃 預定進度甘特圖 Gantt Chart 時間 工作項目 1 月 2 月 3 月 4 月 5 月 6 月 7 月 8 月 9 月 10 月 11 月 12 月 備 註 1 需求訪談 2 軟體需求分析 3 軟體撰寫 4 單元測試 5 系統整合 6 系統架設 7 驗收測試 8 安裝及技術指導 工作時程完成日期 14 查核點發展過程查核內容預計完成日期 1 專案啟動階段軟體開發計畫書 95 01 15 2 需求分析階段軟體需求規格書 95 03 01 3 系統設計階段 軟體設計規格書 軟體測試計畫書 95 06 15 4 系統開發測試階段 軟體測試報告 94 07 31 5 系統驗收 軟體使用手冊 軟體執行報告 94 11 31 3 2 3 資源規劃 3 2 4 預算規劃 15 預算之編列 軟體開發 應用軟體設計開發金額 新台幣 消費系統 60 儲值系統 45 訊息管理系統 40 認證系統 40 導覽系統 15 總計 200 萬 硬體建造與架設 品名數量單價 新台幣 總價 新台幣 伺服主機2 台150 萬300 萬 訊息資料庫主機1 台10 萬10 萬 儲存裝置1 台10 萬10 萬 硬體安裝費 XX 50 萬 總計370 萬 人月成本 職稱人數工作人月薪水 新台幣 專案經理1 人 12 七十二萬 程式分析師3 人 9 四十五萬 程式設計工程師8 人 32 一百二十八萬 美工設計人員2 人 4 十六萬 系統整合人員5 人 25 一百萬 系統測試7 人 14 五十六萬 系統安裝3 人 3 九萬 系統架設4 人 8 二十八萬 教育訓練2 人 2 六萬 總計 35109 四百六十萬 16 4 技術流程規劃 4 1 流程模式 NO YES 認證系統 手機 學校資料 庫伺服器 通過 結束 系統整合 導覽系統 消費系統 儲值系統 公文系統 繼續 YES NO 17 4 2 方法 工具與技術 作業項目方法技術工具 需求分析需求分析方 法 訪談溝通 應用軟體規格描述 應用軟體規格檢查 MS Word MS Excel 系統分析 系統設計 物件導向模 式分析及設 計 定義需求 需求分析 系統分析設計 Rational Rose 手機 PC 程式撰寫由上往下製 作 資料設計 結構化程式設計 使用者介面設計 Java BCB 軟體測試白箱測試 黑箱測試 壓力測試 路徑測試 條件測試 資料流程測試 迴圈測試 Rational Rose Rational TeamTest 4 3 基礎建設規劃 統計資料 建立所有餐廳商店師生資料 於第二階段完成前由校方交付資料 硬體設備 於校園內先建立資料處室 擺放資料庫與建立網頁 4 4 產品接收規劃 1 地圖導覽 當系統建立完成之後 之後學校處所 人員資料可能有所變動 因此 當 系統完成後 就需要時間來訓練學校行政人員如何建立地圖集與輸入新的 人員資料 2 消費系統 在店家資料庫建設完畢之後 如有攤位變換或者推出新產品 則會訓練學 校相關管理人員 把資料重新載入資料庫使資料處於最新資料 3 儲值系統 提供學校隨機產生認證碼 由學校自行販賣點數給欲購買之學生或老師 指導校方分門別類建立學生個人帳戶 4 校園訊息管理系統 校各處室人員發生職務變更和新聘人員對於系統的操作及熟絡 18 5 支援流程規劃 5 1 風險管理規劃 1 目的 在專案執行期間 針對可能影響專案結果的各種突發狀況 事先界定出潛 在因素 以便規劃對應之風險控管計畫及處理原則 在必要時 亦需在軟體開 發生命週期內執行各項改善作業 以降低或排除對專案結果有害之風險因子 2 責任 本流程相關人員所需擔負之責任如下 A 計畫主持人 A 指派風險管理人員 風險處理人員 B 審查風險降低計畫以及含緊急應變計畫 C 監督並掌控風險管理活動之執行 B 風險管理人員 A 訂定風險降低計畫以及緊急應變計畫 B 執行風險界定與評估 追蹤風險處理結果 執行風險監測 C 各組組長為各分項工作的風險管理人員 C 風險處理人員 A 負責執行風險降低處理 緊急應變措施等 B 風險處理人員主要為各組成員 如需要其他組共同解決則由計畫主 持人協調人員處理 D 允入準則 A 在專案執行任一時期 需要規劃潛在風險管理計畫與活動時 B 當專案執行監控活動中 面臨重要問題或與原計畫偏差而提出可能 之潛在風險時 E 輸入說明 專案執行需要之合約 建議書 生命週期之工作產品 例如 軟體設 計文件 相關領域專家之意見 或以往之歷史資料等 F 作法 A 風險管理準備 專案於規劃階段 風險管理人員必須先確定可能之風險來源並加以分類 19 同時定義出風險管理投入的控制參數 並據以達成專案預期目標而規劃 出專案的風險管理策略 進而作為後續執行分析與評估風險之基礎 流 程中各步驟之工作內容說明如下 1 確定風險來源及類別 風險管理人員可以經由執行所需要之合約 建議書 生命週期 之工作產品 專家訪談意見 專案的歷史資料 或者與專案成 員經由集體討論之方式 來確定可能之風險來源並建立風險的 類別 用以認定與收集風險 由專案內部或外部來確定可能之風險來源 如不確定的需求 技術可用性 開發者能力或不切實際的時程規劃等來源 由風險的來源與風險對專案的衝擊加以分類 可分為技術 設 計 環境 成本或時程等類別 風險管理人員須將上述已確定之風險來源及風險類別均記錄於 專案風險來源與種類查檢表 如風險來源或風險類別有異動 時亦須隨時更新 2 定義風險參數 風險管理人員須依照本流程之風險可能性與影響嚴重性兩項參 數分別設定高低等級 用以作為風險評估 風險排序 估計風 險控制層級之標準 依照下列之風險可能性評等表 就風險發生的可能機率對可能 發生之風險定義高 中 低之評等 必要時 可由相對等級範 圍內選定一數值作為優先順序之量化指標 表 5 1 風險機率量化表 可能機率評等準則量化指標 低不太可能發生 或出現率在 10 以內 0 0 0 3 中可能發生 或出現率在 10 50 之間 0 3 0 7 高頻繁發生 或出現率在 50 以上 0 7 1 0 20 表 5 2 風險程度量化表 嚴重程度評等準則量化指標 低 下列情形之一 1 對達成專案目標影響輕微 2 進度落後 10 以內 3 成本增加 10 以內 4 其他由專案定義為 輕度 嚴重之條件 0 3 中 下列情形之一 1 對達成專案目標影響中等 2 進度落後 10 20 之間 3 成本增加 10 25 之間 4 其他由專案定義為 中度 嚴重之條件 3 7 高 下列情形之一 1 對達成專案目標影響嚴重 2 進度落後 20 45 之間 3 成本增加 25 50 之間 4 其他由專案定義為 重度 嚴重之條件 7 9 極高 下列情形之一 1 無法達成專案目標 2 進度落後 45 以上 3 成本增加 50 以上 4 其他由專案定義為 極度 嚴重之條件 9 10 3 建立風險管理策略 本專案風險管理策略包含下列各項內容 風險界定 各組風險管理人員每月填寫 專案風險來源與種類查 檢表 風險分析 各組風險管理人員於專案會議時依據 專案風險來 源與種類查檢表 與計畫主持人討論後 提出 專案風險分析表 風險降低處理 各組風險管理人員依據 風險降低處理對策表 提出建議方法與指派風險處理人員進行風險處理 風險監測 各組風險管理人員需持續監控風險降低活動的執行 方法 完成準則 處理程序或使用之工具 執行管制或核准人員的職責由計劃主持人指派 21 風險監測或再評估之時間訂於每週之專案會議 B 界定及分析風險 於專案進行期間 風險管理人員必須由已確定並記錄之風險來 源 風險類別及定義之風險參數 界定出專案所有可能發生之風險 並加以評估 分類 而各項風險所得之風險曝光程度由高至低依序 排序後 將風險分析結果填寫於 專案風險分析表 中 以決定各 項風險的相對優先處理順序 流程中各步驟之工作內容說明如下 界定風險 a 風險管理人員經由執行需要之合約 建議書 生命週期 之工作產品 專家訪談意見 專案歷史資料 或者與專案 成員經由集體討論的方式進行 b 由記錄於 專案風險來源與種類查檢表 之風險來源及 風險類別 找出在達成專案目標的過程中所有可能發生之 風險 c 將所有已確定風險之背景 發生情形 影響的嚴重性等 用簡潔的敘述加以描述並記錄於 專案風險分析表 評估 分類及風險排序 對 專案風險分析表 中每一個已界定之風險 分別根據上 述表伍 風險可能性評等表 及表伍 風險嚴重性評等表 進行評估作業 並賦予相對的高低等級 定性化 必要時 亦可賦予相對等級之數值來作為量化指標 定量化 a 每一個已界定風險經由評估作業所取得之評估結果 定性 化等級或定量化數值 必須記錄於 專案風險分析表 b 依照 專案風險來源與種類查檢表 中已定義之風險類 別 對每一個已界定之風險進行分類作業 並將分類結果 記錄於 專案風險分析表 c 由各項風險經過風險評估後之高低等級加以判斷風險曝 光程度 risk exposure 其判斷準則說明如表 5 3 表 5 3 風險曝光程度表 風險曝光程度判斷準則 低可能機率為低等且嚴重程度為低等者 中 可能機率或嚴重程度均為中等者 或者一項為中等 且另一項為低等者均屬之 高可能機率或嚴重程度任一項為高等 含 以上者 22 d 各項風險之風險曝光程度亦可以量化指標呈現 也就是 由風險評估所得相對等級之定量化數值加以相乘 風險可 能性評等 風險嚴重性 而得 e 將每一風險所得到之風險曝光程度進行風險排序 並依 照由高而低之排列順序將其記錄在於 專案風險分析表 f 定義執行門檻 風險管理人員必須由下列三項設定方式中 視其需要選擇 一項做為進行風險降低與追蹤管理之執行門檻 對於風險曝光程度在中等以上程度之風險 風險曝光程度之量化指標在 2 9 含 以上者 計算公 式 3 0 3 7 0 7 2 無論風險曝光程度為值化或量化 只要經風險排序後 在前十位者即是 C 降低風險 專案於風險管理人員界定與評估所有風險後 專案經理應研訂 風險管理相關計畫與執行相關風險處理活動 以降低風險的可能性 減少風險發生可能造成的衝擊 尤其對專案可能造成危害的關鍵性 風險更應訂定緊急應變計畫 以降低發生時所造成的傷害 流程中 各步驟之工作內容說明如下 研訂風險降低計畫 a 對於超過專案所定義執行門檻之每一風險 專案必須執 行風險降低處理與追蹤管理 而其他未超過執行門檻之風 險則進行簡單的監測即可 b 專案經理可參酌下列 風險處理方案表 規劃各項風險 來源下可能採取之風險降低處理步驟 並將規劃結果記錄 於 風險降低處理對策表 以提供專案執行風險降低處 理之主要參考 如果專案於執行風險降低處理時訂出新的 處理步驟時 亦得將新處理步驟更新至 風險降低處理對 策表 中 以做為專案未來執行風險管理之參考 23 表 5 4 風險處理方案表 風險處理方案處 理 說 明 風險規避 改變或降低需求 但仍然符合客戶需要 或者企圖 完全降低可能機率及損失程度至零時 所採取之處 理行動 風險控制 採取主動之步驟 以降低風險為主要目的 較常為 專案所採用 風險轉移重新配置設計需求 以降低風險 風險監測觀察及定期對指定風險的改變狀況進行再評估 風險接受風險曝光程度太低 或決定不採取任何處理動作 c 若該風險已決定採取 風險接受 之處理方案時 專案 經理必須將其決定的理由記錄於 專案風險分析表 d 每一必須進行風險降低處理之風險 計畫主持人應由 風險降低處理對策表 選擇至少一項之風險降低處理步 驟 並將其填寫於 專案風險分析表 之 風險降低處理 步驟 欄位內 做為降低該風險時據以執行之處理步驟 e 每一必須進行風險降低處理之風險 專案經理均須指派 風險處理人員負責執行風險處理活動 並將人員姓名填寫 於 專案風險分析表 若人員發生異動時 必須更新該 項資料 研訂緊急應變計畫 a 專案經理必須從已界定之風險中 選定可能無法避免且會危 害專案的風險做為關鍵性風險 並研訂一份處理關鍵性風險之 緊急應變計畫 一但這些風險真正發生時 採取緊急應變 措施加以處理與控制 使其降低對專案所造成之嚴重衝擊 b 緊急處理過後 必須將處理結果記錄於 專案風險監測結果 紀錄表 並再次評估是否需要執行風險處理活動 或者進行 監測即可 執行風險監測與風險降低處理 a 專案執行期間 風險管理人員必須遵照已規劃之風險管理策 略 執行各項風險管理活動 並定期 至少每月一次 監測每 一已界定風險之風險狀態及風險處理活動的執行結果 直到 專案結案為止 24 b 於執行風險處理活動時 必須設定起始日期及預計完成日期 並記錄該風險處理活動之執行結果 以評估執行績效 c 風險管理人員每次進行風險監測的各項結果均須紀錄於 專 案風險監測結果紀錄表 其中無須進行任何風險處理活動者 只需監測 僅需記錄風險狀態即可 不必填寫風險處理執 行績效之欄位資料 d 於發生風險狀態變動與發現新風險時之處理準則如下 被監測風險之風險狀態有所變動 例如 風險曝光程 度的等級上昇或下降 時 必須再次評估是否執行風險處理 活動 若風險狀態之變動結果超出專案所訂降低處理之執 行門檻時 必須決定或重新選擇因應之風險降低處理步驟 若風險狀態之變動結果低於專案所訂降低處理之執行門檻 時 可持續進行監測或由降低處理改為監測即可 若發現未預料到之新風險時 專案必須依照已規劃之 風險管理活動 對新風險進行風險界定 分析與排序 評 估是否需要執行風險處理活動 並進行風險監測或選定因 應之風險降低處理步驟 G 允出準則 A 專案所有可能發生之風險均已界定並完成評估 且降低風險計 畫已完成規劃並開始執行 B 所有風險均已完成定期監測或執行風險降低處理 C 專案結案並且與風險管理相關的度量資料均已蒐集完成 H 工作產品說明 A 專案風險來源與種類查檢表 以品質記錄方式進行管理 B 專案風險分析表 以品質記錄方式進行管理 C 風險降低處理對策表 以品質記錄方式進行管理 D 專案風險監測結果紀錄表 以品質記錄方式進行管理 25 開始 決定風險來源及類別 定義風險參數 建立風險管理策略 界定風險 訂定降低風險計畫 評估 分類及 風險排序 研訂風險降 低計畫 結束 風險管理人員 相關關鍵人員流程圖 執行降低風險計畫 風險管理人員 風險管理人員 風險管理人員 計畫主持人 風險管理人員 研訂緊急應 變計畫 度量 與分析 MA 專案風險來 源與種類查 檢表 專案風險分 析表 風險降低處 理對策表 專案風險監 測結果紀錄 表 專案 監控 PMC 度量 與分析 MA 計畫主持人 風險管理人員 計畫主持人 風險管理人員 風險管理人員 風險處理人員 開始 決定風險來源及類別 定義風險參數 建立風險管理策略 界定風險 訂定降低風險計畫 評估 分類及 風險排序 研訂風險降 低計畫 結束 風險管理人員 相關關鍵人員流程圖 執行降低風險計畫 風險管理人員 風險管理人員 風險管理人員 計畫主持人 風險管理人員 研訂緊急應 變計畫 度量 與分析 MA 專案風險來 源與種類查 檢表 專案風險分 析表 風險降低處 理對策表 專案風險監 測結果紀錄 表 專案 監控 PMC 度量 與分析 MA 計畫主持人 風險管理人員 計畫主持人 風險管理人員 風險管理人員 風險處理人員 圖 5 5 專案風險管理流程 26 風險降低處理對策表 序號風險來源可採取之風險降低處理步驟 01 人員缺乏技術性的 訓練 估計一短暫性可容忍之訓練的時間 提供額外的訓練資源 研擬專案的特別訓練計畫 實施技術交流研討會 02 需求持續性的變動 從客戶端取得最初確認之需求規格 使客戶確信需求變動將影響工作時程 設計一需求變更管理程序 與客戶商議因需求變動而造成實際影響之報償 03 不明確的需求 由經驗與業務邏輯所做的假設必須讓客戶知道 且獲得客戶的確認 依據取得的需求開發一雛型 讓客戶進行審查與確認 04 人員短缺 確定各項人力均分派至專案工作中 建立專案會議 以掌握工作分派情形 專案成員的工作須相互輪調 保有專案之備援人力 維護一個人獨立負責工作的產出文件 嚴格遵照建構管理流程與指引來執行建構管理 05 迫使專案對外作出 緊迫性的決策 敘述支持此項決策所造成不利損失的事實與數據 以及談成作出此 項決策的個人責任 假如無法避免的話 界定出實際的風險及實施風險降低計劃 06 未符合客戶的績效 需求 明確的定義出績效標準 並由客戶進行審查 設計一符合績效標準之遵循規範 準備好符合績效的設計計劃 並審查該計劃 模擬關鍵性交易 transaction 的績效 儘可能使用具代表性且大量的資料進行測試 07 不切實際的時程估 計與安排 與客戶溝通一較好的工作時程 確定平行進行之工作項目 提早準備專案所需資源 假如工作時程中未包含關鍵性的工作流程時 須與客戶進行商議 與客戶商議因此造成實際影響之報償 08 採用新的軟體 硬 體 考慮分階段交貨 關鍵性組件先行交貨 工作時程中需要包含學習所花費的時間 提供新技術的教育訓練 09 不足的商業知識 增加與客戶的互動 並確保可由其中獲得該知識 組織內實施該知識領域的教育訓練 模擬客戶的商業交易 並取得客戶的贊同 10 挽救未履行或較差 的績效 與客戶一起確定可能的預期指標 預先規劃挽救工作所需之工作量 規劃出最理想的挽救方法 備註 本表格可視實際需求 酌予修改 風險來源 及 可採取之風險降低處理 步驟 欄位之資料內容僅為參考範例 於填寫時可視其需求自行增修 27 5 2 確認與驗證規劃 單元列表規劃 客戶參訪軟體開發前參訪客戶 使客戶確認其需求並簽約 廠商訪談在硬體架設前 驗證測試外包廠商產品 測試通過在確認其 品質符合要求 軟體撰寫須與客戶做多次需求訪談 確認後則開始單元工作 系統整合當各單元完成工作時 通過PM確認驗證在交由系統整合人員 系統架設架設進行前 須先通過PM確認其他單元完整性 由PM確認 後方可架設 驗收測試全部單元完工後 由PM先行確認系統 再轉交給客戶做驗收 安裝及技術指導PM確認系統穩定在交由安裝人員 安裝完成後由指定指導人 員教導相關操作 28 5 3 文件製作規劃 在各階段提出報告文件 依照下列方式文件製作 管理 文件種類文件種類 依循 管理方式 依循 管理方式 專案依循文件 合約 建議書 專案管理計畫書 專案開發文件管制程序 開發 生命週期 文件 需求規格書 系統設計文件建構管理程序 非生命週期之文件 紀錄 會議紀錄 訓練資料專案開發文件管制程序 相關之監控資料及管制資訊文件管制程序之規定 參考文件 資料相關圖書管理規定 格式 用紙 使用 尺寸紙張 繕打方式 除圖表 型錄外 由左至右橫式繕打 裝釘方式 文件應編目錄 加註頁碼 加裝封面 封面上註明本專案名稱及廠商名 稱 裝訂線在左側 裝釘成冊 依據合約之規範時程交付下列文件 如下 A 專案管理計畫書 B 資訊人員基礎教育訓練開課計畫 C 設備建置說明會報告資料 D 平台服務 a 獨立驗證與確認工作計畫書 b 平台服務獨立驗證與確認報告 c 平台服務服務水平報告 d 應用系統獨立驗證與確認報告 e 平台服務技術手冊 E 應用系統 a 軟體開發計畫書 b 軟體需求規格書 c 軟體測試計畫書 d 軟體設計規格書 e 軟體執行報告 f 軟體使用手冊 g 軟體測試報告 h 軟體壓力測試報告 F 設備操作訓練結案報告 G 應用系統操作訓練結案報告 H 資訊基礎教育訓練結案報告 29 I 各單位交付及測試清單 a 各單位系統架構圖 b 軟體工具數量分配表 5 4 品質保證規劃 品質管理將依循本公司品質管理系統之相關制度執行 並確保客戶之需求 最 終產品的品質要求 5 5 審查與稽核規劃 PM先規劃各部門每一階段應完成的項目 之後再由各部門對PM定期提出進度報 告 以提供PM掌握各部門進度 以達到審查與稽核的作用 5 6 問題解決規劃 1 相關資料不齊全 導致規劃行程拖延 需要學校方面如期交付預定的資料 在當初計畫中需事先溝通 將此項納入假 設行程delay時的因素之一 2 資料外洩的風險 學生老師私人資料的保密 我方建立檔案庫 由特定人管理 當有人需要使 用必須登記 假如有資料外洩的狀況便可以由此尋找 而校方方面 資料庫 的管理不在此限 3 硬體設備架設場所空間不夠 在雙方初期事先溝通 必須由校方先提供足夠的空間及場所 4 投入資金超過客戶所預期 當初溝通預估資金 必須要先對於事後有可能會增加資金的項目對於校方 先提出可能性 以便於事後溝通 5 外包廠商對系統信任度不足 每一階段對校方提出進度報告 將進度給予廠商了解 增加廠商與校方的 信任度 5 7 承包商管理規劃 目的 外包可以削減開支 控制成本通過外包 運營商無需擴大自身人力規模 減少了因人才聘用或流失而花費的精力 成本以及面臨的壓力 節省了 培訓方面的開支 並增加了人力資源配置的靈活性 承包管理大綱 1 工作項目概況 2 工作項目實施條件分析 3 合同履行的基本策略 4 承包工作結構 WBS 管理目標 30 5 承包工作組織結構 6 工期目標和項目總進度計劃 7 成本目標 8 工程的驗收與測試 9 項目風險預測和防範措施 10 變更的授權範圍 承包工程完成確認 1 工程已經竣工驗收 2 與包商合同責任已經履行完畢 3 確認工程已經履行完畢 結束與承包商合同 5 8 流程改善規劃 軟體撰寫 驗收測試 系統整合這幾個階段中 由於可能會有互相需要的關聯 性 所以在執行過程中會需要更改流程 故在規劃各階段時 要必須要先預留時間 以應付當行程規劃流程改變時 所增加的額外時間 軟體撰寫時程分為兩項 1 撰寫程式時間 對於廠商當初提出的要求 程式設計師對於要求而撰寫的 時間 2 修