期末 - 智慧型系統實驗室

軟體專案管理期末報告校園E化系統開發案組別:第四組組員:A9315003 詹程傑A9315012 劉博睿A9315018 羅銘福A9315028 簡仲毅A9315048 黃彥博軟體專案計畫書1.專題摘要41.1專案名稱41.2專案目的41.3專案交付範圍41.4專案交付項目51.5專案期程與預算摘要52.專案組織62.1內部架構63. 管理流程規劃73.1專案啟動規劃73.1.1預估計劃73.1.2人力規劃83.1.3資源獲得規劃93.1.4專案人員訓練規劃93.2工作規劃103.2.1工作項目123.2.2時程規劃133.2.3資源規劃143.2.4預算規劃154.技術流程規劃164.1流程模式164.2方法工具與技術174.3基礎建設規劃174.4產品接收規劃175.支援流程規劃185.1風險管理規劃185.2確認與驗證規劃275.3文件製作規劃285.4品質保證規劃295.5審查與稽核規劃295.6問題解決規劃295.7承包商管理規劃295.8流程改善規劃306.附帶事項規劃316.1保固與服務316.2會議記錄33軟體專案計畫書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、校園資訊專用資料庫、JAVA儲值系統學生可以是先向學校購買點數，學校給予一組辨別碼，然後透過手機連結學校的系統儲值，在第一次使用此系統時，學生必須設置一組私人密碼，往後在登錄時，要同時輸入辨別碼及私人密碼，才能夠使用其服務項目，配合其他系統，如點餐系統，購書系統，儲值系統必須包含產生辨別碼，身分認證，餘額管理，資料保密。無無1.1.4. 專案期程與預算摘要 本專案共分三階段並於三百六十日曆天完成本專案之全部工作。 第一階段：於本專案簽約次日起三十日曆天交付專案期初計畫書。 第二階段：於本專案簽約次日起六十日曆天交付系統分析報告、系統設計報告 第三階段：於本專案簽約次日起三百六十日曆天交付系統管理手冊、整合測試報告、教育訓練成果、網頁相關檔案、資料庫程式原始碼及執行碼，並完成基本資料建構。 預算金額：新台幣壹千貳佰萬元整2. 專案組織：2.1. 內部架構專案經理系統整合部門系統測試部門訓練教育部門系統建置維護軟體開發部門硬體部門外包程式分析工程師程式設計工程師美工設計人員系統整合人員系統測試人員教育訓練人員系統建置人員系統維護人員3. 管理流程規劃：3.1. 專案啟動規劃：3.1.1. 預估規劃：於360天內完成所有工作項目：(1) 第一階段：於本專案簽約次日起三十日曆天交付專案期初計畫書：先於校園內評估架設機房，統計資料庫所應建立資料內容與數量，來計畫往後需要多少時間來完成資料庫的建立。(2) 第二階段：於本專案簽約次日起六十日曆天交付系統分析報告、系統設計報告：統計完所需要的資料數量，開始規劃相對應的硬體設備：如硬體需要多少空間容量，硬體資料庫機房建立所需要的空間，手機於校園內的普遍度，各餐廳的配合意願等。(3) 第三階段：於本專案簽約次日起三百六十日曆天交付系統管理手冊、整合測試報告、教育訓練成果、網頁相關檔案、資料庫程式原始碼及執行碼，並完成基本資料建構：依此順序進行工作預估開發雛型:雛型開發方法程序圖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月計總計351093.1.3. 資源獲得規劃：硬體設備：手機：由使用者自備。伺服器：外包廠商。軟體設備：開發工具(JAVA)：軟體工程師自行提供。應用軟體：軟體工程師撰寫伺服器認證：軟體工程師撰寫校園資料庫：校方提供資料，工程師建立介面外觀設計：美工人員預算取得：使用者付費。3.1.4. 專案人員訓練規劃：硬體：外包。軟體：【導覽系統】：在校園各處所拍照，建立詳細的地圖集，與簡略的地圖系統，兩者互相連結。所需時間：14天【消費系統】：聘請校內各個消費部門的廠商，向其工程師說明其營業項目，以及學生和老師的消費型態。所需時間：14天【儲值系統】：聘請專業銀行員，向其說明銀行之存款運作方式。所需時間：14天【公文系統】：聘請校內各行政部門代表，向其說明學校公文發送項目，並提供所需簽名之公文形式。所需時間：14天【認證系統】：參訪各大網站之認證方式，並聘請學校之個人登錄系統設計人員，向其說明登錄認證方式，與以統一。所需時間：14天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美工專案工作規劃 專案生命週期表階段區分系統需求分析系統設計程式製作軟體使用手冊撰寫系統整合測試系統壓力測試輸出說明項目輸入出事項(工作產品)輸入輸出輸入輸出輸入輸出輸入輸出輸入輸出輸入輸出測試或審查.輸出通過準則訪談紀錄審查審查確認軟體需求規格書審查審查確認軟體設計規格書審查審查確認軟體程式原始碼測試符合本案軟體設計規格書軟體使用手冊審查符合本案軟體設計規格書軟體測試報告審查審查確認3.2.1. 工作項目：工 作 項 目時 程負 責 工 作本公司學校1.專案會議每一兩週舉行專案檢討會議專案進度檢討專題討論依雙方約定時間進行專案主持人及相關人員須參加準備會議資料 記錄會議記錄專案承辦人及相關人員須參加準備會議室確認會議記錄內容2.需求訪談依據需求進行訪談提供訪談問卷執行訪談製作訪談記錄依需求進行訪談提供受訪人員名單訪談記錄確認3.軟體需求分析分析軟體功能需求執行分析製作需求分析記錄分析記錄確認4.軟體撰寫依據合約規定執行提供進度確認單依照軟體開發流程 進行軟體撰寫依交付清冊進行審查 5.單元測試依據合約規定執行依合約書所定時程及單元測試準則審合驗收確認單6.系統整合依據本計畫書規定依合約書所定時程執行整合審核整合記錄單7.系統架設依據本計畫書規定依合約書所定時程進行系統架設審核系統架設確認單8.驗收測試依據本計畫書規定依專案時程執行測試及產品驗收準則完成產品交付提供交付清冊進行產品驗收配合硬體及整體環境進行測試審核測試單8.安裝及技術指導依據本計畫書規定安裝前備妥硬體，確認安裝地點及環境安裝及設施提供軟體系統技術指導審核安裝記錄單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安裝及技術指導工作時程完成日期查核點發展過程查核內容預計完成日期1專案啟動階段軟體開發計畫書95/01/152需求分析階段軟體需求規格書95/03/013系統設計階段軟體設計規格書軟體測試計畫書95/06/154系統開發測試階段軟體測試報告94/07/315系統驗收軟體使用手冊軟體執行報告94/11/313.2.3. 資源規劃3.2.4. 預算規劃預算之編列軟體開發應用軟體設計開發金額(新台幣)消費系統60儲值系統45訊息管理系統40認證系統40導覽系統15總計200萬硬體建造與架設：品名數量單價(新台幣)總價(新台幣)伺服主機2台150萬300萬訊息資料庫主機1台10萬10萬儲存裝置1台10萬10萬硬體安裝費XX50萬總計370萬人月成本職稱人數工作人月薪水(新台幣)專案經理1人12七十二萬程式分析師3人9四十五萬程式設計工程師8人32一百二十八萬美工設計人員2人4十六萬系統整合人員5人25一百萬系統測試7人14五十六萬系統安裝3人3九萬系統架設4人8二十八萬教育訓練2人2六萬總計35109四百六十萬4. 技術流程規劃：4.1. 流程模式：認證系統手機學校資料庫伺服器通過結束系統整合導覽系統消費系統儲值系統公文系統繼續YESYESNONO4.2. 方法、工具與技術：作業項目方法技術工具需求分析需求分析方法訪談溝通應用軟體規格描述應用軟體規格檢查MS WordMS Excel系統分析系統設計物件導向模式分析及設計定義需求需求分析系統分析設計Rational Rose手機PC程式撰寫由上往下製作資料設計結構化程式設計使用者介面設計JavaBCB軟體測試白箱測試黑箱測試壓力測試路徑測試條件測試資料流程測試迴圈測試Rational RoseRational TeamTest4.3. 基礎建設規劃：統計資料：建立所有餐廳商店師生資料，於第二階段完成前由校方交付資料硬體設備：於校園內先建立資料處室，擺放資料庫與建立網頁。4.4. 產品接收規劃：(1) 地圖導覽：當系統建立完成之後，之後學校處所,人員資料可能有所變動。因此，當系統完成後，就需要時間來訓練學校行政人員如何建立地圖集與輸入新的人員資料。(2) 消費系統：在店家資料庫建設完畢之後，如有攤位變換或者推出新產品，則會訓練學校相關管理人員，把資料重新載入資料庫使資料處於最新資料。(3)儲值系統:提供學校隨機產生認證碼，由學校自行販賣點數給欲購買之學生或老師，指導校方分門別類建立學生個人帳戶。(4)校園訊息管理系統： 校各處室人員發生職務變更和新聘人員對於系統的操作及熟絡。5. 支援流程規劃：5.1 風險管理規劃：(1) 目的在專案執行期間，針對可能影響專案結果的各種突發狀況，事先界定出潛在因素，以便規劃對應之風險控管計畫及處理原則；在必要時，亦需在軟體開發生命週期內執行各項改善作業，以降低或排除對專案結果有害之風險因子。(2) 責任本流程相關人員所需擔負之責任如下：A. 計畫主持人(A) 指派風險管理人員、風險處理人員。(B) 審查風險降低計畫以及含緊急應變計畫。(C) 監督並掌控風險管理活動之執行。B. 風險管理人員(A) 訂定風險降低計畫以及緊急應變計畫。(B) 執行風險界定與評估、追蹤風險處理結果、執行風險監測。(C) 各組組長為各分項工作的風險管理人員。C. 風險處理人員(A) 負責執行風險降低處理、緊急應變措施等。(B) 風險處理人員主要為各組成員，如需要其他組共同解決則由計畫主持人協調人員處理。D. 允入準則(A) 在專案執行任一時期，需要規劃潛在風險管理計畫與活動時。(B) 當專案執行監控活動中，面臨重要問題或與原計畫偏差而提出可能之潛在風險時。E. 輸入說明專案執行需要之合約、建議書、生命週期之工作產品(例如：軟體設計文件)、相關領域專家之意見，或以往之歷史資料等。F. 作法(A) 風險管理準備專案於規劃階段，風險管理人員必須先確定可能之風險來源並加以分類，同時定義出風險管理投入的控制參數，並據以達成專案預期目標而規劃出專案的風險管理策略，進而作為後續執行分析與評估風險之基礎。流程中各步驟之工作內容說明如下：(1)確定風險來源及類別 風險管理人員可以經由執行所需要之合約、建議書、生命週期之工作產品、專家訪談意見、專案的歷史資料，或者與專案成員經由集體討論之方式，來確定可能之風險來源並建立風險的類別，用以認定與收集風險。 由專案內部或外部來確定可能之風險來源，如不確定的需求、技術可用性、開發者能力或不切實際的時程規劃等來源。 由風險的來源與風險對專案的衝擊加以分類，可分為技術、設計、環境、成本或時程等類別。 風險管理人員須將上述已確定之風險來源及風險類別均記錄於專案風險來源與種類查檢表，如風險來源或風險類別有異動時亦須隨時更新。(2)定義風險參數風險管理人員須依照本流程之風險可能性與影響嚴重性兩項參數分別設定高低等級，用以作為風險評估、風險排序、估計風險控制層級之標準。依照下列之風險可能性評等表，就風險發生的可能機率對可能發生之風險定義高、中、低之評等，必要時，可由相對等級範圍內選定一數值作為優先順序之量化指標。表5-1風險機率量化表可能機率評等準則量化指標低不太可能發生，或出現率在10 %以內0.00.3中可能發生，或出現率在10 50 %之間0.30.7高頻繁發生，或出現率在50%以上0.71.0表5-2風險程度量化表嚴重程度評等準則量化指標低下列情形之一：1. 對達成專案目標影響輕微2. 進度落後10 %以內3. 成本增加10 %以內4. 其他由專案定義為輕度嚴重之條件03中下列情形之一：1. 對達成專案目標影響中等2. 進度落後10 20 %之間3. 成本增加10 25 %之間4. 其他由專案定義為中度嚴重之條件37高下列情形之一：1. 對達成專案目標影響嚴重2. 進度落後20 45 %之間3. 成本增加25 50 %之間4. 其他由專案定義為重度嚴重之條件79極高下列情形之一：1. 無法達成專案目標2. 進度落後45 %以上3. 成本增加50 %以上4. 其他由專案定義為極度嚴重之條件910(3)建立風險管理策略本專案風險管理策略包含下列各項內容：n 風險界定：各組風險管理人員每月填寫專案風險來源與種類查檢表。n 風險分析：各組風險管理人員於專案會議時依據專案風險來源與種類查檢表與計畫主持人討論後，提出專案風險分析表。n 風險降低處理：各組風險管理人員依據風險降低處理對策表提出建議方法與指派風險處理人員進行風險處理。n 風險監測：各組風險管理人員需持續監控風險降低活動的執行方法、完成準則、處理程序或使用之工具。n 執行管制或核准人員的職責由計劃主持人指派。n 風險監測或再評估之時間訂於每週之專案會議。(B) 界定及分析風險於專案進行期間，風險管理人員必須由已確定並記錄之風險來源、風險類別及定義之風險參數，界定出專案所有可能發生之風險，並加以評估、分類；而各項風險所得之風險曝光程度由高至低依序排序後，將風險分析結果填寫於專案風險分析表中，以決定各項風險的相對優先處理順序。流程中各步驟之工作內容說明如下：n 界定風險(a) 風險管理人員經由執行需要之合約、建議書、生命週期之工作產品、專家訪談意見、專案歷史資料，或者與專案成員經由集體討論的方式進行。(b) 由記錄於專案風險來源與種類查檢表之風險來源及風險類別，找出在達成專案目標的過程中所有可能發生之風險。(c) 將所有已確定風險之背景、發生情形、影響的嚴重性等，用簡潔的敘述加以描述並記錄於專案風險分析表n 評估、分類及風險排序對專案風險分析表中每一個已界定之風險，分別根據上述表伍風險可能性評等表及表伍風險嚴重性評等表進行評估作業，並賦予相對的高低等級(定性化)；必要時，亦可賦予相對等級之數值來作為量化指標(定量化)。(a) 每一個已界定風險經由評估作業所取得之評估結果(定性化等級或定量化數值)必須記錄於專案風險分析表。(b) 依照專案風險來源與種類查檢表中已定義之風險類別，對每一個已界定之風險進行分類作業，並將分類結果記錄於專案風險分析表。(c) 由各項風險經過風險評估後之高低等級加以判斷風險曝光程度(risk exposure)，其判斷準則說明如表5-3：表5-3 風險曝光程度表風險曝光程度判斷準則低可能機率為低等且嚴重程度為低等者。中可能機率或嚴重程度均為中等者，或者一項為中等且另一項為低等者均屬之。高可能機率或嚴重程度任一項為高等(含)以上者。(d) 各項風險之風險曝光程度亦可以量化指標呈現，也就是由風險評估所得相對等級之定量化數值加以相乘(風險可能性評等風險嚴重性)而得。(e) 將每一風險所得到之風險曝光程度進行風險排序，並依照由高而低之排列順序將其記錄在於專案風險分析表。(f) 定義執行門檻風險管理人員必須由下列三項設定方式中，視其需要選擇一項做為進行風險降低與追蹤管理之執行門檻： 對於風險曝光程度在中等以上程度之風險。 風險曝光程度之量化指標在2.9(含)以上者計算公式：(30.370.7) / 2。 無論風險曝光程度為值化或量化，只要經風險排序後在前十位者即是。(C) 降低風險專案於風險管理人員界定與評估所有風險後，專案經理應研訂風險管理相關計畫與執行相關風險處理活動，以降低風險的可能性、減少風險發生可能造成的衝擊；尤其對專案可能造成危害的關鍵性風險更應訂定緊急應變計畫，以降低發生時所造成的傷害。流程中各步驟之工作內容說明如下：n 研訂風險降低計畫(a) 對於超過專案所定義執行門檻之每一風險，專案必須執行風險降低處理與追蹤管理，而其他未超過執行門檻之風險則進行簡單的監測即可。(b) 專案經理可參酌下列風險處理方案表，規劃各項風險來源下可能採取之風險降低處理步驟，並將規劃結果記錄於風險降低處理對策表，以提供專案執行風險降低處理之主要參考。如果專案於執行風險降低處理時訂出新的處理步驟時，亦得將新處理步驟更新至風險降低處理對策表中，以做為專案未來執行風險管理之參考。表5-4 風險處理方案表風險處理方案處 理 說 明風險規避改變或降低需求，但仍然符合客戶需要。或者企圖完全降低可能機率及損失程度至零時，所採取之處理行動。風險控制採取主動之步驟，以降低風險為主要目的，較常為專案所採用。風險轉移重新配置設計需求，以降低風險。風險監測觀察及定期對指定風險的改變狀況進行再評估。風險接受風險曝光程度太低，或決定不採取任何處理動作。(c) 若該風險已決定採取風險接受之處理方案時，專案經理必須將其決定的理由記錄於專案風險分析表。(d) 每一必須進行風險降低處理之風險，計畫主持人應由風險降低處理對策表選擇至少一項之風險降低處理步驟，並將其填寫於專案風險分析表之風險降低處理步驟欄位內，做為降低該風險時據以執行之處理步驟。(e) 每一必須進行風險降低處理之風險，專案經理均須指派風險處理人員負責執行風險處理活動，並將人員姓名填寫於專案風險分析表，若人員發生異動時，必須更新該項資料。n 研訂緊急應變計畫(a) 專案經理必須從已界定之風險中，選定可能無法避免且會危害專案的風險做為關鍵性風險，並研訂一份處理關鍵性風險之緊急應變計畫；一但這些風險真正發生時，採取緊急應變措施加以處理與控制，使其降低對專案所造成之嚴重衝擊。(b) 緊急處理過後，必須將處理結果記錄於專案風險監測結果紀錄表，並再次評估是否需要執行風險處理活動，或者進行監測即可。n 執行風險監測與風險降低處理(a) 專案執行期間，風險管理人員必須遵照已規劃之風險管理策略，執行各項風險管理活動，並定期(至少每月一次)監測每一已界定風險之風險狀態及風險處理活動的執行結果，直到專案結案為止。(b) 於執行風險處理活動時，必須設定起始日期及預計完成日期，並記錄該風險處理活動之執行結果，以評估執行績效。(c) 風險管理人員每次進行風險監測的各項結果均須紀錄於專案風險監測結果紀錄表，其中無須進行任何風險處理活動者(只需監測)，僅需記錄風險狀態即可，不必填寫風險處理執行績效之欄位資料。(d) 於發生風險狀態變動與發現新風險時之處理準則如下： 被監測風險之風險狀態有所變動(例如：風險曝光程度的等級上昇或下降)時，必須再次評估是否執行風險處理活動。若風險狀態之變動結果超出專案所訂降低處理之執行門檻時，必須決定或重新選擇因應之風險降低處理步驟；若風險狀態之變動結果低於專案所訂降低處理之執行門檻時，可持續進行監測或由降低處理改為監測即可。 若發現未預料到之新風險時，專案必須依照已規劃之風險管理活動，對新風險進行風險界定、分析與排序，評估是否需要執行風險處理活動，並進行風險監測或選定因應之風險降低處理步驟。G. 允出準則(A) 專案所有可能發生之風險均已界定並完成評估，且降低風險計畫已完成規劃並開始執行。(B) 所有風險均已完成定期監測或執行風險降低處理。(C) 專案結案並且與風險管理相關的度量資料均已蒐集完成。H. 工作產品說明(A) 專案風險來源與種類查檢表以品質記錄方式進行管理。(B) 專案風險分析表以品質記錄方式進行管理。(C) 風險降低處理對策表以品質記錄方式進行管理。(D) 專案風險監測結果紀錄表以品質記錄方式進行管理。圖5-5 專案風險管理流程風險降低處理對策表序號風險來源可採取之風險降低處理步驟01人員缺乏技術性的訓練l 估計一短暫性可容忍之訓練的時間l 提供額外的訓練資源l 研擬專案的特別訓練計畫l 實施技術交流研討會02需求持續性的變動l 從客戶端取得最初確認之需求規格l 使客戶確信需求變動將影響工作時程l 設計一需求變更管理程序l 與客戶商議因需求變動而造成實際影響之報償03不明確的需求l 由經驗與業務邏輯所做的假設必須讓客戶知道，且獲得客戶的確認l 依據取得的需求開發一雛型，讓客戶進行審查與確認04人員短缺l 確定各項人力均分派至專案工作中l 建立專案會議，以掌握工作分派情形。l 專案成員的工作須相互輪調l 保有專案之備援人力l 維護一個人獨立負責工作的產出文件l 嚴格遵照建構管理流程與指引來執行建構管理05迫使專案對外作出緊迫性的決策l 敘述支持此項決策所造成不利損失的事實與數據，以及談成作出此 項決策的個人責任l 假如無法避免的話，界定出實際的風險及實施風險降低計劃06未符合客戶的績效需求l 明確的定義出績效標準，並由客戶進行審查l 設計一符合績效標準之遵循規範l 準備好符合績效的設計計劃，並審查該計劃l 模擬關鍵性交易(transaction)的績效l 儘可能使用具代表性且大量的資料進行測試07不切實際的時程估計與安排l 與客戶溝通一較好的工作時程l 確定平行進行之工作項目l 提早準備專案所需資源l 假如工作時程中未包含關鍵性的工作流程時，須與客戶進行商議l 與客戶商議因此造成實際影響之報償08採用新的軟體、硬體l 考慮分階段交貨l 關鍵性組件先行交貨l 工作時程中需要包含學習所花費的時間l 提供新技術的教育訓練09不足的商業知識l 增加與客戶的互動，並確保可由其中獲得該知識l 組織內實施該知識領域的教育訓練l 模擬客戶的商業交易，並取得客戶的贊同10挽救未履行或較差的績效l 與客戶一起確定可能的預期指標l 預先規劃挽救工作所需之工作量l 規劃出最理想的挽救方法備註 本表格可視實際需求，酌予修改。風險來源及可採取之風險降低處理步驟欄位之資料內容僅為參考範例，於填寫時可視其需求自行增修。5.2 確認與驗證規劃：單元列表規劃客戶參訪軟體開發前參訪客戶，使客戶確認其需求並簽約。廠商訪談在硬體架設前，驗證測試外包廠商產品，測試通過在確認其品質符合要求。軟體撰寫須與客戶做多次需求訪談，確認後則開始單元工作。系統整合當各單元完成工作時，通過PM確認驗證在交由系統整合人員。系統架設架設進行前，須先通過PM確認其他單元完整性，由PM確認後方可架設。驗收測試全部單元完工後，由PM先行確認系統，再轉交給客戶做驗收。安裝及技術指導PM確認系統穩定在交由安裝人員；安裝完成後由指定指導人員教導相關操作。5.3 文件製作規劃：在各階段提出報告文件，依照下列方式文件製作、管理文件種類（依循）管理方式專案依循文件（合約、建議書、專案管理計畫書）專案開發文件管制程序開發（生命週期）文件：需求規格書、系統設計文件建構管理程序非生命週期之文件、紀錄：會議紀錄、訓練資料專案開發文件管制程序相關之監控資料及管制資訊文件管制程序之規定參考文件、資料相關圖書管理規定格式用紙：使用尺寸紙張。繕打方式：除圖表、型錄外，由左至右橫式繕打。裝釘方式：文件應編目錄，加註頁碼，加裝封面，封面上註明本專案名稱及廠商名稱，裝訂線在左側，裝釘成冊。依據合約之規範時程交付下列文件，如下：A. 專案管理計畫書B. 資訊人員基礎教育訓練開課計畫C. 設備建置說明會報告資料D. 平台服務(a) 獨立驗證與確認工作計畫書(b) 平台服務獨立驗證與確認報告(c) 平台服務服務水平報告(d) 應用系統獨立驗證與確認報告(e) 平台服務技術手冊E. 應用系統(a) 軟體開發計畫書(b) 軟體需求規格書(c) 軟體測試計畫書(d) 軟體設計規格書(e) 軟體執行報告(f) 軟體使用手冊(g) 軟體測試報告(h) 軟體壓力測試報告F. 設備操作訓練結案報告G. 應用系統操作訓練結案報告H. 資訊基礎教育訓練結案報告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)管理目標。5 承包工作組織結構。6 工期目標和項目總進度計劃。7 成本目標。8 工程的驗收與測試9 項目風險預測和防範措施。10 變更的授權範圍。承包工程完成確認:1 工程已經竣工驗收。2 與包商合同責任已經履行完畢。3 確認工程已經履行完畢，結束與承包商合同。5.8 流程改善規劃：軟體撰寫、驗收測試、系統整合這幾個階段中，由於可能會有互相需要的關聯性，所以在執行過程中會需要更改流程。故在規劃各階段時，要必須要先預留時間，以應付當行程規劃流程改變時，所增加的額外時間。軟體撰寫時程分為兩項：(1) 撰寫程式時間：對於廠商當初提出的要求，程式設計師對於要求而撰寫的時間。(2) 修改更改程式時間：驗收測試、系統整合階段，會遇到不符合預期的狀況或是廠商新的要求與系統不合的狀況。故因此，必須將此更改時間納入軟體撰寫時程中。6. 附帶事項規劃：6.1 保固與服務(1). 依契約進行保固服務。(2). 服務方式A. 一般維修管理除提供各縣市服務據點報修電話外，亦提供維護報修網站，可區分不同應變中心、故障報修類別、故障項目等，以利登錄及查詢相關處理流程，並可產生統計分析報表。其作業說明如下：圖10-1 維修管理作業流程圖B.電話報修服務本公司勤務中心或各辦事處於接獲報修電話後，即依故障設備之性質派遣相關技術人員前往維修。(3). 保固責任本公司在保固期間所應負之責任如下：A. 本系統如有異常，本公司同意依據口頭、電話或書面通知後提供保固服務。B. 本公司接到異常通知後依據合約保固條款之要求辦理。C. 本公司應偵測異常原因，並須於狀況解決後以書面保固記錄呈送承辦相關人員，作為保固之依據及日後問題追蹤之記錄。6.2 會議記錄10/14 分組日期時間會議內容參加人員10/15 星期五19：00 23：20專案題目訂定 (校園E化系統開發案)PM推選小組人員工作分配專案計劃書內容討論(目的、範圍)10/17 星期日10：2012：0015：0017：30專案計劃書內容討論(交付項目、期程、預算摘要)10/19 星期三期初報告10/20 星期四12：0013：0017：3020：50報告事後檢討廠商聯絡組員溝通、意見提出討論期中報告進度規劃專案計劃書內容討論(組識、流程規劃之啟動規劃、人力規劃)10/22 星期六 08：1511：4015：0018：00專案計劃書內容討論(資源獲得預算規劃)11/12 星期六 09：0012：3014：2017：30報告進度檢視計劃書內容細部修正專案計劃書內容討論(時程規劃技術流程規劃)11/27 星期日10：4012：3016：0019：00計劃書統整計劃書內容細部修正、確認投影片製作11/28 星期日廠商參訪日期決定12/07 星期三19：2022：00期中報告計劃書缺點檢討期末進度規劃專案計劃書內容討論(支援流程規之確認與驗證、文件製作規劃)12/09 星期五廠商參訪日參訪內容整理12/10 星期六09：2012：50前次內容細節修改專案計劃書內容討論(品質保證、審查與稽核規劃)12/17 星期六13：0017：2018：3021：50前次內容細節修改專案計劃書內容討論(問題解決、流程改善規劃、附帶事項規劃)12/29 星期四19：3023：20計劃書統整前次內容細節修改投影片製作參觀廠商：翔威科技 .tw/ 臺北市羅斯福路六段218號10樓 (捷運景美站大樓)34