隨著客戶需求范圍的擴大和復雜性的增加，系統(tǒng)的邏輯與控制軟件的規(guī)模和復雜性也隨之擴大和增加。當各機構(gòu)需要在越來越緊迫的時限內(nèi)開發(fā)飛機和汽車應用所需的數(shù)百萬行代碼時，他們發(fā)現(xiàn)傳統(tǒng)的開發(fā)流程已不再能夠滿足質(zhì)量與時間的目標要求。將基于模型的設(shè)計用于嵌入式系統(tǒng)開發(fā)，可在開發(fā)過程早期發(fā)現(xiàn)缺陷并減少潛在缺陷總數(shù)，從而可以降低成本?；谀Ｐ偷脑O(shè)計可以幫助公司在更短時間內(nèi)以更低成本開發(fā)出質(zhì)量更高的系統(tǒng)，具有頗具競爭力的優(yōu)勢。

傳統(tǒng)開發(fā)方法對比基于模型的設(shè)計

在傳統(tǒng)開發(fā)流程中，需求、設(shè)計、實現(xiàn)和測試任務在不同的工具環(huán)境下依次執(zhí)行，其中涉及多個人工步驟（圖1）。使用Microsoft Word或IBM DOORS等工具以文本方式捕獲需求。不同設(shè)計使用針對該領(lǐng)域的不同工具實現(xiàn)，這使得系統(tǒng)級測試一直要到在軟件或硬件中實現(xiàn)后才能執(zhí)行。然后人工將設(shè)計轉(zhuǎn)換成代碼，這是個耗時且容易引入缺陷的過程。每個階段中都會引入一些缺陷，從而使測試階段成為要發(fā)現(xiàn)之前階段中所積累的所有缺陷的清道夫。因此，測試階段占到整個開發(fā)時間和成本的大頭。缺少公用工具環(huán)境、多個人工步驟以及后期才能發(fā)現(xiàn)缺陷等因素都會延長開發(fā)時間、增加開發(fā)成本。

圖 1. 傳統(tǒng)開發(fā)方法需要許多會引入缺陷的不必要的人工步驟。

基于模型的設(shè)計（圖2）以和傳統(tǒng)流程相同的需求開始。但是，這些需求并不作為文本規(guī)范的基礎(chǔ)，而是用于以模型的形式開發(fā)可執(zhí)行規(guī)范。工程師使用這些模型來明確需求與規(guī)范。然后對這些模型進行細化，以開發(fā)需求更具體的設(shè)計。使用基于模型的設(shè)計工具，工程師可以在系統(tǒng)級對設(shè)計進行仿真，在實現(xiàn)之前發(fā)現(xiàn)界面缺陷。完成設(shè)計之后，工程師借助這些模型自動生成產(chǎn)品級代碼和測試用例。此工作流程使工程師們從需求到測試階段都能夠處于同一環(huán)境中，從而減少了人工工作量。此外，當工程師們在模型中仿真可執(zhí)行規(guī)范來驗證其是否滿足需求時，在需求階段即可開始測試。這樣便可及早發(fā)現(xiàn)和消除缺陷，降低開發(fā)總成本。

圖 2. 基于模型的設(shè)計在整個開發(fā)過程中使用系統(tǒng)級模型作為可執(zhí)行規(guī)范。這種設(shè)計方法支持系統(tǒng)級和組件級設(shè)計與仿真、自動代碼生成以及連續(xù)測試與驗證。

基于模型設(shè)計的優(yōu)勢

相比采用傳統(tǒng)方法的機構(gòu)，采用基于模型設(shè)計的機構(gòu)可將成本降低20%到60% 。成本節(jié)約主要得益于更準確的需求分析以及早期和連續(xù)的測試與驗證。由于使用了模型來仿真需求和設(shè)計，因此可在開發(fā)流程中早的多地發(fā)現(xiàn)缺陷；而處理早期發(fā)現(xiàn)的缺陷可成百上千倍地降低成本（圖3）。

圖 3 基于模型的設(shè)計可將缺陷發(fā)現(xiàn)提前到開發(fā)階段早期。

使用基于模型設(shè)計的 ROI 框架量化節(jié)約的成本

采用基于模型設(shè)計 的ROI 框架來進行評估。根據(jù)項目大小、團隊規(guī)模和其它因素，該框架可使用基本構(gòu)造性成本模型（COCOMO）計算出傳統(tǒng)開發(fā)的成本，然后減去基于模型設(shè)計所節(jié)約的成本，即可獲得基于模型設(shè)計的開發(fā)成本。之所以選用基本COCOMO模型原因是該模型是一種廣泛用于航空和國防工業(yè)的通用參數(shù)成本估算工具，在上兩個領(lǐng)域，采購成本的可計算性要求由縝密的模型來進行軟件成本估算。然后便可通過計算軟件成本和項目團隊培訓成本來計算ROI。該框架使用由軟件工程協(xié)會（SEI）、電氣和電子工程師協(xié)會（IEEE） 和行業(yè)研究所規(guī)定的指標。由于項目規(guī)模、現(xiàn)有流程和使用基于模型設(shè)計的團隊的專業(yè)水準因行業(yè)和公司而異，因此可針對特定的項目和團隊自定義基于模型設(shè)計的ROI框架。

我們看一個有500，000行代碼的軟件項目基線案例。使用基本COCOMO模型可以算出使用傳統(tǒng)方法的開發(fā)成本大約為600萬美元。為了計算基于模型的設(shè)計相比傳統(tǒng)方法所節(jié)約的成本，每個開發(fā)階段（需求、設(shè)計、實現(xiàn)和測試）都要根據(jù)行業(yè)指標進行分析。然后便可匯總出所節(jié)約的總成本，并從傳統(tǒng)開發(fā)成本中將其減去。在本例中，基于模型設(shè)計的成本為300萬美元，相比傳統(tǒng)方法節(jié)約了50%。

為了實現(xiàn)50%的成本節(jié)約，該框架會檢查基于模型設(shè)計所消除的傳統(tǒng)開發(fā)流程中的低效情況，并根據(jù)行業(yè)指標和平均值計算出所節(jié)約成本。因每個開發(fā)階段節(jié)約的成本是分別計算的，因此該框架適用于逐步采用基于模型設(shè)計的情況。

下文將討論其中一種低效需求情況，以此來說明該框架是如何工作的。在需求階段，使用模型來發(fā)現(xiàn)不明確、不一致或不可測試的需求，這使工程師能夠更大比例地發(fā)現(xiàn)缺陷?；€案例的該增加比例假設(shè)為9%。在需求階段發(fā)現(xiàn)這些缺陷，意味著可以避免開發(fā)階段后期成本高昂的返工。未發(fā)現(xiàn)的這9%的缺陷乘以解決該類缺陷的平均時常即為部分需求成本的節(jié)約量，而該缺陷的根本原因在于不正確的需求。在基線案例中，各需求缺陷的平均處理時長為4.5小時。根據(jù)該計算，基于模型的設(shè)計可節(jié)約2，025個工程小時。圖4演示了處理需求分析缺陷（pain point）的框架部分。該框架還包含其它七個處理不同低效情況的部分。

圖 4. ROI 框架可計算通過在早期修正不正確需求而節(jié)約的工程小時數(shù)。

本例中，匯總整個開發(fā)過程所節(jié)約的成本時會發(fā)現(xiàn)，節(jié)約主要來自需求和測試階段（圖5）。這得益于更為全面的需求分析，從而減少了遺留到后續(xù)階段的缺陷。簡言之，更好的需求有助于更好的設(shè)計實現(xiàn)。盡早和連續(xù)的測試使得可在引入缺陷的各階段本身就能發(fā)現(xiàn)并處理這些缺陷，這樣就減少了遺留在軟件中的潛在缺陷、降低了整體開發(fā)成本。

圖 5. 需求和測試階段節(jié)約的成本占總節(jié)約成本的大部分

MathWorks與采用基于模型設(shè)計的航空與汽車企業(yè)合作時，ROI框架有助于引導這一采用過程，使企業(yè)能夠發(fā)現(xiàn)可立即、顯著地從轉(zhuǎn)用基于模型的設(shè)計中獲益的領(lǐng)域。

本文小結(jié)

對大多數(shù)企業(yè)而言，投資新技術(shù)和新流程/工藝是一種有風險的嘗試。本文介紹的投資回報計算旨在提供投資基于模型設(shè)計的替代分析方法。除了證明投資的合理性，ROI框架還可以使設(shè)計團隊發(fā)現(xiàn)基于模型的設(shè)計可以帶來最大節(jié)約的領(lǐng)域，以及通過進一步研究可大幅降低成本的領(lǐng)域。

責任編輯：gt