实例1学校教材订购系统.docx
《实例1学校教材订购系统.docx》由会员分享，可在线阅读，更多相关《实例1学校教材订购系统.docx（16页珍藏版）》请在冰豆网上搜索。
实例1学校教材订购系统
1.引言
1.1编写目的
对学校教材订购系统进行初步设计
1.2项目背景
名称:
学校教材订购系统
本项目的用户:
学校的学生，老师和教材订购管理员
本项目与其它软件或其他系统的关系:
工作于windows所有的系统
1.3参考资料
软件工程—理论、方式与实践
1.4系统简介
本系统可以细化为两个子系统：
销售系统和采购系统
销售系统的主要工作进程为：
首先由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生可以到书库领书。
采购系统的主要工作进程为：
若是教材脱销，则记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
1.5技术要求及限定条件
（1）当书库中的各类书籍数量发生转变（包括进书和出书）时，都应修改相关的书库记录，如库存表或进/出库表。
（2）在实现上述销售和采购的工作进程时，需考虑有关的合法性验证。
（3）系统的外部项至少包括：
教师、学生和教材工作人员。
系统的相关数据存储至少包括：
购书表、库存表、缺书记录表、待购教材表、进库表和出库表。
需求说明书
1.需求分析的目的
需求分析对学校教材订购系统进行简单的分析，给出了系统的数据流图。
加深与用户间的交流，在功能与系统界面上与用户达到一致的观点，以便于开发出用户满意的系统。
2.软件产品的作用范围
学校教材订购系统是为大多数教育院校开发的，用于日常的教材管理，包括销售与采购。
提供数字化的管理，提高学校教材管理部门的工作效率。
3.一般性描述
本系统可以细化为两个子系统：
销售系统和采购系统
销售系统的主要工作进程为：
首先由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生可以到书库领书。
采购系统的主要工作进程为：
若是教材脱销，则记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
4.产品功能
本系统在向学生售书时主要输入学生学号、班级代号、购书数量、购书书名信息，然后打印领书单返回给学生领取书籍。
本系统在采购图书进程中，图书发行人员需将脱销教材的编号、书名、出版社信息、版本号等一系列信息打印给书库采购人员，一旦新书入库后，即发进书通知给教材发行人员。
5.数据流图与数据字典
顶层数据流图
0层数据流图
1层数据流图
概要设计说明书
1.引言
1.1概念
1.1.1专门术语
购书表：
寄存提交的购书信息。
库存表：
寄存库中存在的书籍数据。
缺书记录表：
寄存缺少的书籍信息。
待购教材表：
寄存待购的书籍信息。
入库表：
寄存入库书籍的数据。
出库表：
寄存已销售的书籍数据。
1.1.2缩写
系统：
若未特别指出，系统指本“学校教材订购系统”。
1.1.3系统相关数据存储模型
购书表模型如下：
编号
书名
书籍编号
出版社
数量
交易金额
交易日期
备注
1
2
…
库存表模型如下：
书籍编号
书名
作者
出版社
数量
类别
SW-01
SW-02
…
缺书记录表模型如下：
书名
书籍编号
出版社
数量
备注
A
B
…
待购教材表模型如下：
编号
书名
书籍编号
作者
出版社
数量
备注
1
2
…
入库表模型如下：
书名
书籍编号
作者
出版社
数量
进书日期
备注
A
B
…
出库表模型如下：
书名
书籍编号
数量
领书人姓名
开票人姓名
备注
A
B
…
2.整体设计
2.1需求概述
为方便教师、学生领书，教材发行人员处置各类单据，和采购人员采购需开发一个“学校教材订购系统”。
教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生可以到书库领书。
若是教材脱销，则记录缺书，发缺书单给书库采购人员；一旦新书入库后，即发进书通知给教材发行人员。
要求系统能有效、快速、安全、靠得住和无误的完成上述操作。
并要求系统易于操作，数据库利于保护。
2.2软件结构
2.2.1销售子系统
2.2.2采购子系统
3.功能模块
4.程序描述
4.1功能
销售子系统模块：
提交购书单、审核购书单、开发票、记录购书记录、返回领书单、修改和保护数据库中相应的表。
采购子系统模块：
发缺书单、记录缺书记录、打印待购书信息、发进书通知单、修改和保护数据库中相应的表。
4.2性能
（1）精度：
购书是由需求决定的，只要有缺书现象则会表现出来，但也因为这样，若是需要提前多购书籍的话，则需要管理人员的参与。
（2）时间要求：
订购需要提前若干天。
（3）靠得住性：
高
（4）灵活性：
在购书单未审核时，可以撤销订购或修改，一旦审核，则不能再修改。
4.3输入项目
销售子系统模块：
需要输入购书单中要求的信息（提交人姓名、订购书籍书名、数量、备注）。
采购子系统模块：
需要输入缺书单中要求的信息（脱销书籍书名、书籍编号、开票人姓名、交易金额、交易日期）。
4.4输出项目
销售子系统模块：
需要打印领书单（订购书籍书名、书籍编号、数量、领书人姓名），发票（订购书籍书名、书籍编号、开票人姓名、交易金额、交易日期）。
采购子系统模块：
需要打印进书通知单（书籍编号、书名、出版社、作者、数量、进书日期）。
详细设计说明书
1.引言
1.1编写目的
在学校教材订购系统中，已经对本系统所包括的子模块作了概要的茶树，这些子模块的具体功能将在以下取得详细的论述。
本阶段已在系统的整体设计的基础上，对学校教材订购系统做详细设计。
主要解决了实现该系统程序模块具体设计问题。
包括肯定算法，数据结构，模块接口的利用，数据库的动态操作等。
2.系统模块的详细设计
2.1系统功能模块示用意
销售子系统模块具体描述
销售系统的工作进程为：
首先由教师或学生提交购书单，经教材发行人员审核是有效购书单后，开发票、记录并返给教师或学生领书单，教师或学生可以到书库领书。
采购子系统模块具体描述
采购子系统工作进程为：
工作人员提交缺书单后，进行审查，无误后记录缺书，审核记录进程后，汇总缺书，生成采购表，采购结束后发进书通知单，最后更新相应表单，审核修改良程。
在以上各审核进程中发现错误时，返回上一层从头进行操作。
2.2程序逻辑
2.2.1销售子系统模块程序流程图
1购书单错误信息显示
2记录购书记录错误信息显示
3修改表错误信息显示
2.2.2采购子系统模块程序流程图
1缺书单错误信息显示
2记录错误信息显示
3修改错误信息显示
2.3存储分派
为程序当中的数据结构在内存中开辟空间存储，加入到数据库中后在数据库的表中为其开辟存储空间。
2.4限制条件
输入的信息都封装在数据结构当中，不能独立存在，在向数据库中提交数据时必需一路提交而不能逐项提交。
输入数据的类型必需和概念的数据类型相匹配。
测试计划
1.测试方式与用例设计
1.1测试目的
测试的实施是对软件规格说明、设计规格说明和编码的最终审核。
软件测试的目的是以最少的人力、物力和时间投入，尽可能多地找出软件中潜在的各类错误和缺点。
测试的结果为软件靠得住性分析提供了依据。
1.2测试内容
测试库存数，定单数，缺货数
1.3测试步骤
（1）单元测试:
单元测试也称模块测试或程序测试，单元测试是对每一个模块单独进行的，验证数据是不是与模块一致，检查各个模块是不是正确实现规定的功能，对模块的所有主要处置路径进行测试且与预期的结构进行对照，还要对所有错误处置路径进行测试，从而发现模块在编码中或算法中的错误。
（2）集成测试:
集成测试也称组合测试或子系统测试，通常采用自上而下或自下而上的测试方式。
集成测试的对象是指已经通过单元测试的模块，不是对零散模块进行单个测试，而是用系统化的方式装配和测试软件系统。
（3）确认测试:
确认测试又称有效性测试。
它的任务是检查软件的功能与性能是不是与要求规格说明书中肯定的指标相吻合。
（4）系统测试:
系统测试是对整体性能的测试，主要解决各子系统之间的数据通信和数据共享问题和检测系统是不是达到用户的实际要求，系统测试的依据是系统分析报告。
系统测试应在系统的整个范围内进行，这种测试不只对软件进行，而是对组成系统的硬件和软件一路进行。
（5）用户验收测试:
在系统测试完成后，进行用户的验收测试，它是用户在实际应用环境中所进行的真实数据测试。
在具体的测试中，一般应遵循以下原则：
由程序设计者之外的人进行测试；测试用例应由两部份组成：
输入数据和预期输出结果；选用不合理的输入数据与非法输入测试；不仅要查验程序是不是实现预期功能，还应检查程序是不是做了不该该做的工作；集中测试容易犯错的程序模块；对程序求该以后，必需从头进行测试。
1.4测试用例设计
1.4.1白盒测试（结构化测试）
1.4.2黑盒测试（功能测试）
通过采用错误推测法可列举出程序中所有可能有的错误和容易发上的特殊情况：
1库存数、定单数、缺货数<0
2是不是有不正确或遗漏了的功能
3在函数传递的进程中，可否正确的接受输入数据，可否产生正确的输出信息
4性能上是不是知足要求
按照以上情况设计测试用例：
正确输入：
教材编号：
SW-01
教材名称：
软件工程—理论、方式与实践
孙家广
出版社：
高等教育出版社
类别：
计算机
返回信息：
书籍信息添加成功
错误输入：
教材编号：
SW-02
教材名称：
数据结构与算法
张铭
类别：
计算机
返回信息：
输入信息不完整，请检查后填写完整
1.5测试情况分析
1.5.1测试用例执行情况
输入帐号和密码以后登岸系统，进入软件主界面，点击各按钮均能响应。
添加待购教材界面输入教材编号，作者信息等均能存入数据库，在待购教材信息界面能正确呈现待购教材信息。
通过测试系统大体达到设计要求，系统功能完整，错误处置正确，且能正确提示错误种类。
1.5.2建议
将系统的功能加倍完善；改写需求文档，设计文档，使系统的往后保护加倍方便；进行系统化，提高性能。
2.测试总结
总的来讲,软件通过测试,大体上达到需求分析阶段所提出的要求.同时软件的质量和靠得住性是可以接受的,但由于没有正式运行有些问题可能还发现不了,这些错误最终会被用户在利用进程中发现而需要在保护阶段更正它们。
可能的保护计划
1.大体工作：
a）检查用户需求说明书，对用户原来的需求做到心中有数；
b）同用户和开发人员商讨，明确保护的类型；
c） 检查程序和相应的文档；
d）肯定程序错误的性质与位置，或要增加功能的部份；
e） 研究程序修改可行性和修改可能引发的副作用；
f）对改变的部份进行编码；
g） 修改相应的程序文档和程序库
2.改良保护方式的一些建议：
a）利用结构化程序设计技术来修改程序；
b）鼓励保护人员与用户和开发人员彼此商讨问题；
c）成立和增强程序设计和文档标准；
d）改良现有软件的文档；
e）为检查保护工作的质量严格执行保护复审；
f）提高用户对保护工作的重视；
g）应以成批方式处置保护请求，而不是以分散的方式处置保护请求；
h）当软件被修改后，应该特别重视重复测试和重复确认；
i）应对保护人员增强应用领域新知识和新技术的培训，有利于弄好保护工作；
3.理解现有系统；
4.修改现有系统：
a）制定修改计划；
b）按计划修改系统
c）控制系统修改的波动效应（若是修改一个模块引发其他模块的改变则称为波动效应）
5.从头肯定新的系统；
升级会员 