1、內部管理系統詳細設計方案二。二年七月二十七日設計方案簡介本設計方案是為內部管理程序開發而編寫的，它包括了系統可行性研究，系統模塊設計，模塊的具體流程設計，一些需要進一步討論或者研究的問題，需要的資料與硬件，數據表的定義等。但它沒有包含關于編碼的更多主題。例如編碼的約定，注解的格式等。盡管這些問題對于實現這個系統都是非常重要的，但因為是設計方案它沒有被包括在其中。整個設計方案的大致目錄如下：一內部管理系統項目方案（第2 頁第 20 頁）1 項目開發背景（第 2 頁）2 項目可行性研究（第 2 頁第 6 頁）3 系統的大致模塊劃分（第 6 頁第 18 頁）3 1 市場部 （第 6 頁第 17 頁）

2、3 1 1 系統登陸模塊（第 8 頁）3 1 2 系統設置模塊3 1 3 事件添加模塊3 1 4 事件查找編輯3 1 5 事件參數設置3 1 6 事件跟蹤模塊3 1 7 人事基本管理3 1 8 部門參數設置3 1 9 資料票據管理3 1 10 業務收入統計3 1 11 工資參數設置3 1 12 員工工資管理3 1 133 1 143 2 網管部（第4 3 制作部（第5 數據流圖4 1 市場部業務數據流圖8 頁）8 頁第9 頁）9 頁第11 頁）11 頁）數據加密備份模塊數據庫管理模塊17頁）17頁第 18 頁）19 頁第 20 頁）19頁）11 頁第 13 頁）13 頁）14頁）14頁第 15

3、 頁）15 頁）15 頁）15 頁第 16 頁）（第 16 頁）16頁第 17 頁）4 2 市場部工資數據流圖（第 20 頁）（第 21 頁） （第 22 頁）（第 23 頁第 25 頁）1 上層數據庫設計（第 23 頁）2 市場部數據庫設計（第 24 頁第 25 頁）五項目工作量估算（第 26 頁）內部管理系統項目方案項目開發背景為了提高公司內部管理的效率，所以需要編制一套完整的用于公司內部管理的系統。這樣一個系統可以在整個公司范圍內使用，做到了公司資源的整合與共享。項目的可行性研究1 技術方面：整個系統屬于一個規模比較大的MIS 系統。 盡管其在組織關系上存在著很大的復雜性，繁瑣性，不確定

4、性，但是就整個系統的技術構成上來看，它還是屬于一個數據庫應用類的系統。其基本操作還是對存在數據庫進行添加、刪除、查找、編輯等。所以就單純的數據庫應用來看，暫不存在太大的技術問題。2 經濟方面：由于系統對公司的正常運行的影響是相當大的，所以必須要設置單獨的服務器來運行這個系統。又考慮到所有計算機硬件軟件都是存在出錯可能的（具體到這個系統，由于其需要不間斷的運行，所以其出錯的可能就會變得更大），因此整個系統應該考慮使用雙機熱備份技術。使用兩臺服務器同時運行，一個為主一個作備份，這樣可以避免服務器故障對整個系統的影響。又考慮到這個系統是為公司內部服務的，而且數據庫設置和調試時候都必須要直接使用服務器

5、，所以應該將服務器設置在公司內部?？v觀整個系統需要的硬件，我們認為整個項目的投資將可能是比較巨大的。這方面，提請公司再作詳細討論。3 法律方面：整個系統由于是自行開發，自行使用，所以系統本身不存在法律上的版權爭議。在服務器軟件方面，應該使用正版軟件，因為整個系統盡管是開發給內部使用，但它畢竟很多部分還是要依靠 Internet 的，一旦服務器連接到Internet 上，它的操作系統可能會被Microsoft 跟蹤，如果不是正版軟件，將不得不面臨民事訴訟的風險。4 目前存在的問題：目前我們覺得最大的問題仍然是數據庫訪問方式上的問題。和一般的MIS 系統不同，我們面臨著更廣泛范圍內的數據庫訪問。這

6、個范圍已經不可能用局域網解決了，但一旦使用Internet 網，數據傳輸的有效性和安全性就會成為嚴重的問題?，F在將三種可能數據訪問的方式列舉如下，并逐一作分析：a使用純單機版的數據庫系統這是最簡單的數據庫訪問方式。采用這種方式不涉及網絡傳輸，所以無論在哪個部門，也不管其上網設施是如何的，總能采用這種方法的。采用這種系統后，如果要實現數據同步，必須定期將數據庫全部上傳（注意：這里應該是上傳整個數據庫，因為采用這種方式操作的系統，它上傳的時間間隔一般是比較大的，如果記錄哪些記錄是更新的，在實際同步時候，將花費很多時間作整個更新記錄的比對，在記錄量增大時候，這個檢測的時間也會急劇增加，反而增加了處理

7、時間），服務器在收到整個數據庫后，在服務器端運行一個特殊的軟件，用于數據的同步。然后將處理后的數據庫放在一個特定的區域，客戶端可以將處理后的數據庫收下來，以實現數據庫同步。整個系統采用的傳輸示意圖如下（僅以市場部為例）：總部服務器上應該運行特定軟件用于數據同步，此過程可能 需要人工干預。總部服務器DBDB這段傳輸可以采用任何傳輸方式，包括FTP, Email市場部b.采用純網絡數據庫的結構:采用這個結構從理想的角度來看，是最適合這個系統的。因為它具有最好的實時性，可 以將當前獲得的數據立即傳輸出去，這樣其他部門也就立即可以得知目前的業務情況。而且 采用這個結構，從數據庫應用角度來看，對網絡底層

8、的傳輸情況不需要有太多的了解（這部分由SQLServer提供的網絡傳輸協議保證）。但是就公司目前各市場部上網情況來看，由于 很多市場部采用的仍然是 Modem和ISDN,不能24小時在線，因此再不對目前各市場部上 網設備改造的情況下，很難使用這種結構。這種結構還有一個問題是它很大程度上依賴于中 心數據庫，對中心數據庫可靠性和穩定性的要求相當高。這種結構的示意圖如下（以市場部為例）：C.采用本地數據庫和網絡數據庫同時使用的結構這是這個系統最有可能采用的數據庫結構。它的特點是平時數據存儲在本地數據庫，以 天為單位，讓本地數據庫和總部的一個共享數據庫進行交互，以實現數據的同步。這種方式 的優點是數據

9、因為在本地和網絡數據庫上共存，所以可靠性是比較高的。而且就Modem,ISDN和寬帶共存的情況下使用這種結構也是比較現實的。它的缺點是：在每日用于同步的 數據量大的情況下是無法使用的，另外，即使每天用于同步的數據量并不是很大，但是本地 數據庫或者網絡共享數據庫的存儲量已經很大，這樣再搜索用于需要同步的數據的時間也將 成倍增加。系統在剛投入使用時候可能速度比較快，但是存儲量達到一定程序后，系統運行 速度將會急劇減慢。（根據實驗，當數據記錄條數達到5萬條以上時，完整的數據庫搜索花費的時間會很長很長），而在這種系統結構下，為了保持兩者數據庫的完全同步，可能要反 復搜索數據庫。此段時間的開銷是相當大的

10、。除此之外，這個結構最大的問題是：如何保證數據的完整同步。因為諸如Modem等上網設備，其傳輸過程極易由于外界干擾或者線路傳輸速率的突變造成傳輸中斷。重傳這些數 據可能會造成數據的重復。（比如經過檢測，這次需要上傳10條記錄，現在客戶端開始上傳， 上傳一半 Modem斷線了，所以實際只傳了五條。客戶端檢測到這一錯誤，開始重傳，但實 際上盡管斷線仍然有五條記錄是成功傳送的，重傳全部必定造成重復，但是要很準確的定位 具體是在那條中斷是相當困難的。這和網絡傳輸協議里錯誤檢測是類似的）采用這個結構的示意圖如下：介于以上原因，我們認為選用何種數據庫結構需要進行進一步研究?？梢宰饕幌聦嶒?，比如使用各種現有

11、的上網設備來進行一下數據庫連接。測試在不同的數量情況下，對性能的影響。特別要對Modem連接SQLServer作更多的實驗。因為其連接速度比較慢，必須要對數據庫連接超時時間 作調整。（此值過小或者過大都會對性能造成影響。過小的值可能會使使用Modem的機器無法連上SQLServer,過大的值在確實發生錯誤時候，需過很多時間才能檢測到此錯誤）1這里的結構和示意圖a）中的結構看上去有些相似。但其原理是完全不同的。圖a）中，需要上傳的是完整的數據庫，它依靠運行在服務器端的程序對數據進行整理以達到同步的目的。而這個結構中，實際上并不存在一個文件上傳的過程，它 是依靠數據庫訪問接口來直接實現數據交互的。

12、數據庫訪問接口屏蔽了很多網絡的細節。在這個結構中，在服務器上不需 要再單獨運行管理程序來實現數據同步。系統的大致模塊劃分由于整個系統最后使用的結構還沒有最后確定，所以這里的模塊劃分只是一個大致的劃分。在經過實驗，確定使用哪種數據庫結構后，需要對此部分進行進一步修正。1 市場部從最大的方面市場部管理系統可以劃分成業務管理、人事管理、財務管理、數據統計與備份、系統設置等模塊。其中業務管理模塊包括事件記錄添加、事件記錄修改，事件記錄刪除、事件提醒等功能。這部分側重的是對客戶服務的，它是以客戶為中心開展的。是整個系統數據的入口處。在人事管理和財務管理等模塊中，有很多數據是要依靠業務管理模塊的。人事管理

13、模塊指對分公司內部人員的管理，包括用工、退工、員工平時所領取資料、合同等其他憑證的管理與查詢。這里要注意各種憑證領取時候的記錄；在憑證丟失時候的處理。這些憑證都是由業務產生的，所以其與業務管理模塊之間存在很多相互訪問的情況。由于存在這個特性，所以必須要做好數據保護，以防止數據交叉訪問時候對原先數據的破壞。財務管理模塊是用于市場部內部工資結算的。由于市場部工資很大部分是有業務員的業績決定的，所以其在很大程度上也是依賴于業務管理模塊的。它就是根據業務管理模塊的統計結果，再利用一定的算法來計算業務員當月的工資和市場部管理人員當月的工資。這部分繁瑣的地方在工資結算方法和各分公司之間算法的差異上，盡管可

14、以設置一些可選項，但如果差異過分懸殊則可能需要為有些分公司編寫單獨的處理模塊。數據統計功能依賴于業務管理模塊和財務管理模塊，它按照一定的時限生成各種業務報表供公司內部留存、上交等。 除了打印出來的報告外，程序應該提供一定的界面供數據查閱（不打?。浞菔撬蠱IS 系統都應該具備的，盡管數據安全可靠存儲大部分應該由服務器來保證，但是程序中仍然應該具備數據備份功能，用于數據定時的導入導處?；蛘吲c其他程序交互時候可以使用。系統設置模塊用于對程序進行初始設置。這部分應該盡量考慮到可擴展性。對于能夠進行設置的部分在此處應盡量設置設置選項。當然，調整只能在一定范圍內進行，一般是數值上或者選項組合上的。由

15、于系統設置對于系統的運行是起全局影響的，所以再調整前要進行安全性驗證。整個市場部程序模塊示意圖如下：（本圖僅供參考）市場部管理程序系統登陸模塊系統設置模塊業務管理模塊人事管理模塊財務管理模塊事件添加模塊事件查找編輯事件參數設置事件跟蹤模塊人事基本管理部門參數設置資料票據管理業務收入統計工資參數設置員工工資管理注：這里的資料票據 管理模塊被放在人 事管理模塊下面了， 主要是處于以下考 慮：資料票據總是由 特定的業務員領取 的，它需要不斷的與 人事數據庫交互，放 在人事里面可以減 少交叉訪問帶來的 開銷。范里一個粗的雙箭頭表示這些數據庫訪問之間將有頻繁的交互各模塊的功能解釋與數據表之間的對應關系：

16、1 .系統登陸模塊：a.含義解釋：用于市場部合法身份的驗證，使用加密密碼驗證方式。b.相關數據表：上層數據表(1)c.流程：d.其他說明：密碼信息應進行加密存貯。加密方式不用過于復雜，可以使用ASCII碼移位變換的方法。2 .系統設置模塊：a.含義解釋：系統設置模塊是對系統的一些運行參數進行調整。它可以分為兩部分，一是為 了適應不同的網絡傳輸而進行的機器系統參數設置，二是對本市場部的一些個性化經營方式 進行的設置，它偏向于業務。比如說套餐價格，限價等。這些數值都會有默認值，并且允許 在運行時候，通過其他部分，比如財務管理，人事管理，業務管理等操作界面里進行分別設 置。但由于其代碼的重用性，這里

17、保留了一個入口，可以對這些參數進行全面的調整，這樣 不用分別進入每一個界面調整了。這種調整方式通常只在程序第一次運行時候才需要。b.相關數據表：市場部數據表(1) (2) (3) (16) (17) (19) (20) (21)c.其他說明：在具體設計時候，對有邏輯聯系的部分應結合在一起，使界面做到直觀，簡化,并且這些調整數值應該是要立即生效的，所以要采用直接的方式，不然如果需重啟程序甚至 重啟windows才能生效，那么會帶來很多麻煩。3 .事件添加模塊：a.含義解釋：事件添加模塊是整個系統運行的基礎。整個系統的業務數據都是由這里提供的。這里錄入的事件信息包含兩部分，一是業務相關客戶信息，二

18、是業務信息本身。它同時也 存在兩種可能性，一是新客戶，這樣就要同時添加客戶信息與業務信息，二是老客戶新業 務，此時只需要對業務信息進行增加就可以了。但不管是何種方式，這里都提供了一個統 計的入口一一從查找客戶開始，以確定客戶信息是否存在。b.相關數據表：市場部數據表(1) (2) (3) (4) (5) (6) (7) (8) (9)c.流程：事件添加應該以客戶查詢作為整個事件添加的開始。以查詢結果作為添加或者編輯的依據。 整個過程可以用以下流程表示：d.其他說明：按照這個流程，對于第一次在我們這里開辦業務的客戶，需要同時錄入客戶資料以及事件（業務）資料，而對于老客戶來說，其客戶資料已經存在，

19、所以只要錄入事件（業務）資料就可以了，但在錄入前應該將原先資料顯示一遍，這樣比較符合軟件設計慣例與用戶操作習慣。4 .事件查找編輯：a.含義解釋：這一模塊實現了對現有事件的查找和對輸入有錯并且已經添加的資料的編輯。 查找分為兩種信息的查找，一是客戶資料的查找，二是業務資料的查找。當然這兩種查找 模式會有交叉，比如，查到某一客戶后，希望查看這個客戶的所有我們對其開展的業務情 況，或者，查到某一業務資料后，需要列出這個業務所對應的客戶資料，因此在設計時候, 要考慮到這些方面，在代碼重用和靈活性上要作好調整。另外此處的編輯是出于這樣一種 考慮的，在有些數據輸入時候有錯，但并沒有立即發現，隔了一段時間

20、后，通過查找或者 突然記起發現了這個錯誤，那么這里就要提供一個功能，允許用戶修改原先的客戶資料或者業務資料。b.相關數據庫：市場部數據表(1) (2) (3) (4) (5) (6) (7) (8) (9)d.其他說明：這里的查找以及顯示流程應該是很清楚的，但要對編輯功能做一下說明。整個 流程里面似乎沒有出現編輯部分，我們的考慮是將編輯功能融合在顯示的時候，顯示的時 候用戶就可以進行編輯，顯示界面下面有一個修改確認按鈕，這樣用戶按下這個按鈕時候，編輯過程就完成了，這樣一個操作方式在其他工程里面已經被普遍采用了，經過幾個項目 的考察與用戶那里得到的反饋來看，這一操作方式被認為是最符合修改這一功能

21、操作習慣 的，而且也是最直觀的。對于程序設計人員來看，它由于將顯示與編輯界面復用了，有效 的控制了由于界面過多而帶來的混亂。5 .事件參數設置：a.含義解釋：通過這個模塊，各市場部可以設置一些關于業務有關的數據，包括市場部能提 供的業務，價格，限價，套餐組合等。b.相關數據庫：市場部數據庫(1) (2) (3)c.其他說明：這個功能是整個系統設置功能的一部分。操作人員可以在這里調整業務有關的參數，也可以在一個總的設置里面調整這些數據，具體使用哪種方式， 則由操作人員根據自己的習慣決定。6 .事件跟蹤模塊a.含義解釋：這個模塊主要用來跟蹤一筆業務的服務過程。我們可以用它來檢查業務所需資料是否收到

22、，錢款是否收到，票據是否收到，贈品是否給出，合同是否簽訂，是否制作完 成等諸如此類的信息。相對于完整的事件查找而言，它更側重于服務的過程，而不是單純的讓操作人員了解這個事件。事件查找模塊它只能進行一個事件的查找或者編輯，它不帶有對這個事件發展過程進行記錄的過程，而此處的記錄功能則顯得非常重要了。b.相關數據表：市場部數據表(1) (2) (3) (4) (5) (6) (7) (8) (9) (9) (10) (11)上 層數據表(2) (4) (6)c.流程：Some module details:DB Search Operating2.d.其他說明：總的來說，這個模塊的設置是可以讓操作人

23、員方便的了解到一個事件整個的進 展情況（也就是說，它不僅是業務那里的進展，也有制作的進展，業務員可以通過這里知道是否制作完成或者申請成功等消息）7 .人事基本管理：a.含義解釋：人事基本管理模塊包含了人事管理的一些常規操作，包括用工，調動，退工。其中用工，調動和一般的人事管理系統很類似，但是退工部分，由于要處理資料票據的上交，所以有相當的復雜性。b.相關數據表：市場部數據表(12) (13) (14) (15) (16) (17) (18) (19) (20) (21) c.流程：d.其他說明：這部分相關數據表里面有幾張是財務部分的，在這里引用它是因為如果出現部門的撤并，將牽涉到計算底薪， 提

24、成時候部門見的差異 (因為有可能有的部門要撤銷了，那么財務提成或者底薪計算用到的數據庫就要進行同步更新)8 .部門參數設置a.含義解釋：這個功能是比較簡單的。它設置的是某個分公司的部門名稱與編號。在系統第一次運行時候，會要求用戶錄入這些信息(也可能使用某些默認值)，但以后如果需要調整部門設置，可以在這里進行，也可以在總的系統設置里面進行。這個依據操作人員的習慣 而定。但這里要強調一個問題：部門的調整對于這個部門內所有人員來說都是有影響的。調整一個部門的信息，要對涉及這一調整的所有信息做更新，這點非常非常重要。不然很容易出現系統的不一致。比如部門 A被撤銷了，那么原先屬于部門A的所有成員信息就要

25、作同步調整，否則在讀取員工信息的時候，他們仍然指向A,這個數據顯然是無效的。同時，也要注意部門調整對計算工資部分數據的調整。b.相關數據表：市場部數據表(12)(13)(14)(15)(16)(17)(18)(19)(20)(21)9 .資料票據管理a.含義解釋：這里在資料票據管理指業務員領取資料，發票，合同時候的登記，以及為為了避免遺失而做日常定期檢查提供依據(它可以指出哪個業務員何時領取了何種物品票據，是否用掉，如果用掉是用到哪里去了)b.相關數據庫：市場部數據表( 5) (6) (7) (9) (10) (11) (12) (13) (14) (15) c.流程描述：因為這個過程很難用流

26、程圖來做完整表述，所以，改用文字表示。首先，資料以及所有票據的來源。市場部的資料，票據來源與總公司。對于實物(比如： 書，盤等)可以給它編號，這樣便于跟蹤。對于票據，其本身就帶有編號，所以這里不再 需要自行給它編號。然后，根據業務需要，業務員領取了書、盤等。這些領取的東西都必 須要登記下來，并且記錄領取人的姓名(實際內部操作的是編號)。下面的部分，要與業務管理模塊互操作了。在業務管理那部分里面，有一個事件跟蹤模塊，它會記錄業務員使用 這些票據、資料的情況。無論票據還是其他實物資料，一旦業務員領取后，那些資料要么 在業務員手里，要么已經給客戶了。通過上面所述的流程，我們可以很容易的知道業務員 用

27、掉的資料或者票據。在定期檢查時候，系統可以自動得出業務員用掉的資料票據，這樣很容易得出應該在手里的資料票據。只要把這一個清單和業務員手里的資料、票據相比對,就可以了解是否有遺失情況。d.其他說明：這里提供了一種可以跟票據、資料的方法，但這里只是一種方法，它并不能解 決所有的問題。這里很大部分依賴了事件跟蹤模塊對數據庫操作的結果。但是如何判別業 務員是否真的如他申明的那樣把憑證交給客戶了呢？程序只能按照他所申明的那樣做記錄 (換句話說，程序總是認為這個申明是真實的)。所以通過這個系統只能識別非故意的單據 實物丟失，而識別故意隱匿單據則是管理學和法學的范疇，并不是計算機科學的范疇了。另外，這里的票

28、據是指發票、合同、發行憑證、贈品、其他表單等。對每一種票據的處理方 式可以是類似的。都包含查詢與錄入修改等。10 .業務收入統計：a.含義解釋：這里統計的是每一個市場部業務上面的凈收入，支出等。這些數據是通過業務 管理模塊和財務部分的工資管理模塊得到的。b.相關數據表：市場部數據表(11) (9) (22),上層數據表(7)c.其他說明：這部分需要提供給我們更多的資料，比如現在公司需要統計些什么，統計表的 樣式是怎樣的，如果某些統計方法不是顯而易見的，則需要給出算法。11 .工資參數設置：a.含義解釋：由于每一個市場部， 市場部的每一個部門的工資計算方法都不一樣，所以需要 對一些數據進行設置。

29、這些設置將影響到工資計算。和其他設置相比，這里的設置可能進行的更頻繁一些。所以要對它的效率做一個準確的考慮。和其他所有的設置一樣，這里的所有數值都會有一個初始值。b.相關數據庫：市場部數據表(19) (20) (21) (16)12 .員工工資管理：a.含義解釋：市場部的工資計算方法比較特殊，所以在這一塊里面是有一定麻煩的。對于一般業務員需要考慮的是有沒有底薪，有沒有提成，需不需要繳納三金，與之相關的還有底薪計算方法，提成計算方法等；管理人員除了這些基本工資外，還有管理費，但不同部門 管理費又是不一樣的，所以在具體設計時候要把這些問題都考慮進去。b.相關數據表：市場部數據表(7) (9) (1

30、1) (16) ( 22)c.流程：這部分因為要涉及提成，所以計算方法比較復雜。以下是提成的計算方法：d.其他說明：更具體的計算方法可以參考最后的數據流圖。數據加密備份模塊：在SQLServer里面，本身就有數據加密傳輸 使其在數據庫里面就是加密以后的狀態。當然實際應用時候，可以采用簡單的加這個模塊屬于為了維護數據安全而設置的模塊。功能。這里只對一些敏感的重要的數據進行再次的加密, （既即使不通過網絡傳輸，也無法直接解讀這些數據）密方法，如 ASCII移位等，不要太復雜。而且只對重要的數據，比如財務數據和業務數據進行 保護。數據備份可以按照按日，按月對數據進行備份，以防止數據庫的意外破壞。數據

31、庫管理模塊：數據庫管理模塊完成常規的數據庫錄入查找等功能。它除了數據庫常規操作以外要進行錯 誤檢測和可恢復錯誤的處理。將其單獨成為幾個模塊是為了是上層模塊對數據庫的操作更為簡單和靈活，并提供了一定的可靠性保證。遠程數據同步模塊：設計這一模塊的目的是使上層操作可以這一模塊采用何種同步方式是目前需要討論的問題。與數據遠程訪問完全分離。將來如果改換了數據遠程訪問的方式，那么只需要修改此模塊,這一模塊之上的部分，可以不作改動。2 .網管部網管部程序主要是用來記錄和查詢申請的域名信箱等的情況。相對于市場部程序來說，網管 部程序功能上比較簡單與單一，需要統計的數據較少。需要完成的功能是從共享數據庫中獲取消

32、 息，按照消息內容進行處理（如進行空間設置，設置郵箱等），將處理結果返回共享數據庫。輔助功能如查詢等?？偟哪K示意圖如下：再對這一流程進行一下解釋，網管部的數據都來自于市場部，它是一個被動的執行機構，但它執行 的結果又是必須要返回給市場部的，不然是毫無意義的。比對上面兩張圖，其結構是完全不同的，這是相當自然的，因為一個是模塊圖，而另外一個是業務流程圖。每一個流程環節，需要一些模塊的參與來完成的。簡單的說，流程圖側重了事情的描述或者是編程時候的界面實現，而模塊圖側重于了技術上的模塊劃分，其根本目的是代碼的重用，它只是一個技術層面的劃分。舉個例子，這里“接受本部門信息”就需要數據庫交互模塊的支持，

33、而數據庫交互模塊將調用數據庫查找模塊來具體實現這件事情。而在整個流程結束需要上傳這條數據的時候，仍然需要數據交互模塊，此時交互模塊調用數據查找模塊來定位數據，用數據編輯模塊來將完成情況添加上去。3 .制作部制作部的程序和網管部類似，整個模塊結構也可以參考網管部的，在這里就不再重復。兩者 主要的區別體現在流程控制模塊，這是由兩個部分的業務所決定的。制作部的大致流程如下：對上面的流程圖的說明：首先它仍然是一個業務上的流程，括號里面指出了這個流程時候，對于整個系統所進行的操作。 省略號地方省略了制作時候的具體步驟（這部分是需要制作部提供資料的）對上面的模塊圖（不是流程圖）作一個說明：由于制作部和網管

34、部操作都具有被動性和很多確定性，所以這一部分的管理程序是相對比較簡 單的。其數據庫操作也是比較簡單的，只要能記錄流程、 操作人員和完成的具體工作就可以了。需要說明的是這里的數據添加模塊和數據交互模塊在功能上是有重復的，設計這樣一個結構是從性能考慮上出發的。數據添加功能側重對大批量的直接添加，它側重速度，只提供有限的錯誤控制。 數據交互模塊則進行更完整的數據庫操作，它側重應用功能，應該提供更多的可以供上層調用的函數和錯誤檢測。兩個部門最大的差異是在流程控制上。四.數據流圖市場部業務數據流圖業務員在談成一筆業務、接收到一份資料或接收到一筆款項等可以產生單據或可記錄或可對原先記錄 進行修改的事情后，

35、會自動觸發一個事件，接下來就會觸發一連串的動作。? 業務員將資料交給市場部的文員，文員將此事件資料整理并錄入數據庫后，上傳至數據庫服務器;? 制作部從數據庫服務器上下載制作資料，然后開始制作；? 網管部也從數據庫服務器上下載資料，接下來就按照要求申請域名或是設置郵箱；? 無論是市場部、制作部還是網管部都應該在相應的工作完成后將完成的結果反饋到 數據庫服務器。具體示意圖如下：個不規范的數據流圖，但是為了理解的方便， 就借用了一些不說明：從軟件工程學的觀點來看， 上圖是 規范的元素。市場部工資數據流圖市場部工資計算比較復雜，各分公司市場部的工資結算方法也不大一樣。一、業務員的工資由兩部分組成? 第

36、一部分基本工資（若基本工資不存在則設置為零）? 第二部分 業務提成（根據業務員當月業績來計算）? 第三部分 三金的繳納情況（若三金可以不交則設置為零） 二、管理人員的工資分為三部分? 第一部分? 第二部分? 第三部分? 第四部分數據流圖如下：基本工資（若基本工資不存在則設置為零）業務提成（如果仍兼做業務員的話）管理費（按當月業績來計算）三金的繳納情況（若三金可以不交則設置為零）說明：針對上圖的說明（1） 分公司市場部業務員工資分配情況不盡相同，某些地區市場部的業務員沒有基本工資，則基本工 資按零計算。（2） 管理人員的業務提成設置為零。（3） 對于業務員來說，未考慮到的工資部分或者某些額外獎勵

37、可以歸入業務提成；對于管理人員來說,未考慮到的工資部分或者某些額外獎勵可以歸入管理費。內部管理系統所需資料一：市場部I 公司的網站套餐清單及價目表2套餐清單中，每一種套餐具體服務項目及價目，公司可選服務項目清單及價目3市場部內部的部門設置組織圖4市場部內部各部分的具體職責5發票樣張6合同樣張7發行憑證樣張8贈品清單9其它所有表單（如需打印）樣張10人事檔案需要錄入的內容II 工資結算（包括提成的具體計算算法、業績統計方法）12各種票據如果丟失處理方法（如需罰款的，具體罰款數額，或票據注銷方法）13各市場部、計算機及打印機配置情況（具體操作系統、打印機種類（是否噴墨/針打）14各市場部上網設施1

38、5各市場部業務上獨特的地方的清單16市場部需打印報表的清單樣張二：制作部1 部門內組織結構圖2 具體工作流程及工序3 各統計報表清單及樣張三：網管部1 部門內組織結構圖2 具體工作流程及工序3 各統計報表清單及樣張四：補丁程序現有數據庫的字段定義及各字段含義五：其它資料現有各部門之間遞交表單的樣式內部管理系統硬件需求為了保證內部管理系統的穩定高速運行，必須要增加硬件并對現有的硬件進行改造，特提出以下硬件需求。 （注：這里的硬件指一個完整的硬件系統，其部分的包含了對軟件的需求，這些軟件是為了正常運行管理系統所必須配備的）1 對服務器的要求1 服務器的中央處理部件（CPU）建議使用PIII 1G

39、（以上）Xeon處理器芯片。2 服務器內存必須使用服務器專用ECC 內存3 為了保證數據存儲的絕對可靠，硬盤應使用磁盤冗余陣列（RAID 01 ）4 為了防止服務器不可預測的故障，或者服務器的定期維護對公司整個業務造成的影響，所有建議使用兩臺服務器。兩臺服務器應構成雙機熱備份。中間使用WatchDog 電路。這樣的結構可以保證整個系統的長時間不間斷工作，即使在服務器定期維護的時候也可以使用后備另一臺服務器工作。5 服務器應支持熱插拔電源6 服務器必須配備UPS （不間斷電源）。7 服務器應該放在公司內部。不然無法進行程序調試。8 服務器應該必須有固定IP 地址。9 其他性能在經濟條件允許的情況

40、下，應該盡量使用高速穩定的配件。2 服務器上應該配備的軟件1 操作系統：Microsoft Windows 2000 server 或者 Microsoft Windows 2000 Advanced server2 數據庫：Microsoft SQL Server 2000 （ 簡體中文版）3 服務器必須使用專業的防火墻和反病毒軟件。4 除了為了運行必須配備的程序以外，服務器上建議盡量不要安裝其他無關程序，以減少程序的混亂或者程序的意外沖突。5 各其他分公司的操作系統盡量統一。（ Windows 9x 系列或者Windows 2000 系列） 。這樣可以避免管理軟件在出來因為操作系統版本不一

41、致造成的過多的開銷。6 各分公司的機器必須也安裝反病毒軟件和防火墻。以防止網絡上的蠕蟲病毒在整個網絡范圍內的蔓延。7 如果要打印涉及字段比較多的報表，應該配備針式打印機。注： 建議首先把服務器定下來，不然無法進行數據庫定義了。其他內容可以在編制過程中慢慢配上。如果實在不行，可以先用臨時的代替一下，在正式使用時候再作更新。內部管理系統上層數據庫設計數據表定義1、安全性驗證：屬性：部門編號（2） 費里的部門對于市場部或分公司來說就是市場部或分公司編號密碼主鍵：部門編號2、部門編號一名稱數據庫屬性：部門（分公司）編號，主管人員,部門名稱，部門所在地址，聯系電話，Email,備注主鍵：部門編號3、業務

42、員信息數據庫屬性：工上 所屬部門編號（2）,姓名，年齡，職務，報到日期，離開日期，離職原因，日常電話， 手機，BP機，地址，郵編，備注主鍵：工號4、部門一業務信息屬性：業務流水號， 所屬部門編號（2）,遞交部門編號（2）,業務員姓名，業務類型，業務送達時間, 業務應完成時間，備注主鍵：業務流水號5、業務一資料信息屬性：自動編號， 業務流水號（4）,資料名稱，送達時間，遞交人，接收人，是否收到，備注主鍵：自動編號6、業務進程信息屬性：自動編號，業務流水號（4）,目前所屬部門編號（2）,是否完成，完成時間，備注（反饋信息） 主鍵：自動編號7、公司收入條件屬性：部門編號（2）,日期,總收入，總支出主

43、鍵：部門編號，日期內部管理系統市場部數據庫設計.定義實體集1. 公司服務 內容價格數據表按照數據庫設計理論規范，此處不應使用“數據表”這一名稱，實體集并不等同于數據表，但在這里為了表述的方便, 仍然使用了 “數據表”這個名稱屬性：編號，業務名稱,業務簡介，價格，最低限價，備注主鍵：2. 上網套餐 套餐名一所含內容數據表屬性：自動編號，套餐名,套餐編號，服務編號（1）,備注主鍵：自動編號3. 上網套餐最低價格數據表屬性：套餐編號（2）,常規價格，最低限價，備注主鍵：套餐編號4. 客戶信息數據表屬性：客戶編號，客戶名稱,聯系人名稱，聯系地址，聯系電話，聯系郵編，備注主鍵：客戶編號5. 客戶-事件數

44、據表屬性：自動編號， 客戶編號（4）,事件編號（9）,備注主鍵：自動編號6. 事件-服務數據表屬性：自動編號， 事件編號（9）,服務編號（1） （2） 5,是否為上網套餐，備注主鍵：自動編號7. 事件-業務員數據表屬性：自動編號， 事件編號（9）,業務員編號（18）,備注主鍵：自動編號8. 事件-應收資料數據表屬性名：資料編號， 事件編號（9）,資料名稱，資料預備提交方式（文字，照片等），資料類型,備注主鍵：資料編號9. 事件信息數據表：屬性：事件編號，事件簡介,合同價格，合同起始日期，合同終止日期，備注主鍵：事件編號10. 業務員實際收取資料情況數據表屬性：自動編號， 事件編號（9）,收到資料編號（8）,收到資料日期，資料是否完整，資料收到 形式，經手人編號，備注主鍵：自動編號11. 業務員收取錢款情況數據表屬性：自動編號， 事件編號（9