图 书 管 理 系 统
项目开发计划书
可行性研究报告
图书管理系统开发小组
负责人:龙金波
成员: 张斌
杨良华
董小华
指导老师:杜卓敏
20##年11月
软件计划书(图书管理系统)
引言:
编写目的及背景:
随着计算机及网络技术的飞速发展,Internet/Intranet应用在全球范围内日益普及,当今社会正快速向信息化社会前进,信息自动化的作用也越来越大。从而使我们从繁杂的事务中解放出来,提高了我们的工作效率。目前大部份的图书馆尤其是中小学的图书馆以及小型的书店还采用传统的人工方式管理图书,由此花费大量的人力物力,而且工作效率很低,不能及时了解图书的种类和学生们比较需求的图书等,不能更好的适应当前学生的借阅要求。而且手工管理还存在许多弊端,由于不可避免的人为因素,造成的数据的遗漏、误报。计算机信息化管理有着储存量大,速度快等许多优点,提供给我们的处理信息及时快捷,而由此决定开发该图书管理系统。相信有不少公司以及个人都开发过此类产品,其中不乏优秀的产品。我们开发此产品也许不如别人做的好,但此开发过程仅做为我们的实习作业,积累相应的经验,为以后的软件开发项目打下基础。开发出来的产品在经过严格的测试后,也可提供给某些用户使用,由此找出其中的不足并加以完善。
一.范围
1.1 项目名称:图书管理系统。
1.2 项目目标:实现对图书的自动管理,节省人力资源。主要面对小型图书馆以及中小学图书管理,还可用于部分小型书店。
1.3 主要功能:
1.3.1 面向图书馆管理人员:
进货后,完成对图书入库的录入工作,即数据采集(可通过条形码),将所有的数据录入数据库,并进行分类汇总。
1.3.2 办理借书证时的借书人员信息的录入:
借书时,记录借书日期,以及将相应的信息录入数据库以供检索使用。还书时对借书记录进行注销,并把相应的信息录入数据库以供检索使用。
1.3.3 面向借书人员:
提供友好的界面,使用户可查询在馆书目,以及用户的借书记录。还可提供预约借书服务。
1.3.4 面向图书租借管理人员:
新书进货后完成对新书的录入工作,可针对书店具体业务进行系统的二次开发。
1.3.5 面向顾客:
提供友好的界面,供顾客查询书店内的图书,以及新书预订等,这些可以由书店的二次开发来完成。
1.4 性能要求:
建立可根据图书馆规模以及书店的规模来确定需要存储的信息量的大小,最小求为10万册图书,图书馆为10000个借书者的信息。届时可根据具体的需求来重新设定信息量的大小。
录入信息时的响应时间不超过3秒,用户查询时间不超过3秒,具体响应时间应该视机器的具体配置。
其内部网络由用户自行决定,对于一般用户来说,一台微机即可,对于大一些的用户,可能使用一台服务器以及若干客户端机器。视具体用户而决定。
1.5 系统界面
界面友好,面对用户和管理人员用不同的界面,力求友好,使得操作简易,降低培训成本。系统提供诸多接口,例如word导入接口,以及SQL sever数据库的接口,方便用户操作。
1.6 开发概要:
1.6.1 调研和计划:
从10月20日开始着手此项目的开发过程,花一个星期左右的时间进行调研,了解各种不同用户对图书管理系统的不同需求,像图书租借机构、各种图书馆等,尽量使系统开发出来后能满足各方面的需求,即增加系统的实用性。在明确问题的性质、工程的目标及规模后,接下来的一个星期对该开发做一个可行性分析及总体的计划,作为以后开发的指导。
1.6.2 需求分析:
从11月6日左右到11月11月17日进行详细的需求分析,把现实的、抽象的问题具体化,大致设计出系统的逻辑模型。
1.6.3 设计:
分为概要设计和详细设计两个阶段进行,花五天左右时间进行概要设计,大致明确求解方案,设计出软件结构。花10天左右的时间进行详细设计,对各模块的功能给于说明,并作出详细的“设计说明书”。
1.6.4 编码和模块测试:
由于时间的限制,编码阶段有可能在下学期进行,所以这学期主要就是作出测试的计划和方案及可能出现的问题和解决方法,作出“测试报告”。
二. 资源
2.1 人力资源
本开发小组共四位成员,为武汉大学20##级计算机学院本科生。由于经费以及水平的限制,在各个阶段四位成员都参与开发,具体分工将在以后的各项说明书中指出。
2.2 硬件资源
个人电脑4台以及相应的网络设备、移动存储设备,条形码扫描仪,打印机等。
2.3 软件资源
Windows 98/NT/2000/XP操作系统,VC++开发语言,SQL SERVER 2000等。
三.安排和成本估算
四.进度与成本估算的说明:
由于没有经费投入,一切成本均由开发人员自行负担。微机及操作系统为现有的个人设备。其余软件资源可以由网上寻找。因此,成本估算也就无从谈起,主要投入为每个人的时间。主要时间为课余时间,因此具体进度可能会在开发过程中不断地调整。
五.可行性分析报告
5.1 引言
5.1.1 定义
Visual C++程序设计语言:它是Microsoft 公司开发的一种可视化软件开发工具,一种面向对象的编程语言。
Access:它是Microsoft 公司开发的一种具有强大功能的数据库。
图书馆管理系统是图书馆方便学生借阅图书资源快速有效的自动化查询系统。在此次的设计中采用Visual C++程序设计语言和ACCESS来实现本产品的软件部分。
BMS:Book Management System的简称,即:图书管理系统。
BMS-server:指数据服务器,安装在服务器端,它提供学生身份及借阅情况信息,图书数据库以及相关的应用处理程序。
BMS-client: 即信息处理工作站,装在管理人员的客户机上,其中客户机还要装上条形码扫瞄设备和打印机,用来输入学生信息,存储学生借阅信息以及相关内容。
BMS-pos:独立身份验证机,是一个相对独立的身份验证终端,可以独立工作,直接验证图书证的信息,也可以与PC连接,进行联机借阅信息判断处理。
5.1.2 参考资料
Ⅰ.《软件工程国家标准文档》 ——项目开发计划(GB856T——88)
可行性研究报告(GB8567——88)
Ⅱ.《软件工程原理与应用》 ——陈世鸿,朱福喜,黄水松,陈磊 编著
武汉大学出版社
Ⅲ.《软件工程》 ——王利福,张世琨,朱冰 编著
北京大学出版社
Ⅳ.《数据库原理与应用》 ——李昭原主编
科学出版社
Ⅴ. 《数据库系统概论》 ——萨师煊,王珊 编著
高等教育出版社
5.2 可行性研究前提
5.2.1 要求
A. 功能:设计一种智能检索图书并查询相应信息以及更新的图书管理系统
B. 性能:速度快,支持模糊查询
C. 输出:打印报表,如应用到图书馆管理,应有支持相应的借阅功能的服务
D. 输入:通过扫描条形码来录入图书数据
E. 简要处理流程:(略)
F. 在安全与保密方面的要求:只允许系统管理员修改数据库中相关信息,其他
没有管理员权限的人只享有访问查询的权限
G. 同本系统相连接的其他系统:远程访问(扩展中)
H. 完成期限:20##年12月24号
5.2.2 目标
四个人在2个星期的时间内完成系统
5.2.3 条件、假定和限制
假定:操作人员对该图书管理系统的基本流程基本熟悉,并且对一些基本的术语有所了解,由于资金不容许,因此,在涉及的有关验证,采集设备的时候就默认为对相应操作成功完成。
约束:开发小组有4名成员,均为武汉大学20##级本科生。开发项目管理的经验不足,开发经验不够丰富。项目开发经费只有150RMB,因此不可能做到将信息存储到相关设备上进行,故有一定的假定条件。另外开发期限在12.24前完成。
5.2.4 进行可行性研究的方法
该项可行性研究是在对现有的图书管理系统的调研上进行的,参考了武汉大学现行的图书馆管理模式,通过调查当前存在的图书资源利用不足的现象,并且对数据库理论进行研究得知通过计算机和网络资源可将图书资源透明化;
5.2.5 评价尺度
该系统只作实习作业,各项功能够实现,模拟中小型图书管理系统,不做商业用途
5.3 对现有系统的分析及对所建议的系统的建议
对现有的系统的分析主要基于对图书管理系统的调研上面,由于是我们的实习作业,所以就只对所建议的系统的建议提出自己的看法。
5.3.1 对所建议的系统的说明
该系统在学生微机上进行开发,主要实现功能为通过条形码扫描仪进行录入图书信息,存入数据库,通过界面对图书信息进行管理,支持模糊查询,能够通过打印机打印报表,提供管理员和用户两种权限,管理员具有修改,删除等权限,而普通用户只具有查询权限,在后续开发中可以考虑高级用户这一群体需要的权限(因为该系统还可应用到图书经销商上面),以及远程访问等新功能。
5.3.2 主要流程和数据流程
该流程图会在设计说明书里具体给予说明
5.4 影响
5.4.1 对设备的影响
除了对电脑自身配置有所要求外,还需要添加扫描仪,打印机等硬件设施
5.4.2 对软件的影响
不需要对现存的应用软件和支持软件进行修改
5.4.3 对用户单位机构的影响
操作人员的教育水平大约在高中文化,他们主要负责指纹的采集,入库与验证等基本的操作,不用深入了解操作原理。维护人员一般有大专以上的文化水平,主要负责维护产品的稳定性,可靠性,对所采集数据进行加密与维护,出现故障能够立即解决,能够解释基本的操作原理等。
5.4.4 对系统运行过程的影响
1.用户的操作规程:用扫描仪扫描图书信息,操作人员根据电脑提示进行相应操作
2.运行中心的操作规程:将获得的图书信息与源数据库中信息相比较,并根据比较结果打印相关信息
3.运行中心与用户之间的关系:运行中心进行数据处理,用户进行操作,为运行中心提供输入数据
4.源数据的处理:将源数据读入系统与数据库、条形码中数据进行比较
5.数据进入系统的过程:直接经过扫描仪扫描后进入系统
6.对数据保存的要求,对数据存储、恢复的处理:随时可以更新数据库,按时备份数据库
7.输出报告的处理过程、存储媒体和调度方法:直接根据比较信息打印输出结果
系统失效的后果及恢复的处理办法:图书数据库信息应该保存在不同的地方,当前使用的系统出现物理错误时可直接使用以前保存过的数据库,其他非物理性错误可由具备专业知识的维护人员负责解决。
5.4.5 对开发的影响
说明对开发的影响,如:
1.为了支持所建议系统的开发,用户需进行的工作:用户需说明所要求的系统实现那些功能
2.为了建立一个数据库所要求的数据资源:所有图书的信息
3.为了开发和测验所建议系统而需要的计算机资源:硬件资源要求CPU在P2之上,内存128M,硬盘12G以上;操作系统为WINDOWS 98以上。
4.所涉及的保密与安全问题:只允许系统管理员修改数据库中相关信息,其他没有管理员权限的人只享有访问的权利
5.4.6 对地点和设施的影响
5.4.7 对经费开发的影响
5.5 局限性
由于科研经费的有限,不能真正买到扫描仪,打印机等硬件设施,只能在自身拥有的条件下完成,因此,不能模拟真实情况进行,有些步骤仅仅属于理论性研究阶段,再由于本版本仅为初级版本,在某些地方可能不太完善,因此,还需要大量的验证,修改和更新。
5.6 可行性
5.6.1 技术方面的可行性
1.在当前的限制条件下,该系统的功能目标基本可以达到;
2.利用现有的技术该系统的功能可以实现;
3.4名开发人员,要求掌握软件开发过程及VC++编码技术;
4.在规定的期限内能够完成本系统的开发。
5.6.2 社会因素方面的可行性
由于图书资源浪费现象屡见不鲜,因此,要真正解决此现象,此系统的开发和研究是必要的,也是可行的,现在由学校提供科研经费,该项目小组完成该系统的研究和设计工作,故本项目具有开发研制条件。
5.6.3 法律方面的可行性
本软件暂定为试用,不涉及版权等方面的法律问题
5.6.4 使用方面的可行性
可用于中小学图书管理和图书经销商
5.7 结论
本系统根据计划安排进行。
结论有如下几点:
1.有基本的研究可行性,可以立即开始进行;
2.对于扫描仪和打印机部分暂时做理论研究,待相关设备准备好后进行实质研究。
3.因为经济原因,可能在有关步骤无法真正实现,只能理论研究。
总之,本项目技术成熟,完善,测试手段可靠,具有良好的社会效益和市场拓展,无论从哪方面讲都具有可行性。
第二篇:软件工程项目计划书
《项目计划书》
一、参赛作品构思的创意与价值(50%)
a) 背景:问题领域
ATM(自动柜员机)是银行为客户提供自动化的一种现代化电子设备,是银行电子化的一个重要组成部分。系统能为持卡人提供取款、存款、转帐、余额查询、更改密码等多种功能。它的广泛应用可提高银行工作效率,减少由于业务量增加对柜台产生的压力,同时又自动延长了银行的服务时间。
b) 问题:选题的动机与目的
由于各种原因ATM会出现机器故障或是ATM机与主机通信过程中发生丢包现象等事件,可能会出现如下一种情况:储户输入密码后取钱,而ATM机未将钱吐出。那么在这种情况下卡上的钱会不会少呢?若去另一个ATM机能够再取吗?为避免顾客的利益受到伤害,并保证系统的稳定性和可靠性,急需要设计一种较为可靠的机制使ATM机在最短的时间内恢复业务。
c) 研究:市场调查过程和评价结论
通过对ATM系统的学习和研究,其主要运作模式如图1.1所示,主要涉及到银联主机、前置机和ATM三者之间的信息交互。
图1.1 系统结构关系图
本设计主要解决在三者之间通信发生丢包现象时,导致ATM未能正常出钞,则进行自我修复,让客户不会感受到中间发生故障丢包的一系列处理过程,同时免去客户到银行进行冲正处理的繁琐过程,体现人性化设计。
d) 创意:参赛作品的构思描述
ATM机的通信部分主要分为两部分,一为前置机与主机的通信;另一为ATM机与前置机的通信。
通过顾客在取款过程中数据的备份、超时重传、实时打印等技术,尽量避免银行和顾客的利益受到伤害,保证系统的稳定性和可靠性。
e) 功效:最终呈现给用户的实际功效
当ATM出现故障时(发生丢包),客户没有取到钞票,则显示“系统处理中”,直到出钞,若时间超时,则显示退卡。
f) 评价:对创新的深度、广度的自我评价
本解决方案可以尽可能地保护储户的利益,即使在机器无法自动恢复的情况下,可以通过人为查看打印的交易记录来挽救故障造成的损失。为银行的ATM业务作出贡献,提升银行在顾客心中的地位。本设计可应用于各类银行ATM取款机中,具有通用性。
二、参赛作品的目标实现形式(20%)
(1) 参赛作品的最终呈现形式
本作品只为模拟ATM机的操作流程,由三个进程实现主机、前置机、和ATM机之间的通信,并实现开户、登录、查询、取款和存款等业务。
(2) 参赛作品的主要功能描述
储户插入银行卡后,ATM机获取银行卡信息,然后向前置机发出请求,前置机再将请求发送给主机,主机受到请求后检验银行卡号和密码的正确性,若正确则将储户信息返回给前置机。此时前置机通知ATM机可以进行下一步操作。储户此时可以选择查询余额、取款、存款等操作。若是取款操作,前置机会先扣去取款的面值,然后通知ATM机吐钱,若储户取款成功,前置机将修改后的储户数据提交给主机,主机保存数据,至此,通信过程结束。
(3) 参赛作品的实用性和未来可扩展性分析
本作品对提高ATM机系统的稳定性和可靠性具有相当大的作用,故具有很广的实用性,而且本作品采用模块化设计,可扩展性好。
三、参赛作品目标实现的可行性(20%)
(1) 参赛作品的主要技术路线
本设计主要解决在银联主机、前置机ATM机三者之间的通信丢包问题,用到的技术有:数据备份、超时重传、实时打印等技术,尽量避免发生ATM未出钞成功,而银行系统已交易完成的现象。
(2) 参赛作品的核心技术关键与实现可行性
当进行取款操作时,ATM、前置机和主机三者之间的数据交互可以抽象为如图3.1所示模型。
图3.1 取款业务原理图
通过分析,发生客户账户余额修改,而取款机未正常出钞的情况为银行主机收到请求完成数据库修,而ATM机并未收到应答命令,导致此种情况发生的原因可分为如下两种:
a)在主机向前置机发送应答时数据包丢失(即图3.1中③丢失),则采取如下方式进行改进:
前置机设置超时重发机制,如在发送请求后规定时间内为收到主机应答,则重发请求,主机收到请求后查询数据库看前置机余额是否与主机数据库中余额相同,若不同则重发应答,若相同则按正常请求处理。
b)在前置机向ATM机发送应答时数据包丢失(即图3.1中④丢失),则采取如下方式进行改进:
ATM机设置超时重发机制,如在发送请求后规定时间内未收到ATM机应答,则重发请求,前置机收到请求后查询该账户余额是否与ATM传送数据包中余额相同,若不同则重发应答,若相同则按正常请求处理。
由于以上两种情况同时发生的情况概率非常小,故在此不予考虑。
(3) 参赛团队的资源可行性
本团队由6人组成,对网络通信、软件设计、程序编写、软件测试等方面具有一定的基础,完全有能力在预期时间内完成本设计。
四、团队组成与角色分工(5%)
任务分配如表1.1所示。
表1.1 任务分配表
五、项目时间进度表(5%)