团队作业3--需求改进&系统设计
团队作业3--需求改进&系统设计
| 这个作业属于哪个课程 | 软件工程 |
|---|---|
| 这个作业要求在哪里 | 团队项目 |
| 这个作业的目标 | 制作规格说明书，明确分工，制定计划安排 |
| 前端仓库 | 前端 |
| 后端仓库 | 后端 |
一. 团队介绍
1. 团队名称：码农探花队
2. 团队成员
| 姓名 | 班级 | 学号 |
|---|---|---|
| 唐育健（组长） | 软件工程三班 | 3122004879 |
| 李宇康 | 软件工程三班 | 3122004871 |
| 陈境涵 | 软件工程三班 | 3122004775 |
| 张荆茂 | 软件工程三班 | 3122004884 |
| 阳昊 | 软件工程三班 | 3122007304 |
| 梁爽 | 软件工程三班 | 3122004872 |
二. 需求&原型改进
1. 问题与改进
团队针对课堂讨论分享环节的提问以及对需求与功能进行的讨论，再次对选题以及需求进行初步改进
-
问题1：作为用户我想在网站使用不同平台会员进行跨平台听歌
团队将继续对QQ音乐，网易云等流行音乐平台API调用进行研究，争取后续能上线跨平台播放的功能
-
问题2：上传音乐的版权纠纷
团队将委派管理员，在管理员后台对用户上传歌曲进行区分，对版权拥有进行确认与审核，只有当审核通过才可以分享
2. 完善需求规格说明书
对于上次分析的需求规格说明书进行补充和修改
① 第三方平台登录
支持用户登录第三方平台，根据用户在其他平台权限情况，支持用户进行跨平台播放歌曲
② 歌曲版权纠纷
在对歌曲版权有疑问时，平台将标志上传用户的基本信息与免责声明
在新的需求规格说明书中，我们充分吸收了课堂上老师的意见，我们将在实现基础功能的前提下，继续研究API接口调用，从而让用户可以跨平台欣赏他们喜欢的音乐，而对于音乐的版权纠纷，我们会秉持开源的思想，标注歌曲上传用户
场景说明：作为用户，我可以通过注册平台账号获得平台资格，可以在平台享受上传歌曲，搜索歌曲，评论，个性化资料等功能，同时我也可以通过登录其他平台会员账号，享受跨平台听歌
3. 新增功能
- 对歌曲的下载功能
- 显示隐藏播放器
- 对歌单进行个性化编辑，支持上传图片与完善简介
- 能够点击播放器进行改变播放进度
- 播放完本歌曲自动播放下一首
- 可以对歌词进行解析
- 实现首页的轮播图，使界面更加美观
4. 功能分析的四个象限
团队通过对《构建之法》8.5的内容进行阅读，给出功能分析的四个象限
5. 调整任务分解WBS及相应的项目进度计划
对任务进行分解确立测试计划
改进计划表
| 第 9周 | 1.团队组队、团队博客 |
| 2.团队介绍、成员展示、角色分配、选题确定 | |
| 3.制定团队计划安排，团队贡献分的规定 | |
| 第10周 | 1.需求规格说明书 |
| 2.原型设计，队员估计任务难度并学习必要的技术 | |
| 3.编码规范完成、平台环境搭建完成、初步架构搭建 | |
| 第11周 | 1.原型改进（给目标用户展现原型，并进一步理解需求） |
| 2.架构设计，WBS, 团队成员估计各自任务所需时间 | |
| 3.测试计划 | |
| 第12、13周 | 1. 团队项目Alpha任务分配计划 |
| 2. 连续7天的Alpha敏捷冲刺，7 篇 每日Scrum Meeting博客+代码提交 | |
| 第14周 | 1.用户反馈+测试计划改进 |
| 2. 团队Alpha阶段个人总结 | |
| 3. 团队项目Alpha博客：发布说明、测试报告、展示博客、项目管理 | |
| 第15周 | 1. 团队项目Alpha博客：事后分析 |
三. 系统设计
1. 设计摘要说明
首先将从架构层次对项目本身设计进行简短概述
| 前端 | 实现与用户的直接交互 |
|---|---|
| 后端 | 负责对用户请求进行服务，为用户提供目的数据 |
| 播放器 | 实现对歌曲基本操作 |
2. 设计背景
音乐作为被广泛接受的艺术，已经牢固地扎根于每个人的日常生活中，虽然市面上已经存在大大小小的音乐软件，但是每个软件的歌曲难以互通，我们秉承在不侵犯版权的前提下鼓励用户上传包括但不限于自我创造的音乐，用户可以把本项目当作一个简单的音乐播放器亦可以将其做为自我艺术的传播途径。作为开源项目，秉承开源精神，希望能为国内开源环境增添微小的贡献，项目面向广大音乐爱好者，音乐创作人，开发学习者，我们希望能将音乐传递，让音乐不只是音乐。我们期望能够为用户提供高质量的音乐平台，能够整合音乐资源，提供便利的音乐播放功能，也期望能发掘更多有潜力的个人音乐家。
3. 系统架构图
4. 系统架构说明
当我们团队的主要任务是提供方便的音乐平台体验时，我们不仅注重功能性，也致力于确保我们的平台在各种设备上都能流畅运行。为此，我们采用了适应性强、界面漂亮的前端组件库 [[shadcn]]。这个组件库不仅提供了易于自定义的组件，而且默认样式十分吸引人，为我们的用户带来了愉悦的视觉体验。我们也选择了 [[Next.js]] 作为我们的前端框架，它不仅提供了强大的服务器渲染(SSR)和搜索引擎优化(SEO)功能，还具有出色的生态系统和丰富的资料支持。
5. 功能列表
| 模块 | 功能名称 | 实现功能 | 备注 |
|---|---|---|---|
| 管理员 | 注册 | 添加管理员 | |
| 登录 | 输入账号密码登录管理员系统 | 验证身份 | |
| 统计 | 统计歌曲总数、总人数、类型分布等 | ||
| 查询 | 查询用户，歌曲等 | ||
| 管理 | 实现对歌手歌曲歌单等增删查改操作，以及对用户的管理 | 审核上传 | |
| 用户 | 注册 | 注册用户账号 | 用户不能重复注册 |
| 登录 | 登录已有账号 | ||
| 个性化 | 用户个性化资料设置与展示 | ||
| 管理 | 对用户歌单歌曲的增删查改 | ||
| 修改 | 修改登录密码 | ||
| 播放器 | 播放 | 实现对音乐的播放 | |
| 歌词 | 实现歌词的滚动显示 | ||
| 切歌 | 实现手动自动对音乐的切换 | ||
| 展示 | 展示歌曲图片歌手等信息 | ||
| 轮播图 | 展示首页轮播图 |
6. 系统页面
7. 数据库的ER图
四. Alpha任务分配
团队将使用leangoo进行敏捷开发与团队管理，下图为部分用户故事展示
五. 测试计划
1. 项目--蕴玉音乐
1.1项目背景
音乐作为被广泛接受的艺术，已经牢固地扎根于每个人的日常生活中，虽然市面上已经存在大大小小的音乐软件，但是每个软件的歌曲难以互通，我们秉承在不侵犯版权的前提下鼓励用户上传包括但不限于自我创造的音乐，用户可以把本项目当作一个简单的音乐播放器亦可以将其做为自我艺术的传播途径。作为开源项目，秉承开源精神，希望能为国内开源环境增添微小的贡献，项目面向广大音乐爱好者，音乐创作人，开发学习者，我们希望能将音乐传递，让音乐不只是音乐。我们期望能够为用户提供高质量的音乐平台，能够整合音乐资源，提供便利的音乐播放功能，也期望能发掘更多有潜力的个人音乐家。
1.2参考资料
测试计划将按照下述网站的规范修改来进行
1.3测试术语
- 单元测试（Unit Testing）：对软件中的最小可测试单元进行检查和验证。
- 集成测试（Integration Testing）：在单元测试基础上，集成测试主要测试不同模块之间的交互是否正常。
- 系统测试（System Testing）：这是基于软件需求规格说明的黑盒测试，以评估系统的整体功能。
- 回归测试（Regression Testing）：每次修改后，都需要进行回归测试，以确保修改没有引入新的错误。
- 性能测试（Performance Testing）：为了确定系统在其预期负载下的性能。
- 压力测试（Stress Testing）：为了确定系统的稳定性和可靠性，通过在超出系统规定的负载或数据量下测试系统。
- 兼容性测试（Compatibility Testing）：为了评估软件在不同环境（如操作系统，浏览器，硬件等）中的运行情况。
- 用户接受测试（User Acceptance Testing，UAT）：最后的测试阶段，以确定软件是否准备好被交付。
2. 任务概述
2.1测试范围
- 功能性测试（Functional Testing）：这是对软件的功能进行测试，以确保它们按照规格说明书的要求工作。
- 非功能性测试（Non-Functional Testing）：这包括性能测试、安全性测试、可用性测试等，以确保软件在各种条件下的性能和效率。
- 界面测试（Interface Testing）：这是对软件的用户界面进行测试，以确保它们对用户友好，易于使用。
- 兼容性测试（Compatibility Testing）：这是为了确保软件能在不同的操作系统、浏览器和硬件配置上运行。
- 用户体验测试（User Experience Testing）：这是为了确保软件提供了良好的用户体验，包括易用性、可访问性和满足用户需求。
- 安全性测试（Security Testing）：这是为了确保软件的数据和资源在各种威胁下的安全。
- 回归测试（Regression Testing）：在软件修改后，进行回归测试以确保修改没有引入新的错误。
- 烟雾测试（Smoke Testing）：这是一种表面级别的测试，用于确定软件的基本功能是否工作正常。
- 敏捷测试（Agile Testing）：在敏捷开发环境中，测试和开发是并行进行的，以快速发现和修复错误。
2.2测试目标
- 验证功能性（Verify Functionality）：确保软件的所有功能都按照规格说明书的要求正常工作。
- 验证性能（Verify Performance）：确保软件在预期的负载和数据量下能够正常运行，并满足性能要求。
- 验证安全性（Verify Security）：确保软件的数据和资源在各种威胁下的安全。
- 验证兼容性（Verify Compatibility）：确保软件能在不同的操作系统、浏览器和硬件配置上运行。
- 验证用户体验（Verify User Experience）：确保软件提供了良好的用户体验，包括易用性、可访问性和满足用户需求。
- 验证稳定性（Verify Stability）：确保软件在长时间运行或在复杂环境中能够稳定运行。
- 验证可维护性（Verify Maintainability）：确保软件易于修改和扩展，以满足未来的需求。
- 验证可移植性（Verify Portability）：确保软件能在不同的环境中移植和运行。
2.3广义上还包含测试需求分析／测试用例编写／测试环境搭建／测试培训／测试执行等
3. 测试策略
3.1测试人员需求、分工
本项目人员有限，要求前后端互相进行黑盒测试，最后统一进行内测
3.2测试方法
项目拟使用黑盒测试
3.3测试文档及缺陷提交管理等
按照讨论，缺陷统一提交至管理软件中
3.4测试计划
后端接口的黑盒测试
人员：前端开发
前端的黑盒测试
人员：后端开发
总体测试
人员：全员参与
4. 测试资源
4.1硬件资源需求
Windows操作系统的电脑
4.2软件资源需求
有开发环境的工具
4.3测试环境需求
配置前后端环境
4.4测试人员需求
认真负责，不偏袒开发
4.5其他（仪器、服务器等）
5. 风险评估
5.1人力方面
项目人手紧缺，开发兼顾测试
5.2时间方面
开发时间短暂，在完成开发立即测试
5.3环境方面
项目本身对环境无特殊要求，风险较低
5.4资源方面
项目对配置资源无特殊要求，无风险
5.5部门合作方面
团队之间融洽沟通，不存在风险
6. 其他内容
在测试过程中遇到问题，应该相互询问解决，互相帮助，提高团队凝聚体，在遇到突发情况应该积极交流沟通，问题不可怕，一起合作一定可以解决，在完成每一阶段的开发测试应该及时总结吸取教训。
测试计划制定者：张荆茂
日期：2024年4月30日
修改记录：最新版为2024年4月30日13:00版
六. 前端设计文档公开
为贴合开源项目，支持二次开发创作，前端进行了设计文档的详细编写
