適應需求變化的信息系統(tǒng)開發(fā)策略研究

[摘要] 本文從軟件需求方和軟件供應商二者的角度出發(fā)，利用管理手段、需求獲取技術、設計模式、B/S和C/S等技術提出一系列的對策，來解決企業(yè)自身發(fā)展引起的需求變化、隱性需求未被充分發(fā)掘和錯誤的需求分析、軟件設計的靈活性等問題；從成本和效益的角度，利用財務中的ROI（投資報酬率）指標分析信息系統(tǒng)的效益，利用功能點方法結合COCOMO（構造性成本模型）分析信息系統(tǒng)構造成本，對需求變化和信息系統(tǒng)變更做出平衡性分析。

[關鍵詞] 需求變化 信息系統(tǒng) 策略

一、適應需求變化的信息系統(tǒng)之軟件需求商開發(fā)策略

在需求變化的多個因素之中，軟件需求方可以作用的因素有企業(yè)自身發(fā)展引起的需求變化、隱性需求未被充分發(fā)掘或者錯誤的需求分析，作為信息產品的需求方，在開發(fā)信息系統(tǒng)中最重要的作用是積極和軟件供應商配合，而兩者配合最緊密的時期是需求獲取和需求分析時期。因此，對軟件需求方來說，最重要的責任是對自己的需求有一個清晰的認識，畢竟要做什么樣的產品只有需求方最清楚。

企業(yè)方建立一個熟悉精通企業(yè)業(yè)務的部門是非常有必要的，這個部門定位為軟件供應方和需求方之間的一道橋梁，一個接口。這個部門首先必須非常熟悉企業(yè)業(yè)務，特別是將要被信息化的業(yè)務，對業(yè)務中存在的一些問題進行一些發(fā)掘，在發(fā)掘的過程中尋找隱性需求以及解決方法。其次，這個部門在平時的工作之中需要和各個即將被信息化的業(yè)務部門充分接觸，把這些部門對信息系統(tǒng)未來的發(fā)展遠景反映在需求規(guī)格說明文檔上。最后，還需要具備一定的計算機知識，因為現在企業(yè)一般都已經有了或大或小的信息系統(tǒng)，實施信息系統(tǒng)常常是建立在這些已有的信息平臺的基礎上。這些以前實施信息系統(tǒng)留下的信息資源，對軟件供應商來說很是頭疼：它們對現在實施的信息系統(tǒng)有影響，軟件供應商了解它們又很困難。如果有個部門對這些已經實施的信息系統(tǒng)非常了解，將對軟件供應商了解需求、加深理解企業(yè)業(yè)務發(fā)揮重要作用。

二、適應需求變化的信息系統(tǒng)之軟件供應商策略

1.系統(tǒng)地看待信息系統(tǒng)

信息系統(tǒng)必須在一個組織的環(huán)境中運行，開發(fā)人員需要對項目有一個全盤的考慮，認清項目在整個的組織環(huán)境中位置，以整體的視角來看待信息系統(tǒng)和系統(tǒng)所處的組織環(huán)境。例如，在開發(fā)某個信息系統(tǒng)時，考慮運行該信息系統(tǒng)的組織在幾年之后的生產量，以此推測數據存儲容量，依靠這些推測設計數據庫的規(guī)模；從整體的角度理解軟件產品，認識此軟件產品在整個組織中的位置，考慮軟件將來可能需要與哪些其他的系統(tǒng)對接從而預留一些接口；與客戶交談時多關注企業(yè)未來的發(fā)展方向，將企業(yè)未來發(fā)展的想法融入信息系統(tǒng)，以上這些做法都會明顯的增強系統(tǒng)適應需求變化的能力。

2.利用原型、場景等工具增加需求分析的準確度

使用原型的想法是要給人們一些真實的東西，或者至少表面看上去真實的東西。原型是一種模擬，將產品的原型展示給用戶看，并詢問他們使用該產品是否能完成他們的工作。按照創(chuàng)造原型的工具，可以把原型分為“低保真原型”和“高保真原型”兩大類：低保真原型使用用戶熟悉的介質，有助于用戶將注意力集中在主題相關的事情上。諸如筆和紙、白板、活動掛圖等東西都可以用來創(chuàng)建有效的低保真原型；高保真原型是通過軟件工具來創(chuàng)建的，高保真原型的用意是看起來像最終的產品，其意圖是讓用戶有機會用一些東西，這些東西可能成為最終的產品。高保真原型比低保真原型更加細節(jié)化，它讓用戶有更多的機會來探索用例的所有可能性。

場景建模是長期在劇院、戲院和電影中運用的一種技巧。一個場景模型包括了一些場景或者情節(jié)，講述了特寫情況下的一個詳細故事，模型用于計劃隨著每個情節(jié)的推移，故事如何展開。展示場景模型的方式主要有基于文本的場景模型、故事板和對象生命歷史。基于文本的場景模型就是簡單的使用文字來實現這種原型。使用文字的好處是每個人都熟悉，在給予一點幫助的情況下，常常可以讓用戶自己創(chuàng)造他們的某些場景。故事板不如基于文字的場景正式，但是更為有趣。當試圖探索設計真人交互的業(yè)務情況時，故事板是很好的起點。另一種有助于發(fā)現遺漏需求的場景模型是對象或者實體生命歷史模型。其想法是考慮一個關鍵業(yè)務對象，用狀態(tài)轉換圖來對它的生命歷史中所有可能發(fā)生的事情進行建模。當完成了該對象的生命歷史時，考慮是否有足夠的需求來描述對象身上發(fā)生的所有事情。

3.利用系統(tǒng)設計技術來提高信息系統(tǒng)的柔性

如果一個模塊執(zhí)行多個完全不相關的行為，則其具有偶然性內聚。這是由嚴格強制的規(guī)則造成的結果。當一個模塊進行一系列相關的操作，每個操作由調用模塊來選擇時，該模塊就具有邏輯性內聚。當模塊執(zhí)行一系列與時間有關的操作時，該模塊具有時間性內聚。如果一個模塊執(zhí)行一系列與產品要遵循的步驟順序有關的操作，則該模塊具有過程性內聚。如果一個模塊執(zhí)行一系列與產品要遵循的步驟順序有關的操作，而且所有操作都在相同的數據上進行，則該模塊具有通信性內聚。因為模塊中的各操作是緊密相連的，所以通信性內聚比過程性內聚更好，但是它與偶然性、邏輯性、時間性和過程性內聚一樣有相同的缺點，也就是不能復用該模塊。只執(zhí)行一個操作或只達到一個單一目標的模塊具有功能性內聚。通常可復用具有功能性內聚的模塊，因為它完成的操作通常在其他產品上也需要。功能性內聚在擴充產品功能時也很有價值。如果模塊進行許多操作，每個都有各自的入口點，每個操作的代碼相對獨立，而且所有操作都在相同的數據結構上完成，則該模塊具有信息性內聚。

內聚是模塊內部的交互程度，而“耦合”是兩個模塊之間的交互程度。同內聚一樣，耦合可以分為幾個級別，如表1所示，可將耦合分為5個級別，分別是內容耦合、公用耦合、控制耦合、印記耦合和數據耦合。

如果兩個模塊中的一個直接引用了另一個模塊的內容，則它們之間是內容耦合的，假設模塊p和模塊q之間是內容耦合，則危險之一是幾乎對q的任何修改，也要求對p進行修改。進一步說，在一個新產品中，如果不復用模塊q，則不可能復用p，兩個模塊內容藕合時，它們不可避免地相互連接在一起。如果兩個模塊都可存取相同的全局數據，則它們之間是共用耦合。模塊cca和ccb可以存取和修改“global variable”，模塊的值，而不是通過傳遞參數互相通信，最常見的情況是cca和ccb都存取相同的數據庫，并能夠讀取和寫入相同的記錄，對共用耦合，兩個模塊必須能夠和寫入數據庫，如果數據庫存取狀態(tài)是只讀的，那么這就不是共用耦合。這種形式的耦合是不理想的，這有多個原因：第一，它與結構化編程相矛盾，因為生成的代碼完全不可讀；第二個問題是模塊可能會產生負面的效果，從而影響它們的可讀性，必須閱讀整個模塊才能準確的知道它在干什么；第三，如果在一個模塊中對一個全局變量的聲明進行了維護性修改，那么必須修改能夠訪問該全局變量的每一個模塊。進一步說，所有的修改必須是一致的；第四個問題是共用耦合的模塊難于復用，因為每次復用該模塊時必須提供使用同一個全局變量的清單；第五個問題是作為共用藕合的結構，模塊會暴露出比需要的更多的數據，這使得試圖控制數據存取的努力付諸東流?？刂岂詈系囊粋€主要難點是兩個模塊是非獨立的，被調用的模塊需要知道模塊的內部結構和邏輯，因此降低了復用的可能性。

為什么面向對象范型比結構化范型要優(yōu)越呢？面向數據和面向行為的方法的基本缺點在于數據和行為是同一個硬幣的兩面，數據項不能改變，除非對它進行操作，而沒有相關的數據的行為同樣毫無意義。所以，需要一種技術來同等對待數據和行為。面向對象的技術能夠做到這一點毫不奇怪，畢竟一個對象是由數據和行為組成的。面向對象范型容易建造信息性內聚的模塊，結構化范型可以建造功能型內聚模塊，而信息性內聚的模塊比功能性內聚的模塊更容易復用，因為具有功能性內聚的模塊不是自包含和獨立的，相反，它必須對數據進行操作，如果復用這樣的模塊，那么它所操作的模塊也必須被復用，如果新產品中的數據與原產品中的數據不同，那么要么修改數據，要么修改具有功能性內聚的模塊，因此功能性內聚的模塊不適于復用；面向對象范型也更容易建造低耦合的模塊。原因是面向對象范型可以很容易的實現對對象的信息隱藏。

加強系統(tǒng)的可移植能力也可以增強信息系統(tǒng)的柔性?？梢浦残灾饕怯伤膫€因素引起的：第一，硬件的不兼容性；第二，操作系統(tǒng)的不兼容性；第三，數值計算軟件的不兼容性；第四，編譯器的不兼容性。造成這些不同的最初原因是歷史造成的。在軟件設計上對解決硬件兼容問題意義不大。將一個軟件從操作系統(tǒng)A移植到操作系統(tǒng)B上將會引起操作系統(tǒng)兼容的問題，一些操作系統(tǒng)支持虛擬內存，而另外一些操作系統(tǒng)不支持虛擬內存；不同的操作系統(tǒng)之間的GUI實現也不相同。當產品由一臺機器移植到另一個臺機器，或是使用一個不同的編譯器編譯過，執(zhí)行運算的結果都可能不同。遺憾的是，一些語言實現不包含雙精度的整數，例如標準的Pascal語言不包含雙精度整數，因此在一個編譯器—硬件—操作系統(tǒng)的配置上功能完好的產品中使用32比特來表示Pascal整數，而當它移植到整數只能以16比特來表示的計算機上時，程序可能會運行不正常。一些語言比如Java、Ada都可以解決這種問題，因為這些語言對數據類型都有詳細的規(guī)定。

三、需求變化與信息系統(tǒng)變更之間的平衡

如何衡量和決定在何時變更信息系統(tǒng)、以及如何變更，需要從兩個方面來考慮：第一，變更之后的信息系統(tǒng)帶來的效益是否大于變更信息系統(tǒng)投入的成本；第二，比較變更信息系統(tǒng)和構造一個全新的信息系統(tǒng)哪一個更加經濟。所以說，除了進行成本分析以外，還需要進行收益分析。常用的軟件產品的成本估算方法有代碼行、功能點、COCOMO（Constructive cost Model構造性成本模型）等。這里，筆者選擇進行COCOMO估算。

進行COCOMO估算需要兩個參數：第一，產品以KDSI（thousand delivered source instructions）計算的長度；第二，產品的開發(fā)模式。對開發(fā)產品固有的困難程度的測量，有三種模式：有組織的（小而簡單的）、半分離的（中等規(guī)模的）和嵌入式的（復雜的）。對每個開發(fā)模式都有其相應的額定工作量系數（例如簡單的是3.2，1.05，其計算額定工作量的公式為：額定工作量＝3.2×（KDSI）1.05人/月），最后將這個工作量額定值乘以15個“軟件開發(fā)工作量因子”，每個因子按照產品復雜度劃分為6個可以選擇的值，最后就可以計算出工作進度和工作量。COCOMO需要估算出KDSI就會存在和代碼行估算一樣的問題，可以先估算出整個軟件的功能點，然后利用逆向法將功能點轉化為一個等價的SLOC（1ines of code）數值，如表2，最后，利用計算出來的工作量、每個標準單位工作量的成本可以估算出軟件開發(fā)的成本。

對于信息系統(tǒng)實施之后的效益估算，可以在財務管理中找到一系列的指標比如：凈現值、投資回收期、ROI（return of investment投資報酬率）、內部收益率，筆者選取ROI 作為估算指標，原因是ROI最具有綜合性。按照杜邦財務分析體系，ROI指標可分解為銷售凈利率、資產周轉率和權益乘數三個子指標。有了這些指標，可以根據業(yè)界實施信息系統(tǒng)的情況來估計本企業(yè)實施信息系統(tǒng)的收益情況，如表3所示。通過對一系列的子指標（比如存貨周轉率、應收賬款周轉率和銷售費用等）的估算，可以測算實施信息系統(tǒng)之后企業(yè)ROI將增加多少，也可以算出利潤將增加多少。將增加的收益和實施成本進行比較就可以估算出是否值得實施信息系統(tǒng)。

參考文獻：

[1]朱順泉:管理信息系統(tǒng)原理及應用[M].北京：機械工業(yè)出版社，2006年版

[2]薛華成:管理信息系統(tǒng)[M].北京：清華大學出版社，2005年版