王 蕊，張碧肖，黃 婧

（國(guó)家軟件產(chǎn)品質(zhì)量監(jiān)督檢驗(yàn)中心（江蘇），江蘇 南京 210012）

1 總體狀況

1.1 質(zhì)量發(fā)展現(xiàn)狀

我國(guó)的軟件智能化行業(yè)正處于快速發(fā)展期，尤其是東南一帶經(jīng)濟(jì)發(fā)達(dá)省份的軟件行業(yè)收入已占全國(guó)軟件行業(yè)收入的絕大部分。隨著客戶質(zhì)量意識(shí)的不斷提升和政府部門信息化工程建設(shè)力度不斷加大，對(duì)于軟件智能化產(chǎn)品質(zhì)量第三方檢測(cè)服務(wù)的需求也越來(lái)越大，對(duì)軟件智能化產(chǎn)品質(zhì)量的要求也越來(lái)越高。

1.2 檢驗(yàn)檢測(cè)基本情況

第三方檢測(cè)機(jī)構(gòu)所承擔(dān)的檢測(cè)任務(wù)主要來(lái)源于政府和企業(yè)的委托檢驗(yàn)。以2018年三季度為例，我中心共檢測(cè)軟件產(chǎn)品246批次，檢測(cè)企業(yè)數(shù)129家，全部為委托檢驗(yàn)類型，主要提供實(shí)測(cè)數(shù)據(jù)。弱電智能化產(chǎn)品5批次，檢測(cè)企業(yè)數(shù)4家，批次合格率80%。

1.3 檢測(cè)情況分析

軟件產(chǎn)品檢測(cè)項(xiàng)目主要包括功能性、性能效率、兼容性、易用性、可靠性、信息安全性、維護(hù)性、可移植性等質(zhì)量特性，在委托檢驗(yàn)中，檢測(cè)重點(diǎn)通常集中在軟件功能性、性能效率和信息安全性三個(gè)方面。由于軟件產(chǎn)品屬于非傳統(tǒng)行業(yè)，客戶定制化特點(diǎn)非常明顯，在通常用于驗(yàn)收測(cè)試的委托檢驗(yàn)中，通常會(huì)進(jìn)行2-3輪檢測(cè)，在首輪檢測(cè)中發(fā)現(xiàn)的問(wèn)題，在與開(kāi)發(fā)方和委托方溝通后，經(jīng)過(guò)進(jìn)一步修改，更新版本，在后續(xù)檢測(cè)中將問(wèn)題修正。軟件產(chǎn)品的委托檢驗(yàn)，通常只提供實(shí)測(cè)結(jié)果，不提供判定結(jié)論。弱電智能化產(chǎn)品主要檢測(cè)項(xiàng)目有綜合布線、智能樓宇、機(jī)房檢測(cè)、信息網(wǎng)絡(luò)等。

軟件產(chǎn)品委托檢驗(yàn)首輪測(cè)試中，共在50個(gè)軟件樣品中發(fā)現(xiàn)8940個(gè)問(wèn)題。按照嚴(yán)重等級(jí)劃分，其中S2級(jí)問(wèn)題1444個(gè)，占比16.2%；S3級(jí)問(wèn)題7377個(gè)，占比82.5%，S4級(jí)和S5級(jí)問(wèn)題119個(gè)，占比1.3%。缺陷等級(jí)定義見(jiàn)圖1：

圖1 缺陷等級(jí)定義

依據(jù)GB/T 25000.10-2016國(guó)家標(biāo)準(zhǔn)，軟件產(chǎn)品質(zhì)量模型見(jiàn)圖2：

圖2 軟件產(chǎn)品質(zhì)量模型

按發(fā)現(xiàn)問(wèn)題所屬質(zhì)量特性統(tǒng)計(jì)，功能性問(wèn)題372個(gè)，占比4.2%；性能效率問(wèn)題19個(gè)，占比0.2%；信息安全性問(wèn)題8547個(gè)，占比95.5%；其他質(zhì)量特性委托檢測(cè)較少，共發(fā)現(xiàn)問(wèn)題2個(gè)，占比忽略不計(jì)。

首輪測(cè)試后，測(cè)試人員將結(jié)果通知到開(kāi)發(fā)方，經(jīng)過(guò)修改后再進(jìn)行二輪甚至三輪測(cè)試，復(fù)測(cè)后問(wèn)題數(shù)量呈現(xiàn)明顯收斂趨勢(shì)。

2 軟件產(chǎn)品質(zhì)量問(wèn)題產(chǎn)生的原因分析

造成軟件缺陷的主要原因，主要有軟件本身、團(tuán)隊(duì)工作和技術(shù)問(wèn)題等，也與軟件產(chǎn)品的特點(diǎn)和開(kāi)發(fā)過(guò)程有密切關(guān)系：

2.1 軟件本身

⊙ 需求不明確，設(shè)計(jì)方案偏離客戶需求，導(dǎo)致產(chǎn)品功能不符合客戶預(yù)期；

⊙ 系統(tǒng)結(jié)構(gòu)復(fù)雜，系統(tǒng)維護(hù)困難；

⊙ 對(duì)程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮欠缺，漏掉邊界條件，造成容量或邊界錯(cuò)誤；

⊙ 實(shí)時(shí)應(yīng)用要進(jìn)行精心設(shè)計(jì)和技術(shù)處理以保證精確的時(shí)間同步，否則容易引起時(shí)間不協(xié)調(diào)問(wèn)題；

⊙ 沒(méi)有考慮系統(tǒng)崩潰后的自我恢復(fù)或數(shù)據(jù)異地備份、災(zāi)難恢復(fù)等問(wèn)題，導(dǎo)致系統(tǒng)存在安全隱患；

⊙ 系統(tǒng)運(yùn)行環(huán)境復(fù)雜，計(jì)算機(jī)環(huán)境千變?nèi)f化，用戶的各種操作方式或各種不同的輸入數(shù)據(jù)，容易引起一些特定用戶環(huán)境下的問(wèn)題；

⊙ 系統(tǒng)應(yīng)用中突發(fā)數(shù)據(jù)量引起的性能負(fù)載問(wèn)題；

⊙ 通信端口多、存取和加密手段的矛盾性等，會(huì)造成系統(tǒng)的安全性或適用性等問(wèn)題；

⊙ 新技術(shù)的采用或涉及系統(tǒng)兼容性問(wèn)題，事先沒(méi)有考慮到。

2.2 團(tuán)隊(duì)工作

（1）用戶溝通方面，需求分析時(shí)對(duì)客戶的需求理解出現(xiàn)偏差

要改進(jìn)這個(gè)問(wèn)題可以從以下四個(gè)方面展開(kāi)：一是使用項(xiàng)目管理信息系統(tǒng)進(jìn)行輔助溝通，例如：PMIS。二是建立溝通基礎(chǔ)結(jié)構(gòu)：①工具：電話、傳真、電郵、PMIS；視頻會(huì)議系統(tǒng)、文件管理系統(tǒng)、字處理程序。②技術(shù)：指導(dǎo)方針、文檔模板、會(huì)議基本原則和程序；決策過(guò)程、解決問(wèn)題方法、沖突解決和協(xié)商技術(shù)。③原則：提供開(kāi)放式對(duì)話環(huán)境；使用“率直交流”和遵守公認(rèn)工作道德規(guī)范。三是使用項(xiàng)目溝通模板。四是制定項(xiàng)目溝通基本原則。

（2）不同階段的開(kāi)發(fā)人員相互理解不一致。

（3）設(shè)計(jì)或編程上的一些假定依賴關(guān)系，相關(guān)人員沒(méi)有充分溝通。

（4）項(xiàng)目成員技術(shù)水平差異導(dǎo)致代碼質(zhì)量參差不齊。

2.3 技術(shù)問(wèn)題

（1）算法錯(cuò)誤：在給定條件下沒(méi)能給出正確或準(zhǔn)確的結(jié)果。

（2）語(yǔ)法錯(cuò)誤：對(duì)于編譯性語(yǔ)言程序，編譯器可以發(fā)現(xiàn)這類問(wèn)題；但對(duì)于解釋性語(yǔ)言程序，只能在測(cè)試運(yùn)行時(shí)發(fā)現(xiàn)。

（3）計(jì)算和精度問(wèn)題：計(jì)算的結(jié)果沒(méi)有滿足所需要的精度。

（4）系統(tǒng)結(jié)構(gòu)不合理、算法選擇不科學(xué)，造成系統(tǒng)性能低下。

（5）接口參數(shù)傳遞不匹配，導(dǎo)致模塊集成出現(xiàn)問(wèn)題。

2.4 項(xiàng)目管理問(wèn)題

（1）質(zhì)量意識(shí)不足，沒(méi)有盡早介入測(cè)試，或測(cè)試不充分。

（2）開(kāi)發(fā)周期短，需求分析、設(shè)計(jì)、編程、測(cè)試等各項(xiàng)工作不能完全按照流程進(jìn)行，同時(shí)給開(kāi)發(fā)人員造成太大壓力，引起一些人為錯(cuò)誤。

（3）開(kāi)發(fā)流程不完善，存在太多隨機(jī)性，缺乏嚴(yán)謹(jǐn)?shù)膬?nèi)審或評(píng)審機(jī)制，容易產(chǎn)生問(wèn)題。

（4）文檔不完善，風(fēng)險(xiǎn)估計(jì)不足等。

3 措施與建議

（1）制訂周詳?shù)能浖_(kāi)發(fā)計(jì)劃。要進(jìn)行調(diào)查研究，理解工作任務(wù)、工作范圍和所付的代價(jià)，提交可行性研究報(bào)告，編制詳盡的軟件開(kāi)發(fā)計(jì)劃。

（2）軟件需求分析，對(duì)用戶需求進(jìn)行具體分析和細(xì)化，并用軟件需求規(guī)格說(shuō)明書(shū)表達(dá)出來(lái)，作為用戶和軟件人員之間的共同約定。在進(jìn)行需求調(diào)研時(shí)，不但要更多的獲取功能或者業(yè)務(wù)需求，對(duì)于客戶在軟件系統(tǒng)性能上的需求，也應(yīng)進(jìn)行詳盡的獲取。這些需求在實(shí)現(xiàn)過(guò)程中應(yīng)具體體現(xiàn)在開(kāi)發(fā)和測(cè)試等文檔中。針對(duì)此類性能需求的深入分析，往往能較好的規(guī)避軟件系統(tǒng)瓶頸，解決此問(wèn)題，需要對(duì)需求進(jìn)行全面有效的管理，可以按照以下辦法進(jìn)行管理：

①成立需求分析小組，任務(wù)是得到各方簽字認(rèn)可的需求說(shuō)明書(shū)。

②準(zhǔn)備文檔和幫助客戶了解相關(guān)技術(shù)和項(xiàng)目管理知識(shí)。

③訪談客戶：了解劃分客戶所有用戶類型及潛在類型；選擇每類用戶代表，對(duì)其訪談和調(diào)研；需求分析人員對(duì)收集的需求進(jìn)行分析和整理；需求分析人員將需求以適當(dāng)方式呈交用戶和開(kāi)發(fā)方。

④需求分析：圖形表示方式描述整理結(jié)構(gòu)，包括邊界和接口；通過(guò)原型、頁(yè)面流等方式向用戶提供可視化界面，用戶提出評(píng)價(jià)；系統(tǒng)可行性分析，需求實(shí)現(xiàn)的技術(shù)可行性、環(huán)境、費(fèi)用、時(shí)間分析；模型描述系統(tǒng)功能項(xiàng)、數(shù)據(jù)實(shí)體、外部實(shí)體、實(shí)體相互關(guān)系、實(shí)體狀態(tài)轉(zhuǎn)換。

⑤需求說(shuō)明書(shū)編寫。

⑥需求驗(yàn)證和評(píng)審：確保說(shuō)明書(shū)準(zhǔn)確、完整變大必要的質(zhì)量特點(diǎn)；用戶參與，可外部專家評(píng)審；一般評(píng)審：用戶評(píng)審、同行評(píng)審。

⑦需求定稿建立基線。

⑧管理和控制需求變更：手段：變更控制委員會(huì)、需求變更流程；委員會(huì)與項(xiàng)目風(fēng)險(xiǎn)承擔(dān)著協(xié)商。

尤其是針對(duì)變更的需求，在面對(duì)變更需求時(shí)，應(yīng)該堅(jiān)持以下原則：謹(jǐn)慎對(duì)待變更請(qǐng)求，盡量控制變更；高度重視需求變更；簽署變更控制的協(xié)議；在基線的基礎(chǔ)上，做好變更實(shí)施；應(yīng)有變更控制工具的支持；把項(xiàng)目變化融入項(xiàng)目計(jì)劃；及時(shí)發(fā)布變更信息。

（3）軟件架構(gòu)設(shè)計(jì)決定系統(tǒng)的模塊結(jié)構(gòu)，應(yīng)清晰給出模塊的相互調(diào)用關(guān)系、模塊間傳遞的數(shù)據(jù)以及每個(gè)模塊的功能說(shuō)明，定義數(shù)據(jù)結(jié)構(gòu)，軟件體系架構(gòu)是為軟件系統(tǒng)提供結(jié)構(gòu)、行為和屬性的高級(jí)抽象。在結(jié)構(gòu)建模時(shí)應(yīng)遵從最直觀的結(jié)構(gòu)、以特殊問(wèn)題為目的建立框架、對(duì)機(jī)構(gòu)和框架進(jìn)行補(bǔ)充，演化“大顆?！毙袨?、研究步驟和過(guò)程、一組功能構(gòu)建，下層向上層提供服務(wù)。（4）軟件編碼應(yīng)符合規(guī)范要求。

（5）軟件測(cè)試應(yīng)盡早并全面介入，及時(shí)發(fā)現(xiàn)并修改缺陷，降低開(kāi)發(fā)成本和周期。

（6）軟件維護(hù)，經(jīng)過(guò)測(cè)試并應(yīng)用的軟件仍可能有錯(cuò)，用戶需求和系統(tǒng)環(huán)境也會(huì)隨時(shí)發(fā)生變化，開(kāi)發(fā)時(shí)應(yīng)考慮軟件可維護(hù)性。

（7）非功能性的需求很多時(shí)候需要考慮硬件以及網(wǎng)絡(luò)方面的成本。針對(duì)這些問(wèn)題需要與客戶進(jìn)行良好溝通，設(shè)定合理的非功能性目標(biāo)，做好成本與質(zhì)量的平衡。

（8）制訂完善的測(cè)試方案并貫徹落實(shí)，它直接影響軟件的質(zhì)量。