1.对四则运算软件需求的获取方式进行实践，例如使用调查问卷访问相关关系人等。
对四则运算软件需求的获取方式进行实践，例如使用调查问卷访问相关关系人等。
根据作业要求，我们组采用了调查问卷的方式，在“问卷星”上创建了一份调查问卷。
调查问卷网址 https://sojump.com/jq/9930327.aspx
我的一个同学现在在做小学数学老师，所以我就请她帮忙，让她的同事以及学生帮我做了几份调查问卷。虽然人数不多，但是，我觉得这个问卷结果对我们的项目最终完成，仍有一定的帮助。
截止10月9日，调查结果分析报告：
https://files.cnblogs.com/files/msec2016/《小学生四则运算网站》需求分析问卷调查－报告.pdf
2采用四象限法将你小组的四则运算软件的需求功能进行分类。阐述其优势与不足。
经过网上资料的收集，我深入了解了四象限法则。
它把工作按照重要和紧急两个不同的程度进行了划分，基本上可以分为四个“象限”：既紧急又重要、重要但不紧急、紧急但不重要、既不紧急也不重要。
第一象限包含的是一些具有紧迫性和重要性的事情，无法回避也不能拖延，必须首先处理优先解决。
第二象限不同于第一象限，这一象限的事件不具有时间上的紧迫性，但是它具有极其重大的意义。计划、准备、学习、培训等事情都是属于第二象限的工作。
第三象限中是那些紧急但不重要的事情，这些不重要的事件往往因为它紧急，就会占据人们的很多宝贵时间。
第四象限中的事件没有时间紧迫性，没有重要性的。需要尽力去减少这些事情的存在，才会提高工作效率。
这就是关于时间管理的“四象限法则”。
它的使用将会对我们项目进展和实施进行有效的管理和约束，同时对于我们日常学习工作生活中时间的管理也有极大的益处和启发作用。
那么针对我们小组的四则运算软件的开发，我们提出的需求功能列举如下：
1：注册功能：用户能够完成注册；
2：登录功能：用户根据自己的账号密码进行登录；
3：习题练习功能：用户可以进行做题练习，这也是系统实现的主要功能。
4：限时考试功能：用户可以选择考试方式在规定时间内进行答题，并且系统会给出考试成绩。
5：结果统计功能：用户可以看到自己练习的总题数，错误题数，以及计算出错误率。
6：错题显示功能：用户可以选择曾经错误的题目进行仔细查看和分析。
7：教师查看功能：教师身份登录可以对学生的答题情况通过系统统计查看。
8：教师出题功能：教授身份登录可以进行题目的添加和提交。
对于这些需求功能的分析我得到如下划分：
第一象限（重要紧急）：习题练习功能；结果统计功能；
第二象限（重要不紧急）：限时考试功能；成绩显示功能；错题显示功能；
第三象限（不重要紧急）：注册功能；登录功能；
第四象限（不重要不紧急）：教师查看功能；教师出题功能；
优点：
首先，第一象限中包含的功能是该系统具备的最重要的功能，能够满足该系统存在所能提供的基本意义。
其次，对于我们软件系统功能进行划分后我发现分布于四个象限的事件数量均匀分布。
虽然这并不是最好的时间分配现状，但也让我们有了更加明确的操作思路；给我们一些提示如何去改进目前的工作；
例如方更多的时间和关注在第一象限的需求功能上，减少第四象限中功能的时间投入，获取最大的工作效率，进一步确保项目如期按时的完成。
缺点：
对于第一象限和第二象限中这些紧急的需求功能，我们组还未能按照预期时间进行开发未完成。
相比于第三第四象限中那些不紧急的事情如果还没完成的情况之下，重要工作的未完成让我们更有紧迫感的同时也指明了目前工作的缺陷；
我们下一步就是加快进度，投入更多的时间在重要功能的实现上。
3.尝试把四则运算软件需求进行分解，变为每个小组成员可执行的积压工作项，分配这些工作项到小组成员，并预算完成时间（以小时为单位）。并在完成后填入实际用时。
对于我们的系统详细列出如下需求：
对于这些需求进行细分，得到每个人可以执行的积压工作项：
我们组的进度由于刚开始组员的畏惧心理已经超出了预计的任务完成时间节点，
因此在有限的时间里，我们组目前需要着重加快进度的部分就是进行代码编写的完成。
因为前端后端任务分配开了，因此每个组员都要加快自己手头的工作进度了。
4.总结近5周以来的github上的工作情况，以图表方式分析你小组的工作情况、存在的问题及解决的方案。
工作情况
图表主要摘录自 github 的 Graphs 项，首先是 contributors，
可以看出组长同学还是写的代码比较多的，由于前端的代码还没有正式开始提交，所以有一位同学的代码贡献还不能体现出来。
然后是整个小组的整体 commits 情况，右上角红框显示了从 9 月 4 日（第一个 commit）开始每周的提交情况，
可以看出整体的工作状态还是不错的，代码提交量稳步上升（最近的那周是国庆放假）。
然后是代码提交的时间分布 punch card，绝大多数都是在下午以及晚上进行提交，
这是很容易理解的，毕竟标准的做法便是回宿舍前提交以下，算是整个一天工作的结束。
Network 给出了提交的一个时间跨度上的展示，仍旧是因为前端代码还没有正式进行，所以，显得比较单一。
最后是一个整体的 commit 展示，其频率和数目挺多的，可仍旧是协作人员较少，没能很好的体现整个小组作为一个整体的工作。
