在上文《嵌入式軟件開發的十二大基本要素(二):代碼性能》中,我們分析了代碼性能如何具體影響投資回報率(ROI)和總擁有成本(TCO)。
本文為白皮書系列第三部分,將分析工作流程對生產力的具體影響。
一般來說,在現代開發工作流程中,每增加一行代碼或修改軟件都會導致軟件項目的重新構建。在這種情況下,如果代碼太多,就需要很長的時間來構建,從而導致開發周期因為這個等待時間而增加。
這如何轉化為公司的優勢?
Steve McConnell 的《Software Estimation: Demystifying the Black Art》一書中包含了一張從估算模型 Cocomo II(建設性成本模型)中得出的圖表,該圖表以人月為單位的工作與以代碼行 (SLOC) 為單位的項目規模作對比。如果我們研究 COCOMO II 工作量公式:
工作量 = 2.94 * EAF * (KSLOC)E
EAF:是由成本驅動因素得出的工作量調整系數。
E:是由五個規模驅動因素得出的指數。
KSLOC:以千代碼行為單位。
工作量公式中的 EAF 僅僅是與項目的每個成本驅動因素對應的工作量乘數的乘積。
觀察下圖中從《COCOMO II - 模型定義手冊》中提取的成本驅動因素,有很大的比重。在最壞的情況下,極低的評級水平對工作量調整系數 (EAF) 的影響 = 1.40 (1.20*1.17),在最好的情況下,評級水平非常高,EAF=0.66(0.84*0.78)。
圖表:語言和工具經驗(LTEX)和軟件工具的使用(TOOL)
這將直接影響整個開發團隊的生產力。對企業的影響可以在 http://softwarecost.org/tools/COCOMO/ 免費計算和調整。這同樣適用于設計和代碼生成工具。自動生成的代碼的構建時間較長,會影響到設計本身的生產力,因為在進行設計之前,需要對更改或新的邏輯進行測試并集成到整個系統中。
根據不同的客戶反饋,以及在客戶案例中所述,與其他商業工具相比,IAR Embedded Workbench 的構建速度至少是其兩倍。這也同樣適用于 IAR 功能安全版本的產品。而跨平臺支持的 IAR 構建工具在使用相同的硬件主機的 Linux 上的構建時間,顯示出更好的性能(快 4 倍)。在 Ubuntu 上執行標準 C-STAT 靜態分析檢查所需時間是在 Windows 上的 25%。
更快地交付構建和分析結果意味著持續交付 (CD) 能夠更快地收斂。
圖表:IAR Embedded Workbench與IAR構建工具的構建時間比較
圖中顯示的構建時間使用了:
– 574個C/C++源文件
– 最高的編譯器優化級別
– 項目構建后進行分析
– 比較基于相同的主機硬件,Intel i7-8700K,24 GB RAM
– 使用 1、2、4和8個CPU內核
同樣,一般來說,在 Ubuntu 上使用 IAR 構建工具構建嵌入式軟件項目比在 Windows 上使用 IAR Embedded Workbench 構建更快,通常前者構建項目的時間不到后者的 50%。
此外,在現代嵌入式開發工作流程中,采用自動化流程來確保質量并持續構建和測試是一個基本需求。當使用跨平臺框架中底層命令行工具實現了相同功能的正確 DevOps 實踐時,嵌入式軟件研發團隊可以實現更短的新功能上市時間。
IAR 解決方案支持 Ubuntu、Red Hat 和 Windows 上的現代可擴展構建服務器拓撲結構,可用于 CI/CD 管道,包括虛擬機、容器 (Docker) 和自我托管的運行器。
審核編輯 :李倩
-
嵌入式
+關注
關注
5082文章
19115瀏覽量
304923 -
軟件開發
+關注
關注
0文章
614瀏覽量
27353 -
模型
+關注
關注
1文章
3233瀏覽量
48819
原文標題:嵌入式軟件開發的十二大基本要素(三):DevOps
文章出處:【微信號:IAR愛亞系統,微信公眾號:IAR愛亞系統】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論