基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法及裝置的制造方法
【專利摘要】本發(fā)明提供一種基于FOG數(shù)據(jù)的修復(fù)bug和變更的控制方法及裝置，通過自動或半自動的方式確定bug對象和變更對象，并對基于FOG數(shù)據(jù)的bug對象和變更對象進行處理，處理完成后自動提供相關(guān)檢查單對處理結(jié)果進行驗證，并對驗證后的變更對象進行影響性分析，決定變更結(jié)束后自動為變更對象重新生成相關(guān)的工程文檔，完成軟件開發(fā)過程中bug修復(fù)和配置項或基線的變更。解決了現(xiàn)有技術(shù)中存在的bug和變更的對象粒度過粗、現(xiàn)有方法與配置庫分離、手動驗證確認(rèn)等缺點。
【專利說明】
基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法及裝置
技術(shù)領(lǐng)域
[0001]本發(fā)明涉及計算機軟件程序開發(fā)的技術(shù)領(lǐng)域，特別涉及一種軟件開發(fā)中修復(fù)bug和變更控制的方法及裝置。
【背景技術(shù)】
[0002]在軟件工程中，關(guān)于bug的bug報告和變更的控制是軟件開發(fā)過程中極其重要的一項活動，直接關(guān)系到軟件產(chǎn)品的質(zhì)量和可復(fù)現(xiàn)性。bug是指:不符合軟件開發(fā)計劃和標(biāo)準(zhǔn)的過程、軟件編制開發(fā)的過程中輸出的缺陷、軟件產(chǎn)品的異常行為。在民用機載軟件研制領(lǐng)域，權(quán)威的安全標(biāo)準(zhǔn)中明確提出了對于bug報告、變更控制和變更評審的要求。
[0003]bug報告、追蹤和糾正措施的目的是:記錄不符合軟件開發(fā)計劃和標(biāo)準(zhǔn)的過程、記錄軟件編制開發(fā)的過程中輸出的缺陷、記錄軟件產(chǎn)品的異常行為，并確保這些bug得到解決。如果bug報告要求對軟件產(chǎn)品或軟件編制開發(fā)過程中的輸出采取糾正措施，那么應(yīng)觸發(fā)變更控制的步驟。
[0004]變更控制的目的是在軟件編制開發(fā)過程內(nèi)實現(xiàn)變更的記錄、評價、判斷和批準(zhǔn)。由于bug報告的處理可能導(dǎo)致配置項或基線的變更，所以bug報告與變更控制密切相關(guān)。同時，變更控制步驟也需要變更評審步驟的支持。變更評審確保了 bug修復(fù)及其變更能獲得評估、判斷，合格的更改得以完成，并按軟件開發(fā)編制過程定義的bug報告和變更控制方法向受影響的軟件開發(fā)編制過程提供反饋信息。
[0005]現(xiàn)有技術(shù)存在的缺點有:
[0006]1.bug修復(fù)和變更的處理對象粒度過粗?，F(xiàn)有方法的bug修復(fù)或變更的對象是文檔級別，而發(fā)生bug的可能僅是文檔中的某一行，過粗的粒度不利于bug的精確定位分析、影響分析、處理和驗證等一系列工作；
[0007]2.與配置庫分離?，F(xiàn)有方法或工具，一般只能關(guān)注bug和變更本身的狀態(tài)，而配置庫的管理則另有一套方法或工具，因此對于bug和其變更的管理工具無法對配置項或基線的狀態(tài)、版本進行有效跟蹤，這一方面的工作仍需要人工手動進行，可能引入一致性、完整性等bug。例如:在變更處理時，變更處理人錯誤地修改了無需變更的配置項(如配置項在開發(fā)庫中，無需配置管理員出庫)，由于對于bug及其變更管理工具無法自動檢測和記錄配置庫的變更，這一錯誤可能無法在變更驗證時被發(fā)現(xiàn)；
[0008]3.手動確認(rèn)文檔一致性。對于一些文檔共有的共性bug，可能需要多人在多個配置項(文檔)中修改，并在變更驗證時由人工進行一致性檢查，費時費力，并可能引入錯誤；
[0009]4.分散的變更處理控制。在變更影響性分析后，對某個單一配置項(文檔)的更改可能轉(zhuǎn)為對多個階段多個配置項的更改。這就需要為不同團隊的多名人員產(chǎn)生復(fù)數(shù)的衍生變更申請單來跟蹤變更的實施情況。這樣的做法可能為變更評審以及變更后處理的工作帶來不必要的麻煩。

【發(fā)明內(nèi)容】

[0010]本發(fā)明提供一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法及裝置，bug修復(fù)針對開發(fā)庫中的配置項及過程bug，去除了無需進行的影響性分析任務(wù)，簡化傳統(tǒng)的問題報告、變更控制及變更評審流程；變更控制針對受控庫和產(chǎn)品庫中的配置項，實施完整的問題報告、變更控制及變更評審流程。以解決現(xiàn)有技術(shù)中存在的bug和變更的對象粒度過粗、現(xiàn)有方法與配置庫分離、手動驗證確認(rèn)等缺點。
[0011]為解決上述技術(shù)bug，本發(fā)明提供的基于FOG數(shù)據(jù)的基線設(shè)置系統(tǒng)及方法是這樣實現(xiàn)的:
[0012]—種基于FOG數(shù)據(jù)的修復(fù)bug修復(fù)和變更控制的裝置，在用于軟件開發(fā)過程中進行bug的修復(fù)、和配置項或基線的變更，其特征在于，包括:
[0013]FOG數(shù)據(jù)形成模塊，將已編寫的數(shù)據(jù)形成FOG數(shù)據(jù)；
[0014]bug發(fā)現(xiàn)檢測模塊，自動在軟件編寫開發(fā)活動過程中提出問題并自動識別bug的來源；
[0015]變更提出發(fā)起模塊，相應(yīng)自動或手動發(fā)起的變更請求，并自動用于變更
【申請人】提出變更申請并確定變更來源；
[0016]審核模塊，用于分析并確定bug對象或變更對象；
[0017]處理模塊，用于對已確定的所述bug對象或所述變更對象進行處理；
[0018]驗證模塊，自動按照提供相關(guān)檢查單對處理結(jié)果進行驗證；
[0019]驗證后變更處理模塊，對驗證后的所述變更對象進行影響性分析并在決定變更結(jié)束后自動為所述變更對象重新生成相關(guān)的工程文檔。
[0020]所述審核模塊審核所述變更對象時，提供半自動化的變更影響性分析，自動追蹤出所述變更對象相關(guān)聯(lián)的上下級FOG數(shù)據(jù)。
[0021 ] 所述審核模塊審核所述bug對象時，支持半自動化的bug對象識別，bug來源會被自動添加至所述bug對象。
[0022]所述審核模塊審核所述bug對象時，自動限制只選擇開發(fā)庫內(nèi)配置項作為所述bug對象；審核所述變更對象時，自動限制選擇受控庫和產(chǎn)品庫內(nèi)配置項作為所述變更對象。
[0023]所述bug對象和所述變更對象均以FOG數(shù)據(jù)為單位。
[0024]—種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法一種基于FOG數(shù)據(jù)的bug修復(fù)和變更控制方法，在軟件開發(fā)過程中進行bug的修復(fù)、配置項或基線的變更用于軟件編寫開發(fā)活動中bug修復(fù)和配置項或基線變更，其特征在于，包括:
[0025]FOG數(shù)據(jù)形成步驟，將已編寫的數(shù)據(jù)形成FOG數(shù)據(jù)；
[0026]bug發(fā)現(xiàn)檢測步驟，自動識別bug的來源；
[0027]自動在軟件編寫開發(fā)活動過程中提出問題并自動識別bug來源；
[0028]變更提出發(fā)起步驟，相應(yīng)自動或手動發(fā)起的變更請求，并自動確定變更來源；
[0029]用于變更
【申請人】提出變更申請并確定變更來源；
[0030]審核步驟，用于分析并確定bug對象或變更對象用于分析并確定bug對象或變更對象；
[0031]處理步驟，用于對已確定的所述bug對象或所述變更對象進行處理；用于對已確定所述bug對象或所述變更對象進行處理；
[0032]驗證步驟，自動按照檢查單對處理結(jié)果進行驗證；
[0033]自動提供相關(guān)檢查單對處理結(jié)果進行驗證。
[0034]驗證后變更處理步驟，驗證后變更處理模塊，對驗證后的所述變更對象進行影響性分析并在決定變更結(jié)束后自動為所述變更對象重新生成相關(guān)的工程文檔。對驗證后的所述變更對象進行影響性分析并在決定變更結(jié)束后自動為所述變更對象重新生成相關(guān)的工程文檔。
[0035]所述審核步驟審核所述變更對象時，提供半自動化的變更影響性分析，自動追蹤出所述變更對象相關(guān)聯(lián)的上下級FOG數(shù)據(jù)。
[0036]所述審核步驟審核所述bug對象時，支持半自動化的bug對象識別，bug來源會被自動添加至所述bug對象。
[0037]所述審核步驟審核所述bug對象時，自動限制只選擇開發(fā)庫內(nèi)配置項作為所述bug對象；審核所述變更對象時，自動限制選擇受控庫和產(chǎn)品庫內(nèi)配置項作為所述變更對象。
[0038]所述bug對象和所述變更對象均以FOG數(shù)據(jù)為單位。
[0039]本發(fā)明的積極效果在于:
[0040]1.對于bug修復(fù)或變更的對象粒度較細(xì)。以FOG數(shù)據(jù)作為管理粒度，可使bug修復(fù)或變更的來源和對象定位更加精確，提高審核、處理及驗證等一系列工作的效率，減少錯誤發(fā)生的概率。
[0041]2.與配置庫整合。該裝置與軟件項目的配置庫相整合，能自動獲取bug或變更對象的配置狀態(tài)，并自動完成配置項的出入庫操作，使得幾乎整個bug或變更流程(過程bug的處理除外)都可以在該裝置內(nèi)完成。因此，杜絕了 bug修復(fù)或變更處理過程中，錯誤修改bug或變更對象以外的配置項的可能性，同時也便于bug修復(fù)和變更驗證步驟的展開。
[0042]3.保證配置項一致性。以FOG數(shù)據(jù)作為bug修復(fù)或變更的對象，使得原本針對多個工程文檔共有bug的修改工作，轉(zhuǎn)為對這些文檔共用的FOG數(shù)據(jù)的修改，杜絕了多個文檔不一致的可能性。
[0043]4.集中的變更處理控制。該裝置自動為每個變更處理驅(qū)動出變更處理任務(wù)，并跟蹤每個任務(wù)的執(zhí)行狀態(tài)。即無需產(chǎn)生任何衍生的變更申請，而是在一個變更報告中統(tǒng)一控制所有的變更處理活動，便于對軟件項目的追蹤變更狀態(tài)的控制。
【附圖說明】
[0044]圖1為基于FOG數(shù)據(jù)的bug修復(fù)和變更控制裝置結(jié)構(gòu)框圖；
[0045]圖2為基于FOG數(shù)據(jù)的產(chǎn)品bug修復(fù)流程圖；
[0046]圖3為基于FOG數(shù)據(jù)的過程bug修復(fù)流程圖；
[0047]圖4為基于FOG數(shù)據(jù)的變更控制流程圖。
具體實施例
[0048]本發(fā)明所稱FOG數(shù)據(jù)是指具有獨立語義的最小數(shù)據(jù)單位。本發(fā)明提出的基于FOG數(shù)據(jù)的bug修復(fù)和變更的控制方法及裝置，包括兩個相對獨立的過程(bug修復(fù)及變更控制)，兩個過程都分別包含了 bug報告、變更控制及變更評審的部分或全部步驟。
[0049]為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面結(jié)合附圖和實施方式對本發(fā)明作進一步的詳細(xì)說明。
[0050]如圖1，本發(fā)明所提供的裝置包括，F(xiàn)OG數(shù)據(jù)形成模塊11，將已編寫的數(shù)據(jù)形成FOG數(shù)據(jù)。bug檢測模塊12，在編寫、核查、評審、及測試等活動中，都可以通過該裝置檢測出bug。此時，bug來源將被自動識別。具體地:在軟件編制開發(fā)過程中，bug的來源即當(dāng)前編寫中的FOG數(shù)據(jù)；核查步驟中，bug來源即當(dāng)前核查不通過的核查對象；評審步驟中，bug來源即當(dāng)前的評審對象；測試步驟中，bug來源即當(dāng)前執(zhí)行的測試規(guī)程。變更發(fā)起模塊13，可自動或由變更
【申請人】發(fā)起新的變更申請，獲取或填寫變更的優(yōu)先級、嚴(yán)重性、變更描述等必要信息，確定變更來源，同時也可自動或手動選擇變更對象；審核模塊14，用于分析并確定bug對象或變更對象；處理模塊15，用于對已確定的bug對象或變更對象進行處理；驗證模塊16，自動按照相關(guān)檢查單對處理結(jié)果進行驗證。驗證后變更處理模塊17，對驗證后的變更對象進行影響性分析，并在決定變更結(jié)束后自動為變更對象重新生成相關(guān)的工程文檔。
[0051]其中，bug修復(fù)包括兩種bug類型:產(chǎn)品bug和過程bug。下面針對這兩種類型的處理流程做具體的闡述。
[0052]產(chǎn)品bug修復(fù)流程針對所有處于開發(fā)庫中的配置項的問題報告、變更控制和核查。如圖2所示:
[0053]I)確定bug來源步驟21包括自動確定22步驟和手動確定步驟23。
[0054]a)自動確定步驟22
[0055]在編寫、核查、評審、及測試等活動中，都可以通過該裝置檢測出bug，自動限制只可選擇開發(fā)庫內(nèi)配置項作為bug的對象。此時，bug來源將自動識別。例如:編寫步驟中，bug來源即當(dāng)前編寫中的FOG數(shù)據(jù)；核查步驟中，bug來源即當(dāng)前核查不通過的核查對象；評審步驟中，bug來源即當(dāng)前的評審對象；測試步驟中，bug來源即當(dāng)前執(zhí)行的測試規(guī)程。
[0056]b)手動確定步驟23
[0057]通過該裝置，也可以在任何具體活動以外，手動輸入檢測出的bug。此時，需手動指定bug的來源。
[0058]2)審核 bug 步驟 24
[0059]首先，該裝置通過bug分析確定bug是否可接受。若不接受，則拒絕bug，將問題報告狀態(tài)設(shè)置為“已關(guān)閉”;若接受，則進入確認(rèn)bug對象步驟25 ;
[0060]3)確認(rèn)bug對象步驟25
[0061]對bug原因進行分析以確定bug的對象。該裝置支持自動化的bug對象識別功能。對由核查和評審步驟中檢測出的bug，bug來源會被自動識別并添加至bug對象。檢測出的bug也可在分析后，被自行添加/刪除bug對象。bug對象可以是新增的FOG數(shù)據(jù)(即解決bug需要新增FOG數(shù)據(jù))，也可以是當(dāng)前已存在配置庫中的FOG數(shù)據(jù)(即解決bug需要修改或刪除已有FOG數(shù)據(jù));bug對象的選取形式以樹形結(jié)構(gòu)展現(xiàn)，該樹形結(jié)構(gòu)僅包含所有在開發(fā)庫中的配置項。
[0062]該裝置確定bug在當(dāng)前階段是否可以解決，若暫時無法解決或不必解決，則進入延遲審核狀態(tài)，問題報告的狀態(tài)設(shè)置為“已延遲”;若需要解決，則設(shè)定進行處理和驗證的相關(guān)信息，問題報告的狀態(tài)設(shè)置為“已分配”，并進入處理bug步驟26 ;在延遲審核的任意時間點，該裝置都可以根據(jù)用戶需求啟動是否開始處理處于“已延遲”狀態(tài)的bug。若審核步驟通過，則轉(zhuǎn)入處理bug步驟26，問題報告的狀態(tài)設(shè)置為“已分配”;若不通過，則轉(zhuǎn)入審核bug步驟24，重新進行審核bug步驟；
[0063]4)處理 bug 步驟 26
[0064]支持直接新增、修改或刪除bug對象，同時自動完成相關(guān)配置項的配置庫設(shè)置。通過該裝置對每個bug對象的相關(guān)FOG數(shù)據(jù)進行添加、修改和刪除處理步驟。進行bug處理步驟中可能遇到一些需要上級(項目負(fù)責(zé)人)關(guān)注或參與的bug處理步驟，此時可進入bug上報步驟27。bug對象的處理工作必須全部執(zhí)行后，才能進入完成任務(wù)狀態(tài)，處理完成的問題報告狀態(tài)設(shè)置為“已完成”，從而進入驗證bug處理步驟28。
[0065]具體地，對于需新增的bug對象，需編寫新的FOG數(shù)據(jù)，該裝置自動給出對應(yīng)的bug對象(F0G數(shù)據(jù))編寫頁面的鏈接，可直接在該裝置中完成編寫工作，并通過手動操作設(shè)置關(guān)聯(lián)追蹤關(guān)系，新增后的bug對象被標(biāo)記為“已添加”;對于需修改的bug對象，該裝置自動給出對應(yīng)的bug對象(F0G數(shù)據(jù))修改頁面的鏈接，可直接在該裝置中完成修改工作，修改后的bug對象被標(biāo)記為“已修改”;對于需刪除的bug對象，該裝置給出對應(yīng)bug對象(F0G數(shù)據(jù))頁面的鏈接，可直接在該裝置中完成刪除工作，刪除后的bug對象被標(biāo)記為“已刪除”。
[0066]5) bug上報步驟27 (可選)
[0067]bug上報步驟27為可選流程，使用該上報bug功能，后續(xù)該bug只要發(fā)生狀態(tài)變化，該裝置就將會自動發(fā)送郵件告知項目負(fù)責(zé)人。
[0068]6)驗證bug處理步驟28
[0069]對bug處理開展驗證步驟，同時該裝置自動提供相關(guān)檢查單，從而完成驗證工作；若驗證通過，則關(guān)閉bug，問題報告狀態(tài)設(shè)置為“已關(guān)閉”;若驗證不通過，則返回處理bug步驟26重新處理bug。
[0070]bug驗證完成后或者在審核bug步驟24中沒有被接受的bug則進入關(guān)閉bug步驟29對bug進行關(guān)閉。
[0071 ] 過程bug修復(fù)流程針對項目過程的bug的跟蹤、解決和處理流程，而不涉及具體配置庫內(nèi)的配置項。如圖3所示:
[0072]I)確定bug來源步驟31
[0073]一般在質(zhì)量保證過程中，可以通過該裝置對過程檢測出bug，并自動或手動來設(shè)定bug的來源。
[0074]2)審核 bug 步驟 32
[0075]首先進行分析bug步驟，確定該bug是否可以接受，此時也可修改bug的來源。若不接受，則拒絕bug，將bug問題報告的狀態(tài)設(shè)置為“已關(guān)閉”;若接受，則進入審核判斷；
[0076]判斷bug在當(dāng)前階段是否可以解決，若暫時無法解決或不必解決，則進入延遲審核，bug問題報告的狀態(tài)設(shè)置為“已延遲”；若需要進行高層級人員的審核，則進入提交高層審核步驟33 ;若需要解決，則進行處理和驗證步驟，bug問題報告的狀態(tài)設(shè)置為“已分配”，并進入到處理bug步驟34。
[0077]在延遲審核任意時間點，該裝置都可以根據(jù)用戶需求開始處理處于“已延遲”狀態(tài)的bug。若審核步驟通過，則轉(zhuǎn)入處理bug步驟34，問題報告的狀態(tài)設(shè)置為“已分配”;若不通過，則轉(zhuǎn)入提交高層審核步驟33，重新進行審核bug步驟；
[0078]3)提交高層審核步驟33
[0079]如有必要，可設(shè)置項目高層(一般為項目經(jīng)理)對過程bug進行審核，若高層審核通過，則轉(zhuǎn)入處理bug步驟34，問題報告的狀態(tài)設(shè)置為“已分配”;若不通過，則關(guān)閉bug，問題報告的狀態(tài)設(shè)置為“已關(guān)閉”；
[0080]4)處理 bug 步驟 34
[0081]過程bug的處理工作一般在該裝置外進行。該裝置會驅(qū)動處理bug的任務(wù)程序，提示在該裝置外解決bug，并在該裝置內(nèi)輸入處理的描述信息，提交完成處理bug步驟后，轉(zhuǎn)入驗證bug處理步驟35 ；
[0082]5)上報bug步驟36 (可選)
[0083]使用上報bug功能，后續(xù)該bug只要發(fā)生狀態(tài)變化，該裝置就會通過發(fā)送郵件來告知相關(guān)的項目負(fù)責(zé)人；
[0084]6)驗證bug處理步驟35
[0085]對bug的處理開展驗證工作，同時該裝置自動提供相關(guān)檢查單，幫助完成驗證處理；若驗證通過，問題報告的狀態(tài)設(shè)置為“已關(guān)閉”;若驗證不通過，則返回處理bug步驟34重新進行處理bug。
[0086]bug驗證完成后或者在審核bug步驟32中沒有被接受的bug則進入關(guān)閉bug步驟37對bug進行關(guān)閉。
[0087]變更控制流程針對所有處于受控庫和產(chǎn)品庫中的配置項的bug報告、變更控制和核查。如圖4所示:
[0088]I)提出變更步驟401
[0089]在有需要時，變更
【申請人】可以提出新的變更請求，通過輸入變更的優(yōu)先級、嚴(yán)重性、變更描述等必要信息，確定變更的來源，同時也可選擇變更的對象(即FOG數(shù)據(jù))，本發(fā)明自動限制只可選擇受控庫和產(chǎn)品庫內(nèi)配置項作為變更對象；若選擇了變更對象，則需配置該變更對象的處理及驗證步驟。
[0090]2)審核變更步驟402
[0091]a)確認(rèn)變更對象步驟403
[0092]在分析變更后，可自行添加/刪除變更對象。變更對象可以是新增的FOG數(shù)據(jù)(即變更需要添加新的FOG數(shù)據(jù))，也可以是當(dāng)前已存在配置庫中的FOG數(shù)據(jù)(即變更需要修改或刪除已有FOG數(shù)據(jù))。每條變更對象都需分別配置處理及驗證步驟。變更對象的選取形式以樹形結(jié)構(gòu)展現(xiàn)，該樹形結(jié)構(gòu)僅包含在受控庫和產(chǎn)品庫中的配置項。此外，該裝置自動限制變更對象唯一屬于某一條變更，因此樹形結(jié)構(gòu)中僅會展現(xiàn)所有尚未作為其它變更的變更對象的FOG數(shù)據(jù)，任何屬于其它變更的FOG數(shù)據(jù)將無法被再次選取(即在樹形結(jié)構(gòu)中隱藏)。
[0093]b)影響性分析步驟404
[0094]該裝置為變更的影響性分析提供自動化的輔助判斷方案。對每一條變更對象，該裝置能自動追蹤出其關(guān)聯(lián)的上下級FOG數(shù)據(jù)，并進行展示。用戶可手動決定是否需要將關(guān)聯(lián)FOG數(shù)據(jù)添加為新的變更對象。同時，也可由用戶將其它非關(guān)聯(lián)的對象添加為新的變更對象。用戶可輸入影響性分析結(jié)果，作為是否批準(zhǔn)變更的參考依據(jù)。影響性分析結(jié)束后，變更報告的狀態(tài)將設(shè)置為“已影響性分析”。
[0095]c)批準(zhǔn)變更步驟405
[0096]根據(jù)影響性分析描述，該裝置接收是否批準(zhǔn)該變更申請的決定，并可手動輸入審核意見。若拒絕變更，則變更報告的狀態(tài)設(shè)置為“已關(guān)閉”，變更流程結(jié)束；若批準(zhǔn)，則變更報告的狀態(tài)設(shè)置為“已審批”，該裝置為每個用戶驅(qū)動出一個變更處理程序，并進入處理變更步驟45。
[0097]3)處理變更步驟406
[0098]處理變更時，支持直接新增、修改或刪除變更對象，同時自動完成相關(guān)配置項的出入庫配置處理。通過該裝置對每個變更對象，即FOG數(shù)據(jù)進行添加、修改和刪除的處理。多個不同的變更對象可能對應(yīng)多個不同變更處理程序。每個變更處理程序需執(zhí)行相對應(yīng)的所有變更對象的處理后，才能夠提交完成任務(wù)；當(dāng)所有變更處理完成后，該裝置自動將變更報告的狀態(tài)設(shè)置為“已完成”，并進入驗證變更處理步驟407
[0099]對于需新增的變更對象，該裝置自動給出對應(yīng)的變更對象(F0G數(shù)據(jù))編寫頁面的鏈接，可直接在該裝置中完成編寫工作，并通過手動操作設(shè)置關(guān)聯(lián)追蹤關(guān)系，新增后的變更對象被標(biāo)記為“已添加”;對于需修改的變更對象，該裝置給出對應(yīng)變更對象(即FOG數(shù)據(jù))修改頁面的鏈接，可直接由該裝置中完成修改工作，修改后的變更對象被標(biāo)記為“已修改”；對于需刪除的變更對象，該裝置給出對應(yīng)變更對象(即FOG數(shù)據(jù))頁面的鏈接，可直接在該裝置中完成刪除工作，刪除后的變更對象被標(biāo)記為“已刪除”。
[0100]4)驗證變更處理步驟407
[0101]對變更處理開展驗證工作，同時該裝置自動提供相關(guān)檢查單，幫助完成驗證工作；未通過驗證的變更，應(yīng)在驗證結(jié)果中輸入詳細(xì)的描述，無論驗證結(jié)果如何都進入再次進行影響性分析步驟408。驗證結(jié)果提交后，變更報告的狀態(tài)設(shè)置為“已驗證”。
[0102]5)再次影響性分析步驟408
[0103]參考驗證結(jié)果和變更處理，再次進行影響性分析步驟，其方法與影響性分析步驟404相同。影響性分析結(jié)束后，變更報告的狀態(tài)設(shè)置為“已影響性分析”。
[0104]6) CCB 決定步驟 409
[0105]根據(jù)影響性分析描述和驗證結(jié)果，由CCB(變更控制委員會)判斷給出決定，并可輸入審核意見。若需要再次進行變更處理，則轉(zhuǎn)入處理變更步驟407，變更報告的狀態(tài)設(shè)置為“已審批”;若接受變更，則轉(zhuǎn)入變更后處理步驟410。
[0106]7)變更后處理步驟410
[0107]在判斷決定變更后，該裝置自動為作為變更對象的FOG數(shù)據(jù)重新生成相關(guān)的工程文檔。如果當(dāng)前變更對象的FOG數(shù)據(jù)已被納入基線，則自動重新建立基線并替換原有基線。
[0108]處理完成后，進入關(guān)閉變更步驟411，將變更報告的狀態(tài)設(shè)置為“已關(guān)閉”，變更報告管理流程結(jié)束。
[0109]由以上實施例可見，本發(fā)明針對民用機載軟件研制的適航要求和實際需要，將問題報告、變更控制和變更評審的控制融合并整理為相對獨立的基于FOG數(shù)據(jù)的修復(fù)bug或變更處理流程。解決了現(xiàn)有技術(shù)中存在的修復(fù)bug和變更的對象粒度過粗、現(xiàn)有方法與配置庫分離、手動驗證確認(rèn)等缺點。
[0110]雖然通過實施例描繪了本發(fā)明，本領(lǐng)域普通技術(shù)人員知道，本發(fā)明并不局限于上述特定的實施方式，本領(lǐng)域技術(shù)人員可以在權(quán)利要求的范圍內(nèi)做出各種變形或修改，這并不影響本發(fā)明的實質(zhì)內(nèi)容。
【主權(quán)項】
1.一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的裝置，在軟件開發(fā)過程中進行bug的修復(fù)、配置項或基線的變更，其特征在于，包括: FOG數(shù)據(jù)形成模塊，將已編寫的數(shù)據(jù)形成FOG數(shù)據(jù)； bug檢測模塊，自動識別bug的來源； 變更發(fā)起模塊，相應(yīng)自動或手動發(fā)起的變更請求，并自動確定變更來源； 審核模塊，用于分析并確定bug對象或變更對象； 處理模塊，用于對已確定的所述bug對象或所述變更對象進行處理； 驗證模塊，自動按照檢查單對處理結(jié)果進行驗證； 驗證后變更處理模塊，對驗證后的所述變更對象進行影響性分析并在決定變更結(jié)束后自動為所述變更對象重新生成相關(guān)的工程文檔。2.根據(jù)權(quán)利要求1所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的裝置，其特征在于，所述審核模塊審核所述變更對象時，提供自動化的變更影響性分析，自動追蹤出所述變更對象相關(guān)聯(lián)的上下級FOG數(shù)據(jù)。3.根據(jù)權(quán)利要求1所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的裝置，其特征在于，所述審核模塊審核所述bug對象時，支持自動化的bug對象識別，bug來源會被自動添加至所述bug對象。4.根據(jù)權(quán)利要求1所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的裝置，其特征在于，所述審核模塊審核所述bug對象時，自動限制只選擇開發(fā)庫內(nèi)配置項作為所述bug對象；審核所述變更對象時，自動限制選擇受控庫和產(chǎn)品庫內(nèi)配置項作為所述變更對象。5.根據(jù)權(quán)利要求1至4任一所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的裝置，其特征在于，所述bug對象和所述變更對象均以FOG數(shù)據(jù)為單位。6.—種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法，在軟件開發(fā)過程中進行bug的修復(fù)、配置項或基線的變更，其特征在于，包括: FOG數(shù)據(jù)形成步驟，將已編寫的數(shù)據(jù)形成FOG數(shù)據(jù)； bug檢測步驟，自動識別bug的來源； 變更發(fā)起步驟，相應(yīng)自動或手動發(fā)起的變更請求，并自動確定變更來源； 審核步驟，用于分析并確定bug對象或變更對象； 處理步驟，用于對已確定的所述bug對象或所述變更對象進行處理； 驗證步驟，自動按照檢查單對處理結(jié)果進行驗證； 驗證后變更處理步驟，驗證后變更處理模塊，對驗證后的所述變更對象進行影響性分析并在決定變更結(jié)束后自動為所述變更對象重新生成相關(guān)的工程文檔。7.根據(jù)權(quán)利要求6所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法，其特征在于，所述審核步驟審核所述變更對象時，提供自動化的變更影響性分析，自動追蹤出所述變更對象相關(guān)聯(lián)的上下級FOG數(shù)據(jù)。8.根據(jù)權(quán)利要求6所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法，其特征在于，所述審核步驟審核所述bug對象時，支持自動化的bug對象識別，bug來源會被自動添加至所述bug對象。9.根據(jù)權(quán)利要求6所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法，其特征在于，所述審核步驟審核所述bug對象時，自動限制只選擇開發(fā)庫內(nèi)配置項作為所述bug對象；審核所述變更對象時，自動限制選擇受控庫和產(chǎn)品庫內(nèi)配置項作為所述變更對象。10.根據(jù)權(quán)利要求6至9任一所述的一種基于FOG數(shù)據(jù)的修復(fù)bug和變更控制的方法，其特征在于，所述bug對象和所述變更對象均以FOG數(shù)據(jù)為單位。
【文檔編號】G06F11/36GK106033391SQ201510111574
【公開日】2016年10月19日
【申請日】2015年3月13日
【發(fā)明人】王云明
【申請人】上海愛韋訊信息技術(shù)有限公司