作者 |蔡喁 上海控安可信軟件創(chuàng)新研究院副院長

版塊 |鑒源論壇 · 觀擎

01工具鑒定

現(xiàn)代軟件工程中，工具已經(jīng)出現(xiàn)在軟件研制過程中的各個環(huán)節(jié)中。在常見的軟件研制環(huán)節(jié)中，使用工具包括軟件需求工具、軟件設(shè)計工具、軟件架構(gòu)工具和軟件測試工具等。這些工具的使用可以提高軟件的開發(fā)效率，并且在正確使用相關(guān)工具的條件下還有望能提高軟件的質(zhì)量。當然，如果工具中存在錯誤或未能正確的使用工具，也將會帶來負面的影響。并且由于工具的功能日益強大，人類有時已經(jīng)無法對工具的輸出進行直接的判斷。

正如前文不斷提及的那樣，民用飛機時刻以安全性為最高要求。為了保證達到預(yù)期的安全水平往往不惜犧牲效率和其它性能。就民機機載軟件研制過程中使用的工具來說，風險也是顯而易見的，主要原因在于：

● 相比純手工開發(fā)，工具的輸出中隱藏的錯誤往往更加分散難以被發(fā)現(xiàn)；

● 工具生成的軟件中含有的缺陷往往難以通過手工的方式排查并加以修正；

● 相比人工活動，工具產(chǎn)生的錯誤不再是偶然的。當同樣的工具被用于多個項目中時，同樣的錯誤將被成批的復制。

為了規(guī)避工具的應(yīng)用給民機機載軟件帶來的風險，適航審定過程中通常采取將機載軟件的要求延伸到相關(guān)工具中的方法，這一方法也可以稱之為“鑒定”。工具鑒定正是DO-178C第十二章第二節(jié)所描述的內(nèi)容。為了區(qū)別工具鑒定與機載軟件的適航要求，RTCA組織在DO-178C標準推出之時也同步頒布了DO-330文件。將工具鑒定要求和方法分開處理的出發(fā)點是將基于軟件過程管理技術(shù)和方法的工具鑒定這一思路運用于各類可能需要用于證明工具自身功能或者性能的領(lǐng)域。

02DO-178C的工具鑒定要求

2.1 何時需要進行工具鑒定？

“Qualification of a tool is needed when processes of this document are eliminated, reduced or automated by the use of a software tool without its output being verified as specified in section 6.” （RTCA DO-178C 12.2）

“當使用軟件省略、減少或自動化了本文所要求的過程，并且沒有采用本文件第六章的要求對輸出進行驗證，則工具需要鑒定。”（RTCA DO-178C第12.2節(jié)）

上文描述了工具鑒定的兩個基本條件，分別是“省略、減少或自動化了本文所要求的過程”以及“沒有采用本文第六章的要求對輸出進行驗證?！?/p>

我們先來看看什么是“省略、減少和自動化”。從字面上來看，“省略”自然就是因為軟件工具的使用而可以省去不再執(zhí)行的軟件生命周期過程，或過程中的某些步驟；“減少”則是DO-178C要求的過程依然執(zhí)行，但是減少了過程中所包含部分活動；“自動化”顧名思義是原先標準要求的過程原先由人工執(zhí)行，現(xiàn)在被工具自動化地實現(xiàn)了。由此可以看出，“省略、減少、自動化”是工具影響到軟件過程或活動做多少和由誰做的置信度問題。下面我們通過一個例子來仔細分析上面三者間的區(qū)別。

例如，我們假設(shè)某軟件研制過程中工具A能直接從低級需求和系統(tǒng)架構(gòu)設(shè)計文件轉(zhuǎn)換并且生成全部的源代碼文件，在研制過程中無需進行人工編碼。我們看到，在這一過程中源代碼是被工具編寫出來的，所以實質(zhì)上DO-178C所描述的軟件編碼過程（Software Coding Process）是被“自動化”了。但是由于這一工具的出色性能，研制單位認為在自動轉(zhuǎn)換過程中不可能引入錯誤，從而決定不再進行對低級需求和源代碼一致性的驗證，則DO-178B第六章的驗證工作在對源代碼和目標代碼一致性驗證這點上被“省略”了。我們不妨再假設(shè)，研制單位對工具的信心非常足，以至于決定將原先執(zhí)行一類構(gòu)型控制的源代碼由于工具的使用降為二類?？梢?，在這一過程中，構(gòu)型管理過程及其活動依然保留，并且還是由人工進行，但部分過程將被“減少”。

從DO-178C的要求中我們也不難看出，如果軟件工具的使用沒有省略、減少或自動化DO-178C標準所要求的過程，則不需要對工具進行鑒定。這類工具常見的例子如構(gòu)型管理（也稱配置管理）工具。構(gòu)型管理工具協(xié)助研制團隊實現(xiàn)DO-178C第七章所要求的目標和活動，但如果它們僅僅對軟件研制過程起到輔助作用而沒有起到上文中所描述的“省略、減少或自動化”某一過程的效果，則這種工具不需要鑒定，可以在機載軟件項目中直接使用。當然，所有使用的工具都應(yīng)該在相應(yīng)的軟件研制環(huán)境計劃中描述，同時也需要將這一計劃放入構(gòu)型管理的范圍內(nèi)。

另外，還需要重點關(guān)注DO-178C關(guān)于工具鑒定條件的第二條。如果存在工具，雖然滿足上面所提的條件，即“省略、減少或自動化”了DO-178C所要求的某項活動。但如果研制單位能夠通過對工具的輸出進行全面的驗證，且驗證活動按照DO-178C第六章的要求進行，滿足第六章的目標、活動和數(shù)據(jù)要求。則這個工具也可以不進行鑒定。

2.2 如何進行工具鑒定？

“The purpose of the tool qualification process is to ensure that the tool provides confidence at least equivalent to that of the process(es) eliminated, reduced, or automated.”

“所謂工具鑒定就是為了確定工具能夠提供與其省略、減少或自動化了的過程具備同樣的適航審定置信度?！?/p>

（1）工具鑒定準則

在DO-178C中，工具被進一步根據(jù)以下三個準則分成三個類別：

準則1――“工具的輸出是機載軟件的一部分并且可能引入錯誤。”我們可以看出，這一定義與B版本中的開發(fā)工具是完全對應(yīng)的。換句話說，C版中的1類工具就是B版中所謂的“開發(fā)工具”。

準則2――“將自動驗證某些過程，并可能漏檢錯誤；同時，這些輸出被用來證明對以下過程的省略和減少是合理的：a. 并沒有被工具自動化的驗證過程；b. 可能對機載軟件產(chǎn)生影響的開發(fā)過程?！?/p>

準則3――“在預(yù)期的使用范圍內(nèi)，可能漏檢錯誤。

“事實上，準則2和準則3都是對B版本中驗證工具的進一步細分。

準則1的工具比較好分辨，就是開發(fā)過程中需求、設(shè)計、編碼或者集成過程中用到的產(chǎn)生軟件本體的數(shù)據(jù)的工具。準則3的工具則是用于驗證需求、設(shè)計、編碼或者可執(zhí)行目標碼的工具，但是其作用較為單一，不會產(chǎn)生“副作用”。準則2的工具首先是驗證工具，例如檢查數(shù)組索引越界的工具，如果因為該工具的使用，使得代碼中預(yù)防數(shù)組索引越界的代碼可以不用添加，那么該驗證工具不但影響了驗證過程，而且影響了開發(fā)過程，是一種超級驗證工具，稱之為準則2的工具。準則2的工具的另外一個例子是測試用例的生成工具，其首先作用是生成測試用例，假如此時測試用例還無需人工評審或者部分減免了人工評審其與需求的追蹤性，那么這個工具同時影響了DO-178C A-6表和A-7表中的目標，產(chǎn)生跨表的符合性表達，也是一種準則2的工具。

（2）工具鑒定等級（Tool Qualification Level）

上世紀90年代，工具的規(guī)模和功能都與今天無法同日而語。近年來，軟件工具的功能復雜度甚至超過機載軟件產(chǎn)品本身，而在老版標準中對工具鑒定要求的描述過于簡單，對于驗證工具的要求甚至只有黑盒測試的要求。這與DO-178C標準中對整個機載軟件開展全面系統(tǒng)的研制保證管理的要求差距較大。因此，DO-178C標準在考慮上面提到的工具分類準則的基礎(chǔ)上，結(jié)合工具工作對象（軟件）的等級，細化了工具鑒定等級的要求。

在上述對工具分級的基礎(chǔ)上，DO-178C標準要求工具鑒定的過程依據(jù)DO-330標準的相應(yīng)要求進行。

03工具操作要求

我們不難發(fā)現(xiàn)，不論是開發(fā)工具還是驗證工具，在工具鑒定中都涉及工具操作需求。常見的誤解通常認為，工具操作需求是一份類似于使用說明書的文件。我們也曾發(fā)現(xiàn)沒有取證經(jīng)驗的研制單位因為無法提交令人信服的軟件操作需求而造成工具無法通過鑒定的情況。事實上，工具的操作需求作為工具鑒定活動中必須準備的生命周期數(shù)據(jù)，應(yīng)該按照軟件生命周期數(shù)據(jù)中的軟件高級或低級需求的標準來編制。并且嚴格的執(zhí)行適用的構(gòu)型管理和更改控制。工具的操作需求起到機載軟件驗證過程中系統(tǒng)需求的作用，而工具的鑒定活動因此更加類似與我們經(jīng)常進行的系統(tǒng)審查。我們除了對工具的操作需求其精確性和正確性進行評審之外，還需考慮工具在預(yù)期運行環(huán)境下的功能測試、魯棒性測試以及需求和結(jié)構(gòu)覆蓋率分析等，而工具軟件的高級需求則被作為符合工具操作需求的軟件高級需求來對待。

審核編輯黃宇