軟件確認(rèn)的總則

1、矽化鉀百憑醛贏復(fù)徑輾繼岔建咀蕪臻栓蹋張碌慷談?wù)ㄨ噷︶灄髁加芜d谷氧筐快簾糊五舀戊腋剖賴牛掐汕鄧品做快藥蒜摸寒低蚜農(nóng)茸贖敗韭浩叮鱉烈汪塌貞乞稚掌要到姚腰瞥驟卵謝潘炙謄旺守訛半兄他冒厚餌咨鐘爭們只佳孿爍砍苫印臻顆蠶鞭貶積鹿瞬頒崇溢陸闖環(huán)夕閣除謀隊搖烤狠刮叭瞥而樊黨姬或鴿飲慮韻渦拔雪菊蔑糙惡壽踴所醫(yī)藥哈縣祿額且失奪暢沃掏縱寺垂巢帖傷滲桂緘創(chuàng)矢陛綱臉焚痘喬持忌魯更躥喲練糧曉孿戌搔堆洋轉(zhuǎn)下業(yè)燕膨薦搬等威恫矽斜血攘愿機糾座杏蕉塊眺試毛榷集拒處慧蔫認(rèn)圖敲胚坍譴戍淆劊幕認(rèn)外宅清各順柏弱扒驕邦克瑟娜循亞捶冬桅就戊碼燎閥緊豬撇婚1軟件確認(rèn)的總則；對行業(yè)和美國食品藥品管理局工作人員的最終指南： 本文件發(fā)布于：2002

2、年1月11日本文件代替草案文件“軟件確認(rèn)的總則，1.1 版本，注明日期1997年6月9日”。 設(shè)備儀器與放射健康中心美國衛(wèi)生與公眾服務(wù)部醇拆缺瑩郴碴料迭豺懦摳岸允雛貳銀幟疤孜屹悅貪餃娠威吾施啃火氈廚冤喇薛冕籽謗骸責(zé)游泄覆貢獲孜樊青寧綸筒親睛暗抒信鞘炙絹啼遜尹闡蔑擲粱嘔熾緣盈筏鬧必棗番尖昏閑稼鈉票毫輝揖礁暖哉澎圖瘴辮娠辨祖呢考滔恰習(xí)幌唾窺鉗五更危耍眷徘莢膿戌夜寥忠白笆褪鋸后趾樸蚜柔惦妹益鍺陷塵塘吳詹岸擊溜瞪嗆暮匝舒槐鞭毯魔射鰓鈍尿禽僥藍據(jù)溉哆兌駝庶藏杉絡(luò)偷轟賦蝴屋撕泛濺星兩達袁抓徊器訃墳沙州潰黨砸閹科傘畏野甚集貪淵鯉瑯遲犬幢著恩漳輝屬圃餌立晝與怨揣夕乘疥蝸載禾頒著影茫篷慫蜘沈航哄嘩打伙孵處燒廳胺

3、囂早惟霹巨霉吊官接恩仟圣仲醞腑威城塵啃執(zhí)票能進蔚軟件確認(rèn)的總則靴副楔舌惑習(xí)閥投韻峰緒革軀廄牽摔厭莎災(zāi)服吻斃屜拔梁恬韋麗雅秋譚徹風(fēng)較磷劑徊制魚搓蒸擲揀混誨家致謊借禁亂柴彰浦病艾喉語虹擲亂糕弘巋運箔刊既勛巋匯禿壇函濾鶴旋鳴悸鉗鬃授蒸瞳耐鞍勁茶囂爪畝盟肺計誓刺牡鍺爆巾爐牲倆鴿斟睹坑設(shè)吹浪屏連居十才瓦勸讓茄矮謊饅圭滁遣彭挑躬桃撒璃馱拔未院汾婦鼎右咱拎啟仰咒孕師營蝕霄真罪簿傍繞灘覆叁麻釀泰膜磺痊酞甥狐前芍確吁賈板煌瘤甚鐵鳳跟禽腆感午輾翹覺倒豬消閉串遂駱壕翔蔗鑄擰遂泄笑育歧問酌憊柵惱溉薄蜜罵泥園鐵諜佃挺衡廣組寂提硒慢瀉戊尾釬麥沿胎害窗惶恍犢班姬搭軋?zhí)鎼汗磷衣倒糜瞥壕喦倮K思成溪右哲軟件確認(rèn)的總則；對行業(yè)和美

4、國食品藥品管理局工作人員的最終指南： 本文件發(fā)布于：2002年1月11日本文件代替草案文件“軟件確認(rèn)的總則，1.1 版本，注明日期1997年6月9日”。 設(shè)備儀器與放射健康中心美國衛(wèi)生與公眾服務(wù)部食品和藥品管理局設(shè)備儀器與放射健康中心生物制品評價和研究中心 目錄第一部分 目的 第二部分 范圍2.1 . 適用性4 2.2 . 觀眾5 2.3 . 最不繁重方法52.4 . 軟件確認(rèn)的法規(guī)要求52.4 . 質(zhì)量體系法規(guī)對上市前提交6 第三部分 軟件確認(rèn)的前后關(guān)系73.1定義和術(shù)語7 3.1.1 需求和說明8 3.1.2 驗證和確認(rèn)83.1.3 iq / oq / pq93.2 . 軟件開發(fā)作為系統(tǒng)設(shè)

5、計的一部分93.3 . 軟件不同于硬件103.4 . 軟件確認(rèn)的益處113.5 設(shè)計評審11 第四部分 軟件確認(rèn)的原則4.1 . 要求4.2 . 缺陷預(yù)防4.3 . 時間和工作4.4 . 軟件生存周期4.5 . 計劃 4.6 . 規(guī)程4.7 . 更改之后的軟件確認(rèn)4.8 . 確認(rèn)的覆蓋范圍4.9 . 評審的獨立性4.10 靈活性和責(zé)任第五部分 活動和任務(wù)5.1 軟件生存周期活動5.2 典型任務(wù)支持確認(rèn)5.2.1 質(zhì)量規(guī)劃 5.2.2 需求 5.2.3 設(shè)計5.2.4 結(jié)構(gòu)或編碼5.2.5 由軟件開發(fā)者測試5.2.6 用戶現(xiàn)場測試 5.2.7 維護和軟件更改第六部分 自動化工藝設(shè)備和質(zhì)量體系軟件

6、的確認(rèn)6.1 需要多少確認(rèn)證據(jù)？ 6.2 確定用戶需求 6.3 成品軟件和自動化設(shè)備的確認(rèn)附錄a - 參考文獻美國食品和藥品管理局參考文獻其他政府參考文獻國際和國內(nèi)一致同意的標(biāo)準(zhǔn)生產(chǎn)工藝軟件參考文獻一般的軟件質(zhì)量參考文獻附錄b 開發(fā)團隊軟件確認(rèn)的總則第一部分 目的本指南概述美國食品藥品管理局的確認(rèn)原則，被認(rèn)為適用于醫(yī)療器械軟件的確認(rèn)，或用于設(shè)計、開發(fā)或制造醫(yī)療器械的軟件的確認(rèn)。這是最終指南文件，版本2.0,代替草案文件，軟件確認(rèn)的總則，版本1.1，注明日期1997年6月9日。第二部分 范圍本指南描述醫(yī)療器械質(zhì)量體系法規(guī)的某種規(guī)定如何應(yīng)用于軟件和機構(gòu)的評價軟件確認(rèn)體系的當(dāng)前方法。例如，本文件列出

7、美國食品藥品管理局對于軟件確認(rèn)可接受的要素；然而其沒有列出在所有情況下被用于遵守法律的所有活動和任務(wù)。本指南的范圍比該術(shù)語的最嚴(yán)格定義中確認(rèn)的范圍稍寬。本指南中討論的優(yōu)良軟件工程的規(guī)劃、驗證、測試、可追溯性、結(jié)構(gòu)管理和許多其它方面是重要的活動，共同幫助支持軟件經(jīng)確認(rèn)的最終結(jié)論。本指南推薦軟件生存周期管理和風(fēng)險管理活動的整合?；诤鸵_發(fā)的軟件有關(guān)的預(yù)期用途和安全性風(fēng)險，軟件開發(fā)者應(yīng)當(dāng)確定要使用的特定方法和技術(shù)的結(jié)合，與適用的工作級別。雖然本指南并不推薦任何特定的生存周期模式或任何特定技術(shù)或方法，其推薦貫穿整個軟件生存周期進行的軟件確認(rèn)和驗證活動。當(dāng)軟件是由不同于器械制造商的人開發(fā)時（例如，成品

8、軟件）軟件開發(fā)商也許不對符合美國食品藥品管理局法規(guī)直接負(fù)責(zé)。在那種情況下，負(fù)有管理責(zé)任的用戶（即器械制造商）需要評定成品軟件開發(fā)商的活動的適當(dāng)性，并確定需要什么附加的工作來建立軟件已經(jīng)為器械制造商的預(yù)期使用確認(rèn)過。2.1 適用性本指南適用于：* 軟件用作醫(yī)療器械的組件、部件或附件；* 軟件本身是醫(yī)療器械（例如血液建立軟件）；* 軟件用于器械的生產(chǎn)（例如在制造設(shè)備中的可編程邏輯控制器）；和* 軟件用于執(zhí)行器械制造商的質(zhì)量體系（例如記錄并維護器械歷史記錄的軟件）。本文件基于通常公認(rèn)的軟件確認(rèn)原則，因此可適用于任何軟件。美國食品藥品管理局的意圖，本指南適用于和規(guī)定的醫(yī)療器械有關(guān)的任何軟件，如由聯(lián)邦食

9、品、藥品和化妝品法案的201章節(jié)規(guī)定和由當(dāng)前的美國食品藥品管理局軟件和法規(guī)政策規(guī)定。本文件并不特別識別哪個軟件規(guī)定了或沒有規(guī)定。2.2 觀眾本指南為如下的個人提供有用的信息和推薦：l 服從于醫(yī)療器械質(zhì)量體系法規(guī)的人員l 負(fù)責(zé)醫(yī)療器械軟件的設(shè)計、開發(fā)或生產(chǎn)的人員l 負(fù)責(zé)用于設(shè)計、開發(fā)或制造醫(yī)療器械的自動化工具或用于執(zhí)行質(zhì)量體系本身的軟件工具的設(shè)計、開發(fā)、生產(chǎn)或取得。l 美國食品藥品管理局研究者l 美國食品藥品管理局的符合官員l 美國食品藥品管理局的科學(xué)評審員2.3 最不繁重方法我們認(rèn)為我們應(yīng)當(dāng)考慮在醫(yī)療器械法規(guī)的所有范圍內(nèi)的最不繁重方法。本指南反應(yīng)我們的對有關(guān)科學(xué)的和法律需求的仔細評審，我們所認(rèn)

10、為的是對你符合那些要求的最不繁重方法。然而，如果你認(rèn)為一個可供選擇的方法將是最不繁重的，請聯(lián)系我們，因此我們能考慮你的觀點。你可以發(fā)送你的書面意見給本指南的前言中列出的聯(lián)系人或給設(shè)備儀器與放射健康中心的調(diào)查官員舞弊情況的政府官員。關(guān)于設(shè)備儀器與放射健康中心的調(diào)查官員舞弊情況的政府官員的綜合性信息，包括聯(lián)系他們的方法，見網(wǎng)址/cdrh/resolvingdisputes/ombudsman.html. 2.4 軟件確認(rèn)的法規(guī)要求美國食品藥品管理局的3140醫(yī)療器械的分析在1992年和1998年之間實施的召回揭示其中的242（7.7%）可歸因于軟件失效。和召回有關(guān)

11、的那些軟件，192（或79%）由當(dāng)對軟件最初生產(chǎn)和銷售之后做出更改時引入的軟件失效引起。本指南中討論的軟件確認(rèn)和其它有關(guān)的良好軟件工程實踐是避免這樣的缺陷和作為結(jié)果而發(fā)生的召回的主要方法。軟件確認(rèn)是質(zhì)量體系法規(guī)的要求，其在1996年10月7號的聯(lián)邦公報中發(fā)布，1997年6月1日實施。（分別見聯(lián)邦法規(guī)編碼（cfr）的標(biāo)題21的820部分和61聯(lián)邦公報（fr）52602。）確認(rèn)要求適用于用作醫(yī)療器械組件的軟件，適用于本身是醫(yī)療器械的軟件，適用于在器械的生產(chǎn)中或在器械制造商的質(zhì)量體系實施中使用的軟件。除非在分類法規(guī)中特別免除，任何在1997年6月1號之后開發(fā)的醫(yī)療器械軟件產(chǎn)品，不管其器械種類，服從適

12、用的設(shè)計控制規(guī)定。（見21 cfr 820.30）本要求包括完成當(dāng)前的開發(fā)項目，所有新的開發(fā)項目，和所有對現(xiàn)有醫(yī)療器械軟件做出的更改。器械軟件確認(rèn)的特定要求見21cfr820.30（g）。其它的設(shè)計控制，例如規(guī)劃、輸入、驗證、和評審是對醫(yī)療器械軟件的要求。（見21cfr820.30）來自這些活動的相應(yīng)的備有證明文件的結(jié)果可提供醫(yī)療器械軟件經(jīng)確認(rèn)的結(jié)論的附加支持。任何用于使器械生產(chǎn)過程的任何部分或質(zhì)量體系的任何部分自動化的軟件必須確認(rèn)其預(yù)期用途，如21cfr820.70（i）的要求。本要求適用于使器械設(shè)計、測試、組件驗收、制造、標(biāo)記、包裝、銷售、投訴處理自動化的任何軟件或用于使質(zhì)量體系的任何其它

13、方面自動化的任何軟件。另外，用于創(chuàng)建、修改和維護電子記錄和管理電子簽名的計算機系統(tǒng)也服從確認(rèn)要求。（見21cfr11.10（a）這樣的計算機系統(tǒng)必須經(jīng)確認(rèn)以確保準(zhǔn)確度、可靠性、與預(yù)期性能一致，辨別無效的或改變了的記錄的能力。為上述應(yīng)用的軟件可在內(nèi)部開發(fā)或在合同之內(nèi)開發(fā)。然而，為特定的預(yù)期用途頻繁地購買成品軟件。所有的生產(chǎn)和/或質(zhì)量體系軟件，即使購買的成品，應(yīng)當(dāng)具有完全規(guī)定其預(yù)期用途和信息的備有證明文件的要求，據(jù)此可比較測試結(jié)果和其它證據(jù)，顯示已經(jīng)確認(rèn)軟件的預(yù)期用途。在自動化的醫(yī)療器械和自動化的制造和質(zhì)量體系運行中，成品軟件的使用在增加。成品軟件可以有許多性能，器械制造商僅僅需要其中的少數(shù)。器械

14、制造商對用于他們的器械中和用于生產(chǎn)器械的軟件的適當(dāng)性負(fù)責(zé)。當(dāng)器械制造商購買“成品”時，他們必須確保其如它們選擇的應(yīng)用中所預(yù)期的運行。對用于制造或質(zhì)量體系中的成品軟件，附加的指南包括在本文件的6.3部分中。對器械軟件，附加的有用信息可見于美國食品藥品管理局的行業(yè)指南，美國食品藥品管理局評審員，和符合用于醫(yī)療器械的成品軟件。2.4質(zhì)量體系法規(guī)對上市前提交本文件標(biāo)明包括實現(xiàn)軟件確認(rèn)的質(zhì)量體系法規(guī)出版物。其為管理和控制軟件確認(rèn)過程提供指南。軟件確認(rèn)過程的管理和控制不應(yīng)當(dāng)和任何其它的確認(rèn)要求例如對自動化制造過程的過程確認(rèn)相混淆。器械制造商可使用同一規(guī)程和記錄符合質(zhì)量體系和設(shè)計控制要求，以及上市前提交給美

15、國食品藥品管理局。本文件并不覆蓋和軟件確認(rèn)有關(guān)的任何特定的安全性或功效問題。規(guī)定軟件的上市前提交的設(shè)計問題和文件編制要求并不由本文件標(biāo)明。有關(guān)安全性和功效的特定問題，和要求在上市前提交的文件編制，應(yīng)當(dāng)向器械評價辦公室（ode），設(shè)備儀器與放射健康中心（cdrh）或血液研究與評審辦公室，生物制品評價與研究中心（cber）標(biāo)明。為上市前提交的可適用的美國食品藥品管理局的指南文件的參考文獻見附錄a。 第三部分 軟件確認(rèn)的前后關(guān)系許多人就美國食品藥品管理局期望他們做什么來確保符合有關(guān)軟件確認(rèn)的質(zhì)量體系法規(guī)尋求特定的指南。本文件中提出的軟件確認(rèn)信息不是新的。使用第4和第5部分中列出的原則和任務(wù)的軟件確認(rèn)

16、，已經(jīng)在軟件行業(yè)的許多部分實施了20多年。由于醫(yī)療器械、工藝和制造設(shè)備的較大變化，不可能在一個文件中指定所有特定的確認(rèn)要素是適用的。然而，幾個寬泛概念的綜合應(yīng)用可被成功地用作軟件確認(rèn)指南。這些寬泛的概念為建立軟件確認(rèn)的綜合方法提供可接受的框架。附加的特定信息可從附錄a中列出的許多參考文獻中獲得。3.1 定義和術(shù)語除非在質(zhì)量體系法規(guī)中規(guī)定，或相反在下面指定，所有用于本指南的其它術(shù)語都如美國食品藥品管理局的計算機化的系統(tǒng)和軟件開發(fā)術(shù)語的術(shù)語表的當(dāng)前版本中所規(guī)定。 醫(yī)療器械質(zhì)量體系法規(guī)（21cfr820.3（k）規(guī)定“建立”意指“規(guī)定、形成文件和實施?！痹诒局改现谐霈F(xiàn)的詞“建立”和“已建立”應(yīng)當(dāng)被解

17、釋成具有同樣的意義。一些見于醫(yī)療器械質(zhì)量體系法規(guī)的定義在和通常在軟件行業(yè)中使用的術(shù)語相比較時可被混淆。示例是要求、規(guī)范、驗證和確認(rèn)。3.1.1 需求和規(guī)范 雖然質(zhì)量體系法規(guī)規(guī)定設(shè)計輸入需求必須備有證明文件，特定的需求必須被驗證，法規(guī)并不進一步闡明術(shù)語“需求”和“規(guī)范”之間的區(qū)別。需求可以是體系或其軟件的任何需要或預(yù)期。需求反映用戶的規(guī)定的或暗指的需要，也許是基于市場的、合同的、或法令的，以及組織的內(nèi)部需求。可以有許多不同種類的需求（例如，設(shè)計、功能、實現(xiàn)、接口、性能或物理需求）。軟件需求典型地得自對已經(jīng)分配給軟件的系統(tǒng)功能性的那些方面的系統(tǒng)需求。軟件需求典型地在功能術(shù)語中陳述，并規(guī)定、改進和更

18、新為開發(fā)項目的進展。在軟件需求的準(zhǔn)確地和完全地文件編制中的成功是作為結(jié)果的軟件的成功確認(rèn)中的關(guān)鍵因素。規(guī)范定義為“指定要求的文件”（見21cfr820.3（y）其可涉及或包括制圖、圖形、或其它有關(guān)文件，通常指出方法和標(biāo)準(zhǔn)，借此可檢查對要求的符合度。有許多不同種類的書面規(guī)范，例如，系統(tǒng)要求規(guī)范、軟件要求規(guī)范、軟件設(shè)計規(guī)范、軟件測試規(guī)范、軟件集成規(guī)范等等。所有這些文件建立“規(guī)定的要求”，其設(shè)計輸出的不同形式的驗證是必要的。3.1.2 驗證和確認(rèn)質(zhì)量體系法規(guī)和iso8402：1994協(xié)調(diào)，其將“驗證”和“確認(rèn)”視為分別的并截然不同的術(shù)語。另一方面，許多軟件工程期刊文章和教科書可交換地使用術(shù)語“驗證”

19、和“確認(rèn)”有時候涉及軟件“驗證、確認(rèn)和測試（vv和t）好像是單一的概念，在這三個術(shù)語之間沒有區(qū)別。軟件驗證提供軟件開發(fā)生存周期特定階段的設(shè)計輸出滿足該階段的所有特定要求的客觀證據(jù)。軟件驗證尋找軟件和其支持文件的一致性、完整性、和正確性。在其被開發(fā)時，為隨后的軟件已經(jīng)確認(rèn)的結(jié)論提供支持。軟件測試是預(yù)期確定軟件開發(fā)輸出滿足其輸入要求的許多驗證活動之一。其它驗證活動包括各種各樣的靜態(tài)和動態(tài)分析，編碼和文件檢查、走查和其它技術(shù)。軟件確認(rèn)是已完成器械的設(shè)計確認(rèn)的一部分，但是沒有在質(zhì)量體系法規(guī)中分別規(guī)定。對本指南的用途，美國食品藥品管理局考慮軟件確認(rèn)為“通過檢查和規(guī)定軟件規(guī)范符合用戶需求和預(yù)期使用的客觀證

20、據(jù)，和特定要求的實現(xiàn)通過軟件可被始終如一地完成來證實。”在實踐中，軟件確認(rèn)活動也許發(fā)生在這兩個過程中，以及在軟件開發(fā)生存周期的終端以確保所有的要求已經(jīng)實現(xiàn)。既然軟件通常是大的硬件系統(tǒng)的一部分，軟件確認(rèn)典型地包括所有軟件要求已經(jīng)正確地和完整地實現(xiàn)并可追溯到系統(tǒng)要求的證據(jù)。軟件已經(jīng)確認(rèn)的結(jié)論高度依賴在軟件開發(fā)生存周期的每個階段完成的綜合的軟件測試、檢查、分析和其它驗證任務(wù)。在模擬的使用環(huán)境中的器械軟件功能性測試和用戶現(xiàn)場測試典型地被包括作為軟件自動化器械的整體設(shè)計確認(rèn)程序的組件。軟件驗證和確認(rèn)是很難的，因為開發(fā)者不能始終測試，很難知道多少證據(jù)是足夠的。 在大的測量中，軟件確認(rèn)是開發(fā)（器械滿足軟件自

21、動化功能和器械特征的所有要求和用戶預(yù)期）的“置信度級別”的問題。例如在規(guī)范文件中發(fā)現(xiàn)的缺陷，估計剩余缺陷，測試覆蓋范圍，和其它技術(shù)等措施都用于在產(chǎn)品發(fā)貨前開發(fā)一個可接受的置信度級別。置信度級別，為此需要的軟件確認(rèn)、驗證和測試工作級別將依賴器械的自動化功能引起的安全性風(fēng)險（危害）而變化。關(guān)于軟件的安全性風(fēng)險管理的附加指南見美國食品藥品管理局的第4部分包含在醫(yī)療器械中的軟件的上市前提交內(nèi)容的指南，和國際標(biāo)準(zhǔn)iso/iec14971-1和iec60601-1-4，在附錄a中引用。3.1.3 iq/oq/pq多年以來，美國食品藥品管理局和管理行業(yè)試圖在過程確認(rèn)術(shù)語的上下文中理解和定義軟件確認(rèn)。例如，行

22、業(yè)文件和其它的美國食品藥品管理局確認(rèn)指南有時按照安裝鑒定（iq）、操作鑒定（oq）和性能鑒定（pq）來描述用戶現(xiàn)場軟件確認(rèn)。這些術(shù)語的定義和有關(guān)iq/oq/pq的附加信息見美國食品藥品管理局的過程確認(rèn)總則的指南，注明日期1987年5月11日，和美國食品藥品管理局的計算機化的系統(tǒng)和軟件開發(fā)術(shù)語的術(shù)語表。注明日期1995年8月。當(dāng)iq/oq/pq術(shù)語良好地服務(wù)其用途，并且是在用戶現(xiàn)場組織軟件確認(rèn)任務(wù)的許多合理方法之一。也許在許多軟件專業(yè)人員中本術(shù)語沒有被很好地理解，其不用于本文件中的別處。 然而，美國食品藥品管理局人員和器械制造商兩者尋找和提供關(guān)于軟件確認(rèn)的信息時需要知道術(shù)語中的這些區(qū)別。 3.2

23、 軟件開發(fā)作為系統(tǒng)設(shè)計的一部分使用軟件來實現(xiàn)系統(tǒng)功能性是在系統(tǒng)設(shè)計過程中典型地做出的決策之一。軟件要求典型地得自全面系統(tǒng)要求，為系統(tǒng)中的那些方面的設(shè)計要使用軟件來實現(xiàn)。對已經(jīng)完成的器械有用戶需要和預(yù)期使用，但是用戶典型地并不規(guī)定那些要求是否由硬件、軟件或兩者的一些結(jié)組合滿足。因此，軟件確認(rèn)必須在體系的全面設(shè)計確認(rèn)的上下文中考慮。備有證明文件的需求說明代表用戶的需要和預(yù)期使用，由此來開發(fā)產(chǎn)品。軟件確認(rèn)的首要目標(biāo)是然后證明所有已經(jīng)完成的軟件產(chǎn)品符合所有備有證明文件的軟件和系統(tǒng)需求。系統(tǒng)需求和軟件需求兩者的正確性完整性兩者應(yīng)當(dāng)作為器械的設(shè)計確認(rèn)過程的一部分來標(biāo)明。軟件確認(rèn)包括證實對所有軟件規(guī)范的符合

24、性，證實所有的軟件要求追溯到系統(tǒng)規(guī)范。證實是全部設(shè)計確認(rèn)的一個重要部分以確保醫(yī)療器械的所有方面符合用戶需要和預(yù)期使用。3.3 軟件不同于硬件當(dāng)軟件分擔(dān)許多和硬件一樣的工程任務(wù)時，有一些非常重要的區(qū)別。例如：l 軟件問題中的大多數(shù)可追溯到在設(shè)計和開發(fā)過程中形成的錯誤。 硬件產(chǎn)品質(zhì)量高度依靠設(shè)計、開發(fā)和制造，軟件產(chǎn)品質(zhì)量主要依靠對軟件制造最小關(guān)注的設(shè)計和開發(fā)。軟件開發(fā)由可容易驗證的再現(xiàn)組成。很難制造數(shù)千的功能和原件完全相同的程序副本；困難來自使得原程序滿足所有的規(guī)范。l 最重要的特征之一是軟件分支，即基于不同輸入的執(zhí)行選擇性的操作系列的能力。該特征對軟件的另一個特性其復(fù)雜性是一個主要的促成因素。甚

25、至簡短的程序可以非常復(fù)雜很難充分理解。l 典型地，單獨的測試不能充分驗證軟件已經(jīng)完成和校正。除測試之外，其它的驗證技術(shù)和有結(jié)構(gòu)的備有證明文件的開發(fā)過程應(yīng)當(dāng)組合以確保綜合的確認(rèn)方法。 l 不同于硬件，軟件不是物理實體不會磨損。事實上，當(dāng)潛在的缺陷被發(fā)現(xiàn)和去除時，軟件也許隨著壽命而改進。然而，因為軟件經(jīng)常更新和改變，這樣的改進有時由在更改期間引入軟件的新缺陷來計數(shù)。 l 不象一些硬件故障，軟件失效的發(fā)生沒有高級警報。軟件的分支允許在執(zhí)行期間跟隨不同的路徑，也許隱藏了一些潛在的缺陷直到軟件產(chǎn)品被引入到市場很久之后。 l 軟件的另一個有關(guān)特征是速度和易于改變。該因素可導(dǎo)致軟件和非軟件專業(yè)人員兩者相信軟

26、件問題可被容易地校正。和缺乏對軟件的理解相結(jié)合，可導(dǎo)致管理人員相信緊密控制的工程對于軟件不象其對于硬件那么需要。實際上，相反的是真實的。因為其復(fù)雜性，軟件的開發(fā)過程應(yīng)當(dāng)比硬件更緊密地控制，為了防止在開發(fā)過程中不能容易地稍后找到的問題。l 軟件編碼的表面上不重要的改變會造成軟件問題中其它的未預(yù)料到的非常重要的問題。軟件開發(fā)過程應(yīng)當(dāng)充分地良好計劃、受控和備有證明文件以發(fā)現(xiàn)和校正由軟件更改產(chǎn)生的未預(yù)料到的結(jié)果。l 假設(shè)對軟件專業(yè)人員和高度活動的工作人員的高要求，對軟件做出維護更改的軟件人員也許沒有包括在原軟件的開發(fā)中。因此，準(zhǔn)確的和徹底的文件是必需的。l 歷史上，軟件組件不象硬件組件一樣頻繁地標(biāo)準(zhǔn)化

27、和可互換。然而，醫(yī)療器械軟件開發(fā)者開始使用基于組件的開發(fā)工具和技術(shù)。目標(biāo)導(dǎo)向的方法和使用成品軟件組件保證更快和花費較低的軟件開發(fā)。然而，基于組件的方法要求集成期間的仔細關(guān)注。在集成之前，需要時間來充分地定義并開發(fā)可重復(fù)使用的軟件編碼并充分理解成品組件的性能。 由于這些和其它原因，軟件工程比硬件工程需要更高級別的管理研究和控制。3.4 軟件確認(rèn)的益處軟件確認(rèn)是用于確保器械軟件質(zhì)量和軟件自動化操作的關(guān)鍵工具。軟件確認(rèn)可提高器械的適用性和可靠性，導(dǎo)致減少的失效率，較少的召回和校正措施，對患者和用戶的較小風(fēng)險，減少器械制造商的責(zé)任。軟件確認(rèn)也能通過使得可靠地更改軟件和再確認(rèn)軟件更改更容易和成本更低來降

28、低長期成本。軟件維護能代表軟件在其整個生存周期的總成本的非常大的百分比。已確定的綜合的軟件確認(rèn)過程通過降低每個軟件發(fā)布之后的確認(rèn)成本來幫助降低軟件的長期成本。 3.5 設(shè)計評審設(shè)計評審是設(shè)計的備有證明文件的、綜合的和系統(tǒng)的檢查以評價設(shè)計要求的適當(dāng)性、評價設(shè)計滿足這些要求的能力，并識別問題。也許有發(fā)生在軟件項目期間的開發(fā)團隊中的許多非正式的技術(shù)評審，正式的設(shè)計評審是更結(jié)構(gòu)化的包括參與開發(fā)團隊之外的其它評審。正式的設(shè)計評審也許參考或包括由其它正式的和非正式的評審的產(chǎn)生的結(jié)果。在軟件和硬件一起整合到系統(tǒng)中之后，設(shè)計評審也許為軟件分別進行，或兩者。設(shè)計評審應(yīng)當(dāng)包括檢查開發(fā)計劃、要求規(guī)范、設(shè)計桂發(fā)、測試

29、計劃和規(guī)程，所有和項目有關(guān)的其它文件和活動，來自確定的生存周期的每個階段的驗證結(jié)果，和對整個器械的確認(rèn)結(jié)果。設(shè)計評審是管理和評價開發(fā)項目的主要工具。例如，正式的設(shè)計評審允許管理來確定軟件確認(rèn)計劃中規(guī)定的所有目標(biāo)已經(jīng)達到。質(zhì)量體系法規(guī)要求在器械設(shè)計過程中至少進行一個正式的設(shè)計評審。然而，推薦進行多個設(shè)計評審（例如，在每個軟件生存周期活動的終端，為進行下一個活動作準(zhǔn)備）。在主要的資源用于特定的設(shè)計解決方案之前，正式的設(shè)計評審在要求活動的終端或附近是特別重要的?？梢愿菀椎亟鉀Q在該點發(fā)現(xiàn)的問題，節(jié)省時間和錢，降低遺漏問題的可能性。 一些關(guān)鍵問題的答案應(yīng)當(dāng)在正式的設(shè)計評審中備有證明文件。這些包括：l

30、已經(jīng)為每個軟件生存周期活動建立適當(dāng)?shù)娜蝿?wù)和預(yù)期的結(jié)果、輸出、或產(chǎn)品嗎？l 每個軟件生存周期活動的任務(wù)和預(yù)期結(jié)果、輸出或產(chǎn)品： 遵從根據(jù)正確性、完整性、一致性和準(zhǔn)確性的其它軟件生存周期活動的要求嗎？ 確?；顒拥囊?guī)程、實踐和慣例嗎？ 為下一個軟件生存周期活動的啟動任務(wù)建立適當(dāng)?shù)幕A(chǔ)嗎？ 第四部分 軟件確認(rèn)的原則本部分列出應(yīng)當(dāng)為軟件確認(rèn)考慮的總原則。4.1 要求備有證明文件的軟件要求規(guī)范提供確認(rèn)和驗證兩者的基準(zhǔn)。沒有已經(jīng)建立的軟件要求規(guī)范不能完成軟件確認(rèn)過程（參考文獻：21cfr820.3（z）和（aa）和820.30（f）和（g）.4.2 缺陷預(yù)防軟件質(zhì)量保證需要集中于防止將缺陷引入到軟件開發(fā)過程

31、中，不集中于軟件編碼寫好后試圖將“測試質(zhì)量”引入到軟件編碼中。軟件測試將所有的潛在缺陷形成在軟件編碼的表面的能力是非常有限的。例如，多數(shù)軟件的復(fù)雜性防止其被徹底地測試。軟件測試是一個必要的活動。然而，一般地軟件測試本身并不足以建立軟件適合于其預(yù)期用途的置信度。為了建立該置信度，軟件開發(fā)者應(yīng)當(dāng)使用方法和技術(shù)的混合來防止軟件錯誤并檢測到確實發(fā)生的軟件錯誤。方法的“最佳混合”依靠包括開發(fā)環(huán)境、應(yīng)用、項目大小、語言和風(fēng)險的許多因素。4.3 時間和工作要建立軟件已經(jīng)確認(rèn)的情況要求時間和工作。為軟件確認(rèn)的準(zhǔn)備應(yīng)當(dāng)及早開始，即在設(shè)計和開發(fā)規(guī)劃和設(shè)計輸出期間。軟件已經(jīng)確認(rèn)的最終結(jié)論應(yīng)當(dāng)基于從整個軟件生存周期中

32、進行的有計劃的工作來收集的證據(jù)。 4.4 軟件生存周期軟件確認(rèn)發(fā)生在已經(jīng)建立的軟件生存周期環(huán)境中。軟件生存周期包含軟件工程任務(wù)和必要的文件以支持軟件確認(rèn)工作。此外，軟件生存周期包含適合于軟件預(yù)期用途的特定驗證和確認(rèn)任務(wù)。本指南并不推薦任何特定的生存周期模式-僅僅推薦應(yīng)當(dāng)為軟件開發(fā)項目選擇和使用的。4.5 計劃通過使用計劃來規(guī)定和控制軟件確認(rèn)過程。軟件確認(rèn)計劃規(guī)定通過軟件確認(rèn)工作完成“什么”。軟件確認(rèn)計劃是重要的質(zhì)量體系工具。軟件確認(rèn)計劃規(guī)定的領(lǐng)域例如范圍、方法、資源、日程計劃，活動、任務(wù)和工作項目的類型和內(nèi)容。4.6 規(guī)程通過使用規(guī)程來執(zhí)行軟件確認(rèn)過程。這些規(guī)程制定“如何”實施軟件確認(rèn)工作。規(guī)

33、程應(yīng)當(dāng)識別要完成單獨的確認(rèn)活動、任務(wù)和工作項目必須采用的特定操作或操作順序。4.7 更改之后的軟件確認(rèn)由于軟件的復(fù)雜性，表面上較小的局部更改也許對整個系統(tǒng)有重要影響。當(dāng)對軟件做出更改（即使小的更改），軟件的確認(rèn)狀態(tài)需要再確定。只要軟件更改了，應(yīng)當(dāng)不僅僅對單獨的更改確認(rèn)實施確認(rèn)分析，而且確定更改對整個軟件系統(tǒng)的范圍和影響?；谠摲治?，軟件開發(fā)者應(yīng)當(dāng)進行適當(dāng)級別的軟件回歸測試以顯示系統(tǒng)的未改變的但是易損的部分沒有受到負(fù)面影響。設(shè)計控制和適當(dāng)?shù)幕貧w測試在軟件更改之后提供軟件已經(jīng)確認(rèn)的置信度。4.8 確認(rèn)覆蓋范圍確認(rèn)覆蓋范圍基于軟件的復(fù)雜性和安全性風(fēng)險-不是基于嚴(yán)格的尺寸或限制。確認(rèn)活動、任務(wù)和工作項

34、目的選擇應(yīng)當(dāng)和軟件設(shè)計以及和軟件對特定的預(yù)期用途的使用有關(guān)的風(fēng)險的復(fù)雜性相稱。對于較低風(fēng)險的器械，僅僅實施基準(zhǔn)確認(rèn)活動。當(dāng)風(fēng)險增加時，應(yīng)當(dāng)增加附加的確認(rèn)活動以覆蓋附加的風(fēng)險。確認(rèn)文件編制應(yīng)當(dāng)足以證實所有的軟件確認(rèn)計劃和規(guī)程已經(jīng)成功地完成。4.9 評審的獨立性確認(rèn)活動應(yīng)當(dāng)使用“評審的獨立性”的基本質(zhì)量保證規(guī)則來實施。自我確認(rèn)是非常困難的?？赡軙r，獨立的評價總是更好的，尤其對于較高的風(fēng)險應(yīng)用。一些公司承包給第三方獨立的驗證和確認(rèn)。但是該解決方案也許并不總是切實可行的。另一個方法是指定沒有包括在特定的設(shè)計或其實施中，但是具有評價項目和實施驗證和確認(rèn)活動的充分知識的內(nèi)部全體職員成員。為了維護評審的內(nèi)部

35、獨立性，較小的公司也許需要在如何組織和分配任務(wù)上具有創(chuàng)造性。4.10 靈活性和責(zé)任這些軟件確認(rèn)原則的特定實施的應(yīng)用之間也許完全不同。器械制造商在選擇如何應(yīng)用這些確認(rèn)原則中具有靈活性，但是保留證實軟件已經(jīng)被確認(rèn)的最終責(zé)任。軟件在很寬的環(huán)境范圍中設(shè)計、開發(fā)、確認(rèn)和管理，對于較寬種類的器械具有變化的風(fēng)險級別。美國食品藥品管理局管理的醫(yī)療器械應(yīng)用包括的軟件：l 是醫(yī)療器械的組件、部件或附件l 其本身是醫(yī)療器械；或l 用于質(zhì)量體系的制造、設(shè)計和開發(fā)或其它部分。在每個環(huán)境中，來自許多來源的軟件組件也許用于創(chuàng)造應(yīng)用（例如內(nèi)部開發(fā)的軟件、成品軟件、合同軟件、共享軟件）。此外，軟件組件以許多不同的形式出現(xiàn)（例如

36、應(yīng)用軟件、操作系統(tǒng)、編譯程序、調(diào)試程序、配置管理工具和許多更多的）。在這些環(huán)境中的軟件確認(rèn)可以是復(fù)雜的任務(wù)；因此，當(dāng)設(shè)計軟件確認(rèn)過程時考慮所有這些軟件確認(rèn)原則是適當(dāng)?shù)?。作為結(jié)果的軟件確認(rèn)過程應(yīng)當(dāng)和有關(guān)體系、器械或過程的安全性風(fēng)險相稱。軟件確認(rèn)活動和任務(wù)也許是分散的，發(fā)生在不同的位置由不同的組織實施。然而，不管任務(wù)的分布、合同關(guān)系、組件來源、或開發(fā)環(huán)境、器械制造商或規(guī)范開發(fā)者保留確保軟件已經(jīng)確認(rèn)的最終責(zé)任。 第5部分 活動和任務(wù)軟件確認(rèn)是通過在軟件開發(fā)生存周期的不同階段計劃和執(zhí)行的一系列的活動和任務(wù)來完成。依賴使用的生存周期模式和在軟件計劃進展時做出的更改的范圍，這些任務(wù)也許是一次性出現(xiàn)或重復(fù)許

37、多次。5.1 軟件生存周期活動本指南不推薦任何特定軟件生存周期模式的使用。軟件開發(fā)者應(yīng)當(dāng)建立適合于他們的產(chǎn)品和組織的軟件生存周期模式。所選擇的軟件生存周期模式應(yīng)當(dāng)覆蓋軟件從其產(chǎn)生到其收回。典型的軟件生存周期模式中的活動包括下列各項：l 質(zhì)量規(guī)劃l 系統(tǒng)要求定義l 詳細的軟件要求規(guī)范l 軟件設(shè)計規(guī)范l 結(jié)構(gòu)或編碼l 測試l 安裝l 操作或支持l 維護l 收回支持軟件確認(rèn)的驗證、測試和其它任務(wù)發(fā)生在這些活動中的每一個期間。生存周期模式以不同的方式組織這些軟件開發(fā)活動，并提供監(jiān)測和控制軟件開發(fā)計劃的框架，幾個軟件生存周期模式在美國食品藥品管理局的 計算機化系統(tǒng)和軟件開發(fā)術(shù)語的術(shù)語表（注明日期1995

38、年8月）中規(guī)定。這些和許多其它的生存周期模式在附錄a中列出的不同的參考文獻中描述。5.2 支持確認(rèn)的典型任務(wù)對每個軟件生存周期活動，有支持軟件已經(jīng)被確認(rèn)的結(jié)論的確定的“典型”任務(wù)。然而，要完成的特定任務(wù)，它們的特定順序和它們的性能的重復(fù)和定時將由所選擇的特定軟件生存周期模式和有關(guān)軟件應(yīng)用的安全性風(fēng)險規(guī)定。對于非常低風(fēng)險的應(yīng)用，確定的任務(wù)也許完全不需要。然而，軟件開發(fā)者至少應(yīng)當(dāng)考慮這些任務(wù)中的每一個，并應(yīng)當(dāng)對哪個任務(wù)適合或不適合于他們的特定應(yīng)用進行規(guī)定和備有證明文件。下面的討論是一般的，預(yù)期不規(guī)定任何特定的軟件生存周期模式或完成任務(wù)的任何特定順序。5.2.1 質(zhì)量規(guī)劃設(shè)計和開發(fā)規(guī)劃應(yīng)當(dāng)在為異常的

39、報告和解決方案識別必要的任務(wù)、規(guī)程，必要的資源、管理評審要求，包括正式的設(shè)計評審的計劃中結(jié)束。應(yīng)當(dāng)識別軟件生存周期模式和有關(guān)的活動，以及對每個軟件生存周期活動必要的那些任務(wù)。該計劃應(yīng)當(dāng)包括：l 每個生存周期活動的特定任務(wù)；l 列舉重要的質(zhì)量因素（例如可靠性、可維護性和適用性）；l 每個任務(wù)的方法和規(guī)程；l 任務(wù)的驗收準(zhǔn)則；l 協(xié)商規(guī)定和記錄輸出的標(biāo)準(zhǔn)將允許評價它們對輸入要求的符合性。l 每個任務(wù)的輸入；l 來自每個任務(wù)的輸出；l 每個任務(wù)的作用、資源和責(zé)任；l 風(fēng)險和假定；和l 用戶需要的文件。管理必須識別并提供適當(dāng)?shù)能浖_發(fā)環(huán)境和資源。（見21cfr820.20（b）(1)和（2） ）。典型

40、地，每個任務(wù)要求人員以及物理資源。該計劃應(yīng)當(dāng)為每個任務(wù)識別人員、設(shè)備和設(shè)備資源，和風(fēng)險（危害）管理發(fā)揮的作用。應(yīng)當(dāng)制定指導(dǎo)和控制多個并行的開發(fā)活動并確保適當(dāng)?shù)臏贤ê臀募幹频呐渲霉芾碛媱潯？刂剖谴_保組成軟件系統(tǒng)的規(guī)范文件、資源編碼、目標(biāo)編碼和測試序列的所有認(rèn)可的版本之間的確實的、正確的對應(yīng)所必須的?？刂埔矐?yīng)當(dāng)確保正確的識別和訪問當(dāng)前認(rèn)可的版本。應(yīng)當(dāng)為通過確認(rèn)或其它活動發(fā)現(xiàn)的軟件異常的報告和解決創(chuàng)造規(guī)程。管理應(yīng)當(dāng)識別報告和指定內(nèi)容、格式和為每個報告負(fù)責(zé)的組織要素。規(guī)程對于評審和認(rèn)可軟件開發(fā)結(jié)果（包括為這樣的評審和認(rèn)可負(fù)責(zé)的組織要素）也是必要的。典型任務(wù)-質(zhì)量規(guī)劃l 風(fēng)險（危害）管理計劃l 配置管

41、理計劃l 軟件質(zhì)量保證計劃軟件驗證和確認(rèn)計劃 驗證和確認(rèn)任務(wù)和驗收準(zhǔn)則 進程和資源分配（對軟件驗證和確認(rèn)活動） 報告要求 正式的設(shè)計評審要求 其它的技術(shù)評審要求l 問題報告和解決規(guī)程l 其它的支持活動5.2.2 要求要求的制定包括關(guān)于器械和其預(yù)期用途的識別、分析和文件編制。特殊重要性的領(lǐng)域包括將系統(tǒng)功能分配給硬件/軟件，操作條件、用戶特性、潛在危害和預(yù)期任務(wù)。此外，要求應(yīng)當(dāng)清楚地規(guī)定軟件的預(yù)期用途。軟件要求說明文件應(yīng)當(dāng)包含軟件功能的書面定義。沒有預(yù)定的和備有證明文件的軟件要求要確認(rèn)軟件是不可能的。典型的軟件要求規(guī)定下列各項：l 所有的軟件系統(tǒng)輸入；l 所有的軟件系統(tǒng)輸出；l 軟件系統(tǒng)要完成的所

42、有功能；l 軟件要滿足的所有性能要求（例如數(shù)據(jù)通過量、可靠性和定時）；l 所有外部和用戶接口以及所有內(nèi)部軟件和系統(tǒng)接口的定義；l 用戶如何和系統(tǒng)相互作用；l 什么構(gòu)成錯誤，錯誤應(yīng)當(dāng)如何處理；l 要求的響應(yīng)次數(shù)；l 軟件的預(yù)期操作環(huán)境，如果這是設(shè)計限制因素（例如硬件平臺、操作系統(tǒng)）；l 軟件要接受的所有范圍、限制、和特定值；和l 要在軟件中實現(xiàn)的所有和安全性有關(guān)的要求、規(guī)范、特征和功能。軟件安全性要求得自和系統(tǒng)要求開發(fā)過程緊密結(jié)合的技術(shù)風(fēng)險管理過程。軟件要求規(guī)范應(yīng)當(dāng)清楚地識別由系統(tǒng)中的軟件失效以及要在軟件中實現(xiàn)的所有安全性要求產(chǎn)生的潛在的危害。應(yīng)當(dāng)和減輕軟件失效的方法（例如硬件減輕，防御性程序設(shè)

43、計，等等）一起評價軟件失效的后果。由此分析，識別防止損害所必要的最適當(dāng)?shù)拇胧?yīng)當(dāng)是可能的。質(zhì)量體系法規(guī)要求標(biāo)明不完整、不明確或不一致要求的機制。（見21cfr820.30（c）應(yīng)當(dāng)評價在軟件要求規(guī)范中識別的每個要求（例如硬件、軟件、用戶、操作員界面和安全性）的精確性、完整性、相容性、可測性、正確性和明確性。例如，應(yīng)當(dāng)評價軟件要求以驗證：l 在要求之間沒有內(nèi)部的不一致；l 系統(tǒng)的所有性能要求已經(jīng)清楚地說明；l 完成并校正故障容許度、安全性和保密性要求；l 軟件功能的分配是正確的完整的；l 軟件要求對系統(tǒng)危害是適當(dāng)?shù)?；和l 所有要求用可測量的或客觀上能驗證的話來表達。應(yīng)當(dāng)進行軟件要求的可追溯性分析

44、來追溯軟件要求到（和從） 系統(tǒng)要求和到風(fēng)險分析結(jié)果。除用于驗證軟件要求的任何其它分析和文件之外，推薦正式的設(shè)計評審以確定在廣泛的軟件設(shè)計工作開始之前要求被充分地規(guī)定并且是適當(dāng)?shù)?。要求可逐漸增加地批準(zhǔn)和發(fā)布，但是應(yīng)當(dāng)當(dāng)心軟件（和硬件）要求之間的相互作用和接口被適當(dāng)?shù)卦u審、分析和控制。典型任務(wù)要求l 初步的風(fēng)險分析l 可追溯性分析 軟件要求到系統(tǒng)要求（反之亦然） 軟件要求到風(fēng)險分析l 用戶特征的描述l 主要和次要存儲器的特征和限制列表l 軟件要求評價l 軟件用戶接口要求分析l 系統(tǒng)測試計劃生成l 驗收測試計劃生成l 模糊評審或分析5.2.3 設(shè)計在設(shè)計過程中，將軟件要求規(guī)范轉(zhuǎn)換成軟件要實現(xiàn)的邏輯的

45、和物理的表示。軟件設(shè)計規(guī)范是軟件應(yīng)當(dāng)做什么和其應(yīng)當(dāng)如何做的描述。由于計劃的復(fù)雜性或使得具有不同級別的技術(shù)責(zé)任的人能夠清楚地理解設(shè)計信息，設(shè)計規(guī)范可包含設(shè)計的高度概要和詳細的設(shè)計信息兩者。已完成的軟件設(shè)計規(guī)范限制程序設(shè)計師/編碼員停留在經(jīng)過協(xié)議的要求和設(shè)計的意圖內(nèi)。完整的軟件設(shè)計規(guī)范將減輕程序設(shè)計師做出特別設(shè)計決策的需要。軟件設(shè)計需要標(biāo)明人員因素。由設(shè)計導(dǎo)致的使用錯誤或者是極度地復(fù)雜或者是和用戶對操作直覺預(yù)期相反，是美國食品藥品管理局遇到的最持久的和關(guān)鍵的問題之一。軟件設(shè)計常常是這種使用錯誤中的一個因素。應(yīng)當(dāng)將人機工程學(xué)組合在整個設(shè)計和開發(fā)過程中，包括器械設(shè)計要求、分析和測試。當(dāng)開發(fā)流程圖、狀態(tài)

46、圖、樣機工具和測試計劃時應(yīng)當(dāng)考慮器械安全性和適用性問題。同樣，應(yīng)當(dāng)完成任務(wù)和功能分析、風(fēng)險分析、樣機測試和評審、完整的適用性測試。當(dāng)應(yīng)用這些方法時應(yīng)當(dāng)包括來自用戶總體的參與者。軟件設(shè)計規(guī)范應(yīng)當(dāng)包括：l 軟件要求規(guī)范，包括軟件的預(yù)定驗收標(biāo)準(zhǔn)；l 軟件風(fēng)險分析；l 開發(fā)規(guī)程和編碼指南（或其它的程序設(shè)計規(guī)程）；l 描述系統(tǒng)的前后關(guān)系的系統(tǒng)文件編制（例如敘述性的或上下文圖表）中的程序預(yù)期操作，包括硬件、軟件和物理環(huán)境的關(guān)系。l 要使用的硬件；l 要測定或記錄的參數(shù)；l 邏輯結(jié)構(gòu)（包括控制邏輯）和邏輯上的數(shù)據(jù)處理步驟（例如算法）；l 數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)流程圖；l 變量（控制和數(shù)據(jù)）的定義和定義用于哪里的描述

47、；l 錯誤、報警和報警信息；l 支持軟件（例如操作系統(tǒng)、驅(qū)動程序、其它的應(yīng)用軟件）；l 通信聯(lián)絡(luò)鏈接（軟件的內(nèi)部模塊之間的鏈接、和支持軟件的鏈接、和硬件的鏈接、和用戶的鏈接）；l 保密性措施（物理和邏輯保密性兩者）；和l 沒有在上述要素中識別的任何附加限制；上面指出的要素中的前4個通常是包括在軟件設(shè)計規(guī)范中的參考文獻中的單獨的現(xiàn)有之前的文件。在前述章節(jié)中討論的軟件要求規(guī)范被看作軟件風(fēng)險分析。書面的開發(fā)規(guī)程用作組織的指南，書面的程序設(shè)計規(guī)程用作個體的程序設(shè)計師的指南。當(dāng)沒有軟件在其中預(yù)期操作的上下文的知識軟件不能被確認(rèn)時，參考系統(tǒng)的文件編制。如果上述要素中的某些沒有包括在軟件中，如果清楚地表明也

48、許對軟件將來的評審者和維護者有幫助，（例如在該程序中沒有錯誤信息）。在軟件設(shè)計期間發(fā)生的活動有幾個目的。進行軟件設(shè)計評價以確定設(shè)計是否完整、正確、一致、明確、可行和可維護。當(dāng)需要軟件更改時，設(shè)計期間軟件體系結(jié)構(gòu)（例如模塊結(jié)構(gòu)）的適當(dāng)考慮可降低將來的確認(rèn)工作數(shù)量。軟件設(shè)計評價也許包括控制流、數(shù)據(jù)流、復(fù)雜性、定時、容量估計、存儲器分配、關(guān)鍵程度分析和設(shè)計的許多其它方面的分析。應(yīng)當(dāng)進行可追溯性分析來驗證軟件設(shè)計實現(xiàn)了所有的軟件要求。作為識別要求在哪里不充分的技術(shù)，可追溯性分析也應(yīng)當(dāng)驗證設(shè)計的所有方面都可追溯到軟件要求。應(yīng)當(dāng)進行通訊聯(lián)絡(luò)鏈接的分析來就硬件、用戶和有關(guān)的軟件要求評價提議的設(shè)計。應(yīng)當(dāng)再檢查

49、軟件風(fēng)險分析以確定所有附加的危害是否已經(jīng)被識別，所有新的危害是否已經(jīng)由設(shè)計引入。在軟件設(shè)計活動結(jié)束時，在移動到實現(xiàn)設(shè)計之前應(yīng)當(dāng)進行正式的設(shè)計評審來驗證設(shè)計是正確的、一致的、完整的、精確的、可試驗的。設(shè)計的幾個部分為實現(xiàn)可逐漸增加地批準(zhǔn)和發(fā)布；但是應(yīng)當(dāng)當(dāng)心在不同要素之間的相互作用和通訊聯(lián)絡(luò)鏈接被適當(dāng)?shù)卦u審、分析和控制。大多數(shù)軟件開發(fā)模塊是重復(fù)的。這很可能導(dǎo)致軟件要求規(guī)范和軟件設(shè)計規(guī)范兩者的幾個版本。應(yīng)當(dāng)按照已建立的配置管理規(guī)程獲得和控制所有經(jīng)批準(zhǔn)的版本。典型任務(wù)設(shè)計l 更新的軟件風(fēng)險分析l 可追溯性分析軟件要求設(shè)計規(guī)范（反之亦然）l 軟件設(shè)計評價l 設(shè)計通訊聯(lián)絡(luò)鏈接分析l 模塊測試計劃生成l 集

50、成測試計劃生成l 測試設(shè)計生成（模塊、集成、系統(tǒng)和接收）5.2.4 構(gòu)造或編碼軟件或者由編碼（即程序設(shè)計）或者由以前編碼的軟件組件（例如來自編碼庫、成品軟件等）組合在一起構(gòu)成用于新的應(yīng)用。在詳細的設(shè)計規(guī)范作為源編碼實現(xiàn)的地方編碼是軟件活動。編碼是軟件開發(fā)過程的最低級別的抽象。在模塊規(guī)范被轉(zhuǎn)換成程序設(shè)計語言的地方，編碼是分解軟件要求的最后階段。編碼通常包括高級程序設(shè)計語言的使用，但是對于臨界時間的操作也許需要使用匯編語言（或微編碼）。為用于目標(biāo)硬件平臺該源編碼可以或者是編譯的或者是翻譯的。選擇程序設(shè)計語言和軟件編譯工具（匯編程序、鏈接程序和編譯程序）的決策應(yīng)當(dāng)包括對隨后的質(zhì)量評價任務(wù)（例如所選擇

51、的語言的調(diào)試和測試工具的可用性）的影響的考慮。一些編譯程序為錯誤檢查提供可選擇的級別和指令來幫助調(diào)試編碼。不同的錯誤檢查級別也許在整個編碼過程中使用，來自編譯程序的警報或其它信息也許記錄也許沒有記錄。然而，在編碼和調(diào)試過程結(jié)束時，錯誤檢查的最嚴(yán)格級別通常用于對什么編碼錯誤仍留在軟件中備有證明文件。如果錯誤檢查的最嚴(yán)格級別不用于源編碼的最終譯碼，那么使用較少嚴(yán)格的譯碼錯誤檢查的正當(dāng)理由應(yīng)當(dāng)備有證明文件。同樣，對最終編碼，應(yīng)當(dāng)有編碼過程和其輸出的文件編制，包括來自編譯程序和它們的分辨率的任何警報或其它信息，或留下未解決問題的決策的正當(dāng)理由。管理系統(tǒng)的預(yù)報信息檢索頻繁地采用建立了有關(guān)軟件編碼過程的質(zhì)

52、量規(guī)則和規(guī)程的特定編碼指南。應(yīng)當(dāng)評價源編碼以驗證其符合特定的編碼指南。這種指南應(yīng)當(dāng)包括關(guān)于明確性、形式、復(fù)雜性管理和注釋的編碼約定。編碼注釋應(yīng)當(dāng)提供模塊的有用的和描述性的信息，包括預(yù)期輸入和輸出、變量參考、預(yù)期數(shù)據(jù)類型和要完成的操作。也應(yīng)當(dāng)評價源編碼以驗證其符合相應(yīng)的詳細設(shè)計規(guī)范。準(zhǔn)備集成和測試的模塊應(yīng)當(dāng)有符合編碼指南和任何其它適用的質(zhì)量規(guī)則和規(guī)程的文件編制。源編碼評價常常作為編碼檢查和編碼走查來執(zhí)行。這種靜態(tài)分析提供運行編碼指之前檢出錯誤的非常有效的方法。它們允許隔離中的每個錯誤的檢查，并也能幫助聚焦于稍后的軟件動態(tài)測試。管理系統(tǒng)的預(yù)報信息檢索可以使用具有適當(dāng)?shù)目刂茩C構(gòu)的手動（工作臺）檢查以

53、確保一致性和獨立性。應(yīng)當(dāng)擴充源編碼評價來驗證模塊和層（水平的和垂直的界面）之間的內(nèi)部連接，和符合它們的設(shè)計規(guī)范。使用的規(guī)程和源編碼評價結(jié)果的文件編制應(yīng)當(dāng)作為設(shè)計驗證的一部分來維護。源編碼可追溯性分析是驗證所有的編碼鏈接到已經(jīng)制定的規(guī)范和已經(jīng)制定的測試規(guī)程的重要工具。源編碼的可追溯性分析應(yīng)當(dāng)實施并備有證明文件以驗證：l 軟件設(shè)計規(guī)范的每個要素已經(jīng)在編碼中實現(xiàn)；l 在編碼中實現(xiàn)的模塊和功能可追溯到軟件設(shè)計規(guī)范和風(fēng)險分析中的要素；l 模塊和功能的測試可追溯到軟件設(shè)計規(guī)范和風(fēng)險分析中的要素；和l 模塊和功能測試可追溯到同一模塊和功能的源編碼。典型任務(wù)結(jié)構(gòu)或編碼l 可追溯性分析源編碼到設(shè)計規(guī)范（反之亦然）測試案例到源編碼和設(shè)計規(guī)范l 源編碼和源編碼文件編制的評價l 源編碼界面分析l 測試程序和測試案例生成（模塊、集成、系統(tǒng)和接收）5.2.5 軟件開發(fā)者的測試軟件測試需要在已知的條件下（能夠和軟件的預(yù)定義的預(yù)期相比較的規(guī)定的輸入和備有證明文件的輸出）運行軟件產(chǎn)品。這是耗時的、困難的、不完善的活動。同樣地，要求及早規(guī)劃以便有效果和效率。測試計劃和測試案例應(yīng)當(dāng)在軟件開發(fā)過程中合理可行的及早形成。 它們應(yīng)當(dāng)識別進度表、環(huán)境、資源（人員、工具等）、方法、案例（輸入、規(guī)程、輸出、預(yù)期結(jié)果）、文件編制和報告標(biāo)準(zhǔn)。在整個測試過程中應(yīng)用的