文聰敏 劉乃新
摘 ?要:針對當(dāng)前軟件需求變更日漸增多但管理效率低下的現(xiàn)狀,基于大數(shù)據(jù)平臺計算能力強(qiáng)、成本低的特點建立需求自動同步更新管理系統(tǒng),并從總體設(shè)計、需求數(shù)據(jù)庫以及數(shù)據(jù)處理流程三個方面對其進(jìn)行了闡述。該系統(tǒng)通過將繁雜需求進(jìn)行標(biāo)簽化處理建立起需求數(shù)據(jù)庫,通過總庫分庫存儲模式完善數(shù)據(jù)處理機(jī)制,有效優(yōu)化需求建立、測試和變更流程,實現(xiàn)需求的快速查找和自動更新同步,同時減少資源投入和資源浪費,從而加快項目的研發(fā)進(jìn)程。
關(guān)鍵詞:需求管理;數(shù)據(jù)處理;需求變更;軟件生命周期
中圖分類號:TP311 ? ? 文獻(xiàn)標(biāo)識碼:A ? 文章編號:2096-4706(2023)14-0007-05
Design and Research of Requirements Automatic Synchronous Update Management System Based on Big Data Platform
WEN Congmin1, LIU Naixin2
(1.Guangdong Polytechnic of Science and Technology, Zhuhai ?519090, China;
2.TCL Cloud Internet Corporation Technology Co., Ltd., Huizhou ?516001, China)
Abstract: In view of the current situation of increasing software demand changes and low management efficiency, based on the characteristics of strong computing power and low cost of the big data platform, an automatic demand synchronization update management system is established, and it is described from three aspects of overall design, demand database and data processing flow. The system establishes a requirement database by labeling complex requirements, and improves the data processing mechanism through the overall database and sub database storage mode. It effectively optimizes the process of requirement establishment, testing, and change, achieving rapid search and automatic update synchronization of requirements, while reducing resource investment and waste, thereby accelerating the research and development process of the project.
Keywords: requirement management; data processing; requirement change; software life cycle
0 ?引 ?言
隨著現(xiàn)代信息技術(shù)的不斷發(fā)展,需求管理作為軟件生命周期的關(guān)鍵階段,伴隨系統(tǒng)規(guī)劃和開發(fā)的全過程,一直是研究的熱點方向[1]。Standish Group的調(diào)查表明,軟件需求正不斷增多且趨于復(fù)雜化。因此,準(zhǔn)確高效管理日新月異的需求是軟件成敗的關(guān)鍵[2,3]。
1 ?研究背景
當(dāng)前企業(yè)使用的主流需求管理系統(tǒng)主要存在以下局限性[4,5]:
1)基于單機(jī)的服務(wù)器運營成本高,長期工作后積累的大量數(shù)據(jù)經(jīng)常導(dǎo)致卡頓、宕機(jī)等問題。
2)需求間關(guān)系基于系統(tǒng)分配的ID,關(guān)聯(lián)查找困難。
3)需求同步完全依靠人工,存在大量沖突的需求。
4)測試情況總結(jié)依賴人力,且缺乏數(shù)學(xué)依據(jù)。
針對以上缺陷,利用大數(shù)據(jù)平臺組建成本較低、計算能力優(yōu)越的特點[6],建立基于需求內(nèi)容的需求庫,并完善其數(shù)據(jù)處理機(jī)制,使需求實現(xiàn)快速查找和自動更新同步,減少在需求管理中的資源投入和由于需求沖突導(dǎo)致的測試資源浪費,從而加快項目研發(fā)進(jìn)程。
2 ?系統(tǒng)總體設(shè)計
基于大數(shù)據(jù)平臺的需求自動同步更新管理系統(tǒng)主要針對需求的建立、實現(xiàn)和測試進(jìn)行管理,其中系統(tǒng)數(shù)據(jù)庫涉及需求、測試用例和功能測試時產(chǎn)生的問題等對象,并包含需求文檔、測試log和系統(tǒng)運行中所產(chǎn)生的所有數(shù)據(jù)。下面將從項目流程、系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)模塊和數(shù)據(jù)處理四個方面對系統(tǒng)的總體設(shè)計進(jìn)行闡述。
2.1 ?項目流程
從項目研發(fā)角度看,項目流程主要分為立項、需求建立、需求開發(fā)、測試驗證、問題追蹤和項目總結(jié)六大模塊[7]。系統(tǒng)在傳統(tǒng)項目流程基礎(chǔ)上額外增加變更同步模塊和數(shù)據(jù)分析模塊,如圖1所示。改進(jìn)后的系統(tǒng)充分考慮需求的更新同步,即使在項目進(jìn)行中有數(shù)據(jù)更新,其相關(guān)數(shù)據(jù)也會在系統(tǒng)中同步;加入測試數(shù)據(jù)的分析和對測試策略和計劃的評估預(yù)測,即在系統(tǒng)中,建立起關(guān)系型數(shù)據(jù)庫,其數(shù)據(jù)的輸出都帶有詳細(xì)的特性標(biāo)簽,這樣大大增強(qiáng)了缺陷分析的數(shù)據(jù)維度,減少不同場景下可能出現(xiàn)的數(shù)據(jù)模型與場景不匹配而導(dǎo)致分析結(jié)果不準(zhǔn)確的情況。
2.2 ?系統(tǒng)結(jié)構(gòu)
系統(tǒng)主要分為:數(shù)據(jù)采集層、數(shù)據(jù)處理和存儲層、應(yīng)用層,如圖2所示。最底層是數(shù)據(jù)采集層,負(fù)責(zé)對需求庫所有源數(shù)據(jù)的錄入采集,源數(shù)據(jù)主要有需求表格、用戶留言、用戶操作日志、需求附件、問題日志等一系列用以描述和幫助研發(fā)人員理解需求、修復(fù)問題的數(shù)據(jù)文件以及各個用戶在應(yīng)用層與系統(tǒng)交互時產(chǎn)生的各類數(shù)據(jù)。第二層的數(shù)據(jù)處理和存儲層,負(fù)責(zé)對數(shù)據(jù)清洗、轉(zhuǎn)換、入庫和存儲,從上層應(yīng)用層或底層數(shù)據(jù)采集層得來的數(shù)據(jù)都需要經(jīng)過第二層的處理,然后以既定的格式存儲在數(shù)據(jù)庫中。上層的應(yīng)用層則是需求管理系統(tǒng)軟件,是用戶跟整個系統(tǒng)交互的窗口,用于實現(xiàn)項目的流程、圖像化UI、數(shù)據(jù)統(tǒng)計和查詢等功能。
圖2 ?系統(tǒng)功能框架圖
2.3 ?數(shù)據(jù)模塊
從數(shù)據(jù)模塊角度看,改進(jìn)后系統(tǒng)的數(shù)據(jù)模塊類型包括需求、測試用例和缺陷問題以及存儲這些數(shù)據(jù)的關(guān)系型數(shù)據(jù)庫、規(guī)范化測試流程和處理流程工作流等,各模塊共同建立起測試工作相關(guān)環(huán)節(jié)完整的處理流程,使工作流自動在不同角色間流動,從而提高不同角色共同完成測試工作的效率,而且由于數(shù)據(jù)存儲和處理能力的提升,數(shù)據(jù)處理和分析更加透明和透徹,為質(zhì)量管控提供了更多依據(jù)。
2.4 ?數(shù)據(jù)處理
從需求管理系統(tǒng)的數(shù)據(jù)處理模塊角度看,如圖3所示,處理層次包括源數(shù)據(jù)、數(shù)據(jù)采集、數(shù)據(jù)處理、數(shù)據(jù)分析建模和應(yīng)用服務(wù);其任務(wù)棧分成了任務(wù)調(diào)度管理、接口管理、集群管理、訂閱管理、元數(shù)據(jù)管理、權(quán)限管理和應(yīng)用服務(wù)管理。相較于傳統(tǒng)需求管理系統(tǒng),改進(jìn)后的系統(tǒng)增加了對數(shù)據(jù)的統(tǒng)計和建模,輸出能夠作為測試計劃和測試執(zhí)行指導(dǎo)的數(shù)據(jù),相比舊系統(tǒng),使測試過程更加的規(guī)范,大大降低了項目的測試風(fēng)險。
3 ?需求數(shù)據(jù)庫設(shè)計
3.1 ?需求點關(guān)系標(biāo)簽建立
建立需求數(shù)據(jù)庫首先需要對需求源進(jìn)行錄入。以通信類公司為例,運營商客戶所提供的需求源復(fù)雜多樣。針對非圖片或視頻類的需求,使用內(nèi)容提取的技術(shù)分離需求,圖片類的則需要處理形成形式統(tǒng)一的文件審核錄入。例如,針對秘魯無線緊急警報(Wireless Emergency Alerts, WEA)的需求,其原始需求文件是一份詳細(xì)描述其小區(qū)廣播(Cell Broadcast, CB)的文檔。對于秘魯WEA需求,在將其錄入需求管理系統(tǒng)前需設(shè)置“秘魯”“CB”“WEA”“ALL”(需求屬于秘魯?shù)姆梢?,所以針對其國家?nèi)所有的運營商,以“ALL”代表)等標(biāo)簽。此后把文檔中描述的預(yù)期行為轉(zhuǎn)化成需求點或者測試場景,將這些分好類的信息按照特定的順序進(jìn)行排列,然后在系統(tǒng)中設(shè)置讀取的順序標(biāo)簽,即可將這些需求順利錄入系統(tǒng)。為更好地分類和快速查找需求,除了添加描述中的關(guān)鍵字,還會在錄入系統(tǒng)后加入層層相互獨立的標(biāo)簽,如圖4所示。
圖4 ?WEA需求點的關(guān)系型特征示意圖
3.2 ?需求關(guān)系庫表建立
經(jīng)過上述過程的數(shù)據(jù)錄入,各需求點已建立初步關(guān)系標(biāo)簽。系統(tǒng)在獲取需求數(shù)據(jù)后,首先進(jìn)行數(shù)據(jù)清洗,提取標(biāo)簽、特征、描述等有用信息,過濾用于標(biāo)記、排序等的多余信息或重復(fù)的信息,去除結(jié)構(gòu)化數(shù)據(jù)。之后進(jìn)行數(shù)據(jù)轉(zhuǎn)換,加入關(guān)系嵌套,建立起關(guān)系庫表,并最終將其存放在分布式文件系統(tǒng)中。
過濾后的數(shù)據(jù)即可視為數(shù)據(jù)列表,系統(tǒng)將數(shù)據(jù)列表進(jìn)行編碼、類型和格式等的轉(zhuǎn)換,方便系統(tǒng)存放和讀取。為了數(shù)據(jù)的有序存儲和快速查找,數(shù)據(jù)庫建立起分類完善的關(guān)系模型,對每個特征有詳細(xì)的標(biāo)簽嵌套。每個標(biāo)簽被視為數(shù)據(jù)列表中的一個特征值,這些特征值組建起數(shù)據(jù)庫的關(guān)系模型。為了需求管理系統(tǒng)易用性考慮,需求文件在被導(dǎo)入系統(tǒng)后,系統(tǒng)即會生成導(dǎo)入結(jié)果的報告并立即生成需求列表。這些需求在系統(tǒng)中以數(shù)據(jù)塊的形式存儲,每個數(shù)據(jù)塊被存放在不同的DataNode中?;贖DFS分布式虛擬文件系統(tǒng),虛擬系統(tǒng)中的文件與其實際的存儲數(shù)據(jù)呈現(xiàn)映射關(guān)系,映射表被存儲在NameNode中。參考如圖5所示的數(shù)據(jù)庫文件訪問流程[8],當(dāng)用戶查詢需求時,需先訪問NameNode,獲取目標(biāo)數(shù)據(jù)的數(shù)據(jù)塊位置列表,根據(jù)該列表即可獲取所需數(shù)據(jù),即查詢到目標(biāo)需求。
3.3 ?需求項目庫功能分類
當(dāng)需求文件被拆分入庫后,每個需求點或需求場景均被轉(zhuǎn)換成了具有獨立編號的需求,以保證每項需求都能在需求庫中找到且開發(fā)和測試的工作能被追溯到,從而實現(xiàn)研發(fā)工作有跡可循,流程化和標(biāo)準(zhǔn)化。系統(tǒng)基于關(guān)系型數(shù)據(jù)庫中需求添加的特征標(biāo)簽,利用MapReduce模型快速篩選統(tǒng)計出所需數(shù)據(jù)。該過程只需動用存儲目標(biāo)數(shù)據(jù)的少數(shù)數(shù)據(jù)節(jié)點,任務(wù)被分解為若干個小任務(wù)分配到相應(yīng)物理機(jī)上,處理效率提升可觀。
圖5 ?數(shù)據(jù)庫文件訪問流程
此外,每個項目分庫的需求經(jīng)過功能分類,與測試小組職責(zé)進(jìn)行關(guān)聯(lián),當(dāng)需求被開發(fā)完畢后,系統(tǒng)會生成對應(yīng)版本的需求報告表格,自動將測試任務(wù)分配到對應(yīng)測試小組以待驗證。既可以保證開發(fā)好的需求迅速得到驗證,也節(jié)省了需求分類和任務(wù)分組的時間成本,大大提高需求測試效率。
4 ?數(shù)據(jù)處理流程
4.1 ?需求處理流程
系統(tǒng)數(shù)據(jù)庫中基于Hadoop大數(shù)據(jù)平臺建立如圖6所示的基本功能需求總庫和針對各個運營商的需求總庫。前者針對各種未做定制的基本功能測試項,后者則包含各個客戶運營商的需求項。當(dāng)某一項目立項后,在其產(chǎn)品功能支持情況和目標(biāo)出貨上市客戶運營商計劃下,從總庫中復(fù)用相應(yīng)的需求到針對項目而建立的項目分庫中來。
從圖6可知,每個項目分庫的需求均從總庫中導(dǎo)出復(fù)用。同時,分庫需求不僅與總庫需求相獨立,不同分庫需求也相互獨立。實際工作中多個項目常常同時進(jìn)行,涉及立項、開發(fā)、測試、交付等多個工作模塊用戶,過程數(shù)據(jù)龐大。改進(jìn)方案采用基于Hadoop大數(shù)據(jù)平臺的生態(tài)模式,利用其分布式文件系統(tǒng)對服務(wù)器硬件要求不高以及MapReduce等軟硬件結(jié)合快速處理海量數(shù)據(jù)算法的設(shè)計優(yōu)勢[9],不僅能降低服務(wù)器搭建成本,也極大優(yōu)化需求庫數(shù)據(jù)批量處理效率。
項目分庫中的每一個需求都與其所對應(yīng)的總庫中的需求有映射關(guān)系,用戶可以分別通過二者的鏈接入口快速查看到另一方需求。當(dāng)測試工程師在實際的測試工作中發(fā)現(xiàn)需求有更改時,可在項目總結(jié)時提出總庫需求修改申請,評審?fù)ㄟ^后需求修改的結(jié)果也會反饋在總庫中。涉及需求總庫和項目分庫需求變更信息同步的流程如圖7所示。
在實際測試工作中,測試工程師需要根據(jù)需求測試情況對結(jié)果進(jìn)行記錄,分庫中需求基本狀態(tài)包括:新建(項目建立后將總庫中的需求復(fù)用至項目分庫的狀態(tài))、待開發(fā)(將分庫需求轉(zhuǎn)給對應(yīng)的開發(fā)人員進(jìn)行開發(fā)的狀態(tài))、待驗證(開發(fā)人員將功能開發(fā)完畢后轉(zhuǎn)給測試組進(jìn)行驗證的狀態(tài))、已驗證(當(dāng)測試人員驗證后發(fā)現(xiàn)需求未被成功實現(xiàn),用來記錄失敗結(jié)果,提問題讓開發(fā)人員重新開發(fā)的狀態(tài))、關(guān)閉(驗證通過后進(jìn)行關(guān)閉的狀態(tài))和有變更(針對上一段中提到的總庫需求有變更時待處理的特殊狀態(tài)),以及刪除(由于需求已經(jīng)不適用現(xiàn)用的系統(tǒng)或由于需求變更導(dǎo)致需求的失效而不再生效的狀態(tài)),分庫需求的處理流程如圖8所示。
4.2 ?缺陷處理流程
為了反映缺陷Issue的修復(fù)狀態(tài),對處于不同工作階段的Issue進(jìn)行狀態(tài)特性標(biāo)記,同需求狀態(tài)類似,Issue狀態(tài)可分為新建、待修復(fù)(開發(fā)工程師確認(rèn)此Issue需要修復(fù),將其狀態(tài)更改為待修復(fù))、待釋放(修復(fù)Issue的代碼必須被下一個正式版本收錄)、待驗證(測試工程師在代碼生效的新版本上驗證Issue是否被修復(fù))、驗證完畢(表明Issue已被驗證,若通過,則等待有權(quán)限的用戶關(guān)閉Issue;若不通過則又進(jìn)入待修復(fù)狀態(tài)繼續(xù)修復(fù))、關(guān)閉、刪除和掛起(對于暫時不合適修改且不影響用戶正常使用的Issue,做掛起處理,后續(xù)若確定需要修改,可重新進(jìn)入待修復(fù)狀態(tài))。其處理流程如圖9所示。
5 ?結(jié) ?論
基于大數(shù)據(jù)平臺的需求自動同步更新管理系統(tǒng)在降低龐大數(shù)據(jù)管理服務(wù)器搭建和維護(hù)費用的同時,將繁雜需求標(biāo)簽化處理,使得分類統(tǒng)計更加便捷。同時建立總庫分庫存儲模式的需求數(shù)據(jù)庫,方便業(yè)務(wù)層面的需求管理和快速導(dǎo)入。此外,優(yōu)化后的需求變更流程大大降低多項目并行需求變更帶來的風(fēng)險,實現(xiàn)需求變更快速同步,保證軟件開發(fā)效率,提升企業(yè)經(jīng)濟(jì)效益。
參考文獻(xiàn):
[1] SONG W Y. Requirement management for product-service systems:Status review and future trends [J].Computers in Industry,2017,85:11-22.
[2] HOOD C,WIEDEMANN S,F(xiàn)ICHTINGER S,et al. Requirements Management:The Interface Between Requirements Development and All Other Systems Engineering Processes [M].[S.I.]:Springer,2007.
[3] KHAIRUDDIN S N,SARLAN A,AHMAD R. Challenges in Requirement Management Process:An Overview [C]//2021 International Conference on Computer & Information Sciences (ICCOINS).Kuching:IEEE,2021:120-124.
[4] 孫乾.軟件需求管理系統(tǒng)的設(shè)計與分析 [D].長春:吉林大學(xué),2015.
[5] 陳志.一個數(shù)據(jù)需求管理系統(tǒng)的設(shè)計與實現(xiàn) [D].武漢:華中科技大學(xué),2020.
[6] 宮夏屹,李伯虎,柴旭東,等.大數(shù)據(jù)平臺技術(shù)綜述 [J].系統(tǒng)仿真學(xué)報,2014,26(3):489-496.
[7] 李錦,張玲玲.大型軟件項目管理的流程設(shè)計及分析 [J].科技管理研究,2010,30(15):204-206.
[8] 湯姆·懷特.Hadoop權(quán)威指南 [M].北京:清華大學(xué)出版社,2015.
[9] 李成華,張新訪,金海,等.MapReduce:新型的分布式并行計算編程模型 [J].計算機(jī)工程與科學(xué),2011,33(3):129-135.
作者簡介:文聰敏(1994—),女,漢族,湖南益陽
人,助教,碩士研究生,研究方向:計算機(jī)技術(shù)。