摘要：重視軟件項(xiàng)目的質(zhì)量管理，規(guī)范軟件項(xiàng)目質(zhì)量管理體系，對(duì)整個(gè)軟件項(xiàng)目的實(shí)施具有非常重要的推進(jìn)作用。文章研究表明，通過多個(gè)項(xiàng)目管理的經(jīng)驗(yàn)，從多角度開展研究，深入了解軟件項(xiàng)目質(zhì)量管理容易忽視的要素，提出問題和解決辦法，為信息化質(zhì)量管理具體工作提供參考。

關(guān)鍵詞：軟件項(xiàng)目；質(zhì)量管理；需求分析；項(xiàng)目立項(xiàng)

一、引言

隨著信息化技術(shù)的高速發(fā)展，在生活中，人們對(duì)軟件產(chǎn)生了越來越多的依賴。這對(duì)軟件項(xiàng)目的質(zhì)量提出了更高的要求。很多軟件項(xiàng)目在開發(fā)建設(shè)過程中，已經(jīng)采取了一定的管理措施，但還是存在一些缺陷，沒有從根本上解決問題。為了更好地提升軟件項(xiàng)目的質(zhì)量，通過分析列舉軟件項(xiàng)目實(shí)施中容易出現(xiàn)的各類影響質(zhì)量的問題，提出行之有效的解決方案，針對(duì)問題及時(shí)有效地開展管理，以提高整個(gè)軟件項(xiàng)目的管理水平和實(shí)施質(zhì)量。

二、關(guān)于軟件項(xiàng)目中一般存在的質(zhì)量問題

（一）項(xiàng)目前期缺少需求分析

在項(xiàng)目前期應(yīng)進(jìn)行全面的可行性需求分析。這個(gè)要開發(fā)的軟件項(xiàng)目，是小型管理系統(tǒng)還是大型網(wǎng)站系統(tǒng)。一般小型業(yè)務(wù)系統(tǒng)使用人數(shù)相對(duì)較少，最多幾百人，而大型商業(yè)網(wǎng)站一般每天都有幾千甚至幾十萬人訪問。系統(tǒng)定位不準(zhǔn)確，后續(xù)配套的硬件網(wǎng)絡(luò)都將不能適應(yīng)。從類別來講，業(yè)務(wù)系統(tǒng)更注重功能的實(shí)現(xiàn)，而商業(yè)網(wǎng)站更注重瀏覽和體驗(yàn)。前期的可行性需求規(guī)格說明書應(yīng)更加詳細(xì)，在版面大方美觀上和對(duì)瀏覽器、分辨率的支持尤其要描述準(zhǔn)確。很多出現(xiàn)質(zhì)量問題的前期可行性研究需求規(guī)格說明書，從嚴(yán)格意義上說，有需求但缺少規(guī)格。比如只說明首頁包含哪些模塊，而沒有說明各個(gè)模塊的位置、版塊大小、文字大小顏色是否滾動(dòng)、是否自動(dòng)刷新。只說明需要制作專題，而沒有表示需要制作哪些類型的專題，系統(tǒng)能幫我們實(shí)現(xiàn)哪些功能。新老數(shù)據(jù)遷移只考慮到新聞和部分業(yè)務(wù)的遷移，遺漏了信息、專題、歷史數(shù)據(jù)等欄目導(dǎo)致內(nèi)容空洞。根據(jù)這樣的需求規(guī)格說明書開發(fā)出來的系統(tǒng)，勢必不能滿足我們的需要，將會(huì)面臨大量的需求調(diào)整。到后期需求變更的現(xiàn)象會(huì)比較多，這就說明當(dāng)時(shí)考慮的不充分，需要增加內(nèi)容。這樣的話，一來軟件承建單位的成本增加，會(huì)增加抵觸情緒；二來系統(tǒng)需求調(diào)研，系統(tǒng)開發(fā)的時(shí)間將依賴于軟件承建單位的加班加點(diǎn)，不能保證按期完成，影響開發(fā)質(zhì)量。

（二）項(xiàng)目沒有盡早確定主管部門

業(yè)務(wù)管理系統(tǒng)里面各項(xiàng)模塊沒有確定主管部門。各部門權(quán)責(zé)沒有明確，比如哪項(xiàng)工作由A業(yè)務(wù)部門管理負(fù)責(zé)，哪些由B業(yè)務(wù)部門管理負(fù)責(zé)；具體各部門操作人員分別負(fù)責(zé)做什么業(yè)務(wù)；培訓(xùn)由哪個(gè)部門來牽頭；組織實(shí)施由哪個(gè)部門落實(shí)。這就會(huì)造成大家都來做或者大家都不做；或者簡單地?fù)屩觯瑥?fù)雜的大家都不做的情況，從而影響到后續(xù)的需求分析、系統(tǒng)測試等一系列過程。這樣的軟件項(xiàng)目，后期基本都是會(huì)失敗，甚至都不會(huì)堅(jiān)持到系統(tǒng)上線階段。

（三）項(xiàng)目留給測試的時(shí)間太少

一般軟件系統(tǒng)都有至少2到3個(gè)月的試運(yùn)行測試完善時(shí)間。但部分項(xiàng)目由于考慮到上線時(shí)間緊迫，在倒排計(jì)劃時(shí)，安排的時(shí)間非常緊張，程序開發(fā)、培訓(xùn)、測試和錄入歷史數(shù)據(jù)一共只有2個(gè)月時(shí)間，其中用來測試的時(shí)間只有1個(gè)月。測試的時(shí)間不充裕直接導(dǎo)致系統(tǒng)的一些問題在正式上線前沒有得到充分暴露，在上線后才逐一體現(xiàn)，上線后再通過加班加點(diǎn)來處理這些問題其效率要遠(yuǎn)遠(yuǎn)低于上線前發(fā)現(xiàn)并解決問題，造成用戶投訴的現(xiàn)象也時(shí)有發(fā)生。

（四）對(duì)系統(tǒng)的上線服務(wù)缺乏充分準(zhǔn)備

在系統(tǒng)開發(fā)完成測試時(shí)，沒有制定相應(yīng)的軟件測試計(jì)劃。一般都是軟件承建單位和業(yè)務(wù)操作人員進(jìn)行簡單測試，使用少量模擬數(shù)據(jù)測試，測試不全面。有些項(xiàng)目甚至僅有開發(fā)人員自行開展程序糾錯(cuò)的測試，過程混亂無序、相當(dāng)隨意，測試的含義比較狹窄。對(duì)于上線后軟件正常運(yùn)維，提供相關(guān)支撐服務(wù)需要投入的人力、資源過于樂觀，導(dǎo)致系統(tǒng)上線后故障頻發(fā)，修正緩慢，甚至系統(tǒng)崩潰，造成不良影響。

（五）軟件開發(fā)管理監(jiān)督不到位

參與軟件項(xiàng)目開發(fā)的技術(shù)人員一般并不了解實(shí)際業(yè)務(wù)，在項(xiàng)目開始時(shí)沒有提前進(jìn)行業(yè)務(wù)調(diào)研或者調(diào)研不深入，淺嘗輒止，不了解客戶需求，在此條件下開發(fā)出來軟件項(xiàng)目必然會(huì)導(dǎo)致項(xiàng)目和用戶需求不匹配，最終導(dǎo)致開發(fā)出來的軟件不能正常使用。另外有些軟件開發(fā)單位缺少相應(yīng)業(yè)務(wù)知識(shí)和技術(shù)儲(chǔ)備方面的經(jīng)驗(yàn)，在軟件開發(fā)過程中也盡可能降低開發(fā)成本，導(dǎo)致程序代碼執(zhí)行效率低下，開發(fā)出來的軟件性能差，達(dá)不到用戶的要求，極大地降低了軟件開發(fā)質(zhì)量。

三、提升軟件項(xiàng)目質(zhì)量的辦法

（一）確定軟件項(xiàng)目管理計(jì)劃

在軟件項(xiàng)目實(shí)施前，制定相應(yīng)的軟件質(zhì)量保證計(jì)劃，計(jì)劃主要是針對(duì)軟件運(yùn)行過程，調(diào)試相關(guān)設(shè)備，預(yù)防可能出現(xiàn)的缺陷和及時(shí)相應(yīng)的解決辦法。

軟件質(zhì)量管理主要要考慮以下內(nèi)容和方面：管理計(jì)劃開展的目的；對(duì)軟件質(zhì)量管理有關(guān)理論進(jìn)行學(xué)習(xí)，并以相關(guān)參考文獻(xiàn)作為支撐；軟件整體開發(fā)過程中應(yīng)明確組織領(lǐng)導(dǎo)和組織實(shí)施的各部門責(zé)任；對(duì)軟件需求進(jìn)行評(píng)審，得到各方一致意見并通過；加強(qiáng)程序代碼的開發(fā)管理，做到安全可靠穩(wěn)定；在試運(yùn)行和正式上線前，一定要組織相關(guān)人員進(jìn)行培訓(xùn)；在系統(tǒng)正式上線前就安排好相應(yīng)服務(wù)支撐；所有工作到位，項(xiàng)目按期驗(yàn)收完工進(jìn)入日常運(yùn)維階段。

（二）注重在項(xiàng)目立項(xiàng)階段的管理

每個(gè)項(xiàng)目都是從項(xiàng)目立項(xiàng)階段開始，這是信息化建設(shè)的第一步，根據(jù)以往的工作經(jīng)驗(yàn)，這個(gè)時(shí)間可能是1-2個(gè)月。在這段時(shí)間里，其實(shí)有大量工作，包括前期可行性分析調(diào)研，需要整理前期需求文檔，需要明確到系統(tǒng)邊界，各部門各轄市區(qū)，系統(tǒng)中的各個(gè)子系統(tǒng)要讓業(yè)務(wù)部門充分理解，每個(gè)子系統(tǒng)的作用，以后日常工作能不能依托這套系統(tǒng)來進(jìn)行更有效的管理。規(guī)劃整理硬件以及網(wǎng)絡(luò)架構(gòu)，弄清設(shè)備現(xiàn)有情況，落實(shí)資金來源，準(zhǔn)備招標(biāo)文件等等工作。對(duì)于業(yè)務(wù)部門來說，可能一開始會(huì)沒有頭緒。為了更好地推進(jìn)工作，可以這樣來處理，把需要做的事情詳細(xì)列在報(bào)告里面，作為一種啟發(fā)。哪些能做哪些還不能做；歷史數(shù)據(jù)容量有多少，怎么處理合適；現(xiàn)在有沒有舊系統(tǒng)，舊系統(tǒng)運(yùn)行到什么時(shí)候；新舊系統(tǒng)切換數(shù)據(jù)怎么處理；歷史數(shù)據(jù)需不需要導(dǎo)進(jìn)去；系統(tǒng)使用的單位是全市，包不包括轄市區(qū)；所有區(qū)域是否可以使用一套系統(tǒng)完成業(yè)務(wù)辦理；理想中的系統(tǒng)如果上線目前的規(guī)章制度還需不需要進(jìn)一步完善；還需要增加哪些文件作為支持；有沒有企業(yè)用戶會(huì)抵制；是否需要同步做系統(tǒng)的對(duì)外數(shù)據(jù)展示；需要配備多少相關(guān)計(jì)算機(jī)軟硬件；對(duì)系統(tǒng)安全有什么要求；需不需要去外地做得好的地方調(diào)研等等問題。大家把能想到的全部列出來，這樣由項(xiàng)目團(tuán)隊(duì)組織業(yè)務(wù)部門和軟件承建單位一起研究，逐條分析解決，遇到困難可向領(lǐng)導(dǎo)或上級(jí)部門請(qǐng)示。經(jīng)過這樣周密的研究，形成的需求自然也就不會(huì)再空洞了。所以進(jìn)一步加強(qiáng)在項(xiàng)目立項(xiàng)階段對(duì)業(yè)務(wù)部門的管理顯得尤為重要，如時(shí)間緊完不成任務(wù)，可向上級(jí)請(qǐng)示考慮適當(dāng)延長項(xiàng)目立項(xiàng)的時(shí)間來保證項(xiàng)目的質(zhì)量。

（三）加強(qiáng)對(duì)業(yè)務(wù)部門的約束

在整個(gè)項(xiàng)目建設(shè)過程中，往往會(huì)出現(xiàn)系統(tǒng)組織者信息中心和軟件承建單位做了項(xiàng)目的極大部分工作，而軟件的真正操作使用者業(yè)務(wù)部門卻參與甚少。業(yè)務(wù)部門沒有很好地投入到項(xiàng)目建設(shè)中來，為改變這種情況，建議項(xiàng)目組織者至少在項(xiàng)目立項(xiàng)階段、需求調(diào)研階段、系統(tǒng)試運(yùn)行階段，要加強(qiáng)對(duì)業(yè)務(wù)部門的約束。因?yàn)檫@三個(gè)階段的責(zé)任部門都應(yīng)是業(yè)務(wù)部門。負(fù)責(zé)部門到底是A部門還是B部門，或者兩個(gè)一起，由A部門牽頭管理好開發(fā)，B部門負(fù)責(zé)落實(shí)培訓(xùn)場地并組織企業(yè)人員參加培訓(xùn)。這樣看起來就清晰多了，不會(huì)出現(xiàn)差錯(cuò)。只有業(yè)務(wù)部門充分參與并重視，系統(tǒng)的質(zhì)量才能保障。

在項(xiàng)目立項(xiàng)階段，前期調(diào)研應(yīng)建立起每周例會(huì)制度，由業(yè)務(wù)部門提交，本周他們完成了哪些工作并簽字確認(rèn)。例會(huì)上，大家再商量確定到目前為止的進(jìn)度以及下周的計(jì)劃和安排。在需求調(diào)研階段，建立不定期需求會(huì)議，業(yè)務(wù)部門應(yīng)時(shí)刻記錄自己提出的業(yè)務(wù)需求。待需求評(píng)審時(shí)可逐一檢查并確定。在項(xiàng)目試運(yùn)行階段，可要求業(yè)務(wù)部門提供自己的測試周報(bào)，在這一段時(shí)間，測試了多少內(nèi)容，發(fā)現(xiàn)了多少要修改的問題并簽字確認(rèn)。在交流會(huì)時(shí)，可對(duì)問題進(jìn)行逐一確認(rèn)，并由軟件承建單位明確修改完成時(shí)間，并加強(qiáng)管理，盡量在早期把問題先行解決。

（四）開展高質(zhì)量的軟件需求評(píng)審

在軟件開發(fā)項(xiàng)目中，需求是非常重要的內(nèi)容，也是軟件開發(fā)的基礎(chǔ)。需求不明確，工作就沒有方向。需求的獲取是最需要開展交流的，也是最為困難的，在獲取需求的過程中會(huì)比較容易出錯(cuò)。一般來說，用戶需求中變更較少的軟件開發(fā)項(xiàng)目的成功率會(huì)更高。根據(jù)以往的項(xiàng)目實(shí)施經(jīng)驗(yàn)，在軟件開發(fā)過程中，受到很多不確定因素的影響，用戶需求也會(huì)隨之發(fā)生改變，嚴(yán)重影響軟件項(xiàng)目的實(shí)施，甚至造成項(xiàng)目不斷返工，軟件質(zhì)量低下，軟件進(jìn)度延遲，遲遲不能上線等問題。基于以上分析，項(xiàng)目需求的分析一定需要從嚴(yán)把關(guān)，做好需求評(píng)審。

從項(xiàng)目立項(xiàng)開始就要安排相關(guān)人員深入業(yè)務(wù)部門開展需求調(diào)研。軟件開發(fā)人員認(rèn)真聽取業(yè)務(wù)部門用戶的意見并進(jìn)行記錄，反復(fù)進(jìn)行溝通，盡可能從專業(yè)的角度發(fā)掘用戶的潛在需求 ，以達(dá)到最大限度地滿足用戶的目標(biāo)。信息中心要做好雙方溝通的橋梁作用。需求基本成型后，由軟件承建單位編寫完成需求規(guī)格說明書和原型系統(tǒng)演示。這時(shí)候就可以組織召開需求評(píng)審會(huì)議。大家針對(duì)需求內(nèi)容逐條發(fā)表意見。需求的評(píng)審過程本身也是一個(gè)知識(shí)傳遞過程，參與的各方業(yè)務(wù)人員與需求分析人員、技術(shù)人員一起討論用戶需求，這有助于評(píng)審人員獲得用戶需求的正確認(rèn)識(shí)，確保對(duì)需求理解達(dá)成一致。在評(píng)審過程中，通過溝通細(xì)節(jié)，可能會(huì)發(fā)現(xiàn)有些需求不明確需要進(jìn)一步完善，可能會(huì)增加一些遺漏的需求；另外因參與各方所站的角度不同，對(duì)同一業(yè)務(wù)流程、表單的設(shè)計(jì)可能會(huì)提出更有建設(shè)性、更合理的解決方案。

需求評(píng)審最終可以是以下兩種情況：

①需求評(píng)審?fù)ㄟ^，后續(xù)開發(fā)按評(píng)審意見進(jìn)行。參會(huì)各方包括信息中心、軟件承建單位、業(yè)務(wù)部門均在評(píng)審報(bào)告上簽署同意意見。

②需求評(píng)審不通過，后續(xù)需要對(duì)需求進(jìn)行修改，進(jìn)一步完善需求規(guī)格說明書和原型系統(tǒng)，待修改完成后，重新組織評(píng)審。

開展高質(zhì)量的軟件需求評(píng)審有利于項(xiàng)目的順利實(shí)施。如果沒有評(píng)審，軟件開發(fā)過程中出現(xiàn)錯(cuò)誤，業(yè)務(wù)部門表示開發(fā)的系統(tǒng)不是他們想要的，也沒有辦法使用，承建單位表示業(yè)務(wù)部門沒有表達(dá)清楚，產(chǎn)生互相扯皮的現(xiàn)象。這將給承建單位造成嚴(yán)重?fù)p失，甚至關(guān)系到軟件項(xiàng)目開發(fā)的成敗。因此，參與項(xiàng)目的各方都有必要加強(qiáng)軟件項(xiàng)目需求評(píng)審工作，為軟件的順利實(shí)施提供強(qiáng)有力的保障。

（五）立足軟件需求，開展測試

經(jīng)過初步的軟件開發(fā)完成之后，就可以組織開展測試。信息中心、軟件承建單位、業(yè)務(wù)部門和企業(yè)用戶代表都應(yīng)積極參與，主要是確保軟件具有可操作性以及適應(yīng)性，及時(shí)發(fā)現(xiàn)各種軟件系統(tǒng)缺陷并提交技術(shù)人員修改。

一般來說，軟件缺陷有以下幾種表現(xiàn)形式：1.軟件沒有達(dá)到項(xiàng)目需求規(guī)格說明書標(biāo)明的功能；2.軟件中某些模塊和需求不一致；3.軟件功能超出需求中所確定的范圍；4.軟件沒有達(dá)到用戶期望的目標(biāo)，包括需求規(guī)格說明書中沒有說明的；5.所有測試人員認(rèn)為軟件的易用性差。滿足一項(xiàng)以上就可定義為軟件存在缺陷。

通常情況下，軟件測試可通過以下方式進(jìn)行：依據(jù)軟件需求規(guī)格說明書，進(jìn)行功能測試，測試軟件的功能是否符合功能性需求。根據(jù)軟件的用戶數(shù)量，測試單用戶、常規(guī)用戶數(shù)量正常使用和完全用戶最大負(fù)載下應(yīng)用下的性能。測試軟件是否易操作，主觀性比較強(qiáng)。根據(jù)業(yè)務(wù)部門、信息中心、前臺(tái)操作人員，后臺(tái)審批人員，系統(tǒng)管理人員等各類用戶的測試反饋信息，進(jìn)行易用性測試。針對(duì)之前反映的問題，技術(shù)人員表示改好了，請(qǐng)問題提出者重新進(jìn)行測試，測試提出的問題是否已經(jīng)得到解決，另外還需測試因修改過程序或數(shù)據(jù)是否會(huì)造成其他問題。軟件項(xiàng)目通過嚴(yán)格測試再修改完善后，即可安排正式上線。

四、建立軟件質(zhì)量服務(wù)體系

（一）建立項(xiàng)目組服務(wù)制度

一般來說，軟件項(xiàng)目小組對(duì)軟件項(xiàng)目服務(wù)負(fù)有主體責(zé)任，項(xiàng)目組成員為各項(xiàng)目的技術(shù)支持聯(lián)系責(zé)任人。聯(lián)系責(zé)任人應(yīng)當(dāng)常年通過電話、OA系統(tǒng)郵件和系統(tǒng)專用QQ 群三個(gè)渠道接受用戶的咨詢報(bào)修，并及時(shí)作出服務(wù)響應(yīng)。

（二）建立多層次技術(shù)服務(wù)機(jī)制

①電話服務(wù)方式。接到用戶的技術(shù)支持請(qǐng)求或故障報(bào)告后，立即以電話方式與用戶聯(lián)系，指導(dǎo)解決問題。

②遠(yuǎn)程服務(wù)方式。技術(shù)支持人員在用戶授權(quán)后通過遠(yuǎn)程連接進(jìn)入用戶計(jì)算機(jī)界面幫助解決問題。

③現(xiàn)場服務(wù)方式。安排技術(shù)人員第一時(shí)間趕赴故障終端現(xiàn)場，現(xiàn)場了解情況并解決問題。

④應(yīng)急服務(wù)方式。設(shè)立系統(tǒng)技術(shù)支持應(yīng)急服務(wù)小組，小組組長由各項(xiàng)目組組長擔(dān)任。應(yīng)急服務(wù)小組在突發(fā)事件發(fā)生后迅速召集相關(guān)人員查明原因，第一時(shí)間制定應(yīng)急方案，評(píng)估解決時(shí)間并落實(shí)后續(xù)措施。

（三）明確24小時(shí)服務(wù)響應(yīng)機(jī)制

明確對(duì)用戶提供的支持服務(wù)時(shí)間：周一至周五（國家法定休假日和雙休日除外）的9：00-17：00；在節(jié)假日、休息日和下班期間，用戶可通過手機(jī)與技術(shù)支持人員取得聯(lián)系。一般應(yīng)用性故障（不需調(diào)整程序源代碼）應(yīng)在4小時(shí)內(nèi)排除故障，軟件設(shè)計(jì)及軟件系統(tǒng)缺陷等故障（需調(diào)整程序源代碼）應(yīng)在24小時(shí)內(nèi)排除故障。經(jīng)技術(shù)分析不能立即排除故障的，應(yīng)用性故障在12小時(shí)內(nèi)應(yīng)提出有效解決方案或有效替代方法；對(duì)于軟件設(shè)計(jì)及軟件系統(tǒng)缺陷等方面的故障，應(yīng)在24小時(shí)內(nèi)告知用戶并提供具體的解決方案和計(jì)劃完成時(shí)間。需求變更、新增或針對(duì)現(xiàn)有系統(tǒng)規(guī)模比較大的調(diào)整處理方案由系統(tǒng)開發(fā)項(xiàng)目組評(píng)估后提出意見，報(bào)經(jīng)領(lǐng)導(dǎo)決定，應(yīng)在24小時(shí)內(nèi)告知用戶并提供具體的解決方案和計(jì)劃完成時(shí)間。

（四）建立服務(wù)保障配套制度

①定期監(jiān)測制度。項(xiàng)目組安排專人每天監(jiān)測并記錄系統(tǒng)運(yùn)行狀況，預(yù)防故障發(fā)生，對(duì)發(fā)生的各種問題及時(shí)作出響應(yīng)。

②客戶溝通制度。各項(xiàng)目組采取每季度定期拜訪用戶或召開用戶座談會(huì)等，收集用戶反饋意見并進(jìn)行分析，盡可能滿足用戶要求，對(duì)系統(tǒng)功能進(jìn)行改善，使系統(tǒng)更加方便使用。

③系統(tǒng)安全管理制度。項(xiàng)目組應(yīng)當(dāng)建議用戶不使用默認(rèn)密碼，進(jìn)入系統(tǒng)后請(qǐng)求自行修改;已修改密碼的用戶也建議定期更換，防止信息泄漏；應(yīng)當(dāng)定期檢查系統(tǒng)人員權(quán)限后臺(tái)是否配置正確。

（五）建立責(zé)任追究制度

對(duì)不按本制度規(guī)定的時(shí)限和要求履行服務(wù)職責(zé)，造成系統(tǒng)事故或有責(zé)投訴的，單位實(shí)行系統(tǒng)支持聯(lián)系人工作責(zé)任追究制度。對(duì)于發(fā)生問題記錄個(gè)別缺失、一般性事故處理不及時(shí)或輕微有責(zé)投訴的情況，單項(xiàng)問題給予責(zé)任人批評(píng)教育；對(duì)于發(fā)生問題記錄缺失較多、重大事故處理不及時(shí)或有責(zé)投訴的情況，單項(xiàng)問題給予責(zé)任人批評(píng)教育和扣除部分考核獎(jiǎng)勵(lì)的處罰；對(duì)于發(fā)生重大事故處理不及時(shí)且造成嚴(yán)重后果的情況，單項(xiàng)問題可給予責(zé)任人嚴(yán)肅處罰。同時(shí)單位可通過協(xié)議方式與軟件承建單位達(dá)成系統(tǒng)服務(wù)支持考核機(jī)制，對(duì)軟件承建單位原因造成的責(zé)任故障或用戶投訴，依協(xié)議追究該承建單位的經(jīng)濟(jì)責(zé)任。

（六）建立系統(tǒng)更新提前公告制度

系統(tǒng)每次更新前，項(xiàng)目組應(yīng)提供本次系統(tǒng)版本號(hào)和更新內(nèi)容，報(bào)經(jīng)業(yè)務(wù)主管部門審查通過后在網(wǎng)頁發(fā)布通知公告。公告應(yīng)在更新前24小時(shí)發(fā)出。為不影響系統(tǒng)用戶日常工作，系統(tǒng)更新應(yīng)當(dāng)安排在非工作日或工作日的夜間進(jìn)行，如有特殊情況需在工作時(shí)間更新的，應(yīng)當(dāng)提前24小時(shí)匯報(bào)領(lǐng)導(dǎo)并告知該項(xiàng)目業(yè)務(wù)主管部門。

五、結(jié)束語

在軟件開發(fā)的全過程中，質(zhì)量管理相當(dāng)重要，本文主要分析軟件開發(fā)項(xiàng)目實(shí)施過程中容易存在的各類質(zhì)量缺陷，提出改善項(xiàng)目管理質(zhì)量的解決辦法，融入各項(xiàng)監(jiān)督和管理機(jī)制，有助于項(xiàng)目人員達(dá)成共識(shí)，共同參與提升軟件項(xiàng)目質(zhì)量。

作者單位：沈鑫 常州市住房和城鄉(xiāng)建設(shè)發(fā)展促進(jìn)中心

參" 考" 文" 獻(xiàn)

[1]陳幼芬，周欽青，于汶正.基于云計(jì)算的軟件質(zhì)量管理優(yōu)化算法研究[J].河南科技，2022，41（08）：6-9.

[2]楊驍.加強(qiáng)軟件質(zhì)量管理的必要性與方法研究[J].現(xiàn)代工業(yè)經(jīng)濟(jì)和信息化，2018，8（07）：70-71，75.

[3]林洪梅.軟件質(zhì)量管理的目標(biāo)和增強(qiáng)策略的分析[J].計(jì)算機(jī)產(chǎn)品與流通，2018（06）：26.

[4]胡敏.軟件工程與軟件質(zhì)量管理探討[J].中國高新技術(shù)企業(yè)，2017（10）：103-104.

[5]董正芳，賀軍鋒.軟件質(zhì)量管理的優(yōu)化途徑[J].信息與電腦（理論版），2017（06）：78-80.

[6]高洋.軟件質(zhì)量管理的優(yōu)化對(duì)策分析[J].江蘇科技信息，2016（30）：21-22.

[7]李婷，朱接文.計(jì)算機(jī)信息化的影響及其軟件質(zhì)量管理分析[J].無線互聯(lián)科技，2016（12）：110-111.

[8]劉海英.全面質(zhì)量管理理念在軟件生產(chǎn)過程中的應(yīng)用[J].世界標(biāo)準(zhǔn)化與質(zhì)量管理，2002（07）：16-17，25.

沈鑫（1981-），男，漢族，江蘇常州，研究生，高級(jí)工程師，研究方向：軟件項(xiàng)目信息化管理。