戴焕曾---实践课：案例分析

这个作业属于哪个课程	至诚软工实践F班
这个作业要求在哪里	实践课：案例分析
这个作业的目标	从多角度，多方面进行正确的案例分析
学号	212106706

第一部分 找Bug（黑白盒测试）

Bug发生时的测试环境

• 手机操作系统版本ios14.6
• i至诚版本3.2.8.80430（202111081003）

Bug的量化标准

• 一星：界面排版错误，文字缺失等等
• 二星：严重界面错误，影响次要功能不影响主功能
• 三星：功能缺失错误
• 四星：信息安全性错误，包括信息可靠性错误
• 五星：程序崩溃错误

Bug的可复现性及具体复现步骤

• 复现性：必然发生
• 测试次数：10次
• 发生次数：10次

Bug具体情况描述

• Bug1:每日健康填报中的目前所在位置可随意修改，不是根据目前定位来获取位置，不仅如此，地址的组成也不符合逻辑。
  

• Bug2：每日健康填报的填报时间不可修改，但与正确时间不一致。
  

• Bug3：学生返校申请，在申请后没办法及时知道自己是否提交了，在我之前要返校的时候就不清楚自己到底提交没有，反复申请了好几次。

• Bug4：校园一卡通的离线码点进去报服务错误。
  

• Bug5：在校园一卡通界面中有返回按钮，顶部也有一个返回按钮，在点击多个校园一卡通内部功能后，点击上面的返回就不是退出校园一卡通了，而是返回刚才点击的页面，可以说两个按钮功能重复，并会发生冲突。
  

• Bug6：i至诚的入馆教育点进去报错要加载的程序未知
  

Bug分析

• Bug的可能成因：

1.  每日健康填报的Bug可能是当初疫情来势汹汹，开发人员紧急发布此功能让学校能够使用填报功能，之后开发人员看到这个功能可以应付使用，就没有进行继续的完善。
2.  在一卡通页面的返回按钮和顶部返回按钮可能是开发人员当时在开发时将这个功能外包给别的公司开发或者自己分组开发，因此一卡通自身的按钮保留下来了，在正式投入使用时并未完善界面优化。
3.  返校申请无法及时看到申请的历史，属于功能缺失，在该申请得到回应后才能看到，开发人员并未考虑到当前申请未反馈消息时无法准时的获知自己是否发送了申请
4.  离线码和入馆教育有可能是开发人员在当时开发后发现用的人少暂时关闭起来了，但是没考虑到一些功能在之后确实有人会用到

• Bug的严重性：

1.  每日健康填报的Bug属于安全性的错误，所以属于四星级错误。健康填报需要保证的就是信息的准确性和时效性，地址填写不验证，有何安全可言，时间不准确，有何时可言
2.  一卡通的页面返回按钮与顶部返回按钮冲突属于系统功能和用户体验的方面，因此属于二星。用户在使用过程中会因为这种Bug影响体验感
3.  返校申请无法及时查看申请历史，还有离线码和入馆教育，属于三星指标的Bug，功能缺失。

• 对于Bug的预期及改进建议：

1.  每日健康填报的Bug应该定位的逻辑是准确的，并且时间也应该是准确的，修复这个bug需要修改后端代码，让时间获取获取准确，地址的逻辑准确。
2.  一卡通的页面原本应该是只要一个返回按钮即可，这属于ui界面设计方面，若要保持两个按钮，顶部按钮的功能应该与下面的按钮功能分开，顶部按钮按一下即可退出一卡通，下面的按钮则作为返回上一个页面。若修复为一个按钮，那么可以两者功能结合。
3.  流程申请应该在原本有一个接口能看到我申请的历史，这需要ui和后端同时修复，在界面上添加一个申请历史的按钮，后端的代码传送你当前申请的所有历史。
4.  离线码以及入馆教育原本应该是点进去有内容的，后端需要修复，将接口恢复，或者引入新的接口让内容能准确展示。

第二部分 功能分析

根据软件已有的功能，评估其做到这个程度大约需要多少时间？

团队人数十左右，计算机大学毕业，并有专业Ui支持

阶段	周数
可行性研究阶段	2周
需求分析阶段	3周
软件设计阶段	5周
软件测试阶段	3周
软件交付阶段	3周

分析这个软件目前的优劣

优势：
1.功能多，至诚教务助手只有教务相关功能，查成绩或者看课表之类的，i至诚有健康填报，开学的迎新准备，选宿舍，缴费等等
2.界面美观，i至诚是独立的一款软件，因此界面设计灵活，至诚教务助手依托于微信端，界面受限，并且界面也是传统界面样式，过时了，课程表在手机上显示会超出屏幕
劣势：
1.i至诚的教务相关功能没有微信端的至诚教务助手那么详细，有一些功能缺失还是需要到至诚教务助手使用。
2.i至诚的维护和修复比至诚教务助手来的麻烦，因为i至诚修复bug需要多方面进行修复，还要对软件进行新的发布更新。

从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面

这个软件团队需要在需求分析阶段进行提高，因为许多界面的设计和功能是由于未考虑使用者使用情况而造成的bug，当然信息安全性也跟需求分析阶段有一定的联系，所以重点来说，需求分析阶段需要提高。

你在第一部分发现的bug，为何软件团队不能在发布前修复？：

我觉得有以下几个原因：
对用户需求掌握不好；具体的设计质量不高；测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试；

第三部分 建议和规划

这个软件有很多可以提高的部分，如果你是新上任的项目经理，你将如何提高从而使其更富竞争力？请针对以下问题进行思考：

市场现状

• 目前市场上是否有其他类似功能的产品、竞品？
  市场上其他学校也有自己开发app来给学生使用
• 上述产品的定位、优势与劣势在哪里？
  定位：面对学生老师群体，辅助学校管理老师学生相关事务
  优势：便捷性，学校通过app可以在线上完成很多任务
  劣势：没有像至诚教务助手那样有充分的教务相关功能，有的学校在自己特定的app没有体现自己学校的特色。
• 上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？
  因为是不同学校之间的app，因此有着良性竞争关系，每个学校的app之间想做的比对方更好，都是为了让学校师生更好的使用，大家可以相互借鉴，相互竞争。
  与其他任何学校的app都可以是竞品关系。
  目前来讲，有些学校并不在意这种竞品关系，他们只满足于功能够用，不考虑优化与功能增加，有些学校会与时俱进，充分考虑师生需求，定期更新维护。

市场与产品生态

• 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
  产品的用户群体之间都存在着老师和学生的师生关系。
  无法利用其相互作用二次构成特定用户生态。

产品规划

• 我要在当前软件上设计教务系统功能。因为目前i至诚上的功能主要缺少教务相关功能。学生们有的不喜欢微信绑定那么多东西，他们也能更方便的在i至诚上直接使用教务相关功能，省的微信再去搜索再用。
• 我会招聘：项目经理，产品经理，UI设计师，开发工程师，测试工程师，运维工程师
• 设计详细规划

开发周期	计划	开发周期	计划
第一周	确定软件开发目标	第九周	软件编码
第二周	确定软件开发可行性	第十周	软件编码
第三周	需求分析阶段	第十一周	软件测试
第四周	需求分析阶段	第十二周	软件测试
第五周	需求分析阶段	第十三周	软件测试
第六周	软件框架设计	第十四周	软件试运行
第七周	软件编码	第十五周	软件改进
第八周	软件编码	第十六周	软件交付