淺議銀行管理操作系統開發程序范文

本站小編為你精心準備了淺議銀行管理操作系統開發程序參考范文，愿這些范文能點燃您思維的火花，激發您的寫作靈感。歡迎深入閱讀并收藏。

我國加入WTO后，國家最終將放棄對國有商業銀行提供無限量的信用支持，金融機構必然會在市場經濟的"大海"中按自然規則"物競天擇"。要想在激勵的競爭中立于不敗之地，國有商業銀行必須加快金融電子化的步伐，采取有效措施，迅速建立以決策支持系統為核心的管理信息系統，高效地處理和利用信息，提高信息化水平，增強競爭實力。如何根據開發系統的規模、技術復雜的程度、管理水平的高低、技術人員的素質及開發時間的要求等不同要素，確定管理信息系統開發方法，確保以較小的投入取得最優的效果，這一直是管理信息系統開發人員所關注的課題。筆者根據開發實踐，將管理信息系統的開發方法，歸納為以下幾種： 

一、周期法該方法是由結構化系統分析和設計組成的一種管理信息系統開發方法，結構化生命周期法的開發過程亦稱結構化生命周期法。其基本思想是將系統的生命周期劃分為系統調查、系統分析、系統設計、系統實施與轉換、系統維護與評價等階段。應用系統工程的方法，按照規定的步驟和任務要求，使用一定的圖表工具，完成規定的文檔，在結構化和模塊化的基礎上進行管理信息系統的開發工作。結構化生命周期法的開發過程一般是先把系統功能視為一個大的模塊，再根據系統分析設計的要求對其進行進一步的模塊分解或組合。基本做法如圖1所示。結構化生命周期法主要特點是：

⑴開發目標清晰化。結構化生命周期法的系統開發以"用戶第一"為目標，開發中要保持與用戶的溝通，取得與用戶的共識，這使管理信息系統的開發建立在可靠的基礎之上。

⑵工作階段程式化。結構化生命周期法每個階段的工作內容明確，這便于開發過程的控制。每一階段工作完成后，要根據階段工作目標和要求進行審查，這使階段工作有條不紊，也避免為以后的工作留下隱患。

⑶工作文件規范化。結構化生命周期法每一階段工作完成后，要按照要求完成相應的文檔報告與圖表，以保證各個工作階段的銜接與系統維護工作的便利。

⑷設計方法結構化。結構化生命周期法采用自上而下的結構化、模塊化分析與設計方法，使系統間各個子系統間相對獨立，便于系統的分析、設計、實現與維護。結構化生命周期法被廣泛地應用于銀行管理信息系統的開發中。該方法適合于銀行業務工作比較成熟、定型的系統，如作為銀行管理信息系統信息采集的自助銀行、企業銀行、電話銀行、銷售點服務系統、多媒體查詢系統等為客戶提供金融服務、信息咨詢的系統。在管理系統開發方式上，銀行根據系統的復雜程度以及自己的人力、資金等狀況，可在獨立開發、合作開發、委托開發、購買現成軟件這四種模式中選擇其一。

二、原型法該方法是一種根據用戶需求，利用系統快速開發工具，建立一個系統模型，在此基礎上與用戶交流，最終實現用戶需求的快速管理信息系統開發方法。原型法開發過程包括系統需求分析、系統初步設計、系統調試和系統轉換、系統檢測與評價等階段。用戶僅需在系統分析與系統初步設計階段完成對應用系統的描述，開發者在獲取一組基本需求定義后，利用開發工具生成應用系統，快速建立一個目標應用系統的最初版本，并把它提交給用戶試用、評價、根據用戶提出的修改補充，再進行新版本的開發，反復這個過程，不斷地細化和擴充，直到生成一個用戶滿意的應用系統。原型法的開發過程如圖2所示。 目前,我國市場上的管理信息系統快速開發工具有：POWERBUILDER、VISUALBASIC、VISUALFOXPRO、DELPHI等。利用這些面向對象的開發工具，可使開發者的精力和時間集中于分析應用問題及抽取反應應用系統實質的事物邏輯上，而不再拘泥于應付處理繁瑣的開發實現細節，節省了大量的編程工作，并且使系統界面美觀，功能較強。原型法具有開發周期短、見效快、與業務人員交流方便的優點，被廣泛地應用于銀行的財務報表系統、信貸管理系統、工資人事管理系統、固定資產管理系統等的開發中。

三、綜合法綜合法是將周期法和原型法兩者結合使用，采用結構化生命周期法的設計思想，在系統分析與系統初步設計上采用原型法作出原始模型，與用戶反復交流達成共識后，繼續按結構化生命周期法進行系統詳細設計及系統實施與轉換、系統維護與評價階段的工作。綜合法的優點是它兼顧了周期法開發過程控制性強的特點以及原型法開發周期短、見效快的特點。商業銀行在管理信息系統開發中，可針對不同的實際情況，合理采用綜合法，使開發過程更具靈活性，往往會取得更好的開發效果。

四、實例今年上半年筆者采用原型法，開發了交通銀行南通分行計劃信息管理系統，下面就以該系統為例具體介紹一下原型法的主要開發過程。

（1）系統需求分析、系統初步設計。通過與計劃處交流，明確了本系統的設計目標，即通過對財會處人民幣和國外部折美元會計月報表、資產負債表、損益表及計劃處信貸收支表數據進行收集、存儲、檢索、傳輸、加工、分析，為計劃處及其它管理部門的科學決策服務。并根據確定的設計目標初步完成系統基本數據流圖、主要功能模塊圖、網絡結構圖的設計。

（2）系統模型的確定。為實現不同部門間信息資源的共享，本系統的基本模式設計為典型的Client/Server體系結構，在分行計劃處設立數據庫服務器，作為數據處理中心，計劃處及其它管理部門的客戶機，通過局域網與服務器相連，進行操作。Server端采用Sybase數據庫作為數據庫系統，Client端采用PowerBuilder6.5作為開發工具，網絡協議采用TCP/IP的通訊協議。

（3）系統模型的實現。使用面向對象的PowerBuilder6.5設計界面快速且美觀，因此本系統的Client端設計重點不是在界面設計上，而是在提高系統的通用性上。由于計劃處報表統計條件改變頻繁，這給生成報表數據帶來一定的難度。本系統設計上采用?quot;參數表驅動法"，使數據與程序相分離，即基于通用報表結構的報表程序，極大地減輕了報表的編程工作量。Server端設計主要是建立帳務類、字典類、控制類系統數據庫表。

（4）用戶審核。將本系統的最初版本提交給計劃處使用，筆者根據計劃處在使用過程中提出的修改意見，不斷完善系統，如此重復，直至計劃處滿意為止。

（5）系統維護與評價。本系統提交給計劃處正式投入使用，為維護方便，筆者建立系統開發檔案，至此，本系統的開發過程基本結束。電子商務網站訪問量的統計南通航運職業技術學院王建華內容提要：作者就電子商務網站建設中的一個實際問題--網站訪問量統計，介紹了電子商務網站訪問量統計信息和方法。關鍵詞：點擊數；頁讀數；訪問人數；訪問量我們的主頁的頁讀數是多少？有多少人在訪問我們的網站？這往往是電子商務網站迫切需要知道的實際問題。遺憾的是，大多數電子商務網站建立初期，往往只考慮網站的內容和版面，并沒有想到某一天會要跟蹤網站的訪問量。當廣告客戶詢問網站的訪問量，想知道有多少人訪問網站，瀏覽網頁時，為跟蹤訪問量忙得疲憊不堪的工作人員往往拿不出令人信服的統計資料。本文就此問題，談談電子商務網站訪問量的統計信息和方法，目的在于拋磚引玉。

一、點擊數和頁讀數Web服務器能記錄它得到的每次請求的信息。對我們有用的請求的信息包括：點擊的日期和時間、主機名、請求、被授權的訪問者的登錄名、Web服務器的反應碼、涉及者、訪問者的useragent、訪問者的IP地址、訪問者的主機名（如果其IP地址可以被翻譯出來）、傳輸的字節數、被訪問的文件的路徑、訪問者發送的Cookies、Web服務器發送的Cookies。上述能收集到的訪問量數據不多，而且得到的信息也不可靠。可用的信息不準確，但不是完全不可用。雖然數據不精確，但仍然可以知道有多少人在用我們的網站。正如我們知道的，用計數器可以很容易地知道有多少點擊數，但對于更精確的分析，我們將不得不存儲得到的點擊數。一個簡單的辦法是把信息存儲在Web服務器的log文件中，然后定期地加載數據庫的br或直接把信息寫到數據庫的br中。點擊是我們的服務器收到的任何文件請求，包括圖像、聲音文件和任何出現在頁面上的東西。如果直接加載數據到數據庫中，我們需要一個已經實現這種功能的Web服務器（如Microsoft腎IS），或需要源代碼。也可以用第三方的API，如Apache的DBILogger。實現了這樣的功能，就可以收集失敗點擊的次數（只需計算狀態碼為4xx的點擊的數量）。頁讀數更準確些，因為它把一頁當作一個整體，而不是它的各個部分。計算點擊數不如計算頁讀數得到的信息量大，而且點擊數計算的結果與其它網站很難進行比較。頁讀數就不同了：按時間塊的頁讀數，可以查看每5分鐘的頁讀數變化；按訪問者的域名分類的頁讀數，可以確定他們是在工作時，工作前還是工作后訪問我們的網站；按登錄用戶的頁讀數和非登錄用戶分類的頁讀數，可以確定允許用戶登錄是否值得；按信息來源分類的頁讀數，可以確定訪問者進入頁面是通過一個連接還是一個旗幟廣告？他們從哪里來？這些信息可以幫我們了解訪問者的興趣，可以確定往哪兒投資，與哪些人合作；按訪問者的硬件平臺、操作系統、瀏覽器及其平臺統計的頁讀數，可以確定Mac用戶和PC用戶的比例各為多少？Netscape和IE的用戶各為多少；按訪問者主機統計的頁讀數，可以確定訪問者中有多少人用AOL？有多少人用Earthling?總之，頁讀數的統計，也就電子商務網站訪問量的統計鼻子

二、頁讀數的統計為了計算頁讀數，需要制定一些把頁讀數從點擊數中區分出來的方法。下面是電子商務網站經常考慮到的一些因素：文件名、文件類型（HTML、GIF、WAV等）、Web服務器的反應碼、訪問者的主機。一旦確定了哪些點擊是頁讀數，哪些不是，就可以計算網站的頁讀數了。我們按照文件的路徑確定頁讀數算在哪個具體部分，如/web/99/13/index0a.html算做Web的頁讀數；則算做Sys的頁讀數。如果這種標準在網站的各個層次上實行，可以得到網站的詳細統計。我們有時希望把一個頁讀數算在某一部分，在其它部分算在另一部分。電子商務網站頁讀數的統計方法通常有如下幾種。

1．遠程數據跟蹤頁讀數增長的速度是多少？年底的時候我們期望的頁讀數是多少？網站的哪部分頁讀數增長得最快？哪部分最慢？各種瀏覽器的比例隨著時間變化的趨勢是怎樣的？人們過多久訪問我們的網站一次？從其它網站的旗幟廣告第一次進入我的網站的人，他們隨后讀了多少頁？一旦我們看到可用的各種類型的信息，我們就會得到需要長距離回答的各種問題。如果我們對回答這些問題感興趣，那么多天的跟蹤就會有用。進行遠程數據跟蹤，可以考慮使用數據庫。我們可以編寫程序從點擊數日志中提取想要的信息。如果數據庫設計得合理，查詢信息的時間比用程序從日志文件中提取信息快好多倍。數據量越大，這種差別越明顯。如果只存儲感興趣的點擊，可以節省大量的數據空間。也可用SQL從數據庫中提取數據。SQL是一種小型的、簡練的只需學很少的命令和語法的語言。而且，其命令結構簡單明晰，好的程序員建立一個SQL查詢比編程做同樣的事快得多。而且其結果錯誤更少，更容易理解。如果不想用SQL，可以用一種數據庫訪問工具如MSAccess或Excel。這些工具都很好用，而且是圖形界面。

2．計算訪問時間電子商務網站的市場部和廣告部都喜歡統計訪問時間，即某人在離開我們的站點前停留了多長時間。但是，用HTTP是不可能確定這個數值的。假設一個客戶在正午時訪問Hot的一個頁，然后該客戶在12:28p.m.訪問Hot的另一頁，那么該客戶對Hot的訪問時間是多長呢？該客戶可能在這28分鐘內一直盯著第一個Hot頁，但是該客戶也可能在這28分鐘內新開了一個窗口，瀏覽另一個網站。但是，我們的用戶確實需要這種信息，那么該怎么告訴他們呢？我們可以去InternetAdvertisingBureau，它定義了一個訪問為"沒有連續30分鐘的不活動的訪問者的一系列頁面請求"。當有人問起我們的網站的訪問時間時，我們也可以在IAB的定義的基礎上告訴他們。

3．計算訪問來源如果訪問者點擊某個連接或某個旗幟廣告到達我們的網站，他的瀏覽器會隨著這個請求發送他剛離開的站點的URL，這個URL稱為"referer"。Netscape和IE對訪問的來源的處理方式不同。如果我們點擊原始頁到一個有frame的頁，Netscape將把原始頁作為對包含frame的頁和每個frame中的頁的來源；IE把原始頁作為包含frame的頁的來源，這個包含frame的頁反過來把它本身作為各個frame頁的來源。進一步，我們可能還會得到每頁的頁讀數的數據。如果把網站分成頻道或部分，則可能得到每部分的數據。需要注意的是，上述方法計算出的頁讀數不是我們的網站的實際頁讀數。這是因為我們統計的是在Web服務器的訪問日志中計算訪問記錄，而很多請求從不在訪問日志中留下痕跡。因為沒有十全十美的方案，所以使用哪種統計方法取決于網站的實際情況。

三、計算訪問人數計算訪問人數比計算頁讀數難得多，而且沒有絕對可靠的計算訪問者人數的方法。基本上有三種信息可以用來跟蹤訪問者：IP地址、成員名（如果網站使用成員注冊）和cookie。最簡單的辦法是計算log文件中的唯一IP地址的數量。但是，最容易的辦法通常不是最好的辦法。這種方法是可用的最不準確的辦法。大多數人在每次連接時得到不同的IP地址。這是因為很多ISP為用戶賦予動態的IP地址，例如，當一個AOL用戶上網時，AOL給他一個IP地址，當他斷開連接時，AOL把這個地址賦給另一個用戶。這樣，當我們進行統計時，我們不知道這是兩個用戶。如果要求用戶使用成員身份登錄，統計將很容易和準確。但很多人不喜歡需要登錄的網站，這就使得跟蹤成員名的統計沒有實際意義。最后，可以使用cookies。為每個訪問者定義一個包含唯一值的cookie，我們把它稱為機器ID。如果某人訪問我們的網站時沒有提供機器ID（可能她是第一次訪問，或者她的瀏覽器不接受cookies），把她當作新用戶，并為她訪問的頁發送一個cookie。使用這種方法要注意的是：

1．很多人關掉了cookies的功能；

2．可以用瀏覽器刪除舊的cookies；

3．cookie存儲在訪問者的機器上（訪問者可能用不只一臺機器訪問我們的網站）；

4．多人公用一臺機器；

5．服務器對cookies的處理不同。考慮到以上因素，我們在電子商務網站這樣做：如果計算一天的訪問者數量，我們計算成員名；對于沒有成員名的點擊，我們計算cookies；對于既沒有成員名，也沒有cookies的點擊，我們計算IP地址；如果計算多天的訪問者數量，我們只用cookies；如果只關心某一天的數據，可以用處理log文件的程序，如果希望得到多天的數據，應該把它存儲在數據庫中。如果不能準確記錄每個單一請求，當然就不能得到網站的訪問者的完整數量。前面沒有討論的一個問題是cookie和新的訪問者。假設我們想計算昨天的訪問者人數，就要用我們前面討論的方法。當某人第一次訪問我們的網站時，他還沒有cookie，我們的Web服務器隨著被請求的頁發送給他一個新的cookie。現在，假設這個訪問者然后請求第二頁，這時的請求有一個cookie，訪問者的點擊記錄將有一個cookie。當我們用Perl腳本（或別的什么）計算訪問者數量時，如果允許認證，我們首先計算成員名；對于沒有成員名的點擊，可以計算cookie；對于沒有成員名或cookie的點擊，可以計算遠程IP地址。但這種方法重復計算了新的訪問者。一個訪問者的第一次點擊沒有cookie或成員名，所以IP地址被計算在內。這個訪問者的隨后的點擊將用成員名或cookie計算。在電子商務網站中，我們記錄cookie被發送的次數，雖然我們沒有收到cookie。每一個夜晚，我們尋找包含被發送cookie的點擊。對于每一個，我們檢查等于那個被發送的cookie的被接收的cookie的其它點擊。如果能找到，我們在把這些點擊數裝載到數據倉庫之前把發送的cookie值轉移到接收的cookie的字段。當使用我們的計算方法時，此人將只被計算一次。注意我們不只是簡單地把發送的cookie和接收的cookie進行合并。這么做會重復計算屏蔽cookie的人。假設我們有不止一個計算點擊數的域，例如，和。我們可以計算到和的訪問者數量，但是總數肯定不會與這兩個數的和相等。

為什么會這樣呢？假設一個訪問者訪問，他沒有cookie，于是我們的Web服務器發送一個給他。然后他又訪問，訪問者的瀏覽器不會發送的cookie給的Web服務器。這樣，的Web服務器發送另一個cookie給訪問者，對于一個訪問者有兩個不同的cookie。解決這個問題的辦法是使用一個主域名，如和，這樣可以有一套cookie。