团队作业3--需求改进&系统设计

这个作业属于哪个课程	软件工程
这个作业要求在哪里	团队作业3--需求改进&系统设计
这个作业的目标	明确需求、改进原型、系统设计和测试需求
团队Gitee仓库链接	Gitee鏈接

团队成员:

姓名	学号
蔡梓严（队长）	3122004686
刘睿	3122004697
吴炳辉	3122004709
陈翼	3122006207
林诗芸	3222004596
卢铭	3122007933
巫育平	3122004708

目录

• 1、需求&原型改进
  • 1.1、针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
  • 1.1.1、课堂问答 Q & A
  • 1.1.2、与用户沟通理解需求
  • 1.2、修改完善上周提交的需求规格说明书
  • 1.2.1、初稿不足之处
  • 1.2.2、相应具体改进内容
  • 1.3、功能分析的四个象限
  • 1.4、项目任务分解WBS和项目进度计划
  • 1.4.1、WBS
  • 1.4.2、更新项目进度计划
• 2、系统设计
  • 2.1、架构设计
  • 2.2、数据库设计
  • 2.2.1、用户信息和商品信息数据
  • 2.2.2、数据库整体ER图
• 3、Alpha任务分配计划
  • 3.1、在Product Backlog中选取待实现的功能项
  • 3.2、分解任务构成Sprint Backlog
  • 3.3、甘特图
• 4、测试计划
  • 4.1、相关引言
  • 4.1.1、项目背景
  • 4.1.2、参考资料
  • 4.1.3、测试术语
  • 4.1.4、有关项目人员组成
  • 4.2、任务概述
  • 4.2.1、测试范围
  • 4.2.2、测试目标
  • 4.2.3、测试策略
  • 4.3、测试资源
  • 4.3.1、硬件资源需求
  • 4.3.2、软件资源需求
  • 4.3.3、测试环境需求
  • 4.4、风险评估
  • 4.5、其他内容

1、需求&原型改进

1.1、针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改

1.1.1、课堂问答 Q & A

• 问题1：你们团队的选题与其他团队有相似之处，可以提出自己团队独特的设计是什么？与其他团队的不同之处？

• 修改1：其他同学的选题主要是大购物平台，类似于淘宝京东，里面的商品包罗万象，面向对象也是全用户；而我们的主要是小超市，里面的商品以日常用品和食物等为主，面向的也是特定对象。

• 问题2：目前市面上有了很成熟的购物系统，且都拥有了很多稳定的用户群体，你们团队从调研的东西中，发现了什么用价值的地方可以让你们的购物系统区别于其他平台的购物系统？

• 修改2：我们针对了身边的近期有购物行为的同学进行了一定的采访，发现有部分同学苦于支付方式单一的原因，不得不放弃某一个购物系统，所以我们打算在我们的超市系统中引入充值功能，该功能可以支持多种支付平台，方便用户的资金流转。但由于现实资金政策和资金安全的原因，目前该功能只能暂时搁置，或是引入月卡等方式作为代替。

• 问题3：在现实购物中，往往会遇到一种商品有不同规格的情况，（例如手机的不同内存配置），但在商品页面中却只显示该商品最低配置的价格，使得其他高配置商品因为高价格的显示受到影响，用户可能没有细看就跳过了高配置商品的浏览，只看到低配置的商品。对于这种情况，你们团队有没有什么相关的解决方案。

• 修改3：对于这个购物者的痛点，我们可以采用给商品添加配置或规格的标签，然后在搜索相关商品时，会显示筛选功能，用户可以以此来挑选出自己需要的商品规格或配置，然后商品页面就只会显示该配置的商品。而且我们还打算加入按价格升序排序的功能，使得用户更容易找到低价商品，减少用户在货比三家上消耗的时间。

1.1.2、与用户沟通理解需求

1.2、修改完善上周提交的需求规格说明书

1.2.1、初稿不足之处

• 不足1：在撰写初稿的时候，我们由对身边同学的采访得出了用户潜在的需求，但是由于采访人数较少且受访人员基本上都是本校学生，因生活环境相似可能导致结果存在较大的偶然性，所调研出需求可能只是小众的需求。
• 不足2：在撰写初稿的时候，我们认为超市的供货渠道相对单一，便没有打算加入个人商家的模块，但在通过用户调研之后，发现有个体商户有将自家商品投放至电商平台，我们也就发现了这类用户的需求

1.2.2、相应具体改进内容

• 改进1：本周不仅对身边同学进行更加深入的采访，还推出了问卷调查，让小组成员邀请身边人填写，这样我们采访得出的用户需求就不仅有是本校的学生，还有其他学校的学生，以及各类社会人士，调查结果更具备普遍性。
• 改进2：打算在后续的超市系统中加入商家注册功能，商家可以通过系统投放自家商品，或与周围自提点合作，将商品投放至自提点的功能。

1.3、功能分析的四个象限

功能分析的四个象限功能部分有：杀手功能（Core）和 外围功能（Context）。
需求的划分则分为：必要需求（Mission Critical）和 辅助需求（Enabling）。这四种划分结合起来，就得到了功能分析的四个象限。

• 第一象限 杀手功能 必要需求
  我们将采取“差异化”的办法，全力以赴投资在这个领域
• 第二象限 外围功能 必要需求
  我们将采取“抵消”的办法，快速地达到平均水平，对于大家都特别看重的功能，采取“优化”的办法，达到行业最佳。
• 第三象限 外围功能 辅助需求
  我们将采取“维持”的办法，以最低代价实现此功能。
• 第四象限 杀手功能 辅助需求
  对于这些不是用户的刚需，而是辅助的功能，我们将采取独特的办法：采现在不做等待好的时机，或者先小规模实验。
  

1.4、项目任务分解WBS和项目进度计划

1.4.1、WBS

在《构建之法》中，给了一个方案：分而治之（WBS）：从最终的产品开始，一层一层往下，把大型交付件（Deliverable）分割为小型、具体的交付件。
我们决定采用之：从最终的超市系统开始，一层一层往下，把4个大模块交付件分割为更小、具体的功能块。下图为我们团队超市系统的WBS图：

1.4.2、更新项目进度计划

时间	任务
4.10~4.17	1.团队组队、团队博客 （已完成）
	2.团队介绍、成员展示、角色分配、选题确定 （已完成）
	3.制定团队计划安排，团队贡献分的规定 （已完成）
4.17~4.23	1.需求规格说明书 （已完成）
	2.原型设计，队员估计任务难度并学习必要的技术 （已完成）
	3.编码规范完成、平台环境搭建完成、初步架构搭建 （已完成）
4.24~5.4	1.原型改进（给目标用户展现原型，并进一步理解需求）（已完成）
	2.架构设计，WBS, 团队成员估计各自任务所需时间 （已完成）
	3.测试计划 ，队员学习必要的技术 （已完成）
5.5~5.14	1. 团队项目Alpha任务分配计划
	2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交
5.15~5.21	1.用户反馈+测试计划改进
	2. 团队Alpha阶段个人总结
	3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理
5.22~5.28	1. 团队项目Alpha博客：事后分析

2、系统设计

2.1、架构设计

由需求，我们可以分析出：

1. 管理员用户：需要能够添加商品类型以及商品，能够对商品进行管理，能够查询用户信息，能够查询出售记录；
2. 普通用户：需要能够搜索商品并执行购买商品操作。能够查询购买记录，能够对余额进行充值。
3. 注册：能够进行新用户的注册。

由此我们的架构设计可以分三个大模块：

每个大模块下又分若干小模块：

1. 管理员模块：可以管理商品和商品类别，查看出售情况
   
2. 普通用户模块：可以搜索商品、购买商品操作、查询购买记录
   

2.2、数据库设计

2.2.1、用户信息和商品信息数据

2.2.2、数据库整体ER图

实体关系图（ER图）的文本描述：

1. GoodsType（商品类别）:
   • id: 主键，整型
   • goodsTypeName: 商品类别名称，字符串类型
   • goodsTypeDesc: 商品类别描述，字符串类型
2. Goods（商品）:
   • id: 主键，整型
   • goodsName: 商品名称，字符串类型
   • price: 商品价格，双精度浮点数
   • goodsTypeId: 外键，关联到GoodsType的id
   • goodsDesc: 商品描述，字符串类型
   • count: 库存数量，整型
3. ShopHistory（购物历史）:
   • id: 主键，整型
   • useid: 用户ID，整型
   • goodsid: 商品ID，整型
   • btime: 购买时间，字符串类型
   • count: 购买数量，整型
4. Shopping（购物车）:
   • id: 主键，整型
   • useid: 用户ID，整型
   • goodsid: 商品ID，整型
   • count: 商品数量，整型
5. User（用户）:
   • id: 主键，整型
   • userName: 用户名，字符串类型
   • password: 密码，字符串类型
   • userid: 用户标识符，整型
   • money: 余额，双精度浮点数
6. UserShopHistory（用户购物历史）:
   • id: 主键，整型
   • useid: 用户ID，整型
   • goodsid: 商品ID，整型
   • btime: 购买时间，字符串类型
   • count: 购买数量，整型

实体之间的关系如下：

• Goods 与 GoodsType 之间存在一对多关系，即一个商品类别可以包含多个商品。
• ShopHistory 和 User 之间存在多对一关系，因为一个用户可能有多个购物历史记录。
• Shopping 和 User 之间也是多对一关系，因为一个用户的购物车可以包含多个商品。

3、Alpha任务分配计划

3.1、在Product Backlog中选取待实现的功能项

3.2、分解任务构成Sprint Backlog

3.3、甘特图

4、测试计划

4.1、相关引言

4.1.1、项目背景

超市管理系统是用于管理超市内部商品库存、销售、员工等信息的软件系统。本测试计划旨在对超市管理系统进行全面测试，确保系统的功能和性能达到预期要求。

4.1.2、参考资料

软件需求定义书

软件概要设计文档

用户使用说明书

4.1.3、测试术语

功能测试：验证系统的各项功能是否符合需求规格说明书的要求
性能测试：测试系统在不同负载下的性能表现，如响应时间、吞吐量等
手动测试：通过人工操作进行测试，验证系统功能和性能
白盒测试：基于代码结构和逻辑进行测试，了解系统内部运行情况
压力测试：通过模拟大量用户或数据来测试系统的稳定性和性能表现
JIRA：一种用于项目管理和问题跟踪的工具
Selenium：一种用于自动化测试的工具，支持多种浏览器和操作系统

4.1.4、有关项目人员组成

开发人员：陈翼、卢铭
测试人员：林诗芸

4.2、任务概述

4.2.1、测试范围

功能测试：包括商品管理、销售管理、员工管理等功能的测试
性能测试：系统在多用户、大数据量情况下的性能测试

4.2.2、测试目标

验证系统功能符合需求规格说明书
测试系统在各种条件下的性能表现

4.2.3、测试策略

测试人员：2人
测试分工：功能测试负责人、性能测试负责人

测试方法：手动测试、白盒测试、压力测试
测试工具：JIRA、Selenium等

测试阶段计划：

测试阶段	工作内容	负责人	起止时间
功能测试	编写测试用例，执行测试	蔡梓严	2024.4.26
	分析结果，提交缺陷	蔡梓严	2024.4.27
性能测试	设计性能测试方案	林诗芸	2024.4.28
	执行性能测试	林诗芸	2024.4.29
	分析性能数据，提出建议	林诗芸	2024.4.30

测试停止条件：

• 达到预定的测试目标和测试计划中规定的测试用例执行数量。
• 发现了一定数量或严重性的缺陷，导致无法继续测试或需要重新规划测试。
• 测试环境或资源的不可用性或不稳定，影响测试的进行。
• 超出测试时间或预算限制，无法继续进行测试。

测试恢复条件：

• 当停止条件解决后，可以重新开始测试。
• 当测试环境或资源问题得到解决并恢复正常。
• 当缺陷得到修复并经过验证后，可以继续进行测试。
• 当重新规划测试并得到相关部门的批准后，可以继续测试。

4.3、测试资源

4.3.1、硬件资源需求

服务器：1台
工作站：3台

4.3.2、软件资源需求

操作系统：Windows Server 2016
数据库：MySQL
浏览器：Chrome

4.3.3、测试环境需求

网络稳定，数据库连接正常

4.4、风险评估

人力方面：测试人员不熟悉测试工具和方法

时间方面：测试时间不足以覆盖所有功能和性能测试

环境方面：测试环境不稳定

资源方面：缺少必要的测试工具和硬件资源

部门合作方面：开发部门未及时修复已发现的缺陷

4.5、其他内容

测试计划制定者：林诗芸
日期：2024年4月30日
评审人员：开发负责人、测试负责人、项目经理

以上为超市管理系统测试计划的基本内容，具体的测试用例、测试报告等内容将在测试过程中逐步完善。