团队作业2——《需求规格说明书》
| 这个作业属于哪个课程 | 软件工程2024 |
|---|---|
| 这个作业的要求是什么 | 团队作业2——《需求规格说明书》 |
| 这个作业的目标 | 形成《需求规格说明书》，制定团队计划和分工。 |
一、需求规格说明
滑动拼图小游戏
1. 项目简介
这是一个小游戏，是一个让劳苦的大学生能够在解决不了 bug 、写算法没有思路时，能够用来转换心绪、放松心情的小助手，同时还有满足欣赏优美图案、聆听非凡音乐和锻炼几何能力。
2. 用户分析
用户面临问题：学业压力大、空闲时间短、跨平台游戏少等问题，本项目致力于解决上述问题。
3. 功能性需求
-
注册与登录：用户在界面选择注册或登录，并且用户信息会被存储。
-
用户操作：用户通过键盘方向控制空白拼图移动。
-
拼图选择：用户可以自选图片进行拼图游戏，在游戏中也可以更换图片。
-
音乐选择：游戏时播放与图片有关的音乐，用户可决定是否播放。
-
记录游戏过程：记录游戏所用时间或步数，游戏完成时弹出提示，游戏开始时提供完整图案，一键通关功能，重新游戏功能。
-
用户排名：上传用户数据到端，在线根据用户所用的时间或步数，制定用户排名。
4. 技术需求
-
开发语言：Java
-
工具包 ：hutool
-
开发环境： idea
-
任务发布平台：飞书
-
项目开发共享：github
5. 预期的用户数量：200人
6. 项目阐述
- 真实性：
每位成员都掌握相对性的编程知识，了解实现原理。同时，由于其简单的规则和有趣的玩法，滑动拼图游戏在市场上是非常受欢迎的，很多开发者和游戏制作公司都会开发类似的游戏，并且有一定数量的用户群体。因此，从市场上已经存在的滑动拼图游戏来看，可以证明这种类型的游戏在现实世界中是存在的，也证实了这个项目的真实性。
- 可用性
滑动拼图游戏对大学生具有很高的可用性。它是一种简单而愉快的放松方式，适合在忙碌的学习生活中使用。由于可以随时随地进行，非常适合利用零散时间进行娱乐。此外，这种游戏还可以锻炼大学生的思维能力，促进他们之间的社交互动。由于它是一种轻量级游戏，可以在各种设备上流畅运行，满足大学生对轻量级应用的需求。
- 价值所在
目前市场上的游戏种类繁多，滑动拼图小游戏致力于有效利用零散时间、跨平台可用性等，十分符合大学生的需求。并且拼图小游戏作为一种健康的娱乐方式，有助于减少青少年沉迷网络等不良行为的可能性。
二、团队计划与分工
1. 团队码云：经过团队讨论，依然以 ” git+飞书 “ 的合作方式替代码云等项目管理平台，这种无论是学习难度，还是运行的稳定性，都高于码云等平台；
2. 团队原定计划
| 周次 | 原定计划 |
|---|---|
| 第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博客：事后分析 |
3.矫正计算方法
- 新的计划与原本的计划大体相似，只是比原本的计划推前一周多的时间；
- 由于我们的项目结构较为简单，因此简化了一些步骤，项目的编程阶段也已经开始；
- 而且，由于上课的任务存在，我们认为“冲刺”型的开发方式难以实现；
4.全部的计划安排如下：
| 周次 | 具体计划 |
|---|---|
| 第7周 | 1.团队组队、团队博客 |
| 2.团队介绍、成员展示、角色分配、选题确定 | |
| 3.制定团队计划安排，团队贡献分的规定 | |
| 第8、9周 | 1.需求规格说明书 |
| 2.建设项目的大体架构结构，即基本的登录模块和游戏模块 | |
| 3.编码规范完成、平台环境搭建 | |
| 第10周 | 1.完善项目中的扩展功能 |
| 2.第一次较大规模测试，和查错 | |
| 第11周 | 1.尝试对项目进行更多升级，增添更多功能，提示算法效率 |
| 2.第二次较大规模测试，和查错 | |
| 第12周 | 1.发布项目，收集用户体验和建议 |
| 2.确立改进计划 | |
| 第13周 | 对项目做改进 |
| 第14周 | 事后分析，评分分配 |
4.飞书项目管理平台截图
- 需求管理：
- 需求统计：
- bug管理：
5.团队基本分工与工作感想
| 成员 | 任务 | 感想 |
|---|---|---|
| 刘朝坤（队长） | 负责项目任务的具体安排 | 自从组队做项目以来，身为队长，我感觉自己的管理和组织能力有很大的提升，看待项目开发的角度和思维也更加宽广。不过，我还存在不少问题：直接的沟通交流不积极，任务的要求描述不清晰…… |
| 陈德标 | 后端开发 | 熟悉了 git 仓库的创建、管理及维护，尝试写技术文档供他人学习；能分享自己的相关经验，进一步锻炼了自己快速学习的能力，做任务不拖延了；还是有点懒，不想接活，爱摸鱼；团队工作看着活挺少的，一两个人接了，其他人都没什么事情做了，反正我是两个星期没管过软工了(哈哈哈)，也许是功能少，如果功能多的话，感觉多布置几个并行开发也没什么关系，当然保持现状也挺好(摸 ing ...) |
| 陈嘉豪 | 前端开发 | 自从组队了团队之后，我们开始团队项目之后，我学习到了之前自己一个人所不知道的东西，同时更加认清楚自己还有什么不足。或许是我对这个项目的上心程度还不够，同时自己的能力也不够强，所以很少自己单独接任务。希望之后能够学到更多开发技能 |
| 韦兰健 | 测试 | 团队项目开始到现在，我感觉我的自学能力有了提升，努力向其他队员看齐，并且在做任务的时候也让我对项目有了更深的了解。但是感觉自己在做任务这方面会有些拖延。对团队工作建议，希望团队内的交流能多一些。 |
| 杨文琦 | 前端开发 | 在团队项目中，我了解团队项目的搭建与个人项目的许多不同之处，能够了用 Java 实现项目登录和注册的图形化界面，学会了用过 PS 完成丰富图片的前期准备工作，进一步锻炼了自己学习和实践的能力，同时在这个过程中也存在一些不足，修改代码后未能及时调试出运行后的问题， git 提交时存在遗留不够细心等，在之后的任务中我会不断改正，希望以后团队能发现问题及时沟通，不断进步。 |
| 余有亮 | 后端开发 | 自加入团队后，尽管只接了两个任务，但我收获良多，学会了 JAVA 转 jar 包，学会转化为 exe 文件，闯出了舒适区，增长了知识。同时我也发现了自己的缺点，就是懒，懒得看信息，以至于不能及时看到任务，没有活力，不出声。我会改正自己的缺点，不断进步。 |
| 曾郑耿 | 测试 | 自从成为团队的一员，我发现自己并非一无是处，而是能够尽力而为，比如完成随笔的整合。同时，我也了解到其他队员各有所长，都对队伍有独特的贡献。通过接任务做任务，我逐渐熟悉了队伍的协作过程，也渐渐对 Markdown、Java 的操作熟能生巧。但自身有一个较大的缺点，如果没有 任务和 ddl ，也许我永远不会主动去学习。当然，也因为认识到自身的缺点，现在在努力学习中。对本团队，特别是飞书里，希望能有更多的交流。对未来，自己也会更加努力，完成以前我从不敢想能够完成的事。 |
三、其它
1.已确立团队编程规范：
提交代码规定
-
提交的代码应不存在 bug ，可以正常运行；
-
实现的代码应该符合模块化的原则，包装为一个方法或类；
-
不要轻易修改运行类，对于不是自己负责的模块，也尽可能不修改，若必须修改，一定要和对应的负责人商量；
-
在提交的每一个类、每一个方法前，应该按如下要求做笔记注释，尽量帮助其它成员理解代码：
-
功能：输入输出，以及通俗的作用；
-
算法的思路：大致阐述实现过程、实现思路，或者说代码的结构；
-
与代码的其它连接：这个类或方法会在哪个位置运用，在整个项目中的角色；
-
-
写代码时尽量多写注释；
如果实在完成不了自己的任务：
-
不要将代码提交到 git；
-
复盘自己的实现过程，按如下要求将失败了的代码的类文件提交 bug 给队长：
-
思路：自己是想通过怎样的方式实现功能；
-
报错：编译器的报错；
-
推测：错误的原因，以及自己能想到的最可能的新的实现方法
-
-
队长将 bug 作为任务再次发布，有其他人负责，失败了的人按要求提交后仍可得到一定分数；
2.完成情况：
以下为目前每个人已完成的任务：
3.新的项目：
新计划安排已添加到管理平台中，如图 ”需求管理“ 所示，
