高校学费收费管理信息系统分析及其设计应用.doc

高校学费收费管理信息系统分析与设计

摘 要 随着校园网环境建设和学校教务管理改革进一步深化，学生收费工作模式已经从本来学校院系二级管理模式转变为学校一级管理模式。本文提出基于校园网学生收费系统，采用了Client/Server开发方式，给学生提供了灵活以便收费服务，提高了学校收费管理部门工作效率，并为其他部门和有关人员提供实时收费信息服务。
核心词 学生收费系统；综合教务管理系统；结算中心；收费原则
Abstract With the development of campus network and the reformation of educational administration，the mode of tuition administration has changed into one administrative level from two administrative levels. The tuition system based on campus network，described by this article，adopt the method of C/S，provides convenient service for students，improves work efficiency of tuition administration department，and provides real-time information service for other departments and persons.
Keyword tuition system；all-around educational administration system；center of settling account，tuition standard
1 绪论
1.1 开发背景
近几年，诸多高校都在不断扩招，扩招后高校在加大硬件设备建设同步，也在不断调节、完善学校教务管理，随着学校教务管理改革进一步深化，教务管理各个环节有关数据都由各个院系集中到学校，形成了全校性网络共享数据库，缩短了信息流通渠道，在数据及时性、一致性、共享性等方面上都获得了明显成效。为适应学校集中管理模式开发西安石油大学网上综合教务管理系统，大大增进了学校教务管理工作规范化、科学化，为广大教师和学生提供了大量信息服务。
学生收费作为学校综合教务管理系统一种重要环节，对教务系统其他环节有着很大影响，特别是针对学生管理。旧收费系统，功能简朴，只是在一定限度减轻操作员计算量，任务依然很繁重、过程复杂、记录量大，并且容易出错、不以便管理。显然旧系统已经不能满足当前管理规定，因而，学校决定采用新收费软件来完毕操作人员大量计算、记录、查询工作，减轻操作人员工作量，提高工作效率。同步可觉得有关部门提供及时、精确、完整信息。新收费系统需要从教务处获取学生类别和收费原则，给注册、选课提供学生交费信息，同步给教务处、研究生部、财务处等部门提供收费信息服务和决策支持。
(1) 相对于旧收费系统，重要解决了如下问题：
l 所有学生直接去收费中心交费，安全以便，同步省去了诸多麻烦。
l 学生可以依照实际状况通过钞票、汇款、储蓄存折、支票等方式交费。
l 新收费模式给其他部门和有关人员提供实时记录查询功能。
l 学生交费与学生注册有关联，而学生注册与学生选课有关联，从而解决了学生拖费欠费老问题。
(2) 社会上其他收费系统应用对象比较广，但功能不够详细，无法满足特定管理体制下收费管理系统规定
在系统开发之前咱们有必要对系统进行总体规划，拟定系统目的并进行可行性分析。
1.2 新系统规划
1.2.1 新系统总体目的设定及可行性分析
(1) 新系统目的设定
高校学费收费管理信息系统重要目的是：实现有关部门之间信息共享，保证信息传递精确、完整；采用简捷图形化人机界面，操作简朴、容易，提高工作效率；对各种数据汇总，进行辅助决策。
(2) 可行性分析
可行性分析重要是依照信息需求和资源环境等约束，判断高校学费收费管理信息系统必要性和也许性。分别在技术、经济和开发环境上对高校学费收费管理信息系统进行可行性研究。
（1）技术上可行性。
一方面，学校有较好科学管理基本，现行系统基本数据比较完整、合理。有助于历史数据转换和载入；另一方面，学校具备较好计算机配备和网络实行，学校更有较好内部局域网。新系统无论在软件还是硬件方面都不会有大困难。
（2）经济上可行性。
经济上可行性涉及资金上可得性和经济上合理性。
资金上可得性。学校高层领导十分注重学校信息化建设，对各项信息建设均有足够资金投入，因此在资金上需求不成问题。
经济上合理性。系统带来经济效益重要体当前间接效益上，这些间接效益体当前：节约了人力，减少了劳动强度；通过计算机管理，减少了成本和其她管理费用；提供较好汇总和查询功能，可以进行辅助决策；为有关部门提供及时、精确共享信息。
（3）管理上可行性。学校合理管理体制，为现行系统提供了比较完整基本数据，也为新系统运营提供了保障。
（4）开发环境上可行性。该系统开发得到了组织中各层人员支持配合，给系统开发提供了一种较好开发环境。
1.2.2 开发办法及工具选用
该系统采用客户机/服务器体系构造。系统开发采用面向对象系统开发办法，程序设计按照应用层不同分为前台和后台，前台重要为数据收集、客户端信息解决和信息查询服务。后台程序重要完毕数据更新和数据访问。在后台采用Microsoft SQL Server 数据库系统，系统开发工具选取Microsoft Visual Studio .NET可视化集成开发环境
在完毕新系统总体规划和可行性分析以及可行性研究报告得到批准后，就进入了系统分析和设计阶段。
2 系统需求分析
这某些重要完毕系统管理构造分析和功能需求分析。
2.1 管理构造分析
前面理解到学校收费管理模式发生转变，学校管理构造和领导层次关系也相应发生变化。系统组织构造图如下：
学校
财务处
收费中心
教务处
注册中心
各院系
图2-1 组织构造图
其她部门

2.2 系统功能需求分析
学费收费管理系统可以同步对本科生和研究生进行收费，但某些高校在本科生和研究生收费管理模式上有较大区别。
2.2.1 本科生收费管理模式
本科生收费管理模式基本流程如下：
1． 招生办发出录取告知书后，新生就可以开始通过银行汇款进行交费，收费中心从银行获得新生所有汇款记录，手工录入数据库（也可以由银行提供批量数据，系统自动导入）。
2． 新生报到前，收费中心从招生办获取新生数据和新生收费原则信息，以此核对新生汇款信息，最后拟定所有对的汇款学生名单。对学生汇款超过交费原则某些进行“转储蓄”操作，转入银行帐号系统，并为其建立个人存折。新生报届时，收费中心负责为汇款学生打印收费收据，有转储蓄打印存折（普通状况下，已经提前所有打完），没有汇款新生和汇款不够学生可以用钞票和支票现场交费。
3． 注册中心维护在校本科生收费原则，本科生收费原则针对一类学生，即每个学生通过“所属年级＋所属专业”拟定她收费原则，“所属年级＋所属专业”在学生学籍信息里维护。
4． 本科生交费每年一次，普通规定一次能交清，但也容许先交一某些，在规定期间内交清所欠某些，超过规定期间就按有关规定收取滞纳金。对于未交清学费学生不给注册、始终欠费学生禁止选课和期末考试。对于不用交费学生通过设立收费原则应交为零实现。
2.2.2 研究生收费管理模式
研究生收费管理模式基本流程如下：
1． 数据准备
研究生部每学期从招生办获取新入学研究生名单和收费原则，并将数据转入收费系统。每学期交费前对在校研究生进行收费数据准备，并维护收费原则，普通按照上一年收费原则拟定本次收费原则。
2． 研究生收费原则是针对每个人，应交费研究生所交费用涉及每年应交和一次性应交两某些，每年应交必要每年准时交纳，否则不容许注册，但一次性应交只要在毕业前交齐即可。
3． 研究生每学期均有一次收费，普通春季入学研究生在春季交费，秋季入学研究生在秋季交费。但欠费学生可以在任何时间到收费中心交费。
4． 研究生到收费中心交费容许多交（即预先交纳后来几年）、少交（虽然交费，但总数不够，依然欠费，不容许注册），也容许一年内多次交费。但收费中心不负责给学生退费，需要退费学生由收费中心和研究生部协商，手工解决。
虽然在某些高校本科生和研究生采用不同收费模式，但是我校本科生和研究生采用是统一收费模式。即上述本科生收费管理模式。因而，此收费系统采用本科生收费管理模式。
2.2.3 基本信息和数据准备模块
(1) 学校组织构造信息录入：普通学校体系构造为“年级\院系\专业\班级” ，针对组织构造管理就是建立学校各年级资料、各院系资料、各专业资料和班级资料档案。实现资料新建、修改和删除。
(2) 学生基本信息录入：学生基本信息是该系统重要资料，是收费解决中最后对象。
(3) 收费原则录入：收费原则是实现收费前提，也是收费根据。此系统涉及收费原则制定、查询等；参照对象有：艺术类、非艺术类、专科、本科、研究生。在每次新任务建立时完毕收费原则制定。
(4) 收费项目：收费项目指在某项收费任务中详细收款条目。如学费、住宿费、课本费等。
(5) 收款方式：收款方式用于表达学生收/退款时支付形式，重要是钞票、学生帐户（每位学生在学校都内置了一种帐户）、转出（将多缴某些以转出到学校一卡通或者校园银行等一种找补方式）。
2.2.4 收费解决模块
(1) 管理收费任务：重要针对每次收费活动建立、收费原则录入、保存学生应收款、以及任务结存(结转)等，是一种有条件为学生批量记费一种业务解决。

任务管理普通环节如下：
新建任务
录入收费原则
保存应收款
生成应收款
业务操作
记录分析

(2) 管理收费：管理寻常收费（重要用于解决学生在校寻常零星消费业务）、学生预存（学生将钞票预存到学校为每位学生开设个人账户上，如：校园一卡通，后来学生在学校消费时可直接从该帐户上扣除）。有个人收费和批量收费；批量收款是一种针对选定收费任务进行批量收款解决业务解决功能，默认状况下，批量收款收款方式为“钞票” 。
(3) 退费管理：有个人退费和批量退费；批量退费重要用于解决成批满足退费条件学生退费业务。默认状况下，批量退款付款方式为“钞票”。
(4) 减免管理：依照特殊状况或其她规定实现费用减免。有个人减免和批量减免；批量减免重要用于解决成批满足减免条件学生减免业务。
2.2.5 记录分析模块
记录分析是此系统一种非常重要环节，记录信息给学校教务管理提供决策支持。大某些报表查询都是采用先设立查询条件和范畴，再分析出成果操作方式。如果有得到对的查询成果，就必须设立对的分析条件。依照院系、年级、专业、班级条件进行收款记录、欠费记录、减免记录以及学生缴费、欠费历史记录查询。
2.2.6 系统管理模块
重要完毕操作人员管理，数据维护等。
(1) 收费系统操作人员管理
收费中心、注册中心、各院系领导和教务员通过收费系统可以实时查询学生交费成果，但系统对不同登入顾客有严格权限控制，各类顾客使用不同帐号进入系统，各自操作权限范畴内功能。出于安全性和财务结算制度规定，收费中心内部不同终端使用不同帐号。收费系统顾客共提成五类：
1． 收费中心管理员：维护收费公共信息，记录收费状况，生成财务登记表。
2． 收费中心操作员：面向学生完毕收费操作。
3． 注册中心管理员：负责维护本科生收费原则，学生注册。
4． 各院系领导和教务员：只能查询本系学生交费状况
(2) 数据维护重要是完毕数据库数据备份和恢复操作。
2.3 系统流程分析
系统流程分析重要重要涉及业务流程分析和数据流程分析。
2.3.1 业务流程分析
本科生收费管理模式业务流程分析图如下：
银行汇款

新生汇款单
新生

收费中心
招生办
新生名单
收费原则
图2-2 本科生收费业务流程分析
核对新生
汇款信息
对的汇款
学生名单
转储蓄
超额学生
制定、维护
收费原则
核对学生信息
解决学生收费
交清学费学生名单
学生注册
注册中心

研究生收费管理模式业务流程分析图如下：
招生办
研究生名单
收费原则
制定、维护
收费原则
数据录入
银行汇款

新生汇款单
新生

核对学
生信息
研究生部
图2-3 研究生收费业务流程分析
注册中心

2.3.2 数据流程分析
依照本科生收费管理业务流程图，可以得出本科生收费管理顶层DFD图。如下：
招生办
注册中心
收费管
理系统
新生名单
收费原则
报表
图2-4 本科生收费管理顶层DFD图
教务处
报表

对顶层数据流程图2-2进行细分
招生办
新生名单
图2-5 本科生收费管理第一层DFD图
注册中心
收费原则
报表
2
任务
管理
1
基本信
息管理
3
收费
管理
4
记录
分析
院系
教务处
报表
报表
组织构造信息

基本信息管理模块数据流程图如下：
招生办
新生名单
1.1
录入
数据
教务处
注册中心
收费原则
组织构造信息
图2-6 基本信息录入DFD图
3
收费
管理

收费管理数据流程图如下：
新生名单
3.2
收费
解决
3.1
核对
信息
3.3
汇款学
生记录
汇款学
生名单
3.4
收费
记录
注册中心
教务处
图2-7 收费管理DFD图

3.5
退费解决
3.6
减免解决
退费登记表
减免登记表

收费任务数据流程图如下：
注册中心
3
收费
管理
收费原则
2.1
新建
任务
1.1
录入
数据
生成应收款

图2-8 任务管理DFD图
登记表

2.3.3 数据字典
前阶段分析收集了大量数据载体，但这些数据还比较分散，只能局部反映组织某项业务或部门对数据规定和既有数据状况。为了对数据进行统一管理、存储和操作，就应当在数据流程进行描述之前将所有数据进行统一规范化解决。
数据流程图描述了系统分解，即描述了系统由哪些某些构成以及各某些之间联系等，但没有详细阐明系统各某些含义。借助数据字典可以描述数据流程图中数据流、数据存储、解决过程和外部实体。系统建立数据字典如下：
表2-1 学生数据构造
数据构造
编号：001
总编号：1-001
名称：学生基本信息
有关数据流、数据存储：

阐明：所有学生基本信息
班级信息、交费信息

构造：学生编号
数量：约0份

学生姓名
性别
班级编号
当前状态

表2-2 班级数据构造
数据构造
编号：002
总编号：1-002
名称：班级信息
有关数据流、数据存储：

阐明：所有班级信息
专业信息、年级信息

构造：班级编号
数量：约300份

班级名称
专业编号
年级编号
学制
学位
入学时间
当前状态

表2-3 收费项目数据构造
数据构造
编号：003
总编号：1-003
名称：收费项目
有关数据流、数据存储：

阐明：所有收费项目信息
项目类别

构造：项目编号
数量：约40份

项目名称
项目类别
当前状态
[备注]

表2-4 项目类别数据构造
数据构造
编号：004
总编号：1-004
名称：项目类别
数量：约40份

阐明：所有项目类别信息

构造：类别编号

类别名称
当前状态

表2-5 操作人员数据构造
数据构造
编号：006
总编号：1-006
名称：操作人员
数量：约50份

阐明：所有操作人员信息

构造：操作员编号

操作员名称
密码
性别
联系电话
[备注]

表2-6 操作员职务数据构造
数据构造
编号：006
总编号：1-006
名称：操作员职务
数量：约50份

阐明：所有操作员职务信息

构造：职务编号

职务名称
[备注]

表2-7 收费任务数据构造
数据构造
编号：007
总编号：1-007
名称：收费任务
数量：约50份

阐明：所有收费任务信息

构造：任务编号

任务名称
创立时间
当前状态

3 系统设计
在设计与开发高校学费收费管理系统过程中，咱们遵循学校教务管理思路，以校园网络环境和全校性网络共享数据库为基本，采用Client/Serve开发方式。结算中心、注册中心、研究生部等单位密切合伙，为学生收费系统顺利运营创造了有利环境。
3.1 功能构造设计
按照收费系统与其他信息系统或数据源之间数据联系，以及系统自身业务流程，可以将系统划提成四个功能模块。收费系统功能模块图如下：
高校学费收费管理系统
基本信息
业务解决

收费原则维护
收费项目
收款管理
退费管理
减免管理
记录分析
收款记录
欠费记录
减免记录
历史记录查询
学校组织构造
学生基本信息
图3-1 收费系统重要功能模块图
系统管理
操作员管理
数据维护
职务权限管理
收费任务管理

依照功能模块划分可得功能使用者用例图，如下：
业务解决
图3-2 系统用例示意图
基本信息
记录分析
系统管理
操作员管理
数据维护
职权管理
欠费记录
减免记录
收款记录
历史查询
减免管理
收费管理
退款管理
收费项目
学生信息
学校信息
收费原则
操作员
任务管理

3.1.1 基本信息模块设计
(1) 学校组织构造管理：普通学校体系构造为“年级\院系\专业\班级” ，针对组织构造管理就是建立学校各年级资料、各院系资料、各专业资料和班级资料档案。实现资料新建、修改和删除。
(2) 学生基本信息：学生基本信息是该系统重要资料，是收费解决中最后对象。重要功能有新建、修改和删除学生资料、学生转班、休学、复学、退学、毕业等。
(3) 收费原则：收费原则是实现收费前提，也是收费根据。此系统涉及收费原则制定、查询等；参照对象有：艺术类、非艺术类、专科、本科、研究生。在每次新任务建立时完毕收费原则制定。
(4) 收费项目：收费项目指在某项收费任务中详细收款条目。如学费、住宿费、课本费等。（预选收费项目：学费、住宿费、课本费、体检费、服装费、学杂费、借书费、计算机信息费、卧具费、军装费、饭卡工本费、疫苗费、证书工本费、注册费、统考招生费、文体卫生费、班费、自行车保管费、取暖费、毕业证工本费、电教教材代办费）
(5) 收款方式：收款方式用于表达学生收/退款时支付形式，重要是钞票、学生帐户（每位学生在学校都内置了一种帐户）、转出（将多缴某些以转出到学校一卡通或者校园银行等一种找补方式）。
3.1.2 业务解决模块设计
(1) 收费任务管理：重要针对每次收费活动建立、收费原则录入、保存学生应收款、审核学生应收款、以及任务结存(结转)等，是一种有条件为学生批量记费一种业务解决。

(2) 收费管理：管理寻常收费（重要用于解决学生在校寻常零星消费业务）、学生预存（学生将钞票预存到学校为每位学生开设个人账户上，如：校园一卡通，后来学生在学校消费时可直接从该帐户上扣除）。有个人收费和批量收费；批量收款是一种针对选定收费任务进行批量收款解决业务解决功能，默认状况下，批量收款收款方式为“钞票” 。
(3) 退费管理：有个人退费和批量退费；批量退费重要用于解决成批满足退费条件学生退费业务。默认状况下，批量退款付款方式为“钞票”。
(4) 减免管理：依照特殊状况或其她规定实现费用减免。有个人减免和批量减免；批量减免重要用于解决成批满足减免条件学生减免业务。
3.1.3 记录分析模块设计
记录分析是此系统一种非常重要环节，记录信息给学校教务管理提供决策支持。大某些报表查询都是采用先设立查询条件和范畴，再分析出成果操作方式。如果有得到咱们想要查询成果，就必须设立对的分析条件。
(1) 收款记录：依照院系、年级、专业、班级条件记录分析收费状况。
(2) 欠费记录：依照院系、年级、专业、班级条件记录分析欠费状况。
(3) 减免记录：依照院系、年级、专业、班级条件记录分析减免状况。
(4) 历史记录查询：实现学生缴费、欠费查询。
3.1.4 系统管理模块设计
重要完毕操作人员管理，数据维护等。
(1) 收费系统操作人员管理
收费中心、注册中心、各院系领导和教务员通过收费系统可以实时查询学生交费成果，但系统对不同登入顾客有严格权限控制，各类顾客使用不同帐号进入系统，各自操作权限范畴内功能。出于安全性和财务结算制度规定，收费中心内部不同终端使用不同帐号。
(2) 数据维护完毕数据库数据备份和恢复操作。
3.2 数据流程设计
下面解决系统重要功能模块数据流程设计。
顾客登录流程设计如图3-3：
判断顾客信息

顾客存在
提示顾客不存在
判断顾客身份
是
否
进入顾客界面
图3-3 顾客登录流程设计

学生收费管理流程设计如图3-4：
选取学生

满足条件
提示学生不满足条件
选取收费方式
是
否
解决学生收费
图3-4 收费管理流程设计

退费管理流程设计如图3-5：
选取学生

满足条件
提示学生不满足条件
选取退费方式
是
否
解决学生退费
图3-5 退费管理流程设计

学费减免管理流程设计如图3-6：
选取学生

满足条件
提示学生不满足条件
选取减免方式
是
否
解决学生学费减免
图3-6 减免管理流程设计

记录分析流程设计如图3-7：
选取解决任务

选取记录范畴

汇总解决

图3-7 减免管理流程设计
选取汇总方式
登记表

3.3 数据库设计
由系统分析报告可以设计如下数据库表。

系号
字段
含义
类型
1
AcademyID
唯一编号
uniqueidentifier
2
AcademyName

varchar
3
Status
可用|禁用
bit
4
CreateDate
院系创立时间
dateTime
表3-1 院系列表（AcademyList）

表3-2 年级列表（GradeList）
系号
字段
含义
类型
1
GradeID
唯一编号
uniqueidentifier
2
GradeName

varchar
3
Status
可用|禁用
bit
4
CreateDate

dateTime

表3-3 班级列表（ClassList）
系号
字段
含义
类型
1
classID

uniqueidentifier
2
className

Varchar
3
SpecialtyID

uniqueidentifier
4
GradeID

uniqueidentifier
5
EnrollmentTime
入学时间
datetime
6
SchoolingLength
学制
int
7
Degree
学位
varchar
8
Status

bit

表3-4 专业列表（SpecialtyList）
系号
字段
含义
类型
1
SpecialtyID

uniqueidentifier
2
SpecialtyName

Varchar
3
AcademyID

uniqueidentifier
4
Status

bit

表3-5 学生基本信息表（StudentList）
系号
字段
含义
类型
1
StudentID

uniqueidentifier
2
StudentName

Varchar
3
ClassID

uniqueidentifier
4
Status

bit
5
Sex

bit
6
OffTime

datetime
7
OffCause

varchar
8
Predeposition

money
9
Balance
帐户余额
money

表3-6 操作人员（Users）
系号
字段
含义
类型
1
userID

uniqueidentifier
2
userName

Varchar
3
sex

bit
4
phone

Varchar
5
mamo

Varchar
6
userPWD

varchar

表3-7 职务列表（DutyList）
系号
字段
含义
类型
1
dutyID

uniqueidentifier
2
dutyName

Varchar
3
memo

varchar

表3-8 收费项目（ChargeItems）
系号
字段
含义
类型
1
ItemID

uniqueidentifier
2
ItemName

Varchar
3
TypeID

uniqueidentifier
4
Status

bit
5
memo

Varchar

表3-9 项目类别（ItemType）
系号
字段
含义
类型
1
TypeID

uniqueidentifier
2
TypeName

Varchar
3
Status

bit

表3-10 收款方式（GatheringMode）
系号
字段
含义
类型
1
ModeID

uniqueidentifier
2
ModeName

Varchar
3
Status

bit
4
RelationBank
与否与银行关联
bit
5
mamo

Varchar

表3-11 银行列表（BankList）
系号
字段
含义
类型
1
BankID

uniqueidentifier
2
BankName

Varchar
3
Status

varChar

表3-12 任务列表（ChargeTaskList）
系号
字段
含义
类型
1
TaskID

uniqueidentifier
2
TaskName

Varchar
3
TaskType

tinyint
4
CreateDate

datetime
5
Status

bit
6
RelateTaskID

uniqueidentifier

表3-13 任务项目列表
系号
字段
含义
类型
1
TaskID

uniqueidentifier
2
ItemID

uniqueidentifier

表3-14 X任务列表（TaskList）
系号
字段
含义
类型
1
StudentID

uniqueidentifier
2
ItemID

uniqueidentifier
3
AccountReceivable

money
4
Remission

money
5
Refundment

money
6
Gathering

money
7
ReceivableGist

Varchar
8
RemissionGist

Varchar
9
RefundmentGist

Varchar
10
CarryforwordMoney

decimal

数据库表关系图

3.4 输入输出设计
系统重要使用输出方式是屏幕显示，而系统重要输入方式是键盘输入。对输入数据是通过程序进行验证。
完毕系统设计阶段后，就可以进入系统实行阶段了。
4 系统实行
4.1 物理系统实行
该系统采用客户机/服务器体系构造，系统软件采用windows server 或windows server 以上版本。
4.2 程序设计
该系统采用客户机/服务器体系构造。程序设计按照应用层不同分为前台和后台，前台重要为数据收集、客户端信息解决和信息查询服务。后台程序重要完毕数据更新和数据访问。在后台采用Microsoft SQL Server 数据库系统，系统开发工具选取Microsoft Visual Studio .NET可视化集成开发环境
4.3 系统重要程序代码
在详细程序编写之前，先对App.config文献进行编辑，在App.config文献里可以定义应用程序全局变量。之因此在App.config文献中保存全局变量配备信息，而不是在每个窗体中定义变量，有两大长处。
一是减少代码，这样做将全局变量信息集中存储在一种文献中，而不是在每个窗体中都重复这样操作。例如数据库连接字符串，如果不集中存储在特定区域中，而是在应用程序每个需要连接数据库窗体上手工输入，可以设想，当数据库连接字符串改动时将会是一件令人头疼事，由于必要遍历应用程序中所有连接数据库页面去修改。
二是无需重新编译应用程序即可更新应用程序某些属性。当想把数据库迁移到另一种不同服务器时，只需修改App.config文献中数据库连接配备信息，并不需要重新编译和重新布置这个应用程序以适应新服务器规定。
App.config中，在标记“<appSettings>”和“</appSettings>”之间添加全局变量，用来添加数据库连接字符串，代码如下：

编写公共操作类(UtilClass)
在一种管理系统中，诸多办法、数据都是可以共享，为了减少重复劳动，可以建立某些公共类办法，提供统一数据读写办法。提高开发效率。
UtilClass 实现对公共操作办法封装，涉及执行无返回值SQL语句、执行数据库查询以及某些顾客控件数据绑定，通过对这些操作办法封装，以便开发。需要调用时，通过传递参数，选取不同办法，进行不同操作。
获取连接字符串

判断数据表中与否存在指定查询条件记录

DataGrid控件数据绑定

4.4 系统测试
系统采用白盒测试法。对于系统各功能模块采用单元测试法。
5 系统评估
此系统重要特色
² 界面和谐
熟悉Windows通用操作界面，亲切而体贴；
² 功能实用
涉及学籍管理、任务收费管理、寻常收费管理、学生预存管理、欠费管理、等惯用、实用功能；
² 安全可靠
操作员身份验证，操作功能模块严格授权，数据备份功能，给您数据提供多重保护；
² 操作简朴、工作轻松
此系统还没有真正实现与银行关联，数据输入需要手工输入。
6 结论
在开发此系统之前，对管理信息系统开发与设计很不纯熟，但通过这次毕业设计使我对信息系统开发有了很进一步理解。同步在系统实行过程中学到了诸多编程知识和技巧。但局限性是我当前编程技术还不够深，还不能完全完善这个系统。
参照文献
1. 黄梯云主编. 管理信息系统 . 高等教诲出版社.
2. 参照期刊镜像站有关文章
致 谢
在此，我要衷心感谢杨艳梅教师和刘军峰教师，她们给了我极大协助和勉励，特别是刘军峰教师，在她指引下使我对管理信息系统开发和设计有了更进一步理解，对我后来软件开发有着极大协助。再一次感谢两位教师对我指引和协助。
附 录
此附录提供本系统所有实当代码。