团队作业3——需求改进&系统设计

需求&原型改进

1. 给目标用户展现原型，与目标用户进一步沟通理解需求。

痛点：小学生学习效率低，不专心，没有竞争感。

场景：在线的答题竞赛比拼，提高学生的主动学习能力和兴趣

2. 修改完善上周提交的需求规格说明书

 https://gitee.com/miracle_stone/SiZeYunSuan/blob/master/%E9%9C%80%E6%B1%82%E8%A7%84%E6%A0%BC%E8%AF%B4%E6%98%8E%E4%B9%A6.docx

3. 参考《构建之法》8.5节功能的定位和优先级，给出功能分析的四个象限。

 

 

 

4.任务分解WBS

时间分配：

• 1 注册登录   2天
• 2 运算功能   3天
• 3 交互功能   2天
• 4 计时功能   2天
• 5 界面设计   1天
• 6 数据库搭建  3天

系统设计

在设计阶段，我们要清楚：软件是怎么解决这些需求的？

 一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。

1. 如何才能最大限度地实现这些需求，这就是架构设计要解决的问题。请给出系统的架构设计

 

 这样一个四则运算系统想要交付给用户的功能就都在这棵树上啦。那如何验证WBS做得对不对呢？书中说得也很清楚：

• 保证所有子节点覆盖了全部父节点包含的内容。比如在“四则运算”这个目中，用户所能看到的全部功能有：注册、登录、答题、选择语言、计时、查看答题后自己的答题记录。“抢答器”整个项目只包含游客模块、注册用户两个个部分。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点，当然就要再细分，直到每一个独立的子节点都被细分出来，这棵大树才会强建。
• 保证各个子节点不要相互覆盖。比如在“英这个项目中，抢答用户模块和主持用户模块都有“答题”这个叶子节点，则要在两个用户模块下分别列出，而不能只在一个父节点中列出。
• 叶子节点要保证足够小，能在一个里程碑中完成。切得蛋糕要一口就能吃掉，否则就切得不成功，要不一口吃不掉，要不会噎死。做项目也是一样，把功能划分得细不要紧，一天多做两个功能呗，更有成就感，但你划分得不够细，很久很久都做不完，你就有可能慢慢就看不到希望了。
• 从结果出发构建WBS，而不是从团队的活动出发。这点其实是很重要的，“从结果出发”就是你想呈现给用户的样子，你的所有父结点和叶子结点都是用户能看得懂的，而不是你们团队将要使用什么技术来解决这个问题。就比如抢答用户模块中的“切换语言”，我说参赛者一定可以可以“切换语言”，用户一定可以看得懂，但我说要使用特定字符串数组进行替换，这用户一定看不懂，因为这是你团队要干的事，不是要呈现给用户的结果。

Alpha任务划分及任务分配计划

召开 Alpha 计划会议，为下周进入Sprint作准备。会议内容包括两个部分：

• 以需求分析为主，选择和排序该阶段需要实现的任务（订单条目）

• 在最终完成这个项目之前，肯定需要完成很多小任务。有些任务没必要在 Alpha 阶段实现，这些任务先排除掉。要在 Alpha 阶段实现的任务中，又有一些必须的基础或者核心的任务是要优先完成的，需要将这些任务排到任务清单的前面。

• 以设计为主，确定系统设计方案和工作内容

• 每个任务要采用何种技术（实现方案）去完成？每一个任务将会分配给哪位成员去实现？

测试计划

时间	测试任务
第9周	测试数据库是否成功创建并且可连接（郭达）
第10周	搭建部署项目，并且测试项目对数据可的增改查（孙斌）
第11周	对用户登录注册功能进行测试（石浩洋）
第12周	对系统答题界面和答题和成绩进行测试（刘德培）
第13周	对用户定位和排位排行榜功能测试（曾繁钦）
第14周	对整个项目测试（所有人）