有效軟體品質管理

一、引言

隨著社會資訊化水平的不斷提高，資訊行業急速膨脹，資訊企業快速成長，隨之帶來的資訊市場競爭激烈，企業為了求生存，滿足客戶要求則成為各行各業的首要責任。依賴於品質、成本和進度的客戶滿意度，品質則是重點支撐之一，這樣要求我們對品質管理需要加強認識。我們都知道pmbok把專案管理劃分為9個知識領域，即範圍管理、時間管理、成本管理、品質管理、人力資源管理、溝通管理、採購管理、風險管理和綜合管理。品質管理作為9大知識領域之一，可見其重要性。

品質管理組件括：品質計劃編製、品質保證和品質控制三個過程域。品質計劃是品質管理的第一過程域，它主要結合各個公司的品質方針，產品描述以及品質標準和規則通過收益、成本分析和流程設計等工具制定出來實施方略，其內容全面反應使用者的要求，為品質小組成員有效工作提供了指南，為項目小組成員以及項目相關人員瞭解在項目進行中如何實施品質保證和控制提供依據，為確保項目品質得到保障提供堅實的基礎。品質保證則是貫穿整個項目全生命週期的有計劃和有系統的活動，經常性地針對整個項目品質計劃的執行情況進行評估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保項目品質與計劃保持一致。品質控制是對階段性的成果進行檢測、驗證，為品質保證提供參考依據，它是一個PDCA迴圈過程。

二 品質管理責任分配

我們公司在開發項目上按照正常化軟體的生產方式進行生產，在生產流程上採用ISO9000的標準進行。每個項目除配備了項目開發所需角色外，還專門配備了組態管理小組、測試小組和品質保證小組確保品質管理的實施，下面針對這三種角色進行說明：

1、組態管理小組職責

組態管理小組是保證項目開發完畢的同時，內部文檔和外部文檔都同時完成。內部文檔的及時產生和規範，是保證項目開發各小組能夠更好的介面和溝通的重要前提，從另一個方面講，也是保證工程不被某個關鍵路徑所阻塞而延滯的前提。如上所述，組態管理小組還是保證品質保證小組得以發揮作用的基礎。組態管理小組的主要職責包括： 完善各個部門發送需要存檔和進資料列版本設定的代碼、文檔（包括外來檔案）和階段性成果； 對代碼、文檔等進行單向出入的控制； 對所有存檔的文檔進資料列版本設定； 提供文檔規範，並傳達到開發組中。

2、測試小組職責

測試小組作為品質控制的主要手段，負責軟體的測試設計和執行工作。如同軟體開發一樣，測試在執行之前，同樣需要進行測試計劃和測試策略的設計，通常情況下測試可以分為如下幾種類型，如：正確性測試、功能性測試、效能測試、安全性測試和系統測試等。而這些測試均需要在測試計劃和測試策略中進行描述用以指導測試小組成員進行測試案例編寫和測試執行。程式員在交給測試人員之前是進行過一定的單元測試，確保程式編譯、運行正確。
測試人員根據詳細設計的文檔對軟體要實現的功能進行一一測試，保證軟體的執行正確的實現設計要求，在此也只證明了軟體正確的反映了設計思想，但是否真正反映了使用者的需求仍需要進一步的功能性測試。
測試人員只有根據軟體需求規格說明書所提及的功能進行檢測，才能確保項目組開發的軟體產品滿足使用者需求。在正確性測試完成之後，需要測試的是軟體的效能，軟體的效能在本項目中佔有重要的地位，效能要求有可能改變軟體的設計，為避免造成軟體的後期返工，測試在效能上需要較大的側重。如果有必要的話，測試小組還需要做安全性測試，以確保系統使用安全可靠。

3、品質保證小組職責

品質保證小組作為品質保證的實施小組，主要職責是保證軟體透明開發的主要環節。在項目開發的過程中幾乎所有的部門都與品質保證小組有關。品質保證小組對專案經理提供項目進度與項目真正開發時的差異報告，提出差異原因和改進方法。
在項目進度被延滯或品質保證小組認為某階段開發品質有問題時，提請專案經理、項目負責人等必要的相關人員舉行品質會議。解決當前存在的和潛在的問題。品質保證是建立在文檔的複審基礎之上，因而文檔版本的控制，特別是軟體組態管理，直接影響軟體品質保證的影響力和力度。品質保證小組的檢測範圍包括：系統分析人員是否正確的反映了使用者的需求； 軟體執行體是否正確的實現了分析人員的設計思想； 測試人員是否進行了較為徹底的和全面的測試； 組態管理員是否對文檔的正常化進行的比較徹底，版本控制是否有效。 

三 品質管理實施

有了良好的資源配備，又如何在項目全生命週期內實施品質保證，讓我們從以下幾個方面來看品質保證的實施過程： 

1、項目進度的品質保證

項目進度是項目進行是否順利的最直觀表現。顯然在項目開始之前，項目開發計劃是必須的。如果項目開發計劃的制定的是完全合理的，那項目進度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開發計劃幾乎不太可能。可見要保證項目進度，首先要保證項目開發計劃儘可能合理。 
專案計劃的合理程度與專案計劃制定者從事類似規模和類似業務的項目的經驗有直接關係，通過經驗往往能夠預見潛在的阻礙，這樣要求專案計劃制定者需要集眾人之力來完善計劃。
當專案計劃制定初期，由品質保證小組組織召開的專案計劃評審會，邀請公司技術專家、使用者以及項目組小組成員一起討論專案計劃的可行性，會議通常採用頭腦風暴法，各抒己見，會後由指定的記錄員形成品質記錄，發送給相關人員，對其計劃中不合理的地方進行修改完善，並由品質保證人員對其結果跟蹤，以確保專案計劃完整性、可行性，完善後的計劃交由組態管理人員進資料列版本設定。
然而在計劃實施過程中，計劃不是“固定化”。常有人道，“計劃趕不上變化”，但“要跟上變化”。專案計劃以裡程碑為界限，將整個開發週期劃分為若干階段。根據裡程碑的完成情況，適當的調整每一個較小的階段的任務量和完成的任務時間，這種方式非常有利於整個專案計劃的動態調整。也利於項目品質保證的實施。
實際運作中，當質保小組發現計劃實施的差異後，報告專案經理，由專案經理組織負責對計划進行周期性維護，對於已經變動的計劃由質保小組協助組態管理小組完成版本控制。本公司已經開發湖南移動的集中客服系統，開發中的子項目多達六個，曆時十個月，目前多數項目已經開發完畢，系統正在試運行階段，項目金額數千萬元。在這樣的項目中，從管理者到開發人員到測試人員都積累了較為豐富的經驗，特別是項目開發計劃的制定，和項目進度的控制。

2、項目開發各階段的品質保證

a、需求分析

需求分析是開發人員對系統需要做什麼和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了使用者的需求。從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的後期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的品質。
解決系統分析錯誤的方法我們公司通常採用邀請使用者參與進行需求評定，然後對其使用者的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與使用者簽字確認形成需求基準，交由組態管理員放入組態管理庫。
雖然儘早的邀請使用者參與，仍然避免不了項目進行中使用者的需求變更請求。對於開發過程存在的需求變動，我們要求使用者填寫變更申請單發送給項目組態管理員，在通過配置配置員轉交質保小組，負責組織專家小組和項目群組成員一起討論實施變更的可行性及實施後所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文檔實施同步變更（包括需求規格說明書、詳細設計文、安裝手冊、操作手冊等）。但是對於無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給使用者或邀請使用者進行協調會議，討論變更取捨問題或是項目進度變更問題。
決定變更之後，由專案經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程並協助組態管理員對變更後的成果物進資料列版本設定。變更實施完後，上線前還需要指定人員協助使用者一同測試並由使用者簽字後同意方可上線。

b、系統設計 

優良的體繫結構應當具備可擴充性和可配置性，而好的體繫結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是採用哪種設計方法好呢？
對於設計選型不能一概而論，需要針對項目的結構、項目的特徵和使用者的需求來分析，同樣也要考慮到參與項目小組成員的素質，如果其中大部分都沒有從事過物件導向的設計且項目進對緊迫，這樣沒有多餘的時間來培訓小組成員來掌握物件導向的設計方法，儘管眾所周知物件導向設計方法的優勢，我們還是不如採用面向過程的方式（除使用者指定開發設計方式外）可以減少項目承擔的技術風險。
我們公司有過一個項目，使用者指定需要採用物件導向分析、設計和開發，且開發週期短，在無賴的情況下，項目小組只能選用物件導向的軟體開發過程，由於項目小組很少從事過物件導向的開發，經驗缺乏，導致項目上馬後項目進度延誤，項目沒有達到預期的效果。
針對此次開發，我們分析其原因，發現小組成員在開發過程中對於新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重複性高，滯後項目進度。建議解決方案是項目群組成員採用集中辦公，分塊學習，學習的成果馬上向項目相關人員發布，再由組態管理員對其發布的文檔進行整理、規類放入配置庫以供大家共用。這樣方便大家的互相學習，減少重複的工作。在這次開發中我們公司從管理員、設計人員到開發人員都汲取了很多教訓，同時經過此次項目的開發，小組成員也積累了豐富的物件導向的開發經驗。
除設計選型，還有一個容易被忽視的問題，就是公用類開發。公用類開發可以減少工作中的重複工作，降低開發成本。這要求我們再設計階段通過對使用者需求的仔細研究，儘可能的識別出公用類，並進行定義指定專人負責設計通知其它設計人員，以減少重複工作。對於項目組提供的設計文檔，由質保小組組織技術專家、項目組設計人員、開發人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時發現設計中可能存在的錯誤，降低項目開發風險，同時確保設計文檔能為開發人員、測試人員提供切實的指導。對於可複用的設計進行提取作為公用庫設計和開發，提供項目組或整個公司重用。最後交由組態管理員進行設計文檔的版本控制。 

c、實現

實現也就是代碼的生產過程。這裡不僅包括代碼的產生，同時也包括測試案例的產生。針對上一階段提供詳細設計，程式員開始編碼並且偵錯工具，測試人員則根據設計進行測試案例的設計，設計出來的用例需要得到項目群組成員認可由專案經理審核通過才能進入配置庫。同時程式員調試完程式提交測試人員進行程式正確性檢測。 

d、文件管理

文檔維護主要是組態管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。
內部文檔包括： 項目開發計劃； 需求分析； 體繫結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件介面及調用說明； 組件索引； 組件介面及調用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統計報告； 品質監督報告； 原始碼； 文檔分類版本索引； 軟體安裝打包檔案。
外部文檔主要包括： 軟體安裝手冊； 軟體操作手冊； 線上協助； 系統效能指標報告； 系統操作索引。 
如何保證文檔的全面性，使其真正為項目的進度提供保證，又不因為文檔的寫作而耽誤項目的進度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個"度"的問題。在本項目的開發中，組態管理小組的一個非常重要的任務還是書寫文檔規範和文件範本。當有文件範本後需要書寫文檔的人員只剩下"填空"的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認為文檔的更細緻的部分可以由他人協助完成，則該文檔即交由他人完成，但此時文檔並不算被正式提交，當他人書寫完畢之後，必須由文檔的初寫者進行複審，複審通過後方可以正式提交，進入軟體組態管理的迴圈中。 
組態管理小組真正核心的工作是對文檔的組織管理。根據文檔的不同，文檔的來源也不同，有些是通過品質保證小組經過複審之後轉交給組態管理小組，有些則會直接從文檔的出處到達組態管理小組。文檔的管理是一個非常煩瑣的工作，但是長遠來看它不僅使項目的開發對單個主要人員的依賴減少，從而減少人員流動給項目的帶來的風險，更重要的是在項目進行到後百分之十的時候起到拉動項目的作用。
從以往做大項目的經驗來看，寫作文檔在項目開發的早期可能會使項目的進度比起不寫文檔要稍慢，但隨著項目的進展，各個部門需要配合越來越多，開發人員越來越需要知道其他人員的開發思路和開發過程，才能使自己的開發向前推進。一個明顯的例子就是系統整合，或者某些環節是建立在其他環節完成的基礎之上時，就更顯現出文檔交流的準確性和高效性。 

3、系統維護品質保證 

在我們公司，維護小組的任務一方面是保證對項目客戶的Tracing Service，另一方面是確保該項目其它的開發人員從項目中儘快的解脫出來以便投入到下一個項目的開發中。所以通常項目維護小組成員主要由項目組的少部分開發人員承擔完成。他們不僅瞭解軟體的核心內容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對於一般性的錯誤，如操作不當等引起的問題，全部由維護小組執行完成，但需要使用者測試確認上線。如果較大的修改則需要走變更控制流程，使用者或者維護人員填寫變更申請，經專家會議討論分析可行方案在由維護小組實施，通過測試後方可提交使用者。
維護小組的人員基本上是按項目跟進的。當一個項目剛剛交付使用者時，在維護小組有較多的人員進行跟進，隨軟體的穩定，跟進的人逐步減少，並轉移到其它項目中去。