借鑒嵌入式系統開發人員經驗教訓確保構建的嵌入式系統達成目標

工程師一刻也沒忘記交付達到質量、時間安排和預算目標的項目的需求。您可以借鑒嵌入式系統開發人員社區多年來累計的經驗教訓，確保您下一個嵌入式系統項目達成這些目標。下面我們來了解一些為嵌入式開發帶來了最佳實踐的重要經驗。

系統地思考

系統工程是一個廣泛的專業領域，覆蓋從航空母艦及衛星到實現其性能的嵌入式系統的所有開發工作。我們可以運用系統工程方法管理從概念到使用周期結束處置的嵌入式系統工程生命周期。系統工程方案的第一階段跟常人想象的不一樣，，不是確立系統需求，而是制定系統工程管理規劃。這一規劃不僅將為系統定義工程生命周期以及開發團隊將要開展的設計評審，而且還將定義這些評審的預期輸入輸出。該規劃可根據工程事件的次序和每個階段的先決條件，為項目管理、工程和客戶群體做出明確的定義。簡而言之，它可展示預期和可交付項。在清楚理解工程生命周期的情況下，系統思考的下一步是確立正在開發嵌入式系統的需求。良好的需求集應覆蓋三個方面。功能需求定義嵌入式系統如何開展工作。非功能需求定義法規遵從與可靠性等方面的問題。環境需求定義工作溫度和沖擊與振動以及電氣環境（例如 EMI 和 EMC）等方面的需求。在較大規模的開發工作中，這些需求將從較高層次的規范向下延伸并且可跟蹤，比如系統或子系統規范（圖 1）。如果沒有較高層次的規范，我們必須在開發過程中接觸利益相關方，確立一套明確的利益相關方需求，然后將其用于確立嵌入式系統需求。

生成一個良好的需求集,需要我們充分思考每一個需求，才能確保其符合這些標準：
1.它是必要的。沒有需求,我們的項目就不會取得成功。
2.它是可驗證的。我們必須確保該需求能通過檢驗、測試、分析或演示實現。
3.它是可實現的。技術層面上是可以實現的。
4.它是可追蹤的。該需求能夠從較低層次的需求進行追蹤，而且可追蹤較高層次的需求。
5.它是唯一的。這項標準可防止需求之間的界限不清。
6.它是簡單清晰的。每條需求指定一項功能。

使用“應該”。非強制性要求可讓我們表達必要的系統屬性。

在我們確立了我們的需求底線后，最佳實踐就是創建一個合規矩陣，說明符合每項需求。我們還可以通過為每項需求分配一種驗證方法開始確立我們的驗證策略。這些方法一般是測試、分析、檢驗、演示和交叉讀取。根據合規及驗證矩陣創建需求能讓我們：
?

清晰地了解系統行為。?

向內部測試團隊和外部客戶都演示驗證方法。這不僅可在開發過程的早期階段發現任何困難的測試方法，而且還可幫助我們確定所需的資源。

確定技術性能指標。這些指標來自合規矩陣，由存在無法合規的風險的各種需求構成。

分配工程預算

每個工程項目都涵蓋一定數量的預算，我們應將其分配給在架構中識別的解決方案。預算分配不僅可確保項目實現整體需求,而且還可確保每個模塊的設計牽頭人理解模塊的分配，以創建適當的解決方案。我們分配預算的典型領域有功能的總質量、功能的總功耗、用平均故障間隔時間或成功概率定義的可靠性以及設計中信號類型間的正當串擾（一般是一套適用于大量功能的通用規則集）。確立工程預算最重要的方面之一是確保我們有足夠的應急分配。但我們必須戰勝應急再加應急的想法，因為這會成為影響時間安排和成本的嚴重技術問題。

為在我們架構中使用的每項技術分配一個技術就緒指數，再結合合規矩陣，可幫助我們確定技術風險的所在位置。

管理技術風險
從合規矩陣及工程預算的生成看，我們應該能夠識別在技術上有難度的需求。每一個這類有風險的需求都應該有明確的規避計劃，其將說明我們將如何實現這一需求。展示這一點的最佳途徑之一是使用技術就緒指數 (TRL)。TRL 有 9 級，從所觀察到的基本原理 (TRL1) 到完整功能與實地部署 (TRL9) 描述設計成熟度級數。把 TRL 分配給我們架構中使用的每一項技術，再結合合規矩陣，可幫助我們確定技術風險的所在位置。我們隨后可啟動一個 TRL 開發規劃，確保在項目不斷推進時，低 TRL 領域會提升到所需的 TRL 水平。該規劃涉及的內容可確保我們在項目推進時實現和測試正確的功能，或是在項目推進的過程中執行功能或環境／動態測試。