林 郁 曹 琦 郭天文 陳曉杜

(龍巖煙草工業(yè)有限責(zé)任公司 福建 龍巖 364000)

FMEA在A企業(yè)軟件質(zhì)量改進(jìn)中的應(yīng)用

林 郁 曹 琦 郭天文 陳曉杜

(龍巖煙草工業(yè)有限責(zé)任公司 福建 龍巖 364000)

在傳統(tǒng)的軟件測試中，重點在于測試軟件的業(yè)務(wù)功能是否實現(xiàn)，系統(tǒng)的性能是否符合要求，而常忽略了軟件系統(tǒng)失效情況下導(dǎo)致的產(chǎn)品質(zhì)量風(fēng)險。為杜絕此類風(fēng)險，需充分挖掘軟件的各類隱含需求，從而加強(qiáng)對軟件缺陷的管理。本文通過對一個偶發(fā)的軟件失效導(dǎo)致的質(zhì)量問題事故進(jìn)行思考，提出將潛在失效模式FMEA應(yīng)用于軟件開發(fā)測試，預(yù)防軟件失效風(fēng)險，確保產(chǎn)品質(zhì)量的方法。實際應(yīng)用案例表明使用FMEA后，A企業(yè)因軟件質(zhì)量失效模式引起的產(chǎn)品質(zhì)量隱患改進(jìn)效果顯著。

FMEA;軟件質(zhì)量;隱含需求

一、引言

2017年4月某企業(yè)生產(chǎn)過程中A牌號中間物料被誤做B牌號中間物料進(jìn)行包裝生產(chǎn)，引發(fā)質(zhì)量事故。該事故發(fā)生的原因是該企業(yè)自動化物流系統(tǒng)中間物料箱的RFID芯片上一批次的信息未清除，而新批次的信息未正確寫入，導(dǎo)致箱內(nèi)實際物料與系統(tǒng)的物料信息不匹配，從而引發(fā)用料錯誤的質(zhì)量事故。此次事故中，物流系統(tǒng)軟件在過去數(shù)年中運行正常，系統(tǒng)的穩(wěn)定性、效率等性能符合要求。但一次偶發(fā)的事故卻暴露了設(shè)計時邏輯中存在的漏洞，RFID信息采用覆蓋寫入的形式，而非使用后擦除，使用時寫入的方式。雖是單一事件，但也凸顯出過去設(shè)計中重點關(guān)注業(yè)務(wù)功能實現(xiàn)和系統(tǒng)性能的要求，而忽略了系統(tǒng)軟件失效模式下對產(chǎn)品所造成的質(zhì)量風(fēng)險。因此如果在軟件的設(shè)計中融入失效模式及其影響分析，實現(xiàn)基于產(chǎn)品質(zhì)量的軟件風(fēng)險把控，是提高軟件質(zhì)量一個值得思考的問題。

二、軟件質(zhì)量要求

ISO9126的信息技術(shù)標(biāo)準(zhǔn)中對軟件質(zhì)量的定義是:與軟件產(chǎn)品滿足明確或隱含需求的能力有關(guān)的特征和特性的總和［1，2］。這些特征包括可靠性、可用性、易用性、效率、維護(hù)性和可移植性［3］。該定義對軟件質(zhì)量不僅提出滿足明確需求，即各項業(yè)務(wù)需求，也強(qiáng)調(diào)了有隱含需求，即各項業(yè)務(wù)需求以外確保軟件和產(chǎn)品質(zhì)量的需求。這些隱含的需求可能是一些連業(yè)務(wù)需求方也無法明確提出的需求，但這些隱含的需求可能使軟件在特定條件下出現(xiàn)失效問題，導(dǎo)致一些不可預(yù)測的質(zhì)量風(fēng)險。

為了發(fā)掘隱含需求，降低軟件失效的風(fēng)險，軟件領(lǐng)域從上世紀(jì)80年代開始，一直努力探索軟件過程控制和質(zhì)量管理問題。先后建立了CMM［4］、CMMI［5］和 ISO9000［6］等質(zhì)量管理標(biāo)準(zhǔn)，同時國內(nèi)外學(xué)者也建立了故障樹分析［7］、PDCA［8］軟件質(zhì)量改進(jìn)等方法。在眾多方法中，潛在的失效模式及后果分析 (Failure Mode and Effects Analysis，簡稱

FMEA)為近年來提出的一種確定潛在失效模式及其原因的分析方法，常用于產(chǎn)品設(shè)計或生產(chǎn)工藝真正實現(xiàn)之前發(fā)現(xiàn)產(chǎn)品的弱點［9～10］，同樣適合于發(fā)現(xiàn)軟件中存在的缺陷［11］。

三、潛在的失效模式及后果分析FMEA

FMEA是一種分析系統(tǒng)中每一產(chǎn)品所有可能產(chǎn)生的故障模式及其對系統(tǒng)造成的所有可能影響，并按每一個故障模式的嚴(yán)重程度，檢測難易程度以及發(fā)生頻度予以分類的一種歸納分析方法［12］。FMEA的核心在于“事前的預(yù)防措施”，它通過使用系統(tǒng)分析、頭腦風(fēng)暴等方法對產(chǎn)品的設(shè)計、開發(fā)、生產(chǎn)等過程進(jìn)行失效模式及影響分析，幫助設(shè)計人員發(fā)現(xiàn)軟件產(chǎn)品中潛在的質(zhì)量問題 (或稱為失效模式)，分析、評價這些潛在的質(zhì)量問題發(fā)生的可能性及其帶來的影響和嚴(yán)重程度，以便及時采取有效的預(yù)防措施，從而降低產(chǎn)品投入市場后的失效風(fēng)險。

FMEA質(zhì)量管理模型如有如下特點［11］:

1.提出了質(zhì)量目標(biāo)，以確保質(zhì)量為軟件產(chǎn)品質(zhì)量的改進(jìn)目標(biāo)。

2.結(jié)合了過程改進(jìn)和風(fēng)險管理的思想，F(xiàn)MEA可以評估過程的失效，及時采取措施防止它的發(fā)生;并通過持續(xù)的改進(jìn)，提升產(chǎn)品質(zhì)量。

3.可以融合各種常見質(zhì)量管理工具，如控制圖、柱狀圖、帕累托圖等技術(shù)。

4.重視有經(jīng)驗的人員參與，如通過頭腦風(fēng)暴法，讓大家的經(jīng)驗得到共享，提升FMEA質(zhì)量管理效果。

四、FMEA在A企業(yè)軟件質(zhì)量改進(jìn)的應(yīng)用

鑒于FMEA在軟件質(zhì)量改進(jìn)中“防范于未然”的良好特性，A企業(yè)以FMEA為指導(dǎo)思想，在每次信息系統(tǒng)的開發(fā)測試或者后期使用過程中的隱患排查中，采用FMEA方法進(jìn)行軟件風(fēng)險的識別、評估和優(yōu)化，確保軟件的隱形需求得到充分的滿足。實施流程如下圖1所示。

圖1 基于FMEA軟件質(zhì)量風(fēng)險控制流程圖Fig.1 flow chart of software quality risk control based on FMEA

實現(xiàn)過程如下:

首先進(jìn)行風(fēng)險識別。以軟件使用所保障的生產(chǎn)產(chǎn)品質(zhì)量為目標(biāo)，由軟件的需求發(fā)起方即應(yīng)用部門識別確定失效模式，形成失效模式清單，并建立風(fēng)險維度評價標(biāo)準(zhǔn)及等級判定標(biāo)準(zhǔn)，形成風(fēng)險等級判定標(biāo)準(zhǔn)和風(fēng)險維度評價標(biāo)準(zhǔn);

其次進(jìn)行風(fēng)險評估。組織產(chǎn)品質(zhì)量管理員、工藝員、操作員、系統(tǒng)維護(hù)員等各方面的相關(guān)人員，展開頭腦風(fēng)暴，對各種正常、不正常輸入情況下系統(tǒng)可能出現(xiàn)的不同失效模式及其后果進(jìn)行假設(shè)模擬，從而收集足夠的不良率數(shù)據(jù)，形成不良率統(tǒng)計表和FMEA分析表，并對信息系統(tǒng)在這些不同失效模式下的運行情況進(jìn)行評估，形成管理評審材料。

最后進(jìn)行風(fēng)險優(yōu)化。信息系統(tǒng)的相關(guān)開發(fā)維護(hù)人員根據(jù)風(fēng)險評估結(jié)果風(fēng)險等級判定和維度評價標(biāo)準(zhǔn)確認(rèn)出重要風(fēng)險項目，形成風(fēng)險優(yōu)化措施實施計劃，并對系統(tǒng)進(jìn)行相應(yīng)的程序優(yōu)化。

按以上步驟執(zhí)行一次乃至多次，從而確保盡可能多的發(fā)掘軟件質(zhì)量風(fēng)險點，降低因軟件失效所引發(fā)的質(zhì)量事故發(fā)生的可能。

該方法的重點在于風(fēng)險評估階段，該階段需要讓足夠多的相關(guān)人員，在脫離軟件，更多考慮產(chǎn)品質(zhì)量的情況下，通過頭腦風(fēng)暴等各種方法，收集各種正常業(yè)務(wù)需求和非正常流程下可能發(fā)生的不同輸入，從而確保能識別出各類不同失效模式。

五、FMEA在A企業(yè)軟件質(zhì)量改進(jìn)實例

以引言中所發(fā)生的軟件失效導(dǎo)致的產(chǎn)品質(zhì)量問題為例，為杜絕此類事件再次發(fā)生，A企業(yè)對相關(guān)軟件采用FMEA方法通過人機(jī)料法環(huán)等因素進(jìn)行了一次軟件質(zhì)量隱患大排查。

A公司對在制品的存放采用的是基于物料批次的平庫箱式自動存儲出入庫的倉庫物流系統(tǒng)。通過RFID系統(tǒng)全程對在制品的牌號、批次和重量等信息進(jìn)行跟蹤傳遞，并在信息傳遞交互的過程中，對信息進(jìn)行核準(zhǔn)確認(rèn)。本次隱患排查，以信息傳遞為重點，組織工藝員、操作工、電工、軟件維護(hù)員等相關(guān)人員，結(jié)合軟件在過去運行中出現(xiàn)的問題，采用頭腦風(fēng)暴，進(jìn)行風(fēng)險隱患點查找，發(fā)現(xiàn)潛在失效模式，并對各失效模式的嚴(yán)重性、發(fā)生概率以及難檢度進(jìn)行打分，得出對應(yīng)的風(fēng)險順序數(shù)列表，結(jié)果如下表1和表2。

表1 物流系統(tǒng)出入庫環(huán)節(jié)的FMEATab.1 FMEA of inbound and outbound logistics system

表2 潛在失效模式的RPN計算Tab.2 RPN calculation of potential failure modes

表3 潛在失效模式的改進(jìn)措施Tab.3 improvement measures for potential failure modes

以上對策在2017年5月實施后，物流信息化系統(tǒng)在2017年6到8月三個月中因軟件故障導(dǎo)致生產(chǎn)影響2次，共計2.5小時，而改進(jìn)前的2017年2到4月共計因軟件故障導(dǎo)致影響8次共計16.34小時。改進(jìn)效果明顯。此外在改進(jìn)三個月后，重新對原各潛在失效模式的發(fā)生概率和難檢度進(jìn)行評價，結(jié)果如下表4所示。對比結(jié)果表明，改進(jìn)后的各失效模式RPN值均已小于100，顯著優(yōu)于改進(jìn)前RPN，潛在失效模式的可能影響被大幅度降低。

表4 改進(jìn)前后RPN對比Table.4 RPN contrast before and after improvement

六、結(jié)論

本文通過對一個偶發(fā)的軟件失效導(dǎo)致的質(zhì)量問題事故進(jìn)行思考，發(fā)現(xiàn)目前軟件開發(fā)過程中重視業(yè)務(wù)功能需求，而忽視了產(chǎn)品質(zhì)量保證的隱形需求。為確保軟件的產(chǎn)品質(zhì)量保障能力，降低失效模式下對產(chǎn)品質(zhì)量導(dǎo)致的不良影響，提出在將潛在失效模式FMEA應(yīng)用于軟件開發(fā)，預(yù)防軟件失效風(fēng)險。并給出了A企業(yè)基于FMEA的軟件質(zhì)量風(fēng)險控制方法。最后在該方法的指導(dǎo)下，A企業(yè)對引言中發(fā)生失效模式的物流軟件進(jìn)行了一次全面的隱患排查，并對RPN大于100的潛在失效模式進(jìn)行改進(jìn)，從而極大程度提高了物流系統(tǒng)軟件的穩(wěn)定性。

［1］ Antonia Stefani，Michalis Xenos.Weight－ mode ling of B2C system quality［J］.Computer Standards and Interfaces.2011，33(4):411－421.

［2］ DIMITRIS STAVRINOUDIS，MICHALIS XENOS，PAVLOS PEPPAS et al.Early Estimation of Users＇Perception of Software Quality ［J］.Software Quality Journal，2005，13(2):155 －175.

［3］ P.S.Grover，Rajesh Kumar，Arun Sharma et al.Few Useful Considerations for Maintaining Software Components and Component－Based Systems［J］.Software engineering notes:ACM SIGSOFT，2007，32(5):44－0

［4］王寧，邱緒東.一種基于關(guān)鍵因素劃分的CMM軟件過程改進(jìn)模型研究［J］.大連理工大學(xué)學(xué)報，2010，50(3):432－437.

［5］ Mora，M.O＇Connor，R.V.Raisinghani，M.et al.Design，build and evaluation of an ontology－based kms for supporting cmmi－dev understanding:Benefits and limitations［J］.International journal of software engineering and knowledge engineering，2013，23(7):999－1032.

［6］王青.基于ISO9000的軟件質(zhì)量保證模型 ［J］.軟件學(xué)報，2001，12(12):1837－1842.

［7］胡濤.軟件故障樹分析技術(shù)與應(yīng)用研究［D］.北京工業(yè)大學(xué)，2009.

［8］武占春，王青，李明樹等.一種基于PDCA的軟件過程控制與改進(jìn)模型［J］.軟件學(xué)報，2006，17(8):1669－1680.

［9］奚立峰，徐剛.FMEA在過程管理中的應(yīng)用［J］.工業(yè)工程與管理，2002，7(1):37－39.

［10］戴云徽，韓之俊，朱海榮等.故障模式及影響分析 (FMEA)研究進(jìn)展［J］.中國質(zhì)量，2007，(10):23－26.

［11］彭國明.基于FMEA模型的軟件質(zhì)量管理研究［D］.南京郵電大學(xué)，2012.

［12］溫秀琴.FMEA在產(chǎn)品可靠性改進(jìn)中的應(yīng)用［J］.電子科技，2011，24(05):89－90

曹琦