模型驅動開發環境強化軟件開發流程

　　在當今的互連世界，醫療設備理所當然地容納了更多具有智能功能的創新性能。這些新型性能通常采用軟件進行設計；因此，用于實現這些新功能的軟件日益復雜。同時，FDA及其它管理機構也逐步對醫療設備制造商施加壓力，以確保產品安全和有關醫療設備報告信息的準確性。

　　市場上面臨產品復雜性增加、上市壓力、產品安全和監管，對于醫療設備公司來說應對這些挑戰成為良好的商業常識。本文探究一種開發醫療設備軟件的模型驅動方法。

　　設備制造商正處于軟件開發的轉折點，幾種工具可能會幫助他們改良生產率和質量。一種模型驅動的開發流程集成了產品開發的多樣階段，從需求分析到系統設計、實現、文檔制作和測試。此工作流程有助于使復雜的需求和架構能圖形化地以圖表形式表示，因此減少了復雜性，并且還能幫助股東之間就需求和設計進行交流。圖表具有語義并且互連，有助于實現直接從設計要求到設計的可追蹤性。更進一步的是，該軟件實現可由模型直接生成，提供了從設計要求到設計到實現的追蹤檢查。

交付設備軟件

　　在醫療設備市場，交付創新技術的推動力非常現實，智能設備無處不在。在這一領域，是軟件提供了使高技術世界成為可能的功能。醫療設備的軟件被用于執行以往可能以硬件實現的功能：例如，診斷設備上的物理旋鈕和按鈕經常被觸摸屏顯示所替代，或者醫療圖像如X光和MRI逐漸以數字格式而不是物理膠片交付。

　　醫療市場競爭殘酷，而且產品在競爭到來之前上市至關重要。完成上市銷售前的活動（如510(k)流程）和隨后的藥品生產和質量管理(GMP)對設備引入市場并占領強勁市場份額必不可少。但是，在速度和病人安全之間必須取得平衡以避免耗費大的產品召回。策略之一是為上市前活動重復使用現有的大量的等效編程代碼，尤其是當與軟件協同工作進行生命攸關的手術時。實現成功軟件的關鍵路徑是通過理解；在一些情況下，軟件可能已老化，編程人員也早已不在公司，即為什么有效復用取決于文檔可理解。

文檔！文檔！文檔！

　　能發揮其知識產權(IP)效用的組織——并能復用——在工程設計新型醫療設備軟件時已領先一步。對于復用，沒有什么比藥品文檔編制更為重要，它還具有其它的效用。對于維護項目信息，一個設計歷史文件(DHF)被用于儲存項目成果。FDA通過需要一個DHF的質量系統監控(QSR)——21 聯邦管理代碼（CFR) Part 820.30來管理面向美國市場開發的產品。該DHF包含有關的信息，從多種源，包括諸如需求、系統規范、風險管理和其它正式文檔在內的項目。也可能包括筆記、草圖或其它零碎信息。具備一個DHF背后的基本原理是提供可追蹤性和文檔，以顯示設備被用于特定目的，其設計實現了所有要求。然而，如何實現在某種程度上實屬偶然：一些公司使用源代碼打印清單以證明全部實現設計要求。當然，用源代碼作為溝通方法僅在讀者能讀懂代碼的條件下有效。非技術股東可能缺乏所需讀懂源代碼的技能，從而產生了潛在的危險的溝通真空。

可視軟件開發

　　模型驅動開發(MDD)為軟件交付創建了一種可視化開發環境。MDD的基礎是源于對象管理組織的統一建模語言(UML)。MDD環境使復雜的設計輸入可視化，促進了各種各樣股東之間的溝通。開發團隊能用比源代碼更易使股東理解的格式表述設計要求、架構、結構、設計和行為。UML定義了幾種不同的圖表來獲得系統或應用的機構、架構和行為。與UML類似的是，系統建模語言(SysML)基于UML，但是是為系統工程設計需求而量身定做。

　　UML圖表內的信息被存儲在一個模型儲存庫內，這極大地擴展了圖表原僅作為插圖之用的作用(見圖1)。一張圖表上的信息變化被模型儲存庫所反映，并傳送給其它圖表以反映同樣的信息。例如，假定設計中有一級名為“Pump”，同一級出現在兩個不同的圖表內。在一張圖中把“Pump”名改為“InfusionPump”將會在另一張圖中自動變化過來。

圖1：以狀態圖形式描述的設備操作模式。

追蹤設計要求到模型元件

　　對醫療設備的要求通常以文本文件而規定，或存在于用作設計輸入的需求管理工具內。盡管文本能交流大量需要完成的細節，它也會易受誤解。更為重要的是，沒有濾波器或流程來防止有沖突的設計要求在最開始就被記錄下來。通過把需求拆分為產品內每個元件更進一步的細節要求，執行需求分析能幫助解決沖突。建模能通過文本需求以圖表的形式可視化來輔助這一過程，并且提供到設計和實現的可追蹤性。

追蹤需求到模型元件的第一步是將文本需求與建模環境相關起來。模型內的一個需求元件儲存需求，并保持除其它相關信息如需求ID、優先級、安全完整性級別及風險等之外的描述需求的文本。對能儲存的數據類型沒有限制。需求和模型之間保持同步化，從而任何一方的更改都能反映到另一方。從需求到滿足這些需求的模型元件的可追蹤性能在模型內表述出來。憑借這些信息，能生成需求覆蓋報告或進行設計改變的影響分析。例如，能生成一個UML資料，定義了故障樹分析圖表。模型內還能進行安全性和風險分析。圖2展示了故障如何被追蹤到與故障相關的設計要求。可進行更進一步的模型信息分析來說明覆蓋鴻溝。

圖2：關系追蹤需求到滿足設計要求的模型元件。

與代碼和模型協同工作

　　醫療設備制造商已經校驗并測試了現有設備中采用可被未來設備使用的軟件。該軟件可被引入到建模環境內。UML代碼圖能被自動創建，以顯示代碼現有的結構、架構和行為。結果是對現有代碼的文檔編制更好，有助于新開發商或其他股東獲得更容易理解的針對特定目的的代碼。

　　一旦在模型中被描述，到設計要求的可追蹤性能被添加到現有代碼內，可被用于協助創建模型內已開發的新特性。例如，一個新型用戶接口可能為輸液泵而創建，但現有傳送藥物給病人的代碼應該被重復使用。用戶接口代碼簡單地引用現有代碼，兩者之間的關系就隨之在模型內建立。

　　作為設計流程，更多細節和行為被添加進改模型。UML提供了指定模型內全部應用的設備，詳細的目標級代碼也被納入模型。面向設備的代碼能直接由模型生成。這有助于創建模型內從代碼到設計的可追蹤性。模型內也包含了設計要求，因此由需求到實現代碼獲得可追蹤性（見圖3）。有可能直接在代碼內包含需求信息作為對需求、設計和實現之間更進一步可追蹤性的評估。

圖3：從模型生成的代碼可由設計追蹤到實現。

軟件開發人員不需要放棄他們當前的開發環境來采用模型驅動方法。從模型產生的代碼能被編入他們的選擇代碼編輯器內，模型內可自動更新變化（見圖4）.這保持了實現與設計同步。

圖4：模型驅動開發于現有的開發環境如Eclipse相集成。

校驗和驗證

　　FDA 指南推薦在初始設計輸入時啟動校驗，并且持續校驗迭代貫穿整個開發過程。大多數缺陷在開發初始分析階段即進入系統，但通常很晚直到集成階段才被發現。模型驅動方法采用模型執行和一致性校驗，以在最容易被確定的產品設計早期發現問題。采用該模型，有可能生成生產質量代碼，包括C代碼。

　　對于醫療設備工程師來說，在主機平臺運行的模型執行能剛好在硬件可能為軟件測試準備就緒之前校驗設計行為。當硬件可用時，工程師就能專注于目標特定的問題，如時序。

圖5：通過突出設計行為，模型執行有助實現早期校驗。

文檔制作

　　利用模型驅動方法，因為軟件開發人員創建了模型，他們也提供面向其設計的文檔制作。模型中的圖表使設計可視化，能被用于項目股東或監管機構的溝通交流。因為實現代碼也是從模型生成的，實現和文檔制作都保持同步，以幫助確保文檔能準確地表述實現。模型文檔能生成多種格式，滿足每間公司的特定需要。對于整體設備來說，文檔內可包含圖解、表格、矩陣和文本信息。

結論

　　醫療設備軟件的復雜性日益增加，機構監管是生活的現實。基于UML的MDD環境幫助實現文本需求可視化，加強了設計過程。它授予團隊分解復雜需求并與項目湍急及政府機構更有效溝通的能力。通過維持多層的一致信息，模型的語義有助于管理設計變更。

　　在設計周期的初期進行校驗來識別最容易被定位的錯誤，以達到質量和安全性目標。對于醫療設備開發商，一個模型驅動方法集成了產品生命周期的不同階段——有助于改進公司交付創新醫療設備軟件的能力，同時獲得競爭優勢。