藺淑倩 郭小星 向嫄
摘要:核電DCS人機(jī)界面軟件是整個(gè)DCS系統(tǒng)的重要組成部分。人機(jī)界面的自主研發(fā)也是目前國(guó)內(nèi)核電行業(yè)的重要開(kāi)發(fā)課題。該文在DOORS需求管理工具應(yīng)用基礎(chǔ)上,淺析需求管理在人機(jī)界面軟件自主研發(fā)過(guò)程中的應(yīng)用。
關(guān)鍵詞:RTM(requirement tracing matrix);HMI(human-machine interface);DCS
中圖分類號(hào):TL362文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):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
軟件需求管理是對(duì)軟件需求開(kāi)發(fā)的管理,伴隨整個(gè)需求開(kāi)發(fā)全過(guò)程、軟件生命周期全過(guò)程。需求管理的任務(wù)則是:尋求軟件開(kāi)發(fā)的目標(biāo)與客戶就軟件項(xiàng)目的需求保持一致。軟件開(kāi)發(fā)尤其是大型軟件或者多方合作開(kāi)發(fā)軟件的開(kāi)發(fā)周期較長(zhǎng),代碼量龐大、開(kāi)發(fā)設(shè)計(jì)人員眾多,這無(wú)疑增加了軟件開(kāi)發(fā)的難度。對(duì)于核電DCS(Distribute Control System)控制系統(tǒng)所需的二層人機(jī)界面軟件的開(kāi)發(fā),不僅要考慮界面中的人因因素,還要考慮軟件的實(shí)時(shí)性,可靠性和穩(wěn)定性。因此對(duì)人機(jī)界面軟件開(kāi)發(fā)過(guò)程實(shí)施全面的軟件需求跟蹤管理具有非常重要的意義。
1核電人機(jī)界面軟件自主研發(fā)概述
核電DCS控制系統(tǒng)中的HMI軟件,又稱用戶交互界面,是核電站與操作員之間進(jìn)行操作交互和信息交換的媒介,是全廠DCS控制系統(tǒng)的重要組成部分。核電站DCS人機(jī)界面軟件主要用于監(jiān)視電廠系統(tǒng)參數(shù)、報(bào)警信息,并執(zhí)行正常運(yùn)行規(guī)程操作和事故應(yīng)急處理。它的主要功能包括:操作員流程圖顯示操作、報(bào)警顯示操作、趨勢(shì)曲線顯示操作、歷史數(shù)據(jù)集報(bào)警記錄、計(jì)算機(jī)化規(guī)程、二次計(jì)算、報(bào)表生成和打印等功能,詳見(jiàn)表1。
DCS二層人機(jī)界面軟件總體需要滿足以下要求:1)多屏顯示,支持多屏顯示并可根據(jù)區(qū)域不同(如主控室、遠(yuǎn)程停堆站、技術(shù)支持中心、掛牌中心等)靈活配置單屏、三屏、五屏顯示,且各屏顯示風(fēng)格及功能應(yīng)保持一致;2)實(shí)時(shí)性,包括界面切換、參數(shù)顯示刷新率、及操作員發(fā)出二層指令對(duì)0層設(shè)備的操作時(shí)間以及設(shè)備狀態(tài)反饋到二層界面顯示時(shí)間都需要滿足一定的時(shí)間限制以保證系統(tǒng)正常運(yùn)營(yíng)。
2軟件需求管理工具介紹
軟件需求管理是一個(gè)長(zhǎng)期繁復(fù)的任務(wù),其中對(duì)于需求的載體-軟件需求規(guī)格說(shuō)明書這類基于word文檔的存儲(chǔ)方法就有諸多局限性。例如:不易保證文檔的同步和更新;不易存儲(chǔ)每一條需求的屬性,添加日期或更改日期;不利于創(chuàng)建功能性需求與其他系統(tǒng)元素之間的鏈接等等。因此對(duì)于需求的管理勢(shì)必要引入一些管理工具來(lái)實(shí)現(xiàn),同時(shí)也可以利用需求管理工具將需求的管理提高到更高的自動(dòng)化管理層次。軟件需求管理工具的概括見(jiàn)表2。
這些商業(yè)工具之間的一個(gè)顯著差別就是以文檔為中心還是以數(shù)據(jù)庫(kù)為中心。以數(shù)據(jù)庫(kù)為中心的產(chǎn)品(比如:DOORS和Cali ber-RM)將全部需求、屬性和跟蹤信息存放在數(shù)據(jù)庫(kù)中,不同產(chǎn)品依賴的數(shù)據(jù)庫(kù)既可以是通用數(shù)據(jù)庫(kù),也可以是專有數(shù)據(jù)庫(kù);也可以是關(guān)系型或面向?qū)ο蟮臄?shù)據(jù)庫(kù)??梢詮牟煌脑次臋n導(dǎo)入需求,但導(dǎo)入后都保存在數(shù)據(jù)庫(kù)中。然后將需求的文本描述標(biāo)注為一個(gè)所需的屬性。有些管理工具還可以將單個(gè)需求與外部文檔聯(lián)系起來(lái),視為該需求的補(bǔ)充文檔以擴(kuò)充需求存儲(chǔ)庫(kù)中的內(nèi)容。
以文檔為中心的產(chǎn)品(例如:RMTrak、 RequisitePro)使用字處理程序(word或 FrameMaker)制作需求文檔。RequisitePro允許選擇
文檔作為離散需求存儲(chǔ)在數(shù)據(jù)庫(kù)中。只要將需求存入數(shù)據(jù)庫(kù)中,就可以像操作以數(shù)據(jù)庫(kù)為中心的工具一樣,將每個(gè)需求標(biāo)注相應(yīng)的屬性,且創(chuàng)建于其他系統(tǒng)需求或功能需求之間的關(guān)系鏈接。
在表2列出的產(chǎn)品中,除入門級(jí)的 QSSrequireit軟件,其余工具都價(jià)格不菲。但相對(duì)于需求管理的高成本現(xiàn)狀而言,投資購(gòu)買一個(gè)價(jià)格合適的需求管理工具還是值當(dāng)?shù)摹?/p>
商業(yè)工具購(gòu)入后,可以協(xié)助需求管理人員完成以下幾部分內(nèi)容:
1)管理版本和變更。項(xiàng)目導(dǎo)入管理工具后應(yīng)該及時(shí)定義需求基線?;€(Baseline)就是軟件成品要最終實(shí)現(xiàn)的需求集合。
2)存儲(chǔ)需求屬性。對(duì)每個(gè)需求都可以分配不同的屬性以方便管理。其中有部分需求管理工具自帶有一些系統(tǒng)定義好的屬性,用戶可以直接使用。例如:創(chuàng)建日期,創(chuàng)建人等。同時(shí)為了補(bǔ)充詳細(xì)說(shuō)明每條需求,用戶可以自定義相關(guān)屬性,例如:系統(tǒng)需求,功能性需求等。
3)完成影響分析。導(dǎo)入需求文檔后,可以將每一條需求逐一建立與相關(guān)系統(tǒng)組件(比如:代碼模塊、詳細(xì)設(shè)計(jì)、測(cè)試用例)的鏈接,當(dāng)某一條需求變更或者是需求升版導(dǎo)致得需求變化時(shí),用戶可以很方便的根據(jù)鏈接跟蹤到受影響的測(cè)試或是設(shè)計(jì)。
4)跟蹤需求完成狀態(tài)。將軟件開(kāi)發(fā)的需求導(dǎo)入數(shù)據(jù)庫(kù)后,用戶可以很清楚的掌握全部離散需求的完成狀態(tài),因此對(duì)整個(gè)項(xiàng)目開(kāi)發(fā)進(jìn)度也是一目了然,既便于控制項(xiàng)目進(jìn)度,也便于控制時(shí)間成本。
5)權(quán)限管理。大部分需求管理工具都可以定義單個(gè)用戶權(quán)限和用戶組權(quán)限。為不同的項(xiàng)目開(kāi)放不同的訪問(wèn)權(quán)限,有利于項(xiàng)目的管理和人員配置。同時(shí)這些需求管理工具還可以通過(guò)數(shù)據(jù)庫(kù)的Web接口共同分享信息,便于地域分散的合作開(kāi)發(fā)。
6)參與者之間的溝通。需求管理工具允許用戶用廣播在線信息和電子郵件的形式讓其他參與者了解當(dāng)前情況,或是討論具體需求的屬性更改、增加或刪除。
7)需求重用。需求一旦導(dǎo)入數(shù)據(jù)庫(kù)中,就會(huì)長(zhǎng)期保存在數(shù)據(jù)庫(kù)。除非用戶清除該需求,否則數(shù)據(jù)庫(kù)的需求都可以自動(dòng)恢復(fù)。并且需求歸檔還可以保存所有鏈接記錄和基線狀態(tài)。無(wú)論何時(shí)使用,只有有必要,可隨時(shí)引用任意需求。
3 HMI軟件需求管理活動(dòng)
3.1 HMI軟件需求開(kāi)發(fā)
軟件需求開(kāi)發(fā)基本包括以下幾個(gè)步驟:獲取需求,分析需求、形成規(guī)格說(shuō)明、最后是確認(rèn)需求。這些步驟的具體活動(dòng)如下:1)確定軟件產(chǎn)品要面對(duì)哪類用戶。2)從各代表用戶處收集需求,了解用戶任務(wù)和必須實(shí)現(xiàn)的任務(wù)目標(biāo)。3)分析來(lái)自用戶處獲得的信息,區(qū)分出功能需求,業(yè)務(wù)規(guī)則、解決方案和性能要求。4)將需求分配到系統(tǒng)架構(gòu)內(nèi)定義好的軟件模塊中,并協(xié)商需求實(shí)現(xiàn)的優(yōu)先級(jí)。5)將用戶需求表述為需求規(guī)格說(shuō)明,并獲取用戶的審核和認(rèn)可。
核電站HMI軟件的用戶群是核電站的操作員。HMI軟件作為操作員與核電站各系統(tǒng)間的橋梁,可以為操作員實(shí)時(shí)顯示各系統(tǒng)的安全參數(shù),報(bào)警狀態(tài)和報(bào)警級(jí)別,全廠運(yùn)行概況以及電站正常運(yùn)行的總體規(guī)程和系統(tǒng)規(guī)程等。我公司HMI軟件需求開(kāi)發(fā)過(guò)程也是從獲取需求開(kāi)始。首先是調(diào)研,獲取需求,并匯總為立項(xiàng)報(bào)告;由專家組分析各個(gè)需求的重要級(jí)別和開(kāi)發(fā)優(yōu)先級(jí);研發(fā)項(xiàng)目組根據(jù)IEEE830標(biāo)準(zhǔn)撰寫《HMI軟件需求規(guī)格說(shuō)明書》;遞交專家評(píng)審組對(duì)說(shuō)明書進(jìn)行評(píng)審,專家組給出修改意見(jiàn);研發(fā)項(xiàng)目組根據(jù)意見(jiàn)修改文檔,形成終版《HMI軟件需求規(guī)格說(shuō)明書》。
HMI軟件需求規(guī)格說(shuō)明書中詳細(xì)闡述了與軟件開(kāi)發(fā)相關(guān)的系統(tǒng)接口、用戶接口、軟件接口、硬件接口、通訊接口,HMI各功能模塊的詳細(xì)需求、系統(tǒng)性能需求、數(shù)據(jù)需求和設(shè)計(jì)約束。
3.2 HMI軟件需求跟蹤
軟件需求跟蹤是需求管理的主要內(nèi)容,需求跟蹤要依賴于跟蹤鏈。通過(guò)跟蹤鏈可以向前或向后追蹤到需求和代碼實(shí)現(xiàn)。為了實(shí)現(xiàn)可跟蹤能力,每一個(gè)需求都應(yīng)該有且只有一個(gè)獨(dú)立的標(biāo)識(shí)號(hào),并且在整個(gè)項(xiàng)目中要前后統(tǒng)一。這樣需求管理者可根據(jù)鏈接快速找到需求的設(shè)計(jì)狀態(tài)、實(shí)現(xiàn)情況以及是否測(cè)試通過(guò)。
需求跟蹤是一項(xiàng)需要進(jìn)行大量手工勞動(dòng)的任務(wù),因此有效的人員管理和權(quán)限設(shè)置非常重要。在軟件開(kāi)發(fā)過(guò)程中要隨時(shí)更新需求的鏈接,為了避免不必要的誤動(dòng)作,需求管理者應(yīng)該注意需求數(shù)據(jù)庫(kù)的歸檔和需求基線的設(shè)置。需求跟蹤結(jié)束后,需求管理者可以利用管理工具自動(dòng)生產(chǎn)一份RTM(Requirement Tracing Matrix,需求跟蹤矩陣),如表3。
表3
根據(jù)IEEE 1012的標(biāo)準(zhǔn)和公司相關(guān)研發(fā)部相關(guān)要求,HMI軟件需求跟蹤活動(dòng)只介入軟件研發(fā)的三個(gè)階段,包括需求階段、概要設(shè)計(jì)階段、詳細(xì)設(shè)計(jì)階段。其中跟蹤示意圖如圖1所示。
圖1
1)需求階段
需求階段則是把HMI軟件需求規(guī)格說(shuō)明書和HMI軟件系統(tǒng)測(cè)試說(shuō)明書導(dǎo)入DOORS,由需求跟蹤成員將系統(tǒng)測(cè)試用例與軟件需求鏈接起來(lái)。當(dāng)鏈接工作完成后,由DOORS自動(dòng)導(dǎo)出需求階段的需求跟蹤矩陣,由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無(wú)效鏈接分析,并編制鏈接空白分析報(bào)告,將所有未跟蹤到源頭的系統(tǒng)測(cè)試用例匯總成空白分析表格,交由需求管理者存檔。
2)概要設(shè)計(jì)階段
概要設(shè)計(jì)階段則是把HMI軟件概要設(shè)計(jì)明書和HMI軟件集成測(cè)試說(shuō)明書導(dǎo)入DOORS。由開(kāi)發(fā)小組成員將HMI軟件概要設(shè)計(jì)與HMI軟件需求規(guī)格說(shuō)明書進(jìn)行鏈接,需求跟蹤成員完成軟件集成測(cè)試用例與概要設(shè)計(jì)的鏈接。理想情況下,每個(gè)設(shè)計(jì)都應(yīng)當(dāng)對(duì)應(yīng)相關(guān)需求,每個(gè)概要設(shè)計(jì)都有對(duì)應(yīng)的測(cè)試用例去驗(yàn)證。
同樣當(dāng)鏈接工作完成后,由DOORS自動(dòng)導(dǎo)出概要設(shè)計(jì)階段的跟蹤矩陣,由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無(wú)效鏈接分析,并編制鏈接空白分析報(bào)告。將所有未跟蹤到對(duì)應(yīng)需求的軟件概要設(shè)計(jì)匯總成空白分析表格,交由需求管理者傳遞給開(kāi)發(fā)小組;將集成測(cè)試用例和概要設(shè)計(jì)之間的空白鏈接匯總遞交給需求管理者處理。
3)詳細(xì)設(shè)計(jì)階段
詳細(xì)設(shè)計(jì)階段則是把HMI軟件詳細(xì)設(shè)計(jì)明書和HMI軟件單元測(cè)試說(shuō)明書導(dǎo)入DOORS。由開(kāi)發(fā)小組成員將HMI軟件詳細(xì)設(shè)計(jì)與HMI軟件概要設(shè)計(jì)進(jìn)行鏈接,需求跟蹤成員完成單元測(cè)試用例與詳細(xì)設(shè)計(jì)的鏈接。在鏈接工作完成后,由DOORS自動(dòng)導(dǎo)出該階段的跟蹤矩陣,由需求跟蹤負(fù)責(zé)人進(jìn)行空白分析和無(wú)效鏈接分析,并編制鏈接空白分析報(bào)告。其中將詳細(xì)設(shè)計(jì)與概要設(shè)計(jì)之間的空白鏈接匯總后交由需求管理者傳遞給開(kāi)發(fā)小組解決;將單元測(cè)試用例與詳細(xì)設(shè)計(jì)之間的空白鏈接交由需求管理者處理。
上述三個(gè)階段結(jié)束后,需求跟蹤負(fù)責(zé)人將跟蹤情況匯總,由DOORS自動(dòng)生產(chǎn)需求跟蹤矩陣。同時(shí)將需求跟蹤矩陣進(jìn)行分析,形成最終需求跟蹤分析報(bào)告,評(píng)估整個(gè)HMI軟件項(xiàng)目需求的可跟蹤性。
5結(jié)束語(yǔ)
該文給出了核電DCS二層人機(jī)界面軟件開(kāi)發(fā)過(guò)程的需求跟蹤執(zhí)行流程,探索性的提出各研發(fā)階段的需求跟蹤任務(wù)和關(guān)鍵活動(dòng),為執(zhí)行其他行業(yè)的軟件需求管理提供參考。
參考文獻(xiàn):
[1] Wiegers K E.軟件需求[M].2版.劉偉琴,劉洪濤,譯.北京:清華大學(xué)出版社,2004.
[2] Leffingwell D.軟件需求管理統(tǒng)一方法[M].蔣慧,林東,譯.北京:機(jī)械工業(yè)出版社,2002.
[3]向嫄.核電DCS中人機(jī)界面軟件的驗(yàn)證與確認(rèn)的探索研究[J].電腦知識(shí)與技術(shù),2012,18(8).
[4]王志方,谷鵬飛,張建波.數(shù)字化人機(jī)界面設(shè)計(jì)的人因工程問(wèn)題分析[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.