伴隨著軟件產業的快速發展，我國政府電子政務程度不斷加深。各地信息化系統建設速度不斷加快，越來越多的電子政務系統運行于互聯網之上。根據 2003 年 1 月 1日開始實施的《中華人民共和國政府采購法》等有關規定，已建設完成的電子政務系統大部分采用招標采購的建設方式。但筆者在參與多個省級電子政務系統的運維工作多年后發現，由于電子政務系統的行業特殊性，招標采購完成建設的系統在其生命周期的運行和維護階段會存在一些問題，現總結如下。

1 中標軟件公司不能做到定制開發，多為修改復制，系統運行存在隱患

與硬件相比，軟件產品無法設立統一的標準，各建設單位的需求干差萬別，同一款軟件在甲單位適用，在乙單位未必適用。為實現低價中標，軟件公司經常將開發的某款軟件在甲單位應用后，稍作修改，即投放到乙單位實施部署，在項目投標書上也會說明滿足招標書所列功能需求。

但實際結果是電子政務系統的事項辦理流程、審批事項的配置習慣等都不能很好的滿足乙單位的使用。

比如正在運行的某行政審批軟件，基本上是從已經實施完成的省份移植過來，雖有審批功能，但各地的審批流程、業務習慣都不盡相同。并且在軟件的部署試運行階段，當發現某項功能與本項目無關或不符合項目功能需求時，軟件公司通常采取將與該功能相關的操作頁面標簽刪除，其功能模塊的內部程序并未刪除，依然保留在系統代碼中。

經過長時間的累積，程序龐大而復雜，堆積的大量無用代碼在系統運行時會消耗資源，逐漸導致系統速度緩慢。在試運行階段，系統模塊中的殘留代碼均不能暴露，只有當程序運行出現問題后，進行問題定位時，才能從源程序中發現大量的無用代碼，這給后期的系統運行帶來隱患。

2對質保時間的定義各方解釋不一，質保服務形同虛設

在軟件工程中有一句話叫作:找到的軟件缺陷越多，說明未發現的軟件缺陷也越多。測試用例寫得再好，也不能保證測試修改完成的軟件產品沒有缺陷。

很多軟件產品的內部缺陷短期內無法體現，只有通過一段時間的運行使用后，比如數據量有了一定的積累，或者用戶數有了一定增長帶來的高并發量，才會出現問題，這時對問題的分析才能逐步發現諸如程序架構和代碼編寫等方面存在的問題。待到問題發現時，經常質保期已過大半。并且質保期內程序修改的時間不好控制，更有甚者干脆敷衍了事，無限期拖延，以致承諾的服務不能兌現。

另外，軟件公司在投標書中對質保期的定義一般為驗收或正式上線之日起3一5年。隨著項目的完成，軟件公司為了盡快回款，業主方也為了能更好的進行后續合作，通常會比較及時的組織項目驗收;或者在進行了較為充分的測試后選定日期系統正式上線運行，但驗收或者正式上線后應留出充分時間進行設置調整和相關的系統測試。以解決上面所述的問題，按照軟件公司定義的質保開始時間，此時間算在質保時間中筆者覺得有待商榷。

3以業務核心代碼保密為由，3應用程序后期不能改動

由于電子政務行業特殊性，行政審批系統中的業務需求經常會發生變動，相應的，對需求相關的程序功能也需要作出一些小幅改動和調整。根據程序設計的分層思想，審批業務系統通?？蓜澐譃橐晥D層、模型層與控制層，除了視圖層一般為頁面文件\\(如日丁ML文件\\)可直接對其進行某些修改外，模型層和控制層在項目發布上線時一般會將源代碼封裝、打包、編譯成包文件，然后部署到服務器上運行，其內部數據結構和控制邏輯均已無法窺見，某些需求的變動要求對業務邏輯進行修改必須要有編譯前的源文件。

對于較小的程序改動或代碼審查，業主單位希望能夠通過自身技術力量來完成，這就需要獲取項目源代碼。但大多數軟件公司通常以核心代碼乃公司商業機密為由拒絕提供，用戶自己修改代碼變為不可能實現的任務，若提交公司修改則常會出現響應慢或不作為等情況，使系統改動非常困難，無法滿足業務需求的變化。

比如當前國家一直致力于行政審批改革，審批項目不斷簡減、下放，不可避免的會對一些業務需求產生影響，必須合理設計流程配置模塊才能滿足需求，作為審批系統的核心模塊，為了能夠滿足這種不斷變化的流程配置和數據項，模塊得設計會變得比較復雜，在運行過程中會出現一些異常缺陷，因而經常修改程序是不可避免的。但目前的狀況，又使得程序修改工作的進展變得異常緩慢甚至停滯不前。

4出現問題時以自身系統沒有問題為由，拖延推誘系統檢查

我們知道，隨著計算機技術的不斷發展，現在軟件系統的規模越來越大，動輒需要上百人月的工作量才能完成。其功能多種多樣，業務邏輯復雜，用戶權限分類細，不一而足，這些功能和業務邏輯都需要工程師編寫代碼實現。

對于規模較大的軟件企業，其內部一般有針對各行業的開發平臺。在此平臺上開發，許多功能可以通過拖拽組件，并在此基礎上堆砌業務邏輯來完成，此舉可以大大節省人工，提高開發效率。但是同時也會引起一些附作用，比如，一個或者幾個組件由于需求的變更在項目中不再保留，可以通過開發平臺將其刪除。相應的，業務邏輯中與這一個或者幾個組件相關的代碼，也需要進行修改和刪除。對于少量的這種修改，開發人員可以全面考慮由于需求變更而導致的程序變更，但是一旦需求變更牽涉的功能和組件較多，組件與組件之間通過多種業務邏輯進行聯系，修改一個功能，需要對多個組件，以及多個組件對應的控制邏輯進行修改。在此過程中往往會出現功能對應的組件修改或者刪除了，而相關的控制邏輯卻由于失誤未能作出對應的修改。隨著程序的健壯性越來越好，很多時候對于上面的問題，在進行源程序編譯時并不報錯，程序在正常運行時表面上也能完整的執行規定的控制邏輯。但如果對應功能使用了與被刪除組件相關的數據，即使組件刪除，程序依然試圖調用刪除后的組件對數據進行處理，這種情況下不可避免的會導致程序的運行出錯。而一旦出現這種錯誤，系統很有可能不會針對這一錯誤拋出異常，排查這類問題只能靠開發人員根據邏輯結構逐步檢查數據輸出是否正確，人力成本大大增加。如果此類問題在測試時沒有發現，一旦上線運行時出現這種情況，軟件公司出于對公司技術力量的自信以及多一事不如少一事的心態，常會聲明系統絕對沒有問題，多半是網絡問題。筆者曾經就遇到過這種問題，最后查出系統在某個業務邏輯中使用了短信平臺發短信這個模塊，在短信平臺這個組件修改后，業務邏輯沒有相應調整，導致錯誤，如果能夠避免這個問題，就能節省在檢查網絡上耗費的大量時間。

5對策建議

為完善和解決軟件招標中存在的問題，經過綜合考慮，建議從以下幾個方面來著手解決。

1.在項目招標和建設初期，對系統的功能性描述盡量詳細。在項目上線前要對系統做充分測試，特別是關乎用戶體驗的功能性測試，一定要覆蓋全面。在發現問題或對用戶體驗有更好方案時快速響應，立即修改，并要求軟件公司對系統中的冗余代碼進行清理。

2.在項目招標書和合同的文本中，以書面形式明確質保時間和質保起始時間，做到起止時間界定明確，后期質保工作應嚴格按照合同說明遵照執行。

3.可將目前的招標建設系統方式改為購買軟件服務的方式，在前期軟件試用過程中，選擇一到二家其軟件產品與建設單位應用需求契合度較高的投標單位，前期開發完善程序，等完全符合用戶需求后，再通過購買服務的方式支付費用，在此過程中若能引入競爭機制則對建設單位更加有利，這樣既滿足了用戶的使用需求，又給后期的運維工作帶來方便，避免政府投資風險。

4.對于核心的業務邏輯和重要的數據處理流程，要求投標人給出相關的代碼或偽代碼，并通過必要的流程圖和數據流圖對其進行詳細說明。若業務邏輯和數據處理流程出現變化，應指派專人對這些文檔材料進行對應調整，保持代碼和文檔的一致性，為后期的問題檢測提供準確的第一手資料。

最后，電子政務系統軟件招標建設與服務過程中的問題還有很多，筆者謹從中選取幾個較突出問題進行分析，并希望通過相應對策能夠減少和避免這些問題，節約系統建設成本，降低維護費用，為我國電子政務事業快速、健康發展貢獻自己的一份力量。