盡管大多數軟件開發組織都采用敏捷開發，但大多數嵌入式開發人員，尤其是那些尋求認證的開發人員，仍然抵制使用敏捷方法。與獲得認證所需的傳統規范方法和工件相比，開發人員認為迭代敏捷方法的風險更大。具體問題源于如何在敏捷過程中捕獲需求，以及如何在嵌入式系統硬件可用之前滿足敏捷開發的早期和經常測試原則。

反對者沒有考慮到的是已經可用的工具范圍，這些工具有助于確保在采用敏捷方法時滿足認證目標。是什么將它們編織在一起？需求可追溯性使軟件分析和驗證在每個沖刺中成為可能，硬件仿真工具使持續驗證成為可能。最后，工作流管理工具有助于將所有項目工件整合到一個協作環境中，同時定義和管理項目認證標準目標。

捕獲用戶情景

那么，如何獲得嚴謹性呢？反對者聲稱敏捷流程避開了所有認證活動所依賴的正式要求。盡管敏捷流程的開發在一整套功能需求可用之前就開始了，但這并不意味著在敏捷過程中生成的需求比傳統的規范方法更不嚴格。

敏捷方法隱含著早期和經常失敗的概念，從系統需求開始。敏捷中的前期規劃需要與客戶合作開發一系列用戶“故事”，以封裝所需的系統功能。然后定義開發過程的每次迭代處理這些故事的順序，每次迭代的目標是發布一個版本，即它完全正常運行、經過全面測試，并且是包含最高優先級功能的潛在可部署系統。

作為文檔或需求捕獲工具捕獲，用戶故事可以匯集到工作流管理工具（如LDRA的TBmanager）中。開發代碼后，可以將條目提交到工具，從而使代碼能夠追溯到用戶故事。在下游，工作流管理器還可以將代碼映射到軟件驗證活動和結果。然后，工作流管理器成為認證所需的所有驗證證據的所在地。

將質量融入軟件

為需要認證的系統生產潛在的可部署軟件需要滿足軟件的所有認證標準驗證目標，這是對敏捷口頭禪“盡早和經常失敗”的完美補充。通過靜態和動態軟件分析技術的組合實現最高水平的軟件質量，所有這些都可以從工作流管理器中訪問，以確保維護分析的結果和上下文。

靜態分析

靜態分析是指在不執行代碼的情況下審查正在開發的代碼以發現和修復質量問題的做法。例如，當您使用自動化工具驗證代碼標準合規性時，可以使用靜態分析。認證標準要求使用編碼標準和質量分析來驗證開發的代碼是否已統一設計和實施。在開發、集成、測試和驗證的所有階段實施這些標準具有以下幾個優勢：

? 消除

潛在缺陷? 通過創建統一代碼提高代碼的可讀性和可維護性? 防止過于復雜的代碼更容易出錯且更難維護

? 識別無法訪問或使代碼

覆蓋率的測試構建具有挑戰性

的代碼? 生成更模塊化的代碼，更容易追溯到低級需求

動態分析

敏捷方法使用測試來持續提供有關新興產品滿足業務需求程度的反饋。敏捷團隊不斷測試，因為這是確保每次迭代的功能都已完成并取得進展的唯一方法。

對于嵌入式系統，軟件開發取決于目標平臺的可用性，但該硬件通常要到開發生命周期的后期才可用。敏捷開發人員依靠硬件系統模擬器（如Wind River Systems Simics）來幫助填補這一空白。

這些工具模擬完整的目標系統，并且可以在仿真框架內運行未經修改的目標軟件（相同的引導加載程序、BIOS、固件、實時操作系統、板級支持包 （BSP）、中間件和應用程序）。使用硬件模擬器意味著敏捷項目的硬件相關測試可以在盡可能早的迭代中開始。

作為補充，測試自動化工具可以在模擬硬件上自動生成和執行測試用例。可以經常運行自動測試用例生成和執行，在幾分鐘內提供反饋。然后，可以從工作流管理器中控制這些測試的測試用例生成、執行、結果和狀態，以提供對當前迭代進度的可見性。

對于認證，有必要使用代碼覆蓋率來衡量測試完整性。認證需要適當程度的測試嚴格性，這意味著所有測試都必須基于需求并在系統級別執行。如果沒有代碼覆蓋率分析，就不可能獲得提高測試有效性所需的反饋、知識和理解，并且它提供了額外的保證措施，即滿足當前迭代的潛在可部署系統目標。

認證和文件

使用工作流管理器作為所用工具和在整個開發過程中生成的結果的主機，使生成認證所需的文檔變得非常簡單。可以從該工具訪問所有項目工件，從而有助于準備要呈現給證書頒發機構的數據。

這也是為尋求認證的項目通過嵌入式系統開發加速敏捷方法的關鍵。在工作流管理器中管理項目工件有助于確保從需求到基于主機和目標的驗證結果，它們在敏捷項目的每次迭代中都得到維護。

審核編輯：郭婷