软件工程实践——软件评测

助教_李耕助教 2022-04-04 14:02:41

软件评测

软件评测
O、前言
一、截止时间
二、作业内容
1、本学期供分析的产品
2、博客具体要求
第一部分调研，评测(软件的 bug，功能评测，黑箱测试，第8章用户调研，12章软件的用户体验）
第二部分分析(参考8.6节对工作的估计，和14.1节软件工程的质量)
第三部分建议和规划(参考《构建之法》第8章功能的定位和优先级；第9章项目经理)
3、格式和提交要求
4、评分标准
第一部分：
【覆盖课程目标4】↓
【覆盖课程目标5】↓
第二部分：
【覆盖课程目标4】↓
【覆盖课程目标5】↓
第三部分：
【覆盖课程目标4】↓
【覆盖课程目标5】↓
三、作业提交规则
四、其它规则

O、前言

很多同学有疑惑：

软件工程课是否就是枯燥的理论课？
或者是几个牛人拼命写代码，其他人抱大腿的课？
要不然就是学习一个程序语言，练习某个框架，搞一个职业培训的课？

都不对！软件工程有理论，有实践，更重要的是分析，思辨，总结。在课程中，同学们自己组织团队写一个软件发布，然后分析其中的得失，的确是学习软件工程的一个好方法。这样能根据切身体会来分析，很有价值，但也有可能“身在此山中”，未能看清全局。而且，课程时间有限，我们也不能做很多具体的项目。因此，我们也需要从间接经验中学习，分析。别的项目的成败同样给我们很多启发！

我们生活中很多时候要和软件打交道，大家上课开小差时候玩的手机游戏，背英语单词的手机App，买火车票的网站，互相联系用的微信微博，等等，都是软件，都很值得分析。

你为何成为该软件的用户？
软件背后的团队做对了什么，做错了什么？
软件工程质量如何？
如果你来做，会做得更好么？

通过各种案例分析，评测，思辨，总结，我们就能看到软件工程的原则在实践中的种种体现，学好软件工程，帮助我们在实践中做得更好。

分析什么样的软件也有讲究，这就要说到一个故事：

某国空军为了提高飞机在空战中的存活率，决定加固飞机，但是加固什么地方呢？他们研究空战后飞回基地的飞机，飞机各部分中弹的地方和密度，想以此得出结论。但是专家们忽略了一点，那些被击中要害的飞机，都没有能飞回基地，也没有能够参加这些调查。

幸存者偏差 (Survivorship bias)是一种常见的逻辑谬误，意思是只能看到经过某种筛选而产生的结果，而没有意识到筛选的过程，因此忽略了被筛选掉的关键信息。这东西的别名有很多，比如“沉默的数据”、“死人不会说话”等等。

因此，我们不光要分析那些经历战场的考验而最后"活着出来"而胜利的软件，还要分析那些在战场中被打败，或者伤痕累累，正在挣扎的软件，这样才能全面地了解软件工程的原理在好/坏软件上所起的作用。

有的同学会说：

“我只会看看界面，写不出来...”

那么，可以看看这个只评价界面的分析报告，争取写出类似水平的报告来：如何评价微软的UI设计？

2021年软件评测优秀作业参考：
代码仓库管理系统：至沁, CLH029
IT 问答网站：Fino's Blog, 都不吃大白菜, 小球同学bbu, railgunSE, AAAdmin

以及北航的两份作业作为参考：
Shaun_Yao, VOIDMalkuth's Blog

注：请先仔细阅读本次作业的要求；上述优秀作业分别覆盖了本次作业的第一类产品和第二类产品；对于本次作业的全部要求，都建议你完成自己的思考，在完成作业后可以选择参阅，看看自己是否有可以提升的地方。否则可能先入为主，影响到自己的思考。禁止抄袭。

一、截止时间

本次作业截至时间为2022年4月9日23:00。

二、作业内容

1、本学期供分析的产品

从下面提供的两类候选软件中选择一类，完成后续任务：

一、作为一个 IT 行业的学生或从业者，如果你碰到了问题，你去哪里寻找答案呢？请比较以下 3 个 IT 问答网站并尝试体验提问和回答问题：列出它们具体的优缺点，并说明如果你来主持工作，你会怎么改进。

CSDN开发者互助问答社区_程序员有问必答-CSDN问答
Stack Overflow - Where Developers Learn, Share, & Build Careers
SegmentFault 思否
或者，如果你在测评CSDN社区的过程中遇到瓶颈，可以尤为关注CSDN中的新功能模块【技能树】，并通过复用你的博客里Bug评测等环节中的内容，参与CSDN技能树测评有奖征文。你可以在CSDN APP的“我的”->“我的学习”->“技能树”中打开它；或访问C技能树，在左上角可打开更多技能树。

注：

对于问答网站，用户需求有提问和回答等；可以考虑从多个角度评测。
提问需要遵守相应社区规范（例如Stack Overflow: how to ask，如何写高质量的提问和回答，SegmentFault FAQ），避免无意义的水问题。
有的测试对象除了web端还有移动端，例如CSDN和SegmentFault的移动端都有问答板块，这些也可以成为测试对象
对于Stack Overflow，也可以关注一下其他社区，例如Game Development和Softerware Engineering

二、代码仓库管理系统有很多，他们对于你熟悉的目标用户（中国高校大学生）有什么缺陷和需要改进的地方，并且该如何改进？请上手使用并分析以下 3 个常见的代码仓库：

2、博客具体要求

第一部分调研，评测(软件的 bug，功能评测，黑箱测试，第8章用户调研，12章软件的用户体验）

从两类产品中选择一类，体验同类中三个产品的功能，找出至少1个高质量的功能性bug。

体验

介绍和使用软件: 介绍软件基本功能；使用这个软件的基本功能10–30分钟，并上传使用软件的照片
优缺点分析: 描述使用这个产品的过程，解决了用户的问题么？软件在数据量/界面/功能/准确度上各有什么优缺点？用户体验方面有问题么？
对产品有什么改进意见？
采访另一个用户: 让 TA 也使用这个软件/服务， TA 能上手使用么？有什么明显的困难，软件的开发团队为何没有意识到这些初始用户会碰到的困难？
（请将采访过程以图片和文字的方式记录下来，且要求采访对象为其他软工班级的学生；如果TA也要完成软件评测的作业，要求TA选择的测评对象和你的不一样）
记录请至少包含以下几点：
a. 采访对象的背景，为什么选择这个人采访？TA 的需求是什么？
b. 采访对象实际使用的产品栏目
c. 采访对象使用软件的过程中会遇到的问题和亮点
d. 采访对象觉得从用户体验的角度来说需要改进的地方有哪些？

BUG描述

须用专业的语言描述，其中必须包含以下内容（为方便说明，Bug和改进点在接下来的章节中统称Bug）：

Bug发生时的测试环境
- 例如使用的操作系统环境和版本，浏览器环境和版本，以及发生的时间段及前因后果等
- 该部分简述为主，但是需要说清楚基本环境和条件

Bug的可复现性及具体复现步骤
- 对于可复现性，需要说明是必然发生，还是偶尔发生，还是满足某些特定条件下会发生。
  - 对于偶尔发生的Bug，须做多次测试并说明发生频率（例如300次测试中发生了45次）
  - 对于满足特定条件下发生的Bug，须详细且精准描述发生条件
  - 对于情况较为复杂的可复现性情况，须绘制必要的图表进行详细数据分析（例如频率分布直方图，对于多因素的分析可以使用三维图，甚至使用SPSS等软件进行分析）
- 对于复现步骤，需要按照流程顺序，或者绘制流程图进行详细描述，并确保这一情况可以被复现且符合上述全部描述。

Bug具体情况描述
- 描述出现了什么样的Bug，具体现象是什么
- 以配图的方式展示这一Bug，并对配图进行必要的说明
- 该部分的描述务必做到自圆其说，即需要通过你的说明，证明这一情况确实存在，且确实是一个 Bug 而不是 Feature 或者乌龙等情况。

Bug分析
- Bug的可能成因，需要作出足以自圆其说的分析，并可以类比与之相似的情况或个人项目经历
- Bug的严重性
  - 需要从系统功能、安全性以及用户体验这三个或更多维度上进行分析
  - 给出一个可量化的指标（比如星数），并说明理由
  - 此外，建议在全部 Bug 描述开始前，详细说明各个指标的量化标准，以便后续的说明和探讨。（例如五颗星是致命性系统故障、致命性安全性漏洞、用户体验严重影响；四颗星是严重系统故障、服务器鉴权漏洞或重要数据泄露、用户体验较差等）言之有理即可。
- 对于Bug的预期及改进建议
  - 需要结合之前对Bug的分析和严重性展开叙述
  - 需要说清楚这个地方应该是什么样的，以及应该如何设计可以做到这一点
- 对Bug的一系列其他分析，可以自由发挥

Bug 反馈
- 对于开源软件，如果你已经确定找到的 Bug 可复现，确实不是 Feature 或者乌龙，并且能让其他人也验证该 Bug 的存在，我们非常鼓励你向开发团队提出 issue，请参考这个Github 上的 issue，用简洁准确的语言进行描述。例如：
  - 对于GitHub Desktop，可以在这里提交issue：https://github.com/desktop/desktop
- 对于其他软件，通过官方提供的反馈方式提交你发现的Bug，例如：
  - CSDN：https://ask.csdn.net/questions/7398651
  - GitHub可访问：https://support.github.com/contact/feedback
  - SegmentFault：https://segmentfault.com/0x

结论

经过这么多工作，你一定有充分的理由给这个软件下一个评价：

a) 非常不推荐
b) 不推荐
c) 一般
d) 好，不错
e) 非常推荐

请选择一个结论。

除了定性的结论，是否能有定量的结论（就像最近比较时髦的手机评测那样，跑个分），如何定量地评价一个软件？
请看这个链接，并尝试从多个维度对软件进行定量的测评：http://www.cnblogs.com/xinz/p/3308608.html

注:

对于GitHub和Stack Overflow等对象，找出高质量的功能性Bug可能不是一件容易的事情；因此要求至少从三个测评对象中找到1个高质量的功能性Bug。

博客需要分别描述同类中三个软件的体验、BUG（如果没有找到，说明即可）和结论.

第二部分分析(参考8.6节对工作的估计，和14.1节软件工程的质量)

在书上我们看到：

程序 = 算法 + 数据结构

软件 = 程序 + 软件工程（软件服务还有数据，内容的因素）

软件企业 = 软件 + 商业模式

那么：

使用此软件的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。

分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？

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

你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？可以从下面的可能性中选取几个：

对用户需求掌握不好
具体的设计质量不高
开发人员粗心大意
测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试
其他

第三部分建议和规划(参考《构建之法》第8章功能的定位和优先级；第9章项目经理)

这个软件/网站/服务有很多可以提高的部分，如果你是新上任的项目经理，如何提高从而在竞争中胜出？请针对以下的问题进行思考

市场概况
- 首先市场有多大？
- 其次直接的用户有多少？潜在的用户又有多少？

市场现状
- 目前市场上有什么样的产品了？
- 上述产品的定位、优势与劣势在哪里？
- 上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？

市场与产品生态
- 这个产品的核心用户群是什么样的人？典型用户是什么样的？学历，年龄，专业，爱好，收入，表面需求，潜在需求都是什么？
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
- 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？

产品规划
- 你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新在哪里？可以用NABCD分析。
- 如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。
- 请为你的团队设计16个周期每周的详细规划。

对于市场概况、市场现状以及市场与产品生态部分，选择回答至少三分之二的问题，做到有充足的证据支持并自圆其说；对于产品规划部分，请做好完整的回答并阐述理由。