团队作业3--需求改进&系统设计
| 所属课程 | 软件工程导论 |
|---|---|
| 作业要求 | 团队作业3--需求改进&系统设计 |
| 作业目标 | 需求规格说明书改进、系统设计、Alpha任务分配计划、测试计划 |
| github链接 | CampusSecond-handMarket--NoBailanGroup |
| 项目网址 | http://www.stopyc.shop/second/ |
一、团队
1、团队名称：摆烂就不队
2、团队成员
| 姓名 | 班级 | 学号 |
|---|---|---|
| 林劲辰（组长） | 计科2班 | 3121004707 |
| 许庆阳 | 计科2班 | 3121004931 |
| 苏建澎 | 计科2班 | 3121005007 |
| 黎灿宇 | 计科2班 | 3121004867 |
| 伊尔凡江·艾合买提 | 计科2班 | 3121005017 |
| 鄞灿 | 计科2班 | 3121005018 |
| 于杨 | 计科2班 | 3221004940 |
二、需求&原型改进
1.问题与改进
针对课堂讨论环节老师和其他组的问题及建议，对修改选题及需求进行修改
问题一：如果面对大四毕业生，毕业之后不在学校又想出售二手商品，但是不在学校导致再二手交易的过程很麻烦，应该怎么解决？
修改一：在二手市场网站中增加托管机制，实现二手商品的寄售，但是要收取一定的托管费用，且增加仓库管理人员对二手商品进行管理。
问题二：二手商品在网站上交易成功后要怎么实现配送？
修改二：增加一个送货功能，可以让平时想兼职的同学对二手商品进行配送，并给予一定的费用，消费者和销售者可以在平台上看到二手商品的物流信息。类似滴滴司机的接单功能，想要通过送货兼职的同学可以在平台上接单。
问题三：对于前面提到的仓库管理人员和配送员，去哪里找这些人呢？
修改三：我们决定增加一个兼职板块，平时想要赚取生活费的同学可以在这个板块寻找兼职，其中包括二手商品配送员，仓库管理人员等
与用户沟通
2、修改完善需求规格说明书
上周的《需求规格说明书》中，对二手交易市场的功能分析和需求不够充分，功能方面没有考虑到毕业生不在学校如何进行二手商品的交易，且二手商品主要由毕业生进行出售，所以我们增加了二手商品的寄售功能，对于不在校的同学，二手商品可以寄往平台进行托管销售，但要收取一定的托管费中，且增加了仓库管理人员负责对这些寄售的商品进行管理；且我们的平台只考虑到如何实现二手商品的交易，并没有考虑到如何将二手商品送到消费者手中，于是我们增加了配送模块和兼职模块，平时想要赚取生活费的同学可以通过这个兼职对二手商品进行配送。对于前面说到的兼职，我们增加了兼职模块，其中包括二手商品配送员和仓库管理人员，每个职位对应不同的报酬，想要兼职的同学可以在这个职位选取相应的职位，既解决了二手商品的托管和配送问题，还让兼职的同学多了选择。
3、新增内容：
1、商品管理
•发布物品：卖家可以发布商品，包括物品描述、发布时间地点、分类、照片、价格等。
•商品编辑：卖家可以随时编辑和更新物品信息。
•商品搜索：提供搜索功能，允许用户按类别，商品关键词等搜索商品。
•商品详情：每个商品页面包括详细描述、照片、价格和联系卖家的选项。
•商品状态：标明物品的状态，如已完成，缺货等
•商品评论：允许用户在商品页面上发表评论和评分。
•商品托管机制：大四师兄留下来的书籍实行托管制之类的，防止大一和大四时间差，怎么实现配送之类的
2、交易和支付
•购物车：允许用户将多个物品添加到购物车，以便一次性结账。
•支付选项：先充值到我的钱包中，支持多种支付方式，如微信、支付宝等，再用钱包中的钱支付。
•订单管理：用户可以查看和跟踪他们的订单状态。
•交易通知：向用户发送订单确认、付款和发货通知。
4、功能分析的四个象限
参考《构建之法》5节功能的定位和优先级，给出功能分析的四个象限
①必须做且重要（Must-haves）：
用户发布和浏览二手商品： 提供用户友好的界面，使毕业生可以方便地发布和浏览二手商品信息。确保商品信息包括必要的详细描述、价格和联系方式。
交易管理和托管： 实现交易的安全性和可控性，引入托管机制，为不在学校的毕业生提供寄售选择。设计仓库管理系统，确保托管商品的安全存放，增收一定的托管费用。
②必须做但不重要（Nice-to-haves）：
兼职板块： 创建一个专门的板块，供学生浏览和申请兼职，包括仓库管理人员和二手商品配送员。为平台提供人力资源，同时为学生提供赚取额外收入的机会。
物流信息： 引入送货功能，让平台上的兼职配送员可以接单并将商品送达消费者手中。为用户提供实时的物流信息，类似于滴滴司机的接单和配送过程。
③不必做但重要（Not-so-importants）：
优化用户体验： 确保平台的用户界面简洁直观，易于导航。考虑到用户体验的因素，例如快速加载、响应性和友好的设计，以提高用户留存率。
④不必做且不重要（Won't-haves）：
非关键性功能： 避免投入过多资源在一些不是核心业务的功能上，如高级社交功能。优先考虑满足核心业务需求。
5、调整任务分解WBS及相应的项目进度计划
根据修改后的需求，调整任务分解WBS及相应的项目进度计划
任务分解
改进的项目进度计划
| 时间 | 任务内容 |
|---|---|
| 第9周 | 1.团队组队、团队博客 |
| 2.团队介绍、成员展示、角色分配、选题确定 | |
| 3.制定团队计划安排，团队贡献分的规定 | |
| 第10周 | 1.需求规格说明书 |
| 2.原型设计，队员估计任务难度并学习必要的技术 | |
| 3.编码规范完成、平台环境搭建完成、初步架构搭建 | |
| 4、模拟测试，提出可能遇到的问题 | |
| 第12周 | 1.原型改进（给目标用户展现原型，并进一步理解需求） |
| 2.架构设计，WBS, 团队成员估计各自任务所需时间 | |
| 3.测试计划 | |
| 第13、14周 | 1. 团队项目Alpha任务分配计划 |
| 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 3. 邀请部分同学进行第一次用户测试 | |
| 第15周 | 1.用户反馈+测试计划改进 |
| 2. 团队Alpha阶段个人总结 | |
| 3. 发布说明、测试报告、展示博客、项目管理 | |
| 4. 事后分析 |
三、系统设计
1、目的
本文档编写的目的在于阐明校园二手市场的功能需求与架构设计，通过本文档更好地了解校园二手市场系统的架构方案，为系统设计、编写、测试工作提供参考依据。
2、背景
校园二手交易市场是一个旨在为大学生提供便捷、安全、可靠的二手商品买卖平台的项目。在现代社会中，随着资源消费观念的变化和环保意识的增强，二手商品的需求逐渐增加。尤其是在校园环境中，学生们常常需要购买各类学习用品、生活用品以及娱乐设备等，而二手商品不仅价格相对较低，还能有效减少资源浪费，符合大学生的消费需求。
然而，目前校园内的二手交易往往存在以下问题：信息不透明、安全风险高、交易流程繁琐等。为了解决这些问题，我们决定开发一款校园二手交易市场应用，以提供一个便捷、安全、可信赖的平台，满足学生们的二手交易需求。
该应用将充分利用互联网和移动通信技术，采用B/S架构，为用户提供简单易用的界面和丰富的功能。用户可以通过应用发布自己想要出售的二手商品，也可以浏览他人发布的商品进行购买。同时，我们将提供用户登录注册、商品评论、消息通知、交易管理等功能，以提升用户体验和交易安全性。
用户特点：作为用户终端，基本都是一般的办公电脑，操作系统一般为Win7、Win10（可考虑后续会升级为Win11），一般使用主流的浏览器如Chrome、Edge、FireFox等。
3、系统业务架构图
4、系统架构详细说明
项目采用前后端分离架构，前端使用HTML、CSS和JavaScript开发用户界面，后台使用Spring MVC和MyBatis框架实现业务逻辑和数据持久化。通过RESTful API和HTTP协议实现前后端通信，实现用户、管理员、商品、订单、评论和通知等功能模块的交互。以下是对各模块之间联系的详细分析。
用户与管理员模块：
前端提供用户注册、登录、个人信息管理等功能，后台通过Spring MVC处理用户请求并调用相应的业务逻辑处理用户信息。管理员模块包括管理用户、商品、订单等功能，通过权限控制确保管理员操作的合法性，并向前端提供相应的管理界面。
商品模块：
前端展示商品列表、详情，支持搜索、筛选等功能，后台管理商品信息并提供商品数据接口供前端调用。在数据库中存储商品信息，如名称、价格、库存等，并通过MyBatis框架实现商品信息的增删改查。
订单模块：
用户可以浏览商品并下单，后台处理订单逻辑，包括生成订单、支付、配送等功能。订单信息存储在数据库中，并通过后台与前端进行交互，提供订单状态查询、支付接口等服务。
评论模块：
用户可以对商品进行评价，包括文字评价和评分，后台管理评论信息并与相应商品关联。前端展示商品评价信息，并提供用户评论提交功能，后台将评论信息存储在数据库中，并通过接口返回给前端。
通知模块：
系统可以向用户发送通知，如订单状态变更、活动信息等，后台管理通知内容和发送规则，将通知信息存储在数据库中，并通过业务接口向前端推送通知。
交互方式：
前后端通过RESTful API进行数据交互，前端发送HTTP请求到后台指定的接口路径，后台根据路由信息调用相应的Controller进行业务逻辑处理，并返回JSON格式的数据给前端。前端解析数据并进行页面渲染，实现用户与系统的交互
5、功能列表
| 模块分类 | 功能名称 | 模块功能 | 备注 |
|---|---|---|---|
| 管理员 | 登录 | 输入账户名密码登录获得管理员权限 | |
| 注册 | 添加普通管理员 | ||
| 删除 | 删除管理员 | ||
| 查询 | 查询全部管理员 | ||
| 用户 | 登录 | 输入账户名密码登录 | |
| 注册 | 注册新账号 | ||
| 通知 | 查询通知 | 获取商品评论的通知 | 区分管理员和游客 |
| 游客通知 | 获取游客的通知 | 区分管理员和游客 | |
| 读通知 | 消息已读 | ||
| 删通知 | 消息删除 | ||
| 商品 | 购买商品 | 用户购买商品 | |
| 查询商品 | 用户查询商品 | ||
| 发布商品 | 用户发布新商品 | ||
| 删除商品 | 用户删除商品 | ||
| 更新商品 | 用户更新商品 | ||
| 评论 | 评论商品 | 用户评论商品 | 需购买后才可评论 |
6、系统页面
7、数据库设计（ER图）
- 表
Users：这个表存储用户信息，包括用户ID、用户名、电子邮件和注册日期等字段。 - 表
Products：这个表用于存储产品信息，包括产品ID、产品名称、价格和描述等字段。 - 表
Orders：这个表用于记录订单信息，每个订单都有一个唯一的订单ID，以及与订单相关的用户ID和产品ID等字段。此外，还有一个代表订单日期的字段。 - 表
OrderItems：这个表用于记录订单中的产品项信息。每个订单可包含多个产品项，并通过订单ID和产品ID与Orders和Products表进行关联。此外，还有一个字段记录产品数量。 - 表
Categories：这个表用于存储产品类别信息，包括类别ID和类别名称等字段。
这些表之间通过外键建立关联，例如，Orders表中的用户ID外键关联到Users表的用户ID字段，OrderItems表中的订单ID和产品ID外键分别关联到Orders表和Products表的对应字段。 以上是简述的数据库设计内容，如果您有任何其他问题，请随时提问！😊
ER图
四、Alpha任务分配计划
1、Product Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项。
2、Sprint Backlog
对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。在PM的协助下，编码的同学对任务进行认领。
3、甘特图
以甘特图的方式拟定迭代冲刺计划。
五、测试计划
1.引言
1.1项目背景
校园二手交易市场：
本系统主要面向于大学校园网用户，依托校园网提供给这些用户一个发布和交流二手商品信息的平台。在大学校园里，存在着很多的二手商品，但是由于信息资源的不流通以及传统二手商品信息交流方式的笨拙，导致了很多仍然具有一定价值或者具有非常价值的二手商品的囤积，乃至被当作废弃物处理。现在通过进入到本系统，可以方便快捷的发布和交流任何二手商品的信息，并且可以通过留言方式进行深一步的交流。希望本系统的运营不仅可以为同学的校园生活提供便利，而且可以让更多有价值的资源得到利用。
1.2参考资料（计划编写依据：可行性分析报告／软件需求定义／软件概要设计／软件详细设计／用户使用说明书／……）
https://www.cnblogs.com/itest/archive/2008/06/24/1229151.html
1.3测试术语
测试用例（Test Case）：描述了对软件特定功能或场景的测试步骤、预期结果和实际结果的文档或脚本。
缺陷（Defect）：在软件中发现的错误、问题或不符合规范的地方，需要被修复。
自动化测试（Automated Testing）：使用自动化测试工具和脚本来执行测试任务，提高测试效率和覆盖范围。
回归测试（Regression Testing）：在软件发生变更后，重新运行既有的测试用例，以确保修改不会引入新的问题。
白盒测试（White Box Testing）：测试人员有关软件内部结构和代码的详细信息，以编写测试用例和进行测试。
黑盒测试（Black Box Testing）：测试人员无需知道软件内部结构和代码的详细信息，只需根据需求规格进行测试。
集成测试（Integration Testing）：测试不同模块或组件之间的交互和集成，以验证它们一起工作的正确性。
端到端测试（End-to-End Testing）：测试软件从开始到结束的整个流程，以确保整个系统的功能和性能都符合要求。
用户验收测试（User Acceptance Testing，UAT）：由最终用户或客户执行的测试，以确认软件是否满足其预期需求。
性能测试（Performance Testing）：测试软件在不同负载条件下的性能表现，包括响应时间、吞吐量和并发用户数等。
1.4有关项目人员组成以及联系方式（开发人员／版本控制人员／测试人员／软、硬、结构、营销人员等）
林劲辰 产品经理 13676708183
许庆阳 需求经理 13692091187
伊尔凡江·艾合买提 需求经理 15609950937
苏建澎 开发工程师 13714283181
鄞灿 开发工程师 13242597082
于阳 开发工程师 13406728050
黎灿宇 测试员 13556481526
2.任务概述
2.1测试范围
1、功能测试：验证软件的功能是否符合需求规格说明书中的要求，包括输入、输出、处理和用户界面等方面的功能测试。
2、性能测试：测试软件在不同负载条件下的性能表现，包括响应时间、吞吐量、并发用户数等方面的性能测试。
3、安全测试：测试软件在面对各种安全攻击和威胁时的表现，包括数据保护、身份验证、授权和审计等方面的安全测试。
4、兼容性测试：测试软件在不同的操作系统、浏览器、设备和网络环境下的兼容性，确保软件在各种环境下都能正常运行。
5、用户体验测试：测试软件的用户界面和交互设计是否符合用户的预期和需求，包括易用性、可访问性和可用性等方面的用户体验测试。
6、回归测试：测试软件在修改、升级或迁移后是否仍然能够正常工作，以确保修改不会引入新的问题。
7、自动化测试：使用自动化测试工具和脚本来执行重复性高、耗时长的测试任务，提高测试效率和覆盖范围。
2.2测试目标
1、发现和修复缺陷：通过测试，发现并报告软件中的缺陷和问题，帮助开发团队及时修复，提高软件的质量和稳定性。
2、确保软件符合需求：验证软件的功能是否符合用户需求和规格说明书中的要求，确保软件能够满足用户的期望。
3、提高软件质量：通过测试，确保软件的功能、性能、安全性和可靠性等方面达到一定的质量标准，提高用户满意度和信任度。
4、保证软件的稳定性：通过不同类型的测试，确保软件在各种条件下都能够稳定运行，减少软件在生产环境中出现故障的可能性。
5、降低软件维护成本：通过及时发现和修复缺陷，减少软件在生产环境中出现故障的可能性，降低软件维护成本和用户投诉率。
6、提高软件交付的可靠性：通过测试，确保软件交付前经过充分验证，提高软件交付的可靠性和稳定性。
2.3广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等
3.测试策略
3.1测试人员需求、分工
以下测试角色的工作均由黎灿宇担任且完成
测试经理（Test Manager）：负责规划、组织和管理整个测试团队，制定测试策略和计划，确保测试活动与项目目标一致。
测试分析师（Test Analyst）：负责分析需求规格和制定测试用例，执行测试用例并记录测试结果，以确保软件功能符合需求。
性能测试工程师（Performance Test Engineer）：负责规划和执行性能测试，评估软件在不同负载条件下的性能表现。
用户验收测试人员（User Acceptance Testers）：由最终用户或客户承担，负责确认软件是否满足其预期需求。
3.2测试方法（自动化测试／手动测试；白盒测试／黑盒测试；中断测试／临界测试／压力测试等）
手动测试中的白盒测试与黑盒测试
3.3工具引用及测试培训（内训／外训）
IDEA Community Edit
3.4测试阶段计划（工作内容、人员安排、起止时间等）
① 进行各功能函数的白盒测试
人员：黎灿宇
起止时间：开发全程
②进行整体程序的白盒测试
人员：黎灿宇
起止时间：基本开发完成至完全开发完成
③进行整体程序的黑盒测试
人员：黎灿宇
起止时间：基本开发完成至完全开发完成
3.5测试停止及恢复条件
停止条件：
完成测试计划：当测试团队已经完成了测试计划中规定的测试任务和测试用例时，可以停止测试。
达到测试覆盖目标：当测试达到了预定的覆盖范围，包括功能覆盖、代码覆盖、路径覆盖等目标时，可以停止测试。
发现了严重缺陷：当测试过程中发现了严重的、影响系统稳定性和安全性的缺陷时，可以暂停测试并等待缺陷修复后再恢复测试。
超出时间和资源限制：当测试耗费的时间和资源超出了预算或计划范围时，可以暂停测试并重新评估测试策略和资源分配。
测试环境不稳定：当测试环境出现了严重的问题，影响测试的进行时，可以暂停测试并等待环境问题解决后再恢复测试。
恢复条件：
缺陷修复：当发现的缺陷得到修复后，可以恢复测试并验证缺陷是否已经解决。
环境问题解决：当测试环境的问题得到解决后，可以恢复测试并继续进行测试。
重新评估资源和时间：当测试耗费的时间和资源超出了预算或计划范围后，可以重新评估资源和时间，调整测试策略和计划后恢复测试。
重新规划测试：当测试目标或覆盖范围发生变化时，可以重新规划测试策略和测试计划后恢复测试。
3.6测试文档及缺陷提交管理等
软件测试文档和缺陷提交管理是软件测试过程中非常重要的一部分，它们有助于记录测试过程、结果和问题，以便团队成员之间进行有效的沟通和协作。
常见的软件测试文档的内容：
测试计划：测试计划是测试活动的指导文档，包括测试范围、测试目标、测试策略、资源需求、时间计划、风险评估等内容。测试计划通常由测试经理或测试负责人编写，并经项目相关人员审批。
测试用例：测试用例是描述测试步骤、预期结果和测试数据的文档，用于执行测试。测试用例应覆盖软件的各种功能、场景和边界条件，以确保对软件进行全面的测试。测试用例通常由测试人员编写，并经过审查和批准后执行。
测试报告：测试报告记录了测试的执行结果、发现的问题、测试覆盖情况等信息。测试报告有助于评估软件的质量和稳定性，以便决定软件是否可以发布或需要进一步的改进。
缺陷报告：缺陷报告用于记录发现的软件缺陷，包括缺陷的描述、重现步骤、严重程度、影响范围等信息。缺陷报告通常由测试人员提交，并经过评审后分配给开发团队进行修复。
常见的缺陷提交管理步骤：
缺陷提交：测试人员在发现缺陷后，应编写详细的缺陷报告，并提交给缺陷跟踪系统或项目管理工具。
缺陷评审：提交的缺陷报告经过开发团队或相关人员的评审，确认缺陷的有效性和严重程度。
缺陷分配：经过评审后，缺陷被分配给相应的开发人员进行修复。
缺陷验证：开发人员修复缺陷后，测试人员进行验证，确认缺陷是否已经解决。
缺陷关闭：经过验证后，测试人员可以关闭缺陷报告，或重新打开缺陷报告，直到缺陷得到有效解决。
3.7测试环境
设备：联想拯救者R9000P
操作系统Window10IDEA Community Edit
内存：16GB+512GB
测试工具：IDEA
4．测试资源
4.1硬件资源需求
一台win10以上系统的个人电脑
4.2软件资源需求
下载IDEA
4.3测试环境需求
配置好Java环境，且下载好测试插件
4.4测试人员需求
一位时间灵活的软件测试员
4.5其他（仪器、服务器等）
5．风险评估
5.1人力方面；软件测试员可能因为特殊原因无法进行工作，此时团队中有其他技术人员可以顶替，风险较低
5.2时间方面；计划中安排的时间均较为充裕，风险较低
5.3环境方面；该项目对开发环境要求不高，风险较低
5.4资源方面：该项目对软硬件设备要求不高，风险较低
5.5部门合作方面：团队成员之间关系融洽，交流积极，风险较低
6．其他内容
测试计划制定者：黎灿宇
日期：2023年11月16日
修改记录：最新版为2023年11月16日21:00版
评审人员信息:
林劲辰 产品经理 13676708183
许庆阳 需求经理 13692091187
伊尔凡江·艾合买提 需求经理 15609950937
苏建澎 开发工程师 13714283181
鄞灿 开发工程师 13242597082
于阳 开发工程师 13406728050
