Eduardo Lluna擁有巴倫西亞大學的物理學位和巴倫西亞大學理工學院電子工程系的博士學位。他一向對于軟件測試，電子測量設備和感測網(wǎng)路方面的研究都很積極。Lluna有20多年的關于交通控制，公眾視野，支付，電信系統(tǒng)領域的即時嵌入系統(tǒng)的軟件的專業(yè)經(jīng)驗。他曾在SICE， Telvent還有 Design of Systems on Silicon (DS2)公司任過職。他是巴倫西亞大學計算機科學部的副教授，且自2011年1月起，已在ITI公司的軟件質量部擔任協(xié)助不同研發(fā)項目的項目經(jīng)理。更多詳細資料，見：www.linkedin.com/in/elluna。
	Maximiliano Mannise擁有烏拉圭天主教大學的計算機工程學位。他是西班牙巴倫西亞ITI公司軟件質量部的負責人。Maximiliano在烏拉圭蒙得維的亞大學擔任過教授，還參與過西班牙政府或業(yè)內所創(chuàng)建的關于軟件質量和軟件測試的調研項目。 自2007年起，他一直在ITI公司從事與軟件質量測試，研究及傳播活動（如：VLCTESTING）相關的項目。之前，他還在烏拉圭IBM工作過9年多，包括2年多的測試項目經(jīng)理。Maximiliano對實際測試過程提升及用于測試項目的項目管理很感興趣。更多詳細資料，見：www.linkedin.com/in/mmannise。

　　代碼驗證包括檢查一些規(guī)則，并且隨著項目安全水平的提升，需要檢查的規(guī)則的數(shù)量也要增加。可以用不同的工具檢查，驗證團隊獨立于開發(fā)團隊之外的情況在安全關鍵系統(tǒng)中并不常見。集中式系統(tǒng)需要處理所有的缺陷信息并輕松生成報告。本文展示了一個開發(fā)用以管理大型項目的驗證結果的數(shù)據(jù)管理系統(tǒng)。解決方案基于一個商務智能引擎。

　　1.引言
　　代碼驗證過程包括檢查特定規(guī)則被遵守且特定代碼如指定的執(zhí)行�？梢允止�檢查，但這是一件很累，易錯的事，所以使用自動化工具才是佳選擇。要接受檢查的規(guī)則數(shù)量是可變的且依賴項目安全水平。隨著項目變大且安全水平增加，需要檢查的規(guī)則的數(shù)量及要執(zhí)行的代碼變得很高，使用自動化驗證工具勢在必行。
　　驗證任務由一個團隊或一個不同于通常負責開發(fā)安全關鍵系統(tǒng)的公司執(zhí)行時，所有檢查結果都必須被管理以生成缺陷報告并計算可以被及時交付給開發(fā)團隊的項目進展指標。一般情況下，不同的工具要進行所有的檢查（通常是靜態(tài)和動態(tài)分析），因此信息將來自于不同源頭并且是不同的形式。管理來源不同的大量信息產(chǎn)生了問題，工具要匯總所有缺陷信息并管理它們以計算指標并以集中方式生成報告。
　　本文展現(xiàn)了按嚴格安全要求創(chuàng)建以管理大型項目驗證任務的數(shù)據(jù)管理系統(tǒng)。解決方案是基于一個商務智能引擎的。
　　本文結構如下。第二部分簡要概述了驗證任務。第三部分介紹了推薦的驗證流程，描述了不同活動和產(chǎn)品。第四部分講了內部執(zhí)行和商務智能引擎。第五部分展示了一些使用工具的真實案例結果。后，第六部分做了一些總結。

　　2.驗證任務
　　驗證包括檢查任務中創(chuàng)造的產(chǎn)品滿足要求且正確。有各種驗證技術，項目定義中的一項重要任務是為制定項目選擇正確的驗證技術。安全關鍵的開發(fā)是按標準管理的，比如：IEC 61508-3， EN-50128， DO-178B，且根據(jù)項目的安全水平，它們提供一系列可以考慮的技術。一般情況下，可以認為，所有標準中都需要有兩個基本類型的代碼分析驗證技術：靜態(tài)和動態(tài)分析。靜態(tài)分析包括檢查源代碼而不運行，并尋找被認為是危險的或易錯的結構。檢查有很多規(guī)則，包括代碼標準，但是一系列非常重要的規(guī)則是來自使用一個不安全語言的情況中的語言子集定義。大多數(shù)安全關鍵系統(tǒng)是用C或C++編碼的，且兩種語言都被認為是不安全的，所以使用它們的方法是只使用一種被認為安全的語言子集。對于C和C++，有兩種被廣泛使用的子集：MISRA C/C++和JSF。兩種子集都制定一系列必須遵守且必須檢查的規(guī)則。動態(tài)分析包含執(zhí)行部分代碼以檢查它如預期進行。過程包括定義一系列通過它的界面和（結果與規(guī)范中一致的）檢查去執(zhí)行的代碼測試用例。一般來說，驗證任務可以自動或手工執(zhí)行。優(yōu)先選自動化方法，但不可能總這樣。靜態(tài)分析可以是自動的，且有商用工具。動態(tài)分析不容易自動化，一般而言，它要求手工定義測試用例。另一個限制自動化使用的問題是：在安全關鍵系統(tǒng)中，工具必須被認證可以安全使用，因此可用工具的數(shù)量被減少了。另一個出現(xiàn)在一個真實項目中的問題是，通常，沒有一個單獨的工具可以檢查項目要求的所有的規(guī)則。認證工具很貴，有時不會選擇去買一些工具。還有一些項目或公司依賴的規(guī)則，比如檢查主文件格式，對這些任務進行腳本特別檢查。一般情況下，驗證任務必須包括開發(fā)這些特殊腳本的計劃。即使是挑選了工具，開發(fā)了腳本去執(zhí)行特殊檢查后，一些規(guī)則因為它們的復雜性而無法自動化，所以驗證過程必須包括一些將被驗證和驗證工程師執(zhí)行的手動檢查。無論如何，手動檢查的結果必須被輸入管理系統(tǒng)。驗證過程中的另一個重要因素是度量計算。一些度量是由工具計算的且如果值超出范圍時它們可被當做一個缺陷（圈復雜，嵌套級別，函數(shù)長度等）。但也有其他度量是關于追蹤基于隨版本而變化的參數(shù)的過程演變的，所以有必要保存所有的信息并可隨時用于計算這些度量。這些度量的一個實例是Stability Index，它提供了一個版本間變化的指示，每個版本的既定類型的缺陷數(shù)量，等。

　　3.建議流程
　　驗證流程必須考慮一些可以自動執(zhí)行的任務及及其他手動執(zhí)行的任務，但是所有情況下，都要把信息存到信息系統(tǒng)中�；�本工作流程如圖1所示。流程開始輸入源代碼，后輸出關于代碼質量的報告，基本是一大堆沒達到的規(guī)則。獲取數(shù)據(jù)的流程包括使用各種工具執(zhí)行所有要求進行的檢查。數(shù)據(jù)輸入模塊是數(shù)據(jù)存儲的進入點它獲取不同來源不同形式的信息并存入數(shù)據(jù)庫。數(shù)據(jù)來源有三個基本類型：商業(yè)分析工具，特別編寫的腳本，和手工檢查。手工檢查中，有一個搜集數(shù)據(jù)并創(chuàng)建一個（給數(shù)據(jù)輸入模塊使用的文件的）特別腳本。數(shù)據(jù)輸入功能使用一個固定格式的XML文件。開發(fā)的腳本以正確的文件格式創(chuàng)建輸出，但是用轉化層將商業(yè)工具的輸出轉化為正確的格式。存儲和處理系統(tǒng)也能充分利用接收到的所有數(shù)據(jù)并生成報告。

圖1.流程概貌

　　數(shù)據(jù)庫不允許刪除缺陷，但是當算沒有滿足規(guī)定也有正當理由可以違背時，有一個機制接受缺陷。接受機制要求一個人的識別要負責接受并包含接受的具體理由�？杀唤邮艿娜毕菘梢员豢偨Y并列在報告中。圖2展示了具體流程。如之前所見，靜態(tài)分析包括自動化和手動任務。自動化任務直接提供一個如輸出所示的XML文件，但是手動分析的結果也必須被處理以生成一個XML文件。動態(tài)分析并不是完全自動化的。測試用例必須手動定義，但其執(zhí)行是自動的，結果被存入XML文件中。也要給數(shù)據(jù)庫提供關于度量和檢查規(guī)則的信息。