实例1-学校教材订购系统.doc

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销售子系统模块程序流程图

① 购书单错误信息显示
② 登记购书记录错误信息显示
③ 修改表错误信息显示
2.2.2采购子系统模块程序流程图

① 缺书单错误信息显示
② 登记错误信息显示
③ 修改错误信息显示
2.3存储分配
为程序当中的数据结构在内存中开辟空间存储，加入到数据库中后在数据库的表中为其开辟存储空间。
2.4限制条件
输入的信息都封装在数据结构当中，不能独立存在，在向数据库中提交数据时必须一起提交而不能逐项提交。输入数据的类型必须和定义的数据类型相匹配。

测试计划
1.测试方法与用例设计
1.1测试目的
测试的实施是对软件规格说明、设计规格说明和编码的最终审核。软件测试的目的是以最少的人力、物力和时间投入，尽可能多地找出软件中潜在的各种错误和缺陷。测试的结果为软件可靠性分析提供了依据。
1.2测试内容
测试库存数，订单数，缺货数
1.3测试步骤
(1)单元测试:
单元测试也称模块测试或程序测试，单元测试是对每个模块单独进行的，验证数据是否与模块一致，检查各个模块是否正确实现规定的功能，对模块的所有主要处理路径进行测试且与预期的结构进行对照，还要对所有错误处理路径进行测试，从而发现模块在编码中或算法中的错误。
(2)集成测试:
集成测试也称组合测试或子系统测试，通常采用自上而下或自下而上的测试方法。集成测试的对象是指已经通过单元测试的模块，不是对零散模块进行单个测试，而是用系统化的方法装配和测试软件系统。
(3)确认测试:
确认测试又称有效性测试。它的任务是检查软件的功能与性能是否与要求规格说明书中确定的指标相吻合。
(4)系统测试:
系统测试是对整体性能的测试，主要解决各子系统之间的数据通信和数据共享问题以及检测系统是否达到用户的实际要求，系统测试的依据是系统分析报告。系统测试应在系统的整个范围内进行，这种测试不只对软件进行，而是对构成系统的硬件和软件一起进行。
(5)用户验收测试:
在系统测试完成后，进行用户的验收测试，它是用户在实际应用环境中所进行的真实数据测试。
在具体的测试中，一般应遵循以下原则：由程序设计者之外的人进行测试；测试用例应由两部分组成：输入数据和预期输出结果；选用不合理的输入数据与非法输入测试；不仅要检验程序是否实现预期功能，还应检查程序是否做了不应该做的工作；集中测试容易出错的程序模块；对程序求该以后，必须重新进行测试。
1.4测试用例设计
1.4.1白盒测试（结构化测试）

1.4.2黑盒测试（功能测试）
通过采用错误推测法可列举出程序中所有可能有的错误和容易发上的特殊情况：
① 库存数、订单数、缺货数<0
② 是否有不正确或遗漏了的功能
③ 在函数传递的过程中，能否正确的接受输入数据，能否产生正确的输出信息
④ 性能上是否满足要求
根据以上情况设计测试用例：
正确输入：教材编号：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.重新确定新的系统；