有效的軟件質(zhì)量管理

    質(zhì)量管理包括：質(zhì)量計劃編制、質(zhì)量保證和質(zhì)量控制三個(gè)過(guò)程域。質(zhì)量計劃是質(zhì)量管理的第一過(guò)程域，它主要結合各個(gè)公司的質(zhì)量方針，產(chǎn)品描述以及質(zhì)量標準和規則通過(guò)收益、成本分析和流程設計等工具制定出來(lái)實(shí)施方略，其內容全面反應用戶(hù)的要求，為質(zhì)量小組成員有效工作提供了指南，為項目小組成員以及項目相關(guān)人員了解在項目進(jìn)行中如何實(shí)施質(zhì)量保證和控制提供依據，為確保項目質(zhì)量得到保障提供堅實(shí)的基礎。質(zhì)量保證則是貫穿整個(gè)項目全生命周期的有計劃和有

系統的活動(dòng)，經(jīng)常性地針對整個(gè)項目質(zhì)量計劃的執行情況進(jìn)行評估、檢查與改進(jìn)等工作，向管理者、顧客或其他方提供信任，確保項目質(zhì)量與計劃保持一致。質(zhì)量控制是對階段性的成果進(jìn)行檢測、驗證，為質(zhì)量保證提供參考依據，它是一個(gè)PDCA循環(huán)過(guò)程。

　　隨著(zhù)社會(huì )信息化水平的不斷提高，信息行業(yè)急速膨脹，信息企業(yè)快速成長(cháng)，隨之帶來(lái)的信息市場(chǎng)競爭激烈，企業(yè)為了求生存，滿(mǎn)足客戶(hù)要求則成為各行各業(yè)的首要責任。依賴(lài)于質(zhì)量、成本和進(jìn)度的客戶(hù)滿(mǎn)意度，質(zhì)量則是重點(diǎn)支撐之一，這樣要求我們對質(zhì)量管理需要加強認識。我們都知道pmbok把項目管理劃分為9個(gè)知識領(lǐng)域，即范圍管理、時(shí)間管理、成本管理、質(zhì)量管理、人力資源管理、溝通管理、采購管理、風(fēng)險管理和綜合管理。質(zhì)量管理作為9大知識領(lǐng)域之一，可見(jiàn)其重要性。

一、質(zhì)量管理責任分配

　　我們公司在開(kāi)發(fā)項目上按照規范化軟件的生產(chǎn)方式進(jìn)行生產(chǎn)，在生產(chǎn)流程上采用ISO9000的標準進(jìn)行。每個(gè)項目除配備了項目開(kāi)發(fā)所需角色外，還專(zhuān)門(mén)配備了配置管理小組、測試小組和質(zhì)量保證小組確保質(zhì)量管理的實(shí)施，下面針對這三種角色進(jìn)行說(shuō)明：

　　1、配置管理小組職責

　　配置管理小組是保證項目開(kāi)發(fā)完畢的同時(shí)，內部文檔和外部文檔都同時(shí)完成。內部文檔的及時(shí)產(chǎn)生和規范，是保證項目開(kāi)發(fā)各小組能夠更好的接口和溝通的重要前提，從另一個(gè)方面講，也是保證工程不被某個(gè)關(guān)鍵路徑所阻塞而延滯的前提。如上所述，配置管理小組還是保證質(zhì)量保證小組得以發(fā)揮作用的基礎。配置管理小組的主要職責包括： 完善各個(gè)部門(mén)發(fā)送需要存檔和進(jìn)行版本控制的代碼、文檔(包括外來(lái)文件)和階段性成果; 對代碼、文檔等進(jìn)行單向出入的控制；對所有存檔的文檔進(jìn)行版本控制; 提供文檔規范，并傳達到開(kāi)發(fā)組中。

　　2、測試小組職責

　　測試小組作為質(zhì)量控制的主要手段，負責軟件的測試設計和執行工作。如同軟件開(kāi)發(fā)一樣，測試在執行之前，同樣需要進(jìn)行測試計劃和測試策略的設計，通常情況下測試可以分為如下幾種類(lèi)型，如：正確性測試、功能性測試、性能測試、安全測試和系統測試等。而這些測試均需要在測試計劃和測試策略中進(jìn)行描述用以指導測試小組成員進(jìn)行測試用例編寫(xiě)和測試執行。程序員在交給測試人員之前是進(jìn)行過(guò)一定的單元測試，確保程序編譯、運行正確。

　　測試人員根據詳細設計的文檔對軟件要實(shí)現的功能進(jìn)行一一測試，保證軟件的執行正確的實(shí)現設計要求，在此也只證明了軟件正確的反映了設計思想，但是否真正反映了用戶(hù)的需求仍需要進(jìn)一步的功能性測試。

　　測試人員只有根據軟件需求規格說(shuō)明書(shū)所提及的功能進(jìn)行檢測，才能確保項目組開(kāi)發(fā)的軟件產(chǎn)品滿(mǎn)足用戶(hù)需求。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本項目中占有重要的地位，性能要求有可能改變軟件的設計，為避免造成軟件的后期返工，測試在性能上需要較大的側重。如果有必要的話(huà)，測試小組還需要做安全測試，以確保系統使用安全可靠。

　　3、質(zhì)量保證小組職責

　　質(zhì)量保證小組作為質(zhì)量保證的實(shí)施小組，主要職責是保證軟件透明開(kāi)發(fā)的主要環(huán)節。在項目開(kāi)發(fā)的過(guò)程中幾乎所有的部門(mén)都與質(zhì)量保證小組有關(guān)。質(zhì)量保證小組對項目經(jīng)理提供項目進(jìn)度與項目真正開(kāi)發(fā)時(shí)的差異報告，提出差異原因和改進(jìn)方法。

　　在項目進(jìn)度被延滯或質(zhì)量保證小組認為某階段開(kāi)發(fā)質(zhì)量有問(wèn)題時(shí)，提請項目經(jīng)理、項目負責人等必要的相關(guān)人員舉行質(zhì)量會(huì )議。解決當前存在的和潛在的問(wèn)題。質(zhì)量保證是建立在文檔的復審基礎之上，因而文檔版本的控制，特別是軟件配置管理，直接影響軟件質(zhì)量保證的影響力和力度。質(zhì)量保證小組的檢測范圍包括：系統分析人員是否正確的反映了用戶(hù)的需求; 軟件執行體是否正確的實(shí)現了分析人員的設計思想; 測試人員是否進(jìn)行了較為徹底的和全面的測試;配置管理員是否對文檔的規范化進(jìn)行的比較徹底，版本控制是否有效。

二、質(zhì)量管理實(shí)施

    有了良好的資源配備，又如何在項目全生命周期內實(shí)施質(zhì)量保證，讓我們從以下幾個(gè)方面來(lái)看質(zhì)量保證的實(shí)施過(guò)程：

　　1、項目進(jìn)度的質(zhì)量保證

　　項目進(jìn)度是項目進(jìn)行是否順利的最直觀(guān)表現。顯然在項目開(kāi)始之前，項目開(kāi)發(fā)計劃是必須的。如果項目開(kāi)發(fā)計劃的制定的是完全合理的，那項目進(jìn)度也就真正表達了項目與最終的交付使用之間的距離，然而要制定完全合理的項目開(kāi)發(fā)計劃幾乎不太可能�？梢�(jiàn)要保證項目進(jìn)度，首先要保證項目開(kāi)發(fā)計劃盡可能合理。

　　項目計劃的合理程度與項目計劃制定者從事類(lèi)似規模和類(lèi)似業(yè)務(wù)的項目的經(jīng)驗有直接關(guān)系，通過(guò)經(jīng)驗往往能夠預見(jiàn)潛在的阻礙，這樣要求項目計劃制定者需要集眾人之力來(lái)完善計劃。

　　當項目計劃制定初期，由質(zhì)量保證小組組織召開(kāi)的項目計劃評審會(huì )，邀請公司技術(shù)專(zhuān)家、用戶(hù)以及項目組小組成員一起討論項目計劃的可行性，會(huì )議通常采用頭腦風(fēng)暴法，各抒己見(jiàn)，會(huì )后由指定的記錄員形成質(zhì)量記錄，發(fā)送給相關(guān)人員，對其計劃中不合理的地方進(jìn)行修改完善，并由質(zhì)量保證人員對其結果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置管理人員進(jìn)行版本控制。

　　然而在計劃實(shí)施過(guò)程中，計劃不是“固定化”。常有人道，“計劃趕不上變化”，但“要跟上變化”。項目計劃以里程碑為界限，將整個(gè)開(kāi)發(fā)周期劃分為若干階段。根據里程碑的完成情況，適當的調整每一個(gè)較小的階段的任務(wù)量和完成的任務(wù)時(shí)間，這種方式非常有利于整個(gè)項目計劃的動(dòng)態(tài)調整。也利于項目質(zhì)量保證的實(shí)施。

　　實(shí)際運作中，當質(zhì)保小組發(fā)現計劃實(shí)施的差異后，報告項目經(jīng)理，由項目經(jīng)理組織負責對計劃進(jìn)行周期性維護，對于已經(jīng)變動(dòng)的計劃由質(zhì)保小組協(xié)助配置管理小組完成版本控制。本公司已經(jīng)開(kāi)發(fā)湖南移動(dòng)的集中客服系統，開(kāi)發(fā)中的子項目多達六個(gè)，歷時(shí)十個(gè)月，目前多數項目已經(jīng)開(kāi)發(fā)完畢，系統正在試運行階段，項目金額數千萬(wàn)元。在這樣的項目中，從管理者到開(kāi)發(fā)人員到測試人員都積累了較為豐富的經(jīng)驗，特別是項目開(kāi)發(fā)計劃的制定，和項目進(jìn)度的控制。

　　2、項目開(kāi)發(fā)各階段的質(zhì)量保證項目

　　a、需求分析

　　需求分析是開(kāi)發(fā)人員對系統需要做什么和如何做的定義過(guò)程。從系統分析的經(jīng)驗來(lái)看，這個(gè)過(guò)程往往是個(gè)循序漸進(jìn)的過(guò)程，一次性對系統形成完整的認識是困難的。只有不斷地和客戶(hù)領(lǐng)域專(zhuān)家進(jìn)行交流確認，方能逐步明了用戶(hù)的需求。從系統開(kāi)發(fā)的過(guò)程得知，系統分析時(shí)犯下的錯誤，會(huì )在接下來(lái)的階段被成倍的放大，越是在開(kāi)發(fā)的后期，糾正分析時(shí)犯下的錯誤所花費的代價(jià)越是昂貴，也越發(fā)影響系統的工期和系統的質(zhì)量。

　　解決系統分析錯誤的方法我們公司通常采用邀請用戶(hù)參與進(jìn)行需求評定，然后對其用戶(hù)的意見(jiàn)由質(zhì)保成員跟蹤檢測是否納入需求規格說(shuō)明書(shū)，同時(shí)與用戶(hù)簽字確認形成需求基線(xiàn)，交由配置管理員放入配置管理庫。

　　雖然盡早的邀請用戶(hù)參與，仍然避免不了項目進(jìn)行中用戶(hù)的需求變更請求。對于開(kāi)發(fā)過(guò)程存在的需求變動(dòng)，我們要求用戶(hù)填寫(xiě)變更申請單發(fā)送給項目配置管理員，在通過(guò)配置配置員轉交質(zhì)保小組，負責組織專(zhuān)家小組和項目組成員一起討論實(shí)施變更的可行性及實(shí)施后所帶來(lái)的影響，小的變更則直接記錄入變更記錄原因分析項和風(fēng)險項欄，大的變更則需要形成正式的變更報告，無(wú)論那種變更都需要對相應的文檔實(shí)施同步變更(包括需求規格說(shuō)明書(shū)、詳細設計文、安裝手冊、操作手冊等)。但是對于無(wú)法實(shí)現或是變更會(huì )帶來(lái)巨大的影響而將導致進(jìn)度的延期，這時(shí)，我們將變更報告提交給用戶(hù)或邀請用戶(hù)進(jìn)行協(xié)調會(huì )議，討論變更取舍問(wèn)題或是項目進(jìn)度變更問(wèn)題。

　　決定變更之后，由項目經(jīng)理組織實(shí)施變更，測試人員檢測變更結果，而質(zhì)保小組成員監督變更實(shí)施過(guò)程并協(xié)助配置管理員對變更后的成果物進(jìn)行版本控制。變更實(shí)施完后，上線(xiàn)前還需要指定人員協(xié)助用戶(hù)一同測試并由用戶(hù)簽字后同意方可上線(xiàn)。

　　b、系統設計

　　優(yōu)良的體系結構應當具備可擴展性和可配置性，而好的體系結構則需要好的設計方法，自然設計選型成為了系統設計首要的工作，究竟是采用哪種設計方法好呢?對于設計選型不能一概而論，需要針對項目的結構、項目的特征和用戶(hù)的需求來(lái)分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒(méi)有從事過(guò)面向對象的設計且項目進(jìn)對緊迫，這樣沒(méi)有多余的時(shí)間來(lái)培訓小組成員來(lái)掌握面向對象的設計方法，盡管眾所周知面向對象設計方法的優(yōu)勢，我們還是不如采用面向過(guò)程的方式(除用戶(hù)指定開(kāi)發(fā)設計方式外)可以減少項目承擔的技術(shù)風(fēng)險。

　　我們公司有過(guò)一個(gè)項目，用戶(hù)指定需要采用面向對象分析、設計和開(kāi)發(fā)，且開(kāi)發(fā)周期短，在無(wú)賴(lài)的情況下，項目小組只能選用面向對象的軟件開(kāi)發(fā)過(guò)程，由于項目小組很少從事過(guò)面向對象的開(kāi)發(fā)，經(jīng)驗缺乏，導致項目上馬后項目進(jìn)度延誤，項目沒(méi)有達到預期的效果。

　　針對此次開(kāi)發(fā)，我們分析其原因，發(fā)現小組成員在開(kāi)發(fā)過(guò)程中對于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導致工作重復性高，滯后項目進(jìn)度。建議解決方法是項目組成員采用集中辦公，分塊學(xué)習，學(xué)習的成果馬上向項目相關(guān)人員發(fā)布，再由配置管理員對其發(fā)布的文檔進(jìn)行整理、規類(lèi)放入配置庫以供大家共享。這樣方便大家的互相學(xué)習，減少重復的工作。在這次開(kāi)發(fā)中我們公司從管理人員、設計人員到開(kāi)發(fā)人員都汲取了很多教訓，同時(shí)經(jīng)過(guò)此次項目的開(kāi)發(fā)，小組成員也積累了豐富的面向對象的開(kāi)發(fā)經(jīng)驗。

　　除設計選型，還有一個(gè)容易被忽視的問(wèn)題，就是公共類(lèi)開(kāi)發(fā)。公共類(lèi)開(kāi)發(fā)可以減少工作中的重復工作，降低開(kāi)發(fā)成本。這要求我們再設計階段通過(guò)對用戶(hù)需求的仔細研究，盡可能的識別出公共類(lèi)，并進(jìn)行定義指定專(zhuān)人負責設計通知其它設計人員，以減少重復工作。對于項目組提供的設計文檔，由質(zhì)保小組組織技術(shù)專(zhuān)家、項目組設計人員、開(kāi)發(fā)人員和測試人員對其設計文檔的評審，檢測設計文檔對其下一階段工作的可行性，及時(shí)發(fā)現設計中可能存在的錯誤，降低項目開(kāi)發(fā)風(fēng)險，同時(shí)確保設計文檔能為開(kāi)發(fā)人員、測試人員提供切實(shí)的指導。對于可復用的設計進(jìn)行提取作為公共庫設計和開(kāi)發(fā)，提供項目組或整個(gè)公司重用。最后交由配置管理員進(jìn)行設計文檔的版本控制。

　　c、實(shí)現

　　實(shí)現也就是代碼的生產(chǎn)過(guò)程。這里不僅包括代碼的產(chǎn)生，同時(shí)也包括測試用例的產(chǎn)生。針對上一階段提供詳細設計，程序員開(kāi)始編碼并且調試程序，測試人員則根據設計進(jìn)行測試用例的設計，設計出來(lái)的用例需要得到項目組成員認可由項目經(jīng)理審核通過(guò)才能進(jìn)入配置庫。同時(shí)程序員調試完程序提交測試人員進(jìn)行程序正確性檢測。

　　d、文檔管理

　　文檔維護主要是配置管理小組的工作。文檔從用途上分主要分為內部文檔和外部文檔。

　　內部文檔包括： 項目開(kāi)發(fā)計劃; 需求分析; 體系結構設計說(shuō)明; 詳細設計說(shuō)明; 構件索引; 構件成分說(shuō)明; 構件接口及調用說(shuō)明; 組件索引;組件接口及調用說(shuō)明; 類(lèi)索引; 類(lèi)屬性及方法說(shuō)明; 測試報告; 測試統計報告; 質(zhì)量監督報告; 源代碼; 文檔分類(lèi)版本索引; 軟件安裝打包文件。

　　外部文檔主要包括： 軟件安裝手冊; 軟件操作手冊; 在線(xiàn)幫助; 系統性能指標報告; 系統操作索引。

　　如何保證文檔的全面性，使其真正為項目的進(jìn)度提供保證，又不因為文檔的寫(xiě)作而耽誤項目的進(jìn)度，這仍然是一個(gè)比較難解決的問(wèn)題。解決此問(wèn)題，其核心仍然是個(gè)"度"的問(wèn)題。在本項目的開(kāi)發(fā)中，配置管理小組的一個(gè)非常重要的任務(wù)還是書(shū)寫(xiě)文檔規范和文檔模板。當有文檔模板后需要書(shū)寫(xiě)文檔的人員只剩下"填空"的工作，從某種意義上講，書(shū)寫(xiě)文檔的速度會(huì )加快。如果書(shū)寫(xiě)文檔的人員認為文檔的更細致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時(shí)文檔并不算被正式提交，當他人書(shū)寫(xiě)完畢之后，必須由文檔的初寫(xiě)者進(jìn)行復審，復審通過(guò)后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。

　　配置管理小組真正核心的工作是對文檔的組織管理。根據文檔的不同，文檔的來(lái)源也不同，有些是通過(guò)質(zhì)量保證小組經(jīng)過(guò)復審之后轉交給配置管理小組，有些則會(huì )直接從文檔的出處到達配置管理小組。文檔的管理是一個(gè)非常煩瑣的工作，但是長(cháng)遠來(lái)看它不僅使項目的開(kāi)發(fā)對單個(gè)主要人員的依賴(lài)減少，從而減少人員流動(dòng)給項目的帶來(lái)的風(fēng)險，更重要的是在項目進(jìn)行到后百分之十的時(shí)候起到拉動(dòng)項目的作用。

　　從以往做大項目的經(jīng)驗來(lái)看，寫(xiě)作文檔在項目開(kāi)發(fā)的早期可能會(huì )使項目的進(jìn)度比起不寫(xiě)文檔要稍慢，但隨著(zhù)項目的進(jìn)展，各個(gè)部門(mén)需要配合越來(lái)越多，開(kāi)發(fā)者越來(lái)越需要知道其他人員的開(kāi)發(fā)思路和開(kāi)發(fā)過(guò)程，才能使自己的開(kāi)發(fā)向前推進(jìn)。一個(gè)明顯的例子就是系統整合，或者某些環(huán)節是建立在其他環(huán)節完成的基礎之上時(shí)，就更顯現出文檔交流的準確性和高效性。

　　3、系統維護質(zhì)量保證

　　在我們公司，維護小組的任務(wù)一方面是保證對項目客戶(hù)的跟蹤服務(wù)，另一方面是確保該項目其它的開(kāi)發(fā)人員從項目中盡快的解脫出來(lái)以便投入到下一個(gè)項目的開(kāi)發(fā)中。所以通常項目維護小組成員主要由項目組的少部分開(kāi)發(fā)人員承擔完成。他們不僅了解軟件的核心內容，而且與客戶(hù)也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當等引起的問(wèn)題，全部由維護小組執行完成，但需要用戶(hù)測試確認上線(xiàn)。如果較大的修改則需要走變更控制流程，用戶(hù)或者維護人員填寫(xiě)變更申請，經(jīng)專(zhuān)家會(huì )議討論分析可行方案在由維護小組實(shí)施，通過(guò)測試后方可提交用戶(hù)。

維護小組的人員基本上是按項目跟進(jìn)的。當一個(gè)項目剛剛交付用戶(hù)時(shí)，在維護小組有較多的人員進(jìn)行跟進(jìn)，隨軟件的穩定，跟進(jìn)的人逐步減少，并轉移到其它項目中去。 

                                                             2009-7-29