高校学费收费治理信息系统分析与设计毕业设计.docx
《高校学费收费治理信息系统分析与设计毕业设计.docx》由会员分享,可在线阅读,更多相关《高校学费收费治理信息系统分析与设计毕业设计.docx(29页珍藏版)》请在冰豆网上搜索。
高校学费收费治理信息系统分析与设计毕业设计
高校学费收费治理信息系统分析与设计
经管0202李洪进
摘要随着校园网环境的建设和学校教务治理改革的进一步深化,学生收费的工作模式已经从原先的学校院系二级治理模式转变成学校一级治理模式。
本文提出的基于校园网的学生收费系统,采纳了Client/Server开发方式,给学生提供了灵活方便的收费效劳,提高了学校收费治理部门的工作效率,并为其它部门和相关人员提供实时收费信息效劳。
关键词学生收费系统;综合教务治理系统;结算中心;收费标准
AbstractWiththedevelopmentofcampusnetworkandthereformationofeducationaladministration,themodeoftuitionadministrationhaschangedintooneadministrativelevelfromtwoadministrativelevels.Thetuitionsystembasedoncampusnetwork,describedbythisarticle,adoptthemethodofC/S,providesconvenientserviceforstudents,improvesworkefficiencyoftuitionadministrationdepartment,andprovidesreal-timeinformationserviceforotherdepartmentsandpersons.
Keywordtuitionsystem;all-aroundeducationaladministrationsystem;centerofsettlingaccount,tuitionstandard
1绪论
1.1开发背景
近几年,很多高校都在不断扩招,扩招后的高校在加大硬件设备建设的同时,也在不断的调整、完善学校的教务治理,随着学校教务治理改革的进一步深化,教务治理各个环节的相关数据都由各个院系集中到学校,形成了全校性的网络共享数据库,缩短了信息流通的渠道,在数据的及时性、一致性、共享性等方面上都取得了显著成效。
为适应学校集中治理模式开发西安石油大学网上综合教务治理系统,大大增进了学校教务治理工作的标准化、科学化,为广大教师和学生提供了大量的信息效劳。
学生收费作为学校综合教务治理系统的一个重要环节,对教务系统的其它环节有着专门大的阻碍,专门是针对学生的治理。
旧的收费系统,功能简单,只是在必然程度减轻操作员的计算量,任务仍然很繁重、进程复杂、统计量大,而且容易犯错、不方便治理。
显然旧的系统已经不能知足此刻治理的要求,因此,学校决定采纳新的收费软件来完成操作人员大量的计算、统计、查询工作,减轻操作人员的工作量,提高工作效率。
同时能够为相关的部门提供及时的、准确的、完整的信息。
新的收费系统需要从教务处获取学生类别和收费标准,给注册、选课提供学生交费信息,同时给教务处、研究生部、财务处等部门提供收费信息效劳和决策支持。
(1)相关于旧的收费系统,要紧解决了以下问题:
所有学生直接去收费中心交费,平安方便,同时省去了很多麻烦。
学生能够依如实际情形通过现金、汇款、储蓄存折、支票等方式交费。
新的收费模式给其它部门和相关人员提供实时的统计查询功能。
学生交费与学生注册相关联,而学生注册与学生选课相关联,从而解决了学生拖费欠费的老问题。
(2)社会上其它的收费系统应用对象比较广,但功能不够具体,无法知足特定治理体制下的收费治理系统的要求
在系统开发之前咱们有必要对系统进行整体计划,确信系统的目标并进行可行性分析。
1.2新系统计划
1.2.1新系统整体目标设定及可行性分析
(1)新系统目标设定
高校学费收费治理信息系统的要紧目标是:
实现相关部门之间的信息共享,保证信息传递的准确、完整;采纳简捷的图形化人机界面,操作简单、容易,提高工作效率;对各类数据汇总,进行辅助决策。
(2)可行性分析
可行性分析主若是依照信息需求和资源环境等约束,判定高校学费收费治理信息系统的的必要性和可能性。
别离在技术、经济和开发环境上对高校的学费收费治理信息系统进行可行性研究。
(1)技术上的可行性。
一方面,学校有较好的科学治理基础,现行系统基础数据比较完整、合理。
有利于历史数据的转换和载入;另一方面,学校具有较好的运算机配置和网络实施,学校更有专门好的内部局域网。
新的系统不管在软件仍是硬件方面都可不能有大的困难。
(2)经济上的可行性。
经济上的可行性包括资金上的可得性和经济上的合理性。
资金上的可得性。
学校高层领导十分重视学校信息化建设,对各项信息建设都有足够的资金投入,因此在资金上的需求不成问题。
经济上的合理性。
系统带来的经济效益要紧表此刻间接的效益上,这些间接效益表此刻:
节省了人力,降低了劳动强度;通过运算机治理,降低了本钱和其他治理费用;提供专门好的汇总和查询功能,能够进行辅助决策;为相关的部门提供及时、准确的共享信息。
(3)治理上的可行性。
学校合理的治理体制,为现行系统提供了比较完整的基础数据,也为新系统的运行提供了保障。
(4)开发环境上的可行性。
该系统的开发取得了组织中各层人员的支持配合,给系统开发提供了一个专门好的开发环境。
1.2.2开发方式及工具的选用
该系统采纳客户机/效劳器体系结构。
系统开发采纳面向对象系统开发方式,程序设计依照顾用层的不同分为前台和后台,前台要紧为数据搜集、客户端信息处置和信息查询效劳。
后台的程序要紧完成数据更新和数据访问。
在后台采纳MicrosoftSQLServer2000数据库系统,系统开发工具选择MicrosoftVisualStudio2003.NET可视化集成开发环境
在完成新系统的整体计划和可行性分析和可行性研究报告取得批准后,就进入了系统分析和设计时期。
2系统需求分析
这部份要紧完成系统的治理结构分析和功能需求分析。
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.3.2数据流程分析
依照本科生收费治理业务流程图,能够得出本科生收费治理顶层DFD图。
如下:
对顶层数据流程图2-2进行细分
大体信息治理模块的数据流程图如下:
收费治理的数据流程图如下:
收费任务数据流程图如下:
2.3.3数据字典
前时期的分析搜集了大量的数据载体,但这些数据还比较分散,只能局部反映组织的某项业务或部门对数据要求和现有的数据情形。
为了对数据进行统一治理、存储和操作,就应该在数据流程进行描述之前将所有的数据进行统一的标准化处置。
数据流程图描述了系统的分解,即描述了系统由哪些部份组成和各部份之间的联系等,但没有具体说明系统各部份的含义。
借助数据字典能够描述数据流程图中的数据流、数据存储、处置进程和外部实体。
系统成立的数据字典如下:
表2-1学生数据结构
数据结构
编号:
001
总编号:
1-001
名称:
学生基本信息
相关数据流、数据存储:
说明:
所有学生基本信息
班级信息、交费信息
结构:
学生编号
数量:
约20000份
学生姓名
性别
班级编号
当前状态
表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.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-4:
退费治理流程设计如图3-5:
学费减免治理流程设计如图3-6:
统计分析流程设计如图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银行