在上文《嵌入式軟件開發(fā)的十二大基本要素（二）：代碼性能》中，我們分析了代碼性能如何具體影響投資回報率（ROI）和總擁有成本（TCO）。

本文為白皮書系列第三部分，將分析工作流程對生產力的具體影響。

一般來說，在現(xiàn)代開發(fā)工作流程中，每增加一行代碼或修改軟件都會導致軟件項目的重新構建。在這種情況下，如果代碼太多，就需要很長的時間來構建，從而導致開發(fā)周期因為這個等待時間而增加。

這如何轉化為公司的優(yōu)勢？

Steve McConnell 的《Software Estimation: Demystifying the Black Art》一書中包含了一張從估算模型 Cocomo II（建設性成本模型）中得出的圖表，該圖表以人月為單位的工作與以代碼行 (SLOC) 為單位的項目規(guī)模作對比。如果我們研究 COCOMO II 工作量公式：

工作量 = 2.94 * EAF * (KSLOC)E

EAF：是由成本驅動因素得出的工作量調整系數(shù)。

E：是由五個規(guī)模驅動因素得出的指數(shù)。

KSLOC：以千代碼行為單位。

工作量公式中的 EAF 僅僅是與項目的每個成本驅動因素對應的工作量乘數(shù)的乘積。

觀察下圖中從《COCOMO II - 模型定義手冊》中提取的成本驅動因素，有很大的比重。在最壞的情況下，極低的評級水平對工作量調整系數(shù) (EAF) 的影響 = 1.40 (1.20*1.17)，在最好的情況下，評級水平非常高，EAF=0.66（0.84*0.78）。

圖表：語言和工具經驗(LTEX)和軟件工具的使用(TOOL)

這將直接影響整個開發(fā)團隊的生產力。對企業(yè)的影響可以在 http://softwarecost.org/tools/COCOMO/ 免費計算和調整。這同樣適用于設計和代碼生成工具。自動生成的代碼的構建時間較長，會影響到設計本身的生產力，因為在進行設計之前，需要對更改或新的邏輯進行測試并集成到整個系統(tǒng)中。

根據(jù)不同的客戶反饋，以及在客戶案例中所述，與其他商業(yè)工具相比，IAR Embedded Workbench 的構建速度至少是其兩倍。這也同樣適用于 IAR 功能安全版本的產品。而跨平臺支持的 IAR 構建工具在使用相同的硬件主機的 Linux 上的構建時間，顯示出更好的性能（快 4 倍）。在 Ubuntu 上執(zhí)行標準 C-STAT 靜態(tài)分析檢查所需時間是在 Windows 上的 25%。

更快地交付構建和分析結果意味著持續(xù)交付 (CD) 能夠更快地收斂。

圖表：IAR Embedded Workbench與IAR構建工具的構建時間比較

圖中顯示的構建時間使用了：

– 574個C/C++源文件

– 最高的編譯器優(yōu)化級別

– 項目構建后進行分析

– 比較基于相同的主機硬件，Intel i7-8700K，24 GB RAM

– 使用 1、2、4和8個CPU內核

同樣，一般來說，在 Ubuntu 上使用 IAR 構建工具構建嵌入式軟件項目比在 Windows 上使用 IAR Embedded Workbench 構建更快，通常前者構建項目的時間不到后者的 50%。

此外，在現(xiàn)代嵌入式開發(fā)工作流程中，采用自動化流程來確保質量并持續(xù)構建和測試是一個基本需求。當使用跨平臺框架中底層命令行工具實現(xiàn)了相同功能的正確 DevOps 實踐時，嵌入式軟件研發(fā)團隊可以實現(xiàn)更短的新功能上市時間。

IAR 解決方案支持 Ubuntu、Red Hat 和 Windows 上的現(xiàn)代可擴展構建服務器拓撲結構，可用于 CI/CD 管道，包括虛擬機、容器 (Docker) 和自我托管的運行器。

審核編輯 ：李倩