需求改进&系统设计
一、需求&原型改进：
1、对修改选题及需求进行修改
问题1：在实际采访在我当地超市的管理人员后，我了解到在乡镇的中小型超市管理层中，知识文化水平普遍不高，精通计算机专业知识的更是少之又少。
修改1：该程序要开发出简洁的前端界面，按键功能要尽可能明确写出对应功能，操作要符合用户直觉。
问题2：管理人员使用的计算机大多老旧，运行速度较慢，内存较小，不能支持一些最新的、高端的应用技术。
修改2：该超市管理系统程序的逻辑要简单且功能高度集成。在功能不变的情况之下要尽可能的压缩软件体积，简化软件的技术以提升该软件的兼容性。
问题3：现实使用中管理人员往往由于各种原因出现误操作现象，要对现实使用中管理人员的误操作作出预防及提出解决办法。
修改3：做出足够友好的用户界面，做到能通过界面中的信息让用户了解到操作内容及效果，在操作前提醒，误操作后用户可以通过及时的重启程序重新操作止损。
问题4：希望对商品的销售分析能够更加具体，有针对性。
修改4：定义了商品中大类的小类的属性，在进行商品的排行时，能够根据各商品对应种类进行排行，使分析结果更有价值。
问题5：现实中系统管理员往往兼职仓库管理员，工作是进货统计和平时仓库维护。
修改5:把系统管理员职位改为仓库管理员，并增添其增删查改各表的能力。
2.修改需求规格说明书
修改1：对3.1.1改为经理、仓库管理员、销售员
修改2：对3.1.2 权限设置改为下图
修改3：修改2.7.3数据库表的建立
登录系统账号密码数据库 （账号，密码，权限）
货物信息数据库(商品编号，名称，进货价格，出售价格，数量)
//注：商品编号分10位，前两位是大类（如家电类），1到6是小类（如冰箱），7到10是具体编号
职工信息数据库(工号，姓名，职位，手机号码)
货物出售数据库模块（商品编号，名称，单价，数量，总价，出售时间）
货物类数据库（小类编号6位，小类名字，大类编号2位（小类编号前两位），大类名字）
修改4：添加3.5 全系统流程图
修改5：典型用户及使用场景
|
姓名 |
性别 |
年龄 |
文化水平 |
职务 |
|
李龙 |
男 |
45 |
小学毕业 |
经理 |
|
王现 |
男 |
40 |
初中毕业 |
仓库管理员 |
|
莫玲 |
女 |
45 |
小学毕业 |
销售员 |
用户场景：
随着人力成本的不断提高和商品种类数量不断增加，加加超市陷入了花费过多资金在管理上的困境，严重影响了公司收益，老板在好友的推荐下，使用了该款超市管理系统。
李经理是一名乡镇超市经理，他需要超市货物进出情况，从而销售情况，来确定下次的进货时间，各按照销售员的业绩给予奖励。他登录超市管理系统后，能快速的在综合分析中查询到各商品销售情况、库存和利润排行，为他下次进货提供了参考，此外他还可以查询职工表对员工进行考勤，对不在岗的员工进行电话呼叫。
王先生是一名乡镇超市的仓库管理员，登录系统后他在进货时先选择货物的大类，在选择对应的小类，再再具体列表中找到对应的货物，输入其进货数量就能完成进货，如果找不到对应的大类小类或者商品，可以通过创建新类/新商品来快速解决。。
莫女士是一名乡镇超市的销售员，登录系统后可以通过简单的输入商品编号和售出的数量，就能反馈到数据库中。
3、功能分析
4、根据修改后的需求，调整任务分解WBS及相应的项目进度计划
时间分配：
前端页面设计 4天
主函数设计 4天
登录识别模块 4天
添加、修改登录系统账号密码数据库模块 4天
添加、修改货物信息数据库模块 4天
添加、修改、查询职工信息数据库模块 4天
添加、修改、查询货物出售数据库模块 4天
货物出入库明细 4天
货物库存查询 4天
超市流水时段分析 4天
商品销售排行分析 4天
某商品销售情况分析 4天
二、系统设计
1、架构设计
系统架构
前端设计
*开发语言：Java
前端模块
Login类（登陆界面）
Loginlistener类（登陆按钮的响应，登陆信息匹配，以及分配下一步动作）
Admin类（人员货物信息管理窗口以及信息处理）
Adminlistener类（处理相应一些按钮和栏位的响应）
Consumption类（消费模块的窗口）
Consumptionlistener类（消费模块一些按键以及信息处理）
Analyze类（处理综合分析窗口）
Analyzelistener类（处理综合分析的信息以及响应响应的按钮）
*登录界面展示
后端架构设计：
*范围：该设计用于THE BUG团队正在开发中的超市管理系统项目。超市管理系统项目是一款用于乡镇中小型超市的管理系统
*开发语言及原因：为了了达到我们的开发级需求———具有广泛的通用性，我们选择使用Java作为后端开发语言。且Java的开发难度相对较低，且我们团队中大部分成员基础相对薄弱，因此，我们认为后端采用Java进行开发是一个相当正确的选择。
*功能：后端系统主要有两部分功能，一部分是与数据库交互的功能，主要是对各数据库的修改，另一部分则是综合分析功能。
*架构约束：系统必须保证数据的安全访问，用户需通过用户名和密码来进行身份验证，同时对数据的访问要进行授权验证
2.数据库设计
三. Alpha任务分配计划
- 依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。
2对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
|
任务 |
负责人 |
|
前端页面设计 |
温海源、郑堡恩 |
|
添加、修改职工信息数据库模块 添货物出入库明细 货物库存查询 添加、修改货物出售数据库模块 添加、修改登录系统账号密码数据库模块 添加、修改货物信息数据库模块 添加、修改货物类数据库模块 |
杨梓琦 |
|
主函数设计 登录识别模块 |
李华 |
|
货物出入库明细 货物库存查询 超市流水时段分析 |
钟明康 |
|
某商品销售情况分析 商品销售排行分析 |
陈杰才 |
3.以甘特图的方式拟定迭代冲刺计划。
四、测试计划
1.引言
1.1项目背景
这是一个对中小型超市管理系统的测试计划。此次测试具有时间紧，任务急，但测试难度较小的特点，所有测试人员同时兼任开发者，是运用各自开发工具进行手动测试的计划。
1.2参考资料
《用户需求规格说明书5.19改》https://www.cnblogs.com/xiaoyangdeboke/p/12916959.html
1.3测试术语
1.4有关项目人员组成以及联系方式
|
开发及测试人员姓名 |
微信号 |
|
杨梓琦 |
aaa1970360218 |
|
郑堡恩 |
Husky_is_cool |
|
温海源 |
wxaid_ |
|
钟明康 |
tzczx915360686 |
|
李华 |
SuperTopspeed |
|
陈杰才 |
Oikawa777 |
2.任务概述
2.1测试范围
该超市管理系统各个功能模块及全系统功能。
2.2测试目标
在十周前完成所有测试
3.测试策略
3.1测试人员需求、分工
|
测试项目 |
负责人 |
|
前端模块 |
温海源、郑堡恩 |
|
添加、修改职工信息数据库模块 添加、修改货物出售数据库模块 添加、修改登录系统账号密码数据库模块 添加、修改货物信息数据库模块 添加、修改货物类数据库模块 |
杨梓琦 |
|
主函数设计 登录识别模块 |
李华 |
|
某商品销售情况分析 商品销售排行分析 |
陈杰才 |
|
货物出入库明细 货物库存查询 超市流水时段分析 |
钟明康 |
|
系统整体测试 |
全体成员 |
3.2测试方法：手动测试
3.3工具引用及测试培训：内训
3.4测试阶段计划（工作内容、人员安排、起止时间等）
|
测试阶段 |
测试项目 |
负责人 |
起止时间 |
|
各模块测试 |
前端模块 |
温海源、郑堡恩 |
2020.5.25-2020.5.26 |
|
添加、修改职工信息数据库模块 添货物出入库明细 货物库存查询 添加、修改货物出售数据库模块 添加、修改登录系统账号密码数据库模块 添加、修改货物信息数据库模块 添加、修改货物类数据库模块 |
杨梓琦 |
2020.5.25-2020.5.26 |
|
|
主函数设计 登录识别模块 |
李华 |
2020.5.25-2020.5.26 |
|
|
某商品销售情况分析 商品销售排行分析 |
陈杰才 |
2020.5.25-2020.5.26 |
|
|
货物出入库明细 货物库存查询 超市流水时段分析 |
钟明康 |
2020.5.25-2020.5.26 |
|
|
整体测试 |
系统整体测试 |
全体成员 |
2020.5.26-2020.5.27 |
3.5测试停止及恢复条件
|
停止条件： |
1.系统崩溃 2.系统响应时间超过10秒 3.程序运行结果或数据库中数据存储出错 |
|
恢复条件 |
1.程序可正常运行，无乱码 |
3.6测试环境 ：windows xp及以上系统
4．测试资源
4.1硬件资源需求
1.处理器CPU：Pentium 133M（以上）
2.内存容量RAM：64M+
4.2软件资源需求
安装 IDEA 或 Eclipse 软件
4.3测试环境需求
Windows xp及以上系统
4.4测试人员需求
1、熟练掌握IDEA 或 Eclipse测试技术。
2、能撰写简单的测试报告。
4.5其他（仪器、服务器等）
服务器
1.处理器CPU：Pentium 900M
2.内存容量RAM：256M+
5．风险评估
5.1人力方面；
人手充足，但是在各模块测试阶段各测试成员具有不可替代性，如果某一位测试成员因不可抗力因素不能参与测试，将带来至少延迟3天的后果，人力方面风险评估为较低。
5.2时间方面；
时间较为紧迫，在各成员都参与测试情况下预计各模块测试阶段由于个别成员学习进度较慢会延迟1-2天，整体测试阶段预计能在1天内完成任务，总测试时间预测延迟1-2天，时间方面风险评估为高。
5.3环境方面；
产品的市场定位具有稳定性，故在测试期间预计开发者不会对产品进行大的改动，环境方面风险评估为低。
5.4资源方面
测试所需要的知识都可以在网路以及书本上找到，故资源方面风险评估为极低。
5.5部门合作方面
此次测试任务由我们小组组内完成，具有沟通效率高的特点，故部门合作方面风险评估为极低。
6.输出文档
《项目测试计划书》
《项目测试报告书》
