電子政務(wù)系統(tǒng)生命周期的運(yùn)行和維護(hù)問題探討,軟件工程論文

電子政務(wù)系統(tǒng)生命周期的運(yùn)行和維護(hù)問題探討,軟件工程論文伴隨著軟件產(chǎn)業(yè)的快速發(fā)展，我們國家電子政務(wù)程度不斷加深。各地信息化系統(tǒng)建設(shè)速度不斷加快，越來越多的電子政務(wù)系統(tǒng)運(yùn)行于互聯(lián)網(wǎng)之上。根據(jù)2003年1月1日開場施行的(中國采購法〕等有關(guān)規(guī)定，已建設(shè)完成的電子政務(wù)系統(tǒng)大部分采用招標(biāo)采購的建設(shè)方式。但筆者在介入多個省級電子政務(wù)系統(tǒng)的運(yùn)維工作多年后發(fā)現(xiàn)，由于電子政務(wù)系統(tǒng)的行業(yè)特殊性，招標(biāo)采購?fù)瓿山ㄔO(shè)的系統(tǒng)在其生命周期的運(yùn)行和維護(hù)階段會存在一些問題，現(xiàn)總結(jié)如下。1中標(biāo)軟件公司不能做到定制開發(fā)，多為修改復(fù)制，系統(tǒng)運(yùn)行存在隱患與硬件相比，軟件產(chǎn)品無法設(shè)立統(tǒng)一的標(biāo)準(zhǔn)，各建設(shè)單位的需求干差萬別，同一款軟件在甲單位適用，在乙單位未必適用。為實現(xiàn)低價中標(biāo)，軟件公司經(jīng)常將開發(fā)的某款軟件在甲單位應(yīng)用后，稍作修改，即投放到乙單位施行部署，在項目投標(biāo)書上也會講明知足招標(biāo)書所列功能需求。但實際結(jié)果是電子政務(wù)系統(tǒng)的事項辦理流程、審批事項的配置習(xí)慣等都不能很好的知足乙單位的使用。比方正在運(yùn)行的某行政審批軟件，基本上是從已經(jīng)施行完成的省份移植過來，雖有審批功能，但各地的審批流程、業(yè)務(wù)習(xí)慣都不盡一樣。并且在軟件的部署試運(yùn)行階段，當(dāng)發(fā)現(xiàn)某項功能與本項目無關(guān)或不符合項目功能需求時，軟件公司通常采取將與該功能相關(guān)的操作頁面標(biāo)簽刪除，其功能模塊的內(nèi)部程序并未刪除，仍然保存在系統(tǒng)代碼中。經(jīng)過長時間的累積，程序龐大而復(fù)雜，堆積的大量無用代碼在系統(tǒng)運(yùn)行時會消耗資源，逐步導(dǎo)致系統(tǒng)速度緩慢。在試運(yùn)行階段，系統(tǒng)模塊中的殘留代碼均不能暴露，只要當(dāng)程序運(yùn)行出現(xiàn)問題后，進(jìn)行問題定位時，才能從源程序中發(fā)現(xiàn)大量的無用代碼，這給后期的系統(tǒng)運(yùn)行帶來隱患。2對質(zhì)保時間的定義各方解釋不一，質(zhì)保服務(wù)形同虛設(shè)在軟件工程中有一句話叫作:找到的軟件缺陷越多，講明未發(fā)現(xiàn)的軟件缺陷也越多。測試用例寫得再好，也不能保證測試修改完成的軟件產(chǎn)品沒有缺陷。很多軟件產(chǎn)品的內(nèi)部缺陷短期內(nèi)無法具體表現(xiàn)出，只要通過一段時間的運(yùn)行使用后，比方數(shù)據(jù)量有了一定的積累，或者用戶數(shù)有了一定增長帶來的高并發(fā)量，才會出現(xiàn)問題，這時對問題的分析才能逐步發(fā)現(xiàn)諸如程序架構(gòu)和代碼編寫等方面存在的問題。待到問題發(fā)現(xiàn)時，經(jīng)常質(zhì)保期已過大半。并且質(zhì)保期內(nèi)程序修改的時間不好控制，更有甚者干脆敷衍了事，無限期拖延，以致承諾的服務(wù)不能兌現(xiàn)。另外，軟件公司在投標(biāo)書中對質(zhì)保期的定義一般為驗收或正式上線之日起3一5年。隨著項目的完成，軟件公司為了盡快回款，業(yè)主方也為了能更好的進(jìn)行后續(xù)合作，通常會比擬及時的組織項目驗收;或者在進(jìn)行了較為充分的測試后選定日期系統(tǒng)正式上線運(yùn)行，但驗收或者正式上線后應(yīng)留出充分時間進(jìn)行設(shè)置調(diào)整和相關(guān)的系統(tǒng)測試。以解決上面所述的問題，根據(jù)軟件公司定義的質(zhì)保開場時間，此時間算在質(zhì)保時間中筆者覺得有待商榷。3以業(yè)務(wù)核心代碼保密為由，3應(yīng)用程序后期不能改動由于電子政務(wù)行業(yè)特殊性，行政審批系統(tǒng)中的業(yè)務(wù)需求經(jīng)常會發(fā)生變動，相應(yīng)的，對需求相關(guān)的程序功能也需要作出一些小幅改動和調(diào)整。根據(jù)程序設(shè)計的分層思想，審批業(yè)務(wù)系統(tǒng)通?？蓜澐譃橐晥D層、模型層與控制層，除了視圖層一般為頁面文件(如日丁ML文件)可直接對其進(jìn)行某些修改外，模型層和控制層在項目發(fā)布上線時一般會將源代碼封裝、打包、編譯成包文件，然后部署到服務(wù)器上運(yùn)行，其內(nèi)部數(shù)據(jù)構(gòu)造和控制邏輯均已無法窺見，某些需求的變動要求對業(yè)務(wù)邏輯進(jìn)行修改必需要有編譯前的源文件。對于較小的程序改動或代碼審查，業(yè)主單位希望能夠通過本身技術(shù)氣力來完成，這就需要獲取項目源代碼。但大多數(shù)軟件公司通常以核心代碼乃公司商業(yè)機(jī)密為由拒絕提供，用戶自個修改代碼變?yōu)椴豢赡軐崿F(xiàn)的任務(wù)，若提交公司修改則常會出現(xiàn)響應(yīng)慢或不作為等情況，使系統(tǒng)改動非常困難，無法知足業(yè)務(wù)需求的變化。比方當(dāng)下國家一直致力于行政審批改革，審批項目不斷簡減、下放，不可避免的會對一些業(yè)務(wù)需求產(chǎn)生影響，必須合理設(shè)計流程配置模塊才能知足需求，作為審批系統(tǒng)的核心模塊，為了能夠知足這種不斷變化的流程配置和數(shù)據(jù)項，模塊得設(shè)計會變得比擬復(fù)雜，在運(yùn)行經(jīng)過中會出現(xiàn)一些異常缺陷，因此經(jīng)常修改程序是不可避免的。但當(dāng)前的狀況，又使得程序修改工作的進(jìn)展變得異常緩慢甚至停滯不前。4出現(xiàn)問題時以本身系統(tǒng)沒有問題為由，拖延推誘系統(tǒng)檢查我們知道，隨著計算機(jī)技術(shù)的不斷發(fā)展，如今軟件系統(tǒng)的規(guī)模越來越大，動輒需要上百人月的工作量才能完成。其功能多種多樣，業(yè)務(wù)邏輯復(fù)雜，用戶權(quán)限分類細(xì)，不一而足，這些功能和業(yè)務(wù)邏輯都需要工程師編寫代碼實現(xiàn)。對于規(guī)模較大的軟件企業(yè)，其內(nèi)部一般有針對各行業(yè)的開發(fā)平臺。在這里平臺上開發(fā)，很多功能能夠通過拖拽組件，并在這里基礎(chǔ)上堆砌業(yè)務(wù)邏輯來完成，此舉能夠大大節(jié)省人工，提高開發(fā)效率。但是同時也會引起一些附作用，比方，一個或者幾個組件由于需求的變更在項目中不再保存，能夠通過開發(fā)平臺將其刪除。相應(yīng)的，業(yè)務(wù)邏輯中與這一個或者幾個組件相關(guān)的代碼，也需要進(jìn)行修改和刪除。對于少量的這種修改，開發(fā)人員能夠全面考慮由于需求變更而導(dǎo)致的程序變更，但是一旦需求變更牽涉的功能和組件較多，組件與組件之間通太多種業(yè)務(wù)邏輯進(jìn)行聯(lián)絡(luò)，修改一個功能，需要對多個組件，以及多個組件對應(yīng)的控制邏輯進(jìn)行修改。在這里經(jīng)過中往往會出現(xiàn)功能對應(yīng)的組件修改或者刪除了，而相關(guān)的控制邏輯卻由于失誤沒有能作出對應(yīng)的修改。隨著程序的強(qiáng)健性越來越好，很多時候?qū)τ谏厦娴膯栴}，在進(jìn)行源程序編譯時并不報錯，程序在正常運(yùn)行時外表上也能完好的執(zhí)行規(guī)定的控制邏輯。但假如對應(yīng)功能使用了與被刪除組件相關(guān)的數(shù)據(jù)，即便組件刪除，程序仍然試圖調(diào)用刪除后的組件對數(shù)據(jù)進(jìn)行處理，這種情況下不可避免的會導(dǎo)致程序的運(yùn)行出錯。而一旦出現(xiàn)這種錯誤，系統(tǒng)很有可能不會針對這一錯誤拋出異常，排查這類問題只能靠開發(fā)人員根據(jù)邏輯構(gòu)造逐步檢查數(shù)據(jù)輸出能否正確，人力成本大大增加。假如此類問題在測試時沒有發(fā)現(xiàn)，一旦上線運(yùn)行時出現(xiàn)這種情況，軟件公司出于對公司技術(shù)氣力的自信以及多一事不如少一事的心態(tài)，常會聲明系統(tǒng)絕對沒有問題，多半是網(wǎng)絡(luò)問題。筆者曾經(jīng)就碰到過這種問題，最后查出系統(tǒng)在某個業(yè)務(wù)邏輯中使用了短信平臺發(fā)短信這個模塊，在短信平臺這個組件修改后，業(yè)務(wù)邏輯沒有相應(yīng)調(diào)整，導(dǎo)致錯誤，假如能夠避免這個問題，就能節(jié)省在檢查網(wǎng)絡(luò)上消耗損費(fèi)的大量時間。5對策建議為完善和解決軟件招標(biāo)中存在的問題，經(jīng)過綜合考慮，建議從下面幾個方面來著手解決。1.在項目招標(biāo)和建設(shè)初期，對系統(tǒng)的功能性描繪敘述盡量具體。在項目上線前要對系統(tǒng)做充分測試，十分是關(guān)乎用戶體驗的功能性測試，一定要覆蓋全面。在發(fā)現(xiàn)問題或?qū)τ脩趔w驗有更好方案時快速響應(yīng)，立即修改，并要求軟件公司對系統(tǒng)中的冗余代碼進(jìn)行清理。2.在項目招標(biāo)書和合同的文本中，以書面形式明確質(zhì)保時間和質(zhì)保起始時間，做到起止時間界定明確，后期質(zhì)保工作應(yīng)嚴(yán)格根據(jù)合同講明遵照執(zhí)行。3.可將當(dāng)前的招標(biāo)建設(shè)系統(tǒng)方式改為購買軟件服務(wù)的方式，在前期軟件試用經(jīng)過中，選擇一到二家其軟件產(chǎn)品與建設(shè)單位應(yīng)用需求契合度較高的投標(biāo)單位，前期開發(fā)完善程序，等完全符合用戶需求后，再通過購買服務(wù)的方式支付費(fèi)用，在這里經(jīng)過中若能引入競爭機(jī)制則對建設(shè)單位愈加有利，這樣既知足了用戶的使用需求，又給后期的運(yùn)維工作帶來方便，避免投資風(fēng)險。4.對于核心的業(yè)務(wù)邏輯和重要的數(shù)據(jù)處理流程，要求投標(biāo)人給出相關(guān)的代碼或偽代碼，并通過必要的流程圖和數(shù)據(jù)流圖對其進(jìn)行具體講明。若業(yè)務(wù)邏輯和數(shù)據(jù)處理流程出現(xiàn)變化，應(yīng)指派專