軟件項(xiàng)目管理實(shí)踐之如何實(shí)施質(zhì)量控制

軟件項(xiàng)目管理實(shí)踐之如何實(shí)施質(zhì)量控制

質(zhì)量控制包括對項(xiàng)目管理過程績效和項(xiàng)目可交付成果的質(zhì)量控制。質(zhì)量控制主要通過文檔評審、技術(shù)評審、代碼走查和測試檢查實(shí)現(xiàn)?！?.1.1技術(shù)評審技術(shù)評審包括技術(shù)文檔評審、技術(shù)實(shí)現(xiàn)評審和代碼走查。一、文檔評審實(shí)施過程前期產(chǎn)生的需求規(guī)格說明書、系統(tǒng)設(shè)計(jì)說明書、測試用例等文檔是后期編碼、測試的主要依據(jù)和輸入，這些文檔的質(zhì)量直接決定了軟件系統(tǒng)的好壞、系統(tǒng)返工的多寡以及客戶滿意度。因而對這些文檔的評審尤為重要，評審的目的在于在交付給下游開發(fā)或測試時(shí)及早發(fā)現(xiàn)問題，修正錯(cuò)誤，以免問題和錯(cuò)誤在系統(tǒng)中的蔓。文檔評審采用同行評審會議的方式進(jìn)行，由項(xiàng)目經(jīng)理組織，開發(fā)相關(guān)文檔參與的角色包括其他子系統(tǒng)的系統(tǒng)分析員、質(zhì)量控制部相關(guān)人員、其他兄弟部門有類似經(jīng)驗(yàn)的系統(tǒng)分析員等;測試相關(guān)文檔則由項(xiàng)目經(jīng)理、測試經(jīng)理、系統(tǒng)分析員和其他測試人員參與。評審過程中，主要從以下幾方面考察文檔的質(zhì)量：?可讀性。主要從文檔是否符合公司模板規(guī)范、邏輯結(jié)構(gòu)層次是否清晰明確、文字表達(dá)是否無歧義等方面判斷;?完整性。主要從文檔是否完全滿足要求，是否已覆蓋所有的功能點(diǎn)等方面判斷;?一致性。主要判斷文檔表述是否前后不一、是否有矛盾等;?技術(shù)可行性。主要判斷目前的技術(shù)框架是否支持，是否有類似的經(jīng)驗(yàn)，是否有技術(shù)風(fēng)險(xiǎn)等。二、技術(shù)實(shí)現(xiàn)評審技術(shù)實(shí)現(xiàn)評審包括項(xiàng)目技術(shù)框架選型評審、具體某個(gè)模塊的技術(shù)實(shí)現(xiàn)方法評審。技術(shù)框架的評審目的是為了在進(jìn)入大規(guī)模編碼開發(fā)前確認(rèn)選擇何種技術(shù)框架、判斷現(xiàn)有的技術(shù)框架是否滿足項(xiàng)目功能和性能需求、框架是否足夠穩(wěn)定以及可能存在的風(fēng)險(xiǎn)等;具體某個(gè)模塊的技術(shù)實(shí)現(xiàn)方式評審目的是為了保證選擇的實(shí)現(xiàn)方式目前來說是最優(yōu)的、可以推廣到其他模塊使用的。技術(shù)評審?fù)ㄟ^評審會議的方式進(jìn)行，參與的人員包括項(xiàng)目經(jīng)理、系統(tǒng)分析員、開發(fā)人員、公司內(nèi)部相關(guān)技術(shù)的專家、有同類項(xiàng)目經(jīng)驗(yàn)的實(shí)施人員、質(zhì)量控制人員等。三、代碼走查代碼走查主要是對軟件代碼進(jìn)行復(fù)審，主要以高級程序員復(fù)審代碼或同級別的程序員交叉檢查的形式進(jìn)行。代碼走查的目的是通過抽查，保證代碼的編寫和注釋符合編碼規(guī)范，編碼邏輯符合系統(tǒng)設(shè)計(jì)要求，減少測試返工以及因測試返工引起的來回溝通、回歸測試等問題，降低管理成本，提高開發(fā)效率?！?.1.2測試檢查測試檢查是由測試人員根據(jù)測試用例對軟件產(chǎn)品進(jìn)行功能測試以及使用壓力測試工具對系統(tǒng)進(jìn)行壓力測試。測試檢查的目的是確保交付給客戶執(zhí)行驗(yàn)收測試前軟件產(chǎn)品經(jīng)內(nèi)部嚴(yán)格測試，檢查系統(tǒng)是否滿足用戶需求和符合實(shí)際應(yīng)用環(huán)境的需要，從而增強(qiáng)客戶對項(xiàng)目成功的信心。我們定義了五個(gè)測試檢查過程，包括單元測試、集成測試、系統(tǒng)測試、客戶驗(yàn)收測試以及確認(rèn)缺陷已正確修復(fù)的回歸測試。單元測試由開發(fā)人員自行負(fù)責(zé)，測試通過標(biāo)準(zhǔn)由系統(tǒng)分析員制定，測試團(tuán)隊(duì)核準(zhǔn)，確保開發(fā)人員在提交代碼前在本地已經(jīng)過測試，主流程可以跑通，可以進(jìn)入集成測試階段。主要目的是通過自查自糾減少返工以及降低后續(xù)測試階段中開發(fā)人員與測試人員之間的來回溝通成本。集成測試由系統(tǒng)分析員負(fù)責(zé)，通過集成開發(fā)人員提交的代碼，利用Ant等自動化工具發(fā)布到測試環(huán)境。系統(tǒng)分析員選取典型的測試用例對軟件產(chǎn)品進(jìn)行測試，確保業(yè)務(wù)模塊在操作過程中沒有出現(xiàn)重大的業(yè)務(wù)邏輯錯(cuò)誤以及頁面方面的低級錯(cuò)誤，可以提交到測試團(tuán)隊(duì)進(jìn)行進(jìn)一步的深入測試。測試過程如出現(xiàn)問題，進(jìn)一步分析產(chǎn)生原因和影響分析后提交到JIRA系統(tǒng)中交由開發(fā)人員處理，同時(shí)在JIRA系統(tǒng)上進(jìn)行缺陷跟蹤。系統(tǒng)測試由測試團(tuán)隊(duì)負(fù)責(zé)，依照經(jīng)過評審的測試用例對已發(fā)布可用于測試的軟件產(chǎn)品進(jìn)行全面的功能性測試，確保系統(tǒng)滿足功能需求。測試過程中，發(fā)現(xiàn)的問題連同問題出現(xiàn)時(shí)的系統(tǒng)截圖一并提交到JIRA系統(tǒng)中，由系統(tǒng)分析員分析后轉(zhuǎn)由開發(fā)人員實(shí)施缺陷修復(fù)，同樣的，在JIRA系統(tǒng)中進(jìn)行缺陷跟蹤?？蛻趄?yàn)收測試由客戶需求負(fù)責(zé)人負(fù)責(zé)，測試團(tuán)隊(duì)配合完成。測試的過程也是對客戶系統(tǒng)操作培訓(xùn)的過程，必要時(shí)，由系統(tǒng)分析員給客戶演示和解釋?？蛻粜枨筘?fù)責(zé)人往往是業(yè)務(wù)骨干，精通業(yè)務(wù)規(guī)則，熟悉業(yè)務(wù)流程和操作，可以對系統(tǒng)進(jìn)行更深入的功能測試，發(fā)現(xiàn)隱藏較深的缺陷或者因?yàn)榭紤]不周引致的設(shè)計(jì)缺陷?；貧w測試由測試團(tuán)隊(duì)負(fù)責(zé)，根據(jù)JIRA系統(tǒng)上的缺陷修復(fù)狀態(tài)，對已包含缺陷修復(fù)的版本進(jìn)行驗(yàn)證測試。測試過程不單是對缺陷修復(fù)進(jìn)行驗(yàn)證，同時(shí)對因修復(fù)缺陷影響到的其他模塊進(jìn)行回歸測試，確保缺陷被正確修復(fù)的同時(shí)不影響原有模塊以及不引入新的缺陷。由于回歸測試的工作量很大，我們使用QTP工具，通過錄制測試腳本，使回歸測試可以自動化執(zhí)行，減輕測試團(tuán)隊(duì)的負(fù)擔(dān)，提高工作效率。每周的測試情況以測試周報(bào)的形式體現(xiàn)，周報(bào)內(nèi)容包括測試范圍、測試過程中遇到的問題以及解決方法等。另外，周報(bào)還報(bào)告了缺陷的統(tǒng)計(jì)信息，包括缺陷總數(shù)(其中：本周新增的缺陷)、已關(guān)閉的缺陷總數(shù)(其中：本周關(guān)閉的缺陷)、已處理但未關(guān)閉的缺陷總數(shù)、正在處理的缺陷總數(shù)以及未處理的缺陷總數(shù)。通過這些信息基本上可以看出軟件系統(tǒng)的缺陷趨勢，從而為后續(xù)的決策提供量化支持。測試發(fā)現(xiàn)的缺陷我們使用JIRA系統(tǒng)進(jìn)行跟蹤和監(jiān)控。測試人員在系統(tǒng)上提bug，由相應(yīng)的系統(tǒng)分析員負(fù)責(zé)對缺陷進(jìn)行原因分析和影響分析，必要時(shí)與程序員一起確認(rèn)問題產(chǎn)生的原因和可能影響的模塊，分析后轉(zhuǎn)交由相應(yīng)的開發(fā)人員進(jìn)行修改，缺陷修復(fù)并經(jīng)單元測試后發(fā)布到測試環(huán)境交由測試人員進(jìn)行驗(yàn)證測試并關(guān)閉此問題，最后由客戶進(jìn)行驗(yàn)收測試后并確定發(fā)布版本和發(fā)布時(shí)間后予以發(fā)布。在這個(gè)流程中，測試人員驗(yàn)證測試時(shí)需要對該缺陷涉及的本模塊其他功能和其他模塊進(jìn)行一輪回歸測試，確保已修復(fù)的缺陷不再重復(fù)產(chǎn)生，其他功能不受影響。另外，為了確保已發(fā)現(xiàn)