高速鐵路信號系統(tǒng)安全軟件質(zhì)量控制自動化技術(shù)研究

高海艦

（北京全路通信信號研究設(shè)計(jì)院有限公司，北京 100073）

當(dāng)前我國高速鐵路技術(shù)快速發(fā)展，作為控制列車高速安全運(yùn)行的信號系統(tǒng)的地位越來越重要。從CTCS-2級到CTCS-3級，信號系統(tǒng)越來越復(fù)雜，軟件在信號系統(tǒng)中所占比重越來越大，軟件的復(fù)雜性、重要性也越來越高。

通常對信號系統(tǒng)安全相關(guān)軟件的安全等級要求都比較高，一般要達(dá)到歐標(biāo)SIL4級。對于這種高復(fù)雜度和高安全性軟件，開發(fā)過程中如何進(jìn)行高效的質(zhì)量管理，以滿足軟件的高質(zhì)量要求，始終是目前軟件工程的一個難點(diǎn)和研究的熱點(diǎn)。

高安全性軟件質(zhì)量管理脫離不開通常軟件工程質(zhì)量管理的范疇，只是會過程卡控更復(fù)雜、要求更嚴(yán)格。在歐標(biāo)EN 50128中，安全軟件質(zhì)量保證要求供應(yīng)商、開發(fā)者必須有適應(yīng)于EN ISO 9000系列的質(zhì)量保證體系，來支持本歐洲標(biāo)準(zhǔn)的要求，并高度推薦EN ISO 9001認(rèn)證。保證軟件質(zhì)量，是保證軟件安全性的基礎(chǔ)。質(zhì)量失控，軟件的安全性就無從談起。

軟件開發(fā)的關(guān)鍵過程通常包括需求、設(shè)計(jì)、實(shí)現(xiàn)、測試4個階段，過程并不復(fù)雜，但考慮到實(shí)際軟件項(xiàng)目開發(fā)過程中的迭代及演進(jìn)過程，如何保證此復(fù)雜開發(fā)流程中軟件質(zhì)量嚴(yán)格可控，同時又保證管理過程的效率，以便不對軟件開發(fā)的進(jìn)度造成太大的影響，始終是一個令人頭疼的問題。

要解決這一矛盾，除了優(yōu)化管理流程，完善管理制度，加強(qiáng)培訓(xùn)之外，還有一個更直接有效的方法，就是充分利用現(xiàn)代軟件輔助開發(fā)或質(zhì)量管理的工具，盡量實(shí)現(xiàn)管理過程的自動化、信息化和電子化，理想結(jié)果是達(dá)到寓管理于無形的效果，減輕開發(fā)人員和質(zhì)量保障人員的負(fù)擔(dān)與工作強(qiáng)度，提高管理的質(zhì)量。

1 解決方案

要實(shí)現(xiàn)管理過程的自動化、信息化和電子化的目標(biāo)，首先要把開發(fā)過程中關(guān)鍵階段的成果——需求規(guī)范、設(shè)計(jì)規(guī)范、測試案例等，作為待審核對象放到一個可靠、規(guī)范的環(huán)境中進(jìn)行開發(fā)和管理，建立需求和設(shè)計(jì)、測試的追蹤關(guān)系，進(jìn)行覆蓋分析、變更影響分析，并進(jìn)行版本控制及項(xiàng)目基線管理。同時還要有流程管理工具，從流程上對待審核對象進(jìn)行審核控制，自動記錄審核過程。

目前，針對需求管理、變更控制、版本管理都有成熟的專業(yè)商用工具軟件，但這些工具軟件往往只關(guān)注解決某方面的問題，缺少協(xié)同，并且沒有有效集成，使用起來很不方便。如果通過篩選，選擇合適的工具軟件，經(jīng)過系統(tǒng)設(shè)計(jì)及二次開發(fā)，進(jìn)行功能擴(kuò)展，同時實(shí)現(xiàn)各個分離工具的有機(jī)集成，可滿足系統(tǒng)需求。

2 工具調(diào)研

IBM Rational DOORS（簡稱DOORS）是目前比較流行的商用需求管理工具，由IBM公司開發(fā)。具有需求編輯與查看、需求屬性管理、需求基線管理、修改歷史記錄、需求檢索、聯(lián)接（Links）和可疑聯(lián)接（Suspect Link）建立、關(guān)聯(lián)關(guān)系的分析、訪問權(quán)限控制、文檔的導(dǎo)入導(dǎo)出等功能。

IBM Rational Change（簡稱Change）也是IBM公司的產(chǎn)品，定位于變更過程的管理與控制，具有靈活的流程定制、屬性定制、數(shù)據(jù)查詢、報(bào)告定制、用戶及角色管理等功能，能實(shí)現(xiàn)變更管理流程、評審管理流程和缺陷管理流程。

3 架構(gòu)設(shè)計(jì)

集成DOORS和Change工具，搭建軟件質(zhì)量管理自動化系統(tǒng)。將軟件開發(fā)過程中的階段性成果，包括需求規(guī)范、設(shè)計(jì)規(guī)范、測試案例都在DOORS內(nèi)進(jìn)行開發(fā)和管理。在一定階段，將開發(fā)過程中階段性成果按模板導(dǎo)出文檔，然后將此文檔上傳Change服務(wù)器，并發(fā)起審核流程。待審核有結(jié)果時，將審核結(jié)果記錄到審核服務(wù)器，便于后續(xù)的查詢以及項(xiàng)目基線生成。

質(zhì)量控制自動化系統(tǒng)由5部分組成：質(zhì)量控制自動化系統(tǒng)客戶端、DOORS客戶端、DOORS服務(wù)器、Change服務(wù)器、審核狀態(tài)記錄及基線管理服務(wù)器（簡稱審核服務(wù)器）。

3.1 系統(tǒng)順序圖

管理過程覆蓋需求、設(shè)計(jì)、測試等軟件開發(fā)周期的主要部分。需求規(guī)范、設(shè)計(jì)規(guī)范和測試案例都在DOORS內(nèi)進(jìn)行開發(fā)和管理，審核過程主要在Change內(nèi)完成。審核的結(jié)果以及項(xiàng)目的基線管理主要由審核服務(wù)器負(fù)責(zé)。主要過程如圖1所示。

3.2 審核發(fā)起前的準(zhǔn)備流程

審核流程發(fā)起前，首先要在DOORS內(nèi)對待審核對象打基線，固化狀態(tài)。然后將此基線版本導(dǎo)出文檔，此文檔將作為Change中的審核流程的附件上傳，便于審核者審閱。具體過程如圖2所示。

3.3 審核流程發(fā)起

首先在Change內(nèi)定制符合ISO 9001質(zhì)量標(biāo)準(zhǔn)和企業(yè)軟件質(zhì)量管理要求的審核流程。然后通過二次開發(fā)，實(shí)現(xiàn)在質(zhì)量控制自動化系統(tǒng)的客戶端自動登陸Change服務(wù)器，并發(fā)起審核流程。具體過程如圖3所示。

3.4 審核結(jié)果反饋

在Change內(nèi)，各個角色按照分配的權(quán)限，根據(jù)流程，執(zhí)行對應(yīng)的狀態(tài)遷移，從而完成各自的職責(zé)。當(dāng)最終待審核對象審核通過或未通過的狀態(tài)遷移完成后，Change服務(wù)器要向?qū)徍朔?wù)器發(fā)送通知，由審核服務(wù)器獲取待審核對象的審核結(jié)果及其他相關(guān)信息，進(jìn)行存檔，并生成或演進(jìn)項(xiàng)目基線。具體過程如圖4所示。

4 關(guān)鍵技術(shù)及實(shí)施途徑

4.1 工具的集成技術(shù)

質(zhì)量控制自動化系統(tǒng)通過DOORS和Change提供的應(yīng)用編輯接口（API），將工具的客戶端部分的功能集成到質(zhì)量控制自動化系統(tǒng)的客戶端，以簡化和方便軟件開發(fā)人員的操作。

4.1.1 DOORS集成

DOORS為功能擴(kuò)展、定制以及與其他系統(tǒng)的集成提供API，主要的接口是DOORS eXtension Language(DXL)。在DOORS客戶端有DXL Server，外部通過DOORS提供的API建立進(jìn)程間通信（IPC）通道，將DXL腳本發(fā)送到DXL Server內(nèi)解釋執(zhí)行，實(shí)現(xiàn)功能擴(kuò)展。

4.1.2 Change集成

Web Service是建立可互操作的分布式應(yīng)用程序的新平臺，它是一套標(biāo)準(zhǔn)，定義了應(yīng)用程序如何在Web上實(shí)現(xiàn)互操作性。它是一種新的Web應(yīng)用程序分支，是自包含、自描述、模塊化的應(yīng)用。各應(yīng)用程序通過網(wǎng)絡(luò)協(xié)議和規(guī)定的一些標(biāo)準(zhǔn)數(shù)據(jù)格式（Http，XML，Soap)來訪問Web Service，通過Web Service內(nèi)部執(zhí)行得到所需結(jié)果。

本系統(tǒng)利用Change的Web Service提供的Web服務(wù)的接口，按照WSDL文件生成Java版的Change客戶端，并集成到質(zhì)量控制自動化系統(tǒng)的客戶端。

4.2 基于需求的軟件系統(tǒng)基線演進(jìn)策略

軟件開發(fā)過程中基線管理的難點(diǎn)：在軟件開發(fā)過程，每次需求發(fā)生變更，理論上要求對應(yīng)的設(shè)計(jì)、測試及實(shí)現(xiàn)都要及時修改，以適應(yīng)需求的變更，在此基礎(chǔ)上根據(jù)階段目標(biāo)形成一條條項(xiàng)目基線。但在開發(fā)過程中，由于種種原因，需求狀態(tài)不穩(wěn)定，開發(fā)過程中的需求往往存在如下特點(diǎn)：1） 更新頻率大；2）基線版本多。這對項(xiàng)目開發(fā)過程中的項(xiàng)目基線管理構(gòu)成很大的困難。

全面的基線配置項(xiàng)涵蓋的范圍比較廣，除了需求規(guī)范、測試規(guī)范說明和設(shè)計(jì)規(guī)格說明、數(shù)據(jù)庫描述外，還包括用戶文檔，如安裝說明、操作說明、用戶手冊和維護(hù)要求等。但考慮到需求、設(shè)計(jì)、測試在軟件開發(fā)過程中的重要作用，本文主要集中討論軟件開發(fā)過程中的需求、設(shè)計(jì)、測試的基線演進(jìn)。至于軟件項(xiàng)目開發(fā)前的項(xiàng)目策劃，以及軟件項(xiàng)目開發(fā)后期形成的用戶文檔的基線不在此處討論。

前面已經(jīng)說過，在DOORS內(nèi)進(jìn)行需求規(guī)范、設(shè)計(jì)規(guī)范、測試案例的管理；需求在軟件開發(fā)過程中的地位盡人皆知，需求驅(qū)動開發(fā)，需求驅(qū)動測試的觀念被廣泛接收。在項(xiàng)目基線演進(jìn)過程中，需求規(guī)范的作用獨(dú)特。

收集需求、定義系統(tǒng)在軟件開發(fā)過程的第一步，是設(shè)計(jì)和測試的依據(jù)，后續(xù)的整個設(shè)計(jì)、實(shí)現(xiàn)以及測試都由軟件需求驅(qū)動。在軟件開發(fā)過程中，需求規(guī)范應(yīng)是最先形成，需求規(guī)范在需求管理工具DOORS內(nèi)進(jìn)行開發(fā)和管理。當(dāng)需求開發(fā)到一定階段后，生成一個需求基線，然后在Change內(nèi)發(fā)起需求規(guī)范的審核流程。如果審核通過，Change服務(wù)器向?qū)徍朔?wù)器發(fā)送審核結(jié)果，審核服務(wù)器記錄需求的基線版本，并生成新的項(xiàng)目基線。

需求規(guī)范通過審核并發(fā)布后，依據(jù)需求規(guī)范開展模型設(shè)計(jì)以及測試設(shè)計(jì)，輸出是軟件系統(tǒng)概要設(shè)計(jì)和測試案例。當(dāng)模型設(shè)計(jì)和測試設(shè)計(jì)到一定階段，與需求規(guī)范一樣要提交審核，在提交審核時，要指明待審核的設(shè)計(jì)規(guī)格和測試案例是針對審核服務(wù)器中哪個需求基線進(jìn)行的設(shè)計(jì)（指定設(shè)計(jì)輸入）。審核通過后，Change服務(wù)器向?qū)徍朔?wù)器發(fā)送審核結(jié)果。

項(xiàng)目基線演進(jìn)流程如圖5所示。

4.3 審核結(jié)果通知

待審核對象的審核結(jié)果確定后，Change服務(wù)器要向?qū)徍朔?wù)器發(fā)送審核結(jié)果的通知，以便進(jìn)行結(jié)果的采集和記錄，同時由審核服務(wù)器按照項(xiàng)目基線演進(jìn)策略生成項(xiàng)目基線。

在Change的流程設(shè)計(jì)中，可以通過定制，讓流程狀態(tài)遷移時，自動觸發(fā)trigger，就是執(zhí)行特定的perl腳本或javascript腳本，從而完成特定的功能，如設(shè)置狀態(tài)、查詢結(jié)果、發(fā)送郵件等。利用這種自動觸發(fā)機(jī)制，編寫perl腳本，然后通過http協(xié)議向?qū)徍朔?wù)器發(fā)送消息，通知其向Change服務(wù)器獲取審核結(jié)果以及其他相關(guān)屬性信息，完成審核結(jié)果通知功能。

發(fā)送消息的部分perl腳本如下。

my $ua = LWP::UserAgent->new;

5 結(jié)論

本文探討通過設(shè)計(jì)與二次開發(fā)，將專業(yè)的需求管理工具擴(kuò)展為需求規(guī)范、設(shè)計(jì)規(guī)范和測試案例的管理平臺，將專業(yè)的變更管理工具擴(kuò)展為過程審核平臺，同時將它們有機(jī)集成到質(zhì)量控制自動化系統(tǒng)中，結(jié)合新開發(fā)的審核服務(wù)器，實(shí)現(xiàn)了質(zhì)量審核卡控過程的電子化，項(xiàng)目基線管理的自動化，并部分實(shí)現(xiàn)了項(xiàng)目配置管理的自動化。當(dāng)然，本系統(tǒng)還有改進(jìn)的余地，例如目前需求規(guī)范、設(shè)計(jì)規(guī)范和測試案例等重要的技術(shù)文檔已經(jīng)實(shí)現(xiàn)了審核過程電子化和配置管理自動化的目標(biāo)，但代碼還沒納入進(jìn)來，后續(xù)考慮將長于代碼配置管理的工具IBM Rational Synergy或版本管理工具Subvision集成進(jìn)來，通過二次開發(fā)，實(shí)現(xiàn)源代碼與技術(shù)文檔的統(tǒng)一管理。

[1] 李佳慧．業(yè)務(wù)需求驅(qū)動的軟件質(zhì)量管理系統(tǒng)[EB/OL].[2009-06-25].http://www.ibm.com/developerworks/cn/rational/r-cn-bqdrqm/#authorl.