[I.2] 个人作业：软件案例分析

项目	内容
这个作业属于哪个课程	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR
这个作业的要求在哪里	https://edu.cnblogs.com/campus/buaa/BUAA_SE_2026_LR/homework/15609
我在这个课程的目标是	掌握软件工程的核心理论，协作完成软件项目开发
这个作业在哪个具体方面帮助我实现目标	帮助我在真实的软件评测与改进流程中，系统地培养了一名合格软件工程师必备的“用户导向思维”和“系统性分析能力

第一部分：调研与评测

一、软件评测

1. 软件使用

为了完成本次评测，我连续使用了网易云音乐30分钟，体验了其核心功能，包括每日推荐、歌单、搜索、播放、评论、个人电台等。（照片见基本使用流程）

2. 软件分析

使用基本流程

打开 App
首页/推荐
点击某歌单/单曲

播放
收藏/添加歌单/下载

切歌/切设备

评论/社交互动

是否解决用户需求？

能够较好满足“发现音乐 / 播放 / 社交互动”三类核心需求。
1. 推荐机制能发现小众/独立歌曲。
2. 广告/社区模块对首页占比高，影响纯音乐体验（见首页截图）。

按维度列优缺点

维度	得分	评价依据
功能性 (Functionality)	9.0	播放、下载、多端同步、社区互动功能极度完备。
可靠性 (Reliability)	7.5	在弱网切换、多设备并发播放时偶有同步逻辑冲突。
易用性 (Usability)	6.0	菜单层级过深，广告干扰较多，新用户学习曲线因功能冗余而变陡。
效率 (Efficiency)	8.0	性能开销较大。

3. 改进意见

优化启动速度和流畅度，减少卡顿。
增加离线模式下的智能推荐（无网络时根据历史记录推荐）。
改进搜索算法，提高错别字容错和模糊匹配能力。
简化部分功能的操作路径，例如将“最近播放”放在更显眼的位置。
增强歌单管理功能，允许用户对歌单进行标签分类。

4. 用户调研

我采访了软件工程班级的一位同学郭佳琦，她是一名重度音乐爱好者，平时常用网易云音乐听歌、发现新音乐，并喜欢在评论区互动。选择她是因为她对音乐软件有较高要求，且熟悉多个竞品。

5. 评测结论

结论选择（必填）：d) 好，不错。
结论理由：
1. 网易云在“音乐发现 + 社区”上具有明显优势；
2. 体验劣势集中在商业化入口与资源占用，这会影响对“纯音乐/专注型”用户的吸引力；
3. 综上权衡，适合追求发现与社区的年轻用户，但对追求轻量与稳定的场景可改进。
量化结论（跑分）：见下“量化测评表”。

为了避免评价过于主观，我参考了《构建之法》中提到的软件质量衡量方法，设计了一套针对音乐 App 的定量评分模型。通过对五个核心维度加权求和，我们可以得到一个客观的“软件质量分”。

(1) 评分维度与权重分配

根据音乐软件的特性，我设定了以下权重，侧重于功能完整性和推荐算法的护城河效应：

功能性 (Functionality) - 25%：核心播放、歌单管理、评论互动的完备性。
可靠性 (Reliability) - 20%：运行稳定性，是否闪退，播放是否断断续续。
易用性 (Usability) - 20%：界面逻辑是否简单，找歌方不方便。
性能 (Performance) - 15%：启动速度、内存占用、切歌响应。
推荐准确度 (Recommendation Accuracy) - 20%：每日推荐的“心动率”。

(2) 评分标准与实测数据记录

维度	评分标准 (0-10)	实测表现描述	本次得分
功能性	10=全能；5=基础可用；0=缺失严重	播放、下载、多端同步非常成熟，功能极其丰富。	9.5
可靠性	根据 Crash 频率及播放中断次数打分	20 分钟高强度操作无闪退，但切歌时偶有 1 秒无声。	8.5
易用性	综合操作步数与广告干扰度	首页广告多，设置菜单太深，功能堆砌导致找功能费劲。	6.5
性能	冷启动时间与内存占用归一化	启动约 1.6s，播放时内存占用 480MB，属于“重型”App。	7.0
推荐准确度	随机抽取 10 首推荐，计算心动收藏比例	每日推荐 10 首中，有 8 首听完且 3 首加入了收藏。	8.5

(3) 定量测评计算示例

基于上述实测打分，网易云音乐的最终定量得分计算如下：

$$总分 = 9.5 \times 0.25 + 8.5 \times 0.2 + 6.5 \times 0.2 + 7.0 \times 0.15 + 8.5 \times 0.2$$

计算过程：

功能性得分：$9.5 \times 0.25 = 2.375$
可靠性得分：$8.5 \times 0.2 = 1.7$
易用性得分：$6.5 \times 0.2 = 1.3$
性能得分：$7.0 \times 0.15 = 1.05$
推荐得分：$8.5 \times 0.2 = 1.7$

最终总分：

$$2.375 + 1.7 + 1.3 + 1.05 + 1.7 = \mathbf{8.125}$$

(4) 测评结论

8.125分 的结果说明网易云音乐是一个极其成熟且核心竞争力非常突出的产品，但在性能优化和界面减负方面仍有较大的提升空间。这种定量的方法能让我们清晰地看到，虽然它的推荐很准（8.5），但臃肿的界面（6.5）确实拖了总分的后腿。

6. Bug分析和提交

(注:由于本人测试未发现明显功能性bug，以下两处bug为上网查阅资料所得，文末已注明出处)

量化标准说明

严重性等级（1-5星，5星最严重）：
- ★★★★★：致命性系统故障（如服务完全不可用、核心功能失效）、安全漏洞、大规模数据错误。
- ★★★★☆：严重功能异常（如播放失败、数据大面积异常）、用户体验严重受损。
- ★★★☆☆：一般功能异常（如界面显示错乱）、部分用户受影响。
- ★★☆☆☆：轻微问题（如UI不协调、文案错误），不影响主要功能。
- ★☆☆☆☆：建议性改进，非Bug。

Bug 1：年度听歌报告数据异常（2025年12月）

测试环境：
- 操作系统：iOS 17 / Android 14 等多平台
- 应用版本：网易云音乐 v9.0+（2025年度报告版本）
- 网络：所有网络环境
- 时间：2025年12月底（年度报告发布后）
可复现性：特定条件下发生（部分用户账号）
- 条件：根据大量用户反馈，部分用户的年度报告中出现了“从未听过的歌曲”被计入播放量，且“年度歌手”为完全陌生的艺人。该现象并非所有用户出现，但涉及账号范围较广。
- 复现步骤：
  1. 用户正常使用网易云音乐听歌一年。
  2. 2025年12月下旬，App内推送年度报告入口。
  3. 用户点击查看自己的年度报告。
  4. 发现报告中列出的“年度歌曲”“年度歌手”与实际听歌习惯严重不符，甚至出现从未播放过的歌曲和艺人。
  5. 用户可手动在TOP5中调整，但原始数据错误依然存在。
Bug具体情况描述：
- 现象：大量用户在社交媒体反馈年度报告数据不准确，例如“我从来没听过这首歌，居然成了我的年度歌曲？”“年度歌手是一个我根本不认识的乐队”。官方客服回应称数据统计周期为1月1日至12月20日，涵盖全端有效听歌记录，但未解释异常来源，且否认账号被刷数据，强调报告生成后无法修改。随后，网易云音乐紧急上线了“手动调整”功能，允许用户在TOP5范围内修改年度歌手、歌曲、专辑，但原始统计错误并未修复。
Bug分析：
- 可能成因：
  1. 数据统计逻辑缺陷：可能在统计播放量时，错误地将其他用户的播放记录或测试数据混入个人数据中；或者跨端统计时，设备识别出错，导致其他设备的播放记录归属错误。
  2. 数据清洗不彻底：年度报告生成前，未对异常数据（如刷量、机器行为）进行有效过滤，导致无效播放计入。
  3. 缓存或合并问题：用户历史听歌数据可能被错误合并或重复计数。
- 类比：类似电商平台年度账单中出现陌生商品的情况，通常是因为账号授权第三方应用或数据同步异常。
- 严重性：★★★★☆
  - 系统功能：年度报告是重要年度总结功能，数据错误导致用户对平台信任度下降。
  - 安全性：虽未涉及隐私泄露，但数据不准确可能暗示后台数据管理混乱。
  - 用户体验：用户感到困惑和被冒犯，尤其当陌生歌手被列为最爱时，体验极差。
- 为何未在发布前修复？：
  - 可能原因：测试数据量不足，未覆盖所有用户场景；或统计逻辑在上线前未经过充分验证。团队可能急于推出年度报告，忽略了数据校验环节。属于测试把关不严，对特殊配置（如多端用户、异常播放记录）考虑不足。
改进建议：
- 正常行为：年度报告应准确反映用户实际听歌数据，不出现陌生歌曲或歌手。
- 实现方式：
  1. 优化数据统计口径，确保播放记录的唯一性和正确归属。
  2. 增加数据审核机制，对异常播放记录进行过滤（如单曲循环次数过高、短时间内大量播放等）。
  3. 在生成报告前，允许用户预览关键数据并确认，或提供申诉渠道。
  4. 若发现数据错误，应及时修复并向用户致歉，而非仅提供手动调整功能。

Bug 2：平台频繁崩溃与技术故障（以2025年2月28日故障为例）

测试环境：
- 操作系统：iOS / Android / Web 全平台
- 应用版本：网易云音乐 v8.9.x ~ v9.0.x
- 网络：所有网络
- 时间：2025年2月28日（及其他历史故障日期）
可复现性：特定时间段内必然发生（故障期间）
- 条件：当机房网络故障或服务器异常时，所有用户访问App均会出现问题。故障期间，用户无法正常使用部分功能。
- 复现步骤（故障期间）：
  1. 打开网易云音乐App。
  2. 发现首页部分页面加载缓慢，甚至白屏。
  3. 尝试使用推荐功能、搜索、歌单等，均出现异常或无法加载。
  4. 核心播放功能可能正常，但其他功能不可用。
Bug具体情况描述：
- 现象：2025年2月28日，大量用户反馈网易云音乐App出现部分页面加载慢、白屏、推荐功能异常等问题。官方随后回应称故障由机房网络故障引发，并于当晚修复，同时向用户赠送7天黑胶会员作为补偿。类似故障在2024年多次发生：2024年12月安卓端首页报错（配置错误，20分钟修复）；2024年8月服务器故障导致网页端502错误、App五大板块无法使用；2024年3月登录状态失效（网络异常）。
Bug分析：
- 可能成因：
  1. 基础设施单点故障：机房网络设备故障，导致服务不可用，说明缺乏多机房冗余或自动切换能力。
  2. 配置错误：2024年12月故障为配置错误，说明发布流程或配置管理存在漏洞。
  3. 代码或架构缺陷：部分故障可能由代码更新引发，测试未覆盖所有场景。
- 类比：类似大型互联网公司的服务不可用事件，通常与负载均衡、数据库、网络设备等有关。
- 严重性：★★★★★
  - 系统功能：服务完全不可用或核心功能受损，属于致命性故障。
  - 安全性：无直接安全漏洞，但长时间不可用影响用户数据访问。
  - 用户体验：用户无法听歌，体验极差，导致流失风险。
- 为何未在发布前修复？：
  - 可能原因：基础设施的可靠性问题往往需要在长期运行中暴露，单次测试难以覆盖所有故障场景。但多次重复发生，说明团队在灾备、监控、快速恢复方面投入不足。属于对用户需求（高可用性）掌握不好，或开发运维流程不完善。
改进建议：
- 正常行为：服务应保持高可用性，全年故障时间控制在极小范围内。
- 实现方式：
  1. 建立多数据中心冗余，实现故障自动切换。
  2. 完善监控和告警系统，故障发生时能快速定位和修复。
  3. 加强发布前的压力测试和混沌工程实验，模拟机房故障等极端情况。
  4. 优化配置管理，采用灰度发布和自动回滚机制，减少配置错误影响。

第二部分：分析

1. 工作量分析

假设一个6人团队从零开始开发一个类似网易云音乐的产品，估计需要的时间如下：

需求分析与原型设计：2周
UI设计：3周（包括多端适配）
后端架构与数据库设计：3周
核心功能开发：
- 用户系统：2周
- 音乐播放器（包括解码、缓存、播放控制）：4周
- 歌单管理：2周
- 搜索功能：3周
- 评论系统：2周
- 推荐算法（基础版）：4周
前后端联调：2周
测试与修复：3周
上线准备：1周

总计约 26周（6.5个月）。考虑到团队经验不足，可能需要更长时间，实际可能需要30周以上。但如果有成熟的框架和云服务，时间可以缩短。

2. 软件质量分析

与同类软件相比

网易云音乐的主要竞争对手有QQ音乐、酷狗音乐、虾米音乐等。

维度	网易云音乐	QQ音乐	酷狗音乐
曲库规模	较大，但部分版权缺失	最大，腾讯系版权优势	较大，侧重流行
推荐算法	精准，个性化强	较好，但稍逊	一般
社区氛围	评论文化浓厚，社交属性强	较弱	较弱
界面设计	美观，简洁	稍显复杂	较杂乱
功能丰富度	高	高	高
音质	提供无损	提供无损	提供无损

综合来看，网易云音乐在社区和推荐方面领先，但在版权方面处于劣势。我认为其质量在同类产品中可排第二（仅次于QQ音乐）。

软件工程改进建议

从Bug分析可以看出，团队在测试环节可能存在疏漏，特别是对边缘场景的覆盖不足。建议加强自动化测试，尤其是UI自动化测试和性能测试，同时引入更多的用户验收测试，确保核心功能在各种操作下稳定。此外，可以建立更完善的Bug追踪和优先级管理机制，及时修复影响用户体验的问题。

第三部分建议和规划

假设我是网易云音乐的新任项目经理，我计划在现有基础上进行改进，以在竞争中胜出。

1. 市场现状

市场概况：中国在线音乐市场用户规模巨大，直接用户约6亿（月活），潜在用户包括所有网民，约10亿。市场仍在增长，但竞争激烈。
竞争产品：主要对手为QQ音乐、酷狗音乐、酷我音乐（腾讯系），以及抖音、快手等短视频平台（分走用户时间）。
产品定位：
- 网易云音乐：主打“音乐社交+个性化推荐”，用户多为年轻人、学生、文艺青年。
- QQ音乐：主打“版权+大众化”，覆盖全年龄段。
- 酷狗音乐：主打“K歌+直播”，用户偏下沉。
各方态势：腾讯系凭借版权优势占据市场份额第一，网易云音乐以社区特色居第二，但版权劣势明显，用户流失风险大。

2. 市场与产品生态

核心用户群：18-30岁，大学生、白领，喜欢发现小众音乐，热衷评论互动，有文艺情怀。表面需求是听歌，潜在需求是情感共鸣、社交认同。
用户群体关系：用户之间通过歌单、评论、动态形成弱社交关系，可进一步强化，例如引入兴趣小组、音乐圈等。
产品生态：网易云音乐已有子产品如“LOOK直播”、“云村”等，可与主产品联动。例如直播中推荐相关歌曲，或歌曲页面引导进入直播间。

3. 产品规划

新功能设计：音乐社交圈“音遇”

功能描述：基于音乐兴趣的匿名或实名社交圈，用户可以创建或加入“音乐话题”群组（如#摇滚#、#民谣#），在群内分享歌曲、讨论、发起共听活动。
为何做这个：目前评论功能是单向的，用户之间缺乏实时互动。而社交可以增加用户粘性，对抗短视频的冲击。通过兴趣群组，让用户找到同好，形成生态。
NABCD分析：
- Need：用户有寻找同好、深度交流音乐的需求，而现有评论无法满足实时互动。
- Approach：在APP内增加“音遇”入口，用户可根据兴趣加入群组，支持文字、语音、音乐分享、一起听歌等功能。
- Benefit：增强用户粘性，延长使用时长，形成社区壁垒，降低流失率。
- Competition：QQ音乐也有类似“扑通社区”，但偏明星动态。我们的“音遇”更注重用户自发兴趣小组，更接地气。
- Delivery：通过首页推荐、歌单关联、消息推送等方式引导用户加入。

团队配置与16周规划

团队角色（6人）：
- 项目经理（我）1人
- 后端开发2人
- 前端开发（iOS/Android/Web）2人
- 测试1人
- （UI设计由专业支持，不计入6人）
16周详细规划：

周数	任务
1-2	需求调研与分析，竞品分析，撰写PRD，确定功能优先级。
3-4	UI设计，输出高保真原型；后端设计数据库和接口。
5-6	前端开发基础框架，后端开发核心API（用户、群组、消息）。
7-8	前后端联调，实现群组创建、加入、聊天功能。
9-10	开发“一起听歌”功能，实现实时同步播放。
11-12	开发推荐算法，根据用户听歌历史推荐相关群组。
13-14	内部测试，修复Bug，优化性能。
15	邀请部分用户进行Beta测试，收集反馈。
16	修复最后问题，发布版本，准备推广。

通过以上规划，我们期望在第16周推出一个稳定、有趣的“音遇”功能，提升用户活跃度和留存率，进一步巩固网易云音乐的社区优势。

参考文献

[1] 澎湃新闻网. "2025年度歌手，我竟然没听过？" 2025-12.

[2] 光明网. "网易云崩溃了！补偿方案公布→" 2025-02-28.

[3] 邹欣. 构建之法：现代软件工程. 北京: 北京航空航天大学出版社.

[4] 邹欣. "软件工程讲义 1 软件质量评测." 博客园. .

posted @ 2026-03-18 22:26 Nice2cu22 阅读(33) 评论(0) 收藏举报

刷新页面返回顶部