第一篇：有效的軟件質(zhì)量管理

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

51CMM.COM原創(chuàng) 作者：蘇黎虹 [2004/02/16]

一、引言

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

質(zhì)量管理包括：質(zhì)量計劃編制、質(zhì)量保證和質(zhì)量控制三個過程域。質(zhì)量計劃是質(zhì)量管理的第一過程域，它主要結(jié)合各個公司的質(zhì)量方針，產(chǎn)品描述以及質(zhì)量標(biāo)準(zhǔn)和規(guī)則通過收益、成本分析和流程設(shè)計等工具制定出來實施方略，其內(nèi)容全面反應(yīng)用戶的要求，為質(zhì)量小組成員有效工作提供了指南，為項目小組成員以及項目相關(guān)人員了解在項目進(jìn)行中如何實施質(zhì)量保證和控制提供依據(jù)，為確保項目質(zhì)量得到保障提供堅實的基礎(chǔ)。質(zhì)量保證則是貫穿整個項目全生命周期的有計劃和有系統(tǒng)的活動，經(jīng)常性地針對整個項目質(zhì)量計劃的執(zhí)行情況進(jìn)行評估、檢查與改進(jìn)等工作，向管理者、顧客或其他方提供信任，確保項目質(zhì)量與計劃保持一致。質(zhì)量控制是對階段性的成果進(jìn)行檢測、驗證，為質(zhì)量保證提供參考依據(jù)，它是一個PDCA循環(huán)過程。

二 質(zhì)量管理責(zé)任分配

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

1、配置管理小組職責(zé)

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

2、測試小組職責(zé)

測試小組作為質(zhì)量控制的主要手段，負(fù)責(zé)軟件的測試設(shè)計和執(zhí)行工作。如同軟件開發(fā)一樣，測試在執(zhí)行之前，同樣需要進(jìn)行測試計劃和測試策略的設(shè)計，通常情況下測試可以分為如下幾種類型，如：正確性測試、功能性測試、性能測試、安全測試和系統(tǒng)測試等。而這些測試均需要在測試計劃和測試策略中進(jìn)行描述用以指導(dǎo)測試小組成員進(jìn)行測試用例編寫和測試執(zhí)行。程序員在交給測試人員之前是進(jìn)行過一定的單元測試，確保程序編譯、運行正確。測試人員根據(jù)詳細(xì)設(shè)計的文檔對軟件要實現(xiàn)的功能進(jìn)行一一測試，保證軟件的執(zhí)行正確的實現(xiàn)設(shè)計要求，在此也只證明了軟件正確的反映了設(shè)計思想，但是否真正反映了用戶的需求仍需要進(jìn)一步的功能性測試。

測試人員只有根據(jù)軟件需求規(guī)格說明書所提及的功能進(jìn)行檢測，才能確保項目組開發(fā)的軟件產(chǎn)品滿足用戶需求。在正確性測試完成之后，需要測試的是軟件的性能，軟件的性能在本

項目中占有重要的地位，性能要求有可能改變軟件的設(shè)計，為避免造成軟件的后期返工，測試在性能上需要較大的側(cè)重。如果有必要的話，測試小組還需要做安全測試，以確保系統(tǒng)使用安全可靠。

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

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

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

三 質(zhì)量管理實施

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

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

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

項目計劃的合理程度與項目計劃制定者從事類似規(guī)模和類似業(yè)務(wù)的項目的經(jīng)驗有直接關(guān)系，通過經(jīng)驗往往能夠預(yù)見潛在的阻礙，這樣要求項目計劃制定者需要集眾人之力來完善計劃。當(dāng)項目計劃制定初期，由質(zhì)量保證小組組織召開的項目計劃評審會，邀請公司技術(shù)專家、用戶以及項目組小組成員一起討論項目計劃的可行性，會議通常采用頭腦風(fēng)暴法，各抒己見，會后由指定的記錄員形成質(zhì)量記錄，發(fā)送給相關(guān)人員，對其計劃中不合理的地方進(jìn)行修改完善，并由質(zhì)量保證人員對其結(jié)果跟蹤，以確保項目計劃完整性、可行性，完善后的計劃交由配置管理人員進(jìn)行版本控制。

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

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

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

51CMM.COM原創(chuàng) 作者：蘇黎虹 [2004/02/16]

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

a、需求分析

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

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

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

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

b、系統(tǒng)設(shè)計

優(yōu)良的體系結(jié)構(gòu)應(yīng)當(dāng)具備可擴展性和可配置性，而好的體系結(jié)構(gòu)則需要好的設(shè)計方法，自然設(shè)計選型成為了系統(tǒng)設(shè)計首要的工作，究竟是采用哪種設(shè)計方法好呢？

對于設(shè)計選型不能一概而論，需要針對項目的結(jié)構(gòu)、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒有從事過面向?qū)ο蟮脑O(shè)計且項目進(jìn)對緊迫，這樣沒有多余的時間來培訓(xùn)小組成員來掌握面向?qū)ο蟮脑O(shè)計方法，盡管眾所周知面向?qū)ο笤O(shè)計方法的優(yōu)勢，我們還是不如采用面向過程的方式（除用戶指定開發(fā)設(shè)計方式外）可以減少項目承擔(dān)的技術(shù)風(fēng)險。

我們公司有過一個項目，用戶指定需要采用面向?qū)ο蠓治觥⒃O(shè)計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，導(dǎo)致項目上馬后項目進(jìn)度延誤，項目沒有達(dá)到預(yù)期的效果。針對此次開發(fā)，我們分析其原因，發(fā)現(xiàn)小組成員在開發(fā)過程中對于新技術(shù)互相交流少，各自有各自的理解和想法，造成理解上的不一致性，導(dǎo)致工作重復(fù)性高，滯后項目進(jìn)度。建議解決方法是項目組成員采用集中辦公，分塊學(xué)習(xí)，學(xué)習(xí)的成果馬上向項目相關(guān)人員發(fā)布，再由配置管理員對其發(fā)布的文檔進(jìn)行整理、規(guī)類放入配置庫以供大家共享。這樣方便大家的互相學(xué)習(xí)，減少重復(fù)的工作。在這次開發(fā)中我們公司從管理人員、設(shè)計人員到開發(fā)人員都汲取了很多教訓(xùn)，同時經(jīng)過此次項目的開發(fā)，小組成員也積累了豐富的面向?qū)ο蟮拈_發(fā)經(jīng)驗。除設(shè)計選型，還有一個容易被忽視的問題，就是公共類開發(fā)。公共類開發(fā)可以減少工作中的重復(fù)工作，降低開發(fā)成本。這要求我們再設(shè)計階段通過對用戶需求的仔細(xì)研究，盡可能的識別出公共類，并進(jìn)行定義指定專人負(fù)責(zé)設(shè)計通知其它設(shè)計人員，以減少重復(fù)工作。對于項目組提供的設(shè)計文檔，由質(zhì)保小組組織技術(shù)專家、項目組設(shè)計人員、開發(fā)人員和測試人員對其設(shè)計文檔的評審，檢測設(shè)計文檔對其下一階段工作的可行性，及時發(fā)現(xiàn)設(shè)計中可能存在的錯誤，降低項目開發(fā)風(fēng)險，同時確保設(shè)計文檔能為開發(fā)人員、測試人員提供切實的指導(dǎo)。對于可復(fù)用的設(shè)計進(jìn)行提取作為公共庫設(shè)計和開發(fā)，提供項目組或整個公司重用。最后交由配置管理員進(jìn)行設(shè)計文檔的版本控制。

c、實現(xiàn)

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

d、文檔管理

文檔維護(hù)主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。內(nèi)部文檔包括： 項目開發(fā)計劃； 需求分析； 體系結(jié)構(gòu)設(shè)計說明； 詳細(xì)設(shè)計說明； 構(gòu)件索引； 構(gòu)件成分說明； 構(gòu)件接口及調(diào)用說明； 組件索引； 組件接口及調(diào)用說明； 類索引； 類屬性及方法說明； 測試報告； 測試統(tǒng)計報告； 質(zhì)量監(jiān)督報告； 源代碼； 文檔分類版本索引； 軟件安裝打包文件。

外部文檔主要包括： 軟件安裝手冊； 軟件操作手冊； 在線幫助； 系統(tǒng)性能指標(biāo)報告； 系統(tǒng)操作索引。

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

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

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

3、系統(tǒng)維護(hù)質(zhì)量保證

在我們公司，維護(hù)小組的任務(wù)一方面是保證對項目客戶的跟蹤服務(wù)，另一方面是確保該項目其它的開發(fā)人員從項目中盡快的解脫出來以便投入到下一個項目的開發(fā)中。所以通常項目維護(hù)小組成員主要由項目組的少部分開發(fā)人員承擔(dān)完成。他們不僅了解軟件的核心內(nèi)容，而且與客戶也不陌生，以便能夠以最快的速度修正錯誤。對于一般性的錯誤，如操作不當(dāng)?shù)纫鸬膯栴}，全部由維護(hù)小組執(zhí)行完成，但需要用戶測試確認(rèn)上線。如果較大的修改則需要走

變更控制流程，用戶或者維護(hù)人員填寫變更申請，經(jīng)專家會議討論分析可行方案在由維護(hù)小組實施，通過測試后方可提交用戶。

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

第二篇：軍用軟件質(zhì)量管理規(guī)定

軍用軟件質(zhì)量管理規(guī)定

第一章

總則

第一條

為了加強軍用軟件質(zhì)量管理，保證軍用軟件質(zhì)量，依據(jù)《裝備條例》制定本規(guī)定。

第二條

本規(guī)定適用于作為裝備或裝備組成部分的軟件質(zhì)量管理。

本規(guī)定中所稱的軍用軟件(以下簡稱軟件)包括計算機程序、相關(guān)文檔和數(shù)據(jù)，以及固化在硬件中的程序和數(shù)據(jù)。

第四條

總裝備部按照國家軍用標(biāo)準(zhǔn)和有關(guān)規(guī)定對軟件研制單位進(jìn)行軟件研制能力評價，對軟件測評機構(gòu)進(jìn)行認(rèn)可，并以合格名錄形式予以發(fā)布。未達(dá)到規(guī)定的軟件研制能力要求的單位，不能承擔(dān)軟件研制任務(wù);未經(jīng)認(rèn)可的軟件測評機構(gòu)不能承擔(dān)軟件測評任務(wù)。

第二章

職責(zé)

第七條承擔(dān)軟件研制任務(wù)的單位(以下簡稱研制單位)對軟件研制和服務(wù)質(zhì)量負(fù)責(zé)，履行下列職責(zé)：

(一)建立健全質(zhì)量管理體系，保持和改進(jìn)軟件研制能力，明確各類人員的質(zhì)量責(zé)任;

(二)實施軟件工程化管理，制訂本單位軟件研制工作程序和規(guī)范，對軟件研制過程實施質(zhì)量控制;

(三)配備必要的人員、技術(shù)手段和設(shè)施等資源，建立本單位軟件質(zhì)量信息系統(tǒng);

(四)對有缺陷的軟件進(jìn)行修復(fù);

(五)承擔(dān)軟件的使用培訓(xùn)和技術(shù)服務(wù);

(六)向軟件測評機構(gòu)提供軟件測評所需的程序和文檔資料。

第十條

軟件測評機構(gòu)對軟件的測評質(zhì)量負(fù)責(zé)，履行下列職責(zé)：

(一)建立健全質(zhì)量管理體系，保持和改進(jìn)軟件測評能力，明確軟件測評過程中各類人員的質(zhì)量責(zé)任;

(二)承擔(dān)軟件定型、鑒定、驗收和成果鑒定的測評，外購軟件產(chǎn)品質(zhì)量評價及選優(yōu)工作;

(三)制定本單位軟件測評工作的程序和規(guī)范，實施軟件測評過程的質(zhì)量控制;

(四)配置必要的軟件測評資源，建立軟件測評質(zhì)量信息系統(tǒng);

(五)開展軟件測評理論、技術(shù)和方法的研究。

第四章

軟件研制

第十七條裝備主管部門在訂立裝備研制合同時，應(yīng)當(dāng)在合同中明確軟件的級別、質(zhì)量保證條款、測評項目、測評機構(gòu)以及研制單位應(yīng)當(dāng)提供的測評保障條件。

第十八條

裝備主管部門應(yīng)當(dāng)組織對研制單位制訂的軟件研制計劃和軟件質(zhì)量保證計劃進(jìn)行審查和確認(rèn)，并監(jiān)督其實施。軟件質(zhì)量保證計劃應(yīng)當(dāng)明確軟件質(zhì)量要求、軟件質(zhì)量保證的工作責(zé)任、控制項目和方法、編制的文檔等。

第十九條

研制單位在進(jìn)行軟件需求分析時，應(yīng)當(dāng)廣泛征求軟件論證、使用、測評等單位的意見，按照國家軍用標(biāo)準(zhǔn)要求的內(nèi)容和格式，形成能夠全面反映系統(tǒng)任務(wù)要求的軟件需求說明。

第二十條

研制單位應(yīng)當(dāng)在軟件研制的早期對軟件保障進(jìn)行規(guī)劃，在軟件需求說明中提出軟件保障方案，并根據(jù)合同要求研制和交付軟件保障所需要的各種資源。

第二十一條

研制單位應(yīng)當(dāng)制訂和實施軟件設(shè)計準(zhǔn)則;開展軟件可靠性和安全性設(shè)計;按照軟件工程化方法和國家軍用標(biāo)準(zhǔn)的要求，形成與軟件需求說明一致的、可理解的和規(guī)范化的軟件設(shè)計文檔。

第二十二條

軟件編碼應(yīng)當(dāng)嚴(yán)格按照設(shè)計文檔進(jìn)行，確保編碼和設(shè)計文檔一致。

第二十三條

裝備主管部門應(yīng)當(dāng)對研制單位編制的軟件測試計劃進(jìn)行審查和確認(rèn)，并監(jiān)督其實施。軟件測試過程應(yīng)當(dāng)完整、準(zhǔn)確地記錄所有測試結(jié)果，填寫軟件問題報告表，編制軟件測試報告。

第二十四條

軟件設(shè)計、編碼和測試工作必須分別由不同的人員承擔(dān)。

第二十五條

研制單位必須按照國家軍用標(biāo)準(zhǔn)或相關(guān)標(biāo)準(zhǔn)要求的格式和內(nèi)容，在軟件研制過程中，同步完成各項文檔的編制工作。軟件文檔編制項目的剪裁和合并必須經(jīng)過裝備主管部門確認(rèn)。

第二十六條軟件配置管理必須設(shè)立軟件開發(fā)庫、受控庫和產(chǎn)品庫，并規(guī)定相應(yīng)的控制和管理程序。軟件文檔的修改和完善必須納入軟件配置管理。

第二十八條

研制單位應(yīng)當(dāng)建立并運行軟件故障報告、分析和糾正措施系統(tǒng)，及時記錄和報告軟件故障，采取糾正措施。

第二十九條

裝備主管部門應(yīng)當(dāng)對研制單位確定的轉(zhuǎn)承包單位的軟件開發(fā)能力和轉(zhuǎn)承包合同進(jìn)行審查。轉(zhuǎn)承包合同中應(yīng)當(dāng)明確轉(zhuǎn)承包軟件質(zhì)量保證條款、監(jiān)督和控制措施。

第三十條研制單位需要外購軟件產(chǎn)品的，應(yīng)當(dāng)按照要求進(jìn)行測試或者選型，并對其正確使用負(fù)責(zé)。

第三十一條

研制單位應(yīng)當(dāng)根據(jù)合同要求，向軟件測評機構(gòu)提供測試所需要的軟件需求說明、設(shè)計說明、源程序及開發(fā)過程測試文檔等技術(shù)文件，使測評機構(gòu)能夠充分了解軟件開發(fā)情況，保證軟件測評質(zhì)量。

第三十二條

研制單位應(yīng)當(dāng)編制軟件使用培訓(xùn)教材，并根據(jù)合同要求對軟件使用人員提供培訓(xùn)服務(wù)。

第五章

軟件測評

第三十三條

關(guān)鍵軟件和列入裝備體制的軟件，必須經(jīng)總裝備部認(rèn)可的軟件測評機構(gòu)測評合格后，方可交付部隊使用。

第三十四條

裝備主管部門應(yīng)當(dāng)在確定軟件研制任務(wù)的同時，確定軟件測評任務(wù)并下達(dá)軟件測評任務(wù)書。

第三十五條

軟件測評機構(gòu)應(yīng)當(dāng)從軟件需求分析階段開始進(jìn)行測評準(zhǔn)備工作，了解軟件研制情況，參加軟件評審;根據(jù)軟件的級別編制軟件測評計劃和測評說明，經(jīng)裝備主管部門組織評審?fù)ㄟ^后實施。

第三十六條

軟件測評機構(gòu)應(yīng)當(dāng)根據(jù)測評計劃建立軟件測試環(huán)境，嚴(yán)格按照規(guī)程實施軟件測評，及時、完整、準(zhǔn)確地記錄所有測試用例的測試結(jié)果。

對軟件測評機構(gòu)發(fā)現(xiàn)的軟件問題，研制單位應(yīng)當(dāng)進(jìn)行分析、修改、測試和評審后，送測評機構(gòu)進(jìn)行回歸測試。

第三十七條

軟件測評機構(gòu)應(yīng)當(dāng)根據(jù)軟件測評結(jié)果出具軟件測評報告。軟件測評報告由裝備主管部門組織評審。

第七章

獎勵與處分

第四十六條

對保證軟件質(zhì)量做出突出貢獻(xiàn)的單位和個人，按照國家和軍隊有關(guān)規(guī)定，給予獎勵。

第四十七條有下列行為之一的單位和個人，依照《中國人民解放軍紀(jì)律條令》和其他有關(guān)規(guī)定對負(fù)有直接責(zé)任的主管人員和其他直接責(zé)任人員給予處分;構(gòu)成犯罪的，依法追究刑事責(zé)任;對單位給予通報批評，并責(zé)令限期改正：

(一)濫用職權(quán)、徇私舞弊、弄虛作假的;

(二)違反工作程序、規(guī)章制度和操作規(guī)程，造成嚴(yán)重后果的;

(三)違反軟件工程化管理要求，軟件狀態(tài)失控，質(zhì)量問題突出，造成嚴(yán)重后果的;

(四)偽造測評結(jié)果或出具虛假證明的。

第四十八條

對違反合同、隱瞞質(zhì)量問題、將不合格品交付部隊的單位，裝備主管部門應(yīng)當(dāng)終止合同的履行，依照《中華人民共和國產(chǎn)品質(zhì)量法》和《中華人民共和國合同法》的有關(guān)規(guī)定提出賠償要求，并將其從合格名錄中剔除。

第三篇：論軟件項目的質(zhì)量管理

項目管理師論文之我見

聽聞許多考友論文沒過，實在可惜。我這次論文50分，不算高，勉強過關(guān)。我曾經(jīng)參加過系統(tǒng)分析師考試，論文沒過，這次選擇了項目管理師。這兩個考試作為高工級別，要求當(dāng)然高，和大家分享一點經(jīng)驗：

1、你一定要寫一個大項目，不能寫小項目。如果項目不夠大，你的高工職稱就令人質(zhì)疑了。你或許會問：我在的公司里就沒有大項目，怎么辦？去了解啊，了解親戚、朋友的公司里有沒有大項目，爭取拿到資料。

2、你一定要在論文中把自己描述成一個項目中的主要管理者，可以不是項目經(jīng)理，但級別不能太低。級別太低，你的高工職稱就令人質(zhì)疑了。你或許會問：我的級別就是低啊，只是一般的程序員。那沒關(guān)系，去了解你的上司的工作，在論文中把自己描述成你的上司。

3、一定要圍繞指定教材中的綱要來寫，比如今年下半年的考題，論項目風(fēng)險管理，論項目質(zhì)量管理，教材中都有專門的章節(jié)，在論文中一定要把這些理論闡述出來。不 能自己寫自己的，全然不管教材里怎么講。大家如果有看過今年上半年的試題分析，就一定記得在論文的解答中，特別強調(diào)“要有……，要有……”，這都是教材中 的理論，如果沒有，就沒分了。

4、項目管理師的論文題目不外乎教材中的那主要的幾章內(nèi)容，猜都能猜得到，事先一定要構(gòu)思好，考試時寫論文的時間很短，到時再作考慮時間肯定來不及。

5、字跡要工整，平常多寫，也是鍛煉。大家都是做電腦的，多年沒寫字了，打字比寫字還快?？墒强荚囘€是要寫字，大家有空時還是再練練字吧！

一點心得，個人觀點，僅供參考。

[摘要]

我目前擔(dān)任中國石化加油IC卡試點工程江蘇省項目的軟件技術(shù)總監(jiān)，并承擔(dān)了軟件的需求分析和部分的軟件開發(fā)工作，該工程浩大，復(fù)雜，但至關(guān)重要的是該系統(tǒng)的核心軟件的開發(fā)工作，該核心軟件跨平臺、跨地區(qū)、基于網(wǎng)絡(luò)，既有聯(lián)時交易，又有脫機交易，是基于網(wǎng)絡(luò)、大型關(guān)系數(shù)據(jù)庫的實時分布系統(tǒng)，由加油站后臺管理子系統(tǒng)、發(fā)卡充值網(wǎng)點子系統(tǒng)、加油站前臺POS消費子系統(tǒng)、加油站前臺卡機聯(lián)動系統(tǒng)、清算結(jié)算子系統(tǒng)、零售管理與數(shù)據(jù)分析子系統(tǒng)等組成，為了保證軟件按時保質(zhì)保量的完成，提高軟件的質(zhì)量與效率，作為技術(shù)總監(jiān)，我分析了決定軟件和影響軟件質(zhì)量的因素，制定了合適的質(zhì)量管理策略，通過加強項目管理和采取諸多針對性的做法，取得了較好的效果，具體敘述如下

質(zhì)量控制的主要活動:技術(shù)評審、代碼走查、代碼評審、單元測試、集成測試、壓力測試、系統(tǒng)測試、驗收測試、缺陷跟蹤。

[正文]

一、基于對軟件質(zhì)量管理的認(rèn)識與分析

我認(rèn)為，影響軟件質(zhì)量的因素有很多，通常有：人的因素、軟件需求、質(zhì)量問題可能出現(xiàn)在開發(fā)過程的各個環(huán)節(jié)上、測試的局限性、質(zhì)量管理的困難、質(zhì)量管理未能給予足夠的重視、軟件人員的傳統(tǒng)習(xí)慣、開發(fā)規(guī)范、開發(fā)工具的支持不夠等。對于象石化加油卡工程的核心軟件之類的大型軟件，涉及平臺多，開發(fā)環(huán)境多，開發(fā)人員龐大，在全國尚無大規(guī)模的同行業(yè)省級應(yīng)用模式可以參考。因此，我認(rèn)為軟件要能夠恰合需求是最為首要的質(zhì)量因素；其次，對于龐大的開發(fā)人員，對他們培養(yǎng)和樹立軟件質(zhì)量意識，按軟件工程標(biāo)準(zhǔn)規(guī)范開發(fā)流程，因此，質(zhì)量管理和開發(fā)過程控制也十分重要；再次，該核心軟件龐大、復(fù)雜、功能多、子系統(tǒng)多、接口多，我認(rèn)為，要在軟件開發(fā)生命周期內(nèi)重視軟件測試也至為關(guān)鍵。

目前，在業(yè)界影響較深的McCALL質(zhì)量模型、ISO軟件質(zhì)量評價模型以及SSC軟件質(zhì)量度量模型，都比較共同地列舉了軟件的質(zhì)量特性，如正確性、可靠性、完整性、優(yōu)化與效率、可維護(hù)性、可測試性、容錯性、文檔完備性、復(fù)用性、健壯性等等，要想使提交的軟件在各項指標(biāo)方面具有較高的性能和度量指標(biāo)，在軟件開發(fā)過程中，須采用切實可行和有針對性的措施方可達(dá)到要求。以下結(jié)合我工作中針對提高石化加油卡核心軟件質(zhì)量談?wù)劸唧w的管理策略、思維和做法。

二、具體實施的管理策略及做法

1、質(zhì)量管理策略的展開與實施

首先，我向公司的決策層強調(diào)了軟件質(zhì)量的重要性，并提交了具體的實施辦法。從組織上，我公司成立了軟件質(zhì)理管理領(lǐng)導(dǎo)小組，下設(shè)辦公室，有2名專職質(zhì)量管理人員，我作為辦公室主任。最主要開展了公司的集成資質(zhì)認(rèn)證和ISO9001軟件開發(fā)質(zhì)量認(rèn)證的取證工作，并最終獲得成功，同時開展了全體開發(fā)人員的軟件質(zhì)量意識教育，對開發(fā)人員進(jìn)行了系統(tǒng)的軟件工程軟件工程開發(fā)規(guī)范和相關(guān)標(biāo)準(zhǔn)教育。這些工作都是全員行動，涉及到的每個部門、每個開發(fā)小組以及個人，都要按照質(zhì)量管理規(guī)范要求開展各自的工作，這也是開發(fā)工作的基礎(chǔ)準(zhǔn)備工作。

2、高素質(zhì)軟件人才戰(zhàn)略

我始終認(rèn)識到軟件行業(yè)中人才的重要性以及人才在軟件質(zhì)量的重要作用，通過各種渠道，我們招聘了大量高素質(zhì)人員，但要使其發(fā)揮工作積極性，激發(fā)其工作熱情和責(zé)任感，通過我的努力和建議，人事部門制定了比較公平、公正、有效率的薪金激勵體系，例如建立了將開發(fā)人員分為系統(tǒng)分析員、高級程序員、程序員等五檔次十個級差的工資體系，最高人員可達(dá)月薪25000元/月，最底為2600元/月，同時給予人員以晉升和發(fā)展的空間，由于軟件開發(fā)行業(yè)的特殊性，我們還十分重視人員素質(zhì)提高與技術(shù)學(xué)習(xí)和交流，積極提倡和鼓勵人員參與中軟考和各類認(rèn)證考試以及職稱評審，這樣在公司內(nèi)形成了十分良好的積極進(jìn)取向上的科研與學(xué)習(xí)氣氛。

3、系統(tǒng)分析方法與模型選擇、開發(fā)平臺的選擇以及中間件開發(fā)平臺的引入

對于石油銷售行業(yè)，需求并不經(jīng)常變動，只是各地的需求和銷售策略有所不用，我認(rèn)為宜采用傳統(tǒng)的結(jié)構(gòu)化分析方法為主，結(jié)合面向?qū)ο蟮姆治龇椒ǎ谛枨蠓治銮捌?，以結(jié)構(gòu)化分析方法，摸清系統(tǒng)的原有業(yè)務(wù)流程以及數(shù)據(jù)流，在設(shè)計階段，在充分理解需求規(guī)格說明書的基礎(chǔ)上，應(yīng)采用面向?qū)ο蟮姆治雠c設(shè)計方法，這樣方可提高軟件的可靠性、復(fù)用性、可維護(hù)性等，也就提高了軟件的質(zhì)量。在開發(fā)平臺的選擇上，由于加油卡清費數(shù)據(jù)量巨大，首先是基本大型關(guān)系數(shù)據(jù)庫的應(yīng)用，我們選擇了SYBASE，開發(fā)工具采用了DELPHI

6、cylix分別用于WINDOWS平臺和LINUX平臺的開發(fā)，由于整個系統(tǒng)是采用集中式基于網(wǎng)絡(luò)的應(yīng)用，充值發(fā)卡為聯(lián)機交易而加油站加油卡數(shù)據(jù)是在油站產(chǎn)生通過撥號上傳的。為了保證操作事務(wù)的完整性，解決異構(gòu)和跨平臺的困難，采用了現(xiàn)今流行的中間件(BEA TUXEDO)開發(fā)技術(shù)，利用交易中間件實現(xiàn)聯(lián)機交易，利用通訊中間件解決加油站數(shù)據(jù)上傳，通過中間件中的兩階段提交技術(shù)，合理地利用了網(wǎng)絡(luò)帶寬，不至于與聯(lián)機交易相沖突，也保證了網(wǎng)絡(luò)不易擁塞而使數(shù)據(jù)不能上傳。

另外，我們還采用了各類CASE工具，用于軟件的建模、文檔管理、版本管理、方案演示等。

4、收集需求的多種做法

在軟件從分析到編碼設(shè)計以及測試的全過程，我們反復(fù)采用了“請進(jìn)來、走下去”的做法，即分析和開發(fā)人員一定要親臨業(yè)務(wù)現(xiàn)場，切身體會其中的業(yè)務(wù)操作，我們甚至要求與他們與業(yè)務(wù)人員打成一片，我們稱之為走下去，目的就是為了更準(zhǔn)確地把握需求。在開發(fā)時系統(tǒng)有了初步的軟件原型后，我們又將各地石油分公司的專業(yè)人員、業(yè)務(wù)人員請過來，請他們談?wù)剬π略偷目捶ê鸵庖?，并按照他們的意見再次對開發(fā)工作進(jìn)行修正，我們稱之?quot;請進(jìn)來“，目的是使確保軟件提交后能盡快地獲得用戶方滿意。這個過程，是循環(huán)反復(fù)，螺旋演進(jìn)的，通過這個過程，我們的軟件逐步達(dá)到了功能豐富、操作簡便易用、運行效率高、速度快的高質(zhì)量要求。據(jù)我們不完全統(tǒng)計，我們采用的”請進(jìn)來，走下去“的做法涉及到數(shù)百個人次，參與分析與開發(fā)的人員不但結(jié)交了很多朋友，而且也切身體會到這種做法對保證軟件質(zhì)量的重要之處。

5、基于”應(yīng)用微內(nèi)核“模塊的可擴展開發(fā)模式和思維的全面貫徹

雖然系統(tǒng)龐大，我們認(rèn)為軟件中最為基礎(chǔ)的是加油IC卡的核心支付模塊，是整個系統(tǒng)核心的核心，我稱之為大系統(tǒng)的”應(yīng)用微內(nèi)核“，是其他系統(tǒng)的數(shù)據(jù)源，其他模塊如清算結(jié)算子系統(tǒng)、油站零售管理與數(shù)據(jù)分析子系統(tǒng)，都是基于其上的擴展開發(fā)。因此，我要求，在核心級應(yīng)用內(nèi)核采用最為嚴(yán)格的軟件工程開發(fā)規(guī)范，并在其中留有足夠的數(shù)據(jù)庫的表中的數(shù)據(jù)元（字段），以便應(yīng)付多需求情況以及將來需求的可變性，這樣，可使應(yīng)用內(nèi)微具有較大的靈活性。例如，加油站累計消費優(yōu)惠，在各市公司采用不用的優(yōu)惠措施，有的是累計積分獎勵禮品，有的是累計現(xiàn)金，各地分公司由于經(jīng)營上的需要，還執(zhí)行了不同的油品價格政策，利用應(yīng)用內(nèi)核中的擴展字段很方便即可解決這個各地不同需求問題。應(yīng)用微內(nèi)核的采用還為其他系統(tǒng)提供了清晰的接口，例如，石化系統(tǒng)目前是正在作ERP軟件的試點，該軟件作為ERP底層數(shù)據(jù)源，十分方便地溶入了ERP系統(tǒng)中。微內(nèi)核還提高了系統(tǒng)的運行效率，微內(nèi)核代碼經(jīng)過了系統(tǒng)中最為嚴(yán)格的測試，有的模塊和代碼段一般都經(jīng)歷了四版以上才定稿，有的甚至在經(jīng)歷了十次以上的版本。我們還在開發(fā)前開展了較為有趣的編程優(yōu)化大賽，誰的程序效率高、算法優(yōu)、速度快，就選其中的人員參與到微內(nèi)核開發(fā)組，并在薪水和獎金給予這些人員適當(dāng)?shù)纳细　?/p>

6、加強測試

為了提高軟件質(zhì)量，我們還十分重視軟件的測試工作，成立了專業(yè)的測試小組，用于測試開發(fā)的軟件和廠商提交的加油機卡機聯(lián)動樣機、消費POS、充值POS等，由于為全行業(yè)工程，中國石化統(tǒng)一了加油IC卡卡規(guī)范、重新修訂了加油機通訊協(xié)議，這些都需要進(jìn)行測試，方可準(zhǔn)予廠商進(jìn)場作業(yè)，為此開發(fā)部門還編制了相關(guān)的測試軟件，通過測試后，方可發(fā)證與廠商。對核心軟件，除了我們內(nèi)部進(jìn)行單元測試和集成測試和初步系統(tǒng)α測試外，我們還委托中國計算機軟件測評中心這樣的專業(yè)測評機構(gòu)進(jìn)行最終確認(rèn)測試。在試用版投入試點過程中，我們還與各地石油分司共同建立了測試維護(hù)制度與維護(hù)操作辦法，落實了具體人員，收集了大量測試數(shù)據(jù)，全面地進(jìn)行了β版測試，此舉也從運行現(xiàn)場發(fā)現(xiàn)了很多開發(fā)環(huán)境下所沒有發(fā)現(xiàn)的問題，對提高軟件質(zhì)量起到了重要的作用。

三、完成的效果與評價

加強軟件質(zhì)量管理的做法還有很多，對其中的一些細(xì)節(jié)本文也不再討論。如上所述，其做法基本上源于我參與多年的軟件開發(fā)項目和項目管理的經(jīng)驗所得，當(dāng)然在這個項目中我們也有所創(chuàng)新，如”應(yīng)用微內(nèi)核"的開發(fā)思想和思維的實施。這些做法從總體上保證了軟件的高質(zhì)量。當(dāng)然，質(zhì)量管理的內(nèi)容與做法也要與時俱進(jìn)。

但由于自己不是公司的決策層，僅負(fù)責(zé)軟件技術(shù)方面的工作，對部分骨干人員的出走以及因項目各方利益的關(guān)系，從而影響了軟件的開發(fā)和進(jìn)度也無能為力。從這個項目來看，軟件的開發(fā)仍然是整個工程推進(jìn)的瓶頸，其開發(fā)進(jìn)度與提交對整體加油卡工程進(jìn)度影響很大，傳統(tǒng)的軟件開發(fā)問題在這個項目中也依然遇到。近些年來，軟件行業(yè)的CMM認(rèn)證較為流行，可使公司軟件過程能力成熟度得到較大提高，我想這也是將來在軟件質(zhì)量方面的努力之處?？傊瑢τ谲浖椖块_發(fā)，人的作用和質(zhì)量管理的作用都十分的重要，我也期待著在將來能不斷提高自已的技術(shù)與管理水平，也能夠希望更多的專業(yè)人員投入到軟件質(zhì)量管理的研究中來，為提高我國軟件產(chǎn)業(yè)的軟件質(zhì)量而奮斗。

第四篇：軟件項目質(zhì)量管理實戰(zhàn)總結(jié)

軟件項目質(zhì)量管理實戰(zhàn)總結(jié)

第一章 引言

許多IT項目開發(fā)的系統(tǒng)應(yīng)用在生死攸關(guān)的場合。例如，1981年，由計算機程序改變而導(dǎo)致的1/67的時間偏差，使航天飛機上的5臺計算機不能同步運行，這個錯誤導(dǎo)致了航天飛機發(fā)射失敗。1986年，1臺Therac25機器泄露致命劑量的輻射，致使兩名醫(yī)院病人死亡。造成慘劇的原因是一個軟件出現(xiàn)了問題，導(dǎo)致這臺機器忽略了數(shù)據(jù)校驗。這些慘痛的教訓(xùn)說明，在軟件開發(fā)項目中認(rèn)真抓好質(zhì)量管理，并加強有關(guān)軟件項目質(zhì)量管理的研究是擺在我們面前的重要課題。

軟件項目質(zhì)量管理包括：質(zhì)量計劃編制、質(zhì)量保證和質(zhì)量控制三個過程域。質(zhì)量計劃是質(zhì)量管理的第一過程域，它主要結(jié)合各個公司的質(zhì)量方針，產(chǎn)品描述以及質(zhì)量標(biāo)準(zhǔn)和規(guī)則通過收益、成本分析和流程設(shè)計等工具制定出來實施方略，其內(nèi)容全面反應(yīng)用戶的要求，為質(zhì)量小組成員有效工作提供了指南，為項目小組成員以及項目相關(guān)人員了解在項目進(jìn)行中如何實施質(zhì)量保證和控制提供依據(jù)，為確保項目質(zhì)量得到保障提供堅實的基礎(chǔ)。質(zhì)量保證則是貫穿整個項目全生命周期的有計劃和有系統(tǒng)的活動，經(jīng)常性地針對整個項目質(zhì)量計劃的執(zhí)行情況進(jìn)行評估、檢查與改進(jìn)等工作，向管理者、顧客或其他方提供信任，確保項目質(zhì)量與計劃保持一致。質(zhì)量控制是對階段性的成果進(jìn)行檢測、驗證，為質(zhì)量保證提供參考依據(jù)，它是一個PDCA循環(huán)過程。

第二章 對軟件項目質(zhì)量管理理論的認(rèn)識

軟件項目的質(zhì)量管理指的是保證項目滿足其目標(biāo)要求所需要的過程，它包括編制質(zhì)量計劃、質(zhì)量控制、質(zhì)量保證等過程。

2.1 質(zhì)量計劃編制

現(xiàn)代質(zhì)量管理的基本宗旨是：“質(zhì)量出自計劃，而非出自檢查”。只有做出精準(zhǔn)的質(zhì)量計劃，才能指導(dǎo)項目的實施、做好質(zhì)量控制。

編制項目的質(zhì)量計劃，首先必須確定項目的范圍、中間產(chǎn)品和最終產(chǎn)品，然后明確關(guān)于中間產(chǎn)品和最終產(chǎn)品的有關(guān)規(guī)定、標(biāo)準(zhǔn)，確定可能影響產(chǎn)品質(zhì)量的技術(shù)要點，并找出能夠確保高效滿足相關(guān)規(guī)定、標(biāo)準(zhǔn)的過程方法。編制質(zhì)量計劃通常采用流程圖、因果分析圖等方法對項目進(jìn)行分析，確定需要監(jiān)控的關(guān)鍵元素，設(shè)置合理的見證點(W點)、停工待檢點(H點)，并制定質(zhì)量標(biāo)準(zhǔn)：

1)流程圖：

顯示系統(tǒng)的各種成分是如何相互關(guān)系的，幫助我們預(yù)測在何處可能發(fā)生何種質(zhì)量問題，并由此幫助開發(fā)處理他們的辦法。

2)因果分析圖(也稱魚刺圖)：

對于復(fù)雜的項目，編制質(zhì)量計劃時可以采用因果分析圖，描述相關(guān)的各種原因和子原因如何產(chǎn)生潛在問題或影響，將影響質(zhì)量問題的“人員、設(shè)備、參考資料、方法、環(huán)境”等各方面的原因進(jìn)行細(xì)致的分解，方便地在質(zhì)量計劃中制定相應(yīng)的預(yù)防措施。其次，質(zhì)量計劃中還必須確定有效的質(zhì)量管理體系，明確質(zhì)量監(jiān)理人員對項目質(zhì)量負(fù)責(zé)和各級質(zhì)量管理人員的權(quán)限。戴明環(huán)(又名PDCA循環(huán)法)作為有效的管理工具在質(zhì)量管理中得到廣泛的應(yīng)用，它采用計劃——執(zhí)行——檢查——措施的質(zhì)量環(huán)，質(zhì)量計劃中必須將質(zhì)量環(huán)上各環(huán)節(jié)明確落實到各責(zé)任單位，才能保證質(zhì)量計劃的有效實施。

2.2 按照質(zhì)量計劃實施有效的質(zhì)量控制

質(zhì)量計劃確定后，按照其建立的質(zhì)量管理體系，各責(zé)任單位就必須按照PDCA質(zhì)量環(huán)的要求，實施有效的質(zhì)量控制。質(zhì)量控制應(yīng)貫穿于項目的整個過程，它可分為監(jiān)測和控制兩個階段：監(jiān)測的目的就是收集、記錄和匯報有關(guān)項目質(zhì)量的數(shù)據(jù)信息;控制就是使用質(zhì)量監(jiān)測提供的數(shù)據(jù)，進(jìn)行控制，確保項目質(zhì)量與計劃保持一致。

在質(zhì)量監(jiān)測過程中，對于質(zhì)量計劃中設(shè)置的見證點、停工待檢點，質(zhì)量監(jiān)測人員要按照作業(yè)程序及時進(jìn)行測量檢查(其中對于停工待檢點必須由監(jiān)理人員簽字認(rèn)可后才能進(jìn)入下一道工序)，以確定項目成果(或階段成果)是否符合相關(guān)的質(zhì)量標(biāo)準(zhǔn)。對于見證點或停工待檢點要防止跳過檢查，因為避免錯誤的成本總是大大低于補救錯誤的成本。對質(zhì)量監(jiān)測的結(jié)果應(yīng)采用相應(yīng)的統(tǒng)計方法進(jìn)行分析，如帕累托圖法(按發(fā)生頻率排序的直方圖，它顯示了可識別原因的種類和所造成的結(jié)果的數(shù)量)等。通過統(tǒng)計分析對人員、設(shè)備、參考資料、方法、環(huán)境等影響項目質(zhì)量的因素進(jìn)行監(jiān)控，確定項目實施過程是否在控制之中，同時進(jìn)行趨勢分析，對一些偏向于不合格的趨勢及早進(jìn)行控制。質(zhì)量控制階段應(yīng)根據(jù)驗收數(shù)據(jù)做出驗收決定，確定是否進(jìn)入下一步工序。對于質(zhì)量監(jiān)測中發(fā)現(xiàn)的不合格，應(yīng)及時利用“因果分析圖”等方法分析原因，并進(jìn)行適宜的處置，保證不合格得到識別和有效的控制。不合格處置包括返工、返修、降級、讓步放行、報廢等形式。

質(zhì)量監(jiān)測分析時，對于已發(fā)現(xiàn)的不合格或潛在不合格，應(yīng)制定相應(yīng)的糾正措施或預(yù)防措施，以消除不合格或潛在不合格的原因，防止不合格的發(fā)生。糾正措施或預(yù)防措施制定后，應(yīng)對質(zhì)量計劃進(jìn)行相應(yīng)的調(diào)整，保證項目的順利實施。

項目收尾包括項目評估和項目終止兩個階段。項目收尾階段的質(zhì)量控制是一個非常重要而又容易忽視的內(nèi)容。

項目質(zhì)量評估不僅僅是在項目完成后進(jìn)行，還包括對項目實施過程中的各個關(guān)鍵點的質(zhì)量評估。項目質(zhì)量評估看起來屬于事后控制，但它的目的不是為了改變那些已經(jīng)發(fā)生的事情，而是試圖抓住項目質(zhì)量合格或不合格的精髓，以使將來的項目質(zhì)量管理能從中獲益。

項目終止階段，是在決策項目終止后，檢查項目文件資料完備，包括項目施工質(zhì)量驗評表、竣工報告等，同時進(jìn)行項目總結(jié)。項目總結(jié)是一個把實際運行情況與項目計劃不斷比較以提煉經(jīng)驗教訓(xùn)的過程。通過項目質(zhì)量計劃和總結(jié)，項目過程中的經(jīng)驗和教訓(xùn)將得到完整的記錄和升華，成為“組織財富”。

四、項目質(zhì)量管理的難點

每個項目的實施總是擁有同樣的總體目標(biāo)：質(zhì)量、時間和成本。三者是一個相互制約、相互影響的統(tǒng)一體，其中任一項目標(biāo)變化，都會引起另兩個目標(biāo)變化，并受其制約。如何合理的保證項目質(zhì)量，正確處理質(zhì)量與時間、成本之間的矛盾是項目質(zhì)量管理的一個難點，這需要整合項目所有方面的內(nèi)容，保證按時、低成本地實現(xiàn)預(yù)定的質(zhì)量目標(biāo)。

根據(jù)側(cè)重點不同，項目可分為質(zhì)量傾斜型、工期傾斜型及成本傾斜型體系。我們在編制項目計劃時，一般而言是時間、成本、質(zhì)量標(biāo)準(zhǔn)均已確定，在項目實施過程中就需在從客觀因素、具體情況出發(fā)，根據(jù)將要采取的行動和可能導(dǎo)致的后果進(jìn)行綜合分析研究;按切合實際的原則，使項目進(jìn)展平衡有節(jié)奏地進(jìn)行，以求達(dá)到預(yù)期目標(biāo)。避免出現(xiàn)工期緊張或成本減少，導(dǎo)致質(zhì)量降低的現(xiàn)象，而質(zhì)量下降又往往造成返工等后果而導(dǎo)致延長工期和增加成本。

2.3 對軟件質(zhì)量保證的認(rèn)識

2.3.1 有關(guān)SQA的理論

我們都知道一個項目的主要內(nèi)容是：成本、進(jìn)度、質(zhì)量;良好的項目管理就是綜合三方面的因素，平衡三方面的目標(biāo)，最終依照目標(biāo)完成任務(wù)。項目的這三個方面是相互制約和影響的，有時對這三方面的平衡策略甚至成為一個企業(yè)級的要求，決定了企業(yè)的行為，我們知道 IBM的軟件是以質(zhì)量為最重要目標(biāo)的，而微軟的“足夠好的軟件”策略更是耳熟能詳，這些質(zhì)量目標(biāo)其實立足于企業(yè)的戰(zhàn)略目標(biāo)。所以用于進(jìn)行質(zhì)量保證的SQA 工作也應(yīng)當(dāng)立足于企業(yè)的戰(zhàn)略目標(biāo)，從這個角度思考SQA，形成對SQA的理論認(rèn)識。

軟件界已經(jīng)達(dá)成共識的：影響軟件項目進(jìn)度、成本、質(zhì)量的因素主要是 “人、過程、技術(shù)”。首先要明確的是這三個因素中，人是第一位的。

現(xiàn)在許多實施 CMM的人員沉溺于CMM的理論過于強調(diào)“過程”，這是很危險的傾向。這個思想傾向在國外受到了猛烈抨擊，從某種意義上各種敏捷過程方法的提出就是對強調(diào)過程的一種反思?！癤P”中的一個思想“人比過程更重要” 是值得我們思考的。我個人的意見在進(jìn)行過程改進(jìn)中堅持“以人為本”，強調(diào)過程和人的和諧。

根據(jù)現(xiàn)代軟件工程對眾多失敗項目的調(diào)查，發(fā)現(xiàn)管理是項目失敗的主要原因。這個事實的重要性在于說明了 “要保證項目不失敗，我們應(yīng)當(dāng)更加關(guān)注管理”，注意這個事實沒有說明另外一個問題“良好的管理可以保證項目的成功”。現(xiàn)在很多人基于一種粗糙的邏輯，從一個事實反推到的這個結(jié)論，在邏輯上是錯誤的，這種錯誤形成了更加錯誤的做法，這點在SQA的理解上是體現(xiàn)較深。

如果我們考證一下歷史的沿革，應(yīng)當(dāng)更加容易理解 CMM的本質(zhì)。CMM首先是作為一個“評估標(biāo)準(zhǔn)”出現(xiàn)的，主要評估的是美國國防部供應(yīng)商保證質(zhì)量的能力。CMM關(guān)注的軟件生產(chǎn)有如下特點：

(1)質(zhì)量重要

(2)規(guī)模較大

這是 CMM產(chǎn)生的原因。它引入了“全面質(zhì)量管理”的思想，尤其側(cè)重了“全面質(zhì)量管理”中的“過程方法”，并且引入了“統(tǒng)計過程控制”的方法?？梢哉f這兩個思想是CMM背后的基礎(chǔ)。

上面這些內(nèi)容形成了我們對軟件過程地位、價值的基本理解;在這個基礎(chǔ)上我們可以引申討論 SQA。

2.3.2 生產(chǎn)線的隱喻

如果將一個軟件生產(chǎn)類比于一個工廠的生產(chǎn)。那么生產(chǎn)線就是過程，產(chǎn)品按照生產(chǎn)線的規(guī)定過程進(jìn)行生產(chǎn)。SQA的職責(zé)就是保證過程的執(zhí)行，也就是保證生產(chǎn)線的正常執(zhí)行。

抽象出管理體系模型的如下，這個模型說明了一個過程體系至少應(yīng)當(dāng)包含 “決策、執(zhí)行、反饋”三個重要方面。

QA的職責(zé)就是確保過程的有效執(zhí)行，監(jiān)督項目按照過程進(jìn)行項目活動;它不負(fù)責(zé)監(jiān)管產(chǎn)品的質(zhì)量，不負(fù)責(zé)向管理層提供項目的情況，不負(fù)責(zé)代表管理層進(jìn)行管理，只是代表管理層來保證過程的執(zhí)行。

2.3.3 SQA和其他工作的組合

在很多企業(yè)中，將 SQA的工作和QC、SEPG、組織級的項目管理者的工作混合在一起了，有時甚至更加注重其他方面的工作而沒有做好SQA的本職工作。

國內(nèi)現(xiàn)在基本有三種QA(按照工作重點不同來分)：一是過程改進(jìn)型，一是配置管理型，一是測試型。個人認(rèn)為是因為SQA工作和其他不同工作組合在一起形成的。

下面根據(jù)經(jīng)驗對它們之間的關(guān)系進(jìn)行一個說明。

QA和QC ,兩者基本職責(zé);

QC：檢驗產(chǎn)品的質(zhì)量，保證產(chǎn)品符合客戶的需求;是產(chǎn)品質(zhì)量檢查者;

QA：審計過程的質(zhì)量，保證過程被正確執(zhí)行;是過程質(zhì)量審計者;

注意區(qū)別檢查和審計的不同，檢查：就是我們常說的找茬，是挑毛病的;

審計：來確認(rèn)項目按照要求進(jìn)行的證據(jù);仔細(xì)看看CMM中各個KPA中SQA的檢查采用的術(shù)語大量用到了“證實”，審計的內(nèi)容主要是過程的;對照CMM看一下項目經(jīng)理和高級管理者的審查內(nèi)容，他們更加關(guān)注具體內(nèi)容。

對照上面的管理體系模型，QC進(jìn)行質(zhì)量控制，向管理層反饋質(zhì)量信息;QA則確保QC按照過程進(jìn)行質(zhì)量控制活動，按照過程將檢查結(jié)果向管理層匯報。這就是QA和QC工作的關(guān)系。

在這樣的分工原則下，QA只要檢查項目按照過程進(jìn)行了某項活動沒有，產(chǎn)出了某個產(chǎn)品沒有;而QC來檢查產(chǎn)品是否符合質(zhì)量要求。

如果企業(yè)原來具有 QC人員并且QA人員配備不足，可以先確定由QC兼任QA工作。但是只能是暫時的，獨立的QA人員應(yīng)當(dāng)具備，因為QC工作也是要遵循過程要求的，也是要被審計過程的，這種混合情況，難以保證QC工作的過程質(zhì)量。

QA 和SEPG，兩者基本職責(zé)。SEPG：制定過程，實施過程改進(jìn);QA：確保過程被正確執(zhí)行。SEPG應(yīng)當(dāng)提供過程上的指導(dǎo)，幫助項目組制定項目過程，幫助項目組進(jìn)行策劃;從而幫助項目組有效的工作，有效的執(zhí)行過程。如果項目和QA對過程的理解發(fā)生爭持，SEPG作為最終仲裁者。為了進(jìn)行有效過程改進(jìn)，SEPG必須分析項目的數(shù)據(jù)。QA本也要進(jìn)行過程規(guī)范，那么所有QA中最有經(jīng)驗、最有能力的QA可以參加SEPG，但是要注意這兩者的區(qū)別。

如果企業(yè)的 SEPG人員具有較為深厚的開發(fā)背景，可以兼任SQA工作，這樣利于過程的不斷改進(jìn);但是由于立法、執(zhí)法集于一身也容易造成SQA過于強勢，影響項目的獨立性。

管理過程比較成熟的企業(yè)，因為企業(yè)的文化和管理機制已經(jīng)健全，SQA職責(zé)范圍的工作較少，往往只是針對具體項目制定明確重點的SQA計劃，這樣SQA的審計工作會大大減少，從而可以同時審計較多項目。

另一方面，由于分工的細(xì)致化，管理體系的復(fù)雜化，往往需要專職的 SEPG人員，這些人員要求了解企業(yè)的所有管理過程和運作情況，在這個基礎(chǔ)上才能統(tǒng)籌全局的進(jìn)行過程改進(jìn)，這時了解全局的SQA人員就是專職SEPG的主要人選;這些SQA人員將逐漸的轉(zhuǎn)化為SEPG人員，并且更加了解管理知識，而SQA工作漸漸成為他們的兼職工作。這種情況在許多 CMM5企業(yè)比較多見，往往有時看不見SQA人員在項目組出現(xiàn)或者很少出現(xiàn)，這種SEPG和SQA的融合特別有利于組織的過程改進(jìn)工作。SEPG確定過程改進(jìn)內(nèi)容，SQA計劃重點反映這些改進(jìn)內(nèi)容，從保證有效的改進(jìn)，特別有利于達(dá)到CMM5的要求。從這個角度，國外的SQA人員為什么高薪就不難理解了，也決定了當(dāng)前中國SQA人員比較被輕視的原因;因為管理過程還不完善，我國的SQA人員還沒有產(chǎn)生這么大的價值。

2.3.4 QA和組織級的監(jiān)督管理

有的企業(yè)為了更好的監(jiān)督管理項目，建立了一個角色，我取名為 “組織級的監(jiān)督管理者”，他們的職責(zé)是對所有項目進(jìn)行統(tǒng)一的跟蹤、監(jiān)督、適當(dāng)?shù)墓芾?，來保證管理層對所有項目的可視性、可管理性。為了有效管理項目，“組織級的監(jiān)督管理者”必須分析項目的數(shù)據(jù)。他們的職責(zé)對照上圖的模型，就是執(zhí)行 “反饋”職能。

QA本身不進(jìn)行反饋工作，最多對過程執(zhí)行情況的信息進(jìn)行反饋。SQA職責(zé)最好不要和“組織級的項目管理者”的職責(zé)混合在一起，否則容易出現(xiàn)SQA困境：一方面SQA不能準(zhǔn)確定位自己的工作，另一方面過程執(zhí)行者對SQA人員抱有較大戒心。

如果建立了較好的管理過程，那么就會增強項目的可視性，從而保證企業(yè)對所有項目的較好管理;而 QA來確保這個管理過程的運行。

2.3.5 SQA的工作內(nèi)容和工作方法

2.3.5.1 計劃

針對具體項目制定 SQA計劃，確保項目組正確執(zhí)行過程。制定SQA計劃應(yīng)當(dāng)注意如下幾點：

有重點：依據(jù)企業(yè)目標(biāo)以及項目情況確定審計的重點。

明確審計內(nèi)容：明確審計哪些活動，那些產(chǎn)品。

明確審計方式：確定怎樣進(jìn)行審計。

明確審計結(jié)果報告的規(guī)則：審計的結(jié)果報告給誰。

2.3.5.2 審計/證實

依據(jù) SQA計劃進(jìn)行SQA審計工作，按照規(guī)則發(fā)布審計結(jié)果報告。注意審計一定要有項目組人員陪同，不能搞突然襲擊。雙方要開誠布公，坦誠相對。審計的內(nèi)容：是否按照過程要求執(zhí)行了相應(yīng)活動，是否按照過程要求產(chǎn)生了相應(yīng)產(chǎn)品。

2.3.5.3 問題跟蹤

對審計中發(fā)現(xiàn)的問題，要求項目組改進(jìn)，并跟進(jìn)直到解決。

2.3.5.4 SQA的素質(zhì)

過程為中心：應(yīng)當(dāng)站在過程的角度來考慮問題，保證了過程，QA就盡到了責(zé)任。

服務(wù)精神：為項目組服務(wù)，幫助項目組確保正確執(zhí)行過程。

了解過程：深刻了解企業(yè)的工程，并具有一定的過程管理理論知識。

了解開發(fā)：對開發(fā)工作的基本情況了解，能夠理解項目的活動。

溝通技巧：善于溝通，能夠營造良好的氣氛，避免審計活動成為一種找茬活動。第三章 軟件項目質(zhì)量管理在實際中的具體做法

3.1 質(zhì)量管理責(zé)任分配

筆者曾在美國TAJ Technologies公司任軟件工程師工作。TAJ Technologies公司(位于美國明尼蘇達(dá)州，有約200名員工)在開發(fā)項目上按照規(guī)范化軟件的生產(chǎn)方式進(jìn)行生產(chǎn)，在生產(chǎn)流程上采用ISO9000 的標(biāo)準(zhǔn)進(jìn)行。每個項目除配備了項目開發(fā)所需角色外，還專門配備了配置管理小組、測試小組和質(zhì)量保證小組確保質(zhì)量管理的實施，下面針對這三種角色進(jìn)行說明：

3.1.1 配置管理小組職責(zé)

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

3.1.2 測試小組職責(zé)

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

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

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

3.1.3 質(zhì)量保證小組職責(zé)

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

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

3.2 質(zhì)量管理實施

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

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

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

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

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

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

實際運作中，當(dāng)質(zhì)保小組發(fā)現(xiàn)計劃實施的差異后，報告項目經(jīng)理，由項目經(jīng)理組織負(fù)責(zé)對計劃進(jìn)行周期性維護(hù)，對于已經(jīng)變動的計劃由質(zhì)保小組協(xié)助配置管理小組完成版本控制。

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

a、需求分析

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

解決系統(tǒng)分析錯誤的方法。TAJ Technologies公司通常采用邀請用戶參與進(jìn)行需求評定，然后對其用戶的意見由質(zhì)保成員跟蹤檢測是否納入需求規(guī)格說明書，同時與用戶簽字確認(rèn)形成需求基線，交由配置管理員放入配置管理庫。

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

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

b、系統(tǒng)設(shè)計

優(yōu)良的體系結(jié)構(gòu)應(yīng)當(dāng)具備可擴展性和可配置性，而好的體系結(jié)構(gòu)則需要好的設(shè)計方法，自然設(shè)計選型成為了系統(tǒng)設(shè)計首要的工作，究竟是采用哪種設(shè)計方法好呢?

對于設(shè)計選型不能一概而論，需要針對項目的結(jié)構(gòu)、項目的特征和用戶的需求來分析，同樣也要考慮到參與項目小組成員的素質(zhì)，如果其中大部分都沒有從事過面向?qū)ο蟮脑O(shè)計且項目進(jìn)對緊迫，這樣沒有多余的時間來培訓(xùn)小組成員來掌握面向?qū)ο蟮脑O(shè)計方法，盡管眾所周知面向?qū)ο笤O(shè)計方法的優(yōu)勢，我們還是不如采用面向過程的方式(除用戶指定開發(fā)設(shè)計方式外)可以減少項目承擔(dān)的技術(shù)風(fēng)險。

TAJ Technologies公司有過一個項目，用戶指定需要采用面向?qū)ο蠓治觥⒃O(shè)計和開發(fā)，且開發(fā)周期短，在無賴的情況下，項目小組只能選用面向?qū)ο蟮能浖_發(fā)過程，由于項目小組很少從事過面向?qū)ο蟮拈_發(fā)，經(jīng)驗缺乏，導(dǎo)致項目上馬后項目進(jìn)度延誤，項目沒有達(dá)到預(yù)期的效果。

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

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

c、實現(xiàn)

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

d、文檔管理

文檔維護(hù)主要是配置管理小組的工作。文檔從用途上分主要分為內(nèi)部文檔和外部文檔。

內(nèi)部文檔包括： 項目開發(fā)計劃;需求分析;體系結(jié)構(gòu)設(shè)計說明;詳細(xì)設(shè)計說明;構(gòu)件索引;構(gòu)件成分說明;構(gòu)件接口及調(diào)用說明;組件索引;組件接口及調(diào)用說明;類索引;類屬性及方法說明;測試報告;測試統(tǒng)計報告;質(zhì)量監(jiān)督報告;源代碼;文檔分類版本索引;軟件安裝打包文件。

外部文檔主要包括： 軟件安裝手冊;軟件操作手冊;在線幫助;系統(tǒng)性能指標(biāo)報告;系統(tǒng)操作索引。

如何保證文檔的全面性，使其真正為項目的進(jìn)度提供保證，又不因為文檔的寫作而耽誤項目的進(jìn)度，這仍然是一個比較難解決的問題。解決此問題，其核心仍然是個“ 度”的問題。

在本項目的開發(fā)中，配置管理小組的一個非常重要的任務(wù)還是書寫文檔規(guī)范和文檔模板。當(dāng)有文檔模板后需要書寫文檔的人員只剩下“填空”的工作，從某種意義上講，書寫文檔的速度會加快。如果書寫文檔的人員認(rèn)為文檔的更細(xì)致的部分可以由他人幫助完成，則該文檔即交由他人完成，但此時文檔并不算被正式提交，當(dāng)他人書寫完畢之后，必須由文檔的初寫者進(jìn)行復(fù)審，復(fù)審?fù)ㄟ^后方可以正式提交，進(jìn)入軟件配置管理的循環(huán)中。

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

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

3.2.2 系統(tǒng)維護(hù)質(zhì)量保證

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

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

未完待續(xù)

第五篇：軟件質(zhì)量管理部規(guī)檔

軟件質(zhì)量管理部規(guī)范文檔部門職責(zé)

1.1 質(zhì)量管理部

? 部門職責(zé)：

? 接受公司所有系統(tǒng)的質(zhì)量測試任務(wù)

? 發(fā)現(xiàn)并提出系統(tǒng)存在的缺陷，間接保證上線系統(tǒng)無缺陷或在允許缺陷范圍內(nèi) ? 協(xié)助項目經(jīng)理重現(xiàn)、分析系統(tǒng)缺陷

? 提供系統(tǒng)測試報告并做可上線結(jié)論定性

? 系統(tǒng)上線質(zhì)量跟蹤

? 部門經(jīng)理：

? 部門日常行政事務(wù)管理、人力資源招聘、分配及管理

? 制定或協(xié)助測試工程師制定項目測試計劃

? 制定或協(xié)助測試工程師制定項目測試進(jìn)度

? 檢查項目測試用例

? 測試過程管理、保證系統(tǒng)測試的全面性、完整性

? 保證項目測試結(jié)果的高質(zhì)量性

? 審核測試報告

? 測試人力資源培訓(xùn)及技能提高管理

? 系統(tǒng)上線質(zhì)量跟蹤

? 測試工程師：

?

?

?

? 接受部門經(jīng)理分配的測試任務(wù) 制定項目測試計劃 制定項目測試進(jìn)度 高質(zhì)量完成測試任務(wù)

? 編寫測試報告

? 系統(tǒng)上線質(zhì)量跟蹤工作流程及制度

2.1 進(jìn)度表編寫及更新

? 測試進(jìn)度

在接受《功能需求說明書》及項目《詳細(xì)設(shè)計》、《數(shù)據(jù)字典》等資料后，質(zhì)量

管理部經(jīng)理需主導(dǎo)及督促測試工程師制定項目測試計劃及測試進(jìn)度，審核

通過后納入項目開發(fā)進(jìn)度表一起形成整體進(jìn)度表。

? 進(jìn)度變更申請

申請條件：涉及功能變更、人力資源、外部因素、進(jìn)度制定估計嚴(yán)重不足的情況。申請時間：前置一個工作日以上的當(dāng)前工作日下班內(nèi)申請，進(jìn)度過期再申請按項目非正

當(dāng)延遲納入考核。

審核人：中心經(jīng)理。

項目立項后,需要出具測試進(jìn)度安排表;

進(jìn)度表相關(guān)的注意事項:

(1)進(jìn)度安排表:

先安排第一輪測試所使用的時間,回歸測試要等第一輪測試完成后,根據(jù)BUG數(shù)量,BUG牽涉面等來綜合考慮,給出回歸測試進(jìn)度安排后,要及時更新到project上;

(2)測試報告不算在測試時間內(nèi);

(3)性能測試,安排的進(jìn)度表,也是第一輪測試所需的時間,測試完成后,提交報告給開發(fā),進(jìn)行軟硬件調(diào)整后,再根據(jù)需要配合開發(fā)做后續(xù)調(diào)整工作;

但過程中可以先反饋一些情況給開發(fā),讓他們做調(diào)整準(zhǔn)備;

2.2 項目立項流程管理

流程中與測試經(jīng)理及測試人員相關(guān)的步驟包含如下：

（1）需求評審:

主持人：產(chǎn)品經(jīng)理

參與人：產(chǎn)品部經(jīng)理、產(chǎn)品經(jīng)理、項目經(jīng)理、測試經(jīng)理及測試工程師，及其它須邀請人員 目的：評審直至《功能需求說明書》被項目組接受

注：需求確認(rèn)將穿插與后續(xù)需求分析的全過程，涉及后續(xù)開發(fā)中需求變更內(nèi)容，項目經(jīng)理需會知產(chǎn)品經(jīng)理以保持開發(fā)與功能需求的一致性，產(chǎn)品經(jīng)理須承擔(dān)起功能變更管理職責(zé)

（2）編寫測試計劃:

編寫人：質(zhì)量管理部經(jīng)理、測試工程師

產(chǎn)物：《測試計劃》

標(biāo)準(zhǔn)：項目經(jīng)理、質(zhì)量管理部經(jīng)理、中心經(jīng)理審核通過

（3）編寫測試用例:

編寫人：測試工程師

產(chǎn)物：測試用例，見TD

編寫依據(jù)：《功能需求說明書》為主《詳細(xì)設(shè)計》、《數(shù)據(jù)字典》為輔

標(biāo)準(zhǔn)：項目經(jīng)理、質(zhì)量管理部經(jīng)理、中心經(jīng)理審核通過

（4）測試申請:

申請人：項目經(jīng)理

申請對象：質(zhì)量管理部經(jīng)理

申請前提：

1、編寫《測試申請單》并審核通過；

2、保證被測試系統(tǒng)在開發(fā)角度已無BUG；

3、提交封存好的系統(tǒng)安裝程序；

（5）第一輪測試:

申請人：項目經(jīng)理

申請對象：質(zhì)量管理部經(jīng)理

申請前提：

1、編寫《測試申請單》并審核通過；

2、提交封存好的系統(tǒng)安裝程序；

（6）回歸測試及測試完成:

測試對象：開發(fā)修正BUG及其相關(guān)模塊

完成標(biāo)準(zhǔn)：

1、從測試角度保證系統(tǒng)已無任何BUG或僅存可允許之BUG；

2、測試報告編寫完成（可以測試結(jié)束后一工作日內(nèi)完成）。

產(chǎn)物：《測試報告》

（7）結(jié)案、結(jié)案總結(jié)會議、驗收

結(jié)案標(biāo)準(zhǔn)：

1、測試完成并出具測試報告；

2、項目總結(jié)會議招開并發(fā)布會議紀(jì)要；

3、相關(guān)項目文件清單用戶冊及應(yīng)維手冊完成。

驗收人：中心經(jīng)理及分管副總

驗收依據(jù)：項目開發(fā)、文檔、測試進(jìn)度數(shù)據(jù)及BUG數(shù)據(jù)

產(chǎn)物：評定項目一期資金比率

（8）上線跟蹤:

跟蹤人：開發(fā)部經(jīng)理、項目經(jīng)理、測試工程師

跟蹤內(nèi)容：系統(tǒng)軟硬件運行情況

問題處理：上線系統(tǒng)問題處理須響應(yīng)快、處理及時并反饋相關(guān)部門

跟蹤及處理責(zé)任人：項目經(jīng)理

項目立項流程相關(guān)的注意事項:

（1）測試人員不一定要內(nèi)測，視測試人員時間而定；

（2）所有項目除小型變更外都要寫測試計劃；

（3）上線跟蹤要反饋信息給中心經(jīng)理，由中心經(jīng)理發(fā)布。

2.3 短期項目開發(fā)流程

短期項目指為適合特定業(yè)務(wù)或系統(tǒng)需而立項的開發(fā)項目，其特點為流程從簡、結(jié)案迅速。

流程如下：

測試（開發(fā)或測試部門），可不正式測試

2.4 項目變更流程

流程中與測試經(jīng)理及測試人員相關(guān)的步驟包含如下：

更新測試用例:

執(zhí)行人：測試工程師

產(chǎn)物：新測試用例

測試:

執(zhí)行人：測試工程師

產(chǎn)物：經(jīng)需求變更的功能測試通過

項目變更流程的相關(guān)注意事項：

測試前提:變更單變更的內(nèi)容,在需求及詳細(xì)設(shè)計中有體現(xiàn);

測試時間:提交測試到上線截止時間;

測試依據(jù):需求及詳細(xì)設(shè)計例會及報告

開發(fā)中心按角色及部門制定如下例會及報告制度：

3.1 例會制度

?部門經(jīng)理例會：每周第一個工作日定期招開，參與人員為中心經(jīng)理、部門經(jīng)理

?部門例會：須在例會形成例會紀(jì)要，并發(fā)送至中心經(jīng)理、分管副叫及其它部門經(jīng)理處

?產(chǎn)品部例會：由產(chǎn)品部部門經(jīng)理主持，每周一次，參與人員為中心經(jīng)理、產(chǎn)品部經(jīng)理及產(chǎn)品部所有成員

?開發(fā)部例會：由開發(fā)部部門經(jīng)理主持，每周一次，參與人員為中心經(jīng)理、開發(fā)部經(jīng)理及各項目經(jīng)理

?質(zhì)量管理部例會：由質(zhì)量管理部部門經(jīng)理主持，每周一次，參與人員為中

心經(jīng)理、質(zhì)量管理部經(jīng)理及質(zhì)量管理部所有成員

? 其它需討論及招開的會議

3.2 報告制度

? 日報

編寫對象：中心所有成員

發(fā)送時間：每工作日尾段時間

發(fā)送對象：

?產(chǎn)品部及質(zhì)量管理部部門成員發(fā)送至所屬部門經(jīng)理

?

?

?

?

? 周報

編寫對象：項目經(jīng)理、部門經(jīng)理、中心經(jīng)理

發(fā)送時間：每周第一個工作日內(nèi)

發(fā)送對象：

?

?項目經(jīng)理發(fā)送至部門經(jīng)理及中心經(jīng)理和分管副總 部門經(jīng)理發(fā)送至中心經(jīng)理及分管副總，并抄送至其它部門經(jīng)理處 開發(fā)部成員發(fā)送至所屬項目組項目經(jīng)理 項目經(jīng)理發(fā)送至所屬部門經(jīng)理及中心經(jīng)理和分管副部 部門經(jīng)理發(fā)送至中心經(jīng)及和分管副部，并抄送至其它部門經(jīng)理處 中心經(jīng)理發(fā)送至分管副總 ?中心經(jīng)理發(fā)送至分管副總

? 月報

編寫對象：項目經(jīng)理、部門經(jīng)理、中心經(jīng)理

發(fā)送時間：每月第一個工作日內(nèi)

發(fā)送對象：

?

?項目經(jīng)理發(fā)送至部門經(jīng)理及中心經(jīng)理和分管副總 部門經(jīng)理發(fā)送至中心經(jīng)理及分管副總，并抄送至其它部門經(jīng)理處 ?中心經(jīng)理發(fā)送至分管副總

以上各報告，配有詳細(xì)報告模，需嚴(yán)格按模書寫。