系統開發的主要方法范文
時間：2023-08-30 17:12:02
導語：如何才能寫好一篇系統開發的主要方法，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
關鍵詞：Web信息系統;電子商務系統;開發方法
1.主流電子商務系統開發方法的歷史演變
電子商務系統是多媒體、基于Web的信息系統與其他類型的信息系統一樣,電子商務系統需要有符合自己特點的分析設計方法。正確地分析和設計電子商務系統是電子商務系統得以正確實施的條件之一。從20世紀90年代初,研究人員已開始對Web信息系統的分析設計方法進行研究;雖然研究成果層出不窮,但是大都還處在理論研究階段,只有極其少數得到了一定的應用;并且,目前的電子商務系統還沒有出現類似于當年的結構化分析設計方法那樣占據統治地位的分析設計方法[1],這也說明還沒有出現一個令業界公認的、完善的方法。因此,急需對主流的分析設計方法進行比較,分析各自的優劣勢,取長補短,不斷完善。
從軟件工程領域來看,電子商務系統又被認為是一種多媒體系統、Web信息系統。因此,目前電子商務系統的開發方法與Web信息系統開發方法幾乎是等同的詞匯和內涵[1]。本文也將這兩個概念混用。目前,國際上許多學者正在從事這方面的研究工作,同時也取得了一些研究成果,并創建了一批適合于電子商務應用系統開發的開發方法。
1990年,Halasz和Schwartz提出了Dexter(DexterHypertextReferenceModel)[2]。1993年Garzotto[3]提出HDM(HypermediaDesignMethod),它建立在E2R模型基礎上;1998年Fraternali&Paolini發展了HDM,提出了HDM-Lite[4],它特別應用于Web信息系統。1995年Isakowitz提出RMM(RelationshipManagementMethodology)[5],它是建立在E2R和HDM的基礎上;1999年Lee等人在RMM基礎上又提出了VHDM(View2basedHypermediaDesignMethodology)[6]。1991年Rumbaugh提出了OMT(TheObjectModelingTechnique)方法[7];1994年Lange針對OMT的不足,提出了EORM(EnhancedObject2RelationshipModel)[8]。1995年Schwabe和Rossi提出了OOHDM(Object2OrientedHypermediaDesignModel)[9],它建立在OO的基礎上,發展了HDM的思想;1998年Schwabe將原型化方法融入OOHDM方法,提出了OOHDM2Web方法[10]。20世紀90年代末,面向用戶需求的開發方法引起廣泛的重視。1998年,DeTroyer和Leune提出了WSDM(WebSiteDesignMethod)[11];1999年,Bajaj和K.Siau提出了CMU2WEB(ConceptualModelforUsableWebApplications)[12];1999年,Lee等人提出了SOHDM(Scenario-basedObject2OrientedHypermediaDesignMethodology)[13]。
在研究各種開發方法的同時,許多研究者也重視開發方法的實用性,研究了支持開發方法的輔助開發工具,比較著名的是Fraternali和Paolini等人提出了Autoweb[14]。
2.電子商務系統開發方法的比較框架
2.1框架建立的依據
Lee[13]曾經對主要的電子商務系統的開發方法進行過簡單的比較研究,其中的一個比較角度是開發方法的階段劃分,但他只列出了各種方法的階段,并沒有比較。本研究試圖對開發過程進行詳細的比較,從以下兩個方面考慮,提出比較框架。首先,按照軟件工程的方法,系統的開發一般是結構化的過程,特別是像電子商務系統這樣大型的系統開發。其次,電子商務系統的開發有其自身的獨特性。Baskerville[15]經過對若干電子商務系統的開發過程比較,總結了開發過程的特點,包括:開發周期短、需求的不確定性、原型化方法、不斷升級版本、開發的并行性、固定設計架構、以各自的風格編寫程序、系統質量的可協商性、依靠優秀的技術人員、需要新的結構來整合資源。
根據以上的考慮,將電子商務系統開發方法的比較框架設計為四個層次:全局層、概念設計層、導航設計層和系統實施層。
2.2全局層
全局層是從整體的角度,分析和比較各開發方法的設計和開發特點。在這個層次上比較的方面包括:開發階段、每個階段的輸出結果以及整個過程中CASE的支持程度。開發階段比較各開發方法是否涵蓋所有的系統開發階段,一個電子商務系統典型的開發階段應該包括:需求分析階段、概念設計階段、導航設計階段、系統實施階段和系統維護階段。
當然,并不能單單依靠一種開發方法所能涵蓋的開發階段的多少來簡單評價開發方法的優劣,還需要考察開發方法對各個階段支持的深度。因此,各級段輸出結果比較的目的是比較各開發方法是否能夠清晰地輸出系統開發各個階段的結果以及這些結果是否有足夠的可讀性。開發環境支持的比較是比較各開發方法是否在電子商務系統開發的各個階段都能夠提供CASE工具進行支持。
2.3概念設計層
概念設計層是電子商務系統開發的第一層次,是整個開發過程的基礎,涵蓋從系統需求分析到系統概念模型建立的所有階段。在這個層次上比較的方面包括:設計驅動方式和對網絡資源和媒體的支持。
電子商務系統設計的驅動方式主要分為兩種:數據驅動和模型驅動。數據驅動是結構化設計思想下的設計驅動方式;模型驅動則是采用面向對象的設計思想。
電子商務系統與傳統的信息系統最重要的一個區別在于電子商務系統能夠充分利用網絡的資源,以多種媒體方式表現信息。對網絡資源和媒體的支持考察的主要內容就是電子商務系統開發方法對網絡資源和媒體的支持方式,即這些開發方法是如何表示和組織諸如圖像、聲音、視頻、文本等信息的。
2.4導航設計層
導航設計是電子商務系統開發的特性,也可稱為動態設計。在這個層次上,開發人員需要為概念設計層次中的實體、對象、關系以及信息建立符合系統需求的導航路徑和鏈接。在這個層次上主要比較系統鏈接的方式和系統訪問的結構。系統鏈接的方式主要比較開發方法對系統各節點之間、各種信息之間以及節點和信息之間關系傳遞的支持程度。比較中還將引入一些情況來測試這些開發方法是否能夠完全或者部分地表現系統同步、頁面生成、外部鏈接等特殊情況。系統訪問的結構是分析和比較各開發方法對于電子商務系統訪問結構的定義方式和設置環境。在這一項的比較中,主要從訪問單元和訪問方法兩個方面進行比較。
2.5系統實施層
系統實施層將從一個電子商務系統物理實施的層面上進行分析和比較,在這個層次上,開發人員將利用開發方法提供的各種工具將前面層面上形成的邏輯模型轉換成實際的物理系統,從而完成一個電子商務系統的建設工作。在這個層次上比較的方面主要包括:
1)系統的物理表現形式
主要研究各開發方法是否涵蓋從邏輯模型生成物理系統的過程,如果涵蓋的話,那么它們分別是如何來進行這個過程的,主要通過研究物理系統客戶端和服務器端的交互情況、系統數據庫的交互情況和系統事件的處理方式來進行評估。
2)系統生成的自動化程度
主要研究各開發方法在將邏輯模型轉換成物理系統的過程中,對自動生成頁面的支持程度。主要對從數據庫生成動態頁面的支持度和從模板生成靜態頁面的支持度進行測試。
篇2
摘要：回顧了電子商務系統開發方法的歷史演變過程，從全局層、概念設計層、導航設計層和系統實施層四個層次對五種主流的電子商務系統開發方法RMM、OOHDM、CMD2WEB、WSDM 和Autoweb 進行了全面的分析和比較，指出了各自的優勢和劣勢。
【論文“電子商務系統分析設計方法比較研究”分三個部分，本文是第3部分】：
一、主流電子商務系統開發方法的歷史演變；
二、電子商務系統開發方法的比較框架；
三、電子商務系統分析設計各開發方法的比較。
3. 電子商務系統分析設計各開發方法的比較
用上面建立的比較框架對五種電子商務系統開發方法———RMM[ 5 ] 、OOHDM[ 9 ] 、CMU2WEB[ 12 ] 、WSDM[ 11 ] 和Autoweb[ 4 ]進行全面的分析和比較。
3.1 全局層的比較
3.1.1 開發階段
五種開發方法對于各開發階段的涵蓋情況如表1 中的第1 項所示。從表中可以看到，由于電子商務系統開發的特殊性，概念設計階段和導航設計階段是所有這五種開發方法都涵蓋的開發階段。另外，由于系統開發的最終目的是要生成實際可用的物理系統，所以有四種方法涵蓋了系統實施階段。最后，還可以發現Autoweb 的方法最為全面和復雜，涵蓋了所有的系統開發過程，甚至還包括了其他四種方法所沒有的系統維護階段。
3.1.2 各階段輸出結果
僅僅從開發方法涵蓋的階段的多少無法判斷它們孰優孰劣，還需要進一步分析和比較它們對各個開發階段支持的深度。對于開發人員來說，電子商務系統開發各個階段的銜接工作尤為重要，它主要表現在:一方面是上一個階段中將有哪些結果輸出到下一個階段中，另一方面是下一個階段需要依靠上一個階段中的哪些輸出結果為基礎。這就是所謂的系統開發的一致性問題，只有連續的一致性才能確保系統開發的每個階段都圍繞著同樣的主題進行。 在這五種方法中，RMM 的一致性最高，在它的開發過程中，每一個階段都完全利用了上一階段的輸出結果。如片斷設計需要使用實體設計生成的ER 圖，而片斷設計生成的ER + 圖也正是導航設計所必需的設計信息。另外，Autoweb方法的一致性也很高，特別是在它的基礎結構設計、訪問路徑設計和表達設計過程中，這三項設計環環相扣，每一項設計都為后續的設計提供基礎和依據。CMU2WEB 方法的一致性最低，這也是由于這種方法主要集中在系統的概念設計階段造成的。
3.1.3 開發環境的支持
如果開發方法能夠提供CASE 環境來輔助開發人員開發，將大大加快系統的開發速度，提高開發人員的工作效率。各種開發方法對開發環境的支持如表1 中第2 項所示。從表中可以看到，CMU2WEB 和WSDM 沒有任何的開發環境支持，與之相對照的是Autoweb 的開發方法，它為開發人員提供了除了系統維護階段以外的所有階段的CASE 環境，這就意味著這種開發方法能夠大大簡化和加速電子商務系統的開發過程。
3.2 概念設計層的比較
3.2.1 設計驅動方式
RMM 的方法繼承于ER 方法，因此屬于數據驅動方式;OOHDM 方法采用面向對象的設計思想，屬于模型驅動方式;CMU2WEB 方法的主要組成部分是實體和關系，因此也屬于數據驅動方式;WSDM 以對用戶分類、建模為開端，屬于模型驅動方式;Autoweb 方法的概念設計階段采用HDM-lite 模型，因此它也屬于模型驅動方式。
3.2.2 對網絡資源和媒體的支持
作為電子商務系統與傳統信息系統最重要的不同之處，各開發方法對網絡資源和媒體的支持是評價它們的一個重要標準。這五種方法對網絡資源和媒體的支持程度如表1 中第3 項所示。除了CMU2WEB 以外，其他四種開發方法都采用實體屬性或者對象屬性的方法來表示各種網絡資源和媒體，例如，在OOHDM 開發方法中，可以為產品對象定義一個屬性———外觀，則這個屬性就可以用來添加能夠展示產品外觀的圖像信息。
3.3 導航設計層的比較
3.3.1 系統鏈接的方式
良好的、系統的鏈接將指引系統使用者正確地使用系統資源，因此系統鏈接的方式也是電子商務系統的一個基本設計方面。所有的電子商務系統開發方法都在概念設計階段定義了鏈接的表述方式。
RMM 方法使用三種不同類型的鏈接:條件索引鏈接、條件指導鏈接和條件索引指導鏈接。條件索引鏈接主要用于數據庫檢索，條件指導鏈接則用于系統向導式的導引，條件索引指導鏈接則適用于上述兩種情況的綜合情況。
OOHDM和WSDM 都采用面向對象的設計思想，所以它們的鏈接方式只有一種，即使用簡單的有向箭頭來表示對象之間的鏈接關系。
由于導航性能是電子商務系統的一個基本指標，CMU-WEB 方法主要依靠鏈接來確定應用系統的可用性。在CMU2WEB 模型中，鏈接主要有三種形式:一種表示信息塊之間的關系，一種表示信息塊及其描述內容的聯系，還有一種則表示信息塊和頁面之間的導航路徑。
Autoweb 模型中，各個信息集合之間的鏈接分為以下四種類型:索引鏈接、指導鏈接、索引指導鏈接和完全鏈接。每種鏈接都針對不同的系統導航情況。
3.3.2 系統訪問的結構
五種開發方法的系統訪問結構比較如表1 的第4 項所示。系統訪問方法主要分為兩種，一種為有向箭頭，另一種為導航約束。OOHDM、CMU2WEB、WSDM 方法采用的有向箭頭方式只能簡單表示訪問單元之間的單向或雙向聯系，但是RMM 和Autoweb 方法采用的導航約束方式卻可以為系統的鏈接增加更多的維度，例如，當一個客戶在網上選購貨物時，Autoweb 方法設計的系統就能夠利用索引指導鏈接為客戶提供相關產品的信息。
3.4 系統實施層的比較
3.4.1 系統的物理表現形式
一個好的開發方法需要平穩地把握從設計階段到實施階段的過渡，并且能夠提供相關的工具來簡化從邏輯模型到物理系統的轉變過程。對此，五種開發方法分別有不同的支持程度:
RMM 方法采用生成HTML 模板的方法，將HTML 頁面中的每個對象與邏輯模型中的節點和訪問單位相關聯。OOHDM方法具有專門的抽象界面設計階段和系統實施階段。在抽象界面設計方案中描述導航對象、用戶界面對象、多媒體對象等信息;在系統實施階段，OOHDM 提供專門的OOHDM-Web 環境幫助開發人員生成頁面模板。
CMU-WEB 方法沒有涵蓋系統實施階段。 WSDM 具有實施設計階段和系統實施階段，在實施設計階段中，開發人員需要從系統可用性出發，根據WSDM 的指導原則設計整套電子商務系統實施的方案，然后在系統實施階段付諸實施。
與其他開發方法相比，Autoweb 方法具有更完善的物理設計階段，在這個階段中，開發人員建立系統表達模型和風格表單，然后在Autoweb 所提供的CASE 環境中自動生成網頁。
3.4.2 系統生成的自動化程度
RMM、CMU2WEB 和WSDM 都沒有提供任何的輔助工具來自動生成電子商務系統的頁面，OOHDM 和Autoweb 在一定程度上提供了自動生成網頁的工具。OOHDM提供了OOHDM2Web 環境，在這個環境下，軟件自動生成由HTML 代碼和OOHDM2Web 函數庫調用相結合的頁面，所以它產生的頁面必須在OOHDM2Web 環境下運行。
Autoweb 則提供了一個被稱為“Schema & DataEntryGenerator”的自動系統生成器，在開發人員輸入設計完成的HDM2lite 概念模型后，系統自動輸出相應的關系數據庫以及對應的系統頁面，因此，具有更廣泛的應用意義。
3.4.3 系統維護的支持程度
五種開發方法對系統維護的支持程度如表1 中第5 項所示。除了Autoweb 以外，其他四種開發方法都不支持適應型和完善型的系統維護，從而大大降低了它們所開發的電子商務系統的擴展能力，這也是目前電子商務系統開發方法需要迫切改進的一個地方。不過，由于大多數開發方法(CMU-WEB 除外) 都具有十分徹底的分析階段，所以它們大部分都支持改錯型的系統維護，即系統設計的過程可以反復進行。另一方面，Autoweb 為系統維護提供的支持遠遠領先于其他開發方法，對于電子商務系統的更新、擴展和完善提供了很大的幫助。
4. 結論
通過對RMM、OOHDM、CMU2WEB、WSDM 和Autoweb五種電子商務系統開發方法在全局層、概念設計層、導航設計層以及系統實施層四個層次的比較，可以總結出以下幾點:
1) 盡管CMU2WEB 方法在采用量化標準評價電子商務系統設計方案可用性方面有新的突破，但由于它還只是一個概念模型，對于整個電子商務系統的開發過程支持還不夠完善，因此不具有太大的實用意義。
2) OOHDM 和WSDM 方法采用了面向對象建模的思想，這種模型驅動的設計方式與傳統的數據驅動方式相比，更能夠適應電子商務系統復雜、多變的開發特點。
3) Autoweb 最引人注目，它在比較框架的每個項目中都表現出色; 并且在這五種方法中，Autoweb 是唯一建立了CASE 環境的一種開發方法，這種CASE 環境將大大降低開發人員的工作強度，提高電子商務系統的開發效率。
參考文獻
[ 1 ] Lang M. A study of practice in hypermedia system design[A] . European Conference on Information Systems ( ECIS) [ C ] . Bled ，Slovenia ， 2001. 8 - 10.
[ 2 ] Halasz FG， Schwartz M. The dexter reference model [A] . Proceedings of the NIST Hypertext Standardization Workshop [ C] .Gaithersburg ， Maryland : NIST ， 1990. 95 - 133.
[3 ] Garaotto F ， Paolini P ， di Milano P ， et al . HDM- A model-based approach to hypertext application design[J ] . ACM Trans Information Systems ， 1993 ， 11 (1) : 1 - 26.
[ 4 ] Fraternali P ， Paolini P. A conceptual model and a tool environment for developing more scalable and dynamic web applications [ A ] .Proceedings of International Conference on Extending DatabaseTechnology[C] . Valencia ， Spain : Springer ， 1998. 421 - 435.
[ 5 ] Isakowitz T ， Stohr EA ， Balasubramanian P. RMM: A methodology for structured hypermedia design [ J ] . Communications of the ACM ， 1995 ， 38 (8) : 34 - 44.
[ 6 ] Lee H ， KimJ ，Gul Y. A view2based hypermedia design methodology[J ] . Journal of Database Management ， 1999 ， 10 (2) : 3 - 13.
[ 7 ] Rumbaugh J . Object 2Oriented Modeling and Design [ M ] . New York : Prentice2Hall ， 1991.
[ 8 ] Lange DB. An object2oriented design method for hypermedia information systems[A] . Proceedings of the 27th Hawaii InternationalConference on System Sciences[C] . Hawaii : IEEE Computer Society Press ，1994. 336 - 375.
[ 9 ] Schwabe D ， Rossi G. The object2oriented hypermedia design model [J ] . Communication of ACM ， 1995 ，38 (8) : 45 - 46.
[ 10 ] Schwabe D ， de Almeia Pontes R. OOHDM2Web : rapid prototyping of hypermedia applications in the WWW[ R] . Pontifcia Universidade Catlica do Rio de Janeiro ， 1998.
[11 ] De Troyer O ， Leune K. WSDM: a user centered design method for web sites [A] . Proceedings of the Seventh International WWW Conference[C] . Brisbane ， Australia : Elsevier ，1998. 85 - 94.
[ 12 ] Bajaj A ， Krishnan R. CMU2WEB : A conceptual model for usablemweb applications[J ] . Journal of Database Management ， 1999 ， 10(4) : 33 - 43.
[13 ] Lee H， Lee C， Yoo C. A scenario2based object2oriented hypermediamethodology [J ]. Information and Management ， 1999 ， 36 :121 - 138.
[ 14 ] Fraternali P ， Paolini P. Model2driven development of web applications : the autoweb system[J ] . ACM Transactions on InformationSystems ， 2000 ， 28 (4) : 323 - 382.
[ 15 ] Baskerville R ， Pries2Heje J . Racing the e2bomb : How the Internet is redefining information systems development methodology [A]. Realigning
篇3
關鍵詞：環境衛生；管理信息系統；開發探討
在新時期的發展下，管理信息系統逐漸得到了廣泛的應用，并且取得了明顯的成效，管理信息系統最開始出現于上個世紀九十年代末，主要是利用電子計算機技術、網絡通信技術及其他軟件技術進行信息管理的一種系統，其具有信息傳遞速度快、準確性高的特點，不僅能夠為管理工作帶來極大的便利性，還能有效提高工作效率。
一、環境衛生管理信息系統應遵循的原則
在人們物質日益提高的前提下，對環境衛生的保護意識也越來越高，因此加強環境衛生管理工作，為人們創造健康舒適的生活環境也就成為了目前環境衛生管理部門亟待解決的首要問題，并且為了真正提高h境保護水平，構建了一套完整的環境衛生管理信息系統，但在具體應用時需要遵守以下原則：第一，實事求是原則。環境衛生管理部門應根據自身的實際發展情況，如經濟能力方面，制定科學合理的開發目標，從而明確規定服務范圍；第二，突出重點原則。環境衛生管理系統應在根據實際情況的基礎上突出重點內容，從而在滿足管理需求的同時有效節約開發成本；整體性原則。信息管理系統屬于一個整體性的工程，因此在進行系統的開發過程中要將各項技術融合在內，從而保證系統功能的充分發揮。
二、關于環境衛生管理信息系統開發的方法研究
目前，信息管理系統的使用逐漸廣泛化，并且關于環境衛生信息管理系統的方法也是層出不窮，但從使用技術和應用普遍性的角度來看，在環境衛生信息管理系統開發中最常用的方法還是原型法和生命周期法。原型法主要是根據使用者對該系統的實際需求來開發的，并且在開發整個過程中完全以用戶提出的建議和意見為主展開適當的調整，進行進一步的完善，從而為使用者提供高質量的服務，為環境衛生信息管理系統的穩定運行提供保障；而生命周期法主要是指從環境衛生信息管理系統的開發初期到運行階段的一整個過程，都要嚴格按照生命周期的各個階段和流程展開對信息管理系統的開發。
通過對這兩種信息管理系統的比較，我們可知在進行環境衛生信息管理系統開發時，最好還是使用原型法，主要原因在于環境衛生行業涉及到的領域較為廣泛，屬于重復學科。因此為保證信息管理系統在性能和適用性方面都能達到最優狀態。除此之外，信息管理系統的相關開發人員也要和管理人員進行有效溝通交流，讓管理人員對環境衛生信息管理系統的運行過程提出適當的建議，并且開發人員要有針對性的展開解決完善，避免出現信息管理系統在使用時無法滿足環境衛生管理的相關需求現象。
三、環境衛生信息管理系統的開發過程分析
在環境衛生信息管理系統進行開發過程時，主要包括以下幾點：信息管理系統調查階段、信息管理系統設計階段及信息管理系統實現階段，具體闡述如下。
（一）信息管理系統調查階段
若想有效保證環境衛生信息管理系統的適用性和經濟效益性，就要在環境衛生信息管理系統進行實際開發前對系統開發方案的可行性和系統建立完成使用的可靠性展開詳細的調查研究。并且在調查工作具體開始時，首先就要對環境衛生部門的內部進行認真調查，內部工作主要是由環境衛生部門、其他部門、經濟實力及對信息管理系統的需求程度構成。然后在上述條件都具備的基礎上制定環境衛生信息管理系統的相應設計方案，保證其具有一定的可行性。最后對信息管理系統進行仔細調查，并且在調查過程中開發人員和管理人員都要共同參加，這種要求的原因在于雖然大多數的系統開發專業人才對系統開發非常優秀，但對于各部門的工作運行狀態卻是不太了解，將這二者進行有效結合，不但能幫助系統開發人員更好的對各部門工作流程準確掌握，營造和諧的工作氛圍，還能使系統開發人員在進行環境衛生信息管理系統開發時具有一定的針對性，從而實現系統開發的最佳效果。
（二）信息管理系統設計階段
在進行環境衛生信息管理系統設計階段時主要包括以下幾點流程：第一，總體規劃設計。主要包括對功能結構圖、模板結構圖及工作流程圖等；第二，制定科學合理的信息管理系統設計方案和相應的設計流程規范；第三，信息管理系統的配置方案。主要是由設備配置和通信網絡組合而成；第四，關于數據信息的儲存設計方案。主要包括數據庫信息設計和數據庫的保密設計等；第五，計算機處理方案設計。主要是由數據信息的輸入、輸出及程序編寫設計等內容。
（三）信息管理系統實現方案
由于環境衛生信息管理系統的開發過程中涉及到眾多領域，因此在對計算機設備進行應用選擇時，首先要考慮的就是其適用性和售后服務質量如何，如果計算機運行過程中出現故障問題可以及時給予解決，從而為信息管理系統的穩定安全運行提供保障。同時在信息管理系統的設計階段對可維護性要引起重視，這時由于系統會在服務環境的影響下發生改變，因此為了更好的滿足管理者和使用者的需求，就要保證系統具有可維護性，即定期對系統升級和更新。除此之外，在進行系統的調試過程中，要準確發現系統運行過程中存在的隱患問題，避免在使用后出現任何故障現象。
篇4
【關鍵詞】 企業管理;信息系統;系統分析;系統設計
隨著信息時代的來臨,企業越來越重視計算機系統的運用。在市場競爭日趨激烈的今天,企業若要得到穩定的生存和長期的發展,就必須努力開發并有效利用信息資源。信息資源的獲得是依靠當今社會普遍流行、使用的電子計算機來實現的。各個企業在管理方面應全面提高管理水平,構建并完善企業管理信息系統,以便進行信息化管理,來適應企業發展的需要。
一、結構化生命周期開發方法
結構化生命周期開發方法基本思想是:用系統的思想和系統工程的方法,按用戶至上的原則,結構化、模塊化地由頂向下整體性地分析與設計和自底向上逐步實施。用結構化生命周期開發方法開發一個系統,將整個開發過程劃分為5個依次連接的階段:即系統規劃階段,系統分析階段,系統設計階段,系統實施階段和系統運行階段。這5個階段共同構成了系統開發的生命周期。
由此可見,該方法所表現的是一種自頂向下的觀點,其顯著特點是能夠很好地將系統開發過程的整體性和全局性顯示出來,其強調的是以整體優化為前提來進行具體的分析設計。結構化開發方法流程(如圖1所示)。
該方法也顯示出了另一觀點,即將開發階段進行嚴格地區分,它強調一步一步地嚴格地進行系統分析、設計和實施,每一步工作都及時地總結,發現問題及時地反饋和糾正,后一階段的工作必須建立在前一階段工作成果的基礎之上,使每一階段的工作都有可靠的依據,這樣就可以減少開發過程中所存在的盲目性,在一定程度上避免了混亂狀態的出現,使成功開發管理信息系統的幾率大大提高。
隨著科學技術的迅速發展,計算機技術不斷提高,計算機在企業管理信息系統中的應用越來越廣泛,其各種要求也越來越高。由于管理信息系統的更新頻率越來越大,企業對于開發方法提高了時間上的要求,適應社會需求的系統開發應該是能夠在最低費用的條件下保證完成的時間最短。在這種趨勢下,結構化方法的規范化和標準化將其存在的不足之處漸漸地顯現出來,將其歸納為以下幾點:
一是,開發周期較長,此方法的階段劃分過程比較嚴格,每一步工作都需要認真完成,并對文檔的質量有著較高的要求,需要較多的時間。
二是,不能及時適應經常變化的環境,導致開發出的系統不能滿足企業管理需要,與現實相脫離。
三是,工具落后,系統開發過程需要很多的分析圖表,這些分析圖表沒有較為先進的工具,只能手工繪制,導致人力和時間的浪費。
四是,違背人類認識事物的規律性,該方法需要開發者具有很好的預見能力,一些不可抗力是不能避免的,用戶的需求是不能脫離主觀影響的等,要求開發者對這些因素的掌握不符合客觀規律性。
可見這種結構化方法存在上述四方面缺點,但是不能因此而忽視其嚴密的理論基礎,也不能因此徹底放棄該系統工程方法。這是因為,該方法在一些系統開發中往往是必不可少的,一些甚至是必須采用,特別是復雜系統的開發。現在開發工具越來越多,使得開發的工作效率有所提高,為結構化方法不斷注入新的生命力。它還可以作為比較流行并被廣泛采用的一種優秀的系統開發方法,尤其是與其他方法相結合,會產生更好的效果。
二、原型法
原型法的基本思想是系統開發人員憑借自己對用戶需求的理解,通過強有力的軟件環境支持,構造出一個實在的系統原型,然后與用戶協商,反復修改原型直至用戶滿意。原型法通過把實驗機制明確地引入系統的開發過程,從本質上避開了傳統的結構化分析設計法嚴格的需求定義階段。用戶的需要是在不斷的運行和評價原型的過程中逐步明確。在系統開發過程中,用戶不再面對難以理解的圖表,而是直觀的軟件,在演示或使用中提出需求,避免了需求表達不清等問題使系統開發真正體現面向用戶的原則。其開發過程是分析、設計、編程、運行、評價多次重復、不斷演進的過程。該方法的基本原理(如圖2所示)。
在采用原型法進行系統開發時,需要滿足下面幾個條件:首先,同結構化方法一樣,原型法也需要較短的開發周期以及較低的開發成本;其次,需要對原型進行評價,而且要求用戶進行參與;再次,原型必須具有可行性,即是能夠運行的;最后,要以原型的運行結果為依據,來對原型進行合理評價,然后以該評價結果為依據,對原型進行修改。由此可見,原型法具有開發周期短的優點,使用起來比較靈活,適用于中小型管理體制和組織結構不穩定、有變化的系統。原型發的特點是需要快速形成和不斷修改演進,使由這種方法開發出的系統具有較強的適應性,且易于修改。
然而,原型法在嚴格意義上還不能作為軟件工程方法而獨立存在,實際上的原型法只能最為系統開發思想,沒有與其相適應的專門的配套工具。具體地說,它只支持在軟件開發早期階段快速生成后期產品樣品的過程,不是完整意義的方法論體系。要想充分發揮原型法的效能,就必須有效結合其他軟件開發方法。
三、面向對象的系統開發方法
面向對象的系統開發方法是建立在對象、類、封裝、繼承、多態性等概念基礎上的系統開發方法。面向對象方法的基本思想是基于所研究的問題,對問題空間進行自然分割識別其中的對象及其相互關系,建立問題空間的信息模型,在此基礎上進行系統設計,用對應對象和關系的軟件模塊來構造系統。其目的是提高軟件系統的可重用性、可擴充性和可維護性,使軟件系統向通用性方向發展,逐步使軟件系統的生產能像硬件組裝那樣,由“軟件集成塊”來構筑。
面向對象方法的開發過程包括定義問題、識別對象、詳細設計問題和程序實現4個步。該方法的優點是接近現實世界,限制了人的主觀因素的影響,有效控制了因為人的不同而在認識系統上所產生的偏差。這種方法面向的應用解決了傳統結構化開發方法中客觀世界描述工具與軟件結構的不一致問題,縮短了開發周期,解決了從分析和設計等到軟件模塊結構之間多次轉換映射的繁雜過程。
面向對象方法也有一定的局限性,它的應用必須要有功能較強的軟件的支持。在開發大型的信息系統的過程中,若是自始至終都采用自底向上的方法,沒有自頂向下整體劃分的過程,就很可能得不到系統全貌,導致系統結構不合理、各部分關系失調等問題。這種方法在應用上同上述兩種方法一樣,需要與其他方法的結合,來更好地發揮自己的優勢。
四、結語
綜上所述,共有三種管理信息系統開發方法,每種方法都有各自的優點和局限性。在實際應用過程中,最優的開發方法就是根據要開發系統的具體情況,如綜合規模、復雜程度、開發工具等因素,來采取相適應的開發方法,或者將幾種方法結合運用。在經濟不斷發展,信息資源越來越重要的時代,一個企業要想在激烈的競爭中謀發展,在諸多企業間脫穎而出,就必須及時掌握信息動態,建立合理有效的管理信息系統。
參考文獻
[1]杜棟,田卿,劉小健.企業信息化的第3股浪潮:協同管理系統(CMS)[J].信息系統工程.2009(1)
[2]羅艷輝,李彬,鄧飛其.基于ERP與CRM整合的卷煙銷售管理系統[J].微計算機信息.2009(6)
[3]李彪,尤文,楊玉春,李俊峰.礦山企業能源計量管理信息系統的開發與應用[J].中國計量.2009(2)
篇5
關鍵詞：地方高校；應用型專業；案例式教學；DSP
一、引言
《DSP系統開發》是一門專業性很強的應用型課程，該課程要求學生具備卷積、相關運算、頻譜分析以及濾波器設計等基礎知識，同時要求學生具有一定的硬件知識和軟件編程基礎。該課程目標是培養學生成為動手能力強、寬口徑的應用型人才。地方高校的課程繁多，每門課程課時有限，難以在有效的時間內完成課程的學習和掌握必要的知識。另外，為了能培養出適應社會的應用型人才，我們積極響應《教育部國家發展改革委財政部關于引導部分地方普通本科高校向應用型轉變的指導意見》，積極探索地方高校應用型課程的教學改革。本文以工科通識類課程——DSP系統開發為例，從教學內容和教學方法上探索課程的教學改革。
二、DSP系統開發課程特點和問題分析
《DSP系統開發》是一門理論和實際緊密結合的專業應用型課程，它涵蓋的知識面非常寬，主要包括以下內容：DSP系統的硬件結構、指令系統、開發平臺；數字信號處理的基本理論和算法（FFT、FIR等）；DSP匯編語言、C\C++語言和CCS開發工具。同時要求學生了解DSP器件的發展過程及其特點，熟悉DSP器件的基本原理，總體結構、指令系統和尋址方式，學會DSP匯編語言程序的開發，了解TMS320系列中1至2種芯片的使用方法，掌握利用DSP實現軟硬件系統的設計，如完成FIR濾波器、FFT算法、實時小系統的設計。學生在學習該課程時感覺硬件結構復雜，寄存器多，理論難度大。筆者從事DSP課程的教學十余年，在該課程的教學過程中，倍感電子技術行業的發展之快，軟件不斷升級，芯片不斷完善，性價比不斷提升，市場不斷擴大。如何加強地方高校學生學習DSP這樣一門應用型非常強的課程，已成為一個值得思考的問題。本院光電信息科學與工程專業開設的《DSP系統開發》課程安排在大三下學期，總學時為40學時，其中理論28學時，實驗12學時。結合地方高校學生的實際情況，本文在分析該課程的特點基礎上，提出以案例式教學為基本單元，以實驗室教學為補充的教學改革方法，以提升學生的綜合實踐和應用技能。
三、DSP系統開發課程案例教學探索
案例教學法是一種創新性教學方法，它通過引導學生進行案例的交流和研討式分析，以達到利用案例獲取相關信息和數據來實現問題的解決，使學生掌握課程知識和基本技能。案例教學已經引起國內外學者的高度關注，成功地應用在很多學科領域。DSP技術的教學分為理論教學和實踐教學兩部分，目的重在培養學生的實踐應用技能。在地方高校應用型轉型背景下，本文提出采用以下方法實現DSP系統開發課程的案例教學探索。1.DSP系統開發課程案例教學法的組織案例教學法的組織過程包括：案例的搜集和整理階段，案例的分析和討論階段，案例的總結歸納。其中學生主動參與課堂是DSP課程教學改革的一個關鍵環節，因此教師要將一些有趣的DSP案例引入課程教學中，使枯燥的教學過程變得知識趣味化。針對本學院電子信息專業的學科特點和培養目標，結合DSP課程的教學進度和教學計劃，我們通過查閱大量相關文獻資料，整理了四個典型案例，制作教學課件，具體案例包括：存儲器模塊（尋址方式），FIR濾波器的DSP實現，FFT算法的DSP實現，任意波形發生器設計。我們對案例教學的整個環節進行總結，包括知識點的歸納、編程語言的使用、芯片內部結構的學習等。2.DSP系統開發課程的案例教學實施本節以“案例三：FIR濾波器的DSP實現”為例，進行案例教學過程的實施，該節內容包括以下四個知識點：FIR濾波器的基本理論；FIR濾波器的設計方法；FIR濾波器的MATLAB仿真；FIR濾波器的DSP實現。具體的實施過程包括講解環節、自學環節、答疑環節。（1）講解環節教師對學生講解準備的典型案例，首先進行知識點的串講（FIR濾波器的基本理論，FIR濾波器的設計方法，FIR濾波器的MATLAB仿真、FIR濾波器的DSP實現），然后提出需要討論解決的問題，如MATLAB仿真獲取的濾波器系數文件如何導入DSP的匯編程序中，最后安排本班同學進行課后學習和分組討論。其中光電信息科學與工程專業13級共42人，分為6組進行討論，要求各組學生認真準備，積極討論。（2）自學環節學生帶著教師提出的問題和疑難知識點進行資料查詢、搜索、組內討論，整理出問題的答案和解決辦法。（3）答疑環節學生自學完成后，教師安排課堂時間進行集中討論，由小組長匯報結果，提出解決問題的思路和辦法，其他組提出問題，教師進行現場輔導。小組匯報結束后，教師提煉學生存在的難點問題，整理進行講解和補充，啟發學生思考，以獲得最佳的討論效果。3.DSP系統開發課程的案例教學效果分析通過案例式教學后，學生在實驗室進行獨立考核試驗——“FIR濾波器的DSP實驗”，具體實驗要求：兩組完成32階高低通FIR濾波器的DSP實驗，兩組32階帶通FIR濾波器的DSP實驗，一組32階帶阻FIR濾波器的DSP實驗。在實驗過程中，學生能夠正確閱讀和修改程序，正確設置斷點、探針，獲得最終的實驗仿真效果。例如，高通濾波器的仿真效果如下圖所示，其中圖（a）為輸入信號的頻譜圖，（b）為輸入信號經高通濾波后的輸出信號頻譜圖。該實驗效果說明進行案例教學后學生對知識點的掌握更加牢固，更加靈活。
四、結束語
本文針對地方高校應用轉型的需要，研究應用型課程“DSP系統開發”的案例式教學模式。在DSP系統開發課程特點和問題分析的基礎上，筆者提出該課程的案例式教學方法。通過典型案例的活動實施，學生提高學習的主動性，提高思考問題、解決問題的能力，提升學習興趣，更好地適應高校應用轉型需求。
參考文獻：
[1]洪波，王秀敏，徐明彪，等.基于創新理念的DSP課程實驗教學研究[J].實驗室研究與探索，2014.33
[2]張新平，馮曉敏.重思案例教學的知識觀、師生觀與教學觀[J].高等教育研究，2015.11
[3]李曉琴.案例教學在《旅游規劃與開發》課程教學中的應用[J].教育理論與實踐，2016.12
[4]李寒梅.案例教學在教師教育課堂教學中的觀察與啟示[J].中國大學教學，2013.06
[5]王華榮.以案例教學推動大學課堂教學模式改革的實踐與探索[J].中國大學教學，2011.04
篇6
關鍵詞：信息技術 管理系統 項目管理
管理信息系統開發的項目管理是為了使開發項目能夠按照預定的成本、進度和質量順利完成，根據管理科學的理論，對需求、成本、人員、進度、質量、風險等進行科學分析和有效管理及控制，并利用工程化開發方法所進行的系統活動。
1 項目管理的組織模式
管理信息系統開發可以是企業管理信息系統的開發，也可以是為實現企業某一管理職能而進行的一個單獨的開發項目。對于前者，需成立企業的項目委員會，委員會下設項目管理組、項目評審組和項目開發組；如果是后者，則可以根據職能所涉及的范圍，召集相關部門人員成立開發項目組，項目組中分設系統開發小組和項目評審小組，由項目負責人進行統一管理和協調。
項目管理負責人可以為多人，由職能部門和信息部門管理人員組成。主要職責為：擬定項目管理的進度安排；組織項目階段評審；協調整體開發工作；對項目管理采取優化措施。
項目評審小組一般由企業技術專家組成。主要職責為：對項目的需求分析進行評審；對系統選型和開發計劃進行評審；對系統開發進行階段性評審；對項目總結報告進行評審。
開發項目組有開發技術人員構成。主要職責是：根據項目負責人的安排具體負責項目的軟件開發工作；項目結束后提交開發成果并形成技術文檔。
2 管理信息系統項目管理過程
一個完整的管理信息系統開發項目通常包括三大階段：需求分析、系統選型和系統實施。從具體的項目執行過程上來講，項目管理可分為項目的項目授權、需求分析、項目選型、開發計劃制定與實施、項目評估及更新和項目完成驗收六個步驟。
2.1項目授權
在管理信息系統的開發要求提出后，需要確定開發項目管理的責任者，由其負責項目的可行性分析、需求評估，并進行項目開發的總體規劃和管理與質量控制等，即將項目開發與管理的權限授予某一部門。一般而言，如果是針對企業的某項管理職能而進行的系統開發，應由具備此項管理職能執行能力的部門來負責；若是企業的總體管理信息系統開發，這應由成立的項目管理委員會負責。
2.2需求分析
需求分析可分為三個過程：
1）可行性評估：根據項目所期望達到的目標，明確項目開發所需要投入的企業資源，并從企業現行的管理方式和理念、人力資源、技術支持等方面考慮，確定項目開發成果能否被使用者接受，能否促使工作流程的合理化，提高工作效率，降低企業管理運行成本。
2）需求評估：對管理信息系統開發的整體需求和期望做出分析和評估，詳細考慮需求的實現方式，確定系統的各個功能模塊及模塊間的關系，對系統的信息標準進行統一確定，并據此明確管理信息系統項目成果的期望和目標。
3）項目總體安排：對管理信息系統開發的時間、進度、人員等做出總體安排，制定項目的總體計劃。
2.3項目選型
在明確了項目的期望和需求后，項目選型階段的主要工作就是為開發選擇合適的軟件系統和硬件平臺。在項目選型階段的主要管理工作是進行系統選擇的風險控制，包括正確全面評估系統功能，合理匹配系統功能和自身需求，綜合評價軟件系統和硬件平臺的功能及價格、技術支持能力，充分考慮系統維護和后續開發等因素。
2.4 開發計劃制定與實施
在項目策劃時，要充分考慮具體開發人員對開發過程的意見，項目開發的負責人應當協同開發人員進行盡量精確的對開發過程情況的估計。開發計劃常以文本文檔和圖形文檔結合的形式出現，文本主要記錄項目的約束和限制、風險、資源、接口約定等方面的內容，對于進度和資源分解、職責分解、目標分解最好通過項目管理軟件工具來進行規劃和管理，以利于進行同步修改。
2.5項目評估及更新
項目評估及更新階段的核心是項目管理控制，就是利用項目管理工具和技術來衡量和更新項目任務。項目評估及更新貫穿于系統開發的全過程。在項目評估及更新階段常用的方法有：
1)項目實施過程的階段性評估，考察開發過程是否按計劃進行并達到預期的目的，如果出現偏差，研究是否需要更新計劃及資源，同時落實所需的更新措施。
2)通過定期編寫項目進度報告，召開項目開況通報會議，進行定期的工作小結，評估實施進度及成果。
3)通過對開發人員及需求部門人員進行培訓，編寫完善開發過程中的各種技術保障文檔，從而建立起完整的質量資料，以便于開發完成后的進行有效的系統維護，并對將來可能的后續開發提供全面、系統、準確的技術資料。
2.6項目完成
項目完成階段是整個實施項目的最后一個階段。
1)結合項目最初對系統的期望和目標，對項目實施成果進行驗收。
2)正式移交系統正式運轉及使用，由企業的信息部門進行日常維護和技術支持。
3)項目總結對項目實施過程和實施成果做出回顧，總結項目實施過程中的經驗和教訓。 3項目管理質量控制過程
質量控制是項目管理的重要方面之一，建立和執行適當的質量衡量標準是進行項目質量管理的關鍵。質量控制貫穿了項目管理的全過程，是在項目管理中對質量的動態管理，它不僅僅是對開發成果的質量要求控制，還包含了對開發工作流程、開發方式、財務成本以及開發風險等更方面的控制管理過程。
3.1建立項目的質量衡量標準
項目質量控制標準的制定是依據系統開發的功能需求，通過開發項目的計劃和實施過程所建立起來的，對項目開發的若干要求，以此作為項目開發評審和控制標準的基礎和核心。具體的項目質量控制標準主要包括以下內容：
1）項目開發工作流程的合理化；
2）開發時間和成本預算控制；
3）項目風險控制；
4）開發工作安排效率；
5）開發工作的協調管理過程；
6）工程化開發方式的運用；
7）程序的運行效率和信息標準的統一；
8）管理信息系統需求方滿意度。
3.2觀察開發過程的實際表現情況
通過項目執行過程中的各種渠道，收集項目實施的有關信息，了解開發過程的實際表現情況。在這一步驟中可以利用的信息渠道有：
1)正式渠道，如定期編寫項目進度報告，召開項目開況通報會議；
2)非正式的渠道，如在開發過程中與項目小組成員或需求方的交流等。
3.3進行實際表現和控制標準的比較
比較項目實施的實際表現和預先制定的控制標準，主要是了解項目進展情況，及時調整與項目計劃的偏差。
管理控制標準為客觀評價項目狀況提供了依據，使項目負責人能夠迅速、有效地對項目的實際進展情況做出全面、客觀判斷，從而及時采取必要的措施。
3.4采取調整措施
在比較項目實際表現和衡量標準后，如果出現偏差，就需要采取調整措施，糾正措施可以采取以下的形式：
1)對開發流程進行合理化調整；
2)協調項目資源的合理分配；
3)建立系統、全面、準確的技術文檔資料；
4)調整項目組織形式和項目管理方法。
4項目管理過程中的協調工作
在管理信息系統開發的項目管理中，存在著大量的管理協調工作，主要涉及到以下幾個方面：
4.1需求方與開發方的關系
需求方與開發方是對立的統一體，雙方均希望將開發項目做好。但需求方可能對信息開發技術缺乏全面的了解；而開發方對需求方的需求、細節了解不充分等因素，使得雙方對開發過程的理解存在著差異。而這種認識上的差異與理解的不同會導致開發成果與實際需求偏差甚遠。因此，項目管理的重要目標便是建立一個便于開發方與需求方之間進行交流的環境。
4.2需求方參與項目管理人員與使用人員的關系
管理信息系統的使用一方面減輕了工作強度、提高了工作效率，而另一方面也改變了現行的工作管理模式，改變了原有的一些工作流程和工作習慣。但是管理信息系統的成功與否有賴于使用人員的檢驗。特別是在管理信息系統的試運行階段，使用人員對管理信息系統的使用實際上是對系統的深入測試，有助于幫助開發方進一步完善軟件功能，提高軟件的實用性、穩定性及可靠性。
4.3項目管理人員與軟件開發人員的關系
項目管理人員與軟件編程人員的關系處理得如何將直接影響軟件編程人員的積極性。當使用人員對系統提出問題，并改動要求時，軟件開發人員往往找出各種理由予以否定，而這正是引起開發方與需求方矛盾的最經常的原因。在管理信息項目開發中，項目管理人員需要經常協調使用人員和軟件開發人員的關系，既要滿足需求方的需求變化，又要充分調動開發人員的積極性。
4.4性能與靈活的關系
性能與靈活是系統設計中的一對矛盾，在項目管理中應充分考慮性能與靈活的關系。性能是系統可用性的重要因素，很難想象一個響應速度很慢的系統能得到最終用戶的認可，而靈活性是系統適應變化能力的重要因素，一個無法適應工作模式變化的系統也是難以推行的。
篇7
關鍵詞：會計信息管理系統 審計 系統分析 系統設計 系統實施
近年來，會計電算化迅速。會計信息系統的開發已由單項處理向較完整的會計信息管理系統發展，由單機向機的應用發展，由單純的會計核算向管理會計應用方向發展。不少地區和行業，已把會計電算化定為會計工作升級的條件之一。此外，會計軟件市場的出現，促進了會計核算軟件的商品化、通用化，有效地推動了我國會計電算化的進程。總體上，會計商品化軟件在企業中得到了廣泛的應用，并已取得了較好的效果和效率。而眾多的中小企業，如浙江省溫州地區中小企業達到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.詳細檢查系統實施階段的程序設計規格書、源程序清單、程序測試報告、系統測試報告、操作手冊等文檔是否完整準確。
四、結束語
會計信息管理系統開發的審計，是一種事前審計，它具有積極的意義。因此，審計人員、特別是單位內部審計人員對會計信息管理系統的開發進行審計，這對于開發活動的恰當控制，系統開發方法的性、先進性和合理性，系統開發過程中產生的系統資料和憑證的規范性，系統運行以后數據處理的合法性、正確性、完整性和效率性，以及事后審計的可審性，都具有很大的作用。
：
篇8
關鍵詞：嵌入式系統；集中授課；教學方式
中圖分類號：G642.4 文獻標志碼：A 文章編號：1674-9324（2015）49-0182-02
一、引言
隨著信息化與工業化的融合及工業4.0國家戰略的提出，嵌入式系統技術有著越來越廣闊的應用空間。目前，嵌入式系統技術已經深入應用到了工業控制、智慧城市、智慧交通、智能家居、智能醫療、智能穿戴、通信設備等人們生活的各個領域。為了適應社會對嵌入式系統開發人才的緊迫需要，如今大多數高校在電子信息工程、自動化等專業開設了嵌入式系統方向[1-3]。在嵌入式系統開發方向課程教學中大多高校仍采用傳統的授課方式，即把相關專業課分散到三到四個學期，每門課又分散到一個學期講授，每周二到三次課。其教學效果并不理想，學生普遍感到該課程難以掌握。為了解決上述問題，本文給出集中授課方式在嵌入式系統方向教學中應用的一些想法和意見。
二、嵌入式系統方向開設背景及課程介紹
（一）嵌入式系統開設背景
所謂嵌入式系統是軟硬件緊密結合的綜合系統，一般而言，嵌入式系統由嵌入式硬件和嵌入式軟件組成，它是面向用戶、面向應用、面向產品的專用計算機系統。嵌入式系統擁有軟件硬件可裁剪，對可靠性、成本、體積和功耗嚴格要求的特點。基于嵌入式系統的“專用性”以及“嵌入性”，在各個領域均有嵌入式系統的廣泛應用。因此當前嵌入式系統擁有巨大的發展潛力、社會需求大量的嵌入式軟硬件工程師。在此背景下，以及遵循培養應用型人才的教學理念下，國內絕大多數高校紛紛開設嵌入式系統開發課程。
目前我校的嵌入式系統方向人才培養目標是：掌握電子技術、嵌入式系統應用與開發、物聯網技術開發與應用等工程領域的實踐知識和技能，具備嵌入式開發、嵌入式系統測試、物聯網應用開發能力，能在通信、電子設備設計制造、物聯網應用、IT業等部門從事嵌入式系統軟硬件分析與設計、測試、物聯網研究與開發、電子信息系統應用與維護、開發、測試、銷售及研究等生產和管理第一線需要的高素質應用型人才[4]。
（二）嵌入式系統課程介紹
嵌入式系統課程一般包括：Linux系統、C語言、C++面向對象的程序設計、ARM微處理原理與應用、嵌入式系統GUI開發。其中Linux系統為嵌入式系統課程的核心部分，在今后的嵌入式開發編程過程中大多是在Linux環境下進行；C語言則屬于嵌入式系統開發最基礎也是最重要的編程語言，目前嵌入式系統硬件開發多是基于C語言；C++語言則是屬于面向對象的高級編程，嵌入式系統GUI開發則是在Linux環境下在Qt上使用C++語言進行圖形界面的編程設計；最后ARM微處理器的原理與應用是整個嵌入式系統課程的精華也是其難點所在，所有的程序都需要在ARM處理器上運行，所以學習好ARM原理與運用無論以后做硬件工程師還是軟件工程師都有著重要意義[5-7]。
三、嵌入式系統方向教學方式現狀
目前絕大多數高校仍然采用傳統的授課方式來講授嵌入式系統課程，即把相關專業課分散到三到四個學期，某門課程在一個學期開展，分散在15～18個教學周，每周講授4～6節課。從近幾年畢業生難以適應市場的需求來看，按照傳統的教學方式對嵌入式系統課程進行教學顯然有著巨大的不足之處。主要不足是：
1.知識點的講授不連貫，往往在下節課浪費了大量的時間來進行上次課的補習。
2.實踐應用少，尤其對于應用開發型的課程，講完理論之后缺失及時的實驗開發。即使加了實驗課，某些實驗項目不能在兩節課完成[8]。
3.時間跨度過大，嵌入式系統課程知識涉及面廣，僅僅上述的四門基礎課程按傳統授課計劃一學期一門課來看，需要兩年才能完成。
4.高校針對嵌入式系統教學知識落后于當下嵌入式技術發展，同時也缺乏有資深嵌入式工作經驗的教師。
四、集中授課方式在嵌入式系統方向教學應用
集中授課方式是指把某門課程集中在一段時間內連續進行學習，直到該門課程進行完畢，再開展下一門課程的學習。整個學習階段大致是以知識點做基礎，實際應用做課程案例，開發項目為驅動，注重提高學生的實際編程能力。這樣能夠及時有效地進行針對性學習，能夠穩固知識點，加強學生實踐動手能力，而且學習時間跨度大大降低，根據人類的記憶規律更能使學生加深理解記憶，更好地掌握本階段的知識[9]。
由于嵌入式課程涉及知識面廣，系統的嵌入式系統開發課程我在這里大致分為了四個階段：
1.嵌入式系統開發基礎篇。首先，進行Linux系統的基礎學習，其主要內容為：學習Linux系統的理論知識，如Linux系統簡介、Linux的文件系統、文件類型及屬性、文本編輯器等；之后進行學習Linux系統下的常用命令和shell編程；最后也是以后常使用的知識便是編譯與調試，學習GCC編譯器和GDB調試器以及make工具，通過makefile文件來描述源程序之間的相互關系并自動維護編譯工作。其次，在學習了Linux基礎之后便可以在Linux環境下進行開發，也就意味著進入了C語言的高級編程學習中，而在此階段學習中不能像傳統教學一樣僅僅教授C語法基礎，要更深入學習C語言的靈魂知識――指針的學習，之后進行C的高級編程，例如編譯的預處理、鏈表及操作、樹和二叉樹等知識的學習。這樣就基本上完成了本階段的理論學習，本階段最后一步是學生實戰提高的一項內容即C項目系統的設計開發，在一個系統項目的開發過程中幾乎會用到此前所學的所有知識，學生在開發過程中也會看清自己學習中所欠缺的知識。
本階段因為是基礎性知識學習，在后期學習應用中均占有很大的分量，所以用時也是最長的一個階段，約在5～6周方可完成階段性學習。
2.嵌入式開發系統篇。在完成了C語言的學習后，便可以開始進行學習Linux系統程序的設計，本階段學習目標便是掌握Linux系統編程和網絡編程的基本方法，掌握多進程和多線程的編程能力。學習過程中主要學習進程與線程的原理、進程間通信的方式、網絡的基本原理、Socket編程等。在此階段的學習中要多鍛煉大型程序和復雜項目框架的設計能力，使得學生能夠在未來工作中具備掌控和領導項目的潛力。
在完成本階段性學習之后，同樣需要大量的練習以及系統項目的設計開發訓練。本階段主要是系統的設計學習，則需訓練諸如局域網OICQ程序設計、遠程終端管理系統之類的開發項目，來提高學生系統設計開發能力。本階段主要學習系統的基礎性開發，大約在四周左右完成。
3.嵌入式開發的軟件應用篇。本階段主要進行C++面向對象的程序設計開發，學習類和對象的區別與應用，面向對象程序設計的三個基本特征：封裝、繼承和多態。因其在C語言基礎上演變而來，故而此階段屬于快速學習階段，在一到兩周即可完成。然后學習系統GUI開發，主要要求掌握Qt開發的基本流程和Qt提供的類庫的使用方法。在整個的軟件應用階段會在兩周內完成。
雖然學習用時比較短，項目的開發練習依然不可缺少，在未來工作中這類快速學習并加以應用的情景有很多，學生們有必要也必須有快速學習的能力。
4.嵌入式開發的硬件篇。本階段在整個嵌入式系統開發中屬于難點，需在本階段學習ARM微處理原理和應用，主要掌握ARM的基本架構、指令系統，同時也要了解ADS集成開發環境；嵌入式Linux的系統移植，主要掌握u-boot啟動流程、u-boot的移植流程及關鍵步驟，學會構建根文件夾系統，掌握整個嵌入式Linux系統開發方法；學習Linux驅動開發，掌握嵌入式Linux設備驅動程序的基本原理、架構和設計方法以及驅動開發中常用的機制和內核資源。
該階段主要以實驗為主，加強學生動手能力，熟悉嵌入式的硬件程序開發，該階段也在四周左右。
五、總結
經過對社會上嵌入式系統培訓機構的調研來看，大多數機構都是應用的此類授課方式專項培訓嵌入式系統開發人才，而經過培訓之后的學員有著扎實的知識功底和良好的實用技能，明顯比高校畢業生有更高的動手能力和崗位適應優勢。因而在高校嵌入式系統方向課程的教學中嘗試使用集中授課方式，對提高應用型人才培養有重要的借鑒意義。
參考文獻：
[1]王崴.“嵌入式系統”課程的教學改革與實踐[J].常州工學院學報，2013，26（1）.
[2]郭銳.嵌入式系統教學中若干教學方法研究與實踐[J].科技信息，2012，（16）.
[3]彭道剛，李輝，夏飛.基于項目驅動的嵌入式系統教學改革與實踐[J].中國電力教育，2013，（28）.
[4]張廣淵，肖海榮，馬昭，梁偉.應用科技大學本科生科研能力培養改革探討[J].大學教育，2014，（4）.
[5]冀常鵬，馬飛，徐維.項目驅動的嵌入式系統教學改革.電氣電子教學學報，2012，（33）.
[6]鄭廣海，曲英偉.嵌入式系統課程群實踐教學優化整合與知識融合的研究[J].2015，18（6）.
篇9
關鍵詞：船艇裝備；虛擬拆裝；EON
中圖分類號：U676 文獻標識碼：A 文章編號：1009-2374（2013）22-0094-02
目前，船艇部隊和院校對裝備使用和維護人員的拆裝培訓一般采用兩種方式：理論學習和實裝訓練。理論學習利用教材、多媒體動畫、視頻錄像、圖紙及裝備的技術手冊等資源對受訓者進行培訓，可使受訓者掌握裝備結構原理，裝配的信息、工藝等理論知識，但這種方式不利于受訓者的實際操作能力的提升。實裝訓練在理論學習的基礎上，運用所掌握的理論知識，在實際裝備上進行拆裝訓練。這種方式能夠使受訓者直觀地了解實際裝備的內部結構，增強受訓者的實際動手能力。但這種方式在訓練過程中，常出現大量的工具、零部件和材料的損耗現象，導致實際裝備拆裝功能減弱。而且，用于訓練的裝備更新速度遠落后于船艇部隊裝備更新的速度，訓練無法滿足實際需要。在受訓人員較多時，由于實際裝備數量的限制，需要耗費大量的時間和人力。因此，急需教學訓練手段和方法的創新來解決上述問題。船艇裝備虛擬拆裝訓練系統是目前最為有效的替代方法，虛擬拆裝技術能夠保留上述兩種培訓方式的優點，彌補它們的不足，增強裝備使用人員的操作能力，提高維修技術人員的維修技能，為新裝備的使用維護水平的提高，提供了一種新的方式，有利于新裝備快速形成戰斗力。本文通過分析船艇裝備虛擬拆裝訓練系統需求和功能，設計了系統開發的方案，研究了系統實現的關鍵技術。
1 系統的需求與功能分析
拆裝訓練的主要目的是通過訓練提高裝備使用人員對船艇裝備結構、原理性能的認知水平和裝備維修人員的維護修理能力。虛擬拆裝訓練系統要能夠形象直觀地演示船艇裝備結構、原理、拆裝過程，指導受訓者進行裝備認知和拆裝訓練，并能對受訓者的認知和拆裝能力進行考核。通過對船艇裝備拆裝訓練的需求分析，系統主要實現以下三個功能，如圖1所示。
（1）理論學習功能。系統以文字、圖紙、多媒體動畫、錄像視頻等資源為基礎，利用虛擬現實技術構建的虛擬拆裝場景，通過裝備結構與原理的可視化教學、相關資料的檢索、裝備拆裝過程的自動演示講解等子功能，為受訓者提供裝備理論知識、拆裝過程的理論知識。系統有適當的接口，可以更新理論知識，以適應裝備的更新。
（2）拆裝訓練功能。系統為達到實際裝備拆裝訓練相同的作用，通過完全拆裝、部分拆裝和指定目標拆裝三種訓練任務，系統引導拆裝、受訓者自主拆裝兩種訓練模式逐步提高受訓者的實際拆裝能力。訓練的過程中，受訓者可以查閱相關的幫助文檔，了解拆裝的工藝。為了適應部隊裝備的更新，系統能提供任務更新接口。
（3）訓練考核功能。系統追蹤并記錄受訓者的考核過程，根據評估算法評價受訓者拆裝的能力。管理人員能夠根據需求編輯考核的任務。系統能夠對同一批次的考核成績進行分析，了解訓練過程中存在的不足，為以后的訓練提供依據，促進訓練效果的提高。
2 系統開發方案設計
在虛擬拆裝訓練系統的開發方面，國內外的研究者做了大量的研究，主流的虛擬拆裝訓練系統開發的方案主要可以分為三種：底層開發，二次開發和基于3D引擎的開發。底層開發，是利用高級程序語言和圖形開發接口（如OpenGL、VRML等），從底層開始構建虛擬環境。這種方式靈活性好，執行效率相對較高，可以滿足用戶的個性化要求，但是開發周期較長、工作量大、對程序員的要求高。二次開發，是指在原有的CAD軟件進行二次開發（如Pro/E、UG等），這種方式開發周期短、難度相對較低，但對CAD軟件的依賴性高，不能滿足用戶的個性化要求，沉浸感和交互感較差。基于3D引擎的開法（如EON、Virtools、VP等），這種方式開發的周期短，工作量相對較小，對程序員要求較低，而且系統的交互性好、沉浸感強。考慮船艇裝備拆裝訓練的實際要求，結合開發人員的實際情況，本系統采用第三種方式開發船艇裝備虛擬拆裝訓練系統，系統開發的方案如圖2所示，主要包括5個部分：三維建模、模型預處理、虛擬拆裝仿真、系統集成和數據庫。
其中三維建模部分主要完成利用SolidWorks建立船艇裝備、拆裝設備與工具、拆裝場景的三維模型；模型預處理部分主要完成利用3DMax對建立的三維模型進行優化調整；虛擬拆裝仿真部分主要完成在EON中導入三維模型，在拆裝工藝規劃的基礎上，實現裝備自動演示的路徑和順序設置、自主拆裝的路徑及順序設置、交互操作的控制，碰撞檢驗；數據庫部分主要實現對人員信息、拆裝知識、拆裝模型等信息的管理；系統集成部分主要實現數據庫、訓練任務和模式等進行集成，通過人機友好的系統界面，便于人員的使用管理。
3 系統實現的關鍵技術
3.1 虛擬拆裝場景三維模型建立
虛擬拆裝場景是為受訓者在接受拆裝訓練時提供一個“實裝”、“實地”、“實時”的仿真環境，包括虛擬拆裝人、虛擬拆裝裝備、虛擬拆裝設備與工具以及虛擬拆裝場景。本系統為桌面式虛擬系統，以鼠標和鍵盤來代替虛擬拆裝人的動作，不涉及虛擬拆裝人的建模。在SolidWorks軟件中，根據船艇裝備、拆裝工具及輔助設備的幾何信息、物理屬性、裝配關系以及裝配層次等信息，分組建立船艇裝備、拆裝環境、拆裝工具及輔助設備的三維模型。
3.2 虛擬拆裝過程仿真
虛擬拆裝過程仿真是系統的核心，主要在虛擬場景中虛擬裝備運動、虛擬拆裝工具及輔助設備運動以及相互之間的交互作用。本文利用間接的方法對拆裝工藝進行分析獲得拆裝序列，并規劃虛擬場景中虛擬裝備的拆裝路徑，在此基礎上，進行裝備拆裝過程的仿真。
3.2.1 人機交互過程仿真。在本系統中，人機交互過程的仿真主要利用EON中提供的傳感器節點、事件驅動和路由機制來實現的，用戶通過鼠標或者鍵盤輸入操作消息，由傳感器節點感應用戶操作，并將消息通過路由機制傳遞給相應功能節點來處理消息，由輸出設備輸出相應
結果。
3.2.2 碰撞檢測。碰撞檢測是構成虛擬現實系統的基本要素，也是本系統的基本屬性之一。在本系統能夠及時檢測到兩零件的相對位置，并做出相應的判斷，若表面接觸，則能夠及時停止，防止兩零件之間相互穿越，破壞虛擬環境的真實感和用戶的沉浸感。在本系統開發過程中，利用EON中自帶的碰撞檢測（Collision Objectnode）節點和物理管理（Physics Managernode）節點來實現碰撞檢測。
3.3 系統集成
系統管理主要實現對人員、理論知識、訓練與考核任務、考核的管理。本系統采用VC6.0作為系統集成的平臺，對EON和數據庫進行集成，并開發相應的管理功能。EON和VC的通信通過EON提供的ActiveX空間EonX來實現。
篇10
關鍵字：倉庫管理 倉庫 管理系統 VISAUL FOXPRO 面向對象
目錄
內容提要
引言
第一章 管理信息系統概述…………………………………………
第二章 系統設計…………………………………………
21 系統目標設計…………………………………………
22 開發設計思想………………………………………
23 開發和運行環境選擇………………………………………
24 系統功能分析………………………………………
25 系統功能模塊設計………………………………………
第三章 數據庫設計…………………………………
31 數據庫需求分析……………………………………
32 數據庫概念結構設計……………………………………………
33 數據庫邏輯結構設計………………………………………………
34 數據庫結構的實現…………………………………………
第四章 系統主要功能模塊的創建………………………………………
4．1 功能選擇界面的設計……………………………………
4．2 設備入庫模塊的設計……………………………………
4．3 設備出庫模塊的設計………………………………………
4．4 設備還庫模塊的設計……………………………………
4．5 設備需求模塊的設計……………………………………
4．6 設備采購模塊的設計……………………………………
4．7 顯示報表模塊的設計……………………………………
4．8 開發中的難點和解決技巧………………………………
第五章 系統的編譯和發行…………………………………
總結………………………………………………………………
致謝(參考文獻)…………………………………………………
附錄………………………………………………………………
前言
企業的物資供應管理往往是很復雜的，煩瑣的。由于所掌握的物資種類眾多，訂貨，管理，發放的渠道各有差異，各個企業之間的管理體制不盡相同，各類統計計劃報表繁多，因此物資管理必須實現計算機化，而且必須根據企業的具體情況制定相應的方案。
根據當前的企業管理體制，一般物資供應管理系統，總是根據所掌握的物資類別，相應分成幾個科室來進行物資的計劃，訂貨，核銷托收，驗收入庫，根據企業各個部門的需要來發放物資設備，并隨時按期進行庫存盤點，作臺帳，根據企業領導和自身管理的需要按月，季度，年來進行統計分析，產生相應報表。為了加強關鍵物資，設備的管理，要定期掌握其儲備，消耗情況，根據計劃定額和實際消耗定額的比較，進行定額的管理，使得資金使用合理，物資設備的儲備最佳。
所以一個完整的企業物資供應管理系統應該包括計劃管理，合同托收管理，倉庫管理，定額管理，統計管理，財務管理等模塊。其中倉庫管理是整個物資供應管理系統的核心。
鑒于Visual Foxpro6.0有強大的數據庫管理功能，我們選用Visual Foxpro6.0來完成這個倉庫管理系統。
第1章 管理信息系統基礎
管理信息系統就是我們常說的MIS（Management Information System），在強調管理，強調信息的現代社會中它越來越得到普及。MIS是一門新的學科，它跨越了若干個領域，比如管理科學、系統科學，運籌學、統計學以及計算機科學。在這些學科的基礎上，形成信息收集和加工的方法，從而形成一個縱橫交織的系統。
1.1 管理信息系統概述
20世紀，隨著全球經濟的蓬勃發展，眾多經濟學家紛紛提出了新的管理理論。20世紀50年代，西蒙提出管理依賴于信息和決策的思想。同時期的維納發表了控制論，他認為管理是一個控制過程。1958年，蓋爾寫到：“管理將以較低的成本得到及時準確的信息，做到較好的控制。”這個時期，計算機開始用于會計工作，出現數據處理一詞。
1970年，Walter T.Kennevan給剛剛出現的管理信息系統一詞下了一個定義：“以口頭或書面的形式，在合適的時間向經理、職員以及外界人員提供過去的、現在的、預測未來的有關企業內部及其環境的信息，以幫助他們進行決策。”在這個定義里強調了用信息支持決策，但并沒有強調應用模型，沒有提到計算機的應用。
1985年，管理信息系統的創始人，明尼蘇達大學的管理學教授Gordon B.Davis給了管理信息系統一個較完整的定義，即“管理信息系統是一個利用計算機軟硬件資源，手工作業，分析、計劃、控制和決策模型以及數據庫的人-機系統。它能提供信息支持企業或組織的運行、管理和決策功能。”這個定義全面地說明了管理信息系統的目標、功能和組成，而且反映了管理信息系統在當時達到的水平。
1.2 管理信息系統的特點
1.2.1 管理信息系統的組成
管理信息系統在企業中的應用存在三個要素，這就是人、計算機和數據。
人是指企業領導者、管理人員、技術人員，以及MIS建設的領導機構和實施機構，他們在系統中起主導作用。MIS是一項系統工程，不是只靠一些計算機開發人員就可以完成的，必須有企業管理人員，尤其是企業領導的積極參與。
計算機技術是MIS得以實施的主要技術。在這些技術中，軟件開發是MIS開發的重點。
第三個因素也不能忽視。企業的管理數據是MIS正常運行的基礎。廣義地說，各項管理制度是MIS建設成功的基礎。試想要計算一臺機床的生產成本，需要按時輸入每個部件、每個零件甚至每個螺釘螺帽的費用，涉及企業的生產車間、采購、庫房、工藝設計和財務等多個部門，必須有一整套管理制度做保證。
1.2.2 管理信息系統的界面特點
在計算機軟件技術中，人機界面已經發展成為一個重要的分支。
MIS人機界面設計一般遵循以下一些基本原則：
1. 以通信功能作為界面設計的核心
人機界面設計的關鍵是使人與計算機之間能夠準確地交流信息。一方面，人向計算機輸入信息時應當盡量采取自然的方式；另一方面，計算機向人傳遞的信息必須準確，不致引起誤解或混亂。另外，不要把內部的處理、加工與人機界面混在一起，以免互相干擾，影響速度。
設計MIS時，針對每一個功能，都要按照“I-P-O”的模塊化思想，使輸入、處理與輸出“涇渭分明”，充分體現人機界面的通信功能。這樣設計出來的程序不易出錯，而且易于維護。
報表打印是MIS必備的功能之一，而且打印之前常常需要計算。計算與打印分開設計，雖然消耗時間，但易于整個MIS系統的維護。
2. 界面必須始終一致
統一的人機界面不致于會增加用戶的負擔，讓用戶始終用同一種方式思考與操作。最忌諱的是每換一個屏幕用戶就要換一套操作命令與操作方法。
例如在整個系統可以以問號圖標表示幫助，以磁盤圖標表示存盤，以打印機圖標表示打印等。
3. 界面必須使用戶隨時掌握任務的進展情況
人機界面應該能夠告訴用戶軟件運行的進度。特別是在需要較長時間的等待時，必須讓用戶了解工作進展情況，如可以設計已經完成了百分之幾的任務進度條等。目前，Windows下的應用軟件無論大小，其安裝程序幾乎均做到了這一點。開發MIS軟件時，這一點很值得借鑒。
4. 界面必須能夠提供幫助
一個優秀的MIS軟件應該提供在線求助功能，甚至提供使用向導，這將給用戶帶來極大的方便。在多媒體環境下，以語音提示作為操作向導，不會干擾屏幕信息，是一個極佳的選擇。
5. 界面友好、使用方便
多數MIS軟件的數據輸入量較大。對于一些相對固定的數據，不應讓用戶頻頻輸入（特別是漢字），而應讓用戶用鼠標輕松選擇。例如，人事管理系統中的“文化程度”是相對固定的數據，其值一般取“小學”、“初中”、“高中”、“大專”、“大本”、“碩研”、“博研”等。錄入這類數據之前，MIS軟件應在相應位置彈出一個列表框，待用戶以鼠標點擊，而不應讓用戶每次都輸入這些漢字。
另外，開發者應編寫一個錯誤實時記錄程序，自動記錄何日、何時、何程序出了何種錯誤。
總之，所開發的MIS在使用過程中，應使用戶的數據輸入量降至最低限度，同時也要減少用戶的干預量。實踐證明，用戶干預愈少，MIS系統的滿意程度愈高。
6. 輸入畫面盡可能接近實際
如果某個電算會計軟件的憑證錄入畫面是表格式的，一屏可錄入多條記錄，而且與實際憑證一模一樣，甚至連顏色都無異，用戶在終端上錄入憑證，仿佛用筆在紙上填寫憑證，以增加人機親和力。
7. 具有較強的容錯功能
誤操作、按鍵連擊等均有可能導致數據誤錄。巧妙地進行程序設計，可以避免此類因素造成的錯誤。例如，錄入學生成績時，我們可以對其范圍進行限定，使用戶無法輸入0～100以外的數據；錄入學生年齡時，不妨根據實際情況將范圍限制在15～20之間。
1.3 管理信息系統的開發
管理信息系統開發方法主要有：結構化生命周期開發方法、原型法、面向對象的開發方法等。
1. 結構化生命周期開發方法
目前較為流行的MIS開發方法是結構化生命周期開發方法，其基本思想是：用系統的思想和系統工程的方法，按用戶至上的原則，結構化、模塊化地自上而下對生命周期進行分析與設計。
用結構化生命周期開發方法開發一個系統，將整個開發過程劃分為5個依次連接的階段：
? 系統規劃階段：主要任務是明確系統開發的請求，并進行初步的調查，通過可行性研究確定下一階段的實施。系統規劃方法有戰略目標集轉化法（SST，Strategy Set Transformation）、關鍵成功因素法（CSF，Critical Success Factors）和企業規劃法（BSP，Business System Planning）。
? 系統分析階段：主要任務是對組織結構與功能進行分析，理清企業業務流程和數據流程的處理，并且將企業業務流程與數據流程抽象化，通過對功能數據的分析，提出新系統的邏輯方案。
? 系統設計階段：主要任務是確定系統的總體設計方案、劃分子系統功能、確定共享數據的組織，然后進行詳細設計，如處理模塊的設計、數據庫系統的設計、輸入輸出界面的設計和編碼的設計等。
? 系統實施階段：主要任務是討論確定設計方案、對系統模塊進行調試、進行系統運行所需數據的準備、對相關人員進行培訓等。
? 系統運行階段：主要任務是進行系統的日常運行管理，評價系統的運行效率，對運行費用和效果進行監理審計，如出現問題則對系統進行修改、調整。
這五個階段共同構成了系統開發的生命周期。結構化生命周期開發方法嚴格區分了開發階段，非常重視文檔工作，對于開發過程中出現的問題可以得到及時的糾正，避免了出現混亂狀態。但是，該方法不可避免地出現開發周期過長、系統預算超支的情況，而且在開發過程中用戶的需求一旦發生變化，系統將很難作出調整。
2. 原型法
原型法在系統開發過程中也得到不少應用。原型法的基本思想是系統開發人員憑借自己對用戶需求的理解，通過強有力的軟件環境支持，構造出一個實在的系統原型，然后與用戶協商，反復修改原型直至用戶滿意。 原型法的應用使人們對需求有了漸進的認識，從而使系統開發更有針對性。另外，原型法的應用充分利用了最新的軟件工具，使系統開發效率大為提高。
3. 面向對象系統開發方法
面向對象（OO，Object Oriented）的系統開發方法，是近年來受到關注的一種系統開發方法。面向對象的系統開發方法的基本思想是將客觀世界抽象地看成是若干相互聯系的對象，然后根據對象和方法的特性研制出一套軟件工具，使之能夠映射為計算機軟件系統結構模型和進程，從而實現信息系統的開發。
1.3.3 管理信息系統的開發過程
管理信息系統的開發過程一般包括系統開發準備、系統調查、系統分析、系統設計、系統實現、系統轉換、系統運行與維護、系統評價等步驟。根據開發系統的大小、復雜、投入、方式、方法等因素的不同，各步驟的要求和內容也不同，用戶需要根據實際情況進行取舍和計劃。
1. 系統開發準備
系統開發準備工作主要包括提出系統開發要求、成立系統開發小組、制訂系統開發計劃等工作。
2. 系統調查
新系統的系統分析與系統設計工作都要建立在對現行系統調查的基礎上，即必須調查現行系統的運行情況、問題等，明確用戶的需求，特別是合作開發和委托開發方式。
調查的主要內容有：
（1）現行系統概況：該組織的發展歷史、目前組織的規模、工作狀況、管理水平、與外界的主要聯系等。調查該項內容的目的主要是為了劃分系統界限、系統與外界的輸入輸出接口等。
（2）組織機構：畫出組織的組織結構圖，弄清組織的行政關系、人員編制、工作范圍、地理位置等，發現不合理問題及新系統啟動后可能對現有組織的影響。
（3）業務流程：按照業務種類的不同和處理時間的先后不同，深入了解現行系統的業務流程，畫出現行系統業務流程圖，并與業務人員反復討論，得到認可。調查中要注意定性與定量相結合，注意人、財、物、信息的流向、規格、頻率、要求以及需要解決的問題等。
（4）報表、數據處理：了解各種統計報表、數據的格式、內容、處理時間及上報時間、頻率、規律，存在的問題，對新系統的要求、希望等并收集各種報表。
（5）問題：現行系統中存在的主要問題和薄弱環節，可以按照嚴重程度分成不同的等級。新系統的建立應能解決大部分問題，并改善薄弱環節。
（6）新系統的功能和目標：了解各級領導和各類業務工作人員對新系統功能的要求，為進一步完善新系統的目標做準備。
（7）其他：如對新系統的各種約束條件，需要說明的其他問題等。
3. 系統分析
系統分析（又稱邏輯設計）是管理信息系統開發的關鍵環節，要求在系統調查的基礎上，對新系統的功能進行細致的分析，并建立一個新系統的邏輯模型。
新系統的邏輯模型由系統數據流程圖、概況表、數據字典、吃理邏輯表達式及有關說明組成。最后要完成系統分析報告（也稱為系統邏輯設計說明書）。系統邏輯模型就像在根據需要建設一座學校前，按照學校教育的層次（初等、中等、高等）、規模、投資、地理環境、技術水平等條件的要求和約束，先由建筑設計院進行設計，保證學校建成后的各種功能得以實現，之后才能進行工程設計和施工一樣。在系統設計階段要做認真、細致的分析、研究工作，避免新系統在功能上存在先天不足或缺陷。
因為新系統模型是建立在對現行系統的分析及要求的基礎上的，所以系統調查工作要進行得深入、細致、全面。用戶可以對新系統的邏輯模型提出意見，雙方經過討論、修改，最后達成共識，并完成系統分析報告（系統邏輯設計說明書），經有關領導審批通過之后，轉入系統設計（又稱系統物理設計）階段。
4. 系統設計
系統設計又稱系統物理設計。系統設計要根據系統分析報告中的系統邏輯模型綜合考慮各種約束，利用一切可用的技術手段和方法進行各種具體設計，確定新系統的實施方案，解決“系統怎么做”的問題。
結構化系統設計是指利用一組標準的圖表工具和準則，確定系統有哪些模塊，用什么方法連接，如何構成良好的系統結構，并進行系統輸入、輸出、數據處理、數據存儲等環節的詳細設計。這一階段的重點是設計好系統的總體結構，選擇最經濟合理的技術手段。系統設計階段的文件是系統設計報告（又稱系統物理設計說明書）。
管理信息系統的開發是一項系統工程，為了保證系統的質量，設計人員必須遵守共同的設計原則，盡可能地提高系統的各項指標（系統可變性、可靠性、工作質量、工作效率、經濟性等）。
5. 系統實施與轉換
系統實施階段的主要工作包括：系統硬件的購置與安裝、程序的編寫（購買）與調試、系統操作人員的培訓、系統有關數據的準備和錄入、系統調試和轉換。
在系統實施階段要成立系統實施工作量到小組，組織各專業小組組長和有關部門的領導共同編制新系統實施計劃。可以應用各種項目管理的軟件和方法進行管理，實行項目經理負責制，保證系統實施工作的順利進行和成功。
硬件的購置和安裝包括計算機硬件、外設、網絡、電源、機房、環境等有關設備的購買、驗收、安裝與調試工作等，這些工作主要由專業技術人員完成。
數據準備與錄入工作主要是指由手工操作轉入計算機處理所需的各種數據的整理、錄入及計算機系統中為新系統所用數據的轉換工作。數據準備與錄入工作要注意數據的準確性，在整理、錄入、校驗等各個環節把好關，為系統的順利轉換打好基礎。
在進行以上各個環節的同時展開人員培訓工作，包括管理信息系統只是的普及教育、新制度的學習、計算機操作訓練等。使所有人員了解新系統的基本功能、新系統對使用人員的要求、建立管理信息系統的目的、管理信息系統的建立可以為組織和個人帶來的幫助和便利、個人在新系統中應該承擔的工作等，是用戶關心、支持新系統的實現。
6. 系統維護和評價
管理信息系統是一個復雜的人機系統。系統外部環境與內部因素的變化，不斷影響系統的運行，這時就需要不斷地完善系統，以提高系統運行的效率與服務水平，這就需要從始至終地進行系統的維護工作。
系統評價主要是指系統建成后，經一段時間的運行后，要對系統目標與功能的實現情況進行檢查，并與系統開發中設立的系統預期目標進行對比，及時寫出系統評價報告。
系統維護與評價階段是系統生命周期中的最后一個階段，也是時間最長的一個重要階段，就像汽車的維護工作好可以延長汽車的使用壽命和提高其使用效率一樣，系統維護工作的好壞可以決定系統的生命周期的長短和使用效果。
第二章 系統設計
2． 1 系統目標設計
系統開發的總體任務是實現企業物資設備管理的系統化，規范化和自動化，從而達到提高企業物資管理的效率的目的。
2．2 開發設計思想
倉庫管理的物資在本文中主要假定都是企業生產所需要的各種設備。進貨時經檢查合同確認認為有效托收以后，進行驗貨入庫，填寫入庫單，進行入庫登記。企業各個部分根據所需要的物資設備總額和部門生產活動需要提出物資需求申請。計劃員根據整個企業的需求開出物資設備出庫單，倉庫管理員根據出庫單核對發放設備。設備使用完畢需要及時歸還入庫，填寫入庫單。根據需要按照月，季，年進行統計分析，產生相應報表。
倉庫管理的特點是信息處理量比較大。所管理的物資設備種類繁多，而且由于入庫單，出庫單，需求單等單據發生量特別大，關聯信息多，查詢和統計的方式各不相同。因此在管理上實現起來有一定的困難。在管理的過程中經常會出現信息的重復傳遞，單據，報表種類繁多，各個部門管理規格不統一等問題。
在本系統的設計過程中，為了克服以上困難，滿足計算機管理的需要，我們采取了下面的一些原則。
統一各種原始的單據的格式，統一帳目和報表的格式。
刪除不必要的管理冗余，實現管理規范化、科學化。
程序代碼標準化，軟件統一化，確認軟件的可維護行和實用性。
界面盡量簡單化，做到實用、方便，盡量滿足企業中不同層次員工的需要。
建立操作日志，系統自動記錄所進行的各種操作。
2．3 系統功能分析
本人中的倉庫管理系統需要完成功能主要有一下幾點。
倉庫管理各種信息的輸入，包括入庫、出庫、還庫、需求信息的輸入等。
倉庫管理各種信息的查詢、修改和維護。
設備采購報表的生成。
在庫存管理中加入最高儲備和最低儲備字段，對倉庫中的物資設備實現監控和報警。
企業各個部門的物資需求的管理。
操作日志的管理。
倉庫管理的使用幫助。
2．4 系統功能模塊設計
在系統功能分析的基礎上，考慮vfp程序編制的特點，得到如圖所示的系統功能模塊圖：
第三章 數據庫設計
3．1 數據庫需求分析
在仔細調查企業倉庫物資設備管理過程的基礎上，得到本系統所處理的時間流程如圖所示：
在本設計中，通過對企業倉庫管理的內容和數據流程分析，設計的數據項和數據結構如下：
設備代碼信息。包括的數據項有設備號、設備名稱。
現有庫存信息。包括的數據項有現有設備、現有數目、總數目、最大庫存、最小庫存等。
設備使用信息。包括的數據項有使用的設備、使用部門、數目、使用時間、出庫時狀態。
設備采購信息。包括的數據項有采購的設備、采購員、供應商、采購數目、采購時間等。
設備歸還信息。包括的數據項有歸還設備、歸還部門、歸還數目、歸還時間、經手人等。
設備需求信息。包括的數據項有需求的部門、需求設備、需求數目、需求時間等。
有了上面的數據結構、數據項和數據流程，就能進行下面的數據庫設計。
3．2 數據庫概念結構設計
這一設計階段是在需求分析的基礎上，設計出能夠滿足用戶需求的各種實體，以及它們之間的關系，為后面的邏輯結構設計打下基礎。
本設計根據上面的設計規劃出的實體有庫存實體、入庫實體、出庫實體、采購實體、還庫實體、需求實體。各個實體的E-R圖及其關系描述如下：
1）庫存實體E-R圖：
3．3 數據庫邏輯結構設計
在上面的實體以及實體之間的關系的基礎上，形成數據庫中的表格以及各個表格之間的關系。
