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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么面向?qū)ο蠓缎捅冉Y(jié)構(gòu)化范型要優(yōu)越呢？面向數(shù)據(jù)和面向行為的方法的基本缺點在于數(shù)據(jù)和行為是同一個硬幣的兩面，數(shù)據(jù)項不能改變，除非對它進行操作，而沒有相關(guān)的數(shù)據(jù)的行為同樣毫無意義。所以，需要一種技術(shù)來同等對待數(shù)據(jù)和行為。面向?qū)ο蟮募夹g(shù)能夠做到這一點毫不奇怪，畢竟一個對象是由數(shù)據(jù)和行為組成的。面向?qū)ο蠓缎腿菀捉ㄔ煨畔⑿詢?nèi)聚的模塊，結(jié)構(gòu)化范型可以建造功能型內(nèi)聚模塊，而信息性內(nèi)聚的模塊比功能性內(nèi)聚的模塊更容易復用，因為具有功能性內(nèi)聚的模塊不是自包含和獨立的，相反，它必須對數(shù)據(jù)進行操作，如果復用這樣的模塊，那么它所操作的模塊也必須被復用，如果新產(chǎn)品中的數(shù)據(jù)與原產(chǎn)品中的數(shù)據(jù)不同，那么要么修改數(shù)據(jù)，要么修改具有功能性內(nèi)聚的模塊，因此功能性內(nèi)聚的模塊不適于復用；面向?qū)ο蠓缎鸵哺菀捉ㄔ斓婉詈系哪K。原因是面向?qū)ο蠓缎涂梢院苋菀椎膶崿F(xiàn)對對象的信息隱藏。

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

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

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

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

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

參考文獻：

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

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