1．引言：一个令人困惑不解的现象
对于属于信息系统的气象应用系统而言，其灵魂是运行于硬件平台之上的应用软件系统；因此软件工程之于应用软件系统的作用，基本等同于对应用系统的作用。
虽然软件工程以信息系统建设管理规范的身份昂然进入气象界，并被业务职能部门某些官员自觉运用于指导行业信息化建设过程的法则，还是最近若干年的事。但其方法论中的一些具体措施、方法和规范，早在七十年代末BQS系统建设初期，便已被日本工程师引入到我国气象行业信息化建设中的大规模应用软件研发过程中，并在日后的岁月里余脉不绝。九十年代中期中国气象局颁布的《气象软件工程规范（试行）》和《气象信息系统工程规范（试行）》，可视为这一珍贵工作经验的归纳、提炼和希冀用于指导气象界信息化建设愿望的具体体现。近年来随着行业信息化建设日益社会化的趋势，软件工程已成为一些深谙经营之道的专业软件公司妆扮自己的妖冶粉黛。而一些职能部门的管理者，也往往以能够运用软件工程的规范指导具体业务单位应用软件研发项目，做为体现自己专业化工作水平的标志。目前，软件工程方法论正在气象行业信息化建设的管理层面中悄然流行，渐有成为应用软件研发过程规范宝典的可能。
然而另一方面，气象行业中真正从事应用软件研发工作的人员，却几乎无一例外地对这些规范有所保留。尤其是那些承担规模小、经费少、时间紧的“短平快”项目的软件研发人员，更是对这些规范中的繁文缛节怨声载道，并在实践中态度消极。“先编码、后文档”的现象十分普遍，甚至一些受过软件工程规范培训的团队和个人也概莫能外。对于他们来说，被有意安排在项目建设后期的技术文档编写过程是一段缺乏激情的、乏味、痛苦而又无奈的过程。
笔者曾是软件工程虔诚的推崇者，深知造成这种“有法不依”局面的原因并非这些研发人员认知水平有限、缺乏专业化培训或组织纪律性不强，而是另有原因。
下文就是笔者的一些思考结果。
2．几个可能被忽略的地方
在职能部门以及一些项目管理者当中，有几个地方也许被忽略了，其中较为关键的有两点：（1）软件工程的服务对象和第一受益者究竟是谁？（2）应当怎样看待应用系统，是把它当成一件一成不变的产品？还是将其视为一个不断变化发展的生命体？
2.1 软件工程主要是为软件公司服务的
近年来，由于国家层面的规范化运作，气象行业中等以上规模应用软件的研制主要以外包形式完成。承担研制的单位基本上是社会上的专业软件公司，这些公司有很强的软件设计能力和编码能力，但对气象业务的理解基本处于极其低浅的水平；其唯一值得称道之处在于这些公司全部采用软件工程方法指导其软件研制的全过程。在这些公司富有感染力的宣传中，软件工程似乎是应用软件研制成功的不二法门。
然而我们知道，“软件工程”的概念是为有效控制软件危机的发生而被提出的，而软件危机的主要特征表现在软件公司研制软件的完工日期一再拖后、经费一再超支，甚至工程最终宣告失败等方面。因此通俗地讲，软件工程是为那些以工业化生产模式研制软件产品的软件公司提供的一套规避风险的方法论。它关注的重点是解决软件产品研制过程中因专业化分工所引发出来的一系列协调、控制、质量、经费、进度等问题。事实上，软件工程的中心目标就是把软件作为一种物理的工业产品来开发，要求“采用工程化的原理与方法对软件进行计划、开发和维护”。
所以说，软件工程不是针对软件需求者提出来的，而是针对于专业化软件生产者提出来的。它的第一受益者和适用载体是那些拥有专业设计研发乃至测试能力，但对软件需求者所属行业（至少在初期）一无所知或所知甚少的社会上专以生产软件为业的团体或单位。它的适用对象是那些大型、超大型专业应用软件的生产，惟其如此，专业化分工才能施展其特有的优势，软件工程的长处也才可能发挥出来。
尤其需要强调的是，工业化生产的特点决定了，软件工程是以最终生产出软件产品为目的的；因此对待用户需求的处理策略，软件制作过程中和软件制作完成后呈现出两种完全不同的阶段性特征：软件制作过程中要求对用户的需求尽可能全面、准确的了解、把握并予以实现；但一旦进入制作后期，用户的需求就必须予以“冻结”；而对于用户于软件制作完成后提出的新的需求，则一般不被纳入本软件的工作（包括维护）范围。如同生产照相机等工业产品一样，一旦这款产品定型并形成，对其进行的任何修改和调整便不属于本款产品的工作范围，而是下一款产品的工作内容了。“需求管理”、“需求控制”等便是软件工程由此派生出来的一些具体的操作规程和方法。
2.2气象应用系统不是产品
产品的特点之一，就是一旦制作完成，其自身的功能和性能便被固定下来，不再变化，用户的使用完全局限在产品所提供的已有功能范围之内；而对于产品的维护，则是指恢复那些因某种原因导致无法使用的原设计功能。
气象行业是一个高速发展的，不断被赋予新的工作内容和要求的服务型行业。一个用于实际业务的应用软件系统，身处不断发展的汹涌浪潮之中，无一例外地面临着接二连三的新的需求。即便是实时数据库等基础型应用系统，也时常面临着新增资料入库、新的统计要求的满足，对特定关注区域、类型资料的处理时效的提高等新的功能、性能需求的满足；这些需求都是原系统设计中没有或无法预见，因而目前系统中所不具备的功能；现实决定了不可能因不时出现的新的需求而频繁更换系统，而工作又要求必须及时实现这些新的功能需求；因此这些新增需求只能通过调整、完善和改进等手段在现有系统上予以实现。
所以，事业和业务的发展形势要求气象应用业务系统是一个活的能够适应不断变化需求的生命体，而不是一件死板的一成不变的产品。
3．气象行业应用系统生命周期中一些阶段特征
应用系统生命周期有若干种不同的描述方法，这里采取的是以其自然形态的生长过程进行描述，即：从孕育、产生到成型后的生长。
3.1 系统生长初期??需求的不确定性
一个应用系统的出现和确立，自有其孕育、发育、生长的必要环境??应用需求。而在其初期，这些应用需求往往是模糊和概念性的。以MICAPS为例，虽然在其开始研发之初，国外一些发达国家已不乏类似工作平台的应用实例，有关人员也曾对此进行过十分详尽的认真调研，但Micaps的分析、设计、试用、研讨、改进等循环往复的认识需求、梳理需求、明确需求的探讨和调整过程仍花费了大量时间。这一阶段的时间之长，研讨以及原型系统调整修改之频繁，耗费心血之巨，令参与者至今印象深刻。而在这一阶段，如果采用经典软件工程的方法，研制方即便调集最高级的需求分析师，采用最先进的需求分析方法，反复咨询最权威的系统用户，也难以一举明确真正的应用需求。因为无数事实无一例外地证明，此时潜藏在用户脑海中的需求是模糊和不确定的，在没有实际应用操作之前，即使最权威的行业专家，其所提出的需求也是未经验证的。因此尽早地将模拟系统交予用户，由用户在试用过程中逐步理清思路，明晰并确认需求，是行之有效的，这已被无数实例所证明。所以，原型系统的快速搭建和及早提供试用，在这一阶段十分重要。对于应用系统而言，实际应用所得出的结论和意见永远比闭门造车推演出的书斋成果更实用更有效。
业务系统是通过一定的建设过程而产生的，过程的不同可能导致结果的不同。软件工程以制造软件产品为其特征，产品设计之前对需求完整准确的把握，便成为该款产品是否成功的关键；然而上面已分析过，应用系统初期的需求往往的是模糊而不确定的；尤其对于那些因概念而不是实际需求所产生的项目，其应用需求产自于推断、设计而非实际，应用基础原本就不牢固，因而此时所有通过调研、咨询、研讨等方式获取的需求信息，都是不确定的，是需要经过实际应用予以检验的。因此以这些需求信息为基础构建起来的业务系统，是必须经过较长时间的实际应用和调整，方才可能被真正应用起来的。而如果系统建成后的可调整能力问题??即所谓持续改进能力问题??没有得到落实，则该系统便很可能出现原设计的功能不符合实际需求，而实际需求又无法在系统中实现，从而导致系统的不成功甚至失败的结果。
无论采用何种方式，对于一个在建的应用系统而言，需求越具体，目标越明确，建成后便越易于发挥效益。而具体的需求和目标来源于具体的业务工作；应用系统只有在明确了其服务的具体业务范围以及在该业务中服务的具体内容后，其应用才可能具体实现，价值体现才有了承载平台。亦即，应用系统应当明确具体的业务导向，没有业务导向的应用系统只可能是一个概念上的虚幻的应用系统。而一个不被应用的应用系统，无论其投资如何巨大，包装如何华丽，都将与垃圾无异。
一些承担大型应用型业务系统的设计人员始终对缺少一位对所有业务流程环节的需求都了然于胸的领军人物而深感遗憾，认为这是可能导致项目建设不成功的潜在风险。事实上，由于专业化分工的现实和局限性，以及各专业业务需求变化的纷杂迅猛，这样的领军人物是不可能存在的。但这并不意味着项目建设一定不成功；因为项目的成功在于当时所能明确的所有真实需求的全面满足，而真实需求的梳理、明晰和确认，可以通过实际应用和试用得以逐步实现。所以，在目前这一“缺乏英雄”的年代里，采用尽可能贴近实际的有效手段，及时地明确真实需求，有效地调整系统使之满足真实需求，是保障项目建设成功的最为有效途径之一。
3.2 系统成型之后??有效的调整能力更为重要
在国家气象信息中心（后简称“NMIC”）内部，“业务系统”是一个令人肃然起敬的称谓。一个系统一旦被称之为“业务系统”，则其架构和功能便被基本固定下来，原则上不再允许随意变动。同时必须制订完备的维护计划并配备完备的维护队伍，以期充分保障其运行的稳定可靠。因此，NMIC的业务系统运行保障水平在气象行业内是一流的。
然而熟悉NMIC内部业务系统运行方式的人士也知道，实际上即便是身处最为核心地位的通信系统、数据库系统等业务系统，其功能也是在不断增补和完善的。这里所说的增补完善并非指通过项目建设构建新的业务系统予以实现，而是在日常运行中，通过维护人员根据不断提出的新的需求而对现有系统进行的功能补充完善。日积月累，一段时间后再来审视该业务系统，人们会发现，不经意间其现有功能较之最初设计功能之间已经发生了较大甚至很大的变化，而这些新增功能往往更切合实际、更针对需求因而也是更为适用的。令人尴尬的是，这些功能的改进和增补都是基于对现有业务系统的改进、补充和调整而得以实现的。也就是说，即便是管控最为森严的业务系统，日常过程中也是在被不断地调整、补充和完善的??因为现实需要这样做。
所以我们说，气象行业中的业务系统不是产品，而是活的生命体；它的功能需求是会随着事业和业务的发展而不断增长和变化的。在系统建设初期通过分析调研获得的功能需求并不能代表日后在发展过程中所产生出来的新的需求，甚至于不能完全代表当前业务工作的实际需求；因为用户对需求的认识是需要长时间摸索的，成熟的需求认识只能出现在该业务系统被应用之后而不是之前。事实证明，一个应用型的业务系统是永远生存在不断的调整之中的。
一个物体之所以被称之为活的生命体，在于其具备对外界环境变化的反应和自适应的能力。而其活力的旺盛与否，则表现在其对环境变化反应的灵敏度以及自适应时效的快慢。对于处在高速发展的气象行业而言，以往难以预测的各类新的需求不断涌现，我们当然希望承担业务工作的有关业务系统能够适应环境的变化，满足各类新的需求。亦即，我们需要的是活的具有旺盛生命力的业务系统。反映在技术层面，业务系统的活力主要表现在它的可调整性、调整的效率以及质量；即：即便新的功能需求无法由现有系统直接满足，如果现有系统可通过维护人员的增补和调整予以快速补充，使得调整后的系统满足这些新的功能需求，那么该系统仍然可称得上是一个充满活力的业务系统。
因此，对于一个长期运行的应用型业务系统而言，有效的调整能力比精确的初始设计更加重要。对于一个处在不断变化环境中的应用型业务系统而言，不可能做到一步设计完整准确到位。只有在不断的使用中，用户方才可能逐渐梳理出对业务系统真实的需求；而快速的需求响应机制以及高质量的功能调整，才是评价该业务系统乃至其所属业务工作水平高下的最重要的指标。NMIC在业务系统运行方面多年的业绩，除业务系统自身的品质外，关键在于有一支稳定、精干和高水平的维护队伍，以及较为完备的业务规定；使之能够做到随需快速调整。
应用型业务系统的活力集中体现在其是否具备良好的可调整能力方面。而从宏观上分析，系统是否具备可调整能力以及可调整能力的高下，则主要取决于系统架构的合理行和开放性（这是另一个话题，此处不予展开），以及系统运维规范的完备和运维团队的高效。从某种角度看，后者（即：运维规范和团队）的重要性甚至超过前者；因为系统架构的合理性和开放性，仅仅是为系统的可调整提供了可能，届时调整的具体操作则是需要由维护团队根据一定的规程逐一完成的。所以，单靠设计是无法产生系统的活力的，有效的组织、有针对性的培训和完备的规范措施才是系统活力的实现基础。
4. 气象应用软件研发过程中软件工程的角色和作用
实际上，引言中提出的令人困惑的现象是很容易理解的：气象行业内中小规模的应用软件研发是普遍的，经常性的，且多以小团队作坊式形式出现并延续。相较于以招标形式延请社会上专业软件公司来承担这些项目，小团队作坊式有熟悉业务，明了需求、人员稳定、一专多能等优势，因此诸如“文档驱动”、“过程产品评审”等大规模专业化分工协同工作下的运作法则在这里没有运用的实际需求。“先编码后文档”的变通做法在这一特点环境下并不影响软件质量，而且往往工作效率更高。也就是说，对于那些由小团队作坊式承担的规模资金都相对有限，时间要求严格的应用系统（软件）研发工作来说，软件工程并不适用：因为其工业化生产模式的优势无法发挥，而其固有的种种弱点却彰显得淋漓尽致。
所以，应用系统（软件）在研制初期，因其需求须经反复应用及反馈方可得以认识、理清和明确，经典软件工程由于其工业化产品生产的特点，因而不适用于这一阶段的应用系统（软件）的研制过程。而对于那些规模较小、研制周期很短、功能需求相对有限的应用系统而言，软件工程的优势得不到发挥，劣势却无法避免，因而亦不适宜。
前面的分析已得出结论，软件工程较为适用于大规模及超大规模的应用软件的研发。然而我们知道，一个自然形成的复杂系统是由简单系统生长而成的，而其生长的过程??与植物一样??是需要呵护和培育的。应用型业务系统的生长过程实际上就是新增需求不断满足和旧有缺陷不断弥补的调整过程，换句话说，就是业务系统的持续改进过程。而对其生长过程的呵护和培育，则体现在对持续改进行为的激励机制上。由于新增需求的提出和原有缺陷的发现是日常的、随机的且大部分是零散的，因此改进和调整的行为也应当是日常的、持续的和非大规模的。反映在激励机制的策略安排方面，则以小规模的持续不断的经费支持和以对现有系统调整改善为内容的小型项目支持为宜；正如幼芽的生长需要的是涓涓细流的滋润，婴幼儿需要的是量虽不大但却持续不断的母乳哺育一样。
相对应地，大规模大范围大手笔的应用系统研制项目，比较适合于若干应用业务发育到相对成熟后的规范化系统集成。大项目一般通过招标形式由中标的社会上专业软件公司承担，其优势在于资金雄厚、人力资源丰富、工作程序规范，技术相对先进；其弱点在于承建者对行业业务情况不了解，研制周期的严格限制又使得承建者不能无限期地反复试验摸索，因此其最大的软肋之一在于用户所提需求的概念化和不确定。然而，经过自然的发育过程，已经相对成熟的应用业务的需求大部分早已明确并已被反复应用所证实确认，风险已基本规避，软件工程的优势在这里可以得到较大程度的发挥。也就是说，在应用系统研制方面，软件工程较为适用于以系统集成为主要内容的大型项目建设。而在应用系统发育初期和成长阶段，则以持续不断的小规模建设和改进为宜。
值得注意的是，那些由概念而产生的大规模复杂系统的项目建设，由于缺乏应用基础，因此由此研制的系统不是自然生长起来的，而是构建起来的。然而我们知道，知识积累的过程是无法通过构建过程（亦即研制过程）跨越的，在缺乏应用基础这一先天不足的前提下，单单凭借软件工程华而不实的严谨规则，而不对可能存在的潜在应用需求进行有针对性的、持续不断的培育和发掘，则该系统即便建设时烹油烈火，验收时花团锦簇，也难免之后的曲终人散、乏人问津，乃至最终悄然谢世的悲剧性结局。事实上，这种情况在以前真实发生过，如不认真汲取既有经验和教训，以后还会重复发生。
5．结语：效益是检验应用系统成败的标准
对于气象应用系统，正如“实践是检验真理的唯一标准”一样，效益应当是检验其成败的唯一标准。而应用系统效益的体现，则在于该系统被实际应用以及对应用者提出的新需求的充分满足。要达到这一理想境界，准确有效的应用反馈机制和快速高质量的持续改进机制至关重要。没有这些机制，系统便成为一件死板的产品，无法根据实际需求发展和改进；而这些机制的缺失或不健全，将导致系统在日常运行中面对不断出现的新需求反应迟钝，甚至束手无策。
此外，应用系统效益的展现需要承载平台，而其具体服务的业务领域，既是其具体的业务导向，也是其效益体现的具体的展示窗口和平台。
最后，应用系统是生长起来的，而不是构建起来的。其生长过程，就是新的需求不断被满足和旧有缺陷不断被更正的过程，而其生命力的旺盛与否，则体现于对新增需求满足、已有缺陷改正的时效和质量。
有意思的是，所有这一切，都不是软件工程能够解决的。所以说，目前的信息化理论和方法，只能解释和解决现实信息化建设中遇到问题的很少一部分。大部分问题并无现成的明确答案。而这些问题的有效解决，不仅需要所有有关人员的积极探索和勇于实践，更需要无情解剖自己和正视、改正错误的勇气，坦荡包容的胸怀，以及宽松、平等而科学的研讨氛围。
