作业链接：https://edu.cnblogs.com/campus/fzu/Grade2016SE/homework/2107
队友地址：http://www.cnblogs.com/ZCplayground/p/9678358.html
PDF：https://files.cnblogs.com/files/ZCplayground/%E8%BD%AF%E5%B7%A5%E7%BB%93%E5%AF%B9%E4%BD%9C%E4%B8%9A%E4%B9%8B%E5%8E%9F%E5%9E%8B%E8%AE%BE%E8%AE%A1-%E8%B5%B5%E7%95%85-%E8%83%A1%E5%B1%95%E7%91%9E.pdf
需求分析
使用《构建之法》中提到的NABCD方法对这个idea进行分析。
N（need，用户的需求）
本次作业的需求是由一名大三的学生“小樱”提出的，小樱作为一名刚入门科研的同学，缺少合理的论文检索和阅读技巧，但他有快速了解研究领域的热门方向的迫切需求。小樱同学无法短期内阅读大量文献，但他想在毕业前完成一篇“站在时代前沿的优秀论文”，所以需要一个好的软件来对文献进行分析和管理。他有以下需求：
- 由于阅读论文的技巧还不熟练，通过阅读大量文献来掌握当前领域的研究情况实在痛苦。希望只需通过给出一个论文的列表，就可以获取近几年顶会的热门领域和研究方向。对热门研究方向以数据可视化的直观形式展示，例如热词图谱。
- 通过这个论文列表，可以直接爬取一些关于论文的基本信息，来方便论文的阅读。例如：论文的作者、摘要、原文链接、属性等，可以节省很多的检索时间。
- 对于这个论文列表，希望能支持增删改操作，方便及时更新自己的论文库。
- 实现类似搜索引擎的功能，通过输入编号、作者、题目来返回相关的paper信息。
- 数据统计功能，方便小樱了解不同国家/学校对各个方向的研究实力、不同顶会/不同年份的热词变化情况等。
A（Approach，做法）
我们打算使用Web端来实现这个软件，主要出于以下几点考虑。首先，Web端的使用较为简便，省去安装/部署的麻烦，只需要在浏览器上输入网址，就可以随时随地、较为轻松地使用论文检索、分析热度等功能。其次，若只做成手机APP的形式，考虑到用户可能会在我们这个软件上直接阅读paper，手机带来的论文阅读体验并不好（字体过小，需要经常滑动屏幕，不方便做批注等）。将软件用网页的形式让用户使用，还能方便用户利用碎片化的时间，在移动终端设备上使用除了直接阅读paper以外的各项功能。
B（Benifit，能给用户带来什么好处）
- 每篇论文都爬取了原文链接，节省大量花在检索上的时间。
- 整理每篇论文的简要信息，节约熟悉一篇论文的精力。
- 分析特定定会论文的热门研究方向，帮助同学们抓住主干，找到研究点。
- 方便用户管理自己阅读的文献、方便用户进行批注、修改等操作。
C（Competitors，竞争）
目前市面上无论是移动端还是桌面端，都存在一些文献阅读管理的软件，例如papers。这类文献管理软件更像是一个“文件整理助手”或“论文笔记整理袋”的角色。我们的软件除了这两个角色之外，还能够快速提取paper的关键信息、热词分析、研究方向统计等，这些功能是传统文献管理软件所欠缺的。我们的软件不仅仅是所有科研工作者的好帮手，更能够很好地帮助到刚刚入门科研的同学（在大学中有不少和小樱相似的，想要入门科研的同学，以及大四要做毕设的同学们），降低他们阅读论文、寻找研究点时遇到的困难。
D（Delivery，推广）
这个软件的适用目标人群是十分广泛的，就是面向所有的科研工作者、在校大学生/研究生。首先，我们打算找到我校大力支持软工实践课的灵魂人物——张栋老师——麾下的实验室，请里面的各位研究生/本科生们试用此软件的各项功能。若软件的各项功能都较为优秀，或者经过用户反馈后进行若干版本更迭后，可以向数学与计算机科学学院的其他实验室进行推广试用，也通过实验室的各位学长学姐推荐给更多的研究人员使用。如果反响不错，可以考虑正式上线。
原型设计
软件模块
使用了 Axure RP 8 原型设计工具。软件的名字暂时定为 SAKURA PAPER（专为小樱同学设计）。初步的原型囊括的功能如下：
欢迎页
- 登陆
- 注册
论文列表
- 显示论文信息
- 原文链接
- homepage
- GitHub
- 阅读模式
- 热词
- 显示列表
- 选择
- 导入
- 删除
- 阅读
- 生成热词
- 检索
热点分析
- 热词图谱
- 会议热点
- 论文数量
- 不同年份、学校、国家研究热点变化情况具体设计：
- 登陆和注册页面：
- homepage，显示论文列表：
- 点击某一篇论文的标题可以查看该论文的详细信息：
- 阅读模式：
- 选择某一会议，分析该会议类别下的研究热点：
- 用户选中一篇论文来查看该篇论文的热词图谱
- 用户输入不同年份、学校、国家研究来查看论文发表的情况、热点变化情况
视频展示
结对过程
瑞：结对过程就好比谈恋爱，你试探一句，我试探一句，两个人就成了:D.由于其他的原因。我们从周五到周日就是无时不刻呆在一起，畅的思想给了我一个新的高度，可以说是软工实践的领路人。在最后的这几天，我们利用了每天下午的两个小时在互相谈论原型设计。
畅：*在上周五，我们先各自开始阅读《构建之法》的第八章，体会用 NABCD 方法来分析软件的方方面面的技巧。然后两人一起通过交流，一起对作业里的软件需求进行分析，并撰写初步的博客内容框架。至周日，基本上完成了NABCD的分析环节，明确了该软件的各个模块和各功能需求。
确定需求，划分清楚功能模块后，在上周日开始原型的建立。刚开始主要还是花时间熟悉 Axure RP 8 的基本用法，熟悉用法之后用起来还是比较方便的。经过周一、周二、周三这几天的增量迭代之后，逐渐完善了原型的设计，并编写博客。*
上周日时分析需求、讨论软件功能时的照片：
遇到什么困难？
- 审美黑洞。不知道好的UI要如何设计，无从下手。既然自己脑子里没有清晰的目标，不如参考现有的优秀UI设计，所以登陆和注册界面的风格就参考了GitHub。配色也是一种问题，好在展瑞给了一个搭配颜色的网站colorhunt，为界面搭配上了和谐的颜色。
PSP、学习记录表
- PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | 10 | 10 |
| · Estimate | · 估计这个任务需要多少时间 | 10 | 10 |
| Development | 开发 | 360 | 530 |
| · Analysis | · 需求分析 (包括学习新技术) | 60 | 80 |
| · Design Spec | · 生成设计文档 | 60 | 120 |
| · Design Review | · 设计复审 | 30 | 60 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 180 | 240 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 30 | 30 |
| Reporting | 报告 | 50 | 60 |
| · Test Repor | · 测试报告 | 30 | 40 |
| · Size Measurement | · 计算工作量 | 10 | 10 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 10 |
| 合计 | 420 | 600 |
- 学习记录表
| 第N周 | 新增代码（行） | 累计代码（行） | 本周学习耗时(小时) | 累计学习耗时（小时） | 重要成长 |
|---|---|---|---|---|---|
| 1 | 500 | 500 | 12 | 12 | 单元测试的写法 |
| 2 | 0 | 500 | 10 | 22 | Axure RP 8 原型设计工具 |
参考链接
http://www.qianjia.com/html/2018-05/28_293381.html
http://openaccess.thecvf.com/CVPR2018.py
1527
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
