軟件項目質量管理的研究探討

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

關鍵詞：軟件項目；質量管理；需求分析；項目立項

一、引言

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

二、關于軟件項目中一般存在的質量問題

（一）項目前期缺少需求分析

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

（二）項目沒有盡早確定主管部門

業務管理系統里面各項模塊沒有確定主管部門。各部門權責沒有明確，比如哪項工作由A業務部門管理負責，哪些由B業務部門管理負責；具體各部門操作人員分別負責做什么業務；培訓由哪個部門來牽頭；組織實施由哪個部門落實。這就會造成大家都來做或者大家都不做；或者簡單地搶著做，復雜的大家都不做的情況，從而影響到后續的需求分析、系統測試等一系列過程。這樣的軟件項目，后期基本都是會失敗，甚至都不會堅持到系統上線階段。

（三）項目留給測試的時間太少

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

（四）對系統的上線服務缺乏充分準備

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

（五）軟件開發管理監督不到位

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

三、提升軟件項目質量的辦法

（一）確定軟件項目管理計劃

在軟件項目實施前，制定相應的軟件質量保證計劃，計劃主要是針對軟件運行過程，調試相關設備，預防可能出現的缺陷和及時相應的解決辦法。

軟件質量管理主要要考慮以下內容和方面：管理計劃開展的目的；對軟件質量管理有關理論進行學習，并以相關參考文獻作為支撐；軟件整體開發過程中應明確組織領導和組織實施的各部門責任；對軟件需求進行評審，得到各方一致意見并通過；加強程序代碼的開發管理，做到安全可靠穩定；在試運行和正式上線前，一定要組織相關人員進行培訓；在系統正式上線前就安排好相應服務支撐；所有工作到位，項目按期驗收完工進入日常運維階段。

（二）注重在項目立項階段的管理

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

（三）加強對業務部門的約束

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

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

（四）開展高質量的軟件需求評審

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

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

需求評審最終可以是以下兩種情況：

①需求評審通過，后續開發按評審意見進行。參會各方包括信息中心、軟件承建單位、業務部門均在評審報告上簽署同意意見。

②需求評審不通過，后續需要對需求進行修改，進一步完善需求規格說明書和原型系統，待修改完成后，重新組織評審。

開展高質量的軟件需求評審有利于項目的順利實施。如果沒有評審，軟件開發過程中出現錯誤，業務部門表示開發的系統不是他們想要的，也沒有辦法使用，承建單位表示業務部門沒有表達清楚，產生互相扯皮的現象。這將給承建單位造成嚴重損失，甚至關系到軟件項目開發的成敗。因此，參與項目的各方都有必要加強軟件項目需求評審工作，為軟件的順利實施提供強有力的保障。

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

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

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

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

四、建立軟件質量服務體系

（一）建立項目組服務制度

一般來說，軟件項目小組對軟件項目服務負有主體責任，項目組成員為各項目的技術支持聯系責任人。聯系責任人應當常年通過電話、OA系統郵件和系統專用QQ 群三個渠道接受用戶的咨詢報修，并及時作出服務響應。

（二）建立多層次技術服務機制

①電話服務方式。接到用戶的技術支持請求或故障報告后，立即以電話方式與用戶聯系，指導解決問題。

②遠程服務方式。技術支持人員在用戶授權后通過遠程連接進入用戶計算機界面幫助解決問題。

③現場服務方式。安排技術人員第一時間趕赴故障終端現場，現場了解情況并解決問題。

④應急服務方式。設立系統技術支持應急服務小組，小組組長由各項目組組長擔任。應急服務小組在突發事件發生后迅速召集相關人員查明原因，第一時間制定應急方案，評估解決時間并落實后續措施。

（三）明確24小時服務響應機制

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

（四）建立服務保障配套制度

①定期監測制度。項目組安排專人每天監測并記錄系統運行狀況，預防故障發生，對發生的各種問題及時作出響應。

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

③系統安全管理制度。項目組應當建議用戶不使用默認密碼，進入系統后請求自行修改;已修改密碼的用戶也建議定期更換，防止信息泄漏；應當定期檢查系統人員權限后臺是否配置正確。

（五）建立責任追究制度

對不按本制度規定的時限和要求履行服務職責，造成系統事故或有責投訴的，單位實行系統支持聯系人工作責任追究制度。對于發生問題記錄個別缺失、一般性事故處理不及時或輕微有責投訴的情況，單項問題給予責任人批評教育；對于發生問題記錄缺失較多、重大事故處理不及時或有責投訴的情況，單項問題給予責任人批評教育和扣除部分考核獎勵的處罰；對于發生重大事故處理不及時且造成嚴重后果的情況，單項問題可給予責任人嚴肅處罰。同時單位可通過協議方式與軟件承建單位達成系統服務支持考核機制，對軟件承建單位原因造成的責任故障或用戶投訴，依協議追究該承建單位的經濟責任。

（六）建立系統更新提前公告制度

系統每次更新前，項目組應提供本次系統版本號和更新內容，報經業務主管部門審查通過后在網頁發布通知公告。公告應在更新前24小時發出。為不影響系統用戶日常工作，系統更新應當安排在非工作日或工作日的夜間進行，如有特殊情況需在工作時間更新的，應當提前24小時匯報領導并告知該項目業務主管部門。

五、結束語

在軟件開發的全過程中，質量管理相當重要，本文主要分析軟件開發項目實施過程中容易存在的各類質量缺陷，提出改善項目管理質量的解決辦法，融入各項監督和管理機制，有助于項目人員達成共識，共同參與提升軟件項目質量。

作者單位：沈鑫 常州市住房和城鄉建設發展促進中心

參" 考" 文" 獻

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

[2]楊驍.加強軟件質量管理的必要性與方法研究[J].現代工業經濟和信息化，2018，8（07）：70-71，75.

[3]林洪梅.軟件質量管理的目標和增強策略的分析[J].計算機產品與流通，2018（06）：26.

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

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

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

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

[8]劉海英.全面質量管理理念在軟件生產過程中的應用[J].世界標準化與質量管理，2002（07）：16-17，25.

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