1.引言

　　气象行业的信息化进程，已完成了大规模基础型建设，转而进入到信息技术与气象业务深度融合的阶段。对于以气象信息的收集、处理和服务为主要特征的气象行业来说，其实力的体现非但在于高性能计算机、宽带网络通信、新一代天气雷达网、地面观测站网等资源型设备的拥有程度，而且在于对这些资源的高效应用，而应用软件是这些资源应用方法、技巧和步骤的具体体现和执行者。可以预期，未来气象行业各项业务及科研工作对于应用软件的各种需求将越来越旺盛，研制周期越来越有限，质量要求越来越严格。说到底，应用软件的水平是反映气象行业软实力的重要内容之一。

　　由于历史原因，气象行业中原本在长期建设过程中自然形成的软件研发团队已不复存在。目前行业中的中等规模以上应用软件的研发工作完全按照国家政策法规要求，以外包形式交由社会上的专业软件公司承担。小规模软件则或由本单位若干熟悉IT的技术人员自行承担，或以委托形式交由社会上小型软件公司研发。这种现状存在一定问题，如不解决，将长期影响气象行业应用软件质量的提升。

　　本文就这些问题进行了探究，并通过提出重建气象行业自己的软件研发团队的途径试图解决这些问题。

　　2.应用软件是目前信息时代中知识和智慧的重要载体

　　计算机是现代意义上信息技术的核心载体，计算机区别于此前人类发明的所有工具的最主要的特征在于其能够执行程序。而计算机程序的实质，是人类处理事物、解决问题的方法的具体描述，是人类知识和智慧的固化。因此，计算机的独特之处在于能够低成本复制和再现人类的知识和智慧。计算机的出现，引导人们进入了当今的信息时代，而知识和智慧的高速增长和传播是这一时代最主要的特征。

　　气象领域的知识和智慧产生并存在于气象业务之中，它不是由信息技术直接产生的，但信息技术可以复制和再现这些知识和智慧。信息技术复制和再现这些知识和智慧的过程，就是信息技术与气象业务深度融合的过程，而应用软件就是复制和再现的具体工具和手段。计算机、存储设备及网络环境，不过是复制和再现这些知识和智慧的载体和平台——应用软件才是气象业务系统的灵魂。因此，购置计算机、单纯地维护计算机及网络环境，向相关用户提供计算资源和存储资源，已经无法满足信息时代气象事业发展对于信息化进程的需求了;主动地服务于气象业务和科研工作，加强应用软件——特别是气象业务应用软件——的研发，将存在于气象科学书籍论文之中、存在于各种规章制度之中乃至于存在于气象业务人员头脑中的气象知识以计算机软件的形式固化下来，复制出去，在各个相应业务环节上再现出来，以发挥出其自身的价值，才是推动气象业务高速发展的原动力;同时也是身处信息时代的气象行业IT部门的历史使命。

　　所以，气象业务应用软件的发展，应当是信息技术与气象业务深度融合的十分重要的内容之一。

　　3.气象行业应用软件研发现状及存在的问题

　　自上世纪八十年代初建立“BQS系统”开始，气象行业的应用软件研发工作基本上由本行业内部技术人员承担;长期的研发需求以及技术积累，在一些单位内部自然形成了专司于承接本单位应用软件任务的软件研发团队。这些团队虽然规模有限，但具备深刻理解本单位业务需求的先天优势，同时做为本单位的下属机构，能够按照本单位的业务要求很好地完成软件的后期运行维护工作。随着市场化进程的深入，这些团队先后改变了体制的性质，以商业公司的形式和运作模式继续为本单位业务软件研发提供专业化服务;这种现象一直持续到本世纪初。随着国家一系列政策法规的出台，在前一轮行业内部体制改革的过程中，这些团队先后被合并或消解，目前这些专门从事气象行业应用软件研发工作的技术团队已基本不存在了。

　　另一方面，自“九五”以来，随着国力的快速增强，国家加大了做为公益事业的气象行业的投入，气象行业大规模建设项目不断确立。这些建设项目中，除基础型建设内容外，与气象业务相关的应用软件建设项目在其中所占比重越来越大。现实的情况是：目前主持并承担这些应用软件研发任务的单位，主要是相关的气象业务部门，信息技术部门介入得相对较少。

　　3.1 外包是目前中等规模以上应用软件研发的主要模式

　　由于专业的不同，气象业务部门中从事气象业务的技术人员不可能像专业从事信息技术工作的人员一样熟悉信息技术的各项技能。因此对于承担规模较大的应用软件研发任务，在没有自己的研发团队的情况下，气象业务部门终究力难从心，只能依靠外部的IT专业力量才能完成建设任务。另一方面，由于国家财政拨款使用规则的限制，借助外部力量的途径只能通过至少形式上较为公正的公开招标方式，在社会上广征贤能，由中标单位(一般是专业从事软件研发的软件公司)承担。因此，应用软件的外包便成为目前气象行业中等规模以上应用软件研发的主要模式。

　　由于公开招标过程中结果的不确定性，中标的软件公司往往不是熟悉气象行业专业特点和业务特征的公司，因此进入角色的速度相对较慢。同样，由于气象业务部门从事气象业务的技术人员不熟悉信息技术的各项技能，使得他们目前尚不掌握与那些不熟悉气象行业的软件公司的沟通语言和技巧，同时也不掌握如何将目前尚仅存于业务人员头脑中的那些隐性的知识和智慧的完整准确地表达方式(即隐性知识的显性化)。业务人员必须通过与这些软件公司技术人员不断的反复的沟通和交流，方能使本部门业务需求完整清晰地表达出来，并使软件公司技术人员基本上完整准确地了解气象业务部门的真实需求。

　　3.2 软件外包存在的问题

　　应用软件外包的研发模式存在以下问题：

　　(1)需求分析阶段效率低下

　　如果作为甲方的气象业务部门无法运用乙方(外包软件公司)熟悉的工程语言描述自己的需求(包括隐性需求)，那么在项目建设之初的需求理解和分析阶段，如何使乙方完整准确地理解甲方的实际需求，便是一件十分棘手而又无法回避的问题。这等同于在课堂上用对方听不懂的语言向对方讲授一门对方完全陌生的课程，其效果的不理想是十分自然的。而要想最终达到理想的效果，甲乙双方就必须尝试使用各种方法进行反复的沟通和交流，这必将耗费大量的时间和精力，而且要求乙方必须具备很高的咨询能力和认真主动的工作态度，以通过反复的沟通理解甲方的显性需求，通过分析判断挖掘出仅存在于业务人员头脑中的隐性需求并予以确认;否则将难以捕获甲方的真实需求。如果乙方不具备良好的咨询能力，或工作态度较为被动，人云亦云，仅凭阅读甲方现成文档及与甲方的简单交流拼凑出甲方的需求，不做深入的分析研究，则得出的这些需求便不可能完整准确;而依据这些需求设计研制出来的软件也将肯定无法满足甲方的实际需求。这种不成功的案例在业界不胜枚举，在目前气象行业中也不乏例证。

　　即便乙方同时具备良好的咨询能力和积极主动的工作态度，无数事实表明，这一阶段的工作效率也是相当低下的，且难以改善。

　　(2)甲方难以完全掌握核心技术

　　以外包形式研发应用软件，系统建设从需求分析开始，各个工程阶段便几乎完全由乙方主导，其间所涉及到的所有关键性技术或掌握在乙方研发团队手中，或以甲方(气象业务部门)不熟悉的软件工程语言埋藏在浩如烟海的技术文档之中。即便工程结束时产品质量验收合格，移交的技术文档种类齐全、内容完整，也只是意味着乙方为甲方“留下”了关键技术，这并不等同于甲方“掌握了”关键技术。一旦甲方在产品运行过程中遇见各种前期难以预料的问题而需要对应用软件进行功能等方面的变更或补充完善时，由于甲方不熟悉应用软件内部的具体技术实现方式和关键点，难以自行完成这些功能变更和补充完善，这些工作便只能依赖于承建该应用软件研发工作的乙方。这种令人不安的状况显然不利于甲方业务工作的持续发展。

　　(3)后期维护成本很高

　　诚然，甲方可以通过商业合同中的维护期条款对乙方进行行为约束，要求乙方在维护期内承担应用软件的维护(包括变更和补充);但合同条款无法限制乙方公司内部的人员变动和流失。在甲方需要乙方完成应用软件维护工作时，乙方完全有可能因各种因素导致无法派出原参与应用软件研发工作的技术人员，只能差遣对此项目基本一无所知的技术人员前来完成这些工作;这些陌生的新手首先需要通过阅读先期留下的浩如烟海的技术文档，熟悉系统的全貌和技术细节，之后方能开始工作。而另一方面，由于不掌握软件工程的相关技能，做为需求变更方的气象业务部门，其需求的准确表述需要经过乙方的一再记录、交流和沟通方能确定，所有这一切都需要花费大量的时间和精力，进而导致后期维护的显性和隐性成本的大幅增加。这对于一些规模较小、时间紧迫的变更需求而言，显然是难以满足和承受的。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。