团队作业3--需求改进&系统设计
目录
一丶需求&原型改进
1.1 用户需求改进
- 使用场景假设：音游爱好者看到一款新的音游进行游玩体验，普通玩家在休闲事件通过游玩该游戏进行消遣。
1.2 功能分析的四个象限
| 需求\功能 | 外围功能 | 杀手功能 |
|---|---|---|
| 必要需求 | 游戏形式（2D跑酷+音游） | 跑酷控制与"击打"音符控制 精美的音效 良好的交互体验 |
| 辅助需求 | 精美的画面特效 | 良好的分数判定与计算 |
1.3 WBS与项目改进计划
WBS：
项目改进计划：
| 功能 | 功能详情 | 所属版本 |
|---|---|---|
| 场景，流程管理 | 完成场景，软件控制，游戏控制流程模块 | Alpha 1.0，3.0 |
| 音符模块 | 实现读取与生成对应音符模块 以及音效素材设计 | Alpha 1.0，2.0 |
| 美术模块 | 寻找到项目所需要的美术UI资源以及角色资源 | Alpha 1.0，2.0 |
| 分数模块 | 策划以及实现分数计算与完成分数模块 | Alpha 1.0，2.0 |
| 角色模块 | 实现角色控制以及交互 | Alpha 2.0， 3.0 |
| UI模块 | 实现UI显示与交互 | Alpha 2.0， 3.0 |
| 效果模块 | 实现人物动画效果与音符点击产生的特效效果 | Alpha 2.0， 3.0 |
| 道具模块 | 实现道具的产生，移动（存在），销毁 | Alpha 2.0， 3.0 |
| 游戏流程-快速模式 | 当玩家combo达到一定的次数即进入快速模式游玩 | Alpha 3.0 |
| 整体游戏 | 完善整体游戏流程 | Alpha 3.0 |
二丶 系统设计
三丶 Alpha任务分配计划
3.1 Product Backlog和Sprint Backlog
依据项目组能提供的总时间、功能模块的优先级以及模块之间的依赖关系，在Product Backlog中选取待实现的功能项，对已选择的功能项再做进一步分解，分解为1-10小时左右的任务，构成Sprint Backlog。
| Product Backlog | Sprint Backlog |
|---|---|
| 音效模块 | 游戏音效设计，音符读取与生成，音符特效，道具系统 |
| 游戏逻辑模块 | 场景管理，游戏流程管理，软件流程管理，分数管理 |
| 角色模块 | 跑酷控制，人物动画 |
| UI模块 | UI显示，UI交互 |
| 美术模块 | 寻找美术资源 |
3.2 开发任务分配
在PM的协助下，编码的同学对任务进行认领，分工的结果如下：
| 开发任务 | 负责人 |
|---|---|
| 音效设计 | 杨文伟 |
| 美术资源 | 吴永力 |
| 音效模块 | 杨锐楷，杨文伟 |
| 角色模块 | 吴永力，罗耿城 |
| 场景管理，软件流程管理 | 吴永力，曾鑫 |
| 分数模块 | 曾鑫 |
| 道具模块 | 吴永力，杨锐楷, 杨文伟 |
| 游戏流程控制 | 吴永力，曾鑫，罗耿城 |
| 动画与特效实现 | 吴永力，罗耿城 |
| UI模块 | 吴永力，曾鑫，杨锐楷 |
3.3 Alpha阶段冲刺计划甘特图
四丶测试计划
4.1 项目背景
- 项目概述：《MarioPlan》是一款2D跑酷+音游结合的游戏，可以让玩家在休闲时刻进行游玩。
- 参考资料：需求规格说明书
4.2 测试任务
- 测试范围：
- 基本逻辑功能：分数，流程等
- 美术资源与音效资源装载
- 测试目标：
- 保证程序能够基本实现预期功能
- 具有一定的可玩性
4.3 测试通过与失败标准
符合基本逻辑，用户直接交互的模块需要有相应的反馈信息。
4.4 测试策略
- 测试方法:
- 手动测试：功能测试，安装测试
- 代码复审：静态代码检查
- 测试阶段：
- 单元测试：开发人员自主进行，测试人员进行代码复审，依据接口设计测试用例（使用Unity单元测试）
- 集成测试：在完成一个大的模块后，进行组装测试，确认接口是否正确使用
- 系统测试：验证各系统的功能
- 验收测试：基于需求规格说明书执行功能测试，同时交给少量用户测试
4.5 测试环境
Android7.0及以上
4.6 测试提交材料
- 功能测试报告：《项目测试报告书》
- Bug/Debug记录：《项目Bug/Debug记录书》
4.7 其他信息
- 测试计划制定者：杨锐楷
- 评审人员：
- 测试负责人：杨锐楷
- 总负责人：吴永力
