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

徐東，祁薇，張曉雯

（海軍大連艦艇學院基礎部，大連 116018）

0 引言

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

1 CMM模型概況

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

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

2 敏捷的核心思想

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

3 編碼檢查

編碼檢查是一種高效的軟件測試手段，通過編碼檢查能夠盡早地發現軟件已經存在或潛在的缺陷，找出動態軟件測試難以發現或隔離的軟件設計缺陷。事實證明，越早發現編碼缺陷，越有利于降低整體軟件測試的成本。另外，編碼檢查能夠為軟件開發過程中的動態測試過程設計、測試用例制定及使用提供思路。

但當前的CMM軟件編碼檢查主要采用傳統的方法，這種傳統方法通常只關注代碼本身的邏輯問題，如語義語法錯誤等，沒有與該軟件產品所處的專業領域知識相關聯，不易及時發現編碼專業功能等方面的問題，而必須等待功能測試環節才能發現，勢必會造成編碼缺陷的累積，也會影響軟件開發過程。

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

4 CMM編碼檢查的敏捷方案

4.1 工作流的元定義[ 4]

工作流已經得到很多驗證，這項技術與管理模式可以有效降低軟件產品的開發風險，業務流程更加可控、更容易維護，新業務流程的部署也會變得相對容易，提高了對軟件產品迭代開發的支持。因此，在敏捷開發與測試中，使用工作流系統可使軟件開發更有效、風險更低。工作流管理聯盟這個組織定義了元模型,其全稱為Process Definition Meta-mode，簡稱為PDM結構，如圖1所示。

圖1 PDM元模型

4.2 CMM編碼檢查應用H模型

模型中，CMM軟件開發與編碼檢查并發執行，構成基于工作流的H型模型結構[5-6]，其中編碼檢查工作流引擎為其核心部件，整個過程中強調盡早測試等敏捷測試原則，如圖2所示。過程控制的基本流程為：

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

（2）由任務分配來觸發編碼檢查的工作流引擎，制定各階段的檢查方案，并由編碼專家及檢查專家共同評審檢查方案，通過后進行檢查。若檢查結果無誤，則執行檢查評估并填寫相關文檔，若檢查有誤則產生相關編碼缺陷報告并提交審核；

（3）審核編碼缺陷報告，如果發現的編碼缺陷是可以修正的，則作為新任務對象再次進行分配；

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

（5）回歸檢查將上步修正后的編碼作為新任務進行任務再分配；觸發引擎，回到（2）進行迭代，當再無編碼缺陷時執行關閉。

圖2 編碼檢查應用模型

4.3 編碼檢查用例缺陷狀態

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

4.4 編碼檢查任務分配

編碼檢查任務的分配要依照四步原則進行，即計劃、執行、檢查、調整，無論哪個階段的編碼檢查，必須先制定相應計劃，明確編碼檢查步驟和檢查用例，與此同時，要明確檢查的時間和資源消耗等，依此進行人員和任務分配[8]。

4.5 編碼檢查用例

編碼檢查團隊中必須包含兩類成員：一是精通編碼語言的程序設計專家，二是專業領域專家（應具備大型軟件開發經驗），兩類專家注重溝通，共同制定編碼檢查方案，檢查方案隨著軟件開發進度的不同以及項目的不同動態調整編碼檢查清單。

編碼檢查用例采用基于某專業領域的編碼檢查清單中的用例，并將用例分靜態和動態兩種狀態，規定只有動態用例才能參與真正的編碼檢查活動，所以，必須將任務分配后的編碼檢查用例狀態由靜態改成動態。實施中，靜態檢查用例包括通用數據與專業領域數據及邏輯，動態檢查用例的標記包括檢查用例的狀態、檢查結果以及檢查報告等信息進行標記，可用“尚未檢查、檢查通過、檢查失敗、檢查出設計問題”四個狀態來跟蹤編碼檢查用例的執行情況。

5 結語

本著敏捷開發原則并結合專業領域知識進行編碼檢查，做到有需要就檢查，盡量早地發現錯誤并改正錯誤。同時編碼檢查可分為自查和驗收性檢查兩種，自查應在開發團隊內進行，并把編碼自查看作是軟件開發的一部分，且是重要的優化手段；驗收性檢查一般由項目管理者或上級負責，包括階段性驗收檢查。本文模型可以使整個編碼檢查過程更加清晰，使軟件產品質量得以保證、提高開發效率，對中小型軟件開發有著很好的適用性。

參考文獻：

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

[2]徐俊，彭章綱.敏捷開發過程與CMMI實施融合研究[J].現代計算機，2011（12）:21-23.

[3]周景科.專業領域軟件的代碼審查方法研究[J].軟件產品可靠性與環境試驗，2016（6）：39-44.

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

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

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

[7]吳慧韞.基于工作流的軟件測試管理系統研究與設計[D].南昌：南昌大學，2005.

[8]鄭小軍等.基于工作流技術的軟件測試流程定義與監控[J].計算機應用研究，2007（2）：43-45.