基于敏捷思想的CMM編碼檢查方法研究

徐東，祁薇，張曉雯

（海軍大連艦艇學(xué)院基礎(chǔ)部，大連 116018）

0 引言

軟件產(chǎn)品已經(jīng)在各個(gè)領(lǐng)域得到廣泛應(yīng)用，軟件產(chǎn)品質(zhì)量亦變得越來越重要。軟件產(chǎn)品中存在的不足與缺陷會造成非常嚴(yán)重的后果，如2011年的溫州動車追尾事故所導(dǎo)致的212人傷亡事件等。軟件產(chǎn)品質(zhì)量對每個(gè)軟件開發(fā)團(tuán)隊(duì)提出了更高的要求，軟件產(chǎn)品質(zhì)量在軟件開發(fā)過程中的重要性也是不言而喻的。在軟件開發(fā)領(lǐng)域，CMM已經(jīng)越來越受到重視，高質(zhì)量的編碼是提高CMM軟件產(chǎn)品質(zhì)量的重要保證，除對編碼人員的業(yè)務(wù)水平、團(tuán)隊(duì)的整體能力有要求外，更需要一套科學(xué)的行之有效的編碼檢查方法與過程控制策略，盡早地發(fā)現(xiàn)軟件產(chǎn)品的缺陷，從而降低軟件開發(fā)與測試成本。

1 CMM模型概況

CMM模型，英文全稱為Software Capability Maturity Model，是軟件開發(fā)單位在進(jìn)行軟件產(chǎn)品開發(fā)時(shí)，對其軟件產(chǎn)品開發(fā)過程的各個(gè)階段的進(jìn)行性描述，包括對過程和階段性產(chǎn)品等的定義、實(shí)施辦法、度量標(biāo)準(zhǔn)、控制手段和改善機(jī)制等，其核心思想是將軟件產(chǎn)品的開發(fā)過程看作為一個(gè)逐步發(fā)展的過程，并依此對軟件產(chǎn)品開發(fā)過程和軟件產(chǎn)品維護(hù)等方面進(jìn)行強(qiáng)調(diào)過程特性的質(zhì)量監(jiān)控。CMM可以較為科學(xué)地對軟件產(chǎn)品開發(fā)單位的軟件產(chǎn)品研制及開發(fā)能力進(jìn)行評價(jià)，并幫助其實(shí)施軟件開發(fā)質(zhì)量自檢，進(jìn)一步完善和改進(jìn)其軟件產(chǎn)品開發(fā)過程控制方法，提高軟件開發(fā)的質(zhì)量和效率。CMM共分5個(gè)級別，隨著CMM級別的提高，軟件可靠性將有數(shù)量級的改進(jìn)[1]。

目前很多軟件開發(fā)組織都已經(jīng)實(shí)施了CMM，甚至CMMI，隨著CMM軟件產(chǎn)品復(fù)雜程度和規(guī)模的增加，軟件測試作為一種保證基于CMM模型進(jìn)行軟件開發(fā)的軟件質(zhì)量的手段，目前尤其受人們的重視。相對于敏捷方法，傳統(tǒng)的如瀑布模型等軟件開發(fā)過程方法，越來越無法滿足當(dāng)前高質(zhì)量高效率軟件產(chǎn)品開發(fā)的要求，測試人員不能在設(shè)定的控制點(diǎn)之前測試，這就導(dǎo)致此前無法找到編碼設(shè)計(jì)缺陷；而等到了該控制點(diǎn)，再根據(jù)該點(diǎn)的原測試要求進(jìn)行測試，編碼上可能就會累積大量的缺陷設(shè)計(jì)，此時(shí)再進(jìn)行編碼修復(fù)，肯定會導(dǎo)致一系列的編碼重寫或變動，嚴(yán)重影響了軟件開發(fā)進(jìn)程。CMM作為一個(gè)復(fù)雜的過程體系，在軟件測試過程控制方面，有著很多的參考做法，但在CMM中基于敏捷思想的實(shí)踐做法數(shù)量卻有限，且很多都涉及到與敏捷思想的融合問題[2]。實(shí)際上，CMM與敏捷思想在適用范圍、做法等諸多方面上還是存在差異的，不但存在著明顯的區(qū)別甚至對立，還存在著一定的互補(bǔ)關(guān)系，創(chuàng)建一組基于敏捷思想的CMM軟件測試模型和方法，可以取得更好的軟件開發(fā)效率。

2 敏捷的核心思想

敏捷在軟件開發(fā)過程中主要體現(xiàn)了以人為本的理念，開發(fā)過程以循序漸進(jìn)、階段性迭代作為其軟件開發(fā)的主要特征，及時(shí)滿足軟件不斷變更的需求。敏捷宣言強(qiáng)調(diào)團(tuán)隊(duì)行為，個(gè)體能力付出與及時(shí)交流并重，強(qiáng)調(diào)任何可測階段的軟件都是可用的，強(qiáng)調(diào)各方協(xié)作而不是談判，強(qiáng)調(diào)開發(fā)過程的動態(tài)調(diào)整而不是必須按部就班。敏捷軟件過程開發(fā)中，先將整體項(xiàng)目切分成多個(gè)子項(xiàng)目，每個(gè)子項(xiàng)目獨(dú)立完成，但各子項(xiàng)目之間又相互聯(lián)系，每一個(gè)子項(xiàng)目都要經(jīng)過軟件測試，保證各子項(xiàng)目都能成功運(yùn)行，在整個(gè)開發(fā)過程中，軟件始終處于可用狀態(tài)。敏捷開發(fā)提倡盡早測試，即只要有可能就進(jìn)行測試，這種方式更容易在項(xiàng)目早期發(fā)現(xiàn)及控制缺陷數(shù)目。

3 編碼檢查

編碼檢查是一種高效的軟件測試手段，通過編碼檢查能夠盡早地發(fā)現(xiàn)軟件已經(jīng)存在或潛在的缺陷，找出動態(tài)軟件測試難以發(fā)現(xiàn)或隔離的軟件設(shè)計(jì)缺陷。事實(shí)證明，越早發(fā)現(xiàn)編碼缺陷，越有利于降低整體軟件測試的成本。另外，編碼檢查能夠?yàn)檐浖_發(fā)過程中的動態(tài)測試過程設(shè)計(jì)、測試用例制定及使用提供思路。

但當(dāng)前的CMM軟件編碼檢查主要采用傳統(tǒng)的方法，這種傳統(tǒng)方法通常只關(guān)注代碼本身的邏輯問題，如語義語法錯(cuò)誤等，沒有與該軟件產(chǎn)品所處的專業(yè)領(lǐng)域知識相關(guān)聯(lián)，不易及時(shí)發(fā)現(xiàn)編碼專業(yè)功能等方面的問題，而必須等待功能測試環(huán)節(jié)才能發(fā)現(xiàn)，勢必會造成編碼缺陷的累積，也會影響軟件開發(fā)過程。

針對傳統(tǒng)的編碼檢查方法存在的一系列問題，采用與專業(yè)領(lǐng)域相結(jié)合的編碼檢查方法。即在傳統(tǒng)的編碼檢查方法基礎(chǔ)上，將通用編碼檢查與相關(guān)的專業(yè)領(lǐng)域知識相結(jié)合，組建基于某專業(yè)領(lǐng)域的編碼檢查清單。首先建立針對不同軟件開發(fā)語言的通用編碼檢查知識庫，如C語言；然后根據(jù)該軟件產(chǎn)品所涉及的專業(yè)領(lǐng)域，將軟件產(chǎn)品從功能上進(jìn)行劃分，建立某專業(yè)領(lǐng)域編碼檢查要素知識庫；最后將以上兩個(gè)知識庫進(jìn)行融合，形成基于某專業(yè)領(lǐng)域的編碼檢查清單[3]。

4 CMM編碼檢查的敏捷方案

4.1 工作流的元定義[ 4]

工作流已經(jīng)得到很多驗(yàn)證，這項(xiàng)技術(shù)與管理模式可以有效降低軟件產(chǎn)品的開發(fā)風(fēng)險(xiǎn)，業(yè)務(wù)流程更加可控、更容易維護(hù)，新業(yè)務(wù)流程的部署也會變得相對容易，提高了對軟件產(chǎn)品迭代開發(fā)的支持。因此，在敏捷開發(fā)與測試中，使用工作流系統(tǒng)可使軟件開發(fā)更有效、風(fēng)險(xiǎn)更低。工作流管理聯(lián)盟這個(gè)組織定義了元模型,其全稱為Process Definition Meta-mode，簡稱為PDM結(jié)構(gòu)，如圖1所示。

圖1 PDM元模型

4.2 CMM編碼檢查應(yīng)用H模型

模型中，CMM軟件開發(fā)與編碼檢查并發(fā)執(zhí)行，構(gòu)成基于工作流的H型模型結(jié)構(gòu)[5-6]，其中編碼檢查工作流引擎為其核心部件，整個(gè)過程中強(qiáng)調(diào)盡早測試等敏捷測試原則，如圖2所示。過程控制的基本流程為：

（1）由編碼檢查及編碼人員共同建立編碼檢查事例庫；

（2）由任務(wù)分配來觸發(fā)編碼檢查的工作流引擎，制定各階段的檢查方案，并由編碼專家及檢查專家共同評審檢查方案，通過后進(jìn)行檢查。若檢查結(jié)果無誤，則執(zhí)行檢查評估并填寫相關(guān)文檔，若檢查有誤則產(chǎn)生相關(guān)編碼缺陷報(bào)告并提交審核；

（3）審核編碼缺陷報(bào)告，如果發(fā)現(xiàn)的編碼缺陷是可以修正的，則作為新任務(wù)對象再次進(jìn)行分配；

（4）由任務(wù)分配來再次觸發(fā)編碼檢查工作流引擎（編碼缺陷修正），由編碼人員進(jìn)行編碼修正，自測成功后進(jìn)入編碼回歸檢查階段；

（5）回歸檢查將上步修正后的編碼作為新任務(wù)進(jìn)行任務(wù)再分配；觸發(fā)引擎，回到（2）進(jìn)行迭代，當(dāng)再無編碼缺陷時(shí)執(zhí)行關(guān)閉。

圖2 編碼檢查應(yīng)用模型

4.3 編碼檢查用例缺陷狀態(tài)

軟件開發(fā)過程的每個(gè)階段都可能產(chǎn)生編碼缺陷，在整個(gè)軟件開發(fā)過程中對編碼缺陷實(shí)行全程跟蹤管理是非常必要的，因?yàn)檫@種編碼缺陷有可能是由上一個(gè)階段的工作失誤造成。在理想狀態(tài)下，編碼缺陷的狀態(tài)以及編碼缺陷狀態(tài)之間的流轉(zhuǎn)路徑能夠根據(jù)編碼檢查人員的預(yù)定要求在編碼檢查之前進(jìn)行設(shè)置[7]。新發(fā)現(xiàn)的編碼缺陷或沒被修改的編碼缺陷要提交給編碼人員進(jìn)行編碼缺陷修正，待編碼人員完成編碼缺陷修復(fù)后，再次提交編碼檢查，如經(jīng)過檢查后確定編碼缺陷已被修正，則標(biāo)記“已修正”；如果編碼沒有修正成功，則將作為新編碼缺陷再次提交修正。另外，如果編碼檢查人員發(fā)現(xiàn)的編碼缺陷是潛在的并且馬上修正代價(jià)過高，則在其不影響當(dāng)前階段性檢查的情況下推遲至下階段。

4.4 編碼檢查任務(wù)分配

編碼檢查任務(wù)的分配要依照四步原則進(jìn)行，即計(jì)劃、執(zhí)行、檢查、調(diào)整，無論哪個(gè)階段的編碼檢查，必須先制定相應(yīng)計(jì)劃，明確編碼檢查步驟和檢查用例，與此同時(shí)，要明確檢查的時(shí)間和資源消耗等，依此進(jìn)行人員和任務(wù)分配[8]。

4.5 編碼檢查用例

編碼檢查團(tuán)隊(duì)中必須包含兩類成員：一是精通編碼語言的程序設(shè)計(jì)專家，二是專業(yè)領(lǐng)域?qū)＜遥☉?yīng)具備大型軟件開發(fā)經(jīng)驗(yàn)），兩類專家注重溝通，共同制定編碼檢查方案，檢查方案隨著軟件開發(fā)進(jìn)度的不同以及項(xiàng)目的不同動態(tài)調(diào)整編碼檢查清單。

編碼檢查用例采用基于某專業(yè)領(lǐng)域的編碼檢查清單中的用例，并將用例分靜態(tài)和動態(tài)兩種狀態(tài)，規(guī)定只有動態(tài)用例才能參與真正的編碼檢查活動，所以，必須將任務(wù)分配后的編碼檢查用例狀態(tài)由靜態(tài)改成動態(tài)。實(shí)施中，靜態(tài)檢查用例包括通用數(shù)據(jù)與專業(yè)領(lǐng)域數(shù)據(jù)及邏輯，動態(tài)檢查用例的標(biāo)記包括檢查用例的狀態(tài)、檢查結(jié)果以及檢查報(bào)告等信息進(jìn)行標(biāo)記，可用“尚未檢查、檢查通過、檢查失敗、檢查出設(shè)計(jì)問題”四個(gè)狀態(tài)來跟蹤編碼檢查用例的執(zhí)行情況。

5 結(jié)語

本著敏捷開發(fā)原則并結(jié)合專業(yè)領(lǐng)域知識進(jìn)行編碼檢查，做到有需要就檢查，盡量早地發(fā)現(xiàn)錯(cuò)誤并改正錯(cuò)誤。同時(shí)編碼檢查可分為自查和驗(yàn)收性檢查兩種，自查應(yīng)在開發(fā)團(tuán)隊(duì)內(nèi)進(jìn)行，并把編碼自查看作是軟件開發(fā)的一部分，且是重要的優(yōu)化手段；驗(yàn)收性檢查一般由項(xiàng)目管理者或上級負(fù)責(zé)，包括階段性驗(yàn)收檢查。本文模型可以使整個(gè)編碼檢查過程更加清晰，使軟件產(chǎn)品質(zhì)量得以保證、提高開發(fā)效率，對中小型軟件開發(fā)有著很好的適用性。

參考文獻(xiàn)：

[1]俞磊，白尚旺，黨偉超等.基于CMM-3的軟件測試過程模型的研究[J].計(jì)算機(jī)與數(shù)字工程，2011（7）：79-82.

[2]徐俊，彭章綱.敏捷開發(fā)過程與CMMI實(shí)施融合研究[J].現(xiàn)代計(jì)算機(jī)，2011（12）:21-23.

[3]周景科.專業(yè)領(lǐng)域軟件的代碼審查方法研究[J].軟件產(chǎn)品可靠性與環(huán)境試驗(yàn)，2016（6）：39-44.

[4]趙瑞東等.工作流與工作流管理技術(shù)綜述[J].科技信息，2007（8）：105-107.

[5]徐東，張曉雯等.CMM軟件測試H模型研究[J].軟件工程師，2014（4）：11-13.

[6]張曉雯，徐東.基于工作流的軟件測試H模型研究[J].軟件導(dǎo)刊，2013（2）：24-26.

[7]吳慧韞.基于工作流的軟件測試管理系統(tǒng)研究與設(shè)計(jì)[D].南昌：南昌大學(xué)，2005.

[8]鄭小軍等.基于工作流技術(shù)的軟件測試流程定義與監(jiān)控[J].計(jì)算機(jī)應(yīng)用研究，2007（2）：43-45.