伴随着软件产业的快速发展，我国政府电子政务程度不断加深。各地信息化系统建设速度不断加快，越来越多的电子政务系统运行于互联网之上。根据 2003 年 1 月 1日开始实施的《中华人民共和国政府采购法》等有关规定，已建设完成的电子政务系统大部分采用招标采购的建设方式。但笔者在参与多个省级电子政务系统的运维工作多年后发现，由于电子政务系统的行业特殊性，招标采购完成建设的系统在其生命周期的运行和维护阶段会存在一些问题，现总结如下。
1 中标软件公司不能做到定制开发，多为修改复制，系统运行存在隐患
与硬件相比，软件产品无法设立统一的标准，各建设单位的需求干差万别，同一款软件在甲单位适用，在乙单位未必适用。为实现低价中标，软件公司经常将开发的某款软件在甲单位应用后，稍作修改，即投放到乙单位实施部署，在项目投标书上也会说明满足招标书所列功能需求。
但实际结果是电子政务系统的事项办理流程、审批事项的配置习惯等都不能很好的满足乙单位的使用。
比如正在运行的某行政审批软件，基本上是从已经实施完成的省份移植过来，虽有审批功能，但各地的审批流程、业务习惯都不尽相同。并且在软件的部署试运行阶段，当发现某项功能与本项目无关或不符合项目功能需求时，软件公司通常采取将与该功能相关的操作页面标签删除，其功能模块的内部程序并未删除，依然保留在系统代码中。
经过长时间的累积，程序庞大而复杂，堆积的大量无用代码在系统运行时会消耗资源，逐渐导致系统速度缓慢。在试运行阶段，系统模块中的残留代码均不能暴露，只有当程序运行出现问题后，进行问题定位时，才能从源程序中发现大量的无用代码，这给后期的系统运行带来隐患。
2对质保时间的定义各方解释不一，质保服务形同虚设
在软件工程中有一句话叫作:找到的软件缺陷越多，说明未发现的软件缺陷也越多。测试用例写得再好，也不能保证测试修改完成的软件产品没有缺陷。
很多软件产品的内部缺陷短期内无法体现，只有通过一段时间的运行使用后，比如数据量有了一定的积累，或者用户数有了一定增长带来的高并发量，才会出现问题，这时对问题的分析才能逐步发现诸如程序架构和代码编写等方面存在的问题。待到问题发现时，经常质保期已过大半。并且质保期内程序修改的时间不好控制，更有甚者干脆敷衍了事，无限期拖延，以致承诺的服务不能兑现。
另外，软件公司在投标书中对质保期的定义一般为验收或正式上线之日起3一5年。随着项目的完成，软件公司为了尽快回款，业主方也为了能更好的进行后续合作，通常会比较及时的组织项目验收;或者在进行了较为充分的测试后选定日期系统正式上线运行，但验收或者正式上线后应留出充分时间进行设置调整和相关的系统测试。以解决上面所述的问题，按照软件公司定义的质保开始时间，此时间算在质保时间中笔者觉得有待商榷。
3以业务核心代码保密为由，3应用程序后期不能改动
由于电子政务行业特殊性，行政审批系统中的业务需求经常会发生变动，相应的，对需求相关的程序功能也需要作出一些小幅改动和调整。根据程序设计的分层思想，审批业务系统通常可划分为视图层、模型层与控制层，除了视图层一般为页面文件(如日丁ML文件)可直接对其进行某些修改外，模型层和控制层在项目发布上线时一般会将源代码封装、打包、编译成包文件，然后部署到服务器上运行，其内部数据结构和控制逻辑均已无法窥见，某些需求的变动要求对业务逻辑进行修改必须要有编译前的源文件。
对于较小的程序改动或代码审查，业主单位希望能够通过自身技术力量来完成，这就需要获取项目源代码。但大多数软件公司通常以核心代码乃公司商业机密为由拒绝提供，用户自己修改代码变为不可能实现的任务，若提交公司修改则常会出现响应慢或不作为等情况，使系统改动非常困难，无法满足业务需求的变化。
比如当前国家一直致力于行政审批改革，审批项目不断简减、下放，不可避免的会对一些业务需求产生影响，必须合理设计流程配置模块才能满足需求，作为审批系统的核心模块，为了能够满足这种不断变化的流程配置和数据项，模块得设计会变得比较复杂，在运行过程中会出现一些异常缺陷，因而经常修改程序是不可避免的。但目前的状况，又使得程序修改工作的进展变得异常缓慢甚至停滞不前。
4出现问题时以自身系统没有问题为由，拖延推诱系统检查
我们知道，随着计算机技术的不断发展，现在软件系统的规模越来越大，动辄需要上百人月的工作量才能完成。其功能多种多样，业务逻辑复杂，用户权限分类细，不一而足，这些功能和业务逻辑都需要工程师编写代码实现。
对于规模较大的软件企业，其内部一般有针对各行业的开发平台。在此平台上开发，许多功能可以通过拖拽组件，并在此基础上堆砌业务逻辑来完成，此举可以大大节省人工，提高开发效率。但是同时也会引起一些附作用，比如，一个或者几个组件由于需求的变更在项目中不再保留，可以通过开发平台将其删除。相应的，业务逻辑中与这一个或者几个组件相关的代码，也需要进行修改和删除。对于少量的这种修改，开发人员可以全面考虑由于需求变更而导致的程序变更，但是一旦需求变更牵涉的功能和组件较多，组件与组件之间通过多种业务逻辑进行联系，修改一个功能，需要对多个组件，以及多个组件对应的控制逻辑进行修改。在此过程中往往会出现功能对应的组件修改或者删除了，而相关的控制逻辑却由于失误未能作出对应的修改。随着程序的健壮性越来越好，很多时候对于上面的问题，在进行源程序编译时并不报错，程序在正常运行时表面上也能完整的执行规定的控制逻辑。但如果对应功能使用了与被删除组件相关的数据，即使组件删除，程序依然试图调用删除后的组件对数据进行处理，这种情况下不可避免的会导致程序的运行出错。而一旦出现这种错误，系统很有可能不会针对这一错误抛出异常，排查这类问题只能靠开发人员根据逻辑结构逐步检查数据输出是否正确，人力成本大大增加。如果此类问题在测试时没有发现，一旦上线运行时出现这种情况，软件公司出于对公司技术力量的自信以及多一事不如少一事的心态，常会声明系统绝对没有问题，多半是网络问题。笔者曾经就遇到过这种问题，最后查出系统在某个业务逻辑中使用了短信平台发短信这个模块，在短信平台这个组件修改后，业务逻辑没有相应调整，导致错误，如果能够避免这个问题，就能节省在检查网络上耗费的大量时间。
5对策建议
为完善和解决软件招标中存在的问题，经过综合考虑，建议从以下几个方面来着手解决。
1.在项目招标和建设初期，对系统的功能性描述尽量详细。在项目上线前要对系统做充分测试，特别是关乎用户体验的功能性测试，一定要覆盖全面。在发现问题或对用户体验有更好方案时快速响应，立即修改，并要求软件公司对系统中的冗余代码进行清理。
2.在项目招标书和合同的文本中，以书面形式明确质保时间和质保起始时间，做到起止时间界定明确，后期质保工作应严格按照合同说明遵照执行。
3.可将目前的招标建设系统方式改为购买软件服务的方式，在前期软件试用过程中，选择一到二家其软件产品与建设单位应用需求契合度较高的投标单位，前期开发完善程序，等完全符合用户需求后，再通过购买服务的方式支付费用，在此过程中若能引入竞争机制则对建设单位更加有利，这样既满足了用户的使用需求，又给后期的运维工作带来方便，避免政府投资风险。
4.对于核心的业务逻辑和重要的数据处理流程，要求投标人给出相关的代码或伪代码，并通过必要的流程图和数据流图对其进行详细说明。若业务逻辑和数据处理流程出现变化，应指派专人对这些文档材料进行对应调整，保持代码和文档的一致性，为后期的问题检测提供准确的第一手资料。
最后，电子政务系统软件招标建设与服务过程中的问题还有很多，笔者谨从中选取几个较突出问题进行分析，并希望通过相应对策能够减少和避免这些问题，节约系统建设成本，降低维护费用，为我国电子政务事业快速、健康发展贡献自己的一份力量。
