BUSINESS BOOKS

13.2　系統開發概貌

新信息系統是組織問題求解過程的一個產出。新的信息系統的建立是一個公司意識到要面對的某種問題或問題集合的解答。這個問題可能是經理和僱員認為組織表現得不像他們想象得那麼好的問題，問題也可能來自組織想要抓住更好的優勢和機會。

對應一個組織的問題或機會，產生一個信息系統解的活動，叫做系統開發 （systems development）。系統開發是具有清楚活動的結構化型的問題解。這些活動包括系統分析、系統設計、編程、測試、切換及運行與維護等。

圖13-4表示了系統開發的過程。這裡描述的系統開發活動通常按順序進行。但某些活動可能重複或同時進行，這取決於所使用的系統建設方法。

圖13-4　系統開發過程

13.2.1　系統分析

系統分析是對組織試圖要用信息系統解決的問題進行分析。它由問題的定義、原因、解答、識別滿足系統解的信息需求等內容組成。

系統分析員對現在的組織創建一個路徑圖，識別主要的數據所有者和用戶，以及現存的硬件和軟件。然後系統分析員細化現在系統的問題。用的方法是考察文件、工作紙張和步序；觀察系統運行；訪談系統的主要用戶，系統分析員就可識別問題領域和解答要達到的目標。通常這個解答要求建立一個新的信息系統或改進現有的系統。

系統分析應包括一個可行性研究 （feasible study），通過財務、技術和組織觀點分析，確定解答是否可行，或者目標能否達到。可行性研究應確定所建議的系統是不是一個好的投資，系統所需的技術的可用性，並可以被公司的信息系統專家所掌握，以及組織是否能控制系統所引入的變革。

通常系統分析過程識別組織尋求解答的幾個方案。然後評價每一個方案的可行性。書面的系統建議報告描述了成本和收益以及每個方案的優缺點，並上交給管理層確定怎樣的成本、收益、技術特性和組織影響組合能代表最需要的方案。

建立信息需求

或許系統分析中最具挑戰性的任務，是定義滿足所選系統解決方案的特殊信息需求。在基本層面，一個新系統的信息需求包括誰需要什麼信息，何時、何處需要信息以及如何需要信息。（即who，what，when，where，how）。需求分析謹慎地定義新系統或修改後的系統目標，並詳細描述開發的新系統應執行的功能。有缺陷的需求分析是系統失敗和開發成本高的主要原因。圍繞著一組錯誤的需求設計的系統或者必須要放棄，或者要承受重大修改。第13.3節我們講述獲取需求的各種方法以幫助減少這類問題。

有些問題並不要求用一個信息系統來解決，可以通過管理的調整、附加的培訓或完善現有的組織辦事步序來解決。如果這個問題和信息相關，系統分析員可能被要求去判斷這個問題，並得到正確的解答。

13.2.2　系統設計

系統分析描述為了滿足信息需求應該開發什麼樣的系統。系統設計 （systems design）用於指示如何開發該系統，以實現這個目標。信息系統的設計是對系統的總體計劃或模型。系統設計就像一個建築或一幢房子的藍圖，它包括給出這個系統形式和結構的所有說明。

系統設計員細化系統說明，給出系統分析識別的功能說明。這些說明應當闡述系統解決方案的所有管理、組織和技術成分。表13-1列出了系統設計產生的說明類型。

表13-1　設計說明類型

就像房子和建築的設計一樣，信息系統可能有許多設計。每個設計表達某個唯一的技術和組織部件的組合。決定設計好壞的標準是易用和效率，是它在一定的技術、組織、財務和時間約束下實現用戶需求的績效。

終端用戶的作用

用戶信息需求決定著整個系統建設。在設計的過程中系統需要對用戶有足夠的控制，以保證系統反映他們的優先業務和信息需求，不至於偏信於信息技術人員。使用戶參與設計，可增加用戶對系統的瞭解和接受。如第15章所述，用戶介入設計不足是系統失敗的主要原因。然而，有些系統比其他系統要求更多的用戶參與設計，第13.3節展示了各種系統開發方法下，如何強調用戶的參與問題。

組織互動專欄展示了用戶在參與設計和開發成功的解決方案中的重要性。一家帽子和手袋製造商Dorfman Pacific，不能有效地擴展它的企業，因為它被過時的倉儲系統和繁重的手工作業所牽制。該企業決定實現一個無線控制的倉儲，以改變其工作方式。

13.2.3　完成系統開發過程

系統開發過程剩下的過程是要將基於系統分析的特殊的解決方案轉化為企業的運營信息系統。這些後續步驟由編程、測試、切換、運行和維護組成。

1.編程

在編程 （programming）階段，設計階段準備的系統說明被轉換成為軟件碼。今天，許多組織不再自己對新系統編程，而是代之以從外源購買符合新系統要求的軟件，這些軟件包來自一個外部商業軟件供應商，軟件服務來自應用服務供應商，或外源化公司，它們為顧客開發顧客應用軟件。

2.測試

無遺漏的、徹底的測試 （testing）必須導入，以確定系統是否產生了正確的結果。測試回答的問題是“系統是否產生了在已知條件下要求的結果”。

回答此問題所需的時間在系統項目計劃中常被低估。測試是費時的；測試數據必須小心準備，結果要進行評估，系統要做出校正。在某些情況下系統的一部分可能必須重新設計，虛化這個步驟造成的風險是巨大的。

測試一個系統的活動可分為3種：單元測試、系統測試和接受測試。單元測試 （unit testing）或程序測試，分別測試系統中的每一個程序。廣泛的認為這個測試的目的是保證程序沒有錯誤，但是這個目的實際上是不可能達到的。測試應被看成是找到程序錯誤的方法，集中於發現導致程序失敗的所有情況。一旦找到原因，問題就能得到解決。

系統測試 （system testing）從整體上測試信息系統的功能。它試著確定離散的模塊是否可以將功能整合到一起，像計劃的那樣，並確定系統實際的工作方式是否與設想的方式間存在矛盾。在此領域檢測的是執行時間、文件儲存和峰荷處理能力、恢復和重啟動能力以及手工作業步序。

接受測試 （acceptance testing）提供最終的認證，認證該系統已準備好用於生產環境。系統測試由用戶評價、管理層審閱。當所有部分均達到滿意時，新系統就達到它的標準，系統將被正式接受並進行安裝。

系統開發隊伍和用戶一起工作，提出系統測試計劃。系統測試計劃包括我們所說的一系列測試的所有準備。

圖13-5顯示了一個測試計劃的例子。被測試的通常情況是一個記錄變化。文件由一系列測試屏幕組成，在一個數據庫上維護，這是這種應用的理想狀態。

圖　13-5

切換（conversion）是一個由舊系統到新系統變化的過程。可以使用的轉換策略有四種：並行策略、直接切換策略、嚮導研究策略和分段進入策略。

在並行策略中，老系統和它潛在的替代系統同時運行一段時間，直至每個人均確信新系統每個功能均正確無誤為止。這是最安全的切換過程，因為，在錯誤和處理中斷的情況下，老系統作為一個後備系統仍然可用。然而，這個方法十分昂貴，為運行額外的系統可能要求額外的人員和資源。

在直接切換策略中，一個指定的日期新系統完全代替了老系統。這是個很冒險的計劃。如果新系統發現嚴重的問題，可能會造成更大的損失。這時已無其他系統提供挽回措施。不到位、中斷和糾正的費用可能很大。

在嚮導研究策略中，引入新系統僅限於組織中一個有限的區域，如一個部門或運營單位。當這個導航模塊完成並運行順利時，再將系統普及到組織其他部門，或同時普及或按階段普及。

在分段導入策略中，新系統分階段，按職能、或按組織單位引入。以系統按功能引入為例，一個新的工資系統，先引入每週發工資的計時工人工資，6個月以後將領薪職工（按月發工資）加入到系統。若系統是按組織單位引入，公司總部可能先切換，4個月後下屬單位跟上。

由老系統移向一個新系統，要培訓終端用戶使用新系統。當切換時，應當完成系統如何工作的詳細說明，該文件包括技術觀點和終端用戶觀點，能用於培訓和日常運行。缺少培訓和文件編制會導致系統失敗，系統開發的這一部分過程也是很重要的。

3.運行和維護

當新系統已經安裝和完成切換後，該系統可以說是投入生產。在此階段，系統將由用戶和技術專家雙方評估，以確定它是否符合其原本的目標，並決定是否要安排修改或修正。在某些情況下，要準備一個審計文件。在系統調整、投入運行後，系統必須得到維護，校正錯誤，滿足需求，改進過程效率。對運行系統改變硬件、軟件、文件或作業步序，從而校正錯誤、滿足新需求或改進過程效率，這被稱為維護。

維護的研究已考察出各種維護任務所佔用的時間（Lientz and Swanson，1980）。大約20%的時間用於調試或校正緊急運行問題，還有20%關心數據、文件、報告、硬件或系統軟件的變更。60%的維護工作由用戶負責，他們改進文件，記錄系統部分組成，以達更高的處理效率。通過更好的系統分析和設計實踐，上述第三種維護工作的數量可以顯著減少。表13-2總結了系統開發活動。

表13-2　系統開發活動

13.2.4　建模和設計系統：結構化和麵相對象方法

建模和設計系統有多種方法，其中結構化和麵向對象方法是最流行的。

1.結構化方法

結構化方法源於20世紀70年代，用於文件化、分析、設計信息系統。結構係指一步一步地開展系統工作，每一步都是構築在上一步完成的基礎上。結構化方法是自上向下的方法，從最高層、最抽象層向具體的、最低層擴展，即由一般到個體。

結構化開發方法是面向過程的，首先關注於過程建模，或者捕捉、存儲、加工、分發數據，作為一個流經系統的數據流的活動。這個方法將數據和過程分開。每個人每次要想對一段數據採取行動，均需一個獨立的編程步序。當程序通過後，該步序可以作用於數據上。

描述系統部件及流經系統部件數據的主要工具是數據流程圖 （data flow diagram，DFD）。數據流程圖提供一個信息流的邏輯圖解模型，它將系統分解為足夠細的管理水平模塊。它嚴格地指出每一個模塊內，和存在於它們之間接口的過程處理或轉換。

圖13-6給出了一個簡單的數據流程圖，用於郵件預約的大學課程註冊系統。圓角矩形表示過程處理，它實施數據的轉換。直角矩形表示一個外部實體，它位於被建模的系統之外，是信息發出者或接受者。開口的虛線矩形表示數據存儲。箭頭線表示數據流，它顯示了數據在過程、外部實體和數據存儲間的流動。它們總是含有數據包，箭頭旁邊注有每一數據流的名字或內容。

圖13-6　大學課程郵件註冊系統

這個流程圖顯示了學生呈交申請登記表，並填寫了學生的名字、學號和他們想要學的課程號碼。在處理模塊1.0中，系統用大學的課程文件驗證是否所選的每一門課仍處於開放狀態。這個文件區分開放的課程，並取消或選滿的課程。然後處理模塊1.0確定學生所選的課程哪個被接受、哪個被拒絕。處理模塊2.0將學生登入被接受的課程。它用學生的姓名和學號更新大學的課程文件並計算班級的人數。如果最大的登入已經達到，該課程就會被標識關閉。處理模塊2.0也以新學生或更改地址信息更新學生主文件。然後，處理模塊3.0給學生候選人一個選課確認信，列出他所選的被接受的課程和通知不能實現的課程。

這種圖即可用於描述高層處理，也可用於描述低層細節。通過分層數據流程圖，一個複雜的問題可以向下分解成一系列不斷細化的層次圖。任何完全的系統可通過高層數據流程圖將其分解為子系統。一個子系統可通過第二層數據流程圖將其分解為附加子系統，較低層的子系統仍可以再細分，直至達到最細最低的層次。

結構化分析的另一個工具是數據字典。它包括一個系統中數據或數據組的個別片斷數據的信息。數據字典定義數據流和數據存儲的內容，因而，系統建造者能準確地瞭解它們包含哪些數據片斷。處理說明描述發生於數據流程圖最低層的轉換。它們描述每一個處理的邏輯。

在結構化方法中，軟件設計利用層次結構圖表實現模型化。結構圖表是一個自頂向下的圖表，顯示設計的每一層，它和其他層的關係，它在總體設計中的位置。該設計首先考慮一個程序或系統的主要功能，然後將該功能分解為子功能，再分解子功能直至達到最細最低的層次。圖13-7顯示了一個工資系統的高層結構圖表。如果一個設計有很多層要填入結構圖表，它可以進一步分解成更細的結構圖表。一個結構圖表可以文件化為一個程序、一個系統（即一個程序的集合），或一個程序的一部分。

圖13-7　一個工資系統的高層結構圖表

2.面向對象開發

結構化方法對模型化處理是很有用的，但處理模型化數據的效果並不好。它們把數據和處理認為是邏輯上分開的實體，而在現實世界中這種分開似乎不太自然。不同的模型化規則被用於分析（數據流程圖）和設計（結構圖表）。

面向對象開發 （object-oriented development）方法試圖解決這些問題，面向對象開發把對象作為系統分析和設計的基本單位。一個對象把數據和作用於這些數據上的特殊處理結合在一起。囊括於一個對象中的數據，僅能被聯繫於該對象的操作或方法所存取和修改。不是將數據傳輸到作業程序，程序將發送一個消息給對象去執行一個已包含於其中的操作。該系統模型化像一個對象和它們的關係的集合。由於處理邏輯存於對象中，而不是分開的軟件程序，對象彼此必須進行合作才能使系統工作。

面向對象模型化是基於類和遺傳的概念。對象屬於一定的類，或具有相似對象的總體範疇，具有該類的共同特性。對象類可以依次遺傳所有較上層類的結構和行為，並加上一些獨特的變量和行為至每一個對象。新對象類的創建用的方法是選一個現存類，說明新對象類如何不同於現存類，而不是每次由草圖開始。

圖13-8　類和遺傳

我們可由圖13-8看出類和遺傳如何工作，它顯示了僱員類之間的關係，以及如何對他們支付薪資。僱員是其他三類的源，或頂層類。薪金制、小時制、臨時製為僱員的三個子類。類名在圖塊的頂部，屬性在中間，操作在每塊的底層。被所有僱員共享的特性（僱員工號、姓名、地址、僱用日期、職位和工資）存於僱員頂層類。而每一子類存本類特殊的特性。例如，小時制僱員應存小時工資率和加班工資率。由子類到頂類的一根實線是一個通用化路徑，指出薪金制、小時制和臨時制等子類有共同的特性，可以歸納至頂類。

面向對象的系統開發與常規的系統開發相似，由系統分析、設計和實施組成。然而，面向對象的開發較之傳統的結構化開發更具交互性和增量性。在系統分析階段，系統建造者使系統的功能需求文件化，指出它的最重要的性質和建議系統應做什麼。對系統和用戶的交互進行分析以識別對象，對象包括數據和處理。面向對象的設計階段描述對象將如何行動和它們如何交互。相似的對象被分在一起形成一個類，多個類劃分成組形成層次，子類由頂類接受遺傳屬性和方法。

信息系統實施將設計轉換為程序碼，重新使用可重用軟件庫中已有的類，並加入新的在面向對象設計階段創建的類。實施可能還涉及一個面向對象的數據庫的設計。最後開發的系統必須經過測試和評價。

由於對象是可重複使用的，面向對象的開發能潛在地減少編程的時間和成本，因為組織可以應用其他系統已建造的模塊。新系統可以用一些現存系統的對象改變它們，並加入少量新的對象即可。面向對象的框架一旦開發出來，就可用以提供可重複使用的、半完成的應用系統，組織可對它們進一步顧客化成為成品應用系統。

3.計算輔助軟件工程

計算機輔助軟件工程 （computer-aided software engineering，CASE），有時也叫計算機輔助系統工程，提供軟件工具使我們已描述的方法自動化，以減少開發所必須做的重複的工作量。CASE工具也使創建清楚的文件和協調團隊開發的努力更加容易。團隊成員可以相互存取文件評閱和修改已做的工作，更快地共享他們的工作。如果工具應用得當，生產率適度的提高是能達到的。許多CASE工具是基於PC的，具有很強的圖形能力。

CASE工具提供了自動化圖形設備，支持生成圖表和圖形、屏幕和報告產生器、數據字典、擴展報告設備、分析和校驗工具、文件生成器。一般而言，CASE工具試圖通過採用以下方式來增加生產率和質量：

·加強標準開發方法和設計規則。

·改善用戶和技術專家之間的溝通。

·組織和協調設計部門，利用設計存儲提供快速存取。

·自動化地分析與設計那些乏味和易生錯誤的部分。

·自動化代碼的產生和測試與控制的展示。

許多CASE工具根據它們支持的是系統開發過程的前端活動還是後端活動進行分類。前端CASE工具集中於系統開發的早期的捕捉分析和設計信息，而後端CASE工具強調編程、測試和維護活動。後端的工具將說明自動地轉換成程序碼。

CASE工具自動地將數據與使用它們的處理相聯繫。如果一個數據流程圖從一個處理到另一個處理髮生了變化，在數據字典中的元素將也要自動改變，以反映圖中的變化。CASE工具還包括驗證設計圖和說明的性能。CASE工具支持交互設計，提供自動修改和變化以及提供原型化設備。一個CASE信息倉庫儲存分析員在項目中定義的所有信息。這個倉庫包括數據流程圖、結構圖表、實體關係圖、UML圖、數據定義、處理說明、屏幕和報告格式、註解和註釋、測試結果。

為了有效的使用，CASE工具需要組織訓練、管理支持和一種重視這種工具價值的組織文化。每一個開發項目的成員必須堅持一組共同的命名管理和標準及開發方法。最好的CASE工具可以加強共同的方法和標準，當組織缺乏訓練時，這將阻礙它們的應用。