第一篇：基于LPC21 32的U盤軟硬件系統設計概要

基于LPC21 32的U盤軟硬件系統設計

摘要 闡述一個基于ARM7的U盤設計；詳細描述基于LPC2132、USB接口芯片PDIUSBDl2和Flash ROM的硬件系統設計。軟件設計主要包括D12驅動、Mass Storage類協議實現和Flash存儲器的讀寫控制等。關鍵詞 LPC21 32 USB Mass Storage類協議 U盤

引 言

USB移動存儲技術(U盤)把USB接口技術與Flash存儲器技術結合在一起，構成了一種快速、大容量、方便的新型數據交換系統，主要構成有主控制器(MCU)、USB接口芯片和F1ash存儲器。主控制器(MCU)是系統的核心，負責控制各種外圍設備、實現各種算法、協調與主機通信；USB接口芯片負責USB通信；Flash(閃爍存儲器)用來存儲數據，它決定了U盤的容量。硬件系統設計

U盤設計結構框圖如圖1所示。使用Philips公司的ARM7芯片LPC2132，控制Philips的USBl．1接口芯片PDI-USBDl2，處理PMC公司的128 KB串行F1ash存儲器作為數據存儲設備實現U盤。

(1)ARM處理器

LPC2132是基于一個支持實時仿真和跟蹤的16／32位ARM7TDMI-S CPU，并帶有64 KB嵌入的高速Flash存儲器。LPC2132的實時仿真和跟蹤功能方便了代碼的調試，降低了開發成本。(2)PDIUSB012

PDIUSBDl2(簡稱為“D12”)是一款性價比很高的USB器件；通常用于微控制器系統中實現與微控制器進行通信的高速通用并行接口；支持本地的DMA傳輸。PDIUSBDl2所具有的低掛起功耗連同LazyClock輸出可以滿足使用ACPI、OnNOW和USB電源管理的要求。低功耗可以應用于使用USB總線供電的外設。

(3)Flash存儲器

存儲器選用PMC公司的Pm25LV010。適合低功耗和低電壓下工作的應用場合；具有完備的數據保護功能。通過設置芯片的狀態寄存器，可以將存儲空間的高1/

4、高1／2或整片寫保護。寫使能和寫禁止指令進一步保護數據。另外還提供WP引腳用于硬件數據保護，以防止對狀態寄存器的意外修改。

U盤電路原理如圖2所示。軟件設計

軟件設計主要包括D12驅動、Mass Storage類協議和Flash存儲器的讀／寫控制。

2.1 D12驅動的實現

在USB設備插入主機之前，主機對這個USB設備的情況一無所知，無法建立起通信；但USB協議規定了一些最基本的準則，如每個設備的端點0都是可用的，屬于控制端點。有了這個基本的溝通途徑，主機就開始通過端點0向設備提出一些問題，這些問題是有關設備基本情況的。這些基本情況可以反映usB設備所屬的類別及子類，反映配置情況、接口情況和端點情況；一旦得知了這些信息，主機就大體了解了這個設備是個什么樣的設備，按照USB協議中的相應規定，就逐步建立起了一條介于設備之間的高速數據通道，用于數據的傳輸。主機向設備提出的這些問題實際上就是USB協議中規定的各種標準請求，設備必須對這些問題進行回答；而回答的方式就是向主機傳送相應的描述符，即設備描述符、配置描述符、接口描述符、端點描述符。

為了使軟件可移植性強、易維護，采用分層的方法編寫PDIUSBDl2的驅動程序。USB驅動程序分層結構如表1所列。

①硬件提取層(D12HAL．c)包含最底層的函數。

②D12命令接口(D12CI．c)實現PDIUSBDl2的命令接口以簡化器件的編程。該層的甬數及其功能如下：

◇讀取芯片ID號，uintl6 D12_ReadChipID(void)；

◇沒置地址／使能，void D12_SetAddressEnable(UINT8bAddress，UINT8 bEnable)；

◇設置端點使能，void D12_SetEndpointEnable(UINT8 bEnablc)；

◇設置模式，void D12_SetMode(uint8 bConfig，uint8bClkDiv)。

③協議層(Chap_9．c)處理標準的USB設備請求，以及特殊的廠商請求，如DMA等。USB主機通過標準USB設備請求，可設定和獲取USB設備的有關信息，完成USB設備的枚舉。

所有的請求都是通過端點0接收和發送SETUP包來完成的。接收主機SETUP包的函數為ep0_rxdone()，所有SETUP包都由函數control_handler()來處理，發送SETUP包的函數為ep0_txdone()。SETUP包的接收和發送通過控制傳輸結構仝局變量CONTROL_XFER ControlData來控制，它實現了以上3個函數之間的通信。

上述幾個函數及ControlData變量之問的關系如圖3所示。

④應用層(D12Driver．c)實現PDIUSBD12的所有功能。USB設備控制驅動、USB接口控制驅動和協議層都在應用層的控制之中。應用層要實現的仟務包括：

◆初始化PDIUSBDl2。包括初始化PDIUSBD12的硬件連接、復位PDIUSBDl2、配置PDIUSBD12的中斷服務程序地址、初始化應用層相關的全局變量。

◆編寫PDIUSBD12中斷服務程序。PDIUSBD12幾乎所有功能都是通過PDIUSBDl2中斷服務程序來完成的，因此中斷服務程序是應用層的核心部分，也是本驅動程序的核心部分。它要完成以下任務：

◇控制端點數據接收與發送中斷服務程序，負責處理控制傳輸的有關工作；

◇端點1和端點2數據接收與發送中斷服務程序；

◇USB總線掛起、復位、DMA結束中斷服務程序。

◆用戶讀寫端點1和端點2的API函數。

◆傳輸控制處理任務。該任務用于處理枚舉、標準任務請求、廠商請求等傳輸控制。

2.2 Mass Storage類協議的實現

完整的Mass Storage類協議需要實現如下兒部分：在枚舉時，提供Mass Storage類協議描述符；實現BulkOnly批量傳輸協議；實現SCSI命令集。

2.2.1 Mass Storage類協議描述符

USB采用設備類的方式對設備進行管理。要讓主機識別設備，設備就必須提供正確的描述符：

◇設備描述符；

◇配置描述符；

◇接口描述符；

◇端點描述符。

2.2.2 Bulk-Only批量傳輸協議實現

Bulk-Only協議包括兩部分：類特定請求命令和Bulk-Only傳輸。(1)類特定請求命令

①批量傳輸的大容量存儲器復位。要發送批量傳輸的大容量存儲器復位請求，主機將在默認管道發送一個設備請求：

◇bmRequestType——類、接口、主機到設備；

◇bRequest字段設置為255(FFh)；

◇wValue字段設置為0；

◇wIndex字段設置為接口編號；

◇wLength字段設置為O。

批量傳輸的大容量存儲器復位請求如下：

②獲取最大邏輯單元號(專用類清求)。Get MaxLUN設備請求用于確定設備支持的邏輯單元編號。設備的邏輯單元編號可以從LUN為O到LUN的最大值15(Fh)。

要發送Get Max LUN設備請求，主機應在以下默認管道發送一個設備請求：

◇bmRequestType——類、接口、設備到主機；

◇bRequest范圍設置為254(FEh)；

◇wValue字段設置為0；

◇wIndex字段設置為接口編號；

◇wLength字段設置為1。

獲得最大邏輯單元字如下：

設備應返回1字節包含設備支持的最大邏輯單元數。例如，如果設備支持4個LUN，則LUN的編號應從0～3，則返回值為3。如果設備沒有相關的LUN，則返回值為0。主機不應向一個不存在的LUN發送命令塊包(CBW)。

不支持多LUN的設備會返回STALL。(2)Bulk—Only傳輸

Bulk—Only傳輸協議沒有使用中斷和控制端點，僅使用Bulk批量端點來進行命令塊、數據和命令塊狀態的傳輸。控制端點(默認)管道僅用來請求批量端點上的STALL停止的狀態和執行類特定請求命令。

Bulk—Only傳輸的流程如圖4所示。

2.2.3 SCSI命令集實現

SCSI命令集是SCSI設備通用命令集。SCSI有3種字長的命令：6字節、10字節和12字節。Microsoft Win—dows環境下支持12字節長的命令。圖5給出了通用的UFI命令塊的格式。請注意，這些字節就是CBW封包中CBWCB字段的內容。

對不同的命令只需根據SCSI命令集白皮書作出適當的回應。Pm25LV010的最小擦除單位為扇區(4 KB)，故在程序中定義一個4 KB的緩沖區Cache_STRUC Flash-Cache，把每次收到的數據放入緩沖區中，到緩沖區滿數據接收完畢時再將其寫入Flash存儲器中，流程如圖6所示。

2．3 Flash存儲器的讀寫控制

Flash存儲器讀寫程序由SPI控制和Pm25LV010控制兩部分組成。

Pm25LV010 Flash存儲器采用的是SPI串行接口，其SPI有兩種工作模式——模式O和模式3。SPI．c完成SPI底層操作，給Pm25LV010控制程序提供一個讀寫1字節數據函數。該函數使用SPI模式0。

Pm25LV010控制程序完成Pm25LV010器件的所有操作，其向高層提供的函數及功能如表2所列。

Pm25LV010的最小擦除單位是扇區(每扇區4 KB)，在改寫扇區內任意一字節數據時都需要將該扇區擦除。針對這種情況，在程序中定義了一個4 KB大小的緩沖區，當上層調用函數WriteToFlash()向Flash寫數據時，并不直接寫入Flash，而是先寫到數據緩沖區，其流程如圖7所示。結論

基于LPC2132微控制器的硬件平臺上實現了USB驅動、Bulk-Only傳輸協議、SCSI命令集，實現了完整的U盤功能。

第二篇：人事管理系統概要設計說明書范文

概要設計說明書

1． 引言

1．1 編寫目的

在人事管理系統項目的前一階段，也就是需求分析階段中，已經將系統用戶對本系統的需求做了詳細的闡述，本階段已在系統的需求分析的基礎上，該文檔的目的是描述企業人事管理系統項目的概要設計,其內容包括: 系統功能簡介 系統結構設計 系統接口設計 數據設計 模塊設計 界面設計

本文檔的預期的讀者是：

XX有限公司的領導

技術人員

XX有限公司的領導 相關項目組的所有成員

1．2 項目背景

國外企業關于人事信息的管理，主要是利用人力資源方面管理系統來實現的因為這類系統同IT、通信等領域技術的發展存在密切的聯系，因此在計算機、網絡等技術發展相對快的國家，基本上創建了一套人力資源管理系統，人力資源方面的信息能夠在其本國范圍內被授權查閱。無論人才流動到哪里，在人們進行求職、貸款以及辦理保險之時，具備查閱權限的機構都能夠查閱該人的信息，以衡量為該人辦理有關手續的潛在風險，或者是否可以錄用。

1．3 定義

1．3．1 專門術語

C/S：Client/Server客戶機/服務器。

可修改性：容許對系統進行修改而不增加原系統的復雜性。

有效性：軟件系統能有效地利用計算機的時間資源與空間資源的能力。

可適應性：軟件在不同的系統約束條件下使用戶需求得到滿足的難易程度。可移植性：軟件從一個計算機系統或環境搬到另一個計算機系統或環境的難易程度。主鍵：數據庫表中的關鍵域。

1．3．2 縮寫

系統：若未特別指出，統指本機票預定系統。

SQL: Structured Query Language（結構化查詢語言）。ATM: Asynchronous Transfer Mode(異步傳輸模式)。

1．4 參考資料

以下列出在概要設計過程中所使用到的有關資料：

[1]韓萬江 《軟件工程案例教程》機械工業出版社 [2]李金勇 曹軍生，《SQL sever 2000實用教程》，北京理工大學出版社 [3]林鄧偉 等，《JAVA程序設計項目教程》，北京理工大學出版社 [4]孫峰，《數據庫原理及應用》。天津大學出版社 [5]軟件工程文檔編制國際標準：GB8567—88 2． 總體設計

2．1 需求規定

數據庫分析是數據庫管理系統開發周期中的一個重要的階段，也是工作量比較大的一 項活動。隨著現代軟件的發展，手工分析方式已經很難滿足數據庫管理系統數據庫分析的要 求，必須借助相應的工具。

設計數據庫系統時應首先充分了解用戶各個方面的需求，包括現有的以及將來可能增

加的需求。用戶需求具體體現在各種信息的提供、保存、更新和查詢，這就要求數據庫結構 能充分滿足各種信息的輸入和輸出。通過對書店管理工作過程的內容和數據流程分析，設計 數據項和數據結構。

通過與企業的溝通和需求分析，要求系統具有以下功能。1.新員工資料的添加、修改、刪除和查詢。2.部門信息的添加、修改、刪除和查詢。3.自動分配員工編號和部門編號。

4.人事調動的詳細記錄，包括部門、職位和職稱的調整，以及人員離職。

5.添加/修改日常出勤記錄，這里重點實現可按全體員工、部門員工和所選員工添加/修改 日常出勤記錄，以方便用戶操作。員工日常公出/請假信息的添加、修改、刪除和查詢。每月工資信息的批量添加、修改、刪除和查詢。

2．2 運行環境

2．2．1 設備

1．Web服務器1臺 2．數據庫服務器1臺 3．備份服務器1臺 4．開發服務器1臺

5．軟件防火墻服務器1臺 6．千兆路由器1臺

7． 10M網絡寬帶1條

2.2.2 軟件環境

本系統的的軟件環境如下

1.My Eclipese 10開發工具 2．SQL Server2008數據庫系統 3．Windows xp操作系統;4．防火墻，殺毒軟件

2.3 基本設計概念和處理流程

概念模型是對信息世界的建模，所以概念模型應該能夠方便、準確的表示出信息世界 中的常用概念。實體--關系模型（Entity-Relationship Module,簡稱E-R圖）是數據庫結構設計常用的方法。得到了數據項和數據結構以后，就可以設計出能夠滿足用戶需求的各種實體以及它們之間的關系，為后面邏輯結構設計打下基礎。這些實體包含各種具體信息，通過相互之間的作用形成數據的流動。根據需求分析和功能分析，規劃出本系統中使用的數據庫實體分別為員工實體，部門實體，工資實體，出勤實體，公出請假實體，人事調動實體，福利實體，員工離職實體等員工實體包括ID、編號、姓名、性別、身份證號、出生年月、年齡、民族、婚姻狀況、政治面貌、如黨團時間、籍貫、聯系電話和手機號碼等屬性。員工實體E-R圖如圖2.1所示：

部門實體包括部門編號、部門名稱、部門經理、部門地址和部門電話屬性。

部門實體E-R圖如圖2.2所示：。

公出實體包括ID、所屬工資月份、員工編號、員工姓名、基本工資、加班費、工齡工

資、全勤獎、獎勵總額、職務津貼、請假扣除等屬性。工資實體E-R圖如圖2.3所示：

2．4 結構

本系統的實現采用典型的三層模式、B/S結構來實現，不同的客戶端程序共同訪問中心數據庫，系統結構如圖1：

圖1：系統結構

系統基本功能圖解體系基本結構圖

2.5功能需求與系統模塊的關系 各項功能需求的實現同各個塊程序的分配關系：

2.5.1登錄頁面

需要登陸的人員，對于不同的身份，他們的權限是不一樣 的。當用戶輸入ID 和密碼時，查詢數據庫，若用戶名和密

碼正確，則進入相應的員工信息頁面，若不正確，則提示用戶名或密碼錯誤，人顯示當前頁面。

功能描述： 用戶管理 配置管理 數據備份 數據維護 1.2.3.4.2.5.2員工注冊 功能描述：

新員工注冊，輸入員工的注冊信息，包括（登錄賬號，登錄密碼，核對密碼，聯系電話，聯系地址，電子郵箱）。

注冊信息的修改。

用例圖

2.5.3員工的登錄和登出

功能描述：

員工登陸

員工退出 用例圖：

2.5.4信息查詢 功能描述：

查看公司內部相關信息 查看個人信息

查看其他員工的部分信息 用例圖

2.5.5人事檔案

1增加員工檔案信息 2修改員工檔案信息

3刪除員工檔案信息 4查詢員工檔案信息

5打印員工檔案信息 用例圖

2.5.6工資信息管理 功能描述：

1.工資信息模塊

2.計發工資信息

3.查詢工資信息

4.保險/福利

5.打印工資信息 用例圖

2.5.7員工培訓 功能描述：

1.員工培訓模塊主要包括：

2.培訓信息的錄入 3.培訓信息的刪除 4.培訓信息的修改 5.培訓信息的查詢 6.履歷表的打印 用例圖

2.5.8公司招聘

功能描述：

1.錄入招聘信息

2.查詢招聘信息

3.修改招聘信息

4.刪除招聘信息

5.查詢應聘者信息

6.刪除應聘者信息

用例圖

2．6 人工處理工程

創建用戶（注冊新用戶）：用戶信息需要手工輸入計算機。更新部門、員工資料：需要手動輸入更新內容。

2．7 尚未解決的問題

由于數據的傳輸上需要通過網絡傳輸，為了客戶資料進行保密，需要在網絡的傳輸過程中對數據進行加密。

這個工作主要是在準備網絡包，及解開網絡包這兩個模塊完成，它們各對數據進行加密及解密還原工作。

在加密算法選擇上將使用RSA 加密算法。具體算法可參照參考資料中《Computer Network》p.598。

3.接口設計 3.1用戶接口設計

3.2外部接口

3.3內部接口

4．運行設計 4.1運行模塊組合

施加不同的外界運行控制時所引起的各種不同的運行模塊組合如下表所示：

4.2運行控制

5.系統數據結構設計 5.1邏輯結構設計要點

根據設計好的E-R圖在企業人事管理系統中創建各表。

員工信息表用于儲存員工基本信息和單位相關信息，改數據表結構如表2.1所示：

部門表用于存儲部門編號、部門名稱等信息，該數據表結構如表2.2所示。

工資表用于存儲每月每個員工的詳細工資信息該數據表結構如表2.3所示。

6.系統出錯處理設計 6.1出錯信息

程序在運行時主要會出現兩種錯誤：

1、由于輸入信息，或無法滿足要求時產生的錯誤，稱為軟錯誤。

2、由于其他問題，如網絡傳輸超時等，產生的問題，稱為硬錯誤。

對于軟錯誤，須在定票/領票操作成功判斷及輸入數據驗證模塊由數據進行數據分析，判斷錯誤類型，再生成相應的錯誤提示語句，送到輸出模塊中。

對與硬錯誤，可在出錯的相應模塊中輸出簡單的出錯語句，并將程序重置。返回輸入階段。

6.2補救措施

所有的客戶機及服務器都必須安裝不間斷電源以防止停電或電壓不穩造成的數據丟失的損失。若真斷電時，客戶機上將不會有太大的影響，主要是服務器上：在斷電后恢復過程可采用 SQL SERVER 的日志文件，對其進行ROLLBACK 處理，對數據進行恢復。

在網絡傳輸方面，可考慮建立一條成本較低的后備網絡，以保證當主網絡斷路時數據的通信。

在硬件方面要選擇較可靠、穩定的服務器機種，保證系統運行時的可靠性。

6.3系統維護設計

維護方面主要為對服務器上的數據庫數據進行維護。可使用 SQL SERVER 的數據庫維護功能機制。例如，定期為數據庫進行Backup，維護管理數據庫死鎖問題和維護數據庫內數據的一致性等。

第三篇：IT軟硬件系統購置流程

IT軟硬件系統購置流程

IT軟硬件系統購置流程分公司或需求部門總公司信息技術部總公司財務部招標小組總公司領導供應商01申購02本地購買小設備或系統統購06信息技術部審批07預算審批在預算內是03分公司或部門采購審批流程是否在預算內08追加預算流程09領導審批04采購結算10是否為常規采購No22成立招標小組Yes05資產管理處理11是否簽訂大客戶協議項目性設備或系統Yes23確定技術方案No結束12簽訂大客戶協議流程24撰寫招標書14供貨自購設備或系統13下單分公司系統15是否為分公司申購25實施招標流程總公司系統16驗收19驗收26評標17資產管理處理20資產管理處理27是否需要多次招標Yes不同意29領導審批No18結算21結算28商務談判同意結束總公司統購的常規設備或系統結束30簽訂合同31供貨或集成系統32IT項目驗收流程33資產管理處理34結算項目性設備或系統35報告和總結

IT軟硬件系統購置流程說明

IT軟硬件系統購置一般可以劃分為三大類：自購小設備或系統、由總公司統購的常規設備或系統、項目性設備或系統。對于類別的劃分由總公司信息技術部和財務部共同商定，自購小設備或系統一般指價值小于2000元（對于成熟公司該額度可以調高）且非經常性（非批量）采購的軟硬件系統，如光驅等電腦配件、活動硬盤、維修工具、小型軟件等，也包括總公司信息技術部同意在當地自購或委托購買的設備或系統；由總公司統購的常規設備或系統主要指大于2000元或經常性采購的設備或系統，如電腦、打印機、分公司使用的網絡設備、操作系統、日常使用的應用軟件等；項目性設備或系統主要是指一次性或非經常性的設備或系統采購，該類采購一般涉及的金額比較大，如機房工程、小型機設備、總公司網絡系統、核心業務系統、財務系統、銷售支持系統等。

對于自購小設備或系統，由于涉及金額較小，且為非經常性采購，在當地自購可以獲取更低總擁有成本，一般在當地實施采購，但必須在分公司或總公司的部門預算之內，如果不在預算內，需要走追加預算審批流程。

對于由總公司統購的常規設備或系統，由于批量采購可以獲得更好的價格和更好的售后服務，因此采取集中統一采購的方式，先由總公司與供應商簽訂大客戶協議，需求部門或分支機構在辦理本地申請手續后，由總公司信息技術部確定型號和規格，然后交財務進行預算審批，并在主管領導審批通過后，由信息技術部或物控部門下訂單，并由供應商直接發貨給需求機構或部門。

對于項目性設備或系統，由于涉及金額比較大，且為非經常性采購，一般需要成立臨時招標小組進行招標處理。

具體流程說明：

一、需求部門或分支機構購置申請

1.申購。需求部門或分支機構提出設備或系統購買申請，對于項目性設備或系統采購需要進行立案，并經過主管領導審批通過后，方可進行申請。

2.申購設備或系統類別判定。申購部門或分支機構根據總公司相關文件判定本次采購申請的類別（自購小設備或系統、非自購小設備或系統）。

二、“自購設備或系統”處理流程

如果屬于自購設備或系統的范疇，將按照自購設備或系統處理流程處理，由申請機構的電腦部門在本地實施采購，并辦理相關資產管理手續。

3.申購部門或分支機構采購審批流程。申購的設備或系統需要經過財務預算的審批，如果不在預算內，需要走追加預算的審批流程，并需要經過相關領導審批。4.采購結算。由分支機構的電腦部門確定型號和規格，并進行采購和結算（總公司各部門的自購設備或系統由總公司信息技術部或物控部實施采購）。5.資產管理。申購部門或機構所在財務部門辦理資產管理相關手續。

三、“由總公司統購的常規設備或系統”和“項目性設備或系統”的審批 如果不屬于自購設備或系統的范疇，需要上報總公司進行采購審批。

6.信息技術部審批。對于非自購設備或系統，由信息技術部審核采購申請是否符合公司相關要求，如項目性設備或系統是否立項通過，常規設備或系統采購是否符合在預算內，型號和規格是否符合要求等；對于需要確定型號和規格的采購，信息技術部根據實際需求確定型號和規格。

7.預算審批。總公司財務部審核該采購申請是否在預算范圍內。

8.追加預算流程。如果該采購申請不在預算范圍內，需要申請部門或機構申請追加預算，具體流程參見財務部門的追加預算處理流程。

9.領導審批。如果預算審批通過或追加預算審批通過后，該采購申請需要請相關領導進行審批。

10.采購申請類別判定。該采購申請審批通過后，由信息技術部判定本次采購申請的類別（由總公司統購的常規設備或系統、項目性設備或系統），并根據采購申請的類別分別按照不同的流程進行處理。

四、“由總公司統購的常規設備或系統”處理流程

如果屬于“由總公司統購的常規設備或系統”的范疇，信息技術部或物控部將根據大客戶協議進行采購，并由申請部門或機構所在財務部門辦理資產管理手續。11.判定該采購申請是否為大客戶協議范圍。對于常規采購申請，信息技術部先判定該申請是否為大客戶協議范圍。

12.簽訂大客戶協議流程。如果該申請不在大客戶協議范圍，且該類設備或系統為經常性采購范圍，信息技術部將會同相關部門盡快與供應商進行商務談判和簽訂大客戶協議，對于大客戶協議一般直接與生產廠商簽訂，只有對于不能在中國境內直接銷售的廠商才與其代理商簽訂，以獲得更低的成本和更好的服務。13.下單。信息技術部或物控部根據信息技術部提供的技術參數、產品型號和規格，向已經簽訂大客戶協議的供應商下訂單。

14.供應商供貨。供應商根據公司訂單上的產品型號、規格和數量，發貨到訂單上指定的分支機構或部門。

15.采購申請地域判定。需要根據采購申請地域確定驗收和資產管理流程，如果為分支機構申請，則在分支機構進行設備、系統驗收、結算和資產管理；如果為總公司申請，則在總公司進行設備、系統驗收、結算和資產管理。

16.分公司驗收。如果為分支機構采購申請，由分支機構電腦部門驗收設備或系統，并將情況反饋給總公司信息技術部。

17.分公司資產管理處理。設備或系統在電腦部門驗收通過后，辦理資產管理的相關手續。

18.分公司結算。分支機構在收到供應商的發票且通過電腦部門的驗收后與供應商進行貨款的結算。

19.總公司驗收。如果為總公司采購申請，由總公司信息技術部驗收設備或系統。20.總公司資產管理處理。設備或系統在信息技術部驗收通過后，由財務或相關部門辦理資產管理的相關手續。

21.總公司結算。財務部在收到供應商的發票且通過信息技術部的驗收后與供應商進行貨款的結算。

五、“項目性設備或系統”處理流程

如果屬于“項目性設備或系統”的范疇，需要成立招標小組進行招標處理。22.成立招標小組。根據項目性質成立招標小組，招標小組主要組成為使用部門、信息技術部、財務部、物控部等部門，招標小組需要通過主管領導的審批。23.確定技術方案。通過共同商議，招標小組確定技術方案，在確定技術方案時可能需要與廠商或供應商進行接觸和探討方案。

24.撰寫招標說明書。根據技術方案和公司招標要求，招標小組撰寫招標說明書。25.實施招標。IT項目的招標一般有兩種方式：公開招標和邀標。一般常用的是邀標方式，即根據邀標條件先在市場上進行供應商初選，然后對符合條件的供應商邀標，招標小組對愿意參加招標的供應商發標，供應商領取標書后在指定的期限內回標。為了取得較好的價格，盡管在技術方案確定是有明顯的品牌傾向，但在招標時盡量既招標集成商同時也進行品牌（廠商）的招標，以引入廠商的適度競爭。在招標過程中，與廠商進行深入的溝通，對于降低成本也有很大的幫助。26.評標。在IT項目評標前，需要招標小組根據項目情況事先制定評標指標和權重，然后招標小組根據各供應商情況和回標情況進行評分，對于比較重大的項目，可能還需要各供應商進行講標。

27.招標結果的確認。招標小組將根據招標和評標的結果，以及預算等實際情況決定是否需要調整技術方案和實施下一輪招標，一般對于重大和復雜的項目，可能因修改方案而需要進行二次招標，也可能為了更好的降低成本而實施第二輪招標。28.商務談判。招標小組將根據評標結果選擇一家或二家供應商進行價格等方面的進一步探討，以獲得更低的成本，并根據商談結果基本確定供應商，并進行商務方面的談判。

29.領導審批。招標小組將招標結果和商務談判情況上報主管領導，如主管領導不同意招標和商務談判結果，需要招標小組重新進行商務談判，甚至重新實施招標；如主管領導同意招標和商務談判結果，由招標小組繼續實施合同簽署流程。30.簽訂合同。招標小組將根據領導審批通過的招標結果和商務談判結果，與選定的供應商進行商務合同條款的確定，并簽訂商務合同。

31.供貨或集成系統。供應商將根據商務合同要求供貨或集成系統。

32.IT項目驗收流程。IT項目驗收小組將根據驗收要求實施IT項目驗收流程，具體內容見《IT項目驗收流程》。33.資產管理處理。IT項目驗收通過后，由財務部或相關部門辦理資產管理的相關手續。

34.結算。財務部門將根據合同條款和項目驗收情況進行財務結算。

35.報告和總結。IT項目全面驗收通過后，招標小組需要撰寫項目報告和總結，報告包括本項目招標情況的總結，也包括本次招標工作得與失的總結。

第四篇：城院09級 工資管理系統設計概要

目 錄

1、需求及背景分析....................................................................1 1.1 工資管理系統的概述.......................................................................................................1 1.2 A 公司工資管理系統需求調查.......................................................................................2

2、系統分析..................................................................................3 2.1 A 公司工資業務流程圖......................................................................................................3 2.2 A 公司工資管理數據流程圖..............................................................................................4 2.3 A 公司工資管理系統功能分析圖......................................................................................4 2.4 數據字典.............................................................................................................................5 2.6管理信息系統流程設想圖(新系統模型.........................................................................7

3、系統設計部分..........................................................................8 3.1 功能結構圖設計..................................................................................................................8 3.2 新系統信息處理流程設計(ER 圖..............................................................................8 3.3 輸出設計(主要指打印輸出設計..................................................................................9 3.4 存儲文件格式設計(數據庫結構設計..........................................................................9 3.5 輸入設計.............................................................................................................................9 3.6 代碼設計(職工證號和部門代號等............................................................................10 3.7 程序設計說明書................................................................................................................10 3.8 工資管理信息系統數據庫設計........................................................................................10 4.系統實施...................................................................................14

5.課程設計心得...........................................................................14 管理信息系統課程設計任務書 題目 : 工資管理系統設計 1.課程設計教學條件要求

運用現有教學條件,結合所學知識、網絡和圖書館等資料,以團隊小組形式, 團隊協作,保質保量完成課程設計。

2.課程設計任務

課程設計任務的描述應該清晰明確,設計的難度和工作量應符合學生的實際 水平,在規定的時間內能夠完成設計任務。

3.課程設計報告書主要內容 工資管理系統設計

1、需求及背景分析 1.1 工資管理系統的概述

企業工資管理是一個企業單位不可缺少的部分,它的內容對于企業決策者 和管理者來說都是至關重要的,所以企業工資管理系統應該能夠為用戶提供充足 的信息和快捷的查詢手段。但是一直以來人們使用傳統人工的方式管理企業的工 資發放工作,這種管理方式存在許多缺點,例如往往由于抄寫不慎或者由于計算 的疏忽,出現工資發放錯誤的現象。工資管理具有重復性、規律性、時間性,正 是由于這些規律,使得工資管理的計算機化成為可能。

進入 21世紀,計算機已經滲入到社會生活的各個領域,推動著科學技術、社會經濟的發展。計算機用于管理信息處理的突出特點是迅速、準確、可靠并且 具有很大的存儲能力。因此,國內外越來越重視工資管理的效率及其可靠性。目

前,對于工資管理都有著相當普遍和深入的研究,但是工資管理對于社會、企業 和人民生活有著極為重要的影響。

因此在此基礎上對工資管理系統進行分析和設計就非常有必要了。1.2 A 公司工資管理系統需求調查

為了更好的設計企業工資管理系統, 我們對 A 公司的工資管理事項進行調查 和分析,在此基礎上開發設計我們自己的工資管理系統: 對 A 公司的工資管理進行調查,得到工資發放過程及有關數據如下圖:

表 1 上月工資發放清單

表 2 本月人員及工資變動表 表 3 本月扣款清單

根據了解信息: A公司每月月末發放工資,發放前的工資處理過程是每月 25日到 27日由財務科根據已存檔的上月工資發放清單(見表 1和人事科送來的 人員及工資變動表(表 2 填寫本月工資發放清單中的前四項(即姓名、基本工資、附加工資、扣房費。總務科于每月 28日將扣款清單(見表 3送交財務科,由 財務科按扣款清單將扣款數填入本月工資發放清單。最后計算出每位職工的應發 工資數,并填入工資發放清單,為工資發放人員發放工資做好準備。

2、系統分析

2.1 A 公司工資業務流程圖

依據 A 公司調查資料,我們將其工資業務流程繪制出如下業務流程圖:

現行的工資發放體系業務流程圖 上圖中實體的具體功能如下: 財務工資會 :負責匯總人事部遞交的人員及工資變動表和總務處遞交的扣款清單 , 填寫職工工資發放清單 , 交由工資發放人員按時發放職工工資 , 并存 檔工資發放清單。

人 事 部 :負責編寫人員及工資變動表 , 并及時送交財務工資會。總 務 處 :負責編寫扣款清單 , 并及時送交財務工資會。2.2 A 公司工資管理數據流程圖

經過對 A 公司工資業務流程的分析,我們可大致繪出 A 公司工資管理系統中 數據的流程圖:

工資管理數據流程圖

人事科把本月人員工資變動表送去抄寫,同時上月工資發放清單也送去抄寫。抄寫完后把本月工資發放清單送到扣款項進行扣款,同時總務科也將扣款清單送 到扣款項進行扣款。扣款結束后得到的本月工資發放清單進行計算并填寫應得工 資,同時工資發放員把本月工資發放清單進行計算并填寫應得工資。

2.3 A 公司工資管理系統功能分析圖

工資管理信息子系統由建立主文、更新主文、建立扣款文、計算和打印四 個模塊組成。建立主文包括數據的錄入及維護。更新主文包括建立主處理文件及

更新。建立扣款文包括數據錄入和維護。計算和打印包括計算、打印工資單和打

印工資匯總表。2.4 數據字典

數據字典是指對數據的數據項、數據結構、數據流、數據存儲、處理邏輯、外部實體等進行定義和描述,其目的是對數據流程圖中的各個元素做出詳細說明。

:_____1____

:_____2_____

:_____3___

:

______4____

2.6管理信息系統流程設想圖(新系統模型

3、系統設計部分 3.1 功能結構圖設計

工資管理系統功能模塊結構圖 3.2 新系統信息處理流程設計(ER 圖

3.3 輸出設計(主要指打印輸出設計

3.4 存儲文件格式設計(數據庫結構設計

3.5 輸入設計

3.6 代碼設計(職工證號和部門代號等

3.7 程序設計說明書(此部分內容略

3.8 工資管理信息系統數據庫設計 1.數據庫中的表對象

2.表結構設計

2-1本月工資變動表的設計

SQL 語句:select * from gongzi 表內容: 2-2本月扣款清單的設計

SQL 語句:select * from koukuan 表內容:

2-3 本月工資發放清單的設計

select *from 本月扣款清單 select*from 本月工資變動表

select 本月工資變動表,本月扣款清單,扣電費,本月扣款清單,病事假扣 款,本月工資變動表,基本工資 +本月工資變動表,附加工資-本月工資變動表, 房費-本月扣款清單,扣電費-本月扣款清單,病事假扣款 as 應發工資 into 本 月工資發放清單 from

本月工資變動表,本月扣款清單 where 本月工資變動表, 職工代碼 =本月扣款清單,職工代碼

select *from 本月工資發放清單

insert into 本月工資發放清單(職工代碼,姓名,部門,基本工資,附加工 資,房費,備注,扣電費,病事假扣款,應發工資 select 本月工資變動表,本 月工資變動表,基本工資 +本月工資變動表,附加工資-本月工資變動表,房費 as 應發工資 from 本月工資變動表 where 本月工資變動表,職工代碼 not in(select 本月扣款清單.職工代碼 from 本月扣款清單

select*from本月工資發放清單 order by 職工代碼 4.系統實施 此部分內容略 5.課程設計心得

光陰似箭,歲月如梭,不知不覺我即將走完大學生涯,回想這一路走來的日 子,同學的相互扶持,老師的悉心教誨,朋友的支持幫助一直陪伴著我們,讓我 們漸漸長大,也慢慢走向成熟。

在這一課,我們珍惜最后在大學的日子,努力學習,努力實訓,努力運用課 堂教學的知識以更好的完成課程設計。首先,我們在團隊討論后,一致認為要結 合專業知識進行選題,最后定為:工資管理系統設計。根據選好的題目,收集相 關的資料,利用圖書館,網絡等,資料整理完之后,開始可行性分析,程序系統 設計等等,一個環節接著一個環節。在這次的課程設計中,我們認識到在做一個 系統之前,必須要有一個清晰的思路,要明白怎么做,決不能還沒想好就去下手, 那很容易發生半途做不下去的情況的,在做之前必須要對系統進行分析,可行性 分析,需求分析,決不能按著自己的想法,想怎么做就怎么做,要滿足用戶的需 求,要換位思考,程序簡單明了,應注釋的地方要注釋,因為重要的是要讓用戶 明白。雖然這次的課程設計順利完成,但我們清楚的意識

到自身的不足,在以后 的日子里還要繼續學習,而且必須團結同學,學會團隊協作。一個人的力量是渺 小的,但團隊的力量是大的。

我們的選題及進行過程中得到了老師悉心指導。設計過程中，老師多次幫助 我分析思路，開拓視角。團隊成員也在我遇到困難想放棄的時候給予我最大的支 持、鼓勵和幫助。老師嚴謹求實的治學態度，踏實堅韌的工作精神，將使我終生 受益，團隊的友誼使我忠心感激。再多華麗的言語也顯蒼白。在此，謹向老師，所有團隊成員致以誠摯的謝意和崇高的敬意。在此，非常感謝我們的大學認識的最后一位老師--肖科峰老師。肖老師在這 次工資系統設計中給我們很大幫助，還教導我們在實習就業中應注意的方方面面 以及一些為人處事細節。謝謝你！15 課程設計評分表（參考格式）評分標準： 1.學生是否嚴格遵守課程設計紀律，按照規定時間完成設計任務(占 30% 2.課程設計報告書質量：(占 40%(1是否采用了良好的設計方法，獨立完成課程設計。(2課程設計各分段的任務是否按時完成及完成的質量。(3是否完成課程設計任務書指定的全部要求。3.課程設計報告書的撰寫規范(占 30% 課程設計報告書的撰寫規范要求與畢業設計（論文）的要求相同。教師評分： 1.學生出勤得分： _________ 2.內容質量得分： _________ 3.撰寫規范得分： _________ 最終評定成績（以優、良、中、及格、不及格評定）：_________ 教師評語： 簽字： 日期： 年 月 日 16

第五篇：OA辦公系統 概要設計 心得體會

項目心得

根據需求情況的分析。接下來就開始進行具體的設計了首先是數據流圖。對于B/S項目 需要一個具體的框架來實施根據我們所學到的知識 我們選用了jsp＋servlet＋java Bean＋MySQL的方式來實施這次的項目。數據流圖就開始清晰整個數據的傳遞方式以及處理過程。通過流圖的設計具體的功能實施辦法開始明確。接下來就是數據庫的設計了。當然首先要明白數據庫的關系也就是需要對實體進行分析構建一個關系明確的數據關系并繪制實體圖。對于實體的概念開始并不是很清晰。后來發現其實這一步很關鍵。數據庫讀出的數據以及寫入數據庫的數據都是根據實體的情況來設計的。許多在設計初期考慮不到的問題在這一步就會體現出來并進行修正。這一步過后就可以設計數據字典對數據庫中的每個項目進行明確這一步需要全面考慮也是在前面設計的基礎之上來完成的。并且通過設計數據字典會對前面的設計進行相應的修改。并完善設計過程合并一些功能相似的內容或者將一個功能的實現分成幾個模塊來處理。到這一步的設計完成后就開始考慮用MVC的結構來實現功能了。對于視圖層需要處理對用戶呈現的問題。很多頁面之間的跳轉以及根據權限來設計頁面的現實內容。通過功能的分離去處理servlet的跳轉控制以及頁面的刷新。再通過具體的業務要求來設計java Bean。和最后的數據庫訪問控制。最后形成了具體的類設計

model層：進行頁面數據的傳遞和處理實現具體功能

View層：應用jsp＋javascript方式設計界面。設計了用戶登陸界面進入系統。在系統中運用Dtree技術完成功能間的切換。并規劃具體功能的頁面結構。Util層：建立數據庫連接工具并返回具體類的實例。

Control層：提供數據傳遞控制。

這次項目是對前段時間所學的java知識的一個實踐。在實際的項目中讓自己受益匪淺。在經歷這次項目以后發現自己的設計思想有了很大的提高。對于一個項目怎么去實現有了更多的具體經驗。同時也發現自己在軟件設計方法和軟件工程方面的知識不足。對于項目的規劃。初期的設計在后期實現的時候出現了很大的問題。很多都是在設計的時候沒有考慮到的問題。也有邏輯錯誤的地方。這些問題直接導致了后期的代碼階段進度緩慢。不過在這次過程里面也開始意識到項目設計和規劃的重要性。這跟項目實施的成功與否有很大關系。另外在進行組員配合上也總結了一些怎么去規范同組組員的代碼，控制整體進度，了解和溝通意見方面的經驗。在后期整合代碼的時候發現了一些代碼規劃上的問題。這個問題讓我浪費了很多時間。總的來說通過這次項目雖然不是很成功。不過對java 的設計模式有了更進一步的了解。對面向對象的處理問題有了更多的體會。