因此，軟件開發(fā)過程都是經(jīng)過深思熟慮、計(jì)劃、記錄、結(jié)構(gòu)化和到位的。您已經(jīng)在測試工具上投入了大量資金，這些工具可以生成您可能需要的盡可能多的工件。您有來自靜態(tài)分析、動(dòng)態(tài)分析、功能測試、單元測試、對象代碼驗(yàn)證的報(bào)告。沒有任何機(jī)會(huì)。一切都準(zhǔn)備就緒，為評(píng)估小組的猛攻做好了準(zhǔn)備。帶上它！

（輪胎在以每小時(shí)一百英里的速度行駛后尖叫停止的聲音。

DO-178B/C 充斥著對可追溯性的引用，而您的傳統(tǒng)測試文檔都沒有提供可追溯性。更重要的是，可追溯性必須雙向工作——下游（需求到實(shí)施）和上游（植入到需求）?！半p向可追溯性”可能只是一個(gè)兩個(gè)字的短語，但當(dāng)涉及到軍事嵌入式系統(tǒng)時(shí)，它卻是一個(gè)沉重的打擊。為了理解它的重要性，讓我們看看軟件的演變。

幾十年前，瀑布式流程以其獨(dú)特的分析、設(shè)計(jì)、編碼和測試階段主導(dǎo)了軟件開發(fā)。該理論是每個(gè)階段都將獨(dú)立執(zhí)行，一個(gè)階段的輸出是下一個(gè)階段的輸入。預(yù)期的結(jié)果是一個(gè)通過所有測試的工作系統(tǒng)。

使用瀑布式方法，分析階段的目的是完善利益相關(guān)者對系統(tǒng)的愿景，并生成需求列表，軟件需求規(guī)范 （SRS） 中逐項(xiàng)列出軟件需求。如果你能自豪地把它展示在你的書架上，你就是一個(gè)人！

當(dāng)然，在印刷運(yùn)行完成之前，由于新發(fā)現(xiàn)的錯(cuò)誤或歧義，SRS 就已經(jīng)過時(shí)了。無論項(xiàng)目經(jīng)理多么希望SRS沒有錯(cuò)誤，但事實(shí)并非如此。更改日志的大小將開始增加，直到新的打印運(yùn)行變得不可避免。SRS落后于現(xiàn)實(shí)，錯(cuò)誤是生活中的事實(shí)。

如今，需求可追溯性被廣泛接受為開發(fā)最佳實(shí)踐。它確保實(shí)現(xiàn)所有需求，并且所有開發(fā)工件都可以追溯到一個(gè)或多個(gè)需求。然而，盡管有良好的意圖，許多項(xiàng)目仍然陷入一種脫節(jié)的軟件開發(fā)模式，其中需求、設(shè)計(jì)、實(shí)現(xiàn)和測試階段彼此隔離——這通常被稱為“孤島效應(yīng)”。這種隔離導(dǎo)致需求、開發(fā)階段和/或開發(fā)團(tuán)隊(duì)之間的聯(lián)系變得脆弱。

要使軟件開發(fā)被認(rèn)為是完整的，您必須包含可幫助您實(shí)現(xiàn)“雙向可追溯性”的工具。。需求本身需要清晰明確，也許可以通過用例或用戶故事來輔助。自動(dòng)檢查需求規(guī)范可以通過確認(rèn)是否存在特定關(guān)鍵字以及不存在不精確的短語來提供幫助。

有了由此產(chǎn)生的精確需求，使用跟蹤鏈接從需求到特定的代碼行，然后到該代碼的測試等等。..。..在整個(gè)生命周期中，可以通過確認(rèn)范圍內(nèi)的所有需求都已實(shí)現(xiàn)，并且所有設(shè)計(jì)或?qū)崿F(xiàn)元素都可以追溯到需求來實(shí)現(xiàn)雙向可追溯性。更重要的是，對那些跟蹤鏈接的自動(dòng)報(bào)告可確保需求維護(hù)永遠(yuǎn)不會(huì)成為次要問題。

需求是每個(gè)項(xiàng)目的基礎(chǔ)。薄弱的基礎(chǔ)會(huì)導(dǎo)致大量缺陷、不可預(yù)見的補(bǔ)救工作、螺旋式上升的成本和錯(cuò)過最后期限。對需求管理的投資應(yīng)與設(shè)計(jì)和編碼處于同等地位。需求可追溯性為構(gòu)建成功的項(xiàng)目奠定了堅(jiān)實(shí)的基礎(chǔ)。如果沒有這個(gè)基礎(chǔ)，即使是配備最佳測試工具的項(xiàng)目也可能存在缺陷。

審核編輯：郭婷