软件评测
软件评测
这个作业属于哪个课程 | 2021春软件工程实践|S班 |
---|---|
这个作业要求在哪里 | 软件评测 |
这个作业的目标 | IT 问答网站评测 |
其他参考文献 | 无 |
第一部分 调研,评测
CSDN问答
体验
支持的登录渠道还是蛮多的,个人直接使用微信登录了
登录后回到了主页,再次点击进入问答版块
直接查阅一下最热的问答,发现排名第一的是个与技术无关的问答,作为一个技术社区这种氛围略显奇怪.....(我直接放了思否和Stack Overflow的同期榜单)
这同样是热榜上的问题,窃以为csdn还是应该采取一些措施避免灌水的(例如csdn的反对票我一直不知道投了有啥用,一如博客园)
还有一点不习惯的是csdn问答页面右侧没有滚动条,不知道是设计时便如此还是我的浏览器兼容性的问题
我尝试着搜索一个问题,右侧滚动条又回来了???页面的格式还是统一比较好
提了个问题,csdn问答的编辑栏比起segmentfault要简洁一些(当然功能也要少很多),我觉得例如图表和函数之类的功能还是挺有用的
还有一个比较痛苦的地方就是csdn问答板块里有些问题明明已经得到了解决,提问者却不点采纳也没有积极的反馈,这样还是挺消磨回答者的热情的
- 优缺点分析
- 优点:对新手友好,作为中文社区本地化资源丰富
- 缺点:上面已经描述了一部分,还有问题和回答的优劣似乎没办法直观的衡量。
- 产品有什么改进意见
csdn问答区的质量不算高(尽管存在审核),可以期望活跃用户进行社区管理,可以效仿Stack Overflow,通过回答问题获得积分和管理权限,提升权限的用户拥有关闭及修改问题等管理板块的能力
BUG
Bug严重性评估表格:
星级 | 描述 |
---|---|
★★★★★ | 系统功能性故障,如发生服务器崩溃或数据丢失等问题,结果不可逆,严重影响用户体验 |
★★★★ | 系统功能性故障,如发生服务器异常等问题,结果可恢复,较严重地影响大部分用户体验 |
★★★ | 系统设计缺陷,如数据不同步等问题,较轻微地影响大部分用户体验 |
★★ | 系统设计缺陷,通常不易发觉,较轻微地影响小部分用户体验 |
★ | 界面设计不足,有一定主观性,对少部分用户较小地影响用户体验 |
- Bug发生时的测试环境
win10
Chrome浏览器 - Bug的可复现性及具体复现步骤
必然发生,只要有中文符号就会出现 - Bug具体情况描述
中文符号在我的回答的预览界面会报乱码
- Bug分析
- Bug的可能成因:程序员没有考虑到中文编码?
- Bug的严重性:三星
结论
评价:一般
平心而论,csdn是在这三个问答社区中对新手最友好的,相对来说编程初学者面对的大多数基础问题都可以比较好的找到,由于是老牌中文it网站,其实在我日常学习中遇到问题的时候大多数情况下也是先去博客园和csdn上找一找答案(Stack Overflow实在太太太卡了),但是csdn使用中的体验属实不算好,比如这个没有滚动条真的非常不适应,还有问题和回答的优劣似乎没办法直观的衡量,如下图所示或许会更直观些,当然在提问之后短短20分钟内就得到了回答还是挺强的
Stack Overflow
体验
评测csdn的时候也顺便打开了Stack Overflow和SegmentFault一起比对了下,登录的话直接用github账号登录(其实我觉得Stack Overflow的页面老旧了些还是有一点点丑的,但是不知道是不是我的审美问题)
搜索了下一个pip的警告,页面过了好久才出来,并且可见右侧的一些图片还是没有加载出来,还是最好科学使用
解释还是挺清楚的(并且回复挺快的),就是我英文不太好读起来有点费劲
问了个问题
发现如果贴入代码的话,预览时没什么问题,但是发布后发现样式不符合预览时的预期
- 优缺点分析
- 优点:stackoverflow作为全球最大的技术问答网站,可以说每个搞过技术的人是必上的网站
- 缺点:上面已经描述了一部分,速度非常慢,并且规矩挺多的。
- 产品有什么改进意见
StackOverflow有一些国内搭的中文站,但是如果官方能在内地或香港的设个服务器就好了
BUG
- Bug发生时的测试环境
win10
Chrome浏览器 - Bug的可复现性及具体复现步骤
无 - Bug具体情况描述
Stack Overflow感觉没什么大的bug(当然也是因为它实在卡到我失去耐心)
写一些发现的小问题
注销按钮放在了聊天按钮边上,一方面是容易误点到,一方面是比较难找(一般情况下退出登录按钮都应该是从头像中点开吧)
- Bug分析
- Bug的可能成因:没有考虑到人机交互的设计
- Bug的严重性:一星
结论
评价:非常推荐
Stack Overflow这是个英文网站,问题和回答都是英文的,所以英文不好的人比较痛苦,但是Stack Overflow的问答质量和解答速度应该还是这三家中最好的,这里可以推荐一下https://zhanyichu.cn,当然堆栈内存溢出也不错(https://stackoom.com),都是中文版的StackOverflow
SegmentFault
体验
之前都没有使用过,所以注册一下
虽然绑定手机号已经差不多是国内网站的惯例了,但是还是免不了抱怨一下一个问答网站要这些信息干什么嘛。。。。
这是三个网站中唯一一个有广告的.jpg
除了广告有点多外,问答还是挺专业的,热榜上也没有乱七八糟的问题
提了个问题,莫名其妙的跳出来软工实践
SegmentFault有自动保存,还是要赞一下,并且一边编辑一边出预览还是挺舒服的,这个提问模板也是个人认为的好功能,虽然问答社区有设定一系列的规则,例如“写问题标题,描述具体现象。杜绝 “求救,大佬,小白…” 等和问题无关的词汇。写问题内容详细描述你碰到的困难,写清楚你尝试了什么方法,错误代码,软件的版本,相关代码要用代码控件输入。”等等等,但是我舍友以“大佬们求救,小白遇到问题了”作为标题在csdn问答中提问也通过了审核,既然很多人完全不看提问步骤,还不如写个模板给提问者套用。。。
提问题后直接发布出来了,60分钟后才能自问自答还是挺合理的,我推测这与SegmentFault存在等级有关,这样能避免自己刷分
这个举报按钮还是挺有意思的,我注意到csdn问答的举报按钮作为提问者是看不见的,只有其他用户才能举报,这方面比SegmentFault考虑的好
- 优缺点分析
- 优点:页面简洁,刚刚用过StackOverflow后感觉速度贼快,资源还算丰富,能用markdown和支持latex
- 缺点:上面已经描述了一部分,bug挺多的,广告也挺多的,审核非常慢
- 产品有什么改进意见
修一下bug,再多找几个审核吧
BUG
Bug1
-
Bug发生时的测试环境
win10
Chrome浏览器 -
Bug的可复现性及具体复现步骤
稳定复现,但是个人感觉无伤大雅 -
Bug具体情况描述
生日自动设置为注册日期
-
Bug分析
-
Bug的可能成因:或许是开发想和用户开个玩笑呢
-
Bug的严重性:一星
Bug2
-
Bug发生时的测试环境
win10
Chrome浏览器 -
Bug的可复现性及具体复现步骤
稳定复现,点进系统通知就可以看到 -
Bug具体情况描述
系统通知里给的链接居然3个有两个报404
-
Bug分析
-
Bug的可能成因:我也不知道为啥会有这种神奇的问题
-
Bug的严重性:一星
Bug3
-
Bug发生时的测试环境
win10
Chrome浏览器 -
Bug的可复现性及具体复现步骤
稳定复现,点开私信就可以看到 -
Bug具体情况描述
移动光标到私信的用户名上时,用户名高亮显示,但是点击没有任何反应
-
Bug分析
-
Bug的可能成因:可能本来是想写点击用户名跳转到对应用户的主页的,但是接口没写好
-
Bug的严重性:二星
Bug4
-
Bug发生时的测试环境
win10
Chrome浏览器 -
Bug的可复现性及具体复现步骤
稳定复现,一试就崩 -
Bug具体情况描述
当在首页的搜索框内键入的字符串长度过长时,网页会无法响应 -
Bug分析
-
Bug的可能成因:不知道
-
Bug的严重性:三星
结论
评价:好,不错
SegmentFault虽然之前没有使用过,但是上手后感觉还是挺不错的,除了广告多了些,审核慢了些,没有什么大的缺点,但是不知道为什么没啥名气,能用markdown和支持latex是最大的优点,我会继续使用的
第二部分 分析
开发时间估计
如果团队人数6人左右,都是计算机大学毕业生,并有专业UI支持,我预计可以用半年时间给出一个可以用的版本
已每周50个工时作估计,前期要1个月进行用户调研,系统和架构设计等
随后可以花4-6周完成一个包括注册登录,提问回答(富文本框插件版本)点赞回复等基础功能的版本
之后可以花2个月进行一些进阶功能的完善,例如富文本框不应该只有基础的输入文字功能(可以加入上传附件),还有用户管理和一些管理员的审核功能
最后两个月进行一下完整的测试,然后正式上线
同类产品对比排名
考虑CSDN问答、SegmentFault和Stack Overflow,就问答质量,上手难度,回答速度,界面设计做一排名
总体评价 | Stack Overflow >SegmentFault>CSDN问答 |
---|---|
问答质量 | Stack Overflow >SegmentFault>CSDN问答 |
上手难易 | CSDN问答>SegmentFault>Stack Overflow |
回答速度 | Stack Overflow>CSDN问答>SegmentFault |
界面设计 | SegmentFault>CSDN问答>Stack Overflow |
从各方面的问题,推理出这个软件团队在软件工程方面可以提高的一个重要方面
我建议SegmentFault扩大团队规模,多找一些审核和运营,SegmentFault的审核以及问题反馈后得到解决的速度都是慢的要死。。。
你在第一部分发现的bug,为何软件团队不能在发布前修复?他们是不知道,还是有意不修复?你觉得是什么原因?可以从下面的可能性中选取几个
我认为SegmentFault那些BUG很可能是由于赶工导致的,开发进度不及预期导致软件只能赶进度,到最后那些小bug根本修不完,就直接发上去了,当然这些小bug不影响使用也是没有及时修复的原因。
第三部分 建议和规划
市场概况
- 首先市场有多大?
《中国互联网发展报告2019》指出:中国网民规模为8.54亿人,互联网普及率达61.2%,网站数量518万个
根据埃文斯数据公司2019年最新统计数据,2018年全球共有2300万软件开发人员,预计到了2019年底,这个数字将达到2640万,而到了2023年或将达到2770万,其中增长最快的国家是中国(到2023年将占6%至8%)。而作为软件开发人员的重要组成部分,全球程序员的数量也会相应地持续走高,目前中国保守估计有160万软件开发人员。---引用自码农岛 - 其次直接的用户有多少?潜在的用户又有多少?
根据2015年软件开发者白皮书,技术类网站依然是软件开发者获取知识的主要来源,通过社交类工具、App等渠道学习的趋势在上升,有 92% 的软件开发者主要通过访问技术媒体 / 技术社区 / 技术论坛 / 开源网站等渠道获取知识, 同时也有 48% 的软件开发者通过关注技术博客和微信等渠道学习新技术。不论开发者从事开发的时间长短,在获取知识方式上无明显差异。
也就是直接用户有超140万,考虑到行业发展,潜在用户估计在200万左右。
市场现状
-
目前市场上有什么样的产品了?
市场上比较成熟的技术门户网站有、开源社区、csdn、知识库、SegmentFault、博客园 - 开发者的网上家园、ITeye、菜鸟教程 - 学的不仅是技术,更是梦想!、Android Studio 中文社区、MSDN、Stack Overflow、V2EX、oschina等等
具有问答功能的,主要有csdn、SegmentFault、Stack Overflow、oschina -
上述产品的定位、优势与劣势在哪里?
Stack Overflow最大的优点是历史久体量大,然而Stack Overflow常年抽风,不够稳定
csdn和oschina的定位有些类似(csdn的博客做的比较好,oschina的资源比较多),这两个都算是国内的老牌开发者网站,拥有比较多的忠实用户,但是csdn的vip制度和开源中国乱糟糟的版面还是会劝退一批人
SegmentFault网站的整体风格比较简洁,问答也挺专业,缺点的话广告算一个,社区管理者和用户之间的冲突也算一个 -
上述产品之间呈现什么样的关系,哪些为竞品关系?以及竞争中的各方态势如何?
访问问答类的 Stack Overflow 网站的软件开发者占比为 43%,应该算是问答类网站中的扛把子,csdn、SegmentFault、oschina算是地头蛇,我觉得依托于csdn的生态问答社区的优势还是挺大的
市场与产品生态
- 这个产品的核心用户群是什么样的人?典型用户是什么样的?学历,年龄,专业,爱好,收入,表面需求,潜在需求都是什么?
核心用户是30 岁以下的软件开发者。
典型用户是工作在特级城市的男性程序员(九成以上的软件开发者为男性),从事开发时间不超过3年,拥有本科及以上学历,收入1w左右,每周都需要加班,平均加班时长在 20 个小时以上。 - 产品的用户群体之间是否存在一定的关系?是否有利用其相互作用二次构成特定用户生态的可能性?
我觉得理论上来说作为拥有相似工作的群体,在问答网站上熟络了之后形成用户黏性是可以期待的。
产品规划
-
功能以及NABCD分析
csdn可以效仿Stack Overflow,通过回答问题获得积分和管理权限,提升权限的用户拥有关闭及修改问题等管理板块的能力
N:csdn问答区的质量不算高(尽管存在审核),可以期望活跃用户进行社区管理
A:回答者尽管解决了问题却没有得到采纳的话,可以申请仲裁,10名高权限用户通过投票决定能否强制采纳问题
B:csdn社区作为国内比较优秀的社区本就吸引了大量用户,如果能够提升问答质量的话,就更吸引人啦
C:如何保证这种类似管理员的用户不“为非作歹”也是个问题,Stack Overflow的社区自发管理已经非常完善了,短时间内很难比得上
D:可以在csdn的主版面上进行宣传 -
角色配置
团队人数6人左右,可以按2后端,3前端,1测试来安排,pm可以让组内技术比较强的大佬来兼任。 -
16周的详细计划
第1周:市场调研,确立典型用户
第2周:需求评审,进行原型设计
第3周:系统设计,数据库设计
第4周:环境搭建,前后端架构搭建
第5周:正式开始编码,采用迭代式增量软件开发过程,小步快跑
第6周:设定一个Scrum过程为两周,第5和6周完成第一个scrum
第7周:召开一个迭代回顾会,进入下一个周期
第8周:完成第二个scrum,期间进行反馈总结
第9周:在开发过程中同步推进测试与对接,在本周发布第一个可用版本,进行第一轮内测
第10周:收集内测意见,举行事后诸葛亮会议,会后根据反馈暴露的问题进行修修补补
第11周:召开一个迭代回顾会,进入下一个周期(第三个scrum)
第12周:完成第三个scrum,期间进行反馈总结,推动比较完善的版本发布
第13周:测试对项目进行完整的测试并反馈给开发,进行发布前最后的完善
第14周:发布公开的版本,收集用户意见
第15周:整理用户的意见生成报告,进行修改,部署上线
第16周:经过一段时间的试运行,没有问题的话项目收尾,进行交接