內部管理系統詳細設計方案
二○○二年七月二十七日
設計方案簡介
本設計方案是為內部管理程式開發而編寫的，它包括了系統可行性研究，系統模組設計，模組的具體流程設計，一些需要進一步討論或者研究的問題，需要的資料與硬體，資料表的定義等。但它沒有包含關於編碼的更多主題。例如編碼的約定，註解的格式等。
儘管這些問題對於實現這個系統都是非常重要的，但因為是設計方案它沒有被包括在其中。
整個設計方案的大致目錄如下：
一． 內部管理系統專案方案（第2頁－第20頁）
1． 專案開發背景 （第2頁）
2． 專案可行性研究 （第2頁－第6頁）
3． 系統的大致模組劃分 （第6頁－第18頁）
3．1 市場部 （第6頁－第17頁）
3．1．1 系統登陸模組 （第8頁）
3．1．2 系統設定模組 （第8頁）
3．1．3 事件新增模組 （第8頁－第9頁）
3．1．4 事件查詢編輯 （第9頁－第11頁）
3．1．5 事件引數設定 （第11頁）
3．1．6 事件跟蹤模組 （第11頁－第13頁）
3．1．7 人事基本管理 （第13頁）
3．1．8 部門引數設定 （第14頁）
3．1．9 資料票據管理 （第14頁－第15頁）
3．1．10 業務收入統計 （第15頁）
3．1．11 工資引數設定 （第15頁）
3．1．12 員工工資管理 （第15頁－第16頁）
3．1．13 資料加密備份模組 （第16頁）
3．1．14 資料庫管理模組 （第16頁－第17頁）
3．2 網管部 （第17頁）
3．3 製作部 （第17頁－第18頁）
4． 資料流圖 （第19頁－第20頁）
4．1 市場部業務資料流圖 （第19頁）
4．2 市場部工資資料流圖 （第20頁）
二． 內部管理系統所需資料 （第21頁）
三． 內部管理系統所需硬體 （第22頁）
四． 資料庫設計 （第23頁－第25頁）
1． 上層資料庫設計 （第23頁）
2． 市場部資料庫設計 （第24頁－第25頁）
五．專案工作量估算 （第26頁）
內部管理系統專案方案
一． 專案開發背景
為了提高公司內部管理的效率，所以需要編制一套完整的用於公司內部管理的系統。這樣乙個系統可以在整個公司範圍內使用，做到了公司資源的整合與共享。
二． 專案的可行性研究
1． 技術方面：
整個系統屬於乙個規模比較大的mis系統。儘管其在組織關係上存在著很大的複雜性，繁瑣性，不確定性，但是就整個系統的技術構成上來看，它還是屬於乙個資料庫應用類的系統。其基本操作還是對存在資料庫進行新增、刪除、查詢、編輯等。
所以就單純的資料庫應用來看，暫不存在太大的技術問題。
2． 經濟方面：
由於系統對公司的正常執行的影響是相當大的，所以必須要設定單獨的伺服器來執行這個系統。又考慮到所有計算機硬體軟體都是存在出錯可能的（具體到這個系統，由於其需要不間斷的執行，所以其出錯的可能就會變得更大），因此整個系統應該考慮使用雙機熱備份技術。使用兩台伺服器同時執行，乙個為主乙個作備份，這樣可以避免伺服器故障對整個系統的影響。
又考慮到這個系統是為公司內部服務的，而且資料庫設定和除錯時候都必須要直接使用伺服器，所以應該將伺服器設定在公司內部。縱觀整個系統需要的硬體，我們認為整個專案的投資將可能是比較巨大的。這方面，提請公司再作詳細討論。
3． 法律方面：
整個系統由於是自行開發，自行使用，所以系統本身不存在法律上的版權爭議。在伺服器軟體方面，應該使用正版軟體，因為整個系統儘管是開發給內部使用，但它畢竟很多部分還是要依靠inter***的，一旦伺服器連線到inter***上，它的作業系統可能會被microsoft跟蹤，如果不是正版軟體，將不得不面臨民事訴訟的風險。
4． 目前存在的問題：
目前我們覺得最大的問題仍然是資料庫訪問方式上的問題。和一般的mis系統不同，我們面臨著更廣泛範圍內的資料庫訪問。這個範圍已經不可能用區域網解決了，但一旦使用inter***網，資料傳輸的有效性和安全性就會成為嚴重的問題。
現在將三種可能資料訪問的方式列舉如下，並逐一作分析：
a． 使用純單機版的資料庫系統
這是最簡單的資料庫訪問方式。採用這種方式不涉及網路傳輸，所以無論在哪個部門，也不管其上網設施是如何的，總能採用這種方法的。採用這種系統後，如果要實現資料同步，必須定期將資料庫全部上傳（注意：
這裡應該是上傳整個資料庫，因為採用這種方式操作的系統，它上傳的時間間隔一般是比較大的，如果記錄哪些記錄是更新的，在實際同步時候，將花費很多時間作整個更新記錄的比對，在記錄量增大時候，這個檢測的時間也會急劇增加，反而增加了處理時間），伺服器在收到整個資料庫後，在伺服器端執行乙個特殊的軟體，用於資料的同步。然後將處理後的資料庫放在乙個特定的區域，客戶端可以將處理後的資料庫收下來，以實現資料庫同步。
整個系統採用的傳輸示意圖如下（僅以市場部為例）：
b． 採用純網路資料庫的結構：
採用這個結構從理想的角度來看，是最適合這個系統的。因為它具有最好的實時性，可以將當前獲得的資料立即傳輸出去，這樣其他部門也就立即可以得知目前的業務情況。而且採用這個結構，從資料庫應用角度來看，對網路底層的傳輸情況不需要有太多的了解（這部分由sqlserver提供的網路傳輸協議保證）。
但是就公司目前各市場部上網情況來看，由於很多市場部採用的仍然是modem和isdn，不能24小時**，因此再不對目前各市場部上網裝置改造的情況下，很難使用這種結構。這種結構還有乙個問題是它很大程度上依賴於中心資料庫，對中心資料庫可靠性和穩定性的要求相當高。
這種結構的示意圖如下（以市場部為例）：
c．採用本地資料庫和網路資料庫同時使用的結構：
這是這個系統最有可能採用的資料庫結構。它的特點是平時資料儲存在本地資料庫，以天為單位，讓本地資料庫和總部的乙個共享資料庫進行互動，以實現資料的同步。這種方式的優點是資料因為在本地和網路資料庫上共存，所以可靠性是比較高的。
而且就modem，isdn和寬頻共存的情況下使用這種結構也是比較現實的。它的缺點是：在每日用於同步的資料量大的情況下是無法使用的，另外，即使每天用於同步的資料量並不是很大，但是本地資料庫或者網路共享資料庫的儲存量已經很大，這樣再搜尋用於需要同步的資料的時間也將成倍增加。
系統在剛投入使用時候可能速度比較快，但是儲存量達到一定程式後，系統執行速度將會急劇減慢。（根據實驗，當資料記錄條數達到5萬條以上時，完整的資料庫搜尋花費的時間會很長很長），而在這種系統結構下，為了保持兩者資料庫的完全同步，可能要反覆搜尋資料庫。此段時間的開銷是相當大的。
除此之外，這個結構最大的問題是：如何保證資料的完整同步。因為諸如modem等上網裝置，其傳輸過程極易由於外界干擾或者線路傳輸速率的突變造成傳輸中斷。
重傳這些資料可能會造成資料的重複。（比如經過檢測，這次需要上傳10條記錄，現在客戶端開始上傳，上傳一半modem斷線了，所以實際只傳了五條。客戶端檢測到這一錯誤，開始重傳，但實際上儘管斷線仍然有五條記錄是成功傳送的，重傳全部必定造成重複，但是要很準確的定位具體是在那條中斷是相當困難的。
這和網路傳輸協議裡錯誤檢測是類似的）
採用這個結構的示意圖如下：
介於以上原因，我們認為選用何種資料庫結構需要進行進一步研究。可以作一下實驗，比如使用各種現有的上網裝置來進行一下資料庫連線。測試在不同的數量情況下，對效能的影響。
特別要對modem連線sqlserver作更多的實驗。因為其連線速度比較慢，必須要對資料庫連線超時時間作調整。（此值過小或者過大都會對效能造成影響。
過小的值可能會使使用modem的機器無法連上sqlserver，過大的值在確實發生錯誤時候，需過很多時間才能檢測到此錯誤）
三． 系統的大致模組劃分
由於整個系統最後使用的結構還沒有最後確定，所以這裡的模組劃分只是乙個大致的劃分。在經過實驗，確定使用哪種資料庫結構後，需要對此部分進行進一步修正。
1． 市場部
從最大的方面市場部管理系統可以劃分成業務管理、人事管理、財務管理、資料統計與備份、系統設定等模組。
其中業務管理模組包括事件記錄新增、事件記錄修改，事件記錄刪除、事件提醒等功能。這部分側重的是對客戶服務的，它是以客戶為中心開展的。是整個系統資料的入口處。
在人事管理和財務管理等模組中，有很多資料是要依靠業務管理模組的。
人事管理模組指對分公司內部人員的管理，包括用工、退工、員工平時所領取資料、合同等其他憑證的管理與查詢。這裡要注意各種憑證領取時候的記錄；在憑證丟失時候的處理。這些憑證都是由業務產生的，所以其與業務管理模組之間存在很多相互訪問的情況。
由於存在這個特性，所以必須要做好資料保護，以防止資料交叉訪問時候對原先資料的破壞。
財務管理模組是用於市場部內部工資結算的。由於市場部工資很大部分是有業務員的業績決定的，所以其在很大程度上也是依賴於業務管理模組的。它就是根據業務管理模組的統計結果，再利用一定的演算法來計算業務員當月的工資和市場部管理人員當月的工資。
這部分繁瑣的地方在工資結算方法和各分公司之間演算法的差異上，儘管可以設定一些可選項，但如果差異過分懸殊則可能需要為有些分公司編寫單獨的處理模組。
資料統計功能依賴於業務管理模組和財務管理模組，它按照一定的時限生成各種業務報表供公司內部留存、上交等。除了列印出來的報告外，程式應該提供一定的介面供資料查閱（不列印）。備份是所有mis系統都應該具備的，儘管資料安全可靠儲存大部分應該由伺服器來保證，但是程式中仍然應該具備資料備份功能，用於資料定時的匯入導處。
或者與其他程式互動時候可以使用。
系統設定模組用於對程式進行初始設定。這部分應該盡量考慮到可擴充套件性。對於能夠進行設定的部分在此處應盡量設定設定選項。
當然，調整只能在一定範圍內進行，一般是數值上或者選項組合上的。由於系統設定對於系統的執行是起全域性影響的，所以再調整前要進行安全性驗證。
整個市場部程式模組示意圖如下：（本圖僅供參考）
注意各模組的功能解釋與資料表之間的對應關係：
1． 系統登陸模組：
a．含**釋：用於市場部合法身份的驗證，使用加密密碼驗證方式。
超市管理系統可行性研究報告
超市管理系統 可行性分析報告 指導老師 班級 20112014 超市管理系統,它包括訂購管理,倉庫管理,銷售管理等.倉庫管理是其中重要的乙個環節,不容忽視的乙個環節,它在超市的整個 鏈中起著至關重要的作用，如果不能保證正確的進貨和庫存控制和退貨處理，將會導致管理費用的增加，而且整個過程還會癱瘓。而傳...
超市管理系統可行性研究報告
超市管理系統 可行性研究報告 姓名 馮雪君 學號 0791111 報告科目 軟體工程 一 前言 1 可行性研究的目的是為了對問題進行研究，以最小的代價在最短的時間內確定問題是否可解。再經過對此專案進行詳細調查研究，初步擬定系統的實現報告，對軟體開發中將要面臨的問題及其解決方案進行初步設計及合理安排。...
教務管理系統可行性研究報告
一 可行性研究報告 1 1 引言 2 1.1編寫目的 2 1.2專案背景 2 1.3參考資料 2 2 可行性研究的前提 2 2.1功能 效能和要求 2 2.2目標 3 2.3環境條件 3 2.4限定條件 2.5可行性研究方法 3 2.6決定可行性的主要因素 3 3 現有系統的分析 3 3.1處理流程...