基于LPC21 32的U盘软硬件系统设计概要

第一篇：基于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 的设计模式有了更进一步的了解。对面向对象的处理问题有了更多的体会。