2023软工第二次作业-软件案例分析-CSDN博客

本文链接：https://blog.csdn.net/li__jh/article/details/129194273

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程
这个作业的要求在哪里	个人作业-软件案例分析
我在这个课程的目标是	学习软件工程的理论，亲自实践参与软件工程开发全流程
这个作业在哪个具体方面帮助我实现目标	分析其他软件的功能，了解软件评测和市场需求

第一部分调研，评测

软件评测

本次作业为对第二个选题——CSDN APP的“微社区 / 动态 / Blink”功能的分析调研。

软件基本功能

使用的app版本为5.14.2。在此版本下，通过首页-动态进入到CSDN的微社区。其中总共包含如下五个板块：

热门：查看当前热门的动态。
最新：最新发布的动态。
投票：发布内容中包含投票的动态。
同城：与当前定位处于同一城市的动态。
我的：用户自己发布的动态。

用户自己也可以发布动态。发布动态时，可以选择动态的标签，还可以选择身处的地区，动态内容中可以选择添加如下附件之一：多张图片、单个视频、单条链接。动态中也可以专门@某人，提示他来看你的动态。

查看热门动态：
请添加图片描述
查看帖子的评论：
在这里插入图片描述
投票功能：

同城版块：

发表动态：

个人体验分析

优点

相较于微信公众号，CSDN社区在很多地方其实和微博更加相似。社区包含了微博等成熟社区平台的大部分核心功能，比如动态的发布、评论、点赞、分享。
相较于微博以舆论热点为主，CSDN社区主要以编程、计算机等话题为主，且整体的UI风格简约，对于IT行业相关的从业者与学生更为贴合，基本形成了IT生态圈。

缺点

可能是专业性更强的缘故，社区的整体生态比较冷清，数据量较少。虽然有不少用户发布动态，即使是有大量关注度的作者，也很少有人评论。
部分功能虽然都参考了各大社交平台进行设计，但用处不大。比如投票板块中，刷到的大部分投票都只有几个人参与。因为样本过少，投票结果没有什么参考价值，也无法满足动态作者的真实目的。
词条的功能不够完善。如果想要查看拥有某个词条的动态，只能先手动翻到有该词条的动态，再点击动态上的词条，才能查看所有有该词条的动态。
当前板块分类较少。当前的几个板块分别按照热度、发布时间、是否包含投票、发布城市进行排序或聚类，对用户而言可以筛选的条件过少，导致推荐给用户的帖子可能用户并不感兴趣。

软件自身定量评分

下面从不同方面定量的为软件打分。（10分制）

类别	描述	评分
核心功能	能够发表动态，进行交流分享	9
UI设计	界面简洁，但还有不少Bug（见下文Bug分析）	6
附加功能	动态中可以插入投票、链接等附加功能	8
杀手功能	没有发现很有特色的功能	4
用户体验	各种功能可以正常使用，但社交元素不足，其他人的帖子推荐也不够完善	6
运行稳定性	使用过程中比较流畅，基本没有卡顿，没有闪退等现象	9

用户调研

笔者采访了隔壁欧阳老师班上的赵同学。该同学同样是计算机专业的学生，属于CSDN主要面向的人群。采访过程如下。
Q：您平时有用过CSDN吗？使用频率怎么样？
A：有在用。基本每天都在用。
Q：使用CSDN的时候一般是用什么功能？
A：主要是搜索解决技术上的问题，比如想实现某个功能应该用什么函数之类的。
Q：尝试一下CSDN的社区功能。体验过程中有没有发现什么亮点或者遇到什么问题？
A：“投票”功能用起来挺有意思，但参与的人有点少。看别人帖子的时候大部分自己都没啥兴趣。
Q：你认为社区哪一部分目前最需要改进？
A：现有的“热门”、“最新”这些版块内容太杂体验不佳，可以试着增加些只有特定类型内容的版块。
在这里插入图片描述

改进意见

可以适当增加一些新的板块，以及一些新的功能比如查看关注者的动态、筛选不同词条下的动态。

结论

从社区建设角度，CSDN社区还是有着许多的不足之处。用户的活跃度还需要提高，社区的板块功能细化也值得进一步推进。但在社区的整体环境上，CSDN社区是远比微信等其他社交平台适合于程序员的。因此综合来看，对于想要学习社交的IT从业者，我认为CSDN社区是值得使用的。
最终结论：d) 好，不错

Bug分析和提交

Bug评级

根据 bug 产生的具体影响，将 bug 分成如下5 个等级：

等级	描述
SSS	会造成严重后果，如软件/系统崩溃、用户隐私泄漏、数据篡改、财产丢失
SS	对用户使用有较大影响，会引起歧义或极低概率的闪退，但不涉及数据安全问题
S	对用户使用体验有部分影响，如UI界面渲染错误、发生变形、文字错位但仍然可阅读，不涉及数据与软件稳定性
A	容易发现，但不涉及数据与软件稳定性问题，基本不影响界面与使用
B	难以发现，不涉及数据与软件稳定性问题，基本不影响界面与使用

测试环境

环境	版本信息
使用设备	OPPO K10
操作系统	Color OS 12.1
应用版本	5.14.2

Bug1-对自己评论的点赞与取消

Bug描述

手机端可以评论文章并且对自己的评论点赞。当手机端点赞后退出，再次进入时会变成没有点赞的图表，但会显示有一个赞，再次点击可以使赞数变成2。如果此时再取消点赞，则退出再打开后会正常显示为没有赞的状态。如果直接退出，再次进入时依然为没有点赞的图标，且赞数为1。操作过程中全程用网页版同步监视，网页版的显示均为正确。操作及示例见动图。
请添加图片描述

可复现性

按照上述要求操作，可以稳定触发该Bug。

Bug分析

因为网页版的显示完全正确，所以该bug并未实际影响服务器上的数据，而是app中判断点赞按钮的“点赞状态”并进行渲染时出现了问题，没有根据该状态判断应该渲染成什么样。因为只有对自己的评论进行点赞才会遇到该bug。经过对其他人评论的测试，发现对其他人点赞的渲染效果正确。因此对用户使用影响不大。最后评级该bug为B级。
考虑到只有给自己的点赞会出现问题，且网页端没有问题，因此说明服务端无误，而是移动端在渲染过程中因为一些逻辑问题，导致只有自己对自己的点赞出现问题。又因为用户一般不会回顾给自己点的赞，所以测试人员也忽略了这一情况。

改进建议

改成正常逻辑即可。用户打开时如果点赞了自己的评论，也应该渲染为“已点赞”的样式。在用户端渲染点赞组件时查询该条评论是否被该用户点赞，并以此选择对应的点赞图标。

Bug2-动态中的图片选择

Bug描述

发布动态过程中选择插入本地图片时，可以点开图片查看大图并进行勾选，也可以在缩略图的界面下直接勾选。如果在勾选过程中没有以缩略图的形式进行过勾选或取消勾选，则无法点击右上角确定按钮。
在这里插入图片描述

可复现性

按照上述要求操作，可以稳定触发该Bug。

Bug分析

该Bug原因可能是大图形式的选择只会改变已选择列表的内容，但并不会触发相关函数来改变右上角“确定”按钮的可交互状态。出现条件虽然较为苛刻，仅在所有图片都使用大图形式进行勾选时才会出现，但实际使用时仍有一定的触发几率（eg：手机里有多张同质图片，需要以缩略图快速定位后查看大图对比选择）。而用户只要以缩略图形式随便添加然后删除某个图片即可恢复正常，成本较低。因此Bug评级为A。
横向对比微信的发送/分享图片功能。在微信中用户同样可以在缩略图或大图界面下进行勾选，在点开大图后右上角的“发送”按钮（在CSDN中是“确定”按钮）也有着相似的功能。可以认为开发者在开发过程中与微信在这一功能上有着相似的设计理念。而微信在勾选并返回缩略图界面后，可以正常发送。从设计理念上讲CSDN应该是和微信的这一功能一致的，因此应该是开发过程中对于按钮状态的更改逻辑没有考虑周全，且测试时有所疏忽。

改进建议

从大图界面返回缩略图界面时，增加对“已选图片列表是否为空”的判断以及“修改确定按钮状态”的函数的调用。

Bug3-分享功能标签推荐

Bug描述

点击分享时，顶部可选标签为空，软件会自动的推荐一些标签供用户选择。但当用户清空掉选择的标签后，不会再次为用户展示推荐的标签。
未选择话题时：
请添加图片描述
随便选择一个勾选后：

再取消勾选后，变成：
在这里插入图片描述

可复现性

按照选择-取消选择的操作顺序，可以稳定触发该Bug。

Bug分析

该Bug可能是初次载入时，会从服务器返回推荐列表并渲染。当用户选择了标签后会隐藏该推荐列表，但取消选择再次为空时没有再次显示该列表。如果用户在选择过标签但又删除后，想要再查看推荐标签就只能退出分享界面再打开，造成一定的不便。因此，该Bug评级为A。
推荐列表是开发者想要展现的一个“feature”。当用户没有添加标签时，可以提供一些参考。当用户选择了标签但又清空时，可能是因为觉得之前选的标签不合适，因此这时推荐列表也是有意义的，如果没有出现就失去了本身的设计意义。因此我认为这是一个bug，其出现原因可能是开发者对用户需求而做的设计有缺陷（故意设计成只有初次打开才会展示推荐列表），也可能是开发过程中忘记了在标签列表清空后再次展示推荐列表。

改进建议

当删除标签时，新增对标签列表为空的判断。如果变为空，则再次展示标签列表。

Bug4-对单条评论点赞与取消的重复通知

Bug描述

对于当其他人对发布的评论进行点赞后，被点赞的人在刷新“收到的赞和收藏”界面偶后，会增加一条被点赞记录。刷新后（一定要做这一次刷新操作），如果点赞的人取消点赞并再次点赞，当被点赞人再次刷新界面后会同时显示前后两次的点赞记录，原来的点赞记录不会被移除。另外，即使点赞的人在被点赞人刷新界面前就取消了点赞，被点赞人依然会显示出被取消了的点赞记录。
在这里插入图片描述

可复现性

按照上述描述进行操作，可以稳定触发该Bug。

Bug分析

尝试删除本地数据后发现依然会同时存在多条点赞记录，说明这些记录并不是存在被点赞者的本地，而是以记录的形式保存在了数据库中，每次被点赞人刷新过界面后就会永久保存到对应的数据库中。从用户角度来看，此bug会一定程度的影响该界面的观感，但只要不是频繁刷新的话影响不会很大。从软件运营角度来看，则可能是数据库的漏洞。猜测在服务器上有一个缓存池暂存新增的点赞记录，点赞时会向其中添加一条记录，但取消点赞时也没有移除。而被点赞用户刷新界面时，会将这里所有该用户的被点赞记录存储到数据库中。如果没有其他保护措施，那么存在一种可能：用不断的点赞-取消点赞-刷新，使得数据库中产生大量的数据冗余，对服务器进行攻击。综合考量，该bug属于SS级bug。

改进建议

对于被删除了的点赞记录，应该从数据库中删除。服务端增加删除点赞记录的实现函数和接口，并由APP端在取消点赞的函数中进行调用。

Bug反馈

已在在线客服-bug反馈处提出反馈建议，并以收到回复，会对此进行讨论。
在这里插入图片描述

第二部分分析

工作量分析

只考虑CSDN APP的微社区/动态/Blink功能，在有专业UI支持的6人团队，一周五个工作日，每日10小时工作下，大致时间约为10周。将6人按照APP开发与服务器开发分为3+3，工作流程及预计时间大致如下。

流程	时间
APP界面设计	3周
APP功能逻辑编写	4周
数据库设计与服务端功能逻辑编写	4周
前后端对接与调试	4周

其中APP端的逻辑编写和服务端的编写可以同步进行，APP的功能编写需要界面设计到达一定阶段（大致1-2周）后才可以继续推进，因此最终时间大约需要10周。

软件质量分析

应用名	面向人群	主要功能	社交性	技术性
CSDN	IT相关人员	IT相关的咨询与日常分享	一般，用户间互动性不高	强，内容以IT行业为核心
知乎	学生/科技领域工作者	科技领域的分享	强，较多用户参与讨论	强，有大量讨论科技相关的内容
微博	年轻用户	各个领域的内容，以时事热点为主	强，社交气氛浓厚	弱，整体分为偏向娱乐
微信公众号	全年龄段用户	各个领域的内容	一般，用户评论通常经过公众号运营筛选	一般，只有专门的技术向公众号会以技术推广为主

第三部分建议和规划

市场概况

软件业务收入跃上十万亿元台阶。2022年，全国软件和信息技术服务业规模以上企业超3.5万家，累计完成软件业务收入108126亿元，同比增长11.2%，增速较上年同期回落6.5个百分点。——《工信部：2022年软件和信息技术服务业统计公报》

根据统计数据，IT行业依然在持续发展中，仍然有很多人涌入该行业。由于该行业正是CSDN的主要面向人群，CSDN有着良好的市场前景。同时，IT行业的一大特点便是技术更新周期短，迭代速度快，需要从业人员经常了解技术前沿，时常处于学习状态。因此，作为一款以学习、交流为主的软件，在这一方面有着庞大的生命力。
根据CSDN创始人蒋涛的演讲，CSDN的注册账号7000万，活跃用户3000万。但考虑到其演讲可能存在夸大成分，将很多临时注册或一人多账号的计入其中，故使用应用商店的下载量对比来估算活跃用户。目前，在应用商店中CSDN的下载次数约1200万，考虑到重复下载次数，对比商店中微信下载量100亿，实际人数12亿，CSDN的当前直接面向的用户量大约在100-200万。
根据工信部的数据统计，如今IT行业的从业人数约在700万人。因此，总共有约500万人为潜在用户。

市场现状

如上文所述，市面上的主要竞品为知乎、微博、微信公众号等平台。
知乎不局限于IT，主打对各行业问题的讨论，对大多数人而言是最好的拓宽知识、解决问题的平台。优势在于面向人群的广度，缺陷在于对每个行业没有进一步的细分。
微博主要聚焦于时事和社交，对网络舆论的引领有着至关重要的作用。优势在于庞大的在线人数，缺陷在于以娱乐为主，缺少技术氛围。
微信公众号主要是公众号单方面的进行推送，同样有庞大的在线人数，但由于信息的单向性，没有讨论交流的氛围。
在上述应用中，由于面向人群的特殊性，CSDN和微博之间没有很强的竞争关系。在IT领域上，用户会倾向于CSDN，而其他领域则会选择微博。
微信公众号和CSDN存在有一定的竞争关系。因为更适合讨论交流，CSDN在实际体验上会优于公众号。但因为公众号有微信的强大基础，其文章推送式的方式依然受很多人欢迎。
知乎和CSDN存在较强的竞争关系。二者都是用户常用的IT问题讨论平台。就IT领域而言，CSDN的优势在于内容更多，但也因此存在灌水文的问题。而知乎的平均质量相对更高，但内容覆盖度不如CSDN。二者相互竞争，在全领域上知乎有着绝对的优势，但只关注IT领域时，CSDN略占优势。

市场与产品生态

产品的用户分为三类：

用户	学历	年龄	专业	爱好	收入	表面需求	潜在需求
学生	本/硕/博	18-26	计算机专业	编程	低	学习并解决问题	提高计算机水平
IT从业者	本/硕/博	25+	计算机专业	编程	高	解决工作中的实际问题	分享经历
非IT从业者	本/硕/博	20-30	非计算机专业	未知	中高	解决临时遇到的计算机问题	解决计算机问题

三种用户群体之间，学生人群是IT从业者的潜在人群，大部分学生在毕业后都会成为IT从业者的一员。相对而言，学生提出的问题相对基础，IT从业者的问题更加困难、专业。而三种人群中，IT从业者也是最愿意为产品付出的人，因此可以考虑最大化的将学生群体吸收并转换为IT从业者，形成稳定的用户生态。

产品规划

改进功能

更加完善的推荐版块

N：用户需要更清晰合适的推荐板块来浏览
A：建立新的推荐版块
B：让用户更容易看到自己感兴趣的帖子，增强用户间的交流和社区活跃度
C：知乎等平台都有较为成熟的推荐算法
D：有奖调研，鼓励用户尝试并收集推荐的准确性

角色配置及规划

6人分工：

前端开发：2人
后端开发：2人
美工：1人
测试：1人

时间	规划
1-2周	问卷调研，进行需求分析
3周	美工进行初步的设计，其他人员根据需求给出设计文档并把任务进行分解
4-7周	快速开发阶段，按照文档完成功能的编写
8-9周	第一阶段测试
10-13周	根据第一阶段测试进一步优化
14-15周	第二阶段测试
16周	部署与发布