组队后的团队项目的整体计划安排；（5分）
alpha版本的规划是寻求到合适的音乐源并能够使用，基础的播放界面及app主体的实现。
（11.4-11.18）
beta版本则开始对模块化功能进行拓展开发，例如歌词显示、歌单合并、快速查找、主题变换等。
（11.19-12.9）
长期将对流畅度、快速响应进行优化与处理，及时更换失效源，添加更多功能。
（12.9-?）
项目logo及思维导图（由于校庆作业延时一周，新增要求）
评估团队中每个人对本次作业的贡献比例，描述为撰写需求规格说明书的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，全组平均后，组长得分减 50%）（5分）
需求规格说明书的工作流程：集合讨论、共同分析、分工书写各项工作。
| 组员 | 分工 | 贡献比例 |
|---|---|---|
| 跃安(2348) | 需求分析报告、评审表制作、评审、Q&A | 21% |
| 泓(2321) | 需求分析报告、评审、Q&A | 13% |
| 裕翔(2531) | 项目logo、评审、Q&A | 5% |
| 杰(2344) | 博客整理、项目logo、视频、PPT、原型、评审、Q&A | 24% |
| 松(2322) | 需求分析报告、评审、Q&A | 13% |
| 淇(2226) | 原型、评审、Q&A | 12% |
| 佳炜(2531) | 思维导图、类图、Q&A | 12% |
视频&&PPT 20%
原型&&项目LOGO 15%
需求分析报告 36%
评审表&&思维导图&&类图 15%
评审&&Q&A 14%
评审表格设计（2分）
答辩总结（20分）
求出本组的现场答辩得分：去除最高总分，最低总分，求平均分（保留2位小数）
最高分78，最低分63，余
（75+69+66+65+70+72+77）/ 7 = 70.57
收集其他组对本组提出的问题，并回答（每少回答一点，该项得分扣除5%，扣完为止）
答1组：
1. 答辩中没有很好的体现出与竞品之间的不同？产品的核心竞争力在于：
与竞品的核心竞争力在于我们的UI界面与动效，最早网易云音乐在多个音乐平台中脱颖而出正是因为其优雅的界面。同时有一些功能尚未公布，但在考虑范围内。如通过多个用户的歌单来实现反向推荐，例如一些动漫爱好者，他们会在歌单中添加自己喜欢的bgm，通过对重合度的分析，我们可以向用户反向推荐动漫。
2. 是否考虑过用其他方式规避版权风险同时又实现产品功能？
版权问题实属无解，否则版权歌曲也不会分布在各家平台。
答2组：
1. 类似竞品较多，你们该如何从类似产品中拉取用户。
我们会尽力在UI界面与动效上下功夫，最早网易云音乐在多个音乐平台中脱颖而出正是因为其优雅的界面。同时有一些功能尚未公布，但在考虑范围内。如通过多个用户的歌单来实现反向推荐，例如一些动漫爱好者，他们会在歌单中添加自己喜欢的bgm，通过对重合度的分析，我们可以向用户反向推荐动漫。
2. 版权问题该如何解决？音质问题又能否得到保证。
版权问题，请查看上次的Q&A。
就音质而言，目前的320K已经能够满足大部分人的需求。
购买手机时自带或自己购买的500元内耳机几乎无大差别。
其次您对于HiFi是什么看法？在Android的默认设置中，任意采样率的声音在Audio Flinger中将被统一升采样到48kHz播出（这一值可以修改，例如统一修正为44.1kHz），vivo和LG是绕过系统的默认硬件通路，在机身塞进了两颗专用芯片及一颗运放芯片来实现的（vivo xplay）。
同时一般的无损歌曲单曲可达到百兆级别，您的储存够吗？
希望您能有更多的了解后再提出此问题。
3. 如何盈利
前期不考虑盈利，后期通过启动页广告或用户捐赠，以及可作为后续开发应用的引流入口来进一步获得收入。
答3组：
**1. 音乐聚合类软件，目前市面上已经有成熟的软件，比如灵音。并且灵音可以播放无损音质。而你们将音乐聚合作为核心功能，请问你们的竞争优势在哪呢？ **
灵音这款软件之前有认识的人用过，就用户体验说，界面有点单调，而且player有时候会有bug，打不开无法使用。而之前也提过其他的相关软件，我们的优势在于使用界面的简洁和音乐内容丰富，对平台也会进行适用性的调试以及用户的反馈机制，尽量避免bug的出现以及尽快的修复
2. 音乐聚合行为是侵权的，经常有这类软件被下架，我想这对产品的推广也会有很大的阻碍，请问你们要如何应对这个问题？
侵权行为也有例如爬取美团、饿了么等平台的数据。在被通告之前我们会尽力满足用户需求。
3. 你们的歌曲评论是从多个平台获取的吗？如果每个平台都有上千条评论，请问你们要怎么向用户展示呢？
我们目前的打算是优先选择网易云音乐的评论，同时用户可以自己进行选择。
答4组：
1. 仅是聚合各音乐软件的接口，且无法保证当前高需求的用户所希望的无损音质，很难保证用户体验极佳，是否存在改进措施？
就音质而言，目前的320K已经能够满足大部分人的需求。
购买手机时自带或自己购买的500元内耳机几乎无大差别。
其次您对于HiFi是什么看法？在Android的默认设置中，任意采样率的声音在Audio Flinger中将被统一升采样到48kHz播出（这一值可以修改，例如统一修正为44.1kHz），vivo和LG是绕过系统的默认硬件通路，在机身塞进了两颗专用芯片及一颗运放芯片来实现的（vivo xplay）。
同时一般的无损歌曲单曲可达到百兆级别，您的储存够吗？
希望您能有更多的了解后再提出此问题。
2. 版权问题是否有考虑解决？
暂时不考虑，做大之后考虑转型。同时有参考一些neets这个网站的做法，起到的是一个社交平台的作用，不是由我们自身网站提供音源；我有个想法就是，开放性，让有想法的人为圈子的人进行支付，或者我们提供一个支付手段，可由多个用户进行支付一首歌的版权
3. 音乐评论的获取是以什么渠道呢，若是“爬虫”来获取则无法盈利，是否有考虑市场前景问题呢？
爬虫。只要版权未谈好，市场前景就存在。
答5组：
1. 如此多的播放器，除去整合功能外，你们还有哪些其他优势？
与竞品的核心竞争力在于我们的UI界面与动效，最早网易云音乐在多个音乐平台中脱颖而出正是因为其优雅的界面。同时有一些功能尚未公布，但在考虑范围内。如通过多个用户的歌单来实现反向推荐，例如一些动漫爱好者，他们会在歌单中添加自己喜欢的bgm，通过对重合度的分析，我们可以向用户反向推荐动漫。
2. 依旧是版权问题，如果你只是单纯的做单机的平台聚合，歌曲整理，是可以的，但是如果牵扯到网络账号，肯定存在版权问题，如何解决？
搁置争议，共同开发。
3.关于评论的弹幕化，是否考虑过听歌时候的状态，我们在如何的情境下听音乐，是否多余的弹幕化？
我们的想法是在mv以及特定的歌曲里（燃烧我的卡路里等）放置弹幕，默认关闭。
答6组：
1. 你好，请问版权问题是怎么解决的？不盈利的话软件如何运营？
2. 你好，请问付费歌曲需要用户通过你们这个软件从原音乐平台购买吗？
不需要，初期未盈利状态我们将参考网易音乐云盘的方式进行分享。
3. 你好，请问你们的原型界面的功能十分不明确，没有查询等界面，能不能给出原型链接？
答7组：
1. ”歌曲搜索“功能，如果输入的是停用词，那么你们能提供多高的准确率？
这问题……建议回去wiki一下“停用词”的定义。
2. ”歌曲整合“功能，用户需要自己手动一个个平台地整合？每次在一个平台有更新歌单，也要手动整合吗，还是已经登陆过的其他平台地账号即使当前并没有登录，也能自动获取那个账户的更新状态？还有，在获取歌单的过程中，只是列出所有的歌曲，还是说能把其他平台已经分类好的歌单也保留下来？你们提供的自动标签是根据什么样的标准分类的，你们定的标准还是用户的标准？整合的时候对于不同平台重复的歌曲又是怎么处理的？
不需要，我们将会在每次用户打开app时自动获取，同时提供一个手动同步按钮。
就目前了解的情况，QQ音乐可以在未登录状态获取用户的歌单。
分类好的歌单会保留，同名进行合并。
目前的计划是按照评论的热词进行检索匹配。
同一歌单重复歌曲自然是保留一个。
3. ”评论“功能，是使用这个APP的用户填写的，还是这首歌所属平台的？如果使用你们产品的用户在你们的产品上对该首歌进行评论，这条评论只会留在你们的产品里，还是说可以同步到这首歌所属的平台，甚至拥有该首歌的其他所有平台？
属于这首歌的所属平台。
我们期待产生自身的数据，同时将此评论同步至对应平台，如果用户有登陆的账户的话。
答8组：
1. 你们产品最大的亮点是实现多家音乐平台的整合功能，既然你们不考虑侵权，那我直接百度云找到资源不就好了？（反正都是侵权）
懒是人的天性。如果同样的电影，在优酷和百度云都有，您选择哪个。
2. 后期的更新和维护在曲库歌曲庞大的情况下如何进行？因为你们是从其他音乐播放器整合过来的，比如歌词更新？
歌词更新将通过用户的点播来实时获取。
3. 想知道歌曲具体是怎么存储的？如果到后面歌曲太多有些删掉的话肯定也会影响用户的体验？
和大部分的音乐软件是一样的处理方式，设置缓存上限，超出后则删除最早的歌曲。如是用户下载则全部保留。
根据答辩中其他组提出的意见和建议修改完善本组需求分析报告，并标明修改之处（5分）
其中淡蓝色为修改部分
提供 《需求规格说明书》作为随笔的附件（经过修改的最终版本）（5分）
遇到的困难及解决方法（5分）
- 困难描述
- LOGO真滴难做！！
- 有些队员联系不到
- 做过哪些尝试
- 尝试过“乐”字的隶书写法进行变换，然而写的字真丑，然后……就没有然后了
- 找联系的到的人来完成
- 是否解决
- 随手一画完成大事业。
- 解决了提出问题的人，扣他分。
- 有何收获
- 苦中作乐。
- 无能为力。
PSP（3分）
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 60 | 60 |
| · Estimate | · 估计这个任务需要多少时间 | 60 | 60 |
| Development | 开发 | 335 | 375 |
| · Analysis | · 需求分析 (包括学习新技术) | 30 | 30 |
| · Design Spec | · 生成设计文档 | 10 | 20 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 20 | 30 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
| · Design | · 具体设计 | 60 | 60 |
| · Coding | · 具体编码 | 180 | 200 |
| · Code Review | · 代码复审 | 5 | 10 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 20 | 15 |
| Reporting | 报告 | 245 | 340 |
| · Test Report | · 测试报告 | 120 | 180 |
| · Size Measurement | · 计算工作量 | 5 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 120 | 150 |
| 合计 | 640 | 775 |