时间分配：
- 1 注册登录?? 2天
- 2 运算功能?? 3天
- 3 交互功能?? 2天
- 4 计时功能?? 2天
- 5 界面设计?? 1天
- 6 数据库搭建? 3天
这样一个四则运算系统想要交付给用户的功能就都在这棵树上啦。那如何验证WBS做得对不对呢？书中说得也很清楚：
- 保证所有子节点覆盖了全部父节点包含的内容。比如在“四则运算”这个目中，用户所能看到的全部功能有：注册、登录、答题、选择语言、计时、查看答题后自己的答题记录。“抢答器”整个项目只包含游客模块、注册用户两个个部分。这样才能实现所有子节点覆盖了全部父节点包含的内容。如果子节点还可以再划分子节点，当然就要再细分，直到每一个独立的子节点都被细分出来，这棵大树才会强建。
- 保证各个子节点不要相互覆盖。比如在“英这个项目中，抢答用户模块和主持用户模块都有“答题”这个叶子节点，则要在两个用户模块下分别列出，而不能只在一个父节点中列出。
- 叶子节点要保证足够小，能在一个里程碑中完成。切得蛋糕要一口就能吃掉，否则就切得不成功，要不一口吃不掉，要不会噎死。做项目也是一样，把功能划分得细不要紧，一天多做两个功能呗，更有成就感，但你划分得不够细，很久很久都做不完，你就有可能慢慢就看不到希望了。
- 从结果出发构建WBS，而不是从团队的活动出发。这点其实是很重要的，“从结果出发”就是你想呈现给用户的样子，你的所有父结点和叶子结点都是用户能看得懂的，而不是你们团队将要使用什么技术来解决这个问题。就比如抢答用户模块中的“切换语言”，我说参赛者一定可以可以“切换语言”，用户一定可以看得懂，但我说要使用特定字符串数组进行替换，这用户一定看不懂，因为这是你团队要干的事，不是要呈现给用户的结果。
| 时间 | 测试任务 |
| 第9周 | 测试数据库是否成功创建并且可连接（郭达） |
| 第10周 | 搭建部署项目，并且测试项目对数据可的增改查（孙斌） |
| 第11周 | 对用户登录注册功能进行测试（石浩洋） |
| 第12周 | 对系统答题界面和答题和成绩进行测试（刘德培） |
| 第13周 | 对用户定位和排位排行榜功能测试（曾繁钦） |
| 第14周 | 对整个项目测试（所有人） |
