软件产品案例分析

目录:


一、调研,评测

1.BUG

2.采访

二、分析

1.功能逻辑图

2.模块分析

3.多维度评价

4.分析总结

4.1时间估计

4.2优劣势

4.3可提高的部分

三、建议和规划

1.如果你是项目经理,如何提高从而在竞争中胜出?

2.目前市场上有什么样的产品了?

3.你要设计出什么样的功能?

4.为何要做这个功能,而不是其他功能?

5.为什么用户会用你这个产品/功能?

6.你的创新在哪里?可以用 NABCD 分析。

7.如果你来领导这个团队,会有什么不一样?

8.如果你的团队有5个人,4个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?

9.描述你的团队在16周期间每周都要做什么,才能在第16周如期发布软件。


一、调研,评测


1.BUG

**BUG 定义 **

找BUG前,先来看看什么叫BUG,下面是引用《构建之法》第13章软件测试中对于BUG描述的片断。
Bug:软件的缺陷

Bug可以分解为:症状(Symptom)、程序错误(Fault)、根本原因(Root Cause)。 
1)症状:即从用户的角度看,软件出了什么问题。例如,输入(3211)时,程序出错退出。 
2)程序错误:即从代码的角度看,代码的什么错误导致了软件的问题。例如,代码在输入为某种情况下访问 了非法的内存地址——0X0000000C。 
3)根本原因:错误根源,即导致代码错误的根本原因。例如,代码对于id1==id2的情况没有做正确判断,从 而引用了未赋初值的变量,出现了以上的情况。

软件:K米 for Android
版本:4.3.0
测试环境:Android 5.1


**APP不响应,需要重启K米 **

 - 具体描述:在界面切换时,从直播切换到我这个界面,K米无响应,是否退出应用,重启应用。
 - 可能发生原因:网络不稳定加上手机内部运行不稳定
 - 没有发现此BUG的原因应该是测试时没有充分考虑到软件的运行网络环境
 - 此类K米无响应的情况还出现在直播KTV送礼物时,发布自己的动态时,和K歌主界面里的手机传歌

网络不稳定,无法加载数据

 在查看不同板块的信息时,总是会因为网络不给力而出现数据无法加载的状况。此类原因与第一项一样,不再做过多的赘述。

功能存在缺陷
1.进入直播间后模块

 - 具体描述:在进入直播间,发送表情,在大屏幕中无法全部识别,发送语音接收不到具体信息,有些图片资源无法加载
 - 可能发生原因:
              1.不完整字体包,没有兼容有些字符表情
              2.发送语音必须开启铃声
              3.图片无法加载可能是网络原因

2.定向添加好友

 - 具体描述:点击“hi聊天”->右上方“好友”->右上方“添加好友”->进入界面输入昵称或手机号添加好友,输入正确手机号后竟然查找不到此人
 - 可能发生原因:功能型BUG,对方手机号注册,如果是QQ号快速登录,输入昵称也查找不到

其他
1.快速点击

 - 快速点击一些功能键(例如附近->快速点击发布,或者个人设置里,我的红包等)这个几乎所有软件都一样,也许他们觉得没人会无聊到使劲的重复点击同一个按钮。

2.莫名功能键

红框里的两个按键都是返回是一个界面,同样的按键在一些界面里也有

1.采访

参考第8章 用户调研,12 章 软件的用户体验
1.采访对象的背景和需求

 背景:采访的用户是一个有着比较广的社交圈的女孩子,因为满足朋友经常聚会的要求,比较经常出入KTV,也是包厢里大家所称呼的“麦霸”,应不同
      场合的要求只有用过4、5次K米,但也是比较远的事情了。
 需求:除了满足基本的此类软件的必备功能外,他希望能比较快速的找到能活跃包厢里的嗨歌,在歌曲来源能比较广,还有就是软硬件交互要流畅。

2.采访照片

3.总结用户使用此类产品的过程,软件在数据量/界面/功能/准确度/上有什么优缺点? 用户体验方面有什么问题吗?
用户使用流程:

四个方面优缺点:

1)数据量上一般,歌曲来源于现在综艺节目下歌手的准备曲目,改编歌曲偏多,歌曲分类比较单一,在歌曲的详细情况上并没有给予详细的信息,所以对
 于想唱的和点到的有一定的差距

2)界面上window metro UI+安卓底栏

3)功能模块分割比较符合逻辑,软硬件交互流畅
 功能上基本满足了用户需求,但是对于手机传歌,社交分享上经常会出现操作失败闪退的功能。K米的支持KTV比较少还需推广。

用户对产品有什么修改意见

 - 增加歌曲的信息。
 - 提升数据量
 - 歌曲导入速度提升
 - UI交互可以更好

 用户推荐指数:3星

二、分析

参考 8.6 节 对工作的估计, 和14.1 节 软件工程的质量

 使用此软件的大部分功能,联系第二部分的分析,估计这个项目做到这个程度大约需要多少时间(团队人数6人左右,计算机大学毕业生,并有专业
 UI支持)。 
 分析这个软件目前的优劣(和类似软件相比),并推理出团队在软件工程方面可以提高的一个重要部分(具体建议)。

1.功能逻辑图

2.模块分析

3.多维度分析

针对不同的维度评分,对用户体验方面、UI界面美观度、核心功能,分别打分。
以下均使用100分制

1.用户体验:80
2.UI界面美观度: 80
3.核心功能: 70

4.分析总结

1.时间估计

 总时间估计:2个月
 将这个值乘以π之后,是6.28个月。实际情况应该在这个时间左右。

 以自己的大学生的水平来估计,我们并没有接触太多的企业项目开发,这意味着他们前期就得有一段的培训时间。

2.优劣势

优势

   K米直播功能增强包厢内互动性
   比较齐全的社交功能帮助用户找到趣味相投的朋友
   K米点评具有比较专业的只能识别歌手
   k米点歌设备在市场占有率较大,所以有大量线下实体的ktv可以为k米带来可观的流量。

劣势

   主要是UI、页面响应、交互方面还有待改进。

3.可提高的部分

软件的界面加载速度以及响应速度很慢,这让用户体验大打折扣,在界面设计方面,部分界面的设计有点冗余,让设计更加简洁

三、建议和规划

参考《构建之法》第8章 功能的定位和优先级;第9章 项目经理


1.如果你是项目经理,如何提高从而在竞争中胜出?

 首先就是做好需求分析,要真正的了解需求。
 对于这款软件来看:
 主要功能就是点歌、K歌、遥控等,而对于辅助功能就是音效、社交分享等。
 希望在主要功能满足的前提下能尽量挖掘更多的功能需求,可以通过调查问卷以及采访用户等手段获得用户真正需要的功能以及影响用户体验的细节后,吸引更多的用户。
 还有就是宣传,是K米可以在各大KTV里使用,毕竟这款软件是一个软硬件交互的产品,如果去KTV时,都能支持K米点歌,用户群体扩大是自然而然的事情。

2.目前市场上有什么样的产品了?

目前类似的APP还有唱吧、全民K歌、酷狗K歌等。

3.你要设计出什么样的功能?

 除了必备的主要的功能和加分的辅助功能,我希望在原有的K歌软件上增强互动性。
 因为KTV中首先必不可缺的是团体活动,一个人的歌唱大部分会让气氛冷却下来,大家可以歌曲接龙,和声等等
 在聚会后制作特色榜单,制作特色歌单,记录此次大家一起K过的歌,做一个个人定制的CD,或者所谓的“专辑”,可以记录大家在一起的时光。
 另外还想在界面设计上增强趣味性。

4.为何要做这个功能,而不是其他功能?

 在便捷式的点歌基本保障以下,我们更希望在欢乐的时光能快速调动大家的热情。
 也希望一次难得的聚会能快捷的记录并且能够更快的得到所谓私人定制,比较满足当下的快餐文化,尽可能让每个人都能够在KTV找到自己的角色。

5.为什么用户会用你这个产品/功能?

 参考以上第三点和第四点,前提是此软件已经得到大部分KTV的支持,那K歌软件就不仅仅只是K个软件,他会成为引导或者给予大家建议的party软件,增强每个人的互动性中也可拉近大家的距离,那么快速帮助大家记录KTV欢乐时光的“专辑”应运而生,鉴于以上
 两点,可以吸引用户使用该产品。

6.你的创新在哪里?可以用 NABCD 分析。

 Need(需求)—用户需要调节气氛,增强互动和友谊的手段
 Approach(方法)—通过一同参与K歌游戏的方式调动积极性
 Benefits (收益)—一个APP不仅仅成为便捷的K歌控制还能引导派对的趣味走向性
 Competition (竞争) —歌曲接龙,和声等等一些聚会游戏实现不难,但是能很好的满足用户的需求,在同款软件里目前还没有。

7.如果你来领导这个团队,会有什么不一样?

以我目前的水平,估计也没能会不一样到哪去、会更关注如何吸引用户来使用这款软件吧。
还有就是界面设计会精简很多
软件测试会尽可能多的考虑到各个方面

8.如果你的团队有5个人,4个月的时间,你作为项目经理,应该如何配置角色(开发,测试,美工等等)?

五个人: 四个程序员,一个美工
四个程序员,两个兼职负责架构设计,一个兼职测试,负责界面的代码编写

9.描述你的团队在16周期间每周都要做什么,才能在第16周如期发布软件?

第1周,美工设计出初步多套UI界面,通过网络调查,用户调研等多途径获取用户反馈以及建议。
第2~3周,整理用户反馈,美工继续改进UI设计,继续调查,继续获取反馈,并形成初步最终版。
第4~10周,开发人员完成内侧版本,测试人员进行测试反馈。
第11~12周,投放部分市场,接收正式用户的反馈,即时整理,修改BUG。
第13~15周,根据整理出来的反馈,开发人员进行修改,完成公测版本,测试人员进行测试反馈。
第16周,测试通过,发布产品。
原文地址:https://www.cnblogs.com/ACE0404/p/5981977.html