藺淑倩 郭小星 向嫄

摘要：核電DCS人機(jī)界面軟件是整個DCS系統(tǒng)的重要組成部分。人機(jī)界面的自主研發(fā)也是目前國內(nèi)核電行業(yè)的重要開發(fā)課題。該文在DOORS需求管理工具應(yīng)用基礎(chǔ)上，淺析需求管理在人機(jī)界面軟件自主研發(fā)過程中的應(yīng)用。

關(guān)鍵詞：RTM（requirement tracing matrix）；HMI（human-machine interface）；DCS

中圖分類號：TL362文獻(xiàn)標(biāo)識碼：A文章編號：1009-3044(2012)21-5097-03

Software Requirement Management on Human-machine Interface (HMI) Software for Nuclear Power Plant

LIN Shu-qian, GUO Xiao-xing, XIANG Yuan

(China Nuclear Control System Engineering Co., Ltd., Beijing 100176, China)

Abstract: The human-machine interface (HMI) is the most important part of the whole distribute control system. The development and research of HMI software is new point in newclear power plant area. Based on DOORS to manage and trace the HMI software require ment is expressed in this article .

Key words: RTM(requirement tracing matrix); HMI(human-machine interface); DCS

軟件需求管理是對軟件需求開發(fā)的管理，伴隨整個需求開發(fā)全過程、軟件生命周期全過程。需求管理的任務(wù)則是：尋求軟件開發(fā)的目標(biāo)與客戶就軟件項目的需求保持一致。軟件開發(fā)尤其是大型軟件或者多方合作開發(fā)軟件的開發(fā)周期較長，代碼量龐大、開發(fā)設(shè)計人員眾多，這無疑增加了軟件開發(fā)的難度。對于核電DCS(Distribute Control System)控制系統(tǒng)所需的二層人機(jī)界面軟件的開發(fā)，不僅要考慮界面中的人因因素，還要考慮軟件的實(shí)時性，可靠性和穩(wěn)定性。因此對人機(jī)界面軟件開發(fā)過程實(shí)施全面的軟件需求跟蹤管理具有非常重要的意義。

1核電人機(jī)界面軟件自主研發(fā)概述

核電DCS控制系統(tǒng)中的HMI軟件，又稱用戶交互界面，是核電站與操作員之間進(jìn)行操作交互和信息交換的媒介，是全廠DCS控制系統(tǒng)的重要組成部分。核電站DCS人機(jī)界面軟件主要用于監(jiān)視電廠系統(tǒng)參數(shù)、報警信息，并執(zhí)行正常運(yùn)行規(guī)程操作和事故應(yīng)急處理。它的主要功能包括：操作員流程圖顯示操作、報警顯示操作、趨勢曲線顯示操作、歷史數(shù)據(jù)集報警記錄、計算機(jī)化規(guī)程、二次計算、報表生成和打印等功能，詳見表1。

DCS二層人機(jī)界面軟件總體需要滿足以下要求：1）多屏顯示，支持多屏顯示并可根據(jù)區(qū)域不同（如主控室、遠(yuǎn)程停堆站、技術(shù)支持中心、掛牌中心等）靈活配置單屏、三屏、五屏顯示，且各屏顯示風(fēng)格及功能應(yīng)保持一致；2）實(shí)時性，包括界面切換、參數(shù)顯示刷新率、及操作員發(fā)出二層指令對0層設(shè)備的操作時間以及設(shè)備狀態(tài)反饋到二層界面顯示時間都需要滿足一定的時間限制以保證系統(tǒng)正常運(yùn)營。

2軟件需求管理工具介紹

軟件需求管理是一個長期繁復(fù)的任務(wù)，其中對于需求的載體-軟件需求規(guī)格說明書這類基于word文檔的存儲方法就有諸多局限性。例如：不易保證文檔的同步和更新；不易存儲每一條需求的屬性，添加日期或更改日期；不利于創(chuàng)建功能性需求與其他系統(tǒng)元素之間的鏈接等等。因此對于需求的管理勢必要引入一些管理工具來實(shí)現(xiàn)，同時也可以利用需求管理工具將需求的管理提高到更高的自動化管理層次。軟件需求管理工具的概括見表2。

這些商業(yè)工具之間的一個顯著差別就是以文檔為中心還是以數(shù)據(jù)庫為中心。以數(shù)據(jù)庫為中心的產(chǎn)品（比如：DOORS和Cali ber-RM）將全部需求、屬性和跟蹤信息存放在數(shù)據(jù)庫中，不同產(chǎn)品依賴的數(shù)據(jù)庫既可以是通用數(shù)據(jù)庫，也可以是專有數(shù)據(jù)庫；也可以是關(guān)系型或面向?qū)ο蟮臄?shù)據(jù)庫?？梢詮牟煌脑次臋n導(dǎo)入需求，但導(dǎo)入后都保存在數(shù)據(jù)庫中。然后將需求的文本描述標(biāo)注為一個所需的屬性。有些管理工具還可以將單個需求與外部文檔聯(lián)系起來，視為該需求的補(bǔ)充文檔以擴(kuò)充需求存儲庫中的內(nèi)容。

以文檔為中心的產(chǎn)品（例如：RMTrak、 RequisitePro）使用字處理程序（word或 FrameMaker）制作需求文檔。RequisitePro允許選擇

文檔作為離散需求存儲在數(shù)據(jù)庫中。只要將需求存入數(shù)據(jù)庫中，就可以像操作以數(shù)據(jù)庫為中心的工具一樣，將每個需求標(biāo)注相應(yīng)的屬性，且創(chuàng)建于其他系統(tǒng)需求或功能需求之間的關(guān)系鏈接。

在表2列出的產(chǎn)品中，除入門級的 QSSrequireit軟件，其余工具都價格不菲。但相對于需求管理的高成本現(xiàn)狀而言，投資購買一個價格合適的需求管理工具還是值當(dāng)?shù)摹?/p>

商業(yè)工具購入后，可以協(xié)助需求管理人員完成以下幾部分內(nèi)容：

1）管理版本和變更。項目導(dǎo)入管理工具后應(yīng)該及時定義需求基線?；€（Baseline）就是軟件成品要最終實(shí)現(xiàn)的需求集合。

2）存儲需求屬性。對每個需求都可以分配不同的屬性以方便管理。其中有部分需求管理工具自帶有一些系統(tǒng)定義好的屬性，用戶可以直接使用。例如：創(chuàng)建日期，創(chuàng)建人等。同時為了補(bǔ)充詳細(xì)說明每條需求，用戶可以自定義相關(guān)屬性，例如：系統(tǒng)需求，功能性需求等。

3）完成影響分析。導(dǎo)入需求文檔后，可以將每一條需求逐一建立與相關(guān)系統(tǒng)組件（比如：代碼模塊、詳細(xì)設(shè)計、測試用例）的鏈接，當(dāng)某一條需求變更或者是需求升版導(dǎo)致得需求變化時，用戶可以很方便的根據(jù)鏈接跟蹤到受影響的測試或是設(shè)計。

4）跟蹤需求完成狀態(tài)。將軟件開發(fā)的需求導(dǎo)入數(shù)據(jù)庫后，用戶可以很清楚的掌握全部離散需求的完成狀態(tài)，因此對整個項目開發(fā)進(jìn)度也是一目了然，既便于控制項目進(jìn)度，也便于控制時間成本。

5）權(quán)限管理。大部分需求管理工具都可以定義單個用戶權(quán)限和用戶組權(quán)限。為不同的項目開放不同的訪問權(quán)限，有利于項目的管理和人員配置。同時這些需求管理工具還可以通過數(shù)據(jù)庫的Web接口共同分享信息，便于地域分散的合作開發(fā)。

6）參與者之間的溝通。需求管理工具允許用戶用廣播在線信息和電子郵件的形式讓其他參與者了解當(dāng)前情況，或是討論具體需求的屬性更改、增加或刪除。

7）需求重用。需求一旦導(dǎo)入數(shù)據(jù)庫中，就會長期保存在數(shù)據(jù)庫。除非用戶清除該需求，否則數(shù)據(jù)庫的需求都可以自動恢復(fù)。并且需求歸檔還可以保存所有鏈接記錄和基線狀態(tài)。無論何時使用，只有有必要，可隨時引用任意需求。

3 HMI軟件需求管理活動

3.1 HMI軟件需求開發(fā)

軟件需求開發(fā)基本包括以下幾個步驟：獲取需求，分析需求、形成規(guī)格說明、最后是確認(rèn)需求。這些步驟的具體活動如下：1）確定軟件產(chǎn)品要面對哪類用戶。2）從各代表用戶處收集需求，了解用戶任務(wù)和必須實(shí)現(xiàn)的任務(wù)目標(biāo)。3）分析來自用戶處獲得的信息，區(qū)分出功能需求，業(yè)務(wù)規(guī)則、解決方案和性能要求。4）將需求分配到系統(tǒng)架構(gòu)內(nèi)定義好的軟件模塊中，并協(xié)商需求實(shí)現(xiàn)的優(yōu)先級。5）將用戶需求表述為需求規(guī)格說明，并獲取用戶的審核和認(rèn)可。

核電站HMI軟件的用戶群是核電站的操作員。HMI軟件作為操作員與核電站各系統(tǒng)間的橋梁，可以為操作員實(shí)時顯示各系統(tǒng)的安全參數(shù)，報警狀態(tài)和報警級別，全廠運(yùn)行概況以及電站正常運(yùn)行的總體規(guī)程和系統(tǒng)規(guī)程等。我公司HMI軟件需求開發(fā)過程也是從獲取需求開始。首先是調(diào)研，獲取需求，并匯總為立項報告；由專家組分析各個需求的重要級別和開發(fā)優(yōu)先級；研發(fā)項目組根據(jù)IEEE830標(biāo)準(zhǔn)撰寫《HMI軟件需求規(guī)格說明書》；遞交專家評審組對說明書進(jìn)行評審，專家組給出修改意見；研發(fā)項目組根據(jù)意見修改文檔，形成終版《HMI軟件需求規(guī)格說明書》。

HMI軟件需求規(guī)格說明書中詳細(xì)闡述了與軟件開發(fā)相關(guān)的系統(tǒng)接口、用戶接口、軟件接口、硬件接口、通訊接口，HMI各功能模塊的詳細(xì)需求、系統(tǒng)性能需求、數(shù)據(jù)需求和設(shè)計約束。

3.2 HMI軟件需求跟蹤

軟件需求跟蹤是需求管理的主要內(nèi)容，需求跟蹤要依賴于跟蹤鏈。通過跟蹤鏈可以向前或向后追蹤到需求和代碼實(shí)現(xiàn)。為了實(shí)現(xiàn)可跟蹤能力，每一個需求都應(yīng)該有且只有一個獨(dú)立的標(biāo)識號，并且在整個項目中要前后統(tǒng)一。這樣需求管理者可根據(jù)鏈接快速找到需求的設(shè)計狀態(tài)、實(shí)現(xiàn)情況以及是否測試通過。

需求跟蹤是一項需要進(jìn)行大量手工勞動的任務(wù)，因此有效的人員管理和權(quán)限設(shè)置非常重要。在軟件開發(fā)過程中要隨時更新需求的鏈接，為了避免不必要的誤動作，需求管理者應(yīng)該注意需求數(shù)據(jù)庫的歸檔和需求基線的設(shè)置。需求跟蹤結(jié)束后，需求管理者可以利用管理工具自動生產(chǎn)一份RTM（Requirement Tracing Matrix，需求跟蹤矩陣），如表3。

表3

根據(jù)IEEE 1012的標(biāo)準(zhǔn)和公司相關(guān)研發(fā)部相關(guān)要求，HMI軟件需求跟蹤活動只介入軟件研發(fā)的三個階段，包括需求階段、概要設(shè)計階段、詳細(xì)設(shè)計階段。其中跟蹤示意圖如圖1所示。

圖1

1）需求階段

需求階段則是把HMI軟件需求規(guī)格說明書和HMI軟件系統(tǒng)測試說明書導(dǎo)入DOORS，由需求跟蹤成員將系統(tǒng)測試用例與軟件需求鏈接起來。當(dāng)鏈接工作完成后，由DOORS自動導(dǎo)出需求階段的需求跟蹤矩陣，由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無效鏈接分析，并編制鏈接空白分析報告，將所有未跟蹤到源頭的系統(tǒng)測試用例匯總成空白分析表格，交由需求管理者存檔。

2）概要設(shè)計階段

概要設(shè)計階段則是把HMI軟件概要設(shè)計明書和HMI軟件集成測試說明書導(dǎo)入DOORS。由開發(fā)小組成員將HMI軟件概要設(shè)計與HMI軟件需求規(guī)格說明書進(jìn)行鏈接，需求跟蹤成員完成軟件集成測試用例與概要設(shè)計的鏈接。理想情況下，每個設(shè)計都應(yīng)當(dāng)對應(yīng)相關(guān)需求，每個概要設(shè)計都有對應(yīng)的測試用例去驗證。

同樣當(dāng)鏈接工作完成后，由DOORS自動導(dǎo)出概要設(shè)計階段的跟蹤矩陣，由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無效鏈接分析，并編制鏈接空白分析報告。將所有未跟蹤到對應(yīng)需求的軟件概要設(shè)計匯總成空白分析表格，交由需求管理者傳遞給開發(fā)小組；將集成測試用例和概要設(shè)計之間的空白鏈接匯總遞交給需求管理者處理。

3）詳細(xì)設(shè)計階段

詳細(xì)設(shè)計階段則是把HMI軟件詳細(xì)設(shè)計明書和HMI軟件單元測試說明書導(dǎo)入DOORS。由開發(fā)小組成員將HMI軟件詳細(xì)設(shè)計與HMI軟件概要設(shè)計進(jìn)行鏈接，需求跟蹤成員完成單元測試用例與詳細(xì)設(shè)計的鏈接。在鏈接工作完成后，由DOORS自動導(dǎo)出該階段的跟蹤矩陣，由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無效鏈接分析，并編制鏈接空白分析報告。其中將詳細(xì)設(shè)計與概要設(shè)計之間的空白鏈接匯總后交由需求管理者傳遞給開發(fā)小組解決；將單元測試用例與詳細(xì)設(shè)計之間的空白鏈接交由需求管理者處理。

上述三個階段結(jié)束后，需求跟蹤負(fù)責(zé)人將跟蹤情況匯總，由DOORS自動生產(chǎn)需求跟蹤矩陣。同時將需求跟蹤矩陣進(jìn)行分析，形成最終需求跟蹤分析報告，評估整個HMI軟件項目需求的可跟蹤性。

5結(jié)束語

該文給出了核電DCS二層人機(jī)界面軟件開發(fā)過程的需求跟蹤執(zhí)行流程，探索性的提出各研發(fā)階段的需求跟蹤任務(wù)和關(guān)鍵活動，為執(zhí)行其他行業(yè)的軟件需求管理提供參考。

參考文獻(xiàn)：

[1] Wiegers K E.軟件需求[M].2版.劉偉琴,劉洪濤,譯.北京:清華大學(xué)出版社,2004.

[2] Leffingwell D.軟件需求管理統(tǒng)一方法[M].蔣慧,林東,譯.北京:機(jī)械工業(yè)出版社,2002.

[3]向嫄.核電DCS中人機(jī)界面軟件的驗證與確認(rèn)的探索研究[J].電腦知識與技術(shù),2012,18(8).

[4]王志方,谷鵬飛,張建波.數(shù)字化人機(jī)界面設(shè)計的人因工程問題分析[J].核科學(xué)與工程,2010,30(4).

[5] USNRC NUREG-0700 Human System Interface Design Review Guide[S].Revision2,Washington,2004.

[6] 1012TM IEEE Standard for Software Verification and Validation[Z].Revision of IEEE Std,1012-2004.