组长博客链接

作业链接

评测：

福大助手的bug

IOS端

• 如果没有对“福大助手”进行日历的授权设置，那么“考场”中的“加入日历”功能无法实现，点击“加入日历”提示“授权失败”的窗口，但是没有引导用户进行授权的窗口；

• “设置”中的“推送”功能没有实现，点击“推送”显示页面后无法操作，所有Switch按钮无效，也无法回退到“设置”界面；

• “一键评议”功能如果输入错误的字符串会多次提示“发送未知错误，评议失败，尝试继续评议”，然后app崩溃；

• “易班工具”中的“辅导员考核”功能，输入“得分”栏的数据为字母或特殊字符（如@、&等）点击“保存”后没有提示“只能输入数字”的窗口，而是直接显示“辅导员考核详情”页面

Android端

• 进入设置页面，编辑侧边栏的时候，要是选择不显示现在所在的功能页面，退出设置之后，还会存在取消的页面，这个是逻辑上不符的。

• “一键xx”功能，如果反复切换评议用途，切换过后的页面刷新初始化十分缓慢，有时出现初始化的情况，“验证码”无论输入的是什么，都能够开始评议。

福大助手结构体系的思维导图

• 按照描述的bug定义，找出至少两个功能性的比较严重的bug。用专业的语言描述bug（每个bug 不少于 40字），并适当配图.

为什么开发人员没有发现这个bug

• 可能开发人员主要专注于软件主要功能的实现上，测试的话也是会尽量按比较单一的角度测试，所以对于软件的这些个bug就比较难测试出来。

假设团队开发这款app,应注意哪些方面（架构、部署运维、微服务等）？

应注意采用微服务构架以及提高运维要求两方面。

众所周知，福大助手是由福大本校学生组成的西二在线所开发，随着学生不断的毕业以及新技术的不断尝试，团队本身的人员组成以及项目使用的技术会以相当高的频率迭代。同样，作为福大本地化软件，福大助手无疑会在将来不断地进行优化。

对于这类快速更新迭代的团队，随着时间及项目规模的扩大，传统的单体架构有着“复杂性逐渐变高”、“技术债务逐渐上升”、“部署速度逐渐变慢”、“阻碍技术创新”及“无法按需伸缩”的问题。
在此我们先引入微服务这一理念。

微服务，以单一职责、服务自治、轻量级通信及接口明确为设计原则的一种架构风格；而针对福大助手这一app，我们认为最应该注意的是项目应该采用微服务构架。
为什么这样说呢？我们看看微服务和传统单体构架的区别：

1. 单体架构所有的模块全都耦合在一块，代码量大，维护困难；微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

2. 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3. 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

很明显 ，微服务架构其本质便是在结构上实现各个服务模块的松耦合。
就福大助手来说，微服务能为团队带来主要好处如下：

1. 易于开发和维护：微服务单个模块就相当于一个项目，开发时仅需观察其单独的逻辑，易于团队开发和维护app功能。
2. 能够局部修改且容易部署：同样，当某个模块出现bug时，团队能够仅关注于完善出现bug的模块，在解决后只需要单独重启这一模块的服务即可，部署相对简单。
3. 技术栈不受限：由于微服务“单一职责”和“服务自治”的设计原则，技术人员在实现微服务模块时仅需考虑模块本身的业务逻辑，其实现技术本身并没有限制，有利于项目长远的技术创新，同样方便新加入的团队成员接手项目。
4. 按需伸缩：类似与3中所述，开发时仅需关注模块自身逻辑，进行性能扩展时不必考虑其它模块的情况，团队能够及时根据需求对功能模块进行调整优化。

然而，在微服务带来种种好处的同时，它也有一些需要注意的不足：

1. 对团队的运维提出了很高的要求：
   对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。在团队的实际资源分配中，势必要比以往投入更多的资源在运维上。
2. 微服务是一个分布式系统
   对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

采访

福大助手采访：

采访一

• 介绍采访对象的背景和需求
  使用过易班、福大教务通、超级课程表等相关软件。除了现有功能没有什么其他需求。
• 让采访对象使用福大助手（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）
  
• 描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
  这个软件功能很强大，可以解决想要解决的问题。在数据方面，数据量大，可以查很多东西。界面很友好。准确度没有什么问题。用户体验上，它的功能很复杂，在只想看课表的时候更倾向于教务通，因为它功能单一，看起来比较清晰简单。福大助手平时反而不会用。
• 用户对产品有什么改进意见？
  这款软件很强大，没有意见。
• 结论
  非常推荐

采访二：

• 介绍采访对象的背景和需求
  使用过易班、福大教务通、超级课程表等相关软件。希望通过软件方便自己学习和生活。
• 让采访对象使用福大助手（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）
  
• 描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
  这个软件功能很强大，可以解决想要解决的问题。里面东西很多，被安利了。界面有更换主题功能，非常适合自己。功能上，还希望能增加交水电费和校园卡充值功能。准确度上和其他类似软件没有区别。
• 用户对产品有什么改进意见？
  增加交水电费和校园卡充值功能。
• 结论
  推荐

采访三：

• 介绍采访对象的背景和需求
  使用过易班、福大教务通、超级课程表等相关软件。希望只用一款app包括所有内容的软件，不想自己的qpp太多。
• 让采访对象使用福大助手（请上传照片证明用户的确正在使用，远程采访的同学请让别人帮忙照相）
  
• 描述用户使用这个产品的过程, 用户的问题解决了么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
  这个软件功能很强大，可以解决想要解决的问题。数据量方面，里面包括了教务通和易班的大部分内容，界面方面，非常不友好，感觉不好看，iOS手机界面和android手机不同，课程表界面和侧边栏界面不好看。准确度方面，和另外两款没差。用户体验上，第一感觉界面不友好。
• 用户对产品有什么改进意见？
  将ios的界面设计得更友好。
• 结论
  一般

第二部分 分析

估计这个项目做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。

• 三个半月。
  主要分为萌芽，磨合，规范，创造四个阶段。
  人员分工为项目负责人一人，前端两人，后端两人，算法一人，并有专业UI支持。
  

• 一、萌芽时期花费半个月。
  （1）根据调查客户需求进行需求创作，需求再改进，由项目负责人和开发共同确认需求可行。
  （2）然后UI设计和前端进行具体讨论，给出一套完整的需求文档，确定项目开发周期。
  （3）根据以上讨论结果对整个项目进行一个总体的规划，进而确定项目的详细功能和人员的具体分工。

• 二、磨合时期花费两个月。
  （1）原型设计阶段花费十天左右，前期画出产品的基本草图页面，其中包括:产品原型页面交互/产品功能说明文档，前端根据需求分析设计出一套大致的原型设计模型，后期UI设计给出具体建议，对原型进行具体改进，得出一个理想实现界面，并给出产品结构图、模块功能梳理清单。
  （2）开发设计阶段需要一个多月，这阶段主要是前后端开发设计以及前后端交接，实现产品的具体功能，这个阶段应该注意的一点是比如注册域名、买服务器、备案、苹果开发者账号、安卓开发者账号、短信服务等等。在确定开发后就可以准备这些东西了。不然中途会影响开发工期，影响上线时间。
  （3）磨合后期进行初步验收测试，兼容性调试开发。并及时解决此产品不兼容问题，bug问题和闪退问题。

• 三、规范时期花费半个月。
  在磨合期已经得出项目的胚型，规范时期就是对项目进行优化改进，对产品进行调整和增删。
  （1）前端进行版块细化，界面调整和功能增删。
  （2）后端则及时给出接口，与前端进行对接。
  （3）UI设计则注重界面美化，使用户得到一个简洁美观的观赏页面。
  （4）阶段后期进行项目总测试，对项目完整的进行一个验收测试，并给出US流程图。

• 四、创新阶段花费半个月。
  （1）app可小范围的进行发布使用，投入线下运营。
  （2）及时得到用户反馈，进行项目改进优化，最终得出一个简洁实用的app。

分析这个软件目前的优劣(和类似软件相比)，并推理出开发团队在软件工程方面可以提高的一个重要部分(具体建议)

• 优点：
  （1）侧边栏设置简洁，易于观看搜索。
  （2）课程表导出到日历，提醒成绩正在更新。
  （3）相比福大教务处和福大易班，闪退和卡顿更少，用户体验更佳。
  （4）一键评议。可对老师评价进行一键评议，节省时间精力，使用方便快捷。
  （5）功能齐全，相比教务处，福大助手在功能设置这方面丝毫不逊色，而且更胜一筹，包含功能都是学生经常使用的功能，以学生为出发点，更能理解学生需求。
• 缺点：
  （1）成绩查看功能部分无成绩变化图，不可观察成绩波动。
  （2）宣传力度不够，APP宣传大多是通过同学间口口相传，没有最大程度的开发潜在用户，宣传渠道匮乏，进而使产品得不到最大化的使用，也因此得不到更多反馈建议，从而进行项目优化，拉低了app的整体使用效果。
  （3）界面简洁美观，但过于单一，缺少创意，主题设置方面无自定义壁纸选项，不具备在线图库选择功能。

根据理解和体验，画出整个软件所有功能逻辑框图，根据重要度标识出各模块的重要度、完成度、出发点及效果;

重要度为蓝色框，完成度为橘色框

针对不同的维度评分，对用户体验方面、Ul界面美观度、核心功能，分别打分。

第三部分 建议和规划

参考《构建之法》第8章 功能的定位和优先级；第9章 项目经理

这个软件有很多可以提高的部分。

如果你是项目经理，如何提高从而在竞争中胜出？

• 在拥有竞争对手杀手功能的同时，开发出竞争对手不具有的功能。只有不断创新，才能立于不败之地。
• 优化外围功能，尽可能提升用户使用感受，扩大固定用户群体。
• 现有的软件尽管有很多可以提高的部分，但是确实已经做得不错了，不少同学没有使用是因为不知道有这个软件。福大助手功能众多，甚至拥有福大教务处、福大易班、期末考啦这三个app所谓的杀手功能。所以应该加大宣传力度，让更多的同学尝试使用。

目前市面上有什么样的产品了？

• 福大教务处
  福州大学教务处官方推出的一款集课表，成绩查询，学业分析，学期选课，空教室查询等多个功能于一体的教务app。
• 福大易班
  集福州大学学生工作、学习、生活方面为一体的校园服务办理app。（基本上集齐了学校大部分个人日常需要申请办理的事务，但部分功能能否使用/使用感受大家都懂）
• 期末考啦
  面向福州大学的学生学习资料分享软件。
• 超级课程表
  以课程表为基础展开的校园实用工具。部分福大学生会使用这个app查看课表。

你要设计什么样的功能？

优化部分：

• 课程查询
  提供查询其他专业开课情况的功能，用户在查询到感兴趣的课程的情况下可以使用课程表内现有的添加课程功能将课程添加到课程表。
• 课程导出到日历提示
  点击导出到日历功能后出现弹窗显示：在设置-清除数据里可撤销导出操作。
• 学业分析（ios版本有，Android版本没有）
  提供可视化的绩点排名变化、修习学分统计、修习情况的分析。
• 校历查看（ios版本有，Android版本没有）
  查看活动安排、假期安排等情况。

创新部分：

• 同学帮
  实名制的同学互动平台。分成学习、生活两部分。学习部分主要用来发布一些面向用户的个人学习信息。用户可以在这个板块发布找研友、有偿考研信息分享交流、有偿期末答疑解惑等消息。生活部分主要用来发布一些生活上的便利互助信息，如打车拼单、闲置物品转让出售等。
• 在线签到点名
  最小以班级为单位在该板块上发布签到活动，用户在指定地点附近输入特定信息可进行签到签退点名。
• 教师信息查询
  提供教师的个人资料，授课情况，挂科率高分率、学生评价。

为什么要做这个功能，而不是其他功能？

• 同学帮
  我们为福大助手设计了一个板块用于学生间的交流。目前学校资源的分享或出售往往是通过qq群聊，效率低且充满了不确定性。但由于而福大助手实名制的平台提升了学生间交流的效率。该功能的实现需要投入一定成本的开发，但是我们认为这个功能是有用户群体且有是回报的。用户群体形成，社区化的平台可以用来投放考研信息、餐饮宣传等广告，广告集成在这个板块不会影响福大助手其他功能的使用。
• 课程查询
  大学课堂一个很重要的特点就是可以任意蹭到想上的课。提供校内课程查询的功能可以使用户方便地查获想上的课的时间地点并添加到课程表。这个功能提升了用户使用感受且实现成本不大。
• 导出到日历提示
  很多人点击课程导出到日历功能往往只是为了测试这个功能的实现效果如何，但是导出到日历这个功能实际效果并不是很好（如图，不仅不能使课程全部清晰地展示在日历上而且会影响日历的观感，甚至可能导致一些重要事件被盖住）。而且撤销这个操作的行为按键过于隐，用户不易找到。
  但不可否认确实有部分用户会使用课程导出到日历这个功能，因此我们做出的优化手段是在后出现弹窗显示：在设置-清除数据里可撤销导出操作。
• 学业分析、教师信息查询、在线点名签到、校历查看
  学业分析，福大助手不具备的福大教务处的功能两个功能之一，比起可有可无的培养计划，学业分析有一定用户需求。
  教师信息查询，受西二在线公众号这个功能的启发，学生在选课时面对不熟悉的老师能从这里找到一点信息帮助选课，用户需求较大。
  在线点名签到，受到小小签到启发，大学生需要签到签退的场合很多，用户需求大。比起手动签名，电子签到的形式更有效率且适合集成到福大助手这个平台。
  校历查看，提供可视化的学校时间安排，实现成本低，需求大。

总结：福大助手侧边栏支持自定义，理论上只要是有用的功能都能加上去，且不影响用户使用。考虑到实现成本与收益的问题我们为福大助手增加了以上优化和新增功能点。

为什么用户会用你的产品/功能？

在为什么要做这个功能，而不是其他功能？这个问题里已经有体现。

你的创新在哪里？可用nabcd分析。

我们对福大助手app改进的主要创新点在同学帮这个模块。

• N(Need,需求)
  现阶段大学校园内资料分享、物品交易等活动十分丰富，但是此类活动沟通的平台往往是在qq、微信群聊中，充满了不确定性且交易的效率低下。
• A(Approach,做法)
  我们为福大助手app设计了“同学帮”这个模块用于同学间的交流。福州大学的学生可在此平台上分享或出售考研资料，寻找研友，交易闲置物品，发布拼单信息等。
• B(Benefit,好处)
  福大助手实名制的特点使沟通变得透明安全且更有效率。因此这个功能预计可以带来可观用户群体。
• C(Competitors,竞争)
  目前基于福大其他校内的服务软件均未提供这个功能。福大助手ios版本推出的“二手市场”模块和超级课程表推出的沟通功能“下课聊”是匿名制，用户群体小且与我们基于实名制的创新点没有冲突。
• D(Delivery,推广)
  在物品交易、考研分享群里宣传，让更多潜在用户体验该功能。累积一定用户群体后，我们可以在社区化的模块里的广告版面投入诸如考研信息等广告进行盈利。

如果你来领导团队，会有什么不一样？

一个产品从想法的萌芽到最后的交付给用户使用，甚至上架销售，私以为包括了五个部分：需求分析，冲刺安排，冲刺，测试和迭代，上架宣传。《构建之法》的第185页谈到：“PM做开发和测试之外的所有事情”，所以一个优秀的PM是不会参与或者尽可能少的参与软件的开发的。所以来说，如果我来领导团队，中间的三部分是不会发生变化的，所以我这里主要说明对于需求分析和上架宣传的看法。对于需求分析部分，《构建之法》的第八章，功能的定位和优先级中进行了详细的说明。我们可以通过《构建之法》提出的使用四个象限来描述“福大助手”的功能分析：

杀手功能这一列是稳定的加分项，这里我们按下不表。来看外围功能这一列功能，该列描述了一些杀手功能以外的或关键或不关键的功能。在很久之前，我就听到同学们说过“福大助手”的“一键评议”功能苹果可以用，安卓不可以用，这导致我很晚才下载它，甚至在前两天还有同学和我说“福大助手对苹果十分友好，但在安卓端感觉可有可无”，我+1。
除了这个方法，《构建之法》上还提出的另一种方法，将软件的功能分为惊喜，核心功能和基本功能或属性。“福大助手”的惊喜包括了：一键评议，课程表导出到日历，提醒成绩正在更新，主题设置和自定义侧边栏等等的功能，核心功能是课程表和成绩查询，基本功能可以不谈。这样看来“福大助手”还是不错的。
再来看“福大助手”的宣传方面，这款APP我是在第一学期期末要看成绩时从舍友口中听到的，单单从这一点就能体现出很多问题：1.“福大助手”是通过同学之间好的评价来进行宣传的，2.这个学期前面的时间我没用过福大助手，之前一直使用教务通，3.当我听到他很方便时，安卓端却不能使用“一键评议”（大一时，现在可以用了）。这三点体现出了，宣传渠道匮乏，前期流失了大量的用户，即使能100%地保留下ios端的用户，安卓用户少之又少也是个问题，毕竟你不能忽略安卓系统庞大的使用群体。
总结一下，“福大助手”优秀的地方很优秀，但是很多功能安卓端的不适用和后期宣传力度不大给了它致命一击。如果我来做PM，我会注意这两个方面，在研发的安排阶段将核心功能的各个移动端适用这一重要的地方强调一下，并且在后期宣传时加大力度，这一点抽屉就做得很好，可以向他学习一下。
最后偷偷说一句，我比较喜欢很多人一起吃饭，如果我做了PM，估计会经常和团队一起出来吃饭，交流感情。

如果你的团队只有5个人，4个月的时间，你作为项目经理，应该如何配置角色（开发，测试，美工等等）？

在需求分析和软件开发准备阶段大家要一起参与进来，尽快完成自己的任务，提前研发开始的时间。
研发阶段，1个人负责Android前端，1个人负责Android后端，1个人负责ios前端，1个人负责ios后端，1个人负责美工。
后期测试阶段，Android端可以和ios端互换软件进行测试工作。
宣传阶段大家也是要一起参与，我认为这部分工作大家都是一样的所以大家要一起来做。

描述你的团队在16个周期间每周都要做什么，才能在第16周如期发布软件，大小里程碑绩点设定。

假设我的团队都具有一定的开发基础和开发经验，那么我会这么安排我的团队：

项目发布后，有没有考虑过项目该怎么部署才能满足需求。依据附录图（某校教务处系统的部署）作为参考，分析16周后你所完成的项目上线需要哪些配套设备(服务器、带宽、数据库需求数量与配置) 。

基本的服务器框架都是C/S结构的，请求和相应流程是这样的：

现通过增设以下设备以达到优化功能：

• 中间层DLA：
  DLA采用缓冲队列和连接池设计。 客户端大并发请求到来时，DAL设计缓冲队列，存储等待的请求，并且DAL中设计数据库连接池，当数据库连接池中有空闲连接，那么从缓冲队列中取出一个请求处理，以此类推。这种做法有效的降低了服务器的压力，保证请求被缓存。

• 缓存数据库：
  将常用的数据加载入缓存，
  有请求到来时，应用服务器先从缓存中获取数据，如果缓存中有数据，那么不需要访问数据库，如果缓存中没有，在访问数据库取出数据，并更新缓存。如此一来处理效率不受限于数据库的并发数。增设的备份redis数据库则能够实现数据的备份和持久化。

• 在单独应用服务器上部署缓存服务器：
  将缓存
  部署在单独服务器上，通过访问该缓存服务器，方便各个应用服务器访问彼此缓存。

• 将关系型数据库实现读写分离和负载均衡：
  当有大量复杂的写操作数据库时，读写分离可以保证读数据库操作不被阻塞；由于数据库读操作会比写操作多，那么可以对数据库执行负载均衡。主流数据库都有replication机制，采用replication机制可以实现负载均衡。中间层的写数据库操作投递到主数据库中，读操作从读数据库中读取，当主数据库中数据被修改后，数据库采用replication机制将数据同步给备份服务器。

• 任务服务器：
  单独设计一个任务服务器，让应用服务器主动去请求任务服务器，主动获取任务处理，如果应用服务器处于忙碌状态就不需要请求新的任务，空闲的应用服务器会去请求任务服务器中的任务，这是最合理的负载均衡。如果所有应用服务器都处于忙碌状态，
  那么任务服务器将任务缓存至自己的任务队列，当应用服务器空闲时会来取任务。这样便对应用服务器实现了负载均衡

• 备用任务服务器：
  设置多台任务服务器，并且实现failover机制，多台任务服务器之间实现心跳，如果检测不到对方心跳，则使自己成为主任务服务器，以此任务服务器出现故障。

优化后框架图如下：

最终设备如下：

带宽计算方法是这样的：
每秒钟下载文件的字节数×8/0.7 = 宽带的速率
流量和带宽的换算是，带宽：流量=1:150
假设2400人同时在线，2400人并发同时操作，每个人的要恢复30KB的备忘录数据，那么合算成带宽就是：2400/(30KB*8)=10Mb

因为预计在线人数较多以及云备份的使用频率频繁，所以选择4核8G服务器。

第四部分 增量开发设计

既然你对产品有这么多的意见和建议，请就你认为产品的可提升功能、新增需求点做出增量开发设计，要求：

优化/新增功能点的原型界面

优化部分：

• 课程查询
  提供查询其他专业开课情况的功能，用户在查询到感兴趣的课程的情况下可以使用课程表内现有的添加课程功能将课程添加到课程表。
• 课程导出到日历提示
  点击导出到日历功能后出现弹窗显示：在设置-清除数据里可撤销导出操作。
• 学业分析（ios版本有，Android版本没有）
  提供可视化的绩点排名变化、修习学分统计、修习情况的分析。
• 校历查看（ios版本有，Android版本没有）
  查看活动安排、假期安排等情况。

创新部分：

• 同学帮
  实名制的同学互动平台。分成学习、生活两部分。学习部分主要用来发布一些面向用户的个人学习信息。用户可以在这个板块发布找研友、有偿考研信息分享交流、有偿期末答疑解惑等消息。生活部分主要用来发布一些生活上的便利互助信息，如打车拼单、闲置物品转让出售等。

• 在线签到点名
  最小以班级为单位在该板块上发布签到活动，用户在指定地点附近输入特定信息可进行签到签退点名。

• 教师信息查询
  提供教师的个人资料，授课情况，挂科率高分率、学生评价。

• 导出到日历提示
  很多人点击课程导出到日历功能往往只是为了测试这个功能的实现效果如何，但是导出到日历这个功能实际效果并不是很好（如图，不仅不能使课程全部清晰地展示在日历上而且会影响日历的观感，甚至可能导致一些重要事件被盖住）。而且撤销这个操作的行为按键过于隐，用户不易找到。
  但不可否认确实有部分用户会使用课程导出到日历这个功能，因此我们做出的优化手段是在后出现弹窗显示：在设置-清除数据里可撤销导出操作。

基本实现思路

• 课程查询、导出到日历提示、学业分析、教师信息查询、校历查看等功能在可在原有功能基础上进行开发和优化。数据来自该软件原有数据库。
  教师信息查询功能，由于西二在线公众号之前有提供过这个功能，福大助手这个app也是由西二在线进行开发的，只需要把数据合并到福大助手上即可。
• 在线点名签到功能需要调用用户的地点上传服务器进行签到签退。
• 同学帮功能开发难度较大，相较于福大助手之前的功能来说，服务器负载增加，可能需要调用已有的聊天api进行开发。

优化/新增功能点与原有产品如何接入

• 课程查询、导出到日历提示、学业分析、教师信息查询、教师信息查询功能、在线点名签到功能等功能在可在短时间内完成，则在新版本发布时就可进行更新。
• 同学帮功能需要一定时间的开发，可单独更新发布。

第五部分 答辩总结

贡献度及分工

姓名	比例
家伟	11%
卉卉	10%
宇恒	10%
政演	9.5%
丹丹	9%
鸿杰	8%
一好	7%
恺琳	6.5%
青元	9%
家灿	9.5%
绪佩	10.5%

问题回答

第一组

Q1：演讲缺乏对专业测评工具的介绍，可以介绍一下你们所使用的应用在线测评工具吗？
答：感谢提问！我们使用的测评工具是Testin云测试。Testin云测试是一个真机自动化云测试服务平台,可实现自定义终端进行批量自动化兼容适配测试以及功能、性能、稳定性测试。我们在平台上传了福大助手的apk文件获得了测试报告数据。

Q2：项目测评是否有发布问卷调查，对应用进行一个大基数的调查？

答：感谢提问！我们没有采取发布问卷调查的形式。我们认为问卷调查的形式对我们的评测帮助并不大，一是没想到什么有针对性的问题，二是对一个软件的评测和分析是需要对软件细致地测试得出的，大多数同学不会通过日常的操作找到什么我们测试人员没有发现的bug，三是我们通过线下了解，同学们的需求比较单一，对福大助手现有的功能都比较满意，提出的如校园卡充值等需求对非技术性的要求较高，不在我们考虑的增量开发范围内。当然，以上仅代表我们组的观点。贵组的问卷调查分析结果是一个亮点，说明贵组的问卷问题和结果分析做的很好，我们会多多学习。

Q3：项目的增量开发难度如何，以小组实力需要多久的开发时间？
答：感谢提问！增量开发的主要功能同学帮涉及到实时交互的功能，难度较高，以小组实力初步估计要两个月左右的时间。

第二组
Q1：是否也有使用问卷调查的形式呢？
答:感谢提问!我们组这次的测试报告中没有考虑到使用问卷调查的形式，因为感觉大家都是轻使用这款App只会使用一些基础的功能，所以不必采用问卷调查的形式。当然，如果测试报告的形式更有利于我们进行测试的话，我们之后会考虑采用这种方式来进行测试工作。

Q2：假如由贵小组来开发该软件，觉得需要多久呢？
答:感谢提问!由我们组来进行开发的话，由于大家都是在校大学生，且经验不甚丰富，所以我认为助教学姐给出的四个月是个不错的建议。

Q3：具体的评测方法是什么？
答:感谢提问!我们组的测试同学使用的是名为“testin”的网站，该网站只用上传APK文件，就会给出关于该软件的测试报告，若有兴趣，欢迎讨论！

第三组
Q1：在测试的过程中并未提及对应的软件产品的版本号，这就使得bug没有针对性，有些或许并不是所有用户目前所使用的版本都潜在的问题，存在指向不明的情况
答：感谢提问！我们确实没有填，下次注意。但bug是只要一个设备存在，就需要去修改。

Q2：虽然有着详细的测试数据，但并没有给出一定的解释性说明，这造成虽然堆有大量数据但大众很难去理解其所代表的含义，可以挂出你们对于数据的解读吗？
答：感谢提问！其实数据解读我们在测试文档里面有给出来，如果你们还是觉得不是很能理解，可以看我们的详细excel文档。

3：指出的分析大都和数据的安全性相关，能否就你们所目前所指出的安全性给福大助手app提出具体的一揽子解决方案呢？
答：感谢提问！我们也很想提供一揽子解决方案，但确实做不到。

第四组
Q1：测试报告及ppt中均有错别字，为什么没有认真审核呢？
答：感谢提问！对于PPT数字“5”和“五”不统一的问题深感抱歉，由于疏忽影响观看美感。我们下次会注意的。对于测试报告中存在错别字我们团队没有发现，希望可以更明确的指出错误之处方便我们做出修改。

Q2：测试报告没有上传pdf文件，下次能否考虑上传pdf文件呢？毕竟pdf文件不会因为打开软件的不同呈现不同。
答：感谢提问！对于我们没有上传pdf文件给你们带来的不便表示抱歉，我们下次会尽量考虑到大家阅读的友好型做出改进。但是这次作业中也没有明确要求为pdf文件，所以还请谅解。

3：用户采访仅放了三张图，是否不够有说服力呢？毕竟图中部分同学神似团队成员呢？
答：感谢提问！我们的采访是线下面对面采访，虽只放置三张图片但并非代表只采访了三个对象。这在PPT演示过程中已有陈述是抽取三个代表性对象进行展示。而相较于您方放置的一个线下采访短视频是否我们就可以等价的认为您方说服力也不够强呢？对于“图中神似团队成员”的问题，我们团队中就有一半的成员在之前为使用过福大助手。首先，对象已经是属于我们的采访对象范围；其次，我们图中确实存在一位团队成员，但她便是我们挑选出来的代表性对象，我们认为这并没有什么不妥。最后，如果您方认为说服力不够，我们很乐意看到您方所谓比较有说服力的采访数据和证据。

第五组
Q1：测评可以加入问卷调查的，了解下大家对这个软件的认识，因为我发现其实还是很多人不知道的。
答：感谢提问！这是一个很棒的建议！之后我们会多考虑问卷的。

Q2：其实我觉得福大助手在响应时间方面并不是很好，很多东西都半天出不来，也不知道是不是手机问题。
答：感谢提问！其实我们团队也有类似的感觉，不过似乎易班及福大教务通等一众教务类软件都具有这些毛病，或许和服务器也有一定关系。

Q3：PPT一共有四页给福大助手来了一脚，虽然这APP确实很多地方有问题，但还是别踢了，都肿了。（滑稽）
答：感谢提问！柯大魔王要求如此，一人一脚也是无奈之举。（莫非柯老板是西二在线幕后股东？）

第七组
1：你们的测试看起来非常有料，可以具体分享一下是怎么测试的嘛？
答：感谢提问！测试的过程虽然是我们组的核心机密，但是看在我们小组之间的关系非常不错。我们做的测试主要是黑盒测试，除此之外我们还使用了testin，上传apk文件，他们提供了很多款机型做测试，同时也给出测试的方式，性能测试、安全测试和兼容性测试等。不过一个账户只能免费使用一次软件测试。

Q2：你们的增量开发中有“同学帮”，可以具体的介绍一下同学帮是干什么的嘛？可以实现什么？
答:感谢提问！同学帮的功能：实名制的同学互动平台。分成学习、生活两部分。学习部分主要用来发布一些面向用户的个人学习信息。用户可以在这个板块发布找研友、有偿考研信息分享交流、有偿期末答疑解惑等消息。生活部分主要用来发布一些生活上的便利互助信息，如打车拼单、闲置物品转让出售等。我们觉得这个功能能够提供一个很好的校内交流氛围。

Q3：你们认为增量开发难度如何？
答：感谢提问！增量开发的难度视内容而定吧，要是您们指的是“同学帮”功能的话，开发上我觉得是有一定的难度，毕竟功能比较繁杂，不过物品转让在ios上已经有做尝试；对于学习部分，开发难度上类似于一个在线聊天系统，难度应该也不大。

第八组
Q1：对于增量设计中的在线点名功能认为是否有必要加这个？是不是加剧代签之类的情况？
答：感谢提问！本组觉得在线点名功能是可以扩展的功能，至于是否会加剧代签之类的情况，本组觉得教务处账号涉及个人隐私太多，大部分同学可能都不愿意为了签到借给他人。

Q2：可以抽取一部分的思维导图或者逻辑框图展示在ppt中，ppt中好像没有体现。
答：感谢提问！本组认为把思维导图或者逻辑框图放在ppt中没有很大的意义，因为这些图如果放在ppt中很难让同学们看清。

Q3：产品分析感觉这部分内容有点少了。
答：感谢提问！下次会在这方面有所改进。

评分结果

组号	其他组对本组的评分	本组对其他组的评分
1	78	80
2	81	76
3	77	71
4	76	69
5	86	78
6	85	85
7	82	71
8	84	80
平均	81	—

评审表

第六部分 个人部分

个人PSP

PSP2.1	header 2	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	50	30
· Estimate	·估计这个任务需要多少时间	20	30
Development	开发	150	120
· Analysis	需求分析（包括学习新技术）	60	60
· Design Spec	· 生成设计文档	0	0
· Design Review	· 设计复审	0	0
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	80	50
· Coding	· 具体编码	10	20
· Code Review	· 代码复审	0	0
· Test	·测试（自我测试，修改代码，提交修改）	0	0
Reporting	报告	10	10
· Test Repor	· 测试报告	0	0
· Size Measurement	· 计算工作量	0	0
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	20	20

|合计||300|350

个人学习进度条

第十一周	新增代码（行）	累计代码（行）	本周学习耗时（小时）	累计学习耗时（小时）	重要成长
1	100	100	5	5	复习C++
2	200	300	20	25	C++熟悉，对文件读取分析方法
3	0	300	7	32	Axure rp 8使用 熟悉NABCD模型
4	300	600	44	76	使用C++编写爬虫程序
5	0	600	15	91	详细了解需求规格说明书以及接口文档书写
6	0	600	22	113	与团队一起进行需求报告的书写
7	600	1200	11	124	学习如何调用百度语音API，懂得AS基础使用方法和构建APP的基础方法
8	700	1900	61	187	完善百度语音Api调用，实现简易悬浮窗
9	50	1950	12	199	实现悬浮窗口细节功能

测试报告

测试文档

测试ppt

评审表