高校学费收费管理信息系统分析与设计
摘 要 随着校园网环境的建设和学校教务管理改革的进一步深化，学生收费的工作模式已经从原来的学校院系二级管理模式转变为学校一级管理模式。本文提出的基于校园网的学生收费系统，采用了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) 相对于旧的收费系统，主要解决了以下问题：
● 所有学生直接去收费中心交费，安全方便，同时省去了很多麻烦。
● 学生可以根据实际情况通过现金、汇款、储蓄存折、支票等方式交费。 ● 新的收费模式给其它部门和相关人员提供实时的统计查询功能。
学生交费与学生注册相关联，而学生注册与学生选课相关联，从而解决了学
生拖费欠费的老问题。
(2) 社会上其它的收费系统应用对象比较广，但功能不够具体，无法满足特定管理体制下的收费管理系统的要求
确定系统的目标并进行可行性分析。
1.2 新系统规划
1.2.1 新系统总体目标设定及可行性分析
(1) 新系统目标设定
高校学费收费管理信息系统的主要目标是：实现相关部门之间的信息共享，保证信息传递的准确、完整；采用简捷的图形化人机界面，操作简单、容易，提高工作效率；对各种数据汇总，进行辅助决策。 (2) 可行性分析
可行性分析主要是根据信息需求和资源环境等约束，判断高校学费收费管理信息系统的的必要性和可能性。分别在技术、经济和开发环境上对高校的学费收费管理信息系统进行可行性研究。 （1）技术上的可行性。
一方面，学校有较好的科学管理基础，现行系统基础数据比较完整、合理。有利于历史数据的转换和载入；另一方面，学校具有较好的计算机配置和网络实施，学校更有很好的内部局域网。新的系统无论在软件还是硬件方面都不会有大的困难。 （2）经济上的可行性。
经济上的可行性包括资金上的可得性和经济上的合理性。
资金上的可得性。学校高层领导十分重视学校信息化建设，对各项信息建设都有足够的资金投入，所以在资金上的需求不成问题。
经济上的合理性。系统带来的经济效益主要表现在间接的效益上，这些间接效益表现在：节省了人力，降低了劳动强度；通过计算机管理，降低了成本和其他管理费用；提供很好的汇总和查询功能，可以进行辅助决策；为相关的部门提供及时、准确的共享信息。
（3）管理上的可行性。学校合理的管理体制，为现行系统提供了比较完整的基础数据，也为新系统的运行提供了保障。
（4）开发环境上的可行性。该系统的开发得到了组织中各层人员的支持配合，给系统开发提供了一个很好的开发环境。 1.2.2 开发方法及工具的选用
该系统采用客户机/服务器体系结构。系统开发采用面向对象系统开发方法，程序设计按照应用层的不同分为前台和后台，前台主要为数据收集、客户端信息处理和信息查询服务。后台的程序主要完成数据更新和数据访问。在后台采用Microsoft SQL Server 2000 数据库系统，系统开发工具选择Microsoft Visual Studio 2003 .NET可视化集成开发环境
在完成新系统的总体规划和可行性分析以及可行性研究报告得到批准后，就进入了系统分析和设计阶段。
2 系统需求分析
这部分主要完成系统的管理结构分析和功能需求分析。
2.1 管理结构分析
前面了解到学校的收费管理模式发生转变，学校管理结构和领导层次关系也相应的发生改变。系统组织结构图如下：
2.2 系统功能需求分析
学费收费管理系统能够同时对本科生和研究生进行收费，但一些高校在本科生和研究生收费管理模式上有较大的区别。 2.2.1 本科生收费管理模式
本科生收费管理模式的基本流程如下：
1．招生办发出录取通知书后，新生就可以开始通过银行汇款进行交费，收费中心从银行获得新生所有汇款记录，手工录入数据库（也可以由银行提供批量数据，系统自动导入）。
2．新生报到前，收费中心从招生办获取新生数据和新生收费标准信息，以此核对新生汇款信息，最后确定所有正确汇款学生的名单。对学生汇款超过交费标准的部分进行“转储蓄”操作，转入银行帐号系统，并为其建立个人存折。新生报到时，收费中心负责为汇款学生打印收费收据，有转储蓄的打印存折（一般情况下，已经提前全部打完），没有汇款的新生和汇款不够的学生可以用现金和支票现场交费。
3．注册中心维护在校本科生的收费标准，本科生的收费标准针对一类学生，即每个学生通过“所属年级＋所属专业”确定他的收费标准，“所属年级＋所属专业”在学生学籍信息里维护。
4．本科生交费每年一次，一般要求一次能交清，但也允许先交一部分，在规定的时间内交清所欠部分，超过规定时间就按相关规定收取滞纳金。对于未交清学费的学生不给注册、一直欠费的学生禁止选课和期末考试。对于不用交费的学生通过设置
图2-1 组织结构图
收费标准应交为零实现。 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-6 基本信息录入DFD 图
收费管理的数据流程图如下：
图2-7 收费管理DFD 图
收费任务数据流程图如下：
图2-8 任务管理DFD 图
2.3.3 数据字典
前阶段的分析收集了大量的数据载体，但这些数据还比较分散，只能局部反映组织的某项业务或部门对数据要求和现有的数据情况。为了对数据进行统一管理、存储和操作，就应该在数据流程进行描述之前将所有的数据进行统一的规范化处理。 数据流程图描述了系统的分解，即描述了系统由哪些部分组成以及各部分之间的联系等，但没有具体说明系统各部分的含义。借助数据字典可以描述数据流程图中的数据流、数据存储、处理过程和外部实体。系统建立的数据字典如下：
3 系统设计
在设计与开发高校学费收费管理系统过程中，我们遵循学校教务管理的思路，以校园网络环境和全校性的网络共享数据库为基础，采用Client/Serve开发方式。结算中心、注册中心、研究生部等单位密切合作，为学生收费系统的顺利运行创造了有利环境。
3.1 功能结构设计
按照收费系统与其它信息系统或数据源之间的数据联系，以及系统本身的业务流程，可以将系统划分成四个功能模块。收费系统的功能模块图如下：
图3-1 收费系统主要功能模块图
根据功能模块的划分可得功能使用者的用例图，如下：
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 数据库设计
由系统分析报告可以设计以下的数据库表。
数据库表关系图
3.4 输入输出设计
系统主要使用的输出方式是屏幕显示，而系统的主要输入方式是键盘输入。对输入的数据是通过程序进行验证。
完成系统设计阶段后，就可以进入系统实施阶段了。
4 系统实施
4.1 物理系统实施
该系统采用客户机/服务器体系结构，系统软件采用windows server 2000或windows server 2000以上版本。 4.2 程序设计
该系统采用客户机/服务器体系结构。程序设计按照应用层的不同分为前台和后台，前台主要为数据收集、客户端信息处理和信息查询服务。后台的程序主要完成数据更新和数据访问。在后台采用Microsoft SQL Server 2000 数据库系统，系统开发工具选择Microsoft Visual Studio 2003 .NET可视化集成开发环境 4.3 系统主要程序代码
在具体的程序编写之前，先对App.config 文件进行编辑，在App.config 文件里可
以定义应用程序的全局变量。之所以在App.config 文件中保存全局变量配置信息，而不是在每个窗体中定义变量，有两大优点。
一是减少代码，这样做将全局变量信息集中存储在一个文件中，而不是在每个窗体中都重复这样的操作。比如数据库连接字符串，如果不集中存储在特定的区域中，而是在应用程序的每个需要连接数据库的窗体上手工输入，可以设想，当数据库连接字符串改动时将会是一件令人头疼的事，因为必须遍历应用程序中所有连接数据库的页面去修改。
二是无需重新编译应用程序即可更新应用程序的某些属性。当想把数据库迁移到另一个不同的服务器时，只需修改App.config 文件中的数据库连接配置信息，并不需要重新编译和重新部署这个应用程序以适应新的服务器要求。
App.config 中，在标记“”和“”之间添加全局变量，用来添加数据库连接字符串，代码如下：
编写公共操作类(UtilClass)
在一个管理系统中，很多的方法、数据都是可以共享的，为了减少重复的劳动，可以建立一些公共的类的方法，提供统一的数据读写方法。提高开发的效率。
UtilClass 实现对公共操作方法的封装，包括执行无返回值的SQL 语句、执行数据库查询以及一些用户控件的数据绑定，通过对这些操作方法的封装，方便开发。需要调用时，通过传递参数，选择不同的方法，进行不同的操作。
获取连接字符串
判断数据表中是否存在指定查询条件的记录
DataGrid 控件数据绑定
4.4 系统测试
系统采用白盒测试法。对于系统各功能模块采用单元测试法。
5 系统评估
此系统的主要特色 ✧ 界面友好
熟悉的Windows 通用操作界面，亲切而体贴； ✧ 功能实用
包括学籍管理、任务收费管理、日常收费管理、学生预存管理、欠费管理、
等常用、实用功能； ✧ 安全可靠
操作员身份验证，操作功能模块严格授权，数据备份功能，给您的数据提供
西安石油大学本科毕业设计
多重保护；
操作简单、工作轻松
此系统还没有真正实现与银行的关联，数据输入需要手工输入。
6 结论
在开发此系统之前，对管理信息系统开发与设计很不熟练，但经过这次毕业设计使我对信息系统开发有了很深入的理解。同时在系统的实施过程中学到了很多的编程知识和技巧。但不足的是我现在编程技术还不够深，还不能完全完善这个系统。
参考文献
1. 黄梯云主编. 管理信息系统 . 高等教育出版社. 2000
2. 参考期刊镜像站相关文章
致 谢
在此，我要衷心的感谢杨艳梅老师和刘军峰老师，他们给了我极大的帮助和鼓励，特别是刘军峰老师，在他的指导下使我对管理信息系统的开发和设计有了更深入的理解，对我以后的软件开发有着极大的帮助。再一次感谢两位老师的对我的指导和帮助。 附 录
此附录提供本系统全部的实现代码。
21
高校学费收费管理信息系统分析与设计
摘 要 随着校园网环境的建设和学校教务管理改革的进一步深化，学生收费的工作模式已经从原来的学校院系二级管理模式转变为学校一级管理模式。本文提出的基于校园网的学生收费系统，采用了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) 相对于旧的收费系统，主要解决了以下问题：
● 所有学生直接去收费中心交费，安全方便，同时省去了很多麻烦。
● 学生可以根据实际情况通过现金、汇款、储蓄存折、支票等方式交费。 ● 新的收费模式给其它部门和相关人员提供实时的统计查询功能。
学生交费与学生注册相关联，而学生注册与学生选课相关联，从而解决了学
生拖费欠费的老问题。
(2) 社会上其它的收费系统应用对象比较广，但功能不够具体，无法满足特定管理体制下的收费管理系统的要求
确定系统的目标并进行可行性分析。
1.2 新系统规划
1.2.1 新系统总体目标设定及可行性分析
(1) 新系统目标设定
高校学费收费管理信息系统的主要目标是：实现相关部门之间的信息共享，保证信息传递的准确、完整；采用简捷的图形化人机界面，操作简单、容易，提高工作效率；对各种数据汇总，进行辅助决策。 (2) 可行性分析
可行性分析主要是根据信息需求和资源环境等约束，判断高校学费收费管理信息系统的的必要性和可能性。分别在技术、经济和开发环境上对高校的学费收费管理信息系统进行可行性研究。 （1）技术上的可行性。
一方面，学校有较好的科学管理基础，现行系统基础数据比较完整、合理。有利于历史数据的转换和载入；另一方面，学校具有较好的计算机配置和网络实施，学校更有很好的内部局域网。新的系统无论在软件还是硬件方面都不会有大的困难。 （2）经济上的可行性。
经济上的可行性包括资金上的可得性和经济上的合理性。
资金上的可得性。学校高层领导十分重视学校信息化建设，对各项信息建设都有足够的资金投入，所以在资金上的需求不成问题。
经济上的合理性。系统带来的经济效益主要表现在间接的效益上，这些间接效益表现在：节省了人力，降低了劳动强度；通过计算机管理，降低了成本和其他管理费用；提供很好的汇总和查询功能，可以进行辅助决策；为相关的部门提供及时、准确的共享信息。
（3）管理上的可行性。学校合理的管理体制，为现行系统提供了比较完整的基础数据，也为新系统的运行提供了保障。
（4）开发环境上的可行性。该系统的开发得到了组织中各层人员的支持配合，给系统开发提供了一个很好的开发环境。 1.2.2 开发方法及工具的选用
该系统采用客户机/服务器体系结构。系统开发采用面向对象系统开发方法，程序设计按照应用层的不同分为前台和后台，前台主要为数据收集、客户端信息处理和信息查询服务。后台的程序主要完成数据更新和数据访问。在后台采用Microsoft SQL Server 2000 数据库系统，系统开发工具选择Microsoft Visual Studio 2003 .NET可视化集成开发环境
在完成新系统的总体规划和可行性分析以及可行性研究报告得到批准后，就进入了系统分析和设计阶段。
2 系统需求分析
这部分主要完成系统的管理结构分析和功能需求分析。
2.1 管理结构分析
前面了解到学校的收费管理模式发生转变，学校管理结构和领导层次关系也相应的发生改变。系统组织结构图如下：
2.2 系统功能需求分析
学费收费管理系统能够同时对本科生和研究生进行收费，但一些高校在本科生和研究生收费管理模式上有较大的区别。 2.2.1 本科生收费管理模式
本科生收费管理模式的基本流程如下：
1．招生办发出录取通知书后，新生就可以开始通过银行汇款进行交费，收费中心从银行获得新生所有汇款记录，手工录入数据库（也可以由银行提供批量数据，系统自动导入）。
2．新生报到前，收费中心从招生办获取新生数据和新生收费标准信息，以此核对新生汇款信息，最后确定所有正确汇款学生的名单。对学生汇款超过交费标准的部分进行“转储蓄”操作，转入银行帐号系统，并为其建立个人存折。新生报到时，收费中心负责为汇款学生打印收费收据，有转储蓄的打印存折（一般情况下，已经提前全部打完），没有汇款的新生和汇款不够的学生可以用现金和支票现场交费。
3．注册中心维护在校本科生的收费标准，本科生的收费标准针对一类学生，即每个学生通过“所属年级＋所属专业”确定他的收费标准，“所属年级＋所属专业”在学生学籍信息里维护。
4．本科生交费每年一次，一般要求一次能交清，但也允许先交一部分，在规定的时间内交清所欠部分，超过规定时间就按相关规定收取滞纳金。对于未交清学费的学生不给注册、一直欠费的学生禁止选课和期末考试。对于不用交费的学生通过设置
图2-1 组织结构图
收费标准应交为零实现。 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-6 基本信息录入DFD 图
收费管理的数据流程图如下：
图2-7 收费管理DFD 图
收费任务数据流程图如下：
图2-8 任务管理DFD 图
2.3.3 数据字典
前阶段的分析收集了大量的数据载体，但这些数据还比较分散，只能局部反映组织的某项业务或部门对数据要求和现有的数据情况。为了对数据进行统一管理、存储和操作，就应该在数据流程进行描述之前将所有的数据进行统一的规范化处理。 数据流程图描述了系统的分解，即描述了系统由哪些部分组成以及各部分之间的联系等，但没有具体说明系统各部分的含义。借助数据字典可以描述数据流程图中的数据流、数据存储、处理过程和外部实体。系统建立的数据字典如下：
3 系统设计
在设计与开发高校学费收费管理系统过程中，我们遵循学校教务管理的思路，以校园网络环境和全校性的网络共享数据库为基础，采用Client/Serve开发方式。结算中心、注册中心、研究生部等单位密切合作，为学生收费系统的顺利运行创造了有利环境。
3.1 功能结构设计
按照收费系统与其它信息系统或数据源之间的数据联系，以及系统本身的业务流程，可以将系统划分成四个功能模块。收费系统的功能模块图如下：
图3-1 收费系统主要功能模块图
根据功能模块的划分可得功能使用者的用例图，如下：
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 数据库设计
由系统分析报告可以设计以下的数据库表。
数据库表关系图
3.4 输入输出设计
系统主要使用的输出方式是屏幕显示，而系统的主要输入方式是键盘输入。对输入的数据是通过程序进行验证。
完成系统设计阶段后，就可以进入系统实施阶段了。
4 系统实施
4.1 物理系统实施
该系统采用客户机/服务器体系结构，系统软件采用windows server 2000或windows server 2000以上版本。 4.2 程序设计
该系统采用客户机/服务器体系结构。程序设计按照应用层的不同分为前台和后台，前台主要为数据收集、客户端信息处理和信息查询服务。后台的程序主要完成数据更新和数据访问。在后台采用Microsoft SQL Server 2000 数据库系统，系统开发工具选择Microsoft Visual Studio 2003 .NET可视化集成开发环境 4.3 系统主要程序代码
在具体的程序编写之前，先对App.config 文件进行编辑，在App.config 文件里可
以定义应用程序的全局变量。之所以在App.config 文件中保存全局变量配置信息，而不是在每个窗体中定义变量，有两大优点。
一是减少代码，这样做将全局变量信息集中存储在一个文件中，而不是在每个窗体中都重复这样的操作。比如数据库连接字符串，如果不集中存储在特定的区域中，而是在应用程序的每个需要连接数据库的窗体上手工输入，可以设想，当数据库连接字符串改动时将会是一件令人头疼的事，因为必须遍历应用程序中所有连接数据库的页面去修改。
二是无需重新编译应用程序即可更新应用程序的某些属性。当想把数据库迁移到另一个不同的服务器时，只需修改App.config 文件中的数据库连接配置信息，并不需要重新编译和重新部署这个应用程序以适应新的服务器要求。
App.config 中，在标记“”和“”之间添加全局变量，用来添加数据库连接字符串，代码如下：
编写公共操作类(UtilClass)
在一个管理系统中，很多的方法、数据都是可以共享的，为了减少重复的劳动，可以建立一些公共的类的方法，提供统一的数据读写方法。提高开发的效率。
UtilClass 实现对公共操作方法的封装，包括执行无返回值的SQL 语句、执行数据库查询以及一些用户控件的数据绑定，通过对这些操作方法的封装，方便开发。需要调用时，通过传递参数，选择不同的方法，进行不同的操作。
获取连接字符串
判断数据表中是否存在指定查询条件的记录
DataGrid 控件数据绑定
4.4 系统测试
系统采用白盒测试法。对于系统各功能模块采用单元测试法。
5 系统评估
此系统的主要特色 ✧ 界面友好
熟悉的Windows 通用操作界面，亲切而体贴； ✧ 功能实用
包括学籍管理、任务收费管理、日常收费管理、学生预存管理、欠费管理、
等常用、实用功能； ✧ 安全可靠
操作员身份验证，操作功能模块严格授权，数据备份功能，给您的数据提供
西安石油大学本科毕业设计
多重保护；
操作简单、工作轻松
此系统还没有真正实现与银行的关联，数据输入需要手工输入。
6 结论
在开发此系统之前，对管理信息系统开发与设计很不熟练，但经过这次毕业设计使我对信息系统开发有了很深入的理解。同时在系统的实施过程中学到了很多的编程知识和技巧。但不足的是我现在编程技术还不够深，还不能完全完善这个系统。
参考文献
1. 黄梯云主编. 管理信息系统 . 高等教育出版社. 2000
2. 参考期刊镜像站相关文章
致 谢
在此，我要衷心的感谢杨艳梅老师和刘军峰老师，他们给了我极大的帮助和鼓励，特别是刘军峰老师，在他的指导下使我对管理信息系统的开发和设计有了更深入的理解，对我以后的软件开发有着极大的帮助。再一次感谢两位老师的对我的指导和帮助。 附 录
此附录提供本系统全部的实现代码。
21