王飛飛 史家濤 王夢 何曉飛

（濰柴動力股份有限公司 山東省濰坊市 261061）

嵌入式軟件通常是基于項(xiàng)目來管理構(gòu)建每一版軟件所需要的需求、變更、缺陷，在傳統(tǒng)的嵌入式軟件管理模式中，各嵌入式軟件開發(fā)項(xiàng)目之間相互獨(dú)立，各項(xiàng)目分別管理本項(xiàng)目下的需求、變更、缺陷，發(fā)起版本構(gòu)建任務(wù)，并交付構(gòu)建后的軟件，整個過程采用V流程的開發(fā)模式。但在實(shí)際開發(fā)過程中，同一組織的不同嵌入式軟件開發(fā)項(xiàng)目之間會存在大量可復(fù)用的需求、變更、缺陷，基于項(xiàng)目維度的管理方式，會造成同一需求、變更、缺陷的多次重復(fù)調(diào)度，重復(fù)分析、設(shè)計(jì)、實(shí)現(xiàn)、集成、測試，這會造成對組織資源的巨大浪費(fèi)。

與此同時，在配置管理方面，傳統(tǒng)嵌入式軟件基于需求、變更、缺陷所產(chǎn)生的模型或者代碼的配置管理模式也是針對項(xiàng)目本身分別開展配置管理，這決定了同一需求、變更、缺陷所修改的模型或者代碼的配置管理工作也需開展多次。在傳統(tǒng)項(xiàng)目制模式下，不同項(xiàng)目中對同一模型的負(fù)責(zé)人可能并不相同，極有可能造成在一個項(xiàng)目中已經(jīng)被正確實(shí)現(xiàn)的需求，在其他項(xiàng)目中卻未被正確實(shí)現(xiàn)的問題，無法保證需求與所關(guān)聯(lián)模型與代碼版本的一致性，從而造成最終產(chǎn)品的質(zhì)量問題。同理，傳統(tǒng)項(xiàng)目管控模式亦無法保證缺陷、變更在不同項(xiàng)目之間的移植復(fù)用率。

針對上述問題，本文提出了嵌入式軟件平臺化管理方案，通過平臺類項(xiàng)目以及應(yīng)用匹配類項(xiàng)目的建設(shè)，實(shí)現(xiàn)對可復(fù)用需求、變更、缺陷的平臺化管理，從根本上解決重復(fù)需求開發(fā)管理、重復(fù)修復(fù)缺陷的問題。

PTC公司的ALM（軟件生命周期管理）系統(tǒng)可以實(shí)現(xiàn)嵌入式軟件的V流程中所有環(huán)節(jié)的全生命周期管理，本文提出的平臺化管理方案可以基于PTC公司的ALM系統(tǒng)開展。通過一系列定制開發(fā)，實(shí)現(xiàn)平臺類項(xiàng)目以及應(yīng)用匹配類項(xiàng)目在ALM系統(tǒng)中的線上管理，實(shí)現(xiàn)需求、變更、缺陷以及模型、代碼的在不同項(xiàng)目間的靈活復(fù)用。

1 平臺項(xiàng)目架構(gòu)

嵌入式軟件需求通常分為三個層級：客戶需求、系統(tǒng)需求、軟件需求，客戶需求直觀體現(xiàn)客戶提出的相關(guān)功能、性能、接口相關(guān)需求；系統(tǒng)需求將客戶需求轉(zhuǎn)換為需求開發(fā)人員可以理解的技術(shù)要求；軟件需求將系統(tǒng)需求轉(zhuǎn)化為軟件層級需要實(shí)現(xiàn)的邏輯功能要求；而針對軟件需求層級，由于需求實(shí)現(xiàn)方式的不同，進(jìn)一步劃分為應(yīng)用軟件需求和基礎(chǔ)軟件需求；應(yīng)用軟件需求通常是由Matlab建模實(shí)現(xiàn)，采用基于模型的設(shè)計(jì)理念；基礎(chǔ)軟件需求由C語言實(shí)現(xiàn)。

實(shí)現(xiàn)需求、缺陷、變更的平臺項(xiàng)目管理理念，需建立平臺項(xiàng)目，平臺項(xiàng)目架構(gòu)建議如圖1所示。

圖1：平臺項(xiàng)目架構(gòu)

平臺項(xiàng)目架構(gòu)中包含兩類平臺項(xiàng)目，一類應(yīng)用匹配類項(xiàng)目：其中I類平臺項(xiàng)目為應(yīng)用軟件平臺類項(xiàng)目，用于管理嵌入式軟件的平臺化的客戶需求、系統(tǒng)需求、應(yīng)用軟件需求；II類平臺項(xiàng)目為硬件平臺類項(xiàng)目，用于管理嵌入式軟件中跟硬件強(qiáng)相關(guān)的基礎(chǔ)軟件需求，如傳感器信號采集處理、驅(qū)動信號輸出等；III類項(xiàng)目為應(yīng)用匹配類項(xiàng)目，用于管理嵌入式軟件集成以及應(yīng)用匹配類項(xiàng)目所特有的無法與其他項(xiàng)目共享的特殊需求，如專用領(lǐng)域的接口需求。所有對終端客戶所交付的軟件版本均由第III類項(xiàng)目：應(yīng)用匹配類項(xiàng)目進(jìn)行集成和發(fā)布。

2 平臺項(xiàng)目需求架構(gòu)

基于平臺項(xiàng)目的架構(gòu)，建立平臺項(xiàng)目的需求架構(gòu)，并建立各層級需求的追溯跟蹤關(guān)系。各應(yīng)用匹配類項(xiàng)目共用的客戶需求以及系統(tǒng)需求在I類平臺項(xiàng)目中建立并維護(hù)，平臺類的硬件需求和基礎(chǔ)軟件需求在II類硬件平臺類項(xiàng)目中建立并維護(hù)。II類平臺項(xiàng)目中的硬件需求和基礎(chǔ)軟件需求直接與I類項(xiàng)目的系統(tǒng)需求建立追溯管理，II類項(xiàng)目中不再需要重復(fù)維護(hù)客戶需求與系統(tǒng)需求。I類項(xiàng)目與II類項(xiàng)目的需求追溯關(guān)系如圖2所示。

通過I類、II類項(xiàng)目的需求管理架構(gòu)，實(shí)現(xiàn)平臺化的客戶需求、系統(tǒng)需求、軟/硬件需求管理；并通過ALM系統(tǒng)中已有的建立需求追溯關(guān)系的功能建立客戶需求、系統(tǒng)需求、軟硬件需求（應(yīng)用軟件需求、基礎(chǔ)軟件需求、硬件需求）的雙向追溯關(guān)系。通過規(guī)劃的平臺項(xiàng)目架構(gòu)（圖1所示）和平臺項(xiàng)目需求架構(gòu)（圖2所示）及ALM系統(tǒng)的需求追溯管理功能，可實(shí)現(xiàn)各層級需求條目本身的平臺化管理目的。

圖2：I、II類項(xiàng)目需求追溯關(guān)系圖

從I類平臺的應(yīng)用軟件需求、II類平臺的基礎(chǔ)軟件需求到設(shè)計(jì)實(shí)現(xiàn)的追溯，則可以通過ALM系統(tǒng)中現(xiàn)有的Task任務(wù)功能實(shí)現(xiàn)，通過Task任務(wù)，可追溯每一條軟件需求影響到的模型或代碼，以及模型或代碼的具體版本。需求與設(shè)計(jì)實(shí)現(xiàn)的追溯關(guān)系如3所示。

通過圖1的平臺項(xiàng)目需求架構(gòu)和圖3需求與設(shè)計(jì)實(shí)現(xiàn)追溯關(guān)系，可以實(shí)現(xiàn)客戶需求-系統(tǒng)需求-軟件需求-模型、代碼版本的逐級追溯關(guān)系，實(shí)現(xiàn)需求開發(fā)全過程可追溯。

圖3：需求與設(shè)計(jì)實(shí)現(xiàn)追溯關(guān)系圖

在實(shí)現(xiàn)需求全過程可追溯的基礎(chǔ)上，針對不同層級的平臺需求，開發(fā)相應(yīng)層級的測試用例，通過ALM系統(tǒng)中需求條目的關(guān)聯(lián)測試用例的功能建立測試用例與需求條目之間的追溯關(guān)系，確保所有的需求條目均有相應(yīng)的測試用例進(jìn)行覆蓋，實(shí)現(xiàn)需求條目與測試用例的雙向追溯，如圖4所示。

圖4：需求與測試用例追溯關(guān)系圖

至此，基于PTC公司的ALM系統(tǒng)并借助于該解決方案，可實(shí)現(xiàn)平臺化的需求開發(fā)、設(shè)計(jì)、實(shí)現(xiàn)、測試用例的管理和雙向追溯，可有效避免同一需求、測試用例在多個項(xiàng)目中重復(fù)管理。

3 平臺化項(xiàng)目缺陷、變更架構(gòu)

針對同一缺陷、變更需要在多個項(xiàng)目中解決或者實(shí)現(xiàn)的場景，可采取類似于平臺化需求管理的解決方案，將缺陷、變更在平臺項(xiàng)目中進(jìn)行全生命周期管理，直接在平臺項(xiàng)目中建立缺陷、變更，并在平臺項(xiàng)目中建立缺陷、變更與需求的追溯關(guān)系，通過Task在平臺項(xiàng)目中追溯缺陷或者變更解決過程。具體解決方案如圖5所示。

圖5：缺陷、變更平臺化管理方案

針對軟件版本測試發(fā)現(xiàn)的缺陷，或者在軟件開發(fā)過程中發(fā)生的變更，若該缺陷或變更屬于應(yīng)用軟件平臺類項(xiàng)目，則直接在第I類項(xiàng)目下創(chuàng)建該缺陷或變更，通過缺陷或變更的關(guān)聯(lián)（spawned by）功能建立缺陷或變更與需求條目的追溯關(guān)系；若該缺陷或變更屬于硬件平臺類項(xiàng)目，則直接在第II類項(xiàng)目下創(chuàng)建該缺陷或變更，并建立與需求條目的追溯關(guān)系。同時，針對缺陷和變更，也需要分別設(shè)計(jì)測試用例，通過缺陷或變更的關(guān)聯(lián)（validated by）功能建立測試用例與缺陷或變更的追溯關(guān)系，通過平臺化項(xiàng)目缺陷、變更架構(gòu)實(shí)現(xiàn)缺陷、變更與需求的追溯管理以及缺陷、變更與測試用例的追溯管理。

4 平臺化項(xiàng)目集成管理

基于本文1-3章節(jié)搭建的平臺化項(xiàng)目和平臺化需求架構(gòu)、平臺化項(xiàng)目缺陷、變更架構(gòu)的管理方案，可以實(shí)現(xiàn)平臺化需求、缺陷、變更管理，采用平臺化方式管理需求、缺陷、變更從創(chuàng)建、分析、實(shí)現(xiàn)（模型、代碼）、測試用例的全過程追溯管理。

應(yīng)用匹配類項(xiàng)目通過第III類項(xiàng)目進(jìn)行管理，根據(jù)應(yīng)用匹配的具體需要，從第I類項(xiàng)目和第II類項(xiàng)目中關(guān)聯(lián)項(xiàng)目自身所需要的需求、缺陷、變更，基于項(xiàng)目所選取的需求、缺陷、變更開展集成。應(yīng)用匹配類項(xiàng)目與平臺類項(xiàng)目的關(guān)聯(lián)關(guān)系如圖6所示。

圖6：應(yīng)用匹配類項(xiàng)目集成管理

在該種模式下，同一需求、缺陷、變更可以同時被不同的應(yīng)用匹配類項(xiàng)目進(jìn)行關(guān)聯(lián)集成，也可以同時被同一應(yīng)用匹配類項(xiàng)目的不同軟件版本進(jìn)行關(guān)聯(lián)集成；且所關(guān)聯(lián)需求、缺陷、變更的測試用例也可以直接在軟件版本中直觀體現(xiàn)；不同的應(yīng)用匹配類項(xiàng)目，可以基于應(yīng)用匹配的具體情況，在關(guān)聯(lián)的測試用例的基礎(chǔ)上進(jìn)行有目的性的篩選，開展不同程度的測試驗(yàn)證工作，并針對不同項(xiàng)目的軟件版本分別顯示相應(yīng)測試用例的運(yùn)行結(jié)果，實(shí)現(xiàn)基于項(xiàng)目和軟件版本的測試驗(yàn)證過程的精準(zhǔn)跟蹤；基于該方案，完全可以實(shí)現(xiàn)同一需求、缺陷、變更在不同項(xiàng)目間以及同一項(xiàng)目的不同軟件版本的移植復(fù)用。

5 結(jié)束語

本文針對同一需求、缺陷、變更被多項(xiàng)目復(fù)用的場景，給出了平臺化的解決方案，搭建了平臺化項(xiàng)目的架構(gòu)，并基于該平臺化項(xiàng)目架構(gòu)，給出了平臺化需求、缺陷、變更管理的方案，基于該解決方案，可以實(shí)現(xiàn)需求、缺陷、變更的平臺化管理；并針對該解決方案給出了工具的實(shí)現(xiàn)方案，確保該解決方案可以在工具中予以實(shí)現(xiàn)。