2022年軟件項(xiàng)目實(shí)施方案書模板（投標(biāo)版）(完整版)

1、軟件項(xiàng)目實(shí)施方案書模板（投標(biāo)版）目錄 TOC o 1-5 h z 第1章 工程實(shí)施方案51概述51.2項(xiàng)目人員組織61.2.1組隊(duì)模型61.2.2管理人員設(shè)置91.2.3項(xiàng)目組成員101.2.4項(xiàng)目分工界面101.3項(xiàng)目過程模型111.3.1過程模型131.3.2敏捷開發(fā)理念151.3.3版本迭代模式181.4項(xiàng)目進(jìn)度管理191.4.1項(xiàng)目進(jìn)度規(guī)劃191.4.2項(xiàng)目進(jìn)度控制211.5項(xiàng)目質(zhì)量管理231.5.1質(zhì)量管理體系231.5.2質(zhì)量管理措施241.5.3質(zhì)量控制流程251.5.4項(xiàng)目變更管理261.6項(xiàng)目溝通協(xié)調(diào)281.6. 1溝通措施281.6.2沖突因素291.6.3解決沖突311.

2、7項(xiàng)目風(fēng)險管理331.7.1風(fēng)險評估341.7.2風(fēng)險應(yīng)對351.7.3風(fēng)險跟蹤371.7.4風(fēng)險管理組織381.7.5 小結(jié)391.8項(xiàng)目現(xiàn)場管理40第2章 測試驗(yàn)收方案431驗(yàn)收標(biāo)準(zhǔn)431. 1功能項(xiàng)測試431.2業(yè)務(wù)流程測試432. 1.3容錯測試432. 1.4安全性測試442. 1.5性能測試442. 1.6易用性測試442. 1.7適應(yīng)性測試452. 1.8文檔測試452. 1.9用戶有特別要求的測試452.2測試用例編寫方案及標(biāo)準(zhǔn)462. 2. 1編寫原則462. 2.2衡量測試用例設(shè)計(jì)的質(zhì)量標(biāo)準(zhǔn)472. 2.3測試用例與開發(fā)的對應(yīng)關(guān)系約定472. 2.4測試用例類型約定482.

3、 2.5測試階段、類型與執(zhí)行角色的關(guān)系約定492. 2.6測試用例清單502.3測試策略502. 3.1數(shù)據(jù)和數(shù)據(jù)庫完整性測試502. 3.2接口測試512. 3.3集成測試522. 3.4系統(tǒng)測試542. 3.5用戶界面測試552. 3.6壓力測試562. 3.7負(fù)載測試582. 3.8強(qiáng)度測試592. 3.9容量測試622. 3. 10安全性和訪問控制測試632. 3. 11配置測試652. 3. 12安裝測試662. 3. 13文檔測試672.4項(xiàng)目的交付項(xiàng)682. 4. 1程序682.4.2需求覆蓋682. 4.3文檔742.5測試工具766驗(yàn)收方式762.7成績評定標(biāo)準(zhǔn)76第3章技術(shù)

4、服務(wù)方案781服務(wù)范圍783.2服務(wù)方式及內(nèi)容782. 1駐場+現(xiàn)場服務(wù)782.2遠(yuǎn)程支持793.3故障處理流程813.4軟件升級83第4章 技術(shù)培訓(xùn)方案851培訓(xùn)的對象及目標(biāo)854.2培訓(xùn)時間及人數(shù)864.3培訓(xùn)方式及內(nèi)容86第1章工程實(shí)施方案概述項(xiàng)目管理和實(shí)施，有著許多成熟的理論和方法，但是針對不同的 項(xiàng)目，不同的環(huán)境，一定需要靈活地應(yīng)用才能取得良好的效果。XXX 信息網(wǎng)有限公司有多年的電信項(xiàng)目的實(shí)施管理經(jīng)驗(yàn)，針對本項(xiàng)目的特 點(diǎn)，提出了針對性的項(xiàng)目實(shí)施和管理的方案。XXX信息技術(shù)有限公司提出的本項(xiàng)目實(shí)施方案，是在借鑒和參考 微軟解決方案（Microsoft Solutions Framew

5、orks,以下簡稱 MSF） 以及敏捷開發(fā)的核心理念的基礎(chǔ)上，根據(jù)以往長期與電信合作的大量 項(xiàng)目實(shí)例的經(jīng)驗(yàn)總結(jié)，形成的一套適合于軟件行業(yè)業(yè)務(wù)發(fā)展以及工程 建設(shè)規(guī)范的項(xiàng)目實(shí)施與管理方案。針對上述的實(shí)際情況,XXX信息技術(shù)有限公司在本項(xiàng)目的組織上, 在資源的組織和配置上，參考了 MSF的組隊(duì)模型進(jìn)行項(xiàng)目團(tuán)隊(duì)的組 建，從而確保用于項(xiàng)目的資源是充足完備的，使得項(xiàng)目開發(fā)的重要質(zhì) 量指標(biāo)得到有效的保障；在過程管理上，在MSF的基礎(chǔ)上，更多地應(yīng) 用敏捷開發(fā)的快速發(fā)布原則，通過盡早的、持續(xù)的交付有價值的軟件 來使客戶滿意，使得開發(fā)周期盡可能縮短并能滿足xxx業(yè)務(wù)開展的需 要；在需求變更的管理上，充分體現(xiàn)敏捷開

6、發(fā)的擁抱變化的理念，通 過不斷的版本發(fā)布和與使用者的密切溝通，使得發(fā)布的版本不斷地趨 向用戶的需求。但是在實(shí)際的操作中，采用以周為周期的螺旋式版本 迭代，而不是簡單采用敏捷開發(fā)每天發(fā)布的原則，盡量使版本推出趨 近用戶的需求，同時又減少對客戶工作時間的占用。項(xiàng)目人員組織XXX信息技術(shù)有限公司參考了 MSF的組隊(duì)模型，將此次在線客服 平臺項(xiàng)目中不同階段的工作人員分為六個角色，通過這六個角色，項(xiàng) 目可以得以迅速、完善地實(shí)施。這也體現(xiàn)了項(xiàng)目開發(fā)的六個重要質(zhì)量 指標(biāo)。1.2.1組隊(duì)模型本項(xiàng)目的組隊(duì)模型如下圖所示：組隊(duì)模型由六個角色構(gòu)成，這六個角色分別是：產(chǎn)品經(jīng)理。由最終用戶或懂業(yè)務(wù)的人員擔(dān)任這一角色，建

7、議 由XXX方的項(xiàng)目負(fù)責(zé)人擔(dān)任。產(chǎn)品經(jīng)理在項(xiàng)目進(jìn)行的全過程 中，始終代表著最終用戶的利益，反映最終用戶的要求。擔(dān) 任這一角色的人員可以不是技術(shù)人員。但是他必須了解用戶 需求，明確用戶的需求以及需求的期望值。之所以強(qiáng)調(diào)用 戶需求的期望值，是因?yàn)橛脩舻纳虡I(yè)化特征比較強(qiáng)，需求 無盡，無法界定到底如何才算需求得到了滿足。而確定了 需求期望值后，用戶的商業(yè)目的就非常明確，實(shí)施起來也 比較順暢。項(xiàng)目經(jīng)理。項(xiàng)目經(jīng)理是一個交流與協(xié)調(diào)的角色，也是進(jìn)行程 序開發(fā)管理的角色，建議由XXX信息技術(shù)有限公司富有經(jīng)驗(yàn) 的高級項(xiàng)目管理人員擔(dān)任。需要完成基于應(yīng)用系統(tǒng)的業(yè)務(wù)需 求文檔以及目標(biāo)和范圍文檔，設(shè)計(jì)、管理和維護(hù)程序的功

8、能 說明。項(xiàng)目經(jīng)理負(fù)責(zé)所有與分析、定義系統(tǒng)結(jié)構(gòu)的管理任 務(wù)。在開發(fā)人員的配合下，項(xiàng)目經(jīng)理必須確保功能說明在現(xiàn) 有的資源（時間、人力）下，技術(shù)上是可以實(shí)現(xiàn)的。項(xiàng)目經(jīng) 理需要具有很強(qiáng)的技術(shù)能力，以便與開發(fā)人員相配合作出關(guān) 鍵的決策。他們需要理解項(xiàng)目體系結(jié)構(gòu)的實(shí)質(zhì)，他們常常是 項(xiàng)目組中最有經(jīng)驗(yàn)的成員。項(xiàng)目經(jīng)理必須跟蹤負(fù)責(zé)整個項(xiàng)目 的進(jìn)展。他負(fù)責(zé)制定計(jì)劃，每天找出完成該計(jì)劃的風(fēng)險所 在，排除風(fēng)險，每天交付應(yīng)該完成的內(nèi)容，確保計(jì)劃按 質(zhì)、按量實(shí)施。程序開發(fā)。開發(fā)者在開發(fā)前期就參與用戶需求分析和項(xiàng)目 計(jì)劃制定，他最清楚具體的開發(fā)過程。在開發(fā)期開始后， 他負(fù)責(zé)進(jìn)行代碼開發(fā)，在每一個階段，交付每一項(xiàng)內(nèi)容的 代

9、碼。用戶培訓(xùn)。用戶培訓(xùn)的任務(wù)是通過應(yīng)用系統(tǒng)的演示和培 訓(xùn)，盡可能地使最終用戶在使用系統(tǒng)時能充分利用系統(tǒng)所 提供的功能。用戶培訓(xùn)的第二個任務(wù)是通過編寫使用文 檔，使應(yīng)用系統(tǒng)更容易被用戶理解和使用，降低整個系統(tǒng) 技術(shù)支持的費(fèi)用。作為系統(tǒng)的最初使用者，用戶培訓(xùn)應(yīng)參 與系統(tǒng)和用戶界面原型的設(shè)計(jì)和構(gòu)造，也參與包括程序的 安裝部分的設(shè)計(jì)。伴隨系統(tǒng)的開發(fā)過程，用戶培訓(xùn)要根據(jù) 開發(fā)進(jìn)度完成文檔或電子聯(lián)機(jī)文檔。如果需要的話，用戶 培訓(xùn)還要準(zhǔn)備并交付系統(tǒng)的培訓(xùn)材料。系統(tǒng)測試。測試的任務(wù)是保證應(yīng)用系統(tǒng)交付之前，能夠發(fā) 現(xiàn)所存在的問題。測試要準(zhǔn)備測試計(jì)劃、測試規(guī)定和測試 的案例，這些文檔用于有計(jì)劃和目的地進(jìn)行測試。測

10、試這 種角色必須獨(dú)立于開發(fā)，而且測試不僅僅是代碼方面的， 同時它還還應(yīng)用在功能規(guī)定、系統(tǒng)的性能、用戶界面和系 統(tǒng)實(shí)施等方面。部署實(shí)施。該角色規(guī)劃和進(jìn)行系統(tǒng)的安裝實(shí)施，完成硬件 和軟件的規(guī)劃、定貨、采購和安裝，并且負(fù)責(zé)將開發(fā)出來 的代碼在測試的或者生產(chǎn)的環(huán)境進(jìn)行部署，使得交付的成 果可以面向用戶提供使用，同時根據(jù)系統(tǒng)設(shè)計(jì)的部署策 略，實(shí)現(xiàn)系統(tǒng)設(shè)計(jì)所需要的容錯、冗余、可靠性等要求。在本次項(xiàng)目的團(tuán)隊(duì)中，這六個角色將分別由代表客戶的XXX 方人員和代表開發(fā)方的XXX信息技術(shù)有限公司成員擔(dān)任，共同組 成本次項(xiàng)目的項(xiàng)目團(tuán)隊(duì)。1.2.2管理人員設(shè)置根據(jù)本項(xiàng)目的實(shí)際情況，XXX信息技術(shù)有限公司建議項(xiàng)目組的管理

11、人員設(shè)置如下：角色管理人員安排主僕砸XXX主管領(lǐng)導(dǎo)、XXX信息技術(shù)有限公司分管領(lǐng)導(dǎo)產(chǎn)品管理客服中心項(xiàng)目經(jīng)理項(xiàng)目管理XXX信息技術(shù)有限公司項(xiàng)目經(jīng)理開發(fā)組XXX信息技術(shù)有限公司高級程序 員、架構(gòu)師測試組XXX信息技術(shù)有限公司專業(yè)測試經(jīng)理角色管理人員安排客服中心業(yè)務(wù)經(jīng)理用戶培訓(xùn)XXX信息技術(shù)有限公司培訓(xùn)經(jīng)理質(zhì)量管理XXX客服中心領(lǐng)導(dǎo)、XXX信息技術(shù)有限公司分管領(lǐng)導(dǎo)系統(tǒng)實(shí)施和維護(hù)XXX信息技術(shù)有限公司維護(hù)支撐經(jīng)理深圳XXX客服中心技術(shù)支撐經(jīng)理1.2.3項(xiàng)目組成員 1.2.4項(xiàng)目分工界面項(xiàng)目組成員在項(xiàng)目中的分工界面如上所示，XXX信息技術(shù)有限公 司的項(xiàng)目組成員將主要負(fù)責(zé)：1、系統(tǒng)技術(shù)架構(gòu)：根據(jù)技術(shù)規(guī)范和

12、技術(shù)方案的要求進(jìn)行系統(tǒng) 技術(shù)架構(gòu)設(shè)計(jì)2、程序開發(fā)：完成xxx相關(guān)業(yè)務(wù)需求的功能開發(fā)3、程序管理：針對開發(fā)的程序源碼進(jìn)行管理4、發(fā)布管理：針對發(fā)布的程序的版本進(jìn)行管理5、平臺部署：在xxx提供的服務(wù)器上安裝部署平臺軟件，測 試組人員負(fù)責(zé)測試，開發(fā)人員負(fù)責(zé)修復(fù)bug,測試通過后通知 XXX項(xiàng)目經(jīng)理6、平臺上線：負(fù)責(zé)業(yè)務(wù)上線前的基礎(chǔ)數(shù)據(jù)配置、平臺相關(guān)使 用人員的培訓(xùn)，并在上線初期提供10個工作日的現(xiàn)場技術(shù)支 持7、平臺運(yùn)維：負(fù)責(zé)對平臺的監(jiān)控，出現(xiàn)性能下降等問題應(yīng)及 時給出解決方案及分析報(bào)告xxx項(xiàng)目經(jīng)理、業(yè)務(wù)人員等項(xiàng)目組成員主要負(fù)責(zé)業(yè)務(wù)規(guī)劃指導(dǎo)、 產(chǎn)品管理、測試、用戶體驗(yàn)等工作，雙方在業(yè)務(wù)及技術(shù)架構(gòu)

13、設(shè)計(jì)、 測試、用戶體驗(yàn)、發(fā)布等環(huán)節(jié)仍會有較多的交叉和交互，但是工作 重點(diǎn)則有所不同。按在線客服平臺的硬件、軟件要求提供相關(guān)資 源，并提供網(wǎng)絡(luò)所需訪問的端口、帶寬、電力以及機(jī)柜空間等供平 臺使用。項(xiàng)目過程模型在過程管理上，在MSF的基礎(chǔ)上，xxx信息技術(shù)有限公司將更多 地應(yīng)用敏捷開發(fā)的快速發(fā)布原則，通過盡早的、持續(xù)的交付有價值的 軟件來使客戶滿意，使得開發(fā)周期盡可能縮短并能滿足民生業(yè)務(wù)開展 的需要。本項(xiàng)目的過程模型，以微軟的MSF過程模型為主線，吸收敏捷開 發(fā)的核心理念，把傳統(tǒng)的瀑布模型和螺旋模型的概念結(jié)合起來，并利 用了兩者各自的長處。項(xiàng)目的過程模型把瀑布模型基于里程碑的規(guī)劃 的優(yōu)勢與螺旋模型

14、不斷增加的反復(fù)項(xiàng)目交付內(nèi)容的長處結(jié)合了起來， 既能達(dá)到按里程碑階段性到達(dá)規(guī)劃目標(biāo)，同時又能擁抱變化，使成果 更能接近用戶的需求，并且能夠在更短的時間內(nèi)達(dá)到目標(biāo)。在需求變 更的管理上，充分體現(xiàn)敏捷開發(fā)的擁抱變化的理念，通過不斷的版本 發(fā)布和與使用者的密切溝通，使得發(fā)布的版本不斷地趨向用戶的需求。 但是在實(shí)際的操作中，采用以周為周期的螺旋式版本迭代，而不是簡 單采用敏捷開發(fā)每天發(fā)布的原則，使版本的推出盡量趨近用戶的需求, 同時又減少對客戶工作時間的占用。1.3.1過程模型等四個主要的里程碑，每個里程碑都是一個階段的終結(jié)點(diǎn)。預(yù)想和構(gòu)思階段在“范圍核準(zhǔn)”里程碑上到達(dá)了終結(jié)點(diǎn)。一旦一 個新的產(chǎn)品（在信息

15、基礎(chǔ)設(shè)施實(shí)現(xiàn)的項(xiàng)目中，這樣的產(chǎn)品可能是某項(xiàng) 服務(wù)）吸引了大家的興趣并得到了允許構(gòu)建的批準(zhǔn)后，項(xiàng)目組開始集 中起來定義產(chǎn)品。前景描述文檔清晰地闡明了產(chǎn)品或服務(wù)的最終目標(biāo), 并提供了明確的方向。設(shè)計(jì)階段在“設(shè)計(jì)核準(zhǔn)”里程碑上到達(dá)了終結(jié)點(diǎn)。項(xiàng)目設(shè)計(jì)包含 功能規(guī)定文檔、每種角色職能組的計(jì)劃組合（包括的開發(fā)、測試、用 戶培訓(xùn)、系統(tǒng)實(shí)施、項(xiàng)目經(jīng)理和產(chǎn)品管理）和時間進(jìn)度安排。功能規(guī) 定提供給項(xiàng)目組足夠的細(xì)節(jié)情況確定需要的資源并作出承諾。在項(xiàng)目 設(shè)計(jì)核準(zhǔn)里程碑上，客戶和項(xiàng)目組在要交付的內(nèi)容上及如何進(jìn)行構(gòu)建 達(dá)成一致。這是一個重新評估風(fēng)險、建立優(yōu)先級和對時間進(jìn)度和資源 調(diào)配情況做最終估計(jì)的非常重要的機(jī)會。開發(fā)階

16、段在“范圍完成/第一次使用里程碑上到達(dá)了終結(jié)點(diǎn)。經(jīng)過核準(zhǔn)的功能規(guī)定和相關(guān)的項(xiàng)目計(jì)劃提供了開始開發(fā)的基準(zhǔn)線。開 發(fā)組設(shè)置了一系列內(nèi)部交付的里程碑，每個內(nèi)部里程碑都要經(jīng)過全部 的測試/診斷/排錯的過程。在這個里程碑上客戶和項(xiàng)目組評估產(chǎn)品的 功能，驗(yàn)證產(chǎn)品過渡和支持計(jì)劃。同樣在這個里程碑上，所有新功能 的開發(fā)都已經(jīng)結(jié)束，推遲開發(fā)的功能記錄下來作為下一個版本功能的 參考穩(wěn)定階段在“產(chǎn)品發(fā)布”里程碑上到達(dá)了終結(jié)點(diǎn)。測試工作是伴 隨著代碼開發(fā)工作進(jìn)行的，在穩(wěn)定階段因?yàn)榧凶⒁饬τ趯ふ义e誤和 修改錯誤，所以測試活動成為主要的工作。在產(chǎn)品發(fā)布里程碑，產(chǎn)品 正式轉(zhuǎn)交給操作和支持組。通常情況下，項(xiàng)目組或者開始下一

17、個版本 的產(chǎn)品開發(fā)，或者拆散加入其它的項(xiàng)目開發(fā)組。版本1版本2版本3此過程模型鼓勵項(xiàng)目組將正在開發(fā)中的項(xiàng)目，想象成為一個產(chǎn)品, 將新特色的開發(fā)和舊特色的維護(hù)作為不同版本的發(fā)布。這種概念會影 響如何設(shè)定期望，以及整個項(xiàng)目如何設(shè)計(jì)、規(guī)劃和管理。第一個版本 的發(fā)布交付了一系列核心特色。隨后的版本發(fā)布逐漸增加新的特色， 直到完成了產(chǎn)品的全部前景和期望。不同的版本發(fā)布不一定需要前后 銜接（也就是版本1發(fā)布后，版本2才開始）。1.3.2敏捷開發(fā)理念敏捷開發(fā)是一種思維方式和軟件過程方法論，敏捷開發(fā)的核心理 念包括：1）注重概念和架構(gòu)設(shè)計(jì)，而輕詳細(xì)設(shè)計(jì)敏捷開發(fā)中，注重概念和架構(gòu)設(shè)計(jì)，而輕詳細(xì)設(shè)計(jì)。這里的概念

18、設(shè)計(jì)，可以看成是為什么要做這個產(chǎn)品或模塊，強(qiáng)調(diào)的是產(chǎn)品的路線 規(guī)劃、市場趨勢、客戶價值、技術(shù)趨勢等。架構(gòu)設(shè)計(jì)，可以看成從整 體上看，概念設(shè)計(jì)應(yīng)該用什么方式實(shí)現(xiàn)、分幾個層次、多少組件、不 同層次和組件之間關(guān)系是什么。詳細(xì)設(shè)計(jì)，則是具體的設(shè)計(jì)和做法、 API接口等。2）SWOT分析在敏捷開發(fā)中，更加注重客戶需求。如果對產(chǎn)品進(jìn)行SWOT分析， 就能選出付出最小工作量，但能獲得最大價值的模塊。SWOT分析階段會在概念設(shè)計(jì)和架構(gòu)設(shè)計(jì)之后進(jìn)行，輸入是概念 設(shè)計(jì)和架構(gòu)設(shè)計(jì)，輸出是模塊的重要度和需要的時間。這樣按照性價 比可以進(jìn)行排序，選出最能符合市場的模塊。3）業(yè)務(wù)和客戶驅(qū)動，而非技術(shù)驅(qū)動在產(chǎn)品的敏捷開發(fā)中

19、，雖說擁抱變化，但不盲目變化。產(chǎn)品的改 動需要經(jīng)過概念設(shè)計(jì)、架構(gòu)設(shè)計(jì)以及SWOT分析后，三思而后行。敏 捷開發(fā)中也強(qiáng)調(diào)”在整個項(xiàng)目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天 天都在一起工作”，確保技術(shù)人員能夠開發(fā)出客戶需要的產(chǎn)品。4）時刻考慮版本兼容性敏捷開發(fā)，廢除了過多冗余的文檔和繁雜的設(shè)計(jì)，強(qiáng)調(diào)擁抱變化。 但作為產(chǎn)品，敏捷開發(fā)不意味著盲目地去變化。當(dāng)設(shè)計(jì)變動、API接口重構(gòu)、配置文件變更時，要時刻考慮產(chǎn)品 的架構(gòu)、規(guī)劃路線圖，老版本的兼容性，及遷移平滑性。否則，隨著 版本的增多，必將面對著大量的維護(hù)工作。5）輕文檔，但非無文檔敏捷開發(fā)強(qiáng)調(diào)溝通的重要性，而輕冗余文檔。但敏捷開發(fā)并不意 味著無文檔。在

20、敏捷開發(fā)過程中，適量的文檔還是很有幫助，有助于 整理思路，加快溝通和討論。我們產(chǎn)品中的文檔包括：概念設(shè)計(jì)文檔、 架構(gòu)圖、當(dāng)前版本要實(shí)現(xiàn)的功能列表，以及SWOT分析。這些文檔在 每個產(chǎn)品版本開始之前會有產(chǎn)生，在每個迭代的過程中根據(jù)業(yè)務(wù)人員 和市場的反饋也會有一些變更。通過我們實(shí)踐證明，這對產(chǎn)品的思路、 溝通討論都非常有幫助。而且這些文檔，大多是幾頁P(yáng)PT,書寫和維 護(hù)工作都很小。敏捷開發(fā)的優(yōu)點(diǎn)，下面是其中幾點(diǎn)：1、市場和需求驅(qū)動，擁抱變化在產(chǎn)品敏捷開發(fā)中，每個迭代結(jié)束，都會有一個產(chǎn)品迭代演示會, 把這個月的開發(fā)結(jié)果演示給組員、業(yè)務(wù)人員、售前，甚至客戶，并收 集反饋。此外，在開發(fā)的過程中，產(chǎn)品的業(yè)

21、務(wù)人員和售前時刻保持與 產(chǎn)品開發(fā)團(tuán)隊(duì)的溝通和工作，保證開發(fā)出來的產(chǎn)品是符合業(yè)務(wù)需求。2、充分利用資源和時間采用敏捷開發(fā)，迭代開發(fā)、強(qiáng)調(diào)溝通、縮減文檔，在每個迭代初 期就可以充分地利用開發(fā)、測試人員的時間，達(dá)到效率最大化。3、充分自動化敏捷開發(fā)強(qiáng)調(diào)擁抱變化，這必然帶來動蕩的產(chǎn)品代碼變更。每一 個新的功能和修改的功能，都可以影響到其他功能，造成副作用。所 以，需要自動化去支持變化，在變化的同時保證質(zhì)量和開發(fā)速度，包 括編譯自動化、單元測試自動化、功能測試自動化、UI測試自動化、 集成測試自動化等。在IM客服項(xiàng)目中，XXX信息技術(shù)有限公司將在開發(fā)過程中充分 運(yùn)用敏捷開發(fā)的理念，使得開發(fā)過程得以縮短以

22、滿足民生要求內(nèi)提供 試運(yùn)行版本的需要；同時，適當(dāng)加快版本迭代發(fā)布的周期（前期為1 個月，中后期為1周），使得迭代產(chǎn)物能更加趨近用戶的需求，擁抱 變化而非死板地按照前期擬定的需求一直開發(fā)到提供初驗(yàn)版本。力爭 在最短的時間內(nèi)交付包含核心功能的可運(yùn)行版本。1.3.3版本迭代模式在實(shí)際操作中，我們將不拘泥于MSF和敏捷開發(fā)的標(biāo)準(zhǔn)要求，而 是根據(jù)實(shí)際情況加以應(yīng)用，如下圖所示:在本次項(xiàng)目中，我們根據(jù)項(xiàng)目的實(shí)際開展情況，設(shè)置如下方式:1、負(fù)責(zé)構(gòu)思和架構(gòu)設(shè)計(jì)的人員可以與開發(fā)、測試人員并行地工 作，從而使人員的使用效率提高，開發(fā)進(jìn)程得以縮短。2、動態(tài)的迭代周期，使得初期版本推出時的無效、重復(fù)的交互 得以減少，減

23、少了對業(yè)務(wù)人員的壓力，提高了工作效率。項(xiàng)目進(jìn)度管理本項(xiàng)目將由經(jīng)驗(yàn)豐富的項(xiàng)目經(jīng)理領(lǐng)導(dǎo)項(xiàng)目組并控制項(xiàng)目進(jìn)度，包 括設(shè)計(jì)、實(shí)施進(jìn)度及滿足各種需要的進(jìn)度計(jì)劃的編制、檢查；實(shí)施 方案的制定與實(shí)施，經(jīng)常性地對計(jì)劃進(jìn)度與實(shí)際進(jìn)度進(jìn)行比較分 析，并及時調(diào)整計(jì)劃等。1.4.1項(xiàng)目進(jìn)度規(guī)劃T：合同簽訂時間序號工作內(nèi)容完成時間備注1QQ客戶端頁面 聯(lián)動子系統(tǒng)開 發(fā)T+2個月2微信客戶端營銷服務(wù)子系統(tǒng)開發(fā)T+2個月3消息處理子系統(tǒng)開發(fā)T+2個月4客服子系統(tǒng)開發(fā)T+2個月5知識管理子系統(tǒng)開發(fā)T+2個月6運(yùn)營管理子系統(tǒng)開發(fā)T+2個月7網(wǎng)服子系統(tǒng)開T+2個月發(fā)8報(bào)表子系統(tǒng)開發(fā)T+2個月9外部接口子系統(tǒng)開發(fā)T+2個月10硬件

24、及網(wǎng)絡(luò)環(huán)境到位T+2個月硬件要加電、相 關(guān)的網(wǎng)絡(luò)要具 備平臺要求的 條件11部署及聯(lián)調(diào)T+2.5個月12平臺培訓(xùn)T+2. 75個月13平臺上線T+3個月1.4.2項(xiàng)目進(jìn)度控制為確保上述進(jìn)度的實(shí)施，雙方建立定期的工程聯(lián)絡(luò)會制度，以及 時協(xié)調(diào)、解決各個階段出現(xiàn)的有關(guān)問題，具體細(xì)節(jié)待談判時由雙方商 定；在實(shí)施開始前，XXX信息技術(shù)有限公司將會提供總體項(xiàng)目進(jìn)度 計(jì)劃表及分項(xiàng)進(jìn)度計(jì)劃。從設(shè)備安裝、驗(yàn)收、驗(yàn)收、交付、設(shè) 備維修等都制定詳細(xì)的時間表。明確項(xiàng)目各階段劃分，設(shè)置項(xiàng)目分階段完成檢測點(diǎn)，以控制每 個環(huán)節(jié)的按時完成。深圳市XXX信息技術(shù)有限公司信息網(wǎng)技術(shù)有限公司項(xiàng)目經(jīng)理 負(fù)責(zé)匯總項(xiàng)目階段性工作報(bào)告，同

25、民生項(xiàng)目經(jīng)理一起審閱。撰寫項(xiàng)目進(jìn)展和狀態(tài)報(bào)告計(jì)劃。具體實(shí)施如下：項(xiàng)目施工進(jìn)度控制是項(xiàng)目管理的中心環(huán)節(jié)，在整個目標(biāo)控制體系 中處于協(xié)調(diào)和帶動其它工作的主導(dǎo)地位。是保障按時完成任務(wù)，合理 安排資源供應(yīng)的重要措施。1、項(xiàng)目開局，編寫項(xiàng)目開發(fā)計(jì)劃，XXX信息技術(shù)有限公司將首先 安排和重點(diǎn)做好下列幾件事：明確各人員職能、職責(zé)，落實(shí)與民生各子系統(tǒng)負(fù)責(zé)人等相 關(guān)人員、單位的聯(lián)絡(luò)方式，以便各方協(xié)調(diào)配合。抓好系統(tǒng)深化設(shè)計(jì)，制定合理的分期設(shè)計(jì)計(jì)劃，以控制設(shè) 計(jì)、實(shí)施兩不誤。2、進(jìn)度計(jì)劃細(xì)化及管理，細(xì)化實(shí)施計(jì)劃，將規(guī)定的任務(wù)結(jié)合在 線客服平臺業(yè)務(wù)需求，在集成開始前和過程中不斷地細(xì)化、調(diào)整計(jì)劃， 使項(xiàng)目進(jìn)度計(jì)劃更具體

26、、切合實(shí)際和可行。做好進(jìn)度記錄、及項(xiàng)目中 的調(diào)度等工作。項(xiàng)目質(zhì)量管理如前所述，本項(xiàng)目釆用MSF和敏捷開發(fā)相結(jié)合的過程模型，在開 發(fā)過程中，需要釆取一定措施對代碼質(zhì)量進(jìn)行管理。1.5.1質(zhì)量管理體系建立并不斷完善質(zhì)量管理體系，是整個質(zhì)量管理的核心內(nèi)容，它 將為質(zhì)量保證活動奠定一個堅(jiān)實(shí)的基礎(chǔ)。這個管理體系是由五個質(zhì)量 保證系統(tǒng)組成的：一、組織架構(gòu)的保證體系。這個組織架構(gòu)應(yīng)至少包括三個要素：1、最高層領(lǐng)導(dǎo)在這個組織架構(gòu)中扮演的角色；2、全體員工參與的方式和參與的程度；3、專業(yè)質(zhì)量管理人員的配備以及所扮演的角色。二、規(guī)章制度的保證體系。這個規(guī)章制度也至少包括三個要素：1、操作流程的規(guī)范制度；2、信息管

27、理的規(guī)范制度；3、檢驗(yàn)程序和變更程序的操作規(guī)程。三、質(zhì)量標(biāo)準(zhǔn)的保證體系。建立這個質(zhì)量標(biāo)準(zhǔn)體系的原則有三條:1、必須有精確量化的質(zhì)量指標(biāo)；2、必須有具體明確而不是抽象含糊的質(zhì)量要求；3、實(shí)施操作的細(xì)則需要有統(tǒng)一的術(shù)語說明。四、資源配置的保證體系。資源配置至少包括三方面的要素：1、設(shè)備要素，配備必要的質(zhì)量檢驗(yàn)設(shè)備，并保證生產(chǎn)設(shè)備本 身的質(zhì)量；2、原材料要素，建立質(zhì)量認(rèn)證體系保證原材料供應(yīng)鏈的質(zhì)量 標(biāo)準(zhǔn)；3、人才要素，選擇、配備、培訓(xùn)合格的質(zhì)量管理專才。五、持續(xù)改進(jìn)活動的保證。持續(xù)改進(jìn)活動的內(nèi)容并無定勢，但一般都包括培訓(xùn)、檢查、評比、 問題分析、征集建議等活動。1.5.2質(zhì)量管理措施配合上述五個質(zhì)量

28、保證體系，制訂相應(yīng)的質(zhì)量保證措施如下：設(shè)置質(zhì)量保證組織架構(gòu)最高層領(lǐng)導(dǎo)對項(xiàng)目最終質(zhì)量負(fù)責(zé)，他可以充分調(diào)動資源并強(qiáng)力推 行質(zhì)量目標(biāo)。項(xiàng)目組每個成員對自己的產(chǎn)出物負(fù)有質(zhì)量責(zé)任。配備專業(yè)的測試人員對程序開發(fā)的產(chǎn)出物進(jìn)行測試，他們對程序 最終的質(zhì)量起到把關(guān)的作用。制訂完善的程序管理規(guī)章制度項(xiàng)目將采用統(tǒng)一的版本管理服務(wù)器管理項(xiàng)目源程序，每個人的程 序，必須經(jīng)另外一個程序員檢查后才能Check in,每天晚上都有 bu訂d所有程序，如果bu訂d不能通過，程序員必須立即修改自己的 程序。每隔一段時間配合進(jìn)度里程碑release 個內(nèi)部版本。這樣做 的主要優(yōu)點(diǎn)：從開始程序就是一個整體，而不是到最后才整合在一起;

29、 互相檢查才能Check in可以減少錯誤的發(fā)生。設(shè)置明確的質(zhì)量要求和測試過程質(zhì)量要求的準(zhǔn)則是客戶導(dǎo)向的準(zhǔn)則，就是以客戶為中心，把客戶 的滿意度作為質(zhì)量標(biāo)準(zhǔn)的尺子。這是ISO-xxxx體系的首要原則：鑒 于顧客是組織的存在之本，因此組織不但應(yīng)該了解顧客當(dāng)前的需求, 而且要了解其未來潛在之需求，不但要盡力滿足顧客的需求，并爭取 超越顧客的期望。測試過程是質(zhì)量控制的重要環(huán)節(jié)，每一個版本的發(fā)布，都必須經(jīng) 過測試人員的測試，提交測試報(bào)告通過審核后才能發(fā)布。配置充足的人力資源確保代碼質(zhì)量持續(xù)的版本迭代使質(zhì)量不斷改進(jìn)螺旋式的過程模型使得每一個版本的推出都能夠吸收和改進(jìn)前 一版本存在的缺陷，從而使程序的質(zhì)量

30、得到不斷的改進(jìn)。1.5.3質(zhì)量控制流程質(zhì)量控制流程采用PDCA流程法。PDCA是四個英文詞的縮寫，分 別代表質(zhì)量控制過程中的四個環(huán)節(jié)：Plan是計(jì)劃，制定質(zhì)量管理的目標(biāo)、要求、流程、制度等；D。是執(zhí)行，實(shí)施質(zhì)量管理計(jì)劃，給予組織、標(biāo)準(zhǔn)、規(guī)章、資源等方面的保障；Check是檢驗(yàn)，對照計(jì)劃檢查實(shí)施結(jié)果，發(fā)現(xiàn)缺陷及偏差并尋 找原因Action是處理，對缺陷和偏差進(jìn)行規(guī)范化處理，對無法進(jìn)行 規(guī)范化處理的，需要對流程及計(jì)劃進(jìn)行調(diào)整。然后調(diào)整措施又 將被納入下一輪新的計(jì)劃，形成一個循環(huán)往復(fù)的閉路流程。質(zhì)量控制的PDCA流程貫穿了質(zhì)量管理中四個最重要的概念：預(yù) 防、保證、檢驗(yàn)、糾偏。預(yù)防和保證是為了將缺陷排

31、除在過程之外, 檢查和糾偏是為了將缺陷排除在送達(dá)客戶之前，PD著眼于預(yù)防和保 證，CA著眼于檢查和糾偏。1.5.4項(xiàng)目變更管理在線客服平臺項(xiàng)目的設(shè)計(jì)、開發(fā)、測試、推廣全過程中，需要控 制來自小組內(nèi)部或外部發(fā)生的，有關(guān)系統(tǒng)需求、功能、環(huán)境、資源、 時間等方面的改動、變化。對其影響力進(jìn)行評估、權(quán)衡，與提出變更 人員、處理的有關(guān)人員協(xié)商，做出處理決定。變更控制參與人員包括：PDM（產(chǎn)品經(jīng)理）、PGM （程序經(jīng)理）、工 程顧問組成工程變更控制小組。變更控制小組責(zé)任：1、讓每一位相關(guān)成員了解變更帶來的對自己及別人的影響;2、綜合各方意見并作出結(jié)論；3、確認(rèn)受到影響的具體成員，并提出變更處理方法、時限;4

32、、PDM（產(chǎn)品經(jīng)理）或PGM （程序經(jīng)理）要跟蹤變更的實(shí)現(xiàn), 及更新受影響的有關(guān)文檔；5、對工程建設(shè)全過程中產(chǎn)生的變更信息進(jìn)行搜集；6、項(xiàng)目在需求分析與設(shè)計(jì)階段時，變更可以隨時進(jìn)行評估, 但其它階段要對接受變更與否進(jìn)行權(quán)衡；變更處理前提：1、不能影響系統(tǒng)總設(shè)計(jì)目標(biāo)及本次工程目標(biāo)的實(shí)現(xiàn)。2、變更及其處理屬于項(xiàng)目建設(shè)小組工作范圍。3、項(xiàng)目領(lǐng)導(dǎo)小組要尊重控制小組的決定，外部或內(nèi)部變更的 提出需經(jīng)過控制小組。建設(shè)小組所有成員要服從控制小組的決定，不 能未經(jīng)控制小組處理，擅自實(shí)現(xiàn)變更改動。變更處理流程情況內(nèi)容結(jié)論時間參與人員1.變更提出的書面描述變更原因、性質(zhì)、內(nèi)容、處理建議變更提出后2小時內(nèi)變更提 出

33、人員向變 更控制小組 提交2.變更報(bào)告的評估、討論變更版本、理由、影響、代接收變更報(bào)告后4小時內(nèi)變更提出人員、變更與協(xié)調(diào)價及好壞處控制小組、處理人員3o變更處理決定變更處理方法，實(shí)現(xiàn)程度要求，時間安排討論后2小時內(nèi)變更控制小組40變更處理跟蹤監(jiān)控實(shí)現(xiàn)程度，時間處理決定下達(dá)后，規(guī)定時間內(nèi)變更控制小組5o變更歸檔變更檔案的建立、相關(guān)文檔的改動處理決定下達(dá)后1小時內(nèi)變更控制小組1.6 項(xiàng)目溝通協(xié)調(diào)一個項(xiàng)目能否成功實(shí)施，溝通是否暢順是關(guān)鍵。項(xiàng)目溝通是 確保項(xiàng)目團(tuán)隊(duì)的相關(guān)信息能及時、正確地產(chǎn)生、收集、發(fā)布、儲 存和最終處理好項(xiàng)目信息所需的各個過程。為了確保本項(xiàng)目的順 利實(shí)施，XXX信息技術(shù)有限公司將在項(xiàng)

34、目實(shí)施過程中提供良好的 溝通機(jī)制。1.6. 1溝通措施為了保證項(xiàng)目團(tuán)隊(duì)的有效溝通，我們提出了六項(xiàng)措施:建立溝通渠道，項(xiàng)目組實(shí)行每周一次的例會制度，通過例會達(dá) 到項(xiàng)目組各方充分溝通的目的。構(gòu)建緊密矩陣，在空間上最大限度地縮小團(tuán)隊(duì)成員之間的空間 距離。在前3個月，開發(fā)人員和業(yè)務(wù)人員可以集中在民生辦公, 集中在一個隨時可以面對面交流的場所里辦公，克服距離造成 的溝通障礙。保證溝通質(zhì)量，在溝通過程中鼓勵信息反饋，消滅暈圈效果、 虛假合意之類的無效溝通。用量化的信息代替那些“挺好、不 錯、還行”之類的含糊其詞。排除溝通障礙，針對團(tuán)隊(duì)中存在的主觀溝通障礙，消除不良的 消極情緒，避免背后搞小動作，鼓勵有話擺

35、在臺面上說，用坦 誠對話解決問題。促成意見統(tǒng)一，最大限度地求同存異，提取公約數(shù)。把意見的 統(tǒng)一作為溝通的目標(biāo)，以及衡量溝通效果的質(zhì)量標(biāo)準(zhǔn)?；I備有效會議，會議是組織中最重要的溝通渠道，溝通的有效 性在很大程度上取決于會議的效率和效果。通過這六項(xiàng)措施，我們將確保本項(xiàng)目在實(shí)施過程中建設(shè)方和用戶 方能緊密合作、暢順溝通，最大程度地保證項(xiàng)目的實(shí)施質(zhì)量。1.6.2沖突因素項(xiàng)目實(shí)施過程中，項(xiàng)目團(tuán)隊(duì)內(nèi)部產(chǎn)生一些沖突是正常的，也是不 可避免的。關(guān)鍵的問題是要知道容易產(chǎn)生沖突的地方在哪里，產(chǎn)生的 原因是什么，以便盡可能避免沖突，或有效地解決沖突。下面列出的 是最容易產(chǎn)生沖突的六個領(lǐng)域，并不涉及項(xiàng)目決策時干系人之間

36、的利 益性沖突，主要指團(tuán)隊(duì)成員的工作性沖突。1、進(jìn)度計(jì)劃：主要表現(xiàn)在對工時和工期估算的意見分歧。有人想 把工期拉長，減輕自己的壓力，但是你的工期拖長了，別人會有意見， 這意味著別人的工期要縮短，增加別人的壓力。這歸根結(jié)底還是時間 資源的分配問題。2、資源分配：供需矛盾是一對永恒的矛盾，不過管理中的供需 矛盾主要表現(xiàn)在各部門站在本位立場爭奪資源而產(chǎn)生的摩擦，或者苦 樂不均產(chǎn)生的矛盾。3、優(yōu)先級別：既然做什么不做什么已經(jīng)在立項(xiàng)時就決定了，那 么項(xiàng)目的計(jì)劃實(shí)施階段的沖突就將主要表現(xiàn)在先做什么，后做什么的 爭議上了。既然所有的決定都在資源約束的情況下進(jìn)行，那么資源的 優(yōu)先分配權(quán)的問題就變成了沖突的焦點(diǎn)

37、。4、技術(shù)觀點(diǎn)：包括對于技術(shù)方案選擇、質(zhì)量標(biāo)準(zhǔn)認(rèn)定、操作規(guī) 范效果評價等方面的觀點(diǎn)分歧，原因可能是方法問題也可能是利益和 責(zé)任問題。5、行政導(dǎo)向：這方面的沖突涵蓋面最為廣泛，包括因立規(guī)、授 權(quán)、問責(zé)、獎罰、調(diào)度及管理方法而產(chǎn)生的各種矛盾。不按正常的指 揮鏈條進(jìn)行溝通，例如下級的越級告狀，上級的越級指揮，同級的越 權(quán)干涉，也是這方面沖突的高發(fā)領(lǐng)域。6、人際關(guān)系：指因個性不合而產(chǎn)生的感情矛盾。工作中的矛盾 一旦升級到了個人感情的沖突，觀點(diǎn)的分歧就演變成為對人品的偏見, 這個結(jié)就很難解開了。人際關(guān)系的矛盾往往是非理性的，帶有很強(qiáng)的 感性色彩，這是溝通管理中最大的陷阱，被稱為管理盲區(qū)，或者管理 無能區(qū)

38、。因此，在處理工作沖突時，一定要堅(jiān)持就事論事的理性原則， 避開個人情緒化，以免將矛盾升級到感性區(qū)。以上沖突不得到解決，將威脅項(xiàng)目的成功實(shí)施，因此必須在項(xiàng)目 開展過程中時刻關(guān)注沖突的發(fā)生并使之得到妥善解決。1.6.3解決沖突針對上面的沖突因素，可以有解決沖突的五種方式：1、強(qiáng)制執(zhí)行，在雙方發(fā)生沖突時，管理級別較高的一方以權(quán)壓 人，命令對方服從自己的觀點(diǎn)和決定。從坐標(biāo)系的象限位置可以看出， 這種方式有利于解決問題，但是不利于后續(xù)的人際關(guān)系。被迫服從的 一方肯定口服心不服，沖突的根源并沒有被徹底解決。2、主動解決，捅開隔在矛盾雙方之間的窗戶紙，通過面對面的 坦誠溝通交換意見，求同存異。這種方式既有利

39、于解決問題，也有利 于人際關(guān)系的修復(fù)，是這五種方式的上策。管理中人們經(jīng)常犯的錯誤 是找錯了溝通對象：丙明明是對甲有意見，卻對乙說，結(jié)果一旦甲得 到了風(fēng)聲，就會認(rèn)為丙在背后挑撥他與乙的關(guān)系，從而對丙產(chǎn)生成見， 矛盾的種子就是這樣種下的。其實(shí)這件事情很簡單，丙既然對甲有意 見，直接找甲說就行了，找乙說除了發(fā)泄情緒能解決什么問題？這種 發(fā)泄情緒的做法，恰恰會陷入感情沖突的非理性區(qū)。3、調(diào)和斡旋，當(dāng)矛盾沖突陷入僵局的時候，聰明的辦法是委托 一個斡旋人出面解開死結(jié)。扮演這種角色的人最好是德高望重、說話 有份量、且雙方都可以接受的人物。這個調(diào)停人主要的作用其實(shí)只是 給雙方臺階下。這種解決沖突的方式主要著眼

40、于緩和人際關(guān)系，但是 未必能解決問題，雙方雖然保住了面子，但是問題仍舊存在。4、撤退回避，掛免戰(zhàn)牌，脫離接觸，把矛盾掛起來，留到以后條 件成熟了再解決。這就是我們常說的：讓時間來解決問題。時間怎么 解決問題呢？從外因說，隨著時間拖延，外部環(huán)境有可能朝著發(fā)生有 利于解決問題的方向變化。從內(nèi)因說，時間可以腐蝕期望值，當(dāng)雙方 的期望值都降到了一個合適的位置的時候，解決問題的條件或許就成 熟了。這種方法對于解決問題和人際關(guān)系的效果都未必好，因?yàn)橹荒?被動等待。5、妥協(xié)折衷，就是用自己的主動讓步交換對方的讓步，用降低 自己訴求來交換對方降低訴求，以此來緩和沖突。這是一種不求雙贏 而避免雙輸?shù)淖龇?。?jiān)持主

41、張需要勇氣，可是妥協(xié)更需要勇氣。人們 常說：勝人者易，勝已者強(qiáng)。意思是說，戰(zhàn)勝自己比戰(zhàn)勝別人更困難。 用這種方式解決問題和緩和人際關(guān)系雖然不徹底，但表現(xiàn)了某種主動 積極的姿態(tài)，不失為一種可取的策略。五種方式各有優(yōu)缺點(diǎn)，一般來說主動解決才是正解，但是在現(xiàn)實(shí) 生活中，往往也需要其他方式加以輔助，靈活運(yùn)用。總之，XXX信息技術(shù)有限公司將在項(xiàng)目實(shí)施過程中，本著客觀真 實(shí)、實(shí)事求是的態(tài)度，運(yùn)用我們在與電信長期合作的經(jīng)驗(yàn)，保持與民 生用戶方的充分、深入的溝通，確保在項(xiàng)目開展過程中減少和避免沖 突的發(fā)生，即便發(fā)生沖突，也正視沖突，并通過溝通使得沖突得以化 解，從而確保項(xiàng)目的順利實(shí)施。1.7 項(xiàng)目風(fēng)險管理任何

42、一個項(xiàng)目在設(shè)定目標(biāo)，實(shí)現(xiàn)計(jì)劃的過程中都有可能出現(xiàn)一些 意外的情況，或許是技術(shù)上的、或許是資源方面也可能是時間安排上 的問題。因此在項(xiàng)目管理方案中包含了風(fēng)險管理計(jì)劃。風(fēng)險識別和管 理計(jì)劃從進(jìn)程模型的第一個階段就開始介入，是一種預(yù)風(fēng)險管理方式。 不同于一般意義上的風(fēng)險管理，風(fēng)險管理強(qiáng)調(diào)的是防止風(fēng)險的發(fā)生和 減少風(fēng)險的損失，而不是在風(fēng)險發(fā)生之后的補(bǔ)救措施。經(jīng)過多年在實(shí) 踐中的總結(jié)，大多數(shù)的風(fēng)險都是可以預(yù)見和預(yù)防的。因此利用這種預(yù) 風(fēng)險管理模式作為保證項(xiàng)目順利完成的基礎(chǔ)。項(xiàng)目組隊(duì)模型中的不同 角色在不同的實(shí)現(xiàn)階段分擔(dān)不同的風(fēng)險識別和管理任務(wù)，保證高風(fēng)險 的情況應(yīng)該得到優(yōu)先的解決。結(jié)合項(xiàng)目制定的目標(biāo)，配

43、合風(fēng)險管理， 才能達(dá)到在指定時間內(nèi)完成指定功能的目的。1.7.1風(fēng)險評估風(fēng)險管理首先需要定義風(fēng)險，也就是評估風(fēng)險。評估風(fēng)險需要考 慮風(fēng)險發(fā)生的可能性，風(fēng)險的破壞力以及風(fēng)險對整個項(xiàng)目的影響。在 正確評估了風(fēng)險的基礎(chǔ)上，需要考慮面對風(fēng)險的對策，我們需要仔細(xì) 研究風(fēng)險的各個方面，力求全面了解問題并確定風(fēng)險的優(yōu)先級，然后 考慮降低風(fēng)險發(fā)生的方法，最后考慮風(fēng)險發(fā)生時的對策。制定風(fēng)險對 策之后則要做風(fēng)險跟蹤工作，通常我們會有風(fēng)險計(jì)劃的更新和跟蹤、 每個階段結(jié)束后的風(fēng)險總結(jié)以及隨時更新的當(dāng)前最主要的前幾個風(fēng) 險的跟蹤。整個風(fēng)險控制在項(xiàng)目的風(fēng)險管理之下，能最大限度的降低 項(xiàng)目失敗的情況。下面是風(fēng)險控制具體實(shí)施

44、的一個模板。在風(fēng)險確定階段就需要完 成最初的風(fēng)險管理文檔。風(fēng)險管理文檔的目的是詳細(xì)的記錄風(fēng)險的性 質(zhì)，而不是簡單的一個名詞而已。通過風(fēng)險描述，要達(dá)到全面了解風(fēng) 險的目的。最初的風(fēng)險管理文檔應(yīng)包括：風(fēng)險名稱風(fēng)險描述風(fēng)險狀況風(fēng)險后果在最初風(fēng)險管理文檔的基礎(chǔ)上可以對風(fēng)險進(jìn)行更詳細(xì)的分析，并 最終在風(fēng)險管理文檔中增加對風(fēng)險的分析信息。通過風(fēng)險分析要達(dá)到 評估風(fēng)險的目標(biāo)，并分析補(bǔ)充風(fēng)險的資料：風(fēng)險源風(fēng)險發(fā)生的可能性風(fēng)險可能造成的影響風(fēng)險的影響級別風(fēng)險對整個項(xiàng)目的影響相關(guān)聯(lián)的其它風(fēng)險在本次項(xiàng)目中，XXX信息技術(shù)有限公司進(jìn)行了初步的風(fēng)險評估, 并按照風(fēng)險級別進(jìn)行了排序，主要的風(fēng)險列舉如下：1、時間進(jìn)度風(fēng)險。

45、本次項(xiàng)目時間緊、任務(wù)重，能不能在民生制 定的目標(biāo)時間內(nèi)完成相應(yīng)的開發(fā)任務(wù)，是本項(xiàng)目最突出的矛盾和最大 的風(fēng)險。2、程序開發(fā)風(fēng)險。本次項(xiàng)目開發(fā)難度高，對開發(fā)人員的技能水 平、開發(fā)經(jīng)驗(yàn)、協(xié)調(diào)溝通能力提出了很高的要求。3、資金成本風(fēng)險。由于項(xiàng)目開發(fā)時間進(jìn)度緊，需要在初期投入 大量的人力資源，后期維保時間又很長，需要長期投入人力維護(hù)，加 之還有第三方軟件的采購，這些都給項(xiàng)目的資金成本帶來風(fēng)險，控制 不好的話，將使項(xiàng)目虧損，也有可能因此影響項(xiàng)目實(shí)施。1.7.2風(fēng)險應(yīng)對針對風(fēng)險分析的結(jié)果，需要預(yù)先做好風(fēng)險的應(yīng)對計(jì)劃。即如何防 止這個風(fēng)險的發(fā)生，當(dāng)風(fēng)險發(fā)生時我們需要采取的措施。為此，當(dāng)完 成風(fēng)險計(jì)劃的時候，

46、風(fēng)險管理文檔得到進(jìn)一步的補(bǔ)充完善：預(yù)防風(fēng)險策略預(yù)防風(fēng)險策略評測針對風(fēng)險需要采取的行動降低風(fēng)險行動的最終期限負(fù)責(zé)此風(fēng)險的人員風(fēng)險時策略風(fēng)險時策略評測和風(fēng)險時策略的觸發(fā)條件至此，風(fēng)險管理文檔針對可以預(yù)見的風(fēng)險已經(jīng)做好了預(yù)防等措施, 風(fēng)險得到預(yù)先的控制和管理。針對前述對本次項(xiàng)目主要風(fēng)險的評估，我們已經(jīng)做好了預(yù)防風(fēng)險 的準(zhǔn)備：1、針對時間進(jìn)度風(fēng)險。首先是調(diào)配充足的人力資源進(jìn)行項(xiàng)目的 實(shí)施，其次是采用分階段的實(shí)施方式分期交付成果，在每一個階段都 對需求內(nèi)容進(jìn)行風(fēng)險評估，確保最需要的、最核心的功能優(yōu)先得到開 發(fā)，從而加快系統(tǒng)的上線速度。2、針對程序開發(fā)風(fēng)險。除了調(diào)配精兵強(qiáng)將投入本項(xiàng)目的開發(fā)， 團(tuán)隊(duì)內(nèi)部加強(qiáng)

47、溝通和內(nèi)部交流、培訓(xùn)也十分重要，通過充分的溝通統(tǒng) 一大家的認(rèn)識，使得開發(fā)工作更為順暢。3、針對資金成本風(fēng)險。對投入的人力資源進(jìn)行充分的考慮和計(jì) 劃，例如采用重疊式的迭代開發(fā)，盡量提高人員的使用效率，一方面 要保證項(xiàng)目按時保質(zhì)的實(shí)施，另一方面又要防止人力資源浪費(fèi)導(dǎo)致項(xiàng) 目虧損。對于第三方軟件則從一開始的計(jì)劃就對采購成本進(jìn)行計(jì)劃和 控制，在保障民生業(yè)務(wù)需求的前提下減少第三方軟件占用的資金成本。1.7.3風(fēng)險跟蹤風(fēng)險的跟蹤伴隨在項(xiàng)目實(shí)施的整個過程中。根據(jù)風(fēng)險管理文檔， 可以得到當(dāng)前優(yōu)先級最高的前幾個風(fēng)險，并把這些風(fēng)險作為跟蹤的中 心。風(fēng)險跟蹤是通過風(fēng)險跟蹤文檔來實(shí)現(xiàn)的。風(fēng)險跟蹤文檔包括：風(fēng)險項(xiàng)風(fēng)險優(yōu)

48、先級風(fēng)險在跟蹤狀態(tài)下的時間風(fēng)險管理目前的進(jìn)行程度風(fēng)險管理期中時間風(fēng)險管理完成時間在風(fēng)險跟蹤文檔產(chǎn)生的同時，還針對每個時間階段（每個風(fēng)險管 理期開始、期中和完成時間）形成風(fēng)險狀態(tài)表。風(fēng)險狀態(tài)表記錄某一 個特定時間點(diǎn)上各個風(fēng)險的最新情況，這些信息包括：時間風(fēng)險項(xiàng)針對風(fēng)險采取的措施風(fēng)險的負(fù)責(zé)人措施前風(fēng)險發(fā)生的可能性措施后風(fēng)險發(fā)生的可能性措施前風(fēng)險對項(xiàng)目的影響度措施后風(fēng)險對項(xiàng)目的影響度當(dāng)前整個項(xiàng)目的風(fēng)險度（總計(jì)所有項(xiàng)目的影響度）在項(xiàng)目管理體系結(jié)構(gòu)中，通過上面的風(fēng)險描述、風(fēng)險分析、風(fēng)險 跟蹤來達(dá)到風(fēng)險控制的目的。從整個流程上可以看到，風(fēng)險管理將預(yù) 防風(fēng)險的發(fā)生放在顯著的位置上。其次才是在風(fēng)險發(fā)生時的處理

49、方案。1.7.4風(fēng)險管理組織在組隊(duì)模型的六個角色設(shè)立的方式中，充分體現(xiàn)了項(xiàng)目風(fēng)險管理 的概念，每個角色都從不同的角度負(fù)責(zé)方面的風(fēng)險識別和風(fēng)險管理任 務(wù)：產(chǎn)品管理代表客戶的需求，負(fù)責(zé)整個項(xiàng)目的整體目標(biāo)和范圍，保 證項(xiàng)目在實(shí)現(xiàn)的過程中符合客戶的需求。避免資源方面的風(fēng)險和產(chǎn)生 不符合客戶需求的產(chǎn)品的風(fēng)險項(xiàng)目經(jīng)理則關(guān)注整個項(xiàng)目的進(jìn)展情況，保證項(xiàng)目在預(yù)期的時間和 資源條件內(nèi)順利地完成所承諾的功能。避免技術(shù)方案方面和人員方面 的風(fēng)險開發(fā)集中在技術(shù)細(xì)節(jié)和人員能力方面的風(fēng)險，隨時評估開發(fā)過程 中的細(xì)小階段是否能按時完成，完成的部分是否符合要求等開發(fā)需要 避免在開發(fā)過程中影響完成符合功能規(guī)范產(chǎn)品的風(fēng)險用戶教育代

50、表最終用戶的需求，負(fù)責(zé)保證最終用戶使用的方便性, 是負(fù)責(zé)設(shè)計(jì)最終用戶使用系統(tǒng)的界面和文檔的小組，需要評估在用戶 培訓(xùn)階段要面臨的問題，并提供解決的方法。避免最終用戶在使用產(chǎn) 品時不能很快的適應(yīng)新產(chǎn)品或者因?yàn)椴荒芰私庑庐a(chǎn)品的功能而造成 使用上的失誤測試是保證最終交付的產(chǎn)品是解決了所有已知問題的產(chǎn)品。測試 要承擔(dān)在測試階段時的測試方案、測試環(huán)境相關(guān)的風(fēng)險。避免交付的 產(chǎn)品不能達(dá)到最初的設(shè)計(jì)目的最后一個角色是推廣實(shí)施，代表的是運(yùn)行、支持和維護(hù)人員的需 求，負(fù)責(zé)產(chǎn)品在客戶方的安裝和設(shè)置，并保證將產(chǎn)品平穩(wěn)的移交到產(chǎn) 品運(yùn)行、支持和維護(hù)組手中。因此推廣實(shí)施需要面臨的風(fēng)險是產(chǎn)品購 買、硬件方面和軟件設(shè)置安裝

51、方面的風(fēng)險。7. 5小結(jié)項(xiàng)目的管理是圍繞著資源、時間和實(shí)現(xiàn)功能三個方面。相應(yīng)的風(fēng) 險管理就面向于資源、時間和實(shí)現(xiàn)功能三個角度。這三者是一個三角 形的關(guān)系，任何兩方面的能實(shí)現(xiàn)的范圍決定了另一方面可以實(shí)現(xiàn)的范 圍：例如能投入的資源（人力/物力/財(cái)力等）和開發(fā)所需要的時間決 定了應(yīng)用系統(tǒng)可以實(shí)現(xiàn)功能的大致范圍。因此在項(xiàng)目的目標(biāo)/范圍確 定階段，就要根據(jù)三個方面能投入的力度來設(shè)置風(fēng)險管理計(jì)劃，當(dāng)任 何一方面的投入發(fā)生變化的時候，需要修改相應(yīng)的計(jì)劃以避免項(xiàng)目的 失敗。在隨后的系統(tǒng)設(shè)計(jì)、開發(fā)、測試階段不斷更新風(fēng)險管理計(jì)劃， 保證在每個階段的每種情況都有專人的負(fù)責(zé)和充足的準(zhǔn)備，整個項(xiàng)目 所面臨的風(fēng)險都隨時得

52、到關(guān)注和解決。對于大型的項(xiàng)目，還可以委派 專人負(fù)責(zé)整個風(fēng)險管理的管理工作，以確保風(fēng)險隨時得到控制。風(fēng)險 計(jì)劃書對整個項(xiàng)目組和客戶都是可見的，保證它能被實(shí)時更新和及時 跟蹤。1.8 項(xiàng)目現(xiàn)場管理按照敏捷開發(fā)的模式，同時根據(jù)民生客服中心的要求，在整個項(xiàng) 目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須在一起工作。在項(xiàng)目實(shí)施期間， XXX信息技術(shù)有限公司可以將派出開發(fā)團(tuán)隊(duì)到民生現(xiàn)場駐點(diǎn)?，F(xiàn)場駐點(diǎn)的人員包括：1、項(xiàng)目經(jīng)理負(fù)責(zé)和甲方指定的產(chǎn)品經(jīng)理進(jìn)行溝通，了解并掌握用戶的需求; 負(fù)責(zé)項(xiàng)目的總體進(jìn)度控制、資源協(xié)調(diào)、質(zhì)量控制、風(fēng)險控制；負(fù)責(zé)對 項(xiàng)目組的現(xiàn)場工作進(jìn)行管理，包括：人員管理、程序管理、制訂項(xiàng)目 組工作計(jì)劃、召集

53、例會和各種交流培訓(xùn)等；2、需求分析人員需求分析人員需要密切地和甲方的產(chǎn)品經(jīng)理、業(yè)務(wù)人員、最終用 戶進(jìn)行密切的溝通，深入了解并確定需求的內(nèi)容和范圍。3、架構(gòu)設(shè)計(jì)人員架構(gòu)設(shè)計(jì)人員需要深刻地了解用戶的需求，并將需求轉(zhuǎn)換為可實(shí) 施、可開發(fā)的系統(tǒng)和程序的架構(gòu)設(shè)計(jì)，架構(gòu)設(shè)計(jì)人員有責(zé)任和甲方產(chǎn) 品負(fù)責(zé)人明確各個階段需要完成的核心功能的范圍、優(yōu)先順序，有責(zé) 任將架構(gòu)設(shè)計(jì)的思路與各方溝通并得以明確。4、UI界面設(shè)計(jì)人員UI界面設(shè)計(jì)人員需要通過不斷向用戶提供原型設(shè)計(jì)，展示給用 戶并根據(jù)用戶的反饋進(jìn)行修改完善。UI設(shè)計(jì)關(guān)系到最終用戶的使用 體驗(yàn)，是產(chǎn)品最終能否方便、高效、易用的關(guān)鍵。UI設(shè)計(jì)人員還需要 和程序開發(fā)人

54、員密切配合，使程序開發(fā)人員深刻理解用戶的操作，并 準(zhǔn)確地實(shí)現(xiàn)相應(yīng)的功能。5、程序開發(fā)人員在敏捷開發(fā)的模式里，程序開發(fā)人員除了完成程序的開發(fā)、自我 測試、程序版本和質(zhì)量的控制外，很重要的工作就是需要和UI設(shè)計(jì) 人員、需求人員、乃至最終用戶進(jìn)行溝通，在深入了解需求的基礎(chǔ)上 進(jìn)行程序的開發(fā)工作。6、測試人員本次項(xiàng)目采用的螺旋迭代式的開發(fā)，版本的測試、發(fā)布會很頻繁, 每個版本的發(fā)布都必須經(jīng)過測試人員的測試，確保版本的質(zhì)量，因此, 測試人員必須頻繁地和開發(fā)人員溝通，反饋測試過程出現(xiàn)的問題，能 及時解決的就及時解決，暫時不能解決的則列入下一版本的開發(fā)內(nèi)容 里。7、用戶培訓(xùn)人員用戶培訓(xùn)人員并非項(xiàng)目做完了給用

55、戶做一次培訓(xùn)就完了，因?yàn)槭?采用螺旋迭代式開發(fā)，在每一個版本發(fā)布的時候，新的功能都需要對 用戶進(jìn)行培訓(xùn)，使每一個版本所完成的功能都能讓用戶充分的理解并 順利地使用。第2章測試驗(yàn)收方案2. 1驗(yàn)收標(biāo)準(zhǔn)1.1功能項(xiàng)測試對軟件需求規(guī)格說明書中的所有功能項(xiàng)進(jìn)行測試。12業(yè)務(wù)流程測試對軟件項(xiàng)目的典型業(yè)務(wù)流程進(jìn)行測試。1.3容錯測試容錯測試的檢查內(nèi)容包括：1）軟件對用戶常見的誤操作是否能進(jìn)行提示；2）軟件對用戶的的操作錯誤和軟件錯誤，是否有準(zhǔn)確、清晰的提示；3）軟件對重要數(shù)據(jù)的刪除是否有警告和確認(rèn)提示；4）軟件是否能判斷數(shù)據(jù)的有效性，屏蔽用戶的錯誤輸入，識別非法值，并有相應(yīng)的錯誤提示。1.4安全性測試安全

56、性測試的檢查內(nèi)容包括：1）軟件中的密鑰是否以密文方式存儲；2）軟件是否有留痕功能，即是否保存有用戶的操作日志；3）軟件中各種用戶的權(quán)限分配是否合理。1.5性能測試對軟件需求規(guī)格說明書中明確的軟件性能進(jìn)行測試。測試的準(zhǔn)則 是要滿足規(guī)格說明書中的各項(xiàng)性能指標(biāo)。2.1.6易用性測試易用性測試的內(nèi)容包括：1）軟件的用戶界面是否友好，是否出現(xiàn)中英文混雜的界面；2）軟件中的提示信息是否清楚、易理解，是否存在原始的英文 提示；3）軟件中各個模塊的界面風(fēng)格是否一致；4）軟件中的查詢結(jié)果的輸出方式是否比較直觀、合理。1.7適應(yīng)性測試參照用戶的軟、硬件使用環(huán)境和需求規(guī)格說明書中的規(guī)定，列出 開發(fā)的軟件需要滿足的軟

57、、硬件環(huán)境。對每個環(huán)境進(jìn)行測試。2.1.8文檔測試用戶文檔包括：安裝手冊、操作手冊和維護(hù)手冊。對用戶文檔測試的內(nèi)容包括：1）操作、維護(hù)文檔是否齊全、是否包含產(chǎn)品使用所需的信息和 所有的功能模塊；2）用戶文檔描述的信息是否正確，是否沒有歧義和錯誤的表達(dá);3）戶文檔是否容易理解，是否通過使用適當(dāng)?shù)男g(shù)語、圖形表 示、詳細(xì)的解釋來表達(dá)；4）用戶文檔對主要功能和關(guān)鍵操作是否提供應(yīng)用實(shí)例；5）用戶文檔是否有詳細(xì)的目錄表和索引表。2.1.9用戶有特別要求的測試2.2 測試用例編寫方案及標(biāo)準(zhǔn)2. 2.1編寫原則（1）基本的原則就是：“一點(diǎn)多例”，就是針對一個測試點(diǎn)或 者功能點(diǎn)，編寫多個測試用例，從多個方面進(jìn)行

58、測試。各個部分的 用例編寫的都貫穿著這一基本思想。（2）單元測試由開發(fā)人員執(zhí)行，可以自身決定是否編寫單元測 試用例。（3）對于每個用例事件流，測試需求的詳細(xì)列表至少會包括一 個測試需求。對于需求規(guī)格說明書中的功能描述，將至少派生一個 測試需求。（4）測試項(xiàng)描述-簡要說明測試用例所要涉及的項(xiàng)和特性、對 于每一項(xiàng)、可考慮引用以下文件：需求說明書、設(shè)計(jì)說明書、用戶 手冊、操作手冊。（5）輸入說明描述-規(guī)定執(zhí)行測試用例所需的各個輸入。有些輸 入可以用值（允許適當(dāng)?shù)恼`差）來規(guī)定。而另一些輸入，如常數(shù)表 或事務(wù)文件可以用名來規(guī)定。規(guī)定所有合適的數(shù)據(jù)庫、文件、終端 信息傳送的值。輸出說明描述-規(guī)定測試項(xiàng)的所

59、有輸出和特性(如：響應(yīng) 時間)。提供各個輸出或特性的正確值。測試用例的設(shè)計(jì)，始終要考慮測試的執(zhí)行，同時測試發(fā)現(xiàn) 的問題和總結(jié)的經(jīng)驗(yàn)也可以用來完善測試設(shè)計(jì)。2. 2. 2衡量測試用例設(shè)計(jì)的質(zhì)量標(biāo)準(zhǔn)可測性：測試用例的所有步驟是可測的，測試的步驟是具體可實(shí)施后的，按照每個步驟是可以走通的。可驗(yàn)證：測試的每個步驟驗(yàn)證點(diǎn)是具體、可驗(yàn)證的。期望結(jié)果不是抽象的描述，而是可獲得的。全面性：測試執(zhí)行人員，無須考慮怎么測、而是參照測試用例 設(shè)計(jì)的步驟執(zhí)行，測試數(shù)據(jù)的準(zhǔn)備也要在測試設(shè)計(jì)時考慮，而且要具備高覆蓋率和全面性。2. 2. 3測試用例與開發(fā)的對應(yīng)關(guān)系約定開發(fā)階段依據(jù)文檔編寫的用例需求分析階段結(jié)束后需求文檔系

60、統(tǒng)測試對應(yīng)的用例概要設(shè)計(jì)階段結(jié)束后概要設(shè)計(jì)、體系設(shè)計(jì)文檔集成測試對應(yīng)的用例詳細(xì)設(shè)計(jì)階段詳細(xì)設(shè)計(jì)文檔單元測試對應(yīng)的用例備注：單元測試由開發(fā)人員進(jìn)行，故不納入測試用例。2. 2. 4測試用例類型約定測試用例對應(yīng)測試類型測試 覆蓋率 （測試人 員）功能測試用例主要包括功能測試90%100%性能測試用例性能測試、壓力測試、強(qiáng)度測試10%集成測試用例接口測試、健壯性測試、可靠性測試40%50%安全測試用例安全測試10%用戶界面測試用例用戶界面測試、少量功能測 試100%2. 2.5測試階段、類型與執(zhí)行角色的關(guān)系約定測試階段測試類型執(zhí)行角色單元測試主要包括功能測試開發(fā)人員，測試人員可配合部分基礎(chǔ)數(shù)據(jù)準(zhǔn)備集