淺談軟件開發項目的質量控制

1、引言

 

　　J.M.Juran認爲質量控制是一個常規的過程,經過它度量實際的質量性能並與標準比較,當出現差別時採起行動。由此,DonaldReifer 給出軟件質量控制的定義:軟件質量控制是一系列驗證活動,在軟件開發過程的任何一點進行評估開發的產品是否在技術上符合該階段制定的規約。

 

　　2、軟件缺陷分析

 

　　在IEEE 1983 of IEEES tandard729 中對軟件缺陷下了一個標準的定義:從產品內部看,軟件缺陷是軟件產品開發或維護過程當中所存在的錯誤、毛病等各類問題;從外部看,軟件缺陷是系統所須要實現的某種功能的失效或違背。

 

　　軟件缺陷是一個更廣的概念,而軟件錯誤(error)屬於缺陷的一種———內部缺陷,每每是軟件自己的問題,如程序的算法錯誤、語法錯誤或數據計算不正確、數據溢出等。軟件錯誤每每致使系統某項功能的失效,或成爲系統使用的故障。軟件的故障、失效是指軟件所提供給用戶的功能或服務,不能達到用戶的要求或沒有達到事先設計的指標,在功能使用時中斷,最後的結果或獲得的結果是不正確的。

 

　　軟件缺陷的產生主要是由軟件產品的特色和開發過程決定的,如軟件的需求常常不夠明確,並且需求變化頻繁,開發人員不太瞭解軟件需求,不清楚應該 「作什麼」和「不作什麼」,經常作不合需求的事情,產生的問題最多。同時,軟件競爭很是激烈,技術突飛猛進,使用新的技術也容易產生問題。

 

　　從軟件自身特色、團隊工做和項目管理等多個方面進一步分析,就比較容易肯定形成軟件缺陷的一些緣由細節,概括以下:

 

　　(一)軟件自身特色形成的問題。

 

　　需求不清晰,致使設計目標偏離客戶的需求,從而引發功能或產品特性上的缺陷。系統結構很是複雜,而又沒法設計成一個很好的層次結構或組件結構, 結果致使意想不到的問題或系統維護、擴充上的困難;即便設計成良好的面向對象的系統,因爲對象、類太多,很難完成對各類對象、類相互做用的組合測試,而隱藏着一些參數傳遞、方法調用、對象狀態變化等方面問題。

 

　　新技術的採用,可能涉及技術或系統兼容的問題,事先沒有考慮到。

 

　　對程序邏輯路徑或數據範圍的邊界考慮不夠周全,容易在邊界條件出錯或超過系統運行環境的複雜度。

 

　　系統運行環境的複雜,不只用戶使用的計算機環境變幻無窮,包括用戶的各類操做方式或各類不一樣的輸入數據,容易引發一些特定用戶環境下的問題;在系統實際應用中,數據量很大,可能會引發強度或負載問題。

 

　　對一些實時應用系統,要進行精心設計和技術處理,保證精確的時間同步,不然容易引發時間上不協調,或不一致性所帶來的問題。

 

　　沒有考慮系統崩潰後系統的自我恢復或數據的異地備份等問題,從而存在系統安全性、可靠性的隱患。

 

　　因爲通訊端口多、存取和加密手段的矛盾性等,會形成系統的安全性或適用型等問題。

 

　　(二)軟件項目管理的問題。

 

　　缺少質量文化,不重視質量計劃,對質量、資源、任務、成本等的平衡性把握很差,容易擠掉需求分析、評審、測試等時間,遺留的缺陷會比較多。系統分析時對客戶的需求不是十分清楚,或者和用戶的溝通存在一些困難。開發週期短,需求分析、設計、編程、測試等各項工做不能徹底按照定義好的流程來。開發流程不夠完善,存在太多的隨機性和缺少嚴謹的內審或評審機制,容易產生問題。文檔不完善、風險估計不足等。

 

　　(三)團隊工做的問題。

 

　　不一樣階段的開發人員相互理解不一致,軟件設計人員對需求分析結果的理解誤差,編程人員對系統設計規格說明書中某些內容重視不夠,或存在着誤解。設計或編程上的一些假定或依賴性,沒有獲得充分的溝通。項目組成員技術水平良莠不齊,新員工較多,或培訓不夠等緣由也容易引發問題。

 

　　軟件缺陷是由不少緣由形成的,但若是把這些缺陷按整個軟件開發週期的結果———軟件產品(市場需求文檔、規格說明書、系統設計文檔、程序代碼、測試用例等) 歸類起來,統計結果發現,規格說明書是軟件缺陷出現最多的地方。      

 

軟件產品規格說明書是軟件缺陷存在最多的地方,主要緣由以下:

 

　　用戶通常是非計算機專業人員,軟件開發人員和用戶的溝通存在較大困難,對要開發的產品功能理解不一致。

 

　　因爲軟件產品尚未設計、開發,徹底靠想象去描述系統的實現結果,因此有些特性還不夠清晰。

 

　　用戶的需求老是在不斷變化的,容易引發先後文、上下文的矛盾和需求描述的不一致。

 

　　需求分析沒有獲得足夠重視。在規格說明書設計和寫做上投人的人力、時間不足。排在產品規格說明書以後的是設計,編程排在第三位。而許多人印象中,軟件測試主要是找程序代碼中的錯誤,從分析看,這是一個誤區。

 

　　若是從軟件開發各個階段所能發現的軟件缺陷分佈來看,也主要集中在需求分析、系統設計階段,代碼階段的錯誤要比前兩個階段少。

 

　　3、分析及應對措施

 

　　(一)定義合適的項目過程。

 

　　軟件過程是指開發和維護軟件產品的活動、技術和實踐的集合。在以計算機網絡爲基礎的現代社會信息化背景下,過程管理做爲現代企業管理的先進思想和有效工具,隨着外部環境與組織模式的變化而變化。所以,做爲一個好的軟件項目過程,必須針對企業和項目的實際狀況,肯定軟件項目運做流程,定義軟件功能及相關性能,明確各階段的進入條件和退出條件,進行有效的過程控制與管理,在提升軟件開發的效率和項目的成功率的基礎上進一步保證所開發軟件的質量。

 

　　(二)明確項目需求。

 

　　對於任何軟件項目過程而言,需求不只是一個不可避免的環節,也是軟件開發的基礎。每每用戶需求明確、變動少的項目的成功率就高,而那些用戶需求混亂、變動頻繁的項目幾乎從一開始就註定了失敗的命運。可是,在現實生活中,用戶需求老是在開發進入中後期時,由於各類不一樣的緣由而發生變化。這就給軟件項目過程實施帶來不肯定因素。在塗裝項目中,因爲前期需求不明確以及隨意變動需求,致使項目組在開發階段不停的返工,進而形成代碼質量低下,測試拖期等一系列問題。所以,在項目實施過程當中,爲了保證軟件開發的順利進行和最後交付的產品質量,應該對項目需求變動進行管理。

 

　　一、需求說明書要描述明確、詳盡。因爲與用戶溝通的需求人員並非最後的開發人員,因此有可能致使開發人員對需求說明書的理解與用戶真正的意圖會產生必定的誤差。另外,當項目在進行到開發(編碼)階段時,因爲記憶的缺失,對當初所做的需求說明書的理解也會產生誤差。

 

　　二、要對需求變動進行管理。一般需求分析完成後項目就進入開發階段,用戶可能會由於市場或策略的變化而提出需求變動的要求。此時,如果合理變動則有利於項目實施,但有時所做的變動可能會影響項目總體的設計和開發,形成項目進度的延期。對於這一狀況,項目組應該積極與用戶溝通,制訂需求變動說明書,在雙方都承認的狀況下方可實施。

 

　　三、在項目開發過程當中要儘早明確用戶需求,有些內容一時沒法肯定則應該暫緩該部分的開發,儘可能下降因需求變動而帶來的風險。

 

　　(三)代碼走查。

 

　　軟件質量在很大程度上依賴於代碼質量。在實際環境中對於同一項目而言,因爲項目組成員的編程能力、習慣、風格、對需求的理解和個性的不一樣,所開發的代碼質量也不盡相同。再加上一些難以預測的人爲因素,由此帶來的隱患將嚴重影響代碼質量,最終形成軟件質量低下,使得用戶沒法正常使用併爲之後的維護帶來更大的工做量和難度。

 

　　在軟件開發過程當中能夠根據須要引進代碼走查。每週在規定的時間內,輪流讓程序員講解其所開發代碼的主要部分。這項措施一方面能夠從側面促使程序員本人注意所開發代碼的質量,另外一方面在走查過程當中能夠得到他人的意見進一步改善代碼效率,使開發成員共享項目實施過程當中問題解決的思路和方法,使得軟件質量更有保障。

 

　　(四)進行正式的測試,並造成制度測試就是對軟件產品的檢驗。

 

　　項目測試分集成測試和系統測試,主要進行功能測試、健壯性測試、性能-效率測試、用戶界面測試、安全性測試、壓力測試、可靠性測試、安裝/反安裝測試等活動。測試過程一般在模擬環境中進行。要儘量覆蓋整改項目過程,從最初的需求到部署階段,都應該制訂詳細的計劃並編制相應的文檔,如測試計劃、測試用例文檔、測試報告等。經過測試活動,儘量早得發現每一個階段中軟件存在的缺陷,以方便後續階段的實施。總之,一切測試應該符合用戶需求。