需求管理在核電DCS系統(tǒng)開發(fā)中的應(yīng)用

夏丹陽，劉汪平

（1.中核控制系統(tǒng)工程有限公司，北京 100176；2.中國核電工程有限公司，北京 100189）

0 引言

隨著國內(nèi)外控制系統(tǒng)的發(fā)展，DCS（Distributed Control System）被廣泛地應(yīng)用于核電項目及其他行業(yè)。安全性及可靠性是核級DCS最終考慮的因素，目的是開發(fā)高質(zhì)量的軟件[1]。軟件系統(tǒng)開發(fā)過程中最難的部分是對要開發(fā)什么做出準(zhǔn)確性的判斷。所有概念性工作最難的是建立詳細(xì)的技術(shù)需求，這部分工作的錯誤對最終系統(tǒng)的破壞最大，也最難糾正[2]。V&V是用于在全生命周期內(nèi)評估軟件產(chǎn)品的一種嚴(yán)謹(jǐn)方法，力求保證軟件質(zhì)量并滿足用戶的需求[3]。軟件的開發(fā)及測試都以需求作為評估標(biāo)準(zhǔn)，因此需求管理是軟件開發(fā)過程的重要組成部分，貫穿核級DCS系統(tǒng)開發(fā)及測試的整個階段。因DCS系統(tǒng)的開發(fā)周期長、用戶需求及開發(fā)文檔數(shù)量多，進(jìn)而要求更為有效的需求管理。

1 需求管理

Rational把需求定義為“（正在構(gòu)建的）系統(tǒng)必須符合的條件或具備的功能”。需求管理就是：一種獲取、組織并記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個使客戶與項目團(tuán)隊對不斷變更的系統(tǒng)需求達(dá)成并保持一致的過程[4]。

目前的很多測試及配置管理工具均預(yù)留了與需求管理工具的接口，如TP、RTC等，足見其重要性。

表1 比較一覽表Table 1 Comparison table

2 需求管理工具

2.1 需求管理工具介紹

目前比較常用的需求管理工具有RTM、Borland的CaliberRM，IBM Rational的RequisitePro，IBM的DOORS。以上這些需求管理軟件在其功能上存在一定的差異，所針對的項目也略有不同。其中CaliberRM、RequisitePro針對于中小型項目，但在版本管理方面的支持較弱，無法建立基線，記錄變更。而RTM雖然可應(yīng)用于大型項目，但無討論及同步功能，不利于需求評審工作地開展。IBM 的DOORS通過使用DOORS/ERS，實施多種需求管理的方法，可使項目的管理更加透明。它不是單純的需求跟蹤工具，而是一個多平臺的需求管理解決方案。表1是對以上4種需求管理工具的比較。

結(jié)合本項目的規(guī)模，DCS系統(tǒng)的需求管理的要求及DOORS軟件在市場上占有的用戶份額-全球約有250000的用戶等因素，選擇DOORS軟件作為核電DCS系統(tǒng)的需求管理工具。

2.2 DCS系統(tǒng)采用需求管理工具的必要性

軟件測試是保證軟件質(zhì)量的重要環(huán)節(jié)，而穩(wěn)定的需求則是軟件測試的關(guān)鍵[5,6]。然而在DCS系統(tǒng)開發(fā)過程中需求變更頻繁，采用紙質(zhì)及電子版形式無法保證完整的記錄變更，需求管理工具則可以。其優(yōu)點在于以下幾個方面：

1）支持多人同時在線修改同一文檔。

2）保證需求更新后，開發(fā)及測試人員知悉的實時性。

3）保證需求管理的同步性，有效解決開發(fā)及測試人員之間對需求掌握的偏差問題。

4）需求變更信息易得性，包括需求變更日期、變更人員、變更位置、變更后版本。

圖1 需求管理流程圖Fig.1 Requirements management process

5）可對需求建立討論，方便需求評審前意見的交流。

6）權(quán)限管理，通過設(shè)定相應(yīng)的權(quán)限，可控制重要文件的獲取。

7）通過打基線，可進(jìn)行版本的管理。

8）對于復(fù)雜的模塊，可通過DXL語言，在模板庫中建立模板，生成模塊時調(diào)用模板。

9）將全部需求、屬性和跟蹤信息存放在數(shù)據(jù)庫中，數(shù)據(jù)庫可移植復(fù)用。

測試是為支持V&V目的而執(zhí)行的，測試包括4個階段，即部件測試、集成測試、回歸測試、系統(tǒng)測試，其中回歸測試貫穿于其他3個測試階段。需求的變更會導(dǎo)致測試用例的增加。DOORS軟件不僅可以進(jìn)行需求管理，也可進(jìn)行測試用例管理，在測試用例管理上，其優(yōu)點在于：

a）通過鏈接的功能，實現(xiàn)需求與測試用例之間的鏈接，鏈接可快速地跟蹤某個數(shù)據(jù)變化對系統(tǒng)其它部分的影響。

b）可進(jìn)行需求跟蹤，需求跟蹤可進(jìn)行入向及出向鏈接的分析，通過比較不同版本的需求跟蹤矩陣（RTM）模塊可以清楚地跟蹤到哪些需求及用例被更改過，方便用例與需求的同步。

c）測試用例覆蓋率統(tǒng)計，通過DOORS軟件可以統(tǒng)計測試用例對需求的覆蓋率，評估測試用例是否完全覆蓋到需求。

核級DCS系統(tǒng)所處的位置決定了其必須具備安全性、可靠性。而以需求作為重要評價依據(jù)的測試正是驗證核電廠軟件功能可用性、可靠性、安全性的關(guān)鍵點。測試不系統(tǒng)、不全面，不僅會導(dǎo)致測試結(jié)果的錯誤，還會影響后續(xù)現(xiàn)場調(diào)試，更為嚴(yán)重的是可能會對以后的核電廠運(yùn)行造成隱患。結(jié)合需求管理工具在需求及用例管理上的諸多優(yōu)點，決定了DCS系統(tǒng)采用需求管理工具是必要的。

圖2 版本變更比較Fig.2 A version change

3 DCS系統(tǒng)的需求管理

DCS系統(tǒng)需求管理是整個核電項目開發(fā)及V&V中的重要環(huán)節(jié)，開發(fā)及V&V工程師工作的開展均以需求作為評估。核電DCS系統(tǒng)需求管理貫穿于整個開發(fā)及測試過程中，不容小視。

需求管理可分為：需求變更管理、需求版本管理、需求跟蹤管理。圖1為DCS系統(tǒng)需求管理的流程。

3.1 DCS系統(tǒng)需求變更管理

需求變更管理包括對評審?fù)ㄟ^的需求建立基線,確定需要跟蹤的重要依賴關(guān)系,建立相關(guān)項之間的可追溯性,以及變更控制等活動。

需求是軟件開發(fā)和測試的綱領(lǐng)，其變更主要來自客戶對產(chǎn)品要求的變化，可分為需求刪除、需求增加、需求改變。

圖3 文檔跟蹤Fig.3 Document tracking

盡管需求變更是允許的，但需求變更不僅影響測試用例的數(shù)量及測試結(jié)果，還影響開發(fā)工作的重新執(zhí)行，重新設(shè)計和編碼，應(yīng)該盡量地避免和減少。核電項目規(guī)模大，需求數(shù)量多，在實際研發(fā)過程中變更次數(shù)也較多。在DCS系統(tǒng)研發(fā)項目進(jìn)行過程中，需求管理員應(yīng)定期對軟件需求變更情況做記錄并進(jìn)行評估，分析變更對項目的影響。本項目對需求變更程度的評估是通過變更指標(biāo)實現(xiàn)的。設(shè)r為軟件需求變更指標(biāo)，S為某個時間點的需求數(shù)量，C1為某時間段內(nèi)增加的需求數(shù)量，C2為某時間段修改的需求數(shù)量，C3為某時間段內(nèi)刪除的需求數(shù)量，則

r給出的是需求變更程度的量化度量。r指標(biāo)越接近于1，說明被測試的軟件需求越穩(wěn)定。

需求管理及測試人員可以根據(jù)項目情況為r設(shè)置一個閾值，本項目設(shè)定的閾值為0.75，r指標(biāo)低于該閾值時，表明軟件需求變更過于頻繁，應(yīng)暫停測試。

3.2 DCS系統(tǒng)需求版本管理

DOORS軟件可對需求文檔的版本進(jìn)行管理，無需借助其他版本管理工具，就可比較出版本的變化和差異。對于需求版本的管理是通過基線來實現(xiàn)的。需求管理員對評審?fù)ㄟ^的需求打基線，并進(jìn)行不同版本之間的比較，即比較當(dāng)前版本與歷史版本的基線。比較結(jié)果會以不同狀態(tài)顯示用戶修改、新增和刪除需求條目的情況。圖2為兩個不同版本需求的比較。

圖4 需求跟蹤矩陣Fig.4 Requirements traceability matrix

圖5 鏈接關(guān)系圖Fig.5 Link diagram

圖6 狀態(tài)跟蹤表Fig.6 State tracking table

3.3 DCS系統(tǒng)需求跟蹤管理

需求跟蹤是開發(fā)活動的一項重要任務(wù),其結(jié)果可用于可追溯性分析，對配置管理、測試覆蓋分析、V&V結(jié)果分析、回歸測試、關(guān)鍵性評估和V&V管理決策起到支持作用。其目的是建立與維護(hù)“需求-設(shè)計-實現(xiàn)-測試-安裝與檢驗-運(yùn)行與維護(hù)”之間的一致性。需求跟蹤要求對需求進(jìn)行正、反兩個方向的跟蹤，是存在于軟件生命各階段中一項持續(xù)和不斷更新的任務(wù)。需求跟蹤管理包括兩部分：創(chuàng)建需求跟蹤鏈及需求狀態(tài)跟蹤。

1）創(chuàng)建需求跟蹤鏈

需求跟蹤要依賴于跟蹤鏈，為了保證可跟蹤能力，每一個對象的標(biāo)識都要求是唯一的。DOORS軟件中DCS系統(tǒng)的需求跟蹤鏈?zhǔn)亲粉櫟接脩粜枨蟮?，鏈接的文檔包括開發(fā)需求、測試需求、設(shè)計、測試用例等其他系統(tǒng)元素。在DOORS中通過traceability wizard（跟蹤向?qū)В┥筛櫼晥D，可顯示需求演化的整個過程。需求跟蹤結(jié)束后，需求管理員可以利用管理工具自動生產(chǎn)一份RTM（Requirement Tracing Matrix，需求跟蹤矩陣），圖3、圖4為整個項目開發(fā)中文檔的跟蹤關(guān)系及RTM。

DCS系統(tǒng)從結(jié)構(gòu)上可劃分為過程級、操作級和管理級。過程級主要由過程控制站、I/O單元和現(xiàn)場儀表組成。操作級包括操作員站和工程師站，分別完成HMI（人機(jī)交互界面）軟件的實時監(jiān)控及HMI軟件的組態(tài)，其中HMI軟件的主要功能有報警、故障、當(dāng)前值、模擬流程圖、工況等。管理級主要是工廠管理信息系統(tǒng)[8]。IEEE 1012-2004是V＆V遵循的主要標(biāo)準(zhǔn)[7]，結(jié)合IEEE 1012的標(biāo)準(zhǔn)和研發(fā)過程相關(guān)要求及項目實際情況，DCS系統(tǒng)的需求跟蹤活動介入軟件研發(fā)的各個階段，包括需求階段、概要設(shè)計階段、詳細(xì)設(shè)計階段和測試階段。每個階段都需進(jìn)行相關(guān)的鏈接，可以有效的管理變化。在每個階段需求管理員將跟蹤情況匯總，由DOORS軟件自動生產(chǎn)RTM。同時進(jìn)行可追溯性分析，形成分析報告，評估需求跟蹤的一致性、完整性和正確性。3個階段完成后，可形成一個總的RTM，評估整個DCS系統(tǒng)需求在設(shè)計、實現(xiàn)和測試的可追溯性關(guān)系。圖5的V模型顯示了DCS系統(tǒng)不同研發(fā)階段文檔之間的鏈接關(guān)系。

2）需求狀態(tài)跟蹤

在需求管理過程中，跟蹤每項需求的狀態(tài)也是需求管理的一個重要方面。需求狀態(tài)作為需求的一個屬性，可以反映需求的當(dāng)前情況。在每一種可能的狀態(tài)類別中，如果能周期性地報告各狀態(tài)類別在整個需求中所占的百分比將會改進(jìn)項目的監(jiān)控工作。圖6為一個需求狀態(tài)跟蹤表的例子。

4 總結(jié)

本文在總結(jié)了需求管理工具在核電DCS系統(tǒng)研發(fā)中應(yīng)用的必要性的基礎(chǔ)上，給出了核電DCS開發(fā)過程的需求管理中各子項管理的執(zhí)行流程，探索性地提出各研發(fā)階段的需求跟蹤任務(wù)和關(guān)鍵活動，為執(zhí)行其他行業(yè)的軟件需求管理提供參考。

[1]楊永祥,丁軍.核電站數(shù)字化儀控系統(tǒng)軟件驗證和確認(rèn)[M].廈門:廈門大學(xué)出版社,2010:18-20.

[2]Brooks,F.P.,Jr.. No Silver Bullet Essence and Accidents of Software Engineering[J].Computer,1987,20(4):10-19.

[3]劉斌.軟件驗證與確認(rèn)[M].北京:國防工業(yè)出版社,2011:4-5.

[4]吳艷艷,周長倫,姜家軒,等.軟件項目管理中的需求管理[J].信息技術(shù)與信息化,2008,2:67-68.

[5]KENNER C,FALK J.計算機(jī)軟件測試[M].北京:機(jī)械工業(yè)出版社,2004:58.

[6]PERRY W E.軟件測試的有效方法[M].北京:機(jī)械工業(yè)出版社,2004:103.

[7]The institute electrical and electronics engineers,inc.IEEE standard for software verification and validation[S].2004．

[8]DCS[百度百科].http://baike.baidu.com/link?url=FsaYRQIwLl_a6e4RfOXsXbISXay6eaBkInBQn1Lqd91-fbOklOzJkiPH5AmeoXOF,2015.