直升機需求管理系統(tǒng)應(yīng)用方案研究

曾加剛　江卓逞　黃瑋

摘 要 本文以需求管理系統(tǒng)在某直升機型號中的具體應(yīng)用為基準(zhǔn)而展開論述，從需求管理問題與現(xiàn)狀、需求管理系統(tǒng)總架構(gòu)及需求管理具體應(yīng)用，詳細(xì)闡述需求開發(fā)、需求變更、需求發(fā)布、需求建模等4個獨立又能統(tǒng)一系統(tǒng)的實際操作內(nèi)容與步驟，實現(xiàn)基于模型的系統(tǒng)工程在具體型號中的應(yīng)用，真正意義上實現(xiàn)由“文檔驅(qū)動”到“需求驅(qū)動”，再到“模型”驅(qū)動的轉(zhuǎn)變。

關(guān)鍵詞 系統(tǒng)工程；需求管理；需求變更；需求發(fā)布；需求建模；需求管理系統(tǒng)

中圖分類號 V2 文獻(xiàn)標(biāo)識碼 A 文章編號 2095-6363（2017）17-0028-03

隨著科技的發(fā)展，復(fù)雜系統(tǒng)的工程將會遇到越來越多的挑戰(zhàn)，對于非人為因素加入的機械系統(tǒng)其復(fù)雜度將遠(yuǎn)遠(yuǎn)少于有人為因素加入的機械系統(tǒng)，如果是智能系統(tǒng)，其復(fù)雜度將指數(shù)級別上升。但要追究其需求的根源，難度相當(dāng)大。另外，由于航空裝備工程開發(fā)復(fù)雜度高，需求變更頻繁且持續(xù)演變，技術(shù)風(fēng)險日益增加，管理難度空前加大等等，都需要建立需求管理系統(tǒng)來管控所有的需求。本文主要以需求管理系統(tǒng)在某型號中的具體應(yīng)用為基準(zhǔn)而開展論述。

1 需求管理問題與現(xiàn)狀

需求工程是系統(tǒng)工程的一部分，是產(chǎn)品研發(fā)活動和管理的源頭，總輸入[1]，是我國高端裝備“正向設(shè)計”的必經(jīng)之路，也是我國民機型號研發(fā)的核心問題之一，不管是否參與國際競爭，都得遵循民航當(dāng)局的相關(guān)適航條例。例如：FAA/EASA要求民機型號設(shè)計保證體系滿足ARP4754A要求。因此，無論是從市場需求，還是從型號復(fù)雜程度的管控，或是從國際競爭的環(huán)境，以及自身的研發(fā)模式提升等方面，都急需需求工程，需要需求管理系統(tǒng)來落地需求工程。某直升機型號現(xiàn)階段的需求管理問題主要存在于以下幾方面。

1）在需求開發(fā)過程中，一方面由于系統(tǒng)越來越復(fù)雜，專業(yè)越來越多，質(zhì)量要求越來越高，交付周期越來越短；另一方面，需求來源多，需求的正確性、完整性、可追溯性和可驗證性，無法保證需求的同源性。

2）需求管理過程中，存在重方案、輕需求，沒有形成需求牽引的研發(fā)流程，造成產(chǎn)品不符合需求；以文檔形式傳遞的需求難以共同理解，大段的文本描述，容易造成理解歧義，達(dá)成共識的工作量巨大（即使有圖形，也是靜態(tài)的，無法運行）；需求變更的影響率和覆蓋率分析困難，也就是說采用基于文件的系統(tǒng)工程存在需求開發(fā)的可控性不高、基線不明確、版本較混亂。

3）需求變更對項目成本、進(jìn)度影響分析困難，在方案階段難以對系統(tǒng)架構(gòu)、功能、接口進(jìn)行驗證和確認(rèn)，加大了后期設(shè)計、開發(fā)和集成的成本和風(fēng)險。

因此，迫切需要有一套方法和工具來建立和維護(hù)需求與設(shè)計、測試驗證之間的跟蹤關(guān)系，以保持型號研制從用戶需求、系統(tǒng)需求到產(chǎn)品設(shè)計和開發(fā)等各階段需求的一致性。基于模型的需求工程[2]應(yīng)運而生，其所采用的模型化表達(dá)，比文檔更精確、嚴(yán)謹(jǐn)，并且可以執(zhí)行和驗證。

2 需求管理系統(tǒng)總架構(gòu)

需求管理系統(tǒng)主要包括需求開發(fā)、需求發(fā)布變更、需求管理以及需求建模，以滿足利益攸關(guān)者需要，從而實現(xiàn)從需求獲取、定義、分析到需求確認(rèn)與驗證的需求生命周期管理及需求數(shù)據(jù)的統(tǒng)一、集中、迭代管理。也就是說，需要構(gòu)建上述系統(tǒng)來更好地定義和管理需求，管控需求狀態(tài)及其變更，提供需求關(guān)聯(lián)和需求跟蹤的能力，以保持型號項目從用戶需求、系統(tǒng)需求到產(chǎn)品設(shè)計和開發(fā)等各階段需求的一致性。其內(nèi)容如下。

1）需求開發(fā)管理。主要是定義需求文件體系、模板、條目、屬性、視圖等需求信息架構(gòu)內(nèi)容，明確各專業(yè)的權(quán)限角色標(biāo)準(zhǔn)等，通過建立需求基線，確保需求版本清晰受控，為各業(yè)務(wù)專業(yè)提供統(tǒng)一的平臺，從而實現(xiàn)各層次各業(yè)務(wù)專業(yè)需求的管理、追蹤、驗證等，提供技術(shù)手段，主要在需求管理軟件DOORS[3]系統(tǒng)中實現(xiàn)。

2）需求變更管理。需求變更在產(chǎn)品研制實踐過程中會頻繁使用，特別是在需求分析、建模、驗證、設(shè)計等過程中，需求的追蹤性和完整性，其意義非同一般，會隨著時間、成本、技術(shù)、利益攸關(guān)者想法變化等因素而發(fā)生改變故，應(yīng)用成熟的技術(shù)，基于DOORS系統(tǒng)，提高需求條目的精細(xì)化程度，實現(xiàn)其精細(xì)化管控；基于需求變更管理工具（例如：Change[4]），實現(xiàn)需求更改的數(shù)字化定義與集成；組織變更控制委員會進(jìn)行需求更改的規(guī)范化控制，從而實現(xiàn)型號研發(fā)應(yīng)用各階段需求更改的通用化。

3）需求發(fā)布。需求發(fā)布輸出分三種方式，一種是通過RIF直接導(dǎo)出，輸出為RIF標(biāo)準(zhǔn)文件；另一種是通過文檔自動生成發(fā)布軟件RPE[5]，先期定義好樣式模板，配置好數(shù)據(jù)源及輸出樣式，再自動輸出想要的Word文檔或PDF文檔；第三種是DOORS系統(tǒng)軟件中直接輸出相應(yīng)的文檔。

4）需求建模。初步建立需求與功能開發(fā)和設(shè)計分析的對應(yīng)關(guān)系，同時，通過SysML建模語言[6]，初步建立總體/系統(tǒng)級功能、接口和架構(gòu)模型，并通過模型執(zhí)行對系統(tǒng)功能邏輯（功能活動、時序、接口、狀態(tài)）進(jìn)行驗證和確認(rèn)。

3 需求管理系統(tǒng)應(yīng)用方案

依據(jù)需求管理系統(tǒng)總架構(gòu)，全生命周期的管理需求，構(gòu)建需求管理體系（含流程、標(biāo)準(zhǔn)、規(guī)程與模板），形成需求驅(qū)動的研制流程，并支撐適航取證和安全性分析工作。其中，需求管理系統(tǒng)主要包含需求開發(fā)管理、需求變更管理、需求發(fā)布、需求建模等四大塊，即獨立又能統(tǒng)一的系統(tǒng)。下面是各系統(tǒng)在某直升機型號中的具體應(yīng)用。

3.1 需求開發(fā)管理

基于DOORS系統(tǒng)，可以輕松捕獲、跟蹤、分析和管理對需求的更改，需求控制是減少成本、提高效率和改進(jìn)產(chǎn)品質(zhì)量的關(guān)鍵，可以優(yōu)化整個組織和供應(yīng)鏈中的需求溝通、協(xié)作和確認(rèn)。憑借其擁有的內(nèi)置數(shù)據(jù)庫，能提供豐富的功能集來捕獲和管理需求。方便每個人參與并服務(wù)于需求開發(fā)管理，在某直升機型號概念設(shè)計階段主要開展以下工作。

1）命名規(guī)則定義。在DOORS系統(tǒng)中初始化前，型號工作者需要定義DOORS系統(tǒng)中的文件夾名或項目名的命名規(guī)則，在多型號項目管理中，將起到很重要的作用，因為在同一DOORS服務(wù)器系統(tǒng)中，項目名是不允許相同，但是，文件夾名是可以相同。這就要求，在多型號的DOORS系統(tǒng)管理中，必須定義命名規(guī)則。否則，只有通過新建服務(wù)器才能應(yīng)用。例如：以具體的某特征型號代號作為前綴或后綴命名。endprint

2）信息架構(gòu)定義與配置。信息架構(gòu)定義與配置是需求管理的核心內(nèi)容。其中，信息架構(gòu)定義是型號業(yè)務(wù)管理上的要求，而信息架構(gòu)配置是信息架構(gòu)定義在DOORS系統(tǒng)中的實現(xiàn)。信息架構(gòu)是指信息之間的結(jié)構(gòu)，包含信息和信息之間的關(guān)系兩部分，主要體現(xiàn)在信息架構(gòu)類型和信息架構(gòu)關(guān)系，在某直升機型號具體應(yīng)用中定義并配置了四種信息架構(gòu)類型。（1）需求規(guī)范：用于存儲規(guī)范化的需求；（2）設(shè)計：用于存儲設(shè)計相關(guān)的信息；（3）V&V：用于存儲驗證和確認(rèn)相關(guān)的信息；（4）ICD：用于存儲接口，包括EICD、MICD、FICD相關(guān)的信息。

同時，也有5種信息架構(gòu)關(guān)系應(yīng)用在某直升機型號的需求中。（1）滿足：用于表明本層需求與上層需求之間的關(guān)系；（2）分配：用于表明本層設(shè)計與本層輸入需求之間的關(guān)系；（3）驗證：用于表明驗證程序與本層輸入需求之間的關(guān)系；（4）衍生自：用于表明本層輸出需求與本層設(shè)計之間的關(guān)系；（5）參考：用于存放需求與參考引用的信息之間的關(guān)系。

同時，需要定義了具體的屬性、類型和視圖，供型號管理應(yīng)用。例如：需求編號、版本、變體、歷史、作者、來源、工作流、關(guān)鍵字、狀態(tài)、約束、優(yōu)先級、關(guān)聯(lián)、影響、工作量、驗收標(biāo)準(zhǔn)等組成。

3）角色權(quán)限管理與配置。依據(jù)業(yè)務(wù)信息架構(gòu)管理要求，配置角色權(quán)限。首先通過DOORS系統(tǒng)權(quán)限定義標(biāo)準(zhǔn)表，預(yù)先定義好與業(yè)務(wù)相關(guān)的各業(yè)務(wù)組，在系統(tǒng)中定義，并把個人的角色與權(quán)限賦予各業(yè)務(wù)組。

角色是承接業(yè)務(wù)的受動者，角色與業(yè)務(wù)組匹配，形成角色矩陣，與后面的權(quán)限匹配。在DOORS系統(tǒng)中包含4種角色：（1）標(biāo)準(zhǔn)：標(biāo)準(zhǔn)用戶沒有任何權(quán)限；（2）項目經(jīng)理：具有歸檔數(shù)據(jù)、分區(qū)數(shù)據(jù)、創(chuàng)建組的權(quán)限；（3）數(shù)據(jù)庫管理員：具有創(chuàng)建項目、歸檔數(shù)據(jù)、分區(qū)數(shù)據(jù)、創(chuàng)建組、創(chuàng)建用戶、管理數(shù)據(jù)庫的權(quán)限；（4）定制：可在創(chuàng)建項目、歸檔數(shù)據(jù)、分區(qū)數(shù)據(jù)、創(chuàng)建組、創(chuàng)建用戶、管理數(shù)據(jù)庫這幾種權(quán)限中任意選擇組合。

角色一般通過角色組與業(yè)務(wù)組合進(jìn)行管理。在某直升機型號應(yīng)用中分兩組，一是信息化用戶組（主要包括是數(shù)據(jù)庫管理員）；二是業(yè)務(wù)用戶組，主要包括工程師組（該角色類別又根據(jù)業(yè)務(wù)不同分為不同類別）；需求管理組；需求評審組。

權(quán)限是角色操作的能力，由兩類權(quán)限構(gòu)成，一是針對DOORS自身的角色權(quán)限，在新建用戶時會為其分配一個角色，包括標(biāo)準(zhǔn)、項目經(jīng)理、數(shù)據(jù)庫管理員、定制；二是針對項目、文件夾、模塊等特定對象本身的實際訪問權(quán)限，包括R（讀取）、M（修改）、C（創(chuàng)建）、D（刪除）、A（管理）。最終，將角色組與權(quán)限，組合成矩陣，就形成角色權(quán)限表，賦權(quán)給不同的操作人員。其中，不同的人員可以屬于不同的角色組。

3.2 需求變更管理

需求變更管理，用于提交和跟蹤變更請求，Change通過與DOORS系統(tǒng)一起使用，可以跟蹤任何需求內(nèi)容的變更。它主要通過需求變更管理流程來完成變更，子流程：需求變更申請流程、需求變更流程來實現(xiàn)控制。在某直升機型號應(yīng)用中主要開展以下工作。

1）業(yè)務(wù)變更流程梳理與確定。依據(jù)業(yè)務(wù)管理要求，特別是標(biāo)準(zhǔn)化部門，應(yīng)出臺相應(yīng)的需求變更管理業(yè)務(wù)流程，來規(guī)范變更的控制模型。對于直升機研制過程來說，需求變更在型號研發(fā)過程中，可隨時發(fā)生：（1）當(dāng)需求基線凍結(jié)之后即啟動需求更改管理流程；（2）在需求分析階段，凍結(jié)需求基線，作為各專業(yè)內(nèi)部設(shè)計與各專業(yè)之間協(xié)調(diào)接口的輸入，當(dāng)發(fā)生需求更改時，通過更改流程控制需求變更，變更頻繁；（3）在需求建模與架構(gòu)仿真設(shè)計時，需求變更比較頻繁；（4）在設(shè)計階段，當(dāng)發(fā)生設(shè)計問題時，發(fā)起需求更改，作為再設(shè)計的輸入；（5）在研制和試驗階段，發(fā)生更改時，發(fā)起需求更改流程，更改設(shè)計，作為研制和試驗的輸入。

依據(jù)變更控制模型設(shè)定合適的流程，主要由需求變更管理流程和其兩個二級流程，即：需求變更申請流程、需求變更流程組成。

另外，需要組建需求變更控制委員會，它是需求變更的審定和決策機構(gòu)，通過流程形式評估、審查、協(xié)調(diào)和批準(zhǔn)各類更改，其成員為參與項目的各單位負(fù)責(zé)人，承擔(dān)不同的角色。

2）需求變更狀態(tài)設(shè)置與定義。主要依據(jù)需求變更管理流程及其兩個二級流程，定義好不同的狀態(tài)，滿足變更業(yè)務(wù)流程需求，從而在系統(tǒng)中部署實施。

在需求變更申請流程設(shè)置了八種狀態(tài)：（1）創(chuàng)建：表明流程開始創(chuàng)建；（2）已創(chuàng)建：變更表單已經(jīng)創(chuàng)建；（3）已退回發(fā)起人：變更表單由其它狀態(tài)退回至發(fā)起人；（4）已提交審批：變更表單已經(jīng)提交給本專業(yè)CCB成員，等待其進(jìn)行審批；（5）本專業(yè)已審批：本專業(yè)CCB委員已經(jīng)審批完變更單，等待其它受影響專業(yè)進(jìn)行會簽；（6）已會簽：所有受影響專業(yè)的CCB委員已經(jīng)會簽完成，等待項目主任/副主任進(jìn)行審批；（7）已通過：項目主任/副主任已經(jīng)審批完變更單，進(jìn)入實際的需求變更流程；（8）已拒絕：需求變更申請單被拒絕，流程結(jié)束。

在需求變更流程中設(shè)置六種狀態(tài)：（1）創(chuàng)建：表明流程開始觸發(fā)；（2）已創(chuàng)建：子流程從此處開始，已經(jīng)創(chuàng)建；（3）已分配：各專業(yè)CCB委員已經(jīng)分配了實際的需求修改人；（4）評審中：需求修改人修改完需求后，提交復(fù)審人進(jìn)行復(fù)審；（5）已批準(zhǔn)：需求復(fù)審人已批準(zhǔn)需求更改后的內(nèi)容；（6）已應(yīng)用：需求更改已應(yīng)用在需求管理工具中，需求變更流程結(jié)束。

3）表單設(shè)計與配置模板。根據(jù)業(yè)務(wù)管理部門要求，提供的變更表單，在Change系統(tǒng)中進(jìn)行設(shè)置。整個需求變更表單，可根據(jù)不同的用戶權(quán)限，對字段具有不同的訪問權(quán)限。

當(dāng)需求編寫到一定成熟度后，需打基線，并將需求變更進(jìn)行管理。在需求變更之前，需要為DOORS模塊配置需求變更模版，項目負(fù)責(zé)人必須具有與項目經(jīng)理（用戶類型）相同的權(quán)限才可配置變更請求模板。

3.3 需求發(fā)布

需求發(fā)布，是一個自動執(zhí)行的文檔生成解決方案，使文檔生成流程化、便捷化，達(dá)到輕量級的效果。通過抽取多種數(shù)據(jù)源的數(shù)據(jù)，如DOORS、XML、REST等；定義文檔模板、定義文檔規(guī)范，便于達(dá)到以下明顯效果：嚴(yán)格控制需求源頭，動態(tài)的標(biāo)準(zhǔn)化、自動化生成文件；有利于建立標(biāo)準(zhǔn)的文件體系。在某直升機型號應(yīng)用中主要開展以下工作。endprint

1）文件自動生成（RPE）前提條件。首先要制定文檔標(biāo)準(zhǔn)，主要依據(jù)標(biāo)準(zhǔn)化部門提供的標(biāo)準(zhǔn)樣式，匹配并處理宏代碼，保存形成模板文件（.dot）；其次，制定內(nèi)容標(biāo)準(zhǔn)，一般由業(yè)務(wù)部門提出，在輸出的文檔中內(nèi)容表現(xiàn)；最后，輸出屬性規(guī)則定義，為何更好地通過RPE軟件，將DOORS內(nèi)的數(shù)據(jù)自動生成符合業(yè)務(wù)和標(biāo)準(zhǔn)化部門要求的規(guī)范化的文檔，需要在DOORS內(nèi)編寫對象時符合一定的要求，并維護(hù)相應(yīng)的屬性，主要包括標(biāo)識屬性建立和DOORS模塊對象編寫規(guī)則兩方面，主要是預(yù)先定義好每條屬性輸出后的表現(xiàn)形式。

2）主要功能與步驟。某直升機型號通過具體的定義與設(shè)置，控制需求版本，建立文件標(biāo)準(zhǔn)體系，定義相關(guān)模板，其主要功能和步驟有以下幾點。

（1）新建文檔模版：文檔模版是RPE生成文檔的基礎(chǔ)。在文檔模版中，定義了抽取的數(shù)據(jù)源類型及數(shù)據(jù)的展現(xiàn)形式；（2）抽取數(shù)據(jù)源：RPE可根據(jù)不同的數(shù)據(jù)源（如DOORS、RQM、XML）抽取出相應(yīng)的數(shù)據(jù)源模式，定義目標(biāo)數(shù)據(jù)源的數(shù)據(jù)結(jié)構(gòu)；（3）定義文檔模版：文檔模版支持豐富的控件進(jìn)行輸出形式的定義；（4）定義文檔規(guī)范：在文檔規(guī)范中，定義了輸出格式、采用的樣式文件、使用的文檔模版、需要配置的變量信息等；（5）保持文檔模版與文檔規(guī)范同步：當(dāng)啟用模版與規(guī)范同步功能后，當(dāng)文檔模版發(fā)生變化時，會將對應(yīng)變化反映在規(guī)范中；（6）預(yù)覽文檔生成及實際文檔生成：當(dāng)目標(biāo)數(shù)據(jù)量較大時，建議在實際文檔生成之前進(jìn)行結(jié)果預(yù)覽。預(yù)覽同樣也會生成文檔，只是將數(shù)據(jù)量限定在一個小范圍內(nèi)（如10條，可在RPE選項中配置）；文檔發(fā)布完成后，可能還要手工進(jìn)行少量的處理。因為不同的部門發(fā)布不同的文檔，對文檔特有的信息還要根據(jù)實際情況進(jìn)行適當(dāng)更改。

3.4 需求建模

需求建模是應(yīng)用Rhapsody[6]建模工具，為某直升機型號的起飛、懸停、降落建立模型。Harmony SE的一種基于模型的系統(tǒng)工程（MBSE）[2]方法的實現(xiàn)，在系統(tǒng)工程應(yīng)用領(lǐng)域一方面用于系統(tǒng)體系結(jié)構(gòu)設(shè)計的多用途建模，另一方面用于對由軟硬件、數(shù)據(jù)和人綜合而成的復(fù)雜系統(tǒng)的集成體系結(jié)構(gòu)進(jìn)行可視化的說明、分析、設(shè)計及校驗。同時，通過對各種不同的系統(tǒng)工程問題進(jìn)行建模，能夠完成用例圖、活動圖、順序圖、塊定義圖、內(nèi)部快圖、狀態(tài)機圖等功能。某型號在需求分析、功能分析、設(shè)計綜合過程中使用了以下功能。

1）需求分析。需求分析的目的是分析原始的利益攸關(guān)者需求，從中捕獲系統(tǒng)需求，即確定系統(tǒng)必須做什么，并針對系統(tǒng)需求建立系統(tǒng)用例，即確定系統(tǒng)應(yīng)具備哪些功能。主要活動內(nèi)容：創(chuàng)建項目，導(dǎo)入需求，創(chuàng)建用例，分析需求覆蓋范圍，做影響性分析，形成需求圖、需求表格、用例圖、矩陣視圖等。

2）功能分析。功能分析是在黑盒狀態(tài)下分析每一個系統(tǒng)用例的功能流程，進(jìn)而識別系統(tǒng)與外界的交互，最終完整描述系統(tǒng)的狀態(tài)行為（這一過程也稱為黑盒分析），一個用例執(zhí)行一遍功能分析過程。這一階段的焦點是將功能性的、表現(xiàn)的、接口的以及其他的需求翻譯成系統(tǒng)功能的清晰描述，并用來指導(dǎo)后續(xù)的設(shè)計集成。主要活動內(nèi)容：創(chuàng)建模型上下文，創(chuàng)建活動圖，生成場景圖，生成端口和接口，生成狀態(tài)機，模型執(zhí)行，重新組織狀態(tài)機，添加中斷狀態(tài)機，添加塊追蹤，需求變更分析。形成活動視圖、順序視圖、結(jié)構(gòu)視圖、狀態(tài)視圖、內(nèi)部塊圖、接口控制文檔等。

3）設(shè)計綜合。設(shè)計綜合是在綜合考慮所有系統(tǒng)功能的基礎(chǔ)上進(jìn)行系統(tǒng)的架構(gòu)分析與設(shè)計，將系統(tǒng)拆分成子系統(tǒng)，然后基于統(tǒng)一架構(gòu)對每一個用例按子系統(tǒng)進(jìn)行功能分解與分配，子系統(tǒng)成為分析的焦點，這一過程也稱為白盒分析。主要活動內(nèi)容：創(chuàng)建架構(gòu)模型，為Block分配操作、事件、屬性，場景圖、端口、接口，分配非功能性需求，集成用例模型。

4 結(jié)論

按照上述需求管理系統(tǒng)應(yīng)用方案，一方面有利于基于模型的系統(tǒng)工程方法（MBSE）實施應(yīng)用，對應(yīng)于具體的業(yè)務(wù)流程階段劃分，建立全生命周期的研制流程體系；另一方面便于借鑒最佳實踐，形成可操作的文件體系，如：運營環(huán)境體系文件，系統(tǒng)需求文件體系等，更重要的是實現(xiàn)真正意義上的由“文檔驅(qū)動”到“需求驅(qū)動”，再到“模型”驅(qū)動的轉(zhuǎn)變。

參考文獻(xiàn)

[1]張新國.系統(tǒng)工程手冊[M].北京：機械工業(yè)出版社，2014.

[2]張新國.基于模型的系統(tǒng)工程（MBSE）方法論綜述[M].北京：機械工業(yè)出版社，2014.

[3]IBM Rational DOORS 9.5.2，http：//www.ibm.com/software/rational/

[4]IBM Rational Change 5.3.0，http：//www.ibm.com/software/rational/

[5]Rational Publishing Engine 1.3.0， https：//www.ibm.com/support/knowledgecenter/SS6RHZ_1.3.0/

[6]IBM Rational Rhapsody Model Based Systems Engineering Workflow v7.6（Rational Harmony）.endprint