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

032002124林日臻 2024-10-08 21:31:34

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

Tips

本次作业截止时间为：2024年10月15日 23：59
注：博客发布后需要审核，请同学们记得提前发布博客，避免影响作业提交。

O、前言

很多同学有疑惑：

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

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

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

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

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

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

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

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

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

注：请先仔细阅读本次作业的要求，根据要求完成自己的思考，在完成作业后可以选择参阅，看看自己是否有可以提升的地方。前几次作业有出现模仿去年博客的情况，一旦助教发现将进行扣分处理，请同学们 独立完成作业，严禁一切形式的模仿和抄袭。

一、作业要求

1、本学期供分析的产品

作为一个 IT 行业的学生或从业者，每天都在使用各种各样的软件，你能否给这些软件写一个评测博客呢？
请同学们自行在以下四个网站中选择两个网站进行对比测试。

2、博客具体要求

第一部分调研，评测

(参考知识点：软件的 bug，功能评测，黑箱测试，第8章用户调研，12章软件的用户体验)

体验两个产品的功能，找出至少1个较高质量的功能性bug。

（1）使用体验

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

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

Bug发生时的测试环境
- 例如使用的操作系统环境和版本，浏览器环境和版本，以及发生的时间段及前因后果等
- 该部分简述为主，但是需要说清楚基本环境和条件
Bug的可复现性及具体复现步骤
- 对于可复现性，需要说明是必然发生，还是偶尔发生，还是满足某些特定条件下会发生。
  - 对于偶尔发生的Bug，须做多次测试并说明发生频率（例如300次测试中发生了45次）
  - 对于满足特定条件下发生的Bug，须详细且精准描述发生条件
  - 对于情况较为复杂的可复现性情况，须绘制必要的图表进行详细数据分析（例如频率分布直方图，对于多因素的分析可以使用三维图，甚至使用SPSS等软件进行分析）
对于复现步骤，需要按照流程顺序，或者绘制流程图进行详细描述，并确保这一情况可以被复现且符合上述全部描述。
Bug具体情况描述
- 描述出现了什么样的Bug，具体现象是什么
- 以配图的方式展示这一Bug，并对配图进行必要的说明
- 该部分的描述务必做到自圆其说，即需要通过你的说明，证明这一情况确实存在，且确实是一个 Bug 而不是 Feature 或者乌龙等情况。
Bug分析
- Bug的可能成因，需要作出足以自圆其说的分析，并可以类比与之相似的情况或个人项目经历
- Bug的严重性
  - 需要从系统功能、安全性以及用户体验这三个或更多维度上进行分析
  - 给出一个可量化的指标（比如星数），并说明理由
  - 此外，建议在全部 Bug 描述开始前，详细说明各个指标的量化标准，以便后续的说明和探讨。（例如五颗星是致命性系统故障、致命性安全性漏洞、用户体验严重影响；四颗星是严重系统故障、服务器鉴权漏洞或重要数据泄露、用户体验较差等）言之有理即可。
- 对于Bug的预期及改进建议
  - 需要结合之前对Bug的分析和严重性展开叙述
  - 需要说清楚这个地方应该是什么样的，以及应该如何设计可以做到这一点
  - 对Bug的一系列其他分析，可以自由发挥

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

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

请选择一个结论。

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

第二部分分析

(参考知识点：8.6节对工作的估计，和14.1节软件工程的质量)

从书上我们可以得知：

程序 = 算法 + 数据结构
软件 = 程序 + 软件工程（软件服务还有数据，内容的因素）
软件企业 = 软件 + 商业模式

那么请你：

使用此软件的所有功能，估计这个软件/网站/服务做到这个程度大约需要多少时间(团队人数6人左右，计算机大学毕业生，并有专业UI支持)。
分析这个软件目前的优劣(和类似软件相比)，这个产品的质量在同类产品中估计名列第几？
从各方面的问题，推理出这个软件团队在软件工程方面可以提高的一个重要方面(具体建议)。
你在第一部分发现的bug，为何软件团队不能在发布前修复？他们是不知道，还是有意不修复？你觉得是什么原因？可以从下面的可能性中选取几个：
- 对用户需求掌握不好
- 具体的设计质量不高
- 开发人员粗心大意
- 测试把关不严，敷衍了事，没有注意在特殊的配置或环境下测试
- 其他
思考团队在哪一个层次还有问题？为何职业的软件团队还有这些问题？这个软件团队在软件工程方面还可以如何提高？可以把自己想问软件团队的问题都列出来，也许就能得到团队的亲自解答！

第三部分建议和规划

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

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

市场概况
- 首先市场有多大？
- 其次直接的用户有多少？潜在的用户又有多少？
市场现状
- 目前市场上有什么样的产品了？
- 上述产品的定位、优势与劣势在哪里？
- 上述产品之间呈现什么样的关系，哪些为竞品关系？以及竞争中的各方态势如何？
- 这个领域正处于 (萌芽 / 成长 / 风口 / 平台 / 下降)阶段？
市场与产品生态
- 这个产品的核心用户群是什么样的人？典型用户是什么样的？学历，年龄，专业，爱好，收入，表面需求，潜在需求都是什么？
- 产品的用户群体之间是否存在一定的关系？是否有利用其相互作用二次构成特定用户生态的可能性？
- 产品的子产品，以及其他相关产品之间是否存在一定的关系？是否有利用各个产品特性之间的相互关系二次构成产品生态的可能性？
产品规划
- 你要在当前软件的基础上设计什么样的新功能？为何要做这个功能，而不是其他功能？为什么用户会用你的产品/功能？你的创新点在哪里？可以用NABCD分析。
- 如果你是项目经理，可以招聘6个人，并且有4个月的时间，你认为应该如何配置角色(开发，测试，美工等等) 才能在第16周如期发布软件的改进版本，并取得预想中的成绩。
- 请为你的团队设计16个周期每周的详细规划。

二、作业评分规则

本次作业满分100分：

第一部分（40‘）：

【覆盖课程目标4】↓

（20’）两个软件的体验描述
- （10‘）基本功能介绍和使用
- （5‘）优缺点分析
- （5‘）改进意见
（5‘）两个软件定性和定量的结论
（5‘）两个软件中，至少1个高质量的功能性Bug的描述**
（5‘）两个软件中，其他高质量的功能性Bug的描述**

【覆盖课程目标5】↓

（5‘）用户采访

第二部分（20‘）：

【覆盖课程目标4】↓

（5‘）同类产品对比和排名
（5‘）软件工程方面的建议
（5‘） BUG存在的原因分析

【覆盖课程目标5】↓

（5‘）说明你对产品开发时间的预估、理由

第三部分（40‘）：

【覆盖课程目标4】↓

（15‘）产品规划
- （6‘）功能以及NABCD分析
- （4‘）角色配置
- （5‘） 16周的详细计划

【覆盖课程目标5】↓

（25‘）对于市场概况、市场现状以及市场与产品生态部分，回答至少三分之二的问题

三、作业格式以及提交规则

1、为了方便阅读以及助教评分，请大家在博客开头给出博文目录，作为内容的索引

请确认目录可以 正确跳转！
请务必包含以下大标题，标题含义相近即可，你可以个性化你自己的大标题，并添加下属的小标题：
- 第一部分调研，评测
  - 软件产品1
    - 体验
    - BUG
    - 结论
  - 软件产品2
    - 体验
    - BUG
    - 结论
- 第二部分分析
  - 开发时间估计
  - 同类产品对比排名
  - 软件工程方面的建议
  - BUG存在的原因分析
- 第三部分建议和规划
  - 市场概况
  - 市场现状
  - 市场与产品生态
  - 产品规划

2、为了方便其他学校的老师或者助教了解课程实况，请大家在作业开头添加作业的基本信息：（必做）

这个作业属于哪个课程	<班级的链接>
这个作业要求在哪里	<作业要求的链接>
这个作业的目标	<写上具体方面>
其他参考文献	...

3、作业提交规则

在deadline前交，分数为实际得分；
- 若帖子发布后在审核（帖子显示404），可以在deadline 之前先于作业页面提交链接，再等待审核通过
- 不接受上传失败、网络原因等补交理由
补交：在deadline 后两天内提交视为补交，分数为实际得分 * 50%；写了但是忘记提交作业和补交扣分一致
缺交：在deadline 之后两天未补交视为博客缺交，分数为0分；
作业抄袭：当助教发现两篇博客文字/图片/代码过于相似时，判定两篇博客都为抄袭，分数都为-100%（注意是倒扣！）

4、注意事项

班级群如果发布相关通知也是作业要求一部分，请及时查看群通知；若需要在群填写相关信息，未能在deadline之前完成填写的，**扣实际得分的50%**；如对作业存在疑问，请在deadline之前三天在班级群提出；若助教对作业要求有修改，会在群内公告，请务必查看并按新的要求完善作业。即使提交了作业，也应该关注班级群中助教的公告！

5、疑惑解疑

若有对题意不清或者有不理解的地方，可在QQ群或微信群中直接提问

...全文