一、引言
J.M.Juran認為質量控制是一個常規(guī)的過程,通過它度量實際的質量性能并與標準比較,當出現(xiàn)差異時采取行動。由此,DonaldReifer 給出軟件質量控制的定義:軟件質量控制是一系列驗證活動,在軟件開發(fā)過程的任何一點進行評估開發(fā)的產(chǎn)品是否在技術上符合該階段制定的規(guī)約。
二、軟件缺陷分析
在IEEE 1983 of IEEES tandard729 中對軟件缺陷下了一個標準的定義:從產(chǎn)品內(nèi)部看,軟件缺陷是軟件產(chǎn)品開發(fā)或維護過程中所存在的錯誤、毛病等各種問題;從外部看,軟件缺陷是系統(tǒng)所需要實現(xiàn)的某種功能的失效或違背。
軟件缺陷是一個更廣的概念,而軟件錯誤(error)屬于缺陷的一種———內(nèi)部缺陷,往往是軟件本身的問題,如程序的算法錯誤、語法錯誤或數(shù)據(jù)計算不正確、數(shù)據(jù)溢出等。軟件錯誤往往導致系統(tǒng)某項功能的失效,或成為系統(tǒng)使用的故障。軟件的故障、失效是指軟件所提供給用戶的功能或服務,不能達到用戶的要求或沒有達到事先設計的指標,在功能使用時中斷,最后的結果或得到的結果是不正確的。
軟件缺陷的產(chǎn)生主要是由軟件產(chǎn)品的特點和開發(fā)過程決定的,如軟件的需求經(jīng)常不夠明確,而且需求變化頻繁,開發(fā)人員不太了解軟件需求,不清楚應該 “做什么”和“不做什么”,常常做不合需求的事情,產(chǎn)生的問題最多。同時,軟件競爭非常激烈,技術日新月異,使用新的技術也容易產(chǎn)生問題。
從軟件自身特點、團隊工作和項目管理等多個方面進一步分析,就比較容易確定造成軟件缺陷的一些原因細節(jié),歸納如下:
(一)軟件自身特點造成的問題。
需求不清晰,導致設計目標偏離客戶的需求,從而引起功能或產(chǎn)品特性上的缺陷。系統(tǒng)結構非常復雜,而又無法設計成一個很好的層次結構或組件結構, 結果導致意想不到的問題或系統(tǒng)維護、擴充上的困難;即使設計成良好的面向對象的系統(tǒng),由于對象、類太多,很難完成對各種對象、類相互作用的組合測試,而隱藏著一些參數(shù)傳遞、方法調(diào)用、對象狀態(tài)變化等方面問題。
新技術的采用,可能涉及技術或系統(tǒng)兼容的問題,事先沒有考慮到。
對程序邏輯路徑或數(shù)據(jù)范圍的邊界考慮不夠周全,容易在邊界條件出錯或超過系統(tǒng)運行環(huán)境的復雜度。
系統(tǒng)運行環(huán)境的復雜,不僅用戶使用的計算機環(huán)境千變?nèi)f化,包括用戶的各種操作方式或各種不同的輸入數(shù)據(jù),容易引起一些特定用戶環(huán)境下的問題;在系統(tǒng)實際應用中,數(shù)據(jù)量很大,可能會引起強度或負載問題。
對一些實時應用系統(tǒng),要進行精心設計和技術處理,保證精確的時間同步,否則容易引起時間上不協(xié)調(diào),或不一致性所帶來的問題。
沒有考慮系統(tǒng)崩潰后系統(tǒng)的自我恢復或數(shù)據(jù)的異地備份等問題,從而存在系統(tǒng)安全性、可靠性的隱患。
由于通信端口多、存取和加密手段的矛盾性等,會造成系統(tǒng)的安全性或適用型等問題。
(二)軟件項目管理的問題。
缺乏質量文化,不重視質量計劃,對質量、資源、任務、成本等的平衡性把握不好,容易擠掉需求分析、評審、測試等時間,遺留的缺陷會比較多。系統(tǒng)分析時對客戶的需求不是十分清楚,或者和用戶的溝通存在一些困難。開發(fā)周期短,需求分析、設計、編程、測試等各項工作不能完全按照定義好的流程來。開發(fā)流程不夠完善,存在太多的隨機性和缺乏嚴謹?shù)膬?nèi)審或評審機制,容易產(chǎn)生問題。文檔不完善、風險估計不足等。
(三)團隊工作的問題。
不同階段的開發(fā)人員相互理解不一致,軟件設計人員對需求分析結果的理解偏差,編程人員對系統(tǒng)設計規(guī)格說明書中某些內(nèi)容重視不夠,或存在著誤解。設計或編程上的一些假定或依賴性,沒有得到充分的溝通。項目組成員技術水平參差不齊,新員工較多,或培訓不夠等原因也容易引起問題。
軟件缺陷是由很多原因造成的,但如果把這些缺陷按整個軟件開發(fā)周期的結果———軟件產(chǎn)品(市場需求文檔、規(guī)格說明書、系統(tǒng)設計文檔、程序代碼、測試用例等) 歸類起來,統(tǒng)計結果發(fā)現(xiàn),規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方。
軟件產(chǎn)品規(guī)格說明書是軟件缺陷存在最多的地方,主要原因如下: 用戶一般是非計算機專業(yè)人員,軟件開發(fā)人員和用戶的溝通存在較大困難,對要開發(fā)的產(chǎn)品功能理解不一致。 由于軟件產(chǎn)品還沒有設計、開發(fā),完全靠想象去描述系統(tǒng)的實現(xiàn)結果,所以有些特性還不夠清晰。 用戶的需求總是在不斷變化的,容易引起前后文、上下文的矛盾和需求描述的不一致。 需求分析沒有得到足夠重視。在規(guī)格說明書設計和寫作上投人的人力、時間不足。排在產(chǎn)品規(guī)格說明書之后的是設計,編程排在第三位。而許多人印象中,軟件測試主要是找程序代碼中的錯誤,從分析看,這是一個誤區(qū)。 如果從軟件開發(fā)各個階段所能發(fā)現(xiàn)的軟件缺陷分布來看,也主要集中在需求分析、系統(tǒng)設計階段,代碼階段的錯誤要比前兩個階段少。 三、分析及應對措施 (一)定義合適的項目過程。 軟件過程是指開發(fā)和維護軟件產(chǎn)品的活動、技術和實踐的集合。在以計算機網(wǎng)絡為基礎的現(xiàn)代社會信息化背景下,過程管理作為現(xiàn)代企業(yè)管理的先進思想和有效工具,隨著外部環(huán)境與組織模式的變化而變化。因此,作為一個好的軟件項目過程,必須針對企業(yè)和項目的實際情況,確定軟件項目運作流程,定義軟件功能及相關性能,明確各階段的進入條件和退出條件,進行有效的過程控制與管理,在提高軟件開發(fā)的效率和項目的成功率的基礎上進一步保證所開發(fā)軟件的質量。 (二)明確項目需求。 對于任何軟件項目過程而言,需求不僅是一個不可避免的環(huán)節(jié),也是軟件開發(fā)的基礎。往往用戶需求明確、變更少的項目的成功率就高,而那些用戶需求混亂、變更頻繁的項目幾乎從一開始就注定了失敗的命運。但是,在現(xiàn)實生活中,用戶需求總是在開發(fā)進入中后期時,因為各種不同的原因而發(fā)生變化。這就給軟件項目過程實施帶來不確定因素。在涂裝項目中,由于前期需求不明確以及隨意變更需求,導致項目組在開發(fā)階段不停的返工,進而造成代碼質量低下,測試拖期等一系列問題。因此,在項目實施過程中,為了保證軟件開發(fā)的順利進行和最后交付的產(chǎn)品質量,應該對項目需求變更進行管理。 1、需求說明書要描述明確、詳盡。由于與用戶溝通的需求人員并不是最后的開發(fā)人員,所以有可能導致開發(fā)人員對需求說明書的理解與用戶真正的意圖會產(chǎn)生一定的偏差。另外,當項目在進行到開發(fā)(編碼)階段時,由于記憶的缺失,對當初所作的需求說明書的理解也會產(chǎn)生偏差。 2、要對需求變更進行管理。通常需求分析完成后項目就進入開發(fā)階段,用戶可能會因為市場或策略的變化而提出需求變更的要求。此時,若是合理變更則有利于項目實施,但有時所作的變更可能會影響項目整體的設計和開發(fā),造成項目進度的延期。對于這一情況,項目組應該積極與用戶溝通,制訂需求變更說明書,在雙方都認可的情況下方可實施。 3、在項目開發(fā)過程中要盡早明確用戶需求,有些內(nèi)容一時無法確定則應該暫緩該部分的開發(fā),盡量降低因需求變更而帶來的風險。 (三)代碼走查。 軟件質量在很大程度上依賴于代碼質量。在實際環(huán)境中對于同一項目而言,由于項目組成員的編程能力、習慣、風格、對需求的理解和個性的不同,所開發(fā)的代碼質量也不盡相同。再加上一些難以預測的人為因素,由此帶來的隱患將嚴重影響代碼質量,最終造成軟件質量低下,使得用戶無法正常使用并為以后的維護帶來更大的工作量和難度。 在軟件開發(fā)過程中可以根據(jù)需要引進代碼走查。每周在規(guī)定的時間內(nèi),輪流讓程序員講解其所開發(fā)代碼的主要部分。這項措施一方面可以從側面促使程序員本人注意所開發(fā)代碼的質量,另一方面在走查過程中可以獲得他人的意見進一步改善代碼效率,使開發(fā)成員共享項目實施過程中問題解決的思路和方法,使得軟件質量更有保障。 (四)進行正式的測試,并形成制度測試就是對軟件產(chǎn)品的檢驗。
項目測試分集成測試和系統(tǒng)測試,主要進行功能測試、健壯性測試、性能-效率測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試等活動。測試過程通常在模擬環(huán)境中進行。要盡可能覆蓋整改項目過程,從最初的需求到部署階段,都應該制訂詳細的計劃并編制相應的文檔,如測試計劃、測試用例文檔、測試報告等。通過測試活動,盡可能早得發(fā)現(xiàn)每個階段中軟件存在的缺陷,以方便后續(xù)階段的實施。總之,一切測試應該符合用戶需求。
聯(lián)系客服
