【文章內容簡介】 施 協(xié)助系統(tǒng)的日常維護 豐富的系統(tǒng)管理維護經驗 客戶培訓人員 用戶培訓材料的準備 實施用戶培訓 協(xié)助客戶代表落實新的業(yè)務規(guī)范 豐富的系統(tǒng)實施經驗 豐富的系統(tǒng)培訓經驗 客服人員 負責人工坐席的服務包括GIS 位置查詢與路線導航服務、防盜報警服務 系統(tǒng)維護人員 系統(tǒng)的日程維護 豐富的系統(tǒng)管理維護經驗 跟進回訪人員 客戶的定期走訪 接收客戶投訴 組織客戶投訴的解決 主要項目人員簡介 項目經理 一人 ：有 十 年以上大型項目管理經驗，曾經管理的過千萬的大型綜合業(yè)務系統(tǒng)。專職負責本項目的開發(fā)。本系統(tǒng)建設期間，在接到采購人通知 4 小時內可到達采購人現(xiàn)場處理問題或交流情況。 技術主管 一人 ：具有大型綜合業(yè)務應用系統(tǒng)研發(fā)經驗，主持過多項超過 100萬的項目開發(fā)，本系統(tǒng)建設期間，在接到 客戶方 通知 4 小時內能到達現(xiàn)場處理問題或交流情況。 架構設計師 一人 ：具豐富架構設計、數(shù)據(jù)庫設計經驗，有超過 5 年的數(shù)據(jù)庫設計和架構設計經驗。 以上主要人員將全職參與項目建設。 5 進度管理 進度管理是為了確保項目能按時完成所需的各個過程。 流程圖示 進 度 監(jiān) 控進 度 管 理 進 度 計 劃項 目 執(zhí) 行 人 員項 目 管 理 小 組P M S t e e r i n g確 定 本 項 目 范 圍制 定 項 目 進 度計 劃對 項 目 進 度 計劃 進 行 審 批提 交批 準 與 否修 改 項 目 進 度計 劃否 決發(fā) 布 項 目 進 度計 劃批 準按 進 度 開 展 項目 工 作發(fā) 布每 周 匯 報 工 作進 展 情 況匯 總 項 目 進 度情 況匯 報監(jiān) 控 項 目 進 度項 目 進 度 報 告是 否 受 控受 控匯 報修 改 項 目進 度 計 劃失 控 6 風險管理 風險管理是對項目風險進行識別、分析和應對的系統(tǒng)化工程。它包括把對于項目目標而言正面事件的概率和影響結果擴到最大和把負面事件的概率和影響結果減少到最小。 流程 風 險 管 理 監(jiān) 控風 險 管 理 風 險 管 理 計 劃項 目 管 理 小 組 項 目 執(zhí) 行 人 員P M S t e e r i n g標 識 風 險分 析 項 目 中 可能 產 生 的 風 險確 定 項 目 風 險的 級 別制 定 風 險 管 理計 劃審 批 風 險 管理 計 劃確 立 風 險 管 理計 劃批 準匯 報 風 險 處 理情 況分 析 風 險 被 處理 的 情 況上 報匯 報 風 險 處 理情 況否 決風 險 是 否 被妥 善 處 理是監(jiān) 控 風 險 被 處理 情 況匯 報未 被 妥 善處 理 7 質量管理 我們在開發(fā)項目上按照規(guī)范化軟件的生產方式進行開發(fā)，在開發(fā)流程上采用ISO9000 的標準進行質量管理。我們的質量管理主要包括：質量保證、過程控制和持續(xù)改進三個過程域。 質量保證 —— 貫穿整個項目全生命周期的有計劃和有系統(tǒng)的活動，軟件質量保證工程師定期地針對整個項目質量計劃的執(zhí)行情況進行評估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保項目質量與計劃保持一致。 過程控制 —— 對階段性的成果進行檢測、驗證，為質量保證提供參考依據(jù)。 持續(xù)改進 —— 我們 運用 ISO 管理體系的一個主要思想 PDCA，即為PlanDoCheckAction（計劃－執(zhí)行－檢查－措施），不斷地提高質量，以滿足顧客不斷提高的需要，企業(yè)必須要持續(xù)改進才能持續(xù)獲得顧客的支持。 本系統(tǒng)不僅在一定程度上反映工商管理政府機關的信息化建設的水平，還代表著政府的形象。因此，質量問題是值得重視的，對于本項目來說，尤其是擁有大量的初級 開發(fā)人員來說也是至關重要的?？紤]到質量的重要性，為此我們專門制定 了嚴格的質量管理的規(guī)范和質量管理制度體系。 8 項目管理的特點 基于 RUP的軟件開發(fā)流程 本次項目使用了基于 RUP 的迭代開發(fā)方法 迭代開發(fā)的優(yōu)勢 由于項目核心開發(fā)人員水平很高，因此可以 更早提交演示版本，協(xié)助用戶盡早了解系統(tǒng)的本質 ，確定系統(tǒng)需求，為后期的增量和業(yè)務價值的增長提供足夠的空間 ： 需求變更一直是項目中導致交付的系統(tǒng)質量低下、延期交付、令客戶不滿意和使開發(fā)人員泄氣的主要原因。盡可能早地確定用戶的主要需求，是解決上述問題的關鍵。使用迭代開發(fā)方法項目團隊在項目開發(fā)的早期花費較少的時間，就可以關注關鍵的需求，并且生成可以演示的可執(zhí)行軟件，這樣可以協(xié)助用戶盡早了解系統(tǒng)的本質。 系統(tǒng)多次集成，獲得較高的質量： 系統(tǒng)經過多次的迭代，多次 的集成，核心模塊經過多次的測試，更早地發(fā)現(xiàn)系統(tǒng)的缺陷，從而可以更好地保證交付的系統(tǒng)質量。 良好的風險管理： 通過迭代開發(fā)方法，項目團隊可以在早期的迭代中體驗事先制定的風險應對措施的實際效果，并及時調整風險應對計劃。 持續(xù)改進的開發(fā)過程： 迭代末尾的評估不僅能夠從計劃方面揭示項目的狀態(tài)；同時也可以幫助項目經理分析在下一個迭代中如何改進項目的組織結構和過程。 我們 的軟件開發(fā)流程，就是基于 RUP 的迭代開發(fā)的思想，并結合我們多年的軟件開發(fā)實踐經驗，定制而成的。 開發(fā)流程簡介 本項目 的軟件生命周期分為開始、細化、構建 和移交四個階段，并且根據(jù)實際項目的需要采用不同次數(shù)的迭代，每一次迭代中都包括從業(yè)務建模到部署等主要的開發(fā)過程。具體可以見下圖。 系統(tǒng)開始階段：我們是要所有項目關系人對實現(xiàn)項目的目標的所有關鍵因素達成共識。包括項目團隊會明確的說明項目的規(guī)模，計劃和準備工作的安排，項目的架構選型，項目設計和重用，從而合理的估算出項目的成本，進度和資源。 系統(tǒng)細化階段：我們會建立系統(tǒng)架構的基線。項目團隊會快速確定項目的架構，確認架構和建立架構基線，制訂詳細的迭代計劃，同時會對不合理的開發(fā)案例和架構進行改進。 系統(tǒng)構建階段：我 們會闡明剩余的 需求 ，并基于已建立基線的架構完成系統(tǒng)開發(fā)。項目團隊會合理安排資源，控制資源和優(yōu)化過程，對完成的開發(fā)工作按照評估標準進行測試，并對項目發(fā)布進行評估。 系統(tǒng)移交階段：我們會按照用戶反饋調整系統(tǒng)配置、安裝和可用性問題。項目團隊會按照部署計劃對項目進行部署，在開發(fā)現(xiàn)場測試已交付的產品，使最終用戶可以使用此系統(tǒng)。 項目開發(fā)流程 迭代開發(fā)過程分為 6 個核心過程和 3 個核心支持過程。核心過程包括業(yè)務建模、需求、分析、設計、實現(xiàn)和測試。支持過程包括項目管理、變更配置管理和開發(fā)規(guī)范。 業(yè)務建模 (Business Modeling) 項目團隊通過業(yè)務建模過程了解目標組織的結構和機制，了解目標組織中存在的問題并確定改進的可能性，從而確?？蛻?、最終用戶和開發(fā)人員就項目目標達成共識。同時基于這個共識在商業(yè)用例模型和商業(yè)對象模型中定義項目的過程，角色和責任。具體流程請見下圖： 關鍵流程： 評估業(yè)務狀態(tài)：業(yè)務流程分析員和用戶代表小組通過一系列的研討完成對客戶方組織的業(yè)務狀態(tài)評估。 確定業(yè)務流程：業(yè)務流程分析員在業(yè)務研討會上確定業(yè)務術語并概括出業(yè)務用例和業(yè)務主角。 設計業(yè)務流程的實現(xiàn)：業(yè)務流程分析員會根據(jù)項目的業(yè)務建模規(guī)范要求確定業(yè)務中的所有角色、可交付工件和系統(tǒng)業(yè)務要求， 并通過統(tǒng)一規(guī)范的語言詳細說明業(yè)務角色和業(yè)務實體是如何通過執(zhí)行業(yè)務用例來實現(xiàn)的。 評審業(yè)務流程：項目經理會組織用戶代表小組和業(yè)務專家等相關人員對實現(xiàn)的業(yè)務流程設計以及是否符合項目業(yè)務建模規(guī)范進行評審。通過評審會正式核實業(yè)務對象建模的結果是否符合真實的業(yè)務需要。 業(yè) 務 建 模 流 程業(yè) 務 流 程 評 審 員業(yè) 務 流 程 分 析 員評 估 業(yè) 務 狀 態(tài)確 定 業(yè) 務 流 程設 計 業(yè) 務 流 程 的 實現(xiàn)評 審 業(yè) 務 流 程 輸出文檔和工件： 1. 業(yè)務規(guī)范 2. 業(yè)務架構文檔 3. 業(yè)務模型 需求管理 (Requirements) 項目團隊通過需求管理過程來描述系統(tǒng)應該做什么，并 使開發(fā)人員和用戶就這一描述達成共識。為了達到該目標，項目團隊會對需要的功能和約束進行提取、組織、文檔化。經過需求過程后，項目團隊會形成用例模型，利用用例模型可以有效地界定系統(tǒng)范圍及其行為，并同時得到用戶和開發(fā)人員的認同。用例作為分析與設計過程的輸入，是實現(xiàn)分析與設計模型的基礎。項目團隊通過用例模型使設計模型能夠實現(xiàn)用例模型所定義的功能。同時，在測試流中運用用例模型組成了測試實例，幫助項目團隊的測試人員有效地校驗整個系統(tǒng)的正確性。具體流程請參看下圖： 關鍵流程： 1. 分析需求：系統(tǒng)分析員提煉，分析和仔細審查已 收集到的需求，以確保所有的風險承擔者都明白其含義并找到其中的錯誤，遺漏或其他不足的地方。 2. 編寫需求規(guī)格說明書：系統(tǒng)分析員用標準使用實例模板編寫需求規(guī)格說明書。在需求規(guī)格說明書中包含了軟件的功能需求和非功能需求。系統(tǒng)分析員會根據(jù)需求編寫規(guī)范確保需求規(guī)格說明書的統(tǒng)一風格，使讀者能明白怎樣解釋它。 3. 需求評審：項目經理對于已經完成的需求規(guī)格說明書組織一個有不同代表組成的專家小組。專家會根據(jù)需求編寫規(guī)范對需求規(guī)格說明書的內容、風格、形式以及相關模型進行仔細的檢查。 輸出文檔和工件： 1. 軟件需求說明書 2. 數(shù)據(jù)要求說明書 3. 術語表 需 求 管 理 流 程變 更 控 制 經 理需 求 評 審 人 員系 統(tǒng) 分 析 員了 解 干 系 人 的 需 求編 寫 需 求 說 明 書分 析 需 求評 審 是 否 通 過用 戶 方 和 開 發(fā) 方 就需 求 進 行 簽 字 確 認確 定 項 目 的 范 圍不 確 認需 求 變 更 管 理確 認 4. 需求模型 分析和設計 (Analysis amp。 Design) 項目團隊通過分析和設計過程將需求轉化成未來系統(tǒng)的設計，為系統(tǒng)開發(fā)一個健壯的結構并調整設計使其與實現(xiàn)環(huán)境相匹配，并優(yōu)化其性能。分析設計的結果是一個設計模型和一個可選的分析模型。設計模型是源代碼的抽象，由設計類和一些描述組成。設計類被組織成具有良好接口的設計包和設計子系統(tǒng)，而描述則體現(xiàn)了類的對象如何協(xié)同工作實現(xiàn)