高海艦

（北京全路通信信號研究設計院有限公司，北京 100073）

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

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

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

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

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

1 解決方案

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

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

2 工具調研

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

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

3 架構設計

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

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

3.1 系統(tǒng)順序圖

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

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

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

3.3 審核流程發(fā)起

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

3.4 審核結果反饋

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

4 關鍵技術及實施途徑

4.1 工具的集成技術

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

4.1.1 DOORS集成

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

4.1.2 Change集成

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

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

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

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

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

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

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

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

項目基線演進流程如圖5所示。

4.3 審核結果通知

待審核對象的審核結果確定后，Change服務器要向審核服務器發(fā)送審核結果的通知，以便進行結果的采集和記錄，同時由審核服務器按照項目基線演進策略生成項目基線。

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

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

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

5 結論

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

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