实践课：i至诚app案例分析---江洁兰

这个作业属于哪个课程	至诚软工实践F班
这个作业要求在哪里	作业要求
这个作业的目标	分析产品软件，找出其中的问题并进行分析，提高对产品软件bug方面的认识
学号	212106715

第一部分 找Bug

Bug发生时的测试环境

  操作系统：HarmonyOs2.0.0,手机：荣耀9X
  bug程度划分

星星数	严重程度
⭐⭐⭐⭐⭐	致命
⭐⭐⭐⭐	严重
⭐⭐⭐	一般
⭐	轻微

Bug具体情况描述

1. 健康日报填报时间和提交时间有延迟

可复现性：必然发生，bug程度：⭐⭐⭐

2.进校申请提交后找不到更改申请信息的地方，如果提交的申请信息有错，或者没有得到辅导员同意，只能撤回或者终止后重新提交，不能修改，很不方便。

可复现性：必然发生，bug程度：⭐⭐⭐⭐

3.校园一卡通-离线码，点进去并没有离线码

可复现性：必然发生，bug程度：⭐⭐

4.办公管理-考核系统-页面跳转失败

可复现性：必然发生，bug程度：⭐⭐

5.安全设置-手机号绑定和邮箱绑定，只能输入四位字符，无法完成绑定

可复现性：必然发生，bug程度：⭐⭐⭐⭐

6.重置密码的时候点右边的眼睛，密码还是看得到，重置密码后不需要重新登录，自己退出登录后再登录才需要输入新密码

可复现性：必然发生，bug程度：⭐⭐⭐⭐

Bug分析

可能成因

  开发人员疏忽大意，测试工作做得不完善，没有反馈功能，用户在使用过程中发现bug后无法反馈给维护人员，维护人员不能及时意识到需要完善。

严重性

  app展示的功能没有完全实现，存在功能缺陷，存在用户体验很不好的方面。

改进建议

  没有实现的功能都实现，增加反馈功能，以便能及时获取用户反馈，进一步改善app。

第二部分 功能分析

根据软件已有的功能，评估其做到这个程度大约需要多少时间？(例如：团队人数6人左右，计算机大学毕业生，并有专业UI支持)。

阶段	所花时间
需求分析	2周
程序设计	2周
编码	14周
测试	3周

分析这个软件目前的优劣（和微信端的“至诚教务助手”相比），哪个更实用？（必答）

  我觉得该软件的功能没有完全实现，用户体验感不高，至诚教务助手只需关注公众号，无需再下一个app，查课表、查成绩等都比较便捷，所以我认为至诚教务助手更实用。

从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面（具体建议）。

  软件测试方面，测试是对软件功能实现的检测，也是对软件整体部分的检测，建议尽可能在系统安全、功能实现、用户体验等其他对软件进行全面的测试，将测试出来的问题及时解决。

你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？

  开发人员粗心大意，可能是有意不修复，以及测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试。

第三部分 建议和规划

市场现状

目前市场上是否有其他类似功能的产品、竞品？

  功能相似的产品：校园专属app，竞品：乐云一卡通，校园E码通，易校园

上述产品的定位、优势与劣势在哪里？

  定位：为在校生服务
  优势：有app和微信公众号、支付宝等多个平台，满足在校生在校使用需求
  劣势：局限于校园生活，在校生毕业后就不需要了

上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？

  校园专属的产品是相对独立的，其他校园类软件产品互为竞争关系

市场与产品生态

产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？

  用户群体相同，用户需求也接近。有

产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？

  存在竞争关系。有

产品规划

你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。

  新功能：校园导航，帮助新生了解所在位置，指引新生去到目的地。
  原因：对不熟悉校园的新生来说，具有实用性。新生刚入学，对校园环境不了解，虽然说会有校园地图提供给新生，有时候地图表达的可能不够清楚，更有可能有新生看不懂校园地图又羞于问路。
  创新点：地图导航和校园app结合

如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。

角色配置：两名名开发，两名测试，一名美工，一名架构师

请为你的团队设计16个周期每周的详细规划。

  详细规划

时间	工作内容
第一周——第二周	做调研，了解用户使用该产品过程中存在的不足之处，以及用户希望改进的方面
第三周——第四周	两名测试对现有版本进行测试，生成测试文档
第五周——第七周	架构师确定改进方案
第八周——第十二周	编码实现改进
第十三周——第十四周	测试，且提交测试后的修改
第十五周	邀请部分用户体验
第十六周	最后完善