序論：寫作是一種深度的自我表達。它要求我們深入探索自己的思想和情感，挖掘那些隱藏在內心深處的真相，好投稿為您帶來了七篇系統開發的主要方法范文，愿它們成為您寫作過程中的靈感催化劑，助力您的創作。

篇(1)

關鍵詞：軟件工程 管理信息系統 系統開發

中圖分類號：TP311.5 文獻標識碼：A 文章編號：1672-3791（2014）10（c）-0013-01

目前人們已經意識到了軟件工程思想在管理信息系統開發中的重要性，但是其重視程度還遠遠不夠。在管理系統開發的過程中如果不將軟件工程思想運用到其中，那么開發者在對管理系統進行分析時，可能會依據信息系統管理理論構建出略顯呆板的管理信息系統框架，無法得到一個友好的用戶界面，及適合用戶使用的系統，這樣的系統在現在的開發中，是一個失敗的系統。因此在軟件開發中應當將軟件工程理念應用到管理信息系統開發中。

1 開發管理信息系統中存在的問題

通常情況下，現在的管理信息系統都具有復雜化、大型化，受傳統開發理念制約等特點，因此管理信息系統的開發面臨著許多問題。當前，管理信息系統開發主要面臨的問題有以下幾點。

1.1 模型呆板，理論化嚴重

傳統的管理信息系統開發比較注重自身，輕視了軟件工程思想的重要性，在上文中我們已經介紹了這種做法的弊端，一個無法讓客戶滿意的系統開發出來也必將是一個失敗的系統。模型的呆板，必將導致用戶界面的呆板，這樣的系統勢必不會被用戶所接受[1]。

1.2 結構化分析無法解決復雜的技術和管理問題

依據管理信息系統理論將系統開發分為三階段：第一階段為系統分析，第二階段為系統設計，第三階段為系統實施。在第一階段，管理信息系統理論通常為結構化分析，對結構的闡述通常需要通過數據流圖和數據詞典來完成，采用此種方法雖然可以使需求分析變得更加簡單，系統的邏輯性更加符合標準化。但是系統的開發周期將會變得更長，整個開發過程也會變得更加復雜，系統對環境的依賴性較強，一旦環境發生變化，軟件將有可能無法繼續使用，因此該種分析方法可能會直接造成系統開發失敗[2]。

1.3 缺少管理，造成質量評估不準

在管理信息系統開發中，沒有將管理理念合適的引入到開發之中，將會導致對軟件的質量評估出現問題。沒有合理的軟件質量度量，無法對系統進行詳細的安排，也無法對系統的可行性進行合理的評價，更無法對所需要的資金進行評估，最終將會造成對整個系統的質量評估出現誤差[3]。

1.4 閉門造車，導致開發周期過長

在軟件開發過程中還有許多軟件開發者，一意孤行，聽不進別人的意見。他們具有“英雄主義情懷”。一個人將所有的開發任務都攬到自己身上，他們在軟件開發過程中習慣一切從零開始，他們認為這樣的軟件開發過程才是正統的，不去參考相關的成功經驗，這樣勢必會使開發周期變得更長。

2 解決開發中存在的問題

造成軟件開發過程中種種問題的主要原因是開發方法和理念的不當，目前所謂的經驗化開發，主要就是利用模塊化和結構化設計思想對開發工作進行安排。一旦系統的需求發生變化時，系統的開發人員通常先對當前系統進行調試，依據調試結果進行修改，這樣系統出現問題的概率就會有所提高[4]。一般情況下，由于用戶無法對自己的清楚進行描述，或隨著時間的推移用戶可能對系統的需求發生變化，因此系統開發者就需要不斷的依據用戶的需求，對系統進行調整，采用這的形式進行系統開發，將要付出嚴重的代價，是十分不可取的。因此，要想合理的解決管理信息系統開發中存在的種種問題，就必須將管理信息系統當作一種“商品”，通過合理的軟件工程方法提高“商品”的質量，因此在管理信息系統開發中將軟件工程理念的運用引進迫在眉睫[5]。

2.1 將軟件工程方法引入到管理信息系統開發中

開發管理信息系統是一項復雜的工程，因此要取得成功就必須要將軟件工程理論貫徹到管理信息系統開發之中。嚴謹、科學、規范是成功開發管理信息系統的前提。所以在開發中，應當在合適的時候對軟件工程的方法加以應用，這樣在兩種理論的指導下，管理信息系統的適用性將會得到進一步的提高。

2.2 面向對象分析法的應用

面向對象分析法在軟件開發中得到了廣泛的應用，并且已經處于了一個相對成熟的階段，因此在管理信息系統開發中完全可以大膽的對其進行使用，使面向對象技術能夠在管理信息系統開發中發揮其作用。例如，將對象概念進行引入，對實體進行描述，結合類圖、數據傳遞圖等分析非結構信息，從而建立合理的非結構模型。如果情況需要，我們也可以將形式化方法引入到系統開發之中，用嚴謹的語言對客戶的需求進行定義。這樣系統開發人員可以依據語言和圖，對用戶的需求進行詳細、合理的分析，最終開發出讓用戶滿意的系統。

2.3 加強項目管理工作

項目管理在軟件開發中有著中重要作用，它在軟件工程中的主要任務是：制定計劃、分配任務；依據進度進行風險管理、成本管理、質量管理，最終實現對軟件的成功開發。軟件開發能否取得成功，很大程度上受軟件工程管理的影響。軟件工程現階段在項目管理上已經形成了一套健全的理論。在管理信息系統開發中，可以利用軟件工程理論對管理信息系統的開發進行評估和管理，合理的評估和管理將會提高管理信息系統成功的概率[6]。

2.4 對原有軟件原型進行利用

軟件開發者可以利用軟件原型提高客戶對軟件的滿意程度，原型可以是實化產品，消除軟件原型是一種行之有效的技術，可以利用這種技術提高客戶對產品的滿意程度。因需求的不確定會導致開發人員在開發過程中形成疑惑，原型的建立可以對系統開發過程中的不確定性進行糾正。原型可以使項目經理、用戶、技術項目風險承擔者對軟件的理解更加透徹。

2.5 利用構件技術避免重復開發

要想管理信息系統開發的效率和質量能夠得到保障，不僅需要有高質量的需求，同時還需要利用重復開發技術對系統開發予以支持。可將構件思想和建模思想應用到管理信息系統開發之中，構件相當于生產預制板的模子，構件實例相當于建筑上的預制板，將預定板組合在一起就構成了高樓。用構件產生構件實例，通過構件實例的組裝和控制來構造應用軟件，這也是目前比較先進的方法。

3 結語

管理信息系統的建立和使用都是一項復雜的工程，在整個過程中需要投入大量的財力、物物力、人力，要想在管理信息系統開發過程中取得成功并不是一件容易的事，因此在管理信息系統建設階段應當將軟件工程思想應用到系統開發中，改善管理信息系統開發中的缺陷，形成一套科學合理的開發體系。

參考文獻

[1] 涂海麗，陸玲.軟件工程思想在管理系統開發中的應用探討[J].電腦知識與技術，2011，10（13）：17-18.

[2] 韓生利，狄明.軟件工程思想在有線電視管理信息系統開發中的應用[J].有線電視技術，2013，12（3）：21-22.

[3] 王建良.面向對象方法在管理系統開發中的深入應用研究[J].南京航空航天大學，2012，11（11）：27-28.

[4] 王子嘵，孟慶祥.林權證管理信息系統開發中軟件工程理論的應用[J].中南林業調查規劃，2013，11（3）：31-32.

篇(2)

[關鍵詞]DMBIA信息構建信息系統開發信息構建師

一、引言

信息構建（InformationArchitecture簡稱IA），是美國建筑師沃爾曼（RichardSaulWurman）在1975年首次提出的。在將信息的收集、組織和表示與建造建筑物的相應過程進行比較之后，其認為在滿足使用者需求這一點上，構筑信息建筑物與構筑物理建筑物有異曲同工之處，都可以看成是一種服務于特定目標的建筑設計工作，由此創造性的提出了IA這樣一個概念，并在此基礎上將其應用到各個領域中。

信息構建在國外的研究已30多年，近十年的發展最為突出，從2000年開始，美國情報科學技術學會（ASIST）已經連續六年舉辦了以IA為主題的峰會，而在中國，則開始于2001年在湖北襄樊召開的新世紀情報學學科建設、發展與應用研討會。而其在中國的真正研究與推廣則可以視2001年在湖北襄樊召開的新世紀情報學學科建設、發展與應用研討會為起點。IA發展的主要推動力是信息載體及其所依托環境的不斷變化，特別是因特網的迅速普及和推廣，使得企業面臨很大的信息爆炸，信息生態環境日漸復雜、冗余，如何從復雜繁多的信息中把握提取對企業有用的信息成為企業成功的關鍵因素之一。而IA理論在某種程度上能夠解決或者說是緩解這一問題，它的出發點在于關注用戶的感受，體現以人為本的宗旨，努力改善信息瀏覽、信息檢索和數據交換等各方面的信息處理和展示，以用戶可理解為最終目標，構建信息。

信息構建的發展近年來越發迅速，在某些領域中也有重大突破，但歸納而言其主要的應用領域較多體現在網站設計、網絡信息管理等方面，在其他領域的涉及相對而言比較的少。而本文借此欲創造性地嘗試把信息構建的理論應用到信息系統開發中去，分析傳統信息系統開發的不足，換角度思考信息系統開發，并提出相對更為有效合理的基于IA的信息系統開發方法。并希望為以后信息構建理論在其他領域的應用作鋪墊。

二、信息構建與信息系統開發

信息系統開發方法通過近幾十年的發展已經到達一個成熟階段，形成了幾種比較成熟也較為常用的方法，本文稱之為傳統開發方法，如生命周期法、原型法以及面向對象法。隨著新技術的不斷出現，新的開發方法也不斷涌現，大多是基于某種軟件技術的，如基于UML技術、基于web、基于internet交互技術的等。信息系統的開發作為一項耗資大、開發周期長、技術復雜、涉及面廣的系統工程，如果沒有相應的開發方式來實現，就無法達到預先設定的目標。但在綜合這一系列信息系統開發方法之后，發現目前仍存在一系列的問題，例如MIS的重復建設，企業的各個部門往往會出現多個職能域的MIS，而各個MIS之間又普遍存在“孤島效應”，重復建設很難避免;MIS建設缺乏全局性、戰略層面的意識，造成物流、資金流、事務流、信息流在部門內、各部門間以及本單位與外部單位之間流通的不順暢；信息可理解不突出，這也是目前就突出的問題所在，即使是系統最終能夠發揮出其有效性以及可用性，而在其實施階段，使用者不得不花費較長的時間去學習以及適應這一系統，通常情況下很難完全掌握系統的操作，也就無法發揮其最大的效用，ERP在我國發展的“早死”現象就是最好的例證。

而信息構建理論關注的焦點正是如何解決這類問題，突出核心思想為“以用戶為中心，使用戶可理解”，國外一些學者已經在很多領域作了嘗試，并取得一定成果，如ElaineG.Toms的信息交互模型、Sarahbidigare的Shoppingcart模型、LouisRosenfeld的企業信息構建模型(EAIRoadmap)等。也是基于這樣的思想，本文將信息構建的方法論和思維應用到信息系統開發中去，在彌補傳統開發方式不足的同時，也希望使最終開發的信息系統具有可行性、可操作性，并保證系統的易用性和有用性。

三、基于IA的信息系統開發模型

在充分理解信息構建理論以及信息系統開發的概念、內涵、方法、現有模型或方法的基礎，建立基于信息構建的信息系統開發模型（TheDevelopmentModelBasedonInformationArchitecture，簡稱DMBIA），根據圖1可以了解其具體包括六個流程:信息概念設計信息內容組織信息結構設計信息界面設計信息系統實現信息系統評估。

1.DMBIA的基本流程

（1)信息概念設計

該階段主要是以理解信息系統開發用戶為宗旨，了解企業現狀，確定用戶需求，包括信息系統需求企業用戶的整體環境，企業優弱勢，系統目標以及系統可行性等等。現狀了解主要采用市場調查，同時與其他方式相結合的方法。整個市場調查分析的核心在于信息系統開發人員或者說是信息構建師怎樣去理解用戶信息。以網站信息系統為例，包括理解網站系統建立的短期和長期目標是什么？誰是潛在的觀眾？人們為何使用你的網站？如何按照重要性程度為每個目標排序？用戶在網站上的行為特征？競爭對手的現狀？網站的特性和標準，比如下載時間、網頁大小、版面、外觀和感覺等等？在確定所有以上問題的答案后，再次征求意見，最終得到客戶認可的網站目標。

（2)信息內容組織

該階段的主要工作是根據掌握的信息，通過合理的方法，組織信息內容，形成定義信息結構的文檔。作為模型的核心內容之一，信息內容組織的合理性直接影響后期流程的成效。其目的在于能夠合理地對現有的用戶信息進行歸類、區分，盡可能實現所有系統使用者的需求，以便后續的結構設計、定向檢索等。信息組織一直是傳統圖書館學的研究對象，其方式有很多種，常見的是分類方式以及主體方式。目前，國內外信息構建師較為關注的是沃爾曼先生提出了“LATCH組織模式”、LouisRosenfeld和PeterMorville提出的精確組織方法[8]和模糊組織方法以及孟廣均先生提出的信息組織體系。

（3)信息結構設計

該階段的主要工作是搭建用戶的整體信息結構。用戶可以利用自己的想象力和經驗，去了解信息，理解信息。但當一個信息系統沒有提供背景知識時，就必須要有一個邏輯清晰的結構，來形成背景知識以便讓觀眾循著這個結構聯想或學習，了解信息的內容，進而找到所需信息的所在地。因此關鍵點集中在尋找一種結構，一個能最簡便表達主題的、正確的、特有的組織格式，能夠使讀者忽略無關信息，最快發現感興趣的東西；一個能夠容納信息，以及決定所要顯示內容的結構。在信息結構設計時，同樣必須完全把握貫穿模型始終的核心思想即需理解用戶信息，掌握用戶需求。為保證最終的設計結構滿足系統目的，信息構建師應從不同的環境中選擇需要的信息，并將這些零碎的內容片段的各種元素設計成為一個結構完美、和諧、統一、有機的整體。

（4)信息界面設計

信息界面設計也可以認為是外觀設計、視覺設計，以用戶理解為主。信息界面設計的效果體現在能夠使那些對信息系統不熟悉的用戶通過一定的簡單了解或操作就能夠直接使用信息系統，并獲得所需的信息。信息構建與界面設計之間有非常緊密的關系，在設計潛在系統結構的早期階段，就需要界面設計人員的參與，因為潛在的信息構架必定會影響其在用戶界面水平上所做的工作。界面是一個橋梁，許多的對話和交互都是從它開始的，它也是商業目標和用戶體驗的交叉點。好的界面設計能從表達潛在目的的背景中生成一個有效的、引人注意的視覺體驗。信息界面設計主要內容體現兩個方面。一個是界面的美觀性，用戶的可接受性，另一個則是要體現足夠的系統導航性。（5)信息系統實現

該階段將軟環境的設計向硬環境的設計轉變，整個信息系統實現流程按照筆者模型的設計，主要內容包括系統軟件選擇，硬件購置，網絡布局，系統調試等幾個方面。這里主要涉及的是各種計算機網絡技術，因此信息構建師需要具備相關的專業知識，也和與其他相關人員配合進行。該階段很好地體現了信息構建是基于各個學科知識理論之上這一特點。

（6)信息系統評估

該階段是對系統實現效果的評估，主要是指與用戶需要的符合性以及與預先目標的一致性。評估的方面主要包括信息內容組織、信息結構設計和信息界面設計的合理性，以及信息系統的硬件和軟件的可靠性。在這里根據信息構建的原理，提出基于用戶的信息構建評估，即系統必須體現可用性、信息使用戶可理解。以網站設計為例，其主要涉及到內容組織評估，包括內容與用戶需求的一致性、內容登機劃分是否標準等;信息結構評估，是指內容的組合連接，也就是信息片斷是否符合用戶所需;信息導航評估，是指導航要數是否清晰，冗余是否多，標識是否明顯;信息檢索評估，是指檢索反映速度是否較快，檢索結果是否達到用戶滿意，檢索結果信息展示是否用戶可理解等；界面美觀評估，是指其信息網站界面基調是否一致、是否體現企業文化內涵等。

2.DMBIA的基本原理

在模型具體應用中，各個階段的最終目的都在于最終系統的用戶可理解，保證在企業對信息需求和利用日益擴大的今天，通過信息構建，可以更好的了解信息，掌握信息，利用信息，創造價值。因而各個階段始終體現以信息可理解為目的。信息的變化按照周曉英博士的理論，一般可以劃分為信息片斷、信息集合、信息結構、信息空間四個信息狀態，見圖2。

模型的構造遵循信息構建的原理，在綜合國內外學者對信息構建理解和使用方法的基礎上，并考慮信息系統開發的適應性，模型開發原理主要按照信息狀態變化過程的四個方面展開，即:

信息片斷的集成原理，是指信息構建過程是從信息片段的采集開始，對采集的信息，通過一定的集成準則，集合所采集的信息，簡單而言，把采集到的用戶未知的信息轉換為用戶可知的信息，主要涉及到三大方面，集成各種信息資源、綜合合理應用不同的媒介和工具、信息最佳有效集成。

信息集合有序原理，是指信息構建過程中對信息集合中信息內容的組織和信息形式的表達形成有序、邏輯、主題鮮明的信息結構體系。

信息結構展示原理，是指信息構建師為序化后的信息設計一個協調一致的、功能化的信息構架,簡單的說就是設計一個信息展示界面，一方面有效地展示信息系統構建用戶所需表達的信息，另一方面使信息系統使用戶能感知信息結構中所存在的信息，可以方便地、心情愉悅地從中獲得信息，滿足自己的信息需求和實現自己的目標。

信息空間優化原理，是指信息構建過程通過一系列手段和措施，在復雜的龐大的信息空間中幫助人們緩解信息環境造成的心理上的迷惑或行動上的困境，減輕人們認知負擔，加強人們信息感知和信息捕捉能力，促進信息接受和利用。

3.DMBIA的基本原則

在模型的實際應用中，信息構建師除了必須在理解信息構建基本原理的基礎上，同時必循遵循信息構建的一些基本原則。在信息構建其他學者所制定的原則之上，結合信息系統開發領域的自身規律，得出以下幾點模型應用的原則:

以用戶為中心原則，是指信息構建時要以用戶為中心，從用戶的理解、用戶的興趣、用戶的習慣、用戶的期望、用戶的評價方面開始設計和運作。

整體性最優原則，是指必須從整體和各組成部分的相互關系來考察事物，從整體目標和功能出發，正確處理系統各組成部分之間的相互關系和相互作用。就是把復雜問題化成若干相對簡單的子問題以方便求解。

突出設計原則，是指重視對信息結構、信息界面或信息內容的外觀和展示形式進行設計。

美觀與功能平衡原則，是指信息構建時要考慮構建結果應當具有的目的和效用，為目的服務而不是為外在的東西服務。

篇(3)

《經濟管理應用軟件案例分析》是是計算機專業本科生的選修課之一。該課程主要講述經濟應用軟件開發中，各種計算機技術的綜合應用，培養學生的綜合分析能力思維和應用開發能力，培養學生自我學習的能力，最終目標是培養學生通過本課程的學習掌握系統開發所需的關鍵技術和方法，從而為學生今后在經濟和社會的開發工作打下堅實的基礎。為專業實習、畢業實習、畢業論文奠定基礎。

二、教學模式運行背景

1.課程特點。《經濟管理應用軟件案例分析》課程是在學生完成《數據庫應用》、《數據結構》、《面向對象程序設計》等相關課程的基礎上，從軟件工程的角度出發，按照項目的開發順序，系統、全面地介紹了程序開發流程。從開發背景、需求分析、系統功能分析、數據庫分析、數據庫建模、系統開發到系統實施及維護，每一過程都作了詳細的介紹。由于信息量太大、知識點太多以及專業術語過多，學生難把握重難點，妨礙了學生自學；同時教學知識點過多，課程教學容易出現拉完情況；還有系統開發需進行全局規劃，需要具有全局意識，有一定的難度。《經濟管理應用軟件案例分析》將會以循序漸進的方式介紹ASP.NET的相關技術知識，幫助學生建立開發系統應有的正確觀念。

2.學生情況。計算機專業的部分學生前期專業課知識不夠扎實，且動手能力不是很強，而本課程知識點多了，需一定動手能力，學生易產生畏難情緒；因此如果還是采用傳統教育模式，學生也只依賴課堂學習，不采用新的教學模式，那么上面提到的問題就不會得到較好解決。

三、教學模式設計

1.教學內容改革。《經濟管理應用軟件案例分析》課程整個教學量是非常大的，需要學生掌握整個系統開發生命周期的開發方法，即從系統規劃、系統分析、系統設計、系統實施到系統維護，并且按照各階段的開發方案對系統進行開發。因此對教學內容改革首先必須仔細分析個系統開發階段的特點，對教學內容進行分解，部分內容弱化，部分內容重點講，并以典型經濟管理應用軟件案例的講授為基礎，帶動學生掌握系統開發所需的關鍵技術和方法，鍛煉學生的系統開發能力。

《經濟管理應用軟件案例分析》主要分為兩個方面：一方面是應用軟件案例的分析。主要是從軟件工程的角度出發，對系統規劃、系統分析、系統設計、系統實施到系統維護的每一階段的關鍵技術和開發方法進行介紹，對各個階段所需編寫的文檔進行講解，并以案例為基礎對開發階段所需做工作進行說明。另一方面是ASP.NET的學習。對ASP.NET相關背景進行說明，對開發環境進行介紹，如以教材訂購系統為例，講解系統登錄、注冊、用戶主界面等的制作為例，讓學生能夠按照自己所分析的文檔制作對應的系統。

2.教學方式改革《經濟管理應用軟件案例分析》課程的教學形是一門理論性、實踐性都很強的應用性課程，內容抽象。為優化教學效果， 讓學生從知識的被動接收者轉變為主動參與者和積極探索者，在發揮教師主導作用的同時，充分發揮學生的主體作用，引導學生去思考、去探索、去發現。為此教學中應結合以下教學方法合理組織教學活動，以激發學生的學習興趣，加強學生對此課程的理解。

第一，案例教學。本門課中有些知識較為抽象，對此可結合實際案例進行講解，以求通俗易懂，以典型經濟管理應用軟件案例的講授為基礎，帶動學生掌握系統開發所需的關鍵技術和方法，鍛煉學生的系統開發能力。例如，在講解完系統分析階段后，結合實際項目，給出對應的可行性分析報告。通過實例，幫助學生理解系統分析階段所需做的工作。

第二，小組實踐。由于項目的開發是個團體項目，教師應將學生進行分組，鼓勵學生進行小組學習，明確小組的項目要求，在教師指導下由他們自己制定項目開發計劃。在多媒體教學、案例閱讀與分析（項目管理、可行性分析、需求分析、系統設計、數據庫設計等）的基礎上對比開發相應系統。比如本課程的考核方式就是以小組為單位，相互交流進行項目開發及文檔的編制。學生通過實踐的方式，運用所學的知識分析問題，解決問題，最終達到熟練掌握系統開發方法的目的，也是對學生所學知識的復習和鞏固最有效的方法。

第三，討論教學。教師在教學中應該適當的轉換角色，圍繞中心問題同學生相互交流個人看法，相互啟發，相互學習。針對學生提出的難點再進行重點講解。教師不應該死板地遵照預先制定的課堂教學計劃，在教學中應該多于學生進行交互，并對學生進行適當鼓勵，提高學生學習主動性。比如學生在編制可行性分析報告時，對于可行性分析部分存在難點，可以針對不懂的地方進行講解。對于部分報告編寫認真且良好的學生給予鼓勵，并以范本的形式給其余學生瀏覽，供其余學生學習。

第四，多媒體教學。在教學過程中使用多媒體技術是有必要的，既可以使一些教學難點的講解變得生動形象，同時又可以激發學生的學習興趣，讓學生在輕松自如的環境里逐步提高理論水平和實踐能力。 例如，講解數據流圖的繪制，可以由教師邊講解邊演示制作步驟，然后在屏幕上打出練習題，讓學生學習繪制數據流圖。學生填完后將幾個學生的數據流圖再放到展示臺上，讓學生們指出他們填的對不對？問題出現在什么地方？

第五，自主學習。教師應該激勵和支持學生自主學習。教學過程中教師應該明確給出學生應該自主學習的內容范圍，由他們自己制定學習進度、方式。比如在教學過程中，教師可教授系統公共模塊的制作，再選用教材供學生自學，幫助學生建立開發系統應有的正確觀念。當遇見問題時，教師給出一些指導。

四、課程考核及評價

課程考核應采取平時成績與實踐操作相結合，以小組方式自由選題，按照系統開發流程編寫對應的可行性分析報告、需求報告、設計報告、測試報告等，根據所編寫的文檔開發系統。系統功能可概要化抽象實現，不需大而全，要求概而精。這樣對學生進行分階段測試，力求客觀地、全面地反映學生的綜合素質和能力，既符合本科教育培養目標的要求，又能真實反映學生學習能力，使考核評價伴隨學習的全過程。

篇(4)

Abstract： In this article， the definition of UML is described， the UML graphics is classified， the UML development process is put forward for object-oriented modeling of information system. As an example， the educational administration information system based on Web， the author has illustrated the UML application for object-oriented information system development.

關鍵詞： UML；面向對象；圖；信息系統

Key words： UML；object oriented；diagram；information system

中圖分類號：TP31 文獻標識碼：A 文章編號：1006-4311（2013）08-0189-02

0 引言

面向對象方法（Object-Oriented Method）是一種把面向對象的思想應用于軟件開發過程中，指導開發活動的系統方法，簡稱OO（Object-Oriented）方法。面向對象方法不僅是一種軟件工程的開發技術，而且是一種對客觀事物進行分析與處理的思想方法。

1 統一建模語言

1.1 UML的定義 統一建模語言UML（Unified Modeing Language）是一種建模語言，是第三代用來為面向對象開發系統的產品進行說明、可視化和編制文檔的方法，它用若干個視圖構造系統的模型，每個視圖描述系統的一個方面。UML吸取了面向對象技術領域中其他流派的長處，它適用于各種規模的系統開發，使用UML進行系統分析和設計，可以加速開發進程，提高代碼編寫質量，并能促進軟件復用，方便集成已有的系統。

1.2 UML的圖形 統一建模語言UML的圖形可以劃分為5類。

①用例圖（Use Case Diagram）。用例是對系統提供的功能的描述。用例圖從用戶角度描述系統功能，指出各功能的操作者，用例圖定義了系統的功能需求。②靜態圖（Static diagram）。靜態圖包括類圖、對象圖和包圖。類圖描述系統中類的靜態結構，不僅定義系統中的類，表示類之間的聯系如關聯、依賴、聚合等，而且包括類的內部結構。對象圖是類圖的實例，使用與類圖基本相同的標識，與類圖不同之處在于對象圖顯示類的多個對象實例，而不是實際的類。包由包或類組成，包圖表示包與包之間的關系，用于描述系統的分層結構。③行為圖（Behavior diagram）。行為圖包括狀態圖、活動圖、交互圖（順序圖、協作圖）。狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件，是對類圖的補充；活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系，它是一種特殊的狀態圖，強調對象間的控制流程；順序圖展現了一組對象和由這組對象收發的消息，用于按時間順序對控制流建模。④交互圖（Interactive diagram）。交互圖包括順序圖和合作圖，描述對象間的交互關系。順序圖顯示對象之間的動態合作關系，強調對象之間消息發送的順序；協作圖與順序圖相似，除描述對象間的協作關系，強調對象之間的關系。⑤實現圖（Implementation diagram）。實現圖包括構件圖和配置圖。構件圖描述代碼部件的物理結構及各部件之間的依賴關系；配置圖定義系統中軟硬件的物理體系結構，它可以顯示實際的計算機和設備以及它們之間的連接關系，也可顯示連接的類型及部件之間的依賴性。

1.3 UML在面向對象信息系統開發中的建模過程

圖1是UML建模過程的一個高層視圖，這是一個迭代遞增的開發過程，每次迭代都包含軟件生存周期的所有階段，采用這種開發方法不是在項目結束后一次性提交軟件，而是分塊逐次開發和提交，每次迭代都可以分為以下5個階段：第1階段，需求分析。需求分析是捕獲用戶要求，包括功能性需求和非功能性需求。第2階段，系統分析。系統分析是對用例圖的進一步擴展，是從邏輯概念角度表達系統的結構和功能。第3階段，系統設計。系統設計是在系統分析的基礎上將分析模型中概念性的模型轉化為與具體語言掛鉤的設計模型。第4階段，系統實施。將設計模型轉換為系統的源代碼，是信息系統最終產品的最重要部分之一，這部分工作重點在系統編程工作。第5階段，系統測試。在系統構建后，對系統的功能和結構進行確認，使用多種測試方法和手段來保證系統的正確性。

2 基于Web的教務管理信息系統開發實例

以基于Web的教務管理信息系統開發為例，說明UML在面向對象信息系統開發中的應用，重點對前3部分內容進行說明。

2.1 需求分析 基于Web的教務管理信息系統開發要根據高職院校實際情況，充分考慮教務管理工作業務流程、業務項目和業務規范，基于校園網絡、為教學管理提供科學、規范、高效、準確、便捷的高職院校教務管理平臺。通過系統調研可知，系統面向的用戶有4類：系統管理員、教務管理員、教師、學生；系統主要實現的功能有5項：系統管理、學籍管理、教學管理、考務管理、師資管理，系統用例圖如圖2所示。

2.2 系統分析 系統分析是對在需求分析的基礎上，提取系統的類，用包類、類圖、順序圖等描述它們合作的概況。

2.2.1 包圖。基于Web的教務管理信息系統劃分為人員、事務和接口3個包，分別控制不同的應用。系統分析包圖如圖3所示。

2.2.2 類圖。統一建模語言UML用類圖描述系統中的靜態結構，根據系統劃分的3類包圖，分別繪制人員、接口和事物包中的類圖，以人員包為例，類圖如圖4所示。

2.2.3 順序圖。順序圖用于描述對象間的動態關系，著重體現對象間消息傳遞的時間順序，以課程管理為例，順序圖如圖5所示。

2.3 系統設計 系統設計是通過考慮現實環境，將分析階段的模型擴展和轉化為可行的技術實現方案。

2.3.1 活動圖。活動圖既可用于描述操作（類的方法）的行為，也可用于描述用例和對象內部的工作過程，用活動圖建模后可以清楚地了解進程的操作過程，以教務員課程管理為例，活動圖如圖6所示。

2.3.2 協作圖。協作圖用于描述系統中相互協作對象間的交互關系和關聯鏈接關系，與順序圖不同之處在于，順序圖側重于表示交互的時間順序，而協作圖側重于表示交互對象的靜態鏈接關系，以教務員排課課程管理為例，協作圖如圖7所示。

2.4 系統實施和系統測試

2.4.1 系統實施。系統實施是信息系統開發的一個重要階段，其目的是把系統分析和系統設計成果轉化為可實際運行的系統，主要任務就是根據構造模型進行編碼，并對已構造的模型進行修正。

2.4.2 系統測試。系統測試是信息系統開發的最后一個階段，其目的是保證新系統運行的正確性和有效性。

3 結束語

綜上，在面向對象信息系統開發中，以UML為工具為系統進行建模，可以針對系統開發不同階段的具體任務，建立不同的模型。

參考文獻：

[1]邵維忠，楊芙清.面向對象的系統設計[M].北京：清華大學出版社，2003.

篇(5)

一、精確軟件開發過程概述

相對于精確軟件開發過程，統一軟件開發過程（RationalUnifiedProcess，RUP）中存在著諸多的不足與弊端。所謂的統一軟件開發過程（RUP）主要是指以網絡基礎、面向對象的程序開發方法論，它就好像一個在線的指導人員，能夠為全部層級、所有方面的軟件程序開發提供開發模板、方針建議以及案例支持等等。統一軟件開發過程（RUP）擁有著一個十分完整的框架結構，在該框架結構下，技術、實踐等面向過程的方面以及代碼、模型、文檔等其它開發組件均被囊括其中。但是統一軟件開發過程（RUP）的不足也是顯而易見的，筆者在深入分析研究的基礎上，以統一軟件開發過程（RUP）為基礎，給出了一種相對更加高效、更加可行的精確軟件開發過程。精確軟件開發過程的終極目標就是彌補統一軟件開發過程（RUP）的不足，通過科學、系統以及有計劃的指導，提高軟件開發的效率、可行性尤其是成功率，能夠為中小型軟件系統的開發提供必要的扶持和幫助。精確軟件開發過程的基本思想主要體現在以下幾個方面：第一，合理簡化使其更具針對性。統一軟件開發過程（RUP）的主要面向對象是那些常規性的絕大多數的軟件系統開發，因此，在針對性方面顯得不足，沒有能力可以根據實際的問題給出具有很強針對性的軟件開發設計方案。尤其是那些開發數量與日俱增的中小型軟件系統，應用統一軟件開發過程（RUP）則會使得整個開發過程顯得啰嗦、累贅和臃腫，軟件設計人員除了要進行軟件設計活動之外，還需要有效處理統一軟件開發過程（RUP）天生的不足，增加了軟件開發人員的工作壓力。而精確軟件開發過程的基本思想則采取了與統一軟件開發過程（RUP）的面面俱到截然相反的理念，即“分割簡化、細致明確”。具體而言，就是將軟件開發過程的復雜性問題進行合理劃分，分析并探討相對簡單的部分，明確這些簡單部分之后進行設計活動和實現活動。

由于精確軟件開發過程來源于眾多的中小型軟件系統的設計實踐，因此，它在有效解決實際問題不僅高效，而且極具針對性和簡化性。這些特點使得不論是軟件開發人員還是軟件工程管理人員都能夠比較容易地接受精確軟件開發過程，獲得良好的執行效果。第二，能夠實現軟件開發支持的最大化。在軟件開發的過程中，存在著諸多的不確定性因素，例如軟件設計人員對于業務理解的偏差、系統用戶對于業務的變更和微調等，統一軟件開發過程（RUP）很難進行有效地應對，而精確軟件開發過程則能夠很好地解決軟件系統在開發過程中出現的各種不確定性因素。這主要是由于精確軟件開發過程當中，軟件系統開發團隊的人員構成與統一軟件開發過程（RUP）團隊存在著較大的差異，前者不僅擁有軟件系統開發領域的專業技術人員，更有用戶業務領域的專家。因此，精確軟件開發過程的軟件系統設計團隊能夠在開發的整個過程中與用戶進行直接、沒有偏差的交流，及時發生客戶對于業務的新要求、新變化，相應地，客戶也能夠在交流過程中了解軟件系統開發的具體進程，并根據軟件系統開發團隊的要求為軟件系統開發提供最大的支持和協助。第三，優化合理的軟件系統開發過程。對于統一軟件開發過程（RUP）而言，它的過程一般包括以下幾個方面：計劃過程、需求分析過程、設計過程、編碼過程、測試過程以及運行維護過程。其中，統一軟件開發過程（RUP）的設計過程要比精確軟件開發過程（該過程的設計過程主要包括整體性設計過程和詳細設計過程）籠統得多；而統一軟件開發過程（RUP）的測試過程中主要包括兩個方面，即開發人員的測試過程和用戶的測試過程，且開發人員的測試過程密切聯系著編碼過程；同時，測試過程之后直接進入到運行過程也缺乏合理性，這兩者之間應該增加“試運行過程”，即保持“測試過程試運行過程運行過程”的順序，經過試運行過程證明系統具有良好的穩定性之后再進入到正式的運行維護過程中。有鑒于此，精確軟件開發過程對軟件系統開發過程進行了合理化與優化處理，將其劃分為以下七個方面，即需求定義過程、外部設計過程、內部設計過程、編碼測試過程、聯合測試過程、系統試運行過程、系統初運行過程。其中，“外部設計過程”和“內部設計過程”同屬于大的設計過程，“聯合測試過程”則合并了編碼和開發人員的單體測試，單獨增加了“系統試運行過程”這一個重要環節。正是由于精確軟件開發過程對軟件系統開發過程進行了合理化與優化處理，使得軟件工程管理人員能夠更加有效管理和控制軟件系統開發的進程。同時需要說明的是，精確軟件開發過程在每一個開發環節當中均有開發進度文檔，該文檔的主要作用就是用來進行階段性任務的明確、任務完成人員和完成時間的嚴格定義，借助于開發進度文檔，徹底實現了軟件系統開發進程的精確化管理和控制。第四，基本思想概述。通常以上三個方面的論述我們知道，精確軟件開發過程是建立在統一軟件開發過程（RUP）的基礎之上的，并充分融入了CMM（CapabilityMaturityModelforSoftware，能力成熟度模型）理念，是一種具有很強針對性的軟件開發過程。所以，精確軟件開發過程中對中小型的B/S系統及其類似軟件系統的開發過程具有非常好的適應性。精確軟件開發過程的基本思想可以概述為以下幾個方面：（1）過程的細化分割。精確軟件開發過程實現了對復雜問題的細化分割，將其劃分成為多個簡單的問題進行分析處理，不論是系統開發過程還是軟件工程管理均更容易；（2）軟件開發團隊當中增加了新成員——業務領域專家，他的階段性介入對于增強整個軟件系統開發團隊業務能力方面是不言而喻的，提高了發現不合理業務的及時性，并能夠給出專業化的解決方案，有效解決了軟件系統開發資源；（3）優化合理的軟件系統開發過程，包括需求定義過程、外部設計過程、內部設計過程、編碼測試過程、聯合測試過程、系統試運行過程、系統初運行過程等七個過程，更加科學合理。精確軟件開發過程要求計劃具有非常高的細致程度，例如，以周為單位進行計劃的制定，以天為單位確定開發計劃，以小時為單位明確測試計劃，等等。總體而言，精確軟件開發過程能夠為軟件開發質量和開發進度提供更可靠的保證，對于軟件工程水平較低的國內現狀而言，其積極作用還是非常顯著的。

二、基于精確軟件開發過程的X系統開發實例

某企業需要開發一套物流中心倉庫管理系統，要求對倉庫進行嚴格的控制，即對倉庫進行精確的入/出庫管理，提供在庫量的實時監控，并且為財務用戶提供準確的入/出庫數據以及相關的財務數據。需求定義。在立項初期，首先確立系統開發的對應體制，包括開發商、用戶系統課負責人、用戶業務負責人。在開發商方面，有項目經理，項目組、開發人員以及技術支持人員。項目經理主要負責項目整體進度的把握已經項目合同的相關事宜。項目組長則全面的管理項目的開發進展，對各個開發階段進行全程的跟蹤，并且對項目中的相關技術方面的問題做出決策，還包括了與用戶系統負責人進行聯絡。開發人員主要負責系統需求的獲取，系統設計以及系統實現。在用戶方面，系統負責人主要起聯絡開發商和用戶的作用，協助開發商和用戶對業務需求進行溝通。另外，還負責向系統課的領導匯報系統的開發進度情況以及開發遇到的重大課題。業務負責人主要由實際工作的操作者構成，是系統功能的提出者以及系統測試和確認的人員。外部設計。在需求定義階段，己經對系統的功能需求進行了詳細的討論與確認，系統整體上可以分為8個大的功能模塊，主要包括系統管理、Maste管理、集裝箱堆場、倉庫管理、溢出倉庫管理、工廠側管理、財務用戶部分和Housekeeping。在每個人功能模塊當中又劃分了若干了個功能畫面，分別對用戶提出的需求進行實現。內部設計。詳細描述了系統數據的數據結構，定義了各個數據表以及表中的數據字段的名稱、類型、長度、含義等相關信息。系統實現。開發系統環境：MicrosoftWindowsServer2003SP2；開發平臺：MicrosoftVisualStudio2003；開發語言:，C#，JavaScript；數據庫服務：MicrosoftSQLServer2005；數據庫客戶端：Oracle9.2。

篇(6)

關鍵詞：會計信息管理系統審計系統分析系統設計系統實施

近年來，會計電算化迅速發展。會計信息系統的開發已由單項處理向較完整的會計信息管理系統發展，由單機應用向計算機網絡的應用發展，由單純的會計核算向管理會計應用方向發展。不少地區和行業，已把會計電算化定為會計工作升級的條件之一。此外，會計軟件市場的出現，促進了會計核算軟件的商品化、通用化，有效地推動了我國會計電算化的進程。總體上，會計商品化軟件在企業中得到了廣泛的應用，并已取得了較好的效果和經濟效率。而眾多的中小企業，如浙江省溫州地區中小企業達到16.7萬家，占全部企業總數的90%以上，占整個GDP的83%.但在使用商品化會計軟件上卻不如人意（除了財政部門規定的發票管理系統以外），發展速度遠遠低于全國的水平。其原因除了人為的主觀因素外，最主要的是商品軟件雖然功能較多，但不能適應企業的具體環境（如企業的管理思想、管理方法、經營的外部環境、企業生產規模、產品類型等因素），整體應用效果不很理想。筆者認為，中小企業根據自身特點，從企業的實際出發，自我開發或委托有實力的專業軟件公司開發自己的會計信息管理系統軟件也是有效途徑之一。

本文結合筆者在溫州地區開發幾個會計信息管理系統過程中的情況，僅就系統開發過程中的審計內容和方法作一介紹。

會計信息管理系統開發周期長、技術復雜、投資較大，如果開發的系統在技術、經濟和管理上不可行，或新系統不符合系統目標，或在系統開發階段沒有建立必要的內部控制，待系統運行后再進行修改，這不僅增加成本，而且影響系統的正常運行，有時甚至無法實現。因此在系統開發前和在開發過程中，都必須嚴格遵循一定的階段和步驟，且每一階段和步驟均有明確的成果，這些成果作為下一步工作的依據，使整個開發工作有規律、有步驟的完成。系統開發審計就是對會計信息管理系統開發的整個過程進行的審計。按照系統開發的周期，系統開發分為系統分析、系統設計和系統實施三個階段，因此需分別對每一階段進行審計。

一、系統分析階段的審計

系統分析階段包括提出新系統目標、成立開發小組、可行性分析、現狀調查、需求分析和邏輯模型建立。其審計內容和方法如下：

1.與系統分析人員一起確定系統的長期目標（2～4年）和近期目標（1～2年），以確保系統目標滿足單位內外的管理對會計信息的需求，能完成所要承擔的會計工作，要符合單位財會人員的習慣，同時必須保證數據信息的可靠性并具有一定的效率；確定系統與外部環境的信息聯系和接口；確定系統的主要功能和結構；確定系統與企業其他系統（如CAD、CAM）的界面和信息聯系。

2.確保各有關部門派代表參加開發小組并確定其熟悉所屬部門的崗位責任和工作范圍；檢查項目負責人召開的重要會議，看是否均有各部門人員參加。

3.審核企業可以投入的資金、物力、人力及其來源。

4.與系統分析人員共同研究新系統在技術、經濟、管理等方面的可行性。

5.復核系統分析人員取得的現系統的信息關聯狀況、會計工作流程和會計業務流程、信息載體和信息量等全部詳細資料；審核所建立的新系統的目標能否滿足其處理和控制上的要求。

6.向會計部門查詢，確定該部門就會計處理的立場，審核有關的成本與效益的計算。

7.與系統分析人員一起分析新系統的邏輯模型（重點是數據流程圖）是否滿足會計和財務制度流程的要求，是否充分體現了用戶的需求。

8.全面檢查系統分析階段的現狀分析報告、可行性報告、會計業務作業流程圖、輸入輸出和代碼調查表、系統分析說明書等文檔是否完整、正確。

二、系統設計階段的審計

系統設計是根據系統分析中提出的邏輯模型，考慮實際的設備、技術條件、經濟條件及社會條件，確定新系統的實施方案即系統的物理模型。系統設計階段的主要活動有系統總體設計和系統詳細設計。系統總體設計包括功能模塊設計、文件與數據庫設計、計算機及網絡系統配置方案設計。系統詳細設計包括代碼設計、輸入和輸出設計、用戶界面設計和處理過程設計。其審計內容和方法如下：

1.查閱系統設計是否采用了模塊化、自頂向下逐步求精、各模塊之間聯系最少的結構化設計方法，以確保系統“波動效應”盡量小，可修改性和擴展性盡量好；以確保模塊的劃分滿足會計核算和內部管理的需要，符合會計人員的習慣；以確保系統結構控制圖符合系統的處理要求。

2.審核數據庫文件是否符合控制要求、用戶輸入數據和輸出信息要求。特別要注意文件和數據的安全保密控制和權限控制，以保證未授權人員不準接觸文件和數據。審核字段和記錄的設計，并進行一致性、準確性、合理性的綜合分析，盡量消除冗余和節約存貯空間。

3.審核計算機和網絡系統配置方案。以確保系統環境的合理配置，以較小的投資獲得較好的系統性能；硬件的配置要符合目的性、先進性、配套性、經濟性；軟件配置要選擇合理的操作系統、語言編譯系統、數據庫管理系統；網絡系統的配置要符合標準化、主流化、實用性和技術性能指標好的原則，實現數據、程序與硬件等資源的共享。

4.抽查部分代碼，看其是否符合國際、國家、行業頒發的標準代碼設計。檢查代碼在邏輯上能否滿足用戶的需要，在結構上能否與處理的方法相一致。檢查代碼是否符合惟一性、直觀性、可擴展性和合法性。確保一級會計科目的代碼應符合財政部頒發的會計制度規定的科目編碼。

5.審核系統的輸入輸出設計是否符合《會計核算軟件基本功能規范》的要求，以保證輸入和輸出數據的合法性和正確性。特別要保證輸入數據的質量和糾錯能力，竭力避免“垃圾進，垃圾出”的情況；并采取一定的控制措施，確保“正確的輸入，正確的操作，正確的輸出”的原則。檢查輸出報表的設計是否滿足對外報送和對內管理的要求。復核系統的輸入輸出設計是否包含一定的審計線索，以便能由系統的輸入順查到輸出，或者由輸出逆查到輸入。

6.審閱處理過程設計是否符合《會計核算軟件基本功能規范》的要求。以確保具有符合國家統一會計制度的規定的自動編制會計報表的功能和允許使用的多種核算方法；以確保有適當的控制措施，使所有經過審核的業務，均能完整的被處理；確保結賬功能的設計能自動檢查本期輸入的會計憑證是否全部入賬，并保證賬證、賬賬相符；以確保機內銀行存款日記賬與輸入的銀行對賬單及適當的手工輔助自動進行銀行對賬，自動生成銀行存款余額調節表。

7.審核新系統的實施方案，以確定整個系統設計的文檔（系統總體設計書、詳細設計報告、系統設計報告）是否齊全、正確。

三、系統實施階段的審計

系統實施階段是將新系統付諸實施的過程。它的主要活動是根據系統設計所提供的控制結構圖、文件與數據庫設計、系統配置方案及詳細設計資料，編制和調試程序，進行系統試運行、系統轉換等工作，將技術設計轉化為物理實際系統。其審計內容和方法如下：

1.與程序設計人員一起選擇合適的程序開發工具、合適的數據結構和合理的算法；檢查是否采用了結構化程序設計方法；查閱程序中采用何種控制措施，確定各種必須的內部控制是否都以納入所設計的程序中；檢查程序流程圖是否正確，檢查源程序的正確性、可讀性、可測試性和可維護性是否達到要求；檢查程序文檔是否完整和規范。

2.參與和監督程序的分調試和總調試。調試時需精心組織測試數據模型，即有正常的、有效的各類業務數據，又有不完整的、無效的、不合理的、不合邏輯的數據。分調試時以查明該模塊是否按預定的要求接收并處理正常的業務，并發現是否拒絕不正常的業務且按預定的要求給出錯誤的信息并給予記錄，以確保每一模塊內部控制關系的正確和數據處理內容正確；總調試時要測試各模塊接口之間的各種可能的使用形態及其組合情況，查出系統中屬于相互關系方面的錯誤和缺陷，以保證各控制信息關系的正確。

3.與有關人員一起參加系統的試運行，試運行應采用并行運行方式，試運行的期限不低于三個月。檢查試運行記錄和試運行報告，核對新舊系統處理結果，看其是否達到預定的目標，有無發現系統存在的問題；查明實際的電算化會計信息管理系統與原來設計考慮的差異是否合理，系統能否正式投入運行；審核所選的系統轉換方式是否合理。

4.審核被審單位電算化會計信息管理系統的操作管理制度，查明系統的操作員、管理員、程序員的工作職責是否明確，有無相互兼任的情況。查明未經授權批準、不掌握密碼的人能否接觸程序和數據并對其修改；實地觀察系統操作人員的操作情況，查明輸入數據是否經審批，正確的數據能否被完整準確地輸入系統，錯誤的數據能否被發現并經過適當的程序更正后重新向系統提交；查明是否制定了嚴格的硬件、軟件管理制度，制定的制度是否符合內部控制的原則并有效執行；檢查系統修改的文檔資料，查明每次修改是否按規定的程序進行，已修改過的程序是否妥善保管；實地觀察系統的運行狀態，檢查系統的運行是否正常；參與系統運行后的審核和評價。

5.詳細檢查系統實施階段的程序設計規格書、源程序清單、程序測試報告、系統測試報告、操作手冊等文檔是否完整準確。

四、結束語

會計信息管理系統開發的審計，是一種事前審計，它具有積極的意義。因此，審計人員、特別是單位內部審計人員對會計信息管理系統的開發進行審計，這對于開發活動的恰當控制，系統開發方法的科學性、先進性和合理性，系統開發過程中產生的系統資料和憑證的規范性，系統運行以后數據處理的合法性、正確性、完整性和效率性，以及事后審計的可審性，都具有很大的作用。

參考文獻：

篇(7)

[關鍵詞] 信息系統 用戶需求 功能過度 功能適度

一、引言

本文依據作者多年的信息系統開發實踐經驗，以及對此問題的研究與認識，提出信息系統開發中的“功能適度”原則，用以解決“用戶需求至上”與功能過度的矛盾。

二、用戶需求與功能過度

在許多軟件工程和信息系統開發的資料中，都在系統分析或設計時特別強調“用戶需求”。把其作為系統分析的出發點和系統設計，特別是新系統功能設計的主要依據。應該說這種觀點本身是正確的，問題在于信息系統分析與設計中對“用戶需求”概念的理解和運用。

關于“用戶需求”有兩種觀點值得我們注意，一種是理解為：由用戶提出的所有要求（如需要新系統解決的所有問題，需要新系統實現的所有功能）；另一種觀點認為：“用戶需求”是指用戶所在業務系統本身對信息化的需求，這種需求是系統的、長期的，開發人員可以通過現行系統中用戶提出的各種需求來歸納、提煉。

觀點一是由于信息化進程的特殊性而造成的。早期信息化的啟動和推進主要是由計算機的專業人員而非專業的信息系統人員，用戶方面也普遍存在對信息系統的知識缺乏。所以當把信息系統的開發通過商業合同來運作時，所謂的“用戶需求”就成為了連接開發人員和用戶的必然橋梁。信息系統開發人員要求用戶必須提出自己的需求，雖然需求可以修改、完善，但不能無度；計算機專業人員按照這種需求設計完成信息系統的開發。

這樣運作的缺點是：（1）用戶由于缺乏足夠的計算機與信息系統的知識，提出的要求可能是片面與不完整的；（2）開發人員雖然為項目的運作尋求到了必要的依據，項目完成相對容易，但完成的項目可能很難真正滿足用戶（系統）的實際需求，特別是長期的需求；（3）按照這種觀點開發出來的所謂信息系統本身就不是企業業務系統的信息化，而是將信息技術用于企業業務，完成了企業現有功能的不完整信息化。

觀點二反映了信息系統開發中“用戶需求”的本質，即這種需求不是用戶提出需求的表面含義，更不是個別用戶提出的需求，而是新的信息系統的需求。新系統的需求來源于現行系統用戶的需求，所以在信息系統開發過程必須重視現行系統用戶的需求。

“功能過度”包含兩層含義：一是指目前信息系統開發過程中由于用戶對信息系統知識的缺乏，作為合同甲方對系統功能提出的過高要求，或者是用戶在信息系統開發過程中隨著信息系統知識的不斷增加而對信息系統功能不斷提出超越項目合同的新要求；二是指信息系統開發過程中信息系統專業人員利用信息技術的優勢為用戶設計了一些對業務系統開展業務無關、無用的功能，或者是設計了一些有關、有用，但過分超前，目前系統無法運行的功能。

“用戶需求”與“功能過度”是相關的。如果用戶需求解決的好，用戶需求系統、完整地反映了新系統的本質需求，新系統的功能設計便會在科學的前提下進行，自然不會出現前述的兩種功能過度的情況。反過來，如果出現了功能過度的情況，一定是用戶需求沒弄清楚，即新系統的需求不清楚、不系統。既可能是用戶方對新系統的需求不清楚，也可能是系統開發人員對新系統需求不完全了解。

三、“功能適度”原則

在實際應用中，產生“功能過度”主要有兩種原因：一是信息系統開發過程中開發雙方由于意見不一致的情況，如應用方對信息系統知識的缺乏、開發方對應用業務的不了解；二是一些軟件開發商為滿足所有用戶的需求而開發的通用軟件。所謂通用軟件一般都存在一個顯著問題，即對用戶和市場細分不夠。雖然功能設計是合理的，但合理的功能并不是大家都需要。解決功能過度最好的方法是在功能設計中始終堅持功能適度，為此，我們設計了功能適度原則。

1.功能不是越多越好

信息系統的開發中并不是系統的功能越多越好，用戶不需要的功能、用戶不會用的功能、對系統開展業務無作用的功能再多也是冗余。

2.設計的功能應該是用戶有用、要用和能用的

所謂“有用”是指這些功能是系統業務正常開展所需要的功能；而“要用”的功能是指用戶由于業務崗位的不同而需要使用的本崗位定制功能；“能用”的功能是指為用戶提供的功能應該都能滿足用戶的正常操作要求，并與用戶的使用能力相適應，能運行出正常與正確的結果。注意，也許系統的功能都“有用”，但對某個特定的用戶卻不一定“要用”、“能用”。

3.功能設計應該以對用戶的細分和新系統業務需求作為依據

功能設計為了“適度”，必須有針對性的設計，即必須針對每一個具體的操作崗位的具體業務需求來設計。不能把所有的功能都提供給用戶供其選擇，更不能憑想像來設計功能。

4.功能設計必須是完整的

這里說的“功能設計必須是完整的”是指功能設計必須適度，但每一個具體的功能設計都不能因為“適度”而影響設計的完整性。

四、結論

信息系統開發過程中必須正確理解“用戶需求”的概念，其不應該是用戶提出什么就做什么；而應是通過對現行系統用戶需求的調查，全面理解新系統的需求，并把這種需求作為新系統功能設計的主要依據。

新系統的功能不能過度設計，只需要設計用戶開展正常業務夠用的功能即可，冗余的功能設計是一種浪費。為了解決功能過度的問題，設計中堅持功能適度原則是十分必要的。

參考文獻：

[1]徐芳芳張鵬翥:信息系統用戶需求認知變化的紀實性研究[A].生產力研究,2006(4)