关于 微软必应词典客户端 的案例分析
产品：微软必应词典Android客户端
软件版本号：4.2.6
测试环境：小米手机4
MIUI版本：7.5.10.15（开发版）
Android版本：4.4.4
第一部分 调研，评测
评测：
bug：
1. 在使用“必应电台”功能时，在“网络听力”中任意选择一项，如选择“CRI每日新闻”，随意选择一条进入播放界面，在开始播放后，按下手机上的返回键，虽然页面成功返回，但播放并未停止，并且在进入其他功能如单词发音后，单词发音与之前的播放音同时发出。若此时想停止播放，要么退出软件，要么再次进入该功能，点击右上方按钮进入播放页面选择暂停方可停止其播放。
2. 随意查找一个单词（有词形变化的），点击词形变化后的条目，会发现点击后很快又会返回原来的条目，有时就算成功查看，若返回原条目，会发现词形变化功能消失。
3. “语音翻译”功能中“按住说普通话”有时按住说话后无法提交，仍然在不停加载或相应时间过长，最后提示失败（测试时网络环境为移动4G）。
4. 在“设置”的“离线资源”中，点击下载后，取消下载时在弹出的窗口中选择“立即中止”无法取消下载，点击“继续”反而取消了下载。
这几个bug也不算什么严重的问题，产品组的人没有发现也是正常。就拿第一个bug来说，也许开发人员是考虑到用户可能希望一边听听力一边做别的事，于是就做成和许多音乐播放器一样，可以后台播放。这本无可厚非，但若用户在未手动暂停的情况下，直接进入单词发音功能，并且点击某个单词进行发音，那是否意味着用户此时希望后台播放能够暂停呢？对于这种临界资源（扬声器）的处理，应当是抢占式的，而不应该同时进行。并且我本人仍希望在按返回键时能有提示是否要进入后台播放，毕竟英语听力不同于音乐，也是很烧脑的。至于第三个bug比较难以测试，因为产生这种情况的因素有很多，况且资源来自服务器，对于不同的情况下，网络状况不尽相同。第四个bug应该是写反了……
采访：
采访对象是大三的同学，英语四级，用词典的主要目的就是查查单词和翻译句子。
必应词典基本能达到日常查询单词和翻译句子的需求，界面简洁友好，精确度还不错，体验效果良好，很重要的一点就是没有广告。
改进意见：希望加入四六级模块。
结论：推荐
第二部分 分析
人员分配：
假设为ABCDEF 6人，A为项目经理，B负责UI设计，CDEF负责主程序实现。
1. 需求分析，市场调研，6人同时参与，考虑到可能需要对一些技术进行学习，因此BCDEF 5人工作量适当减少。 时间：1周
2. 原型设计，数据库设计，根据第一周的结果由B负责设计原型，以CDEF 4人为主负责数据库设计。 时间：1周
3. 基本框架设计与搭建，接口统一，需要全员参与讨论。
之后以2周为一个迭代周期，每个周期间隔0.5周进行需求调整，完善剩余6个功能模块。每个迭代周期内，4个程序员可分组进行结对编程，AB在完成自身任务后还需要担任测试人员的工作。
因此大概需要4个月左右的时间。
目前的优劣：
有些单词的解释还不够准确，长句的翻译不论中文还是英文都不够强大，语音识别的功能也不准确，“我爱说英语”必须和例句音调相近才能得高分。
软件工程方面应加强不同人员之间的沟通和交流，明确每个人的分工，尤其是在前期的准备上应当下更大的功夫。在后期调整的过程中，应尽可能的与用户沟通，项目经理要突出作用。
第三部分 建议和规划
在生词本中可以添加“快速定位”的功能：
N：有时候用户需要从某个字母开始查看而不是从A看到Z，或从Z看到A。
A：做法是在生词本的右侧添加从A到Z的快速定位功能，点击A就能快速定位到单词首字母为A的第一个单词。
B：这样做的好处就在于不仅满足了用户需求，并且用户操作起来相当方便和简单。
C：就我所知，金山词霸有这个功能，但是它的定位按键太小了，常常按不到。
D：微软的软件要推广起来也不是什么难事，可以在很多地方植入广告。
如果你的团队有5个人, 4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
除外之外的2人负责开发（可结对编程），1人负责美工，1人负责测试。
描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件。
第一周：需求分析，市场调研。
第二周：项目原型，UI设计。
第三至四周：第一次迭代开发，做出项目大致雏形。
第五周：与客户沟通，及时调整需求，并规划下次计划。
第六至七周：第二次迭代开发，完善需求和功能。
第八周：再次与客户沟通，调整需求。
第九至十周：第三次迭代开发，并发布内部测试版。
第十一周：接受反馈信息，修改bug。
第十二至十三周：第四次迭代开发，并发布测试版，给真正用户测试。
第十四周：根据用户反馈进行调整。
第十五至十六周：最后进行调整，完善，然后部署上线。