1．引言：一個令人困惑不解的現象

　　對于屬于信息系統的氣象應用系統而言，其靈魂是運行于硬件平臺之上的應用軟件系統；因此軟件工程之于應用軟件系統的作用，基本等同于對應用系統的作用。

　　雖然軟件工程以信息系統建設管理規范的身份昂然進入氣象界，并被業務職能部門某些官員自覺運用于指導行業信息化建設過程的法則，還是最近若干年的事。但其方法論中的一些具體措施、方法和規范，早在七十年代末BQS系統建設初期，便已被日本工程師引入到我國氣象行業信息化建設中的大規模應用軟件研發過程中，并在日后的歲月里余脈不絕。九十年代中期中國氣象局頒布的《氣象軟件工程規范（試行）》和《氣象信息系統工程規范（試行）》，可視為這一珍貴工作經驗的歸納、提煉和希冀用于指導氣象界信息化建設愿望的具體體現。近年來隨著行業信息化建設日益社會化的趨勢，軟件工程已成為一些深諳經營之道的專業軟件公司妝扮自己的妖冶粉黛。而一些職能部門的管理者，也往往以能夠運用軟件工程的規范指導具體業務單位應用軟件研發項目，做為體現自己專業化工作水平的標志。目前，軟件工程方法論正在氣象行業信息化建設的管理層面中悄然流行，漸有成為應用軟件研發過程規范寶典的可能。

　　然而另一方面，氣象行業中真正從事應用軟件研發工作的人員，卻幾乎無一例外地對這些規范有所保留。尤其是那些承擔規模小、經費少、時間緊的“短平快”項目的軟件研發人員，更是對這些規范中的繁文縟節怨聲載道，并在實踐中態度消極。“先編碼、后文檔”的現象十分普遍，甚至一些受過軟件工程規范培訓的團隊和個人也概莫能外。對于他們來說，被有意安排在項目建設后期的技術文檔編寫過程是一段缺乏激情的、乏味、痛苦而又無奈的過程。

　　筆者曾是軟件工程虔誠的推崇者，深知造成這種“有法不依”局面的原因并非這些研發人員認知水平有限、缺乏專業化培訓或組織紀律性不強，而是另有原因。

　　下文就是筆者的一些思考結果。

　　2．幾個可能被忽略的地方

　　在職能部門以及一些項目管理者當中，有幾個地方也許被忽略了，其中較為關鍵的有兩點：（1）軟件工程的服務對象和第一受益者究竟是誰？（2）應當怎樣看待應用系統，是把它當成一件一成不變的產品？還是將其視為一個不斷變化發展的生命體？

　　2.1 軟件工程主要是為軟件公司服務的

　　近年來，由于國家層面的規范化運作，氣象行業中等以上規模應用軟件的研制主要以外包形式完成。承擔研制的單位基本上是社會上的專業軟件公司，這些公司有很強的軟件設計能力和編碼能力，但對氣象業務的理解基本處于極其低淺的水平；其唯一值得稱道之處在于這些公司全部采用軟件工程方法指導其軟件研制的全過程。在這些公司富有感染力的宣傳中，軟件工程似乎是應用軟件研制成功的不二法門。

　　然而我們知道，“軟件工程”的概念是為有效控制軟件危機的發生而被提出的，而軟件危機的主要特征表現在軟件公司研制軟件的完工日期一再拖后、經費一再超支，甚至工程最終宣告失敗等方面。因此通俗地講，軟件工程是為那些以工業化生產模式研制軟件產品的軟件公司提供的一套規避風險的方法論。它關注的重點是解決軟件產品研制過程中因專業化分工所引發出來的一系列協調、控制、質量、經費、進度等問題。事實上，軟件工程的中心目標就是把軟件作為一種物理的工業產品來開發，要求“采用工程化的原理與方法對軟件進行計劃、開發和維護”。

　　所以說，軟件工程不是針對軟件需求者提出來的，而是針對于專業化軟件生產者提出來的。它的第一受益者和適用載體是那些擁有專業設計研發乃至測試能力，但對軟件需求者所屬行業（至少在初期）一無所知或所知甚少的社會上專以生產軟件為業的團體或單位。它的適用對象是那些大型、超大型專業應用軟件的生產，惟其如此，專業化分工才能施展其特有的優勢，軟件工程的長處也才可能發揮出來。

　　尤其需要強調的是，工業化生產的特點決定了，軟件工程是以最終生產出軟件產品為目的的；因此對待用戶需求的處理策略，軟件制作過程中和軟件制作完成后呈現出兩種完全不同的階段性特征：軟件制作過程中要求對用戶的需求盡可能全面、準確的了解、把握并予以實現；但一旦進入制作后期，用戶的需求就必須予以“凍結”；而對于用戶于軟件制作完成后提出的新的需求，則一般不被納入本軟件的工作（包括維護）范圍。如同生產照相機等工業產品一樣，一旦這款產品定型并形成，對其進行的任何修改和調整便不屬于本款產品的工作范圍，而是下一款產品的工作內容了。“需求管理”、“需求控制”等便是軟件工程由此派生出來的一些具體的操作規程和方法。

　　2.2氣象應用系統不是產品

　　產品的特點之一，就是一旦制作完成，其自身的功能和性能便被固定下來，不再變化，用戶的使用完全局限在產品所提供的已有功能范圍之內；而對于產品的維護，則是指恢復那些因某種原因導致無法使用的原設計功能。

　　氣象行業是一個高速發展的，不斷被賦予新的工作內容和要求的服務型行業。一個用于實際業務的應用軟件系統，身處不斷發展的洶涌浪潮之中，無一例外地面臨著接二連三的新的需求。即便是實時數據庫等基礎型應用系統，也時常面臨著新增資料入庫、新的統計要求的滿足，對特定關注區域、類型資料的處理時效的提高等新的功能、性能需求的滿足；這些需求都是原系統設計中沒有或無法預見，因而目前系統中所不具備的功能；現實決定了不可能因不時出現的新的需求而頻繁更換系統，而工作又要求必須及時實現這些新的功能需求；因此這些新增需求只能通過調整、完善和改進等手段在現有系統上予以實現。

　　所以，事業和業務的發展形勢要求氣象應用業務系統是一個活的能夠適應不斷變化需求的生命體，而不是一件死板的一成不變的產品。

　　3．氣象行業應用系統生命周期中一些階段特征

　　應用系統生命周期有若干種不同的描述方法，這里采取的是以其自然形態的生長過程進行描述，即：從孕育、產生到成型后的生長。

　　3.1 系統生長初期——需求的不確定性

　　一個應用系統的出現和確立，自有其孕育、發育、生長的必要環境——應用需求。而在其初期，這些應用需求往往是模糊和概念性的。以MICAPS為例，雖然在其開始研發之初，國外一些發達國家已不乏類似工作平臺的應用實例，有關人員也曾對此進行過十分詳盡的認真調研，但Micaps的分析、設計、試用、研討、改進等循環往復的認識需求、梳理需求、明確需求的探討和調整過程仍花費了大量時間。這一階段的時間之長，研討以及原型系統調整修改之頻繁，耗費心血之巨，令參與者至今印象深刻。而在這一階段，如果采用經典軟件工程的方法，研制方即便調集最高級的需求分析師，采用最先進的需求分析方法，反復咨詢最權威的系統用戶，也難以一舉明確真正的應用需求。因為無數事實無一例外地證明，此時潛藏在用戶腦海中的需求是模糊和不確定的，在沒有實際應用操作之前，即使最權威的行業專家，其所提出的需求也是未經驗證的。因此盡早地將模擬系統交予用戶，由用戶在試用過程中逐步理清思路，明晰并確認需求，是行之有效的，這已被無數實例所證明。所以，原型系統的快速搭建和及早提供試用，在這一階段十分重要。對于應用系統而言，實際應用所得出的結論和意見永遠比閉門造車推演出的書齋成果更實用更有效。

　　業務系統是通過一定的建設過程而產生的，過程的不同可能導致結果的不同。軟件工程以制造軟件產品為其特征，產品設計之前對需求完整準確的把握，便成為該款產品是否成功的關鍵；然而上面已分析過，應用系統初期的需求往往的是模糊而不確定的；尤其對于那些因概念而不是實際需求所產生的項目，其應用需求產自于推斷、設計而非實際，應用基礎原本就不牢固，因而此時所有通過調研、咨詢、研討等方式獲取的需求信息，都是不確定的，是需要經過實際應用予以檢驗的。因此以這些需求信息為基礎構建起來的業務系統，是必須經過較長時間的實際應用和調整，方才可能被真正應用起來的。而如果系統建成后的可調整能力問題——即所謂持續改進能力問題——沒有得到落實，則該系統便很可能出現原設計的功能不符合實際需求，而實際需求又無法在系統中實現，從而導致系統的不成功甚至失敗的結果。

　　無論采用何種方式，對于一個在建的應用系統而言，需求越具體，目標越明確，建成后便越易于發揮效益。而具體的需求和目標來源于具體的業務工作；應用系統只有在明確了其服務的具體業務范圍以及在該業務中服務的具體內容后，其應用才可能具體實現，價值體現才有了承載平臺。亦即，應用系統應當明確具體的業務導向，沒有業務導向的應用系統只可能是一個概念上的虛幻的應用系統。而一個不被應用的應用系統，無論其投資如何巨大，包裝如何華麗，都將與垃圾無異。

　　一些承擔大型應用型業務系統的設計人員始終對缺少一位對所有業務流程環節的需求都了然于胸的領軍人物而深感遺憾，認為這是可能導致項目建設不成功的潛在風險。事實上，由于專業化分工的現實和局限性，以及各專業業務需求變化的紛雜迅猛，這樣的領軍人物是不可能存在的。但這并不意味著項目建設一定不成功；因為項目的成功在于當時所能明確的所有真實需求的全面滿足，而真實需求的梳理、明晰和確認，可以通過實際應用和試用得以逐步實現。所以，在目前這一“缺乏英雄”的年代里，采用盡可能貼近實際的有效手段，及時地明確真實需求，有效地調整系統使之滿足真實需求，是保障項目建設成功的最為有效途徑之一。

　　3.2 系統成型之后——有效的調整能力更為重要

　　在國家氣象信息中心（后簡稱“NMIC”）內部，“業務系統”是一個令人肅然起敬的稱謂。一個系統一旦被稱之為“業務系統”，則其架構和功能便被基本固定下來，原則上不再允許隨意變動。同時必須制訂完備的維護計劃并配備完備的維護隊伍，以期充分保障其運行的穩定可靠。因此，NMIC的業務系統運行保障水平在氣象行業內是一流的。

　　然而熟悉NMIC內部業務系統運行方式的人士也知道，實際上即便是身處最為核心地位的通信系統、數據庫系統等業務系統，其功能也是在不斷增補和完善的。這里所說的增補完善并非指通過項目建設構建新的業務系統予以實現，而是在日常運行中，通過維護人員根據不斷提出的新的需求而對現有系統進行的功能補充完善。日積月累，一段時間后再來審視該業務系統，人們會發現，不經意間其現有功能較之最初設計功能之間已經發生了較大甚至很大的變化，而這些新增功能往往更切合實際、更針對需求因而也是更為適用的。令人尷尬的是，這些功能的改進和增補都是基于對現有業務系統的改進、補充和調整而得以實現的。也就是說，即便是管控最為森嚴的業務系統，日常過程中也是在被不斷地調整、補充和完善的——因為現實需要這樣做。

　　所以我們說，氣象行業中的業務系統不是產品，而是活的生命體；它的功能需求是會隨著事業和業務的發展而不斷增長和變化的。在系統建設初期通過分析調研獲得的功能需求并不能代表日后在發展過程中所產生出來的新的需求，甚至于不能完全代表當前業務工作的實際需求；因為用戶對需求的認識是需要長時間摸索的，成熟的需求認識只能出現在該業務系統被應用之后而不是之前。事實證明，一個應用型的業務系統是永遠生存在不斷的調整之中的。

　　一個物體之所以被稱之為活的生命體，在于其具備對外界環境變化的反應和自適應的能力。而其活力的旺盛與否，則表現在其對環境變化反應的靈敏度以及自適應時效的快慢。對于處在高速發展的氣象行業而言，以往難以預測的各類新的需求不斷涌現，我們當然希望承擔業務工作的有關業務系統能夠適應環境的變化，滿足各類新的需求。亦即，我們需要的是活的具有旺盛生命力的業務系統。反映在技術層面，業務系統的活力主要表現在它的可調整性、調整的效率以及質量；即：即便新的功能需求無法由現有系統直接滿足，如果現有系統可通過維護人員的增補和調整予以快速補充，使得調整后的系統滿足這些新的功能需求，那么該系統仍然可稱得上是一個充滿活力的業務系統。

　　因此，對于一個長期運行的應用型業務系統而言，有效的調整能力比精確的初始設計更加重要。對于一個處在不斷變化環境中的應用型業務系統而言，不可能做到一步設計完整準確到位。只有在不斷的使用中，用戶方才可能逐漸梳理出對業務系統真實的需求；而快速的需求響應機制以及高質量的功能調整，才是評價該業務系統乃至其所屬業務工作水平高下的最重要的指標。NMIC在業務系統運行方面多年的業績，除業務系統自身的品質外，關鍵在于有一支穩定、精干和高水平的維護隊伍，以及較為完備的業務規定；使之能夠做到隨需快速調整。

　　應用型業務系統的活力集中體現在其是否具備良好的可調整能力方面。而從宏觀上分析，系統是否具備可調整能力以及可調整能力的高下，則主要取決于系統架構的合理行和開放性（這是另一個話題，此處不予展開），以及系統運維規范的完備和運維團隊的高效。從某種角度看，后者（即：運維規范和團隊）的重要性甚至超過前者；因為系統架構的合理性和開放性，僅僅是為系統的可調整提供了可能，屆時調整的具體操作則是需要由維護團隊根據一定的規程逐一完成的。所以，單靠設計是無法產生系統的活力的，有效的組織、有針對性的培訓和完備的規范措施才是系統活力的實現基礎。


4. 氣象應用軟件研發過程中軟件工程的角色和作用

　　實際上，引言中提出的令人困惑的現象是很容易理解的：氣象行業內中小規模的應用軟件研發是普遍的，經常性的，且多以小團隊作坊式形式出現并延續。相較于以招標形式延請社會上專業軟件公司來承擔這些項目，小團隊作坊式有熟悉業務，明了需求、人員穩定、一專多能等優勢，因此諸如“文檔驅動”、“過程產品評審”等大規模專業化分工協同工作下的運作法則在這里沒有運用的實際需求。“先編碼后文檔”的變通做法在這一特點環境下并不影響軟件質量，而且往往工作效率更高。也就是說，對于那些由小團隊作坊式承擔的規模資金都相對有限，時間要求嚴格的應用系統（軟件）研發工作來說，軟件工程并不適用：因為其工業化生產模式的優勢無法發揮，而其固有的種種弱點卻彰顯得淋漓盡致。

　　所以，應用系統（軟件）在研制初期，因其需求須經反復應用及反饋方可得以認識、理清和明確，經典軟件工程由于其工業化產品生產的特點，因而不適用于這一階段的應用系統（軟件）的研制過程。而對于那些規模較小、研制周期很短、功能需求相對有限的應用系統而言，軟件工程的優勢得不到發揮，劣勢卻無法避免，因而亦不適宜。

　　前面的分析已得出結論，軟件工程較為適用于大規模及超大規模的應用軟件的研發。然而我們知道，一個自然形成的復雜系統是由簡單系統生長而成的，而其生長的過程——與植物一樣——是需要呵護和培育的。應用型業務系統的生長過程實際上就是新增需求不斷滿足和舊有缺陷不斷彌補的調整過程，換句話說，就是業務系統的持續改進過程。而對其生長過程的呵護和培育，則體現在對持續改進行為的激勵機制上。由于新增需求的提出和原有缺陷的發現是日常的、隨機的且大部分是零散的，因此改進和調整的行為也應當是日常的、持續的和非大規模的。反映在激勵機制的策略安排方面，則以小規模的持續不斷的經費支持和以對現有系統調整改善為內容的小型項目支持為宜；正如幼芽的生長需要的是涓涓細流的滋潤，嬰幼兒需要的是量雖不大但卻持續不斷的母乳哺育一樣。

　　相對應地，大規模大范圍大手筆的應用系統研制項目，比較適合于若干應用業務發育到相對成熟后的規范化系統集成。大項目一般通過招標形式由中標的社會上專業軟件公司承擔，其優勢在于資金雄厚、人力資源豐富、工作程序規范，技術相對先進；其弱點在于承建者對行業業務情況不了解，研制周期的嚴格限制又使得承建者不能無限期地反復試驗摸索，因此其最大的軟肋之一在于用戶所提需求的概念化和不確定。然而，經過自然的發育過程，已經相對成熟的應用業務的需求大部分早已明確并已被反復應用所證實確認，風險已基本規避，軟件工程的優勢在這里可以得到較大程度的發揮。也就是說，在應用系統研制方面，軟件工程較為適用于以系統集成為主要內容的大型項目建設。而在應用系統發育初期和成長階段，則以持續不斷的小規模建設和改進為宜。

　　值得注意的是，那些由概念而產生的大規模復雜系統的項目建設，由于缺乏應用基礎，因此由此研制的系統不是自然生長起來的，而是構建起來的。然而我們知道，知識積累的過程是無法通過構建過程（亦即研制過程）跨越的，在缺乏應用基礎這一先天不足的前提下，單單憑借軟件工程華而不實的嚴謹規則，而不對可能存在的潛在應用需求進行有針對性的、持續不斷的培育和發掘，則該系統即便建設時烹油烈火，驗收時花團錦簇，也難免之后的曲終人散、乏人問津，乃至最終悄然謝世的悲劇性結局。事實上，這種情況在以前真實發生過，如不認真汲取既有經驗和教訓，以后還會重復發生。

　　5．結語：效益是檢驗應用系統成敗的標準

　　對于氣象應用系統，正如“實踐是檢驗真理的唯一標準”一樣，效益應當是檢驗其成敗的唯一標準。而應用系統效益的體現，則在于該系統被實際應用以及對應用者提出的新需求的充分滿足。要達到這一理想境界，準確有效的應用反饋機制和快速高質量的持續改進機制至關重要。沒有這些機制，系統便成為一件死板的產品，無法根據實際需求發展和改進；而這些機制的缺失或不健全，將導致系統在日常運行中面對不斷出現的新需求反應遲鈍，甚至束手無策。

　　此外，應用系統效益的展現需要承載平臺，而其具體服務的業務領域，既是其具體的業務導向，也是其效益體現的具體的展示窗口和平臺。

　　最后，應用系統是生長起來的，而不是構建起來的。其生長過程，就是新的需求不斷被滿足和舊有缺陷不斷被更正的過程，而其生命力的旺盛與否，則體現于對新增需求滿足、已有缺陷改正的時效和質量。

　　有意思的是，所有這一切，都不是軟件工程能夠解決的。所以說，目前的信息化理論和方法，只能解釋和解決現實信息化建設中遇到問題的很少一部分。大部分問題并無現成的明確答案。而這些問題的有效解決，不僅需要所有有關人員的積極探索和勇于實踐，更需要無情解剖自己和正視、改正錯誤的勇氣，坦蕩包容的胸懷，以及寬松、平等而科學的研討氛圍。

　　本文是在研讀胡小明教授的若干文章和談話后受到啟發而形成的，在此遙向胡教授表示敬意。

　　作者沈文海 系國家氣象信息中心正研級高級工程師、第三屆北大CIO班學員