計算機室張立霞
一、引言
隨著社會資訊化水平的不斷提高，使用者對軟體功能、效能、可靠性以及可擴充套件性的要求迅速提高,我們所開發的軟體專案的規模和複雜度日益增大,軟體產品中越來越多的質量問題也隨之暴露出來。 在市場競爭日益激烈的情況下,如何提高軟體產品的質量,增強產品的市場競爭力,已經成為關係到軟體企業是否能夠健康持續發展的乙個關鍵因素。
在實際的專案質量管理中，質量管理可以分解為質量計畫編制、質量保證和質量控制三個過程。質量計畫是針對質量提公升及質量保證這兩項而制定的，制定原則是主要結合公司的質量方針，產品描述以及質量標準和規則通過收益、成本分析和流程設計等工具制定出來實施方略，其內容全面反應使用者的要求，為質量小組成員有效工作提供了指南，為專案小組成員以及專案相關人員了解在專案進行中如何實施質量保證和控制提供依據，為確保專案質量得到保障提供堅實的基礎。質量保證則是貫穿整個專案全生命週期的有計畫和有系統的活動，經常性地針對整個專案質量計畫的執**況進行評估、檢查與改進等工作，向管理者、顧客或其他方提供信任，確保專案質量與計畫保持一致。
質量控制是對階段性的成果進行檢測、驗證，為質量保證提供參考依據，它是乙個pdca迴圈過程。質量保證與質量控制這兩個過程通常相互作用，在實際應用中還會發生交叉。
二質量管理責任分配
我們公司在開發專案上按照規範化軟體的生產方式進行生產，在生產流程上採用iso9000的標準進行。每個專案除配備了專案開發所需角色外，還專門配備了配置管理小組、測試小組和質量保證小組確保質量管理的實施，下面針對這三種角色進行說明：
1、 配置管理小組職責
配置管理小組依據配置管理規程，結合iso 9000其它各項支援活動,保證在質量體系的各生存週期活動中全面實施有效的質量管理。其主要職責包括： 完善各部門傳送需要存檔和進行版本控制的**、文件（包括外來檔案）和階段性成果； 對**、文件等進行單向出入的控制； 對所有存檔的文件進行版本控制； 提供文件規範，並傳達到開發組中，促進專案開發小組之間進行更好的介面和溝通，保證開發過程中關鍵路徑不被阻塞而延滯的前提。
測試小組職責
測試小組作為質量控制的主要手段，負責軟體的測試設計和執行工作。如同軟體開發一樣，測試在執行之前，同樣需要進行測試計畫和測試策略的設計，通常情況下測試可以分為如下幾種型別，如：正確性測試、功能性測試、效能測試、安全測試和系統測試等。
而這些測試均需要在測試計畫和測試策略中進行描述用以指導測試小組成員進行測試用例編寫和測試執行。程式設計師在交給測試人員之前是進行過一定的單元測試，確保程式編譯、執行正確。
測試人員根據詳細設計的文件對軟體要實現的功能進行一一測試，保證軟體的執行正確的實現設計要求，在此也只證明了軟體正確的反映了設計思想，但是否真正反映了使用者的需求仍需要進一步的功能性測試。
測試人員只有根據軟體需求規格說明書所提及的功能進行檢測，才能確保專案組開發的軟體產品滿足使用者需求。在正確性測試完成之後，需要測試的是軟體的效能，軟體的效能在本專案中占有重要的地位，效能要求有可能改變軟體的設計，為避免造成軟體的後期返工，測試在效能上需要較大的側重。如果有必要的話，測試小組還需要做安全測試，以確保系統使用安全可靠。
2、 質量保證小組職責
質量保證小組作為質量保證的實施小組，主要職責是保證軟體透明開發的主要環節。在專案開發的過程中幾乎所有的部門都與質量保證小組有關。質量保證小組對專案經理提供專案進度與專案真正開發時的差異報告，提出差異原因和改進方法。
在專案進度被延滯或質量保證小組認為某階段開發質量有問題時，提請專案經理、專案負責人等必要的相關人員舉行質量會議。解決當前存在的和潛在的問題。質量保證是建立在文件的複審基礎之上，因而文件版本的控制，特別是軟體配置管理，直接影響軟體質量保證的影響力和力度。
質量保證小組的檢測範圍包括：系統分析人員是否正確的反映了使用者的需求； 軟體執行體是否正確的實現了分析人員的設計思想； 測試人員是否進行了較為徹底的和全面的測試； 配置管理員是否對文件的規範化進行的比較徹底，版本控制是否有效。
三質量管理實施
有了良好的資源配備，又如何在專案全生命週期內實施質量保證，讓我們從以下幾個方面來看質量保證的實施過程：
1、 專案進度的質量保證
專案進度是專案進行是否順利的最直觀表現。顯然在專案開始之前，專案開發計畫是必須的。如果專案開發計畫的制定的是完全合理的，那專案進度也就真正表達了專案與最終的交付使用之間的距離，然而要制定完全合理的專案開發計畫幾乎不太可能。
可見要保證專案進度，首先要保證專案開發計畫盡可能合理。
專案計畫的合理程度與專案計畫制定者從事類似規模和類似業務的專案的經驗有直接關係，通過經驗往往能夠預見潛在的阻礙，這樣要求專案計畫制定者需要集眾人之力來完善計畫。
當專案計畫制定初期，由質量保證小組組織召開的專案計畫評審會，邀請公司技術專家、使用者以及專案組小組成員一起討論專案計畫的可行性，會議通常採用頭腦風暴法，各抒己見，會後由指定的記錄員形成質量記錄，傳送給相關人員，對其計畫中不合理的地方進行修改完善，並由質量保證人員對其結果跟蹤，以確保專案計畫完整性、可行性，完善後的計畫交由配置管理人員進行版本控制。
然而在計畫實施過程中，計畫不是「固定化」。常有人道，「計畫趕不上變化」，但「要跟上變化」。專案計畫以里程碑為界限，將整個開發周期劃分為若干階段。
根據里程碑的完成情況，適當的調整每乙個較小的階段的任務量和完成的任務時間，這種方式非常有利於整個專案計畫的動態調整。也利於專案質量保證的實施。
實際運作中，當質保小組發現計畫實施的差異後，報告專案經理，由專案經理組織負責對計畫進行週期性維護，對於已經變動的計畫由質保小組協助配置管理小組完成版本控制。本公司已經開發湖南移動的集中客服系統，開發中的子專案多達六個，歷時十個月，目前多數專案已經開發完畢，系統正在試執行階段，專案金額數千萬元。在這樣的專案中，從管理者到開發人員到測試人員都積累了較為豐富的經驗，特別是專案開發計畫的制定，和專案進度的控制。
2、專案開發各階段的質量保證
a、需求分析
需求分析是開發人員對系統需要做什麼和如何做的定義過程。從系統分析的經驗來看，這個過程往往是個循序漸進的過程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶領域專家進行交流確認，方能逐步明了使用者的需求。
從系統開發的過程得知，系統分析時犯下的錯誤，會在接下來的階段被成倍的放大，越是在開發的後期，糾正分析時犯下的錯誤所花費的代價越是昂貴，也越發影響系統的工期和系統的質量。
解決系統分析錯誤的方法我們公司通常採用邀請使用者參與進行需求評定，然後對其使用者的意見由質保成員跟蹤檢測是否納入需求規格說明書，同時與使用者簽字確認形成需求基線，交由配置管理員放入配置管理庫。
雖然盡早的邀請使用者參與，仍然避免不了專案進行中使用者的需求變更請求。對於開發過程存在的需求變動，我們要求使用者填寫變更申請單傳送給專案配置管理員，在通過配置配置員轉交質保小組，負責組織專家小組和專案組成員一起討論實施變更的可行性及實施後所帶來的影響，小的變更則直接記錄入變更記錄原因分析項和風險項欄，大的變更則需要形成正式的變更報告，無論那種變更都需要對相應的文件實施同步變更（包括需求規格說明書、詳細設計文、安裝手冊、操作手冊等）。但是對於無法實現或是變更會帶來巨大的影響而將導致進度的延期，這時，我們將變更報告提交給使用者或邀請使用者進行協調會議，討論變更取捨問題或是專案進度變更問題。
決定變更之後，由專案經理組織實施變更，測試人員檢測變更結果，而質保小組成員監督變更實施過程並協助配置管理員對變更後的成果物進行版本控制。變更實施完後，上線前還需要指定人員協助使用者一同測試並由使用者簽字後同意方可上線。
b、系統設計
優良的體系結構應當具備可擴充套件性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是採用哪種設計方法好呢？
對於設計選型不能一概而論，需要針對專案的結構、專案的特徵和使用者的需求來分析，同樣也要考慮到參與專案小組成員的素質，如果其中大部分都沒有從事過物件導向的設計且專案進對緊迫，這樣沒有多餘的時間來培訓小組成員來掌握物件導向的設計方法，儘管眾所周知物件導向設計方法的優勢，我們還是不如採用面向過程的方式（除使用者指定開發設計方式外）可以減少專案承擔的技術風險。
我們公司有過乙個專案，使用者指定需要採用物件導向分析、設計和開發，且開發周期短，在無賴的情況下，專案小組只能選用物件導向的軟體開發過程，由於專案小組很少從事過物件導向的開發，經驗缺乏，導致專案上馬後專案進度延誤，專案沒有達到預期的效果。
針對此次開發，我們分析其原因，發現小組成員在開發過程中對於新技術互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重複性高，滯後專案進度。建議解決方法是專案組成員採用集中辦公，分塊學習，學習的成果馬上向專案相關人員發布，再由配置管理員對其發布的文件進行整理、規類放入配置庫以供大家共享。這樣方便大家的互相學習，減少重複的工作。
在這次開發中我們公司從管理人員、設計人員到開發人員都汲取了很多教訓，同時經過此次專案的開發，小組成員也積累了豐富的物件導向的開發經驗。
除設計選型，還有乙個容易被忽視的問題，就是公共類開發。公共類開發可以減少工作中的重複工作，降低開發成本。這要求我們再設計階段通過對使用者需求的仔細研究，盡可能的識別出公共類，並進行定義指定專人負責設計通知其它設計人員，以減少重複工作。
對於專案組提供的設計文件，由質保小組組織技術專家、專案組設計人員、開發人員和測試人員對其設計文件的評審，檢測設計文件對其下一階段工作的可行性，及時發現設計中可能存在的錯誤，降低專案開發風險，同時確保設計文件能為開發人員、測試人員提供切實的指導。對於可復用的設計進行提取作為公共庫設計和開發，提供專案組或整個公司重用。最後交由配置管理員進行設計文件的版本控制。
c、實現
實現也就是**的生產過程。這裡不僅包括**的產生，同時也包括測試用例的產生。針對上一階段提供詳細設計，程式設計師開始編碼並且除錯程式，測試人員則根據設計進行測試用例的設計，設計出來的用例需要得到專案組成員認可由專案經理審核通過才能進入配置庫。
同時程式設計師除錯完程式提交測試人員進行程式正確性檢測。
d、文件管理
文件維護主要是配置管理小組的工作。文件從用途上分主要分為內部文件和外部文件。
內部文件包括： 專案開發計畫； 需求分析； 體系結構設計說明； 詳細設計說明； 構件索引； 構件成分說明； 構件介面及呼叫說明； 元件索引； 元件介面及呼叫說明； 類索引； 類屬性及方法說明； 測試報告； 測試統計報告； 質量監督報告； 源**； 文件分類版本索引； 軟體安裝打包檔案。
軟體質量管理
前邊我們介紹了，面向過程的軟體開發過程，從計畫到測試的整個過程，但是如何確保軟體的質量呢？只要我們的軟體質量過關才會得到使用者的肯定，所以從質量這個角度看，我們該如何管理呢？這篇部落格，總結了軟體質量管理的相關知識。首先，總的了解一下，需要我們知道一些相關概念 然後是我們軟體質量該如何保證，有什麼措...
軟體質量管理的法則
質量管理在軟體工程中是非常非常重要的乙個環節，無論你有多麼精妙的演算法，或是使用了多麼先進的技術，還是擁有了多少強的設計，在質量控制或質量管理面前，這些都可能什麼都不是。這裡，有一些質量管理的法則，可以讓軟體的使用者從中受益。如果對質量管理一言以蔽之 面對乙個長期不斷需要改善的軟體，當其使用者或是管...
軟體專案質量管理
一 研究軟體專案質量管理的背景 提起如今的it專案，軟體工程倍受關注。而軟體的質量更是眾人關注的焦點，因為目前還沒有一套完善的評估標準。甚至有人提出，現在的軟體開發根本提不上是 工程 因為它太稚嫩了，還沒有一套成熟的標準來比照 因而軟體專案極易出現失敗或失誤。大量實踐證明，軟體工程專案的成敗，通常是...