第一部分 调研，评测
评测基于微软必应词典Android5.2.2客户端，手机型号为MI NOTE LTE，Android版本为6.0.1。
软件bug：关于这方面，其实有一些疑问。因为相对于市面上其他的词典应用，这个软件的bug实在是是是太多了。（甚至怀疑这个软件不更新是专门作为软工作业的。。。）
下面就一一列举：
- 拍照取词功能。这个功能我试过扫描电子图片上很大的英文单词和纸质试卷上的单词，都无法使用。前者是提示翻译错误（有一次报了java的错误），后者的结果是“没有识别到文字”。我也试了有道词典的拍照取词功能，虽然只有识别打印文字的成功率高些，但是至少可以使用。
- 获取发音失败。点击应用内的每日一句右上角的小喇叭，理应播放这句话的读音，但是点击后显示“正在获取发音...”，之后没有任何反应。再次点击还是同样地结果。另外，今日热词和其中的联想词也有同样的bug。
- “单词挑战”点了没反应，点击旁边的刷新按钮提示“加载失败，请稍候重试”。同样的bug出现在“我爱说英语”按钮上。
- 使用QQ登录功能。这个bug间歇性出现。刚下载安装的时候，点击用QQ登录，没有问题，登录成功。但是多次使用以后，打开应用时突然又让我登录，这次依旧选择使用QQ登录，提示登录失败（详情看下面截图）。但是当我关闭必应词典重试后，使用QQ登录又成功了。
- 页面不全。首页一直拉到最底下时，显示的页面不全（最下面一行字只有上半截），按理说应该可以继续加载之类的，就算不能，也不应该只有半截。
上面是找出的几个主要bug，下面贴几张图。
用户采访：
1）采访对象背景和需求：采访对象是一名普通的大三学生，化学专业，六级英语已过。由于化学专业有很多英语名词，该用户需要一个词典APP来查询专业词汇。另外，该用户的英语听力不是很好，需要平常锻炼听力。
2）采访对象使用必应词典30分钟。
3）用户体验过程及反馈
①过程：用户依从左到右、从上到下的顺序，将该APP的所有功能使用了一遍。使用过程中还与有道词典做了对比。
②优缺点：
- 数据量：体验时查了一些化学专业词汇，基本都能查到，数据量上还可以。
- 界面：用户较为喜欢必应词典这样简单干净的界面，有道词典等的广告和八卦新闻太多。但单词点进去界面不是很美观，有待进步。
- 功能：用户较喜欢推荐阅读、必应电台等功能，有自己的特色功能。
- 准确度：准确度还可以，使用过程中没有出错。
③用户体验：界面简单，有趣的功能比较多，无广告。总体感受不错，但身边没有人用，没有宣传，缺少吸引力。用户表示不会继续用下去。
4）改进意见
- 电台里音频下载时，希望能显示下载进度。
- 翻译的输入框只有一行固定高度，如果要返回去修改之前的输入会很麻烦。建议改成三行高或根据输入自动调节高度。
- 背单词时希望能给一个例句。
结论：b)不推荐。理由是虽然界面简单大方，没有广告，但宣传力度太小，实用功能少，bug太多。所以不太推荐使用。
第二部分 分析
时间分析：
在分析之前必须先肯定一些东西：该团队之前有过软件开发经验，无需过多时间磨合，且需要学习的新技术不是很多。
团队模式采取功能团队模式，开发流程选用统一流程（RUP）。项目时间估计采用回溯法。
下面是估计时间表格。
| 阶段 | 任务 | 估计时间 |
| 磨合阶段 | 团队角色分配，相互熟悉磨合 | 1周 |
| 初始阶段 | 分析软件系统的构成，系统和外部系统的边界在哪里，大致的成本和预算，系统的风险主要在哪里。 | 1周 |
| 细化阶段 | 分析问题领域，确定项目的具体范围、主要功能、性能、安全性、可扩展性等。 | 2-3周 |
| 构造阶段 | 开发出所有的功能集，并有秩序地把功能集成为经过各种测试验证过的产品。 | 10-12周 |
| 交付阶段 | 将产品交给用户内测，基于反馈调整产品功能。可以有多次迭代，最终发布产品。 | 5周 |
| 总计 | 19-22周 |
软件优劣分析：
大部分已经在前面分析过了，这里就做一个总结。主要的优势是界面干净，功能有特色。劣势有实用功能少、bug多、宣传力度小等。
软件工程中可以提高的部分：
刚刚在分析软件功能的时候我大概依照杀手功能/外围功能、必要需求/辅助需求将必应词典的功能做了分类，如下表。
| 杀手功能 | 每天首页的及时更新，单词挑战，我爱说英语等。 |
| 外围功能 | 单词本，经典词库，背单词等。 |
| 必要需求 | 单词查询，翻译准确性。 |
| 辅助需求 | 界面各种皮肤的设计，各个平台的运行支持。 |
我们在完成这个软件的时候，可以先全力以赴将杀手功能和必要需求重叠的部分做好，即单词查询、首页的每日一词和每日一句、单词挑战、我爱说英语等。对于必要需求和外围功能重叠的部分，即单词本、经典词库、背单词等，采取抵消的办法，快速达到和别人差不多的地步。至于剩下的功能，可以等产品上市后有了一定的用户基础，再一步步加上去。这也是构建之法上提到的最小可行产品MVP的思路，先找出最关键、最小的功能集，快速实现，获得用户反馈，再来改进产品。
第三部分 建议和规划
提高：
1）修复不能获取读音的bug，这是必要需求，应放在首位。很多人下载APP的主要目的就是查单词。
2）修复“单词挑战”、“我爱说英语”等功能的bug。
3）设计多种皮肤，让用户的喜爱度加深。
设计功能：
目前市场上词典产品五花八门，功能也是各有千秋。但是这些软件针对口语的联系还是差一些，大多都是一遍一遍地跟读，效果一般。我想设计的功能是一个聊天功能。这个功能很特殊，首先，它有一个类似于微信摇一摇的匹配功能，只能匹配陌生人。然后陌生人之间可以加好友，重点在聊天上，聊天只能发语音且只能用英语。这个功能的目的是通过人们跟陌生人之间对话的好奇感来激发他们自主地想要讲英语的欲望。兴趣是学习最好的老师。想做这个功能的原因是一方面现在还没有软件有这样的功能，另一方面我认为这个功能的受众广泛，从大学生到学英语的中老年人，都会感兴趣。下面用NABCD来分析这个功能。
- N：创意解决了用户缺乏自主联系口语兴趣的需求。
- A：我们是第一个做这个语音聊天学习口语功能的软件，而且我们有微软庞大的用户群。
- B：这个功能能通过人们跟陌生人对话的好奇感来激发用户学习口语的欲望，有兴趣有欲望做事才有效率。
- C：优势一方面在于我们是第一个进入这个市场的，另一方面是微软庞大的用户群，如果在每一个windows系统上都推送这个应用，我们很快就能占据市场。
- D：推广。我认为这是现在必应词典做的最差的一点了。在这次软工作业之前我完全不知道还有这么个东西。我觉得微软完全可以利用自己的用户群和搜索引擎等资源大力推广。
实现功能：
如果我的团队算上我只有5个人，而我又是PM。那么剩下的应该是2个开发人员，1个测试人员，1个美工。
| 团队人员熟悉磨合，确定编码规范，开发流程。 | 第1周 |
| PM召集大家讨论作出初步需求分析，包括技术上完成的难易程度分析。 | 第2-3周 |
| 开发人员进行功能的架构设计，同时攻克匹配算法和语音识别技术。 | 第4-7周 |
| 开发人员根据上一步的设计实现功能，同时美工人员也根据架构设计进行准备。此阶段的最终目标是功能基本成型。 | 第8-12周 |
| 测试人员进行测试，验证需求已被满足。 | 第13-14周 |
| 进入迭代阶段，交给用户体验，收集反馈，对功能进行修改、调整。最终发布。 | 第15-16周 |