软件是与计算机相伴相生的，气象部门也是如此。

　　上世纪五、六十年代，气象部门用于分析处理数据的工具，大致局限在算盘、手摇计算器范围，鲜有电子计算机，遑论计算机软件。

　　上世纪七十年代，气象部门陆续引进了若干台国产晶体管计算机（如DJS-8、108、131等），但由于这些计算机配置简单，既无操作系统，更无标准的输出存储设备（如磁带、磁盘等），甚至连键盘和终端显示器都没有，计算机操作员通过控制面板上的几排不停闪烁着亮光的开关来操纵计算机的各种运行，而使用者只能以纸带或卡片的形式将编写的简单程序（包括数据）通过光电机输入，运算完毕后再通过宽行打印机将计算结果打印在打印纸上供使用者分析。那时由于计算机网络还未出现，存储方式简单而不安全（纸带、卡片），通用计算机语言尚不丰富（仅有如：Fortran、Basic、Arglo等），甚至连英文字母的计算机16进制码都尚未统一（有EBCDIC码和ASCII码之分），气象部门对计算机的应用多是以“程序”形式予以完成的，这些程序规模较小（≤1,000行），通过纸带或卡片保存于个人手中。真正意义上的气象软件尚未出现。

       

　　气象部门成规模的软件，肇始于1980年初投入运行的BQS系统（世界气象组织亚洲通讯枢纽）。BQS系统对于气象业务的意义，在于建立起了实时获取全球气象观测资料的路径和手段；对于气象IT的意义，在于所有的全球气象观测资料通信、数据的处理及绘图等工作，全部由计算机自动处理完成。为此该项目引进了三台大型计算机（日立M-160二台，M-170一台），所有业务功能全部由计算机软件实现，而这些软件全部由气象部门的技术人员在日本专家的指导下设计、编制完成。

　　BQS系统的业务软件，是我国气象部门首个成规模的气象软件，也是我国气象部门首次接触到软件工程这一概念和方法。

　　由于当时国内高性能计算资源奇缺，BQS系统引进的大型计算机（M160、M170）是当时世界上先进的计算机，在国内实属翘楚，且这三台大型机的内存、存储、输入输出设备以及通用计算机语言等配置完整；因此这些大型机在业务空闲时段为全国以及气象部门科研人员提供了良好的运算环境，我国第一代气象预报模式（A模式）就是在这几台大型机上发育成长的。

       

　　作为世界银行第一期农业贷款的使用单位之一，国家气象中心于1984年购买了日本富士通的M360大型计算机以及相应的配套设备，用于气象资料的分析处理，并在其上进行了我国第一代气象预报模式（B模式）的研制和试运行。中国气象科学研究院利用世界银行第二期农业贷款，于1986年从法国引进了大型计算机DPS7，并在其上完成了中尺度模式MM4的引进和试运行。与此同时，一些国际通用的气象绘图软件（如NCAR绘图软件等）也陆续在这些大型机上移植成功，提供使用。

　　上世纪八十年代前期和中期，高档计算器PC-1500在一些省辖气象观测站的普及使用，为台站观测数据的处理和编报提供了便捷的手段。PC-1500内置有BASIC语言，并配有精巧的液晶显示器、键盘和针式打印机，一些省局技术人员在其上编制了基于BASIC语言的气象观测站数据处理程序，实现了地面和高空常规观测数据气象要素的提取和换算以及报文编码等项工作的半自动化处理。国家气象局主管职能部门为此曾召开研讨会，在对其进行相应完善后予以全国范围内推广。由于PC-1500上配有RS232串口，可连接盒式录音机，为这套软件的复制和推广提供了便捷条件。

       

　　与此同期，气象科学研究院通过从中科院获得的五台不同型号的Cormemco微型计算机，尝试用BASIC语言编制高空气象探测信号的全自动化处理软件，并取得一定经验。

　　1988年9月7日，我国第一个自行研制的气象卫星“风云一号”A星发射成功。该卫星的地面接收系统的所有应用软件全部由国家气象卫星中心的技术人员自行设计并编制完成。这是继BQS系统之后我国气象部门又一个完全由部门内部组织设计开发完成的大型计算机软件系统。

　　上世纪八十年代后期，以CONVEX-120为代表的“小巨型机”、以DEC-VAX系列为代表的“小型机”以及以IBM-PC为代表的具有工业规范意义的微机逐步进入气象部门，UNIX和DOS作为通用操作系统开始在气象部门普及。上至中大规模数值预报模式的研究和试运行，下至省地县局常规气象数据的分析处理，各种计算机应用在气象部门全方位展开，相应的各种基于通用操作系统的气象应用软件也开始萌芽破土。由于“小巨型机”和“小型机”均可配有6250bpi磁带驱动器以及各种当时流行的I/O设备（如3.5吋软盘驱动器），而IBM-PC标配有3.5吋软盘驱动器，这为各类气象软件和数据的复制、流转和磁介质保存提供了条件。

　　上世纪九十年代初，微机开始在气象部门进一步普及，从一个处室拥有一、二台微机，到一个科、组拥有一、二台微机，最后到每个技术人员拥有一台微机，拥有程度逐渐大众化。与此同时，微软Windows图形界面操作系统以及鼠标随着微机进入到气象部门的计算机房乃至办公室，气象数据的分析和展示开始向着可视化方向发展。

　　同样在九十年代初，以“粗缆”和“细缆”为主要形式的办公室网络、以及以同轴电缆为主要形式的通用高带宽局域网络开始传入气象部门，同事之间、科室之间的实时数据通信开始出现。随后不久，TCP/IP网络协议，以太网、令牌环、FDDI、ATM等网络形式和概念随着“9210工程”、国家气候中心筹建、风云系列卫星地面测控系统建设等一系列大型项目和工程建设而进入气象部门，局域网络环境迅速形成。技术和科研人员告别了延续十余年的在计算机房集中使用计算资源的“上机”时代，开始自己的办公桌上完成所有业务和科研工作。

　　1992年10月由国务院批复，代号为“9210工程”的气象卫星通信系统工程，是气象部门继BQS系统之后又一个大型信息系统建设工程。该工程利用国产通信卫星亚卫-2号的星载富余带宽，建立起国省地县四级星型卫星通信网络系统，彻底解决了困扰气象部门数十年的气象观探测资料实时获取难题，为天气预报、气候预测以及气象服务等领域业务工作的快速发展奠定了坚实的数据基础。“9210”系统（气象卫星通信系统）与各级气象部门已先后建成的本地局域网系统的有机结合，实现了各级气象部门之间的远程数据通信。

　　“9210”通信系统软件由气象部门独立设计，采用部门内部大协作方式，集体开发完成。

       

　　“9210工程”在成功建立起全气象系统的卫星通信网络的同时，还计划建立国省地县四级气象数据库系统，为此引进了当时业界较为著名的Sybase数据库系统，并随工程建设的各种设备一道布设到各级部门。这是气象部门首次接触到业界规范的商用数据库概念及系统。

　　“9210工程”的另一项成果，是着手开发了第一版用于天气预报员分析天气情况并制作天气预报产品的实时交互式图形/图像桌面系统“气象信息综合分析处理系统”（即：MICAPS系统），填补了我国气象部门在这一业务领域的空白。第一版MICAPS系统与“9210”通信系统一样，完全由气象部门自己设计、自行开发完成。限于当时的设备条件，第一版的MICAPS分别由工作站版和微机版两个小组分头开发。后随着市场上微机性能和功能的快速提升，工作站版MICAPS逐渐淡出；自第二版起，MICAPS全部采用基于Windows的微机版。

　　自出生伊始，有关部门就注意营造MICAPS的生态环境。随着时间的流逝，MICAPS至今已走过二十几个春秋，版本更新到第四版，开发模式也由最初的自行设计、自己开发转变成现在的软件外包。

　　MICAPS是目前我国气象部门最为知名的行业软件之一。

　　上世纪九十年代，气象部门先后从美国引进了巨型向量机CRAY/C92、巨型阵列机IBM-SP和IBM-SP2、大型机Cyber-991/992等大规模和超大规模计算机设备，并同期引进了国产巨型机“银河-I”、“银河-II”及“曙光-100”等国产计算设备，为我国数值天气预报模式的业务运行构建了较为完备的算力环境。短短几年时间，T42、T63、T106等全球谱模式以及MM5等区域天气模式纷纷业务化或准业务运行，天气预报开始向着以数值预报为主要手段的方向发展。

　　与此同时，新组建不久的国家气候中心也在积极从事气候模式的研制、引进、调试和业务化工作，其主要模式有：CCM2、MOMs3及动力延伸预报等，这些工作大部分是在以服务器IBM-59H为主的相对简陋的计算环境下完成的。

　　自1988年9月7日第一颗国产气象卫星“风云-I号”A星始，至上世纪九十年代末，所有发射的风云系列国产气象卫星的地面接收处理系统的软件部分，都是由国家气象卫星中心的技术人员设计、研发、调试并运行的。

　　也是在上世纪九十年代，以ArcGIS和MAPinfo为代表的地理信息系统进入中国大陆并迅速为气象部门所接受，气象服务部门和一些专业气象（如农业气象）部门积极应用这些新概念和新平台拓展自己的工作领域，丰富自己的工作内容，并取得良好成效。与此同时，伴随着工作站这一昙花一现的专用于可视化展示和制作的专用计算机的出现，一批绘图软件也随之进入用户视野，其中以SGI公司的GL库最为著名。而在气象绘图方面，NCAR、Vis5D、GrADS等通用气象绘图软件以源代码或可执行程序形式出现在互联网上，为气象工作者所拥趸。其中GrADS以其适用计算机种类广泛、操作简单、便于个性化补充完善等特点，受到气象从业者（尤其是科研人员）的热捧。

　　同样是上世纪九十年代中期，互联网首先以email形式在气象部门得到应用，相比较纸质信函邮递，电子邮件大大提高了气象工作者之间的远距离通信时效——尤其是越洋跨国通信时效。很快地，气象部门便出现了利用email成功进行越洋数据传输的事例。紧接着，浏览器开始出现并为气象从业者所青睐，通过浏览器搜寻国外各大著名气象单位网站上的各种信息，下载渴望已久的数据资料和软件，成为不少气象工作者上班期间的一项日常工作内容，GrADS绘图软件的迅速普及应用，就是这项工作内容的成果之一。由于互联网上丰富的气象数据资源，许多原本因缺乏相关数据而无法开展的业务工作因此而得以开展，一些单位甚至将国外网站上所发布的专业气象数据作为本单位业务的数据来源，并为此建立了相应的业务系统，编制相应的下载软件，以便定时下载获取；其中的一些业务甚至延续二十余年，直至现在。

　　九十年代中后期，国家气象中心依托DEC公司的小型机VAX6320开发出了我国第一套气象实时资料数据库，并正式投入运行，为国家级气象业务单位提供由国际和国内通信系统所获得的实时气象资料服务。该数据库的投入运行，在气象部门内部首次实现了实时气象资料的数据管理和共享，并为日后一系列气象数据库的建设进行了有益的探索和实践。

　　也是在九十年代后期，国家气象中心以引进的IBM Lotus/Notes为依托，首次在全气象系统建立起办公自动化平台。该平台最初以邮件、文字对话、日程安排、会议管理等为主要功能。该平台以业务单位为节点，基本达到了受众范围的横向到边、纵向到底，从而使得气象部门的办公效率得以大幅提升。

　　同样是在上世纪九十年代后期，由于“9210”工程、局域网以及计算机的普及，许多因计算资源和通信资源问题而被迟滞的业务工作因之而得以陆续展开，气象各部门纷纷自己着手建设或完善领域内的各项业务工作，业务系统建设数量和规模明显上升。由于气象业务的特点，几乎所有气象业务系统的建设最终都将归结到相关的气象信息系统建设、归结到软件研发。而由于各单位相应技术力量和水平参差不齐，业务系统建设的质量亦出现较明显差异。有鉴于此，有关职能部门在总结BQS系统和9210系统建设经验，并参照当时国家颁布的相关标准规范的基础上，编制并发布了《气象信息工程建设规范》和《气象软件工程规范》，试图以此来规范气象部门内部的业务系统建设，保证工程质量。

　　二十一世纪初，中国气象局抽调全国各省数值预报业务和科研骨干，成立了“数值预报创新基地”，开始研制国产数值预报模式GRAPS。在此前后，由于国产气象卫星研制和发射计划的有序进行，各待发射国产气象卫星的地面接收处理系统需要一一设计和建设，国家卫星气象中心为此成立了 “星地通公司”，专职于国产气象卫星地面接收系统设计和研制。为进一步规范软件研发过程，该公司特意引进了专门人才，以推进软件工程理念、方法的贯彻和实施。华云信息科技有限公司（简称“华信公司”）则是在九十年代中期，依托“9210工程”而成立的信息系统集成公司，专司承接国家气象中心中大型气象软件的研发任务。

　　二十一世纪头十年，是气象软件高速发展的十年，除风云系列国产气象卫星地面接收系统及相应的远程数据传输系统外，国家级气象资料管理系统、新一代国内通信系统、卫星视频会商系统等一批基础性工程陆续展开并完成。其中：

　　国家级气象资料存储系统（MDSS）首次在国家级层面上实现了除卫星资料外所有实时和历史气象资料的统一规范化管理、服务。该系统首次运用商用关系型数据库（ORACLE）实现了结构化气象资料的规范化管理，实现了结构化、非结构化气象数据的一体化管理，实现了热、温、冷数据的动态迁移和回迁，实现了气象数据的规范化对外服务。

　　上世纪九十年代建成的“9210工程”首次实现了气象观探测资料的实时传输，具有划时代里程碑意义。但由于所依托的通信卫星富余带宽资源有限，无法适应日益增长的气象观测资料、数据和服务产品的传输需求。因此在新世纪之初，在三大运营商地面光纤宽带通信迅速发展的背景下，依托地面光纤宽带通信公共资源，国家气象信息中心启动、实施并完成了“光纤为主、卫星为辅”的新一代国内通信系统的设计和建设工作，为此后气象观测、预报和服务领域的高速发展奠定了坚实的通信基础。

　　由于上世纪九十年代一系列大规模信息基础设施的建设，气象系统各业务部门终于摆脱了因计算、通信、存储等IT基础资源长期短缺所造成的窘境，业务创新与发展热情空前高涨，业务系统建设遍地开花。一批涉及短时临近预报、干旱预测、台风、农业气象等重要业务领域的业务系统，依托国内通信系统、Internet系统、数据库系统、绘图系统、地理信息系统等基础性平台而逐一建立或重建起来。这些系统以及相应业务软件的建设，绝大部分是由项目所属单位自行设计、开发、运行和维护的。

　　2008年，为贯彻执行国务院政企分离的重要指示精神，气象部门内部采取了大规模行动，许多挂靠在各单位业务处室之下的小微企业纷纷关闭，中大规模企业如星地通、华信等公司则逐步独立经营，与原有挂靠单位不再有直接往来。伴随而来的是这些企业中的不少业务骨干纷纷或出走、或回归业务单位，积累十余年的技术力量大量流失，令企业经营者痛心疾首，一时茫然不知所措。

　　政企分离措施对气象软件研发工作最直接的影响，是彻底断绝了气象部门内部自行研发气象软件的经费来源，迫使气象部门转而寻求社会力量，以软件项目外包形式来完成气象软件的设计和研发工作。自此，气象软件逐步走上了“软件研制项目化”的道路。

　　“软件研制项目化”的直接结果，是使气象部门摆脱了气象软件自己设计、自己研发、自己运行、自己维护的小作坊型生产模式，气象软件的规模不再受到限制，一些大型和超大型气象软件陆续被研制出来，同时软件的质量得到了相当的保证。

　　“软件研制项目化”的另一个结果，是软件研发周期的确定性作为刚需被强制遵守。甲乙双方在研制时间上都有明确要求，气象部门作为甲方在付出费用后，希望能在预想的时间内得到满意的结果——即便在需求一时梳理不清的情况下；而乙方出于企业经营考虑，更不可能无限期地在需求、功能和性能等方面与甲方无休止地磨合，需求在梳理到一定阶段后必须冻结，后续跟进的软件设计和研发一切以冻结时的需求为依据。而需求一旦固定下来，软件的功能和性能也就随之固定下来，研制出来的软件以“产品”的形式提供给甲方，这就是所谓“软件形态产品化”。

　　“软件研制项目化”的再一个结果，是项目外包承接方的不确定性。由于软件研制项目外包多采用招标形式，为公平起见，甲方不可能直接指定承接商，一切以投标企业的投标书和评标专家组的评判结果为结果。因此最终中标者很可能是甲方不熟悉甚至不中意的陌生企业。这对于一些以升级和更新换代为目标的气象软件的研制是相当不利的，因为陌生的中标企业对需要升级的原软件不熟悉，而对于一个大规模软件而言，由陌生到熟悉的过程，对甲乙双方而言都是十分痛苦的过程。受到时间、人力资源和经费的三重压力，多数情况下陌生的中标企业不可能投入充足的时间和人力资源来了解、熟悉并掌握原有软件的各种技术细节，技术人员宁可推倒重来，在需求的基础上重新研制一套新的软件产品，也不愿埋头一页页一行行阅读原有软件的各种技术文本，以求在字里行间中获取原有软件的设计理念、风格、方法和具体技术手段。新研制的升级软件不是在原有软件基础之上继承开发，而是在一片平地上另起炉灶、重打鼓另开张，原有软件的继承性受到破坏——即所谓“软件升级断代化”。

　　“软件研制项目化”的最后一个较有影响的结果，是研制团队的临时性。从建设项目管理角度而言，研制团队因项目而聚，项目结束而散，原本天经地义、无可厚非。然对于气象软件（尤其是那些关键业务的软件系统）而言，如果没有一支较稳定的团队（甚或小组）对该软件持续跟踪，发现问题、记录问题、分析问题并最终解决问题，或者将所有发现的问题归纳汇总，作为软件下一个版本的需求内容之一，那么这个软件实际上便置身于一种乏人问津的环境之中，败枝无人修剪、干涸无人浇灌，听凭其自生自灭，此即所谓“软件生态荒芜化”。

　　实事求是地说，并非所有气象软件都需要培育生态环境，如：国内通信系统、气象卫星地面接收系统等，这些系统功能需求明确（且不会变更），能力边界清晰，并有其自身的特定运行环境和业务流程节点位置，只要运维措施得当，终其一生也不需要对其悉心观察、小心呵护。

　　但也确有不少气象软件，因其最初的需求不确定、不完整或应对新情况需要调整增加新的功能，导致功能需求的不断变化。这样的情形在面向用户的、以应用和服务为主要特征的气象软件中随处可见。这种气象软件，与其说是产品，不如说是生命体，因为它一直处于生长变化状态。而生长状态中的气象软件，最为需要的就是良好的生态环境。

　　很遗憾，除MICAPS等仅有的几个知名气象软件外，不少以应用和服务为特征的“生命体”气象软件，其所处生态环境并不理想，一些大型应用服务软件因项目验收后缺乏后续的应用培训、推广普及、技术交流和经验总结等有效的生态培育机制的建立和落实，软件项目的验收之日，便是该软件的凋零之始。即便主导者以行政命令强行推广，也往往事倍功半，难收预期之功。过若干年后，不得不再以另一个单位，用另一个名称重新再建一遍，令前番所做的所有工作、花费的巨额投入全部消散于无形中（熟悉情况的人对此心知肚明，为避免不必要的纠葛，此处不予举例）。

　　所以，软件研制项目化，软件形态产品化、软件升级断代化和软件生态荒芜化，是十余年来困扰气象软件的幽灵。

　　对此，气象部门并非束手无策，只能坐困愁城，笔者认为至少有以下应对策略：

　　一、着力培育优秀的意图贯彻员和项目管理员

　　事实上，国内各大互联网企业、电讯运营商、银行等都拥有自己实力雄厚、技术精湛的软件研发团队，以满足自身业务变更和发展的需要。气象部门即便因各种原因不能拥有类似的机构，只能以项目外包形式实现业务发展目标，则起码应当配置适当的技术岗位，拥有若干熟悉业务、了解技术、善于交流、掌握项目管理技能并具备一定组织能力的技术骨干，通过技术交流和项目管理等途径，在项目执行过程中完美地贯彻甲方的业务意图，而不是将所有管控工作悉数交予监理部门；同时，应当尽可能培育熟悉气象业务的、有较强专业擅长的长期稳定的合作伙伴；以此来减缓因项目外包所可能导致的一些负面效应。

　　二、引入敏捷业务概念，采用敏捷开发模式

　　气象部门的许多业务并非稳态，其功能是需要不时变化和更新的，有些业务需要快速发布，不断更新迭代，这在气象服务领域尤为常见；一些虽以“平台”著称，但用户需要在其上进行各种开发应用的软件平台，也有功能不断补充和组合的现实需求；采用经典的软件工程方法研制和维护这类业务显然存在缺陷。因此，气象部门需要引进“敏捷业务”概念，以“稳态”和“敏捷”双模式架构共同驱动业务发展。就软件研制方式而言，气象部门在以经典软件工程为灵魂的软件项目外包之外，需要引进敏捷开发模式，并着意培养掌握相应技能的敏捷开发技术骨干，以适应敏捷业务的各种需求；职能管理部门则需要给予相应的配套政策支持。事实上，相应的技术和研制模式（如“微服务”等）已经成熟，一些单位已经在具体应用了。

　　三、培育良好的软件生态环境

　　应用和服务型业务及软件需要下大力气培育良好的生态环境，以利其茁壮成长，这是常识；相应的方法和手段也尽人皆知；问题的关键在于贯彻和落实。这不是技术问题，而是机制和管理问题，且并非无解。故在此不予展开。

　　总之，气象软件的发展历程充满艰辛，成果辉煌。目前虽面临诸多问题和挑战，但这毕竟仅为行路上的羁绊，只要认真面对、积极思考、着力解决，发展的前景依旧光明。

2021年12月16—20日，草稿。

20日，修改