团队作业3--需求改进&系统设计
团队作业3：需求改进&系统设计
| 所属课程 | 软件工程2024 |
|---|---|
| 作业要求 | 需求改进&系统设计 |
| 作业目标 | 改进需求、完成系统的初步的设计 |
一、需求改进与系统设计
1、需求改进
问题1：原本发布帖子只是发布物品的相关信息，没有发布人的相关信息，没有办法很好的解决该系统的难点与痛点。
修改1：在发布帖子的模块中增加联系方式，方便双方进行沟通和交流。
问题2：原本的设计没有对已经认领的物品或者已找回的物品进行标注或者分类，加大了用户搜索寻找的难度。
修改2：新增加一个设置该帖子状态的功能，如果已找回或被认领，可以设置相关的状态。
2、修改需求规格说明书
上次的需求规格说明书考虑得不够全面，没有考虑到用户双方之间的沟通和交流问题，和本系统实现失物招领必须需要丢失物品方和捡到物品方都登陆本系统，没有考虑到多方式的寻找和通知，没有办法很好的解决该系统的难点与痛点。还有对于已经找到物品或者已经归还捡到物品的用户发布的相关帖子没有进行相应的处理和区分，导致帖子十分混乱，加大了用户寻找物品的难度。所以我们新添加了两个功能：在发布帖子的模块中增加联系方式，方便双方进行沟通和交流；设置该帖子状态的功能，如果已找回或被认领，可以设置相关的状态，以帮助用户进行区分无效的帖子。
改进内容：
(1)发布帖子
-
用户可以发布失物招领帖子，包括失物描述、失物时间、失物地点、联系方式等信息。
-
用户可以发布寻物帖子，包括物品描述、遗失时间、遗失地点、联系方式等信息。
-
发布帖子时，支持上传图片作为附件，以便更直观地展示失物或寻物信息。
(2)帖子的处理
-
用户已经找到丢失的物品后，可以将该帖子设置为"已找回"状态
-
用户已经归还物品给失主后，可以将该帖子设置为"已归还"状态
-
支持用户对帖子进行修改和删除
3、功能分析的四个象限：
4、WBS任务分解图
5、进度计划
| 时间 | 任务 |
|---|---|
| 第九周 | 1、 原型改进(给目标用户展现原型，并进一步理解需求) |
| 2、架构设计，WBS,团队成员估计各自任务所需时间 | |
| 3、测试计划 | |
| 第十周 | 1、综合考虑队员对新技术的学习能力和任务的难度，调整任务分工 |
| 2、团队项目Alpha任务分配计划 | |
| 第十一周 | 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 |
| 第十二周 | 1、用户反馈+测试计划改进 |
| 2、 团队Alpha阶段个人总结 | |
| 3、团队项目Alpha博客:发布说明、测试报告、展示博客、项目管理 | |
| 第十三周 | 团队项目Alpha博客:事后分析 |
二、系统设计
（1）用户功能设计
（2）系统架构设计
(3)数据库设计
三、Alpha任务分配计划
1、Product Backlog
2、Sprint Backlog
3、甘特图
四、测试计划
1、引言
1.1背景：
校园内失物情况时有发生，传统的招领方式效率低下，信息传播范围有限。因此，需要搭建一个校园失物招领平台，提高失物招领的效率，方便师生快速找回失物或找到失主。
1.2测试术语
自动化测试：使用自动化测试工具和脚本来执行测试任务，提高测试效率和覆盖范围。
回归测试：在软件发生变更后，重新运行既有的测试用例，以确保修改不会引入新的问题。
白盒测试：测试者需要检查程序的内部结构，从程序的逻辑着手，得出测试数据。
黑盒测试：黑盒测试主要关注程序是否按照需求规格说明书的规定正常使用，是否能接收输入数据并产生正确的输出信息。
集成测试：集成测试主要验证组件之间的接口和交互是否正确，以及组件在一起工作时是否符合预期。
功能测试：验证系统各功能模块是否按照需求文档进行工作。
性能测试：评估系统在负载下的运行效率和稳定性。
兼容性测试：检查系统在不同操作系统、浏览器等环境下的兼容性。
1.3项目组成人员
| 队员 | 任务 |
|---|---|
| 廖莹 | PM |
| 梁丽贤 | 前端开发 |
| 姚佳如 | UI+需求分析 |
| 李慧娣 | 需求分析 |
| 肖扬 | 前端开发 |
| 黄诃华 | 后端开发 +测试 |
| 欧文杰 | 后端开发 +测试 |
2、任务概述
2.1测试范围
用户登录与注册功能测试
失物信息发布与浏览功能测试
招领信息发布与浏览功能测试
用户与管理员互动功能测试
系统后台管理功能测试
性能测试
兼容性测试
安全测试
2.2测试目标
确保系统能正常运行：通过测试保证失物招领系统的各项功能正常运行，满足用户需求
保证系统的稳定性和安全性：通过不同条件的测试，确保系统在各种条件下都能够稳定运行。
提高系统的可靠性：确保软件的功能、性能、安全性等方面达到一定的标准。
3、测试策略
3.1测试人员需求、分工
主要的测试均由开发人员负责，前端开发人员主要负责模块功能测试和兼容性测试，后端开发人员主要负责性能测试、安全测试。后面的用户测试和分析由需求分析的两位同学负责。
3.2测试方法
自动化测试：使用自动化测试工具进行部分测试用例的执行。
手动测试：对自动化测试无法覆盖的测试用例进行手动执行。
黑盒测试：关注系统的输入输出，验证系统是否符合需求。
白盒测试：关注系统内部逻辑，对代码进行覆盖率测试。
3.5测试停止及恢复条件
停止条件：
当测试覆盖率达到预定目标时，可停止测试。
当系统出现严重缺陷或测试环境出现问题时，需暂停测试并进行相应处理。
恢复条件：
发现的缺陷得到修复后，可以恢复测试并验证缺陷是否已经解决。
环境问题已经解决，以恢复测试。
3.6测试文档
测试计划：包括测试范围、测试目标、测试策略、资源分配、风险评估等。
测试用例：包括测试数据、测试环境等。
测试执行记录：包括执行结果、测试问题、截图和日志等。
测试问题报告：包括问题汇总、问题分析、问题跟踪等。
4、测试资源
4.1硬件资源需求：win10以上的电脑
4.2软件资源需求：IDE
4.3测试环境需求:java环境
4.4测试人员需求：掌握相关知识的测试人员
5、风险评估
5.1人力方面：我们团队并没有专业的测试人员，大部分由开发人员担任，执行测试有点困难。
5.2时间方面：开发人员既要开发又要测试，时间比较紧张。
5.3环境和资源方面：本系统对此的要求不高，风险较小。
