福大软工 · 第十次作业 - 项目测评（团队）
写在前面
第一部分 调研，评测
一、评测
软件的bug，功能评测，黑箱测试
1.下载并使用，描述最简单直观的个人第一次上手体验
IOS端
- UI界面简单明了，是我喜欢的极简风格。课程模块界面简洁优雅，功能切换方式灵活便利。
- 登陆界面的验证码识别功能深得我心。（ps：强迫症驱使着我在明知道不区分大小写的前提下，还是不得不切换大小写）
- 功能齐全到让人无法用言语描述，所以只好引用作业原文中的一段话：
查的了成绩、考场、空教室，左通图书馆，右达易班，能抢实验，能下历年卷。
Android端
- 在福大三年，听过很多人推荐福大助手，但是用惯了福大教务通，而且它的功能基本能满足我
需求，就迟迟没有入手这个App。在华为应用市场找到了这个App，只有2.4MB，很快就下好了，这算是我对它的第一个好印象。 - 打开App，迎来的是简洁好看的界面，有趣的是，还可以在设置中更改侧边栏颜色，算是给挑剔颜色的人一个无可反驳的理由去喜欢它。
- 课程表界面和福大教务通没什么大不同，比较有趣的是可以把课程导到日历里面，
好像有了日历就能提醒你按时上课一样。比较尴尬的是这步操作找不到撤销的地方，对于我这种手残点到，看着日历满满当当心烦的人就不是一次很美好的体验了 - 最令人称道的是它丰富的附加功能，可以说把“助手”这两个字发挥到了极点。不管是登易班，还是查空教室，这些功能都是比较有用的，而且在福大教务通中并没有。还有一个有趣的地方是一键评议功能被放到了易班工具中（易班：我没有），并且写成了一键XX，还是比较耐人寻味的。
- 总的来说，体验感还是很不错的，如果有其它朋友需要相似功能的软件，我会向他翘起大拇指推荐福大助手。
2.使用思维导图，描述福大助手的结构体系
3. 按照描述的bug定义，找出至少两个功能性的比较严重的bug
测试主体：
福大助手(IOS端)
福大助手(Android端)
IOS端
- 进入“设置->推送”界面后，APP卡死，无法返回，无法执行其他操作。
- 易班工具使用时一直卡在登陆界面，无法进行其他操作。
- 单科绩点无法显示。
- 虽然验证码识别功能深得我心，但是它偶尔还是会开小差的～
Android端
- 课程表在刷新的过程中点击“+”，“+”功能会消失。
4. 用专业的语言描述bug（每个bug 不少于 40字），并适当配图
BUG描述模版参考知乎：怎样用简洁又清楚的语言将 bug 描述清楚？
IOS端
Bug1
1.标题：“设置->推送”界面，APP卡死，无法返回，无法执行其他操作。
2.测试人员姓名：刘宏岩
3.缺陷报告提交的时间：2018.12.07
4.缺陷的等级：中级
5.缺陷的优先级（等级表明缺陷的严重程度，优先级表明修复缺陷的优先程度）：中级
6.测试环境（包括但是不仅限于使用的设备名称，测试标的物的版本，操作系统的信息。等等一切相关信息）：IPhone8，操作系统及版本：IOS12.1
7.缺陷发生的位置（模块）：“设置->推送”界面
8.预期结果：正常操作，并且可以正常退回主界面。
9.实际结果：APP卡死无反应。
10.重现步骤：打开app依次点击：设置->推送。
11.附图：
Bug2
1.标题：易班工具无法正常登陆，导致APP卡死，无法进行其他操作，且不会提示登陆超时。
2.测试人员姓名：蔡宇航
3.缺陷报告提交的时间：2018.12.07
4.缺陷的等级：中级
5.缺陷的优先级（等级表明缺陷的严重程度，优先级表明修复缺陷的优先程度）：中级
6.测试环境（包括但是不仅限于使用的设备名称，测试标的物的版本，操作系统的信息。等等一切相关信息）：IPhone6s，操作系统及版本：IOS12.1
7.缺陷发生的位置（模块）：“易班工具”界面
8.预期结果：正常登陆。
9.实际结果：APP卡死无反应。
10.重现步骤：打开app依次点击：易班工具。
11.附图：
Bug3
1.标题：成绩查询界面，学分可以显示，但是单科绩点无法显示，单学期绩点无法显示。
2.测试人员姓名：刘宏岩
3.缺陷报告提交的时间：2018.12.07
4.缺陷的等级：初级
5.缺陷的优先级（等级表明缺陷的严重程度，优先级表明修复缺陷的优先程度）：初级
6.测试环境（包括但是不仅限于使用的设备名称，测试标的物的版本，操作系统的信息。等等一切相关信息）：IPhone6s，操作系统及版本：IOS12.1
7.缺陷发生的位置（模块）：“成绩界面”
8.预期结果：正常显示单科绩点。
9.实际结果：绩点一列显示为“-”。
10.重现步骤：打开app依次点击：成绩。
11.附图：
Bug4
1.标题：验证码识别功能识别错误.
2.测试人员姓名：刘宏岩
3.缺陷报告提交的时间：2018.12.07
4.缺陷的等级：初级
5.缺陷的优先级（等级表明缺陷的严重程度，优先级表明修复缺陷的优先程度）：初级
6.测试环境（包括但是不仅限于使用的设备名称，测试标的物的版本，操作系统的信息。等等一切相关信息）：IPhone6s，操作系统及版本：IOS12.1
7.缺陷发生的位置（模块）：“登陆界面”
8.预期结果：正常识别验证码并完成填写。
9.实际结果：有些验证码识别错误。
10.重现步骤：打开app依次点击：进入登陆界面。
11.附图：
Android端
Bug1
1.标题：课程表在刷新的过程中点击“+”，“+”功能消失
2.测试人员姓名：朱志豪
3.缺陷报告提交的时间：2018.12.07
4.缺陷的等级：初级
5.缺陷的优先级（等级表明缺陷的严重程度，优先级表明修复缺陷的优先程度）：初级
6.测试环境（包括但是不仅限于使用的设备名称，测试标的物的版本，操作系统的信息。等等一切相关信息）：IPhone6s，操作系统及版本：Android 8.0.0
7.缺陷发生的位置（模块）：“课程表界面”
8.预期结果：
9.实际结果：
10.重现步骤：打开app依次点击：“+” -> “刷新” -> 在刷新过程中点击“+”
11.附图：
5. 你觉得为什么这个产品组的人没有发现这些bug?
IOS端
- 开发人员在测试时没有注意到这些细节。
- 开发人员忽略了访问教务处可能出现的问题，也有可能是教务处自身的失误造成了这些BUG的产生。
- 运用不同IOS版本进行测试，可能开发团队的测试机没有BUG，但是使用者的某款手机有BUG。
- 验证码识别程序自身存在的BUG。
Android端
- 可能是测试人员不像我会
手贱地在刷新的时候点“+”吧。
6. 假设我们团队需要开发这套系统，需注意的方面
- 如果我们团队要开发这套系统的话，首先要踩在巨人的肩膀上，找一找有没有合适的可以借鉴的系统。同时要做好需求分析，明确我们的客户，系统的用户是谁，他们需要解决什么问题。很显然，用户群体是福大可爱的学生们。便捷的体验和强大的功能是免不了的，当然，对学生来说最重要的免费版也是必不可少的。
- 架构方面要做到可靠性，安全性和可维护性，尤其是要考虑到用户的体验，必须保证容易上手。
- 运行维护方面只能辛苦我们的开发团队每隔一段时间进行一次维护了，相信我们的用户也会积极反馈问题，大大加快这个软件进入能用好用的阶段。
- 微服务方面我们会安排金牌客服宏岩，在线满足各类需求。
二、采访
第8章 用户调研，12 章 软件的用户体验，
被采访人 ：林佳炜（数计学院2018级新生）
采访过程：
- 请问您使用过福大助手吗？
答：没有使用过，我现在在用福大教务通。 - 在使用福大教务通的过程中，有什么是你需要却没有的功能吗？
答：有的，比如它无法查历年卷，无法看空教室。 - 正好现在就有这么一款app推荐给您，叫做福大助手，可以满足您的这些需求，你可以现场试一下。
答：好啊。 - 在使用这款软件的过程中，你的问题解决了吗？
答：解决了，这款软件非常好用，不仅可以看教务通知，还可以查历年卷。 - 软件在数据量/界面/功能/准确度上各有什么优缺点？
答：数据量的话我很满意了，界面也是我比较喜欢的简洁型，功能很齐全。准确度的话，我打开了历年卷里的ppt，感觉还是不错的。 - 用户体验方面有问题么？
答：用户体验上感觉还不错，功能比较完善，而且使用起来并不困难。 - 您对产品有什么改进意见？
答：如果能够兼容安卓9.0以上就好了。 - 若要给这个软件下一个评价,请选择一个结论:
a 非常不推荐
b 不推荐
c 一般
d 推荐
e 非常推荐
答： d
第二部分 分析
参考 8.6 节 对工作的估计， 和14.1 节 软件工程的质量
1. 估计这个项目做到这个程度大约需要多少时间（团队人数6人左右，计算机大学毕业生，并有专业UI 支持）。
- 如果这个团队具有熟悉安卓开发和iOS开发，以及能够熟练掌握接口设置的同学的话，估计需要3至4个月时间。
- 如果团队中没有同学有过类似的开发经验的话，算上学习时间和熟悉开发工具的时间，估计需要半年时间。
2. 分析这个软件目前的优劣（和类似软件相比），并推理出开发团队在软件工程方面可以提高的一个重要部分（具体建议）
我们将福大助手与三个类似软件相比，分别是：超级课程表、课程盒子和针对武汉大学生的微信小程序“在武大”。
- 由于前两者是面向全国大学生的，所以他们的功能更加偏向显示课表、查询成绩以及各校学生的交流互动。与这两者对比，福大助手更加本土化，除了显示课表、查询成绩功能，它还可以使用福大易班的相关工具，更便于福大学生的使用。
- 微信小程序“在武大”，如果说把搭载在微信上算是他的一个劣势的话，那似乎这个小程序涵盖了福大助手的所有功能。包括图书馆借阅查询、成绩查询、故障报修等等。甚至还有失误招领、校园巴士以及一些娱乐项目。
- 如果说福大助手与之相比的优势的话那估计就是他能够直接查看学校教务处信息
和提供学科历年卷以及一键XX的功能了。（敏感词已屏蔽） - 在对比了三个软件之后，我们觉的开发团队要在软件中添加一个动态功能，一个能够让用户进行社交的平台，有助于学生之间的交流和一些校园有趣事情的分享。这是前三个软件都具有而福大助手没有的功能。那么可以认为，当年开发团队在开发福大助手的时候，当时的学生用户是不需要这种平台功能的，而现在的大学生对此的需求量还是很大的。所以我认为，开发团队需要在软件工程的用户调研方面实时跟上进度，起码半年进行一次，否则很有可能漏掉当代用户的需求。
3. 根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果。
原图显示：
4. 针对不同的维度评分，对用户体验方面、UI界面美观度、核心功能，分别打分。
用户体验：★★★☆☆
- 可以很容易地上手，各个功能在页面中的分布也很合理。
UI界面美观度：★★★★☆
- 感觉已经是理工学生的UI巅峰水平。
核心功能：★★★★☆
- 能够显示课表、查询成绩、使用易班工具和进入教务处，都完成的很不错。就是存在一些些的bug以及处理边界问题的手段不够高明。
第三部分 建议和规划
参考《构建之法》第8章 功能的定位和优先级；第9章 项目经理
这个软件有很多可以提高的部分。
1.如果你是项目经理，如何提高从而在竞争中胜出？
- 如我我是项目经理，我将会从以下几方面提高我们产品的竞争力：
- 质量保障：高质量是一个有竞争力的产品必须具备的条件。作为一个产品经理，我将从以下两方面提高软件质量：
- “磨刀不误砍柴工”，在软件开发工作进行前，应先根据项目的大小和个人的能力进行合理的分工，并制定代码规范等一系列标准。
- 正如柯老板所说的，“一个好的公司，测试和开发人员的地位是同等重要的”，所以我们会运用一定的流程和工具，量化工作的流程和结果，例如：测试用例、BUG、代码覆盖率、MTTF、软件效能参数等等。将测试结果反馈开发人员进行进一步的调试优化。确保产品的高质量。
- 迭代模式：在每次软件更新时，除了修复已知BUG和进行细节优化，还可以加入一些实验性的功能，以吸引新的用户群体和提高不同用户分群的留存率。
- 自我分析：采用SWOT框架分析本产品进行创新过程中可能遇到的问题，并有针对性地采取方案。
- 宣传推广：制定合理的宣传策略，提高产品的知名度，开展活动，吸引更多的用户。
- 提高用户体验：定期投放问卷，进行用户调研，根据用户反馈有针对性地进行改进，以提高用户体验
- 质量保障：高质量是一个有竞争力的产品必须具备的条件。作为一个产品经理，我将从以下两方面提高软件质量：
2.目前市场上有什么样的产品了？
- 目前市场上的同类产品主要有：
- 福大教务通
- 超级课程表
- 课程格子
- 课程表助手
- 轻课表
- MD课表
- 我的课程表
3.你要设计什么样的功能？
- 杀手功能（Core）
- 课程表
- 日程管理
- 成绩查询
- 考场查询
- 空教室查询和申请
- 课程资源共享
- 师资信息
- 校招信息
- 外围功能（Context）
- 宿舍报修
- 图书借阅
- 实验预约
- 校园地图
- 教务通知
4.为何要做这个功能，而不是其他功能？
- 课程表、日程管理、成绩查询、考场查询、课程资源共享这些功能是此类产品的基础功能，如果产品缺少此类功能，可能会流失大量用户。
- 空教室查询、师资信息、校招信息这些功能能很好地满足大部分用户的需求，开发此类功能为了面向主要用户群体。
- 宿舍报修、图书借阅、实验预约、校园地图、教务通知这些功能相比于前面的那些，用户使用频率较低，开发此类功能主要为开拓潜在用户群体的市场。
- 除了上述功能之外，其他功能暂时不做考虑，一方面，因为用户群体对这些功能的需求并不是很大，投入极大人力物力资源来满足极小部分用户的需求；除了投入多产出少，另一方面，对于本产品面向的主要用户群体来说，加入这些功能，将使软件变得“臃肿”，造成不良的用户体验。
5.为什么用户会用你的产品/功能？
- 横向来看，正如《构建之法》中所述：“让用户惊喜的功能一旦出现，就能给用户的满意度带来正面帮助。”用户之所以会选择我们的产品，就是因为我们的产品相较于别的产品有更有亮点，更能给用户带来惊喜。例如：使用本产品的师资信息功能在选课时候相较于通过网页手动查询教师信息的方式更能给用户带来便利，提升用户满意度。
- 纵向来看，用户对课表查询、成绩查询等基础功能性存在强烈需求。本产品正是为了满足用户的基本需求而设计的，功能齐全，能较好地满足用户的基本需求。除了产品本身能满足用户的需求外，从产品本身来看，产品良好的设计给用户良好的用户体验，使用户在使用本产品时身心愉悦，具有一定的黏性。
- 综合来说，本产品的核心价值或服务、交互体验，运营宣传等都是用户持续使用本产品的原因。
6.你的创新在哪里？可以用 NABCD 分析
- 我们的产品的主要创新功能有：师资信息、校招信息。
- 采用NABCD模型按部就班分析：
- N （Need，需求）
- 用户的需求有：
- 对于师资信息：学生需要详细了解授课教师
- 对于校招方案：学生在报考该学校，需要详细了解该学校。
- 用户存在的痛点有：
- 对于师资信息：例如：1.学生在选课时只能看到教师姓名，想要详细了解只能一个个去各学院官方网站查找，十分不便。2.在选择导师时，无法详细地了解每个导师擅长的方向和研究的领域，导致最后做出的选择可能并不是最适合自己的。
- 对于校招信息：学生在报考学校时，只能通过百度百科、学校官网、或者亲自咨询目标院校的学生，了解信息不够全面不够及时。
- 用户的需求有：
- A （Approach，做法）
- 解决方案：
- 对于师资信息：从各个学院官方网站整合师资信息。
- 对于校招信息：将学校发布的校招信息及时推送给用户，并且给出往年校招信息，作为参考，让用户可以自行对比，及时了解招生政策的变化情况。
- 解决方案：
- B （Benefit，好处）
这些创新功能给用户带来了及时的信息，并简化了信息收集的过程。 - C （Competitors，竞争）
- 优势：软件质量高，可靠性强，交互友好
- 劣势：因缺少官方接口，数据获取采用爬虫实现，效率低。不利于商用化推广。
- D （Delivery，推广）
- 制定合理的宣传策略，提高产品的知名度，开展活动，如：
- 可以与校方合作，以二维码、链接形式分享推广
- 通过邀请新用户注册给予一定奖励形式推广
- 制定合理的宣传策略，提高产品的知名度，开展活动，如：
- N （Need，需求）
7.如果你来领导这个团队，会有什么不一样？
- 正如亚当·斯密所说：“分工的起源是由于人的才能具有自然差异”，如果我来领导这个团队，我会更加重视分工，根据每个人的能力进行合理的任务分配和deadline制定。也像柯老板说的一样，“deadline是第一生产力”，合理地制定deadline能推动整个工程项目的进度。适时对组内成员进行push，跟进项目进度，进行督促，定期召开站立会议。注重团队成员之间的沟通，例如可以进行利用共享文档编写工作总结，实现组内成员之间进度的相互了解，以便在遇到瓶颈时集中力量克服困难。
8.如果你的团队有5个人,4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？
| 角色 | 项目初始阶段 | 详细设计阶段 | 编码阶段 | 测试阶段 | |
|---|---|---|---|---|---|
| 项目经理 | 制定软件规格需求说明书，评估风险 | 审批方案 | 跟进项目进度，组织召开会议 | 审核测试报告 | |
| IOS端开发 | 了解客户需求，统一开发流程规范 | 框架搭建，接口设计 | 开发IOS端App | 根据测试人员返回的结果，改进优化 | |
| Android端开发 | 了解客户需求，统一开发流程规范 | 框架搭建，接口设计 | 开发Android端App | 根据测试人员返回的结果，改进优化 | |
| 美工 | 了解客户需求 | 应用专业知识，设计符合客户要求的UI界面 | 根据程序编写的实际需求提供额外的图片 | 协助交互测试 | |
| 测试人员 | 制定测试计划 | 设计测试用例 | 根据测试计划，编写测试数据、测试脚本 | 执行测试并提交测试报告 |
9.描述你的团队在16 周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定
| 时间/周 | 工作 |
|---|---|
| 1-3 | 需求分析，文档规范撰写 |
| 4 | 界面设计 |
| 5 | 界面美化 |
| 6 | 客户端框架搭建，模块接口设计 |
| 7 | 服务器搭建 |
| 8-11 | Android、IOS编码 |
| 12-15 | 程序测试，bug修改 |
| 16 | 正式上线，发布产品 |
10.项目发布后，有没有考虑过项目该怎么部署才能满足需求。依据附录图（某校教务处系统的部署）作为参考，分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置)
- 应用服务器配置：8核8G*3（2台日常使用,分IOS、安卓，1台作为备用服务器）
- 后端服务器配置：8核8G*3（2台日常使用，1台作为备用服务器）
- 关系型数据库：MySQL，数量2（一个日常使用，一个备份）
- 带宽：20Gbps
第四部分 增量开发设计
1. 我的日程
- 新增功能点的原型界面
- 基本实现思路
- 对于每个用户，每新建一个日程，就将其同步到数据库中，以便记录用户日程。
- 日程如上图所示，每个日程为一个简单的小卡片，全部日程以时间轴的方式进行查看，使得整个界面更加简洁有条理。
- 对于每个日程可单独管理，通过右划小卡片可以对卡片进行删除和修改。
- 可以增加日历事件，选择性同步到手机自带的日程、闹钟提醒以及在通知栏上提示，用户可以通过每个日程小卡片上快捷开关，对每个日程单独管理，选择提醒或不提醒
- 时间轴上每个日程对应的小方块，对于选择提醒的日程会为蓝色，选择不提醒的日程为白色，更加方便查看。
- 新增功能点与原有产品如何接入
- 新增的日程功能是以福大助手的一个子功能接入，与其他现有功能交集小，接入十分简单。
- 我的日程的进入点可以同福大助手的其他子功能一样，放在福大助手本身的右侧菜单栏上。
- 数据库方面，可以以原来的用户列表做一个索引，对于每个用户的日程单独做一个数据表，通过原来的用户表索引找到这个日程数据表。
- 我的日程也可尝试与课表接入，把相应时间段的日程放入课表显示。这个功能需要与课表显示接入。在日程数据库中新增一个标志位，对于要加入课表的日程就设置这个标志位置“1”，在生成课表时，可以先遍历日程数据表，将置“1”的日程加入课表。
第五部分 答辩总结
得分
| 第一组 | 第二组 | 第三组 | 第四组 | 第五组 | 第六组 | 第七组 | 第八组 | 第九组 | 平均分 |
|---|---|---|---|---|---|---|---|---|---|
| 67 | 77 | 78 | 81 | 82 | 69 | 68 | 81 | 75.8 |
- 说明：第八组的分数在经过沟通之后对方同意修改，改为81。
贡献度
| 名 | 贡献度 | 工作量比例 |
|---|---|---|
| 燊 | 10% | 10% |
| 钧昊 | 10% | 10% |
| 俞辛 | 10% | 10% |
| 宏岩 | 14% | 14% |
| 喜源 | 11% | 11% |
| 柏涛 | 11% | 11% |
| 宇航 | 11% | 11% |
| 恺翔 | 10% | 10% |
| 志豪 | 13% | 13% |
Q&A
1.爸爸饿了队
- 问：评测报告与PPT中展示的内容不一致，ppt制作先于报告，是否考虑以后避免这样的问题出现？
- 答：以后会加强审核工作。
- 问：希望更多的内容通过演讲者口述出来，ppt用来展示更多图表
- 答：好的，感谢你的建议。
- 问：增量开发的实现难度如何，大概需要多长的工作时间？
- 答：增量开发实现难度不大，在熟悉产品的情况下半个月可以实现。
2.拖鞋旅游队
- 问：为什么IOS端与Android端的BUG数量有所差异？
- 答：我们组员大部分都是IOS的手机，而且负责测试的组员也是IOS手机导致安卓端测试时间较少，所以BUG数量有差异。
- 问：第八第九页的GIF已经糊了，是否应采取其他形式来展示BUG？
- 答：GIF是因为视频转格式问题导致模糊，现场采用了直接播放视频的形式来展示，下次会做好提前审核。
- 问：增量开发的功能已与日历功能相近，是否真的有必要实现？
- 答：我们认为这个功能还是有必要的。
3.彳艮彳亍队
- 问：Android端的bug数量较少，是否是Android端测试交缺漏？会不会有其他bug没检测出来？
- 答：初期安卓端确实测试有缺漏，后期我们已经补上，详见我们的测试报告。
- 问：PPT制作更加精美细致吗？如文字的大小等。（仅是建议。）
- 答：感谢你的建议，下次我们会做的更好。
- 问：视频和GIF图片，一个没有配音，一个图像过于模糊，能否更好解决？
- 答：视频问题在我们电脑上测试良好，现场可能由于音响原因倒是没有声音，图像问题因为格式转换问题导致模糊，主要还是我们审核工作没做好，下次会注意。
5.起床一起肝活队
- 问：BUG测试中IOS端和Android端的BUG数量差距明显，IOS端4个，Android端才1个，Android端才开发1年，BUG明显应该更多，为什么只找出了一个呢？
- 答：安卓端BUG已经补充，详见测试报告。
- 问：功能逻辑框图缺少了一键评议、大物实验、嘉锡讲坛和二手市场这四个功能模块，为什么呢？
- 答：我们是根据IOS端来做的逻辑框图，IOS端并没有这几个功能。
- 问：在报告中第六部分测试结果与建议，其中全是文字，为什么没有图片，而且这部分内容是否过少了呢？
- 答：去学习了一下贵组的第六部分是怎么叙述的，发现贵组无非是把测试结果的表格做成了一张图片，然后写了一个总体分析，一共四行建议。希望这个建议我们两组共勉。
6.404 Note Found队
- 问：安卓端bug为什么只有一个呢？
- 答：已经补充详见测试报告。
- 问：PPT上的内容展示是否会字数过多，内容冗余？
- 答：是的，这次PPT制作策略上出了点问题，下次会改进。
- 问：PPT上的产品分析对比和文档上的产品分析对比为什么不一致呢？
- 答：由于测试报告和PPT是不同同学负责制作，又没有做好审核工作，所以出现了这个问题。
7.第三视角
- 问：为什么不对视频进行后期录音或者配置简单的录音设备？
- 答：视频在我们的笔记本上查看是有声音的，不知道为何现场演示的时候出现了这个问题。
- 问：关于过小的字体和部分高糊图片是不是应该考虑下观感？
- 答：感谢你的建议，下次会改进。
- 问：增量开发的部分会不会显得有点略简单了？
- 答：简单实用也不失为一件好事。
8.小白吃
- 问：ppt中采访的是对福大教务通的使用情况，为什么没有呈现对福大助手的采访？
- 答：PPT只截取了部分采访情况，具体采访情况可以看我们博客。
- 问：从bug评测那起ppt里的文字变得非常多，请问是否考虑过观众的观看体验。
- 答：感谢您的建议，下次我们会改进。
- 问：思维导图内容之多，是否应该取其重点呈现，而不是一次性的放一整个部分？为什么部分图片高糊？
- 答：高糊问题我们确实没有做好审核工作，思维导图希望可以换个方式展示也许会更好。
第六部分 个人部分
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 100 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 100 | 60 |
| Development | 开发 | 560 | 500 |
| · Analysis | · 需求分析 (包括学习新技术) | 120 | 120 |
| · Design Spec | · 生成设计文档 | 0 | 0 |
| · Design Review | · 设计复审 | 0 | 0 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 240 | 180 |
| · Coding | · 具体编码 | 180 | 200 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 40 | 0 |
| Reporting | 报告 | 50 | 60 |
| · Test Repor | · 测试报告 | 10 | 10 |
| · Size Measurement | · 计算工作量 | 20 | 5 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 20 | 45 |
| 合计 | 710 | 620 |
学习进度条
| 第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
|---|---|---|---|---|---|
| 1 | 300 | 300 | 15 | 15 | map 容器的性能瓶颈分析 |
| 2 | 0 | 300 | 8 | 23 | 完成基本功能的实现及附加功能的构思 |
| 3 | 200 | 500 | 8 | 31 | 学习 python 中与附加功能相关的库，例如 wordcloud |
| 4 | 0 | 500 | 5 | 36 | 学习了分而治之alpha版本事项和用例图的绘制 |
| 5 | 0 | 500 | 8 | 44 | 学会了简单的原型设计和写没人看的剧本 |
| 6 | 240 | 740 | 8 | 52 | 学习了xml和Android studio的一些简单使用，以及简单的P图技术，熟悉了python语言，学会用python画直方图 |
| 7 | 50 | 790 | 5 | 57 | 熟悉了前端和python语言 |
| 8 | 200 | 990 | 7 | 64 | 熟悉了前端和制作，前端一些特效的学习，AR技术的学习，前后端的连接 |
| 9 | 0 | 990 | 5 | 69 | 团队测评PPT的制作，答辩，采访和测试部分工作 |
