
闽江学院软件学院-计算机办公应用2班-吴文俊
DSN – 版本 1.0.0.0
日期:2010-9-26
目 录
1.引言 3
1.1项目背景 3
1.2项目范围 3
2.1拓扑结构 4
2.2层次体系结构图 5
2.3校园数据结构图 6
2.4系统功能结构图 7
3. 校园一卡通系统业务流程图 8
4.所建议系统技术可行性分析 9
4.1对系统的简要描述 9
4.2与现有系统比较的优越性 10
4.3 采用建议系统可能带来的影响 10
4.4技术可行性评价 11
5 所建议系统经济可行性分析 11
5.1该系统对客户的影响: 11
5.2估算方案 11
5.3 具体项目总体估计 11
5.4收益 11
6.社会因素方面的可能性 11
6.1.法律方面的可行性 11
6.2.使用方面的可行性 12
7. 校园一卡通系统开发资源 12
7.1开发环境 12
8.工作进度安排 12
1.引言
1.1项目背景
项目的任务提出者:XX学院院长
开发者:软件工程系
用户:XX学院全体师生和员工
系统开发背景
随着社会信息化的蓬勃发展,校园的管理也进入了一个信息化的时代,先进的信息管理系统成为建设世纪一流大学的重要标志。在信息网络高速发展的今天,越来越多的信息均以数字形式进行交换和管理。伴随着智能技术的高速发展和计算机应用的普遍推广,在校园信息管理中引入IC卡应用正逐步成为一种趋势。
1.2项目范围
应用范围:
学生管理:注册、注销、成绩单。
身份识别:图书馆、计算中心、校医院。
交费:学费、上机、医疗。
用餐:餐厅、食堂、快餐店。
购物:百货商场、自选商场、商店、书店、教材部。
娱乐:俱乐部、娱乐中心、体育活动中心。
网上交易:INTERNET上网费、电话费、网上购物。
1.3目标
随着社会的进步与变革,各学校原有的消费和管理模式已不能适应新的发展要求,基于目前现状“一卡通”应运而生。所谓“一卡通”即在学校内,凡有现金、票证或需要识别身份的场合均采用卡来完成。此种管理模式代替了传统的消费管理模式,为学校管理带来了高效、方便与安全
项目具体需求:
① 部分子系统可以实现学生无人监管自助消费,并有详细记录,方便管理;
②减少工作人员对软件维护所花费的时间;
③减少管理人员,减轻工作人员劳动强度,提高工作效率;
④延长自动化系统的开放时间,甚至实现24小时不间断开放;
⑤免去打电话时,输入冗长的卡号、密码,实现轻松拨打;
⑥ 提高校园网使用率,设备利用率,可以在一定的程度上弥补学校维护和发展的经费。
2. 校园一卡通系统体系规划
2.1拓扑结构
根据校园环境和应用实践,考滤系统的实用性、方便性,既保证各部门间的相对性和系统的统一性及完整性,充分利用现代网络技术,采用了三种网络体系结构构造校园一卡通网络通讯平台。
2.2层次体系结构图
层次体系结构图可分为三层,表现层,业务层,数据层。
表现层具体表现方式即WEB
业务层具体的业务有借阅信息管理,书籍信息管理,读者信息管理,系统管理
数据层有SQL数据库,ORACLE数据库
2.3校园数据结构图
2.4系统功能结构图
现金充值
主要功能是持卡人在卡务中心直接用现金进行充值。并做帐务平衡处理。
结转充值
这种方式主要是在卡务中心将原有旧卡(正式卡已挂失、损坏或临时卡)的所有信息转入新的正式卡。
就餐管理模块
就餐管理接收持卡人实时就餐数据,并具有汇总、查询和打印功能。然后将所有发生的数据一并送到信息中心进行帐务平衡处理。
注册交费模块
学生注册之前应该将所有学生的注册状态置为未注册状态。学生注册时,将学生校园卡上的学费转到学校的财务总帐上,再把该学生的注册状态置为已注册状态,最后打印该学生的注册凭证。此模块还具有汇总、查询和打印功能。
帐务平衡模块
帐务平衡管理接收就餐数据和注册交费数据,再做帐务平衡处理。此模块还具有查询和打印总账平衡表的功能。
查询模块
持卡人可在查询机上持卡查询持卡人的所有信息。比如:所选课程、考试成绩、资金余额等等。
3. 校园一卡通系统业务流程图
4.所建议系统技术可行性分析
4.1对系统的简要描述
新系统在原有系统的基础上加入了新的数据库的支持,使用了先进的数据库技术与数据管理技术,使数据的准确性与安全性得到了很大的提高,且在用户的并行操作与用户管理方面也有了极大地改善。
一、 简单易用
本软件是在 Microsoft Windows环境下开发,采用了图形界面显示和鼠标的操作方式,同时提供良好的在线帮助信息。
二、丰富的功能
本系统的设计是建立在充分理解业务需求的基础之上的,合理的分配用户的业务功能及操作流程,功能丰富强大。
三、灵活方便
系统软件既可联网操作,又可单机使用,为用户提供了灵活的管理方式.
4.2与现有系统比较的优越性
在以上几点中已可以看出新系统的性能与功能上与现有系统的差别,首先新系统克服了原来系统的资金投入大,人员设备技术含量低,系统工作负担重等缺点。而且加入了对数据的安全性保护的功能,使原有系统在可用性与稳健性方面有了很大的进步。
Ⅰ 保密安全性好----虽然“校园一卡通综合应用系统”在一个相对封闭的环境中使用,但有一些功能的实现要在WEB上实现,所以要防止一些不良网络攻击或要防止一些重要的数据被别人查看或窜改。校园系统由于要和银行系统连接,相互之间除了一些公共的接口函数或相互交换的数据外,要求互相隔离。加之彼此间的数据交换要通过公共网络进行传输,所以要求保证传输的安全性。校园卡的使用也要保证安全,要求在校园内使用的校园卡读写设备具有自动识别功能,要求只有在本校办理的合法校园卡才能使用。同时校园内不同部门对数据库的操作要分别根据功能授权。
Ⅱ 大容量存储----一些部门每天要产生大量数据,例如食堂,按照一个一万人的学校,每日3餐就会至少产生十万条记录,这样要求有大容量的存储设备和大型数据库来处理。
Ⅲ 响应速度快----有一些应用要求有极高的响应速度。例如在学生就餐集中的时间段要求能及时作出响应。而且通过网络从数据库中读取数据也要求在很短的时间内完成。所以读写设备和网络必须具备比较高的速度。
数据接口要规范----对学校和银行的信息交换数据,要求规范双方数据格式和数据交换方式。要为以后进一步拓展应用提供可靠和友好的接口。
Ⅳ 系统稳定性好----系统要求能长时间运行,对于存放数据的服务器要求具有连续24小时工作能力。因此要求保证软件和硬件的可靠性。
Ⅴ自动化程度高--由于数据库中的大量数据,许多原先由财务部门处理的业务要求由计算机完成,因此很多功能要求能自动完成,例如每天每人的帐务平衡以及学校和银行的转帐和对帐,财务不平衡的自动提示功能等。
Ⅵ 容易操作管理----由于“校园一卡通系统”在校内不同部门应用,许多部门的管理人员是非计算机专业人员,要求操作界面要根据不同的工作环境情况进行设计。一方面便于管理人员操作,另一方面使管理人员在其权限范围内便于维护。
4.3 采用建议系统可能带来的影响
(1).设备:采用建议系统后,改进了原有系统的性能所以对设备要求自然更高,建议系统使用了最先进的技术使设备也必须跟着升级。
(2).现有软件:由于建议系统采用了先进的数据库技术以及一系列高技术含量软件,使得原来系统上的一些软件无法继续使用,不过在新系统开发过程中将尽量考虑到,对现有软件的兼容性。
(3).用户:建议系统使用的新技术是完全基于原有的系统上的,故用户不必考虑新系统带来的人员培训等等。
4.4技术可行性评价
校园一卡通系统是架构在校园网上,以感应式射频IC卡为媒介,综合提供身份识别与电子支付服务功能的系统平台,以及其架构在此平台上的各种信息化应用系统。 校园一卡通的平台是数字校园总体规划中的基础平台设施之一,与共享数据中心等其它基础平台协调共存,可以为新建的和原有的各种信息化应用系统综合提供统一的身份识别与统一的电子支付服务,凡是需要确认身份及付费的各种应用都可以用校园卡来实现。身份识别可以提供多级安全认证强度,电子支付连接银行系统可以提供各种支付和清算业务。
5 所建议系统经济可行性分析
5.1该系统对客户的影响:
建议系统是为了改善原有系统在经费支出过高的缺点的,所以新系统一经使用在经费支出方面一定会得到很好的改善,用户在使用了新系统后只需要花一定资金购买一部分计算机与软件就能实现自动化.
5.2估算方案
本系统完全按开发计划进行估算,办公用品的消耗,办公设备的消耗,开发人员生活与维护(包括水、电、房、工作餐)等。
5.3 具体项目总体估计
本系统大约总体耗费为10000元。
5.4收益
(1)提高工作效率
(2)减少工作人员
6.社会因素方面的可能性
6.1.法律方面的可行性
合同责任:符合国家标准的合同,经双方签字后生效
侵犯专利权:有
侵犯版权:有
6.2.使用方面的可行性
用户单位的行政管理:自定
工作制度:自定
人员素质等能否满足要求:可以满足
据相关统计,截止到目前,全国校园卡(一卡通)发卡量已超过1亿张,成为继银行卡、电信卡 (包括各种IC卡、IP卡、手机卡)之后的第三大卡。2000-2006年间,已经建设的真正意义上的一卡通工程累计有200多所。按照目前的建设进度,预测有80%左右的高校在近几年将投入校园一卡通或数字校园建设项目,校园一卡通系统建设成为高校信息化的必然趋势。 总之,经过研究,此系统的用户无使用方面的问题。
7. 校园一卡通系统开发资源
7.1开发环境
(1)主要开发平台
Windows 2000 Server / Professional 操作系统平台
(2)主要编程语言VB
(3)数据库开发平台SQL
(4)数据库设计辅助
7.2运行环境
服务器端(操作系统,数据库,WEB服务器,运行库)
客户端(浏览口)
8.工作进度安排
校园一卡通系统工作进度安排可分为四个阶段,首先是分析阶段这个阶段预算时间为5天,然后是设计阶段,此阶段所需天数为8天,写代码及单元测试所需天数为10天,最后是总测试及修改阶段,所需天数为15天。
| 名称 | 所需天数 | 工作启动时间说明 |
| 分析阶段 | 5 | |
| 设计阶段 | 8 | 分析结束后 |
| 写代码及单元测试阶段 | 10 | 可与设计同步 |
| 总测试及修改阶段 | 15 | 所有工作结束后 |
