吳 彬

（國(guó)核自儀系統(tǒng)工程有限公司，上海 200000）

0 引言

日本福島核事故發(fā)生后，全球?qū)穗姲踩筇岣撸鳛楹穗娬镜纳窠?jīng)系統(tǒng)，數(shù)字化儀控系統(tǒng)的設(shè)計(jì)、制造、調(diào)試、維護(hù)工作面臨了新的發(fā)展機(jī)遇和考驗(yàn)。在安全級(jí)和非安全級(jí)數(shù)字化儀控系統(tǒng)中，計(jì)算機(jī)軟件均高度集成了數(shù)據(jù)和算法，其質(zhì)量直接受制于開發(fā)體系和工程師的素質(zhì)。

數(shù)字化儀控系統(tǒng)由于安全性、可靠性非常高，如果軟件產(chǎn)生故障或帶有潛在的缺陷，將可能造成人身、財(cái)產(chǎn)安全的巨大損失。若軟件質(zhì)量不高，對(duì)業(yè)主來說維護(hù)費(fèi)用將十分龐大，并且維護(hù)工作的難度也會(huì)非常高。

AP1000非能動(dòng)壓水堆核電站中的安全相關(guān)軟件遵循美國(guó)聯(lián)邦法10CFR50附錄A“核電廠通用設(shè)計(jì)準(zhǔn)則”和附錄B“核電廠和燃料后處理工廠質(zhì)保準(zhǔn)則”中的要求。為了保證質(zhì)量，還引入軟件工程領(lǐng)域的眾多過程領(lǐng)域作為工作導(dǎo)則，例如需求管理、配置管理等。

1 軟件質(zhì)量評(píng)價(jià)與能力成熟度模型集成

IEEE對(duì)于軟件質(zhì)量的定義為：①系統(tǒng)、組件、過程滿足指定需求的程度；②系統(tǒng)、組件、過程滿足客戶或用戶需要或期望的程度。軟件質(zhì)量評(píng)價(jià)是一項(xiàng)系統(tǒng)活動(dòng)[1]，包括開發(fā)過程的評(píng)價(jià)、最終產(chǎn)品的評(píng)價(jià)、若干相似功能軟件的相互比較。軟件質(zhì)量評(píng)價(jià)的標(biāo)準(zhǔn)主要有ISO 9126“軟件工程產(chǎn)品質(zhì)量模型”和IEEE Std 1061“軟件質(zhì)量度量方法”。

圖1 軟件模型與IEEE過程域的聯(lián)系Fig.1 The connection of Software model and IEEE process area

ISO 9126采用6個(gè)軟件質(zhì)量特性：功能性、可靠性、易使用性、效率、維護(hù)性、可移植性。

功能性是與一組功能及其指定的性質(zhì)有關(guān)的一組屬性，這組屬性描述軟件滿足什么需求?？煽啃允桥c在規(guī)定的一段時(shí)間和條件下，軟件維持其性能水平的能力有關(guān)的一組屬性，可靠性是由于軟件需求、設(shè)計(jì)、實(shí)現(xiàn)中的缺陷所致。

根據(jù)以上6個(gè)質(zhì)量特性，可以再進(jìn)行子特性的細(xì)分，如可以將可靠性細(xì)分為成熟性、容錯(cuò)能力、故障恢復(fù)性等。每一個(gè)子特性都和一個(gè)質(zhì)量特性所對(duì)應(yīng)，其特定組合反映了某一軟件質(zhì)量特性。對(duì)于特性和子特性，應(yīng)設(shè)置度量單元，用于在開發(fā)過程中評(píng)估和預(yù)測(cè)軟件質(zhì)量。度量單元是一些具體的問題，被用于開發(fā)過程中評(píng)估和預(yù)測(cè)軟件的質(zhì)量，對(duì)這些問題的答案進(jìn)行計(jì)分，可以反映出質(zhì)量子特性與特性的得分。

例如，對(duì)于控制軟件中的控制邏輯來說，功能性可以采用白盒測(cè)試進(jìn)行驗(yàn)證，在其中可以運(yùn)行各種測(cè)試用例，對(duì)邏輯中的條件覆蓋、分支覆蓋、語句（簡(jiǎn)單邏輯）覆蓋進(jìn)行檢查。測(cè)試的統(tǒng)計(jì)結(jié)果以覆蓋率百分?jǐn)?shù)的形式進(jìn)行記錄，對(duì)覆蓋率進(jìn)行等級(jí)劃分，可以確定相應(yīng)的評(píng)價(jià)級(jí)別。

對(duì)于儀控軟件開發(fā)和維護(hù)組織而言，軟件質(zhì)量評(píng)價(jià)的結(jié)果往往取決于組織的能力成熟度?？▋?nèi)基·梅隆大學(xué)軟件工程研究所給出了能力成熟度模型集成（CMMI）的框架，描述了有效的軟件過程的關(guān)鍵元素，給出了軟件開發(fā)和維護(hù)組織從不成熟的開發(fā)過程向成熟規(guī)范的開發(fā)過程上升的通道，覆蓋了軟件開發(fā)維護(hù)相關(guān)的策劃、工程、管理實(shí)踐。核電儀控企業(yè)可參考CMMI中的過程域，對(duì)標(biāo)IEEE相關(guān)標(biāo)準(zhǔn)，制定和修改軟件開發(fā)和維護(hù)過程。

2 需求開發(fā)與管理

2.1 概述

從監(jiān)管的角度，美國(guó)NRC導(dǎo)則RG 1.173-1997“核電廠安全系統(tǒng)中使用的數(shù)字計(jì)算機(jī)軟件的軟件壽命周期過程開發(fā)”中背書了IEEE Std 1074-1995“開發(fā)軟件生命周期過程”[2]，在標(biāo)準(zhǔn)的5.1節(jié)描述了需求過程。從質(zhì)保的角度，ASME NQA-1-2004中對(duì)軟件開發(fā)過程進(jìn)行了描述，即要求3的801部分。其中，規(guī)定的軟件設(shè)計(jì)需求的識(shí)別、軟件設(shè)計(jì)、軟件設(shè)計(jì)的實(shí)現(xiàn)、軟件設(shè)計(jì)驗(yàn)證、計(jì)算機(jī)程序測(cè)試過程涵蓋了需求開發(fā)和管理的內(nèi)容。

2.2 需求開發(fā)活動(dòng)

核電儀控項(xiàng)目中需求開發(fā)過程的目的是產(chǎn)出并分析業(yè)主、交付物及其組件的需求，用來表達(dá)相關(guān)方的需要，包括與儀控系統(tǒng)生命周期各階段及產(chǎn)品屬性有關(guān)的需要，也包括選擇某設(shè)計(jì)解決方案而產(chǎn)生的限制條件。

需求開發(fā)的過程是循環(huán)迭代的，結(jié)合IEEE Std 1233-1996[3]的定義，儀控軟件需求開發(fā)的4個(gè)子過程包括：從輸入資料、業(yè)主/設(shè)計(jì)院/其它相關(guān)方的技術(shù)團(tuán)隊(duì)處識(shí)別需求；創(chuàng)建形式良好的需求；組織需求，進(jìn)行結(jié)構(gòu)化調(diào)整，寫入軟件需求規(guī)范書；將軟件需求規(guī)范書以不同的表達(dá)形式展示給各相關(guān)方。結(jié)合軟件需求規(guī)范，對(duì)軟件架構(gòu)更細(xì)層次不斷分析，直到可以獲得足夠的細(xì)節(jié)進(jìn)行詳細(xì)設(shè)計(jì)和測(cè)試。儀控EPC項(xiàng)目中會(huì)存在產(chǎn)生多層子系統(tǒng)需求的情況，但無論規(guī)模大小，需求都應(yīng)當(dāng)分解到最小的可實(shí)現(xiàn)單元。對(duì)于項(xiàng)目的軟件部分，最小的可實(shí)現(xiàn)單元為計(jì)算機(jī)軟件配置項(xiàng)。在此過程中，軟件開發(fā)組織還應(yīng)當(dāng)定義功能和實(shí)體之間的接口。

2.3 需求管理活動(dòng)

需求管理過程的目的是在項(xiàng)目啟動(dòng)后，在設(shè)計(jì)活動(dòng)開始前和執(zhí)行中，通過結(jié)構(gòu)化的過程定義，保證能識(shí)別出所有需求，以此保證客戶需求得以實(shí)現(xiàn)，減少或消除返工，避免在測(cè)試階段變更系統(tǒng)配置。作為一個(gè)迭代過程，需求管理要求軟件開發(fā)和維護(hù)組織具備系統(tǒng)工程的實(shí)踐能力。

需求管理過程應(yīng)根據(jù)項(xiàng)目規(guī)模確定活動(dòng)粒度，可以通過兩種維度進(jìn)行度量：需求分解的層次，為完成某項(xiàng)功能指派的人員數(shù)。

需求管理包括需求追溯、需求變更控制、界定項(xiàng)目工作與需求間的差異。通過維護(hù)需求追溯性，可以建立原始需求和衍生需求之間雙向的追溯性，也可以涵蓋需求和設(shè)計(jì)、測(cè)試、最終產(chǎn)品等實(shí)體之間的追溯性。需求追溯可以采用需求追溯表和需求追蹤系統(tǒng)的途徑來實(shí)現(xiàn)。

需求變更作為一種重要的變更形式，在軟件開發(fā)過程中十分常見，但若處理不當(dāng)，容易造成軟件設(shè)計(jì)缺陷、項(xiàng)目延期、超支等后果。因此，需求變更應(yīng)符合變更控制的要求。

3 配置管理

3.1 概述

在ASME NQA-1-2004要求3設(shè)計(jì)控制的802部分，詳細(xì)描述了軟件配置管理過程，對(duì)配置管理活動(dòng)提出了相關(guān)要求。配置管理過程體現(xiàn)了PDCA全面質(zhì)量管理的精髓，從計(jì)劃、執(zhí)行到檢查、處理，再回到計(jì)劃，通過螺旋式的逐步改進(jìn)提升，使整個(gè)項(xiàng)目質(zhì)量能夠達(dá)到預(yù)期目標(biāo)并維持在較高水準(zhǔn)。

3.2 配置管理活動(dòng)

根據(jù)IEEE Std 828-2005[4]，軟件配置管理計(jì)劃中需要涵蓋配置管理所執(zhí)行的活動(dòng)，主要包括配置標(biāo)識(shí)、配置控制、配置狀態(tài)記錄、配置審計(jì)、接口控制、供應(yīng)商控制以及釋放的管理和交付。配置管理與需求管理、文件控制有著緊密的聯(lián)系，但彼此又有區(qū)別。在軟件產(chǎn)品向前演進(jìn)的過程中，三者的關(guān)系能夠明確地體現(xiàn)出來。

3.2.1 配置標(biāo)識(shí)

配置標(biāo)識(shí)是軟件配置管理的基礎(chǔ)性工作，是優(yōu)化配置的前提。配置標(biāo)識(shí)目的是要識(shí)別項(xiàng)目中的所有配置項(xiàng)（Configuration Item），配置項(xiàng)包括但不限于軟件、軟件文檔以及與軟件集成的硬件，對(duì)識(shí)別出的配置項(xiàng)進(jìn)行命名以便及時(shí)準(zhǔn)確地獲取某個(gè)狀態(tài)下軟件的配置。如果配置標(biāo)識(shí)不合理，基線（Baseline）管理將難以操作，隨之而來的版本控制和變更控制也將成為棘手的問題。

3.2.2 配置控制

配置控制是配置管理活動(dòng)日常管理的重點(diǎn)，而變更管理又是配置控制的關(guān)鍵。變更可能在項(xiàng)目任何階段發(fā)生，并且任何項(xiàng)目成員都可能成為變更的發(fā)起者。因此，對(duì)于變更控制組織必須建立一套有效方案來加以控制。手段可包括制定變更程序，成立變更管理委員會(huì)，委派專員采用變更管理軟件對(duì)變更進(jìn)行管理。

變更可能會(huì)牽涉多個(gè)專業(yè)領(lǐng)域，如必要，需對(duì)受影響的各專業(yè)領(lǐng)域進(jìn)行評(píng)估，方能確定變更的范圍。對(duì)變更的結(jié)論進(jìn)行決議時(shí)，可根據(jù)變更影響范圍、優(yōu)先級(jí)程度，結(jié)合開發(fā)組織結(jié)構(gòu)特點(diǎn)來決定。當(dāng)決議生效后，變更內(nèi)容需要以文檔的形式記錄。變更文檔需經(jīng)過軟件開發(fā)組織的審查，確保變更內(nèi)容正確無誤可以實(shí)施。

3.2.3 配置狀態(tài)記錄

配置狀態(tài)記錄反應(yīng)配置項(xiàng)的狀態(tài)，特別在形成基線或釋放（Release）時(shí)，可確保軟件開發(fā)組織成員及時(shí)獲知配置項(xiàng)的最新狀態(tài)，避免產(chǎn)生不適當(dāng)?shù)能浖种Ш蜌w并。

3.2.4 配置審計(jì)

配置審計(jì)是對(duì)配置管理執(zhí)行情況的檢查，執(zhí)行一般為軟件質(zhì)量保證人員（SQA）。SQA對(duì)當(dāng)時(shí)軟件配置的質(zhì)量情況與質(zhì)量改進(jìn)建議負(fù)責(zé)。項(xiàng)目對(duì)于審計(jì)出的不符合項(xiàng)應(yīng)分析原因，識(shí)別職責(zé)，避免相同質(zhì)量問題在本項(xiàng)目或其他項(xiàng)目的再次發(fā)生。

3.2.5 接口控制

接口控制主要反映配置項(xiàng)之間的聯(lián)系，某配置項(xiàng)的變更會(huì)引發(fā)其他配置項(xiàng)的改變，這類配置項(xiàng)在配置管理計(jì)劃中應(yīng)加以標(biāo)識(shí)。

3.2.6 供應(yīng)商控制

供應(yīng)商提供的配置項(xiàng)一般不列入項(xiàng)目本身直接管理的范圍。對(duì)于這些配置項(xiàng)，需評(píng)估供應(yīng)商對(duì)其進(jìn)行配置管理的計(jì)劃以及執(zhí)行的結(jié)果，經(jīng)開發(fā)組織確認(rèn)的外來配置項(xiàng)才會(huì)被納入配置管理中。供應(yīng)商配置項(xiàng)變更也需符合3.2.2的變更控制。

3.2.7 釋放管理與交付

釋放管理與交付關(guān)注軟件代碼、目標(biāo)碼、二進(jìn)制文件和軟件文檔。對(duì)于那些涉及安全的關(guān)鍵性功能需保存所有記錄，保證釋放或交付的產(chǎn)品正確可靠。

4 文件控制

4.1 概述

在ASME NQA-1-2004的要求6中，定義了文件控制：“確定質(zhì)量要求或規(guī)定影響質(zhì)量活動(dòng)的文件，如細(xì)則、程序、圖紙等，它的形成、發(fā)放和變更都應(yīng)予以控制，以保證使用正確的文件。如該文件需變更，應(yīng)審查其合適性，并由授權(quán)的人批準(zhǔn)后發(fā)布。”

針對(duì)軟件，文件控制會(huì)貫穿其生命周期各階段，全面記錄了軟件需求、軟件設(shè)計(jì)、軟件實(shí)現(xiàn)、軟件測(cè)試、發(fā)布軟件產(chǎn)品、運(yùn)行維護(hù)等過程。在軟件開發(fā)組織的質(zhì)量體系框架內(nèi)，文件控制的策略和具體措施很大程度影響了核電儀控軟件的質(zhì)量。各公司對(duì)文件控制的方法不盡相同，建立一套符合自身實(shí)際狀況的文控流程才能保障項(xiàng)目有效推進(jìn)。結(jié)合NQA-1-2004以及ISO 9001-2008提煉出以下要求，這些要求不僅適用于軟件文檔：

1）文件發(fā)布前需得到批準(zhǔn)，以確保文件充分且適宜。

2）必要時(shí)對(duì)文件進(jìn)行評(píng)審與更新，并再次批準(zhǔn)。

3）確保文件的更改和現(xiàn)行修訂狀態(tài)得到識(shí)別。

4）確保在使用處可獲得適用文件的有關(guān)版本。

5）確保文件保持清晰、易于識(shí)別。

6）確保策劃和運(yùn)作質(zhì)量管理體系所需的外來文件得到識(shí)別，并控制其分發(fā)。

7）防止作廢文件的非預(yù)期使用，若因任何原因而保留作廢文件時(shí)，對(duì)這些文件進(jìn)行適當(dāng)?shù)臉?biāo)識(shí)。

4.2 軟件文檔

在項(xiàng)目啟動(dòng)前，組織根據(jù)客戶要求和軟件產(chǎn)品需求構(gòu)劃軟件文檔類型，主要包括軟件質(zhì)量計(jì)劃、軟件需求文件、軟件設(shè)計(jì)與實(shí)現(xiàn)文件、軟件驗(yàn)證和確認(rèn)文件、用戶文件。具體的軟件文檔范圍和分類定義可參考GB/T 8567-2006《計(jì)算機(jī)軟件文檔編制規(guī)范》，與軟件文檔相關(guān)的其它技術(shù)文件包括但不限于各類圖紙、軟件設(shè)計(jì)文件等。這些文件之間彼此相互依賴，相互聯(lián)系，保證軟件產(chǎn)品能夠符合原始需求且具有傳遞性。

軟件文檔的編制可依據(jù)模板規(guī)范文件內(nèi)容形式，對(duì)于軟件設(shè)計(jì)文件和記錄不但應(yīng)包括最終設(shè)計(jì)文件，如圖紙、規(guī)范書及其相關(guān)修訂，還應(yīng)包括確定設(shè)計(jì)過程重要步驟的文件，如支持最終設(shè)計(jì)的初始輸入資料。

4.3 文件的形成、發(fā)放與變更

4.3.1 文件形成

為保證儀控軟件文檔的合規(guī)性、正確性、完整性和可用性，正式的軟件文檔，與之相關(guān)的其它技術(shù)文件應(yīng)經(jīng)過編制、校核、審核和批準(zhǔn)等步驟。

文控人員在文件編制過程中，有必要追蹤文件當(dāng)前狀況，記錄編制、校核、審核和批準(zhǔn)的開始和完成時(shí)間，以跟蹤計(jì)劃進(jìn)度的完成情況。

4.3.2 文件發(fā)放

文件在經(jīng)過批準(zhǔn)后，軟件開發(fā)組織負(fù)責(zé)對(duì)文件執(zhí)行保密性評(píng)定并進(jìn)行歸檔入庫，并由專門的檔案管理人員妥善保存檔案原件。軟件開發(fā)組織成員可通過一種或多種途徑獲取已發(fā)布文件的信息，并且符合公司文件控制流程。

已失效的文件由檔案管理人員及時(shí)回收，統(tǒng)一存放管理，以保證不被誤用。對(duì)于無必要保留的作廢文件，執(zhí)行銷毀處理，保證文件內(nèi)容無法還原。

4.3.3 文件變更

文件的變更參考配置控制的要求和控制手段進(jìn)行，可見3.2.2節(jié)。

5 實(shí)例

圖2以核電廠控制系統(tǒng)中的化學(xué)與容積控制系統(tǒng)（CVS）由輸入工藝系統(tǒng)文件升版導(dǎo)致的變更為例，描述和分析了儀控系統(tǒng)軟件設(shè)計(jì)由需求管理、配置管理、實(shí)施至文件控制的流程。

5.1 輸入文件升版

在控制軟件詳細(xì)設(shè)計(jì)階段，軟件開發(fā)組織接收到新版的CVS系統(tǒng)規(guī)格書，其中修改增加了電廠水實(shí)體模式下CVS系統(tǒng)的控制策略。由于控制軟件的功能需求來自于工藝系統(tǒng)規(guī)格書，因而輸入文件的升版將直接影響需求。

5.2 對(duì)比需求基線，統(tǒng)計(jì)差異

通過與需求基線中CVS系統(tǒng)部分進(jìn)行對(duì)比，發(fā)現(xiàn)新版CVS系統(tǒng)規(guī)格書主要影響了水實(shí)體模式下CVS補(bǔ)水泵的控制邏輯需求。

5.3 輸入基線變更

配置控制委員會(huì)（Configuration Control Board，簡(jiǎn)稱CCB）將新版CVS需求規(guī)格書加入輸入基線，替代原版文件。

5.4 提出需求變更建議

圖2 CVS軟件開發(fā)管理Fig.2 CVS software development manage

負(fù)責(zé)控制軟件需求開發(fā)的工程師針對(duì)CVS系統(tǒng)規(guī)格書中的變化提出名為“CVS水實(shí)體模式控制策略變更”的需求變更建議，進(jìn)入變更管理過程。在此過程中，變更的初步影響范圍（對(duì)系統(tǒng)架構(gòu)、硬件I/O分配、軟件設(shè)計(jì)、測(cè)試）、變更等級(jí)、原因及依據(jù)等信息被識(shí)別。根據(jù)變更等級(jí)的不同，相應(yīng)的責(zé)任人需確認(rèn)變更信息完整性和正確性，變更正式建立。

5.5 評(píng)審變更，分解變更任務(wù)

配置管理員在總結(jié)變更信息后，分發(fā)相關(guān)專業(yè)組織進(jìn)行詳細(xì)評(píng)估。特別地，負(fù)責(zé)CVS軟件設(shè)計(jì)和測(cè)試的組織將對(duì)受影響的軟件組件、單元進(jìn)行分析，識(shí)別受影響的控制邏輯、畫面顯示等，并明確受影響的程度，提出同意/否決該變更的意見，反饋給配置管理員。配置管理員在集齊所有專業(yè)組對(duì)變更的評(píng)估后，組織CCB會(huì)議。在此會(huì)議中，CCB成員將根據(jù)影響范圍、成本、進(jìn)度等方面進(jìn)行綜合評(píng)估，并對(duì)變更進(jìn)行決議。在此例中，CCB會(huì)議通過了CVS水實(shí)體模式控制需求的變更，將根據(jù)新版CVS系統(tǒng)規(guī)格書更新需求基線。

5.6 修改CVS功能需求

需求開發(fā)人員負(fù)責(zé)根據(jù)新版規(guī)格書提出與之符合的控制功能需求。

5.7 確立新CVS系統(tǒng)需求基線

需求管理員根據(jù)變更評(píng)審過程中提出的評(píng)估意見，聯(lián)合架構(gòu)設(shè)計(jì)工程師、硬件工程師、軟件工程師對(duì)需求進(jìn)行分解，保證增加、修改的需求分配到特定的配置項(xiàng)，同時(shí)確保刪除的需求從配置項(xiàng)需求中除去。

5.8 發(fā)布升版后的需求文件

文件控制人員發(fā)布升版的需求文件。

5.9 變更分解任務(wù)執(zhí)行完成，關(guān)閉變更

配置管理員在變更過程中，保持對(duì)變更狀態(tài)的跟蹤，并在所有變更分解任務(wù)完成后，關(guān)閉變更。

5.10 發(fā)布變更文件

文件控制人員發(fā)布變更文件，此文件記錄了此次變更中涉及的所有內(nèi)容，包括原因、過程、結(jié)果。CVS水實(shí)體模式控制策略變更全部完成，其理由充分、過程完整、結(jié)果正確，從需求到設(shè)計(jì)、需求到測(cè)試具備可追溯性，在保證高效完成任務(wù)的同時(shí)，為產(chǎn)品的優(yōu)良質(zhì)量打下了堅(jiān)實(shí)的基礎(chǔ)。

5.11 CVS控制邏輯與畫面設(shè)計(jì)

負(fù)責(zé)CVS系統(tǒng)的控制軟件工程師依據(jù)重新分配后的軟件需求，對(duì)現(xiàn)有邏輯與畫面設(shè)計(jì)實(shí)現(xiàn)進(jìn)行修改，維護(hù)需求追溯關(guān)系，以證明更新后的軟件設(shè)計(jì)實(shí)現(xiàn)可以滿足新需求基線。

5.12 發(fā)布升版后的設(shè)計(jì)文件

軟件工程師應(yīng)保證提交的設(shè)計(jì)文件真實(shí)完整地記錄了軟件的設(shè)計(jì)實(shí)現(xiàn)過程和結(jié)果，文件控制人員發(fā)布升版的設(shè)計(jì)文件。

5.13 修改測(cè)試規(guī)程重新執(zhí)行測(cè)試

軟件測(cè)試人員根據(jù)新需求基線設(shè)計(jì)CVS測(cè)試規(guī)程，并對(duì)新CVS邏輯與畫面重新執(zhí)行測(cè)試。實(shí)際執(zhí)行過程中，軟件測(cè)試和設(shè)計(jì)是一個(gè)迭代的過程，迭代的出口是軟件質(zhì)量評(píng)價(jià)結(jié)果符合業(yè)主和設(shè)計(jì)院提出的要求。

5.14 發(fā)布升版后的測(cè)試文件

文件控制人員發(fā)布升版的測(cè)試規(guī)程，以及相應(yīng)的測(cè)試報(bào)告。

6 結(jié)束語

在開展需求開發(fā)和管理、配置管理和文件控制的研究基礎(chǔ)上，核電儀控軟件開發(fā)組織根據(jù)自身的能力水平采取針對(duì)性的措施，將有力地支持軟件開發(fā)過程。開發(fā)過程中，開發(fā)組織若能夠及時(shí)對(duì)軟件質(zhì)量進(jìn)行評(píng)價(jià)，反饋并解決遺留的問題，將持續(xù)提升儀控軟件質(zhì)量和開發(fā)組織的能力。