【正文】 人機界面的美工設計 項目實施計劃項目前期的籌備階段時間較長，目前在需求調研與分析，系統(tǒng)設計，平臺上線方面都有了較多的工作及實際的工作成果。項目組全體成員每周舉行一次內部例會，將本周的各項工作進展以及遇到的困難進行總結和交流，并對下周的工作計劃進行明確。表格5. 溝通計劃列表報告種類責任人提交時間要求發(fā)送對象工作日報項目成員每日下班前小組長小組工作周報小組長每周五下班前項目經(jīng)理項目工作周報項目經(jīng)理每周一中午前客戶項目經(jīng)理項目工作月報項目經(jīng)理每月最后一個工作日下班前客戶項目經(jīng)理會議紀要項目助理會議結束后8個工作小時內與會人員、項目組成員 與客戶的接口由于技術需要，在項目實施過程中有時候需要項目組成員直接與客戶工作人員進行充分的溝通。在項目實施過程中，所有文檔（包括電子件）都應及時歸檔，統(tǒng)一平臺管理。 實施控制的手段項目組將通過以下方法對項目實施進行跟蹤和監(jiān)控：u 每周項目例會。不管是項目例會還是雙方項目經(jīng)理的碰頭會都需要形成相應的會議紀要。u 階段總結。**公司采用Microsoft Project 2003作為項目進度的計劃和跟蹤工具。4. 具體執(zhí)行內容周會是項目實施跟蹤和監(jiān)控的主要執(zhí)行方式，通過周會總結每周的實施情況，提前對某些可能導致項目實施風險的控制因素進行防范，及時發(fā)現(xiàn)問題并調整項目計劃，對于已造成負面影響的情況更加需要亡羊補牢并總結原因。周會由項目經(jīng)理召集，全部項目組成員參與，根據(jù)項目計劃和其他跟蹤資料（按控制標準而制定的跟蹤表，如測試報告、進度報告等），由與會人員總結項目實施情況，并產生相應的會議紀要和對計劃的調整。 變更控制流程變更控制流程簡要描述如下：1. 客戶或**公司一方提出變更申請；2. 將變更申請?zhí)峤辉u審小組作初步審核；3. 項目組對初步審核通過的變更申請進行詳細評估，提交評估報告；4. 評審小組討論評估報告并決定是否接受變更；5. 客戶與**公司對合同進行修改（或補充協(xié)議）；6. 由項目組對變更申請進行實施。評審小組初步審核通過后，將變更申請轉交給項目組進行詳細的影響評估。經(jīng)批準的變更申請將轉給**項目組進行實施，未被批準的變更申請將退還給提出變更的本人。第二層《程序文件》規(guī)定了軟件開發(fā)、系統(tǒng)集成以及專業(yè)技術服務的過程和管理、控制。對于測試過程中的版本的更新，測試負責人記錄并通知所有參加測試人員進行版本更新，每次開始測試前測試人員應檢查測試計算機上的版本是否為最新版本；1 測試中發(fā)現(xiàn)問題應填寫《測試情況反饋表》，反饋表由測試者保留，定期匯總上報項目經(jīng)理；1 每次測試必須填寫《測試報告》，項目經(jīng)理定期向公司提交《測試工作報告》。**公司采用VSS（Visual SourceSafe）作為軟件系統(tǒng)的配置管理工具。配置管理小組由項目負責人領導，配置管理小組成員由各功能小組組長組成。當前開發(fā)階段結束時，將把這個階段的階段產品送入軟件受控庫，同時建立軟件受控庫的副本供下一階段的開發(fā)使用，并建立新的軟件開發(fā)庫。事實上， 系統(tǒng)也將大量采用之前積累的可重用部件。u 操作日志，對于關鍵性的數(shù)據(jù)操作和文檔的上下載，系統(tǒng)提供詳細的操作日志記錄，可以跟蹤數(shù)據(jù)修改的痕跡。在此過程中，**公司將會在提交新版本的同時提交更新說明，包括操作的風險分析和防范措施。在系統(tǒng)從測試平臺經(jīng)過測試并準備轉到正式平臺時，**公司將把測試平臺的數(shù)據(jù)進行清理，有效數(shù)據(jù)將被導出，并確保能正確導入到正式平臺。不管是在內部開發(fā)過程中的版本控制還是正式的版本發(fā)布，這些管理規(guī)范可以有效的確保系統(tǒng)版本的正確性，避免因為版本混亂而導致系統(tǒng)缺陷和數(shù)據(jù)的損壞。u 訪問控制，系統(tǒng)服務器置于移動公司內網(wǎng)上，只有廣東移動和合作伙伴的操作員才能進行直接訪問。u 重用在軟件產品開發(fā)進入試運行階段后，項目經(jīng)理將指定項目的軟件重用主管，軟件重用主管應組織項目組的軟件開發(fā)人員研究分析項目的軟件架構和軟件代碼的重用的可能性，并把可重用的軟件架構、軟件代碼和相關的設計文檔加以規(guī)范，以適應在后續(xù)項目中應用的普遍性。配置管理小組建立并維護軟件庫。u 計劃項目計劃階段，項目經(jīng)理開始編制《配置管理計劃》，軟件產品的開發(fā)應按照《配置管理計劃》的規(guī)定開展配置管理工作。按照項目的質量管理計劃，經(jīng)過多次質量保證流程的循環(huán)，可以在項目組內部有效的控制項目產品的質量，并按計劃在開發(fā)和測試完成之后提交公司技術委員會內部評審，最終只有評審通過的合格系統(tǒng)才能提交給用戶使用，否則需要繼續(xù)改進系統(tǒng)質量，直到系統(tǒng)合格。 系統(tǒng)測試措施質量組將按照制定的質量管理計劃，通過嚴格的測試流程來控制項目產品質量，除開發(fā)小組內部測試外，由測試部門的專職測試人員組成測試小組對系統(tǒng)進行獨立的測試。 質量體系文件**公司編制有質量體系文件，經(jīng)審定后頒布實施。表格6. 變更申請表項目名稱需求變更主題編號提出部門優(yōu)先級別提出人提出日期聯(lián)系電話需求變更描述附件列表：提出人建議的解決方案 變更的評估項目組在接到變更申請的2天內確認已收到變更申請，并在 30天（或規(guī)定的時間）內，對變更申請進行分析研究并填寫評估意見。變更申請需提交給由客戶代表和**項目組代表組成的評審小組。項目經(jīng)理每周需要向用戶提交進度報告和需要協(xié)助的詳細工作說明。以下為**公司項目組內部的周會流程，可以作為雙方例會的參考。因此，需要在制定控制標準時設定多種因素的標準，并平衡這些關鍵因素的作用。**公司項目總監(jiān)將定期對項目提交的績效報告進行審核，并因應項目的進展情況對重新調整的項目計劃進行審批和協(xié)調資源。包括狀態(tài)周報、進度報告和預測。u 會議紀要。 實施過程管理 實施控制的基礎**公司對項目實施的跟蹤和監(jiān)控分為七大類：u 綜合控制；u 范圍控制；u 進度控制；u 成本控制；u 質量控制；u 風險監(jiān)控；u 合同管理。如非特別說明，與客戶的固定接口人為項目經(jīng)理。項目經(jīng)理應與客戶項目經(jīng)理約定每周工作周會的時間安排，并在工作周會前4個工作小時將上周工作報告及下周工作計劃以工作周報形式發(fā)送給客戶項目經(jīng)理。相應的工作會在之前的工作基礎上進一步完善，建議的項目實施計劃如下表所示：表格4. 項目實施計劃序號工作任務完成時間交付物品1項目啟動2006122u 項目實施計劃（MS Project文檔）2需求調研和分析2006128u 軟件需求規(guī)格說明書（Word文檔）3系統(tǒng)概要設計20061212u 系統(tǒng)概要設計說明書（Word文檔）4二維碼電子票業(yè)務平臺上線試運行200616u 用戶操作手冊（Word文檔）u 用戶培訓教材（Powerpoint文檔）u 系統(tǒng)安裝維護手冊（Word文檔）5二維碼電子票業(yè)務平臺初驗2007110u 系統(tǒng)初驗報告（Word文檔）6二維碼電子票業(yè)務平臺終驗2007115u 系統(tǒng)終驗報告（Word文檔）6 項目管理計劃 溝通管理針對項目的實施制定明確的溝通管理計劃，目的在于保證項目相關信息能夠及時產生并得到有效的傳遞，從而建立統(tǒng)一的項目溝通流程和語言，明確項目組每位成員的溝通職責。2005年開始專注于UI設計。1 李毓：2003年畢業(yè)于華南熱帶農業(yè)大學計算機科學與技術專業(yè)，本科，獲工學學士學位。1 李英山：2003年畢業(yè)于華中科技大學計算機科學與技術學院，獲工學學士學位。對底層通信，相關的各類通信協(xié)議以及各類增值應用方面都有豐富的實踐經(jīng)驗及深刻的認識。曾先后擔任程序員、高級程序員、系統(tǒng)分析員、項目經(jīng)理，相關項目管理和開發(fā)經(jīng)驗：廣州移動彩信營銷平臺、東莞移動彩信營銷平臺、順德移動彩信管家系統(tǒng)、廣州移動短信群發(fā)平臺、茂名移動短信互動平臺等。 開放性系統(tǒng)確保具有良好的開放性，所有軟件都應遵循業(yè)界相關標準，支持開放的標準接口，支持跨平臺。系統(tǒng)具有良好的安全管理功能，數(shù)據(jù)存儲、檢索、提取、發(fā)布和管理等各個層面和角度都須具有相應的安全機制，并確保達到以下要求：u 可分級進行權限管理；u 能設置角色權限，可以定義角色以及角色對應的權限；u 提供完整的操作日志，提供數(shù)據(jù)庫存儲日志接口/功能；u 系統(tǒng)本身穩(wěn)定；u 用戶活動的可審計性，提供良好的事后追查能力；u 符合移動IT安全策略和標準；u 系統(tǒng)具備訪問權限的識別和控制功能，提供多級密碼口令或使用硬件鑰匙等選擇和保護措施；u 系統(tǒng)提供操作日志記錄功能，以便即時掌握運行狀況； 可靠性系統(tǒng)運行具有極高的可靠性和良好的容錯性能，因軟件系統(tǒng)自身原因（排除硬件、網(wǎng)絡、數(shù)據(jù)庫、中間件故障）導致系統(tǒng)局部功能短暫不可用的次數(shù)每月平均不超過1次；應用系統(tǒng)MTBF（平均失效間隔時間）部低于2000小時（不包括因網(wǎng)絡、主機硬件