课程名称：软件工程实践
作业要求：结对第一次—原型设计（文献摘要热词统计）
结对学号：221600428 | 221600438
作业目标：了解NABCD模型,学习建立软件原型
原型工具：墨刀
PDF链接：下载PDF
NABCD模型
- N（Need）
- 用户可给定论文列表
- 通过论文列表，爬取论文的题目、摘要、关键词、原文链接；
- 可对论文列表进行增删改操作(今年、近两年、近三年)；
- 对爬取的信息进行结构化处理，分析top10个热门领域或热门研究方向；
- 可对论文属性（oral、spotlight、poster）进行筛选及分析；
- 形成如关键词图谱之类直观的查看方式；
- 可进行论文检索，当用户输入论文编号、题目、关键词等基本信息，分析返回相关的paper、source code、homepage等信息；
- 可对多年间、不同顶会的热词呈现热度走势对比（这里将范畴限定在计算机视觉的三大顶会CVPR、ICCV、ECCV内）。
- 可进行数据统计，例如每个国家录用文章的分析、每个学校录用文章的分析、哪个学校哪方面的研究方向比较强等。
- A（Approach）
根据需求,我们打算一个Web的网页原型设计。首先切割功能需求，使页面更加的合理，提高页面的开发速度，减轻编程量。
我们将所有的功能以及展示划分为六个页面，分为主页面、导出论文信息、关键词图谱分析、不同顶会热词呈现的热词走向趋势、学校录用论文分析、国家录用论文分析六大主要页面。另外论文信息检索的界面是直接以网络搜索引擎的检索结果为准。
1、主页面：
（1）将数据统计以及热词统计还有通知作为一栏，这样就是属于链接一栏，这一栏需要做的：
A、通知链接、文字展示。
B、去爬取三大顶会（CVPR，ICCV，ECCV）的论文信息，并且做出统计分析。
（2）以论文编号、题目、关键词为输入的搜索栏作为一个场景。
（3）以论文列表输入的论文信息分析与统计作为场景。（2）（3）作为一栏。
2、导出论文信息作为一个页面，将其结果作为关键词图谱分析的内容。另外还能够对结果为属性分析。故而关键词图谱分析界面作为导出论文信息的子页面。 - B（Benefits）
这个平台的好处就是直击用户的需求----对论文的信息统计分析，能够向用户展示近年来国际的热门领域和研究方向、学校的热门领域和研究重点。同时还能够简略的展示用户所感兴趣的所有论文的简略信息（论文标题、关键词。摘要），让用户能够在短时间内筛选出自己所需要的论文及其信息。 - C（Compettors）
我们的竞争优势已经在B中有所提及，那就是能够让用户在短时间内筛选出自己所需要的论文及其信息，用户需要做的很简单，提供一份论文列表就可以了，或者是用户自己去挑选自己所感兴趣的论文，将其作为分析统计的内容就可以了。 - D（Delivery）
可以通过QQ，微信等通讯工具进行推广。
结对过程
在阅读用户给出需求后，我们在草稿上对基本的设计以及结构做了一定的分析并结合原型页面对需求进行了正常的结构分析（输入内容、处理、输出结果）
原型截图
1、登陆页面
2、注册页面
3、主页面
搜索框：可输入论文编号、题目、关键词，然后在三大顶会爬去相应论文信息。
输入框：论文列表/会议名称----此项用于做论文内容分析---添加则可以将相应论文添加到列表项。
批量导入：用户可以将论文标题、链接等内容制成Excel表格，然后以文件形式导入列表
（按钮---导出论文信息）：论文标题、摘要、关键词、原文链接。
（按钮---选中删除）：对所显示的论文列表里面的选中的论文标题进行删除。
（按钮---筛选）对论文标题进行信息爬取。
（图标--星号）用于论文列表的收藏，方便用户下次的论文信息导入
页面左边三个链接：导出的页面也都是基于三大顶会（CVPR、ICCV、ECCV）的论文信息做出的论文内容筛选（热词呈现在不同年限内的热度走向趋势，国家、学校对论文的录用情况分析）。
4、导出论文信息页面
（按钮--筛选）对属性（oral、spotlight、poster）的筛选
链接：对筛选出来的内容的关键词做数据进行统计分析。
5、关键词图谱分析界面
先是以列表形式以从高到低的占比排序列出关键词的出现占比，再以扇形给出top10关键词占比（即top10研究方向），再以条形图的方式给出top10领域的占比。
6、主页面左边一栏链接（从上到下的顺序）
三大顶会热词走向对比
国家对论文的录用次数对比
上边一个表格列出列表论文每一标题论文的总录用次数。
下边一个即点击论文标题后显示出来的，即表示每一个国家对该论文的录用次数对比（默认是第一篇，存在点击事件）
（均是由高到低的排序）
学校录用论文及研究重点分析
左边表格显示论文被录取的次数具体的显示数目可由客户选定）
右边表格显示学校的研究重点（具体的显示数目可由客户选定）
困难与解决
做为一个编程不算太好的人，做原型设计的时候，对功能实现的具体做法有一定的局限性----（不知道这个功能能不能实现，具体的实现方式是什么）。对此做原型设计会感到畏手畏脚的，因为一旦某个功能觉得不能实现的时候，还需要做出具体的分化。
比如，做议论文列表作为输入，导出论文信息的功能处理的时候，考虑了用户的具体输入是什么。若是只有标题，那么我们必须实现对顶会的论文做处理，并且存储在自己的数据库中，不然，直接爬取信息那么就感觉会出现问题----（但是具体的问题就不知道什么，但是根据自己的理解应该是这样的，直接以论文标题作为输入去检索定位论文的第一手内容，然后对其爬取，那是很容易出问题的，甚至无法实现），对此不清楚这个问题需要在原型设计中怎么展现出来。
所以问题的解决方法也只能记录问题的所在，然后留待具体的实现的时候讨论方案设计。
所以存在一个问题，做原型设计的时候是不是需要设计师和程序员的相辅相成才能够设计出更加合理，贴近基于能够实现的原型设计。然后考虑到这，问题的答案已经呼之欲出了----两者的兼顾是十分必要的。只是我们现在的所学有限，限制住了我们的实现方式...
出现这种问题的时候，我们需要记录问题，在讨论实现的可能性，再反馈到原型设计中。
PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
|---|---|---|---|
| Planning | 计划 | ||
| • Estimate | • 估计这个任务需要多少时间 | 580 | 640 |
| Development | 开发 | 520 | 580 |
| • Analysis | • 需求分析 (包括学习新技术) | 60 | 60 |
| • Design Spec | • 生成设计文档 | 120 | 150 |
| • Design Review | • 设计复审 | 30 | 30 |
| • Coding Standard | • 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| • Design | • 具体设计 | 300 | 330 |
| • Coding | • 具体编码 | 0 | 0 |
| • Code Review | • 代码复审 | 0 | 0 |
| • Test | • 测试（自我测试，修改代码，提交修改) | 10 | 10 |
| Reporting | 报告 | 60 | 60 |
| • Test Report | • 测试报告 | 20 | 20 |
| • Size Measurement | • 计算工作量 | 20 | 20 |
| • Postmortem & Process Improvement Plan | • 事后总结, 并提出过程改进计划 | 20 | 20 |
| 合计 | 580 | 640 |