創(chuàng)建嵌入式軟件可能是一項(xiàng)具有挑戰(zhàn)性的工作，這種體驗(yàn)可以是定義明確、受控的過程。無論嵌入式開發(fā)周期在這個(gè)范圍內(nèi)的哪個(gè)位置，設(shè)計(jì)周期中都有一些元素應(yīng)該對它們都是通用的。這些包括收集需求、創(chuàng)建設(shè)計(jì)、構(gòu)建軟件、測試軟件，最終維護(hù)軟件。執(zhí)行任一階段所花費(fèi)的時(shí)間量將根據(jù)所使用的設(shè)計(jì)周期過程而有所不同，但通過掌握設(shè)計(jì)周期的這些方面，將確保在分配的預(yù)算內(nèi)持續(xù)、按時(shí)地開發(fā)產(chǎn)品。
本文對設(shè)計(jì)周期的每一個(gè)方面都提供了最簡短的介紹。
需求
收集并恰當(dāng)?shù)赜涗浶枨罂赡苁侨魏伍_發(fā)過程的關(guān)鍵步驟之一。如果一個(gè)團(tuán)隊(duì)不知道他們在構(gòu)建什么，那么他們注定會失敗。需求可以用多種方式來定義，但是一個(gè)好的通用定義是，需求是軟件為了解決特定問題而必須表現(xiàn)出來的屬性。就像生活中任何事情一樣，需求比定義稍微復(fù)雜一些，因?yàn)樗鼈冇袃煞N不同的風(fēng)格;功能性和非功能性。
功能需求描述了軟件要展示的行為，這意味著功能需求實(shí)際上是軟件的一種能力。另一方面，非功能性需求是約束解決方案的需求，嵌入式開發(fā)人員關(guān)注的不是系統(tǒng)的能力，而是如何限制這種能力。這些類型的需求通常面向系統(tǒng)性能、可維護(hù)性等等。
有許多不同的方法來記錄和維護(hù)需求，無論是基于網(wǎng)絡(luò)的系統(tǒng)還是簡單的文檔。在任何一種情況下，軟件需求規(guī)格說明書(SRS)的使用都是記錄需求的非常有用的工具。SRS用于以工程團(tuán)隊(duì)能夠理解的技術(shù)術(shù)語陳述要求，而不是以最終客戶能夠理解的語言陳述要求。
SRS有許多目的，不僅僅是記錄要求。它們可以用來估計(jì)成本，確定項(xiàng)目風(fēng)險(xiǎn)，甚至評估和創(chuàng)建開發(fā)進(jìn)度。在整個(gè)設(shè)計(jì)周期中，隨著驗(yàn)證的進(jìn)行，SRS可用于創(chuàng)建要求可追溯性矩陣，該矩陣可用于確保每個(gè)要求都得到實(shí)施和測試。
設(shè)計(jì)
如果嵌入式開發(fā)人員想要最小化錯(cuò)誤數(shù)量和軟件構(gòu)造問題，設(shè)計(jì)階段是極其重要的。一個(gè)經(jīng)過適當(dāng)思考和設(shè)計(jì)的軟件實(shí)現(xiàn)起來幾乎是輕而易舉的，因?yàn)樵O(shè)計(jì)階段做了所有繁重的工作!
設(shè)計(jì)階段有一些非常重要的輸出，是軟件構(gòu)造所需要的。這些是軟件架構(gòu)和詳細(xì)的軟件設(shè)計(jì)。軟件架構(gòu)是對軟件系統(tǒng)的子系統(tǒng)和組件以及它們之間關(guān)系的描述。這個(gè)文檔驅(qū)動(dòng)詳細(xì)的設(shè)計(jì)，并指示軟件應(yīng)該如何構(gòu)造。它允許工程師在編寫一行代碼之前，考慮整個(gè)設(shè)計(jì)和所有相互關(guān)聯(lián)的部分。
軟件設(shè)計(jì)階段還有助于產(chǎn)生軟件模型，這些模型可以作為正確的解決方案進(jìn)行測試和驗(yàn)證。該設(shè)計(jì)有助于為編寫的軟件提供藍(lán)圖，這大大有助于減少軟件返工的時(shí)間和成本，當(dāng)然也有助于減少bug。請記住，雖然只是因?yàn)闀r(shí)間花費(fèi)在預(yù)先設(shè)計(jì)軟件上，但這并不意味著高風(fēng)險(xiǎn)的區(qū)域不會被識別，這些區(qū)域確實(shí)需要編寫一些測試代碼，以便充分理解設(shè)計(jì)所必需的組件，這是一個(gè)相當(dāng)大的過程。
構(gòu)建
構(gòu)建階段很可能是大多數(shù)嵌入式開發(fā)工程師花費(fèi)時(shí)間并且想要花費(fèi)時(shí)間的地方。軟件構(gòu)建是指通過編碼、驗(yàn)證、單元測試、集成測試和調(diào)試的組合來詳細(xì)創(chuàng)建工作軟件。雖然測試通常被認(rèn)為是一個(gè)獨(dú)立的階段，但它也作為構(gòu)建的一部分來執(zhí)行是很重要的。
在建造階段會發(fā)生很多事情，但是真正發(fā)生的是，被創(chuàng)造出來的設(shè)計(jì)，軟件架構(gòu)，從簡單的流程圖和圖表轉(zhuǎn)換成工作代碼。創(chuàng)建設(shè)計(jì)給出了如何實(shí)現(xiàn)軟件的路線圖，但工程師仍然需要盡量降低復(fù)雜性，可能需要實(shí)現(xiàn)編碼標(biāo)準(zhǔn)，如MISRA-C，并需要確保代碼是模塊化的。如果要重用代碼，開發(fā)人員可能需要遵守API或硬件抽象層(HAL )，以確保代碼在未來可以重用。
在構(gòu)建過程中，度量和統(tǒng)計(jì)也很重要。有許多不同類型的度量可以被跟蹤，但是一些最有用的是代碼開發(fā)、修改、重用和復(fù)雜性。限制一個(gè)函數(shù)變得多復(fù)雜對于那些被迫維護(hù)代碼庫的可憐的嵌入式開發(fā)人員來說是非常重要的。這個(gè)獨(dú)特的度量標(biāo)準(zhǔn)也可以用來確定驗(yàn)證一個(gè)功能所需的最小測試用例數(shù)量。
測試
軟件測試包括動(dòng)態(tài)驗(yàn)證，即程序在有限的測試用例集上提供預(yù)期的行為，這些測試用例是從通常無限的執(zhí)行域中適當(dāng)選擇的。正如前面提到的，雖然測試被分成了不同的類別，但是它應(yīng)該貫穿于整個(gè)設(shè)計(jì)周期。測試軟件的目的是識別軟件中的故障、錯(cuò)誤和缺陷。
理解這些潛在測試狀態(tài)定義的差異是很重要的。故障是指系統(tǒng)或部件不能在規(guī)定的性能要求范圍內(nèi)執(zhí)行其所需的功能，而故障可以是程序中的錯(cuò)誤步驟、處理器數(shù)據(jù)。這兩者是有區(qū)別的，但是有時(shí)候開發(fā)者可能并不在乎這種區(qū)別。當(dāng)這種情況發(fā)生時(shí)，他們可以簡單地將其歸類為缺陷。
嵌入式開發(fā)人員有許多方法可以跟蹤、執(zhí)行和創(chuàng)建測試。一個(gè)簡單的方法是使用軟件需求規(guī)格說明文檔來生成需求跟蹤矩陣。矩陣變成了一個(gè)簡單的列表，可以識別需求并將其與代碼模塊、測試用例以及測試結(jié)果聯(lián)系起來。需求和任何圈復(fù)雜度分析也可以用來生成測試用例。
維護(hù)
軟件維護(hù)涉及到所有設(shè)計(jì)周期階段的重復(fù)，有點(diǎn)曲折。維護(hù)工程師需要能夠更新軟件以包含新的需求，同時(shí)維護(hù)現(xiàn)有系統(tǒng)的完整性，而不是從零開始。這可能涉及對當(dāng)前設(shè)計(jì)的詳細(xì)分析，了解在哪里進(jìn)行架構(gòu)和設(shè)計(jì)更新，實(shí)現(xiàn)這些更新，當(dāng)然，在下一個(gè)版本發(fā)布之前還要測試它們。軟件維護(hù)變成了重復(fù)的設(shè)計(jì)周期。
軟件維護(hù)人員通常從修改請求日志開始工作，并以某種形式進(jìn)行電子跟蹤。該軟件允許對更新以及現(xiàn)場可能發(fā)現(xiàn)的任何錯(cuò)誤進(jìn)行優(yōu)先排序。工程師需要研究任何提議的變更的影響，并經(jīng)濟(jì)高效地實(shí)施它們。
軟件設(shè)計(jì)周期可以像任何團(tuán)隊(duì)希望的那樣復(fù)雜或簡單。任何設(shè)計(jì)周期的這五個(gè)階段都包含了大量的知識，對每個(gè)階段的正確掌握將為任何嵌入式開發(fā)人員提供在設(shè)定的時(shí)間表和預(yù)算內(nèi)一致地構(gòu)建嵌入式軟件所需的理解。這篇文章僅僅觸及了這個(gè)非常豐富的研究領(lǐng)域的皮毛。